DXって何じゃらほい？或いは2025年の崖っ淵に向かって熊とワルツを踊る刹那について

何週間か前のこと、急にエンプラっぽくないAIベンチャーの社長さんからメッセで飲みに誘われ、秋葉原の焼き鳥屋さんでDXとやらについて聞かれて、とりあえずこのレポート読んどけと返しつつも考えちゃった訳です。Direct Xとか、よくテレビに出てるマツコの方じゃなくて「2025年の崖って実際どうなんだ？」とか何とかオッサンたちから相談される話あるじゃないですか。あれって何なんですかね？オンプレをクラウドにリフトしたらDXなのか。華麗にk8sやらコンテナ使いこなしてCIパイプライン組み立ててテスト自動化したらDXなのか、だいたいDigital Transformationなのに、どうしてDXなのか。SAP R/3とCOBOL PL/Iを捨てて、どこぞのSaaS入れてSparkぶん回してPythonとか書いたらDXなのか。おいおい、そんな話だっけ？って心配になっちゃう訳です。

内製内製って簡単に言うけどさ

そして内製、みんな忘れてるけど1980年代まで日本って内製してて、電電公社なんか新人研修ではDIPSサブセットのアーキに割込命令を追加させたりとか、国産メーカーが互換機つくったら訴えられたからコンパイラから何から書き直そうぜ！とか新人にやらせていた訳ですよ。（途中で和解してPJ中止の憂き目に遭ったらしいですが）でもってスパコンで米国を脅かし、世界のどこもやってないようなリアルタイムの勘定系オンラインを動かして、そいつを何十年もリプレースできずに今日、四苦八苦している訳です。新しく国土交通省がつくったドローン情報基盤システムにDIPSと名付けたと聞いて、おっさん「昭和も遠くなりにけり」って遠い目をしちゃったね。DIPSってほら年金機構で2002年まで動いてたアレでしょ、アレ。富士通から買っても日立やらNECから買っても同じソフトが動くやつ、といっても今じゃ当たり前の話ですね。閑話休題。

時代は内製っていうけど1980年代にプログラマーがン万人足りなくなるといったソフトウェア危機が叫ばれて、様々なソフトウェア部品化やら、ソフトウェア工場をどうするとか、品質管理をちゃんとやらんとねって話になりつつ、コの業界のドタバタもあったけど、結局なんやかんやで時代はパッケージ、COTSを組み合わせろ、カスタマイズは敵だ、業務をパッケージに寄せるんだ、とこの四半世紀くらいやってきて、ブラックボックスの塊をスパゲティで繋いだ聳え立つ糞をあちこち建立してきた訳ですよ。その中でCOBOLプログラムなんかはまだ割と保守しようがある方で、OODBやら4GLやら、VB6やら、シェルスクリプトの塊やら、かつて銀の弾丸と讃えられながらも早々に世間から忘れ去られてしまった数々のロスト・テクノロジーの残骸がある訳です。ぶっちゃけ死屍累々です。憎まれるほど広く長く使われていたら、それは勲章なんです。大概そうなる前に廃れてしまうんだから。

COBOLとかバカにしたもんじゃないのよ若者たち

最近も世界を代表する業界の巨人がk8s経験12年の技術者（k8sの歴史はまだ6年しかない）を募集して話題になりましたが、還暦を迎えたCOBOLとか、四半世紀を生き延びたJavaだとかスゴいんですよ。そーゆーのに囲まれてる会社の人事がk8s 12年の経験者とか探しちゃうのは仕方がない。10年も経ってない青臭い技術を汎用機の巨人が追ってることを褒めてあげたらいい。それにBorg（開発されたのは2003～2004年頃）から数えたら、それくらい経験しているex. Googlerも中にはいるかも知れないし。最近のフロントエンド系のVueかReactかFlutterか？みたいな話を聞いてると、ちょうどJavaアプレットでAWTだけじゃなくKFCやらJFCがあるぞ、こんどSWINGが出るんだって！ってドキドキしていた90年代末を思い出して、このフロントエンド系の諸々が5年後にどれだけ生き残ってるんだろうね？って心配になる訳です。規格としてのLXCは流石に残りそうだけど、Dockerやらk8sが10年後にあるのかも正直よく分からないし、今年書かれたJava Scriptが3年後に動くかも分からないし、いま手元で動いてるプログラムが半年後に同じようにビルドできるかなんて分からない世界を僕らは現に生きているのでしょう。みんな還暦を迎えたCOBOLやら、そこから叩かれるIMSなりCICSを馬鹿にしてるかも知れないけど、いま動いてるLambdaやAzure Functionsが3年後に動かなくなっても、1980年代に書かれたCOBOLコードは10年後も同じように動いてる可能性がかなり高い、悔しいけど。下手すればJavaよりもずっと長生きする可能性さえある。風雪に耐えるとは、そういうことです。そこのイキってる若者君さ、10年後のCOBOLよりも前に、ちょっと前だったら半年後のChainerとか、3年後のFlutterとかCFnを心配した方がいいと思うよマジで。既存のコードが動かなくなるって急速な改善の裏返しでもある訳で。

学びたくないプログラミング言語　まだ現役COBOL

日経XTECHの調査によるとスキルを磨きたい言語の第1位は「Python」エンジニアが学びたいと思わない言語の第1位は「COBOL」となってるけど、これからヨーイドン！で比べた時どっちの寿命が長いか、どっちを学んだ方が結果的に給料が増えるのか、蓋を開けてみたら分かったもんじゃない。

『オンプレをクラウドにすれば？』　そんな単純じゃない世知辛い世の中

エンジニアが足りない、巨人の肩に乗ろうとやってきたこの四半世紀、一世を風靡したRDBMSにロックインされて高い保守料を取られるとか、数年おきにリプレースで大枚はたいてる割に、どんどんシステムは複雑化して改修に随分と時間がかかるとか、倉庫に行けば山ほどExcel帳票を納めたキングファイルが出てくるけど、ちゃんと仕様を調べようとするとソースを解析する他ないとか、そういう様々な理不尽に直面して、この世からバージョンアップとかリプレースがなくなって、全て機械可読なメタデータによって管理することができたら、どんなに幸せになるだろう、とか考えたりもする訳です。データもコードもクリックひとつで別の環境に移してぶん回すことができ、足元を見られることがなくなったら、数えたくもない数のインスタンスのソフトウェアに勝手にパッチが当たってくれたなら、何年もリブートさせていない塩漬けDBクラスタではなく、放っておいても勝手にバージョンアップしてくれる止まらないデータベースをお任せできたなら、どんなにか糞仕事を減らすことができるだろう、とか。クラウドはそんな銀の弾丸になるんだろうか？クラウドの上で内製することは狼人間を撃つ銀の弾丸になるんだろうか？そう考えたところでブルックス翁の警鐘が脳裏で鳴り響く訳ですね。

クラウドは結局のところ規模の経済性という点ではパッケージの延長でしかない。ソフトウェア・コードだけでなく、運用やデリバリーも集約してしまえば、頭数を減らせるし規模の経済性がさらに働く。抽象化されたリソースプールをどう制御するかだけ、利用者は考えれば良くなるし、インフラという名の資源構成も全てコードで定義できるので、手順書やCEがまるっと要らなくなる。チャネルやサポート部隊への依存度を大幅に下げて、少人数でサービスのデリバリが可能となる。それがAWSがA9検索エンジン（ちょっと前まで隠れ採用サイトになってたけど、今はAmazonにリダイレクトされる）をつくったとき、規模の経済でGoogleに負けないために組み立てたオープン戦略・パブリッククラウドのガワの話だし、そういったサービスの提供が可能になった背景にはGoogleが2000年代初頭からやった大量の計算機資源を構造的に組織化する仕組み、それによって運用保守要員を劇的に減らした革命がある。Hotmailが2MBのメールボックスしか提供できなかった時代に、Gmailが1GBのメールボックスを提供できた魔法がある訳です。

ちょっと前までのシステム事情ってもんはよ

曲者はむしろ内製で、直感的にこれは規模の経済に反する。クラウド上ではSaaSを使うのであって、今さら内製とはどういうことだ？だいたいユーザー企業にはコーディングできる技術者なんて置いてないだろう、少なくとも90年代以降はとなる訳です。みんな忘れちゃってるけど1990年代の途中まで、ユーザー企業の中にはコードを書く人がいたんです。役所でも今だって統計とか細々とCOBOLコードを保守してはテストもせずに本番環境で動かして問題を起こしたりしている。コードを書かなくなったのは、オープン化でパッケージを入れるように方向転換したこともあるし、大昔の話をすれば電電民営化まではNTTデータに頼むことも「内製」だったし、その頃のようなズブズブの関係って21世紀初頭までデ通サとして残っていた訳です。予算要求もせずにポンポン依頼をするとつくってくれて債務が溜まっていく、今になって振り返ればガバナンスもへったくれもないけれども、その頃までは小さな取引コストでちょこちょこシステムを直していくことが簡単にできた。

当時のベンダーロックインというのは、そういった契約関係であり、汎用機アーキテクチャでメーカーが違えばミドルウェアからプロトコルから全て違ってソース互換性もない、そういうゴリゴリのロックインがあったんです。IBMがSNAをつくったら、似たような思想で富士通はFNA、日立はHNAをつくって、それぞれ繋がらない。今時のサーバーレスなんてたまたま標準化されていないところで似たようなアプローチをしているだけで、みんな一応IPとかHTTPとかJSONを喋っている訳で、まあ笑っちゃうくらい似たようなもんです。ベンダーロックインとは、そんな生易しいもんじゃない、借金と本当の独自技術と無数の貸し借りと業務に対する深い暗黙知で逃げようがないくらいまで囲い込むんですよ。とりあえず決まってないんでエイヤでつくっちゃいましたーってオープン系なりサーバーレスの方言とは次元が違う。

オープン化が必ずしも悪い話ではない。世界中で起こったことだし、計算機資源が安く手に入るようになったのは基本的にいいことです。その上にクラウドとかの新しい技術だって花開いた訳ですから。日本にとって不幸だったのは、それがバブル崩壊とその後の失われた20年と重なっていたことと、米国からの圧力による自由化によって社会の様々なところが流動性を前提に組み立て直された中で、雇用だけが判例法理と大企業の過剰コンプライアンスによって維持されて、経済の縮小に合わせて既存の従業員を切ることができず、一方で膨れ上がるシステムを自社組織で賄えずにSIベンダーへの依存度を強めていったこと、その過程で業務構築とシステム設計とが分離して受発注の関係に置き換わり、ノウハウが蓄積されにくい産業構造となった時期にパッケージのブラックボックス化とシステムの肥大化が進んでいったことなのかも知れません。この辺はまだ調べている途中で、1990年代後半に入ってからのことは物心ついて自分の目で業界をみてきたつもりだけど、前半くらいのことは世間知らずの中学生が親父が家に持って帰ってくる日経コンピュータとか日経オープンシステムを読んで耳年増になっただけなので、もっと多くの人たちからオーラルヒストリーを聞かないと、正直よく分からないと感じています。ここのところの生き証人はまだみんな全然現役でしょうから是非いろいろ教えて下さい。このご時世だから秋葉原の接待を伴う飲食業の並びにある焼き鳥屋でも歌舞伎町の地下でホストが握ってくれるカウンターのお寿司屋さんでもなく、今はZoomとかdiscordで飲みましょう。

2025年問題とDXの本質

結局のところ内製といっても、これまでパッケージで提供されていたものを手で書き直すという話ではない。あくまで90年代以降のオープン化の時代、たまたま日本においてはSIer任せになっていたシステム設計やデプロイの手数を、もうちょっとユーザー企業側に取り戻そうという動きと捉えた方がいい。何故そういった動きが出てきているかというと、昔のように「入れポン」でベンダーに丸投げして導入がうまくいかなくなってきたということ、資源管理の自動化によってデリバリの敷居が下がり、SaaSベンダーもユーザー企業のエンジニアによる導入のレベルに合わせたパッケージングを行っていること。昔と比べてデリバリに必要なバッドノウハウが減って、一方で毎月のようにコロコロと画面構成なんかが変わってしまうので、マニュアル化して横展開というのが難しくなった。マニュアル通りにやるのではなく、英語で自分で情報収集して、自分の頭で操作する人じゃないと手に負えなくなっちゃった、どんどん便利で欲しいものが提供されてるのに、間にSIerを噛ますとできませんといわれたり、勉強分の工数まで請求されちゃったり、見積もり通りの工期・費用で収まらなかったり、勝手にバッファを積まれたりというのがバカバカしくなってきて、委託ではなく準委任でやるか、お勉強のために準委任で高い人月単価を払うくらいだったらエンジニアを雇っちゃったほうが合理的じゃないか、少なくとも教育コストを投じるんだったら、そのエンジニアを囲い込んだ方が結果として安上がりだろう、と考えても無理からぬことでしょう。

この文脈において何故、海外に於いてDXという議論にならないかというと、もともと直接雇用が当たり前なんです。少なくとも米中英あたりにおいては。大陸の独仏なんかは日本と同じように雇用保護が強いので、IT人材のキャリアパスをどうしてきたのか、改めてどこかで勉強してみたいと思ってるんですけれども、どなたか教えていただけますか？どちらも日本ほど急激な成長の鈍化を1990年代に迎えた訳ではないし、もともとスキルや資格を重視する社会なので、日本の1990年代のようなことは起こらなかったんじゃないか？と推察します。つまり日本がDXというバズワードで克服しようとしている産業構造の特質は、割と日本固有の歴史的経緯の中で生じたことであって、実はあんまりクラウドとかAIの活用とは直接には関係ないんじゃないか？たまたま90年代のバブル崩壊後の緊縮＆情報化とともに肥大化してきた情報サービス産業が、1990年代から2000年代にかけての雇用絞り込み・情報化投資増加の時期に独特の役割を果たしてきたものの、その事業モデルが立ちいかなくなりつつあって、ユーザー企業も従前のセールスチャネルに対して丸ごとお任せするという発想から脱しつつあるのかも知れない、そんなこと本当にできるのか？というのが日本固有のDX議論なのかなあ、と考えると、米欧で似たような議論にならない理由も分かろうというものです。

私の僕としての計算機、計算機の僕かもしれない私

悔しいかな、人減らしの口実に使われてしまうのは計算機システムの業というものらしく、かつて高邁な哲学があったはずのBusiness Process Re-engineering (BPR)なりRe-stracturing（いわゆるリストラ）がそうであったように、もう5年くらいするとDXもといDigital Transformationもまた、運用保守要員やらコードの書けないテスト要員やら顧客対応要員をクビにすることの隠喩となってしまうかもなあ、という心配があります。ちょっと前の外資だとOptimizationとかいったらしいですね。「何を研究してるの？」「GPGPUをtargetにした並列コンパイラのoptimizationで」という何気ない会話で、最適化されるのが冗長なコードなのか、高速化によって要らなくなったGPU時間なのか、手動でコードを最適化してきた職人さんの工数なのか、思いを致すとかね。「そういえば最近アイツみないよね」「どっかにtransformされちゃったんじゃないの？」みたいな会話はしたくない訳です。

しかしどんなにExcel帳票を束ねて積み上げたところで誰も管理できない、質の低い伝言ゲームをなくしていくためには、機械で処理できるものは機械に処理させるというのを突き詰めていけば、人間の仕事というと機械に処理できないやるせない感情を受け止め、法律上は自然人しか負うことのできない責任を負い、機械が自らつくることができない機械に食わせることのできる入力を創出するとか、そういう機械には手に負えない残滓ばかりが人間の仕事として残っていく訳です。ぶっちゃけ機械をイビッたところで気が晴れないんだから、怒れるお客様のところにはネクタイ締めて人が謝りにいく必要があるんです。ブラウザに鯨の漫画とか癒されそうな犬の写真を出しておくだけじゃ終わらんのです。リビングにおわすルンバ様のためにお片付けする家事のお仕事バージョンですよ。ルンバを買って床を掃除させている自分が主人なのか、ルンバが機能するよう床をきれいにしておかなきゃならない自分が奴隷なのか。そこまでは何となく自分が主人のような気がするけれども、じゃあ他に主人がいて「君はルンバにできないあらゆることをやってくれたまえ」といわれた瞬間に、お得意な仕事を選べるルンバ君と、選べない自分との上下関係が難しくなってきます。

そして箱売り、人売りの果てに直面する現実

振り返るに東京オリンピック以降さまざまな事務に計算機が使われるようになって、それからの四半世紀くらい内製の時代が続いた訳です。その時代の端っこを見ていた記憶が辛うじて残っていて、人とシステムが一緒に歳をとって、偉い人がその世代だから、この技術を選ぶみたいなことが起こる。自分が何を使うか決められるところで、システムごとお払い箱になりたい技術者なんていないんです。90年代に起こったオープン化というのは、ああいう属人的な世界は嫌だね、中で人を抱えずに全てベンダーに任せたら、もっとお手軽にシステムとか捨てて新しい技術に飛びつけるんじゃないの？これからはゴリゴリつくるんじゃなくて入れポンがいいんだよ、入れポンが、という安直な考え方があったんじゃないかと思います。それで個々のシステムはパッケージなんだけど、機械同士でよしなにできるところは自動化して、とやっていくと、徐々にレガシー資産が溜まってくる。パッケージそのものは汎用品でも、パッケージとパッケージを繋いだ塊でみたら一品ものであって、そうそう簡単には置き換わらない訳です。それどころか期限を設定されて、いついつまでしかサポートしませんとか、脆弱性があって危ないから使い続けないでくださいとかいわれて、似たようなものをつくり直すだけのはずが数年おきに巨額の請求書が回ってくる。あれ！俺たちが望んでいた入れポンってこれだっけ？と四半世紀も経ってハタと気付く訳です。で、リフトシフトだ、クラウドだ、俺たちはバージョンアップから解放されて、サブスクリプションを払えば済むようになる！これはきっといいことだ、1年半も前から基盤の移行計画を立てなくても、ワンクリックで数十秒もあればサービスが建っちゃうぜ！DX！DX！NO SOFTWARE！Serverless！何とかon demand！というシュプレヒコールが上がる。で、自分たちは実際のところシステムの複雑さと、生身の人間から解放されたのか？全くそんなことはない。やっぱりシステムは雲の中ではなく世界のどこかのデータセンターに潜むウォンウォンとファンが唸るサーバーの中で実行されていて、そこに書かれたコードはどこぞのGitHubに転がっているかも知れないけど、何故そう書かれているかは誰かの頭の中にしかなくて、そいつが退職した時「あれ？これどうなってたっけ」と聞いたって、クラウドサービスのコンパネから可読性の高いポンチ絵が出てくるはずもなく、まるっと設定をエクスポートするにしても、無数のクリックを繰り返すにしても、複雑なシステムが複雑であることには変わりない、でも実際に動いてるものと一致した構成ファイルが取り出せるのは幾分マシじゃない？とはいえ複雑なもんは複雑なんだよ、頑張って簡単にしたところで担当者の脳味噌が耐えられるところまでは複雑化し続けるんだよ、ということが起こる訳です。

じゃあDXに全く意味がないのか？一昨年リースが切れたサーバーをもう何回か契約延長すればいいのか？というと、そんな話でもない。10年おきぐらいに式年遷宮を繰り返して、業務なりを継承しながら、今ある最適な道具で諸々を設計し直す営為の中で、事業遂行に必要な情報システムをつくり、書き換えられる体制を維持していくしかない。結局のところ私たちはレガシーとかオープンシステムに騙された訳ではなく、何でもカネで買えると勘違いして、業務を組み立てシステムを構築し、オペレーションを回していく人を育てることを怠ってきたところが、因果応報で身動き取れなくなっちゃっただけであって、誰かが何か騙してる訳でも、悪徳ベンダーがぼったくってる訳でもないんだよ。そんなに割のいい商売だったら決算書に現れてくるだろう、とまで考えたところで現実に引き戻される訳です。（ひとやすみ）