ある建設会社では、1人の開発者が1年以上かけて構築したデータ同期システムを引き継ぎました。そこには224件ものコミットで動作ロジックが記述されていました。ところが、その開発者が不在になった途端、システム全体が機能しなくなってしまったのです。コストコードのマッピングは、たった一人の担当者の頭の中にしか存在しませんでした。会計システムでは「配管」が「15.1 配管」と名前変更されていましたが、その翻訳を知っているのはチームメンバーのうちたった一人だけでした。  

データを正規化すれば、より有用な質問を始めることができます。システムは予算超過を検出できますか？特定のコストコードの消費率がおかしい場合に警告を発することができますか？たとえば、解体工事はプロジェクトの初期段階で消費が減り、仕上げ工事は終盤に向けて消費が増加するはずです。しかし、このケースでは大きな差異が繰り返し発生し、プロジェクトマネージャーが資金をあるバケツから別のバケツに移動させるなど、さまざまな操作を行っていたことが判明しました。彼らは最終的な数字を変更していたわけではありません。プロジェクトの他の部分が順調に進み、誰もがそれを聞きやすい気分になるまで悪い知らせを遅らせることで、顧客の期待を操作していたのです。こうした論理は機械には見えません。

企業が不快な事実に気づくのは、組織内の知識の多くが文書化されておらず、しかもその一部は偶然ではないということだ。ルールが誰かの頭の中にしか存在しない場合、その人は不可欠な存在となる。プロセスが文書化されていない場合、誰もその妥当性を問うことができない。作業を明確にすることは、それを検証可能にすることであり、それは人間にとってある種の脆弱性となる。

会議を録音して検索可能な記録にする。例外ルールを文書化する。データを構造化された形式に整理する。「良い」状態とは何かを定義して、機械が正しく処理したかどうかを評価できるようにする。これがL2の仕事です。AIのような見た目ではありません。出力は、マッピングのスプレッドシートと、用語の意味を説明するドキュメントです。言葉にできないことを書き留めることで、不都合な真実が明らかになることがあります。しかし、それがなければ、上記のすべてが崩壊します。