はじめに
昨年の夏に以下の記事を書きました。
その末尾は、以下のようになっています。
この国の DX が進まない大きな理由の一つがレガシーシステムにあるのであれば、ブラックボックス化し技術的負債となってしまったレガシーシステムからのリアルタイム連携をどのように実現するかについても、大きな変革が必要だと考えています。それをどのように実現するかについては、別途、考えを記事にまとめたいと思います。
かなりのロングパスになりましたが、そのリプライです。
Data Fabric
前回のつづき
前回の記事をもう少し引っ張ると、この記事でも Data Fabric の定義は、以下のとおりです。
データがバラバラであっても、『欲しいデータを』『欲しい時に』『欲しい場所で』入手できる
そして、前回の記事では、データを管理しているシステムからメタデータを機械的に収集すれば、お金も時間も人手もかけずにデータマネジメントを始められることを説明しました。
これまでのヒトが EXCEL ファイルにテーブルの定義を入力するというメタデータ・マネジメントから、データを管理するツールとメタデータを管理するツールの連携によって、メタデータをマネジメントする という新しい業務へ変革を行いませんか？
メタデータを自動収集して、システム化することで、全ての関係者がメタデータを共有できます。データをデータで語り合える環境なくして、真のデータ活用はできません。そして、これを実現するメタデータ管理サービスのご紹介を追記しました。
本当にしたいこと
データ活用というと、
- データ活用基盤にデータを集めて、データ分析基盤でデータを分析して、新たな知見を得る。
- AIのモデルに投入して、特徴量を得る。適切な文章を要約させたり、生成させたりする。
みたいなことになっているかもしれません。それは、それで大切だと思いますが、それは、データ活用のゴールなのでしょうか。本当にしたいことは、データ分析で得られた知見やAIで得られた特徴量を、実際の業務に適用して成果を上げることなのではありませんか？
それでも、やはりDX
DXは、かなり使い古された、新鮮味を失ったワードになってしまった感もありますが、それでも、我々が目指すべきゴールはDXだと思います。見飽きたと思いますが、もう一度、経済産業省の定義から見直しておきましょう。
企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、顧客や社会のニーズを基に、製品やサービス、ビジネスモデルを変革するとともに、業務そのものや、組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立すること。
この定義は、平成30年12月の「デジタルトランスフォーメーションを推進するためのガイドライン（DX 推進ガイドライン）Ver. 1.0」の冒頭の「はじめに」の脚注が初出と思います。先週、経済産業省から出された「デジタルガバナンス・コード3.0」が、その後継です。
DXを進める基盤として、ITシステムに求められるもの
もちろん、ITだけでDXができる訳ではありませんが、ITがDXを進める基盤であることは間違いありません。このセクションの見出しは、IPAの「「DX推進指標」とそのガイダンス」からお借りしました。
DX を進める基盤として、IT システムに求められる主要な要素は、以下の３つ。
① データをリアルタイム等使いたい形で使えるか
② 変化に迅速に対応できるデリバリースピードを実現できるか
③ データを、部門を超えて全社最適で活用できるか
この部分は、経済産業省の所管であった令和元年度版から変わっていません。この３つの要素を実現するためのキーワードはWeb APIです。
Web APIとともにAPI仕様書も公開することで、そもそもどんなデータを持っているのか、リアルタイムで使いたいデータは何かを認識し、実際にそれを使うことが可能となります。
ITシステムを小さい単位でサービス化してWeb APIで連携すれば、新しいビジネス、新しい顧客が現れても、サービスを組み替えて適切なシステムを素早く構築できます。
これらの結果、部門を超えて、会社を超えて、外部のサービスを含めたバリューチェーンの組み換えにも対応できるようになります。
ここまでは、前回の記事でも書けたのです。上の引用は、以下のように続きます。
しかしながら、多くの日本企業では、部門ごとに個別最適でシステムを構築し、しかも過剰なカスタマイズにより、IT システムがブラックボックス化してしまっている。これを解消できないと、全社的に DX を展開することは困難である。
解決したいこと
対話に向けた検討ポイント集 第3章
前回の記事でも触れましたが、見出しにしたドキュメントが経済産業省から2020年12月に公開されています。このドキュメントでは、新規システムへ投資できない原因である既存システムの「ブラックボックス化」「ドキュメント陳腐化」「複雑化」といった技術的負債がなぜ存在して、それでも目指すべきDX化のためには、どのような手順で、どのように優先度を決め、段階的に解消していく方法が丁寧に記載されています。
前の節の末尾の「「DX推進指標」とそのガイダンス」の引用までなら、この「対話に向けた検討ポイント集 第3章」で処方箋としては十分だと思いました。ですが、このドキュメントは2020年12月に出されているのです。タイミングとしては、DXレポート2 中間とりまとめなのです。その後、DXレポートは、2.1、2.2と続き、昨年のDX白書2023のサブタイトルは『進み始めた「デジタル」、進まない「トランスフォーメーション」』なのです。
つまり、この問題は、正攻法では解決しない。という結論に達しました。
少し古いですが、経済産業省で公開されている 対話に向けた検討ポイント集 第3章 を読む前なら、「リアルタイム連携であれば、WebAPI が良いと思います」で終了していたかもしれませんが、この国の DX が進まない大きな理由の一つがレガシーシステムにあるのであれば、ブラックボックス化し技術的負債となってしまったレガシーシステムからのリアルタイム連携をどのように実現するかについても、大きな変革が必要だと考えています。
どのように実現するか
長くなりましたが、本題です。
2020年に比べて、IT人材不足、ITスキル不足の問題はより深刻さを増しています。弊社でも、エンジニアの採用には大変苦労しています。ですから、人的リソースに頼らない解決方法が必要です。
Web API サーバ自動生成
正しいメタデータが存在していることを前提とすれば、そのデータに対してアクセスするプログラムを機械的に実現することができます。なぜなら、データにアクセスするために必要な情報がメタデータとして管理されているからです。
しかしながら、Web APIを利用するヒトが、そのWeb APIが何であるかを理解できなければいけません。これも正しいメタデータが存在していることを前提とすれば、仕様書を機械的に生成することが可能です。
これらを独自方式のローコード、ノーコードと独自のランタイムで実現したのでは、数年後、そのツールの寿命とともに技術的負債に逆戻りする危険性があります。ですから、すべての構成要素は標準的で汎用的なソースコードから組み立てられるべきです。
Web APIサーバーはコンテナイメージとして提供されることで、データベースを共有する別のアプリケーションとして実装でき、複雑化、ブラックボックス化したレガシーシステムを変更することなく、Web API連携可能にします。
Data as a Product
製品のように扱いやすいデータを実現するため、すべてを標準的な要素で構成します。
まず、仕様は、OpenAPI Specification（日本語訳（拙訳））に準拠します。扱いやすいようにHTML形式にした仕様書も生成します。
OpenAPI仕様のとおり、URLとHTTPメソッドの組合せに対して、Schemaを指定するRESTライクな標準的なWeb APIアプリケーションを生成します。また、OpenAPI仕様書で定義されたValidationも自動生成します。拡張ポイントを明示したソースコードを生成するので、生成コードを活かしたカスタマイズが可能です。もちろん、自由に拡張することもできます。
生成されたWeb APIサーバーは、一般的なDockerコンテナ形式にビルドして提供します。コンテナ内のWeb APIサーバーは、OpenAPI仕様書もホストするので、動いているものと完全に一致する仕様書が同梱されます。一般的なDockerコンテナなので、利用者の組織で標準とされている運用が可能です。認証や認可の仕組みもサイドカー・パターンによって、組織で標準とされている方法が実現可能です。
データカタログと組み合わせることで、データの発見から利用までサポートすることが可能です。
おわりに
この記事のコンセプトで開発された Web API自動生成サービスをローンチしました。ご興味のある方は、是非、ご評価ください。
弊社の技術ブログを見て頂いた方は、お気づきかもしれませんが、ここまでのブログには、Veleta を実現するための技術検証を兼ねたものが多数あります。これからも Data Fabric を実現するための仕組みをどんどん提供していきますので、ご期待ください。
Discussion