引用: Life is beautiful: スタートダッシュ型仕事術：実践編 まず最初に言っておくと、「仕様がころころ変更になる」のはソフトウェア の宿命。どんなに頭の良い人が設計しても、「作ってみなければ分からない」 「使ってみなければ分からない」ことはどうしてもあるので、「アーキテクチャ の大幅な変更」「ユーザーインターフェイスの大幅な変更」があるのはあたり まえ。 ぜひとも認識して欲しいのは、「だからこそスタートダッシュで肝となる部 分を一気に作って、早めに（仕様変更が必用かどうかの）見極めをする必用が ある」という点。特に「作って見なければ分からない」部分の見極めのための コーディングの時間を惜しんでいては、良いものは作れない。紙の上での設計・ 仕様書作り・会議に時間をかければかけるほど、そのかけた時間そのものが足 かせになって柔軟な発想ができなくなる。それよりも、発想が浮かんだ時点で 実際にコードを書いてみて「これで行けるかどうか」の実感をつかむことが大 切。 (略)

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

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

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

製品化されるプロジェクトでなくても同じだな… プロジェクトの一番のキモになる部分が自分の想定したイメージ通りかを先に試す必要がある。 プライベートのプロジェクトでは自分の時間を投資しているわけだから、キモが実現出来るかどうかを早目に見極めて続けるか/やめるかを速い段階で決断しないといけないわけだし。

この記事を読んで、早速[Nendo]の開発の優先順位が変わった。 define-rulesとかどうでもいいので(誰がいつやっても実装できるに決まっている) 先にRubyとの連携部分をもっと詰めるべきだと思った。

よし。いろんなgemsを使ってみて問題点を洗いだし、先に解決していこう。(そのためにはそれなりに使えるツールを作る必要あり？) SRFIライブラリの充実とかは後でじっくりやればいいのだよな。(util.listだけは普段必要としているので先にポーティングするかも)