監視を回すだけでは終わらせない。クラウド移行後の運用を、人が育つ体制へ変えるまで｜支援実績
大規模な基幹システムをクラウドへ移行したあと、現場で本当に問われるのは、移行が完了したかどうかではありません。
監視は安定しているか。障害が起きたとき、誰がどこまで判断できるのか。ジョブや帳票の運用を、次の担当者へ引き継げる状態になっているか。運用コストを見直しながら、品質を落とさずに体制を変えられるか。
移行後の運用には、こうした課題が同時に現れます。
特に大規模システムでは、監視、障害対応、ジョブ管理、帳票運用、進捗管理、複数ベンダーとの連携が並行して動きます。ひとつの作業だけを見ていても、全体は回りません。担当者が変われば止まる業務、経験者しか判断できない例外、手順書には残っていない連絡の順番。表面上は安定して見える運用でも、実際には個人の経験や関係性に支えられていることがあります。
ディーシステムが今回取り組んできたのは、運用要員を増やすことではありません。
L1監視を安定して運営しながら、作業を標準化し、オフショア化を支援し、そこで得た経験をL2運用保守、JCLスケジューラ運用、帳票運用、PMO支援へつなげていくことです。
定型業務を減らす。
その先で、人の役割を広げる。
この二つを切り離さずに進めることが、クラウド移行後の運用を強くすると考えています。
クラウド移行後に増えるのは、作業ではなく「判断の場面」だった
クラウドへ移行すると、運用は自動化され、楽になると思われることがあります。実際、監視ツールやログ管理、ジョブの実行管理などは、以前より効率化できる部分もあります。
ただ、現場では別の難しさが出てきます。
アラートが出たとき、それが単なる一時的な事象なのか、業務影響につながる異常なのか。複数システムの連携が止まりかけている場合、どのチームへ、どの順番で連絡すべきか。再実行できる処理なのか、それともデータ不整合の確認が必要なのか。
こうした判断は、操作手順だけでは決まりません。
対象システムの構成、業務の締め時間、関連チームの役割、過去に起きた類似障害、利用部門への影響。いくつもの情報を重ねて、初めて優先順位を決められます。
大規模運用で怖いのは、障害そのものだけではありません。
判断が特定の人にしかできない状態です。
経験者がいれば解決できる。けれど、その人が休みの日や異動後に同じことが起きたら、誰が判断するのか。担当者が「以前も同じ対応をした」と言っても、その根拠が残っていなければ、次の人はまた一から調べることになります。
だから、監視業務を単なる定型作業として扱うだけでは足りません。
監視を通じて何を見て、どのように判断し、誰と連携したのか。その経験を、次の人が使える形へ変えていく必要があります。
L1監視は、キャリアの終点ではなく、運用を理解する入口になる
本プロジェクトでは、クラウド移行後の安定化フェーズにおいて、L1監視オペレーションを8名体制で運営してきました。
L1監視には、アラート監視、定型作業、依頼対応、一次切り分け、関係者への連携などが含まれます。外から見ると、決められた手順を守る仕事に見えるかもしれません。
もちろん、正確に作業を行うことは大前提です。
ただ、現場で経験を積む中で、社員が学ぶのは操作そのものだけではありません。どのアラートが緊急度の高いものなのか。どの処理が業務影響を持つのか。上位チームや関係部署へ連絡するとき、何を先に伝えれば判断しやすいのか。
こうした感覚は、教科書だけでは身につきません。
たとえば、同じジョブ異常でも、月次処理の時期なのか、翌朝までに完了すべきバッチなのか、周辺システムの処理とつながっているのかによって、対応の優先順位は変わります。L1で経験する日々の確認や連絡は、上位運用へ進むための前段階でもあります。
一方で、L1を長く続けているだけで、自然に次の役割へ進めるわけではありません。
ただ監視をして、決められた相手へ連絡して、作業を終える。その繰り返しでは、経験は増えても、判断の幅は広がりにくいからです。
現場で得た経験を、どのように振り返るか。何ができるようになり、次に何を身につけるべきか。そこまで見なければ、L1は「入り口」のままで終わってしまいます。
障害対応を経験で終わらせない。DSCが、次の判断をつくる
夜間帯に引き継いだのは、緊急性の高いジョブ異常への対応でした。
担当者は、引き継ぎを受けてすぐに操作へ入ったわけではありません。まず、L1としてどこまで対応が終わっているのかを確認し、関係チームへの連絡状況や、上位者からの回答待ちかどうかを整理しました。
その後、障害情報を管理台帳へ記入し、チケットを起票する。並行して、経験の浅いメンバーにも対応の流れを共有しました。緊急対応では、一人が作業を抱え込むと、復旧後に何が起きていたのかを周囲が説明できなくなります。作業を進めながら、他のメンバーも状況を追える状態にすることが、運用の安定化につながります。
今回の事象では、データセットを作り直しても異常が解消しませんでした。確認を重ねる中で、削除済みのはずの情報が残っており、それが再実行時の異常につながっていることが分かりました。上位運用チームの判断を受け、関係チームが必要な対応を行い、L1が監視を継続する。その後、再実行して正常終了を確認しました。
ここまでを見ると、障害対応は完了しています。
ただ、ディーシステムでは、復旧できたことだけで評価を終わらせません。
担当者は入社後、DSC（D-system Cycle）の中で、日報に対するフィードバックを受けながら成長してきました。今回の記録についても、対応の順番や原因の切り分けは以前より具体的に書けていました。一方で、誰に何を伝え、相手からどのような返答があり、何をもって完了と判断したのか。その部分は、まだ次の担当者が再現できるほどには残っていませんでした。
そこで次回の目標は、単に「適切にエスカレーションできた」と書くことではなくなります。
なぜその時点で連絡したのか。相手から何が返ってきたのか。どの確認結果をもって復旧と判断したのか。この三つを、一つの対応として残せるようにすることです。
DSC（D-systemCycle）は、日報を評価するだけの仕組みではありません。
現場で起きた対応を振り返り、本人がまだ言語化できていない判断を見つけ、次の実務で試す行動へ変える。その繰り返しによって、作業をこなす段階から、状況を整理し、根拠を持って報告できる段階へ進んでいきます。
L1監視からL2運用保守やジョブ管理へ進むために必要なのは、画面を見続ける力ではありません。
起きたことを整理し、関係者に伝え、次の人も使える形で残す力です。
オフショア化で減らしたかったのは、人ではなく国内に残る定型業務だった
運用コストの最適化を考えると、オフショア化は選択肢の一つになります。
ただ、業務をそのまま移管すれば、品質が保てるわけではありません。
手順書があっても、例外が起きたときの判断が書かれていない。エスカレーションの条件が曖昧で、連絡が遅れる。担当者によって記録の粒度が違い、次のシフトが状況をつかめない。こうした状態のまま移管すると、短期的に人件費を抑えられても、後から連携コストや障害対応の負荷が増えてしまいます。
今回の取り組みでも、監視業務のオフショア化を支援しました。
目的は、国内要員を単純に減らすことではありません。
定型的な監視・運用業務を整理し、手順、判断基準、エスカレーション条件、運用上の注意点を明確にする。そして、国内で経験を積んだ社員が、L2運用保守やジョブ管理、帳票運用、PMO支援といった領域へ進める余力をつくることでした。
ここで難しかったのは、作業手順を文章にすることそのものではありません。
経験者にとっては当たり前になっている確認や、連絡の順番、判断の背景を、他の人が使える形に置き換えることです。
「いつもと違う」と感じる場面にも、必ず何らかの根拠があります。通常より処理時間が長い。前工程の状態が異なる。影響を受けるジョブが多い。こうした感覚を、本人の勘のままにしておけば、移管先では再現できません。
標準化とは、作業を機械的に単純化することではありません。
現場で積み上がった判断を、他の人が使える状態へ変えることです。
L1からL2、JCL、帳票運用へ。異動先を決める前に、任せられる範囲を見極めた
L1監視を縮小する局面で、重要になるのは「次に誰をどこへ移すか」です。
空いている枠に人を入れるだけでは、本人にとっても、受け入れ先にとっても負荷が大きくなります。異動先で何を期待されているのか。現時点で何ができ、何を補えば独り立ちできるのか。そこを見極めずに異動すると、キャリアアップのはずが、単なる人員調整になってしまいます。
本プロジェクトでは、L1監視を経験した複数の社員を、インフラL2運用保守の領域へ配置転換しました。また、JCLスケジューラ運用支援にも2名を異動させています。
L2では、一次対応だけでなく、原因の切り分け、ログの確認、インフラ構成の理解、関係チームとの連携、恒久対応に向けた情報整理まで求められます。JCLスケジューラ運用でも、ジョブを実行するだけではなく、業務処理との関係や、停止した場合の影響を理解しなければなりません。
そのため、受け入れ先のプロパー人材や上位パートナーとも連携し、どの水準に達すれば独り立ちと判断できるのかを確認しながら進めました。
異動直後は、誰もが同じ速度で立ち上がるわけではありません。
新しい領域では、技術知識の不足だけでなく、報告の仕方、調整の進め方、確認の粒度にも差が出ます。以前なら「対応しました」で終わっていた報告に、影響範囲や確認結果、次に必要な判断を添えられるようになるまでには、時間がかかります。
それでも、L1で得た経験は無駄になりません。
対象システムの動きや日々の運用を見てきたこと。障害時に、どのチームが何を確認するのかを知っていること。緊急時に、情報を整理して引き継ぐ難しさを経験していること。
こうした積み重ねが、L2やJCL運用へ進んだときの土台になります。
上位運用やPMOでは、「正しく作業する」だけでは足りなくなる
運用の経験を積んだ社員が、次にL2やPMO領域へ進むとき、求められる力は変わります。
ある社員は、内部運用における権限制御の見直しを担当していました。
現場の実務を考えれば、権限を厳しくしすぎると作業が滞る。一方で、利便性を優先しすぎれば、統制やセキュリティのリスクが残る。権限構造で吸収すべきことと、運用プロセスで吸収すべきこと。その境界をどこに置くのかを考える中で、検討が何度も戻る場面がありました。
これは、本人の作業が遅いという話ではありません。
現場の実態と、あるべき運用の間にある矛盾をどう整理するか。その判断には、技術知識だけでなく、利用者の動き、チームの役割、業務上のリスク、将来の運用負荷まで見る視点が必要になります。
本人の週報にも、自分のタスクが運用組織全体の中で何を求められているのか、その対応がどのような効果やリスクにつながるのかを、まだ十分に捉え切れていないという振り返りがありました。
この感覚は、上位領域へ進む人材がぶつかる壁の一つです。
L1では、正しい手順で確実に対応することが求められます。L2では、原因を切り分け、関係者と連携しながら復旧へ進める力が必要になります。そしてPMOや運用設計の領域では、個別の対応を超えて、そもそもどのようなルールや体制なら同じ問題を繰り返さないかを考えなければなりません。
ここでは、早く結論を出すだけでも足りません。
拙速に進めれば、見落としが増える。慎重になりすぎれば、改善は進まない。求められるのは、必要なタイミングでたたき台を出し、レビューを通じて確認観点を増やし、優先順位を調整しながら精度を上げていくことです。
ディーシステムでは、監視業務を経験した社員を、そのまま別の現場へ送ることを目標にはしていません。
現場で起きていることを理解し、次には運用の設計やチーム運営まで考えられる人材へ進めていくことを目指しています。
顧客の方針が変わるとき、必要なのは増員ではなく体制の組み替えになる
大規模運用の現場では、顧客側の担当者やプロジェクトマネージャーの交代をきっかけに、求められる価値が変わることがあります。
これまで最優先だったのは、安定稼働を守ることだった。ところが、一定の安定が見え始めると、次には自動化、効率化、コスト最適化、運用品質の可視化といったテーマが前に出てきます。
こうした変化を、単なる窓口変更として受け取ると、支援する側は「増員の可能性があるか」「契約が更新されるか」だけを見てしまいます。
しかし、顧客がこれからどのような運用組織をつくろうとしているのかまで考えると、準備すべきことは変わります。
定型監視を担う要員だけでは足りません。標準化を進められる人材、障害の原因を整理できる人材、複数チームをまたいで進捗を管理できる人材、運用品質を数字や記録で説明できる人材が必要になります。
今回、L1監視からL2やJCL運用へ人材を移したのは、体制縮小への対処ではありませんでした。
定型業務の割合が変わっても、現場で積んだ経験を次の専門性へ変えられるようにするためです。
顧客にとっては、運用品質を保ちながら、コストや役割分担を見直せる体制になる。
社員にとっては、定型業務を続けるだけではなく、現場経験をもとに、より責任のある領域へ進める機会になる。
どちらか一方だけでは、長く続く運用体制にはなりません。
評価が変わるのは、任せられる範囲が広がったとき
人材を上位領域へ配置転換しても、異動した直後に評価が変わるわけではありません。
新しい役割に慣れるまでには、学習やフォローが必要です。対応範囲が広がれば、判断の責任も増えます。支援会社側にとっても、立ち上がりの期間は育成に時間を投じる時期になります。
それでも、現場で独り立ちし、任せられる範囲が広がれば、先方からの見え方は変わります。
今回も、上位領域で対応を続けてきた社員について、先方から「評価を上げたい」という意向をいただき、契約条件の見直しが進みました。
これは、単に人手が不足しているから起きたことではありません。
運用品質を保ち、より上位の領域で対応し、関係者から「この人に任せられる」と評価された結果です。
単価は、保有資格やスキルシートに書かれた技術名だけで決まるものではありません。
顧客の課題に対して、どこまで状況を理解し、どこまで自分で整理し、どの範囲まで責任を持てるか。その積み重ねが、評価や契約条件に反映されていきます。
だから、社員の成長を本人の努力だけに任せることはできません。
現場経験をどう振り返るのか。どの段階で次の役割を任せるのか。顧客や上位者からの評価を、どう本人の次の課題へ変えるのか。こうした仕組みがあって初めて、経験はキャリアにつながります。
一人の成長を、次の案件でも使える運用モデルへ変える
今回のプロジェクトで得られた経験を、一つの案件だけで終わらせるつもりはありません。
L1監視を安定して運営する。定型業務を標準化する。オフショア移管を支援する。国内要員をL2、JCL、帳票運用、PMOへ進める。さらに、そこで得た知識や判断の型を次の担当者へ引き継ぐ。
この流れを、別の運用案件でも使える形へ整理していくことが、次の課題です。
もちろん、すべてを同じ型にはできません。
システム構成も、顧客の組織も、運用ルールも案件ごとに違います。全員が同じ速度でL2やPMOへ進めるわけでもありません。本人の努力や挑戦がなければ、役割を広げることも難しいでしょう。
それでも、共通して設計できる部分はあります。
引継ぎを後回しにしないこと。手順だけでなく判断基準を残すこと。L1のシフトと次の配置を別々に考えないこと。異動後も、現場の評価を見ながら任せる範囲を広げること。日報や週報を通じて、現場で起きたことを次の学びへ変えることです。
運用を標準化することは、仕事を単純にして終わる話ではありません。
人が変わっても、運用品質が残る状態をつくることです。
そして、その中で社員が、監視からL2へ、L2から運用設計やPMOへ進める道をつくることです。
クラウド移行後の安定化は、システムを止めないためだけの取り組みではありません。
顧客の運用を強くし、そこで働く人材の役割も広げていく。その両方を続けられる体制をつくることだと、ディーシステムは考えています。
クラウド移行後の運用体制を、次の段階へ
クラウド移行が完了しても、運用上の課題がすべて解消されるわけではありません。
監視や定型作業が特定の担当者に依存している。障害時の判断基準や連絡条件が十分に整理されていない。運用コストを見直したい一方で、品質を落とさずに体制を変える方法が分からない。
こうした課題を解決するには、作業の移管だけでなく、判断基準、エスカレーション条件、育成、次の配置まで含めて運用体制を設計する必要があります。
ディーシステムでは、クラウド移行後の監視・運用支援、業務の標準化、オフショア移管、L2運用やPMO領域への体制拡張を支援しています。
現在の運用品質を維持しながら、コストや役割分担、人材配置を見直したい方は、ご相談ください。
【クラウド移行後の運用体制について相談する】
ほかのプロジェクト実績を見る
ディーシステムは、顧客現場で何を支援してきたのか。プロジェクト実績から見る仕事のかたち
製薬ヘルプデスク、基幹システム統合、情報システム部支援など、ディーシステムが顧客現場で担ってきた役割を紹介しています。
現場で働く社員の成長を知る
【現場から見えた成長の瞬間 #01】監視業務から上位レイヤーへ
監視業務で得た経験を、設計・構築や上位運用の仕事へつなげた社員の歩みを紹介しています。
