スクラム"的"であれ。スクラム移行の僕的失敗談
こんにちは。Voicyで7月からPMMを拝命しましたDさんです。
昨年7月に双子が生まれ、三児の父としても奮闘中です。
PMMって何？って思った方はこちらも併せてどうぞ
この記事は「スクラム開発」をまだ始めてないけど始めたい、そんな人に届け！という気持ちで書いてます。
前もって言っておくと、スクラム開発への移行に失敗したという視点ではなく、スクラムを導入したことで僕が陥ったビルドトラップのことをお話します。
PdMみたいな方はきっと共感してくれる人もいるんじゃないかなあ。
スクラム開発とはなにか
スクラムは「経験主義」と「リーン思考」に基づいている。経験主義では、知識は経験から⽣まれ、意思決定は観察に基づく。リーン思考では、ムダを省き、本質に集中する。
スクラムでは、予測可能性を最適化してリスクを制御するために、イテレーティブ（反復的）でインクリメンタル（漸進的）なアプローチを採⽤している。(以下、略)
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
スクラム開発の定義は概ねこのあたりに集約されるんじゃないでしょうか。
どうやら雑にまとめると、「未来はわかんないからチームで学びながらお客様が本当に求めるものを開発するためにちょっとずつ開発していこうよ！(意訳)」っていう感じでしょうかね。
スクラム開発の定義はいい意味でふわっとしてるんですが、これとは別にスクラムイベントと呼ばれる開発プロセスの中における様々なイベント(リリースしたり振り返ったり、認識合わせのmtgを行ったり)が設定されます。
このスクラムイベントによって手段が目的化してしまうことを危惧しています。
以下、僕の失敗談を交えて少しだけ。
この半年の僕の失敗
2021年7月1日から僕がジョインしたころ、Voicyはちょうど組織全体が40人を超える規模にどんどん拡大しているタイミングでした。
プロダクトに直接関わっているメンバーは20人を超えるぐらいで、ひとつの節目を迎えていたと言ってもいいでしょう。
2月から期初の弊社において、8月は下期の始まり。
ちょうど"グロースチーム"なるものができて、ド新参者の僕はグロースを担当することになりました。
それと同時に開発体制としては「スクラムを導入しましょう」という動きになりました。
当初はエンジニアだけでも約15人と大きくなってきて、一般的な(少なくとも僕が過去2社で5年ぐらい慣れ親しんだ方法としての)スクラムの形ではなかったけど、全員の認識を合わせるために約15人全員でスクラムチームを組成しました。
みんなで知恵を出し合って工夫して、今ではスクラム開発もそれなりに板についてきたと思いますが、ここまでで最も大きな課題は「アウトプット最適化」に陥ってしまったことです。
これは2月からの期に持ち越している課題です。
スクラムイベントがPdMをダメにする？
スクラム開発体制になって最も大きな変化は「リリースサイクルを周期としたスクラムイベント」です。
Voicyの場合、基本的に1週間に1度リリースサイクルを回しています。
それに伴ってスクラムイベント（リファインメント、プランニング、レビュー、朝会などなど）も行います。
これを改善を重ねながら半年運営してきたのですが、僕の反省点は大きく2つ。
①"リリースサイクル"と"不確実性への対応"を意識するあまり、開発の規模が小さくなってしまったこと
②リソースを有効活用する という観点からアウトカム(価値)ではなくアウトプットのデリバリーに注力してしまったこと
順を追って説明します。
①"リリースサイクル"と"不確実性への対応"を意識するあまり、開発の規模が小さくなってしまったこと
Voicyは僕が入社する前のすでにPMFしており、音声業界のなかで一目を置かれる規模に成長していました。
しかし、今後描く理想からすればまだまだ成長しなければなりません。
本来は非連続な成長を目指し、リスクをうまく取りながらより不確実性の高い領域にチャレンジすべきだったのですが、リリースサイクルとリスク(不確実性)を意識するあまり足し算の施策に終止してしまったのです。
日本家屋を増改築すればいつか日光東照宮になれるかもしれませんが、サグラダ・ファミリアにはなれません。
日光東照宮とサグラダ・ファミリアのどちらがいいかという話ではなく、選択の幅を増やすこと
不確実性は高いが非連続な成長が見込める領域に健全にBetすることによってプロダクトを成長させることがPdMの本分だということを改めて感じた半年でした。
②リソースを有効活用する という観点からアウトカム(価値)ではなくアウトプットのデリバリーに注力してしまったこと
これもプロダクト開発あるあるだと思うけど、「今iOSエンジニア手が空いてるんだけど、なんかやることない？」っていうのあると思うんです。
これがよくない。
優先度を飛び越えて、影響度合いや確度を飛び越えて、リリースされてしまう機能たち。
デリバリーされているのは機能であって価値ではない(少なくとも求めている体験向上、数値改善は得られない)。
たぶんいつかはやってたけど、今じゃない。そんな開発を進めてしまったという事実はあります。
スクラムは悪くない。でも…
声を大にしていいたいんですが、スクラムが悪いわけじゃない。
スクラムは先人たちが編み出したひとつの最適解で、スクワッドにしろ何にしろそれぞれが指針を示してくれているので、先人たちは偉大です。
ただし、スクラムは手段であって目的ではない。
弊社の場合、組織体制の変更とプロセスの変化が同時に起きたことによるところは大きいと思っています。
組織を動かすと大きなストレスがかかるので、一定の足踏みは許容せざるを得ないと感じます。
気を取り直して今期は同じ轍を踏まないように気をつけたいと思います。
スクラム"的"であれ。
表題に書いた「スクラム的」というのは僕が志すニュアンスですが、スクラムを思想と捉えて、本来やるべきことを見失わないようにしましょう。
本来やるべきこととは、お客様に本当の価値ある機能やプロダクトを提供することです。
スムーズにたくさんの機能がリリースされれば当然気持ちいいものです。
少しずつでも自分たちの手によってプロダクトがアップデートしている感覚がある。
しかし、それが本当にお客様を喜ばせるものなのか、また今のプロダクトの成長に必要なのか、時々立ち止まって考えてみることをおすすめします。
[定期]仲間を募集しています！
Meetyやってるのでゆるく話したい方はこちらからどうぞ！
弊社採用ページはこちら！たくさんインタビュー記事が掲載されてます！
この記事が気に入ったらサポートをしてみませんか？