最終更新日：2026年8月15日
fe fe-management system-development service-management
まず結論
システムを開発から運用へ円滑に移すには、運用部門が開発の早い段階から参加し、実際に運用する立場の要件や注意点を開発側へ伝えることが重要です。
基本情報技術者試験では、次のように切り分けると判断しやすくなります。
開発が終わってから運用部門へ説明
→ 遅い
運用部門だけで運用テスト
→ 開発側との連携が不足
開発部門が運用テストの主体
→ 役割が逆
開発段階から運用部門も参加
→ 適切
覚えるポイントは、運用部門は「完成品を最後に受け取る人」ではなく、「運用できるシステムにするために開発段階から関わる人」ということです。
直感的な説明
新しい設備を設計する場面を考えてみます。
設計者だけで設備を完成させ、据付け後に初めて保全担当者へ渡したとします。
すると、次のような問題が起こるかもしれません。
- 点検場所に手が届かない
- 日常点検の手順が複雑
- 異常時の復旧方法が分からない
- 保守に必要な情報が表示されない
完成してから直すより、設計段階で保全担当者の意見を聞いた方が効率的です。
システム開発でも同じです。
要件定義・設計
↓
運用部門も参加
↓
実際の運用条件を反映
↓
運用テスト
↓
本番移行
運用開始後の姿を早くから考えることが、円滑な移行につながります。
定義・仕組み
システム開発では、開発部門と運用部門で役割が異なります。
| 部門 | 主な役割 |
|---|---|
| 開発部門 | 要件をシステムとして設計・実装する |
| 運用部門 | 本番環境で安定して使い続けられるよう運用する |
役割は異なりますが、完全に分離して進めるわけではありません。
運用部門が開発段階から参加すると、例えば次の点を早期に確認できます。
- 監視や障害対応をどのように行うか
- バックアップや復旧をどうするか
- 定期処理やバッチ処理をどう運用するか
- 利用者からの問い合わせにどう対応するか
- 本番移行時にどのような作業が必要か
- 運用マニュアルに何を記載するか
つまり、機能が正しく動くだけでなく、実際に運用できることまで考えて開発するのがポイントです。
運用テストとの関係
運用テストでは、本番稼働前に実際の業務や運用の流れで問題なく使えるかを確認します。
運用部門が中心となって確認しますが、開発部門の支援が不要という意味ではありません。
運用部門
→ 実際に運用できるか確認する主体
開発部門
→ システム仕様や技術面から支援する
詳しくは、運用テストとは？ で確認できます。
本番移行との関係
運用テストが終われば、それで移行準備が完了するわけではありません。
本番移行では、データ移行、切替え、切り戻し、利用者への周知なども必要です。
そのため、開発部門と運用部門が共通認識を持っておくことが重要です。
移行計画そのものについては、システム移行計画とは？ で整理しています。
公式の出題範囲やシラバスは、IPA：基本情報技術者試験 から確認できます。
科目Aでどう出る？
科目Aでは、開発部門と運用部門の役割を説明した選択肢から、適切な進め方を選ぶ問題があります。
選択肢を切る手順
まず、文章の中でいつ運用部門が関わっているかを見ます。
開発完了後に初めて関与
→ 遅い可能性が高い
開発段階から関与
→ 運用性を早期に反映できる
次に、運用テストの主体と支援者を確認します。
運用部門が主体
＋
必要に応じて開発部門が支援
→ 自然
一方、次の表現には注意します。
運用部門だけで行う
開発部門の支援は不要
開発部門が運用テストを実施して引き渡す
部門を完全に切り離す表現は、円滑な移行という目的と合わないことが多いです。
「運用マニュアルを誰が作るか」だけで判断しない
運用マニュアルは運用に必要ですが、重要なのは単純に「どちらか一方が作る」と覚えることではありません。
開発側はシステム仕様を知り、運用側は実際の運用方法を知っています。
そのため、内容に応じて両者が情報を出し合う必要があります。
試験では、開発と運用を不必要に分断していないかを見ると判断しやすくなります。
どんな場面で使う？
この考え方は、新しいシステムを本番稼働させるまでのさまざまな場面で使われます。
例えば、次のような場面です。
- 新しい業務システムの導入
- 基幹システムの刷新
- サーバやクラウド環境の移行
- 新しい監視・バックアップ方式の導入
- 運用手順や障害対応手順の作成
特に、開発と運用が別部門の場合は、情報が部門間で途切れないようにすることが重要です。
開発側が知っていること
→ 仕様・制約・構成・技術的注意点
運用側が知っていること
→ 実際の運用手順・監視・障害対応・利用者対応
両方の視点を合わせることで、本番稼働後のトラブルを減らしやすくなります。
よくある誤解・混同
誤解1：運用部門は開発完了後に説明を受ければよい
運用開始直前になって初めて説明すると、運用上必要な機能や手順の不足が見つかっても修正しにくくなります。
完成後に初参加
→ 手戻りが大きくなりやすい
開発段階から参加
→ 早く問題を見つけやすい
誤解2：運用テストは運用部門だけで行う方がよい
運用部門が主体であっても、開発部門の支援を禁止する理由はありません。
仕様や技術的な問題が見つかった場合、開発側との連携が必要です。
誤解3：開発部門が運用テストをして、その結果を運用部門へ渡す
開発部門はシステムを作る側です。
一方、運用テストでは、実際に運用できるかという運用側の視点が重要です。
開発部門だけで確認
→ 開発側の視点に偏りやすい
運用部門が主体となって確認
→ 実運用の観点を反映しやすい
誤解4：運用性は開発が終わってから考える
運用性は後付けすると手戻りが大きくなることがあります。
監視、バックアップ、障害復旧、定期処理などは、設計段階から考えておく方が自然です。
まとめ（試験直前用）
- 運用部門は、開発完了後に初めて関わるのではなく、開発段階から参加する
- 開発段階から参加することで、実際の運用に必要な条件を早期に反映できる
- 運用テストは 運用部門が主体、開発部門は必要に応じて支援する
- 「開発と運用を完全に分離する」選択肢には注意する
- 迷ったら、本番運用で困らないために早くから連携しているかで判断する