Tech Sketch Bucket of Technical Chips by TIS Inc.

なんでもインタビューできるシステム「GLEAN」の企画・設計・開発

Pocket

TIS株式会社 戦略技術センターの新人研修としてチーム開発演習を行いました。

本記事は菊谷・林﨑チームによる、研修の成果報告を中心とした記事です。

研修概要

研修の目的は、アプリケーションの開発・運用・保守の経験です。
2か月半に渡る期間は、まず半月、基礎技術に関する研修を行い、そこで蓄積した知識を基に2か月間、2人1組でアプリケーションの開発・運用・保守を行うという流れで行われました。

基礎研修

基礎演習では、後のチーム開発演習や実際の業務で関わる技術の基礎を習得するために、以下の3つの個人演習が行われました。

その他、講義や輪講、ミーティングは基礎研修からチーム開発演習まで通して、随時行われました。

  • Python演習(5/16~5/23)
    • Pythonを用いた基礎的なプログラムの開発演習を行いました。
  • JavaScript演習(5/24~5/27)
    • JavaScript、及びDOM(Document Object Model)について学習するための演習を行いました。
  • Webアプリケーション演習(5/30~6/3)
    • Python用WebフレームワークであるDjangoの扱い方を、日報管理アプリケーションの開発という形で学習しました。
  • 講義等
    • 各種講義
      • Webアプリケーションフレームワークに関する講義
      • テストコードの書き方
      • GitHubの使い方
      • デプロイの仕方
    • CentOSインフラ構築輪講
    • 日報/週報/週次MTG

チーム開発演習

チーム開発演習は2人1組で、「一連の開発工程を実践し学習する」「チームで開発し、それを円滑に進めるための手法を習得する」「自分たちでアイデアを出し、形にする力を身につける」の3つを目的に行われました。

開発要件

以下の要件を満たすWebアプリケーションの開発を行いました。

  • テーマ:「TIS新人営業が打ち合わせのために使うツール」
  • 要件:
    • Pythonを使用すること
    • Cloud環境上で実行できること
    • インターネットからアクセスできること

開発スケジュール

実際の開発は以下のスケジュールで行われました。

  • 開発前半 6/6~7/20
    • 営業の方へのヒアリング
    • スケジューリング/画面設計
    • 機能実装/デプロイ
  • 開発後半 7/20~8/5
    • 他チームとのPull Request送受信
    • 機能修正/追加

開発後半のPull Requestの送受信は、疑似的な運用・保守の実践として行われました。

開発したサービス

開発したアプリケーション「GLEAN」は、Web上でインタビューを行うアプリケーションです。

ユーザーの課題

ヒアリングの中で、新人営業の打ち合わせにおける問題点として、様々な分野における知識の不足や認識の相違といったものが挙げられました。
それに対し、当社新人営業は、育成の一環として先輩や上司の方に対するインタビューを行っています。しかし、その現状として、以下の課題が挙げられます。

  • 時間が少なく、聞きたいことを聞ききれない
  • 聞きにくい質問をしにくい、聞いていい質問なのかわからない

原因

インタビューという形式は、新人営業が必要とする知識や情報を、ピンポイントで取得し、育成に繋げられるという点で有利です。しかし、特にインタビューされる側である先輩、上司側の時間的な制約により、最低限の質問しかできないという現状となっています。

また、新人だからこそ、例えば「一番まずい失敗の経験」というような聞きにくい、または聞いていいのかわからない質問も多く存在し、同時に、その様な質問に対する回答こそ多くの知識や経験を与えるものでもあります。加えて、新人がそれぞれにインタビューを行うという形式から、回答する側は必然的に同じような質問を受け、同じような回答を返すという形となり、作業感が増してしまうということも問題です。

私たちは、これらの「新人営業が行うインタビュー」だからこその課題の解決を目指しました。

その成果がWebインタビューシステム「GLEAN」です。

アプリケーションの特徴

私たちはアプリケーションにbotを搭載しました。

ロボットは人ではないからこそ、人がやれば怒られるようなことをしても怒られにくいとされています。その点は発話botも同様です。

そこで、私たちが実装したbotに定義した役割は、質問者の聞きたいことを代わりに聞いてくれることと、第三者の視点を取り入れることの二つです。

以下に動作イメージを示します。

bot

ユーザーは、通常の質問によるインタビューのほか、botの発言を促したり聞きたいことをbotに代わりに質問してもらうことができます。

開発の進め方

今回の開発では、意思決定に関わる作業(ヒアリング、要件定義、完成イメージの作成)を共同で行い、実装はメンバーで役割分担して行いました。毎朝、お互いに進捗とその日の作業内容を報告し、必要に応じてリスケやOJTの先輩への報連相を徹底しました。お互いの状況を把握しながら開発を進めたことで、開発が大幅に遅れることなく進めることができました。

チーム作業

まず最初に、当社営業の方に、「新人営業が打ち合わせに対して、どのような課題を抱えているのか?」という観点でヒアリングを行いました。

その結果から、私たちは「新人とベテランの間に知識、認識のギャップを埋めるアプリを作る」という考えを共有し、要件定義や完成イメージ、スケジュールの作成を行いました。

チームとしての作業が終わった後、担当する作業を分担し、個人ごとの実装作業に移りました。

共同作業

分担作業(菊谷)

菊谷は主に画面設計を中心としたクライアントサイドの実装を担当しました。

また、テストコードや発表資料の作成を行いました。

担当作業_菊谷

分担作業(林﨑)

林﨑はリアルタイムWebシステムの実装を中心にサーバーサイドシステムの構築を担当しました。

また、クライアントサイドとサーバーサイドの結合、デプロイ、GitHubドキュメントの作成を担当しました。

担当作業_林﨑

振り返り

チーム振り返り

今回のチーム開発で良かった点は、OJTの先輩にレビューや相談をこまめに依頼できたことです。第三者からの意見を参考にすることで、自分たちに足りていないものに気付くことができ、同時に、無駄な作業をせずに済みました。

一方、悪かった点はチーム内でのコミュニケーションがうまく取れなかったことです。主な原因は言葉や単語に対する認識のズレや抽象的な表現を多用して説明していたからでした。また、認識がずれているにも関わらず、それを認識しないまま自分の解釈で話を進めてしまったため、開発途中で揉めることも多々ありました。言葉の使い分けや具体的に表現することの大切さを学びました。

今回は、先輩からのレビューがきっかけで自分たちの誤解に気付き、話し合い、無事に解消できましたが、今後はこの経験を活かして自ら誤解を解消できる、未然に防げるよう、情報の発信方法と受信方法を改善していきたいと思います。

個人振り返り(菊谷)

今回の開発では、作業の進め方と技術に関して、成長できたと感じました。

作業の進め方について、いきなり手をつけるのではなく、全体像をいかに速く明確にできるかが重要だと感じました。開発前半は完成させることばかり考えて、調査した内容に抜け漏れがあり再調査等、やり直しが多発しましたが、後半では、まずやることを決めてしまうことで、抜け漏れを早い段階で気付き、無駄な時間を減らすことができました。

技術面では主に画面設計を担当し、HTML, CSS, JavaScriptについて理解を深めることができました。予め、完成イメージを明確にしていたことで必要な技術調査を効率的にでき、Materializeフレームワークを活用したことでイメージ以上のものを作ることができました。

一方で、自分が担当しなかった作業(サーバサイドやデプロイ)について、あまり理解できなかったことは課題だと感じました。特に、開発後半はお互いに自分が担当した機能しかわからず、機能の追加や修正は担当した方しか行えなかったことは改善すべきだと感じました。

個人振り返り(林﨑)

研修を通して、最もよかったことは、調査→デモ実装→本実装という流れでの機能実装を習得できたことです。調査したことをそのまま機能の実装に活用するには、その調査内容を開発中のアプリの合う形に落とし込むために、多くのギャップを解消する必要があります。それに対し、デモ実装などの段階を間に挟むという流れは、段階の間のギャップを小さくし、スムーズな機能実装につながる結果となりました。この流れはほかの多くの技術を習得する際にも意識して実践したいと思います。

チーム開発演習の中で最も大変だったのは、コンセプトとソリューションを決めることでした。研修の一部という意識が捨てきれず、期間内に開発するという、QCDのD(デリバリー)を重視した結果、ユーザーの何を解決したいのか、本当に解決できるのかという最も重要な部分がおろそかになり、OJTの先輩方を交えつつ、チームで何度も話し合うことになりました。

ユーザーの視点は重要であり、ソリューションは作る側の押し付けであってはいけません。チーム振り返りでも触れていますが、不明点を聞く、相手の意見を聞く、単純ですが、まずはその回数と頻度を増やすことから改善していきたいと思います。

リンク

GLEANのGitHubリポジトリ: tech-sketch/GLEAN

エンジニア採用中!私たちと一緒に働いてみませんか?