記事一覧に戻る
開発

納品後に「思っていたのと違う」と言われないために|途中で見せることでしか防げない

2026年9月4日 約4分で読めます
この記事の結論

納品後に「思っていたのと違う」と言われないための方法は、定期的に打ち合わせをして途中経過を見せることに尽きます。ただし見せると、当初の想定からずれていくことがあります。そのズレは、追加のお見積もりか、他の機能を削って充てるかで解決します。

システム開発でいちばん避けたい事態のひとつが、納品してから「思っていたものと違う」と言われることです。発注側にとっては費用が無駄になり、開発側にとっては手戻りになります。この記事では、FUNBREWが実際にこの食い違いをどう防いでいるのか、それでも起きるズレをどう処理しているのかを書きます。特別な手法はありません。むしろ地味な一手しかない、という話です。

納品後に「思っていたのと違う」と言われた経験はあるか

結論から書くと、大きな食い違いによるトラブルは起きていません。基本的に、納品後に「思っていたのと違う」と言われた経験はありません。

理由は、定期的に見せているから

これは品質が高いからでも、要件定義が完璧だからでもありません。定期的にお客様と打ち合わせをして、進捗を実際に見せているからです。動いているものを途中で見ていれば、完成したときに初めて中身を知る、という状況になりません。

逆に言えば、納品まで何も見せない進め方をすると、認識のズレは最後まで発見されません。そしてその時点で見つかったズレは、作り直すしかない場所に埋まっています。食い違いは、最後に起きるのではなく、最後に発見されるのです。

それでも、途中でズレは起きる

ここが正直に書いておきたい部分です。途中経過をお見せすると、当初の想定よりも要望がずれていくことがあります。

なぜズレるのか

動くものを見て初めて気づくことがあるからです。見積もりの段階では見えていなかった要望——画面を触ってみて「ここはこう動いてほしい」と分かる類のもの——が、そこで出てきます。これは発注側の落ち度ではありません。図と文字だけで完成形を想像するには限界がある、というだけのことです。

つまり、途中で見せることには二つの効果があります。ひとつは食い違いを早く発見できること。もうひとつは、見せることで新しい要望が生まれることです。後者は避けられませんし、避けるべきものでもありません。

ズレが見つかったときの二つの選択肢

選択肢内容
追加のお見積もり増えた分を別途お見積もりし、予算を追加していただく
他の機能を削って充てる優先度の低い機能を外し、その工数を新しい要望に回す

どちらを選ぶかは、予算と優先順位の判断です。予算に追加の余地がない場合は、後者になります。何かを足すなら、何かが減る——この関係は、規模が小さい案件ほどはっきり出ます。どこからが追加費用になるかの線引きは、システム開発で「これは追加費用です」と言われるのはどこからかに詳しく書いています。

発注側が納品前にできること

1. 進捗を見せてもらう約束を、最初にしておく

「定期的に動いているものを見せてください」と最初に伝えておくだけで、この記事で書いた仕組みはほぼ機能します。頻度や形式は開発会社の進め方によりますが、完成まで何も見えない進め方になっていないかだけは、契約前に確認しておく価値があります。

2. 優先順位を、自分の中で持っておく

途中でズレが見つかったとき、判断を求められるのは発注側です。「追加でお見積もりするか、他の機能を削るか」という問いに答えるには、どの機能が自社にとって重要で、どれは無くても回るのかという順番が要ります。ここが決まっていないと、判断が止まり、開発も止まります。すべてを同じ重要度で持ったまま進めると、削る選択肢が使えなくなり、追加予算しか道が残りません。

3. 見た瞬間に、違和感を言う

途中経過を見て「なんとなく違う気がするが、まだ途中だろうから言わないでおこう」と飲み込むのが、いちばんもったいないパターンです。その違和感は、後から言うほど高くつきます。言葉にしづらい段階でも、「ここが引っかかる」と伝えていただければ、こちらで原因を切り分けられます。

なお、この「違和感を言う」は、細かい指摘を大量に出してほしいという意味ではありません。気になった点を、気になった時点で口に出していただければ十分です。原因が仕様なのか、実装途中なのか、こちらの理解のズレなのかは、こちらで切り分けます。判断まで発注側で用意していただく必要はありません。

相談の段階で何を伝えると話が早いかは開発の相談メールに何を書けば話が早いか、小さな案件で何を取り交わすかは小規模なシステム開発で契約書は必要かもあわせてご覧ください。

途中経過をお見せすると、たいてい新しい要望が出ます。それは失敗ではなく、正常な反応です。むしろ何も出てこない方が、見ていただけていないのではないかと心配になります。気づいたことは、その場で遠慮なくお伝えください。

まとめ

納品後の「思っていたのと違う」を防ぐ方法は、定期的に打ち合わせをして進捗を見せることに尽きます。FUNBREWで大きな食い違いのトラブルが起きていないのは、この一点によるものです。

ただし、途中経過を見せると当初の想定からずれていくことはあります。見積もり段階では見えなかった要望が出てくるためで、その場合は追加のお見積もりか、他の機能を削って充てるかで対応します。発注側にとって重要なのは、完成まで何も見えない進め方を避けることと、違和感をその場で伝えることの二つです。

進め方についてのご相談も承ります。お問い合わせよりご連絡ください。

よくある質問
納品後に「思っていたのと違う」と言われたことはありますか。
大きな食い違いによるトラブルは起きていません。理由は、定期的にお客様と打ち合わせをして進捗を実際に見せているためです。動いているものを途中で見ていれば、完成時に初めて中身を知るという状況になりません。
途中で見せても要望がずれていくことはありませんか。
あります。動くものを見て初めて気づくことがあるため、見積もり段階では見えていなかった要望が出てきます。これは発注側の落ち度ではなく、図と文字だけで完成形を想像することの限界によるものです。
途中で要望が増えた場合はどうなりますか。
追加のお見積もりをするか、優先度の低い機能を削ってその工数を新しい要望に充てるかの二つです。予算に追加の余地がない場合は後者になります。何かを足すなら何かが減るという関係は、規模が小さい案件ほどはっきり出ます。
発注側として納品前にできることは何ですか。
最初に「定期的に動いているものを見せてください」と伝えておくことと、見て違和感を覚えた時点でその場で伝えることの二つです。違和感は後から言うほど高くつきます。

この記事をシェア

進め方からご相談ください

完成まで何も見えない進め方にならないよう、定期的に動くものをお見せしながら進めます。

この記事に関連するサービス

お困りごとのご相談は無料です。まずは状況をお聞かせください。

最新情報をお届けします

IT活用のヒントやお役立ち情報を定期的にお届けします。

関連記事

開発
2026年9月4日

複数の開発会社が1つのシステムに関わるとき|責任の線を引きすぎて困るのは発注側

1つのシステムに複数の開発会社が関わる状態で、責任の切り分けをどうしているか。境界で問題が起きたとき各社が線を引くと発注側が間に立たされるという構造と、発注側が用意できることを書きました。

2026年4月11日

システム開発の外注で失敗しない|発注前に確認すべき10のチェックポイント

システム開発を外注する際に事前に確認すべき10項目を解説。要件定義から契約、検収まで、失敗を防ぐチェックリストを紹介します。

開発
2026年4月4日

システム開発の検収期間の目安|期間の決め方・延長対応・トラブル防止策

システム開発の検収期間は一般的に1〜4週間が相場ですが、規模や複雑さによって大きく異なります。この記事では、検収期間の適切な設定方法、契約書への記載方法、期間延長が起きる原因と対処法、トラブルを防ぐ実践的なポイントを発注者向けに解説します。

開発
2026年3月22日

システム開発の検収チェックリスト|受け入れテストの進め方と合否判定基準【テンプレート付き】

システム開発の検収(受け入れテスト)で使えるカテゴリ別チェックリストと検収書テンプレートを公開。機能テスト・非機能テスト・UI/UX・ドキュメントの4カテゴリで抜け漏れなく確認でき、合否判定基準の決め方やよくあるトラブル対処法まで徹底解説します。

相談のハードル、下げました

まずは気軽にご相談ください

「まだ具体的に決まっていない」「とりあえず話を聞きたい」でも大丈夫。プロトタイプを見ながら、一緒にアイデアを形にしていきましょう。

相談無料 オンライン対応 1週間でプロトタイプ