問い合わせの電話を受けたあと、内容を紙に書き、夕方にスプレッドシートへ転記する。LINEで届いた追加希望をメールへ貼り直し、担当者へ確認してから返信する。そんな毎日の作業を減らしたくて、開発会社の問い合わせフォームを開いたところで手が止まっていませんか。

「何を作りたいですか」と聞かれても、画面や機能の名前までは決まっていない。今ある紙、メール、確認漏れ、転記の手間をどう説明すればよいのか分からない。ここで悩むのは自然です。

最初の相談文は、完成した仕様書でなくて大丈夫です。この記事では、今の仕事の流れと、最初に楽にしたい場面を伝えるための相談メモとして、初回の依頼文を組み立てます。

問い合わせ文で止まっていませんか？

「まだ何を作るか決まっていないのに、開発会社へ問い合わせてよいのだろうか」

たとえば、次のような場面です。

  • 電話で受けた内容を、あとで紙から管理表へ書き写している
  • LINE、メール、フォームの内容を一つの一覧へまとめ直している
  • 担当者へ確認している間に、お客様への返信が遅れている
  • 過去の申込内容を探すたびに、紙の束やメール履歴を見返している
  • 確認メールの文面を毎回少しずつ手で直している
  • 「この作業をシステム化したい」と思っても、機能名に置き換えられない

開発会社へ相談するとき、多くの方は「ログイン」「管理画面」「通知」「CSV出力」のような機能名を並べようとします。

でも、最初に大切なのは機能名ではありません。誰が、何に困っていて、どの作業を先に楽にしたいのかです。

そこが伝わると、開発会社は「まず試作で確認する」「既存サービスを組み合わせる」「本開発の前に整理する」など、現実的な進め方を提案しやすくなります。

先に結論

初回相談の依頼文には、次の7つを書ければ十分です。

  1. 今、どんな業務で困っているか
  2. その業務を、今は誰がどのように行っているか
  3. 紙、電話、LINE、メール、スプレッドシートなど、今使っている道具は何か
  4. 最初に楽にしたい流れはどこか
  5. 使う人は誰か
  6. まだ決まっていないことは何か
  7. 相談で一緒に決めたいことは何か

反対に、最初の問い合わせで次のことまで決め切る必要はありません。

  • 画面の細かい配置や色は、初回相談前に決めなくてよい
  • データベースの項目名は、今使っている紙や表を見ながら後で整理してよい
  • 外部サービスとのつなぎ方は、使いたいサービスが決まってから確認してよい
  • 正式な予算は、試す範囲や優先順位を見てから相談してよい
  • 完成版のすべての機能は、最初から一度に書き出さなくてよい

依頼文の目的は、相手へ完璧な答えを渡すことではありません。相談の入口を作ることです。

依頼文は仕様書ではありません

「仕様書」は、作るものの内容を細かくそろえるための文書です。画面、入力項目、処理の流れ、利用者、運用方法などを整理します。

一方で、初回の依頼文はそこまで細かくなくて構いません。

デジタル庁の標準ガイドラインでは、政府情報システムの整備や管理には手続・手順の共通ルールがあり、要件定義書や調達仕様書の標準テンプレートも用意されています（参考）。ただし、これは本格的な調達や開発で使う整理です。

中小企業や小規模事業の初回相談では、いきなり同じ粒度を目指すと手が止まります。まずは、開発会社が状況を理解できる材料を集めます。

GOV.UKのサービスマニュアルでも、作る前に問題を理解し、利用者が何を達成しようとしているか、今どんな制約があるかを学ぶ考え方が示されています（参考）。これは大きな公共サービス向けの資料ですが、相談前の整理にも使えます。

つまり、最初に書くべきなのは「こういう画面を作ってください」だけではありません。

次のような説明がある方が、話が早くなります。

  • お客様からの問い合わせを、今は電話とLINEで受けている
  • 受付担当が紙にメモし、夕方にスプレッドシートへ転記している
  • 担当者へ確認するまで返信できず、連絡漏れが起きる
  • まずは受付内容を一覧化し、担当者へ通知できるか試したい

このくらい具体的なら、まだ仕様が固まっていなくても相談できます。

どの形で相談する？4つの伝え方

依頼文には、いくつかの形があります。最初から正式な資料にする必要はありません。

相談の形向いているケース主なメリットデメリット・確認点
短い問い合わせ文

困りごとはあるが、作るものや予算がまだ決まっていない

最初の連絡をしやすく、相談で決めたいことをそのまま伝えられる

業務の流れが少なすぎると、相手が質問しないと状況をつかめない

相談メモ

紙、メール、スプレッドシートなど、今の資料を見ながら話したい

今の作業、使う人、困っている場面をまとめて伝えやすい

決まっていない項目を無理に埋めると、かえって誤解が生まれる

簡単な業務フロー

受付、確認、返信、集計など、複数の担当者をまたぐ作業がある

どこで転記や確認漏れが起きるかを一緒に見つけやすい

きれいな図にする必要はない。箇条書きや写真でも十分な場合がある

正式な仕様書・依頼書

発注先を比較したい、社内決裁が必要、見積条件をそろえたい

複数社へ同じ条件で相談しやすく、見積もりの前提を残しやすい

作成に時間がかかる。初期段階では、先に試作や整理が必要なこともある

初回相談なら、短い問い合わせ文か相談メモで十分です。正式な仕様書は、作る範囲や前提をそろえる段階で考えれば間に合います。

初回相談で伝える7項目

依頼文を書くときは、次の順番にすると読みやすくなります。

1. 今困っていることを書く

「業務を効率化したい」だけでは、相手はどこから聞けばよいか分かりません。

次のように、日常の場面で書きます。

  • 電話で受けた申込を紙に書き、あとでスプレッドシートへ転記している
  • LINEで届いた変更希望を担当者へ確認し、メールで返信している
  • 月末に参加者一覧を作るため、複数のファイルを見比べている

細かい機能名より、現場で起きている作業が伝わる方が有用です。

2. 今の流れを書く

「誰が、何を見て、次に誰へ渡すか」を書きます。

たとえば、次のような形です。

  • お客様が電話またはLINEで問い合わせる
  • 受付担当が紙に内容を書く
  • 現場担当へ空き状況を確認する
  • 受付担当がお客様へ返信する
  • 夕方に管理表へ転記する

この流れが分かると、開発会社はどこを自動化し、どこを人が確認するべきか考えやすくなります。

3. 使う人を書く

使う人が一人なのか、複数の担当者なのかで作り方は変わります。

  • 受付担当だけが使う
  • 現場スタッフもスマートフォンで確認する
  • 管理者だけが集計やCSV出力を使う
  • お客様もフォームから入力する

ここでは、役職名や人数の目安で構いません。名前や個人情報を出す必要はありません。

4. 最初に楽にしたい流れを書く

全部を一度に変えようとすると、相談が広がりすぎます。

まずは「最初に楽にしたい一つの流れ」を選びます。

  • 問い合わせ内容を一覧に集めたい
  • 担当者へ自動で通知したい
  • 確認メールを決まった文面で送りたい
  • 月末のCSV出力を楽にしたい

GOV.UKのユーザーストーリーの資料では、利用者、やりたいこと、理由を短く説明する考え方が紹介されています（参考）。専門的な形式にこだわる必要はありませんが、「誰が、何をしたいのか、なぜ必要なのか」は相談文にも入れておくと伝わります。

5. 今ある資料を書く

開発会社は、現物に近い資料を見ると状況を理解しやすくなります。

  • 紙の申込書や記入例がある
  • 今使っているスプレッドシートがある
  • お客様へ送っているメール文面がある
  • 手順書やチェックリストがある
  • よくある問い合わせの例がある

最初の問い合わせに添付しなくても構いません。「必要であれば共有できます」と書くだけでも十分です。

6. 決まっていないことを書く

決まっていないことを隠す必要はありません。

むしろ、先に書いておくと相談しやすくなります。

  • 画面の細かい項目はまだ決まっていない
  • 既存サービスで足りるか、個別開発が必要か分からない
  • 予算は大まかにしか決まっていない
  • まず試作で確認するべきか相談したい

「未定です」だけで終わらせず、「相談で決めたい」と添えると、相手も次の質問を出しやすくなります。

7. 相談で確認したいことを書く

最後に、初回相談で聞きたいことを書きます。

  • まず何を整理すればよいか
  • 小さく試すなら、どの範囲がよいか
  • 既存サービスで足りる部分はあるか
  • 開発する場合、見積もり前に何を決めるべきか

ここまで書ければ、依頼文としては十分です。

伝わりにくい依頼文の例

次のような依頼文は、相手が状況をつかみにくくなります。

業務効率化のため、管理画面と通知機能とCSV出力があるシステムを作りたいです。見積もりをお願いします。

この文章が悪いわけではありません。ただ、何を管理するのか、誰へ通知するのか、CSVを何に使うのかが分かりません。

次のように、現場の流れを少し入れるだけで相談しやすくなります。

電話とLINEで受けた申込を、受付担当が紙に書いてからスプレッドシートへ転記しています。担当者へ確認してから返信するため、確認漏れと返信遅れが起きています。まずは申込内容を一覧に集め、担当者へ通知し、月末にCSVで確認できる形を試したいです。

後者なら、まだ画面の細部が決まっていなくても、相談の入口になります。

送る前のチェックリスト

チェックが全部埋まらなくても問題ありません。分からない項目は、初回相談で確認する項目です。

そのまま使える相談メモ

初回相談メモをコピーできます

まだ決まっていない項目は「相談で決めたい」と書いて大丈夫です。問い合わせフォームやメールの下書きとして使えます。

開発相談をしたい内容：

【今困っていること】
例：電話、LINE、メールで受けた依頼を紙に書き写していて確認漏れが起きる

【今のやり方】
例：受付担当が紙に記入し、夕方にスプレッドシートへ転記している

【使う人】
例：受付担当2名、現場スタッフ5名、管理者1名

【最初に楽にしたい流れ】
例：問い合わせ受付 → 担当者確認 → お客様へ返信 → 管理表へ反映

【できれば入れたいこと】
例：通知、一覧画面、CSV出力、検索

【まだ決めていないこと】
例：画面の細かい項目、外部サービスとのつなぎ方、正式な予算

【相談で確認したいこと】
例：まず試作で確認した方がよいか、既存サービスで足りるか

【共有できる資料】
例：今使っている紙の記入例、スプレッドシート、通知メールの文面

次にやること

まず、今週中に実際に起きた問い合わせや申込を3件だけ選んでください。

次に、その3件について「どこから来たか」「誰が確認したか」「どこへ転記したか」「何に時間がかかったか」を短く書きます。

それだけで、相談文の材料になります。

Ready Mockの業務改善チェックでは、紙、電話、LINE、メール、転記、確認漏れのうち、どこから試作や自動化を考えるとよいか確認できます。問い合わせ文を書く前の整理にも使えます。

参考情報