あくまでも自分の経験上での話ではあるけれど、受託開発って問題のあるビジネス形態だと思ってます。以下、具体的に書きます。
まずなんといっても利益相反構造であること。発注元の会社にとっての利益と、受注側の会社にとっての利益が一致しないんですね。理想は双方がよりよいシステムを作るという共通のゴールを目指すことなんですが、受託開発の場合はゴールがそれぞれ逆方向に力が働いてしまう。
発注元にとってはより少ない金額で開発して貰うのが理想なんですよね。一旦仕様が決まって発注した後も、金額を変えずに追加仕様をがんがん放り込むのがベスト。そうすることによって同じ金額でより多機能なシステムを得ることが出来る。だから、いかに解釈の幅が広くなるような仕様書を押し付けるかに腐心するわけです。
受注先にとっては受注金額が決まっているので、より少ない工数で実装できれば利益が増えるわけですね。目指すゴールはよりよいシステムを作ることなんかではなく、いかに手を抜くかになります。極論するとシステムが動作しなくてもいい。検収さえ通ればそれでOKというスタンスになります。
当たり前ですが、こんなひどい話はそうそうはありません。大抵の受託開発プロジェクトはそこそこの品質でなんとかなっています。発注元にも受注先にも、それぞれそれなりに矜持も良心もありますからね。現場のモラルによって守られている。逆に言うとモラルが守られなくなると一気に利益相反構造が牙をむきます。ありがちなのがどっちかの会社の経営が傾いたとき。経営陣からコストカットの圧力がかかって現場がその言いなりになってしまってモラル崩壊が起きます。受託開発は常にそういうことが起こりえるリスクに晒されているということなんですね。
一番大きな問題は利益相反なんですが、それ以外にも問題はあります。それはコミュニケーションコストが高くなること。発注元と受注先が別々の組織ですから、そのコミュニケーションには時間も手間もかかります。同じ社内のチームであれば都度調整で済むようなことも、全て事前にやり取りして確定させる必要があります。そして確定させた事項は全てドキュメントに残さなければならない。でないと言った言わないのトラブルになってしまう。コミュニケーションに時間がかかる上に、ドキュメント作成にひたすら時間がかかる。これも受託開発の問題点ですよねぇ。
コミュニケーションの問題がありますから、システムにトラブルが合った場合に、その原因追究事態よりも、責任がどっちにあるかがひたすら問題になったりもします。そりゃお金の話になりますから大事な話ではあるんですが、エンジニアの立場としてはそんなどうでもいいことのために時間を割くのはバカらしいなぁとも思ったりもします。
なのでまあ、社内開発が理想ではあると思うんですよ。それでも受託開発が必要なのだとするなら、それはスポットでシステム開発が発生する場合のみですよね。スポットということは開発が終わったら開発チームは不要になるわけで、社内開発しているとその社員の雇用をどうするか問題になってしまいますからね。継続的に開発が続くシステムの場合、社内開発するべきだと思いますね。検証を兼ねた立ち上げ期であれば外部に開発を委託するのもありっちゃありですけれども。