振り返り
前編では、仕組みの土台作りについて書きました。
現状把握、管理対象の絞り込み、台帳の再設計、そして法人カード統制の導入。
これで「何があるか」は見えるようになりました。
でも、土台ができても日々の運用が回らなければ、崩壊します。
後編では、制度を回すために実施した「ワークフロー」と「入退職フロー」の運用の仕組み化を解説します。
ステップ5:ワークフローの設定(1日)
法人カード統制で、契約の「網羅性」は確保できました。カード明細を見れば、何が契約されているかは一目瞭然です。
でも、それだけでは不十分でした。
「誰が承認したのか」「なぜ契約したのか」——この2つが記録されません。半年後に「このSaaS、何のために契約したんだっけ?」となります。
だから、ワークフローが必要です。
ワークフローとカード統制の役割分担
ワークフローは「意思決定の記録」のため。カード統制は「無断契約の防止」のため。
両方あると初めて回ります。
申請フローをどう設計したか
僕が作った申請フローは、こうなっています。
①申請のタイミング
トライアル終了後、有料化する前。または有料化と同時。
②承認ルート
5万円未満:部門長 → 管理部
5万円以上:部門長 → 代表 → 管理部
最終承認者を管理部にすることで、全ての契約申請を管理部が把握できます。これにより、台帳への記載漏れを防げます。
③申請項目
サービス名、契約プラン、利用目的、管理者、更新頻度。
必須項目だけに絞りました。項目が多いと、誰も申請しなくなるからです。
トライアルはどう扱うか
ここで疑問が出ます。
「トライアル時に申請しないと漏れるのでは?」
確かに、トライアル開始時に申請すれば漏れは減ります。でも実際には、トライアルと本申込で書類や条件が違うため、2度手間になります。トライアル時に申請を求めると、現場の負担が大きくなりすぎます。
だから、こう運用しています。
①トライアル開始時:Slackの「SaaS契約チャンネル」に報告(申請は不要)
②有料化を決めた時点:freeeで正式に申請
これにより、「試してみる自由」を残しつつ、有料化する契約は確実に把握できます。
緊急時の対応
営業から「明日のプレゼンで使いたいので、今日中に契約したい」と言われたらどうするか?
答え:口頭承認OK、ただし法人カードは必ず使う。
完璧な運用より、現場が止まらない運用の方が重要です。後日申請でも構いません。
ステップ6:入退社フローの更新(1日)
管理が最も崩れやすいタイミングは、入社と退職です。
どちらも「必ず発生するイベント」であり、かつ「やらないと実害が出るイベント」。だから、入退社フローに台帳更新を組み込むことで、強制的に管理を回す仕組みを作ります。
特に退職時は、機器の回収やアカウント停止を忘れると、情報漏洩やコスト増につながります。入社時も、配布したIT機器やSaaSアカウントを記録しておかないと、後で把握できなくなります。
入社フローで追加したこと
入社時のチェックリストに以下を追加しました。
①IT機器の配布
PC、スマホ、モニター等を配布したら、その場でIT資産台帳に記録。
②SaaSアカウントの付与
SlackやGoogleワークスペース等のアカウントを付与したら、SaaS台帳の利用者数を更新。
入社は増えるだけなので、記録を忘れにくい。でも、記録しておかないと困ります。
退職フローで重要なこと
退職時のチェックリストで、特に重要なのは以下の2つです。
① IT資産台帳の更新を必須にする
退職日当日のチェック項目に「IT資産台帳の更新(状態を『返却済』に変更)」を入れることで、台帳更新が漏れなくなります。
② SaaS管理者の引き継ぎを確認する
退職者が管理者になっている契約をSaaS台帳で確認し、引き継ぎ先を決めます。これをしないと、後から解約できなくなります。
実際、ある退職者が管理者になっているSaaSの解約手続きに1ヶ月かかったことがあります。サポートに「契約者本人からの連絡が必要」と言われ、結局、書類のやり取りで時間を取られました。
だから、退職前に必ず引き継ぎを確認します。
アカウント削除の注意点
退職後のアカウント削除には注意が必要です。削除すると取り返しがつかないものがあります。
特に注意が必要なのは:
Googleワークスペース:ドライブのデータが消える。所有権を移管してから削除。
Slack:DM履歴が消える。保存が必要なやり取りがないか確認。
メールアカウント:サービスのIDやメールアドレスとして使われていないか確認。
これらをチェックリストに明記しておくことで、削除ミスを防げます。
運用開始後に出た問題と対処法
実装後、いくつか問題が出ました。
問題1:「急ぎで契約したい」という要望
営業から「明日のプレゼンで使いたいので、今日中に契約したい」と言われました。でもワークフローの承認に時間がかかる。
対処法:緊急時は口頭承認OK(後日申請)。ただし、法人カードは必ず使う。
学び:完璧な運用より、現場が止まらない運用の方が重要。
問題2:トライアル時にカード情報を登録し忘れる
トライアル開始時に法人カード登録を忘れ、有料化時に個人カードで立替してしまう。
対処法:Slackに「SaaS契約チャンネル」を作成。トライアル開始時に報告してもらい、管理部がカード情報登録をサポート。
学び:「報告してもらう」だけでなく、「管理部が代わりにやる」方が現場の負担が減る。
この仕組みを回すための3つのコツ
1年運用してわかった、続けるためのコツです。
コツ1:完璧を求めない
最初から100%を目指すと、必ず崩壊します。台帳の項目が抜けていてもOK。月次チェックはしない。
最低限、法人カード統制だけ守れば、8割は防げます。
コツ2:現場に負担をかけない
「管理のために現場が止まる」は本末転倒です。カード情報登録は管理部がやる。入退社時のチェックリストは、人事が主導。
管理部が手を動かす前提で設計することが重要です。
コツ3:定期的に見直す
年に1回、以下を確認します。
法人カード明細と台帳の差分、使われていないSaaSの洗い出し、入退社フローが守られているか。
完全に放置すると、また崩壊します。
まとめ
前編・後編でやったことを振り返ります。
前編で作った土台
現状把握、管理対象の絞り込み、台帳の再設計、法人カード統制の導入。
後編で仕組み化したこと
ワークフローで意思決定を記録。入退社フローで台帳更新を強制化。
かかった時間
約2〜3ヶ月
かかったコスト
ほぼゼロ(法人カードの年会費のみ)
得られた効果
SaaS把握率 60%→100%、台帳更新の負担激減、無駄な契約削減 年間約10万円
最後に
この方法が向いているのは、小規模な会社のバックオフィス担当で、管理が止まっていて、どうにかしたいけど、専用システムを導入する予算はない人です。
小規模で、手が回っていない会社だからこそ、この仕組みが機能します。
管理は、完璧さより継続性。
潰れない仕組みを作ることが、最優先です。
こんな支援ができます
就業規則の新規作成・見直し、勤怠管理の整備、社員への展開設計、経営陣との合意形成支援まで一気通貫で対応できます。「何から手をつければいいか分からない」という段階からでも歓迎です。まずは現状の課題整理からお気軽にご相談ください。
.png)
