「ペアプログラミング」の版間の差分

提供: MonoBook
ナビゲーションに移動 検索に移動
imported>ProgrammingCH
2行目: 2行目:
  
 
== 概要 ==
 
== 概要 ==
ペアプログラミングは[[冗長化]]手法として広く知られている[[HDD]]の[[RAID]]構成を[[プログラマー]]という[[人的リソース]]に適用したものである。これにより[[デスマーチ]]突入率を大幅に抑えることができる。
+
ペアプログラミングは[[冗長化]]手法として広く知られている[[HDD]]の[[RAID]]構成を[[プログラマー]]という[[人的リソース]]に適用したものである。
  
なお、[[RAIDコントローラー]]に相当するプロジェクトの現場責任者(日本では[[システムエンジニア]]と呼ばれることが多い)が無能である場合は、ペアプログラミングの理想も虚しく、綺麗に空中分解する。そのような人物は[[バグ]]を抱えた[[不良品]]であり、迷わず[[リストラ]]して[[新品交換]]するのが望ましい。
 
  
ペアで業務に取り組むという行為は絶対の安全が求められる分野では常識となっており、たとえば航空機の機長と副機長や、チーム医療などでは当たり前の形態である。わざわざお硬く提唱される時点で知能指数の低い者が多い業界だということである。
+
ペアで業務に取り組むという行為は絶対の安全が求められる分野では常識となっており、たとえば航空機の機長と副機長や、チーム医療などでは当たり前の形態である。
  
 
よってペアプログラミングという概念は[[プログラマー]]に限ったものではなく、営業職なども基本的にペアで行動するようにしている企業も少なからず存在している。ペア行動の有無は[[ブラック企業]]を判別する手法としても注目が集まる。2014年3月ごろから発生した[[すき家]]の[[パワーアップ工事]]も[[ワンオペ]]が原因のひとつと言われている。
 
よってペアプログラミングという概念は[[プログラマー]]に限ったものではなく、営業職なども基本的にペアで行動するようにしている企業も少なからず存在している。ペア行動の有無は[[ブラック企業]]を判別する手法としても注目が集まる。2014年3月ごろから発生した[[すき家]]の[[パワーアップ工事]]も[[ワンオペ]]が原因のひとつと言われている。
27行目: 26行目:
  
 
=== 勤労意欲の向上 ===
 
=== 勤労意欲の向上 ===
ペアプログラミングを行うことでチームの各人が互いをよりよく知ることができ、結束力を生み出しやすい。またペアプログラミングの方が1人で作業するよりも楽しいと感じる開発者もいる。これは友達の少ない[[プログラマー]]の[[コミュ力]]を向上させることにもつながることであろう。
+
ペアプログラミングを行うことでチームの各人が互いをよりよく知ることができ、結束力を生み出しやすい。またペアプログラミングの方が1人で作業するよりも楽しいと感じる開発者もいる。
  
 
=== 集団的なコード所有権 ===
 
=== 集団的なコード所有権 ===
38行目: 37行目:
 
経験を積んだ開発者によっては、初心者とのペアプログラミングを一種の退屈な指導と捉える場合もある。一部の技術者は1人で作業することを好み、ペアでの作業を面倒と感じる場合もある。
 
経験を積んだ開発者によっては、初心者とのペアプログラミングを一種の退屈な指導と捉える場合もある。一部の技術者は1人で作業することを好み、ペアでの作業を面倒と感じる場合もある。
  
これは上級者側の[[コミュ力]]不足、[[指導力]]不足であるともいえ、そのような人物は[[RAプログラム]]の対象としても差し支えない。
+
また、ペアの組み合わせによっては双方が「よくわからんけどあいつはしっかりやるし大丈夫だろう」の考えの元に行動してしまい、結果として人件費を2倍かけたのにもかかわらず逆にチェックが杜撰になることもあるので注意が必要である。
  
また、ペアの組み合わせによっては双方が「よくわからんけどあいつはしっかりやるし大丈夫だろう」の考えの元に行動してしまい、結果として人件費を2倍かけたのにもかかわらず逆にチェックが杜撰になることもあるので注意が必要である。プロジェクトリーダーや人事はお互いが「あいつで大丈夫か」と思えるような人材同士(かつ険悪な関係にないもの)をペアにする必要があり、リーダーや人事の高い能力が求められる。
 
 
== 現実 ==
 
2人組であれば開発速度は落ちないどころか向上すると言われているが、目下の[[人件費]]が2倍になるという理由から、いわゆる[[IT土方]]が集う、いわゆる[[ブラック企業]]ではまず行われていない。そもそもそんな企業の人事やプロジェクトリーダーは能力不足によりまともに機能するペアを社内で構成することすらできず、ますますブラック化を加速させているのが実情と思われる。
 
 
[[システム]]を発注する顧客の場合は、「本当に完成品を納品してくれそうか」を測る指標として、[[見積]]段階でペアプログラミングを導入しているかを尋ねてみると良い。尋ねると良いどころか、必ず確認しておかなければ危険な点であるとう人もいる。
 
  
 
== 関連項目 ==
 
== 関連項目 ==

2014年11月8日 (土) 22:35時点における版

ペアプログラミング英語:pair programming)とは、大雑把にいうと職業プログラマー冗長化することである。

概要

ペアプログラミングは冗長化手法として広く知られているHDDRAID構成をプログラマーという人的リソースに適用したものである。


ペアで業務に取り組むという行為は絶対の安全が求められる分野では常識となっており、たとえば航空機の機長と副機長や、チーム医療などでは当たり前の形態である。

よってペアプログラミングという概念はプログラマーに限ったものではなく、営業職なども基本的にペアで行動するようにしている企業も少なからず存在している。ペア行動の有無はブラック企業を判別する手法としても注目が集まる。2014年3月ごろから発生したすき家パワーアップ工事ワンオペが原因のひとつと言われている。

利点

規範意識の増大

組合せ次第では、個人の作業よりもサボりにくく、ちゃんと作業を進める可能性が高い。なお組合せを間違えると2人してサボる。

よりよいコード

相乗効果により設計実装の質が向上することが期待される。2人組だと常にコードレビュー単体テストが行われているような状態になるため、後から読めないスパゲッティコードを抑制できる。

作業効率の向上

2人組だと1人で作業するときとは流れが変わる。1人がドライバーとなり、1人がナビゲーターとなるため、次に何をすべきかを考え込むといったことが少なくなる。

外乱要因に対する耐性

2人組だと「Excelの使い方がわからない」などといった、「助けてパソコンの大先生!」的な、いわゆるFAQな外乱要因に対しても耐性を示し、他の人が割り込んできても、一方が応対し、もう一方が作業を進められる。

多数の開発者による設計

ペアを頻繁に入れ替えれば、複数の人間が1つの機能の開発に関わることになる。これにより、よりよい設計が生み出され、たとえばあるペアが解決できない問題で作業が止まってしまっても、別のペアでは解決できることもある。

勤労意欲の向上

ペアプログラミングを行うことでチームの各人が互いをよりよく知ることができ、結束力を生み出しやすい。またペアプログラミングの方が1人で作業するよりも楽しいと感じる開発者もいる。

集団的なコード所有権

プロジェクトの全員がペアプログラミングを行い、頻繁にペアを組みかえる場合、そのコード全体について全員がそれなりの知識を共有することになる。

教育的側面

初心者であっても固有の知識(プログラミングテクニックなど)を持っているものである。ペアプログラミングでは、余計な手間をかけずにそのような知識をチーム全体で共有できる。

欠点

経験を積んだ開発者によっては、初心者とのペアプログラミングを一種の退屈な指導と捉える場合もある。一部の技術者は1人で作業することを好み、ペアでの作業を面倒と感じる場合もある。

また、ペアの組み合わせによっては双方が「よくわからんけどあいつはしっかりやるし大丈夫だろう」の考えの元に行動してしまい、結果として人件費を2倍かけたのにもかかわらず逆にチェックが杜撰になることもあるので注意が必要である。


関連項目

参考文献