はじめに
ソフトウェアを本気でビジネスで活用しようと思うなら、ソフトウェア開発を内製化したほうが良いという仮説について考えてみた。
とくにアジャイル開発が主流になってくるであろうDX文脈において、開発を外部発注することの構造上の歪みを感じていたので、自分の思考を整理するために、まとまってはいないが書き連ねてみることにする。
アジャイル開発と内製化
日本ではソフト開発専門の会社に発注する（ようはアウトソース）ケースが多く、受託開発自体を本業とするSIerやSEという業種・職種が多く誕生してきた。欧米では違うらしいが。
自分たちが必要とするものが何か完全に見通せていれば、それで仕様化して発注してあとは待つだけ、というやり方でできるのだが、そんなことは滅多にない、ということが分かってきた。 使ってみて、フィードバックを得て、それをまた取り込んで、というやり方のほうが、本当に価値あるものを作り上げて手に入れることができる。これがアジャイル開発を導入する目的でもある。
では、ソフト開発会社に委託しつつも、アジャイルでやってもらえばいい、という考えもある。 それも一理あるし、実際にそのスキームでITシステム開発を行っている事業会社も日本には多い。
ここで、事業側（委託側）と開発会社（受託側）それぞれビジネスモデルについて考えてみる。
事業側は、開発したシステムを使って何らかの売上をあげる。売上-開発費用=利益となる（超ざっくりですが）。同じモノなら、安く作れば作るほど利益を増大することができる。
開発会社は、開発費用をもらって開発する。開発にかかる費用を差っ引いた残りが利益となる。
事業側も開発会社側も、それぞれ自社のビジネスをやっているわけなので、売上拡大や利益増加が重要な経営指標となっているはずである。 開発会社はたくさん仕事を受注し、それを少ない工数で完了させればさせるほど、利益率が大きくなる。 したがって、請負開発において同じ金額の開発を比較した場合、技術力向上やツール導入によって効率化をはかり生産性を向上させることで、自社の利益を大きくすることが出来る。つまり、生産性向上が利益に直結するわけである。（＝生産性向上に対するインセンティブが働く）
一方、アジャイル開発では、準委任契約となることが多い。 準委任契約のとき多くの企業では、アジャイルチームの人数×人月単価で契約をすることになる。そうすると、技術力やツール導入で効率化をしようがしまいが、利益率は一定である。 つまり、実績工数ベースの準委任契約では生産性向上が開発会社にとって自社の利益に直接は結びつかなくなるのである。（＝生産性向上に対するインセンティブが働かない）
長期的な目線で、事業側の予算内で多くの成果を上げ続けることで、事業の存続確率（継続性）とソフト発注にかけることのできる予算が確保できるという考え方もできるが、そこまで考えて活動できる受託開発会社は少ないのではないか。
目先の売上と利益確保が最優先で、細くとも長く継続することでLTVを最大化するといった、サブスクにあるような継続率を追いかける考え方は難しい。
また、受託開発で売上を伸ばし利益額を増大していこうとすると、エンジニアの頭数がボトルネックになってくるため、プロパー社員だけではスケールに限界がある。 したがって、協力会社への再委託や派遣社員といった形でプロパー社員ひとりあたりの抱える人数を増やすことでしか売上をスケールさせることができない。 結果として、実装に関与せずに比率としてメンバーの管理業務が多めの社員が増えていく。
継続的に開発し、ノウハウが蓄積されるようなソフトウェアの開発は、内製化したほうが良い。正しく内製化してこそ、ノウハウ獲得や自動化による生産性向上を自社の利益に還元できる。 （すでに業界や技術が枯れていて、どこがやっても生産性はある程度突き詰められているようなものは外部に発注してもよい）
新技術やツールの導入が、業績につながるような事業構造になっていないと、新しい技術の獲得がむくわれない。
もしくは上層部の理解が得られず、こっそりやるしかない。手を打つのが遅れる（そういう発注が来るまでやらないから）
わかりやすい例が、テスト自動化である。
受託開発会社にとっては、テスト自動化が自分たちのビジネスの利益につながらない。（競合についていくため/競合差別化という点では意味があるが）
力をかけてやる意味が薄い（毎回テスト工数をもらう方が売上稼げる）し、持ち出しで技術的負債を解消する意義はない。発注があれば対応する、という動き方になる。
事業会社とアジャイルチームを組んで人を完全に組み込んだ形の入り方は、開発会社からすると、メリットが薄い。高レートで長期的に体勢確保してもらえるならいいが、スケールはしない。 ソフト開発とソフトファーストや事業を切り離すことに無理がある。
つまり、目指しているゴールがそもそも違う2社でやっていく限りしょうがないということになる。
- 事業会社は、事業による売上と利益を追求する
- ソフト開発会社は、ソフトウェア開発それ自体で儲ける
そこで、内製化もしくは子会社戦略が必要になる。このとき、何も考えずに子会社を売上と利益をあげることを目標にして経営すると、外部の開発会社を使っているのと同じ事が起こるので注意が必要。 そうではなく、親会社のゴール達成の一部を切り出したミッションを開発子会社に与えるべきである。そうすると、ソフト開発の売上や利益よりも重要な指標があるはずである。 外部の会社にそんなことをお願いするのは無理だが、子会社に対してなら経営目標や方針にまで関与できるはず。アジャイル開発の時代に開発子会社をつくる意義はそこにあるのではないだろうか。
自由競争させるか、開発効率化するメリットが開発会社サイドにないと、新しいことに先行的に取り組んでいくモチベーションがうまれにくい。
結論
- アジャイル開発が適しているようなものは、内製化がベスト
- 内製化がリソース的に難しいなどであれば、開発子会社（OR関係会社）という手もあり。ただし、子会社は売上追求型ではなく提供価値重視型の経営となるように工夫が必要。
- 丸投げしても本当にOKといえる部分は、外部に発注すればよい（なんでもかんでも丸投げはダメ）
