自作が増える背景には理由がある
部署ごとに自作ツールが増えるのは、担当者が規律を欠いているからではありません。正式な経路が遅く、自作のほうが速いという条件が揃っているからです。
最初に確認しておきます。自作すること自体は正当な選択です。表の第12章に自作に向く条件が示されているとおり、多くの用途では自作が最も速く安い手段になります。この章で扱うのは、リスクが認識されないまま数が増える構造です。
型1 ― リスクの説明が省かれる
自作を推奨する説明の中で、省かれやすい項目を挙げます。省略は多くの場合、意図的なものではなく説明する側もリスクを知らないことから生じます。
| 説明 | 省かれている前提 |
|---|---|
| 「数時間で作れます」 | 機密度の判定、権限設計、実データでの確認、運用の受け皿の工数 |
| 「社内向けなので安全です」 | URLを知る誰でもアクセスできる状態は、退職者や異動者も含む |
| 「文書を渡すだけで要約できます」 | 文書に含まれる個人情報も同時に送信される |
| 「動いたら完成です」 | 引き継ぎ資料がなければ、作った本人以外は変更できない |
| 「必要なくなったら消せばいい」 | 業務に組み込まれた後は消せない |
実務的な対処は、作る前に5点を決めることを手順にすることです(表の第12章)。機密度の判定、利用者と権限、置き場所と引き継ぎ資料、止める条件、相談先。この5点は作業ではなく判断であり、所要は30分程度です。
型2 ― シャドーIT化を助長する社内の構図
情報システム部門が把握していないツールが増える背景には、いくつかの組織的な要因があります。
- 申請すると時間がかかる ― 承認に数週間かかる状態では、申請せずに使う判断が合理的になります。
- 申請すると止められる ― 登録することに利益がなく、制限だけがある場合、登録されません。
- 「AI活用の推進」が組織目標になっている ― 推進が評価される状況では、統制の指摘が歓迎されません。
- 個人で契約できる ― クレジットカードで完結するため、調達の手続きを経ません。
- 作ってから相談すると承認されやすい ― 完成したものは止めにくいため、先に作る動機が生じます。
5番目が構造的に厄介です。事後承認のほうが通りやすい状態は、事前相談を不利にします。この非対称を解消しないと、把握は進みません。
対処 ― 登録に利益がある状態を作る
禁止では止まりません(表の第12章)。機能する設計は次の形です。
- 登録のみで始められる範囲を明示する ― 承認ではなく登録。即時に始められます。
- 登録すると支援を受けられる ― 権限設計の相談、共通の仕組みの利用、費用の集約。
- 禁止事項を数項目に絞る ― 「個人情報を含むデータを未承認のサービスに入力しない」など具体的に。
- 事前相談を有利にする ― 相談した案件は優先して支援するなど、順序による利益差を作ります。
型3 ― 指摘されても放置される
技術的な不備が判明しても修正されない状態には、組織的な理由があります。
| 理由 | 実際に起きていること | 対処 |
|---|---|---|
| 担当者がいない | 作った人が異動・退職し、触れる人がいない | 引き継ぎ用の1ページを作成の条件にする |
| 止められない | 業務に組み込まれており、停止すると業務が止まる | 代替手順を用意してから対処する |
| 修正の工数が確保されない | 新規の取り組みが優先される | 棚卸しの結果を 年間の計画に載せる |
| 把握されていない | そもそも点検の対象に入っていない | 年1回の棚卸しを既存手続きに組み込む |
| リスクが伝わらない | 「社内向けだから」で判断が止まる | 扱うデータの区分で判定基準を示す |
4番目が前提になります。把握されていないものは点検も修正もできません。だから棚卸しが最初の作業になります。
型4 ― 引き継ぎを作らないまま量産する
自作ツールが増えるとき、引き継ぎ資料が伴わないことが多くあります。理由は単純で、動くものができた時点で目的が達成されるためです。
しかし引き継ぎ資料の不在は、時間が経ってから請求が来る性質の負債です。
- 担当者の異動時に、そのツールが業務に組み込まれたまま触れない状態になる
- 不備が判明しても修正できない
- 類似のツールが別の担当者によって作られる(重複投資)
- 使われているのか分からないまま維持される
対処は表の第12章に示したとおり1ページの記録です。目的・動かし方・変更のしかた・依存しているもの・連絡先・止める条件。合計で1ページに収まり、作成に要するのは30分程度です。
自作ツールについて「作った本人以外に動かし方が分かるか」を確認してください。分からない場合、そのツールは業務に組み込まれた時点で組織のリスクになります。加えて、APIキーなどの秘密情報がコードに埋め込まれていないかを確認してください。コードを共有した時点で外部に渡るため、影響が広範になります(表の網羅版 第21章「セキュリティ」)。
型5 ― 数字を出すツールの前提が共有されない
集計や計算を行う自作ツールでは、前提の違いが数値の不一致として現れます。この不一致は、どのツールも「正しく」動いている状態で発生します。
典型的な前提の差を挙げます。
- 締め日の扱い(月末か、営業日基準か)
- 対象期間の境界(当日を含むか)
- 除外条件(キャンセル、返品、社内取引)
- 単位(税込か税抜か、箱数か個数か)
- 参照するデータの取得時点
対処は、計算の前提を画面に表示させることです(表の第12章)。「対象期間・除外条件・締めの扱い」を出力に併記するだけで、不一致の原因の切り分けが容易になります。
朝凪精機の経理課では、春に若手が生成AIで作った「出張の日当を聞くと答えてくれるツール」が重宝されていました。作った本人は十月に第二工場へ異動し、一月に規程が改定されると、ツールは古い金額を答えるようになります。改定後に3人が古い日当で精算を出していました。動かし方の記録はなく、日当と宿泊費の上限はコードの3か所に直接書かれていたため、経理課では誰も中を開けられず、外部の業者に直してもらう見積もりを取ろうとしていました。推進室に登録して相談したことで、情報システム課の倉田が異動先の本人と電話をつなぎ、30分で直しました。作成時に「目的・動かし方・変更のしかた・依存・連絡先・止める条件」の6項目を1ページ書いておけば、部内で対応できた作業でした。作成に要する時間は30分程度です。
この場面は網羅物語之巻 第10章「野良ツール四十七本」に出てきます。
個別の自作が増える根本原因
最後に、この章の型に共通する背景を扱います。個別の自作が増える背景には、共通の仕組みが用意されていないという原因があることが多いのです。
各部署が独立して作っているものを並べると、重複が見えます。
- 社内文書を検索して回答する仕組み
- 認証と権限の管理
- AIサービスへの接続と費用の集約
- プロンプトのテンプレート
- ログの記録
これらを中核組織が共通の仕組みとして提供すると、各部署は設定で使えるようになります(表の網羅版 第8章「組織・人材・チェンジマネジメント」)。結果として個別の自作が減り、権限設計と費用管理も一元化されます。
この対処は、統制の強化ではなく手間の削減として現場に伝わります。だから協力が得られます。