[XP]ゆとりの定義と運用事例（2024 Advent Calendar 18日目）

この記事は私をシニアエンジニアにしてくれた「真のアジャイル開発」体験記の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分ビルド」の定義と運用を紹介します。