バベルの図書館は完成しない

Extended outer memory module
for my poor native memory.

Posts:
2026/11/10 曖昧さの請求書は現場に届く
2026/01/06 前回記事から4年が経過しました、現状報告
2022/02/13 クラビスの CTO になりました
2020/09/28 gendoc という YAML からドキュメントを生成するコマンドを作った
2020/09/13 ISUCON10 の予選を 7 位で通過した
2019/12/01 Puma の内部構造やアーキテクチャを追う
2019/05/27 Golang の正規表現ライブラリの処理の流れをざっくり掴む
2019/04/29 InnoDB の B+Tree Index について
2019/04/29 InnoDB における index page のデータ構造
2019/04/28 InnoDB はどうやってファイルにデータを保持するのか
2019/01/06 Designing Data-Intensive Applications を読んでいる
2019/01/03 年末年始に読んだ本について、など
2019/01/01 Ruby から ffi を使って Rust を呼ぶ
2018/11/10 ブラウザにおける状態の持ち方
2018/07/01 Rust で web アプリ、 或いは Rust における並列処理
2018/05/14 なぜテストを書くのか
2018/05/13 Rust で wasm 使って lifegame 書いた時のメモ
2018/03/12 qemu で raspbian のエミュレート(環境構築メモ)
2018/03/12 qemu で xv6 のエミュレート(環境構築メモ)
2018/03/03 Ruby の eval をちゃんと知る
2018/02/11 Web のコンセプト
2018/02/03 Rspec のまとめ
2018/02/03 Ruby を関数型っぽく扱う

曖昧さの請求書は現場に届く

仕事をしていると、「責任」という言葉の解像度の低さに悩まされる場面が多い。

何か新しいことを始めようとするとき、事後にどういう帰結が起きたら誰がどう責任を取るのか、事前に文章で合意しておく、という文化を正直言って私はほとんど見たことがない。だいたいみんな適当に始めて、責任が曖昧になって終わることばかりに見える。

これは特定の会社の文化が壊れている、という話ではないように思う。事前に帰結まで書く文化が育っている領域、例えば航空や原子力や軍事のような領域は、事故の代償が即座に、隠しようのない形で跳ね返ってくる世界だ。ソフトウェアの事業はそうではない。代償は遅れてやってくるし、薄く広く拡散する。だから曖昧なまま始められるし、曖昧なまま終わっても誰も即死はしない。曖昧さは組織のデフォルトであり、しかも多くの参加者にとってだからこそ機能的でさえある。

曖昧さの効用

曖昧さには効用がある。

帰結を先に書くということは、対立を未来から現在に前倒しすることだ。痛みを伴うので、みんな避けたがる。決着していない問題であっても「なんとなく」で始められるし、明確化したら合意できなくて止まってしまう案件が、曖昧だからこそ動く、ということがある。責任の所在が曖昧であれば、失敗したときに全員が少しずつ言い逃れすることもできる。

つまり曖昧さは必ずしも怠慢の結果ではなく、政治の技術として合理的に選ばれている側面がある、と私は考えている。(参加者が意識的に活用しているかどうかはまた別の話だ。)

ただしコストがゼロなわけではない。曖昧さの請求書は、決める側 = 組織の意思決定層ではなく現場に、現在ではなく未来に届く。組織が曖昧さによって得ている流動性の対価を、運用や保守を担う側がコストという形で支払わされている構造がある。

責任は4つに分解できる

そもそも「責任」という言葉自体が、複数の別物を束ねすぎているのではないか。

「リスクは引き受ける」という合意があったとして、引き受けられているのは大抵の場合、判断の責任の、しかも口頭の部分だけである。実際に事故が起きれば残りの3つは自動的に現場に戻ってくる。引き受けたはずなのに実効性がない、という違和感の正体はだいたいここにある。

責任に実効性を持たせる装置は、突き詰めると3つしかないように思う。

責任とは「判断の記録 × 事前に合意した帰結 × 期限」の掛け算であり、どれか一つがゼロであれば責任はゼロになる。感情の問題ではなく、設計の問題だと考えるようになってきた

最低ラインの話

開発組織の文脈で言えば、開発側が「責任を持てる」と言っていい範囲は、意外と狭い。

開発側が持てるのは、運用体制の最低ラインを定義し、ラインを割った状態を検知して報告する責任と、ラインの内側では運用を回しきる責任までだ。そのラインを維持するコストを払う価値が事業にあるかどうかは採算性の判断であり、事業側の仕事である。ここが分解できていないと、責任の4要素は全部開発側に寄ってくる。

さらに言えば、事業側が「最低ライン分のコストは払わない」と判断するのであれば、それは「最低ライン以下で運用するリスクを、事業判断として引き受けた」ということになるはずだ。この引き受けが可視化されるかどうかが、構造としての健全性を決める。コストを認識しない、という選択肢が消えるからである。

文化を変えるのではなく、1件に名前と日付をつける

とはいえ、組織全体を事前合意の文化に変えようというのは無理筋だ、ということも同時に思う。

こういう場合には狙うべきは最小形である。立派な契約書は不要。 決めた人の名前と、判断の位置づけと、見直しの時期。この3点が残ればいい。会議の議事メモでも、チャットの一言でも成立する。対象も全部の仕事に広げる必要はない。高コストで不可逆な判断だけに絞ればいい。可逆な判断は曖昧に始めて走りながら直す方が、組織全体では速い。

もちろん弱点もある。記録があっても「状況が変わった」で反故にするのは簡単だし、記録が決めた人を吊るすための道具に転用されるリスクもある。だから記録は残すが、吊るし上げには使わない、という運用までセットで設計する必要がある。

文化を変える話ではなく、1件の判断にだけ名前と日付をつける話としてなら、持ち込める余地はあるのではないか。最近はそんなことを考えている。

2026/11/10 21:00
tags: work
This site is maintained by furuhama yusuke.
from 2018.02 -