開発が遅いと感じたら、エンジニアを責める前に見る3つの時間

月曜の定例で、経営者が「公開はいつですか」と聞きます。開発責任者は「確認します」と答え、翌週も同じ会話が続きます。画面は少しずつできていますが、顧客へは届きません。

「開発が遅い」と感じた経営者は、担当エンジニアの能力や人数を疑いたくなります。僕なら、人を増やす話より先に、依頼から公開までを手を動かした時間、返事を待った時間、作り直した時間へ分けます。

遅れの多くが社内の回答待ちや着手後の変更なら、採用や担当交代では直りません。優先順位を決める人、質問へ答える期限、完成を認める条件を整えるほうが先です。

開発が遅い原因は、コードを書く時間だけでは分かりません

開発にかかった期間は、エンジニアが実装していた時間と同じではありません。顧客から依頼を受けた日から公開日までには、企画の承認、仕様の確認、データや権限の受け取り、実装、レビュー、受け入れ確認、公開承認が入ります。

経営会議から見ると、全期間が「開発中」に見えます。しかし、開発者が質問を出してから営業部門の回答まで五日止まっていたなら、五日間を実装能力の問題にはできません。公開直前に対象顧客が変わり、画面を作り直した場合も同じです。

反対に、必要な回答がそろい、優先順位も動かず、似た規模の変更より実装とテストに長い時間がかかっているなら、技術側を調べます。複雑な既存コード、遅い自動テスト、開発環境の不具合、担当領域の経験不足、レビューの集中が候補になります。

エンジニアの能力が原因になる案件もあります。ただし、依頼から公開までの総日数だけでは判定できません。担当者を評価する前に、本人が動かせた区間と、社内外の返事を待った区間を分ける必要があります。

僕が最初に知りたいのは、長く止まっている区間です。誰を責めるかは後で構いません。区間が分かれば、経営者が回答者を決めるのか、仕様を狭めるのか、技術支援を入れるのかを選べます。

開発スピードを上げるには、3つの時間へ分けます

一つ目は、手を動かした時間です。技術調査、設計、実装、自動テスト、手動確認、コードレビューの作業を含めます。厳密な秒数を記録する必要はありませんが、着手日、最初のレビュー依頼日、修正完了日を課題管理画面で追えるようにします。

手を動かした時間が長い案件では、テスト結果とビルド履歴を開きます。毎回同じ確認を人が繰り返しているなら自動化を検討し、一つの変更で広い範囲が壊れるなら作業を小さく分けます。担当者が領域を初めて扱う場合は、経験者が設計と最初の変更を一緒に見ます。

二つ目は、返事を待った時間です。優先順位、画面の文言、利用者の範囲、追加予算、外部サービスの審査、レビュー、公開可否への回答待ちを含めます。質問を出した日時、答える人、回答予定日が書かれていなければ、待ち時間は会議の外で増え続けます。

待ち時間を短くする方法は、会議を増やすことではありません。質問を「誰か確認してください」のまま流さず、回答者名と期限を同じチケットへ書きます。期限までに答えられない場合は、仮の前提で進めるか、別の仕事へ移るかも回答者が選びます。

三つ目は、作り直した時間です。着手後に対象利用者が変わった、営業との約束が追加された、完成条件が後から変わった、承認済みの案が別の会議で覆った場合に発生します。差し戻しの回数だけでなく、変更前の作業を捨てた理由を残します。

作り直しが多い案件では、実装を急ぐほど損失が増えます。CTO代行で組織の意思決定を変える考え方も参考に、実際に近いデータを入れた試作画面で、利用者と受け入れ担当者が同じ操作を確認してから実装へ進みます。

直近10件を三つの時間へ分けても、担当者同士の生産性比較には使いません。案件ごとに難しさと確認相手が違うためです。PR数やコミット数も操作回数に近く、顧客へ届いた価値や開発全体の生産性とは同じではありません。

10件は業界標準を示す数字ではありません。僕が、最初の会議で現物を読める量として置いた出発点です。公開できた案件だけを選ばず、中止した案件と長く止まっている案件も含めます。成功した仕事だけでは、待ち時間と作り直しを小さく見積もってしまいます。

経営側の選び方が、開発を遅くする場合があります

優先順位を毎週決めていても、週の途中で役員や営業から新しい依頼が直接入れば、実装中の仕事が増えます。担当者はどの仕事も少しずつ進め、調査した内容を思い出す時間が何度も発生します。新しい依頼を入れるなら、止める案件も同時に選ぶ必要があります。

経営者が公開日だけを固定し、機能範囲を決めない場合も止まります。日程、予算、対象範囲を全部守れない場面で、何を動かしてよいかを実装者は決められません。選択肢が上がった日に答えず、期限だけを維持すると、表面上の予定と実際の作業が離れます。

評価方法も報告の速さへ影響します。予定どおりに出した人だけを高く評価し、早く懸念を共有した人まで責めると、難しい情報は締切の直前まで上がりません。早い警告には代替案を求め、無断で放置した場合と分けて扱います。

開発会社へ依頼している案件では、発注側の返答手順も確認します。開発会社が追加要望を受けても、費用と納期を承認する人が決まっていなければ着手できません。顧客への聞き取り結果や現行業務の資料を共有できない契約と運用なら、開発会社は仮定で作るか、回答を待つしかありません。

経営側に原因があるという話は、経営者が技術の細部まで決めるべきだという意味ではありません。経営者が持つのは顧客、予算、期限、優先順位の選択です。技術責任者は選択内容を設計と作業順へ変え、実装者が迷わない形にします。

開発が遅いとき、増員と交代は記録を見て決めます

手を動かした時間が大半で、承認済みの仕事が並び、レビューと公開も止まっていないなら、実装する人数が足りない可能性があります。担当範囲を分けられるか、教える人とレビューする人の時間を確保できるかを確認してから増員します。

人数を増やす判断では、採用後の説明とレビューも作業に含めます。CTO代行は週1で何を担えるかで説明したように、質問へ答える人がいない組織へ実装者だけを加えると、待つ人とレビュー依頼が増えます。

手を動かした区間が似た案件より長く、同じ種類の指摘がレビューで続く場合は、担当者への支援を決めます。完成条件を一緒に読み、経験者と設計し、小さな変更から確認します。支援後も同じ問題が続くなら、担当範囲の変更や交代を検討できます。

返事を待った時間が長い場合は、増員より回答経路を直します。顧客要望を採用する人、追加費用を認める人、公開を止められる人を案件ごとに一人ずつ決めます。全員の合意が必要な項目は限定し、通常の変更は担当者が期限内に決められる範囲を渡します。

作り直した時間が長い場合は、企画と要件確認を直します。対象利用者、変える業務、対象外、完成を確かめる画面を着手前に一枚へ置きます。途中変更を禁止する必要はありません。追加する機能と引き換えに、外す機能、動かす日付、増える費用を一緒に選びます。

技術的な遅れと経営側の遅れは、同じ案件に共存します。たとえば、自動テストに時間がかかり、仕様の回答も遅い案件では、片方だけを直しても公開日は十分に縮まりません。三つの時間のうち長い区間から順に手を入れ、次の10件で変化を見ます。

次の定例では、直近10件を一本の線へ並べます

次の定例までに新しい管理制度を作る必要はありません。課題管理画面から、最近公開した案件、取りやめた案件、作業中の列へ長く残る案件を合わせて10件選びます。案件名の一覧では足りません。実際のチケットを開ける状態で会議へ持ち込みます。

各案件について、依頼日、優先順位を確定した日、仕様の質問日と回答日、実装の着手日、レビュー依頼日と完了日、受け入れ確認日、公開日を時系列へ置きます。着手後に範囲が変わった場合は、変更した人、理由、捨てた作業も同じ線へ記録します。

日付が残っていない区間は、記憶で正確な数字を作りません。「記録なし」と書き、次の案件から質問と回答をチケットへ残します。測れない状態を認めたほうが、根拠のない進捗率を並べるより改善へつながります。

会議では「なぜ遅いのですか」と全体を聞かず、最も長い区間を一つ選びます。手を動かした区間ならテスト結果とレビュー履歴を開き、待った区間なら質問と回答者を開き、作り直した区間なら変更前後の完成条件を開きます。

経営と技術をつなぐ人がいない会議の問題も、進捗率の数字を離れて現物を見る助けになります。経営者がコードを読めなくても、止まった理由、次に答える人、確認できる画面、顧客へ届く日付は確認できます。

開発スピードを上げる最初の一手は、チームへ「もっと速く」と伝えることではありません。明日の午前に直近10件から一件を選び、依頼から公開までの日付と待った相手を課題管理画面へ追記してください。

手を動かした時間が長ければ技術支援を選び、返事を待った時間が長ければ回答者と期限を決め、作り直した時間が長ければ完成条件を画面で合わせます。最も長い区間を縮める施策だけを次の一週間で試せば、採用、担当交代、仕事の進め方のどこへ手を入れるべきかを記録から決められます。