「（相対的に）ドキュメントは重要ではない。」と考えていたけど、改宗する。「そのドキュメントが何を表現するかを考えずに、ドキュメントを作る」という行為が無駄なのであって、「設計を文書にして残す。それをレビューする。」という行為はけして無駄じゃない。やるべきなのは、「何をドキュメントにするか、何をドキュメントにしないかを判断すること」と、「レビューして、設計での一定レベルの合意を形成すること」だ。そして、その目的は「品質の高いインターフェースを持ったコードを共有し、スケールさせることができるようにする。」という点に尽きる。
ふつうのプログラマで成り立つプロジェクトだからこそ、上記を徹底しないといけない。詳細設計として程度の悪い擬似コードを日本語で書いたようなドキュメントを受け取る必要は当然なく、その分、たとえばビジネスルール単位で、それをどのように設計するのかを検討する必要がある。これをコードに近い表現でやってもいいし（TDD のようになるだろうけど。）、文章とインターフェース定義でやってもいいけれど、ドキュメントとして受け取ることとレビューをすることは省かないようにする。
以上、Google のソフトウェア開発についての興味深いエントリ「いいアジャイルと悪いアジャイル」を再読してみて、最近の考え続けていたことに出した結論。
彼らはユニットテストや設計ドキュメントやコードレビューといったことを、私が聞いたことのあるどの会社よりも真剣にやっている。彼らは自分たちの環境が常に整理されているよう熱心に働いており、どこかのエンジニアやチームが自分勝手な方法でやらないようにする厳格なルールやガイドラインが実施されている。結果として、コードベース全体が同じように書かれ、チームを変えたりコードを共有したりすることが、他の会社でよりもずっと簡単なことになっている。
安易にまとめてしまったけれど、上記の文章はさらに深い含蓄がある気がしている。もう一度、自分の直面している課題と照らし合わせて、なぜそれをするのか（あるいは「なぜあえてそれはするのか」）を考えてみようと思う。
