morrita さん、karino2 さんのいう嫌さは半分くらいわかるかなあ。
「Design Doc 書いてください」というのが、設計が終わったあとに実装がはじまる直線的なソフトウェア開発や、設計が難しい/偉くて実装はそうでもないという、上流工程偏重な職業感を想起させるというのはわかる。無駄な Design Doc が書かれがちなのもわかる。文章がないことに文句を言う人は多いけれど、文章があることに文句を言う人は少ない。でもまあ、無駄な実装よりは無駄な Design Doc の方がマシかなあ。
あと、Design Doc を書かなくてはいけないときは、それなりに大手術になってしまう変更を入れるときで、それは初期の設計のダメさであるとか、機能のつけすぎの現れじゃないか、と思うこともある。炎上プロジェクトには、それを消火してくれるヒーローが現れるように、柔軟性のない巨大ソフトウェアには、それを乗り切るための Design Doc が必要なんじゃないか。
一方で、テンプレートが新規のサーバーサイドのシステムを開発するのを想定しているとか、将来に誰かに読まれそうな期待というのはよくわからない。あわないテンプレートは無視すればいいし、昔に書かれた Design Doc を参照するのは自己責任で、書き手がそれを意識する必要はなくない?
Is it that Design Doc?
morrita さんのテンプレートの話や、karino2 さんの
Design Docは形式が広く知られているし、書く時に気をつけるべき事なども良く語られていて、しかも比較的それらの説明は短い。
あるいは、Design Docs at Google の
The sweet spot for a larger project seems to be around 10-20ish pages. If you get way beyond that, it might make sense to split up the problem into more manageable sub problems. It should also be noted that it is absolutely possible to write a 1-3 page “mini design doc”.
とかを読むと、人々が Design Doc といって想起するものには結構ばらつきがある気がする。私が好んでいるものは、ここでいう mini design doc というか、もっというと単なる “doc” なのかもしれない。メール やSlackで五月雨式に質問したり、ミーティングで口頭で話したり、突然コードレビューで大作を送ってくるのはやめて、全体像を文章でまとめて送ってくれませんか?
ここで私が読みたいのは、問題の背景、複数の実装案の良し悪しと、結果として著者が良いと思っている実装案くらい。そんなの実装みたらわかるじゃない、と思うこともあるけれど、実装し終わったものをコードレビューで「これはそもそもがダメなのでやめましょう」というのは気分的にも締め切り的にも難しいことが多く、手をつけるまえに全体像を見れたほうがいい。そのためのツールとして文章に一回まとめるのは良いですよ、という話。
プロトタイプ力
というわけで、私は Design Doc に関してはそこまで問題意識がないのだった。私の周りの人々が私の書く Design Doc に問題意識を持っている可能性はなくもないので、今度聞いてみてもいいかもしれない。でもなー、初回のミーティングでみんなが納得、コメントなしとなると、それはそれで不安になりそう。
ところで、Design Doc と同じような、実装まえにやると良いこととしてあげられがちなものに、プロトタイプ作りがある。個人的には、文章の説得力をあげていくよりは、プロトタイプをさっと作る方向に力を割きたいと思っている。Design Doc を書いてレビューしてみると良さそうだけど、作ってみるとダメなものってあるはずで、やっぱりちょっとはコードを書きながらデザインしたい。
ただ、画面のあるもののプロトタイプ作りは、ペーパープロトタイピングから Figma や Sketch みたいなものまで色々と方法論やツールがあるけれど、画面のないもののプロトタイプを人々がどう作っているのか、というのはよくわからない。
karino2 さんがリンクしている、Paul Graham のハッカーと画家には、
これはプログラミング言語は柔軟でなければならないということを意味する。 プログラミング言語はプログラムを考えるためのものであって、 既に考えたプログラムを書き下すためのものじゃない。 それはペンではなく鉛筆であるべきなんだ。 静的な型付けは、私が大学で教わったようにプログラムするなら良い考えだと 思う。でも私の知るハッカー達はそんなふうにはプログラムしない。 我々に必要なのは、落書きしたりぼかしたり塗りつぶしたりできる 言語であって、型の紅茶茶碗を膝に置きながら 厳しいコンパイラおばさんと丁寧な会話をするような言語じゃない。
静的型に対する批判があるけれど、じゃあ最終的に静的型のついたプログラミング言語で書くものも、プロトタイプでは Ruby/Python で書くかというと、私はそこまで動的型に愛はないなあと思う。似た話に、遅い言語で書いてホットスポットだけ速くすればいいというのがあるけれど、これも Reflections on software performance あたりを読むと、ちょっと楽観的すぎるんじゃないかと思う。
あるいはコーナーケースをどれだけ無視するかとか、一番難しいユースケースから挑むべきなのか、一番簡単なユースケースから挑むべきなのかもよくわからない。気分的には簡単なところから挑みたいけれど、これは結果として簡単なことだけできる中途半端なソフトウェアが量産されがちで、一番に難しい問題が手付かずになりがちだとも思う。
そもそも、プロトタイプじゃなくて本番向けの実装を最初から書けばいいじゃん、という気もするけれど「デザインの前に実装します」より「デザインの前にプロトタイプ作ります」のほうが角がたたない感じがしませんか。日和すぎ?