機能を足す前に、壊し方を直せ: すべての問題は境界の設計で決まる

Jul 02, 2026

1 min read

1 views

84%

問題はたいてい、機能ではなく境界にある

チームが何度も同じミスを繰り返すとき、私たちはつい「もっと気をつけよう」「手順を増やそう」「レビューを厳しくしよう」と考えます。けれど、本当に問うべきなのは別のことです。なぜミスが起きる余地が、そこに残っているのか。もし毎回つまずくなら、直すべきなのは人の注意力ではなく、つまずける構造そのものかもしれません。

この視点は、画面描画の話にもそのまま当てはまります。ある場面では、ポストエフェクトの後にメッシュを描きたい。つまり、処理の順番を少し変えたいだけに見えます。だが実際には、順番を変えるとは、どこで描くか、何が見えるべきか、どのレイヤーが何を所有するかを設計し直すことです。人間の失敗も、レンダリングの失敗も、表面上は「うまくいかない」だけですが、根っこには境界設計の問題があります。

何度も壊れるなら、壊れるたびに修理するのではなく、壊れにくい境界を作るべきだ。

この一文は、ソフトウェア開発の格言であると同時に、システム思考の核心でもあります。問題は、努力が足りないことではなく、努力の使い道が間違っていること。注意を増やすより、事故の入口を減らすほうが強いのです。

「射撃の腕」を鍛える前に、「銃」を見直す

多くの組織では、失敗が起きるたびに個人のスキルや集中力が議論されます。だが、同じ種類のミスが反復されるなら、それは偶然ではありません。人は疲れますし、忘れますし、コンテキストを取り違えます。だから本当に設計すべきなのは、失敗しても致命傷にならない仕組みです。

たとえば、会計の締め処理を思い浮かべてください。担当者に「絶対にミスしないでください」と言うのは簡単ですが、それは安全設計ではありません。入力制限、二重計算、差分チェック、異常値の検知があるから、ミスがあっても発見でき、被害が限定されます。つまり、優れたシステムは「正しさを人に委ねる」のではなく、誤りを前提に、誤りが広がらないよう設計するのです。

この発想は、UIにもコードにも組織にも共通しています。エラーが頻発する箇所に、さらに気合を入れるだけでは不十分です。入力箇所を減らす、状態を単純化する、権限を分離する、責任範囲を明確にする。そうした地味な工夫こそが、後から見ると最も大きな生産性の差を生みます。

ここで重要なのは、「人の能力を上げる」のと「人が失敗しにくい構造を作る」のは別の仕事だということです。前者は訓練、後者は設計です。訓練は効きますが遅い。設計は一度効けば、何度でも効く。だから成熟したチームは、優秀な個人を集めるだけでなく、愚かなミスが成果を食い潰さない配置を作ります。

描画の順番が変わると、世界の意味が変わる

ポストエフェクトの後にメッシュを描くというのは、一見すると単なる実装順の問題に見えます。けれど実際には、どの層が最終的な現実を決めるのかという問いです。先にフィルタをかけ、後からメッシュを重ねると、そのメッシュは「加工済みの世界」の外側に現れます。これはゲーム開発だけでなく、情報設計の本質をよく表しています。

たとえば写真編集を考えると分かりやすいでしょう。全体にぼかしや色補正をかけた後で、文字やロゴだけをくっきり重ねるとします。このとき文字は、背景の処理に巻き込まれません。逆に、先に文字を描いてから全体にエフェクトをかけると、文字までぼやけたり歪んだりします。順番は見た目の差ではなく、意味の差を生みます。

これはコードでも同じです。ログを出すのか、例外を投げるのか、キャッシュを先に見るのか後に見るのか。こうした順序の違いは、単なる速度や美しさではなく、システムがどの事実を優先するかを表しています。後段に置かれたものは、前段の世界を支配できます。だから順序設計は、しばしば権力設計でもあるのです。

ここで見えてくるのは、**「最後に何を描くか」は「何を現実として固定するか」**だということです。システムの最後に置かれたものは、全体の印象を決めます。だから優れた設計者は、機能を積み上げる前に、レイヤーの優先順位を決めます。何が土台で、何が上書きで、何が例外なのか。その境界を曖昧にした瞬間、後から追加されるものが全体を侵食し始めます。

本当に難しいのは、機能を足すことではなく、壊れない境界を引くこと

この二つの話を並べると、同じ中心問題が浮かび上がります。人間の失敗も、レンダリングの順序も、どちらも境界の設計に収束するのです。どこまでを自動化し、どこからを人間の判断に任せるのか。どこまでをエフェクトの対象とし、どこからを例外として保護するのか。優れた設計は、複雑さを消すのではなく、複雑さの居場所を限定します。

ここで役立つのが、**「失敗の半径」**という見方です。失敗そのものをゼロにするのは難しい。だからこそ、失敗したときにどこまで影響が広がるかを最小化する。メッシュを後から描く設計は、ある種の「保護された要素」を作っています。全体の効果とは別に、絶対に見せたいものを最後に残す。これは、組織における重要工程のチェックポイントにも似ています。

たとえば、巨大なリリース前に全員が自由に変更を入れられる状態は、境界が弱い設計です。反対に、最終確認の責任者、変更可能な範囲、差し戻し条件が明確なら、事故は減ります。これは自由を奪う話ではありません。むしろ、自由に動ける範囲を明確にすることで、安心して速く動けるようにする話です。

同じことは、自分自身の仕事にも言えます。毎回の作業で集中力を消耗しているなら、意志力を増やすより、判断回数を減らすほうがいい。テンプレートを作る、チェックリストを固定する、定型の入力を自動化する。これらは地味ですが、実は「銃の改良」です。引き金を軽くするのではなく、誤射しにくい構造を作るのです。

優れた設計とは、正しいことをやりやすくするのではなく、間違ったことをやりにくくすることだ。

この逆説は、派手なイノベーションよりも重要です。なぜなら、日常の大半は例外ではなく反復だからです。反復のなかで毎回少しずつ摩耗するなら、最終的な差は劇的になります。だから設計とは、単発の正解を作ることではなく、正解が何度も再生される地形を作ることなのです。

すぐ使える実践フレーム: 3つの質問で「銃」を見直す

問題が起きたとき、次の3つの質問を投げてみてください。これはコードレビューでも、運用改善でも、個人の作業改善でも使えます。

1. 何が繰り返し壊れているのか

表面的な失敗ではなく、パターンを見ます。入力ミスなのか、順序ミスなのか、責任の曖昧さなのか。反復しているなら、それは偶然ではなく、構造のサインです。まずは「何が何度も起きるのか」を言語化してください。

2. その失敗は、どこで止められるか

人が気をつける前に、システムで止められないかを考えます。入力制約、事前検証、自動テスト、権限分離、最終レイヤーでの上書きなど、失敗を局所化する手段はたくさんあります。重要なのは、失敗の発生点ではなく、失敗の伝播点を見つけることです。

3. 最後に守るべきものは何か

ポストエフェクトの後に描くメッシュのように、全体の影響を受けさせたくないものは何かを明確にします。UIなら可読性、業務なら監査可能性、プロダクトなら信用。最後に守るべき価値が分かると、設計の優先順位が決まります。

この3問は単純ですが、効きます。なぜなら、問題を「頑張り不足」から「構造の再設計」に引き戻してくれるからです。多くの改善は、努力を増やすことでなく、摩擦の置き場所を変えることで実現します。

Key Takeaways

反復する失敗は、個人ではなく構造の問題として疑う。
人を鍛える前に、失敗が広がりにくい境界を作る。
順番の設計は、見た目ではなく意味と権力を決める。
最後に何を守るかを決めると、全体の設計が締まる。
正しさを人に依存させるのではなく、誤りを局所化する仕組みを持つ。

終わりに: 直すべきなのは、壊れた人ではなく、壊れやすい配置かもしれない

私たちはしばしば、問題を「もっと注意すれば解決するもの」として扱いすぎます。けれど、繰り返し壊れるものは、注意だけでは守れません。必要なのは、壊れ方を前提にした設計です。つまり、ミスをなくすことではなく、ミスが致命傷にならないようにすること。

ポストエフェクトの後にメッシュを描くという発想は、その象徴です。世界全体に一律の処理をかけるだけでは、守りたいものまで変質してしまう。だから最後に残す層を意識する。人間の仕事でも同じで、最後まで守るべき価値を決め、その価値が処理の波に呑まれないよう境界を引く。そこに設計の知性があります。

結局のところ、上手い人とはミスをしない人ではありません。ミスが起きても、壊れるのは一部だけにしておける人です。そして、優れたチームとは、個々の根性ではなく、壊れ方まで考えて配置されたチームです。次に何かがうまくいかないときは、まず自分に問いかけてみてください。直すべきなのは、銃の扱いか、それとも銃そのものか。