Buildで展開される最新のMicrosoftテクノロジー

及川卓也氏(以下、及川):今回のBuildで(発表されていたのは)、たしかエッジがコンテナで展開できるんですよね。これは実はすごいんじゃないかなと思っています。

先ほどのホワイトボックスでネットワークもソフトウェア化しているというSDx(Software-Defined anything/ソフトウェア定義)的な話は、コンテナの世界をKubernetesでやるというのは、その世界でIoTのデバイスまで全部やってしまうんですね。

だから、ネットワークが今後いろいろ変化していったとしても、そこがKubernetesでコントロールできるならば、「これはエッジじゃなくてクラウド側で」「ここは今、帯域がこの状態だから、エッジ側に持っていって」ということが、全部制御できるようになるような世界ですよね。

澤円氏(以下、澤):そうですね。実際にBuildの中でも、Azure IoT Edgeというものでデモをしながら、DJIのドローンを使って実際に見せるんです。それで、その中にAIが組み込まれているという。そこらへんが全部一気通貫になっているんですよ。

当然、その中にクラウドネイティブになっているものがあります。いわゆる人が見て何かをやっているわけではなく、それ(ドローン)が勝手に動いていって、自立的にそういったデータのやりとりまで行う時代になってきたわけですね。

及川:なるほど、わかりました。

藤井彰人氏(以下、藤井):エッジ側もきっと多段になると思うんですね。コンテナの動くモジュールも、今は全部クラウド側に入っちゃってますけど、それがMECとかモバイルの基地局みたいなレベルのエッジもあれば、それこそゲートウェイ的な部分のエッジ、IoTデバイス側での本当のエッジのところもある。そういった多段のかたちになって分散していくのかなと思いますね。

及川:フォグ(コンピューティング)というのは、その中間層みたいなことを言っているイメージなんですよね。

藤井:たぶんね。そうですね。

経営層の隣でコードを書いて遊びたい

及川:このIoTの話題もそうですし、触れていなかったVR/AR/MRとか、開発系も含めて、会場からのご質問を伺いたいと思います。

ここからは、前半に登壇していただいた井上さんと東さんにも質問があれば出ていただくかたちにしたいなと思います。でしたら会場の方、何かご質問があればぜひ拾いたいんですけど、いかがでしょうか。

:(誰も)手を上げてくれないと及川さんが指すの?

(会場笑)

(客席挙手)

及川:はい、じゃあお願いします。

:素晴らしい。ファーストペンギンは本当に素晴らしいですね。

質問者1:私はもともとエンジニアだったんですけれど、今の会社では経営企画(の部門)に入っています。何がしたいかというと、経営層の横でコード書いて遊んでるということをしたいなと思っているんです。

KDDIさんとかMicrosoftさんには、経営層の近くで(エンジニアが)遊んでいられるような事例や、それに関するインスピレーションが与えられるような事例はあったりするんでしょうか。

:うち(Microsoft)にエバンジェリストの西脇(資哲)というのがいるんですが、まさに彼なんかはそれに近い立場じゃないかなと思います。彼は端的にいうと、社長がキーノートなどでしゃべったあとで、それを受けてデモをやったり、技術的な話をしたりする人間なんですね。

「遊んでる」と言うと殴られると思うんですけれど、(彼は)遊んでいるわけではなくて、最新のものや、とにかくいろんなものをわかりやすい形で表現をする仕事をしています。もう1つの役割は、社長なり経営層が別のところでドヤ顔ができる状態をつくってあげるというのが大事かなと思います。

その人がちょっとスマホか何かでちゃちゃっとデモを見せて、経営者たちの集まりの中で「おおっ、すごいですね!」と言われると、これはすごい成功体験になるんですね。そうすれば、どれだけ遊んでいても怒られることはありません。

「もっとおもしろいものをくれ」と絶対に言ってくると思います。だから、経営層にドヤ顔をさせるために、27パーセントくらいの時間を使って、あとの73パーセントは好きなことをやればいいかなと思います。

質問者1:ありがとうございます。実名まであげていただいて(笑)。

藤井:経営企画みたいなことをされているのであれば、もうまっとうな、外に出てなにかプロダクトを売るような社長なのかしら?

質問者1:そうですね。一応社長は完全に営業畑の人で、逆に……。

藤井:なにかモノを売ってる会社?

質問者1:モノは売っていなくて、電子書籍の流通をやっている会社です。

藤井:それだったら、明確にデータアナリストみたいなところを見せつけるのが、今のトレンドじゃないかなあと思います。経営企画の人は、どちらかというと経営方法論みたいなところで育ってきてるから、そこにデータの解析のリアルタイムさを見せつけるのは、非常にいいんじゃないかなと思います。遊んでいたらクビになりますよね。

(会場笑)

質問者1:良い意味で遊んでいるというか(笑)。

藤井:ぜひ、データで遊んでみるとおもしろいのかなと、私なんかは思いますね。

質問者1:アクセスできるデータがまだ少ないので、そこを集めてくるところから……。

:ハッキングしちゃって。

(会場笑)

及川:Microsoftのセキュリティ担当者から(笑)。

質問者1:さすが(笑)。ありがとうございます。

ジョブ・ディスクリプションなくして責任の所在はない

及川:他はいかがでしょうか。たくさん手が挙がってくれると嬉しいです。そのまんなかの方。もう1回手を上げていただいてよろしいですか。

質問者2:今日はお話ありがとうございました。エッジ側を含めて、とても可能性が広がっているなかで、そのアーキテクチャを誰が考えたらいいのか、全体の責任を誰がとったらいいのかが非常に複雑になってきて、すべてができるオールマイティの人がなかなかいない気がしています。

先ほどシリコンバレーでは、数時間単位でいろんな人たちが(仕事に)コミットする、というお話がありましたけれども、どうやって責任をとる人を決めて、どうやって異なるスペシャリティのある人をつなぎ合わせて、責任がとれるようにしていけばいいのか。それについて、みなさんがどうお考えになられてるのかをお伺いできればと思います。

:じゃあ先に僕から。これは2つの考え方があると思うんです。例えばちょっと大きい企業で、責任の所在を明確にしないと経営そのものが信用されなくなる、というのであれば、これは実はまったく違う観点です。

僕があちこちで働き方改革の話をするときに、必ず言っている話なんですけど、ジョブ・ディスクリプションがない会社は圧倒的に多いんですよね。

僕から言わせると、そもそも「誰が責任をとるのか」じゃなくて、「責任範囲を明確に定義してないのに、そんなこと言う資格はそもそもないでしょ」なんですよ。「先にジョブ・ディスクリプションを作ってからにしなさいよ」なんですよね。

そのうえで、新しいことをやる時に誰が責任をとるのかを語るべきであって、それ以前に、社員の責任の所在もはっきりしてないのに、何かの行動に対してだけ「責任をとれ」というのはおかしいと思うんですね。そうなっていると、おそらくはイノベーションなんて永遠に起きないですし、前に進むことも基本的にないと思うんですよ。

もしそういった大企業や、ある程度の組織体ができている企業が、ジョブ・ディスクリプションがなくてそう言っているんだったら、まずは「全力でジョブ・ディスクリプションを作りなさい」ということなんですね。それがまず1つ。

新規事業に必要なのは早めに失敗して修正すること

:そうではなくて、もうちょっと新規事業的なものだったり、それこそスタートアップなどの実験的なものであれば、責任なんてものはとらなくていいと思います。失敗したら賞賛し、祝福をするくらいのカルチャーをつくることが大事かなと思います。その代わり、早めに失敗することです。

致命傷をいきなりくらうんじゃなくて、早めに失敗してすぐに修正できる。そういった流れ、サイクルでやっていくこと。責任をとるとなると、場合によっては犯人探しになるんですよね。そんな暇はないんです。そんな人を探している場合ではなくて、早く前に進むためには何をすればいいのかを考えておかなきゃいけない。

そのためには、責任をとる云々という話ではないんです。僕はオーナーシップという考え方でよく言っているんですけれども、「誰がこれのオーナーなんだっけ」というふうに言えば、必然的にその人は、誰から言われるでもなく責任をもって行動するはずなんですね。

そうしたら、「あ、これ失敗した、ごめんやり直す」。それでいいと思うんですね。それだけで次のステップに行けばいい。それが2つあります。

藤井:僕も澤さんの後半の考えと一緒です。失敗をできるだけ早くして修正して、正しい方向に結びつけていく。ムービングターゲットを追えるようにする。正しいことをしようとするから失敗するわけです。

とくにそういうイノベーションを目指しているところに関しては、それ(正しいこと)が変わっていくというふうに考えたほうがいいと思うんですよね。

私もKDDIで一番びっくりしたのは、企画開発部だったんです。アジャイルデベロップメントの仕組みがなかったんですよ。だからまずそれをつくるところから始めました。それで、そこのある流派でスクラムやって、POがこのプロダクトの責任を負う。スプリントをきっちり2週間でまわして、その度にみんなで評価をして、次はどっちの方向に進んでいくのかを決める。

アーキテクトの話はまたちょっと別かもしれないですけどね。そのアーキテクトがどこを目指しているのかをみんなで議論していれば、「誰から何を学べばいいのか」も明確になってくるので、それでムービングターゲットを追えるようにして前に進んでいけばいいのかなと思います。

メンバーシップ雇用の中ではテクノロジーは磨かれない

及川:ジョブ・ディスクリプションの話というのはそのとおりです。たぶん、日本企業はずっとやっていなかったことなんですよね。日本企業の雇用モデルはメンバーシップ雇用と言われていて、その人の職種・役割を定義しないまま採用し、かつ、その役割がなくなってもあなたの雇用は守りますから、ということをやっていました。

なので、やはり澤さんの言うとおりだと思うんですよ。それを変えていかないといけないなと思います。失敗を許されるような組織と、職種・役割を明確にしていくところの両方をやっていくことが、もしかしたらこういったテクノロジーを活用する組織において、必要なことなのかなと思いますね。

:そうすると、本当にスキルを持っている人が、テクノロジーを磨いていくところに集中できると思うんですよね。いつ営業にすっとばされるかわからないという今の状態になると、そのカッティングエッジの技術にものすごくコミットするにはやりづらいんじゃないかなと思っています。そこを救う意味でも、ちょっと意味があるかなと思いますね。

及川:(質問者の方が)期待されている回答とは違うところですが、そのアーキテクチャ設計が難しいというところは、私の期待を込めて言うと、Microsoftさんなりがテクノロジーで解決できるといいと思うんですよ。

要は、少し小さい開発であるならば、設計をIDEに落とせば、ある程度スケルトンコードを吐き出すというところはもう全然できてるじゃないですか。

ただ、少し大きいところのレベルで、さっき言った「5Gがあります、何があります」というところのネットワークの話なども入るような大きなシステムの場合、ここは、リスクのところは担保しなければならない。

SLA(Service Level Agreement)を入れたり、もしくは制約条件となるベンダーリスクも、世間の評判みたいなものを学習してくれるところまで取り入れられるならば、今はGitHubのところのコードをベースにしてインテリコードができるくらいだから、不可能じゃないと思うんですよね。

そうすると、ある程度こんなアーキテクチャにいった場合、「こういうリスクがあります」「こういった時にこういうリスクがあります」というようなところまでサジェストできる未来は、なんだかMicrosoftさんならできそうだなと思うんですよね。

:十分可能ですね。とくに、うちの会社の場合だと、GitHubの前にLinkedInを買収してるんですよね。LinkedInというのは人材データベースそのものなので、スキルセットを数値化して、分析の対象にすることができる。これは別に個人情報をいじるとかいう話じゃなくて、もうちょっとビッグデータ的な観点での話です。

そうなると、その人の動きや働きと、さっきおっしゃっていたようなテクノロジーによる何かの解決方法をリンクさせることは、現実的にできるんじゃないかなと思いますね。

及川:Microsoft Graphの拡張みたいなかたちですね。

:そうですね。まさにそういうことですね。