この記事は NTTコムウェア Advent Calendar 2022 14日目の記事です。
背景
- スクラムマスタ―として、いくつかのエンタープライズ企業でアジャイルなプロダクト開発をサポートしたり、勉強会などで他のチームの話を聞いていると、組織的な制約や文化などが障壁となり、「価値があるものを早く提供する」理想的な組織像にはなかなか近づけないなと感じます。
- むしろ、あえてそうしているんじゃないかとすら思えるほど、価値があるかどうかわからないものを長い時間かけて検討・開発していることが多くある気がします。（個人の主観です）
- そこで、アジャイル開発としてはアンチパターンと呼ばれるものを、「価値があるかどうかわからないものを遅く提供する」ためのベストプラクティスとしてまとめてみたら面白いんじゃないかと思い、今回の記事を書きました。
3つのプラクティス
私の考える最も重要なベストプラクティスは以下です
1. 詳細な”要件”を全て決めて、全て設計するまでは開発は一切しないようにしましょう。
2. 多くの承認プロセスを設けましょう
3. チームを機能別にたくさん分割しましょう
1.詳細な要件を決めて全て設計するまでは開発は一切しないようにしましょう
- スケルトンベースのものは作れるからといって開発を始めてしまうと、ショボいものしか提供できないのでやめましょう。たくさんの機能をずーっと長い時間作り続けている方が作っているものの価値があるかどうかもわからないまま過ごせます。
- 入念に検討と計画を行い、特に手戻りは”絶対に"起こさないように気をつけることで、多くの時間を検討に費やすことができるため、開発の着手を遅らせ、結果としてリリースを遅らせることができます。
2.多くの承認プロセスを設けましょう
- 開発着手前に「顧客へのヒアリング活動承認」、「スコープ&チーム活動承認」、「設計着手判断」、「設計承認」、「開発着手承認」などできるだけあらゆる活動に対して上位者の承認を得るようにしましょう。そうすることで承認のための準備・調整に時間を割くことができ、価値を生み出す一次ニーズへの対応稼働をなくすことができます。
- できるだけ承認者を複数用意した合議制にし、スケジュールはそれぞれ別の会議で埋めておくことが望ましいです。そうすれば承認会議をはるか先に設定できるので、開発着手等の承認後の活動をさらに遅らせることができます。
3.チームを機能別にたくさん分割しましょう
- 1つの小さなプロダクトをリリースするまで、できるだけ多くのチームが関わるようにしましょう。そして、各チームが複数のプロダクト開発を兼務する状態にすることで、リリースまでの時間を長くすることができます。
- さらに、各チームがいまなにをやっているのか、余力があるのかどうかをできるだけ不透明にしておくとボトルネック特定ができなくなるので、より効果的です。
さいごに
- 私は、「価値があるものを早く提供する」理想像を実現したいので、今回まとめた"ベストプラクティス"はひとつも採用したくはないです。
- ただ、いざ改善していこうとすると組織構造上の問題や文化などすぐにはどうにもならない制約がつきまというまくいかず挫折しそうになります。
- いまは、少しずつやれるところから変えていくしかないと割り切って、試行錯誤しながら理想像の実現に向けて改善を進めています。
- 何を達成したいのか次第ではありますが、今回まとめた"ベストプラクティス"に対する"アンチパターン"を踏みまくってもらい、少しでも素早く市場に価値を届けられるようなチーム・組織が増えることを祈ります。