メソッド屋のブログ

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

「自分を否定する」呪縛をとく

前回のポストでは、自分が人生の必殺技と思って使っていたマインドセットをシェアしたのだが、 コメントを拝見していると「強者の理論」というコメントを沢山いただいた。

「自分を否定する」呪縛をとく

 これは私の書き方の配慮が足りなかったのだと思う。私は昔は完璧主義なのに、運動も勉強もなにをやってもできないのび太君みたいな感じだったので自尊心は皆無だった。だから、自分が失敗するたびに心もつらく、自分はなんてクズのような人間なのだと考えていた。

simplearchitect.hatenablog.com

 自分はADHDで、ダメ過ぎたので、前に進むしかなかったが、とんでもなく出来ない自分に、正直なところ、運を恨んで、世間を恨んで、悲観主義でそして、自分に常にダメ出しをして価値の無い人間と考えていた。そして実際何をやってもうまくいかなかった。

 しかし、そんな自分を救ってくれた出来事があって、今は精神はとても安定している。そして、現在は上記で紹介したようなマインドセットになっている。もし、自分と同じようなことで苦しんでいる人がいたら、きっとあの記事はたしかに「強者の理論」としか思えないだろう。

 だから、そんな人はいるのかわからないがその人のために、どうやってそんな苦しい状況から抜けたしたのかというエピソードを公開したいと思う。それはあなたのせいではないし、誰でもなる可能性はあるし、そうなるのはどうしようもないことだ

「なんてお前はダメなんだ」と自分に常に語り掛けていた

 私が昔、何か自分がうまくいかなくて、失敗するといつも心の中で「なんてお前はダメなんだ」と自分に叱咤していた。本当は出来るようになりたいのに、現実は全くできないどころかどんなに努力しても普通の人並みにもなれない。自分の人生が早く終了したら楽なのにと本気で思っていた。自分の親父は上記のポストでも書いたが、自殺したが、直接の死因と言えるのは躁うつ病だった。

 躁の時は、「俺は偉い」と母を相手にがなり立てたり、夜中に大音量でバイクをふかして団地暮らしの家に帰って来たりするから、めっちゃ恥ずかしかった。鬱の時は一転布団から出てこない。自分はそういう親から生まれたのだから、自分の遺伝子にも入ってるから、絶対に自分は結婚できないな、しちゃいけないなと思っていた。今から思うと父は繊細な人だったのだと思う。

ワインバーグのスーパーエンジニアへの道

 しかし、その日々は終わりを告げる。全く意外な方向から。ワインバーグさんは、ソフトウェアの世界で有名で、数々の名著を書いている。私はコンサルタントの道具箱という書籍を最初に読んで衝撃を受けた。彼はロジックの塊のようなコンピュータの世界に初めて「人の心」を持ち込んだような人物である。

 例えば、こんなエピソードがある。エレベータがあっていつも混雑していて、制御がうまくいってなかった。そんな時にクライアントはコンピュータの専門家たる彼にその解決を依頼した。彼はどうしたかというと、エレベータの前に鏡を設置したのだ。それによって、人々が鏡で自分の身なりが気になるので、エレベータが遅いということが気にならなくなった。。。というのに代表されるように、技術よりも、人の心をも巻き込んだソリューションの数々は目からうろこで私も大変影響を受けた。

「その日」は突然やってきた。最初の本に感銘を受けた私は、次のワインバーグさんの書籍を探していた。コンサルタントの秘密もとんでもない名著で次への期待が膨らんだ自分が選んだのは次の「スーパーエンジニアの道」だった。

www.amazon.co.jp

 その書籍には技術者として「自尊心を高める」のがいかに大切かかかれていた。「そんなん言っても、俺は自分のこと世界で一番クソな人間やと思ってるねんけどな…」と正直思いながら読んでいたらなんとそこには「自尊心を高めるメソッド」が載っていた。それは「サバイバルルール変換」と呼ばれるものだ。必要なものは紙と鉛筆だけ。私はそれに従って、サバイバルルール変換のワークをやった。本代しか使ってないが、30分後自分は「ああ、俺もまわりの人程度には価値があるな」と人生で初めて思うことができた。たった30分で、自分の30年以上間、最低だった自尊心が高いとは言えないが0にまで復帰した瞬間だった。自分には天地がひっくり返ったような衝撃で、その後いろんなことがつらくもなんともなくなって、どんな失敗をしてもたいしたことに思えなくなった。なにより、心がつらくなくなった。

サバイバルルール変換を体験する

 サバイバルルールとは、自分が過去に生きてきた過程で各自が持っているルールや思い込みだ。特に自分の強い感情と結びついているものがある。これを自分でちがったものに「変換」してしまうことができる。自分の地の底まで落ちた自尊心をレベル0に回復させるのは本当にいろいろな効果があった。「スーパーエンジニアの道」に記載されているステップの通り実践してみよう。

第一段階 規則を明確かつ具体的に述べる

 例えば、私の場合「私は仕事が出来なければ価値がない」というサバイバルルールを持っている。強い感情を持っていた。それを感じるときにはいつも心がつらかった。自分の心がつらくなるサバイバルルールをピックアップして明記する。それを探すためには、「何に自分がつらく思っているか」、何を「しなければならない」と思っているか?を考えてみると見つけやすい。見つけたルールを紙に書き出してみよう。

第二段階 その規則のサバイバル上の価値を承認し、自分の無意識と取引する

 このステップはすこし理解しずらいだろう。どういう事かというと、上記のような強い感情をもったサバイバルルールは幼少の頃のトラウマと関連していることがほとんどだ。だから、セラピーの世界では催眠誘導などを行いながら、その「根本原因」が何であるかを調査をしたうえで、こういった心理療法を行う。何故かというと、これらのサバイバルルールは自分に有効だったからそれが形成されたのだ。上記のものの場合、例えば「自分は人として価値がない」と思い込むことによって、幼少の頃に、自分が全然できないのに、もっとがんばって、失敗して自分が傷つく状況を回避してくれていたのかもしれない。でもそれは、セラピストなどの専門家の分析が必要だ。そうでないと、勝手にサバイバルルールを書き換えようとすると、自分の無意識が反発してしまうのだ。  だから、次のようなことを自分の無意識に暗示としていれるために、ワインバーグの次の文章をかみしめながら書くとよいだろう。

この規則は、私が生き残ってくるのに有用だった。だからそれを追い払おうとは思わない。手元に置いておいて、適切な状況に出会ったら使おう。私は新しい規則をつけくわえるかもしれないが、古い規則も使いたくなったら使えるように取っておく

第三段階 自分に選択の余地を与える

「私は仕事が出来なければ価値がない」というのは、選択の余地がない。だから、選択の余地を与えて文を書き換えてみよう。「~なければならない」を「してもよい」に変えよう。かみしめながら紙に書いてみよう。

「私は仕事が出来なければ価値がなくても良い」

第四段階 確実性から可能性への変換をする

 上記の文は暗黙のうちに、「常に」という意味がはいっている。だからそれをちょっと緩めて、いつもじゃなくそう。次のことをかみしめながら紙に書こう」

「私は時には、その気になれば、仕事をしてもよいし、価値がなくても良い」

第五段階 規則の中の全体性を非全体性に変える

 価値がないというのは全体性を表しているのでそれを非全体に変えてみよう。こころに刻みながら文を書こう

「私は時には、その気になれば、仕事をしてもよいし、価値があっても無くても良い」

 かなり気持ち的にふわふわしてきたことだろう。

第六段階 一般を個別に変える

 まだ文は、固定的な一つの状態について述べているので、3つぐらいの条件を付けてみよう。

「私は、 自分の心が穏やかな時や、 自分がつかれていない時や、 自分がそうしようと思うときに、 自分は時には、その気になれば、仕事をしても良いし、楽しんでよい。やってもやらなくても 他の人とちょど同じ程度に価値があっても良い」

 これを読んでいるだけだと、本当に?と思うが、この段階まで来ると、あれ、なんで俺自分に価値がないって思ってたんだろ?ぐらいの気分になってしまった。

 え?こんなことでと思うかもしれないが、ワインバーグが書いているように本当にめっちゃ効いた。これはあくまで私の例なので、人によって心に来る思い込みは違うから、是非「スーパーエンジニアへの道」を読んで、紙とペンを用意して実践してみてほしい。私も今回久々に現在の自分がもっているサバイバルルールを見つけてやってみた。自分はなんでもないと思っていたが、心に来ていたことに気が付いた。これ以外にもいろいろなサバイバルルール変換を行って、気持ちに余裕が出来て自分をより客観視できるようになった。

サバイバルルール変換をやってみた

なぜそんなことが実現したのか?

 どうやら、ワインバーグはヴァージニア・サティアという心理療法家から心理を学んだようだ。上記のメソッドも彼女から学んだようだが、NLP神経言語プログラミング)という手法があるらしいというのがわかった。自分も衝撃を受けたので、その手の本を沢山読んで学んだ。私はもちろん専門家ではないので、それや、私の知識が正しい知識かわからないが、人がそういう反応をしてしまうには次のステップがあるようだ。

  • 子供の頃に何らかのトラウマが発生する。これは、親が虐待してたとか限らず、ものすごく小さなきっかけによって発生するケースもあるため、親が悪いとはいいがたい
  • そのトラウマに関するイベントが発生すると、トリガーが引かれる。そのトリガーによって幼少期にトラウマになった時の感情が再生され非常につらい気持ちになる
  • 本人はそのトラウマについてすっかり忘れているし、思い出せないことも多い

 これは、だから本人のせいでもないし、親のせいでもない、性格ではない。たまたま偶然当時の小さな本人の心が何らかの(時には大人からみたらほんの些細な事)によって、トラウマになって、トリガーが植え付けられて、それがいろんなきっかけで発火して、そうなったら、本人にはそれは止められない。つらくなって何もできなくなってしまう。周りの人からたら「難しい人」と言われるようになってしまう。

 つらさの大小はあれ、こういう仕組みなので、本人はどうしようもない。努力とか、根性とか、理屈でどうしようもない問題なので。だから決して本人のせいではない。 じゃあ、どうやったらその状況を取り除けるのかというと、「トリガー」を除いてあげればよいのだ。過去のことを思い出しても「感情」の方が再生されなければよい。

 それを書き換える手法が「神経言語プログラミング」と呼ばれるテクニックだ。上記のサバイバルルール変換もそういった手法の一つと思ってもらっていいだろう。これらの手法には、サバイバルルール変換みたいに自分でやれるものがある。他には効き目は個人差があるが、EFTというツボをつかって暗示を入れる方法もある。NLPの手法の場合は、専門家の助けが必要なテクニックも存在する。サバイバルルール変換を見ていただいてわかるとおり、そんな恐ろしい何かではなくきわめて単純なんだけど、本当に強力でびっくりしてしまう。

 その後も、そういった方法を学んで、自分の心が反発することなく、すべての人には価値があると考えられるようになり、自分を客観視できるようになった。でも、これは自分の実力や努力ですらなく、たまたまそのことにワインバーグ先生の本で出合ったからに過ぎない。ちなみにワインバーグ氏は、この方法を自己肯定感を上げて技術リーダが実力を発揮するためのツールとして使っているようである。

あなたのせいではない。誰でもそうなる可能性がある。しかし、方法はある。

 この話はセンシティブな話であり、私は専門家でないし、今だとUpToDateなものでもっとより良いものがあるのかもしれない。正直シェアするのも怖い。でも、これが私を長年の低い自尊心と自分を責めて苦しめるトリガーから解放してくれたのも事実だ。そして、学んだ知識を利用して、さらにセラピストの先生に習って、心理学をもっと勉強した時期もあり、それは、精神的安定だけじゃなくて、いろんなことにも役立っている。特に営業や、教育の方面で特に役に立った。

 私の親戚にも、私よりもっと強いトラウマを持った人が何人かいたが、私がそのセラピストを紹介したら全員社会復帰して、今は皆元気そうだ。今は本も出している立場なので、専門家でもない私が安易にその先生を紹介するのとかは避けようと思うが、一つだけ言えることは、こういったことは、決してあなたのせいじゃないし、親のせいでもない。そして、ソリューションが世の中には存在するという希望をこのポストで伝えたかった。

だって、たった一冊の本が自分の人生を救ってくれたから。ありがとうワインバーグさん。そのことを書いてくれて!

最後にワインバーグさんのカンファレンスをみんなでやった時のポストをシェアします。

simplearchitect.hatenablog.com

 この話は載っていませんが、世界一流のエンジニアがどんな思考法をしているか、そして、どんな組織で働き方をしているか?という本を書きましたので興味があればぜひご覧ください。おかげ様で非常によく読んでいただいています。エンジニアだけではなく、ビジネス書なので、どなたにも生産性向上の参考になるように書いています。

「何をやっても駄目だった」ポンコツの自分を救ってくれたマインドセット

 先日 エンジニアType さんから取材『牛尾剛さん、『世界一流エンジニアの思考法』って本当に日本でも実行できますか?(仮)』を受けました。私は「日本で出来ないことは何一つありません」と回答しました。私が日本にいるときに実際に実施したアクションや、実際にやってみた事例などをご紹介しました。

 それは、私が自信に満ち溢れた人物だからではなく、幼少のころから自己肯定感も低く、何をやっても上手くいかなかった自分を救ってくれたちいさな「マインドセット」があったおかげです。

「何をやっても駄目だった」ポンコツの自分を 救ってくれたマインドセット

 このマインドセットは『日本では一見難しそうな何かを実現すること』に対しても過去の人生でとても有効でした。同じような悩みを持つ人のために、エンジニアTypeさんの記事のフォローアップとしてこちらにも書いてみることにしました。それは小さなマインドセットのチェンジなので、少しだけ練習するだけであなたにも手がとどくような小さな「考え方」の転換です。

現状は過去の自分の選択の結果

 そのマインドセットは単純で、「他の誰かや、世間の仕組みによって『何かが出来ない』ということは一切世の中に存在せず、自分の選択の結果しかない」と考えることです。物理的な法則で不可能なものは世の中に本当に少ないはずです。ただ、多くの人が『自分以外の何か』によってやりたいことが出来ない悩みを持っているようです。その状態は面白くないでしょう。だって他の人に自分の人生握られるなんてなんも面白くないし、それによって自分のやりたいことが出来ないとかつまらなさすぎます。

 ただ、『現在の状況は、自分が、自分の意志で選択した結果そうなっている』ということを理解すれば事態はいろいろ簡単でシンプルになってきます。自分の選択で現在の状態になっているのであれば、今日から違う選択をし始めたら、もちろん自分にとって面白い未来が待っているということですから!

 このマインドセットについて解説してみたいと思います。

部長が絶対に許してくれない

頑固系部長

 例えば、本に載っているような新しい開発のやり方をやってみたいとします。でも部長が絶対ゆるしてくれないから無理だ。という状況があるとしましょう。この状況は実際は出来ないのではなく、自分が「やらない」もしくは「やりたくない」という意思決定をしています。どういうことかと言いますと、実際にはこの状況を突破するためには無限の方法があります。自分が「やりたい」と思うのであれば。 例えば

  • 部長を説得するために、心理学を学習して実践して、部長を説得する
  • 部長がそれをいやなら、他の部署のわかりがいい人のところに異動させてもらえるように働きかける
  • 部長を政治的圧力で更迭して、他のわかりのいい部長に来てもらう
  • 部長がダメならその上の事業部長に相談してみる。それでもだめならその上に行く
  • そういうのがめんどくさいなら、会社を辞めて、やりやすいところに転職する…

など無限に見つかります。ただ、こういうのにエネルギーを使うのが面倒だったり、そこまでパッションなかったりするので、「やらない」という選択をしたにすぎません。もしくは「難しいから無理」とやる前から思い込んでいるというケースもあるでしょう。

 例えばこの例だと、実際は勇気をだして部長に話してみると「新しいことをやるのはいいことだね。今のプロジェクトは今からは変えられないけど小さな安全なプロジェクトで試してみようか」というケースも実際によくありました。やってみなければ「難しい」かすらわからないことに気づきました。ちなみに私は「努力」すらお勧めしているわけではありません。例えば、「努力はめんどくさいから、努力せずに自分の思ってることを達成したい」と考えて工夫するのも最高だと思います。自分に行動力がないと思うなら、行動力のある人を味方につけてやってもらうでもいいかもしれません。ポイントは「行動する」こと、そして「行動」しないと次のフィードバックは得られないということです。大抵の人はやる前から尻込みしているのにすぎません。やってみると簡単かもしれませんよ。

 「やりたくない」とか「やらない」選択は何も恥ずかしいことではありません。自分の人生に対して自分に対して命令できる人は世の中に存在しません。私も時間は有限なので「やらない」「やりたくない」みたいな選択をすることももちろんあります。だから、第三者や自分以外の何者かのせいで何かが出来ないという状況は存在しません。よかれ悪かれ、「自分で選択」した結果が現状になっているのです。どう思っていても、すべて「自分で選択している」とわかったら気が楽じゃないですか?

人生をコントロールする

 ストレスは自分が「コントロールできない」状況から生まれるのではないでしょうか。例えば、上記の例で、自分がそこまでそれをやるエナジーが無いので「やらない」という選択を自分でしたとしても、「自分が選択した」のだから、ストレスがありません。気が変わっていやになったら辞めてもいいです。社内の中で頑張りたかったらそれでもいいです。一度やらないと決めたけど、やっぱりやろうかなと思ってもいいです。

 つまり選択は常に自分であり、他の誰かにコントロールされることは存在しないという考え方です。私は同時に他に人に「〇〇すべき」とかいうのはおこがましいと考えています。この考え自体も私の考えをシェアしているに過ぎません。ただ、観察してみると私と同じようにこんな感じで考えている人は総じてストレスがなく、本人が楽しそうです。

出来ないケース

 じゃあ、出来ないケースはないのか?と考えられるかもしれません。物理的に不可能な何かだと無理かもしれませんが、本に書いてる内容でそんなものは存在しません。このマインドセットだと出来ないのではなく、「やらない」と自分が選択しただけという考え方になります。もしくはやる前から「無理と思い込んでいる」でしょうか。それも結局自分で「やらない」を選択しています。「やらない」とか「やりたくない」のケースはなぜやる必要があるでしょう?それは恥ずかしくもなんともありません。人生の時間は有限です。そして「やらない選択をした人」や「やりたくない選択」をした人に無理からやらせるなんておこがましいと思います。ただ、自分が「やりたい」と思って行動するなら出来ないことは何もないと断言できます。

才能ないし、親も貧乏なんやけど

 私はこの前ある人に「マイクロソフトに入社するのはすごく難しいですよね」と言われてびっくりしました。なぜびっくりしたかというと、私はなんも苦労してません。私の同僚でマイクロソフトが好きだから時間をかけていろいろ工夫して入った人もいます。よく考えると、その発言をした人はやったことも、入社するために戦略を立てたり、工夫したこともないのになぜ「難しい」とわかるのでしょう?本当に世の中はそんな「難しいこと」だらけでしょうか?答えは多分小さな勇気と行動です。多分マイクロソフトのに入った他の人もたぶんこう答えると思います。「難しくはないよ。ただ自分で行動したからここにいる」。

Microsoft

 なんとなくの私の妄想かもしれませんが、そういうケースは、マイクロソフトに入るような人は、才能にあふれていたり、親の経済状況が良かった人なのだろうと思っている節はないでしょうか?確かに才能の違いも親の経済状況の違いもあります。くっそポンコツの私の例でお話しますと、私は才能ないですから、普通の人の3倍かかります。才能ある人が3倍速くできるとします。じゃあ、私が9年今のまま頑張れば、「才能ある」人の1年目の状態に到達するかもしれません。みんなが「こいつできる!」と一目置くような状態に。

そこそこ貧乏でした

 私の家の経済状況を公開しますと、貧乏でした。極貧ではないかもしれませんが、父親は良かった時に儲かったお金をすべて使い果たして、借金を残して自殺しました。家族は貧乏な公団の団地暮らしだったけど、母はそんな状況でも必死に働いて自分たちを育ててくれました。大学にまで行かせてもらえましたがもちろん奨学金です。そんな親になんの文句が言えるでしょうか?感謝しかありません。人の経済状況のスタート時点はそれぞれやけど。そこからは自分の人生のターンです。自分でコントールできないそこを嘆いても残念ながら何も Happen しません。

 私はマイクロソフトの Azure Functions のチームにいます。物凄ーーーーく頭いい人、明らかにスーパー才能ある人もいます。でも、自分の一番のヒーローであるクリスに対して「才能ある」とか「頭いい」とか思ったことはありません。当たり前ですが全員がそうではありません。一方私がスーパー頭いいと思ってる Paul とか、めっちゃくちゃ才能ある Glenna は楽して今のポジションにいるかというと、彼らは明確に頑張っています。行動して、頑張ったから今のポジションにいます。彼らに才能あっていいなとかいうときっとこういうでしょう。「いや、わしがんばったんやで。失礼な」と。

才能ある人とは?

 才能とか親の経済状況とかは、0.0000000000001 ぐらいしか作用しないと考えましょう。自分がどういう状況であろうとも、そういうマインドセットで考えるといろいろ良いことに気づきました。正直誤差です。オリンピックで金メダルとか Top of top の世界なら影響あるかもしれませんが、そうでなければ、人がうらやむような環境を手に入れるために必要なことは小さな「行動」です。人がうらやむような環境にいる人を何人も見てきましたが、誰一人として本人が行動せずその位置にいる人はいません。才能ある人も、ない人も、親が裕福な人も貧乏な人も誤差の範囲内であり、いくら才能と親が裕福な人でも、本人が「行動」しなければ、何も Happen しないので、才能も無いし親貧乏やけど、行動する人と比較すると、比較もできないぐらい惨敗します。繰り返しますが、自分の選択以外の要素で何かが起こることはありません

 そんなことを言っても実際はちゃうやろと思う人もいるかもしれません。そういう人に見てもらいたいマイクロソフトの吉田さんのポストがここにあります。ぜひスレッドを見てみてください。紹介されている10人は本当にみんなが考えるエリートなんでしょうか?

 彼はアメリカの就職にはコンピュータサイエンスの学位が必要だというポストに対して次のように反対意見を述べました。ちなみに、吉田さんは、就職できずマクドナルドでバイトしていた状態からマイクロソフトに入って大学に平行して通って、毎年のように出世して若くしてすでにプリンシパルです。でも「才能」ではなくて彼の場合純粋に「努力」だと思います。単純に自分より彼がやっているから、彼が自分より認められるのは当然です。このように考えると、ストレスも嫉妬もなにもありません。「やる」も「やらない」も自分が決めた結果だし、いまから変えたければ、何らかのものを「やる」に変えるだけですからシンプルです。

本当にできるのかよ?

 じゃあ、お前できるのか?と言われそうですが、私の具体的な事例ややり方をエンジニア Type さんに、日本でどうやって導入して、実践して、そして成功したのかをすべてお話しておきましたので、リンクを参照していただければよいと思います。

ただ、これは私の事例であり、皆さんの状況はどれも違うでしょう。しかし、今回お話している「マインドセット」が自分が紹介したすべてを可能にしてくれました。

 何もできなかった自分であっても、多くの人が実施しない小さな「行動」をすることで。自分の場合は、自分がダメすぎて、前に進むしかなかったのですが。だから、「やりたい」ともし選択したならば、「どうやったらできるだろう」と考えて、やってみて、うまくいかなかったら「なぜうまくいかなかったんだろう。次はこうしてみようかな」という感じでうまくいくまでチャレンジすればよいです。上記で紹介した方法はこのようなマインドセットで行動した結果の一例ですので、様々な状況にきっとフィットするのはマインドセットの方が汎用性があります。

自分が望んだ姿へのステップ

難しく考えなくてもこのプロセスでほとんどのケースは問題解決します。もちろん途中でエナジーがなくなったら「やっぱめんどくさいからやらんとこ」と思ってもなんも問題ありません。だって、自分の幸せが何より重要ですから!そのケースでも自分で「やらない」と選択したわけですから。自分の心がつらくなりません。

自分の人生を好転させる方法

取材でもお話しましたが、上司に紹介してもらった本で、私もお気に入りの Atomic Habit を紹介したいと思います。日々のほんの小さな「習慣」を積み重ねることで本当にすごいことが達成できます。こういう努力とも思えないような「小さな習慣」を積み重ねることで本当に人は遠くに行けます。もし努力したくないなら、努力せずにどうしたらできるかを考えると良いでしょう。

Amazon.co.jp: ジェームズ・クリアー式 複利で伸びる1つの習慣 eBook : ジェームズ・クリアー, 牛原眞弓: 本

まとめ

人生において第三者によって、「出来ない」ことは物理法則以外存在しません。「やる」「やらない」というジャッジを自分が選択しているだけです。だから、自分がやりたいことがあるならば、自分がやりたいことにフォーカスして「やる」判断をして、自分にとって重要でないことは「やらない」ジャッジをして負荷を減らします。ただそれだけです。自分以外の第三者や環境によって左右されるものなど存在しません。  自分次第です。自分の人生は自分で責任をもってコントロールしてエンジョイしましょう! 本当にたったこれだけのマインドセットのチェンジで、ほとんどの「日本では出来ない」問題は解決します。そうして、小さな習慣を積み重ねれば、自分がなりたい状況に徐々に近づいていきます。特に他の人がこういうマインドセットでないなら、大チャンスです!皆さんがもっと人生をエンジョイできますように。

他の具体的なTips はぜひエンジニア Type さんの記事をお楽しみください!

最近ありがたくも沢山読んでいただけているのですが、世界一流エンジニアの思考法という本をだしましたので、もしよかったら読んでくださいね!

日米でエンジニアの育成戦略が正反対だと気付いた話

今週は、Thanksgiving はお休みムードなので考える時間や、自分の本についてディスカッションしている バンクーバーのえんじに屋さんのPodcast なんかを聞かせていただいたりしてるうちに、思い出したことがあって、記録に残してみることにした。それは、エンジニアの育成方針でこれはめっちゃくちゃ違うことに気づきましたので、シェアさせていただきたいと思います。

日米でエンジニアの育成戦略が正反対だと気付いた話

採用の段階での違い

 良く知られているように、新卒のケースで考えると、こちらの場合は「コンピュータサイエンス」の学位を出ていることが前提で、中途採用の場合も、「コンピュータサイエンス」の学位を出ている、もしくはそれ相当する知識が求められる。だから、新人でも少なくともプログラムが結構組めることを期待されます。

 一方、日本では文系でも理系でもプログラマになれます。採用されたときに「スキルがある」ことは期待されないので、新入社員教育とかがあって0から教育ぐらいの勢いのカリキュラムが組まれます。どちらも体感した正直な実感としては、アメリカ式の方が圧倒的に良い気がします。というのも、「基礎がちゃんとできている」ことを企業がそもそも期待するので、きっと学生の方や中途採用の方もちゃんと勉強したり、プログラミングを練習してくるのだと思います。インタビューもコーディングインタビューとかします。

 これは「文系の人はプログラミングになるべきではない」ということが言いたいのではありません、「それ相当の知識が要求される」ことによって、採用の段階で、学んで応募者がその水準にもってくることが重要だと思います。それによって、エンジニアのレベルの平均値が相当違う感じを受けます。逆に世界の潮流では、日本式の「コンピュータサイエンス学位」のリミットを外す流れもでていると聞きますので、門戸は広い方が私も良いと思います。かつ「コンピュータサイエンス」を出てる程度の実力を求めるというのが一番いいのかなぁとか個人的には思います。

入社後の違い

 先ほど書きましたが、日本の場合は一括教育で全部教えてもらえます。新人は「知らないもの」として扱われるので簡単な仕事しかさせてもらえません。アメリカで働いていると、新人でもキャリアのある人と同じように扱われます。もちろん Junior であるので、マネージャが手厚く助けてくれたりとかはありますが、基本的には他の人と同じです。何か自分に足りない知識があったら自分で調べて身に着けます。日本の場合は、会社で使うツールなどに関しては結構手厚い手引きや参考文献とかが用意されています。

 アメリカだと、自分が知りたい知識があったら自分からその分野をよく知っている人にコンタクトをとってミーティングを設定したり、コードやドキュメントを読んだりして理解を深めます。  これは前のセクションで書いた通り、採用時点で「スキルがあること想定」か「スキルが無いこと想定」の違いなのかなぁとも思います。

設計・アーキテクチャ

 私は大手SIにいたしそれは昔の事なので今でも、すべてのチームがこうであるとは思いませんが、自分が実体験したことを書いておくと、日本の時はアーキテクチャを考えるのは一部の標準化グループとかアーキテクトと呼ばれる技術的に優れた人もしくはグループでそれ以外の人はその標準化グループが作ったフレームワークの上で、仕様書通りにコードを書きます。そうでなくても、それ以外の人はアーキテクトと呼ばれる人が作ったアーキテクチャの上で比較的簡単なコードを書くことが多いです。

 一方自分がアメリカで体験していることはゴリゴリに違います。たとえ New Grads(新卒) であっても、アーキテクチャをその人がリードします。リードすると書いているのは、他の人の「脳」を借りてその人が主体的になってアーキテクチャを考え、設計します。日本ではアーキテクチャを考えて実装する経験はアーキテクトで、それ以外の人はあまり経験が積めませんでした。ただし、現在もそうなのかは私はわかりません。今だとそうではない企業もありそうです。

 私の例でもそうですが、私は今のチームに入るまでもちろんクラウドの中身の設計とかやったことがありません。そんな人でも自分がアーキテクチャとか設計のリードになります。しかし、経験や知識が足りないので普通だとうまくいかなそうですが、実際どうなるか?というと、その人が「リード」して、必要な経験のある人やマイクロサービスのコンポーネントの知識がある人にお願いして、一緒にアーキテクチャを考えてもらったり、考えた設計をレビューしてもらったりします。だから、全員が、アーキテクチャや設計の経験をします。

標準化の考え方

 日本にいるときは標準化で細かくルールが決まっていて、それに従わないといけない感じでしたが、こちらは人にまかされています。そもそも、コンピュータサイエンスを学んでいる前提なのでそんな変なことになりません。おかしな設計や人が読みにくいコードを書いていたらレビューで指摘されます。標準化という考えというより、何か全員がやらないといけないことがあれば、たいていそれは自動化されて、自動で適用されます。

オンコール

SIerの場合は、オンコール(障害担当する週間)はありませんでした。開発したら保守する会社さんが引き継ぐので。もちろん日本でも内製の会社だと違うと思いますが、私の職場では開発者でも、障害担当をする習慣があります。インシデントが来るのが嫌だし、自分のコードのせいで障害が起こると面倒なので、保守しやすいコードを書こうという考えになりますし、障害が起きたらいろいろ考えて設計も工夫するようになります。

エンジニアの成長の度合い

エンジニア育成戦略の日米の相違

 上記で紹介したような違いを整理すると上記のテーブルになるでしょう。日本時代のものと比較してもそうですが、実感の上でもこちらの開発環境の方が全然早く「エンジニアが育っている」という感じを受けます。日本にいるときは、ものすごく基本的な部分もあやしい人や、経験を積んでいる人でも独自流でソフトウェア設計の考え方からするととんでもないような設計(クラス連番、オブジェクト指向/関数型禁止、async/await 使わない、ものすごく大きなロジックにまみれた重複だらけのクラス、全部スタティック…)をしている暗黒なものも山のようにみましたが、こちらで見たことがありません。あってもレビューが通らないでしょう。

 日本のエンジニアの育成(特に私がSIで経験場合)は、優れた少数な人と、それ以外というモデルで育成が設計されており、「だれでもできるように」思想でフレームワークも作られてるし、アーキテクチャや設計などスキルが必要な場面は特定の人しか経験できませんでした。こちらだと、それが誰でも最初から経験できるのが物凄く貢献しているのか、そんなに経験無いエンジニアでもガンガンに難しいことにチャレンジして実装して、保守します。もっと言うならインターンでも結構主要な機能の開発とか任されることもあります。

 日本型の、「優秀な人だけが担当」モデルだと、設計でこけないのかもしれませんが、それ以外のエンジニアが育つことはありませんし、高度なことをするチャンスももらえませんし、なにより楽しくないと思います。他の課題としては、チャレンジングなことが出来なくなります。誰でも書けるフレームワークを目指すということは単純なことしかできなくなるので、重複も多くなり、開発スピードや品質に多くの影を落とします。

 だから、私がアメリカに来てからは、日本時代には体験できなかったような難しいこと、複雑なことにチャレンジする必要があり、正直楽しくて仕方ありません。アーキテクチャも設計も自分で決めます。だから、指示待ちなんて人は存在しません。新人をフォローする時も、めっちゃ基礎的なことはみんな勉強してくるから、そんなことを教える必要もないのでめっちゃ楽です。(そして感謝してもらえる)

まとめ

 自分的な意見としては日本も、こっち型にシフトしたほうが、会社にとってもエンジニアの成長して生産性やクオリティが上がるし、エンジニアも成長できてうれしいし、難しいことにチャレンジできて楽しいと思います。たぶんそういう会社も今は日本でもあると思うのですがそういう会社さんが増えるとよいなぁと思いながら書きました。

最近『世界一流エンジニアの思考法』という書籍を執筆しました。よかったら読んでみてね!

 

令和の時代に本を読む必要はあるだろうか?

 私は本来本好きの人間であるが、最近はめっきり本を読む機会が少なくなった。技術を学ぶなら pluralsightとかのビデオのコースもあるし、Webの公式ドキュメントも充実している。よしんば本を読んでも紙ではなくKindle が多い。ブックマークもつけれるし、サーチもできるし、老眼にもやさしい。本ってもうオールドファッションのメディアじゃないだろうか?

 最近本を書く機会があって、そんなことを考えたので久々にはてなのブログのほうで考えたことを書いてみたい。

本を書くべきかどうかの葛藤

 私は米国のマイクロソフトで Azure Functions というサーバーレスのサービスの開発者として勤務している。アメリカで働いているので日本で本を書こうとか全く考えていなかったが、ある日文藝春秋の山本さんが突然コンタクトをとって来て「本を出しませんか」と言われた。私は普段はnoteで自分の学んだことを、自分のための記録としてブログを書いているのだが目に留まったらしい。

 こんなことを書くのはこのブログが初めてなのだが「わーうれぃしい!本書けるぞ!」とは思わなかった。正直にいうと私の感想は「今の時代に本書いてどうかなるんやろか?」だった。自分の最も大切といえる「時間」を本に投資していいものか。自分はエンジニアとして一流になりたいのでそちらの方に時間を使うべきではないだろうか?

note.com

本を書いて何になるのだろうか?

 私は過去に数冊本を書いたことがあるので、本を書く大変さは経験済みだ。物凄く時間がかかるし、きっとものすごくベストセラーにでもならない限り本業に集中している方がお金になるだろう。みんなが思っている以上に本の著者というのは儲からない。そもそも正直私はお金に興味がない。ギターやプログラミングがうまくなる方が1000倍以上嬉しい。

 だから、過去の執筆のモチベーションは何だったかというと、「自分が実際に体験して学んだことで、絶対にみんなに役にたつんちゃう?」ということをシェアすることだった。実際に著者になって、技術者の中でという狭いくくりだがベストセラーを書いたこともあるが、自分にとって良かったことはコミュニティに行ったときに「オブ脳を書いた牛尾さん」と認識される効果ぐらいだった。

そもそも最近俺本あんまり読んでいない

 もっと言うならば、私自身が最近本を読まなくなった。技術を学びたいなら先に紹介したようなオンラインのビデオのコースとかめっちゃわかりやすいし、プログラミング練習するなら、LeetCode とかのサービスもある。例えばC# や、Azure を勉強したかったらマイクロソフトの公式サイトが超絶充実しているうえに丁寧なラーニングコースもある。しかも何が良いって常に情報が最新でアップデートできる。

learn.microsoft.com

 だから正直本を読む機会は相当に減っている。本はこうはいかない。こういう風にすぐにアップデートされる技術やリファレンスには向いていないし、本を常に最新に保つなど一人の人間ができることでもないだろう。

 本を読むにしても物理本はかさんですぐに本棚がいっぱいになるし重い。Kindle は、重くならないし、サーチもできるし、ブックマークも便利。大きなディスプレイで見ると老眼にも優しいし、最高だ。正直私は本はオールドファッションのメディアというイメージがあった。本屋さんの数もすくなくなってるように思う。

依頼を断らなかった理由

 結局私は依頼を断らなかった。それには理由が二つある。ブログは本にするために書いているわけではない。ただ、マイクロソフトで働いて、米国に移住してガチの世界一流のエンジニアと働ける幸せな環境で、私自身がものすごくびっくりしたり、衝撃を受けたことが沢山あるからだ。

 だから「自分が実際に体験して学んだことが、絶対にみんなに物凄く役にたつんちゃう?」というモチベーションでブログを書いていた。だから私のブログは有料にしたことがないが、このモチベーションで自分がラッキーにも得られた知識や経験を「おすそ分け」して貢献している感じだからだ。この辺りはオープンソースや技術コミュニティで育ったのでそういう意識があるかもしれない。そして、もう一つは自分自身が「本はオールドファッション」と思いつつも何か割り切れないことがあったからだ。

一行でも読むところがあったら

 自分の親せきで「茂木家」というファミリーがいる。彼らにはとてもお世話になって、その茂木のおじさんは本人も最高に魅力的な人で、子供を東大に無理なく合格させて、国際弁護士を2人も出している。他の人もみんないい人でめっちゃくちゃ賢くて、あんまり賢くない自分からは羨望の一家だった。もう亡くなった茂木のおじさんは私に言ったことがある。

つよしくんよ。本はな、一行でも読むところがあったら躊躇なく買うんだよ。

 それ以来、私は茂木のおじさんの言う通りのことを実行して、確かに積読とかもあるけど、きっとそのおかげもあって、今ここに立てている。だから自分のパッションに加えて、自分がお世話になってきた「本」に対する愛情が自分を後押しして依頼を受けることにした。学生時代に自分がどんなにダメで、周りの人にバカにされている時も、茂木のおじさんだけは自分に「つよしくんは優秀や」って言い続けてくれた。自己肯定感がめっちゃ低かった自分が当時がんばれたのはこの言葉のおかげだったから。そんなことを思い出した。

本の中の人を体験する

 さて、受けてみると本づくりの作業は興味深いものだった。過去の著作と違って、今回は「ビジネス書」なのだ。(従来の書作は基本的に技術書の出版社さんだった)だから、自分も体験したことのないことを沢山体験した。まずは編集の山本さんの編集力と構成力だ。本は私のブログをベースにしたもの、新作、そしてそれらを整理して最新の経験・知識をもとにアップデートしている。

 ただ、私はADHDなので、整理力は全くないし、そもそも大阪弁しかしゃべれない。だけど、山本さんは魔法のようにすべての情報を整理して、自分の文書を「原作:牛尾」と言っていいぐらいプロフェッショナルな文章にしてくれたし、内容のピックアップや構成も自分やったら絶対できへんレベルにしてくれた。ほんまプロもの凄い国語力。

 誰かはしらないけど校閲さんも凄かった。ファクトチェックや言い回しのわかりにくいところとか全部見つけてこうしたらいいというアドバイスしたり、重複をのぞいたり、自分ですら認識していないこと(例えば私が何年にアメリカに渡った時に自分は何歳だったか)そんなんわしもあんまりはっきり認識してないことを全部見つけてくれて、仕上がった本を読んだら、プロクオリティの仕上がりになっていた。

表紙のデザインもめっちゃええ感じやし、イラストも自分のあいまーーーーいな落書きのようなものをすっごくかっこいいものにしてくれた。

 だから、みんな作者がすごいと思うかも知らんけどちゃうで。あれは全部私の体験したこと、考えたことではあるけど、漫画でいうと「原作:牛尾 作画:山本 校正:校閲さん イラスト:docco さん デザイン:古屋さん」みたいなチームでできた作品やで。

さらなる体験

 さらにおもろかった体験としては本の帯がある。自分は単なるサラリーマンなので、有名人とのコネクションなどあろうはずもない。自分が身近に知っている有名人のMaxはたぶん澤円さんだろう。山本さんは私に「帯で推してもらえる人見つけてきました~」と言われて誰がこんな誰もしらんやつ推してくれるねん?と思ったら落合陽一さんと、楠木建さんだった。もちろん私は面識など全くない。もうなんで推してくれたのか全くわからなかった。だって、こんな誰もしらんやつ推しても彼らの得になるとはとても思えないから。

 しかも本読むとなると、ちょっとだけでもかなり時間を使ってしまうはずで。それはたぶん忙しい有名な方にとってはおそらく金よりも大切なものだと思う。だから、山本さんに聞いた。そしたら「本の業界のために新しい著者のことを応援してくれる方も多いみたいですよ」とのことだった。この件に関してはなんと楠木さんが次のように回答してくれた。

こんなんめっちゃ恐縮やけど、マジでめっちゃええ人としか言いようがない。

令和の時代に本を読むことの価値

 こんな体験をして、今の時代に本を読む価値をも一度考え直してみた。本は明らかにスピードではWebやブログに劣るし、わかりやすさというものでも動画に負けるかもしれない。でも、一つ物凄くすぐれていることに気が付いた。それは次の要素だ。

  • 自分のスピードで読める。つまりゆっくり読める
  • まとまった情報をプロの手で整備された最高の読みやすさで読める
  • 他の人が何年もかけて経験したり獲得した知識を数時間~数日もしくは数か月で獲得できる

それぞれ説明してみよう

自分のスピードで読める

 本の価値は「スピード」でそもそも無いのだ。それは「スロー」だ。アメリカのクラウド開発の現場で働いていると面白いことに気が付く。みんな思ったより慎重でゆっくりでスローなのだ。日本から見たらアメリカは最新の技術の導入が早いイメージがあるかもしれないが、それを生み出している場所で勤務していても、実は「速い」感はまるでない。というか新しい技術が公開されたときに「とびつく」速度は日本の方が100倍速い感じだ。アメリカの場合は、思ったより時流に流されずに「着実に学んで、実際にやって、積み重ねる」ことを地道にちゃんとやるので、気が付いたら世界でも進んでいたというノリだ。そもそも物事をちゃんと理解するのは時間がかかるし、技術の習得も一朝一夕に10分で学べるものでもない。

 本はその点とてもよい。本の製作チームが手間暇かけて時間をかけて作ったもの自分のペースで読める。重要なことは表面的に「わかった気になること」ではなく、読者の人が本を読んで、それが「行動に反映」されたときに価値が出ると思う。動画はさっと物事をふわっとわかることには向いているが、本のように、「ここの意味どういうことやろ?」と気になったことを推敲したり、調べたり、読み返したり、いろいろ考えたりする暇がない。物事を身に着けるにはそういうのが必要で、だから、「スロー」であることが価値なのだと思う。

まとまった情報をプロクオリティで読める

 このブログもそうだけど、日本語や構成に関してはプロがやったものには到底及ばない。まとまったことを深く理解したいときに、本は最高だ。コンサルの時には新しい分野を学ぶときは、偏らないように4種類の同じトピックの本を読めなんてアドバイスもあって実際にやっていた。

 今は技術者だが、ブログや公式のドキュメントがどんなに充実していても、ものすごくイケてる技術者の人が書いた技術書は書いてある内容の濃度は最高なうえに、編集されてるからブログとかよりずっとずっと読みやすい。

 ついでに言うと、「紙」の本って Kindle ばっかり買っている今から久々に紙の本を買ってみると、そのユーザビリティの最高さに驚いている。ページをめくる感覚や手触り、本を集中して読みたいときは、ディスプレイよりやっぱ紙のほうが世間を離れられるし、集中もできる。たぶん将来は「紙」の本は贅沢品になるのではないだろうか。

他の人が何年もかけて経験したり獲得した知識を数時間~数日もしくは数か月で獲得できる

本は「スロー」であるが「獲得」できるものは強力だ。英語でブッククラブを主催しているNatsukoさんはこんなことをつぶやいていた。ほんまその通りやなぁ。

ちなみに、私が今季読んでよかったなー。思った本を適当に上げておく。どの本も自分のピンチを救ってくれて、実力をぐっと押し上げてくれた感覚がある。

www.amazon.co.jp

www.amazon.co.jp

技術者じゃない人のために、今年じゃないけど、スキップマネージャの Anirudhに進められて、日々自分の糧にしている Atomic Habit。そして休む意味を学べる Time off。

Amazon.co.jp: ジェームズ・クリアー式 複利で伸びる1つの習慣 eBook : ジェームズ・クリアー, 牛原眞弓: 本

Amazon | Time Off: A Practical Guide to Building Your Rest Ethic and Finding Success Without the Stress | Fitch, John, Frenzel, Max, Suzuki, Mariya | Management & Leadership

ちなみに、ビルゲイツは、毎年50冊ぐらいの本を読むらしい。毎年お勧めの本を紹介しているが、彼のように先見の明のある人で、最新のテクノロジーに触れている人でも「本」を学びのツールとして使っているのはやはりこれが学びの手段として優秀だからだろう。この記事もビルゲイツがどういう戦略で本を読んでいるか書いてあって勉強になる。

eab.com

この記事のポイントをかいつまむと、ビルゲイツは本を読むときに

  • ノートを取りながら読む。中身を振り返るのに有用だから
  • 本のすべてを読み終える。そうでないと、重要なポイントや作者の意図を誤解するから
  • 自分にやさしく。自分が心地よいペースで読む
  • 少なくとも1時間確保して読む
  • コンテキストを得る。本を読んだら理解のベースができる。全体のフレームワークを理解したら、いろんなところに適用できる。そしたら楽に細かいことが記憶できる

らしい。この読み方だと絶対紙の方が良さそう。

令和の時代に本を読む価値

こんな経験を積んで、今の自分は「もっと本を読まなあかんなぁ」という気分になっている。やっぱり本は勉強の最強ツールであるのに安いしほんま最高。茂木のおじさんに言われた通りやっぱり一行でも読むところがあったら買うポリシーで行こう。これはたぶんある意味チャンスだ。きっと多くの人は本を少しづつ読まなくなっているから、自分は読む Habit を身に着けて、それを積み重ねるときっと自分の目標である「自信をもってソフトウェアエンジニアと言える」レベルの自分にきっと近づけるから。

もしよかったら、チームで作ったわしの本も読んでみてな。よかったら紙で。

コロナ禍の最中にアメリカから日本に帰国しようとしたら高額すぎる勉強代を払う羽目になった話

私はアメリカのシアトル在住なのだが、同じシアトルに住んでいる友人が、先日帰国して帰ってきたらしくて、ちょっと前にその話を聞いていた。彼は嬉しそうにこういった

アメリカと比べると、日本は全然マシですよ。問題は、帰国時には、14日間公共交通機関が使えない、それは、経由便も含むんです。だけでどそれだけです。今はコロナで、WFHなので、一人暮らしの人は親元とかに帰っている人も多いみたいですし、それが今は良いみたいですよ。

f:id:simplearchitect:20201210160523j:plain

それはすごくわかる。私は、一人で過ごすのが苦にならないタイプなので、相当に孤独に強いはずだが、私は新しい職場に移る前から、コロナの自宅待機が始まったため、3月から12月までにリアルで会った人の数は5本の指以下だ。自宅には自分だけなので、普段話をすることもない。筋トレもできない。スーパー以外どこにも行けない。仕事は最高だけど、私生活はギター弾いている以外ストレス以外の何者でもない。

日本に一時帰国する事を画策する

そんな時に上記の話を聞いて、彼からも「日本にしばらく帰っちゃえばいいんじゃない?」と言われた。そうやなぁ。自分の仕事的には、12月は閑散期で、スケジュールを調整して、12月は日本で過ごせるように算段を立てた。

考えたプランは次の通り

  • 実家は大阪なので、関空に外国から直接来るルートを選択する。Expedia で調べると、唯一シアトルーハワイ・ホノルルー関空のルートがあったので、それを申し込んだ。600ドルぐらいだった。帰りは1月2日で、14日の拘束が終わっているので、普通に成田から帰れる。前の職場は度が多い職場だったので、がっつりマイルがあるのでそれを使ったので無料。

我ながらいい感じ!

f:id:simplearchitect:20201210155157j:plain

  • ハワイのコネクティングフライトは、20時間待ちなので、ハワイで1泊を過ごす
  • ハワイ州に他の州から入るときは、フライトの2−3日前に、COVID19 のテストを受けて、その結果が陰性でないと14日間ホテルなどで待機
  • 関空では多少足止めを食うらしいので、その後に、家族に車で迎えに来てもらう。

Expediaの予約が完了し、150 ドルかけて COVID19 テストを受けて、認定書を取得。仕事もメインマシンから、ラップトップに環境を移して準備は完璧。長年のADHDが消えたのだが、効果は絶大で、前日も、割り込みタスクが入ったにも関わらず、すべてが片付いており、なにも慌てることなく出発できた。唯一の心配だったUberはちゃんと営業している様子だった。

note.com

f:id:simplearchitect:20201210160044j:plain

ハワイの入州と滞在

シアトルから、ハワイへ到着して、ゲートに行くと、コロナ関連の検査があり、ハワイの場合は、事前にアプリに項目を入力して、QRコードを携帯に表示しておかないと行けない。それを表示して、コロナの陰性証明を見せるとすんなり空港から出ることができた。ちなみに空港の近くにとったホテルでも、そのアプリの提示を求められた。コロナの陰性証明がないと、14日間どこにもいけなくなる。

ホテルに滞在したのだが、正直いい経験ではなかった。ホテルのレストランも締まっており、近くのレストランもデリバリー中心。本当はハワイの美味しいものを味わおうと思っていたけど、エビフライとBBQみたいなものぐらいしか頼めなかった。無念。でもいい。ハワイはまた来たらいいし、今回は寝に来ただけだ。

経由地のハワイでフライトが消えた

翌朝も、ADHDを脱したせいか、いつもと違ってすべてがスムースで余裕がある。ADHD脱出最高!とか思いながら空港に向かう。たった5分で着いた。意気揚々と、ハワイアンエアラインに向かって、チェックインしようとすると、様子がおかしい。係員さんが寄ってきてくれて、自分のExpediaを見せると「今日関空へのフライトなんかあれへんで」と言われた。

f:id:simplearchitect:20201210160738p:plain

ん?

関空のフライトは来週の水曜ぐらいからやで」、え、ここにチケットあるねんけど、、、色々そのおばちゃんが調べてくれたのだが、おばちゃんはこういった。

おばちゃん「こういうオンラインブッキングってこれがあるのよね。」

私    「よくあるんすか?」

おばちゃん「しょっちゅうよ。」

マジッスカ、、、まぁ、Expediaが悪いねんから、彼らにいって、フライトを他社便に変更してもらえばいい。しかし、おばちゃん曰く「今日出るのは、ユナイテッドぐらいね。しかも、ユナイテッド’は、ロスに一旦行ってから、成田に行くの」、、、いや、成田はあかんねん、、、「じゃあ、シアトルに帰るっててもあるわ」。それ意味なくね、、、

イムリミット1時間の意思決定

ともかくExpediaに電話をかけて、便の変更とかできないか聞いてみる。待ち時間が長いので、その間自分で他の便を調べてみる。最初に今日の便を見ると、JALの便が 12:00 ぐらいにあって、700ドルぐらい。ただし成田。関空という選択は、来週まで存在しない様子。色々調べたが、関空に行く方法は、来週まで待つ以外に無い。私の現時点でのチョイスは

  • シアトルに帰る
  • ハワイで1週間滞在して関空で帰る
  • どれかの便で成田か羽田に帰り、帰ってからどうするか考える

シアトルに帰る、、、は虚しすぎる。一体今までの調整はなんなのだろう?ちなみに今を逃すと来年7月までWFHなので同じ状況だ。関空はよく考えると厳しい。なぜかというと、1週間以上ハワイに滞在すると、日本の14日の拘束期間が長引く。つまり、12月29日まで拘束、、、ってなんもできんやん。これは、もう一番下の、東京に帰って、あとは考える。しかチョイスがない。わしは経験に金払ってるねん!

f:id:simplearchitect:20201210160950p:plain

Expediaと話をしていると、3日後の便に変えることはできるかもしれない。到着は東京だが。それを検討してもらい、しばらく、電話待ちの音楽が流れている。それがとっても長かったのだが、ふと、さっきのおばちゃんと色々会話をしている時のことを思い出した。

「ハワイにいるんだったら、COVIDの試験どうするん?」

先ほどのように、ホテルを取るなら、COVIDのネガティブの証明書72時間以内に検査されたものが必要だ。ということは、今帰らないと、COVIDのテストをどこかで受ける(そして2−3日待つ)もしくは、14日間拘束されるということになる。ちなみに、今日帰るんだったらさっきの12:00 の JAL を取るしかない。そうなると、今は9時ぐらいなので、1時間ぐらいで決断を下す必要があるので、ゆっくり調査をしている暇などない。 f:id:simplearchitect:20201210162607p:plain 14日拘束されると、どんな不便があるかわからない。何しろホテルのレストランも締まってるのだ。三食全部Uber?きっついなぁ、、、他にも、14日間の制約はどんなことが起こるかもわからない。そうなると「今日帰る」の一択だ。Expediaを待ってる間に、気を変えて、ExpediaでJALを予約しに行った。自分の脳みそは、ドラマのシャーロックの如く高速に回転する

絶望の展開

2139 ドル

f:id:simplearchitect:20201210161839p:plain

え、、、さっきまで 700ドルやったやん、、、、なによこれ、、、え、でも 2-3 日待つのも相当リスキーや、、、やっぱ、シアトルに帰るしかないんやろか?チームのみんなが気前よく送り出してくれたのに、またあのシアトルの一人の部屋に戻るんだろうか?しかし、それが一番「安全」ではある。が、わしは一体何をしたんや?

 しばらく迷ったが、腹をくくった。もうエコノミー売り切れでビジネスしか空いてないんやな。今年はお金使ってないし、日本に帰って家族に会うという経験をするんや。腹をくくって予約をした。オペレータのおっちゃんには、詫びを入れて、キャンセルしてリファンドしてもらうことにした。来年買おうと思ってたテレキャスターを諦めたと思おう。

f:id:simplearchitect:20201210162218j:plain
激痛の自腹 Business Class

プライベートでビジネスなんて初めてやし、折角金ぶち込んだんやから、楽しむぞ!と思って、ビジネスクラスで、Wifiを接続。普段はやらないけど、今回は、フライトの間に、日本での滞在の場所を確定するのと、成田空港から、滞在場所に、公共交通機関を使わずに移動するという必要がある。

ありがたいことに、Facebookでそんなことを呟いたら、仕事でご一緒した方が、空いている家を貸してくれるのと、成田まで迎えに来てくださるという夢のようなオファーを出してくれた。めっちゃありがたい。めっちゃありがたいけど、このオプションを選ぶと、私は、14日の拘束期間が過ぎる21の週に東京で予定があり、大阪に帰れない、つまり、家族に会えない。14日間一人で東京で過ごす。ということになる。シアトルにいるのと大して変わらない、、、orz

f:id:simplearchitect:20201210163142j:plain
家族会議中

しばらくすると、家族からも連絡があった。色々ディスカッションしていくといいアイデアを聞いた。「あんたが、レンタカーを運転して大阪に帰ったらどうや?」おお、いいプランやな。私は財布をチェックした、、、無念。免許ないやん、、、そらアメリカと日本車道反対やから危ないから、日本で車に乗るつもりなかったので持ってこなかったのだ。財布の中には、ワシントン州の免許が輝くのみ、、、

詰んだ、光はないのか?

詰んだか、、、神様はわしに孤独になってほしいんやろか?

そしたら、妹がこんなことを言い出した。

うちが、車で成田までいって、成田から大阪に帰るというのもあるのはある

しかし、Lineの雰囲気を見ていると、どう考えてもやりたくない感が溢れていた。ただし、妹はマネーに弱いし、謝礼もないとかないわなと思って、

じゃあ、東京まで、新幹線から飛行機まで来て、帰りレンタルカーとかどうよ。もちろん交通費と謝礼は出す。

という話をした。紆余曲折を経て、なんと来てくれることになった。なんともありがたい話だ。

乗り捨ては安くない

しかし、話は終わらない。じゃあ、レンタカーを予約しといてというので、貧弱な飛行機のWifiで成田から借りられるレンタカーを調べる。乗り捨てという成田で借りて、大阪で返すというオプションが可能な感じだ。大抵レンタカーは1日1万ぐらいやからな。と思っていた。が、乗り捨ては違った。

10km につき 1000 円です。で、成田ー大阪は? 500km ぐらい、、、 orz

調べると、レンタカー代が6万ぐらい+高速代、ガソリン代、妹の交通費、謝礼、、、すでに20万以上ぶち込んでいるがそこに、さらに10万プラスかぁ、、、めっちゃ高いやん、、、、お金を払っていい体験が出来るなら苦じゃないけど、元々6万円だったものが得るものが何も変わらないままレイズされていく、、、 f:id:simplearchitect:20201210163548p:plain

やっぱ神様が孤独になれといってるんやろか、、、もう諦めた方がええんやろか、、、、

いや、東京で一人で滞在したら、友人は来てくれるかもしれないけど、いったい何のためにお金を払ったのだ。ビジネスに金ぶち込んだんや?ここは辛いけど、BETやと思って、その案にしようと決まった。妹は、予約しとってと言いつつ風呂に向かった。まだ、そもそも、レンタルが可能かもわからないのだ。レンタルが可能でなければこのプランは無に還る。

待て、俺にはレイズの権利が残ってるぜ

しばらくすると、妹が、LINEをしてきて「ちなみにレンタルは86130円らしい」え、、、6万ちゃうかったっけ、、、今残ってるのは、ミニバンのみらしくそうなったらしい、、、。もう自分の心境は、映画によくある落札のシーンの心境だ。この値段で落札できると思ったら、ライバルが、値段を釣り上げ、自分も値段を上げていくと、またライバルが、、、どっちが降りるか、、、

BET。OK。もう今回は金で解決してやる。なんぼかかるんか知らんけど勝負や。

関空から、成田の飛行機ないわ。

レイズ再び、、、

私は、「じゃあ新幹線+成田エクスプレスやな」。妹はいった「成田エクスプレス」止まってるらしいで。

ああ、詰んだ、やっぱ無理か、運命には逆らえんのか、ここまでぶち込んで。

あと妹が言った、「新幹線はわからんから、いくんやったらオカンも来てもらわなあかんで」 え、ということは、新幹線と、成田エクスプレス(的なもの)の値段倍っすか、、、、そもそも、成田エクスプレス動いてないし、、、どうやって、、、

「そう倍やで。」

f:id:simplearchitect:20201210163842p:plain

orz 、、、そしたら、他の案が生まれてきた。福岡にいる弟が成田まで来て、大阪までレンタカーをドライブするプラン。もちろん妹が来るより値段はアップするが、自分的には、気分は楽だった。なぜなら、なかなか大阪に帰ってこない弟が、数日でも大阪にいると母が喜ぶと思ったので、その経験に金を払うならそっちの方がいいと思った。彼もエンジニアなので、WFHは普通にやれるはずだ。

自腹合計の算出

結局親切にも、弟が来てくれることになった。結局この旅で追加でかかった費用は

ビジネスクラス 2163 ドル ・弟が福岡から、成田へのフライト ・レンタカー 86130 円 プラス ガソリン代、高速代 ・弟が大阪から福岡に帰る費用 ・家族が調査に使った工数

プラスになった。ざっくりうと、元々6万円ぐらいだったものが、35万ぐらいになった感じだろうか、、、ビジネスクラスの時点で、テレキャスター代ぐらいだったのが、Surface Book の一番高いのぐらいの値段だ。でも、自分は経験をとった。もう8ヶ月ぐらい、ガチで一人で過ごしているのだ。今回みたいなクッソ失敗話も、いいネタになるぐらいに、日本の滞在を楽しもう。

www.amazon.co.jp

www.microsoft.com

教訓

これから、アメリカに帰る人への教訓。みなさんが私のような間抜けなミスをしませんように

  • Expediaなどで、ブックングをしたら完了と思わない方が良い。私のケースだと、数日後に、関空へのフライトがキャンセルになったメールが届いてたようだ。Expediaのアプリを入れていたのだが、特に通知もなく、完全に見過ごしていた。
  • COVID19 の制約下では、完璧に見えるプランを立てていても、一つが欠けると色々なものが瓦解して、代えが効かない。次のフライトにするかとか、気楽にはいかない。
  • 金で解決していくと、どんどん雪だるま式に増えていく。
  • 東京以外の人は、万が一関空がダメになったケースを想定して、日本の免許を持ってくるのが良い。自分でレンタカーを運転する分にはOK。レンタカーは予約必須。飛行機でWifiを契約して家族に予約してもらう。
  • 避けるのは難しいかもしれないが、コネクティングフライトはこの状況下ではリスクが高いかもしれない。経由地で予定が変更になった場合、COVID19の制約でよりがんじがらめの状況になりかねない。

ちなみに、ホテルに泊まるをチョイスすると、10万以上のコースなので、レンタカーコースとそんなに変わらないようだ。東京在住以外の人のCOVID19帰国は計画が破綻した時のダメージがで大きいが、初めから計画しておけばなんとかなるかもしれない。幸せな帰国を!

www.tokutenryoko.com

皆さんの参考に少しでもなれば幸いです。

アジャイルの反対はウォータフォールでは無いんじゃない?という話

先日ふとSNSを眺めていると、「アジャイル」と「ウォータフォール」はあうあわないがあるので、使い分けるのが吉的な意見を見てなんだかもやっとした気分になった。 正直アメリカに来てから「ウォータフォール」を見たことが無い。確かに日本にいたときは使われていた。最近はさすがに「アジャイル」がだんだん主流になっていく流れも見える気がするが、 アジャイルが「主流」という感じすらしっくりこない。なんでだろう?アメリカでもアジャイルは「主流」ではない。 f:id:simplearchitect:20201116123518p:plain

日本にいたときの個人的な開発方法論のイメージ

日本に居たときは、実際にウォータフォールが沢山あった。ただし、自分はソフトウェア開発には「ウォータフォール」が効率が良いとは一切感じられなかったので、そのことを書いたら結構炎上した。

simplearchitect.hatenablog.com

日本に居る時のイメージは、自分的にはこんなイメージだった。ウォータフォールと、アジャイルという軸があって、アジャイルが100%合わないものもあるけど、基本的にアジャイルのスタイルの方がソフトウェア開発にあっていて、プラクティスが合わない場合は工夫するけど、ウォータフォールは役に立たないというイメージ。でも実際には現場にはウォータフォールのプロジェクトはある。

f:id:simplearchitect:20201116112609p:plain
アジャイルとウォータフォール

自分が特にいまいちだと思ったのは、このプロセスのイメージ。今のソフトウェアスタックで、ドキュメントだけで設計とかはっきり言ってありえない。危険すぎる。昨日動いていた昨日が、何もコード変えなくても動かなくなってしまうこともあり得るのがクラウド時代のソフトウェアだ。(とはいえ、そこには必ずロジカルな原因が存在するが)それぐらい見通しが難しいものをコードに触れず設計できるとかは絶対にありえないと思う。これは実際にコードを書いている人ならみんなそう思うレベルのことだと思う。

f:id:simplearchitect:20201116113240p:plain
ウォータフォールのイメージ

アメリカに来てからの開発方法論のイメージ

実際にアメリカに来てから、世界規模のクラウドのプロダクトチームのデベロッパとして仕事をしている。私はこっちに来るまではアメリカは技術レベルが高いし、アジャイルカンファレンスでは、日本のカンファレンスより圧倒的に進んでる発表がなされているので、ほとんどの会社が「アジャイル」なんじゃないかと思ったが、そうではなかった。ただし、ウォータフォールでやっているチームは見たことが無い。じゃあ、開発方法論はどういうイメージかというとこんな感じ。 ウォーターフォールとか、アジャイルとか、乗っかれる枠組みがあって、それに従うというより、自分たちの課題があって、その課題の解決のためにどうしよう?そんな時に、参照できるアイデアが沢山あって、それが「アジャイル」だったり「ソフトウェアエンジニアリングやパターン」だったり、「研究論文」だったり、「事例やベストプラクティス」だったりする。だから先進的なプロダクトを開発しているチームでも、アジャイルラクティス的観点でみると改善の余地が沢山あったりもする。

f:id:simplearchitect:20201116114925p:plain

だから、そもそもの出発点が、「自分のチームの課題」があって、その解決策を探っているのであって型があるわけではない感じ。だから、開発のやり方なんてものは、しょっちゅう変わっていくというイメージ。ただ、「ウォータフォール」はもはや誰も参照してないようなイメージ。自動車が発達した後の「馬車」みたいな感じ。

アジャイルの対極にあるものとは?

アジャイルは 2000年当時はやっていた重厚長大なプロセスのアンチテーゼ的なところがあったが、実際のところ現在のソフトウェア開発によくフィットしたプラクティスが多い。ただし、考え方が合わないこともある。それは、例えば失敗できないものだったり、フィードバックサイクルが長いものだったり、多くのシステムとの連携があるものだったりする。私がやっている例でいうと、例えばライブラリや、Extension のリリースはアジャイルがピッタリ。もうゴリゴリにアジャイルのプラクティスが効きまくる。だから、フルアジャイルみたいな状態で開発する。 f:id:simplearchitect:20201116122233p:plain

アジャイルが合わないものとしては、例えば、プラットフォームのインフラを制御するコードのデプロイみたいなものがある。これはリリースサイクルが1か月以上かかることもざらで、失敗したときの影響度はとんでもない。ライブラリや、extension なら、あるバージョンがバグがあっても、古いバージョンに固定すればいいだけだし、修正もPushしたら終了だ。しかし、プラットフォームのインフラを制御するコードとなると本番でのテストすら難しく、テストのためのインフラをデプロイするのすら大変であり、時間もかかる。かかわっているチームが多ければ、こっちがインターフェイスでミスをすれば、その修正のサイクルが長くなる。だから、失敗したらリリースが、2か月先とかになりかねないので、慎重にテストしたり、しっかりテストケースを作ったりコードを書いたり設計を何度も行き来して見直したりする。検証するべきものが見えたら、それを自動化したりする。

Subject Matter Expert

クラウドプラットフォームのような複雑で、デプロイを失敗したらとてつもなく多くの人に影響するけど、実際の本番では試せないようなソフトウェアの場合、つまり、アジャイルが合わないものの場合、今の我々がどういう解決方法をとっているか?というと、名前を付けるとすると「SubjectMatterExpert」モデルといえるかもしれない。実際にわれわれはその問題を解決するために様々なプラクティスを使う。結局我々が知りたいのはデプロイの前に「ちゃんと動くと思われるアプリケーション」を作ることだ。「完全に動く」と保証は残念ながらできない。どんなに慎重になったとしても。しかし、そこに極限までに近づけるように努力をする。

  • カナリアリリース
  • コード、要求仕様、デザイン、テストを行ったり来たりして、設計を確実にする
  • 本番に最も近いインフラ自体をデプロイしてテストをする
  • 自動化されたテストで検証する
  • ソフトウェアエンジニアリングや、パターン、ベストプラクティスなどを参照する

あと、一つ、我々がよく使う手として、「SubjectMatterExpert」という考え方がある。クラウドの中身をすべて把握している人間はおそらくいない。複雑すぎるのだ。きっと皆さんのコードベースでも正直そうだろう。だから、自分が開発したコードを中心に、「それについて一番知っている人」を「SubjectMatterExpert」と呼ぶ。

f:id:simplearchitect:20201116122942p:plain

だから、ソフトウェアの設計や実装を確実なものにするために、「SubjectMatterExpert」とディスカッションをする。例えば「Linux Consumption Plan のインフラ」のエキスパートに、自分が、考えている設計やコードをシェアしてディスカッションする。デベロッパ自体がそれを自分きっかけで行う。特に早い段階で。そうしたら、いろんな落とし穴を避けることが出来る。すごくダイナミックなコミュニケーションなので、「誰が、どのことを知っているか?」というのが重要で、それが開発のスピードと確実性を増す。自分が「すべてを把握しようとしない」と思うことも結構重要だと思う。そうでないと、何かのことについてディープになり、他者に貢献ができないからだ。

小さな最初の一歩

日本の開発現場のカルチャー的にいきなりは難しいかもしれないが、本当に世界に通用するアプリケーションを作るためには、枠組みに乗っかるのではなく、初めの一歩として「自分のチームの課題」が何であり、「どうやって解決するか?」という観点でやっていることを見直すのはどうだろうか?結局のところ「自分で考える」しかない世界でだから、ソフトウェアエンジニアの給料は高いのだ。すべての過去のアイデアはリファレンスでしかない。もちろん学ぶ価値はとてもある。そして、開発のやり方は頻繁に変えてもいいもので、今までのやり方を踏襲するほうがよっぽど危険だ。f:id:simplearchitect:20201116123235p:plain アメリカに来てから、ソフトウェアの開発だけではなく、ソフトウェアの仕組み、ビジネスプロセスが頻繁に変わるのを何回も見てきた。日本に居る時は「現場が反対する」とかいってなかなかそういうものは変えずらかったが、こちらだと、しょっちゅう変わるし、かわるものなので、「前と違う」とか誰も言わない。新しいのがきたらそれに慣れるだけだし、「前と同じインターフェイスにしてほしい」とかいうのはそういう変化に対応できないということなので、ファイアーされても仕方がない。文化的な違いがあるが、日本で本当にデジタルトランスフォーメーションをガンガンに進めたいのなら、そういうところから変えていかないとうまくいかない気がするし、実際にそういう会社も日本で増えている気がするので、私が日本に帰るときにはそういう職場が沢山あるといいなと思う。そして、そっちの方がきっと、ずっとエキサイティングだし、会社にとってもいいんじゃないかな?

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

職場が変わって、前の職場と比べるとよりインターナショナルになりました。今はアメリカ人の人はいてなくて、インド、メキシコ、ロシア、中国、エジプト、ブラジルかなりインターナショナルです。 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

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

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