ソフトウェア開発をしていると、
一度は耳にしたことがあると思う。

「内部向けのAPIだし、
そこまで厳密に設計しなくていいですよね」

言っていること自体は、分かる。
スピードも大事だし、全部を最初から固めるのは現実的じゃない。

この判断で前に進んだ現場も、たくさんある。

ただ、この一言が、
あとからもう一度、違う形で戻ってくることも多い。

よく見る光景

しばらく経ってから、
こんなやり取りが始まる。

え、これフロント以外から叩かれる想定だったっけ？

いや、たしか「内部向け」って話だった気がするんだけど……Slackで誰か言ってなかった？

あれ、その判断したとき○○さんってもうチームにいたっけ？

どれも強く断定されない。
「違う」と言い切る人もいない。

ただ、
みんな少しずつ自信がない。

この空気、
見覚えがある人は多いと思う。

これは設計の良し悪しの話ではない

こういう場面でありがちなのが、

• 厳密にやるべきだった
• 設計が甘かった
• ちゃんと考えてなかった

という方向に話が寄っていくことだ。

でも、少し引いて見ると、
問題はそこじゃないことが多い。

あのときの判断は、
その場の状況では妥当だった可能性が高い。

ただ一つ、抜けていたとしたらこれだ。

その判断は、
どこまでを前提にしていたのか。

判断は「正しいか」より「射程」で壊れる

ソフトウェア開発の判断は、
だいたい条件付きだ。

今のメンバー構成なら。
今の運用なら。
今のスコープなら。

この「なら」が、
言葉にされないまま消えていく。

すると後から、

• 条件が少し変わっただけで
• 判断そのものが否定されたように見える

という状態になる。

実際には、
判断が間違っていたわけじゃない。

適用範囲が共有されていなかっただけだ。

例外が語られていない判断

ここで一つだけ、
よくある共通点がある。

その判断について、

「このケースでは当てはまらない」

という話が、ほとんど出てこない。

忙しいし、そこまで細かく言語化する余裕もない。

だから自然と、

• 成立する前提
• 成立しないケース

が、まとめて省略される。

その結果、

• 判断の射程が見えなくなる
• 責任の境界が曖昧になる
• 次の判断がしづらくなる

という状態が残る。

少しだけ整理すると

この話は、難しいフレームワークの話ではない。

やっていることは、だいたい次の流れだ。

• その判断は、何を意味しているのか
• どんな前提に支えられているのか
• 条件が変わっても成立するのか
• どこから先は成立しないのか

特別なことではない。
現場で起きていることを、
少し言葉にしているだけだ。

例外を語れない判断は、責任範囲を語っていない

「この判断は、こういう場合には使えない」

この一言があるかどうかで、
判断の性質はかなり変わる。

例外を出すと、
判断が弱くなるように見えるかもしれない。

でも実際には逆で、

• どこまで任せていいかが分かる
• 変更が来たときに切り替えやすい
• 後から責めにくくなる

判断が、道具として扱えるようになる。

最後に

ソフトウェア開発では、
判断をしない、という選択肢はほぼない。

だから大事なのは、

その判断が正しいかどうか、ではなく
どこまで通用するつもりだったのか。

そこが見えているかどうかだ。

今やっているその判断、
どこから先は当てはまらないだろうか。

そこを一度だけ考えてみる。
それだけで、次の判断は少し楽になる。

少なくとも、
あとから戻ってきたときに
「話が違う」にはなりにくい。

現場なんて、
だいたいそんなものだけど。