2021年度JEITAソフトウェアエンジニアリング技術ワークショップ「デジタルトランスフォーメーションとソフトウェア開発」開催報告

電子情報技術産業協会(JEITA)ソフトウェアエンジニアリング技術専門委員会は、ソフトウェア開発技術の調査・研究活動を行っています。その活動の一環として毎年、JEITA会員に閉じないオープンなイベント「ソフトウェアエンジニアリング技術ワークショップ」を参加費無料で開催しています。
今期は、去る1月28日（金）に「デジタルトランスフォーメーションとソフトウェア開発」をテーマに、昨年度と同じくオンライン開催しました。なお、これまでは毎年12月に開催していたものを1月に変更したことで、タイトルを「2021年度JEITA…ワークショップ」に改めています。
少し時間が経ってしまいましたが、[2018年のブロックチェーン](https://qiita.com/yuki-yoshida/items/2f578fdf2eeca44c335f)・[2019年のクラウドネイティブ](https://qiita.com/yuki-yoshida/items/0065fdf7df2122530017)・[2020年のプログラミング言語の進化と未来](https://qiita.com/yuki-yoshida/items/74312d76496766f6cb1f)に引き続いて、企画サイドの立場からその内容を報告します。

# 公式サイト
3月末日まで、講演資料と録画を公開しています。
[https://home.jeita.or.jp/cgi-bin/page/detail.cgi?n=1379](https://home.jeita.or.jp/cgi-bin/page/detail.cgi?n=1379) 

# 開催趣旨
Software is eating the worldと言われて10年、まさにあらゆる産業がソフトウェアによる変革を促される時代になっています。2018年には経済産業省が『DXレポート～ITシステム「2025年の崖」の克服とDXの本格的な展開～』を発表し、大半がレガシー保守に投入されているIT投資をビジネス変革に振り向けることの重要性を指摘しました。一方で一昨年来のコロナ禍において、我が国のデジタル化の立ち遅れが明らかになった結果、官民を挙げての早急なデジタル化の取り組みが始まり、その先のターゲットとしてデジタル改革（DX）を目指す動きも顕著になっています。
本ワークショップでは、先進的なソフトウェアによって新たな顧客価値・社会価値を迅速に生み出すことが求められる時代において、機能設計・アーキテクチャ設計・開発手法・開発体制・人財育成等にどんな変革が必要なのかを議論しました。

# プログラム内容
プログラムは、基調講演、技術講演3件、総合討議（拡張Ｑ＆Ａ）から構成しました。
この記事では、まず事前収録で実施した4件の講演の概要を簡単に紹介してから、最後にリアルタイムに実施した総合討議の内容について主に紹介します。（講演内容の詳細は、上記サイトで期間限定公開中の講演資料をお早めに参照ください）

## 基調講演　DXとソフトウェア開発の課題
名古屋国際工科専門職大学　山本修一郎教授

山本先生は、経済産業省のDXレポート策定に当初から参画されています。
基調講演では以下の４つのテーマについて解説いただきました。
- デジタルプラットフォーム（DP）
「デジタルプラットフォーム」とは、一般に、IT＆データを活用して利用者間を結び付ける場を提供するサービスのこと。講演では、これがGAFAM等が提供する汎用DP、産業別の共通DP、および企業固有DPの三層に別れ、その上にアプリが乗る構造が主流になって来ていることを指摘。
- アジャイル開発
ソフトウェアの受託開発が主流の日本においては、今後のベンダ企業は、ユーザ企業とアジャイルな考えを共有するパートナーに移行していく必要がある。
また、テレワーク拡大によって、非対面型のアジャイル手法が課題になって来ている。
- DX人財
経営変革(ビジネスモデル)、ビジネス変革(業務プロセス)、IT変革(デジタル化)を明確なビジョンを描いて牽引・実行できる、という非常にレベルが高い人財が必要。
- ガバナンス
アジャイルやマイクロサービスの採用で、一組織の中に多数の小規模開発チームが存在するようになるので、技術・要件・品質等についてこれまで以上に全社的なガバナンスが重要になる。

## 技術講演１　マイクロサービスアーキテクチャーと最新OSS/Javaエコシステムで変わるソフトウェア開発 ～クラウドネイティブからコンテナネイティブへ～
富士通株式会社　数村憲治氏

数村さんは、Javaの標準化活動に当初から参画され、講演の中で紹介されているJakarta EEとMicroProfileの委員として、Javaのクラウドネイティブ対応の標準化を推進されています。
- クラウドネイティブ（CN）の歴史
    - クラウドネイティブ1.0：Cloud Nativeという言葉が提唱された2010年から16年まで。Twelve-Factorを様々に試行していた時代。
    - クラウドネイティブ2.0：2017年以降。コンテナ活用が本格化し、コンテナ技術を使ってTwelve-Factorを実現。
- Javaとマイクロサービス
    - 企業内のIT資産や人財を活かすために、クラウド化でもJavaの利用が多数
    - GCや動的コンパイラを持つJavaのランタイムについて、コンテナのサイズ縮小・起動性能確保のために軽量化技術が進展
- Cloud Native for Java（CN4J）
    - Eclipse FoundationによるクラウドネイティブJava技術標準化 = Jakarta EE + MicroProfile
    - Java技術者のスキルを活かしたマイクロサービスアプリケーション開発が可能
    - Twelve-Factorすべての実現が標準的に可能になった

## 技術講演２　ローコードで実現する開発内製化～Microsoft Power Platform～
日本マイクロソフト株式会社　平井亜咲美氏

平井さんは、Microsoft Power Platformのプロダクトマーケティングを担当されています。
- 全世界で働き方の変化によってDX需要がさらに増加
    - 今後５年間で５億個のアプリ開発が見込まれ、開発者が100万人不足する
    - その結果、優先度が低く改善が後回しにされる業務が、個人の生産性の阻害要因となる
- ローコード開発
    - ビジネス部門が自ら必要な開発が可能、あらゆるデバイスにすぐに展開可能
    - MS Power PlatformはPower BI, Power Apps, Power Automate, Power Virtual Agentsから構成
    - Fortune 500企業の97%が利用
- Power Apps
    - キャンバスアプリ、Power Appsポータル、モデル駆動型開発、Dataverse for Teamsの４機能
    - 開発事例：経済産業省で後援名義申請アプリを内製化し試験運用中
    - 開発事例：日揮の新入社員が開発した残作業管理アプリで５億円効率化

## 技術講演３　SREホールディングスのDX展開とバーティカルSaaSの創出
SREホールディングス株式会社　角田智弘氏

角田さんは、SonyのDistinguished Engineerを務められ、SREホールディングス（旧ソニー不動産）創立時から役員として技術開発をリードされています。
- 日本のDXにおける課題とSREの取組み
    - 日本のデジタル競争力低迷の課題はスピード、法制度、人財
    - SREホールディングスでは、「リアル✕テクノロジー」、トップダウンな組織連携、週次のPDCA、積極的な中途採用、DX貢献度によるアワードや人事評価、といった取り組みをしてきた
- SRE創業からDXグランプリ受賞までの道のり
    ① スマート化：リアルビジネスにソニーのAI・IT技術を適用
    ② プラットフォーム化：同業他社に展開し、ビッグデータを蓄積
    ③ スケール化：他業種のパートナー企業のDX事業へ展開
- 不動産領域におけるバーティカルSaaS事例の紹介
    - AI不動産査定：査定時間180分→10分、誤差率7～8%→5～7%
    - AI与信審査：顧客の信用度をAIで算出
    - 富裕層判定：顧客の証券取引情報と不動産データを合わせて潜在富裕層判定

## 総合討議（拡張Q&A）
（司会）ソフトウェアエンジニアリング技術専門委員会　幹事
ジャパンシステム株式会社　チーフテクノロジーアドバイザー　吉田裕之

例年このワークショップでは、最後に講演者と聴講した皆さんによるディスカッションの時間を取るのが恒例になっています。委員会委員からの質問の他、当日の聴講者からはチャットで質問を受け付けました。最初に、４名の講演者に共通するテーマについて議論していただき、続いて３つの技術講演を順番に取り上げ、最後にまとめを兼ねて基調講演についての議論を行いました。
（以下、発言者の敬称は省略させていただきます）

### ・デジタルトランスフォーメーションとソフトウェア開発
#### DXでソフトウェア開発はどう変わるのか
吉田（委員会幹事）：
DXを実現するソフトウェアの開発は、今までとはどこがどう違ってどこを注意しないといけないのでしょうか？

数村:
スピードが大きく違う。スピードを上げるための手段は色々あって、例えばテスト自動化は当たり前。人が実施するのはコーディングとレビューだけになるくらいにする。そこで重要なのは自動化の完全性、つまりCI・CDに乗せていくことが非常に大きなポイントになると思う。OSSコミュニティを例にとると、凄いプログラマがいて凄いプログラムを書けるのだけど、それをCIのパイプラインに乗せるのにかなり苦労していることが多い。これからは単にプログラムを書くだけでなく、デリバリするところまでを一貫してできる技術を持つことがポイントになってくると思う。

平井：
スピードという点には本当に共感する。DXの需要自体が爆発的に伸びているので、そこに応えていくためにはスピーディーにアジャストしていくのが非常に大事。その中でキーワードとしてあがってくるのが、人財が足りない、実行できるエンジニアが足りない、ということでローコードプラットフォームも普及してきている。多くの企業で課題として聞かれるのが「人財育成」であり、DXを一部の人だけがやるのではなくて、社員にリスキリングをして会社全体でやっていこう、皆がリテラシーを少しでも上げてやっていこう、ということがこれからのDXを促進していく上で大事。

吉田：
平井さんのご講演で５年間であと５億個のアプリを作らないといけないと。え？毎年１億個か、と思いました。

平井：
それにつれてデータの生成量も凄く伸びていくので、それをどう使うか、それをどう溜めていくか、が非常に大事になっていく。

角田：
人財育成にも関わるが、やはりソフトウェアを開発するエンジニアが、新しい市場を作って行こう、新市場を創出してDXをどう進めていくのか、という意識を持つことが非常に重要。技術的な興味だけではなくて、その技術を用いて新しいイノベーションを行ってビジネス展開を行いたいという思いを持っていること、まずそれが非常に重要。その上で、そういったマインドセットを持ったエンジニアが、DXを実現したい実業側、ビジネス側にも入り込んで、その実業側のメンバーとコミュニケーションを取るスキル、そこで実際に何が課題のクリティカルなコアなのかを理解することが重要。また、ビジネス展開を加速するという観点では、BizDevOpsという形で、ビジネスメンバーを巻き込みながらサービスでのフィードバックをいち早くソフトウェアに反映していく、そういう開発スタイル・運用スタイルが今後DXを実現する上で非常に有用になっていく。

吉田：
角田さんのお話では具体的な開発手法については触れられなかったですが、やはりデフォルトとしてアジャイルなのでしょうか。

角田：
アジャイルで開発していて、だいたい１週間のイテレーションで複数のチームが回っている。

吉田：
今日のお話では、最初の社内向けに作ってそれを外に展開するという方向で発展されていましたが、外に展開する時に、例えば今言われていたデリバリのスキルがいきなり必要になったりすると思います。そこはまた新しい人を導入したりするのですか？それとも今までの人が頑張っているのでしょうか？

角田：
それぞれ強みがあるエンジニアがいるので、新しく入ってもらった人もいるが、縦割りにしてしまうと自分は関係ないみたいになってしまうので、チームの中で機械学習が強い人間、バックエンド、フロントエンドを書く人間と、オペレーションをやる人間とがいっしょになるチームフォーミングをやる形。

山本：
皆さんがおっしゃる通りだろうと思うので、ちょっと違う視点で今までのソフト開発との違いについてお話すると、やはり「ビジネス価値」を創出しなければならないので、今までのソフト屋さんでは無理。それが一番大きい。それから数が圧倒的に増える。５億個と言われたらどうやってガバナンスするのか、つまり作るだけでは終わらなくなる、統制をとらなければいけないので。ローコード開発というキーワードは耳に心地いいが、終わった後が大変なことになる可能性がある。30年前にはエンドユーザープログラミングと言われていて、現場の人が勝手にソフトを作るが、作った後、その維持管理がどんと回ってくる時があった。ひどいスパゲティ状態になる可能性があるので、最初からガバナンスを効かさなければ駄目。すると次の問題は、欧米ならまだガバナンスルール等を作れるが、日本企業は「それはなんですか？」みたいな人がたくさんいる。まずガバナンスの原則をちゃんと書いて、それは物凄く抽象的なものになるが、それを具体化しなければならない。理解して、自分がおかれたビジネスの現場でどのようなガバナンスが必要になるかという、具体化する能力・抽象化する能力を相互に回すような能力が必要になる。逆に今までのソフト開発は、言われたことを作るだけだったから、ガバナンスはアウトオブスコープだった。できているものを実装するだけだった。これから大変なことが起こると予想される。

### ・平井さんの講演に関して
#### 膨大な数のアプリの管理
吉田：では、その件に関係が深い平井さんのご講演に関する議論に移ります。

牛山（委員会委員）：
まさに今のお話で、野良アプリと言われているものをどうしたらいいのかが、企業としての悩みです。

平井：
まさに皆さんが最初にご心配されるのは、エンドユーザーコンピューティングの時代のように、データベースが乱立、アプリケーションが乱立して、管理できなくなってしまう、ということで、今でもお客様にピンポイントでご意見をいただいている。Microsoftは世界中にお客様がいらっしゃるので、大規模に導入されているお客様から色々と学んだことをガイドとしてまとめたものがあり、「COEスターターキット」と呼んでいる。COE：Center of Excellenceは、中央集約的にガバナンスを効かせる組織・体制をちゃんと作り、ガバナンスのルールを作って、その中で運用できるように、管理された状態を保ちながら使っていくという考え方。クラウドプラットフォームのメリットでもあるが、Power Platformは完全なクラウド型なので、作られたアプリケーションが誰に使われているか、どういうユーザが使っているか、データ間の接続をすべてコネクタで行うが、どういった種類のコネクタが使われているか、それらが全部見えるので、このアプリケーションの中でどのデータが使われているのかが見えるようになる。そして、コネクタを環境毎に制限できるので、組織内で検証環境・本番環境をもちろん分けることができるし、ユーザの規模や部署によって環境を分けることもできる。お客様によっては、社内で使われるアプリケーションをエンドユーザーが勝手に使う場合に情報漏えい、機密情報がアプリケーションを通して漏れてしまうことを非常に心配されているケースがあり、業務データや基幹システムに繋ぐコネクタは基本的に禁止する。一方で、IT部門やCOEのようなしっかりした体制を作った中で使う環境においては、色々な業務データに接続するアプリケーションを開発可能にできる。環境によってアクセスできるセキュリティのレベルやデータの機密度を分けて事前にロックを掛けておく。危ないデータにはアクセスしないように環境毎に事前のロックを掛けて、その中で作られるもの、そしてアクセス数が10人規模とか小さいグループで使っているものは自由に使ってよい。一方、アクセス人数が50名、100名と大きくなってきたら、部門で作られたものであっても中央集約的な組織、例えばIT部門に運営元を移管して、ちゃんと管理ができる状態で運営していく。そういうアプリケーションの管理について、山本先生がおっしゃる通り、ドキュメント化する。うちの組織ではこういう環境を作って、こういう制限を掛けて、こういうリスクを排除した上で、自由に使って行きましょう、と決めた上で導入して、そのルールから逸脱するものに関しては、自動でひっかけることができる。例えば、利用者数が50名を越えたらアラートを上げて管理者のチームに通知が飛ぶようにしておくとか、作られたアプリの管理者として必ずCOEチームの人が就くようにするとか、そういった運用を一部自動化しながら管理するケースが多い。

吉田：
御社の場合ですと、Teams等との連携が非常に強みと思いますが、今説明されたような管理もTeams等にテンプレートが用意されているとかでしょうか？

平井：
そうですね、そういった運用の管理はPower Automateという自動化ツールの中で、管理者用の自動化テンプレートがけっこう用意されている。それを使うとTeamsに通知を飛ばすことなどができる。

聴講者からの質問：
運用系に関しては、何かPower Platformなりの支援機能が用意されているのですか？

平井：
アプリの運用に関しては、まず監査ログは対応している。またアプリケーションライフサイクル管理ができる仕組みがありますかという質問もあり、ソリューションパッケージ化してバージョン管理ができ、環境も検証用・本番用と分けてアプリを移しながら運用できる。Azureのノウハウを提供する形。

#### 日本企業にガバナンスはできるのか
山本：
たしかにその通りだが、日本企業で本当にそういうガバナンスがちゃんとできるのかが疑問。

平井：
COEという形を取ってやっている会社はたしかに限られているが、Microsoftのポストセールス活動として色々な知見を活用していただきたく、お客様を啓蒙している。体制を作っていただいたり、ガバナンスもほとんどテンプレートのようにできているので、お客様の社内に合わせてどうカスタマイズしていくか、をご提案している。

山本：
そういう意味では、COBITとかITILとかの思想とそんなには違わない。ただ、問題がより早くより大量になっているので、人間だけではもう無理だからPower Automateなどを使うことで、よりデジタル化・厳密化・手順化が推進されるということ。

平井：
おっしゃるとおり。それと、これが日本企業で難しいところだが、諦めるところは諦めるというか、この範囲で作られるアプリケーションはリスクが低いのだから、いちいち全部チェックしなくていい、ユーザが手元でExcelでデータ集計しているのとあまり変わらないレベルのものは、例えば個人の生産性を上げるためにデスクトップ上で動くRPAを作るとか、あるいはデータをちょっとスマホで入力してリストを作るくらいのもの、そういうものはリスク低として、年に一回棚卸しするだけでOKですと、割り切ってしまうことも大事。

聴講者からの質問：
元々ITガバナンスが確立されていない多くの日本企業に対して、そのあたりの意識改革から手をつけないと思います。特に日本企業は現場主義で、現場の力が強いので、彼らをどうやって説得するか、そして浸透させていくか。

平井：
おっしゃる通り。うまく行っているところほどトップの意識改革、そこが非常に大事。トップメッセージとして、全社でDXをやっていく、現場でDXがやれるようにツールを入れるのだ、のようなメッセージが強くある会社であれば非常に動きが早い。一方で、現場主導で、例えば営業部だけで出てくるとか、が往々にしてあるのが現実。現場が強いけれどもうまくやっているところは、事例としてはJTさん。発端は営業の業務システムをもっと自由にカスタマイズできるものにしたいとPower Platformで作り出したが、その営業の企画部門だけで走るのではなくて、そこにIT部門も代表で入った。バーチャルチームの形で、ちゃんとガバナンス設計・セキュリティ設計はIT部門が一緒にやりつつ、営業の企画部もちゃんとルールを理解して一緒に環境を作った。トレーニングや育成は営業部門が担っているので、エバンジェリストのような代表を何人か作って、現場の中でトレーニングして「みんなで使えるようになろう」という動きをしている。うまくいっているところと、なかなか進まないところが、別れているのが現状。

### ・数村さんの講演に関して
#### 膨大な数のコンテナの管理
牛山：
コンテナもローコードと同じように野良コンテナができてくるのではないかと思いますがいかがでしょうか？

数村：
あると思います。ガバナンスは大切だが、一般的にはサービスをリリースする時にはリリース判定会議を設けることがひとつ歯止めとして動いている。ただし、リリース判定で何をどう判定するのかは難しいところで、少なくとも開発者が勝手にリリースできるという状態ではなく、独立した別組織が判定する仕組みを作るのが第一歩。

#### なぜJavaなのか
大槻（委員会委員）：
Java資産が40%というお話がありましたが、昔はCOBOL資産がありました。メインフレームというコンピュータアーキテクチャがあった時には主要な言語はCOBOL、今だとWebという世界だとJava。Twelve-Factorという話がありましたが、あの中のどれが効くのか、組織とアーキテクチャとの関係で資産量が決まってくるのではないでしょうか。いかがでしょうか。

数村：
技術的なものと政治的なものがあると思う。Java言語特有の、メモリ管理しないでいいとか、生産性が高いとか、信頼性が高いとか、そういう技術的なところもあるが、どちらかと言えば政治的な話。Javaが出てきた時にIBM・Oracle・富士通をはじめとしてJava連合を作って一気に、これからはJavaだ、Javaでビジネスロジックを簡単に作れるのだ、という啓蒙活動をベンダーがよってたかってやった。そういう歴史から成功して一気にJavaが流行った。いったん作っちゃうともう離れられない、ということがある。そういう意味ではそこからしかたなく（という言い方もよくはないが）、当然時代の流れの中で新しいテクノロジーを入れながらJavaが成長し続けて、Javaに変わる新しいフレームワークや言語が出てきていないのが今の状態と思う。

大槻：
マイクロサービスの話はアーキテクチャにもの凄く影響している。組織とアーキテクチャとの同型性とか、そういうところがあることが優位性ではないか。

数村：
アーキテクチャ的には必ずしもJavaがマイクロサービスに最も適しているかというとそうとも言えないが、逆に先行している言語のいいところを取り入れるという進化のしかたをして来ているし、組織としてJavaを使い続けたいということろからどうしてもJavaをマイクロサービスに発展できるフレームワークにしていきたいという思いが逆にベンダーを動かして、Javaをこういう言語に仕立て上げてきた。そういう循環だと思う。

#### Javaはクラウドネイティブに最適な言語になったのか
吉田：
今日のご講演ですと、JavaのCN4Jを使ってついにTwelve-Factorをすべてクリア、ということですが、これは他の言語と比べてどうなのですか？Javaが追いついたのか、あるいはついにJavaが先陣を切ることになったのか。

数村：
Javaがこれまで先行してきたかというと必ずしもそうではないが、逆に後塵を拝していたかというとそうでもない。というのは、NetflixとかUberとか先進的な企業では、クラウドネイティブとかマイクロサービスとか凄い早い段階から取り組んで、しかも100％ではないにしてもJavaで組み立ててきた。かつ、彼らの成果をOSSとして提供している。という意味ではごく初期からJavaでマイクロサービスをやろうと思えばできた。ただ、Netflixができるからと言って普通の企業ができるとは限らない。そこが難しいところで、より普通に使えるコモディティ化や標準化ができた段階で初めてTwelve-Factorが満たせるようになったのかな、と思う。そういう意味で、ようやく今Javaがコモディティ化した技術として他の言語を先行しつつあると思う。

吉田：
他の言語ではこのCN4Jのようなものがまだ整備されてないので、けっこうプログラマが頑張って書かないといけないものがまだまだ多いよ、そういう意味でJavaはそこを一つ抜けたよ、という理解でよろしいですか。

数村：
はい。それに、他の言語にも色々フレームワークはあるのですが、どれを選べばいいのか、こっちは良かったりこっちは悪かったりで、なかなか選択が難しいところがあるが、Javaはいい悪いは別として標準化というところは昔から強いので、選択に困らないという点がある。

吉田：
これからは、どんどんマイクロサービスというアーキテクチャに当然なっていっちゃう、という感じですかね。

数村：
必然の流れだと思う。

吉田：
すると今までの作り方として、例えば開発標準とかそういうものに関して何か、特別なことはありますか？

数村：
やはりTwelve-Factorの原則に従ってやるということかと。

吉田：
コーディングレベルではそうですね。あとはもっと大きな話としては、山本先生がおっしゃっているガバナンスということでしょうか。

### ・角田さんの講演に関して
#### DXを狙うべきドメイン
三部（委員会委員）：
不動産市場という良いドメインを選定してそこをベースにリアル✕テクノロジーのコンセプトで成功したという話を伺ったが、スケール化で展開していく中で、角田さんからみて攻めどころだと思う他の事業領域があればお聞かせください。

角田：
本当にここを攻めれば勝てるというところは、私も教えて欲しいくらいだが、我々がまず不動産市場を攻めたのは、山本先生のお話で中小企業のDXが導入途上というお話があって、まさにそうだなと改めて思った。不動産の市場はかなり規模は大きいが、その構成は不動産宅建業者で１２万社くらいあって、かなり中小企業が多い。コンビニが６万件なのでその倍くらいあって、コンビニは大手がチェーン店化しているのに対して、不動産業は個人オーナーさんが多い。そういった、個社単体ではDXや効率化が自分たちではできないという集まりの業界を狙うのがいいと思う。その観点で考えると、例えば宿泊業とかはありかなと思っている。宿泊業はホテル・旅館など５万以上が日本にはあって、今はコロナで厳しい状況にはあるのですが、一方それが明けた後に事業再生やITの活用による効率化・DXがかなり進展する可能性があるかも。

#### デジタル産業の４類型での位置づけ
聴講者からの質問：
JEITAでDX推進を担当している者です。DXレポート2.1追補版の中に、デジタル産業の４類型があって、今後は経産省は企業をこの４類型の方に向けていくということですが、御社は現在プラットフォームも提供していますし、自らサービスも提供していますし、それを踏まえてこの４類型のどういう位置づけにいて、将来どういう方向に向かっていくのかをお聞かせください。

角田：
大きく２つの領域、クラウドとコンサルティング。クラウド側はSaaSサービスとして、山本先生のお話の共通プラットフォームよりももう少し業界に寄ったVerticalなSaaSプラットフォームを志向している。コンサルティングは企業様と一緒に変革・DXをしていくパートナー。どちらかに完全に寄り切るということはないが、基本的にはやはり業界特化のところから共通プラットフォームを提供していく。それは結局新しいビジネスとか新しいサービスを実現するためのプラットフォームになるので、そういった位置づけの中により高位を占めていきたい。

川井：
どちらかというとやはり共通プラットフォーム、業種をある程度限定したところでの共通プラットフォームでビジネスを拡大していくとか、事業を広げていくのがメインということですね。

#### デジタル産業の４類型とは
吉田：
今日の角田さんのお話は、山本先生が最初にお話されていたデジタルプラットフォームのお手本のような感じですが、山本先生からコメントはありませんか？

山本：
私は一つ疑問に思うことがある。４つの業態分け、「プラットフォーマー」、「サービスプロバイダー」、「DXパートナー」、「技術パートナー」があるけれど、不動産業界だと最後に不動産を売る人達は４つのどこなのか。そういう意味でこの４類型は、私は最初から限界があると思っていた。割り切れない人達が出てくるはず。そういうその他の人達が、プラットフォームを使ったり、デジタルサービスを使ったり、使う側の人達もいるはず。

角田：
私も４類型のどこかと言われて「結局全部です」みたいに答えたが、実業と一緒にやっているからこそ、先ほどのBizDevOpsのみたいな横串の形の中でデジタル化が進んでいくので、なかなか４類型のどこなのかというのは難しい。

山本：
だから私はハイブリッドというのがあっていいのではないかと思っている。リアルとデジタルのハイブリッド企業。将来はすべての企業がハイブリッド企業になって、まったくデジタルを使わない会社は無いだろうと思うので、デジタル産業に全部移行するのかと言われるとちょっと違うのではないか、と個人的には思っている。

吉田：
一昨年のグランプリのトラスト中山とかは、まさにハイブリッドですね。

山本：
物流は絶対にそうなる。

#### DX人財育成
吉田：
ご講演の中でも人財育成については触れられていたのですが、ビジネスの内容からしてかなりレベルの高いエンジニアが必要だったのではないでしょうか。そのあたりはどの会社も非常に苦労しているところだと思うので、何か秘訣はないのでしょうか？

角田：
やはり人を集めるという観点で、私はSony出身ということもあるかもしれませんが、先ほどのビジネスをやりたい、新しいイノベーションを行いたい、という人を獲得するように努めている。応募していただく方もそういった意識が高い方が集まっていただいている。なのでたぶんそこの軸があまりずれていない。もちろん入っていただく方は、例えばAWSのオペレーションはバリバリの人とか、機械学習は強いですとか、全部ができる人はあまりいないので、そこは先程来議論にあるような形でのアジャイルのチームの中でうまくコントロールする形でやる。まだ弊社はできて７～８年なので育成もまだ道半ばだが、メンバーには意識付けとして、ビジネス＋フルスタックエンジニアになろうよね、という話をしている。意識的にバックエンドをやっている人もフロントを書かせたりとか、オペレーションを自分で回して最終的にはこういうビジネスのサービスを作りたいなと思ったら自分で作れるようになろうね、と。まだそこまで高度なメンバーがちゃんと揃っているかというと、まだまだかなとは思っている。

吉田：
やはり、そういうレベルの方々がそもそも集まるというところが、Sonyさんというブランドが凄いのかなとは思います。

### ・山本先生の基調講演に関して
#### DX人財育成
大槻：
私がコンサルティングして感じるのは、イノベーター型の人とマネージメントとかアーキテクチャをやる人とは、全然発想・思考の回路が違う。誰でもひょっと連れてきて何かトレーニングしてDX人財になるか、というとそうとは思えない。そのあたりの素質・資質をどうやって見極めたらいいでしょうか。

山本：
例えばイノベーターだったらビジネスモデルを書かせてみればいいのではないか。書けなかったらアウトです。マネージメントもアーキテクチャも同じで、書けなかったら駄目。教育してみて書ける人と教育しても書けない人がいることはアグリー。教育者として教育を否定するような言い方にはなるが、もし本当に教育がちゃんとできるのであれば、そういう質問にはならない。やはりできない人がいるので、早い段階で割り切った方がいい。無駄です。そういう意味で、今、リスキリングを一生懸命みんなやっているが、やるのはいいけど、まぁ社員教育３年かけて1000人教えました、その後どうするのですか、というと、できない人がたくさんでてくると思う。

#### 非対面型アジャイル
角田：
ご講演の中で、非対面型アジャイル、ハイブリッドアジャイルが今後重要になるとおっしゃられていて、まさにそのとおりだと思う。我々は一週間のイテレーションでアジャイルをやっているが、まだまだイテレーション計画とか、ふりかえりとか、オペレーションからのフィードバックでこう直して行こうとかは、なかなか対面でないとうまく行っていない。どうやったら非対面型アジャイル、かつ、チームが増えていって連携しながらのアジャイルができるのかに悩んでいる。どういうステップでそこにシフトして行けばいいのか、を教えていただければ。

山本：
そこはまだ日本でも始まったばかりなのでよく分かっていない面もあるが、海外だとやはりモデル。対面だとその場であーだこーだと言ってなんとなく解決できてたことが、非対面だと解決できなくなるので、その時使えるのは「言葉」。それが話言葉だとその場にいれば雰囲気で伝わるものが伝わらなくなるので、ちゃんとビジュアルな言語を使うとか、日本語でもいいのだけれどきっちりと用語定義するとか、用語がわからなかったらそれをきちんとわかるようにフィードバックをかけてもらうとか、そこらへんの非対面コミュニケーションが成熟してないのが問題。海外のローコード開発などでも、何を使うかというと意外にモデルを使ったりしている。画面定義を使ったり、やっぱりそういうふうに確実に解釈が特定できる手段、コミュニケーション手段が必要。だから、逆に言えばそれを開発すればいいのでは。金融系だったら割に素材は明確じゃないか。そこがきっちりとできてしまえば早いのではないか。

#### DXは世界を救うのか
黒川（委員会委員）：
DXというものが、今世界が抱えている、例えば温暖化とか格差の解消とか、そういった問題にどうアプローチしているのでしょうか。

山本：
実は、国連はSDGsの問題解決にデジタルが活用できるとレポートを出している。日本でも大企業はSX、Sustainability Transformationと言って、それとGX、Green Transformationということで、デジタル技術を使って今のような問題を解決しようとしている。ただし、そのメソッドがまだできていないので、これからじゃないかと思う。グローバルには着実にその方向に進んでいるし、経産省でもSXを言い始めている。デジタルガバナンスコードの中で、SXも組み込んだ形で原則を作るべきという議論が始まったので、いずれそういうsustainabilityや環境についてのガバナンスコードも出てくる。そういう状況。でもまだこれから。

#### DXと生産性
吉田：
SDGsはもう世界共通の課題なのですが、特に日本は少子高齢化で労働人口が減っていくということで、生産性を上げるということはもう必須。そこが一番ポイントではないでしょうか。

黒川：
生産性というと、今までは日本の企業の経営者は生産性を上げるために賃金を抑えることをしていた。私は生産性の話をするとそこがいつも気になる。賃金を下げながら、さらに能率を下げているから、こういうひどい目にあっている。

山本：
OECDだと日本の労働生産性は10位くらいで全然高くない。SDGsの中に働き方改革もあるので、それをやることかと。

吉田：
生産性という言葉がよくないのかもしれなくて、ようするに働いている人が少ないのにちゃんとお金が回るのか、ということかと。そこにデジタルという技術が何か活かせるのではないか、ということでは。

山本：
SDGsはゴールなので、価値ですよね。DXは価値が入ってない。何のためにデジタル技術を活用するのか、が入ってないので、デジタルの軸とSDGsのゴールの軸ともう一つはValue Chain、価値連鎖。企業の中の生産・物流とか、サプライチェーンの3つの軸が必要、というのを私は提案しているが、それをデジタルSDGsキューブと呼んでいる。これからそういう手法が出てくる。

### ・まとめ
#### 日本の情報教育の変革
二木（委員会委員長）：
答えが無いことを承知してお聞きしますが、大学、大学だけでなく高校を含めて、情報の教育が話題になっていて、教育・人財育成が非常に基本的に重要な課題。今のものでは駄目で、改革しなければいけないと思っている人はたくさんいると思う。ぶっ潰すしかないと思っている人もいるかもしれない。本当に10年後に役に立つ人財を育てるためには、今の日本の情報教育のどこを変えるべきか。

山本：
まず先生を変えませんか。

二木：
山本先生のようにまず企業にいてから大学に移る人は、増えてきてはいますが、たしかに大学では人の移動は少ないですね。

山本：
DXで一番問題なのは、常に人財不足。人財はどこにいるのかというと、もう学生しかいない。言葉が悪いかもしれないけど、学徒動員。教える前にとにかく現場に出してしまう。高校とか高専とか大学もそうだが、例えばmicrosoftの無償のツールがあるのならばそれを持って、人が不足の場所があればどんどん送り込んで、そこで出てきた知恵を教科書にする。それでデジタル教育を再生産していく。それは、まだ誰もやっていないのですが。大学で、学校の中で教科書作ろうなんてやると、その閉じた空間の中で何が出てくるかもわからないから、それが問題。

二木：
大学は非常に大きな問題抱えているし、そのような実世界とのインタラクションを伴った教育も大きな課題。ぜひそのあたりに風穴を空けていただきたい、よろしくお願いいたします。

山本：
ぜひ、microsoftさんのご協力を。

最後に、御講演いただいた方々、議論に参加していただいた方々、聴講していただいた方々に感謝いたします。