目次
はじめに
上司から「ANGEL Dojoというのがあるんだけど、参加してみる?」と話を聞いたのをきっかけに、アマゾンウェブサービスジャパン株式会社様(以下、AWSJ様)企画の疑似プロジェクト「ANGEL Dojo」に約3カ月間取り組みました。
結果的には、いくつか賞がある中、ANGEL賞で2位をいただくことができました!
今回はその「ANGEL Dojo」がどんな取り組みだったのか、学んだことを中心にご紹介したいと思います。
ANGEL Dojoとは
先述の通り、ANGEL(APN Next Generation Engineer Leaders)Dojoは、「日本を元気にする」という趣旨のもと、AWSJ様が企画した疑似プロジェクトです。
(以下、「日本を元気にする」APN Next Generation Engineer Leaders(ANGEL) Dojo のご紹介より引用)
ANGEL Dojoでは次世代を担うAPNの若手のエンジニアの方々に、擬似プロジェクトを通じてアジャイル、DevOps、モダンなアプリケーション開発などのクラウドネイティブな手法と、
様々なInnovationを作ってきたAmazonの文化と考え方を体験いただくことで、お客様にクラウドの価値を100%届けるための基礎的なスキルを実践を通して身につけていただきます。
参加者の皆様はここで培ったスキルと、各パートナーの皆様がお持ちのそれぞれの強みを活かすことでお客様のビジネスを成功に導き、日本のITや経済をさらに成長させる主役、
すなわち「APN Next Generation Engineer Leader」になっていただきます。
参加するためには、IT経験1-3年以内、毎週金曜日の1日ワークDayは毎回参加必須など、いくつか条件がありますが、約3カ月間(2020年1月~3月中旬)、1チーム5人で、疑似プロジェクトの企画から実装までを実践していきます。
※APN:AWS Partner Network
また、平日には週2、3回程度、AWSの各サービスの紹介や設計時の考え方、また、AWSに限らず一般的なGitの使い方といった幅広い分野の講義やトレーニングもあります。
その他、各チームにはPSA(パートナー ソリューション アーキテクト)が1名、メンターとしてサポートについていただけたり、$500のAWSクレジットの支援もあるなど、困ったときに相談、活用できる環境も整備されていました。
詳細は以下を見てみてください。
「日本を元気にする」APN Next Generation Engineer Leaders(ANGEL) Dojo のご紹介
スケジュールと当社体制
当社では、新入社員4名、3年目1名の計5名と、社内メンターとして2名がサポートにつく体制をとり、以下のようなスケジュールで進めていきました。
全体スケジュール
事前キックオフの際にAWSJ様より公開されていたスケジュールです。(黒字部分)
企画フェーズが短期間、そして初めての取り組みということもあり、当社では昨年末から動き始めていました。(赤字部分)
チームビルディング :2019/12/19 ~ 2019/12/26
企画フェーズ :2020/01/06 ~ 2020/01/17
企画フィードバック :2020/01/20 ~ 2020/01/23
実装フェーズ :2020/01/24 ~ 2020/03/05
発表会 / 表彰 :2020/03/06
※AWS Partner Summit Tokyo: 2020/03/19
新型コロナウイルスの影響で2020/03/25にオンライン開催
1週間スケジュール
金曜日のワークdayだけでは、作業時間が少ないことが想定されたため、もう1日、ワークdayを追加し、1週間単位で開発をしてました。
ただ、実際には2日間作業日があっても足りないくらいのボリュームだったので、Best Effortの日も作業を行うことが多かったです。
1日の振り返りは、YWT(Y:やったこと・良かったこと、W:分かったこと、T:次やること)という振り返りの手法を採用しました。個人的に、日ごとであればKPT(Keep/Problem/Try)よりもYWTの方が振り返りしやすいと感じました。
CoreDay | Remote | Best Effort |
月 | 火 | 水 | 木 | 金 | |
---|---|---|---|---|---|
午前 | 以下を2hで行う ・前週の振り返り (KPT) ・今週1週間の計画 |
tdi ワークDay |
AWS ワークDay |
||
午後 | 1日の振り返り (YWT) |
1日の振り返り (YWT) |
1日の振り返り (YWT) |
1日の振り返り (YWT) |
1日の振り返り (YWT) |
業後 | 講義など |
顧客起点で考える方法――企画フェーズ
それでは本題に入っていきたいと思います。
個人的に今回のANGEL Dojoで一番考えさせられ、学びが多かったのがこのフェーズです。1から企画をすること自体、ほぼ初めてだったので、非常に時間もかかり大変でした。
みなさんも「いつの間にか自分が作りたいものになっていて、ユーザが欲しているものとは違った」といった経験があるかもしれませんが、このようなギャップを極力なくすためにも、実装前から「顧客起点で考える」というのがとても大事になってきます。
そこで今回は、企画を考えるときに用いられる手法の中で『顧客起点で考える』ことを大事にした「デザインシンキング」と「Working Backwards」という2つの手法を参考にしました。
各手法についてざっくりとですがご紹介します。
手法例1:デザインシンキング
まずは、このデザインシンキングで、テーマの絞り込みと顧客の潜在的なニーズの洗い出しを行いました。
進めていく中で、アイデアが膨らみすぎて脱線してしまったり、定義が曖昧で優先順位付けの際にばらつきが生じず、1つのテーマに絞り込めないという問題もありました。
これに対しては、アイデアを出す際のルール設定や、出たアイデアを何かしら観点を決めてさらに分類するなどし、最終的に「人見知り軽減を支援する」というテーマに決まりました。
tdiチームでやったデザインシンキングのプロセス例
プロセス概要 | |
---|---|
1 | 顧客目線で誰の何を解決したいかを各自で大まかに考え、共有 |
2 | 1人の人間(ペルソナ)を設定し、その人に関する詳細な情報を想像しながらアイデアを出していく |
3 | ペルソナの発言や感情などをいくつかの観点で想像し、さらに肉付けしていく |
4 | 考えるスパン(1日、1週間等)を決め、場面ごとに上記で出たアイデアを分類していく 重要だと思った事象に印をつけ、顧客の潜在的なニーズを見つける |
5 | 顧客の体験がどのように変わっていくのか、 「誰が」、「どのようにして」、「何ができるようになるのか」の観点で洗い出していく ここでは実現可能性は深く考えずに数を多く出す |
6 | 5.で出たアイデアを顧客の感動度合い、実現可能性から評価し、優先順位を決める |
手法例2:Working Backwards
Working BackwardsはANGEL Dojoのワークdayの際に学んだ考え方で、逆向き解決法とも言われているようです。開発時にありがちな、「機能から考える」というのではなく、顧客起点に立ち最終的な目標から考えます。
Working Backwardsのプロセスは、顧客に対する下記の5つの問いかけから始まります。
顧客に対しての5つの問いかけ
-
- 対象となるお客様は誰ですか?
- お客様が抱える課題や改善点は明確ですか?
- お客様が受けるメリットは明確ですか?
- お客様のニーズやウォンツはどのように知りましたか?
- お客様の体験が描けていますか?
次のステップとしては、上記の問いかけで出たアイデアをもとに、プレスリリース(以下、PR)を書いていきます。PRは本来開発後に出すのが一般的だと思いますが、企画の段階で書くことで、考えが足りていない部分を可視化することができます。
また、「そのサービスってどうやって使うんですか?」「費用はどれくらいかかりますか?」など、PRに対する質問(顧客向け、社内向け)を想定し、それに対するFAQも作成しました。
初めてということもあり、PRを書く際はAmazonのなかで推奨されている下記のアウトラインを参考に作成しました。
PRを書く際のアウトライン
アウトライン | 概要 |
---|---|
Heading | 見出し:短く、説得力のある説明。(一番最後に書くのが良い) 一文でのサマリ:お客様が受け取る一番重要な価値を説明する 日付:リリース予定の日付 |
FIrst pararaph |
それが何であるかのサマリ |
SECOND Paragraph |
お客様の課題、もしくは改善点 |
Third paragraph |
課題解決のアプローチ、もしくはソリューション |
Fourth Paragraph |
必要に応じてAmazon(または自社)のリーダーの言葉 |
FIFTH Paragraph |
顧客体験の説明(使い方) |
Sixth paragraph |
お客様の声(想像で考える。ただし、具体的に顧客にどのように感じ、何を体験して欲しいかを考える) |
Seventh |
Call to Action(行動喚起) |
ここで重要なのは形式ではなく、しっかりと「顧客視点で考える」ことと「顧客の課題解決に対する根拠を明確にする」ことです。
自分たちで作成したものを何度かレビューしてもらったのですが、「それって本当に顧客の課題を改善できるの?」「技術的な制約の前に、顧客にとって必要なものは何かもう一度考え直してみて」と言ったご指摘をいただきました。
内容を確認してみて、PRに書いた人見知りの人が抱えている課題解決に対する根拠や、処理ができる音声ファイルの制限に関するFAQ等は、形式どおりに書くことを優先してしまい、全く顧客視点で考えられていなかったことが浮き彫りになりました。
顧客の真の課題の深掘りとそれに対するアプローチの根拠を明確にすること、また、実現が困難でも顧客にとってニーズやウォンツがあるのであれば、どう解決するかを考えることの大切さを改めて実感しました。
上記の部分が曖昧なまま後回しにしてしまうと、「これって何で必要なんだっけ?」「これが無いと解決できなくない?」など実装に入ってからも影響が出てくるので、押さえておきましょう。
実装フェーズ編へ続く
みなさんも何かを企画・実装する際に、「これはちゃんと顧客起点で考えられているか」ということを念頭に置き、自分自身や周りに問いかけてみていただけたらと思います。
大分長くなってしまったので、実際どういうものを実装したのかは実装フェーズ編でご紹介します。
執筆者プロフィール
- 配属後、ロボコン担当として、ETロボコン2017東京地区大会優勝・ITAロボコン2017優勝に貢献。現在は、AIチームの一員として、機械学習、ディープラーニングなどに挑戦しています。