開発が予定通りに進まない、という話は多くの現場で起きます。
たとえば、予定していた機能がスプリントに乗らないと、月内に出すはずだった改善は次のリリースに回ります。
その結果、営業資料に載せる予定だった機能や、顧客に説明していた改善が間に合わず、事業側の計画にも影響が出ます。
事業側から見ると、これは単なる工数のズレではありません。
予定していたタイミングで、事業に必要な機能や改善が使える状態にならないことです。
このとき、原因はエンジニアの作業速度や見積もりの甘さに見えやすくなります。
もちろん、実装スピードや見積もり精度も遅れに関係します。
ただ、開発の遅れをそこだけで捉えると、本質を見誤ります。
実際には、開発が遅れる前から、遅れる理由が計画の中に埋め込まれています。
- 作る理由が曖昧なまま進む。
- 機能名だけで工数を見積もる。
- 調査前の感覚値が、いつの間にか約束された納期のように扱われる。
こうした前提のズレが、実装中やリリース前に表面化します。
そしてこのズレは、主に3つの前提から生まれます。
- 作る理由が共有されているか: 機能名だけが渡ると、仕様通りでも目的からズレます。
- 見積もりの前提が分かれているか: 調査前の概算と、実装方針を見た後の見積もりは別物です。
- 不確実性をチームで扱えているか: バッファを取りにくい空気は、遅れを開発中に先送りします。
遅れは実装中に見えるが、原因は実装前にある
開発の遅れは、実装中やリリース前に表面化します。
実装に入ってから思ったより時間がかかり、レビューで大きな修正が出る。
仕様の確認が戻り、作ったものを見た事業側から「少し違う」と言われる。
こうした出来事だけを見ると、開発中に問題が起きたように見えます。
しかし原因をたどると、実装前の時点で前提が曖昧だったと分かります。
何を作るかは決まっているように見えても、なぜそれを作るのか、誰のどの業務を変えるのか、何ができれば成功なのかまでは詰めきれていない。
その状態で「この機能を作る」と決まり、開発に渡されると、エンジニアは仕様やチケットに沿って実装します。
それでも完成後に、事業側から見ると「たしかに作られているが、期待していたものとは違う」という状態になります。
これは単なる仕様漏れではありません。
作る理由が十分に共有されないまま、機能だけが開発に渡っていることが問題です。
作る理由が落ちると、仕様通りでもズレる
多くの開発では、上流とエンジニアの間にPMやディレクターが入ります。
事業側や顧客が「こういうことをしたい」と話す。
PMやディレクターがそれを整理し、「この機能を作る」と決める。
エンジニアには、実装する機能や画面が渡される。
この流れ自体が悪いわけではありません。
事業側の要望を整理し、開発に渡せる形にする役割は必要です。
ただし、途中の翻訳で目的が落ちると、開発はズレやすくなります。
本来は「問い合わせ対応を早くしたい」だったものが、「管理画面に検索機能を追加する」だけに変わり、「営業が商談前に顧客状況を把握したい」だったものが、「CSVエクスポートを作る」だけになる。
機能名だけが渡されると、エンジニアはその機能を実装します。
しかし、目的が違えば必要な項目、導線、権限、表示順、例外処理は変わります。
仕様通りに作っているのに、事業側から見ると違う。
このズレが後から修正や再検討になり、リリース予定を押し出します。
重要なのは、エンジニアにすべての背景を長文で渡すことではありません。
その機能がどの事業課題を解決するためのものかを、判断できる程度に共有することです。
機能名だけでは工数は見積もれない
もうひとつ大きいのは、見積もりの前提です。
現場では、機能名だけを見て工数を尋ねる会話がよく起きます。
開発計画を立てるには、概算が必要です。
事業側が時期や優先順位を決めるためにも、ある程度の見通しは欠かせません。
ただし、機能名だけを見ても、本来は工数を正確には出せません。
同じ「検索機能」でも、既存データの構造、検索対象、権限、表示速度、既存画面との関係、例外処理、テスト範囲によって工数は変わります。
既存コードを読んで初めて、想定していなかった依存関係も見えてきます。
実装方針が決まっていない段階の数字は、見積もりというより仮の感覚値に近いものです。
それ自体が悪いわけではありません。
問題は、その感覚値がいつの間にか約束された納期のように扱われることです。
数字を受け取る前に、少なくとも次の違いは分けておく必要があります。
- 調査前に出した概算
- 既存コードを見たうえでの見積もり
- 実装方針やテスト範囲まで含めた計画
ここを分けずに数字だけを受け取ると、後から見えてきた作業はすべて「遅れ」として扱われます。
本来は調査によって明らかになったリスクでも、計画上は単なる遅延に見えてしまいます。
見積もりの数字を見るときに重要なのは、その数字が何を前提にしているかです。
作る理由、変えたい業務や顧客体験、成功したと言える状態、既存コードへの影響、実装方針の有無。
これらが揃っていない数字は、計画というより、まだ不確実性を多く含んだ目安として扱う必要があります。
バッファは個人の甘えではなく、チームの設計である
開発では、実際に手を動かしてみて初めて見える作業があります。
古い実装の前提が残り、別の機能にも影響する。
データの持ち方が想定と違い、権限や例外処理まで見ると単純な実装では済まなくなる。
こうした不確実性を考えるなら、見積もりにはバッファが必要です。
ただし、バッファを取る責任をエンジニア個人だけに置くのは危険です。
チームの空気によっては、バッファを取りにくくなります。
短い見積もりが前向きに見え、慎重な見積もりが消極的に見える。
他の人が短い工数を出していると、自分だけ長く出しづらくなる。
この状態では、チーム全体が浅い見積もりに寄っていきます。
見積もりでは、経験によって見えている作業の範囲が変わります。
実装の中心部分だけを見ると短く見えますが、既存コードへの影響、レビュー、テスト、将来の変更、リリース後の運用まで含めると、必要な時間は変わります。
慎重な見積もりは、手が遅いから出ているとは限りません。
見えている作業が多いから、長めの見積もりになります。
短い見積もりだけを評価するチームでは、不確実性は表面上消えます。
しかし消えたのではなく、開発中に先送りされただけです。
その結果、実装の途中やリリース直前にまとめて表面化します。
バッファは、個人の甘えではありません。
未知の作業を計画の中で扱うための、チーム側の設計です。
開発の遅れを減らすには、エンジニアに「もっと速く」と言うだけでは足りません。
実装前の不確実性を、チームとして見える場所に出す必要があります。
作る目的が曖昧なら、先に目的を整理する。
既存コードの影響が分からないなら、見積もりの前に調査する。
実際にやってみないと分からない領域があるなら、その前提を計画に含める。
このように扱うことで、開発の遅れは個人の問題ではなく、チームで管理できるリスクになります。
開発の遅れは、チームが不確実性をどう扱うかで決まる
開発が予定通りにリリースできないとき、最後に見えるのは実装の遅れです。
しかし、その原因はもっと前にあることが少なくありません。
なぜ作るのかが曖昧なまま機能だけが渡され、機能名だけで工数が聞かれる。
調査前の感覚値が約束のように扱われ、バッファを取る空気がないまま浅い見積もりが評価される。
これらはすべて、チームが不確実性をどう扱っているかの問題です。
開発は、予定表に機能を並べればその通りに進むものではありません。
作る理由、影響範囲、実装方針、事前に見えているリスクを共有して初めて、リリース計画は現実に近づきます。
開発が遅れる理由を、エンジニアの手の遅さだけにしないこと。
そこから、事業側と開発側の会話は変わります。
予定通りに出すために必要なのは、強く急がせることではなく、遅れにつながる前提を早い段階で見えるようにすることです。