はじめに

私は、働く人が働きやすく、企業は働きやすいから人が育ち、より良いサービスを提供できるから多くの人が喜べる。と考えております。
このサイクルで大きな一助になれるのは、エンジニアの力。企業発展や働く人がより輝けるWEBサービスを提供できるエンジニアを目指し、1年ほど前から独学を始め、現在はAPPRENTICE3期生として学ばせていただいております。
APPRENTICEのカリキュラムで2回目のチーム開発があり、今回の貴重な経験をまとめました。
メンターの方から振り返りは、経験をスキルにする事を意識してまとめていくことが大切とお言葉をいただきました。今回の経験の成功体験を再現性のある経験にできればスキルになる。
そのためには、なぜ成功につなげることができたのかを言語化することが大切ということで、しっかりと意識してまとめていこうと思います。

簡単に自己紹介

私は管理職を経験したく、アパレルが好きだったため、アパレルの世界規模の組織化された企業で店長を経験。
管理職の楽しさを痛感し、さらに視野を広げて経営の根幹に関わりたいという思いで、2社のベンチャー企業で経営企画や人事を経験しました。
この経験から、業務効率や人材育成につながるWEBサービスを作りたいと現在にいたります。

今回のチーム開発で良かったと感じた事

開発期間中に悲しく、不本意な対応が必要となったが、プレゼンまでにプロダクトを目標水準の開発をする事ができました。
結果として、Best Student Awardを受賞させていただきました。
なぜこのような結果にできたのかを、順を追って振り返っていきます。

チーム方針

コミュニケーションを大切に

チーム開発という貴重な体験を、より充実させるための発言は無理のない範囲で行う
チームとしては、意見を尊重して可能な限り取り入れられる形やインセプションデッキを元に判断をしていく
もくもく会を実施する
開発に伴う技術力の向上や、お互いの事を知りコミュニケーションをしやすい環境を作る。

チームとしての指針となるインセプションデッキの作成
このインセプションデッキによって、3人の意見をまとめたり、方向性の確認やチームの決定をする時に大きな後ろ盾となってくれました。
コミュニケーションを取りやすく、相手の考えを理解しやすくするためにNotionをツールとして取り入れました
要件定義からテーブル定義まですべての考察をチームメンバーそれぞれが考え、まとめたものをいつでも確認することができるように利用しました。
こうすることで、どういう経緯で取り入れたんだっけ？やなぜこれを重要視していたんだ？というときにとても有効でした。また全員が考えを言語化していたため、Notionをベースに案をプレゼンしていくので最初の理解にも非常に有効でした。

開発テーマ

カリキュラムで定められたテーマは、主に２つ。

ワクワクする！楽しそう！使ってみたい！そう思わせる魅力のあるプロダクト
書きたくなる日報システムを開発せよ

この２つのお題から私たちのチームでは、課題解決を実現するプロダクト開発をやりたいという事で、書きたくなる日報システムをテーマに選択しました。

開発プロダクトの決定

日報が継続できない課題として、日報のメリットが見えてこない、カリキュラムと日報投稿のツールが分離されているため投稿が手間、日報自体がめんどくさいと仮説を立てました。
この課題を解決するためには、

カリキュラムと日報投稿のツールの行き来をなくす
日報投稿を学習進度として反映させて、学習進度を可視化することでモチベーションにつなげる
日報の優位性を提示できる
日報を振り返ることで、学習時の成功体験や改善事項がわかりやすくなり、行動の質向上つなげられるなど日報の優位性を体験できる

チームとして解決案を明確にし、私のアイデアとして以下のように考えました
APPRENTICEのカリキュラムがエンジニアの必須要素と行動が明示されていたので、マンダラチャート化できるという視点を持ちました。
マンダラチャートは目標達成に必要な要素を整理、明確化して、行動を具体化できるというツール？です。ここに日報という行動の履歴や実行結果を取り組むことができれば、より強いツールになると考えました。
そしてマンダラチャートの遂行度を明確化できれば、モチベーションにもつなげられ、日報を楽しめるツールにする。そうすれば解決案を実現できるのではないかとまとめました。
そして、チームに提案したところアイデアとして採用され、ここからプロダクトの要件定義や設計など詳細を決めていきました。

開発中に起きたメンバーの離脱

チーム開発のアイデア出しから、開発期間に入るまでの間、チームメンバー3人でより良いプロダクト開発がしたいという思いで意見を出し合い、実装期間までを過ごしました。
3人ともインセプションデッキをもとに、それぞれの視点で意見をまとめ、プロダクトの内容をかためていきました。全員が基本的な指針を明確にした上で考察を進めていたため、同じ方向性の中で、それぞれの視点から見て必要だと気付かせてもらえることが多く、チーム開発の優位性を活かせていたと思いました。
それができていたからこそ絶対にこのプロダクトを成功させたいという気持ちも強くなっていきました。
そして、実装期間へ。
実装期間に入って3日目、1人のチームメンバーの体調不良による離脱になってしまいました。
なんとかチームに残れるすべがないかと考えましたが、なによりもご本人の意思を尊重し、チームからの離脱が決まりました。3人で考えたプロダクトだったので、必ず形にしたいと決意しました。

プロダクト完成基準の見直し

限られた時間の中で残されたタスクとプロダクトの構成について2人で話し合いました。
その時にもすぐに対応することができました。
それはインセプションデッキを作成し、要件定義から設計までを通じて、チームとしてコアを明確にしていました。コアを支える機能がどこなのかも明確になっていたため、タスクの優先順位もおのずと決まってきます。
こういった基準があったので、見直しとタスクの振り直し、対応策までをすぐに決める事が出来ました。

2人でも開発

その後も開発状況を常に共有し合いながら実装を進めました。コミュニケーションを常にとっているからこそ、DBの扱いやエンドポイント、お互いに影響ができる範囲の開発に関してもぶつかることがありませんでした。
お互いの状況を理解しているからこそ、スムーズな開発ができ、手戻りなども発生しなかったため、本当に良かったです。当日までには、基本的なコア機能の目処がたっている状況で迎えることができました。
そして無事プレゼンを終え、受賞することまでできた経験は本当にうれしく覚えています。

まとめ

今回のチーム開発では、非常に貴重な経験をさせていただきました。
チーム開発を進める上で、インセプションデッキのような一本明確な方針をチームで持てていて良かったです。意見を出し合う、議論する、アイデアとしてまとめる、すべてのときにこの基準や方針があることで常に建設的に進めることができました。
そして、この基準があることによるコミュニケーションもしやすかったと感じています。利己的な考え方が入りにくく、チームとしての思考は強くなる、しかしチーム開発なので一人一人の異なる視点からの意見を入れられるためプロダクトとしては強固なものになっていくと感じました。
また発言することも方針を理解しているからこそしやすくなり、コミュニケーションの促進にもつながっていたのかと感じました。そしてプロダクトのコアについてもチームで共通認識となり、イレギュラーな対応にも優先度の高いタスクを明確かして進捗管理をすることができました。

受賞の瞬間を3人で迎えることができなかったですが、時間が経ったときに3人で考えたプロダクトが受賞したよという話ができる結果に結びつけることができて良かったです。

日記のような内容になってしまいましたが、チーム開発として非常に大きな学びを得られることができました。
この内容が次のApprentice生や学習を始められている方の一助になれば幸いです。