勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

ディフェンシブなアジャイル開発

頭の体操。アジャイル創発的なアプローチでソフトウェア開発の諸問題を(適したプロジェクトにおいては)解決する。従来の計画駆動開発の石橋を叩いて渡る防衛的なスタイルに比べてオフェンシブな開発と呼ぶひともいる。開発をオフェンシブにした分、開発以外の部分でディフェンスを強化する必要があるのではないか。タイトルは釣り。

プログラムマネジメント

小刻みに、段階的にリリースを実施したからといって、必ずゴールに辿り着くという保証は無い。逆に袋小路に入ってしまって、大きな手戻りに繋がる場合がある。しかも先行してリリースしてしまった機能が重荷となって、前にも後ろにも進めなくなってしまう可能性がある(例えばデータ移行など)。この可能性を排除(または極小化)するためのプログラムマネジメント的な作業はやっぱり必要だと思う。

f:id:kent4989:20120319114157j:plain
SQUAREENIX OPEN CONFERENCE ゲーム開発プロジェクトマネジメント講座 2011年10月8日 より。(この資料はもっと有名になってもいい、すごい資料だと思う!)

実際にこのような問題に突き当たったプロジェクトの事例はあまり世の中には出ていない気がするが、例えばXPの原点となったクライスラーのC3プロジェクトは中止となったし、最近話題となったはてなブログの問題も本件を想起させる。

•連続的な進化に限界を感じている
•非連続な進化を起こしたい
新はてなダイアリーの裏側

継続性

前のエントリでも少し書いたけれど、アジャイル型にやる、ということは顧客(あるいはプロタクトオーナー)と開発者の境界を意図的に曖昧にすることだと思う。成果を出すために必要な事だけれども、チームは固く結び合わせられてしまう。これは逆に、離れにくくなるということだ。

自社組織の要員で開発をする(いわゆる)内製開発戦略をとるのでなければ、開発者は外部組織から調達することになる。開発が進むと強いロックインの力が働く。ロックインされた状態で、双方の方向性に相違がないなら幸福な結婚生活が続くだろう。でも主に市場動向などでビジネス方針が変わると、苦しい離婚が待っているような気がする。

具体的にはここらへんがリスクだと考えている。チームメンバーを外部から調達する場合にありがちな起こりそうな事。

  • 求められる成長スピードが釣り合わずに破局
  • 不況で破局(やっぱり真っ先に切られるのは外部組織だから)
  • より魅力的な相手に浮気される
  • 市場の要請により業態が変化して破局
  • 他のトラブルに巻き込まれて(修羅場)重要メンバーが離脱
  • 他のトラブルが原因(サイドビジネス)で継続できず
  • 労働市場の変化でコアメンバーが離脱(いまなら、ソーシャルゲーム系に人材流出)

じゃあどうすれば良いのかというと結論は無いのだけれども、「準委任だからOK」みたいな風潮については問題意識がある。