システム会社に発注する前に聞く5つの質問｜ITに詳しくなくても確認できます

システム会社から見積書が届いた。

金額も予算内。

説明も丁寧。

ここまで来ると、そのまま発注したくなります。

でも、自分ならあと5つだけ聞きます。

Pythonがどうとか、サーバーがどうとか、難しい技術の質問ではありません。

ITに詳しくない人でも聞ける内容です。

むしろ、技術を知らない発注者ほど聞いておいた方がいいと思っています。

自分はSEとして15年、ココナラでも販売実績270件まで対応してきました。

開発する側にいると、「そこを先に聞いてもらえたら、後で揉めなかったのに」と思う場面があります。

発注前は、開発会社を試す場ではありません。

お互いの認識を合わせる場です。

なので、遠慮せず聞いて大丈夫です。

■ 質問1　「この金額に含まれていないものは何ですか？」

最初に聞くならこれです。

普通は、見積書に「何をやるか」が書いてあります。

でも、本当に事故が起きやすいのは、書いていない部分です。

たとえば、

・サーバーやクラウドの利用料

・外部APIの利用料

・本番環境への反映

・既存データの移行

・操作マニュアル

・ソースコードの引き渡し

・納品後の改修

このあたりが別料金なのかどうか。

「全部込みだと思っていました」が一番危ないです。

自分も見積りを作るとき、対象外はなるべく明示するようにしています。

対象範囲だけ書くより、対象外を書いた方が境界線がはっきりするからです。

聞き方はそのままで大丈夫です。

「この金額に含まれていない作業があれば教えてください」

これだけです。

■ 質問2　「完成の判断は、何をもって行いますか？」

これも重要です。

「システムを完成させる」と言っても、完成の基準は人によって違います。

画面が表示できれば完成なのか。

データ保存まで動けば完成なのか。

実データを使ったテストまで終われば完成なのか。

本番環境へ反映して利用者が使える状態までなのか。

ここが曖昧だと、納品時に揉めます。

発注側は「実際に使える状態」を想像している。

開発側は「指定された機能が動く状態」を想像している。

どちらも間違っていないのにズレます。

自分は業務システムの案件では、できるだけ実際の作業フローまで確認します。

入力して、保存して、確認して、出力して、必要なら修正する。

この一連が終わって初めて使えるからです。

「納品時にどの状態まで確認できますか？」と聞いてみてください。

■ 質問3　「途中で仕様変更が出た場合はどうなりますか？」

システム開発で、仕様変更ゼロを前提にするのはかなり厳しいです。

画面を見たら項目を変えたくなる。

社内で見せたら別の要望が出る。

実データを入れたら例外ケースが見つかる。

普通にあります。

だから、仕様変更が起きないことを期待するより、起きたときのルールを聞いた方がいいです。

・追加見積りになる条件

・小さな調整はどこまで含むか

・納期はどう変わるか

・変更前に金額確認があるか

この4つくらいは確認したいです。

自分も昔、軽微な修正のつもりで受け続けて、作業範囲が膨らんだことがあります。

今は「ここから先は追加対応」と切り分ける方が、依頼者にとっても分かりやすいと考えています。

変更自体が悪いのではなく、変更の扱いが曖昧なのが危ないんですよね。

■ 質問4　「納品物として何を受け取れますか？」

完成したシステムだけなのか。

ソースコードもあるのか。

設定ファイルはあるのか。

操作手順はあるのか。

バックアップ方法は分かるのか。

ここは数か月後に効いてきます。

業務システムは、納品して半年後に「この項目を増やしたい」となることがあります。

そのとき、元の開発者にしか触れないのか、別の人にも引き継げるのかで選択肢が変わります。

もちろん、サービスの仕組み上、ソースコードを渡さない契約もあります。

それ自体が悪いわけではありません。

大事なのは、発注前に知っていることです。

「納品時に受け取れるものを一覧で教えてください」と聞けば十分です。

■ 質問5　「納品後に問題が出た場合、どこまで対応されますか？」

完成直後のテストでは問題がなくても、実運用で初めて出ることがあります。

データ件数が増えた。

別のPCで動かした。

Macで開いた。

スマホで操作した。

外部サービス側の仕様が変わった。

自分も実際に、Windowsでは動くのに別環境で挙動が違う、という確認をすることがあります。

システムは動作環境の影響を受けます。

そこで確認したいのが、

・不具合修正期間

・保守の有無

・仕様変更の料金

・緊急時の連絡方法

です。

「納品したので終了です」なのか、「一定期間は不具合対応します」なのかでは安心感が違います。

■ この5つを聞いて嫌がられるなら、そこも判断材料

念のため言うと、相手を詰める必要はありません。

「追加料金取るんですよね？」

「本当に大丈夫ですか？」

こういう聞き方をする必要はないです。

普通に、

「発注前に認識を合わせたいので、対象外の範囲を教えてください」

で十分です。

開発側からすると、事前に確認してもらえる方が助かります。

後から「聞いていない」となる方がお互い大変です。

自分も依頼を受けるとき、質問が多いお客さんを面倒だとは思いません。

むしろ、業務ルールを話してもらえるほど、仕様を作りやすくなります。

■ 発注者がプログラミングを勉強する必要はない

システムを発注するために、技術者になる必要はありません。

JavaScriptのフレームワークを覚える必要もないですし、データベース設計を勉強する必要もありません。

発注者が押さえるのは、

・何が完成するのか

・何が含まれないのか

・変わったらどうなるのか

・納品後はどうなるのか

ここです。

技術的な妥当性は、必要なら第三者に見てもらえばいいです。

自分自身、開発する側として多くの見積りや仕様整理をしてきましたが、後半で苦しくなる案件は初期確認が足りていないことが多いです。

逆に、最初に質問しておけば、全部を完璧に決められなくても「変更が出たらこうする」が作れます。

それだけで進めやすさはかなり変わります。

見積書や提案書をもらったけれど、「何を聞けばいいのか分からない」「この内容で発注していいのか不安」という方向けに、第三者目線で確認するサービスも出しています。

金額、要件、技術構成、追加費用のリスク、ベンダーへ聞く質問まで整理します。

■ 質問するときは「答え」より「認識がそろうこと」が目的

この5つを聞いたから、必ず完璧な発注になるわけではありません。

大事なのは、質問をきっかけに双方の認識をそろえることです。

たとえば「データ移行は含まれますか？」と聞いて、「含まれません」と返ってきたとしても、それ自体は問題ではありません。必要なら追加で頼む、社内で対応する、今回は移行しない、と判断できます。

一番困るのは、お互いに「当然含まれている」「当然含まれていない」と思ったまま進むことです。

自分は開発側として、仕様がはっきりしている案件ほど進めやすいと感じます。質問を受けて確認する時間より、完成後に認識違いを直す時間の方が圧倒的に重いからです。

もし5つ全部聞くのが多いと感じたら、最低でも「対象外」「仕様変更」「納品後」の3つだけでも確認してみてください。

この3点だけでも、後から出るトラブルの種類はかなり減らせます。

システム開発の見積りチェックはこちら

#システム発注

#システム開発

#見積り

#IT相談