6.4開発プロセスとDevOps

開発プロセスの選択とリリース後の保守運用は、システムのライフサイクル全体を左右します。システムアーキテクトは、要件の確定度・変化の速さという制約からウォータフォールとアジャイルのどちらが適合するかを判断し、リリース後に発生する障害・要望・環境変化を保守の4分類に基づいて適切な対応へ振り分ける責任を負います。分類を誤ると、緊急対応すべき障害が計画外の改修に紛れて後回しにされる、といった事故につながります。

6.4.1ウォータフォール・反復型・アジャイル

• ウォータフォールモデル＝要件定義→設計→実装→テストという工程を上流から下流へ後戻りしない前提で順に進める開発モデル。要件が早期に確定し変化しにくい大規模システムでは進捗管理・予算管理がしやすい利点があるが、後工程で要件変更が生じると手戻りコストが大きい弱点がある。
• 反復（イテレーティブ）型＝要件定義から実装・テストまでの一連の工程を小さな単位（イテレーション）で繰り返し、都度フィードバックを取り入れて機能を積み上げていく開発モデル。アジャイル（代表例：スクラム）はその実践形態で、短い期間（スプリント）ごとに動くソフトウェアを作り、優先順位や要件の変化に柔軟に追従できる。要件が変化しやすい・早期に価値を届けたいプロジェクトに向く。

6.4.2CI/CDと保守の4分類

• CI（継続的インテグレーション）＝開発者がコードを変更するたびに自動でビルド・テストを実行し、問題を早期に検出する仕組み。CD（継続的デリバリー/デプロイ）＝CIを経たコードを本番相当環境へのリリース（デリバリー）まで、あるいは本番への反映（デプロイ）まで自動化する仕組み。手動リリース作業のばらつき・ミスを減らし、リリース頻度を高められる。
• 是正保守＝本番稼働後に発覚した不具合（バグ）を修正する保守。適応保守＝OS・ミドルウェアのバージョンアップや制度改正など、外部環境の変化にシステムを適応させる保守（システム自体に不具合はない）。
• 予防保守＝将来の不具合発生を未然に防ぐため、潜在的なリスク箇所を先回りして手当てする保守（例：ログ監視で兆候をつかみディスク枯渇前に対処）。完全化保守＝不具合ではなく、性能改善や使い勝手向上など機能を積極的に向上させる保守。4分類は「不具合対応か否か」「システム側の要因か外部要因か」「事後対応か事前対応か」で整理すると識別しやすい。

あるシステムアーキテクトが、リリース済みの基幹システムに関する複数の依頼を受け取り、それぞれをどう分類し対応すべきか判断するとします。1件目は「特定条件下で注文金額の計算が誤る」という報告で、これは本番稼働後に発覚した不具合の修正＝是正保守に分類し、影響範囲の大きさから最優先で対応します。2件目は「利用中のミドルウェアが2027年にサポート終了するため、その前にバージョンアップ対応が必要」という依頼で、システム自体にバグはなく外部環境（サポート終了）への適応＝適応保守であり、計画的に予算とスケジュールを確保して対応します。3件目は「ログを監視していたところ、特定のログファイルが半年後には想定ディスク容量を超過する見込みが判明した」というもので、まだ実害は出ていないが将来の障害を未然に防ぐ予防保守として、ディスク拡張やログローテーション設定の見直しを計画的に行います。4件目は「現状の検索機能は要件通り動作しているが、利用者から応答をもっと速くしてほしいという要望が継続的に来ている」というもので、不具合ではなく機能・性能の積極的な向上を求める完全化保守に分類し、他の改修の優先度と比較のうえ次期リリースに組み込むかを判断します。並行して、これらの保守対応を迅速かつ安全にリリースできるよう、コード変更のたびに自動でビルド・テストを行うCIと、テスト済みコードを本番相当環境へ自動的にデリバリーするCDのパイプラインを整備し、特に是正保守（バグ修正）を迅速に本番へ届けられる体制を強化します。このように、依頼の性質（バグか環境変化か将来リスクか機能向上か）を見極めて4分類に振り分け、優先度と対応方法を判断するのが実務です。

6.4.3この節のまとめ

• ウォータフォール＝要件確定・大規模向き、手戻り大、アジャイル（スクラム）＝要件変化に強い短期反復
• CI＝自動ビルド/テスト、CD＝リリース/デプロイまで自動化
• 保守4分類：是正＝バグ修正／適応＝外部環境変化への追従／予防＝将来の不具合を先回り／完全化＝機能・性能の積極改善