@IT会議室で「開発現場にトヨタ看板方式」が投稿されてます。
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?mode=viewtopic&topic=36273&forum=25&start=0
私の発言もあるので重複する部分もあるのですが。
・タイムリーな部品調達
・タイムリーな現場の要求項目の伝達
・在庫ストック限りなく0の状態での組み立て部品の流通
この点に絞って考えて見て、局所的には正解なのかもしれませんが、流通形態に無理が起こり、配送途中の貨車の中が移動倉庫の役割を果しているのを見聞きすると、
公共の資源を倉庫として使用しいる気がして違和感を感じるのです。
とはいえ、「看板方式」は確立されているので成功手法の一つでしょう。
各部署の作業内容の独立性が高く,部署内で完結している作業が多く,部署間の連絡は決められたインターフェースを通してやり取りすることを徹底しているから可能になったと言えます。
部署はカプセル化されたモジュールになり,部署間の連絡は、提灯/看板というMessageを解して,イベントドリブンで処理されると見なすことも可能です。
マネージャはMessageのDispatchを行うのが仕事となり役割も明確化できます。
前提条件の一つにモジュールの作業内容自体が規定化され、個人の自由裁量の余地が少ないからこと可能になるとも言えます。
システムの開発現場は PM工程,SE工程,PG工程の切り分けが難しく、各工程に当事者の自由裁量が大きく入り込んだりします。
各工程間のインターフェースを確定し、各担当者はインターフェースを介して連絡すればアヤフヤ性は少なくなると考えています。
これをウォーターフォールのように1回の流れでするのでなく,再帰的にスパイラルすることで円滑に流れるでしょう。
その面でも「看板方式」はウォーターフォール-方式に感じるのは私だけでしょうか。
昨今のPG工程は,俗に言うコーダー工程ではなく、PGの意思決定の作業になります。
コーダー工程は開発環境が実装してくれるようになるでしょう。
それゆえに,PM/SE/PGは役割分担なのです。残念ながら、上下関係だと認識している職場も少なからず見受けられます。
上流工程でのアヤフヤな点をアヤフヤなまま次工程に回すとアヤフヤ倍増法則が働き、デスマーチとなりかねません。
工程のモジュール化はアヤフヤな状態では次工程に移せない仕組みであり、チェック機能だと想うのです。
開発現場はまだまだ家内製手工業の域を脱してないなと改めて感じたしだいです。