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