arclamp

ITアーキテクト 鈴木雄介のブログ

アジャイルがダメだと思う7つの理由

1.全体スケジュールにコミットできない
アジャイルはタイムボックス型（一定期間で棚卸しをして、それを繰り返す）のマネジメントをする。だから、全体としての計画は立てられない。「だって、最初に全ての機能を洗い出せないでしょ」というのは分かる、分かるけど全体の計画は立てないといけない。経営者は顧客やVCと全体の計画にコミットしなきゃいけないんだ。そのときに「やってみなきゃ分からない」なんて言えるわけでない。

てか「やってみなきゃ分からない」なんてことは誰でも知っているんだよ。でもさ、それを言わぬが花。大人なんだからコミットメントをしないといけないんだよ。そして、その達成ためには、あらゆる手段を尽くすのです。


2.アーキテクチャ上の無駄が生じる
ソフトウェアの構造や構成は工程が進むほどに修正しにくくなり、ずっと残る。だから、アーキテクチャ設計は慎重に全体を考えながらやらなきゃいけない。でも、アジャイルだから全体が決まらないとか言って、なんとなく流行の技術を使って作ってないか？そうやって作られた物は負債になる。

たとえばtwitterはRuby On Raisで初期構築したシステムをScalaに置き換えた。その無駄を超えるだけの成功が見えているからいいさ。でも、大抵の場合はそうじゃない。近視眼的なアーキテクチャが足かせとなり、生産性が落ちて、エンジニアのモチベーションを下げる。

もちろん、うまくアーキテクチャを組めているアジャイルチームだってある。でも、それはメンバーに優秀なアーキテクトがいただけのことでしょ。プロセスがどうあれ、アーキテクチャはちゃんと考えるべきなんだ。


3.コーチって何だよ
アジャイルコーチって何だよ。コーチって。コーチはチームの持つ解決能力を引き出すために存在する？何を言っているんだね。成果を生み出さない人員なんか不要なんだよ。

だいたい、それはエンジニアの甘えじゃないか。スーパー優秀だけど人間的に欠陥があるような人に付けるならいいよ。コーチ付けたってペイするだろうさ。でも、世の中の大半のエンジニアにコーチなんかいても、ベビーシッターと違わないでしょ。おしめぐらいは自分で変えて頂きたい。

そうだ、成果に貢献しているというならチームメンバーにお金を払うから、彼らからコーチにフィーを支払ってもらえばいい。チームメンバーがコーチのことを本当に必要だと思えば、つまり、この金を手に入れるのにコーチが役立ったと信じているなら、きっと十分なフィーがもらえる。そういう契約にする勇気がないなら「コーチやります」とか気軽に言うな。


4.変化ヲ抱擁スルために固定化している
変化に適応するというのは全ての開発チームが取り組むべき課題だ。

現在のソフトウェア工学は不十分なので構造的に柔軟性を得ることはとても難しい。テーブル構成をがしがし変えてもコードが付いてくれば良いけど、そんなことはできないから、アジャイルはプロセスを柔軟にして変化に適応すると考えた。これは悪くないアイデアだ。

でも、完璧じゃない。大抵の場合は要員を固定化するという前提が付くのです。ロールベースでないとノウハウが人に貯まり、どんどん引き離せなくなる。そして、同じ事を繰り返すメンバーはモチベーションが下がり、いつか辞めることになるのだ。


5.実証主義的な説明に過ぎない
世界中でアジャイルで成功した事例がある？うん、知っている。でもね、「成功したチームがあるから、お前のチームも成功するはずだ」なんて話はまやかし。優れたチームのプラクティスを実践しても優れたチームになるわけではない。順番が逆。

結局、良い人材がいればチームは成功するってことなんだよ。でも、そんなのは難しいから、個別のケースで現実的な手法をとるしかない。世の中の大半は普通のチームなんだから。


6.手段が目的になっている
大体さ、かぶれてんじゃないよ。トヨタにしても、リーンにしても、スクラムにしても、日本由来で海外が評価したからって浮かれているんじゃないと。

アジャイルの本質は顧客との信頼関係を築くこと？そうだよ、信頼関係はとても大事なこと。じゃあ「信頼関係を築くためならなんでもする」と言えよ。アジャイルという手法にこだわって「理解しない顧客が悪い」だの「契約が悪い」だの、そんなの言い訳でしょ。手段の目的化ほど下らないことはない。

だいたいさ「アジャイルで開発したいんです」みたいな案件、その時点で危険な臭いがするって気付けよ。どういうプロセスで開発するのが最も効率的なのかはプロに任せて頂きたい。


7.アジリティはアジャイルだけのものではない
今日のビジネス環境において、あらゆる企業にとってアジリティ（俊敏さ）は重要。そんなことは分かっていますよ。でも、アジャイルプロセスで実現できます！なんて、ちゃんちゃらおかしい。

プロセスで出来ることなんて、ほんの少しでしかない。ソフトウェアの構造や構成はどうなっているのか。そもそも、どういった機能を作るべきなのか。顧客がソフトウェアを使うことで価値が生まれているのか？

そういう全体にコミットしてこそ、アジリティを手に入れられる。アジャイルなんて、一部分に過ぎないことを自覚して欲しい。


＜補足＞
というような現実を受け入れつつ、どうやって行くのかということなんですよ。アジャイルが本格化して10年。そろそろ、次の議論に行ってもいいと思うんだ。


本文ここまで

＜追記１＞
続き：アジャイルをダメにしないためにすべきこと

＜追記２＞
「なにかいやなことでもあったんですか？」とご心配をいただいておりますが、特にいやなこともないですし、アジャイルで失敗もしておりません。アジャイルに関して見聞した失敗パターンを整理して、やや誇張して書いたものでございます。芸のうちとお考え頂ければ幸いです。

＜追記：みなさまの反応＞