nikkie-ftnextの日記

イベントレポートや読書メモを発信

週末読書ログ | ペアプログラミングをさがして

はじめに

頑張れば、何かがあるって、信じてる。nikkieです。

2人のプログラマーでコードを書くペアプログラミングについて、この週末インプットをしました。
現時点のバックアップとしてアウトプットします。

目次

nikkieのペアプログラミング、これまで

ペアプログラミングの経験は2年半ほど。
XPを実践するユーザベースの開発チームで毎日楽しく開発しています。
1人では浮かばなかった設計・実装・進め方に至れたときは本当に気持ちいいですね!

以下のペアプロの心得は(そんなに頻繁にはやれていないですが)定期的に見返します。

ペアプロの心得 · GitHub

ユーザベース Tech Blogの「アジャイル」タグにはペアプロについての記事もあり、参考にしています。

ケント・ベックエクストリームプログラミング

ペアプログラミングをやっていくにあたり、XPの提唱者 ケント・ベック氏の著書からインプット。
第2版で読んでいます。

この本は達人の言という感じで、「7.5 ペアプログラミング」を読んでもわかったようなわからないような・・・

同じマシンを前にした2人で、本番用のすべてのプログラムを書くこと。

「2人」は交代しますし、「プログラムを書く=実装」ではなくて設計やテストもペアでやります。

Uncle Bob『Clean Agile

やってみると「これでいいんだっけ?」となるもので、ちょっとでも具体的な記述を求めて手を伸ばしたのが『Clean Agile』。

第5章 テクニカルプラクティスの中の1項目として詳しめに書かれています。
詳しめなところは一般的というよりUncle Bob流といった趣ですね(今回いろいろな文献を読んで気づきました1)。

今回のインプット

『アート・オブ・アジャイル デベロップメント』

読書会改めビデオ鑑賞会に継続参加中2の『アート・オブ・アジャイル デベロップメント』。
2版を英語で読んでいますが、「初版(日本語)を改めて読んでみてもいいかも」と思い、今回読んでみました。

5.1がペアプログラミングです3
2版で読んだ話題が出てきて、「ここは変わってないんだなあ」としみじみ読みました。

「Promiscuous pairing and Beginner’s mind」

『アート・オブ・アジャイル デベロップメント』の参考文献に挙がっていたベルシー氏による論文(2005年)。

Promiscuous pairing(訳してみるなら、無差別ペアリング)の事例です。
90分でペアの1人を交代、開発者1人あたりあえて180分しか連続してタスクに取り組めないようにし、初心者マインド(Beginner’s mind)をうまく使うという手法の紹介。

時間を区切って読みましたが、次の『スクラム現場ガイド』でわかりやすく紹介されてました。

スクラム現場ガイド』

『アート・オブ・アジャイル デベロップメント』の参考文献ではベルシー氏の論文と合わせて、Lacey氏の論文(2006年)も挙がっていました。
ただこれはWebに公開されているものがパッと見つかりませんでした。

調べる中でLacey氏が『スクラム現場ガイド』を書いていることを知り、目次を見ると19章がペアプログラミングの章!
プロミスキャスペアリング(Promiscuous pairing)と、もう1つマイクロペアリングが取り上げられています。

スクラム」を冠した本はノーマークでした。
こんなに詳細にペアプログラミングについて書いてあるなんて!

ペアプログラミングについての気付き

現時点の自分の伸びしろかなという点を2つアウトプットします。

ナビゲータは戦術ではなくて、"戦略"担当

ペアプログラミングには、ドライバーとナビゲータの2つの役割があり、役割を(細かく)入れ替えながらタスクを進めていきます。
スクラム現場ガイド』ではドライバーとナビゲータという言い方が出てこないみたいなんですよね。
おそらく以下の対応だと思います:

  • ドライバー:戦術担当
  • ナビゲータ:戦略担当

『アート・オブ・アジャイル デベロップメント』にはナビゲータについての記述が多く、「ナビゲータって具体的にはこんなこと考えるんだ!」とかなり参考になりました。

私の場合、Pythonが好きすぎるので、Pythonの書き方(=戦術)を重視しがちなのですが、それだとナビゲータはドライバーの数歩先の状態には行きづらいな、と。
ナビゲータは、戦略担当として数歩先にいて、全体を見て考える役割。
「戦術へのこだわりをこれまでよりも捨て去って、全体の設計の中でどう位置づけるかを考えるように変えよう」と気付きました。

1人で実装しているときは、全力出して作った後に「もっと良い設計にできるじゃん!」と気付くのですが、ナビゲータは全力で実装しているドライバーと違って、設計全体が見える立場!
これは自分の伸びしろを伸ばす練習にもなるなと結構ワクワクしています。

なぜペアを替えるのか:初心者マインド

もう1つはペアの交代について。
ベルシー氏論文には図があり(Figure 2)、90分での交代が一番ベロシティが高くなるとあります。
どのチームも90分がベストかは分からず、自チームのフィードバックを得たいところですが、「なぜペアを替えるのか」の理由を考える機会となったのが面白かったです。

スクラム現場ガイド』19章によると、プロミスキャスペアリングは初心者マインドを活かすプラクティス。
初心者マインドを使ってチームの生産性を上げるポイントは以下にあるように思われました(ベルシー氏論文からの引用の日本語訳です)。

人は1つだけ理解できない点があって、それさえなければ安心できるという状況にいると、その点が解決するまでいろいろなことを試そうとする (2-1)

この点から「最大で180分程度しか1つのタスクに取り組めないならば、いろいろなことにペアの関心を広げず、"1つだけ理解できない点がある"という状態とその解決を細かく何回もペアで繰り返して、タスクのゴールに向かえばいいのではないか」と考えています。

また、プロミスキャスペアリングにおける「設計コンセプトカード」はぜひ試してみたいなと思っています。

終わりに

ペアプログラミングについての読書ログと、そこからの気付きのアウトプットでした。
ペアプログラミング、新しい視点で見えるようになった気がする!(アンラーンというか、これも1つの初心者マインド?)

思うに、誰しもアジャイルの旅の途中にいる4
得た知見を元に、実践する日々!
XPの旅は続くのです。


(『アート・オブ・アジャイル デベロップメント』はオライリーさんでPDFが現実的かもしれません)


  1. 狙ったわけではないですが、先日聞いた3️⃣の実践になってる!「技術書」の読書術を達人に聞いてみた - Forkwell Library #10 - connpassの増井さんのお話です。
  2. 2022/05の記事です:近況報告:『The Art of Agile Development Second edition』の読書会に参加しています #agile_devs - nikkie-ftnextの日記
  3. 英語版が公開されています。要約やhaikuも付いている! James Shore: The Art of Agile Development: Pair Programming
  4. 恥ずかしいセリフ禁止