Seaser2終了から学ぶフレームワークとの付き合いかた

Seasar2が終わってしまって、フレームワークとどう付き合うべきなのかなど思うところがあったのでまとめました。

2016年9月26日に終わりを迎えた

この日Seaser2が正式にメンテナンスおよびサポートが終了になった（ただし「DBFlute」「Doma」「Mayaa」など続いているプロジェクトはある。詳しくは公式サイトを参照 → http://www.seasar.org/ ）。

この発表自体に驚きはなかった。その1年前から終わる告知みたいなものはされていたし、もっと前から積極的な新規開発は行われていなかった。なので数年前から徐々に使わなくなっていたし、そんな雰囲気は感じていた。

当時はそれがよい選択だった

心情的にはさみしさと感謝がある。私はSeaser2が流行っていたころに20代中盤で、数々のプロジェクトでお世話になったからだ。

Seaser2が流行っていた頃はStrutsによってフレームワークやOSSという概念が浸透してきた時期で、プロジェクトでどのフレームワークを選ぶのかが一つの大きな関心事だった。「Seaser2」「Struts」「Spring」あたりが有力な選択肢だったと思うが、その中でも「Seaser2」は人気だった。

国産であったことが人気の一番の理由だったと思う。日本語資料の充実などは国産ならではで、MLも中心は日本語だったのでなんかあったらすぐに直してくれそうという考えもあった。なんだかんだ安心感は大きかった。もちろんプロダクト自体もよかった。DIコンテナやAOPなど先端のモノは含まれていたし、個人的にはS2Daoはとても使いやすかった。

フレームワークの選定は難しい

ここでSeasar2を選択したことについてふりかえると、当時、2016年頃終わるかなぁと予想できた人はいなかっただろうし、文句なんか出なかった、妥当だと思えた。これが例えば今だったら「おいおい」ということになる。

継続されるフレームワークを選べなかったという点で言えば、結果的にはSeasar2を間違えであった。ただそれは予想しきれない部分も多いことなので、結果論でしかない気がする。新規開発が停滞してきたあたりに察するぐらいしかなかったのだと思う。

ただ、ここまでの規模感のSeasar2が終わる可能性があるということを真剣には考えていなかった気がする。そんな雰囲気もなかった。

こう考えて行くと、継続されるフレームワークを選ばなければいけないということが無理な話かもしれない。同じフレームワークでも下位互換が確保されないバージョンアップがされる可能性もある。なので選択自体に重きをおくより、フレームワークもいざとなったら切り替えるという覚悟が必要かも知れない。

フレームワークを含めたメンテが必要。それができないプロジェクトはアップデートしないことを覚悟させるor自分たちで直す。

こうなるとSeaser2資産が心配になるが、みんなどうしているのだろうか。私のように数年前から徐々に離れていったのだろうか。全社をあげて使っていくと宣言していた会社もあったような…。

基本的な考え方としては流行りのフレームワークであっても何らかの理由で終わることはある。終わらないにしても実質的に死んでしまっているような状態になってしまうことがある。なので、フレーワークを含めてメンテし続けてプロジェクトを運用していくのが正論なのだろう。

Seasar2ぐらいの規模感であっても終わるのだから、数年単位でフレームワークごと見直す機会を設けるべきなのだろう。予算は前もって確保しておきたい。フレームワーク変更なんて表向きに変化が現れないやっかいな作業だが、やるときはやらないとしょうがない。それがなんとかできるプロジェクトはそうとう必要とされているプロジェクトということ。

Webのフレームワークなんてもはや開発やメンテがいらないと思われるかも知れないがそんなことない。セキュリティ系のメンテは必要だし、スマホやクラウドなど新しいモノは出てくるわけだからそれに対応した新機能はやっぱり必要。

それができないプロジェクトは実質使わなくなったものになっているか、アップデートされないことを覚悟させなくてはいけないってことかな。いやいや、OSSの基本に立ち返って自身でメンテや開発するもの一つの選択肢。ソースは公開されているのだから。

Javaフレームワーク開発入門