開発部門と運用部門の連携は設計と移行のどこから始めるか
基本情報技術者試験 令和6年度 問14 ／ サービスマネジメント › サービスの設計・移行
過去問にチャレンジ
システムの開発部門と運用部門が別々に組織化されているとき，システム開発を伴う新規サービスの設計及び移行を円滑かつ効果的に進めるための方法のうち，適切なものはどれか。
- ア
運用テストの完了後に，開発部門がシステム仕様と運用方法を運用部門に説明する。
- イ
運用テストは，開発部門の支援を受けずに，運用部門だけで実施する。
- ウ
運用部門からもシステムの運用に関わる要件の抽出に積極的に参加する。
- エ
開発部門は運用テストを実施して，運用マニュアルを作成し，運用部門に引き渡す。
会話形式の解説
講師今回は、開発部門と運用部門が別々の組織になっているとき、新しいサービスの設計と移行をどう進めるかという問題です。見るところは二つです。運用部門がいつから関わるかと、運用テストを誰が主体になって行うかです。
受験者開発したのは開発部門なので、運用テストも開発部門がやって、マニュアルを付けて引き渡すのが自然だと思っていました。
講師そう考える人は多いです。ただ、運用テストは、実際にシステムを運用する部門が主体になって行います。本番と同じ形で運用できるかを確かめるテストだからです。開発部門は支援する立場です。
受験者そうすると、開発部門が運用テストをしてマニュアルを作り、引き渡すという選択肢は、主体が逆なので誤りですね。
講師そのとおりです。それに、開発部門だけで作ったマニュアルは、実際の運用手順や現場の制約に合わないおそれがあります。マニュアルは両方の部門の視点を入れて、協力して作るのが望ましいです。
受験者では、運用部門だけで運用テストをするという選択肢は正しいのでしょうか。主体は運用部門なので合っているように見えます。
講師主体が運用部門という点は正しいです。問題は「開発部門の支援を受けずに」という部分です。支援がないと、開発部門が持っている仕様や障害原因についての知識を活用できません。支援を受けながら進めるほうが効果的です。
受験者「だけで」が引っかかるのですね。運用テストが終わってから開発部門が仕様と運用方法を説明するという選択肢はどうですか。
講師説明するのが遅すぎます。運用テストが終わった段階では、運用上の課題に気付いても設計に反映しにくく、手戻りが起きやすくなります。
受験者ということは、運用部門も運用に関わる要件の抽出に積極的に参加するという選択肢が正解ですね。要件を出す段階から加わるので、時期がいちばん早いです。
講師はい、それが正解です。監視、障害対応、バックアップといった運用要件は、運用部門がいちばんよく分かっています。早い段階で設計に反映できれば、引継ぎ後の手戻りや運用上の不備が減り、切替時のリスクも下がります。
受験者整理すると、運用部門は要件抽出の段階から参加し、運用テストは運用部門が主体で開発部門が支援する、ということですね。
講師そのとおりです。この問題では、「運用部門だけで実施する」「完了後に説明する」のように一方の部門だけで進める表現や、関わる時期が遅い表現が、誤りを見分ける手がかりになりました。役割の分担と協力、それに早い段階からの参加という二つの観点で選択肢を確かめてください。
まとめ
開発部門と運用部門が別組織のときは、運用部門が運用要件の抽出に積極的に参加する方法が適切です。監視、障害対応、バックアップなどの運用要件を早い段階で設計に反映できるので、引継ぎ後の手戻りや切替時のリスクが減ります。運用テストは運用部門が主体となって行い、開発部門がそれを支援します。運用テストの完了後に説明する方法や、一方の部門だけでテストやマニュアル作成を進める方法は適切ではありません。
解答・解説
正解はウです
この問題のテーマ
開発部門と運用部門が別々の組織になっているときに、システム開発を伴う新規サービスの設計と移行を円滑に進めるには、運用部門がどの段階から、どのように関わるべきかを問う問題です。
解き方の考え方
着目点は二つあります。一つは「運用部門がいつから関わるか」、もう一つは「運用テストを誰が主体となって行い、誰が支援するか」です。運用上の要件は運用部門がよく知っているので、設計の前の要件抽出から加わるのが効果的です。運用テストは運用部門が主体となり、開発部門が支援する形が適切です。この二つの基準で選択肢を見ていくと、要件の抽出の段階から運用部門が加わるとしているウだけが当てはまります。
選択肢ごとの解説
- ×ア 運用テストの完了後に，開発部門がシステム仕様と運用方法を運用部門に説明する。アは、運用テストが終わってから開発部門が仕様と運用方法を説明するとしています。この時点では、運用上の課題に気付いても設計に反映しにくく、手戻りが起きやすくなります。また、運用部門は運用テストより前に運用方法を理解しておく必要があります。
- ×イ 運用テストは，開発部門の支援を受けずに，運用部門だけで実施する。イは、開発部門の支援を受けずに運用部門だけで運用テストを行うとしています。運用テストの主体が運用部門であることは正しいのですが、支援がないと、開発部門が持つ仕様や障害原因についての知識を活用できません。開発部門の支援を受けながら進めるほうが効果的です。
- ○ウ 運用部門からもシステムの運用に関わる要件の抽出に積極的に参加する。ウは、システムの運用に関わる要件の抽出に運用部門も積極的に参加するとしています。監視、障害対応、バックアップなどの運用要件を早い段階で設計に反映できるので、引継ぎ後の手戻りや運用上の不備が減り、切替時のリスクも下がります。
- ×エ 開発部門は運用テストを実施して，運用マニュアルを作成し，運用部門に引き渡す。エは、開発部門が運用テストを行い、運用マニュアルを作って引き渡すとしています。運用テストは運用部門が主体となって行うもので、開発部門は支援する立場です。また、開発部門だけで作ったマニュアルは、実際の運用手順や現場の制約に合わないおそれがあります。
補足
この種の問題では、「〜だけで実施する」「完了後に説明する」のように、一方の部門だけで進める選択肢や、関与の時期が遅い選択肢が誤りになりやすいです。役割の分担と協力、そして早い段階からの参画という二つの観点で選択肢を見分けると、似た問題にも対応できます。
POINT
- 運用部門は、設計の後ではなく要件抽出の段階から参加させるのが効果的です。
- 運用要件（監視、障害対応、バックアップ、保守など）を早く設計に反映するほど、引継ぎ後の手戻りが減ります。
- 運用テストは運用部門が主体となって行い、開発部門はそれを支援します。
- 運用マニュアルは、開発部門と運用部門の両方の視点を入れて協力して作るのが望ましいです。