本記事は、READYFOR 株式会社の READYFOR Advent Calendar 2021 18日目になります。
プロダクト開発部のPdM @feat-kj です。
2021年、READYFORのプロダクト開発チームは多くの大型リリースを行いました！
- 2021年8月 実行者プロダクト編集画面のリニューアル
- 2021年9月 支援者一覧ページのリニューアル
- 2021年11月 続寄付サービスβ版のリリース
いずれのプロダクトもサービス価値に大きく寄与し、プロダクトチームとしては本当におつかれ様の1年でした。
同時にリリースで終わりとせずに成果を出し続けるような体制を作っていく必要を感じました。本記事で課題の認識と対策を検討しながらサンタさんに会う夢を見ようと思います。
本記事について
全体の大きな施策(プロダクト注力ポイント)に対応しながら [カイゼン] を進めていくにはどうすれば良いかを検討した内容を書いていこうと思います。
検討したこと
プロダクト注力ポイントにコミットしながらカイゼンを進める仕組み
Index
- カイゼンを意識したきっかけ
- カイゼンの対象
- バックログにラベルをつける
- カイゼンを進めていくSquad構成
- ※READYFORはSquad体制で運用しています
カイゼンを意識したきっかけ
プロダクト注力ポイント にコミットできた事は大成功ではあるのですが、既存のプロダクト課題・改修の優先度を下げざるを得ない問題もありました。細かい施策で効果の出るものも多く、コスト削減(ユーザーへの対応が早くなるようなものもある)への貢献などに対応しきれていない事が非常にもったいないと感じました。(数字なども取れているので効果の不確実性が低い)
- ちょっとした施策でインパクト出そうな箇所に手をつけられない
- 細かい要望に対応できない
- ここをリファクタしておきたいのに！
- このオペレーション効率悪そうだからどうにかしてあげたい
プロダクトはリリースがスタートで [カイゼン] を進めていく事で本当に創出したかった価値を提供できるようになると思っています。またプロダクト開発Squadの観点でいうと [カイゼン] 施策に手を加えれらない状態が続くとビルドトラップに陥るようになり開発自体が作業化してしまう懸念もあります。
カイゼンの対象
プロダクト開発現場でよくある事例について大きく2つに分類してみました。目に見えないが効果があるものだったり、優先度が下がりがちなものです。
[カイゼン] を推進していくことが目的なので**[対応しないと・・・]ではなく[対応するとプロダクトに良い影響があるのでやっていこう！]**というモチベーションで取り組みました。
カイゼン① - 技術的負債
技術的負債についてはエンジニア以外の方に理解してもらうのになかなか苦労した経験がある人が多いのではないでしょうか。
納得感をなかなか得られない理由は様々ですが、個人的にコレだなと感じるところがあります。
- 機能としては正常に動いている
正常に動いている状態だと、そこまで急ぎでやる必要あるの？ という議論になり、どうしても納得感が薄れてしまいます。
技術的負債を改修した際のメリットを共通認識としてエンジニア以外の人と持てるようにする事が大事だと感じました。ただし全てを対象にやる必要はなく、本当に大事な箇所や変更が頻繁に入るとこだけなど基準を決めて対応していく必要があります。
今回はプロダクト目線でのメリットを挙げてみました。
プロダクト計画がしやすくなる
どういう事かというと 見積もりの不確実性が減り、見積もりの精度が上がるという事です。以下のような兆候が続く場合は、技術的負債の影響によるものなのか認識合わせをする必要があるかもしれません。
- 仕様自体は複雑でないのに、想定外の箇所まで対応箇所が及んでいる
- 機能を追加する際に見積もりどおりにいかないことが多くなってきた
- StoryPointで見積もりしても、その倍かかってくるような状態が当たり前になっている
- 影響範囲の調査に結構時間がかかる
何故かというと蓋を開けなければわからないという設計・実装になっている場合は、開発してみたら想定外のパターンを発見してしまう事が非常に多いからです。
綺麗に整理されていれば見積もり・実装速度と精度が上がってくるのでプロダクト戦略がより立てやすくなります。理想論ではありますが、少しでもこの状態を作っていく事が大事です。ただし機能開発と同時に行おうとすると現実的ではない(スケジュール的にゴリとやらざるを得ない)ので常日頃から対応していく必要があります。
属人化による影響が少なくなる
[この機能はこの人でないとダメ、この人に聞けばわかりそう] という事があります。この状態が起きているときによく取られる対策は [あの人の知識を誰かに共有してもらおう]という感じで同じSquadにアサインするパターンです。
理想の状態としては人に依存しているコードを整理して、コードが属人化されるような状態は避けておきたいところです。この状態が作れると、人によるアサインを考慮する必要がなく適切なSquadを組む事ができます。ただしドメイン知識なども大きく影響するので完全に属人化を排除する事はできないかもしれませんが、対応できる人が増えるのは間違いないと思います。
テスト工数削減・不具合率の減少
コードが密結合されていると、改修する際の心理的安全性がかなり低い状態になります。これはエンジニアだけでなく、PdMや関係部署も同様で機能ができているけど、過剰にテストしないとリリースできない状態を生んでしまいます。また想定外のところに影響が出て、大きな問題が発生することもあります。機能リリースしたら、不具合改修に追われることなく次の施策に注力していきたいところです。再リリースになると関係者のテスト、スケジュール調整なども増えるのでなるべく影響範囲の少ない状態を作り出していきたいです。
カイゼン② - カイゼン要望
- オペレーションで〇〇の機能が使いにくく操作ミスが多い
- 機能がないのでシステム以外の所でユーザーとのやり取りが多くある
対応方針を決めるのが一番難しいところでもあります。代表的な言葉として[運用でカバー]が良く知られています。技術的負債は エンジニア要件とプロダクト要件という観点の異なる検討になるのですが、カイゼン要望はプロダクト注力ポイント施策との優先度内で決められる事が多いからです。
この問題を解決するために [カイゼンチーム] として別チームとし対応していく組織もよく聞きます。別チーム案も考えたのですが、検討した結果、後述するSquad構成で対応する事にしました。
バックログにラベルをつける
プロダクト注力ポイント・大きめの施策と [カイゼン]を明確にする事によってプランニングする際の判断ができるようにバックログにラベル付けしていくようにしました。
featureバックログ
- プロダクト注力ポイントに関連しているもの
- [カイゼン]から上がってきたもので効果は高いが要件を詰める必要があるもの
- プロダクト注力ポイントではないが、並行で進めなければいけないものなど
カイゼンバックログ
カイゼン要望
- ちょっとした修正や手オペ・依頼が都度発生するもの
- 少しの改善で成果が出せるような施策
- 既知の問題でずっと対応できていないものなど
システム観点のカイゼン
- 技術的負債の対応
- SLO/SLIに影響が出た場合の対応
- ログやデータ周りの整備
- その他
カイゼンを進めていくSquad構成
いろんなパターンでシミュレーションした結果、以下のようなSquad構成とする事にしました。
Squad構成を決めるにあたり、Squadが自律的に動けることを重視しました。
守備範囲を設けると変な境界ができてしまうようなイメージがあると思いますが、プロダクトバックログを全体で共有するようにしています。まだ詰め切れていないですがLeSSの共有方法などは参考になりそうだと思っています。
MECEであること
Squad内で判断できる事を増やすために、Squadの守備範囲を明確にしました。
カイゼン施策を実施し、効果測定を行い検証サイクルを回していくには同じ指標を定常的に追っていく必要があります。そのためSquad構成も機能ではなく、ユーザー行動・ニーズが異なるという境界で分けるようにしました。守備範囲が被らないのでSquad内で完結して動ける事が多くなる為、カイゼン施策を回しやすくなります。
注意しないといけないのがAの課題を解決する際にBをやらなければいけない。そのためにBの機能を別のSquadにお願いしないといけない
というような分断が起こる事です。この場合は解決したい課題を持っているSquadがBのSquadと連携して自分達で解決していくようにできればと思います。
MECEではなくなってしまいますが、連携が必要なところは積極的に連携できるようにしたいです。
Squadがアウトカムを意識して動けること
担当領域が明確になる事により、メンバーが事業指標が担当領域の課題により関心を持って取り組めるようにフローの改善などにもTryしています。
今までも方針や数字の共有などを行っていましたが、その数字に対して明確にコミットできるという状態が作れれば共有された情報にも大きな意味が出てきます。詳しくは amachinoの不確実性下の意思決定理論入門 情報の価値 の項目を読んでいただければと思います。
実際に課題共有を積極的に行った事で以下のような効果がありました。
- 課題解決するなら、要件どおりだと期日厳しいからこんな案はどうかなどの提案
- やるやらの判断が共有認識がSquad内で揃うようになってきた
- 課題に対しての効果などの視点
- オーバーエンジニアリングなのかどうかの視点も考慮されるようになった
- 見積もりと実績のズレがSprint内で吸収できるようになった
- 期日を考慮した場合と最善案をエンジニアが詳細に提案する動き
課題共有をどのように行ったかというと通常のプロセスの中に課題を検討しアイデアだしするMTGを入れ、全員でやるようにしただけです。
情報の価値を活かせていると思います！
[プロダクト注力ポイント]と [カイゼン]を進める際に意識する事
実際に[プロダクト注力ポイント]と [カイゼン]をどのように同時に進めていくかという事ですが、エンジニアパワー(Velocity)をどのように配分していくかという事になります。ここでバックログにラベル付けした効果が出てきます。方法として大きく2つあると思います。
リリースとプロジェクト終了を混同せずに計画する
大きめのプロジェクトだと多く見られる事ですが、リリース終わった後に、次の施策にすぐ移る事がありますが、それだと[カイゼン]は進みません。そこで計画的に[カイゼン]を行う時期をリリース後に確保するパターンです。
- リリース日はプロジェクトの中間ゴール
- 計画したものが終わった時点でプロジェクトは終了
集中すべき事が明確に分かれていて上手くいきそうな感じはしますが、現実的にはリリース後に別の施策を打つケースがほとんどなのでパターンの1つとして持っておく程度にしておこうと思います。
SprintBacklogで常に計画していく
[カイゼンバックログ]は常に発生するものなので、定期的に行っていくのが一番良さそうです。ある一定の割合で[カイゼンバックログ]を消化していく事で常に[カイゼン]が進んでいく状態になります。時期によっては[featureバックログ][カイゼンバックログ]の割合を変えて優先度の高いものに対応していく柔軟性は必要になってきます。例で言うとSprint3, Sprint4のパターンです。これはSprint3の時期に[featureバックログ]の優先度が上がり [カイゼンバックログ]の割合が減っています。Sprint4の段階で[カイゼンバックログ]の割合を増やしSprint3の分を調整しています。
[カイゼンバックログ]に使う割合などは、今後状況を見て決めていく予定です。
最後に
まだ試しながら導入している状態ですが、チームビルディングも [カイゼン] が必要になってきます。できるところからどんどん試して行ってフィードバックを受け、より良い体制を作っていければと思います。
昨日の記事は @t2-kob さんの「ファシリテーション手法「ラジオDJシステム」でオンラインイベントの孤独の壁を破壊する！ ～コミュニケーションの特徴とその対策～」、明日の記事は @kyota さんの予定です！