【スプリングブーターの漂流記 #1】Spring Boot歴10年超のSE、今さら外の世界が気になり始めた

はじめに：10年以上使い続けてきたSpring Boot

システム開発に携わって20年以上。そのうち10年以上、Spring Bootを使ってきました。

開発のスピードを大きく変えてくれた、頼れる相棒です。今でも、その信頼は変わりません。

けれど、ふと思いました。

もし今、何もないところから新しいシステムを作るなら、私はもう一度Spring Bootを選ぶのだろうか。

使い慣れているから、という理由をいったん脇に置いて考えてみたい。ほかの技術にも触れたうえで、自分の選択肢を見直してみたくなりました。

「スプリングブーターの漂流記」は、そんなSEの技術探索の記録です。初回は、出発点となったこれまでの経験と、これから確かめたいことを書いてみます。

Spring Boot登場前のJava開発

Spring Bootを使う前は、Struts 1やStruts 2、Spring Framework、Java EEなどで開発していました。

当時の開発を振り返ると、業務の処理を書く前に、設定や実行環境を整える作業がありました。XMLの設定やライブラリの組み合わせなど、アプリケーションを動かすための準備も仕事の一部でした。

もちろん、そこで身についた知識は、その後の開発にもつながっています。ただ、作りたい機能にたどり着くまでの道のりは、もう少し短くならないものかと思っていました。

Spring Bootとの出会いは衝撃だった

Spring Bootを使い始めて強く感じたのは、「開発のスピードが格段に上がった」ということでした。

XMLで書いていた設定が減り、依存関係の管理がしやすくなりました。組み込みTomcatでアプリケーションを動かせることも、REST APIを作りやすいことも、私には大きな変化でした。

それまで準備に使っていた時間を、作りたい処理に回せる。その手応えがありました。

プロジェクトの構成をそろえやすくなったことも、チームで開発するうえでは助かりました。長く使い続けてきたのは、こうした便利さを実感してきたからです。

一度基盤を作れば、開発は驚くほど進む

とはいえ、Spring Bootを選べば、最初からすべてが決まるわけではありません。

私の開発では、パッケージをどう分けるか、ログをどう出すか、セッションや例外をどう扱うか、といった判断が必要でした。依存関係も含め、最初の基盤は試行錯誤しながら作っています。

その後は、既存プロジェクトの基盤を出発点にして、バージョンに合わせて手を入れたり、改善したりしてきました。

一度土台が整えば、チームで開発を進めやすくなります。共通のやり方があることで、個々の機能に集中しやすくなるからです。

この蓄積は、長く使ってきた技術の強みだと感じています。同時に、ほかの技術と比べるときには、私が持っている経験の差も意識する必要がありそうです。

便利な一方、理解できているのだろうか

使い続けるうちに、便利さとは別の問いも出てきました。

DI、アノテーション、自動設定。開発を助けてくれる仕組みですが、内部の動きを十分に理解しないままでも、使えてしまうところがあります。

私自身、動いていることと、仕組みを説明できることを、分けて考えたいと思うようになりました。

また、以前のプロジェクトで使った設計が、次のプロジェクトにも合っているとは限りません。基盤を再利用できるのは便利ですが、今回の要件にも必要なのかは、改めて考える余地があります。

慣れていると、選ぶ理由を説明する前に手が動きます。その手際のよさを生かしつつ、ときには立ち止まってみたいのです。

10年使い続けたからこそ見えてきた課題

もう一つ気になっているのが、使い続けるための負担です。

アップグレードでは、互換性を調べ、必要な修正を入れ、回帰テストを行います。Spring Securityの設定変更など、調査や対応に手間を感じることもありました。

機能を作る時間だけでなく、維持する時間も含めて技術を考えたい。長く使ってきたからこそ、そう思います。

ただし、これはSpring Bootだけに固有の問題とは限りません。ほかの技術でも、更新への対応や学び直しは必要になるでしょう。まだ比較していない段階で、隣の芝生の手入れまで楽だと決めるわけにはいきません。

始めやすさと、続けやすさ。その両方を確かめてみたいと思っています。

今、ゼロから作るなら何を選ぶか

実際の技術選定では、過去の資産やチームの習熟度を無視できません。私にとっても、Spring Bootの経験は大きな判断材料です。

では、その制約をいったん外して、小さなシステムを作るならどうでしょうか。

これから、次の技術で同じ仕様のAPIを段階的に実装し、比べてみる予定です。

• Spring Boot（Java）

• FastAPI（Python）

• NestJS（TypeScript）

• Quarkus（Java）

• Go（フレームワークはGinかEchoを検討中）

まずはGETとPOSTでJSONを扱うところから始め、DBのCRUD、入力検証、例外処理へ進む構想です。その先には、認証・認可やトランザクションなども考えています。

見てみたいのは、処理の速さだけではありません。最初に動くまでの手間、コードの読みやすさ、学習や保守の負担も気になります。何をどう測るかは、実装を始める前に整理します。

比較の結果、やはりSpring Bootを選ぶかもしれません。用途によって、別の技術を選びたくなるかもしれません。今のところ、答えは決まっていません。

長く使ってきた相棒のよさも、外へ出てみると違って見える気がします。

次回は、比較する技術と、同じ条件で何を確かめるかを整理する予定です。まずは、小さなAPIを作るところへ向けて準備を進めます。