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

本記事は書籍の内容に基づいて執筆しているため一部内容が古くなっております。DevOpsに関する最新の情報はDORAの2024年版State of DevOps Reportをご覧ください。

DevOpsを紐解く

本記事ではDevOpsと書籍「LeanとDevOpsの科学」の考え方を紹介します。

DevOpsの一般的な定義をWikipediaを参考に見てみましょう。

DevOpsとは、開発担当者と運用担当者が協力し、ソフトウェアを迅速にビルドしテストする文化と環境により、確実なリリースを、以前よりも迅速に高い頻度で可能とする組織体制の構築を目指すこと https://ja.wikipedia.org/wiki/DevOps

この定義によると、開発者と運用者が協働してソフトウェアを高頻度に素早くリリースすることと言えるでしょう。さらに現代のスタートアップでは開発者と運用者は明確に分けられず、開発者が運用にも責任を持つことが当たり前になってきています。

LeanとDevOpsの科学の説明

「LeanとDevOpsの科学」はソフトウェアを素早く高頻度にリリースしてビジネスでも競争力を得ているハイパフォーマーの特徴を統計学の手法を用いて分析した結果を紹介した書籍です。

我々はソフトウェアデリバリのパフォーマンスを厳密かつ計測可能な方法で定義することができた

『進行中の作業の管理』から、『テストの自動化』に至るまで、どのプラクティスがどの程度デリバリのパフォーマンスを向上させるかに関する仮説が検証可能になったのである。加えて、チームの燃え尽き症候群（バーンアウト）やデプロイ関連の負荷（ペイン）など、我々が気にかけている懸念材料の測定も可能になった 「LeanとDevOpsの科学」 p.34

書籍の中では自分たちの組織のパフォーマンスを測定するための指標と、ソフトウェア開発において組織のパフォーマンスを向上させるために効果的なプラクティスが紹介されています。このプラクティスは書籍内でケイパビリティと呼ばれています。

書籍タイトルに科学という名前がついているように、書籍に書かれていることを実践すると、あらゆる組織でも再現性がある形でパフォーマンスを向上させられるというのがこの書籍の魅力です。ソフトウェア業界ではこれまでに様々なベテラン達が書いた様々な書籍やブログで様々なプラクティスが紹介されてきましたが、この書籍を読めば結局どれが真に組織のパフォーマンスを向上させるのかがわかります。

プラクティスを具体的に紹介する前に、Four Keysとケイパビリティについて説明します。

Four Keysとは

Four Keysとは、ソフトウェア開発チームのパフォーマンスを示す4つの指標です。Googleの「エリート DevOps チームであることを Four Keys プロジェクトで確認する」という記事から引用します。

• デプロイの頻度: 組織による正常な本番環境へのリリースの頻度
• 変更のリードタイム: commit から本番環境稼働までの所要時間（コードのマージからデプロイまでにかかる時間という解釈も）
• サービス復元時間: 組織が本番環境での障害から回復するのにかかる時間
• 変更障害率: デプロイが原因で本番環境で障害が発生する割合（%）

エリートとは、この指標の中で一番成績がいいグループを指します。エリートな組織は1日に何度もコードがデプロイされ、変更のリードタイムはわずか1時間以内、サービスの復元時間も1時間以内で変更障害率は0-15%です。

Four Keysを測定して継続的に改善することで組織のパフォーマンスが向上し、ビジネスの競争力を向上させることができるのです。エリートな組織は目標を達成する確率が他の組織の2倍高いとのことで、確かにチームがハイパフォーマンスであることが競争力の源泉となることが伺えます。

エリートチームが組織のパフォーマンス目標を達成または超える可能性は2倍であるとの調査結果を得ました （同ブログより）

ケイパビリティとは

ケイパビリティは書籍の中で以下のように説明されています。

ケイパビリティとは、ソフトウェアデリバリだけでなく、収益性や生産性、マーケットの占有率の向上といった形で示される組織自体のパフォーマンスを向上させるために欠かせないこと 「LeanとDevOpsの科学」p.12を元に作成

書籍では具体的に以下の24のケイパビリティが紹介されています。なお、2022年時点では27のケイパビリティになっていますが、2024年時点ではさらに増えているかもしれません。2022年の4-6月でチームで実践したときは書籍を参考にしていたため、ここでは書籍の分類に従います。

技術的なプラクティスは「継続的デリバリの促進効果が高いケイパビリティ」として以下のものが挙げられています。

• 本番環境の全ての成果物をバージョン管理システムで管理
• デプロイメントのプロセスの自動化
• 継続的インテグレーション（CI）の実装
• トランクベースの開発手法の実践
• テストの自動化
• テストデータの管理
• 情報セキュリティのシフトレフト
• 継続的デリバリ（CD）の実践

CIやテストの自動化などXPで紹介されていたプラクティスと被るものがあることが伺えます。相違点はXPがKent Beck氏の経験則であるのに対して、これらのケイパビリティは統計学的に組織のパフォーマンス改善に効果があると示されたものであるということです。

さらにこれらのケイパビリティが組織の何に影響を与えるのか、下記の相関図で示されています（図は書籍を元に作成）。

チームや組織のパフォーマンスを向上させるためには一筋縄ではいきません。「リーン思考」や「組織文化」もパフォーマンスに影響があります。これらはチーム内で改善できないものもあります。

例えば「負担の軽い変更承認プロセス」というケイパビリティは、コードのマージに上長の承認が必要で、その承認には1週間ほどかかるという会社の場合、チーム内部で改善することは不可能でしょう。マネージャーや役員などもっと多くの人を巻き込む必要があるからです。

忘れないで欲しいのは、「ハイパフォーマンス」とは購入したり、真似したりできるものではないという点である。 自信のケイパビリティを高めつつ、自チームや自組織の現況や目標にしっくりくる道を模索する必要がある。 そして、これには絶え間ない努力、投資、集中、時間を要する。 同上。p.233

チームのパフォーマンスを向上させてビジネスで競争力を得るためには、Four keysを計測しつつエリートを目指して地道に改善を続けていきましょう。

次回は継続的デリバリの促進効果が高いケイパビリティの詳細を紹介します。

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

継続的インテグレーション

本記事ではXPの継続的インテグレーションと自分たちのプロジェクトでの運用を紹介します。

継続的インテグレーションの定義

ソフトウェア開発において、変更箇所のテストと統合（インテグレーション）はタイムリーに完了させることが理想的です。統合に時間がかかれば、それだけ予期せぬコストが増加してしまうからです。現代的な開発ではCI環境を整備するのが当たり前になっているため、「XPではCIをやろうと主張しているんだ」といっても目新しさはそれほどないでしょう。しかし、温故知新で原点に立ち返ることで読者の方にとって何か新しい発見があるかもしれません。

継続的インテグレーション（CI）におけるビルドとテスト結果の確認には、非同期と同期の2つのアプローチがあります。どちらの場合もコードをプッシュしたことがトリガーとなって実施される点は共通していますが、非同期の場合は結果がメールやSlackで通知され、同期の場合は結果が出るまで画面を見て待つ形になります。

Kent Beck氏は同期的な方法を好むそうです。その理由は、ペアプログラミングの相手と一緒にCIの結果を待つ間に振り返りを行えるからです。この待ち時間に「これまでどんな作業をしたのか」「もっと良い方法はなかったか」などを二人で話し合うことができます。

一方、非同期の場合は結果を待つ間に別のタスクに着手することが多いです。しかし、CIでビルドやテストが失敗した場合、元のタスクを再び思い出すためにコンテキストスイッチが発生してしまいます。コンテキストスイッチのコストの重さは侮れません。頭が切り替えられないと作業の効率が低下する可能性があります。この懸念は同期的な確認方法で回避できます。

インテグレーション（統合）を実施した後は必ずデプロイまでやり切ることが重要です。これにより、統合の成果を確実に活用する流れを作ることができます。

継続的インテグレーションの運用

GitHub Actions の登場によってCI環境の整備がより身近で簡単になりました。自分のチームではCircle CIとGitHub ActionsによってCI環境が既に整備されていたため、特筆すべきことはあまりありません。そこで、ここでは一般的な話としてCIについて触れてみます。

CIには大きく2つの側面があります。一つはコードを統合すること、もう一つは自動でビルドとテストを実行することです。

新しいコードを書いても長時間統合しなければ、そのコードが問題なく動作するかどうかが分からなくなります。同僚が同時に開発を進めていれば、コードのコンフリクトが発生するリスクも高まります。

さらに、ビルドとテストを自動化しない限り、新しく書いたコードが信頼できるかどうかを判断するのは困難です。特に、コードベースが大きくなり、関心ごとや依存関係が適切に分割されている場合、ローカルで全てのテストを実行する開発者は少ないでしょう。多くの場合、変更を加えた箇所やその影響範囲のみのテストを実行して、開発中のコードに対するフィードバックを得る程度だと思います。

しかし、自分が変更した範囲でテストが通っても、考慮漏れによって別の箇所にバグが生じる可能性があります。そのようなバグがあるコードを知らずにマージしてデプロイしてしまえば、ユーザーがそのバグに気付き、信頼を失う原因になりかねません。信頼を失えばビジネスが上手くいかず、売り上げが伸び悩みます。最悪の場合は会社が倒産し、自分の仕事が失われる可能性もあります。会社の明日を守るためには、今日のテストが重要です。

CIに馴染みがない人向けの説明する

CIに馴染みがない場合は、Gitを用いたバージョン管理を例に考えると分かりやすいです。たとえば、本番で稼働しているコードを管理するmainブランチから、新機能を追加するためのfeatureブランチを作成します。featureブランチでコードを変更し、それをリモートのリポジトリにプッシュします。

このプッシュをトリガーとしてCI環境でビルドとテストが実行されます。また、mainブランチやdevelopブランチにfeatureブランチをマージする際にもビルドとテストが実行されます。もし失敗した場合はリリースを中止してバグの原因を特定します。このように、デプロイ前に何度も自動テストを実施することで、ユーザーにバグを届けるリスクを未然に防ぐことができます。

手動テストは変更があるたびに繰り返す必要があるため、テストはできる限り自動化することが推奨されます。ただし、全てを自動化した場合、flakyテスト（実行結果が不安定なテスト）が問題になることがありますが、この話題については深掘りせずここまでにとどめます。

継続的インテグレーションの運用: CIの待ち時間に振り返りをする

ペアプログラミング中にCIの結果を待つ場面は自分も経験しますが、その時間をペア作業の振り返りに使うことはあまりしていません。CIの待ち時間を利用してSlackの新規メッセージを確認したり、スプリントバックログを見直したり、休憩時間に充てることが多いからです。

ただし、一度Kent Beck氏の提案に基づき、CIの待ち時間を振り返りに活用してみたことがあります。それはポイントが1の小さいストーリーに取り組んだ際のことです。このストーリーは実装が簡単だったため、事前に考えた方法でサッと実装を完了してコードをpushしてテストの実行完了を待っていました。

待ち時間に「思考実験ですが、もっと簡単に実現する方法はあったと思いますか」とペア相手に問いかけてみたところ、「シェルコマンドを組み合わせるのはどうでしょうか。それならアプリケーションコードを書く必要がありません。ただ、メンテナンスコストを考えるとどちらでも大差ないですが」と提案をもらいました。

自分はストーリーの完了条件を見た段階で実装方法を決めてしまっていたため、シェルコマンド案は思いつきませんでした。そこで早速ペア相手の案を取り入れてコードを書き直しました。この経験から「小さいストーリーでもすぐに思いついた方法に飛びつかず、より良い方法を検討する」重要性を学びました。この経験から、振り返りというものは小さいものでも十分威力を発揮するのだと実感しました。

Kent Beck氏がWard Cunningham氏とペアプログラミングを行いながら、CIの実行の待ち時間に振り返りを行うことでXPの数々のプラクティスを生み出したのだろうと想像すると、このアプローチがより素晴らしいものに思えます。CIの待ち時間に振り返りをすることは、誰もが賢人になれる可能性を秘めた強力なプラクティスと言えるでしょう。

次回はDevOpsの概要を紹介します。

この記事は私をシニアエンジニアにしてくれた「真のアジャイル開発」体験記の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技術部一周年＋仲間募集

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

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

ゆとり

本記事ではXPのゆとりの定義と自分たちのプロジェクトでの運用を紹介します。

ゆとりの定義

開発は長期的なマラソンに例えられます。なんでも詰め込みすぎるのではなく、コンスタントに成果を出すためにはゆとりが必要です。

例えば、スプリントプランニングの際には、後から外せる重要度の低いストーリーを含めておくようにしましょう。ストーリーの追加は後からでも可能です。見積もりよりも進捗が遅れる場合には、重要度の低いストーリーを外してバッファを確保することで対応できます。

作業を詰め込みすぎずにバッファを持ちましょう。心の余裕があると大量のバグを混入してしまうリスクや士気の低下、人間関係のギスギス感を避けることができます。詰め込みすぎて炎上したプロジェクトを想像するとこの逆であることがわかるでしょう。健全な余裕がチームの健全な運営に繋がるのです。

イテレーション計画に20%ルールを設けたり、「ギーク週間」を設定してプロダクトオーナーではなくプログラマが選んだタスクを進める時間を確保するのも良い方法です。こうした取り組みはチームのモチベーション維持や、創造性を発揮する機会にも繋がります。

ゆとりの運用

自分たちのチームでは、18時45分からの任意参加である雑談の時間を設けることでゆとりを作っていました。各人は18時45分までにその日の作業を終えて、19時以降はなるべく働かないようにしようと声かけをしています。タスクが途中でも問題ありません。人間は無意識にタスクの疑問を考え続けるもので、入浴中やトイレでふと答えが浮かぶこともあります。

深夜まで働くことは長続きしません。それよりも19時で仕事を切り上げ、翌日10時に出勤してコンスタントに成果を出し続ける方が良いのです。ソフトウェア開発は50メートル走ではなくマラソンだからです。

ただし、絶対に変えられないリリース日直前を除きます。リリース日前以外にも、長期の開発では集中してタスクをやり切らないといけない場面があります。そのような場面が来たときに、チームがすでに疲弊してはいけません。そのような緊急事態にも余裕を持って対処できるように、普段はゆとりを持てるように調整するのです。

ゆとりの運用：心にゆとりを持つこと

ゆとりを持つことは重要な考え方です。興味深いことに、人間は常に何らかの不満を抱える生き物です。

スプリントの振り返りであるエンジニアが次のように話しました。「今スプリントは全員が作業に集中しており、アウトプットもたくさん出ました。ストーリーに対する仕様は固まっており、あとは手を動かして実装するだけ。エンジニアたちは10時30分ごろから18時45分まで、ミーティングの時間を除いてずっとGatherにいてペアプロをしていました。スプリントゴールも達成したしプロジェクトが前進している実感があります。文句のつけようがありません」

ところが、彼は続けて言いました。「しかし、気持ちの面で疲弊しています。インプットの時間が欲しいです。一人になる時間が欲しいです。」

この背景には、チーム内でペアプログラミングは任意だとされてるものの、実質的に常にペアを組む運用になっていたことがありました。この振り返りをきっかけに「一人でやりたいタスクはソロでやります」と宣言する文化が生まれました。

それまでは自分が作業を開始する時に、他の人に何をしているかわかるようにSlackのチャンネルにタスクの内容を投稿していました。その際、タスクを一人でやるか、二人でやるか、一人でやるが他の人が参加してもいいのかを気軽に宣言できるようにしたのです。

この振り返り以降、気持ちの面で疲弊したという意見は出ていません。ただ、学習時間の不足は課題として残っており、執筆時点ではチームでの勉強会を開催すること以外に有効なプラクティスは見つかっていません。自分たちにのアウトプットに関係のないインプットはしないことは効率的であるものの、人はゆとりを感じなくなるのだなと思いました。

ゆとりの運用：「スプリントの休み」を作って負債を解消する

プロダクトオーナーが開発メンバーの燃え尽き防止のため、大きなリリースの後にスプリントを休む週を設けたいと提案してくれました。現在会社には20%ルールがなく、チームメンバーが毎日スプリントにフルコミットしていることを気にかけてくれたのです。

面白いことに、エンジニアの休息はビーチでただ寝転ぶような体力の回復（いわゆるHP）ではなく、意志力の回復（いわゆるMP）が重要です。何もせずただ休むのではなく、前から触ってみたかったツールを触ったり流行のプログラミング言語を学ぶなど、自分の興味のあることを追求することで意志力が回復し、仕事のモチベーションも上がるのです。

この提案をエンジニア陣は喜んで受け入れました。一般的にこのような機会はエンジニアが根気強く主張してなんとか勝ち取るものだからです。結成から3ヶ月しか経っていないチームでの初めての試みだったため、この「スプリントの休み」ではプランニングを行わず、取り組むタスクを共有するだけにしました。実質的には3日間の休みでしたが、いくつかの学びが得られました。

一つは、プランニングをやめるとペースが乱れるということです。ベロシティを算出できず、みんなで洗練してきた朝会の質問群も機能しませんでした。いつものように朝会の質問で「スプリントゴールの達成に影響があるアイテムはありますか？」と聞いても、そのスプリントにゴールを設定していなければ質問自体が成立しないのです。

最後に振り返りを行ったところ、このチームでは「プロダクトオーナーではなくエンジニアが優先順位をつけるスプリント」こそがエンジニアにとっての休みのスプリントだという結論に至りました。その時は、なるほどいいアイデアだと満足しました。

しかし、この項目を書くためにXP本を読み返したところ、「ギーク週間を設けよう」と既に書かれていました。チームのみんなで考えたアイデアは、20年以上前の本に既に書かれていたのでした。これこそ「時を超えたXPの道」ではないかと私は膝を打ちました。

次は「週次サイクル」「四半期サイクル」「10分ビルド」の定義と運用を紹介します。

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

ストーリー

本記事ではXPのストーリーの定義と自分たちのプロジェクトでの運用を紹介します。前回の記事の後編です。

ストーリーの運用: ポイントの運用のコツ

XPのストーリーを用いた開発手法をスクラムと組み合わせると、プロダクトバックログアイテムはストーリーの形式で記述されるようになります。それぞれのストーリーにストーリーポイントを付与し、全ポイントを合算することでプロダクトリリースまでの時間を見積もることができます。

さらにスクラムのスプリントでは、直近2スプリントで消化完了したポイント数の平均（ベロシティ）をもとに次のスプリントでに完了できるストーリーの数を予測することができます。

ストーリーが大きすぎる場合にはフィーチャーやタスクに分解することも検討できます。例えば、私のチームでは1～3ポイントのストーリーは問題なく扱えますが、5ポイントのストーリーは大きすぎる可能性があるので注意が必要とされ、8ポイント以上のストーリーについてはさらに細かく分解する方針を取っています。

これは、過去に8ポイントと見積もったストーリーが2週間のイテレーションを跨いでしまい、8ポイントを丸々ベロシティに計上できなかったという経験に基づきます。

例えば、今回のスプリントで8ポイントと見積もられたストーリーがスプリント内でほとんど完成したものの、スプリントレビューに間に合わず完了と見なされなかった場合、8ポイントはそのスプリントの完了として計上しませんでした。また、部分的な進捗として5ポイントや7ポイントを計上することもしていません。

この場合、残りのタスクを1ポイントと見積もって翌スプリントで完了させた場合、結果としてベロシティには1ポイントしか計上されません。同時に、スプリント中に開発者が「着手済みで順調に進んでいます」とPOに報告していても、ストーリーを完了としない限りバーンダウンチャートには何の進捗も反映されません。バーンダウンチャートのポイントが減らない状況が続くと、チームは「今回のスプリントは失敗だ。ゴールを達成できないかもしれない」と思い込んで士気が低下してしまいます。

ストーリーの運用: ストーリーのポイントが大きすぎるときの対処法

このような状況を改善するためには、次の2つの方法を組み合わせると効果的です。

手法1: ストーリーを細かいタスクに分解する 手法2: デイリーで再見積もりを提案する（スクラムでいう検査と適応）

1つ目の方法はシンプルなテクニックです。例えば、2～2.5日で終わるような2～3ポイントのストーリーには、このテクニックを適用する必要はありません。ただし、初回見積もりの時点で3日以上かかることが予想される5ポイントや8ポイント以上のストーリーには有効です。

2～3ポイントのストーリーの場合、それを分解したタスクにはポイントを設定しません。一方、5ポイントや8ポイントのストーリーの場合は、細かく分解したタスクにそれぞれにポイントを振ります。例えば、ユーザーに価値のある機能Xを実現するために8ポイントが必要と見積もった場合、機能XをタスクA、B、Cに分解して、それぞれに8ポイントを配分するのです。

この際、タスクの記述はユーザーストーリー形式にこだわらず開発者が自由に記述します。

2つ目の「デイリーで再見積もりを提案する」は勇気が必要です。「思ったより時間がかかっています」と伝えるのは簡単なことではありません。しかし、現実は変えられないため、勇気を持って状況をチームに共有しましょう。また、遅れそうだと伝えてくれたメンバーには、プロジェクトの透明性を重視している姿勢をリスペクトするべきです。

開発者としては「少し遅れそうですが間に合わせます」と言いたくなるかもしれません。しかし、その発言を聞いた周囲のメンバーは、「このストーリーは着手から最大3日以内に終わる見込みなのか？もしそうでなければ、ストーリーをさらに分解する必要があるのでは」と感じるかもしれません。そうした場合には、アイテム（ストーリーやタスク）のリファインメントを提案するのが適切です。

ストーリーについては、着手前よりも着手後の方が多くの情報が得られています。さらに、今日よりも明日の方が状況を詳しく把握できていることが多いです。このように情報が増えるということは、見積もりの判断材料も増えているということであり、より正確に見積もりを修正できるチャンスがあるということです。

毎日のスタンドアップミーティングの本質的な価値は、過去の進捗を共有するだけではなく、新たな情報を基に過去の判断を覆す必要がある場合、そのことをメンバーに共有し、チームでスプリントを見直す判断をすることにあります。

私のチームでは以前「このストーリーは重そうに見えるけど大丈夫ですか？そんなに日数をかけずに終わらせられますか？」という声かけを朝会でしていました。開発者は「大丈夫、すぐ終わります」と答え続けたのに、実際には2～3日以上が経過してしまうことがありました。周りのメンバーは進捗状況を正確に把握できなかったのです。

この経験を基に、スプリントレトロスペクティブで「今後のデイリーでは、現在取り組んでいるストーリーは着手から3日以内に終わっていますか？という質問を司会者が必ず行う」というネクストアクションを決めました。

毎日の朝会でこの質問を投げかけることにより、進捗を正確に把握しやすくなり、必要であれば再リファインメントやスプリント計画の見直しを早期に行えるようになりました。

ストーリーの運用: 具体的な作業が伝わりやすいストーリーの作り方

ストーリーの書き方にはフォーマットがあると冒頭で述べましたが、具体的な作業を想像するためにはどのように進めれば良いでしょうか。その問いの答えは、私の同僚である@tanden氏の「アジャイルで不確実性に向き合うための開発タスクの切り方」というスライドから引用します。

@tanden氏が述べる「全ての工程を含むように開発タスクを小さくする」というアプローチは、「More Effective Agile」という書籍の中で「バーティカルスライス」と呼ばれていますやり方です。各ユーザーストーリーをバーティカルスライスで開発しデリバリーすることは、アジャイル開発の重要な考え方の一つです。

短いスプリントがうまくいくには、動く機能を少しずつ頻繁にデリバリーする能力をチームが養わなければならない。こうした活動をサポートするために用いられる設計アプローチはバーティカルスライスと呼ばれる。バーティカルスライスは、増分的に機能または価値をデリバリーするために各アーキテクチャ層で変更を行う、というものである。 「More Effective Agile」9.4 基本原則：バーティカルスライスでのデリバリー

この考えを同僚の@hgsgtk氏は次のように表現しています。

「XxxAPIを実装します」や「テーブルの設計をします」といったレイヤごとの作業ではなく、「ユーザーとして自身のメールアドレスを変更できる」といったフルスタックの機能を指します。 「少人数でのアジャイル開発への取り組み実例 （一歩目の踏みだし方）」| 詳説 | July Tech Festa 2020 登壇レポート

ユーザーストーリーはソフトウェアの機能を機能そのものではなく、ユーザーに対する価値として表現するものです。「全てのテーブル設計が終える」「全ての画面デザインを実装する」といった表記はユーザーストーリーとは言えません。

ユーザーに価値を素早く届けるには、ユーザー目線で何ができるかというストーリーを作成し、それを実現する機能をバーティカルスライスで開発してデリバリーすることが重要です。

ブログのシステムを例に考えると、管理画面、編集画面、一般ユーザーが見るブログ記事の閲覧画面を全て完成させてから公開するのではありません。まずは管理画面の記事一覧だけでも完成させてユーザーに見せ、フィードバックを得るのがアジャイルの姿勢です。この場合、ストーリーは「執筆者として、下書きの記事タイトルが一覧できる。ブログで発表したいアイデアがたくさんあるからだ」といった形になるでしょう。「管理画面の開発を完了する」はユーザーストーリーではないのです。

ストーリーポイントの注意点

自分たちのチームは開発の見積もりにストーリーポイントを活用していると紹介しました。

しかし、あなたの組織でストーリーポイントについて誤解が生じる場合はその使用を見直すべきだとRon Jeffries氏はブログ「ストーリーポイント再考」（“Story Points Revisited”, 2019） で述べています。Ron Jeffries氏はKent Beck氏に並ぶXPの考案者の一人です。

このブログではストーリーポイントに関する誤解や誤用の例として、「見積もりは相対的なものであるにもかかわらず、AチームとBチームを比較してBチームがポイントを多く消化していれば優秀と見なされる」「マネージャーが見積もりと実際の作業時間の差に過剰反応する」といった事態を挙げています。

ストーリーポイントを誤解しているチームや組織は、アジャイル開発というものを十分に理解していない可能性があると思われます。ストーリーポイント自体が悪いわけではありませんが、それが誤用されるアジャイルの価値を十分に理解していない環境では使用を控えた方が良いのでしょう。そのような環境ではチームや開発者がリリースに対する過度なプレッシャーを受けてしまうからです。

次回はゆとりの定義と運用を解説します。