ハードやソフトなどテクノロジーにかかる費用が、ここ10年横ばいであるのに対し、システムの開発費は減少し、運用費は8倍に増えている。それでも業務が破綻しないのは、社内に要件があるシステムは、ほぼ作り尽くしたことの表れだ。今後は、要件が見えづらいシステムの構築に乗り出さねばならない。
コンピュータが企業情報システムに利用されるようになってからの50年間、世界中のIT部門やITベンダーは、「デマンドドリブン型」のシステムを開発・運用してきた。デマンドドリブン型とは、利用者の要求（デマンド）が決まっており、その要求に沿って決定したルールに基づいて動作する仕組みである。
例えば、「喉が渇いた」という要求に対し、自動販売機のボタンを押せば商品が出る仕組みや、「現金で買い物をしたい」という要求に対し、ATM（現金自動預け払い機）で「1」と「万」のボタンを押せば1万円が引き出せる仕組みである。
デマンドと、それに対する仕組みが分かっているので、アプリケーションは作りやすいものの、ビジネスルールとコンピュータロジックが分離されない。アプリケーションとしてのロジックが、if-then-else型またはcase x型でプログラミングされる。システムは、開発者の経験やスキルなどに依存し、俗人的な要素を内在してしまう。しかし、こうしたシステム群は、過去50年で作り切っており、ニーズは枯渇しているのが現実である。
デマンドが定義しづらい時代に突入
これに対し、「イベントドリブン型」のシステムが存在する。デマンドは決まっておらず、イベント（単なる事象）に基づいて動作する仕組みである。冒頭の例でいえば、「喉が渇いた」というデマンドではなく、自販機の前をただ通りかかった人に対し、年代や性別、気温・湿度などをモニタリングし、その人に見合っているであろう商品を提案する。
ATMの例でいえば、ATMを操作しに来た利用者のイベント、例えば近いうちにヨーロッパに旅行するという情報を察知していれば、ユーロの現金パックやトラベラーズチェックの購入を勧誘する。プライバシーの観点から、この実現には壁があるものの、銀行と旅行会社の間に新しいつながりができれば、ATMはもはや、単に現金を引き出すための機械ではなくなる。
いずれの例でも、システム動作の起点は「通りかかる」「機械の前にいる」というイベントになる。そこでは、デマンドが決められないので、アプリケーションを作るのは難しい。まず仮説を立て、最初は、あいまいなルールでもってシステムを構築する。実際に稼働させて得られた結果を科学的に分析することでルールの精度を高めていく。言うなれば、生きたビジネスルールで動作する仕組みだ。
完璧な要件定義はできないのだから、あいまいな要件を前提に、運用しながらシステムが成長できるように開発しなければならない。そこでのアプリケーションは、ビジネスルールとコンピュータロジックの分離が不可欠であり、従来の俗人的ではない科学的アプローチが求められる。
この段階で必要なのが、DevOpsの概念である。アプリケーション開発者とITインフラ運用者が連携を密にするDevOpsの基本概念があって初めて、イベント・ドリブン型システムの構築に乗り出せる。
会員登録（無料）が必要です
- 1
- 2
- 次へ ＞
