ペアプログラミング、実践してますか? 70
ストーリー by mhatta
どうなんでしょ 部門より
どうなんでしょ 部門より
oldtype 曰く、
最近redditで議論になっていたのですが、/.Jの皆さんはペアプログラミングを仕事で実践していますか?
数年前からエクストリーム・プログラミングの一環として話題になり、2003年には解説書出版に合わせて/.Jのストーリーにもなり、一部研究によれば生産性が1人で作業した場合の2倍以上になるともされていますが、タレコミ子の周辺ではまだやっている人がいないのが現状です(私のいるところが遅れているだけかもしれません……)。また、「誰もが向いているわけではない」というような意見も見られます。
ペアプログラミングを職場で実践している/.Jerの感想を聞いてみたいです。
先生！ (スコア:5, おもしろおかしい)
Re:先生！ (スコア:1)
Re:先生！ (スコア:1)
周りにプログラマーが一人もいない環境はどうしようもないんですよええもう。
せいぜい一人で二役やってキモがられるのがオチという。
Re:先生！ (スコア:1)
なんで学校であんなこくなマネをするのかと疑問だったのだけれど、
実社会で必要になる場面があることを予見して、先生は鬼になったのか。
Re:先生！ (スコア:1)
Re:大丈夫 (スコア:2, 参考になる)
不思議なことに、なぜか周りの目も温かくなります。
クマ (スコア:5, おもしろおかしい)
http://www.amazon.co.jp/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%... [amazon.co.jp]
Re:クマ (スコア:5, おもしろおかしい)
えっと「ベアプログラミング」って言っちゃうとジョークか何かと思われそうですが、
質問責めに辟易した著者が「まずこのぬいぐるみに相談しろ。それでも解決しなかった時には聞きに来い」ってやったら、実際に質問に来る人の数が減ったって話ですね。
オカルトでもジョークでもなく「相談するためには状況を整理する必要があるが、その過程で問題点が見つかり解決するというのはよくあること」って話。
Re:クマ (スコア:1)
導入してみました (スコア:5, 興味深い)
交友がある人をペアにしましたが
全ペアで二人の関係が険悪になりました
その後ペアの組み直しをしましたが
それ以降はうまくいってるようです。
KentBeckのペア分類を参考にするより
自己主張が強い＆プライドが高い人をどうやって扱うかが 重要と感じました。
Re:導入してみました (スコア:4, 参考になる)
もう片方が、間違いを指摘しずらい雰囲気になってしまうから。
例えば航空業界で採用されている、ヒューマンファクター訓練
（CRM訓練）のようなものが今後必要になってくると思います。
----CRMについて（抜粋）----------------
http://www.jalcrew.jp/jca/public/cap-voice/cap-voice_1.htm [jalcrew.jp]
私達の仕事は、機長、副操縦士、航空機関士が、チームを組んで一つのフライトを
完遂します。チームで仕事をする時、どうしても権限を持った人、或いは経験を
持った人が主導権を握りがちです。機長は航空法上、運航の最終責任を負ってい
る反面、指揮、命令などの権限も持ち合わせています。一昔前の飛行機の世界で
は、機長の言うことは｢絶対｣といった風潮がありました。たとえ、それが間違っ
ていたとしても、なかなかそれを指摘しづらかったのです。本来、安全運航の為
には｢何が正しいのか｣と言う視点に立った考え方が必要です。しかし、｢誰が正し
いか｣と言う事でチームの判断が決まってしまった結果、本来起こらなくてもよか
った事故が起きてしまい、多数の尊い命が失われていきました。
そこで、人間関係に焦点を当てた訓練が必要、と言うことで、CRM訓練が始まりま
した。人は、他人から自分の間違いを指摘されることにはとても抵抗があります。
機長が、自分より年下で、経験も少ない副操縦士から指摘を受ける場合、素直に
聞く事が出来ない事もあります。｢聞く耳を持つ｣と言うことがCRMの大切な要素
の一つです。
-----------------------------------ここまで------------
ペアプログラミング以前に (スコア:4, すばらしい洞察)
---- ばくさん！＠一応IT土方
Re:ペアプログラミング以前に (スコア:1)
# 一人で２倍なら、ペアで２人なら４倍だな！と思った俺はバカ
Re:ペアプログラミング以前に (スコア:2, おもしろおかしい)
1200万ステップだ！とか考えてしまった俺よりマシ。
理想のペア (スコア:4, 参考になる)
操作は速いが業務はまるで分からんという人がペアで
仕事するというのは３次元ＣＡＤなどでよくあります。
両方できる専門家を育てるのが結構大変なので。
Re:理想のペア (スコア:4, 興味深い)
指示に従ってExcelマクロ駆使する俺みたいな
それまでは
「金の勘定も出来ない小僧が」「今時PC触れないなんて使えないジジイだ」
だったのに、大仕事が終わったあとは
「やるな、坊主」「爺さんもな」
みたいな戦友気分
何かが違うペアプログラミング (スコア:4, おもしろおかしい)
本来、人がペアになるはずなのに、
仕事がペアになってました。
一つの案件の問い合わせの返事待ちの間に、別の仕事をやって・・・
飽きてきたら入れ替えて。
小物だと、ペアどころじゃないですね。
人のケツ持ちまで含めたら何件平行線だったか、思い出したくも無い。
今ではそんなこともなくなりましたけどね～
4年前くらいが酷かったかなあ。
#ほら、今じゃ/.jを読み書きする余裕すらあるｗ
大学でのペアプログラミング実習 (スコア:3, 興味深い)
ペアワーク・マニュアル [keio.ac.jp]が、参考になります。
Re:大学でのペアプログラミング実習 (スコア:2, 興味深い)
さらに PairProgramming+TestFirstの導入に関する仮説 [keio.ac.jp]には、次のように書かれています。
Re:大学でのペアプログラミング実習 (スコア:1, おもしろおかしい)
メッセンジャーペアプロ (スコア:2, 興味深い)
疑問があると、相方に投げて、相方がその間に検索してメッセで答えを貼り付け。
コードはビルドが通らなくても逐次SVNで共有。
また、お互いに手が空いているときは、平行で開発。
普通のプログラミングはソフトウェアの完成にたいして責任が発生するので、ルーズになってしまうんだけど、
ペアプロだと、モジュールの完成にたいして責任が発生するので、高い緊張感を持って開発することが出来ました。
Re:メッセンジャーペアプロ (スコア:1, 興味深い)
一見、収集が付かなくなるような気がするんですが、
よろしければ、これのメリット（や実践して初めて判るデメリット）を教えてもらえますか?
Re:メッセンジャーペアプロ (スコア:2, 興味深い)
「○○の部分、ビルド通らないけど送っておいた。悪いけど、直してもらえない？」
一般にSVNにビルドが通らないのを突っ込んで何が問題かっていうと、
何故ビルドが通らないのかが共有されていないことが多いため。
だから、それさえ共有されていれば、特に問題ない感じでした。
もちろん、平行開発に近い時にそれをやられると、自分もビルドできなくなって死にますが。
告白 (スコア:2, おもしろおかしい)
僕とペアプログラミングしてください。
Re:告白 (スコア:2, おもしろおかしい)
Re:告白 (スコア:1, おもしろおかしい)
Re:告白 (スコア:1, おもしろおかしい)
# ○○に好きなプログラミング言語を入れてください。
Re:告白 (スコア:1, おもしろおかしい)
#HのことをCって言われなくなって幾星霜…
Re:はじめてのC (スコア:2, おもしろおかしい)
日本物産にあやまれ！！
Re:告白 (スコア:1)
標準的な出し入れするエッチですか…
そもそもXPやってますか？ (スコア:2, すばらしい洞察)
Re:そもそもXPやってますか？ (スコア:4, 興味深い)
自分はメーカー系のSEをやってます。環境的にXPのプラクティスの導入は無理と判断しました。しかし、XPの発想には感銘を受けたので、自分の裁量で可能な範囲内でウォーターフォール的発想を排除しています。
そもそも、プログラミングを下働きだと考えるマネジメントレベルの物の考え方が癌なので、この手のある意味当然の改善しかできないのが歯がゆいです。
Re:そもそもXPやってますか？ (スコア:1, すばらしい洞察)
業務知識を持たせないのが問題なのでは？？
Re:そもそもXPやってますか？ (スコア:3, 参考になる)
同じコンビで数年間やってきて、ある程度固まった開発スタイルです。
まだまだこれから変化するとは思いますが、現段階はこんな感じ。
・ペアプログラミング
本来は分業しているんですが、ここぞという時は同じコードに2人で向かいます。
「なんで動かないんだーうがああああ！」的葛藤が圧倒的に減りました。
一人だと解決できずに延々考えていたかもしれないと考えると、作業効率は上がっているのかなーと。
・YAGNI
1日スパンで実装目標を立てて、それを遂行しています。
1日でバージョン番号が10増えることもざらにあります。
1日で完結しない目標は立てません。
・共通の用語
2人の間でしか通じない造語が飛び交います。
「犬問題」「待ちぼうけ現象」など、他から見たら何のこっちゃ造語集が出来上がってます。
・開けた作業空間
常に手を動かし、常に喋っています。
思いついた問題は即発言するようにしています。
間に仕切りすらないので、密なコミュニケーションが可能です。
他にも独特な部分が結構あるんですが、とりあえず思いついた範囲で書いてみました。
... from rakehelly programmer.
Re:そもそもXPやってますか？ (スコア:1, 興味深い)
それは、ありがちですが大間違いですね。
原典と言える、ケント・ベック、マーチン・ファウラーの本を読めば、
計画性なんか無意味だ感性を信じろなんて事は書いていない事が解ります。
むしろ、反復型開発を思いつきにしないためにどうするか、でも楽しくやりたい、
出来たものが顧客が使ってくれるにはという事を、色々考えたからこそ、
ペアプログラミング等の形にしたと言えます。
ではどうして、思いつきの正当化という一面的な誤解が蔓延したのか？
おそらく、新しい仕組みを取り入れやすいベンチャー企業の自由な風土の与える印象で、
原典を読まないままXPなんだと早合点しちゃうからではないでしょうかね。
要は、細かく目標を区切ってリリースする反復型開発の一種と思えば理解しやすい。
ウォーターフォールが「丸投げ」「長期化」「出来たら要求と違っていた」
という事故を起こしがちだった点に対して、改善策を具体化標準化したものです。
もちろん、ウォーターフォールだって、要求フェイズと開発フェイズを
きちんと行った上でやって実施すれば、オフショアに出せるなどメリットはあります。
それが、しっかり出来ている人にはアジャイルとかエクストリームが胡散臭く見える、
新しい価値観に必要性を感じないというのは当然理解できます。
ただ、色々なSIerを見てきたけどパッケージ開発でないシステムの場合、
要求が出来ていないのに設計に進み、設計が済まないのに開発を始めないといけない、
そして手戻り多発になってる案件が少なくないですよね。
請負が悪いとか派遣が悪いとか、責任を一個人に押し付けて、
また同じ構造をイテレーションしていくエクストリーム・デスマーチ（笑）
Re:そもそもXPやってますか？ (スコア:1, 興味深い)
（名目上でも）全貌が決まらないのに、お客側が予算を取れるわけがありません。
なので、XPは社内プロジェクトや「なんでも屋」的人材派遣の時にお薦めです。
必然的にペア? (スコア:2, おもしろおかしい)
昔は「人の数 > 端末台数」だったので、 大勢に取り囲まれて、衆人環視の中でヤジに耐えつつプログラミングってのが多かったが、 これはペアプログラミングとは呼べないだろうな。
相方が壊されるという危惧… (スコア:2, 興味深い)
むしろ、そのような方の相方を頻繁に換える (日に2,3人？) ことで、ペア・プログラミングが実効的に実施されるのでしょう。
それができないのならば、「レベルの揃った外注を使いまわす」という、
“平均的な成果・現状”という名の“低いレベルに足並みをそろえさせることでマネージメント職務者 (だけ) がその場限りの安心を得る”
先のない鬱屈とした停滞気味の国内産業全般に見られる
“参加メンバの実感・実態としては、底なしの価値低減傾向”
が、このまま続いていき、産業構造そのものが
“はい、それまぁ～で～よぉ”
となるのではないでしょうか？
あるいは、こうも言えないでしょうか？
プロジェクトのキックオフ時点で、まず、管理職にコードを書かせてみるのです。
そして、「ここの大将は、この程度のプログラミング能力なんだ」ということについて、
管理者自身から末端のテスタまでの全員のコンセンサスを確立するべきです。
(多分)平均以下の技術レベルの者がマネージメントするという状況で、参加メンバそれぞれが
「それでは、そこに何を提供できるのか」
についてもプロジェクトの早期に明確化するでしょう。また
「メンバ自身が関わった工程での品質に対する責任感」云々
も育まれるのではないでしょうか？
更に、「出来ない君・伸びないチャン」のままでヒューマン・スキルだけを身に付けた者のマネージメントを
受けながら、何をどれだけの値段で提供できるのか？といった“自分の能力の真っ当な値段の感覚”というものも
身に付けられるのではないでしょうか？
「マネージメント」などという基本的には「接待業と同等のテクニック」でしかないものを無批判に「価値の高い能力」と前提することを、技術者全員が捨てるが先決かも知れません。
そこから、生産性云々の課題も真っ当な取り組みが出来るのだろうと予期しています。
市場価値を生むのは「モノを作っている」担当者なのであって、管理職はその価値が外部的要因でムザムザ損なわれないように配慮・対処するという「外向きの作業」での成果を事後的に測られるべき“二の次、三の次”な存在なのだということを広く技術者に認識させていくことが「エクストリーム」や「ペア」の最大の眼目ではないでしょうか？
そうであってこそ、“開けた”開発空間で作業できるのではないでしょうか？
関連ストーリ (スコア:1, 興味深い)
うちの場合 (スコア:1, おもしろおかしい)
独り言で問題解決しています
「間違った！」
「しまった！」
「ＯＫ！」
「次はライブラリの修正だ！」
「たのむぜ～！」
「おいおい！」
「俺って天才！？」
「うわー、死ねばいい～」
等と一人だけでも結構にぎやかで楽しいですよ
いや、これは違うか・・・
むしろ (スコア:0)
設計段階において、一人で悶々とするよりかペアで設計したほうが柔軟性がある気はします。
その場その場で問題点を討論しながら、より良い方法を探って行けるのと、問題点に気が付き
やすくなるという感じでしたね。
3人以上になったとたんに細かい意見(好み？)の相違に終始しがちになる気がします。
Re:むしろ (スコア:5, 興味深い)
現在，取り組んでいるプロジェクトでは， まさに，皆でホワイトボードを前に設計して， その後，ペアプログラミングを実践しています．
設計を全員ですることによって，実装のポイントや問題点を事前に共有することができます． さらに，設計を全員が把握しているので，以後のペアプログラミングもスムーズに 進めることができます．
誰かが書いた設計書をレビューするよりもずっと効率的です． 設計で議論した内容は，デジカメやWikiで記録しておき， お客さんに納める設計書は，これらの記録を参考にしながら， 実装が終わった段階，あるいはリリース直前に清書します．
ｳﾎｯ (スコア:0)
せかされる感じ (スコア:0)
Re:季節がら (スコア:1, おもしろおかしい)
＃ジャンプ・ペアもエクストリームといえるでしょう
Re:季節がら (スコア:1)
Re:力量差の調整はどうやってますか？ (スコア:2, 参考になる)
ペアプログラミングの場合，Bさんの仕事は二倍以上で進みません．たぶん普段と同じくらい．
Aさんの仕事はBさんと仕事を重なって行うのでほぼ0です．
という結論がダメ（１人で業務を負って，その人が倒れたら業務も共倒れ等）．
仕事である以上速い遅いはほとんど関係なくて『どうすれば正確に（仕様通り）プログラミングできるか？』『どうすればバグ発生率の軽減できるか？』という課題に対する１つのアプローチがペアプログラミング．
バグ発生率を抑える，もしくはプログラミング時の知見を複数人で共有／議論する事が，仕事全体のスループットを引き上げるという考えがペアプログラミングの根底にあります．なので一人でやった方が早いという目先のスループット（自分自身だけのスループット）を上げるような仕事はペアプログラミングに沿いません．
というより社会に沿いません．
# とは言っても人材とか人件費の問題もあるので，どんなプロジェクトにもペアプログラミングが適用できるとは限りません．
# また力量差が開きすぎると，極端なスループット低下や，士気の低下，またいじめにも発展する場合がある．
# なので同じ年代，同じ技量の人をペアでやらすのが効率良いとどっかの文献に書いてあった（ソース失念）．
Re:力量差の調整はどうやってますか？ (スコア:1, 興味深い)
ペアプログラミング素敵、無敵、もう夢中
Re:力量差の調整はどうやってますか？ (スコア:1)
# ペアプロの効果の一つとか言われてる。
Re:私がやれば、生産性は2倍以上になるだろう (スコア:1)
# ナイショ。でもID。