1. 「誰が決めたのか」が答えられない組織
大企業のIT部門でシステム障害が起きた後、あるいは根本的なアーキテクチャの問題が露呈した後に、こう問うことがある。「これ、誰が決めたんですか？」
答えが返ってこない。あるいは、こう返ってくる。「当時の委員会で検討した結果です」「関係部署の合意を得て決定しました」「以前からそういう設計でして……」
誰も決めていないのだ。正確には、決定に名前がついていない。委員会が決め、合議が決め、「そういう流れ」が決めた。特定の個人が「これでいく」と判断し、その判断に責任を負った形跡がない。
問題はここにある。誰も決めていなければ、誰も責任を負わない。誰も責任を負わなければ、誰も変えられない。変えようとしても「決定のプロセスを遡れない」ため、なぜその構造になったのかを検証する起点がない。こうして、誰も決めていない設計が、誰も触れられない聖域として残り続ける。
2. 責任の希釈
組織は自然に、責任を希釈する構造を生み出す。委員会、多段階承認フロー、合議制、コンセンサス文化。これらはいずれも、個人が「これでいく」と言い切らなくてよい仕組みである。
その代償は大きい。委員会の決定は、最大公約数ではなく最小公倍数の否定になる。誰かが信じているものではなく、誰も強く反対しないものが選ばれる。全員の賛成を経た決定は、誰かの確信から生まれたものではなく、誰の反対も受けなかったものに過ぎない。
全員が賛成した決定は、誰の決定でもない。
これはアーキテクチャに直接影響する。「サーバーにデータを送らない」という設計判断は、委員会で決められるものではない。誰かが「それが正しい」と確信し、その判断に名前を刻むことで初めて設計原則になる。合議は原則を生まない。合議が生むのは、妥協の産物としての仕様書だ。
3. 決められない組織の症状
決断が希釈された組織には、繰り返し現れる症状がある。一見それぞれ独立した問題に見えるが、根は同じだ。
| 症状 | 根にある問題 | 関連するエッセイ |
|---|---|---|
| 終わらないPoC | 「進む」または「やめる」を言える人間がいない | PoCの目線 |
| 後付けのEA | 最初の構造を誰も「これでいく」と決めなかった | エンタープライズアーキテクチャ |
| 後付けのセキュリティ | 「これは倫理の問題だ」と誰も決断しなかった | SSDLC |
| 多段階承認フロー | リスクを一人で評価できる人間がいない、あるいは評価したくない | エンタープライズアーキテクチャ §6 |
終わらないPoCは、検証結果を受け入れて「やめる」または「進む」を宣言できる人間の不在が原因だ。後付けのEAは、最初のアーキテクチャを誰も決断していないから、後から体裁を整えるしかなくなる。セキュリティが後付けになるのは、セキュリティを「コストの問題」ではなく「倫理の問題」として決断した人間がいないからだ。
どの症状も、決断の不在という同じ病から派生している。
4. トキストレージにおける決断
トキストレージには、記録できる決断がある。抽象的な方針ではなく、具体的な判断と、その判断がアーキテクチャに与えた影響の記録だ。
「サーバーにデータを送らない」
これは一つの文だが、設計全体の根拠になった。音声のエンコード・デコードをブラウザ完結にする。バックエンドを持たない。ユーザーの音声データがネットワークを通じて外部に出ることを構造的に不可能にする。この判断から、WASM上でCodec2を動かすという技術選択が導かれ、静的サイトとしてのデプロイ方針が確定し、プライバシーの主張が検証可能な事実になった。一つの決断がアーキテクチャの形を決めた。
「Opusでは不可能」
音声QRの最初の候補はOpusだった。Web標準コーデックで、ブラウザネイティブデコードが可能。しかし2kbps以下でDTXに陥り、4kbps以上ではQRの容量に収まらない。この判定を数日で下し、Opusへの投資を打ち切った。「もう少し最適化すれば」という選択肢は存在していたが、取らなかった。判定は明確で、決断は即座だった。この決断がなければCodec2には到達していない。
「コードを全公開する」
セキュリティの主張を検証可能にするために、コードを公開した。「サーバーにデータを送らない」は、コードを見れば確認できる。「主張」ではなく「事実」にするための決断だ。これはトレードオフを伴う。競合に実装を見せることになる。それでもこの決断は正しいと判断した。その判断に名前がある。
「NDL納本は編集権で制御する」
国立国会図書館への納本にあたり、アーカイブされたコンテンツの将来的な編集をどう制御するかという問いが生じた。答えはシンプルだった。GitHubのリポジトリ権限が編集権であり、それはトキストレージが保持する。この判断で、ガバナンスの問題が一つの会話で解決した。委員会は不要だった。
これらの決断すべてに、一人の名前がある。創業者の。全責任は一点に集中している。これが、アーキテクチャに一貫性をもたらす条件だ。
5. 決断のコスト
決断には代償がある。間違える可能性がある。Codec2を選んだ判断が間違いだったかもしれない。コードを公開したことが競争上の不利になるかもしれない。これらのリスクは実在する。
しかし、決断しないことにもコストがある。そしてそのコストは、決断の失敗より見えにくい。
決断しない組織が抱えるコストは積み上がる。確信のないアーキテクチャは、誰も変えられない聖域になる。ガバナンスの歯のない方針は、守られない規則になる。結論の出ないPoCは、予算と時間を消費しながら何も生まない。これらは単独では小さく見える。しかし時間とともに複利で積み上がり、解きほぐすことのできない構造的負債になる。
間違った決断は修正できる。決断しなかった事実は修正できない。
間違った決断は記録として残る。「あの時こう判断したが、これが間違いだった」という学習の起点になる。決断しなかった事実は記録に残らない。「なぜそうなったのか」の問いに誰も答えられず、修正のための足がかりがない。
6. 一人であることの意味
ここで主張したいのは、一人のチームが最良だということではない。スケールには人が必要で、多様な視点には複数の人間が必要だ。それは事実だ。
主張したいのは、責任は個人的でなければならないということだ。組織の規模に関わらず、すべての決断には「これを決めた人間」が存在しなければならない。
日本の組織には「判子を押す」という文化がある。承認の証として、文書にハンコを押す。形式としては個人の責任を示しているように見える。しかし実態は異なることが多い。ハンコを押した人間が実際にその判断を下したわけではなく、前段の合議を追認する形式として押されている。ハンコは決断の証ではなく、決断の不在を隠す儀式になっている。
トキストレージの利点は、一人であることではない。すべての決断に顔があることだ。「誰が決めたのか」を問われれば、即座に答えられる。その答えが設計の根拠になり、変更の判断基準になり、アーキテクチャの一貫性を生む。
7. 結論 — 決断とは名前を刻むこと
決断とは、自分の名前を刻むことである。
選択ではなく、責任の引き受けだ。
アーキテクチャは、それを決めた人間の確信を反映する。「サーバーにデータを送らない」という構造は、プライバシーを倫理として引き受けた個人の名前を内包している。「OpusではなくCodec2」という選択は、検証結果を受け入れた個人の判断を内包している。
システムのどの層についても「誰が決め、なぜ決めたのか」に答えられるとき、そのシステムには誠実さがある。設計に意図があり、意図に責任があり、責任に名前がある。
トキストレージのすべての設計判断には、一人の名前がある。それが、ハリボテではない構造を生む。