【2026年8月版】

問題を定義する技術（第1回）― 依頼を問題へ戻し、As-is・To-be・Gapで書く

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

要件の整理、設計、実装、リリースという一連の作業は、すべて、解くべき問題を正しく理解しているという前提の上に載っている。前提が外れていても、作業自体は成立してしまう。間違った問題に対して正しい解決策を実装することはできるし、それは技術的には成功として見える。

1. 要件定義の前に、何を決めているのか

要件定義は「作るものが満たすべき条件」を決める工程である。その条件を決めるより前に、何を変えるのかが決まっている必要がある。どの状態を、どの状態へ移すのか。それが定まっていなければ、満たすべき条件も書けない。

この「何を変えるのか」を決める作業が問題定義になる。要件定義が解決策の側を扱うのに対し、問題定義は現実の側を扱う。そして、システムを作らないという結論を含む点でも役割が違う。

これは各人の流儀ではなく、工程として定義されている。英国政府の Service Manual には、サービスを作ると決める前に置く Discovery という段階が定義されている。期間の目安は4〜8週間で、そこに書かれている最初の指示は調査の作法ではない。Discovery の進め方を説明したページは「調査を始める前に、その解決策を吟味し、解くべき問題として捉え直す必要がある」と書いている。作るものが先に決まった状態で相談が来ることを前提にしたうえで、それを一度問題へ戻せ、と国の手引きが定めている。

同じページには、調査の結果として作らないという結論に至る場合のことも書かれている。「調査の結果それが最善だと分かったなら、Discovery の終わりで止めることは失敗ではない。実際には、他へ振り向けたほうがよい時間と費用を節約したことになる」。

同じ順序は、ソフトウェア開発の外側でも標準になっている。システム工学の知識体系 SEBoK は、対象システムを正式に定義する前段に System Concept Definition を置き、そこで問題空間とステークホルダーのニーズを検討するとしている。この段階に含まれるのは Business or Mission Analysis と Stakeholder Needs Definition で、解決策が何を達成すべきかとなぜ必要かを、どう解くかより先に答えることを求めている。

前提を外したまま進めた場合の帰結も決まっている。高性能なシステムを作っても利用者の困りごとは消えず、業務を自動化しても本来なくすべき手続きが温存され、AIを導入しても複雑な規則を処理する層が一つ増えるだけで終わる。

2. 届く相談は問題ではない

では、その問題はどこから手に入るのか。相談を受けた時点で渡されていることは、ほとんどない。届くのは解決策か症状であり、そのどちらも問題そのものではない。

2.1 依頼は解決策として届く

顧客管理システムを作りたい、Excel を Web 化したい、AIチャットボットを導入したい、承認ワークフローを電子化したい、ダッシュボードが欲しい、検索機能を追加したい、データを一元管理したい。システム開発へ届く相談はこうした形をとる。どれも問題ではなく、選ばれた手段である。

「顧客管理システムを作りたい」の背後には、複数の異なる問題があり得る。担当者の退職時に顧客との経緯が失われるのか、複数部署が同じ顧客へ重複して連絡しているのか、経営者が営業状況を把握できないのか。どれが実際の問題かによって対策は変わり、退職時の情報喪失なら引き継ぎ方法の標準化が、重複連絡なら担当責任と連絡ルールの整理が先に来る。

2.2 症状は原因も対象も指さない

現場から上がってくる報告も、依頼と同じ位置にある。入力ミスが多い、問い合わせが減らない、処理が遅い、データが合わない、会議が長い、担当者が忙しい、システムが使いにくい、顧客満足度が低い。これらは何かが起きていることを示す観測事実であって、そのままでは原因も解決対象も定まらない。

「入力ミスが多い」という報告一つを取っても、原因は何通りも考えられる。同じ情報を何度も転記している、項目名の意味が部署ごとに違う、そもそも収集する必要のない項目である。入力チェック機能を強化すれば症状の一部は抑えられるが、転記が不要なら手を入れる先は入力工程の廃止であり、項目の意味が揃っていないなら概念と責任範囲の合意が要る。

2.3 解決法に触れずに書き直す

問題定義の入口は、依頼をそのまま記録するところにある。どのようなシステムが欲しいのか、なぜ今必要だと考えているのか、何が起きたことをきっかけにしたのか、誰が予算と決定権を持っているか。この時点では否定しない。そのうえで、依頼文から解決の方法を述べた部分を消してみる。「AI」「ワークフロー」「ダッシュボード」「一元管理」「自動化」を消したとき、何を変えたいのかが残っていなければ、まだ問題は書かれていない。

たとえば「Excel 管理をやめて顧客管理システムを導入する必要がある」は、そのままでは解決策の宣言になっている。方法を書かずに直すと、次のようになる。営業担当者が顧客との接触履歴を個別の Excel へ記録しているため、担当変更時には平均3営業日の引き継ぎ作業が発生している。担当者が変わっても、必要な顧客対応履歴を当日中に確認できる状態が必要である。ここまで書ければ、SaaS、共有文書、入力ルールの標準化、役割変更のどれもが候補として並ぶ。

「データを一元管理できていない」も同じ扱いになる。一元管理は手段であり、分散していること自体が問題とは限らない。同一顧客の住所が三つの業務システムへ別々に保存されており、変更時にすべて更新されないため、毎月平均27件の誤配送が発生している。こう書けば、物理的なデータ統合のほかに参照方式の変更、変更通知、所有権の明確化も同じ列に並べられる。

手段が残っているかどうかは、次の問いで確かめる。

問い	確かめる対象
それを導入すると何が変わるか	変化の中身が言えるか
その変化を必要とする理由は何か	目的が手段と別に存在するか
その技術の利用を禁止されたら、問題をどう説明するか	記述が技術に依存していないか
同じ結果を別の方法で実現できないか	選択肢が一つに固定されていないか
何も作らないとしたら、代わりに何を変えるか	非システム手段が見えているか

最後の問いに答えられなければ、依頼はまだ解決策のままである。

3. 問題定義より先に解決策が出てくる

3.1 実装を思いついた時点で検討をやめる

組織の問題に対しても IT 技術で対応できることは多い。部署ごとにデータの定義が違うなら、その差を吸収する変換処理を書けばよい。規程が複雑で誰も把握できないなら、検索する仕組みを用意すればよい。誰が承認するか決まらないなら、承認経路を設定で変更できる作りにすればよい。どれも実現できるし、動く。

問題は、これらが問題定義の前に出てくることである。相談を受けた技術者が対応する実装を思いつくと、なぜデータ定義が違うのか、その差を組織として揃えられないのかを調べないまま、その実装をどう作るかへ検討が進んでしまう。

工学の側では、順序が定められている。SEBoK の Business or Mission Analysis は、ISO/IEC/IEEE 15288 に基づく最初の工程として、戦略上の問題・脅威・機会を定義したうえで、それに対処する解決策クラスを識別すると書いている。ここでいう解決策クラスとは、新しいシステムを作る、既存システムを改修する、複数の既存システムを組み合わせる、運用を変更する、といった手段の種類を指す。システムを作ることは、その選択肢の一つとして並ぶ。同じページは、問題空間と解決策空間を分けて扱うとも書いている。

同じページには、既存システムがない場合の進め方として、問題・脅威・機会の観点から「as is（現在の状態）」を記述し、それが解決された状態として「to be（将来の状態）」を記述する、という手順も書かれている。次節で扱う As-is と To-be が、システム工学の標準的な工程にも現れる。

同じ順序は、日本の標準にも入っている。IPA が2026年に公開したシステム構築はビジネス分析から始まるは、JIS X 0170:2025（ISO/IEC/IEEE 15288:2023）の「ビジネス又はミッション分析プロセス」を解説したもので、そのアクティビティを次の順に並べている。

問題又は機会の空間を定義する（分析する・定義する・優先付けする）
ソリューション空間を特徴付ける
代替ソリューションのクラスを評価する

問題を定義し終えてから解決策の空間を検討する、という順序が規格の側で決まっている。同ページは BABOK も紹介し、ニーズを「対処すべき問題または機会」と説明している。

GOV.UK もDiscovery の進め方で「Discovery でサービスを作り始めてはならない」と明記している。この段階で理解しておく対象として挙がっているのは、次の工程へ進んだ場合に直面する制約であり、レガシー技術もその一つとして扱われている。

この順序を守らずに実装へ入ると、システムは動作するものの、部署ごとにデータの定義が違うことも規程が複雑なことも解消されないため、変換処理と検索の仕組みを保守し続けることになる。誰が承認するかを決めないまま設定で運用した場合は、組織のロールが半年や1年ごとの組織変更で入れ替わるたびに、権限と経路を設定し直す作業が発生する。

3.2 問いの立て方で結論が決まる

困っている状況と、解くべき問いは別物である。シャリフ工科大学の Ali N. Mashayekhi と Soheil Ghili が2010年の国際システムダイナミクス学会で発表した問題定義についての論文は、この二つを困りごと（difficulty）と未解明の問い（ambiguity）として区別している。定義はそれぞれ「困りごととは、解消を必要とする困った状況である」「未解明の問いとは、その答えが困りごとの解決に役立つ謎あるいは問いである」となっている。

論文が挙げている例はイランのエネルギー補助金である。困りごとは補助金の支出が極端に大きいことで、これは誰の目にも明らかである。ここで論文が未解明の問いとして挙げるのは「大半の意思決定者が破滅的な結果を承知しているのに、なぜ補助金は廃止されてこなかったのか」である。「補助金を廃止すべきか」のほうを問いに据えると、行き着く先は「廃止すべきである」という結論に限られる。経済学者も政治家もそれをすでに知っているため、どれだけ精緻にモデルを作っても、既知の結論を確認して終わる。

同じ対比は、業務システムの現場にも当てはまる。申請処理に10日かかっているという困りごとに対して、「どう電子化するか」を問いに据えれば、答えは電子化の設計に限られる。誰もが電子化すべきだと知っているため、この問いは既知の結論を確認して終わる。未解明の問いのほうは「なぜ10日かかる手続きが、これまで見直されてこなかったのか」になる。答えは、部署間で承認の責任を移す合意ができていない、といった形で出てくる。

4. 現状と望ましい状態の差

問題を扱いやすくする形式として、現状と実現すべき状態の差で書く方法がある。

4.1 三つの要素で書く

実務で扱いやすい問題の定義は、現在の状態と実現すべき状態のあいだにある無視できない差、という形になる。求められるのは次の三つである。

現状（As-is）
望ましい状態（To-be）
その差（Gap）を放置できない理由

三つとも、状態と、その差と、差を放置できない理由だけを書く。どうやるかは書かない。手段は解決策の側にあり、問題定義の構成要素から外れる。

現状（As-is）は、印象や推測ではなく観察できる事実として書かれる。申請完了まで平均7営業日かかっている、申請の38%が一度以上差し戻されている、問い合わせの62%が申請状況の確認である。件数、時間、エラー率、待ち時間を測っておかなければ、解決後の効果も測れない。

望ましい状態（To-be）で手段が紛れ込みやすい。「システムを導入する」は状態ではなく方法である。標準案件は翌営業日までに処理される、申請者が問い合わせなくても処理状況を把握できる。こうした書き方であれば、実現の方法は後から比較できる。

差（Gap）を放置できない理由も、同じだけ要る。顧客が契約開始に間に合わない、従業員が本来業務へ使える時間を失っている、法令違反のリスクがある。理想と違うというだけでは投資の対象にならず、経営上か業務上か利用者上のどこで効いているのかが要る。

現状を数値で書くという考え方は、トヨタで生まれた A3 に古くからある。297ミリ×420ミリのA3用紙一枚へ、現状、原因分析、対策、実行計画を書く書式である。

A3 は問題の把握から対策までを一枚で扱う。左半分の現状と原因分析がここでいう As-is にあたり、右半分の対策と実行計画は解決策の側になる。問題定義で書くのは、このうち左半分までである。

Lean Enterprise Institute の説明は、A3 を「具体的な問題についての対話を通じて学ばれる管理プロセス」と位置づけ、A3 用紙に記録するかどうかとは独立に成立するとしている。左から順に埋めること自体が、現状を確かめてから対策を考える順序を保つ仕掛けになっている。

4.2 問題・原因・解決策の三つの層

4.2.1 三つの層を見分ける

問題と原因と解決策は、混ざりやすい。「受注処理に平均3日かかり、顧客の希望納期に間に合わない」は問題であり、「承認者が多すぎる」は原因についての仮説であり、「承認段階を減らす」は解決策である。問題定義の段階で原因を決め打つと、その原因に対応する解決策しか検討の対象に残らない。

4.2.2 原因を先に決めない

実際には、処理が遅い原因は同時に複数存在することが多い。入力情報が不足している、承認者が不在である、例外案件と標準案件を同じ流れで扱っている、他部署からの回答待ちが発生している。複数の要因が相互作用して現象を作っている場合、単一の根本原因を先に決めると調査の範囲がそこへ縛られる。

そこで、原因を掘る前に問題の捉え方そのものを広げておく。Julia Binder と Michael D. Watkins が2024年に HBR へ書いた問題の捉え直しについての記事は、この順序を五段階として示している。

段階	内容
Expand	先入観を脇に置き、問題の側面を洗い出す
Examine	氷山モデルで根本原因を掘る
Empathize	当事者の受け止め方を理解する
Elevate	組織全体の課題との繋がりを見る
Envision	問題の枠組みから解決策の設計へ移る

根本原因を掘る Examine は二番目であり、その前に Expand が置かれている。ここで使われる frame-storming について、記事は「チームが前提と盲点を特定することを助け、不十分あるいは偏った解決策を追いかける危険を減らす」と説明している。すでに定義された問いへの解答を増やすブレインストーミングとは、向きが逆になる。

解決策へ移るのは五番目の Envision である。問題の捉え方を広げ、原因を掘り、当事者を理解し、組織との繋がりを見るまでが、解決策の前に置かれている。

4.2.3 原因の混入を確かめる

書いた問題文に原因が紛れ込んでいないかは、「だから」「〜のため」「原因は」といった因果の語を探せば分かる。見つかったら、それが観測した事実なのか推測なのかを分ける。そのうえで、原因候補を三つ以上挙げられるか、反証になる事例はないか、その原因があっても症状が出ないケースはないか、原因を取り除いても残る問題はないかを確かめる。解決策を実施しなくても、原因仮説だけを先に検証できる場合は多い。

4.2.4 問題と課題を分ける

日本語では問題と課題がほぼ同義に使われるが、IPA は両者を分けている。2019年のセミナー資料では、問題を「事実」「あるべき姿と現状との負のギャップ」、課題を「自ら設定するもの」「問題を解決するために何をすべきか」と定義している。ここまで述べてきた As-is と To-be の差が問題にあたり、それに対して何に取り組むかを決めたものが課題になる。

したがって「承認待ちを削減する」は問題ではなく課題であり、「承認を自動化する」はその手段である。問題定義が決めるのは、何が起きているか、何を変える必要があるか、どの範囲を調査するか、までになる。原因分析と課題の設定は、その後に置かれる。

同じ事実からでも、どこで切り取るかによって別の問題が書ける。第2回では、境界・立場・時間・制約の四つの軸で、問題の範囲を決める。