プロジェクトでプロセスの負債を抱え込んではいけない

仕事の中でプロセスというと、業務プロセスが真っ先に思いつくかもしれませんが、プロジェクトの中でもプロジェクトを円滑にまわすためにプロジェクトの中でルールを決めて、プロジェクトを実行します。

多くのプロジェクトを見ていると、デスマ、炎上しているプロジェクトは、プロジェクトマネージャがプロジェクトの中で適用するルールを決めずに進めていくため、メンバ各自の判断に任せて進めてしまい、顧客とのレビューで指摘されたり、テストなどで不具合が出てから慌ててルールを考えてその対応するための作業量に絶望し、天井を見上げている光景に出くわします。

プロジェクトの標準化は、労働集約型のウォーターフォールのプロジェクトで多く取り入れられるケースが多いですが、アジャイルのプロジェクトでも決めごとはチームで合意しながら作ります。決して、アジャイルなプロジェクトにはルールはなくて、「スペシャルなエンジニアが好き勝手にやっているんでしょ？」と思っているとするならば、「それは違いますよ」、と言います。
＃少なくともワタシは。

プロセスの標準化の目的
プロジェクトでプロセスを標準化する目的は、

“一定の作業品質を確保したいから”

に尽きます。労働集約型のウォーターフォールのプロジェクトでは、兎に角必要なエンジニアを集めて開発させようとするけれど、集められたエンジニアの技量を一人ひとりサーベイなんてやってられないから、「このプロセスでやってよ」とルールを決めて、確保したい品質レベルを文書化したルールで作業を縛るわけです。

なら、アジャイルは？と問われれば、Doneの定義があって、

“作業が終わった状態はどのようなものか”

を作業開始前に全員で決めておきます。例えば、このテーマは、“本番環境にリリースする”というものがあったとき、それだけでは意味がなくて、きちんと、

“どのようなステップを踏んで、その完了状態に遷移していくのか”

を決めておかなければなりませんし、実際、決めています。なぜなら、コーディングしてUTして、いきなり本番環境にリリースなんてありえないですよね。
＃世の中にはあるのかもしれませんが...。

アジャイルでは、やらなければならないステップは踏むけれど、

“管理のための管理のドキュメントや意味のない手続きはやらないよ”

と言っているのだと理解しています。それは、その作業をして顧客がうれしいか、という判断基準があるからです。

意外としないプロセスのテスト
プロジェクトの中でルールなどの標準プロセスを決めるとき、そのルールをした結果とそれに費やしたコスト＝時間でのテスト、つまり、評価をしていないだろう、と思わざるえないことが散見されます。

その上、一度決めたルールがそのプロジェクトの体力に見合わないとか、無駄なステップがあったとしてもそのステップを止めたり簡略化や見直しをするようなことをしなかったりします。

すべては、忙しいからと言い訳を聞くことが多いですが、プロセスの見直しに掛かるコストと、これから継続するコストを量れば、どちらをすべきかは誰が見ても判然とするものです。
＃プロセスだってリファクタリングしなさい、ということです。

それより、問題が起きてから見直すよりも、ルールを決めたときに実演して問題点がないことを発見するタイミングを設けるか、少しの間トライアルして問題点を修正することを設けるようにした方が、

“プロセスから生み出されるムダな時間と費用の浪費を抑えられる”

という効果を手にする選択をしたほうがよいです。
ワタシはよく、

“プロセスの負債を抱え込むな。”

と言います。
誰もうれしくないことをすることは、させたくないからです。