【反省】初リードを務めたプロジェクトを3週間遅延させた話
こんにちは、mayaです。
昨年11月から既存システムのリプレイスプロジェクトに参画し、初めてプロジェクトリードというポジションを経験しました。4名ほどの小規模チームで、計画から実装までを担当し、今回一区切りついたので振り返りをしようと思います。
対象読者
この記事は以下のような方に読んでいただけると嬉しいです：
- 最近プロジェクトリードやマネージャーになったばかりの方
- 将来的にチームを率いる立場になりたいと考えている方
- プロジェクト進行に課題を感じている開発者の方
私たちのチームも完璧ではなく、予定より3週間の遅れが生じました。その原因と対策を共有することで、同じような立場の方の参考になれば幸いです。
※記事内容は、できるだけ汎用的な内容になるよう努めましたが、一部リプレイスプロジェクトならではの反省点も含まれます
プロジェクトの全体像
プロジェクト概要
私が参画したのは、既存のシステムをリプレイスするプロジェクトです。当初は2月の下旬〜3月上旬の完了を予定していましたが、バッファを追加して3/19完了予定としていました。実際には4/9に完了し、結果として3週間のスケジュール遅れが発生してしまいました。
チーム構成
【チーム構成】
・プロジェクトリード兼実装担当 2名（自分含む）
・実装メンバー 2名
・アドバイザー 1名
・インフラ担当 1名
小規模なチームだったため、リード役の私たちも計画立案から実際の実装作業まで、あらゆる工程に関わりました。
開発フロー
- 機能開発
- リファクタ対応
- 手動テスト
- デザインTレビュー
- サービスTブラウザレビュー
- バグ修正
- 再テスト
- 残課題対応
スケジュール遅延の原因分析
プロジェクト全体を通して、ほぼ全ての工程で工数通りには進められませんでした。主な原因は以下の3つです。
原因①：スケジューリングの甘さ
実労働時間の考慮不足
「工数が8hのタスクが5つある場合は、1週間で片付く」という期間設定をしていました。しかし現実はそう単純ではありません。
1日の勤務時間は9時間ですが、昼休みを除くと8時間、小休憩や雑務を除くと7時間、各種MTGやレビュー時間を考慮すると実質6時間程度しか集中して作業できません。この現実を考慮しないスケジューリングをしていました。
根拠のない期間設定
実装工数は比較的根拠のある数字を出しましたが、テストにかかる期間やバグ修正期間、他部署が担当する業務の工数については感覚値でざっくり出していました。
また、「誰が」その作業をするのかや、実質的に「作業できる時間」を考慮せず、単純に工数だけで期間設定していた点も問題でした。
バッファ設定の不足
前任者が作成したスケジュールを踏襲したいという気持ちと、早く完了させたいという思いから、バッファをほとんど設定していませんでした。特に実装フェーズにはバッファがなかったため、少しの遅れが大きく響きました。
※実はこのプロジェクトには初期から途中までリードを担当した方がおりまして、諸事情でその方がプロジェクトから外れたため、急遽自分たちが引き継いだのです
原因②：実装工数見積もりの甘さ
要件理解の不足による見積もり誤り
要件の洗い出しや他画面との関連理解が十分でないまま、コード量（行数）やロジック部分における依存数などでざっくりと見積もっていました。特に複雑な処理やデータ取得部分は、予想以上に時間がかかりました。
テスト仕様書先行型の欠如
画面の要件を洗い出した上で、テスト仕様書を作成してから工数を見積もる方がより正確だったと思います。仕様書は作成していましたが、レビューが適切に行えていなかったため、実装段階で多くの疑問や問題が発生しました。
原因③：想定以上のバグの発生
以下のような原因でバグが多発しました：
- 仕様理解が十分でなかったことによる不適切な実装、漏れ
- レビュー漏れ、デグレによる機能不全
- 細かな実装不備（リンクの遷移方法、バリデーション条件など）
- 環境変数の管理方法変更による慣れない運用
各開発工程の振り返りと実践知
1. 機能開発
良かった点：テスト仕様書先行型開発
仕様を明確にしてから実装に取り組むことで、明らかに実装漏れが減り、レビューも効率的になりました。また、後に使用するテスト仕様書を並行して作れたことで、手動テストもスムーズに進められました。
課題：PR処理のテンポの悪さ
PRの処理が滞り、PRが溜まることでレビューアー・レビュイー共に負荷が大きくなりました。
改善策：
- PRは適度に小さく作成する
- レビュアーはレビュー優先で進める（例：1日の中で1,2回、レビューする時間を設ける）
- Ready状態のPRは2つまでに制限し、それ以上はDraft状態にする
課題：適切な実装者割り当て
プロジェクト初期のメンバーに、複雑な仕様の考慮が必要な箇所の実装をお任せしてしまいました。チームに慣れていない段階では、もっとシンプルな要件のページから始めるべきでした。
課題：仕様書作成・実装・レビューの粗さ
時間的余裕がない中で全ての作業を急ぎ足で行ったため、細かい確認漏れが生じ、多量のバグ発生につながりました。
2. リファクタ対応
リファクタリングフェーズの目的を再確認しました：
- 実装フェーズ中に生まれた「パフォーマンス改善」「設計改善」「テスト実装漏れ」などに対応するフェーズ
- 計画の中に明確な「余白/余裕」を作ることで、プロジェクトの品質を向上させる期間
効果：
- 品質の向上
- 実装/レビュー時のストレス軽減（「リファクタの時に対応しよう」という判断ができる）
改善案：
- リファクタリングは2-3週間に一度の頻度で定期的に行う
- リファクタ対象はTODOコメントではなくリスト化して管理する
3. 手動テスト
良かった点：テスト仕様書の事前統一
テストおよびテスト仕様書を作る前に、チーム内で認識のすり合わせを行い、統一感を持って作業できたことで、レビュー時・テスト時に混乱が少なくなりました。
課題：テスト管理シートの分散 / 管理のしづらさ
バグ修正対応時、テスト仕様書と指摘を照らし合わせながら作業する必要がありましたが、指摘内容が個別のテスト仕様書に書かれておらず、シートを行き来する必要があって効率が悪かったです。
改善案：
- デザインチームのレビューシート方式を採用（ページごとの進捗を一覧で管理するページ＋個別のテスト仕様書）
- バグ一覧をSlackリストで管理し、自動通知を活用する
4-5. デザインレビューとブラウザレビュー
良かった点：スムーズな連携
テストの開始・終了の連携や、期間中のコミュニケーションをスムーズにとれました。
良かった点：わかりやすいレビューシート
デザインチームが作成したレビューシートは、スクリーンショットとFigmaリンクが添えられており、ページごとの進捗も一覧で管理されていて対応しやすかったです。
6-7. バグ修正と再テスト
課題：バグ記載方法の改善
バグの内容がテストシートと別れていることで、修正時や起票時にシートを行き来する必要があり手間でした。
改善案：バグの詳細内容をテストシートにも記載し、シートの関数を使ってバグ一覧シートに自動反映する仕組みを検討。
良かった点：異なるテスター間での再テスト
再テストでは一部、最初のテストとは別の人にテストしてもらったことで、二重チェックになり対応漏れを防止できました。
開発フロー改善の提案
私たちのチームは、今回の経験を踏まえて次のプロジェクトでは以下のような改善を検討しています。
もっと細かく開発サイクルを回す
一連の開発サイクル「実装→リファクタ→テスト→バグ修正→レビュー」をもっと細かく回すことで、今回浮き彫りとなった様々な課題に対応できると考えています。
全ページを一気に開発するのではなく、3-4つくらいのグループに分けて、段階的に開発していくイメージです。
なぜボリュームを小さくすべきか
リリースを経験して強く感じたのは「先行きが不透明であることの不安と焦り」です。これが様々な作業の粗さにつながり、多量のバグ発生の原因になりました。
ボリュームを小さくすることで：
- 見通しが立てやすくなる
- 管理もしやすくなる
- 1回あたりの手動テスト/レビュー負荷も下げられる
- バグの量もある程度コントロールできる
また、短期間で何度も開発サイクルを回すことで、バグに気づく機会も増え、リファクタをする機会も多く得られます。1サイクルで得られた学びを、次のサイクルにすぐに活かせます。
留意点
- 分割したまとまりがそれぞれ独立している必要がある
- 開発順の考慮も必要
- 最終的な統合テストも必要
- テスト・レビューを複数回行うため、各チームとの綿密な連携が不可欠
見積もり精度向上のための具体的手法
実働時間を考慮した工数見積もり
1日の実質的な作業時間を考慮して工数を見積もります。例えば1日9時間勤務の場合：
- 昼休み除いて8時間
- 小休憩除いて7.5時間
- 各種MTGや雑務除いて7時間
- PRレビューにかける時間を除いて6時間程度
これを基準に工数を計算すれば、より現実的なスケジュールが立てられます。
テスト仕様書作成後の工数見積もり
適切な設計・実装ができていない旧システムのコードはブラックボックスが多く、コード量・依存数だけで見積もるのは不正確です。特に複雑な処理やデータ取得部分は、テスト仕様書を作成して要件を洗い出した上で工数を見積もる方が確実です。
バッファ設定の科学
工数の25%程度の期間をバッファとして上乗せすることを検討しています。例えば実装に20日かかるなら、5日をバッファとして含めます。また、不確定要素の量に比例してバッファを増やすのも有効です。
プランニングポーカーの導入
アジャイル開発でよく使われる見積もり手法であるプランニングポーカーを部分的に取り入れることも検討しています：
- そもそも規模の大きいプロジェクトでは工数ベースの絶対見積もりが難しい
- いきなり工数（時間）をみつもるのではなく作業量を見積もる
- 定期的に実際かかった工数と見積もりを照らし合わせ、徐々に見積もり精度を向上させる
まとめ：このプロジェクトから学んだこと
プロジェクト全体を通して、主に以下の教訓を得ました：
- スケジュールは「実働時間ベース」で考える
- テスト仕様書先行で品質と工数精度を向上させる
- 小さな開発サイクルを回して見通しを立てやすくする
- チーム間連携は早期に明確なプロセスを設計する
- 相対見積もりとデータに基づく工数計画で精度を高める
私たちのチームは、これらの学びを次のプロジェクトに活かし、より効率的な開発フローを実現したいと考えています。同じような立場で奮闘している方々の参考になれば幸いです。
最後まで読んでいただき、ありがとうございました！
皆さんのプロジェクトが成功することを願っています。
Discussion