最近、自社のプロジェクトだけでなく、他社の Rails な仕事でも燃えていて、どうにかしてほしいみたいなことを頼まれることが多い。
それらのプロジェクトを見てみると、幾つか共通した燃えてる理由みたいなのがあったのでまとめてみた。
- 画面がかなりリッチ
- 要件や仕様が口伝化している
- 技術スキルが足りない
- そもそも工数が足らない(ww
結論を先に書いておくと、「いくら Rails だろうとちゃんと見積りとプロジェクト管理しないと燃えるものは燃える」。
当たり前の話なんだけど、これが一番多い理由だと思う。
もう少し詳しく考えてみると、見積りに関しては、現時点で、発注側も受注側も Rails を採用すれば、どの部分の工数は短縮できて、どの部分の工数は短縮できないかを把握できていない気がする。
また、教育コストをきちんと計画に盛り込めていない気がする。
そのため、見積りの工数と実工数の乖離が大きくなり、結果、悲しい結果になっていることが多い気がする。
この事は、これまでの Java な仕事の時でも、採用するフレームワークの特性の分析や教育コスト等は考えてきたはずなので、それをそのまま実行すれば良いと思う。
確かに、Java な仕事が主だった場合、言語自体が変わるので教育コストがどれくらいかを考えるのは難しい気はしますが、デブサミの発表で聞いたパイロット開発みたいな事を行なえば、ある程度は計測できる気はするなぁ〜。
また、開発プロセスの方でも、ゆるい仕様や口伝ベースで進めるのはリスクが高いと思う。確かに、Rails なプロジェクトの場合、そういった方向に行きやすかったり、タスクの分け方とかも若干影響したりしますが、基本は今まで通り当たり前の事をすれば回避できると思う。
とは言え、Rails を採用した事で、色々と試行錯誤しているので、どうしてもそういった基本的な所が抜けてしまうのは、私もやった間違いなので非常に良く分かったりもする。
とりあえず、ここまで。
上で書いた項目の詳細とかは、要望があれば追々解説していく予定。
AUTHOR: nawoto
DATE: 02/08/2010 13:53:31
そうです。
>当時の思いとして良い道具(技術)だからといって、それらの利点や前提を知らずに採用すれば失敗します。技術面とリスクをきちんと分析するといったプロジェクトの運営面の両方が大事ですって事が伝えたかった事でしたAUTHOR: babydaemons
DATE: 12/13/2009 00:39:48
Railsも魔法ではないということですね。格言的にいえば銀の弾丸などないとか言うやつですか。
>とはいうものの、RESTなサイトを作るときに実装に関していえば私が使える技術の中では
>Railsが一番の近道なのは確かです。
>性能とか運用とか未経験なのでわかりません。orz