まず、まとめ Rails でも View にかかる工数はあまり変わらない。 web 2.0 っぽいリッチな画面は技術リスクが高いので、思ったより高くつく どうも、上記ふたつの点で計画との乖離が大きくて、失敗するケースが多い。 Rails なプロジェクトの場合、俗に言う web 2.0 の文脈からか従来よりリッチな画面を要求されがちである。 確かに、Rails はそういうアプリケーションの作成には、非常に向いていると思う。 しかし、どうして向いているのかを考えてみると、大きな理由として、Rails では従来 Model と Controller に必要だった工数を大幅に削減できるため、その分の工数を View に回せるからだと僕は思っています。 prototype.js や script.aculo.us などの有用なライブラリや Try and Error のしやすい環境で View の開

最近、自社のプロジェクトだけでなく、他社の Rails な仕事でも燃えていて、どうにかしてほしいみたいなことを頼まれることが多い。 それらのプロジェクトを見てみると、幾つか共通した燃えてる理由みたいなのがあったのでまとめてみた。 画面がかなりリッチ 要件や仕様が口伝化している 技術スキルが足りない そもそも工数が足らない(ww 結論を先に書いておくと、「いくら Rails だろうとちゃんと見積りとプロジェクト管理しないと燃えるものは燃える」。 当たり前の話なんだけど、これが一番多い理由だと思う。 もう少し詳しく考えてみると、見積りに関しては、現時点で、発注側も受注側も Rails を採用すれば、どの部分の工数は短縮できて、どの部分の工数は短縮できないかを把握できていない気がする。 また、教育コストをきちんと計画に盛り込めていない気がする。 そのため、見積りの工数と実工数の乖離が大きくなり、

この前、会社の仲間たちと「誠実な開発」って話をした。 何をもって「誠実」なのかはそれぞれ解釈があると思うけど、僕たちは「お客様に正直である」、「お客様に嘘をつかない」が繋がると思っている。 納期間近になってお客様に「この機能は納品できないかもしれません」と調整したり、MS-Excel で書かれたよく分からない画面デザインを見ながら、適当に「これで大丈夫と思います」と言うのは、騙すつもりは無いがそれは不誠実だと思う。 単にビジネス面で成功を考えるなら超絶なスキルであったり、巧みな交渉術などがあれば、そんなもんは必要ないかもしれない。 けど、僕みたいな普通のちょっと下な人間にはもちろんそんなスキルは無い(www ちゃんと、どういった開発を行なっているか open にし、また、実際に画面だけでも動作するものを前にお客様と談笑しながら、システムのイメージを膨らませていく。そういった普通の事が「誠実

少し前から RoR な仕事をしているのですが、RoR はハカー御用達みたいなイメージがあったんだけど、案外、普通の SI 屋さんのプログラマでもどうにかなるもんだなぁっと思った。 振り返りも兼ねつつ、良く人に聞かれる事とかまとめていきたいなぁ。

グダグダになりそうなので, せめて軸がブレないように今のスタンスを書いておこう. 私は LL(Ruby, Python and more) は「Beyond Java」ではなく, エンタープライズ開発のためのアプローチの一つだと思っている. 最近, メディア等で「Beyond Java」という文脈で LL が紹介される事が多くなった. その中には「行数が少ないので生産量が云々」といった視点で語られる記事も少なからず見かける. これに関しては, 私も納得はできない. タイプ量や簡潔な表記が有効な場面は存在するとは考えているが, それが単純に生産量に結びつくとは思えない. しかし, エンタープライズの世界での開発は, 過去と比較した場合, より複雑な要求や困難な問題に直面しているように思う. また, 今後, さらにそれは加速していくようにも感じられる. そういった場合に, はたして Java