受託開発もイノベーションのジレンマに陥るか

「「納品」をなくせばうまくいく」本が出てから、従来の受託開発とベンチャー企業向けスタートアップビジネスを対比した議論が多くなっている気がする。
以下、ラフなメモ書き。

【元ネタ】
SIer系エンジニアがベンチャーで働き始めるとぶつかる壁のリスト - IDEA and Players

アプリのリリースに必要な「引き算担当」について - @hitoshi annex on hatena

akipiiさんはTwitterを使っています: "SIとベンチャー・ビジネスの違い。「仕様」って言うな！「品質」ではなく「価値」を重視。作らない判断の重要性。「分業」より「協力」。SIer系エンジニアがベンチャーで働き始めるとぶつかる壁のリスト - IDEA and Players http://t.co/dBtT24aGSe"

【1】従来の受託開発にはいくつかのキーワードがある。
【1－1】仕様凍結、スコープ確定

システムの開発スコープを確定し、要件定義フェーズで要件を確定したら、仕様は凍結する。
顧客よりも、SIは仕様凍結を重視する。
なぜなら、要件を確定しなければ、開発費用がどんどん膨らむからだ。

【1－2】過剰品質

本番リリース後は保守フェーズになるので、一定金額の保守費用の売上がたつ。
その時、品質が悪ければ、保守費用よりも、システム保守に張り付く開発要員の工数が膨れ上がって赤字になってしまう。
リリース後のバグをできるだけなくすように、過剰なまでに品質を重視しがち。

【1－3】開発者の動員力

WF型開発では、要件定義から設計までは少数精鋭で進め、開発・テスト工程で一気に開発者を増やす。
下請けの開発者をかき集めて、労働集約的にシステムを作るのが普通だ。
そして、リリース間際に、大量動員した開発者をプロジェクトから離任させて、プロジェクトの原価を安定させるように持っていく。

つまり、上流工程と下流工程では、チームの人数が大きく変動する。
要員の変動に耐えられるのは、元請けと言われる1次請けの大手SIだけだ。

【1－4】プロジェクトマネジメント重視

下流工程で大量に動員した開発者を管理するために、元請けSIの社員はプロジェクト・マネージャとしての役割でチーム運営を期待される。
たくさん開発者がいるので、分業して手分けして作業する方が効率的。
つまり、プログラム開発がたくさんの開発者で並行作業で実施される。

しかし、このようなWF型開発の手法では、結合テストがビッグバンテストになりがちというリスクを伴う。
その結果、テストで予期しないリスクや手戻り作業が大量に発生し、品質を確保するどころか、延々とテストを繰り返すはめに陥りがち。

【2】だが、ベンチャー向けスタートアップビジネスでは、受託開発で慣れ親しんだ開発手法や開発スキルが通用しないらしい。
実際、SIer系エンジニアがベンチャーで働き始めるとぶつかる壁のリスト - IDEA and Playersで詳しく書かれている。

【2－1】仕様よりもMVP(minimum viable product)

仕様という言葉には、システムの要件は既に存在しているという前提条件がある。
しかし、スタートアップビジネスでは、売上が上がるかどうか、試行錯誤しながら開発するから、仕様という客観的なモノは存在しない。

MVPを作って、少しずつ試していく。
まさに小規模リリース。
すると、どの機能をリリースすべきか、という取捨選択が必要になってくる。

アプリのリリースに必要な「引き算担当」について - @hitoshi annex on hatenaでは、機能を削減する担当者が別途必要という指摘がある。
システムに何でもかんでも機能追加してみたくなるが、いかにシンプルにすべきか、という観点が大事。

XPの計画ゲームにも、機能を削減するという考え方がある。
XPが出現するまで、リリース計画では、一度リリースした機能を削減するという発想はなかったから、すごく驚いた時があった。

tech venture business ≫ Lean Startup基礎#3: MVPとは？

【2－2】「品質」ではなく「顧客の観点」を重視

SIにいると、過剰品質に陥りがち。
しかし、スタートアップビジネスでは、売上を上げる観点に基づき、システムを使うユーザを徹底的に考え尽くす。
例えば、AARRRモデルを使って、ユーザの行動を把握し、売上を上げるように持っていく。

「AARRR」　今更だけど絶対抑えておくべきグロースハッカーのコンバージョンの見方 | グロースハックジャパン | growth hack japan

ユーザは、どのように操作するか？
ユーザは、どのように感じているか？

システム開発で面白い点は、システムを作った開発者が想定しない操作をユーザが行うことだ。
ユーザは、プログラマの思い通りにシステムを触ってくれない。
ユーザはそう簡単に、システムに馴染んでくれない。
特に、業務システムではそう思う。

だから、顧客の観点を考えることは重要だと思う。

【2－3】分業よりもチーム力

WF型開発では、メンバーの役割は明確で、責任範囲も明確になっている。
指揮命令系統が一方的。
だから分業するのが普通。

しかし、スタートアップビジネスでは、メンバーの役割はその時々に応じて変わる。
むしろ、メンバーが自発的に仕事をとっていくことが求められる。
人が足りないというのも理由かもしれない。

【3】SIer系エンジニアがベンチャーで働き始めるとぶつかる壁のリスト - IDEA and Playersを読んでみると、受託開発はイノベーションのジレンマに陥っているような気もしている。

今までは、B2Bで、大企業向けの業務システム開発が多かった。
だから、システム開発ビジネスでは、受託開発が当然、という考えになりがちだった。

でも、「「納品」をなくせばうまくいく」本のように、スタートアップビジネスを支援するようなソフトウェア開発は、開発のやり方が違う。
当初は、スタートアップビジネスを支援するようなソフトウェア開発のマーケットは、B2Bの受託開発に比べれば小さかっただろうが、それがどんどん大きくなってきているのではないか。
つまり、スタートアップビジネスを支援するようなソフトウェア開発は破壊的イノベーションになるのではないか。

その象徴として、googleのように、次々に優れたWebサービスを提供するような会社が増えていることから明らかではないか。

「イノベーションのジレンマ」の本で最も興味深かったのは最初の一節だ。
イノベーションのジレンマ～過剰技術・過剰品質の罠: プログラマの思索にも書いた。

著者が「何故、優良企業が失敗するのか」という研究に取り組むために良い例はないかと探していた時、こんなアドバイスを受けたと言う。
遺伝の研究者は、人間ではなく、ショウジョウバエのように1日で生まれて死ぬ短いサイクルのモデルを使って研究する。
産業界で最も近いショウジョウバエの例は、ディスクドライブメーカーだから、それを元に研究すればいい、と。

我々IT業界にいる技術者も、ショウジョウバエみたいなものだろう。
ソフトウェア工学者が、ソフトウェア開発のあるべき開発プロセスを実験したい時、IT業界の技術者ないしSIを相手に研究すれば、それが可能かもしれない。
実際、Cobol→C/C++→Java/C#→LAMPと発展した歴史を振り返れば、開発プロセスがいかに開発環境や開発ツールに依存していたか、がよく分かる。
それもかなり短い期間の中で。

時代は静かに動く。
ゆでカエルにならないように注意していこう。