08/09/11 01:21:36 2+ZUqf6O
一、先に素材を用意しろ
一、見た目から入れ
一、考えてないで書け
一、フェイルセーフは二の次
一、高速化は二の次
一、エンドユーザはどうせ結果しか見ない
一、無駄な機能は全て外せ
一、付けたくない機能はやる気が伴わないのでバグを生む
一、コードを書かない人間の話を聞きすぎるな
どんな機能の実現にも少なからず労力がかかり、やる気が伴わない機能はバグを生む。
思い付いた機能は全て付けておけ、オプションでON／OFFできれば邪魔にもならない、という考え方は全く間違っている。
機能が増えて安定性が上がるプログラムはない。10000行をデバッグする労力は1000行をデバッグする労力の10倍ではない。
無駄な機能など一つも付けてはならない。
ポテンシャルを上げるのは結構なことだ。だが問題はそこではなく、それを用いて本当に面白いことができるかどうかである。
全ての新機能にはエンバグという呪いがかかっている。極端な話本当は新機能など一つも付けたくはない。
ことに（SSTPのような）ネットワーク絡みの機能はセキュリティやらプライバシーやら本来の機能とは
全く関係のない部分にまで気を使わなければならない地獄のような代物だ。それら数々のデメリットを覚悟の上で
新たな機能を実装するためにはその機能を付けることで間違いなくリターンが得られるという確証が必要である。
それを示すものが企画書であり素材だ。
先にネタがあり、その実現方法としてテクノロジがある。使われないポテンシャルほど滑稽で有害なものはない。
人を動かすのは完成図であり、それは端的に言えば素材だ。
まず素晴らしい素材があり、それを動かしたい、命を入れたいと思うから後付けで仕様ができる。
ペラ紙1枚で企画は立ち上がらないが、長大な企画書もまたごく少量の「実物」の前にあっけなく敗北する。
荒削りなプロトタイプや僅か数枚の絵が計画全体を大きく動かす。
-- Finite Laboratory Root - 教訓 Reprise, June 17, 2003 (Fri)