Safie Engineers' Blog!

Safieのエンジニアが書くブログです

プロジェクトにおける「全体像の可視化」の重要性

こんにちは。25新卒エンジニアの中です。

大学院では、ある車の会社と共同で「機械学習を用いて物理シミュレーションを置き換える手法」について研究を行い、先日ローマにて行われたAI関連の学会でポスター発表してきました。エスプレッソもパスタもワインも美味しかったです。

このブログでは、入社してから4ヶ月弱で行われた新卒研修プロジェクトで学んだ、「全体像の可視化」の重要性について話していきます。

新卒エンジニア研修について

今回のセーフィーの新卒エンジニア研修では、4月真ん中から7月末までの4ヶ月弱で、「社内課題を解決するためのプロダクト開発」を行ないました。この研修の最大の目的は、「プロダクト思考を体現し、エンジニアとして成長する」ことです。つまり、ユーザー目線に立ち、プロダクトを考え、それに沿って開発を進め、その上で成長していくことが求められました。

研修で直面した壁

研修プロジェクトが始まってすぐに私たちが直面したのは、『チーム全員でプロジェクトの全体像を把握すること』の難しさでした。私たちのチームには、以下の2つの目的がありました。

  1. 新卒研修プロジェクトの目的:プロダクト思考を身につけ、エンジニアとして成長する
  2. プロダクトの目的:ユーザーの課題を解決する

プロジェクトの全体像の把握ができていないと、この2つの目的を同時に達成することは難しいと痛感しました。

プロジェクトの全体像が見えなかった初期フェーズ

チームでの開発フェーズが始まった初期段階では、プロジェクトの進捗状況が把握できていませんでした。

  • 口頭でのタスク管理:口頭で決まったことがタスクとして記録されず、それぞれのタスクの粒度もバラバラでした
  • タスクの偏り:誰が何をするのかが曖昧になり、チーム全体でタスクを抱えている人と、そうではない人の差が大きくなっていきました。
  • 漠然とした不安:目の前のタスクをこなすことに精一杯で、「本当にユーザーの課題を解決するものなのか?」「このプロセスが自身の成長に本当につながっているのか?」という漠然とした不安が常に付きまといました。

これは、プロジェクト全体の把握ができていないことにより、「自身の成長」と「ユーザーの課題解決」という2つの目的を見失っていたことが原因でした。

振り返り会と「可視化」の徹底

プロジェクト全体の把握ができていないという課題を解決するため、私たちは開発機関の中間地点で開催した振り返り会で現状を共有しました。そこで、私たちは以下のシンプルなルールを徹底することに決めました。

タスクは必ずチケットとして可視化し、粒度を揃える

具体的なルールは以下の通りです。

  • チケットは1~2営業日以内で完了するものに限定する
  • 処理中のタスクは1~2個にする
  • 複数のタスクが同日に並ぶ場合は、全てその日で終わらせられる場合のみとする

このルールにより、メンバー間でタスクの共通認識が生まれ、スムーズに開発を進められるようになりました。

Before

弁当競合調査の中で何をするのか、どう調べるのかがわからず、進捗状況が一目で分かりづらい。開発本部会は1日のはずなのに4日分引かれており、その中で何をするのかがわからない。

After

アイテム画面実装という親タスクに対し、何をするのかを小タスクとして設定し、進捗を確認しやすくなりました。

研修を振り返ってみて

もし研修開始当初に「全体像の可視化」の重要性に気づけていたら、私たちのプロジェクトはもっとスムーズに進んだという仮定のもと、開発研修を振り返っていきたいと思います。

4月-5月前半:課題発見フェーズ

この時期は、プロジェクトの進め方や課題を発見するための手法に関する知識が不足していました。

もし全体像が可視化されていたら…

  • 最終ゴールの明確化:最終的に完成させるプロダクトの規模やビジョン、最終到達点をチームで明確に合意していれば、そこから逆算してマイルストーンを設定できたはずです
  • Backlogの適切な運用:ゴールが定まっていれば、Backlogのチケットの粒度も自然と定まり、手探りでの運用を避けることができたはずです

5月後半-6月前半:課題発見フェーズ2

この期間は、メンバーが入れ替わりで研修に参加していたため、チーム内での進捗共有が不十分になってしまいました。

もし「全体像」が可視化されていたら...

  • スムーズな進捗共有:プロジェクトの全体像が可視化され、Backlogに適切にチケットが反映されていれば、戻ってきたメンバーもすぐに状況を把握できたはずです
  • チームの一貫性の維持:チームとしての判断軸が定まっていれば、メンバーが抜けても方向性がぶれることはなかったでしょう

6月後半-7月:開発と未来設計のフェーズ

開発期間は、当初の計画よりもミニマム開発の完了が遅れてしまいました。また、明確なルールがないままアジャイル的な進め方になったため、進捗の把握に苦労しました。

もし「全体像」が可視化されていたら...

  • 運用を見据えた設計: 開発の初期段階から「運用しやすい設計になっているか?」「コストに見合う価値があるか?」といった問いに向き合え、属人化を避けるための人員配置や計画を立てられたはずです

まとめ

この研修プロジェクトを通して、私は技術的なスキルだけでなく、『チーム全員が同じ全体像を共有し、目的を意識して開発を進めること』が、プロジェクトの成功と自身の成長に不可欠だと学びました。

研修で直面した壁は、私たちを大きく成長させてくれました。配属されて数週間経った今、この経験を活かし、自身の成長とチームとしての成果、両方の視点を持って行動することを心がけています。

今後、この研修で開発したプロダクトは、社内運用に向けてチームで議論を重ねていきます。技術を学ぶだけではないこの新卒研修プロジェクトを経験できたこと、そして多くの壁をチームで乗り越えた経験は、これからのエンジニアとしてのキャリアにおいて、常に活かされていく大切な教訓です。

© Safie Inc.