TPS と Agile(1)　- Process と Meta-process, 遅延着手とENUF

昨年は、トヨタの方やトヨタ生産方式のコンサルタントの方（松井順一さん）と話す機会があり、とても刺激になった。松井さんが出された本、『職場の「カンバン方式」～トヨタ流改善術ストア管理』や、Mary Poppendieck の新刊、『Implementing Lean Software Development』を読みながら、再度、トヨタ生産方式とアジャイル開発について考えて行くことが、今年の一つの僕の活動になりそうな予感がしている。

というわけで、「TPSとAgile」を開始します（不定期です）。

最初にことわっておきたいが、TPS（トヨタ生産方式）は生産に関する考え方であり、ソフトウェアのような開発活動にそのまま適用できる訳ではない。「生産」と「開発」は異なる活動であり、実際の実践項目（プラクティス）のレベルでは全く違うものだ。しかし、考え方の部分では、非常に共通するものがある。アジャイルでいう原則と価値、TPSでいう原理原則の領域は、同じことやものを別の名前で指している例が本当に多い。

プロセスとメタプロセスの同居

まず、「ものを作る(making products)」ことの中に、「ものをよりよく作る(making products better)」という視点が盛り込まれており、この２つを同時に行うという点が、TPSとAgileが共通している原点だと思う。これは、「カイゼン」であり、アジャイルが繰り返しを重視し、繰り返しごとに「ふりかえり」を行う理由である。

2. 先行してやらない

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

（このシリーズ、つづく…はず。反響があれば…、求む、フィードバック！）