アジャイルについての雑感

コモディティ化と人月というなかなか興味深い記事があった。
主旨は、

ITがコモディティ化されたとしても、アプリケーション開発のビジネス単位が「人月」から変わることはなく、ますますそれは有効になる。

ってところだろうか。
それ自体はまぁそうだよね、というか、オープンソースが全盛になると、FP法などモジュール数、機能数に依存した見積もり手段ってあまり有効にならない気がする。
見積もり手法については今以て難しい問題であり、例えば、ナレッジシェアのツールMovableTypeをハックして作りました、なんて話になると、じゃあその手間賃はどうやって請求しようか?ってことになり、現在はそういったケースの算出方法が確立していない気がする。
結局、そのときどきの相場感だったり、人件費そのものをベースに弾き出すしかない。

(誤読があったらごめんなさいだけど)違和感があったのは幾つかの話だ。
例えば、アジャイルハッカー・モデルの話。

こういった問題を全て解決できるのは、クライアント企業自身が直接エンジニアを雇うという手法だ。
そもそも「アウトソーシングの波」以前は、ユーザ企業が(アプリケーション開発も含め)エンジニアを直接雇用していた傾向は今より強かったんじゃないの?と思っている。「アウトソーシング」って「固定費(人件費)削減施策」の面があったと思うのだが、そりゃあ自分のところでエンジニアを抱えるのが理想ではあるのだが、そもそもはコストカットという理由があったのでそれに至ったのであり、そこはクリア出来てないのでは?と思う。
なお、非継続的に発生する社内要件に対応すべく、また開発アプリケーションの品質を維持するという意味でも「優秀な」エンジニアをプロパーとして抱えておくのは現時点においても多くの企業で有効施策と考えられているとは思う。
最大の問題は、先の記事では一時担保されている「優秀なエンジニアの確保方法」ではないだろうか?「はてな」がケースステディとして上げられているが、「はてな」は「はてな」というブランド作りに成功した為、優秀なエンジニアがどんどん集まっていくる状況になっており、またITそのものがメインの事業になっているからこそ、プロパーとして抱え込むという戦略が成立するのではないだろうか?
中長期的に人間を育成するという手もあるのだが、該当企業において、システム部が間接部門的扱いであったとき、そこにそれ程の教育コストを果たして費やすか?というのは疑問が残る。

また大規模開発に対しては、ウォーターフォールアジャイルのハイブリッド・モデルを適用すべしと述べられており、開発アーキテクチャーチームはアジャイルハッカー・モデル、開発実装チーム自体はウォータフォールということで、アーキテクチャー部分に優秀なハッカーを集中させるというのはまぁそりゃそうだなってか普通と思うのだが、開発実装チームがウォータフォールのままだったら、結局、開発生産されたシステム自体は「変化ヲ抱擁セヨ」的なアジャイルの恩恵は受けられないのでは?と思う。

ところで、大規模開発にアジャイルモデルが適用可能か否かについてだが、Googleライブドア(メール術ってやつ)の情報共有の施策だったり、またははてなの「はてな開発モデル」がITの進化が規模による様々な制約をなくすという意味で(追記箇所)実は壮大なパイロットケースになっているのではないか?
はてなについては、社長が非システム工学畑の人間だからこそ出来たのだろうか)
例えば、「はてな」は「はてなアイディア」というユーザからの機能要求優先度の市場化を実践してしまったわけだが、アジャイルモデル内のタスク優先度管理についても、これに近い仕組みを取り入れることが出来るのではないか?とか。
個人的にはウォーターモデルとのハイブリッドでなくても適用できるのではないの?と思うが、それはちょっと甘いのかしら。