1. はじめに
1.1. 自己紹介
こんにちは、NTTドコモ 第一プロダクトデザイン部の李、安立、木村、第二プロダクトデザイン部の吉田、サービスイノベーション部の千歩です！
普段の業務では、toC向けサービスのシステム基盤構築（李、安立、木村、吉田）や社内エンジニア支援（千歩）を担当しています。
1.2. 本記事のテーマと、読んでほしい人
本記事では、私たちが参加してきたANGEL Dojoの体験記について紹介します。
ANGEL Dojoを知りたい、何を学ぶことができたかが気になる方や、内製化に興味がある方はぜひ読んでいただきたいです。 また開発編については、開発編の記事で深ぼって紹介するため、お楽しみにお待ちください！
2. ANGEL Dojoとは
「AWSで日本を元気に！」がテーマの3ヶ月間のハッカソン型トレーニングです。 3ヶ月毎週木曜日と金曜日を使い、Amazon流のモノづくりの手法を学び、自らが考えたアイデアを具体的に動かすまでを体験します。
今年のテーマは内製化の「はじめの一歩」を踏み出しませんかでした。 今年度の開催の目的は、ユーザー企業の実課題を元にモノづくりを体験することで、ユーザー企業が内製化を進める基盤を作ることでした。 そのため、今年は、下記のような課題を持っている企業におすすめされていました。（※来年度の開催状況やテーマによっては異なる場合がございます。）
- 内製化をはじめたいが、どこから手をつけると良いか分からない
- 課題は社内にあるが、開発できるエンジニアがいないので、すぐに作り始められない
- 経営層は内製化をしたいが、現場エンジニアのスキルが追いついていない
- 内製化にチャレンジしてみたが、継続した運用が困難である
課題に対するアプローチとして、最初のチーム構成からサポートしてもらうことができます。 具体的には、AWSのユーザー企業とパートナー企業の混合チーム（1チーム8名前後）で構成され、内製化の手の付け方、スキルサポートをいただくことができます。
3. 活動内容を紹介する前に
活動内容を読み進めるための事前情報として、参加のきっかけやチーム構成、それらを踏まえて作ったシステムの紹介をします。
3.1 参加するきっかけ
私たちは今回、社内の周知を見てANGEL Dojoに参加しました。私たち全員、元々内製開発やAWSを活用したプロダクト開発に興味があり、貴重な機会だと思い、手を挙げました。
参加を決意する前は、週二日の稼働を使うことや、業務でプログラミングをしていないという不安を抱えていました。 しかし、内製化をする力をつけ、ドコモサービスを良くしていきたいという強い想いが、不安を勝って参加につながりました。
3.2. 自分たちのチーム構成
今回はユーザー企業とパートナー企業の混合チームで参加ということもあり、ドコモの5名に加え、AWSのパートナー企業であるデロイトトーマツウェブ株式会社から2名の計7名で構成されたチームでした。
写真？
3.3. 作成したシステム
私たちは入稿物の自動審査ツール「mody」 を作成しました。
modyは、掲載する広告が景品表示法や社内ルールを満たしているかをAIで自動審査するシステムです。 手作業で行っていた審査を自動化することで、業務効率化を図れます。
審査したい項目の一覧は下図のようなダッシュボードで管理できます。
下図は審査結果の一例です。画像内の修正が必要な箇所を特定し、どのルールに違反していたかも表示できます。（テキストの審査も可能です。）
4. 活動内容
modyを作り上げるまでの活動をこれから紹介していきます。
4.1. チームビルディング
「宣言」によるコミットメント
活動開始に先立ち、参加者である私たちは「宣言シート」を作成しました。 作成する目的は、3ヶ月後の自分がどうなっていたいか（Be）、そのために何をするか（Do）を明文化することです。 この宣言により、受け身の研修ではなく、自らが主役となる「Ownership」のマインドセットを持つことができました。 また、この宣言自体はアジャイル開発におけるインセプションデッキに近いものを感じました。
私たちのチーム宣言
- 目標達成に向けて自分自身が行動しなければならないことを意識します。
- 課題解決や目標達成に向けチームのために主体的・積極的に取り組みます。
- 疑問や要望はそのままにせず、チームメンバーとメンターに都度相談し、解決します。
- 成果はチームメンバーとメンターと喜んで分かち合います。
- あだ名で呼び合い、chatやwebMTGで気軽に発言できる環境を作ります。
- 動くものを作ることを第一に考え、困難に立ち向かい、妥協しません。
4.2. 企画
Amazon流「Working Backwards」の徹底
最初の1ヶ月は、Amazonのプロダクト開発の根幹である「Working Backwards（お客様から逆算して考える）」手法を徹底的に学びました。 開発に入る前、私たちはまず以下のWorking Backwardsの「5つの質問」に答えることから始め、お客様（開発物を利用する人）を常に意識するようになりました。
- 対象となるお客様は誰か？
- お客様が抱える課題や機会は何か？
- もっとも重要な顧客体験（ベネフィット）は何か？
- その解決策はどのように機能するのか？
- お客様はどのように解決策を知り、利用するのか？
これらを曖昧にせず、具体的なペルソナを設定し、その人がどのような状況でどのようなペイン（痛み）を抱えているのかを、チーム全員が共感できるレベルまで深掘りしました。 さらに重要視したのは、これから作成するサービスが「真に顧客課題の解決に結びつくか」という点です。 「3ヶ月間の稼働を使いながらチームで開発を行うのであれば、それを実際にユーザに使ってもらって喜んでもらいたい。」そんな思いがあったため、 Working Backwardsの2~4の質問に向き合いながら、顧客課題の解決にこだわりながら案を絞り込んでいきました。
プレスリリースとFAQ（PR/FAQ）の作成
次は、すぐに仕様書を作成せず、プレスリリースとFAQを作成しました。システムが完成し、サービスとして世に出た時、お客様がどう感じるかを先に文章化します。
- プレスリリース： 専門用語を使わず、顧客が得られる価値をシンプルに伝える。
- FAQ： 顧客からの質問（外部向け）だけでなく、社内ステークホルダーからの厳しい質問（内部向け）も想定して回答を用意する。
プレスリリースやFAQの作成を通じて、チームメンバ全員がサービスに関する「問いを立てて答える」プロセスを反復し、チーム全体でプロダクトの課題、解決方法、実装上の制約などのイメージを共有できました。 これによりメンバー全員がフロントエンド、バックエンドの垣根を超えてあるべき姿や改善点について議論することができ、サービスの品質向上に大いに役立ったと感じています。
さらにプレスリリースの中では、現実的にDojoの期間内で主要機能を完全に実装可能な見込みのある案を重視しました。 将来の拡張性は色々検討できるがコンセプト止まりになって開発が終了する、そんな望まない未来をできるだけ回避して顧客課題の解決に繋げるためにそのような考え方で案を絞りました。
上記を踏まえて、作ることになったシステムがmodyです。
4.4. 開発
アーキテクチャなど技術的な説明はAdvent Calendar 23日目で公開しますので、そちらを読んでいただけると嬉しいです！
本記事では、開発手順の概要を紹介します。
- Amazon Q Developerを使い、modyの画面遷移を作成することで、意識合わせ
- フロントエンドチーム（3名）とバックエンドチーム（4名）の決定
- Backlogでチケットを起票し、タスクの可視化および担当者の割り当て
- 朝と夕方に進捗報告を実施しながら、開発を進める
4.5. 中間発表・最終発表
開発したシステムは、中間発表と最終発表の場で披露する機会がありました。 ここでは「作ったものを説明する」だけでなく、「その価値を聴衆に伝え、共感を得る」ためのプレゼンテーションスキルが問われました。 必要となったプレゼンテーションスキルは、ANGEL Dojo内の講義「プレゼンテーションセミナー」で、下記のようなスキルを学びました。
- プレゼンテーションは聞き手に変化をもたらす手段という意識
- わかりやすく伝えるためのポイント
- スライド（資料）の作り方
私たちの発表では、単なる機能説明に終始せず、「誰のどんな課題を解決し、どのような未来をもたらすのか」というストーリーを語ることに注力しました。
結果は、、、
私たちのチームでは以下のような結果になりました！
- 中間発表・・・総合2位
- 最終発表・・・技術賞1位
いずれの結果発表時、メンバー全員が嬉しくて笑顔になっていました。 （他のチームもレベルが高く、尊敬できる点が多かったため、受賞できるか不安になっていたこともありました。）
評価軸については、ビジネス面と技術面が定められていました。そのため、ただ開発すれば良いわけではなく、ビジネスを考える必要性が自然と意識づけられました。
さらに、最終発表でビジネス面と技術面の上位2チームに入賞すると、頂上決戦に進出することができました。 頂上決戦では、最優秀賞が決定し、その様子はYouTubeで中継されていました。
4.6. 頂上決戦
最終発表から頂上決戦まで約2週間程度しかありませんでした。 私たちはさらに運用を意識して負荷試験やテストの自動化などこれから運用していくにあたって必要な項目を充足させて挑みました。
残念ながら最優秀賞には選ばれませんでしたが、他のチームの発表も大変すばらしく、まさに「AWSで日本を元気に！」が体現されていました。 以下からアーカイブが視聴できますので是非見てみてください。
頂上決戦の様子はこちら
5. 振り返りと学び
振り返り
宣言シートの宣言内容をもとに、3ヶ月間を振り返っていこうと思います。
まず言えることとしては、メンバー全員がチーム宣言を達成していました！
証明は難しいですが、例えばソースコードのコミット数が889回、デプロイが144回と積極的に開発を進め、ミーティングでの会話文字数が218万文字と対話を重ねたことから、主体的に取り組んでいたと考えられます。（1時間2万文字と仮定すると、100時間以上議論を重ねたことになります）。
学び
ANGEL Dojoを通して、内製化とは「外部に頼らないこと」ではなく、「自社ビジネスのコアとなる部分にオーナーシップを持ち、テクノロジーを使って迅速に課題を解決できる組織能力」のことだと学びました。
さらに、以下のような、内製化を実現するために必要なことを学ぶことができました。
- Working Backwardsによるお客様を意識すること
- チーム開発を進めるために、自分の考えを持って議論し合うこと
- 価値提供をするために開発速度を上げる方法
- 生成AIの活用方法（技術編で紹介）
6. これから
このサービスは、ANGEL Dojoが終わったあとも初期のペルソナであるチームとの検証が続いていますし、 ありがたいことに部長の方々からも評価をいただき、現在は導入検討サービスがどんどん広がっています。 まだまだ道の途中ですが、Working Backwardsの考えを使いながら「顧客課題の解決」にこだわることができたからこそ実現できた結果なのではないかと思っています。 ANGEL Dojoの参加はゴールではなく、スタートラインだと強く感じています。そのため、私たちの内製化への挑戦は、ここからが本番です。
