既存コードの解析ではなく、業務要件の把握からスタートする
ルール駆動開発とは、以下の特徴を持った開発手法である。
- ルール（ロジック）とデータアクセスを完全分割
- 業務目線でルールを整理し、そのまま実装
- 小さく作ってはテストをくり返す、イテレーション開発
読者のなかには、モノリシックなレガシーアプリケーションの改修プロジェクトに携わった経験のある方もいるかもしれない。例えばクライアント企業から「既存のアプリケーションと全く同じ機能を持ったアプリケーションを、他の言語で作り直してほしい」といった要望があったと仮定しよう。
そうしたケースにおいて、要件定義書や設計書などのドキュメント類が全てそろっているケースはまれだ。多くの場合は資料が不足しているか、内容に不備があり読んでも役に立たなかったりする。そうした場合、どのような方法でリプレースを行うべきなのだろうか。
「一番やってはいけないのは、既存のプログラムの解析から入ることです。現行のソースコードは多くの場合、継ぎ足しでのメンテナンスが行われており、『秘伝のタレ』のような状態になっています。
また、不要コードが残ったままになっていることも多いです。私が経験した某案件では、『既存コードのうち約60％が不要ロジックだった』ケースすらありました。コード解析からスタートしてしまうと、必要なプログラムとそうでないプログラムの判断がつきにくくなってしまいます」（松田氏）
では、ルール駆動開発においては、どのようなアプローチで既存アプリケーションの解読を進めていくのだろうか。その答えは「まず、業務内容を知っている人にヒアリングしに行く」ことだ。本来、アプリケーションのリプレースにおいてエンジニアが知りたい情報とは、プログラムの中身そのものではなく「どのような業務要件が必要なのか」である。
ヒアリングにおいて、注意すべき点がある。業務内容を知っている社員に1から10まで全てを聞くと時間がかかるうえ、全体像を把握しているメンバーはそうそういない。そのため、「あなたが携わっている業務の情報だけをまずは聞かせてください」とお願いし、基本的なルールから質問していくことが肝要である。
また、業務マニュアルや業務フロー図など、システム要件を把握するのに便利な資料を業務担当者が持っているケースもある。資料を発掘するという意味でも、社員へのヒアリングは非常に有効である。
可視化した業務要件は、DMN（Decision Model and Notation）を用いて図示していく。これは、業務的な意思決定を説明してモデル化するために、OMG（Object Management Group）が確立している規格である。DMNの内容をもとに、業務担当者と認識のすり合わせを行っていく。このプロセスを経ることで、開発の手戻りや設計・実装の誤りを最小化できるのだ。
業務内容の整理ができたら、次は一連の業務ルールをサービスとして切り出す。例えば、「請求金額を算出する」ために必要な一連の業務ルールがあるならば、その塊を1つのサービス単位として分離する、といった具合だ。切り出し後は、どのようなインプット・アウトプットが必要かというインターフェースを定義していく。
アプリケーションがスパゲティコード化しやすい理由の1つとして、「業務ルールとデータアクセスが混在している」という要素が挙げられる。例えば、「何かの条件分岐を判定するために、特定のマスタデータにアクセスする。その判定が正であれば、別のテーブルに格納されたデータを取得する」といった処理が積み重なれば、コードは一気に難読化していく。
ルール駆動開発では、そうしたロジックの複雑化を回避できる。業務ロジックを1つのサービスとしてまとめ、REST APIなどを経由して呼び出す形をとるためだ。サービスの適切な分離により「ルールのテストがしやすい」「改修時の影響分析範囲が狭まる」「データベース構成の変更影響を受けにくい」などの利点が生じる。
小さく作ってテストをくり返しながらルールを育てていく
ルール駆動開発を実現するうえでは、レッドハット社が提供する「Red Hat Decision Manager（旧 Red Hat JBoss BRMS）」の導入をおすすめする。この製品は拡張性の高いルールエンジンを使用しており、開発の推進を手助けしてくれる。
「Red Hat Decision Manager」は、業務担当者にも理解可能なフォーマットを用いた、直感的なルール実装が可能である。DMNを作成ためのエディタが搭載されているうえに、ルールをすぐにRESTサービスとして実行できるサーバー機能も提供している。
ルールエンジンを活用して業務ルールを記載することで、仕様が明確になる。非エンジニアにも理解できる形式であるため、業務担当者がルールの誤りにすぐ気付ける利点もある。また、ルールのメンテナンスも容易だ。
「ルールエンジンを使うことで、小さく作ってテストをくり返しながらルールを育てていけます。ソースコードの解析からはじめると、全ての内容を読み解きながら、不要なところを捨てていくことになります。多くの無駄が生じるのです。必要なルールだけを拾う方法でシステムを育てることで、開発工数の最適化を図ることができます」（松田氏）
また、ルール駆動開発を用いてサービスを適切な粒度で分割することで、モノリシックだったアプリケーションはマイクロサービス化していく。画面やロジック、プロセス、データアクセスといった役割ごとにサービスを分割することで、以下のような利点が生じるという。
- スパゲティコードの解消
- メンテナンス性の向上
- ウォーターフォールからくり返し開発方式へ
- 開発生産性の向上
- 分散環境に対応
「本セッションで解説したように、ルール駆動開発を導入することで開発効率やソフトウェアの品質を向上させることができます。ぜひ、みなさまの開発に役立てていただければ幸いです」（松田氏）
巨大なシステムに立ち向かう際、私たちは得てして「自分自身がすでに知っている開発手法を用いて頑張ろう」といった思考回路に陥ってしまう。だが、レガシーアプリケーションの改修において、その開発手法が有効でないケースはままある。
あたかも、大木を切り倒すために、手持ちの小さなカッターナイフを用いるようなものだ。大きな仕事に取り組む際には、適切な道具を選ぶことが鉄則である。松田氏のセッションは、その原則の重要性と、ルール駆動開発の有効性が十分に伝わるものとなった。
お問い合わせ
レッドハット株式会社
