# 【ANGEL Dojo体験記】顧客視点でチームを強くする！5つの実践的ワークショップ

はじめに

この記事は、7月中旬から始まったANGEL Dojoでの私たちの取り組みとと、そこで得られた学びについて共有させていただきます。

前回の記事（3ヶ月間のハッカソン型プログラム「ANGEL Dojo」参加体験記）では、ANGEL Dojoでの取り組みや、私がどのようにAWSの知識を身につけ、スキルアップできたのかをまとめました。
今回はその続編として、講習で学んだ具体的な開発プロセスや、チームでのワークショップの内容を共有します。

技術的な習得だけでなく、Amazon流のサービス開発や現代的なチーム運用について深く知る機会となりました。
社内の皆さんの業務にも役立つエッセンスがあれば幸いです。

紹介するワークショップ一覧

• Working Backwardsワークショップ
• アジャイル・スクラム
• モブプログラミング
• BizDevOps
• AWS Well-Architected Framework

1. Working Backwards：顧客の幸せを定義する

ANGEL Dojoのキックオフから体験したのが、Amazonのすべてのサービス開発の根幹にある「Working Backwards」です。
これは、「まず顧客の体験から始まり、そこから逆算して製品を作る」という思考プロセスを指します。

通常は技術や機能から考えがちですが、この手法では「顧客がどう幸せになるか」を最初に定義することを徹底します。

具体的なプロセス：5つの質問

企画を具体化する際、私たちはまず以下の質問に答えることから始めました。

1. お客様は誰ですか？（具体的なペルソナの設定）
2. お客様の抱える課題は明確ですか？（解決すべき問題の特定）
3. お客様が受けるメリットは明確ですか？（価値の定義）
4. お客様の体験が描けていますか？（具体的な利用シーンの想定）
5. お客様の悩みに対し、どのような解決策を提示しますか？

主要な3つの成果物

Amazonではプレゼン資料を使わず、以下のドキュメントを作成して文章ベースでレビューを行います。

• プレスリリース (PR)： 製品発売日に顧客が目にするニュースを想定し、その価値を1〜2ページに簡潔かつ魅力的に記述します。
• FAQ (よくある質問)： 顧客向けと内部向けの質問を想定し、内容を深掘りします。
• ビジュアル： ストーリーボード等で顧客体験を視覚化し、テキストの理解を補完します。

実際にハンズオンでプレスリリースを作成したところ、そのスピード感に圧倒されました。
進行が非常に早いため、顧客の状況へいかに「没入」して課題を深掘りできるかが重要だと実感しています。
この学びを活かして、開始から1か月ほどで本手法を取り入れた企画書を提出いたしました。

2. アジャイル・スクラム：変化への対応力を磨く

変化の激しい現代のビジネス環境に適応するための開発思想が「アジャイル（Agile＝俊敏な）開発」です。
小さな単位で「実装とテスト」を繰り返し、短期間でのリリースを積み重ねる特徴があります。

アジャイル宣言の精神

ワークショップでは、以下の4つの価値観を重視することを学びました。

プロセスやツールよりも「個人と対話」を重視。

包括的なドキュメントよりも「動くソフトウェア」を重視。

契約交渉よりも「顧客との協調」を重視。

計画に従うことよりも「変化への対応」を重視。

ビジネスの変化に即座に対応できるため、方針の誤りに早い段階で気づけるメリットがあります。 結果として、プロジェクトの失敗リスクを最小限に抑えられます。

スクラムの3つの柱

スクラムは、アジャイル開発の中でも最も普及しているフレームワークの一つです。 「経験主義」に基づき、以下の3つの柱を大切に運用します。

透明性 ： プロセスのあらゆる側面が、成果に責任を持つ人々に共有されていること。

検査 ： 制作物や進捗を定期的にチェックし、望ましくない変化がないか確認すること。

適応 ： 検査の結果、問題があればすぐにプロセスや内容を調整すること。

スクラムにおける役割

スクラムチームは通常10人以下の構成で、以下の役割を分担します。

• プロダクトオーナー (PO)： 何を作るかを決定する、製品価値の最大化責任者。
• スクラムマスター (SM)： スクラムの実践を助け、障害を取り除くコーチ。
• 開発者： どのように作るかを実行する専門家。

私は開発者の役割を担当し、POは経験者の方に務めていただきました。
「プロセスよりも個人と対話」を重視する精神を学び、柔軟な開発姿勢を身につけることができたと感じています。

3. モブプログラミング：知恵の共有と品質の向上

モブプログラミングは、「チーム全員が同じ時間、同じ場所で、同じ課題に、一つのコンピュータを使って取り組む」手法です。 「モブ（群衆）」という名の通り、全員の知恵を1点に集中させます。

基本の役割

モブプロでは役割を分けることで、議論の質を高めています。

ワークショップでは、実際に「ドライバー」を交代しながらデモを行いました。

モブプロがもたらすメリット

単なる多人数作業以上の効果があると感じました。

• リードタイムの圧倒的な短縮： その場で合意が取れるため、レビュー待ちの時間がなくなります。
• 知識の共有と平準化： 特定の人しか触れないコードがなくなり、チーム全体の教育コストが下がります。
• 品質の向上： 常に複数の目によるチェックが入るため、その場で最適な設計判断が下せます。

私は開発に取り組む段階で、2人体制のペアプログラミングを実施しました。
開発初心者であったため、経験者の知識を直接得られる体験は非常に貴重だったと感じています。

4. BizDevOps：ビジネスと現場の融合

BizDevOpsとは、開発（Dev）と運用（Ops）に、ビジネス（Biz）を加えた3者でIT推進を行う枠組みです。
組織が一体となって共通の目標に向かう運営が重視されています。
BizDevOpsはANGELDojoでの内製化のメインのような気がします。

なぜビジネス連携が必要なのか

ビジネスの目的を相互に理解することで、プロダクトの方向性を「素早く、正しく」決断できるようになります。
「なぜそれを作るのか」という理由（コンテキスト）が不明確なままでは、優れた製品は作れません。
開発者がビジネスの背景を理解していれば、UXデザインにおいても迷いなく最適な判断を下せます。

ソフトウェアの優位性とスピード

現代のビジネスでは、物理的な制約がないソフトウェアならではの特性を活かすことが不可欠です。
講義では、特に以下の3つのポイントが強調されていました。

• 作成と配布の加速： クラウドの発達により、製品を開発してから顧客に届けるまでのスピードは、かつてないほど高速化しています。
• 限界費用の低さ： ソフトウェアは複製コストが極めて低いため、規模の経済を活かして急速な成長（スケーラビリティ）を実現しやすい強みがあります。
• 俊敏性（アジャイル）： 絶え間ない顧客の要求に応えるには、スタートアップのようなスピード感が欠かせません。

BizDevOpsを支える3要素

この仕組みを実現するには、以下の要素を組織に取り入れる必要があります。

1. 文化 (Culture)： チーム間の壁を取り払い、責任をチーム全体で持つ。
2. 実践 (Practices)： アジャイル開発や継続的インテグレーション（CI/CD）を採用する。
3. 道具 (Tools)： 自動化ツールを活用し、迅速なリリースを可能にする。

現代のビジネスでは、ソフトウェアの配布スピードが重要です。
開発者がビジネスの背景を正しく理解していれば、UXデザインにおいても迷いなく最適な判断を下せます。
「なぜそれを作るのか」という理由をチーム全体で共有する大切さを、今回の講習で強く学びました。

5. AWS Well-Architected Framework：設計の健全性を確認

AWS Well-Architected Framework（以下、W-A）は、AWSが10年以上にわたり数多くのお客様を支援してきた経験から作り上げたベストプラクティス集です。
クラウド設計・運用の「大局的な」考え方を学ぶことができます。

W-Aを構成する「6本の柱」

W-Aは、以下の6つの評価基準に基づいてシステムを評価します。

1. 運用の優秀性: システムを動かし、モニタリングし、プロセスを継続的に改善する能力。
2. セキュリティ: データやシステムを保護し、クラウド技術を活用して安全性を高める能力。
3. 信頼性: 期待される機能を正しく実行する能力。障害からの回復や需要の変化への適応を含みます。
4. パフォーマンス効率: リソースを効率的に使用し、技術の変化に合わせてその効率を維持する能力。
5. コスト最適化: 不要な支出を避け、ビジネス価値を最大化するようにコストを管理する能力。
6. 持続可能性: クラウド運用の環境への影響を最小限に抑える能力。

レビュー（Well-Architected Review）の進め方

W-Aは監査ではなく、リスクを顕在化させて改善するための建設的な話し合いです。
ワークショップでは、以下のステップを体験しました。

• 関係者の招集: ビジネス、開発、運用の担当者が集まります。
• AWS Well-Architected Toolの活用: マネジメントコンソール上のツールで、定義された設問に回答します。
• 現状（As-Is）の把握: 「誰も責めない」雰囲気で現状を正直に分析します。
• 改善策の検討: 現状からリスクを特定し、理想の姿（To-Be）に向けた優先順位を決定します。
• 継続的な改善: 定期的に見直すことで、ノウハウを蓄積します。

4時間ほどかけて座学とディスカッションを行い、自分たちが開発中のサービスについて深く見直しました。
客観的な基準で現状を知ることで、今後の開発における指針が明確になったと感じています。

講習全体のまとめ

今回の講習を通じて、それぞれのワークショップで多くの気づきを得ることができました。

• Working Backwards: 「何ができるか」という自分中心の視点から、「顧客がどう幸せになるか」という利他中心の思考へ切り替える重要性を体感しました。
• アジャイル・スクラム: 短期間でのリリースを積み重ねることで、変化への柔軟性と開発の俊敏性が向上することを実感しました。
• モブプログラミング: チーム全員で知見を共有しながら設計を磨き上げることで、全体の技術レベルが底上げされる効果に驚きました。
• BizDevOps: ビジネスの背景を理解することが、開発における迷いをなくすと実感しました。
• AWS Well-Architected Framework: サービスを客観的に評価し、継続的に改善する手法を学びました。

紹介していないのですが 「プレゼンテーションノウハウ」や、「Solutions Architect によるライブアーキテクチャレビュー」といった講義も非常に印象的でした。

一連のプログラムを通じて、ANGEL Dojoには技術の習得以上に価値がある活動だと強く実感しました。
特に企画から実装まで、実務のフェーズに即して段階的に学べる構成により、深い理解を得られたと確信しています。
チームで協力し、変化を恐れずに価値を創造していく姿勢を、これからも大切にしていきたいです。

今後、ANGEL Dojoに参加を検討している方にとっても、ここで得られる経験は大きな財産になるに違いありません。
最後までお読みいただき、ありがとうございました！