アジャイル開発の現在・過去・未来

2010年9月6日

9月4日土曜日に、有志によるアジャイル開発のイベント「XP祭り2010」が早稲田大学西早稲田キャンパスで開催されました。イベントは200名以上の参加者が集まる盛況となり、アジャイル開発への注目の高さをうかがわせました。

基調講演では、「アジャイル開発の現在・過去・未来」というタイトルで、アジャイルの第一人者であるチェンジビジョン代表取締役社長の平鍋健児氏が登場。タイトル通り、アジャイル開発の全体と最新動向を俯瞰する、アジャイル開発のイベントでしか聞けない充実した内容となっています。

この記事では、その基調講演の内容を紹介しましょう。

なぜアジャイルが注目されるようになったのか

なぜいまアジャイルが注目されるようになったのか？

何かのビジネスを行う際には、企業が市場を分析して、企画を立て、IT関連のシステムを発注する、といったことが行われる。すると、ITが「仕様通りにできました」と納品してくる。これが期間にして半年とか3年とか、そんな期間で回っていると。

ところがこれには問題があって、ITの人は発注書に書かれている仕様通りに作ればいいと思っていて、ビジネス上のリスクはとらず、開発のリスクだけをとろうとしている。「それは仕様書には書かれていません」とか。

ところが仕様書通りに作っても時間が経つとビジネス環境が変わっていくので要求が劣化していくんですね。そのリスクをビジネス部門がとれればいいのだけど、もうとれなくなってきてる。

そこで、ちょっと市場があればそれに合わせてITで何かを作ってみて、市場に出してみる。うまくいったら強化していき、だめなら撤退する。こんなビジネスとITが一体となったビジネスが多くなってきた。

アジャイルが注目され始めたのは、こんな風にビジネスがアジャイルを求めることがここにきて強くなってきたからだと思う。

アジャイルには、変化に対応する仕組みがもともと組み込まれている。アジャイルに相当するものは、以前は「ライトウェイトプロセス」などと呼ばれていたけれど、2001年に関係する人たちがみんなで集まって「アジャイル」という名称に決めた（Manifesto for Agile Software Development）。

実は名前の候補には「Business Aligned（ビジネスアラインド）」、つまりビジネスと一体化する、というものもあったという。

あえていえば、要求仕様がぴたっと決まって動かないのなら、ウォーターフォールで作った方がいいといってもいい。アジャイルは要求が動いているときの開発手法といえるし、あるいは要求とはもともと動いているのだともいえる。

プロセスとしてのアジャイルは、短いサイクルで分析、設計、実装、テストを並列に行うもの。

こういうことができるようになったのは、統合開発環境（IDE）がよくなってきて開発しやすくなったり、CPUやストレージが安くなって自由に使えるようになり、いつでも開発ができるようになったという要因もある。

アジャイルの現在

アジャイル開発にいちばん影響を与えているのはスクラム（SCRUM）、そしてeXtreme Programming（XP）。どちらもはじまったのは90年代の頃。日本ではXPが脚光を浴びて、そのあとスクラムがきた。

XPは、そのeXtreme Programmingという名前がキャッチーだったと思う。一方でeXtreme Programmingが曲芸、すごいプログラミングと思われて、開発者のための手法と思われてしまい、マネージャまで巻き込んだ採用になかなか至らなかった。

SCRUMはスクラムマスター認定制度を作ったのが普及にとって大きな要因となった。アジャイルがキャズムを超えた、というのはSCRUMがキャズムを超えたといってもよく、それにはスクラムマスター認定制度が大きかったと思う。

この会場でスクラムマスターはいますか？（10人くらい手が挙がる）

アジャイルは、実は本を読んで理解するのがとても難しい。現場ごとにコンテキストがあるので、そのコンテキストの中で自分たちで解を作っていなくてはいけないから。問題に対する向き合い方は、経験者と一緒に問題を解いていくことでしか身につかない。スクラムマスターは徒弟制度があったりして、人づてにアジャイルが伝わっていったというのがあると思う。

さて、もう1つアジャイルに影響を与えたのがリーン。「リーンソフトウェア開発」という本がありますが、日本ではTPS（Toyota Production System、トヨタ生産方式）といった方が通りがよいかも（参考：「アジャイルの現状と未来、次に来るもの。～リーン開発への展望～」Agile Japan 2010基調講演から）。

リーンは顧客の価値の流れを現場の人が作っていく、それをソフトウェア開発に適用するとアジャイルになるんだ、という考え。

ブリティッシュテレコムでアジャイルを推進している人が言うには、アジャイルを理解してもらうには、経営者にはメアリー（メアリー・ポッペンディーク氏、「リーンソフトウェア開発」の著者）の本を、プロジェクトマネージャにはSCRUMの本を、開発社にはケント・ベック（「eXtreme Programming」の著者）の本を渡すと、みんな「これだ！」というらしい（笑）

TPSに影響を与えた人としてデミング博士がいる。アメリカがデミング博士の業績を発見したのが1980年代以降。それ以前（1950年代）から日本ではデミング博士の技法を適用しており、それが日本の製造業の強さを作ったといわれる。リーンにはそれが流れ込んでいるといわれている。

XPの源流はもともとパターンにある。最初にソフトウェアにパターンを持ち込んだのが、ケント・ベックとウォード・カニンガム。GUIの構築やソフトウェア開発にパターンを持ち込んだ。

スクラムにパターンを持ち込もうという動きも最近ある。

最近の話題としては、アジャイルを大規模に適用すること、組織全体でアジャイルに適合していくにはどうするか。それからリーンアジャイル、そしてアジャイルUX（User eXperience）。

それから、アジャイルから「かんばん（Kanban）」というムーブメントがスピンオフしていて、ポストアジャイル、ポストスクラムという感じになっている。

日本国内でのアジャイル、ブレイクスルーへの期待

日本でのアジャイルについて。日本でアジャイルをやるのは難しい面がある。

日本には「SIer」という謎のビジネスがありまして（笑）、まあうちもSIerなのですが、日本だとユーザー企業に情報部門があって、それがSIerに発注して、そこから外注に出してと、ビジネスの成功がITの成功であるという中で、こんな長いものをどうやって統一するのかと。そういう契約の部分が（難しさの）大きいところかなと思う。

それでも独立行政法人情報処理推進機構（IPA）に「非ウォーターフォール研究会」というのができて、そこにでて日本でのアジャイルについて研究している。そこには日本のSIerの人も出てきていて、みんな言っていることは一緒。「顧客満足が高く」「現場が生き生きと」したものにしよう、というのは合意している。そういう方向には進んでいるので、何かブレイクスルーがあるのではないかなと思っている（参考：日本のアジャイルは海外と比べると周回遅れか、アジャイル開発が国内で普及するには？ IPAの報告書から）。

かんばんとSCRUMとウォーターフォールの違い

「かんばん」は、アジャイルからのスピンオフで、デビッド・アンダーソンという人が中心になっている（参考：最近盛り上がってきた「かんばん」、ソフトウェア開発における「かんばん」（Kanban）とは何か）。

アンダーソン氏は、アジャイルとCMMIとの整合性や、リーンの考え方を取り入れたり、「Kanban」という本も書いている。

ヘンリック・ナイバーグ（Henrik Kniberg）氏は、最初「かんばんvsスクラム」と書いたらバッシングにあって（笑）、「かんばん＆スクラム」に変えた。

かんばんは価値のかたまりをどう流していくか。タスクにブレイクダウンするのではなく、ユーザーにとって意味を持つ最小単位「ミニマム・マーケティング・フィーチャー」（Minimum Marketing Feature、MMF）にする。この単位だとユーザーにまで（価値のかたまりを）流せる。

つまり「この画面」だけではユーザーにとって意味を持たないけれど「この画面とこの画面でこう動きます」というユーザーにとって意味を持つ単位で、これをカードなどに書いて見える化して流していく。こう流していくのを「かんばん」と言っている（参考：最近盛り上がってきた「かんばん」、ソフトウェア開発における「かんばん」（Kanban）とは何か）。

この図がウォーターフォールとSCRUMとかんばんを比べたもの。ウォーターフォールだと、分析、設計、実装、テストと次々に流れていく。SCRUMだと、期間を区切ってタイムボックスを繰り返す。かんばんはMMF単位でイテレーションはない。作ったものが1つずつ左から入って右に流れていく。

このウォーターフォール、SCRUM、かんばんが、どれも終わり（納期）が一緒だとすれば、スループットは一緒。ある時間たつと完成する。

このとき、納期が1年で完成すべき要求が365あるとする。

ウォーターフォールは、分析、設計、実装、テストと、春夏秋冬で実行していって365日後に全部がいっぺんに完成する。

SCRUMでは、1カ月で30個ずつ作るとなる。

かんばんでは、これが1日1個、できたものから（顧客に）流していこうよとなる。

これをWork in Progress（仕掛かり、WIP）で見たときに、WIPはどれだけあるか？

かんばんはつねにWIPは1個。SCRUMは30個、ウォーターフォールはこれだけ（365個全部）あるんです。これだけあると、ビジネスに変化があって要求が変わったときに、どれだけ手戻るんだ、という話。

このように、ある時間で切ったときに、仕掛かり、WIPを減らすのが重要。なぜか、これを減らすとリードタイム、サイクルタイムが減る。要求が形として分かってから、顧客に届くまでの時間が減るから。

かんばんはリードタイム1日を実現できる。スクラムは1カ月、ウォーターフォールは1年。

えー、残り時間があと8分ですか。でもまだ3分の1くらいしか終わってないですけど（笑）

XPとは何か？

アジャイルからSCRUMを引いたら何が残るだろう？

TDD（Test Driven Development、テスト指向開発）、リファクタリング、継続的インテグレーションなどが残るかもしれないけれど、クラフトマンシップも残ると強く思う。スキルを持ってない人を集めてSCRUMしても絶対にうまくいかない。

アジャイルソフトウェア宣言がある。プロセスやツール、ドキュメント、契約交渉など（左に書かれたもの）よりも、対話、動くソフトウェア、協調、変化への対応（右に書かれたもの）に価値を置く（参考：「アジャイルソフトウェア開発宣言」公式日本語版が公開）。

これに刺激されたものとしてソフトウェアクラフトマンシップ宣言、というのもある。動くソフトウェア、変化への対応、対話など（左に書かれたもの）だけではなく、Well-Crafted、よりよく作られたソフトウェア、着実に価値を加えていくこと、プロフェッショナルのコミュニティといったこと（右に書かれたもの）が大事だとある。