git blame で「なぜこのコードはこう書かれているのか」を追っていったら、行き着いた先のコミットメッセージが fix の一言だけだった。書いた本人は、もういない。
エンジニアの方なら、一度は味わったことのある脱力ではないかと思います。コードという結果は、ちゃんと目の前に残っている。なのに、なぜそう書いたのかという判断だけが、きれいに抜け落ちている。
実はこれ、コードに限った話ではありません。私はソフトウェア開発ではなく、業務委託（BPO）の現場で長くプロジェクトマネジメントをやってきたのですが、まったく同じ脱力を、提案書やマニュアルの前で何度も味わってきました。
今日は、その「結果は残るのに、判断は消える」という現象を、エンジニアの世界と、なぜか歴史学とを行き来しながら、解剖してみたいと思います。
まず、私が味わった脱力の話
あるコンペ向けに、提案書を作ったことがあります。市場を分析して、競合を調べて、自分たちの強みを並べて、運営体制を描いて、収支まで試算した、それなりに分厚い一冊でした。何日もかけて、現場の知恵を絞り込んで書きました。
その提案書は、受注が決まった瞬間に、役目を終えました。
正確に言うと、完全に捨てられたわけではありません。半年後、よく似た別の案件のコンペがあったとき、別のチームが私の提案書を開いて、半分くらいをそのまま引用していました。だから「再利用された」と言えなくもない。
でも、引用のされ方に違和感がありました。中身を実際の運営に反映させるための引用ではなく、見せ方を整えるための引用だったのです。「こうやります」と書いてある段取りは、提案を通すための材料として流用されるだけで、受注後にその通り実装されるわけではない。提案書は、運営の設計図としてではなく、クライアントに良い印象を残すための材料として使われていました。
結果（分厚い一冊）は残っている。でも、その背後にあった判断は、誰にも引き継がれていない。git blame の fix と、構造はよく似ています。
作ったものが、隣に渡らない
不思議なのは、同じ会社の中でも、きれいに横展開されているものがあることです。
採用の手順、勤怠の管理、経費の精算、社内のワークフロー。こうした間接業務の仕組みは、どの現場でも同じ型で回っています。一度作った仕組みが、全社の共通基盤として使い回される。新しい現場が立ち上がっても、勤怠の付け方をゼロから考え直す人はいません。
ところが、クライアントから預かった業務そのものになると、話が一変します。ある現場のために整えた業務マニュアルや判断基準、改善のノウハウは、その現場の中で完結してしまう。似たような業務を別の場所で受けても、前の現場の蓄積が、そのまま効くようにはなっていない。
間接業務（採用・勤怠・経費・社内ワークフロー）
→ 共通の型に固定 → 全現場へ展開 → 使い回される（蓄積）
クライアント業務（マニュアル・判断基準・改善ノウハウ）
→ 各案件に特化 → その現場で閉じる → 隣に渡らない（消費）
同じ会社の中に、蓄積される領域と、消費されて消えていく領域の境目が、はっきり走っているのです。そしてその境目は、たいてい「間接部門」と「現場」のあいだに引かれています。
経営学では、知識を仕組みに固定して使い回す戦略を codification（成文化）、人を介して運ぶ戦略を personalization（個人化）と呼んで区別する議論があります。標準化しやすい仕事は前者が向き、一件ごとに事情が違う仕事は後者が向くと言われています。間接業務は codification できれいに横展開され、クライアント業務は personalization に倒れて現場に閉じる。あの非対称は、運び方の違う二種類の仕事が、同じ会社の中に同居しているからなのかもしれません。
「消費される」とは、どういうことか
ここで言う「消費される」を、もう少し具体的にしておきます。
成果物が物理的に消えるわけではありません。提案書もマニュアルも、フォルダのどこかには残っています。けれど、検索されず、参照されず、次の仕事の土台として使われないなら、それは保管ではなく死蔵です。残っているのに、いないのと同じ状態になる。腐ったまま誰も開かない社内Wikiのページを思い浮かべてもらえると、近いかもしれません。
| 消費されている | 蓄積されている | |
|---|---|---|
| 物理状態 | フォルダに残っている | フォルダに残っている |
| 違い | 検索・参照・再利用されない | 次の仕事の土台になる |
| 行き着く先 | 死蔵（あるのに、無い） | 横展開（隣の現場で蘇る） |
冒頭の提案書は、まさにこの「消費」の典型でした。受注という目的を達成した瞬間に、役目が終わる作りになっている。次のコンペで引用されても、それは中身の再利用ではなく、体裁の流用にすぎませんでした。
のれんとして、償却されていく
会計に「のれん」という考え方があります。企業を買収したとき、その会社の純資産を上回って支払った金額が、ブランドや信用といった目に見えない価値として資産に計上される。ただし、のれんはその後、年々少しずつ価値を取り崩していく（償却する）ものです。
提案書のふるまいは、これによく似ていると感じます。
提案書を作成（渾身の一冊・現場の知恵を凝縮）
│
▼
受注 ＝ 価値のピーク（クライアントに「良い印象」が計上される）
│
│ 案件が始まると…
▼
中身は実装に反映されない（現場はまた一から組み直す）
│
│ 次のコンペでは…
▼
見せ方として流用される（中身ではなく体裁の引用）
│
▼
印象は薄れ、評価は目減りしていく ＝ のれんの償却
提案書が示した「こうやります」は、受注の瞬間に価値のピークを打ち、あとは少しずつ目減りしていく。期待に届かないと指摘されるたびに、慌てて別の案件からノウハウを借りてきて、また「こうやります」と見せて安心してもらう。けれどそれも実装には根づかず、再び償却されていく。広告のような成果物が、静かに価値を減らし続ける。この繰り返しでした。
経済学に、シグナリングという考え方があります。情報を持つ側が、持たない側に何かを信じてもらうために発する合図のことです。ここで大事なのは、合図にコストや実行の裏づけが伴わないと、それは cheap talk（安い約束）と呼ばれ、信頼の土台にならないという点です。提案書が「こうやります」と語っても、実装でコミットされないなら、それは設計図ではなく安い約束に近づいていく。本来はコストをかけて蓄積した資産であるはずのものが、広告へと性質を変えてしまうのです。
なぜ、結果だけ渡しても伝わらないのか
ここが、今回いちばん書きたかったところです。
仮に、改善後のフロー図を完璧に文書化して、隣の現場に渡したとします。それでも、横展開はうまくいかないことが多い。「うちの現場は事情が違うから」と言われて、結局また一から作り直しになる。
長いあいだ、これを現場の頑固さや、抱え込み体質のせいだと思っていました。でも、最近は少し違う見方をしています。
渡せるのは、あくまで結果物です。フロー図、手順書、チェックシート。けれど、その背後にあった「なぜこう判断したのか」という思考そのものは、文書の表面には乗りません。受け取った側が、その思考を自分の頭の中でもう一度たどり直さない限り、ノウハウは蘇らないのです。
作った人が持っていたもの
＝ 判断の過程（なぜこうした・どの代案を捨てた・どんな失敗をした）
│
│ 文書化すると…
▼
組織に残るもの
＝ 結果だけ（こうなりました、というフロー図・手順書）
│
│ 受け取った人にできること
▼
結果は眺められる。でも「なぜ」は再現できない → また一から作り直す
文書を渡すことと、思考が伝わることは、別のことなのだと思います。隣の現場が「事情が違う」と言って作り直すのは、頑固なのではなく、渡された結果物から元の思考を再現できなかった、ということなのかもしれません。
そういえば以前、標準化が現場の個性を均していく話を書きました（参照：標準化された現場で起きる、静かなやる気の壊れ方）。あれは標準化が「人」から何を抜くかという話でした。今回はその先で、均して文書になったものが、なぜ「隣に渡らないまま捨てられるのか」という、できあがった文書のほうの話なのだと思います。
エンジニアの世界が、すでに出していた答え
冒頭の git blame の話に戻ります。
「なぜこのコードはこうなっているのか、もう誰にもわからない」。エンジニアはこれを tribal knowledge（部族知）と呼んだりします。特定の人やチームの頭の中にだけある、文書化されない知識のことです。その人が去ると、元の意図がわからなくなり、小さな変更すらリスクになる。残っているのはコードという結果物だけで、なぜそう書いたかという判断は、人とともに消えている。
私が提案書やマニュアルで感じていたことと、構造はまったく同じです。結果物は残る。でも、判断の過程は残らない。
面白いのは、エンジニアの世界が、この問題への答えを編み出していることです。
ひとつは ADR（Architecture Decision Record）と呼ばれる習慣です。重要な設計判断を下したとき、その結果だけでなく、「どんな選択肢があり、どれを、なぜ選び、何を捨てたか」を一枚の記録として残しておく。決定の意図（intent）を、それがどんな問題を解こうとしたのかという文脈ごと保存する、という発想です。
もうひとつは postmortem（ポストモーテム）です。直訳すれば検死で、障害が起きたあとに「何が、なぜ起き、どう対応し、次にどう防ぐか」を検証して残す文書です。ここには blameless（犯人を責めない）という作法があります。「誰が悪かったか」を問うと、人は本音を書かなくなり、判断の過程が記録から消えてしまう。だから個人を責めず、「どういう構造でその判断に至ったか」だけを残す。
どちらも、やろうとしていることは同じです。結果だけ残しても意味がない。そこに至った判断の過程を、後の人がたどり直せる形で残しておく。
歴史家が、ずっと前から言っていたこと
ここで、まったく畑の違う分野の話をします。歴史学です。
ある歴史哲学者は、歴史を理解するとは過去の出来事の記録を眺めることではなく、当時の人がなぜそう行動したのかという思考を、歴史家が自分の頭の中でもう一度たどり直すことだ、と論じました。これは再演（re-enactment）と呼ばれています。年表や記録という結果をいくら読んでも、その奥にあった思考は、自分の頭で考え直さない限り蘇らない、という考え方です。
並べてみると、不思議な一致が見えてきます。
| 観点 | エンジニアの世界 | 歴史学の世界 |
|---|---|---|
| 残るもの | 動くコード／フロー図 | 出来事の記録・年表 |
| 失われるもの | なぜそう書いたかの判断 | なぜそう行動したかの思考 |
| 困りごと | git blame しても理由が不明 | 記録を読んでも動機が不明 |
| 出した答え | ADR・ポストモーテムで判断の過程を残す | 再演（当時の思考を自分の頭でたどり直す） |
いずれも行き着く結論は同じです。結果だけでは思考は運べない。判断の過程を、たどり直せる形で残せ、ということ。
百年も離れた、まるで関係のない二つの分野が、同じ結論に別々の道から辿り着いている。エンジニアは現場の痛みからそこに気づき、歴史家は遠い昔の出来事を理解しようとしてそこに気づいた。
そして、BPOの提案書やマニュアルが消費されてしまうのは、この逆をやっているからだと思うのです。結果物だけを残して、判断の過程を残さない。だから隣の現場で再演できず、また一から作り直す。私たちは、再演の手がかりを捨てたまま、結果だけを渡し合っていたのかもしれません。
なぜ、こうなりやすいのか
もちろん、現場が悪いという話ではありません。消費型になりやすい構造の側にも、理由があります。
ひとつは、お金の管理が案件単位だということです。それぞれの案件で予算と利益が管理されていると、「複数の案件をまたいで使えるナレッジを整える作業」は、どの案件の費用でやるのかが宙に浮きます。結果として、横展開は誰かの善意と余力に頼ることになる。私自身、横展開を試みたことはありますが、それは個人の意志でやっていたことで、組織の仕組みとしては回っていませんでした。この、個人の意志に頼るしかなかったという感覚が、ずっと喉に引っかかっていました。
もうひとつは、契約の期間と、人の異動の周期がずれていることです。案件が数年続くあいだに、現場の担当者は何度か入れ替わります。そのたびに、引き継ぎきれなかったものが少しずつこぼれ落ちる。案件が終わればチームは解散し、蓄積は組織にではなく、個人の中に持ち越されます。
そして、現場業務そのものが、どこかで「中心ではない仕事」と見なされている空気もあります。中心と見なされない領域に、蓄積のための投資は向かいにくい。投資が向かわないから消費型のまま温存される、という静かな循環が回り続けます。
おわりに代えて
判断の過程を残すというのは、技術というより、姿勢の問題なのかもしれません。ADRもポストモーテムも、歴史家の再演も、根っこにあるのは「結果だけ見ても、人は分からない」という同じあきらめと、それでも残そうとする意志です。
セクションを越えた会話が必要だと言われるのも、たぶん同じ理由です。文書だけではこぼれ落ちる判断の過程を、人と人とが向き合って、もう一度たどり直す。ナレッジは文書だけでは運べず、誰かの頭の中で考え直されて、はじめて次の現場に根を張る。
整った現場で、提案書が静かにフォルダに眠っているのを見るたびに、思います。あれは確かに、一度は誰かを安心させた。けれど、もう一度誰かの役に立つ日は、来るのだろうかと。そして、fix とだけ書かれたあのコミットも、どこかで誰かが、同じことを思っているのかもしれません。
参考にした考え方
- Hansen, Nohria & Tierney（1999）「ナレッジ・マネジメントの戦略」 ― 知識を仕組みに固定して再利用する codification 戦略と、人を介して運ぶ personalization 戦略を区別した議論。標準化しやすい仕事と、一件ごとに事情が違う仕事とで、向いている運び方が異なるとされる。
- シグナリング理論（Spence ほか）/ cheap talk ― 情報を持つ側が発する合図は、コストや実行の裏づけを伴わないと信頼の土台にならず、安い約束（cheap talk）にとどまる、という経済学の考え方。
- Markus（2001）知識再利用の理論 ― 知識が再利用されるには、作る人・再利用可能な形に整える人・使う人の三役が必要で、特に「なぜそうしたか」という判断の根拠（rationale）が抜け落ちやすいと指摘される。
- ADR（Architecture Decision Record） ― ソフトウェア開発で、重要な設計判断の結果だけでなく、選択肢・採否・理由・文脈（intent）を一枚に残す習慣。
- blameless postmortem（非難なき事後検証） ― 障害対応後に、犯人を責めず「どういう構造でその判断に至ったか」を残す検証文化。個人を責めると判断の過程が記録から消えるため、とされる。
- Collingwood の再演（re-enactment）論 ― 歴史の理解とは記録を眺めることではなく、当時の人の思考を歴史家が自分の頭でたどり直すことだ、とする歴史哲学の考え方。
- （関連）organizational forgetting / tribal knowledge ― 知識が離職や時間経過で組織から失われる現象。エンジニアは属人化した暗黙知を tribal knowledge（部族知）と呼ぶ。