道具を適切に使おう！〜何でもアジャイルで考えてしまう罠について〜

先日、AgileJapan2011でアジャイルの組織導入について講演をしてきた。Twitter等で感想を見て驚いた事の一つに私のアジャイルの組織導入のやり方がウォータフォール型という意見が多かった事です。この意見に私はなんとなく違和感を感じました。そのことについて考えてみます。

ウォータフォールと呼ばれる理由

　ウォータフォールは、ルイスさんって人が考えたソフトウェア開発アプローチがありました。そのアプローチは、現在のウォータフォールの元になっている考え方です。

http://leadinganswers.typepad.com/leading_answers/files/original_waterfall_paper_winston_royce.pdf　←これウォータフォールの元の論文です。

　現在のシーケンシャルな考え方の他に、フィードバックや、繰り返しの考え方が当初から盛り込まれていたものです。この考え方のうち、「フィードバック」や「繰り返し」の考え方がカットされて米国国防省に広がったソフトウェア開発の手順がいつしか「ウォータフォール」と呼ばれるようになったものです。基本的に「要求」「設計」「製造」「テスト」のように順番にフェースをもうけて実施するソフトウェア開発の考え方で、できるだけ後戻りが無いように上流工程をしっかりやろうという考え方です。

　
　私のスライドを振り返ると、アジャイルの導入ステップを１〜５ステップで手順を追って説明しているものです。これは、私の組織導入のやり方を人に説明するにあたり、こういう順番でやりますよと単に説明したものです。ですでの、これは、別にソフトウェア開発でもなく、要求、設計、製造、テスト等の工程がありません。しかし、この説明方法がウォータフォールと何人かの人に思われたということは恐らく、「計画的で、手順があるもの＝ウォータフォール」「変化に対応する、繰り返し型のもの＝アジャイル」という捉え方がある気がします。

アジャイルコンサルタントの秘密

View more presentations from Tsuyoshi Ushio

　私のスライドで説明した内容は、計画的で手順があるのでウォータフォール的アプローチととらえられた感じなのだなと思いました。

道具を適切に使うこと

　
　私が違和感を感じた理由を考えてみると、このウォータフォールという言われ方の背景には、「アジャイル」が良いものであり、「ウォータフォール」というものは悪であるというムードがあることは否めないということを感じました。私も基本的に現在のソフトウェア開発には少なくともアジャイル的なアプローチの考えを導入したほうが上手く行きやすいと考えています。ソフトウェア開発にはという部分がポイントです。同時に現場では、ガントチャートや、Excelが悪と見なされる傾向がありますが、私はこの空気が好きではありません。私は計画的なアプローチも、手順的な説明アプローチも、ガントチャートも、Excelもみんな素晴らしいツールだと考えています。ただし、道具は適切につかわないと効果がでない。とただそれだけのことだと思います。道具にいいも悪いもなくて、単に使うシチュエーションが悪いだけで、ウォータフォールも、アジャイルもええも悪いもないと思うのです。単に適切な場所で使われていないだけと思います。
　それをアジャイル＝良いもの、ウォータフォール、手順的なアプローチ、Excel、ガントチャートは悪というのはなんか気持ち悪いと思うのです。ちなみに、今回のアジャイル組織導入の方法は、プロジェクトマネジメントの考え方、要求開発の考え方、そしてアジャイルの特性を考えて作り出したものです。道具は単に道具でしか無く、そこに良いも悪いもなく、それを使ってどうするか考えて、やりたいことが上手く実現することが本当に大切なことだと思うからです。

道具を適切に使わない例

　例えば、私も大好きなアジャイル的なアプローチですが、それが適切に使われない例を考えてみましょう。例えば、何かの技術を学ぶためのチュートリアルはどうでしょう？例えばアマゾンのクラウドを試せるようなセットアッップの手順とかです。普通は、やり方が決まっていて、手順的です。まさにウォータフォール的なものではないでしょうか？もし、これがアジャイル的なアプローチ（注１）だったとすると、「Javaのランタイムをインストールする」「EC2のインスタンスを起動する」「秘密鍵を転送する」とかいろいろなストーリがが存在して優先順位づけされていて、初めてそれに触れる人がその中身を「自分で考えて」実行してくださいとだけチュートリアルに書いてあるということになります。いや、もしかすると、そのストーリは依存関係があり個々のストーリでは価値がでないため、「EC2を試してみる」という１つのストーリになってて、タスクは皆さんで出してくださいとだけ書かれるという事になるかもしれません。これは相当暗黒なことです。

　逆にウォータフォールがなぜ適切じゃない場面が増えてきたか？というと、現在の技術では、実際にものを作ってみないとわからないということがあまりに多いので、「製造、設計、テスト」そして「要求」を行き来しながらソフトウェアを作るということが適切な場合が圧倒的に多くなっているからです。アジャイルの伝道師の方がソフトウェア開発の文脈で使われるガントチャートを否定するのは、先を予想しにくい現在のソフトウェア開発で、タスクをあらかじめ出し切る事は難しく、それを予見して細かくガントチャートを作っても、変更や漏れが多くなるため、作業が効率的に進まず、変更の手間も増えるから効率的ではないためです。

道具が適切に使われた例

　逆に、計画的で手順的なアプローチが良い例を示してみましょう。先のチュートリアルはもちろんですが、あらかじめ物事の見通しが立てやすいものは、多少の変更はあるにせよ計画的なアプローチが有効です。また、こういったアプローチのいいところは他の人に「分かりやすいし「安心できる」ということがあります。例えば東電さんが、「原発の件は見通しが立たないため、２週間毎に計画を見直して振り返りを行います。」「リリース日は2050年の予定です」「ストーリは、放射能放出をストップする、石棺を作成する、自然エネルギーを開発する」という優先順位で実施します。と言ったとしたらどんな気分になるでしょう？そういう場合は、計画の変更は多少あるにしても、専門家を集めて、こういう計画でやります、予算はこの程度の見込みです、こういうリスクが起こったらこんな対処をするとか、どういう体制でやるとか、どういうタイミングで報告するとか、あらかじめ決めておいてやってもらう方が嬉しくないですか？私は少なくとも嬉しいし、安心しやすいです。

　余談ですが私が大手SIerにいた頃、私が見ていた中では、失敗したのを見た事がないウォータフォールを使うマネージャの方がいました。彼は技術を深く知っており、予見できる能力が高いので適切なスケジューリングをしており、チームはとても快適でした。ガントチャートはもちろん作っていますが、細かすぎず適切で、メンバーの人にまかすところはまかせていました。そして豊富な経験でソフトウェア開発で起こりうることをリスク対策していましたので、問題が発生してもスムーズに対応していました。このように、予見的なアプローチが使えるときは使った方がスムーズにいくと思います。そうでないとき、予見が出来ないときは、違うアプローチの方が適切でしょう。予見できるところは、予見的なアプローチ、そうでないところは適応的なアプローチという考えも可能でしょう。すべて、状況によると思うのです。要はその現場で上手くいけばいいのですから。

　ガントチャートも、時系列のアクティビティを表現するためにはとても適切な分かりやすいツールです。ざっくりとした全体のスケジュールを表現するのに使ったりするとあまり変更は入らないし、わかりやすいです。また平行して行われるアクティビティも表現しやすいです。先が読めないものを細かく書きすぎるから、大変で無駄がありむちゃくちゃになるだけです。適切に使えば、全体でどんなことが行われるのかが時系列で把握しやすいので、とてもいいツールになり得ます。円グラフ、バーチャート等、いろんなチャートは、ある目的を達成するためには適切ですが、他の事に対してはそうではありません。余談ですが、人に伝えるという目的でいうと、テレビでどういう時に、どういうチャートが使われるかというのはとても参考になります。

　もちろん、ソフトウェア開発の部分にはアジャイルや、そのアプローチを部分的にでも導入したほうが今のソフトゥエア開発には大部分のソフトウェア開発に向いていると思います。そうでないケースをあげると、人の生死に関わるようなシステムの開発でしょうか？

　またアジャイル組織導入という文脈で考えると、ソフトウェア開発チームが「アジャイル」になるためには、いろんな準備をしておいて計画的に行く方が上手く行く体験をしていますし、何回も経験しているので、予見的なアプローチもある程度採りやすいです。そのノウハウを皆さんに伝えるためには手順的なアプローチの方が分かりやすいのでは？と考えてあのようなスタイルにしました。

まとめ

　私の言いたかった事は、道具に善悪はなく、それに適した状況があるだけといこと。それを上手くうかうかどうかは、現場の皆さんにかかっていて、皆さんの現場を上手く行かせるために、考えて、複数の道具を適切に使っていくことが重要だと考えます。

　また、私の偏った意見ですが、アジャイル導入という文脈で考えると、例えばあなたが今やっているやり方を「それは悪だ」とか「間違ってる」と否定されて、その人の言う事を聞くでしょうか？相手を理解することに加えて道具に善悪をつけないことも重要じゃないでしょうか？その道具の適切な使い方や、どういう状況で上手く行くか？を知る事によってプロジェクトにかかわるみんながハッピーになると私は嬉しいです。

補足

　私は他のことに「アジャイルの考え方を応用すること」を否定しているわけではありません。実際にポモドーロテクニック等もそうですがいろいろ使える場面は多くあります。ただ、アジャイルの考え「だけ」にとらわれるともったいないんじゃないかな？と思います。

追記 2011/4/23 13:22

注１：補足です。私はこの記事で「ウォータフォール的」「アジャイル的」という言葉を使っていますが、実際はアジャイル開発でも計画的アプローチも入っています。この記事の文脈では、手順的な説明を見て「ウォータフォール的」だという反応があったため、その対比として,その考えだとすると、「アジャイル的」というのはこんな感じじゃないか？という意味で「アジャイル的」と記述しています。