最初にマイルストーンを切って、この週で設計、この週で実装、みたいなことをやるのはおすすめできない。
設計に使える時間を最初に決めた時間までしか使わないということは、どうすればいいか、考えきれてなくても作り始めているということ。
コードは書けていくので、進んでいるようにも見えるけど、問題を先送りしているだけなので、じっくり設計や作戦を詰めていれば気付ける問題に、あとのほうで直面することになる。
この問題を回避するためにはこのように作るべきであった、ということにあとで気づくと手戻りが大きくなり、こんなことをするくらいなら最初に決めておけばよかった、となることが多いと思う。
家を建てることをイメージすると、設計フェーズはここで打ち切って、手を出せるところから始めよう、といきなり柱を建てることをイメージしてほしい。
先のことを見据えると、4本の柱は長方形になっているべきという制約があるけど、そのことに気づかず、適当な四角形で柱を建ててしまい、家具とのフィット感が低いことに気づいても、あとから戻すことはできない。
まったく手を出せないわけではなくて、あとのフェーズに影響が出ない切り分け方がうまくできると、各フェーズで小さく動くものを作っていくことができる。
そのときに、もとに戻せる形で作っていって、もとに戻せない変更は最後まで手を付けずにおいておけると良い。
なので、設計の最初の段階で考えることは、問題の解き方ではなくて、問題の分解の仕方ということになる。
どのコンポーネントにどのような制約があって、どこがどこの影響を受けるか、どこをどう決めると、どこが動かせなくなるか、ということを見ていって、その上で、よくわからないところは後回しにする。すると、周りのものができていく中で詳しいことがわかっていって、これなら解けますね、と着地する。というのが理想。
最初から難しいところをやっても、まわりの制約が見えてなければうまく結合できないことがある。
最近やった事例では、データを貯めるとこを作って、普通ならデータを参照する部分を作るのが、そうではなくて、得られたデータがあるとして、やりたい計算が本当にできるかの検証をしていった。それで、このような入力からこのようなデータを得られればよい、ということがわかってから、データ参照する部分を作ることにした。
そうすることで、勘で参照部分を作って、あとで無理して使うのではなくて、必要だと分かっている形式がはっきりしてから実装に入ることができた。
また、データを貯めてるだけで参照していないので、問題があればデータの蓄積部分には好きに手を入れられる形で進められた。
社内ブログに書いたのでこっちにも貼っておく