ルール駆動開発の目的と効果
ルール駆動開発とは
聞き慣れない言葉かもしれません。
業務は時代の背景と共に変わりゆく物です。アプリケーションを作って業務の軽減をしていたはずが、周りの情勢の変化に伴いマッチしなくなっているケースはどのお客様でも見受けられます。そこでIT部門で作り直そうと見積もりをとると、そこには莫大な費用が記載されています。
そうすると、IT部門は費用を安くするために今あるものを再利用しようとします。
現行システムのアーキテクチャやソースコードを再利用すると何が出来上がるかと言うと、極論ですが、今までのアプリケーションと何ら変わらないものが出来上がるのです。なんのために費用を掛けて更新したのか、言い訳を探す旅が始まります。
これが現実ではないでしょうか。
企業向けアプリケーションは、画面、データ、ロジック、プロセスという4要素で80%を占めます。上記のような膨大な費用は、画面、データやロジック部分がかなり多くの割合を占めます。私の経験上、最もバグが多い部分はロジックになります。このロジック部分をいかに品質良く工数少なく作るかが、アプリケーションモダナイゼーションの成功の肝なのです。
そこで、ロジックの効率的な作り方はないものかと様々な経験を元に作ったものが、ルール駆動開発という開発手法です。当初はロジックの部分に特化していましたが、改めて考えるとアプリケーション全体にも適用できる開発手法です。
ルール駆動開発の目的
主に既存のシステムをマイグレーションすることを念頭とすると、このルール駆動開発の効果はご理解いただけるのではないかと思いますが、マイグレーションでないと使えないのかと言うとそうでもなく、新規プロジェクトにおいても完全に有効です。
ルール駆動開発の目的は大きく3つあります。
無駄をなくす
高品質のものを作る
組織の垣根をなくす
無駄をなくす
多くの場合、既存システムはある程度の年月を経て稼働してきています。ある年では必要だったロジックやデータは、今では使われていない というのは、関わった全てのお客様で目にしてきています。つまり、かなりの量のロジックのゴミがありますが、そのメンテナンスはされておらず、ソースコードの中に残ったままです。その場合は、使っていないロジックは作る必要がないわけで、つまり、使われていないロジックを判別することが必要です。しかし、IT部門側でどのロジックが業務で使われているのか、使われていないのかを判断することはほぼ不可能なのです。
思いつくのは、どのロジックが実行されたかわかるようにlogを仕込み、1年間回してみることです。が、これでは予定が1年遅れ、かつ、実行されなかったロジックを考察すると、その年はたまたま動かなかったロジックなのか、何年も動かす必要のないロジックだったのかの判別ができず、結局全部移行しなければならなくなります。これでは費用が高止まりしてしまいます。
そこで登場するのが、ルール駆動開発です。幹となる業務アプリを作成し、複数年分の過去のデータをテストとして流してみて、テストがNGであったデータを業務側と相談・類推し、人力でロジックを充足していく方法です。流すデータ量に依存するわけですが、正答率が100％となることをゴールとすることで、少なくとも数年前までに実際に使われていたロジックのみを作成することが可能です。
結果として、工数を抑えることが出来ています。
高品質なものを作る
ここで言う品質とは、今までのWaterfallでありがちな、要件定義・設計・実装といった各フェーズでの品質を完璧にするという意味ではありません。Waterfallでのテストフェーズでようやく発見されるような機能的・非機能的な重大な設計ミスなどを、もっと早い段階で発見し問題を大きくさせないという意味です。
そのためには、繰り返し型の開発手法が適しています。作成する目標を立て、実装し、テストを行い、結果を評価します。評価した考察より次の目標を立てて行きます。
この繰り返しの中では、機能テストだけではなく性能試験も同時に行います。テストの時点までの性能を測っていくことで、前回よりも極端に性能が悪くなる結果が出た場合、その時点で原因と対策を考えることで、問題を複雑化することが防げるわけです。
いわゆるscrum開発とは違うのは、出来たところで本番環境にデプロイするわけではなく、一つの業務が完全に移行できるレベルまではデプロイせずに繰り返し設計・開発・評価することです。品質が良くなった結果として、大きな手戻りなどの工数が削減されます。
組織の垣根をなくす
ルール駆動開発は、完成品を樹木に例えるなら、幹を作り、次第に枝葉を付けていくような開発手法であり、繰り返し型開発となります。繰り返すサイクルの中で、それぞれ設計・開発・テスト・評価を繰り返していきます。その際に業務部門の方々、IT部門の方々に意見を聞いたり調整したりすることが必要になります。
現状を見ていると、IT部門の方々で業務部門の方々へのヒアリング等ができず、想像でプログラミングされていたりします。これは業務部門がトップで、その下にIT部門、更にその下にシステムインテグレータという、上下関係があるピラミッド構造になっていて、上下間の力関係が存在するからです。各部門間で隙間があると認識の齟齬を生み、上下関係があると下の者が上の者に意見を言うのを躊躇したり、ミスを拭うのは下の者という関係性が出来上がってしまいます。これこそが、開発の現場にて生産性を大きく下げる理由の一つだと思います。
ルール駆動開発をすると、仕様書は参考にするもののソースコードは極力見ない方針になりますので、必然と業務部門と密に連携を取らざるを得なくなります。最初は業務部門側に負担を掛けるかもしれませんが、「最終的に欲しい物」なにか、実際にモノを作りながら進めていくことで、現行システムの制約がある故に仕方なくやっていた「作業」が、実は要らなかったという無駄がわかったりします。となると、それだけで業務部門としても価値のあるものになっていきますし、それがきっかけで組織の垣根も無くなり、会社として良い方向に回りだします。
ルール駆動開発の効果
これらを実行した結果として、ルール駆動開発の効果としては下記が挙げられます。
品質の向上や作成するモノの削減による工数の削減
本当に欲しい物が作られる
業務ロジックの立て付けを整理でき、業務の管轄を超えるメンテナンス依頼が少なくなる
既存のロジックではやってはいけない業務の不正があったことがわかる
自動的に(マイクロ)サービスアーキテクチャとなり、負荷への容易な対応、リリースの時短が実現する
不要になった時の整理が容易となり、常に最適な状態となる
事業部門とIT部門が仲良くなり、会社としての風通しも良くなる
新しい事業アイデア、より効率的なシステムの運用などの発案がしやすくなる
また、ルール駆動開発にルールエンジンを適用されている企業では、新規サービスの構築、キャンペーンの適用などが10年以上に渡って高速対応が常態化できており、事業への貢献度は計り知れないほどになっています。上記のような効果の全てが実現できており、いわゆるデジタルトランスフォーメーションと称した、デジタル技術を用いて業態を変えてしまった事例も経験してきてきました。
ルール駆動開発から生まれる効果は、今までの想像を超えるものがあります。是非ともご検討ください！
リンク
ルール駆動開発をよりわかりやすくお伝えするために、漫画を作成しました。ぜひご覧ください。（下記画像をクリックするとレッドハット社のダウンロードサイトに飛びます。必要項目を入力いただくとダウンロードできます。
この記事が気に入ったらサポートをしてみませんか？