ペアワークをデフォルトにしたら生産性が劇的に上がった話

こんにちは、yoichi22です。半年ほど運用から離れて平和な日々を過ごしていましたが、2018年初からECサイトバックエンドの運用開発の現場に戻ってきました。この記事では新しいチームで3ヶ月ほどペアプロ、ペアワークを推進してきた過程と、その結果何が起こっているかを紹介します。

出戻り初日

少し前から基盤開発チームで一緒に働いていた1人と、隣のチームの活きのいい若手1人と一緒に、私にとっては古巣のチームにジョインすることになりました。私はまずは離脱していた間に変わったことの把握から始めることになりましたが、新しい仲間たちは業務知識がない状態からどう入っていこうかと相談になり、元から居たメンバがやろうとしている作業を新しい人とペアワークでやったらどう？と唐突にぶつけてみました。するとチームからは、

大きめのタスクはもう進行中で、いきなり入るのは難しいのでなしで
小さめのタスクは簡単すぎるので、ペアワークしても業務知識はそんなに学べないし、一人でやったほうが早いのでなしで
タスク溢れかえっていて時間があまりとれないので、まずは有り物のドキュメント読むところから始めといて欲しい

という気乗りしない反応が返ってきました。よくない状況を何とかするために呼ばれて来たつもりでしたが、新しいメンバを受け入れる余裕すらない状況だと感じました。心の中では

ちょっとしたことでも実際のシステムに触り始めてしまえば、そこをとっかかりに素早く全体を把握できそうなのになぁ
小さな案件は簡単と言ってるけど、待ちや手戻りが結構出てて、実はそんなに簡単に行ってないような気がするけどなぁ
一緒にやって違った視点から状況を見たら、忙しい忙しいと言ってるその根本対策のヒントが得られたりしないかなぁ

などと思ったものの、いっぱいになってるコップに今さらに水を注いでも仕方ないなと、一旦退いてじっくり取り組んでいこうと思いました。

自分が辛いことをペアワークで解決

数週間が過ぎ、チームにも少し馴染んできたなと思ったころ、ふと気付くとちょくちょく起きる障害の一次対応で動いているのが自分ばかりになっている！！元々チームに呼び戻されたのは、障害が頻発していて対応できる人が足りてないので、まずは一次対応を分担して負荷分散して、次は障害を減らして安定稼働するようにシステムを作り直していくことを求められてでした。でも、このまま目の前の対処だけしていても、障害を減らす施策に到達する前に自分が疲弊して潰れてしまいそうな気がしました。

そもそも我々がジョインする前には、チーム内では障害対応をするための環境、権限が与えられていたのはマネージャ＋シニアエンジニアの2人だけでした。我々が入った直後にマネージャの計らいで、環境と権限を持つ人を拡大するところまでは進められたものの、実際に障害対応できるようになってもらうための育成のプランはまだない状態でした。やり方を短期間で伝承することができないか、普段の障害対応時の行動を見直してみると、

本番システムに変更を加える操作は立ち会い必須なので、対処方針が決まった後は複数人で作業してる
そこに至るまでの調査、切り分けは該当箇所に詳しいメンバが一人でやってしまっている
初動から調査、切り分けをする過程を学ぶ機会がない

ということに気付きました。

影響が大きい障害が起きた時は複数人で調査にあたったり、対処後に進め方を共有してふりかえりを開催するけど、普段から起きている小さめの障害では調査の過程で学ぶ機会を捨ててしまっている。ここでもし、調査や切り分けを詳しいメンバがやるのを横で見てる、あるいは詳しいメンバに指示してもらって一緒に調査、切り分けをやったら、短期間で障害切り分けができるメンバを増やせるんじゃないかと思い、

障害調査するときは必ず複数人でやることにしようとチーム内で宣言
言ったからにはまずは自分から、調査するときに誰かに声をかけて一緒に見てもらう

をやってみました。

実際やってみると、横で見てて気になったことや指示を受けてやる内容について積極的に質問してくれて、育成の目的を十分に果たせるのは期待通りだったのですが、ペアで常に説明しながら作業することで、立ち止まったり横道に逸れそうなとき即座に進路修正して前に進むので、詳しいメンバが一人でやっているよりも問題切り分けのスピードが高まるという期待してなかった効果が得られました。

しばらくすると障害切り分けのペアワークはチーム内で定着し、それとは別に、障害が発生した想定での訓練や利用するツールのハンズオンをやったこともあって、障害対応を安心して任せられるメンバが増え、私が一人で疲弊してしまうという懸念は払拭されました！

みんなが困っていることをペアワークで解決

常に忙しい忙しいと余裕がない状態になっている原因として、何が辛いと感じているかをメンバから出してもらったところ、「リリース時間が長い問題」が上位にランクインしました。弊社のサービスは日中に利用されるお客様が多く、リリース起因の障害が発生してしまった場合の影響を抑えるため基本的に業務時間外にリリース作業をしています。リリースにかかる時間が長いことで残業が積み重なって疲労が蓄積しており、一方で大きなリリースで手戻りするリスクを避けるため小さなリリースを繰り返したいという事情があり、リリース頻度を減らして緩和するわけにも行かないというのがチームのつらみとしてありました。

幸いなことに最近追加されたメンバはまだ開発の本流には合流できておらず、今ならそのつらみを解消する活動ができるという状況を利用して、いっちょやったるかということで「リリース時間が長い問題」に取り組み始めました。実はリリース時間の問題は基盤開発チームに居た時にも相談を受けていて、デプロイツールの修正で時間短縮できそうというアイデアを持っていたので、それを幾つかのタスクに分割してペアプロでやりたいと言ったら数人が乗ってくれました。自分と誰かというペアでの設計実装を数回繰り返して、成果として2時間弱かかっていたリリース作業を30分以内に短縮でき、時差出勤すれば残業なしでリリースできるという状態を達成できました。

辛い状態が続いているところにどこの馬の骨ともわからない連中が入ってきて、コード書きながらしゃべり続けててうるさくしてたり、時折「やったー！」とか大きな声を上げたりして妙なことしてくれてるなと思われていたかもしれないですが、みんなが辛かったリリース時間の問題を解決したことで、ちょっと役に立つ仲間がやってきたぞと思ってもらえるようになったんじゃないかと思います。

ペアワークをデフォルトにしよう

障害対処とリリース時間をペアワークで改善でき、ペアワークもっとやろうよという雰囲気が高まってきたので、次はデフォルトの働き方をペアワークにするという試みを、まずは4人から成るサブチームから取り組むことにしました。

一週間でやるタスクを選んだ上でそれぞれの担当を決めて作業するという流れで開発していたので、まずは計画に乗ったタスクのうちペアワークをやるタスクを増やせばよかろうという単純な発想で、ペアワークできそうなタスク毎に計画時にもう一人の担当を決め、その組み合わせで各タスクをやってみることにしました。

ところが実際に一週間それでやってみたところ、意外とペアワークできてないぞという結果になり、状況を分析すると、

ひとつのタスクが終わったらペアの組み換えが発生するが、そのタイミングで次の相棒が空いてないと待ちになってしまう
待ってるのも何なのでとペアでやったほうがいいことをソロでやり始めてしまう
結果、思ったようにペアワークできてない

ということが見えてきて、どうしたら解消してもっとペアワークできるようになるかみんなで考えました。

ペアワークがデフォルトになった

考えた結果、個人にタスクを割り当てるんじゃなく、ペアに対してその週のタスクを割り当てたら、組み換えが自体が要らないのでうまくいくのではというアイデアが出ました。そこで

プランニングの最初にペアを決める
ペアに対してタスクを割り当てていく
ペアで一週間どう進めるかを計画する

というやり方にしたところ、ペアの組み換えの悩みはなくなり、微調整をしつつ数週間進めているうちに、ペアワークがデフォルトになりうまく回るようになりました。

当初はペアプロにより品質面の向上は期待していたものの、二人分のリソースを掛けることに対して、アウトプットのスピードは若干落ちるかよくて同じくらいだろうと予想していました。しかし実際にはアウトプットのスピードはむしろ上がっている（倍のリソースを掛けて、倍以上のアウトプットが出てきてる）のが見えています。

何故そんなことが起きたのでしょうか？ペアプロをしてなかった時は、リリースの前にプルリクエストを作成してコードレビューを受ける段階で