クラウドネイティブ導入を阻むものは何か？　組織づくりから考えるハードルの乗り越え方

なぜ仮想マシンからコンテナに移り変わったのか？

新野淳一氏（以下、新野）：さきほど青山さんが、クラウドネイティブは運用が楽になったり、開発を速くすることを目指して実現していくもので、そういうメリットを得られるものであるというお話がありました。ここで2つ目のアジェンダに移っていきたいと思います。

それは楽したいがためになんらかの苦労をして作り上げていくわけじゃないですか。そのためにどんな苦労をしているのか、どんな技術を使おうとしてるのか、どんな組み合わせをしているのか。要するに要素技術は何を使っていらっしゃって、それをどう組み合わせて実現しているのかを少し教えていただけませんか。

青山真也氏（以下、青山）：弊社の場合は、さすがにKubernetesみたいなOSSを作るほどの体力はないので、基本的にはオープンソースと共生して、一緒に使っていって貢献していくスタイルになっています。最近はKubernetes・コンテナが多いんですが、古くは自動化のスクリプトだったり、もう少し進んでくると、ChefやAnsibleみたいなコードでインフラを管理するものを使っていってます。

新野：ということは、さきほどまさにおっしゃったように、仮想マシンを使っている時代から、楽をする方向へできるだけ向かっていったわけですよね。

そのために、仮想マシンだったらAnsibleやChefなどを使っていたと。今それがコンテナに変わっているということでいいですか？

青山：そうですね。結局技術スタックは何を使うんでもいいのかなと思っていて。今だとChefやAnsibleがDockerfileとKubernetesの設定ファイルのマニフェストに変わったりしました。ただ、それが変わってきているだけという印象ですね。

新野：ある意味わかりきっている答えではあるかもしれないのですが、あえて聞くと、なぜ仮想マシンからコンテナに替わったんでしょう？

青山：1つに、ChefとかAnsibleだといわゆる冪等性という「ちゃんと同じものになるか？」が厳密には担保できないんですよね。VMをイメージ化まですれば、ちゃんと冪等になるんですけど、そのイメージ化が大変だったことがありました。

コンテナになるとそれがすごいスムーズにできるし、インフラがやらなきゃいけなかったようなことがアプリケーション側にもできるようになってきた世界観なので、弊社の文化というか組織と考えが非常にマッチしているのが大きいところですね。

新野：なるほど。クラウドネイティブ的な理想にたどり着くためには、仮想マシンよりコンテナのほうがより近づきやすかったという理解でいいですか？

青山：80パーセントはそうです。データベースや要件によっては「いや、これ、VMのほうがいいよ」って、こんな私が言うこともあります。

新野：なるほど。一般的にはコンテナがたくさんになるとKubernetesを使ってオーケストレーションするのが多いと言われていますけど、まさにそういうわけですよね。そのへんは今どういう運用をされていらっしゃるのか、教えていただけませんか？

青山：「どのオーケストレーターを使うように広めているか？」みたいな感じですか？

新野：はい。

青山：基本的にはKubernetesを使うことをおすすめしているんですが、別にKubernetesじゃなくてもいいと思っています。

オープンソースなもので言うと、KubernetesやDocker SwarmやMesos系があるんですが、だいたいどれも触っています。当初だとDocker Swarmもかなり力を入れてやっていたので、全部見て判断して「Kubernetesが一番だよ」と個人の見解として言っている感じですね。

Kubernetesは洗練されている

新野：それはどのへんが理由なのか、手短に教えていただくことは可能ですか？　すごい複雑そうな気もしますが。

青山：シンプルに言うと、ちゃんとたくさん機能があるのと、Kubernetesはめちゃくちゃ洗練されていて超かっこいいんですよ。本当に洗練されてるんです。「よく作られてるな」としか思わないというか、作った人は天才だと思うんですね。

新野：なんとなくイメージでは洗練されているソフトウェアであることはイメージしやすいんですけど、でも、具体的にはどういうところか、少し説明できます？

（会場笑）

荒井康宏氏（以下、荒井）：そこがすごく聞きたい。

青山：Kubernetesは、いわゆるReconciliation Loopと呼ばれる、あるべき状態に戻す仕組みがKubernetesのコアのロジックに入っているんです。それを拡張できる仕組みになっています。

運用の作業は全部、「なにか変になったら元に戻す」「負荷が高くなってきたから増やす」など、なにかに対して調整するものが多いと思うんですね。それがKubernetesでは抽象化されてそういうコンセプトが内部に備わっているので、そういったものが簡単に実現もできますし、すでに実現されているものがたくさんあるというところですね。

CI/CDはちゃんとやるべき

新野：なるほど。さきほどのクラウドネイティブのメリットとして、回復性・管理性・可観測性に向かって積み上げていくと、クラウドネイティブ的なメリットが得られる。そのための要素技術としてコンテナやKubernetesを使う話をしていただきました。ほかになにか使っていたり、あるいはこれは大事だと思っているというソフトウェアやシステムはありますか？

青山：基本的にCI/CDは最初にちゃんとやるべきですね。アプリケーションをアップデートするなど、デプロイのサイクルをちゃんと速く回すところは一番必要です。Kubernetesよりも必要だと思います。

新野：CI/CD、要するに継続的統合と継続的デプロイというわけですよね。それには開発環境を自動化していくことが必要なわけじゃないですか。よく言われるのは、GitHubでソースを管理して、OKが出たら自動的にビルドして、テストが走って、デプロイするというワークフローを作ると言われていますが、それは何を使っていらっしゃいますか？

青山：CIに関しては、弊社の場合はCircleCIとかCloud Buildが多いんですけど、あまりそこはなんでもいいかなと思っています。CDに関しても、Kubernetesに対してデプロイすることができるものであればなんでもいいかなと思っています。そこにあまり大きな違いはないですよね。多少の違いはあるんですが、そこは弊社の中でもすごく乱立している感じかなと思います。

新野：ツールはとくに大きなこだわりはないが、とにかくやることが大事ということですね。

青山：やることが大事です。もう一つは、新しい良いものや新しい管理しやすいものがすごくたくさん出てくるので、「これに決めたから、ずっとこれ」というのだけはやめたほうがいいと思います。CI/CDツールも移り変われるようにしておく。そこもクラウドネイティブっぽい感じにしておかないとよくないなと思います。

新野：そのためにどういう心構えでいるといいですかね。ツールを使ってるとツールを好きになっちゃうじゃないですか。変な話ですけど思い入れがどんどん出てきて。

データレイクに何を使うかが重要

青山：でも、さらにいいものが出てきたら移り変わりたくないですか？

（一同笑）

荒井：なるほど。性格が（笑）。

青山：軽自動車に乗っていたけど、フェラーリが出てきて、フェラーリを使えるんだったら使いたくなると思うんですね。

新野：ドライにいいものを切り分けて使っていくということですね。

青山：はい。

新野：じゃあ荒井さんにも。荒井さんはどっちかというとSIerの立場で、お客さんの要望に対して技術を使って提供しています。

荒井：どういう要望が多いかというと、最近は大規模なデータを処理する基盤が多いですね。利用するクラウドは、お客さんにデータ処理内容を聞いてそこから決めたり、あるいはすでにお客さんが使っている場合も多いので、それをベースに使います。だから、AWSも使うし、Azureも使うし、GCPも使っています。

クラウドの選択においてポイントとなる機能は意外とデータレイクです。「GCPのBigQueryを使うの？」「それともAzure Data Lakeを使うの？」「Amazon S3、AthenaやDynamoDB、Redshiftを使うの？」とか、そういうデータレイク設計で何を使うかがまず重要になってきました。

そのあとにいわゆるデータを加工するETL処理や、パイプライン化するためにそれらの処理をKubernetes上で動かすことはよくあります。

新野：なるほど。荒井さん、さきほどイベントドリブンやデータドリブンなのは比較的クラウドネイティブっぽいというお話をされていました。そのためにどんなソフトウェアだったり、あるいはクラウドの機能を使っていらっしゃいますか？

荒井：AWSの場合は、Lambdaを使うことが多いです。

新野：AWSのLambda。サーバレスですね。

荒井：他にも、AWS Data Pipelineのようにデータ処理フローを管理したり、Cloud Dataflowのようなデータを連続的に処理をする機能も使います。AWS EMRなどのデータ処理を並列化して高速化するものも頻繁に使っています。

新野：なるほど。そう聞くと、既存のアプリケーションをクラウドに持ってきてもクラウドネイティブっぽくならなくて、どうしてもサーバレスを使って作り直すのが前提になる理解でいいですか？

荒井：はい。ある程度のデータ規模以上になると作り直す必要があり、そこは作り直しています。

CI/CDツールの選び方

新野：ありがとうございます。じゃあ安田さん。

安田智有氏（以下、安田）：実際にはどんな技術を使っているかということなので、現場というかお客様ニーズで何が一番クラウドネイティブという切り口で見ると使われているテクノロジーがあるかというと、コンテナなんですよね。

他のクラウドもそうですが、IBM CloudにはKubernetesで基本マネージドの環境がありますので、それを使って開発されているお客様はいらっしゃいます。さらに、企業のお客様で「もうちょっとサポートとかちゃんとやってくれるよね」と気にされるお客様がOpenShiftを使われる。

その技術というか、製品名を言っちゃいましたけど（笑）、今私たちがやっているのってまさにクラウドネイティブのアプローチで、組織も変えながら使うことを検討されているお客様は、そういったテクノロジーを積極的に採用されていると思います。

新野：3人の話を聞くと、コンテナとKubernetesは定番の使い方という感じに聞こえてきますけど。

荒井：定番です。

新野：あと開発環境、CI/CDの話題もさきほど出てきました。IBMや安田さん的には、でもいいんですけど、CI/CDも大事な要素だと思われますか？

安田：大事ですね。

荒井：さきほど青山さんが「いや、Kubernetesを使う前にCI/CDはやってないといけない」というのはまさにそのとおりです。まずはCI/CDはやってることが前提だと思います。日本の場合、CI/CDができていない状況で「とりあえずKubernetesちょうだい」と言われて「いやいや」と困ってしまうのが多いです。

新野：荒井さん、CI/CDの始め方、あるいは導入の仕方についてなにかおすすめはありますか？

荒井：難しい質問ですね。一応自分はGitLabを利用することが多いです。

新野：まあ、そうですね。

荒井：はい。まずは「うちに相談してください」というのがあるんですけれども（笑）。

そうですね、まずはツールにこだわらずやってみるのがいいと正直思っています。そのCIで「あっ、楽になったな」と体感して、そこからどのツールだと一番楽なのか、自分のやりたいことに適しているのかを探していくのがいいと思います。

新野：安田さんにも今の議論の続きで聞いていきます。IBMさんはもう10年以上前からアジャイルにはすごく力を入れていて、CI/CDはある意味でその延長線上にあるものだと思うんですけど、CI/CDを開発スピードを速くしたいお客さんに勧めますか？

安田：勧めます。私たちの社内は、クラウドをやっているインフラのチームもいれば、アプリケーション開発を主に担う部隊もいて、基本的に昔はプロジェクトごとにいろいろな開発の環境を立てていました。お客様のプロジェクトのデータのガバナンスが強く利いていない場合は共用の開発環境が提供されています。

基本、そこの上でCI/CDがもうすでにあるので、自分が好きなツールを持ち込んでツールチェーンを作って組み上げていく開発スタイルでやっていますので、お客様がもしそういうアジャイルになにか回したい場合は、自分たちの経験をお客様にお伝えして「どうですか？」と聞きます。

新野：IBMが持っている経験をお客様に伝える。

安田：そうですね。それをお客様が「こういうふうにやると、僕らみたいなこんな開発ができるようになるんじゃないでしょうか」といった話をします。

セキュリティが厳しくGitHubが使えない会社も

新野：インフラの話と開発の話が2つ出てきました。インフラの話は比較的コンテナとKubernetesの定番があって、これはやればできそうな気がするんですけど、CI/CDは開発のプラクティスの話じゃないですか。これはハードルが別な気がします。このあとの課題の話につなげていきたいんですが、そのへんの課題はどう感じていらっしゃいますか？

安田：そうですね。そのCI/CDの課題の前に、いろいろなツールってインターネット経由でアクセスできてすごく便利なんですけど、お客様によっては「いや、そのサイトは禁止されているので見れません」とか、非常にセキュリティが厳しいお客様が多いです。

新野：例えば、まさにGitHubもインターネット上で使えるし、CircleCIもインターネット上で使える。でも、そういうのはアクセスを禁止している会社があるんですね。

安田：そうですね。決して少なくないというか。そういうチャレンジをこれまでお客様がしてこなかったので、禁止されたままです。そこは組織を変えていくというか、そういう便利なものをちゃんとセキュリティを守りながら、「お客様のコンプライアンスに合いますよね」というのを1個1個潰していきながら、その環境をセットアップしていくところから始めます。

新野：ちなみに、そういう会社はなぜ禁止されたんでしょうね。

安田：もともと、開発したコードって自社占有のもので著作物であり、漏洩は機密情報を垂れ流すのと一緒だということでした。それが自分の管理が及ばないと思っている。例えばパブリックに公開するという誤解を持たれることも多くて、「いやいや、それは公開もできるし、限定もできるし」と、しっかり説明できていないのもあるんじゃないかなと思います。

新野：まさに一番最初にパブリッククラウドが登場したときの状況に近いかもしれないですね。

安田：近いですね。

クラウドネイティブ導入のハードルは何か？

新野：3番目のアジェンダについて、そのためのハードルについて今度はおうかがいしていきたいと思います。これもまさに開発の部分のハードルとインフラの部分のハードルの両方があるのでおうかがいしていきたいんですけど。

今の話の続きとして、CI/CDはツールを入れるハードルも当然あると思うんですよ。インターネット上のツールを使えないとか。それとは別に組織の話をされていらっしゃいましたよね。ウォーターフォール的に作ってバーンと出すのと、CI/CD的に速く回して作るのは、カルチャーが違うとよく僕も記事に書いたりするんですけど、どんなハードルがあって、何を超えなきゃいけないですか？

安田：ずっと僕らは手法の話をしているので、ゴールは「速くアプリバージョンアップしたい」「もっと落ちなくしたい」「お客さんにもっといろいろなサービスをどんどん出したい」というお客さんのニーズがあると思うんですけど。

それをやろうとすると、これまでサーバ部や〇〇開発部や企画部といったように組織が分かれていて、会議をセットアップするだけでも数日かかるようなスピード感を変えていかなければ、お客様自身が勝負に出づらいと思われるんじゃないかなと思います。

先日、先日お客様の声を聞く会をやったんですけど、あるお客様が「いや、実は今年一番大きなことをやりました。組織を変えました」と言うんですね。

それが、さきほど言ったサーバ部とかデータ設備部とか、そのへんの人たちをとりあえず1個の部門にしましたというのを1人の方が言うと、他の方が「そうか」みたいに思うんですね。

参加者の半分の方は、そういうことをそもそも変えていかなければいけないと思って、変えていくと、一歩を踏み出せると気づいていらっしゃる。もしくはどこかでやった事例を聞いて、それをやってみようと思っている。でも、そのチャレンジを許す会社がこんなにいるんだって。

だから、超えなきゃいけないハードルは、コミュニケーションをもっとスムーズにするとか、なにかの話をしようと思ったときにすぐ会話ができることです。組織を分けているとなかなか難しいと思います。

そういうコミュニケーションの仕方に慣れている人たちを「じゃあ1個にしたらいいんじゃないの？」ということができる会社は、ハードルを1個超えたのではないかと思います。

新野：組織をまとめると、肩書を持っている人が減りますからね。3つに部署を分けていたら課長が3人いるのに、1つにしたら課長1人になっちゃいますからね。

安田：そうですね（笑）。

新野：日本は肩書と給与はだいたい結びついているじゃないですか。だから、そういう組織を変えるのは難しかったりしますよね。そういうところは比較的クラウドネイティブで、とくにCI/CD系は大事なところがあります。

同じ業界の事例を求める

安田：私も先日とくに驚いたのが、社内でコストを調達して「こんなアプリ作りたいのでよろしく」と言ってくる人たちが、同じチームにいる会社さんがいました。

新野：開発チームと同じ？

安田：開発チームと同じところにいる。それが組織で、その方はテストだとおっしゃったんですけど、うまくいけばそれを正式に組織として発足する。日本の企業でもそういう組織のレベルでテストマーケティングや、A/Bテストみたいなことをやっていてビックリしました。

新野：なるほど。今の開発組織の話で、今度はコンテナやKubernetesを入れる上で、なにかハードルがあると思われるところはなにかありますか？

安田：多くのお客様がまず事例を聞いてきます。国内で、しかも私と同じ業界で、どんなお客さんが、それをやることによってどんなメリットがあったのかを聞かれるんですね。そこはなかなか厳しいですね。

新野：なるほど。まだ本気になってないという感じですね。

安田：いや、「使ってみればわかるのに」とか、当然使う用途の紹介はしますが、どうしても、とくに私たちが接しているお客様では同じ業界の事例を求める声が多いです。

新野：ちなみに、これはうまく説明できた事例はありますか？

安田：一番おもしろかったことは、「落としたくないアプリだからこそコンテナライズしました」という話です。

Kubernetesもマネージドのサービスがたくさんありますので、1つのAvaliability ZoneだけじゃなくてマルチAZを使っています。SLAだけでも99.999ぐらいでは足りないと。落ちないためにをそれを世界3極でしっかりやったり、落ちないインフラを実現するために使える唯一のテクノロジーだと社内で言っています。

私たちの場合、The Weather Companyという会社を買収して、まさに落ちないインフラを作るためにコンテナ化した事例を公開しているのですが、それをご紹介すると「なるほど」と言っていました。「IBMも自社でそういうことやってるのね」と言っていて、「よし、伝わった」という感じですね。

新野：ありがとうございます。

顧客を巻き込んで、何を実現したいのかをすり合わせる

新野：荒井さん的なクラウドネイティブを導入する上で、お客さんになにか説得しなきゃいけなかったり、お客さんにがんばってハードルを超えてもらわなきゃいけない場面があると思いますが、どんなハードルがありますか？

荒井：実は安田さんの言っていることとかなり近くて。お客さんを含めて、なおかつ自社のエンジニアも含めて、組織とマインドを変えなければいけません。

弊社もアジャイル開発もやりながら、請負開発もまだしています。この2つは、お客様を含めてのマインドではぜんぜん違います。ここは非常に重要です。

我々が取り組んでいるのは、「お客さんもこっちに来てください」と。開発メンバーも呼んで最初にインセプションデッキをして「これは何のために必要なんですか」と、とことん話し合って、「結局必要なのはこれなんですね」に落として、開発者も納得した上で開発を進める。

新野：なるほど。ということは、技術の話から入るのではなく、何を実現するかをよく話し合うということですね。

荒井：そうですね。まずそこが大事なポイントです。結局、何を実現したいのか、お客さんを含めて、なおかつ開発者も含めてしっかり議論します。その議論の中でチームができていくんですね。「こうしたほうがいいんじゃない？」「こういう用途で使われるから、こういう機能が必要なんじゃないか？」というものが出てきて、自律的・自発的に開発ができるようになってくる。

新野：その中で、イベントドリブンなソフトウェアやCI/CDをやっていく結論になるものですか？

荒井：開発サイクルは速くしないといけないので、CI/CDあるいはDevOpsということはもう必須です。

新野：なるほど。自ずとそういう結論になる。

荒井：自ずとそうなりますね。

新野：コンテナを使うのはどうですか？

荒井：コンテナは必ずしも使わないケースもあります。ただ、だいたいは可用性や、実はKubernetesはアプリケーションのCI/CDとものすごく相性がよくて、アプリケーションのライフサイクルを回すときはコンテナを使ったほうが早いし、便利で楽なんですよ。

新野：必然的にCI/CDで回して、コンテナとKubernetesを入れる話になりがちだということですね。

顧客のミッションを一緒にこなす重要性

新野：でも、お客さんは使ったことないわけじゃないですか。「いや、CI/CDやったことねぇよ。コンテナをこれから始めるんだけど」というときに、荒井さんはどういう支援をするんですか？

荒井：弊社の場合は、そこにプロフェショナルなエンジニアをアサインしています。プロフェッショナルなエンジニアとして、弊社の中のエンジニアに加えて、実は青山さんにも手伝ってもらってます（笑）。

ほかにも、ビッグデータの達人がいて。そういった方をプロジェクトチームに入れていくんですね。そうすると非常に高度な問題が一瞬のうちに解決するので、それはすごいですよね。

新野：それは従来の支援の仕方と違う気がするのですが、どこが違いますか？

荒井：1つとしては、我々がお客さんのミッションを一緒にこなさなければいけないんですよね。お客さんのやりたいこと・やるべきことを一緒に考えて実現するのが弊社のミッションです。

言われたとおりのものを作って「はい、終わり。あとは売れるかどうか任せる」じゃなくて、「どうやったらこれって、世の中に対して価値が出るの？」を一緒に考えた上で作っていくところです。

新野：まさに安田さんが企画部門と開発部門を同じにしたと話されていたことと、文脈的に近い気がしますね。

荒井：そうですね。だから、お客さんの企画部門と開発部門は同じアジャイルチームに入ります。だいたい企画の人はPOという立ち位置に入って、開発の方はデベロッパーやアドバイザー的に入ったりするんですが、チームはワンチームにしていますね。

最初は開発の方向性を合わせるためにものすごく力を使います。そのためにアジャイルコーチが徹底的にチームに考えさせます。「本当にそれ必要なの？」「いらないんじゃないの？」と言われて、「えっと……」となったらある意味負けです。「いや、それはこういう価値があるから必要です」と言えるような状態まで持っていきます。

いつでも落とせるように作るメリット

新野：青山さん、人を支援したり、自分の会社でクラウドネイティブなシステムを作ろうとしているなかで、どんなハードルを超えてきたか、あるいはこの先どんなハードルが見えているか、少し教えていただけませんか。

青山：ちなみにお二人が言ってたような問題は、まず弊社のようなWeb系のテクノロジー企業だと、ほぼほぼ解決されていることが多いです。

新野：課題とは、組織的な課題だったり、企画と開発が一体化していたりということですね。

青山：はい。基本的にはDevとOps近い位置にいるので、そこはうまく回っているかなと思います。

ただ、クラウドネイティブなアーキテクチャにしていくときに、弊社でもまだ「これは落とさないで欲しい」「今はこれ更新できない」「更新したくない」ということもたまにあります。それをまずは変えていってもらっていること、変わってきたことが最近の実感としてはあります。

新野：それはどっちに変わってきたんですか？　「落としたくない」というのを「わかりました。落とさないようにします」なのか。

青山：もちろん違います。落としても大丈夫なようにシステムに変わってきているのが非常にいい傾向かなと思います。そうやってやっていくと、いつでも落とせるようなアプリケーションを作るように心懸けてくれるので、いつでも新しいビジネスロジックやアプリケーションをすぐに提供できる土壌ができ、ビジネスインパクトのあるコードがすぐに提供できるかなと思います。

CI/CD・Kubernetes化は短期的にはコストである

新野：それは技術的なアプローチで解決していたという意味でいいですか？

青山：技術的といえば技術的なんですが、そういうふうにやっていく風土をつくることだとは思います。

逆にKubernetesがいい例で、Kubernetesを使うとそうせざるを得なくなるんですよ。Kubernetesを使うには「こういうシグナルが来たらこういうふうに落ちます」「アップデートのときに絶対にすべてを停止させていく」という仕組みだったり、そのレールに乗っかることによって、逆にそういうところは半強制的に徹底できるのは良かったかなと思います。

新野：じゃあ、ツールと組織が一体となって変化していくイメージを思い浮かべたんですけど、そういう感じなんですかね。

青山：そうですね。別にツールありきで、ツールを入れることがもちろん目的ではないんですが、結果的にそうなっている部分はあります。ただ、誰かがKubernetesを知っていて入れていく決断をしたのはいいんじゃないのかなと思います。私の話じゃなくて、ほかのプロダクトでもそういう優秀なエンジニアがいます。

新野：開発の面で、CI/CDを入れるときの苦労やハードルがあれば教えていただけませんか？

青山：ないですね。弊社はもうCI/CD完備です。

新野：最初から。ある意味クラウドネイティブ時代の会社ですよね。

青山：そうですね。唯一あるとすれば、CI/CDやKubernetes化は単発的に見るとコストでしかないんですね。今100時間かけてそういうことを達成したとしても、ペイできるのは3年間をトータルすると200時間浮いたり、価値のあるものをすぐ提供できてお金を生み出せるところです。

短絡的に見ると、いかに余剰なリソースを作って投資できるか、リソースを確保するか、説得する必要はあるかなと思います。

新野：なるほど、確かに。今忙しくて新しいものに手をつけている暇がない状態は、IT業界だとよくありますよね。

青山：はい、うちの会社もたくさんあります。

新野：そこはなにか決断するきっかけはあったんですか？

青山：いや、説得するしかないですね。別にそれに対してダメという会社でもないので、熱量を持ってちゃんと説得すればいいかなというところですね。

クラウドネイティブ導入における課題

新野：なるほど。一方で、これから解決しなきゃいけない課題があるとしたら、何だと考えていらっしゃいます？

青山：これから解決しないといけない……。技術的には、もっと複雑性が増したときにサービスメッシュを入れることなど、今後の手法を見ておくことですかね。

現状のクラウドネイティブは100パーセントなにもしないでいい状態ではなくて、どんどん進んでいくんですよね。それをちゃんと追って、それを導入していくかどうかの判断をしながらやっていくのが、未来永劫、今後の課題だと思っています。

新野：それはサービスそのものの事業会社のある意味の課題かもしれないです。自分でシステムを動かして、そのシステムを常にいいものにするには、同時にリサーチし続けなきゃいけないわけじゃないですか。

とくにKubernetesみたいな変化の速いものについては、何がアップデートされていくのか、それによって何が影響するのかを自分で判断して入れていかないといけないですよね。そういう組織づくりも大事なんですかね？

青山：そうですね。弊社の場合にも、外での情報収集や検証に業務時間をある程度充てていますし、社内にはそういうメンバーがたくさんいるので、ウォッチをして、技術的投資をしてより良いものを使っていくことは必ず必要かなと思います。

新野：荒井さんに聞いたほうがいいと思うんですけど、お客さんはあまりそういうことしたくなかったりしますよね。

荒井：そうですね。お客さんはわざわざ最初にコストがかかることを好んではいなくて、明確な理由がないとしないですよね。

新野：お客さんは「クラウドネイティブのメリットは欲しいんだけど、Kubernetesの最新情報まで俺は追ってらんねぇよ」というのが普通のお客さんの態度じゃないですか。それに対してはどういう提案をします？　「うちにお任せください」なのか、「いや、そこまでお客さんにやってもらう覚悟がないと、なかなか今の時代難しいんですよ」と言うべきなのか。

荒井：そこはお客さんの状況次第ですが、お客さんがそこは苦手だという場合であれば、弊社のエンジニアをアサインしてやっています。ただし、そのノウハウをお客さんと一緒に持っていないと、将来的に「○○さんがいないとダメだ」となってもらうと困るので、一緒にペアプロなどのワークスタイル、チームとしてしっかりノウハウを共有していくようにしています。

新しい技術へ追いつくには

新野：安田さん、どうですか？

安田：圧倒的にお客様の、お客様自身も新しい技術についていくスキルをすごく心配されていて。今いるメンバーにどうやって習得させて、スキルフルな人たちをどうやって雇うか。

IBM自身もそこは本当に強化していかないといけないと思っていますし、お客様もそこの危機意識を持っています。次のテクノロジーできっと自社の強みになるようなIT基盤のテクノロジーなんだけど、それをわかっている人はいないというですね。そこは課題に思われているお客様が多いです。

新野：IBMさんはというと主語が大きすぎる気がするので、安田さん自身はお客さんがそこまでリサーチ能力を持つべきだと思います？　あるいは、そこからはベンダーに任せてくれと。我々がお金をいただいて裏方は全部やったほうがいいと思うか。どうお考えですか？

安田：お客様自身も選ぶための知識だとか、ある程度「これは青い」「これは赤い・黒い・白い」を見分けられる情報量は持っておいたほうが、お客様のためにもよいと思います。

新野：そうですよね。でないと、お客さん自身が変なものを掴む可能性がありますからね。

というわけで、今日予定されていた3つのアジェンダ、「クラウドネイティブって何だろう？」「それを組み立てるための技術的な側面には何があるだろうか？」「それを実際に超えるためのハードルとしてどんなものがあるか？」というのを議論してきて、おおむね時間がやってまいりました。

ありがとうございました。

（会場拍手）