松浦修治（@shujinext）です。
普段の業務はITサービスマネージャの役割を担っています。
もし、あるプロダクトや会社にITサービスマネージャとして着任または入社したら、まず何から把握するか、についてまとめてみます。
ITサービスマネージャは会社や現場によって役割に偏りがあるので、必ずしもみなさんに当てはまるとは限りませんが、参考になれば幸いです。
大きく分けて、ビジネス、組織、システムの3点です。
- ビジネス
- 顧客
- 儲け方
- 業務プロセス
- 重点テーマ
- 組織
- 自組織と開発体制
- プロダクト体制
- ユーザー部門
- 支援してくれる機能組織
- キーパーソン
- システム
- システム全体図
- 障害管理
- 保守運用
1.ビジネス
顧客
まず何より、誰がお客様なのか、です。
ITサービスの使われ方を把握していきます。だからこのようなWebサイトの作りになっているのか、と紐づけて理解しやすくなります。1日や月間の使われ方の特性にも現れてくるはずです。
儲け方
次に、そのプロダクトはどうやって儲けているのか、というマネタイズポイントです。ビジネスモデルといってもいいです。これにより、障害対応を行うときに大事にしないといけないポイントが見えてきます。
例えば、何かを掲載して課金するのか、何らかの成約をもって課金するのか、によって、重要機能に差が出てきます。また、どこがこけると痛いのかが分かれば、関係組織とのコミュニケーションも円滑になります。
業務プロセス
そのビジネスモデルを実現するための、プロセス（業務）をざっくり把握します。いきなり細かい業務詳細まで立ち入っても、BPRをやるわけではないので、ざっくりです。
バリューチェーンの中を1段階ブレイクダウンしたような粒度です。どの機能で障害が起きると、どの業務に影響を与えるのか、業務の名前や特殊な言葉遣いを中心に理解しておく必要があります。特に、知らない用語が飛び交う会議は非常に苦痛なので、用語は早めにクリアしておくと良いです。
重点テーマ
戦略に基づいて、何かを推進していることがあります。中身を細かく知らなくてもいいので、課題になっていることなどのwhyを中心に把握します。もしかすると、パフォーマンスに影響を与える施策が動いているかもしれません。
2.組織
自組織と開発チーム体制
内製か外製なのかでだいぶ変わりますが、自組織の立ち位置と開発チーム体制を把握します。切り口は、障害対応や保守は誰がどんな役割で担っているか、開発チームは保守に関する専門チームがあるかどうか、を見ていきます。一体になっていると融通が利きやすい一方で、開発が忙しくなると保守が後回しになったり、障害が起きると開発が遅延したりします。
その中で、自分がどのような期待値で振る舞うべきか、然るべき方と合意します。もしかすると、実は何らかの組織課題があって、何かを変えていきたい意向があるかもしれないので、その大きな流れを理解しておきます。
プロダクト体制
企画やプロダクトマネジメントをしている組織については、開発プロセスと絡めて把握します。何かの開発案件や保守案件が立ち上がったら、誰がどんなふうに起案して、誰が承認して、誰が推進していくのか、です。
特に、障害というわけではないが早期解決しなければならない改修案件がある時、どうすれば最速で進むのか、は押さえておきます。
ユーザー部門
組織の切り方を把握しておきます。エリアごと、業界ごと、職種ごと、など様々な分け方があり、その時々の組織コンディションや戦略で変わります。ざっくり、どんなユーザーがいるのか、を把握しておきます。
支援してくれる機能組織
技術専門組織や、法務、リスクマネジメントなど、心強い味方になってくれる組織を把握します。ただ、これも会社や現場によって守備範囲が異なるので、どのようなスタンスで、どこまで支援しているのかを押さえておきます。
キーパーソン
情報のハブになっていたり、精神的支柱になっていたりする方を把握します。必ずしも職位の高い方とは限らず、どちらかといえば、当然ながら経験年数が長い方に多く見られます。障害や保守はサービスに影響が出たり、何らかの不便を我慢してもらうシーンがあるので、その勘所をうまく押さえさせてもらうのが目的です。
3.システム
システム全体図
サブシステムとシステム間連携の切り口でシステム全体図を眺めます。ただし、ないことが多いです。その場合は、IT部門のキーパーソンを特定し、ホワイトボードのある場所に集合して「お絵描き大会」をします。
ここでは、先ほど書いた「業務プロセス」の流れを追うように、順番にシステムとデータの流れを書き入れながら、絵を育てていくと描きやすいです。
障害管理
どこで検知し、誰が受け付け、障害の重大度をどのような評価軸で判定し、どんなエスカレーションが行われるか、を把握します。
非営業時間だったらアラート発報から障害対応開始までどのような考え方でやっているか、も重要です。障害の重大度判定と対応サービスレベルが定まっているかを確認します。
保守運用
定常的に行なっている保守運用を把握しておきます。サービスデスク体制とキャパシティ管理などのモニタリングを押さえます。
おわりに
何から把握するか、という順番までは表現しきれませんでしたが、大事なのは、システムの前にビジネスと組織を把握することだと思います。なぜなら、システムはビジネスと組織のためにあるからです。
また、何かが課題になっているはずなので、それを特定した上で、把握の順番を工夫したり、濃淡をつけたりすることも重要です。せっかく着任したのなら、何かをテーマ設定してITサービスマネージャとして立ち上がる方が、自分も動きやすく、周りからも助けてもらいやすくなるはずです。何よりも、誰かの役に立てられる可能性が高まります。
頑張ってください！
そして、何か私にできることがあれば、ご連絡ください。（連絡手段は、冒頭に記載の通り @shujinext で各種SNSからよろしくお願い致します）