ペア制度を導入して、開発チーム内の相談しやすさ向上・知見展開・透明性向上を狙う

最近プロジェクトマネジャーを担当していた仕事で、開発チーム内の相談しやすさ向上・知見展開・透明性向上・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人以上割り当てるという制度を導入したので、その背景や振り返りをブログに書いた。アンケートによると概ね好意的であったため、うまく活用していきたい。また改善ポイントはいくつか見つかったので、仕組み自体も改善できると良いだろう。

開発パフォーマンス指標とバリューストリームマップでチーム改善をする

以前Pull Requestから社内全チームの開発パフォーマンス指標を可視化し、開発チーム改善に活かそう - Hatena Developer Blogの記事で、開発パフォーマンスを可視化する話を書いた。その後、バリューストリームマップを作り開発フローの課題を洗い出して、チームの改善を行い、そして開発パフォーマンス指標で効果を検証する取り組みを行ったので、その経験についてブログに書いておく。

前回の記事のサマリー

前回の記事を前提として書くため、簡単にサマリーすると

• 開発チームのパフォーマンスを測るためには、以下の4つの指標を計測すべきと言われている
  • 変更のリードタイム: first commit〜そのcommitが本番にリリースされるまでの時間
  • デプロイの頻度: 本番環境へのデプロイの回数
  • MTTR（平均修復時間）: サービスダウン〜復旧までの時間
  • 変更失敗率: 本番デプロイ時のサービスダウン発生率
• 全てを一気に可視化するのは難しいため、一旦計測しやすい次の指標を可視化した
  • 変更のリードタイムの一部分であるPull Requestのプロセスタイム : first commit〜Pull Requestのマージまでの時間
  • デプロイの頻度

バリューストリームマップを作り、開発フローの課題を発見する

前回の記事で、開発チームの開発パフォーマンスの指標を可視化できた。しかし、この指標だけでは具体的にどのような改善すべきかは分からない。そこでまずバリューストリームマップを作り、開発フローのボトルネックを洗い出そうと考えた。

バリューストリームマップとは何か

バリューストリームマッピングとは、製品やサービス、機能を顧客へ届けるために必要なプロセスを可視化するツール。詳細や具体的なやり方については、ここはあえて紙とペン！ Value Stream Mappingで開発サイクルの無駄を炙り出せ！やバリューストリームマッピングをやってみたの記事が非常に参考になる。

チームのバリューストリームマップを作る

自分のチームの開発は、企画が決まった後は、次のように進んでいく。

• 機能のためのPull Requestを細かい粒度で作っていき、レビューが通り次第マージする
• ある程度の量マージされたら、リリースする
• リリースを繰り返して、最終的に機能が完成したら、ユーザーに公開する

そこで、Pull Requestの粒度の開発サイクルと、リリースの粒度の開発サイクルについて、バリューストリームマップを作ってみた。本当は企画から全てのフローを含めてバリューストリームマップにした方が良いのだが、最初から全部やろうとすると大変なため、まずは一部に絞って行った。

バリューストリームマップを作るポイントとしては以下の二点と考えている。

• 1) 課題を分かりやすくするため細かめにカードを分割し、それぞれ作業人数と時間を書くこと
• 2) 作業者が変わるところはボトルネックになりやすいので、その部分は点線でつなげること
  • 自分は、作業者は同一だけど待ち時間が発生するものも点線でつなげた。コンテキストスイッチのボトルネックを分かりやすくするため

書いてみたバリューストリームマップは次の通り。

Pull Requestの粒度の開発サイクル

リリースの粒度の開発サイクル。「デプロイ」の部分は実際はもう少し詳細に分割していたが、外部公開の都合上1つのカードにしてしまっている。

バリューストリームマップから課題を見つける

バリューストリームマップから分析したところ、やはり20分もかかっているCIの遅さがさまざまな場所でのボトルネックになっていると分かった。CIの時間は、開発パフォーマンス指標における変更のリードタイム・デプロイ頻度・MTTRの全てに影響を与える。開発フローの中でインパクトが最も大きいので改善したい。

他にも、コードレビューにコストがかかりすぎている、リリースフローの関係上マージ禁止の期間がある、リリース時のパフォーマンス確認に時間がかかっているなどの課題も見つかった。見つかった部分には赤色の付箋で印をつけていった。

見つかった課題を解決する

バリューストリームマップによって課題を発見できたので、後は1つずつ解決していくだけである。

まずCIについては

• テストの並列化などを通して、5分ほど実行時間を短縮した
• フロントエンドしか変更していない場合、バックエンドのテストに影響することはないため、特定条件の場合バックエンドのテストをスキップした

という改善を行い、すべてのテストを動かしても15分弱で、フロントのみの変更なら4分でCIが終わるようになった。

他に見つかった課題も分析を行い、ランダムでコードレビューを割り当てるのをやめる、マージ禁止の条件を見直して1時間ほどマージ禁止期間を短縮する、パフォーマンス確認がしやすくなるMackerelのダッシュボードを作るなど、地道に改善していった。

開発パフォーマンスの指標で改善結果を振り返る

最後に開発パフォーマンス指標を観察し、改善結果を振り返った。今回の改善が直接的に効くのは変更のリードタイムであり、その一部であるPull Requestのプロセスタイムを見てみたところ、20％ほど改善していることが分かった。色々な要因で指標は変化しうるので、全てが改善した結果とは思っていないが、少なくとも良い方向に向かわせられたと思っている。

まとめ：データを根拠にチーム改善するという進歩

今回はバリューストリームマップを作り開発フローの課題を洗い出して、チームの改善を行い、そして開発パフォーマンス指標で効果を検証する取り組みについてブログを書いた。

今回の内容を読むと、チーム改善の施策については特に特別なことはしていない。これまでもCIが遅すぎるから直そうとか、レビューフローを見直そうとか、リリース大変すぎるから直そうなどは自然発生的に起こってきた。

しかし、これまでは何を改善すべきかは勘で決めていた部分も多く、かつチーム改善の振り返りもしづらかった。そこから、開発パフォーマンス指標やバリューストリームマップなどを用い、データを根拠にチーム改善し振り返りもできたのは、非常に大きな進歩だと感じている。

今後もチーム改善や組織改善をデータ駆動で行うという取り組みは続けていきたい。

参考

• Pull Requestから社内全チームの開発パフォーマンス指標を可視化し、開発チーム改善に活かそう - Hatena Developer Blog
• ここはあえて紙とペン！ Value Stream Mappingで開発サイクルの無駄を炙り出せ！
• バリューストリームマッピングをやってみた

リモートワークに必要なスキルの言語化を試みる

最近リモートワークでしばらく暮らしたところ、オフィスの時より人によって成果の差が出やすいと感じている。また昔からリモートワークしてきた人の様子を見ていると、仕事の進め方がうまいと感じることが多い。このことから、リモートワークに重要なスキルが何かあるはずだと感じていたのだが、自分の中でちゃんと言語化できていなかった。

そこで以下の資料を読み、少し言語化してみたのでメモ。

• リモートワーク大全

• Effective Remote Working - Speaker Deck

いくつか読んで、自分の中で以下のキーワードが重要なのかなと考えている。

• セルフマネジメント
  • モチベーション・集中力コントロール
  • メンタルケア
  • タスクマネジメント
• コミュニケーション
  • こまめなアウトプットによる状況の可視化、それによる信頼の醸成
  • 曖昧でない言葉で全てを伝えるコミュニケーション
  • こまめな賞賛や雑談でのエンゲージメント向上
  • 会社全体の情報の透明化
• 自宅での快適な仕事環境
  • 肉体 -> ネットワーク -> 音声 -> その他

セルフマネジメント

リモートワークではセルフマネジメントが重要と言われているが、もう少し分解すると、モチベーション・集中力コントロール、セルフメンタルケア、セルフタスクマネジメントあたりが重要だと感じた。

元々オフィスによって（もしくは人がいる場所に行くことによって）ベースとなるモチベーション・集中力が生み出されていた場合、それが無くなったため、自分でコントロールする必要がある。例えば、前日にやりかけにする、その日にやるべきことを書き出す、やる気がなかったらすぐに手を動かせるタスクをまずやる、などといったテクニックがある。

また他者から自分の様子が見えなくなったことにより、周りが自分の不調に気付きにくくなった。そこでセルフメンタルケアが重要になってくる。自分のメンタル状況の可視化、寝る前にその日の自分を労うなど、マインドフルネスやセルフコンパッションなどのスキルがあると良い。

他者から自分の様子が見えなくなったことは、仕事の進行の見えやすさにも影響してくる。そこで、周りから安心して仕事を任せられるためには、セルフタスクマネジメントが重要になってくる。タスク分解や報告の手法を身につける必要がある。

コミュニケーション

リモートワークでは、コミュニケーションに重要な非言語情報がほぼ全く伝わらない。これにより文脈やニュアンスの伝達、信頼感の醸成が難しくなっている。そこで全ての情報を過剰になってでも「言語情報で伝える」という努力が必須になる。

例えば先にあげたことが重要になってくる。

• こまめなアウトプットによる状況の可視化、それによる信頼の醸成
• 曖昧でない言葉で全てを伝えるコミュニケーション
• こまめな賞賛や雑談でのエンゲージメント向上
• 会社全体の情報の透明化

自宅での快適な仕事環境

スキルといったものの、もちろん自宅で快適に仕事をする環境を整えることも重要である。肉体 -> ネットワーク -> 音声 -> その他の順で大事に感じた。

• 肉体
  • 肩こり・目の疲労・病気など、肉体がダメージを負っていると仕事どころではなくなる
  • 机や椅子、ディスプレイ、照明、空調など
• ネットワーク
  • いかに良い音声やビデオ環境を用意しても、ネットワークが不安定なら全く意味がない
• 音声
  • 同期コミュニケーションで音声をクリアに保つことでコミュニケーションの質を上げる
  • イヤホン、マイク、Krispなどのノイズキャンセリングソフトなどに投資する

まとめ

今回はリモートワークに必要なスキルを自分の中で言語化してみた。リモートワークのスキルをどんどん身につけていきたい。

参考: リモートワーク大全の読書メモ

* 社内のメンバーへの可視性（による信頼性の向上）のためや、自分の達成感のためにも、取り組んでいることをこまめに発信する 307
    * 成果だけではなく、挑戦や努力も発信
    * 気付き：アウトプットの形はなんでも良いと思う。PRをこまめにでも良い
* 信頼関係を培うベースは、ちゃんと様子が見えること 588
* とにかく言語情報で伝える
    * 感謝も賞賛も言葉で伝えよう 595
        * 気付き：非言語情報で伝わっていたものは全て伝わらない前提で、より言葉を多く働く
        * ピアボーナスなど感謝を伝える仕組みはリモートワークとも相性が良い
    * 誤解なく伝える。主語と述語を明確に。どちらとも取れる曖昧な表現はなくす 606
* 行間を読みすぎて誰かの言葉を悪く受け取らないようにする 613
* リモートワークではセルフマネジメントスタイルが重要 780
    * 前日にやりかけにしておく
    * その日にやるべきことを書き出す
    * チームにやることを宣言する
    * すぐに手を動かせるタスクをやる（2 Minutes Starter） 861
    * 寝る前にその日一日頑張った自分をねぎらう 1019
* リモートチームのコミュニケーションのベースは、それぞれが自分のやるべきことをやっていると信頼すること 1724
* リモートでは言葉で伝えることは必須の能力 1744
* ローコンテキストなコミュニケーションを行う 1748
    * 問いかけるときは背景と意図も伝える
    * ニュアンス（言外に表された話し手の意図、表現や微妙な差異）も言葉で伝える。難しかったら絵文字も使う
* ローコンテキストな会話のポイント 1799
    * 言葉を省略しない
        * メッセージの宛先、主語と目的語、背景・意図・目的
    * 明確な言葉を使う
        * 期間：今週中 -> 今週の金曜まで、少し早めに -> 15分前まで
        * どちらの意味にも取れる言葉を使わない：大丈夫です
    * 話をしている目的を伝える
        * 相談に乗って欲しい、承認して欲しい、フィードバックが欲しいなど
    * 分からない場合はそのまま伝える
    * 返事には理由を添える
    * 1投稿1トピック
* チャットでメッセージを送った後、即座に返事が来ることを「毎回、常に期待するのは控える 1906
    * 緊急の場合は明確な期限付きで伝える
* いいねはたくさんしよう 2065
* 会議など仕事で集まる機会の前後にコミュニケーションのための時間も確保する 3229
* フルリモートになると、大体の人は自分のチームに関連するアップデートだけに注目し、他チームの活動が見えなくなる 3340
    * 気付き：実際に起こっている問題に見える
        * これが起こるとどうなる？ -> 自然な知見共有が起こりづらく局所最適になりうる、全社の方向性がバラバラになりやすい
    * 毎週金曜のランチ会などで対策するなど
        * 気付き：バーチャルなランチルームがあるともっといいけど