基本情報技術者試験過去問 令和6年度（2024年）科目A問14
システムの開発部門と運用部門が別々に組織化されているとき，システム開発を伴う新規サービスの設計及び移行を円滑かつ効果的に進めるための方法のうち，適切なものはどれか。
選択肢
- ア：運用テストの完了後に，開発部門がシステム仕様と運用方法を運用部門に説明する。
- イ：運用テストは，開発部門の支援を受けずに，運用部門だけで実施する。
- ウ：運用部門からもシステムの運用に関わる要件の抽出に積極的に参加する。
- エ：開発部門は運用テストを実施して，運用マニュアルを作成し，運用部門に引き渡す。
- ア
- イ
- ウ
- エ
正解と解き方・学習ポイント（AI解説）
開発部門と運用部門が分かれている場合は、運用開始後に必要になる作業や制約を、要件の段階から設計に反映させることが重要です。運用部門が運用に関わる要件の抽出に参加しておくと、運用できない設計や移行計画による手戻りを減らし、設計と移行を円滑かつ効果的に進められます。
Point
この問題は、開発部門と運用部門が分かれている組織で、新規サービスの設計から移行までを円滑に進めるには、運用部門がいつ、どの工程で関与するのが適切かを理解しているかを確認しています。
解くために必要な知識
この問題を解くには、開発部門と運用部門が分離しているときに、運用に必要な条件を要件として早期に取り込み、設計と移行に反映する考え方の理解が必要です。
用語の整理
| 用語 | 意味 |
|---|---|
| 運用テスト | 本番運用を想定して、運用手順、監視、バックアップ、障害対応などが問題なく実施できるかを確認するテストです。 |
| 要件抽出（要件定義） | 必要な機能、性能、運用方法などの条件を洗い出し、関係者で合意して文書化する作業です。 |
| 移行 | 新サービスへ切り替えるための準備と実施です。例として、データ移行、切替手順、教育、切替計画の作成などがあります。 |
他の選択肢に出てくる用語
| 用語 | 意味 |
|---|---|
| 運用マニュアル | 運用手順、監視方法、定常作業、障害時対応などをまとめた手順書です。 |
運用要件として扱う内容
運用部門が要件抽出に参加する目的は、運用上の必要条件を設計の前提として決めることです。運用要件の例は次のとおりです。
-
監視項目、ログの取得内容と保管期間
-
バックアップ方式、復旧手順、復旧に要する時間の目標
-
権限設計、運用作業の担当分担、運用体制で実施可能な手順
-
障害時の連絡手順、エスカレーション、手順の切替条件
手戻りが起きやすいパターン
運用要件を後から伝える進め方だと、次のような問題が起きやすいです。
-
運用部門の体制では実施できない手順になっている
-
監視やログが不足していて、障害原因の特定に必要な情報が取れない
-
バックアップや復旧の設計が運用要件を満たしていない
このため、運用要件は設計の早い段階で取り込むのが原則です。
問題の解法手順
設計・移行を円滑にするには、運用開始後に必要な条件を、後工程の引継ぎ事項ではなく要件として早期に確定させます。
各選択肢の整理
| 選択肢 | 確認する観点 | 評価 |
|---|---|---|
| ア | 情報共有のタイミング | 運用テスト後では遅く、設計や移行の手戻りが起こりやすいです。 |
| イ | 運用テストの進め方 | 運用部門主体は重要ですが、開発部門の支援なしだと仕様理解不足で見落としが起きやすいです。 |
| ウ | 運用要件の取り込み | 運用部門が要件抽出に参加し、設計に反映できるため適切です。 |
| エ | 運用マニュアルの作り方 | 開発部門だけで作ると実運用の体制や手順に合わない可能性があります。 |
結論
運用要件を要件抽出の段階で取り込める「ウ」が適切です。
選択肢ごとの解説
- ア：不正解
運用テストの完了後に仕様や運用方法を説明すると、運用部門は十分に理解しないまま運用テストを実施することになりやすいです。運用テストの前に、仕様や運用方法の共有が必要です。よって誤りです。
- イ：不正解
運用テストは運用部門が主体となって実施することが重要です。一方で、仕様の意図、制約、既知の問題、想定負荷などは開発部門の知見が必要になることがあります。開発部門の支援を受けない場合、確認観点の漏れや誤解による評価が起きるリスクがあります。よって誤りです。
- ウ：正解
運用部門が運用に関わる要件の抽出に参加すると、監視、ログ、バックアップ、権限、障害時対応などの条件を要件として早期に確定できます。これにより、設計段階から運用可能な形にでき、移行計画も立てやすくなるため適切です。よって正解です。
- エ：不正解
運用マニュアルを開発部門が作成して引き渡すだけだと、運用体制や既存手順に合わない内容になりやすいです。運用部門が要件抽出や手順作成、レビューに関与して、実運用に合う内容にすることが重要です。よって誤りです。
まとめ
開発部門と運用部門が分かれている場合は、運用開始後に必要になる作業や制約を、要件の段階から設計に反映させることが重要です。運用部門が運用に関わる要件の抽出に参加しておくと、運用できない設計や移行計画による手戻りを減らし、設計と移行を円滑かつ効果的に進められます。
運用テストの完了後に仕様や運用方法を説明すると、運用部門は十分に理解しないまま運用テストを実施することになりやすいです。運用テストの前に、仕様や運用方法の共有が必要です。よって誤りです。
運用テストは運用部門が主体となって実施することが重要です。一方で、仕様の意図、制約、既知の問題、想定負荷などは開発部門の知見が必要になることがあります。開発部門の支援を受けない場合、確認観点の漏れや誤解による評価が起きるリスクがあります。よって誤りです。
運用部門が運用に関わる要件の抽出に参加すると、監視、ログ、バックアップ、権限、障害時対応などの条件を要件として早期に確定できます。これにより、設計段階から運用可能な形にでき、移行計画も立てやすくなるため適切です。よって正解です。
運用マニュアルを開発部門が作成して引き渡すだけだと、運用体制や既存手順に合わない内容になりやすいです。運用部門が要件抽出や手順作成、レビューに関与して、実運用に合う内容にすることが重要です。よって誤りです。