プロセスの並列化
表準（ｵﾓﾃﾋｮｳｼﾞｭﾝ）* を前にして、関係者で議論したことで、
大きな成果が出て来ました。
*表準：現状のありのままの姿を可視化したもの
性能グループを構造グループの二つのグループは、
下図のカイゼン前の矢印の長さが物語っていますが、
性能グループが約３週間かけて、外形の検討
そこで決定した情報を受けて、構造グループがまた３週間検討
性能グループの外形の検討結果にミスが出た場合、
構造グループの工程がやり直しとなります。
大きなロスが発生していたことがわかりました。（図１参照）
改善後は、検討プロセスを機械の基礎部と上部の二つに分け、
それぞれの検討が終了した時に情報を確実に検証した後に、
次の工程に渡すことにしました。
情報の一元管理による効率化と検討の充実
前工程での検討結果情報をもらってから、
自工程の検討を開始するプロセスが６回も繰り返していることが見つかりました。
議論の結果、お互いに相手の情報を待っていることが習慣化しているだけであることを共有しました。
この場合、お互いに必要な情報をサーバー内で共有しておくことで、十分に検討が進むことも確認できました。
これにより、お互いの待ち時間がなくなったことで、検討に現状より多くの時間を取ることができるようになります。
まとめ
TPSの生産現場の表準（ｵﾓﾃﾋｮｳｼﾞｭﾝ）を開発の改善にも適用することができました。
生産現場では作業工程（プロセス）で実際の物（ワーク）に部品を取り付ける動作などがカイゼンの対象となります。
開発では情報を扱います。目には見えませんが、情報を加工していくプロセスを可視化すると、問題が見えるようになります。
生産現場＝物理空間ではものを加工する動作を改善していく活動に対して、 開発＝情報空間では、情報の流れを澱みなく整流化することがポイントになります。
抽象度を上げ上位概念で見ることができると、 プロセスで仕事をしていることは製造も開発も共通していることが理解できます。