PM視点で読み解く 基幹システム運営録 1: 情シスは“便利屋”なのか？ — PM視点で再定義する基幹システム運営
シリーズのはじめに
情シスの仕事をしていると、「ちょっとこれお願いできますか？」という依頼が日常的に飛んできます。小さな設定変更から、急ぎの調査、管轄外の相談まで。気がつけば一日が“対応”で埋まり、本来やるべき基幹システムの整備や改善は後回し、そんな日も珍しくありません。
これは特別な話ではなく、多くの情シスが似た状況を経験しているのではないでしょうか。私自身も例外ではありません。目の前の課題に応え続けるうちに、「情シスとは何を担う仕事なのか？」という問いを何度も考えましたし、見失いかけたりもしました。
基幹システムは、導入して終わるプロジェクトではありません。日々の運用、改善、そして小さな意思決定の積み重ねによって形作られていく継続中のプロジェクトといえます。振り返ってみると、現在の構成や運用の姿は、その時々の制約や優先順位、現場の判断の履歴そのものだと言えます。
このシリーズでは、そうした視点から、情シスとして基幹システムをどう捉え、どう運営しているのかを整理して書いていきます。内容は、現場で感じている悩みやトレードオフ、設計や運用の考え方、そして現在の構成に至った背景まで多岐にわたります。
本シリーズの目的は二つあります。一つは、同じように基幹システムに携わる方々と実践的な知見や悩みを共有すること。もう一つは、私たちのシステムがどのような判断の積み重ねで今の形になっているのかを記録として残すことです。これは技術解説というより、意思決定のログに近い試みかもしれません。
このシリーズ「PM視点で読み解く 基幹システム運営録」が、日々の運用に追われながらも「自分たちは何を守っているのか？」を考えるきっかけになれば幸いです。
情シスを取り巻く構造の特徴
情シスを取り巻く構造の特徴には次のようなものがあります。
- （多くの場合）プロフィットセンターではない
- 他部門の業務を止めないことが最重要の役割
- ステークホルダが社内全域にわたるため、非常に多い
こうした特徴から情シスは
- 成果が見えづらく、評価されづらい（売上などのわかりやすい数値指標が立てづらい）
- 依頼、相談の間口が広く、それらの優先順位をつけることが難しい（部門Aと部門Bと部門Cの依頼、どれが優先？）
- 体制増強もなかなか難しい（成果もわかりづらいし、利益を産むわけでもないし）
という、今ひとつ何をしているか周囲から理解されづらく、評価もされづらく、でも困ったらまず相談されて、結果忙しくてバタバタしているという「便利屋」さんとしての位置付けになりがちなのです。
PMの視点から情シスの仕事をとらえてみると
そんな情シスの仕事をPM（プロジェクトマネージャ）の観点からとらえてみると、その最大の特徴は「終わらない」ということです。一般的なプロジェクトは一時的な取り組みであり、ゴールがあり、終わりがあります。しかし、情シスのプロジェクトは継続運営そのものがプロジェクトとなるため、明確な終わりというものはないのです。
もちろん、情シスの仕事にも新規機能開発はあり、その場合は納期も設定します。しかし、その機能も納めて終わりにはならず、運用し、保守していくことになります。私は、家庭では自炊担当なのですが、情シスの仕事をしていて感じることは、この毎日の家事に近いなぁということ。納期はある（朝食、昼食、夕食の時間）けれど、それで終わりではなく、後片付けや買い出しをして、また次の食事の調理をする。その間、掃除やら洗濯やらも発生する（他部門の依頼）。電球が切れたら買いにも行く（緊急対応）。そして、明日も明後日も繰り返し、そのタスクはやってくる。
PMの視点では、この終わりのなさということが通常のプロジェクト運営とは全く異なる部分になります。終わりがないので、いきおいそこには理想的な構造と現実との乖離も生まれやすいのです。つまり、日々の対応と意思決定が積み重なって構造になるという特徴が情シスの仕事にはあります。それは、皆さんの住まいがモデルルームのような理想的な姿になっていないことと近しい。確かに、整然と整理され、機能的で無駄のない状態にはしたいです。したいですが、そうなるまで何処にも住まないわけにもいかないし、じっくり考えていられないし、日々、生活の中で発生する家事に対応しているうちに現在のお姿になっているのではないでしょうか。なぜなら、家事は快適に生活することが主であるからです。
同じく、情シスの仕事も快適に業務を継続できることが主であるため、理想は理想として追求しつつも、なんだかんだ雑然となったりもするのです。
ですので、基幹システムは設計図ではなく、意思決定の履歴でできているとも言えるわけです。
情シスの役割再定義
さて、ここまでで情シスが「便利屋」になりやすい構造にあるということが理解いただけたかと思いますが、では、本当に情シスは「便利屋」なのでしょうか？もっと言えば「便利屋」に甘んじていていいのでしょうか？
私は「No」だと思います。
情シスは組織に欠かせない次のような役割を果たせると考えています。
- 便利屋（修理屋）ではなく
安定設計者として、業務品質を組織に作り込む - 単なるタスク処理ではなく
運用設計者として、業務の足回りを改善し続ける - 多部門との調整を通じて短期最適に陥りがちな組織に、長期安定の視点を持ち込む
オフェンスとディフェンスでいえば、ディフェンス。短期と長期でいえば長期。こうしたことに寄与できることが情シスの素晴らしいところだと思います。
何より、多様なユーザが目の前にいる環境ということが強い。これは情シスがビジネス視点を持つように研鑽すれば、全社のビジネスを加速するポジションに立ちうるということです。
シリーズの宣言
このシリーズでは今後、
- クラスメソッドの基幹システムの構成
- その歴史的背景
- 意思決定の理由
- 運用の現実
- 改善の考え方
をPM視点＋技術視点で書こうと考えています。
これは単なる知識共有だけでなく、私たちの意思決定の記録でもあります。
そのため、社外の同じく情シスや基幹システム運営にあたる方だけでなく、クラスメソッド社内の同僚達にとってもログとして価値のあるものになればと考えています。
まとめと次回予告
情シスはそのロール上、目立ちません。
しかし、組織の土台として業務を支え、上手く行えれば業務をブーストする可能性も持つ重要な役割だと私は考えています。
そしてまた、情シスのあり方は組織の歴史を示すものでもあると思います。
あなたの基幹システムはどんな意思決定の積み重ねでできていますか？
そんなことを考えながら、次回以降も読んでいただけると嬉しいです。
次回はPM視点に着目して、終わらないプロジェクトをどう管理するか？というテーマで書きたいと思います。
