4.4ソフトウェア開発管理（アジャイル・DevOps/CI-CD・見積り・構成管理）

ソフトウェア開発管理の分野は、「どの開発モデルが向いているか」を状況から判断させる問題と、見積り・構成管理の計算/手順を問う問題の2系統に大別されます。前者はウォーターフォールとアジャイルの前提の違い（要件が固まっているか、変化を前提とするか）を、後者はファンクションポイント法やCOCOMOの計算ロジックを正確に押さえることが得点の鍵です。この節では開発モデルから見積り・構成管理まで、実務の意思決定の流れに沿って整理します。

4.4.1開発モデル（ウォーターフォール・アジャイル）

• ウォーターフォールモデル＝要件定義→設計→実装→テストを上流から下流へ順に進め、原則後戻りしない開発モデル。要件が早期に確定しており変化が少ない大規模システムに向く。スパイラルモデル＝リスク分析を伴いながら設計・実装・評価を反復し、段階的にプロトタイプを洗練させるモデル。
• アジャイル開発＝短い期間（イテレーション/スプリント）で計画・設計・実装・テストを繰り返し、動くソフトウェアを早期かつ継続的に届けることを重視する開発モデル群の総称。要件の変化を前提とし、変化への対応を歓迎する点がウォーターフォールと対照的。
• スクラム＝プロダクトオーナー（要求の優先順位付けとプロダクトバックログの管理）・スクラムマスター（チームを支援しプロセスを円滑化）・開発チームという役割分担で、スプリント（通常1〜4週間の固定期間）単位でスプリントバックログの項目を実装する。デイリースクラム（毎日の短時間の進捗共有）・スプリントレビュー（成果物のデモと確認）・スプリントレトロスペクティブ（プロセスの振り返り）という定例イベントを持つ。
• XP（エクストリームプログラミング）＝テスト駆動開発（TDD）（テストコードを先に書いてから実装する）・ペアプログラミング（2人1組で1台の端末を共有し実装とレビューを同時に行う）・リファクタリング（外部から見た振る舞いを変えずに内部構造を改善する）・継続的インテグレーションを実践の柱とするアジャイル手法。

4.4.2DevOps・CI/CD・IaC

• DevOps＝開発（Development）と運用（Operations）が密に連携・協働し、リリースの頻度と信頼性を両立させる文化・実践の総称。開発と運用が分断され「開発は早くリリースしたい、運用は安定性を優先したい」という対立が生じがちな従来型組織の課題を解消する狙いがある。
• CI（継続的インテグレーション）＝開発者が変更を頻繁に共有リポジトリへ統合し、そのたびに自動ビルド・自動テストを実行して問題を早期に検出する実践。CD（継続的デリバリー/デプロイ）＝CIを経たビルドを自動的に本番相当環境へデプロイ可能な状態にする（デリバリー）、あるいは自動的に本番へデプロイまで行う（デプロイ）実践。デリバリーは「デプロイ可能な状態を保つ」・デプロイは「実際に自動デプロイする」という到達点の違いを区別する。
• IaC（Infrastructure as Code）＝サーバやネットワークといったインフラ構成を、手作業ではなくコード（構成定義ファイル）として記述し、バージョン管理・自動適用の対象とする手法。構成の再現性・変更履歴の追跡・環境差異の削減が利点。SRE（Site Reliability Engineering）＝ソフトウェア工学の手法で運用信頼性を高める実践で、SLI/SLO/エラーバジェットを用いた定量的な信頼性管理を特徴とする。

4.4.3見積り技法と構成管理

• ファンクションポイント法＝画面・帳票・ファイル・外部インタフェース等の機能を利用者から見た規模で数え、その複雑さに応じた重み付けをして合計する見積り技法。プログラミング言語やコーディング量に依存せず、要件定義の早い段階から見積りできるのが利点。
• COCOMO（Constructive Cost Model）＝プログラムの規模（見積りコード行数）を基に開発工数を見積もるモデル。開発対象の性質（組込み型/半独立型/独立型）に応じた係数を用いる。基本COCOMOでは工数＝係数×(規模)^指数というべき乗の関係で、規模が大きくなるほど工数が規模以上の割合で増える（規模の経済が働きにくい）傾向を表す。
• 構成管理＝ソースコード・ドキュメント・設定ファイル等の構成品目を、変更履歴を追跡しながら一貫性を保って管理する活動。バージョン管理（Git等）は構成管理を支える中核技術で、コミット（変更の記録）・ブランチ（並行した変更系列）・マージ（ブランチの統合）・タグ（特定時点への印付け）といった操作で変更履歴を管理する。
• 変更管理（変更要求のプロセス）＝構成品目への変更は無秩序に行わず、変更要求→影響範囲の評価→承認→実施→記録という統制されたプロセスを経る。これにより「誰が・いつ・なぜ・何を変更したか」の責任追跡性を保ち、意図しない副作用の混入を防ぐ。

ある企業が旧来のウォーターフォール型開発から、リリース頻度と品質の両立を目指してアジャイル・DevOpsへ移行する過程を追って、各要素の役割を確認しましょう。従来は要件定義から半年かけて設計・実装・テストを順に進め、テスト工程で要件との齟齬が発覚しても後戻りのコストが大きいため見過ごされがちでした。そこでチームはスクラムを導入し、プロダクトオーナーがプロダクトバックログの優先順位を継続的に見直し、2週間のスプリントごとに動くソフトウェアを実際に届けてスプリントレビューでフィードバックを得るサイクルへ切り替えます。開発チーム内ではXP由来のテスト駆動開発（TDD）を採用し、実装前にテストコードを書くことで仕様の解釈違いを早期に検出し、ペアプログラミングでコードレビューを実装と同時に行います。リリース工程では、変更を共有リポジトリへ統合するたびに自動ビルド・自動テストを走らせるCIを整備し、テストに通ったビルドを自動的に本番相当環境へ配布できる状態に保つCD（継続的デリバリー）を構築します。さらにサーバやネットワークの設定もIaCとしてコード化し、バージョン管理システムで構成の変更履歴を追跡できるようにすることで、環境ごとの設定の食い違い（いわゆる「本番だけ動かない」問題）を防ぎます。新機能の開発規模を見積もる際には、コーディング量ではなく画面・帳票・外部インタフェースといった利用者から見た機能の数を基準にするファンクションポイント法を採用し、要件定義の早い段階でも規模感を関係者と共有できるようにします。一方、大規模な基幹システムの刷新など要件が早期に確定し変更が少ないプロジェクトでは、依然としてウォーターフォールモデルが適しており、「アジャイルが常に優れている」という短絡は避けるべきです。

4.4.4この節のまとめ

• ウォーターフォール=要件確定・後戻りなし／アジャイル(スクラム/XP)=変化前提の短い反復。スクラムの3役割・3イベント、XP=TDD/ペアプログラミング/リファクタリング
• CI=頻繁な統合+自動テスト／CD=デプロイ可能な状態維持 or 自動デプロイ。IaCでインフラ構成をコード化し版管理
• ファンクションポイント法=利用者視点の機能数で見積り／COCOMO=コード規模のべき乗で工数見積り。構成管理=変更履歴の一貫した追跡