開発会社の相見積もりで 3〜4 社の初回商談を終え、提案書と見積書が出揃った段階で、多くの発注担当者がこう感じます。「実績も技術スタックも価格帯もほぼ同じ。決め手が見当たらない」。この状態で最後の意思決定を下す軸として浮かび上がるのが、開発会社との「相性」です。しかし相性という言葉はあまりに定性的で、社内会議に持ち込んでも「A 社は雰囲気が良かった」「B 社の担当者は話が合いそうだった」といった感覚的な意見の応酬に終わり、合意形成に至らないケースが少なくありません。
一方で、開発プロジェクトの成否を左右する変数として「相性」は決して感覚論ではありません。長期プロジェクトでは、実装スキルの差以上に、コミュニケーションの粒度・意思決定のスピード・トラブル発生時の姿勢といった「働き方の噛み合い」が成果を大きく左右します。過去に「大手だから安心」で選んで担当者の相性が合わず疲弊した、または「安さで選んで運用フェーズで手戻りが多発した」という経験を持つ発注者ほど、この感覚を切実に理解しています。
問題は、相性を「観察可能なシグナル」に分解する共通言語がないことです。1〜2 回の限られた商談時間で、雰囲気や空気感を根拠にせず、具体的な観察事実として相性を測る方法を持てていない。だから社内会議で「B 社の担当者と相性が良さそうです」と発言しても、他のメンバーが同じ結論に至れず、議論が停滞します。
本記事では、この課題に答えるために、開発会社の相性をスキル以外の 5 つの評価軸に分解し、各軸を初回商談で検証する 15 の質問を提供します。さらに、答えの内容だけでは差がつかない場面で決定的になる「答え方」の 5 つの観察ポイントと、商談後 30 分で複数社を横並び比較できる簡易評価シートを紹介します。
読み終えたときには、次の商談で「何を聞き、何を観察し、どう記録するか」が明確になり、感覚ではなく観察された事実で最終判断を下せる状態を目指します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
なぜ開発会社の「相性」が実績や技術力より長期プロジェクトを左右するのか
実績・価格が横並びになった相見積もり後、最後に効くのは相性
相見積もりのプロセスをきちんと踏むと、最終候補に残るのは「実績・技術スタック・価格が近い」会社です。RFP に沿って選定してきた以上、これは当然の結果です。しかし裏を返すと、ここから先の意思決定は数値化された比較表では下せないということでもあります。
なお、本記事は相見積もり後の「最終判断」に絞って解説しています。相性以前の総合的な選定プロセス（実績・技術・価格・体制の比較や RFP 設計）を先に整理したい方は開発会社の選び方 総合ガイドを、大手・中堅・地域密着といったタイプ選定から迷っている段階の方は開発会社のタイプ別比較を先に参照してください。
システム開発は数ヶ月から数年にわたる継続的な協業であり、契約後に日々発生するのは「軽微な仕様変更をどう扱うか」「進捗が遅れたときにどう報告してもらうか」「本番リリース直前に見つかった不具合をどう共有するか」といった、実装スキルではなく「働き方」に関する意思決定です。ここで噛み合わないと、月次会議は毎回消耗戦になり、プロジェクト管理コストが当初想定を大きく上回るケースも少なくありません（筆者が発注者から相談を受けた事例では、追加会議・仕様調整・関係修復のための工数が積み重なり、当初計画を超えるコスト超過が発生していました）。
だからこそ、実績や技術力で差がつかなくなった段階では、「一緒に働いて楽か・重いか」を先読みする軸として相性が最後の決定打になります。相性は「あったらいい」要素ではなく、「なければ運用フェーズで確実に問題化する」必須要素なのです。
相性ミスマッチで起きる典型トラブル3パターン
相性のミスマッチが具体的にどう問題化するかを整理すると、次の 3 パターンが典型的です。
第一に、コミュニケーション粒度のズレによる情報の齟齬です。発注側は「週次で細かく状況を知りたい」のに、開発側は「マイルストーン単位で報告する文化」だと、進捗の見えなさに不安が募り、会議で追加確認を繰り返すことで両者とも疲弊します。技術力があっても、情報の出し方が噛み合わないと信頼関係は蓄積されません。
第二に、意思決定スタイルの違いによる仕様変更の衝突です。発注側は「まず作ってみて感触を見ながら調整したい」のに、開発側が「仕様を確定してから着手する契約前提」だと、軽微な変更の依頼のたびに「見積り再提示ですか？」「これは追加費用ですか？」というやり取りが発生し、心理的な距離が開いていきます。
第三に、トラブル報告の遅れによる手戻りの拡大です。相性が悪い相手には「都合の悪いことを早めに言えない」空気が生まれます。結果、リリース直前に大きな不具合が発覚し、対応期間の圧迫と信頼低下が同時に起きます。逆に、初回から率直に議論できる関係であれば、小さな兆候の段階で共有され、被害は最小化されます。
いずれのトラブルも、実装スキルの高低とは独立に発生します。相性は「あとで直せる」ものではなく、契約前の初回商談で読み解いておくべき変数です。
相性は「感覚」ではなく「観察可能なシグナル」に分解できる
ここで大切なのは、相性を「なんとなく合う・合わない」で語らないことです。相性は次の 2 つに分解できます。
- 働き方の型に関するシグナル：コミュニケーション頻度、意思決定プロセス、トラブル対応の初動、改善提案の姿勢、対等な議論を歓迎するかといった、目に見える行動パターン
- 答え方に表れる非言語シグナル：即答するか一呼吸置くか、「わからない」と言えるか、こちらの状況を確認する質問を返すか、といった対話の中の観察可能な振る舞い
初回商談は、この両者を同時に観察できるほぼ唯一の機会です。次の章からは、前者を測るための 5 つの評価軸と 15 の質問、後者を測るための 5 つの観察ポイントを順に紹介します。感覚論ではなく観察された事実として相性を記録できれば、社内会議で「相性で選ぶ」ことが説明可能な意思決定になります。
「相性」を5つの評価軸に分解する（スキル以外の判断フレーム）
相性を漠然と語らず、5 つの軸に分解します。各軸は独立して観察でき、次の章の質問リストと 1 対 1 で対応します。5 軸フレームの狙いは、担当者ごとの印象を「どの軸で良く／どの軸で懸念があったか」と切り分けて記録可能にすることです。
軸1 コミュニケーション文化
日々の情報流通のスタイルを指します。テキスト中心か対面中心か、同期的（会議・電話）か非同期的（Slack・メール）か、報告の粒度は細かいか粗いか、といった行動パターンです。発注側と開発側の文化が近いほど、情報の齟齬は減り、日々の意思決定コストが下がります。
たとえば、発注側が「Slack で気軽に相談したい」文化なのに、開発側が「相談は週次会議に集約する」文化だと、簡単な確認事項が翌週まで滞留し、開発スピードが失速します。文化そのものに優劣はありませんが、噛み合わないと確実にストレスの発生源になります。
軸2 意思決定スタイル
プロジェクトを進める上での判断プロセスを指します。合意重視か委任重視か、スピード優先か慎重優先か、階層的（承認プロセスが多層）かフラット（現場判断が広い）か、といった軸です。
意思決定スタイルは、「軽微な仕様変更を現場で決められるか、上長承認が必要か」「トラブル時に現場が即断できるか、稟議が必要か」といった実務に直結します。発注側が高速な意思決定を期待しているのに、開発側が階層的な承認プロセスを持つ組織だと、日常のやり取りで摩擦が生まれます。
軸3 トラブル発生時の姿勢
問題が起きたときに、隠すか早期に開示するか。原因説明の解像度が「なぜそうなったか」を含めた構造的説明か、「たまたま起きた」で終わるか。この軸は、契約後の信頼関係の質を最も強く決めます。
初回商談では、過去の失敗事例をどこまで具体的に話せるかで判断できます。抽象的な失敗談しか出てこない相手は、契約後もトラブルを構造化して共有する習慣が薄い可能性が高いといえます。逆に、生々しい失敗と学びをオープンに語れる相手は、契約後もトラブルを早めに開示する文化を持っています。
軸4 学習・改善姿勢
言われたことをやる「受注生産型」か、改善提案を持ち込む「共創型」か、という軸です。要件通りに納品してくれれば十分という発注もあれば、業務改善のアイデアも一緒に議論したい発注もあります。ここの期待値がズレると、発注側は「言われたことしかやらない」と感じ、開発側は「余計なことを言うと嫌がられる」と感じるすれ違いが起きます。
学習・改善姿勢は、「開発途中で見つかった業務プロセスの矛盾を、誰が指摘するか」を左右します。開発側が能動的に指摘する文化であれば、業務側では気づけなかった改善点が仕様に反映されます。
軸5 対等パートナー観
下請け意識で仕事を受けるか、対等な議論相手として振る舞うか、という軸です。「発注者の言うことは全て正しい」という前提で動く会社は、一見従順で扱いやすく見えますが、仕様の矛盾や技術的リスクを指摘してもらえず、後工程で問題化します。
対等パートナー観のある会社は、こちらの要件に対して「なぜそれが必要か」を確認し、必要であれば代替案を提示します。この対等性は、長期プロジェクトで「発注側が気づかない盲点」を補完する重要な機能です。
初回商談で相性を見極める質問リスト15問（5軸×3問）
前章で定義した 5 軸それぞれについて 3 問ずつ、合計 15 問の質問を提供します。各質問には「なぜこの質問で相性が測れるか」「良い答え方の一例」「注意すべき答え方の一例」の 3 点セットを添えます。網羅性より意思決定支援を優先し、15 問に絞り込みました。次の商談で持参し、順番に聞いていくだけで、5 軸すべてに関する観察材料が揃うように設計しています。
カテゴリA コミュニケーション文化を測る3問
Q1. 日常のやり取りは、どのツールでどの程度の頻度を想定していますか？（Slack・メール・電話・定例会議の使い分け）
- なぜ聞くか: 情報流通のツールと頻度は、日々の摩擦の大きさを最も強く決めます。相手の「普段のやり方」がこちらの期待とどれくらいズレているかを確認します。
- 良い答え方の一例: 「日常の質問と共有は Slack で即時、意思決定が必要な議題は週次定例で 30〜60 分。過去のプロジェクトではこの組み合わせでうまく回りました」など、ツールと頻度と根拠がセットで語られる。
- 注意すべき答え方の一例: 「基本はメールで、必要に応じて会議します」など、粒度も頻度も抽象的で、こちらのニーズを確認する質問が返ってこない。
Q2. 進捗共有はどの粒度で、誰から誰に、どの頻度で行われますか？
- なぜ聞くか: 進捗の見えなさは発注側の不安の最大要因です。「タスク単位」「機能単位」「マイルストーン単位」のどの粒度で報告される予定かを事前に握っておく必要があります。
- 良い答え方の一例: 「週次で機能単位の進捗表を PM から共有し、月次で全体ロードマップに対する進捗をレビューします。急ぎの変動は Slack で即時共有します」。
- 注意すべき答え方の一例: 「定例で報告します」だけで、粒度・担当者・頻度が具体化されない。
Q3. 想定と違うことが起きたとき、どのタイミングで、誰が、どう連絡してくれますか？
- なぜ聞くか: 予定外の事象への初動対応が「即時共有」なのか「次回会議まで持ち越し」なのかは、コミュニケーション文化の核心です。
- 良い答え方の一例: 「営業日中に発覚した事象は当日中に PM から Slack でファーストコンタクトし、影響範囲がまとまり次第 24 時間以内に共有します」。
- 注意すべき答え方の一例: 「そういう事態にならないよう管理します」と、発生前提の質問に対して発生自体を否定する答え。
カテゴリB 意思決定スタイルを測る3問
Q4. 軽微な仕様変更（工数半日程度）はどのプロセスで扱っていますか？
- なぜ聞くか: 契約後に必ず発生する「小さな変更」の扱いに、意思決定スタイルが最もよく表れます。
- 良い答え方の一例: 「工数半日以内の変更は PM 判断で当日中に着手し、月次で変更履歴をまとめてレビューします。工数を超える場合は事前に見積り提示します」。
- 注意すべき答え方の一例: 「全ての変更は書面で見積り再提示します」など、粒度に応じた柔軟性がない。
Q5. 開発チーム内で、日々の実装判断はどこまで現場で決められますか？
- なぜ聞くか: 現場の裁量範囲は、意思決定スピードを大きく左右します。「上長承認が必要」な範囲が広いと、待ち時間がプロジェクト全体を遅らせます。
- 良い答え方の一例: 「技術選択・実装手法は現場判断、要件解釈が必要な事項は PM を経由、契約範囲に影響する事項は営業に上げます、と 3 層で切り分けています」。
- 注意すべき答え方の一例: 「全て社内レビューを通します」など、層が単一で判断のスピードが読めない。
Q6. こちらが判断を保留した場合、どのタイミングでどう催促してもらえますか？
- なぜ聞くか: 発注側の意思決定が滞ることは実際によくあります。これを黙って待つのか、能動的に催促するのかは、プロジェクト進行の質を左右します。
- 良い答え方の一例: 「判断保留から 3 営業日経過すると PM から Slack と口頭で確認します。1 週間経過するとリスク影響を明記した書面でエスカレーションします」。
- 注意すべき答え方の一例: 「お客様のご判断をお待ちしています」で終わる、受動的な姿勢。
カテゴリC トラブル発生時の姿勢を測る3問
Q7. 過去に担当されたプロジェクトで、うまくいかなかった事例と、その原因・学びを教えてください
- なぜ聞くか: トラブルをどう構造化して振り返るかは、契約後の失敗共有文化を予測する最良の指標です。
- 良い答え方の一例: 具体的な事例（時期・規模・トラブルの種類）を挙げ、原因を「要件の解釈違い」「見積り時の楽観」「体制設計」など構造的に分解し、その後の再発防止策までセットで語れる。
- 注意すべき答え方の一例: 「大きな失敗はありません」「守秘義務があり話せません」で終わる、または「たまたまお客様都合で遅延しました」など他責的な説明。
Q8. トラブル発生時、社内ではどのプロセスで情報が集約・意思決定されますか？
- なぜ聞くか: 「担当者個人に依存する対応」なのか「組織として仕組み化されている対応」なのかを見ます。
- 良い答え方の一例: 「重大事象は SEV レベルで分類し、SEV1 は 1 時間以内に全関係者を招集、SEV2 は当日中に対応方針を決定するとルール化しています」。
- 注意すべき答え方の一例: 「PM が状況を判断して対応します」など、判断基準もエスカレーション経路も明示されない。
Q9. こちら（発注側）の運用ミスや業務側の遅延でプロジェクトに影響が出た場合、どう扱われますか？
- なぜ聞くか: 相手側の落ち度ではない場面での姿勢に、対等パートナー観の伏線としても意思決定スタイルとしても本音が出ます。
- 良い答え方の一例: 「原因の切り分けを共同で行い、追加工数が発生する場合はその根拠を明示した上で協議します。責任配分より、まず影響最小化を優先します」。
- 注意すべき答え方の一例: 「契約範囲を超える対応は追加費用になります」と、費用の話から入る（協業姿勢が薄い）。
カテゴリD 学習・改善姿勢を測る3問
Q10. RFP や要件を読んで、疑問に思った点や引っかかった点があれば教えてください
- なぜ聞くか: 初回商談の時点で能動的に疑問を出せるかは、契約後の改善提案スタンスを予測します。「疑問なし」と答える相手は、あとになっても改善提案を持ち込まない可能性が高いといえます。
- 良い答え方の一例: 「要件の X と Y の関係が実装上矛盾する可能性があるので、優先度の考え方を確認したいです」など、具体的な指摘が返ってくる。
- 注意すべき答え方の一例: 「特にありません、記載通り実装可能です」だけで終わる。
Q11. プロジェクト進行中に、業務改善につながる気づきがあった場合、どう扱われますか？
- なぜ聞くか: 「言われたことをやる」か「気づきを共有する」かの文化差が、この質問で明確になります。
- 良い答え方の一例: 「月次ふりかえりで気づきを共有する枠を設けており、業務側の改善提案としてお持ちします。採用は業務側判断です」など、共有プロセスと判断権限の切り分けが明示される。
- 注意すべき答え方の一例: 「ご要望に応じて対応します」だけで、能動的な共有プロセスがない。
Q12. 過去のプロジェクトで、発注側の要件を『別の方法で実現した方が良い』と提案された事例はありますか？
- なぜ聞くか: 具体的な提案事例の有無は、共創型か受注生産型かを最も強く示す証拠です。
- 良い答え方の一例: 具体的な事例（要件の課題・代替案・議論のプロセス・最終判断）を語れる。
- 注意すべき答え方の一例: 「基本的にお客様のご要件通りに進めます」と、代替提案の経験がない、または能動的に提案しない方針。
カテゴリE 対等パートナー観を測る3問
Q13. 今回の要件で、技術的なリスクや懸念がある部分を教えてください
- なぜ聞くか: 契約を取りたい段階でリスクを口に出せるかは、対等パートナー観の本質を示します。ネガティブ情報を隠さない相手は、契約後も率直な議論ができます。
- 良い答え方の一例: 「Y の部分は要件通り実装可能ですが、想定利用量が増えるとパフォーマンスに懸念があります。代替設計を 2 案検討したいです」。
- 注意すべき答え方の一例: 「特にリスクはありません」「全て問題なく対応可能です」と、リスクをゼロと言い切る。
Q14. こちら（発注側）の判断が技術的に見て良くないと思ったとき、どう伝えますか？
- なぜ聞くか: 「発注側の言うことに従う」だけの相手なのか、根拠を持って異論を伝えられる相手なのかを見ます。
- 良い答え方の一例: 「まず判断の背景を確認し、技術的なリスクを構造的に説明した上で、こちらの推奨案を提示します。最終判断はお客様に委ねますが、意見はきちんと申し上げます」。
- 注意すべき答え方の一例: 「お客様のご判断を尊重します」で終わる、または「お客様の判断が最優先です」と即答する。
Q15. 契約範囲の解釈が曖昧な事項について、御社ではどう扱いますか？
- なぜ聞くか: 契約範囲の解釈は必ず発生する論点です。ここで「白黒つけずに協議する」姿勢か「厳密に契約書で判定する」姿勢かで、日々の関係性が大きく変わります。
- 良い答え方の一例: 「契約書の解釈が分かれる事項は、まず現場で協議し、大きな影響がある場合のみ営業を交えて再定義します。目的達成を優先し、範囲論争は最小化します」。
- 注意すべき答え方の一例: 「契約書の記載通りに扱います」だけで、協議プロセスがない。
相性は「答えの中身」より「答え方」に表れる5つの観察ポイント
前章の 15 問に対して、多くの会社は「準備してきた回答」を返します。準備の質は差がつきますが、それでも答えの内容だけで大きな差がつかない場面が出てきます。そこで最後の決定打になるのが、「答え方」に表れる非言語シグナルです。以下 5 つの観察ポイントを、質問中と回答中に意識的に見ることで、答えの内容だけでは掴めない相性の核心が見えてきます。
観察1: 即答するか、一呼吸置いてから答えるか
即答は流暢さの証ではなく、単に「準備された答えを再生している」だけかもしれません。逆に、一呼吸置いて「今のご質問は、日常的な変更のことか、大規模な変更のことか、どちらを想定されていますか？」と確認してから答える相手は、状況に応じて考える文化を持っている可能性が高いといえます。長期プロジェクトでは、この「一呼吸置く」姿勢がトラブル時の判断ミスを減らします。
観察2: 「わからない」と正直に言えるか、無理に答えを埋めようとするか
初回商談は営業活動でもあるため、「わからない」と言うことに抵抗があるのは自然です。しかし、明らかに事前情報がない事項に対して「持ち帰って確認します」と即座に言える相手は、契約後も知ったかぶりせず正確な情報を伝える文化を持っています。逆に、憶測で埋めようとする相手は、契約後にも同じことをする可能性が高いです。
観察3: 質問に答える前に、こちらの状況を確認する質問を返すか
一方通行の Q&A ではなく、対話のキャッチボールが成立するかを見ます。「Q7 の失敗事例」を聞いたとき、「どのような観点で参考にされたいですか？」と確認してから話し始める相手は、こちらのニーズに合わせて情報を提供する姿勢を持っています。用意された答えを流すだけの相手は、契約後も「聞かれたことだけ答える」スタンスになりがちです。
観察4: 提案書を読み上げるだけか、その場で議論・修正に応じるか
提案書のスライドをそのまま読み上げるだけの商談は、契約後の議論の柔軟性も低いことが多いです。逆に、こちらの反応を見ながらページを飛ばしたり、その場でホワイトボードに書いて説明したり、「今のご質問を受けて提案の Y の部分は考え直します」と即座に言えたりする相手は、契約後の議論でも柔軟に対応してくれる可能性が高いといえます。
観察5: ネガティブ情報（リスク・過去の失敗）を自ら口にするか、隠すか
Q7・Q13 で失敗やリスクを直接聞きますが、それ以外の場面で自発的にネガティブ情報を口にするかも重要です。「実は前回の類似案件では Y の部分で 1 週間遅延が出ました、今回は Z を先に検証する予定です」など、聞かれていないリスクを自ら開示する相手は、契約後も早期共有の文化を持っています。
これら 5 つの観察ポイントは、質問リスト 15 問と並行して見るものです。商談中はメモを取る余裕がない場面もあるため、次の章で紹介する評価シートに商談後 30 分以内に転記し、印象が新鮮なうちに記録することをおすすめします。
商談後30分でできる相性の簡易評価シート
前章までの 5 軸フレームと 15 の質問と 5 つの観察ポイントを、商談後 30 分で数値化するための簡易評価シートを紹介します。感覚を数値化することで、社内会議で「B 社は 5 軸のうち 4 つで A 社を上回っています」という具体的な議論が可能になり、感覚論から抜け出せます。
5軸×5段階の評価テンプレと採点基準
各軸について 1〜5 の 5 段階で評価します。基準は次の通りです。
点数 | 状態 |
|---|---|
5 | こちらの期待とほぼ一致。契約後の摩擦がほぼ想定されない |
4 | 期待とほぼ一致するが、一部の運用で調整が必要 |
3 | 中立。良くも悪くもない。追加の商談で見極めが必要 |
2 | ズレが大きく、契約後に恒常的な摩擦が予想される |
1 | ミスマッチが明確。契約後にプロジェクト管理コストが大幅増となる懸念 |
商談後 30 分以内に、各軸について「なぜその点数か」の根拠を 1〜2 行で記録します。根拠を書かないと後日の議論で「なぜその点数だったか」を思い出せず、感覚論に逆戻りします。根拠には、質問への回答内容（カテゴリ A〜E で観察した具体的発言）と、答え方の観察ポイント（観察 1〜5 で気づいた振る舞い）の両方を含めることが理想です。
評価軸 | A社 | B社 | C社 | 根拠メモ |
|---|---|---|---|---|
軸1 コミュニケーション文化 | 4 | 3 | 4 | (例) A: Slack + 週次で具体的な運用ルールあり |
軸2 意思決定スタイル | 3 | 4 | 3 | (例) B: 3層の裁量切り分けが明確 |
軸3 トラブル発生時の姿勢 | 5 | 3 | 2 | (例) A: 過去の失敗を構造的に共有 |
軸4 学習・改善姿勢 | 3 | 4 | 4 | (例) B: RFP に対する具体的な指摘あり |
軸5 対等パートナー観 | 4 | 5 | 2 | (例) B: 技術的リスクを自ら開示 |
合計 | 19 | 19 | 15 | — |
複数社を横並びで比較するときの見方（絶対点数より相対差）
このシートを使うときの最大の注意点は、絶対点数ではなく相対差で見ることです。上の例では A 社と B 社が同点ですが、内訳を見ると強みが異なります。A 社はコミュニケーションとトラブル対応が強く、B 社は意思決定スタイルと対等パートナー観が強い、という傾向が読み取れます。
自社にとって重要な軸はプロジェクトの性質で変わります。仕様変更が多発するプロジェクトなら軸 2（意思決定スタイル）と軸 4（学習・改善姿勢）が重要ですし、既存業務を安定運用する保守プロジェクトなら軸 1（コミュニケーション文化）と軸 3（トラブル発生時の姿勢）が重要です。単純な合計点で選ぶのではなく、「今回のプロジェクトで重要な軸で 4 以上を取っているか」を優先判断基準にします。
社内会議に持ち込むときは、このシートを画面共有し、各軸の根拠メモを 1 つずつ読み上げます。「A 社は軸 3 で 5 点、根拠は前回プロジェクトの失敗を SEV レベルの運用ルールとセットで説明できたこと」といった具体的な観察事実で議論すると、他のメンバーも同じ判断基準に立って評価できるようになります。
数値以前に「これが出たら組めない」危険サイン
数値評価の前段として、次のサインが出た場合は評価シートに載せる前に候補から外すことを推奨します。相性の問題以前に、健全な協業関係が構築できない可能性が高いためです。
- 質問に対して価格の話でごまかす: 相性やプロセスの質問に対して「価格でご相談させてください」と話をすり替える。契約後も本質的な議論を避ける可能性が高い。
- 社内政治や他社批判の話が多い: 「以前担当した会社は Y だったのでうまくいかなかった」など、他社批判で自社を持ち上げるスタイル。契約後も責任転嫁の文化を持ち込む可能性がある。
- 担当者を交代させたがる: 初回商談で信頼関係を築いた担当者が、契約後に別のメンバーに交代する予定。営業と実行部隊が分離している組織は、契約後のコミュニケーション品質が読めない。
- 契約書の話を早すぎるタイミングで持ち出す: 初回商談で「NDA を巻きましょう」「契約書の文面を送ります」ばかりが先行し、プロジェクトの中身への関心が薄い。手続き優先の姿勢は、契約後のトラブル対応でも「まず契約書」というスタンスになりがち。
- こちらの発言を最後まで聞かず遮る: 相手の質問中に自分の話を被せる。契約後も対話のキャッチボールが成立しない可能性が高い。
これらの危険サインは、5 軸の点数が高くても十分な理由になります。「相性が良い会社」は、5 軸の点数が高いこと以上に、これらの危険サインが出ないことが前提条件です。
まとめ｜相性を可視化して、感覚ではなく観察で最終判断する
開発会社の相性は、実績や技術力の差が縮まった相見積もり後の最終判断で決定的な役割を果たします。しかし相性を感覚論のまま扱っていると、社内会議で議論が進まず、最終判断を先延ばしにするか、根拠の薄い直感で決めることになります。
本記事では、相性を次の 3 つの道具で観察可能にする方法を紹介しました。
- 5 つの評価軸（コミュニケーション文化・意思決定スタイル・トラブル発生時の姿勢・学習改善姿勢・対等パートナー観）で相性を分解する
- 15 の質問（5 軸 × 3 問）で各軸の実態を初回商談で確認し、良い答え方と注意すべき答え方の判別基準を持つ
- 5 つの観察ポイント（即答か一呼吸か / わからないと言えるか / こちらの状況を確認するか / 議論に応じるか / ネガティブ情報を自ら口にするか）で非言語シグナルを読む
そして、これらを商談後 30 分以内に 5 軸 × 5 段階の評価シートに転記することで、複数社の横並び比較が可能になり、社内会議で「感覚」ではなく「観察された事実」で議論できる状態になります。
次にとるアクションはシンプルです。次の商談前に 15 の質問リストと評価シートを印刷して持参します。商談中は質問を投げながら回答内容と答え方の両方を観察し、商談直後 30 分以内に評価シートを埋めます。すべての候補社について同じ手順を踏んだあと、シートを社内会議に持ち込み、根拠メモを 1 つずつ確認しながら最終判断を下します。
なお、スタートアップ特有のスピード感や成長ステージを踏まえて開発会社を選定したい場合は、あわせてスタートアップ向け開発会社の選び方も参考にしてください。相性軸の見極めと組み合わせることで、ステージに合った意思決定がしやすくなります。
相性は感覚ではなく、観察できます。この観察の道具を持っているかどうかが、長期プロジェクトの成否を左右する意思決定の質を決めます。次の商談から、ぜひ試してみてください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- 15問すべてを1回の初回商談で聞く時間がありません。どう絞ればいいですか？
時間が限られる場合は各軸1問（計5問）に絞り込み、自社プロジェクトでリスクが大きい軸（仕様変更が多いなら軸2、保守中心なら軸1・軸3）を優先し、残りは追加ヒアリングシートで後日回収してください。網羅性より意思決定に直結する軸を優先することが重要です。
- 商談担当者と実際にプロジェクトへ入る実務担当者が違う場合、評価はどう扱えばいいですか？
営業担当者の評価はあくまで参考値とし、契約前に実務担当者（PM・エンジニア）を交えた顔合わせを依頼した上で、同じ15問の一部を改めて確認することを推奨します。担当者交代そのものが本文で紹介した危険サインの一つでもあります。
- 相見積もりをしておらず1社しか商談していません。それでも評価シートは使えますか？
相対比較ができない場合でも使えます。絶対点数を基準に5軸すべて3点以上を最低ラインとしつつ、本文で紹介した危険サインが1つも出ていないかを重点的に確認し、出ていれば点数が高くても再検討してください。
- フリーランス・個人事業主に発注する場合もこの質問リストは使えますか？
使えますが、「社内プロセス」を問う質問（Q2・Q8など）は個人の判断基準や過去の対応実績に読み替えて質問してください。組織としての仕組み化の有無よりも、本人の説明の一貫性や過去事例の具体性を見る軸として活用します。
- 評価者が複数人いて、同じ商談でも点数にばらつきが出ます。どう扱えばいいですか？
点数を平均して丸めるのではなく、各評価者が記録した根拠メモを持ち寄って議論してください。点数差は評価者ごとに注目していた場面が異なるだけのことが多く、根拠のすり合わせ自体が社内会議での有益な判断材料になります。
