研究開発部門でのプロダクトバックログの育て方
はじめに
こんにちは、メタルは全てを解決するです。ナビタイムジャパンでVPoEを担当しています。
当社では研究開発にスクラムで取り組んでいるチームが多数存在しています。複数のチームを観察する中で見えてきた、「そもそも実現できるかわからない」ものを取り扱う研究開発でプロダクトバックログを育てる勘所についてまとめました。
研究開発部門でスクラムを採用したもののプランニングに苦労している方の参考になれば幸いです。
技術的スパイク
研究開発部門ではその特性上、実現方法が明らかになっていないものを扱う機会が多くなります。そのため、明示的に顧客価値を生み出す開発の前段階、スパイクが必要となっていきます。そのため、研究開発チームのプロダクトバックログには技術的スパイクを扱ったプロダクトバックログアイテムがいくつも含まれることになります。
スパイク
リリース可能なプロダクトを作るのではなく、質問に答えたり情報を収集したりすることを目的とした作業。 開発チームが技術的な質問や設計上の問題を解決するための実際の作業を行うまで、見積りができないようなプロダクトバックログアイテムが出てくることがあります。 解決策は、「スパイク」を行うことです。 目的は、質問に対する回答やソリューションを見つけることです。
2023年8月にリリースされた「日陰ルート」を例に考えてみます。
ユーザー目線で一番コアなプロダクトバックログアイテムは以下のようなものになります。
ユーザーとして日陰を優先した経路を選択できる
いざこのユーザーストーリーを実現しようとすると、開発前にはわかっていないことがたくさんありました。
時間ごとに変化する日陰情報をどのように算出するか
都度計算するべきか、事前に計算しデータとして保持しておくべきか
日陰を考慮した探索は実用に耐えるレスポンスタイムで返却できるのか
なので研究開発チームにおいては、こういったわかっていないことを明らかにするためのスパイクの取り組みが重要な位置を占めているのです。
技術的スパイクのDoD(完成の定義)
含めるもの
■単体テストの通過
研究開発は、実現可能性が明らかになっていないという意味において本質的複雑さを含有します。ただでさえ複雑な対象を扱うので、なるべく偶有的複雑さは取り除いておきたいところです。
やったー狙い通り動いた！と思ったら実は実装をミスっていて、たまたま正しいっぽい挙動をしていたときの絶望感といったらありません。
少なくとも想定通りに作ったものであることがわかるように、単体テストの通過はDoDに含めておきたいところです。
■プロダクトコード作成タスクの発行
試行錯誤を伴うスパイクのコードは、往々にして既存コードと整合が取りづらい、過度な依存性がある、など品質上の課題を抱えていることがあります。そして恐ろしいことに、そういった捨てるつもりで書いたコードがそのままプロダクトコードに取り込まれてしまうこともままあります。
そういった事態を避けるため、スパイク時に開発したコードはあくまでプロトタイプであるという共通認識を持ち、実現可能性が担保できたらあらためてプロダクトコードとして書き直すことが望ましいです。それを明示するために、チームメンバーが合意している方法でタスクを発行しておきます。
含めないもの
■コードレビュー
技術的スパイクを扱う場合、試行錯誤を伴うため大幅な設計変更を伴う可能性が高くなります。そのためこの段階で詳細なコードレビューを行っても、レビューした対象をそもそも破棄してしまう可能性があります。よって、コードレビューの通過をDoDに含めることはあまりおすすめできません。
■リグレッションテストの通過
研究開発を経て新しい挙動を付加した結果、それが破壊的変更となりリグレッションテストが通らなくなることがあります。プロダクトコードにマージしていく段階では考慮しなければならないポイントですが、実現可能性そのものを探索する段階ではリグレッションは評価したい対象には入りません。
スパイクオンリーのスプリントの是非
大前提として、スクラムで開発を行っているのであれば、スプリントごとに「リリース判断可能なインクリメント」を作ることが求められます。
スクラムではスプリントごとに「リリース判断可能なインクリメント」を作ると決められています。 それぞれのスプリントで、スプリントゴールを満たすように進めていかないといけません。 したがって、スプリントの時間をスパイクで埋め尽くしてはいけません。 以下の手順で進めていくとよいでしょう。
研究開発チームとしても、数スプリントに渡ってリリース判断可能なインクリメントが存在することは望ましくありません。なので基本的にはリリース判断可能なインクリメントは開発しつつ、スパイクも平行して進めることになります。
一方で、そのスパイクが研究開発チーム、そして会社にとって非常に重要であり、そのスパイクを乗り越えないことにはこの先のプロダクトの展開は考えられないというときには、スプリントゴールをスパイクの完了と同義にし集中して取り組むこともありえます。
ただ、その瞬間はスクラムとしては壊れてしまっている状況なので、長引かないよう注意が必要です。
持続可能な開発環境の維持
前述のように、研究開発部門においてはダイレクトにプロダクトそのものを開発する場合と比べてスパイクを扱う場面が多くなります。そうするとコードベースが荒れやすくなりますし、開発環境のアップデートなど研究開発と直結しない領域に手が回らなくなりがちです。そしてそれを放置してしまうと偶有的複雑さが増していき、ただでさえ複雑な研究開発に要らぬ複雑さを招いてしまいます。悲しい。
理想的には「プロダクトバックログに入れなくても常に庭の手入れがなされている」状況です。もしそういった理想的な状況なら問題ないですが、気がつけば庭が荒れてしまう状況であれば開発環境の維持活動自体をプロダクトバックログアイテムとして言語化し、必要に応じてスプリントバックログに含めていくとよいでしょう。いうまでもなく、スクラムマスターの勇気が求められる局面です。
インパクトを生み出し続ける
研究開発はその性質上、スパイクを扱う機会が多くなります。
スパイクをプロダクトバックログアイテムとして扱う場合、通常のプロダクトバックログアイテムとは異なるDoDを設定すると扱いやすくなります。
スパイクはインクリメントを生み出すものではないので、スプリントがスパイクオンリーになる状況は極力避けましょう。避けられない場合、集中的に行いなるべく短期間でスパイクオンリーの状況を脱出できるようにしましょう。
そして、難易度の高い研究開発を継続するために、自分たちの開発環境は手入れを怠らないようにしましょう。必要に応じてプロダクトバックログアイテムとして言語化することをおすすめします。
このようにしてプロダクトバックログを育て、プロダクトそのものを育てることで、世の中に対してインパクトを与える研究開発を持続することができます。技術の力で世界を変えていきましょう。