コードレビューによる効果を定量的に説明する必要がある

パトナーさん通しでペアを組ませて、レビューをさせるというのはどうでしょう。と私は提案しました。できる人と経験が足りない人を組ませることで、経験が足りない人のスキルも向上するし、ダメなコードも少なくなります。

最後の提案に関しては、データの方からは、やってみるともやらないとも反応がありませんでしたが、レビューに力を入れるというのは、品質を向上させる王道なので、ガチガチな縛りよりレビュー重視のほうが良いと思っています。

http://d.hatena.ne.jp/higayasuo/20080612/1213241779

パートナー同士でレビューする時間を設けるには、レビュー工数を積む必要があります。個人的にはコーディングの時間に含めてしまった方がよいと思いますが、そうすると計算上の生産性が半分近く下がります。プロジェクトや組織のトップにコードレビューの必要性を認識させないと、お金の問題は解決できません。

最大の問題は、納品物であるソースコードの品質をどのように担保するか。ソースコードを理解できない人にも客観的に説明できる指標が必要になります。そうなると、ステップ数やレビューの指摘件数を使って計算することになりますが、コードレビューの指摘でいちいち詳細なバグ報告を書くのは面倒ですよね。この手の無駄なルールを減らしていて、本当に大事な作業に集中すべきです。

レビュー重視による効果を定量的に説明できるとよいのですがね。

今まで動けばいいや、金もらえたらいいやレベルでやってきた人も、とんでもないコードを抑制する動きがあることを理解して、まずは世間的に良いコードとはどんなのかを理解して、とんでもないコードを納品してしまわないような工夫を個人レベルでいいからしてみませんか。

http://d.hatena.ne.jp/bash0C7/20080612/1213281663

私がいま一緒に仕事をしている人たちはとても優秀です。他に比べてバグが少ないと指摘が出るほど。優秀な人の能力を活用し、成長させることができるかは、協力会社のリーダーの腕に掛かっている気がします。

パートナーさんの努力も大事だと思いますが、お金をもらわずに余分な作業をするのはサービス残業と同じです。コードレビュー無しで引いているスケジュールにコードレビューを入れようとすれば、一日当たりの作業量が増加するのは自明です。作業量の見積もりが（元請けや協力会社ともに）経験ベースなのが問題ですね。コードレビューなんて必要ないというPMは追加工数を認めないでしょう。

ひがさんのように身分を明らかにして議論できるほど、私も偉くなりたいですね ;-)