商談中のデモ、何を見て開発会社を見極めるか。契約前チェックリスト

商談の終盤、開発会社の担当者がノートPCを開き、「実際の画面をお見せしますね」とデモを始める。この瞬間、多くの後継社長は前のめりになる。先代の代からずっと紙とExcelで回してきた業務が、目の前の画面できれいに動いているのを見せられると、「これで長年の悩みが解決する」という期待が一気にふくらむからだ。

しかし、この「デモを見て感動する瞬間」こそ、実は最も判断を誤りやすい場面でもある。デモは開発会社が最も見せたい部分だけを、最も条件の整った状態で見せる場だ。実際に自社の業務データを入れて、自社の従業員が使ったときに同じように動くとは限らない。提案書の比較はできても、「デモで何を見て、何を質問すればよいか」を体系立てて教えてくれる相手は、社内にも社外にもほとんどいない。

この記事では、刷新の相談先を見極めるために、提案書で見るべきポイントで提案書段階の見極め方を扱ったのに続けて、実際に商談で行われるデモ・トライアルの段階で何を確認し、どう質問すれば、契約後の「思っていたのと違う」を防げるかを具体的に解説する。IT用語に詳しくなくても、この記事のチェックリストに沿って見れば、開発会社の実力と自社との相性をかなりの精度で見極められるようになる。

なお、この記事は契約直前の「見極め方」に絞った内容で、契約後に小さく試しながら進める発注の仕方は小さく発注して試す、承継後のPoC発注のすすめで扱っている。まだ相見積もりの段階で条件をそろえられていない場合は、先に相見積もりを取るとき、条件をそろえるための伝え方を読んでおくと、この記事のチェックリストがより活きる。

この記事で分かること

• デモで「感動」と「実力」を切り分けて見るための3つの視点（動くか・自社の業務に合うか・運用後を見据えているか）
• デモの場でその場で聞くべき質問と、聞いても濁される場合に何を疑うべきか
• トライアル（試用）を依頼できる場合の頼み方と、断られたときの代替案
• 承継社長が陥りやすい「デモの見た目に流される」失敗パターンとその回避策

ただし、デモで良い印象を持てたからといって、それだけで契約を決めてよいわけではない。この記事の後半では、デモの印象が良かった開発会社ほど見落としがちな「デモには映らない部分」についても触れる。まずは全体の流れをつかんでから、実際の商談に臨んでほしい。

なぜ「デモで感動する」ことが判断を誤らせるのか

デモという場は、構造的に「開発会社に有利」にできている。担当者は自社の得意なシナリオ、あらかじめ整えたサンプルデータ、慣れた操作手順でデモを進める。これは決して不誠実というわけではなく、営業の場としてはむしろ当然のことだ。問題は、発注側がその構造を意識しないまま「動いているところを見た」という事実だけで安心してしまうことにある。

先代の代から紙・Excel・古いシステムで業務を回してきた会社ほど、この落差は大きく感じられる。今まで何十分もかかっていた集計が、デモ画面ではワンクリックで表示される。この「劇的なビフォーアフター」を見せられると、細部を確認する前に「もうこれでいい」という気持ちになりやすい。これは特別なことではなく、多くの発注担当者が経験する自然な心理反応だ。

システム開発会社の提案評価に関する解説記事でも、プレゼンやデモの後に評価が提案書段階から逆転することがあると指摘されている。つまり、デモの印象は評価を大きく動かす力を持つ一方で、その印象は「実力」そのものではなく「見せ方」に左右されやすいという性質があるということだ。だからこそ、デモを見る側には「何を確認すれば見せ方に惑わされずに実力を判定できるか」という視点があらかじめ必要になる。

デモの持つこの性質を理解したうえで、次の章から具体的な確認ポイントに入っていく。

視点1: そのデモは「本当に動いている」のか、「動いて見えるだけ」なのか

最初に確認すべきは、目の前で見せられているものが実際に機能しているシステムなのか、それとも画面遷移だけを作り込んだ「見た目のモックアップ」なのかという点だ。

モックアップとプロトタイプの違い

デモには大きく分けて2つの段階がある。

どちらが良い・悪いという話ではない。提案の初期段階でモックアップを見せられるのは自然なことだ。問題は、発注側が「これはどちらなのか」を意識しないまま話を進めてしまうことにある。

その場で聞くべき質問

デモを見ながら、次のように率直に聞いてみてほしい。

• 「今動いている画面は、実際にデータを処理していますか。それとも画面の見た目を作ったものですか」
• 「この画面の裏側で、今どんな処理（計算・検索・保存）が行われていますか」
• 「もし今、私が実際の取引データを100件入れたら、同じように動きますか」

この質問に対して、担当者が処理の仕組みを具体的に説明できるかどうかが、最初の分かれ目になる。「詳しい話は契約後に」「そこは別のエンジニアが担当なので」といった形で説明が濁される場合、まだ設計が固まっていない段階である可能性を疑ったほうがよい。

視点2: そのデモは「自社の業務」に合わせて見せているか

2つ目の視点は、デモの内容が発注側の業務に個別に合わせて作られているか、それとも汎用的なサンプルをそのまま見せているだけかという点だ。

汎用デモと個別デモの見分け方

多くの開発会社は、複数の見込み客に同じ「鉄板デモ」を見せている。これ自体は効率的な営業手法として自然なことだが、承継社長が見極めるべきは「その鉄板デモが、自社の業務にどこまで当てはまるか」という点になる。

先代の代から続く独自の商習慣（特定の取引先だけ特殊な単位で発注する、季節によって計算式が変わる等）がある会社ほど、汎用デモがそのまま使えることは少ない。デモを見ながら、以下を確認してほしい。

• 「このデモは弊社向けに用意していただいたものですか、それとも標準のデモ環境ですか」
• 「弊社が今使っている〇〇（先代の代からの独自の帳票・計算方法）は、この画面のどこで扱うイメージですか」
• 「このデモに出てくる項目名・帳票の並び順は、弊社の実際の帳票に合わせて変えられますか」

3つ目の質問への回答で、「そのまま使ってください」「なるべく標準機能の範囲でお願いします」という答えが返ってきた場合は要注意だ。パッケージ製品であれば標準機能に業務を合わせる前提もあり得るが、フルスクラッチやカスタム開発を謳っている会社が「標準に合わせてほしい」と繰り返す場合、実態はカスタマイズ性の低い汎用パッケージの可能性がある。フルスクラッチとパッケージ、承継後の刷新はどちらを選ぶ？も参考に、提案されている開発形態と実際のデモの柔軟性が一致しているかを見てほしい。

「先代の頃からの業務用語」を通じさせてみる

もう一つ有効なのが、社内でしか通じない業務用語や帳票名をあえてそのまま使って質問してみることだ。「うちで言う『〇〇台帳』はこの画面のどこに当たりますか」というように聞いたとき、担当者が的確に対応関係を答えられれば、事前に業務内容をきちんとヒアリングして臨んでいる証拠になる。逆に、聞き返されたり曖昧な返答しか返ってこない場合は、まだ自社の業務理解が浅い段階だと判断してよい。

視点3: デモには映らない「運用後」を見据えているか

3つ目の視点は、最も見落とされやすい。デモという場は「導入直後、うまく動いている状態」を見せるものであり、「1年後、日々の運用で何が起きるか」までは基本的に見せてもらえない。

運用フェーズについて確認すべきこと

以下の質問は、デモそのものではなく、デモの前後の会話で確認しておきたい項目だ。

• 「導入後、データの入力ミスに気づいたとき、誰がどこまで修正できますか」
• 「先代の代からのExcelデータを、このシステムに移行する場合の作業は誰が担当し、どのくらいの期間がかかりますか」
• 「システムに障害が起きたとき、何時から何時まで対応してもらえますか。休日・夜間は含まれますか」
• 「担当者が異動・退職した場合、引き継ぎはどう行われますか」

これらは、IPA（情報処理推進機構）が公開する要件定義の枠組みの中でも「非機能要求」と呼ばれる領域に近い。機能（何ができるか）だけでなく、可用性・保守性・移行性といった「動き続けるための条件」を、契約前にどこまで言語化できているかが、後々のトラブルを左右する。IPAの非機能要求グレードでは、可用性・性能拡張性・運用保守性・移行性・セキュリティ・システム環境の6分類で要求レベルを段階的に整理する枠組みが示されており、専門用語を使いこなす必要はないが、この6つの観点を頭の片隅に置いて質問するだけでも、確認漏れをかなり防げる。

先代の代からの独自システムが「動いているのに誰も詳しい経緯を知らない」状態になっていた経験がある会社ほど、この「運用後」の視点を軽視しないでほしい。同じ轍を、新しいシステムで繰り返さないための質問がここに集まっている。

「運用後の費用」もデモの場で確認しておく

もう一つ、デモの場で聞いておくと後々の交渉が楽になるのが、運用開始後にかかる費用の内訳だ。初期費用の見積もりばかりに気を取られ、月々の保守費用やサポート費用の内訳を後回しにしてしまうと、契約後に「思っていたより月額が高い」という事態を招きやすい。

• 「保守費用には、障害対応・軽微な仕様変更・法改正対応のうち、どこまでが含まれますか」
• 「利用者数やデータ量が増えた場合、追加費用が発生するタイミングはどこですか」
• 「契約期間中に機能追加を依頼した場合、都度見積もりになりますか、それとも一定の範囲は保守費用に含まれますか」

これらの質問への回答が具体的であるほど、契約後の想定外の請求を防ぎやすくなる。保守契約の内容そのものをどう確認すべきかは、先代から引き継いだ保守契約、内容を確認せず放置していませんかでさらに詳しく扱っている。

デモの形式による見え方の違い(対面・オンライン・録画)

デモには、対面・オンライン会議・録画動画という3つの実施形式があり、それぞれ確認できる情報の質が異なる。商談の日程調整を担当していると見落としがちだが、どの形式でデモを受けるかによって、こちらが取れる主導権の大きさが変わってくる。

対面デモ

会社の会議室やショールームに出向いて受けるデモは、担当者の表情や、その場での質問への反応速度を直接観察できるという利点がある。想定外の質問をぶつけたときに、資料を見ずにどこまで答えられるかは、対面のほうが見極めやすい。一方で、移動の手間がかかるため、比較したい会社が多いほど日程調整の負担も大きくなる。

オンライン会議形式

Web会議ツールを使ったデモは、画面共有で操作画面を見ながら進む。録画をその場で依頼できる場合があり、「後日、社内の他の役員や古参社員にも見せたい」という要望を伝えやすい形式でもある。ただし、通信環境やカメラのオンオフによって、担当者の反応が見えにくくなることがある点は意識しておきたい。

録画動画・オンデマンド視聴

あらかじめ用意された説明動画を見るだけの形式は、質問をその場で投げかけられないという弱点がある。この形式しか提示されない場合、それが「まず概要をつかんでもらうための一次案内」なのか、「個別の質問に答える気がない」ことの表れなのかを見極める必要がある。動画を見た後、必ず個別の質疑応答の場(対面またはオンライン)を設定してもらえるかを確認してほしい。

形式ごとの使い分けの目安

先代の代から一つの開発会社としか付き合いがなかった会社ほど、比較そのものに慣れておらず、最初に打診してきた会社の形式にそのまま従ってしまいがちだ。複数社を比較する場合は、意識して形式をそろえる(すべてオンラインにする等)と、後で比較しやすくなる。

複数社のデモを比較するための記録シート

2〜3社のデモを見た後、記憶だけを頼りに比較しようとすると、話が上手だった会社の印象ばかりが強く残り、実際の適合度を見誤りやすい。デモの直後、その場でメモを取り、以下のような形式で記録しておくことを推奨する。

このシートは凝ったものである必要はなく、手元のノートに項目を書き出すだけでも十分に効果がある。重要なのは、デモを見た直後、記憶が鮮明なうちに記録することだ。数日経ってから複数社の印象を思い出そうとすると、話し方が上手だった会社、資料が見やすかった会社の印象だけが強く残り、実際の技術力や適合度の評価がぼやけてしまう。

費用感の異なる案件で、デモ評価の力の入れ方を変える

すべての商談に、この記事で紹介した質問を同じ密度でぶつける必要はない。投資規模に応じて、確認の深さを調整するという考え方も持っておきたい。

小規模案件(既製のSaaS・パッケージ導入が中心)

月額数万円程度のSaaSツール導入であれば、無料トライアル期間が用意されていることが多く、この記事のチェックリストのうち「トライアルの可否」を最優先で確認すればよい。デモの見極めに時間をかけすぎるより、実際に触ってみて判断するほうが早い場合が多い。

中規模案件(パッケージ+カスタマイズ)

フルスクラッチとパッケージ、承継後の刷新はどちらを選ぶ？で扱ったような、既存パッケージをベースにカスタマイズを加える案件では、「標準機能でどこまでカバーできるか」と「カスタマイズでどこまで対応可能か」を、デモの場で明確に切り分けて聞く必要がある。この記事の視点2で紹介した質問は、特にこの規模の案件で威力を発揮する。

大規模案件(フルスクラッチ・基幹刷新)

投資額が大きくなるフルスクラッチ開発では、契約前の段階で完成品に近いデモを見せてもらえること自体が少ない。この場合は、要件のまとめ方。何から刷新するか固まっていない社長のための資料作りで整理した要件を伝えたうえで、「同種の要件に対して、過去どのようなシステムを作った実績があるか」という過去の類似事例のデモや画面キャプチャを見せてもらう形が現実的になる。この場合、視点3で紹介した「運用後」の質問により重点を置いて確認してほしい。

トライアル(試用)を依頼できるか、頼み方と代替案

デモよりもさらに踏み込んだ確認方法として、本番導入前の一定期間、実際にシステムを試用させてもらう「トライアル」がある。

トライアルを依頼するタイミングと伝え方

トライアルは、投資額の大きいカスタム開発では難しいことが多いが、既製のパッケージ製品やSaaS型のサービスであれば、無料または有償の試用期間を用意している会社も少なくない。契約規模が大きくなりそうな場合、以下のように率直に相談してみる価値がある。

• 「契約前に、実際の担当者数名で1〜2週間ほど触らせていただくことは可能ですか」
• 「試用の際、弊社の実際のデータ(の一部)を使って試すことはできますか」
• 「トライアル中に出た疑問点は、どなたに、どのくらいの頻度で相談できますか」

カスタム開発でトライアル自体が難しい場合の代替案としては、小さく発注して試す、承継後のPoC発注のすすめで扱っているように、本開発の前に小規模な検証工程を別途発注する方法がある。デモ・トライアルの見極めで不安が残った場合、いきなり本契約に進むのではなく、この段階を挟むことも検討してほしい。

トライアルを断られた場合に疑うべきこと

「トライアルは前例がない」と断られること自体は、特に高額なカスタム開発案件では珍しくなく、それだけで開発会社の信頼性を疑う必要はない。むしろ注意すべきは、断り方だ。

• 理由を明確に説明した上での丁寧な断り(投資規模・工数の観点から難しい等) → 自然な対応
• 「うちはそういうのはやっていないので」と一方的に片付ける、または話をそらす → 危険な開発会社のサイン10選、承継社長が見極めるポイントに挙げた兆候と重なる部分がないか、他の質問への対応もあわせて確認したほうがよい

デモに古参社員を同席させるかどうかの判断

デモに誰を同席させるかも、意外と見落とされがちな論点だ。後継社長一人で判断してしまうか、実際にシステムを使う現場の古参社員を同席させるかで、その後の社内の受け止め方が大きく変わる。

同席させるメリット

実際に日々の業務でシステムを使うのは、多くの場合、後継社長本人ではなく現場の担当者だ。古参社員をデモに同席させることで、「自分たちの業務にどこまで合っているか」を、後継社長には分からない実務の勘所から評価してもらえる。また、選定プロセスに現場の声を反映させたという事実そのものが、後の刷新への合意形成を進めやすくする効果もある。古参社員の抵抗が予想される会社ほど、この段階から巻き込んでおく価値は大きい。

同席させる際の注意点

一方で、古参社員が「今のままでいい」という気持ちを強く持っている場合、デモの場で否定的な発言を繰り返し、商談の空気を悪くしてしまうことがある。同席を依頼する前に、「今日は良い悪いを決める場ではなく、今のやり方とどう違うかを一緒に見てほしい」という趣旨を事前に伝えておくと、話がまとまりやすい。同席者の人選や声のかけ方に迷う場合は、「デジタル化するなら辞める」と言われたら。刷新と離職リスクの向き合い方も参考にしてほしい。

同席させない場合の代替案

日程が合わない、あるいは複数社の比較段階でまだ絞り込めていない場合は、無理に同席させる必要はない。その場合は、デモの録画や画面キャプチャを持ち帰り、後日あらためて現場の意見を聞く機会を設ける形でも代替できる。重要なのは、最終候補が1〜2社に絞られた段階で、必ず一度は現場の目を通すことだ。

承継社長が陥りやすい3つの失敗パターン

ここまでの視点を踏まえたうえで、実際の商談でよく見られる失敗パターンを3つ紹介する。自分に当てはまる部分がないか、確認しながら読んでほしい。

パターン1: 見た目の完成度の高さに満足し、業務適合性を確認しない

デモの画面デザインが洗練されているほど、「これだけ作り込める会社なら大丈夫だろう」と安心してしまいがちだ。しかし、画面デザインの美しさと、自社の業務に合わせて作り込めるかどうかは、まったく別の能力だ。視点2で紹介した質問を、デザインの印象に流される前に必ず投げかけてほしい。

パターン2: 一度のデモで即決してしまう

先代の代から刷新が滞っていた会社ほど、「やっと解決策が見つかった」という高揚感から、初回のデモで即断してしまうことがある。しかし、1社のデモだけでは比較対象がなく、そのデモの質が業界内でどのレベルにあるのか判断できない。最低でも2〜3社のデモを比較したうえで判断することを強くすすめる。相見積もりを取るとき、条件をそろえるための伝え方で紹介している「条件をそろえて依頼する」考え方は、デモの比較にもそのまま当てはまる。

パターン3: 質問すること自体に遠慮してしまう

商談の場で、専門用語が分からないことを理由に質問を控えてしまう後継社長は少なくない。しかし、この記事で紹介した質問は、いずれもIT専門知識を前提としない、事実確認のための質問だ。むしろ、こうした質問に丁寧に答えられない、あるいは面倒くさそうな態度を見せる開発会社があれば、それ自体が契約後の関係性を占う重要な情報になる。分からないことを分からないまま流さず、その場で確認する姿勢を持つことが、承継後の発注では特に重要になる。

パターン4: 「先代の付き合い」への配慮からデモの評価を甘くしてしまう

先代の代から付き合いのある開発会社の場合、もう一つ特有の失敗パターンがある。「長年の付き合いがあるから」「先代の顔を立てて」という理由で、デモの内容を厳しく評価すること自体に気が引けてしまうケースだ。

しかし、長年の付き合いがあることと、今回の刷新案件に対する技術力・提案力が十分であることは、本来別の話だ。付き合いの長さへの配慮は、デモの評価が終わったあと、契約するかどうかを決める最終段階で考慮すればよい。デモの場では、他社と同じ基準で評価することを自分の中でルール化しておくと、後になって「あのとき甘く見てしまった」と悔やむ事態を避けやすい。乗り換えそのものの判断軸に迷う場合は、開発会社の乗り換え判断フロー、承継後いつ・どの手順で切り替えるかも参考にしてほしい。

デモ・トライアル評価チェックリスト

商談に臨む前に、以下の項目をあらかじめメモしておくと、その場で聞き漏らしを防げる。

• [ ] 見せられているのはモックアップかプロトタイプか、その場で確認したか
• [ ] デモは自社向けに個別に用意されたものか、汎用デモかを確認したか
• [ ] 先代の代からの独自帳票・独自の計算方法への対応可否を質問したか
• [ ] 運用後のデータ修正・障害対応・担当者交代時の引き継ぎについて質問したか
• [ ] トライアル(試用)の可否を確認したか。断られた場合、理由が具体的だったか
• [ ] 少なくとも2〜3社のデモを比較する予定を立てているか
• [ ] その場で答えられなかった質問について、後日の回答期限を約束してもらったか

このチェックリストをそのまま使うだけでも、「デモを見て感動して終わり」という状態から、比較可能な材料をそろえた状態へと商談の質を引き上げられる。

この記事で持ち帰れること

商談でデモを見るとき、次の3点を判断できるようになることが、この記事のゴールだ。

• デモの「見た目の完成度」と「自社業務への適合度」を切り分けて評価する視点
• 商談のその場で聞くべき具体的な質問と、答え方から見える開発会社の実力・誠実さの見極め方
• トライアルの依頼の仕方と、断られた場合に何を代替案として検討すればよいか

これらを踏まえたうえで、実際に契約に進む前には、先代の代からのシステム発注、契約・権利・データはここを確認するで契約書面の確認ポイントも合わせて見ておくと、デモの印象だけに頼らない判断ができる。

次の商談がまだ先という場合も、今すぐできることが一つある。まずは、前回すでに見たデモがあれば、記憶が薄れないうちに「デモ・トライアル評価チェックリスト」の7項目に沿って、分かる範囲だけでも印象をメモに書き出してみてほしい。それだけで、次の商談での質問の精度が上がる。

よくある質問

Q. デモを見て良い印象を持った1社に絞ってよいですか。相見積もりは必須ですか。

法律上の義務ではないが、少なくとも2〜3社のデモを比較することを強くすすめる。1社だけを見た状態では、そのデモの質が業界内で高いのか低いのか、そもそも判断する基準がない。特に先代の代から刷新が滞っていた会社ほど、最初に見た解決策に飛びつきやすい傾向があるため、意識的に比較の機会を作ってほしい。

Q. デモの場で専門用語が分からず、質問しづらいです。どうすればよいですか。

この記事で紹介した質問は、いずれも「動いているか」「自社に合うか」「運用後どうなるか」という事実確認のための質問であり、専門用語を使わなくても聞ける内容になっている。分からない専門用語が出てきたら、その場で「今のお言葉の意味を教えてください」と聞くこと自体も、開発会社の説明の丁寧さを測る材料になる。

Q. トライアルを依頼したら失礼にあたりませんか。

失礼にはあたらない。特に投資額が大きくなる契約であるほど、発注側が事前に確認したいと考えるのは自然なことだ。ただし、カスタム開発の規模によってはトライアル自体が難しい場合もあるため、依頼する際は「投資規模に見合った確認をしたい」という趣旨を丁寧に伝えるとよい。

Q. デモで「できます」と言われたことが、契約後にできないと分かった場合はどうすればよいですか。

口頭でのやり取りだけに頼らず、デモで確認した内容のうち重要なものは、提案書や見積書、契約書の別紙などの書面に残してもらうことを商談の早い段階から依頼しておくとよい。書面化を渋る、あるいは曖昧な返事に終始する場合は、危険な開発会社のサイン10選、承継社長が見極めるポイントで紹介している注意サインと重ねて確認してほしい。

まとめ

デモは、開発会社の実力を知るための貴重な機会であると同時に、「見せ方」によって発注側の判断を左右しやすい場でもある。先代の代から刷新が滞っていた会社の後継社長ほど、目の前で動く画面に感動し、細部の確認を後回しにしてしまいやすい。

この記事で紹介した3つの視点――動作の実態、自社業務への適合、運用後を見据えているか――を意識して商談に臨むだけで、デモの印象に流されず、比較可能な材料をそろえた状態で契約の判断ができるようになる。焦って1社に決める前に、まずはこのチェックリストを手元に置いて、次の商談に臨んでみてほしい。