こんにちは。EMの加川(@shinpr_p)です。
本記事は、開発プロセスの変更を残したADRを眺めながら、スクラムの適用など開発チームの改善と向き合ってきた2-3ヶ月を振り返ります。
はじめに
前提知識としてADRについて説明します。
ADRは Architecture Decision Records の略で、アーキテクチャの決定を記録したドキュメント群です。
「意思決定の過程を残すこと」が特徴で、「検討したが導入しなかったもの」や「運用を進めることで適切ではなくなったため廃止したもの」、「技術選定の過程で選ばれなかった選択肢」など、よく歴史的経緯と言われがちな過程の情報が残ることが好きで、私はここ数年よく利用しています。
実際のADR
実際のADRがこちらです。
意思決定の関係者はby nameが含まれるので、公開用に加工しています。
以下、それぞれの意思決定について振り返っていきます。
イベント(会議体)の運用
これまでは、よくある「スクラム風な開発プロセス」でした。
この提案から、「継続的に価値を届けられるよう成果やプロセスを点検できるチームになる」ことをテーマに、開発プロセスの見直しを行なっています。
この時点では明確に「スクラムのフレームワークを導入する」とは言っておらず、「スクラムのエッセンスを盛り込む」という表現をしていました。
変更したこと
- タイムボックスを1週間から2週間にする
- プランニングMTGの進行を見直す
- 成果報告、進捗共有、各種振り返りと散らばっていたMTGを整理し、Sprint Review / Retrospective に集約
タイムボックスの変更
個人的には1週間のままで良かったのですが、スクラムイベントをしっかりやろうとしたときに「MTGの時間が多くなりすぎる」と言われがちなので、細かくやっていたMTGの時間と同等にできる2週間をリズムとすることにしました。
最近はステークホルダーとのコミュニケーションやデモを見ることの重要性をチームが感じ始めてきているため、いずれ1週間に変更ということもあり得るかもしれません。
プランニングMTGの進行を見直す
これまでは、やることの共有とタスクアサインの決定、定期リリースのためのリリース計画の確認を行なっていました。
それを、Sprint PlanningとしてSprint Goalの決定とSprint Backlogの作成、完了条件(Acceptance Criteria: AC)の認識合わせを行うように変更しました。
ステークホルダーの召集もアジェンダには入れていましたが、当初はあまり召集されていませんでした。直近のスプリントで一度招集し意義が感じられたことで、最近のスプリントでは積極的に召集が検討されるようになってきています。
Sprint Review / Retrospective
「週次のやったこと共有」「週次or隔週の障害振り返り」「月次の数値共有」「月次のKPT」と、レビュー・振り返りの要素が分散した状態で運営されていました。そこで、「リズムを作り、学びを次に活かしやすくする」ために、Sprint Review / Retrospectiveとして統廃合を行いました。
Reviewでは新たに「ゴールの共有」「できなかったことの共有」「デモ・ステークホルダーの召集」が盛り込まれ、振り返りはKPTからYWTに形を変えつつ「ネクストアクションを必ず出す」ことに重きをおくようにしました。
印象に残っていること
「スクラムのエッセンスを盛り込む」と表現しているように、比較的ゆるめにフレームワークを適用しています。
そんな中、粒度が大きいPBIに取り組むときに「折角やるのだから守破離の守でMVPを意識した分割をしよう」というムーブメントが発生したことが印象に残っています。
AWS のコスト最適化について
チーム運営とは関係ないため本記事では割愛します
QAの振る舞いの変更
これまでは、コードレビューが終わったものをQAが品質保証し、保証されたものがリリースされるというフローでした。
これを、以下のように変更しようとしています。
- プロダクトにとって重要な機能を定義し、重要な機能はQAが品質保証をし、リリースする
- 重要な機能以外は、基本的にはエンジニアが品質保証をし、リリースする
- QAの基本的な振る舞いを次のように定義する
- 完了条件に関与し、品質保証の観点が盛り込まれている状態にする
- コードレビューに関与し、品質保証の観点でフィードバックをする
- ゆくゆくは、PdM/エンジニアが品質の知識を身に付け、QAではなくチームが品質を保証できるようにする(QA Enabling)
現状はまだまだ道半ばですが、少しずつでも前進していきます。
DROBEのリリースフローの変更について
手動で作業が必要な箇所を一部自動化し、リリースにかかる時間を短縮しました。
また、直近Four Keysの計測が始まったこともあり、これまでは定期リリースだったものが、ある程度まとめてリリースになり、現在ではリリースできる状態になったら順次リリースが行われるようになっています。
今後は「変更のリードタイム」を改善していく予定です。Sprint Backlogでのタスク分解にトライしつつ、放置気味だったPRのCloseや古くからあり対応に苦慮していたタスクのリリースに向けた作業に取り組んでいます。
MLが関係する開発のプロセス
MLの領域は専門性が高く、透明性が担保しづらい(実験や実装が特定個人に閉じてしまい、他のメンバーが内容を把握できていない状態)という課題がありました。
また、MLと機能開発のチームがゆるく分離しており、活動の母体が2つあるような状態となっていました。これにより、何もしないと足並みを揃えることが難しいという課題もありました。
これらの課題を緩和すべく、以下の変更を加えました。
- MLの活動リズムも2週間にし、タイムボックスの終わりにReview(MLエンジニアの活動状況や実験結果の共有)とRetrospective(MLにまつわるプロセス・システムを眺め、改善することがないか探る)を実施することにした
- Discoveryという概念を作り、機能開発との連携に活用するようにした
- 実験の状況(実験したい項目がいくつあり、どれに取り組んでいて、どのPBIと関係しているのか)が分かりやすくなる
- 実験で明らかにする観点が明確になる
ReviewにはPdMも招待しており、MLによってできることの理解やPdMが困っていることの把握といった相互理解を育むことも期待しています。
私が入社する以前にはML開発チームがステークホルダーとコミュニケーションを取りながらMLで何をやろうかというディスカッションをしていたらしいですが、最近では実施されなくなってしまっていました。
MLとビジネス/ユーザー価値を繋げていかないと価値の種が枯渇してしまうため、本活動をブラッシュアップさせていくことが急務だと感じています。
ビルドトラップを回避するため、Story Issueのテンプレートとフローを変更する
MLの活動をきっかけに、Discoveryの概念を機能開発チーム(以下スクラムチーム)全体に適用することにしました。
端的に書くと、「以下の観点を満たさないものはProduct Backlogに積まないので、Discoveryという過程を経てそれらを明らかにしてね」ということを強制するようになりました。
- ビジネス的な価値(複利の効くInvestの削減 or Investを上回るReturn)があるか
- ユーザーにとって価値があるか
- ユーザーが使い方がわかるか
- 現実的な工数での実現が可能か
Issue(当社ではGitHub Issueを用いている)のテンプレートに4つの観点をチェックボックスとして追加し、POは4つの観点が満たされていると判断したらPBIに優先順位をつけてProduct Backlogに積むようにしています。
まだ試行錯誤中のため少々Product Backlogが心許なくなっていますが、協力し乗り越えていきたいと考えています。
Sprint Goalに関する変更
Sprint Goalを廃止する
直近のSprint Planningの中で、「このPBIをやることがSprint Goalと同義であるため、あえて抽象的なゴールを作ると混乱するのではないか？」という課題提起があり、それに対する明確な対案が見出せなかったことから、Sprint Goalを廃止したスプリントに取り組んでみることにしました。
PlanningのMTGの中で「Sprint Goalを合意する」アジェンダに要する時間がそれなりの比重となっていたことも、意思決定を後押しした要素となっています。
Sprint Goalを導入する
Sprint Goalの無いスプリントに取り組む中で、「Sprint Goalがないことの課題 / あることのメリット」の言語化が進みました。その説明をし、結果的にSprint Goalは設けようという結論になり、最近のスプリントからはゴールを考えるようになっています。
- 優先順位としてはROIが高いものが上がりやすく、1つの施策(タスク)で大きい効果が見込まれるもの(Returnが高く、Investが低いもの)から順に着手することになりがちである
- Sprint Goalというテーマがあることで、相対的にROIが高くない(Return > Investであるのは必須)タスク群に取り組むことも可能になるのではないか？
- ゴールが無いことで「ゴールを達成するためにこれをやろう」ではなく「このタスク群を終わらせることがゴール」になってしまい、創意工夫の余地がなくなってしまう
- 変化に弱くなってしまう
- 不確実性を取り込むことが困難である
最近好きなスライドがあって、ここに書かれている考え方も参考にしました。
今後は「Sprint Goalを合意するために全員が集まる時間をどう短縮するか」と「Sprint Goalを達成するためのタスク群を如何に早く作り込むか」という課題に向き合っていきます。
さいごに
ADRを眺めながら、この2-3ヶ月を振り返りました。
チームはまだまだ改善の真っ只中ですが、変化が起きていることや試行錯誤できていることをポジティブに感じています。
今後も自己管理されたチームを目指して改善を続けていきます。
