要件定義の「進捗率」という言葉の危険性
――初級SEから知っておきたい、その数字が信じられない理由
進捗率は上がっているのに、要件定義が収束する気配がない
こんな経験はないでしょうか。WBS上のタスクは順調に消化されている。ヒアリングも予定通り5回のうち3回終わった。進捗報告では「60%」と伝えている。
それなのに、要件定義がいつまで経っても収束する気配がない。新しい要求が次々と出てくる。確認したはずの内容に、後から「実は」という話が付け加わる。ゴールが見えないまま、進捗率だけが積み上がっていく。
この違和感の正体は、進捗率そのものの数字ではなく、その数字が何を基準に計算されているか、という点にあります。
先ほどの例がまさにこれです。「WBSで消化したタスク数÷全タスク数」や「全5回のヒアリングのうち、3回消化した」という発想で進捗を捉えているなら、少し立ち止まって考えていただきたいことがあります。この発想は、経験を積んでからでは、かえって手放しにくくなります。初級SEのうちから、進捗というものの本質を捉え直しておくことには意味があります。
その数字は、本当に「要件定義がどこまで進んだか」を表しているでしょうか。
プロジェクトマネージャーから「要件定義、今どのくらい進んでいますか」と聞かれたとき、「大体7割くらいです」「あと少しで終わります」と答えることはできても、その基準自体が実態とズレていることに、気づいていないことが多いのではないでしょうか。
これは、要件定義というフェーズに特有の問題です。コーディングであれば、実装すべき機能一覧に対して「完了した機能の数」を数えれば、進捗はある程度機械的に算出できます。テストであれば、テストケースの消化数を数えれば進捗が見えます。
しかし要件定義には、この「数えられる単位」が存在しません。「ヒアリングを何回やったか」を数えることはできますが、それは進捗の指標にはなりません。ヒアリングを10回やっても、暗黙知が引き出せていなければ、実質的な完成度は低いままです。第1回・第3回でお伝えしてきたとおり、量をこなすことと、質が伴っていることは別の話です。
今回は、この「要件定義の進捗をどう測るか」というテーマについて、考えていきます。
なぜ「進捗率」という言葉自体が、危険なのか
まず、根本的な問題を整理します。「進捗率」という言葉には、暗黙の前提が含まれています。それは、「全体量が確定していて、そのうちどれだけ終わったかを測る」という前提です。
コーディングであれば、実装すべき機能の一覧が(ある程度)確定した状態からスタートします。「全体」が見えているからこそ、「進捗」が意味を持ちます。
しかし要件定義は、その「全体」自体が、作業を進めながら明らかになっていくプロセスです。第3回でお伝えした暗黙知の話を思い出してください。ヒアリングを重ねる中で、これまで見えていなかった要求や制約が新たに発見されることがあります。それだけでなく、当初想定していたスコープそのものが広がることもあります。「この業務は対象外だと思っていたが、実は密接に関連していた」という形で、スコープの境界線が動くことは珍しくありません。
ここで「それはスコープ外だ」と安易に切り捨ててしまうと、大きな見落としにつながることがあります。本来対応すべき業務や制約を、スコープの外側に押し出してしまうことで、後になって「対応していなかった」という致命的な欠落として表面化するのです。つまり、要件定義における「全体」は、最初から確定しているものではなく、進めながら輪郭がはっきりしていくものです。
「全体が分からないのに、進捗率を語る」という行為には、本質的な矛盾があります。分母が変動し続けるのに、分子だけを数えて「70%」と言っているようなものです。
この矛盾を放置したまま「進捗率」という言葉を使い続けると、実態とかけ離れた数字が独り歩きします。「70%終わっている」と報告されたプロジェクトが、実際には根本的な要求の見落としを抱えたまま進んでいた、というケースは珍しくありません。冒頭の「進捗率は上がっているのに収束しない」という違和感は、まさにこの矛盾が表面化した状態です。
「作業量」と「充足度」は、比例しません
ここで、ひとつ重要な区別を導入します。「作業量ベースの進捗」と「充足度ベースの進捗」という区別です。
作業量ベースの進捗とは、「ヒアリングを何回やったか」「要件定義書に何ページ書いたか」「打ち合わせに何時間費やしたか」といった、投入した労力の量を基準にした進捗です。冒頭で触れた「WBSのタスク消化数」や「ヒアリング回数」は、まさにこれにあたります。
充足度ベースの進捗とは、「必要な要件がどれだけ揃っているか」「その要件がどれだけ品質基準を満たしているか」という、成果物の完成度を基準にした進捗です。
この充足度を突き詰めていくと、ひとつの限界に行き着きます。
「必要な要求は、すべてで尽くしたか」
この問いに、自信を持って答えられる人を、私は見たことがありません。ベテランであっても、経験豊富なプロジェクトマネージャーであっても、答えられないのです。
それは、聞く側だけの問題ではありません。要求を出す側、つまり顧客にとっても同じです。「必要な要求は、これですべてですか」と尋ねたとき、顧客が誠実に出せる最大限の回答は、「現時点では、これですべてだと思います」です。「現時点では」という留保を外すことは、顧客にもできません。第1回でお伝えした投資顧問会社の例のように、「全部です」という言葉が、後から覆ることは珍しくないからです。
これは、個人の能力の問題ではありません。要件定義そのものが、長年抱え続けてきた、いまだ解決されていない最大の問題です。「進捗率が測れない」という、この記事全体を通じて扱っている問題も、突き詰めればこの一点に集約されます。
多くの現場で語られる「進捗率」は、実は作業量ベースのものです。「今週、3回ヒアリングを行ったので、進んでいます」という報告は、作業量の話であって、充足度の話ではありません。
問題は、作業量と充足度が必ずしも比例しないということです。第4回でお伝えしたように、初級SEのヒアリングは、時間をかけても重要な情報を引き出せていないことがあります。作業量は増えているのに、充足度はほとんど変わっていない、という状態が起こり得ます。
逆に、経験豊富なSEが的確な質問をすれば、短時間のヒアリングでも充足度が大きく上がることがあります。
プロジェクトマネージャーが本当に知りたいのは、「どれだけ作業したか」ではなく、「どれだけ完成に近づいたか」のはずです。しかし現場で報告されているのは、多くの場合、前者です。このズレが問題の根っこにあります。
充足度を測るための、素材はすでにある
では、充足度を測ることは可能なのでしょうか。
これまでの回でお伝えしてきた内容を振り返ると、実はその素材はすでに揃っています。
第6回「要件の品質とは何か？」・第7回「その要件、テストできますか？」でお伝えした、要件の品質を測る観点——網羅性・一貫性・検証可能性・合意形成、あるいはBABOK V3・IEEE 29148が定義する品質特性——は、個々の要件が「良い状態」にあるかどうかを判定する基準でした。
この基準を、個々の要件に対して適用し、その結果を積み上げていけば、要件定義書全体の充足度を測ることができるはずです。
たとえば、以下のような指標が考えられます。
- 要件定義書に含まれる要件のうち、検証可能性の基準を満たしていない(曖昧な表現を含む)要件が何件あるか
- 洗い出すべきステークホルダーのうち、まだヒアリングできていない人が何人いるか
- 抽出された要求のうち、要件レベルまで具体化されていないものが何件あるか
- 例外シナリオが定義されていない機能要件が何件あるか
これらは、いずれも「数えられる」指標です。数えられるということは、集計できるということであり、集計できれば、それを何らかの形でスコア化できます。
「なんとなく7割」という感覚的な報告ではなく、「網羅性の指標がこのレベル、検証可能性の指標がこのレベル」という、具体的な内訳を示すことができれば、進捗の議論は大きく変わります。
ただし、これらの指標がどれだけ充実しても、「必要な要求がすべて出尽くしたか」という根本の問いには、完全には答えられません。指標は、「今、見えている範囲での充足度」を測るものであり、「見えていない要求がまだ存在するかどうか」までは測れないからです。この限界を認識した上で、指標をどう扱うべきかを、次のセクションで考えます。
経験を積めば、全体量は見えるようになる？
ここで、視点を変えてみます。経験を積むことによって、要件定義の「全体量」そのものが見えるようになるのか、という問いです。
私自身、これまで数多くの要件定義を経験してきました。その経験のおかげで、あるプロジェクトの話を聞いた段階で、「このくらいの期間、このくらいのヒアリング回数で終えられるだろう」というおおよその目安をつけることができます。
しかし、正直に言えば、この目安は完全ではありません。
開発規模が10人月に満たないような小さな案件であれば、この目安が大きく外れることはあまりありません。関係者の数も限られており、業務の範囲も見通しやすいため、経験に基づく予測が比較的よく当たります。
しかし、開発規模がそれ以上になってくると、話は変わってきます。ブレ幅が大きくなるのです。「大体このくらい」という予測が、実際には倍近くかかることもあれば、逆に予想より早く収束することもあります。
では、開発規模が大きくなるほどブレ幅が大きくなるのだとすれば、開発規模こそが要件定義の全体量を決める主な要因なのでしょうか。
いえ、そうではありません。
開発規模は、確かにひとつの目安にはなります。関わるステークホルダーの数、業務プロセスの複雑さ、システムが影響を及ぼす範囲——これらは規模が大きくなるほど増える傾向にあります。しかし、規模だけでは説明できないブレが、現場には必ず存在します。
同じくらいの規模のプロジェクトでも、驚くほどスムーズに要件が固まることもあれば、いつまで経っても収束しないこともあります。この違いを生んでいるのは、規模という数字では捉えきれない要因です。
ここで思い出していただきたいのは、要件定義は人と人の作業だということです。
どれだけ経験を積んでも、規模という指標をどれだけ精緻に分析しても、要件定義の全体量は、最終的には「誰が、どういう組織で、どういう関係性の中で」行われるかに左右されます。担当者の説明力、組織内の合意形成のスピード、キーパーソンの多忙さ、部門間の力関係——こうした、数値化しにくい人的要因が、全体量を大きく動かします。
経験は、規模から大まかな予測を立てる精度を上げてくれます。しかし、人と人が関わる作業である以上、その予測には常に限界があります。この限界を「経験不足」のせいにしてしまうと、いつまで経っても「経験を積めば読めるようになるはずだ」という期待から抜け出せません。そうではなく、「全体量は、事前には正確に読めないものだ」という前提に立つことが、これから述べる「動く指標」という発想につながっていきます。
それでも残る、難しさ
経験による目安はつけられても、要件定義の「全体」は、事前には確定しません。この前提に立つと、充足度を測るための指標にも、正直に向き合わなければならない難しさがいくつか残っていることが見えてきます。
① 「全体」が、作業を進める中で更新され続ける
充足度を測るためには、「何が揃えば完全と言えるか」という基準が必要です。しかし、その基準自体が、ヒアリングを進める中で更新され続けます。ステークホルダーの洗い出しが進むほど、確認すべき項目は増えます。第3回「要件定義で抜け漏れが起きる理由」でお伝えした「ステークホルダーの網羅漏れ」が後から発覚すれば、それまで「70%」だと思っていた充足度は、その時点で下方修正されることになります。
これは、充足度を測ることの限界というより、要件定義というプロセスの本質的な性質です。完璧に「全体」を確定させてから充足度を測ろうとすると、いつまでも測定を開始できません。
② 指標の重み付けが必要になる
「曖昧な表現を含む要件が5件ある」という情報だけでは、それが致命的な問題なのか、軽微な問題なのかが分かりません。基幹業務に関わる要件の曖昧さと、些末な補足情報の曖昧さでは、影響度がまったく異なります。
すべての欠落を同じ重みで数えてしまうと、「件数は多いが実質的な影響は小さい」プロジェクトと、「件数は少ないが致命的な欠落を含む」プロジェクトが、同じスコアになってしまう可能性があります。
③ 測定そのものに手間がかかる
第5回でお伝えした「議事録から要求を抽出する」作業と同様に、要件をひとつひとつ品質基準に照らして評価する作業は、地味で時間のかかる作業です。この評価作業自体が、ヒアリングと同じくらいの負荷になってしまっては、本末転倒です。
「動く指標」として使う、という発想
これらの難しさを踏まえると、充足度の指標は「一度確定させて終わり」のものではなく、「プロジェクトの進行とともに更新され続ける、動く指標」として捉える必要があります。
第6回「要件の品質とは何か」でお伝えしたとおり、要件定義書は生きたドキュメントです。同様に、充足度のスコアも、生きた数字として扱うべきです。今日70%だったスコアが、新しいステークホルダーの発見によって明日60%に下がることもあります。これは後退ではなく、むしろ「見えていなかった欠落が可視化された」という前進です。
この発想の転換が重要です。充足度のスコアが下がることを「悪い報告」として捉えるのではなく、「隠れていたリスクが、今、発見された」という健全なシグナルとして捉える。この認識がなければ、充足度を正直に測ること自体が、現場で避けられてしまいます。
「測れない」から「測ろうとしない」への逆転を防ぐ
ここまでお伝えしてきたように、要件定義の進捗を正確に測ることには、いくつもの難しさがあります。しかし、この難しさを理由に「測れないから測らない」という結論に至ってしまうと、第1回でお伝えした「完了の基準がない」という問題に逆戻りしてしまいます。
完璧な指標は存在しません。しかし、不完全であっても、感覚だけに頼るよりは、はるかに客観的な議論ができます。「なんとなく7割」という報告と、「網羅性はこのレベル、検証可能性はこのレベル、まだヒアリングできていないステークホルダーがこれだけいる」という報告では、その後の意思決定の質がまったく変わります。
測ることの難しさと、測ることの価値は、両立します。難しいからこそ、素朴な感覚に頼るのではなく、できる限り客観的な仕組みで補う必要があります。
まとめ
要件定義の進捗率は、コーディングやテストのように単純には測れません。「全体」が事前に確定しないという性質を持つためです。その根底には、「必要な要求が、すべてで尽くしたか」という、誰も自信を持って答えられない限界があります。
WBSのタスク消化数や、ヒアリングの実施回数といった「作業量ベース」の指標は、本来知りたい「充足度ベース」の指標とは別物です。作業量が増えても、充足度が同じように上がるとは限りません。「進捗率が上がっているのに要件定義が収束しない」という違和感は、この2つを混同していることのサインです。
経験を積めば全体量が正確に読めるようになるかというと、そうとも言い切れません。開発規模が大きくなるほど予測のブレ幅は大きくなり、しかも規模だけでは説明できないブレが必ず存在します。要件定義は人と人の作業であり、担当者の説明力や組織内の合意形成のスピードといった数値化しにくい要因が、全体量を大きく動かすからです。
充足度を測るための素材は、これまでの回でお伝えしてきた品質の観点(網羅性・一貫性・検証可能性・合意形成)の中にすでにあります。ただし、「全体」が動き続けること、指標の重み付けが必要なこと、測定自体に手間がかかることなど、いくつかの難しさが残っています。
これらの難しさを踏まえた上で、充足度を「一度確定する数字」ではなく「動き続ける指標」として捉えることが、現実的なアプローチです。スコアが下がることを、後退ではなく「リスクの可視化」として受け止める姿勢が重要です。
この問題に、仕組みで向き合うツールがあります。
AiRee（アイリー）は、要件定義の完了度をスコアで可視化するAIプラットフォームです。「勘」に頼らず、構造的な欠落を検出します。
現在（2026年7月31日まで 2026年8月31にまで延長しました。）、10社限定で無償トライアルを受付中です。
［先行トライアルに応募する →］ ［資料をダウンロードする →］
最後までご覧いただきありがとうございました。
メルマガ登録をしていただければ、コラムが更新された時にお知らせします。
また、AI要件定義プラットフォーム AiRee（アイリー）の情報も合わせてお届けします。