«前の日記(2007-11-08 (木)) 最新 次の日記(2007-11-11 (日))»  

まちゅダイアリー


2007-11-10 (土)

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 方面から進んでいくかも)
  • 仕事の進め方の変化 (プログラマを「信頼」できるか?)
  • 人月やライン数での見積もりからの脱却

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

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

Tags: Ruby
本日のツッコミ(全3件) [ツッコミを入れる]
kenz (2007-11-11 (日) 04:26)

うちの会社の例で言うと、予算が案件ごとで評価されていて、それが元凶だと思う。<br><br>保守やほかの案件への流用を考えて設計すると、開発工数が余計にかかるから、いいものが出来ているのに評価が下がる。<br>だから、皆流用を考えずにがちがちに作っていて、開発ソフトウェアが資産で残らないし、保守で赤字が膨らむ<br><br>おまけに、たとえ流用可能な物が出来ても、ほかのプロジェクトの開発効率が上がると、相対的に自分たちの評価が下がるから、作ったモジュールを別部署に流さない。<br>もうなんだがgdgd<br><br>たまーに正規化されているDBを見るだけで感動して、開発者の名前を調べて拝んでいる毎日。<br>まぁ、その人はたいてい既によその会社に移っているんだけど・・・

PoohKid (2007-11-11 (日) 05:46)

エントリをあげていただいたのでこちらにコメントさせていただきます。<br><br>>「丸投げSEが下請けPGを浪費する」とすると顧客が直接PGに発注しないのはなんででしょうね? > id:PoohKid<br><br>単純に考えると、自分達で開発を完結させる企業の絶対量と、顧客の現状のパイプがそこに繋がってないことが理由だと思います。<br><br>そのような企業は少数ですが登場し始めてますよね。私の知る限り(で知名度がありそうなところ)では、スターロジックさんやゼロベースさんなど。<br><br>SIerさんの中にも優秀な方やアジャイルな方がたくさんいることは十分承知しているつもりです。そういう方々が活躍できる場所はITゼネコン構造のなかではなく自社で開発を完結できる環境にこそあると思っています。<br>(プロジェクトによって色々違いがあるかもしれませんが)<br><br>ちなみに顧客はSIerのSEと下請けPGの単価が倍ほど違うことはご存じなのでしょうか???<br>完全に設計済みのものを外注するならまだしも、設計段階から一緒に作業していたり、プロジェクト後半には偽装請負状態で同じオフィスで同じ様な障害対応業務をしている状態で妥当な価格とは思えないのですが。。。

まちゅ (2007-11-11 (日) 06:28)

>kenzさん<br>人が増えすぎて縦割りになるってのはありますよね。囚人のジレンマみたいです。<br>どこかで誰かが第一歩を踏み出す必要があるのでしょうが。江島さんの警告がそのキッカケになるといいかもと思っています。 <br><br>>PoohKidさん<br>idコールへのお返事ありがとうございます。<br>自社で開発を完結できないということは、その分を丸投げSEがやっている訳で、それってなんだろうと思ったのです。<br>やっていることと対価の妥当性は別問題ですが。<br>PoohKidさんのおっしゃるような自社で完結した企業が増えると、この業界も面白くなりそうですね。<br>梅田さんの言う「スモールビジネス」の時代かもしれません。