基本情報技術者 2024年 科目A 問14

運用部門参画【午前解説】

正解の理由

解法ステップ

1. 問題の目的を明確にする：開発部門と運用部門が別組織のとき、移行を「円滑かつ効果的に」する方策を選ぶ。
2. キー要素を洗い出す：早期の情報共有、責任分担、運用要件の反映、ナレッジ移転。
3. 各選択肢を照らし合わせる：後出し説明や一方的な引き渡しはリスクが高い。運用のみ・開発のみで完結させる方法は現実の運用課題を拾えない。
4. 最も妥当な手法を選ぶ：運用部門が要件抽出に積極参加することが、設計期から運用性を担保し移行を容易にするため最適。

選択肢別の誤答解説

• ア: 開発が運用テスト完了後に説明する
  • 問題点：運用テストの結果からしか運用上の課題を把握できず、設計変更や運用手順の追加が遅れる。運用側の要望が反映されないままテストが進む可能性があるため手戻りが発生しやすい。
• イ: 運用部門だけで運用テストを実施する
  • 問題点：運用テストで検出された不具合や環境設定の問題に対して開発の支援がないと対処が遅れる。加えて、テスト環境・テスト項目の整備を開発と協力して行わないと網羅性が低くなる。
• ウ: 運用部門からも要件抽出に積極参加する（正解）
  • 主な利点：運用制約を初期設計に反映できる、運用性・監視設計が向上、引継ぎ・教育が円滑、切替リスク低減。
• エ: 開発部門が運用テストとマニュアル作成を行い引き渡す
  • 問題点：開発側だけで作成した運用マニュアルやテストは現場運用者の実務にそぐわないことがあり、運用現場での受け入れや実行性が低下する。運用の主体性が確保できない。

よくある誤解

1. 「開発が完璧なマニュアルを作れば運用は不要」
   • 実務上、マニュアルだけでは運用中に発生する細かな現場判断や運用慣習をカバーできません。現場の参加が不可欠です。
2. 「運用はテスト段階だけ参加すれば十分」
   • 運用要件は設計段階で組み込むほど効果的です。テスト段階だけでは手戻りや設計変更が発生しやすくなります。
3. 「運用参加は工数の無駄」
   • 初期フェーズでの投資は、運用開始後の障害対応や作業効率低下といった高コストな問題を未然に防げます。

補足コラム

• RACIなどで責任範囲を明確化する（誰がResponsible/Accountableか）
• 要件定義・設計レビューに運用代表者を必須参加にする
• 「運用受入試験（Operational Acceptance Test, OAT）」を定義し、運用性評価の基準を設ける
• 運用ドキュメントは運用者主導で作成し、開発は技術的な補助を行う（共同作業）
• 移行時にパイロット運用や限定リリースで実運用検証を行う
  チェックリスト例（移行準備）：
• 監視・アラート仕様の確定、しきい値と通知先の整備
• バックアップ／リカバリ手順、実行担当者の確定
• 運用マニュアル・手順書の現場確認と承認
• 障害エスカレーション体制の整備と演習

FAQ