電話で受けた予約変更を紙に書き、LINEで届いた写真を担当者へ送り、メールの申込内容を閉店後に手元の表へ移す。翌朝になって「昨日の変更は誰が反映したっけ」と確認し、紙、スマホ、メールをもう一度開く。
修理受付、教室申込、イベント備品の予約、訪問サービスの日程調整では、現場だけが知っている決まりが少しずつ増えます。常連のお客様は電話で受ける、キャンセルは前日まで、担当者が空いていても道具が空いていなければ受けられない。こうした小さな前提を伝えないまま開発を頼むと、あとから「思っていた動きと違う」が起きやすくなります。
この記事では、開発外注を検討している事業者が、契約前に今の業務のどこをすり合わせればよいかを整理します。ここでいう前提とは、開発前に共有しておく条件のことです。専門的な仕様書ではなく、電話、LINE、紙、表で実際に起きている流れを言葉にするところから始めます。
契約前に何を伝えればよいか迷うのは自然です
「見積もりは早くほしい。でも、今のやり方をどこまで説明すれば失敗を防げるのだろう」
たとえば、次のような場面です。
- 電話で受けた変更だけ、表に反映されるタイミングが担当者によって違う
- LINEで届いた写真や補足を、あとから申込内容と見比べている
- 紙の受付票には書いてある注意点が、メールやフォームには入っていない
- 店長だけが知っている例外対応を、現場スタッフが毎回確認している
- 月末に数える件数から、キャンセルや日程変更をどこまで除くか迷う
- お客様情報を、社内の誰と外部の相談先にどこまで共有してよいか不安がある
開発外注でつまずく理由は、依頼者が悪いからではありません。
多くの場合、現場では当たり前になっている決まりが、相談先からは見えないだけです。
「予約管理を作りたい」「申込フォームがほしい」「一覧で見たい」と伝えるだけでは、毎日の判断や例外が抜けます。
大切なのは、完成形を細かく決めることではなく、契約前にずれやすい前提を言葉にしておくことです。
先に結論
開発外注で失敗を避けたいときは、契約前に次の5つをすり合わせます。
- 今の受付経路は、電話、LINE、メール、紙、フォームのどれか
- 例外対応は、誰が、どのタイミングで判断しているか
- 社内で誰が見るのか、誰が直すのか
- お客様情報をどこまで扱うのか
- 公開後に誰が問い合わせ、更新、月ごとの確認を持つのか
この5つが曖昧なままでも、相談を始めることはできます。
ただし、曖昧なまま契約範囲まで決めると、あとから画面、通知、状態名、権限、確認方法の見直しが増えます。
初回相談では、「まだ決まっていないこと」も伝えて大丈夫です。
「電話とLINEと紙が混ざっています。例外対応は店長に確認しています。どこまで最初に作るか相談したいです」と言えるだけで、話はかなり具体的になります。
失敗につながりやすい前提を分ける
前提という言葉は、少し硬く聞こえます。
この記事では、現場では当たり前でも、相談先には見えていない条件として扱います。
まず、次の表のように分けます。
| すり合わせる前提 | 現場で起きる場面 | 曖昧なままだと起きること | 相談前にメモすること |
|---|---|---|---|
| 受付経路 | 電話、LINE、メール、紙、フォームから同じ種類の依頼が入る | どこを正しい情報として見るのかが決まらず、一覧の作り方がずれる | 1件の依頼がどこから入り、誰が最初に見て、どこへ写すか |
| 例外対応 | 常連だけ電話で受ける、前日変更は店長確認、備品が足りない日は受けない | 画面上は申し込めるのに、実際には受けられない依頼が出る | よくある例外を3つだけ書き、最初から入れるか後で相談するか分ける |
| 確認する人 | 受付担当、現場スタッフ、店長、事務担当が別々のタイミングで確認する | 全員に同じ画面を見せる前提になり、見せたくない情報まで広がる | 誰が毎日見るか、誰だけが直すか、外部の相談先へ何を共有するか |
| 状態名 | 未対応、確認中、返信済み、支払い済み、キャンセル、受け渡し済みが混ざる | 月末に数える件数や、通知を送るタイミングがずれる | 最初に使う状態名を3つから5つに絞り、月末に数える状態を決める |
| 公開後の担当 | 料金変更、スタッフ名変更、問い合わせ対応、月ごとの確認が公開後に出る | 作った後に誰が直すか決まらず、小さな変更でも止まりやすくなる | 社内で直したいことと、相談先へ頼みたいことを分ける |
この表は、契約書を自分で作るための表ではありません。
初回相談で「ここは今の業務に合わせたい」「ここは相談しながら決めたい」と伝えるための表です。
代表的な進め方を比べる
契約前の進め方は一つではありません。
いきなり全部を決める必要はありません。
今の業務がどれくらい見えているかに合わせて、始め方を選べます。
| 進め方 | 向いているケース | 主なメリット | 確認点 | 相談時の言い方 |
|---|---|---|---|---|
| 現状メモだけで初回相談する | 作りたいものはあるが、細かい画面や機能はまだ決まっていない | 相談を早く始められ、決めるべきことと後回しでよいことを分けやすい | 契約範囲まで急いで決めず、未定の項目をそのまま残す | まだ仕様は固まっていません。今の業務の流れから一緒に整理したいです |
| 実際の1件を一緒に追う | 電話、LINE、紙、表のどこで確認漏れが起きるかを説明しにくい | 抽象的な機能名より、現場の判断が伝わりやすい | 個人情報は伏せ、流れと判断だけを共有する | 昨日の申込1件を例に、受付から返信までの流れを見てほしいです |
| 小さな試作で確認する | 画面を見ないと、現場が使えるか判断しづらい | 本開発に入る前に、入力項目、一覧、通知、状態名のずれを見つけやすい | 試作は本番運用ではなく、判断材料として扱う | まず受付と一覧だけ試作して、現場で確認したいです |
| 契約範囲を段階に分ける | 最初から全部必要に見えるが、予算や公開時期に限りがある | 初回で作る範囲と、公開後に足す範囲を分けやすい | 後で足す可能性があるものも、存在だけは最初に共有する | 初回は受付と未対応一覧までにして、月ごとの確認は後で相談したいです |
| 契約前に担当を決める | 公開後に誰が問い合わせや更新を持つか決まっていない | 作った後に困る場面を、開発前から相談に入れられる | 未定なら、未定のまま相談してよい。無理に社内担当を決め切らない | 公開後の更新担当が未定です。社内で持つ範囲も含めて相談したいです |
この比較はランキングではありません。
「どれが正しいか」ではなく、今の不安に合う始め方を選ぶための整理です。
公式情報から見た注意点
IPAの「情報システム・モデル取引・契約書（第二版）」は、情報システム開発の取引構造を透明にし、ユーザ企業とITベンダが契約のタイミングで仕様、進め方、確認方法について共通理解のもとで対話することを期待すると説明しています（参考）。
小さな業務アプリでも、考え方は同じです。
契約書の細部を読者が自力で作る必要はありません。
しかし、依頼者側が「今の業務では、何を正しい情報として見るのか」「誰が確認するのか」「公開後に誰が直すのか」を話題にできると、相談のずれは減ります。
デジタル庁のデジタル社会推進標準ガイドラインは、サービス・業務改革と情報システムの整備・管理に関する共通ルールや参考資料をまとめています（参考）。
公的な大規模システム向けの資料ですが、作る画面だけでなく、業務の進め方と管理を合わせて考える点は、小さな事業にも参考になります。
GOV.UKのDiscovery phaseでは、作る前に利用者、制約、今の業務や周辺の流れを理解することが説明されています（参考）。
同じService ManualのUser research in discoveryでは、利用者が今どの道具や経路を使っているか、困っていることは何かを確認し、必要に応じて観察や聞き取り、既存データを使うと説明されています（参考）。
つまり、電話、LINE、紙、表のような一見ばらばらの道具も、開発前に確認すべき大事な材料です。
また、氏名、電話番号、住所、申込内容、支払い状況などを扱う場合は、情報の扱いも契約前の相談に入れます。
IPAの中小企業向け情報セキュリティ対策ガイドラインは、個人事業主や小規模事業者を含む中小企業向けに、情報セキュリティ対策の考え方と段階的な進め方を整理しています（参考）。
読者側で覚えるべきなのは、難しい法律用語や技術ではありません。
お客様情報を誰が見られるのか、外部の相談先へ何を共有するのか、公開後に誰が更新するのかを、早い段階で話題にすることです。
契約前にすり合わせたい5つのこと
ここからは、依頼者側が相談前に見ておきたいことを5つに分けます。
1. どこから依頼が入っているか
電話、LINE、メール、紙、フォームが混ざっているなら、最初に受付経路を出します。
「全部を一つにしたい」と言うより、「電話で受けた変更だけ後から表へ移しています」と伝える方が具体的です。
相談先は、どこを最初の入口にするか、どこを残すかを考えやすくなります。
2. 例外対応を誰が判断しているか
例外対応とは、いつもとは違う扱いのことです。
たとえば、常連だけ電話で受ける、前日変更だけ店長が確認する、備品が足りない日は受けない、といったものです。
最初からすべてを自動にする必要はありません。
まず、よくある例外を3つだけ書きます。
3. 誰が見るか、誰が直すか
一覧を見る人と、内容を直す人は同じとは限りません。
受付担当は未対応だけ見ればよい。
店長は料金や受付時間を直したい。
現場スタッフは担当分だけ確認したい。
この違いがあるなら、最初から相談に入れます。
4. お客様情報をどこまで扱うか
氏名、電話番号、メール、住所、支払い状況、相談内容は、扱い方を決めておきたい情報です。
誰でも見られる状態にしてよいのか。
外部の相談先へ共有するとき、名前や連絡先を伏せる必要があるのか。
この点は、画面の便利さより先に確認します。
5. 作った後に誰が見るか
公開後には、問い合わせ、入力ミスの修正、料金変更、スタッフ名変更、月ごとの確認が出ます。
社内で全部持つ必要はありません。
ただし、誰が最初に受けるのか、どこから相談先へ頼むのかは、契約前に話題にします。
相談前にできる5つの整理
完璧な仕様書を作る必要はありません。
次の5つを、箇条書きで残すだけで十分です。
- 昨日か先週に実際にあった依頼を1件選び、受付から返信までの流れを書く
- 電話、LINE、メール、紙、フォームのうち、どこから入る依頼が多いかを書く
- よくある例外対応を3つだけ書く
- 毎日見る人、直す人、最終確認する人を仮で書く
- 公開後に社内で直したいことと、相談先へ頼みたいことを分ける
ここで空欄があっても問題ありません。
むしろ、空欄は初回相談で確認する議題になります。
実務上の目安としては、「昨日の1件を説明できるか」を先に見ます。
昨日の1件を説明できれば、抽象的な機能名だけで話すより、相談先と現場のずれを減らしやすくなります。
契約前のすり合わせチェック
そのまま使える相談メモ
契約前の相談では、完成した仕様書よりも、今の業務が分かるメモの方が役に立つことがあります。
次のメモは、そのまま問い合わせや初回相談の下書きに使えます。
未定の項目は「相談で決めたい」と書いて構いません。
契約前のすり合わせメモをコピーできます
開発外注の前に、現場では当たり前になっている流れや例外を相談先へ伝えるためのメモです。未定の項目は「相談で決めたい」と書けます。
開発外注前にすり合わせたい内容： 【作りたいもの】 例：申込フォーム、予約管理、問い合わせ管理、業務アプリ 【今困っていること】 例：電話、LINE、メール、紙で受けた内容をあとから手元の表へ移していて、反映漏れが起きる 【実際にあった1件の流れ】 例：電話で変更を受ける → 紙に書く → 店長へ確認する → LINEで返信する → 夕方に表へ移す 【今使っている受付経路】 例：電話、LINE、メール、紙の受付票、フォーム 【よくある例外対応】 例：常連だけ電話で受ける、前日変更は店長が確認する、備品が足りない日は受けない 【毎日見る人】 例：受付担当、現場スタッフ、店長、事務担当 【内容を直す人】 例：氏名の誤字は受付担当、料金や受付時間は店長だけが直す 【最初に使いたい状態名】 例：未対応、確認中、返信済み、キャンセル 【扱うお客様情報】 例：氏名、電話番号、メール、住所、申込内容、支払い状況 【公開後に社内で持ちたいこと】 例：問い合わせ一次対応、軽い文面変更、月ごとの確認 【相談先へ頼みたいこと】 例：入力項目の追加、通知先の変更、画面構成の変更、不具合対応 【相談で決めたいこと】 例：最初にどこまで作るか、試作を挟むべきか、公開後の担当をどう分けるか
次にやること
まず、直近で受けた依頼を1件だけ思い出してください。
それは、電話、LINE、メール、紙、フォームのどこから来ましたか。
誰が最初に見ましたか。
どこへ写しましたか。
誰が最終確認しましたか。
この4つをメモできれば、開発外注の相談は始められます。
「失敗しないように、全部決めてから相談しなければ」と抱え込む必要はありません。
「ここまでは今の流れです。ここから先は相談で決めたいです」と伝えるところから始めましょう。
参考情報
- IPA, 情報システム・モデル取引・契約書（第二版）。情報システム開発の取引構造、契約時の仕様・進め方・確認方法に関する共通理解の重要性を確認。公開日 2020-12-22、最終更新日 2025-06-17。2026年7月21日参照。
- デジタル庁, デジタル社会推進標準ガイドライン。サービス・業務改革と情報システムの整備・管理に関する共通ルール、DS-100/110/120、テンプレート更新状況を確認。ページ最終更新日 2026-07-15、DS-100/110/120は2026-07-15更新、策定日または最終改定日 2026-06-12。2026年7月21日参照。
- GOV.UK Service Manual, How the discovery phase works。作る前に問題、利用者、制約、今の業務や周辺の流れを理解する考え方を確認。Published 2016-08-04、Last updated 2021-06-21。2026年7月21日参照。
- GOV.UK Service Manual, User research in discovery。利用者が今使っている道具や経路、困りごと、観察や聞き取り、既存データ確認の考え方を確認。Published 2016-11-18、ページ上で最終更新日は確認できず。2026年7月21日参照。
- IPA, 中小企業の情報セキュリティ対策ガイドライン。個人事業主や小規模事業者を含む中小企業向けの情報セキュリティ対策の考え方を確認。公開日 2016-11-15、最終更新日 2026-07-03。2026年7月21日参照。