4-2 ソフトウェア開発管理技術
ソフトウェア開発管理技術
ソフトウェア開発管理技術では、要件の変化、品質、納期、リスクに応じて開発方法を選び、ソースコード、設定、テスト、リリースを一貫して管理します。ITパスポートでは、「ウォーターフォールかアジャイルか」という単純な優劣ではなく、プロジェクトの条件に合う進め方を判断する問題が出題されます。
この節の目標は、代表的な開発モデル、スクラム、DevOps、CI/CD、構成管理、変更管理、品質管理を具体的な開発ケースへ適用できるようになることです。
1. 開発モデルを条件で選ぶ
| モデル | 進め方 | 向いている条件 | 注意点 |
|---|---|---|---|
| ウォーターフォール | 工程を原則として順番に進める | 要件が比較的明確で、承認・文書化を重視する | 後半の大きな変更は影響が広い |
| プロトタイピング | 試作品を作り、利用者と確認する | 画面や操作性、要求が曖昧な部分を確認したい | 試作品をそのまま本番品質と誤解しない |
| スパイラル | 開発とリスク評価を段階的に繰り返す | 大規模で技術・要件リスクが高い | 管理が複雑になりやすい |
| アジャイル | 短い期間で価値ある機能を作り、反応を得て改善する | 変化が多く、利用者と継続的に確認できる | 全体目的、品質、技術的負債も管理する |
| DevOps | 開発と運用が協力し、変更を安全・継続的に届ける | 頻繁な改善と安定運用を両立したい | ツール導入だけで文化や責任分担は変わらない |
規制対応システムでもアジャイルを一切使えないわけではなく、変更が多いWebサービスでも全てを無計画に進めてよいわけではありません。必要な統制、文書、受入条件を保ちながら適切な方法を組み合わせます。
2. 完全ケース：新しい会員アプリの開発方法
小売会社が会員アプリを開発します。基本的な会員管理と決済連携には厳格なセキュリティ要件があります。一方、クーポン画面やおすすめ機能は利用者の反応を見ながら改善したいと考えています。
適切な進め方の例は次のとおりです。
- 会員・決済の要件、権限、監査ログ、外部連携は早期に明確化する。
- 画面やおすすめ機能は試作品で利用者の反応を確認する。
- 短いスプリントで小さな機能を完成させる。
- 各変更に自動テスト、レビュー、セキュリティ確認を適用する。
- 本番リリースは承認、監視、切戻し手順を用意する。
「アジャイルだから設計書やテストは不要」「ウォーターフォールだから要件変更は禁止」という判断は誤りです。必要な品質と統制を満たしながら、変化への対応方法を選びます。
3. スクラムの役割と作成物
| 要素 | 主な役割・内容 |
|---|---|
| プロダクトオーナー | 製品価値を最大化し、プロダクトバックログの優先順位を管理する |
| スクラムマスター | スクラムの理解と実践を支援し、妨げの除去を促す |
| 開発者 | スプリント内で利用可能なインクリメントを作る |
| プロダクトバックログ | 製品に必要な機能、改善、修正などの優先順位付き一覧 |
| スプリントバックログ | 当該スプリントで実施する作業と計画 |
| インクリメント | 完成条件を満たし、利用可能な成果の積み上げ |
| 完成の定義 | 完成と判断する共通の品質基準 |
スクラムの主なイベント
- スプリントプランニングで目標と作業を決める。
- デイリースクラムで開発者が計画を調整する。
- スプリントレビューで成果と今後の方向を関係者と確認する。
- スプリントレトロスペクティブで進め方を改善する。
デイリースクラムは上司への詳細報告会ではありません。開発者がスプリント目標に向けて計画を調整するための短い機会です。
4. 要求を小さくし、価値を確認する
ユーザーストーリーは、利用者の視点から必要な価値を簡潔に表します。
会員として、購入履歴を確認したい。家計管理に利用するためである。
ただし、文章を書いただけではテストできません。受入条件を追加します。
- ログインした本人の購入履歴だけを表示する。
- 購入日、店舗、商品、金額を表示する。
- データがない場合は適切な案内を表示する。
- 他人の会員番号を指定しても閲覧できない。
大きな要求を小さく分けると、早く確認でき、失敗時の影響も小さくできます。一方、画面単位だけに分け、利用者価値が完成しない状態を量産しないようにします。
5. DevOpsとCI/CD
DevOpsは、開発と運用が共通の目標と情報を持ち、変更を素早く安全に提供する考え方です。
| 用語 | 内容 | 目的 |
|---|---|---|
| CI | 変更を頻繁に統合し、自動ビルド・テストを行う | 統合時の問題を早期に発見する |
| 継続的デリバリー | 本番へ安全にリリース可能な状態を保つ | 必要な時に承認して公開できるようにする |
| 継続的デプロイメント | テストを通過した変更を自動的に本番へ反映する | 小さな変更を頻繁に届ける |
| IaC | インフラ構成をコードとして定義・管理する | 再現性を高め、手作業の差を減らす |
| 可観測性 | ログ、メトリクス、トレースなどから内部状態を理解する | 障害の早期発見と原因分析を支援する |
継続的デリバリーと継続的デプロイメントは同じとは限りません。前者はいつでもリリース可能な状態を保ち、後者は自動的な本番反映まで含みます。
6. 安全なリリースの流れ
- 開発者が小さな変更をバージョン管理へ登録する。
- 自動ビルド、単体テスト、静的解析を実行する。
- コードレビューと必要な承認を行う。
- 結合・システム・セキュリティテストを実施する。
- 本番に近い環境で構成と移行を確認する。
- リリース計画、監視項目、切戻し条件を確認する。
- 段階的に公開し、エラー率や性能を監視する。
- 問題時は切戻し、原因分析、再発防止を行う。
リリース方式
| 方式 | 内容 | 特徴 |
|---|---|---|
| 一斉切替え | 全利用者を一度に新バージョンへ切り替える | 短時間だが失敗時の影響が大きい |
| 段階リリース | 部門・地域・利用者の一部から順に公開する | 影響を限定しながら確認できる |
| ブルーグリーン | 旧・新の二環境を用意し、接続先を切り替える | 切戻しやすいが環境費用が増える |
| カナリアリリース | 少数の利用者へ先行公開し、問題を監視する | 実環境で小さく検証できる |
| フィーチャーフラグ | コードを配置したまま機能の有効・無効を切り替える | 公開範囲を制御できるが設定管理が必要 |
7. 構成管理・変更管理・リリース管理
| 管理 | 主な対象 | 目的 |
|---|---|---|
| 構成管理 | ソースコード、文書、ライブラリ、設定、環境 | 何がどの版で構成されているか識別・統制する |
| バージョン管理 | ファイルの変更履歴、分岐、統合 | 誰が何を変更したか追跡し、必要なら戻す |
| 変更管理 | 変更要求、影響、承認、実施結果 | 無秩序な変更による障害を防ぐ |
| リリース管理 | 本番へ提供する変更の組合せと展開 | 適切な版を計画的に公開する |
ソースコードだけでなく、データベース定義、クラウド設定、外部ライブラリ、テスト結果、手順書も構成管理の対象です。
変更要求の判断手順
- 変更の目的と緊急度を記録する。
- 要件、設計、コード、テスト、運用への影響を分析する。
- 費用、納期、品質、リスクを見積もる。
- 権限を持つ人が承認・却下・延期を決める。
- 実装・テスト・リリース・切戻しを計画する。
- 実施後に結果と文書を更新する。
8. 品質を測定し改善する
| 指標・活動 | 読み取れること | 注意点 |
|---|---|---|
| 欠陥件数 | 発見された問題の数 | 規模や重大度を考慮する |
| 欠陥密度 | 規模当たりの欠陥数 | 規模の測り方を統一する |
| テスト網羅率 | 実行したコード・条件などの割合 | 高くても欠陥ゼロを保証しない |
| レビュー指摘 | 早期に見つけた問題 | 件数だけで担当者を評価しない |
| 変更失敗率 | リリース後に障害や修正が必要となった割合 | 速度と安定性を合わせて見る |
| 平均復旧時間 | 障害から復旧するまでの時間 | 検知・判断・復旧の各段階を改善する |
品質はテスト担当だけの責任ではありません。要件、設計、実装、レビュー、運用の各段階で作り込みます。
9. 外部委託とソフトウェア部品の管理
外部委託やオープンソースソフトウェアを利用するときは、次を確認します。
- 委託範囲、成果物、受入条件、知的財産、秘密保持。
- 再委託、事故報告、脆弱性対応、契約終了時のデータ処理。
- 使用するライブラリの版、ライセンス、既知の脆弱性。
- 更新元と配布物の完全性。
- 保守終了日と代替計画。
SBOMは、ソフトウェアを構成する部品や依存関係を把握するための一覧です。作成するだけで安全になるわけではなく、脆弱性情報と照合し、影響を判断して更新します。
10. よくある誤りと理由
- ウォーターフォールは変更禁止と考える：変更は影響を評価し、正式に管理します。
- アジャイルは計画・文書・テストが不要と考える：短いサイクルでも必要な品質と統制を保ちます。
- プロダクトオーナーが開発者へ作業方法を細かく指示する：価値と優先順位を管理し、開発方法はチームが検討します。
- CI/CDを導入すれば自動的に高品質になる：テスト、レビュー、監視、判断基準が必要です。
- 構成管理はソースコードだけと考える：設定、文書、ライブラリ、環境も対象です。
- 緊急変更は記録や承認が不要と考える：簡略化した緊急手順と事後確認が必要です。
- 品質指標が高ければ利用者価値も高いと考える：技術品質と業務成果の両方を確認します。
11. セルフチェック
- 要件の変化、リスク、文書・承認の必要性から開発モデルを選んだか。
- スクラムの役割、バックログ、イベントを区別できるか。
- CI、継続的デリバリー、継続的デプロイメントを区別したか。
- 構成管理、変更管理、リリース管理の対象を確認したか。
- リリース時の監視と切戻しを計画したか。
理解を確認したら、第4章の練習問題と第4章の知識カードで開発モデルと管理活動を使い分けてください。工程とテストはシステム開発技術、日程・リスク管理はプロジェクトマネジメントで確認できます。
公式範囲との対応
本節は、IPA「ITパスポート試験シラバス Ver.6.5」の開発プロセス・手法、知的財産適用管理、開発環境管理、構成管理・変更管理に対応し、ウォーターフォール、プロトタイピング、スパイラル、アジャイル、スクラム、DevOps、CI/CD、IaC、構成・変更・リリース管理を扱います。