「アジャイルがダメだと思う7つの理由」から始まったアジャイル論争の現時点のまとめ

2013年3月25日

アジャイルがダメだと思う7つの理由」という刺激的なタイトルのエントリを、先週木曜日、3月21日にグロースエクスパートナーズの鈴木雄介氏が公開してから、アジャイル開発に関する議論の波紋が広がっています。

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

おそらく、これだけさまざまなブログを通じてアジャイル開発の議論が活発化したことはこれまで国内ではなかったのではないでしょうか? ここでは現時点での議論をまとめますが、興味のある方はぜひここを起点にそれぞれのエントリを読んでみていただきたいと思います。

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

発端は鈴木雄介氏(id:arclamp)のブログarclampにポストされた「アジャイルがダメだと思う7つの理由」というエントリ。以下がその7つの理由として挙げられたものです。

1.全体スケジュールにコミットできない
2.アーキテクチャ上の無駄が生じる
3.コーチって何だよ
4.変化ヲ抱擁スルために固定化している
5.実証主義的な説明に過ぎない
6.手段が目的になっている
7.アジリティはアジャイルだけのものではない

その中身は、例えば1の「全体スケジュールにコミットできない」について。

「だって、最初に全ての機能を洗い出せないでしょ」というのは分かる、分かるけど全体の計画は立てないといけない。経営者は顧客やVCと全体の計画にコミットしなきゃいけないんだ。そのときに「やってみなきゃ分からない」なんて言えるわけでない。

3の「コーチって何だよ」では。

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

と、アジャイルをばっさりと切るエントリになっていますが、補足で次のように書いて、議論を促しています。

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

アジャイルがそんなにダメだと思わない7つの理由 - haradakiro's blog

アジャイルがそんなにダメだと思わない7つの理由

これにいち早く反応したのが、id:haradakiro氏のエントリ「アジャイルがそんなにダメだと思わない7つの理由」です。冒頭に「がんばって返答を書いてみる。どこかでディスカッションできるといいなぁ。」と書きつつ、鈴木氏の主張への反論と同意を示しています。

例えば1の「全体スケジュールにコミットできない」については、次のように反論。

全体を見えずに計画したところでうまくいくはずはない。アジャイルがタイムボックスで計画、実施を行うからといって、全体を計画しないわけではない。むしろ積極的にやるべきである。

3の「コーチって何だよ」では同調しつつも、第三者は必要ではないかとの主張。

これは痛い。かといって、成果に連携した契約にする気もない。(略)そこを見える第三者がプロジェクトの近くにいるのは、必要なことだと考えている。

5の「実証主義的な説明に過ぎない」では同意。

その通り。すべてのベストプラクティスは過去のプラクティスである。次にうまくいく保証はない。

6の「手段が目的になっている」でも同意。

まあ、その通り。それでビジネスにはならないし、すべきでもない。

アジャイルがダメなようでダメじゃないちょっとだけダメだと思う7つの理由 - Hのキーがhellで、Sのキーがslaveだ、と彼は思った。そしてYのキーがyouだ。

アジャイルがダメなようでダメじゃないちょっとだけダメだと思う7つの理由

鈴木氏がポストした翌日に、id:ledsun氏が自身のブログにポストしたのが「アジャイルがダメなようでダメじゃないちょっとだけダメだと思う7つの理由」というエントリ。

こちらも7つの理由について1つずつご自身の主張を記していますが、いくつかピックアップしましょう。

5の「実証主義的な説明に過ぎない」では。同意しつつ、コーチの必要性を説きます。

「優れたチームのプラクティスを実践しても優れたチームになるわけではない。」に同意。

(略)

アジャイルでは自分たちが何をするかは自分たちで選ばないといけない。誰かが決めてくれたプロセスを守ってればいいわけではありません。ホント アジャイル開発は地獄だぜ?

はじめてアジャイルやるなら、まずKPTから。ファシリテーションできないなら、そういうときにアジャイルコーチを呼べばいい。

6の「手段が目的になっている」では、アジャイルの始め方としてはアリではないかと。

「よくわかんねーけど、かっこいい」で始めるのもアリだと思います。

7の「アジリティはアジャイルだけのものではない」については以下のように同意。

まさしく!開発プロセス変えて開発者のアジリティが上がるとボトルネックが発注者に移動するんだ・・・

上司からの"アジャイルがダメだと思う7つの理由"になんと答えれば良いか - しゃなりしゃなりと

“アジャイルがダメだと思う7つの理由”になんと答えれば良いか

鈴木氏の元部下だというid:yusukefも、「上司からの"アジャイルがダメだと思う7つの理由"になんと答えれば良いか」というエントリで議論に参加してきました(ちなみに、ここまで紹介した4つのブログは全部はてなブログですね)。まず、次のようなスタンスを最初に表明。

現場のいろんなステークホルダーに今回の7つの”ダメ”を言われ場合に、どう切り返すか?という形で意見を述べたいと思います。

1の「全体スケジュールにコミットできない」については、

スケジュールはチームで決めてチームでコミットしましょうよ。

と、前向きな解決を提案。

3の「コーチって何だよ」については、

チームの自己組織化が閾値を超えるまでは、チームの外から「君の仕事の目的は何かね?」って聞く役割は必要だと思うんですよ。

と、一定の役割があると主張。4の「変化ヲ抱擁スルために固定化している」については、

せめて要員数は同じにするのはお勧めですよ。だって、要員数固定してしまえば、コストは固定化されて、チームの生産性とチーム同士の生産性の違いがトラッキングできるようになるんですよ。

と、固定化の一面にはメリットもあることを指摘しています。このエントリは全体に元上司愛にあふれるものでした:-)

アジャイル開発を多角的に捉えられる

ここまで紹介してきたブログのエントリはどれも、それぞれの経験や知識に基づいてアジャイル開発の現状とそのよい面、悪い面、あるいは改善すべき点などを指摘したものとして読むことができます。

Publickeyもそうですが、アジャイル開発やDevOpsなど新しい手法や技術やムーブメントを紹介する場合には、どうしてもその優れている部分や特徴が紹介される一方、それが現場で実際に使われたときに何が起きたか、どう評価されているのか、といった部分は情報量の少なさや、(コンテキストの共有の難しさなどゆえに)文章として表現することの難しさなどなどがあってなかなか伝えられていません。

その意味で、さまざまな開発の現場に関わる人がそれぞれの立場で意見を表明した今回のケースは、アジャイル開発を多角的に捉えて考えを深めていくうえで参考になるものだと思います。

そのほか、今回の議論に関連したエントリを見つけた範囲でリンクしておきます。

(2013//3/29追記)
鈴木雄介氏が、これらさまざまな反応に対してあらためてご自身の考えをまとめたエントリ「アジャイルをダメにしないためにすべきこと」を公開しています。

あわせて読みたい

DevOps アジャイル開発




タグクラウド

クラウド
AWS / Azure / Google Cloud
クラウドネイティブ / サーバレス
クラウドのシェア / クラウドの障害

コンテナ型仮想化

プログラミング言語
JavaScript / Java / .NET
WebAssembly / Web標準
開発ツール / テスト・品質

アジャイル開発 / スクラム / DevOps

データベース / 機械学習・AI
RDB / NoSQL

ネットワーク / セキュリティ
HTTP / QUIC

OS / Windows / Linux / 仮想化
サーバ / ストレージ / ハードウェア

ITエンジニアの給与・年収 / 働き方

殿堂入り / おもしろ / 編集後記

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed

最新記事10本