RIAをSIerの仕事道具として普及させるには

SI


SIerで働いているが、RIAが今一流行っていない。Ajaxはいまだに様子見の段階で、要件上どうしようもないところだけ恐る恐る導入している感じだし、Flexも実案件で結構トラブルが起きていて今一みたいな風潮になっている。自分の身の周りだけの話かもしれないが、お客さんはRIAを望んでいるにも関わらずSIerがRIAを敬遠しているように感じる。


なんでなのか、ちょっと考えてみた。



SIerの技術要素を選択する際の判断基準を２つ挙げると工数と品質になる。


まず工数だが、リッチな画面の要件がどのくらいあるかとか、メンバーのFlexに対する習熟度とかあるので普遍的な数値ではないが、今までの経験から得た実感としてFlex開発にかかる工数はJSP/Strutsによる工数の3倍程度かかる。そして全体で見ると、リッチな画面の開発よりも、通常の範囲内の機能を持った画面の開発に工数がかさむ。


そのため、必然的に、リッチな機能が必要な画面のみRIAを採用し、それ以外の部分は従来どおりJSP/Strutsで開発するという選択をおこなうが、これはこれで覚えないといけない技術要素が増えるのでチーム編成を考える上で頭を悩ます種となる。また、リッチな画面が当たり前になると、お客さんは当然のようにそういう機能を要求してくるわけで、結合テスト終盤ぐらいになって突然JSPで作った画面を次から次へとRIA製品で置き換えていくような案件が一つのトラブルパターンとして最近よくある。


企業の基幹システムなんかのリッチな機能はほんの一部分しかいらないみたいなアプリケーションの構築でRIA製品が採用されるためには、リッチではない画面の開発をJSP/Strutsでの開発効率に近づけていくことが絶対必須だと思う。



次に品質だが、SIerのいう品質っていうのが何かというと、「低スキルなプログラマーを大量動員した時に最低ラインの品質を確保できるかどうか」ってことだと自分は思っている。普通、プロジェクトは、開発費用を抑えるために高スキルな技術者数人と低スキルな技術者大多数で構成される。プロジェクト内には、高スキルな技術者は必要最低限な数しかいない。


高スキルな技術者は技術要素を選択して低スキルな技術者に開発の仕方をガイドすることが主な役割となり、ドキュメンテーションと打ち合わせが業務時間のほぼ全てを占める。昔は内製のフレームワークの実装なんかもやっていたが、今は通常の案件で必要な機能がほぼすべてOSSとして存在しているのでフレームワークはそれを組み合わせるだけでだいたい出来上がってしまうため、プログラミングはほとんどせず組み合わせを考えることがメインの作業となる。プログラミングは低スキルな技術者だけがおこなう作業となる。なので、低スキルな技術者向けが使うことを想定してどうなのかという視点で技術は評価される。


で、こういう観点でいうと、開発環境の貧弱な現状のRIAはSIerの仕事道具としては選択しづらい技術にカテゴライズされてしまうのである。Flexの場合ベンダーが開発環境を整えていこうとしているものの、それでも画面開発をGUIツールでやるのは現実的でなかったりするわけで、Javaの世界のようにIDEのプラグインのコマンド一発でスケルトンコードがすべて吐き出されて、手作業では業務ロジックしか書かないみたいな状態にまで持っていく必要がある。


エンタープライズをターゲットにしたRIA製品は、開発環境を充実させること、とくにリッチではない部分の開発効率を良くすることに主眼をおくべきで、リッチではない画面が今まで以上に効率よく開発できればSIerのデフォルト技術がJSP/StrutsからRIAに一気に流れると思う。