at posts/single.html

SIer と Rails とエンタープライズと

ニッポンIT業界絶望論など、 SI 業界に逆風が吹いている今日この頃。

生産された財は、最も低水準なサービス財と同様、たった一人の顧客に届けられる。以上おわり。

情報財に固有の、限界費用ゼロで複製できる性質が活かされる余地はまるでない。

OS やミドルウェアは流用されているから複製が0と言うことはないけど、カスタムメイドのシステムよりも広く使えるパッケージの方がコスト的に有利なのはその通りだと思う。 id:gothedistanceさんの「受託開発型のSIという仕事は相当コモディティ化している」という指摘にも強く同意している。 コモディティ化されている状態で、とにかく頭数をそろえるという人海戦術をやっても消耗戦にしかならなくて、同じくid:gothedistanceさんが維持管理なんてやめちまえで書かれている「維持管理でヒトを張り付けにしない仕組みを作ること」という考え方にも賛成。

この辺の話は、ブクマコメントのここここに以下のように書いた。

エンジニアの価値を認めないとダメだよね。今は逆にダメエンジニアを集めて仕事を進めるスキームが出来上がっている。

実現のためには設計の時から運用を考えておく必要あり。問題は維持管理を楽にするための費用を開発時に頂けるかどうか。

LL とフレームワークと分業でも以下のようなことをちょっと書いた。

生産性を多少犠牲にしても、分業によって開発の安定性を選んでいるんじゃないかな。開発チームから一人が抜けても、影響が少ない状態が望ましいからね。デメリットとして、 SE とプログラマの対立とか、刺身タンポポとかの問題が出てくるし、これが幸せな状態かどうかは疑問だけど。

言いたかったのは、安定性を重視しすぎて効率性を失っているんじゃないか、ということ。

Rails とエンタープライズについて

それで、ようやく本題の Rails の話。 id:kuranukiさんが、エンタープライズにおけるRailsの価値とはで以下のように書かれている。

金額のためだけにRailsを選ぶくらいならば、Javaでオフショアを選んだ方がよほど低リスク・低価格だと思います

Ruby on Railsを使ったとしても、システムの内部設計までが終わった状態で、ヨーイドンで、プログラミング工程だけを競った場合、Javaで作る場合と、ほとんど差は出ない程度になってしまうだろう

本来、コード量の少なさや、CoCを前提とした設定の少なさが価値を発揮するのは、メンテナンスの場面です。読み込まないといけないコード量の少なさと、少ないコードの変更で修正ができることが、その理由です。

なんだかすごく同意する。J2EE→Railsにスイッチするなら仕事のやり方も変えないと意味が無いというのが僕の意見。 とにかく頭数を揃えてガッチリしたものを作るやり方だと、前述の江島さんの指摘のようにいずれコスト面でパッケージに勝てなくなる。 なので、これからは、本当に必要な箇所だけを最小限の人数で作る手法が必要。 システムのコストは「開発」だけでなく「維持」でも発生するから、ちょっと拡張するのに費用がたくさん必要になるようじゃダメ。

Ruby 特集の日経ソフトウエアの8月号Rails の記事を書いた時にも、この視点はかなり意識していた。記事のタイトルは「Railsで実現するシンプルなWebプログラミング」。 この記事の最後(77ページ)に、以下のことを書いている。 それ以前の10ページは全て、これを伝えたいために書いていたようなものだった。 もし、機会があると読んでもらえると嬉しいなぁ。

Railsを利用すると、プログラムを書く量が少なくなるため、素早くアプリケーションを完成させることができます。しかし、それ以上に筆者が注目しているのは、できたプログラムがシンプルで読みやすいことです。プログラムには変更がつきものです。読みやすいプログラムであれば変更にも強くなります(後略)

「Rails を使えば SIer の未来は明るい」とは思わないけど、「目指すべき方向を Rails が指し示しているかもしれない」とは思う。 本当に実現するためには…

  • Rails や Ruby とエンタープライズの橋渡し (これは JRuby 方面から進んでいくかも)
  • 仕事の進め方の変化 (プログラマを「信頼」できるか?)
  • 人月やライン数での見積もりからの脱却

たぶん、下に行くほど難易度が難しくなる。 人月で評価するやり方だと、作る方としても人海戦術作戦を採った方がお金になるからね。

なんだか、雑誌の紹介をするだけのつもりが、少し偉そうな内容になっちゃった。

関連する日記