最終更新日：
本稿は、近年の組織・職場に関する言説や人材育成論で扱われる「言語化能力」重視に対する批判を出発点として、ソフトウェアエンジニアにとってこの能力がなぜ必須であるかを論じる。本稿でいう言語化能力とは、内的な感覚、観察、判断、知識、意図を、他者と共有し、検証し、再利用できる外部表現として記録・構造化する活動を可能にする認知的・社会的能力である。
ただし、本稿が退けるのは、即時応答、話術、自己主張の強さを職務遂行能力と誤認する評価慣行である。ビジネス系メディアに見られる批判は、この慣行が、即座に説明できる人や話し方の印象が強い人を過大に評価し、十分に言葉になっていない違和感を持つ人を不利にしうる点を問題にしている。1 本稿は、この批判の射程をソフトウェア開発の作業構造に照らして検討する。会議中の即答だけでなく、調査、草稿化、非同期コメント、レビュー後の修正を通じて判断を精緻化する過程も、評価対象に含める必要がある。したがって、この批判は、本稿が定義する能力そのものの不要性ではなく、即時的、表面的、権力的な言語化への批判として理解すべきである。
ソフトウェアエンジニアリングにおける要求定義、設計、実装、レビュー、障害対応、文書化は、テストや運用を含む検証・保守と結びつき、自然言語、コード、図表、ログ、仕様などを介した共同作業に深く依存している。2 要求定義は曖昧な要望を受け入れ条件へ変換する作業であり、設計は責務、境界、依存関係をチームが参照できる概念構造へ整理する作業である。コードレビューや障害対応では、観察、仮説、判断、提案を区別して書くことが、後続者による根拠確認と品質改善を支える。
人工知能（AI）との協業では、必要な記録対象が、依頼条件、出力評価、採否理由、追加検証事項にまで及ぶ。AIへの指示文、すなわちプロンプトは、目的、制約、出力条件を自然言語で記述する仕様の一部として機能する。しかし、AI協業で問われる言語化能力は、依頼文を巧みに書く能力に限定されない。生成物を採用する場合にも棄却する場合にも、テスト、評価基準、採否理由、未確認事項を残し、後続者が判断の根拠を確認できるようにすることが中心になる。3
本稿でいうAI連携ツールとは、AIモデルの出力を用いて、ファイル編集、コマンド実行、テスト実行、外部ツール呼び出しなどを、開発環境上で実行または提案する支援ツールを指す。生成物だけを受け取るAI利用と異なり、このようなAI連携ツールに操作を許す場合は、入力範囲、許可した操作、求める出力項目、人間の判断へ戻す条件を作業前に明示する必要がある。これらの条件は、出力後に変更差分、検証結果、未確認事項、許可した範囲からの逸脱、未承認の変更を照合する基準になる。4
この能力を分析するため、本稿は、語彙・概念化、構造化、文脈管理、説明・論証などの要素からなる分析枠組みを用いる。詳細な分類は第5章で定義する。5 これらは言語化能力の成り立ちを論じるための枠組みであり、AI協業だけを分類する表でも、個人を一つの尺度で順位づける分類でもない。
本稿が特に重視するのは、言語化能力が実務成果物の中に現れる点である。第一に、観察、根拠、判断理由、検証条件を記録することが、後続者による確認を可能にする。第二に、自然言語、コード、図表、ログ、仕様の対応関係を保つことが、判断の検証を支える。第三に、採否理由や見直し条件を残すことが、後続作業での再利用を可能にする。
したがって、組織は、即時応答、発話量、抽象語の流暢さ、権力的な説明要求を、言語化能力の代理指標として扱うべきではない。問うべきなのは、実務成果物に証拠として残る言語化実践をどのように育成し、その証拠をどのように評価するかである。
教育では、即答や発話量を伸ばす訓練ではなく、未完成の説明を出せる環境を支える心理的安全性を確保すべきである。そのうえで、文書化のための時間配分、テンプレート、非同期共有、不足箇所への具体的なフィードバックを組み合わせ、判断過程を実務成果物へ残す支援構造を設計する必要がある。
評価では、話し方から受ける印象や支援手段の導入有無だけを見てはならない。担当機会と支援条件を併記したうえで、プルリクエスト、Architecture Decision Record（ADR）、障害報告、AI出力レビューなどに残る記述を証拠として扱う。評価基準は、問題の具体化、理解範囲の明示、判断の再利用可能性の三点に置く。6
語彙量、作業記憶、文章経験、口頭説明と文書整理の得手不得手といった個人差は、才能による選別の根拠ではなく、表現媒体、時間配分、役割分担を調整する条件として扱うべきである。本稿の結論は、言語化能力を個人の話術へ還元せず、共有可能で、検証可能で、再利用可能な外部表現を作る実務能力として育成・評価する必要がある、という点にある。
本稿は、職場で流通する「言語化能力」重視への批判を手がかりに、ソフトウェアエンジニアリングでは判断を外部表現として記録・構造化する能力がなぜ中核的能力になるのかを問う。ここで扱うのは、発話の流暢さや自己主張の強さではなく、要求、設計、実装、レビュー、障害対応、AI協業において、観察、根拠、制約、判断理由を他者が確認できる形へ移す実務上の活動である。本稿の中心命題は、ソフトウェアエンジニアに必要な言語化能力を、共有可能で、検証可能で、再利用可能な外部表現を作る認知的・社会的能力として捉える点にある。本章ではこの問題設定を示し、言語化能力の操作的定義は第5章で行う。
近年の公開資料では、言語化力が若手社員の研修・人材育成上の重要スキルとして扱われ（PHP人材開発, 2025）、ビジネスに応用可能な能力として紹介されている（株式会社ソフィア, 2025）。一方でメディア上では、人工知能（AI）への指示文（以下、プロンプト）、評価場面での説明要求、言葉にできる人への偏りを含む「言語化ブーム」をめぐる肯定的評価と批判的論点も示されている（文化放送, 2026）。これらは職場一般で言語化が論点化していることを示す導入上の背景である。本稿は、この流行言説そのものではなく、ソフトウェア開発で判断記録が不可欠になる作業構造へ焦点を移す。
本稿が扱う作業構造は、非同期性、検証可能性、進捗・判断材料の記録化という三点から把握できる。すなわち、関係者が同時に同じ場へ集まらなくても文脈を追えること、成果物や判断が後から確認・更新できること、作業内容や判断材料が個人の記憶に閉じず記録として残ることが問題になる。公開資料は、言語化要求が歴史的に増えたことを測定する実証研究ではないため、本稿は流行の増減ではなく、この作業構造を対象にする。
この整理を支える代表例として、Scrumにおける透明性・検査・適応は、成果物や進捗を関係者が確認できる状態に置く実務例として参照できる（Schwaber & Sutherland, 2020）。GitLabのHandbookは、非同期コミュニケーションにおいて文脈、意図、次の行動を文書化する例を示す（GitLab, n.d.）。遠隔勤務やテキスト中心の業務に関する公開資料も、作業内容、目標、文脈、進捗、判断材料を外部表現として残す必要を示す背景資料である（パーソルクロステクノロジー, 2021; 厚生労働省, n.d.-b）。これらは本稿の概念を直接証明する資料ではなく、判断を口頭の応答や個人の記憶に閉じず、他者が確認できる形に置く作業構造を考える手がかりである。違和感や懸念の共有を可能にする組織条件は、心理的安全性および従業員の発言行動（employee voice）の研究と接続して第2章・第8章で扱う。7
作業内容や判断材料を共有可能な形で示す必要性は、ソフトウェアエンジニアリングにおいてとりわけ顕著である。ソフトウェア開発では、要求定義、設計、実装、レビュー、障害対応、知識継承が、テストや運用を含む検証・保守活動と結びつきながら、自然言語、プログラミング言語、図表、ログ、コメント、ドキュメントを通じて進められる。
以下では暫定的に、言語的活動を、自然言語、コード、図表、ログ、仕様などを用いて判断、制約、意図を共有・検証する活動として扱う。この活動を可能にする能力を第5章で操作的に定義し、その能力が観察可能になる媒体を外部表現と呼ぶ。
コードは機械に実行される命令であると同時に、保守者に設計意図を伝える記述でもある。要求仕様は、利用者、事業担当者、開発者、運用担当者の間で何を作るかを合意するための言語的媒体である。これらの詳細は、第4章でソフトウェアエンジニアリングの成果物として検討する。本章で確認すべき点は、ソフトウェアエンジニアの仕事が、個人の内に閉じた技能としてではなく、観察、判断、概念、制約、意図を共有可能な形に変換する活動として成立していることである。
一方で、言語化能力の重視に対しては批判も生じている。「言語化ハラスメント」と呼ばれるような権力的要求への批判が提示されているからである（木暮, 2025）。厚生労働省のハラスメント対策資料も、職場のパワーハラスメントを、優越的な関係を背景とし、業務上必要かつ相当な範囲を超え、就業環境を害する言動として整理している（厚生労働省, n.d.-a）。したがって、言語化要求が上司と部下、評価者と被評価者、熟練者と初学者の非対称な関係の中で行われる場合、それは学習支援ではなく統制手段になりうる。問題は、口頭で即座に答えられる人、説得的に話せる人、抽象語を流暢に操れる人だけが高く評価され、熟考に時間を要する人、観察や実装を通じて深く考える人、まだ十分に言葉にならない違和感や経験的判断を持つ人が不利になりうる点にある。
本稿は、これらの批判を軽視しない。むしろ、それらは現代組織における言語化の扱い方に対する重要な警告である。組織が経験から学ぶためには、単に個人に説明責任を負わせるのではなく、行為の背後にある前提や判断を対話的に検討する必要がある（Argyris & Schön, 1978）。したがって、言語化能力を重視することは、即時に応答できることや話術を過大評価することと同義であってはならない。
ただし、以上の批判から「言語化能力そのものは重要ではない」という結論を導くことはできない。批判の対象は、言語化能力それ自体ではなく、即時的・表面的・権力的な言語化を過度に評価する職場慣行である。問題は、考える前に話すこと、抽象語で説明した気になること、立場や評価権限の非対称性の中で弱い立場の人にだけ説明を迫ることにある。これに対して、ソフトウェアエンジニアリングでは、要求、設計、レビュー、障害対応、AI協業の各場面で、観察、概念、制約、変更理由、代替案、トレードオフを後から確認できる形に残す必要がある。
本稿の目的は、言語化能力の過度な重視への批判を踏まえたうえで、それでもなお、ソフトウェアエンジニアにとって言語化能力が中核的能力であることを論じる点にある。そのために、まず言語化能力偏重への批判を整理し、その批判の射程を明確化する。次に、要求仕様、設計文書、命名、テスト名、ログ、レビューコメントなどを通じて判断を共有・検証する活動にソフトウェアエンジニアリングがなぜ依存するのかを検討し、心理学・認知科学の知見を参照しながら言語化能力を操作的に定義する。そのうえで、要求定義、設計、コードレビュー、障害対応、ドキュメント、人工知能（AI）との協業において、この能力がどのように実務成果へ結びつくのかを示し、最後に組織がどのように育成・評価すべきかを考察する。
以上の検討を通じて、本稿は次の立場を展開する。ソフトウェアエンジニアに必要な言語化能力は、単なる会話の上手さや自己主張の強さではなく、内的な感覚、観察、判断、知識、意図を、他者と共有可能で、検証可能で、再利用可能な外部表現として記録・構造化する認知的・社会的能力である。
本稿では、この能力を自然言語による発話・文章化に限定しない。コード、図表、ログ、仕様、テンプレートなど、ソフトウェア開発で用いられる記号的・図式的な媒体も、判断を他者が確認できる形に置く外部表現として扱う。この理解を、第5章では三要件と七要素からなる操作的定義へ展開する。
この立場は、AI協業を扱う第7章にもつながる。AIがコード、説明、テスト案、文書案を生成しても、人間は依頼条件、品質基準、採否理由、追加検証事項を外部表現として残さなければならない。本稿は、言語化能力がAI協業で不要になるのではなく、要求を定義し、出力を評価し、設計意図を保持するために記録対象を拡張すると論じる。
言語化能力を重視する近年の傾向に対しては、複数の批判が提示されている。本章の役割は、これらの批判から直ちに結論を導くことではなく、批判がどのような実務上の不利益を指摘しているかを分類することにある。本章では、公開資料および研修・職場言説を、批判そのものの根拠としてではなく、批判対象になりうる「言語化能力」理解の例として扱う。そのうえで、筆者の分析枠組みにより、即時応答と熟考過程の混同、話術と認知能力の混同、立場や評価権限の非対称性による言語化の強制、暗黙的判断・違和感の軽視という四つの観点から整理する。
第一の批判は、会議や面談において素早く言葉にできる人が、実際以上に優秀であると見なされやすい点に向けられている。たとえば、上司から「なぜそう考えたのか」「何が課題なのか」と問われる面談や、仮説、学び、反省、次の行動を共有する振り返りでは、その場で説明することが期待されやすい。このような場面では、短時間で整った説明を返せる人が有利になりやすい。
職場・研修言説においても、即座に説明できることは「言語化力」の一部として扱われやすい。たとえばPHP人材開発（2025）は、「言語化力の高い人」の特徴の一つとして、よどみなく言葉が出ることを挙げている。同記事は、ひきたよしあき監修のPHP通信ゼミナール教材をもとに編集されたものであり、ひきた（2024）も、言語化とは、頭に浮かぶイメージ、考え、思い、アイデア、感情を的確な言葉に変えて口に出すことだと説明している。これらの資料は、即時応答偏重を批判する文献としてではなく、即時的な発話や伝達技能が言語化能力の特徴として語られやすい背景を示す資料として参照する。
しかし、即時的に言葉を出す能力と、深く調査し、分析し、複数の情報を統合して結論を出す能力は同一ではない。ここで重要なのは、即答それ自体を否定することではなく、それを思考能力の代表指標として扱う危険を分類することである。ソフトウェア開発では、性能劣化、障害、設計上の不整合、利用者行動の変化などが、ログ、コード、仕様、運用履歴を突き合わせて初めて理解される場合がある。したがって、会議中に即答できることは有用な場面もあるが、それだけを深い理解の証拠にしてはならない。
むしろ、熟考を要する課題では、沈黙、保留、再調査、草稿化が重要な思考過程になる。言語化能力を会議中の即時応答として評価すると、時間をかけて精密に考える人材を見落とすだけでなく、追加調査が必要な問題を、その場の印象で処理しようとする危険もある。
この危険は、初めから論点や評価基準が固定されていない障害分析、要求整理、設計上のトレードオフで特に大きい。会議中の即答だけを評価すると、未定義の問題を既存の枠組みに早く当てはめる説明を、深い理解の証拠として過大評価しやすい。したがって、本節で確認すべき批判は、即時応答偏重が、保留、追加調査、仮説更新、草稿化を含む熟考過程を見えにくくする点にある。熟達の条件や構造の定まっていない問題については、次章で、即答を検証可能性へ変換する条件として扱う。
第二の批判は、説明がうまいこと、説得的に話せること、強く主張できることが、正確な理解や優れた判断と混同される点にある。職場では、流暢に話す人、抽象語を使って大きな構図を語れる人、会議で場を支配できる人が「仕事ができる人」と見なされる場合がある。たとえば、勅使川原（2026）は、人事評価の実務経験に基づく公開対談において、「言語化が得意であること」と仕事能力を同一視する評価の危うさを論じている。ただし、本節は、この種の評価が職場一般でどの程度生じるかを実証するものではない。本節で扱うのは、公開資料に現れる能力観を分析的に分類し、伝達技能と判断能力を混同すると何が問題になるかを整理することである。話し方の巧みさは、理解の正確さや判断の妥当性をそのまま保証しない。
この混同は、一般的な研修・職場言説を評価実務へ移すときに生じやすい。短い言葉でわかりやすく発言すること、的確な質問をすること、対話・交渉や文章表現に長けることは、実務上有用な技能であり、それ自体を否定すべきではない。しかし、こうした伝達技能は、思考内容の精密さ、根拠の妥当性、検証可能性をそのまま保証するものではない。認知心理学でも、情報の処理しやすさは真偽判断に影響しうることが示されている（Reber & Schwarz, 1999）。また、発話の聞き取りやすさに関わる特徴が話者の信頼性判断に影響しうることも報告されている（Lev-Ari & Keysar, 2010）。これらはソフトウェア開発の評価制度を直接測定した研究ではないが、流暢さや聞き取りやすさから生じる印象を、内容の正確さや根拠の妥当性と区別すべき理由を補助的に示している。したがって、言語化能力を評価する際には、伝達の巧みさと、観察・分析・判断を外部表現として検証可能にする能力を区別する必要がある。
ソフトウェアエンジニアリングでは、実装上の判断、観察、検証、持続的な思考が重要である。設計上の欠陥に気づくこと、再現条件の曖昧な不具合を追うこと、既存コードの暗黙の前提を読み取ること、仕様変更の影響範囲を調べることは、必ずしも口頭での説得的な発話として現れるわけではない。話すことが得意な人が常に正しく設計できるわけではなく、逆に話すことが苦手な人が深い理解を持たないわけでもない。
この混同が問題なのは、評価対象が成果物から発話の印象へずれるためである。説明の形式が整っていても、根拠が不十分であったり、検証可能性を欠いていたり、代替案を検討していなかったりすれば、エンジニアリング上の説明としては弱い。言語化能力を評価するなら、発話の滑らかさではなく、観察、根拠、前提、制約、判断基準がどれだけ明確かを問う必要がある。
第三の批判は、言語化が権力的な要求として用いられる危険に関するものである。本稿でいう非対称な関係とは、評価権限、職位、専門性、発言力などの差によって、一方が他方へ説明を求めやすく、他方が拒否しにくい関係を指す。上司、評価者、熟練者、強い発言権を持つチームメンバーが、若手や弱い立場のチームメンバーに対して「もっと言語化して」と求めるとき、それは必ずしも学習支援にはならない。相手がまだ十分に考えを整理できていないにもかかわらず、即時の説明を求めれば、言語化は説明責任の一方的な押し付けになる。
木暮（2025）が「言語化ハラスメント」と呼ぶ問題は、この点を指している。この問題は、呼称の新しさではなく、優越的な関係を背景に説明要求が過度になりうる点から捉える必要がある。厚生労働省のハラスメント対策資料は、職場のパワーハラスメントを、優越的な関係を背景とし、業務上必要かつ相当な範囲を超え、就業環境を害する言動として整理している（厚生労働省, n.d.-a）。もちろん、すべての説明要求が不当であるわけではない。業務上の判断には説明責任が伴う。しかし、説明を求める側が自らの前提を開示せず、問いの目的や評価基準を示さず、相手の未成熟な表現を攻撃するならば、その場は学習の場ではなく防衛の場になる。
心理的安全性の観点から見ると、チーム内で対人関係上のリスクを取っても安全だという認識が十分に共有されていない環境では、人は不確かな仮説、失敗、違和感、反対意見を表明しにくい（Edmondson, 1999）。言語化は本来、曖昧な認識を他者との対話を通じて精緻化する過程である。しかし立場や評価権限の非対称性が強い場では、未完成の言葉は低評価の材料となり、結果として重要な情報ほど表面化しなくなる。
第四の批判は、言葉になっていない知識や感覚を軽視する危険である。本節で採用する実務上の主張は、暗黙的判断や違和感を、完成した説明に劣るものとして直ちに排除してはならないという点である。「まだ説明できないが危ない気がする」という発話は、それだけでは設計判断の根拠にならない。しかし、そのような感覚を表明できない環境では、リスク検知の入口も失われる。
知識創造論における暗黙知とは、命題や手順として完全には明示されていないが、経験や実践を通じて判断に影響する知識を指す（Nonaka & Takeuchi, 1995）。本稿では、技能の身体的側面を独立して論じるのではなく、ソフトウェア開発における熟練者の暗黙的判断と違和感に焦点を絞る。熟練したエンジニアが「この抽象化は早すぎる」「この仕様は運用で破綻しそうだ」「このログだけでは追跡できない」と感じるとき、その判断は、まだ完全には言語化されていない複数の経験、類似事例、注意の向きに支えられている場合がある。
この点については、即時説明が認知過程を完全に写し取るとは限らないことを示す研究がある。Schooler and Engstler-Schooler（1990）は、視覚記憶を言葉で記述することが後の再認を妨げる場合を、言語的隠蔽として示した。8
Nisbett and Wilson（1977）は、人が自分の認知過程を直接に正確に報告できるとは限らず、求められた説明が事後的でもっともらしい合理化になりうることを論じている。これらの研究は、ソフトウェア開発上の違和感の扱いを直接証明するものではない。本稿では、言語的隠蔽をソフトウェア開発上の違和感へ直接適用するのではなく、説明できない感覚を即座に無価値と見なす評価態度を慎重に扱うために用いる。
したがって、ソフトウェア開発では、未整理の違和感を否定せず、同時にそれを根拠のない断定としても扱わない運用が必要になる。たとえば、「この仕様は危ない」と断定するのではなく、「例外ケースで運用手順が未定義に見える」「このログでは障害時の追跡ができない可能性がある」のように、違和感を観察、仮説、確認事項へ分解する必要がある。暗黙的判断をどのように検証可能な論点へ変換するかは、検証可能性を欠く言語化と検証可能性を備えた言語化を区別する次章以降の議論で扱う。
以上の整理から明らかなように、言語化能力偏重への批判は、即時応答と熟考過程の混同、話術と認知能力の混同、非対称な関係による言語化の強制、暗黙的判断・違和感の軽視がもたらす実務上の不利益を指摘している。次章では、この分類を踏まえ、各批判が妥当する範囲と、そこからは導けない結論を分けて検討する。
前章で見たように、言語化能力偏重への批判には十分な妥当性がある。即答できる人だけを評価すること、口頭で説得的に話せることを正確な理解と混同すること、上位者が下位者に一方的に説明を迫ること、言葉になっていない違和感を軽視することは、判断記録の不足、懸念表明の抑制、根拠確認の困難として現れ、組織学習とエンジニアリング品質を損ないうる実務上の危険を持つ。しかし、これらの批判から、言語化能力は不要であるという結論を導くことはできない。批判されるべきなのは、言語化そのものではない。即時性、流暢さ、権力的説明要求に偏り、観察や根拠を検証できず、説明者を支えず、後続の判断へ残せない言語化である。
この区別を置くと、批判が守ろうとしている価値は、調査、保留、草稿化、見直しを含む熟考過程、発話印象では測れない観察と実装理解、未完成の考えや弱い立場からの懸念表明、まだ十分に言葉になっていないリスク感知である。したがって、なお必要として残るのは、調査結果や判断保留を共有可能な形で記録し、根拠、前提、例外条件を示し、問いの目的や評価基準を明示し、違和感を観察可能な論点へ徐々に変換する能力である。本章では、この望ましい言語化の条件を三つに分ける。
| 条件 | 本稿での意味 |
|---|---|
| 検証可能性 | 観察、根拠、推論、前提、判断基準、未確認事項が分けて示され、他者が追跡、反証、更新できる状態。 |
| 支援構造 | 検証可能な説明を権力的要求にしないために、問いの目的、評価基準、利用できる資料、更新の機会を整える組織条件。 |
| 記録可能性 | 判断理由や検証結果を、後続の判断で参照できる形で残せる条件。 |
本稿では、検証可能性を説明内容の妥当性を検討できるという狭い条件として扱い、公平な支援構造や後から再利用できる記録可能性とは区別する。
前章の即時応答批判から本稿が引き出す肯定命題は、即答を禁止することではなく、説明の検証可能性を確保することである。短い質疑応答や日常的な調整では即答が有用な場合もあり、十分に熟達した実務家が繰り返し経験した型の問題に迅速に答えられる場合もある。Kahneman and Klein（2009）が整理したように、直観的専門性は、規則性のある環境と十分なフィードバックの下では成立しうる。Chase and Simon（1973）やChi, Feltovich, and Glaser（1981）が示す熟達研究も、専門家の迅速な反応が、発話の速さそのものではなく、領域固有知識と、問題をどのような構造、関係、制約として捉えるかという問題表象の質に支えられていることを示している。
それでも、即時性は説明の正確性を保証しない。ソフトウェア開発の問題は、しばしば要求、設計、データモデル、運用手順、責任分界の複数層にまたがる。このような問題に対して必要なのは、その場で整った説明を返す能力だけではない。調査した事実、まだ確認していない前提、判断を保留する条件、次に検証すべき仮説を共有可能な形で残す能力である。
即時性が正確性を保証しない理由は、外部化による見直し、熟達が成立する条件、構造の定まっていない問題という三点に分けられる。第一に、考えを外部表現へ移す過程は、判断を整理し修正する機会でもある。Flower and Hayes（1981）が文章作成を、計画、翻訳、見直しが相互作用する認知過程として捉えたことは、この点を支える。第二に、熟達者の迅速な説明は、単なる反応速度ではなく、長期記憶内の検索構造に支えられる場合がある（Ericsson & Kintsch, 1995）。第三に、構造の定まっていない問題では、何を問題として定義するか、どの情報を集めるか自体が解決過程に含まれる（Simon, 1973）。本稿では、Simonのいうill-structured problemを、初期状態、目標、操作、評価基準があらかじめ十分に定義されていない問題という含意を明示するため、「構造の定まっていない問題」と呼ぶ。したがって、評価対象は即時応答そのものではなく、保留、調査、文章化、更新を追跡できる記録である。
これらの知見をソフトウェア開発に適用すると、熟考を要する場面で評価すべきなのは、沈黙せず即答することだけではない。追加観察や外部情報が必要な場面では、即答を保留し、調査した事実、未確認の前提、次に検証すべき仮説を文章化し、他者のコメントを受けて更新することも、重要な言語化能力である。これは、発話の遅さを正当化する主張ではなく、正確性を確保するために、保留、調査、文章化、更新を検証可能な作業過程として扱うべきだという実務上の結論である。
前章の話術批判と権力的説明要求への批判から本稿が引き出す肯定命題は、説明を個人の流暢さへ委ねず、支援構造の中で育てることである。支援構造とは、問いの目的、評価基準、利用できる資料、調査に使える時間、未完成の説明を更新する機会を明示し、説明を共同で改善できる条件を整えることである。この条件がなければ、説明要求は内容の吟味ではなく、発話の流暢さや組織内の力関係を評価する場に変質する。
支援構造が不足している場面では、抽象語や流行語へ逃げる説明が生じやすい。「課題の解像度が低い」「本質的ではない」「心理的安全性がない」「技術的負債が大きい」といった表現は、適切に用いれば有用である。しかし、問いの目的や評価基準が示されず、参照できる資料や調査時間も与えられなければ、説明者は具体的な観察へ戻る足場を失い、抽象語によって説明したように見せる方向へ押し出される。
支援構造は、説明者に「もっと論理的に話せ」と求めることではない。たとえば設計相談であれば、どのユースケースを前提にするのか、どの制約を動かせないものとして扱うのか、比較対象にする代替案は何かを、問い手も明示する必要がある。コードレビューであれば、「読みにくい」という印象を命名、制御フロー、抽象化、テスト不足、ドメイン概念との不一致などの修正可能な観察へ分解できるように、レビュー観点や例示を与える必要がある。
Toulmin（1958）の論証モデルは、主張、根拠、保証、裏付け、限定、想定される反論や例外条件を区別する。ここで重要なのは、この区別を個人の即興能力として要求するのではなく、テンプレート、問い返し、草稿更新、レビュー記録によって支えることである。表面的な言語化は主張を飾るが、支援構造を備えた場では、主張、根拠、前提、例外条件を分ける作業を共同で進められる。このため、検証可能な説明を求めることは、説明責任を弱い立場の人だけに負わせることを意味しない。むしろ、強い立場の人ほど、問いの目的、判断基準、利用可能な情報、更新の機会を明示する責任を負う。
前章の暗黙的判断・違和感の軽視への批判から本稿が引き出す肯定命題は、未完成の認識を、判断理由、検証結果、未確認事項として後続判断で参照できる形に残すことである。ここでいう記録可能性は、説明をその場の説得で終わらせず、後から読み返し、反証し、更新できる記録へ変換する条件を指す。記録可能性の役割は、検証結果を残すことにとどまらない。どの前提を置き、何を確認し、何を未確認のまま残したかを記録し、将来の設計変更、障害対応、レビュー、教育に引き渡す点にある。
組織学習の観点から見ると、この条件は重要である。Argyris and Schön（1978）は、組織が学習するためには、行為の結果だけでなく、その背後にある前提や規範を問い直す必要があると論じた。ソフトウェア開発でも、結論だけが残り、判断時の制約、却下した代替案、未確認の懸念が残らなければ、後続者は同じ前提を再検討できない。形式的には合意が成立していても、記録がなければ、組織は過去の判断を学習材料として扱えず、同じ判断様式を無自覚に再生産する。
記録化は、公平な支援条件を必要とする。説明責任が特定の立場の人にのみ課され、強い立場の人の言葉だけが正しい言語化として扱われるなら、記録は共同検討の媒体ではなく、既存の力関係を固定する手段になる。たとえば、若手が設計上の懸念を表明したときに「もっと論理的に説明して」と退けられる一方で、熟練者の直感的な判断は説明なしに採用されるなら、記録化は学習支援ではない。未成熟な説明に対しては、攻撃ではなく、観察と解釈の分離、用語の定義、根拠の確認、代替案の提示を通じて、後から参照できる記録へ発展させる必要がある。
ここまでの議論を三条件として整理すると、権力的な言語化を退けた後に残るのは、検証可能性、支援構造、記録可能性である。問いの目的や支援構造を整えたうえで、判断理由、検証結果、未確認事項を記録として残すことにより、一回の説明の妥当性は、後続の判断で再利用できる実務上の記録へ接続される。
この三条件を成果物に即して言い換えると、望ましい言語化は、会議中の整った発話よりも、判断を検討できる記録として現れる。設計説明では、責務境界、依存関係、変更理由、採用しなかった代替案が分けて残されているかが問題になる。障害対応では、観察された事実、原因仮説、未確認事項、再発防止策の追跡条件が混同されていないかが問われる。コードレビューでは、印象や人格評価ではなく、命名、制御フロー、抽象化、テスト、ドメイン概念との対応といった修正可能な観察へ分解されているかを確認する。
ここでいう言語化は、狭義の発話ではない。書くこと、読み返すこと、修正すること、他者の理解に合わせて構造を変えること、曖昧な言葉をより具体的な言葉へ変換することを含む。三条件は、これらの成果物を読む際に、確認済みの観察が追跡できるか、説明要求を支える条件が置かれているか、判断が後から参照できる形で残っているかを確かめるための基準である。
次章以降では、この結論を、ソフトウェアという人工物の性質、心理学・認知科学上の知見、実務成果物の設計へ順に接続する。第5章では、即時の言語報告を思考過程の透明な記録と見なせないという留保を含め、確認済み事項と未確認事項を分け、根拠の欠落や前提の混入を発見し、記録を読み返して更新する過程として言語化能力を定義する。
三条件は、後続章で役割に応じて引き継がれる。検証可能性は、第5章で成果物が満たすべき三要件の一つとして扱う。記録可能性は、後続の判断や学習に使えるという側面を強調して再利用可能性と呼ぶ。支援構造は、成果物そのものの性質というより、その成果物を生み出し改善するための組織条件であるため、第8章の教育設計と第9章の評価設計で扱う。さらに第5章では、外部表現が他者に参照されるための成果物要件として、共有可能性を明示する。章間の用語対応は付録Cに整理する。
結論として、言語化能力をめぐる議論では、「言語化するか、しないか」という二分法を避ける必要がある。問題は、どのような言語化を評価し、どのような言語化を避けるかである。即時的で、表面的で、権力的な言語化は批判されるべきである。一方で、観察、概念、根拠、判断基準、代替案を示し、支援構造の中で更新され、後続の学習や判断に再利用できる記録として残る言語化は、ソフトウェアエンジニアリングに不可欠である。次章では、その理由を、ソフトウェアという人工物の性質から検討する。
本稿の中心命題は、ソフトウェアエンジニアリングが、要求仕様、設計文書、命名、テスト名、ログ、レビューコメントなどを通じて判断を共有・検証する実践に深く依存しているという点にある。ソフトウェアエンジニアが扱う対象は、単なる機械部品や数値ではない。要求、仕様、設計、コード、テスト、ログ、障害報告、レビューコメント、運用手順、ドメイン用語は、いずれも言語によって構成され、共有され、変更される人工物である。したがって、ソフトウェアを作ることは、単にプログラムを動作させることではなく、複数の関係者が概念、意図、制約、判断を共有できる状態を作ることでもある。本章では、この依存関係を人工物の性質から原理的に説明し、成果物ごとの詳細な観察証拠は第6章で扱う。
コードは、コンピュータに実行される命令である。この点だけを見れば、プログラミングは機械に対する形式的記述の作業であるように見える。しかし、実務におけるコードは、一度書かれて終わるものではない。保守、拡張、レビュー、デバッグ、移植、リファクタリングを行うのは人間であり、その人間はコードを読んで意図を推測する。したがって、コードはコンピュータに意図した処理を実行させるための記述であると同時に、未来の読み手に設計意図を伝える説明でもある。
この二重性は、命名、関数分割、抽象化、コメント、テスト名に現れる。変数名や関数名は、単なる識別子ではなく、何を同じ概念と見なし、何を別の概念と見なすかを示す語彙である。関数分割やモジュール分割は、責務の境界を読者に伝える構造である。コメントは、コードから直接読み取れない背景、制約、例外的判断を補足する。テスト名は、期待される振る舞いを自然言語に近い形で明示する。
Knuth（1984）の文芸的プログラミングは、プログラムを機械が読む順序だけでなく、人間が理解しやすい文章構成として編成する発想を明確に示した。また、Abelson, Sussman, and Sussman（1985/1996）は、プログラムを手続き的知識の記述として捉えた。これらの文献から本章が取り出す論点は、コードが人間に読まれる構成を持ちうること、そしてプログラムが処理手順だけでなく知識や考え方の表現でもありうることに限られる。
本稿はこの論点を、現代の保守、レビュー、デバッグ、運用における成果物の点検へ拡張して用いる。すなわち、命名、テスト名、コメント、ログは、Knuth（1984）やAbelson, Sussman, and Sussman（1985/1996）が直接検証した実務項目ではなく、後続者がコードから意図、制約、判断理由を再構成できるかを確認するために本稿が設定する点検対象である。この意味で、コード品質の一部は、設計意図がどれだけ読み取り可能な言葉と構造に変換されているかによって決まる。命名やテスト名の不整合は単なる表現上の問題ではなく、保守時の誤読と変更リスクを増やす品質問題になりうる。これらが実務上どのような失敗類型として現れるかは、第6章で成果物上の点検観点として扱う。以下では、成果物を読んだ他者が対象、制約、判断理由、検証条件をたどれるかという共通構造を、要求定義、設計、判断記録に広げて確認する。
ソフトウェア開発では、何を作るかを決める段階で、すでに言語的な調整が始まっている。利用者、事業担当者、運用担当者、法務・セキュリティ担当者、開発者は、同じシステムについて語っていても、目的、制約、リスク、実現可能性を異なる語彙で表す。要求定義は、これらの異なる語彙を接続し、関係者が同じ対象について合意していると言える状態を作る過程である。
ISO/IEC/IEEE 29148:2018は、要求工学を、利害関係者のニーズを明らかにし、分析し、仕様化し、検証し、管理する過程として位置づける。この定義が示すように、要求は単なる希望の記録ではなく、後続の設計、実装、検証、変更管理を支える言語的人工物である。要求定義における言語化能力とは、個々の要望をそのまま書き写すことではなく、何が同じ要求であり、何が別の制約であり、何を検証できれば合意が成立するのかを整理する能力である。
要求が曖昧なまま残ると、実装の自由度が高まるのではなく、検証不能な合意が生まれる。たとえば「使いやすくする」「高速にする」「管理者が確認できるようにする」という記述だけでは、誰の利用場面を想定し、どの操作時間や応答時間を満たし、どの権限の管理者が何を確認できればよいのかが分からない。受け入れ条件、制約、未確認事項が分かれていなければ、完成後の評価は担当者の印象や発言力に左右されやすくなる。成果物に現れる詳細な失敗は第6章で扱うが、原理的には、要求定義は検証可能な言葉へ合意を変換する作業である。
設計もまた、言語化能力に依存している。モジュール分割、責務分離、境界づけ、抽象化は、概念をどのように切り分けるかの判断である。Parnas（1972）は、モジュール分解の基準として、変更されうる設計判断を隠蔽することの重要性を論じた。これは、単にファイルを分ける技法ではない。どの設計判断が一緒に変わり、どの情報を他のモジュールから隠蔽すべきかを言語的に把握する設計思想である。
設計判断を共有するには、「何を同じものと見なし、何を別のものと見なすのか」を説明できなければならない。設計とは、現実の複雑さを無理に単純化することではなく、実務上重要な差異を保持しながら、変更可能な構造へ整理することである。この整理は、クラス名、モジュール境界、責務名、インターフェース、図、設計文書といった複数の表現に現れる。したがって、設計は内部構造の決定であると同時に、チームが共有する概念体系の形成でもある。
このため、設計上の名前や境界が曖昧な場合、変更時の判断も曖昧になる。責務境界の説明がない設計では、修正が本来の局所変更に収まらず、似た処理の重複や過剰な共通化を招きやすい。具体的な点検対象は第6章で扱うが、原理的には、設計とは概念の境界、変更理由、共有語彙を複数の外部表現に残す作業である。
Evans（2003）のドメイン駆動設計、すなわちDomain-Driven Design（DDD）は、この点を明確に示している。DDDにおけるユビキタス言語とは、ドメイン専門家と開発者が共有し、会話、モデル、コードに一貫して用いる言葉である。Fowler（2006）も、ユビキタス言語を、ドメインモデルと実装を結びつける実践として説明している。これは、ソフトウェア設計が単なる内部構造の決定ではなく、共同言語形成であることを意味する。
この失敗は、設計成果物上では概念名の混同として確認できる。たとえば設計図やクラス名で「ユーザー」という語が、ログイン権限を持つアカウント、契約上の請求主体、実際に画面を操作する利用者を区別せずに使われている場合、どの責務を認証モジュール、契約管理、利用履歴管理のどこへ置くべきかが不明確になる。権限仕様を変更したいのか、契約主体の変更履歴を扱いたいのか、利用者ごとの行動履歴を扱いたいのかが成果物から読めなければ、変更影響の範囲も検証条件も定まらない。この場合の問題は命名の好みではなく、同じ語が複数の概念境界を隠しているため、責務境界と変更理由を後続者が再構成できない点にある。
Parnasのモジュール分解やDDDから本章が取り出すのは、設計判断が概念の境界、変更理由、共有語彙として表現されなければ、後続者が意図・制約・判断理由を再構成しにくくなるという点である。要求の検証可能性、コードの可読性、設計境界、判断記録はいずれも、後続者が判断をたどれるかという問題に収束する。したがって本稿では、言語化能力を会話技能ではなく、ソフトウェア人工物に判断を残す能力として扱う。
ソフトウェアは長期にわたって変更される。初期の設計者が不在になっても、残されたチームはコードを読み、意図を推測し、変更を加える必要がある。このとき、判断理由が言語化されていなければ、後続の開発者は、現在の構造が偶然なのか、制約に基づく意図的な選択なのかを区別できない。結果として、必要な制約を壊したり、逆に不要になった構造を温存したりする。
設計文書、Architecture Decision Record（ADR）、プルリクエストの説明、レビューコメント、障害報告は、判断を組織の記憶に変換する媒体である。ADRとは、アーキテクチャ上重要な意思決定について、文脈、決定内容、状態、帰結などを短い文書として記録する形式である（Nygard, 2011）。ここで重要なのは、これらの媒体が「完成した成果物の説明」だけでなく、後から判断を再評価するための手がかりを保存する点である。
ADRが存在しない場合、後続者は現在の構造を、守るべき制約なのか、過去の一時的な都合なのか、単なる未整理なのかを区別しにくい。その結果、性能、セキュリティ、運用上の制約を意図せず破壊することもあれば、すでに不要になった構造を過剰に温存することもある。具体的に何を記録すべきか、記録不足が成果物品質にどのような影響を与えるかは、第6章で検討する。
以上のように、ソフトウェアエンジニアリングは、要求を合意に変え、設計を概念構造に変え、コードを意図の読める人工物に変え、判断を組織の記憶に変える活動である。この過程の中心には常に言語がある。次章では、このような活動を可能にする言語化能力を、心理学・認知科学の観点から定義する。
本稿でいう言語化能力とは、内的な感覚・観察・判断・知識・意図を、他者が共有し、検証し、再利用できる外部表現として記録・構造化する活動を可能にする認知的・社会的能力である。ここでいう外部表現には、自然言語の発話や文章だけでなく、メモ、図、コード、ログ、仕様、テンプレートのように、認知主体の外部に保持され、他者が確認できる表現を含む。したがって、ソフトウェアエンジニアリングにおいて必要な言語化能力は、話術、プレゼンテーション能力、自己主張の強さではなく、記録、検証、再利用を成立させる能力である。
要求仕様では、同じ語が同じ業務対象を指す必要がある。Architecture Decision Record（ADR）では、採用案だけでなく却下案と制約が後から読めなければならない。レビューコメントでは、単なる不満ではなく、どの観察からどの修正提案が出ているのかを分ける必要がある。障害報告では、事実、仮説、暫定対応、未確認事項が混ざると、次の対応者が同じ判断を検証できない。これらの不足は、話し方の巧拙というより、名前をそろえること、根拠と仮説を分けること、未確認事項を残すこと、過去の判断を参照可能にすることの不足として現れる。
本章で定義するのは、実務成果物に現れる言語化能力を読むための操作的枠組みである。この枠組みは二層からなる。第一は、成果物が満たすべき性質を示す三つの要件であり、第二は、不足箇所を修正可能な記述単位へ分解する七要素である。
本章で用いる用語の層を先に区別しておく。次の表でいう操作的用語は、本稿が要求仕様、設計メモ、レビューコメント、障害報告、AI出力レビューなどの成果物を読むために用いる語である。参照概念は、その操作的用語がなぜ実務成果物の品質に関係するのかを説明するために参照する心理学・認知科学上の概念である。
| 区分 | 本章での扱い | 代表例 |
|---|---|---|
| 操作的用語 | 成果物上の不足や改善対象を読むために本稿が定義する語。 | 外部表現、共有可能性、検証可能性、再利用可能性、七要素 |
| 参照概念 | 操作的用語の背景を説明するために参照する文献上の概念。 | 外部表象、認識的行為、分散認知、作業記憶 |
この区別により、本稿は「外部表象」などの認知科学上の概念を、外部表現が共有、検証、再利用を支える理由を説明する補助根拠として用いる。
三つの要件とは、共有可能性、検証可能性、再利用可能性である。共有可能性は、外部表現が他者に参照され、同じ対象や基準を指せる性質である。検証可能性は、第3章で述べた条件を成果物の記述として確認できるようにした要件である。再利用可能性は、第3章で述べた記録可能性を、後続の判断や学習に使えるという側面から言い換えた要件である。第3章で述べた支援構造は、成果物の性質ではなく、これらの成果物を生み出し改善する組織条件として第8章・第9章で扱う。
七要素とは、不足箇所を直すための分析観点であり、語彙・概念化、構造化、メタ認知、文脈管理、説明・論証、違和感・懸念の論点化、共同言語形成からなる。三要件は「成果物がどの性質を欠いているか」を見るための基準であり、七要素は「どの記述をどの単位で直すか」を考えるための観点である。要求仕様、設計メモ、ADR、レビューコメント、障害報告、AI出力レビューを読むとき、三要件だけでは「共有、検証、再利用のどれが失敗しているか」は分かっても、「どの記述を直せばよいか」までは十分に分解できない。七要素は、この不足を、命名、構成、理解範囲、文脈、根拠、懸念、共同語彙という実務上の修正単位へ分類するために本稿が構成した枠組みである。
この操作的定義を、成果物上で確認できる観点へ展開すると、対応関係は次のように整理できる。
| 不足する要件 | 成果物上の典型的な問題 | 関連する七要素 | 成果物上の主な手がかり |
|---|---|---|---|
| 共有可能性 | 関係者が同じ要求、状態、責務を扱っているつもりでも、別の対象を指してしまう。 | 経験や観察に名前を与える語彙・概念化、チームで安定して使える語彙を作る共同言語形成。 | ドメイン用語、関数名、状態名、用語定義、命名規約、同一概念の表記一貫性。 |
| 検証可能性 | 結論、根拠、仮説、未確認事項が混ざり、他者が判断を追跡できない。 | 情報を関係や順序へ配置する構造化、理解済み事項と未確認事項を分けるメタ認知、主張と根拠を示す説明・論証。 | 時系列、依存関係、代替案、確認済み事項、未確認事項、主張、根拠、例外条件。 |
| 再利用可能性 | 過去の制約、判断理由、懸念が後続作業へ引き継がれない。 | 制約や履歴を外部表現で維持する文脈管理、未分化な懸念を後続の検討対象へ変える違和感・懸念の論点化。 | 影響範囲、制約、履歴、論点リスト、懸念対象、発生条件、確認事項。 |
この表は、七要素を三要件へ固定的に割り当てるものではない。成果物のどこに不足が現れ、その不足を補うためにどの働きが必要になるかを読むための整理である。一つの実務行為は複数の要件を同時に支える。たとえば障害報告では、時系列、影響範囲、暫定対応、恒久対応を分ける記述が構造化に当たり、「監視条件が更新されていないため同じ兆候を検知できない可能性がある」という記述は説明・論証と違和感・懸念の論点化に当たる。同じ報告の中で、サービス名、状態名、アラート名がチーム規約と一致していれば、語彙・概念化と共同言語形成も同時に現れる。実務場面との詳細な対応は付録Aで補足する。
三要件と七要素は、成果物の不足を読むために本稿が構成する操作的枠組みである。すなわち本章の役割は、第一に、共有可能性、検証可能性、再利用可能性を実務成果物が満たすべき要件として定義すること、第二に、その不足を成果物上の修正可能な単位へ分解するために七要素を示すことにある。
心理学・認知科学の文献は、三要件・七要素の名称や数を直接導出する根拠ではなく、外部表現が実務成果物の品質に関わる理由を説明する補助根拠として用いる。三要件と七要素は、本稿が要求仕様、設計メモ、レビューコメント、障害報告、AI出力レビューに現れる不足を読むために構成した操作的枠組みである。したがって5.3節以降では、各要素について、まず成果物上の失敗と修正単位を示し、その後に必要な範囲で文献上の概念を位置づける。9
共有可能性とは、要求仕様、設計メモ、障害時系列などが、関係者にとって同じ対象を指す参照点になることである。要求一覧に受け入れ条件が書かれ、設計図に依存関係が示され、障害報告に発生時刻と影響範囲が残ると、担当者は個人の記憶や口頭説明に戻らずに同じ対象を確認できる。認識的行為とは、課題理解や推論負荷の低減のために外界を操作する行為であり、メモ、図、チェックリスト、時系列表は、判断材料を並べ替え、比較し、見直すための道具になりうる（Kirsh & Maglio, 1994）。また分散認知は、認知活動を個人、道具、記録、作業環境、他者との相互作用を含むシステムとして捉える見方である（Hutchins, 1995）。これらの知見は、実務成果物が単なる保存物ではなく、関係者が同じ問題を指すための共有媒体として働く理由を説明する。
検証可能性とは、読み手が結論までの経路を追跡し、必要なら反証や更新を行えることである。要求仕様で目的、制約、受け入れ条件が分かれ、設計メモで代替案と採否理由が分かれ、障害時系列で観測値、原因仮説、確定原因、未確認事項が分かれていれば、他者は判断の妥当性を確認できる。外部表象研究は、表現の配置が課題の探索、比較、推論の負荷を変えうることを示している（Larkin & Simon, 1987; Scaife & Rogers, 1996）。本稿はこの知見を、要求仕様や障害報告を結論、根拠、仮説、未確認事項が区別された構造へ整える必要性の説明として用いる。
再利用可能性とは、過去の判断を後続作業が参照できることである。ADRに却下案と制約が残り、レビューコメントに懸念対象と確認条件が残り、障害ログに暫定対応、恒久対応、再発防止策の追跡条件が残ると、後続者は同じ前提に戻って判断を再開できる。作業記憶とは、情報を一時的に保持し操作する認知機構であり、複数の制約や履歴を同時に扱う実務では、個人内の保持だけに依存しない記録化が必要になる（Baddeley & Hitch, 1974）。設計記録、レビューコメント、障害ログは、個人記憶への依存を下げ、過去の制約、採否理由、未確認事項を後続作業へ渡す文脈管理の道具になる。
本稿が特に重視するのは、内的状態を外部に出すこと自体ではない。表現が他者に共有され、根拠や前提を検証され、将来の判断や学習に再利用されることである。単なる独白や一回限りの発話ではなく、後から読み返せる要求仕様、設計メモ、Architecture Decision Record（ADR）、レビューコメント、障害報告、AI出力レビューとして残るとき、言語化能力は実務成果物の品質に結びつく。
この定義を明確にするため、本稿では狭義の言語化と広義の言語化を区別する。狭義の言語化は、自然言語による発話や文章化を指す。第2章・第3章で整理した批判は、主にこの狭義の言語化、とりわけ口頭での即時応答や評価場面での説明要求に向けられていた。これに対し、本稿が扱う広義の言語化は、内的な認識、判断、仮説、制約を、他者が追跡できる記録や構造として表す活動を指す。ここでいう広義の言語化は、コードや図表をすべて言語化と呼ぶ定義拡張ではない。自然言語、コード、図表、ログ、仕様、テンプレートが、同じ目的、制約、判断理由、検証条件を指すように結びつけられているかを問題にするための定義である。
この関係を三要件に沿って言えば、用語集、レビュー規約、運用手順のような外部表現は、語彙・概念化や共同言語形成を成果物上に固定し、共有可能性を支える。要求仕様、設計メモ、障害時系列は、情報を読み手が追跡できる構造へ配置し、検証可能性を支える。メモ、チェックリスト、ログ、設計図は、個人の記憶を補い、後続の判断が前提へ戻るための文脈管理の道具として機能し、再利用可能性を支える（Zhang & Norman, 1994）。
したがって、以下の七要素は、文献上の概念をそのまま列挙したものではない。各節では、成果物上の失敗、その失敗を直す記述単位、必要な文献上の根拠の順に整理する。
語彙・概念化とは、経験や観察に名前を与え、事象を分類し、要求、設計、コード、レビューで同じ対象を同じ概念として扱えるようにする働きである。成果物上の失敗は、区別すべき対象が同じ名前で表されたり、同じ対象が複数の名前で参照されたりすることで、関係者が異なる前提を同じ語で読んでしまう点にある。この失敗を直す記述単位は、ドメイン用語、クラス名、関数名、イベント名、状態名、用語定義である。この側面で問われるのは語彙量そのものではなく、同じ対象を同じ名前で扱えるようにし、異なる対象には異なる名前を与える実践である。
「ユーザー」と「アカウント」を区別するか、「注文」と「契約」を区別するか、「削除」と「無効化」を区別するかは、単なる命名上の好みではない。それは、業務上何を同じものと見なし、何を別のものと見なすかの判断である。Carroll（1993）は、人間の認知能力が言語能力、理解、語彙、推論など複数の下位能力と関係することを示している。Levelt（1989）は、発話産出を、意図形成から言語形式への変換を含む過程として説明している。これらは、言語化が単一の出力行為ではなく、概念化、語彙選択、形式化を含む複数の過程に支えられることを示す。
この記述単位をソフトウェア設計側から補う文献が、Evans（2003）のドメイン駆動設計とFowler（2006）のユビキタス言語である。これらは、ドメイン専門家と開発者が共有する言葉をモデルやコードに反映する実践を論じており、曖昧な要望や実装対象をチームで扱える概念へ切り出す必要性を説明する。
構造化は、要求仕様、設計メモ、障害時系列の中で、情報が階層、因果、時系列、対立、依存関係として配置されているかを確認する要素である。情報を列挙するだけでは、実務上の説明は成立しない。成果物上の失敗は、問題、理由、選択肢、判断基準が混在し、読み手が結論までの経路を追跡できないことである。この失敗を直す記述単位は、背景、制約、代替案、判断理由、影響範囲、例外条件である。
よい設計説明は、単に結論を述べるのではなく、これらの単位を適切な順序で配置する。要求仕様においても、利用者の目的、機能要件、非機能要件、受け入れ条件、例外条件を整理しなければ、実装や検証に使える文書にはならない。Flower and Hayes（1981）は、文章作成を計画、文章化、見直しの相互作用として捉えた。この知見は、書くことが単なる逐語的出力ではなく、計画と再検討を含む認知過程であることを示す。本稿ではこれを、要求、設計、障害時系列を実装や検証に使える構成へ整える働きとして読む。
メタ認知とは、自己またはチームが何を理解しており、何を未確認のまま判断しているかを監視し、その範囲を外部表現に反映する働きである。成果物上の失敗は、観察した事実、推測、理解済み事項、未確認事項が混ざり、判断の射程が分からなくなることである。この失敗を直す記述単位は、確認済み事項、未確認事項、仮説、保留条件、追加検証の項目である。Flavell（1979）は、メタ認知を、認知についての知識と認知の監視として論じた。本稿ではこの知見を、自己の理解範囲を外部表現に反映する働きの基礎として用いる。
自己の理解範囲を監視できていない場合、説明は過度に断定的になる。前提を把握しないまま結論を述べたり、観察していない事実を推測で埋めたり、理解していない設計を理解したつもりで変更したりする。逆に、メタ認知が働いていれば、「このログから言えるのはここまでである」「この仮説はまだ検証していない」「この判断は性能要件を前提としている」と表現できる。障害対応やAI出力評価では、この働きが、事実、仮説、未検証の前提を分けて残す記述として必要になる。
文脈管理は、複数の論点、制約、履歴、未解決事項が、後から同じ前提や論点を参照できる形で、影響範囲、会議メモ、論点リスト、既存設計との照合記録などに残されているかを確認する要素である。成果物上の失敗は、過去の決定、現在の制約、相手の関心、未解決の論点、実装上の影響が会話や個人記憶に閉じ、後続者が同じ前提へ戻れなくなることである。この失敗を直す記述単位は、影響範囲、決定履歴、未解決論点、確認済み事実、参照先である。作業記憶とは、情報を一時的に保持し操作する認知機構であり、Baddeley and Hitch（1974）は、短期記憶を単なる保管場所ではなく、複数の情報を処理する作業記憶として捉えた。
実務で必要な文脈管理は、作業記憶の容量だけに依存するものではない。上記の記述単位は、個人の頭の中に保持し続ける対象ではなく、メモ、議事録、ADR、チケット、設計図、チェックリストに移して扱うべき対象である。したがって本稿では、作業記憶を、複数情報を一時的に扱う個人内の認知機構として位置づけ、文脈管理を、その限界を補うために外部表現を配置し、後から参照できる形に維持する実務上の働きとして区別する。
複雑なコードレビューでは、対象コードの局所的な変更だけでなく、既存設計、テスト、運用、将来の拡張可能性を同時に考慮する必要がある。このとき重要なのは、すべてを記憶して即座に説明することではなく、影響範囲、未確認事項、過去の判断、確認済みの事実を記録し、レビュー参加者が後から同じ前提や論点を参照できるようにすることである。障害対応でも、事実、時系列、仮説、影響範囲、暫定対応、恒久対応を混同せずに扱うには、個人の記憶に頼るより、時系列表、仮説リスト、対応ログとして文脈を外部表現に移す方が適している。コードレビュー、障害対応、ドキュメントでは、この記録化が参照性を支える。
説明・論証とは、主張、根拠、前提、例外条件、代替案を分けて示し、他者が賛否や修正案を返せる状態にする働きである。成果物上の失敗は、ADR、技術選定理由、レビューコメントにおいて主張だけが残り、判断材料となる根拠、制約、代替案、見直し条件が読めないことである。この失敗を直す記述単位は、主張、根拠、前提、例外条件、代替案、採否理由である。Toulmin（1958）の論証モデルが示すように、主張は根拠や保証と結びついて初めて検討可能になる。
たとえば、「このモジュールを分割すべきである」という主張は、それだけでは十分ではない。変更理由、現在の問題、想定される代替案、分割による利点、移行コスト、失敗した場合のリスクを示すことで、初めてチームは判断できる。Chi et al.（1989）の自己説明研究は、説明が学習と理解を促進しうることを示す。ここでは、設計判断の説明が他者を説得するためだけでなく、自分の理解の不足を発見するためにも重要であることを示す根拠として用いる。設計、レビュー、障害報告では、この働きが採否理由と、主張が成り立たない条件を成果物へ残す力として現れる。
「危ない」「納得できない」といった未分化な反応は、そのままでは判断根拠にならない。しかし、それをコードスメルの指摘、仕様リスク、運用上の不安、確認依頼へ変換できれば、チームは懸念を扱える。10 違和感・懸念の論点化は、「不安」「違和感」「危うさ」「納得できなさ」を、観察、発生条件、仮説、確認事項へ分け、攻撃的でない形で共有可能にする働きである。
本節では、この働きを三つの層に分けて扱う。第一は、個人内の未分化な感覚に名前を与える層である。第二は、組織内で懸念を表明できる条件を整える層である。第三は、記録の中で観察、仮説、確認事項へ分け、後続の検討に渡す層である。このうち本節の主対象は第三層、すなわち実務成果物上の論点化である。第一層と第二層は、未分化な感覚を排除せず扱うための補助条件として参照する。11
第三の層で重視するのは、感情をそのまま正当化することではない。未分化な懸念を、他者が検討し、必要なら対応できる論点へ変換することである。具体的には、違和感を対象、発生条件、観察、仮説、確認事項へ分け、検証可能な作業記録として残す運用が必要になる。
コードレビューでは、「この関数は危ない」ではなく、「例外時にロック解放が保証されるか未確認である」と書けば、確認すべき観察対象が定まる。仕様レビューでは、「この仕様は不安である」ではなく、「返品処理とキャンセル処理が同じ状態名を使っており、会計処理の分岐条件が未定義に見える」と書けば、用語と条件の確認に進める。障害対応では、「再発しそうで怖い」ではなく、「暫定対応後に監視条件が更新されていないため、同じ兆候を検知できない可能性がある」と書けば、運用手順の修正対象になる。
ただし、違和感を直ちに整った説明へ変換することを常に求めるべきではない。Schooler and Engstler-Schooler（1990）が示したように、早すぎる言語化は認識を狭めることもある。したがって、違和感は、十分に構造化されていない初期的な表現として一度受け止められたうえで、対象、観察、仮説、確認事項へ徐々に分けられるべきである。コードレビューや障害対応では、この働きが、攻撃ではなく修正可能な観察として懸念を伝える力になる。
共同言語形成とは、チーム内で同じ概念を同じ名前で扱い、その名前が指す責務や制約を安定させる働きである。成果物上の失敗は、個人がその場では説明できても、用語、責務、判断基準がチーム内で安定して参照されず、判断が属人的に再解釈されることである。この働きは、用語集、ドメインモデル、API名、ADR、設計原則、レビュー規約などに現れる。確認すべきなのは、同じ語が同じ対象を指し、同じ判断基準として後続者に参照されるかである。
Evans（2003）がDDDにおいて論じたユビキタス言語は、ドメイン専門家と開発者が同じ言葉でモデルを語り、その言葉をコードにも反映する実践である。本稿ではこの知見を、業務上の概念、責務、状態、制約を、会話だけでなくモデル、クラス名、イベント名、APIの語彙へ反映する必要性を示す根拠として用いる。ここで重要なのは、用語を統一すること自体ではなく、同じ語が同じドメイン上の区別を指し、実装上の構造と対応することである。
API設計、用語集、ADR、設計原則、レビュー規約は、共同言語を維持するための実務上の外部表現である。これらは、個人の判断をその場の発話に閉じず、後から参照できる語彙、責務、採否理由、判断基準として残すために使われる。Nonaka and Takeuchi（1995）の知識創造論は、暗黙的な判断や経験を組織的に共有可能な知識へ移すという観点から、この主張を支える。ただし、共同言語が常に暗黙知を形式知へ十分に変換するわけではない。共同言語形成は、言語化能力が個人の発話技能ではなく、要求、設計、ドキュメントをチームで再利用できる資産へ変える条件である。
以上のように、言語化能力は単一の才能ではなく、複数の認知的・社会的な働きから構成される複合的技能である。本章の七要素は、成果物を確認するための分析枠組みである。次章では、この七要素をそのまま採点項目にするのではなく、要求仕様、設計文書、レビューコメント、障害報告、ドキュメントに現れる記述不足や検証不能性を、成果物から確認できる失敗類型として検討する。
前章では、言語化能力を七要素からなる分析枠組みとして定義した。本章では、この枠組みをソフトウェアエンジニアの日常業務に適用し、抽象的なコミュニケーション能力ではなく、要求定義、設計、実装、コードレビュー、障害対応、ドキュメントという具体的な成果物の品質として検討する。第4章が、要求仕様、設計文書、命名、テスト名、ログ、レビューコメントなどを通じた共有・検証の実践への依存を原理的に述べたのに対し、本章は、成果物に記録された記述不足、区別不足、検証不能性を、実務上の失敗類型として整理する。各節では章間対応を繰り返すのではなく、どの実務場面で何が検証不能になり、どの成果物上の記述を補うべきかに焦点を置く。詳細な対応一覧は付録Aに置く。
要求定義では、ユーザーや事業担当者の要望を、そのまま実装項目に変換してはならない。実務上の要望は、しばしば目的、制約、前提、例外、受け入れ条件が混在した形で表明される。要求仕様では、目的、制約、受け入れ条件、検証方法の分離がまず問われる。これらが同じ箇所に混在すると、後続の設計者や実装者は、何を満たせば要求が成立したと言えるのかを判定できない。したがって、要望、業務制約、受け入れ条件が一つの文に圧縮されていないか、要求ID、検証方法、関連する業務目的への参照が残っているかを読む必要がある。
この過程が失敗すると、検証可能性が失われる。たとえば「検索しやすくしたい」「管理画面を改善したい」「通知を柔軟にしたい」といった要望が、利用者の目的、業務フロー、入力、出力、制約、非機能要件、受け入れ条件に分解されていなければ、実装後に何を満たせばよいかを確認できない。さらに、それぞれの要求がどの事業目的に結びつくのか、どの制約のもとで優先されるのかを説明する必要がある。Wiegers and Beatty（2013）やISO/IEC/IEEE 29148:2018が要求の明確性、検証可能性、追跡可能性を重視するのは、要求が合意形成と検証の基盤になるためである。この場面で中心になるのは、用語を安定させ、目的、制約、受け入れ条件を後続工程で照合できる単位に分けることである。
要求定義における言語化能力が弱いと、開発者は利用者の言葉をそのまま実装し、後になって「本当に必要だったもの」とずれた成果物を作る危険がある。この危険を低減するには、要求仕様に目的、制約、受け入れ条件、検証方法、追跡先を分けて記録し、後続工程で照合できる状態にする必要がある。逆に、よい言語化は、要望の背後にある目的を捉え、複数の実現方法を比較し、最小限の実装で価値を検証する可能性を開く。
要求定義に固有の失敗は、要望、業務制約、受け入れ条件が同じ文に圧縮され、合意した対象と検証すべき条件を後続工程で再確認できなくなる点にある。評価時にこれらの記述をどの証拠として読むかは、第9章で整理する。
設計とアーキテクチャ判断では、責務、境界、依存関係、変更容易性を言語化する必要がある。第5章の定義に即していえば、設計における言語化とは、設計者の頭の中にある判断や予測を、他者が検討できるモデル、図、命名、ADRなどへ変換することである。Parnas（1972）が示したように、モジュール分割は、将来変更されうる設計判断をどこに隠蔽するかという問題である。これは、単にコードを小さな単位へ分けることではなく、どの概念がどの責務を持ち、どの依存を許容し、どの変更に備えるかを説明することである。
実務では、設計判断はしばしばトレードオフを含む。性能を優先すれば単純性が損なわれる場合があり、汎用性を高めれば初期実装が重くなる場合がある。将来の拡張に備える設計は有用だが、過度な抽象化は現在の理解を曖昧にする。したがって、設計説明では、採用案だけでなく、却下した案、前提条件、許容したリスク、後で見直すべき条件を残す必要がある。設計文書やADRを読む際には、結論だけでなく、代替案、判断基準、副作用や不利益、見直し条件が残っているかを確認する。これらを残せなければ、将来の変更者は結論だけを引き継ぎ、なぜその設計が妥当だったのか、いつ見直すべきなのかを判断できない。設計場面の検査対象は、概念や依存関係の正しさだけではなく、判断が置かれた前提と見直し条件が記録上たどれるかである。
第4章で述べたArchitecture Decision Record（ADR）は、このような判断を組織の記憶に変換する形式である。Nygard（2011）は、ADRを、構造、非機能特性、依存関係、インターフェース、構築技法などに影響するアーキテクチャ上重要な決定を記録するものとして説明し、軽量な記録項目として文脈、決定、状態、帰結を示している。この基本項目は、結論だけでなく、決定が置かれた文脈と、その決定がもたらす帰結を将来の読者へ残すための最小構造である。
したがって本稿では、ADRや設計メモの点検時に、文脈、決定、状態、帰結が記録されているかをまず確認し、そのうえで、代替案、却下理由、判断基準、副作用や不利益、見直し条件が、設計判断の検証可能性と再利用可能性のために十分残っているかを確認する。ここで重要なのは、特定のテンプレート欄を増やすことではなく、後続者が「なぜその案が選ばれ、どの条件なら見直すべきか」をたどれることである。設計における言語化能力は、現在の判断を他者と未来の自分が検証できる形にし、前提が変わったときに判断を再検討できる記録として残す能力である。12
設計に固有の失敗は、採用案だけが残り、代替案、却下理由、許容した不利益、見直し条件が消えることで、後続者が前提変化時にどの判断を再検討すべきかを追跡できなくなる点にある。
実装における言語化能力は、コードとは別の説明文を書く能力だけではない。命名、関数分割、テスト名、コメント、ログ、例外メッセージの中に、実装者の理解、責務境界、想定する状態、失敗時の扱いが現れる。コードは機械への命令であると同時に、後続の保守者が意図を読み取る外部表現でもある。したがって実装中に問われるのは、処理が動くかだけでなく、どの概念がどの名前で表され、どの責務がどの単位に閉じられ、どの条件を満たすと正しいと言えるのかが、後から読めるかである。
命名が曖昧であれば、ドメイン上の区別がコード上で消える。「無効化」と「削除」、「注文」と「契約」、「認証」と「認可」が同じ語で扱われれば、仕様、実装、レビュー、運用手順の間で前提がずれる。関数分割が責務境界を反映していなければ、障害時にどの条件で失敗したのかを追跡しにくい。テスト名が期待する振る舞いや境界条件を表していなければ、後続の変更者は何を壊してはならないのかを判断しにくい。コメント、ログ、例外メッセージも同様に、単なる補足ではなく、実行時の状態や判断理由を後続者が検証するための記録である。
Martin（2008）やFowler（1999/2018）が重視する命名、関数分割、重複除去、リファクタリングの実践は、単なる美的好みではない。それらは、実装上の概念、責務、変更理由を読み取り可能にする実践である。Knuth（1984）の文芸的プログラミングも、プログラムを人間が理解する説明として扱う発想を示す。ただし、本稿が主張するのは、すべての実装に長い説明文を加えるべきだということではない。必要なのは、コード、テスト、ログ、コメント、例外メッセージが、同じ目的、制約、判断理由を指し、後続のレビューや障害対応で検証できることである。実装場面では、抽象的な説明文を増やすよりも、名前、単位、テスト名、失敗時の出力が同じ概念区分を保っているかが重要になる。
実装に固有の失敗は、同じ概念が命名、関数分割、テスト名、ログ、例外メッセージの間で別々に表され、コードは動いていても、保守者が責務境界や変更時の検証条件を特定しにくくなる点にある。
コードレビューは、言語化能力が最も日常的に現れる場面の一つである。第5章の定義に従えば、レビューにおける言語化とは、読み手の違和感や設計上の懸念を、書き手が検証し修正できる観察、理由、提案へ変換することである。レビューでは、対象コードの問題を見つけるだけでは不十分である。その問題を、書き手が理解し、修正でき、チームの学習につながる形で伝える必要がある。
悪いレビューコメントは、しばしば印象や人格評価に近づく。「読みにくい」「雑である」「設計が悪い」といったコメントは、書き手に防衛的反応を生みやすく、修正可能性も低い。レビューコメントでは、対象箇所、確認された事実、問題となる理由、影響、代替案が、書き手の次の修正に使える形で示されているかが重要である。これらが欠けると、書き手は何を直すべきかを特定できない。よいレビューコメントは、観察、理由、影響、提案を含む。たとえば、「この関数は認証、入力検証、永続化を同時に扱っているため、失敗時の責務が追いにくくなっている。認証結果の確認を別関数に分けると、テスト対象を分離できる」というコメントは、問題の所在と改善方向を示している。
この主張は、レビューコメントの有用性が技術的内容だけでなく言語的特徴にも左右されることを示す研究とも整合する。Turzo and Bosu（2023）は、OpenDev Novaプロジェクトのコードレビューコメントを対象とした実証研究において、コメントの有用性が、欠陥指摘や品質改善提案のような技術的内容だけでなく、理解可能性や丁寧さといった言語的特徴にも関係すると報告している。本稿ではこの知見を、レビューコメントを相手が理解し、修正に使える単位へ整える必要性を説明する根拠として用いる。
ただし、同研究は特定のコメント形式が訓練効果をもつことを直接示すものではない。したがって、人格評価的または攻撃的な表現を避ける必要は、同研究だけから導くのではなく、対人関係上のリスクを取れるという共有認識が学習行動と関係するというEdmondson（1999）の心理的安全性の議論と接続して捉える。結論として、レビューコメントは、対象箇所、観察、理由、影響、提案を分け、書き手が修正でき、チームが同種の判断を再利用できる形に整える必要がある。
前節で述べた命名、関数分割、リファクタリングの観点は、レビューでは修正可能な観察として表現される。レビューにおける言語化能力は、違和感を攻撃ではなく、対象箇所、観察、理由、影響、提案へ変換する能力である。ここでの要点は、書き手の資質を評価することではなく、どの箇所のどの性質が、どの変更リスクや保守上の負荷につながるのかを示すことである。
コードレビューに固有の失敗は、違和感が対象箇所、観察、理由、影響、提案へ分けられず、書き手が検証できる修正単位にも、チームが同種の判断を再利用する材料にもならない点にある。
障害対応では、事実、時系列、仮説、原因、影響、対応、再発防止策を区別して整理する必要がある。障害発生時には、情報が不完全であり、関係者の不安も高い。そのため、確認された事実と推測を混同すると、対応を誤る危険がある。障害報告に残る失敗類型としては、タイムライン、観測値、暫定仮説、確定した原因、顧客影響、暫定対応、恒久対応が同じ叙述に混在し、後から判断の妥当性を検証できない状態が挙げられる。第5章の枠組みから見ると、障害対応における言語化能力は、不完全な観察や、緊張の高い状況で生じる暫定判断を、時系列、仮説、影響範囲、対応記録という外部表現として記録・構造化する能力である。
ここでいう事後分析とは、障害後に影響、対応、原因、再発防止策を記録し、学習へつなげる作業を指す。GoogleのSite Reliability Engineering（SRE; サービスの信頼性をソフトウェア工学的に扱う実践体系）の文献では、この種の記録はポストモーテムと呼ばれ、インシデント、その影響、緩和・解決のための行動、根本原因、再発防止のための追跡行動を記録する文書として位置づけられている（Lunney & Lueder, 2016）。実務上重要なのは、「データベースが原因である」と断定する前に、どのメトリクスが変化し、どのログが出ており、どの時間帯にどの変更があったのかを記述することである。
事後分析は、個人責任の追及ではなく、組織学習のための言語化である。障害を一人のミスに還元すれば、表面的には説明が簡単になる。しかし、実際には、監視の不足、手順の曖昧さ、レビュー観点の欠落、アラート設計の不備、組織間の引き継ぎ不足など、複数の要因が絡むことが多い。
そのため障害後の記録では、個人の操作だけでなく、事実、時系列、仮説、影響範囲、責任分界、監視条件、連携条件、再発防止策の追跡条件を分けて残す必要がある。Lunney and Lueder（2016）は、ポストモーテム作成を処罰ではなく学習機会として扱い、blameless postmortem（非難を目的としない事後分析）では、個人やチームを断罪するのではなく、インシデントに寄与した原因を明らかにすることが重視されると述べる。事故分析の文献でも、Dekker（2014）は、失敗を不注意な個人の問題として扱うのではなく、制約、目標葛藤、手順、組織条件を含むシステムの中で理解する必要を論じている。
Edmondson（1999）の心理的安全性の観点からも、障害対応における言語化は慎重に設計される必要がある。失敗を話すことが処罰につながる環境では、真因は表面化しない。組織が学ぶためには、事実を正確に記述し、判断の背景をたどり、再発防止策を具体化する言語化が必要である。障害対応では、緊張の高い状況で生じた暫定判断を、事実、仮説、原因、影響、対応へ分離し、後から検証できる記録へ変換することが中心になる。
障害対応に固有の失敗は、時系列、観測値、原因仮説、確定原因、影響、対応が同じ叙述に混在し、当時の判断が妥当だったか、再発防止策が実行可能かを後から検証できなくなる点にある。
ドキュメント品質は、第5章で述べた「再利用可能な外部表現」への変換が、もっとも明示的に現れる場面である。コードだけでは、なぜその実装になったのか、どの制約を前提としているのか、どの判断が過去に却下されたのかまでは十分に伝わらない。設計文書、運用手順、用語集、ADR、障害報告、オンボーディング資料は、コードを読むだけでは得にくい文脈を補う。ただし、ドキュメントは暗黙知そのものを完全に形式知へ変換する手段ではない。ドキュメント化できるのは、暗黙的判断そのものではなく、後続者が判断を再現・検証するために必要な背景、制約、採否理由、見直し条件である。それらを、明示可能な範囲で共有資産にすることが知識継承における文書化の役割である。
ただし、ドキュメントは書けばよいというものではない。実装と乖離しやすく、更新されなければ誤った知識を広める。ドキュメントを再利用可能な外部表現にするには、参照性、更新可能性、実装との対応関係、見直し条件を確認する必要がある。文書上の用語がコード上の名前や設定値と対応しているか、更新責任、更新契機、関連するテストや運用手順への参照が示されているかによって、ドキュメントが再利用可能な知識になっているかを判断できる。
この四条件は、特定文献から直接導いた標準基準ではなく、共有可能性、検証可能性、再利用可能性を文書場面で点検するための本稿の操作的基準である。四条件は三要件に代わる別枠組みではない。参照性は読者が同じ対象へたどるための共有可能性を具体化し、実装との対応関係は共有可能性と検証可能性を同時に支える。更新可能性と見直し条件は、文書を将来の変更時にも使える再利用可能性に結びつき、同時に、前提や実装との差分を後から検証する条件にもなる。
| 条件 | 主に対応する三要件 | 説明 |
|---|---|---|
| 参照性 | 共有可能性 | 読者が必要な判断理由や用語を見つけられる。 |
| 更新可能性 | 再利用可能性、検証可能性 | 変更時に直すべき記述、更新責任、更新契機が分かる。 |
| 実装との対応関係 | 共有可能性、検証可能性 | 文書上の概念、設定、手順が、コード、テスト、運用手順と結びついている。 |
| 見直し条件 | 再利用可能性、検証可能性 | 前提が変わったときに、再検討すべき判断が残っている。 |
コードだけでは読み取りにくい設計判断は、構造、制約、相互作用、学習された教訓として補われる必要がある。Brown and Wilson（2011-2012）が編んだ The Architecture of Open Source Applications は、複数のオープンソースソフトウェアについて、作者や関係者が設計の背景、制約、構成要素の相互作用、運用上の教訓を説明する事例集である。この種の記述は、読者が必要な判断理由へたどる参照性、コードだけでは見えにくい構造や制約を補う実装との対応関係、将来の変更時に前提を再確認する見直し条件を考える手がかりになる。ただし同書は、ドキュメント品質の実証的測定結果ではないため、本稿では設計判断を後続者へ伝える記述例として限定して用いる。
この観点から見ると、知識継承における言語化能力とは、個人の頭の中にある判断を、他者が必要なときに参照し、検証し、更新できる記録として残す能力である。したがって記録すべきなのは、すべての詳細ではなく、読者が判断を再現するための背景、制約、用語、設計原則、実装との対応、見直し条件である。
ここまでの失敗類型は、場面ごとに異なるように見えるが、共通する構造を持つ。要求定義では合意条件が、設計では見直し条件が、実装では責務境界と検証条件が、レビューでは修正単位が、障害対応では原因仮説と再発防止策が、ドキュメントでは参照先と更新条件が、それぞれ検証可能な外部表現へ変換される。これらが記録されない場合、関係者は同じ対象を参照できず、判断の根拠を追跡できず、後続作業で前提を再利用できない。この構造は第5章の三要件に対応するが、本章の焦点は、三要件の再説明ではなく、成果物ごとに検証不能性や記述不足がどのように現れるかを示す点にある。次章では、AI協業において同じ失敗類型に加え、依頼条件、許可操作範囲、出力後レビューが記録対象に加わることを検討する。
AI協業では、言語化能力は不要にならない。むしろ、記録・検証すべき対象は、依頼条件、AIまたはAI連携ツールに許可した操作、出力評価、採否理由、追加検証事項にまで及ぶ。本稿でいうAI連携ツールとは、AIモデルの出力を用いて、ファイル編集、コマンド実行、テスト実行、外部ツール呼び出しなどを、開発環境上で実行または提案する支援ツールを指す。コード生成、要約、テスト作成、ドキュメント作成をAIが支援しても、人間が目的、制約、品質基準、未確認事項、リスク判断を外部表現として示さなければ、生成物を既存コード、設計判断、運用制約、業務要件へ統合できない。
本稿では、AI協業を、人間が人工知能（AI）に目的と制約を与え、出力を評価し、必要な修正指示を与え、既存設計・運用条件に照らして生成物の採否を判断する作業過程として用いる。以下では、この過程を、依頼、評価、修正、採否判断の循環として扱う。AI支援を前提としない開発を本章では「従来の開発」と呼ぶが、従来の開発でも、要求、設計、レビュー、障害対応には言語化能力が必要である。AI協業で変わるのは、その必要性が消えることではなく、記録対象が作業前条件、出力後の採否理由、既存設計・運用制約との照合結果へ広がることである。
本章の議論は、AI導入前後の能力重要度を直接測定するものではなく、AI協業の作業構造分析である。すなわち、依頼、評価、修正、採否判断という循環の中で、どの対象を記録し、何と照合すべきかを整理する。Stack Overflowの2025年開発者調査は、AI利用が実務上の背景になっていることと、出力の正確性を無条件には信頼できないという慎重な態度が併存していることを示す補助資料として参照する（Stack Overflow, 2025）。13 本章で扱う実務上の連鎖は、作業前に依頼条件を置き、生成物を既存文脈と照合し、出力の理解範囲を明示し、AI連携ツールに許可した操作を確認し、採用・棄却・保留の理由を後続作業へ渡すことである。
第5章の定義をこの循環に適用すると、焦点は「うまいプロンプトを書くこと」だけには収まらない。依頼文で示した目的、制約、品質基準を、テスト、レビュー記録、修正指示、AI連携ツールに許可した操作と照合できる形に残すことが問題になる。依頼、評価、修正、採否判断のそれぞれで、未検証の仮説を検証可能な外部表現に変える必要がある。
本稿が批判するのは、AIへの依頼文作成だけを独立した能力として切り出し、出力評価、採否判断、既存設計との照合を能力の範囲外に置く見方である。AI利用における言語化能力は、それとは異なる。目的の命名、タスクの分解、既存コードや設計判断との照合、採用・棄却理由の説明、リスク感知、チーム内基準の安定化が、生成物の扱いの中で一体として求められる。
AIへのプロンプトは、単なる質問にとどまらない。実務におけるプロンプトは、目的、背景、制約、入力、期待する出力形式、品質基準、禁止事項を自然言語で記述する仕様の一部として機能する。ここで「仕様」と呼ぶのは本稿の解釈である。第5章の定義に照らせば、プロンプト作成は、利用者の内的な意図や判断基準を、AIへの入力として機能し、かつ人間が後から意味、責任、採否を検証できる外部表現へ変換する作業である。その外部表現は、出力後レビューで、品質基準、変更範囲、未確認事項、採否理由を照合するための記録として再利用される。
ここでいうプロンプトは、第1章で述べたAIへの指示文を指す。本章ではそれを、仕様として機能する外部表現として扱う。システム指示とは、会話全体に適用され、AIが応答を生成する際に優先して参照する上位の指示を指す。出力スキーマとは、出力項目、型、形式をあらかじめ定めた定義を指す。これらは依頼文の言い回しだけでなく、出力後の確認方法を決める条件でもある。
たとえば「このコードを改善して」と依頼するだけでは、AIは性能、可読性、型安全性、責務分離や依存関係の整理、テスト容易性のどれを優先すべきか判断できない。実務上必要なのは、対象コード、変更目的、変えてはならない振る舞い、望ましい出力形式、確認方法を分けて示すことである。これらが曖昧なままでは、出力後のレビューでも、何を成功と見なすかを判断しにくい。
OpenAI Help Centerは、ChatGPT向けのプロンプト作成指針として、明確で具体的な指示、十分な文脈、反復的改善を示している（OpenAI, n.d.-a）。またOpenAI API Docsは、要件を満たす出力を得るための指示作成、構造化されたメッセージ、テストと評価の必要性を示している（OpenAI, n.d.-b）。これらの公式文書は、依頼条件を構造化し、出力後に評価できる形へ置くための実務指針として読める。White et al.（2023a）やSasaki et al.（2024）の整理も、プロンプト作成が表層的な文言調整ではなく、問題の型、制約、期待する出力を構造化する作業に関わることを示す。したがって本節の焦点は、依頼文を、後続の評価にも使える仕様へ変える点にある。
AI利用には、生成物だけを受け取る利用と、AI連携ツールにファイル変更、テスト実行、外部ツール利用などの操作を許す利用がある。前者は、AIが返したコード片、説明、テスト案、文章案などを人間が受け取り、採否を判断する利用形態である。後者は、AI連携ツールが開発環境上のファイル、コマンド、テスト、外部ツールに関与し、変更案の作成や実行を伴いうる利用形態である。どちらの場合も、依頼前に残した条件が出力後の採否判断で参照されなければ、AI出力の評価は印象に流れやすい。作業前条件は、生成のための依頼文にとどまらず、出力後に品質基準、変更差分、未確認事項、追加検証事項を読むための参照点になる。
生成物だけを受け取る利用では、対象、期待する出力、評価基準、参照してよい情報を明示することが中心になる。AI連携ツールにファイル編集やテスト実行などの操作を許す利用では、それに加えて、入力範囲、許可する操作、求める出力項目、人間の判断へ戻す条件を同じ作業単位の記録として残す必要がある。本節では、この後者を「AI連携ツールに操作を許可する利用」と呼び、単に生成物を返すAI利用と区別する。14
ここでいう入力範囲は、AIに渡す対象と渡さない対象を明確にする観点である。許可操作範囲は、許可する操作、禁止する操作、承認を要する操作を分ける観点である。出力形式は、単なるファイル形式ではなく、変更理由、影響範囲、実行したテスト、未確認事項など、レビュー可能な出力項目を指定する観点である。停止条件は、人間の承認や判断保留が必要な状態を記録する観点である。
両者の差分は、次のように整理できる。
| 利用形態 | 作業前に中心となる記録 | 出力後に中心となる確認 |
|---|---|---|
| 生成物だけを受け取るAI利用 | 依頼内容、期待する出力、評価基準、参照してよい情報 | 品質基準の充足、未確認事項、追加修正の要否 |
| AI連携ツールに操作を許可する利用 | 入力範囲、許可操作範囲、出力形式、停止条件、評価基準 | 許可外操作の有無、変更差分、検証結果、停止・承認条件との一致 |
この表は、依頼時の条件をレビューで参照できる形に保つための整理表である。生成物だけを受け取る利用では、対象機能、期待する出力、評価基準、参照してよい情報が、品質基準の充足や未確認事項を読む基準になる。操作を許す利用では、入力範囲、許可操作範囲、出力形式、停止条件が、変更差分、検証結果、未確認事項、許可外操作の有無を読む基準になる。
本節の結論は、すべてのAI利用に同じ重い事前統制を課すことではない。依頼時に定めた条件を、採用、棄却、保留、追加確認の判断で再利用できる形にすることである。AIセキュリティ文献との詳しい対応は付録Bに置く。
AIは有用な成果物を生成する一方で、もっともらしい誤りを出力しうる。コードは一見動作しそうでも境界条件を満たさず、自然に見える説明に前提の取り違えが含まれ、既存設計に沿った提案に見える変更がチームの制約や運用要件と衝突することもある。
評価の段階では、まず理解済み事項と未確認事項を分ける。ここで確認するのは、出力の意味をどこまで理解したか、既存設計や運用条件とどこまで照合したか、まだ確認していない前提が何かである。自分が何を知っており、何を確認していないのかを把握していなければ、AIの出力を適切に検証できない。AIが提示した説明を読んで、「この部分は根拠が示されていない」「この前提はプロジェクトには当てはまらない」「この変更は既存の運用手順を壊す可能性がある」と判断するには、人間側が基準と文脈を外部表現として持っていなければならない。この作業では、根拠不足、文脈不一致、未検証の前提、運用リスクが、レビュー記録や確認項目の単位になる。これは、第5章で述べたメタ認知だけでなく、文脈管理、説明・論証の働きとも結びつく。
Zamfirescu-Pereira et al.（2023）は、非専門家が大規模言語モデルへの指示設計で失敗する過程を分析し、ユーザーがモデルの振る舞いを十分に把握せず、試行錯誤を体系化できない問題を示した。この知見が直接示すのは、プロンプト設計の失敗が、単なる文言不足ではなく、モデル理解、問題設定、試行錯誤の記録方法と結びつくという点である。
本稿はこの知見を、実務上のAI出力評価へ拡張して読む。利用者が問題設定、評価基準、参照すべき文脈を外部化できなければ、出力後の採否判断も印象評価に流れやすい。したがって、生成コードや説明を受け取った後には、出力のどの範囲を理解したのか、既存設計や運用条件とどこが一致・不一致なのか、どの前提が未検証なのかを記録する必要がある。
この整理から、本節の実務上の提案が導かれる。AI出力の評価では、内的な違和感を「根拠不足」「文脈不一致」「未検証の前提」「運用リスク」といった検討可能な表現へ変換する必要がある。生成コードの理解、修正、デバッグの困難は、第7.5節でVaithilingam, Zhang, and Glassman（2022）を参照して扱う。
AI協業では、依頼とレビューが別々の能力として完結しない。依頼時に示した目的、制約、禁止事項、期待する出力形式は、出力後に品質基準、変更差分、既存設計との整合、未確認事項を確認する基準になる。たとえば、リファクタリングを依頼する段階で「外部APIの振る舞いを変えない」「既存テストを壊さない」「変更理由を説明する」と残しておけば、出力後レビューでは、振る舞いの維持、テスト結果、変更理由の妥当性を同じ条件に照らして確認できる。
この接続を欠くと、プロンプトは一回限りの依頼文になり、レビューは印象評価になりやすい。したがって本節の主張は、作業前条件を、出力後に採否理由や追加検証事項として記録する必要があるという点にある。要求抽出、制約指定、出力形式指定、代替案提示といった依頼条件は、依頼時にはAIに作業範囲と応答形式を与える条件であり、出力後には受け入れ条件、既存設計との整合、テスト条件、未確認事項、追加検証項目を照合する基準へ変わる。White et al.（2023b）のソフトウェア設計や要求抽出に関するプロンプトパターンは、この変換を直接証明する資料ではなく、依頼条件を構造化する例として位置づけられる。
本節で扱うのは、AIが生成した候補、修正案、説明、テスト案、ドキュメント案を受け取った後に、人間が何を確認し、何を採用し、何を棄却したかを後続作業へ渡すことである。複数候補の生成、反復的な修正、既存環境への統合を伴うAI協業では、作業前の条件に照らして、生成物の採否判断と既存コード、設計判断、運用制約との照合を残す。依頼時に言葉にした条件を出力後レビューで再利用し、判断基準、未検証事項、採否理由を人間が記録して初めて、成果物は保守可能な形で統合される。
AI出力後レビューでは、まず生成物の意味、変更範囲、未確認事項をどこまで理解したかを明らかにする。次に、その生成物をどの用途で採用するのか、またはなぜ棄却・保留するのかを、既存コード、設計判断、運用制約に照らして説明する。最後に、追加テスト、脆弱性確認、データ取扱い、許可操作範囲との一致を確認し、保留条件や追加対応を後続作業へ渡す。
本稿では、これらの記録項目を、理解範囲、利用目的・採否理由、追加検証・安全性確認の三分類として整理する。理解範囲は修正やデバッグへ移る入口になり、利用目的・採否理由は生成物を実務成果物へ統合する根拠になる。追加検証・安全性確認は、自然に見える出力や実行可能な変更を過信せず、後続の保守や監査で参照できる確認事項を残す役割を持つ。
理解範囲には、理解できた範囲、未確認事項、追加テストの必要性が含まれる。利用目的・採否理由には、既存設計との不一致、採用・棄却理由、修正指示が含まれる。追加検証・安全性確認には、脆弱性、許可操作範囲、データ取扱い、保留条件の確認が含まれる。したがって、運用上は、AI出力の自然さや実行可能性だけを確認するのではなく、依頼時に残した条件に照らして、何を理解し、何のために採用し、何を追加検証事項として残したかをレビュー記録へ渡す。15
このため、AI出力後のレビューでは、品質基準、理解できた範囲、未確認事項が、採用判断の前提を示す。利用目的、採用・棄却理由、既存設計との照合結果は、生成物を実務成果物へ統合する根拠になる。セキュリティ確認、追加検証事項、保留条件は、後続の保守や監査で参照される作業記録として残される。AIは判断責任を消すわけではない。
以上を踏まえると、AI協業がソフトウェア開発に組み込まれる場面で必要なのは、プロンプトの言い回しを暗記することではない。目的と制約を仕様化し、出力を批判的に評価し、必要な修正を指示し、チームの既存コード、設計判断、運用制約へ統合する能力である。AIに実行権限を与える場合には、入力範囲と除外範囲、許可する操作と禁止する操作、確認可能な出力項目、停止や保留の条件も同じ記録単位に含まれる。この能力は、第5章で定義した、観察、根拠、判断理由、検証条件を共有・再利用可能な外部表現として整える能力を、AIへの依頼、出力評価、成果物統合へ適用したものである。次章では、この能力を組織がどのように育成すべきかを論じる。
言語化能力は、個人の性格や生まれつきの才能だけで説明できるものではない。本章が対象とするのは、個人だけを訓練対象として切り出す施策ではなく、暗黙的知識や判断の根拠を、文書、テンプレート、用語集、レビュー記録として扱えるようにする組織的な仕組みである。
本章の教育指針は、心理的安全性を前提に、即答偏重を避ける時間配分、テンプレート、観察・解釈・判断を分ける練習、不足箇所への具体的フィードバックを組み合わせる点にある。その目的は、判断過程を実務成果物として記録・構造化し、後続作業で参照できる学習材料に変えることである。
以下では、まず導入前に整える条件を示し、次に教育設計の原理として、時間配分、テンプレート、観察・解釈・判断の分離、判断過程の記録を整理する。そのうえで、これらの原理を実装する導入運用を、記録、課題化、共有化の三段階として述べる。本章が扱うフィードバックは、改善機会を作る形成的支援であり、それ自体を処遇判断や能力判定へ直結させるものではない。個々の成果物をどう評価証拠として読むかは第9章で扱う。
未完成の説明を成果物上の論点へ育てるには、先に対人的リスクを下げる必要がある。心理的安全性は、他の教育指針と同列に置く一項目というより、未成熟な説明、違和感、不安、仮説、反対意見を扱う施策ほど優先して整えるべき導入条件である。心理的安全性とは、チーム内で対人関係上のリスクを取っても罰せられたり拒絶されたりしないという共有された認識であり、Edmondson（1999）は、チームの心理的安全性が学習行動と関連することを示した。本稿では、同研究を、未完成の説明や懸念を表明できる組織条件を考えるために用いる。
導入時には、四つの条件を確かめる必要がある。第一に、未分化な懸念に嘲笑や即時否定ではなく確認の問いを返せること。第二に、失敗報告が処罰や人格評価に直結しないこと。第三に、未確認事項や保留の記録が不利な評価だけに使われないこと。第四に、評価へ接続する範囲が事前に明示されていることである。これらの条件がなければ、「うまく言えないが違和感がある」という初期的な表現は、成果物に残る前に抑制されやすい。
ただし、心理的安全性は、曖昧な説明をそのまま放置することを意味しない。むしろ、十分に構造化されていない表現を、観察、対象、発生条件、仮説、確認事項へ分解するための条件である。ソフトウェア開発では、違和感や失敗報告を攻撃として扱わず、観察を確認し、対象を絞り、検証可能な論点へ育てることで、後述するテンプレート、観察・解釈・判断の分離訓練、三段階運用が機能する。したがって、心理的安全性は、単独の教育項目ではなく、支援手段、運用手順、反復的なフィードバックを成立させるための前提条件として位置づけられる。
即答偏重を避けるには、まず時間配分を変える必要がある。会議中にすぐ答えられることは、実務上有用な場面もある。また、熟達者が十分に構造化された領域で迅速に判断できること自体は否定されない（Kahneman & Klein, 2009; Ericsson & Kintsch, 1995）。しかし、それを言語化能力の中心指標にすると、会議中の即時応答で能力を示しやすい人だけが有利になる。調査、草稿化、非同期コメント、レビュー後の修正を通じて判断を精緻化する担当者や、文書による非同期の整理で能力を発揮しやすいメンバーは不利になりうる。複雑な設計判断、障害分析、要求整理では、その場での発話よりも、調査、草稿、レビュー、修正を経た説明の方が信頼できる場合が多い。
組織は、事前メモ、非同期コメント、レビュー時間、ドラフト提出を許容すべきである。会議で結論を急ぐのではなく、論点を持ち帰って整理する時間を認める。発言量だけで判断せず、後から提出された設計メモ、レビューコメント、障害分析、意思決定記録も検討対象に含める。教育設計の段階では、「その場で話せる人」と「後から深く整理できる人」の双方が記録を残せる条件を用意することが重要である。
確保した時間を記録へ変えるには、テンプレートによる支援構造が必要になる。ここでいうテンプレートは、完成文を強制する書式ではなく、判断理由、検証条件、未確認事項の欄を成果物に置く支援手段である。これにより、後続のレビュー、調査、設計判断で、何を観察し、何を根拠とし、何を未確認事項として残したのかを扱えるようにする。
この提案を支える補助概念として、学習者が自力では難しい課題に取り組めるよう支援を段階的に与える考え方を足場かけ（scaffolding）と呼ぶ（Wood, Bruner, & Ross, 1976）。また、Ritchhart and Perkins（2008）が論じる思考の可視化は、学習者の考えを外部に出し、他者が扱える形にする教育上の考え方である。足場かけは欄を置く支援原理を、思考の可視化は欄に残された記述を他者が読解・検討できる形にする必要性を支える。
本稿では、これらの教育上の考え方を実務成果物の欄設計へ翻訳する。第3章から第6章までで述べたように、実務上必要なのは、観察、根拠、判断理由、検証条件を共有・再利用可能な形で記録することである。テンプレートは、この認知過程を外部表現として記録するために、背景、制約、選択肢、却下案、帰結、確認済み事実、未確認事項を分けて見る視点を与える。これらの欄があると、採用案だけでなく却下案や制約を残し、どの事実を確認すれば判断を支持または修正できるかを示し、現時点の限界を後続の調査やレビューへ引き渡せる。
実務成果物ごとの欄設計は、各成果物が何を記録対象にしているかに応じて決める必要がある。ADR、プルリクエスト説明テンプレート、障害報告テンプレート、コードレビューコメントの型、要求整理テンプレート、上司・メンターとの一対一面談記録などは、判断理由、検証条件、未確認事項を残すための支援手段になる。これらは、先行研究で検証済みの標準手順ではなく、第5章の三要件を実務教育へ移すための本稿の設計案である。既存例との対応は脚注に置く。16
ただし、テンプレートは官僚的な記入作業になってはならない。すべての欄を埋めること自体が目的化すると、言語化は思考の支援ではなく形式的負担になる。テンプレートは、思考の型を学び、必要に応じて省略・拡張できる道具として扱うべきである。
テンプレートを有効にするには、観察、解釈、判断、提案を分けて書く訓練が必要である。実務上の混乱の多くは、観察された事実と、そこからの推測や評価が混同されることで生じる。第6章では、この混同がコードレビューや障害対応の成果物の品質を下げることを述べた。本章で重視するのは、その失敗を減らすための教育上の介入である。
この指針の理論的根拠は、主張と根拠を区別することが説明を検証可能にするという点にある。Toulmin（1958）の論証モデルは、主張、根拠、保証、限定条件、想定される反論を分けて扱うための枠組みとして使える。本稿では、この枠組みを、実務成果物上で観察、理由、判断、提案を分けるための理論的支えとして用いる。
コードレビューについては、Turzo and Bosu（2023）がOpenDevのレビューコメントを対象とした研究において、有用性が欠陥指摘や品質改善提案だけでなく、理解可能性や丁寧さといった言語的特徴にも関連すると報告している。この知見は、レビューコメントの内容だけでなく、読み手が理解しやすく、修正可能な形で記述することの重要性を示す補助根拠である。
以上を踏まえた本稿の教育設計は、レビューコメントを「観察、理由、影響、提案」に分けて書き直す練習を行うことである。メンターやレビュー担当者は、次に補うべき観察、根拠、未確認事項を修正可能な指摘として示す。ここでの指摘は練習用の返答であり、単発のコメントを評価結果へ直結させるためのものではない。障害報告や設計相談でも同じく、事実、仮説、判断、提案の混同をほどく練習が必要になる。これは、第6章で整理した観察と評価が混同されたレビューコメント、曖昧な問題提起、早すぎる原因断定を減らすための本稿の教育設計である。
観察と判断を分けられるようになったら、完成した成果物だけでなく、判断過程も記録対象に含める必要がある。コードや仕様は最終的な形を示すが、なぜその形になったのかまでは十分に伝えない。将来の開発者が必要とするのは、結論だけでなく、代替案、却下理由、制約条件、未解決の懸念である。
判断過程が残っていれば、後の変更時に過去の決定を再評価できる。たとえば、あるアーキテクチャが性能要件を理由に採用されたのであれば、性能要件が変わったときに見直せる。ある外部サービス連携が運用負荷を理由に見送られたのであれば、運用体制が変わったときに再検討できる。AIに作業を依頼する際にも、過去の判断過程が残っていれば、文脈として提示しやすい。
Argyris and Schön（1978）が論じた組織学習は、単なる結果の修正ではなく、行為の背後にある前提の検討を含む。判断過程の言語化は、この学習を可能にする。組織は、成果物の説明だけでなく、なぜその判断に至ったのかを残す文化を育てる必要がある。本節は、テンプレートや分離訓練を判断過程の記録へ広げる支援手段として位置づけられる。
教育原理を実務へ適用するには、記録、課題化、共有化を分けて導入する必要がある。記録は、未完成の判断を観察、未確認事項、採否理由、検証条件などの記述単位に分け、処罰ではなく確認可能な材料へ変える。課題化は、その記録に残った不足を、次回の成果物で補える観察、根拠、未確認事項として返す。共有化は、確認済みの判断や反復する基準だけを、後続者が参照する設計メモ、運用手順、用語集、レビュー規約へ移す。順序を分ける理由は、未完成の説明をいきなり処罰や選別の対象にせず、まず成果物上の記述単位へ分け、不足を次回の行動へ変え、確認済みの判断だけを共有資産へ渡すためである。17
| 段階 | 主な役割 | 代表的な成果物 |
|---|---|---|
| 1. 記録欄を限定して追加する | 未完成の判断を、未確認事項、採否理由、検証条件などの記述単位に分けて残す。 | プルリクエスト、ADR、障害報告、AI出力レビュー、AI作業前テンプレート |
| 2. 不足箇所を学習課題として設定する | 不足している観察、根拠、未確認事項を、次回の成果物で確認できる課題として示す。 | レビューコメント、メンタリング記録、次回作業の確認事項 |
| 3. 後続作業の参照先へ反映する | 確認済み事項や反復する判断基準を、後続者が参照する成果物へ記載する。 | 設計メモ、運用手順、用語集、レビュー規約、AI作業テンプレート |
運用上重要なのは、記録頻度と記録範囲を作業リスクに応じて明示することである。高リスクな設計変更、障害対応、セキュリティ上の判断、AIによる大きな変更では、背景、制約、未確認事項、検証条件、採否理由を厚く残す。一方、すべての作業に同じ量の説明を求めると、テンプレートは思考支援ではなく監視や儀礼になる。本節の要点は、記録、課題化、共有化を混同せず、未完成の説明を次の学習課題と共有資産へ変える順序を保つことである。
第一段階の入力は、作業中の仮説、解決できていない論点、採用しなかった案、確認した事実である。担当者の行為は、それらを完成した説明に整えることではなく、観察した事実、未確認事項、採否理由、検証条件、保留した論点として記入欄に分けて置くことである。代表的な成果物は、プルリクエスト説明、ADR、障害報告、AI出力レビュー、AI作業前テンプレートである。
判断基準は、後続者が「何が確認済みで、何が未確認か」を成果物から読み取れるかである。たとえば、プルリクエストでは変更理由、影響範囲、確認方法、未確認事項を分ける。障害報告では時系列、根拠ログ、原因仮説、再発防止策を分ける。AI作業前テンプレートでは入力範囲、許可操作範囲、出力形式、停止条件を分ける。記録欄は、学習者の説明不足を採点する欄ではなく、判断過程を次の確認へ渡す欄である。
第二段階の入力は、提出済み成果物に残った観察不足、根拠不足、未確認事項である。中心となる作業は、欄が埋まっているかを採点することではなく、次の提出物で補える記述単位を取り出すことである。代表的な成果物は、レビューコメント、メンタリング記録、次回作業の確認事項である。ここでの課題化は、短い時間幅で、次の実践に向けて不足を補う形成的支援である。一定期間の複数成果物から総括的に判断する第9章の評価コメントとは、時間幅、証拠範囲、用途が異なる。
判断基準は、指摘が後続作業の行動に結びつくほど具体的かどうかである。たとえば、「説明が足りない」という指摘は、「採用しなかった案の条件が残っていない」「障害時系列の根拠ログが欠けている」「AI出力を採用する目的と追加検証事項が分かれていない」のように書き換える。レビュー担当者やメンターは、完成答案を示すよりも、どの判断過程が見えないのか、どの根拠がまだ弱いのか、どの条件が未確認なのかを成果物上の確認項目として返す。学習者は、その確認項目を次回のプルリクエスト、設計相談、障害報告、AI出力レビューに持ち込み、同種の判断で補えたかを確認する。
第三段階の入力は、課題化を通じて補われた判断のうち、複数の作業で反復して使われるもの、または後続者が参照すべきものに限られる。ここでの中心課題は、不足指摘を繰り返すことではなく、補われた判断を再利用できる場所に記載することである。代表的な成果物は、設計メモ、運用手順、用語集、レビュー規約、チェックリスト、AI作業テンプレートである。AI作業テンプレートとは、入力範囲、許可操作範囲、出力形式、停止条件、出力後の評価基準を含む、チームで再利用する依頼条件のひな型を指す。
判断基準は、補われた判断が後続者に参照される場所へ記載され、更新条件まで残っているかである。概念や名称の混乱を減らすなら用語集、判断理由を将来再検討するならADRや設計メモ、再発防止や作業手順を安定させるなら運用手順、レビュー観点をそろえるならレビュー規約やチェックリスト、AI協業の依頼条件を再利用するならAI作業テンプレートが適している。同じ用語の揺れ、同じ確認漏れ、同じ採否理由、同じAI依頼条件が繰り返し現れる場合は、個別フィードバックだけでなく共有成果物へ反映する候補になる。反対に、一回限りの局所的判断や、まだ根拠が不十分な仮説は、共有規約へ急いで昇格させず、設計メモや確認事項として保持する方がよい。
この区別により、個人の説明不足を責める運用ではなく、成果物上で観察できた不足を、次の支援と共有成果物へ接続する運用になる。成果物ごとにどの記述を証拠として読むかは、第9章で扱う。
最後に、個人差は、選別ではなく支援設計の調整に用いるべきである。言語化能力を才能として固定的に扱うべきではないが、すべてのチームメンバーが同じ速度や媒体、同程度の支援条件で説明できると仮定することも現実的ではない。第5章で述べた七要素を支援設計に用いる際には、認知的負荷に関わりうる要因と、実務上の観察項目を分けて扱う必要がある。
第一に、語彙量や作業記憶は、第5章で扱った心理学・認知科学上の知見と接続する要因である。語彙量そのものは七要素の「語彙・概念化」と同一ではないが、経験や観察に名前を与える候補を広げる条件になりうる。作業記憶も七要素の「文脈管理」と同一ではないが、複数の制約、履歴、未確認事項を一時的に保持して操作する負荷に関わりうる（Carroll, 1993; Baddeley & Hitch, 1974）。ただし、第5章で述べたとおり、実務上の文脈管理は個人内の記憶容量だけに依存せず、メモ、議事録、ADR、チケット、設計図、チェックリストなどの外部表現によって支援される。
第二に、文章経験、図式化の得手不得手、口頭説明と文書による非同期共有の得手不得手は、心理尺度としてではなく、支援設計上の観察項目として扱う。これらは、個人を「文章型」「図解型」「口頭型」のように固定分類するための根拠ではない。むしろ、どの媒体や支援手段を用いれば必要な説明を低い負荷で提出できるかを決める手がかりである。文章経験が少ない場合は短い項目欄や例文、図式化が有効な場合は構成図や時系列表、口頭説明の負荷が高い場合は事前メモや非同期コメントを用意する。組織が見るべきなのは、個人の向き不向きではなく、どのような外部表現、テンプレート、レビュー時間、協働形式があれば、必要な言語化をより低い負荷で行えるかである。
教育に十分な時間や人員を割けない組織では、この観点が特に重要になる。全員に同じ研修を長時間課すことが難しい場合でも、メモを許容する、図で説明できる場を用意する、プルリクエストや障害報告に最小限の項目を設ける、口頭説明が苦手なチームメンバーには非同期コメントを認める、文脈管理が難しい議論では議事録と論点リストを併用する、といった支援は比較的低コストで導入できる。これは、個人差を「向き不向き」として固定するのではなく、実務上必要な言語化を発揮できる条件を整えることである。
以上の指針に共通するのは、言語化能力を個人の努力や話術だけの問題にしないことである。本章で示した順序の意義は、導入前に整える条件、支援手段、運用手順、定着条件を分けたうえで、未完成の説明を処罰や印象評価の対象にせず、不足している観察、根拠、未確認事項を次に補う課題として返せる点にある。これにより、言語化能力の育成は単発研修ではなく、実務成果物、支援条件、後続作業の参照先を結ぶ組織的な学習過程になる。次章では、教育介入ではなく、どのような証拠をもってこの能力を評価すべきかを考察する。
言語化能力を育成するためには、それをどのように評価するかを慎重に設計する必要がある。第8章は、判断過程を記録として残す支援の仕組みを設計する章であり、そこでのフィードバックは次の実践に向けた形成的支援であった。これに対し本章の固有の問いは、その仕組みのもとで、一定期間の複数成果物、担当機会、支援条件を併記したうえで、成果物に残るどの記述を評価対象にするかである。評価が誤れば、組織は再び、即時応答、話術、発言量を「言語化能力」と取り違える。したがって本章では、評価対象となる成果物、観察可能な証拠、避けるべき代理指標、フィードバックの提示方法に焦点を絞る。
まず、声の大きさ、発言量、即答の速さを評価指標にしてはならない。これらは情報共有や軽微な調整では有用な場合があるが、観察が正確であること、判断が妥当であること、他者の理解を助けていることを意味しない。熟達者が反復経験した型の問題では、即答であっても一定の妥当性を持つ判断になりうる（Kahneman & Klein, 2009）。しかし、複雑な設計判断や障害分析では、調査、検証、文章化、見直しに時間をかける方が望ましい場合が多い。評価上の問題は、これらの指標が成果物品質を測る代理指標として妥当性を欠きやすい点にある。さらに、根拠を確認する前に断定する行動や、発言しにくい立場にある人の知識や懸念を議論から失わせる行動を強化しうる。
また、抽象語を多用することや、もっともらしいが検証不能な説明も評価すべきではない。「本質的」「解像度が高い」「心理的安全性が低い」「技術的負債がある」といった語は、有用な分析概念になりうる。しかし、具体的な観察、根拠、判断基準、改善案が伴わなければ、議論の進展に寄与しない。Toulmin（1958）の観点から言えば、主張だけがあり、根拠や例外条件を欠く説明は、論証として弱い。
さらに、他者を黙らせる説得的な発話を評価してはならない。ソフトウェアエンジニアリングにおける説明の目的は、議論に勝つことではなく、判断を検証可能にし、チームがよりよい決定を行えるようにすることである。強い言い方によって反対意見を封じることは、短期的には合意を早めるように見えるが、長期的にはリスクの表明を妨げる。Edmondson（1999）が論じた心理的安全性の観点からも、他者が不確かな懸念を表明できる環境を維持することが重要である。
加えて、認知的特性や適性をそのまま評価項目にしてはならない。語彙が多い人、作業記憶への負荷が高い状況でも複数の情報を保持しやすい人、口頭での対話に抵抗が少ない人は、特定の場面で言語化を発揮しやすい場合がある。しかし、それは実務上必要な説明、判断記録、共同言語形成を安定して行えることと同義ではない。逆に、口頭での即時説明が苦手な人でも、メモ、図、非同期コメント、テンプレート、ペア作業を通じて高品質な言語化を行うことがある。評価は、個人特性そのものではなく、支援構造を含む実務環境の中で、共有可能で検証可能な表現を生み出せているかに向けるべきである。
第9章の三基準は、評価時に読む順序である。第一に、問題の具体化として、何を評価対象にするかを定める。第二に、理解範囲の明示として、その対象について何が確認済みで何が未確認かを見る。第三に、判断の再利用可能性として、採否理由や見直し条件が後続作業へ渡せるかを確認する。
たとえば障害報告に「検索が遅い」とだけ書かれている場合、評価者がまず見るのは、どの画面、どの条件、どの時間帯、どの利用者影響を指すのかである。この対象を絞る作業が、問題の具体化である。次に、確認済みの応答時間、未確認のクエリ、原因仮説、次に見るログが分けられているかを見る。この分離が、理解範囲の明示である。さらに、採った対応、見送った対応、再発時に参照すべき条件が残っていれば、判断の再利用可能性を読める。
本章では、この三つを評価基準と呼ぶ。これは第5章の三要件を、人事評価やレビューで読める記述へ変換するための手順である。ただし、単発成果物だけで個人能力を判定してはならない。評価時には、担当機会と支援条件を併記し、複数の成果物を見比べ、改善前後の変化を確認する必要がある。この前提を欠くと、成果物評価は第8章で避けた個人選別へ戻ってしまう。
各成果物で三基準を確認する箇所を、証拠の確認場所と呼ぶ。また、見つかった不足は、次に補うべき観察、根拠、未確認事項として記述する。成果物評価は個人の固定的能力を直接測るものではないため、担当機会、支援条件、複数成果物、改善過程と組み合わせて読むことを本章全体の前提とする。
第5章の三要件をそのまま評価語にしないのは、評価者が成果物上で扱う証拠が、抽象概念そのものではなく、具体的な記述として現れるからである。この変換関係の前提は第3章末で述べ、対応表は付録Cに整理した。第3章の三条件を、第5章では成果物要件へ、第9章では評価時に読む証拠へ変換している。
この順序は、抽象概念を成果物上の証拠へ移すための読み方である。問題の具体化では、目的、制約、観察、仮説、受け入れ条件、影響範囲が対象を絞る形で書かれているかを見る。理解範囲の明示では、確認済みの事実、未確認事項、原因仮説、次に調べる対象が区別されているかを見る。判断の再利用可能性では、代替案、採否理由、トレードオフ、将来の見直し条件が残っているかを見る。問題の具体化にも、観察と仮説を分けて検討できるかという検証可能性の側面が含まれるが、評価上は、まず対象を定め、次に確認済み範囲を分け、最後に判断を引き渡せるかを見る。
| 第9章の評価基準 | 第5章の三要件との対応 | 評価時の読み方 |
|---|---|---|
| 問題の具体化 | 共有可能性、検証可能性 | 目的、制約、観察、仮説、受け入れ条件、影響範囲が分けられ、同じ問題を他者が参照できるかを見る。 |
| 理解範囲の明示 | 検証可能性 | 事実、仮説、判断、提案、未確認事項が区別され、他者が追跡または反証できるかを見る。 |
| 判断の再利用可能性 | 再利用可能性 | 代替案、トレードオフ、採否理由、将来の見直し条件が残り、後続判断に使えるかを見る。 |
三つの評価基準が評価の主軸であり、成果物別の表は証拠の確認場所と、避けるべき代理指標を示す。この順序を取ることで、評価は話し方から受ける印象ではなく、後から確認できる記録に基づくものになる。
以下は、一般成果物に三基準を適用するときの確認場所である。AI協業に固有の追加確認項目は、表の後で分けて扱う。
評価者が成果物別に確認するのは、目的、制約、観察、仮説、判断理由、未確認事項、見直し条件が分けて記録されているかである。代表的な成果物は、要求メモ、プルリクエスト説明、Architecture Decision Record（ADR）、障害報告である。これらは会議での話し方から受ける印象と異なり、後から読み返し、修正し、複数人で検討できる記録である。
次の表は、成果物ごとにどの証拠を確認し、どの代理指標を避けるかを示す実務上の補助表である。表を使うときは、担当者がその成果物を書く機会を実際に持っていたか、テンプレートやレビュー時間などの支援条件が与えられていたか、複数成果物の間で記述が改善しているかを併記する必要がある。そうしなければ、成果物の違いを能力差として過剰に読んでしまう。
| 成果物 | 主に見る評価基準 | 証拠として確認する記述 | 避けるべき代理指標 |
|---|---|---|---|
| 要求メモ・要求仕様 | 問題の具体化、理解範囲の明示 | 目的、利害関係者、制約、受け入れ条件、非機能要件、未確認事項、追跡関係が分けて示されている。 | 要望の文章量、利害関係者の発言の強さ、曖昧な優先度表現。 |
| プルリクエスト説明 | 問題の具体化、理解範囲の明示 | 変更理由、確認方法、影響範囲、未確認事項が分けて示されている。 | 文章量、発話量、即答の速さ。 |
| ADR | 判断の再利用可能性 | 代替案、却下理由、制約、将来の見直し条件が残っている。 | 採用案だけの説得力、専門語の多さ。 |
| 障害報告 | 理解範囲の明示、判断の再利用可能性 | 時系列、観測値、原因仮説、確定原因、顧客影響、暫定対応、恒久対応、再発防止策、追跡条件が分けて記録されている。 | 早い原因断定、責任追及の明快さ。 |
AI協業で追加される確認項目は、AIへの依頼、出力評価、修正指示、採否判断が記録から検証できるかである。ここでも評価すべきなのは、プロンプトの技巧そのものではなく、同じ三基準をAI利用時の証拠へ適用できることである。依頼時の品質基準と利用目的は、問題の具体化に対応する。理解できた範囲と未確認事項の分離は、理解範囲の明示に対応する。採用・棄却理由と追加検証事項は、判断の再利用可能性に対応する。セキュリティ確認は、理解範囲の明示と判断の再利用可能性の両方に関わる。
| AI協業の利用形態 | 三基準に対応する追加確認項目 | 避けるべき代理指標 |
|---|---|---|
| 生成物だけを受け取る利用 | 依頼時の品質基準、理解範囲、利用目的、採用・棄却理由、追加検証事項、セキュリティ確認、既存設計との不一致が記録されている。 | プロンプトの技巧的表現、AI出力が一見もっともらしく見えること。 |
| AI連携ツールに操作を許可する利用 | 入力範囲、許可操作範囲、出力形式、停止条件、許可外操作の有無、変更差分、検証結果、停止・承認条件との一致が記録されている。詳細な記録観点は付録Bと対応する。 | AIが実行したこと、テストを実行したこと、または差分が小さいことだけで安全と見なす判断。 |
たとえばAIにリファクタリング案を依頼した場合、まず問題の具体化として、対象ファイル、変更目的、変えてはならない振る舞い、品質基準を確認する。次に理解範囲の明示として、AI出力のどの変更を読み、どのテストを確認し、どの副作用を未確認として残したかを読む。最後に判断の再利用可能性として、採用した変更、棄却した変更、追加検証事項、将来見直す条件が記録されているかを見る。同じ記述が複数基準に関わる場合でも、評価コメントでは、この順序に沿って主な不足箇所を一つずつ特定する。
AI連携ツールに操作を許可する利用でも、入力範囲、許可操作範囲、出力形式、停止条件は三基準に対応して読む。問題の具体化では、入力範囲と許可操作範囲により、AIまたはAI連携ツールがどの対象を扱い、どこまで変更してよいかを確認する。理解範囲の明示では、出力形式、変更差分、検証結果、未確認事項、許可外操作の有無により、人間が何を確認し、何を未確認のまま残したかを読む。判断の再利用可能性では、停止・承認条件との一致、採用・棄却理由、追加検証事項により、後続の保守や監査で同じ判断をたどれるかを確認する。
第7章では、AI出力後レビューで残す記録項目を、理解範囲、利用目的・採否理由、追加検証・安全性確認として整理した。第9章では、第7章で扱った関連研究の説明を繰り返すのではなく、各記録項目を評価時に確認する証拠として読み替える。すなわち評価者は、理解範囲、利用目的、採否理由、追加検証事項、セキュリティ確認が記録に残っているかを確認する。個別研究は、これらの欄を選ぶための補助根拠であり、三基準そのものや個人能力を直接測定する根拠ではない（Vaithilingam, Zhang, & Glassman, 2022; Barke, James, & Polikarpova, 2023; Perry et al., 2023）。
課題化の教育運用は第8章で扱ったため、ここでは、評価者がどの証拠を読み、どの代理指標を避け、どの記述不足に評価コメントを限定するかに焦点を絞る。第9.2節で証拠を確認した後、評価者が行うべきことは、不足箇所を実際の記述に即して特定し、観察、根拠、未確認事項、採否理由、見直し条件のどれが欠けているのかを示すことである。この評価コメントは、単発の練習への返答ではなく、複数成果物と支援条件を踏まえた総括的判断の根拠を明示するための記述である。この限定により、評価は「説明がうまいか」という印象ではなく、どの記述が不足しているかに基づくものになる。不足箇所を次回の学習課題や共有成果物へ接続する運用は、第8.6節の課題化・共有化に渡す。
評価コメントは、三基準に沿って証拠範囲を限定する。問題の具体化では、未分化な違和感が対象、発生条件、観察事実、確認事項へ分解されているかを見る。理解範囲の明示では、観察、解釈、仮説、未確認事項が混同されていないかを見る。判断の再利用可能性では、採用・棄却理由、制約条件、後で見直す合図が残っているかを見る。
| 評価基準 | 評価コメントで扱う証拠 | 代理指標として避けるもの |
|---|---|---|
| 問題の具体化 | 仕様上の違和感が、対象となる状態名、分岐条件、業務処理、確認事項へ分解されているか。 | 不安の強さ、発言の速さ、断定の強さ。 |
| 理解範囲の明示 | 障害報告やAI出力レビューで、確認済み事実、原因仮説、未確認の副作用、追加テストの対象が分かれているか。 | 「理解した」という自己申告、文章量、AI出力の自然さ。 |
| 判断の再利用可能性 | ADRや採否記録で、却下した代替案、許容した不利益、見直し条件、追加検証事項が残っているか。 | 採用案だけの説得力、専門語の多さ、プロンプトの技巧性。 |
評価コメントは、このように成果物上で確認できる記述単位へ限定する。教育上の課題化の手順は第8.6節で扱ったため、本節では、評価者がどの証拠に基づいて不足を指摘し、どの代理指標を使わないかに限って整理する。
以上から、言語化能力の評価は、会議での印象評価から切り離されなければならない。評価すべき対象は、成果物から確認できる説明と判断記録である。
具体的には、曖昧な問題を具体化し、事実と仮説を分け、代替案とトレードオフを示し、他者の説明や成果物、およびAIの出力を検証できているかを確認する。さらに、確認済み事項や判断理由を障害報告やADRへ移し、後から参照できるようにしているかも、判断の再利用可能性として評価する。
この観点に立つと、言語化能力は、話がうまい人を優遇するための評価項目ではなく、ソフトウェアエンジニアリングの成果を安定して高めるための実務能力として位置づけられる。
本稿は、言語化能力の過度な重視に対する近年の批判を出発点として、ソフトウェアエンジニアリングにおける言語化能力の位置づけを検討した。結論は三点に整理できる。
第一に、批判されるべきなのは、即答、発話量、抽象語の流暢さ、権力的な説明要求に偏った言語化であって、検証可能な記録を残す活動ではない。即時に応答できること、口頭で流暢に説明できること、抽象語を用いて説得的に見せることを、業務上の有能さと同一視してはならない。会議中にすぐ話せる人だけを高く評価すれば、調査、草稿化、非同期コメント、レビュー後の修正を通じて判断を精緻化する人、実装や観察を通じて深く考える人、まだ十分に言葉にならない違和感を持つ人を見落とす。また、心理的安全性を欠いた環境で「言語化せよ」と迫ることは、学習支援ではなく権力的な説明要求になりうる（Edmondson, 1999）。
第二に、ソフトウェアエンジニアリングで必要な言語化能力とは、観察、根拠、判断理由、検証条件を後から検証できる形で示し、目的や制約が自然言語、コード、図表、ログ、仕様などの複数の表現形式の間で食い違わないように保つ活動を可能にする能力である。この能力が、要求定義、設計、実装、レビュー、運用を含むソフトウェア開発を成立させる。AI協業でも、依頼条件を示し、出力を評価し、必要に応じて修正指示を与え、既存コード、設計判断、運用制約へ統合するには、同じ能力が必要になる。本稿のAI協業に関する主張は、AI導入後の能力変化を直接測定した経験的事実ではなく、AI協業の作業構造から導かれる理論的結論である。
第三に、組織は即答や話術ではなく、検証可能な記述を成果物に残す実践を育成し、その記述を評価すべきである。育成は支援構造の設計であり、評価は成果物に残る記述の確認である。未完成の判断を他者が確認できる記録や構造として表す条件を整え、その記録から問題の具体化、理解範囲の明示、判断の再利用可能性を評価し、次に補うべき観察、根拠、未確認事項を選ぶことが、本稿の提案する組織的対応である。
ただし、本稿の教育・評価提案は、成果物に残る証拠と支援構造を結びつける設計原理である。この限定を踏まえれば、組織は言語化能力を才能による個人選別に使うのではなく、担当機会と支援条件を併記したうえで、文書・レビュー記録・障害報告から読み取れる証拠を評価対象にすべきである。テンプレート、問い、レビュー体制は、その証拠を生み出す支援条件として別途点検する必要がある。
したがって、ソフトウェアエンジニアにとっての言語化能力は、あれば望ましい補助技能ではない。それは、要求を仕様に変え、設計判断を共有し、コードの意図を保守者が理解可能な形にし、レビューを学習に変え、障害を組織知に変え、AIの出力を実務成果へ統合するための基盤である。これからのソフトウェアエンジニアリング組織に求められるのは、即答偏重、表面的な流暢さ、権力的な説明要求を避けながら、判断理由を再利用可能な形にする能力を育成することである。
本付録は、第5章で定義した七要素が、第6章の実務場面および第7章の人工知能（AI）協業場面にどのように現れるかを確認するための索引である。ここでいうAI協業は、第7章と同じく、AIへの依頼、出力評価、修正指示、既存コード・設計判断・運用制約に照らした生成物の採否判断を含む作業過程を指す。以下の表は、個人を評価・分類する尺度ではなく、本文で述べた記述や記録を引くための補助資料である。
表中の七要素名は、第5章の定義を参照するための索引用の短縮名である。詳細な定義は第5章に置き、本付録では、各要素が実務成果物のどこに現れるかを確認するために用いる。たとえば「文脈管理」は、第5章で定義した七要素の一つであり、作業記憶の制約を補うために、制約、履歴、未確認事項を外部表現で維持する実務上の働きを指す。その他の「語彙・概念化」「構造化」「メタ認知」「説明・論証」「違和感・懸念の論点化」「共同言語形成」も、個人の下位能力名ではなく、成果物に残る記述を通じて共有可能性、検証可能性、再利用可能性を支える働きを指す。また、「典型的な外部表現」は、第5章で述べた「共有可能で、検証可能で、再利用可能な形式」の具体例である。
表A-1と表A-2では、要求メモ、設計図、ログ、チケット、ADR、レビューコメントなど、外部表現として保持され、他者が確認できる記録を「典型的な外部表現」として示す。複数の制約や履歴を扱う実務では、個人の記憶だけで文脈を保持するのではなく、これらの記録によって確認済み事実、未確認事項、判断理由、制約、代替案を配置し直す必要がある。
| 要素 | 実務上の現れ | 典型的な外部表現 | 主な実務場面 |
|---|---|---|---|
| 語彙・概念化 | 曖昧な要望、責務、状態、設計上の問題に名前を与え、議論可能な単位にする。 | ドメイン用語、機能名、状態名、責務名、レビュー上の問題名 | 要求定義・仕様化、設計・アーキテクチャ判断、コードレビュー |
| 構造化 | 情報を目的、制約、因果、時系列、依存関係、代替案として整理する。 | 要求仕様、設計説明、ADR、障害時系列、事後分析、ドキュメント構成 | 要求定義・仕様化、設計・アーキテクチャ判断、障害対応・事後分析、ドキュメント・知識継承 |
| メタ認知 | 自分やチームが何を理解しており、何を未確認のまま判断しているかを明示する。 | 未解決事項、前提条件、確認事項、リスク、判断保留の記録 | 設計・アーキテクチャ判断、障害対応・事後分析、コードレビュー |
| 文脈管理 | 複数の制約、既存設計、変更履歴、運用条件を外部表現で維持しながら説明・判断する。 | 設計背景、変更理由、影響範囲、運用手順、引き継ぎ資料 | 設計・アーキテクチャ判断、障害対応・事後分析、ドキュメント・知識継承 |
| 説明・論証 | 採用理由、棄却理由、影響、代替案、例外条件を示す。 | 受け入れ条件、設計判断、レビューコメント、再発防止策、技術選定理由 | 要求定義・仕様化、設計・アーキテクチャ判断、コードレビュー |
| 違和感・懸念の論点化 | 不安、危うさ、読みにくさ、納得できなさを、攻撃ではなく検討可能な論点にする。 | レビューコメント、リスク記録、障害時の懸念事項、事後分析の論点 | コードレビュー、障害対応・事後分析 |
| 共同言語形成 | 個人の説明を、チームや組織で再利用できる用語、基準、設計原則にする。 | 用語集、ドメインモデル、ADR、レビュー規約、オンボーディング資料 | 要求定義・仕様化、コードレビュー、ドキュメント・知識継承 |
表A-1が示すように、実務場面における言語化能力は、発話の流暢さではなく、未整理の情報を仕様、設計記録、レビューコメント、障害記録、ドキュメントへ変換する働きとして現れる。たとえば要求定義では、語彙・概念化と構造化が中心になるが、受け入れ条件を検証可能にするには説明・論証が働き、関係者間で用語を安定させるには共同言語形成が働く。設計・障害対応・知識継承においても、複数の要素が分離せず、成果物の品質として同時に現れる。
| 要素 | AI協業上の現れ | 典型的な外部表現 | 主なAI協業場面 |
|---|---|---|---|
| 語彙・概念化 | AIに扱わせる目的、ドメイン概念、品質基準、禁止事項を命名する。 | プロンプト、システム指示、用語定義、品質基準、タスク名 | プロンプトの仕様化、依頼とレビュー |
| 構造化 | タスク、入力、出力、制約、権限、検証方法を分解し、関係づける。 | 出力スキーマ、チェックリスト、テスト、ツール権限設計、評価手順 | プロンプトの仕様化、入力・出力・権限・検証方法の設計、依頼とレビュー、出力評価・採否判断 |
| メタ認知 | AI出力の限界と自己理解の限界を監視し、未検証の前提を明示する。 | 確認事項、採用を保留する条件、採用保留の理由、追加検証メモ | 出力評価・採否判断、依頼とレビュー |
| 文脈管理 | コードベース、既存設計、運用制約、過去の判断を記録と照合しながらAI出力を評価する。 | レビュー観点、既存設計との対応、変更影響の記録、統合方針 | 出力評価・採否判断 |
| 説明・論証 | AI出力を採用・棄却・修正する理由を説明し、判断を再利用可能にする。 | レビューコメント、修正指示、採用理由、棄却理由、評価レポート | プロンプトの仕様化、依頼とレビュー、出力評価・採否判断 |
| 違和感・懸念の論点化 | AI出力への不安や危うさを、根拠不足、文脈不一致、運用リスクなどの論点に変換する。 | リスク指摘、追加検証依頼、レビューコメント、修正指示 | 出力評価・採否判断 |
| 共同言語形成 | 人間とAIを含む作業過程で、用語、品質基準、判断基準を安定させる。 | AI作業テンプレート、評価基準、ガイドライン、運用ルール、チーム内の用語集 | プロンプトの仕様化、入力・出力・権限・検証方法の設計、依頼とレビュー、出力評価・採否判断 |
表A-2は、AI協業における言語化能力が、単なるプロンプト作成能力に還元されないことを示している。プロンプトやシステム指示は重要な外部表現であるが、実務上の成果は、出力スキーマ、テスト、権限設計、評価基準、レビューコメント、採用・棄却理由といった複数の表現に依存する。したがって、AI協業における言語化能力とは、AIに依頼する前に目的と制約を定義し、出力後に品質・文脈・リスクを評価し、必要な修正を指示し、その判断をチームで再利用可能にする能力である。
以上の対応関係は、第5章で定義した七要素を、第6章と第7章の実務場面に当てはめて整理したものである。各表は、本文の議論を読む際の索引として用いるべきであり、七要素を独立したチェック項目として機械的に採点するためのものではない。とりわけ実務では、一つの行為が複数の要素を同時に含む。設計判断の説明には構造化、文脈管理、説明・論証が含まれ、コードレビュー上の違和感の提示には語彙・概念化、違和感・懸念の論点化、共同言語形成が含まれる。したがって、本付録の表は、個人の下位能力を分断するためではなく、複合的な実践を読むための索引として扱う必要がある。
第7.2節で示した入力範囲、許可操作範囲、出力形式、停止条件は、本稿が、AI利用を実務上管理するために整理した四観点であり、公式標準や一般に確立したリスク分類として提示するものではない。本稿でいうAI連携ツールとは、AIモデルの出力を用いて、ファイル編集、コマンド実行、テスト実行、外部ツール呼び出しなどを、開発環境上で実行または提案する支援ツールを指す。本付録では、ファイル編集やテスト実行などをAIまたはAI連携ツールに許可する利用形態を扱い、そのうち許可・禁止・承認条件を読む観点を「許可操作範囲」と呼ぶ。許可操作範囲は、アクセス制御やユーザー権限の一般概念そのものではなく、作業前条件と出力後レビューを同じ記録単位で読むための実務上の整理である。本文では言語化能力との関係に焦点を絞るため、記録例と参照文献との対応を本付録に置く。
この利用形態では、少なくとも表B-1の四観点を記録対象として検討すべきである。四観点は、作業境界の命名、AIまたはAI連携ツールに認める操作と禁止する操作の区別、人間のレビューや自動検査で照合できる出力項目の設計、中断・承認条件の説明からなる。ここでいう照合できる出力項目とは、人間のレビュー、自動テスト、スキーマ検証、静的解析、ルールベースの確認などに渡せる形式を指す。
| 分類 | 明示すべき内容 | 記録例 |
|---|---|---|
| 入力範囲 | AIに渡すファイル、ログ、仕様、参照情報 | 対象ディレクトリ、除外する機密情報、参照専用資料 |
| 許可操作範囲 | AIまたはAI連携ツールに認める操作と禁止する操作 | 読み取り、差分作成、テスト実行、ネットワーク利用の可否 |
| 出力形式 | 人間が確認・レビューするための出力項目 | 変更理由、影響範囲、実行したテスト、未確認事項 |
| 停止条件 | 自動処理を止め、人間の承認を求める条件 | テスト失敗、権限外ファイル、秘密情報、設計変更の拡大 |
停止時には、承認者、承認条件、停止理由、関連ログを別途記録する。これらは停止を引き起こす条件そのものではなく、停止後に担当者が再開または棄却の判断を追跡するための記録内容である。
表B-2の文献は、四観点そのものを直接提示するものではなく、各観点を外部仕様として明示すべき理由を説明する資料である。
| 分類 | 参照文献が支える論点 | 本文で導く実務要件 |
|---|---|---|
| 入力範囲 | Chismon（2025）は、大規模言語モデル（large language model: LLM）ではプロンプト内部の命令とデータの境界が古典的なプログラムほど堅牢に分離されないと論じる。 | AIへ渡すファイル、ログ、利用者入力、参照専用資料を区別し、どれを命令として扱い、どれを参照専用データとして扱うかを作業前に明示する。 |
| 出力形式 | OWASP（2024）は、LLMアプリケーションの主要リスクとして不適切な出力処理（LLM05:2025）を整理している。 | AI出力をそのまま実行・保存・送信せず、変更理由、影響範囲、実行したテスト、未確認事項など、人間のレビュー、自動テスト、スキーマ検証、静的解析、ルールベースの照合で確認できる項目へ分ける。 |
| 許可操作範囲 | OWASP（2024）は過剰な自律性（LLM06:2025）をリスクとして扱い、Debenedetti et al.（2025）はツール呼び出し時の権限ポリシーを扱う。 | 読み取り、差分作成、テスト実行、ネットワーク利用など、AIまたはAI連携ツールが実行できる操作を最小化し、権限外の行為を停止させる。 |
| 停止条件 | OWASP（2024）はプロンプトインジェクション（LLM01:2025）を主要リスクとして扱い、Rebedea et al.（2023）は入出力や対話経路をモデル外部で制約する実行時制御規則（programmable rails）を扱う。 | どの入力、操作、出力を理由に自動処理を止め、担当者の承認を求める状態になったのかを記録する。停止理由、承認者、関連ログを後から追跡できる形で残すが、本稿では監査可能性を独立した第五の観点ではなく、停止後の判断記録に含まれる性質として扱う。 |
この四観点は、AIに作業を依頼する前のチェックリスト、出力後レビューの照合基準、停止時記録の項目として用いる。依頼前には、入力範囲と許可操作範囲により作業境界を確認し、出力形式と停止条件によりレビュー方法を確認する。出力後には、実際の変更差分、実行結果、未確認事項が、四観点に基づいて事前に定めた具体的な条件から逸脱していないかを照合する。停止時には、どの条件に触れたために自動処理を止めたのか、誰が何を確認すれば再開または棄却できるのかを記録する。このように読むことで、四観点は文献対応表ではなく、作業前条件、出力後レビュー、停止時判断を同じ記録単位で結びつける実務上の道具になる。
Rebedea et al.（2023）は、LLMアプリケーションの実行時にユーザー定義可能で解釈可能な規則を適用する制御機構を programmable rails として論じている。本稿では、これを比喩的な「ガードレール」一般としてではなく、入出力、ツール利用、対話経路、扱ってよい話題や操作を、モデル外部の規則、検査、実行時制御によって制限する仕組みとして参照する。これは、特定の基盤モデルの訓練時調整ではなく、実行時に追加される制御である。本稿ではこの概念を、出力形式の検査だけでなく、ツール呼び出しの可否、対話経路、禁止事項、停止条件を外部仕様として記述・実行する仕組みとして用いる。
この付録の目的は、AIセキュリティに関する包括的な統制分類を提示することではない。Chismon（2025）やDebenedetti et al.（2025）が示す命令とデータの分離の困難、OWASP（2024）が整理する不適切な出力処理・過剰な自律性・プロンプトインジェクション、Rebedea et al.（2023）が扱う実行時制御は、それぞれ射程が異なる。本稿はそれらを、ソフトウェアエンジニアが作業前後に記録すべき外部仕様、すなわち入力範囲、許可操作範囲、出力形式、停止条件という四観点へ翻訳して用いる。
本付録は、第3章の三条件、第5章の三要件、第9章の三基準の対応関係を確認するための補助表である。これらは一対一対応ではない。第3章の三条件は、言語化能力偏重への批判を受け止めた後に、どの条件を残すべきかを示す。第5章の三要件は、それを成果物の性質として読み替えたものであり、第9章の三基準は、評価時に実際の記述として読むための語である。
| 第3章の条件 | 第5章での成果物要件 | 第9章での評価基準 | 変換の理由 |
|---|---|---|---|
| 検証可能性 | 検証可能性 | 理解範囲の明示 | 観察、根拠、仮説、未確認事項を分け、他者が追跡または反証できるかを評価するため。 |
| 記録可能性 | 再利用可能性 | 判断の再利用可能性 | 判断理由、制約、却下案、見直し条件が後続作業で使えるかを評価するため。 |
| 支援構造 | 成果物要件ではなく教育・評価の運用条件 | 担当機会、支援条件、改善過程の併記 | 説明要求を権力的な選別にしないため、成果物そのものではなく第8章・第9章の運用条件として扱うため。 |
| 第3章では未分化 | 共有可能性 | 問題の具体化 | 外部表現が他者に参照されるには、目的、対象、制約、受け入れ条件を同じ問題として指せる必要があるため。 |
この対応表は、章間の用語を機械的に置換するためのものではない。第3章では批判の射程、第5章では成果物の性質、第9章では評価時に読む証拠というように、同じ問題を異なる役割から扱っている。
アクセス日は、特に断りのない限り2026年5月5日である。ウェブ記事の公開日・更新日は、公開ページで確認できる範囲を記す。AI協業・プロンプトエンジニアリング関連の変動しやすいウェブ資料、arXiv資料、本稿で追加確認したScrum Guide、GitLab Handbook、SICP、および厚生労働省、ISO、ビジネス言説・批判記事のウェブ資料は、2026年7月8日に再確認した。Fowler（2006）、Nygard（2011）、Lunney and Lueder（2016）、Turzo and Bosu（2023）、NCSCのプロンプトインジェクション記事、Debenedetti et al.（2025）、Rebedea et al.（2023）、AOSAは、2026年7月9日に再確認した。Stack Overflow Developer Survey 2025、OpenAI公式文書、OWASP Top 10一覧ページ、Ritchhart and Perkins（2008）のASCDページ、Tyree and Akerman（2005）のDOIメタデータ、Nogueira, Silva, and Conte（2026）のarXivページ、Reber and Schwarz（1999）、Lev-Ari and Keysar（2010）のDOIメタデータ、Land and Zembal-Saul（2003）のSpringerページは、2026年7月10日に再確認した。
この節の資料は、職場・メディア上の言語化言説と批判の所在を確認するために用い、言語化を求められる場面の増減を測定する実証研究としては扱わない。
この節には、査読済み論文・会議論文、arXivプレプリント、標準化団体・公的機関・企業の公式または実務ガイドが含まれる。本文では、各資料の性格に応じて、経験的知見、理論的提案、実務上の指針を区別して扱う。