基本情報 令和6年度 科目A 問14：テクノロジ系に関する問題

答えは c です。

システムは「作る人(開発)」と「動かす人(運用)」が別の部署になっていることがあります。作ったあとに丸投げすると「これ運用しづらい!」となるので、運用する人にも最初から相談して、運用しやすい条件を一緒に決めようというのが正解。

例えば、引越しの家具を選ぶときに掃除する人の意見も聞いておくと、後で「これ掃除できない」と困らない感じ。

👉 覚え方：運用部門も最初から仲間に入れる。

ほかの選択肢：a・dは“あとから”運用部門に丸投げ→失敗パターン／b 開発の支援なしで運用テストは無理。

なぜこれが正解か

正解は c。新規サービスの設計段階から運用部門が要件抽出に関与することで、可用性・運用性・保守性(非機能要件)が初期から組み込まれ、移行・本番運用がスムーズになる。サービスマネジメント(ITIL/JIS Q 20000)のサービス設計フェーズで強調される基本原則。

各選択肢の解説

• a 運用テスト完了後に説明：手遅れ。運用観点が設計に反映されない。
• b 開発部門支援なしで運用テスト：開発知識なしでは異常時切り分け不能。共同実施が原則。
• d 開発部門が運用テスト実施→引渡し：運用部門の習熟機会を奪い、移行後の障害対応力が育たない。

覚え方・ひっかけ注意

「Shift-Left(早期着手)」と「DevOps(開発と運用の融合)」が現代の正解パターン。選択肢に“あとで”“別々に”が出てきたら不適切と判定。要件定義への運用部門参画は応用情報・SM試験でも頻出。

理論的背景

ITサービスマネジメント国際規格ISO/IEC 20000(国内対応JIS Q 20000)及びITIL 4のサービスバリューシステムでは、サービス設計時に運用要件(SLA・OLA・キャパシティ・可用性・継続性・情報セキュリティ)を組み込むことが必須。これを怠ると本番移行時にService Acceptance Criteria(SAC)を満たせず、リリースゲートで差し戻し→工期遅延→運用部門の負荷急増という連鎖が起きる。SDLCのV字モデルでも左側(要件/設計)と右側(運用テスト/受入テスト)は対称で、設計時の運用観点取り込みが品質の鍵。

実務での使われ方

大企業では「サービスデザインパッケージ(SDP)」を成果物化し、開発・運用・セキュリティ・ビジネスの合同レビューを義務化。DevOpsムーブメントではSRE(Site Reliability Engineering)が運用要件をエラーバジェット・SLI/SLO/SLAとして数値化し、開発と運用の責任境界を明確化。CI/CDパイプラインのリリース判定にも運用部門が定めたObservability(可観測性)指標が組み込まれる。

試験での位置づけ

基本情報ではSM(サービスマネジメント)領域・ITサービス開発と移行の頻出論点。応用情報・SM試験ではChange Enablement・Release Management・Service Validation and Testing(ITIL用語)の役割分担、変更諮問委員会(CAB)の構成、移行戦略(ビッグバン/段階/並行)の選定基準まで深堀り。近年はDevOps/SRE/プラットフォームエンジニアリングとの統合視点で出題される傾向。

選択肢の発展補足

a/dのアンチパターンは“スループット型サイロ組織”の典型で、コンウェイの法則どおりに組織構造がシステム構造に反映され、運用しづらいモノリスを生む。逆コンウェイ戦略(Team Topologies)で「Stream-aligned team + Platform team」を組むのが現代的解。bは責任分界点を厳格化しすぎた失敗例で、運用部門が開発知識を持たぬまま障害切り分けが滞り、MTTR悪化を招く。