最近考えていることを独り言。ITにおけるコモディティ化の流れは、ここ最近のエントリで書いている。コモディティ化がおきると、価格競争に入りやすくなり、果てしない消耗戦が始まる。それでは、とても健全なビジネスを行うことは出来ない。
ビジネス単位の変化でコミディティ化を乗り切る、とはいうけれど
大きな話から入れば、ビジネスの世界ではコモディティ化を乗り切るための手法として、ビジネス対価の変革というのはよく議論されることである。ちょっと前の号になるがハーバードビジネスレビュー 2005年8月号の"「脱」コモディティ化の成長戦略"で論じられていたのが、UOB（unit of business：ビジネス単位）の変革だ。
例えば、セメント業界のセメックスは、販売するものを「生コンクリート」から「生コンクリートの配送」に変化させた。それは、顧客は必要なときに必要なだけの生コンが手に入ることを望んでいたことに気づいたからだ。そしてミキサー車の行き先を適宜変更できるシステムを開発し、地域の配送を最適化させた。この場合、UOBは生コンの量から納入時間帯に、つまり自社のビジネス単位から顧客が価値を置くビジネス単位にかわった訳である。
人月にかわる新しい単位は定義可能なのだろうか
アプリケーション開発のビジネス単位といえば"人月"である。「1人の人間が１ヶ月働く」という労働力を販売していた訳である。では、顧客が価値を置くものとは何だろうか。たぶん、完成したアプリケーションが与えるビジネス価値と言いたいところだろう。
だが、それは難しい。ITはインフラであり、それ自体が大きな価値を産むわけではない。ECサイトでは、ECサイトというアプリケーションがなくては1円も儲からない。しかし利益はあくまでも製品の販売によるものだ。それに、在庫管理、配送管理、支払管理、そういうアプリケーション全ての集合よって成立していることも忘れてはいけない。ようはクライアント自身も、そのアプリケーションの価値を正しく定義なんてできないのだ。
アジャイル／ハッカー・モデル
こういった問題を全て解決できるのは、クライアント企業自身が直接エンジニアを雇うという手法だ。
アジャイル型開発の成功例の多くは、企業が直接エンジニアを雇い、中長期的なスパンで開発を行うというものだ。この場合のコストは人を雇うための人件費に他ならない。ビジネス価値への対価という概念も、自社内であれば長いスパンで考えることができる。
それに圧倒的にコストが安い。「ハッカーと画家」的世界、最近では"はてな"の開発手法が注目されているが、まさにそれである。あれだけのシステムを構築しても、たいした投資を受けずにやっていられるのは、直接エンジニアを雇うことで異常に低い人月によって開発を行っているからだ。
試しにやってみれば良いと思う。実開発工数100人月（1億円）という案件があれば、10人の優秀なエンジニアに1000万円ずつ払って半年で実現できるはずだ。しかも、圧倒的に良い品質で。もちろん十分に優秀であると見極める力が必要だが、そんなもんだと思う。10倍の生産性、10倍の品質なんて当たり前なのだ。真のハッカーというは、そういう人種である。
こうした、アジャイル／ハッカー・モデルを言い換えれば、クライアント自身がリスクを取っているといえる。そして、人月はまさに人月であり、人件費というコストになっている。銀の弾丸を扱える（つまり、リスクに応じて正しい対処を行える）人間をそろえれば、人月の神話は実現できるのだ。
大型案件にはウォーターフォールとアジャイルのハイブリッド・モデル
僕自身、アジャイルに傾倒しているし、ハッカーという人種が好きだ。しかし、世の中それだけに回る訳ではないだろう。アジャイル／ハッカー・モデルの弱点は規模。数千人月レベルになってくると、それだけ多様で優秀な人物をそろえるのも厳しくなってくる。
そこで僕が思うのがアジャイル／ハッカー・モデルとウォーターフォールを組み合わせたハイブリッド型の手法である。
その前提が開発アーキテクチャと言えるものだ。いいかえれば開発を進めるための規約である。エンジニアのためのアプリケーション・ストラクチャーと開発フレームワーク、さらに設計者のための要求定義、設計手法によって成り立っている。そういう開発全体のアーキテクチャによって開発リスクは大きく低減させられる。
であれば、開発アーキテクチャにはアジャイル／ハッカー・モデルを採用し、それを利用して開発を行うチームは、ウォーターフォール・モデルであればよい。開発アーキテクチャによって全体の品質が30%でも向上するなら十分である。なお、開発時の生産性に寄与するとは思っていない。しかし、将来のメンテナンスコストを削減することを思えば、長期的なコストには大きな影響を与える数字だ。
たとえば、開発工数の10%をかけても価値と思うなら、1000人月であれば100人月ということになる。それだけのお金があれば十分に考えられた開発アーキテクチャができるはずである。
コモディティ化によって人月の有効性は高まった
アプリケーション開発が人に依存する、つまり人月という単位の有効性は、コモディティ化によって、さらに高まったではないだろうか。
かつて、コンポーネントとツールによって開発効率を上げようとしたことがあった。しかし、そここそがコモディティ化の波を受けてしまった。いまではオープン・コンポーネントを使いこなす力が重視されている（まさか、まだ商用製品を使う方が必ず安心だなんて思っている人、いないよね！？）。
たしかにITはコモディティ化された。しかし、対象は人ではない。
人月という言葉の持つ意味は多様になっているように思う。昔のように十把一絡げに語ることはできない。組織の1人月をどう使うのか。そして、その価値をどうやってクライアントに伝えるのか。考えなくてはいけない。ついでに僕の１人月をどう使うのかも。
