未整理の条件を、判断できる形に変える

by

仕事で必要な能力というと、知識が多いこと、処理が速いこと、正しい結論をすぐに出せることが想像されやすい。もちろん、知識も速度も結論の正確さも不要ではない。しかし、本稿が扱うのは、接客、交渉、営業、教育、身体技能、対人調整まで含む広義の職務遂行能力ではない。扱うのは、未整理の条件を読み分け、判断を組み立て、後から検証できる形に残す力である。実務で最初に与えられるものは、たいてい整理済みの問題ではない。仕様は部分的であり、依頼は断片的であり、議事録には決定事項と未決事項が混在し、設計記録には前提と判断理由が十分に残っていない場合があり、障害報告には観測事実と推測が同居する。したがって、本稿の中心命題は、この種の実務で根本的に必要とされるのは、知識量や瞬発力ではなく、不完全で複雑な入力を、検証可能な判断構造へ変換する能力である、というものである。

ここでいう判断構造とは、結論だけを指すのではない。どの条件を拾い、どの条件を保留し、何を仮定し、何を同一状態とみなし、どの制約をどの順序で適用し、どこまでを断定し、どこから先を不明として残したのか。その一連の経路を含めて、判断構造と呼ぶ。実務では、結論そのものよりも、結論へ至る経路の再現可能性が重要になる。なぜなら、後から条件が追加され、前提が修正され、別の担当者が引き継ぎ、監査やレビューで根拠を求められることがあるからである。結論だけが残っていても、そこへ至る経路が残っていなければ、判断は再利用できない。

この命題は、既稿で扱ってきた記録、判断、AI 利用、責任、証跡の議論とも接続する。場や道具をどういう装置として使うのかを定義することは、後から再利用できる判断の器を作ることである[1]。また、AI に任せる前に人間が初期仮説、前提、判断軸を持つ必要があるという議論は、AI 利用に限らず実務判断一般にも当てはまる[2]。思考設計の有無が成果物の品質を分けるという既稿の整理は、本稿では「判断構造を作れるか」という問題に引き上げられる[3]。さらに、AI の答えであれ人間の推論であれ、結論を実務で使った時点で責任が生じるため、判断の根拠を残す必要がある[4]。証憑や記録を保存する意味も、単に資料を残すことではなく、後から確認できる経路を残すことにある[5]。

本稿では、論理課題や視覚課題を、判断を構造化する力の縮約模型として扱う。ここでいう縮約模型とは、現実の仕事をそのまま再現するものではなく、実務で必要になる思考操作を小さな形式に圧縮したものを指す。たとえば、条件を数える課題は、実務では入力状態、業務条件、エラー条件、処理結果を分ける力に対応する。状態が変化する課題は、実務では現在の選択が後続工程へ与える影響を読む力に対応する。限られた条件から確実に言えることを選ぶ課題は、実務では可能性と必然性を混同しない力に対応する。図形や配置を読む課題は、実務では目立つ情報と本質的な情報を分ける力に対応する。

したがって、本稿で扱うのは、条件を読む、状態を定義する、制約を層別する、断定範囲を制御する、検算可能な説明に戻す、という判断の構造である。これは職務遂行能力全般を代表する話ではないが、仕様読解、設計、テスト、障害対応、データ分析、運用判断、レビュー、文書化、意思決定のように、条件と根拠を扱う実務には広く関係する。この種の実務で求められるのは、整理された問いに答える力だけではなく、整理されていない現実を、答えられる問いへ変換する力である。

1. 実務では、整理済みの問題は与えられない

実務の入力は、学校の問題文のようには整っていない。依頼者はすべての前提を言語化しているとは限らず、仕様書には例外が抜け、調査記録には観測された事実と担当者の解釈が並び、障害報告には再現条件が十分に書かれていないことがある。会議で合意されたように見える事項も、実装条件、運用条件、期限、責任分界まで確定しているとは限らない。ここで必要なのは、与えられた情報をそのまま信じることでも、すぐに結論を選ぶことでもない。まず、何が事実で、何が推測で、何が確認待ちなのかを分けることである。

たとえば、ある機能について「特定条件では表示しない」と説明されたとする。この一文だけでは、実務上はまだ不十分である。表示しないとは、入力欄を画面から消すことなのか、入力欄は残すが操作不可にすることなのか、入力は受け付けるが結果には反映しないことなのか、処理時にエラーを返すことなのか、結果だけを表示しないことなのかが分からない。表面上は同じ「表示しない」でも、実装、テスト、運用、問い合わせ対応ではまったく別の状態になる。したがって、実務では言葉を受け取っただけでは足りない。その言葉が、どの層の状態を変えるのかを確認しなければならない。

扱い 実務上の意味 確認すべきこと
入力欄を表示しない 利用者はその項目を画面上で操作できない。 非表示時に内部値をどう扱うのか、条件なしになるのか、既存値を保持するのかを確認する。
入力欄を操作不可にする 項目は見えているが、利用者は値を変更できない。 なぜ操作できないのかを画面上で理解できるか、既存値が処理に使われるかを確認する。
入力は受け付けるが処理に使わない 画面上の状態と業務処理上の条件が一致しない。 利用者に誤解を与えないか、ログや検索条件にどう残すかを確認する。
入力後にエラーにする 指定自体は可能だが、処理実行時に妥当でないと判定される。 エラーメッセージ、後続処理停止、再入力の導線を確認する。
結果だけを表示しない 入力と処理は成立しているが、表示段階で制御される。 検索や集計は実行されるのか、権限や表示制御とどう関係するのかを確認する。

この表が示しているのは、実務上の言葉は、そのままでは判断に使えない場合があるということである。同じ「表示しない」という表現でも、入力状態を消す話なのか、操作可能性を制限する話なのか、処理条件を変える話なのか、エラー判定を追加する話なのか、表示段階だけを制御する話なのかで、意味が変わる。意味が変われば、設計すべきものも、テストすべきものも、障害時に確認すべきものも変わる。したがって、実務判断では、言葉をそのまま結論にせず、状態、制約、処理、表示へ分解する必要がある。

この見方は、人間の意思決定が完全情報と無限の計算能力を前提にできないという限定合理性の考え方と相性がよい。Simon は、現実の組織における意思決定は、完全な最適化ではなく、認知的制約や組織的制約の下で行われるものとして扱った[6]。ここで重要なのは、人間が不完全だから単に誤るという話ではない。現実の組織では、情報が分散し、時間が限られ、利害が異なり、計算可能な選択肢にも限界がある。そのため、判断は常に、制約の中で構造を作る営みになる。

また、設計とは内的環境と外的環境を結びつける人工物を作る営みであり、問題をどう表現するかが解の性質を左右する[7]。この視点に立つと、実務で重要なのは「正しい解」をいきなり探すことではなく、解ける形に問題を表現し直すことである。何を入力とし、何を状態とし、何を制約とし、何を成果と呼ぶのか。その定義が曖昧であれば、どれだけ手を動かしても、作業は安定しない。

現場の熟達者が時間圧や責任を伴う状況で判断する過程を扱う自然主義的意思決定の研究も、実務判断が単純な形式問題ではないことを示している[8]。熟達者は、常にすべての選択肢を列挙して比較しているわけではない。状況の型を読み、過去の経験と照合し、破綻しそうな点を確認しながら、実行可能な判断へ進む。ここでも重要なのは、直感そのものではない。直感で得た候補を、状況、制約、検証可能性に照らして扱えるかである。

さらに、判断は個人の頭の中だけで完結しない。議事録、設計記録、チェックリスト、画面、ログ、レビューコメント、チケット、運用手順書などは、判断を支える外部の足場になる。Hutchins が示した分散認知の考え方は、認知が個人の内部だけでなく、道具、記録、組織、環境に分散して成立することを示している[9]。この視点に立つと、本稿で扱う力とは、個人の暗算能力や記憶力だけではなく、外部化された情報を使って判断を再現可能にする能力でもある。

したがって、実務で最初に問われるのは、「答えを知っているか」ではない。問われるのは、未整理の入力を、答えられる問いへ変換できるかである。これは、問題を解く力であると同時に、問題を定義する力でもある。その入口は、知識の多さではなく、入力を分解し、判断可能な構造に置き直す能力にある。

2. 論理課題は、判断を構造化する力の縮約模型である

論理課題や視覚課題は、一見すると現実の業務から遠い。図形の規則を探したり、条件の組合せを数えたり、限られた条件から確実に言えることを選んだりしても、その題材自体が日々の仕事になるわけではない。業務で直接必要になるのは、図形の向きを当てることや、抽象的な条件パズルを解くことではない。したがって、これらの課題をそのまま「実務そのもの」と見るのは無理がある。

しかし、表面の題材を一段抽象化すると、実務と同じ操作が残る。条件を読む、候補を広げる、制約を適用する、不要な特徴を捨てる、可能性と必然性を分ける、検算できる形に戻す、という操作である。これは、仕様を読むときにも、テスト観点を洗い出すときにも、障害原因を切り分けるときにも、設計判断をレビューするときにも必要になる。つまり、論理課題や視覚課題は、題材としては抽象的であっても、判断操作としては実務と地続きである。

ここでいう縮約模型とは、現実の仕事を忠実に再現する模型ではない。現実の仕事には、関係者、期限、既存システム、運用制約、費用、責任分界、組織文化など、多くの要素が絡む。そのままでは、どの能力が問われているのかを観察しにくい。縮約模型は、その複雑さをいったん削り、実務で必要になる思考操作の一部だけを見える形にしたものである。現実の業務を小さくしたものではなく、現実の業務に含まれる判断操作を取り出したものと考えると分かりやすい。

課題類型 表面上の操作 実務に接続する能力
条件組合せ 複数の条件が取りうる組合せを数える。 入力可能な状態、入力不能な状態、処理時にエラーとなる状態、結果を返す状態を分ける能力に接続する。
状態遷移 手順ごとに状態がどう変わるかを追う。 現在の選択が後続工程、残り資源、将来の制約へ与える影響を読む能力に接続する。
総量制約 合計値と個別条件の整合性を確認する。 成立可能な状態、必ず成立する状態、条件上ありえない状態を分ける能力に接続する。
必然性推論 限られた条件から確実に言えることを選ぶ。 必要条件、十分条件、片方向条件を取り違えず、断定できる範囲を管理する能力に接続する。
真偽整合 発言の真偽と対象属性の整合を確認する。 観測、証言、解釈、対象状態を同じ層で混同しない能力に接続する。
関係分類 語や概念の関係を分類する。 表面的な連想ではなく、関係の向き、強さ、型を識別する能力に接続する。
視覚系列 図形や配置の変化規則を読む。 目立つ特徴と本質的特徴を分け、最小限の規則で全体を説明する能力に接続する。
空間変換 折り、回転、反転、展開の履歴を追う。 操作履歴を保持し、結果から過程を復元する能力に接続する。

この表が示しているのは、論理課題や視覚課題を、単なる結果の正誤の問題として見るべきではないということである。条件組合せを数える課題では、掛け算そのものよりも、何を一つの状態として数えるかが問われる。状態遷移を追う課題では、いま最大に見える選択ではなく、次に何が残るかが問われる。必然性を判定する課題では、成立する可能性があることと、必ずそう言えることの違いが問われる。視覚課題では、目立つ特徴をすべて拾うことではなく、主規則とノイズを分けることが問われる。

この構造は、実務にそのまま対応する。仕様読解では、書かれている条件を単に読むだけではなく、その条件が入力、処理、表示、保存、権限、エラーのどこに効くのかを分ける必要がある。テスト設計では、すべての組合せを機械的に並べるだけではなく、有効な状態、無効な状態、境界となる状態を区別する必要がある。障害対応では、観測された現象から原因候補を挙げるだけではなく、どこまでが確実に言えることなのか、どこから先が推測なのかを分ける必要がある。

大きなシステムを扱う実務では、要求、設計、実装、検証、運用、退役をばらばらの作業としてではなく、一つのライフサイクルとして扱う。この考え方は、システムズエンジニアリングと呼ばれる分野で整理されてきた。NASA の Systems Engineering Handbook も、システムを目的、要求、設計、検証、運用の連鎖として扱う枠組みを示している[10]。ISO/IEC/IEEE 15288:2023 も、システムのライフサイクルプロセスを共通の枠組みとして整理している[11]。ここで重要なのは、実務の問題は単独の結論ではなく、要求、状態、制約、検証の関係として現れる点である。

要求工学とテストの標準も、同じ方向を示している。ISO/IEC/IEEE 29148:2018 は要求の扱いをライフサイクルプロセスの一部として位置づける[12]。ISO/IEC/IEEE 29119-1:2022 はソフトウェアテストの一般概念を整理し、ISO/IEC/IEEE 29119-2:2021 はテストプロセスを組織やプロジェクトで実行できる形として定義する[13][14]。これは、テストが単なる確認作業ではなく、条件、状態、期待結果、判定基準を明示する作業であることを意味する。

論理課題が判断を構造化する力の縮約模型になるのは、このためである。抽象的な課題は、現実の業務を忠実に再現しない。しかし、実務で必要な判断操作を、短い時間で観察できる形に圧縮する。したがって、見るべきものは「その問題を知っていたか」ではなく、「どのように構造化したか」である。結論は結果であり、構造化は過程である。実務で再利用できるのは、多くの場合、結果そのものではなく、結果に至るまでの判断過程である。

3. 判断を構造化する力は、五つの層で構成される

本稿で扱う、未整理の条件を判断できる形に変える力は、一つの能力ではない。知識がある、処理が速い、説明がうまい、計算を間違えない、といった能力はそれぞれ重要である。しかし、条件と根拠を扱う実務で安定して判断するには、それらをばらばらに持っているだけでは足りない。未整理の入力を受け取り、条件を分け、状態を定義し、制約を適用し、どこまで言えるかを決め、後から確認できる形に戻す必要がある。したがって、本稿ではこの力を、入力読解、状態定義、制約層別、断定範囲の制御、検算可能な説明という五つの層として整理する。

この五つの層は、単に並列に存在するのではない。基本的には、前の層が後の層を支える。入力を誤読すれば、その後の計算が正しくても結論はずれる。状態を定義できなければ、場合分けやテスト設計が不安定になる。制約の層を混ぜれば、画面制御、業務ルール、エラー処理、結果表示が混乱する。断定範囲を誤れば、可能性を確定事項として扱ってしまう。検算できなければ、判断は個人の直感に閉じ、他者が再確認できない。つまり、本稿で扱うのは、個々の知識を使う前に、判断が壊れない足場を作る能力である。

層 役割 誤解しやすい点
入力読解 明示条件、暗黙条件、解釈仮定を分ける。 書かれていない前提を、最初から事実として扱ってしまう。
状態定義 何を同一状態とみなし、何を別状態とみなすかを決める。 見た目の違いと意味の違いを同じものとして扱ってしまう。
制約層別 入力制約、処理時エラー、表示条件、次状態への影響を分ける。 入力できないことと、入力できるが無効になることを混同する。
断定範囲の制御 必ず言えること、ありうること、言えないこと、矛盾することを分ける。 成立例があるだけで、必然性まで示されたと考えてしまう。
検算可能な説明 表、反例、逆算、別経路、作業記録によって判断を再確認できる形にする。 結論が合っていれば、過程を残さなくてもよいと考えてしまう。

第一の層は、入力読解である。ここでいう読解とは、文章の意味をなんとなく理解することではない。何が明示されている条件で、何が文脈上補われている暗黙条件で、何が判断のために置いた解釈仮定なのかを分けることである。たとえば「未指定の場合は全件対象とする」と書かれているなら、未指定は単なる空白ではなく、条件なしという意味を持つ状態である。逆に「この条件では選択不可」と書かれているなら、その状態は入力可能な候補から外れる。入力読解とは、文面を読むだけではなく、その文面が状態空間をどう作り変えるのかを読むことである。

第二の層は、状態定義である。状態定義とは、何を一つの状態として扱うかを決めることである。画面上のチェック状態としては異なるが、業務上の意味としては同じになる場合がある。逆に、見た目は似ていても、内部の保存値、権限、処理条件、ログ上の扱いが違う場合もある。ここを定義しないまま作業すると、同じものを二重に数えたり、別物を同一視したりする。実務では、状態定義が曖昧なままでは、テストケース、障害再現条件、仕様確認、レビュー観点のいずれも安定しない。

第三の層は、制約層別である。制約とは、ある条件が成立したときに、何かをできなくしたり、処理を変えたり、結果を変えたりする規則である。ただし、制約は一種類ではない。入力そのものを禁止する制約、入力は受け付けるが処理時にエラーにする制約、処理は実行するが結果表示を変える制約、現在の選択が次状態に影響する制約がある。これらをすべて同じ「制限」として扱うと、実装箇所もテスト観点も誤る。制約を層別するとは、その制約が、入力、処理、表示、保存、遷移のどこに効くのかを分けることである。

第四の層は、断定範囲の制御である。実務では、すべての結論を同じ強さで言ってよいわけではない。ある条件から必ず言えることもあれば、ありうるだけのこともある。情報が不足していて言えないこともあり、与えられた条件と矛盾することもある。断定範囲を制御できないと、可能性を確定原因として扱ったり、逆に確実に言えることを曖昧なまま放置したりする。信頼できる判断は、強く言うことによってではなく、言える範囲を正確に区切ることによって成立する。

第五の層は、検算可能な説明である。実務上の判断は、本人の頭の中だけで完結してはいけない。別の担当者が読み返したとき、どの前提を使ったのか、どの候補を除外したのか、どの反例を確認したのか、条件が変わった場合にどこを修正すべきなのかが分かる必要がある。検算可能な説明とは、結論を飾るための説明ではない。判断を再利用し、引き継ぎ、レビューし、修正するための構造である。

品質の議論でも、単に「動く」だけでは十分ではない。ISO/IEC 25010:2023 は、ICT 製品やソフトウェア製品の品質を、複数の品質特性とその下位特性として整理している[15]。このことは、実務上の成果物が、正しく動くかどうかだけでなく、使いやすいか、保守しやすいか、信頼できるか、変更に耐えられるかといった複数の観点で評価されることを意味する。判断も同じである。結論が一見正しくても、その根拠が追えず、条件変更に弱く、他者が検証できないなら、実務上の品質は高いとは言えない。

人間中心設計を扱う ISO 9241-210:2019 も、利用者、利用状況、要求を理解したうえでインタラクティブシステムを設計することを重視する[16]。これは、システムを作る側の都合だけでなく、利用者がどの状況で何を理解し、何を操作し、どこで迷うのかを考える必要があるということである。UI 設計のヒューリスティックでは、システム状態の可視性、現実世界との対応、エラー防止などが重要な原則として示されている[17]。WCAG 2.2 も、知覚可能、操作可能、理解可能、堅牢という原則に基づき、コンテンツが利用者に届く条件を整理している[18]。

これらの標準や原則が示しているのは、実務判断が単発の結論ではなく、条件、状態、利用者、品質、検証の関係として成立するということである。五つの層は、その関係を人間が扱える単位に分けるための骨格である。入力を読み、状態を定義し、制約を層別し、断定範囲を制御し、検算可能に説明する。この一連の層を通すことで、実務判断は、個人の直感から、共有可能で再確認できる構造へ移る。

4. 条件組合せは、状態空間を定義する力を測る

条件組合せ型の課題は、表面的には場合の数を数える問題に見える。選択肢がいくつあり、それぞれを掛け合わせれば答えが出るように見えるからである。しかし、実務に近い条件組合せでは、単純な掛け算だけでは十分ではない。重要なのは、何を一つの状態とみなすのか、どの状態は存在するのか、どの状態は入力できないのか、どの状態は入力できるが処理時に無効になるのかを定義することである。したがって、この種の課題が測っているのは、計算力そのものではなく、状態空間を定義する力である。

状態空間とは、ある対象が取りうる状態の全体である。業務画面であれば、各入力欄が取りうる値の組合せ全体が状態空間になる。ただし、実務では、すべての組合せを同じ種類の状態として扱えるわけではない。画面上は指定できるが処理時にエラーとなる状態もあれば、画面制御によってそもそも指定できない状態もある。入力欄が非表示になっているため利用者は選べないが、業務処理上は「条件なし」として意味を持つ状態もある。この違いを分けずに数え始めると、答えの数値は出ても、仕様整理やテスト設計には使えない。

たとえば、ある業務画面に、顧客区分、サービス種別、地域、対象期間を指定する入力欄があるとする。顧客区分は単一選択、サービス種別と地域は複数選択、対象期間は開始月と終了月を指定する。開始月が終了月より後なら、指定自体はできても処理時にエラーになる。また、特定の顧客区分を選ぶと、サービス種別の入力欄が非表示になり、検索条件としては条件なしとして扱われる。この例では、単に選択肢の数を掛け合わせるだけでは、実務上の状態を正しく表せない。

この例で重要なのは、画面上で入力できる状態、そもそも入力できない状態、入力できるが処理時にエラーになる状態、処理できて結果が表示される状態、非表示だが意味としては条件なしになる状態を分けることである。ここを混同すると、見かけ上は計算していても、実務上は誤った整理になる。たとえば、非表示の項目を 0 通りと数えると、その条件での処理自体が存在しないことになってしまう。逆に、入力はできるがエラーになる状態を有効状態として数えると、実際には結果を返さない組合せまで正常系に含めてしまう。

観点 意味 実務上の注意
入力可能状態 画面上または API 上で指定できる状態である。 指定できるからといって、処理が有効とは限らない。
入力不能状態 UI 制御や入力仕様によって、そもそも指定できない状態である。 存在しない状態をテスト対象に含めると、テスト設計が膨らむ。
処理時エラー状態 入力はできるが、処理実行時に妥当でないと判定される状態である。 入力制御ではなく、エラーメッセージや後続処理停止の確認が必要になる。
結果表示状態 入力が妥当であり、処理結果を表示すべき状態である。 有効状態だけを数える場合と、エラー状態を含めた画面状態を数える場合を分ける必要がある。
条件なし状態 項目が非表示または未指定であり、検索条件としては絞り込みを行わない状態である。 選べないことを 0 通りと見ると、その条件での処理自体が存在しないことになってしまう。

この表が示しているのは、条件組合せでは「存在するか」「入力できるか」「処理できるか」「結果を返すか」が別の問題だということである。入力可能状態は、画面や API が受け付ける状態である。しかし、受け付けることと、有効に処理されることは同じではない。入力不能状態は、そもそも利用者が指定できない状態である。処理時エラー状態は、指定自体は可能だが、実行時に妥当性違反として扱われる状態である。結果表示状態は、入力も処理も成立し、結果を返すべき状態である。条件なし状態は、利用者が具体値を指定していなくても、業務上は「絞り込まない」という意味を持つ状態である。

この違いは、テスト設計だけでなく、要求確認にも直結する。依頼者が「この場合は選べないようにする」と言っているのか、「選べるがエラーにする」と言っているのか、「内部的には条件なしとして扱う」と言っているのかで、実装も確認項目も変わる。選べないようにするなら、画面制御や API バリデーションを確認する必要がある。選べるがエラーにするなら、エラーメッセージ、後続処理の停止、再入力の導線を確認する必要がある。条件なしとして扱うなら、検索条件、保存値、ログ、画面復元時の表示を確認する必要がある。

さらに、障害対応でも同じ区別が必要になる。利用者から「検索できない」と報告された場合、それは入力欄が操作できないという意味かもしれない。入力後にエラーになるという意味かもしれない。処理は成功しているが結果が 0 件であるという意味かもしれない。あるいは、入力したはずの条件が内部的には無視されているという意味かもしれない。表面上は同じ「検索できない」でも、状態空間上の位置が違えば、調査すべき箇所は変わる。

したがって、条件を扱うとは、単に場合を数えることではない。何を状態と呼び、その状態がどの層で有効なのかを定義することである。状態空間を定義できれば、条件の組合せは整理できる。状態空間を定義できなければ、数え上げは見かけだけの計算になる。条件組合せ型の課題が判断を構造化する力の縮約模型になるのは、ここに理由がある。実務で必要なのは、選択肢を機械的に掛け合わせる力ではなく、状態の種類を分け、意味のある検証単位へ落とし込む力である。

5. 状態遷移は、現在値ではなく将来状態を見る力を測る

状態遷移型の課題では、目先で最大に見える選択が、全体として最善とは限らない。状態遷移とは、ある時点の状態が、操作や条件によって次の状態へ移ることである。ここで重要なのは、現在の値だけではなく、次に引き継がれる条件まで含めて判断する点である。いま大きく進む選択が、後続の資源を減らすこともある。逆に、いまは小さく見える選択が、次の選択肢を広げることもある。したがって、状態遷移型の課題が測っているのは、単に手順を追う力ではなく、現在の選択が将来状態へ何を残すのかを読む力である。

たとえば、ある作業フローでは、各ステップで処理量を選ぶとする。大きい処理量を選ぶと、その回の進捗は大きい。しかし、その代わりに次回以降に使える資源が減る。小さい処理量を選ぶと、その回の進捗は小さい。しかし、次回以降に使える資源が増える。さらに、特定の進捗地点にちょうど到達すると、追加処理が発生する。このとき、現在の進捗だけを見れば、大きい処理量を選ぶ方が合理的に見える。だが、後続の資源や追加処理まで含めると、短期的に小さい選択の方が、全体として有利になる場合がある。

この例で必要なのは、現在値だけでなく、次に引き継がれる状態変数を見ることである。状態変数とは、後続の判断に影響する値や条件である。進捗、残り資源、利用可能な選択肢、発生済みの操作履歴、例外処理の有無、上限到達時の扱いなどがこれに当たる。ある時点で進捗が最大でも、資源を失っていれば後続で伸びない。逆に、短期的には進捗が小さくても、次に使える資源が増えていれば、全体として有利になることがある。状態遷移を読むとは、このように、いま見えている結果と、次に残る条件を同時に扱うことである。

観点 短期的な見方 状態遷移として見るべきこと
現在の進捗 いまどれだけ進んだかを見る。 その進捗が後続工程の自由度を増やすのか、狭めるのかを確認する。
残り資源 いま使える資源の量だけを見る。 次に残る資源、回復可能性、消耗条件を含めて確認する。
特定地点 到達したかどうかだけを見る。 ちょうど到達した場合だけ発生する処理や例外があるかを確認する。
操作履歴 現在の結果だけを見る。 どの操作を経た結果なのかを保持し、再現可能性を確認する。
終了条件 完了したかどうかだけを見る。 完了条件、打ち切り条件、上限到達時の扱いを分けて確認する。

この表が示しているのは、状態遷移では「いまどう見えるか」だけでは不十分だということである。現在の進捗は重要である。しかし、それが次の自由度を失わせるなら、全体としては不利になる。残り資源も、現在の量だけでなく、次に増えるのか減るのか、回復できるのか使い切りなのかを見なければならない。特定地点への到達も、単に通過したかどうかではなく、ちょうど到達したときだけ特別な処理が起きるのかを確認する必要がある。操作履歴や終了条件も同じである。状態遷移型の判断では、現在の結果を、次状態へ引き継がれる条件の一部として読む必要がある。

この構造は、設計や運用でも頻繁に現れる。短期的に速い実装は、後続の変更耐性を下げることがある。いま障害を止めるための強い制限は、後から通常運用へ戻す手順を複雑にすることがある。緊急対応で一時的な例外を入れると、後続の監査や権限管理に負債が残ることがある。逆に、短期的には遠回りに見える設計記録の整備、検証手順の追加、権限境界の明確化が、後続の変更や障害対応を容易にすることもある。現在値だけを見れば遅く見える作業が、将来状態を安定させる場合がある。

動的な環境での判断には、状況認識が欠かせない。Endsley は、状況認識を、環境内の要素を知覚し、それらの意味を理解し、将来状態を予測することとして理論化した[19]。この考え方は、状態遷移型の課題とよく対応する。いま何が見えているかを把握するだけでは足りない。見えている値が何を意味し、その意味が次に何を可能にし、何を不可能にするのかを読む必要がある。状態遷移を読む力は、現在の観察から将来の制約を予測する力でもある。

また、実務では失敗を個人の注意不足だけに帰すと、構造が見えなくなる。Reason は人的エラーを、個人アプローチとシステムアプローチに分けて論じた[20]。状態遷移の観点では、ある失敗は一人の一回の判断だけで生じるとは限らない。情報の提示順序、確認手順、権限設定、例外処理、通知の出方、引き継ぎの不足などが連鎖して、ある状態から別の状態へ移っていく。その連鎖を見なければ、表面上のミスだけを修正し、同じ構造を残してしまう。

自動化を導入する場合も、状態遷移の見方が必要になる。どの機能をどの程度自動化するかによって、人間の活動や調整要求が変わる[21]。自動化は、人間の作業を単純に減らすだけではない。何を機械が判断し、何を人間が監視し、どの時点で人間が介入し、どこで責任を引き受けるのかを変える。つまり、自動化そのものが、業務の状態遷移を作り変える。Safety-II の観点では、人間は失敗要因であるだけでなく、複雑な社会技術システムの中で適応を担う構成要素でもある[22]。AI リスク管理でも、リスクを特定し、測定し、管理し、統治する構造が必要になる[23]。

したがって、状態遷移を読む力とは、単に手順を順番に追う力ではない。現在の選択が、将来の資源、制約、責任、検証可能性に何を残すのかを読む力である。実務判断では、いま最も進むことより、次状態に何を残すかが重要になる。短期的な進捗だけを見れば合理的に見える選択も、後続の自由度や説明可能性を失わせるなら、全体としては不利になる。状態遷移型の課題が判断を構造化する力の縮約模型になるのは、ここに理由がある。

6. 断定可能性は、言えることと言えないことを分ける力を測る

実務で重要なのは、正しい可能性を見つけることだけではない。断定できないものを断定しないことも同じくらい重要である。むしろ、実務上の誤りは、可能性を見落とすことよりも、可能性にすぎないものを確定事項として扱うところから生じることが多い。障害対応、原因分析、レビュー、データ分析、設計判断では、情報が部分的にしか与えられない。その中で、何が必ず言えるのか、何はありうるだけなのか、何はまだ言えないのか、何は条件と矛盾するのかを分けなければならない。

たとえば、ある障害について、複数の条件が与えられているとする。ある設定が無効なら特定のエラーは起きない。しかし、その設定が有効だからといって、必ずそのエラーが起きるわけではない。あるログが出ていれば特定の処理は通っている。しかし、その処理が通っているからといって、必ずそのログが出るわけではない。ある入力値が不正なら処理は失敗する。しかし、処理が失敗したからといって、必ずその入力値が不正だったとは限らない。このような片方向の条件を双方向に読んでしまうと、可能性を確定原因として扱ってしまう。

ここで必要になるのが、必要条件と十分条件の区別である。必要条件とは、ある事象が成立するために欠かせない条件である。十分条件とは、その条件があれば事象が成立すると言える条件である。たとえば「A でなければ B は起きない」と言える場合、A は B の必要条件である。しかし、それだけでは「A なら B が起きる」とは言えない。逆に「A なら B が起きる」と言える場合、A は B の十分条件である。しかし、それだけでは「B なら A である」とは限らない。表現としては似ていても、判断の向きが異なる。

条件の読み方 意味 誤りやすい変換
A なら B A が成立すれば、B が成立すると言える。 B が成立したなら A も成立したはずだ、と逆向きに読んでしまう。
A でなければ B でない B が成立するためには、A が必要である。 A が成立すれば B も成立する、と十分条件のように読んでしまう。
A のとき B が起きうる A は B の可能性を残すが、B を必ず生じさせるとは限らない。 起きうることを、必ず起きることとして扱ってしまう。
A と B は同時に成立しない A が成立するなら B は成立せず、B が成立するなら A は成立しない。 一方だけを見て、もう一方を候補に残してしまう。

この表が示しているのは、条件文には向きがあるということである。実務では、この向きの取り違えが大きな誤判断を生む。ログが出ていることは、ある処理が通ったことを示すかもしれない。しかし、処理が通ったすべての場合に同じログが出るとは限らない。ある設定が有効であることは、特定の障害が起きる前提かもしれない。しかし、その設定が有効であるだけで障害が確定するわけではない。条件の向きを確認せずに結論を急ぐと、原因候補の一つを確定原因として扱ってしまう。

断定可能性を扱うときには、結論を四つに分けるとよい。必ず言えること、ありうること、言えないこと、矛盾することである。この四つは、似ているようで役割が違う。必ず言えることは、条件を満たしながら反例を作れない結論である。ありうることは、条件とは矛盾しないが、必然ではない結論である。言えないことは、情報が不足しており、肯定も否定もできない結論である。矛盾することは、与えられた条件と同時には成立しない結論である。

区分 意味 誤った扱い
必ず言えること 与えられた条件だけで、反例を作れない結論である。 根拠を示さず、直感的に確からしいだけで確定扱いする。
ありうること 条件と矛盾しないが、必然とは言えない結論である。 成立例があるだけで、常に成立すると考える。
言えないこと 情報が不足しており、肯定も否定もできない結論である。 保留すべきところを、説明しやすい方向へ寄せてしまう。
矛盾すること 与えられた条件と同時には成立しない結論である。 条件の一部を見落とし、候補として残してしまう。

ここで重要なのは、成立例だけでは必然性を示せないということである。ある条件の下で結論が成立する例を一つ作れたとしても、それは「ありうる」ことを示すにすぎない。必ず言えると主張するには、条件を満たしながら結論が成り立たない例、つまり反例が作れないことを確認しなければならない。反例を考えることは、結論を否定したいから行う作業ではない。断定してよい範囲を正確に決めるために行う作業である。

断定範囲の制御は、障害対応、原因分析、レビュー、データ分析に広く関係する。ログから原因を推定する場合、出ているログが何を示し、何を示さないのかを分ける必要がある。レビューでリスクを指摘する場合も、「この設計では問題が起きうる」と「この設計では必ず問題が起きる」を分けなければならない。データ分析でも、相関があること、原因であること、今後も同じ関係が続くことは別である。この区別をしないと、観測事実から説明しやすい物語へ飛んでしまう。

実務で信頼できる判断とは、強く断定する判断ではない。言えることを言い、言えないことを言えないまま残し、確認すれば分かることと、現時点では判断不能なことを分ける判断である。断定可能性を扱う課題が判断を構造化する力の縮約模型になるのは、ここに理由がある。実務では、正しい候補を見つけるだけでなく、その候補をどの強さで言えるのかを管理する必要がある。

7. 視覚課題は、主規則とノイズを分ける力を測る

視覚課題では、色、形、向き、数、位置、重なりなど、多くの特徴が同時に見える。人間の目は、目立つ色、変わった形、大きな変化に引きつけられやすい。しかし、目立つ特徴が、そのまま主規則であるとは限らない。たとえば、複数の図形が並んでおり、色も形も変化しているように見えても、実際には外側に付く要素の数だけが単調に増えている場合がある。逆に、数は変わらず、回転、反転、折り返し、重なりの履歴だけが本質である場合もある。重要なのは、見えている特徴をすべて同格に扱うことではなく、系列全体を最も少ない仮定で説明できる規則を見つけることである。

ここでいう主規則とは、対象全体を一貫して説明する中心的な規則である。これに対して、ノイズとは、まったく無意味な情報という意味ではない。観察事実としては存在しているが、その課題で結論を決めるうえでは中心ではない情報である。色が変わっていること自体は事実である。形が違って見えることも事実である。しかし、それらをすべて規則として扱おうとすると、説明が過剰に複雑になり、かえって単純な増減や変換の規則を見落とすことがある。視覚課題で問われるのは、見えるものを多く拾う力ではなく、どれを本筋として扱い、どれを保留するかを決める力である。

特徴 引き起こしやすい誤読 確認すべきこと
色 目立つ色の変化を、系列全体の主規則として扱ってしまう。 色だけで全体を一貫して説明できるか、他の特徴の方が少ない仮定で説明できないかを確認する。
形 形状の違いをすべて意味のある変化として読んでしまう。 形の違いが、追加、削除、回転、反転、重なりの結果として説明できるかを確認する。
数 単純すぎる規則として軽視してしまう。 要素数の増減だけで候補をどこまで絞れるかを確認する。
位置 配置の印象だけで、対称性や移動方向を判断してしまう。 基準線、向き、移動量、隣接関係を固定して確認する。
重なり 見えている形だけを完成形として扱い、背後の操作履歴を見落とす。 折り、展開、隠れている部分、操作前後の対応関係を確認する。

この表が示しているのは、視覚情報には階層があるということである。色や形は目立ちやすいが、常に主規則とは限らない。数や位置は地味に見えるが、系列を説明するうえでは中心になることがある。重なりや折り返しがある場合には、見えている図形だけでなく、そこに至る操作履歴を考える必要がある。したがって、視覚課題では、最初からすべての特徴を同時に説明しようとするのではなく、数、向き、位置、対称性、操作履歴のような観点を分けて確認する方が安定する。

この能力は、実務にもそのまま接続する。障害画面で赤い表示が目立っていても、本当の原因はその背後の権限状態かもしれない。ダッシュボードで大きく変動している数値があっても、それは業務実態の変化ではなく、集計条件の変更による見かけの変化かもしれない。会議の場で強く主張された論点が、実際の制約条件ではないこともある。目立つ情報は、重要情報であることもある。しかし、常にそうとは限らない。実務判断では、目立つ情報をすぐに原因や本質として扱うのではなく、それが全体構造を説明する情報なのか、局所的に目立っているだけの情報なのかを確認する必要がある。

この点で、視覚課題は、情報過多の状況での判断に近い。情報が多いほど、正しく判断できるとは限らない。むしろ、情報が多いほど、どの情報を主軸に置くかが重要になる。ログが多い、画面表示が多い、関係者の発言が多い、指標が多いという状況では、判断材料そのものは増える。しかし、その中で主規則とノイズを分けられなければ、判断はむしろ不安定になる。必要なのは、情報量を増やすことだけではなく、情報を階層化することである。

不確実な状況での判断では、人間は代表性、利用可能性、係留などのヒューリスティックに影響される。代表性とは、ある対象が典型例に似ているかどうかで判断しやすくなる傾向である。利用可能性とは、思い出しやすい情報や目立つ情報を重く見やすい傾向である。係留とは、最初に与えられた値や印象に判断が引きずられやすい傾向である。Tversky と Kahneman は、不確実性下の判断において、こうした簡便な思考方略が体系的な偏りを生むことを示した[24]。

ただし、本稿でいうノイズ除去とは、直感をすべて否定することではない。直感は、最初の候補を得るためには有効な場合がある。問題は、直感で目に入った特徴を、そのまま主規則として扱ってしまうことである。直感で得た候補は、他の特徴、系列全体の整合性、反例、より単純な説明と照合する必要がある。色が気になるなら、色だけで全体を説明できるかを確認する。形が気になるなら、その形の違いが操作履歴として説明できるかを確認する。数が増えているなら、まずその単純な規則で候補を絞れるかを確認する。

視覚課題を判断を構造化する力の縮約模型として読むなら、そこで測られているのは図形そのものの知識ではない。測られているのは、見えるものの中から、判断に必要なものと、判断を乱すものを分ける力である。実務でも、情報が多いほど正しく判断できるとは限らない。必要なのは、情報量ではなく、情報の階層化である。主規則とノイズを分けられる人は、目立つ現象に反応するだけでなく、背後にある構造を見ようとする。そこに、視覚課題と実務判断の接点がある。

8. 組織は、結論だけでなく判断過程を扱うべきである

組織で実務判断を扱うなら、結論だけを見る運用には限界がある。結論は重要である。誤った結論を出してよいわけではない。しかし、結論だけでは、その判断がどの条件に基づき、どの前提を置き、どの制約を適用し、どの範囲まで断定しているのかを区別しにくい。特に、実務で必要になるのは、既知の手順をなぞる能力だけではなく、未知の条件に出会ったときに判断を組み立てる能力である。したがって、扱うべき対象は、結果だけではなく、判断を生成する過程である。

ここでいう判断過程とは、単なる途中式や作業量のことではない。何を条件として採用したのか。何を仮定として扱ったのか。何を一つの状態として定義したのか。どの候補を、どの条件によって除外したのか。どこまでを断定し、どこから先を保留したのか。結論をどのように検算したのか。こうした経路が見えなければ、結論が妥当に見えても、実務上再利用できる判断かどうかは判断しにくい。

たとえば、ある条件組合せの整理で正しい数値が出ていたとしても、その数値だけでは、入力可能状態と処理時エラー状態を分けて考えたのか、非表示項目を条件なしとして扱ったのか、単に見かけ上の組合せを機械的に数えたのかは分からない。状態遷移の整理でも、最終到達値が合っているだけでは、現在値だけを見たのか、後続状態に残る資源まで見たのかは分からない。断定可能性の整理でも、妥当な候補を残していても、反例を検討して断定範囲を絞ったのか、直感的にもっともらしいものを選んだのかは分からない。

ここには、指標そのものが行動を変えるという問題もある。Goodhart の法則として知られる議論は、指標が政策目標として使われると、その指標がもとの意味を失いやすいことを示す[25]。Campbell も、社会的意思決定に使われる量的指標は、圧力が高まるほど歪みや腐敗を受けやすく、測ろうとした過程を歪める傾向があると論じた[26]。実務判断の管理でも、単に処理件数、速度、表面的な完了率だけを重視すれば、判断構造ではなく、短期的な処理、形式的な記録、説明の省略を促進しかねない。

運用観点 見るべきもの 結論だけでは見えない理由
条件整理 明示条件、暗黙条件、解釈仮定を分けているかを見る。 結論が妥当に見えても、勝手な前提を足している可能性がある。
状態定義 何を一状態とみなすかを説明できるかを見る。 数値や判定だけでは、数え上げ対象の定義が妥当か分からない。
制約適用 入力制約、処理時エラー、表示条件、次状態への影響を分けているかを見る。 同じ条件でも、どの層に効く制約として読んだかによって結論が変わる。
除外理由 候補を捨てた理由を示せるかを見る。 妥当な候補を残していても、誤った理由で除外している可能性がある。
反例確認 断定を崩す例を考えているかを見る。 成立例だけでは、必然性を示したことにならない。
条件変更耐性 前提が一つ変わったとき、どこを修正すべきか分かるかを見る。 場当たり的な処理では、変更時の影響範囲を説明できない。
検算方法 別経路、表、逆算、作業記録によって結論を再確認できるかを見る。 結論だけでは、再現可能性と説明責任を確認できない。

ここで重要なのは、組織で実務判断を扱う場合、結論の正誤だけでなく、結論を支える構造を見なければならないということである。条件整理を見ることで、与えられた情報と補った仮定を分けられるかが分かる。状態定義を見ることで、数え上げや判定の単位を正しく置けるかが分かる。制約適用を見ることで、条件がどの層に効くのかを読み分けられるかが分かる。除外理由や反例確認を見ることで、候補を単に選んだのではなく、なぜ他を捨てたのかを説明できるかが分かる。条件変更耐性を見ることで、判断を一回限りの処理ではなく構造として保持しているかが分かる。

組織が実務判断の品質を高めるなら、扱い方そのものを変える必要がある。結論だけを提出させるのではなく、条件整理、状態定義、除外理由、断定範囲、検算方法を確認できる記録にする。さらに、前提が変わった場合の影響範囲を確認することで、表面的な処理ではなく、構造を保持しているかを確認できる。たとえば、入力条件が一つ増えた場合に全体を最初からやり直すのか、それとも影響する層だけを差し替えられるのかを見れば、理解の深さが分かる。

もちろん、判断過程を扱う運用には注意点もある。過程を長く書かせればよいわけではない。冗長な説明ができることと、構造化できることは違う。必要なのは、条件、状態、制約、断定範囲、検算方法が、必要十分な形で示されているかを見ることである。記述量の多さに寄りすぎると、今度は過剰な記録が重視され、実務で必要な簡潔な判断が見えにくくなる。したがって、扱うべきなのは、長い説明ではなく、判断の骨格である。

実務判断を扱うとは、答えそのものよりも、答えに至る構造を扱うことである。結論は必要条件であるが、それだけでは十分ではない。条件を読み、状態を定義し、制約を適用し、反例を確認し、検算可能に説明できることが、実務上の信頼性を支える。組織が本当に見ようとすべきなのは、結論が出た瞬間ではなく、複雑な入力から結論に至る判断構造を作れるかどうかである。

9. 個人は、個別解法ではなく構造化手順を持つべきである

個人が実務判断を磨くうえで必要なのは、個別問題の暗記ではない。もちろん、典型的な問題類型を知ることには意味がある。条件組合せ、状態遷移、断定可能性、視覚系列といった類型を知っていれば、最初の読み筋は立てやすくなる。しかし、それだけでは表面の条件が変わったときに崩れやすい。必要なのは、個別の解法を覚えることではなく、題材が変わっても使える構造化手順を持つことである。つまり、答え方を記憶するのではなく、未整理の入力を判断可能な構造へ変換する順序を持つことである。

この違いは重要である。個別解法に依存すると、慣れた題材では速く処理できるが、条件が少し変わると、どこを修正すべきか分からなくなる。たとえば、条件を数える課題で新しい制約が加わったとき、全体を最初から数え直すしかなくなる。状態遷移の課題で資源の増減ルールが変わったとき、どの状態変数を追加すべきか分からなくなる。断定可能性の課題で条件文の向きが変わったとき、必要条件と十分条件を取り違える。これに対して、構造化手順を持っていれば、表面の題材が変わっても、どの層を見直せばよいかを判断できる。

手順 行うこと 目的
問いを固定する 数えるのか、判定するのか、最大化するのか、分類するのか、復元するのかを確認する。 解くべき対象を誤らないためである。
条件を分ける 明示条件、暗黙条件、解釈仮定、未確認事項を分離する。 事実と推測を混ぜないためである。
状態を定義する 何を同一状態とみなし、何を別状態とみなすかを決める。 数え上げや検証の単位を安定させるためである。
全体を網羅する 候補、場合分け、状態空間、関係、遷移をいったん広げる。 早すぎる絞り込みによる見落としを避けるためである。
制約で削る 条件に反するもの、矛盾するもの、対象外のものを除外する。 削った理由を明確にして、判断を追えるようにするためである。
断定範囲を決める 必ず言える、ありうる、言えない、矛盾するを分ける。 過剰な断定を防ぐためである。
検算する 別方法、反例、逆算、表、作業記録によって結論を確認する。 判断を再現可能にするためである。

最初に固定すべきなのは、問いの種類である。何を問われているかが曖昧なまま進むと、解くべき対象がずれる。数を求める問題なのに、業務意味として同じかどうかだけを見てしまう。必然性を問う問題なのに、成立可能な例だけを示してしまう。分類を問う問題なのに、単なる連想で判断してしまう。復元を問う問題なのに、見えている最終形だけを見てしまう。問いを固定することは、判断の座標を固定することである。

次に必要なのは、条件の分離である。明示条件は、与えられている条件である。暗黙条件は、文脈上ほぼ必要だが、明文化されていない条件である。解釈仮定は、判断のために暫定的に置いた前提である。未確認事項は、現時点では判断材料にできないが、確認すれば結論を変えうる情報である。この四つを混ぜると、後から検証できない。特に実務では、解釈仮定を事実として扱ってしまうことがある。これは、仕様誤読や原因誤認の典型的な入口になる。

その後、状態を定義し、全体を網羅する。状態を定義するとは、何を一つの単位として扱うかを決めることである。全体を網羅するとは、いきなり答えを選ばず、候補、場合分け、状態空間、関係、遷移をいったん広げることである。ここで大切なのは、広げる段階と削る段階を分けることである。候補を広げずに直感で選ぶと、目立つ特徴に引きずられやすい。逆に、候補を広げたまま削らなければ、判断は進まない。網羅と除外は、別の操作として扱う必要がある。

制約で削る段階では、なぜその候補を除外するのかを残す必要がある。条件に反するから除外するのか、前提と矛盾するから除外するのか、対象外だから除外するのか、情報不足で保留するのかは違う。除外理由が残っていれば、条件が変わったときに、どの候補を復活させるべきかが分かる。除外理由が残っていなければ、結論はその場限りの判断になる。

断定範囲を決める段階では、結論に強さを与える。必ず言えるのか、ありうるだけなのか、現時点では言えないのか、条件と矛盾するのかを分ける。これは、結論を弱める作業ではない。むしろ、結論を実務で使える強さに調整する作業である。強すぎる断定は誤対応につながり、弱すぎる断定は判断を進められない。必要なのは、根拠に見合った強さで結論を出すことである。

最後に、検算する。検算とは、単に計算結果をもう一度見ることではない。別の方法で同じ結論に戻れるかを確認することである。表で確認する。逆方向にたどる。反例を作る。条件を一つ変えて影響範囲を見る。作業記録に戻って、どの前提からどの結論が導かれたのかを確認する。この作業によって、判断は個人の直感から、共有可能で再確認できる構造へ移る。

この手順は、論証の構造とも接続する。Toulmin は、主張、根拠、保証、裏づけ、反論、限定といった要素によって、議論がどのように成り立つかを分析した[27]。実務判断でも、結論だけを出すのではなく、その結論がどの根拠によって支えられ、どの条件で限定され、どの反例に耐えるのかを示す必要がある。また、Pólya の問題解決論が示したように、問題を理解し、計画を立て、実行し、振り返るという基本手順は、数学に限らず、構造化された問題解決の基礎になる[28]。

実務に強い人は、問題ごとの答えを覚えている人ではない。未知の入力に対して、条件を分け、状態を定義し、制約を適用し、断定範囲を制御し、検算可能な説明へ戻せる人である。この能力があれば、題材が変わっても、判断の骨格は失われない。個別解法は、その場の問題に役立つ。構造化手順は、次に出会う未知の問題に役立つ。実務で本当に必要なのは、後者である。

10. 結論――未整理の条件を、判断できる形に変える

本稿で見てきたように、ここで扱ってきたのは、職務遂行能力全般ではなく、条件と根拠を扱う実務において、未整理の入力を検証可能な判断構造へ変換する力である。現実の仕事では、最初から整理された問いはほとんど与えられない。仕様は曖昧であり、条件は後から増え、例外は途中で見つかり、議事録や調査記録には事実と解釈が混ざる。さらに、関係者ごとに見えている範囲は異なり、ログや記録も常に十分とは限らない。だからこそ必要なのは、複雑な入力をそのまま受け取ることではなく、判断可能な構造へ変換する力である。

ここでいう構造とは、単なる整理表や手順書のことではない。何が明示条件で、何が暗黙条件で、何が解釈仮定なのかを分けること。何を一つの状態として扱うのかを定義すること。どの制約が入力、処理、表示、保存、遷移のどこに効くのかを層別すること。どこまでが必ず言えることで、どこからが可能性や保留なのかを区切ること。さらに、その判断を後から検算できる形に戻すこと。これらを合わせて、検証可能な判断構造と呼ぶことができる。

論理課題や視覚課題は、この判断構造を作る能力を小さな形式に圧縮している。条件組合せ型の課題は、状態空間を定義する力を測る。状態遷移型の課題は、現在値ではなく将来状態を見る力を測る。断定可能性を扱う課題は、言えることと言えないことの境界を測る。視覚課題は、主規則とノイズを分ける力を測る。これらは、題材としては抽象的であっても、実務で必要な判断操作と接続している。

課題が測るもの 実務で必要になる力 誤ると起きること
条件組合せ 入力可能状態、入力不能状態、処理時エラー状態、結果表示状態を分ける力である。 仕様整理やテスト設計で、存在しない状態を数えたり、有効でない状態を正常系として扱ったりする。
状態遷移 現在の選択が、後続の資源、制約、責任、検証可能性に何を残すかを見る力である。 短期的に進む選択を優先し、後続工程の自由度や説明可能性を失う。
断定可能性 必ず言えること、ありうること、言えないこと、矛盾することを分ける力である。 可能性を確定原因として扱い、誤った対応や過剰な対策につながる。
視覚課題 目立つ特徴と本質的特徴を分け、主規則を見つける力である。 派手な表示、強い主張、大きく動いた数値に引きずられ、背後の構造を見落とす。

この表が示しているのは、論理課題や視覚課題が、単なる結果の正誤の問題ではないということである。重要なのは、問題の形式を知っていたかどうかではない。与えられた条件をどう読み、どこに状態を置き、どの制約を適用し、どの範囲まで断定し、どの方法で確認したのかである。実務で再利用できるのは、多くの場合、個別の答えそのものではなく、答えに至る判断過程である。

したがって、組織が実務判断を扱うなら、結論だけでなく判断過程を確認できる仕組みを持つべきである。結論は必要である。しかし、結論だけでは、構造を理解しているのか、条件を偶然満たしただけなのか、前提変更に耐えられるのかを区別しにくい。見るべきなのは、条件整理、状態定義、制約適用、除外理由、反例確認、条件変更耐性、検算方法である。これらを見て初めて、その判断が実務上再利用できるものかどうかが分かる。

個人がこの力を高める場合も、個別解法の暗記だけでは不十分である。典型的な問題類型を知ることには意味がある。しかし、表面の値や題材が変わったときに崩れないためには、問題を構造へ変換する手順が必要になる。問いを固定し、条件を分け、状態を定義し、全体を網羅し、制約で削り、断定範囲を決め、検算する。この順序を持っていれば、未知の問題に対しても、どの層を見ればよいかを判断できる。

最終的には、冒頭の命題に戻る。条件と根拠を扱う実務において根本的に必要とされるのは、知識や瞬発力だけではなく、不完全で複雑な入力を、検証可能な判断構造へ変換する能力である。この種の実務で必要なのは、整理された問いに答える力だけではない。整理されていない現実を、答えられる問いへ変換する力である。そして、その変換過程を他者がたどれる形に残すことが、実務における判断の品質を支える。

参考文献

  1. id774, ここをどういう装置として使うのかを定義する（2026-02-21）. https://blog.id774.net/entry/2026/02/21/3748/
  2. id774, AI に任せる前に、人間が残すべき判断（2026-06-21）. https://blog.id774.net/entry/2026/06/21/4912/
  3. id774, AI は思考設計格差を拡大する（2026-02-19）. https://blog.id774.net/entry/2026/02/19/3698/
  4. id774, AI の答えは、採用されたときに責任になる（2026-06-26）. https://blog.id774.net/entry/2026/06/26/4925/
  5. id774, 続・配当金計算書は捨てずに保管したほうが良い（2026-06-02）. https://blog.id774.net/entry/2026/06/02/4844/
  6. Herbert A. Simon, Rational Decision-Making in Business Organizations（1978）. https://www.nobelprize.org/prizes/economic-sciences/1978/simon/lecture/
  7. Herbert A. Simon, The Sciences of the Artificial, third edition（1996）. https://mitpress.mit.edu/9780262691918/the-sciences-of-the-artificial/
  8. Gary Klein, Sources of Power: How People Make Decisions（1998）. https://mitpress.mit.edu/9780262611466/sources-of-power/
  9. Edwin Hutchins, Cognition in the Wild（1995）. https://mitpress.mit.edu/9780262082310/cognition-in-the-wild/
  10. NASA, NASA Systems Engineering Handbook（2016）. https://www.nasa.gov/wp-content/uploads/2018/09/nasa_systems_engineering_handbook_0.pdf
  11. ISO/IEC/IEEE 15288:2023, Systems and software engineering — System life cycle processes. https://www.iso.org/standard/81702.html
  12. ISO/IEC/IEEE 29148:2018, Systems and software engineering — Life cycle processes — Requirements engineering. https://www.iso.org/standard/72089.html
  13. ISO/IEC/IEEE 29119-1:2022, Software and systems engineering — Software testing — Part 1: General concepts. https://www.iso.org/standard/81291.html
  14. ISO/IEC/IEEE 29119-2:2021, Software and systems engineering — Software testing — Part 2: Test processes. https://www.iso.org/standard/79428.html
  15. ISO/IEC 25010:2023, Systems and software engineering — Systems and software Quality Requirements and Evaluation（SQuaRE）— Product quality model. https://www.iso.org/standard/78176.html
  16. ISO 9241-210:2019, Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systems. https://www.iso.org/standard/77520.html
  17. Jakob Nielsen, 10 Usability Heuristics for User Interface Design（1994/2024）. https://www.nngroup.com/articles/ten-usability-heuristics/
  18. W3C, Web Content Accessibility Guidelines（WCAG）2.2（2024）. https://www.w3.org/TR/WCAG22/
  19. Mica R. Endsley, Toward a Theory of Situation Awareness in Dynamic Systems（1995）. https://journals.sagepub.com/doi/10.1518/001872095779049543
  20. James Reason, Human error: models and management（2000）. https://www.bmj.com/content/320/7237/768
  21. Raja Parasuraman, Thomas B. Sheridan, Christopher D. Wickens, A model for types and levels of human interaction with automation（2000）. https://ieeexplore.ieee.org/document/844354
  22. Matthew Scanlon and Nancy Jacobson, Safety I, Safety II, and the New Views of Safety（2025）. https://psnet.ahrq.gov/primer/safety-i-safety-ii-and-new-views-safety
  23. NIST, Artificial Intelligence Risk Management Framework（AI RMF 1.0）（2023）. https://www.nist.gov/itl/ai-risk-management-framework
  24. Amos Tversky and Daniel Kahneman, Judgment under Uncertainty: Heuristics and Biases（1974）. https://www.science.org/doi/10.1126/science.185.4157.1124
  25. Charles A. E. Goodhart, Problems of Monetary Management: The U.K. Experience（1975）. https://www.econbiz.de/Record/problems-of-monetary-management-the-u-k-experience-goodhart-charles/10002525062
  26. Donald T. Campbell, Assessing the Impact of Planned Social Change（1979）. https://ideas.repec.org/a/eee/epplan/v2y1979i1p67-90.html
  27. Stephen E. Toulmin, The Uses of Argument（1958）. https://www.cambridge.org/core/books/uses-of-argument/26CF801BC12004587B66778297D5567C
  28. George Pólya, How to Solve It: A New Aspect of Mathematical Method（1945）. https://books.google.com/books/about/How_to_Solve_It.html?id=X3xsgXjTGgoC