開発を外注する前に読んでほしい、受注側エンジニアの本音

著者：野原琉海（業務効率化に特化したエンジニア）

「開発会社の選び方」と検索すると、比較サイトや会社ランキングばかりが並ぶ。

ほとんどはライターや比較メディアが書いたもので、実際にコードを書いているエンジニアの目線で書かれた記事はほとんどない。

僕はエンジニアとして開発を受注する側でもある。中小企業の業務効率化顧問として、外注先の開発会社との交渉に立ち会うこともある。両側を見てきたからこそ、書けることがある。

この記事では「受注側のエンジニアから見た現場のリアル」を正直に書く。どういう発注が来ると「これは大変になるな」と身構えるのか。逆に「この会社の仕事はいいものを作りたい」と思う瞬間はどんな時か。見積もりの読み方、契約前の確認事項、騙されない発注者になるための具体的な方法まで書く。

正直、「受けたくない案件」がある。受注側が身構える発注パターン

受注側にも「これは受けたくないな」と感じる瞬間がある。正直に言う。

これを発注側が知っておくと、自分の発注がどう見られているかが分かる。

欲しいものが自分でも決まっていない

一番困るのが「欲しいものが定まっていない」ケースだ。

「なんかいい感じのシステムを作ってほしい」「社内の業務を全部まとめて管理したい」「競合がアプリを出したからうちも」。こういう発注が来ると、エンジニア側は正直身構える。

欲しいものが曖昧なまま開発を始めると、完成した時に「思ってたのと違う」が起きる。仕様通りに作った。打ち合わせで合意した。それでも「なんか違う」と言われる。「何が正解ですか」と聞き返すと、発注側も答えられない。こうなると作り直しが発生して、お互いに時間もお金も消耗する。

自社でも過去に「なんかいい感じにして」という依頼を受けて、完成後に仕様変更が7回発生したプロジェクトがあった。最終的に当初見積もりの2倍の工数になった。発注側も受注側も疲弊した。原因は「欲しいものの言語化が不十分だったこと」だけだった。

対策はシンプルだ。「何に困っているか」を業務の課題として伝える。システムの機能ではなく、解決したい問題から出発する。「毎月末の請求書突合せに3日かかっていて、1日以内に終わらせたい」という形で伝えれば、エンジニア側で解決策を考えられる。

全部丸投げ・全部お任せ

「プロなんだから全部やってください」も、現場では難しい。

開発は発注側の業務知識がないと完成しない。「この画面、実際の業務でどう使いますか？」「この例外ケースは月何回くらい発生しますか？」。こういう質問に答えられるのは発注側だけだ。それが返ってこないと、エンジニアは最低限の合理的な想定で作るしかない。

結果として「なんか使いにくい」「実務に合ってない」という評価になる。

業務のプロは発注側。技術のプロはエンジニア。これは役割分担であり、どちらかが偉いわけではない。双方が持っている情報を出し合わないと、いいものは作れない。

価格だけで選ぶ

3社に見積もりを取って一番安い会社に決める、は選択肢として悪くない。ただ、極端に安い見積もりには理由がある。

腕のあるエンジニアは相場以上の価格をつける。自分のスキルに自信があるから安売りしなくていい。逆に相場より大幅に安い会社は「安くしないと仕事が取れない」ということだ。経験が浅い、実績が少ない、過去にトラブルがある、といった理由が背景にある場合が多い。

見積もりが「安い＝お得」ではない。「安い＝それなりの理由がある」と考えた方がいい。

「いい開発会社」を見分ける前に「いい発注者になること」が先決

開発会社を選ぶ前に、まず自社の発注姿勢を整えることが先だという逆説がある。

いい発注者には優秀なエンジニアが集まる。安請け合いする会社が寄り付かなくなる。「発注者の質がアウトプットの質を決める」というのは、受注側として実際に感じてきたことだ。

業務課題を数字で語れるか

初回の打ち合わせで業務の課題を具体的に話せるクライアントは、エンジニアにとって設計がしやすい。

「売上管理が毎月Excelの手入力で、月末の集計に4〜5時間かかっている。集計ミスで税理士への確認依頼が年2〜3回発生していて、その都度1〜2万円の追加費用がかかっている」。このレベルで課題を話せる発注者と「なんか効率化したい」という発注者では、エンジニアの設計の方向性が変わる。

課題が具体的なほど、解決策も具体的になる。

提案へのリアクションがあるか

打ち合わせで提案した時に「それは業務でいうとこういうことですかね」「そこが気になっていました」と反応がある発注者は、エンジニアが「一緒に作っている」と感じられる。

「お金を払っているんだからやってください」というスタンスは形としては分かるが、実際には機能しない。システムは双方向の情報交換がないと精度が落ちる。

変更を仕様として管理できるか

「ここ変えてください」という要望が出るのは自然だ。問題は「ちょっとだから無料でできますよね」という感覚で依頼してくるケースだ。

どんなに小さい変更でも、実装・テスト・確認に工数がかかる。それが積み重なるとプロジェクト全体が遅れる。追加要件は都度仕様として固めて、別見積もりを取る姿勢の発注者は、エンジニアから見て信頼できる。

見積もりの正しい読み方｜「一式」「工数不明」は要交渉

開発の見積もりを初めて受け取る発注者は、金額の比較しかできない。でも見積もりで確認すべきは金額だけではない。

「一式」の罠

見積書に「システム開発一式：280万円」とだけ書いてある場合、内訳が分からない状態だ。どの機能にいくらかかっているのか、修正対応はいくつまで含まれているのか、テストや設計書の作成は含まれているのか。

「一式」という書き方は後から追加費用を請求しやすい。「一式に含まれていなかった」という理由が成立するからだ。

見積もりを受け取ったら「機能ごと・フェーズごとの内訳を出してほしい」と依頼すること。それを嫌がる会社は避けた方がいい。

工数の内訳がない

「設計10日 × エンジニア1名 × 日額2万円 = 20万円」のような形で工数と単価が明示されているか確認する。

工数が書かれていない見積もりは、どこを削れるかが見えない。「この機能、最初のフェーズでは省けますか」という交渉ができない。工数が明示されている見積もりは、予算調整の余地が生まれる。

保守・運用の費用が入っていない

開発費用だけ見て判断すると、納品後に困る。

サーバー代、バグ修正、機能追加、インフラ管理。これらが月額いくらになるのかを納品前に確認しておかないと、想定外のランニングコストが発生する。月額5〜15万円のランニングコストが発生するシステムを、開発費用だけで比較するのは意味がない。

顧問先の会社と一緒に外注先を検討する時は、必ず「1年後の維持費はどれくらいかかりますか」を先に聞くようにしている。この質問に答えられない会社は、運用設計が甘い可能性がある。

デジタルツール導入で失敗する4つのパターンと対策でも書いたが、ツールや開発への投資を判断する時は初期費用だけでなくランニングコストを含めた総費用で考えることが重要だ。

受注側が本当に困ること｜発注者が知っておくべき3つの現実

仕様変更の連続が品質を落とす

開発中の仕様変更はある程度は仕方ない。使ってみて気づくことはある。ただ、毎週のように要件が変わると品質が下がる。

エンジニアが設計の途中で方針を変えると、前の設計との整合性を取り直す作業が発生する。この繰り返しがバグの温床になる。「ちょっと変えるだけ」が積み重なった結果、コードが複雑になり、後から手を入れるたびに別の問題が起きる。

経験上、要件定義に時間をかけた案件は開発フェーズが速く終わる。「早く作り始めたい」という気持ちは分かるが、「何を作るか」が固まらないまま開発を始めると、後半で必ず修正コストが跳ね上がる。後半の仕様変更は、序盤の修正に比べてコストが数倍になることが多い。

確認返答が遅いと納期が伸びる

受注側の連絡が途絶えるパターンはよく話題になるが、実は発注側の返答が遅いケースもかなり多い。

「この仕様、AにしますかBにしますか」という確認メールに1週間返事が来ない。その間、エンジニアは止まる。でも納期は変わらない。

開発中の確認事項への返答は、できれば48時間以内が理想だ。3〜4日以内でも許容範囲。1週間以上返答がない場合は、スケジュールが遅れても仕方ない状況になる。

予算感の共有がないと双方が損する

「いくら出せるか」を最初に話さない発注者は多い。予算を言うと足元を見られると思っているからだ。

ただ、エンジニアの立場では予算を知っていれば「この予算なら機能を絞って確実に動くものを作れる」という提案ができる。予算を知らないと、相手に合わせた最適解が出せない。

月100万円の予算と月300万円の予算では設計の方向性が変わる。先に予算感を伝えた方が、発注側にとっても最適な提案が返ってくる。

発注前に確認すべき5つの質問｜この回答で開発会社を見極める

開発会社に見積もりを依頼する前に、以下の5つを聞いてほしい。回答の質で、その会社の実力と誠実さが分かる。

質問1：「最初の1ヶ月で何をやりますか？」

「まず要件定義から」「まずヒアリングをして提案書を作成します」は合格。「とりあえず開発を始めてから要件を固めましょう」は注意が必要だ。最初のフェーズが曖昧な会社は、プロジェクトの進め方が整備されていない可能性がある。

質問2：「従業員20〜50人規模の会社への導入事例を教えてください」

自社と規模が近い会社での事例があるかを確認する。大企業向けの実績しかない会社は、中小企業特有の制約（予算・人員・スケジュール・ITリテラシー）に対応した経験が薄い場合がある。

事例を聞いた時に、成果まで語れる会社は信頼できる。「○○社に導入しました」だけでなく「○○社で月20時間の工数削減につながりました」まで言えるかどうか。

質問3：「見積もりの内訳を機能別に出してもらえますか？」

これを嫌がる会社は避けた方がいい。内訳を出すことを渋る理由は「どこが高いか知られたくない」か「そもそも内訳を考えていない」のどちらかだ。機能別の内訳があれば「この機能は後回しにできますか」という交渉ができる。

質問4：「保守・運用の費用はどれくらいかかりますか？」

開発費用だけで判断すると後から驚く。インフラ（サーバー代）、バグ修正、セキュリティアップデート、機能追加。これらが月額いくらかかるのかを確認する。月額費用が含まれるのか、別途費用なのかを契約前に明確にしておく。

質問5：「開発中の仕様変更はどう扱いますか？」

「すべて無料で対応します」という会社は怪しい。変更の都度、追加費用が発生することを契約書に明記している会社が健全だ。「○回まで仕様変更に対応」「重要度に応じて判断」といった回答も合格。変更管理のルールが明確な会社は、プロジェクト管理がきちんとしている。

規模別・目的別で変わる開発会社の選び方

システム開発の外注先は、規模によって最適な選択肢が変わる。

小規模案件（費用目安100万円以下）

まず既存のSaaSで代替できないかを確認することを強く勧める。月額5,000〜1万円のツールで解決できることに100万円の開発費用をかけているケースは珍しくない。

自社でも月3.5万円のツール代で、経理・請求書処理・コンテンツ制作・顧客管理をすべて回している。「開発しないと解決できない」課題は、実際にはかなり少ない。業務効率化は何から始める？最初の一歩を具体的に解説でも書いたが、まずツールで試して「どうしてもカスタムが必要」という判断をしてから外注に進む方が、後悔が少ない。

どうしても外注が必要な場合は、フリーランスのエンジニアが費用対効果が高い。クラウドソーシング経由で実績・評価・ポートフォリオを確認してから依頼する。小規模案件での注意点は「後から機能追加できる設計にしてもらうこと」だ。最初は最小限でも、後から拡張できない構造で作られると、機能追加のたびに作り直しになる。

中規模案件（費用目安100万〜500万円）

5〜20名規模のシステム開発会社が最適になるケースが多い。この規模帯は、大手開発会社は受けたがらず、フリーランスでは管理が大変なラインだ。担当者との距離が近く、意思決定が早いのが利点で、中小企業との相性がいい。

複数社に声をかけて、ヒアリング・提案・見積もりの質を比較する。提案書の内容だけでなく「どこまで業務を理解して提案してきたか」で判断する。

大規模案件（費用目安500万円以上）

RFP（提案依頼書）を用意して複数社から提案を取る体制が必要になる。この規模になると、開発会社の選定プロセス自体を支援してくれる外部の相談先を活用するケースもある。業務効率化の相談はどこにすればいい？中小企業向けの相談先まとめで相談先の種類をまとめているので参考にしてほしい。

いい開発会社と長く付き合うために

最初の「小さいもの」から始める

はじめて依頼する会社に、いきなり数百万円の案件を発注するのはリスクが高い。

まず小さい案件（LP制作、簡単なツール導入支援、5〜10万円程度の小規模改修）で一度試してみる。そこでのコミュニケーション・品質・スケジュール管理を見てから、大きな案件を依頼するかどうか判断する。

「試しに小さい案件で」という提案を嫌がる会社は、長期の付き合いより短期の利益を優先している可能性がある。

信頼できる会社を1社持つことの価値

中小企業にとって、「困った時に相談できるエンジニアや開発会社が1社いる」という状態は、それだけで大きな資産だ。

外部のシステムを使っていれば、必ず「これ、設定変えたい」「機能追加したい」「なんか動かなくなった」という場面が出てくる。その度に毎回一から業者を探すのは時間がかかる。信頼できる1社と継続的な関係を持っていれば、相談のコストが劇的に下がる。

「いい開発会社を探す」というより「いい関係を育てる」という考え方の方が、中小企業には合っている。

まとめ：「騙されない発注者」になるための5つの行動

開発会社選びで失敗しないために、今すぐできることを5つ整理する。

• 業務課題を数字で言語化する: 「なんか効率化したい」ではなく「毎月○時間かかっている○○を○時間以内に終わらせたい」
• 見積もりの内訳を必ず確認する: 「一式」で記載されている場合は、機能別の内訳を求める
• 保守・運用費用を含めた総費用で判断する: 開発費用だけで比較しない
• 小さい案件で先に試す: 大きな発注の前に、小さな依頼でコミュニケーションを確認する
• 確認事項への返答を素早くする: 発注側の返答遅れがプロジェクトの遅延につながる

「騙されない」というのは、知識を武器に相手を疑うことではない。自分の業務課題を言語化して、見積もりを読めて、変更管理のルールを決められる発注者になることだ。

いい発注者にはいいエンジニアが集まる。最終的に最もコストパフォーマンスが高い外注先を引き寄せるのは、「発注者自身の品質」だと思っている。

関連記事

• 業務効率化は何から始める？最初の一歩を具体的に解説
• デジタルツール導入で失敗する4つのパターンと対策
• 業務効率化の相談はどこにすればいい？中小企業向けの相談先まとめ
• 外注・ツール・採用、どれが正解？バックオフィスの人手不足を解消する3つの方法
• AI導入は小さく始めるが正解｜中小企業が失敗しない最初の一歩