/note/tech

AIの使い方を学ぶ前に、まずソフトウェア工学を

要約:

■ 1. 本稿の主張

  • AIの使い方より先にソフトウェア工学を理解すべき:
    • AIにテストコードを書かせる例で説明する
    • AIは高速にテストコードを書くが、テスト理論を理解していないとバグを見逃すテストを書かせてしまう

■ 2. テスト理論の基礎

  • ブラックボックステストとは:
    • コードの中身を見ず、仕様(入力と出力)だけを基準にテストする方法
    • 「入力に対し仕様どおりの結果が返るか」を確認する
    • 境界値分析や同値分割はこちらに含まれる技法
  • ホワイトボックステストとは:
    • コードの内部構造(分岐、ループ、処理経路)を見てテストする方法
    • 「if文のtrue側とfalse側の両方を通したか」を確認する
    • 通過度合いはカバレッジという数値で測定できる
  • 理論上の核心的な分離:
    • ホワイトボックスであっても、コードを基準にしてよいのはテストの経路選択のみ
    • 結果が正しいかどうかの判定(期待値)は必ず仕様から立てる必要がある
    • コードの挙動をそのまま正解とすると、バグごとテストが追認されてしまう

■ 3. 検証に使った題材コード

  • 料金計算関数の仕様:
    • 10,000円以上は10%オフ、会員はさらに5%オフ
  • 実装に仕込まれた問題:
    • 仕様は「以上(>=)」だが、実装は「超(>)」になっている境界値バグ
    • 仕様書に記載のない負数チェックの分岐が実装者により独自に追加されている

■ 4. 失敗例:理論を意識せずにAIへ指示した場合

  • 与えた指示:
    • 「このコードのテストを書いて。カバレッジ100%にして」という素朴な依頼
  • AIが生成したテストの問題点:
    • AIはコードを読んで期待値を逆算する
    • 10,000円ちょうどのケースについて「コード上は>10000に該当しないため割引なし」と解釈し、バグの挙動をそのまま正解としてテストに固定する
    • 負数チェックの分岐についても、コードにある挙動をそのまま期待値としてしまう
  • 実行結果:
    • 4件のテストが全てパスし、分岐カバレッジも100%となる
    • 数字上は完璧に見えるが、境界値バグの検出はゼロである
    • 指標がすべて良好であるため、この見逃しに気づく手段がない

■ 5. 成功例:テスト理論を踏まえてAIへ指示した場合

  • プロンプトの設計方針:
    • 「経路はコードから選び、期待値は仕様から導く」という分離を指示に落とし込む
    • カバレッジ設計はソースコードの全分岐・例外パスを洗い出して行う
    • 期待値設計は仕様書のみを参照し、ソースコードの出力を期待値に流用することを禁止する
    • 境界値分析を適用し、境界(10,000円)の直前・ちょうど・直後を必ず試す
    • 仕様書に記載がなく期待値を判断できないケースは、期待値を書かず「要確認」として質問リストに出すよう指示する
    • 各テストには通す分岐の根拠と期待値の根拠をコメントで明記させる
  • 実行結果:
    • 境界値10,000円ちょうどのテストが失敗し、バグ検出に成功する
    • 分岐カバレッジは87%にとどまり、負数チェックの分岐が未達となる
    • AIは負数分岐について期待値をでっち上げず、「負の金額の仕様はどうなっているか」という質問として報告する
    • カバレッジの未達がそのまま仕様書の記載漏れの発見につながっている

■ 6. 両者の比較

  • 素朴なプロンプトの結果:
    • テスト結果は4件パスで全て緑
    • カバレッジは100%
    • 境界値バグは追認され見逃される
    • 仕様にない分岐は期待値がでっち上げられる
  • 理論に基づくプロンプトの結果:
    • テスト結果は1件失敗し、バグが検出される
    • カバレッジは87%にとどまり、これは仕様漏れの兆候である
    • 境界値バグが検出される
    • 仕様にない分岐は要確認として報告される
  • 逆説的な結論:
    • 数字だけ見れば失敗例のほうが良く、成功例のほうが悪い
    • しかし健全なのは数字が悪く見える成功例のほうである

■ 7. AIの使い方よりソフトウェア工学が重要だという結論

  • 2つのプロンプトの差の正体:
    • 差はAIの使い方のテクニックではなく、テスト理論を知っているかどうかの差である
    • 「経路はコードから、期待値は仕様から」も「境界のちょうどの値を試す」も、いずれも従来からあるテスト理論に基づく
  • 理論を知らないことの制約:
    • 境界値分析を知らなければ、「10,000円ちょうどを試す」という発想自体がプロンプトに出てこない
    • AIは指示された観点しか網羅しないため、観点を出せない人はプロンプトの書き方を工夫しても差を埋められない
  • AI活用ノウハウとソフトウェア工学の関係:
    • AIの使い方講座やスライド作成術のような情報は有用であり、業務効率を大きく向上させる
    • しかしソフトウェア開発者にとって重要なのはソフトウェア開発の基本的な理論である
    • 「このコードのテストで何を検証すべきか」という問いは、聞く側に理論がなければそもそも正しい質問にならない
  • AIと人間への指示の共通性:
    • AIに指示を出すことと人間に指示を出すことは本質的に同じである
    • 後輩に「このコードのテスト書いといて」とだけ伝えた場合も同様の失敗が起こり得る
    • 指示する側が中身を理解していなければ、きちんと伝えることはできない
  • 結論:
    • AIはテストコードを書く速度を劇的に向上させた
    • だからこそ「何を検証すべきか」を決める側の理論、すなわちソフトウェア工学の価値はむしろ上がっている
    • AI時代に学ぶべきものを問われれば、ソフトウェア工学だと答える
    • いつの時代でも基本が重要である