OSSの開発モデルを、そのまま社内に持ち込むのは止めたほうがいい（もしくはコードレビューの話）

以前以下のようにツイートした話だけど、OSSの開発モデルを社内開発にそのまま持ち込むのは危険。

チーム開発の場合、簡単にコメント返せないようなPR送られた時点で負けだと思ってる。無駄なコードが生産されないよう事前に設計を詰める作業をすべき / “雑なレビュー - ✘╹◡╹✘” http://htn.to/by5or1

https://twitter.com/kazuho/status/431602421068877824

今日一般的に想定される「OSSの開発モデル」はEric S. Raymondの有名なエッセーである「伽藍とバザール」によって解説されたところの「バザール」である。

「バザール」モデルにおいては、多くの改善提案の中から最善と考えられる実装が取り入れられ、コミュニティで共有されるようになる。同エッセーから引用するなら、

　ふりかえってみると、Linux の手法や成功の前例は GNU Emacs の Lisp ライブラリと Lisp コードアーカイブの開発にみることができる。Emacs の C のコア部分やその他 FSF ツールみたいな、伽藍建築方式にくらべると、Lisp コードのプールの進化は流動的で、すごくユーザ主導で行われた。アイデアやプロトタイプ・モードは、安定した最終形に落ち着くまで 3 回も 4 回も書き直されるのがしょっちゅうだった。

今日的に言い換えるなら、あまたあるブランチやpull-requestの中から最良のものが選択されるということ。

これは、エンジニアリングリソースが潤沢にあるからこそ採ることができるアプローチ。そして、成功したOSSは必ずエンジニアリングリソースが潤沢になるので（成功したOSSの場合、問題があったら直そうとする人が多数いるから）、OSSの開発モデルとしては「バザール」モデルがうまく機能するように見える。

しかし、社内開発においては、限られたエンジニアリングリソースをできるだけ効率よく活用することが求められる。別の言い方をすると、エンジニアが「無駄な作業」をする可能性を減らすことを考えるべきだが、これはバザールモデルとは相反する。

コードレビューの話はその具体例であって、社内でのグループ開発においてプルリクエストの評価（やコードレビュー）で設計の問題を指摘するというアプローチは、実装完了後に設計の評価を行うことになるという意味で、手直しが発生した場合の損失が大きくなりがち。

それよりも、実装開始前に設計レビューをやるなどして、無駄なコーディング作業を減らすことを考えるべき。

参考:
テストファーストなGitワークフローについて - kazuhoのメモ置き場
https://twitter.com/t_wada/status/443945356665962496のスレ