モデリングと論理的推論（あるいはエンジニアリングを進歩させるナレッジとは）
先日(2025/4/22)のきちぴーでユミ駆動さんが発表したネタから着想を得た。
「モデリング」という行為を不慣れな人に伝えるの難しい、、などと思うことがあったが、論理的推論(帰納法: induction、演繹法: deduction、アブダクション: abduction)の観点から説明したら、多少は理解されやすくなるかも？と思い立ってまとめてみた。
特に、複雑な問題領域の本質に迫るモデリングには、ある種の「身体知」や「センス」が必要であり、それはなぜなのかを考えてみる。
モデリングの壁を越えるには？ 〜洞察と文脈知識、そして「推論のループ」〜
ソフトウェア開発、特にビジネス価値に直結する領域において、モデリングは非常に価値の高い営みであることに大きな異論はないでしょう（と信じてる）。
ドメイン駆動設計（DDD）を持ち出すまでもなく、システムの「本質的な複雑性」に立ち向かうためには、現実世界をどう捉え、どう構造化するかが鍵となります。
が。
このモデリングという活動は、掴みどころがなく難しいと感じる人も多いように感じます。
特に経験の浅いジュニアメンバーにとっては、「何から手をつければいいのか」「どう考えればいいのか」が分からず、戸惑ってしまうことも少なくないのでは？
なぜ、モデリングにはこういった「壁」が存在するんでしょう。
このモデリングという行為、実は私たちが普段（無意識に？）用いている論理的な思考プロセスと深く結びついているように思います。
具体的には、「帰納法（Induction）」「アブダクション（Abduction）」「演繹法（Deduction）」、そして「検証（Proof）」という推論のループは、いわば「IAD&Pループ」として捉え直すことができそうです。
1. 観察からパターンを見出す（帰納法: Induction）: まずは現実を注意深く観察します。ユーザーの業務プロセス、既存システムの振る舞い、ドメインエキスパートの話など、具体的な「観察結果」の中から、共通するパターンや傾向、あるいは「何か変だな」という違和感を見つけ出します。これは帰納的なアプローチ。例えば、「この業務では、いつも類似したデータ入力が繰り返されている」「こことここの処理は似ているが、微妙な違いがある」といった気づきがスタート地点となるでしょう。
2. パターンから説明仮説を生み出す（アブダクション: Abduction）: 次に、見出したパターンや「驚くべき事実」に対して、「なぜそうなっているのだろう？」「これを最もよく説明できる理由は何か？」と考えます。これがアブダクションです。他の推論とは異なり、必ずしも論理的に唯一の正解を導くのではなく、「もっともらしい仮説」を生み出す点に特徴があります。これは、複雑な現実の中から本質的と思われる要素や関係性を抽出し、構造化していくモデリングにおける「捨象」のプロセスとも深く関連しているように思います。例えば、「あの業務がいつも煩雑なのは、本来別々の関心事が一つのプロセスに混在してしまっているからではないか？」といった仮説を立てる。そして仮説に沿って不要な概念を削ぎ落していく。これが、モデリングにおける概念の発見や構造化の重要なヒントとなります。
3. 仮説を検証する（演繹法: Deduction と 実証: Proof）: 立てた仮説が本当に妥当かどうかを確かめます。「もし、この仮説が正しいならば、このような状況ではこうなるはずだ」と論理的に予測を立て（演繹法）、実際にそれを試してみます（実証）。この「Proof」は、ソフトウェアエンジニアリングにおけるPoC（Proof of Concept）の"P" が示すように、プロトタイプの作成、簡単なコード実装、ドメインエキスパートへのヒアリングなどを通じた検証・実証を意味します。その結果（新たな観察結果）に基づき、仮説を修正したり、さらに新しい仮説を立てたりします。
この「観察→帰納→アブダクション→演繹→実証→新たな観察…」という「IAD&Pループ」を回し続けることは、モデリングのプロセスそのものであると言えるのではないでしょうか。
複雑な現実を少しずつ解きほぐし、本質に迫っていくための思考フレームワークそのもののように思います。
鍵となるアブダクション：洞察を生む「文脈知識」の力
このループの中でも、特に重要＆難しいのはアブダクション、すなわち「もっともらしい仮説」を生み出す部分ですよね。
観察した事実から、その背後にある本質的な構造や原因を推測する力。これは、単に事実を並べて眺めているだけでは生まれてきません。
このモデリングにおけるアブダクションの出発点となるのは、次のような「違和感」や「気づき」のように思われます。
チーム（ビジネス＋システム）の言語に耳を傾ける中で感じる違和感
設計のぎこちなさや、ビジネスが語る内容の矛盾
新しい要求が既存のモデルに自然に適合しない状況
「面倒くさい」「明確な答えが出てこない」「言語化しにくい」「ごちゃごちゃするところ」といった（しかし見過ごされがちな）重要な業務領域
システムの利用者が自ら必要とするものをうまく言語化できない状況や、部分最適・現行維持に固執した要求
では、どうすればこれらの「違和感」から質の高い仮説、すなわち 深い「洞察」 が得られるのでしょう。
ここで重要になるのが 「文脈知識」 です。
観察した事実に、様々な角度からの知識や経験を重ね合わせることで、初めて「それな!!!」という仮説が閃きますよね。その文脈知識って具体的にどのようなものでしょう。
ドメイン（業務領域）への深い理解: そのビジネスがどのように動いているのか、専門用語の意味、業界の慣習、暗黙のルールなど。ドメインエキスパートとの対話や業務体験を通じて得られる知識は不可欠です。表面的な言葉だけでなく、「なんか面倒くさい」「ここはいつも揉める」といった現場の感覚（「野生」「身体知」と呼んでもいいかも）も重要なヒントとなります。
ビジネスの目的や価値観、あるいは重力: このシステムは何のために存在するのか、誰にどんな価値を届けようとしているのか、ビジネス上の優先順位（「重力」）はどこにあるのか。このような視点がなければ、技術的に優れていてもビジネス価値に繋がらない仮説を立ててしまう可能性があります。
システム設計やアーキテクチャの知識: 既存コードの「ぎこちなさ」の原因を、結合度や凝集性といった設計原則で説明できるか。クリーンアーキテクチャやドメインモデル、境界付けられたコンテキストといった設計パターンや概念の「引き出し」を持っているか。技術的な観点から問題構造を捉え、解決策の仮説を立てるためには、これらの知識が必要です。
組織やチームの力学: コンウェイの法則にも示唆されるように、組織構造がシステム構造に影響を与えることは少なくありません。チーム間の連携不足が、そのままシステムの歪みとして現れていることもあります。また、業務担当とシステム担当間の関係性も大いに影響します。
人間への共感と対話: ドメインエキスパートやチームメンバーが、なぜそのような発言をするのか、どのようなことに困っているのか。相手の立場や感情を理解しようと努めることが、言葉の裏にある本質的な課題を発見する鍵となることもあるでしょう。
このような多角的な文脈知識があって初めて、観察された断片的な事実が意味を持ち始め、本質に迫る仮説（洞察）へと繋がっていくのではないでしょうか。
なぜジュニアは難しいのか？：「文脈知識」と「身体知」の壁
ここまで考えると、なぜジュニアメンバーにとってモデリングが難しく感じられるのか、その理由が見えてくる気がしますね。彼らが困難を感じるのは、質の高いアブダクションに必要な「文脈知識」が、まだ十分に形成されていないからでは？？
観察力や論理的思考力があったとしても、それを解釈するための「引き出し」が少ないのです。
ドメインの常識、ビジネスの勘所、設計の定石、組織の力学といった文脈知識は、一朝一夕に身につくものではないですよね。
多くの場合、実際のプロジェクトでの経験、成功や失敗、多くの人々との対話といった「実践と学習」の積み重ねの中で、時間をかけて身体に染み付いていくものです。いわば「身体知」とでも言うべき側面が強いのでしょう。
したがって、シニアメンバーが「ここは何かおかしい」「こちらの設計の方が筋が良い気がする」と直感的に感じることの根拠を、ジュニアメンバーが理解するのは困難です。
シニアの頭の中にある膨大な文脈知識と、目の前の事象が一瞬で結びついて生まれる「洞察」のプロセスを、言葉だけで完全に伝えるのは至難の業でしょう。
ここに、経験の差からくる「壁」が存在するように思われます。
エンジニアリングを進歩させるナレッジと人材育成戦略
では、どうすればよいのでしょう。
シニアが持つ「身体知」としての文脈知識を、どのように組織の中で共有し、次世代に繋いでいけるのでしょう。
ここに、今後のソフトウェアエンジニアリングの進歩のヒントがあるように感じられます。
シニアの持つ暗黙的な文脈知識や洞察のプロセスを、少しでも形式知化し、共有・再利用可能な「ナレッジ」として蓄積していくこと。これが、組織全体のモデリング能力、ひいては「本質的な複雑性」に向き合う力を底上げする鍵となるのではないでしょうか。
ここでLLMが重要な役割を果たせる可能性があります。
シニアの思考プロセスや判断の根拠となる文脈知識をLLMに学習させることができれば、それは強力なナレッジベースとなり得ます。
しかし、その活用においては注意が必要です。
身体知を獲得したLLMにただエンジニアリング作業をさせるだけでは、ジュニアエンジニアが自ら学び、成長する機会を奪いかねません。
より効果的な戦略は、LLMをジュニアの「メンター」あるいは「学習パートナー」として位置づけることです。
ジュニアがモデリングに行き詰まった時、LLMは良き相談相手となり、多様な視点やヒントを与え、思考を深める手助けをしてくれるでしょう。いくらしつこく聞いてもLLMは気を悪くしません。聞き放題です。
これにより、シニアが従来担ってきたメンタリング負荷の一部を軽減しつつ、ジュニアは能動的にLLMと対話することで、より多くの、そして質の高い学習機会を得ることができます。
AIが「偶有的複雑性」の解消を助け、人間がより「本質的な複雑性」の探求、すなわち深い洞察やセンスメイキングに集中できる環境を目指すのです。
もちろん、身体知のすべてを形式知化できるわけではなく、AIが人間の直感や共感を完全に代替することもできません。
しかし、これまで個人の経験の中に埋もれがちだった「洞察の勘所」のようなものを、LLMのような技術も活用しながら組織の共有財産とし、次世代の育成に繋げていく努力は、エンジニアリングを進歩させる上で非常に重要な要素になるでしょう。
ただし、この戦略が成功するためには、ジュニア自身がLLMに答えを求めるだけでなく、自ら問いを立て、批判的に吟味し、能動的に学ぶ姿勢を持つことが不可欠です。
おわりに：本質的な複雑性に向き合える人材育成への挑戦
結局のところ、これからのソフトウェアエンジニアリングで求められるのは、単にコードを書くスキルだけではありません。
真に求められるケイパビリティは、複雑な現実の中から本質を見抜き、価値あるモデルを構築するための「洞察力」と、それを支える豊かな「文脈知識」です。
そして、そのような人材をどう育てていくのか。これは難しいですよね、、
知識やスキルを教えるだけでなく、経験を通じて「身体知」を育み、多様な視点を持つ人々と「共創」する中で洞察力を磨けるような環境を、どう作っていくかが課題です。
OJTやペアプロ、モブプロといった実践的な取り組みはもちろん、ドメインエキスパートとの継続的な対話の機会、チーム内での設計議論の活性化、失敗から学べる心理的安全性、そしてLLMを学習パートナーとして活用する新しい試み。
こういった協創の機会を多く持ち、さらに組み合わせることで、組織全体で「文脈知識」を育み、共有し、「センスメイキング」を支援する文化を醸成していくこと。それが、本質的な複雑性に立ち向かい、真の価値を創造できるエンジニアと組織を作るための、遠回りなようで一番の近道なのかもしれません。