なぜ情シスがすべてのSaaSの管理をするとうまくいかないのか？

本記事を書くきっかけは「10人規模のスタートアップが社内SaaSアカウント管理を始めたけど早速ワークしなかった」というnoteが書かれていたのがきっかけです。

アカウント管理を情シスが中央集権的に管理するのはうまくいかない。組織が大きくなればなるほど現場と距離ができてしまうので。情シス部門が管理するのは全社横断SaaSに絞るのがよいと思っている。
@CorporateDxer #note https://t.co/zRjnLyR5OV

— howdy39 (@howdy39) May 29, 2021

実際私も「情シス側でこのSaaS管理してほしい」と言われることがありますが、この手のはうまくいかなくて結局、事業部側に戻るケースもなんども見てきているので引き受けていません。なぜうまくいかないの？なにがだめなの？どうすればいいの？ってところの私なりの考えを書いてみようかなと思います。

※ 私は10年以上ソフトウェアエンジニアをやっていましたが、20年の4月から情シスをやっています。現在の立場は情シスですがキャリアとしては情シスではない期間が圧倒的に長いです

1つめ 業務のスピードが落ちるから

たとえば情シスがとあるSaaSのアカウントの管理をしていて、それに付随するパスワードリセットだったりのヘルプデスク対応が当日中に返答できているとします。
このとき管理するSaaSが増えるとどうなるでしょうか？
SaaSが増えるごとに翌営業日、2営業日、3営業日以内の対応…みたいにズルズルと延びていきます。
いやいや人を増やせば延びないでしょ？っておもいますよね？
はい、人を増やせば延びませんが、実際問題、対応できる人はSaaS数にきれいに比例で増えたりはしないのがポイントです。

これはヘルプデスク対応には波があるためです。組織変更の直後、入社の直後、新規プロジェクトがたちあがったタイミングなどで負荷が高くなりがちです。

通常のヘルプデスク対応を次のようなグラフにしました。
その日に処理できる依頼工数を超えた分は残業したり翌日に回して対応し、余裕がある日はドキュメントの整備を始めとした改善プロジェクトを行います。

ではここから管理SaaSを2倍、ヘルプデスク対応人数も2倍にしましょう。
この場合、超えた分の扱いはさきほどと一緒ですが、改善工数が大きくなりすぎるのです。

改善業務があったとしてもそれはヘルプデスクではなくコーポレートエンジニア中心で回したほうがうまくいくケースが多いですし、改善の中心はコーポレートエンジニアです。
そのため実際には管理SaaSが2倍になってもヘルプデスク対応人数は1.5倍とかに抑えた形になります。
そのため、超えた分は3営業日以内に対応するみたいな形にせざるを得ないのです。

結果、ヘルプデスク対応が遅れるので、業務のスピードが落ちます。

すぐやってほしいのに数日待たないといけなくなります、待ちが発生するとリマインドが発生する、などの悪循環も発生します。
「前はすぐやってくれたのに、対応悪くなったなー」「いやSaaSの管理巻き取ったからじゃん！」みたいなやりとりしたくないですよね、これお互い不幸です。終わりの始まりの足音が聞こえてきます。
下手に情シス側でSaaSの管理を巻き取ってしまうと、業務のスピードも落ちれば働く環境もどんどん悪化します。なので依頼工数とヘルプデスクにあてられる工数を十分に考慮して管理するSaaS数を調整していかないといけません。

2つめ セキュリティリスクがあがるから

情シスが管理しているSaaSって多いんですよね。
会社にもよると思いますが10〜20程度はあるんじゃないでしょうか。
管理しているSaaSのアップデート情報をすべて追っていかないといけません。
このSaaS一覧が増えすぎるとアップデート情報をおえなくなり、本来やらないといけなかった作業を漏らしてしまうのです。その結果、情報漏えいなどのリスクがあがってしまいます。

アカウントの発行削除だけでなく権限や設定も適切に管理しないといけません。管理SaaSが20〜40になっても適切に管理できる自信ありますか？私はないです。

また他部門で使っているSaaSでどういう情報を扱っているのか？どういう使い方をしているのか？などは情シス側だと詳細はわかりません（つかってないので）
そのため、めちゃくちゃ厳格にアカウントや権限を管理をするべきSaaSなのか、たいした情報持ってないからある程度ゆるくてもよいのかなどの判断ができず、一律の対応になり工数を適切にあてられなくなります。

棚卸しの頻度やヘルプデスク対応の優先度をつけられないため、セキュリティ面だけでなく工数面でも無駄が生まれてしまいます。みんな不幸になります。

3つめ 評価が難しくなる

管理だけを情シスというか別部門になげてしまうと評価が難しくなります。
どれだけスピーディに対応しても、どれだけ運用を改善しても、実際に影響を与えるのは他部門の人なので、情シスのマネージャーがその評価をするのが難しいのです。その改善施策に実際どれだけ効果があるのか使ってないのでわからないのですよね。
結果、適切な評価がされずメンバーのモチベーション低下などにもつながっていきます。

4つめ 管理コストが大きくなる

アカウント管理だけの権限を付与できるSaaSや請求担当が決められるSaaSであればいいですが、ない場合は管理者でひとくくりにされています。
仮に情シス側でアカウント管理を巻き取ったしても、請求部分（クレカ、口座引落、振り込みetc）は現場の人がやるべきなのですよね。

そうするとSaaSの管理者を現場と情シスの2部門で持つことになります。
すごく良くない状態になります。どうなるかというとシステムを管理する部門が宙に浮くんですよね。

現場は情シスがやってくれると思っていた。情シスは現場がやってくれると思っていた。みたいなお見合いになるケースです。
じゃあこっからここまで情シスね、などのやりとりを細かく定義しないといけないので、管理コストがどんどんあがるのです。

また本当の管理者がブレることでセキュリティリスクの増加にもつながっていきます。

情シスがすべてのSaaSの管理をするとうまくいかない理由

ツイートで触れたような現場との距離が生まれるからうまくいかない、というのは、1〜4で触れたような認識のズレが発生するからです。現場と情シスの両方の視点を持ってないとここに気づけないんです。
情シスの人は昔は開発やってました、昔は営業やってました、昔は人事やってました。のようなキャリアの幅が広い人が多いと思います。そのため両面で見てうまくいかないのが直感的にわかる方が多いと思います。

でも逆パターンって超レアケースなんですよね。情シスやってたけど今は営業やってる人とかいますか？
私が知っているのは、スタートアップでCTOやエンジニアやってて情シス業も兼務してたーって人ぐらいです。

なので現場側からではなく情シス側からどうすればいいのかってのをアプローチしていく必要があります。

そもそも強い組織（チーム）と弱い組織（チーム）のちがいって？

組織（チーム）の仕事の範囲を超える仕事をしているかどうかが大きいと考えています。

エンジニアだから採用（人事）を手伝わない、営業だからアカウント管理（情シス）をやらないとか言ってるようじゃ弱い組織です。

エンジニアのことを一番わかってるのは誰ですか？
人事ですか？違いますよね？エンジニアですよね？
エンジニアに響く採用施策を考えられるのはエンジニアです。
とはいえ採用のプロは人事ですのでもちろん必要です。
エンジニアと人事の橋渡しをする人が必要なんです、組織が大きくなると採用施策を人事と一緒に考えるエンジニアが必要になってくるんです。
もちろん開発だけやるスペシャリストも必要です。別にエンジニア全員が採用をがっつり手伝う必要なんてないとおもいます。

営業だからITに詳しくない？だからITに詳しい情シスに投げる？
実際に営業ツールを使っているのは誰ですか？営業さんですよね？
そのツールを真に使いこなすってのは、上っ面の部分だけ触ってるようじゃだめなんです。管理者権限を持ち、アカウント管理も権限管理もやり、アップデート情報も追いかけて初めて100%ツールを活かせるんです。

そこを手抜きした結果が最近良く見るSalesforceの顧客情報流出とかにつながっていくんです。Salesforceが悪い！とかツールのせいにしているようじゃだめなんです。使いこなせないなら最初から使うべきではないのです。ツールに振り回されてはいけません、ちゃんとツールを組織で使いこなしましょう。

再度書きますが、「私の職種は〇〇だから〇〇の仕事はやらない」とか言ってるようじゃだめなんです。

もちろんそれは情シスを始めとしたバックオフィス部門だって一緒です。
情シスだから社内ITだけしてればいいんだーとか言って事業を追っかけないとかだめなんです。
事業を成長させるための社内ITを作るんですよ。事業を理解しないでそんなもの作れるわけないですよね。

ではSaaSはどう管理すればいいのか

別に情シスが管理しないSaaSは他部門に丸投げでOK、なんて言ってるわけではありません。SaaSの管理方法に詳しいのは情シスですよね。導入から運用方法を一緒に考えてあげたりするのだって情シスの立派な仕事です。全部まるっとやってあげることは本当の優しさではありません。

いま、私の中でベストだと思っているのは次のような形です。
情シスは全社向けのSaaSの管理や社内NWの構築を始めとした情シスにしかできないことをまずしっかりやりましょう。と同時に部門でSaaS管理している人を支援しましょう。部門向けSaaSを管理してあげるのではなく管理に役立つデータを提供したり、管理方法を一緒に考えてあげたり、SSOの設定を手伝ってあげたりの支援です。あくまで管理の主体は部門の方で、情シスは支援にとどめます。

本来、組織があるべき形、生産性があがる形、働くみんながHappyになる形ってなんだろうってのを、組織の枠を超えてみんなで考え、それに向けて全社一丸となって動けるといいですよね。
そうすることで強い組織にスケールする組織になるんじゃないかなと思っています。