社内ツール開発を外注する前に決めておくべき7つのこと

社内の準備で、開発の進み方が変わる

社内ツールの開発は、開発会社だけでは完結しません。業務の流れや判断のルール、誰が使うのかといった情報は、発注する会社の中にしかないからです。

開発会社は「どう作るか」の専門家ですが、「何を作るべきか」を決めるには、発注者からの情報が欠かせません。ここが曖昧なまま進むと、次のような問題が起きやすくなります。

• 見積もりの前提が人によって違い、比較ができない
• 開発の途中で「やはりこの機能も必要だった」と範囲が広がる
• 完成後に、現場の担当者から「この流れでは使えない」と言われる

逆に言えば、社内で決めるべきことを先に押さえておけば、技術的な部分は開発会社に任せることができます。そもそもどの業務をツール化するかを迷っている段階であれば、業務効率化に向いているWebアプリとは？で、手作業を減らせる業務の見つけ方を紹介しています。

社内ツール開発を外注する前に決めておくべき7つのこと

1. 目的と、うまくいったと判断する基準

最初に決めるべきは、ツールを作る目的です。「顧客管理ツールがほしい」は手段であって、目的ではありません。「担当者が不在でも、顧客との過去のやり取りをすぐ確認できるようにしたい」「月末の集計作業にかかる時間を減らしたい」のように、今の業務で困っていることとツールで実現したい状態を言葉にしておきましょう。

あわせて、何がどうなれば「うまくいった」と言えるかも決めておくと役立ちます。「対応漏れがなくなる」「月末の集計が当日中に終わる」など、自社の業務の言葉で構いません。目的と基準がはっきりしていれば、機能を追加するか迷ったときに「それは目的に必要か」で判断できます。

2. 利用者の範囲と、見せる範囲の方針

ツールを使う人の範囲と人数を整理します。社内の一部の部署だけなのか、全社なのか、取引先や顧客も使うのかによって、必要な権限やログインの仕組み、画面の作り方が変わります。

• 主に入力する人（現場の担当者など）
• 主に確認・承認する人（管理者、責任者など）
• 情報を見るだけの人（他部署、経営層など）
• 社外の利用者がいるかどうか

そのうえで、「担当者は自分の担当分だけ見られればよいのか」「他部署には閲覧だけ許すのか」といった見せる範囲の方針を社内で決めておきます。権限の細かさは費用にも影響するため、方針だけでも早めに固めておくと見積もりがぶれにくくなります。

3. 範囲：今回やること・やらないこと

見落とされがちですが、「今回はやらないこと」を決めておくのは非常に重要です。社内ツールは、検討を進めるうちに「ついでにこれも」と要望が増えやすいものです。

たとえば「今回は案件の進捗管理だけを対象にし、見積書の作成は次の段階で検討する」と決めておけば、範囲が膨らむのを防げます。後で追加する可能性がある機能は、「将来の候補」としてメモしておけば十分です。

4. 業務のルール：流れ・ステータス・承認

ツールを使って、誰がどの順番で何をするのか、そのときのルールを決めます。ここは開発会社には決められない部分です。専門的な図は不要で、箇条書きで構いません。

この流れが決まれば、必要な画面（登録、ステータスで絞り込める一覧、対応履歴つきの詳細など）は開発会社と一緒に具体化できます。社内で決めておくべきなのは、画面の形よりも「どの状態になったら次の担当に渡すのか」「誰が完了と判断するのか」といったルールのほうです。

5. データの扱い：記録する情報・既存データ・管理責任

ツールで扱う情報（項目）と、既存のデータの扱いを決めます。

• 記録したい項目（例：顧客名、問い合わせ日、内容、担当者、ステータス、対応履歴）
• 今あるデータ（Excel、紙、別のツールなど）を移行するかどうか
• 移行する場合、どの期間のデータを対象にするか
• 個人情報や機密情報を含むかどうか

個人情報を扱う場合は、社内で誰がデータの管理責任を持つのか、退職者のアカウントを誰が止めるのかといった運用面も決めておきましょう。

6. 社内の担当者と確認の体制

発注後、開発会社とのやり取りを担当する窓口を決めます。窓口が複数いたり、決まっていなかったりすると、確認に時間がかかったり、指示が食い違ったりする原因になります。

• 開発会社との連絡窓口は誰か
• 仕様の最終判断をするのは誰か
• 動作確認（テスト）をするのは誰か。現場の担当者に参加してもらえるか
• 社内での承認（稟議など）にどの程度の期間がかかるか

特に、現場で実際に使う担当者が確認に参加できるかどうかは、完成後に使われるツールになるかを大きく左右します。

7. 予算・時期・公開後の運用

最後に、予算の目安、使い始めたい時期、公開後の運用について整理します。

• 予算：おおよその範囲で構いません。予算感が分かると、開発会社は範囲の提案をしやすくなります
• 時期：いつから使い始めたいか。繁忙期を避けたい、年度の切り替えに合わせたいなどの事情があれば伝えておきます
• 公開後の運用：不具合対応や軽微な修正を誰が行うか、サーバーやアカウントを自社で管理したいか
• 補助金の利用：利用を検討している場合は、スケジュールや見積書の形式に影響するため最初に伝えます

費用がどのような要素で決まるかは、業務用Webアプリ開発の費用はどう決まる？で詳しく解説しています。

「決めたつもり」になりやすい3つのずれ

7つの項目を決めたつもりでも、社内と開発会社の間で、言葉の意味がずれていることがあります。よくあるのは次のようなケースです。

ステータスの意味がずれる

「対応中」という言葉ひとつでも、「担当者が決まった状態」を指す人もいれば、「顧客に連絡済みの状態」を指す人もいます。ステータスを決めるときは、名前だけでなく「どの状態になったら、このステータスにするか」を一文で書いておくと、ずれを防げます。

「承認」の範囲がずれる

「上長の承認が必要」と伝えた場合、承認者は1人なのか複数なのか、承認されなかったら差し戻すのか却下するのか、承認者が不在のときはどうするのか、といった点が決まっていないことがよくあります。承認の流れはシステムの作りに大きく影響するため、具体的な場面を想定して決めておきましょう。

「全員が使う」の範囲がずれる

「社員全員が使う」と言った場合、パートや業務委託のスタッフは含まれるのか、閲覧だけの人も含むのかで、アカウントの数や権限の設計が変わります。利用者の範囲は、役割ごとに人数を書き出しておくと確実です。

こうしたずれは、開発会社からの質問によって表に出ることもあります。質問を受けたら「細かいことだ」と流さず、業務の実態に沿って答えることが、使えるツールにつながります。

決めた内容を社内で共有しておく

7つの項目を整理したら、関係者に共有して認識をそろえておきましょう。特に、実際にツールを使う現場の担当者と、予算を承認する立場の人の両方に目を通してもらうことが大切です。

• 現場の担当者からは、業務の流れや必要な項目について、管理者が気づいていない点が出てくることがあります
• 予算を承認する人からは、目的や範囲について、別の視点からの意見が出ることがあります

発注後に社内から「そんな話は聞いていない」と意見が出ると、仕様の変更や手戻りにつながります。発注前の共有は、手間のようでいて、結果的に開発期間を短くする効果があります。

社内で決めること、開発会社と決めること

すべてを発注者が決める必要はありません。役割を分けて考えると、準備の負担はぐっと軽くなります。

社内のセキュリティ規程で使えるサービスが決まっている、既存のシステムとつなぐ必要がある、といった前提条件は、技術的な話であっても最初に伝えておきましょう。

7つの項目をまとめたチェックリスト

相談の前に、次のチェックリストで「決まっていること」と「まだ決まっていないこと」を確認してみてください。すべてが埋まっている必要はありません。

• 解決したい課題と、うまくいったと判断する基準を一文で説明できる
• 利用者の種類と人数、見せる範囲（権限）の方針が決まっている
• 今回やること・やらないことを分けている
• 業務の流れ、ステータスの意味、承認のルールを言葉にしている
• 記録したい項目、既存データの扱い、データの管理責任者を決めている
• 社内の窓口、最終判断者、確認の担当者を決めている
• 予算の目安、使い始めたい時期、公開後の運用の方針がある

依頼先を選ぶときに確認したいこと

社内で決めることが整理できたら、依頼先を選ぶ段階に進みます。社内ツールの開発を依頼する際は、次の点を確認しておくと安心です。

• 見積もりに含まれる画面・機能の範囲が明記されているか
• 初回納品後の修正対応の範囲がどうなっているか
• 仕様の追加・変更が出たときの進め方が決まっているか
• ソースコードやサーバー、各種アカウントの管理者が誰になるか
• 公開後の保守を依頼できるか、その範囲はどうなっているか

制作会社、フリーランス、開発会社など、依頼先ごとの違いについては小規模な業務システム開発はどこに依頼すべき？で比較しています。

まとめ：社内で決めることと、相談しながら決めることを分ける

社内ツール開発の外注で大切なのは、完璧な準備をすることではなく、社内でしか決められないこと（目的、利用者、範囲、業務の流れ、担当者）を先に押さえることです。技術的な判断や、画面の具体的な設計は、開発会社と相談しながら決めれば問題ありません。

Tailboneでは、仕様書がない状態からのご相談にも対応しています。箇条書きのメモ、参考サービス、手書きの画面イメージ、今使っているExcelなど、今あるもので十分です。お問い合わせの際にお伺いする項目と、そのまとめ方については、Webアプリ開発を依頼する前に準備するもの｜要件メモの書き方とテンプレートも参考にしてください。