モノと情報の流れ図（バリューストリームマップ）とは 書き方注意とヒント
Value stream map.
皆さんこんにちは！ 今日も一日お疲れ様です。
働き方改革とかなんとか言われて久しいですが、何かしら楽にはなっていますか？
「Do more with less」 なんていう言葉がありまして。
単純に、「少ない人数でより高い生産性」を目指すためのスローガンだったりします。
Forbes（アメリカの経済紙） が「annoying words」（うざいビジネス単語）を紹介しているのですが、この「Do more with less」も見事に入っております（Weblio）。
わからんでもない。
そんなわけで、効率化というのはいつも声高に叫ばれています。
改善して、生産性を上げていきましょ。
ということで今回は、物と情報の流れ図（バリューストリームマップ）の目的や、書く時の注意点・ヒントを少しご紹介したいと思います。
物と情報の流れ図（バリューストリームマップ）とは
上が情報、下がモノとプロセス。お客さまは右、プロセスの流れは左から右へ。
この物と情報の流れ図（英語でValue stream map、バリューストリームマップ）と呼ばれるもの、トヨタで生まれたと巷では言われていますが、現在われわれが良く目にするタイプのVSMは本家のものとは違います。
でも、ここでは「正しい」とか「オリジナル」とか、あんまり語りません（理由後述）。
いずれにせよ、描く目的は「見えるようにする」。この一点に尽きますね。
お客さんから注文が入って、会社が受注することで全ての物事が動き出します。
予測をもらい、のちに実際の生産量が決まる。
受注量に合わせて、材料を仕入れないといけない。サプライヤーとやりとりが始まりますね。
届いた材料は倉庫で管理。
そこから上流工程を経て下流工程へと、どんどんモノが流れていく。そして最終的には、完成品がお客様のもとへ届けられていくわけです。
こうしたプロセスの、モノと、情報、そしてそれぞれのプロセスが描かれていくのがこの物と情報の流れ図（バリューストリームマップ）になります。
パッと見て、どういう工程で工場が稼働しているのかわかるようにするためのツールですね。
ちなみにこれは、工場や製造ラインで使うべきもの。
主にオフィスに関わるお仕事に使いたいのなら、以前ご紹介した「プロセスと情報の流れ図」（Information and process flow; Swim lane）を使うのがいいと思います。
物と情報の流れ図（バリューストリームマップ）のチーム編成
目的は、先にも書きました前工程の、頭からお尻までの見える化ですが、さらに最も重要なのが、これを書くことによって、どこに問題があるのかが誰が見てもわかる。あるいはわかるようにする。
そしてどの問題（工程）から優先してやっていかないといけないかが、全員一致で理解できる。
この全員一致で、というのがキーです。
倉庫の方は、もちろん倉庫のことはわかるけれども、ラインのことはわからない。
ラインの方も自分の部署や作業場のことはわかっても、前や後ろの工程のことは、いまいち。
あるいは発注やら生産計画の方も、あんまり現場のことまでは、というのが現実ではないでしょうか。
ですのでいったんこのVSM改善をやると決めたら、頭からお尻まで、すべて関わる部署から人を出しましょう。でないと改善プロジェクトは立ち行かなくなります。
Cross functional team（横断的部署によるチーム）を作ること、これも重要です。
使う英語は、以前まとめましたのでご覧ください。
VSMから改善を始めるメリット
我々が、仕事や現場で改善しなくてはいけない物事は、山ほどあります。
しかしながら、当然、同時にそれら全てを解決するのに足るリソースや、時間なんてものはない。
そして多くの場合、誰もビジネス全体の状況を知らないです。
知らないまま改善しても、「部分最適」になってしまい、上流の工程で何か変化が起きると、それまでの改善努力が、全部パーになってしまったりする。
そのような、誰かの努力がムダになってしまうことは、極力避けなければならない。
構造的なカイゼン（継続的なもの）を行うためには、全体をみて、そしてどこからやっていくのか優先順位を付ける必要があります。
現在だけでなく、将来のビジネス分野全体を見据えたうえで、今何が起こっていて、これから起こっていきそうなのかを考えるカイゼンが必要ですよね。
ですのでこのVSMは、そうしたことを踏まえつつ、工場やラインの様々な側面（人、運賃、品質、在庫、リードタイム、システムなどなど）から、ビジネス全体を概観するための優れたツールなのです。
ちなみにリードタイムに関してはこちら。
したがって
- 現在、および将来のお客様の需要を満たせなくなる、問題工程（ボトルネック）はどれで、
- 最初にやること、次にやること、その次の次の…と、どのような順序で問題解決をしていくか
ということが、チーム全体のコンセンサスを得られたうえで、進めていくことができます。
なかなか優れものですよ。
注意点とヒント
ここでいくつか、VSMを進めるにあたっての注意点とヒントです。
- 製品、サービス、プロセスバリューストリームの流れを完全に理解することに焦点を当てる。が、完璧にしすぎないようにする。
- 未来図（あるべき姿：Future state）は書いたほうがいい。
- バリューストリーム全体を、まずはささっと描く。そしてプロセス中の工程や材料の停滞具合を特定しつつ、詳細データを書き込んでいく（現地現物で）。
- まずは、お客さん側から始める癖をつける。そして上流に筆を進める。これ結構重要。
- 現地現物を大切に。 言われたこと、システムデータを信じない。自分で見て、すべてを測って、データをとること。
１は、もちろん理解できたに越したことはないですが、いつも口すっぱくして言っている、「これ書いたからって改善できるわけではない」という。
書くのはいい、でも実際に付加価値つける改善は手を動かすことによってですよね？ なので、あんまり完璧を目指さないでください。これ完璧にしても、一銭にもならない。
２、改善活動を通して、現状はどう変わるのか。これは書いた方がいいです。そうするとその未来図が、そのうち「現状図」になって、次のカイゼンにつながっていく。
大事なことは続けていくことです。
３、まずは大きな絵をかいて、それからどんどん細部に意識を向ける。Leanの考え方です。「Broaden->narrow down-> Broaden->narrow down->….」
４、これ結構重要（二回目）。例えば、不具合が出ていて、気づかずお客さんまで行ってしまうことだってあります。カイゼンはいつもお客さんに近いところから見ましょう。そうすれば、不良がお客さんに出ていってしまうことを、少なくとも防げる。
５、言うまでもないですね、現地現物でお願いします。
まとめ
書き方に関しては、いろんなサイトでご紹介されています。
- Edrawさんという会社で紹介されてるVSMソフトウェアなんかいいですよね。これ楽に描けそう。ちなみに私は会社PCのセキュリティブロックに阻まれて、残念ながら試してません。
- 「VSM (Value Stream Mapping)を書いたらリリースリードタイムが約200時間も短縮できることがわかった話」
この方の会社でも、威力発揮してますね。
でもこちらの方は、先ほどお話しした「プロセスと情報の流れ図」（Information and process flow; Swim lane）を使うほうがいいと思いますね、オフィス系なんで。
- Developers IOさんは、実際に作る際のProcedureが書かれていて、なかなか参考になるサイトと思いました。
以前もお話ししましたが、カイゼンで大事なことは「見える化」です。
VSMもそのためのツールになります。
現状を、未来のへの展望・予測を考慮に入れながら書き起こす。
そして、キーマンとなるCross functional teamで共通認識を作り上げて、継続的なカイゼンにしていく、そのための可視化ツール。
なかなか役立ちますから、ぜひ活用してみてください。
でも、ツールはツールでしかないので、これを美しく完成させようなどとは思わず、ぶっちゃけ必要なとこだけ埋めてくくらいでもいいから、まずは初めてみることですね。
書いて、試してみて、自分の会社の中で「VSMスタンダード」を作ったっていいんですよ。
なので、あえて「正しい」VSMの書き方とか、そういうことは紹介しませんでした。
やってみましょう。そして自分の会社（産業形態）に、最も合う形のものを模索していってみて下さい。
私がよくご一緒させていただくコンサルの方から一言、
「みなさんはプロなんだから、出来合いの道具をそのままありがたがって使うようなことはしないで下さい。自分の最も使いやすいように調整したツールを持っている、それがプロってものですよ」
とのこと。
VSMというツール、使い倒してくださいね！
今日も読んでいただきましてありがとうございました！
では！
トヨタ生産方式にもとづく 「モノ｣と「情報」の流れ図で現場の見方を変えよう
訳が分かりづらくて読むのに苦労する。もっと説明が必要な記述も多々。
でもVSMに関する書籍ってこれぐらいしかないのが実情です。
