ANGEL Dojo を通して、若手エンジニアが学んだこととは ?

多くの人が、休日を有意義に過ごしたいと思っているはずです。
しかし、いざ土曜日になると、何をすればよいのか分からず、気がつくと何もせずに月曜日を迎えてしまった。そんな経験のある人も同じくらい多いのではないでしょうか。
その背景には、自分の興味が分からなかったり、計画を立てるのが難しいといった、様々な理由があると思われます。

具体的には、以下の 5 つの目玉機能で、利用者に充実した休日をお届けします。

1. 利用者の特徴 (年齢・性別・居住地・車の有無など) に応じて、おすすめのお出かけスポットを AI が提案してくれる。
2. ユーザーは提案されたスポットを自由に組み合わせて、休日プランを作成できる。
3. 作成した休日プランが「旅のしおり」となり、お出かけの際の便利なガイドブックになる。
4. お出かけ中、各スポットでは「写真をとる」「感想を書く」などの簡単なミッションを実行し、しおりに保存していくことができる。
5. お出かけのあと、「思い出レポート」が自動で生成され、ミッションの内容とともに休日の思い出を振り返ることができる。

StanBee では、AWS の様々なサービスを活用し、クラウドネイティブな構成を採用しています。 これによって、高度な機能を簡単に実装できたと同時に、開発・運用も行いやすいシステムを作ることができました。

開発・運用・機能の 3 つの視点から、アーキテクチャを簡単に説明いたします。

ANGEL Dojo の 3 ヶ月間を通して、特に印象的だったことを 4 つの切り口から紹介していきます。

6 月の企画フェーズでは、Amazon のイノベーティブな文化のひとつである「Working Backwards」という手法に基づいてプロダクトの企画を行いました。この手法がとても印象的でした。

「Working Backwards」とは、お客様を起点にプロダクトを企画する手法です。
Amazon では最初にプレスリリースと FAQ を書き、顧客の体験や提供価値を明らかにしたうえで企画の詳細を深めていく文化があると教わりました。

私は、事業企画の部署に所属をしていることもあり、事業企画書の作成に携わったことはあります。 時間をかけて、多くのステークホルダーの意見を汲み取りながら作り上げる大きな企画書は、組織の理解や投資判断を得るためには必要なものです。

しかし、そのようにしてできあがる企画書が、構想当初にお客様へ提供をしたかった「本来の価値やソリューション」とは異なるものになってしまったこともあったかと感じています。 

だからこそ、最初にプレスリリースを書いて、顧客への提供価値を明らかにする「Working Backwards」の手法は、企画や開発が進んでいく中でも、守るべきところと変えてもいいところの区別がわかる「基準点」になると感じました。

実際、私たちが開発フェーズで作業をしている時、機能の洗い出しや優先度の決定で迷ったことがありました。

その際はプレスリリースを見直して、プロダクトの価値についての認識をメンバー内で合わせることで、開発の方針をブレずに決めていくことができました。

7 月 8 月の開発フェーズでは、スクラムのプラクティスに従い、1 週間を 1 スプリントとしてプロダクトの開発を進めていきました。

以前からアジャイル開発に興味があったものの、これまでの業務では携わる機会がなかったため、Dojo を通してスクラムを経験できたことはとても大きな学びになりました。

スクラムに取り組んでみて何よりも驚いたことは、プロダクトだけではなく、チームとしての「高度化」も目指しているところでした。

スプリントごとにレトロスペクティブ (振り返り) を行い、課題や学びの共有、そして次のスプリントでの改善事項を明らかにします。

この作業を通して、自分やチームが確実に成長をしているという感覚が得られました。また、さらに上のレベルを目指そうというモチベーションにもつながりました。

他に、ペアプログラミングを実施して互いの知識を共有するなど「ノウハウの共有」をメンバー間で行いながら開発作業を進められたことも良かったです。リモート環境におけるコミュニケーションにつながった他、メンバーのスキルセットが分かり、作業分担の参考にもなりました。

メンバー間で助け合いをしながら、プロダクトとチームにしっかりと向かいあって作業を進めることができた今回の経験は、「良いチームづくり」という視点でも貴重な経験になりました。

新型コロナウイルス感染症拡大の影響もあり、ANGEL Dojo の取り組みはすべてリモート形式での実施となりました。

私たちのチームは 6 名全員が異なる会社に所属をしていたこともあり、互いに協力をしながら進めていくことができるのか、当初は不安に感じる部分がありました。
しかし、Dojo が始まってからは全く問題ありませんでした。 

これは、

1. メンバー間で積極的にコミュニケーションをとった
2. メンバー間で「優勝したい」という想いを共有した

という 2 点が大きかったと思います。

1 つ目の「コミュニケーション」という観点では、金曜日のワークデイの他にも 1 週間に 2 回はリモートでミーティングを行いました。コミュニケーションの回数が純粋に増えたことはもちろん、進捗報告と振り返り (= レトロスペクティブ) をミーティング時に実施したことで、各メンバーの困っていることなどをチームメンバーで共有することができました。
困っているメンバーがいた際には、Cloud9  (オンラインIDE) のペアプログラミング機能を用いて、コーディングのサポートを共同で行ったりしました。そのような取り組みによって、メンバー間の信頼関係を深めていくことができたと感じています。

また、2 つ目の「想いの共有」という観点では、優勝という共通目標をメンバー間で持てたことが効果的でした。同じ目標を持つことで、プロダクトのクオリティーについても認識をあわせやすく、「チームのために頑張れる」という効果もありました。
例えば、私たちのチームでは毎週金曜日のワークデイだけでは作業が終わらず、休日や平日夜の作業も当たり前でした。(※業務工数は割いておりません)
日中は業務があるため、業後の Dojo の作業を重たく感じることも正直ありました。しかし、優勝を目標に頑張っているチームメンバーのことを思うと、私も頑張らなくてはいけないなと自然とエネルギーが出てきます。
チームメンバーのことを想い、時には徹夜で開発作業に取り組んだことは、社会人になってからは忘れていた「楽しさ」がありました。

一般的には、リモートワークだとコミュニケーションが取りにくいと言われています。
しかし、私たちはリモート会議ツールやオンライン IDE を活用することで積極的にコミュニケーションをとり、また共通の目標を持つことでプロダクトに対する Ownership も高めることができました。
それが、一度も対面で会ったことがないメンバーを信頼しあえる「良いチーム」を作ることができた理由だと感じています。

AWS の方々を持ち上げているわけではありません。
ANGEL Dojo を通してお世話になった AWS の方々の、その真摯な姿勢がとても印象的でした。

何か技術的な質問をすればすぐに的確な回答をいただけ、資料のミスを指摘するとすぐに修正してくださいました。 金曜日のワークデイ の後には毎回必ずアンケートがあり、何かコメントを書くと次の回にはすぐに対応していただきました。 3 ヶ月間にわたって、これでもかというくらいに丁寧な準備と対応をしてくれた AWS の方々の姿勢に、私はとても心を打たれました。

ANGEL Dojo のキックオフの際、Amazon の企業理念と OLP (≒リーダーとしての心得) というものを教わりました。
Amazon の企業理念は、「地球上で最もお客様を大切にする企業」であり、
OLP (Our Leadership Principles) としては、"Ownership" や "Deliver results" などの考え方を大切にしていると説明がありました。

最初、この企業理念を聞いた際 「お客様第一主義はどこの企業でも言っていることだな」と考え、あまり真面目にとらえていませんでした。しかし、Dojo を通して多くの AWS 社員の方々と関わる中で、言葉だけではなく、本当にお客様を大切にする姿勢に様々なところで触れる機会がありました。 実際、私はDojo の期間中、日々「大切にされている」感覚を受け、とても幸せな気分になりました。 また、それが当然であるかのように働く AWS の方々の姿は、社会人として憧れるものがありました。

日々の仕事にまっすぐと向き合い、お客様を幸せにする。
私も、そのような誠実な社会人の姿でありたいと、改めて強く思う機会になりました。

約 3 ヶ月間のサービス開発を通して、自分なりに想ったことが 1 つありました。
それは、「DX (デジタルトランスフォーメーション) 時代のサービス開発では、顧客に素早く価値を届けるマインドと、それに向けたプロセスの変革が大切である」ということです。

「そんなの当たり前だ」と怒られるかもしれません。もしくは「それは違う」とも怒られるかもしれません。 しかし、私はこう考えることで DX やサービス開発に対するハードルが下がり、「自分でも DX に貢献できそうだ」という自信や希望を持つことができるようになりました。

私は、会社の中で DX を推進する部署に所属をし、新規事業の企画などに携わってきました。
しかし、「DX とは何か」「事業企画で大切なことは何か」という問いに、今まではしっかりと答えることができなかったように思います。

DX という言葉はあいまいで、捉え方は人の数だけ存在します。
世間一般では、IT 技術を活用した新規事業の創出などが DX と言われているようで、私もそういうものだと以前は考えていました。

しかし、新規事業の創出を DX とした場合、それは実現がとても難しいものになってしまいます。
ビジネスやマーケティングに関する高度な知識はもちろんのこと、成功には運の要素も大きく関わってきます。
誰もが解法を知らない事業創出という取り組みにおいて、入社 3 年目の私に何ができるのだろうかと、もどかしくも感じていました。

ANGEL Dojo でのサービス開発を経験した今の私は、そんな昔の自分に対してこそ、「大切なのはマインドとプロセスの変革である」と今の考えを伝えたいです。

ANGEL Dojo では、Working Backwards な手法で企画を作り、スクラムのプラクティスに沿った開発をしてきました。 また、 AWS の方々やチームメンバーの Ownership あふれる姿勢を近くで見てきました。 それは、「顧客にしっかりと向きあう、素早く作って喜ばせる」という当たり前の『マインド』と、それを実現するための『プロセスやツール』の大切さを身に染みて理解するきっかけになりました。

当たり前のことではありますが、その謙虚で地道な取り組みの先にこそ、「成功する事業の創出」といった果実が生まれてくるのだと思います。

「顧客志向のマインドと、柔軟なプロセスへの変革が大切である」と捉えると、難しく感じていた DX や新規事業の企画も、手が届く取り組みのように思えてきます。 実際、そういった「マインドとプロセスの変革」という試みは、日々の仕事の中でも様々なアプローチがとれるはずです。

私自身の場合は、Dojo を通して経験した様々なプラクティスを周囲に展開することで、組織における「マインドとプロセスの変革」 に自分なりの方法で貢献できるなと思うようになりました。

ANGEL Dojo を終えた今、この 3 ヶ月間で学んだことを所属組織に還元していくことが、私の義務だと感じています。 

運が良いことに、私は DX を推進する部署に所属をしています。
会社が従来型の SI モデルから新しいビジネスモデルを創ろうとしている中、私の ANGEL Dojo での経験や知見が少しでもヒントになって、会社の DX に貢献できればと思っています。

そんな姿を理想に、Dojo の終了後、社内において以下の取り組みを行っています。

私の取り組みが、組織における「マインドとプロセスの変革」の 1 つのヒントになってくれたら嬉しく思います。

ANGEL Dojo で得た AWS についての知見を、実際の案件で直接活用できた嬉しい機会もありました。 

某不動産事業者との案件にて、スマホアプリの PoC を実行することになり、そのデモの開発を私に任せてもらいました。 要件を整理すると、ネイティブなスマホアプリである必要はなく、LINE Bot を用いた構成で素早く実現することにしました。 

ANGEL Dojo でサーバーレスの知見を深めていたこともあり、約 1 週間で AWS 上にシステムを構築。お客様企業に喜んでいただけたことはもちろん、Dojo で得た知見を日々の業務でも活用できたことは、とても嬉しい経験になりました。 

これからも、ANGEL Dojo での経験を、業務の様々なところで活用していきたいと思っています。

• AWS 公式のレポート記事はこちら。
  ANGEL Dojo Season2、全日程終了しました !! | AWS JAPAN APN ブログ
• 開発をしたプロダクト 「StanBee」は Web にて公開をしておりましたが、Dojo の終了とチームの解散に伴い、2020 年 11 月末をもってサービスを停止いたしました。たくさんのご愛顧をありがとうございました。
• 本記事の記載内容は個人としての見解であり、所属組織を代表したものではありません。