バグを生むのは知識不足ではなく想像力不足である

この記事は約 6 分で読めます。

「知らなかった」のではなく「想像できなかった」

バグの原因を分析すると、大きく 2 種類に分かれます。

1 つは純粋な知識不足。API の仕様を知らなかった、言語の挙動を誤解していた。これは本を読めば解決します。

もう 1 つは想像力不足。「ユーザーがこの順番で操作するとは思わなかった」「このフィールドが空になるケースを考えていなかった」「同時に 2 人が同じデータを更新する状況を想定していなかった」。

後者のバグは、知識があっても防げません。必要なのは「こういうことも起きるかもしれない」と想像する力です。

想像力はどこから来るのか

エッジケースを想像する力は、経験から来ます。過去に「ユーザーが空文字を入力してシステムが落ちた」経験があれば、次からは空文字のチェックを忘れません。

しかし、すべてのエッジケースを自分で経験するのは不可能です。ここで技術書が役立ちます。技術書には、著者が経験した (あるいは見聞きした) 失敗パターンが凝縮されています。他人の失敗を追体験することで、自分の想像力の範囲を広げられます。

想像力を鍛える 3 つの読書法

1. 失敗事例を集中的に読む

技術書の中で最も想像力を鍛えるのは、失敗事例のセクションです。「こうしたらこう壊れた」「この設計にしたらこういう問題が起きた」。

ソフトウェア障害に関する本は、想像力のトレーニング教材として最適です。

失敗事例を読むとき、「自分のコードで同じことが起きないか」を考えてください。この 1 つの問いかけが、想像力を飛躍的に高めます。

2. テストの本を読む

テスト設計の本には、「どういうケースをテストすべきか」が体系的に書かれています。境界値分析、同値分割、状態遷移テスト。これらのテスト技法は、エッジケースを網羅的に洗い出すためのフレームワークです。

テスト技法を知っていると、コードを書く段階で「この入力の境界値は何か」「この状態遷移で抜けているパスはないか」と自然に考えるようになります。

3. セキュリティの本を読む

セキュリティの本は、「悪意のあるユーザーがどう攻撃するか」を想像する訓練です。SQL インジェクション、XSS、CSRF。これらの攻撃手法を知ると、「ユーザーの入力は信頼できない」という前提でコードを書くようになります。

セキュリティの知識は、防御的プログラミングの基礎です。「正常なケース」だけでなく「異常なケース」を常に想像する習慣が身につきます。

想像力が足りないコードの特徴

以下の特徴があるコードは、想像力不足の兆候です。

• null チェックがない
• エラーハンドリングが空の catch ブロック
• 入力値のバリデーションがない
• 同時実行を考慮していない
• ネットワーク障害を想定していない

これらはすべて「正常系しか想像していない」コードです。異常系を想像できていれば、自然と防御的なコードになります。

「もし○○だったら」を口癖にする

コードを書いているとき、以下の問いかけを習慣にしてください。

• もしこの値が null だったら？
• もしこの API がタイムアウトしたら？
• もしユーザーが戻るボタンを連打したら？
• もしデータが 100 万件あったら？
• もし 2 人が同時に同じデータを更新したら？

この「もし」の数が多いほど、堅牢なコードになります。そして、「もし」のバリエーションを増やすのが、技術書の失敗事例やテスト技法の知識です。

想像力と経験の関係

経験年数が長いエンジニアほど想像力が豊かなのは、多くの失敗を見てきたからです。しかし、経験だけに頼ると、自分が遭遇したパターンしか想像できません。

技術書を読むことで、自分が経験していないパターンも想像の引き出しに加えられます。10 年分の経験を 1 冊の本で追体験できる。これが技術書の最大の価値の 1 つです。

関連記事

• テスト本ガイド - テスト設計を学べる技術書の選び方
• セキュリティ本ガイド - Web 開発者が読むべき技術書の選び方

まとめ

バグの多くは知識不足ではなく想像力不足から生まれます。「こういうケースもありうる」と想像する力は、失敗事例の読書、テスト技法の学習、セキュリティの知識で鍛えられます。コードを書くとき「もし○○だったら」を口癖にし、技術書で想像力の引き出しを増やす。これが、堅牢なコードを書くための最も確実な方法です。