はじめまして、フリーランスWebエンジニアでReproさんのお手伝いさせていただいているTONYと申します。 ReproではLeSSという大規模スクラムのフレームワークを採用し、開発を行っております。僕が所属している機能開発チームでも、スプリント内で取得したPBIのゴール条件をきちんと満たすために、日々バーンダウンチャートとにらめっこしながら、きれいに消化すべく試行錯誤しております。

その中で今日は安定してバーンダウンチャートを消化するためにチームに今まで提案した取組みを一部紹介しますので、ご参考になればと思います。

そもそもLeSSとは何か？

f:id:galepilot:20191113201606p:plain

簡単に言ってしまうと、1プロダクトのプロダクトバックログアイテム（以下、PBI）を複数の開発チームが取得し、出来上がり次第、リリースを行なっていく手法です。

LeSSの概要は以下のURLが参考になります。 https://slide.meguro.ryuzee.com/slides/80#page_top

いきなり結論から話すと

僕のチームで以下のことを心がけてスクラム開発に取り組んでいます。

合わせよう！みんなの前提知識！
論点洗い出しと認識合わせはお早めに！

合わせよう！みんなの前提知識！

よくある問題

Reproのプロダクトはサービスローンチからすでに約5年経っており、様々な機能がリリースされてきました。その中で既存機能の改修案件を行う際、開発やテスト段階でメンバーの誰も把握していない細かい仕様が発覚し、手戻りや追加の開発作業が発生することがよくあります。そして、どんどんバーンダウンチャートの実線が離陸を始め、大空に飛びだっていくのです（涙）

f:id:galepilot:20191016175734j:plain

なぜ発生するのか？

メンバーの間で既存機能の仕様に対する理解にバラツキがあるからです。僕がいる機能開発チームはエンジニア3名、デザイナー1名の構成されていますが、入社して1年経っていないメンバーがほとんどを占めています。そのため、Reproの昔からある既存機能の細かい仕様を追いきれていないことがあり、開発やテストの段階で新たに考慮漏れが判明することがあります。

どう解決すべきか。

要件定義に入る前に既存仕様の把握をチームメンバー全員で行う取組みを行っています。具体的には以下のとおりです。

自社の公開資料を読む会を実施する。

Reproではクライアント向けに仕様をまとめたReproDocsというドキュメントを公開しています。 Reproの新機能がリリースされるたびにこのドキュメントが更新されるフローになっているため、おおよその機能がこのドキュメントに記載されており、仕様把握に利用しています。僕のチームでは、このドキュメントを必要に応じて、要件定義前にみんなで読むようにして、機能の仕様確認を行い、更にはユーザーがどのように利用するのかのユースケースやその機能がどのような価値をユーザーに届けているかの認識をチーム内で合わせます。

みんなで既存仕様を直接さわって理解する。

ドキュメントを読むだけではわからない細かい仕様や画面の挙動に関しては、リファインメント時に検証環境にて実サービスをみんなでさわります。できるだけ、本番環境に近いデータ（※1）を利用し、既存仕様の把握に努めます。必要に応じて、全員でコードリーディングを行い、git blame でコードを書いた本人が在籍している場合は、設計意図を聞いたりして、改修時のコスト感の認識を全員であわせます。

こうすることで、既存仕様をコードレベルで確認し、正しく改修時の制約条件（どれくらいコストが掛かりそうか、等）を把握し、要件定義や設計の前提知識をメンバー間で揃えるのと同時に、極力、既存仕様の把握漏れを無くすようにしています。

※1 ... もちろん、センシティブな情報がマスクされた状態のデータです。

論点洗い出しと認識合わせはお早めに！

よくある問題

既存仕様について、メンバー間で認識を合わせた後に要件定義や設計を経て、開発に差し掛かる頃、以下のような理由でタスク消化に時間がかかるケースに見覚え無いですか？

実装が終わりある程度テストコードを書き終わった後に、PRのレビューを依頼したものの、その段階で設計の議論が白熱し、マージまで時間がかかってしまった。（最悪、実装がやり直しになるケースも）
プランニング2でタスクの見積りや切り方や雑で大きいために予想以上にタスク消化に時間がかかってしまう。
ドメイン名の認識がメンバー間でバラバラでみんな微妙に違うネーミングを行っており、統一するために修正作業が発生してしまった。

そして、どんどんバーンダウンチャートの実線が離陸を始め、大空に（以下略

なぜ発生するのか？

プランニング2のタスクを見積もる段階で要件定義や設計の曖昧な部分が残ったまま、開発のスプリントに突入するとよく事故るのかなと思っています。具体的にはスプリント中に改めて設計の曖昧な部分を詰めていくと想定外の実装が必要になり、タスク消化に時間がかかることが多くあると思います。

どう解決すべきか。

リファインメントで論点をなるべく先出ししよう！

僕のチームではリファインメントの段階で次のスプリントの要件定義や設計上の論点を徹底的に洗い出して、リファインメント内でできる限り決めるようにしてみました。次のスプリントのフェーズ次第で話す内容は変わりますが、概ね以下のとおりです。

要件定義が主な場合

既存仕様の把握、あるべき仕様の策定、外部要因や開発における制約、スプリントレビューでの検証したいポイント、等を議論します。また、リファインメント時点では、決められない不明瞭な部分がある場合はなにが決まれば明確にできそうかを明確にしておきます。

設計、開発が主な場合

要件に沿って、DB設計をどうするか、外部IFはどうするか、既存コードのどこを変更するか、等を議論します。設計に関しては、クラスやコンポーネントの粒度で議論し、必要であれば、ドメイン名も確定させます。

たたき台が必要な場合は、担当者が事前に調査して、資料にまとめてもらって、議論し、なるべくPRレビュー時に設計や議論をしたり、再設計による手戻りをしないように心がけています。

スプリント入る際は全員認識が揃っていること！

リファインメントで徹底的に論点を潰しておくと、プランニング2がかなりスムーズになります。なぜなら、要件定義や設計の認識が全員で合っているので、あとは細かくタスクに分解するだけだからです。開発の場合はタスク粒度がクラスやコンポーネント単位で分かれることが多いです。もし、プランニング1に想定していたPBIと違うものが入ってきた場合は、プランニング2でリファインメントをします。大事なのは、スプリントに入る際に設計、実装の方針で全員の認識が揃っていることです。

余談ですが、設計の認識をあわせていて、かつ、開発タスクをクラスやコンポーネント単位で切り出していると開発メンバーが体調不良で急遽休みが発生した際も、他の開発メンバーが設計方針を把握しているので、フォローに回ったり、フレキシブルな対応ができるようになります。

チェックリストで漏れを防ぐ！

頑張って論点を潰したつもりでも、スプリント中に考慮漏れが出てきたりするケースは結構あると思います。僕のチームではそのケースを少しでも減らすためにリファインメントにチェックリストを設けて、確認するようにしました。

（一例）Refinement checklist
- 自チームで取る予定のPlanning1のPBIとゴール条件が設定、更新されているか。
- Planning2で、論点無くタスクに分解可能な状態であるか。
- ドメイン名、設計方針の認識はチーム全体で議論し、（あとで揉めないように）共有と納得ができているか？
- 開発前後でサービスとしての機能や与えるUXがどのように変化するのかを全員理解しているか。
- 他チームが並行して開発している機能の実装部分がバッティングしている箇所はあるか。ある場合はその調整を終えているか。