最適化の前に秩序を作れ: 技術選定とハラスメント疲れに共通する一つの罠

はじめに: その「自由」は本当に自由か

「何でも後から足せるなら、最初から厳しく決めなくていいのではないか」。この問いは、設計の世界でも、組織の空気でも、驚くほど同じ形で現れる。データベースを最初から分けるべきか、まずはRDBMSで十分かという議論と、やたらと増え続ける「〇〇ハラスメント」に疲れる感覚は、一見まったく別の話に見える。だが根っこでは、どちらもルールを増やすことで秩序を守るべきか、自由を優先して後で調整すべきかという問いにぶつかっている。

そして、多くの場面で本当に問題なのは「自由」ではない。ルールのなさが生む摩擦を、誰がどのタイミングで回収するのかが曖昧なことだ。技術でも組織でも、最初は軽く見える選択が、あとから巨大な運用コストとして返ってくる。逆に、先に秩序を入れすぎると、柔軟性を失って現実に対応できなくなる。

この矛盾を解く鍵は、すべてを厳格にすることでも、すべてを緩くすることでもない。「後で直せる」ではなく、「後で直すコストを誰が払うのか」を先に設計することにある。

---

第1章: 技術設計は、実は社会設計でもある

RDBMSを使うべきか、NoSQLに逃がすべきか、ファイルシステムに切り出すべきか。こうした議論は、単なる性能や流行の話に見えて、実際には秩序の置き場所をどう決めるかの話だ。スキーマをガチガチに固めることは、制約を増やすことではない。むしろ、データの意味を共有しやすくし、あとから別の仕組みを足したときにも、壊れにくい土台を作る行為だ。

たとえば、会計システムを考えてみる。請求書番号が文字列でも数値でも入るような自由さは、一見すると便利だ。しかし、その自由はすぐに不整合を呼ぶ。検索が揺れ、集計が壊れ、監査で説明できなくなる。そこで型と制約を入れると、最初は窮屈に感じるが、長期的には「この値は何を意味するか」をチーム全員が揃えて扱えるようになる。

ここで重要なのは、制約は敵ではなく、共同作業の前提だということだ。コードレビュー、知見の共有、責任分担が機能するのは、チームの誰かが好き勝手に意味を変えられないからだ。秩序があるからレビューでき、レビューできるから改善できる。

先に秩序を作るとは、未来の自分たちが迷子にならないように、意味の境界線を引いておくことだ。

もちろん、すべてをRDBMSで抱え込めばいいわけではない。ポインタ操作でメモリ領域を直接いじるような、あえて危ういハックが必要な場面もある。Rustのような堅い設計では触れない現実の肌触りが、低レベルな最適化や特殊な実装には存在する。だが、その例外を理由に、最初から無秩序で良いことにはならない。例外を扱うには、まず原則が必要だからだ。

この点で、技術設計は組織設計の鏡になる。どちらも、自由を増やすこと自体は簡単だが、自由の副作用を受け止める機構を作るのは難しい。だから本当に問うべきは、「制約があるかどうか」ではなく、制約がどこに置かれ、誰が更新し、誰が責任を持つかである。

---

第2章: 「ハラスメント」が増え続けるのは、言葉が増えたからだけではない

「〇〇ハラスメント」が増えたことに対して、息苦しさを覚える人は多い。たしかに、注意すべき振る舞いを細かく切り出し続ければ、会話は萎縮し、人間関係はぎこちなくなる。だが、ここで起きているのは単なる過剰分類ではない。本来ひとつの基準で扱われるべき不快や加害の問題が、運用できないまま個別名で増殖していることが、疲れの正体だ。

たとえば、職場での威圧、無視、過度な皮肉、私的領域への侵入、評価をちらつかせた圧力。これらを全部別々のラベルで覚えさせられたら、現場は混乱する。人はラベルを増やして安心したつもりになるが、実際には判断基準がぼやける。結果として、「これはセーフなのか、アウトなのか」「誰が判断するのか」「どこまでが許容なのか」が曖昧なまま、言葉だけが増えていく。

ここには、技術設計と同じ罠がある。スキーマを作らずにJSONを無限にぶち込み続けると、柔軟性はあるように見えて、後で誰も整合性を説明できなくなる。組織でも同じで、禁止事項を無数に増やすだけでは、秩序は生まれない。必要なのは、個別ラベルの追加ではなく、どの原理で線を引くかの共有だ。

たとえば、次のように整理できる。

• 相手の拒否や違和感を軽視していないか
• 立場差を利用していないか
• 公的な場で私的な支配を持ち込んでいないか
• 一度の冗談ではなく、継続的な圧力になっていないか

このように、個別の現象をすべて覚えるのではなく、背後にある原理を共有するほうが、現場はずっと強くなる。言葉が増えること自体が悪いのではない。問題は、言葉が増えても判断の土台が増えていないことだ。

本当に疲弊させるのは、ルールの数ではない。ルールの増殖に対して、原理が追いついていない状態である。

そしてここでも、責任の所在が決定的になる。だれもが「私は悪くない」と言える環境では、ルールは増える一方で実効性を持たない。逆に、レビュー体制や相談の仕組み、基準の共有があると、個人の善意に依存しすぎずに済む。つまり、組織が成熟するとは、単に禁句が増えることではなく、摩擦を早期に見つけて、共同で処理できることなのだ。

---

第3章: 自由と秩序は対立しない。順番があるだけだ

ここまで見ると、厳格なルールこそ正義に見えるかもしれない。しかし、秩序は多ければ多いほどいいわけではない。過剰な制約は、現実の変化に対応する前に人を疲弊させる。だから大事なのは、すべてを固定することではなく、変えてはいけないものと、後から変えていいものを分けることだ。

これを技術に置き換えると、中心にはRDBMSのような強い秩序があり、周辺にJSONや検索インデックス、イベントログ、ファイルストレージなどを置く構造が見えてくる。中心はぶれない。周辺は用途に応じて変えられる。つまり、コアは厳格に、エッジは柔軟にという設計だ。

組織も同じで、価値観や安全基準は曖昧にしてはいけないが、表現方法や運用手順は改善の余地を残すべきだ。たとえば、相手を傷つけないという原則は固定する。一方で、どの会話が危険信号になりやすいか、どう注意を返すか、どう相談窓口へつなぐかは、現場に合わせて更新する。こうすると、ルールは増えても息苦しさは減る。なぜなら、個別の禁止事項に縛られるのではなく、判断の筋道が共有されているからだ。

この順番の発想がないと、人は極端に走る。自由を守るために秩序を全部拒否するか、秩序を守るために自由を全部奪うかの二択になる。だが実際には、その中間にこそ成熟がある。成熟とは、何でも許すことでも、何でも禁じることでもない。何を固定し、何を変え、誰がその境界を守るかを言語化できることである。

ここで一つ、実践的な比喩を置いておきたい。家の設計を想像してほしい。壁や柱がなければ、部屋は成立しない。しかし、壁ばかり増やせば動線が死ぬ。よい家とは、最初に柱を立て、後から家具や仕切りを調整できる家だ。技術も組織も同じで、骨組みは先に作るが、暮らし方は後から調整するのが最も強い。

---

第4章: では、現場では何をすればいいのか

抽象論だけでは役に立たない。現場で必要なのは、秩序を過剰にせず、しかし無秩序にも戻らないための手順だ。まず必要なのは、ルールを増やす前に、判断軸を1つにまとめることである。技術なら「このデータは真実の源泉か」、組織なら「この行為は相手の自由を狭めていないか」といった具合に、個別ケースをまとめる上位概念を置く。

次に必要なのは、責任を個人に閉じないことだ。データの整合性を開発者の気合いで守るのは危険だし、ハラスメント対策を「空気を読める人」の暗黙知に任せるのも危険だ。レビュー体制、相談導線、ログ、監査、教育。これらは面倒に見えるが、秩序を人間の善意だけに依存させないための装置である。

最後に必要なのは、例外を例外として扱う勇気だ。低レベルなハックが必要な場面はある。業務上、厳密な言い方だけでは届かない会話もある。だが例外は、原則が強いからこそ意味を持つ。原則のない例外は、やがて慣習になり、慣習は説明不能な圧力になる。

実務的には、次の三段階で考えるとよい。

1. 中心を決める: 何を絶対に壊してはいけないかを明文化する。
2. 周辺を分離する: 変化しやすいものは外に出し、接続点だけ厳密にする。
3. 更新責任を置く: ルールの改定や例外処理を、誰がどう判断するか決める。

この考え方は、コードにも会話にも効く。無限に規約を増やすのではなく、判断の設計をする。そうすると、技術選定の迷いも、言葉に疲れる感覚も、同じ地平で扱えるようになる。

良い秩序とは、人を縛る網ではない。人が迷わず動けるための地図である。

---

Key Takeaways

• 自由を増やす前に、責任の受け皿を作る。 後から直せるかではなく、誰が直すのかを先に決める。
• ルールを増やすより、原理を共有する。 個別の禁止事項を覚えるより、判断軸をそろえたほうが強い。
• コアは厳格に、周辺は柔軟に設計する。 すべてを固定せず、壊してはいけない部分だけ強く守る。
• 例外は原則があるから扱える。 例外処理を常態化させると、秩序は静かに崩れる。
• 組織の成熟は、禁止の数では測れない。 摩擦を早期に見つけ、共同で処理できる仕組みがあるかで決まる。

---

おわりに: ルールが増える社会で、本当に必要なのは「減らす勇気」ではない

私たちはしばしば、ルールが多すぎると感じると、それを減らせば自由になると考える。だが本当の問題は、ルールの数そのものではない。秩序を支える設計がないまま、現象だけを切り刻んで増やしていることだ。だからこそ、技術でも組織でも、まず必要なのは「何を守るか」を定めることであり、そのうえで必要なものだけを足していくことだ。

RDBMSを先に置く判断も、ハラスメントを個別ラベルで増やすことに違和感を覚える感覚も、実は同じ地点から生まれている。どちらも、世界を支えるには、表面的な自由よりも、見えにくい秩序のほうが先だと知っている。自由は秩序の後に来る。順番を間違えると、自由はただの混乱になる。

だから次に何かを設計するときは、こう問い直してみてほしい。これは自由を与える設計か、それとも責任を見えなくする設計か。 この問いに答えられるなら、技術選定も、組織の言葉づかいも、ずっと澄んで見えてくるはずだ。