Life is beautiful

　昨日書いた「『時間に余裕があるときにこそ全力疾走で仕事し，締め切りが近づいたら流す』という働き方」というエントリー、Twitterやハテブでたくさんのフィードバックをいただいたが、その中で気になったものの一つが、「そうは言っても仕様がころころ変更になるからスタートダッシュで仕事をしていたら時間が無駄になる」というもの。

　まず最初に言っておくと、「仕様がころころ変更になる」のはソフトウェアの宿命。どんなに頭の良い人が設計しても、「作ってみなければ分からない」「使ってみなければ分からない」ことはどうしてもあるので、「アーキテクチャの大幅な変更」「ユーザーインターフェイスの大幅な変更」があるのはあたりまえ。

　ぜひとも認識して欲しいのは、「だからこそスタートダッシュで肝となる部分を一気に作って、早めに（仕様変更が必用かどうかの）見極めをする必用がある」という点。特に「作って見なければ分からない」部分の見極めのためのコーディングの時間を惜しんでいては、良いものは作れない。紙の上での設計・仕様書作り・会議に時間をかければかけるほど、そのかけた時間そのものが足かせになって柔軟な発想ができなくなる。それよりも、発想が浮かんだ時点で実際にコードを書いてみて「これで行けるかどうか」の実感をつかむことが大切。

　まだ半信半疑の人も多いだろうから、具体的な例をしめそう。先日のエントリーにも書いたCloudReadersとneu.Notesのコードを組み合わせて「PDFの赤入れ」を可能にしようというプロジェクト。当初計画していたアーキテクチャではうまく行かず、次のアーキテクチャで作ってもうまくいかず、ようやく三番目で「商品化する価値のあるアーキテクチャ」にたどり付けた、という典型的な「大幅な仕様変更を伴う」プロジェクトだ。

　実際にどうやって作ったか言えば、「仕様書も書かず、UIの細かな設計もせず、とにかく肝となる部分をスタートダッシュで手早く作る」を三回繰り返しだだけのこと。一つ目のアーキテクチャに基づくプログラミングに約３日かけた後、それを破棄、二つ目のアーキテクチャに基づくプログラミングに約２日かけた後、それを破棄、そして三番目のアーキテクチャに基づくプログラミングに同じく２日だ。

　この段階で大切なことは、

• 書いたプログラムを捨てることを恐れないこと
• この段階で仕様書を書くことは時間の無駄と認識すること
• 細かなことを無視して、一番難しい部分を最初に作ること
• できるだけ早く、一気に「見極めが出来るところ」まで持って行くこと
• コードは多少汚くても良いが、モジュール間のインターフェイスだけはキチンと設計すること

の５つである。とにかく、このプロセスの目的は、「このアーキテクチャのままで製品化できるのかどうか」「想定しているユーザーシナリオに合致したものができるかどうか」の「見極め」をすることなので、それ以外のこと（たとえば仕様書を書く、ミーティングに出席する、ユーザーインターフェイスの細部を決めるなど）に時間を使わず、とにかく一日でも早く「見極め」ができるところまで持って行く。

　この「見極め」の段階で、「このアーキテクチャではだめかも知れない」「これではユーザーモデルに矛盾ができて使いにくくなる」と感じたら、ばっさりと切り捨てて、もう一度作り直す。アーキテクチャに不安を抱えながらずるずると作り続けても決して良いことはない。

 【図の解説】この図の一番上のグラフが私が推奨する開発プロセス。最初に思いついたアーキテクチャで８割型動くところまで一気に持って行き、そこで「これで行けるかどうか」の判断をする。「このままでは行けない」と感じたら、あっさりと最初に戻り、次ぎのアーキテクチャで作る。これを繰り返し、納得できるアーキテクチャに到達したところで、後は流す（コードをきれいにする、UIの細部を詰める、徹底的にテストをする、コメントを入れる、など）。

　二番目のグラフが、同じプロセスをラストスパート型でした場合。スタートダッシュ型と比べてやたらに時間がかかるのが分かると思う。

　しかし、実際にはラストスパート型でプロジェクトを進めた場合に陥るのが三番目のグラフのパターン。それなりに時間もかけてしまった、詳細な仕様書も作ってしまった、そのアーキテクチャで行くことの承認も取ってしまった、などの理由で、一度採用したアーキテクチャ・書いてしまったコードを捨てられなくなるのだ。なんとかアーキテクチャの大変更だけは避けようといろいろと工夫をするのだが、バグがバグを呼び、ドツボ（デス・マーチ）にハマるのがこのパターン。