自分が Design Docs というものがいまいち好きでない。Design Docs という抽象的な概念が嫌というよりは、提供されるテンプレートが嫌（という話は前に書いた気もするけれども発見できなかった・・・。）

典型的な Design Docs は BDUF によりがちである。バシっとしたデザインを宣言し、これでいくぞ！という。しかしそれは多くの場合嘘である、というと語弊があるが結果できあがるものとは違う。違うものを作るの自体は良いが、そんなら最初からバシっとデザインできてるみたいな顔すんなよ、と思う。

これは半分はテンプレートや慣習の問題である。多くの design docs は confidence level を communicate しない。「ここのデザインはまだ決められないので適当です。ちょっと作ってみてから考えます」「これはあとで変えられない重要な決定です」みたいな情報は一級市民であるべきだが、抜け落ちがちである。

そうしたプロジェクトの confidence level を上げていくというか uncertainty を絞り込んでいくの作業は planning と呼ばれる。つまり planning と design は表裏一体である。しかしなぜか２つは独立に扱われがちである。書いてる人が違ったりすることすらある。アホか。まあ planning というとプログラマ以外の stakeholder も色々関係してくるのでプログラマだけがどうこうすることはできないけれども、自分のぶんの計画くらいは design に織り込んでいいのではないか。そうしないと PM の書いた PRD みたいないまいち iterative 精神を理解してない計画に縛られて色々厳しくなりがち。不透明なものを段階的にすすめるならそうはっきり伝えなておかないと。

Agile は planning についてはいろいろと手法を開発したが、design 側は手薄になりがち。もともと BDUF に対するアンチテーゼの面があるから documented design を意図的にがんばってない部分はあるのだろうけれど、そうはいってもコード書く前に多少はなんか考えて書き出しといた方がよくね？実験的に開発をすすめるにしろ、多少は当初の目論見をはっきりしないと slip しがちじゃん? いやドキュメントも必要に応じて書くよとかいうけど、たとえば Scrum のプロセスの回し方みたいのを議論する細かさに比べたら design の話は皆無といってよい。そういうことやってると BDUF の亡霊に襲われるぞ。というかその亡霊が Design Docs だと思うのだよね。

自分はある時期までは iterative に進めるなら事前の documented design はなくてもいいと思っていた。実際なくてもできることは多い。ただ相手にするコードベースが大きかったり達成したいゴールが自明じゃなかったりすると iteartoin の turnaround time が長くなりがち。だから事前にあるていど調査をして見通しを立てるのには意味がある。しかしその調査の結果や見通した設計を資料化する部分でいつもモタモタしてしまい、もたついた末にサボってひどい目にあったりする。

特に誰かに助けを求めたいときはやりたいこと、やっていることを文書化しておくと be on the same page する上で都合が良い、というか割と必須。ひどい目にあうのは意思疎通の失敗が多い気がする。

もう一つ多いのは自分がやるべきことをはっきり決められていないのに気づいていない場合で、症状として procrastination が現れる。これは文書を書くとはっきりしたり、少なくとも何がはっきりしてないか自覚できたりする。考える道具としての文書化。

自分はこういう uncertainty から始まる evoluving design を記録するメディアとしての半時系列的なアプローチに興味あがり、だから blog 的なものに期待があるのだろうということに気づいた。もしかして一部では solved problem なのかもしんない。勤務先、なんとかならんかなー・・・。

まあ勤務先はおいといて、自分でなんかモダンなものをさわってみないとなあ。