「最近、うちの若手がAIを使って便利なツールを作ったんです」。最近、こういうお話を伺う機会が増えました。
実際そのとおりで、プログラミングの経験がない方でも、生成AIに相談しながら業務用の小さな仕組みを作れるようになりました。これは間違いなく良い変化です。
一方で、こんなご相談も同時に増えています。「作った本人が異動してしまい、誰も直せなくなった」。
この記事では、20年以上ITベンダーで基幹システムの開発・導入に携わり、現在は中小企業診断士として公的支援機関の相談員も務めている立場から、業務アプリをどこまで内製すべきか、その境界線についてお話しします。
まず前提として、社員が作れる時代になったのは本当です
Google Apps ScriptやExcelのマクロ、ノーコードツールなどを使えば、スプレッドシートの集計を自動化する、申請フォームを作る、期限が近い案件を自動で通知する——このくらいのことは、生成AIに手順を聞きながら十分に作れます。
しかもこれらは、すでに社内で使っている環境の中で完結するため、追加費用がほとんどかかりません。
私はこの流れを止めるべきだとは思いません。むしろ、現場が自分で改善できる会社は強いと考えています。
ただし、何でも内製すればよいわけではない。ここから先が本題です。
内製の最大のリスクは「作った人が辞める」こと
技術的な難しさより、こちらのほうがはるかに深刻です。
社内で作られた仕組みは、たいてい次のような状態になっています。
- 設計書も手順書もない
- 作った本人の個人アカウントの中で動いている
- どんなデータをどこから取っているか、本人しか知らない
- 「なぜこの計算式なのか」を説明できる人が他にいない
この状態で担当者が異動・退職すると、誰も触れないが、業務は依存しているという仕組みだけが残ります。
ベンダー側にいたころ、こうした「作った人がいなくなったシステム」の相談を何度も受けました。中身を解読するところから始めるので、作り直すより時間がかかることも珍しくありません。
内製が悪いのではなく、引き継げる形になっていないことが問題なのです。
素人判断が危険な領域が、2つあります
1つめ：データ構造の判断
「どのデータとどのデータを、どう結びつけるか」。ここは経験がものを言います。
たとえば、案件ごとの原価を集計したいとします。仕入のデータには案件番号が入っているのに、得意先の情報は入っていない。こういう食い違いは、実際のデータを開いてみて初めて分かります。
ここで安易に「だいたい合っていればいい」と処理してしまうと、それらしい数字は出るが、実は間違っているという状態ができあがります。見えないより危険です。
数字が合わないことに気づけるならまだ良いのですが、たいていの場合、気づかないまま経営会議の資料になっていきます。
2つめ：セキュリティと権限の設計
もう1つが、誰がどのデータを見られるか、という設計です。
社内の仕組みを作るとき、動かすことを優先すると、つい「全員が見られる」設定にしがちです。しかし、そこに顧客情報や給与情報が含まれていたらどうでしょうか。
また、個人のアカウントに紐づけて作った仕組みは、その人が退職してアカウントが削除された瞬間に止まります。これも実際によくある事故です。
こうした判断は、動くかどうかとは無関係なので、作っている本人には見えません。
判断の基準は「壊れたら、誰が困るか」
では、どう仕分ければよいのか。私がおすすめしているのは、この一言で考える方法です。
| 壊れたときに困る範囲 | おすすめの進め方 |
|---|---|
| 自分だけが困る | どんどん内製してよい。個人の作業効率化は、試行錯誤そのものが学びになる |
| 部署の業務が止まる | 内製してもよいが、引き継げる形にする。共有アカウントで動かす、手順書を残す |
| 会社の業務が止まる／お客様に影響する | ひとりで抱えない。経験のある人と一緒に作り、データ構造と権限を確認する |
「便利そうだから作る」ではなく、「これが動かなくなった日に何が起きるか」から逆算する。この順序で考えると、判断はかなりはっきりします。
内製が向くもの・向かないもの
もう少し具体的に整理すると、次のようになります。
| 向いているもの | 慎重に考えたいもの |
|---|---|
| 自分の作業を楽にする小さな自動化 | 基幹システムのデータを扱うもの |
| 定型的な文書の作成補助 | 顧客情報・人事情報を扱うもの |
| スプレッドシート内で完結する集計 | 複数のシステムをまたいで連携するもの |
| 試して、だめなら捨てられるもの | 経営判断の材料になる数字を出すもの |
右側にあるものを内製してはいけない、という意味ではありません。ひとりで判断せず、確認する相手を置いてほしいということです。
実は、内製と外注の二択ではありません
ご相談を受けていて感じるのは、多くの会社が「自分たちで作るか、業者に頼むか」の二択で考えているということです。
しかし実際には、その中間があります。一緒に作って、御社に残すというやり方です。
- データ構造の調査と、権限の設計は経験のある人間が行う
- 作った仕組みのソースコードは、すべて御社の資産としてお渡しする
- 操作の手順書を残す
- 将来、社内の方が自分で改修できる状態を目指す
これなら、内製のスピード感を保ちながら、属人化のリスクを避けられます。実際、私がお手伝いする際は、顧客ご自身のクラウド環境の中に作ることを原則にしています。契約が終わったあとも、そのまま社内で動き続けるからです。
「作ってもらったが、業者に依存し続ける」という形にはしたくない。ベンダー側にいた人間として、そこは強く思うところです。
明日からできること
すでに社内で作られた仕組みがある会社は、まずこの棚卸しをおすすめします。
- 社内で作られた仕組みを、すべて書き出す。Excelマクロ、スプレッドシートの自動集計、通知の仕組みなど
- それぞれについて「作った人」と「今、直せる人」を書く。この2つが同じ名前しか入らないものが、リスクの高いものです
- 「壊れたら誰が困るか」を3段階で書く。自分だけ／部署／全社の3つです
- 全社に印が付いていて、直せる人がひとりしかいないものから手を打ちます
これから作ろうとしている段階なら、作る前にこの3段階だけ考えてみてください。判断が変わることがあります。
まとめ
生成AIによって、社員が業務アプリを作れる時代になりました。これは活かすべき変化です。
ただし、内製の本当のリスクは技術ではなく属人化にあります。そしてデータ構造とセキュリティの2点だけは、ひとりで判断すると後戻りが大きくなります。
判断に迷ったら、「これが壊れた日に、誰が困るか」で仕分けてみてください。全社が困るものについては、一度、外の目を入れることをおすすめします。
社内で作った仕組みが増えてきて整理したい、あるいはこれから作るものをどう進めるべきか決めかねている——そうした段階でしたら、30分の無料相談でご一緒に整理します。