最遅着手の原則

平鍋さんが興味深いシリーズを始められた。

また、例えばトヨタで「最遅着手」という原則がある。余裕があれば、ぎりぎりまで着手しない。変更による手戻りが発生したり、在庫をかかえたりするからだ。これは、Agileの「重要な決定をできるだけ遅らせる」ことと良く似ている。ウォーターフォール型のBDUF（Big Design Up Front）開発では、すべてを先読みして大きな分析・設計を決定してしまう。ソフトウェア開発には「やってみないとわからない」ことが多く、またビジネス変化も速いので、このように先行して全体をロック・インしてしまうような「ビッグ・デザイン」は、Agileではご法度。なるべく決定を遅延するのだ。すなわち、できるだけ情報が集まってから、手戻りがおこらないようになった段階で、大きな決定する。そのためには、少しずつ実装して試していく（情報収集する）必要がある。問題解決をしながら問題理解をしていくのがAgileのスタンスだ。かといって、まったく設計しないわけではない。現時点の情報でもっともシンプルな解決を行うこと。そして、これをリファクタリングしながら進化型設計をすること。これが、Agile で ENUF（ENough design Up Front）もしくは、YAGNI(You Aren't Going to Need It)と呼ばれる原則だ。これを続けることで、大きな設計が「現れて(emerge)」くるのだ。

引用中にある「最遅着手の原則」は特に興味深い、というかSI文化圏では切実な問題だ。SI文化の開発プロジェクトのメンバーにとって、手戻りはビジネス変化の速さの結果、ではなく、揺れ動く仕様の所為なのだ。この違いは実は大きい。「ビジネス変化」は、なにかしらポジティブな感じがするけども、「揺れ動く仕様」は実にネガティブだ。
そして、最近実感しているのだけども、経験を積んだチームで繰り返し型の開発プロセスを行っていると、メンバーが自発的に「手戻りの痛みを和らげる」スタイルの開発に取り組み始めるのだ。こうなってしまえば、日々の変化に対する対応はメンバーに任せ、リーダーはスケジュールと、スコープ、成果物の調整を行うだけで良い。これはある意味リーダー視点からみた「変化の抱擁」なのかもしれない。
少々のネガティブさ、というか「痛みの記憶」は、メンバーを少しずつ進化させるので、それほど神経質になりすぎのも良くない。ただ、断続的な、あるいはものすごく大きいネガティブさは現場を疲弊させる。リーダーは、ネガティブさが続いていないか、あるいは大きなネガティブさが発生しそうでないか、に注意を払っていれば良い気がしている。