密です！
コロナウィルスが猛威を奮ってますが、皆様お元気でしょうか。私も家に籠もっておりますが、歩かなくなったせいか、体全体が大きくなる病気になっているかもしれません。病気だとしたら、栄養のあるものを食べてよく寝ないといけませんね！（笑）
東京都の小池知事が、記者会見場に来た報道陣に対して「密です！」と言いながら散らしていく映像。インパクトありましたよね。さらに「密ですゲーム」なるゲームが登場したり、「密ですゲーム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
みなさんも、小池知事よろしく「密です！」「密です！」と言いながら、アプリケーションのソーシャルディスタンス(!?)を作って、より良い世界にしませんか！
コレジャナイ感 撲滅運動！
納入された業務アプリケーション。作ってくれたIT部門、SIerの皆さんには感謝しつつも、「コレジャナイ感」が否めない... 何でだと思います？ というご相談をいただくケースがあります。
大概の場合、思いつく要因として
- 要件定義が甘かった
- ユースケースをもっと提示すべきだった
- 我社の業務をよく知っている業者に出すべきだった
等が出てきます。業務側の視点に立つと、わからなくはないのですが、これ、全部間違ってます。この視点で考えていたらいつまで経っても同じ感覚に陥ります。視点を大きく変える必要があります。
要件定義をもっと柔軟に
まず、プロジェクトがWarterfallであること自体を考え直したほうが良いです。要件定義を「最初に」完璧に出せるところってあるんでしょうか？そんなスーパーレディ・スーパーマンがいたら、地球上から炎上プロジェクトなんて存在するはずがありません。人間、過去にやってきた内容の全て事細かに覚えている人はいません。全てをドキュメント化されている事業者も見たことがありません。それが「今回だけのちょっとした変更」であれば、なおさらのことです。事業をやっていれば、「明日、明後日、毎日新しい要件が生まれる」可能性だってあります。
つまり、最初に要件定義を行うというプロセス自体を変えればよいのです。
ある日を境に業務の根幹が全く変わることはないはずです。例えば、昨日まで医療用マスクの販売業務をしていたけど、今日から製鉄業になります！とか、ありえないですよね。ということは、業務の根幹となる部分は、その会社の事業部に属する人なら誰もが知っている業務のはずです。いかなる例外も一切切り捨て、まずそこだけに集中して業務要件を整理します。
この業務の整理は業務部門の方々と一緒に行います。よくSIerだけでやっているのを見ますが、「絶対にSIerだけでやるべきではない」です。いや、そんなこと言ったって今まで付き合ってきた業務部門の人たちは、忙しいからとかシステム部門の人のほうが知っているから、とかの理由で参加してくれないんですよ、聞けないんですよ... という話をよく耳にします。もしそれが本当であると仮定すると、心を鬼にして申し上げますが、それは「あなた方が業務部門から信頼されていない」んですよ！気づいてください！私はそうじゃなく、SIerが「お客様に対して聞く行為をしていないだけ」だと思っています。
我々はある特定のお客様の業務をずーっとやってきたということは1例も無いのですが、この作業を行う時に「不明点があったら聞きますから！覚悟しておいてね！」と言うと、100%、業務部門の方は苦笑いしつつも付き合って教えてくれます。恐縮なことに、事業の勉強会まで開いていただいています。業務部門の方はちゃんと教えてくれます！プロジェクトが始まる前までにいかに業務部門の方々と仲良くなり、技術観点などで信頼関係を築いておくかは担当営業や担当プリセールスの責務ですから！上下関係ではありません。関係性は一緒に仕事をする「パートナー」です。
設計
次に行うことは、枝葉の業務要件整理... ではなく、その業務要件を満たすための要素技術とのマッピングです。
- データの入出力→Web画面とする判定部分はできるだけ自動化
- 法令改正に対して5日以内で対応できる仕組みとする→データ・ルール・プロセス・画面の疎結合化
- 最大1,000人の同時アクセスがあるが、昼間の同時アクセス数はせいぜい10人→コンテナ化でAuto Scale Out/In
... などです。
さらに、各要素技術をどのように実現するのかのマッピングをします。
- WebであればHTML5をベースにJSPサーブレットとシングルサインオン
- 判定部分はルールエンジン
- データのリアルタイム処理にはStream Queueとマイクロサービスによる連携
- コンテナ化によるコンテナの管理はKubernetes
... などです。そして、その実現方法をどのメソッドで行うかを決定します。オープンソースを主軸に考えるのであれば、WebやJDKはRed Hat Runtimes, ルールエンジンはRed Hat Decision Manager、コンテナはRed Hat OpenShift Container Platform等です。ここまでくると、要件定義から設計段階に踏み込んでおり、概略設計が出来上がっている状態になります。大筋の見極めをつけておきます。
そして、次にすべきことはこの概略設計の確からしさの検証です。設計が正しくないと最後のテストの段階で地獄を見ます。なので、幹となる業務部分で、典型的なパターンのデータで一気通貫に業務が行えるプロトタイプを作成します。今までこの部分は机上の検討だけで済ませてきているのが多いと思いますが、実物を作って検証することを強くお勧めします。画面は超絶簡素なもの、ロジックは数パターンのみの実装、データもCSV形式で読み込み・書き込み程度のものでよいです。しかし、とりあえず動けばいいだけのものを作るのではなく、ITのプロフェッショナルとして将来のシステムはこうあるべきだ的な考えは存分に入れるべきです。その上で、機能的に満たせるものが想定したメソッドなどで「カスタマイズすること無く」作れて見通し良くできるかどうかを検証します。
大量のデータを流してみて、簡易的なパフォーマンスも計測しておきます。作ったものに対して振返りを行います。この時に重要なのは、業務に関わる人も一緒に検証に参加することです。「コレジャナイ感」があるかどうか、このプロトタイプの時点で忌憚のない声を聴かせてもらいます。
その検証の場で、ここはもうちょっとこうすべきだったとか、これは要らないんじゃないか？等が、必ず出てきます。私の経験上、ここでの会話で「この業務って要らないよね？」「これができるなら、A課でやってたチェックはシステム化して業務負荷を減らせるよね？」「もしかしてアプリケーションでこんな事できたりする？」等という、「業務の整理(改革)」が始まります。ほぼすべてのお客様で。ホント、面白いように！
業務部門の方も、何ができるかわからない中でひたすら要件の書き出しをやっても、不安だしそこで責任を取らされても...と感じているわけですよ。これが、ITのプロが考えた動くプロトタイプを目の前にすると、業務部門の方々の脳はドーパミンが溢れて、建設的な考えと喜びに満ち溢れるわけです。僕らITで仕事をしている人間は喜び組なのですよ！（非科学的ですが、そういうのは絶対あると思います）
皆さんもお気付きの通り、「業務部門がシステムを縛っていた」のではなく、実は「システムが業務を縛っていた」のです。新しいアプローチ・機能などを紹介することで、業務の無駄・不合理が見つけられ、プロジェクトがもっとシンプルな方向に動き始めます。
イテレーション開発
不要な機能などが削ぎ落とされ、本当に欲しかった機能が追加された状態で、もう一度、入れるべき要件を検討します。そして、それを設計し、先に作ったプロトタイプを拡張する形で作り、また検証を行います。あとはこれをお客様が用意した入力データと期待値を使って、100%マッチするまで作るだけです。毎回、検証時には業務部門の方に参加いただき、意見を聞いていくことで、業務部門の方々の「コレジャナイ感の撲滅」に持っていく事が可能です。
一つ重要なこと。このイテレーションの中で業務部門の「わがまま」を全て聞くのは間違いです。業務部門の方はITの限界や苦労をわからずに要望を出してきます。それを聞き入れるのに、基本方針とした立てたアーキテクチャを変える必要があるのであれば、それは残念ながら受け入れるべきではありません。現実、結構あるんです。その機能いる？的な。
一番多い例としては、「部長承認の後、事業部長が却下したら、関係するコミットしたデータを全部元に戻して部長に差戻しして。」みたいな流れ。部長の承認があったために一度コミットしてしまったデータ（例えば発注指示）を、他のシステムが参照して物事が進んでしまってしまったかもしれない状態（サプライヤーへの注文書の発行）に戻すなんて、担当してるシステムだけではできません。出来たとしてもめちゃめちゃ面倒で、そのケースだけならまだしも、課長の場合とか他部署での場合とか、他のケースまで全部洗い出すなんて不可能です。
この場合は、承認・却下した人が責任を持って仕事をしたのであり、却下された時点でその「案件」はボツなわけです。もし再検討が必要というのであれば、ちょこっと直す程度のものではなく、きちんと考えてもう一度新たにプロセス（稟議）を起こすべきです。え？そんなこと面倒？ いえいえ、その面倒さを回避したいなら、ちゃんと考えてから稟議起こしなさいということです。
ITのプロフェッショナルは、そのようなわがままご要望に対してはシステムでやることの限界をお伝えし、代替策を考えるか、そのご要望を実現するための費用や工数などをきちんと提示します。技術的に製品の基本機能で実現でき、かつ、本当にどうしても必要な場合は、次のイテレーションでやるべき内容かどうかをプロジェクトマネージャがハンドリングします。
最終的に、「コレジャナイ感」ではなく「コレなのよ！感」が出てくることで、お客様の満足度も向上し、開発する側も無駄な心労もなくプロジェクトは成功します。そのための鍵としてあるのが、ルール・プロセス・データ・画面の疎結合アーキテクチャであり、マイクロサービス化であり、CI/CDであり、コンテナ環境であり、ルール駆動開発であり、イテレーション開発なのです。
まとめとして書いておきますが、
- Waterfall開発はせず、イテレーション開発とする
- 幹となるプロトタイプを作成して検証、次の目標を策定する
- お客様の業務部門を巻き込んで一緒に検証し考える（お客様は自分たちの業務改善につながるので積極的に参加する）
- 要望を出すのは事業部門、ITの専門家の視点で実現の可能性を考えるのはシステム部門(もしくはSIer)の役割
みなさんも一緒に、コレジャナイ感の撲滅運動にご参加ください！
清く正しいキャパシティプランニング
製品の導入を勧めている中で必ず聞かれるのが、「リソースはどのくらい必要ですか」。キャパシティプランニングなんて言ったりしますが、これ、エンタープライズアプリケーションの中ではかなり重要で、炎上も頻発しやすいテーマです。今日はそんなお話。
タイミングはいつなの？
いわゆるパッケージソフトウェアだと、必要なCPUのスペック、メモリのスペック、ディスクのスペックは大体書かれています。それは機能が固定されていて、変動するところはデータ部分のみになるので、xxGB以上のメモリ、YYGB以上の空き容量 等と、最低限の条件が書けます。ハードウェアを調達するには、使うパッケージに合わせるのが普通かと思います。
ところがです。エンタープライズアプリケーションという分野では、スクラッチで開発するので、どのような機能が付き、どのような画面があり、どのようなデータが来て、どれくらいの処理能力が必要なのか は、見積もりことが困難です。
「いやいや、あなたのところは他社でも経験してきているんでしょ？だいたい分かるでしょ？」
本当に良く聞かれます。でも、他社のデータとこの会社のデータは違うのです。処理させる内容も違うのです。参考値として出しても、コミットなんてできるわけがありません。
予算取りで必要、というのは理解しますが、99%、その値がコミット値として取り扱われてしまいます。その結果、設計もされていないアプリケーションの動作環境だけが先に決まり、CPU/Memory/Disk容量の制約が生まれてしまいます。アプリケーションの作る側としては、それが聖域になってしまい、処理能力を稼ぐためのチューニング、メモリ容量を節約するためのチューニングなどを徹夜で行い続けることになります。
パッケージソフトを動かす感覚でハードウェアを調達しているとしか思えません。キャパシティプランニングは、設計前に机上で行うものではないのです。
本来どうあるべき？
エンタープライズアプリケーションのキャパシティプランニングは、設計して、ある程度の規模のプロトタイプ（例外条件の無いような状態で、想定している簡単なデータが来れば業務として成り立つようなもの）を作成し、本番相当のデータを流した上で測定して決定すべきと考えています。
まず注目すべきは、1件あたりの処理時間 (Turn Around Time, TAT）。これが想定より大幅に掛かっているのであれば、プログラムの中のそれぞれの処理がどれだけ掛かっているか、ブレークダウンして確認します。処理時間が一番掛かっている部分から処理方式の見直しを行っていきます。
次に使用メモリ容量を確認します。10,000件くらい流してみて、どのくらいのメモリ使用量の増減があるかを確認します。Cの環境とかであれば、メモリリークしているかどうか、Javaの環境であれば、HeapとGCのタイミングを見てGCが頻発しないよう、Heapのメモリ容量の調整や、場合によっては一部は別のVMに処理を移す等の検討を行います。
さらにスループットを検討します。単体でのスループットを計測し、目標のスループットに達する為に多重度をいくつにすべきか を検討します。データの入り口が一つ（QueueとかWebServerとか）の場合、後続の処理を行うモジュールを2倍に増やしても、シングルスレッドで動作するところがボトルネックとなるため、1.7倍程度のパフォーマンスしか得られませんので注意が必要です。
いつ評価するの？
これらの「性能検証」は、設計段階でやっておくべきです。
「え？だってさっき、ハードウェアの見積は最初にする必要がないみたいなこと言ってたじゃない！」
違うんです。こういう時こそ、時間貸しのクラウド環境を上手く使って検証すればよいのです！そして、このような性能問題は本開発前に確認しておくことで、開発が進むに連れて、もし性能が未達となった場合でも、どこを多重化・チューニングすれば回避できるかの判断が容易になります。
これを、実装後のテスト段階でやってみてください。炎上と悲劇しか生まれません。設計から見直す必要があるものの、「今更何イッテンだ！とにかく直せ！納期は守れ！」みたいな奴隷への号令よろしく、「テストフェーズからが本開発！」なんていう自虐的な武勇伝が生まれ、炎上・徹夜を繰り返し、体も心もズタボロになってしまうのです。倒れて救急車に運ばれるならまだまし、倒れても救急車に乗れないなんていう最悪中の最悪な結果なんて誰も望んでいません。楽しく仕事が出来ないなら、今すぐ辞めるべきです！
設計段階において、ある程度の性能をクリアするための基礎情報が取れれば、そこで初めて環境のリソーススペックが決められます。そしてよほどのことがない限り、自前でハードウェアを調達する時代ではなくなっています。何のためのVirtual Machine、何のためのContainer でしょうか？区画を一度作ったら二度と変えない方針のVM設計なんて、仮想化の意味がないです。必要な時に必要な分だけリソースを利用できるメリットをもっと享受すべきです！
リソースの決定
パッケージソフトもスクラッチで開発するアプリケーションも、リソースの決定方法は同じです。アプリケーションがどれだけ使用するのかをプロトタイプなどを利用して目処をつけて、稼働環境や開発環境としてどれだけのリソースが必要なのかを計算し、それをクラウド上に作るべきです。
そのためには、取るべきアーキテクチャを策定し、使う製品の特性をその道のプロ（ベンダーのコンサルタント等）から学び、基礎固めを行わないといけません。ちなみに、ITに従事している皆さんはめちゃめちゃ頭の良い方が多いので、「こんなことにも使えるんじゃないか」と、色々やっていただくケースが多いのですが、「その目的に使われるような製品の機能なのか」どうか、今一度確認することをお勧めします。製品として想定していた以外の使い方をして上手く動かなかった場合、我々製品提供側もどうすることも出来ないケースが多々ありますので... 疑問点があれば、製品サポートにお尋ねいただくのが良いです。
話はちょっと逸れましたが、プロジェクトの予算承認という課題の時
にも触れましたが、全体を一気にプロジェクト化・予算化するのではなく、マイルストーン毎に区切って一つ一つ進めるのがよいのです。キャパシティプランニングを行うための、「そう大きくない予算」を是非置いておくことをお勧めします。
相談先
レッドハットではプロジェクト全般の進め方について、皆様のプロジェクトマネージャと同じ視点で支援する「テクニカルアドバイザー」的なコンサルティングも行っています。レッドハットのコンサルタントは、広く深く技術的な観点で。ITシステムとしてあるべき形を常に追求してお客様にご提供していますので、一度ご相談いただければと思います。
脱バッチ教
新興宗教の勧誘のお知らせです！（違
バッチ処理
メインフレーム等の大型コンピュータって、バッチ処理がたくさんありますよね。なんでバッチ処理なのか、みなさんはご存知でしょうか。
大型汎用コンピュータが出てきた当初、計算を行うためには予めプログラムを組んで使いたい時間を申請して、実行時間に応じた料金が掛かるものでした。今でいうクラウドで時間単位で課金されるのと同じ。私も小学生の頃、父親の会社にあった3270端末を叩いてみたことがあります。ええ、キーを叩くのは親父で、私は画面をぶっ叩いていましたが。（笑）
つまり、CPUの利用率に関わらず"利用時間"で料金が掛かるので、ダラダラと雑多な処理を長時間行うのではなく、データをまとめてドガッと行ってパッと終える必要があったわけです。更に言うと、昼間と夜間では料金が違ったと記憶しています。そうすると昼間は金融機関などの「リッチ」な会社が利用し、父親が居たような中小企業などの「節約」しなければならない会社は夜の時間に利用することになります。（父親の会社では港湾施設の基礎設計などをやっていて、潮力等の流体力学等のシミュレーションを行っていました。簡単なプログラムだと実行時間が0.5秒とか出てて、当時小学生だった私はその速さに興奮した覚えがあります！）
バッチ処理はそういう技術計算だけではなく、月次の料金計算、営業の売上集計、代理店手数料計算等にもよく使われています。大型汎用コンピュータでのこの「習慣」が、Intel Architecture(IA)の環境になっても同じように使われています。
バッチ処理の何が問題か
上で書いたとおり、バッチ処理は「いかに利用料金(コスト)を減らして処理させるか」に焦点が当たったものになっていました。自前でハードウェアを持たず、専用線の接続先で処理をしていた時代はそれで良かったのですが、ハードウェアのコストが安くなったことで、自前でサーバを立てた方が安くなりました。アセンブラやCOBOL/FortranからCやJavaに書き換えはしたものの、バッチプログラムを構造的にはそのまま持ってきて実行しても、IAサーバでは単体ではまかないきれません。そこでバッチ処理のピーク時に合わせた処理性能を確保するために、多くの高速なCPUを載せて、大型サーバを用意して実行しています。分散処理型ではないため、処理能力を増大させるにはスケールアップ（CPUを積み増すとか高速なCPUに載せ替える）方法になります。
ここに問題が２つあります。一つは夜間バッチ処理に合わせたリソースで、昼間がどうしても使用率が上がらない問題。もう一つはビジネスが好調で処理件数が増大してしまい、サーバの能力を超える処理が必要になり、夜間バッチが朝の始業時間までに終わらず、翌日の業務開始が遅れるという問題です。
バッチ処理の中身
ここでバッチ処理の中身をよく見てみましょう。私の経験を例にお伝えすると、営業成績を月次で夜間に集計をしするアプリケーションがありました（メインフレームで動いていました）。契約数の急な増加により夜間バッチ処理が終わらなくなっており、翌日の営業活動に支障が出かねないというご相談いただきました。中身の処理は、１ヶ月分の受注した伝票データを元に、商品毎・お客様毎・営業マン毎・営業部毎・事業部毎・地域毎・代理店毎等の単位で集計するという業務です。しかもかなり細かい条件（AさんはG店に居たのでG店の売上として扱うが、商品Y,ZはG店ではなくU事業部付、商品Xでかつ契約期間が1年以上のものは1年に丸めた上でK事業部に半分付ける等）があり、１ヶ月の伝票データは2,000万件程度にまで膨れ上がっていました。
皆さんならどうしますか？
解決策その１
バッチ処理と言っても全てを一気にメモリ上に読み込むことはまず不可能です。ではどうするかと言うと、1件読み込み、それを各集計単位に落として、終わったら次の1件を... という繰り返しを行います。
でもこれを逐次的（シーケンシャル）に行っていても、処理は全く進みません。処理している内容をよく見ると、異なる複数の伝票間に関係性を持った処理（例えば3つの伝票があって、A伝票のKという項目の値が100でB伝票のJという項目の値が80の場合、C伝票のGという項目を0にする というようなものを関係性と言っています）は無いのです。つまり1伝票毎に異なるサーバで処理を行ったとしても、なんら問題がないのです。
いろいろなお客様で聞くのが、「バッチ処理は複雑で触りたくない」というものですが、それは「バッチ処理の中身」に書いたとおり面倒くさい処理が山ほどあるだけで、データ間の関係性は無かったりします。としたら、処理の系の途中にQueueを置いて、その中にデータを入れて、Publish/Subscribeという機能を使い必要とするデータをアプリケーションが選択取得し、処理が終わったら処理済みのQueueに入れて次の処理をする というような流れにして、「処理」を多重化・多段化することで全体の処理時間を短縮することが可能です。サーバも「スケールアップ」ではなく、「スケールアウト」として、同じようなサーバを追加するだけで性能向上が見込める形になります。
最終的にはルールエンジンを使って伝票の仕分けと集計を行い、伝票1件ずつ、10台のサーバを使って多重化しました。1伝票の内容を集計する単位別に複製し、集計単位が同じキー（営業店コードとか）を持つものが2つ以上あればすぐに集計オブジェクトに合算し、計算が終了した複製した伝票を消去する、というような流れです。
解決策その２
更に良く見ると、1ヶ月分の集計を行うのに1ヶ月待ってから月次処理する必要性が無いことに気づきます。「月次処理」として本当に必要なのは各集計単位を「足し込む」事のみで、途中の集計結果は毎日、いえ、リアルタイムに処理していても良いんじゃないのか？ということです。つまり、バッチ処理を極小化してなるべくリアルタイムに処理してしまえということです。そうすると、「夜間バッチ」に合わせたリソースは、実は必要なく、負荷を平準化させることでもっと少ないリソースでその処理が可能になるのです。これはハードウェア費用の節約だけではなく、夜間バッチの運用立ち会い人員の削減（Abendした時の回復要員とかね）も可能、さらにデータがリアルタイムにわかることによる経営的なトレンドの把握によるダイナミックな作業指示、それによる商機逸失の回避ができることを意味します。
つまり、システムの系としてQueueやインメモリデータベース、処理のマイクロサービス化などを行い、バッチ処理をリアルタイム処理に極力変えることで、コストの削減とリスクの低減と売上の増大を一気に達成することが可能なのです。
別のお客様では、工場の生産計画を、メインフレームでは夜間の10分の稼働で3ヶ月分を作成できたものを、IAの分散環境にしたことで3分の稼働で8ヶ月分が作成できるようになりました。処理の効率化により、今までできなかった処理もできるようになったのと、作成する計画がより長期で見れることによる経営的な判断のしやすさもベネフィットとしてありました。
さらにもう一歩。この「処理」や「Queue (Stream処理できるKafkaとかだとさらに良い）」に相当するところをmicroservicesと定義し、コンテナで動かすことによって「サービスとして止めない」仕組みが出来上がり、業務の変更に対して柔軟に変更が可能な「最強システム」が出来上がります！
この活動を、私は「脱バッチ教」と社内で宣告し、勝手に教祖を名乗っております。（誰にも承認を得ていないので、「野良教祖」ですが...笑）皆さんも入信してみませんか？
技術のお話
今日のお話の中で、レッドハットでご用意している技術・製品は下記のとおりです。
ルールエンジン：Red Hat Decision Manager
データ連携：Red Hat Integration (AMQ, Kafka, Data Virtualization)
In Memory DataBase：Red Hat Runtimes (DataGrid)
クラウド環境：Red Hat OpenShift Container Platform
IT環境の自動化：Red Hat Ansible
働く環境
COVID-19の影響で、Work From Home (WFH, 日本企業はテレワーク等と言ってますね）を強制的にしなければならない状態になっています。IT業界以外の人から見ると、ITの人たちはパソコンさえあればどこででも仕事ができるんでしょ？と思われています。
幸いなことに、私のところではほぼリモートワークになっています。しかし、どうしても出社しなければならない人たちがいるのも現実です。
「書類」で回している業務
日本固有の「印鑑」ビジネスが悪しき形態だ！と声高に叫ばれています。業務はまだまだ、紙という媒体に依存しています。昭和の時代から申請・承認行為は紙に印鑑を押すものであります。紙とハンコの依存性を少なくする必要がありますね。できるだけ「電子化」「データ化」して、Web画面上でその作業が終わるようにすることが望まれます。その場合、要素技術として何が必要かというと、データの入出力としての「画面」（Webブラウザが一番良い）、データのチェックや計算などの「ルール」（ルールエンジン等）、進捗を管理する「プロセス」（タスク管理）、入力や計算をしたデータを格納しておく「データベース」です。
この、「画面」「ルール」「プロセス」「データ」を疎結合化するようなアーキテクチャを採用してサービスとして構築しておくことで、アプリケーションの構成としては、どのサービスをどんなタイミングで呼ぶかに集中することができます。
他社とも同じ業務をしているから、販売しているパッケージでも良いのではないか？という声も聞こえてきますが、お客様の業務は他社と全く同じでしょうか？全く同じなら、同じ業務を行っている会社同士がくっついた方が、投資もリスクも少なくリターンが望めるでしょう。是非M&Aをお勧めします。（笑）
ところが、現存する殆どの会社の場合、その会社の考え方に基づいて活動しているはずです。大体似ているけど、ちょっと違う部分が必ずあります。その部分がパッケージでできない場合、パッケージをカスタマイズする・パッケージは部分利用として他は人力で行うの二択になっていませんか。
パッケージをカスタマイズすることで、沼に落ちやすくなります。沼とは、カスタマイズを進めていくことで本来のパッケージの姿ではなくなる沼、カスタマイズした部分がスパゲッティになってしまって、それ以上のカスタマイズができなくなる沼、カスタマイズ部分によって製品の脆弱性を修復するためのパッチが充てられない沼 等はよく知られた沼です。あまり知られていない沼として、カスタマイズを提供会社にお願いすることで、自社のノウハウが知らない間に製品化されてしまい、他社との差別化ができなくなる沼、パッケージとカスタマイズの呪縛に囚われ、業務側が本来やりたいことができなくなる沼、コロナウィルス等の外的要因に起因する変化に耐えられない沼などがあります。
私的には、もしパッケージを使いたい場合は「素のまま」で使うことをお勧めします。自社特有の要件はパッケージの外部に作るか、パッケージをやめて変化に耐えられるようなスクラッチ開発をするかをお勧めします。強いて言うと、それらが全部自宅から何らかの手段でアクセス可能な「クラウド」上にあると最強です。自宅にいながら電話会議で要件を聞き出し、修正・テスト・リリースができるとなると、今後も自宅に籠もらなければならないような事態に陥っても業務は続けられる可能性が高いです。
クローズドな環境
世の中、晴れた空にプカプカ浮かぶ雲の中で仕事ができることばかりではありません。セキュリティという観点では、アリ一匹の侵入も許さぬ屈強なシェルターの中で外界と遮断した世界で仕事を行うのが良しとされています。
ですが、コロナウィルスのパンデミックのような状況では、クローズドな環境に振り切れていると不具合がたくさん出てきます。外出禁止令が出ているにも関わらず、探偵やスパイのごとく監視の目を盗んで、まさに「命を掛けて」仕事に出る必要があります。
「USBメモリとかMailとかで情報が盗まれて売られている。」
こんな不祥事が過去によくありました。
残念ながらモラルが欠如している人はいます。自分はそのつもりでなくとも、結果的に情報流出につながってしまった、そういうこともあるでしょう。私自身、USBメモリがある時代に、サーバに持ち込めるのはフロッピーディスク1枚という現場で働いていたこともあります。これはフロッピーディスクの容量が1.4MBしか無いので、持ち出されたとしても被害が大きくならないという観点での対策でした。携帯電話は建物自体の電磁シールドにより圏外、WiFiも利用できないので外界との通信は遮断されていました。セキュリティについては物理・論理的な対策はもちろん必要ですが、過度にやりすぎると不便でしか無く、コストに見合わない施策になります。
セキュリティの技術としては終りが見えない追いかけっこが続くと思うので、契約書というか誓約書というか、それで縛る事が意外と良いかもしれません。情報の流出が本人の故意であった場合、迷惑料もプラスで被害総額全部、個人に請求するぞ 的な。それでも映画のヒロインのように、命を掛けてやる人はやるのでしょうけど...
「フロッピーディスクなら許す」みたく、完全に封鎖するのではなく必要最低限の利便性は残しておくのが良いと思います。
作業者のPC問題
セキュリティと利便性は相反する事象であり、バランスを取る必要があります。セキュリティに関してはおそらく今後、技術の発展と見直しが入るはずです。問題は、作業者のPCです。
ITの世界でもクローズドな環境はまだまだ多く、サーバーご本尊と専用線で結ばれた事務所の狭い部屋で、一人あたり横幅60cmしか割り当てられていないスペースで、メモリが4MBしか載っていない、しかも3世代前で中性能くらいだったPCで作業している方々がたくさんいらっしゃいます。ほんとに。お気の毒です...
3世代前で少ないメモリしか無いために、PCが遅くて人間が待っている状態が多発している環境は、まったくもってヨロシクありません。生産性を1/100にしていると言いたいです。
「そんなこと言ったって7万円のPCを一人一台付与して、100人いたらそれだけで700万円だぞ。一台あたり20万円のPCが良いのはわかるが、減価償却の手間もかかるんだぞ。」
って声が聞こえますが、だから何？です。そこをケチることで、社員の生産性が著しく落ち、長時間労働になり、モチベーションも落ち、開発品質も落ち、必要な時に力を発揮できないストレス等は、減価償却の手間などどうでも良いくらい、重要な話です。開発環境が良くなると、全てがポジティブに向かい、人数も少なく品質良く開発して、結果的にコストも抑えられるというものです。
「さっき言ってたように、全部クラウド上で動かして、手元はWebブラウザだけアレばいいじゃないか？」
ごもっとも、そういう環境が自在に使えるのであればそれでも構いません。その場合は、回線速度、CPU、メモリ、ストレージの割当、使いたいアプリやモジュールが簡単にインストール・利用可能である環境に制限されます。まだ全てが対応できていません。それならば、今は少しでも良いノートパソコンでストレス無く作業ができ、より良い技術を気軽に試せる環境を用意することのほうが重要に思えます。
私が伺うお客様の作業環境も、もうすこし良くしてあげてください！
企業の基幹システムの開発者であれば、Core i7相当、メモリ16GB、ストレージ512GB、IEEE 802.11nのWiFi は最低限必要です！私もこのスペックで2015年にMacBookProを購入してもらいましたが、ほぼ5年経った現在も、全く不満なく使えています。
将来のことを考えれば用意されたクラウド環境での開発も良いのですが、それだと「泥臭い」技術を習得するチャンスが少なくなるんですよね... 自前の環境で試せる「余裕」は必要だと思います！
技術のお話
今日のお話の中で、レッドハットでご用意している技術・製品は下記のとおりです。
プロセス管理：Red Hat Process Automation Manager
ルールエンジン：Red Hat Decision Manager
データ連携：Red Hat Integration
クラウド環境：Red Hat OpenShift Container Platform
プロジェクトの予算承認という課題
Application Modernizationという、既存のアプリケーションをモダンに作り変える提案をいろいろなところでやっています。アプリケーションアーキテクチャ、プロジェクトの流れ、品質の管理等多岐にわたって色々ご説明しています。その内容については今後順次公開していきたいと思っています。私の拙い説明にも納得いただけるお客様が多数いらっしゃいまして、ありがたい限りです。
ですが一方で、「言っていることは理解できる。しかし、もう一歩踏み込めない。」というお客様もいらっしゃいます。今日はそこで出ている課題について書きます。
Return On Investiment (ROI) を示さないと上層部を説得できない！
わかります。費用を出すには効果が見込まれていないと予算化が難しい。経営視点からすれば、効果が無いものに対して費用を垂れ流すわけにはいきません。説得するための資料として、ROIがわかるものを提出する必要があります。
製品を採用した場合や手作りをした場合等、複数のシナリオを立てて導入する製品の金額、設計・構築する費用、運用の費用を算出し比較する必要がありますね（お買い物が大好きな人は意外と楽しかったり...）。製品の金額は「定価」「標準小売価格」等が大体の場合存在しているので目安を付けやすいです。問題は「設計・構築する費用」です。
今までと同じアーキテクチャ・同じやり方で設計構築するのであれば、過去の経験から見積と効果が見えやすいです。しかし、過去と同じことをやるのであれば、モダンに作り変える必要も無いですよね？ つまりこれは考慮に値しないのが一般的です。
お客様の上層部はイノベーションを求めてます。提案側はイノベーションを起こすための「新しいツール」「新しい手法」を提案します。しかし、お客様のシステム部門の現場は、責任問題を回避するために「実績のあるツール」「実績のある手法」に固執される傾向が強いのです。そして、見積の妥当性を定量的に測る方法として、ソースコードのステップ数で測ろうとします。そうすると、製品で自動生成されるソースコードの量とスクラッチ開発時でのソースコードの量を比較したり、CI/CDをやると言いつつWaterfallな開発手法を取るなど、そもそも論...的なおかしな話が噴出します。最終的にはその中で「コスト」だけが独り歩きして、上層部の意思決定として一番安いもので決定してしまうということになってませんかね？
Return on Investment と言う言葉は、日本語に訳せば「投資に対する効果」のはずです。それを「投資金額」だけで判断するのは間違いなのではと強く思っています。効果とは、「想定しているものが、品質良く作成・稼働し、それによって会社に恩恵がある」ところまでなのではないでしょうか。つまり、初期の構築費用だけではなく、その後のメンテナンス性、業務に変更があった場合に速やかに対応できる仕組みでありつづけることまでを考えるべきかと思います。
もちろん、先の話なんてわかりません。このblogを書いている(2020/4/8)間も、新型コロナウィルス感染症予防のために緊急自体宣言が発令されていますが、6ヶ月前に予見できたかといえば、そんなことは無理でした。ならば、先のことを考えずに今の投資だけ抑えるべきなのでは？という考えも、一部理解はできます。ですが、業務のプロセスや基準を自由に組み替えられる仕組みがあったら、危機へのインパクトも低減できるはずで、ベネフィットを過小評価した考えは投資ではないと思います。
ROIを出す必要がある場合は、初期の開発コストだけではなく、5年間での経営計画に則った業績の数値を出してみてはいかがでしょうか。例えば構築するシステムで年3%の改善（コストダウンや収益の増加等）が見込めるReturnとして計算することで、投資金額としていくら位が妥当なのかもわかるはずです。Investment を最小化、Returnを最大化せよというのはわかりますが、何事もバランスが必要ですし、めちゃくちゃ美味しい話はそうそう転がってないものです。
新しい開発手法では見積もれない
「システムはWaterfallで構築し、瑕疵担保責任付きの請負契約で作ってもらうものだ。なぜなら全体の工数がわかってからでないと予算承認ができないし、責任分界点も見えにくいから。」
そう言われるお客様の多いこと、多いこと... 私も心が折れそうになります...
ITのシステム構築費用の算出は、建築業などがお手本になっています。箱やインフラを作れば、あとは自由にできるというところから来ているのでしょうか。未だに官公庁ではシステムの構築のこと「工事」と言っていたりします。ところが、ソフトウェアである業務アプリケーションは、箱やインフラではないのです。箱の中身になるわけなので、そもそも算出方法も工法も違うはずです。無理やり合わせていることにすごく違和感があるのは私だけではないはず。
ならば、私が今ここで宣言します！
変えましょう！ アプリケーションの 構築手法と見積手法。
私が提唱しているのは「イテレーション開発」。AgileやScrumのようですが、それよりも少し粒度を大きくし、1週間〜8週間で要件の整理・設計・開発・テスト・振返りを行うスタイルで、完成基準を満たしたら初めてリリースできる手法です。この手法の目的は品質の向上です。小さな目標を立てて、そこまで作ったら必ずテストを行い、問題の早期発見と修正をしやすくすることで問題が大きくならない、手戻りが発生しない、要望に柔軟に対応しつつ品質良く短期間で開発が終了するという特徴のある方式です。（別途紹介したいと思います）
良いのはわかるが、これにどれだけの予算を計上するのか。いつまでも繰り返し開発が発生して、当初の予想より費用がかかってしまうのではないか？という疑念が踏み切れない理由かと思います。最初に全体がわからないというのはその通りですが、ではWalterfallなら完璧に全体が把握できるのでしょうか？無傷で終わる大規模プロジェクトは見たことがありません！
コトを大きくするから難しいのです。開発規模を小さくしてみれば見積もしやすいのです。例えば、イテレーションの期間を、4週間等と区切ってしまえば見積はしやすいはずです。最初の1回は8週間等、少し長めに期間を取ります。これは基礎固めをしっかり行うためです。基礎がしっかりしていると、建築物も完成するのが早いし長く住めますよね。8週間 x 5人でできる範囲を設計・実装し、どのくらいの品質で達成できたかで一旦締めます。締めた後は振返りを行い、良い点・悪い点の意見を出しあって方向性を確認し、次のイテレーションとして4週間等と期間を定めて、必要な予算を計上します。イテレーション開発の最初の1期間は長いですが、課題の少ない確固たる基盤が出来上がることで、各イテレーションは短くなっていきます。
たとえ最初の1回で失敗したとしても、8週間 x 5人分であれば傷は大きくないはずです。修正も容易に効きます。最初の1回で成功した場合、その次のイテレーションを回せば全体でどのくらいの予算が必要で、どれだけの開発生産性になるか、見通しがつくはずです。最初から全体を一気に予算化しようとするか難しいのであって、全体像を描いたうち、イテレーション開発として最初の1回を試行すればよいのです。 2,000人月を使い切って初めて品質を満たしていない事に気づいて炎上するより、遥かに良いはずです。
リスクを下げ、品質を上げてコストを下げる。みなさんこれを目指しているはずです。それは、単にフレームワークだけ変えれば達成できるというものではありません。アーキテクチャ、開発手法、テストの方法、品質の確認方法等、全てをもう一度見直してみる必要があると思いませんか？
相談先
レッドハット社では、ITのプロフェッショナルという視点でコンサルティングサービスを行っています。業務課題から要素技術のマッピング、それをカバーするレッドハットの製品の選定、さらにはその仮設に対する検証としてのサンプルアプリケーションの実装、パフォーマンスのチューニング等まで行っています。IT部門の文化を変えるお手伝いを行っている、と言っても過言ではありません。Red Hat Enterprise Linux というOS部分からJava上のアプリケーション層まで、DatabaseとUser Interface以外の広い範囲をカバーしています。どのIT企業よりも尖りまくった人材を抱えているレッドハットに、是非ご相談ください。
ブログ始めます
はじめまして。うめぞーこと梅野と申します。
IT業界歴およそ25年。
そのうちの半分くらいはルールエンジン絡みのお仕事をしてきました。
なかなか自己表現が不得意な人間ですが、ITに対する思いとか技術の紹介とか精神論？とかを書いてみようと、一念発起しました。どこまで続くかわかりませんし、時々毒も吐くかもしれませんが、皆様のお役に立てる情報になるよう頑張りたいと思います。どうぞよろしくおねがいします。
簡単に自己紹介。
2020年4月1日、赤い帽子の会社にて10年目。プリセールスをやってます。
前職からルールエンジンを中心に、BPMとかアプリケーション周りをやってます。製品技術だけではなく、開発手法や体制なども含めてお客様にご提案しています。
趣味は写真撮影（最近体力ない...）、美味しいものを作ったり食べたり（作る方はあまりチャレンジなコトしてないなー）、ドライブしたり。温泉大好き。
尊敬する人：May'n、MISIA、麻生太郎、イチロー 他、心を揺さぶる人
好物：フレンチフライ、ハンバーグ等の洋食系
アレルギー：甲殻類（生でなければOK）
:)
