システム開発の外注で失敗後のやり直し｜再依頼の見直し点
システム開発の外注で一度つまずいた会社が、もう一度依頼するときに何を見直せばよいかを整理します。失敗の原因を「作る側」だけに求めず、進め方・判断の材料・契約・納品後の4つに分けて振り返る方法を紹介します。あわせて、再依頼の前に確かめたい5つのポイントも分かります。
やり直す前に、失敗の中身を分けて考える
過去に外注で失敗した経験があると、「外注は向いていなかった」「もう頼みたくない」という結論に傾きがちです。ただ、一口に失敗といっても中身はさまざまです。中身によって、見直すべき場所が変わります。
私たちは、外注の失敗を大きく次の3つに分けて考えると整理しやすいと考えています。
完成したが、想定と違うものができた
納品はされたものの、使ってみると「思っていたものと違う」となるケースです。要件(システムに求める機能や条件)を文章や打ち合わせの言葉だけで決めたときに起きやすい失敗です。
言葉は、人によって受け取り方が変わります。「簡単に使える」「柔軟に設定できる」といった表現は、発注する側と作る側で、頭に浮かべている画面が違うことがあります。この食い違いは、完成して触ってみるまで見えにくいものです。詳しくはシステム開発の認識のズレを防ぐ、実物を見ながらのすり合わせでも整理しています。
途中で止まった、または完成まで届かなかった
開発の途中で仕様変更が重なる、予算や期間が足りなくなる、社内で承認が取れなくなるといった理由で、計画が止まるケースです。新規事業では、事業の見通しそのものが途中で変わることもあり、最初に決めた仕様のまま進めることが難しくなる場面があります。
この場合は、作る側の問題というより、「仕様と費用を先に固めてから進める」という進め方が事業の変化に合っていなかった可能性があります。
納品後に直せない、引き継げない
システムは動いているものの、改修を頼める相手がいない、中身が分からず手を入れられない、権利関係が曖昧で他社に依頼しにくい、といったケースです。納品の時点では問題が見えず、後から負担になって表面化します。
自社の失敗がどれに近いかを先に決めておくと、再依頼で何を重点的に確かめるべきかが見えてきます。複数に当てはまる場合も、順番に整理すれば問題ありません。
失敗の原因を振り返る4つの観点
振り返りの目的は、誰かの責任を決めることではありません。次の進め方を決める材料を集めることです。私たちは、次の4つの観点で整理するとよいと考えています。
- 目的：何のために作るシステムだったのか。事業上の目的が、関係者の間で同じ言葉で共有されていたか
- 要件：何を作るかを、どのように決めたか。文章だけで決めたのか、画面など実物に近いもので確かめたのか
- 判断：誰が、どの材料で、いつ判断したか。決裁者と現場で判断の材料や速度に差がなかったか
- 契約と体制：範囲、変更の扱い、権利、納品後の対応がどう決まっていたか。発注側の窓口は誰だったか
新規事業では、経営陣(決裁者)と現場(立案者)が同じ目的を見ているのに、判断の材料と進める速度が違うために話が噛み合わなくなることがあります。このとき、ずれているのは目的ではなく進め方です。過去の失敗にこの傾向がなかったかを確かめてみてください。関連する内容は新規事業で経営陣と現場がすれ違う原因は進め方のズレで解説しています。
要件の抜け漏れや食い違いが気になる場合は、要件定義とは？新規事業で抜け漏れとズレを防ぐ進め方も参考になります。
再依頼の前に見直したい5つのポイント
ここからは、再依頼の前に確かめたい点を5つに絞って紹介します。特定の会社に向けた話ではなく、どの会社に依頼する場合にも当てはまる一般的な見直し点です。
1. 判断の基準を先に言葉にする
最初に見直したいのは、「何をもって成功とするか」です。機能の一覧ではなく、事業としての判断基準を決めておきます。
たとえば、次のようなものです。
- 誰が使い、どんな行動が起きれば手応えがあると言えるのか
- 続行・変更・中止の判断を、いつ、誰が、何を見て決めるのか
- 判断に必要な材料は、開発のどの段階で手に入るのか
基準がないまま進めると、途中で「何となく違う」という感覚だけが残り、修正の指示も曖昧になります。結果として、作る側も直し方が分からなくなります。
2. 言葉だけでなく、実物で確かめる機会をつくる
過去の失敗が「想定と違うものができた」タイプなら、最も見直したいのはこの点です。
文章の仕様書や画面のイメージ図だけでは、実際の使い心地や操作の流れまでは伝わりません。動く実物に触れながら「ここはこう」と指摘できる機会があれば、「これじゃない」という違和感を早い段階で直せます。
実物と一口に言っても、種類はいくつかあります。見た目だけのモック、一部の機能が動くプロトタイプ、実際に使い始められる最小限の製品(MVP)などです。それぞれの違いと使い分けは、プロトタイプとMVP・モックの違いを整理で整理しています。
確認を依頼するときは、次の点を決めておくと進めやすくなります。
- いつの時点で実物を見られるのか
- 誰が触って、何を確かめるのか
- 直すべき点が出たとき、どう扱うのか
3. 最初に作る範囲を小さくする
大きな範囲を一度に発注して失敗した場合は、最初に作る範囲を絞ることを考えます。新規事業では、事業の仮説が正しいかどうかを確かめる前に、大きな投資をしてしまうと、見直しがきかなくなります。
最初は、事業の中心になる機能だけに絞って作り、確かめてから広げる進め方があります。機能の絞り方はMVP開発の機能の絞り方、投資判断との関係は新規事業の開発は小さく作って確かめる投資判断の進め方で詳しく書いています。
「小さく作る」ことは、品質を下げることとは違います。範囲を絞る代わりに、残した部分の確認を丁寧にする、という考え方です。
4. 権利・保守・引き継ぎを契約の前に確認する
「納品後に直せない、引き継げない」タイプの失敗を経験している場合は、契約の前の確認が特に重要です。確かめたい項目は次のとおりです。
- ソースコードや成果物の権利は、誰に帰属するのか
- 納品後の不具合対応や改修は、誰がどの範囲で行うのか
- 設計の資料や運用の手順は、納品物に含まれるのか
- 将来、別の会社に引き継ぐことはできるのか
権利の考え方は契約ごとに異なります。システム開発の著作権帰属は誰のもの？契約前の確認点で、確認の観点をまとめています。
AIを使って作られたコードの扱いが気になる場合は、AI生成コードの保守は可能かも合わせて確認してください。
また、システムは納品した時点で完成するものではなく、事業の変化に合わせて直していくものです。納品後をどう考えるかは、システムは納品後の改善で育てるで整理しています。
5. 社内の窓口と決める人を決める
意外と見落とされやすいのが、発注側の体制です。過去の失敗を振り返ると、技術の問題ではなく、次のような社内の事情が原因になっていることがあります。
- 窓口の担当者に、仕様を決める権限がなかった
- 現場の意見と経営陣の意向が、開発の途中で食い違った
- 確認の依頼に対する返答が遅れ、進行が滞った
誰が決めるのか、確認には何日以内に答えるのか、意見が分かれたときに誰が最終判断をするのかを、開発の前に決めておきます。決裁を取る場面があるなら、実物を使って説明する方法もあります。企画書だけで決裁を取る難しさは、新規事業の決裁を企画書だけで取るのが難しい理由に書いています。
同じ会社に頼むか、別の会社に頼むか
やり直しの依頼先を、前回と同じ会社にするか、別の会社にするかで迷うこともあります。どちらが正しいとは言えません。判断の材料を整理しておきます。
同じ会社に再依頼する場合
前回の経緯や、作ったものの中身を相手が把握している点は利点です。一方で、失敗の原因が進め方にあったのなら、同じ進め方を繰り返すと同じ結果になる可能性があります。
再依頼するなら、まず「前回、何がうまくいかなかったか」を双方で言葉にして共有します。そのうえで、進め方をどう変えるかを具体的に決めます。たとえば、実物を確認する回数を増やす、範囲を小さくする、判断の場を設けるといった変更です。
別の会社に依頼する場合
進め方を一から選び直せる利点があります。一方で、過去の経緯や成果物の中身を一から説明する必要があり、前回の成果物を引き継げるかどうかも確認が必要です。
選ぶときは、実績の数だけで判断せず、進め方が自社の状況に合っているかを見ます。見るべき視点はシステム開発会社の選び方｜新規事業で失敗しない7つの視点で整理しています。外注全体の流れを確認したい場合は、システム開発の外注ガイドも参考になります。
前回の成果物を活かせるかを確かめる
前回の成果物がある場合は、活かせるかどうかを先に確認します。確認したいのは、次の3点です。
- 画面や設計の資料に、再利用できる部分があるか
- ソースコードを、別の会社が読んで改修できる状態か
- 作り直したほうが、事業の確認に早くたどり着くか
すでに費用をかけたからといって、成果物を活かすことにこだわる必要はありません。これまでにかけた費用や時間は、後から取り戻せません。これから先に何が必要かだけを見て判断するほうが、事業にとっては合理的です。
相談の前に整理しておくと話が進む資料
再依頼の相談では、状況を整理して伝えられるほど、話が早く進みます。資料が完全にそろっていなくても、次のようなメモがあれば十分です。
- 失敗の経緯：いつ、何が起きたかを時系列で数行
- 当時の資料：要件をまとめた文書や画面のイメージ、見積書、契約書など、残っているもの
- 成果物の状態：動いているか、止まっているか、一部だけ使えるのか
- 事業の目的：このシステムで何を確かめたいのか、何を実現したいのか
- 決める人：最終的に判断する人と、日々のやり取りをする窓口
仕様がまだ固まっていない段階でも、相談はできます。進め方は、仕様が決まってないシステム開発の相談は可能かで紹介しています。依頼の前の準備を確認したい場合は、システム開発を依頼する前の準備と流れも参考にしてください。
また、PoC(概念実証)が途中で止まってしまった経験がある場合は、PoC失敗で終わる新規事業の共通点と本開発への進み方で、止まる原因を整理しています。
まとめ
過去に外注で失敗した会社がやり直すときは、まず失敗の中身を分けることから始めます。「想定と違うものができた」「途中で止まった」「納品後に直せない」のどれに近いかで、見直すポイントが変わるためです。そのうえで、目的・要件・判断・契約と体制の4つの観点で振り返ります。
再依頼の前に確かめたい5つのポイントは、次のとおりです。
- 成功の判断基準を先に言葉にする
- 言葉だけでなく、実物で確かめる機会をつくる
- 最初に作る範囲を小さくする
- 権利・保守・引き継ぎを契約の前に確認する
- 社内の窓口と決める人を決める
失敗の原因の多くは、誰かの能力ではなく、進め方にあると私たちは考えています。同じ会社でも別の会社でも、進め方を見直せば結果は変わる可能性があります。前回の経緯を整理するだけでも、次の依頼でやるべきことははっきりします。
私たちJustFit(サービス紹介)は、株式会社LEGAREAが運営する完全オーダーメイドの受託開発サービスです。「先に作って、後から決める」という考え方で、構想をもとに約1ヶ月で動くプロトタイプを先に開発し、実物を見てから契約を判断していただけます。過去に開発の外注で失敗した経験がある場合や、仕様が固まっていない段階でも、相談の対象です。再依頼の進め方に迷っているときは、状況をお聞かせください。