「お任せします」が失敗を作る。丸投げ発注が迷走する構造
発注側が責任を持たない案件は
必ず失敗する
経営相談で多いのが、開発案件の失敗後の相談です。
話を聞くと「業者に丸投げしました」という言葉が出てくる。丸投げ発注は構造的に失敗する。業者の技術力ではなく、発注側の姿勢で決まることが多い。
なぜ丸投げ発注が失敗するのか。現場で見てきた構造を書きます。
丸投げの正体は「考えることの放棄」
開発案件の相談で必ず聞くのが「何を実現したいのか」という質問です。
ここで明確な答えが返ってこない案件は、後で必ず失敗する。
よくあるのが「業務を効率化したい」という依頼。この状態で発注すると、開発会社は何を作ればいいか分からない。だから確認する。
「具体的にどの業務ですか」
「今どんな手順で進めていますか」
「何に一番時間がかかっていますか」
ここで発注側が答えられないと、仕様は決まらない。打ち合わせが増える。費用も時間も膨らむ。
問題は技術ではなく、発注側が自社の業務を言語化できていないことにある。
丸投げ発注の本質は、責任の転嫁です。「プロに任せれば何とかなる」という思考が失敗の構造を作る。現場でよく見るのが以下の流れ。
発注側が曖昧な要望を出す
↓
開発会社が仕様を提案する
↓
発注側が「お任せします」と言う
↓
完成後に「こんなはずじゃなかった」となる
「お任せします」は合意ではなく、思考の停止です。
判断基準がない発注は開発会社も困る
開発会社は発注側の業務を完全には理解していない。だから提案には必ず仮説が含まれる。その仮説を発注側が検証しないまま進む。
これが失敗の正体です。
そして、ここで見落とされがちな構造がある。
開発会社には、発注側の事業を成功させる義務がない。
契約上の仕様を満たせば、それで完了です。「使われなかった」「売上が上がらなかった」は、開発会社の責任ではない。言われたものを、言われた通りに作る。それが仕事です。
これは開発会社を責めているわけではない。構造の問題です。
打ち合わせの場でこういう場面をよく見ます。発注側が「もう少し使いやすくしてほしい」と言う。開発会社は「どのような操作を想定していますか」と返す。発注側が「そこはお任せします」と言う。開発会社は仕様書に書かれた内容を粛々と実装する。
誰も悪くない。でも、誰も発注側のビジネスゴールを考えていない。
もう少し踏み込むと、開発会社の評価軸は「納期通りに仕様通りのものを納品できたか」です。現場で使われているかどうか、発注側の売上に貢献しているかどうかは、評価の外にある。だから気にしない。気にする仕組みになっていない。
あるクライアントの案件では、完成後に現場スタッフから「このシステム、前の方が早かった」という声が出ました。開発会社に確認すると「仕様通りに作っています」という回答でした。どちらも正しい。でも、誰も現場の業務スピードを要件に入れていなかった。その判断をしなかったのは、発注側です。
作って代金を受け取る側と、使って成果を出さなければならない側では、見ているゴールがそもそも違う。発注側がこの非対称性を理解しないまま「お任せします」と言った瞬間、失敗の確率が跳ね上がる。
任せていいのは実装の方法であって、何を作るかの判断ではない。
発注側の仕事は「決めること」だけ
失敗する案件は、たいてい最初のヒアリングで分かる。
「どんなシステムを作りたいですか」という問いに、「そちらに提案してもらえますか」と返ってきた時点で、その案件は難しい。
判断できる人がいない組織には、共通した症状がある。
打ち合わせで「持ち帰って確認します」が毎回出る。確認した結果が翌週また「もう少し検討します」になる。仕様変更の理由が「上から方針が変わった」で説明が終わる。開発会社への要望が担当者によってバラバラで、都度矛盾が生じる。誰かが決めているようで、誰も決めていない状態です。
こういう組織では、開発会社も動きようがない。仕様が固まらないまま工数が増え、追加費用の請求が来る。発注側は「こんなはずじゃなかった」と言うが、決めなかったのは自分たちです。
私たちが開発案件に入る前に必ずお願いするのが、「判断できる人を一人決めてください」ということです。担当者ではなく、最終的にYES・NOを言える人。この一点を決めるだけで、案件の進み方が変わります。
これを決められない組織は、どんなに優秀な開発会社を選んでも結果が出ない。
発注側の仕事は、要件を言語化し、仮説を検証し、判断し続けることです。それを放棄した案件を、外部の誰かが救うことはできない。
開発案件の失敗について相談を受ける際、発注側の問題を指摘すると「そんなことを言ってくれたのは初めてだ」と言われることがある。
それ自体が、業界の構造を表していると思っています。
システム開発の判断に悩んでいる経営者の方へ
開発会社に言われるがまま進めてしまっている
完成したのに現場で使われていない
費用だけかかって成果が見えない
一つでも当てはまるなら、発注の設計を見直すタイミングかもしれません。
壁打ちレベルでも構いません。
Xで日々、システム開発や業務改善の考え方について発信しています。
気軽にDMください。
開発案件の成否は、技術ではなく「発注側の判断力」で決まります。
仕組みを変えれば、結果は変わります。
