arclamp.jp アークランプ

　思いつくままに書いてしまったわりには、フィードバックをいただけたので再度整理してみます。

ハッカーであれば人月の神話は実現できる
　僕が書いた「ハッカーであれば人月の神話は実現できる」というのは同意していただいたみたいです。β. (Bee’s Blog)さんのエントリを引用します。

確かに、優秀な人材であれば、ほぼ見積り通りの工数かそれ以下の工数で、要求以上の品質を確保でき、結果として人月の精度がかなり向上すると思うので、この開発手法は、人月の神話を実現しうると思う。

ハッカーなんて集まらない
　しかし「ハッカーなんて集まらない」という指摘も同時に受けたと思います。それは、もう、その通り。なので、僕が思っているのを整理すると、次の2点です。

- 10倍優秀なら10倍払え
- 少ない優秀な人物を効率的に使うために開発アーキテクチャーに集中させる

10倍優秀なら10倍払え
　ハッカーなら生産性も品質も10倍にできます。だから、10倍払うのは当然です。ただ、これを外注でやろうとすると厳しい。なにせ人月100万円の10倍となったら人月1000万円ですから。でも自分で雇えば安く上がります。個人に月額200万円払えば年棒2400万円。これは十分に魅力的な金額でしょう。
　もし、優秀なエンジニアの市場が確立され、人材の流通性が高まれば、企業としてのリスクは小さくなります。もちろんエンジニアのモチベーションも高まるでしょう（これは年棒高額化などの問題は孕みますが、ある程度の年棒以上であれば、あとは仕事の面白みでいいと思ってくれる人が多いと信じます。欧米での事情はどうなんだろう？）。

　もちろん、これが理想論であることはわかっています。ただ、価値があるならお金をかけるという当たり前の認識はもっと広まって欲しいと思います。人月単価を安くしても品質が悪ければ意味が無い。でも、人月単価が高いSIが品質が良いわけでもない。だからこそ優秀な個人に対価を払えるような健全性が欲しいです。
　大きなプロジェクトであれば数百万円という金額は誤差の範囲になってきます。その規模こそ個人への対価を重視して欲しいなと思います。外注の優秀なエンジニアを雇うとしても、普通のエンジニア4人分ぐらいではないでしょうか。絶対にお得です。

少ない優秀な人物を効率的に使うために開発アーキテクチャーに集中させる
　優秀な人物は少ない（1つのプロジェクトにかけられる時間も短い）。だから、効率的に使う方法を考えなくてはいけません。僕が考えているのは「開発アーキテクチャー」の開発に使えばどうだろうということです。前回も書きましたが、開発アーキテクチャとは、

エンジニアのためのアプリケーション・ストラクチャーと開発フレームワーク、さらに設計者のための要求定義、設計手法

という幅広いものです。これをしっかり作っていれば、その後の大量実装フェーズへのリスクを減らせると考えています。ただアーキテクト1名とかでは厳しいですね。3-5人程度のチームである方が望ましいです。個人よりもチームが優秀であるというのは言うまでも無いことでしょう。

アジャイルとウォータフォールの有効性
もう１つ、アジャイル型開発で大規模開発できるのかという点。眠る開発屋blogさんは、

開発実装チームがウォータフォールのままだったら、結局、開発生産されたシステム自体は「変化ヲ抱擁セヨ」的なアジャイルの恩恵は受けられないのでは？と思う。

と書かれています。
　ウォーターフォール・モデルと書いたのがいけないのですが、開発アーキテクチャに"「変化ヲ抱擁セヨ」的なアジャイル魂"が織り込まれていれば、ある程度は柔軟にできると思います。
　仕様変更が発生しないことはありえないので「基本的には対応しないけど、対応できるようにしておく」というぐらいが現在のビジネスからすると落としどころかなと。つまりウォーターフォールにアジャイル的な要素を持ち込む、ぐらいの言い方の方が安心する人が多い。残念ですが、ここらへんが現実です。

　余談ですけど、UPの影響でイテレーションも使われる言葉ですが「1回目はパーツを作って2回目に作りこみます」って、それはイテレーティブでもアジャイルでもありませんｗ。ただのマイルストーンです。一部でいいからアプリをちゃんと仕上げていくことが重要なんです。そうしないとリスクヘッジになりませんから。組み上げるのではなく、成長させるという思考の転換が必要なのですが、なかなか難しいみたいです。

　最近、中～大型案件（数百～数千人月）に関わらせてもらうようになりました。アジャイルが良いのは知っているけど、それをどう使っていただくかというのは難しい問題です。いかに優秀なハッカーでも、動き始めた数千人月プロジェクトの方向性を変えることは出来ません。
　本で語られているアジャイルを、業務システムの現場で実現することは難しいです。でも、あきらめるのももったいない。だから、現場で使えるアジャイル／ハッカーというのは、また別の文脈で語られるべきかなと感じています。
　ハッカーを集めるのは難しい、アジャイルは難しい、よーくわかりますが、業務システムの現場でそれらを有効に使うにはどうしたらいいのか、みんなで考えていきたい話題です。