トヨタ生産方式(参考記事リンク)の構成要素の一つに、標準化という考え方がある。Kanban Development(リンク)のリストに寄せられた最近の投稿(リンク)に、トヨタ生産方式とリーン生産方式がソフトウェア プロジェクトに適用された場合、この考え方は引き継がれるのかといった質問があった。これに対し回答者たちは、ソフトウェア開発は実際には製造業でないにもかかわらず、開発に「標準化」という考え方を適用することに価値を見出した。
Norman Bodek氏(リンク)は、「Standardized Work - Toyota's Powerful Improvement Process（リンク）」において、トヨタで実施されている標準化を見て次のように述べた。
私は、ゴムホースの上にノズルを置いている現場の女性に気付きました。彼女の前には、厚さ約1インチ、2フィート四方の木製のかんばんがありました。その木製のかんばんには、完成したホースの部品とエラーで変形したホースのサンプルが添えられていました。また、そこには彼女が品質の耐性のチェックを行い、発見した問題およびプロセスを改善するための意見を書き込むスペースもありました。
Kanban Developmentのリストで、初期の投稿者は「標準化」という考え方はソフトウェア開発には適さないという姿勢だった。
私にとって、アジャイルが成し遂げた躍進は、ソフトウェア開発は決定的なプロセスではないということ、また、そこには「標準化」などないということを認めた点です。
Alisson Vale氏(リンク)の見解はこれとは異なっていた。氏は、標準化を「現代におけるチームの作業のやり方」と見なしている。標準化をこのようにとらえた場合、アジャイル ソフトウェア チームに適用できる事例は以下のようになるだろう。
- 毎朝9時にスタンダップミーティング(リンク)を開催する
- 赤と緑のリファクタ(リンク)手法を用いてコードを記述する
- チェックリストを用いて新しいストーリーの作業が実際に行われている(参考記事)か確認する
- ペアプログラミング(参考記事リンク)
- ピンポン ペアプログラミング(リンク)
- 特定のツールおよびライブラリを使用する
Robert Thompson氏(リンク)は、「The no-nonsense guide to standardized work（リンク）」の中で次のように説明している。
従業員たち（「第三者」ではない）は、最適な手法の発見や継続的なプロセス改善のための手法の作成に向けて、彼らが熟知している作業を分析します。こうして、彼らは問題解決への責務を担うようになり、結果として生じる標準を認めることになるのです。
今日のプラクティスは標準的であり、チームが現時点での作業のやり方を理解する最善の方法である。標準が確立されれば、チームは自由に実験を行い、改善方法を見出すことができ、これにより進化し続ける標準がもたらされる。この考え方は、チームを制限するものとして標準的な方法を使用するということではない。むしろ、この標準は継続的な改善へのベースラインとして使用されるべきである。
この説明は、適切かつ有効的に「標準化」をとらえているだろうか？コメントを書き込み、意見をシェアしてほしい。