電話で受けた依頼を紙に書き、あとでスプレッドシートへ転記する。LINEで届いた変更希望をメールへ貼り直し、担当者に確認してから返信する。そんな作業を減らしたくて開発会社を探し始めると、今度は「どこに相談すればよいのか」で手が止まることがあります。

検索すると、制作会社、システム会社、フリーランス、ノーコード支援、SaaS導入支援など、似た言葉が並びます。実績が多い会社がよいのか、料金が分かりやすい会社がよいのか、初回相談の時点では判断しにくいものです。

開発会社選びで大切なのは、有名かどうかより、自社の困りごとを一緒に分解してくれるかです。この記事では、初回相談で確認したい質問と、比較するときの見方を整理します。

開発会社選びで迷っていませんか？

「どの会社も良さそうに見える。でも、相談してから話が大きくなりすぎたらどうしよう」

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

  • 問い合わせフォームから3社へ連絡したいが、同じ内容をどう送ればよいか分からない
  • 「申込内容を一覧で見たい」「確認メールを自動で送りたい」「月末にまとめて確認したい」と書いてみたが、相手に伝わるか不安が残る
  • 料金の安さだけで選ぶと、あとで追加費用が出そうで怖い
  • 実績ページを見ても、自社の紙、電話、LINE、メールの運用に合うか分からない
  • 初回相談で何を聞けば、相性の良さを比べられるのか分からない

ここで迷うのは自然です。

開発会社のWebサイトだけを見ても、実際の進め方までは分かりません。だからこそ、初回相談では「作れますか」だけでなく、どう聞いてくれるか、何を確認してくれるかを見ます。

先に結論

開発会社を選ぶときは、最初から1社に絞り込まなくて大丈夫です。

まずは、同じ相談メモを2〜3社へ送り、次の7つを確認します。

  1. 今の業務の流れを、機能名ではなく日常の作業から聞いてくれるか
  2. 最初に作る範囲と、後回しにする範囲を分けてくれるか
  3. 既存サービスや手作業でよい部分も一緒に考えてくれるか
  4. 見積もりに含まれる作業と、含まれない作業を説明してくれるか
  5. 連絡方法、担当者、返答の目安が分かるか
  6. 個人情報やアカウント権限の扱いを確認してくれるか
  7. 作った後の修正、運用、問い合わせ対応まで話題に出してくれるか

金額だけで比べると、見えていない前提が残ります。

たとえば、A社は画面を作るところまで、B社は運用後の軽い修正まで含むかもしれません。C社は既存サービスで済む部分を提案してくれるかもしれません。同じ相談メモをもとに、返ってきた質問の質を比べると判断しやすくなります。

会社を比べる前に、相談内容をそろえる

開発会社を比較するとき、最初にそろえるべきものは「見積もり金額」ではありません。

先にそろえるのは、相談する内容です。

デジタル庁の標準ガイドラインでは、政府情報システムの整備や管理には共通ルールがあり、要件定義書や調達仕様書の標準テンプレートも用意されています（参考）。これは大きな調達向けの資料ですが、「前提をそろえて相談する」という考え方は、小さな開発相談にも使えます。

小規模な相談では、正式な仕様書を作る必要はありません。

ただし、次のような情報は同じ形で伝えた方がよいです。

  • 今は電話、LINE、メール、紙、スプレッドシートのどれを使っているか
  • 誰が受付し、誰へ確認し、誰がお客様へ返信しているか
  • どこで転記、確認漏れ、返信遅れが起きているか
  • 最初に楽にしたい流れはどこか
  • まだ決まっていないことは何か

GOV.UKのサービスマニュアルでも、作り始める前に、解決すべき問題、利用者、制約を理解する必要があると説明されています（参考）。開発会社選びでも同じです。最初に「何を作るか」だけを見るより、今の困りごとを一緒に理解してくれる相手かを見ます。

どこに相談する？代表的な選択肢

開発の相談先には、いくつかの形があります。どれが上位という話ではありません。

ここでいうSaaSは、予約、フォーム、顧客管理のように、インターネット上で使える既存サービスのことです。自社で一から作らず、月額や年額で使う形が多いサービスです。

自社の状況に合うかを見ます。

相談先の形向いているケース主なメリットデメリット・確認点初回相談で聞くこと
個人の開発者

小さな入力フォーム、確認メール、担当者への連絡など、範囲が比較的狭い

担当者と直接話しやすく、試作や小さな改修を始めやすい

代替担当がいない場合がある。保守、緊急対応、納品後の窓口を確認する

連絡が取れない期間、急ぎの不具合、引き継ぎ資料の扱いを確認する

小規模な開発会社

入力内容を見る画面、担当者への連絡、普段使うサービスとのつなぎ方などをまとめて相談したい

複数人で分担しやすく、相談から試作、本開発まで続けやすい

得意分野が会社ごとに違う。デザイン、業務整理、保守のどこまで含むかを見る

初回相談後に、誰が要件整理、開発、確認、運用相談を担当するか聞く

SaaS導入・業務改善支援

既存サービスで足りるか、連携や運用ルールを先に試したい

作る前に、予約、フォーム、顧客管理などの既存機能を使って試せる

サービスのプラン差、一覧を取り出せるか、解約時の扱い、つなげられる範囲を確認する

既存サービスで足りない部分が出たとき、個別開発へ進めるか聞く

大きめのシステム会社

社内決裁、複数部署、長期運用、厳しいセキュリティ確認が必要

体制、契約、保守、運用、セキュリティ確認をまとめて進めやすい

小さな試作には重い場合がある。最初の相談だけで費用や期間が大きくなりやすい

試作だけの相談ができるか、見積もり前に必要な資料量を確認する

表のどれか一つに決める必要はありません。

最初は、今の業務を小さく試せる相手へ相談し、本開発や長期運用が見えてきた段階で体制を広げる方法もあります。

初回相談で確認する7つの質問

初回相談では、専門用語を知らなくても聞ける質問にします。

1. 今の業務をどの順番で確認しますか？

良い相談は、いきなり画面や機能の話だけで進みません。

紙、電話、LINE、メール、スプレッドシートなど、今使っている道具を聞きます。誰が何を確認して、どこへ転記しているかも聞きます。

「まず今の流れを聞かせてください」と言ってくれる相手なら、作る前の整理に向いています。

2. 最初に作らない範囲も一緒に決められますか？

全部を一度に作ると、費用も確認項目も増えます。

初回相談では、最初に作る範囲だけでなく、後回しにする範囲も聞きます。

  • 確認メールや前日の案内メールは決まった文面でよい
  • 月末の集計は最初から自動化せず、一覧表をダウンロードして確認できればよい
  • 店長や事務担当だけが見る画面は最初に入れるが、スタッフ用の画面は後で考える

このように分けられると、相談が現実的になります。

3. 既存サービスや手作業でよい部分も提案してくれますか？

開発会社へ相談すると、全部を作る話になるとは限りません。

予約、フォーム、顧客管理、メール配信などは、既存サービスで始められる場合があります。

ただし、既存サービスにはプラン差、他のサービスとつなげる条件、一覧を取り出せるかの制限があります。SaaSやパッケージを使う場合の契約資料も、IPAのモデル取引・契約書では別の形として整理されています（参考）。

「作る部分」と「既存サービスに任せる部分」を一緒に分けてくれる相手かを見ます。

4. 見積もりに含まれる作業を説明してくれますか？

見積もりは、金額だけでは比較できません。

次のような作業が含まれるかを確認します。

  • 今の業務を聞いて整理する時間が含まれる
  • 画面案や試作を確認する時間が含まれる
  • 入力内容の確認、エラー表示、確認メールや案内文の作成が含まれる
  • 公開後の軽い修正や不具合対応が含まれる
  • 操作説明や引き継ぎ資料が含まれる

含まれない作業があること自体は問題ではありません。問題は、あとで分かることです。

最初に「ここまでは含みます」「ここから先は別相談です」と説明してくれる相手を選びます。

5. 連絡方法と担当者は分かりますか？

開発中は、細かな確認が何度も出ます。

そのため、連絡方法は早めに確認します。

  • 連絡はメール、チャット、定例ミーティングのどれを使うか
  • 返答の目安は当日、翌営業日、週次のどれか
  • 窓口は営業担当、開発担当、ディレクターの誰か
  • 急ぎの不具合はどこへ連絡するか

連絡のルールが曖昧だと、確認漏れや待ち時間が増えます。

6. 個人情報や権限をどう扱いますか？

申込、予約、問い合わせ、顧客管理を扱う場合、氏名、メールアドレス、電話番号などの情報が入ります。

個人情報保護委員会のガイドラインでは、利用目的、適正な取得、安全管理措置、委託先の監督などが整理されています（参考）。専門的な条文を初回から読み込む必要はありませんが、開発会社が情報の扱いを確認してくれるかは見ておきたい点です。

また、IPAの中小企業向けガイドラインでは、バックアップやクラウドサービス安全利用の手引きなど、事業者が取り組むべき情報セキュリティの観点がまとめられています（参考）。

初回相談では、次のように聞けば十分です。

  • お客様情報を扱う場合、閲覧できる人を分けられるか
  • 管理者アカウントを複数人で共有しない運用にできるか
  • データのバックアップや削除依頼はどう扱うか
  • 開発会社へ共有する資料に、不要な個人情報を入れない方がよいか

7. 作った後の修正や運用も相談できますか？

システムは公開して終わりではありません。

運用を始めると、文面を変えたい、入力項目を追加したい、一覧の並びを変えたい、といった調整が出ます。

次の点を聞いておくと安心です。

  • 公開後の軽い修正はどのくらい対応できるか
  • 月額の保守が必要か、必要な場合は何が含まれるか
  • 担当者が変わったとき、操作説明や引き継ぎ資料は残るか
  • 使わなくなったとき、データを取り出せるか

作った後の話まで確認してくれる相手は、現場の運用を見てくれている可能性が高いです。

初回相談で気をつけたい反応

初回相談では、相手を疑うためではなく、進め方が合うかを見るために確認します。

次のような反応が続く場合は、一度立ち止まります。

  • 今の業務の流れを聞かず、すぐに大きな機能一覧だけを出してくる
  • 「全部できます」と言うが、何を後回しにするかを話さない
  • 見積もりに含まれる作業と含まれない作業が分からない
  • 連絡方法や担当者が曖昧なまま進む
  • 個人情報やアカウント権限の話が出ない
  • 既存サービスで足りる可能性をまったく検討しない

もちろん、初回相談だけで全ては分かりません。

ただ、質問に対して丁寧に前提を確認してくれるかは見えます。

相談前チェックリスト

全部をきれいに埋める必要はありません。分からない項目は、初回相談で聞く項目です。

そのまま使える相談メモ

開発会社比較メモをコピーできます

同じ内容を複数の相談先へ送ると、返ってきた質問や提案を比べやすくなります。

開発会社へ相談したい内容：

【今困っていること】
例：電話、LINE、メールで受けた依頼を紙に書き、あとでスプレッドシートへ転記している

【今の業務の流れ】
例：受付担当が内容をメモ → 現場担当へ確認 → お客様へ返信 → 管理表へ転記

【最初に楽にしたい流れ】
例：問い合わせ内容を一覧に集め、担当者へ知らせ、返信漏れを減らしたい

【後回しでよいこと】
例：月次集計の自動化、スタッフ用の細かい画面、デザインの作り込み

【既存サービスで足りるか相談したいこと】
例：予約管理、申込フォーム、顧客管理、確認メール

【見積もり前に確認したいこと】
例：最初に作る範囲、含まれる作業、公開後の修正、保守の有無

【情報の扱いで確認したいこと】
例：お客様情報、管理者アカウント、バックアップ、削除依頼への対応

【共有できる資料】
例：紙の記入例、今の管理表、お客様へ送っているメール文面、よくある問い合わせ

次にやること

まず、候補の相談先を2〜3社だけ選びます。

次に、同じ相談メモを送ります。会社ごとに文章を変えすぎると、返ってきた回答を比べにくくなります。

返事が来たら、金額の前に次の3つを見てください。

  1. 今の業務を理解するための質問があるか
  2. 最初に作る範囲を小さくする提案があるか
  3. 作った後の運用や情報の扱いにも触れているか

この3つが見えると、初回相談の相性を判断しやすくなります。

Ready Mockの業務改善チェックでは、紙、電話、LINE、メール、転記、確認漏れのうち、どこから相談するとよいか確認できます。開発会社へ問い合わせる前の相談メモ作りにも使えます。

参考情報