瀬宮の球拾いブログ

エンジニアだったはずが、みんなにヘイストかける方がチームに貢献できた男のブログ

俺たちのペアプロ戦記

論旨

  • いままでのタスクには困るところが結構あった
  • いままでのタスクの進め方を改善していったら、ペアプロになった
  • 最終的にペアプロになった
  • ペアプロがなぜすばらしいかを言葉ではなく心で理解できた

従来のやり方

私のチームはそれまでこんな感じでタスクを進めていました。

  • タスクの終了条件を決めてアサインされる。
  • タスクの仕様を説明される
  • プログラムする
  • レビュー受ける

問題点

ところが新プロダクトの開発を上のフローで進めるうちに、問題点が噴出しました

聞く側

  • プログラム中に細かいところを何度も聞きにいくのが面倒くさい
  • 確認待ちで作業が止まる
  • レビューが帰ってくるまでの待ち時間が長い。
    • 帰って来た頃には半分くらい忘れている
    • レビュー待ちの間に別のタスクを始めるので仕掛中のタスクがどんどん増える
    • レビュワーの指摘でタスクの仕様が変わる事がある その場合タスクが振り出しに戻る

聞かれる側

  • 何度も聞かれて作業が中断される
  • 聞くなら一回にしてほしい
  • レビュー依頼の件数が際限なくたまる
    • すこしでもレビューを貯めてしまうと、レビュー待ちしている人が別のタスクを始めてまた積んでいくので、レビュー待ちが複利で増える
    • merge間隔が開く
    • レビュー未了だとmergeできないため、 main branch から孫ブランチやひ孫ブランチが発生する。
  • 疑問点や質問を書いたり、細かく指摘を繰り返すレビューラリーが増える

問題の被害が無視しがたいレベルであり、作業スピードを悪化させました。 これでは目標リリース日までにリリースできません。 リリースできない場合、社長は激おこになり、我々はユーザーにその辺りの街灯に高く吊るされます

移行経過

我々はこれらの問題を解決すべく、いくつかのプラクティスを導入しました

  • 最初の段階でgithubのIssueで話し合うようにした
    => 要件が固まるので質問に行く頻度が減った
  • それでも話がまとまらない場合はホワイトボードで話し合った
  • レビュー依頼したときに以下の事をすることでレビューの回数と時間を圧縮
    • レビュー依頼時に背景知識について5分程度で説明
    • 重点的に見てほしい場所をdescriptionに記述
    • 横に座ってリアルタイムでレビュワーの疑問点や指摘に応える

プラクティスを順次導入する事で作業スピードは改善し、徹夜や終電を連発しましたがなんとかプロダクトを期日までにリリースすることができました。

最終的に

リリース後、別の開発で上のプラクティスを洗練させた結果、以下のプラクティスにたどり着きました。

  • 特定のタスクに対し、ホワイトボードの前に二人が座ってホワイトボード前と端末前を行き来しながらペア作業すれば以下の3つのフェーズをフィードバックを受けつつ高速に回転させられる。
    • 仕様策定
    • 実装
    • レビュー
  • タスク粒度が大きくても比較的とても短時間で完了できるため、二人が拘束されたとしても一人ずつ作業するより生産性が高い事が分かった。
  • 副次効果として、メンバーが密度の高い作業をこなすと短い時間で相当疲労するため、帰宅時間が早くなった。

これはなにかに似ていないでしょうか。
そう、ペアプロです。
ペアプロがなぜよいかが心で分かりました。
この瞬間私はペッシになりました

f:id:ShinSemiya:20141211132835j:plain