こんにちは、こんばんは、おやすみなさい。id:sota1235です。

私は組織図上、セキュリティチームに所属しています。

ですが次の記事でも言及しているとおりここ1年弱の間はCorpIT業務も担っています。

本日はCorpIT業務を引き継ぎ、改善していく過程で取り組んだ「業務で利用しているSaaSやWebサービスを把握」について紹介します。

課題
どのように取り組んだか
完成したITサービスカタログの運用
- よかった点
  - ナレッジストック場所としてのITサービスカタログ
  - CorpITの改善への活用
- 課題
  - ITサービスカタログに載せる基準
  - 誰がいつ書いて保守するのか
最後に

課題

引き継いだタイミングの状況

詳しくは先ほど貼り付けた記事を読んでもらえればと思いますが、2024年の10月ごろにセキュリティチームとコーポレートチームの一部メンバーでCorpIT業務を巻き取ることになりました。

引き継ぐ上で守るべき最低ラインはCorpIT業務を止めず、社内業務を止めてしまう事態を避けることでした。

ただ、せっかくセキュリティチームが引き継ぐからには上記に加えてCorporate Securityの状態を把握し、あるべき姿を模索しつつ巻き取っていくことも目指していました。

何があるかわからない

徐々に引き継ぎを行い、業務を回していく中でいくつかの課題が見えてきました。

そのうちの1つが「10Xの社内でどんなSaaS / Webサービスを利用して業務をしているのかわからない」ことでした。

サービス管理台帳はあったがメンテが中途半端に止まっており、Ownershipが浮いていた
SaaS管理SaaSとしてAdminaを利用していたが、すべてのサービスが連携されているわけではなかった
- 大半はカスタム連携だったがメンテナンスされていない、もう使っていないサービスが連携されている等、実態の状態と乖離が生まれていた
社内で利用するサービスの全体像を掴んでいるメンバーが誰もいないため、CorpIT業務の過程で毎回考古学をしたり、詳しそうな人を探す旅に出る必要があった
- たとえば「このアカウント、権限強いけど1Passwordのここに置いて大丈夫かな…」という課題をみつけてもサービスの管理者がわからない、どういう理由で使ってるかもわからない、ドキュメントもないという状態からスタートしなければいけませんでした

スピードを優先し、リーンな体制でやっていく必要のある企業ではこういうことは珍しくないんだろうなと思いますし、あえてこの状態を受容する選択肢もあると思います。

一方で当時の10Xではこの課題に紐付き、厄介な課題につながっている状態でした。

さまざまな課題

CorpIT観点

1つ目の課題は業務のoverheadがたびたび発生していたことです。

先ほど権限の強いアカウントの調査、という例を出しましたがCorpIT業務を回し、改善していく中では多くのサービスの状態を調べたり、利用実態を掘り下げていく必要がありました。

その過程で毎回、調査から始めなければならないという状態は地味に、しかし確実に業務負荷を増やす要因になっていました。

また、その業務の過程で得た知見やナレッジを溜めておく箱もない状態だったため各々がいったん、NotionやGitHub Issue、Slackにメモを残すという状態になりやすくもありました。

2つ目の課題は、重要なイベントを漏れなくキャッチすることが難しい状況だったことです。

登録されてるアドレスが統一されていなかったり把握できていなかったため、たとえば年間契約の更新、利用規約の改定、便利な機能の追加といったニュースをキャッチしづらい状況でした。

幸い、（手前味噌ですが）私含めCorpITを引き継いだメンバーがそれらをキャッチして回ったため重要なものが漏れることはありませんでしたが継続的に多くのサービスを運用することを考えると負荷が高い状態でした。

セキュリティ観点

セキュリティチームがCorpIT業務を巻き取ることに積極的だった理由のうちの1つにCorporate Securityの状態の把握、そして必要ならレベルアップしたいという思惑がありました。

しかし実際に蓋を開けてみるとセキュリティの取り組みをするためのスタートラインである「自分たちが守りたい資産を把握する」状態を満たせていない状態というのがわかってきました。

守りたいものがわからなければそもそも課題が見えず、改善するためのアクションを出すこともできません。

また、ただ存在を知っていればいいわけではなく「どんな情報を」「誰が」「どんな風に」「どこで」扱っているかを知ってはじめて把握した状態といえます。

当時はそれができていませんでした。

管理方法の課題

メンテされてないながらもサービス管理台帳はあったと先ほど述べましたが、この方法にも課題がありました。

この管理台帳は具体的にはスプレッドシートで管理されていましたが運用を引き継ぐ中で次の課題が見えてきました。

管理したいプロパティが増えた時、右にどんどんシートが伸びていき見通しが悪い状態になる（なっていた）
作業ログやそのサービス特有の特殊な事情、議論ログといったフロー情報の記載とスプレッドシートの相性が悪い
マクロ的なものを組めば自動化は可能なものの、属人性を高めるリスクがあった

どう課題に立ち向かうか

これらの課題に対して最初に考えたのが、次の2つのアプローチのちどちらを選択するべきかでした。

全部未把握だけど、それを承知で走りながら徐々に把握する
いったん、足を止めてでも全容を把握することにコストを払う

CorpITの業務や社内のヘルプデスクを維持することを優先するなら前者が有力な選択肢でしょう。しかし、私たちはCorpIT観点の課題で挙げた日々の業務でのoverheadを重く捉え、後者の「足を止めてでも全容を把握することにコストを払う」アプローチを取ることにしました。いわば急がば回れです。

もちろん、足を止めると言ってもCorpIT業務を全部止めるわけではなく、優先度を相対的に強化するイメージです。

どのように取り組んだか

ここからは具体的に何をしたのか。記事タイトルの「ITサービスカタログ」とは何なのかについて説明していきます。

ToBeを考える

ここまで述べてきた課題はCorpIT業務を引き継いで回す中で徐々に浮き彫りになってきたものです。

その過程でひとまず次のことに確信を持っていました。

サービス管理台帳的なものの存在は必須

業務の過程で特定のSaaSやWebサービスに触れる中で「わからなかったらまずはここを見る」「何かメモるならまずはここに」という場所は必須だと感じました。

未経験だった私が引き継ぎの過程でCorpIT業務に感じた特徴の1つは自動で残されていくメタ情報の少なさです。

たとえば開発であればドキュメントがなくてもgit logやGitHub上のレビューログ、ディスカッション等のログからある程度実装やコードの背景を掴むことが可能です。

一方でSaaSやWebサービスの設定情報やアカウントの状態、権限の設定状態などの背景を知るにはどうしても作業ログやストックドキュメントが必要になります。

監査ログはあるけど欲しいログがない。利用しているプランだと監査ログを見ることができないなんてことは当たり前でした。

それらのメタデータをストックしていくための箱は必要だと考えました。またそのためには必然的に利用しているサービスを網羅し、台帳としても機能することが求められます。

管理台帳に相応しいのはSaaS管理SaaSでもスプレッドシートでもなさそう

弊社で大変お世話になっているAdminaをはじめとしたSaaS管理SaaSでサービス管理台帳の管理する困難だと感じました。

利用サービスの全容を把握していく中で、自分たちが管理したいメタデータやそのフォーマットに柔軟性を持たせたかったこと。それを解決するためにSaaS管理SaaSを新たに契約したり、既存の利用サービスをなんとかカスタマイズすることはコスパが見合わないと判断したことが理由です。

また、引き継いだスプレッドシートで作成された管理台帳の拡張も先ほど述べた理由により難しいと判断しました。

いったん、目指すところ: Notionでサービス管理台帳を作ろう

これらを踏まえて、Notion DBでサービス管理台帳を作ろうと決意しました。選定理由は以下です。

社内のドキュメントはチーム問わずNotionで管理されていること
- 完成後の台帳は全社員が参照しうるものになるためアクセシビリティはとても重要
メンテナンスコスト
- スプレッドシートのマクロをいじれる人材は少ないですが、Notion DBのプロパティやautomatoinであればいじれる人材が社内にたくさんいます
カスタマイズ性
- プロパティのタイプの豊富さ、テンプレート機能によるページフォーマットの均質化、DBの相互参照による後の拡張等

このNotionで作ったサービス管理台帳こそがITサービスカタログ*1です。

まずは箱を作る

というわけでまず一番最初にNotion DBの箱を作りました。

お見せしてしまうとこんな感じのものを作りました。

トップページ

プロパティの一部

ページテンプレート（一部抜粋です）

些細ですがいくつか工夫した点を書きます。

プロパティセクションを使う

プロパティを設計する中で「このプロパティはCorpITが管理したい」「このプロパティはサービス管理者に埋めて欲しい」といったように複数の立場のメンバーが迷いなく編集できる形にする必要がありました。

そこでNotionのプロパティをセクションでグルーピングすることである程度、わかりやすいように整理しています。

とはいっても素直にセクションを増やしすぎても見通しが悪くなりますし、この整理だけで迷いなく記入しろというのは難しいので別途、記入ガイドを用意しています。

管理するための情報の記載に留める

当初は社内のサービス利用者向けのガイド等もここに集約しようと思ってたのですが次の理由からやめました。

全サービスで利用ガイドが必要でないこと
社員向けのガイドポータルは別で整備されており、そことのリンクを考えるとかえって不便になること

現在は、利用者向けのガイドを社内ガイドポータルに配置。必要であればITサービスカタログからそのページへのリンクを貼る形で落ち着いています。

把握して箱を埋めていく

ある程度、Notion DBという箱を整えたら本丸である把握フェーズです。

やることはひたすら社内で利用しているSaaS / Webサービスを探し出し、Notion DBのページを作っていくことです。

このタイミングで作成したページの中身やプロパティをすべて埋めようとすると途方もない時間がかかってしまうので、最低限の情報だけ埋めた上でまずはリストを埋め切るところを優先しました。

具体的には次の手段で利用サービスの把握を進めていきました。

スプレッドシートで管理されていた管理台帳からの転記
- ものによってはすでに利用が終了していたケースもあったので1つ1つ、転記のタイミングで利用状況等を調査しました
セキュリティチェックのログからの探索
- 10XではISMS認証を取得しており、その運用一環として新規サービス導入時にセキュリティチェックを行なっています
- このセキュリティチェックのログから未把握のものがないかを探索
1Passwordのすべての共有Vaultのチェック
- CorpITチームがはじめて会社で生まれた以前に契約した利用サービスがここからいくつか見つかりました
Google WorkspaceのOAuth連携アプリのチェック
- この機会に最後のダメ押しとしてチェックしました

一連の取り組みの中でおそらくこのフェーズに一番時間がかかりました（本当に）。コツは腕力です。

やってる間は「本当にここまでやる必要があるんだろうか…」と思ったことも正直ありました。というのも把握していったサービスの中にはCorpITもしくはセキュリティチームが強くコントロールせずとも問題の起きづらいものも多くあったからです。

とはいえ、この取り組みの後の業務への影響や過程で得られた知見を考えるとここでやり切っておいてよかったなと思っています。

把握したものの解像度を上げる

ひととおり把握が完了し、Notion DBにすべてのページが出揃いました。次は把握したものの実態を把握するフェーズです。

この時点でITサービスカタログのページ数は100を超えていました。半分以上はなんとなく把握できているとはいえこの分量をすべてセキュリティチームだけで埋め切ることは困難でした。

また、埋め切れたとしても今後そのカタログないしはサービスを管理していくことは難しいです。

なので各サービスで管理チーム / 管理責任者を定義し、そのチーム・メンバーにITサービスカタログのメンテナンスとサービス自体の管理を委譲することにしました。

そして委譲したチームのメンバーに対して緩めの締め切りを設け、記入ガイドとともにITサービスカタログの記載を依頼しました。

並行して、カタログの中でも重要度の高いものや潜在的なIssueがありそうなものはセキュリティチームから能動的に実態把握を進めていきました。わかりやすいところだと利用しているグループウェア製品やドキュメンテーションSaaS、プロダクトで本番稼働しているSaaSなどがこれに当たります。

取り組みの途中でみつけた課題は溜めておく

この取り組みを行なってよかったことの1つは思わぬ未知の課題に多く出会ったことです。

たとえば1Passwordのアイテムを眺めていると1Passwordの権限設計が甘いことに気づいたり、もう利用していないのにお金を払ってるSaaSをみつけたり等です。

これらの課題は優先度の高いものはすぐに手をつけつつ、そうでないものはIssueとしてバックログに積んでおき、ITサービスカタログの完成を優先しました。

また、これは私自身の良かったポイントですがこの過程でCorpITの難しさやリアル、正解のなさ*2を学べました。

今後、新しく生まれるものを取りこぼさないようにする

多くの労力を割いてITサービスカタログを完成させましたが、ここで終わりにしてしまうとまたN年後に同じ課題が再燃します。

それに陥らないよう、新規サービス利用時のワークフローを整え、ITサービスカタログの作成がなるべく漏れないように再設計しました。

完成したITサービスカタログの運用

ITサービスカタログの完成には丸1年ほどかかりました。本当に大変だった…。

とはいえ完成はスタートラインであり、本番は最初に定義した課題を解決できるように運用していくことです。

ここからは運用していく過程で良かった点と見えてきた課題をお話しします。

よかった点

ナレッジストック場所としてのITサービスカタログ

各サービスの情報や運用ノウハウ。管理時の注意点などの情報をストックしたいとき、ITサービスカタログという受け皿があることで迷うことがなくなりました。

また、嬉しい副作用としてCorpIT以外のメンバーにとってもよいドキュメントハブになった点が挙げられます。

たとえば経理チームは経費管理の観点から各サービスの利用状況や何に使われてるのか。それを誰に聞けばいいのかを知りたい場面があります。そのときにITサービスカタログが役立ったという声をもらえました。

CorpITの改善への活用

CorpIT領域で改善を行なっていく際にもITサービスカタログは役立っています。

たとえばSAML連携ができていないものを洗い出し重要なものから対応していく、という取り組みをした際にITサービスカタログのプロパティを元に絞り込み、ソートを行うことですぐに対応リストを作成できました。

他にはAdminaにまだ連携していないサービスを一覧化したり、重要な機密情報を扱うサービスを可視化するといった場面で活用ができています。

課題

よかった点はCorpIT目線だと山ほどあり、書ききれないくらいです。一方で運用していくことで見えてきた課題もあります。

ITサービスカタログに載せる基準

当初は「業務で利用するSaaS / Webサービスをすべて管理する」というざっくりとした定義でITサービスカタログ作りを始めました。

一方、利用しているサービスを把握していく過程でITサービスカタログを使って管理するのはコストが見合わないものや定義にマッチするか判断に迷うものが多くありました。

たとえば特定のサービスを利用することになるChrome拡張もカタログに入れるのか。備品を購入するために登録したオフィス製品のECサイトも必要か。チームの飲み会でスケジュール調整サービスを一時利用するのは業務利用なのか。等々、細かいところを詰めていくとキリがないです。

それらに対して結論、今は「よしなに判断する」という基準で運用しています。

当初はフローチャートみたいな基準を作れないかを模索したんですが、どこまで作り込んでも機械的に判断できないサービスが残ること。今の規模感であれば目が十分に届くこと。何より10Xメンバーの自治能力が高いことからあえて柔らかい定義にしています。

ITサービスカタログの目的に立ち返ると何をどのように使っているかの把握ですが、たとえば備品を購入するECサイトで把握すべきことは全社員が使うSaaSと比べるとごくわずかといえます。そのようなサービスに対してまでNotionページの作成を必須とするのはコスパが悪いですし、そこはバランス感を見極める必要があるなと感じています。