Spring Boot + Angularによる少人数・短納期開発の事例紹介

はじめに

本ドキュメントは、Spring Boot + Angularによって実証実験を目的とした少人数・短納期の開発案件を推進した際の事例紹介です。主な内容として、上記フレームワークを用いた開発手法およびアーキテクチャと、短納期を成功させるにあたって採用した開発手法について紹介します。

想定読者

• Spring Boot + Angularの開発手法に興味のある方
• 少人数・短納期開発の事例に興味のある方
• 自動生成ツールを用いた開発手法に興味のある方

TL;DR

• PoCを目的としたMVP開発
• 開発着手からPoC開始まで1カ月の少人数・短納期開発
• 中・大規模開発で実績のある、Spring Boot + Angularを用いた開発手法を採用
• 自動生成ツールを用いて安定品質・短納期開発を実現

背景

昨今、新規サービスのPoC（Proof of Concept）を目的としたMVP(Minimum Viable Product)開発に取り組まれている開発現場も多いと思われます。 まさにこの事例も、弊社内で新規サービスのPoC向けにMVPを開発した現場における事例です。 MVP開発では一般的に、素早く市場へローンチするため短納期開発が必要となります。

今回、事例の元となったプロジェクトの特徴は次の通りです。

• 開発着手からPoC開始まで1カ月
• 開発チームは3名構成
• 開発着手時点の設計レベルは、受託開発における外部設計レベル
• アプリケーション仕様や画面デザインの変更は、開発と並行して実施
• 画面数は7画面で複雑系画面を含む。もっとも複雑な画面では、入力／計算項目が、30項目 × 13 ＋ 7項目 × n

頂いた画面デザインには、検討途中の箇所も目立ちました。 システム背景を踏まえた上で、効率よく開発を進める必要がありました。

開発手法の選定

開発にあたり、まずは開発手法の選定から始まりました。 一番の課題は納期遅延のリスクが高いことです。 開発に伴う各種リスクが高い場面では、「経験・実績のある方法をとる」という判断セオリーが挙げられます。 そこで今回は、過去の開発で実績のある、Spring Boot + Angularを用いた開発手法を採用しました。 セオリーどおりの判断でしたが、この開発手法は中・大規模開発を見据えたものであったため、「短納期かつ少人数開発にマッチするのか」という懸念点がありました。

システム構成

システム構成は次の通りです。

アプリケーションはAWS Fargateを用いたコンテナ配置。 PoC実施目的のため、スケールや耐障害性は考慮しないシンプルな構成です。 SPA（シングルページアプリケーション）の静的コンテンツについても、Spring Bootの静的リソース^※1として配信するシンプルな方式としました。

※1: クラスパス上の/staticに配置。

開発コストをかけない為にも、サポートブラウザはChromeのみでした。

アプリケーションアーキテクチャ

アプリケーションアーキテクチャにおいても、過去に実績のあるレイヤー化アーキテクチャを採用しました。

テーブルモデル層はこのアーキテクチャ独自のもので、一般的に知られるレイヤーではありません。 テーブルモデル層にあるエンティティモデル、ビューモデルを、纏めてテーブルモデルと呼んでいます。 テーブルモデルは、データベースのテーブルやビューと1：1で対応するモデルです。 サービス層のサービスモデルは、サービスに必要なモデルを現したものであり、ビューモデルに近い存在です。 主なドメインロジックは、サービスにトランザクションスクリプトとして記述します。 サービスモデルやテーブルモデルには、そのクラス内に閉じたドメインロジックを記述します。

これまでの説明の通り、ドメインモデルには固執していません。 ドメインモデルについては、エリック・エバンスの「ドメイン駆動設計」が有名ですが、 マーチンファウラーの「エンタープライズアプリケーションアーキテクチャパターン」にもその紹介があります。 そこでは、ドメインロジックの構築手法として３つの主要パターンが紹介されています。 それぞれの特徴を次に示します。

• トランザクションスクリプト
  • シンプルな手続き型モデル。大半の開発者にとって理解が容易
  • サービス毎に手続きを構築するため、ドメインロジックが重複しやすい
  • システム規模の拡大やドメインロジックの複雑度が上がるつれて、機能追加のコストが飛躍的に大きくなりやすい
• ドメインモデル
  • 複雑なドメインロジックに体系的な方法で対処できる。ドメインロジックが複雑になっても機能追加のコストが抑えられる
  • 有効なドメインモデルの構築には、ドメイン知識に応じたリファクタリングが必要
  • 単純なシステムや規模の小さなシステムへの適用は、オーバースペックになりやすい
  • ドメインモデルがリッチになると、データベースとのマッピングが複雑になる
• テーブルモジュール
  • データベースのテーブル毎にモデルを用意し、そこにドメインロジックを記述する
  • トランザクションスクリプトとドメインモデルの中間に位置する
  • ドメインモデルよりも直感的に分かりやすいが、ドメインモデルに比べ多くの技法が使用できない

テーブルモデルはテーブルと1：1の構成であることから、ドメインモデルというよりはテーブルモジュールの思想に近いです。 上記パターンにはありませんが、「ActiveRecordからテーブル操作を抜き出して、Repositoryクラスに移譲したもの」 がテーブルモデルの説明として一番近いと考えています。

ドメインモデルの構築には、ドメインに対する知識が必要です。 開発が進むにつれて深まるドメインへの理解度に応じ、適切にリファクタリングを実施することで、より洗練されたドメインモデルを得ることが出来ます。 値オブジェクトやドメインサービスなど、ドメイン層を用意するための初期コストは大きくなりがちです。 しかし、システム規模や難易度が増加した場合、そのシステムの複雑度を一定に抑えて初期投資を上回る効果が期待できます。

これらの特徴から、次のような状況でのドメインモデル採用は、その特徴に応じたリスクが存在すると考えています。

• システム変更権限が開発チームにないプロジェクト
• 不特定多数の開発者が参画する中規模以上の開発
• （今回のような）短納期開発

例えば、今回の開発で「ドメインモデル」を採用した場合、次の考慮や作業が考えられます。

• 値オブジェクトとして金額クラスが必要。金額はバックエンドとフロントエンドの両方で扱う。JavaとTypeScriptの両方でクラス定義すべきか
• 値オブジェクトとデータベース項目のマッピングのため、O/Rマッパーの定義が必要
• 繰越金のような複雑な仕様を、どのようにドメインロジックで表現すべきか
• SPAのため、バックエンドとフロントエンドにドメインロジックが散らばりやすい。どのような対応方針をとるか
• 自動生成ツールの出力するソースコードがドメインモデルの表現力を疎外する場合、どのような対応方針をとるか

これら考慮は、将来の拡張性を踏まえる上では大切ですが、「素早く動くものを作る」ことを重視するシステム背景とは相反します。

今回の開発においては、初期コストが少なく、より素早く開発できる手法の選定が重要となります。 実績を重視して採用したアーキテクチャ構成でしたが、このような観点においても、「ドメインモデルに固執しない」判断は有効であると考えました。

開発手法

開発手法についても、過去に実績のある手法を採用しました。 この開発手法の特徴は、テーブル設計から駆動していくスタイルです。 次の図に示すとおり、システムはユーザインタフェースに近づくほど変更が多く、データモデルに近づくほど少ない特性があります。 一方で、変更に対する影響は、データモデルに近づくほど大きくなります。

最初にしっかりとテーブル設計することが、後々の手戻りによる遅延を防ぐことに繋がります。 そのような理由から、テーブル設計を重視したスタイルを採用しております。

開発の流れを表わしたものが次の図です。

次の流れで（主にバックエンドの）開発を進めます。

1. A5:SQL Mk-2というツールを用いて、ER図を設計
2. A5:SQL Mk-2からDDLを出力。そのDDLを入力とし、DBマイグレーションツールであるFlywayを用いて、データベース構築
3. MyBatis GeneratorというOSSツールを用いて、データアクセス層のJavaソースコードを自動生成
4. SpringFoxを用いてAPIドキュメント(JSON形式）を出力。それを用いて、OpenAPI GeneratorでクライアントのAPIソースコード（TypeScript）を自動生成

自動生成ツールを活用し、変更に伴う機械的な作業を抑えやすいというのも、この開発手法の特徴です。 前述にあるとおり、この開発手法はもともと中・大規模開発を見据えたものでした。 中・大規模開発においては、開発に関わるエンジニアの数が非常に多く、変更に伴うコストを如何に抑えるかという課題があります。その為、本手法では自動生成ツールを積極的に活用しています。

今回の開発においても、作りながら設計変更を取り込んでいくため、変更を前提として開発を進めていく必要がありました。 そのような観点でも、本手法は有効であると考えました。

プロジェクトの結果

開発開始から1カ月、一部機能を4日遅れとする調整のみで間に合わすことが出来ました。 開発当初に予想したとおり、開発途中にも機能やデザインの変更・追加要望がありました。 これらについては、スピード重視の方針を採ったことにより、そのほとんどを要望どおり実装出来ました。 現在、PoCの最中ですが、執筆時点で大きな問題は発生していません。

まとめ

「短納期かつ少人数開発に合う手法か」という懸念を抱えてのスタートでしたが、効率よく開発を進めることができました。 今回紹介した手法は、中規模案件および少人数・短納期開発で実績のある、有用な開発手法のひとつとして捉えています。 また、Spring BootやAngularそのものの品質が高いことも、大きな成功要因の1つでしょう。

過去の開発経験が非常に活きたプロジェクトでした。 一方で、今回挙げなかったMVP開発の特徴として、新技術への対応があります。 今回の開発範囲には含まれなかったですが、対象システムの背景により、MVP開発では新技術の取り込みも盛んです。 今回の開発経験を今後も活かしつつ、これからの技術動向を見据えた準備も進めていこうと考えております。

素早く市場へローンチするために、今回のような少人数・短納期開発は今後も益々増えていくと推測します。 同様のシステム開発に関わるチームにおいて、本事例が参考になれば幸いです。

本コンテンツはクリエイティブコモンズ(Creative Commons) 4.0 の「表示—継承」に準拠しています。