【2026年8月版】

問題を定義する技術（第3回）― 定義を運用し、要件定義へ渡す

公開日: 2026/08/11
読了時間: 約 33分

マネジメント IT産業

第1回と第2回で、問題は書けた。

ただし最初に書いた問題定義は、限られた情報から作った仮説である。第3回では、調査に応じて定義を更新する手順を扱い、要件定義へ渡すまでを示す。

1. 定義の運用

問題定義は一度書いて終わる文書ではない。調査に応じて更新し、要件定義へ渡すまでの扱いが決まっている。

1.1 定義は仮説として扱う

最初の問題定義は、限られた情報から作った仮説である。ユーザー調査を行えば、想定していた利用者とは別の人が最も困っていると分かることがある。業務を観察すれば、担当者が説明した手順と実際の手順が違っていることが出てくる。

観察の対象になるのは、説明された業務ではなく実際に行われている業務のほうである。どこで待つか、何を転記するか、正式手順をどこで迂回するか、どの情報を信用していないか。この記録が、会議室で書いた問題文を書き換えることになる。

System Dynamics の世界でも、問題定義は最重要とされながら方法論は薄い。Mashayekhi と Ghili の論文が挙げているのは、Sterman の1000ページを超える教科書のうち問題定義に割かれているのが5ページだという事実である。Richmond の本でも10ページに満たず、当時の System Dynamics Review には過去10年間この主題の論文が一本もなかった。彼らの説明では、その理由の一つは問題定義が反復的な作業だという点にある。実務では、問題定義はモデリングの後続ステップから得た情報にもとづいて完成する。

1.2 解く価値と規模を測る

解く価値があるかどうかの判定は、実務でも整理されている。英国司法省が2020年に公開した Discovery の実践記では、次の七つの問いを使っている。

問題は存在するか
解く価値はあるか
自分たちに解決できるか
緊急か
広く発生しているか
利用者は自分で解決してしまっているか
他の誰かがすでに解決しているか

1から5がはいで、6と7がいいえであれば、解く価値のある問題をおそらく見つけたことになる、という判定になっている。6と7を確かめずに開発へ進めば、すでにある代替手段と競合するものを作ることになる。

この判定には規模の見積もりが伴う。GOV.UK の Discovery のページも、問題を解くことの価値を定量化するよう求めている。測る軸は、影響を受ける人数、発生件数、一件あたりの損失、継続期間の四つになる。操作に30秒余計にかかるという事実だけでは小さく見えるが、100万人が年20回行う操作であれば、失われる時間は年間およそ16万7千時間になる。

ただし件数だけで決まるわけではない。年に一度しか起きなくても、一件の失敗が重大事故になる業務は優先度が高い。四軸に加えて、最悪の場合どこまで被害が及ぶか、何もしなければ問題は拡大するのかを押さえる。

1.3 問題定義書に書く項目

問題定義では、一枚の巨大な文書を作る必要はない。重要なのは、何を問題と判断したのか、その判断を何が裏付け、どこまでが未確認で、その結果として次に何をするのかを追跡できることである。

そのため、成果物を「問題そのもの」「未確定事項」「意思決定」の三つに分けて管理する。これまでの議論をまとめると、以下の項目に収束できるだろう。

1.3.1 三つのグループ

問題そのもの

項目	内容
現状（As-is）	現在の値、手順、発生頻度
望ましい状態（To-be）	手段を含まない形で書いた到達点
差（Gap）と、放置できない理由	誰のどのような差を、なぜ今解くのか
根拠	差を裏付ける観察と数値
境界	対象と対象外
当事者	影響を受ける人、利益を得る人、負担する人、決定権を持つ人
時間の変化	主要な指標の推移
制約	法令、契約、期限、安全性

未確定事項

項目	内容
原因の仮説	支持する事実、反証、検証の方法
未検証の前提	慣習、思い込み、過去の判断など、変えられないと思われているだけの条件
未解決の問い	次の調査で明らかにすること

意思決定

項目	内容
成功指標	望ましい状態を何で観測するか
次の行動	追加調査、業務変更、試行、システム化、中止のいずれか

このうち対象外の範囲、政策や事業の意図、制約、利用者については、GOV.UK の Discovery のページも調査中に理解しておく対象として挙げている。同ページは「問題の捉え直しには、何が問題に含まれないかを合意することも含まれる」と書き、成功をどう測るかを決めることも求めている。

1.3.2 制約と未検証の前提を分ける

制約と未検証の前提を別の表へ置くのは、扱いが違うためである。「既存システムは変更できない」を制約の欄へ書いた時点で、それは確定した条件として扱われ、解決策の候補が狭まる。そう決めた文書や決裁を示せないのであれば、未検証の前提の側へ移し、確認する対象として残す。

第2回では、制約を絶対的制約、選択された制約、交渉可能な制約、未検証の前提の四つに分けた。この表では、前の三つを制約の欄へ、最後の一つを未検証の前提の欄へ置く。法令や安全性は動かせないが、予算や期限は経営判断で再交渉でき、契約や部署間ルールは調整の対象に載る。制約の欄へまとめて書くとしても、どれがどの分類なのかは併記しておく。

制約を問題定義の成果物に含めること自体は、システム工学の側でも同じである。SEBoK の System Concept Definition は、Stakeholder Needs Definition について、主要な関係者からの入力、上位の要求、そしてライフサイクル概念・駆動要因・制約・リスクの分析にもとづいて、統合されたニーズを識別すると書いている。制約は解決策を設計する段階で出てくるものではなく、ニーズを固める段階の入力として扱われている。

書き出す作業そのものにも意味がある。SEBoK の Foundations of Systems Engineering は、状況に応じて手法を選ぶ実践的な取り組みの例として境界批判（boundary critique）を挙げ、それが「立場の異なる関係者が前提と制約を明示できるようにする」ものだと書いている。前提は、書き出さなければ各人の頭の中に残ったままになる。

1.3.3 境界は二段構えで書く

境界の欄には、対象と対象外の二つを書く。対象だけを書くと、書かれていない範囲が「まだ検討していない」のか「検討したうえで外した」のかを区別できない。後から関係者が増えたときに、この区別がないと同じ議論を繰り返すことになる。

ただし対象外を決めるには、その前に問題の全体像を把握している必要がある。把握しないまま範囲を狭めれば、それは対象外の決定ではなく、単に見ていない範囲になる。

SEBoK の Identifying and Understanding Problems and Opportunities は、この二段構えを求めている。問題の文脈には、費用、実現までの期間、使用期間、運用上の有効性について境界を設けるとしたうえで、「一般に、問題の全体像と、次に取り組むと合意した問題の版の両方を記述する」と書いている。全体像を書き、そのうえで今回の版を書く、という順序である。

1.3.4 成功指標と望ましい状態を分ける

望ましい状態と成功指標は、同じことを言っているように見えて役割が違う。望ましい状態は到達点を述べ、成功指標はその到達を何で確かめるかを述べる。

「標準案件の90%を翌営業日までに処理する」は望ましい状態である。これに対する成功指標は「申請の受付から完了までの所要時間の90パーセンタイル値」になる。前者は関係者との合意の対象で、後者は測定の設計になる。

分けておかないと、測れる範囲まで望ましい状態を縮めてしまう。既存のログから所要時間しか取れない場合に、望ましい状態を「処理時間を短縮する」と書き換えれば、利用者が本当に困っている待ち時間の見通しは記述から消える。望ましい状態は測定の都合と切り離して書き、測り方は成功指標の側で考える。

測定できない指標を置いた場合も、それは問題定義の欠陥ではない。何をどう測るかを決める作業が残っている、という状態を示している。

1.4 記入例

実際に書くと、次のようになる。第1回で扱った「Excel 管理をやめて顧客管理システムを導入する必要がある」という依頼を、三つの表へ落としたものである。

問題そのもの

項目	記入例
現状（As-is）	営業担当者が顧客との接触履歴を個別の Excel へ記録している。担当変更時の引き継ぎに平均3営業日かかっている
望ましい状態（To-be）	担当者が変わっても、必要な顧客対応履歴を当日中に確認できる
差（Gap）と、放置できない理由	引き継ぎ期間中は顧客への回答が遅れ、契約更新の商談が停止する
根拠	過去1年の担当変更18件の引き継ぎ実績、営業部門への聞き取り
境界	対象は法人営業部の顧客接触履歴。受注後の保守対応履歴は今回は扱わない
当事者	営業担当者、後任の担当者、営業管理職、顧客
時間の変化	担当変更の件数が、組織改編のあった昨年度から年8件へ倍増
制約	顧客の個人情報を扱うため、社外サービスへの保存は情報システム部の審査が要る

未確定事項

項目	記入例
原因の仮説	記録の形式が統一されていないため転記に時間がかかる。支持する事実は Excel の様式が担当者ごとに違うこと。検証は、様式を揃えた場合の所要時間を測る
未検証の前提	「履歴は担当者が管理するもの」という運用。決裁文書は見つかっていない
未解決の問い	引き継ぎの3営業日のうち、転記作業と口頭説明のどちらが長いか

意思決定

項目	記入例
成功指標	担当変更から後任が過去の接触履歴を参照できるまでの経過時間
次の行動	引き継ぎ作業の内訳を1か月測ってから、システム化の要否を判断する

この例で確かめてほしいのは、三つの表のどこにも解決策が書かれていない点である。SaaS の導入も共有文書への移行も、次の行動として測定を終えたあとに比較する。現時点で書けるのは、測定の対象と判断の時期までになる。

1.5 書けたかどうかを判断する

三つの表を一文へまとめておくと、会議や依頼のやり取りでそのまま使える。文型は、1.3 の項目と、GOV.UK が Discovery のユーザー調査について書いているページの二つから組み立てる。

GOV.UK は、調査で明らかにする対象として、利用者が誰か、何をしようとしているか、現在それをどう行っているか、どのような支障や不満があるかを挙げている。この四つを前半に置き、後半へ 1.3 の項目を続けると、次の形になる。

「［対象者］は［状況］において［達成したいこと］を行おうとしているが、［観測された障害］によって［具体的な影響］を受けている。現在は［現状値］であり、［期限・範囲］までに［望ましい状態］を実現する必要がある。ただし、原因と解決策については未確定である」

後半の枠は 1.3 の表と一対一で対応する。対象者は当事者の欄、観測された障害と現状値は現状（As-is）と根拠の欄、具体的な影響は差（Gap）を放置できない理由の欄、期限・範囲は境界と制約の欄、望ましい状態は同名の欄にあたる。表を埋めてあれば、書き写すだけで一文になる。

末尾の一文を残すかどうかで、その後の扱いが変わってくる。原因も解決策も、この時点ではまだ仮説だからである。

1.4 の記入例を、この形へ当てはめる。

法人営業部の後任担当者は、顧客を引き継いだ直後に、過去の接触履歴を確認しようとしているが、履歴が前任者個人の Excel にあることによって、確認までに平均3営業日を要している。現在は担当変更が年8件発生しており、来期の組織改編までに、担当が変わっても必要な顧客対応履歴を当日中に確認できる状態を実現する必要がある。ただし、原因と解決策については未確定である。

この一文には、顧客管理システムも SaaS も出てこない。出てくるのは、誰が、いつ、何をしようとして、どれだけ待たされているかである。ここに製品名が入っていれば、まだ依頼を書き写した段階にとどまっていることになる。

書けたかどうかの判断は、文章の出来ではなく、その後に起きた変化のほうに現れる。

変化	確認すること
議論	関係者が同じ問題について話せるようになったか
分離	症状と原因と解決策が別々に扱われているか
特定	利用者と影響範囲が定まり、未検証の前提が見えているか
選択肢	解決策の候補が増え、開発対象が縮小したか
測定	成功を測る指標と、次に調べる問いが決まったか
中止	解く価値のない問題を止められたか

記入例をこの六つで点検すると、次のようになる。

変化	記入例での状態
議論	営業部門と情報システム部が、引き継ぎの所要時間という同じ数字を見て話せる
分離	様式が統一されていないことは原因の仮説として別の表にあり、問題そのものと混ざっていない
特定	対象は法人営業部、対象外は保守対応履歴と決まり、「履歴は担当者が管理するもの」という前提が未検証として残っている
選択肢	様式の統一、共有文書への移行、SaaS の導入が候補として並び、まだ一つに絞られていない
測定	履歴を参照できるまでの経過時間を測ると決まり、転記と口頭説明のどちらが長いかが次の問いになっている
中止	測定の結果、引き継ぎの大半が口頭説明であれば、記録の仕組みを作る話は取り下げられる

未確定の欄が埋まっていることを、書けていない状態と取り違えないほうがよい。最後の行のように、測ってみたら開発が不要になる可能性を残しているのは、問題定義が働いている状態である。

良い問題定義は、チームを一つの解決策へ早く収束させるとは限らない。むしろ一度選択肢を広げ、何を解くべきかについて合意したあとで解決策を狭めていく。問題を定義する前に解決策を発散させれば、間違った問いへの回答が大量に出てくることになる。

2. 要件定義・ユースケースとの関係

2.1 要件定義との役割の違い

問題定義と要件定義は、名前が近いわりに役割が違う。

項目	問題定義	要件定義
中心となる問い	何を変える必要があるか	解決策が何を満たすべきか
対象	現実、利用者、業務、組織	システムやサービス
主な成果	現状、望ましい状態、差、重要性	機能、品質、制約、データ
解決策	原則として確定しない	選択した解決策を具体化する
終了可能性	何も作らない結論を含む	通常は実現対象が存在する
失敗時の結果	間違った問題を選ぶ	解決策が要求を満たさない

要件定義が扱うのは、選んだ解決策が満たすべき条件である。どの問題を解くかは、その前の工程で決まっている。要件の一つひとつについて、それがどの問題を解決するために存在するのかを答えられれば、問題定義との対応が取れていることになる。

この順序は、IPA のユーザのための要件定義ガイド第2版にも入っている。ビジネス要求の獲得は、現状把握、問題・課題抽出、ゴール抽出、手段抽出という順で構成されている。要求を集める前に、現状と問題を見る順序になっている。

2.2 ユースケースを書ける段階

ユースケースにも同じ順序が当てはまる。ユースケースは、そこに書かれた業務が今後も続くことを前提に含んでいる。問題定義より先に書けば、現在の業務と想定したシステムの境界が、その時点で固定される。ユースケースは問題を発見する道具にはなるが、問題定義の代わりにはならない。

順序は次のようになる。

問題を定義する
業務の廃止・縮小・再設計を検討する
システムが担う範囲を決める
残った利用者目的をユースケースとして書く
そこから要件へ落とす

ユースケースを書けるのは、四番目まで来た段階である。二番目でその業務を残すと決まり、三番目でシステムが担う範囲が決まっていれば、ユースケースはその範囲の中で利用者が何を達成するかを記述できる。

2.3 問題定義の抜けを実装前に見つける五つの問い

次の五つは、本来であれば問題定義の段階で答えが出ているはずの内容である。要件定義より前に済んでいるはずのものなので、開発チームが実装の直前に確認を請け負うべき項目ではない。

それでも確認せざるを得ないのは、問題定義を経ないまま要件が渡ってくることがあるためである。責務の範囲を越えた作業になるが、ここで気づかなければ、抜けたまま実装することになる。答えられない項目が見つかったら、実装を進める前に、問題が未定義であるとして発注元や利用部門へ差し戻す。

問い	該当するときに疑うもの
システムを作ることを禁じられても、その問題は残るか	残らないなら問題は技術側にない
技術で隠そうとしている組織上の問題はないか	責任分担や合意の欠落
制度を変更したら、この機能は不要にならないか	規程の複雑さを実装で吸収している
データモデルで吸収しようとしている意味の不一致はないか	用語定義の未合意
柔軟なシステムが必要なのか、業務ルールが未整理なだけか	要件の曖昧さを可変性で代替している

差し戻しを受けた発注元や利用部門が問題定義をやり直すと、担当部門の権限では決着しない問題が出てくる場合がある。そうなれば組織の設計を変える判断になるため、そこから先は経営が引き取ることもある。

このとき、技術課題として開発チームへ渡されていたものが、実際には経営が決める課題だったと判明したことになる。開発チームが差し戻さなければ、その課題は実装として吸収され、経営まで届かないままになりかねない。

まとめ ― 開発コストの低下と問題選定の重み

ソフトウェアを作る能力は上がり続けている。クラウド、OSS、ローコード、生成AI、コーディングエージェントによって、以前より速く、大量に、複雑なものを作れるようになった。作るコストが下がるほど、作る前に考える必要はないという感覚も強くなりやすい。

ただし、下がったのは実装コストだけである。利用者が覚えるコスト、データを維持するコスト、権限を管理するコスト、障害へ対応するコスト、セキュリティを保つコスト、制度変更へ追従するコスト、古い仕組みを廃止するコスト。英国政府のレガシーITガイダンスは、古い資産を維持し続けること自体がセキュリティとコストの負担になると指摘している。廃止も工程として残る。GOV.UK はサービスの廃止を独立した段階として扱い、構築時と同じように利用者のニーズを検討し、そのニーズが廃止後にどう満たされるかを考えるよう求めている。

簡単に作れることは、作る価値があることとは別の話になる。解決策をいくらでも生産できるようになった以上、成果を決めるのは実装の速さではなく、何を問題として選んだかである。