社内ツールを開発する前に：内製・ノーコード・外注の選び方

社内ツールを作るとき、「内製するか」「ノーコードで作るか」「外注するか」は、技術の好みではなく、利用する人数、仕様が変わる頻度、そして作った後に保守できる人がいるかどうかで決めるのが基本です。少人数で使い、頻繁に変わるツールなら、現場の担当者がノーコードで作るのが最も速く安く済みます。多くの人が使い、業務の中核を担い、他のシステムとつながるツールなら、設計から外部の専門家を入れるほうが、長く安定して使えます。

判断を誤るよくあるパターンは、最初の作りやすさだけで選んでしまうことです。ノーコードや表計算のスクリプトで手早く作ったツールが、利用者の増加とともに業務の中核になり、作った人しか直せない状態で何年も使われ続ける。あるいは、少人数で試せば済む段階で大がかりな外注をして、完成した頃には業務が変わっている。どちらも、作る前に「数年後にどう使われているか」を考えていれば避けられます。

この記事は、業務の効率化のために社内ツールを作ろうとしている事業部門の責任者や、情報システム担当者、経営者に向けています。3つの作り方の特徴、選び方の判断基準、作る前に決めておくこと、よくある失敗を順に整理します。

社内ツールとは何か、どこまでを指すか

この記事でいう社内ツールは、社員が業務で使うための小規模なシステムのことです。たとえば、次のようなものを想定しています。

• 申請・承認、日報、備品の貸し出しなどの管理ツール
• 案件、問い合わせ、タスクなどの一覧管理ツール
• 複数のシステムからデータを集めて加工し、レポートにまとめるツール
• 定型の書類や見積もりを作成するツール
• 社内向けの情報検索やナレッジ共有の仕組み

顧客に提供するサービスと違い、社内ツールは利用者が限られ、使い方を社内で説明できるため、作り込みの度合いを調整しやすいのが特徴です。その一方で、「社内向けだから」と保守や権限、データの扱いを軽く考えがちな点には注意が必要です。

3つの作り方の特徴

内製（社内のエンジニアが開発する）

社内にエンジニアがいる場合、プログラミング言語やフレームワークを使って自社で開発する方法です。業務の事情をよく知る人が作るため、要件の伝達のロスが少なく、変更にも素早く対応できます。一方で、エンジニアの時間は限られており、顧客向けの開発と取り合いになりがちです。また、作った人が異動・退職すると、保守が止まるリスクがあります。

ノーコード・ローコード（現場の担当者が作る）

kintoneのような業務アプリ作成ツール、データベース型のノーコードツール、表計算ソフトとそのスクリプト（Google Apps ScriptやVBA）、業務自動化ツールなどを使い、プログラミングの専門知識がなくても現場の担当者が作る方法です。現場が自分で作って改善できるため、最も速く、費用も抑えられます。こうした取り組みは市民開発とも呼ばれます。ただし、複雑な処理、大量のデータ、細かい権限、多くの外部連携には向かず、作った人に依存しやすい点が課題です。

外注（開発会社やフリーランスに依頼する）

要件を整理して、開発会社やフリーランスのエンジニアに開発を依頼する方法です。社内に専門家がいなくても、設計・セキュリティ・保守まで考えたツールを作れます。一方で、要件を言葉にして伝える手間がかかり、仕様の変更にも費用と時間がかかります。依頼先によって得意分野や体制が異なるため、選び方も重要です。依頼先の違いについてはフリーランスと開発会社のどちらに頼むべきかで整理しています。

作り方を選ぶ判断基準

判断の軸は、主に次の5つです。

この表で最も重要なのは、最後の「保守できる人」の行です。どれほど作りやすい方法でも、作った後に直せる人がいなければ、ツールはいずれ使われなくなるか、誰も触れない状態で動き続けることになります。

判断に迷ったときの考え方

複数の列にまたがる場合は、次の順番で考えると決めやすくなります。

1. 止まったときの影響を確認する：ツールが一日止まったら何が起きるかを考えます。代替手段がない、顧客に迷惑がかかる、という場合は、ノーコードで手早く作るより、保守体制まで含めて設計するべきです。
2. 数年後の利用者数を想定する：今は一つのチームでも、うまくいけば他の部署にも広がるかもしれません。広がる見込みがあるなら、最初から権限やデータ構造を意識した作り方を選びます。
3. 保守担当を名前で挙げる：「誰か」ではなく、具体的な担当者を挙げられるかを確認します。挙げられない場合は、外注で保守まで含めて依頼するか、作り方そのものを簡単にします。
4. 小さく試してから決める：迷うなら、まずノーコードや表計算で最小限の形を作り、数週間使ってみます。本当に必要な機能と、使われ方が分かってから、本格的な作り方を選んでも遅くありません。

作り方ごとの費用の考え方

社内ツールの費用は、作り方によって発生の仕方が大きく異なります。

外注の作業費は、基本的に「作業量 × 作業する人の単価」で決まり、作業量は画面の数、権限の複雑さ、外部連携の数、データ移行の有無などで変わります。見積もりを比べるときは、金額よりも、前提となる範囲がそろっているかを確認します。

ノーコードは月額が安く見えますが、利用人数が増えるとその分費用も増えます。また、作った人が本来の業務の合間に作業しているなら、その時間もコストです。内製では、社内エンジニアの時間を社内ツールに使うことで、顧客向けの開発が遅れることも考慮に入れる必要があります。

組み合わせという選択肢

3つの作り方は、どれか一つに決める必要はありません。実際には、次のような組み合わせがよく使われます。

• ノーコードで試し、外注で本格化する：まず現場がノーコードで作って使い方を固め、利用が広がった段階で、要件が明確になった状態で外注する。要件の伝達のロスが小さくなります。
• 外注で土台を作り、内製やノーコードで改善する：データベースや権限、外部連携などの土台を外注で作り、画面の調整や帳票の追加は社内で行う。変更の多い部分を社内に残せます。
• 外注で作り、保守を段階的に内製に移す：最初は開発会社に開発と保守を任せ、社内にエンジニアが育ったら保守を引き継ぐ。引き継げるように、設計書やソースコードの管理を最初から取り決めておきます。

社内ツールを作る前に決めておくこと

作り方に関係なく、作り始める前に次のことを決めておくと、後の手戻りを減らせます。

1. 目的と効果の測り方：何の業務の、どの時間やミスを減らすのかを決めます。「便利にする」ではなく、「月末の集計作業を手作業から自動にする」のように具体的にします。
2. 利用者と権限：誰が使い、誰が何を見られて、何を編集できるべきかを整理します。人事や給与、顧客の個人情報を扱う場合は特に慎重に決めます。
3. 扱うデータとその正本：ツールで扱うデータが、他のシステムやファイルにもある場合、どれが正しいデータかを決めます。
4. 最初に作る範囲：必要な機能を書き出し、最初のリリースに含めるものと、後回しにするものを分けます。
5. 保守と改修の担当：作った後に、不具合の対応、利用者の追加・削除、仕様の変更を誰が行うかを決めます。
6. やめ方：ツールが不要になったとき、データをどう取り出し、どう廃止するかを考えておきます。特にノーコードツールでは、データを書き出せる形式を確認しておきます。

ノーコードで作る場合の社内ルール

現場の担当者がノーコードで作る場合、自由に作れることが強みである一方、全社で見ると似たツールが乱立し、どこに何のデータがあるか分からなくなることがあります。完全に自由にするのではなく、最低限のルールを決めておくと、強みを生かしたまま混乱を防げます。

• 作ったツールは、名前・目的・作成者・利用者・扱うデータを一覧に登録する
• 個人情報や機密情報を扱う場合は、作る前に情報システム担当や管理部門に相談する
• 作成者のほかに、内容を理解している副担当を一人決める
• 外部サービスとの連携やアカウントの契約は、個人ではなく会社の管理下で行う
• 一定期間使われていないツールは、作成者に確認したうえで停止する

ルールは厳しすぎると誰も守らなくなるため、最初は登録と副担当の二つだけでも十分です。

外注する場合に社内で準備すること

外注を選んだ場合、発注側の準備の質が、できあがるツールの質を大きく左右します。少なくとも次の資料を用意しておくと、見積もりの精度が上がり、依頼先の比較もしやすくなります。

• 現在の業務の流れを示した図と、使っているファイルやシステムの一覧
• 最初のリリースで必ず実現したいことと、できればほしいことの区別
• 利用者の役割と、それぞれが見られるデータ・操作できる範囲
• 連携したい他システムの名前と、データの向き
• 社内の窓口担当と、判断を下す責任者

依頼先には、作るだけでなく、リリース後の保守や改修をどう引き受けてもらえるか、ソースコードや設計書の扱いをどうするかも確認しておきましょう。社内ツールは使い始めてから要望が出ることが多いため、改修の依頼のしやすさは、開発費と同じくらい重要な比較の観点です。

具体的な場面で考える：見積もり作成ツールの例

架空の例として、設備の販売とメンテナンスを行う会社で、見積もり作成を効率化するツールを作る場面を考えます。現在は営業担当がExcelのテンプレートで見積もりを作っており、単価の改定のたびにテンプレートを差し替え、古いテンプレートで作られた見積もりが出回ることがありました。

最初は、営業部の一人がGoogle Apps Scriptで、単価表から自動で見積もりを作成するツールを作りました。数人の営業で使うには十分で、改善もその担当者がすぐに行えました。

しかし、利用者が営業部全体に広がり、承認の手順や値引きの上限、過去の見積もりの検索、顧客管理システムとの連携が求められるようになると、状況が変わります。スクリプトは作った担当者しか分からず、その担当者は本来の営業活動の時間を削って対応していました。ツールが止まると見積もりが出せず、商談に影響します。

判断基準に当てはめると、利用人数、業務上の重要度、連携の複雑さ、保守できる人のすべてで、ノーコードの列から外れています。このタイミングで、スクリプトで固まった使い方を要件として整理し、外注でWebシステムとして作り直す、単価表の更新や帳票の文言変更は営業部で行えるよう管理画面を用意する、という進め方が考えられます。表計算のスクリプトで作ったツールの限界については、GASで作る社内ツールの限界と移行の目安で詳しく解説しています。

社内ツール開発でよくある失敗と避け方

作った人しか分からない状態になる

ノーコードでも内製でも、作った人が一人で抱え込むと、その人の異動や退職でツールが止まります。こうした属人化を避けるには、作る段階から二人以上が関わる、何をどう作ったかを簡単な文書に残す、設定やソースコードを共有の場所で管理する、といった取り決めが必要です。

便利な機能を足し続けて複雑になる

社内ツールは要望を聞きやすいため、利用者の声に応えて機能を足し続け、誰も全体を把握できない状態になりがちです。目的に照らして本当に必要か、使われていない機能はないかを定期的に見直し、不要なものは削る判断も必要です。

権限とデータの扱いを軽く見る

「社内向けだから」と全員に全データを見せる設計にした結果、人事評価や個人情報が意図しない人に見えていた、という事故が起きます。社内ツールでも、扱うデータの重要度に応じて、権限とアクセスの記録を設計しましょう。

ノーコードで作れる範囲を超えて無理をする

ノーコードツールの限界を、複雑な設定や外部サービスの組み合わせで乗り越えようとすると、作った人以外には理解できない仕組みになります。限界のサインが出たら、無理に延命するより、作り方を見直すほうが結果的に安くなります。kintoneの場合の判断基準はkintoneの限界はどこかを参考にしてください。

外注で要件を丸投げする

「いい感じに作ってほしい」と依頼すると、業務に合わないツールができあがります。外注する場合でも、目的、利用者、業務の流れ、最初の範囲は発注側で整理し、試作段階で現場に触ってもらって確認する必要があります。

社内ツールの作り方を決めるチェックリスト

• ツールの目的と、効果を測る指標を決めたか
• 利用人数と、将来広がる見込みを整理したか
• ツールが止まったときの影響と代替手段を確認したか
• 仕様がどのくらいの頻度で変わりそうかを見積もったか
• 扱うデータの重要度と、権限の要件を整理したか
• 他のシステムとの連携の有無と方向を確認したか
• 保守担当を具体的な名前で挙げられるか
• 最初に作る範囲と後回しにする範囲を分けたか
• 作り方ごとの初期費用と継続費用を並べて比較したか
• ツールを廃止するときのデータの取り出し方を確認したか

よくある質問

Q. 社内にエンジニアがいない場合、ノーコードしか選択肢はありませんか？

ノーコードで十分な業務なら、それが最も合理的です。ただし、業務の重要度が高い、利用者が多い、連携が複雑、といった条件がある場合は、外注を選ぶべきです。その場合も、保守や改修を誰がどう依頼するかを最初に決めておけば、社内にエンジニアがいなくても運用できます。

Q. ノーコードで作ったツールを、後から外注で作り直すのは無駄になりませんか？

無駄にはなりません。ノーコードで作って使った経験から、本当に必要な機能と使われ方が明確になっているため、外注時の要件整理が速く、正確になります。むしろ、最初から外注して使われない機能を作るよりも、全体の費用を抑えられることが多いでしょう。

Q. 生成AIを使えば、社内でも本格的なツールを作れますか？

生成AIを使ったコーディング支援によって、プログラミングの経験が浅い人でも作れる範囲は広がっています。ただし、作れることと、安全に長く保守できることは別の問題です。権限やセキュリティ、障害時の対応、他の人が引き継げる構成になっているかは、専門家の確認を受けることをおすすめします。

Q. 既製のSaaSを使うのと、社内ツールを作るのはどう判断すればよいですか？

業務のやり方を製品に合わせられるなら、既製のSaaSが最も早く安く済みます。自社独自のルールが業務の中核にあり、製品では表現できない場合や、複数のSaaSの間をつなぐ作業そのものを効率化したい場合に、社内ツールを作る意味が出てきます。

Otsumuに相談できること

利用者が一つのチームに限られ、仕様が頻繁に変わり、止まっても手作業で代替できるツールであれば、現場の担当者がノーコードや表計算で作るのが最善です。その場合、外部に依頼する必要はありません。この記事の判断基準とチェックリストを使って、作る前に目的と保守担当だけは決めておきましょう。

一方で、ノーコードで作ったツールが業務の中核になり、作った人しか直せない状態になっている場合や、利用者の拡大、権限の細分化、他システムとの連携が必要になってきた場合は、外部の力を借りるタイミングです。どの作り方を選ぶべきか、どこまでを社内に残すべきかの判断に迷う場合も、第三者の視点が役に立ちます。

Otsumuでは、社内ツール開発として、作り方の選定から、要件の整理、設計、開発、運用後の改善までを一貫して支援しています。目的から逆算して必要な機能に絞り、AIを活用した開発で少人数・短期間で進めるため、ノーコードで固まった使い方を土台に、必要な部分だけを本格的なシステムにすることも可能です。社内で改善を続けたい部分は、管理画面や設定で変更できるように設計します。

まだ作り方を決めていない段階でもかまいません。30分の無料相談で、作りたいツールの目的と社内の体制をお聞きし、内製・ノーコード・外注のどれが合うかを一緒に整理します。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01