ここ数日、私はずっとペアプログラミングをしている。
ペアプログラミング自体は、これまでに何度も経験したことがある。
しかし今回の試みが今までと違うのは、
一日中、ペアプログラミングしかしないという点である。
1セット1時間半、15分の休憩を入れて、
ドライバーとナビゲーターを交互に入れ替えて毎日4セットやる。
このところ、これを何日も続けている。
こうやって、ある程度ストイックに続けてみることで、
わかってきたことがある。
それは、ペアプログラミングにはメガトン級の破壊力があるということだ。
ペアプログラミング自体は、これまでに何度も経験したことがある。
しかし今回の試みが今までと違うのは、
一日中、ペアプログラミングしかしないという点である。
1セット1時間半、15分の休憩を入れて、
ドライバーとナビゲーターを交互に入れ替えて毎日4セットやる。
このところ、これを何日も続けている。
こうやって、ある程度ストイックに続けてみることで、
わかってきたことがある。
それは、ペアプログラミングにはメガトン級の破壊力があるということだ。
■ 人に言えないこと
プログラマーは絶えず誘惑にさらされている。
調べ物でウェブを見たついでに何時間もネットサーフィンしてしまったり、
考えたことをメモするついでに2時間かけてブログを書いてしまったり、
仕事の用事で知人に IM したついでにしばらくだべってしまったり、
Twitter に書き込んだついでに Friends のアーカイブを読みふけってしまったり、
PC は仕事道具であると同時に遊び道具でもあるので、
納期直前かゾーン状態でもない限り、
これらの誘惑はしばしばプログラマーの集中力を奪い去る。
プログラマーは自分自身のコンディションによって
生産性に何倍もの差が出ることを知っている。
だから、テンションがピークに達するまではあえて何もしないことも多い。
このあたりの生々しい事情はジョエル・オン・ソフトウェアの
「射撃しつつ前進」に詳しい。
このようなプログラマーの日常を考慮して、
実は多くの会社は20%ルールを取り入れたのと同じ状態と指摘する人もいる。
■ 見られて綺麗になる
そして、もう一つ忘れてはいけないこと。
プログラマーにはプライドがある。
自分が華麗にソフトウェアをつくりあげていく姿を人に見せたい願望がある。
だから、
プログラミングをしているシーンが誰かに見られる機会さえあれば、
誰よりも速く、誰よりも美しく、
魔法のようにキーボードの上で踊る自分の姿を見せたくてウズウズしている。
行き詰って悶々としている姿なんて見せたくない。
プログラマーとして、サプライズを与えたいんだ。
ペアプログラミングはライブコーディングよりも、
コミュニケーションがずっと繊細だ。
そこにあるのは、誰が言ったかもわからない野次のようなコメントじゃない。
時間をかけて丁寧に、見て、見られて、
プログラマーの能力も、プログラム自体も、
人に見られて磨きをかけられていく。
■ そして、ペアプログラミングが始まる
ペアプログラミングをやってみたことがある人はかなり多いのではないかと思う。
部分的にペアプログラミングを導入する場合、
その対象となるのは、例えば次のようなものだ。
・教育目的で OJT としてペアプログラミング
・一人では解決が難しい問題に対処するためにペアプログラミング
・担当パートの引継ぎのためにペアプログラミング
アプレッソでこれまでやってきたペアプログラミングも、
上のような理由で行われてきたものがほとんどだった。
つまり、これまでは、ペアプログラミングを導入する明確な理由があった。
今回の試みでわかったことは、
上記のような、いかにもペアプログラミングが有効な場合だけに
ペアプログラミングを導入するのではなく、
一日の開発作業全部にペアプログラミングを導入することに
爆発的な効果があるということだ。
新規に開発をする場合にも、
テストケースを書くときにも、
バグ修正をする場合にも、
修正内容を BTS にレポートする時にも、
一見地味で、「後は自分でやっておきます」と言いたくなるような
作業も含めて、全部ペアプログラミングで行う。
ずっと見られているから、ペアプログラミング中には
手の抜きようもなければ、気の抜きようもない。
そういう状態が長く続くと、
今まで刺激されたことのないツボをずっと刺激されているような、
独特の快感の中で開発作業を進めていくことができるようになってくる。
そして気付くと、今までよりずっと短い時間で、開発がグングンと進んでいる。
関連エントリ
・アプレッソのジョエル・テスト判定結果
・プログラム・デザイナー宣言
・諸君、私はプログラミングが好きだ
プログラマーは絶えず誘惑にさらされている。
調べ物でウェブを見たついでに何時間もネットサーフィンしてしまったり、
考えたことをメモするついでに2時間かけてブログを書いてしまったり、
仕事の用事で知人に IM したついでにしばらくだべってしまったり、
Twitter に書き込んだついでに Friends のアーカイブを読みふけってしまったり、
PC は仕事道具であると同時に遊び道具でもあるので、
納期直前かゾーン状態でもない限り、
これらの誘惑はしばしばプログラマーの集中力を奪い去る。
プログラマーは自分自身のコンディションによって
生産性に何倍もの差が出ることを知っている。
だから、テンションがピークに達するまではあえて何もしないことも多い。
このあたりの生々しい事情はジョエル・オン・ソフトウェアの
「射撃しつつ前進」に詳しい。
このようなプログラマーの日常を考慮して、
実は多くの会社は20%ルールを取り入れたのと同じ状態と指摘する人もいる。
■ 見られて綺麗になる
そして、もう一つ忘れてはいけないこと。
プログラマーにはプライドがある。
自分が華麗にソフトウェアをつくりあげていく姿を人に見せたい願望がある。
だから、
プログラミングをしているシーンが誰かに見られる機会さえあれば、
誰よりも速く、誰よりも美しく、
魔法のようにキーボードの上で踊る自分の姿を見せたくてウズウズしている。
行き詰って悶々としている姿なんて見せたくない。
プログラマーとして、サプライズを与えたいんだ。
ペアプログラミングはライブコーディングよりも、
コミュニケーションがずっと繊細だ。
そこにあるのは、誰が言ったかもわからない野次のようなコメントじゃない。
時間をかけて丁寧に、見て、見られて、
プログラマーの能力も、プログラム自体も、
人に見られて磨きをかけられていく。
■ そして、ペアプログラミングが始まる
ペアプログラミングをやってみたことがある人はかなり多いのではないかと思う。
部分的にペアプログラミングを導入する場合、
その対象となるのは、例えば次のようなものだ。
・教育目的で OJT としてペアプログラミング
・一人では解決が難しい問題に対処するためにペアプログラミング
・担当パートの引継ぎのためにペアプログラミング
アプレッソでこれまでやってきたペアプログラミングも、
上のような理由で行われてきたものがほとんどだった。
つまり、これまでは、ペアプログラミングを導入する明確な理由があった。
今回の試みでわかったことは、
上記のような、いかにもペアプログラミングが有効な場合だけに
ペアプログラミングを導入するのではなく、
一日の開発作業全部にペアプログラミングを導入することに
爆発的な効果があるということだ。
新規に開発をする場合にも、
テストケースを書くときにも、
バグ修正をする場合にも、
修正内容を BTS にレポートする時にも、
一見地味で、「後は自分でやっておきます」と言いたくなるような
作業も含めて、全部ペアプログラミングで行う。
ずっと見られているから、ペアプログラミング中には
手の抜きようもなければ、気の抜きようもない。
そういう状態が長く続くと、
今まで刺激されたことのないツボをずっと刺激されているような、
独特の快感の中で開発作業を進めていくことができるようになってくる。
そして気付くと、今までよりずっと短い時間で、開発がグングンと進んでいる。
関連エントリ
・アプレッソのジョエル・テスト判定結果
・プログラム・デザイナー宣言
・諸君、私はプログラミングが好きだ
XPエクストリーム・プログラミング入門―変化を受け入れる
posted with amazlet on 07.07.05
ケント ベック Kent Beck 長瀬 嘉秀 テクノロジックアート
ピアソンエデュケーション (2005/12)
売り上げランキング: 40183
ピアソンエデュケーション (2005/12)
売り上げランキング: 40183
コメント
コメント一覧 (9)
> 手の抜きようもなければ、気の抜きようもない。
なので、ペアプロには1日8時間、週40時間ルールがあるんですよね。
作業者アサイン2倍、残業なしというのは「作業品質向上は理想だが現実的でない」という理由で、導入検討すらしないマネージャが大半だと思いますが、実際には効果絶大だと思います。(後工程での手戻りが激減するので)
もっと成功事例が増えてほしいものですね。
ペアプログラミングをするとなると、開発者がラップトップで開発しているか、または十分に広い机がひとりひとりに与えられているかだと思うのですがどうでしょうか?
ちなみに私が働いている環境は、狭い机かつデスクトップなのでペアプログラミングが結構困難です(ソフトウェアで解決しようとしておりますが)。
物理的環境ですが、アプレッソではデスクトップを使っていて、机も特別に広いということはないと思います。
一つの机に向って、二人横に並んで座れるスペースがあれば基本的に問題ないのではないでしょうか。
返信頂いて気付いたのですが、机の広さというよりも、横の机や後ろの机との距離が狭いことがペアプログラミングしにくいことの最大の原因の様な気がしてきました。あと椅子がでかいことも。。。
何はともあれ色々工夫してみます。
私が思うに教育や引継ぎ時より開発時のほうが効率良いです
品質向上のみでなく作業効率向上にも貢献してる事をマネージャーに伝えたいですが「自分が気を抜かなきゃ良い」ってことなっちゃうんで難しいです
というのは、非常に採用したい開発手法ですが、工数見積上、ペアプログラミングで行う場合の値を単純に2倍にしてしまうとプロジェクトレビュー時にNGが出てしまうと思いますので。
厳密にデータを取ったわけではありませんが、1か月程やってみた感触としては、効率は変わらず(つまり、各自作業した場合と同じ程度進む)、品質は大幅に向上しています。
アプレッソで採用しているケースでは、特にテストケース作成やバグの修正で効果を発揮しています。
記事のアップからかなりタイムラグのあるコメントであるにもかかわらず、早々のお返事ありがとうございます。
それは有益な情報です。是非積極的に取り入れていきたいと思います。
ちなみにその際、スキルのバランスはどのようにとるのでしょうか?
フェロークラスのプログラマと新人さん、というのもありでしょうか?
それともほぼ同等スキルのほうが良いでしょうか?
もちろん、各自のモチベーションにも依存するとは思いますが…。
小野さんの記事、いつも楽しみにしております。
> フェロークラスのプログラマと新人さん、というのもありでしょうか?それともほぼ同等スキルのほうが良いでしょうか?
アプレッソでも両方試しているのですが、前者はベースのスキルアップにつながり、後者はこの円とりで書いたような恩恵があり、それぞれ効果がありました。
XP 本ではスキルの差がある場合にも1ヶ月ほどでその差はグッと縮まるだろうとありましたが、今回やってみた結果としても、スキルの差はかなりのスピードで縮まりました。