エンタープライズにおけるRailsの価値とは

Ruby on Railsが、エンタープライズの中でどのように広まっていくのか。スーツの奴らが金のために煽ってるだとか、エンタープライズRailsってどうよとか、バブルだとか、バブルは弾けたとか、色々な意見があるようです。

言語やフレームワークの考え方の好き嫌いといった哲学的な観点で色々な意見が出たり、テクノロジの観点で様々な意見が出るのは、むしろ良いことだなぁと思うわけですが、どうも違うなぁという考え方が１つあります。

それは「価格競争になったときの選択肢」のためにRailsに取り組もうとすること。それがエンタープライズにおけるRailsの価値なのでしょうか。私は違うと考えています。

単純に、金額のためだけにRailsを選ぶくらいならば、Javaでオフショアを選んだ方がよほど低リスク・低価格だと思いますし、せっかくの生産性の高さを安売りしている風に聞こえます。（それはSIの人月ビジネスの問題に根付く話なので、またいつか。）

私は、Railsの生産性の高さは、仕様の変更にも柔軟に対応できるとか、手早く作って動くものを顧客に確認してもらい、修正しながら、顧客の理想に近づけるため、という、品質向上や満足度向上というところを狙いにすべきと考えています。

もちろん価格競争に勝ち抜くことを考えることは、企業としてはとても重要な課題だと考えています。そのために企業として実施することとして、同一技術を横展開できる部隊を作る、などといった組織マネジメントの観点が大きいと思います。テクノロジの観点だけでは考えられることではないでしょう。

むしろ、エンタープライズでのビジネスを考えたときに、価格競争も考慮するとしても、顧客に対して、品質や満足度といったところでの高い付加価値を提供する提案を実現することで、プライスマターな勝負をしていかないようにしていく戦略をとることが重要だと思いますし、その付加価値のための武器として、Railsを使っていくということはとても有効ではないかと考えています。

私自身、2年間Railsでシステムを構築し、それを保守・運用するＰＪのマネージャをしてきた経験から考えると、講演等でも公言している話ですが、Ruby on Railsを使ったとしても、システムの内部設計までが終わった状態で、ヨーイドンで、プログラミング工程だけを競った場合、Javaで作る場合と、ほとんど差は出ない程度になってしまうだろう、と感じています。

本来、コード量の少なさや、CoCを前提とした設定の少なさが価値を発揮するのは、メンテナンスの場面です。読み込まないといけないコード量の少なさと、少ないコードの変更で修正ができることが、その理由です。そのためには、大前提として、Ruby（on Rails）らしい、プログラムを作っておくことが必須なので、マネージャはその辺りに腐心すべきでしょう。今までと同じやり方では駄目です。

そして、メンテナンスという行為は、システムのリリース後に発生するものではなく、プログラムを1行でも書き始めた時点からメンテナンス作業は始まっている、と考えれば、Ruby on Railsを使うことで、開発時の生産性も高めることができるはずです。（この場合、仕様が完全に固まりきって変更の無いPJでは別です・・・現実的にそんなPJ があるかどうかは知りませんが。）

仕様変更のための修正や対応に対するコストパフォーマンスが、Railsを使うことによって、ある一定の閾値を超えることができれば、要件を確認しながら外部設計をしながら、プログラミングすることができるようになります。そして、そのワークスタイルを実現することができれば、システム開発におけるプロジェクト上のリスクを相当減らし、かつ高い要求実現性を発揮し、顧客からの高い満足度・評価も得られるようになるのではないか、と考えています。

ビジネス的にもWin-Winを狙うことを目指した、システム開発のそのワークスタイルを「アジャイル」と呼びます。エンタープライズにおけるRailsの価値は、その実現を助けることではないか、と考えています。