革新的な大規模システムは、受託では作れない

さ、やっと本題が書ける。表題の説明をする。

今まで、「ソフト受託ビジネスには、２つのビジネスモデルがある」ことを書いた。

１つは、単価を上げる戦略。
もう一つは、人数を増やす戦略
結果として（それを意図してるわけではないのだが）
　・前者は、設計に力を入れ、あらかじめリスクを回避する方法

　・後者は、とにかくやってみるので、開発後期にリスクが出る方法

となる。

---

　ここで、最近の最新技術？を導入した、革新的な大規模システムを開発することを考えよう。この場合、最新技術なので、全てを見通せない。そこで、後者の「とにかくやってみる戦略」を取ることになる。この結果、うまくいけば、開発できるが、まずい事が起こると、上記の「とにかくやってみる戦略」のように、テスト以降で問題が発覚、炎上することになる。

　これを回避するために、よく、「アジャイルで」ということになるが、

　アジャイルは

　　　　・革新的な小規模開発か
　　　　・漸進的な大規模開発

　に向いている手法である。

---

　アジャイルも、「とにかくやってみる戦略」なので、リスクはある。そのリスクを軽度に押さえるため、開発期間を短くし、細かく区切って確認しながらやっていく。そして、その結果を見て、取るべき手段を変えていく（アジャイルの文脈だとリーンのセットベース開発、経営の文脈だとリアルオプション）。

　リスクを制御するので、革新的なことはできるが、細かく区切って、（具体的には、１スプリントのレベルに）開発していくので、小規模開発ということになる。

　また、個々には革新的なことを行っても、それを長いスパンで継続的に行っていくので、全体的には、漸進的に見える。したがって、大規模開発に導入した場合、全体的に見ると、「漸進的な大規模開発」となる。

---

大規模開発を行う場合、リスクを押さえて行う必要がある。
ハイリスクの場合、ハイリターンにならずに、会社が潰れてしまう危険性が大きい。
リスクを押さえるためには、設計部分でリスクに対処しておく必要がある。
つまり、「設計に力を入れる戦略」となる。

しかし、この戦略は、リスクがある程度見えていないと使えない。
枯れた技術を使う場合は、リスクは見えるので、問題はない。
しかし、革新的な技術だと、リスクは見えない。なので、このパターンにはならない。

つまり、「設計に力を入れる戦略」は、　

　　　　・枯れた技術による大規模開発

には向いているのだが、革新的な大規模開発は、できない。
この開発方法は実はウォーターフォールに近い。
つまり、

　　　「ウォーターフォールでは、革新的な大規模開発はできない」

例えば、
　仕様がころころ変わってしまうような、クラウドのAPIや
　結局リリース時、できない仕様やバグがいっぱいあるOS
とかを使って、ウォーターフォールでは開発できない。
急にインターフェースが変わったりするから・・・

---

ということで、大規模開発は「受託で行う場合」

　　　・最新技術を漸進的に取り入れて行うか
　　　・枯れた技術を使って行うか

になる。前者はコアビジネスを行う場合、後者は、そうでないビジネスに対して（バックオフィス的な）有効な手法となる。

では、革新的な、大規模開発はできないか・・・

とは、書いていない。この場合、「とにかくやってみる戦略」でのテスト以降のリスクをすべて発注者が受け取ればよい。つまり、受託ではなく、発注者が情報システム部を使って行うか、請負受託ではなく、準委任契約をすれば、実現可能になる・・・理論上は・・・（ただし、そんなことをする会社はないが。。）

受託ビジネスは１人月いくらにすると儲かるか（３）戦略２：人を増やす

ソフト受託ビジネスには、２つのビジネスモデルがある話。
前回は、単価を上げる戦略。
今回は、人数を増やす戦略。

---

＜＜単価を上げる＞＞

人数を増やしても、もちろん、儲かる。
たとえば、１人月単価６０万でも、技術者数を２０人人にしたら・・・
１人月単価６０万だとしたら、１年で７２０万。
変動費が４００万だったので、
限界利益は７２０－４００＝３２０万
（１人あたり、３２０万、会社に入れられる）

固定費を３０００万と見ていたので、同じ７人でも、
３２０＊２０－３０００＝ざっくり３４００万くらい儲かる・・・

この場合、それで固定費大丈夫か？（部屋は足りるか？とか）
はあるけど、その分を増やしたとしても、まあ、前のモデルより結構儲かる。

---

ということで、この「低料金で、大規模化」というのは、
大手でよく取られる戦略になる。

この戦略のポイントは、固定費と人件費を抑えること。
そこで、
・固定費を抑えるため、実践教育中心。
　ネットで調べろ、実践で学ぶのが一番→体系的には教わらない

・人件費を抑えるため、出来ない人は切り捨てる
　そして、若い人をどんどん入れると、平均給与は下がる。
　離職率は上がるけど・・・

さらに、若い人をどんどん入れるため

・見栄えはよく
　　→そうすると、建物の固定費はあがるが、これは、たいしたことない。

こうすると、営業活動さえうまく行けば、会社はどんどん大きくできる。

---

じゃあ、これは、いいことづくめなのか？

実は、リスクが膨大になる！

教育を切って、実践中心になると、

・ネットで聞いた話で企画し、
・正常系を確認して設計し
　　→そもそも、聞いた話レベルなので、異常系がどうなるか、わからない
・そのまま実装にツッコミ・・・聞いてないよ状態になり
　　→ネットに書いてあることが、そのまま出来るとは限らない
・ITで異常系に耐えられず、設計をしなおし・・・
・STでパフォーマンスが出ず、さらにつくりなおし・・・

などということにもなりかねない。

たとえば、
・クラウドを使ってシステム作りたい
　　　→さいきんOpenStackって、きいた
　　　→監視はZabbixなの？
・正常系で設計し・・・
　　　→ネットがどうなるかなんて、知ったこっちゃない。
　　　　CAP定理をこよなく愛すので、トランザクションなんて考えない。
　　　　可用性のじゃま
・そのまま、実装にツッコミ
　　　え、zabbixで、OpenStackをどう監視する・・・
　　　ってか、そもそも、監視項目は何？
・ITで異常系に耐えられず・・・
　　　あ、やっぱり、トランザクションは必要でしたか・・・
　　　・・・そうですよね・・・
・STでパフォーマンスが出ず
　　　クラウド遅い（＞＿＜！）
なんてことにも、なりかねない。

こうなると、IT,STで炎上する。人は、こんな感じで必要。

この場合、大赤字。
しかし、こうならないでうまく行くプロジェクトも多い（多いと思いたい）。
なので、うまく行かなければ大赤字、うまく行けば利益。

というまさに、ギャンブル状態なのだ。

---

ギャンブルといってしまうと、対策ないのだが、
これを、リスクを保有する金融商品としてみれば、結構分かりやすい

つまり、短期化して、予測を立てやすくし、
自分が分からないものはやらないで
大量に、多種多様に保有する。

この点からも、短期勝負で、比較的開発規模の小さいアジャイルは、
有利なのだ。

なお、金融商品の場合、情報がオープンにならないと、判断を誤る
この開発の場合も、IT,ST段階で、情報がオープンにならず、
修正しやすいところから、修正していき、問題が後々まで残ると、
最終段階でとんでもないことになり、判断を見誤る