バリューストリームマッピングの本を読みました

正式名称は『トヨタ生産方式にもとづく「モノ」と「情報」の流れ図で現場の見方を変えよう!!』ですが、言いづらいので、「バリューストリームマッピング(VSM)の本」ということでw

全体最適の概念をサポートするツールの一つとしての、バリューストリームマッピング。自分の立ち位置・ロール的に、個別最適ではなく全体最適を見据えて動く必要があり、ぜひとも身につけておきたいものの一つだったので、トヨタ生産方式なので製造業についてだけどこの本を購入しました。

トヨタ生産方式にもとづく「モノ」と「情報」の流れ図で現場の見方を変えよう!!

トヨタ生産方式にもとづく「モノ」と「情報」の流れ図で現場の見方を変えよう!!

VSMを知らない人は、こっちを読んでおくとざっくりどんなものかが分かりやすそう。DevOpsの文脈で語られてはいるけど、それ抜きにしても多分問題なく理解できる。

gihyo.jp



序文

序文から、大事なことが書いてあります。

1. チェンジ・エージェントを見つける
2. よいセンセイを見つける
3. 危機を利用して、会社全体を動機づける
 しかし、ここで彼らはステップ 5 へ飛んでしまうのです。
5. 重要なテーマを選んですぐにムダ取りを始める
 けれども、飛ばしてしまったステップ 4 は、実はもっとも重要なクリティカル・ステップなのです。
4. 全ての製品ファミリーについて最初から終わりまでの全体の「バリュー・ストリーム」のマップを作る

5. でのムダ取りによって個別最適な部分でのカイゼンは達成できるけど、それが全体最適につながるとは限らない。むしろ個別最適されていないところに在庫が溜まって流れがよどみ、フラストレーションを引き起こすかもしれない。なので、まずバリュー・ストリームから全体を眺める必要がありますよね、ということ。

Part III : バリュー・ストリームをリーンにするには?

つくりすぎ

「リーン開発の本質」を読みました - @ikikko のはてなブログで、『「作りすぎのムダ」=「余分な機能のムダ」が一番タチが悪く他のムダを引き起こすことがある』と紹介していたけど、ここでも同様のことがもうちょい具体例をあげて触れられています。

つくりすぎは、あらゆる種類のムダの原因になります。単に、過剰在庫とその中で眠るお金、という問題だけではありません。部品をまとめてつくったり買ったりすればそれを置いておかなくてはいけないし、置くためのスペースも必要です。置いてあれば運ばなくてはならず、そのために人も設備も必要になります。並びかえたり、修理したり、ということもあるでしょう。また、つくりすぎは欠品の原因にもなります。各工程が必要でないものをつくっているせいで忙しい、というのがその理由です。いま必要でないものをつくるのに人と設備を使っているが故に、余分な人と余分な設備能力が必要になっているのです。つくりすぎはまた、リードタイムも長くしてしまい、お客様の要求に対するフレキシビリティを弱めてしまいます。

製造業の話なので、ソフトウェア開発にそのまま当てはめられないところもありはします。在庫の保管スペース・設備とか持ち運びのコストなど、物理的なものは当てはまらないでしょう。ですが、一度着手すると完成するまでそれをメンテしないといけないとか(ステータスどういう状態になってる?とか、周辺コードの修正によるコンフリクトの解消作業とかとか)、あとちょっとで完成する他のものがあるのに今着手してるもののせいでなかなかそっちに手を出せないとか。

結局この辺も、自分の身の回りの個別最適ではなく、全体最適な視点でどこがボトルネックでそれを解消するには何が必要?を意識しないと抜け出せないので、やっぱりそこに落ち着くのかなーと。

ガイドライン #3:スーパーマーケットを使って、流れ化できない上流の生産をコントロールする

単純に流れ化できない工程において、後工程と前工程をつなぐ仕掛けとして、以下の二つが紹介されていました。

スーパーマーケット
後工程がスーパーマーケット内の部品を必要なときに必要な分引き取り、前工程は引き取られた分だけ部品を補充する
FIFOレーン
ある程度量をしぼったキューを用意しておき、その範囲内であれば前工程から後工程に自由に出していいけど、キューの制限を超えた場合は前工程をストップする

二つの違い、正直いまいち分かってません。が、WIP の制限をつける / 後工程が pull 型でコントロールするというのは、いわゆるソフトウェア開発でのカンバンプロセスと一緒だよねという理解はできました。逆に、これやらないと、前工程の都合だけでどんどん作られて在庫が増えてしまい、作り過ぎのムダが発生するよねと。

ガイドライン #5:ペースメーカー工程で、異なる製品を少しずつ繰り返してつくる(機種ミックスを平準化する)

機種ミックスを平準化するということは、一定期間に異なる製品の生産を平らにならして配分することを意味します。たとえば、午前中にタイプAの全数を組み立てて、午後にタイプBの全数を組み立てる、ということをしないで、もっと小さな単位でAとBを繰り返しつくるのです。

この例みて、ちょっとエクストリーム過ぎると最初感じました。部分だけを見ると、明らかにまとめてやったほうが効率よくできそうに感じるので。だけど、部分最適を重視してバッチサイズを大きくしていくと、結局流れが淀んでしまってリードタイムが長くなる・全体最適に支障をきたすというのは、この本だけでなく色んなところで言われてることなので、そっち方面に倒すよう意識しないとなーと。


全般的に、製造業に対してはすぐにでも使えるぐらい細かくいい本だけど、ソフトウェア開発の文脈ではそのまま使うのはオーバースペックかもと感じました。タクトタイム*1をベースラインとして、秒単位での改善を目安としていくとかとか。ただ、全体の流れ = バリューストリームを見える化して関係者全員で共通認識を持ち、ボトルネックを解決していくというのは、ソフトウェア開発でもやっておくべきことかなと思ってます。

そういう意味では、冒頭に紹介した日本のDevOps変革を促進するバリューストリームマッピング:一般記事|gihyo.jp … 技術評論社や、@ryuzee さんが以前ポストしていたバリューストリームマップの書き方などを参考にして、あとはやってみるぐらいから始めるのがいいのかな。コーチと自分で素振り的なのはやったことあるけど、やっぱ関係者巻き込まないと効果が薄いので、どっかでやりたいやりたい*2

togetter.com

*1:あまり理解できていない・・・

*2:そういや、一回やったときホワイトボードではまったく収まりきらなかったので、次やるときは大きな壁か机か、もしくは地面でやろうかしら