テスト駆動開発（TDD）とは？てすとくどうかいはつ
テスト駆動開発（TDD）とは、実装より先に、まだ通らないテストを書き、それを通す最小限のコードを書き、動作を保ったまま整理する、という短い周期を繰り返す開発の進め方。仕様が実行可能なテストとして残るため、変更時の後戻りを早期に検出できる。ST試験の文脈では、内製化やアジャイル開発を選ぶときに、品質をどう担保し、委託契約をどう組むかという判断材料として押さえる。
最終更新：2026-10-06
ITストラテジストを最短で暗記・合格する →背景
仕様書を書き切ってから作る進め方は、要件が固まっている領域では有効だが、作りながら仕様が変わる領域では、文書と実物の乖離が積み上がる。テストを先に書けば、仕様が実行できる形で残り、変更のたびに自動で検証されるため、乖離が発生した瞬間に分かる。文書の更新という人の努力に頼らずに仕様を維持する仕掛け、と捉えるのがITストラテジストの読み方になる。経営会議では「機能追加のたびに全体を人手で試験し直す費用が、この進め方では自動化された試験に置き換わる。初期の工数は増えるが、変更が続く領域ほど数年で回収できる」と、費用の前倒しとして説明する。
具体例
デジタル庁や、内製開発へ切り替えた企業のアジャイル開発では、自動テストの整備を前提にした短い開発周期が採られている。ベンダーへ委託する場合は、成果物として動くソフトウェアだけでなく自動テスト一式も納品対象に含め、次のベンダーへ引き継げる状態にするかどうかで、将来の乗り換え費用と保守の交渉力が変わる。
試験での引っ掛け
テストを通すことと、利用者の要求を満たすことは別で、この進め方は妥当性の確認（本当に業務に役立つか）を代替しない。またすべてを先にテストできるわけではなく、性能や外部システムとの結合など後段でしか確かめられない領域は残る。契約面での取り違えも多く、この進め方を採るからといって請負契約が不可能になるわけではないが、要件が変わり続ける前提なら準委任のほうが整合する、という順序で考える。
関連用語
出典・参考
解説は資格暗記が独自に作成しています。過去問の出典は各問題に記載のとおりです。