「プロジェクトが成功するためならなんでもする」と考えておけば十分か

まあ、大人げないと思いつつ。いろいろ考えるのですよ。

「プロジェクトが成功するためならなんでもする」

まあ聞いたことがあるよねこの言葉。SIer にいたころに協力会社の営業から。できれば頼みたくない会社だったりするんだが、そういうところに限って見積が安かったりするんだな。

で、トラブルになっても何もしない。唯一やってくれるのは、「人が足りないんですか？職務経歴書お送りしますよ。」だ。

あうち。

ソフトウェアにアーキテクチャがあるように、プロセスにもアーキテクチャがある。変わりにくいものと変わりやすいことを読むのが本質だ。

ソフトウェア開発において、みんなどこでも「なんでもやりますよ」をやるとどうなるかはみんな知っているだろう。大きな泥だんご(Big Ball of Mud)っていうやつだ。結局何もできなくなるまで、無駄を生み続ける。

プロセスも一緒で、どこのプロセスでも「なんでもやりますよ」をやると、小学生のサッカーみたいになる。見たことあるでしょ、流行のバズワードのプラクティスは全部やってるように見えて、実際には何も役に立っていないような現場を(テストカバレッジが100%だけど、アサーションが一行もないとか)。

私は、

無駄とわかっていることを、さらに続けることを無駄という
改善とは、成果の量と品質と保ちつつ、やることを減らすことである

という立場だ。

でも、どうやって無駄を認識して、取り除いていくか？また、より良いプロセスを試行するか。それを変えにくい(依存しやすい)プロセスとして入れておく必要があるだろう。

プロセスが生み出した結果(プロダクト)とプロセスを定期的にふりかえり、やめること、次に試すことを決めることだ。スクラムだと、スプリントレビューとレトロスペクティブを必ず固定のタイムボックスにいれるというところだな。「なんでもやる」という姿勢を続けるための安定した基盤としては、今のところ有効なメタプロセスであると自身では思っている。

ただ、そこで止まっているわけではないよ。最近名前を聞くようになってきた、Kanban というプロセスでは(ところで日本語訳はまだ出ないのかなぁ？)、タイムボックスが改善の妨げになると主張している。バッチを小さくするのに飽き足らずフローでの開発に取り組むという野心的な取り組みだ。うまくいく例、いかない例が報告され、だんだん知見が蓄積されていくのではないかな。楽しみだ。

P.S.

うーん、でも職業アジャイラーって何だろう？