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

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

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

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

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

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

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

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

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

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

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

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

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

ソフトウェア障害を扱った本は、自分がまだ踏んでいない地雷の一覧として読めます。

失敗事例を読むとき、「自分のコードで同じことが起きないか」を考えてください。読んで終わりにせず、手元のコードへ引き当てる。この一手間があるかどうかで、同じ本を読んでも後に残るものが変わります。

2. テストの本を読む

テスト設計の本には、「どういうケースをテストすべきか」が体系的に書かれています。境界値分析、同値分割、状態遷移テスト。これらは、無数にある入力の中から「壊れやすい代表値」を絞り込むための手順です。

ここで誤解しやすいのは、技法を覚えれば抜けが無くなるわけではない点です。JSTQB の Foundation Level シラバス (V4.0・2023 年 4 月 12 日版) は、同値分割法について「各パーティションに対して 1 つのテストがあれば十分である」と説明しています。同じ扱いを受けるはずのデータをひとまとめにして 1 件で代表させる技法であり、全パターンを試すものではありません。同シラバスは、経験ベースの技法がブラックボックスやホワイトボックスの技法では見逃す欠陥も検出できるとも述べています。技法は想像の抜けを減らしますが、ゼロにはしません。だからこそ、失敗事例で仕入れた「こういう壊れ方がある」という引き出しが技法と噛み合います。

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

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

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

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

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

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

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

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

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

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

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

挙げられる「もし」の数が、そのまま想定できる異常系の幅になります。そして、「もし」のバリエーションを増やすのが、技術書の失敗事例やテスト技法の知識です。

想像力と経験の関係

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

技術書を読むことで、自分が経験していないパターンも想像の引き出しに加えられます。自分では踏まなかった失敗を、他人の記録として先に知っておけます。これが技術書の価値の 1 つです。

関連記事

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

まとめ

バグの多くは知識不足ではなく想像力不足から生まれます。「こういうケースもありうる」と想像する力は、失敗事例の読書、テスト技法の学習、セキュリティの知識で鍛えられます。コードを書くとき「もし○○だったら」を口癖にし、技術書で想像力の引き出しを増やしてください。テスト技法は抜けをゼロにはしませんが、想像できる異常系の幅は、仕入れた失敗事例の数だけ広がります。