プログラマーには、コーディングの生産性で10倍、コードレビューの速度では6倍もの能力差があるという
プログラマーの生産性をテーマにした有名な著書「ピープルウェア」には、最も優秀なプログラマと最低の成績のプログラマのあいだには約10倍にあたる生産性の違いがある、というデータが出てきます。
プログラマーの生産性を計るコンテストでの結果のグラフ。最優秀者は最低者の約10倍の生産性がある（書籍「ピープルウェア」p57より引用）これは、1984年から1986年にかけて92社、延べ600人が参加したプログラミングコンテストのデータを分析した結果から導き出された結果で、課題として与えられたプログラミング作業の開始からコンパイル時のエラーを消すところ（第1チェックポイント）へ到達するまでにかかった時間を比べています。
グラフを見ても分かるように、最優秀者と最低者のあいだには作業時間にして約10倍のひらきがあります。また最優秀者は平均の約2.5倍の生産性だそうです。そして、COBOLやFortranのような旧世代のプログラミング言語と、PascalやCのような現代的なプログラミング言語でのコーディングでの生産性はほとんど同じであったそうです。また、プログラミングの経験年数や得ている収入と、プログラマーの優秀さとの相関関係もほとんどなかったと記述されています。
では、ソースコードを読むスピードにはどのくらいの能力差があるのか？
一方でコードを読むスピードにはどれくらいの能力差があるのでしょうか？ 先週の金曜日に公開されたCodeZineの記事「 【読者参加型企画】2,000行のJavaソースコードを読むのに何分かかりますか？ 」に、興味深いデータが掲載されていました。
この記事の著者である森崎修司氏は、奈良先端科学技術大学院大学でソフトウェアの品質を向上させる技術の1つである「ソフトウェアインスペクション」を専門にしています。いわゆる、コードレビューの方法論や効率などについて研究されていると言えばいいでしょうか。
森崎氏の研究グループでは研究の一環として、一般のプログラマを対象にさまざまなコードレビューを実際に行ってもらっています。記事から一部を引用します。
私たちの研究グループで実施した観察でもソースコードを読む速度は個人差が大きいことを確認しており、同じソースコードを理解するための時間に6倍の差がある事例を確認しています。
プログラミングと同様に、コードレビューでもかなり個人の生産性には差があることが分かります。また記事では、いくつかの書籍や論文を挙げて、コードレビューにおける平均的な1時間当たりの行数も示しています。
- 100～200行（Technical Reviews）：IEEE: IEEE Standard for Software Reviews and Audits（1028-2008）
- 200行以下（インスペクション）：ワッツハンフリー: TSPi ガイドブック（Introduction to the Team Software Process）、秋山義博 監訳、JASPIC TSP研究会訳、翔泳社
- 700～900行（問題発見）、500～700行（問題指摘）、（インスペクション、COBOL, コメント行含まず）： M. Fagan: "Design and code inspection to reduce errors in program development", IBM Systems Journal, vol. 15, No. 3, p 181-211
ちなみに上記の森崎氏の記事では、研究のためにオンラインでできるコードレビュー者を現在募集しています。誰でも参加できて、自分が参加者の中でどれくらいの生産性なのか、どこが弱い部分か、といった客観的な評価を知ることができるそうです。
コードレビューの生産性として6倍という数字を示した森崎氏の研究グループの報告は現在作成中とのことで、公開されたらまたPublickeyで紹介しようと思います。
生産性に深い関連があったのは「誰とチームを組んでいるか」だった！
このようにプログラマーの生産性には大きな開きがあることが明らかにされています。では、能力を向上させるにはどうすればいいのでしょうか？
書籍「ピープルウェア」によると、プログラマの生産性に最も深い関連があったのは「誰とチームを組んでいるか」だったそうです。パートナーの成績が良ければ、もう一人もやはり優秀な成績であり、いつまでたってもプログラムの出来上がらなかったプログラマーは、その相手も出来が悪いとのことです。
優秀なプログラマーになりたければ、優秀な人と一緒に働くことが大事だというこの指摘は、もしかしたら多くのプログラマーにとって密かに実感していることではないでしょうか。
また関連記事として、優れたエンジニアの特徴とコミュニケーションの重要性について紹介した記事「優れたエンジニアになる方法と、その知識を伝達する方法 」もぜひ参照してみてください。
ピープルウエア 第2版 - ヤル気こそプロジェクト成功の鍵開発プロジェクトで技術よりも何よりも大事なもの――それは「人」。一人一人の人格の尊重、頭を使う人間にふさわしいオフィス、人材の選び方・育て方、結束したチームがもたらす効果、仕事は楽しくあるべきもの、仕事を生み出す組織づくり、という6つの視点から「人」を中心としたプロジェクト開発の大切をユーモラスに語っている。
TSPiガイドブック (IT Architects'Archive ソフトウェア開発の課題 10)ソフトウェア業界はチームによる開発がほとんどです。そして、この開発チームに必要なものは、自分たちの計画を作り、自分たちの進捗を追跡し、自分たちの作業を調整しなければならないのです。また、チームは共通のゴールを目的とし、共通の作業プロセスを持ち、自由かつオープンにコミュニケーションをとらなければなりません。本書(教科書)とそれに付随するコースは、チームソフトウェア開発の総合的な入門書として新たなページを刻むものです。
関連記事 on Publickey
- 優れたエンジニアになる方法と、その知識を伝達する方法
- SIerとパッケージベンダはどちらが高給？ IT系上場企業の平均給与を業種別にみてみた
- ［ディスカッション］ソフトウェアインスペクション／コードレビューを成功させる方法（前編）
- ［ディスカッション］ソフトウェアインスペクション／コードレビューを成功させる方法（後編）
Junichi Niino（jniino）
Trackbacks （TrackbackURL:http://www.publickey1.jp/mt/mt-tb.cgi/299）
Comments