作っては壊して進んでく
昨日無事設計データをテープアウトすることが出来ました。スケジュール的には余裕だと思っていたんですが、結局データを提出したから手元でその最終検証をするという綱渡りっぷり。でも全体LVS通ってたので、まずは一安心といったところです。
さて、設計期間中ずっと思ってたことをまとめようと思います。
プログラムやICを作るときには上流→下流という流れ（いわゆるウォーターフロー型開発）をすることが多いと思うんだけど、どうもそれになじめない。きっちりと決められた仕様に沿って進めていくよりも、ちょっと作ってはああじゃない、こうじゃないと悩んで壊してまた書いてといった形じゃないとうまく進められない。一発で綺麗なものができることはほとんどなくて、設計のスピードが思うように上がらない。もともと思考が発散しやすい僕の頭のつくりは、もしかしたら大規模開発には向かないんじゃないか、という気にすらなっていく。
でもどうやらそうじゃないらしい。
これに関しては、自信を持って言えるのだが、「どんなに優秀なエンジニアでも、決してプログラムを自分自身で書かずに良い詳細仕様を作ることは出来ない」という絶対的な法則があるのだ。私の知っている優秀なエンジニアは、皆それを知っており自ら実行している。もちろん、彼らはプログラムを書き始める前に大まかな設計をするのだが、十分な経験を積んだエンジニアは、その段階でのものが「仮設計」でしかないことを良く知っている。だから、その段階で詳細設計書を書くような時間の無駄使いはせず、すぐにプログラム（もしくはプロトタイプ）の作成にかかるのである。
実際にプログラムを書き始めて初めて見えてくること、思いつくことが沢山あるので、それを元に柔軟に設計を変更しながらプログラムを書き進めるのである。作っているプログラムが予定通りに動き始めてやっと、設計も完成に近づくのである。（ただし、そんな作り方で作ったプログラムはソースコードが汚くなってしまうケースが多いので、この段階から出来上がったプログラムを、読みやすさ・メンテナンスの高さを重視して大幅に書き直すことを強く薦める。エンジニアによっては、ここで一度作ったプログラムを全部捨ててしまってもう一度全部作り直す人もいるぐらい、この作業は重要だ。）
実は、このポール・グラハムが感じていた引け目というのと同じ類ものを、僕もずっと感じ続けていました。僕がこれまで読んできた多くの技術書には、プログラミングは詳細に設計された設計書を実際の形に落とし込むための手段に過ぎないとか、オブジェクト指向開発においてはコーディング作業は全体の中で占める20%の作業にも満たないとか、そんなことが書いてありました。一時はそれを正しいと思って、実践しようと思い試行錯誤を試みたものでした。
でもなんだかうまくできませんでした。僕がプログラミング言語を使わずに考え出したソフトウェアというのは、綺麗に設計されているようで、実際に作り出してみるとまったくその通りにいかない。あそこがおかしい、ここがおかしい。紙の上の設計に後戻りしては設計書の間違いを訂正するのです。なんでだろう、本にあったとうりにやっているのに! そのときは、僕にはソフトウェアを綺麗に設計する才能がないんだろうと思い込んでいました。
トップエンジニアと呼ばれる人でさえ、仕様を実装にすんなりと落とし込むことを必ずしも良しとしていないことにやや勇気付けられました。もちろんある程度しようをしっかり決めないといけないことは自明だけど、それに囚われることなく作って壊して、という姿勢もありなのかな、と。
今回の反省としては一回で完成版を作ろうとするのではなく、プロトタイピングと清書の時間を自分の中で計算していなかったことがスケジュールの遅延を招いたのではないか、ということかな。
綿密に計画された旅より、行き当たりばったりで行動する旅（とか人生）のほうが好きです。
