要件定義・設計構築は、本当に運用より上の仕事なのか

運用保守を「通過点」と呼ぶ前に、考えておきたいこと

本番稼働から数週間後、運用チームに問い合わせが入ります。

「昨日から、処理が終わる時間が遅くなっています。業務への影響はありますか」

監視画面には、いつもより長く動いているジョブが表示されています。手順書には、ジョブ遅延時に確認する項目が書かれています。対象のジョブ名、実行時刻、ログの確認場所、連絡先。

ただ、その先が曖昧です。

どこまで待ってよいのか。再実行してよいのか。関連する処理に影響はないのか。利用部門は、何時までに何を終えなければならないのか。顧客へ今すぐ連絡すべきなのか。誰の判断を仰ぐべきなのか。

担当者は過去の障害記録やメールを確認し、必要に応じて詳しい人や顧客側の担当者へ問い合わせながら状況を整理します。

その場では対応できたとしても、次に同じことが起きたとき、同じように判断できるとは限りません。

新しいシステムやクラウド環境が本番で使われ始めれば、設計時には想定し切れなかったことが起きます。問題は、想定外のことが起きること自体ではありません。

想定外のことが起きた後、誰がどこまで判断し、何を残し、次に起きにくくするために何を変えるのか。その仕事が運用チームだけに集まり続けることです。

面接で、「将来は要件定義や設計構築をやりたいです」と聞くことがあります。

その目標を否定したいわけではありません。

顧客の要望を整理し、技術やサービスを選び、設計し、構築し、移行を進める仕事には専門性があります。より広い範囲に関わりたいと考えることも自然です。

ただ、その言葉の中に、「運用保守は通過点で、設計構築の方が上」という前提が混ざっていないかは、一度考えてみる必要があります。

運用保守は、設計された環境を言われたとおりに回すだけの仕事ではありません。

本番で起きる異常を見つける。原因を切り分ける。利用者への影響を考える。関係者へ状況を伝える。暫定対応で影響を抑え、再発を防ぐための課題を残す。

その仕事がなければ、どれだけきれいな設計書も、利用者の業務を支え続けることはできません。

要件定義や設計構築は、本当に運用より上の仕事なのでしょうか。

少なくとも、工程名だけで上下を決めることはできません。

「上流工程へ行きたい」が、いつの間にか正解になっている

ITエンジニアのキャリアは、階段のように説明されることがあります。

監視やヘルプデスクからキャリアをスタートし、運用保守を経験した後に構築へ進み、さらに設計を担いながら、最終的には要件定義やプロジェクトマネジメントへと役割を広げていく。

こうしたキャリアの広がり方は、実際にあります。

担当範囲を広げ、顧客との対話を増やし、技術的な判断だけでなく、予算、期限、業務要件、関係者の事情まで考えるようになる。そこに挑戦したい人がいるのは当然です。

ただ、この説明が繰り返されるうちに、仕事そのものまで上下に並べられやすくなります。

要件定義は上流、設計構築は中流、運用保守は下流といった形で工程が区分されることがあります。

上流に近いほど価値が高く、運用保守は経験を積んだら早く抜けるべき仕事だと捉えられることがあります。

その見方はキャリアを説明するには便利ですが、本番環境で起きていることを十分には説明していません。

本番では、設計書に書かれていないことが起きます。

月末だけデータ量が増える。外部連携先の都合で処理時間が変わる。利用部門の運用が変わり、今まで問題なかった処理が止まり始める。クラウドサービスの仕様変更により、以前と同じ手順では対応できなくなる。

障害は、いつも一つの原因で起きるわけではありません。

アプリケーション、データベース、ネットワーク、認証、外部連携、データ量、利用者の操作、直前の変更。複数の要因が重なって、初めて現象として表れることがあります。

設計した時点で、すべてを見通すことはできません。

だから、本番で起きたことを見ながら、監視を変える。手順を見直す。連絡の流れを整える。責任分担を確認する。必要なら設計や運用ルールへ戻す。

この仕事を担う人がいなければ、システムは使われ続けません。

要件定義や設計構築が担うのは、将来の状態をつくることです。

運用保守が担うのは、その状態が現場で本当に回るのかを確かめ、回らない部分を日々直していくことです。

同じ仕事ではありません。

ただし、どちらか片方だけで成り立つ仕事でもありません。

運用側が疲弊するのは、障害が多いからだけではない

クラウド移行やシステム刷新では、本番稼働日が大きな節目になります。

環境を構築し、ネットワークを接続し、認証や権限を設定したうえでアプリケーションを動かします。その後、性能を確認し、テストを完了させてから本番環境へ切り替えます。

移行が完了すると、プロジェクトとしては一つの山を越えます。

運用側から見ると、そこで初めて日常が始まります。

監視アラートを誰が確認するのか、障害が発生した際に誰が初動対応を担い、どの段階で上位担当や顧客側へ判断を引き上げるのかといった役割分担は、あらかじめ整理されている必要があります。また、ログがどこに保管されており、調査に必要な人が適切な権限を持っているかどうかも重要です。さらに、バックアップから復旧する場合にはどの時点まで戻すのか、復旧後に誰がどのデータを確認するのかといった手順も明確でなければなりません。変更作業が失敗した場合についても、誰が切り戻しを判断し、利用部門への連絡を誰が行うのかを決めておく必要があります。しかし、設計書に監視やバックアップの記載があったとしても、こうした具体的な運用上の判断や役割分担まで整理されているとは限りません。

運用手順書もありますが、通常時の手順しか整備されていない場合があります。

定期ジョブが正常に終了している場合や、アラートが発生していない場合、申請内容に不備がなく、変更作業も計画どおりに進んでいる場合には、通常どおり手順書に沿って対応することができます。

現場が苦しくなるのは、定型から外れたときです。

ジョブは遅れているものの、それがどの業務に影響するのかははっきりしません。ログにはエラーが出ていますが、それが原因なのか結果なのか判断がつかないこともあります。アラートが発生していても、すぐに対応が必要なのか、それとも翌朝の確認で問題ないのか迷う場面もあります。さらに、権限申請の内容が不十分で付与してよいか判断に悩んだり、変更手順の途中で想定していなかった画面や状態に遭遇したりすることもあります。こうした状況に直面すると、担当者は過去の情報を探しながら対応を進めることになります。

以前の障害対応を探し、詳しい人に聞きながら状況を整理し、必要に応じて顧客側へ確認したり、技術担当へ調査を依頼したりします。

その場を止めないため、暫定的な対応を選ぶこともあります。

暫定対応そのものが悪いわけではありません。

利用者への影響を抑えるために、まず復旧や回避を優先しなければならない場面はあります。

問題は、暫定対応が終わった後です。

なぜその対応を選んだのか、どのリスクが残っているのか、そして次に同じことが起きたときに誰が判断できるのかといった点が整理されないまま終わると、対応は個人の経験にとどまってしまいます。また、恒久対応が必要な場合でも、その必要性を誰が整理し、優先順位を誰が決めるのかが曖昧なままでは、同じ問題が繰り返される可能性が高くなります。

次に似た事象が起きたとき、その人がいれば進む。いなければ、また調べ直す。

手順書には、対応方法が一文だけ追記されるかもしれません。

ただ、使う条件、確認の順番、使ってはいけないケース、周辺への影響まで整理されないまま追記が続くと、手順書は少しずつ読みにくくなります。

新しい担当者は、どの手順が今も有効なのか、どの手順が特定の条件でしか使えないのか、判断できなくなります。

確認漏れが起き、その結果として障害につながることがあります。障害が発生すると対応に追われ、まずは原因の確認が優先されます。その後、問題管理に上げて恒久対応を検討する流れになりますが、日々の監視や問い合わせ対応、定常作業、障害報告といった業務が優先されるため、恒久対応は後回しになりがちです。この悪循環は、運用担当者が怠けているから起きるのではありません。

本番稼働後に、設計や移行の段階で決め切れなかったことを、日々の対応の中で決め続ける状態になっているからです。

運用チームは、システムを運用しているだけではありません。

本番に出てから見つかった未決事項を、一つずつ拾い続けています。

運用設計は、手順書を書くことではない

運用設計というと、手順書やフローを整える仕事だと思われがちです。

もちろん、それ自体は必要です。

担当者が変わっても同じ対応ができるようにし、確認漏れを防ぎながら引き継ぎにも活用できるようにすること、さらに対応の記録を残すことが目的です。

ただ、手順書が整備されているだけで運用が円滑に回るとは限りません。実際の現場では、手順書に書き切れない判断が求められる場面が多くあります。

たとえば、同じエラーであっても月末と通常日では業務への影響が異なるため、対応の優先度や方法を変える必要があるかもしれません。また、アラートが発生した際に、それが利用部門の業務にどの程度影響するのかを見極めることも重要です。

さらに、誰に連絡すれば判断が前に進むのか、どこまでを運用担当が判断し、どこからを顧客やアプリケーション担当に委ねるべきなのかといった点も、状況に応じて判断しなければなりません。過去に似たような事象が発生した際に何が問題となったのかを踏まえることも、適切な対応には欠かせません。

このような判断は、単に手順の数を増やすだけでは補えないものです。運用保守の専門性は、手順を覚えることではなく、状況に応じて適切に判断できる力にあります。

手順が何を守ろうとしているのかを理解し、想定外のことが起きたときに、何を確認し、誰へ相談し、どこまで対応するかを考えることです。

監視も同じです。

CPU使用率、メモリ使用率、ディスク使用率、エラー件数、応答時間、ジョブの実行時間。監視できる項目は多くあります。

ただ、監視項目を増やせば、運用品質が上がるわけではありません。

夜間に何度も通知が来るが、ほとんどが様子見でよいものばかりなら、担当者は疲弊します。本当に対応すべき異常が起きたとき、その通知までいつものものとして扱われる危険もあります。

通知を受けた人が、その場で何も判断できないのであれば、そのアラートは監視の役に立っているとは言い切れません。

運用を知る人は、「何を監視できるか」ではなく、「通知を受けた人が何を確認し、次に誰へ何を伝えられるか」を見ます。

そこまで考えて初めて、監視は運用の道具になります。

障害対応は、技術と業務の間で判断する仕事である

障害が起きたときは原因調査が必要ですが、それだけで現場の仕事が終わるわけではありません。

利用者は復旧の見通しや、自分の業務をどう進めればよいのかを知りたいと考えています。一方で顧客側の担当者は、影響範囲がどこまで広がっているのか、他の部門へ連絡すべきかどうかを判断する必要があります。さらに技術担当者は、調査に必要なログや直前の変更有無、再現環境といった情報を求めます。運用担当者は、こうしたそれぞれの立場で必要とされる情報を整理しながら、対応を前に進めていきます。

「画面が遅い」という問い合わせがあったとします。

原因が必ずしもインフラにあるとは限りません。

アプリケーション処理、データベース負荷、ネットワーク、外部連携の遅延、特定のデータ量、利用者の操作など、いくつかの可能性があります。

ここで求められるのは、最初から正解を言い当てることではありません。まずは、いつから遅くなっているのか、影響を受けているのは全体なのか一部の利用者だけなのか、特定の機能に限られているのかといった状況を整理します。あわせて、同じ時間帯に別の異常が発生していないか、直前に変更がなかったかも確認しながら、どこから調べれば原因に近づけるかを考えていきます。

運用保守では、情報を集め、仮説を立て、必要な担当者へ渡します。

トラブルシューティングは、単なる調査ではありません。

情報が不足した状態から、次の判断ができる状態へ近づける仕事です。

この力は、インフラ、アプリケーション、クラウド、データベース、ネットワークのどれか一つだけを知っていれば身につくものではありません。

技術と業務、過去の変更、関係者の役割を行き来しながら育ちます。

運用保守は技術が現場でどう壊れ、どう復旧し、どこに改善の余地が残るかを知る仕事でもあります。

設計構築にテンプレートがあるからこそ、運用の視点が問われる

設計構築の仕事には、別の難しさがあります。

要件定義では、利用部門から出てくる曖昧な要望をそのまま受け取るのではなく、実現可能な形へ整理し直す必要がありますし、設計の段階では性能や可用性、セキュリティ、コスト、拡張性、保守性といった複数の観点を同時に考慮しながら構成を決めていくことが求められます。さらに構築では、複数の製品やサービスを組み合わせて環境を作り上げ、テストや移行計画を進めながら、期限と品質の両方を守る必要があります。

現在は、標準構成、リファレンスアーキテクチャ、IaC、自動化の仕組みがあります。

これらは品質をそろえ再現性を高め手作業のばらつきを減らすために有効ですが、テンプレートを適用して環境を作ることとその環境が現場で運用できることは別の問題です。

IaCで再現できるのは、主に環境の設定に限られます。障害が発生した際に誰が判断を下すのか、切り戻し後に誰が業務データを確認するのか、アラートを受けた担当者がどの情報を見れば影響範囲を把握できるのか、変更が失敗した場合に誰が顧客へ説明するのかといった点は、自動的に整備されるものではありません。

運用経験がある人が設計に関わると、問いが変わります。

「監視を入れるか」ではなく、「誰がその通知を受け、何を確認し、どこまで判断できる状態にするか」。

「バックアップを取るか」ではなく、「復旧にどれだけ時間がかかり、どの業務影響を許容し、復旧後に誰が確認するか」。

「自動化するか」ではなく、「失敗したときに誰がどの手順で戻し、どこまで人が確認するか」。

本番稼働後の運用負荷は、こうした設計時の問いによって変わります。

運用で苦労した人が、次に設計へ関わるときに「運用のことも考えないと」と言うのは、このような背景があるためです。

監視を入れることや手順書を整備すること、自動化を進めること自体は重要ですが、それだけで運用が成立するわけではありません。本番で発生する例外や、その例外に対して誰がどこまで対応するのかといった点まで含めて考えておかなければ、結果として運用側の負荷は後から増えていきます。

この感覚は、設計書を読んだだけでは身につきにくいものです。

夜間のアラート対応をした。影響範囲が分からないまま顧客へ連絡した。暫定対応を続けた結果、同じ問題が繰り返された。詳しい人に確認しなければ何も決められない状態を経験した。

そうした経験をした人ほど、設計書を見るときに構成図の外側を見ます。

運用を深める道も、専門職として成立する

ここで、もう一つ考えたいことがあります。

運用経験を積んだ人は、必ず設計構築へ行かなければならないのでしょうか。

私たちは、そうは思いません。
運用保守を深めること自体が、一つの専門性として成立します。

障害対応やインシデント管理を深めながら、監視設計やログ管理、性能分析といった領域を担うこともあります。また、変更管理や問題管理を通じてサービスレベルの維持を整えたり、クラウド運用の自動化や運用受入れを進めたりする役割も含まれます。さらに、バックアップや復旧、BCPやDRが実際に機能する状態をつくることや、業務部門、情報システム部門、アプリケーション担当、インフラ担当、外部ベンダーの間に立ち、障害時の情報と判断を整理することも求められます。どれも単純な定型作業ではありません。

技術理解に加えて、業務、運用ルール、責任分担、関係者との対話、緊急時の判断が必要です。

運用保守は設計構築の前段ではなく、本番環境を守り使い続けられる状態をつくる専門職です。

運用の現場で働く人の役割は、日常では見えにくいものです。

障害の兆候に気づく。

利用者が困っていることを、技術担当者が調べられる情報へ変える。

一時的な対応で影響を抑えながら、次に同じことが起きないための課題を残す。

こうした積み重ねがあるから、利用者は翌日も業務を続けられます。

私たちは、運用の現場で働く人に敬意を払いたいと考えています。

その人たちがいなければ、設計構築の成果物は本番で使われ続けません。

運用経験なら何でもキャリアになるわけではない

運用保守を専門職として語るなら、前提となる条件も整理しておく必要があります。

単に運用に携わっているだけでは、専門性が自然に積み上がるわけではありません。

監視画面を確認し、アラートが出た際には定型文で連絡を行い、問い合わせを受けた場合はすぐに上位担当へ引き継ぐ。障害が解決した後も原因や対応結果が共有されず、改善や手順見直しに関わる機会もない。

こうした状態が長く続くと、経験年数は増えても、判断できる範囲は広がりにくくなります。

運用を深めるには、定常作業を正確に行うことに加えて、障害の背景、対応結果、問題管理、変更、改善に触れる機会が必要です。

自分が対応したアラートの先で、実際に何が起きていたのかを知る。

エスカレーション後、上位担当者が何を確認し、どう判断したのかを学ぶ。

手順書にない事象が起きたとき、どのように対応が決まったのかを振り返る。

同じ問題を減らすために、監視、権限、ログ、手順、連絡の流れのどこを見直せるかを考える。

こうした経験があって初めて、運用は「対応した量」ではなく、「判断できる範囲」が増えるキャリアになります。

運用を続けるか、設計構築へ進むか。

その二択で考える前に、今の現場で何を学び、何を任され、どんな判断に触れられているかを見るべきです。

面接で「設計構築をやりたい」と言う前に

将来、要件定義や設計構築を目指すことは悪くありません。

ただ、面接で「上流工程に行きたい」と言う前に、少し具体的に考えてみてほしいと思います。

本番稼働後にこのシステムを誰が監視するのか、障害が発生した際には誰が最初に何を確認するのかといった点は、あらかじめ整理しておく必要があります。また、利用部門が困ったときに判断を進めるためにはどの情報が必要なのか、変更が失敗した場合にどこまで切り戻せるのか、さらに切り戻し後に誰が何を確認するのかといった運用面の前提も重要です。暫定対応が続いた場合に恒久対応を誰が判断するのか、日々の運用担当者がどのような作業を抱えるのかまで含めて考えられる人は、設計構築に向いています。

設計とは、構成図を描いたり、クラウドサービスを選定したりするだけではありません。

システムが使われ続ける前提をつくる仕事であり、運用を専門として深める選択もキャリアの停滞ではありません。

本番環境を維持し、障害時に状況を整理して判断し、改善につなげていく役割として、十分に専門性のある領域です。

ディーシステムでは、運用経験を「そのうち抜けるための仕事」とは考えていません。

顧客の現場で何が起きるかを知り、技術が役に立つ条件を学ぶ仕事だと考えています。

運用を知る人が、設計へ進む。

設計を知る人が、運用の負荷まで考える。

運用そのものを専門領域として深める人がいる。

こうした人がそれぞれの役割を持つことで、システムはリリース後も現場で使われ続けます。

おわりに

要件定義・設計構築は、本当に運用より上の仕事なのか。

工程名だけで、その答えを決めることはできません。

設計構築にも運用保守にも、それぞれ異なる難しさがあります。運用を知らずに設計すると本番後の負担が増えることがあり、逆に運用経験があっても原因や業務影響、改善に関われなければ次につながりにくくなります。

大切なのは、「上流へ進むか」「運用にとどまるか」という単純な選択ではありません。

自分は、どんな場面で判断できる人になりたいのか。

本番で何か起きたとき、誰のために、どこまで仕事を引き受けられる人になりたいのか。

その問いから、キャリアを考えることだと思います。

参考資料

AWS Well-Architected Framework
Operational Readiness and Change Management

Google Cloud Well-Architected Framework
Operational Excellence／Manage Incidents and Problems

Microsoft Cloud Adoption Framework
Cloud Operations

Google SRE
Incident Management Guide

さらに詳しく知りたい方へ

「運用経験は、本当にキャリアの遠回りなのか」
運用経験が次の役割につながる条件と、停滞しやすい現場の違いを紹介しています。

「L1監視からL2へ進むには」
監視業務の中で、次の判断を任される人になるための視点を紹介しています。