だいぶ減ったとは思いつつ、アジャイルでやって大きな失敗にならないようにするためにも、自分的なメモを記しておきます。
そもそも、アジャイルとはなんなのか？
いきなり、おおもとのここから入ります。
アジャイルソフトウェア開発宣言を読んでほしいのですが、アジャイルって開発メソッドというわけでもないと思っています。
どちらかというと、文化や概念の話で、その文化を醸成するためのメソッドがいろいろと公開されていて、日々進化をしている状況。開発メソッドとしてだけとらえるよりも、組織文化など大きな概念に迫る話がアジャイルなんですね。
結構有名な文章として、以下の文章があります。
このマイナーなページにたどり着いた人は、もしかしたら見たことあるかもしれません。
プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を、
よく引用されているここだけをみて、「ドキュメントを作らない」とか「計画がいらない」とかの話をする人もいるのですが、そんなことは全くなく。
価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。
こう続きます。左の事柄の価値がないなんていっていなくて、価値があることを認めつつ、より価値があることは右の事柄だ、といっているんです。このあたり、しっかり理解しないと、前述のように、「ドキュメントを作らない」とかの話になってきます。
同様に、スケジュールはいくらでも遅らせてよいというのも違うし、仕様変更はいくらでもできるというのも違う。
そういった勘違いを最初に補正しつつ、クライアントに言われたときの話をしていきます。
クライアントからアジャイルでやってくださいと言われたら
最初に意図を確認する
当たり前なんですけど、「なぜ、アジャイル開発を望んでいるのか」の意図を確認するのが最初です。
- アジャイルがなんかいけている開発方法と聞いたから
- アジャイルでやると、いくらでも仕様変更できるから
- まだ要件が決まっていないから、アジャイルじゃないとできないから
- 全社的にアジャイル導入を進めていて、その方針に従わなければいけないから
- 早く完成形を見て、フィードバックしたいから
- 期間を短くできると聞いたから
- 費用を安く抑えられると聞いたから
こんなこという人はほとんどいないかもですが、なんとなく思いつくことをざらっと並べてみました。よくあるQAとかにもあるやつですね。
クライアントがアジャイルを誤認しているのか、本気で導入したいのか、それとも別の事情か、などによってこのあとの対応パターンは異なります。
パターン１：クライアントが理解していない場合
クライアントが何かでアジャイルを聞いて、良いことづくめのものとして理解しているケースですね。他のプロジェクトでうまくいってたり、なにかのセミナーで聞いたり、そういうこともあるかもしれないですね。
こういうケースは「アジャイルの良い点、悪い点を正しく理解してもらう」につきますね。正しい理解ってなんだ、とかいろいろあるんですけど。
「なんかいけている開発方法」というのは、あながち間違いでもないんですよ。クライアントが期待しているのは、中長期にわたりアジャイル開発を継続して圧倒的な生産性を誇るスーパーアジャイルチームがいきなり提供されることとか、自分たちがアジャイルを何も知らなくてもよいアジャイルチームになるとか、そういう話のことがほとんど。
そんな都合の良いことはなく、成熟していないアジャイルチームの生産性は、ウォーターフォールに劣ります。品質面でもおそらく劣るし、全体的に拙い感じになるはず。
ただ、その取り組みを続けていき、すごく強いチームになったときは、期待しているところに行きつきます。そういう話を理解することが大事ではないかな、と。
「いくらでも仕様変更可能」は、「やろうと思えばできるけど、その分全体で実現できる機能の総量は減る」とか「要員追加して予算も追加して対応」とか、そういうことを理解してもらわなければいけない。
「早く完成形を見たい」は、別にアジャイルではなくても実現できる。プロトタイプモデルで進めれば、成果物イメージは早々に見て、どこをどう掘り下げるかとかを考えていける。だったら、対案としてプロトタイプモデルでやりませんか、と言える。
パターン２：経験ないけど導入したい場合
クライアントが経験ないけど、導入しなければいけない何かしらの理由があり、導入前提で物事が動いている場合。これ、なかなか厄介なんですけど、相応に準備しないと大やけどするケースかな、と。
自社に経験がありばっちりなら、教えることも含めてプロジェクトとして取り組めばよいです。それですべては解決する。
問題は、自社に十分な知見がない場合。この場合、それとなくアジャイルではじめると、大きな事故につながり、いわゆる炎上案件化する可能性が高いです。
クライアントも、自社も含めて、一度しっかり概念から学ぶべきです。アジャイルコーチとか、セミナーをやっている会社もたくさんあるので、クライアントと一緒に受ける。できれば同じ会社のセミナーを受けて、考え方をそろえておく。
プロジェクト開始タイミングでは、アジャイルコーチという形で、伴走してくれる専門家を起き、軌道にのるまで支援をしてもらう。
そういうところまでやって、はじめて、アジャイルの一歩目を踏み出せると思います。
パターン３：予算や期間の圧縮のために切り出している場合
これはもう、論点が違いますよね。
予算や期間圧縮のために、アジャイルを指定されたのであれば、パターン１と一緒で、正しく理解してもらえばよいです。
そもそも、予算や期間があって、それを合わせたいというのはクライアントから正当な要望なので、それをアジャイルという隠れ蓑で包み隠すべきではない。普通に、「予算や期間がはまらないから、こうしてほしい」というオーダーを出させるべきで、それが出てこない場合は、引き出す努力をすべき。
聞き出したら、手段を考えることができるので、そこで初めてアジャイルでもウォーターフォールでも、スコープの調整でも、品質の調整でも、なんでも調整かけていけばよい。
終わりに
いろいろ書いてしまいましたが、いいたいのは、幸せなアジャイルしようぜ！ということ。アジャイルがうまくいき、成熟したチームができ、クライアントと一緒にビジネスの成長を考えていけるチームができたら、それに越したことはありません。
アジャイル開発がうまくいく事例は、まだまだ事業会社のことが多いですが、受託でもうまくいくケースが増えることを願っています。