メソッド屋のブログ

米マイクロソフト Software Development Engineer 牛尾の日記です。ソフトウェア開発の上手なやり方を追求するのがライフワーク。本ブログは、個人の意見であり、所属会社とは関係がありません。

「知らないこと」を恐れないマインドセットが技術導入を加速する

先日、米マイクロソフトの Redmond キャンパスで行われたマイクロサービスのハックフェストに2週間ほどサポーターとして参加してきた。 そこで気づいた日本との技術導入の差の秘密について気づきをブログに書き留めておこうと思う。

f:id:simplearchitect:20161202162159j:plain

 ハックフェストというのは、お客様のガチの環境もしくはそれに近い環境/テーマで行うハッカソンだ。

例えば DevOps の文脈であれば、自動化したら効率化されそうな部分に関して、マイクロソフトの製品チーム、エバンジェリストがサポートしながら、お客様自身が我々と一緒にハックをして、実際にお客様の環境を自動化してしまうようなイベントだ。 Hello Worldチュートリアルレベルではないので、お客様の環境が本当に自動化されてリードタイムが短縮されたり、我々にとっても、現場の難しい問題を知り、それに対してソリューションを作ることができるので、スキルアップまでできるので私は大変気に入っている。マイクロソフトはこのイベントをプッシュして展開している。

 さて、今回のイベントは、米国、カナダ、欧州のマイクロソフトのパートナーを集めてマイクロサービスのハックフェストを実施していた。ほとんどのパートナーは、Service Fabric というマイクロソフトの激アツのマイクロサービスの PaaSサービスを試していた。

azure.microsoft.com

 私が驚いたことに、Service Fabric はまだ出てそんなに経っていないというのに、ガンガンに使ってたり、基幹業務系に使っていたり、通常はクラウドサービスなのに、オンプレに自らインストールして使っていたりとそのレベルの高さに本当に驚かされた。

 彼らとディスカッションをしても、正直相当レベルが高かった。普通にBoundary Contextとか、Conways's Lawとか、DDDとか普通に知っていて当然のように活用している。一体この差はなんなのだろうか?今回は、2回 x 5日間のハックフェストを体験して気づいた彼らの新しい技術に対するマインドセットをシェアしたい。

準備不足からくる不安を感じる

正直このハックフェストが始まる前に、私は相当準備をしていった。Service Fabric はとても便利だが、マイクロサービスの基盤なので、しっかり理解しようとしたら相当いろいろ学ばないといけない。 私は事前に自分でコードを書いたり、CI / CD パイプラインを作ってみたりしていた。そうでないと、私はハックフェストで役に立つはずがないから。しかも、相手の会社さんは毎日のようにプロダクションでService Fabricを使い倒しているパートナーさんもたくさんいる。しかも、日本より技術的に進んでいる米国でのハックフェストなので、正直いうと通用するか相当自信が無かった。自分の準備が十分かどうかわからないままハックフェストがスタートした。

Julien 衝撃のひとこと

f:id:simplearchitect:20161202164843j:plain

初回のハックフェストは、DevOpsチームからは私のみの参加だったが、2回目のハックフェストでは、Julienという同僚が参加をしてくれていた。その時に、私が彼に「来てくれてありがとう!ちなみにService Fabricどれぐらいやったことあるの?」と聞いた時の彼の返答は衝撃だった。彼は自信満々にこういった。

やったことないよ。

 えええええーーーーこんなガチのハックフェストなのに!そういえば、日本であったBot frameworkのハックフェストの時に来日した、むっちゃ技術力の高いEricに、Bot frameworkの経験を聞いた時も「やったことないけど、今日やるわ」だった。当時は彼は死ぬほど優秀だから、できちゃうんだろうなと思っていた。もちろんJulienは最高に優秀だけど、難易度の高く、ユニークなマイクロサービスのPaaSにノー準備で挑むってどういうことだろう?すごい度胸だ。彼もむっちゃ優秀なんだなと思っていた。

docs.botframework.com

準備を全くしなかった人の成果

 初日が終わって、彼はとてもエキサイティングしていた。彼はハックフェストのおかげで、IaCを使った、ADのセキュアクラスタの構成も体験できたし、CI/CDパイプラインもできてとても良かったと言って喜んでいた。  ガラス越しに彼がサポートしているチームの部屋を見ると、彼が堂々と、ディスカッションしている様子が見れた。後日談だが、彼のサポートしたチームはDevOpsの要素で素晴らしい成果を上げていた。この時点でも、私は単に彼が優秀だと思っていたのだが、あることで考えが変化していった。

f:id:simplearchitect:20161202171954j:plain

Jason の提案

私は 幾つかのチームをサポートしたのち、最後にJasonというエバンジェリストのいるパートナーのルームを支援していた。このチームは、パートナーが作っており、リリースされているプロダクトを、Service Fabricで動かしてみるというガチハックをしていた。担当の彼はMVPで相当レベルが高い。

f:id:simplearchitect:20161202165104j:plain

私はCI/CD を支援する予定だったが、まだ、彼がマルチパートのデバッグで苦労しているので待ちの状態だった。そんな時、Jsonは彼にこういった。

「俺に見せてよ。一緒にデバッグしよう」

 製品のコードを書いているのは、彼だし、Jsonがコードのことを知っているはずもない。自分は「は?」という気分だった。そして、「これが原因じゃないか?」と言って彼と一緒に原因を探り始めた。彼が「知っているはずもない」ことについて。    その姿を見て、Eric, Julien, そして、Jsonの行動に関してあることを思いついた。彼ら、米国の技術者がいろいろできるのは、すでに準備して勉強しているからではなくて、「知ってようが、知っていまいが、とにかく躊躇せず一緒にやってみるから」じゃないだろうか?

 そう思った私は、Jsonと一緒に彼のデバッグを手伝うことにした。コードを読んだり、インターネットを調査したりして一緒に取り組んだが、問題を解決したのは、彼らより、もっとコンテキストやその技術を知らない「私」の仮説だった。彼も、Jasonもとても喜んで我々はハイタッチした。もちろん私も、完璧にそのコードを理解したわけではないが、他の3人とディスカッションしながら進めることで、そういった仮説にたどり着くことができた。みんなの勝利だ。

私の仮説は

彼らは、もともと、「知っていた」から優秀なのではなく、準備ができてようが、知ろうが知るまいが、果敢に本番環境に近い環境で、実際に適用してやってみて、そこから学んでいるから優秀になるスピードが速いのでは?

ということだ。確かに、検討をいくら重ねても実力はつかないし、結局のところ本番環境で発生する問題には対応できない。

「とにかくやってみる習慣」がスピードを生む

私は、まず調べて、理解してできるとわかってからやるというステップを踏む癖がある。日本の多くの企業もそうじゃないだろうか?その技術が十分に使い物になって、本番でも本当に問題なく使えるということがわかって導入する。そして、あのケースはどうだろうか?このケースはどうだろうか?と思考をめぐらす。

一方、彼らを観察しているともっと単純に考えているように感じる。この新しいテクノロジーを使うと、この問題が解決しそうだからまず適用してみる。ぐらいのノリで、単純に考えてそれを実行する。実行すると決めたら、そこのマニュアルがなかろうがバグを踏もうが、回避策を考えて実際やってみてそこから学んでいく。あれこれ検討していると、時間だけ過ぎていくが、その間はノーバリューだ。しかも、長い間検討したからといって、良い回答につながるかはわからない。

だから、まず「こうだったら、難しい」「ああいう時は上手くいかない」ということを考える前に、まず適用してみて、そこから学びを得ているように感じた。早く実践して、そこから学んで方向修正をしていく方が結局早い。DevOpsのプラクティスにも、Testing in production という考えがあることを思い出した。

www.itproguy.com

この2つの思考スタイルにいい悪いは特にない。ただ、おそらくソフトウェア産業においては後者のスタイルのほうが圧倒的にスピードが出やすいだろう。なぜなら、現在のソフトウェアは、バージョンアップや、新しいサービスの出現のスピードが非常に早い。だから、それが本当につかえるか調査しているうちに次のバージョンが出てしまう。

「知らないこと」を「悪」にしない空気が重要

 彼らは何をするにもあまり準備をしない。そして、時間内で如何に成果を出すかに集中する。だから、彼らは「知っている、知らない」とか「準備できている」とかは、さほど重要ではなく、それぞれのメンバーが貢献できるところで貢献して、全員で成果を達成するという感覚が強いように感じる。誰がどんなスキルをどれだけ持っているとかはあまり誰も気にしない。 だから、私が知らないことがあっても、一回も不平不満を言われたことがない。

f:id:simplearchitect:20161202165612j:plain

 ただ一つ言えるのは「知らないけど、一緒にやってみましょう」は非常に評価されるということだ。今の時代、たとえマイクロソフトに勤めていても、そのサービスの全容を把握するのは一人の人間では不可能だろう。  これはマイクロソフトだけではなく、一つのサービスの全容を一人の人間が把握するのは無理になってきていると思う。一人のスキルですべてカバーすることも。  日本だと、プロが「知らないこと」があると、批判の対象になりやすいが、これは恐れを生んで、必要以上の準備につながっていると思う。だから、「知らないこと」があっても、当然であるという空気作りも重要と思えた。

日本では、「知りません」というのは勇気がいるが、向こうのメンバーを観察していると、本当は多少知っていることでも、「知らない」と簡単にいうのだ。「知らない」のは何も恥ずかしくない。ただ、彼らはそれでもその場で問題を解決しようとする。 助けを求めたり、人に聞いたり、お客さんと一緒にハックしたり。持ち帰りをせず、その場で解決しようとする。

「知らないこと」にアタックすることで成果が出やすくなる

f:id:simplearchitect:20161202165419j:plain

 ハンズオンやレクチャーの形式というものは、結局のところある人の知識がある人に移転することでしかない。ハックフェストは一つの例だが、誰かが一方的に物事を知っている事を準備するのではなく、とにかく集まって、みんなの頭脳を結集して、問題を解決するスタイルだと、二人分の知識どころか、二人が知らなかった部分にもトライすることになる。そうすると、その時間内で二人が従来持っていた以上の知識を獲得することになる。これはとても効率的だ。

  新しい技術の獲得、適用に関してもこういう性質が関係しているかもしれない。実は新しい技術の初速のキャッチアップは日本の方が最近は優れているように感じる。例えばマイクロソフトの大きなイベントがあっても、次の日にはすでにまとめサイトができあがっている。これは早すぎる。

しかし、そのあとにその技術を本当に使われるか?となるとそうはならない。一方米国では、初速ははやくないものの、自分たちのアタックしたい問題にそれをともかく使おうとする。リスクの検討をがっつりするのではなく、これを試してみようとおもったら、とにもかくにもやってみる。

 そして、知らないことにチャレンジしていくと、実際の問題に対応しているので複雑で難しユースケースにも対応していくことになるので経験が積まれる。さらに、自分がわからない状況でもどうやって問題を解決していけばいいか、その場でどうやってバリューを出していけばいいか?という訓練ができることになる。

 米国では、技術者は基本コンピュータサイエンスを出ているというのもあるが、それよりも、あれこれ考えず素直に「ともかくやってみる」 作戦によって、たくさんの工数をかけることなく、効率よく新しい技術を獲得してスキルアップしていっている気がする。

日本でどうやってスピードアップをしていくか?

f:id:simplearchitect:20161202170728j:plain

言葉だけは知っていたが、日本人の性質として語られるものに「不確実性の忌避」というものがある。不確実なものを嫌う性質だ。今回の体験で、文化の専門家が語る「不確実性の忌避」の性質の具体例を自分で体験できた気がした。自分はチャレンジングな性質だと思っていたがその自分がしっかり「不確実性の忌避」の性質をしっかり持っていたのだ。  こういう日本の「文化」に基づく、スピードの遅さに対処する方法としては、私は「西洋文化インストール」と言っているが、彼らの考え方を理解するところから始めるといい。大抵それは、彼らが優秀だからできることではなくて、それが理解できれば日本でも全然実践可能なものばかりだからだ。だから、チームで、マインドセットに関してチーム内でシェアして、チームがそれを気に入ればその考えで作業を進めると楽なことが多くなるだろう。

doc.co

例えばこんなマインドセットでどうだろう?

「Just Do It」

  • 自分の仕事に自分が主体性を持つ
  • 知らないことは悪ではない
  • 知らないことでも、自分のできる範囲で他の人を助ける
  • 準備しすぎていないか?、何をやらなくてもいいだろうか?を自己に問いかける
  • 例外をあれこれ考えず、単純に新しい技術をまず本番適用し、本番から学ぶ

これは、DevOpsのマインドセットにもつながる内容だ。このマインドセットは結構難しい。可能であれば米国の開発チームと一緒にはたらくと日本人でも、この辺りの感覚がわかるようになる。  次善策としては、皆さんのチームに、上記のマインドセットをグランドルールとして開発を進めてみるのはどうだろうか?

「知らないこと」のハックフェストが怖くなくなった

私もこのことに気づいてから、スタイルを変えるようになった。このハックフェストが終わった後Redmondのエバンジェリストチームの同僚が「Tsuyoshiお前、NodeJS強いか?」と言われた。今までだと「イヤーごめん、強くないわ」と言っていたところをこういってみた「さわったことあるよ。そこまで強くないけど。何が問題?」と言ったら「君の助けが必要だ」といって彼のオフィスに連れていかれた。 どうも認証周りがうまく動かないみたいだ。私は一緒にコードを読んで、とあるコールバックの部分の記述についてアドバイスしたらそれが正解だった。私はNodeJSなんて触ったことぐらいしかないし、彼はむっちゃいけてる技術力のあるエバンジェリストだけど、自分が知っているか、知らないかは気にせずとにかく彼を助けてみた。

f:id:simplearchitect:20161202171214j:plain

すると、自分もHello Worldレベルじゃない、NodeJSのコードを読む機会に恵まれたし、彼は早く問題を解決することができた。会議に出ても、自分が現状で持っているものを活用し、知らないことも、相手に聞く、相手と一緒に考えるなりして、その場でその問題を解決するような方向性に変えているが、結構かなりいい感じな気がしている。

「知らないこと」を恐れず、楽しむ習慣

その後「知らなくても」一緒にハックする習慣をつけると、その後の顧客からも常に喜んでもらえるようになった。「本当に生産性が高かったよ!」と。私はただ、知らなくても、知っていても一緒に「問題解決」を「その場」でしようとしているだけだが、これがかなりの効果とスピードを生んでいるようだ。自分のレベルが変わったわけじゃない。以前は「知らない」状況は非常に怖かったが、今は「知らないこと」が来ても成果が出せることがわかってきたので、逆に「知らないこと」がやってくると嬉しくなってくるようになった。

f:id:simplearchitect:20161202171057j:plain

おわりに

 こちらに来て何度も思っていることだが、彼らは日本より進んでいるし、技術力も総じて高いと思うが、個人の個体差が大きいわけじゃ 決していない。本の小さな「習慣」や「考え方」がちょっとだけ違うだけで差がついているだけだ。これは非常にもったいない。先ほど書いた日本の「準備を入念 に行う」「例外ばかりをたくさん考えてしまう」マインドセットは、時間をかけて精緻なことをしたいときは非常に役に立つだろう。 実際私がハックフェストや、同僚の問題を解決できたのは日本人のこの性質な気がする。  こういう日本人が、彼らの「速さ」の原因になっているちょっとしたマインドセットを獲得すれば、ガンガンに世界でも同じように活躍できるようになると思う。だから、私もいろいろ試して調査して、そして個人的に気づいたことをシェアしてきたいなと思っている。 

ハックフェストの成果として、Service Fabric のデプロイメント戦略について書いておいたの蛇足だが記載しておきたい。

blogs.technet.microsoft.com