ソフトウェア開発プロジェクトを蝕むさらに10の過ち - (page 3)

7．計画を立てる前に約束する

　また、ある読者は、電子メールでわたしの最悪の悪夢の1つを思い出させてくれた。それは、開発者と話をする前に、顧客に「イエス」と言ってしまう営業担当だ。これは多くの場合、ベンダーと顧客の双方を、悲惨さ、苦痛、欲求不満、失望に導く道だ。プロジェクトはすぐに遅れはじめ、開発者は非現実的な期限を守ろうと苦労することになる。

8．最先端の技術に頼る

　開発者のMichael Graziano氏もまた、電子メールで多くの提案を送ってくれた。その中の1つに、まだ新しく実績のない技術をプロジェクトで使おうとする開発者の習性があるが、これにはわたしも同意せざるを得ない。これをやると、プログラミングは綱渡りになる。その新技術には圧倒的な利点があるのか。今後使われない技術を使おうとはしていないか。正しい技術の選択はひとつの芸術だが、先週SourceForgeに最初のベータ版が掲載されたライブラリを使うのを避けるようにすることで、少しは楽になるだろう。

9．自前の技術を使う

　上述の開発者が指摘したもう1つのポイントは、多くの開発者はフレームワークやライブラリを購入するのではなく、自分で設計して書きたがる習性を持っているということだ。自前のライブラリやフレームワークには利点があることも多いが、欠点もまた多い。自前のフレームワークとライブラリの設計、開発、テストの作業に取りかかる前に、そうすることの重要性をしっかり評価すべきだ。

10．間違ったプロトタイプを作る

　同開発者からの最後の項目は、プロトタイプに関するものだ。彼は実際のプロジェクトで使うものとはまったく異なるシステムで、アプリケーションのプロトタイプを作った開発チームの話をしている。勘違いしないで欲しいのだが、プロトタイプを作るのはよいことだ。そして一部のケースでは、そのために設計された言語やシステムでプロトタイプを書いてみて、教訓を学び、実際の作業を始めるときにはそのプロトタイプを捨てることも有効だ。危険なのは、プロトタイプに多くの時間をかけたが、実際の製品を作る際には役に立たない教訓しか学べないということが起こり得るということだ。

　例えば、Ruby on Railsでプロトタイプをくみ上げ、Railsでデータベースにアクセスする方法については多くを学んだが、その後ASP.NETで製品を作るというのでは、時間を無駄にしただけだ。Railsでプロトタイプを作って、バックエンドに関しては最小限の作業しか行わずに済ませ、それを使ってユーザーから意見を集めた上で、ASP.NETで本物を作るというのであれば筋は通る。