「ITガラパゴスの日本」
はじめに
1960年代から1980年代までのコンピュータのビジネス利用黎明期においては日本と米国は競い合っていましたが、IBMの超大型機の登場によって拠点拠点の中小型機を集約し、一元的に管理運用ができるようになってから、その活用の方法は、大きく分かれることになってしまいました。私はそれが現在の米国や米国をコピーした日本以外の国のIT＆DXはどんどん進むのに、日本のIT＆DXが進まない根本的な原因であると考えています。
今までほとんど仕事に関係する内容を文字にして公開するようなはしなかったですが、実は日本のITは大問題を抱えており、DXどころの騒ぎでないのが現実なのですが、黙っていても何も変わらないので、少しでも関係する方々と問題を共有すべく、自分の理解や考えを発信して行こうと思います。
道が分かれてしまった原因
中小型機による拠点単位でのコンピュータ活用から、大型機へ一元化するうえで、東西に長くニューヨークとロサンゼルスでも4時間の時差がある米国では、夜間バッチの時間を短縮しなければならず、各拠点の業務を標準化するだけでなく、仕事のやり方自体をオンラインリアルタイムでのトランザクション完結型にBPR（業務プロセスの見なおし）する必要があり、それをやり遂げました。
一方、日本は業務の標準化は行いましたが、伝票溜め込み型(昼間はインプット、夜間にデータ処理)の基本的な仕事のやり方を変える必要まではありませんでした。
両者が道を分つ事になった理由は地理的要因だけではなく、極めて高価だったコンピュータリソースを如何に上手に使うかということもあったでしょうが、米国が行ったようなBPRの必要性がなかったという意味において、最も大きな要因は時差だったと言えるでしょう。
しかし、両者にその違いがあることを理解しないまま、90年代初頭に中身は同じなのですが、目的別に並び方を変えて構築していた複数の階層型データベースの統合を可能にするリレーショナルデータベース(DB2やOracleなど)が登場すると、益々コンピュータの活用方法は離れて行く事になります。
リレーショナルデータベースとERP
ここでリレーショナルデータベースが出てきた頃の私の経験を伝えておきたいと思います。
私は1993年から1997年の5年間、XXXXX（株）の100%子会社であるXXXXX XXXXXXX（株）が、主として米国で事業を展開してた英国資本のコンサルティング会社James Mrtin & Co.の持ち株会社であるJames Martin HoldingsとJames Martin & Co.と50:50の合弁で設立したJames Martin & Co. Japanに出向し、コンサルティング業務に従事していた事から、同社事業の本拠地である米国への出張機会がしばしばありました。そこで、同社に限らず顧客企業のエンジニアとのワークショップに参加し、様々なトピックで議論をする機会を得ましたが、当時の人気トピックはBPRやデータ統合でした。
そのデータ統合のワークショップで私から、「リレーショナルデータベースはバッチ処理のためのロード/アンロードのパフォーマンスが悪すぎて夜間バッチが終わらないから実用的でない。」という問題提起をしたときに、私以外のエンジニア全員が「そもそもそんな夜間バッチが何故必要なのかが分からない。」と口を揃えて言われ、もちろん、彼らは私の問題提起の目的を理解しようとしてくれましたし、私も一所懸命説明はしたものの、結局は文化や慣習の違いがあるようだと言うことでワークショップは終了し、何か釈然としないものが残りながらも、私の記憶からも、ある日の出来事のひとつとして通り過ぎて行ってしまいました。
その一方、徹底的にノーマライズする論理データモデリングやデータ設計、それに基づくリレーショナルデータベースを中心にしてバッチ処理をミニマム化したシステム&業務オペレーション設計を得意技のひとつとしてコンサルティングをしていたその当時、今や世界を席巻するERPであるSAP/R3が日本に上陸し超大手企業が採用を始めましたが、巨大な費用がかかる大変なプロジェクトだという情報が専門誌に良く掲載され、よく話題に上りましたが、ERPベンダーやお抱えのコンサルタントからはERPに合わせるためのBPRが必要だという話しをよく聞きましたが、その具体案が提示される事は何ひとつありませんでした。それが本質的にどういうことなのか？がわかっていなかったのでしょうし、私も仲間も部分的なことだけで、結局はわかっていませんでした。
データモデリングとデータ統合の明暗
ここからは、順を追って日本と米国（日本以外の世界）について綴っていこうと思います。
1980年代までは、一般企業におけるコンピュータシステムはプログラマーが所定のプログラミング言語（Cobolが主流）で、手書きの仕様書に基いてソースコードを書き（初期はパンチカードに穴を開けてリーダーで読み込ませる）、コンパイル（機械語へ変換）してロードモジュールを生成し、それを実行するための条件を指定したJCL(Job Control Language：IBM用語)によって動かしていました。これらのコンピュータを動かすための作業についてはメーカーが異なっていても、日本でも米国でももちろん同じで、決して生産性の高い作業ではありませんでした。
パンチカードに穴をあける機械を使って作業を行うキーパンチャーという職業があったくらいです。
一方、1980年代になるとコンピュータ技術のポテンシャルの高さと進歩の速さによって高度情報化社会の到来が声高に叫ばれるようになりました。実際、日々増大するプログラムの保守を含めたコンピュータシステムの運用・管理、続々と出てくるシステム化ニーズへの対応のために、コンピュータ技術者の確保はもちろん、設計・開発・保守・運行の生産性の向上は益々重要な課題となっていきました。
そして、IBMのコッド博士が1970年に発明したリレーショナルデータベースの、そこそこ動く製品版が出始める1980年代の中盤頃から、米国を中心に、ソフトウェア開発におけるQCDを高度に両立させるための、各種の技術や、開発方法論、データ統合、データ中心設計（Data Oriented Approach）、オブジェクト指向設計などの各種のアプローチや技法の重要性が認知されはじめ、日本でも意識の高い企業の情報システム部門では米国を倣ってこぞって導入・学習し、実際の設計・開発作業への適用を試行しました。
しかしながら、すでに、拠点コンピュータを統合したときにBPRを行い、オンラインリアルタイム処理中心にシステムを組み替えていた米国の先進企業では、本格的にデータ中心設計を導入することで、整合性確保が課題になっていた目的別データベースを、一つに統合されたリレーショナルデータベースを中心としたシステムへの転換を果たし、次々と様々な企業が追従していきました。
つまり、米国の幾つかの先進企業は1980年代終盤には、物理制約を極力排除した形で、コンピュータという論理空間に最適化した業務プロセスをソフトウェアとして転写して動かすようになっていたということです。
一方、標準化して集中化しただけのバッチ中心のシステムを継続した日本では、データ中心アプローチでデータモデルを作成し、すでに完成しているバッチ中心システムの中にリレーショナルデータベースを構築しても、処理時間が長くなり、高価なメモリーを食い尽くすだけのものでしかなく、データ中心設計もリレーショナルデータベースも、その価値は、コンピュータの本来の価値とともに、ほとんどのエンジニアにもマネジメントにも理解されないまま、データ中心アプローチやデータモデリングは廃れていきました。
なお、データベース製品としてのリレーショナルデータベースは、処理性能も向上したことと、従来型製品がなくなっていったこともあって、現在でも主流のデータベース製品として使われています。
テンプレート、そしてソフトウェアパッケージへ
米国での動き
1980 年代後半あたりから、米国において、ノーマライズを追求したデータモデリングによってデータ統合(1fact in 1place)を果たした企業は、そのモデルやモデルに基いて構築した自社のソフトウェアが、極めて一般性の高いものになっていることに気付き、テンプレートとして他社に販売するところまで出てきました。
中小型機の世界では会計システムなど業界固有でない機能については会計事務所などが開発したソフトウェアパッケージ製品を導入サービスとセットで販売していましたが、大型機の世界ではこれと言った製品はありませんでした。
SAP/People/JD Edwards など企業の業務システム全体をカバーしたERPソフトウェアパッケージ製品全盛期の始まりです。
ERPが登場するまで、手作りであってもオンラインリアルタイム型に BPR していた企業にとっては、データ統合済みか否かにかかわらず、リアルタイムベースに統合化された ERP を導入するのは、扱うデータの仕様も異なるので、決してたやすい事ではないにしても、大きく業務処理フローの基本的な考え方を変えることなく導入できたはずです。そして、そのときに基幹システムの開発・運用に従事していた一定割合の技術者はデータモデリングやデータベース設計のスキルをもって、WEBアプリケーション開発や BPRコンサルタント、急拡大する ERP ベンダーの開発部隊等に移っていったのでしょう。
そしてその理論や技法はプログラミングとともに高校・大学のベーシックカリキュラムとして常識化し、今や話題に上る事はありません。
日本での動き
日本では、米国や他国の有名企業が次々に ERP を導入していることを知り、1990年代の後半から、 SAP など ERP の導入を図りはじめましたが、バッチ中心システム上に、会計とその周辺システムを ERP に載せ替えるのが精一杯で、既存のバッチ中心システムとのインターフェース地獄に陥るだけでなく、ERP 化できない機能を外付けと称して新規で開発してバッチでインターフェースするという世界でも類を見ない複雑なシステムに膨大なお金を投じ、そのお金はシステムインテグレータと言われる大手開発ベンダーをいたずらに大きく太らせることになりました。
しかしながら結局は米国など外国のソフトウェアの導入作業であり、データモデリングはもちろん、リレーショナルデータベースの正しい使い方を知らない、しかも特定パッケージへの依存者を大量に生み出すことになります。
当然、データモデリングや正しいデータベース設計のスキルは認識の外にあり、もはや話題に上る事がない点では同じですがが、その理由は随分異なります。(とても残念なことに、それに気づいている人と私は会った事はありません)
日本・米国以外の国
失われた 20 年か 30 年かは良くわかりませんが、緊縮財政と増税路線を始めた 1994年から日本経済の成長はストップし、1990 年代の後半からは、東南アジアや中国の学生の留学先は日本ではなく米国が主流となっていきました。
情報システムの分野にもおいても同じで、日本以外の国は、米国の、データモデリングやリレーショナルデータベースの使い方を含めたコンピュータの使い方そのものを学び、本国に持ち込みました。実際、2000 年初頭に上海を訪れる機会がありましたが、その印象は“いきなりアメリカ”でした。
コンピュータの本来の力
コンピュータがもつ本来の力は、その計算能力や記憶能力だけではなく、ネットワーキングと組み合わせることで、私達が普段の生活で当たり前のように受けている様々な物理制約を排除した論理空間を構築できることにあります。
そして、そのための基本の基が、ノーマライズして 1fact in 1place を追求するデータモデリングであり、リレーショナルデータベースであり、実現するシステムは限りなくオンラインリアルタイムになります。論理空間にバッチなど存在しないからです。米国では常識化しましたが、日本では結果的にではあろうと思いますが、事実上放棄することになってしまっています。
昨今、時々話題にのぼるオントロジー(Ontology)という概念も、アリストテレス時代から知の体系化に向けた連綿とした議論を経て今に至っているようですが、メタ認知を含めたデータモデリングにおけるエンティティとその関係性、データ設計やデータディクショナリーがより広く大きく拡張したものとして解釈し理解することができます。日本以外の外国では企業間取引など各種のコミュニケーションの国際標準化における重要なテーマと位置づけられているが、日本ではその重要性はもちろん意味すら理解する人が極めて少ないのが残念な現実です。
そんな日本で、いつものように、デジタルトランスフォーメーション（DX）が流行り言葉のようになっていますが、その本質は、コンピュータ上にソフトウェア化した企業活動をベースにパートナーや顧客とネットワーキングすることで競争力あるエコシステム（価値創造ネットワーク）を構築し、既存の価値を高め、また、新しい価値を創造していくことであるにも関わらず、日本のコンピュータシステムは、物理制約を前提にした業務手続き（プロシージャ）をそのままソフトウェア化しているので、そのソフトウェア自体が DX の足かせになることに気づく必要があります。
そして、それは、日本だけが持っている問題なのですが、その問題にほとんどの人が気づいていないだけでなく、米国や日本以外の国でも日本がそんなことになっているとは思っていないし、まして、IT 技術者と名乗るほとんど人達がデータモデリングや正しいリレーショナルデータベースの使い方を知らないなどとは夢にも思っていません。
完全に取り残されていますが、取り残されている自覚も取り残しているという自覚もない、つまり日本の IT については国家レベルでメタ認知が欠如しているという、極めて由々しき事態にあると言わざるを得ません。
結構深刻なITガラパゴス問題
このあたりで一旦、日本のITがガラパゴス化している問題については、まとめに入っていこうと思います。
巨額のお金を使って導入したERPのバージョンアップに当然巨額の費用をかけながらも、2010年代後半になると、古くから事業者や生活者に価値を提供してきた伝統的な製造業などでもDXに取り組む企業が日本でも増えてきましたが、AI/センサー/クラウド/BIGDATA/ブロックチェーンなど各種テクノロジーに着目するのは当然としても、一体何をやればいいのかわからない企業が多いのではないかと思います。
Uberやairbnbなどによる既存ビジネスのディスラプションに危機感を持って、何か新しいことにチャレンジすべくデザイン思考やプロトタイピングにトライするタスクフォースもいい。しかし、いかに筋の良さそうなサービスをローンチできて、一定の顧客を獲得できたとしても、マネタイズいかんにかかわらず、スケールアップするのは大変なことです。
バーチャルなサービスならまだしも、リアルな現地現物を持つ実業においては、スピーディーなスケールアップを、それを支えるプラットフォーム抜きで考えるのは現実的とはいえません。
すでにオンラインリアルタイムのソフトウェアをコンピュータに実装し、実際に存在する従業員/取引先/顧客/製品/場所/装置・機器/などと原則リアルタイムにインターフェースして実オペレーションの最適化を何年も追求してきた米国企業や米国をそのまま持ち込んだ企業と、未だに物理制約を受けたままの業務処理手続きを転写しただけのシステム群とERPに夜間バッチでインターフェースしているようなソフトウェアのために、夜間バッチのスケジュールがボトルネックになってしまうような、大多数の日本の大手企業では、強者連合を組むべく経営レベルで連携を合意することはできても、実際にシステム間でリアル連携して動くエコシステムを組むこともできません。また、そもそも各社のシステムも、トランザクションのターンアラウンドタイムやサービスの柔軟性という点で致命的であり、スケールアップ段階でどう転んでも勝てないでしょう。
よく海外製のプロセスマイニングツールやAPIマネジメントツールが日本でも盛んに営業していますが、オンラインリアルタイムのソフトウェアを中心にして業務プロセスを実行している企業が業務プロセスの全体最適化を追求するために有益であっても、日本企業のバッチ中心システムを対象に導入しても、効果はほとんどありませんし、営業の方もそのことをわかっていません。まあ、そんな感じですので、もしトップダウンで入れさせられているなら少々気の毒ではありますね。
つまり根本的な問題は、
エコシステムはおろか個別企業単位でも業務オペレーションのQCDの全体最適を追求するためのソフトウェアになっていない事
論理空間設計能力(最適化したソフトウェアを設計する能力)をもった技術者がほとんどいない事
上記問題に気づいている人がほとんどいない事
(気づいてもらうために書いています)
であります。
問題解決のシナリオ
根本的な問題を解決するのに手っ取り早い方法などはありませんが、今の八方塞がり状態を脱する方法として考えられるシナリオがなくもありません。もちろん、経営陣や主要組織長による、日本企業が陥った根本問題に対する理解と解決すべしという、総論であったとしても、ある程度合意された意思として、意思決定権限をもつ人達に気づいてもらえたのであれば、３の問題については最低限の風穴を開けることができたと言えます。
やはり１の顧客や取引先のレベルにも依存している実業務と絡み合った既存システムの構造的問題と、２の論理空間設計能力を持つ技術者不在の問題は、現実として相当厳しいと言わざるを得ません。
シナリオの一つとして考えられるのが、以下の３つないし４つのことを同時並行で走らせることで、部分であっても早期にDXの成果を確認するとともに、論理空間設計能力をもった技術者や、いままでは曖昧で美辞麗句に近かった全体最適の一つの切り口を知ることができます。そして、それらの活動を通じて、組織的に当事者能力を身に着け、真の全体最適化とエコシステムへの展開に向け、１の本丸、真のBPRに取り組んで行くというシナリオです。
一つ、
基幹業務周辺領域のDXで早期成果創出
顧客接点のデジタル化/生産工程の自動化/BIGDATA＆AI活用による分析の高度化等
一つ、
新事業や新サービスの企画・検討・導入（任意）
一つ、
データレベルで最適化を目指した全社統合DMP構築と活用推進
この活動には、データ設計とデータマネジメント体制作りが必須であり、データモデリングやデータ設計、オントロジーへの拡張を意識したデータディクショナリー作りを通じて、論理空間設計能力を持った技術者を育成していく意味があります。
一つ、
複数部門横断の業務範囲で全体最適化を目指したオペレーショナルエクセレンス(OE)
この活動では、論理空間設計能力習得のOJTを兼ねてノーマライズを追求したテータモデルを作成し、そのデータモデルをもとに全体最適化したシステム設計と業務設計を行い、システムを構築・導入することで、全体最適の意味と価値と運用の要諦を組織知とすることができます。
おわりに
論理空間設計能力を身に着け、真のBPRに取り組んで行くのは、30年以上の遅れを取り戻そうという話しなので、一朝一夕の話しではありませんが、決して不可能な話しでないと思っています。
少なくともケヴィン・ケリーの言う、全てがAIと接続された「ミラーワールド」が訪れる5000日後までには間に合わせたいものです。
この記事が気に入ったらサポートをしてみませんか？