TPS でいう 5S とは、「整理」、「整頓」、「清掃」、「清潔」、「躾」を言う。これは、ソフトウェア開発ではほとんど関係ない－－と考えている人が多い。しかし逆で、アジャイルのような持続可能な開発では非常に重要になる。

この５Sは、しっかり英語にもなっており（いくつか文献によってばらつきがあるが)、Maryの本では、Sort, Systemize, Shine, Standardize, Sustain である。要不要を区別し(Sort)、見つけやすく場所を移動し(Systemize)、いつでも使える状態に磨き(Shine)、誰でもわかるようにし(Standardize)、それをキープするルールを作る(Sustain)。

Kent Schnaith がより具体的にこの5Sを、ソフトウェア開発で例示したものを、Mary Poppendieck は本の中で紹介している。

1. 整理(Sort)

コードの中で、通過しない死んだコードや、不要な import 文、使われていない変数、使われていないクラス、メソッド、アトリビュートを削除。整理する。

2. 整頓(Systemize)

プロジェクトのパッケージ構造を見直す。相互参照や循環参照を取り除いたり、依存関係を最小にする。

3. 清掃(Shine)

プロジェクトの掃除をする。

テストケースのエラーをなくす、ユニットテストのカバレッジを上げる、AllTests のパフォーマンスを上げる、checkstyle の警告をなくす、PMD の警告をなくす、javadoc の警告をなくす、…などなど。

4. 清潔(Standardize)

きれいな状態になったら、それをキープする。プロジェクトの複雑性を上げないよう、監視する。

5. 躾(Sustain)

これをプラクティス（実践項目）として、チームのルールにする。

文献によっては、Sift, Sort, Shine, Standardize, Sustain となっているものもある（この方がぼくはよいと思う）。

昨年は、トヨタの方やトヨタ生産方式のコンサルタントの方（松井順一さん）と話す機会があり、とても刺激になった。松井さんが出された本、『職場の「カンバン方式」～トヨタ流改善術ストア管理』や、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)」くるのだ。

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