最近プロジェクトマネジャーを担当していた仕事で、開発チーム内の相談しやすさ向上・知見展開・透明性向上・WIPタスク数減少を狙ってペア制度というのを導入した。今回は導入した背景、導入した仕組み、そしてその振り返りについてブログに書いておきたい。
導入した背景
最近はエンジニア6~7人程度のフロントエンドフレームワーク置き換えプロジェクトのプロジェクトマネジャーをやっていた。ペア制度を導入する前は、大体1~6ヶ月程度かかる粒度のタスクを1人にアサインし、人数と同じだけのタスクが進行しているという状態であった。
この1人1つのタスクを担当するやり方の時に、特にフルリモートでの働きという状況も相まって、次のような課題を感じ始めた。
- ちょっとした相談のしづらさ
- 知見展開のしづらさ
- タスク状況の透明性の不足
- WIPなタスクが多く、プロジェクトマネジメントが複雑
ちょっとした相談のしづらさ
元々チームとして、困ったらチャットやcallでチームの誰にでも相談しても良いとなっていた。しかし、フルリモートという状況によって、ちょっとした相談をすることに気後れしてしまう場合があった。これにより、Pull Requestになった段階で考慮漏れに気づき、大幅に手戻りするという場面が見られた。
知見展開のしづらさ
1人1タスクだと、担当している人だけがその部分に詳しくなり、属人性が高まりすぎる問題も起こった。もちろんコードレビューはしていたが、それだけだと「その部分を今後改修できるほどの知見」をレビュアが得ることは難しく、知見展開としては不足していると感じていた。
タスク状況の透明性の不足
1人1タスクで黙々と進めていると、今取り組んでいるタスクがどのような状況なのか、ブラックボックスになりがちだった。オフィスにいた頃も起こっていた問題ではあったものの、同じ場所にいた時は雰囲気で察することによって多少軽減できていた。しかしフルリモートになり、より見えづらくなり、さらに強い問題となっていた。
WIPなタスクが多く、プロジェクトマネジメントが複雑
6~7人が1タスクずつ持つと、Work In Progressなタスクが6~7つあり、並行してタスクが進むことになる。並列数が多いと、それだけ状況把握やタスクアサインなどのプロジェクトマネジメントコストも増大し、複雑であった。プロジェクトマネジメントの書籍にもWIP数は最小限にすべきと助言されていることが多い。
また、1人1タスクだと、そのタスクが完全終了するまでの時間（リードタイム）が長くなる問題もあった。例えば6人がそれぞれ3ヶ月のタスクを一斉に取り組むと、それぞれの機能がユーザーに提供できるのは6つの機能とも3ヶ月後になる。もしペアにして1ペアが低めに見積もって1.5人月出せるとすれば、3つの機能を2ヶ月後にだせ、全体効率は多少悪いが、一部機能をユーザーにより早く提供できる。
ペア制度を導入する
以上の課題の解決をするために、1人当たりの開発効率が多少落ちても、1~6ヶ月程度かかるタスクを2人組もしくは3人組で行ってみようとなった。導入した仕組みは単純で、
- 1~6ヶ月程度かかるタスクを、最低二2以上にアサイン
- アサインされたタスクの進め方は、ペアに完全にお任せする
- 毎日1回くらいペアで相談や雑談の機会を用意してもらったり
- ペアでやりやすいタスクの分解を考えてもらったり
- 各タスクの状況共有は、用意しているスプリント会で報告してもらう
導入したのが大体2021/2あたりだったので、大体半年くらい運用してみている。
ペア制度の振り返り
最後に制度を導入運用してみてどうだったか振り返ってみる。方法としては、メンバーにアンケートを行いつつ、自分のプロジェクトマネジャーの視点でもどう変化があったかをまとめる。
ペア制度を振り返っての点数評価
5段階評価でペア制度が良かったか点数をつけてもらった結果がこちら。1が悪かった、5が良かったで点数をつけてもらった。
概ね好意的な印象であったが、1対1のペアを組むとストレスが多かったという意見もあり、重要な意見だなと感じている。
導入して良かったこと
まず相談のしやすさの観点ではアンケートからも好意的なコメントが多く、課題に対して効果的に機能したと考えている。いくつかピックアップすると
- コロナでオフィス出社が無くなってから入社した身なので少人数で仕事と関係ない話とかをする場が本当になかったので良かった。とりあえず一日一回わからん！を気兼ねなく発言できる場があってよかった
- わざわざ聞くのは気が引けるけど、曖昧にしておくと障害になりそうな微妙な立ち位置の話をしやすかった
- ペア昼会が毎日発生したことで、強制的に会話の場ができた。自分で調べて全然分からなくても、少なくとも1日後には会が発生するので、難しくても「聞けばいい」に意識が変わったことがよかった
- 困ったときに相談しやすいので一人で考え込んで詰まることが減る
また知見展開の観点でも、好意的なコメントが多かった。
- 知見の伝達は行われやすかったように思う. 受信は自分の仕事に直接関連するので責任を持ってする必要があるし, 逆に発信に気を使いすぎなくても相方が受け取ってくれるはず
- 他者の動き方・考え方を(少なくともレビューだけの状態よりは)知れたところは良いと思った。
- 問題解決の一連の流れをペアの方からたくさん学ぶことができた。
タスク状況の透明性の観点や、プロジェクトマネジメントの煩雑さの観点はプロジェクトマネジメントの課題であったのでアンケートでは特に意見は現れてこなかった。プロジェクトマネジャーロールである自分の視点から振り返ると
- タスク状況の透明性
- ペアで進める以上、ペアで効率的に進めるためには自然とタスク分解や相談する必要があり、その相談内容のログなどで透明性がより増していた
- WIPなタスクの多さによるプロジェクトマネジメントの問題
- まず並列で動くタスクの数が半減したことにより、考えることは明らかに減った
- ペアの中でタスクマネジメントの得意な方が引っ張ってくれるため、そもそもタスクの進め方で問題が起こりにくくなった。プロジェクトマネジャーがサポートに入る必要が少なくなった
他にもアンケートで、コンテキストが共有されることでコードレビューなどがスムーズに進んだという意見も集まった。
- コードレビュー時に背景が共有されているのでコミュニケーションがスムーズに進む
- ペア同士でレビューを積極的にすると背景を理解できているのでレビューが早く終わり，開発サイクルの速度が向上する
- コンテキストを共有できるのはよかった。1人で scrapbox に書いてツッコミをもらって……とかでもできなくはないのだけど、そういうガッツに頼らずできる仕組みがあったのはよかった
導入して困ったことや、改善すべきポイント
困ったことや改善すべきポイントもアンケートでコメントをもらった。
- 一つのタスクを共有するとタスクの並列化が難しい(まずは並列化できるまでの準備期間があった方がいいかも?)
複数人で進めると並列化が難しいという問題は起こると思っていた。どのタイミングからペアにするかを検討する、あまりに小さいタスクはペアでは取り組まないなどの改善が考えられる。
- タスクの進め方にもよるかもしれないものの, 全体的な方針を揃えるのは意識してやらないと内的な品質が下がってしまうリスクはあると感じた。全編ペアプロで進めるとか, あるいは結合時など適当なタイミングで全体を整えるのをタスクとして考えておくとよさそう
これは一人でやると一貫性がある設計になりやすいが、複数人で行うとコミュニケーションミスで一貫性がなくなり、結果として品質が下がるということなのかなと思った。意識合わせのやり方を洗練させていきたい。
- ペア相手が長期間いない場合に、上で書いた「良かったこと」の恩恵が受けられなくなるので、不在が多くなりそうなら3人にしておくと良いかもと思った。
確かに。出社日数などに応じて組み方を考えたい。
一人当たりの短期的な開発効率は下がったか？
ペア制度を導入したとき、短期的には一人当たりの開発効率は下がるかもしれないと懸念していた。これはタスクを2人で担当したとしても作業のコンフリクトが発生し、1人で担当するときの2倍速では進まないだろうと考えたからだ。この点についても、簡易的に振り返っておきたい。
今回のプロジェクトではストーリーポイントで見積もりしていたため、ベロシティの変化を振り返ることで短期的な開発効率の変化が推定できると考えた。ペア制度を導入する前の4ヶ月ほどと、ペア制度を導入した後の6ヶ月ほどで、1スプリントの1人当たり平均ベロシティを計算してみた。その結果
- ペア制度導入前は1人あたり1スプリント3.2ポイントを消化していた
- ペア制度導入後は1人あたり1スプリント3.3ポイントを消化していた
となった。
タスクへの慣れ・営業日数・割り込みなど他の変数でベロシティは変わるので断言はできないが、ペア制度を導入したことでベロシティが3分の2になるといった大幅な劣化はせず、今回に関しては懸念は良い意味で裏切られた。ペアのコンフリクトによる効率の悪化と、相談しやすさやコンテキスト共有による効率の向上が釣りあったのかなと思っている。
まとめ
今回は最近プロジェクトマネジャーを担当していた仕事で、1タスクに最低2人以上割り当てるという制度を導入したので、その背景や振り返りをブログに書いた。アンケートによると概ね好意的であったため、うまく活用していきたい。また改善ポイントはいくつか見つかったので、仕組み自体も改善できると良いだろう。
