実は先日、運転免許の更新講習を受けてきました。
そこで改めて聞いた話が、意外と強く印象に残っています。

「事故が多いのは、見通しのいい交差点です」

見通しの悪い交差点ならわかるけど、「見通しのいい交差点で？え、そこ？」と少し意外に感じました。
話を聞いているうちに、「あ〜確かに、なるほど〜」と感じました。
またこの話を聞いて、これは車の運転だけの話じゃないなと思ったのです。

❌ 【イラスト右】ショートカット気味の右折

見通しがいい交差点ほど、ついやってしまいがちなのが
ショートカット気味に右折してしまう走行です。

  • 早く曲がろうとする
  • 交差点の中央を省略する
  • ハンドルを早めに切る

この走り方をすると、車のフロントピラーが進行方向と重なり、
自転車や歩行者が死角に入りやすくなります。

しかも、

  • 見通しがいい
  • 危険がなさそう
  • スピードも出やすい

という条件が重なるため、「見えないこと」に気づかないまま右折してしまうのです。

⭕️ 【イラスト左】円弧を描くように、遠回りして右折

一方で、講習で推奨されていたのが円弧を描くように、少し遠回りする右折です。

  • 交差点の中央までしっかり進む
  • 角度をつけてゆっくり曲がる
  • 徐行を保ったまま右折する

この走り方をすると、

  • 視線が安定する
  • ピラーの死角が動く
  • 隠れていた自転車や歩行者が視界に入る

という効果があります。

結果として、「見えていなかった存在」に気づく時間が生まれるのです。
講習で聞いたこの話は、とても当たり前のようでいて、普段の運転では忘れがちなことだと感じました。

ここまで運転中の右折時の話を書いてきましたが、講習を受けて、僕はこんなことも考えました。

これ、プログラミングでもまったく同じ場面がある！

ショートカット気味の右折 = if文の条件漏れ

右折をショートカット気味にすると、

  • 早く終わらせたい
  • 大丈夫そうに見える
  • これ以上確認しなくてもいい気がする

という心理が働きます。

プログラミングでいうと、これはまさにif文の条件を省略してしまう状態です。

if (age >= 18) {
  // OK
}

一見、問題なさそうに見えます。
見通しもいいし、シンプルです。

でも実際には、

  • age が数値じゃなかったら？
  • null や undefined だったら？
  • 想定外の値が来たら？

というケースが、ピラーの死角として残っています。

「たぶん来ないだろう」が一番危険

ショートカット思考の怖さは、

来ない前提でコードを書いてしまう

ことです。

  • この値は必ず入ってくる
  • この関数はこの順番で呼ばれる
  • ユーザーは変な操作をしない

どれも、見通しのいい交差点で
「たぶん大丈夫」と思う感覚とそっくりです。

そして事故（バグ）は、その「たぶん」の隙間から入り込んできます。

円弧を描く右折 = 安全設計のコード

一方、円弧を描くように右折するのは、

  • 少し遠回り
  • 少し遅い
  • 一見、無駄に見える

行動でした。

プログラミングでいうなら、
条件を丁寧に積み重ねる安全設計です。
（以下のコードは、JavaScript および TypeScriptで使われる書き方です）

if (typeof age !== 'number') return;
if (age < 0) return;

if (age >= 18) {
  // OK
}

処理は増えました。
正直、書くのも少し面倒です。

でもその分、

  • 想定外が入り込む余地が減る
  • バグが起きる範囲が限定される
  • 「見えなかったケース」が見える

ようになります。

もちろん、すべてを細かく書けばいいわけではありません。
省略した書き方でシンプルに表現するのは、決して悪いことではありません。

ただし、

  • 前提条件がコードから読み取れない
  • 条件を省きすぎて意図が伝わらない
  • 読んだ人が「察する」必要がある

ような書き方は、結果として不親切なコードになってしまいます。

大切なのは、

「短さ」より「伝わりやすさ」

遠回りに見えても、必要な条件をきちんと書いてあるコードの方が、
あとから読む人にも、自分自身にも、安全です。

大事なのは「速さ」より「見える時間」

右折の話でいえば、

  • 早く曲がる → 危険
  • ゆっくり曲がる → 安全

でした。

プログラミングも同じです。

  • 早く書く
  • 少ないコードで済ませる
  • スマートに見せる

ことよりも、

「何が起きうるかを考える時間」

を取るほうが、結果的に安全です。

プログラミングは「頭の中の交差点」

交差点で大事なのは、

  • 死角がある前提で動く
  • 見えていないものを想定する
  • 慎重すぎるくらいがちょうどいい

という意識でした。

プログラミングも同じで、

  • 思い込みを前提にしない
  • ユーザーを信用しすぎない
  • 「もしも」を潰していく

ことが、バグを防ぎます。

まとめ

見通しのいい交差点での右折も、シンプルに見えるコードも、
一番危険なのは「もう大丈夫だ」と思った瞬間です。

遠回りでもいい。
遅くてもいい。

見える時間を作る設計が、事故もバグも減らしてくれます。