「作れる人」に依存した瞬間に詰む——AIで社内ツールが乱立しはじめた会社の話
- ▶ AIで「作るコスト」が激下がりした一方、「持ち続けるコスト」は1ミリも下がっていないという話
- ▶ 社内で乱立しはじめたAIツール・GAS・拡張機能を、情シスが全部巻き取ると死ぬ理由
- ▶ オーナーシップが「設計」ではなく「重力」で決まってしまう構造と、その止め方
- ▶ 情シスのポジションを「代わりに作る人」から「基準を出す人」に変える具体策
AI活用に前のめりな、数百名規模の会社での話だ。
社内のあちこちで、エンジニアやIT寄りの人がAIを使ってGASやブラウザ拡張、ブックマークレットを組み合わせた「便利な仕組み」を作りはじめた。一個一個は本当に役に立つ。手作業が消える。みんな喜ぶ。ここまではいい話だ。
問題は、その人が異動・退職・契約終了でいなくなった瞬間に起きる。
「これ、誰が直せるんですか？」
誰も手を挙げない。中身を理解している人間がいないからだ。そして業務にがっつり組み込まれているから、止まると「なんとかしてくれ」が情シスに飛んでくる。中身を知らない情シスは、解読から始めるしかない。
▼AIは「作るコスト」だけ下げて、「持ち続けるコスト」を下げていない
ここが今回の核心だ。
AIによって、社内ツールを作るコストは劇的に下がった。今まで「エンジニアに依頼して、要件詰めて、何週間か待って」だったものが、やる気のある一人が午後イチで作れてしまう。これは純粋にすごい。
だが、持ち続けるコスト——運用・保守・バグ対応・仕様の把握・オーナーシップ——は1ミリも下がっていない。むしろ「作れる人」が増えた分、世の中に存在する野良ツールの総量は爆発的に増える。作るのが速くなった結果、保守すべき対象が積み上がっていく。
これから：「抜けた後も誰かが運用できる形で作ったか＝偉い」
評価軸がここで完全に入れ替わる。作れること自体は、もう価値の中心じゃない。
▼オーナーシップは「設計」ではなく「重力」で決まってしまう
一番まずいのはこれだ。
社内ツールのオーナー（最終的に責任を持つ人）が、誰がどう決めたわけでもなく、「巻き込まれた側」に勝手に落ちてくる。
自分の経験でもあった。電子契約サービスと別システムのデータ連携を「こうすればできますよ」と情シス側から提案した。実際に形になって、現場の人が作ってくれた。いい話だ。だが結局、メンテナンスは情シス側に残った。提案して、入り込んだから、持ち物になった。
ヘルプデスクの自動化も、ワークフローの自動連携も、たいてい同じ流れをたどる。「入り込んだ側が、入り込んだものの持ち主になる」。設計思想で決まっているわけじゃない。物理法則みたいに、重力で落ちてくる。
▼情シスが全部巻き取ると詰む。でも事業部に丸投げしても詰む
じゃあ事業部側に持たせればいいかというと、そう単純でもない。とくに人手の少ない会社だと「事業部側にメンテできる人がいる」という前提が成り立たない。「どこまで任せきれるんだろう」を突き詰めると、だいぶ手前で「やっぱりこっちが持つか…」に着地しがちだ。
そして「早く作ってあげる」を優先して情シスが作ると、こうなる。
- ▶ プロセスもメカニズムも事業部が知らない
- ▶ だから「バグりました」の連絡が常に情シスに来る
- ▶ 情シスがまた直す → さらに依存が深まる
- ▶ これが無限に増えていく（AI時代はもっと増える）
このスパイラルに一度ハマると抜けられない。だから「早く作ってあげる」の誘惑に、最初の段階で勝たないといけない。
▼正解に近かった一人の判断：あえてコードを書かなかった
同じ会社で、業務効率化を担当していた人の判断が、自分は一番きれいだと思っている。
その人はゴリゴリのエンジニアで、コードで書けば一瞬で済むような自動化も多かった。だが、あえてノーコードツール（Zapier系）で組むことを選んでいた。理由を聞いて納得した。
コードの方が速いし美しい。でもそれは「作るコスト」の話でしかない。彼が見ていたのは「持ち続けるコスト」のほうだった。だから、自分しかわからない作り方を意図的に避けた。
技術選定の良し悪しじゃない。「自分がいなくなった後」を起点に逆算しているかどうか。ここが、属人化していく作り方との決定的な分かれ目だ。
▼情シスのポジションを「作る人」から「基準を出す人」に変える
ここまでを踏まえて、情シスが取るべきスタンスははっきりしている。代わりに作る人をやめる。その代わり、判断基準を公開して「これを見たらやれるよね？」でとどめる。
1. 作る前に「運用オーナー」を決めさせる
作ってからオーナーを探すと、重力で情シスに落ちてくる。だから順番を逆にする。「これ、誰が運用オーナー？」を作る前に必ず確認する。決まらないなら作らせない、くらいでいい。
2. 業務必須かどうかで、見る範囲をはっきり分ける
| ツールの位置づけ | 情シスの関与 |
|---|---|
| 業務のワークフローに組み込まれている（止まると業務が止まる） | 情シスも見れる範囲に置く。利用ツールのリストにオーナー・メンテ条件を明記して管理 |
| 特定の人・部署の便利ツール（止まっても業務は回る） | 正直もう自分たちで管理してもらう。情シスは見ない |
この線引きをしておくと、何でもかんでも情シスに飛んでくる状態を防げる。「業務必須なら、そもそもちゃんとシステム化する流れに乗せるべき」という別の議論にもつながる。
3. 利用許可の「条件」として運用ルールを最初に握る
ブックマークレットやGASを許可するとき、利用可否の判断とセットで条件を握っておく。「誰が管理するのか立ててほしい」「メンテは情シスではやらないからお願いします」。これを利用条件として最初に入れておくと、後から揉めない。
ありがちな最悪のパターンは「業務で毎日使ってて止められない」「エラーが出て困ってる」「直せる人がいない」の三重苦。これは依存しきってから気づくから詰む。だから「一定期間以上使うならシステム化を検討してね」を、作る前から言い続けるしかない。
▼AIコードレビューにも「システム化を促す一言」を仕込む
具体的な仕込みどころとして、AIによるコードレビューの仕組みがあるなら、レビュー項目に「これ、システム化を検討すべき規模になってない？」を促す文言を入れておくのがいい。
コードの良し悪しをレビューするだけでなく、「作りっぱなしで野良化しそうな兆候」を作り手本人に気づかせる。レビューのタイミングは、作り手が一番素直に受け止められる瞬間だ。ここに運用観点を一行混ぜるだけで、乱立の速度はだいぶ変わる。
▼小規模な会社ほど、この問題はエグくなる
最後に、これは情シス不在のスタートアップ・中小企業ほど深刻になる、という話をしておきたい。
大企業なら「とりあえずインフラチームで受ける」という受け皿がまだある。だが50〜300名規模で情シスが手薄な会社には、その受け皿すらない。各事業部に「詳しい人」も「BizOps的な人」もいない。
そういう会社で、やる気のある一人がAIで全員依存の仕組みを作って、その人が抜ける。すると文字通り、誰もいなくなる。
▼まとめ
- ▶ AIは「作るコスト」を激下げしたが、「持ち続けるコスト」は下げていない。むしろ保守対象が増える
- ▶ オーナーシップは設計ではなく重力で決まる。「入り込んだ側」に勝手に落ちてくる
- ▶ 情シスが全部巻き取ると死ぬ。だが小規模な会社では事業部に丸投げもできない
- ▶ だから「作る前に運用オーナーを決める」「業務必須かどうかで関与範囲を分ける」「利用条件として運用ルールを最初に握る」
- ▶ 情シスは「代わりに作る人」をやめ、「基準を出す人」に立ち位置を変える
- ▶ 一番大事なのはサプライズにしないこと。「いずれシステム化してね」を作る前から言い続ける