ペアプロと上司でないマネージャはすっぱいブドウ
開発者が楽しく仕事できる環境とはを読んで。
ペアプロについて
以前いた会社を辞める前に、引継ぎとして(そして個人的な実験を兼ねて)ペアプロをしてみたことがある。確かに効率的だった。近藤さんのおっしゃるような効能を容易く体感できる。僕は何一つドキュメントを書かなかったが、しかしこの引継ぎは「xxx引継ぎ資料20050806.doc」なんていうWordファイルを書いてこれを元に1時間プレゼンして、このファイルをファイルサーバの奥深くに格納するよりもはるかに効果的だった。
ヒント:そういう引継ぎはやらないよりは幾分ましだが、せいぜい「話題の映画のあらすじを教えてもらったから世間話ができる」という程度のご利益しかない。大事なことはいつだって行間に書いてあるのだ。
- ペアで作業を行うため仕事以外の事は一切できない(一人で作業しているとついついメールをチェックしたりウェブを見たりしてしまいます)
- 「これはあとからちゃんと作るから今は適当に作っておこう」という「とりあえず」なプログラムができにくく、プログラムの品質が上がる(「とりあえず」を放っておくとどんどんバグができてしまい、最終的な効率を大きく下げてしまいます)
- 作業者間のノウハウが共有され、スキル向上につながる(特に新人教育時には有効です)
しかしながらペアプログラミングはすっぱいブドウだ。優秀なプログラマならば誰だってペアプロが効率的であることが直感的に分かるはずだ。僕の知る限り優秀なプログラマは大抵就業時間の30%くらいしか労働しない。残り70%を使えるのは北斗神拳の伝承者くらいのものだ。(30%は言い過ぎかもしれない。こんなに働ける人は稀だ!)
これに関しては面白い記事がある。ジョエルソフトウェアより。
私の一日の多くはこんな感じだ: (1) 仕事にとりかかる。(2) emailをチェックしたり、Webを見たり、そのほかのことをする。(3) 仕事に取りかかる前にランチを取ったほうがいいと判断する。(4) ランチから戻る。(5) emailをチェックしたり、Webを見たり、そのほかのことをする。(6) いい加減はじめたほうがいいと心を決める。(7) emailをチェックしたり、Webを見たり、そのほかのことをする。(8) 本当に始めなきゃいけないと、再び決心する。(9) くそエディタを立ち上げる。(10) ノンストップでコードを書いていると、いつのまにか午後7:30になっている。
ステップ8とステップ9の間のどこかにバグがあるようだ、私は必ずしもこの溝を飛び越えられないからだ。私にとっては、ただ始めることが唯一困難なことなのだ。(中略)
たぶんこれが生産性の鍵なのだ: ただ始めること。ペアプログラミングが機能するときにそれがうまくいく理由は、たぶんペアプログラミング セッションを相棒とスケジュールするときには取りかかるために2人が力を合わせるからだ。
おそらくそういうことなのだ。従って、ペアプロで作業することを(技術者出身でない)CEOに納得させることは不可能に近いくらい困難であることが分かる。そのためには、自分が70%遊んでいることを自供するか、さもなければ相当トリッキーな手段を使うかしなければならないからだ。
偉くない管理職
これも正しいと思う。これまた、ジョエルソフトウェアから。
私のいた当時のMicrosoftでは、強力なプログラムマネージャのいるグループは非常に成功した製品を作り出した: Excel、Windows 95、Accessが頭に浮かぶ。(中略)ここに避けるべきことが3つある:
(中略)
3. コーダをプログラムマネージャの監督下に置かない。
これはちょっとした間違いだ。Microsoftのプログラムマネージャとして、私はExcelのVisual Basic (VBA)ストラテジーをデザインし、VBAをExcelにどのように実装すべきか、微細な詳細にいたるまで完全に仕様化した。(中略)奇妙なのは、私が職階の「最下層」にいたということだ。(中略)もし主席開発者のベン・ワルドマンが私が仕様書に書いたようなことを何もやりたくないと思っていたなら、彼は単にやらなかっただろう。テスタが私の仕様書に書いたことは完全にはテストできないと文句をつけてきたら、私はそれを単純化する必要があった。もしこれらの人々の誰かが私の部下であったなら、製品はそんなに良いものとはならなかっただろう。
これらのことはみなベストプラクティスの部類だと思うのだけれど、実施するのがとてもダルい(とりわけプログラマにとっては)。実施するための方策を3つくらい挙げるとするとこんな感じか。