フレームワークの採用基準とは？

◆フレームワークの浸透

1997年に Servlet 技術が公開されから現在までに、Java による Web アプリケーションはさまざまな形態で実装され、社会に根を下ろしていきました。

ほんの数年前には、Servlet や JSP 内にいわゆる MVC が混在してしまっている、メンテナンス性の悪い仕組みが蔓延していたものですが、現在はフレームワークを採用しないプロジェクトは、ほぼ皆無、という状況ではないでしょうか。

フレームワークの採用自体が、設計や作業、ソースコードの標準化と再利用性を高め、ひいては生産性と品質の向上が見込める、という認識が広まったことは、大変喜ばしいことと思います。

しかし、フレームワーク自体も複数選べる時代となったがゆえに、果たしてどれを選択してよいものか、悩んでいるマネージャも多いのではないでしょうか。

その結果、無難に Struts（2000年〜）という古い技術を使用するプロジェクトも、まだまだ多いと聞きます。

そこで本稿では、フレームワークの採用基準について、弊社が考えるおおまかな目安をお知らせしたいと思います。

◆フレームワーク採用基準

（1）要件

フレームワークが要件を満たせることが大前提となります。

　　・とにかく高速化が必要。
　　・複雑な GUI が多い。
　　・帳票が工数の大部分だ。
　　・DBMS は変更できない。
　　・大量のバッチ処理の生成が必要。

などなど、プロジェクトごとに固有の困難さをいかに早く解決できるか、それを極力満たせるフレームワークであることが肝要です。広義のフレームワークという意味では、SAP や SalesForce.com などを使用することも、業務要件にマッチすれば、多大な効果を生むと言えます。

（2）規模

プロジェクトの規模が大きくなれば、適切なフレームワークの選択による利用効果が高くなりますが、当然ながら、フレームワークのデメリットによるリスクも、それに応じて大きくなります。

したがって、一定規模以上のプロジェクトであれば、上流工程で必ずフレームワーク選定期間を確保すべきです。あらかじめパイロットプロジェクトで利用することができれば、理想的です。

（3）機能

ひとくちにフレームワークといっても、機能は様々となります。

例えば、Ruby On Rails のような、フルスタックのフレームワークであれば、GUI から永続化までをサポートしているので、それのみで開発を網羅できます。

しかしながら、高機能であることが同時に敷居を高くしており、習得が困難であることや、採用検討段階での調査に時間がかかる、などのデメリットがあります。

逆に軽量かつ守備範囲が限られたフレームワークを複数採用する場合は、機能がシンプルである分、作りこみ部分が多くなるケースや、組み合わせによる複雑さが増す可能性があります。

（4）性能

高性能が要求される場合は、思うような効果が出せない場合があります。

例えば SQL を完全自動生成できるうたい文句のフレームワークを採用したが、実際はほとんど手でチューニングしなければならず、その場合、急激に効率が落ちてしまうことがわかった、といったケースなど。

一般に性能の面でシビアなプロジェクトの場合は、最終的にソースコードレベルでのカスタマイズが可能な体制を用意すべきです。

（5）費用

有償フレームワークには、初期費用のみならずサポート費用が多額になる場合があります。

逆にオープンソースのフレームワークは導入費用は無料ですが、困ったときにサポートが受けられるかどうかが心配、といった声もあります。フレームワークの経験や、効果などトータルの費用で検討すべきです。

（6）運用

例えば、設定ファイルが膨大になるようなフレームワークは、環境設定に予想外の工数を要します。

運用時点でのミスは致命的になりがちなので、あらかじめ運用コストの判断時に、確認が必要です。

（7）技術者との相性

フレームワークの選択はプロジェクトの成否に関わるので、やはり、技術者がある程度知識のあるフレームワークは無視できません。

もちろん、習得容易性なども考慮すべきでしょう。

また、技術者のレベルによっては、自動生成の部分を多くするといった方策も必要になります（もちろん、カスタマイズ容易性との兼ね合いとなりますが）。

（8）実績・将来性

OSS のフレームワークには、すばらしい思想を持ったものもありますが、実績を伴わないものには、なかなか手を出しにくくなります。

特に、開発主体がこれまでどれだけバグフィックスしてくれているか、また今後そのフレームワークの開発をどれだけ継続してくれるか、といった確認も必須です。

◆弊社の場合

以上、フレームワークの採用基準についてさまざまな角度から見てきました。

弊社の場合は、2002年当時に、なかなか条件にあうフレームワークが見つからなかったこともあり、それならば自作してしまえと、pirka（前身の HBJ）を生み出した経緯があります。

開発コストと勘案する必要はありますが、フレームワークを外部から持ち込むだけでなく、チームにとって使い勝手がよいように改良したり、共通部品を作成するなど、一層の標準化・共有化なども、当然ながら積極的に進めるべき施策と考えます。