アジャイルがうまくいかなくなる魔法の言葉があると思います。「いい所を組み合わせれば」この言葉が出てくると、私は、あぁこのプロジェクトはアジャイル崩れになって、失敗するだろうな、と思います。
良いとこどり、ができると思って皆、悪いところどりをして、結果としてウォーターフォールでもアジャイルでもない、ただのグダグダ、素人が初めて開発やってみました、みたいな失敗プロジェクトになってしまうのです。
PMBOKの勉強をした人なら誰もが感じるのは、開発手法というのはとてもたくさんの要素のバランスで保たれるということです。PMBOKなら様々なドキュメントが定義されています。例えば、開発する範囲、スコープも、それを完成させるために必要なタスクの一覧も、バグの一覧も。設計書だけでなくそういったドキュメントが管理されていることでPMBOKでの開発がうまくいきます。そしてそのドキュメントはファイルである必要はありません。Azure DevOpsやGitHubなどのサービスを利用してできるだけ省力化して実現します。それでもこれはとても大変なことです。
これらのドキュメントはそれぞれ欠かすことができない理由があって、用意されます。なければ、どんな失敗につながるか？PMBOKの教科書にしっかり書かれています。それでも、多くのプロジェクトでこれらの管理、特に日々の更新、最新化がおろそかになって痛い目にあうものです。規模の大きなプロジェクトになると、これらの管理の工数だけでも膨大になり、専門の人員が配置されることもあります。
そこまで重要なものを、手間がかかるからと、はい、辞めてしまえるでしょうか？そんなわけがありません。アジャイルがPMBOKの従来のドキュメントをやめてしまえるとしたら、代わりに、それがないときに問題になるはずのことを問題にならないようにしている別の仕組み、要素、があるはずです。それはたとえば、ウォーターフォールのときには自由に決められていた何かのタイミングを、自由に決められなくなることかもしれません。アジャイルのスクラムでは、定期的にやらなければならないことが定められています。そしてそれは以前のウォーターフォールでは特にきめられていなかったことです。
そんな、同じ課題を解決するために、あるいは起こさないために、必要とされる全く違う要素を、それぞれ、全然違う開発手法からうまくいいとこどりできますか？
たいてい、ドキュメントは書きたくないしタイミングも守りたくないから両方省略すれば、きっと素晴らしい開発ができるよね、と、失敗へ突き進むことになります。
なぜ、良いとこどりしなければならなくなるか？と思い返せばきっと、それは、アジャイルありき、だからだと思います。必要に迫られて、アジャイルを採用するのなら、もうすでに痛い目にあっていて、それを変えたいからアジャイルになったはずです。そうではなくて、変えたくないけど、アジャイルにしなければならないから、では、良いとこどりしたくもなります。しかし、良いとこどりが決ってしまった現場は地獄です。新しいアジャイルもできず、元のやり方にも戻れず、何かというと良いとこどりの名の下に、やるべきことをやらせてもらえなくなる。あるいは、適切な契約ができず、ステークホルダーとの関係も築けていないのに、合意したつもり、了承を得たつもりで時間が過ぎてみたら、実は何も決まっていなかったり。
やるなら本気でちゃんとやりましょう、アジャイルでも、そうでなくても、最適な契約形態、最適な開発手法を選んで。本当に。
コメント
