業務システム開発の最初の打ち合わせで聞くこと｜後戻りを防ぐ

業務システム開発の初回の打ち合わせは、案件の成否がほぼ決まる場です。ここで聞き漏らした一つの前提が、実装が半分終わったあとに「そもそも違う」という形で戻ってきます。この記事では、初回の打ち合わせで必ず聞くべきことを質問の形で並べ、それをどの順番で、どう聞くかまで具体的に書きます。

結論から言うと、初回で目指すゴールは「全部を決めること」ではありません。目指すのは、見積もりが出せる状態と、決まっていないことの一覧を発注者と共有した状態の二つです。この二つが揃えば、後戻りはかなりの割合で防げます。

初回の打ち合わせで決まること、決まらないこと

業務システム開発を受ける側が最初につまずくのは、初回の打ち合わせに「要件を全部聞き出す場」という期待を持ってしまうことです。実際にはそうなりません。発注者の多くは、自分の会社の業務は完璧に説明できますが、それをシステムの機能に翻訳する言語を持っていません。翻訳するのは受ける側の仕事です。

初回のゴールは「見積もれる状態」に届かせること

初回で必要なのは、細かい画面仕様ではなく、規模を測るための輪郭です。誰が使うのか、いくつの業務が乗るのか、既存のデータをどこから持ってくるのか、いつまでに必要なのか。この四つが取れれば、精度は粗くても見積もりの幅は出せます。

逆に、初回でボタンの配置や画面の色を詰めるのは順番が違います。輪郭が決まる前に細部を決めると、輪郭が変わったときに細部の合意ごと壊れます。これが後戻りの最も典型的な形です。打ち合わせの冒頭で「今日は細かい画面の話ではなく、全体の形と優先順位を決めさせてください」と宣言しておくと、話が細部に落ちても引き戻せます。

発注者側も整理できていないという前提に立つ

発注者が「こういうシステムが欲しい」と言うとき、その言葉は多くの場合、解決策の形をしています。「在庫管理システムが欲しい」という要望の裏には、「棚卸しのたびに残業が発生している」「複数の販売チャネルの在庫がずれて欠品が出る」といった、もっと手前の困りごとがあります。

初回で聞くべきは、解決策ではなく困りごとです。解決策から入ると、発注者が思いついた形をそのまま作ることになり、作ったあとで「思っていたのと違う」が発生します。困りごとから入ると、より小さく安く解決できる案が見つかることもあり、その提案自体が信頼につながります。

私が最初にEC周りの業務改善を受けたとき、依頼は「受注データを自動で集計する仕組みが欲しい」でした。話を聞いていくと、本当に困っていたのは集計そのものではなく、集計結果を朝礼で口頭共有していて伝達ミスが起きることでした。結果として作ったのは集計ツールではなく、決まった時間に決まった形式で配信される通知でした。最初の質問を「何が欲しいですか」ではなく「いま何に一番時間を取られていますか」に変えていなければ、間違ったものを作っていました。

決まらないことは「決まらない」と記録する

初回で決まらないことは必ず出ます。問題は決まらないこと自体ではなく、決まっていないのに決まったつもりで進むことです。「あとで詳細を詰めます」で流した項目が、実装フェーズで爆発します。

決まらなかった項目は、その場で「未決定リスト」として口に出し、議事録に項目名と「いつまでに誰が決めるか」を書きます。この一手間があるだけで、後日「そんな話は聞いていない」という食い違いがほぼ消えます。

打ち合わせの前に用意しておく三つのもの

初回の打ち合わせの質は、当日の会話力ではなく、事前準備でほぼ決まります。準備なしで臨むと、聞き役に回って情報を集めるだけの場になり、相手の記憶に何も残りません。

仮説をぶつける準備

事前に業界や相手の事業内容を調べ、「おそらくこういう課題があるのではないか」という仮説を作って持ち込みます。仮説が外れても構いません。むしろ外れたときの相手の訂正の仕方に、本当の課題が現れます。

システム開発の受注で成約率を高めている会社の実務では、この仮説の準備が初回の中心に置かれています。

その工夫が、先に説明したPowerPointで30ページにもなる『仮説＋提案』の資料となるのだが、伊藤氏によれば「実際に話す内容にも工夫をしている」という。「会社紹介のときには、会社の紹介もしますが、メインで担当するプロジェクトマネージャーやシステムエンジニアが『どんな人柄か』を話します」（伊藤氏）。システム開発のプロジェクトは、数カ月から1年以上に及ぶこともある。長い付き合いとなるだけに『人となり』もプロジェクト成否の重要な要素になるだろう。そこで、『もしご発注いただけたら、御社の担当になるのはこんなメンバーです』と感じていただけるように人柄を紹介しているという。 出典: hnavi.co.jp

個人で受ける場合、資料を30ページも作る必要はありません。ただ、仮説を一枚の紙にまとめて画面共有する程度の準備はした方がいいです。口頭だけの仮説は流れますが、画面に映った仮説は相手が指を差して訂正してくれます。訂正された箇所こそが要件です。

自分の人となりが伝わる自己紹介

業務システムは納品して終わりではなく、運用と改修が続きます。発注者は技術力と同じくらい、この人と数か月やり取りできるかを見ています。実績の羅列だけを話すと、この判断材料が渡せません。

自己紹介では、これまでどんな業種の業務を触ってきたか、どういう進め方をするか、返信のペースはどれくらいか、詰まったときにどう相談するかを話します。特に返信のペースは、個人で受ける場合に相手が最も不安に思う点です。「平日は24時間以内に必ず一次返信を返します」といった具体的な約束は、抽象的な「丁寧に対応します」の何倍も安心材料になります。

議事録のひな形

打ち合わせが終わってから議事録の形式を考えると、書き上がるのが翌日になります。翌日になると、細かいニュアンスが抜け落ちます。事前にひな形を作っておき、打ち合わせ中に直接書き込むのが最も速く、最も正確です。

ひな形に入れる項目は、決定事項、未決定事項と決定期限、宿題（誰が何をいつまでに）、次回の日程の四つで足ります。打ち合わせの最後の数分でこの画面を共有し、「この認識で合っていますか」と読み上げると、その場で認識のずれが潰せます。

最初の打ち合わせで必ず聞く質問

ここからが本題です。業務システム開発の初回で、順番も含めて聞くべき質問を並べます。上から順に聞くと、話が自然につながります。

現状の業務は、いま誰がどうやっているのか

最初の質問は、システムの話ではなく現状の業務の話から入ります。「今この作業は誰がやっていますか」「どんな順番で進みますか」「どこで別の人に渡りますか」。この三つで業務の流れが見えます。

このとき、口頭の説明だけで理解した気にならないことが重要です。実際に使っているエクセルのファイル、紙の帳票、送っているメールの文面を見せてもらいます。現物には、口頭説明では絶対に出てこない例外処理が必ず含まれています。「この列、何に使っていますか」と聞くと、「ああ、これは特定の取引先のときだけ手で入れているんです」という答えが返ってきます。この例外が後戻りの種です。

この作業のどこが一番つらいのか

現状が見えたら、次はどこが痛いかを聞きます。「一番時間がかかっているのはどこですか」「ミスが起きるのはどこですか」「担当者が休んだときに困るのはどこですか」。

三つの質問はそれぞれ違う痛みを掘り当てます。時間は工数の削減、ミスは品質、属人化は継続性の問題です。どれを最優先に置くかで、作るべきものが変わります。全部やろうとすると予算も期間も膨らむので、初回のうちに優先順位を発注者の口から言ってもらいます。

誰が使うのか、その人はITにどれくらい慣れているのか

利用者の人数と、そのITへの習熟度は、設計に直結します。毎日使う担当者が数人なら操作の学習コストは払えますが、月に一度しか触らない人が広く使うなら、説明なしで触れる作りが要ります。

さらに、社外の人が触るのかも確認します。取引先が入力する画面があるなら、認証やセキュリティの要件が一段上がり、工数もまるごと変わります。ここを聞かずに見積もると、あとで大きくずれます。セキュリティ周りの知識は継続的に必要になる領域で、AI・マーケティング・セキュリティのお仕事では、この分野で在宅・業務委託として求められる役割の広がりが整理されています。

いま使っているシステムと、データをどうやりとりするか

業務システムが完全に独立していることはほとんどありません。会計ソフト、販売管理、勤怠、EC のカート。どこかとデータをやりとりします。

聞くべきは三点です。連携先のシステム名、その連携がAPI経由なのかCSVの手動アップロードなのか、そして誰がその連携先の設定権限を持っているか。三つ目が抜けがちですが、実務では最も詰まります。「連携できます」と技術的に判断しても、連携先のアカウント権限を持つ担当者が別会社で、依頼から設定まで数週間かかるということが起こります。既存システムの棚卸しと連携の設計は、業務システム開発の中で最も工数の読みが難しい領域です。この領域の仕事の全体像は、Web・業務システム開発のお仕事にまとまっています。

誰が決裁して、誰が使う側の代表なのか

初回に同席している人が決裁者とは限りません。むしろ、情報システム担当や総務の担当者が窓口で、決裁は役員というケースが多いです。

確認するのは二つの役割です。予算と契約を決める人と、仕様の細部を決める人。この二人が別なら、それぞれと合意する必要があります。さらに重要なのは、実際にそのシステムを毎日使う現場の担当者が誰かです。現場が一度も打ち合わせに出ないまま作られたシステムは、納品直後に「これでは使えない」と言われます。初回のうちに「途中で一度、実際に使う方に触っていただく回を作らせてください」と提案しておくのが効きます。

いつまでに必要で、その期日は何で決まっているか

期日は必ず理由とセットで聞きます。「年内に」と言われたとき、その理由が「なんとなく区切りがいいから」なのか「取引先との契約更新が年明けだから」なのかで、動かせるかどうかが全く違います。

理由が外部の締切に紐づいているなら、その締切から逆算して、最低限その日までに動いていなければならない機能を切り出します。全機能を期日に間に合わせるのが無理でも、優先度の高い機能だけ先に出す段階リリースなら成立することが多いです。この提案ができるかどうかが、初回の打ち合わせの価値を大きく左右します。

予算はどう考えているか

予算の質問は聞きにくいものですが、聞かないと双方が損をします。聞き方を「予算はいくらですか」から変えるのがコツです。「今回の投資として、どのくらいの規模感で社内の承認を取る想定ですか」「これまで似た投資をされたことはありますか」と聞くと、金額を言いにくい相手でも規模の感覚を返してくれます。

金額が出てこない場合は、こちらから幅で提示して反応を見ます。「機能を絞った第一段階と、フル機能の二案で概算を出しますが、どちらの方向でお考えですか」と聞けば、予算の当たりがつきます。エンジニア職の一般的な報酬水準を把握しておくと、この幅を示す根拠が持てます。職種ごとの水準はソフトウェア作成者の年収・単価相場で確認できます。

後戻りが起きる典型パターンと、初回で潰す方法

聞くべきことを聞いても、後戻りは起きます。起きやすいパターンは決まっているので、初回のうちに手を打ちます。

「あとで決めます」を放置してしまう

最も多いパターンです。初回で「そこは追って詰めましょう」と流した項目が、そのまま誰の宿題にもならず、実装が始まってから発覚します。

対策は単純で、未決定の項目に必ず「決定期限」と「決める人」を紐づけます。議事録に「帳票のレイアウト：9月15日までに経理部長が確定」と書くだけです。期限が来たら、こちらから確認の連絡を入れます。この確認の連絡があるかないかで、プロジェクトの進み方がまるで変わります。

画面の話を言葉だけで進めてしまう

「一覧画面で絞り込みができるようにしてください」という言葉から、発注者が想像している画面と受ける側が想像している画面は、まず一致しません。言葉は共通でも、頭の中の絵が違います。

初回のうちに、手書きでいいので画面のラフを描いて見せます。紙にペンで描いた四角と線で十分です。相手は絵を見ると「ここに日付も出したい」「この並び順は変えられますか」と具体的に反応します。この反応が、言葉だけの打ち合わせでは絶対に出てこない情報です。ツールを使うなら共有できるホワイトボード系のもので構いませんが、道具の準備に時間をかけるより、その場で描く速さを優先します。

現場の担当者が最後まで出てこない

窓口の担当者だけと話し続け、実際の利用者に一度も会わないまま納品すると、運用が始まった瞬間に不満が噴出します。窓口の担当者は業務全体を俯瞰していますが、日々の細かい手順は現場ほど知りません。

初回で「途中で現場の方に触っていただく回を入れたい」と提案し、その回をスケジュールに組み込みます。これは工数を増やす提案なので嫌がられそうに見えますが、実際には歓迎されます。発注者側も、現場から不満が出るリスクを認識しているからです。

保守と運用の話を初回でしない

納品したあと誰がデータを管理するのか、障害が起きたときにどこに連絡するのか、機能追加は誰に頼むのか。この話を初回でしないと、納品後に無償対応の要望が延々と続く関係になります。

初回のうちに「納品後の運用について、どういう体制をお考えですか」と一言聞いておきます。相手が考えていなければ、それ自体が提案の余地です。保守の契約を別に結ぶ形を早い段階で示しておくと、あとで切り出すより圧倒的に話が通ります。

聞き方を変えたほうがいい質問

同じことを聞くのでも、聞き方で得られる情報の質が変わります。避けたい聞き方をいくつか挙げます。

「どんな機能が欲しいですか」は、答えが出てこないか、思いつきの羅列になります。「今の作業で一番手間なのはどこですか」に変えます。前者は相手にシステム設計を求める質問で、後者は相手が確実に答えられる質問です。

「要件定義はできていますか」も避けます。専門用語で不安を煽る形になり、相手が構えます。「今の時点で決まっていることと、これから決めることを一緒に整理させてください」と言い換えると、相手が話しやすくなります。用語を相手の言葉に翻訳する力は、開発そのものと同じくらい重要な実務スキルです。文書のやりとりを標準的な形に整える基礎はビジネス文書検定のような体系でも扱われており、議事録や提案書の型を持っているかどうかで初回の印象は変わります。

「予算はおいくらですか」も、直球すぎると身構えられます。前述のとおり、規模感や過去の投資額を聞く形にします。

逆に、遠慮して聞かない方が損をするのは、他社にも相談しているかという質問です。これは失礼な質問ではなく、むしろ聞いた方が誠実です。他社と並行なら、こちらは比較されている前提で提案の粒度を上げます。相見積もりであることを隠されたまま進むより、双方にとって健全です。

打ち合わせの終わり方と、その日のうちにやること

初回の打ち合わせで、最後の数分の使い方が最も差がつきます。

議事録は当日中に送る

打ち合わせ中に書き込んだひな形を整えて、その日のうちに送ります。翌日でも遅くはありませんが、当日中に届く議事録は、それだけで仕事の速さの証明になります。

初回のやりとりでスピードが持つ意味について、システム開発会社の営業実務ではこう語られています。

まずは「発注者にとって『最初に連絡をくれたシステム開発会社』として記憶してもらうため」（伊藤氏）だ。ひとつの開発案件に複数のシステム開発会社が競合する中にあっては、自社を少しでも強く印象づけることが重要になる。「イメージとしては、発注者のメールの受信ボックスで自分たちが送ったメールが常に存在感を示しているような感じが理想です。そのためには、『こんなにすぐに返信メールをくれていた』とわかるように受信履歴を残す、これが大切になります」（伊藤氏）。 出典: hnavi.co.jp

個人で受ける場合、この速さは組織より出しやすい強みです。社内の承認を通す必要がないので、その日のうちに議事録も概算も出せます。競合が数日かけている間に届く一通は、記憶に残ります。

決まっていないことのリストを必ず添える

議事録に決定事項だけを書くと、読んだ相手は「順調に進んでいる」と誤解します。未決定事項を同じ分量で書き、それぞれに期限と担当を付けます。

このリストは、発注者にとっては宿題の一覧ですが、同時に「この人はプロジェクトを管理してくれる」という信頼の材料になります。後戻りを防ぐ実務であると同時に、受注確度を上げる営業行為でもあります。

次のアクションを一つに絞って提示する

議事録の最後に、次に何が起きるかを一行で書きます。「9月10日までに概算のお見積もりをお送りします」「未決定事項が確定次第、詳細のお見積もりに切り替えます」。

複数の選択肢を並べると、相手は決められません。次の一手を一つに絞って提示すると、話が前に進みます。相手が別の希望を持っていれば、そのときに言ってくれます。

打ち合わせを支える道具の選び方

初回の打ち合わせで使う道具は、凝ったものである必要はありません。むしろ、相手が導入していない道具を持ち込むと、最初の十分間が接続トラブルで消えます。判断の基準は「相手が今すでに使っているものに合わせる」の一点です。

オンラインの会議ツールは、相手の会社が標準で使っているものに合わせます。こちらの都合で別のツールを指定すると、相手側で管理部門の許可が必要になり、それだけで日程が一週間ずれることがあります。事前のメールで「普段お使いの会議ツールに合わせますので、URLを発行いただけますか」と書いておくと、この摩擦がなくなります。

画面共有をしながらその場で書き込む道具は、共有ドキュメントかホワイトボードのどちらかです。文字で残す議事録は共有ドキュメント、画面のラフや業務の流れ図はホワイトボードが向いています。ただし、相手がホワイトボード系の道具に不慣れなら、無理に使わず紙に描いてカメラに映す方が速いです。道具の操作説明に時間を使うのは本末転倒です。

打ち合わせの録音や録画は、必ず事前に許可を取ります。「聞き漏らしを防ぐために記録を残してよろしいですか、社内共有はしません」と一言添えれば、断られることはほとんどありません。録音があると、議事録を書くときに細かいニュアンスを拾い直せます。ただし、録音があるから安心して打ち合わせ中にメモを取らないのは逆効果です。メモを取っている姿そのものが、相手に「真剣に聞いてもらえている」という感覚を与えます。

タスクと未決定事項の管理は、専用の道具を入れるより、共有ドキュメントの表で始めるのが確実です。項目名、決める人、期限、状態の四列があれば足ります。プロジェクトが動き出して項目が増えてきた段階で、必要なら専用の道具に移せばよく、初回から重い仕組みを入れると相手が見なくなります。

見積書と提案書の形式も、この段階で確認しておきます。相手の社内稟議に添付する書類なので、決まった様式がある会社も少なくありません。「稟議に上げる際に決まった形式はありますか」と聞くだけで、あとから作り直す手間が消えます。この確認を忘れると、内容は完璧なのに形式が合わずに差し戻される、という無駄が発生します。

見積もりと契約に繋げるときの判断基準

初回の打ち合わせが終わったあと、その案件を受けるかどうかの判断が要ります。全部受けるのが正解ではありません。

判断の軸は三つです。一つ目は、決裁者と現場のどちらとも接点が作れそうかどうか。窓口の担当者だけで完結し、他の関係者に会わせてもらえない案件は、途中で必ず揉めます。二つ目は、期日に理由があるかどうか。理由のない急ぎは、途中でさらに前倒しになります。三つ目は、未決定事項に期限を付けることを相手が受け入れたかどうか。この提案を嫌がる相手は、進行中も決めてくれません。

三つのうち二つが怪しい案件は、見積もりを保守的に出すか、第一段階を小さく切って様子を見る形にします。いきなり大きな契約を結ぶより、小さく始めて相性を確かめる方が、双方にとって傷が浅く済みます。

契約の形も初回のうちに触れておきます。請負なのか準委任なのか、検収の基準は何か、支払いのタイミングはいつか。細部は契約書を作る段階で詰めますが、「請負でお考えですか、それとも工数ベースでしょうか」という一言は初回で出しておくべきです。ここが噛み合っていないまま見積もりを出すと、金額の議論が始まる前に前提から作り直しになります。

ネットワークやインフラの知識が求められる案件では、こちらが対応できる範囲を初回で正直に伝えることも大切です。守備範囲外の部分を曖昧にしたまま受けると、後工程で確実に破綻します。インフラ領域の基礎を体系的に押さえたい場合、CCNA（シスコ技術者認定）のような資格の学習範囲が、自分の対応可能範囲を言語化する助けになります。

現場を長く見てきた立場からの観察

フリーランスと在宅ワークの市場を20年運営してきた立場から言えば、業務システム開発で長く続く人は、技術力が突出している人ではありません。初回の打ち合わせで、相手が言語化できていないことを代わりに言葉にしてあげられる人です。

発注者は、自分の業務は完璧に説明できます。ただ、それをシステムの要件に翻訳する言葉を持っていません。この翻訳を初回でやってみせた瞬間、相手は「この人は分かってくれる」と判断します。技術の説明を丁寧にする人より、業務の理解を示す人の方が選ばれています。運営者として見てきた限りでは、この差は案件の単発と継続を分ける最大の要因です。

もう一つ、直接取引の構造についても触れておきます。仲介の手数料が乗らない形で取引すると、同じ予算で発注者はより多くを頼めますし、受ける側の手取りは厚くなります。この構造が効いてくるのは、実は金額そのものより関係の質です。手数料の分だけ値引きを求められる圧力がないので、初回の打ち合わせで安く見せる必要がなく、必要な工数を正直に話せます。正直に工数を話せる関係は、後戻りが起きたときにも「相談してみよう」という行動につながります。手数料0%の意味は、手取りの厚さだけでなく、こうした会話のしやすさにも現れます。

海外の発注者と直接やりとりする場合も、初回の打ち合わせで押さえるべきことは基本的に同じです。ただ、時差と契約慣行の違いが加わるぶん、未決定事項の管理はより厳密になります。海外案件の受注の進め方はUpworkの使い方ガイド｜日本人フリーランスが海外案件を取る方法で、応募から契約までの流れが整理されています。

初回の打ち合わせは、営業の場でも技術の場でもなく、翻訳の場です。相手の業務の言葉を、作れるものの言葉に置き換える。その作業をその場でやってみせることが、後戻りを防ぐ最大の予防策であり、同時に次の依頼を呼ぶ唯一の方法です。

よくある質問

Q. 初回の打ち合わせはどのくらいの時間を確保すべきですか？

一時間から一時間半が現実的です。それより短いと現状の業務を聞ききれず、長すぎると相手の集中が切れて細部の議論に流れます。最初の三十分で業務の流れと困りごと、次の三十分で利用者と連携先と期日、最後に決裁体制と未決定事項の確認という配分にすると収まります。足りなければ二回目を設定する方が、無理に詰め込むより結果が良くなります。

Q. 発注者が何を作りたいか整理できていない場合はどうすればよいですか？

機能を聞くのをやめて、現状の業務を聞く形に切り替えます。今その作業を誰がどんな順番でやっているか、どこで時間がかかりミスが出るかを一つずつ聞くと、必要な機能は自然に浮かび上がります。実際に使っているエクセルや帳票を見せてもらうのが最短で、口頭説明では出てこない例外処理が現物からは必ず見つかります。

Q. 初回の打ち合わせで予算の話を切り出しても失礼になりませんか？

聞き方を変えれば問題ありません。金額を直接尋ねるのではなく、どのくらいの規模感で社内の承認を取る想定か、過去に似た投資をしたことがあるかという形で聞きます。それでも出てこなければ、機能を絞った案とフル機能の案の二案を提示して反応を見ます。予算を確認しないまま見積もりを出す方が、双方の時間を無駄にします。

Q. 議事録はどこまで細かく書くべきですか？

決定事項、未決定事項と決定期限、宿題の担当者、次回の日程の四つが揃っていれば十分です。会話の逐語録は不要で、むしろ読まれなくなります。重要なのは未決定事項を決定事項と同じ分量で書き、それぞれに期限と決める人を紐づけることです。この一手間が後日の食い違いをほぼ消します。

Q. 現場の担当者が打ち合わせに出てこない場合はどうしますか？

初回のうちに、途中で実際の利用者に触ってもらう回をスケジュールに組み込む提案をします。工数が増える提案に見えますが、発注者側も現場から不満が出るリスクは認識しているので、多くの場合は歓迎されます。それでも会わせてもらえない案件は、納品後に揉める確率が高いため、見積もりを保守的にするか段階を小さく区切る判断が必要です。