日本はクラウド導入の「抵抗国」　クラウド・ネイティブ推進を阻むもの

クラウド・ネイティブ活用のために必要なこと

及川卓也氏（以下、及川）：次に「クラウド・ネイティブを活用するために必要なことは？」です。クラウド・ネイティブ以前に、今我々が住んでいる日本のITの現状はどうなのか？　『ソフトウェア・ファースト』を読んでいただいた方はわかると思いますが、私自身危機感を持っていて、おそらく登壇されている3人もそうだと思います。

典型的なのは、クラウドへの移行がほかの先進国に比べて遅れている。それ以前に、ITのリテラシーが遅れている。

なので、クラウド・ネイティブと言っていますが、日本のITのイケていないところということで、そもそも何が必要なのかをお聞きしたいと思います。今度は羽山さんからお話しいただいてもよろしいですか。

羽山祥樹氏（以下、羽山）：最近感じたことがあったので、それをお話しさせていただきます。ワールドワイドのことはわかりませんが、セキュリティ絡みの話が日本で流行って、クラウドが次に来たという、その順番が足枷になってしまっているのではないかと思います。

例えば、大手のSIerさんの中には、「ISMSを取ってます」といった感じで、非常にガチガチのセキュリティでマニュアル作ってやってきた人がいらっしゃるわけですね。そんな価値観を持っている人がわりと上の立場にいるわけです。そんな状況下でクラウドをやろうとして跳ね返されるということを感じています。

PマークだったりISMSをがっつりやった時代を経てのクラウドというのが、けっこう足枷になっているのではないかと感じました。

及川：クラウド時代にもセキュリティは重要であり、また新たな攻撃等も出てくるというところにおいて、セキュリティをないがしろにしていいという意味ではないけれども、セキュリティの本質は何かを考えないまま、昔からのクラシカルなセキュリティのメソドロジーで固めたもの以外は許さないという、変化に対して受容性がないところが足枷になっているということですかね？

羽山：おっしゃるとおりです。

及川：ほかのお二人はどう考えられていますか？

日本には変化を受け入れづらいマインドが存在している

広木大地氏（以下、広木）：そうですね。まさにその変化に向き合うというか、不確実性に向き合うというのがこの本の中で触れているポイントです。変化する前提で取り組まなきゃいけないなかで、日本にはその変化自体を受け入れづらいマインドが存在しています。

「ホフステッド指数」という、国民性を調査した1つのベクトルでお話しすると、日本人は不確実なものを恐れる、忌避してしまう度合いがとても高いそうです。

最近のGartnerさんの調査で、クラウドに対して後進国どころか「抵抗国」だと出ていて、インドネシア並みの普及率や成長率だったりします。

そういった変化を受け入れないマインドというか、組織的なマインドが醸成されてしまったことが、実験主義的なことや失敗を受け入れたり失敗したところから学んでいくところを途絶えさせてしまったのではないかと思います。組織としての文化醸成、マインドが変わっていくことが、一番必要なことかなと思います。

及川：松本さんいかがですか？

松本勇気氏（以下、松本）：「ソフトウェアは経営の重要な意思決定なんだよ」ともう少し認識することが、日本がクラウド・ネイティブを活用するために大事なことだと思っています。

というのは、広木さんがおっしゃったみたいに、組織戦略でもあるわけですよね。なので、そもそも会社の土台にソフトウェアがあることをちゃんと認識していかなければ、クラウド・ネイティブは片手落ちになってしまいます。

なので、経営者として「クラウドをどう使うんだ？」「ソフトウェアをどう使うんだ？」「そこに対して必要な組織はどうあるべきなんだ？」「我々の事業ドメインはこういうところだからこういう組織設計にして、この事業で攻めるべきポイントはここなので、ここに対してこんな内製チームを作っていく」といった経営的な意思決定が一番上にあって、はじめて全体が調和するような設計になるのがクラウド・ネイティブだと思っているので、それをきちんと認識することが大切です。

例えば営業チーム1つを作るにしたって、ソフトウェアを使ってインセンティブ設計と計測をきちんと加えていって、うまく分業をしながら組織スケールを狙っていかなければいけませんし、どんな領域においてもソフトウェアであることを認識していくのが、クラウド・ネイティブの活用に対して一番大事な骨になるのかなと思います。

SIerとの関係はどうあるべきか

及川：今ちょうど「内製」という言葉が出てきたのでそこをもっとお聞きしたいと思います。今他国との比較が出てきましたが、日本は、実装、もしくは設計も含めたところを第三者のパートナーに委託する率が非常に高いところが特徴的だと思います。クラウド・ネイティブ、ITをしっかり活用するというなかで、SIerとの関係はどうあるべきだと思いますか？

極端な意見として「全部内製だ」という話もあれば、「SIerに依存してもいいけれども……」というのはいろいろグラデーションがあると思います。いかがでしょうか？

広木：『ソフトウェア・ファースト』でも「手の内化」というのが書かれていましたが、全部が全部内製化しないといけないわけではないと思います。ですが、変化してほしい領域、つまり競争領域として力を入れていくところに関しては、ある程度内製でノウハウがないといけないと思います。

ソフトウェア・ファースト

ソフトウェアはハードウェアにくっついた付属物だと捉えているのが日本のズレだなと思っています。継続的に経費をかけていって作るものではなくて、資産として一括で計上してしまうと、あとは償却するだけのものみたいになってしまいます。それでは継続的に変化させるという前提ではないわけです。

ですが、ソフトウェアというのは本来はイテレーションを回しながら継続的に実験をして改善をしてということを繰り返すものなので、生モノです。どちらかというとウェットウェアをちょっと固くしたもの、脳みそをちょっと固くしたものがソフトウェアで、ハードウェアをちょっとやわらかくしたものがソフトウェアじゃないところに立ち返る必要があります。

例えば最近だとラボ型開発みたいな感じで、一緒にラボを作って、そこにユーザー企業さんも入ってノウハウを移転しながら作るというやり方もありますし、その活用の仕方や持っているもの、現時点でこれだけエンジニアが集中してるのがSIのビジネスだったりするなかで、ユーザー企業ができることは、どうやってノウハウを自社の側に持っていくのかという戦略を立てることです。

実際、内製化しましょうといってすぐ採用できるようなところばかりではないので、それこそプロダクトオーナーの内部化であったり、テックリードであったり、「せめてソースコードだけでも……」とか、マルチベンダーかとか、さまざまな方法の中でノウハウを自社に蓄積させられるアプローチを提案できるSIerさんが必要です。

そのなかで「いや、請負契約以外ダメだよ」と言ってしまう情報・情シス部門ばかりだと「そんなの作れないよ」となってしまうので、ここの距離感が溶けていくべきだと思います。

ソフトウェアに強い会社と、そこが弱くて活用していかないといけない会社が溶けてナレッジを蓄積していかなければならなくて、ベンダーもそうですし、ユーザー企業もそうですし、SIerさんもそうですし、そこをどんどん溶かしていっていただくと良いのではないかと思います。

及川：羽山さん、UXという観点で見たときにはどうでしょうか？　もう1個、デザインはやはり難しいところなので、外部に委託する話も普通にあると思いますが、こういったクラウド・ネイティブ時代においてはどのように捉えるべきだと思いますか？

羽山：良いユーザーエクスペリエンスを実現するためのSIerさんとの付き合い方みたいな感じですね？

及川：そうですね。

羽山：何事もそうだと思うのですが、仮に僕が発注者の立場だったとしたら、僕のお客さんがまずいて、僕が発注するSIerさんがいるわけです。SIerから見ると、発注者の先に発注者のお客さんがいるわけです。この発注者の先のお客さんをいかに幸せにできるかが、プロジェクトやビジネスで考えることです。

ですが、直の契約関係でいうと、例えば情報システム室の人とSIerさんの間だけで幸せになれるかみたいな視点から出られなくなってしまいがちです。

僕はUXデザインのコンサルティング的なこともしているのですが、気をつけているのが、発注者のお客さんに発注者よりも詳しくなること。そうすると本当にいいものが作れます。

及川：逆に事業会社側からすると、そういったSIerのパートナーを探しましょうという話になってくるわけですね。

羽山：はい。

及川：松本さんはどう思いますか？

組織や事業への帰属意識が高いほど、デプロイが速くなる

松本：事業会社、とくにスタートアップをずっとやってきたなかで、逆に今の会社に来てから発注している部分もけっこう見えてきました。それを見ていると、やはりデリバリーの速度が圧倒的に違うんですよ。

例えばスタートアップだと1日に何回デプロイするみたいな世界ですが、これが受発注の関係になってくると、「デプロイしていいですか？」「いいですよ」というコミュニケーションをいちいちしなければいけない。この時点でアジリティに大きな差が出てしまっています。

だから、この境界をどれだけなくせるかが付き合い上で一番大事なのかなと思っています。つまり、1つのチームの中にいるという関係にできるかが良い付き合いができるかの境界線かなと思っていて、それができないかぎりにおいては、僕自身も「発注するのは難しい」となってしまいます。

僕が事業側として求めているのは、1日に何回新しい実験施策をリリースできるのか。例えば1日10個リリースできてたら、それだけで月に1個リリースできる会社と比べると、営業日ベースで考えてもだいたい数百個の実験数の差が生まれて、ヒット率が1パーセントだとしたら、毎月2個ぐらい解答が見つかっているわけです。それだけでぜんぜん事業速度が変わりますよね。

なので、これに対応できる新しい取り組み方のモデルが求められているのかなと思います。そうすると、いま羽山さんの話に出てきたような、イタコというか、相手の考え方を自分の中に降霊させていくような、相手の立場になって一緒に改善して一緒にリリースしていく。なんなら許可も得ず勝手に改善していくぐらいのスピード感が求められていて、それができてはじめて良い付き合い方になるのかなと思っています。

広木：おもしろいのは、デプロイ速度とデプロイ・パイプラインに対してうまくできる会社とそうじゃない会社を、米国のDORA（DevOps Research and Assessment）のリサーチをもとに比較してみると、組織への帰属意識が高い会社はシステムのデプロイ速度が速いパイプラインができていて、そうじゃない会社は、例えば自動テストもそうだし継続的デリバリーもそうだし、このあたりのSAFeが弱いことが見えてきます。

実はその事業領域が、例えば「うちはERPだからもうちょっと固いんだよ」「うちは〇〇だから……」ということが支配的なのかと思ったのですがそうではなくて、事業領域は関係なく、組織や事業への帰属意識が高ければ高いほど、デプロイ速度への反映が速いという現状があります。

そんなパートナーシップみたいなものが自社内でもできていない会社はきっとあります。逆に言えば、パートナー、契約関係にあってもできるかもしれないというのもあるので、そういった新しい形をどうやって模索するかという側面はありますね。

及川：たしかに。

高速な開発を計る指標「d/d/d」

及川：パートナーシップに関しては、必ずしも外部だけではなく内部でもどうだろうかと考えられる話かなと思います。

そこで、設計・人材育成というところでお話しさせていただければなと思います。さきほどお三方から、スケールというのは必ずしもソフトウェア的なところだけではなく、組織もスケールするような設計をしなければいけないという言葉もいただきました。ざっくばらんに、「もしクラウド・ネイティブとして理想のかたちをとるならば、こんな組織がいいと思う」というところをお話しいただければと思います。

広木：端的に言うと、先ほど言ったように意思決定者が隣で、あるいは自分自身で、「今から改善します」というものをデプロイできなきゃいけない。つまり、分散的な権限移譲ができていないと分散システムで開発はスケールしないという極めて単純なことで、これができていないばかりに、分散システムを作ったはいいんだけど、分散統治できていないので、結局遅いということになりがちです。

僕は最近「d/d/d」という指標を考えていて、「Deploys per a Day per a Developer」というものです。1営業日あたり、1開発者あたり何回ぐらいデプロイしているかを見ています。例えば20営業日で20人開発者がいるとして、月に200回デプロイしている場合、0.5になりますよみたいな。

こういった指標をもって、高速な開発が人数に対して安定してスケールしていくかを見ていく必要があって、それができるような組織設計にすると、ビジネス・ケイパビリティごとに分けるというマイクロサービス的な考え方の本質により近づいてくるのかなと思いました。

及川：それは、スクラムでベロシティを見るということと同じような感じでデプロイを見るというイメージですかね？

広木：そうですね。

及川：なるほど、それはおもしろいですね。確かに、コミュニケーションのフローを見たときに、どこにコストや時間がかかるという分析する手法がありましたが、そういったことを取り入れないかぎり、改善が難しいですよね。嫌でも組織のところにアーキテクチャの考え方を取り入れなければいけないのかなと思います。

広木：そうですね。まさにサイクルタイムやフロー効率性を見るツールはどんどん増えていて、アジャイル方法論も、そういったスプリントのものから、フロー効率性みたいなものであったり、SAFeみたいな大規模アジャイルであっても、そういった製造業、製造のラインのメタファーを取り入れたフローを作っていくこと。

単位時間あたりでどれだけ効率的に機能改善できているのかに注目するタイプのプロジェクト・マネジメントのスタイルがどんどん主流になっていくんだろうと思います。それを軸にできる組織設計が重視されていく。

なので、一括ドン！　ではなく、継続的にパフォームしていくような組織にしなければならないということが、ソフトウェアと事業が一体化するということなんだと思います。

それぞれが正しい方向に意思決定できるようにする土台作りが大事

松本：そこにかぶせていくと、まさに言いたかったのは各所で意思決定できるということですが、もう1個は分散的に意思決定しても、みんな同じようにちゃんと動けることが組織設計上で大事だと思っています。

よく社内で「アジリティってなんぞや？」という話をするときに、例えばこれはOODAループみたいな、いわゆる軍隊から出てきたものですが、大隊からどんどん分割されて小隊が動いていて、例えば「通信途絶してもきちんとミッションを遂行できるか？」が一番大事なところだと思っています。そういった非通信環境下においても、ちゃんと意思決定する土台が揃っていることが組織設計上において一番大事だと思っています。

自分が数千人をマネージするなかでいつも意識しているのは、どちらかというと一番上から、「俺たちはどういうところを目指すんだ」「その目指すところに対して我々はこういう振る舞い方を大事にするんだ」「その振る舞い方を大事にする上でこういう施策をやっていて、あなたのいるシステムは、この中ではこういう位置づけのものなんだ。負うものはこれなんだ」。

そういったその場に置かれたときに転がりだす方向が明確に、力場が形成されているイメージがあると、組織がスケールしたとしてもより分散的な意思決定が正しい方向に噛み合っていることが言えるようになります。

つまり、それぞれが正しい方向に意思決定できるようにする土台作りが、クラウド・ネイティブな組織づくりの上で大事なのではないかと思っています。

及川：そこは米国ではけっこう使われていて、日本にも普及しつつあるOKRみたいな目標設定と重なる部分ですよね。

松本：そうですね。OKRって、組織を分散型にしていったときに各コンポーネントがどんなコミュニケーションを取っていて、最終的にどんなシステムになっているかをそのまま表現するツリー構造だと思っています。なので、OKRや目標設定の方法は、整合性を保つための1つの方法なのかなと思います。

誰に価値を届けるための技術か？

及川：ありがとうございます。羽山さんはいかがですか？

羽山：今の話に続きますが、分散的な組織の中でみんな同じ方向を向いて意思決定をできるようにする。そのときに、僕の経験的にもですが、何を軸に置いておけばみんなが同じ方向を向けるかという話です。

それにはいくつか候補はありますが、先になんにもないとどうなるかというと、各人がそれぞれの立場で語り始めるので、SIerさんの例とかだとわかりやすいですが、作りやすいものを語る人と理想を語る人と保守しやすいものを語る人、あるいはビジネスの利益を語る人といった感じで、いろいろいるわけですね。これを同じ方向を向かせるために僕自身がいつもやっているのは、まずユーザーを中心に置くことです。

結局、クラウド・ネイティブでものづくりしているときに、「誰に価値を届けるためにそれをやっているのか？」というところを技術を使うときに忘れてはいけません。

テクニック的なところをお話しすると、漠然と「ユーザーの立場で考えなさい」と言われても難しいですよね。「ユーザーの目線になってください」といくら社内で言っても、その言葉でユーザーの目線になれる人はいません。

ユーザーの目線になるためには、きちんとユーザーに会いに行って、話を聞く。そして彼らの言葉の裏に何があるのかみんなで掘り下げて考えて、それを共通化する。それを中心に置くと、はじめてみんながユーザーの目線になれます。そんな組織が大切だと思っています。

及川：今のお話を聞くと、やはりソフトウェアの設計に近いところがあるのかなと思いました。

例えば各所で意思決定できるようにするという話は、自律分散というものを考えるのと同じように、組織においても自律分散するにはどんなコミュニケーション・フローが必要なのかにも関係してくるかなと思います。

今の話も、ユーザーをよく知るといっても実態を知らないと、ソフトウェアにおいてはどうしても計測するための元の指標がわからなきゃいけないというところと同じ話かなと思いました。

「人材育成」の観点から考える

及川：ここでもう1つ、人材育成というテーマがあります。例えばそんな組織になったとして、どんな人材が必要なのか？　日本のIT人材、とくに事業会社ではそういった主体性を持っている方がなかなか少ないところはありますが、どのような育成方法を取ればいいと思われますか？

例えば、羽山さんが今言われていましたが、ユーザーのことをちゃんと理解することも「面倒くさいよ。それは誰かがやってくれればいいよ」という人がけっこういらっしゃるんじゃないかと思います。でも、ユーザーのことを理解して良いものを出そうと思うように社員の意識を変えていくためには、どんなことが必要なのでしょうか？

羽山：ユーザーのことを知りたいと思ってくれるようにするスタンダードな方法で僕がおすすめしているのは、まず「情報を細かく見ましょう」ということをお伝えしています。

例を挙げると、みなさんIT系の資格をお持ちかと思いますが、資格を取る人のモチベーションの調査をしたことがあるんですね。どんな心理があって資格を取るのか。

僕が調査したときのインタビューをサマリーしてお話しすると、こんな感じの話が聞こえてきます。「あの資格を取ると会社の中で報奨金が出るんだよな。あれはけっこうおいしいよな。でも、あの資格を受けようとすると5,000円かかって、さらに参考書も3,000円かかっちゃうんだよな。でも、資格は体系的にできてるから勉強にもなるような気がするし、履歴書にも書けるかな。でも、日曜日全部つぶれるんだよな」みたいな感じで話が流れていきます。

みなさん、今お話ししたなかでいくつの心理があったと思いますか？　たぶん1～2つくらい頭に残っていると思うのですが、物事をなんとなく流していると、今の速度で情報が入ってくるので、普通にしていると1～2個しか汲み取れないんです。でも、今、僕は5つの大きな心理を入れています。

話を分解していくと「社内で報奨金が出る」で1つ、「5,000円かかる」で1つ、「3,000円かかる」で1つ、「資格が体系的」で1つというように、細かく分解していくと、それぞれ違うことを言っていることがわかります。このように、ユーザーを理解する文化や人材育成のためには、まずは細かく見る習慣を身につけましょうと話しています。

及川：それは、ユーザー理解だけでなく、社内のコミュニケーションでも非常に必要なスキルのような気がしました。ありがとうございます。

課題を設定できる能力をつけることが重要

松本：今の話はもうちょっと抽象化できるのかなと思っていて、「人材育成上、何が大事なんだろう？」というときに、課題解決型という振る舞い方のスタイルがあると思うんですけど、今の羽山さんの話はそれを端的に表しているのかなと思いました。

結局、課題を設定できる能力をつけることだと思うんですよね。だから、例えば私が担当しているこのサブシステム1つは、何を課題と捉えなければいけないのか。目的はここにあるけれど、それに対して今はどんな制約条件があって、それに対してどういう課題があるのか。

これを認識した上で、「どの技術を行使するのか？」「そもそもこれはマネージドでいいよね？」「ここはまだファジーで変化しやすい領域で、不確実性の高い領域だから、ここは我々が作っていこうよ」という課題を認識する。

課題を設定できた時点で、だいたい解決できると思っているので、だからこそ自律的に意思決定する上で、与えられた制約条件から課題を設定できる能力が大事なのかなと思います。そういったところを育成をしてあげる、ガイドしてあげることが大事かなとは思います。

及川：わかりました。それはいち個人だけでなく、企業として日本が苦手なところなのかなと聞いていて思いました。

広木：大きい会社の方にはとても優秀な方が多くて、「なぜ全体としてそういうことをしちゃうんだろう」ということがけっこうあります。純粋に能力の問題じゃなくて、そもそも「失敗してもいいよ」「失敗してから学べるよ」という環境が与えられてないのが大きいのではないかと僕は感じています。

僕としては、失敗は福利厚生だと思っていて。ベンチャーなど自分で意思決定して挑戦して失敗した体験が与えられる場所や、与えられるようになっていると、そこから人間は成長していったり目の向き方が変わっていくなと思っています。

これが「絶対失敗すんなよ。お前！」とずっと圧をかけられて、「もうこれだけやってればいいから」と言って絞った範囲で前例と同じことをただrun the businessすることしかしていないと「そりゃ優秀な人を連れてきてもなんにもできんわ」という状況にどんどんなってしまいます。

なので、失敗から学べたり、失敗するのが当然でその数をどんどん増やして学んでいこうという組織的な文化を作ったりマネジメントしていくことが、人材育成では重要かなと思っています。

及川：なるほど。そこもなにか壊れることを前提にしているソフトウェア設計と近い考え方なのかなと思いました。それではお時間になりましたので、パネルディスカッションは以上とさせていただきます。ありがとうございました。

（会場拍手）