米国から一時帰国して「老害」がなくなるといいなと思った話
米国に移住して一年が経過した。正直なところ日本のほうがいいところはめっちゃある。特に生活面は、日本はホンマに素晴らしいと実感している。ただ「職場環境」は米国に圧倒的に負けていると思う。たとえ英語のハンデを背負ったとしてもこちらの方が圧倒的に快適だ。日本に一時帰国して感じた違和感とその分析、対処策について考えてみた。
日本で感じた「違和感」
日本を出た１年前と比べると、働き方改革の成果か、多くの人が日本の職場環境に疑問を抱くようになっていてそれはとても素晴らしいことだと思う。ただ、一方でインターネット上の議論を読んでいると、今まで圧倒的な「権力」を持っており、ある意味表面上は「尊敬の対象」だった「年齢の高い人」が「老害」や「昭和」などとバッシングされているのを見て非常に違和感を感じた。私も来年早々５０だし、昭和だし、日本に帰ってきたら年齢で就職できないから自分で会社やるしかないかなとかぼんやり思っていたことも思い出した。
米国の職場環境と「年齢」
私は、米マイクロソフトのHQで勤務をしているが、米国では、職場において年齢で区別されるというのが全くない。白髪のおじいちゃんから、インターンの人までほぼ同じ扱いだ。上下とか無い。実際に働いてみるとこれがホンマに心地よい。誰かが年上とか、年下とかも気にしたこともない。年上の人が偉そうに接することもないし、新人やインターンの人が過度に「できない」とみなされることなく、同じように扱われる。つまり、「それぞれの職場に必要なスキル」とのパッション含むマッチングとそのレベルが重要になる。例えば DevOps チームに所属しているなら、DevOpsの知識や技術的実践力、それに関するプロジェクトの遂行力、コラボレーション、それを通じたインパクトなどが評価の対象になり、レベル別にどういうことが出来たらいいか明確に定義されているのでわかりやすい。著名で、実力がめちゃめちゃあっても、DevOpsに関係ない技術にだったら、採用されない。
年齢が高い人の扱いの比較
日本だと、年齢が高いと仕事で成果がでているか否かにかかわらず、給料も高くなりがちで、ポジションも高くなりがちになる。「偉い人」もこの年齢層の人が多い。一方ある程度年を取ると、高いポジションにいない限り相当転職とかは困難になる。例え能力があっても敬遠されがちであり、実際年齢が高くなると、いろんな言い訳をして、年齢を理由にまったく勉強しなくなる人も多いと思う。また、年齢を言い訳にいろんなことを「それは無理」と自分であきらめてしまっている傾向が多いように感じる。
一方、米国だと、白髪のおじいちゃんのような感じの人でも、能力があればガンガンにプログラマをやってたりする。給料を上げたければ技術力＋マネジメントに進むほうが有利だけど、そうでない選択をする人も多い。（少なくとも現場レベルでは、マネジメントのみというのは無い感じ）。年齢が高かろうが、低かろうが、定義されたJOBが遂行できるか？というのが問題なので、年を取っている人でも勉強するのは当然で、自分が働きたいから、自分で自ら勉強やスキルアップの機会を求めている。ちなみに、今回ブログ用にお金を払っている画像サイトで検索したら、「シニア」で検索すると介護みたいなイメージばかりで、白髪の人がバリバリ働いている日本人の画像をさがすことができなかった。
ただし、私の記憶が正しければ、ある統計によると、年収が一番高いレンジは４０代ぐらいになって、年齢が行くと低下する傾向にある。やはり老いと経験は成果に関係すると思うが、あくまでそれは人の努力次第であり、面接で年齢が聞かれることもない。それは自然なものと自分は感じる。少なくとも私の職場では、年齢を何かの言い訳にする人を見たことがない。ちなみに、人を「叱る」ような人も見たこともない。あったら多分パワハラでクビだろう。マネジメントは、いかに人をいうことを聞かせるか？ではなく、いかにチームで目的を達成しつつ、各メンバーが個人がハッピーになるかが気にされる。
年齢が若い人の扱いの比較
日本だと、新人や、インターンというのは基本仕事ができないものとして扱われる。ものを知らないという前提で、たとえマスターを出ていたとしても、電話とりとかそういう仕事から始まって簡単な仕事ばかりから始まる。まわりも３年ぐらいは役に立たないものと考えており、期待もしない。ただ、教育制度が充実しているので、ゼロから教えてもらえる。だから大学にはある意味あまり期待していない。
米国だと、新人や、インターンでも同じ扱いになる。ただ、自然と、クリアできるJOBディスクリプションが高くならないので、一般的にそんなにもらえないが、IT企業だと、大学でコンピュータサイエンスを学んでその辺は出来ることが前提となっているし、大学で学んで実践してきたことがとても重要になる。だから、新人でもいきなり活躍の場があり、実際活躍する人も多い。先輩に丁寧に教えてもらえるという感覚もないので、同じく同僚のようにわからないことは聞いてくるし、こちらもサポートするという感覚。ただ、わからないことがベテランの人より多いという感じ。
心地よい「実力」の世界
このような感じで、年齢のバイアスのない世界ではいろんなことがうまく回っているように感じる。年をとっても実力さえあれば働けるし、大学を出たてでも活躍が期待されるので、大学でコンピュータサイエンスをしっかり学んで実践してくる。つまり、どんな年齢層の人でも「実力勝負」だ。だからみんな言われなくても努力するし、いかに上手くキャリアを積めるかを考える。指示待ちの人とかは存在しない。それは得な選択肢ではないから。実力勝負というと、シビアな感じがあるが、実際にはそうでもない。明確なJOBディスクリプションがあって、それをクリアするか否かだけなので、明確だし、それは「ストレッチ目標」ではなく「普通にやればクリアできる」程度の目標で余裕もあるので、自由度も十分ある。この背景にはキリスト教のバックグラウンドも関係あるかもしれない。キリスト教では、偉い人は存在せず、唯一存在するとすると、ジーザスとかGODなので、それ以外は「人」なので偉い人もくそもない。
どうしたらいいだろうか？
このまま働き方改革が進んでいくと、多かれ少なかれ同じような状況になると考えられる。だから、そうなってからではなく、今からそっちの世界にターゲットを絞ってキャリアを積んでおくといいかもしれない。今の日本だとまだまだ「政治」や、「偉い人」が存在するけど、一旦それは忘れて純粋に「実力」をつけるようなキャリアアップを目指しておくのはどうだろうか？もし、それが耐えられなさそうだと、外資系だと日本でもそんな感じなので英語を勉強して、そっちに移行してしまうのもいいかもしれない。日本の外資系にいるとよくわかるのだが、「実力があり、英語も出来る人」というのは本当に限られるレアキャラになるので、ちゃんとITの場合だったら技術を学んで実践して、英語も頑張っておくと、給料もあがるし、実力を伸ばしやすい環境にもなるので一石二鳥だろう。日本の外資系でビジネス英語に慣れると、海外で就職するというステップも踏みやすくなる。
年齢が高いから、大学を出たばかりだから、と言い訳するのは簡単だ。無理をする必要はないけど、一歩一歩自分なりに積み重ねたら、どんな年齢の人でも継続して学習しつづけ「実力」をつけるもしくはキープすることは可能で、そういう習慣がこのような世界が来た時にとても有効だと感じる。そしてそれが最も安全なことじゃないだろうか？ 米国で働いていると、年取ったから記憶力が、新しいものは難しい、、、とかはホント単なるバイアスが大きいのではないかと感じた。みんな余裕でキャッチアップしていく。多分単純にやっているから。 出世の概念のような、今の日本での「成功」をターゲットにしていたら、そうなったときにつらいかもしれない。実際自分も米国に移住して、自分の「日本での成功と実力」と思われていたものが全く役に立たない現状に直面している。その状況を早く知れてラッキーとは思っているが、少しづつどうしたらいいか研究している最中だ。
日本に一時帰国して思ったこと
日本で頑張って働いてきた人が突然「老害」といわれるのはホンマつらいやろなと思った。年とっただけやのに。それよりも、誰も年齢を気にしない世界は本当に快適だったので、そのことをシェアしてみたいと思いブログを久々に書いてみた。人を怒鳴りつけるようなパワハラがまかり通ったりしてやってられん！って思うとは思いますが、そういう価値観の中で育った人の努力や成果を否定するのはなんか違う気がしました。今は過渡期で、そこから徐々に「実力」のみで評価されて、どんな年齢の人でも楽しく働ける日本になったら本当に素晴らしいなと思いました。例えば、今そのパワハラをしている人でも、たぶん米国で、日本人が居ない環境で働いたら、考えは絶対自然と変わるとおもうのです。パワハラしたら首ですし、JOBディスクリプションが達成できないとファイアで、技術力が求められるのできっと真面目な日本人は頑張って勉強すると思います。言い訳してもファイアされるだけですから。日本だとそうはいかないので流れはゆっくりになると思いますが、いずれそうなると思います。そうなったときに全ての年齢の人も楽しく働けるようになったら最高だなぁ。自分が日本に戻る頃にはそうなっていたらいいな。
勉強したり、留学したりすればするほど、英語のレベルが落ちている現象を考察してみた
私は、現在米国でエンジニアをやっていて、もうそろそろ５ヶ月目に突入している。私の部門は、エンジニアでもお客様のところにいく部門なので、こちらのお客さんと会話をしたり、チームで開発することも多いけど、特にコミュニケーションで困ってはいない。もちろんもっとリスニングが良くなれば良いのになぁとは思うけど、業務に支障が出るほどではない。どっちかというともっとリーディングのスピードを爆上げしたいのが今の悩みだ。
英語の実力が低下し続けているのはなぜ？
しかし、ふと思い起こしてみると、私の英語のレベルは下がり続けている。しかも勉強すればするほど。自分の体感としては、昔に比べると総合的な英語力は上がっているはずで、知っているフレーズも増えたし、リスニングの理解力も向上している。私の英語の勉強は、本格的に始めたのは、おっさんになってからで、自分で英語を独学で勉強した後、３週間、３ヶ月とそれぞれ２回ロンドンに短期留学して、その後外資系企業に就職してインターナショナルチームに配属されたので、英語ざんまいの環境になって、３年後に、USに移籍という感じのキャリアだ。語学学校に入学すると、最初にプレースメントテストというのがあって、レベルの判定があって、その人の実力にあったクラスに配属される。その結果が実に不思議な感じだ。
私が独学で英語を勉強して、生まれて初めて海外に３週間留学した時に受けたプレースメントテストの結果は、Upper Intermediate だった。ちなみにインタビューでの会話のレベルは、Advanced と言われていた。１年間英会話学校に通って勉強したのち、次の年に留学した時のプレースメントテストの結果は、Intermediateだった。当時もなんで？と思ったのだが、３ヶ月の間に、Intermediate -> Upper Intermediate -> Advanced のクラスで終了した。
さて、その後外資系の企業に入って英語漬けになって、USに移籍になった時に、リロケーションパッケージの一部で、オンラインの英会話学校のベネフィットがあったのだが、そのクラスのプレースメントテストの結果は、Pre-Intermediateだった。マジ、なんでやねん？って感じ。
自分の体感の英語力
自分が独学して最初に留学する前も、結構喋りはできていた。英語を日本語で理解しないとか、シャドーイングとか、発音練習とか色々やったけど、結構喋ることはできていた。ただし、表現はそんなに多くないし、英語の環境の経験がゼロなので、この時に今のレベルのところにぶち込まれたら対応できていたかはわからない。
自分の体感的に、大きく英語力が伸びたのは、３つのタイミングがあって、独学で勉強した時は、英語力の飛躍的な伸びを感じた（何しろ、全然英語ダメだったから）、その後、２回目の留学で３ヶ月英語漬けになったのも相当レベルアップした感があった。最後は、外資系企業に入って、同僚との会話が完全に英語になってから。最後のは、実力が伸びたというより、英語を使うのに慣れて、度胸がついたぐらいのものかもしれないが、ゴリゴリに実用になったので、ある意味レベルアップしたと言える。自分の体感的にはそうだ。
アメリカにきてからは成長していないのを感じる
その一方で、アメリカに住むようになってから、もちろん日常は全て英語なのだが、正直なところ、英語力が伸びた感じはまるでない。先日も日本から来た日本人の同僚が「牛尾さんの英語力は正直あまり変わりませんね」と言われて、自分も「うん。俺もそう思うねん」と答えた。本当に正直そう思うのだ。アメリカに住んで、英語を使いまくっても、特に実力は向上しない様子だ。使っているだけでは、度胸がつく程度で、何か実力アップに繋がることをしないと成長しないらしい。もちろんアメリカ人の友達もいるし、お家にお呼ばれとかもよくあるので、家から出てないとかではない。
謎を考察する
このテストのレベルが落ち続けている現象と、自分的にはレベルが向上しているというこのギャップは一体なんだろう？一つ思い当たるのは、勉強スタイルを変えたことだ。私は、最初の留学までは、日本語翻訳にたよらず、CDや映画をリスニング、ディクテーションしたのち、シャドーイングを自分の脳に刻まれるまで繰り返しやると、勝手に口が喋るようになるというスタイルでやっていた。本も日本語訳はせずGraded readersという本を少しづつレベルをあげながら多読していた。つまり、大量のデータをぶち込んで、本能と反射で英語を使うというスタイルだ。最初の留学の時は、先生にものすごく英語を褒められたし、聞き返されることもほぼほぼなかった。その後、英会話学校に行って、日本語で学ぶのは反対だけど、英語で学ぶなら文法を勉強するのもいいなぁとか、英会話が学校の教材はよくできているので、学んだフレーズがすぐ使えるし、ネイティブもたくさん使うので、効率がいいとも感じて、シャドーイングの頻度が極端に落ちて、愚直に「勉強」をしていた。おそらく、この勉強スタイルの違いが今回のギャップを生んでいると想定される。ではなぜ？
自分的な分析
先に書いているように自分的には、英語力は向上していると思う。リスニングとかは明らかに向上しているので、例えば今Upper Intermediateの教材を聞くと初見でもシャドーイングができて理解できる程度にはできる。多分最初の留学の時はそこまではできなかったと思う。フレーズの理解力も向上している。ただ、プレースメントテストをする人がわの方を見ているとどうだろう。私の分析では、私は昔より「ミス」をすることが増えたのだと思う。昔のやり方だと、私は、過去に聞いたフレーズを精々単語を入れ替える程度で、過去に聞いたことのあるフレーズで、私の口から出るフレーズが構成されていたはずだ。だから表現が多くなくても、ミスが極端に少なかったのだろう。何しろ、自分が無意識でも口から出るぐらい繰り返したフレーズなので間違えもしないし、頭で考えてもない。一方、文法とかのテストも、感で答えた当たる感じだった。なんとなく間違ってるやつは気持ち悪いので、選ばないみたいな感じだ。だから、そっちのテストもそこそこ良かったのだろう。
しかし、文法とかを勉強し始めたらどうなったか？というと、文法知識やフレーズに関しては、知識が大幅に増えているが、いざ口に出すと、そのフレーズを使おうとすると、シャドーイングしまくった訳ではないので、頭で考えて「作文」して喋ることになる。本能と反射ではない。だから、つい先日まで受けていた英会話のコースでも先生にいっぱい文法ミスを指摘されて、どうやって直したらいいと思うと言われたら、全て回答できる感じだった。知らない単語や表現もほぼほぼない感じだ。つまり、頭でわかってるけど、反射的に使えるほどこなれていないということなのだと思う。だから、プレースメントテストでは点数が落ちる一方ということだろう。
対策
あっているか、どうかわからないけど、自分的な分析の結果、一番最初の英語学習スタイルに戻すことにした。これからは、一切文法は勉強しない。全て、本能と反射で英語を使えるように鍛えていく。週２回程度の英会話では身につかない。毎日数時間をぶち込んで、徹底的に英語を体化していく作業が必要だろう。じゃあ、今までの努力はなんだったの？となりそうだが、多分今まで、英語を「勉強」した蓄積は、無駄ではなく、有効だと思う。問題は、「体化」のステップを怠っていたことだろう。具体的には、英語を音で理解して、反射的に理解して、喋れるよう、シャドーイングを死ぬほどやる、文法とかは考えない。（考えなくても喋れるようにする）リーディングも音読から再スタートで、文法は忘れて、体化に焦点を当てる。つまり、私が一番影響を受けている、英語は絶対勉強するな方式に戻すということだ。実際に、一番伸びを感じたのは独学した時なのだ。
今後の戦略
今後の戦略は、先に進みたいのは、グッと我慢して、まずは、Upper Intermediate の教材を使って、リスニング-> ディクテーション-> 英英辞書で意味調べ -> シャドーイングのプロセスを実施、その後-> Advanced -> Business English (Upper Intermediate)に進んでみる。 多分CDはこれぐらいやったら無敵になるだろう。昔やってた時はどのレベルでやればいいのかがわからなかったが、今は、自分が楽にできるレベルからスタートすることに決めた。インターネットで調べるとうまくいっている人は、無理なことはしていない。だから、ほぼほぼ意味がわかって、初見でもシャドーイングできるUpper Intermediate の教材だと、多分結構早くこのステップを終えられるだろう。Advanced は最初から最後まで通してないので知らない表現とかはありそうだけど、Upper Intermediateを復習したら相当にレベルアップしていると思う。その後に、チャレンジすると意外とすんなりいける気がする。最後のBusiness English は結構（勉強は）やったけど、これを飽きるほどシャドーイングして体化させると、仕事上の英語はほぼ苦労することはなくなりそう。その後、ガチの英語力に移行するために、映画で同じプロセスを繰り返して、最終的に、英語は絶対勉強するなで紹介されてるけどやったことがなかった、英字新聞のメソッドもやってみよう。
最後に
ちなみに、この分析は、ADHDな私なので、一般の人に当てはまるかは知らない。英語を勉強して実力をあげている人はたくさんいるので、私のケースはこうかもしれないという考察に過ぎないし、実際やってどうなるかもわからない。ただ、自分の感覚的には、これでいけるという確信に近いものがある。英語を勉強している時にはなかった感覚だ。たまに、こっちにいると、ネイティブからも、「例外的に英語ができる日本人」という人がたまーにいて話を聞くことができるのだが、そういう人にコツを聞くと、要領を得ないことが多い。「んー。特に勉強もしてないけどなぁ」とか、「楽しいから、会話の中で知らない表現があったら、５分後にはそれ使ってるわ」とか、我々からすると「なんでやねん」という感じなんだけど、才能ある人はそんな感じなのだろう。つまり、ある程度仕事で使えるレベルではなく、ネイティブに混じっても遜色ないレベルになるためには、「頭を使っている」状態は好ましくないのだろう。結果はわからない、ただ、今は、英語を使いまくれる環境にはいる。こうなったら、昔夢見ていたネイティブと遜色ないレベルというやつを目指してみよう。そしたら、仕事でも超絶アドバンテージになるはずだ。なぜならネイティブは少ないし、日本人は、ネイティブの国々の人の文化とは真逆にある文化なので、いろんな価値が出せるはずだ。
ちなみに、今は昔の方式に戻しているが、何時間でもやれるし、楽しい！この調子でガンガンやって試してみよう。ネイティブ並みになってやるぜ。そしたら、プログラミングとか、技術の勉強も超絶楽になるはずやわ。
アメリカで、ソフトウェアエンジニアの日本人がインパクトのある仕事をする方法
アメリカに移住してもうすぐ４ヶ月ぐらいになるけど、こちらに来てから面白いほど成果が出ていない。
最初の２ヵ月ぐらいはなんやかんやで仕事にならんやろうなと思っていたから、気にもしなかったが、そろそろ４ヵ月なので、流石に焦りを感じて来た。何一つ仕事が完了しない。日本で仕事をしていた時はこんなことは発生しなかった。こっちの方が一緒に働いている人が同じタイムゾーンだし、近いし、やりやすいはずなのに何故だろう？焦っていても何も改善しないので、直接仕事をしているクリスと、日本人エンジニアの先輩の河野さんに話を聞いてみた。自分の会社限定かもしれないけど、学んだことの記録と、もしかすると誰かの役にたつかもしれないから書いておこうと思う。
仕事が完了しない焦り
何だろう、この仕事の完了しないっぷりは。いくつか、終えたらインパクトがある仕事があるのだが、これがまた完了しない。一緒に働いているエンジニアの人はみんな超絶忙しい感じで、声をかけるのも気を使う感じ。だから、何かのブロッカーの質問があったとしたら、彼らにメールなり、メッセなり、PRのコメント欄に書いたりするのだけれど、全く反応がなかったりすることもしょっちゅうある。自分のPRのコードがイマイチだからダメなんだろうか？それとも単に忙しすぎてみる暇がない？そもそも反応がないのだからどうしようもない。
でも、その質問がクリアされないと前に進まないしどうしたらいいんだろう？いろんなことがそんな感じで止まってしまう。勝手に先に進める？しかし、大きな手戻りが発生する可能性が高い。しかも、日本と違って、仕事は勝手に降ってこない。自分でゲットするもののようだ。誰かがインストラクションしてくれたりするわけでもない。そんなものと思ってやってたけど、ここまで成果がでないと焦って来た。
インパクトが停滞する
そんな折、私が２ヵ月ぐらい使って分析して、インプリした大きめの機能追加があって、それがマージされると結構なインパクトだし、貢献と思うのだけど、それはまだだ。というか、レビューもしてもらっていない。アポとってデモした時は、結構好評だったように感じて、次はPRレビューすると言ってたのに、しばらくしてもするそぶりがないので、何度かメールを送ったり、PRにメンションしたりするけど、反応がない。どうしたらいいんだろう。しかも別のドキュメント系の仕事も、あるアーキテクチャのディスカッションのポイントが合意できないと、書いても意味ないので、自分には時間があるのに前に進めない。先ほどのPRも何か一つでも反応があり、不満な点があれば速攻で対応する準備があるのに無反応だから何もしようもない。どうしたらええのよ。こんなの日本ではありえない状態やわ。しかし、これ以上プッシュしたら流石にうざいだろう。もうどうしたらいいのかわからない。
とあるイケてるエンジニアのスムーズな仕事ぶり
そんな折、私よりよっぽど後にムッチャ難しい機能に着手しためっちゃイケてるエンジニアがいた。彼は、私たちの前で、初めて１週間ぐらいでさっと最初のデモを作り、毎週、更新しては、みんなに見せて来た。正直めっちゃカッコいい機能。次のリリースの目玉のような機能だ。そして、１ヵ月ちょっとぐらいで、着想からからのでっかいPRはマージされた。もの凄くスムーズだった。彼が超優秀というのもあるし、この機能だったらみんな夢中で、優先順位上がっているというのもあるけど、たった一人でめっちゃスムーズにインパクトを出した。なんて優秀な人なんやろ。
クリスにフィードバックを聞いてみる
多分自分の仕事の仕方に問題があると思ったので、仕事をしている相手のクリスに話を聞いてみることにした。自分の仕事の仕方に問題があるからフィードバックをくれないかと言って時間をもらった。意外なことに、私の仕事の仕方には問題がないというので、私は、反応がなくて困ってて、たとえ今無理でも、何時頃に時間取れるとかそんなことだけでもわかったらええのに、それすら難しい、これ以上ピングしたら日本人的には、失礼だと思ってしまうという話もした。すると彼は、それは多分みんな忙しくて、単に時間がなくて後回しになって忘れているだけやと言ってくれた。彼のアドバイスでは、メールでダメなら、メッセでピング、それでダメならこちらから会議を設定、それでダメなら直接乗り込んで、話をすると。なんやそれ、大阪のおばちゃんのような厚かましさやんけ、、、でもそれでええらしい。ただし、相手に尊敬を持って。そんなもんらしい。日本ではあんまし相手がたまにメール見落としてるとかあるけど、もう一回ピングしたら無視されるとかは普通無いからそれは凄い違いだ。クリスは、自分が相手であってもそうしてくれたら良いよって言ってくれた。
日本人の河野さんにも聞いてみる
たまたまクリスと同じビルに河野さんがいて、さっきちょっと話したので、「そうだ河野さんに聞いてみよう」と思い立って、少し時間をいただけませんか？とメッセをしたら程なくしたらカフェテリアのコーナーに来てくれた。私が、上記のような事に困っているというと河野さんはいくつも重要なアドバイスをくれた。河野さんはとても優秀な人で、私の会社でも製品的にも、技術的にも、チーム的にも中核の最高のチームでずっとサバイバルしている、つまりめっちゃ優秀な人なんだけど、これまためっちゃいい人で、日本でも凄くいい講演をされていて記事にもなっている。河野さんに聞いたら何かいいヒントが得られるんじゃ無いか？と思って藁にもすがる感じで聞いてみた。
日本人を捨てる事
全く意外な事に、河野さんも、今ぐらいの頃私と全く同じ問題で悩んでいたらしい。当時の彼の上司のトルコ人に河野さんが相談したら、以外にもトルコの文化は日本と似ていて、控えめな文化なので、「俺が、これやりました、見てみて！」みたいな事をしないらしい。そんな彼が、USに来てから、トルコ人である事を捨てて、アメリカ人のように振る舞うようにしたらしい。日本人の自分ならきっとやらないような、「俺これやった！見てみて」「俺これやらんといけ無いから、時間作って」みたいなことをガンガンにやるようになったらしい。河野さんもそれを聞いてそういう風にするようにされたらしい。ただし、それがちゃんと出来るには３ヵ月ぐらいかかったともお話されていたので、そんなに直ぐには日本人癖は抜けないのだろう。常時大阪のおばちゃんレベルの厚かましさになることから始めよう。
コミュニケーションとビジビリティ
河野さんに褒めてもらったのは、私が毎週プロダクトチームの定例に参加していること。これは、コミュニケーションの面でもいいことだけど、ビジビリティにも良いと教えてくれた。他の人に自分が何をやっているのかを見せないと、誰もそれに気づかない。だから、相手に自分が何をやってるのか見せるのが重要で、そしたら気づいてもらえる。スクラムのイベントとかも、ビジビリティをあげる効果があるという話もされていた。自分的にはコンサル時代から「価値を出したら、それを見える化しないと行けない」と言われていたのでその概念は直ぐに理解できたけど、純粋なソフトウェアエンジニアの世界でもそれは同じという事を教えてもらった。
周囲と比べず、周囲の人をリソースと考える
次に教えてもらったのが、周囲の人をリソースとして考えるという考え方。周りの人は物凄く優秀な人が多い。本当にスーパーマンのよう。しかも英語とか読んで理解するのも自分より何倍も早い。だから、正直自分はガチでダメやなとしょっちゅう思っていたけど、河野さんも最初は同じだったらしい。比較したら落ち込むだけだ。だから、昨日の自分と比較して、成長しているかだけを考えて、周りの人はリソースだと思って、わからないことは質問しまくる。
仕事は降ってこない。自分で作る
次の問題として、仕事が降ってこない問題がある。日本の場合は、マネージャとかいるので（こちらにもいるが）仕事は基本的に降ってくる場合が多い。自分は能動的に動くほうだが、それでも、基本的にミッションとかあって、達成することが明確であることが多い。ところが、こちらのソフトウエアエンジニアリングでは、自分のスコープぐらいは決まっているかもしれないけど、仕事は自分で作らないと無い。ゼロ。だから自分で動いて、なんか作ってみるとか、貢献してみるとかしないと行けない。だから自分が作っていいと思ったものは、どんどん周りの人に見せていく。もし、何人かが、あまり興味なかったとしても、さらに他の人にもデモしてみたりする。リンクや動画を送っただけではダメで、目の前で時間をもらって、俺これ作ったぐらいすると、誰かが興味を持ってくれるかもしれない。 そんな事をしていて、周囲にも聞きまくっているうちに得意分野が出来てきて、だんだん忙しくなっていくという感じのようだ。
マネージャは使うもの
日本にいるときはマネージャは管理したり、何か指示を出す人だけど、こちらでは、全くそんな事はない。河野さん曰く、すごく良い作戦としては、マネージャを使う事だと言っていた。私も感じているけど、こちらのマネージャはガチで優秀。技術もよく知っているし、困ったら本当に助けてくれる。だから、先頭にあったような、反応してくれない問題も、マネージャに相談すると、一緒に解決したり、自分がアプリを作ったらまずマネージャにデモすると、それを広めるのを助けてくれたりすると言った具合に、とても助けてくれる。だから、こちらではマネージャに「使われる」のではなく、マネージャは「使うもの」だとアドバイスをくれた
ものづくりを楽しむ
これはアドバイスではないのだが、最後に河野さんが言っていたのが、電子工作興味ありますか？楽しいですよ？と言われた。そういえば、実力をあげよう、あげようとばかり考えていて、技術を楽しんだり、自分でなんか作ったりとかそういう感覚って忘れていた。自分のツール作るの最高に楽しいし、面白いアプリ作るのも面白いな。楽しい事やってる方が人間上達するよね。そんな事を思い出しながら、河野さんに去年作ったStrikes をご紹介した。復活して継続開発しようかな！ラズパイも楽しそうだから買っててやってないので、そろそろ魂を吹き込んでみるかな。
最後に
あの河野さんでも自分と同じような事を感じていたのかとびっくりするのと同時に、物凄く適切なアドバイスをいただけた。ガチで世界中で使われまくっている、自分の会社の中核のサービスを開発をしている本物、本当に私が目指している本物のエンジニアが時間をくれてアドバイスをもらえた。今回のブログは誰のためでもなく、自分のためなんだけど、私や河野さんが感じたような事を感じている人のためにこちらでもシェアしてみる事にした。誰かのために役に立つと幸いです。
アメリカに住んで初めてわかった「最大級」の違い
昨年の年末にアメリカに移住して、今はシアトルの近くの Kirkland というところに住んでいる。大体三か月たって、いろんなことを体験した。移住した理由は単純で、コンピューターサイエンスの世界ではアメリカがどう考えても一番進んでいるので、そこで修行して通用するようになったら楽しいかなと思ったからだ。他にも他国の人を観察しているととても生産性が高い。特にアメリカの人は生産性が高い傾向が高い。なんでこんなにアメリカはコンピューターの世界が向いているのだろう？その一旦を感じた気がしたので久々にこのブログを書いてみることにした。
自分へのご褒美を買う
アメリカに移住すると、当然日本にいる友達とかと会えなくなる。私は一人でもさみしくない人だけど、さすがにこたえるだろうと思った。だから大好きなバンドをまたやろうと思った。ただ、こっちは正直レベル高いし、私はヴォーカリストだから、さらにハードルが高い（英語という意味で）。だから、移住した時に何か自分にご褒美を買おうと思っていた。最初はアメリカは家が広いだろうから、歌も、楽器もやりたい放題じゃないか？とおもったけど、アパートに住むと、そうでもないので、高い機材を買うより、思いっきり歌って、楽器を弾ける環境を作ることにした。ヴォーカルブースという一人用の防音室があるからこれを買おうと思い立った。これでがっつり練習しよう。ちなみにこんな感じのものだ。
ドキドキの銀行振り込み
と、ここまではいいのだが、実際に行動に移してみるとコテコテにトラブルに巻き込まれた。私の住んでいるのはアパートなので、そもそも入るかとても心配だった。だから、Vocal Booth の人にちゃんと分解されてくるか？とかの質問を投げたが、彼曰く「大丈夫、分解してくるからアパートも大丈夫。家用だし、Philips (プラスドライバーのこと) があれば簡単に組み立てられるよ。」その一言を聞いて注文した。高い買い物なのでドキドキだ。アメリカやし。
直接銀行口座に振り込むようになっていたけど、アメリカ人の友人がリサーチしたほうがいいと。だまされる可能性があるからとのことのようだ。しかも、振り込みをしようとした銀行のアプリも、「口座振り込みは詐欺に気を付けましょう」とか出てくる。ググったけど悪い評判ないし、ええい、やってしまえ！と振り込んだ。メールもちゃんと返してくれたが、ブースを作っているオレゴンでは、雪が降っていて交通がマヒしているようで、すぐに出荷できないといわれる。先の詐欺の件もあるので、ドキドキだ。数日間後、出荷したと連絡が入った。それと同時にメールで、注意書きを読んでおいてね。といわれた。人を二人用意してね、ドリルとかあったほうがいいかもね？クレートをトラックの上で開けておろすようにしてね。ドアは重いから、二人で運んでねと。なんやねんクレートとか、ドリルって？まー、何とかなるやろ。
日本の宅配の凄さ
こっちにいると、宅配の遅れみたいなのはしょっちゅうだし、適当だし、翌日配送とかありえない。昔は Amazonすげーって思っていたけど、あれ凄いの佐川とか、黒ネコだわ、、、とこちらでもAmazonを利用して実感した
。だから、今回も遅れとかはありがちかなーとおもったけど、今回のはなかなかディープだった。この荷物は受け取りの時に絶対に自宅にいとくようにとインストラクションがあったので、宅配予定（昼の１－６時のどこかで配送）の日は、自宅作業にした。その日の終わりになって電話がかかってきて、「ごめん、今日配送無理だわ」と電話がかかってきた。まーそんなこともあるだろう。次の日も自宅待機にして宅配をまっていたら、夕方にメールが入っていて、「おまえの電話番号つながらんから、配達無理やわ。連絡しとって」と。オペレーターさんに電話して、電話番号を伝えて次の日。あれ、まだこない。するとメールが入っていて「電話がつながらんから無理や。連絡して。と、いや、昨日伝えたし、、、」、と思いつつもまたオペレータさんに電話した。そこで衝撃の一言を聞くことになる。
フォークリフトを持っていますか？
オペレータさんに電話をすると、言われたことが、「Do you have a fork lift?」「えっ」、、、流石にそんなこと人生で言われたこと無い。どう考えてもわしの住所アパートやねんけど、、、彼女曰く、めっちゃ重い荷物があるから、フォークリフト無いと無理で、オプションとして、トラックの上で分解する方法もあると。そして、宅配で届く予定の荷物の詳細を見てかなり不安な気持ちになった。「920lbs」大体 480 kg 。何かが間違っている。そういえば、Vocal Booth のインストラクション意味が理解できなかったけど、今頃事態を把握した。これ、一般の家庭で買ったらあかんやつちゃうん、、、
キャンセルに備える
Vocal Booth はガチで欲しいものだったけど、こんなもの買ったら引っ越しの時どうするねんとか、そもそも入るのか？ということが頭をよぎった。これ買った俺がアホやったんちゃうか、、、別の用事のついでにアパートの事務所によって聞いてみた。ここのアパートの天井の高さはどれぐらいですか？と。すると、彼女はこう答えた。「そうねー。ようしらんけど、8-9 (inch) の間ぐらい」そして、VocalBoothのスペックを調べると、「8.8 inch」こんなん絶対無理やん！ということで、Vocal Booth に電話をした。キャンセルした時の、返金の手続きとかについて教えてもらうためだ。キャンセルをしようとしている自分に若干安堵する。お金は失うけど、ひどい目にあうことはないだろう。
自分だって英語で電話するのはつらいものがあるが、やるしかない。「高さが多分無理なので、キャンセルしたいんだけど、リファンドとかあるの？」と聞くと、彼は「そうか、残念だね。１０００ドルぐらいは負担になるけど、そんなひどい目には合わないし、リファンドするよ。単にコンテナを送り返すように指示をしたらいいよ。だけど、このVocalBoothは、何千台も出荷しているけど、一回たりとも高さが問題になったことがない。８インチあれば組みあがるよ。」彼の口調もだましているようには感じなかったので、素直に信じてみることにした。せっかくアメリカに来たのだからこうなったらやってみよう。「ドアが重いから、それだけは二人で持ってね。あとは、Phillipsがあれば、大丈夫。ドリルもなくても大丈夫だよ、３０分ぐらいでトラックの上でクレート（コンテナ）を分解して中身をとりだせるよ。」とのことだった。
友人を手配
同じ職場の友人が、手伝ってくれるというので、宅配会社に電話をして、なんとか、時間を狭めることに成功して、５－６時に来るらしい。友人が４：００頃こっちに向かってると電話をくれた。私が待っていると、トラックの運転手さんから電話かかってきて「ごめん、今日無理だわ」 orz 今まではともかく友達が向かってきてくれっるのに30分前にってなによ、、、、家に来てくれた友達に事情を話したら明日は家族旅行だから、昼までなら手伝えるとのこと。宅配会社と交渉して明日朝に持ってきてもらうことにした。
絶望
次の日は、９－１２時のスポットなので、友人には、トラックの運転手さんから連絡は要ったら連絡するわと言ってある。ところが、今回はいつもとは逆に突然電話がかかってきて「ついたから、どうすればいい？」とのトラックの運転手さんの電話だった。「へ？あ、了解」友人に、メッセージを送ったり、電話を掛けたりしたけどつながらない。どうするよ！もう一人手伝ってくれるといってくれた友人にもメッセするが反応がない。やるしかない。そして、トラックに向かった。オペレータさんにトラックの上で分解するようにするという話をしていたのだが（彼女からもそう提案があった）、実際に来たトラックの運転手さんは、時間ないから、さっさとおろすね、多分このツール使えばおろせるよ。と言われて私茫然。
「こんなクソ重いのどうしたらいいの？」と聞くと「あー、それ君のコンテナやから、君のビジネスだよ」と。ちなみに、運転手さんは意地悪そうではなくて、親切なかんじだけど、彼もどうしたらいいのかわからない様子。私の眼前には、ドカッとおかれた920 lbs のコンテナが。脳内イメージでは、プラスドライバーで簡単に組みあがる、分解パーツなので、IKEAの家具みたいなのをイメージしていたが、実物はこれだった。友人もいない、雨も降っている。よくわからんが、とにかく分解するしかない。中身抜いた後もこのコンテナどうやって処理したらいいかわからんけど、とりあえず開けようと、ドライバーを片手に開けてみる。
後悔
この巨大なコンテナと中に入っていた工場施設のようなパーツを見つめながら、「無理じゃね、、、」と心の中でつぶやく自分がいた。「やっぱ昨日の時点でキャンセルが一番正しかったなぁ。」で、これどうするよ、、、たった一人で、、、しばらくすると、友人二人が反応があって、わざわざ来てくれた。
Brent の一言
同僚であり、友人のブレントは、いろんなツールを貸してくれた。ドリルだとか、トンカチだとか、ノコギリだとか。彼は南アフリカから私と同じように来た超絶ナイスガイ。彼にも、もう一人の日本人の友人にも、こんなだから、入らなかったらキャンセルも考えてるんだという話をした。高さも多分無理だし。すると、Brentは、「メジャーで入るかどうかはかってみよう。折角君が楽しむために買ったんだから、入ると絶対いいよな」といって、メジャーで天井まではかってくれた。結果は 9.4 inch 。Brentは、「絶対入る。君が、このブースをエンジョイするのを楽しみにしてるよ」といって時間になったので、家族旅行に旅立った。家族旅行の前に仕事でもなんでもないようなこんなんを一生懸命手伝ってくれるなんてなんていい人なんだろう。ホンマ感謝しかない。
再び挫折
さて、２人で運べるといってたので、パーツを残りの友人と運んでいたが、２人でないと無理と言っていたドアが出てきた。友人が持ち上げようとすると、まったく持ち上がらない。私は筋トレをしているので、持ち上がるがかなりの重さ。そして、超でかい。これが自分の自宅の曲がりくねった玄関をちゃんと通過するんやろか？これは、２人では絶対無理という感じになって、自分のアパートの事務所にいって、手伝ってくれる人を探すことにした。自分の気持ちとしては、心の奥底で、誰かに「無理、だめ」って言ってほしかったような気がする。事務所の人だと、「こんな重いものを家に上げたらだめですよ」とかいう反応も想定しながら声をかけてみた。すると気楽にてつだってくれることになった。ローリーという道具までもってきてくれて、３人がかりで運ぼうとしたが、デカすぎるのと、重すぎるので、すぐにアパートの壁に大穴を開けそうになる。頑張ったが、そもそも、普通にエレベータに乗らないのがわかった。中に仮に入ったとして、組み立てなんて２人で絶対無理だわ。エレベータは斜め上にしてあげたらいけるかもしれんけど、機械つかって３人でも無理な重さだ。
どこのだれが、２人で十分って言ってるんねんほんま。とうとう私たちはエレベータに詰めることもできず、スタックした彼は「人でを調達したほうがいいよ。ローリーは貸してあげる。」とアドバイスをくれて「自分にはアイデアがある。この扉のパーツは、扉が重いから、これを外せば、かるくなるからインストールできるんじゃないか？」そういいながら、彼は仕事に戻った。しかし彼は「こんな重いものは無理だ」とか、「こんなのここのアパートに入れたらだめだわ、傷がついちゃう」とか言いそうなものだが、「どうやったらできるか」を必死にかんがえてくれた。
彼が去った後、くっそおもいローリーが邪魔なので、なんとかアパートの扉の外に戻して、にっちもさっちもいかなくなって、日本人の友人につぶやいた「自分がアホでした。やっぱり昨日キャンセルしとけばよかった。」彼は「この国の経験値があったと思いましょう。」そして、彼に、キャンセルの相談をしていると、まずは、宅配会社を呼ぶ前に、VocalBoothに連絡をして、リファンドの指示をもらわないといけないよと言ってくれた。だから、VocalBoothに再度電話をして、キャンセルのプロセスを教えてもらうことにした。
周囲の住民の反応
さて、このクソ重い、そして、デカい防音室の扉がアパートの前にローリーにくくりつけられて立ってる。こんなものを見たら、日本の同じアパートの人だと「大家さんに相談したほうがいいんじゃない？こんなのは入らないよ。」「邪魔だし、無理だよ」「迷惑です」とかいわれそうなものだが、絶望している私に何人もが話しかけてきて、「おー、これ、めっちゃいいやつやん、俺もギター弾いてるんだよ、君がうらやましいな！」とかおばちゃんも「防音室だねー。エンジョイしてね！」誰一人あきらめろとか、迷惑とか言わなくて、「めっちゃいいね」と言ってくるのだ。自分は絶望しているのに。もうキャンセルしたいって。
Vocal Booth の一言
キャンセルの指示を聞くためにVocalBoothに電話をしてみた。高さは大丈夫だけど、扉が重いし、エレベータに乗らないし、どうしようもないという話をしていた。そしたら、彼が、「そうなんだ、普通は２人でいけるんだけどなぁ。」私「ちなみに、ドアを取り外して軽くするとかできる？」彼「お勧めしないない、だけど、ピンでとれるよ。こういう時は、うちは、People Readyというところにいつもお願いしているよ。」キャンセルもできるけど、最後の望みで、そこに電話をかけてみることにした。すると、そこは、人を派遣してくれるような会社さんて、「今すぐなんだけど、大人２人２時間手配できる？ものすごく重い家具を運んで組み立てるのを手伝ってほしいんだけど。」「いつがいいですか？」「できればなるはやで」すると１時間ぐらいで２人を派遣してくれた。
屈強のナイスガイ
すると、２人のかなりごっついナイスガイがやってきた。時間差で来たので、最初に来たナイスガイと私で、重くないけど、扉と同じサイズのものをためしに上げてみることにした。一応家には入った。ただし、扉は重いし厚い。この人が２人来てもあの重さやし、無理やったらキャンセルやな。と思っていた。もう一人のナイスガイもやってきて、とうとう扉にチャレンジすることになった。３人がかり＋機械で無理やったやつだ。それが、なんと２人のタフガイは、機械も使わず普通に運んだ！マジっすか？ エレベーターも斜めにして、通過して、曲がりくねった入口もさすがに大変そうだったけど、私も手伝ってなんと家の中に運搬できた。ホントかよ！すごすぎるこのナイスガイは！
手際のいいナイスガイ
するとナイスガイは、Vocal Booth の説明書を読みながら、苦労はしながらも着々とめっちゃ重いブースを組み上げていく。重さを知っているだけに、信じられない光景だ。私も筋トレをしているが、なにか根本が違う。引っ越し系のプロ凄い！俺はプログラミング頑張ります。ごめんなさい。という気分になりながらも、何回も挫折して絶対無理だと思っていたものが目の前で組みあがる光景は感動的だった。しかも、アメリカではあるあるなのだが、Vocal Booth の組み立ての説明書が、間違っている。私は Silver を買ったのに、Gold の説明になっている。これはわかるはずないわ。でも、ナイスガイは、そんなことはものともせず、たぶんこうだと文句ひとつ言わず、組み上げていく。そして完成。
さらなる不可能を現実に
最後の大仕事は、コンテナだ。中身を抜いたものだが、めっちゃ重いし、そもそも、これ、どうするの？どこに捨てるの？という感じだ。先のどのBrent が去る前に相談したら。コンテナは２つにおって捨てるといいよと言われた。彼も経験があるらしい。アメリカどんな国やねん、、、
しかし、このコンテナは各段に硬いし重い。しかしナイスガイたちは、ガンガンにトンカチでたたいたり、上に乗ったりして、コンテナをぶっ潰してゴミ箱にぶち込んだ。あんたら凄すぎやろ、、、ナイスガイと感激の握手をして、のこりの日本人の友人と家に帰って、出来立ての Vocal Booth を試してみることにした。
人生で最も良い買い物
私は音楽をやっていて、長年いろんなものを買ってきた。少しでもうまくなりたくて、いい音がだしたくて、いろいろ買ってきた。しかし、この目の前にあるVocal Booth は人生で買ったものの中で最も素晴らしいものと断言できるものだった。ミュージシャンにとって、一番のストレスは、「音を出せないこと」で、歌にしても、家だと近所迷惑なので思いっきり歌えないし、ギターのアンプも小さくしないといけない。そうなるといろいろ違うので、実際にやるときとは違うし、歌も大きな声で歌わないと、うまく練習にならない。それが、なんの気兼ねもなく全力で歌って、ギターも相当デカい音で鳴らしてもTVぐらいだし、あれだけ昔苦情をいわれたアコースティックギターもTVよりもちっさいぐらいの音になる。ヴォーカルに至ってはシャウトしてもめっちゃ小さいおとしかしない。もう最高、最高だ。自分の家に音を出せるスタジオがあるのがこんなに素晴らしいことと思わなかった。人生で一番いい買い物だ。マジで。めちゃくちゃいろいろあったけど、あきらめなくて本当によかった。いや、私はあきらめてたんだけど、他の人が背中を押してくれた。
最大級の違い
今回はめっちゃくちゃ苦労したので、思い入れがありすぎて、長くなってしまったが、今回の一連の事件で最も衝撃だったことは、こんなタフなことを起こっても、Facebookの上の人を含めて誰一人「おまえアホやなー」「無理やろ」「諦めさない」とか言わなかった。全員が「絶対にできるよ」とか、「これ、めっちゃいいやつだよね！」「つよしが、ヴォーカルブースでエンジョイできることを楽しみにしてるよ」とか、どんな立場の人でも言ってきた。こんな環境で生きているからかもしれないけど、相当困難なチャレンジもきっと彼らにとっては普通で、それより、その先にまっている楽しいことを考えているし、失敗したらどうしようとか誰も考えていない。自分は日本人の中では相当チャレンジな人やと思ってたけど、やっぱ日本人なんだなとおもった。やっぱ失敗が怖いんだ。失敗を避けたいんだなぁと。こういう話を後で友人のDavidにして、日本人は失敗さけたいから、先に予見しようとして、時間がかかるんやと思ったわ。みたいな話をしたら、「そういう場面やと、自分はメジャーで測りもしないわ。やってみたらわかるやん」と返してきた。タフすぎるｗ つまり、私だけかもしれないが、自分のような日本人はそういうのが体に染みついているから、出来るほうに倒してしまうのだけど、こっちの人は、失敗するかもしれない難しいことにサクッとチャレンジして、それが普通で、周りの人もそれを歓迎してくれるんだ。だから、自分は、自分にそういうのが染みついていることを意識して、難易度ではなくて、「こういうことを実現したい」ということに対して難しそうに見て得てもチャレンジするようにするように選択を倒すのが必要と思った。
ソフトウェアもチャレンジング
そういえば、ソフトウェアでも、こちらの事例はチャレンジングなのが多い。昔マイクロサービスのハックをこちらでやったときも、出たばかりの製品を本番どころか、普段クラウドで使うところをオンプレで使ったりしていた。どんだけチャレンジャーやねん。と当時は思っていたが、そういう無理目なことをするから、失敗も多分あるけど、技術力が上がるし、うまくいったときの成果も自分にとってのVocal Booth のように、感動的なものになるのかもしれない。そういえば、Davidもスノーボードのコースも日本だったらそもそも入れないような区域に余裕で滑りに行っていた。つまり、結局のところ、困難なチャレンジをしないと本当にインパクトがある結果など出せない。それができている国民性がアメリカというところなのかと思った。確かにGitとかでも酷い目にあったときに新しいコマンドを覚えて使えるようになよな。上記のようにすべてが素晴らしいわけではないが、プロフェッショナルとしての腕を磨くには最高の環境かもしれない。
では日本ではどうしたらいいだろう？
この学びを日本で生かすにはどうしたらいいだろう？少なくともソフトウェアにおいては自分には、相当な「失敗への恐怖」と、「チャレンジの回避」の傾向があることを自覚するだけでも、かなりいろんな効果があるかもしれない。そういう視点で、他国の人を観察してみよう。日本にいても例えば、GitHubとかのプルリクエストでどんな会話をしているか？とか、観察するチャンスはいろいろある。そういえば、そういう方面でも、失敗を恐れて何かしないとかほぼ見たことないことに気が付く。だから、自分が思ってるよりもかなり困難なことをを実施しても出来てしまうかもしれない。自分が無理でも、私の出会ったAmazingなマッチョなナイスガイが手伝ってくれたら自分が想像だにしていなかったことを実現できるかもしれない。どうするかは人それぞれやけど、自分は、プログラミングの方でも「Vocal Booth」のような人生に何回もであえないような感動的な体験をしてみたいと思う。
ググるのをやめるとプログラムの生産性が上がるかもしれない
今日はプログラミングの生産性に対して気づきがあったのでシェアしてみたい。
なぜ米国の人は生産性が高いのだろう
プログラミングの生産性に関しては以前から興味がありいくつかのポストで考えたことをシェアしてきた。私は職業柄、いろんな国でいろんな人々とプログラミングを一緒にする機会が多い。その時に頻繁に感じるのは、平均的に言うと、アメリカの人プログラマが生産性が高い確率が高くて、しかもコードもきれいだという傾向にある。アメリカでお客さんと一緒にコードを書くと、お客さん自体が物凄く良く知っているし、実行力もある。アメリカの次と言うことでいうと、英語がネイティブの国もそれに近く、フランスなどの言語が近いところが続く感じなので、英語が物凄く影響すると思っていたし、実際すると思う。そのあたりの話はこちらのポストに書いてみた。
simplearchitect.hatenablog.com
定義での理解と、例での理解
アメリカのエンジニアと自分や、日本のエンジニアを比較すると、「理解」のロジックの傾向があるように感じる。日本の多くのエンジニアの場合は、「例」で理解するのを好むように感じる。「定義」をみても、今いいち理解しにくくて、例を見て理解する傾向が強いように感じる。一方、アメリカのエンジニアや、いけてるエンジニアは、「定義」で理解する傾向があるように感じる。定義の短い文章だけを見て、それがどういうものかをさっと理解できてしまう。
一方、「例」先行の人の場合、もちろん私もだが、最初に、定義を見るより、先にググって、ブログやコードサンプルを見つけて、どうやったらできるかを見つけて、その後で定義を見て理解するといったステップになっている。ひどい時は、サンプルをコピーして動けばOKで、なぜそのコードが動いているのかも理解していない人もいる。短い定義だけをさっと見て理解してコードをかける同僚や、師匠を見て凄いなぁ、、、といつも思っていた。やっぱこれは、言語と文化による違いだろうか？ 理解を重視するのと、動くことを重視する姿勢とも言える。
シンガポールでの出来事
この仮説を覆す出来事が先日シンガポールに行った時に発生した。シンガポールの人はビジネスは全部英語なので英語が大変堪能だ。自分の仮説上は、英語が堪能なので、アメリカに近いつまり、定義と理解を重視する人々と思ってハックをすると全く違った。彼らは私たちと全く同じく、例を重視して、理解よりも動くことを重視していた。インドの人も混じっていたが、インドの人は、定義重視と理解重視の感じだった。この「定義での理解」と「例」での理解は、言語に大きく影響しているのかと思いきやもしかすると違うのかもしれない。もちろん、コンピュータサイエンスの場合英語がリーディングやネーミングやメタファで圧倒的に有利なのは間違いないが、この部分に関しては違ったらしい。
アメリカのインターンとのペアプログラミング
そういえば、シンガポールに行く前は、アメリカでハックをしてきた。そこで、Javascript のコードを書く必要があったのだが、最近触ってなくてすっかり忘れていることともあり、堪能な人に助けを求めた。すると、コーディネーターが Javascript できるインターンのハンサムガイを連れてきてくれた。
一緒にペアプログラミングをしたのだが、一つ衝撃的だったことに、彼はほぼググらなかった。見るとしても、リファレンスか、公式のサイトのみ。それでも、定義だけを読んで、「このメソッドがこのように使えるはずだ」とか言って、さっとプログラムを一緒に作ってくれた。インターンのせいか、彼のコードは綺麗ではなかったが、彼は十分に挙動を理解して、全然サンプルを見ないままコードを一緒に書き上げてくれた。ある一瞬彼が、「どうしたらいいんだろう？」と悩んで、リファレンスなどを見ながら悩んでいたので、私が、自分のブラウザでその時困っている現象をグーグルに打ち込んで検索してブログを見つけて、一瞬で解決した。なぜ彼にそうしなかったのかは聞かなかったけど、彼はそもそもそういうことをするという素ぶりも見せなかった。そういえば他の同僚もあまりググらないし、見ても公式ドキュメントで次にコードという感じだ。
全ては習慣ではないだろうか？
Extreme Programming で著名な Kent Beck は、「私は偉大なプログラマではなく、偉大な習慣を身につけたプログラマ」だ。と語った。つまり習慣は誰でも身につけられる。もしかすると、「定義」vs 「例」、「理解」vs 「動くこと」の違いは習慣で埋められるのかもと思うようになってきた。つまり、英語云々ではなく、彼らは幼少の頃から、「定義」で理解し、「理解」する方法を習ったか、練習してきたから、自然とそうなっているのでは？という仮説で、そうであるならば、「定義」だけを見てゴリゴリにコードをかけるようになるのではないだろうか？という仮説だ。だったら実際に自分で試してみよう。
仮説の検証
仮説に基づいて、次のことを気をつけてコードを書いて見た。自分がまだそんなに慣れていない Go 言語で実行して見た。
- 可能ならリファレンスのみを見てコードを書く
- 公式ドキュメントは見ても良い
- サンプル / ブログの類は見ない
- 速く完成させようと思わない
この単純な３つの条件をつけて、自分が今までコーディングしたことのないトピックを Go で実装して見ることにした。
実践した気づき
実際にコードを書いて見ると、色々気づきがあった。最初は、例を全く見ないでコードを書くのに不安があった。「早く作る」ことだけを考えると、自分のやりたいことで検索して、ブログを読んで書いてあることを真似するのが一番速い。ただし、この作戦は、その１回限りに於いては確かに速いのだが、本人がちゃんと理解できているか？はとても怪しいものがある。つまりどうなるか？というと、普段の私だと、何かが出てくるたびに、前にやっていても忘れているので、またググって、同じページを見て、同じコードを真似て、実装するという感じだ。確かにコードは出来るのだが、結局速くないし、理解も浅い。
今回の作戦をやって見ると、確かに初回の時間はかかるのだが、定義だけを見て、コードを書こうとすると、深く理解しないと書けないので、しっかりと定義を読むようになるし、コードサンプルがないので、自分の頭で考えてアルゴリズムを毎回考える必要があるので、コピペ作戦がこれまた使えないので、アルゴリズムを書くときに使われるイディオムも深く理解しないと結局遅くなってしまう。すると、２回目似たようなロジックが出てきたときには高速にコーディングが終わったし、サンプルの無いようなコードでもリファレンスだけを見てさっとコードが書けるようになってきた。しかもたった１日で。出来るか不安だったが、やろうとしたら出来るやん！
おおおお！これこそわしの求めていたものや！
実践のポイント
ただし、一つポイントがあって、先ほどの条件にもあった「速く完成させようとしない」というのがものすごいポイントで、他者からも、自分からも、速く終わらせようと思うと、どうしても「ブログ検索」の甘い汁を吸ってしまいそうになる。しかも、「速く終わらせよう」と思ってなかなか終わらないととってもイライラするのだ。つまり楽しく無くなる。「速さ」は、後から付いてくるから心配しなくてもいい。それよりも「理解できていない」ことを恐れたほうが、絶対的に安全だし、スピードも結局上がることに気づいた。
後、「ヤクの毛刈り」ともいうけど、あるコードを調べているときに、その中でわからないことが出てきて、またそれを調べて、、、起こった時にはどうするか？それも焦らず理解するようにした。作戦としては、調べ物をするときに、ブログを同時に書いて、調べた内容や、自分で作り上げたコードを書いていく。その過程でわからないところが出てきたら、理解してブログに書くようにして見た。これは、先日紹介した、自分の動作を先に書き出してから実践するの応用作戦だ。急ぐのをやめると、コードを書いている過程できになる「ああなったらどうやって書くんだろう？」みたいなものもみんな調べて試すようになってきて、深さも出るようになってきた。
simplearchitect.hatenablog.com
書いていてどうしても解法がわからない時とか、書けるけど多分なんかいい API ありそうみたいな時もある。そういう時は、まず自分の解法で書いてみて、その後、ググってみて、あーこんな API あるんだとわかったら一瞬でブログや、サンプルを閉じて、リファレンスのページを見るようにすると良さげです。
まとめ
サンプルコードを求めて、ググってブログや、Stack Overflow のサンプルに頼るのをやめると、理解が高まり、高速にコードが書けるようになってきたと思う。そういえば日本人の技術イケメンや師匠もあまりやたらとググってなかった気がする。この方法を継続してやってみて、どうなるか実験して行きたい。実際にやっていると、初めのうちは高速なのかわからないけど、確実にわかるのは、完璧に自分でコントロールできている感を持てているということだ。これは自分にとっては大きい。
ちなみにこちらのブログは、初めて、リファレンスのみを見て技術調査をしながら書いたブログだ。単純なものだが、今後もっと複雑になっても、この姿勢をキープしながら継続してみたい。
最近気づいてきた、「日本人」のいいところは、我々は真面目ということだ。平均のレベルは圧倒的に米国に負けているが、トップレベルの日本人プログラマは向こうに行って十分通用するどころか、向こうに行ってもすば抜けていると思う。彼らは、言語やら習慣やらでコンピュータサイエンスは強いけど、私たちほど頑張ったりしない。だから、積み重ねていけば私たちでも世界で十分に活躍出来る素養は十分にあると思うのだ。
メタファーを身につけてプログラミングの生産性を向上させる
インターナショナルチームでプログラミングの仕事をしていると、いろんなところで同僚との差を感じてしまう。いろんな国の人がいて、レベルは人によりそれぞれなんだけど、一般的にいうと、アメリカのプログラマのレベルは平均してとても高い場合が多い。とにかくコードがきれいでシンプルで仕事が早い。
彼らがなぜそれができるのかを観察しているが、一つ気が付いたことについてその対策も含めて書いてみたい。
彼らがプログラマとして優れているところ
USにいるとお客様の技術レベルが高いとか、新しいことにチャレンジするとかいろいろ要素はあるのだけど、個人の生産性、コードの美しさをみても、平均値を観察するとアメリカの人が一番に感じる。その他にも、ドキュメントを見てすぐ理解できる能力は、アメリカの人はおろか、ヨーロッパ圏やインドの人と比べても、私は圧倒的に負けていると感じる。
Williams 衝撃の読解力
新しいライブラリを学習しようと思って、GitHub のページを読んでいると、フランス人の同僚 Williams がやってきて、何読んでるの？というので、それを見せてあげた。
彼は GitHub のディスクリプションだけよんで、「あーこれはこうこういうことが出来るライブラリできっとこんなコンセプトだよ！」みたいなことを言い出した。彼ももちろんそのドキュメントは初めて見るのになんだろうこの理解力の差は。
自分だと、ドキュメントを読んで、チュートリアルをやってみて、コードを書いて試してみてやっと大体どんなものかが理解できるというのに。しかも、これは、彼だけではない。私だけ劣っている感じ。
同僚のJavaの世界で著名な寺田さんも言っていたが、これはものすごい差だ。彼らは我々ほどまじめじゃないので、少なくとも私と寺田さんは、この溝を、努力の量で埋めている。
だけど彼らはもっと楽にそれを成し遂げる。アジア圏の人は同僚にいないのでわからないけど、このあたりは日本人は不利に感じる。
技術力の差は英語力の差
この差がある理由は漠然と「英語力の差」ではないかと思っていた。寺田さんも同じように感じているようだ。
彼らは同じドキュメントを読んでも読み取れる内容が我々とは違っていて、同じ文章を読んでも、明確にそれが何を意図しているかイメージできるのだろう。しかし、これはどうやったら身に着けることができるのだろうか？
英語の勉強して、Proficient とかになったり、海外に長年住んで多読とかをすればいいのだろうか？多分それでもいいのだろうけど時間がかかりすぎる気がする。どうしたらいいのだろう。
Deliberate Practice
私は要領が悪いので、自分の生産性を高めてくれるメソッドを学ぶのが好きなのだが、この前 Deliberate Practice というコンセプトを知った。
何かをできるようになるためのメソッドなのだが、最初は凄くゆっくりから、１つのことに集中して練習するらしい。それを試してみようと思って、自分が知らなかった DependencyInjection のライブラリのドキュメントをその方式で読んでみることにした。
実施したことは下記のこと。
- ドキュメントを読むときに、わからないと立ち止まって意味を調べる、ゆっくり考える
- コードを読むときも、わからないときは立ち止まって意味を調べる、ゆっくり考える
ただこれだけ、先に先に行かず、本来なら１７分で読める技術ドキュメントを精読してみた。すると、あることに気づいた。
自分は「コード」の意味がよくわかっていないのではないか？
これは、そのコードが「どのように動作するか？」をわかっていないという意味ではない。コードに書かれている英単語の意味が「ふわっと」しか分かっていないのでは？ということに気が付いた。例えば、コードを書いているときによく出てくる「Context」という用語がある。ここでは、「DBContext」が出てきた。ふわっとはわかるし、コードによくでて きて、大体どんな雰囲気のコードがでてくるかもふわっとわかる。問題は「ふわっと」しかわかってないことじゃないか？と思って、英英辞典を引いてみた。
The context of an idea or event is the general situation that relates to it, and which helps it to be understand. We are doing this work in the context of reforms in the economic, social and cultural spheres.
適当に訳してみると、コンテキストというのは、アイデアとか、イベント、それがかかわっていることの一般的な状況で、それが理解されるのを助けてくれるもの。例文としては、私たちはこの仕事を経済、社会、文化的な領域をリフォームするという文脈で実施している。
とある。HttpContext とかよく出てくるけど、HttpのRequest/Response とかにかかわかるデータやステートがごそっとそこに入っているけど、これは、この意味と照らし合わせると、明確にわかりやすいネーミングだなあとわかる。このContext の意味をもとから知っている人なら、あまりその内容がわからなくても、Context という単語の意味合いから、そのクラスがどういう責務を持っているかが容易に理解できそうだ。
英単語の意味を調べるのは英英辞書がお勧め
ちなみに、私は英単語の意味を調べるときは、英英辞書を使っている。なんかハードル高そうだが、英英辞書にもネイティブじゃなくて、第二言語学習者向けの説明が簡単になっているものがあるのでそれを使っている。なぜかというと日本語に翻訳した翻訳は意味がちがっていたり、元の意味が取りにくくなっているのがおおいからだ。私は iPhone のアプリを使っている。
他にも私がその文書を読むときに調べたよくあるけど、よく意味がわかってなかったものに、Transient がある。和英の意味を引くと意味が分からない。Transient は遷移的とかいてある。なんじゃそりゃ？英英辞書で調べてみると
Transient is used to describe a situation that lasts only a short time or is constantly changing. ...the transient nature of high fashion
Transient は、短い時間で、変わり続けるような状況。なるほど。強引に日本語にすると遷移的というのはまちがってはいないけど、こっちのほうがわかりやすい。で、例えば、これが、どういう文脈でコードで使われていたかというと、DI のコードがあって、DI の対象になるクラスを登録する過程で次のようなコードが出てくる。
service.AddTransient<ITransientService, TransientService>(); service.AddSingleton<ISingletonService, SingletonService>(); service.AddScoped<IScopedService, ScopedServcie>();
ちなみに、ここでは、シングルトンはこのインスタンスが呼び出されるときに、インスタンスは常に１つ、Scopedは、リクエストが同じなら同じインスタンス、Transient は、呼び出されるたびに新しいインスタンスが作られる。これだと、Transient の意味は上記とマッチしていない気がするが Guid を DI 対象のクラスで生成して、同じインスタンスが使われているかを調べるとどうだろう。Singleton は常に同じ Guidになるし、Scopoed はリクエスト内なら同じ、そして、Transient は、呼び出されるたびに、毎回「違うGuid」になる。つまり、毎回違うインスタンスになる。
短い時間で移り変わるというイメージを持ったTransientの意味と照らし合わせるとこれまたむっちゃわかりやすいネーミングだ。
他の例としても Container とかある。私だと、ふわっと、Docker のコンテナとか、コードの文章でも、コンテナって出てくる。技術やコードから逆算すると、船に積むコンテナみたいなイメージだろうか？と思っていたけど、最初の意味はこれだった。
A container is something such as a box or bottle that is used to hold or store things in ...the plastic containers in which fish are stored and sold.
もちろん、私が思った船に積むコンテナの意味もあるのだが、最初の意味を調べると、もっと一般的に何かをいれる箱みたいなものみたい。Docker のコンテナのイメージは船のコンテナのイメージが強いけど、コードだともっとカジュアルな状況につかわれている場合も多い。なんかの入れ物ぐらいな感じなのね。他にもこのコードの中では Service とか Registry とか、Populate とか Construct の意味を調べた。どれもこれも、頻繁にコードにでてくるのに「ふわっ」としかわかっていなかった単語の数々だ。
メタファーの意味を２０年近くかかってやっと理解する
このように、コードがどのように動作するか？だけではなく、コードで使われている単語を英英辞書で調べることで、相当コードでなぜその英単語がチョイスされているのかが明確にイメージできるようになった。多分これはすっごい重要な事だ、なんで今までやってこなかったんだろう！と思ったが、そんなことはとっくに先人わかってたことで、しかも私もその概念を何年も前に学んでいる。
それは「メタファー」だ。2000年頃に Extreme Programming に出会ったときに、そのプラクティスの一つとして「メタファー」というのがあって、「クラスの名づけをするときに、比喩を使う。そうすると、ほかの人とその意味合いを共有しやすくなる。」とか書いてあった。
当時は正直意味もわからなかったし、「そんなん英語圏の人だけ有効なんちゃうかな」と思ってたけど、たぶんこれのことだ。だから、英語が一番できるアメリカの人のコードはきれいなことが多いのか！だから、ネイティブのアメリカ人やイギリス人じゃなくても、単語の意味を分かっている人はいろんな理解が早いのかとかなりの腹落ちをした。
メタファーってこれやったんか。２０年近くたってやっとわかったわ。
最初からスピードアップできないだろうけど、ゆっくりはじめて、手抜きをせずやってるとだんだん早くなってくるんじゃないかと思う。
使われるメタファーの用語を理解しよう
というわけで、今回学んだことは、コードに出てくる単語はそんなに多くないので、自分がふわっとしか理解できていない用語が出てきたら、それを英英辞書で調べるとかなりすっきりするということだ。ツールの名前とかも調べるとよさそう。例えば Heptio という製品群に Ark というk8sのバックアップツールがあるのだけど意味を調べると
In the Bible, the ark was a large boat which Noah build in order to save his family and two of every kind of animal from the Flood
これは確かにわかりやすいわww
英語学習をがっつりやるより楽
となる感じ。ちょっとしたことだけど、英語全体をがっつり勉強してもこれらのボキャブラリに到達しないかもしれないので、コードに出てくる順から調べたほうが効率がよさそう。CLI のコマンドのサブコマンドとか普段使っている Build とか、Compileとかの意味を調べてみてもいろいろイメージできて楽しい。プログラミングの生産性向上目的なら、英語自体をふわっと向上させようと思うより圧倒的に調べないといけないことが少ないし、ふわっとしか意味がわかっていなくてもなじみはあるので、記憶に残りやすい。
しばらくいろいろ調べるのを楽しんでみて生産性が上がるか試してみたい。
今回は「メタファー」を理解できるといろいろはかどりそうだと気づいたので、ブログでシェアしてみました。
ADHD プログラマの私がやっと見つけた「達成すること」が出来る方法
私は昔から ADHD で昔から発想力や問題解決力はあるのだが、自分自身が何かのスキルを上達することが非常に苦手だ。コンサルとか、エバンジェリストみたいな「人にやってもらう仕事」は得意だが、プログラマとか、ヴォーカリストとか、自分が本当になりたかった職業には何回もチャレンジして何回も失敗してきた。
遠くから見ていると私は何かが出来てるように見えるかもしれないが、冗談抜きで人の３倍ぐらい時間をかけないと成果が出ない。しかも、中途半端にしか完成しない。だから、土日も常に何か努力していないと不安になる。
多分私と同じようなADHDの人は、自分的に努力しても何も達成出来ない辛さを感じているかもしれない。過去にも色々試してみたのだが、４７年生きてやっと自分でも実施できる対策が見つかったので、同じ様なことで苦しんでいる人のヒントになればと思い久々にこのブログを書いてみた。
「自分で何かを作れる人」が長年の憧れ
大変な偶然なのだが、今は私はエバンジェリストからプログラマになれた。ただ、それは私の実力というより、組織変更でロールが変わったためだった。NEC に新卒で入社した時は、OSのコマンドを担当したいと言ったのだが、配属は営業部門だった。営業活動は全くやる気が出ず、仕事が終わったら、会社に行ってUnixをずっと触っていた。そしたらある先輩が私をSEにしてくれた。
それからもプログラマになる事は心の中で燻っていたのだけど、「自分がやる仕事」は本当に全く出来なかった。仕事だけじゃなくて、スポーツも、勉強も、音楽も、何か「自分が上達する」という事に関しては致命的にうまくいかない。
スポーツも全然だめ。皆勤賞で、６年間やってたバスケは誰より１時間早く来てシューティングしたり毎朝ランニングとかやってたけど、レギュラーどころか、一秒も試合に出れなかった。
風向きが変わって来たのは、オブジェクト指向とか、アジャイルとかをやり始めてから、「コンサル」や「コーチ」みたいなもの、つまり、「人に何かやってもらう」とか、「仕組みを考える」とかは得意な様だった。それからもそういう人生だったけど、自分が本当になりたかったものは、「自分で何かを作れる人」だった。
3倍の努力をいつまで続けたらいいだろう？
今回はたまたま、憧れのプログラマになって、多分会社としては、今はロールが変わったばかりで能力に関しては多めに見てくれているが、私がマイクロソフトに入れる程優れたプログラマではない事は明白だ。このまま、３倍の努力を続けていないと、実力が無いのだからいつクビになっても仕方がない。しかし、「三倍の努力」は生活の殆どの時間を奪う。朝起きて、寝るまで、今はほぼ仕事、筋トレしかやっていない様な生活だ。同僚がバケーションを楽しみながらも、効率よく色々なものをマスターしていくのを横目に、自分は時間がずっとかかり、しかも中途半端。
４７年も ADHDをやっていると、こういう事も自分では受け入れている。ないものを嘆いても仕方ないから、別の方法を試すしかない。効果があったものとして、医師に処方されたリタリン。これは現在禁止されている。Lumosity というゲーム（科学的に効果がないと判定されたらしいが、ADHDの自分には集中力を上げる効果があるので今も契約している。）
あとは、それよりも強力なのが、オメガスリーのフィッシュオイル（こちらは、科学的にも効果が認められている）ただし、１日の「ここぞ」というところでそれを飲むので、効果は長くは続かない。
他に BCAA という筋トレで使うパウダーも集中力を保ってくれる働きがあるので、よく使う。朝型にして、仕事の後、運動をがっつりして仕事に戻るという働き方も、物凄くよくて、脳のキレも最高にはなるのだが、ADHDの「達成出来ない」問題は解決しない。しかし、ある日ふとした事で、解決策を思いつた。
プログラミングをしていて気づいた事
先日プログラミングの技術調査をして、サンプルコードを書こうと思っていてパソコンに向った。やりたかった事は、たった１つのAPIの検証。しかし朝７時から初めて気づいたら１５時だった。しかも、終わっていない。ADHDの私が昔から何回も体験した感覚。いつもながら自分にがっかりする。自分が知らず知らずに無意識にやってる見積りでは、「２時間ぐらいでできるかな。余裕を持って」だった。しかし、いつも私の考えている見積りは大幅に遅い方に間違うのが普通だ。
XP とかだったら、理想見積という考え方をやるときは、邪魔が一切入らない状態でという条件で見積もりをして、初回は2.5倍する。人はだいたい見積りが下手だ。しかし、私の場合はこの度合いがもっとひどい感じ。
筋トレに向かう電車の中で、なんでこんなことが起こったのだろう？というのをふと考えてみる事にした。今までは、ADHDだからこんなもんと思っていたけど、本人は本当に嫌な事だった。本当に。思い起こしてみると、もっとも大きな問題は「最初に思ったことと、関係ないことを大量にしていること」だった。ちなみに、次点は、「何かを調べているうちに、前にやっていたことを忘れる」だった。
全ての行動をはじめる前に書いてから始める
次の日にやってみたこととしては、やるタスクをリストアップしてから仕事をしてみようと思ったことだった。これは、例えばアジャイルの世界で有名なテスト駆動開発でも、最初にタスクリストを自分の手元の紙に書いてから始めるというのがある。
一定の効果はあるものの、ADHDの自分には「効ききらない」のも過去に試して知っている。しかし、今回は何かをするときに、先に紙に書かないと行動しないと決めてやってみた。
すぐに違うことを初めてしまう事に気づく
すると気づいたのだが、自分はすぐに違うことを始めようとするのだ。それも、「Webサーフィンしてしまう」とか、「Youtubeを見てしまう」とかわかりやすいもの以外が大量にあるのだ。
一つの例として私は、API の使い方を理解して、あるプロジェクトにコントリビュートしようと思った。今日のゴールは、無理せず、APIを調べて、その使い方を理解するためにサンプルを書くことだ。
Task 1. Azure Functions の Function Keys を Golang で取得する方法を調べる
今回は、Azure Functions の Functions Keys をGo lang で取得する方法を調べたかったはずなのに、APIリファレンスを見ているうちに、次々と違うことが頭に浮かぶ。
- 「あ、そういえば、次は CORSもすぐ調べないといけないな」
- 「あ、これ、CORSのAPIだ。」
- 「この構造体一体なんだろう？」
- 「コード読んでみよう」
- 「あれ、このプロバイダって一体なんだ？」
- 「この文法よくわからないな」
- 「サンプルプログラム作ってみよう」
- 「あれ、venderのディレクトリが認識できないぞ」
- 「Google で調べてみよう」
- 「うーんよくわからない」
- 「さっき何を調べているんだっけ？」
-> 時間ぎれ
みたいな感じで、一切何も達成できておらず、身にもなっていない。
こんな事だと、いくら最初にタスクリストを書いても効果がないのは当然だ。多かれ少なかれ人にはあるのかもしれないけど、ADHDの人にはこの特徴が顕著なのかもしれない。ADHDの原因として、今有力な説は、前頭葉が不活性で、短期記憶が人より短く、短期に覚えておけるものが少ない→だからすぐ気が散るというものらしいので、そらそうだなという感じだ。
行動する直前にタスクを書く
通常にタスクをリストアップするのは自分には通用しないと悟ったので、次にとった作戦は、タスクをこなしている途中で、「これをしてみよう」と途中で思った事も、まず、その場でタスクリストにまず書いてから、それをやるべきか考えてから、行動するという作戦にして見た。
これは正直めちゃめちゃ有効な作戦だった。途中で思いついた事は、今すぐやるのが「悪い事」とは限らないのだが、今は違う事に集中した方がいい事の方が圧倒的に多い。だから、一旦紙に書いてみると、「あー、これ今しないほうがいいや」と思うことが多い。たまに「確かに今のゴールにはこれはやった方がいい」となる場合もあるけど、前のように、あっちいって、こっち行って何も達成できないとかが激減して、自分が普段見かけた「普通の人」と同じ程度の生産性を出せている。
ADHD 特有の短期記憶の弱さにも有効
しかも、いいことにこの方法で行くと、ADHDの短期記憶が弱い欠点の助けにもなる。例えば、よくあるのが、コードの意味を理解すために、メソッドを読む -> ロジックを読む -> その過程で知らない構造体が出てくる -> 構造体を探し回る -> その間になぜ構造体を理解したかったのかを忘れる ということなのだが、これも最初は
1. ○○メソッドを理解する
というタスクだったとすると、これを調べているうちに、内部で使われている認証ライブラリがサンプルに必要であると気づく。そこの引数にはどんな値が渡せるのだろう。その型を調べないとと考える。 その時点でタスクを追加する。なぜ調べているかも書いておき、調べたら、Linkなども貼って置いたりする（すぐに忘れて、 ブラウザがタブの嵐になって、探せなくなるから）
1. ○○メソッドを理解する 1.2. 認証ライブラリに引き渡せる構造体の条件を調べる https://docs.microsoft.com/en-us/.......
その構造体を探している間にもいろんな事に気が散る。あれ、このGetXXというメソッドこんなところにあったとか。前に調べていたやつだ。コードを見てみようとか考える。でもそれをやり始める前にグッとがまんして、先にに書いてみる
1. ○○メソッドを理解する 1.2. 認証ライブラリに引き渡せる構造体の条件を調べる 1.3. GetXXメソッドのコードを読む
そこで、ふと我に帰る。「おっと、これは全然関係ないじゃないか」と。そこで、このタスクを Parking Lot （駐車場に入れる）Parking Lot は今やらないけど、重要なことという意味。
1. ○○メソッドを理解する 1.2. 認証ライブラリに引き渡せる構造体の条件を調べる
Parking Lot GetXXメソッドのコードを読む
ポイントをまとめると
- 何か思いついてやろうと思う前に書いてから始める
- タスクの内容は常にアップデートする
- タスクリストは常に追記し続ける
という単純なもの。通常のタスクリストの粒度よりずっと細かくなるのだが、ADHDの私にとっては「思いつく」-> 「違う事始める」にめちゃめちゃ効果がある。たったこれだけ。
別のサンプル
このやり方をより理解するためにに、私がこのメソッドを「歌の練習」に適用した時の手書きのカオスなタスクリストを公開したい。これをみるとどんだけ気が散ってるねん！という感じがわかると思う。どんな感じだったかをシェアしたい
最初に書いたタスクリストはこれだけだった。
最初の１小節を完璧に歌う 1. あいた喉の状態をキープする 2. 母音、子音のバランスをとる 3. 正しい音程と、音の長さを確認する
もちろん、全部できると思っていないので、1. 2. 3. は優先順位で最悪 1. だけでもいいと思って練習を始める。練習をし始めると、いろんな事を頭が思いつく。突然ウォームアップを歌い出そうとする。ちょっと待て、その前に、書いてから。これは、ゴールに近いのか？と考える。どう考えても違うので、Parking Lot の方に
最初の１小節を完璧に歌う 1. あいた喉の状態をキープする 2. 母音、子音のバランスをとる 3. 正しい音程と、音の長さを確認する
ウォーミングアップする
次に思いついたのが、喉があいた状態をキープするために、テンポを落とした状態で歌ってみる。という事。確かに、これは、最初にやっている「あいた喉の状態をキープ」の練習に有効で今やるべきなので書いてから、今実施。（ちなみに、実際の写真は自分でも字が読めないほどカオスやけど、やってるときは認識している）
最初の１小節を完璧に歌う 1. あいた喉の状態をキープする ・ゆっくり歌ってみる（キープしたまま） 2. 母音、子音のバランスをとる 3. 正しい音程と、音の長さを確認する
次に思いついたのが、あー、そういえば、イタリアに旅行に行きたかったけど、まだ予約してないなという事。もちろん関係ないから、パーキングロットへ。もちろん今やらない。
最初の１小節を完璧に歌う 1. あいた喉の状態をキープする ・ゆっくり歌ってみる（キープしたまま） 2. 母音、子音のバランスをとる 3. 正しい音程と、音の長さを確認する
ウォーミングアップする イタリア旅行調査
次に思いついたのが、ヘッドボイス、ミドルボイス、チェストヴォイスをいつ切り替えるかを考えないといけないなという事。これは重要だけど、「あいた喉の状態をキープする事を できるようになる練習」とは違うよな。今しない。
最初の１小節を完璧に歌う 1. あいた喉の状態をキープする ・ゆっくり歌ってみる（キープしたまま） 2. 母音、子音のバランスをとる 3. 正しい音程と、音の長さを確認する
ウォーミングアップする イタリア旅行 ピアノで音をとって、ヘッドヴォイス、ミドルヴォイス、チェストヴォイスの切り替えを確認する
次に思いついたのは、「あー、英語の発音悪いな。母音と子音のバランスを調整しないと聞こえが悪い」しかし、これは書く前に、リストをみると、２でやる事になっているので、今はまずは喉の状態をキープする練習を続ける。
といった感じで、振り返ってみると、これがこの後もずっと続いて「これでもか！」というほど気が散っている。しかし、この単純なリストがあれば、気が散っても、元の目的に戻ってくることができるので、結局この日は、1. はおろか 2. まで達成できた。まじで、人生でこんなことはじめてちゃうやろか！
まとめ
先の例でも、この方法を使ったら、プログラミングの方も超順調で何回も脱線しそうになったり、忘れたりということなく、「達成」することができた。こんなのは人生ではじめて。 この方法がADHDの人の全員に有効かはわからないですが、自分を救ってくれた方法なので、シェアしておこうと思いました。
