何故、内製開発の組織なのか

Webサービスの企業にいると漠然と内製開発が当たり前だと思っていて、SIerさんのような外部開発組織は時代遅れだと思っている部分がある。

実際はそんなことはなくて、わざわざ採用から人件費から組織管理が大変な内製開発をした方がメリットがある理由があるからこそ、そうなってるんだということをちゃんと噛み締めておかないといけない。

よく大企業DXの文脈で既存の基幹システム組織との切り分けの話をするケースにおいて、いわゆるSoRなシステムは、内部的な規約に基づいて構築されるシステムなので、仕様書がある意味全てであり、理想的な仕様書を作ることと、非機能要件も含めて仕様書通りに作ることが結果としての正解につながる。そういう意味では、適切なプロジェクトマネジメントと業務、仕様設計ができれば、開発そのものはSIerさんのような、ちゃんと作ってくれる外注組織にアウトソースしてしまっても良い。むしろ外部開発にお願いするところで仕様書がスクリーニングされるのであれば、設計自体がそこでブラッシュアップされる。つまりウォーターフォールのメリットはここにある。

ちなみに、そのプロジェクトがうまくいくのか行かないとかは、この話のスコープ外である。それは別に内製だって同じくリスクのある話なので。結局人の話に落ちるし。多重請負とかでコミュニケーションが破綻していて、作る側による作らせる側へのガバナンスが効かないとかは、そもそも組織としておかしいので、そういうが改善できない人たちの話は無視する。個人的にはそれのスケープゴートとしてウォーターフォールという手法がやり玉に上がってるのがかわいそうだと思ってる方。

それに対してWebサービスのような誰が使うかわからない相手に対してビジネスを実現するシステムをSoEと表現すると、こちらは、組織が維持できなくなるまでに何回失敗できるか？というトライの数が重要である。

もしもサービスの設計者がものすごく優秀で、考えたものが100%当たって、多くのユーザを虜にして業績がバンバン伸びるものが見通せるのであれば、多分、開発は外注で良いハズだ。オフショアなどを活用して低コストかつ低リスクで実現しても当たるんだったら、こんなに楽な商売はない。

しかし実際は外れる。「思ったように数字が伸びない」というのも含めて外れる。だからこそ、数字を伸ばすために試行錯誤しつづ得るわけで、それをチームとしてスピーディーに実現するための組織が必要で、システムをこねくり回してトライをし続けるためにも、自分たちのソースコードに精通した人員を確保し続けることになる。これが内製組織が必要になる理由。

個人的にはアジャイル開発という言葉において、どちらかというとプロジェクト管理的なソフトウエアデリバリーまでの手法というイメージがあったが、実はそうじゃなくて、このトライを含めてイテレーティブな開発をし続けて、ビジネスの成功に向けて試行錯誤し続けるプロセス全体がアジャイル開発なのだなと最近気がついた。少なくともWebのビジネスとして期待されているのはそこらへん。

これか

反復型開発 - Wikipedia