メソッド屋のブログ

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

批判が少しだけ上手くなる方法を考えてみた [最終回]

職場が変わって、前の職場と比べるとよりインターナショナルになりました。今はアメリカ人の人はいてなくて、インド、メキシコ、ロシア、中国、エジプト、ブラジルかなりインターナショナルです。 f:id:simplearchitect:20200629123603p:plain

前回私は批判についての気づきをシェアしましたが、今までのブログの中でも1、2を争うぐらいに多くの人に読んでいただいたみたいです。そのリアクションの中で、多く含まれたコメントが「批判」と「非難」「中傷」はちがうというコメントが多くありましたの、今回はそのトピックに関して書いてみたいと思います。

simplearchitect.hatenablog.com

反対意見や批判が全くつらくない職場

私がアメリカに移ってから職場が2つ目ですが、今まで反対意見を言われたり、批判をされたときに心がつらくなったことがありません。日本にいたときを思い起こすとそうではなくて、批判や、反対意見を聞くと正直心がつらいと思っていました。私は炎上慣れしていてスルーも得意なのですが、どうしているか?というと単に通知を切ったりコメントを見ないようにしています。うれしいコメントやロジカルなものも沢山あるので申し訳ないのですが、そうでないとバズればバズるほど、自分のメンタルを守る手段がないからです。 f:id:simplearchitect:20200629123745p:plain

大抵の人は大丈夫なのですが、一部の人のコメントを読むと心がやられます。量が多いとボディブローのように効いてきます。人格否定みたいなものもありますが、おそらく本人は、そのつもりがなくても、私の心がつらくなるものもあります。これは一体何が違うのでしょう?

他人はコントロールできないので、何か自分がほかの人に対してそうしないためにうまい批判のコツはあるだろうか?気持ち良いディスカッションをするためには?という発想から考えてみました。ブログがバズると、どんなメッセージが作者に届くか?というのは私の炎上系のブログのはてぶとかを見ると体験できるかもしれません。Twitterはより激しいのを堪能できますw

b.hatena.ne.jp

批判の定義

[名](スル) 1 物事に検討を加えて、判定・評価すること。「事の適否を批判する」「批判力を養う」 2 人の言動・仕事などの誤りや欠点を指摘し、正すべきであるとして論じること。「周囲の批判を受ける」「政府を批判する」 3 哲学で、認識・学説の基盤を原理的に研究し、その成立する条件などを明らかにすること。

  1. to express disapproval of someone or something
  2. to give an opinion or judgment about a book, film, etc.

批判(ひはん)の意味 - goo国語辞書

CRITICIZE | meaning in the Cambridge English Dictionary

日本語のほうが若干キツイ感じがしますね。よく、技術者たるもの、「どんな批判も甘んじて受け入れたり、まさかりを投げ合って成長するものである」とか、言わることがあるようです。まるで、「願わくば、我に七難八苦を与えたまえ」とか言ってる戦国武将のようです。 f:id:simplearchitect:20200629133859p:plainそんな辛いことをしないとプロフェッショナルになれないのかな?と思っていましたが、アメリカに来てみるとみんな「ハッピーかどうか?」が重要であって、こんなノリが全くありませんでした。しかし、実際には意見が対立することなんてしょっちゅうあるわけです。じゃあ何が違うのでしょうか?同僚の発言を思い出してみました。

他人や、他人のアイデアを否定しないこと

観察してみた結果、すごく単純で、他人や、他人のアイデアを否定しないことが究極のポイントのようです。「えーそんなんやったら違う意見言えないやん」と思うかもしれませんがそんなことはありません。

否定されたときに心がつらくなる原因としては、「自分が否定された気分になる」ということが大きいと思います。私の職場のコミュニケーションを見ていると、日本にいるときによくあった「お前は間違っている」とか「それは間違っている」という発言は全く聞きません。

多分言ったら相当失礼な人と思われるかもしれません。ちなみに、日米文化の専門家のㇿッシェルカップさんが言っていたのですが、日本から来たマネージャが、パワハラで訴えられることが多いという話があって、このあたりが原因の一旦かもしれません。意外かもしれませんが、アメリカでは敬語はないですが、人に何かを依頼するときは相当丁寧な言い回しをします。

相手のアイデアを尊重して、自分の意見を言う

こういった反対意見を言うときや自分の意見を言うときに頻繁に出てくるフレーズが、「In my opinion」です。日本語でいうと、「自分の意見では」とか「自分の意見を述べさせてもらいますね」みたいなニュアンスです。 f:id:simplearchitect:20200629125635p:plain このノリで話すと、たとえ相手のアイデアと正反対の意見であっても、言われたほうがあまり「心にぐさっとこない」感じになります。ソフトウェアエンジニアの人でしたら、英語圏GitHubのコメントやディスカッションを見ているとノリがつかめるかもしれません。少なくとも、ガバナンスが効いているリポジトリはかなり平和です。英語が得意な方は、次のディスカッションとか見ていただければ雰囲気がわかるかもしれません。がっつり議論はしていますが、「感謝の言葉」や、「自分的には、、、」という言い回しにあふれてますので、とても気持ち良いですし、心にグサッとこないので、議論が効率的です。

github.com

アメリカだと、今起こってるような暴動系の話は置いとくと、大抵のことは、「人はこうすべき」ということがものすごーく少ない世界です。だから、「人」はそれぞれに魅力があり、自分ではない他人に対して「こうすべきだ」というのはおこがましいという雰囲気があります。私もその考えがとても気に入っています。逆に、「お前はこうすべきだ」とか「こうしろ」というのがコメントから透けて見えると結構心を持っていかれます。

具体例を考えてみる

具体例を考えてみましょう。例えば最初にリンクした私の前回のブログと一部意見が違う人のコメントで、上記のテクニックに沿っている人の例を見てみましょう。「お前は間違っている!」というノリではなく、「私はこう思う」というのを発信しているだけですので、このノリでコメントが来ても心がつらくなることはないと思います。

もっと激しい例でみてみましょう。残念ながら元ネタは、公開できないところで見かけたものなのですが、このようなニュアンスでした。

私は、高木先生の言ってることが正しいと思うので、牛尾さんのブログには賛同できません

まさに私のブログの内容の正反対の意見です。ただ、ここでも特に私自身を否定したり、私のアイデアを否定したりしているわけではなくて、「私は、このように違う意見を持っている」と表明しているだけです。ですので、まったく正反対の意見なのですが、私がこのようなコメントで心がつらくなることはありませんでした。意見が違う=相手を否定したいり、相手のアイデアを尊重しない とは違います。

先日同僚と意見が対立した時の話

先日私はあるアプリケーションのリリース作業を依頼されていて、作業していました。いろんな人にレビューをお願いして、もう大丈夫でマネージャに今日リリースするよという話をしました。私は同僚のあるコメントがあったのですが、正直重要じゃないと思ってコメントしてなかったのですが、そのままにするのは失礼かなぁと思って本人と話しをしてみました。すると自分が、「うっ」という展開になりました。

f:id:simplearchitect:20200629130215p:plain

牛尾:このコード、コメントアウト外してほしいということやねんけど、サンプルで応用的なサンプルも示しておきたかったんだけど、このケースだと、多くの人はそのサービスのアカウントがないから使えないと思うのでコメントアウトにして、実行時にエラーが出ないようにしているんだ。

同僚:なるほど、でも、自分の意見としては、自分が見て混乱したんだよ。これコメントやめて、ディレクトリわけたらええんちゃう?

牛尾:(今のタイミングでそれやると、死ねる、、、今日リリースやし、大したことないポイントやん、、、)Make sense やなぁ。ただ、ポイントとしては今日リリースしようとしていて(この時点で4時)これの変更を入れるとほかの言語のサンプルをすべて修正、そしてテストをしないといけないので振り出しに戻るような状態なんだ。ドキュメントにはしっかり記載しているよ

同僚:最後の最後で本当に申し訳ないんだけど、自分の意見では、混乱すると思うんだ。ただ、決めるのは君だし、自分の意見なんて全然無視していいよ。君次第さ。

牛尾:じゃあ、このプルリクエストは大きいのでいったんマージした後対応を考えるよ。レビューしてくれていつもありがとう

同僚:こちらこそ!

このケースだと、私的には相当つらい意見です。今までやってきたものが崩れ落ちるようなイメージです。ただ、彼のことを思い出すと、彼は普段からドキュメントを見ません。いろんな国から技術者が来るのでスタイルが本当にいろいろです。確かに彼のような習慣を持った人、つまり、ドキュメントをあまり読まず、コードを見るスタイルの人がいたら、コメントアウトされていたら確かに意味が分からないかもしれません。私はその日結局夜中の3時までその対応をしましてしんどかったですが、「心にぐさっ」というのはありませんでした。決定は自分次第で自分できめたことになるのですから。それは、始終「自分の否定」「自分のアイデアの否定」がないこと、そして、私の意見を「否定」していません。相手の意見を「尊重」しているのが、言葉だけではなく、態度からもにじみ出ています。

このように、かなり意見が違ったり、利害関係が異なっていても、「相手を否定しない」「相手のアイデアを否定しない」そして「自分の考えとして意見を言う」ということだけで、心が痛まないのでは?という小さな発見をしました。

否定をやめることで議論が効率化する

日本にいるときに、議論の際には「勝負」みたいな感覚がありました。反対意見を言うときは、言うほうも非常に言いにくいものでした。ただ、アメリカに来てからは議論で「心がつらくなる」瞬間がないので、議論自体は楽しいもの、助かるものと感じることが多いですし、反対意見を言うのになんの躊躇もなくなりました。つまり生産性がとってもいいわけです。これは気持ちがいいし、日本でもこうなるといいなと思ったポイントの一つでした。日本の職場でもチームでこういう文化にしていこうと決めて取り組んでいれば全然できちゃう話じゃないでしょうか?

私の会社がそうなった背景

ただ、昔からいた人に聞いてみると、私の会社も昔からこうだったわけでは無いようです。10年ぐらい前は嫌な人(toxic な人というらしいです)もいたみたいです。大きかったのは前のCEOがまだ現役の頃、社内で組織同士が対立していたとところ、組織同士が協力すると、よりCoolな仕事ができるとわかってきて、前のCEO主導で、みんなで協力していこう!という流れになって、その後評価制度も変わったようです。前は、チームがあると、チーム内で順序付けをして給料を配分みたいな感じだったので、ギスギスしていたらしいです。

f:id:simplearchitect:20200629123030p:plain

www.extremetech.com

今の評価制度に代わって人と「競争」がなくなったのが効いているようです。私が今の会社に入ってから同じ評価制度ですが、人と競争するというより、自分でゴールを設定して、それの達成で評価されまますし、人を助けたということでも評価されます。ですから、人との競争では全くなく「コラボレーション」を目指しているのが、現在の快適な職場環境をつくっているのかもしれません。

最終回、おわりに向けて

今回はこのブログの最終回です。正直前回のブログがバズって、普段スルーするところですが、バズりすぎて見てしまって、結構メンタルがやられました。正直自分の時間をかけて、自分が外資系に勤めて、アメリカに移住して体験したことや、気づいたことをシェアしているだけなのに、「批判」をうけてメンタルやられるのはあほらしい。と思いました。たくさんの「応援」もいただいているので、大変申し訳ないのですが、「ネガティブな空気から距離を置いて、やるべきことにフォーカスしよう」。と思ったのが切っ掛けです。

また、私も日本を離れて1年以上経っているので、日本の事情に関しても、最早よくわかっていないのかもしれません。今まで楽しみにしていただいていた方や、応援していただいた方、本当にありがとうございました。私はこのブログの記事が何か少しでも皆さんや日本が生産的になるためにちょっとでも貢献できたらうれしいなと思っていました。調査や二次情報ではなく、自分が実際に体験した事からくる気づきをシェアしていました。そして、毎回何か一つでも具体的に「実践できそうな」最初の一歩のアイデアをシェアしてきたつもりです。 f:id:simplearchitect:20200629130606p:plain

将来復活させるかもしれませんが、当面は、現在やっていることに集中して、自分の今の夢である「世界で通用する本物のプロのエンジニアになる」ということの達成を目指すつもりです。そうなれたら、また日本に少しでも貢献出来たらいいなと思っています。それまで、皆さんも人生をエンジョイされてくださいね!

このブログが何か一つでも皆さんのお役に立ちますように!

批判の文化が日本を技術後進国にしているかもしれないという話

先日、接触確認アプリがリリースされました。これは正直日本のソフトウェアの進歩に画期的なことだったと思います。私も衝撃を受けました。 f:id:simplearchitect:20200622075114p:plain

www.mhlw.go.jp

その後起こったことに関して正直は私の感想はこの通りです。

このような展開は、私が今住んでいるアメリカでは発生しない事案だと思います。じゃあ、日米でどういう違いがあって、日本人の自分が小さな一歩を踏み出して、日本がよりよい国になるようにできるとしたらどんなことだろうということを考えてみましたので、あまりソフトウェアの専門用語を使わない形で書いてみようと思います。

接触確認アプリが生まれた経緯

実は私はこの接触確認アプリが生まれたすぐぐらいの時に協力といえないぐらい微々たるものなので、言っていませんでしたが、ちょっとだけコントリビュートしています。だから誕生した経緯などは理解しています。世間ではいろいろは噂がありますが、実際の経緯はこの記事に書いてあることが最も真実に近いと思います。

www.businessinsider.jp

コロナの現状を見て、「自分が何か貢献できることは無いか?」と考えて、アプリ開発者である廣瀬さんが始めたことです。彼の会社の仕事とは一切関係ありません。そして、それに共感した仲間が集まって、多くの人のコントリビュートで出来上がったものです。ネット上にはいろいろな批判がありますが、政府の対応も少なくとも私は素晴らしいと思います。このような誰も体験したことの無い状況で、すべて政府主導など不可能です。そういう状況化で、そういった人々が善意で作ったものが、政府の人の目にとまって採用されたという経緯です。政府にも中の人はいて、その人ががんばって、この未曽有の危機をなんとかしようと頑張ってこういうことに至っています。政府の人もきっと、「前例がない」とかいう人と戦って、やっとリリースできたのだと思います。

アプリをリリースした人に降りかかった地獄

このリリースの後、どうなったのかというと、廣瀬さんのポストをみて正直私は泣きました。日本で最もこの件に関して自分の時間を割いて、貢献したヒーローがみんなにボロカスに叩かれて心が折れてしまったんです。

f:id:simplearchitect:20200622072617p:plain

よくよく考えてください。コロナ発生など誰も予想できなかった事で、こういったプロジェクトが始まった後で GoogleApple から共通の仕様が発表されて、いろんな事情から早いタイミングでリリースしたのは驚異的なことです。わたしはソフトウェアの専門家ですが、アプリケーションに不具合が必ず存在するのは理論的に証明されています。だから、ソフトウェアに不具合はつきものなのです。だから、不具合があるのは当然のことです。どんなソフトウェアにも存在するので、上げ足をとろうとしたらいくらでも取れてしまいます。今回のソフトウェアも最初のリリースと上記の制約があるなかであのレベルのものを出せたのは驚異的です。私は最初のバージョンとしては素晴らしいと思います。

「批判」の文化がすべてをぶち壊しにする

この一件で最も世間に貢献した人は誰でしょうか?アプリを作って実現することに貢献した人です。そして、お金をもらってようが、もらっていまいが、その人たちは自分の時間を使って人のために動いてくれたわけです。その人たちをSNSなどで批判する人が現れました。批判どころか、人格否定ぐらいのことを言っている著名人の人もいます。 f:id:simplearchitect:20200622073804p:plain

自分が時間を使って、自分が額に汗してみんなに貢献したら、こんなことを大量に言われたらどんな気分になるでしょう。自分だったら二度とやらないと思うでしょう。

責任の所在と、完璧を求める文化

日本では、このように「責任の所在」や「完璧」を求める文化があります。いいところでもありますが、すくなくともソフトウェアの開発に関してはあまり良いようには働きません。少なくとも私の観察している限りでは、私の住んでいるアメリカではこういう展開は無いと思います。残念ながら日本のソフトウェア業界は遅れてるといってしまっていい状況になっていますが、私の観察範囲ではエンジニアの人の資質の問題ではありません。私が見た最も優れたエンジニアは、私が日本にいるときにあった人々です。じゃあ何が問題なのでしょう? f:id:simplearchitect:20200622075251p:plain

開発者の心を砕いてしまう問題

今回の件で気づいた、大きいことが「開発者の心を砕いてしまう」問題です。日本は完璧主義があって、何か失敗すると、批判されて、責任の所在を追求されて、罰を受けます。それがたとえ、日本の国のためにがんばってくれたヒーローであっても、いいところが9あって、問題が1であっても、1を批判されます。大抵の人は、何か自分がやった事に関して、お金も欲しいかもしれないけど、それよりも「人から感謝される」こととか、「人の役に立ってると実感」することが欲しいんじゃないでしょうか?一方、ソフトウェアの開発で世界一位のアメリカはどうでしょう? f:id:simplearchitect:20200622075726p:plain

アメリカの「コントリビュート」文化

アメリカには「コントリビュート」するという文化があるように感じます。「コントリビュート」は貢献という意味です。人に何かを期待するのではなく、「自分がどういう貢献ができるか?」ということをベースに考えます。だから、人がちょっとでも自分に何かしてくれたら「ありがとう」という気持ちが生まれます。私がエンジニアリングチームに入って、自分の作ったものをはじめてみんなにお披露目する会がありました。ところが、以前にテストした時は全く問題なかったのに当日はデモが全く動作せず、めちゃめちゃになりました。

 こういう時日本では上司から死ぬほど怒られる場面ですが、こちらでは上司に謝ったら「問題ないよ。だって我々は新しいことをやってるんだから、こういうことは起こるんだよ」といわれました。誰一人批判する人はなくて、こんなめちゃめちゃになって、みんなの時間を無駄につかったのに、「私たちのために時間をとってくれてありがとう」という人まで何人かいました。 f:id:simplearchitect:20200622080511p:plain

これは、明らかに自分の上司のメンツをつぶす場面です。実際につぶれていると思います。だって、新しく入ったメンバーが、自分の下でちゃんと役立っているというのを示したいはずです。実際そうしたかったのだと思います。だけど、失敗しても彼はそういわず、彼の上司も特に何もいわずで、今彼は私のパフォーマンスに喜んでありがとうとかよく言ってくれています。

コントリビュート文化とソフトウェア開発のマッチング

ソフトウェア開発の文化はアメリカから生まれているので、こういった文化の下地があるのかもしれません。ソフトウェアは最近できたばかりであるのと、毎週のようにバージョンアップされたり、変更されたりするものなので、計画や予見が非常に難しいものです。そして大変複雑なのものです。ですので一人の人がすべて把握できるような代物ではありません。専門家でも「一部」の知識しかもっていないものです。だから人が強力しあって開発を進めます。誰もが「完璧な人はいない」とか、「物理的に無理なものは無理」という前提で物事を考えます。 f:id:simplearchitect:20190327181937j:plain

そして、アプリがリリースして、それがよりよくなってほしかったら「自分がどう貢献できるか?」を考えて、それを実行します。具体的には、問題のある部分のソースコードを修正して、送ってあげたり、そこまでしなくても、「こういう場面でこういう問題が起こりました」というのを定型のフォームにしたがって報告してあげたりします。自分が動かないのであれば、「よりよくなってほしい」のがそうならなくてもしたかがないでしょう。あくまで「自分次第」です。日本にいた時を思い出すと、日本では、「人がこれぐらいやってくれて当然」という感覚があります。それはいいこともありますが、「自分次第」の感覚の方が、人間関係のストレスは圧倒的に少なく感じます。

f:id:simplearchitect:20200622081330p:plain

 一方、プロフェッショナリズムも正直米国の方が上です。日本では、現実的に出来るかどうか?よりも、できもしない完璧とか、メンツが重視されます。それを徹夜でこなすのは少なくともユーザにとってはプロフェッショナルではありません。不完全で、いろんなレベルの知識を持った人がいて、そういう人が集まっている状態で、無理なくよりよくどうやったら出来るか?を常に考えているので、「現実的」にソフトウェアのレベルが無理なく向上ていくのだと思います。そして、失敗から批判が生まれるのではなく、「フィードバック」が生まれます。「こうしたら上手くいかなかった」「ここに問題が発生した」こういうレポートがアプリケーションの特定のサイトに集められることで、開発者も優先順位をつけてその修正に取り組むことでアプリがよりよく改善されます。アプリは不具合があるのは当然という考えがシェアされているので、報告したほうも、された方も「ありがとう」という感覚を持っています。

コントリビュートと感謝のループ

私は世界規模のクラウドのシステムを作っていますが、リリースして、不具合があっても批判にさらされることはありません。上記のような文化があるからだと思います。うちのシステムでなくても、開発者の誰しもが日常的に使っていて業務が滞るシステムが落ちた時でさえ、開発者の人は「あー、今日は仕事にならねぇなぁ、どっか遊びに行くか」とかつぶやく感じです。誰も開発者を責めたりしません。給料をもらっている事なのに、ほぼほぼ「作ってくれてありがとう」とか「助かった!」とかそういうフィードバックばかりです。問題があったら、問題をGitHubというサイトにポストしてもらえて、批判や人格否定は一切なくて、そこで建設的にどう改善したらいいかというディスカッションが行われます。だから感謝しかされません。そうやって、作っている方もみんなに感謝されているから、もっと、よりよくしていこう!とやる気になりますので、結果としてユーザーさんの欲しいものがさらに作られていくという良いサイクルを感じます。 f:id:simplearchitect:20200622081632p:plain

完璧・批判・責任の所在のループ

一方日本では、ディスカッションを見ると、「誰に責任がある」とか「こうすべきだった」とか、「品質が悪い」とか文句のオンパレードです。それは困難な状況に立ち向かった人に対して、自分は椅子に座っているだけの人がやっていることです。良かれと思ってやってると思いますが、「責任の追及」や「批判」をして世の中の何が前進するのでしょうか?それが、いったい何の貢献になるのでしょう?それよりも、「今からどうやったらよくなるだろう?」「今自分が何をしたら貢献できるだろう?」と考えると人それぞれ、貢献できることが見えてくるのではないでしょうか? f:id:simplearchitect:20200622082019p:plain  「完璧主義」から生まれる「批判」「責任追及」によって、自分が時間をつかって貢献した技術者の人は心が折れて、恐らく「二度とこんなことはしない」と思うかもしれませんし、アメリカがそうじゃないとわかると、日本を捨ててアメリカに移住するかもしれません。そらそうです。同じことをして、もっと給料がもらえて、みんなに感謝される。このようにパッションも実力もある人から日本を去っていくのは当然のことじゃないでしょうか?

世界的クラウドの開発でちびりそうになったこと

世界規模のクラウドの開発に参加した時は正直ちびりそうでした。日本の感覚でいたので、失敗でもしようものなら、世界中から批判されて大変なことになる、、、絶対失敗できない、、、と。 f:id:simplearchitect:20200622082811p:plain しかし現実はそうではありませんでした。人間は失敗するもの、むしろ「やってくれてありがとう」と感謝される日々で、日本で1システムを作っていた時よりもよっぽど気が楽です。私が失敗したら、世界中のシステムが止まるかもしれないのにです。私と日本にいる開発者の方でレベルが違うとかありません。むしろ私より上の人は多いと思います。だから、この国では、ソフトウェア技術者になりたい人が多く生まれて、キャリアを続けていても楽しいからやっていけて、だからこそいろんなサービスが生まれる。そんなことがとても大きいのではないかと思いました。

いま私たちが出来ること

多くの人が努力した成果がリリースしていただいたので、我々にできる「小さな貢献」を考えてみませんか?例えば、問題を見つけたら下記のメールアドレスに問題を報告するということもそうです。忙しくて何もできない人もいるかもしれませんが、アプリを作ってくれた人に対する感謝を発信したりすると、批判を発信する人から受ける開発者や政府関係者の人の痛みを軽減して、より生産的になれるかもしれません。何よりもアプリをインストールすることも貢献だと思います。私は米国に住んでいて、彼らのために何が出来るだろうと考えました。私のブログは多くの人に読まれるケースが多いので、ブログを書くことにしました。人それぞれなので、強制とかはもちろんあほらしいと思います。そうではなくて、少なくとも、「実際に動いた人」に対して感謝の気持ちが最初に来る方が私は少なくとも気持ちがいいし、「動いてくれている」人にもきっといいし、日本の未来を考えても、そういう環境になるほうがきっとソフトウェアを作ってくれる人が増えて、世界を気持ちよくよりよくしてくれると思います。

 

世界規模のクラウド「中の人」の働き方

現在私は、世界規模のクラウドの中の人になって一か月が経過しました。グローバルで、クラウドプラットフォーム自体を作って運用する側はどんなスタイルで開発されているのか興味がある人もあるかもしれないと思ってブログを書くことにしました。これは自分のチームや周りのチームを観察しただけであって、私の所属会社全体がそういうスタイルではないかもしれませんが、何らかの参考になるかもと思い書いてみました。 f:id:simplearchitect:20200524174313j:plain

スモールチーム

世界規模のグローバルなシステムなので、ものすごい大人数で、ものすごく厳密に開発されているイメージがあるかもしれませんが、実際のところ小さなチームの集まりです。自分がアジャイルコーチだったころに学んだことですが、開発は25人ぐらいのチームがマックスで、Amazon でも two pizza team といわれているように、ソフトウェア開発は少人数でないとまわらないのでそうなっているようです。沢山チームがありますが、チーム自体は小さいので意思決定のスピードはかなり速い感じです。既存で沢山のお客さんが使っているので慎重なところは慎重ですが、上の指示というよりエンジニアがそうしています。 f:id:simplearchitect:20160809120355j:plain

個人事業主スタイル

自分たちを助けてくれるマネージャがいて、「今期はこんなことをやろう」とリードしてくれますが、具体的なことは各個人が決めます。お題に上がっているネタで自分がやりたければそれをピックアップします。誰かが指導してくれるということはありませんので、自分ですべて考えますが、自分がどうしたらいいかわからないときや、困ったときは、同僚やそのマネージャに相談すると、間違いなく助けてくれます。製品が出来てきたら、周囲の人に「デモ」をします。

f:id:simplearchitect:20160403014646j:plain

「デモ」があると多くの人が認知してくれますし、プロダクトオーナーが気に入ったら、担いでくれるかもしれません。私はちなみに、初めてのデモは、リモートで画面共有してやったら全く動かず大失敗したいのですが、「デモ」を通じて「自分でプロモートするものだ」ということを学びました。失敗しても、日本ほど心象は悪くなりませんが、「成功」しないと多分誰もつかってくれないので、「デモ」がうまくいくための投資を自分にしているところです。親切な仲間が助けてくれる個人事業主の集まりのようなスタイルです。他の人や、他のチームとコミュニケーションや同期や確認をとる必要があるときは、エンジニア自らが連絡してコミュニケーションをとります。それを本人が気づいていない時は、日々のデイリースタンドアップで、マネージャがさり気に教えてくれたりしてフォローしてくれます。

アーキテクチャのレクチャ

中の人向けに、クラウドの中身の各パーツのアーキテクチャのレッスンが頻繁に行われていて、外からは知りえなかった内部アーキテクチャを学べて超楽しいです。

オンコール

プロダクトのエンジニアはオンコールと呼ばれる、お客さんから上がってきた障害報告のみに対応する週間があります。ローテーションで回ってきます。ものすごく自動化されていて、本当に凄いなと思いますが、内部の話なので、残念ながら公開はできません。ただ、開発者自ら、実際に運用と、障害の対応をすることによって、現場ではどんな問題が起きているか?を感じることができます。自分が書いたコードがもしバグったりしたり、障害の調査が難しかったら、きっと大いにフィードバックを受けて、二度とそういうことをしなくなるでしょう。そうやってセンスが磨かれるので、大変いい経験だと思っています。

自分が担当していない部分のアーキテクチャを学べたり、知らないことの調査の過程で教えてもらえるので、かなり理解も深まって一石二鳥で楽しいです!ちなみに、ガチでヤバイ障害が発生したときは、サティアの声で電話がかかってくるという伝説を聞きましたが、体験していないのでわかりませんw

f:id:simplearchitect:20200524175626p:plain

日本で体験した開発の職場との違い

SIerで開発しているときは、たとえアジャイルであったとしても、もっと「チームで動く」とか、「トップダウン」の色合いが強くて、「各エンジニアが各自で判断する」とか「自分の機能は、自分がその機能の個人事業主になってなんでもやる」いう雰囲気はあまりなかったと思います。自分が一緒に仕事をした「永和システムマネジメント」のアジャイルチームはそんな感じでした。クラウドの中の人とかにかかわらず、アメリカとかだとそういう感じが多いのでしょうか。

そんなので回るの?

多分、そんなスタイルって優秀な人でないと無理なのでは?と思うかもしれませんし、私もそう思っていたかもしれませんが、前の職場、そして新しい職場で完全に考えがかわりました。こっちのほうが断然いいです。明らかにスキルも付きますし、自分の実力以上のことは仲間が助けてくれます。しかし、自分がリードします。それはたとえ自分が新人だったり、インターンであってそれは一緒です。 f:id:simplearchitect:20200524180826p:plain で、見ているとやれば出来るんですね。なぜかというと、自分にそこのセンスや、能力が仮になくても、周囲が助けてくれるからです。日本だと、新人だと、「できないもの」として扱う場合がほとんどですが、「できるもの」として扱うと、みんなちゃんとできるんですね。日本だと新人にはエクセルのスクショとか、簡単な仕事しかふられない場合が多いですが、「できるもの」+周囲の助けで、本人も成長し、周りも自立した人が出来るので嬉しいことだらけです。だから、みんな堂々自信をもった顔をしていますし、新人も、年取った人も全く同じ同僚という扱いです。自分の周囲が親切に助けてくれることは、本当に生産性が上がるポイントだと思います。

失敗に対する反応の違い

この職場では失敗にとても寛容です。私はデモで大失敗して、まったく動かず、パワポと口頭と事前に撮ったビデオ(ただし、説明したいことと違う)を使ってやりましたが、自分的には100点中5点ぐらいです。最初のデモをきっかけにわかりやすく説明するつもりだったので、最初のがこけたら何も説明できません。もちろん後でビデオをとったり、Getting Started を作ってシェアしたりしました。しかし、一番重要なはずの「Demo or Die」の世界で失敗するのは致命的です。自分の評価は下がっているとは思いますが、それでも「マネージャは気にしなくてもいいよ、自分たちは新しいことをやってるのだからこういうことは起こるんだよ」って言ってくれたりします。 f:id:simplearchitect:20170618230921j:plain 自分がパイプラインで自動化してデプロイしているイメージがあって、それが数日後のBuildという最大のイベントでも大きく取り上げられているやつなのに、イメージが壊れていると連絡が入って、びっくりして、速攻でロールバックしたこともあります。悪いことほど速攻で連絡する癖があるので、マネージャに報告しましたが。「よくあることだよ。この前なんて、、、」みたいな話をしてくれました。これぐらいのかなりの失敗でも、こちらではかなり寛容なようです。それよりも、自分が失敗して、「I'm awfully sorry about that」とか言ってると、そんな反省しているみたいな空気がみんな苦手らしく、「問題ないよ」「助かったよ」とかポジティブな態度でいてほしいみたいです。失敗しても、ポジティブでいるほうが彼らには心地が良いようです。

自分はチャレンジしていなかった

このチームに来てから、先ほどの書いたとおり、死ぬほど失敗しています。かつてやったどの職場より失敗していると思います。さっきのデプロイにしても、デプロイしないと失敗しないわけです。でも、大きなイベントが控えているのに、デプロイをして失敗して、絶対やらかさないぞと思うから、いろいろ自動化して工夫をしたり、次失敗しないように必死でパラメータを調査したりします。自分もこのチームに来た時は正直通用するか不安でした。 f:id:simplearchitect:20200524181304p:plain 日本にいるときは、なんだかんだいって、「成功」ばかりしてた気がしますが、これって自分の実力以上にチャレンジしていなかっただけやなと思い知りました。「失敗」って結局自分の能力を上回ることをするからするのであって、その領域のことをすることは恐怖感があるのですが、それをやることで、自分の実力も少しづつ向上していく気がします。ただ、誰が失敗しても、それに寛容であるというチームであることが重要であると感じました。私はまだまだ失敗を恐れている傾向にあるのでもっと勇気を持ってみます。

おわりに

クラウドの中の世界は、思ったよりずっと「人」任せの世界でした。アジャイルマニフェストでも「プロセスやツールよりも、個人とその相互作用」という価値がありますが、この意味はたぶんこういう世界のことを指すのかと思いました。この記事が何か少しでも参考になれば嬉しく思います。Amazon さんはきっと「ゆう」さんとかがシェアしてくれるかな?

リモートワークのデモで壮大に失敗した話とその改善方法 - スクリーンシェアするすべての人に送る失敗談と対策

新しい職場で初めてのデモの機会がありました。多くの人が参加して、自分がやってきた仕事をデモして、知ってもらし、皆さんからフィードバックを受るのが目的です。新しい職場だし、俺元エバンジェリストやし、何千回とデモしたかわからんぐらいの経験があるので、ここは一発かまさなきませんな。そして、結果は!

f:id:simplearchitect:20200513113334p:plain

壮絶なる失敗

私の初めてのプレゼンとデモは完全に失敗した。何せ最初の一番簡単な Hello World 的なものが動かない。もちろん過去に同じことを何回もリモートでやったけど、動かなかったことなどない。私はリモートワークのツールとして、Teams を使っている。 

本番は、Teams+スクリーンシェア+紹介するクライアントアプリみたいな感じで、クライアントアプリはまぁまぁ負荷高いけどそこまででもない。ちなみに、過去に何回か少人数で同じ構成でデモしているけど、完全に上手くいっている。今回はさらにみっちり準備までしているのに、、、こけた。CPU張り付いて帰ってこない。

f:id:simplearchitect:20200513114040p:plain

プレゼンテーションのページ送りですら動きが緩慢とかいうレベルで、シェアしたかったことの3分の1もシェアすることができなかった。最初の デモで、「こういうものですよー」というのを知ってもらって、そこから説明を展開する予定だった。それがデモできへんと何も説明できないんじゃー!そのあとで、オフラインでビデオを取り直して、フィードバックがあった Getting Started のドキュメントも書いてシェアしたが、さすがにあまり見てもらえない。そらそうだ。

上司が、「失敗なんて思わなくていい。私たちはいつも未知のことをやってるのだから、こういうことは起こるんだ。だから気にせんでいいよ」と言ってくれてええ人やなと思ったけど、わし元エバンジェリストやで、、、orz

f:id:simplearchitect:20200513113623p:plain

これぐらいみじめな失敗は、エバンジェリストの時のデブサミでの失敗以来か、、、あの時は会場のネットワークがガチで遅くて、クラウドベースのツールのデモなのに、ホームページを開こうとしても、ネットワークが通信できず、はっきりいってデモ不可能だった。あの時は有線一択だったんだろうな、、、と学びを得て、その後はその手の失敗は無いかった。ビデオも常に録画するようにしていたので、その後は一切無かった。今回は社内のデモなのでビデオを準備まではしていなかった。やっぱこんな時でもビデオ重要だよ、、、

f:id:simplearchitect:20200513115635p:plain
写真は失敗した時のものではなく上手くいったときのもの

さて、この超絶みじめな失敗をシェアしてもしかたがないので、その後学んで改善した内容をシェアしたい。皆さんが私みたいにリモートワークのデモで壮大にこけませんように。私は Teams の事例を紹介していますが、ビデオ通話をするアプリではどれでも似たようなことが起こりうるので、何らかの参考になればとシェアしてみました。

課題の整理

さて、この大失敗だが、私は Surface Book2 を使っている。相当にパワフルなマシンだ。プログラマやし、速いマシン好きなので、相当早いはず。それが、Teams で沢山の人が参加した会議で、自分がスクリーンシェアリングを使って、自分の PC の画面を共有して、ローカルのアプリを動かそうとすると、完全に動かない。

パフォーマンスモニタというツールがあって原因を分析してみた。CPUがパツパツになってる。具体的にどのソフトが影響しているかというと、今回は Teams の負荷がデカかった。メモリもごっつい使っている。マシンは強力のはずなので、明らかに「設定の問題」が大きいだろう。

パフォーマンスモニタを使ってない人がいたら、Windows マシンを使っている人なら、Ctrl + Alt + Del キーを同時に押してください。すると、Task Manager というのが選択できますのでクリック。すると、今どんなアプリがコンピューターのCPUやメモリを大量に使っているのかがわかるので、何が影響しているのかを分析することができます。ちなみに下記のスクリーンショットは当時のものではありません。

f:id:simplearchitect:20200513102719p:plain

この時の分析では、Teams というリモートワークで使うツールがCPUをたくさん使用していたので、そこをまず何とかしようと思います。

Teams の改善

インターネットでサーチすると、自分の問題にマッチするブログを見つけました。実際にこれを試すと、Teams が相当軽快になりました!どのようにサーチをするといいかというと、私の例だとこれで下記のブログが一発ヒット

Teams how to reduce the cpu consumption while doing screen sharing

日本語だと こんな感じでサーチするかもしれません。残念ながらいいのは見当たりませんでしたが、そんな雰囲気で検索するというのを覚えていてください。

Teams スクリーンシェア 遅い

www.itexperience.net

具体的には3つのことをしました。

  • GPU のハードウェアアクセラレータを Offにする
  • キャッシュをクリアする
  • Teams を一旦終わらせて再起動する

これだけです。最初の、GPUのハードウェアアクセラレータをOffにするというのは専門用語が入っていてややこしいと思いますが、これはコンピュータが画面の処理を高速に扱うためのハードウェアが搭載されているマシンがあるのですが、その機能を使う設定です。なんでかわからないですが、Offにするほうが良いとのことです。

GPU のハードウェアアクセラレータを Offにする

実際のやり方は次の通りです。右上にある自分の顔のところをクリックすると、Setting (日本語だと多分「設定」)というのが出てくるのでここをクリックします。

f:id:simplearchitect:20200513103750p:plain

そして、この設定をオフにします。(画面ではオンになっています。)

f:id:simplearchitect:20200513103931p:plain

これに関しては将来改善される可能性が高いですし、私も一旦設定してからオフにしましたけど、そこまで最悪ではないので、将来設定を見直してみるとよいかもしれません。

キャッシュをクリアする

次にキャッシュをクリアするです。私の場合これが効いてそうです。キャッシュというのは、皆さんが使うアプリケーションを起動すると、最初の1回目はゆっくりだけど、2回目の起動が早くなったりしませんか?

 アプリケーションは大抵最初にデータをダウンロードしたり読み込んだときに、同じデータが必要になった時のために、データをどこかに保存しています。次にそれが必要になった時に、新たにダウンロードする必要がなくなるので、動作が早くなります。

 私はもうTeamsを長年使っています。そういう人だと、そういうファイルがたまりすぎて、逆に動きが遅くなることがあります。そういう時には一旦保存されたファイルを削除すると動きが早くなります。

エクスプローラを起動して、私の場合のユーザ名が ushioだとすると、C:\Users\ushio\AppData\Roaming\Microsoft\Teams のディレクトリに移動します。 f:id:simplearchitect:20200513105228p:plain

皆さんの場合だと、ushioのところを皆さんがログインするときに使っている名前に置き換えてください。その後最初に紹介したブログにかかれているとおり下記の内容を実施します。

  1. temp フォルダのすべてのファイルを削除する
  2. Blob_storage フォルダのすべてのファイルを削除する
  3. Cache フォルダのすべてのファイルを削除する
  4. IndexedDB フォルダのすべての.db ファイルを削除する
  5. GPUCache フォルダのすべてのファイルを削除する
  6. databases フォルダのすべてのファイルを削除する
  7. Local Storage フォルダのすべてのファイルを削除する。
  8. Application Cache の下の Cache フォルダのすべてのファイルを削除する

ちなみに、Mac だとここらしいです。~/Library/Application Support/Microsoft/Teams

Teams をリスタートする

Teams を一旦終了させて、再起動します。Teamsのウィンドウの×印を押してもダメです。赤丸で囲った箇所をしたからクリックするとTeams のアイコンが見えるので、右クリックしましょう。 f:id:simplearchitect:20200513105439p:plain

多分日本語だと、終了というボタンがあるので、それをクリックするとちゃんと終わります。

f:id:simplearchitect:20200513105548p:plain

その後ここに、teams を打ち込めばアプリのアイコンがでてくるのでクリックすると再起動します。

f:id:simplearchitect:20200513105707p:plain

その結果

今までスクリーンシェアをしていた時には常に1位だった、Microsoft Teams が、3位以下に落ちています。これは凄い改善!当日こけていたデモも楽々動作します。

f:id:simplearchitect:20200513105759p:plain

すばらしい!

その他の改善ポイント

自分のビデオをオフにする

ミーティングを開始した時点では自分の顔を動画で映すのは絶対的にお勧めですが、デモやプレゼンがはじまって、動作がもっさりしているなと感じたらまずは自分のビデオをオフにします。ビデオの情報転送量は相当なものなので、結構有効な手段です。

4K ディスプレイをシェアしない

私のマシンが強力だったこともあって、気にしていませんでしたが、コロナでずっと家にいると、自分の環境でスクリーンシェアをすることが多くなります。私の環境は、ディスプレイが2枚、真ん中にラップトップのディスプレイという構成になっています。 f:id:simplearchitect:20200513120457p:plain 左側が4Kのディスプレイで、右側がそうでないやつです。今までは4Kのディスプレイをスクリーンシェアで使っていましたが、4Kではない方をシェアするようにしてコンピュータの負荷を減らすことにしました。

ブラウザを閉じる

ご紹介している Task Manager を起動して観察していると、一番多くのコンピュータ資源を馬鹿食いするのは「ブラウザ」つまり、インターネットエクスプローラ、グーグルクロームファイアーフォックスといったWebブラウザです。Macだと、Safari です。普段から使っているととついついたくさんのタブをオープンしていますが、もっさりする多くの原因はこいつです。スクリーンシェアの時は、ブラウザを出来るだけ閉じましょう。

f:id:simplearchitect:20200513120622p:plain
あかんやつ
必要最低限のページのみをオープンするようにしましょう。

WSL2 のキャッシュをクリアする

このポイントはエンジニアの人限定になりますが、私の環境では、Windows Subsystem for Linux のバージョン2で、Docker のビルドなどをしていますが、これが超絶にメモリを食っていてびっくりしました。エンジニアでない方はまずインストールしてないと思うのでご安心ください。ここにある Vmmem というプロセスが凄いことになっていますが、これがVMを扱っているところで、この中で WSL2 が動作しています。

f:id:simplearchitect:20200513110428p:plain

ここの回避策がものすごーーーく効きました。ちなみにこのスクリーンショットはたまたまたですが、前のものとは比べ物にならないぐらい小さいメモリですみました。

github.com

具体的には、キャッシュをクリアするクーロンを設定して、15分おきに消すとただそれだけなのですが、これがゴリゴリに効きます!この問題が修正されるまでは、この回避策でいい気がします。このパートを読んでいるのは、エンジニアの皆さんなので、詳しくは、上記のリンクをご覧ください!

そうすると、めちゃくちゃ巨大やったメモリが、おとなしい子供のように変わりました。 f:id:simplearchitect:20200513111123p:plain

事前に動画をとっておく

これが最強の方法です。エバンジェリスト時代は常にしていました。それだけに、なぜ今回しなかったんだよ、、、と大反省です。つまりデモを事前にビデオで録画しておけばいいです。とっても簡単な方法があります。わたしは普段 PowerPoint を使っています。Insert(日本語だと多分挿入でしょうか)をクリックすると、Screen Recording というボタンがあるので、新しいページを作って、そのボタンをクリックします。

f:id:simplearchitect:20200513111916p:plain

すると、こんな画面がでてくるので、Select Area のボタンをクリックして、動画を撮りたい画面の範囲を指定して、Record を押すと、レコーディングがスタートして動画が作られます。

f:id:simplearchitect:20200513112046p:plain

デモを取り終えたら、こんな感じでページに張り付きます。何かあったら、動画に切り替えてみんなに動画を見てもらえばよいのでとても楽です。今はインターネットの時代なので、今日動いているものが明日動くとは限りません。たまたま障害が発生しているかもしれません。動画だと絶対に失敗しませんので、心の支えにもなりますので、絶対的に準備しておくのはお勧めです。しかも、動画に撮ることで説明がしやすくなりますし、他の人に後からシェアすることもできます。

f:id:simplearchitect:20200513112333p:plain

パワーポイントのオンラインシェアを使って、画面共有をやめる

他の技として、音声通話のみにして、スライドショーをWebサーバー経由にする方法があります。そうすると、圧倒的にデータ転送量が減るので、プレゼンだけならかなり強力かも。

f:id:simplearchitect:20200513121448p:plain

まとめ

リモートワークを生産性良くするためには、強力なマシンを買うことを絶対的にお勧めしますが、強力なマシンを持っていても、私のようにPCがいっぱいいっぱいになってしまうことが起こりえます。

そうならないためには、ご紹介したような方法で、「うまく設定する」ことで、劇的にパフォーマンスを改善することが可能になるかもしれません。また、動画をとるとか、違うディスプレィを使うとか、他のアプリがたくさんコンピュータのリソースを使ってるとかいろいろあります。

コンピュータの動作が重い時に立ち止まって、「なぜ重いのか」を分析して、Webで改善方法をさがしてみませんか?今回は Teams ですが、Zoom や他のものでも、基本的にすごく重たい処理をしていますので、十分に発生しうることで、同じように十分改善の余地を見つけることができると思います。

是非皆様は、私のようにコテコテな失敗をせず、快適なリモートワークをお過ごしください!

ガチ三流エンジニアが米国マイクロソフトのドリームチームのメンバーになれた話とそのためにやった事

私は卑下しているわけではなく、ガチでプログラミングの才能が無い。他に才能があるといわれる分野は持っているが、プログラマとしてはガチで三流だ。 そんな私が、今でも夢のようなのだけど、長年あこがれた米国マイクロソフトのドリームチームのポジションを得ることができた。今回はどうやってそのポジションをゲットすることができたかについてシェアしてみたい。 f:id:simplearchitect:20200422173100j:plain

ガチの三流プログラマ

私はガチでプログラミングの才能が無い。プログラミングを始めたのは確か、10歳ぐらいだろうか?だからキャリアはスーパー長い。三流というのは謙遜ではなくて、自分と過去に仕事したことがある人なら知っていることだと思う。私には人より出来ることもある。それはコンサルティングだったり、アジャイルや、DevOps のコーチ、そしてエヴァンジェリストだ。日本のマイクロソフトではプレゼンは必ず上位だった。私は過去を振り返ると、何回もプログラマになろうとして、失敗したり挫折したりしている。つまり、人にやってもらうことは得意だけど、自分でやることに関しては暗黒だ。 f:id:simplearchitect:20200422173318j:plain 最初の大手SIに勤務したときも、あまりのプログラミングのできなさ加減に、先輩に見捨てられて、しばらく営業になっていたし、プロジェクトを自分で営業してとってきてやったりしたけど、プログラマとしてアサインされることはほぼほぼなく、スタートアップでも、「牛尾さんは、プロマネ力凄いねんから、プロマネやりはなれ。プログラマとしては才能無いですわ」とガチに好意でいってもらえたこともある。他にも自分が才能無いことを見せつけられるケースはそれこそ山のようにあれど、プログラミングで私が能力を示すことはなかった。

f:id:simplearchitect:20200422173546j:plain

マイクロソフトに入ったのも、自分の技術力のなさからくる「偽物感」がものすごく嫌だった。友人のアジャイルコーチとかも、そもそも基本的な技術者としての実力がある人ばかりなのに、自分は偽物やなぁ、、、ってずっと思ってた。だから、マイクロソフトエバンジェリストで入ると、プレゼンとかは得意なので、コントリビュートしつつクラウドコンピューティングが学べると思ったのだ。

Serverless の Azure Functions チーム

日本にいる時代から、自分にはあこがれのチームがあった。Azure Functions チームだ。明らかに才能ありまくりの人がそろっていて、イノベーティブなサーバーレスのプロダクトをガンガンに作って運用している。Serverless が大好きだったので、めっちゃくちゃ時間をかけてリポジトリにコントリビュートしたり、公式ドキュメントやPRでコントリビュートをしたりしていた。Durable Functions を発明した Chris を含めて、めっちゃくちゃ優秀な人がいて、Serverless のプラットフォームを作ってるチームにいつか Join したい!と思っていたけど、自分も心のなかで、何年かかることやら、、、と思っていた。

f:id:simplearchitect:20200422173756j:plain

自分は自分の実力を知っているし、自分でも、友達の Chris に、「わしが君やったら絶対自分を雇えへんわ」とよく言っていた。そういうことを複数のプロダクトチームの友人に言うと、「Tsuyoshi は才能あるねんから、CAがいいよ」と複数の人から言われていた。CA は、日本だとちょまどさんや、寺田さんがやっているアドボケートのポジションで一握りの人しかなることができません。たしかにそこは自分でも才能あると思うし、実際に友人のアドバイス通り声をかけてみたけど、英語の環境では、日本語のトークがうまいという利点はないも同然なので、アジアの担当の人を紹介するわ。と言われたりしていました。いや、わしシアトルに住んでるんすけど、、、

f:id:simplearchitect:20200422174301p:plain

自分ってホンマ米国に来ると価値無いなぁ、、、ってガッカリしたりもした。 しかし、自分の唯一のいいところはあきらめが悪いところなので継続してプロダクトチーム(クラウドサービス自体を作っているチーム)に参加できる実力になることを心に決めてそれに向かって行動しました。しかも私のロールは、DevOps なので、コーディングよりコンフィグレーションや、Pipeline の構築が主な仕事で、コーディング仕事はそんなありませんし、あったとしてもそんなに難しくありません。だから、私の同僚も、DevOps チームからプログラマ系の職を得るのは非常に難しそうでした。「君はプログラマやなくて DevOpsやろ?」ってよく言われていたらしいです。むずいのはわかったけど、やるだけやと思って計画を始めることにしました。

プロダクトチームの人に話を聞く

最初にやったことは、既にプロダクトチームの一員になった友達や、プログラマや研究職の日本人の人に話を聞いてみました。私はリロケーションでアメリカに来たので、こちらでのジョブインタビューは受けたことがありません。マイクロソフトの中での転職作業でも、外部からの転職と変わりありませんので、がっつりジョブインタビューがあります。具体的にはコーディングインタビューだったり、アーキテクチャディスカッションだったりします。私が個人的にとても役にたったものが3つあります。最初は LeetCode です。コーディング面接用のサービスらしいですが、アルゴリズムやデータ構造の勉強になるので、とてもいい感じです。私は教えてもらったこのブログの60問を2週して、考え方をしっかり吸収しようとしました。実はコーディング面接には全然でなかったのですが、プログラマとしての実力を上げるのに役立ちました。

1kohei1.com

アメリカでの就職事情を学ぶ

この本、アメリカに来る前に買っていたのですが、なんと、この著者の竜さんが当時マイクロソフトで働いていて、友達になれたので本も熟読したし、本人にもお話をお伺いすることができました。竜さんは、マイクロソフトだけではなく、Amazon, Google (現在) にもお勤めで、面接を受けるだけではなく、面接をする側も何回も体験されている方なので、内容がガチでリアルです。勉強になりまくることばかりだったのですが、特に印象に残っているのは「コーディング面接は、結果というよりも、過程や、考え方、面接官とのコミュニケーションを見ている」という部分です。

f:id:simplearchitect:20200422174448j:plain

問題がさっととけるのに越したことはないですが、例えば問題をたまたま知ってたら解けるわけで、問題を解けるかどうかはある意味重要ではありません。その人が同僚になって働いたときに、面接官がこの人と働きたいなと思ってもらうことが重要なので、自分が解答がわからなくても、ガッカリせずに面接官に質問したりコミュニケーションをとりながら自分の考え方を口にだしながらコーディング問題を考えていくのがよいようです。事実、私は2つのプロダクトチームのコーディング面接を受けました。両方通りましたが、1つは正直ガチで落ちたと思っていました。それぐらい問題はあまりできませんでした。でも蓋を開けたら合格していました。たぶんこの本や竜さんのアドバイスが無ければ、そんな状態になったら、焦るばかりで何もできなくなっていたかもしれません。それぐらいこの本は本当に有用でした。この話に関しては竜さん以外からも複数の人が言っていました。

Applyすること

3つ目は希望のポジションがあったらApplyすることです。当たり前に聞こえるかもしれませんが、Applyしなければ絶対受かりません。しかし、今になって思いますが、これが最も重要です。私の Azure Functions チームは、AppService チームというグループに所属するのですが、そこに所属する唯一の日本人が先輩の河野さんです。本当に素晴らしい人で技術者としても半端ないので、よくたくさんの人から質問を受けています。みなさんこう聞きます。「河野さん、どうやったらマイクロソフトの本社でクラウドを作るプロダクトチームに入れるのですか?」、河野さんはこう返すそうです。「受けたから。受けましょうよ!」 f:id:simplearchitect:20170126001407j:plain しかし、誰一人として Apply した日本人はいなかったそうです。たぶん多くの人は「あんなハイレベルなところは受かりっこない」「実力をつけてから受けよう」と思ったのかもしれません。しかし、自分が満足できる実力になる瞬間は永遠に来ません。今受かった私が思うのは、「受けないと受からない」というシンプルな事実です。明らかにプログラマとして実力が大したことない私でも受かるのですから。

じゃあなぜ受かったんだろう?

事実、Azure Functions チームのプログラマは半端ない人が多いです。でも、雇う側から見たら、「凄腕プログラマしか雇わない」と思っているとは限りません。その時々の事情によって欲しい人は変わります。そりゃできたほうがいいに決まっていますが、「ここのコードベースのことを知っていて、チームビルディングがうまい人が欲しい」とたまたま思っていたタイミングがあったらどうでしょう?雇う側の人もスーパー賢いひとなので、私のプログラミング力が大したこと無いことは当然見抜いていると思います。その上で私をやとったのは、たまたま、チームの事情と、私がマッチングしてたからで、「プログラマとして凄腕だったから」ではないのです。

f:id:simplearchitect:20200422175550p:plain

私は元アジャイルコーチですし、Kubernetes や Go の経験がありますし、Azure Functions のリポジトリにコントリビュートしていたので、コードベースを知っていたわけです。凄腕だからじゃないのです。こんなことは、当然受けるまでわかりませんでした。でも、ポジションの応募がかかったから受けたら、本当にたまたま受かったのだと思います。タイミングが良くて。事実私より1000倍ぐらい凄腕のプログラマがこのポジションを落ちているのです。でもそんなチームの事情など外部から知ることが出来るはずがありません。だから、本当に受かった理由は、「受けたから」です。河野さんが、みんなにアドバイスをした「受けましょうよ」で、実際に受けたのが私だけで、私が受かったのです。皆さんもいろいろ考える前に「受けて」みませんか?もし、落ちたとしてもそこからフィードバックが得られて面接がうまくなるし、将来再チャレンジするときも、参考になるはずなので、マイナスなど一切ありません。

コーディング面接、アーキテクチャ面接はどんなものだったか?

どんな問題が出ていたか?はお話しできませんが、残念ながら LeetCode の問題は一切出ませんでした。私は2つのチームを受けて両方受かりましたが、2つの設問に対して共通する傾向を発見しました。それは、「そのチームが欲しい技術分野が試される」ということです。基本的にプログラミングがちゃんと出来る人、だからまずはアルゴリズムとデータ構造に強い人が欲しいと思う人が居たら、LeetCode の問題が出ると思います。他に何かのプロダクトを作っているチームだとすると、そのチームのつくってるものに必須となる素養が試されるという感じでした。 f:id:simplearchitect:20190515160549j:plain

例えば、プロダクトのアプリケーションのアーキテクチャが重要なプロダクトでは、オブジェクト指向の問題が出るかもしれませんし、高度な並列処理を行うのであれば、コンカレントプログラミングについて問われるかもしれません。また、大量のデータを受け付けて処理するようなアプリケーションでは、データストアを効率よく操作するための設問がでるかもしれません。つまり、そのチームが欲しい人がもっていてほしい技術が問わるかもしれません。コーディング面接はチームによって全く異なると思っていた方が良さげかもしれません。

f:id:simplearchitect:20190327181857j:plain 先にプロダクトチームにいったブラジルの友達が言っていました。「自分はめっちゃたくさん面接受けたけど、どれも全然違った。あるチームでは、お前はジュニアの力しかないといわれたけど、別のチームでは、実力があるから、アップグレードしてシニアとして採用しようと言われた。評価も含めて全然ちがうのが普通。自分は同じなのにね」ここでも、やっぱり受けないと始まらないことがわかります。受けて落ちても得ることがあるので、受けて損することはありません。

やったことで、役立ったことのまとめ

既に書いたもの含めて今回のポジションをゲットするために役立ったものをリストアップしておきます。就職のために意識してやったわけではありませんが、後になって思って効果的だったことも書いています。

情報を得る

  • プロダクトチームの人に話を聞く
  • 書籍
  • ブログ

実力をつける

  • LeetCode
  • プログラミング師匠を持つ(わたしの場合かずきさん)
  • 技術を学んだら、ブログに書く

Visibility を上げる

  • リポジトリにコントリビュートする
  • オフィシャルドキュメントに寄稿してコントリビュートする
  • 英語でブログを書く
  • Azure Functions のプロジェクトを実施して、チームとコミュニケーションをとる
  • チームの人と Serverless のイベントをつなぐ
  • Linked In をアップデート

スペシャリテ

情報を得るに関しては先にはなしてありますので、話してないことを。受かった後でOfferLetterを受け取る前のタイミングでは、わたしはこのブログを書いているゆうさんにお世話になりました。この記事も大変有用でした。

三流プログラマなので、素直に実力をつける努力を継続して行っていました。LeetCode は役に立ちました。アルゴリズムやデータ構造などは、三流プログラマでも、学んで実践したらコーディング力が上がる実感があったので、よかったです。また、私にはラッキーなことにコーディング師匠のかずきさんがいます。よく助けてくださって、ここまでこれたのも彼のおかげですが、彼のアドバイスとして、学んだらブログを書くことといわれていて、実際に彼もやっています。彼は自分が見た中で1,2を争うぐらいコードが書ける人で。彼のようになるためには、そういうシンプルで小さな積み重ねが重要みたいです。私も継続しています。

blog.okazuki.jp

Visibility は、チームの人から見た、私の存在感です。雇う側としても「この人実力あるのかな、、、無いのかな、、、」と面接で判別する必要があります。ところが、実際にコントリビュートとかしている人がいたら、少なくともこの人は知っているし、実際にコントリビュートもしているのだから、役に立つ確率は相当高いと雇う側からすると思えると思います。GitHubのプロジェクトにコントリビュートするといいことづくめです。レビューされるので実力が付きますし、コードベースを学ぶこともできます。

f:id:simplearchitect:20200422183016p:plain

普段の学び用のブログはこことは別で Qiita に書いていて、内容は既にどこかにあったりしても、自分が知らなかったら書くようにしています。つまり自分用です。中身をみると、なんと内容の無い、どこでもあるような内容だと思うかもしれませんが、それでよいみたいです。師匠曰く、複雑なプログラミングの中で知らないことが出てきたら、必ず小さなサンプルを作って動かして、ブログに書くこと。

qiita.com

でも、たまにこの情報はシェアしたほうがいいんじゃないか?と思ったときは、英語でブログを書くようにしています。大したアクセス数はありませんが、そんなものでも、「Tsuyoshi ブログ見てるよ。この前やくだったわ」とか知らん人から言われることもよくあります。先日もお客さんからフォローしたと言われてびっくりしました。

medium.com

あとは、面接の直前ですが、Linked In の情報をターゲットのチーム向けに書き換えました。彼らが関心ありそうなことがわかるようにしています。アメリカの面接の場合、Linked In は完全に楽です。こいつをアップデートしておけば、履歴書が必要ありません。もう絶対これしかない。

https://www.linkedin.com/in/tsuyoshi-ushio-34458a19/

最後のスペシャリティは、自分がもともとやっていただけで、今回のチームには関係ないと思っていたけど、プラスに働いたことです。つまり何が言いたいか?というと、自分では関係ないと思っている事でも、チームにとっては欲しい要素があるかもしれないということです。私は DevOps とかは、マイナスでしかないと思っていました。プログラミングをする機会もプログラマよりずっと少ないからです。つまり事前にはわからないので、今自分がやっていることは手を抜かずしっかりやっておくのがいいと思います。

おわりに

大変ラッキーなことに、アメリカに来て目標にしていたドリームジョブをゲットできたので、自分がやったこと、体験したことをシェアしようと思いました。 とりとめもありませんが、この記事が誰かの役に少しでも立てたらうれしく思います。

これからは、Serverless の世界をよりよくするのに貢献していきたいと思います!

アメリカのエンジニアと仕事をするときに日本人エンジニアがやったら良さそうなこと

前回のブログの最後で少し触れましたが、今回はアメリカのエンジニアと仕事をしていて感じたコミュニケーションの大きな違いについて書いてみたいと思います。 私はアメリカのシアトルでソフトウェアエンジニアをやっていますが、日本人の人と仕事をするときに求められるコミュニケーションのスタイルと、アメリカのスタイルがものすごく違う点があって、 今も苦労しています。

f:id:simplearchitect:20200417140045p:plain

そんな中でも自分が気づいて改善中のポイントについてシェアしたいと思います。今回の対象は「アメリカ在住のエンジニア」ではなくて、「アメリカ人の」エンジニアの感覚の違いです。同じ英語圏でも文化が違うので、今回は英語の話ではなく、文化的な違いと思ってください。

日本ではコミュニケーションが得意だったのにまるで通用しない

私は日本にいるときは元コンサルタントですし、プレゼンをするとマイクロソフトでも常に上位でしたし、お客さんをエンゲージするのも非常に得意でした。つまり、日本人として、日本人の中で仕事をする分には多分コミュニケーションスキルは高かったと思います。ところが、アメリカに移住すると、これが死ぬほど通用しません。最初は英語力の問題と思ったのですがそうでありませんでした。わかりやすい。という感覚の違いが大きいように感じます。

日本では「情報量が多い」のが好まれる

日本人のコミュニケーションをするときには、一般的に「情報量が少ない」のは好まれません。例えば多くの人に技術プレゼンをするときに意識していたことの一つに、来てくれたお客さんにみんな満足してもらうためにどうするか?というのをいつも考えていました。だから、初心者の人が来ても、上級者の人が来ても「来てよかったなー」と思えるような構成にしていました。また、「お得感」みたいなものを持っていただくために、プレゼンの最後に、前日徹夜してきてくれた人のためのドキュメントやブログ、サンプルアプリケーションなんかを用意しておいて、その場で公開したりとかもよくしていました。

f:id:simplearchitect:20200417140631p:plain

プレゼンで評価が高いものをみても、日本のものはスライドの枚数がすくないものってあまりないのではないでしょうか?

アメリカでは「情報量の少ない」のが好まれる

一方、アメリカ人のエンジニアの人には「情報が少ない」のが好まれます。たくさん情報があっても消化できへんやん。という感覚みたいです。それは、プレゼンとかではなくて普段のコミュニケーションでも頻繁に出会います。私はエンジニアなので、技術的な質問とかをする時にどうするか?というと、日本にいるときは、もちろん情報はわかりやすく整理するのですが、相手が知っていてほしいと思う情報は全部盛り込みます。そして、そちらの方が好まれます。おそらく「失敗せず成功させたい」という思いがやるほうも強いので、失敗しないように(そして、めっちゃよろこんでもらえるように)一生懸命がんばっていました。

会話の例

例えばCIのパイプラインがよくわからないエラーで落ちて原因がわからないとします。日本だったら、こんなエラーメッセージがでて、バージョンがどれで、自分が試したのはこれと、これで、結果がこうで、これをやったら落とし穴で、ストールするしてハマるので、しないようにしてね。ちなみに、パイプラインのコードはこのプルリクエストみたいなことを整理して送ってあげるのが喜ばれました。

しかし、アメリカの人はどうやら様子が違うようです。実際に私がメッセを送っても無視されるような感覚を持っていました。そこで、友人のクリスに相談してみたところこんなことを言われました。

クリス:「みんな忙しいだけやで。ただ、そこにたくさん書いてると読むの大変じゃない?だから単純なのでいいの」

牛尾 :「えっ、まじ、、、ちなみに、これやったらはまるでみたいな情報っていらないの?だって、はまったら大変やん」

クリス:「要らんで。さっきの例やと、このエラーメッセージがでて困ってるんやけどなんか知ってる?ぐらいでいいよ。付加的な情報は後でええねん」

f:id:simplearchitect:20200417140924p:plain

つまり、日本人の自分的には、あったほうがいいと思って、相手にも日本では喜ばれた情報が、こちらの人にはいらん情報みたいです。つまりこんな感じで会話が進む想定です

自分「CIシステムでこんなエラーメッセージがでて困ってるねんけど、なんかしってる?」

相手「ああ、これ前あったことあるわ。このコンフィグは今どうしてる?」

このやり取りでおわったらこれで終了です。

もし終わらなかったら。

相手「そうやなぁ、調査が必要やな。このパラメータどうなってる?」

自分「こうしてるよ。もしよかったら、プルリクエストのURL送るけど」

相手「いいね、見てみるわ」

自分「あ、ちなみに、やるとき、これやったら、バグ踏むから、気を付けてね」

相手「ありがとう!」

といっ感じです。つまり、アメリカの人とコミュニケーションをとるときは、最初から全部説明ぜず、「情報量を減らす」というのがものすごく重要と気づきました。

f:id:simplearchitect:20200417143804p:plain 情報を与え過ぎないのにものすごく気を使います。 何かの技術を説明するときも、日本だったら事前準備したパワーポイントのスライドで技術を説明するケースでも、こっちだと、同じくパワーポイントで説明する場合でも、スライドの枚数を極限に絞って、「これだけ わかって欲しい。」と思う1点だけを説明して、質問が来たら他のを説明したり、というスタイルに変えています。これは良しあしではなく、文化なのですが、どちらが本質的で楽かを考えるとこのアメリカンスタイル は確かに楽だと思います。

その場で吸収できるものを最大化する

背景にある考え方として、日本の場合は得して帰りたい感覚があるので、情報はたくさんもらえるのがうれしいですが、アメリカの場合は、「その場で吸収できることを最大化したい」という感覚があるみたいなので、複雑なものを提供されてもその場で理解できないので、単純でシンプルで、その場で理解できる情報量のものが好まれるようです。

日本人はどうしたらいいだろう?

アメリカ万歳」みたいに聞こえますが、日本人としての仕事の仕方を続けてきた人としては、アメリカの人と働いて有利になる習慣はないでしょうか?おそらくそれは「準備」だと思います。アメリカの人はほぼほぼ「準備」しません。その代り何が来ても対応できるように、普段から反射神経を鍛えている節があります。その姿勢は見習いたいですが、第二外国語の英語である以上戦闘力の低下は否めません。ただ、いくら頭がよくても限界があります。 f:id:simplearchitect:20200417144016p:plain

人生であった最も頭のいい人も理解できるとは限らない

私があるチームに対して技術的な説明をしたのですが、そのメンバーの人は自分が人生で会ったことのある人の中で最も頭のいい人でした。しかも、圧倒的に。人間ってこんな頭よくなるんやぐらいの感覚です。ですので、最初に説明をしたときは、技術的に難易度の高いところから、すべてのパターンやプラクティス、リポジトリアーキテクチャを知っている前提で話ましたが、反応があまりよくありませんでした。自分は正直三流エンジニアで、自分ですら理解できることを説明しているに、ふと、そのときに思ったのですが、「まさか、みんなよくわかってない、、、?」、そこで学んだことは、自分の人生で断トツ圧倒的に一番頭がいいぐらいの人でもなんでも即座に理解できるわけではないということです。自分で書いたある程度複雑なものは、自分は自分でやったからわかってるのであって、他の人がそんなさっさと理解できるものではないのでは?と仮説を立てました。

情報量を最小にする

2回目に説明するときは、手を変えて、「簡単なこと」をしっかり説明するこようにしました。こんなクラスのこと知ってるよな、、、と思っても説明しました。頭が強烈に良くても、知らんものはすぐ理解できないようです。ところが、ここからが猛烈に頭のいい人は違いました。ちゃんと情報量を抑えて、ちゃんと筋道立てて基礎的なことから、説明すると、一瞬で理解して、そして、ものすごく鋭い質問がたくさん来るようになりました。「この人らはやっぱパネェ!」と思いました。たぶんこれはアメリカ人の人のように「アドリブ」で自分がやっていたら英語力的にも無理だったと思います。日本で鍛えた「準備」「改善」が効いた瞬間です。

準備・改善・情報最小化

さらに、改善して、今度は、アーキテクチャを説明するのに、コードや、ダイヤグラムだけでは難しいのがあったので、パワーポイントで動画を作って3分ぐらいにまとめたのをシェアするようにしました。作るのは、パワーポイントでレコーディングして、Youtubeに上げたらできるので、30分ぐらいです。オフィシャルのじゃないので、編集もなしですが、他のメンバも見るべきだよとか、嬉しいコメントがもらえました。 f:id:simplearchitect:20200417144340p:plain

遅延ソリューション

他の日本的な欠点でいくと、「その場での思考の瞬発力」があるように思います。私たちは、持ち帰って考える癖があるので、瞬発で考えるのがあまり得意ではないかもしれません。昔悩んでいた時に、ドリューというボスが言っていたのが、それでいいんだよ。あとでもし、いいアイデアを思い付いたら、その時シェアをしてくれたらいいよ。と言いました。確かに会議がおわったあとに、「こうすればいいんじゃね?」と思いつくこともよくあったのですが、あとでメールしたりすると「いいアイデアだ」と喜ばれることもよくありました。

おわりに

正直言って、頭の回転で彼らに勝てるとは到底思えませんが、どんくさい改善とか、準備とか、工夫とかしていると、くっそ頭のいい人のなかでも役にたてる気がしています。私たちは彼らが持っているものを持っていませんが、別のものをもっているので、うまく活用したほうがよさそうですね。

私はこのトピックに関してはまだまだ研究中です。もし、よいアドバイスなどありましたら、コメントがいただけると嬉しいです。

マイクロソフトのリモートワークが得意な人を観察して気づいた、たった一つのポイント

コロナウィルスによって、誰もがリモートワークを実施する必要があるようになりました。昔はインターナショナルチームのメンバーとして日本に住んでいましたが、今は同じチームのいるシアトルに移住してアメリカでエンジニアをやっています。正直なところ私はリモートワークより対面でコミュニケーションをとるほうが好みななのです。しかし、アメリカのマイクロソフトにいると、コロナが始まる前からそもそも通勤できる距離にないメンバーが居たり、同じチームのメンバーが別の国に住んでいたり、お客さんが別の国だったりということもしょっちゅう起こります。そんな環境のなかで、リモートワークが得意な人が共通して持っている、たった一つのポイントをご紹介したいと思いブログを書きました。

f:id:simplearchitect:20200415095413p:plain

リモートワークのつらさ

リモートワーク好きな人もいますが、私はできれば同じ場所で作業したいと思います。リモートワークをすると、視野が画面に限定されますし、チャットで誰かに相談しても、反応が返ってくるとも限りません。めっちゃ頑張って英語で説明をがっつり書いたとしても、スルーされることすらもしょっちゅうです。みんなで会議をしていても、高速な英語での応酬三昧で、誰かがしゃべり終えるのを待つ癖のある私はめっちゃ不利です。対面ならホワイトボードを使ったりして、いろいろやりやすいですが、画面の中に固定されるコミュニケーションで、ほぼほぼ音声だけを頼りに多くの人のいる会議で成果だすとか「つらすぎるんじゃーボケー」という感じです。シアトルに来てから友達になった私よりもずっとTOEICの点数が上のゆうさんがこんなことを言ってました。マジで骨身に染みるぐらい同感です。さて、こんなつらい状況のなかで、どうやって成果を出したらいいでしょう?

Can I have a quick call?

アメリカで働いている人でもリモートワークが得意な人とそうでない人がいますが、リモートワークが得意な人はほぼほぼ Quick Call をよくすることに気づきました。Quick Call というのは、1対1のビデオ(ビデオオフの場合もありますが)通話のことです。自分は、リモートのときは、定例とか、正式に招待された会議だけそういうことをして、あとはチャットとかでコミュニケーションをしていました。しかし、リモートワークが得意な人は、チャットとかも使うのですが、ものすごく頻繁(少なくとも日に1回ぐらいはあるペース)で、Teamsとかのチャットをつかって「Can I have a quick call?」とか言ってきます。自分がいまOKであるなば、「Sure!」とか送り返すと、向こうからコールがかかってきて1対1で話したり、画面を共有して一緒に作業したりします。最初は正直、「あつかましいおっちゃんやなぁー。」と思ってたけど、実際にやってみるとこっちのほうが劇的に生産性がよくて、自分の時間をも節約できることがわかってきました。だから今は私も困ったことや、つまったときは、すぐに「Can I have a quick call?」といって、すぐに1対1の通話を始めます。

f:id:simplearchitect:20200415094542p:plain

クイックコールの良いところ

正直なところ、リモートになると、対面の時より、みんなで集まるときの会議の生産性が良いように感じません。実際に成果がでるのは、個人個人の成果を出す作業にどれだけ時間を使って、それを生産的にできるか?ということが重要に感じます。ですので、みんなでする会議は簡単な進捗のシェアと、今抱えている問題のシェアだけというのが最も効率よく感じます。で、それぞれ、自由に作業をするわけですが、私のようなソフトウェアの開発者でも実際にコードを書き始めれる状態になればいいのですが、その前にいろいろコミュニケーションが必要になります。それがチャットだと、やっぱりやり取りに時間がかかって多くの待ち時間が発生したり、誰かが本来知ってたり、すごく詳しかったりすることでも、チャットで呼び出して反応してくれなかったら、待っていたりします。答えが返ってきたとしても、その答えをみて、次の質問が浮かんだりしてもどうしようもありません。またチャットで自分が抱えている課題を英語で説明しようとしても、伝わりにくいこともあるし、見てくれないこともあります。

www.youtube.com

ところが、クイックコールを頻繁に使うようになると、上記の問題が全部解決します。例えば、コードを書いていてうまく動かない時があったとしても、画面をシェアして「Look at this」というだけで、相手は状況を理解してくれます。複数人がいる会議だと、自分がだけが理解できてない場面ではやっぱり会議を止めるのがつらいこともありますが、1対1だと、「Does it make sense?」と聞かれても「No. Could you tell me one more time?」とかいって聞き返しやすいです。私は Microsoft Teams を使っていますが、他のツールでも、自分のディスクトップの画面をシェアして、一緒に作業とかも簡単に今はできますし、そういったビデオ通話の機能がないものでも、例えば、PowerPoint や Word, Excel 、そして、VSCodeVisual Studio も、単体で、他のリモートの人と状況をシェアして一緒にコーディングやデバッグが出来る機能が備わっています。一人でうんうんうなるより、知ってる人とたとえ10分だけでも一緒にやるだけで、自分一人でやることを思うと100倍速いですし、チャットと違って、新しい質問が浮かんでも瞬時に答えが返ってきます。これ最高!

クイックコールされる側もよいことがある

さて、クイックコールをする側のメリットは十分にわかりましたが、される側はどうでしょう? 実はされる側も随分楽になります。なぜなら大抵のクイックコールはそんなに長くかかりません。オフィスにいて、「ちょお、教えてくれへん?」の感覚なので、この程度でものすごく楽になるのがわかります。都合がわかるければ、「Sorry, I'm not available. Are you available at 11 am?」とか返してあげれば自分がフォーカスしたいときに邪魔されることもありません。また、自分が、気軽にクイックコールを受け付けていると、自分が困ったときも相手が簡単にクイックコールを受け付けてくれます。しかも、クイックコールが無かったら、自分も相手に答えをチャットで書いてあげないといけないですが、伝わらないかもしれませんし、やり取りが発生して面倒になることも多いです。

クイックコールが文化になるといろいろはかどる

今のプロジェクトで経験したことなのですが、最初はこのようなクイックコールをするのは、リーダーのリチャードだけだったのですが、私含めて、みんなが徐々にクイックコールが楽だと気付き始めて、みんながやるようになりました。今では一日に何回もクイックコールをしています。そして、とても生産的に感じます。バグを探すのもわからなければ、すぐにチャットして、クイックコールするとすぐわかって、3分でクイックコールを切ったりもします。こんな風に、みんながクイックコールのことに気づいて文化になると、ホンマいろいろ楽です。ガチで楽です。だから、こういうことをシェアしようとしてブログを書きました。

自分的には常時接続より好み

個人的な意見ですが、私はクイックコールのほうが、常にチームの全員と接続している環境より好みです。せっかくリモートワークなのだから、正直だらだらするときはだらだらして、フォーカスするときはフォーカスしたいです。要は成果なのですから。あたまが疲れてきたら、ランニングに行ったり、筋トレしたりマンガ読みたいです。フォーカスして、他の人に話かけられたくない時もあります。もちろんこれは好みの問題なのでそれが悪いとも非効率とも思いませんが、私的にはだらしなくて、1日で成果の帳尻を合わせるタイプなのでクイックコール好き派です。

おわりに

今回は自分的には劇的に効果のあったクイックコールをご紹介しました。次回は英語環境下でのコミュニケーションのポイントでもご紹介しようかなぁ。