![見出し画像](https://assets.st-note.com/production/uploads/images/53286862/rectangle_large_type_2_00e61b0d00bf4cd3a4310dbe0669071f.png?width=1200)
シード期のスタートアップが社内SaaSアカウント管理を始めたけど早速ワークしなかったです。
はじめまして!
情シス支援サービス「シスクル」を提供しているDXER株式会社でコーポレート担当をしているササキです!
この度、弊社のコーポレート運用を発信するnoteをはじめました!
未だ無名のスタートアップながら、10人程度の小規模チームがどのようなコーポレート運用を行い、どのような失敗を経て、どのような知見を得られたのか、自分たちの振り返りを兼ねて情報発信していければと思っています!
今回は、セキュリティ対策の一環で実施した「SaaSアカウント管理」について実施内容とその振り返りについて書いてみました!
少人数チームだと後回しになりがちな管理タスクですが、今回のコーポレート施策で、小規模だとしても、いかにカオスが広がりつくしているかということを痛感する結末となりました…!
私のように、コーポレート担当という名の「何でも屋」として、社内で落ちているあらゆるボールを拾わなければならず、SaaSのアカウント管理なども任されてしまい困っている、そんな方の参考なれば嬉しいです。
また、「自社ではこんな運用を実践して上手くいったよ!」そんな方のアドバイスも大歓迎です。みなさんが社内で行っている運用も参考にさせて頂き、よりよい運用を作っていければと思っています!
それでは早速いってみましょー!
■なんでアカウント管理をやり始めたの?
事業を進めていく中で情シス界隈の方とお話しする機会があり、様々な会社のセキュリティが”カオス状態”であることを耳にするようになったのがきっかけです。
弊社も「規模が小さいうちに対策をしておこう!」ということで、Secure SketCHを使って現在のセキュリティ対策評価を確認し、評価が低い部分の対策を進めていくことになりました。
![スクリーンショット 2021-05-27 18.16.29](https://assets.st-note.com/production/uploads/images/53247736/picture_pc_17ef8ee87a9bf2113672d05b96256e8f.png?width=1200)
Secure SketCH▶︎無料のセキュリティ対策評価サービス | Secure SketCH
しかし、いきなり大規模なセキュリティ対策はできないので、ハードルが低そうな部分から着手することになり、アカウント管理をするに至ったのです。
■どうやってアカウント管理をやったの?
まず前提として、弊社は社員1名と業務委託メンバー数名で構成されており、基本的には常時10名前後くらいの人がいるような体制です。
いざメンバーのアカウント管理をしよう!と思ったときには
・社長がSaaS大好きなので色んなSaaSを使いまくってた
・社内で誰が何のSaaSを使っているか分かってない
・どのSaaSにいくらかかってるのか分かってない
といった状況が既に発生していました。
なので、まずはこれらを把握するところから始めました。
実施したタスクは、大きく3つあります。
![スクリーンショット 2021-05-28 9.05.36](https://assets.st-note.com/production/uploads/images/53286940/picture_pc_2e6b3883652c354b8915299696e691e9.png?width=1200)
①利用中のSaaSを全てリスト化
②SaaS別に誰がアカウントを保持しているかを全てリスト化
③リストが定期更新され、最新の情報を維持
それぞれ詳しく説明します!
①利用中のSaaSを全てリスト化
弊社の場合は、利用しているSaaSのID/PWをLast Passで一元管理していたので、ある程度の情報は集約できていたのが不幸中の幸いでした。
![スクリーンショット_2021-05-26_12_14_04](https://assets.st-note.com/production/uploads/images/53287170/picture_pc_680d96bda83eb7816937bc1db7442b39.png?width=1200)
Last Pass▶︎#1 Password Manager & Vault App, Enterprise SSO & MFA | LastPass
とはいえ管理が漏れているSaaSも絶対にあるので、Last Passに登録していないSaaSは過去のコミュニケーション遡ってかき集め、スプレッドシートでリスト化しました。
結局、約60ものSaaSを利用している実態が判明しました…
②SaaS別に誰がアカウントを持っているのかを全てリスト化
SaaS一つひとつにログインし、ひたすらメンバーを確認します。
縦軸にSaaS名、横軸にメンバーという感じで①と一緒にシートにしました。
![スクリーンショット_2021-05-24_18_35_14](https://assets.st-note.com/production/uploads/images/53287553/picture_pc_5d7599bd994fe92df360ac15f7bdeb82.png?width=1200)
「このSaaS誰も使ってないのに課金してるじゃん…」みたいなことも、ここで発掘されます。
③リストが定期更新され、最新の情報を維持
⑴窓口を一本化
①②のタスクを定期的に実施するのは工数的に無理があるので、弊社では「アカウント申請フォーム」というものをGoogleフォームで作成しました。
「アカウント申請フォーム」(以下、フォームと略称)をつくり窓口を一本化することで、メンバー各々が自由にアカウントを作ってしまう状況をなくし、リストが最新の状態を維持できると考えたのです。
![スクリーンショット 2021-05-27 15.37.27](https://assets.st-note.com/production/uploads/images/53287912/picture_pc_5aaa9796521e6a74ae006860c3fff964.png?width=1200)
フォームは
・新しく利用したいSaaSがある時
・既存のSaaSアカウントを追加したい時
・既存のSaaSアカウント情報を更新したい時
・既存のSaaSアカウントを削除したい時
にメンバーがフォームから申請し、承認者が依頼事項を承認・対応します。
さらに、GoogleフォームとSlackを連携しました。
申請があるとSlackに通知されるようにに設定し、申請から対応までのタイムラグを短くしたり、対応漏れが発生しないようにしました。
![スクリーンショット 2021-05-27 15.35.50](https://assets.st-note.com/production/uploads/images/53287944/picture_pc_0cdb3e7b3083d3c45539fbfff410fdb1.png?width=1200)
GoogleフォームとSlackの連携方法▶︎Googleformからのslack通知設定方法 - Qiita
⑵月一でアカウントを棚卸し
「アカウント申請フォーム」で最新情報を維持しつつ、さらに月に一回「アカウントの棚卸し」を実施することで、承認者の対応漏れやシートの更新漏れなどを防ぎます。
「アカウントの棚卸し」で実施する具体タスクは、
①実態と申請の一致を確認(全て申請されているか)
②申請と管理シートの一致を確認(すべての申請を処理しているか)
③管理シートと実態の一致を確認(SaaSにログインしてアカウントリストを確認する)
④解約・削除の対象はあるか確認
という4つです。
■運用はうまくいったの?
いきませんでした。
「アカウントを管理する」という目的には果たせていたものの、事業部の業務フローに全く寄り添えていなかったのです。
つまり、コーポレート部門のエゴっぽくなってしまったのでした。
![スクリーンショット 2021-05-27 15.39.49](https://assets.st-note.com/production/uploads/images/53288052/picture_pc_68cb8f569361e69b628d665b76aa107e.png?width=1200)
フォームが想定通りの役割をしなかった
実態はどうだったかというと、アカウント申請フォームが稼働してから実際の申請数は、週に1〜2件申請があるかないかという感じでした。(入社があるともう少し増えたりします。)
しかし、本来想定していた「メンバーがフォームから申請し、承認者が依頼事項を承認・対応」という事前申請型フローで運用できたのは、実際の申請のうち50%程度でした。
残り50%はどうだったかというと「メンバー自身がアカウントを作成し、その報告をした」です。
つまり、事後報告になっていたということです。
報告してくれればまだいい方で、報告がなかったものももちろんありましたし、そもそもフォームを使わず直接わたしにメッセージを送ってくる場合も多々ありました。笑
なんのためにフォーム作ったんだー!と思いましたが、そりゃあスタートアップでただでさえ忙しいのに、一個アカウント作るのにいちいち申請するのなんてめんどくさいですよね…
工数が結構かかる
月一回のアカウント棚卸しは、かなり工数がかかりました。
ひと月目のアカウント棚卸し作業にかかった総工数はなんと、10時間!!
フォームがきちんと利用されていればここまでかからないのですが、フォームは想定の役割をしていないので致し方ないという結果に…
最初にも書きましたが、弊社は常時10人前後の会社です。
しかもツール申請者はそのうち2名。つまり「不明点の確認はその2名だけにすれば済む」という極めてスリムな体制規模です。
10人前後でこんだけかかるのに、もっと大きい会社はどうなっちゃうんでしょうか…
でも弊社も毎月10時間を棚卸しに費やすのは絶対ムリです。
新たな課題は見えた
では、なぜ事後報告になってしまうのかというと、原因は2つありました。
①業務委託メンバーが多い
業務委託メンバーの稼働は、基本的に定時外が多くなります。一方で、コーポレート部門は定時制なので、事前申請をするとアカウント付与までにどうしてもタイムラインが生じてしまうのです。
せっかく業務委託メンバーが作業していて「今このSaaSが必要!」となっているのに、事前申請をしないとSaaSが使えないので「明日まで待って!」は超ナンセンスですもんね。
②そもそもオンボーディングができていない
そして、この問題点はアカウント申請うんぬん以前に「作業前にきちんとオンボーディングができていないのでは」という、新たな課題の発見につながりました。
そもそもオンボーディングがちゃんとできていれば、「このSaaSがないから作業ができない!」ということを防げそうですよね。
■コーポレート課題は継続的にチューニングしていこ!
もともとの想定では、「フォームを作ってアナウンスと実施の徹底をすれば良い」と思っていました。
しかし結果は、「業務実態と乖離したフローになってしまい運用がうまくいかない」でした。
つまり、このフローのアナウンスや実施を徹底しても、おそらく仕組みとしては定着しません。
すなわち、継続的なチューニングが必須であると言えます。
継続的なチューニングを行うために、今回新たに「コーポレート施策振り返りシート」なるものを作成しました!
施策実施前後で、記入箇所が左右に分かれています。
![スクリーンショット_2021-05-27_18_07_38](https://assets.st-note.com/production/uploads/images/53288173/picture_pc_122cc093f92cd386bf090db3dc46f01d.png?width=1200)
施策実施前に目的や達成要件を定義しておくことで、実施後に改善点や定性・定量での振り返りができるフォーマットになっています。
情シスフォームの振り返りシートを公開いたしますので、参考にしてみてください!
振り返りシートのダウンロードはコチラから▼
振り返りシートテンプレートとDXERアカウント申請フォーム振り返り
■「情シスが来る」サービスを作りました!
弊社DXER株式会社は、企業を後押しする情シスに変革させるサービス「シスクル」を2021年7月14日(水)よりサービス開始いたしました!
「シスクル」は、ひとり情シスの悩みを情シス専門人材のシェアによって解決するサービスです。「情シスが来る」ので「シスクル」です。
情シス人材でお困りの方がいらっしゃいましたら、ぜひご活用ください!
詳しい情報は下記よりご覧いただけます。
企業を後押しする情シスに変革させるサービス「シスクル」
![](https://assets.st-note.com/img/1695088650653-2uSbPonC6w.png?width=1200)
この記事が気に入ったらサポートをしてみませんか?