【2026年8月版】

問題を定義する技術（第2回）― 境界・立場・時間・制約の四つの軸

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

第1回では、依頼から解決法を切り離し、現状との差として問題を書いた。

ただし、同じ事実からでも、どこで切り取るかによって別の問題が書ける。第2回では、その切り取り方を決める四つの軸を、順に扱う。

軸	決めること
境界	どこからどこまでを対象にするか
立場	誰にとっての問題として書くか
時間	一時点の値か、変化の傾向か
制約	変えられない条件はどれか

1. 境界をどこに引くか

狭すぎる問題定義は、局所最適を生む。「経理担当者の請求書入力を速くする」と定義すれば OCR や入力支援が候補になるが、本来の問題が「取引先への発注から支払いまで、同じ取引情報を複数回入力している」ことであれば、請求書入力だけを高速化しても重複構造はそのまま残る。

逆に広げすぎると扱えなくなる。全社の生産性を向上させる、顧客満足度を高める、デジタルトランスフォーメーションを実現する、情報共有を改善する。これらは方針や願望であって、具体的な調査と意思決定を導く単位にはならない。局所的な症状だけに閉じず、しかし一つのチームが検証できる範囲に収まり、利用者の一連の行動を含み、関係する業務や組織の境界と対象外の範囲まで書かれている、というあたりが実際に動く広さになる。

引いた境界が妥当かどうかは、動かしてみると分かる。

動かす方向	問い
上流へ	一工程前には何が起きているか
下流へ	一工程後には何が起きるか
組織を越えて	部署の境界を越えると何が見えるか
利用者側へ	目的の達成まで含めると境界はどこになるか
対象外	今回は何を含めないか

一段広げたときに解決策が変わるなら、その広さで定義し直す価値がある。

Design Council が2003年に作った Double Diamond は、この広げてから狭める動きを二つのひし形として描いている。当時 Director of Design and Innovation だった Richard Eisermann が「設計の過程をどう説明するか」と自分のチームへ問うたところから生まれた。段階は Discover、Define、Develop、Deliver の四つになる。前半のひし形について、Design Council は「第一のひし形は、問題が何であるかを単に仮定するのではなく、理解することを助ける」と書いている。探索と収束を構造として分けておくことが、最初の依頼や仮説がそのまま問題として固定されるのを防いでいる。

2. 誰にとっての問題か

2.1 主語のない問題定義

主語のない問題定義は、いくらでも書ける。情報共有ができていない、手続きが複雑である、データが活用されていない、システムが使いにくい、処理が非効率である。誰にとって、何をするときに、どのような不都合があるのかが書かれていないため、結局は組織の都合だけで解決策が決まっていく。

主語を要求するのは、人間中心設計の考え方でもある。NIST の説明は、この手法を利用者とそのニーズおよび要求に焦点を当てて有用なシステムを作る取り組みと定義したうえで、設計は利用者・そのタスク・利用環境の明示的な理解に基づかなければならないとしている。最初の活動として置かれているのも、利用文脈の理解と明確化になる。誰がどの状況で何をしようとしているかが決まっていなければ、そもそも設計を始められないという順序である。

同じ事実からでも、立場が違えば別の問題が出てくる。ある申請に一週間かかっているとして、申請者にとっての問題は結果を得るまでの待ち時間であり、処理担当者にとっては入力内容の不備と問い合わせの多さである。管理職にとってはどこで処理が止まっているのか見えないことで、監査担当者にとっては判断の証拠が残っていないこと、経営者にとっては処理コストの高さかもしれない。「申請に一週間かかる」という事実だけでは、まだ問題は定義されていない。誰にとって何が望ましくないのか、どの状態と比較してどの程度の差があるのか、なぜ今解決するのかが決まって初めて問題になる。

洗い出す相手は、依頼者だけにとどまらない。実際の利用者、業務担当者、顧客、管理者、後工程の担当者、監査・法務・セキュリティ、保守運用者まで並べたうえで、誰が利益を得て誰に新しい負担が生まれるかを見ることになる。

2.2 主語の選び方が解決策を決める

主語の選び方は、そのまま解決策の候補を決める。コールセンターへの問い合わせを減らすプロジェクトを企業側の問題として定義すれば「オペレーター一人当たりの処理件数が少なく、運営コストが高い」になり、応答時間の短縮、AI音声応答、オペレーター支援が並ぶ。利用者側の問題として定義すれば「利用者が必要な情報へ到達できず、電話で問い合わせなければならない」になり、手続きの簡略化、通知の改善、説明文の修正、処理状況の可視化が並ぶ。どちらか一方だけが正しいとは限らないが、どの立場を中心に置いたかを記録に残しておかなければ、後から検証もできない。「業務効率化」という言葉は、この判断を覆い隠しやすい。

立場を選んだ後は、その選択が誰に何をもたらすかを確かめる。

確認する対象	問い
改善の対象	誰の指標を改善しようとしているか
新たな負担	その改善によって誰の仕事が増えるか
移転	負担を別部署へ移しただけになっていないか
衝突	顧客にとっての最適と組織にとっての最適が衝突しないか
優先順位	衝突する場合、最終的に誰の成果を優先するか

ここを記録しないまま進めると、後から誰の判断だったのかを追えなくなる。

例えば「問い合わせ対応へ生成AIを導入したい」という依頼も、主語を入れ替えると別の姿になる。

まず、組織の立場から問題を書いてみる。問い合わせの件数が多く、対応の人手が足りない。この問題に対する解決策を考えてみると、例えば応答の自動化が挙がるだろう。

同じ状況を、今度は利用者の立場から書いてみる。新規利用者の42%が、自分が申請の対象になるのか、何を提出すればよいのかを判断できず、申請の前に窓口へ問い合わせている。説明は Web サイトと PDF と申請画面に分かれていて、それぞれ書いてある内容が違う。担当者に聞いても、答える人によって回答が変わる。

つまりこの例の利用者は、問い合わせたくて問い合わせているのではなく、自力で判断できないから問い合わせている。この読み方をすると、目指す状態は「問い合わせへ速く答えられること」ではなく「問い合わせずに判断できること」になる。

こちらの問題に対する解決策を考えてみると、候補は一つに絞られない。説明の置き場所を整理する、三つに分かれた文書を一つにまとめる、申請画面に判定を組み込む、そもそも申請条件を単純にする、検索を用意する、AI に答えさせる。どれも候補として同じ列に並び、AI はそのうちの一つになる。

2.3 利用者も解決策の形で話す

利用者自身も、自分の問題を解決策の形で話すことがある。一覧画面が欲しい、CSV出力が欲しい、検索条件を増やしてほしい、スマートフォンから承認したい、AIに回答させたい。一覧画面は処理漏れを発見したいからかもしれず、CSV出力はシステム内で必要な集計ができないからかもしれない。検索条件は対象データを特定する共通の識別子がないこと、スマートフォン承認は管理職の不在で処理が止まること、AI回答は規則や情報が複数の文書へ分散していることを指しているかもしれない。要求をそのまま実装すると、利用者が想像できた範囲の解決策しか出てこない。GOV.UK が Discovery 段階のユーザー調査について書いているページが、設計や構築へ進む前に利用者は誰で何を達成しようとし現在どう行動しているかを理解するよう求めているのは、この順序による。利用者は自分の経験については専門家であり、提案した機能が最善の解決策であるとは限らない。

IDEO のデザイン思考も、人にとって望ましいこと、技術で実現できること、事業として成立することを統合する枠組みとして説明されている。IDEO はこれを「複雑な問題を解くための、人間を中心に据えた取り組み」と定義し、あらかじめ解決策を決めておくのではなく、作って試すことによって学ぶ反復的な過程として位置づけている。三つのうち一つの立場だけで問題を書けば、残りの二つは後から制約として現れることになる。

2.4 検討を省くことが双方にとって合理的になる

検討を省いた実装が繰り返されるのは、当事者の判断が間違っているからではない。発注側と受注側の双方にとって、そのほうが得だからである。

根本的な問題を検討しないまま作った実装では、その問題が残るため、発注した組織はその後も小銭を払い続けることになる。データ定義が変わるたびに変換処理の修正を発注し、規程が改訂されるたびに検索の精度調整を発注する。組織が定義や規程を整理しない限り、この支払いは終わらない。

それでも発注側にとって、これは損な選択とも限らない。部署間でデータ定義を統一する、規程を整理して廃止する、責任の所在を決める。どれも他部署との交渉と、誰かの権限を削る決定を伴う。いつ決着するかも読めない。組織へ手を入れずに実装で済ませれば、この痛みを、予算に載せられる保守費用へ置き換えられる。根本的な問題を、金額と時期の分かるコントロール可能な問題にしたほうが、傷は浅く済む。

受注側にとっても、この保守は継続的な仕事になる。問題が残っているほど改修の依頼は続き、売上も続く。組織の問題を解いてしまえば、その保守は不要になる。

つまり検討を省く判断は、双方が短期的な利益を選んだ結果として成立している。個人の怠慢ではなく、両者の利害が噛み合った構造の産物である。

2.5 作らない判断を評価する仕組みがない

未解明の問いを立てにくくする力は、組織の側にもある。「問題を調査したい」では予算が取れず、「新システムを導入する」としたほうが承認されやすい。プロジェクト責任者にとっては、システムを作らないという結論より画面や機能があるほうが成果として説明しやすい。技術者の側でも実装量やリリース件数は測りやすい一方、問題の捉え直しによって不要になった開発は評価されにくい。

会計と税務の扱いも同じ向きに働く。ソフトウエアは減価償却資産として扱われ、自社利用のものは条件を満たせば無形固定資産へ計上する。システムを作れば資産が残るが、業務を廃止して問題を解消しても計上できる資産はない。

実装しない技術の第3回で扱った予算・契約・決裁の構造も加わる。制度の側は作る判断を評価できるが、作らない判断を評価する仕組みを持たない。作らないほうへ向かう誘因が、そもそも弱い。

3. 一時点の値か、時間の変化か

問い合わせ件数が多い、在庫が多い、障害件数が多い、開発速度が遅い、技術負債が増えている。こうした状況は、現在値だけを見ると誤読しやすい。いつから増え始めたのか、一時的な変動か継続的な傾向か、特定の時期に周期的に発生するか、対策後に一度減って再び増えていないか、他の指標とどう連動しているか。同じ数字でも、この情報が付くかどうかで意味が変わる。

問い合わせが月1000件あること自体より、利用者数は変わっていないのに半年で300件から1000件へ増えたことのほうが問題を指している。在庫についても、多いという状態より、欠品を恐れて安全在庫を増やし、保管コストが増え、さらに大量発注による在庫が積み上がる構造のほうが解くべき対象になる。

System Dynamics では、この時間に沿った振る舞いのパターンを参照モード（reference mode）と呼ぶ。1981年の国際システムダイナミクス学会には、参照モードの使い方そのものを主題にした VanderWerf の論文が出ている。Ali N. Mashayekhi と Soheil Ghili が2010年に書いた問題定義の論文は、この分野が強調してきたのは「システムをモデル化すること」ではなく「困りごとを取り除き、問題を解くこと」だと整理している。モデルはシステム全体に対してではなく、説明すべき問題の振る舞いに対して構築される。

確かめる対象は、いつ始まったのか、何を境に変わったのか、周期性はあるか、一度改善した後に戻っていないか、先行して動く指標は何か、遅れて現れる影響は何か、という点になる。主要な指標については、過去から現在を経て望ましい将来までを一本の時間軸へ描いておくと、問題の形が文章より早く伝わる。

問題定義に時間軸が入ると、記述の強さが変わる。「過去6か月間、利用者数がほぼ一定であるにもかかわらず、申請状況に関する問い合わせが月300件から月1000件へ増加している」は、「問い合わせが多い」とは別の文書になる。

4. 制約と、未検証の前提

現在の承認段階は変えられない、この帳票は廃止できない、部署ごとにシステムを分けなければならない。このデータは永久保存が必要で、顧客には必ず紙で提出してもらう。既存システムは変更できず、月末に一括処理しなければならない。こうした条件は、問題を解く前から解ける範囲を狭めている。

本当に変えられない制約はある。法令、契約、安全性、予算、期限、技術的限界がそれにあたる。一方で、変えられないと思われているだけの前提も多い。過去の運用を引き継いでいるだけ、誰も変更を決裁したくないだけ、関係部署と調整したことがないだけ、という場合がある。システムの仕様を業務上の規則だと思い込んでいたり、法令ではなく社内規程で決めていたり、一度発生した事故への暫定対応が残っていたりもする。列挙するより、どの種類なのかを分けておくほうが後の扱いが変わる。

分類	内容	扱い
絶対的制約	法令、安全、物理法則	前提として受け入れる
選択された制約	予算、期限、対象地域	経営判断として再交渉できる
交渉可能な制約	契約、部署間ルール、既存製品	調整の対象に載せる
未検証の前提	慣習、思い込み、過去の判断	根拠を確認する

どの分類に入るかは、根拠をたどれば決まる。

問い	判別できること
その根拠となる文書はどこにあるか	文書が出てこなければ未検証の前提
誰が変更できないと決めたのか	決めた主体が組織の内か外か
法律なのか、社内規程なのか	交渉できる相手がいるかどうか
制約なのか、過去の判断が残っているだけか	現在も有効かどうか
最後に確認されたのはいつか	根拠が古びていないか
この前提が誤りなら何が可能になるか	確認に投じる価値があるか

最後の問いに具体的な答えが出るなら、確認する価値がある。

適切な制約が選択肢の質を上げることはあるが、未検証の前提は解ける範囲を狭めるだけになる。Lean Enterprise Institute の faculty でもある Daniel Markovitz が2020年に HBR へ書いた問題の枠組みに関する記事は、問題をどう記述するかがそのまま解き方を決めるという筋で書かれている。そこで引かれているのは、Charles Kettering の「よく枠づけられた問題は半分解けた問題である」という言葉になる。

5. 四つの軸で枠組みを決める

四つの軸は、それぞれ別の失敗を防いでいる。境界は局所最適を、立場は組織の都合だけで解決策が決まることを、時間は現在値の誤読を、制約は解ける範囲が不必要に狭まることを防ぐ。

軸	決めること	決めないまま進めた場合
境界	どこからどこまでを対象にするか	一工程だけ速くして、重複構造が残る
立場	誰にとっての問題として書くか	組織の指標だけが改善し、利用者の負担が増える
時間	一時点の値か、変化の傾向か	数字の大きさに反応し、増加の原因を見ない
制約	変えられない条件はどれか	変えられる前提を制約と見なし、候補を捨てる

この四つは、順に通せば答えが出るという性質のものではない。境界を動かせば当事者が変わり、当事者が変われば測る指標も変わり、指標が変われば制約の重みも変わる。一つを動かしたら残りを見直す、という往復になる。

決まったかどうかは、書いた問題文を読み返せば分かる。対象の範囲と対象外が書かれているか。誰にとっての問題かが書かれているか。現状が時間の変化として書かれているか。制約と未検証の前提が分けて書かれているか。四つとも書けていれば、解決策を比較する土俵ができている。

最初に書いた問題定義は仮説にすぎない。第3回では、調査に応じて定義を更新し、要件定義へ渡すまでを扱う。