開発プロセスの分析・課題解決でVSMが役に立った話

こんにちは！スナックミーでPM兼エンジニアをやっている渡邉(nabepiyo)です。

スナックミーに限らず、これまで開発する中で、「この機能が使われていないのはなんで？」、「この機能リリースしたけど要望と違っていたよ」、「この機能リリースまでに思ったより時間がかかる」という出来事に遭遇することがありました。

今年の1〜3月にかけてVSM (Value Stream Mapping)を使って、開発プロセスの課題を可視化したり、解決に関する取り組みをやって、徐々に改善できてきたのでそんなお話をご紹介したいと思います。

こちらの動画を何度も見て学ばせていただきました！めちゃくちゃわかりやすいのでオススメです！

ではでは、どんなことをやってきたのかお伝えしたいと思います。

VSMを書くツールはdiagrams.netを使用しました。

スナックミーのとあるチームでは開発の際にZenHub、GitHub、Docker、Ruby on Rails、AWS(細かい部分は割愛)を使っているので、こうしたツール群をVSMにプロットします。

VSMを書いてみるとわかるのですが、それぞれの手続きでLT(リードタイム), PT(プロセスタイム)を出すところが大変でした。特にGitHubのそれぞれのPRごとにレビュー完了までの時間を取得するところ。。。

※ 実はAPIで抽出することもできるのですがVSMを作成したのが初めてだったので、まずは生のデータを見ながら手を動かす選択をしていました。結果的にこの行動が意味を持ちます。

所々カスタマイズしたスクラムで開発しており、ストーリーポイントごとに開発にかかる時間や、レビューが完了するまでの時間やSR(手戻りが発生する割合)が異なるので、違いがある部分は別のマップに切り出して作成しました。

今回は、VSMを書いたことで、

などなど他にもいろいろと改善したくなるポイントが浮かび上がりました。

生のデータを見たことで、この時はこんな出来事があったな(障害対応していたな等)と思い出すことができ、一概に全てこの結果が悪いまたは改善の余地があるとは言い切れないものもあるとわかりました。

レトロスペクティブでVSMを見て、チームでなぜこうした結果になるんだろうと話し合い、解決策を考えました。実際に改善につながっていくブレストなのでここはチーム全員の士気も上がります🔥

細かな部分まではお伝えできないのですが、例えば、上の2.は急ぎのPRなのかどうかが不明確であったり、日々バーンダウンチャートを見てチームの進捗を追うことができていないという課題が隠れていてLTが長くなっていました。

そこで、日々10分程度のデイリースクラムを取り入れてみたところQA、Stage/QAのLTが半分以下になりました🙌(出社時間が異なるため、それまでやっていませんでした。。)

意外と簡単にできることで改善インパクトが大きいコスパの良い取り組みの1つのご紹介でした。

VSMはどこのプロセスを改善すればどれぐらいのインパクトが出るか判断することにも使えます。

開発生産性の向上にはまだまだ伸びしろがありますが、数字が見えてなくて改善してもインパクトが小さなものを優先度高くやるような無駄打ちをすることがなくなるので、効率も上がって良い試みだったと感じています。

そんなスナックミーではもりもりコードを改善し、開発していきたいテックリード(バックエンド)を募集中です。ご興味のある方はぜひこちらからご応募ください。

snaqme Engineers Blog