ソフトウェア製品が実際にどう動いているのかは誰にもわからない［翻訳文］

1. 大規模テックシステムの不透明性

• 大手テック企業は、自社システムですら「戦場の霧(fog of war)」の中で運用している。
• 「Yタイプのユーザーは機能Xを使えるのか？」「アクションZのとき正確に何が起きるのか？」「現在の料金プランは何種類あるのか？」といった基本的な質問にさえ、組織内のごく一部の人しか答えられない。
• ひどい場合は調査専任者を割り当てる必要があり、公開ドキュメントを見るだけで答えが出るはずなのに、そうなっていない。

2. 複雑性の源: Wicked Features

• 大きなソフトウェアは、self-hosting、無料トライアル、組織/ポリシー制御、多言語ローカライズ、規制対応機能などによって極度に複雑になる。こうした機能は あらゆる新機能に影響する。
• 例: ポリシー制御を追加すると、そのたびに新機能にも適用しなければならず、ローカライズするなら翻訳も追随しなければならない。
• 「EUリージョンのself-hostingエンタープライズ顧客が特定機能にアクセスできるかどうか」は、コードを直接調べるか実験することでしか確認できない。こうした機能を省くと 莫大な収益を手放すことになり、これが大企業と小企業の違いでもある。

3. ドキュメント化の限界

• 新機能ごとに相互作用をドキュメント化することは理論上は可能だが、システムの変化速度がドキュメントを上回る。
• 静的なシステムではなく動的な環境では、ドキュメント作成者は変化より先を行かなければならず、これは不可能に近い。
• さらに大きな問題は、多くの動作が 明示的な意図ではなくデフォルト設定同士の相互作用 から生まれることだ。ドキュメント化は実際のシステム探索に近い。

4. 答えの核心: コードベースとエンジニア

• 正確な答えは コードベースを直接見ること でしか得られず、これがエンジニアの権力基盤になっている。
• エンジニアリングチームの中核機能は ソフトウェアに関する質問に答える能力 である。
• 特定のコードについて頭の中に蓄積された暗黙知(tacit knowledge)を活用する。
• チーム再編時には知識の喪失によって「探索的手術」(コード修正/チェックの強制など)が必要になる。
• コードを書くのは簡単でも、信頼できる回答は確信の問題 のため難しい(間違うリスク、要約と圧縮の必要)。

5. 結論: 貴重な能力

• 非技術職はソフトウェアがエンジニアに完全に理解されていると信じがちだが、大規模システムは誰も完全には把握していない。
• 基本的な質問ですら繰り返し調査が必要で、変化があるとニュアンスや例外が発生する。正確に答える能力はきわめて価値が高い。