最終更新日：2026年9月16日

fe fe-management service-management system-development

まず結論

システム開発では、運用部門を要件定義や設計の早い段階から参加させることが重要です。

基本情報技術者試験では、次のように考えると判断しやすくなります。

開発が終わってから運用へ説明する
→ 遅い

運用部門だけで運用テストする
→ 分断が残る

要件定義から運用部門も参加する
→ 適切

ポイントは、運用は最後に引き継ぐものではなく、最初から設計に反映するものと考えることです。

直感的な説明

例えば、新しい業務システムを作るとします。

開発部門は、利用者が使う機能を中心に考えます。

一方、運用部門は、実際にサービスを継続して動かすために次のような点を考えます。

  • 障害をどう検知するか
  • バックアップをどう取るか
  • 夜間や休日に障害が起きたらどうするか
  • 誰にどの権限を与えるか
  • ログをどう保存するか
  • 問合せや変更依頼にどう対応するか

これらを開発の最後になって考えると、設計変更や作り直しが必要になることがあります。

そのため、

要件定義
↓
設計
↓
テスト
↓
移行

の途中からではなく、できるだけ早い段階から運用部門が参加することが重要です。

定義・仕組み

開発部門と運用部門の連携とは、システムの設計・開発・テスト・移行・運用を別々に考えず、実際の運用を見据えて協力することです。

要件定義で運用部門が参加する

要件定義では、利用者の業務要件だけでなく、運用に必要な要件も確認します。

例えば、次のような内容です。

運用要件 例
監視 障害をどのように検知するか
バックアップ 何を、どの頻度で保存するか
復旧 障害時にどの状態まで戻すか
権限管理 誰がどの操作をできるか
ログ 何を記録し、どのくらい保存するか
保守 メンテナンスをいつ行うか

運用部門が早い段階から参加すると、実際の運用で必要な機能や制約を開発側へ伝えられます。

設計・開発で運用しやすさを考える

システムは「動けばよい」わけではありません。

運用中に問題を発見し、復旧し、変更し続ける必要があります。

そのため、設計時点で次のような点を考えます。

障害を見つけられるか
↓
原因を調べられるか
↓
復旧できるか
↓
運用手順に落とし込めるか

運用テストは運用部門が主体でも、開発部門が支援する

運用テストでは、実際の運用手順や障害対応が機能するかを確認します。

運用部門が主体となる場合でも、開発部門の知識や支援が必要です。

運用部門だけで実施
→ システム内部の理解が不足する可能性

開発部門が支援
→ 問題の切り分けや修正がしやすい

移行直前に初めて説明するのは遅い

運用部門がシステムの仕様や運用方法を理解するのは、運用テストが終わった後では遅すぎます。

テストに参加するためにも、事前に仕様や運用方法を理解しておく必要があります。

科目Aでどう出る？

科目Aでは、開発部門と運用部門の役割を分断した選択肢と、早期から連携する選択肢が並びます。

問題文の表現 判断
運用テスト終了後に初めて説明する 不適切
運用部門だけで運用テストする 不適切
運用部門も要件抽出に参加する 適切
開発部門だけで運用テスト・マニュアル作成を行う 不適切

判断するときは、次の一文を思い出します。

運用で必要になることは、開発の早い段階から設計に入れる。

「誰がやるか」より「一緒に考えるか」を見る

この種の問題では、どちらの部門が担当者かを細かく暗記するより、開発と運用を分断していないかを見る方が判断しやすいです。

開発だけで決める
→ 要注意

運用だけに任せる
→ 要注意

両部門が早くから協力する
→ 適切な方向

どんな場面で使う？

この考え方は、新規システムの開発だけでなく、既存システムの更改やクラウド移行でも重要です。

例えば、クラウドへ移行する場合、開発側だけで設計すると、稼働後になって次のような問題が見つかることがあります。

  • 監視方法が決まっていない
  • バックアップから復旧できない
  • ログの保存期間が不足している
  • 障害時の連絡先が決まっていない
  • メンテナンス手順がない

こうした問題は、運用部門が早い段階から参加することで見つけやすくなります。

よくある誤解・混同

運用部門は完成後に引き継げばよい

違います。

運用上必要な要件を後から追加すると、大きな設計変更が必要になることがあります。

要件定義から参加すると考えます。

運用テストは運用部門だけで行う

運用部門が主体でも、開発部門の支援が不要という意味ではありません。

障害の原因調査やシステム仕様の確認には、開発部門の協力が役立ちます。

運用マニュアルは開発部門だけで作ればよい

開発側だけでは、実際の業務運用に合わない手順になる可能性があります。

開発側のシステム知識と、運用側の実務知識の両方が必要です。

DevOpsと完全に同じ意味

今回の考え方はDevOpsと方向性が近いですが、FEではまず、開発と運用を分断せず、早い段階から連携すると理解できれば十分です。

用語だけで判断するのではなく、問題文に書かれた役割分担を見ることが大切です。

まとめ（試験直前用）

  • 運用部門は要件定義など早い段階から参加する
  • 運用要件は、監視・バックアップ・復旧・権限・ログなど
  • 運用テストは運用部門が主体でも、開発部門が支援する
  • 運用テスト後に初めて説明するのは遅い
  • 開発部門だけ、運用部門だけで完結させる選択肢は疑う
  • 「早期から開発と運用が連携」なら適切な方向

© 2024-2026 stemtazoo. All rights reserved.