開発の進捗率50％は何が終わった数字？受入記録と予定を照らす方法

50％を読む前に、四つの前提をそろえる

進捗率は、何をどの方法で数えるかによって意味が変わります。作業に使った時間の割合、開発側が実装を終えた割合、発注側の受入確認が終わった件数の割合は、同じ数字になるとは限りません。「50％」と書かれていたら、まず報告書の見出しと数え方の説明へ戻ります。

対象の範囲：どこまでを数えたか

受注画面だけなのか、配送連携も含むのかを確認します。範囲を示さない割合を、システム全体の完成度へ読み替えません。

数える単位：分母に何を一件と置いたか

この例では四つの受入単位です。画面数、作業数、機能数、工数を混ぜません。一件ごとの大きさが違うこともあるため、件数の半分が仕事量の半分だとは限りません。

完了条件：どの確認を終えると数えるか

下書きができた、実装した、試験した、発注側が受入条件を確認した、を区別します。この例では最後の受入確認が済んだものだけを完了件数へ入れます。

報告時点：いつまでの事実か

同じ日時点の記録を比べます。先週の予定と今週途中の実績、あるいは対象の違う二つの報告を、そのまま比較しません。

以下の架空例の対象は「架空の印刷会社の受注画面に関する4つの受入単位のみ。全プロジェクトではない。」です。数え方は「各単位の受入条件と確認者を先に固定し、その条件を満たしたものだけを受入完了件数に数える。単位間の工数や価値が同じという仮定は置かない。」。四つすべてを同じ重さの工数として扱う前提はありません。

顧客にとって確認できる完成物と、開発側の管理で報告する進み具合を分ける観点は、IPAの旧資料「非ウォーターフォール型開発WG 活動報告書」の、顧客・経営層への進捗の見える化に関する箇所も参考にしています。2011〜2012年の検討を扱う資料で、すべての開発方式や契約に共通する計算式を定めたものではありません。本稿の四単位の教材は独自の架空例です。

受注画面の四つの仕事と、受入記録を照らす

架空の印刷会社の発注側業務担当が、注文受付画面の進行報告を読む場面です。対象は受注画面の四単位の記録、報告時点は架空の第2週末。記録された前回からの範囲変更はなしで、この四単位を同じ分母として扱います。

数える対象は4単位、受入確認済みは2件。計算の根拠は2/4=50%です。割合だけを見る前に、次の四件の状態と根拠を照らします。

1. 注文番号を表示

   受入状態：受入確認済み。記録の根拠：受入確認記録あり。

   先に決めた条件と確認者に対応する受入記録を、実際の案件でも開ける状態にします。画面が一度表示されたという説明だけと、受入確認が終わった記録を区別します。

2. 納品先を入力

   受入状態：受入確認済み。記録の根拠：受入確認記録あり。

   入力する仕事の受入記録がある状態です。これは記録された当該単位についての確認で、別の連携や未確認の条件まで保証するものではありません。

3. 数量の入力

   受入状態：受入未完了。記録の根拠：下書き確認中・受入記録なし。

   下書きを見ている段階です。どこまで確認したかを作業状況として伝えられますが、受入完了の半件や一件へ置き換えません。

4. 受付内容の確認表示

   受入状態：受入未完了。記録の根拠：未着手。

   この単位の着手前という記録です。誰が何をそろえると開始できるかを聞きます。他の単位や、すべての開発工程が未実施という意味には広げません。

とくに数量入力については、数量の入力は確認中で、受入完了とはしないという扱いです。「担当者が頑張っている」「もう少しでできる」という見通しと、受入条件を満たしたという記録は分けます。作業中の情報も必要ですが、二件を完了と数えた根拠は受入記録にあります。

この教材には、個々の受入条件の文面や確認者の名前まではありません。現場では、開発側に「何の条件を、誰が、どの版で確認した記録ですか」と対応する記録を示してもらいます。四つの単位名だけから、存在しない試験手順や合否基準を補いません。

図で、受入済み・確認中・未定義を分ける

見る前の問い：報告の50％は、注文受付に関するどの仕事の、何が終わった数字でしょうか。図では、四つの具体的な単位と受入状態を見ます。配送連携は別の範囲として、線引きを保ったまま読みます。

解説図を原寸で見る

図から読む判断：受入記録のある二件だけを四件の分子へ入れるので、受入完了件数率は50％です。確認中と未着手は、ともに受入完了へ数えませんが、同じ作業状況ではありません。予定の三件と実際の二件の違いは、この受注画面の同じ報告時点に限って読みます。

次の行動：数量入力では、残る確認内容と次の確認予定を聞きます。未着手の確認表示では、着手に必要な前提と担当を聞きます。配送連携は別に範囲と受入条件を決める話へ戻します。四件の図を見ただけで、受付業務全体が半分使えるとは判断しません。

予定三件と実際二件は、同じ条件で比べる

予定との差を見るときも、分母、受入の条件、報告時点をそろえます。この例の同じ架空第2週末には、受入完了の予定が3件あり、その割合は3/4=75%です。実際は受入確認済み二件でした。

予定三件の内訳は、この教材に記録されていません。「予定の三件目は数量入力だった」と決め付けず、予定表と単位を対応させてもらいます。数量入力が確認中という事実は分かりますが、それが予定から外れた原因や唯一の対象だとは、今の記録だけでは言えません。

件数の違いと、納期への影響を分ける

同じ分母で予定の件数へ達していないことは、追加で確認すべき手がかりです。ただし、割合の差だけから何日遅れるかは計算できません。残る仕事の大きさ、必要な確認、着手条件、他の仕事とのつながり、担当者の予定が必要です。

例えば、受入を待つ作業が配送連携の開始条件になっているか、独立して進められるかを開発側へ聞きます。これは確認する問いで、この例で依存関係が確定しているわけではありません。「まだ二件あるから、これまでと同じ時間でもう半分」とも見積もれません。一件の工数や難しさが同じとは限らないためです。

開発側が使った作業時間も補足になりますが、使った時間だけで受入確認が終わるわけではありません。情報処理学会の論考「エンタープライズ領域のアジャイル開発の課題」の2.3節も、作業項目の進捗の主観性や、消費工数を指標とする際の限界を論じています。本稿では、その観点を、割合と確認済みの記録を分けるために参照しています。すべての案件の管理方法を一つに決める根拠ではありません。

配送連携と、まだ分からないことを混ぜない

配送連携が未定義なのに、受注画面の四件へ勝手に「配送連携一件」を加えて、全体の割合を作りません。仕事の切り方も受入条件もそろっていないためです。また、値がないことを「進捗ゼロ」「問題なし」とも解釈しません。最初に、どの情報をどこへ渡す仕事か、何をもって確認済みとするか、誰が確かめるかを開発側と整理します。

この報告だけでは決められないこと

二つの記録とも、実作業時間は未確認、残り時間は未確認、納期への影響は未確認です。件数から時間や納期を埋めず、残作業と前提を開発側へ確認します。

不具合件数は未確認、全プロジェクトの進捗率は未確認、全範囲に対する発注側の受入は未確認です。不具合がゼロ、全体が50％、全範囲が承認済みという記録ではありません。分からない項目を増やして終わるのではなく、今回必要な判断に関係する情報を、それぞれ説明できる相手へ聞きます。

受注画面の受入件数を示す数字だけでは、その画面を本番で利用してよいかも決まりません。実際の案件で必要な業務確認や運用上の条件は、適用する計画と合意に沿って別に確かめます。この教材には本番利用の可否を判定した結果はありません。

開発側へ何を聞き、返答でどう動くか

報告へ「もっと正確な進捗率を」とだけ返すと、数字の説明が増えても業務の判断に届かないことがあります。まず直近の報告を開き、対象の四件、受入条件、根拠の記録、予定した対象を対応させてもらいます。

1. 50％の定義を確認する。「この割合は、受注画面の四つの受入単位だけが対象ですか。何を終えると完了へ数えますか。いつ時点の報告ですか」と聞きます。今回の読み方と開発側の定義が違えば、先に定義の違いを解消します。
2. 二件の受入記録を開く。「注文番号の表示と納品先の入力は、どの条件を誰が確認した記録ですか」と聞きます。単位名と記録を対応させ、実装完了だけの報告を受入済みと読み替えないようにします。
3. 確認中と未着手を分けて聞く。数量入力では残る確認点、答える担当、次の確認予定を聞きます。確認表示では着手に必要な資料や先行する仕事、担当を聞きます。この時点で日付や担当が不明なら、誰がいつまでに明らかにするかを相談します。
4. 予定の三件と影響を対応させる。どの三件を終える予定だったか、受入を終えていない対象は何か、残る仕事とつながるかを確認します。開発側の見通しに必要な前提と、まだ確かめていないことも分けてもらいます。
5. 配送連携を別に定義する。連携する仕事の範囲、数える単位、受入条件、確認する役割を整理します。今の四件の割合を、そのまま全体へ引き継ぎません。

返答がそろう・一部だけ・そろわないで、次を変える

• 条件と受入記録がそろったら

  対象、時点、条件、確認記録を同じ単位へ結びます。根拠のある受入完了件数を読み、未完了の対象と次の確認予定を追います。将来新しく一件の受入確認を終えた場合も、その記録と報告時点を残してから件数へ反映します。この例で追加の受入が済んだ事実はありません。

• 一部の記録だけ確認できたら

  受入を確認できる部分と、条件や根拠が残る部分を明示します。未確認の単位まで完了へ広げず、開発側と確認者へ残る資料や問いを返します。報告の数字と根拠が合わない場合は、対象、定義、時点のどこが違うかを確かめ、修正が必要な報告を明らかにします。

• 定義や根拠が分からないままなら

  その割合から全体の完成や納期を判断することは保留します。分母、完了条件、記録を開ける担当、次に説明を受ける時点を確認します。管理表を全部作り直す前に、まず直近の四件の報告から根拠へ戻れるようにします。

受入の記録を開けたことと、残る仕事の納期見通しが確かになったことも別です。見通しを得るには、残作業と依存する前提を説明してもらい、発注側が必要な業務上の時点と照らして相談します。報告を受けた業務担当が、未確認の時間や影響を推測して埋める必要はありません。

次回の報告では、前の基準と確認結果を残す

次回は割合の変化だけを見るのではなく、どの受入記録が増え、どの問いが残ったかを見ます。前回と同じ範囲・単位・条件で数えているなら、追加の確認結果とその時点を対応させられます。条件が違う場合は、単純な増減で進み具合を判断しません。

1. 前回の報告を残す。受注画面四単位、予定三件、実際二件、架空第2週末という基準と、対応する記録を保ちます。後の説明に合わせて元の予定を消しません。
2. 新しい確認を同じ単位へ戻す。受入確認の結果、残る指摘、次に確認する担当と予定を更新します。作業中の説明だけなら作業状況を更新し、受入完了の件数とは分けます。
3. 範囲や条件が変わったら、変更を見えるようにする。追加・削除した対象、変更前後の条件、変更を決めた経緯と適用時点を記録します。前と後の割合が同じ数字でも、同じ意味とは限りません。この架空の受注画面記録には範囲変更なしとありますが、配送連携は変更の有無も未確認です。
4. 予定を見直すなら、残作業と前提を添える。新しい確認日や進め方を相談する際は、何が残り、どの担当・資料・先行作業が必要かを示してもらいます。過去の予定と新しい見通しを区別して残します。

数える仕事の単位自体を整理する必要がある場合は、WBSで作業・担当・完了条件を決める方法が参考になります。担当者や開始条件を含む日程を組み直す場合は、システム導入のスケジュールを作る方法へ進めます。この記事では、受け取った割合を根拠へ戻して読むことに範囲を絞っています。

まとめ：直近の50％を、四件の受入記録へ戻す

印刷会社の例で50％と言えるのは、決めた四単位のうち二件の受入確認が終わったという範囲です。数量入力の下書き確認中と、確認表示の未着手は、次に確かめる内容が違います。予定の三件と比べる際も、同じ時点・対象・条件で見て、予定した対象の内訳と残作業を聞きます。

配送連携は範囲と受入条件が未定なので、四件の分母へ混ぜません。件数の割合を、残り時間、納期への影響、不具合の少なさ、全体の承認へ読み替えることもできません。分からないことは、判断に必要な質問と説明できる相手へ結びます。