![見出し画像](https://assets.st-note.com/production/uploads/images/70001792/rectangle_large_type_2_e01af7a3644a8584511f7d39f07463e5.png?width=1200)
開発の外注はなぜ失敗するのか 真剣に考えてみた
少し前の話ですけど、COCOA不具合が起きた件で個人的に考えさせられた「開発の外注はなぜ失敗するのか」課題について話をしようと思います。
これまで色々なスタートアップやベンチャー経営者に聞いた、かつ手伝っていた会社での経験から「開発の外注はなぜ失敗するのか」を真剣に考え、どうやったら上手くいくのかまで自論を説明します。
上の記事でも語られている「丸投げ問題」以外の点にフォーカスして話を進めていきます。
特にwebサービス系のスタートアップの方や、これから起業したいと思っている方には凄く参考になると思います。
前提
そもそも開発の外注とは?
開発の外注に出てくる登場人物は「受託開発会社」「発注側企業」の2社と言えるでしょう。(COCOAの場合は複数社ありましたが、シンプル化のために2社とします)
そもそも受託開発とは「他社から開発を委託されて開発すること」です。
逆に受託開発側からみると、「他社のために開発をすること」と言い換えることができます。
図にすると以下のような形になります。
![](https://assets.st-note.com/img/1642260271218-QoWToTqyNd.png?width=1200)
受託開発のビジネスモデル
次に、受託開発のビジネスモデルの特徴について言及させてください。
もちろん労働集約型のビジネスで、尚且つ広告代行などと異なり短期的なフロー収入のモデルになっています。
※受託開発は2~6ヶ月程度で完了することがほとんどです。
そのため、今行なっている開発案件が終わる予定の時に、次に始まる案件を営業が探していることが大多数です。
![](https://assets.st-note.com/img/1642260829098-cAF7L6mi5X.png?width=1200)
前提の話はこの辺にして次から根本原因を見ていきましょう
根本原因
ここまで話を読んでいただければ、もうわかっているかも知れませんが、最大の原因は「受託開発会社と発注側企業の目線が擦りあっていないこと」です。
もう少し具体的な整理を以下に記載します。
▼受託開発会社の気にしていること
納期通りに案件を終わらせ、納期になれば報酬を受け取ること
▼発注側会社の気にしていること
ROIが高い開発をすること
└可能な限り安い金額で、良い開発をすること
解決方法
みなさんが気にしているであろう解決方法について自論を説明していきます。
解決方法は大きく2つで
①根本原因を解決する
②根本原因が問題にならなくする
だと考えています。
もっと詳細に見ていきます。
①根本原因を解決する
この根本原因を解決するには、受託開発会社のフロー収入型というビジネスモデルの特徴を変更させる必要があります。
この方法は個人的には以下の2つのみだと認識しています。
1-1. 受託開発会社に長期的に発注する
1-2. 受託開発会社とレベニューシェアを結ぶ
1-1. 受託開発会社に長期的に発注する
これは言い換えると「エンジニア採用をするのではなく、エンジニア会社を雇う」というようなものです。
そのため、超大手の会社以外は発注側の資金問題やROI判断で実行が難しいものがあると思います。
もちろんそんな事をする場合は、エンジニアを元から雇ってしまう方が良いでしょう。
※もちろん1人のエンジニアを雇わずに、0.1MMだけ発注を続ける等もあり得ますけど、その場合は本質的には受託開発会社のビジネスモデルは変わらないため、ここでは1MM以上の発注を続けるという意味で書いています。
1-2. 受託開発会社とレベニューシェアを結ぶ
実現可能性がある案の1つ目になります。
おそらくどこの受託開発会社も、凄く良さそうな開発案件の相談が来た場合にはレベニューシェアを提案していると思います。
なので、解決法1つ目としては「レベニューシェアを結んでくれる開発会社を探す」になります。
②根本原因が問題にならなくする
次に根本原因が問題にならなくするという、これまでの説明を裏切る形の解決法を説明していきます。
このために出来ることは個人的には以下の2つのみだと認識しています。
2-1. 目線が合っていなくても問題にならないくらい要件を定義する
2-2. 目線が合っていなくても問題にならないくらいミニマムな開発をする
2-1. 目線が合っていなくても問題にならないくらい要件を定義する
実現可能性がある案の2つ目になります。
詳細に見ると、もう一つ分岐があると思っていて、自社で要件定義ができるかどうかの分岐です。
結論この2パターンの解決法があると思います。
自社で要件定義できる:自社で要件定義をし外注する
自社で要件定義できない:要件定義と開発で発注フェーズを分ける
2-2. 目線が合っていなくても問題にならないくらいミニマムな開発をする
実現可能性がある案の3つ目になります。
これは馴染みがない方もいるかもしれませんが、俗にいう「MVP開発」をするということです。
▼MVP開発の説明はこちらの記事に譲るので、こちらを参照ください。
特に「MVP開発をノーコード開発ツールを用いて実施する」というのが個人的には良いと思っていますので、最後の解決法はこちらにさせていただきます。
※もちろんノーコード開発ツールで検証したいことが本当にできるかどうかのチェックは必須です
▼ノーコードについて知りたい方はこちら参照ください