第2章 仮説を先に持つ ― ヒアリングの前に立つオントロジー
2.1 ヒアリングが変わる
要件定義は、これまで白紙から始まってきた。担当者に話を聞き、業務の全体像を少しずつ組み立て、その場で出てきた語彙を都度すり合わせる。「顧客とは何を指しますか」「この帳票のこの欄は誰が承認しますか」——こうした質問の多くは、業務内容そのものを聞いているのではなく、語彙のすり合わせを兼ねている。ヒアリングが長引く理由の大半は、業務が複雑だからではなく、語彙が揃っていないからだ。
前章で見た通り、業務資料から抽出したオントロジーがあれば、この順番は変わる。ヒアリングの前に、すでに語彙は定義されている。だから最初の質問は「これは何ですか」ではなく「この理解で合っていますか」になる。質問の形が変わるということは、ヒアリングという行為の重心が移動するということだ。定義を作る作業から、定義を検証する作業へ。
従来のフローは、ヒアリング(属人)から要件定義、設計へと進んだ。オントロジーを起点に置くフローは、業務資料からオントロジーを抽出し、それを持って確認のヒアリングに入り、要件定義、設計へと進む。両者の違いは工程の数ではない。ヒアリングという行為の性質そのものが、白紙からの聞き取りから、仮説を持って確認しに行く作業に変わる、という点にある。
ミスコミュニケーションの根本は、共有された語彙が存在しないことにあった。オントロジーが先にあれば、語彙は定義済みだ。ヒアリングが担っていた仕事のうち、語彙のすり合わせという部分は、ヒアリングが始まる前にすでに終えられている。担当者の記憶力や説明能力に依存していた工程が、業務資料という事実に基づく仮説に置き換わる。
2.2 設計の仮定を問い返す
もう一つ、ヒアリングの性質が変わる以上に大きな変化がある。設計そのものが、批判的な視点を獲得する。
オントロジーは、変わるものと変わらないものを語彙の中で分離している。この分離があるということは、設計のフェーズで「これは本当に変わらないか」と問い返せるということだ。これまでの設計は、担当者が「これは変わらない」と言ったものを、そのまま前提として受け取ってきた。担当者に悪意はない。ただ、その人が知っている範囲で「変わらない」と信じているだけであり、他部門の事情や将来の組織変更までは見えていない。その前提が外れたときのコストは、後になって初めて表面化する。仕様変更ではなく、設計のやり直しという重いコストとして。
オントロジーが変わりうると示しているものは、変更容易な構造で設計する動機になる。逆に、変わらないと確認できたものだけを、本当の意味で定数として扱っていい。設計者が自分の判断で「たぶん変わらないだろう」と見積もっていた領域が、業務資料という事実の側から検証される。オントロジーは、設計の仮定に対する事実の批評者として機能する。批評者であって、決定者ではない。最終的に何を定数として扱うかは、それでも人間が判断する。ただしその判断は、根拠のない直感ではなく、業務資料に現れた流通のパターンを踏まえた判断になる。
2.3 具体例:承認フローの境界
抽象的な話を、一つの例に落としてみる。ある帳票の承認フローを新しいシステムに載せ替える案件があるとする。従来のヒアリングでは、まず担当部門に「承認の流れを教えてください」と聞くところから始まる。担当者は自分の部門の流れを説明する。しかし多くの場合、その帳票は複数の部門をまたいで流通しており、担当者の説明は自部門から見えている範囲に限られる。他部門での扱われ方は、その部門にもう一度ヒアリングするまで分からない。ヒアリングを一往復では終えられない理由の多くは、ここにある。
オントロジーがあれば、業務資料の段階で「この帳票はどの部門でどう参照されているか」がすでに見えている。ヒアリングに入る前に「この帳票は経理と営業の双方で承認が必要で、経理側では金額の妥当性、営業側では取引先との整合性という異なる観点で見られている」という仮説を立てられる。担当者への質問は「教えてください」ではなく「この理解で合っていますか、抜けている観点はありますか」に変わる。担当者が答えやすくなるだけでなく、ヒアリングの往復回数そのものが減る。
この例が示しているのは、境界を引く作業の性質の変化でもある。承認フローのどこまでを一つのシステム境界に収めるかは、これまで「経理システムの範囲」「営業システムの範囲」という組織の管轄で決まっていた。業務資料から見えた「金額の妥当性は変わりにくいが、取引先との整合性の基準は取引先ごとに変わりやすい」という性質の違いは、組織の管轄とは別の軸で境界を引く根拠になる。
2.4 システム境界を性質で引く
システムの境界は、今のところ多くの場合、組織の都合や慣習で引かれている。この部署が担当しているからここまで、この帳票を扱っているからここから先、という具合だ。境界の根拠が組織構造にある限り、組織が変われば境界も引き直される。部署の統廃合のたびにシステム境界も引き直しを迫られるのは、この依存関係が原因だ。
オントロジーがあれば、境界を引く根拠が変わる。変わるものの集まりには、柔軟性と拡張性を優先した設計が要る。変わらないものの集まりは、安定した基盤となる領域であり、変更コストをかけてでも堅牢にする価値がある。境界は、組織の都合ではなく、語彙が持つ変化の性質によって引かれるようになる。組織図が変わっても、語彙が変わらない限り、境界を引き直す必要はない。これは後述する温度の適温制御(2.6)を、境界設計という粒度に前倒しして適用していることになる。
2.5 DDDのbounded contextとの違い
DDD(ドメイン駆動設計)のbounded contextも、同じ問いを立てている。どこまでを一つの文脈として扱い、どこから別の文脈として切り出すか。この問いの立て方自体は、オントロジーが目指すものと変わらない。
違うのは、その判断が何に基づいているかだ。DDDの実践では、この境界線引きは結局のところ人の判断に頼っている。経験豊富な設計者が「ここで切るべきだ」と直感し、チームがそれに同意する。直感が正しければうまくいくし、外れれば後から境界を引き直すことになる。しかもその直感は、設計者が異動すればチームから失われる。属人的な判断は、判断した本人がいなくなった瞬間に検証不能になる。
オントロジー抽出は、この判断をグラウンドする。業務資料の中でどの語彙がどこまで一貫して使われているか、どこで意味が分裂しているかは、観察可能な事実だ。境界線を引く判断は、人の直感から、業務資料という事実の側に足場を移す。DDDが立てた問いに、初めて検証可能な根拠を与える、と言ってもいい。設計者が変わっても、業務資料とそこから抽出したオントロジーは残る。
2.6 適温をヒアリングの前に持ち込む
前章1.5で、要件定義とデータエージェントが自然言語を形式的な構造へ写像するという同じ問題を抱えていることを見た。そこで導入したCore第6章のV = f(S, R, T)という定式化——構造(S)が固定されたまま関係(R)の熱だけが下がる冷却崩壊、関係(R)が構造(S)を追い越して暴走する過熱崩壊——は、ヒアリングと設計の関係にもそのまま当てはまる。
ヒアリングの前にすべてを固定してしまえば、それは冷却崩壊だ。要件定義の初期段階で細部まで仕様を決め切り、以後の変更を認めない進め方がこれにあたる。業務の実態から離れた仕様書が、現実との摩擦を生み続ける。逆に、ヒアリングのたびに語彙をゼロから作り直せば、それは過熱崩壊だ。プロジェクトごとに定義が揺れ、前のプロジェクトで積み上げた理解が次に引き継がれない。
オントロジーがヒアリングの前に置く仮説は、この適温を実現するための装置だ。変わらないと確認された語彙は固定し、変わりうると分かっている語彙は仮置きのまま設計に持ち込む。これは前章1.4で述べた「分裂を保持する」という原則の、設計工程への応用形にあたる。分裂を統一せずに保持するという態度は、業務資料の読み取りだけでなく、ヒアリングと設計というシステム開発の実務そのものの構えを変える。
2.7 まだ残る問い
仮説を持ってヒアリングに臨むという方式には、当然ながら仮説が外れる場合が伴う。業務資料から導いた「優位性」や「変わらない」という判定が、実際の現場感覚とずれていることは起こりうる。この方式は、ヒアリングという行為をなくすものではない。ヒアリングの出発点を、白紙から仮説に置き換えるだけだ。仮説が外れたと分かった時点で、それは業務資料の側の見落としとして記録され、オントロジーの訂正につながる。前章で述べた「訂正を受け付けることが設計の原則そのものだ」という立場は、ここでも変わらない。
もう一つ残る問いは、境界の引き直しにかかるコストだ。変わらないと見積もっていた領域が実は変わるものだったと後で判明したとき、すでに堅牢に固めてしまった基盤をどう扱うか。この問いには、まだ実践に基づいた答えを持っていない。
2.8 次章への接続
この章では、業務資料から抽出したオントロジーが、ヒアリングの性質を変え、設計の仮定を問い返す批判的視点を与え、システムの境界を組織の都合ではなく語彙の性質から引き直すことを見てきた。承認フローの例で見た通り、この変化はヒアリングの往復回数や、境界を引く根拠そのものに具体的な差を生む。DDDのbounded contextが人の判断に頼ってきた部分に、事実による足場を与える、という位置づけも示した。
次の章では、この同じ語彙が、自然言語をSQLに変換するデータエージェントの中でどう働くのかを見ていく。要件定義のヒアリングで人間が担ってきた写像の作業を、今度はLLMが担うことになる。そこで問われるのは、優位性と訂正リスクという、前章1.6で分解した二つの量を、実行時の判断としてではなく、オントロジー側の定義としてどう封じ込めるか、という問題だ。