new takyam();

Qiitaぽい話はQiitaに書いていくことにする気がする http://qiita.com/takyam

ペアプログラミング エンジニアとしての指南書

ザッとだが、この本を読み終わったので簡単に感想などを。

ペアプログラミング―エンジニアとしての指南書

ペアプログラミング―エンジニアとしての指南書

  • 作者: ローリーウィリアムズ,ロバートケスラー,Laurie Williams,Robert Kessler,長瀬嘉秀,今野睦,テクノロジックアート
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2003/03
  • メディア: 単行本
  • 購入: 5人 クリック: 35回
  • この商品を含むブログ (29件) を見る

@hirocaster さんが、先日うちの会社にてTDD Bootcampの講演を行なっていただいた際にご紹介いただいた本です。

XPやAgileといった開発手法(プロジェクト手法)の書籍内で紹介される事は数あれど、ペアプログラミングについてのみを扱った和書ってコレ以外に無いのではないでしょうか?
少なくともAmazon内で探しても見つかりませんでした。

2003年3月に第1刷が出て以降、特に増刷されてるわけでもなく、今日の段階でAmazonでも「3点在庫あり。(入荷予定あり)」といったステータスで、手に入らなくなる可能性も無きにしもあらずですので、まだ読んでない方はぜひ買ってみてください。

というわけで、他の人にオススメできるくらいには、良い本だったと思います。

全5部、全27章構成です。

目次を簡単にご紹介。


第1部

  • 第1章 はじめに
  • 第2章 ペアプログラミング7つの神話
  • 第3章 ペアプログラミングの7つの相乗的な方法
  • 第4章 ペアプログラミングに対する管理的抵抗の克服
  • 第5章 同僚からのサポートおよび承認の獲得
  • 第6章 自発的なペアプログラミングへの移行
  • 第7章 問題点

第2部

  • 第8章 オフィスレイアウト
  • 第9章 ペアローテーション:コミュニケーション、ナレッジマネジメント、トレーニング
  • 第10章 その他の課題
  • 第11章 ペアプログラミング実践の秘訣

第3部 ペアプログラミングパートナー選択の原則

  • 第12章 専門家-専門家のペア
  • 第13章 専門家-平均的なペア
  • 第14章 専門家-新人のペア
  • 第15章 新人-新人のペア
  • 第16章 外向型-外向型のペア
  • 第17章 外向型-内向型のペア
  • 第18章 内向型-内向型のペア
  • 第19章 ジェンダーの問題
  • 第20章 文化問題
  • 第21章 プロドライバーの問題
  • 第22章 「私のパートナーは全くの負け犬だ」過剰な自尊心の問題
  • 第23章 「パートナーはすごく賢い」歌唱な自尊心の問題

第4部 ソフトウェア開発プロセスにおけるペアプログラミングのケーススタディ

  • 第24章 ソフトウェア開発プロセスケーススタディにおけるペアプログラミング:XP
  • 第25章 ソフトウェアケーススタディにおけるペアプログラミング:CSP

第5部 おわりに

  • 第26章 前進、限界の超越
  • 第27章 有能なペアプログラマの7つの習慣

付録

  • 付録A ペアプログラミングのチュートリアル
  • 付録B ペアプログラミングの経済上の分析
  • 付録C 授業におけるペアプログラミング
  • 付録D テスト駆動開発入門

というわけで、結構長くなりましたが、結構モリモリな内容になってる風に見えます。

表紙には、

  • 第1部:読者がペアプログラミングに関する深い理解を得ることが目的です。
  • 第2部:ペアプログラミング実践上の詳細を扱います。
  • 第3部:さまざまな種類のペアのメリットとデメリットを説明し、それぞれのペアに最も適した状況を示します。
  • 第4部:複数の方法論でのペアプログラミングに関する事例を2つ(XCPとCSP)採り上げます。
  • 第5部:将来の方向性を提案します。そして、「有能なペアプログラマの7つの習慣」を列挙します。

というふうに書いてありますが、ぶっちゃけ、第3部まででOKです。
全300ページくらいなので、4時間くらいで読めましたが、面倒だったら途中まででいいと思います。

まず、第1部・第2部で「ペアプロってこんなにすごいんやで!」って事が書いてあります。
どれくらいすごいのかというと、「2人でやっても、ソロプログラミング(1人でやるプログラミング)と同じ工数を出し、品質はソロプラグラミングよりかなりいいよ!」っていうのが、実験データをもとに紹介されています。

たとえば、開発の初期から最後までを、一人×複数でやった場合(ソロプログラマ)と、ペア×複数でやった場合(ペアプログラマ)のデータが載っています。


  ソロプログラマ ペアプログラマ
プロジェクト規模(KLOC) 20 520
チーム規模 4 12
労力(人月) 4 72
生産性(KLOC/人月) 5 7.2
生産性(KLOC/ペア月) - 14.4
ユニットテストの欠陥 107(5.34 欠陥/KLOC) 183(0.4欠陥/KLOC)
システム統合での欠陥 46(2.3 欠陥/KLOC) 82(0.2 欠陥/KLOC)

引用 P.42


生産性を1人対2人で比較しても、ペアプログラマのほうが高く、
欠陥にいたっては、10倍以上の差がつくという素晴らしい結果がでています。

このように、この本では開発の初期から最後までペアで作業する事を推奨しています。
私のイメージでは、ペアプロとは、

「HEY! JONY! ちょっと詰まったからペアプロやろうぜ!」
「OK! BOB! いまそっちにいくよ!」

みたいに、どっかのタイミングで、ペアを作成して、
それでもって数十分から数時間作業して、解散、というイメージでした。

Clean Coder プロフェッショナルプログラマへの道とかには、そういったイメージで描かれてたとおもいます。

なので、ペアプロってそういうものだーとばっかり思ってましたので、これはビツクリでした。

といったわけで、実際どれくらい普及していて、どれくらい信頼性が高いデータなのかは不明ですが、ペアプログラミングは夢のプラクティスだよ!感をすごいだしてます。


そんなこんなで、第1部、第2部でペアプロすげぇ!ってなったあとに、あとはひたすらケーススタディが書いてある感じです。

第3部のケーススタディを読むとわかるのは、「ペアプロには方法論なんて無い。人間同士がペアを組む以上、お互いが歩み寄らない限り軋轢が生まれるよね。目的に向かって歩み寄って、仲良くなって、爆進しようぜ!」という事。

どんなに凄いプログラマでも、「おいてめー!俺の言うとおりにやればいいんだよ!」っていう感じだと、ペアプロの意味がないし、無理にペアプロやらせるよりソロでやらせたほうがいいだろう。

逆に、お互いのナレッジを補強しあう良いペアが組めれば、ソロプログラマなんて目じゃない生産性で、高い品質のコードが産まれるだろう、という事。

そのために、たとえば「プロと新人の場合には、プロは忍耐を覚えることが大事だよ」といった心構えはが書いてあります。ひたすら書いてあります。いろんなバリエーションで書いてあります。


というわけで、データや実例をもとに、終始ペアプロの素晴らしさと、難しさを伝えてくれる良書だと思います。

とはいえ最終的には、「やってみねぇとわかんねぇなwww」となっちゃいますw
失敗するケースも書いてあり、その問題はシステムではなくて人なので、
「どんなプロジェクトにも恩恵を必ず与えるプラクティス」では無いからです。

早く誰かとやってみたいな〜