オピニオン
DXを進展させるために情報システム部が取り組むべき事とは何か？
更新： 2019年7月1日
このコラムの読者ならDXと聞いてデラックスと読む人はいないでしょう(笑）。我々の業界で今やDXの文字が躍らない日はないと言っていいぐらい浸透しています。ちなみに、BizHintによるとDXのXは英語圏ではTransを省略する際にXと表記することが多いためだそうです。
そんなDXが直近の課題としてクローズアップされる発端とも言える経済産業省のDXレポートには、「DXを実行するに当たっては、新たなデジタル技術を活用して、どのようにビジネスを変革していくかの経営戦略そのものが不可欠である。～中略～。ビジネスをどのように変革していくか、そのためにどのようなデータをどのように活用するか、どのようなデジタル技術をどう活用すべきかについて、具体的な方向性を模索している企業が多いのが現状と思われる」とあります。
つまり「デジタルに対するビジョンと戦略の不足」、これがDX推進における課題の1つであるという指摘です。まさに「経営課題」ですね。続いて「DXを実行していくに当たっては、データを収集・蓄積・処理するITシステムが、環境変化、経営・事業の変化に対し、柔軟に、かつスピーディーに対応できることが必要である。そしてこれに対応して、ビジネスを変えていくことが肝要である」とITに言及します。
そしてこう述べます。「我が国の企業においては、ITシステムが、いわゆる『レガシーシステム』となり、DXの足かせになっている状態が多数みられるとの結果が出ている。～中略～。すなわち、DXを進める上でデータを最大限活用すべく新たなデジタル技術を適用していくためには、既存のシステムをそれに適合するように見直していくことが不可欠である」。ここまで来るとIT部門に直結します。
レガシーシステムに関する記述をもう少し引用しましょう。「レガシーシステムの問題は中身がブラックボックス化することにあり、自分の手で修正できないほどの状況」と定義し、それに陥る原因を挙げています。1つは適切なメンテナンスやシステム刷新が行われない、つまりITマネジメントが不在であることです。
もう1つは「システム全体が一体化した古いアーキテクチャや開発技術はメンテナンスによって肥大化、複雑化する傾向にあり、時間の経過と共にレガシー問題を発生しやすい」こと。たとえ費用や時間を費やしてITマネジメントを実践したとしても、古いアーキテクチャのままでは常に再レガシー化の恐れが残るーー。仰る通りで、ぐぅの音もでません。
DXに求められるテクノロジー（技術）を理解しよう
前置きが長くなりましたが、前半の経営課題については別の機会に譲ることにして、後半のITに関わる指摘について、我々がどうしていけばいいのかを考察してみます。あらかじめ、かなり技術的な話になることをご容赦下さい。個々の要素を理解する必要はないとしても、IT部門として備えるべき能力だと考えるからです。
まずユニチカの状況に触れると、昨年春に30年以上も使い続けてきたIBMのホストコンピュータの電源を落としました。ここでは書けない多くの苦労があったのですが、ストレートコンバージョンのリホスト手法の1つである「システムリフォーム」によってオープン環境への移行を実現したのです。オープン環境はJavaのフレームワークを活用して、MVCモデル（これも既に古くなりました）に則り、ビジネスロジック制御はコンテナの形で実装しています。
しかしデータベースの正規化や最低限の三層モデル化は実施したものの、ビジネスロジックの中身は昔のPL/Ⅰのソースをそのままコンバートしたものであり、モノリシックな作りは旧来のまま。したがってオープン環境に移行したと言っても、再レガシー化する可能性を否定できません。実際、何からの変更をする際、影響範囲を確定するのに多大な時間を要するのはホスト時代とそう変わりません。
もちろん結合テストの自動化やCRUDツールの導入など手を打ってはいますが、変更に要する期間を劇的に短縮させるまでには至っておらず、いわゆる”技術的負債”を抱えている状況です。2025年の崖を乗り越える健康な身体になるには、モノリシック構造という病変そのものを取り除き、新たにマイクロサービス、アジャイル開発などのDXを推進するための核となる技術を活用できる構造に切り替える必要があります。
この点で脱ホストはまだジャーニーの始まりに過ぎません。システムの構造を、業務のコンテキストが密結合されているモノリシック構造から最小業務単位のコンテキストに分割し、業務そのものが疎結合な構造に置き換えて行く必要があるのです。とはいえ、これを推進していくにあたり大きな壁となる2つの問題が存在すると筆者は考えています。
一つは、どうやってマイクロサービス構造にリファクタリング（外部から見た機能や動作を変えずにソースコードを整理・洗練すること）するのかという技術的問題、もう一つはモノリシックに繋がった一連の業務をいかに今後のビジネスの変化に合わせた適切な業務単位に切り分けるかと言ったいわゆる設計手法の問題です。もちろんこれらの取り組みを推進する人材や体制の問題もありますが、これはいったん置いておきます。
さて、一つ目の技術的問題としてマイクロサービスのバージョニング、あるいはサービスの非同期通信、カスケード障害、データ整合性問題、サービスの検出、および認証への対処といった多くのサービスが林立するがゆえの、サービス間の相互作用による複雑性と依存関係といったマイクロサービス自体の難しい課題があります。
また、運用面ではインフラのプロビジョニング、コードのデプロイメント、大量のログデータの分析といったソフトウェア開発・実行環境も重要な課題でしょう。ただし、これはAWSやAzure、GCPなどのクラウドサービスが数年前と比べて格段に向上してきており、これらの課題をクリアする製品が多く出てきています。クラウドサービスを利用するのが現実的な解ではないでしょうか。
そう考えると、一番の問題と言えるのは既存データベースの分割です。リレーショナルデータベース上でのトランザクション処理、バッチ処理などは長大なトランザクションであっても複数テーブルに渡るデータの整合性が保たれています。しかしサービスごとにデータベース持つマイクロサービスでは、これらのデータを含めて各サービスの独立性を高めなければ、変更容易性や拡張性、可用性を享受できません。データベースを分割しながら、データ間の一貫性をどう保つのかが難しいところです。
次に、マイクロサービスをどの業務単位に切り分けるのかの設計手法の問題があります。これは「ドメインコンテキスト境界の定義」とも呼ばれますが、対処法としてドメイン駆動設計（以下、DDD）が注目を集めています。割と以前から提唱されていた手法ですが昨今、マイクロサービスのドメイン分割はDDDでいう「境界づけられたコンテキスト」をサブドメインに割り当てマイクロサービスとするのが良いとされています。
ここらあたりの技術に詳しくない方には「ドメイン？何のこっちゃ！？」という感じですが、ドメインとは領域、事業領域のこと。例えばECサイトで商品を販売する一連の業務を例に挙げましょう。販売部から見た「商品」の概念は 売値、在庫数、顧客（直接の売り先）などになります。一方、配送部にとっては売値は不要であり、配送先や配送日、配送状況などが「商品」の定義となります。
これに経理部が入ってくると請求額、請求先、請求状況などが関心事です。このように同じ「商品」であっても関係者によって違うイメージを持っており、これらを強引に統一するとモノリスな商品マスタが出来上がります。旧来のやり方ですね。
DDDでは用語の意味が同じ範囲を「境界づけられたコンテキスト」と呼んで、それをサブドメインとして分割し、サブドメイン単位で言語を統一します（これをユビキタス言語と呼ぶそうです）。この「境界づけられたコンテキスト」をマイクロサービスの単位にするのが、いい具合にハマるので近頃にわかに脚光を浴びているというわけです。
よく似た概念にSOA（サービス指向アーキテクチャ）があります。源流と言ってもいいかもしれませんが、再利用性を主な目的としたSOAに対し、マイクロサービスは影響範囲を限定し頻繁な変更にも耐えられることを主目的としているため、DDDの設計手法はピタリとハマります。全体を分割して小さい範囲で開発していきますので、アジャイル開発、あるいはCI／CD（継続的インテグレーション、継続的デリバリー）とも相性が良いという利点もあります。
これらを組み合わせると、おぼろげながらリファクタリングの方向性が見えてきます。例えば、モノリスのデータベースの分割はDDDの「境界づけられたコンテキスト」の概念で行う。そしてEJBあるいはサーブレットにDDDを適用し、ドメイン層を作成してマイクロサービス群に置き換えて行く。それらをクラウドサービスで提供される開発・実行環境やその他の機能（サービス）を活用して構築し、実行させるという流れです。
移行の方法としては、対象とする現行の処理をトランザクション単位で切り出して、クラウド上に先に定義したドメイン層のマイクロサービスの組み合わせで一連の処理を実行し、最終的に得られた結果を元の処理に返しモノリスのDBを更新すると言うのはどうでしょう。マイクロサービス間のオーケストレーションがきちんとされていれば結果的にトランザクションの「結果整合性」が取れていることになります。
DBは元のテーブルと二重持ちとなり二度手間のようですが、これだと現新比較も容易であり、なにより部分的に始められてスモールスタートが可能です。また、今後も変更の可能性が低いSoRな処理はリファクタリングせずに、そのまま使い続ける。変更依頼があった部分やSoEと絡んできそうなところを優先的に実施していくのが現実的でしょう。
いずれにしても今後、我々IT部門がDXに対応するには、アジャイル開発やDDDの設計手法、CI/CDなどは獲得すべき技術であり、SoEに絡む部分からマイクロサービス化に取り組んでいく必要があります。もちろんCIOやIT部門長が自ら手を動かす必要はないにせよ、スタッフにはここで述べてきた技術が求めらます。先に「人材や組織の問題はいったん置く」と書きましたが、そこには求められる技術を理解せずにデジタル人材問題を議論しても答えが出にくいのではという思いがあります。
ただ、これまでの技術とは異なる面も多いので、1社で全て行うにはかなりハードルが高いと言わざるを得ません。この点は当社にも当てはまりますが、そこは経産省が推進している「技術研究組合（https://www.meti.go.jp/policy/tech_promotion/kenkyuu/01.html）」のような枠組みを活用して、心あるベンダーやアカデミアと一緒に取り組めないか、などと考えています。
ユニチカ株式会社
情報システム部長
近藤 寿和