「ペアプログラミング」の版間の差分
imported>ProgrammingCH |
(うー>言う) |
||
(5人の利用者による、間の10版が非表示) | |||
6行目: | 6行目: | ||
なお、[[RAIDコントローラー]]に相当するプロジェクトの現場責任者(日本では[[システムエンジニア]]と呼ばれることが多い)が無能である場合は、ペアプログラミングの理想も虚しく、綺麗に空中分解する。そのような人物は[[バグ]]を抱えた[[不良品]]であり、迷わず[[リストラ]]して[[新品交換]]するのが望ましい。 | なお、[[RAIDコントローラー]]に相当するプロジェクトの現場責任者(日本では[[システムエンジニア]]と呼ばれることが多い)が無能である場合は、ペアプログラミングの理想も虚しく、綺麗に空中分解する。そのような人物は[[バグ]]を抱えた[[不良品]]であり、迷わず[[リストラ]]して[[新品交換]]するのが望ましい。 | ||
− | + | [[副作用]]を軽減する効果がある。 | |
− | + | ==他業種ではあたりまえ== | |
+ | ペアで業務に取り組むという行為は絶対の安全が求められる分野では常識となっており、たとえば航空機の機長と副機長や、チーム医療などでは当たり前の形態である。刑事ドラマの警察官も2人組、覆面パトカーでドライブしている警察官も2人組が基本である。つまり「ペア」いう概念は[[プログラマー]]に限ったものではない。某外資系電機メーカーなど、一部の企業では営業職なども基本的にペアで行動するようにしているところも少なからず存在している。 | ||
+ | |||
+ | わざわざお硬く提唱される時点で知能指数の低い者が多い(多くなった)業界だということである。 | ||
+ | |||
+ | ペア行動の有無は[[ブラック企業]]を判別する手法としても注目が集まる。2014年3月ごろから発生した[[すき家]]の[[パワーアップ工事]]も[[ワンオペ]]が原因のひとつと言われている。 | ||
== 利点 == | == 利点 == | ||
15行目: | 20行目: | ||
=== よりよいコード === | === よりよいコード === | ||
− | 相乗効果により[[設計]]や[[実装]]の質が向上することが期待される。2人組だと常に[[コードレビュー]]と[[単体テスト]]が行われているような状態になるため、後から読めない[[スパゲッティコード]] | + | 相乗効果により[[設計]]や[[実装]]の質が向上することが期待される。2人組だと常に[[コードレビュー]]と[[単体テスト]]が行われているような状態になるため、後から読めない[[スパゲッティコード]]を抑制できる。とくに[[中級者病]]の抑制には強い効果を発揮する。 |
=== 作業効率の向上 === | === 作業効率の向上 === | ||
36行目: | 41行目: | ||
== 欠点 == | == 欠点 == | ||
+ | ===コミュニケーション障害者=== | ||
経験を積んだ開発者によっては、初心者とのペアプログラミングを一種の退屈な指導と捉える場合もある。一部の技術者は1人で作業することを好み、ペアでの作業を面倒と感じる場合もある。 | 経験を積んだ開発者によっては、初心者とのペアプログラミングを一種の退屈な指導と捉える場合もある。一部の技術者は1人で作業することを好み、ペアでの作業を面倒と感じる場合もある。 | ||
− | |||
これは上級者側の[[コミュ力]]不足、[[指導力]]不足であるともいえ、そのような人物は[[RAプログラム]]の対象としても差し支えない。 | これは上級者側の[[コミュ力]]不足、[[指導力]]不足であるともいえ、そのような人物は[[RAプログラム]]の対象としても差し支えない。 | ||
また、ペアの組み合わせによっては双方が「よくわからんけどあいつはしっかりやるし大丈夫だろう」の考えの元に行動してしまい、結果として人件費を2倍かけたのにもかかわらず逆にチェックが杜撰になることもあるので注意が必要である。プロジェクトリーダーや人事はお互いが「あいつで大丈夫か」と思えるような人材同士(かつ険悪な関係にないもの)をペアにする必要があり、リーダーや人事の高い能力が求められる。 | また、ペアの組み合わせによっては双方が「よくわからんけどあいつはしっかりやるし大丈夫だろう」の考えの元に行動してしまい、結果として人件費を2倍かけたのにもかかわらず逆にチェックが杜撰になることもあるので注意が必要である。プロジェクトリーダーや人事はお互いが「あいつで大丈夫か」と思えるような人材同士(かつ険悪な関係にないもの)をペアにする必要があり、リーダーや人事の高い能力が求められる。 | ||
+ | |||
+ | ===人件費=== | ||
+ | 小規模な[[ブラック企業]]では[[ワンオペ]]による[[プログラミング]]が広く行われており、そのような環境下ではペアプログラミング以前に[[プログラマー]]1人のみですべてを行い、[[プロジェクトマネージャー]]や[[システムエンジニア]]などという役職も存在しない。また、その前提で[[チキンレース]]の末に[[不当廉売]]のような価格が横行しており、[[安かろう悪かろう]]を繰り返し顧客からの信頼も薄いため、正常な価格への値上げも難しい状況に陥っている。このような[[ブラック企業]]では[[人件費]]を捻出することが難しくペアプログラミングは夢のまた夢である。 | ||
+ | |||
+ | ====RAIDプログラミング==== | ||
+ | ただこの状態は[[大企業病気]]の真逆の[[弱小企業病]](なお私が勝手に名付けた名称で一般的なものではない)であるといえ、顧客からの信頼性の面や企業としての収益性の面からみても放置すればその企業は確実に経営破綻する。それを回避するためにも徐々にでも正常な状態にもっていく必要があるといえる。 | ||
+ | |||
+ | いわゆる世間一般でいわれるペアプログラミングは[[ハードディスク]]でいえば[[RAID1]]構成である。確かに目先の[[コストパフォーマンス]]は悪い。 | ||
+ | そこでまずは[[RAID5]]のような[[RAIDプログラミング]](なお私が勝手に名付けた名称で一般的なものではない)からはじめてみてはいかがだろうか。 | ||
+ | |||
+ | [[プログラマー]]は最低3名構成で、うち1名はペアプログラミング的に巡回を担当する。 | ||
+ | それを日替わりなどで行うのである。 | ||
+ | 万が一、不慮の事故や病気などで[[プログラマー]]が1名ほど欠落しても、一時的にペアプログラミング状態は停止することになるが、巡回するプログラマーを通常のプログラマーとして補欠できるため[[デスマーチ]]に陥る確率は大幅に低減できる。 | ||
+ | |||
+ | そして企業として少し余裕が出てきたならば巡回するプログラマーを徐々に増やすなどして[[RAID6]]や[[RAID50]]に近い形態に移行し、最終的には[[RAID1]]、すなわち本来のペアプログラミングの体制にもっていけばよい。 | ||
+ | |||
+ | 長くなりそうなので以下に検証ページを作る。 | ||
+ | *[[RAIDプログラミング]] | ||
== 現実 == | == 現実 == | ||
2人組であれば開発速度は落ちないどころか向上すると言われているが、目下の[[人件費]]が2倍になるという理由から、いわゆる[[IT土方]]が集う、いわゆる[[ブラック企業]]ではまず行われていない。そもそもそんな企業の人事やプロジェクトリーダーは能力不足によりまともに機能するペアを社内で構成することすらできず、ますますブラック化を加速させているのが実情と思われる。 | 2人組であれば開発速度は落ちないどころか向上すると言われているが、目下の[[人件費]]が2倍になるという理由から、いわゆる[[IT土方]]が集う、いわゆる[[ブラック企業]]ではまず行われていない。そもそもそんな企業の人事やプロジェクトリーダーは能力不足によりまともに機能するペアを社内で構成することすらできず、ますますブラック化を加速させているのが実情と思われる。 | ||
− | [[システム]]を発注する顧客の場合は、「本当に完成品を納品してくれそうか」を測る指標として、[[見積]] | + | [[システム]]を発注する顧客の場合は、「本当に完成品を納品してくれそうか」を測る指標として、[[見積]]段階でペアプログラミングを導入しているかを尋ねてみると良い。尋ねると良いどころか、必ず確認しておかなければ危険な点であると言う人もいる。 |
== 関連項目 == | == 関連項目 == |
2017年2月9日 (木) 12:22時点における最新版
ペアプログラミング(英語:pair programming)とは、大雑把にいうと職業プログラマーを冗長化することである。
目次
概要[編集 | ソースを編集]
ペアプログラミングは冗長化手法として広く知られているHDDのRAID構成をプログラマーという人的リソースに適用したものである。これによりデスマーチ突入率を大幅に抑えることができる。
なお、RAIDコントローラーに相当するプロジェクトの現場責任者(日本ではシステムエンジニアと呼ばれることが多い)が無能である場合は、ペアプログラミングの理想も虚しく、綺麗に空中分解する。そのような人物はバグを抱えた不良品であり、迷わずリストラして新品交換するのが望ましい。
副作用を軽減する効果がある。
他業種ではあたりまえ[編集 | ソースを編集]
ペアで業務に取り組むという行為は絶対の安全が求められる分野では常識となっており、たとえば航空機の機長と副機長や、チーム医療などでは当たり前の形態である。刑事ドラマの警察官も2人組、覆面パトカーでドライブしている警察官も2人組が基本である。つまり「ペア」いう概念はプログラマーに限ったものではない。某外資系電機メーカーなど、一部の企業では営業職なども基本的にペアで行動するようにしているところも少なからず存在している。
わざわざお硬く提唱される時点で知能指数の低い者が多い(多くなった)業界だということである。
ペア行動の有無はブラック企業を判別する手法としても注目が集まる。2014年3月ごろから発生したすき家のパワーアップ工事もワンオペが原因のひとつと言われている。
利点[編集 | ソースを編集]
規範意識の増大[編集 | ソースを編集]
組合せ次第では、個人の作業よりもサボりにくく、ちゃんと作業を進める可能性が高い。なお組合せを間違えると2人してサボる。
よりよいコード[編集 | ソースを編集]
相乗効果により設計や実装の質が向上することが期待される。2人組だと常にコードレビューと単体テストが行われているような状態になるため、後から読めないスパゲッティコードを抑制できる。とくに中級者病の抑制には強い効果を発揮する。
作業効率の向上[編集 | ソースを編集]
2人組だと1人で作業するときとは流れが変わる。1人がドライバーとなり、1人がナビゲーターとなるため、次に何をすべきかを考え込むといったことが少なくなる。
外乱要因に対する耐性[編集 | ソースを編集]
2人組だと「Excelの使い方がわからない」などといった、「助けてパソコンの大先生!」的な、いわゆるFAQな外乱要因に対しても耐性を示し、他の人が割り込んできても、一方が応対し、もう一方が作業を進められる。
多数の開発者による設計[編集 | ソースを編集]
ペアを頻繁に入れ替えれば、複数の人間が1つの機能の開発に関わることになる。これにより、よりよい設計が生み出され、たとえばあるペアが解決できない問題で作業が止まってしまっても、別のペアでは解決できることもある。
勤労意欲の向上[編集 | ソースを編集]
ペアプログラミングを行うことでチームの各人が互いをよりよく知ることができ、結束力を生み出しやすい。またペアプログラミングの方が1人で作業するよりも楽しいと感じる開発者もいる。これは友達の少ないプログラマーのコミュ力を向上させることにもつながることであろう。
集団的なコード所有権[編集 | ソースを編集]
プロジェクトの全員がペアプログラミングを行い、頻繁にペアを組みかえる場合、そのコード全体について全員がそれなりの知識を共有することになる。
教育的側面[編集 | ソースを編集]
初心者であっても固有の知識(プログラミングテクニックなど)を持っているものである。ペアプログラミングでは、余計な手間をかけずにそのような知識をチーム全体で共有できる。
欠点[編集 | ソースを編集]
コミュニケーション障害者[編集 | ソースを編集]
経験を積んだ開発者によっては、初心者とのペアプログラミングを一種の退屈な指導と捉える場合もある。一部の技術者は1人で作業することを好み、ペアでの作業を面倒と感じる場合もある。 これは上級者側のコミュ力不足、指導力不足であるともいえ、そのような人物はRAプログラムの対象としても差し支えない。
また、ペアの組み合わせによっては双方が「よくわからんけどあいつはしっかりやるし大丈夫だろう」の考えの元に行動してしまい、結果として人件費を2倍かけたのにもかかわらず逆にチェックが杜撰になることもあるので注意が必要である。プロジェクトリーダーや人事はお互いが「あいつで大丈夫か」と思えるような人材同士(かつ険悪な関係にないもの)をペアにする必要があり、リーダーや人事の高い能力が求められる。
人件費[編集 | ソースを編集]
小規模なブラック企業ではワンオペによるプログラミングが広く行われており、そのような環境下ではペアプログラミング以前にプログラマー1人のみですべてを行い、プロジェクトマネージャーやシステムエンジニアなどという役職も存在しない。また、その前提でチキンレースの末に不当廉売のような価格が横行しており、安かろう悪かろうを繰り返し顧客からの信頼も薄いため、正常な価格への値上げも難しい状況に陥っている。このようなブラック企業では人件費を捻出することが難しくペアプログラミングは夢のまた夢である。
RAIDプログラミング[編集 | ソースを編集]
ただこの状態は大企業病気の真逆の弱小企業病(なお私が勝手に名付けた名称で一般的なものではない)であるといえ、顧客からの信頼性の面や企業としての収益性の面からみても放置すればその企業は確実に経営破綻する。それを回避するためにも徐々にでも正常な状態にもっていく必要があるといえる。
いわゆる世間一般でいわれるペアプログラミングはハードディスクでいえばRAID1構成である。確かに目先のコストパフォーマンスは悪い。 そこでまずはRAID5のようなRAIDプログラミング(なお私が勝手に名付けた名称で一般的なものではない)からはじめてみてはいかがだろうか。
プログラマーは最低3名構成で、うち1名はペアプログラミング的に巡回を担当する。 それを日替わりなどで行うのである。 万が一、不慮の事故や病気などでプログラマーが1名ほど欠落しても、一時的にペアプログラミング状態は停止することになるが、巡回するプログラマーを通常のプログラマーとして補欠できるためデスマーチに陥る確率は大幅に低減できる。
そして企業として少し余裕が出てきたならば巡回するプログラマーを徐々に増やすなどしてRAID6やRAID50に近い形態に移行し、最終的にはRAID1、すなわち本来のペアプログラミングの体制にもっていけばよい。
長くなりそうなので以下に検証ページを作る。
現実[編集 | ソースを編集]
2人組であれば開発速度は落ちないどころか向上すると言われているが、目下の人件費が2倍になるという理由から、いわゆるIT土方が集う、いわゆるブラック企業ではまず行われていない。そもそもそんな企業の人事やプロジェクトリーダーは能力不足によりまともに機能するペアを社内で構成することすらできず、ますますブラック化を加速させているのが実情と思われる。
システムを発注する顧客の場合は、「本当に完成品を納品してくれそうか」を測る指標として、見積段階でペアプログラミングを導入しているかを尋ねてみると良い。尋ねると良いどころか、必ず確認しておかなければ危険な点であると言う人もいる。