こんにちは！スタディサプリ TPM（Technical Product Manager）組織のマネージャーをしている@yuukiinoueです。
突然ですが、皆さんのチームでは「アジャイル開発」と「納期」の付き合い方に悩んだことはありませんか？
「うちのチームはスクラムだから、カッチリした納期はちょっと…」 「変化に強いのがアジャイルの良さなのに、期限に縛られたら意味ないのにな…」 アジャイル開発を実践していると、一度はこんな声が聞こえてくるかもしれません。実際に私もそんなことをよく思っていました。
私たちスタディサプリの開発チームは、多くがスクラムを採用してプロダクトを開発しています。しかし、もちろんビジネスである以上、大規模な機能リリースや法改正への対応など、明確な「納期」が設定されるプロジェクトも存在します。特に教育業界は4月の新年度にあわせてプロダクトをリリースすることも多く期限に追われることがしばしばあります。
そこで今回は、アジャイルな開発チームが、納期のあるプロジェクトとどう向き合っているのか、その裏側にあるプロジェクトマネジメントの考え方と、それによって引き出されるアジャイルの強みについてご紹介できればと思います！
明確な「納期」が設定される以上アジャイルでもプロジェクトマネジメントは必要不可欠
まず、大前提の考え方として「納期」が設定されている以上どんな開発手法であれ、プロジェクトマネジメントは必要不可欠だと考えています。
そもそもプロジェクトとは、 「独自のプロダクト、サービス、所産を創造するために実施される有期的な業務」 とPMBOK®*1では定義されています。つまり、始まりと終わりがある活動です。
スクラムは「どうやってプロダクト価値を最大化するか」に長けたフレームワークだと思いますが、複数のチームが関わり、特定の期日までに価値を届ける、という大きな枠組みの中では、プロジェクト全体を俯瞰し、チーム間の認識を統一するための羅針盤がどうしても必要になります。
そこで活きてくるのが、PMBOK®で語られている「ベースライン」という考え方です。
計画の拠り所となる「ベースライン」の要素
私たちは、プロジェクトの開始段階で、以下の3つのベースライン*2についてプロジェクトメンバー間で共通認識を持つことを重要視しています。
- スコープベースライン（何を作るか）
- スケジュールベースライン（いつまでに作るか）
- コストベースライン（どれくらいかけて作るか）
これらのベースラインを合意することで、「いつまでに、何を、どれくらいで達成するのか」というプロジェクトの全体像が明確になります。またベースラインをもとに進捗管理や変更管理を行うことでチーム間の認識を統一し、プロジェクトのモニタリングが可能となり、安定的に推進することができます。
プロジェクトマネジメントを支えるツールたち
こうしたプロジェクトマネジメントとアジャイル開発の両立を、私たちは気合だけで行っているわけではありません。適切なツールを活用してプロジェクトの状況を可視化することで、円滑な進行をサポートしています。
Jira*3：開発タスクと進捗の可視化 開発するプロダクトの要件をチケットとして細かく分解し、進捗を管理しています。各チケットのステータスを見れば、誰が何に取り組んでいるかが一目瞭然です。 また、バージョンレポートなどで対象のバージョンが予定通り進捗しているかを確認したり、タイムライン機能でプロジェクト全体のスケジュールとマイルストーンを可視化し、計画したベースラインと実績を比較したりすることで、健全なプロジェクト運営に役立てています。
バージョンレポート（例） Confluence*4：認識齟齬を防ぐドキュメント 細かい仕様のロジックや、会議の議事録など、チームや関係者間での認識合わせが必要なドキュメントはConfluenceに集約しています。口頭での確認だけでなく、ドキュメントとして残すことで、「言った言わない」問題を防ぎ、スムーズな意思疎通を促進します。
プロジェクトマネジメントとアジャイル開発の両立
「ベースラインを引いてしまうと、アジャイルの良さが失われるのでは？」と思う方もいるかもしれませんが、明確なゴールと制約があるからこそ、アジャイル開発の持つ本来の強みが最大限に引き出されると考えています。
1. 状況に合わせた柔軟なプロダクト改善
プロジェクトマネジメントで納期というゴールをしっかり守りつつ、ゴールへの道のりは柔軟に最適化できる。これが最大のメリットです。 スプリントごとに動作するプロダクトを触りながら、ビジネスサイドと「もっとこうした方がユーザーは喜ぶのでは？」といった対話が生まれます。ベースラインの範囲内であれば、こうした改善を積極的に取り入れながら、プロダクトの価値を最大化してゴールを目指すことができます。
2. 「想定外」をなくすコミュニケーション
アジャイル開発では、仕様書の作成に時間をかける代わりに、「動作するソフトウェア」をコミュニケーションの中心に据えます。
これにより、スプリントレビューなどの場で、開発の早い段階から動作するプロダクトを用いての認識合わせが可能です。結果として、リリース直前になって『思っていたものと違う！』という悲劇が起こりにくくなります。
もちろん、ドキュメントを全く作らないわけではありません。リリース後の保守運用に必要なものや、チーム間の認識合わせを円滑にするための図や細かいロジックを表現したものなど、お作法として作成するのではなく、「本当に価値を生むドキュメント」に絞って作成することで、チームはプロダクト開発という本質的な作業に集中できると考えています。またドキュメントなど必要なものはレトロスペクティブなどで振り返りを行い、チームとして適宜改善を行っていきます。
チーム横断を円滑に進めるための工夫
スタディサプリのような大きなプロダクトでは、複数チームが連携して開発することも日常茶飯事です。こうした依存関係のあるタスクをスムーズに進めるため、私たちは以下のような点を特に意識しています。
- API仕様などのシステム間の連携仕様は関係者で集まりレビュー会を実施する
- 仕様変更が発生した際は、依存するチームへ速やかに、かつ丁寧に共有する
- システムテストや移行作業など複数チームで同時に行うタスクは、共同で計画を立て、可能な限りリハーサルを行う
一つひとつは地道なタスクですが、こうした丁寧なコミュニケーションが、チーム横断での開発を支える潤滑油になっています。
さいごに
アジャイル開発とプロジェクトマネジメントは、対立するものではありません。 むしろ、しっかりとしたプロジェクトマネジメントの土台があるからこそ、アジャイルチームは安心して、変化に強く、しなやかに価値を届けられるのだと考えています。
この記事が、同じように開発の進め方に悩む方々にとって、少しでも参考になれば嬉しいです。 最後までお読みいただき、ありがとうございました！
