著者: 野原琉海（株式会社ラズリ代表）
僕はエンジニアとして、システムを作る仕事を受ける側にいる。だから、発注側の担当者とやりとりすることが多い。
その中で「この人、たぶん今の説明ほとんど分かってないだろうな」と感じる場面が正直ある。でも担当者は分かったふりをして「はい、大丈夫です」と言う。そのまま開発が進む。完成してから「思ってたのと違う」と言われる。
発注する側が少し知識を持っておくだけで防げるトラブルは多い。今日はその話を書く。
見積もりが高いのか安いのか分からない問題
これが一番多い。
開発会社から「300万円です」と見積もりが出てきた時に、それが適正なのか判断できない。何にいくらかかっているのかが読み解けない。
やるべきこと:
- 見積もりの中身を聞く。「全部で300万円」ではなく、「この作業にいくら、あの作業にいくら」と分けてもらう
- 「この作業には何人が何日かかるんですか？」と聞く。人数×日数が開発費の基本
- できれば3社に見積もりを取る。金額の幅を見ることで「だいたいこのくらいなんだな」が分かる
ITに詳しい人が味方にいるだけで、価格は変わる
これは発注する側にぜひ知っておいてほしいことだ。
開発会社が提案してくる作り方は、基本的に「安全に動くこと」を優先している。だから、全部イチから作る前提になりがちだ。
でも、ITに詳しい人がいると「ここは全部作らなくても、既にあるサービスを組み合わせれば安く済みますよね？」とか「この機能はそこまで凝らなくていいから、最小限の作りでお願いします」と言える。
これが言えるだけで、見積もりが数十万円変わることがある。
開発会社は聞かれなければ「もっと安い方法がありますよ」とは言わないことが多い。発注する側が「全部お任せします」と言えば、全部作る。当然その分の費用がかかる。
社内にITに詳しい人がいない場合は、外部のエンジニアに見積もりだけ見てもらうのも手だ。数万円の相談料で数十万円の削減ができることがある。
開発会社の説明が分からない問題
打ち合わせで開発会社の人が専門用語を使ってくる。分からないけど、聞き返すのが恥ずかしくて「はい」と言ってしまう。
これは本当に危ない。
分からないまま「はい」と言うと、開発会社は「了解を得た」と判断する。後から「そんなつもりじゃなかった」と言っても、「打ち合わせで合意しましたよね？」と返される。
やるべきこと:
- 分からない言葉が出てきたら、その場で聞く。「すみません、それどういう意味ですか？」
- 恥ずかしいことではない。開発会社の側も、分からないまま進む方が困る
- 打ち合わせの内容をメモに残してもらう。「今日決まったこと」を文章で確認する
- 口頭だけで決めない。重要なことは必ずメールかチャットで文字に残す
「伝わっている」と思ったら伝わっていない問題
「こういう画面が欲しい」と説明する。開発会社は「分かりました」と言う。でもお互いがイメージしているものが全然違う。
「こういう感じで」「いい感じに」「使いやすく」。こういう曖昧な言い方が一番危ない。「使いやすい」の基準は人によって違う。
やるべきこと:
- 画面のイメージがあるなら、手書きでもいいから絵を描いて渡す
- 「このサービスのこの画面が近い」と実際のサイトを見せる
- 作り始める前に、画面の見た目だけのサンプルを作ってもらって「これで合ってますか？」と確認する
- 「いい感じに」は禁句。「ここを押したらこうなる」と具体的に伝える
スケジュールが適正か分からない問題
「3ヶ月で完成します」と言われても、それが早いのか遅いのか判断できない。
やるべきこと:
- 「なぜ3ヶ月なのか」を聞く。どの作業に何週間かかるのかを分けてもらう
- 途中で確認できるタイミングを決めておく。「1ヶ月後に途中経過を見せてください」
- 完成が遅れた場合のルールを、契約する前に決めておく
まとめ
- 見積もりは中身を聞く。「全部でいくら」で終わらせない
- ITに詳しい人が味方にいるだけで「ここはもっと安くできる」と言えて、数十万円変わる
- 分からない言葉はその場で聞く。分かったふりが一番危ない
- 重要なことは必ず文字に残す
- 「いい感じに」は禁句
ITに詳しくないことは恥ずかしいことじゃない。でも、分からないまま数百万円の契約をするのは危ない。「分からないから教えてください」と言えるだけで、トラブルの大半は防げる。
「開発会社からの見積もり、これ妥当なのかな」と思ったら、こちらからご相談ください。エンジニア目線で一緒に見積もりを確認します。