差分
ナビゲーションに移動
検索に移動
'''ペアプログラミング'''（英語：pair programming）とは、大雑把にいうと[[職業プログラマー]]を[[冗長化]]することである。
== 概要 ==
ペアプログラミングは、[[冗長化]]手法として広く知られている[[HDD]]の[[RAID]]構成を、[[プログラマー]]という[[人的リソース]]に適用したものである。これにより[[デスマーチ]]突入率を大幅に抑えることができる。
なお、[[プログラマー]]に限ったものではなく、オランダのフィリップスのように営業職もペア営業しているところも多い。
== 利点 ==
=== 規範意識の増大 ===
組合せ次第では、個人の作業よりもサボりにくく、ちゃんと作業を進める可能性が高い。なお組合せを間違えると2人してサボる。
=== よりよいコード ===
相乗効果により[[設計]]や[[実装]]の質が向上することが期待される。2人組だと常に[[コードレビュー]]と[[単体テスト]]が行われているような状態になるため、後から読めない[[スパゲッティコード]]を抑制できる。
=== 作業効率の向上 ===
2人組だと1人で作業するときとは流れが変わる。1人がドライバーとなり、1人がナビゲーターとなるため、次に何をすべきかを考え込むといったことが少なくなる。
=== 外乱要因に対する耐性 ===
2人組だと「[[Excel]]の使い方がわからない」などといった、「助けて[[パソコンの大先生]]！」的な、いわゆる[[FAQ]]な外乱要因に対しても耐性を示し、他の人が割り込んできても、一方が応対し、もう一方が作業を進められる。
=== 多数の開発者による設計 ===
ペアを頻繁に入れ替えれば、複数の人間が1つの機能の開発に関わることになる。これにより、よりよい[[設計]]が生み出され、たとえばあるペアが解決できない問題で作業が止まってしまっても、別のペアでは解決できることもある。
=== 勤労意欲の向上 ===
ペアプログラミングを行うことでチームの各人が互いをよりよく知ることができ、結束力を生み出しやすい。またペアプログラミングの方が1人で作業するよりも楽しいと感じる開発者もいる。これは友達の少ない[[プログラマー]]の[[コミュ力]]を向上させることにもつながることであろう。
=== 集団的なコード所有権 ===
プロジェクトの全員がペアプログラミングを行い、頻繁にペアを組みかえる場合、そのコード全体について全員がそれなりの知識を共有することになる。
=== 教育的側面 ===
初心者であっても固有の知識（プログラミングテクニックなど）を持っているものである。ペアプログラミングでは、余計な手間をかけずにそのような知識をチーム全体で共有できる。
== 欠点 ==
経験を積んだ開発者によっては、初心者とのペアプログラミングを一種の退屈な指導と捉える場合もある。一部の技術者は1人で作業することを好み、ペアでの作業を面倒と感じる場合もある。
これは上級者側の[[コミュ力]]不足、[[指導力]]不足であるともいえ、そのような人物は[[RAプログラム]]の対象としても差し支えない。
== 現実 ==
2人組であれば開発速度は落ちないどころか向上すると言われているが、目下の[[人件費]]が2倍になるという理由から、いわゆる[[IT土方]]が集う、いわゆる[[ブラック企業]]ではまず行われていない。
[[システム]]を発注する顧客の場合は、「本当に完成品を納品してくれそうか」を測る指標として、[[見積]]段階でペアプログラミングを導入しているかを尋ねてみると良い。尋ねると良いどころか、必ず確認しておかなければ危険な点であるとう人もいる。
== 関連項目 ==
* [[エクストリーム・プログラミング]]
== 参考文献 ==
{{reflist}}
{{stub}}
== 概要 ==
ペアプログラミングは、[[冗長化]]手法として広く知られている[[HDD]]の[[RAID]]構成を、[[プログラマー]]という[[人的リソース]]に適用したものである。これにより[[デスマーチ]]突入率を大幅に抑えることができる。
なお、[[プログラマー]]に限ったものではなく、オランダのフィリップスのように営業職もペア営業しているところも多い。
== 利点 ==
=== 規範意識の増大 ===
組合せ次第では、個人の作業よりもサボりにくく、ちゃんと作業を進める可能性が高い。なお組合せを間違えると2人してサボる。
=== よりよいコード ===
相乗効果により[[設計]]や[[実装]]の質が向上することが期待される。2人組だと常に[[コードレビュー]]と[[単体テスト]]が行われているような状態になるため、後から読めない[[スパゲッティコード]]を抑制できる。
=== 作業効率の向上 ===
2人組だと1人で作業するときとは流れが変わる。1人がドライバーとなり、1人がナビゲーターとなるため、次に何をすべきかを考え込むといったことが少なくなる。
=== 外乱要因に対する耐性 ===
2人組だと「[[Excel]]の使い方がわからない」などといった、「助けて[[パソコンの大先生]]！」的な、いわゆる[[FAQ]]な外乱要因に対しても耐性を示し、他の人が割り込んできても、一方が応対し、もう一方が作業を進められる。
=== 多数の開発者による設計 ===
ペアを頻繁に入れ替えれば、複数の人間が1つの機能の開発に関わることになる。これにより、よりよい[[設計]]が生み出され、たとえばあるペアが解決できない問題で作業が止まってしまっても、別のペアでは解決できることもある。
=== 勤労意欲の向上 ===
ペアプログラミングを行うことでチームの各人が互いをよりよく知ることができ、結束力を生み出しやすい。またペアプログラミングの方が1人で作業するよりも楽しいと感じる開発者もいる。これは友達の少ない[[プログラマー]]の[[コミュ力]]を向上させることにもつながることであろう。
=== 集団的なコード所有権 ===
プロジェクトの全員がペアプログラミングを行い、頻繁にペアを組みかえる場合、そのコード全体について全員がそれなりの知識を共有することになる。
=== 教育的側面 ===
初心者であっても固有の知識（プログラミングテクニックなど）を持っているものである。ペアプログラミングでは、余計な手間をかけずにそのような知識をチーム全体で共有できる。
== 欠点 ==
経験を積んだ開発者によっては、初心者とのペアプログラミングを一種の退屈な指導と捉える場合もある。一部の技術者は1人で作業することを好み、ペアでの作業を面倒と感じる場合もある。
これは上級者側の[[コミュ力]]不足、[[指導力]]不足であるともいえ、そのような人物は[[RAプログラム]]の対象としても差し支えない。
== 現実 ==
2人組であれば開発速度は落ちないどころか向上すると言われているが、目下の[[人件費]]が2倍になるという理由から、いわゆる[[IT土方]]が集う、いわゆる[[ブラック企業]]ではまず行われていない。
[[システム]]を発注する顧客の場合は、「本当に完成品を納品してくれそうか」を測る指標として、[[見積]]段階でペアプログラミングを導入しているかを尋ねてみると良い。尋ねると良いどころか、必ず確認しておかなければ危険な点であるとう人もいる。
== 関連項目 ==
* [[エクストリーム・プログラミング]]
== 参考文献 ==
{{reflist}}
{{stub}}
