書こうと思ったキッカケ

VSCodeのLive ShareやIntelliJのCode With Meなどリモート環境でペアプロをする上でのツールが発達しているのに対して、自身のソフトスキルやペアプロに関するナレッジが無いなと思っていたところ良さげな雑誌の回を発見したので、まとめておく。

WEB+DB PRESS Vol.102 2018

メキメキ人が育ちプロダクトの質を高めるという文言に惹かれた。

ペアプロ・モブプロとは

• ペアプロ（２人で分析・設計・開発・テストの工程を行うこと）
  

• モブプロ（２人で分析・設計・開発・テストの工程を行うこと）
  

ペアプロ・モブプロの効果

作業への集中力向上

• 監視効果（見られているという緊張感）
• 発話による思考整理
• コードの可読性・保守性の向上
  • リアルタイムに質の低いコードを指摘できる
  • なぜいけないのかその場で聞ける
• ミスに気づける
• 抜け漏れの防止

知識と学びの共有

• 技術力の底上げと高い教育効果
• 過程を学ぶことができる
• 暗黙知の共有
• ドメイン知識の共有

チームで開発することの楽しさ・一体感を共有できる

なぜペアプロ・モブプロなのか

ソフトウェア開発が事業そのものになっている

• コードの品質・変更容易性・開発速度がそのまま事業の運営上の品質や成長速度に直結する
  • 小さいサイクルを回せることが競争力になる
• GitHubの登場でプルリクエストレビューが一般化した

環境の変化

• GitHubでブランチ管理することにより平行開発が用意になり、作業待ちがなくなった
  • 稼働率の最大化
• 複数機能が同時リリースされることにより効果測定対象が混ざる
  • こまめに１個づつリリースできるのが効果測定上の観点では理想

GitHub時代の新たなボトルネック → プルリクエストのレビュー

• ボトルネック：　プルリクエストのレビュー
• 手戻り：　レビュー指摘の対応
• 在庫：　レビュー待ち

細かいリリースでサイクルが早くなったことやデプロイ容易性が上がったことなどで、プルリクエストのレビューがボトルネックとなる
↓
ビジネス理解・技術的背景のわかる人間がレビュアーに

• 結果
  • ベテランがコードを書くのをやめレビューに専念
  • レビュー速度を上げるためにレビューを簡略化

大きい手戻りを防ぐためWIP PR(未完成の状態のレビュー)が触れるとさらにレビュー待ちの在庫が増える

在庫を減らし、スループットを最大化するのがペアプロ・モブプロ

• 在庫の状態のコードは価値を生まない

手戻りを減らしビュー済みの状態のコードを早く作ることで即リリースできる状態を作るほうが全体のスループットは上がる可能性

ペアプロの進め方

コードを書く前に方針付けを行う

• 手戻りをなくすため
• 脱線を防ぐため

①最終目標を決める
②作業を箇条書きする（マークダウンを使うとよさそう）
③最初の目標を決める
④時間を見積る（筆者観点）

書きながら会話

• ドライバーが考えていることを口に出す
• ナビゲーターはよく聞き支える

ロール交代の基準

• 時間
• ステップ
  • プロダクトコード
  • テストコード
  • リファクタリング
• 自由に交代
  • 口で説明するより書いた方がわかりやすい場合

TDDはペアプロと相性がいい

• 目的が明確
• フェーズで交代しやすい

いつ行えばいいか

ペアプロが強みを持つ場面

• チームに新しい人が入ってきた時
  • キャッチアップ観点
• 深刻なバグのデバッグ・不具合修正を行う場合
  • 多様な観点と慎重さが必要
• 新機能を作る時
  • 致命的なバグの予防
  • 方針レベルの手戻りを予防
• 既存機能の改修が長期間にわたる時

手戻りが発生しそうな場合においては積極的に行うといい気がする

定期的にペアプロを行う

• 週のうちでペアプロ日と時間を決める
• 技術負債の返済日はペアプロと決める
  • したいと思いつつも手が出しにくいので

ペアの組み合わせ

• ベテランと新人
  • 教育とキャッチアップ
• ベテラン同士
  • 議論が必要
  • 難度が高い
  • プルリクエスト上で議論になりそうなトピック

新人同士は別のレビュアーが必要なために向かないかもしれない

息苦しさの対処方法

• ミスが多いので恥ずかしい
• 指摘されるのが窮屈

パーソナルスペースを意識

価値観を押し付けない

その他

• ペア以外にも伝わるように
  • 内容によってはチーム全体に共有
• ドライバーは積極的に意見を求める
• 知識の習得時に喜びを表現する
• チームの一体感を重視する

ビジネスサイドから理解を得るために

１つのタスクを２人以上で行うことに対して、プログラマーではないビジネスサイドから生産性に対する疑問が生じるような組織もあると存じております

• ベテランがレビュー対応に追われている状態は健全ではない（ボトルネック）
  • 最も技術的背景がわかる人間が能力を発揮できていない状態
  • 主担当ではないプロジェクトの会議に呼ばれすぎて自身のタスクが消化できなくなっているビジネスサイドマネージャーを例に出すといいかも
• レビューにかかるコストが下がること
• 手戻りが減ること
• 品質の高いプロダクトづくりができること
• 生産過程において、知識の共有・技術力の底上げができる行為であること
• チームで一体感を出すことにつながること

あたりを説明しつつ
タスクを消化しながらリモート下で不足しがちなコミュニケーションを取りつつ課題解決に臨める有効な方法だということを主張してみたらいいのではないでしょうか

感想

ペア同士のスキル差が大きい場合は
「こんなことも知らないの！！」とか思われていないかな？
みたいな羞恥心が出たりしますが、
知らないままレビュー時に差し戻す方が指摘側のコストは高いし
何よりチームの技術力の底上げという意味では知らないことが露呈すればするほどペアプロを行った意義があるとも言えるので、
知らないことに悲観的になるよりは、割り切って学びに貪欲になったほうが実りのあるチーム開発になるのではないかと思いました。