arclamp.jp アークランプ

　最近、「アジャイルは死んでいる」と思うことが多くなってきました。

（ちなみに僕のアジャイルの定義は『（規模にもよるが）数週間から数ヶ月程度の短期間で同一ソフトウェアのリリースを繰り返すソフトウェア開発スタイルで、漸進的な機能拡張を実現する』です）

最速は最適ではない
　アジャイルでは「開発者個人の生産性や効率を高めることが重要だ」と言われているようです。しかも、それがユーザーのためになるという。

　何度も書いていますが、早く作ったところで使われなければ意味がないのです。あぁ、いい事例が。（産総研：独法の電子申請、無駄　特許関連、８７５４万円かけ使用ゼロ－－検査院指摘）。

　使われれば今度はメンテナンス性が重要です。保守にはライフサイクルの60- 80%ものコストが掛かると言われていますから、メンテナンス性は作る事の1.5倍（60/40）～4倍（80/20）ぐらい重要だとも言えます。

　もちろん、開発効率を上げるのは大事です。でも、早いことが良いコトじゃない。例えばキーボードを早く入力できることは価値なのでしょうか？キーボード入力が遅いけど、結果的には僕より早くコードを仕上げるエンジニアを知っています。彼がすごいのは、ほぼ書き間違えをしないこと。ゆったりをしたリズムの中で着実にコードを組み立てていきます。

　重要なのは最適であることであって、最速であることではありません。無目的な効率化は単なる自己満足です。

他人の最適化手法が有効とは限らない
　では、そもそもアジャイルが目指すべき最適化とはどういったものでしょうか。

　よく聞くのはトヨタに代表される製造業で確立された手法の適用です。先日、某家電メーカーの業務用製品を作っている工場を見学させて頂きました。セル生産方式、カンバン、全部ありました。

　新しく入ったメンバーが行うダミー作業では作業目標時間が設定されていますが、それは「早くても遅くてもダメ」だそうです。通路には歩く速度を計測する装置があり、目標にされている歩く速度も「早くても遅くてもダメ」。天井からつられた電子掲示板には目標数と現在生産数、そして時間当たりの誤差が常に計算されています。値は常にゼロ、つまり「早くても遅くてもダメ」。

　また床に張り巡らされたテープによって荷物の置く場所、作業台の置く場所がセンチ単位で決まっています。それだけではありません。朝礼で人間が立つべき位置にまで足形が書いてある。

　チームの力を最適化するために個人のパフォーマンスは制約を受けるのです。まさに目的のための最適化。トヨタ方式はイテレーティブにカイゼンを行うことで最適化を維持し続ける優れた手法です。

　なるほど、では、このチームを最適化する手法は本当にソフトウエア開発でも有効なのでしょうか。ちなみに少なくとも僕には工場の現場が活き活きしているは思えなかったです。

　だいたいトヨタの手法が良いのかすら、現状のビジネス環境では否定的な意見も多いです。ビジネス環境は変化するので何に対して最適であればいいかという定義すら変わってしまうのです。そう言った中で、トヨタの手法に縛られるのはブランド信仰からくる思考停止ではないでしょうか。ソフトウェアは、ソフトウェアなりの最適化が何かを考え続けていけなくてはいけません。

契約まで含めた最適化ができていない
　このアジャイルの最適化にはマネジメントのコミットメントが非常に重要と思っています。開発者個人の努力だけではなく、その力を引き出すには契約含めた周辺を固めていく必要があります。

　最近、ある有名なアジャイル企業で聞いたのは、ある開発チームで顧客との契約が1ヶ月おきに更新されるというのでした。しかも、若干名とはいえメンバーの増減もありうる（前提として誤解の無いように言っておきますが、彼等は開発者としては優秀なチームです）。

　アジャイルは変化に適応するための道具ですが、そのために副次的に発生するリスクを開発サイドに押しつけるのは問題です。毎月契約更新というのは開発サイドのマネジメントからみれば非常にリスクの高い状態です（大げさに言えば相手が突然倒産するとか）。これまでの実績は関係ありません。実績に関係ないからリスクなんです。

　僕は先方のマネジメントがアジャイルに本気ではないのではとも思っています。もし本気なら中長期契約をしてメンバーの維持に努めるべきです。アジャイルチームではメンバーが替わることが大きなリスクだからです。ようはアジャイルを採用した場合に最適な契約形態について配慮が足りないのです。

「開発者のためのアジャイル」では死んだも同然
　僕は単純にアジャイルがダメだなんて言うつもりはありません。しかし、いまの「開発者のためのアジャイル」という位置づけでは、アジャイルは死んでいるも同然です。

　そもそもアジャイルが個人の幸福感やワーク・ライフ・バランスの文脈で語られるのは間違いでしょう。それらは組織マネジメントの問題であり、開発手法の問題ではないからです。この混同は現場への責任転嫁です。

　アジャイルは企業戦略のための手法であり、ビジネスのための手法だと位置づけるべきです。より実益があるものだと。だからこそ、「アジャイルが目指すべき最適化とは何か」を開発手法だけでなく、契約などマネジメントまで含めて検討を進めなくてはいけません。いま世界で起きているリーンのムーブメントは一つのヒントになるでしょう。

　残念ながら、まだまだ僕も実現に向けて努力をしているところで事例は持っていません。現在は必要要件からアジャイル的であることを導きつつ、まずはアーキテクチャの整備から入っています。今後、チーム体制、契約形態含めて継続的に提案をしていくことになります。

　残念ながら道のりは遠い。ですが、僕らはアジャイルの精神に従って一歩一歩進まなくてはいけません。

　Agile 2009で日本から参加したメンバーが集めたメッセージの中でとても素敵なものがありました（ href="http://www.youtube.com/watch?v=p64wpnOyW-g">Agile2009 Hi! Clutch! はーい！倉っち！　ぜひ4:55を見て、彼女の言葉で聞いて欲しいです）。

Remember, it's all about learning. Take small steps and learn, good luck.

忘れてはいけません、すべては学びなのです。小さな歩みで学び続けましょう。幸運を