アジャイルがダメだと思う7つの理由を前向きに考えてみる

アジャイルがダメだと思う7つの理由話題になっています。感想としてはTwitterでつぶやいた様に

「というような現実を受け入れつつ、どうやって行くのかということなんですよ。」が言いたい事であれば、「アジャイルをダメにする７つのパターン」で良かったような、、/ アジャイルがダメだと思う7つの理由 - arclamp arclamp.hatenablog.com/entry/2013/03/…

— さかばさん (@sakaba37) 2013年3月22日

と思っています。せっかく話題になっているので、私も便乗して前向きに考えてみました。

書いているうちに、ご本人が書かれている様に、良く言われているパターンを面白おかしく書かれているだけと言うのが透けて見えました。関連する議論には有益なものもありますが、気持ちが前面に出ているものもあり、私には不毛だと思えました。一部で解説を求められたので、追記します。

以前、論文を書く上での注意点で書いた様に、研究の初めの問題設定が新たな発見によって見直さないといけない場合、主張した点を裏返して問題設定します。今回はこの逆で、問題からどう実践すれば良いかを考えてみます。

物事の本質を見極めるには余分なものを取り払わないといけません。対称性、一般性、同値類などを考えて整理すると論理が明確になると思います。

1.全体スケジュールにコミットできない

全体スケジュールにコミットしないといけないなら、アジャイル開発しない。アジャイル開発と同様に理想時間で見積もるCCPMの方が向いているでしょう。 変動を認めるなら小さめの必須分のみコミットすれば良いでしょう。

元記事は「経営者は顧客やVCと全体の計画にコミットしなきゃいけないんだ。そのときに「やってみなきゃ分からない」なんて言えるわけでない。」とされています。

技術には適用範囲がある事を忘れてはいけません。アジャイル開発の特徴はタイムボックスを固定して実現する仕様の範囲（スコープ）を可変にする点です。仕様を固定すると言う事は優先順位の高いものから実現する事で無駄を省くという考えに合いません。

全体仕様を確定した上で無駄を省くなら、アジャイル開発でなく仕様を固定しタイムバッファを変動させるCCPMの方が向いているでしょう。スコープの無駄を省くものの一定のコミットメントが必要なら、優先順位を決めた上で、必須のものをコミットするのが良いでしょう。

2.アーキテクチャ上の無駄が生じる
アーキテクチャは予め検討して始めましょう。しかし、リーンソフトウェア開発で言われているように、最終責任時点まで決定をできるだけ遅らせることで、選択肢を維持しましょう。

元記事は

「アジャイルだから全体が決まらないとか言って、なんとなく流行の技術を使って作ってないか？そうやって作られた物は負債になる。」

とされています。当たり前の指摘なので、予め検討すべきだと思います。ただし、全てを決定する必要はなく、その時点で決めておかなければいけない事のみを決めれば良いはずです。選択肢の残し方はリーンが役に立つでしょう。

3.コーチって何だよ
コーチはニワトリです。身を削りません。豚はその卵を食べて甘えるなら、身を切られても余るぐらい知識を貯えないといけません。得た知識を再伝搬して元を取りしょう。

元記事は「成果を生み出さない人員なんか不要なんだよ。」とされています。スクラムの世界では身を切るものを豚、身を切らない努力をする者をニワトリと呼びます。アジャイルコーチはニワトリなので、存在する事によって効果がないといけません。投資対効果を考えろと言う事です。

4.変化ヲ抱擁スルために固定化している
暗黙知が特定の人に固定化されない様に気をつけましょう。ペアプロやコード共有は重要ということですね。

元記事は「大抵の場合は要員を固定化するという前提が付くのです。」とされています。アジャイル開発はドキュメントと言う形式知は必要最低限にして、コミュニケーションを活発にして暗黙知を活用します。

アジャイル開発の効果を期待するなら、ドキュメント増やさないで必要なアジャイルプラクティスを活用すれば良いでしょう。

5.実証主義的な説明に過ぎない
良い人材を育てましょう。

元記事「結局、良い人材がいればチームは成功するってことなんだよ。」とあるとおりです。元記事に「でも、そんなのは難しいから、」されていますが、プロセス改善は文化を変える事です。なので、これは何もしないと言う意味になります。

もし、求められるレベルが高すぎると言うなら、アジャイルコーチが短期的な解決策になりますが、3と矛盾します。

6.手段が目的になっている
目的や問題を見極めて手法を導入しましょう

タイトル通りですね。元記事の

「アジャイルという手法にこだわって「理解しない顧客が悪い」だの「契約が悪い」だの、そんなの言い訳でしょ。」

という意見はアジャイル開発を前提にしていて、プロセスに責任を持つプロとして、目的を見失っていますね。理解せずにプロセスを変更してはいけません。

7.アジリティはアジャイルだけのものではない
保守性の高い構造を考慮しましょう

元記事は「アジャイルなんて、一部分に過ぎないことを自覚して欲しい。」と言っています。ソフトウェア開発の目的はソフトウェアの開発です。あたり前過ぎてこれ以上は説明できません。

う〜ん、普通の話になってしまいました。

これまでの10年、救われないカルト宗教のような誇張した表現で色々な議論がされてきました。それはそれで面白いのですが、S/N比が悪くなってしまいます。もっと技術論をしましょうよ。