はじめに
こんにちは、プラットフォーム開発部の石垣(@i35_267)です。
2015年4月にDMMに入社し、現在はサービスで利用される基盤システムの開発チームでプロダクトオーナーをしております。
突然ですが、私のチームでは以前こんな事例がありました。 ある機能を2日で開発できたため、早くリリースして効果測定がしたい。 ただしそう簡単にはいかずに、グループ内承認・他部署との調整・リリース手順書の作成など、リリースまでの調整部分で30日も時間を費やし、結果として32日後にリリースできたといった事例でした。
そこで、当記事では
”VSM(ValueStreamMapping)によってリリースまでに268.5hかかっていた時間を54.5hに短縮できた秘訣”
と題して、社内外のイベントで度々登壇してきた内容をご紹介いたします。 ValueStreamMapping (以下 VSM)を使った時短術を、皆様にもご活用いただけたら幸いです。
VSM(ValueStreamMapping)によって 実現できたリリースまでに268.5hかかっていた時間を54.5hに短縮できた秘訣 from i35_267 Ishigaki
▼ 登壇イベント
devopsdaystokyo
目次
①VSMとは？
②VSMを作ることでどのくらいの効果があるか。
②明日からVSMを作れるようになるには。
①VSMとは？
VSMとはこのような図のことです。
1つの機能をリリースするために必要なプロセスとそれにかかった時間を可視化します。 VSMを作成する際は、機能をリリースするにあたって関わった関係者を全員集めて行うのが理想的です。
組織は大きくなればなるほど開発のプロセスにおいて無駄な手順が発生してしまうことは避けられません。DMMのように大きな組織になると、開発からリリースまでのリードタイムが長くかかります。 VSMは開発プロセスを可視化することで、無駄の発見をステークホルダーやチーム内に促す効果があります。
②VSMを作ることでどのくらいの効果があるか
複数のサービスにおいてVSMを導入してもらったところ、開発からリリースまでのリードタイムの時間配分比率がほぼすべて下記のようになりました。
図を見てもわかるとおり、
① ステークホルダーとの調整
② リリース準備+作業
に大きな時間がかかっていることがわかります。
どのように上の2つを改善していったかを、例として説明します。
まず、不要なMTGの排除を実行しました。ミーティングの目的を明確にして、不要であれば排除しました。また、不明点や相談事項があればslackで常に確認できる状態を作った結果、228.25時間かかっていた調整作業を40時間に短縮することに成功しました。
③リリース準備＋作業においては、リリース作業の簡素化としてSlackを利用して1つのメッセージを送ることでデプロイメントツールをハンドリングしてリリース可能に。リリース申請フローにおけるステークホルダーとの調整の無駄も、目的を明確にして不必要な箇所は排除しました。これにより、26.5時間かかっていたリリース準備の時間を5分に短縮できました。
③明日からVSMを作れるようになるには
VSM作成には3つのフェーズがあります。
| Ph | 項目 |
|---|---|
| 1 | VSMの描き方について |
| 2 | ムダを発見する |
| 3 | どこから改善するべきか |
図のVSMを例に述べていきます。
③-1VSMの描き方について
VSMの要素は下記の４つです。
1. プロセスのタイトル・・・プロセスの名前(例 : 会員登録機能作成)
2. プロセスタイム・・・プロセスにかかっている時間(例 : 会員登録機能作成→12h)
3. 完成と正確性の割合・・・前のプロセスへどのくらい出戻っているか(例 : 承認MTGを経て、会員登録機能作成の70%が実装出戻り)
4. リードタイム・・・プロセスにかかっている時間と次のプロセスに移るまでの時間
③-2 ムダを発見する
VSMを描いた後、どのようにしてムダを発見するのが良いでしょうか。ポイントをまとめたメソッドを紹介します。 ムダを発見するフローとして
・2 STEPS
・3 POINTS
の順で説明していきます。
STEP1,2では、VSMの中でムダを発見しやすくするためにプロセスのカテゴライズをします。
そしてPOINT1,2,3で実際にムダを発見していきます。
③-3 改善メソッド ~ECRSの原則 〜
ムダを発見したら最後に、どの順番で改善していくのが効率的なのかを、業務プロセス改善の『ECRSの原則』をVSMに当てはめて考えていきます。下記をご覧ください。
一般的には、1→2→3→4の順番で改善していくと良いとされています。 例えば、1.Eliminate(排除)に関しては、プロセス自体を排除できればそのプロセスを行っているProcessTimeも、そのプロセスの前後のLeadTimeも排除できるため効果は高いです。
また、VSMを作成するプロセスにおいて頭に入れておきたい点がもうひとつあります。
それは、
「大事なのは改善ポイント(=ムダ)を見つけることであり、どう改善するのかは別のレイヤーで話すこと」です。
関係者を集めてVSMを作成している最中に「どう改善するか」についても議論が及んでしまうと、そこでも時間的・人的コストがかかってしまいます。VSMを作成している時は「どこがムダかを発見する」ことに集中して、改善はまた別の時間に行うことが重要と考えています。
明日からできること
通常、VSMは開発プロセスに関係している人を集めて行いますが、それが難しいのであれば、まずは自分がわかる範囲の小さい開発プロセスを見つけて、それを一人でVSM作成→可視化し、発見したムダをチームもしくは上司に見せることです。 そうするとチームからグループ→部署へと自然と広がっていきやすくなると考えています。私もそうでした。 明日からVSMを作って開発プロセスのムダを可視化してみてください。
登壇したイベントの最後にあったClosing Sessionでの会場アンケートでもVSMに関する注目度がわかりました。
おわりにメンバー募集
私が所属しているプラットフォーム開発部では一緒に働いてくれる仲間を探しています。 ご興味のある方はぜひ下記をご覧ください。
