構造は官僚主義ではない

構造とは各ページに重厚なテンプレートを被せることではない。判断に固定の置き場を与え、症状を原因にリンクし、タイトルが将来も検索しやすい状態にすること。[[payment-module]] にリンクした短い ADR は、誰も開かない 10 ページのドキュメントに勝る。

エンジニアリングボルトで使えるパターン

  1. ハブノート — [[Platform overview]] のようなインデックスページ。各サービスと運用マニュアルへのリンクを集約する。
  2. 意思決定記録 — 「X を選んだ、理由は Y」という短いノート。Frontmatter に日付とステータスを記載する。
  3. インシデントの関連付け — 振り返りを影響を受けたコンポーネントにリンクする。Slack スレッドに留めない。
  4. 問題ベースのコードスニペット — サンプルコードをファイル名ではなく、問題名のノートに置く。

ツールは摩擦を減らすべきで、プロセスを増やすべきではない

2 つのノートをリンクするのがテキストをコピーするより面倒なら、構造は続かない。Lunote は素早い執筆と [[双方向リンク]] の自動補完、知識サイドバーのバックリンク、知識グラフ——「プラットフォームハブ」が本当につながっているか、孤立ノートになっていないかを確認できる。

「答えを見つけるのにどれくらいかかるか」で効果を測る

正しい指標はノートの数ではない。「なぜモバイル auth の挙動がこうなっているのか？」に答えるのにどれくらいかかるか、と問いかけてみる。ハブ → サービスノート → ADR → インシデント記録という経路が辿れるなら、システムは機能している。ワークスペース認識型 AI は同じ経路に沿ってアウトラインを起草できる——空白のチャットではなく、リンクされたノートをコンテキストとして。