5.2ソフトウェア開発管理

システムをどのような進め方で作るかは、要件の変化しやすさやリリース頻度の要求によって最適解が変わります。開発モデルの選び方、開発とリリースを自動化・高速化するDevOpsとCI/CD、そして開発規模を数値で見積る技法を押さえ、状況に応じた判断ができるようになることが目標です。

5.2.1開発モデルの特徴と選択基準

• ウォーターフォールモデル＝要件定義→設計→実装→テストの各工程を順番に、後戻りしない前提で進める伝統的モデル。工程ごとの成果物が明確で大規模プロジェクトの進捗管理に向く一方、要件が開発途中で確定しにくい案件には不向き（後工程での要件変更ほど手戻りが大きい）。
• アジャイル開発＝要件変化への迅速な対応を重視し、短い期間（イテレーション/スプリント）を繰り返しながら動くソフトウェアを段階的に作る開発手法群の総称。スクラム＝アジャイルの代表的フレームワークの1つで、スプリント（短い固定期間）ごとに優先度順のプロダクトバックログから作業項目を選び開発する。XP（エクストリームプログラミング）＝ペアプログラミング・テスト駆動開発（TDD）・リファクタリングなどのプラクティスを重視するアジャイル手法。
• 選択基準＝要件が明確で変化が少なく、大規模・厳格な進捗管理が要る案件はウォーターフォールが適し、要件が変化しやすく、早期に利用者フィードバックを反映したい案件はアジャイルが適します。両者は優劣ではなく適用条件が異なるという理解が重要です。

5.2.2DevOps・CI/CD・IaC

• DevOps＝開発（Development）と運用（Operations）が協調してリリースの頻度と信頼性を高める文化・実践。CI（継続的インテグレーション）＝コード変更のたびに自動ビルド・自動テストを実行し統合の問題を早期発見する仕組み。CD（継続的デリバリー/デプロイメント）＝CIを経たコードを自動的に本番へリリース可能な状態にする（または実際にリリースする）仕組み。CI/CDにより手作業のリリース工程が削減され、リリース頻度と品質の両立を図れます。
• IaC（Infrastructure as Code）＝サーバーやネットワークなどのインフラ構成をコード（定義ファイル）として記述・管理する手法。手作業での構築に比べ、再現性が高く（同じコードから同じ環境を何度でも作れる）、構成の変更履歴をバージョン管理できる利点があります。

5.2.3見積り技法と構成管理

• ファンクションポイント法（FP法）＝画面数・帳票数・入出力データ数など利用者から見える機能の数と複雑さを点数化して開発規模を見積る技法。プログラム言語や実装方式に依存せず、利用者視点で規模を測れるのが特徴で、要件定義の早い段階から見積りが可能です。
• COCOMO（Constructive Cost Model）＝プログラムの推定行数（開発規模）を基準に、工数・開発期間を数式で見積るモデル。開発の複雑さに応じて基本型（organic）・中間型（semidetached）・組込み型（embedded）の3モードがあり、モードによって係数が変わります。ファンクションポイント法が「機能の数」を起点にするのに対し、COCOMOは「コード規模（行数）」を起点にする点が対照的です。
• 構成管理＝プログラム・ドキュメントなどの成果物のバージョンと変更履歴を体系的に管理する活動。バージョン管理（システム）＝ソースコードの変更履歴を記録し、差分の把握・過去バージョンへの復元・複数人での並行編集（ブランチ/マージ）を可能にするツール群。構成管理はより広い概念で、バージョン管理はその中核をなす実現手段の1つと位置づけられます。

ある新規Webサービスの立ち上げを例に、これらの技法のつながりを見てみます。要件がまだ流動的で、利用者の反応を見ながら機能を追加していく方針であれば、ウォーターフォールで最初に全てを固めるのではなく、スクラムで短いスプリントを繰り返しながら優先度の高い機能から作り、プロダクトバックログを都度見直す進め方が適しています。開発の初期見積りでは、まだ実装言語や内部構造が固まっていないため、画面数や入出力データ数から規模を算出できるファンクションポイント法で「利用者に見える機能の量」を見積り、予算やスケジュールの目安を立てます。実装が進みコード規模の見通しが立ってきた段階では、COCOMOのようなコード行数ベースのモデルで工数を再見積りし、当初の見積りとの乖離を確認する、という使い分けが実務では行われます。開発が進むにつれて、ソースコードはバージョン管理システム（Gitなど）で管理し、機能追加はブランチを切って並行開発、レビューを経てマージするという構成管理のプロセスを回します。そしてコードがマージされるたびにCIが自動テストを走らせて統合の問題を即座に検出し、テストを通過したコードはCDの仕組みによって自動的に検証環境・本番環境へリリース可能な状態になります。さらにサーバーやネットワークの設定を手作業でなくIaCとして定義ファイルに落とし込んでおけば、検証環境と本番環境を同一のコードから再現性高く構築でき、環境差異に起因する障害を減らせます。このように、開発モデル・見積り・構成管理・CI/CD/IaCは互いに独立した技法ではなく、要件の変化しやすさと自動化の必要性という共通の軸でつながっていることを理解しておくと、状況に応じた技法選択の判断がしやすくなります。

5.2.4この節のまとめ

• ウォーターフォール＝要件明確・大規模・厳格管理向き。アジャイル/スクラム/XP＝要件変化への迅速対応・早期フィードバック向き（スクラムはスプリント＋プロダクトバックログ）
• CI＝自動ビルド/テストで早期に統合検証、CD＝自動リリース準備/実施。IaC＝インフラ構成をコード化し再現性とバージョン管理を実現
• ファンクションポイント法＝機能の数が起点（利用者視点）、COCOMO＝コード行数が起点。構成管理（成果物のバージョン/変更履歴管理）の中核がバージョン管理システム