+1

2009年2月10日火曜日

「完璧」を捨てる

中途半端な「完璧」主義ほど、やっかいなブレーキはないなあと思います。現状で完璧な状態じゃないから始めない。始められない。とてもやれない。システムを構築する時も、たくさんブレーキがたくさんかかったりします。

 ・高負荷時の問題点は?
 ・セキュリティリスクは?
 ・今後の拡張性については?
 ・安定稼働させるための仕様は?
 ・障害からのリカバリ対応は?
 ・スクリプト言語は何が適切か?
 ・DBを使うべきか使わないべきか?
 ・DBを使うなら何を使うべきか?
 ・システム移行の際の安全性は?

全部、大事なことです。すごく大事。最初のウチから考えておくべきこと。大規模なモノについては、最初からキッチリとした仕様を作ることが肝心。・・・なんですが、全てに適用すべきかというと、それは違うと思います。

「このサービスは、絶対に利用者が増えていくはずだ。」
「爆発的に利用されたら、次はこういう機能を付けよう。」
「セキュリティリスクがあるからチェックを徹底的に。」

どれも想定として大事なんだけど、あまりやりすぎるとゴテゴテしていく。最初はシンプルだったものが、気づいた頃にはシンプルじゃなくなっている。シンプルじゃなくなったシステムは、複合的なトラブルを抱えやすくなる。

どうせ「完璧」なんてないんだからさ。むしろ完璧を最初から目指したシステムを後から作り直そうとすると、最初から作り直した方が楽なことの方が多い。どうせ作り直すなら初回のトライはアドホックに作っておいて、後から焼き直せばいいんだと思う。

システムだけに限らない。報告書にしてもそうだし、提案書にしてもそうなんじゃないのかな。まずはやってみる。走り出して走りきらないうちに周りに見てもらう。方向性が固まりきって硬直してしまう前に、いろんな提案や感想を聞いてみる。

βバージョンでいいじゃない。
ミクシィだって未だにβバージョンだ。

まぁ、ミクシィはそろそろβじゃなくなってもいい頃だと思うけど。

0 件のコメント:

コメントを投稿