はじめに
この記事は、NSSOL Advent Calendar 2024の10日目の記事です。
スウォーミングとは一つのタスクに全員（または多人数）で取り組むことを指します。ここで疑問を持つ方は多いと思います。「POでスウォーミング？それ、アンチパターンでは？」。スクラムをやっている人ならだれもが知っているアンチパターン複数人のPOを踏んでしまっています。しかし今回扱うのは複数人のPOではなくPOのスウォーミングです。これには明確な違いがありますので後述します。
実際に約1年間、POのスウォーミングに取り組んだので、それについて書いていけたらなと思います。
チームについて
我々のチームは社内向けのサービスをアジャイルで制作しており、スクラムを始めて1年半ほどになります。PoCを行っており、ユーザーからのフィードバックをもとに頻繁に機能拡張を行っています。現在は新たな導入先に向けて準備を進めており、開発自体はかなり盛り上がっています。メンバー数は3人です。
背景
なぜPOを決めなかったのか
理由はシンプルで全員が「コードを書きたい!」という思いが強すぎたためです。
POをローテーションするという選択肢もありましたが、POになっている期間、そのメンバーのモチベーションが下がることは明白なため、チーム全体のモチベーションの維持を優先しました。
なぜモチベーションを優先するのか
ビジネスのなのだから、自分たちの都合を優先すべきではないと言えばそうかもしれません。ですが、開発者が仕事を楽しんでいるかどうかは生産性と密接に関わっています。
開発者の幸福とパフォーマンスの関係について調査されている論文では以下のよう言われています
Low motivation is also an important consequence of unhappiness for software
モチベーションの低下は、ソフトウェア開発の中で不幸によって起こる重要な結果でもある。
The participants were clear in stating that unhappiness leads to low motivation for developing software, e.g., “[the unhappiness] has left me feeling very stupid and as a result I have no leadership skills, no desire to participate and feel like I’m being forced to code to live as a kind of punishment. [...]”, or “Also, I’m working at a really slow pace [...] because I’m just not as engaged with the work”.
参加者たちは、不幸がソフトウェア開発に対するモチベーションの低下につながることを明確に述べている。例えば、「（不幸なことが）私をとても馬鹿にしているように感じ、その結果、リーダーシップのスキルもなく、参加する意欲もなく、一種の罰として生きるためにコードを書くことを強いられているように感じる」、「また、仕事に没頭できないので、本当にスローペースで仕事をしている」
また、開発生産性を計測する有名なフレームワークの一つであるSPACEでは開発者のアウトプットだけではなく、開発者の満足度やコミュニケーションの指標を計測することが推奨されています。
何か施策を講じるとき、開発のプロセスに目を向けがちですが、根幹にあるのは人の問題であり、それを解決しない限り、仕事のプロセスの問題をいくら解決しても、チームパフォーマンスの劇的な改善は期待できません。
アンチパターンを踏んでもよいのか
アンチパターンをあえて踏むことは問題ないと考えています。重要なのは踏んだことにより発生するリスクを調査し、それをチームとステークホルダーが許容できていることです。我々のチームでは、ステークホルダーにこの施策の了承を得たうえで取り組んでいます。
POのスウォーミング
そもそも複数人POはなぜアンチパターンなのか
一般的にはPOが複数いると判断軸がぶれたり、合意形成のための時間が伸び、スクラムの強みである適応性やアジリティが損なわれてしまうと言われています。複数人POは私も推奨はしません。
POのスウォーミングと複数人POの違い
大きな違いはDEVメンバーの負荷にあります。スウォーミングの場合、チーム全員でPOとDEVの両役を行うのに対して、複数人POの場合はPOとDEVのメンバーが分かれていることが多いと思います。DEVメンバーが複数人のPOに判断を仰ぐのは非常に労力がかかり、認知負荷が増加します。スウォーミングではチーム全員で同じタスクに取り組んでいるため、POとDEV間の認知負荷はほとんどありません。
実施したこと
POとしてのタスクはバックログに入れて全員で取り組むようにしました。ユーザーへの質問リストの作成や追加機能の検討など、POが行うようなタスクも開発タスクと同じようにバックログに入れてスウォーミングで取り組んでおり、ユーザーとの打ち合わせもチームメンバー全員で参加するようにしています。
バックログリファインメントはスプリント中であっても気づきがあったときに都度行っています。それに加えて週末に1時間のタイムボックスでリファインメントを行っています。
気を付けたこと
判断軸を合わせる
複数人で意思決定をする際、全員が共通のビジョンを理解していることが重要です。我々はエレベーターピッチを用いてチーム内でプロダクトビジョンを共有しています。毎週月曜日にみんなで読み合わせ、違和感がある個所を修正する時間をとっています。また、バックログリファインメントの際にはチームがどんな状況でどのエピックに注力するべきかの認識を合わせるところからスタートしています。
アジリティをできるだけ落とさない
とはいえ複数人の意思決定では合意形成に時間がかかります。そのため、検討の場ではあらかじめタイムボックスを設定し、それに収まるように進めていき、選択肢が複数ある場合は投票などを駆使して速やかに決定します。
もちろんPOが一人のときよりもアジリティは落ちてしまいますが、お互いに対話をし、納得した上で仕事を進めることを優先しています。
やってみてどうだったか
よかったこと
モチベーションを維持できたのはもちろんですが、最も良かった点は常にチーム全員で同じ方向を向けていることです。POタスクで対話を重ねることによって、メンバー間の認識齟齬がなくなり、透明性が担保されるようになりました。また、複数人の多様な視点により、さらに深く検討できるようになったと感じています。
改善が必要なこと
今回の施策は社内向けのサービスの開発で小規模のチームだから取り組めたものだと考えています。チームの人数が増えるにつれ、合意形成の時間や判断軸の問題が大きくなると考えられるので、今後は別の策を講じる必要があるかもしれません。
伝えたいこと
モチベーションを優先する（許容できるリスクの中で）
高いモチベーションを持たずして、高い生産性で仕事をすることは困難です。プロセスばかりに目を向けてしまうと、優先的に解決すべきである開発者自身の問題に気づくことはできません。「スクラム アンチパターン」と検索すると、とんでもない量の記事がヒットしますが、これらすべてを考慮することは困難です。もし、今のスクラムに息苦しさを感じていて、解決するために型から外れる必要があるのならチャレンジする選択肢を持つのもいいかもしれません。選択する際はリスクの調査とステークホルダーへの説明をお忘れなく。
意見を言い合えるチーム文化
今回の施策にスムーズに取り組めたのは、忌憚なく自分の意見を発信できる文化の醸成がチーム内でできていたからだと考えています。我々のチームでは「意見があるときは相手に悪いかもを超えてちゃんと言おう。」という価値観を大切にしており、ワーキングアグリーメントにも記載しています。
さいごに
POのスウォーミングについて書くつもりがモチベーションの話が多くなってしまいました。
来年もモチベーション高く、生産性高く過ごしたいと思います。
ここまで読んでいただき誠にありがとうございました！