「発注してから後悔した」という話を、どれくらいの会社が経験しているか。数字はないが、感覚的に多い。一方、「発注してよかった」と話す会社も存在する。同じシステム開発でも、なぜ結果が分かれるのか。
後悔する会社と後悔しない会社を分けるのは、開発会社の選び方だけではない。むしろ、発注前の準備量が、最大の差をもたらす。同じ開発会社に頼んでも、準備が整っていた案件は「期待通り」になり、準備が不足していた案件は「思っていたのと違う」になる。
後悔しない会社がやっていること5つ
①「何を解決したいか」を業務レベルで整理している
「業務を効率化したい」「データを一元管理したい」——これは目的ではなく、方向性だ。業務レベルで整理するとは、「現在、〇〇という作業に毎週〇時間かかっており、この部分をなくしたい」「入力ミスが月に〇件発生しており、チェック作業に〇人工かかっている」という具体性を持つことだ。
解決したいことが曖昧なまま発注すると、開発会社も何を作ればいいかわからない。結果として、「こちらが聞いたことを聞いた通りに作った」システムが納品される。動いてはいるが、何かが足りない、という感覚が残る。
後悔しない会社は、発注前に社内で「今どんな業務が困っているか」を洗い出す時間を作っている。この作業に丸1日かけることも珍しくない。業務課題を付箋に書き出し、類似のものをまとめ、影響の大きい課題に優先順位をつける、という作業を経営者だけでなくスタッフを交えて行う。それだけ、この準備が結果を左右する。
②複数社に見積もりを取って比較している
1社に見積もりを取り、それが高いか安いかを判断する基準がないまま「お願いします」と決めてしまう会社がある。これは発注者として最も不利な状態だ。相場感がなければ、提示された金額が適正かどうかを判断できない。
後悔しない会社は、同じ要件を最低3社に渡して見積もりを取る。金額だけでなく、「見積もりの内訳の詳しさ」「追加費用の発生条件」「保守サポートの範囲」「変更対応の方針」を比較する。安い見積もりが後から膨らむことも、高い見積もりに含まれている支援が実は重要なこともある。
比較することで、業界の相場感が身につく。この感覚を持っていると、開発中の追加費用交渉でも自信を持って臨める。また、複数社の提案を聞くことで、「自分たちが気づいていなかった課題」に気づくこともある。提案の場が、要件整理の場にもなる。
③プロトタイプや画面イメージを事前に確認している
言葉で合意した要件は、完成品を見て「思っていたのと違う」になりやすい。人は言葉より、実際に目で見て触れるものから具体的なイメージをつかむ。「使いやすい画面」のイメージは、言葉では伝えきれない。
後悔しない会社は、本開発の前にプロトタイプ（動作する試作品）や画面モックアップ（見た目の確認用画像）を確認することを、発注条件として求める。この段階で「ここの操作が直感的でない」「この情報はもっと目立たせたい」というフィードバックを出せると、修正コストを大幅に抑えられる。
「プロトタイプは作れますか」という質問をした際の開発会社の反応も、選定の参考になる。積極的に「作りましょう」と提案する会社は、発注者の視点を理解している。「それは費用がかかります」だけで終わる会社は、完成後の齟齬リスクが高い。プロトタイプに費用が発生しても、完成後の根本的な修正費用より安価に済む。
④変更管理のルールを最初に決めている
開発の途中で「やっぱりここを変えたい」は、ほぼ必ず発生する。問題はその変更に費用が発生するかどうか、発生するとしていくらかが、曖昧なまま進んでしまうことだ。
後悔しない会社は、契約の段階で「どの規模の変更から追加費用が発生するか」「変更の申請から承認までのフロー」「変更履歴をどこに記録するか」を文書化している。
この取り決めは開発会社への不信感からではなく、双方が気持ちよく仕事をするための合意形成だ。ルールが明確だと、発注者も「変えたいが言い出しにくい」という状況がなくなり、早い段階で変更を伝えられる。早期の相談は修正コストを下げる。ルールがないまま「また変更か」という雰囲気が醸成されると、双方の信頼関係が損なわれ、プロジェクト全体の質が下がる。
⑤稼働後の評価基準を持っている
「稼働したら終わり」ではなく、「稼働後に何が変わったかを評価する」という視点を持つ会社は少ない。しかしこの評価がないと、システムが本当に課題を解決したかどうかがわからない。「使えているが、よかったのかどうかよくわからない」という状態が続く。
後悔しない会社は、発注前に「稼働から半年後に、〇〇が〇%改善されているかどうかで評価する」という基準を持っている。たとえば「月次報告の作成時間が現在の半分以下になる」「入力ミスによる差戻しが月10件以下になる」という具体的な指標だ。
この基準があることで、開発会社との対話も「機能を作ること」から「課題を解決すること」に向かう。開発会社も「この機能がその課題に対して効果的か」という視点で提案できる。開発がゴールではなく、問題解決がゴールだという認識を共有できると、プロジェクト全体の方向性が揃う。
また、この評価基準が達成されなかった場合に、追加の改善依頼をする根拠になる。「なんとなく使いにくい」ではなく、「当初の目標に対して〇〇が不足している」という具体的なフィードバックができる。これが、稼働後の継続的な改善につながる。
発注前の1週間が、稼働後の1年を決める
後悔しない会社と後悔する会社の違いは、発注者の準備量にある。開発会社の技術力より、発注者の整理力がプロジェクトの成否を左右することの方が多い。
技術力のある開発会社でも、発注者が何を作りたいかを整理できていなければ「課題を解決するシステム」は作れない。技術は課題が明確になってはじめて、解決策として機能する。
1週間、社内で要件を整理し、複数社に見積もりを取り、プロトタイプを確認する。この準備に時間をかけた会社が、「発注してよかった」という結果を手にしている。準備を省略した時間の節約は、後から何倍にもなって返ってくる。発注の前に整理する習慣を持つことが、システム開発を成功させる最もシンプルな方法だ。
後悔しない発注者が「しないこと」
後悔しない会社がやっていることと同じくらい重要なのが、「しないこと」だ。
「要件を曖昧なまま発注しない」——急いでいるからとりあえず発注し、細かい要件は開発中に決める、という進め方は、後から変更費用を積み上げる。曖昧な状態での発注は、発注者にとって不利な条件での契約になりやすい。
「価格だけで選ばない」——最安値の見積もりを選ぶことが、最終的に最も高くつくことがある。安い見積もりの背景に何があるかを確認しない発注は、リスクを抱えたまま進めることになる。
「完成してからすべてを判断しようとしない」——完成後の根本的な変更は、もう一度作り直すことに近い。途中段階での確認の機会を求めない姿勢が、「思っていたのと違う」を生む。
しないことを意識することで、後悔につながる行動パターンを事前に避けることができる。発注は一度始めると後戻りしにくい。最初の選択の質が、最終的な結果の質を決める。