「アジャイル開発」は存在しない？　その1～アジャイル開発とカレー、そしてScrum（スクラム）の話～

今回は若干釣り気味のタイトルになってしまいました。最後まで読んでみて「やっぱり釣りだったじゃないか！」となるか、「なるほど、そういうことか！」となるか、もし弊社のブログにコメント欄があったら盛り上がっていた（荒れていた？）かな、と思いつつ始めてみたいと思います。

その前に今回何故このような記事を書こうと思ったかについて少しだけ。きっかけは大きく2つです。1つは社内の資料の確認のために、久々にAgile（アジャイル）関連の調べものをした際、「アジャイル開発」の説明と言いつつ（こちらはまだ分かるのですが）「Scrum（スクラム）」の説明がされている記事を見つけたり（昔ありましたね。Javaの本というタイトルなのに、中身を見てみたらJavaScriptのことが書いてあった本とか）、うーん、と唸ってしまう（≒頭を抱えてしまう）ような説明を見かけたりしたこと。もう1つは、昨今流行っているChatGPTにアジャイルについて質問したら、まだちょっとツッコミどころはあるけど「そうそう」と思えるような回答が返ってきて、少々驚いた反面このまま進化が進んだらAIの説明に勝てなくなりそうだから、今のうちに勝てる（？）ような回答を作ることができるかに挑戦してみたかったから、ということになります。

早速始めようと思いますが、最後に副題の「Scrum（スクラム）」については、次回（とその次の回？）のメインの話題になる予定です（いざ書いてみると、少々長くなってしまいました、、、次回、お楽しみに！？）

まず、ソフトウェア開発における「Agile」という言葉の起源・出自についてはご存知でしょうか？有名な話なのでご存知の方も多いとは思いますが、今から遡ること20年以上前の2001年2月に、17人の著名なソフトウェア開発手法の提唱者がアメリカ合衆国のユタ州のスノーバードに集まって生み出されました。正確には、それぞれの主張する開発手法が共有する価値観について議論された結果、採択された言葉・概念ということになるでしょう。
　⇒　有名な「Manifesto for Agile Software Development（アジャイルソフトウェア開発宣言）」というものです。

日本で「アジャイル」という単語が流行り始めた当初には「アジャイル開発という概念・ルールがあって、そこから具体的なScrum（スクラム）やXP（エクストリームプログラミング）の開発手法が生まれた」というような勘違いをしている人を少し目にしました。ですが本当は全く逆で、ScrumやXP等の開発手法が先に生み出されて、その後にそれらの共通する価値観・哲学についてまとめられたのが「Manifesto for Agile Software Development」（アジャイルソフトウェア開発宣言）ということになります。実際、Scrumが初めて実際のプロジェクトで試行されたのは1996年ですし、XPの書籍が初めて刊行されたのが1999年10月ですので、いずれもAgileという単語が生まれる前から存在していました。

実はその他にも1990年代にはDSDM、Crystal、FDDといった軽量級開発手法（軽量級開発プロセス、軽量級フレームワーク）が雨後の筍の如く次々に世に出ていました。
「軽量級」？そう、じゃ、その反対の「重量級」って何なんだ、という話になりますが、これは皆さんよくご存じの「Waterfall」なんですね。関係者へのガッツリとした要件定義に始まり、設計、開発、テスト、運用・・・という「滝が上から下に流れるように」「手戻り（前工程への後戻り）を許さない」という、「いわゆる」Waterfall開発手法というものです。ただ、そもそもこちらにも結構な誤解がありまして・・・

Waterfallは Winston W. Royce 氏の書いた1970年の論文「Managing the Development of Large Software Systems」が元になっている、という話からして既に誤解があり、、、本題から外れすぎるので、こちらの方は下記の参考資料や動画に譲ります。
ただ、もし自分が Royce 氏だったとしたら「そもそも自分が書いた論文の中で Waterfall なんて言ってないし。そして、前工程に手戻りしたらダメなんてことも言ってないし。むしろフィードバックループする方がいいよ、って言っているし」と、ボヤいていると思います。

本題に入る前に、「アジャイルソフトウエア開発宣言」を採択するにあたり、17人の個性が強い（クセが強い？）人達が2001年に集まった時の話について、書籍「アジャイルソフトウエア開発」の17人の中に名を連ねている Alistair Cockburn 氏が少し記述しています。

流石にクセが強い方々の集まりだったなぁ、と。特に4つ目。「同意しないことに同意する」というのがミソですね。
そういえば、UMLの規格の策定の際も似たような話があったような気がしますが、方法論者（メソドロジスト）という方々は皆そうなんですかね。
（「テロリストとメソドロジストの違いは？ 前者とは交渉できるが、後者はノン・ネゴーシャブル（交渉できない）」というジョークがあることを思い出しました）

もう少しこの辺りの歴史的な話に興味のある方はこちらの動画なんかが面白いと思います。
「アジャイルよもやま話 ~ 川口 恭伸さんとアジャイルの歴史を振り返りながら学ぼう」

それと同じく川口さんのこちらのブログ（アジャイルマニフェスト10周年 - アジャイルマニフェストはどう生まれたのか ）も面白いかもしれません。

と、前置きが長くなりすぎました。そろそろ本題のアジャイル開発とカレーの話に進みたいと思います。

私が昔よく読んでいた某グルメ漫画に、単行本1冊丸ごとを使った「カレー」についての話がありました。その中のストーリー展開が今の「Agile」に共通する点が多いなと感じたので、そちらになぞらえつつ、私なりに「Agile」について説明してみたいと思います。

その漫画では、仲の良い会社の同僚達とキャンプに行った際、昼食にカレーを作る時に揉めたことから始まります（市販のルーを使ったらダメとか、小麦粉入ったらダメとか、ジャガイモを入れるとか入れないとか。結局その時は話がまとまらずにカレーが作れず、肉野菜炒めになっていましたが）

場面は変わって、この漫画の最大の敵役の海○雄○が、町で評判のカレーショップに訪れ、そこの店主に対して質問を投げかけます。
「これは本物のカレーか？」
「まず第一にカレーとはなにか？カレーの定義だ。カレーと呼ばれるためにはなんとなにが必要なのだ？」
「辛ければそれがすべてカレーなのか、色が黄色ければカレーなのか？」
「スパイスを調合すると言ったが、これを欠いたらカレーといえなくなるという、決め手のスパイスはなんだ？」
「この店は何を根拠に、あるいはなにを標準にして、スパイスの調合をしているんだ？」
「第二の質問だ、カレー粉とはなんなのだ？」

令和のこの時代、こんなことしたらクレーマーとかカスハラとか言われて炎上しそうですね。
ただ、この中の単語をちょっと本稿の主題に沿って置き換えてみますと、以下のような感じになります。

「これは本物のアジャイル開発か？」
「まず第一にアジャイル開発とは何か？アジャイル開発の定義だ。アジャイル開発と呼ばれるためには何と何が必要なのだ？」
「ドキュメントを書かなければそれがすべてアジャイル開発なのか？、計画を立てなければアジャイル開発なのか？」
「朝会やペアプロをやっていると言ったが、これを欠いたらアジャイル開発と言えなくなるという、決め手の開発手法（プラクティス）とは何だ？」
「あなたの開発現場では何を根拠に、あるいは何を標準にして、アジャイル開発を実施しているのだ？」
「第二の質問だ、プラクティスとはなんなのだ？」

さて、いかがでしょう？この問いかけに答えられますか？


と、ここで話を振りっぱなしになってしまうと、「じゃ、お前はどうなんだ？」というツッコミの矢が山ほど飛んできそうなので、ハリネズミみたいになる前に、私見を述べておきたいと思います。まぁ、述べたら述べたで「それってあなたの感想ですよね？」というツッコミの嵐になりそうですが、「厳しい北風は気骨あるしたたかなバイキングを生んだのだ！」というお話もありますし、勇気をもってチャレンジしてみます。

結論から述べると「アジャイル開発」については、「【アジャイル開発】という唯一絶対の具体的な開発手法は存在しない」が、「アジャイル【な】開発手法はScrum、XPを始め幾つも存在する」というのが私の結論になります。

単なる偏見かもしれませんが、Waterfallを引き合いに出して「アジャイル開発」を説明しようとする場合に、あたかも「アジャイル開発手法」というものが存在しているかのような説明になっていることが多い気がします。例えば「Waterfallでは初めに要件定義を行って、設計、開発、テストと進められるが、アジャイル開発では毎日朝会で進捗報告して、2週間で分割された機能をリリースしていく」というものです。（そして、そういう説明をしている人の場合、先述したようにWaterfallも誤解している場合が多い気がします。。。）

大体先に説明した通り、「アジャイルソフトウェア開発宣言」自体が、ソフトウエア開発における価値観や哲学、向き合い方のような「ふわっとしたもの」の合意事項であり、それを策定した人達自身が、「詳細なプロジェクト戦略で同意しようがない」って言っているので、「これが正しいアジャイル開発の方法です」なんて言った日にはいろんな批判が飛んでくるのではと思います。

某漫画では海○雄○はカレーの真髄を「よいか、カレーの真髄とはなにか！材料に変わったものを使うことか！？豚の代わりに、牛の代わりに、蟹を使うことか！そうではあるまい！」「カレーの真髄はスパイスだ。いかにスパイスと材料を取り合わせるか、それがカレーの真髄だ」「ありふれた材料である豚肉を使って、味と香りを重層的に構築してみせる。これこそがカレーの真髄というものだ」と断言していました。

では、アジャイル開発の真髄とは何なのでしょうか？個人的にはやはり「アジャイルソフトウェア開発宣言」に真正面から取り組めているかどうか、がポイントだと考えています。
その内容は20年以上も経っている現在でも、個人的には古臭さは感じられない内容だなと思います（「青臭い」という人はいるかもしれませんが）。と、いうのもソフトウェア開発というか、モノづくりにおける本質的な部分を突いているからではないでしょうか。

というところで、今回はここまでにしたいと思います。（肝心の「アジャイルソフトウェア開発宣言」と「12の原則」の中身についてほとんど触れてないので、次回（https://base.terrasky.co.jp/articles/jVNHn ）の冒頭にでもその辺りの話をしたいと思います）

また、今回のブログを作成するにあたり参考にした書籍・資料の中で、文中では紹介できなかったものを挙げておきます。

（参考書籍）

（参考Webサイト）
Waterfallを巡る誤解についての記事

追記：

今回のブログを書くにあたり、少し自分の中のモヤモヤ整理したら以下のような感じになりました。
●個人的にAgileの考え方は「好き」である
　⇒　誤解の無いように付け加えると、唯一正しいとか、一番良いとは言っていません
　　（インド式の本場のカレーは好きですが、それが唯一本物で一番美味しいという気はありません）

●自分の中でAgile（な考え方）はあくまでも道具・手段の一つであって、Agileでなければならない、というほどのこだわりはない
　⇒　Waterfallが嫌いだからやらないというわけではありませんし、状況によってはWaterfallの方が向いているという場合もあります。
　　（本場のカレーは選択肢の一つであって、欧風のカレーだって、勿論和風のカレーだってアリです。何ならカレーうどんの場合は出汁で割ります）

●とはいえ、Agileの本質を外した形だけの「アジャイル」で商売することに対して「それはどうなんだ？」という程度の良心・矜持（？）はある
　⇒　予算を引っ張ってくる為だけに「アジャイル」とか「DevOps」とかいう単語を使うのはどうだろう、と。プロジェクトが成功すればまだマシですが。
　　（レトルトカレーに少し市販のスパイス足して、これは本物のカレーだから1万円です、という商売は自分にはできなさそうです。）