[XP]週次サイクル・四半期サイクル・10分ビルドの定義と運用事例(2024 Advent Calendar 19日目)

@Panda_Program

この記事は私をシニアエンジニアにしてくれた「真のアジャイル開発」体験記の19日目の記事です。このアドベントカレンダーは「ある機能開発チームでスクラム, XP, DevOps を一度に実践したら真のアジャイル開発ができた」という内容です。執筆者は全てプログラミングをするパンダです。

週次サイクル・四半期サイクル・10分ビルド

本記事ではXPの「週次サイクル」「四半期サイクル」「10分ビルド」の定義と自分たちのプロジェクトでの運用を紹介します。

週次サイクルの定義

週次サイクルとは、イテレーションのことを指します。これは週の初めに1週間分の計画をまとめるプロセスです。この中で、先週の振り返りを行い、顧客にストーリーを選んでもらい、選ばれたストーリーをタスクに分解します。

一般的にサイクルは月曜日に始めますが、火曜日や水曜日に開始する場合もあります。ストーリーに取り組む前には受け入れテストを記述し、そのテストが通ることを目標に週内の実装を進めます。サイクルが1週間ごとであるため、毎週新しい取り組みを試すことができる点も特徴です。

ストーリーは優先順位順に並べ、一番上にあるものから着手します。誰がどのストーリーを担当するかはあらかじめ決めても良いですし、当日に決める方法でも問題ありません。一人で作業する場合でも構いませんが、ペアで作業を行うと互いの専門性が発揮されてより良い成果が期待できます。

計画作りは顧客に対する直接的な価値を生み出さないため、必要な無駄の一つと考えられることがあります。このため、計画作りにかける時間は徐々に減らして効率的に進めることを目指しましょう。

週次サイクルの運用

XP本を読むと、週次サイクルはスクラムで言うところのスプリントレトロスペクティブ、プロダクトバックログ作り、プロダクトバックログリファインメント、スプリントプランニングに相当します。

XP本では顧客にストーリーを選んでもらうことになっています。しかし、たとえばtoCの自社開発などで顧客がチームに直接参加していない場合、プロダクトオーナーを顧客の代表とみなして着手するストーリーの優先順位を決めてもらうと良いでしょう。

自分のいるチームではイテレーションを2週間単位で進めていました。火曜日にスプリントレビュー(スプリントの終わり)、水曜日にスプリントプランニング(スプリントの始まり)を実施しています。月曜日が祝日になることが多いため、重要なスクラムイベントが月曜日に重ならないようにしているのです。

受け入れテストを書いてから内部実装を進める手法は、振る舞い駆動開発(BDD)の発明だと思っていました。しかし、XP本の第二版でこのアプローチについて言及されているためBDDの専売特許でもないのだなと気づきました。

自分がいるチームでは、TDDを用いて信頼できる小さなクラスをボトムアップで設計・実装し、それらを組み合わせることでユーザーストーリーを実現しています。ストーリーの完了条件を満たしたらプロダクトオーナーに手動で受け入れテストを実施してもらいます。手動の受け入れテストがパスすれば、その手順やデータセットを受け取って同様のテストケースの自動テストを作成しています。このように、受け入れテストを後から自動化し、デグレ防止のためのリグレッションテストとして利用しています。

なお、自分たちが開発していた機能はフロントエンドで複雑な操作を必要としないので、バックエンドのロジックの確認が中心でした。そのため、コントローラーに対するテストを受け入れテストとしていました。一方、フォーム入力などフロントエンドで複雑な操作が必要な場合には、受け入れテストはコンポーネントテストやヘッドレスブラウザを使った自動テストを選択していたでしょう。

四半期サイクルの定義

四半期サイクルとは、3ヶ月先までの計画を立てることを指します。このサイクルでは、四半期に一度、大きなゴールやその達成に向けたプロジェクトの進捗、そしてチームでの振り返りを実施します。

四半期ごとにテーマを設定し、その四半期ではそのテーマに沿ったストーリーを選びます。3ヶ月に一度は組織やビジネスにおけるプロジェクトの位置付けや目指す方向を開発チームと確かめ合うというプラクティスです。週次サイクルを続けているとチームが近視眼的になってしまうため、自分たちの目標と届ける価値を定期的に確認することが重要なのです。

四半期サイクルの運用

四半期サイクルの運用: ロードマップを作る

四半期サイクルというプラクティスはプロダクトのロードマップを作ることでスムーズに実践できます。

プロダクトロードマップは、1年先にプロダクトがどのような機能を備え、顧客にどのような価値を提供するかを、大まかなタイムラインで示したものです。このロードマップを作成することでチームの目線が揃い、チームメンバーが望む未来を実現しやすくなります。その結果、ふとした時に「今自分が取り組んでいることは何の役に立つのだろう」と自問することがなくなります。

ロードマップを作る際には3ヶ月スパンで区切りをつけると良いでしょう。もちろんある価値を実現するために3ヶ月以上かかっても構いません。3ヶ月のスパンでは作り切るのが難しいと感じる機能も、1年後には実現できるだろうと思えることも多いはずです。

プロダクトロードマップは開発チームだけでは作れません。ビジネス側のメンバーやプロダクトオーナーなどいろんな人を巻き込んで議論し、様々な情報を集約して優先順位をつけて作り上げる必要があります。ロードマップを作るにあたり、社内の多様なメンバーが長期的な視点に立って本当に顧客に届けるべき価値を議論することができるのです。

この議論では、3年かかりそうな壮大なアイデアも歓迎しましょう。チーム全員でブレインストーミングを行うと良いでしょう。最終的には、ユーザーがそのアイデアを望むかどうか、また価値を最大化できるかどうかを、プロダクトオーナーを含めたチームで話し合い、取り組む優先順位を決めます。

ロードマップという制作物は計画なので変更される可能性があります。しかし、ロードマップを作る際に関わってくれたメンバー全員が、より長期的な視点を持って顧客に届けるべき価値を議論するという点を考慮すると、議論の結果出来上がったものよりこの議論のプロセスこそが全員の目線を揃えることに役立ちます。チームとしてより深いレベルでの一体感を醸成するからです。

四半期サイクルの運用: 開発チームもビジネス側の視点を持つ

ただし、時間には限りがあることや、経営陣もプロダクトを通じてビジネスを成長させることを考えているため、チームで考えたことが全て実現できるわけではないことを念頭に置いておく必要があります。もし趣味でプロダクトを作っているのであれば自分で全て優先順位を決められますが、仕事としてプロダクトを開発する以上、ビジネス側の視点を忘れないようにすることが大切です。

ビジネス側の視点では、上場企業であれば経営陣が投資家に示している数字や目標を達成するための施策と関連しています。経営陣は、投資家に約束した目標数値を達成し、自社の企業理念を実現するために、チームにプロダクトの開発を求めています。チームとしては目の前の仕事を完了させることでも達成感を得られますが、それに加えて、自分たちがより大きな目標を達成するために会社から必要とされていることや、自分の仕事が社会の役に立っていることを感じられることが、仕事へのモチベーションにつながるでしょう。

四半期サイクルにおいては、次に取り組む仕事が組織にとってどのような意味を持つのか、社会にどのようなインパクトを与えるのか、そして具体的にユーザーが喜ぶこと、つまりユーザーにとっての価値をチームで話し合う時間を設けるのも良いかもしれません。

もちろんロードマップを作る以外にも四半期サイクルというプラクティスを実践する手段はあります。四半期サイクルの進め方については、会社やチームごとに独自の方法があるでしょう。しかし、どのチームにも共通して言えるのは、少なくとも将来についてしっかりと考える時間を設けることが重要だという点です。

10分ビルドの定義

10分ビルドはシステム全体を自動でビルドし、すべてのテストを10分以内に実行させることを目指すプラクティスです。もしビルドに10分以上かかる場合は、10分以内に収まるように最適化を行いましょう。ビルドとテストに10分以上かかるとフィードバックサイクルを短くすることが難しくなるためです。

ビルドとテストのプロセスがまだ自動化されていない場合は手動でのビルドをやめて、まずは自動化を目指してください。ビルドを最適化する方法としては、システムの変更が加わった部分だけをビルドする仕組みを導入したり、変更によってリスクが高まった部分のテストだけを実行することなどが考えられます。

10分ビルドの運用

10分ビルドに関する話題は、CIをいかに素早く実行するかというテーマに通じます。ビルドやテストの実行時間が長くなるほど、ストーリーのリリースにかかる時間が延びてしまい、ユーザーに素早く価値を届けることが難しくなります。

自分のチームでは幸いにしてCI環境がすでに整備されていたため特に大きな課題はありませんでした。ただ、「元からできていました。終わり」では味気ないので、ビルドやテストを高速化するためのいくつかのTipsをご紹介します。

ビルドやテストを高速化するには、実行を並列化したり、変更があった部分だけを実行する仕組みを導入するのが効果的です。例えば、筆者が友人から聞いた話では、フロントエンドのビルドを並列化したり、ビルドツールをより高速なものに差し替えたり、独自スクリプトを作成して変更箇所だけをテストすることで効率化を実現したとのことです。

ただし、テストに関しては注意が必要です。実行すべきテストをスキップしてしまい、本番環境にバグが混入してしまえば、いくらテスト時間を短縮できたとしても本末転倒です。

ここで注目したいのが、特にテスト分野でAIを活用する手法です。AIを用いて本当に必要なテスト箇所を特定し、ソフトウェアテストにかかる時間を削減することを目指しているのが、Launchableというスタートアップです。2020年に設立されたこの企業は、すでに大手企業に導入されており、年間何千時間から何十万時間ものテスト実行時間を削減した実績があるとのことです。

Launchable技術部一周年+仲間募集

次回は継続的インテグレーションの定義と運用を紹介します。

Happy Coding 🎉

パンダのイラスト
パンダ

記事が面白いと思ったらツイートやはてブをお願いします!皆さんの感想が執筆のモチベーションになります。最後まで読んでくれてありがとう。

  • Share on Hatena
  • Share on Twitter
  • Share on Line
  • Copy to clipboard

advent-calendar」カテゴリの投稿