こんにちは、 BOXIL 開発に携わっている、新卒エンジニアの高砂と申します！
私は今年の4月で社会人2年目になったのですが、ちょうどその前後、2月~5月にかけて「BOXILビジネステンプレート」というサイトのリニューアルプロジェクトを企画から開発まで主導していました。
本記事では、このプロジェクトの振り返りを通じて得た、新卒目線での学びについて紹介します。
やったこと
前述した通り、私は「BOXILビジネステンプレート」の企画と開発をほぼ一人で進めてきました。
普通だとそこまで任せる事はなかなか無いのですが、今回は下記の理由よりそのように進める事になりました。
- 開発をリードできる人材を増やしたい
- その為に、高砂に事業やユーザーの事を意識しながら企画・開発する経験をして欲しい
- 「BOXILビジネステンプレート」はリニューアルの規模感としては小さめなので任せやすい
これらを背景に本プロジェクトはスタートし、企画・開発を経て4月頃ローンチ完了、その後も企画・開発を続け、5月中で必要最低限の機能がそろった状況となりました。
KPTを用いた振り返り
プロジェクトとしては一区切り付いたので、ビジネス面やデザイン面でご協力頂いた方々と共に振り返りを行いました。
振り返りは「KPT」と呼ばれるフレームワークを用いました。KPTは「Keep（良かったこと）」「Problem（気になること）」「Try（次試すこと）」の頭文字から来ており、それらをベースに振り返りを行う手法です。
詳しくは下記記事で解説しているので、よければご覧ください。
その振り返りで実際に出てきたトピックは以下の通りでした。
Keep（良かったこと）
- エンジニア主導でプロジェクトを推進できた
- プレスリリースまでに炎上せずリリースできた
- 0からサイト構築する事で技術力が伸びた
- 企画からほぼ一人で進めたので企画チームのリソース的に助かった
- ユーザーインタビューや他社協業を自発的に進められて良かった
Problem（気になること）
- 誰がフォローやクオリティチェックをするかが不明瞭だった
- 全体への情報共有不足を感じられた
- 明確に事業としての目標数値を達成できた訳ではなかった
- 工数見積りの精度が低かった
- 期限短めのレビュー依頼やデザイン依頼が多かった
- いつまで本プロジェクトに取り組むかが不明瞭だった
Try（次試すこと）
これに関しては、前述のProblemの中で特に話し合いたい2トピックを議論する形式で洗い出しました。
誰がフォローやクオリティチェックをするかが不明瞭だった
- 関係者全員でチェックする時間を設ける
- 主導する若手がどこまでの責任や期待値を持っているかを、関係者全員に事前共有する
全体への情報共有不足を感じられた
- ミーティングでは、進捗だけでなく意図も共有する
- 誰がどこまでを誰に共有する、というラインを明確に設定しておく
振り返りを踏まえた理想体制
ここからはチームではなく個人で考えた事なのですが、今回のように若手に主導を任せるプロジェクトでは、下記のような体制で進めるのが良さそうだと結論付けました。
前提
- 体制の目的は2つ
- 小さめのプロジェクトを主に若手のリソースで進める（事業的観点）
- 若手にプロジェクト主導を経験をしてもらう（教育的観点）
方針
- 若手以外のリソースを大きく割かなくても進む
- 認識齟齬による手戻りが少ない
- 関係者が適切な行動を取れるように、十分に情報共有がされている
まとめ
若手にプロジェクトの主導を任せるのはなかなか勇気の要る事ですが、その分成長機会としては非常に良いものになるかと思います。
一方でマネジメントやコミュニケーションの面は経験不足かもしれないので、その点は体制や周囲の意識でフォローしていければ良いのではと思いました。
本記事が、プロジェクトの主導を任された方、もしくは任せようとしている方の参考になれば幸いです！
