動く社内ツールを作る前に、考えておかないと後で困ること
AIやノーコードで社内ツールを作りやすくなった今だからこそ、作る前に運用ルール・保守性・拡張性を考えておくことが重要です。
近年、生成AIやノーコードツールの普及により、専門のエンジニアでなくても社内ツールを作りやすくなりました。
日報の入力フォーム、問い合わせ管理、在庫の一覧、簡単な承認フローなど、これまで外部に依頼しなければ難しかったものでも、AIに相談しながら形にできる場面が増えています。
この流れ自体は、非常に良いことです。現場の困りごとを、現場に近い人が素早く改善できるようになるからです。
しかし一方で、「とりあえず動くものができた」だけで、そのまま業務に組み込んでしまうことには注意が必要です。
社内ツールで本当に怖いのは、作れないことではありません。最初は便利に見えたものが、業務の変化に耐えられず、少し直すだけで全体を作り直すような状態になってしまうことです。
社内ツールは、作った瞬間から運用が始まる
社内ツールは、完成したら終わりではありません。
むしろ、実際に使い始めたところから運用が始まります。
誰が管理者になるのか。入力ミスがあったとき、誰がデータを修正するのか。利用者が増えたとき、誰がアカウントを追加するのか。エラーが出たとき、誰が原因を確認するのか。
こうしたことを決めないまま使い始めると、最初は小さな便利ツールだったものが、いつの間にか「誰も責任を持って見られない仕組み」になってしまいます。
特に社内ツールでよく起こるのが、「作った本人にしかわからない」という属人化です。
作った担当者が在籍している間は問題なく見えても、異動や退職があった瞬間に、修正も確認もできなくなる。これは決して珍しい話ではありません。
最初に決めておきたい運用ルール
社内ツールを作る前には、機能だけでなく、最低限の運用ルールも決めておく必要があります。
- 誰が管理者になるのか
- 誰が利用者を追加・削除するのか
- 誰がデータの修正や確認を行うのか
- どこにデータを保存するのか
- バックアップは必要か
- 権限を分ける必要があるか
- 不具合が出たとき、誰に相談するのか
- 仕様変更の要望は、誰が判断するのか
これらは、画面を作るだけなら後回しにされがちな項目です。
しかし、実際の業務ではこうした運用部分こそが重要になります。
「誰でも使える」ことと「誰でも管理できる」ことは違います。便利に見えるツールほど、裏側の管理ルールが曖昧なまま広がってしまうことがあります。
保守性がないツールは、少しの変更で壊れる
AIに「このような社内ツールを作ってください」と依頼すると、画面や基本的な動作は短時間で作れることがあります。
しかし、その成果物が後から修正しやすい構造になっているとは限りません。
たとえば、入力項目を1つ増やしたいだけなのに、複数の画面や処理をそれぞれ手作業で直さなければならない。部署ごとに閲覧権限を分けたいだけなのに、そもそも権限を追加できる設計になっていない。承認フローを1段階増やしたいだけなのに、データの持ち方から見直さなければならない。
このような状態になると、最初は小さな修正に見えても、実際にはかなり大きな作業になります。
大切なのは、作った直後に動くかどうかだけではありません。
業務の変化に合わせて、後から無理なく直せる状態になっているかどうかです。
社内ツールは、一度作ったらそのまま永遠に使われるものではありません。利用者が増えたり、部署が変わったり、承認ルールが変わったり、集計したい項目が増えたりします。
その変化を全く想定せずに作ってしまうと、少しの変更が「作り直し」に近い作業になってしまうのです。
拡張性を考えないと、運用変更に耐えられない
最初は「営業部だけで使う問い合わせ管理ツール」のつもりだったものが、後から「総務でも使いたい」「拠点別に見たい」「担当者ごとに権限を分けたい」と広がっていくことがあります。
このとき、最初の設計があまりにも場当たり的だと、機能を追加するたびに無理が出てきます。
最初は1つの部署しか想定していなかったため、部署という考え方がデータに存在しない。担当者を1人だけ持つ前提で作ったため、複数人で確認する運用に対応できない。ステータスが固定の文字列で埋め込まれていて、承認中・差し戻し・保留といった状態を増やしにくい。
こうした問題は、表面上は見えにくいものです。
画面上では普通に動いていても、運用が少し変わった瞬間に限界が見えてきます。
もちろん、将来起こりうるすべての変更を最初から完璧に予測することはできません。むしろ、最初から大きく作りすぎると、かえって使いにくいものになります。
大切なのは、「今は作らないが、将来変わりそうな部分」を把握したうえで、後から直せる余地を残しておくことです。
現場の声を全部入れると、別のものになる
社内ツールを作るとき、現場の声を聞くことは非常に大切です。
実際に使う人の業務を理解せずに作ったツールは、現場に定着しません。
しかし、現場の要望をすべてそのまま盛り込めばよいかというと、それも違います。
たとえば、最初は「在庫を簡単に確認できるツール」を作るつもりだったとします。ところが話を聞いていくうちに、「発注も管理したい」「承認も入れたい」「売上とも連携したい」「勤怠情報も見たい」と要望が増えていく。
気づけば、最初に作ろうとしていたものとは全く別のシステムになっていることがあります。
ラーメンを作るつもりで具材を足していたはずなのに、いつの間にかパスタを作ろうとしているような状態です。
要望を聞くこと自体は悪くありません。問題は、「今回作るもの」と「今回は作らないもの」の線引きがないことです。
この線引きがないまま作り始めると、仕様が膨らみ続け、完成しない。あるいは、完成しても何のためのツールなのかわかりにくいものになってしまいます。
AIに丸投げした成果物で抜けやすいこと
AIは、指定された内容をもとに、画面や処理を作ることは得意です。
しかし、業務上の前提や将来の運用変更まで、勝手に深く考えてくれるわけではありません。
特に、以下のような点は抜け落ちやすい領域です。
- 例外的な業務フローへの対応
- 担当者が変わったときの引き継ぎ
- 権限やアクセス制御
- データのバックアップ
- エラー発生時の復旧方法
- 後から項目や部署が増えることを想定した設計
- 仕様変更の履歴やドキュメント
もちろん、これらをすべてAIが考えられないという意味ではありません。
ただし、こちらが前提条件を整理し、何を重視するかを明確に伝えなければ、AIは「とりあえず動くもの」を優先して出力しがちです。
そして、素人目にはその差が見えにくいのが難しいところです。
画面が整っていて、登録や編集ができると、それだけで十分に完成しているように見えます。しかし、実際には運用・保守・拡張の観点で大きな落とし穴を抱えていることがあります。
作る前に考えるべきなのは「機能」だけではない
社内ツールを作る前に考えるべきことは、「どのような画面が必要か」「どのような機能が必要か」だけではありません。
誰が使うのか。
誰が管理するのか。
誰が直すのか。
どこまでを今回の対象にするのか。
将来、どのような方向に広がる可能性があるのか。
どこから先は、専門家に相談すべきなのか。
こうした判断が曖昧なままツールを作ると、最初は便利でも、後から現場を縛る仕組みになってしまうことがあります。
小さく作ることは大切です。
しかし、「小さく作る」ことと「何も考えずに作る」ことは違います。
AIやノーコードで社内ツールを作れる時代だからこそ、最初の設計判断や運用ルールの整理が、以前にも増して重要になっています。
私たちが提供するサービス 専任担当者がいない会社の「社外IT相談役」 では、社内で作ったツールや、これから作ろうとしている仕組みに対して、運用・保守性・拡張性・セキュリティの観点から伴走支援を行っています。
「とりあえず動くもの」は作れそうだが、そのまま業務に乗せてよいか不安がある。
そのような段階で一度相談していただくことで、後から大きな作り直しになるリスクを減らしやすくなります。