2026/9/17更新: 2026/10/26約11分で読めます

「80％完了しています」を信じていい？開発の遅れに早く気づく確かめ方

「80％完了」「ほぼ完成」という報告を、使える機能と残作業に置き換えて確かめます。デモで見る点、遅れの原因、立て直しの選択肢を整理。確認表と再計画メモを、次の打ち合わせへ持っていけます。

影山湧亮 / NeoLogic株式会社代表取締役。元警視庁。現場業務の整理と生成AI活用・Webシステム開発を一貫して担当。

開発の進み具合は、「何%完了」ではなく、業務の場面ごとに、保存した結果まで動いた範囲、残る作業、判断待ちの担当と期限で見ます。

たとえば、開発会社から「80%完了しています」と報告されたのに、実際に使えるかは分からない。開始予定日は近づいているのに、何を聞けばよいか迷うことがあります。

打ち合わせ前にメールで確認するなら、次の文を使えます。

初回に必要な操作について、現在の版で保存した結果と、まだ試していない部分を見せていただけますか。残る作業と、判断待ちの担当・期限も教えてください。利用開始予定日に何を使えるか、次の打ち合わせで確認したいです。

進捗確認表・再計画メモ（Excel）の「03_確認表_空欄」へ回答を記入すると、使える業務と残る作業を並べられます。

完成時の受入テスト・検収は、合意した完成条件に沿って別に行います。

進捗率だけでは分からないこと

「80%」の分母が画面数なのか、作業時間なのか、試験項目なのかで意味は変わります。まず算出方法と完了基準を聞きます。算出方法が分からなくても、利用場面を示せば話を進められます。利用場面は、「担当者が修理依頼を登録し、保存した内容をもう一度見る」といった、業務として結果を確かめられる単位です。

たとえば、入力画面と完了メッセージができていても、データの保存や外部台帳への連携が残っている場合があります。成功したように見える表示が、説明用の仮の応答である可能性もあります。利用場面が未整理のままでは、開始日に何の業務を任せられるのかを判断できません。

修理受付システムの開発を例に、報告の違いを比べます（想定例）。

表1　「80%完了」報告と、利用場面別の報告の違い

知りたいこと	割合だけの報告	利用場面別に補った報告
いま動く範囲	80%完了。分母と完了基準は不明。	入力画面は操作できる。保存・再表示はまだ試していない。
納期に残る不確実さ	残り20%。残作業の内訳は不明。	外部接続情報の提供日が不明で、連携の試験に着手できない。
発注側が次に決めること	特に記載がない。	外部連携を初回に含めるか、代替運用を認めるかを判断する。

割合や工程表は全体の予定を把握するために使い、利用場面別の報告で使える範囲と残る判断を補います。設計や環境準備など、画面に現れない成果まで「進捗ゼロ」と扱わないようにします。

毎回見るものを絞る

進捗会議では、重要な利用場面ごとに「動いた範囲」「試した結果」「残作業」「未決事項」「次に必要な判断」をそろえます。試した結果は「合格」「不合格」「未実施」「判定保留」などに分け、何の条件に対する判定かを書きます。画面の表示だけが合格でも、利用場面全体が完了したとは扱いません。

修理依頼なら、まず一件を入力し、登録を押し、一覧へ戻って、その依頼を開き直します。完了メッセージが出ても、保存した内容が再表示できなければ「登録から再表示まで済み」にはできません。次の架空例では、この保存の試験がまだ残っています。外部台帳への反映と通信失敗後の再送も、同じように操作後の結果まで追います。

表2　利用場面別の完了表：画面と、業務の完成状況

利用場面	実際に動いたこと	未完了事項	次に必要な判断
S1　修理依頼を登録し、再表示する	仮の入力で完了画面まで表示。保存の証拠は不明。	保存・再表示の試験。開発側は保存処理を実装中と報告。	発注側が9月16日までに必須項目を確定する。
S2　外部の顧客台帳へ反映する	連携ボタンと仮の成功表示。実接続は未実施。	接続設定、項目の対応付け、相手側の登録結果を見ること。	契約窓口が接続情報の提供日を照会し、初回に含めるか決める。
S3　通信失敗後に再送する	通常送信の画面だけ。失敗時の再現は未実施。	失敗記録、二重登録防止、再処理の実装と試験。	発注側が再送の単位と担当を決め、開発側が試す日を示す。

共通条件は2026年9月15日、試験環境v0.8、仮の入力データです。3場面とも、一連の操作はまだ通っていません。

再送には、修理依頼の登録時に通信が切れた場合も含めます。外部連携を後日に回しても、初回に残す登録処理の二重登録防止は確かめます。

デモでは、操作の後に保存内容を再表示し、外部連携なら相手側の登録結果まで示してもらいます。画面で示せない部分は、処理記録や試験結果の該当箇所を見せてもらいます。秘密情報は伏せ字や共有画面など、閲覧できる範囲に合う方法で扱います。仮の応答で代用した部分と、実接続した部分は分けて記録します。

同じ「登録できた」でも、別の版や権限で試していれば比較できません。試した日、環境・版、入力条件、試した人、証拠の所在をそろえ、変更後に試し直す範囲を決めます。「未実施」は、判断材料がまだない状態です。

発注側が開発側の全試験をやり直す必要はありません。業務上の期待結果と未決事項を押さえ、技術的な試験記録の提示を依頼します。受入れの合否を決める段階では、システムの受入テスト・検収で確かめることで、契約で合意した完成条件と照合します。

同じ画面でも、前回から何が動いたかを書ける

進捗報告の練習には、店頭預かり修理の操作例を使えます。架空のラジオTG-1001で、4,800円の見積りへ同意を記録し、見積りを直すボタンで金額を6,000円へ直して確定してください。2026年11月1日の確認では、同意の記録で「修理開始待ち」へ進み、「③ 修理」の画面が自動で開きました。見積り変更後は「同意待ち」の状態へ戻りました。受付の記録・全明細の件数も、初期の1件から2件、3件へ増えました。

この結果を会議で報告するなら、「修理画面が完成」ではなく、次のように分けられます。

報告する範囲	書ける内容
画面で動いたこと	同意前・同意後・見積り変更後の状態を切り替えられ、記録が増えた
次に見せてほしいこと	実際に保存した変更前後の内容を、画面を閉じた後も同じ受付番号で開けるか
別に残る試験	同意記録の保存、担当交代後の再表示、通知先での受信、通信失敗時の再操作

この公開デモは画面の流れを試す見本であり、上表の後ろ二行まで済ませた証拠にはなりません。打ち合わせでも、状態が変わった画面と、保存先・連携先で確かめた結果を分けて示してもらうと、次回までに必要な作業を絞れます。表2の架空案件v0.8とは別の操作例です。

兆候と事実を分ける

「順調です」と言われる一方で前回から何が進んだか分からない、デモの日が何度も変わる。こうした状況は調べる手がかりになります。ただし、連絡の遅さや資料の少なさだけで、開発が止まったとは断定できません。まず、印象を確かめられる事実へ置き換えます。

表3　気になる兆候を、調べる事実へ変える

気になる兆候	調べる事実・資料	その時点では断定しないこと
完了予定や説明が変わる	前回と今回の計画差分、追加された作業、変更を決めた記録。	説明が変わっただけで、虚偽や失敗とは判断しない。
同じデモが続き、先へ進めない	デモの版と環境、前回から進んだ箇所、見せられない理由と次のデモの日。	画面に変化がないだけで、裏側の作業も止まっているとは判断しない。
未決事項が積み上がる	判断待ちの項目、担当者、回答期限、それが止めている作業。	未決事項をすべて開発側の責任とは判断しない。

たとえば「デモを断られた」ではなく、「9月15日に予定したS2の実接続を試せず、接続情報の提供日も分からない」と残します。これなら、連携の遅れと、提供日が分からないことを分けられます。原因が分からない欄は「不明」とします。

次のデモの日を合意しても必要な記録が出ない、必須業務に影響する判断待ちを担当者だけで解消できない場合は、双方の責任者を交えて相談します。証拠、影響、選択肢をそろえて持ち込み、案件で決めた協議手順に沿います。

IPAのアジャイルモデル契約の説明も、チーム内で解消が難しい問題を、チーム以外の責任者を含む協議へ進めることを規定しています（講演資料p.46（PDF））。

遅れの原因を整理する

遅れを立て直すには、「何が何を止めているか」を整理します。仕様変更なら、当初の合意と追加要望の差分。資料不足なら、必要な資料と提供担当。技術課題なら、再現条件と調査結果。作業量の見誤りなら、残作業の内訳と見直した見積りを聞きます。複数の原因が重なっている場合もあります。

修理受付の例では、外部サービスの接続情報がないと実接続を試せません。一方、必須項目が決まれば、登録・再表示の試験は先に進められるかもしれません。「接続情報の提供→設定→実接続」と「必須項目の確定→保存処理→再表示」を分け、前の条件がそろう日と、その後の作業を確かめます。

足りない情報の取得先も決めます。接続条件は外部サービスの公式資料と契約窓口、業務上の必須項目は発注側の業務責任者、実装の残作業は開発側の担当者に聞きます。提供日が分からなければ、「いつまでに照会し、いつ再計画するか」を決めます。

依存する判断が変われば、選ぶ案も変わります。外部台帳への登録を一時的に手入力できるなら、連携を後日に回す案が候補になります。必要な件数を処理できない、照合担当を置けない場合は、同じ案を選べません。代替運用は、担当・処理量・照らし合わせ方・終了条件までそろえて比較します。

小さな表示変更を定額保守の範囲で行う案件なら、詳細な工程表までは不要な場合があります。変更箇所、試した結果、反映日、担当の短い記録で足りることもあります。次の判断に足りる情報を残してください。

立て直しを選ぶ

原因が見えてきたら、同じ残作業を前提に選択肢を比較します。追加開発だけでなく、代替運用や引き継ぎの負担も含めて見積りを求めます。範囲変更と日程変更、必要な支援の追加は組み合わせても構いません。

表4　立て直しの選択肢を、費用と影響で比べる

選択肢	費用として聞くもの	成立条件・残る影響
A　必須範囲を絞る	削減後の再見積り、代替運用と後日開発の費用。	外した機能を使わなくても業務が成立すること。重要な安全確認は省かない。
B　日程を変更する	延長中の開発・運用費、旧業務を続ける負担。	待ち条件と残作業から新しい日程を組めること。日付だけを後ろへずらさない。
C　支援を追加する	追加担当の費用、引き継ぎ・環境準備・試験の時間。	分担できる作業があること。外部の回答待ちや仕様未決は人数だけでは解消しない。
D　一時停止・中止する	精算、成果物・データの引き継ぎ、別手段へ移る費用。	継続の前提が整わない場合の選択肢。終了条件と業務継続策を先に決める。

外せる機能は業務上の影響で決め、データの欠損や二重登録を防ぐ必須の点検を後回しにしないようにします。分からない費用はゼロと置かず、見積りの担当と提示日を残します。

この案件を、再計画メモにする

この例では、9月15日に予定した一連の動作に間に合っていません。外部連携を後日に回すA案を第一候補としますが、手入力が成立するかはまだ分かりません。条件がそろわなければB案へ切り替え、開始日を再設定します。判断日と不成立時の扱いを残し、日付だけを約束し直さないようにします。

当初の計画から変えるのは、外部台帳への連携を初回から外すことです。9月18日までに業務責任者が手入力を続けられるか見極め、開発側は範囲変更と後日連携の費用を示します。登録と再送の試験は9月24日まで、受入・移行は9月25〜29日という案です。9月30日の開始を確定したわけではなく、手入力が成り立たなければ日程も変えます。

未合意の再計画メモを通して読む

表5　遅延案件の再計画メモ（想定例・未合意の検討案）

記録する項目	記入例
利用場面・当初計画	修理受付・顧客管理連携システム。9月15日に一連の動作を試し、9月30日に業務開始の計画。
動いたこと・残る作業	表2のS1〜S3。9月15日の一連の動作はまだ通っていない。外部接続情報の提供日と、追加費用は不明。
依存する判断	契約窓口は9月16日までに提供日を照会。業務責任者は9月18日までに手入力の担当・処理量・照合方法・終了条件を決める。
範囲・日程の変更案	Aを第一候補とし、S2の外部連携を後日に回す。S1・S3を9月24日までに試し、9月25〜29日に受入・移行を行う案。9月30日の開始は条件付き。
費用・体制	開発側が9月18日までに範囲変更と後日連携の費用を提示。業務側は代替運用の負担を見積もる。追加費用・負担の確定値は不明。
合意・見直し条件	9月18日に双方の責任者が案を選ぶ予定で、現時点は未合意。手入力が成立しなければBへ変更。重要な確認が終わらなければ9月30日は開始しない。
日付・版・証拠の所在	2026年9月15日／試験環境v0.8／再計画メモ案v1、会議記録EX-01、作業表EX-02。
まだ分からないこと	実データでの動き、運用負荷、最終的な受入可否。