コードレビューのコスト

私のチームでも、当然のようにコードレビューは行っています。そして品質向上に一定の効果をあげているのですが、しかしそのコストが支払えなくなってきています。

うちのチームでは、

1. 実装前（実装中でもよいのだけれど）に どういう風に実装するか チーム全員に対しホワイトボードでプレゼンする
2. 実装が終わったら レビュワーにコードを渡す
3. レビュワーはコードをレビュー。
4. 指摘事項を直してコミット

という流れになっています。

ホワイトボードプレゼンは、毎朝の朝会の後に 「レビューある人？」と聞いて手を上げた人がいたらやるかんじ。プレゼンなしでの実装完了はご法度というルールです。

コードレビューはペアレビューとかじゃなく、基本的に一人でコードを読みます。ソフトの構造の大枠はプレゼン済みなので、改めて実装者が説明する必要なしという考え。（それでも話と違うじゃん、みたいなのはあって、そうなれば任意聞き取り調査になります）

コードレビューは、だいたい実装する人が2人いたら、レビューする人が1人弱つぶれる感じ。それくらいのコストがかかるのは当然なのですが、開発も大分キツキツになってきて、そのコストを許容してもらえないようなムードになりつつあります。チームは、仕様を詰める人（お客様との窓口）が1人、コードレビューとウォーターフォール偽装(^^;)のための人員が1人、プログラマ3人（うち1人が新人）という構成ですが、作る人をせめてもう一人分くらいは増やしたい状況です。それでなくともコードレビューが回しきれていないですし、そこで効率の良いコードレビューの方法ってないかな、という話が出てくるわけでして。

無いかなぁ、虫のいい話だものね。

話はズレますが、コードレビューにこれだけのコストを書けるのなら、普通にペアプロやっちゃっても割に合いますねぇ。もうペアプロしてしまいたい。でも世の中そう論理的に判断してくれる人ばかりではないので。しくしく。

天動説とウォーターフォール

むしろウォーターフォール偽装のコストをばっさり削りたいのだけれど、そうは問屋が卸してくれない(T△T

事前にほぼ完璧な工数見積もりを、スケジューリングをこなす。そして最初の段階でフィックスできるレベルで用件分析（仕様確定）を行う。それを元に実装時に「こうすればもっと良くなる」と思う余地の無いほど完璧な設計をあげる。そこまでしてから実装すれば、開発は絶対うまくいく。――というのがウォーターフォールな開発です（←偏見入りすぎw)。

もちろん出来るわけ無いです。どんな預言者だというんです、あたしたちは。でも、出来ないと 事前の見積もり（分析や予測）が良くなかったからだ...という話になりがちで、頭の痛い問題だわ、これは。

天動説って、見た目の天球の動きに対する直感を元に モデルを組み立てていったものです。ごくシンプルな発想ですが シンプルは美徳です。それでは説明できなさそうな惑星の不可解な動作も、周転円や離心円を導入して綺麗につじつまを合わせてしまったりして、一般の宗教に縛られたと無理な説というイメージとは異なり、天動説はモデルとしてかなり整合するんです。

でも、そんな見事な天動説も実は間違いで、実際は地動説だったわけです。観測技術の向上や知見の拡大にともない、初期の分析間違いはやがて明らかになってきて、そして大胆にそのデザインを変える日を迎えます。

天動説は決して思考停止の産物ではなく、その時代の人類の英知を結集したものです。そうであっても天動説というモデルの見誤りが過去にあったくらいですから、たかが一プログラマたる私たちに「最初は決して間違うな」なんて言われても出来る相談ではないのは当然じゃん、と思います。――てなことを言ったら「屁理屈」とか言われるんですが。

初期の間違いを直せない開発プロセスよりも、修正のコストを下げられるプロセスのほうが絶対いいなんて、誰の目にも明らかだと思うのに、思うのに...。ウォーターフォールなんて無理だよぅ。どうして3ヶ月先の日単位の予定なんて立てられるっていうのさ。しくしく。