DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

今回はお馴染みのEA(Enterprise Architecture)ではなく、もう１つのEA(Enterprise Agile)の話をしたい。私は今から４年前ユーザ企業の情報システム部門長時代に、３０年間ウオータフォール一辺倒のSIerの開発手法にしびれをきらし、E-Agilityなるコミュニティ（現在も継続）に参加した。それは企業の求めるスピードに従来のやり方では応えられないと常々思っていたことに起因するが、一方で、日本企業の基幹系システムへのアジャイル適用事例が少ないことに自身のエンタープライズＡＰの開発経験が何かの役に立てるのではないかと考えたことも動機付けとなった。

日本においてエンタープライズレベルでのアジャイル開発を可能にするには、本シリーズ2013.12.16号“DEVOPS”に書いた通り、体制面におけるベンダー請負型開発の是正と、技術面での向かうべきアーキテクチャ青写真の作成が条件となる。今回のブログではこの前提の上で、現実のエンタープライズ・システムの開発・保守に、どうすればアジャイル手法を適用することができるかをお話したい。  まず第一に基幹系と呼ばれるアプリケーシヨンのセオリーを知る事。財務会計、サプライチェーンマネジメント、ヒューマンリソースマネジメント等にはそれぞれ揺るぎないロジックがある。それ故、MBAの履修科目にもなっている。そして今ではMBAで学ばなくとも多くの書物が出版されている。既成概念をぶち壊すパラダイムチェンジの創造も良いが、まずは基本を知っての上だ。ここでSIerの方は、「セオリーが予め組み込まれたのがパッケージシステムなので、四の五の言わずそれを利用すれば良い」とおっしゃるかもしやない。もちろん、これを一から作り込み何年もかかってパッケージに追いついたのでは、それこそアジリテイに欠ける。言いたいのはセオリーをブラックBoxのままにせずに自分のものにする事で、”パッケージで実現出来ない部分が何か”がわかり、その部分にアジャイル開発を適用する事が可能となるということだ。

では次に実際にアジャイル手法を適用してプロジェクトが路頭に迷うことなく、要求された品質、コスト、納期通りにシステムを完成させる為には何が必要か？答えは開発単位を小刻みにすることである。と言っても継続する一連の業務（ロングトランザクション等）を分断することは出来ない。大きい側のリミットは、ビジネス上の投資回収開始の早期化を考慮して６ヶ月以下で完成できる大きさとしたい。そして、これらの開発単位の境界線はデータベースがその役割を果たす。いわゆるデータベースＨＵＢを介した疎結合アーキテクチャモデルである。疎結合か密結合かの選択はビジネスニーズから決まる。ここで読者の中には、「スコープを狭めればそりゃアジャイルでもうまく行くに決まってるよ」とおっしゃる方がいるかもしれない。しかし皆さんは全社システムのＴＯＢＥスケッチをお持ちでしょうか？上述したようにエンタープライズでは全社スケッチの存在が必須である。海図をもたずに外海に船出することは、ちょっとそこまでと思っても遭難の可能性が高い。高性能な船であれば、なおさら進路の外れ方も大きい。（※非エンタープライズ・アジャイルはいわば内海から出ないので安全であるが期待も小さい。）

最後に”エンタープライズ”の接頭語が付く場合と付かない場合との最大の違いがデータ品質に対する構えである。アジャイル開発がデータ品質をないがしろにしていると言っているのではない。よりデータ品質に気を使う必要があるという事である。企業レベルの基幹系処理においては社内外に出力するデータに問題があるとステークホルダの信用失墜を招く。エンタープライズシステムでは「少々のバグは稼動しながら直します」とは言えない。アジャイル開発したとしても、あらゆるシナリオで綿密なテストを繰り返し１円単位での現新比較が必須となる。複数アプリ間でのデータのシンクロナイズは必須であり、結果としてそのアーキテクチャはData-Centric にならざるを得ない。

このように、もう１つのEA(Enterprise Agile)は、本来のEA(Enterprise Architecture )なくしてはうまく行かない。がしかし、本来のEAが描かれていれば、もう１つのEAを矢継ぎ早に繰り出すこが可能になり、ビジネス・アジリティーに大きな貢献をもたらす手段となり得る。待ちに待った”システムが企業活動に直接貢献できる時代”に突入できるのだ。