ホーム エンジニア AWS ANGEL Dojo Season2 アピリッツチーム 成果発表
ANGEL Dojo Season2 アピリッツチーム 成果発表
 

ANGEL Dojo Season2 アピリッツチーム 成果発表

前書き

デジタルビジネス部所属の渡邊と申します。

私は2020年6月12日より、AWS 主催のエンジニア向けイベント ”ANGEL Dojo Season2″ にアピリッツチームとして参加しており、2020年9月4日に最終発表を行いました。そこで発表をした、私たちが企画から開発までを行ったサービスについてを、本記事で紹介します。

ANGEL Dojo についての詳しい概要は、過去の記事を参照ください。

関連:出てこい!AWSネイティブ世代 ~若手エンジニアがAmazon Web Services 主催 ANGEL Dojoに参戦!~

関連:新卒も参加中! AWS主催 “ANGEL Dojo Season2” 若手エンジニアインタビュー

関連:AWS主催イベント“ANGEL Dojo Season2” 最終成果発表会 レポート


会社に入りたての頃、困ったときに誰かに相談できましたか?

皆さんは会社に入ったばかりの時に、困ったことがあった場合に気軽に誰かに相談できる環境があったでしょうか?

例えばエンジニアであれば、プログラムでエラーが発生し自分では解決できなさそうだけど、いつも相談している先輩が忙しそうで聞きづらい。また、会社のルールについてわからないときに誰に聞けばよいのかがわからず無駄な時間を過ごしてしまう、なんて経験したことのある方々も多いのではないかと思います。

弊社では社内コミュニケーションツールとして Slack を利用しています。仕事中にわからないことが出てきた場合は、社員全員が参加しているチャンネルや部署のチャンネルで相談を投げれば解決するのかもしれません。

でも、発言とともに自分の名前が出ると思うと「こんなこともわからないの?」と思われてしまうのでは…と身構えてしまったり、個人的な内容を全体チャットに投げてみんなに通知が行ってしまい迷惑になるのではないか、と不安となってしまったりなど、入りたての頃は正直恥ずかしくて気後れしてしまいますよね(勿論、そんなこと無いって方もいるかもしれませんが)。

また、相談する側だけでなく回答する側にとっても、多くの人が見える中で間違った情報を伝えてしまうと恥をかくリスクがあったり、発言するハードルは低くはないはずです。

このように、相談する側と回答する側のお互いがチャットでの発言を遠慮をしてしまった結果失われる時間は非常にもったいないと私たちは考え、課題と捉えました。

そこで、私たちはこのようなサービスを考案しました。

こまっち 【困っている社員と相談できる社員をマッチング!】

名前を明かさずに相談を投げ、相談に乗ってくれる人が居たらマッチングするというSlackbot、その名もこまっちです。

こまっちを使えば、困っている人は気軽に相談を投げることができるし、誰に聞けば良いかわからないような内容でもこまっちが相談相手を探してくれます。また、相談を受ける人も1対1での会話になるので人目を気にせずアドバイスをすることができます。

また、今まで話したことのない社員同士がつながるきっかけとなる可能性も生まれます。

それでは、こまっちの仕組みを説明していきます。

マッチングするまでの流れ

まず、困っている人はこまっちに相談を投稿します。

すると、こまっちは投稿された文章から特徴的なキーワードを解析・抽出し、それを元に答えられそうなユーザを数人探します。その後こまっちは探し出したユーザに対し、相談投稿者の名を明かさずに相談内容のみを送ります

相談内容が送られたユーザーは、相談に乗ることができる場合はOKを、そうでなければNGを選択できます。

OKを選択したユーザーは、こまっちによって投稿者とマッチングし、相談投稿者に対して Slack アカウント情報が伝えられます(この時点ではまだ相談投稿者の名は明かされません)。

あとは相談投稿者から DM でやりとりしたり、直接会って相談するなどアクションを起こし、自由に連絡をとることが可能です!

実際の見た目はこのような感じです。こまっちのAppを追加し、こまっちのホーム画面を開くと「相談相手を探す」ボタンが表示されるので、押して出てくるフォームに相談の概要を書いて投稿します。

アーキテクチャ紹介

ANGEL Dojo は AWS 主催のイベントということで、Slack 以外の部分は全て AWS のサービスによってこまっちを作り上げました。

こだわったポイントは、保守運用を簡単にするためにフルサーバレスな構成としたところです。今回、サーバーレスなアプリケーションの構築のために、AWS サーバーレスアプリケーションモデル、通称 SAM ( Serverless Application Model )を用いて開発しました。

相談が投稿されてからマッチングするまでの処理ごとにどのような動きになるのかを具体的に見ていきます。

1) Slack で相談が投稿される → 他のユーザーへ相談内容を通知する

Slack で相談が投稿されると、 Amazon API Gateway からリクエスト受付AWS Lambda が起動します。

リクエスト受付AWS Lambda は、リクエスト情報から次に実行する AWS Lambda の振り分けを行いますが、リクエストが相談投稿の場合は、相談投稿を処理するための、内容解析相談登録相談相手取得通知、の4つの AWS Lambda 群を管理する AWS Step Functions が実行されます。

1つ目の内容解析 AWS Lambda では、 Amazon Comprehend を用いて投稿された内容からキーワード抽出を行います。

例えば「EC2について教えて下さい。」といった相談投稿がされたとします。すると、「EC2」のようなキーワードを抽出し、2つ目の相談登録AWS Lambda に、抽出したキーワードを渡します。

この相談登録AWS Lambda では、渡されたキーワードや相談概要、また相談投稿者の情報を、まとめて Amazon DynamoDB に登録します。

相談登録の処理が終わると、3つ目の相談相手取得AWS Lambda が呼ばれて、キーワードをもとに通知を送るユーザーを5人ランダムに選び、4つ目の通知AWS Lambda に情報を渡します。

最後にこの通知AWS Lambda で、選ばれたユーザーに対してこまっちから Slack のメッセージを送信します。

2) マッチングが成立する

選ばれたユーザーに対して送られる Slack のメッセージには「OK」と「NG」のボタンが表示されていて、「OK」を押すと、リクエスト受付AWS Lambda からOKした人を通知する AWS Lambda が起動します。

この AWS Lambda では、「OK」を押したユーザーの情報を相談投稿者に対して、こまっちから Slack のメッセージを送信します。

3) 相談が解決する

相談投稿者に対して送られる、「OK」を押したユーザーの情報のメッセージには、「解決」ボタンも含まれています。相談投稿者が解決したと判断した場合にはこの「解決」ボタンを押してもらいます。すると、リクエスト受付AWS Lambda から解決処理AWS Lambda が呼ばれ、相談が誰によって解決されたのか、また、解決したユーザーに、最初に相談概要から抽出されたキーワードを紐付け、 Amazon DynamoDB に登録します。

つまり、相談が解決されればされるほど、解決した人がどんな分野に長けているかの特徴付けがされていくという仕組みです。

その他) Slack ワークスペースのユーザー情報の取得

相談概要を他のユーザーへ通知するために、前提として Slack ワークスペースの全ユーザー情報を Amazon DynamoDB に登録しておく必要があります。そのため、 Amazon EventBridge を用いて、ユーザー登録AWS Lambda を1日に1回実行させ、 Slack から取得できるユーザー情報をもとに Amazon DynamoDB へ登録をしています。


後書き ~ ANGEL Dojo で学んだこと ~

ANGEL Dojo が始まる前は、様々な AWS のサービスに触れることが主な目的と捉えていました。しかし本当は、 AWS という会社がどのようにサービスを生み出しているかのノウハウを吸収させてもらえる場ということがわかりました。実際に私たちのワークショップは、具体的に実在しそうな人物象を設定し(ペルソナ設定)、その人がどんな課題を抱えていてその課題を解決するにはどんなものが必要か、という設計から始まりました。これは今までやったことない経験であり、ほかチームよりも難航してスケジュールが遅れるほど苦労しましたが、「ただ要件通りにシステムを作るプログラマー」ではなく、「今、どのようなシステムが求められていて、そのシステムを当初の要求から逸れずに完成させる」、という流れに触れた経験は非常に大きかったと、私は思います。

また、もちろん技術的な面でも得られるものは大きかったです。私はこれまでの業務の中で AWS に触れる機会はあったものの、アプリケーションサーバーとマネージドデータベースとクラウドファイルストレージの構成といったものの経験しか無く、今回サーバレスなアプリケーションに挑戦したことにより、サービス構築時のインフラストラクチャーの選択肢を広げることができたと思います。

この場で恐縮ですが、 ANGEL Dojo を主催してくださった AWS の方々、また、 ANGEL Dojo に参加できるように手配してくださった社内の方々にお礼を申し上げます。

現時点でまだまだこまっちは完成したとは言えない状態です。例えば、最初相談を投げてから誰も相談相手が見つからなかった場合の考慮や、よくされる相談はデータとして蓄積しナレッジツールとしても使えるようにしたいなど、課題が残っています。ただ、こちらに関しては、 ANGEL Dojo は終了したもののチームメンバーは引き続き完成させることを目標に動くことが決まりました。また、ゆくゆくはチームメンバー以外で有志を募り、実際に運用していくことを目指しています。続報があれば本ブログにてお伝えしていければと思います。

最後に、 ANGEL Dojo の最終発表時のプレゼンテーションファイルを添付して本記事は以上とさせていただきます。

最後までご覧いただきありがとうございました!

アピリッツ_ANGEL_Dojo_2nd_最終発表

記事を共有

最近人気な記事