中谷 話は変わりますが、デジタルネイティブの話をします。物心ついたときはインターネットが当たり前だった世代が新しいビジネスを考え出す、クリエートしていく。思いついて実行するには、ＩＴシステムの技術的負債を解消して、新たなデジタル技術を導入し、データ活用などを通じたスピーディーなビジネス展開ができるようにする、方向転換やグローバルなビジネス展開がスピーディーにできる。そのようになっているのがＤＸの将来像だ、と『ＤＸレポート』には書いてあります。
みんなで落ちれば怖くない、という話じゃない
中谷 ＤＸを躊躇するユーザーがいると、それに引きずられてＩＴベンダーも動けなくなるんですね。ユーザーが保有するシステムを保守するために技術者を割り当てなければなりません。そうなると、ユーザーと一緒にＩＴベンダーも潰れていくんですね。２０２５年の崖から転げ落ちていく企業が多いと、ＩＴベンダーも落ちていきます。みんなで落ちれば怖くない、という話じゃありません。だからなんとかしなくちゃいけない。
それではＤＸの焦点は何か、システム刷新の意義についてですが、たぶんですね、ＤＸによるメリットを理解し認識することが大事でして、そのためにはＩＴ部門ですとかＩＴ技術者が頑張ればできるというものではありません。なんといっても、やはりエグゼクティブが決断しなければならない。そこに働きかけないと。研究会ではそのような議論が交わされました。
もう一つは、ＩＴシステムが肥大化して、全体が見えなくなっている。ＩＴベンダーに丸投げして、システムがブラックボックス化しているという話とは別に、ユーザーが自社のシステムを理解できないという問題です。情報システムのリソースを見える化しましょうという話ですが、要求工学をやっている者としては、これ、いまごろなんですか？ です。仕様書、設計書がないまま、保守を続けてきたんですか？ 保守の記録を残さないんですか？
見える化のアプローチでは、他社と比較できるようにしましょう、ということがあります。他社がどのくらいの予算と人、時間をかけてシステムを構築しているか、どのような効果を出しているか、保守と新規開発の比率はどうかetcを比較できるような仕組みが必要ですよね、というわけです。それがガイドラインにつながっていきます。
「ＩＴ人材」の定義が間違っていないか？
中谷 ＩＴシステムの刷新で、さきほど「クラウド・ファースト」と申しましたけれど、すべての企業がクラウドにあるアプリケーションを共同で利用すると、サービスまで同じになって競争原理が働かない。ではどうするかというと、競争優位に寄与するアプリケーションと、競争と関係がないシステムを切り分ける。競争優位に寄与するアプリケーションは自社でオンプレミスで持っていなければいけませんけれど、給与計算とか配送管理とか、すでにパッケージで対応しているシステムならクラウドで共同利用型にしたって構わない。
そのとき必ず出てくるのが「ＩＴ人材不足」という話でして、ちょっと前に同じような話をする機会がありまして、盛り上がったのは、いつまで人材不足って言い続けるんですか、ということでした。１９８０年代には「１００万人足りない」って言ってました。いまは５０万人ぐらい足りない、でしたっけ？
これを見てますと、どうもね、「ＩＴ人材」の定義が間違っているんじゃないか、と思うんですね。仕様書や開発プロセスやリソース・マネジメントなんかをちゃんとやれる人がＩＴ人材なんであって、残念ながらコードを書ける人、プログラミング言語が使えればＩＴ技術者、ＳＥと呼ぶような間違った認識があるような感じです。
これはわたし個人の見解ですが、ＩＴベンダー、とりわけソフトウェアの開発や保守を受託している会社は、人／月が商売のベースですから、売上げを上げようとするとたくさん仕事を受けないとダメですし、長時間就労が恒常化します。そうなると新しい技術を習得する時間がなくなってしまう。もっとも企業は技術者の教育費をちゃんと計上していないんで、Ｒ＆Ｄをやる環境がないのも問題です。
なので、この現状をひきずったままＤＸに突入しても、それが多重下請け構造の解消につながるかどうか、ちょっと疑問です。ここはやはりユーザー企業のエグゼクティブが、自社の立場ではなく、「日本」の立場でＤＸを決断して、システムの刷新、クラウド・ファーストを推進してもらうしかありません。
フィジカルＤＸはあちこちで実現している
中谷 ＤＸはしばしばＡＩだのＩｏＴだのＲＰＡだの、新しいキーワードで語られるんですが、もう一つ、ＤＸのイメージがあります。それはプラットフォームを提供するＩＴ企業、別の言い方をするとＳＩｅｒですね。彼らが提供するプラットフォームに、規模は小さいけれど専門技術や分野特化したＩＴ企業がコンポーネントを提供する。コンポーネントとはアプリケーションと言い換えてもいいのですが、クラウドで共有するのは競争優位とは関係ないシステムですから、インターフェースだけ標準化しておけばいいし、カスタマイズはしない。
時間とともにビジネス環境が変わる、新しい技術が登場するのはこれまでと同じですが、適応保守はコンポーネントを提供するＩＴ企業がやるので、ユーザーは社内のＩＴ人材を保守に割かなくてよくなるし、費用は割り勘なので安くなる。ＳＩｅｒが提供するプラットフォームを、ユーザーとコンポーネント・ベンダーが共有するんです。実はこれ、今に始まったモデルではなくて、ショッピングモールとか名店街とか、みんなこれです。ネットではアマゾンや楽天、ヤフーなんかですね。
それで、共通プラットフォームですが、これはすでに実現されています。アマゾンのＡＷＳとかマイクロソフトのＡｓｕｒｅのことではなくて、やっているユーザーがいるという話です。例えば、自動車の自賠責保険。昔は保険会社が個々にシステムを作って運用していたんですが、自賠責保険ってどこも同じなんですね。そのことに気がつき、損保会社６社とＩＴベンダー３社がタッグを組んで、保険料徴収業務とか証明書などを管理するシステムを共有化したそうです。
経産省がこれから手をつけるのは、上下水道管理システムです。厚労省もかかわって実証実験をやることになっているそうですが、人口が少ないのに面積が広い村や町が、少ない予算で上下水道を運営管理していくのはそろそろ限界です。水道管とか下水処理設備の老朽化に伴う交換コスト、人員の高齢化、利用料金の上昇抑制といった課題がありますし、個々にシステムを運営管理するのはたいへんなんで、共通化しましょうというわけです。
地銀共同センターというのもそうですが、こういうのも「あれ、前に聞いた話だな」ということに気がつきます。朝日、キリン、エビス、サッポロのビール４社が、北海道でビールの共同配送をしているなんていう物理的な事例もあります。味で勝負しているんだ、届け先は同じだし、じゃあ配送は共同でいいじゃん、ということです。昨年の１１月には、商品を載せて移動するパレットの回収を共同ですることにも踏み切ったということです。
コールセンターなんかもフィジカルなＤＸです。日本のどこかに電話をかけたつもりでも、実はベトナムだったりして、しかもそこにはＡ社、Ｂ社、Ｃ社の受付担当がいて、それぞれの対応をしている、なんていうことが珍しくありません。クレーム対応とか操作方法の案内などは、競争優位のキーポイントではありませんからね。
いよいよソフトウェア工学の時代
中谷 ＤＸのカギは、繰り返しになりますが競争優位に寄与するシステムと、共同化しても競争には関係ないシステムを切り分けることです。このとき留意しなければならないのは、可変要素が多いか少ないか、それが最初から分かっていれば、もっときれいな設計図、仕様書を書けたとは思われますが、とりあえず作って、動かしながら不都合を手直ししてきたという反省に立たなければなりません。
「ＤＸガイドライン」……つまりこれから出てくるのでまだ存在しません。そこに「ＤＸをどう進めるか」が書いてあるはずなんですが、どこにフォーカスするかとか、評価基準ですとか、それを読めばいいと思いますので、経産省が公表する資料に注目してくださるとよろしいかと思います。
その前にやっておかなければならないのは、既存システムの価値分析、企業の強み・弱みの分析です。エクセルではなくて、クラス図でモデル化する。シーケンス図でヒトとヒトの関係、組織と組織の関係、モノの動きなんかを見える化する。わたしの立場で言うとそういうことになるんですが、やり方は一つじゃなくて、いろいろあると思います。
そのとき開発プロセスはどうなるのか、を考えてみます。ＤＸはこれまでにやったことがないアプローチでもあるので、試行錯誤が前提になります。既存システムの価値分析をやって、「じゃ、この機能はクラウドに上げちゃいましょう」ということになるんです。最初から分かっているわけではありません。いったんクラウドに乗せる、共通コンポーネントを使うことにしたんだけれど、よくよく考えたら、此、戦略的なシステムだった、なんていうこともあるでしょう。だから、失敗を恐れない、失敗を許容することが重要です。
とすると、開発プロセスはアジャイルなんじゃない？ という話になってきます。ただ、規模の大きな案件をアジャイルでやって、プロジェクト・マネージャーがどこまで掌握できるかという問題はあるかもしれません。それも含めて試行錯誤なんだと思います。実際は開発・運用の現場では、すでに行われているんではないかな、とも思います。
経産省は、業界団体で取り組むことを推奨しているようです。業界のリーダー企業が牽引役になってくれないと、せっかくのコンポーネントを利用する企業が少なかったら運用・保守のコストが安くなりません。みんなで進まないと、意味がない。という意味では、中堅・中小の企業が集まるというのもアリかな？ と思います。
ソフトウェア工学の世界では、１９８０年代から９０年代にかけて、フレームワークとかコンポーネントとか、部品化・再利用とか、われわれは言っていました。ユーザーのＡ社、Ｂ社、Ｃ社からそれぞれ受注するんだけれど、みんな同じだな、というところは共通化して、差異の部分をコンポーネントで提供したらどうなの？ という話です。共通性、可変性、不変性を整理するには、デザイン・パターンの考え方が必要です。
システム設計のとき、データはどこに置くのか、そのデータを使うアプリケーションはどこでどのように動くのか、それをきれいにしておかないと、アプリケーションとデータをバラバラにメンテナンスすることになってしまいます。アプリケーションとデータの結合度はできるだけ低くしましょうというのがソフトウェ工学、ないしシステム工学の見地からの指摘です。
それと、クラウドのプラットフォームというのは、プロダクト・エンジニアリング、プロダクト・ライン開発の考え方で捉える必要があります。最初に作ったシステムを適応保守ないし派生開発で改良していきますと、コア・アセットは何かが見えてきます。そうか、これをプラットフォームに乗せればいいんだ、ということが分かります。
この部分は意見がわかれるところですが、ソフトウェアの保守はハードウェアと同じように、開発した人と保守する人を分けなければならない、あるいは別の人でも同じようにメンテナンスできるようにしなければならない、という意見があります。アジャイル開発の観点からすると、開発と保守を別々にできるかどうか、ちょっと考えなければなりません。試行錯誤で作って行きますので、どこが可変部分なのか、どういう設計思想なのか、担当者が変わると伝わらないかもしれません。いまは８割が保守なので、開発と保守は担当者が別々にならざるを得ない事情があるともいえます。
ＤＸが広がった世界では、ＩＴ技術者に相応の見返りが与えられるでしょう。そうしなければいけない。いまＩＴエンジニアの平均年収が６００万円ですか？ それを倍にするんだ、と『ＤＸレポート』は言っています。いよいよソフトウェア工学の時代がくる、というわけです（笑）。みなさん、いまこそソフトウェア工学です、と強調しておきます。以上です。ご静聴、ありがとうございました。（拍手）
