「アジャイルの現状と未来、次に来るもの。～リーン開発への展望～」Agile Japan 2010基調講演から

アジャイル開発手法として知られるXPやスクラムは、国内で徐々に浸透し始めています。しかしアジャイルをさらに推し進めて企業レベルでアジャイルを活用したり、あるいは企業自身がビジネスをアジャイルに回すためにはどうすればよいのでしょうか。

4月9日と10日の2日間開催されたイベント「Agile Japan 2010」。2日目の基調講演に登壇したAlan Shalloway氏は「アジャイルの現状と未来、次に来るもの。〜リーン開発への展望〜」（What Is Next In the Agile World）と題し、企業をマネジメントする視点からのアジャイルについて講演を行いました。

Shalloway氏の講演は、アジャイルについてよく言われる「プロジェクトではうまくいくが、会社レベルで展開しようとするとうまくいかない」や、「アジャイルのやり方を管理職のレベルでなかなか理解してもらえない」といった課題に対して解決の道筋を与えてくれます。その内容を紹介しましょう。

アジャイル開発には全体のマネジメントがない

ソフトウェア開発のトレンドは何度も行ったり来たりしている。60年代にソフトウェア危機が起きて70年代にソフトウェア工学とウォーターフォールが広まり、80年代はPCの登場と第四世代言語の時代となり、誰もが開発へ参入するようになった。90年代にはY2K問題が起き、しっかりした開発プロセスが求められるようになった。

こうしてみるとマネジメントが硬いもの、ゆるいもの。構造があるもの、あまりないものと繰り返している。

そしていま注目されているアジャイル開発はよいものだが、十分なマネジメントの構造を持たない。その課題をどうやったら解決できるのか、がこの講演のテーマだ。

ソフトウェアビジネスの「バリューストリームマップ」から話を始めよう。ビジネスは顧客から始まり、ビジネススポンサーがニーズをつかみ、開発チームがそれを開発し、顧客に届ける、というバリューストリーム（価値流）からなる。アジャイルはこれを小さな規模で素早く回していくことだといえる。

しかしアジャイル開発には全体のマネジメントがない。それは必要ないわけではない、マネジメントは必要なのだ。

バリューストリームマップを基に、アジャイル開発で人気のあるXPとスクラムについて見ていこう。XPは顧客にフォーカスした方法論であり、マップでみるとこの領域にとどまっている。

スクラムはプラクティス主体の始めやすい開発手法だ。スクラムではマネジメントとチームは切り離されることになっている。スクラムがカバーするのは、この領域だ。

それぞれを見て分かるように、両方ともバリューストリームの中でカバーする領域が限られており、全体のマネジメント構造を備えているものはない。

XPもスクラムもそもそも1つのプロジェクトを成功させることにフォーカスしている。しかし企業というのは1つのプロジェクトではない。アジャイルは非常によいものであり、広まっており、チームでは成功率が高い。しかし企業レベルではうまく適用できていない。

企業が本当に求めているのはビジネスでのアジリティだ。ビジネスのアジリティとは、組織全体で顧客への対応を早くすることである。それは個々のプロジェクトをよくすることだけでなく、組織全体をよくすることも必要である。これは戦略的な視点であり、まだ企業でのアジリティを実現する手法をうまく説明するものはない。

どうすれば企業のアジリティを実現できるだろうか？ ここでは仕事の中の「遅れ」を取り除くという考え方の「リーンシンキング」を用いる。アジャイルになる、価値を素早く提供するというのは、遅れを取り除くという意味なのだ。急いで実行することにはリスクが伴う。そうではなく遅れを取り除き、無駄なく効果的に実行するのだ。

では、何が企業を、組織を遅くしているのだろうか？

リーンの基礎と原則

リーン思考について説明しよう。リーンには基礎や原則がある。

リーンは人を尊重する。言い換えるとすれば、間違いを指摘するときには人の間違いを指摘するのではなく、システムや状態の間違いを指摘するのだ。何か問題があったら人の責任ではなく、そこで働いているシステムの問題と見るのだ。

そしてチームではなくビジネス価値に注目し、バリューストリームを管理する。遅れを取り除くためには、企業レベルではプロダクトの「ポートフォリオマネジメント」を行い、チームレベルでは「カンバン」を用いる。

これがリーンの基礎である。

トヨタはリーン発祥の地として知られているが、トヨタは自動車の製造業であり、われわれはソフトウェア開発者である。そのため、リーンの基礎や原則はトヨタとは切り離して考えよう。そのほうがリーンがより活用できるものとなる。

ここからは、リーンの原則の説明となる。まず「ワーク・イン・プログレス」、つまり仕掛かりを管理すること。何がビジネスの「遅れ」を作りだしているのかに焦点を当ててみよう。

なぜ遅れが発生するかといえば、何かを待っているためだ。あるスタッフやチームが同時に多くの依頼を受け作業をしているときには、（同時に複数のアウトプットを出せるわけではないので）作業が終わるまで依頼者を待たせていることになる。

ソフトウェア開発者が開発をしているとき、プロダクトマネージャや顧客は開発が終わるのを待っていることになる。しかし彼らはもちろん、できるだけ待ちたくない。

この待ちをなくすためにありがちなのは、開発社者に多くの作業をやらせ、生産性を引き上げようとすることだ。それは生産的なことなのだろうか？ かえって作業の減速を引き起こさないか？

そこでマネージャの出番だ。人を忙しく働かせるのがマネジメントではない。効果的に働かせることこそマネジメントなのだ。もしも作業を終わらせるのに非常に時間がかかるのであれば、おそらくたくさんのことをやらせすぎているのだ。もっと短く集中できるようにするべきだ。

これがリーンのエッセンスである。無駄を取り、遅れをなくし、待っている状態をなくすことでバリューストリームを作り出す。

どうやって無駄や遅れを取り除くのか？

ビジネス価値にフォーカスし、無駄を取り、遅れをなくすための方法、それが「プロダクトポートフォリオマネジメント」だ。

プロダクトポートフォリオマネジメントをしなければならないのには2つの理由がある。1つはもっとも重要なものに優先度を置いて開発すること、もう1つはチームが無駄なものを作らないようにすることだ。

リーンは無駄取りを重視するが、しかし本当にしなくてはいけないのは、無用なものを作り出す仕事そのものを作り出さない、ということだ。

例えば、要求、計画、プログラミング、統合テスト、デプロイなどの作業があるとき、途中で要求が変わったり、古い要求のまま作業したりすることは不要な作業の発生源になる。

もしも開発中にバグが発生したら、それはすぐに取り除くべきだ。一週間後では遅いし、その遅れが（途中の仕事をやり直さなければならないといった）新しい仕事や問題を作り出してしまっている。

さて、こうした「遅れ」による問題を起こさないようにするにはどうすればいいだろうか？ 問題提起は簡単だが、実際に行うことは難しい。大事なことは、生産性に注目するのではなくて、遅れを作り出している部分の作業にフォーカスすること。

ある作業を開始したら、それに集中して完成させる、ということ。XPやスクラムでは、プロジェクトレベルでこれを実現している。

しかしそれを企業のレベルで見てみよう。そして、それぞれのチームを遅らせたり減速させてしまうような作業をなくすことが大事だ。それがマネジメントの仕事だ。

それをバリューストリームのマップで見ると、ビジネスの段階で仕事をうまく管理する。すると開発段階での余計な負荷、無駄を未然に取り除くことができる。すると開発チームは1つのことに集中できる。これがとても大事なマネジメントの役割なのだ。

プロダクトポートフォリオマネジメントの実際

さて、プロダクトポートフォリオマネジメントを考える上で、どうやってプロダクトを選ぶのか、それが難しいところだ。

時間と価値のグラフを示そう。1つ目は古典的なパレートグラフ。プロジェクトの初期に多くの価値を提供できる。1つのプロジェクトだけを見れば、こういう形でやりたいものだ。

しかし、いくつかのプロダクトではプロジェクトの初期にはある程度の投資（あるいは多くの作業）が求められるものや、プロジェクトの最後にならないと価値が提供できないものもある。ウォーターフォール型の開発はこうなるが、できればこれは避けたい。

企業全体の視点からすると、短期でも長期でも同じように投資に対して価値を提供できるような、これらの混合を目指すのがバランスのとれたものといえるだろう。では、こうなるように選択するには実際にはどうやればいいのだろうか？

まず、開発すべきビジネスケーパビリティ（≒ビジネス要件）を、ミニマム・マーケッタブル・フィーチャー（顧客にとって意味のある、できるだけ小さな要件に分割した単位）に分割し、それらのリリースプランを立てていく。そしてそれらの中でもっとも重要なものから順番にリリースしていくのだ。

アジャイルとリーンを組み合わせる

まとめに入ろう。この数百年におけるマネジメントのパラダイムを見てみよう。

1800年以前の産業は工芸（Craft）であり、スキルは個人に属していた。1800年代には部品という交換可能なパラダイムが登場し、以前ほどスキルが必要ではなくなった。

1900年代にフォードが組み立てラインを発明し、人が交換可能になった。マネジメントとは人にやることを指図することであり、それで低コスト高品質を効果的に実現できた。

しばらくの間はこのパラダイムが続いて、登場したリーンでは人を尊重する。人はやる気と規律を備えている。ただしそのためには教育も必要である。

この考えがマネジメントを大きく変えた。人にすることを指示するのではなくコーチングとエデュケーションを提供する、これが人の能力を活かすマネジメントであり、方法であり、これがデミング氏が日本の製造業に伝えたことだった。

そしてトヨタはそれをマネジメントの方法として作り上げ、さらに時間の概念を組み込んだ（それがリーンとなった）。

アジャイル開発の世界では、しばしばマネジメントが不要とか閉め出されている印象がないか？ しかし、マネジメントは重要なのだ。何をするべきかを決め、バリューストリームを作ることなのだから。そして途中で発生した障害を取り除き、それぞれのチームがモチベーションの高い状態であるようにするのだ。

リーンとは、ビジネスの段階で遅れの原因を取り除いていく。遅れがなくなればコストも下がる、なぜなら無駄な作業や修正が減るためだ。品質も上がる、多くの問題は無駄や遅延に由来するからだ。

リーンはマネジメントの役割を提供する。コンセプトからはじまったことがプロダクトになるまでの流れを作り出す。リーンが企業全体のフローをつなぎ合わせる。それをXPやスクラムなどのアジャイルと組み合わせると全体がうまくいく。

平鍋健児氏（Agile Japan 2010実行委員長）の補足。

アジャイルの抱えている問題は、もともとデベロッッパーが自分たちの仕事を効率よく顧客に届けるという視点から始まっていた。そのためにアジャイルの言葉は開発者のためのものであり、マネジメントにはうまく伝わらなかった。

アジャイルを企業レベルに展開する場合、アジャイルが対象としているプロジェクトの考えを企業レベルへと押し広げることでマネジメントを変えようとしてもうまくいかない。企業全体のバリューストリームをスムーズにすることの方が大事。その流れをつくるのがマネジメントの役割であり、そのための方法論がリーンなのだ、というのが講演のテーマだった。

会場から質問

無駄取りが重視されていたが、無駄から生まれる創造性といったものもあると思う。無駄取りによって創造性を失う可能性はないのか？

Shalloway氏の回答

「無駄を排除」するのではなく「無駄取り」という表現を使うのは、実はそこに理由がある。無駄を排除してしまったら、価値のあるものまで捨ててしまうかもしれない。だから無駄取りの意味として「遅れをなくす」という言い方を私は好んでいる。「無駄」を定義するのは難しいが「遅れ」を定義するのは簡単だと思う。

リーンからトヨタを切り離そうとしているのもそこに理由がある。製造業の現場では無駄を認識するのは簡単だが、ソフトウェア開発ではそもそも無駄とは何かが分かりにくい。そういうわけで時間で考える方が簡単だと思う。

平鍋氏の補足。

リーンの考え方をソフトウェアに応用しているときに、どうしても製造業からきている言葉をソフトウェアにそのまま当てはめるのは難しいところがある、というのにみんな気付き始めている。なので、ソフトウェア開発ではどういう言い方がいいかというのをみんなで考えているところでもある。

Shalloway氏のプレゼンテーション資料はSlideshareで公開されています。