部署が増えるたびにツールが増える会社のIT導入申請ルールの作り方（野良SaaS増殖を防ぐ最低限の申請フローの設計）

新しい部署ができるたびに、新しいツールが増えていく。カスタマーサポート部門が発足すればチケット管理ツールが、マーケティング部門が発足すればMAツールが、それぞれ独自の判断で契約されます。10-30人規模の会社にとって、これは組織が成長している自然な結果です。しかし、この「増える」プロセスに何のルールもなければ、数年後には誰も全体像を把握できない、収拾のつかない状態に陥ります。

このガイドでは、部署が増えるたびにツールが無秩序に増えていく状態を防ぐための、最低限のIT導入申請フローの設計方法を解説します。重要なのは、現場の判断スピードを損なわない範囲で、必要最小限のチェックポイントだけを設けることです。過度に厳格な申請フローは、かえって「申請せずにこっそり導入する」という、より悪い状態（野良SaaS化）を誘発してしまいます。

なぜ「申請なし」が危険なのか: 野良SaaSの正体

各部署が自由な裁量でツールを選定・契約できる状態は、一見スピーディで効率的に見えます。しかし、この自由度が野放しになると、いわゆるシャドーIT、俗に「野良SaaS」と呼ばれる状態が生まれます。会社の管理部門が把握しないまま、現場が独自に導入・利用しているクラウドサービスのことです。

野良SaaSが積み重なると、次のような具体的な問題が発生します。

• 顧客の個人情報や機密情報が、セキュリティレベルの不明なツールに入力されてしまう
• 契約したことを忘れられ、使われないまま費用だけが発生し続ける（いわゆる幽霊契約）
• 退職者のアカウントが、総務も把握していないツールに残り続ける
• 似た機能のツールを部署ごとに重複契約し、コストが無駄になる
• 万一の情報漏えい事故の際、そもそもどんなツールにどんなデータが入っているか、会社として把握できていない

これらの問題の根本原因は、「ツールを導入する際に、誰かが最低限のチェックをする仕組みがない」ことにあります。申請フローは、この最低限のチェックを機能させるための仕組みです。

申請フローを「厳しくしすぎる」ことの逆効果

申請フローの必要性を理解した経営者や総務担当者が陥りやすい失敗が、フローを厳格にしすぎることです。稟議書の作成を必須にし、複数人の承認を経なければ導入できないような重厚なプロセスを作ってしまうと、現場は「無料プランなら申請しなくていいだろう」「とりあえず試すだけだから後で申請すればいい」といった形で、申請そのものを回避するようになります。

10-30人規模の会社にとって、申請フローの目的は「導入を止めること」ではなく、「導入の実態を把握し、最低限のリスクチェックを通すこと」です。この目的を見失い、承認プロセスの重厚さそのものが目的化してしまうと、かえって野良SaaSを助長する結果になりかねません。

申請フローの設計にあたっては、次の原則を意識してください。

「現場の判断スピードを尊重しつつ、会社として最低限知っておくべき情報だけは必ず拾う」

この原則に基づき、申請フローは「重すぎず、軽すぎない」バランスを目指す必要があります。

申請が必要なケースと不要なケースを線引きする

すべてのツール導入に一律の申請を求めると、現場の負担が大きくなりすぎます。まず着手すべきは、「どんな場合に申請が必要か」の線引きです。10-30人規模の会社であれば、次のような基準が現実的な出発点になります。

この基準はあくまで一例であり、会社の業種や扱う情報の性質によって調整が必要です。例えば個人情報を大量に扱う業種であれば、無料プランであっても情報の取り扱いに関するチェックは必須にすべきでしょう。逆に、社内の業務効率化のためだけに使う、機密情報を扱わない小規模なツールであれば、より緩やかな基準でも構いません。

重要なのは、基準を明文化し、現場が「これは申請が必要かどうか」を自分で判断できる状態を作ることです。基準が曖昧なままだと、結局「よく分からないから聞いてみよう」という総務への相談が増え、総務が「なんとなく情シス」になった30人の会社の役割整理で扱った兼任負荷の問題が再燃してしまいます。

最低限の申請フォーマット: 5項目で十分

申請フローを設計する際、申請フォーマット自体も最低限に絞り込むことが重要です。項目が多すぎるフォーマットは、それだけで申請への心理的ハードルを上げてしまいます。次の5項目程度に絞り込むことをお勧めします。

1. ツール名・提供元: 何のサービスをどこから導入するか
2. 導入目的: 何のために使うか（1〜2行で簡潔に）
3. 利用予定人数と部署: 誰が使うか
4. 取り扱う情報の種類: 個人情報・機密情報を扱うかどうか
5. 月額（年額）費用の概算: だいたいの費用感

この5項目であれば、申請者は5分程度で記入を終えられます。チャットツールの専用フォームやシンプルなオンラインフォームで運用すれば、紙の稟議書のような手間もかかりません。

承認者は誰にするか: 兼任者に背負わせすぎない設計

申請フローを設計する上で悩ましいのが、「誰が承認するか」という点です。10-30人規模の会社では、この役割が総務担当者1人に集中しがちですが、これは総務が「なんとなく情シス」になった30人の会社の役割整理で扱った「なんでも屋」化を助長するリスクがあります。

承認プロセスを設計する際は、次のように役割を分担することをお勧めします。

• 形式チェック（総務担当者）: 申請フォーマットが埋まっているか、必要な情報が揃っているかの確認
• セキュリティ・情報管理の観点のチェック（経営者、または情報管理の責任者）: 個人情報や機密情報を扱う場合の可否判断
• 予算の妥当性チェック（経営者、または経理責任者）: 一定額を超える費用の場合の予算承認

この分担により、総務担当者は「形式が整っているかの窓口」という限定的な役割に留まり、最終的な可否判断は経営者が担う構造になります。この構造は、部署が増えるたびにツールが増える会社のIT導入申請ルールの作り方自体のタイトルにもある「野良SaaS増殖を防ぐ」ことと、「総務担当者に責任を集中させすぎない」ことの両立を実現します。

申請フローの実際の流れ

具体的な申請フローの流れを、フローチャート形式で整理します。

1. 現場が新しいツールの導入を検討する
2. 申請が必要な条件に該当するか、現場自身が基準に照らして判断する
3. 該当する場合、5項目の申請フォームを提出する
4. 総務担当者が形式チェックを行う（1営業日以内を目安）
5. 個人情報・機密情報を扱う場合、または一定額を超える場合は、経営者の確認を経る
6. 承認され次第、現場が契約・導入を進める
7. 導入後、部署ごとに違うツールを使う10-30人組織の管理台帳の作り方で紹介した管理台帳に自動的に反映される

このフローで重要なのは、ステップ4と5の所要時間を可能な限り短く保つことです。申請してから何日も承認が下りない状態が続くと、現場は「申請しても意味がない」と感じ、フローを迂回するようになります。目安として、形式チェックのみで完結する軽微な申請は1〜2営業日以内、経営者の確認が必要な申請でも1週間以内の回答を目標にすることをお勧めします。

「事後申請」を許容する設計にする

厳格な事前承認だけを前提にすると、緊急性の高い状況で現場が対応できなくなるケースが出てきます。例えば、取引先とのやり取りで急遽必要になったツールや、無料トライアルとして試しに使い始めたツールなどです。

こうした状況に対応するため、申請フローには「事後申請」の枠も用意しておくことをお勧めします。緊急で導入したツールについては、導入後1週間以内に申請フォームを提出することを義務付ける、という形です。事前承認を原則としつつ、現実の業務スピードに配慮した柔軟性を持たせることで、フローの形骸化を防げます。

ただし、事後申請の枠を設ける場合は、「事後申請さえすれば何でも許される」という誤解を生まないよう、個人情報を扱う場合など特に重要なケースについては、事後申請であっても速やかに経営者への報告と、必要であれば利用中止の判断を行う旨を明記しておく必要があります。

既存の「申請なしで導入済み」のツールへの対応

新しい申請フローを導入する際、すでに申請なしで導入されているツールをどう扱うかも検討が必要です。過去に遡って全て問題視すると、現場は「今さら言われても」と反発しやすくなります。

現実的な対応としては、新しいフローの導入と同時に「これまで導入したツールも、今回まとめて事後申告してください」という一斉棚卸しの機会を設けることです。この際、「過去の導入を責めるためではなく、これから健全に運用していくために、現状を正確に把握したい」という趣旨を明確に伝えてください。この一斉棚卸しは、部署ごとに違うツールを使う10-30人組織の管理台帳の作り方で紹介した台帳作りのプロセスと、そのまま組み合わせて実施できます。

セキュリティチェックの最低ライン

申請フローの中でも特に重要なのが、個人情報や機密情報を扱うツールに対するセキュリティチェックです。個人情報保護委員会「中小企業における個人情報保護法への対応について」でも、中小企業においても個人情報の適切な管理体制の整備が求められており、新しいツールに個人情報を入力する際は、そのツールの提供元がどのようなセキュリティ対策を講じているかを事前に確認する姿勢が重要とされています。

10-30人規模の会社で、専門的なセキュリティ監査を毎回実施することは現実的ではありません。最低限、次のようなチェック項目を申請フォームに含めておくことをお勧めします。

• 提供元の会社は実在し、プライバシーポリシー・利用規約が公開されているか
• データの保存場所（国内か海外か）が明記されているか
• 個人情報を入力する場合、暗号化通信（HTTPS）に対応しているか
• 退会・解約時にデータを削除できる仕組みがあるか

これらはあくまで最低限のチェックであり、より高度なセキュリティ要件が求められる業種であれば、追加の確認項目を検討する必要があります。それでも、この最低限のチェックすら行わずにツールを導入する状態と比べれば、大きなリスク低減効果が期待できます。

申請フローの定着に向けた周知の工夫

どんなに優れた申請フローを設計しても、現場に周知され、実際に使われなければ意味がありません。定着させるための工夫として、次のような取り組みが有効です。

• 新入社員のオンボーディング資料に、申請フローの説明を組み込む
• 各部署のミーティングで、フロー導入の背景と目的を直接説明する機会を設ける
• 申請フォームへのリンクを、社内チャットツールの分かりやすい場所（ピン留めなど）に常時掲示する
• 実際に申請があった際は、できるだけ早く反応し、「申請してよかった」という体験を積み重ねてもらう

特に最後の点は重要です。申請フローを導入した直後は、現場も慣れておらず、申請するかどうか迷うケースが多く出てきます。そうした際、総務担当者や経営者が迅速かつ丁寧に対応することで、「申請すればスムーズに進む」という信頼が積み上がり、フローが自然と定着していきます。

申請フローの運用状況を定期的に振り返る

申請フローは一度作って終わりではなく、定期的に運用状況を振り返り、改善していく必要があります。振り返りの際は、次のような観点でチェックしてみてください。

• 実際にどれくらいの申請が上がってきているか（少なすぎる場合、形骸化・迂回の兆候かもしれません）
• 承認までにかかった時間は妥当か
• 申請なしで導入されていたツールが、後から発覚したケースはないか
• 現場から「申請フローが使いにくい」という声は上がっていないか

これらの振り返りは、部署ごとに違うツールを使う10-30人組織の管理台帳の作り方で紹介した台帳の定期棚卸しと同じタイミング（例えば四半期に1回）で実施すると、業務負担を抑えながら継続しやすくなります。

申請フローと業務範囲の整理はセットで進める

このガイドで紹介した申請フローは、単独で機能するものではなく、総務担当者の業務範囲の整理と密接に関連しています。申請フローがあっても、「誰が最終承認者か」「総務担当者はどこまで対応するか」が曖昧なままでは、結局フローが機能しません。

業務範囲の整理と責任の所在の明確化については、総務が「なんとなく情シス」になった30人の会社の役割整理で詳しく解説しています。申請フローの設計と業務範囲の整理は、どちらか一方だけでは効果が限定的であり、両方を組み合わせて初めて、持続可能な仕組みになります。

申請フォームのサンプル: 実際の文面イメージ

具体的なイメージを持てるよう、実際の申請フォームの文面例を示します。社内チャットツールの簡易フォーム機能や、オンラインフォームで運用する場合の項目立てです。

新規ツール導入申請

>

1. ツール名・提供元: （例）○○チャット、株式会社△△

2. 導入目的: （例）カスタマーサポート部内の情報共有を効率化するため

3. 利用予定人数・部署: （例）カスタマーサポート部5名

4. 取り扱う情報: 個人情報を扱う／扱わない（該当する方を選択）。扱う場合、具体的にどんな情報か記載してください

5. 月額（年額）費用の概算: （例）月額3,000円

>

※ 提出後、1〜2営業日以内に総務から確認のご連絡をします。個人情報を扱う場合や費用が5,000円を超える場合は、追加で経営者の確認をお願いすることがあります。

このように、記入者が迷わないよう各項目に記入例を添えておくと、フォームの完成度が申請のしやすさに直結します。特に「取り扱う情報」の項目は、判断に迷う申請者が多いため、「個人情報とは具体的に何を指すか」の簡単な説明（氏名・メールアドレス・電話番号・購入履歴など）を併記しておくと親切です。

業種別に見る、申請フローのカスタマイズ観点

申請フローの基本設計は業種を問わず共通ですが、扱う情報の性質によって、重視すべきチェックポイントは変わってきます。

• 顧客の個人情報を多く扱う業種（小売・サービス業など）: 個人情報を扱うツールの申請ハードルをやや高めに設定し、データの保存場所や暗号化の有無を必須確認項目にする
• 取引先の機密情報を扱う業種（製造業の受発注データなど）: 取引先との契約上、情報管理に関する条項がある場合は、申請フォームにその条項への抵触有無を確認する項目を追加する
• 社内業務効率化が中心の業種: 個人情報を扱わない社内向けツールについては、申請のハードルをより低く設定し、スピードを優先してもよい

自社がどのカテゴリに近いかを踏まえ、基本の5項目フォーマットに、必要な確認項目を1〜2個追加する形でカスタマイズすることをお勧めします。項目を追加しすぎると当初の「軽やかさ」が失われるため、追加は最小限に留めてください。

申請フローが機能しているかを測る指標

申請フローを導入した後、それが実際に機能しているかを客観的に把握するために、次のような指標を定点観測することをお勧めします。

これらの指標は、完璧な数値を目指すものではなく、傾向をつかむためのものです。四半期ごとの棚卸しのタイミングで、これらの指標を簡単に振り返るだけでも、フローの形骸化を早期に察知できます。

小規模だからこそ、フローの「軽さ」が生命線

最後に強調しておきたいのは、10-30人規模の会社にとって、申請フローの「軽さ」こそが最も重要な設計原則だという点です。大企業であれば、情報システム部門や法務部門が専任で申請の審査に当たれますが、10-30人規模の会社では、審査に割ける人的リソースはごくわずかです。

そのため、このガイドで紹介した5項目のフォーマットや、1〜2営業日での回答目標は、単なる理想ではなく、実際に運用を継続できるための現実的なラインとして設定しています。フローを設計する際は、常に「これは総務担当者や経営者が、無理なく継続して運用できる分量か」を自問しながら、項目や承認ステップを絞り込んでいく姿勢を持ち続けてください。

申請フローに反対する声への向き合い方

新しい申請フローを導入する際、現場から「今までスピーディにできていたのに、面倒になった」という反対の声が上がることは珍しくありません。この声に対しては、頭ごなしに「ルールだから守ってください」と押し切るのではなく、反対の背景にある懸念を丁寧に聞き取ることが重要です。

よくある反対理由とその向き合い方を整理します。

「無料トライアルを試すだけなのに、申請が必要なのは大げさすぎる」

この場合、事後申請の枠を明確に周知することで解消できる懸念です。トライアル段階では事後申請で構わないこと、正式契約に進む段階で改めて確認することを、フローの説明時に明記しておくとよいでしょう。

「承認が遅くて、商談のタイミングを逃しそうになった」

このケースは、承認プロセスの運用に問題がある可能性が高いサインです。承認者（総務担当者や経営者）の対応が遅れている原因を確認し、必要であれば承認フローの簡略化や、承認者の一時的な増員を検討してください。

「そもそも何のためにこのルールがあるのか分からない」

背景の説明が不十分なまま、ルールだけが降りてきた場合に起こりがちな反応です。導入時に、野良SaaSが引き起こす具体的なリスク（情報漏えい、コストの無駄、退職者アカウントの放置など）を、自社の実例（あれば）や一般的な事例を交えて丁寧に説明する機会を設けることをお勧めします。

申請フローとセキュリティインシデント対応の関係

申請フローを整備しておくことは、万一情報漏えいなどのセキュリティインシデントが発生した際の対応スピードにも直結します。どのツールに、どんな情報が、いつから入力されているかが台帳と申請記録から即座に把握できれば、インシデント発生時の影響範囲の特定や、関係者への説明が格段にスムーズになります。

逆に、申請フローが存在せず、どんなツールが社内に存在するかすら把握できていない状態でインシデントが発生すると、まず「どこに何のデータがあるか」を洗い出すところから始めなければならず、対応が大幅に遅れます。IPAの資料でも、情報資産の把握が情報セキュリティ対策の出発点として位置づけられていることは、繰り返し強調しておく価値があります。申請フローは、平時の業務効率のためだけでなく、有事の初動対応スピードを左右する備えでもあるという認識を、社内で共有しておいてください。

将来の規模拡大を見据えた申請フローの育て方

10-30人規模で整備した申請フローは、会社がさらに成長して30人、50人、100人と規模が拡大していく過程で、徐々に見直しが必要になっていきます。このガイドで紹介したフローは、あくまで10-30人規模、つまり専任の情シス担当がまだ置かれていない段階を前提とした、最低限の設計です。

会社の規模が拡大し、専任の情シス担当や情報システム部門が置かれる段階になれば、申請フローもより体系的な仕組み（例えば、システム化されたワークフローツールの導入、セキュリティ基準のより詳細な審査項目の追加など)へと発展させていくことになります。重要なのは、10-30人規模の段階で「何もないゼロの状態」から「最低限のルールがある状態」へ移行しておくことです。この土台があれば、会社が成長して本格的な仕組みが必要になった際も、ゼロから設計するのではなく、既存のフローを拡張する形でスムーズに移行できます。

申請フローを設計する際は、常に「今の規模に合った最低限」を意識しつつ、将来の拡張を妨げない設計（例えば、申請データを蓄積しておけば、将来ツールを導入する際にそのまま移行できる形式にしておくなど）を心がけておくと、後々の手戻りを減らせます。

申請フロー導入初期に総務担当者が意識すべきこと

申請フローを導入した直後の数ヶ月間は、総務担当者にとって最も負荷が高まりやすい時期です。新しい仕組みに現場が慣れていないため、問い合わせや確認の依頼が一時的に増える傾向があります。この初期の負荷増加を見越して、導入直後の1〜2ヶ月は、他の業務の優先順位を意識的に下げるなど、経営者と事前に調整しておくことをお勧めします。

また、導入初期は完璧な運用を目指しすぎないことも重要です。フォーマットの項目が実態に合っていない、承認の判断基準が曖昧な点が見つかるなど、運用しながら気づく改善点は必ず出てきます。こうした気づきをその都度メモしておき、四半期に1回程度のタイミングでまとめて見直す機会を設けることで、フローを実態に合わせて育てていくことができます。最初から完璧なフローを目指すのではなく、「まず動かしてみて、少しずつ調整する」という姿勢で臨むことが、結果的に定着への近道になります。

まとめ: ルールは「止めるため」ではなく「知るため」にある

部署が増えるたびにツールが無秩序に増えていく状態は、10-30人規模の会社が組織として成長している証でもあります。この成長のスピードを止めることなく、会社として最低限知っておくべき情報だけを確実に拾い上げる仕組みが、このガイドで紹介した申請フローです。

申請フローの目的は、現場の判断を制限することではなく、「何が、どこで、どんな情報を扱いながら動いているか」を会社として把握し続けることにあります。この把握があって初めて、セキュリティリスクへの対応も、コストの最適化も、そして万一のトラブル時の迅速な対応も可能になります。重厚な承認プロセスを目指すのではなく、5項目程度の軽やかな申請と、迅速な確認体制から始めてみてください。

野良SaaSは、誰か1人の怠慢によって生まれるものではなく、組織が成長する過程で自然発生的に積み重なっていくものです。だからこそ、性善説に立ちながらも、最低限の仕組みで実態を把握し続ける姿勢が、10-30人規模の会社には求められます。自社の状況を客観的に把握したい場合はひとり情シス危険度診断も、あわせてご活用ください。