マツダ×日本IBM対談：クラウドネイティブ導入には技術先行で目的を見失わないことが重要

デジタルトランスフォーメーションの進展を背景に、「クラウドネイティブ」という概念がIT変革の重要な要素と見なされるようになった。では、クラウドネイティブの本質とは何か？　このシンプルな問いの答えを探るべく、今回は、日本を代表する自動車メーカー、マツダと日本アイ・ビー・エムの対談を設定。両者はクラウドネイティブをどう捉えているのか――“実ビジネスへの寄与”を軸に、リアルな観点で議論いただいた。

　デジタルトランスフォーメーション（DX）の進展を背景に、「クラウドネイティブ」という概念がIT変革の重要な要素と見なされるようになった。先進的な企業は、コンテナやコンテナオーケストレーション、マイクロサービスといった、クラウドネイティブに含まれるテクノロジーやアーキテクチャを駆使してCI/CD（継続的インテグレーション／継続的デリバリー）を実践するなど、既にビジネス展開のスピードを加速させている。およそ全てのビジネスをITが支え、「ニーズに応えるスピード」が差別化の一大要件となった今、こうしたクラウドネイティブな技術の活用は業種・業態を問わず不可欠なものになるのは間違いない。

　しかし、成果を出すことは簡単ではない。中には、コンテナやマイクロサービスを従来のITツールの延長線上で捉え、「導入しさえすれば一定の効果が出るもの」と誤解しているケースも見られる。その結果、DXどころか、かえってビジネスを遅滞させてしまうケースすらある。

　では、クラウドネイティブの本質とは何か？　このシンプルな問いの答えを探るべく、今回は、日本を代表する自動車メーカー、マツダにおいて、コンテナ・PaaS活用を進めるMDI＆IT本部の主幹エンジニア、品川誠一氏と、チーフアーキテクトとしてさまざまなプロジェクトに携わり、クラウドサービスの立ち上げも推進してきた日本IBM 技術理事の沢橋松王氏による対談を設定した。

　マツダのMDI＆IT本部は、シミュレーション技術を使って自動車開発を進める「モデルベース開発」を支えるとともに、サプライチェーンマネジメント関連システムの開発・運用も担う。すなわち、マツダのコアビジネスを根幹で支える部門において、品川氏はアプリ開発の内製化やレガシーシステムの再構築プロジェクト、コンテナ・PaaSを中心にしたクラウドの活用など、「攻め」と「守り」の両面からITをリードしている。一方、沢橋氏はクラウド基盤の構築・コンサルティングなどを通じて、マツダをはじめ多数の企業を支援する立場だ。両者はクラウドネイティブをどう捉えているのか――“実ビジネスへの寄与”を軸に、リアルな観点で議論いただいた。

攻めと守りの二方面作戦でカギになるのは「コスト」

──　DXトレンドが進展する中、自動車業界では「100年に一度の変革期」といわれています。また、「2025年の崖」のようにレガシーシステムがDXの足かせになることが懸念されます。こうした状況の中でITをどう見ているか、それぞれの意見をお聞かせください。

マツダ MDI＆IT本部 主幹エンジニア 品川誠一氏

品川氏　マツダは2020年に創立100周年を迎えました。ちょうど100年に一度の変革期と呼ばれるタイミングでもあり、思いを新たにしているところです。自動車業界は今、コネクテッド、自動運転、電動化といった技術や、シェアリング・サービスへ対応する「CASE（Connected、Autonomous、Sharing＆Service、Electric）」と呼ばれる変革が起きています。これらはビジネスモデルそのものに関わる変革であり、その全てにITが重要な役割を果たします。その意味でもマツダのMDI＆IT本部として強い使命感を持って取り組んでいます。

沢橋氏　マツダさんをはじめ、今多くの企業が変革期にあってさまざまな新しい取り組みを進めています。ただ、課題の一つは、レガシーなシステムが社内に数多く残り、ランニングコストが高止まりしていることです。そこに社内の多くの要員を割かねばならず、予算を新しい投資に振り向けにくくなっています。こうした課題の背景にはあるのは、従来のアプリやインフラは、その後の運用保守まで考えて設計されていなかったという点です。IBMでは、ビジネス起点でITのライフサイクル全体を視野に入れた、レガシーの変革が今こそ必要だと考えています。

──　ビジネスとITが直結している今、従来のように経営戦略やビジネスモデルからITが分断されたままでは、もはや立ち行かないというわけですね。

品川氏　マツダでは、沢橋さんがおっしゃったレガシーシステムの再構築のような課題は「守りのIT施策」として対応しています。マツダは、2025年までに300超のシステムを再構築する必要があります。その一方で、CASEのような新しい課題は「攻めのIT施策」として取り組んでいます。この二方面作戦を展開する上でカギになるのがコストです。従来の開発スタイルでは、コストがあまりにかかり過ぎる他、仮にコストに見合うとしても、多数のレガシーシステムの再構築に対応できる膨大なIT技術者を広島という地で調達するのは困難です。そこで数年前から始めているのが、開発効率を大きく向上させる取り組みです。

　今、私のチームでは大きく3つの取り組みを推進しています。1つ目はローコード開発、2つ目はAPI指向開発、3つ目はコンテナ・PaaSを活用した開発への移行です。まだ「クラウドネイティブ」と呼べるほどではありませんが、IBMさんの力を借りながら取り組みを進め、かなりの成果を出せるようになってきました。

ローコード開発、API指向開発、コンテナ・PaaS活用を進める

──　それら3つの取り組みについてもう少し詳しく教えてください。

品川氏　まずローコード開発では、モデル駆動型で基本的にコードを書かないスタイルでの開発を進めています。ローコード開発は日本で利用が進んでおり、当社でも、生産性・品質向上の面で成果を上げています。もろちん全てをローコード開発で賄うことはできないので、従来のJavaなどによるコード開発も継続して生産性を高める必要があります。

　2つ目のAPI指向開発は、イメージとしてはドメイン駆動に近い形で集中的に特定の業務領域のAPI実装を進めるものです。例えばクルマのサプライチェーン業務のシステムでは、REST API化と同時に、総コード量を減らす取り組みを進めています。サプライチェーン領域では、コード量が従来比75％減まで削減できるところまで進んだ業務もあります。

──　限られた人員、予算、期間で開発生産性を高めることが求められているのですね。

品川氏　そうですね。そして、3つ目のコンテナ・PaaSを活用した開発への移行は、今まさに取り組んでいるものです。開発の一部でコンテナやPaaSの活用を始めていて、クラウドネイティブやマイクロサービスの考え方やアプローチに触れる機会も増えてきました。マツダでは、攻めの領域／守りの領域を問わず、開発をコンテナとPaaSを活用した形態に移行しようとしています。

　コンテナ・PaaSに取り組む理由は単純です。従来の開発スタイルでは、スピード、コストの両面で開発需要に対応できなくなったからです。マツダは15年くらい前からJavaを中心に開発を行ってきました。コードを自動生成するツールを含めて、Javaの独自フレームワークを開発、整備してきました。

　これには功罪あって、開発者の技術レベルがあまり高くなくても開発できるといったメリットはあるのですが、最近の新しい技術には対応しにくくなります。例えば、UIが進化したモバイルのネイティブアプリを自社フレームワークで構築するには限界がきています。また、昔ながらのJavaで、重厚長大なアーキテクチャで構築されているため、新しいアプリを開発しようとすると生産性を下げる要因になってしまう。これらを、PaaS基盤の下で、より軽量なSDKで開発することがまず1つ。

　2つ目に、コンテナで構築することで、これまでと比べると大幅にサーバ構築期間が短縮でき、構築にかかるコストも削減できます。また、コンテナ化しておくことでシステムの可搬性が向上し、特定のクラウドベンダーのロックインによる価格高止まりのリスクが減少することも、中長期のコスト戦略の中では大きいです。

──　開発・提供のスピードを上げるだけではなく、機能変更も迅速・柔軟に行えるようにする、新たな技術要素も取り入れやすくする。つまりビジネスニーズに応えるスピード、柔軟性を向上させると同時に、技術的負債の解消も狙っているわけですね。

日本IBM 技術理事 沢橋松王氏

沢橋氏　品川さんがおっしゃった技術的負債の問題は、多くの企業に共通する悩みです。直接的に利益を生む分野ではないので、投資の承認も得られにくい。ところが、クラウドネイティブの世界になると、それが大きく変わります。開発スタイルだけの問題ではなく、ITのライフサイクルが変わることがポイントです。

　例えば、コンテナの世界では、これまでのサーバの世界と違い、アプリを更新するタイミングでコンテナをビルドし直します。ビルドし直す際に、ミドルウェアやライブラリも最新のものに置き換わる。ミドルウェア、ライブラリといったインフラ的な要素も含めて常に最新になるのです。つまり、「オンプレミスのサーバの世界で行われてきた『10年ごとの大バージョンアップ』といった、リプレース作業は不要になる。技術的負債が生まれにくくなり、スピード、コスト、生産性などの問題を解決できる」として大きな期待が寄せられています。

クラウドネイティブ、マイクロサービスを適材適所で活用

──　では、マツダではどのようにクラウドネイティブな技術を採用してきたのか、具体的に教えていただけますか。

品川氏　「クラウドネイティブをどのように定義するか」というのはありますが、マツダでは当面考えているのはコンテナ技術の活用と、PaaS前提の開発形態への移行です。マツダでも以前からDockerの利用は進めていました。先ほども述べましたが、首都圏のようにIT技術者を潤沢に確保できないため、オフショア／ニアショア開発を積極的に進めてきた中で、開発環境を素早く提供することなどを目的としていました。

　最近のIT部門のコスト構造改革の流れにおいてコンテナによるコスト削減効果への期待が大きくなってきたことから、コンテナを中心とした開発スタイルへの移行を目指してコンテナオーケストレーションの推進に至りました。具体的には、2019年夏から「Red Hat OpenShift」のPoC（概念実証）を実施し、その効果が認められたため、開発で利用を開始します。

　ただし、全ての開発環境をコンテナやPaaSに移行するのではなく、あくまでビジネス目的に応じて適材適所で活用する考え方を採っています。

──　クラウドネイティブやマイクロサービスで実現したいビジネス目標とはどのようなものなのでしょうか。

品川氏　われわれの目標は、前述のような制約がある中で、ソフトウェアを「早く、安く、うまく（品質良く）」作ることです。しかし、新しい技術やバズワードに踊らされ、その導入が目的化してしまい本来の目的が失われてしまうことは避けなければなりません。

――　先のAPI指向開発についても、マイクロサービスという“アーキテクチャ先行”で考えず、あくまでビジネスドメインを起点に最も効率的な開発の在り方を考えられたということなのでしょうね。

品川氏　マイクロサービスアーキテクチャについても、コンテンツ系の企業がモバイルネイティブアプリをゼロから構築するようなケースや、少数の優秀な技術者で比較的短期に開発するようなケースでは、有力な選択肢になると思います。ただ、マツダのように社内システムを大人数で構築するようなケースには向かない場合もあります。これまでの開発スタイルを踏襲して作った方が「安いし早い」ケースはまだ多いのです。

　そのため、適材適所で活用することが重要になっていきます。マツダはこれまでサプライチェーン領域を中心に800個近いAPIを整備し、開発に利用してきました。まずは、そうした分野から“必要に応じて”マイクロサービスアーキテクチャを取り入れていければと思います。

スモールスタートでできることから積み上げていく

──　確かに多くの企業において、クラウドネイティブやマイクロサービスに限らず、言葉先行、技術先行になり、目的が見失われやすい傾向は強いと思います。

品川氏　マイクロサービスと似た考え方として、15年ぐらい前にSOA（サービス指向アーキテクチャ）が流行しました。本来は安く早く作るための手段だったはずですが、うまく結果を出せたケースは少ないと認識しています。結局は、再利用性の高い美しいサービスを設計して実装することも、それを維持するSOAガバナンスにも、お金と時間がかかり過ぎたのです。

　SOAから学べる教訓は「いきなり100点を目指して、高尚なアーキテクチャを実現しようとするのではなく、スモールスタートで、できることから徐々に積み上げていく」ことが重要ということだと思っています。マイクロサービスでいえば、まずは普通の作り方でシステムを構築して、運用、改善していく中で、明らかにサービス化した方がいいものを切り出す。それを続けながらサービスの数を増やし、技術者の育成も行っていく。それがマツダのような普通の日本企業にあった現実的なやり方だと思います。

沢橋氏　その点では、「開発プロセスをどう変革するか」もよく課題になりますね。DevOpsの文脈でいえば、開発から運用までをシームレスにつなげることが理想ですが、職責分離や内部統制、ガバナンスといった課題があり簡単にはできない。また、外部のベンダーに開発を依存する文化や、そうした文化によって内部にスキルやノウハウがたまりにくいことも課題となっている。これらを着実に変革していく必要があります。

品川氏　そうですね。マツダでも従来の開発プロセス規定の下で、アプリ、インフラ、運用のそれぞれで管轄部門も委託先ベンダーも異なっており、それが高速開発を阻む要因の一つになっていました。コンテナを導入する際、技術的には問題がなくても、プロセスや組織を変えるための合意形成が大変です。関係者のコンセンサスを得ながら、新しい業務プロセスを設計し、既存の枠組みの中で最大限バランスが取れるものを考えていく必要があります。

コンテナセキュリティと運用自動化でIBMに期待

──　では、そうした文化やプロセスの問題にひも付くものではありますが、コンテナやコンテナオーケストレーションにおいて、技術面で特に重視している点はありますか。

品川氏　セキュリティと運用の自動化です。コンテナは全体としてはセキュリティのリスクポイントを軽減するアーキテクチャですが、運用上は複製のような形で増やしていくため、事故が発生したときの影響が大きくなるリスクもあります。例えば、ベースとなるDockerイメージに脆弱（ぜいじゃく）性が潜んでいれば、それが複製さることで大きなリスクになる。それらをツールや仕組みで防止することが求められます。

　運用の自動化については、「マニュアル作業をいかに減らし、コストを軽減できるか」がポイントです。その意味で、コンテナオーケストレーションの機能に期待しています。また、コンテナはベンダーロックインを防ぐプラットフォームでもあります。コストを重視して必要に応じて利用するクラウドを変えることも、運用を自動化する中で実現できればと思っています。

──　IBMでは、どのように技術的な支援やアドバイスを行っているのでしょうか。

沢橋氏　クラウドネイティブプラットフォームを担当する専門部隊を2019年に立ち上げて、支援する体制を整えています。コンテナやコンテナオーケストレーション、マイクロサービスアーキテクチャに詳しい技術者が集結しており、「IBM Cloud」だけではなく、他社ベンダーのクラウド環境も支援します。

　IBMの強みの一つは、オープンソースソフトウェア（OSS）に多く貢献してきたことです。DockerやKubernetesに代表されるように、企業ITプラットフォームの中心はOSSになりつつあり、今後この流れは加速するでしょう。ただ、OSSには特有の課題もあります。例えば、Kubernetesは3カ月ごとにアップデートを繰り返すため、企業のIT部門がそのアップデートに追随することは現実的ではないといった点です。そうした課題もOSSをパッケージングしたRed Hat OpenShiftやIBM Cloud Paksなどのディストリビューションを活用することで、ユーザー企業は本来の目的の遂行に集中できます。

　セキュリティについても、コンテナの脆弱性をチェックするなど、さまざまなソリューションを提供します。さらに、内製化に向けた取り組みなどについてもコンサルティング部隊が並走しながら、今後必要になるスキルをトランスファーすることで、スキルやリソース不足の課題解決をサポートします。

本質を捉えながら、技術を正しく評価し、適材適所で使う

──　では最後に、今後の展望を教えていただけますか。

品川氏　マツダは自動車業界ではスモールプレイヤーです。しかし、価値ある商品をお客さまにお届けするために、例えば、モデルベース開発のような新しい設計製造手法をいち早く導入するような、新しい技術に挑戦する風土がある会社です。ITの面でも、従来のやり方に固執することなく、貪欲にチャレンジを続けたいと思っています。

　まずは、コンテナオーケストレーションやPaaSを中心にした早くて安い開発への変革は徹底して追求します。その中で、例えばマイクロサービスアーキテクチャについては、本当に効果があるかどうかを見定めながら身の丈に合った現実解を追求していきます。その際に重要なのは、あくまで「本質が何か」を忘れることなく技術を正しく評価し、適材適所で使うことです。価値があると判断したものについてはさまざまな障害にもひるまずに諦めずに追及していきたいと考えています。

沢橋氏　クラウドネイティブという言葉は「ネイティブではないものがある」ことも示しています。それは従来型システムのことですが、ネイティブであることを強調するのは、それだけ「変革が難しい」ということでもあります。何十年にもわたって続けてきたシステムの作り方そのものを変える必要があります。「技術だけの導入だ」と捉えてしまうと、おそらく失敗するでしょう。技術だけではなく、文化、体制、組織の変革を併せて推進することが重要です。

　あくまでビジネス目的を起点に、制約解消に向けたいろいろな取り組みを実践することで、クラウドネイティブの世界におのずと近づくと考えています。IBMではツールの導入や技術支援だけではなく、業務プロセスや組織の変革まで含めてさまざまな点から、マツダさんをはじめ、多くの企業を支援していきたいと思います。

提供：日本アイ・ビー・エム株式会社
アイティメディア営業企画／制作：＠IT 編集部／掲載内容有効期限：2020年6月30日