t_wada 氏にペアプログラミングについてご講演頂いた際の個人的メモ

今や @t_wada(和田卓人) 氏については私が説明しなくとも、皆さんご存知のことかと思います。そう、このライオンスタンドの人です（違わないけど違いますw

　　　　 ,、,,,、,,, 
　　　_,,;' '" '' ;;,, 
　　  （rヽ,;''""''゛゛;,ﾉｒ）　　　　 
　　 ,; i ___　、___iヽ゛;,　　テスト書いてないとかお前それ@t_wadaの前でも同じ事言えんの？
　 ,;'''| ヽ・〉 〈・ノ |ﾞ ';, 
　 ,;''"|　　▼　　 |ﾞ゛';, 
　 ,;''　ヽ ＿人＿  /　,;'_ 
 ／ｼ、    ヽ  ⌒⌒  /　 ﾘ　＼ 
|　　 "ｒ,,｀"'''ﾞ´　　　,,ﾐ| 
|　　 　 ﾘ、　　　　,ﾘ　　　 | 
|　　i 　゛ｒ、ﾉ,,ｒ" 　　　i _ | 
|　　｀ー――-----------┴ ⌒´ ） 
（ヽ  _____________ ,, ＿´） 
 （_⌒_______________ ,, ィ 
     T                 |
     |                 |

このAAは 日本Node.jsユーザグループ代表である @yusuke_furukawa 氏が遊びで作ったとかなんとかw 何故このようにテストの鬼みたいな方になったかというと、おそらく以下の二点かと思います。

◯ 1点目：power-assert という npm パッケージを開発されたから

www.npmjs.com

このパッケージは名前の通り、自動テストをサポートするアサーションツールです。このパッケージのロゴを見ますとライオンの画像が使用されており、おそらく古川氏もこれを見てライオンのAAを作成したのだと予想しますw

◯ 2点目：Kent Beck 氏著「Test-Driven Development By Example」を日本語訳した書籍「テスト駆動開発」を出版されたから

テスト駆動開発

ご自身もテスト駆動開発の良さについて様々な勉強会で何度もご登壇されたり、企業に招待され講演されております。

このように、テストについて造詣が深くかつテストについての発信を度々されていることから、t_wada 氏はテストの権化のような印象が持たれたのかと思います。（もちろんライオンの人、の印象もw）

講演内容のメモ

ここからは個人的に感銘を受けたり、学びになったことを列挙的にメモしたことを書き連ねていきたいと思います。あくまで私個人の理解や咀嚼の仕方なので、t_wada 氏の言葉どおりとは限りませんので、ご了承いただければと思います。それではどうぞ。

↓↓↓

• ペアプロの役割の名前

  • ドライバー(driver)
  • ナビゲーター(navigator)
  • 由来はおそらく車のラリーカーレースから (edited)

• ペアプロをしていると集中力が増す

  • 個人だとツイッターをやってしまう
  • ペアプロなら相方がいるので、余計なことをしない

• 可読性・保守性も上がる

  • もう一人が読めないコードを書いてはダメ
  • もう一人が理解できないコードを書いてはダメ
  • 自動的にダブルチェックをすることになる

• thinking out loud

• ベアプログラミング

  • 即時フィードバック
  • 心理的ハードルを下げ、安全性を上げる
  • ペアプロ = ojt といえなくもない

• ペアプロは教育効果が高い

  • 結果の共有ではなく、過程の共有
  • 技術力の底上げ
  • 暗黙知の共有 ←これデカい
  • （下からコードを書くだと…？考えたことなかった）

• コードを書く瞬間の思考にアドバイスを貰える

  • これはペアプロの他に方法がない

• 楽しさ も大きい。

  • チームビルディングにもなる
  • 生産性があがる

• 大事なこと

  • ナビゲーターだけが喋るのではなく、ともに喋る
  • ドライバーも説明する必要があるので
  • デカいモニタ重要
  • 指差し確認大事

• ペアプロは3時間も保てば良い方

• こんなときに効果を発揮する

  • 新機能開発
  • チームに誰か入って来た時
  • 不具合修正
  • 先輩や経験者のカンなどの暗黙知を教えてもらえる効果
    • なかなか言語化されてないものを知れる

• ペアプロ導入の申請の仕方

  • ペアプロ ではなく、ダブルチェック体制 と言えば良い

• エクストリームプログラミング(XP)
  ↓

• スクラム開発

• ペアプロが生まれた時代はアジャイルが生まれ始めた時代

• 罠たち

  • 手戻りは減らせるが、在庫は減らせない (WIP PR)
  • 稼働率の罠
  • 効果測定の対象が混在
  • スループットが出なく、ボトルネックが発生する罠もある
  • レビューがボトルネックになりがち

• レビューの工数を減らせるのが良い → ペアプロ

• 「リードタイム」=「コードを書き始めて、リリース、実際に使われるまでの時間」

  • コードを書き終わるまで、ではない
  • レビューで止まってたら意味がない
  • 要は、一つずつのタスクを確実に完了させてスループットを上げる
  • 稼働率よりスループット

• ベテランにしてみれば、自分の知識の棚卸しとアップデートできる可能性があることが大きい

• もちろんペアプロの押し付けはだめ
• 食わず嫌いもだめ
• 詳しくは → web+db press vol.102

gihyo.jp

以上、ではでは(=ﾟωﾟ)ﾉ