i35_267’s diary

DMM platform engineer /Agile/Lean/Scrum(CSPO)/RDRA/DevOps

VSM (Value Stream Mapping)の改善プロセスの悩みを「カイゼン・ジャーニー」を読んで解決した。

背景

常日頃から、VSM (Value Stream Mapping)を使った改善を続けていますが、改善プロセス(どうやって改善していくか)の方法にずっと悩んでいた。

i35-267.hatenablog.com

そんな中、最近クラウドエナジャイズ経由でコミュニティーにも参加しだした、「カイゼン・ジャーニー」という本を読みました。

CrowdEnergize(クラウドエナジャイズ) — 行動を通じて、人を応援する

kaizenjourney.jp

この本の中で特に自身の状況とマッチして解決したのがVSM (Value Stream Mapping)について述べられているものになります。

本題

普段、VSM (Value Stream Mapping)を記載して「ムダ」を可視化した後、私の場合は

  1. カテゴリー分けをする。
  2. カテゴリーごとにどのくらいリードタイム、プロセスタイムがかかっているかを計算
  3. どこを改善していくか検討する。

といった方法を取っていました。 https://qiita-image-store.s3.amazonaws.com/0/122901/b3e940e6-9948-556c-5198-e19ef756489b.png

これでも特に間違えではないとは思いましたが、カイゼンしていくのに「ポリシー」みたいなものがないかを探していた。

そんなとき「カイゼン・ジャーニー」という本に出会いました。カイゼン・ジャーニー」ではリードタイムを削減するポイントとして下記を提示していました。

ポイント① 待ち時間が長く、ボトルネックとなっているプロセス付近

とある。VSMには待ち時間といった観点では2つあると思っており

  • プロセスタイムの中で待ち時間(WT)
  • リードタイムの待ち時間(プロセス間での待ち時間)

の2つである。どっちかというとリードタイムの待ち時間の待ち時間のほうが多くなる傾向が高い。なので実行時間(PT)を短縮するよりも上記のような待ち時間を削減したほうがよい。

ポイント② 手戻りが発生していて、その割合が発生しているプロセス

と次にある。例としてあげているのを一部引用させていただくとプロセスの最終段階でテストをすると不具合があったときにそのプロセスがすべて手戻りになってしまうのでTDDを導入する等をしたほうがプロセスとしてスムーズに行くと言った形である。

そして、私自身がほしいと思っていた

カイゼンしていくのに「ポリシー」みたいなものがないかを探していた。

といった面だとこの章に書いてあったコラムとして上がっていたECRSの原則がとても参考になった。

ECRSの原則とは?

ECRSの原則とは、業務改善方法の4原則でVSMに当てはめると

  1. Eliminate(排除): そのプロセスは本当に必要な業務かどうか。
  2. Combine(結合) : 作業分担をしずぎて、逆に待ち時間のムダを発生させていないか。
  3. Rearrange(交換 ) : プロセスの順番を入れ替えることで効率化を測れないか。
  4. Simplify(簡素化): 作業を簡易化することで効率化できないか。

の4つの頭文字をとっています。 一般的に1→2→3→4の順番でおこなうべきとしています。

  • プロセス自体を(排除)すれば作業自体がなくなるので大きな改善(リードタイムの削減)につながります。
  • また、作業分担を見直しプロセスを(結合)することで削減できるものも多いとおもいます。
  • (交換)に関しては、

    例としてあげているのを一部引用させていただくとプロセスの最終段階でテストをすると不具合があったときにそのプロセスがすべて手戻りになってしまうのでTDDを導入する等をしたほうがプロセスとしてスムーズに行くと言った形である。 にあるような例が当てはまると思います。

  • 最後に(簡素化)に関しては、複雑なことをせずに作業を簡単にする。また作業を標準化するなどで横展開できるようにすることでも良いと思いました。

ECRSの原則は本書(カイゼン・ジャーニー)ではじめて知ったので非常に助かりしました。

上記で記述したようなことをもとに改善を進めていきたいと思います。