障害対応が上手な人ほど「システム以外」を見ている。着任直後に把握すべき3つの視点
はじめに
新しいプロダクトや組織に着任し、ITサービスマネジメントの役割を持ったとき、多くの方は「まずシステムを理解しなければ」と考えるかもしれません。しかし、システムだけを見ていても、本当に重要なことは見えてきません。
なぜなら、システム障害対応や保守運用は、単にシステムを維持する仕事ではなく、「事業が生み出している価値を守る活動」だからです。
例えば、同じ障害でも、売上へ直結する機能なのか、内部業務だけに影響する機能なのかによって、優先順位も、関係者への説明の仕方も変わります。また、システム構成を理解していても、組織の意思決定プロセスや、現場で暗黙知になっている運用を知らなければ、障害時に適切な判断ができないことがあります。
そのため、「システムを理解する前に、まずビジネスと組織を理解する」という視点が非常に重要です。
この記事では、新しい現場へ着任した際に、どのような観点で状況を把握していくとよいのかを整理していきます。
特に、以下のような方には役立つ内容になるはずです。
- 新しい ITサービスやプロダクトの担当になった方
- システム障害対応や保守運用を改善したい方
- ITサービスマネージャとして着任し、どこから手を付けるべきか悩んでいる方
この記事を読むことで、「システムを理解する」とは、単にシステムや構成を把握することだけではなく、事業・組織・サービスを含めて立体的に理解することなのだ、と感じてもらえるのではないかと思います。
また、障害対応において、なぜ関係者との協同や、サービス視点での理解が重要なのかもお分かり頂けるはずです。
ITサービスマネジメントの仕事は、システムだけを見ていても務まりません。
事業、組織、システムをつなぎながら、サービス価値を守り続ける役割だからです。
では、具体的にどんな観点で把握していくと良いのでしょうか。大きく分けて、ビジネス、組織、システムの 3 点から見ていきます。
1.ビジネス
顧客
まず何より、「誰がお客様なのか」です。IT サービスがどのように使われているのかを把握します。これにより、「なぜこのような画面構成になっているのか」「なぜこの導線が重視されているのか」が見えやすくなります。
また、利用時間帯やアクセス特性を見ると、サービスの性質も見えてきます。
例えば、平日日中に集中する BtoB サービスなのか、夜間や休日もトラフィックが高い BtoC サービスなのかによって、障害時の影響範囲や、求められる対応スピードは変わります。
ここを理解していないと、障害の重大度判定を誤ることがあります。
技術的には軽微な障害でも、重要顧客の業務停止につながる場合がありますし、逆に、多数のアラートが出ていても、ユーザー影響が限定的なこともあります。
つまり、障害対応は、システム視点だけではなく「サービス利用者に何が起きているか」という視点で見なければならないので、お客様を理解することが大事です。
儲け方
次に、そのプロダクトがどのように収益を生み出しているのか、というマネタイズポイントを理解します。
例えば、広告掲載で収益化しているサービスと、成約課金型のサービスでは、重要となる機能が異なります。広告表示が止まることが致命的なケースもあれば、会員登録や決済機能が止まることが重大障害になるケースもあります。
障害対応では、「どこが止まると事業インパクトが大きいか」を理解しているかどうかで、判断の質が変わります。
また、関係部門とのコミュニケーションも変わります。ビジネスモデルを理解していれば、「なぜ今これを優先するのか」を説明しやすくなり、意思決定もスムーズになります。
業務プロセス
そのビジネスモデルを実現するために、どのような業務プロセスが存在するのかを把握します。
ここでは、いきなり詳細な業務分析まで踏み込む必要はありません。
重要なのは、「どのようなシステム障害が、どの業務へ影響するのか」を結び付けられる程度に理解することです。業務の流れをざっくり理解しておくだけでも、障害時の影響調査がしやすくなります。
また、現場特有の用語を早めに理解することも重要です。
障害対策会議では、業務用語や略語が飛び交います。用語理解が追いつかない状態だと、情報収集だけで精一杯になり、本質的な判断へ集中できません。
そのため、知らない単語が出てきたら、なるべくその日のうちに確認しておきます。
重点テーマ
会社や事業には、その時々で重点テーマがあります。
例えば、事業拡大、新規プロダクト立ち上げ、クラウド移行、コスト削減、セキュリティ強化などです。
ここで重要なのは、「何をやっているか」だけではなく、「なぜそれをやっているのか」を理解することです。
例えば、パフォーマンス改善施策が進んでいる背景には、アクセス急増が起きているかもしれませんし、運用自動化が推進されている背景には、慢性的な人手不足があるかもしれません。
このような背景を理解していると、障害対応時に、「今この組織が何を重視しているのか」を踏まえて動きやすくなります。
2.組織
自組織と開発チーム体制
次に、自組織と開発チームの体制を把握します。
内製なのか、SIer中心なのか、複数ベンダー構成なのかによって、障害対応の進め方は大きく変わります。
特に見ておきたいのは、「誰がどの役割を担っているか」です。障害検知、一次対応、エスカレーション、恒久対応、リリース判断など、それぞれ誰が責任を持つのかを理解します。
また、開発チームと保守チームが分離されているか、一体運営されているかの違いもポイントです。一体型だとスピード感は出やすいですが、開発案件が忙しくなると保守改善が後回しになりやすくなります。逆に分離型だと、安定運用はしやすい一方で、情報伝達コストが増えます。
体制理解を進める中で、自分はどのような役割を期待されているのか、認識しておくことも大切です。
プロダクト体制
企画部門やプロダクトマネジメント体制も把握します。
どのように開発案件が起案され、誰が優先順位を決め、誰が意思決定するのか。これを理解しておくと、「仕様通りだが、サービス影響が出ていて急いで直したい問題」が発生した際に、どう動けば最速で解決へ向かえるかが見えてきます。
システム障害対応は、純粋な技術問題だけで完結することは少なく、組織的な意思決定プロセスと密接につながっています。
ユーザー部門
ユーザー部門についても、組織構造をざっくり把握します。
エリア別、商材別、業界別など、様々な切り方があります。障害時には、「どのユーザー部門へ影響するのか」を整理する必要があるため、組織図を把握しておくことは非常に役立ちます。
支援してくれる機能組織
法務、セキュリティ、リスクマネジメント、SRE、インフラ専門組織など、支援してくれる機能組織も重要です。
ただし、会社によって守備範囲は大きく異なります。「どこまで相談できるのか」「どのタイミングで巻き込むべきか」を把握しておくと、障害時に迷うことがなく、頼りやすくなります。
キーパーソン
最後に、キーパーソンを把握します。
組織には、正式な役職以上に、実質的な情報ハブ、影の意思決定者になっている方がいます。
障害対応では、こうした方の存在が非常に大きいです。
どこに気を付ければ現場が動きやすいのか。
どのような説明をすると関係組織やお客様の納得感が得られやすいのか。
こうした勘所を理解している方々と関係を築けると、障害対応や改善活動が進めやすくなります。
3.システム
システム全体図
まずはシステム全体を把握します。ただし、理想的な構成図が整備されているとは限りません。
その場合は、関係者とホワイトボードを囲み、「お絵描き大会」をします。業務の流れに沿って、システムとデータ連携を書き込みながら整理していくと、理解しやすくなります。
特に重要なのは、「どのシステム障害が、どのサービス影響につながるか」を結び付けることです。単なる構成図ではなく、「サービス視点のシステム理解」が必要になります。
障害管理
障害管理プロセスも確認します。
どこで検知し、誰が受け付け、どう重大度判定し、どのようにエスカレーションするのか。また、夜間や休日に、どのような考え方で対応開始するのかも重要です。
アラートは飛んでいるが誰が見るのか曖昧になっている、重大度基準がない、連絡ルールが属人化している、といったケースは珍しくありません。こうした状態だと、障害そのものよりも、「誰が何を判断するか」で混乱することがあります。
そのため、障害管理を見る際は、「技術的な仕組み」だけではなく、「コミュニケーション設計」を重視することをおすすめします。
保守運用
最後に、定常的な保守運用の把握です。
例えば、サービスデスク、監視運用、キャパシティ管理、定期メンテナンスなどです。
保守運用は、単なる現状維持ではありません。IT サービスが生み出している価値を、長期間にわたって維持する活動です。
システム障害対応が安定している現場は、日常運用が整理されていることが多いですし、逆に、日常運用が混乱している現場では、障害時の混乱も増幅しやすくなります。
おわりに
ここまで、新しい現場へ着任した際、何を把握すればいいのかを紹介しました。
順番としては、システムの前に、ビジネスと組織を理解することが重要だと考えています。なぜなら、システムは、ビジネスと組織のために存在しているからです。
また、多くの現場では、何かしら課題になっていることがあります。例えば、障害が多い、アラートが多い、保守が属人化している、連携が悪い、ユーザー部門との関係がぎくしゃくしている。
そのため、ただ情報を集めるだけではなく、「今、どこに課題があるのか」を意識しながら、把握する順番や濃淡を変えていくことも重要です。
ITサービスマネジメントの仕事は、単に障害へ対応する役割ではありません。サービス価値を守り、関係者をつなぎ、事業を継続させる役割です。だからこそ、システムだけではなく、ビジネスと組織を含めて理解する必要があります。
新しい現場へ入ると、不安やプレッシャーもあると思います。
しかし、焦って全てを理解しようとしなくても大丈夫です。
まずは、サービスを理解しようとすること。
そして、関係者と協同しながら、一歩ずつ現場を理解していくこと。
その積み重ねが、障害対応の質を高め、結果として、エンドユーザーへ提供するサービス価値を守ることにつながるのです。