三人寄れば文殊の知恵、と昔から言われていますが、これは現代のプログラミング現場にも当てはまるのでしょうか。ペアプログラミングを単純に、1人で出来るものを2人で行うと考えるならば、分業制で明確な役割分担がある仕事ならばともかく、ことプログラミングの開発においては、無用で邪魔と判断しがちです。しかし長い目で見れば、これが正に文殊の智恵になるのです。
1999年にユタ大学で、被験者をソロとペアとに分けて、設計の時間を除いて「プログラムを書く為に費やす時間」を比較する実験が行われました。結果は、ペアの方が、平均して15%多かったのです。また、別の検証実験では、ペア作業者の方がソロ作業者より品質に関する設定課題の合格率が15%高いという結果が出ています。加えてペアが作成したソースコードは、常にソロの場合と比較して20%短かったようです。その他にも、1人より2人がすべてを知っているという状況がプロジェクトの安定性を高める点や、1人ではないという緊張感から効率よくタスクを進めてお互いにコミュニケーションをとらざるを得ない状況におかれる点などにその効果を見出すことが出来るのです。
プログラミングというものは、一度完了した後にその有用性を試されます。そしてどんなプロジェクトにもいえることですが、開発の現場というものは、限られた予算と時間をフルに利用してプログラマが持つ能力を最大限に発揮することが要求されるのです。ここでペアプログラミングを導入すると、2人のプログラマがまるで共同研究をするかのように、互いに異なる視点に立って批判し合い、刺激し合い、時には思わぬ解法を思いつくというように、その後の検証の段階を一段早く取り込むことが出来たり、現場のリソース要求を先取り出来るのです。もちろん始めから短命なソフトウェアで良いという場合であれば、わざわざペアプログラミングを選択してコストをかけるメリットはないのかもしれません。しかし長期的に安定した安全なプログラミングが望まれるような寿命の長いソフトウェアの開発では、ペアプログラミングの長所が遺憾なく発揮されることでしょう。
ここに一般的なシステムにバグが見つかった場合、33時間から88時間もの時間がその修正に必要というデータがあります。その一方で、そのバグを開発期間中に発見して修正したならば、30分から88時間に及ぶ時間を節約することが出来るというのです。つまり、このような手法を導入するに当たっての費用対効果はあくまで相対的なものであり、プロジェクト全体を俯瞰した上で、個々の事情に即して検討する必要があり、かつ検討するに十分値するといえるのです。
プログラミングが早い人、ただ早いだけではなく本サイトのテーマの通り、生産性の高いプログラマの特徴を紹介します。生産性の高いプログラマは、広い視野を持って全体を俯瞰しています。目の前にあるコードだけを見るのではなく、最終的な完成形の一部としてプログラムを捉えられるかどうかで、その完成度には違いがでます。コードを書く速度はとにかく毎日書くことにつきます。毎日書いて、かつ、公開することがポイントです。
システム開発プロジェクトにおいて生産性向上をめざすにあたっては、陥りがちな落とし穴にも気をつけなければなりません。仕様も納期も決められた中での開発なのか、開発しながら仕様を決めるケースなのかによっても、生産性向上のための選択は変わります。目的に合わせたものを採用すること、トップダウンで決定しないこと、導入コストを考えること、そして導入後の現状確認を怠らないことが、落とし穴を避ける秘訣です。
プロマネという道を選択したがために、好きなコーディングがなかなかできなくなってしまい不満があるなら、プログラマに戻り、転職やフリーランスへの転身を考えてみるのも一つの手です。ただし、どちらにしても本当に自分がやりたいことを実現できるのかどうかを見極めて行動に移しましょう。転職の場合は選考の時点で確認を行い、フリーランスの場合は目的や方向性がマッチするようであれば多くの案件をこなし、場数を踏んで実績を積みましょう。