1.2開発手法とテスト

自動化コードは一度書いて終わりではなく、要件変化に追随し壊れないよう育てるものです。だからこそ「どの手順で開発を進めるか（手法）」と「変更しても壊れないと保証する仕組み（テスト）」が問われます。この節では、要件が固いか変わりやすいかで手法を選ぶ判断と、実装より先にテストを書くTDDの回し方を、「この状況でどう進めるか」「この失敗テストは何を意味するか」という現場の判断として学びます。単なる手法名の暗記ではなく、置かれた状況に対して適切な進め方を選べることが目標です。

1.2.1開発手法の使い分け

• ウォーターフォール＝要件定義→設計→実装→テスト→運用と前工程を固めてから次へ進む逐次モデル。要件が明確で変わりにくく、規制や契約で工程の証跡が要る案件に向く。反面、後半での要件変更にコストが高く、動くものが出るのが遅い。
• アジャイル＝短い反復（イテレーション/スプリント）で動くものを小刻みに届け、フィードバックで方向を修正する反復・漸進モデル。要件が変わりやすい/初めは曖昧な案件に強い。ネットワーク自動化のように環境や要求が動く領域と相性がよい。
• リーン＝ムダの排除と価値の最速検証を重視する考え方。仮説を最小限の実装（MVP）で早く試し、学びに基づいて続けるか方向転換するかを決める。アジャイルと親和的で、「作る前に本当に必要かを確かめる」姿勢が核。

1.2.2テスト駆動開発（TDD）

• TDDは実装より先にテストを書く。サイクルはレッド（まだ実装がないので失敗するテストを書く）→グリーン（テストを通す最小限の実装を書く）→リファクタ（テストが緑のまま内部を整える）。失敗テストは「未達の仕様」を示す指標であり、消すものではない。
• ユニットテストは関数/メソッド単位の小さな検証で、高速に多数回せる。自動化スクリプトでは、機器やAPIへの依存をモックに置き換えて、ロジックだけを再現性高く検証する。回帰（過去の機能が壊れる）を早期に捕まえられるのが最大の価値。

あなたのチームは、機器から取得したインタフェース速度を集計する新しい関数summarize_speeds()をTDDで開発しています。まず仕様「速度リストの合計と最大を返す」を表す失敗テストを書きました（実装がまだ無いので当然レッド）。ここで別のメンバーが「CIが赤いままではマージできないから、この失敗テストを一旦削除しよう」と言い出します。これはTDDの意味を取り違えた判断です。レッドのテストは「まだ満たしていない仕様」を可視化しているのであって、消せば仕様の証跡ごと失われます。正しい次の一手は、テストを通す最小限の実装を書いてグリーンにすること——例えば合計はsum(speeds)、最大はmax(speeds)を返すだけの素直な実装です。緑になったら、可読性や重複をリファクタで整えますが、その間もテストは緑のまま＝振る舞いを壊していないことが保証されます。さらに現実には、summarize_speeds([])（空リスト）でmax([])が例外を投げる、というエッジケースが後から見つかることがあります。このときも手順は同じで、まず空リストの期待挙動を表す失敗テストを追加（レッド）→空なら合計0・最大はNoneを返す分岐を実装（グリーン）→整える（リファクタ）と回します。開発手法の観点でも、こうした仕様が実装しながら見えてくる案件は、前工程を固めきるウォーターフォールより、短い反復で気づきを取り込むアジャイルが向いています。要点は、失敗テストを「邪魔な赤」ではなく次に実装すべき仕様の指し示しとして読む判断です。

1.2.3この節のまとめ

• ウォーターフォールは要件が固い逐次案件、アジャイルは変化に追随する反復、リーンはMVPで最速検証——要件の変動性で選ぶ
• TDDはテストを先に書きレッド→グリーン→リファクタで回す。失敗テストは仕様の指標で、消さず最小実装で緑にする
• ユニットテストは関数単位の高速検証で回帰を早期に捕まえる。エッジケースは「失敗テスト追加→実装→整える」の順で扱う