「動くものを見せてほしい」と頼んだら「完成まで見せられない」と言われた…中間確認を断られたときの交渉と頼み方

システム開発の途中で「今どこまでできているのか、実際に画面を触って確かめたい」と思うのは、発注者として自然なことです。ところが開発会社から「今はまだ見せられる状態ではありません」「完成してからお見せします」と返ってくると、不安が一気に大きくなります。

先に結論をお伝えします。「見せられない」という返事には、正当な理由があることも、見せる工夫が足りないだけのこともあります。大切なのは、断られたことを責めるのではなく、「完成品ではなく、途中の一部でよいので確認させてほしい」と頼み方を変えることです。この記事では、見せてもらえない理由の見分け方、頼み方の言い換え、見せてもらう日程の決め方を、そのまま使える質問例とあわせて解説します。

「完成まで見せられない」と言われる主な3つの理由

まず、開発会社の側でなぜそう言うのかを押さえましょう。理由が分かると、こちらの頼み方も変えやすくなります。

理由1：見せられる単位に区切って作っていない

システムは、画面・データベース・裏側の処理を同時並行で作ることがあります。この進め方だと、完成間際まで「全部がつながって動く」状態にならず、途中で見せられるものがありません。開発会社に悪意はなく、作る順番が「完成まで通しで見せる」前提になっていないことが原因です。

理由2：途中の画面を見せると、仕様が揺れるのを心配している

未完成の画面を見せると、「ここが違う」「こうしてほしい」と意見が次々に出て、全体の作業が止まりやすくなります。そのため、まとまってから見せたいと考える開発会社もあります。ただし、見た目の違和感に気づくのは早いほど修正が小さく済むので、発注者にとっては早めに見るほうが得になることが多いです。

理由3：契約や進め方で「確認の機会」を決めていない

見積もりや契約の時点で「中間でどう確認するか」を決めていないと、見せる側にも見る側にも義務がありません。その結果、依頼しても「予定にないので」と断られる形になります。

完成品でなくても確認できる4つの見せ方

「動くもの」にこだわらず、状態に応じた見せ方を選ぶと、断られにくくなります。

見せ方	見られるもの	向いている時期
画面の見本（ワイヤーフレームや画面イメージ）	画面の配置・項目・操作の流れ	設計の初期
一部の機能だけ動くデモ	例：ログインして一覧が表示されるところまで	開発の前半〜中盤
開発者が画面を操作して見せる（画面共有）	実際に動いている様子。まだ不安定でもよい	いつでも
確認用の環境に置いてもらい自分で触る	自分のペースで操作して確かめられる	開発の中盤〜終盤

ポイントは、「全部が動く」ではなく「一部が動く」を求めることです。「ログインから一覧表示まで」のように範囲を小さく区切ると、開発会社も準備しやすくなります。

頼み方を変える：断られにくい4つの言い換え

同じお願いでも、言い方で受け止められ方が変わります。

• 「完成前のままで構いません」と先に伝える：不具合や見た目の粗さを指摘する場ではなく、方向性の確認だと伝えます
• 見たい範囲を具体的に指定する：「全体」ではなく「注文の登録画面だけ」のように絞ります
• 見る目的を添える：「現場の担当者に早めに見せて、使い勝手の意見をもらいたい」など、目的があると前向きに検討してもらえます
• 日時の候補をこちらから出す：「来週の定例会の最後30分で、画面共有で見せてもらえませんか」のように、負担が小さい形で提案します

それでも見せてもらえないときの対処

何度頼んでも見せてもらえない場合は、次の順で進めると整理しやすくなります。

1. 見せられない理由を文章で聞く：「いつ頃なら見せられるか」「それまでの進み具合をどう確認できるか」を、メールなど記録が残る形で尋ねます
2. 代わりの確認方法を出してもらう：画面の見本、進捗の数字、テスト結果の共有など、動くもの以外で状況が分かる材料を依頼します
3. 定例会に「確認の時間」を入れる：進捗報告の中に、毎回短くてもよいので「できた部分を見せる時間」を入れてもらいます
4. 契約書・計画書を見直す：中間での確認が決められているか、確認の回数や時期の取り決めがあるかを確かめます
5. 社内の決める人と相談する：確認の機会が得られないまま工程が進むと、後から修正の費用や期間に響くおそれがあります。社内で判断できる人と共有しておきましょう

進捗報告が「順調です」ばかりで不安なときの確かめ方は、次の記事でも詳しく解説しています。

中間確認の取り決めは「契約前」が一番楽

後から頼むより、最初から取り決めておくほうがはるかに簡単です。

アジャイル開発（＝小さく作って確認しながら進める開発のやり方）向けのモデル契約を公表しているIPA（情報処理推進機構）のページでは、発注者側が「プロダクトオーナー（PO）」を選任し、プロダクトの方向性と内容に責任を持って、開発チームへの情報提供や意思決定を適時に行う役割だと説明されています。また、契約は成果物の完成に対価を払う請負ではなく、専門家として業務を行うこと自体に対価を払う準委任契約を前提としています（2026年10月時点で確認）。

📰 出典：IPA「アジャイル開発版 情報システム・モデル取引・契約書」

このモデルは、すべての案件にそのまま当てはまるわけではありません。ただ、途中で確認し、発注者も決める役割を担うという考え方は、請負契約で進める案件でも参考になります。契約前の段階で、次の点を決めておくと安心です。

• 中間確認の回数と時期（例：開発の中盤に1回、終盤に1回）
• 確認の方法（画面共有か、確認用環境か）
• 確認で出た意見の扱い（範囲内の修正か、変更の相談か）
• 確認に参加する発注者側の担当者と、決める人

発注者がやりがちな失敗パターン

• 「見せて」とだけ言って、範囲や目的を伝えない：開発会社が何を準備すればよいか分からず、断る返事になりがちです
• 未完成の画面に、仕様の追加要望をどんどん出す：確認の場が要望の追加の場になると、開発会社が見せることを避けるようになります。方向性の確認と、変更の相談は分けましょう
• 見せてもらったのに、感想だけで終わらせる：何を確認して何を直すのか、記録に残して初めて意味があります
• 現場の担当者を呼ばない：発注者側の窓口だけで見ても、実際の業務で使えるかは分かりません

発注者がやることチェックリスト

• ☐ 「完成品」ではなく「一部が動く状態」で確認したいと伝えた
• ☐ 見たい範囲（画面・機能）と見る目的を具体的に伝えた
• ☐ 断られたとき、理由と「いつなら見せられるか」を文章で聞いた
• ☐ 画面の見本・進捗の数字・テスト結果など、代わりの確認材料も依頼した
• ☐ 定例会に「できた部分を見せる時間」を入れてもらった
• ☐ 確認の場に、実際に使う現場の担当者を同席させた
• ☐ 確認で出た意見を記録し、修正か変更の相談かを分けた
• ☐ 契約や計画に、中間確認の回数と時期が書かれているか確かめた

開発会社への質問例

• 「完成前の状態でも構いませんので、今できている部分を画面共有で見せていただけませんか？」
• 「全体の完成前に、確認できる区切りはありますか？ 区切りごとに何が見られるのか教えてください」
• 「今は見せられないとのことですが、いつ頃なら、どの範囲を見られそうですか？」
• 「動くもの以外で、進み具合が分かる資料（画面の見本、テスト結果、残作業の一覧など）はいただけますか？」
• 「途中の確認で出た意見は、どのように記録して、修正か変更かを判断しますか？」

こうした質問への答えから、その開発会社が発注者との認識合わせを大切にしているかも見えてきます。

まとめ：「見せて」を「小さく見せて」に言い換える

「完成まで見せられない」と言われても、すぐに不信感を持つ必要はありません。理由は、作る順番、仕様が揺れる心配、確認の取り決めがないこと、のどれかであることが多いからです。

• 完成品ではなく、一部が動く状態や画面の見本で確認する
• 見たい範囲と目的を具体的に伝え、日時の候補もこちらから出す
• 断られたら理由と時期を文章で聞き、動くもの以外の確認材料も頼む
• 次の案件からは、契約前に中間確認の回数・時期・方法を決めておく

中間で確認する習慣は、発注者のためだけでなく、手戻りが減るという点で開発会社にとってもメリットがあります。まずは次の定例会で、「できている部分を30分だけ見せてください」と頼むところから始めてみてください。