密です！ - うめぞーコラム

コロナウィルスが猛威を奮ってますが、皆様お元気でしょうか。私も家に籠もっておりますが、歩かなくなったせいか、体全体が大きくなる病気になっているかもしれません。病気だとしたら、栄養のあるものを食べてよく寝ないといけませんね！（笑）

東京都の小池知事が、記者会見場に来た報道陣に対して「密です！」と言いながら散らしていく映像。インパクトありましたよね。さらに「密ですゲーム」なるゲームが登場したり、「密ですゲーム3D」とか、小池知事（らしき人）が空を飛んだりしてます！（笑）私も自宅勤務な身。息抜きに「密ですゲーム」をやっております。楽しい！こんなクソゲームを開発していただきありがとうございます！

今までのアプリケーションは「密」

アプリケーション（特に業務アプリケーション）は、画面や帳票などのUI、データ、ロジック、プロセスで構成されています。今までの業務アプリケーションの作り方としては、こんな形が多かったのではないでしょうか。

データベースは昔からのデータを引き継ぐ必要があるので、テーブル構成などの見直しはあまり行わない
業務の流れを画面で表現するため、画面フローから設計を行う
画面から呼び出される「機能」を洗い出して実装
何度も呼び出される機能は共通化
データの書き換えなどは結局DBにあるデータを書き換えるだけなので、ロジックをSQLの中に書く
難しいロジックや繰り返しの多いロジックはアプリ内で実装
簡易(?)なチェックは画面側のscriptに書く。
案件進捗などのステータスの管理はデータの状態を見て判断

最初はこれらを疎にして作っていたと思うのですが、

「今すぐ変えて欲しい」
「コストをかけないで欲しい」
「どのロジックがいつ使われているかわからないので、ロジックが消せない」
「案件のステータス判断が商材や担当が変わるたびに画面も変更する」

などを繰り返すことで、どんどんぐちゃぐちゃに、そして「密」になっているのではないかと思います。それが、「モノリシック」「サイロ」と言われるような構造になり、「ハウルの動く城」だの「サグラダファミリア」だの「樹海」だの言われるようになるわけです。

特に、データとロジック、画面とプロセスの組み合わせは、「アッパレ」ともいうべきな密っぷりで、海外ならスパゲッティと表現していますが、日本人の私としては伸び切った素麺と表現したくなるくらいです。水をかけても何してもほどけない。これが業務要件の変更に対するアプリケーションのアジリティの重しになっているのです。

あるべき姿

業務アプリケーションの持つべきアーキテクチャは、画面、ロジック、データ、タスク管理（プロセス）を疎結合にすることです。それぞれの役割を明確化します。

画面：データの入力と出力
タスク管理：案件進捗のステータス管理
ロジック：チェック・計算・集計・イベント検知・推論
データ：データの入力と出力

こうした上で、それぞれ下記のように定義します。

画面・帳票：UIサービス
タスク管理：プロセスサービス
ロジック：ディシジョンサービス
データ：データサービス
サービス連携：アプリケーション

このように整理すると、各サービスを連携するものがアプリケーションとなります。サービス間連携は、インテグレーションサービスとして定義すると、アプリケーションはほぼインテグレーションサービスとして定義することも可能です。皆さん、覚えていますか？今から20年前の紀元後2000年頃に流行った「SOA (Service Oriented Architecture) という言葉を。ここで述べているのは、まさにそれなのです。

やっちゃいけないこと

「なんだ、うめぞーは言っているのは単に言葉を言い換えただけじゃにゃいか！」とお思いの皆様もいらっしゃるかもしれません。歴史は繰り返します（キリッ）。開き直りかよ？　いいえ。歴史は繰り返しますが、前進しているのです。このアーキテクチャを取る上でやってはいけないお約束があります。

ディシジョンサービスからデータサービスを直接呼ぶこと

これは、心を鬼にしてやりません。なぜか？「密です」なアーキテクチャをそのまま持ってきたところで、何も生まれません。それしか出来ないのであれば、刷新など諦めて現状で動かすべきです。ロジックからデータを直接参照させないようにすることで、疎にします。

え？だってマスターデータを参照して値とか判定しているよ？

はい、存じております。でも、1明細を処理するのにマスターデータの全件必要ですか？1明細を処理するのに必要なデータだけを持ってきて処理すればいいですよね？例えば、新しいパソコンの見積書を作成する業務だとしましょう。パソコンは画面、キーボード、マウス、本体に別れます。画面はHDMIという規格のインターフェースさえあれば、ほとんどのモデルで本体とつないで表示することが出来ます。キーボードやマウスは、USBとかBluetoothの規格があれば、大概のものは接続可能です。

つまり、沢山の種類のあるモニター・キーボード・マウス・本体のデータを、全部一緒に扱う必要はなく、モニターの見積、キーボードの見積、マウスの見積、本体の見積はバラバラにできるはずです。どういうことかと言うと、判断・決定する前に「処理に関係するデータ」だけ、データサービスから絞り込んだデータを持ってきて、そこに閉じた世界で答えを出せばよいのです。

データサービスにクエリーを投げて関連するデータを抽出する→そのデータと明細データをディシジョンサービスに渡して、組み合わせのチェックや価格の算出を行う→合計をデータサービスにストアして→画面に表示する

という流れにすることで、それぞれの役割が明確化し、分散処理も可能になり「密」にはならないのです。

案件の作業と進捗状況を画面の遷移で表現すること

画面はあくまでも、人間が必要とするデータの入出力装置であり、タスクにひも付きます。業務の流れはタスクが羅列したプロセスで表現できます。つまり、最初に「業務の流れ」をタスクとプロセスで表現し、「人が責任を持って承認などの行為を行う」為に必要な画面を作り、その行動記録をプロセスサーバに記録しておくようにします。また、次のタスクを誰に渡すのかというのをプロセス側で定義しておくことで、担当者がいちいち指定することなくバトンを渡すことができます。

＃笑い話なのですが、あるお客様のところに訪問していた時、担当者が上長の承認を得るために、ご自身のノートパソコンを持ってきて、その画面で承認をもらっていました。これって、紙を画面に置き換えただけの仕組みで、IT化の意味は...

#別のお客様のところでは、承認すべき人を申請者が「自分で」追加する必要があり、20人ほど追加して申請したそうなのですが、関連部署の偉い方を入れ忘れてしまって、後から叱られた上に無視されるようになったとか...

そして、タスク管理の良いところは、「今日あなたがすべき仕事リスト」を出せることです。私もそうですが、タスク管理って意外と出来ませんよね。歳取ってくると忘れますよね？他人から催促されて仕事をすることは、ストレスの貯まる仕事であることに他なりません。それが画面にアクセスさえすればわかるのは、かなり「気が楽」になります！

最近のプロセス管理は、AdHocとかCase Managementという機能が付いており、定型的でシーケンシャルな動作だけでなく、条件が揃ったところからどんどん処理を進めることが可能です。それによりプロセス全体に掛かる時間を短くでき、顧客満足度の向上、残業の削減、キャッシュフローの向上、現状のビジネスプロセスの改善、新規事業へのチャレンジにつながっていきます。

この先

「ディシジョンサービスからデータサービスを直接呼ぶこと」「案件の進捗状況を画面のフローで表現すること」の2つの「密」を「疎」に変えるだけでも、かなりの効果が出てきます。さらに大きな効果に導くには、これらの「疎」になったサービスを連携するためのデータの流れ、トランザクション境界を定義し、サービス間連携をQueueやStreamingで連結させることです。サービスはAPIとして定義することで、APIアクセス権限管理とともに使用すれば、要らない機能の断捨離に一層役立ちます。

これらのサービス・マイクロサービスを全部コンテナで動かし、fail overや負荷の検知をアプリケーションからコンテナへ、ひとつ下のレイヤーに移管することでアプリケーションの仕組みはもっと簡素にでき、柔軟なScale Out /Scale Inや「止まらないサービス」が実現できます。最終的には、システム系としてのサービス稼働率の向上かつコストの削減かつビジネスアジリティの増強が手に入るわけで、やらない理由はないと思います！

技術のお話

今日のお話の中で、レッドハットでご用意している技術・製品は下記のとおりです。

ルールエンジン：Red Hat Decision Manager
プロセス管理：Red Hat Process Automation Manager
データ連携：Red Hat Integration (AMQ, Kafka, Data Virtualization)
In Memory DataBase：Red Hat Runtimes (DataGrid)
クラウド環境：Red Hat OpenShift Container Platform

みなさんも、小池知事よろしく「密です！」「密です！」と言いながら、アプリケーションのソーシャルディスタンス(!?)を作って、より良い世界にしませんか！