AWS ANGEL Dojo 活動報告

Transcript

1. AWS ANGEL Dojo活動報告 1
2. アジェンダ 1. ANGEL Dojoとは 2. 企画・開発フェーズ 3. 開発したサービスの概要 4. さいごに 2
3. アジェンダ 1. ANGEL Dojoとは 2. 企画・開発フェーズ 3. 開発したサービスの概要 4. さいごに 3
4. ANGEL Dojoとは ANGEL(AWS Next Generation Engineer Leaders) Dojo 「AWSで日本を元気に！」というテーマで開催されている、AWS主催のハッカソン型の研修 ➢ 参加企業：ユーザー企業（年次制限なし）、パートナー企業（2-3年目） ➢ 1チームにつき5-6名に分かれて、ビジネスモデルの決定からサービスの実装までを期間中に行う ➢ 開発手法やW-Aに関する講義がある 4 事前 トレーニング 企画 フェーズ 開発フェーズ 07/11 Kickoff 08/02 PR提出 09/06 中間発表 10/10 最終発表 10/25 頂上決戦
5. ANGEL Dojoとは ➢ 1チームにつき5-6名に分かれて、ビジネスモデルの決定からサービスの実装までを期間中に行う 5
6. ANGEL Dojoとは サービス開発以外の活動も実施 ➢ LT 朝会・夕会の中で有志がLTを実施 ➢ アドベントカレンダー 有志が持ち回りで毎日ブログ記事を投稿 2024-ANGEL-Dojo - Qiita 6
7. アジェンダ 1. ANGEL Dojoとは 2. 企画・開発フェーズ 3. 開発したサービスの概要 4. さいごに 7
8. 講義内容 8 ➢ Working Backwards Workshop ➢ 生成AIのユースケースとサービス紹介 ➢ エンドユーザーとSIerの関わり方 ➢ アジャイル・スクラム講義 ➢ モブクログラミング ➢ BizDevOps講義 ➢ Well-Architected基礎 ➢ マイグレーション & モダナイゼーションとITXのご紹介
9. 講義内容 9 ➢ Working Backwards Workshop ➢ 生成AIのユースケースとサービス紹介 ➢ エンドユーザーとSIerの関わり方 ➢ アジャイル・スクラム講義 ➢ モブプログラミング ➢ BizDevOps講義 ➢ Well-Architected基礎 ➢ マイグレーション & モダナイゼーションとITXのご紹介
10. 講義内容 10 ➢ Working Backwards Workshop ➢ 生成AIのユースケースとサービス紹介 ➢ エンドユーザーとSIerの関わり方 ➢ アジャイル・スクラム講義 ➢ モブプログラミング ➢ BizDevOps講義 ➢ Well-Architected基礎 ➢ マイグレーション & モダナイゼーションとITXのご紹介
11. Working Backwards 11 全ては、お客様を起点に考え、お客様体験を徹底的に固める アマゾンのイノベーションメカニズム ➢ お客様は誰か？ ➢ お客様の課題は何か？ ➢ 解決策は？ ➢ お客様のメリットは？ ➢ 新しいお客様体験とは？ PR作成 FAQ作成 5つの質問
12. Working Backwards（5つの質問） 12 お客様は誰か? お客様の課題は何か? 解決策は? お客様のメリットは? 新しいお客様体験とは? 名前:山田花子 性別:女性 年齢:22歳 職業:営業 電話の頻度:5回/日 緊張して上手く話せない 実践的な練習を積むことが難しい 場数を増やす フィードバックを貰える機会を作る 相手がいなくても練習できる（好きな時にいつでもどこでも） フィードバックがもらえることで効率的に電話練習できる 自分の好きなタイミングで電話練習することができるようになる 話すスピードや敬語の遣い方等、細かいフィードバックが得られるようになる
13. Working Backwards（PR） 13 導入 課題 課題解決 お客様の声
14. Working Backwards（FAQ） 14 考え得る全ての質問に対する 回答を作成
15. 講義内容 15 ➢ Working Backwards Workshop ➢ 生成AIのユースケースとサービス紹介 ➢ エンドユーザーとSIerの関わり方 ➢ アジャイル・スクラム講義 ➢ モブプログラミング ➢ BizDevOps講義 ➢ Well-Architected基礎 ➢ マイグレーション & モダナイゼーションとITXのご紹介
16. モブプログラミング 16 3人以上の複数人で1つのコードを共有しながらプログラミングをする開発手法 ➢ 実際にコードをかくドライバーは一人 ➢ 他の人はナビゲーターとしてドライバーに指示を出す ➢ ドライバーとナビゲーターは一定期間で交代する ➢ 知識の共有に繋がる ➢ 認識のすり合わせができる ➢ コードレビューが常時実施される ➢ コミュニケーションが活発になる
17. 開発フェーズ 17 モブプログラミング・ペアプログラミングは実施せず ➢ 技術的な挑戦が多く、工数が足りない 各個人で構築を実施 ➢ 作業中は常にZoomを繋げて、すぐに会話ができる状態にしておく ➢ 疑問点・エラーが発生したらモブプログラミング・ペアプログラミングを実施
18. アジェンダ 1. ANGEL Dojoとは 2. 企画・開発フェーズ 3. 開発したサービスの概要 4. さいごに 18
19. サービス概要 19 AIを使用した電話練習サービス
20. サービス概要 20 AIを使用した電話練習サービス ➢ 電話に対する苦手意識の払拭 ➢ 電話スキルの向上
21. Tele Talk Tutor（T3）とは シチュエーションを設定するだけで、いつでもどこでも電話練習ができるサービス フィードバック機能 様々な場面に活用可能 21
22. ①シチュエーション登録 ②電話練習 ③フィードバック確認 22
23. ①シチュエーション登録 ②電話練習 ③フィードバック確認 23
24. ①シチュエーション登録 ②電話練習 ③フィードバック確認 24
25. Tele Talk Tutor（T3）とは シチュエーションを設定するだけで、いつでもどこでも電話練習ができるサービス フィードバック機能 様々な場面に活用可能 25
26. 想定ユーザーと活用場面の一例 26 大学生(19歳/接客アルバイト) 予約対応 商品在庫の問い合わせ対応 新入社員(23歳/営業職) 新規取引先へのアポイントメント 既存顧客への自社製品紹介
27. 様々な場面に活用可能 シチュエーション登録機能で相手と場面を設定しリアルな会話に 27
28. ①デフォルトで選択（2パターン） 28 様々な場面に活用可能 ②カスタマイズでシチュエーション登録
29. Tele Talk Tutor（T3）とは シチュエーションを設定するだけで、いつでもどこでも電話練習ができるサービス フィードバック機能 様々な場面に活用可能 29
30. フィードバック内容 ◼ 言葉遣い ◼ 感情 30
31. 良い点： 緊急の問題発生を報告する目的を明確に伝えており、簡潔に要件を説明しています。また、上司の時間を尊重し、3分 ほどの時間をいただけるか確認している点は適切です。さらに、「お疲れ様です」という挨拶から始めており、基本的なビジ ネスマナーを押さえています。 悪い点： 問題の具体的な内容や緊急性の度合いについての説明がなく、上司が状況を把握しにくい可能性があります。 改善点： 問題の概要や影響範囲、緊急度について簡潔に説明を加えると、上司がより状況を理解しやすくなります。例えば、「昨 日リリースしたシステムで顧客データにアクセスできない重大な問題が発生し、早急な対応が必要なため」といった具体的 な説明を加えると、より適切な報告になるでしょう。 フィードバック内容(例) 31 ◼ 言葉遣い
32. フィードバック内容(例) 32 感情分析結果： 電話の内容全体を通して、感情は中立的(NEUTRAL)です。緊急の問題が発生したという深刻な状況にもかかわらず、 落ち着いた態度で報告しています。 改善点： ・緊急の問題を報告する際は、もう少し緊急性や重要性を声のトーンに反映させると良いでしょう。例えば、声に若干の 緊張感を持たせることで、状況の深刻さを適切に伝えられます。 ・上司に対して丁寧な言葉遣いを使用していますが、緊急時には簡潔さも重要です。「お時間よろしいでしょうか？」という 表現は省略し、すぐに本題に入ることも検討してください。 ・全体的に感情の起伏が少ないため、問題の重要性が十分に伝わらない可能性があります。声の抑揚を適度につけるこ とで、メッセージの重要度をより効果的に伝えられるでしょう。 ・ただし、過度に感情的になることは避け、プロフェッショナルな態度を保つことが大切です。緊急性と冷静さのバランスを取 ることを心がけてください。 ◼ 感情
33. Step Functions アーキテクチャ AWS Cloud Tokyo Region Amplify Cognito 利用者 Bedrock 返答生成 S3 S3 GitHub AppSync Transcribe Bedrock データ変換 DynamoDB SNS DynamoDB CloudTrail CloudWatch GuardDuty SNS Security Hub Config EventBridge 運用者 S3 Chatbot Health Dashboard React アプリケーション 開発者 音声データ 会話 テキストデータ WAF Osaka Region Backup Backup 外部API連携 シチュエーションデータ EventBridge 署名付きURL生成 Route 53 33
34. Step Functions アーキテクチャ AWS Cloud Tokyo Region Amplify Cognito 利用者 Bedrock 返答生成 S3 S3 GitHub AppSync Transcribe Bedrock Lambda DynamoDB SNS DynamoDB 運用者 React アプリケーション 開発者 音声データ 会話 テキストデータ WAF Osaka Region Backup Backup 外部API連携 シチュエーションデータ EventBridge 署名付きURL生成 Route 53 CloudTrail CloudWatch GuardDuty SNS Security Hub Config EventBridge S3 Chatbot Health Dashboard 通話機能 34
35. Step Functions アーキテクチャ AWS Cloud Tokyo Region Amplify Cognito 利用者 Bedrock Lambda S3 S3 GitHub AppSync Transcribe Bedrock データ変換 DynamoDB SNS DynamoDB 運用者 React アプリケーション 開発者 音声データ 会話 テキストデータ WAF Osaka Region Backup Backup 外部API連携 シチュエーションデータ EventBridge 署名付きURL生成 Route 53 フィードバック機能 CloudTrail CloudWatch GuardDuty SNS Security Hub Config EventBridge S3 Chatbot Health Dashboard 35
36. 通話機能 利用者 Bedrock 返答生成 S3 AppSync DynamoDB React アプリケーション 会話 テキストデータ WAF 外部API連携 シチュエーションデータ 署名付きURL生成 返答の生成 登録されたシチュエーションと ユーザが話した内容をもとに Bedrockで返答内容を生成 シチュエーション登録 電話のシチュエーション(相手と場面) の情報をDynamoDBに登録 DynamoDB Bedrock 返答生成 返答の音声変換 外部APIと連携し 返答内容を音声データに変換 音声（S3署名付きURL）に返す S3 DynamoDB 署名付きURL生成 外部API連携 AppSync AppSync 36
37. Step Functions フィードバック機能 利用者 S3 AppSync Transcribe Bedrock DynamoDB SNS React アプリケーション WAF EventBridge 音声データ フィードバック作成 Transcibeで感情分析と文字起こし Bedrockでフィードバックの作成 フィードバック完了通知 ユーザにフィードバック作成が 完了したことをメールで通知 SNS フィードバック作成の開始 S3 EventBridge Stepfunctions 会話データがS3に格納されると フィードバック作成を開始 37 データ変換 Bedrock Transcribe DynamoDB データ変換
38. AWS Well-Architectedへの対応 運用上の優秀性 セキュリティ 信頼性 パフォーマンス効率 コスト最適化 持続可能性 監視・通知機能を用いた運用 全てのリソースをサーバレスで構成 W-A 6つの柱 データベースのバックアップ T3による実現方法 Cognito･WAFを用いた制御・防御 セキュリティサービスを用いた脅威検知 マネージドサービスを利用し、運用負荷軽減 統制管理サービスを用いた変更管理 データベースのTTL設定 ストレージのライフサイクル設定 38
39. アジェンダ 1. ANGEL Dojoとは 2. 企画・開発フェーズ 3. 開発したサービスの概要 4. さいごに 39
40. さいごに（活動を通して学んだこと） 40 チームワーク・雰囲気作りの重要性 ➢ GW中は画面オン・適度に雑談を挟む ⇒各々が意見を出しやすい環境がつくれた ➢ メンバー全員が納得いくまで話し合いをする ⇒一切妥協することなく自分たちが満足できるサービスの開発に繋がった
41. さいごに（活動を通して感じたこと） 41 自分で考えることが習慣づいた ➢ 正解が分からない状態で開発を行っていく ⇒課題に対して自力で答えを出す力がついた 自信を持てるようになった ➢ 設定内容・エラー内容をメンバーに説明する ⇒「できる」「理解している」を実感し、自分ができることが明確になった
42. さいごに 42 正直、期間中はすごく大変ではありましたが… その分得られるものが沢山ありました！ ➢ 案件では触れない技術に挑戦できる ➢ 同世代と切磋琢磨しあえる ➢ 他社SEと繋がりができる ➢ サービスが完成したときの達成感を味わえる
43. おわり ご清聴ありがとうございました 43
44. CloudFormation Appendix:監視・通知機能 CloudTrail CloudWatch GuardDuty SNS Security Hub Config EventBridge 運用者 S3 Chatbot Health Dashboard 1. ヘルスチェック 2. 障害情報チェック 3. 統制管理 4. セキュリティ情報管理 5. 脅威検知 6. イベントルーティング 7. 通知 8. ログ保管 通知 メール、Slackを用いて、 検知情報を運用者へアラート発報 SNS Chatbot Security Hub セキュリティ情報管理 セキュリティ情報の一元管理 ベストプラクティスに沿っているか監視 ヘルスチェック リソースのメトリクスを監視し、 サービスの低下を検知 CloudWatch 44
45. 【監視するメトリクス】 ◼ AppSync • Latency ◼ Bedrock • InvocationLatency:呼び出しレイテンシー • InvocationClientErrors:クライアント側で発生した呼び出しエラーの数 • InvocationServerErrors:サーバー側で発生した呼び出しエラーの数 ◼ DynamoDB • ConsumedReadCapacityUnits:読み込みキャパシティユニット使用量 • ConsumedWriteCapacityUnits書き込みキャパシティユニット使用量 • SystemErrors:システムエラー数(500エラー) • UserErrors：ユーザーエラー数(400エラー) ◼ S3 • BucketSizeBytes:バケットのデータ量 ◼ Lambda • Duration:関数実行時間 • Errors:エラー数 • Throttles:同時実行数を超えた呼び出し試行回数 ◼ StepFunctions • ActivitiesFailed：失敗したアクティビティの数 45 Appendix:アーキテクチャ
46. 機能 サービス 用途 ヘルスチェック CloudWatch ・Bedrock、DynamoDB、AppSync、Lambda、 Stepfunctions、S3のメトリクスを監視し、サービスの低下を検知 統制管理 Config, CloudTrail ・リソース、ユーザーの操作をモニタリングしガイドラインに準拠してい るか監視 障害情報チェック Health Dashboard ・発生している障害やメンテナンス情報の確認 脅威検知 GuradDuty ・取得したログから機械学習を用いて脅威を検知 セキュリティ情報一元 管理 Security Hub ・GuardDutyやConfigといったセキュリティ情報の一元管理 ・ベストプラクティスに沿っているか監視 イベントルーティング EventBridge ・検知結果を集約し、脅威度に合わせ通知サービスへルーティング 通知 SNS、 Chatbot ・メールやSlackを用いて運用者へのアラート発報 ログ保管 S3 ・監査ログの保管 46 Appendix:監視通知
47. 【サービスの需要】 一日あたりの業務上の受電回数：7.4回/人 平均電話時間：3.1分/回 7.4回×3.1分＝22.94分/日 22.94分/日×245日（平均営業日数）＝93.6時間/年 93.6時間/年×2000円（平均時給）＝18万7200円/年 1年で平均18万7200円分の時間を 電話業務に費やしている 47 Appendix:電話業務におけるコスト 引用：株式会社ソフツー（https://www.miraiai.jp/research_231101/）