メソッド屋のブログ

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

ググるのをやめるとプログラムの生産性が上がるかもしれない

今日はプログラミングの生産性に対して気づきがあったのでシェアしてみたい。

f:id:simplearchitect:20180917205414j:plain

なぜ米国の人は生産性が高いのだろう

プログラミングの生産性に関しては以前から興味がありいくつかのポストで考えたことをシェアしてきた。私は職業柄、いろんな国でいろんな人々とプログラミングを一緒にする機会が多い。その時に頻繁に感じるのは、平均的に言うと、アメリカの人プログラマが生産性が高い確率が高くて、しかもコードもきれいだという傾向にある。アメリカでお客さんと一緒にコードを書くと、お客さん自体が物凄く良く知っているし、実行力もある。アメリカの次と言うことでいうと、英語がネイティブの国もそれに近く、フランスなどの言語が近いところが続く感じなので、英語が物凄く影響すると思っていたし、実際すると思う。そのあたりの話はこちらのポストに書いてみた。

simplearchitect.hatenablog.com

定義での理解と、例での理解

アメリカのエンジニアと自分や、日本のエンジニアを比較すると、「理解」のロジックの傾向があるように感じる。日本の多くのエンジニアの場合は、「例」で理解するのを好むように感じる。「定義」をみても、今いいち理解しにくくて、例を見て理解する傾向が強いように感じる。一方、アメリカのエンジニアや、いけてるエンジニアは、「定義」で理解する傾向があるように感じる。定義の短い文章だけを見て、それがどういうものかをさっと理解できてしまう。

f:id:simplearchitect:20180917215649j:plain

一方、「例」先行の人の場合、もちろん私もだが、最初に、定義を見るより、先にググって、ブログやコードサンプルを見つけて、どうやったらできるかを見つけて、その後で定義を見て理解するといったステップになっている。ひどい時は、サンプルをコピーして動けばOKで、なぜそのコードが動いているのかも理解していない人もいる。短い定義だけをさっと見て理解してコードをかける同僚や、師匠を見て凄いなぁ、、、といつも思っていた。やっぱこれは、言語と文化による違いだろうか? 理解を重視するのと、動くことを重視する姿勢とも言える。

シンガポールでの出来事

f:id:simplearchitect:20180917215404j:plain

この仮説を覆す出来事が先日シンガポールに行った時に発生した。シンガポールの人はビジネスは全部英語なので英語が大変堪能だ。自分の仮説上は、英語が堪能なので、アメリカに近いつまり、定義と理解を重視する人々と思ってハックをすると全く違った。彼らは私たちと全く同じく、例を重視して、理解よりも動くことを重視していた。インドの人も混じっていたが、インドの人は、定義重視と理解重視の感じだった。この「定義での理解」と「例」での理解は、言語に大きく影響しているのかと思いきやもしかすると違うのかもしれない。もちろん、コンピュータサイエンスの場合英語がリーディングやネーミングやメタファで圧倒的に有利なのは間違いないが、この部分に関しては違ったらしい。

アメリカのインターンとのペアプログラミング

そういえば、シンガポールに行く前は、アメリカでハックをしてきた。そこで、Javascript のコードを書く必要があったのだが、最近触ってなくてすっかり忘れていることともあり、堪能な人に助けを求めた。すると、コーディネーターが Javascript できるインターンのハンサムガイを連れてきてくれた。

f:id:simplearchitect:20180917215434j:plain

一緒にペアプログラミングをしたのだが、一つ衝撃的だったことに、彼はほぼググらなかった。見るとしても、リファレンスか、公式のサイトのみ。それでも、定義だけを読んで、「このメソッドがこのように使えるはずだ」とか言って、さっとプログラムを一緒に作ってくれた。インターンのせいか、彼のコードは綺麗ではなかったが、彼は十分に挙動を理解して、全然サンプルを見ないままコードを一緒に書き上げてくれた。ある一瞬彼が、「どうしたらいいんだろう?」と悩んで、リファレンスなどを見ながら悩んでいたので、私が、自分のブラウザでその時困っている現象をグーグルに打ち込んで検索してブログを見つけて、一瞬で解決した。なぜ彼にそうしなかったのかは聞かなかったけど、彼はそもそもそういうことをするという素ぶりも見せなかった。そういえば他の同僚もあまりググらないし、見ても公式ドキュメントで次にコードという感じだ。

全ては習慣ではないだろうか?

Extreme Programming で著名な Kent Beck は、「私は偉大なプログラマではなく、偉大な習慣を身につけたプログラマ」だ。と語った。つまり習慣は誰でも身につけられる。もしかすると、「定義」vs 「例」、「理解」vs 「動くこと」の違いは習慣で埋められるのかもと思うようになってきた。つまり、英語云々ではなく、彼らは幼少の頃から、「定義」で理解し、「理解」する方法を習ったか、練習してきたから、自然とそうなっているのでは?という仮説で、そうであるならば、「定義」だけを見てゴリゴリにコードをかけるようになるのではないだろうか?という仮説だ。だったら実際に自分で試してみよう。

仮説の検証

仮説に基づいて、次のことを気をつけてコードを書いて見た。自分がまだそんなに慣れていない Go 言語で実行して見た。

  • 可能ならリファレンスのみを見てコードを書く
  • 公式ドキュメントは見ても良い
  • サンプル / ブログの類は見ない
  • 速く完成させようと思わない

この単純な3つの条件をつけて、自分が今までコーディングしたことのないトピックを Go で実装して見ることにした。

実践した気づき

実際にコードを書いて見ると、色々気づきがあった。最初は、例を全く見ないでコードを書くのに不安があった。「早く作る」ことだけを考えると、自分のやりたいことで検索して、ブログを読んで書いてあることを真似するのが一番速い。ただし、この作戦は、その1回限りに於いては確かに速いのだが、本人がちゃんと理解できているか?はとても怪しいものがある。つまりどうなるか?というと、普段の私だと、何かが出てくるたびに、前にやっていても忘れているので、またググって、同じページを見て、同じコードを真似て、実装するという感じだ。確かにコードは出来るのだが、結局速くないし、理解も浅い。

今回の作戦をやって見ると、確かに初回の時間はかかるのだが、定義だけを見て、コードを書こうとすると、深く理解しないと書けないので、しっかりと定義を読むようになるし、コードサンプルがないので、自分の頭で考えてアルゴリズムを毎回考える必要があるので、コピペ作戦がこれまた使えないので、アルゴリズムを書くときに使われるイディオムも深く理解しないと結局遅くなってしまう。すると、2回目似たようなロジックが出てきたときには高速にコーディングが終わったし、サンプルの無いようなコードでもリファレンスだけを見てさっとコードが書けるようになってきた。しかもたった1日で。出来るか不安だったが、やろうとしたら出来るやん!

おおおお!これこそわしの求めていたものや!

実践のポイント

ただし、一つポイントがあって、先ほどの条件にもあった「速く完成させようとしない」というのがものすごいポイントで、他者からも、自分からも、速く終わらせようと思うと、どうしても「ブログ検索」の甘い汁を吸ってしまいそうになる。しかも、「速く終わらせよう」と思ってなかなか終わらないととってもイライラするのだ。つまり楽しく無くなる。「速さ」は、後から付いてくるから心配しなくてもいい。それよりも「理解できていない」ことを恐れたほうが、絶対的に安全だし、スピードも結局上がることに気づいた。

 後、「ヤクの毛刈り」ともいうけど、あるコードを調べているときに、その中でわからないことが出てきて、またそれを調べて、、、起こった時にはどうするか?それも焦らず理解するようにした。作戦としては、調べ物をするときに、ブログを同時に書いて、調べた内容や、自分で作り上げたコードを書いていく。その過程でわからないところが出てきたら、理解してブログに書くようにして見た。これは、先日紹介した、自分の動作を先に書き出してから実践するの応用作戦だ。急ぐのをやめると、コードを書いている過程できになる「ああなったらどうやって書くんだろう?」みたいなものもみんな調べて試すようになってきて、深さも出るようになってきた。

simplearchitect.hatenablog.com

書いていてどうしても解法がわからない時とか、書けるけど多分なんかいい API ありそうみたいな時もある。そういう時は、まず自分の解法で書いてみて、その後、ググってみて、あーこんな API あるんだとわかったら一瞬でブログや、サンプルを閉じて、リファレンスのページを見るようにすると良さげです。

まとめ

サンプルコードを求めて、ググってブログや、Stack Overflow のサンプルに頼るのをやめると、理解が高まり、高速にコードが書けるようになってきたと思う。そういえば日本人の技術イケメンや師匠もあまりやたらとググってなかった気がする。この方法を継続してやってみて、どうなるか実験して行きたい。実際にやっていると、初めのうちは高速なのかわからないけど、確実にわかるのは、完璧に自分でコントロールできている感を持てているということだ。これは自分にとっては大きい。

ちなみにこちらのブログは、初めて、リファレンスのみを見て技術調査をしながら書いたブログだ。単純なものだが、今後もっと複雑になっても、この姿勢をキープしながら継続してみたい。

qiita.com

最近気づいてきた、「日本人」のいいところは、我々は真面目ということだ。平均のレベルは圧倒的に米国に負けているが、トップレベルの日本人プログラマは向こうに行って十分通用するどころか、向こうに行ってもすば抜けていると思う。彼らは、言語やら習慣やらでコンピュータサイエンスは強いけど、私たちほど頑張ったりしない。だから、積み重ねていけば私たちでも世界で十分に活躍出来る素養は十分にあると思うのだ。

メタファーを身につけてプログラミングの生産性を向上させる

インターナショナルチームでプログラミングの仕事をしていると、いろんなところで同僚との差を感じてしまう。いろんな国の人がいて、レベルは人によりそれぞれなんだけど、一般的にいうと、アメリカのプログラマのレベルは平均してとても高い場合が多い。とにかくコードがきれいでシンプルで仕事が早い。

彼らがなぜそれができるのかを観察しているが、一つ気が付いたことについてその対策も含めて書いてみたい。

f:id:simplearchitect:20180722204819j:plain

彼らがプログラマとして優れているところ

USにいるとお客様の技術レベルが高いとか、新しいことにチャレンジするとかいろいろ要素はあるのだけど、個人の生産性、コードの美しさをみても、平均値を観察するとアメリカの人が一番に感じる。その他にも、ドキュメントを見てすぐ理解できる能力は、アメリカの人はおろか、ヨーロッパ圏やインドの人と比べても、私は圧倒的に負けていると感じる。

f:id:simplearchitect:20180722204942j:plain

Williams 衝撃の読解力

新しいライブラリを学習しようと思って、GitHub のページを読んでいると、フランス人の同僚 Williams がやってきて、何読んでるの?というので、それを見せてあげた。 

彼は GitHub のディスクリプションだけよんで、「あーこれはこうこういうことが出来るライブラリできっとこんなコンセプトだよ!」みたいなことを言い出した。彼ももちろんそのドキュメントは初めて見るのになんだろうこの理解力の差は。

 自分だと、ドキュメントを読んで、チュートリアルをやってみて、コードを書いて試してみてやっと大体どんなものかが理解できるというのに。しかも、これは、彼だけではない。私だけ劣っている感じ。

f:id:simplearchitect:20180722205157j:plain

同僚のJavaの世界で著名な寺田さんも言っていたが、これはものすごい差だ。彼らは我々ほどまじめじゃないので、少なくとも私と寺田さんは、この溝を、努力の量で埋めている。

 だけど彼らはもっと楽にそれを成し遂げる。アジア圏の人は同僚にいないのでわからないけど、このあたりは日本人は不利に感じる。

技術力の差は英語力の差

この差がある理由は漠然と「英語力の差」ではないかと思っていた。寺田さんも同じように感じているようだ。

彼らは同じドキュメントを読んでも読み取れる内容が我々とは違っていて、同じ文章を読んでも、明確にそれが何を意図しているかイメージできるのだろう。しかし、これはどうやったら身に着けることができるのだろうか?

英語の勉強して、Proficient とかになったり、海外に長年住んで多読とかをすればいいのだろうか?多分それでもいいのだろうけど時間がかかりすぎる気がする。どうしたらいいのだろう。

Deliberate Practice

私は要領が悪いので、自分の生産性を高めてくれるメソッドを学ぶのが好きなのだが、この前 Deliberate Practice というコンセプトを知った。

www.youtube.com

何かをできるようになるためのメソッドなのだが、最初は凄くゆっくりから、1つのことに集中して練習するらしい。それを試してみようと思って、自分が知らなかった DependencyInjection のライブラリのドキュメントをその方式で読んでみることにした。

docs.microsoft.com

実施したことは下記のこと。

  • ドキュメントを読むときに、わからないと立ち止まって意味を調べる、ゆっくり考える
  • コードを読むときも、わからないときは立ち止まって意味を調べる、ゆっくり考える

ただこれだけ、先に先に行かず、本来なら17分で読める技術ドキュメントを精読してみた。すると、あることに気づいた。

自分は「コード」の意味がよくわかっていないのではないか?

これは、そのコードが「どのように動作するか?」をわかっていないという意味ではない。コードに書かれている英単語の意味が「ふわっと」しか分かっていないのでは?ということに気が付いた。例えば、コードを書いているときによく出てくる「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 のアプリを使っている。

コリンズコウビルド新英英辞典 - DioDict 3

コリンズコウビルド新英英辞典 - DioDict 3

  • SELVAS AI Inc.
  • 辞書/辞典/その他
  • ¥3,000

他にも私がその文書を読むときに調べたよくあるけど、よく意味がわかってなかったものに、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>();

ちなみに、ここでは、シングルトンはこのインスタンスが呼び出されるときに、インスタンスは常に1つ、Scopedは、リクエストが同じなら同じインスタンス、Transient は、呼び出されるたびに新しいインスタンスが作られる。これだと、Transient の意味は上記とマッチしていない気がするが Guid を DI 対象のクラスで生成して、同じインスタンスが使われているかを調べるとどうだろう。Singleton は常に同じ Guidになるし、Scopoed はリクエスト内なら同じ、そして、Transient は、呼び出されるたびに、毎回「違うGuid」になる。つまり、毎回違うインスタンスになる。

短い時間で移り変わるというイメージを持ったTransientの意味と照らし合わせるとこれまたむっちゃわかりやすいネーミングだ。

f:id:simplearchitect:20180722210110j:plain

他の例としても 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 の意味を調べた。どれもこれも、頻繁にコードにでてくるのに「ふわっ」としかわかっていなかった単語の数々だ。

メタファーの意味を20年近くかかってやっと理解する

このように、コードがどのように動作するか?だけではなく、コードで使われている単語を英英辞書で調べることで、相当コードでなぜその英単語がチョイスされているのかが明確にイメージできるようになった。多分これはすっごい重要な事だ、なんで今までやってこなかったんだろう!と思ったが、そんなことはとっくに先人わかってたことで、しかも私もその概念を何年も前に学んでいる。

 それは「メタファー」だ。2000年頃に Extreme Programming に出会ったときに、そのプラクティスの一つとして「メタファー」というのがあって、「クラスの名づけをするときに、比喩を使う。そうすると、ほかの人とその意味合いを共有しやすくなる。」とか書いてあった。

 当時は正直意味もわからなかったし、「そんなん英語圏の人だけ有効なんちゃうかな」と思ってたけど、たぶんこれのことだ。だから、英語が一番できるアメリカの人のコードはきれいなことが多いのか!だから、ネイティブのアメリカ人やイギリス人じゃなくても、単語の意味を分かっている人はいろんな理解が早いのかとかなりの腹落ちをした。

 メタファーってこれやったんか。20年近くたってやっとわかったわ。

最初からスピードアップできないだろうけど、ゆっくりはじめて、手抜きをせずやってるとだんだん早くなってくるんじゃないかと思う。

使われるメタファーの用語を理解しよう

というわけで、今回学んだことは、コードに出てくる単語はそんなに多くないので、自分がふわっとしか理解できていない用語が出てきたら、それを英英辞書で調べるとかなりすっきりするということだ。ツールの名前とかも調べるとよさそう。例えば 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 で昔から発想力や問題解決力はあるのだが、自分自身が何かのスキルを上達することが非常に苦手だ。コンサルとか、エバンジェリストみたいな「人にやってもらう仕事」は得意だが、プログラマとか、ヴォーカリストとか、自分が本当になりたかった職業には何回もチャレンジして何回も失敗してきた。

f:id:simplearchitect:20180701232738j:plain

 遠くから見ていると私は何かが出来てるように見えるかもしれないが、冗談抜きで人の3倍ぐらい時間をかけないと成果が出ない。しかも、中途半端にしか完成しない。だから、土日も常に何か努力していないと不安になる。

 多分私と同じようなADHDの人は、自分的に努力しても何も達成出来ない辛さを感じているかもしれない。過去にも色々試してみたのだが、47年生きてやっと自分でも実施できる対策が見つかったので、同じ様なことで苦しんでいる人のヒントになればと思い久々にこのブログを書いてみた。

「自分で何かを作れる人」が長年の憧れ

大変な偶然なのだが、今は私はエバンジェリストからプログラマになれた。ただ、それは私の実力というより、組織変更でロールが変わったためだった。NEC に新卒で入社した時は、OSのコマンドを担当したいと言ったのだが、配属は営業部門だった。営業活動は全くやる気が出ず、仕事が終わったら、会社に行ってUnixをずっと触っていた。そしたらある先輩が私をSEにしてくれた。

それからもプログラマになる事は心の中で燻っていたのだけど、「自分がやる仕事」は本当に全く出来なかった。仕事だけじゃなくて、スポーツも、勉強も、音楽も、何か「自分が上達する」という事に関しては致命的にうまくいかない。

f:id:simplearchitect:20180701233243j:plain

スポーツも全然だめ。皆勤賞で、6年間やってたバスケは誰より1時間早く来てシューティングしたり毎朝ランニングとかやってたけど、レギュラーどころか、一秒も試合に出れなかった。

風向きが変わって来たのは、オブジェクト指向とか、アジャイルとかをやり始めてから、「コンサル」や「コーチ」みたいなもの、つまり、「人に何かやってもらう」とか、「仕組みを考える」とかは得意な様だった。それからもそういう人生だったけど、自分が本当になりたかったものは、「自分で何かを作れる人」だった。

3倍の努力をいつまで続けたらいいだろう?

今回はたまたま、憧れのプログラマになって、多分会社としては、今はロールが変わったばかりで能力に関しては多めに見てくれているが、私がマイクロソフトに入れる程優れたプログラマではない事は明白だ。このまま、3倍の努力を続けていないと、実力が無いのだからいつクビになっても仕方がない。しかし、「三倍の努力」は生活の殆どの時間を奪う。朝起きて、寝るまで、今はほぼ仕事、筋トレしかやっていない様な生活だ。同僚がバケーションを楽しみながらも、効率よく色々なものをマスターしていくのを横目に、自分は時間がずっとかかり、しかも中途半端。

f:id:simplearchitect:20180701233605j:plain

47年も ADHDをやっていると、こういう事も自分では受け入れている。ないものを嘆いても仕方ないから、別の方法を試すしかない。効果があったものとして、医師に処方されたリタリン。これは現在禁止されている。Lumosity というゲーム(科学的に効果がないと判定されたらしいが、ADHDの自分には集中力を上げる効果があるので今も契約している。)

www.lumosity.com

あとは、それよりも強力なのが、オメガスリーのフィッシュオイル(こちらは、科学的にも効果が認められている)ただし、1日の「ここぞ」というところでそれを飲むので、効果は長くは続かない。

item.rakuten.co.jp

他に BCAA という筋トレで使うパウダーも集中力を保ってくれる働きがあるので、よく使う。朝型にして、仕事の後、運動をがっつりして仕事に戻るという働き方も、物凄くよくて、脳のキレも最高にはなるのだが、ADHDの「達成出来ない」問題は解決しない。しかし、ある日ふとした事で、解決策を思いつた。

item.rakuten.co.jp

プログラミングをしていて気づいた事

先日プログラミングの技術調査をして、サンプルコードを書こうと思っていてパソコンに向った。やりたかった事は、たった1つのAPIの検証。しかし朝7時から初めて気づいたら15時だった。しかも、終わっていない。ADHDの私が昔から何回も体験した感覚。いつもながら自分にがっかりする。自分が知らず知らずに無意識にやってる見積りでは、「2時間ぐらいでできるかな。余裕を持って」だった。しかし、いつも私の考えている見積りは大幅に遅い方に間違うのが普通だ。

f:id:simplearchitect:20180701235324j:plain

XP とかだったら、理想見積という考え方をやるときは、邪魔が一切入らない状態でという条件で見積もりをして、初回は2.5倍する。人はだいたい見積りが下手だ。しかし、私の場合はこの度合いがもっとひどい感じ。

筋トレに向かう電車の中で、なんでこんなことが起こったのだろう?というのをふと考えてみる事にした。今までは、ADHDだからこんなもんと思っていたけど、本人は本当に嫌な事だった。本当に。思い起こしてみると、もっとも大きな問題は「最初に思ったことと、関係ないことを大量にしていること」だった。ちなみに、次点は、「何かを調べているうちに、前にやっていたことを忘れる」だった。

全ての行動をはじめる前に書いてから始める

次の日にやってみたこととしては、やるタスクをリストアップしてから仕事をしてみようと思ったことだった。これは、例えばアジャイルの世界で有名なテスト駆動開発でも、最初にタスクリストを自分の手元の紙に書いてから始めるというのがある。

f:id:simplearchitect:20180701235852j:plain

一定の効果はあるものの、ADHDの自分には「効ききらない」のも過去に試して知っている。しかし、今回は何かをするときに、先に紙に書かないと行動しないと決めてやってみた。

すぐに違うことを初めてしまう事に気づく

すると気づいたのだが、自分はすぐに違うことを始めようとするのだ。それも、「Webサーフィンしてしまう」とか、「Youtubeを見てしまう」とかわかりやすいもの以外が大量にあるのだ。

一つの例として私は、API の使い方を理解して、あるプロジェクトにコントリビュートしようと思った。今日のゴールは、無理せず、APIを調べて、その使い方を理解するためにサンプルを書くことだ。

Task
1. Azure Functions の Function Keys を Golang で取得する方法を調べる

 今回は、Azure Functions の Functions Keys をGo lang で取得する方法を調べたかったはずなのに、APIリファレンスを見ているうちに、次々と違うことが頭に浮かぶ。

  • 「あ、そういえば、次は CORSもすぐ調べないといけないな」
  • 「あ、これ、CORSのAPIだ。」
  • 「この構造体一体なんだろう?」
  • 「コード読んでみよう」
  • 「あれ、このプロバイダって一体なんだ?」
  • 「この文法よくわからないな」
  • 「サンプルプログラム作ってみよう」
  • 「あれ、venderのディレクトリが認識できないぞ」
  • Google で調べてみよう」
  • 「うーんよくわからない」
  • 「さっき何を調べているんだっけ?」

-> 時間ぎれ 

みたいな感じで、一切何も達成できておらず、身にもなっていない。

f:id:simplearchitect:20180701235543j:plain

こんな事だと、いくら最初にタスクリストを書いても効果がないのは当然だ。多かれ少なかれ人にはあるのかもしれないけど、ADHDの人にはこの特徴が顕著なのかもしれない。ADHDの原因として、今有力な説は、前頭葉が不活性で、短期記憶が人より短く、短期に覚えておけるものが少ない→だからすぐ気が散るというものらしいので、そらそうだなという感じだ。

行動する直前にタスクを書く

通常にタスクをリストアップするのは自分には通用しないと悟ったので、次にとった作戦は、タスクをこなしている途中で、「これをしてみよう」と途中で思った事も、まず、その場でタスクリストにまず書いてから、それをやるべきか考えてから、行動するという作戦にして見た。

f:id:simplearchitect:20180702000716j:plain

これは正直めちゃめちゃ有効な作戦だった。途中で思いついた事は、今すぐやるのが「悪い事」とは限らないのだが、今は違う事に集中した方がいい事の方が圧倒的に多い。だから、一旦紙に書いてみると、「あー、これ今しないほうがいいや」と思うことが多い。たまに「確かに今のゴールにはこれはやった方がいい」となる場合もあるけど、前のように、あっちいって、こっち行って何も達成できないとかが激減して、自分が普段見かけた「普通の人」と同じ程度の生産性を出せている。

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の私にとっては「思いつく」-> 「違う事始める」にめちゃめちゃ効果がある。たったこれだけ。

別のサンプル

このやり方をより理解するためにに、私がこのメソッドを「歌の練習」に適用した時の手書きのカオスなタスクリストを公開したい。これをみるとどんだけ気が散ってるねん!という感じがわかると思う。どんな感じだったかをシェアしたい

f:id:simplearchitect:20180701230809j:plain

最初に書いたタスクリストはこれだけだった。

最初の1小節を完璧に歌う
1. あいた喉の状態をキープする
2. 母音、子音のバランスをとる
3. 正しい音程と、音の長さを確認する

もちろん、全部できると思っていないので、1. 2. 3. は優先順位で最悪 1. だけでもいいと思って練習を始める。練習をし始めると、いろんな事を頭が思いつく。突然ウォームアップを歌い出そうとする。ちょっと待て、その前に、書いてから。これは、ゴールに近いのか?と考える。どう考えても違うので、Parking Lot の方に

最初の1小節を完璧に歌う
1. あいた喉の状態をキープする
2. 母音、子音のバランスをとる
3. 正しい音程と、音の長さを確認する
ウォーミングアップする

次に思いついたのが、喉があいた状態をキープするために、テンポを落とした状態で歌ってみる。という事。確かに、これは、最初にやっている「あいた喉の状態をキープ」の練習に有効で今やるべきなので書いてから、今実施。(ちなみに、実際の写真は自分でも字が読めないほどカオスやけど、やってるときは認識している)

最初の1小節を完璧に歌う
1. あいた喉の状態をキープする
 ・ゆっくり歌ってみる(キープしたまま)
2. 母音、子音のバランスをとる
3. 正しい音程と、音の長さを確認する

次に思いついたのが、あー、そういえば、イタリアに旅行に行きたかったけど、まだ予約してないなという事。もちろん関係ないから、パーキングロットへ。もちろん今やらない。

最初の1小節を完璧に歌う
1. あいた喉の状態をキープする
 ・ゆっくり歌ってみる(キープしたまま)
2. 母音、子音のバランスをとる
3. 正しい音程と、音の長さを確認する
ウォーミングアップする
イタリア旅行調査

次に思いついたのが、ヘッドボイス、ミドルボイス、チェストヴォイスをいつ切り替えるかを考えないといけないなという事。これは重要だけど、「あいた喉の状態をキープする事を できるようになる練習」とは違うよな。今しない。

最初の1小節を完璧に歌う
1. あいた喉の状態をキープする
 ・ゆっくり歌ってみる(キープしたまま)
2. 母音、子音のバランスをとる
3. 正しい音程と、音の長さを確認する
ウォーミングアップする
イタリア旅行
ピアノで音をとって、ヘッドヴォイス、ミドルヴォイス、チェストヴォイスの切り替えを確認する

次に思いついたのは、「あー、英語の発音悪いな。母音と子音のバランスを調整しないと聞こえが悪い」しかし、これは書く前に、リストをみると、2でやる事になっているので、今はまずは喉の状態をキープする練習を続ける。

といった感じで、振り返ってみると、これがこの後もずっと続いて「これでもか!」というほど気が散っている。しかし、この単純なリストがあれば、気が散っても、元の目的に戻ってくることができるので、結局この日は、1. はおろか 2. まで達成できた。まじで、人生でこんなことはじめてちゃうやろか!

まとめ

先の例でも、この方法を使ったら、プログラミングの方も超順調で何回も脱線しそうになったり、忘れたりということなく、「達成」することができた。こんなのは人生ではじめて。 この方法がADHDの人の全員に有効かはわからないですが、自分を救ってくれた方法なので、シェアしておこうと思いました。

日本のITエンジニアがイノベーティブでないのは暇じゃないからかもしれない

ここ1ヶ月ぐらいは、海外のメンバーと仕事をしているが、Serverless Hackfest というイベントと、Serverless Conf やワークショップに関わっているので仕事量が増えていった。日本にいることだし、久々に「日本流」のハードワークをしてしまったのだが、一つ気づいたことがあった。それは、ここしばらくの謎だった、日本人のIT エンジニアはなぜイノベーティブな感じがしないのか?ということに対する問いだった。

f:id:simplearchitect:20171029232049j:plain Microsoft Hack week

日本人はイノベーティブ

Rochelle Kopp さんとの仕事で知ったことで、一つとても意外だったことは、アメリカ人から見ると日本人は相当にイノベーティブに感じるらしい。

f:id:simplearchitect:20171029232156j:plain

自分的には、少なくともIT 分野に関しては、向こうの真似ばかりしていて、後追いのイメージがある。私たちも向こうで生まれたツールやサービスばかり使っていて、全然日本から出ていかない。もちろん例外はあるがとても少ない。実際に、米国で働いて見ると、彼らと比べて「人」としての能力に違いはない。日本人のエンジニアでイケてる人にたくさん出会って来たし、向こうは基本コンピュータサイエンスは出ているからベースラインは高いけど、日本のエンジニアでもイケてる人はたくさん現場にも溢れている。むしろ極めているような人は日本の方が多いのではないかとも感じる。ではなぜイノベーティブにならないのだろう。

日本流ハードワークと米国流ハードワーク

自分が日本に帰って来て、久々に、人に言われたからではなく、ついつい仕事をたくさん受けて日本流のハードワークをしてしまった。米国にもハードワークな人も沢山いるが、例えば、「忙しい」というイメージが彼らと違うことに気がついた。日本では忙しいというと、残業は当たり前で、そろそろ休出しないと回らないぐらいのイメージが「忙しい」だが、向こうにいるときは、残業はおろか、定時内にできる仕事量で、しかもそれがだいたい埋まっていたら「Busy」という感じだ。

f:id:simplearchitect:20171029232330j:plain

定時だけを使って、新しい仕事を始められない状態が「Busy」だから、ハードワークな人も、朝も昼も夜もなく働いている人ではなくて、バリューを出すために、たまに日曜とかでも仕事したりするけど、5時に帰るときは帰るし、みたいな感じで、日本みたいな仕事量に追われてパツパツという感じでもない。そもそも仕事量を沢山こなすことが求められないし、誰も喜んでくれない。求められるのはインパクトだ。

simplearchitect.hatenablog.com

余裕があるからイノベーティブになれる

そういう日本流のハードワークを久々にしてみて気づいたのだが、米国にいて仕事をしているときは、毎日5時で終わりで、大量の仕事をこなすのを求められないので、5時の時点で会社の仕事をしなくてよくなる。私は、3流プログラマなので、家に帰ったら、その日に学んだことを自分のためにブログに書いたり、オープンソースのプロジェクトにプロバイダを書いて貢献したりとかしていた。

ところが、日本流ハードワークをやってしまうとどうなるかというと、そんな余裕は全くない。仕事で新しい技術を使ったら、学んだことをブログにしないと身につかない性格なのに、それをしている暇がない、オープンソースに貢献する時間も圧倒的に減った。米国にいるときみたいに、仕事の中で疑問に思ったことを調べて、コードを書いてブログを書くみたいなことをする暇が全くなくなった。つまり、「仕事をこなす」ことをやっているだけだ。

f:id:simplearchitect:20171029232637j:plain Bruno と David と会社帰りにウェイクボーディング

私の仮説だが、米国でも Moon lighting と言って、会社の仕事とは別に夜にソフトウェアのプロジェクトをやるという話があるが、前者だと、十分できそうだが、後者の環境だとそんなことしている体力も気力も相当なものが必要だろう。また、日本のハードワークだと仕事をこなしているだけなので、仕事で学んだことをより深く学んだり、全然違うことを学んだり、プロジェクトをしてみたりという時間が取れない。だから、折角イノベーティブな性質を持った私たちが、仕事を沢山こなすことを求められる日本のIT 業界ではイノベーティブになれようがないのではないだろうか?

よりイノベーティブになるための方策は?

つまり、エンジニアに余裕がないから、イノベーティブになりようがないので、「余裕」ができるようにすればいいということになる。

この問題の対策としては、日本に止まるなら、Rochelle さんと作った8つの習慣みたいなものがもっと広まって、多くの人が違いを「認識」し始めることじゃないだろうか。

simplearchitect.hatenablog.com

それよりさらに良いのは、働き方改革とかの成果を待つより、どんどん転職して海外の企業を体験するのはどうだろう。今まで、「常識」で「無理」と思っていたことが平気で実現されている世界に触れると、「あー、あれって不可能じゃなかったんだ」と思えるようになる。日本では35歳定年説と言われるのに、46歳の私が、今年からSoftware Development Engineer としてコードと再び格闘している。私が得意だった政治的なことは一切していないが、過去最高の給料をもらっている。我慢とか勿体無い。もし、あなたがプロフェッショナルであろうと思うエンジニアであれば、海外の企業とかを一回でもいいので体験するのは本当におすすめだ。

f:id:simplearchitect:20171029232936j:plain Microsoft のオフィスでの風景

良いエンジニアを確保したい会社さんはチャンスだ。他の会社さんが、低賃金で、仕事量をエンジニアに求めている間に、米国みたいな労働環境を提供してみると、エンジニアにとっては日本にいながらそうなれるのは、超魅力的だろう。しかも、そうなると、エンジニアの成長も早く、イノベーティブになるので、海外進出とかではなく、普通に、世界の一員として活躍できるだろう。ソフトウェアは頭脳労働の権化で、早くタイプできる人が必要なわけではない。成果は数や量ではない。コードで如何にインパクトを出すかだ。そのためには、「こなす」ではなく、本当に「理解し、出来るようになる」ことのほうが重要だ。

海外の企業を体験してみよう

 日本では我慢しなければならないものが、全くなく、政治より技術が求められる世界は本当に楽しく、もっとエンジニアリングができるので成長も早い、給料もいい、無理に忙しくないからイノベーティブになれる。

こんな話を聞いたことがある。ある地域のレストランがまずいのは、お客さんが「まずい」と認識していないからで、お客さんが本当に「美味しい」ものを見分けられるようになると、「まずい」ところには誰も寄り付かなくなるので、相対的にレストランの味のレベルが向上するという話だ。それと同じかもしれない。

 どんどんそういう人が会社をやめて海外に流れていけば、日本企業でもITの良い人材を確保するために待遇を上げざるを得なくなるかもしれない。プログラマを出来るだけたくさん働かせたいと思うような、労働条件の悪いところで働かなくなるかもしれない。少なくとも、世界が変わるのを待ってるより自分が幸せな方がいいし、もしかするとそっちの方がより日本のためかもしれない。

アジャイル開発の導入のビデオシリーズを作ってみた

今年から会社の方針も変わり、エバンジェリストからSoftware Development Engineer という職種に変わった。プレゼンとデモの世界から、お客様と一緒にハックしたりコードで世の中にインパクトを出す仕事に変わったので、楽しくも四苦八苦しながら頑張っている。

f:id:simplearchitect:20171015141700j:plain

先日友人の Rochelle Kopp さんから Agile のビデオを作ってくれないか?という依頼があった。今から Agile を始めたいと思っている企業さんが増えてきたのだが、残念ながら私はコードを書くのが`今の仕事なので、エバンジェリストやコンサルをやっているときのように対応できない。出来るとしたら、自分が新技術導入 (Serverless, Microservices等)をご支援しているプロジェクトに限られる。 だから、彼女がビデオを作ってくれたらうれしいといったので、既存の資料を少しカスタマイズして、ビデオをいくつか撮ることにした。ビデオでは、インタラクティブにお話しできないので、どこまで皆さんのお役に立つかはしらないが、クローズにするよりは、とりあえずシェアしてみようと思った。

 現在プログラマとして米国の開発プロジェクトに参画したりするなかで、学んだ内容などももりこみながら、アジャイルの全体像と、日本で多くの人がアジャイルの世界にはいってくるときに、「なんでこうなるんだろう」と疑問に思いそうな部分に関してお話ししてみました。

プレゼンテーション

アジャイルの全体像 (17:22)

背景とか、全体像のお話し

アジャイルの考え方 (43:42)

アジャイルの考え方で日本人的にしっくりこないと思われる部分の解説や、本を読んだだけで実行したら誤解しそうな部分についてのお話し

simplearchitect.hatenablog.com

simplearchitect.hatenablog.com

アジャイルプラクティス (27:47)

アジャイルの具体的なテクニックをいくつかご紹介。ただ、これだけですべてカバーできているわけではないので、是非次はアジャイルコーチを呼んで実践を。やる前からたくさん学んでも、頭にはいらないので、全部学び終えようと思わず、この程度の知識を得たら、やったことがある人と、すぐにやり始めるのがいいと思います。

Q&A (26:47)

よくあるQ&Aに対して回答してみました。本来はお客様や状況によって違うのですがビデオなので、ありがちなシナリオについてコメントしてみました。

次の一歩

この程度の情報を得たら、まずはやってみることをお勧めします。まずお勧めのステップは、上層部を巻き込んで目的を明確にしたのち、アジャイルコーチを連れてきます。次に、誰もアジャイルをやった人がチームにいないなら、アジャイル開発がバリバリできるプログラマをつれてきて、小さくてもいいからチームをつくって、そこで、濃度100%の妥協なしアジャイルチームを実際にやってみるのをおすすめします。

技術なきマネジメントの衰退とその対策

今回は、マイクロソフトにいて自分が感じているIT業界の大きなスタイルの変化の兆候とその対策について書いてみた。今回もいつも通り、単に自分の意見をシェアしているだけであって、他の人にどうこうしろと言いたいわけではない。ただ、日本のIT業界が米国に追いつき、追い越すための議論のきっかけになるといいなと思っている。自分も楽しみながらも、もがいていることと、そこで見えた光について書いてみたい。

f:id:simplearchitect:20170618224052j:plain

世界は「技術力」の重視に向かっている

 私のキャリアは、某大手SIerを12年勤めた後、ITコンサルティング企業に3年在籍して、主に超上流を実践した。その後独立し、ビジネスモデリングから、アジャイルや、DevOpsの導入支援、マネジメント、開発などを実施していた。

 私がマイクロソフトを受けてみようと思ったのは、友人からの推薦の要素が大きかったのだが、その背景では、海外で勤務したいという希望があったのと、「技術力」を磨きたいというのがあった。ラッキーなことに、海外転勤ではないものの、インターナショナルチームエバンジェリストというテクニカルな仕事ができているので大変幸せだ。

 なぜ当時「技術力」を磨きたかったかというと、私は、アジャイルや、DevOpsの導入、超上流の技術をはじめとして、「人」系の技術を磨いてきたので、アジャイルのような新い考え方を日本に導入するということに関しては絶対の自信もあったのだが、プログラマとしての技術力は、過去のキャリアを見てもらっても分かる通り、正直3流だ。

技術力がないのは何となくやばい

 お客様と接している時に、ふと「このまま技術力」を磨かないと将来やばいとぼんやりと不安に思っていた。特にクラウドコンピューティングが普通になってきた頃から、そろそろやばいという感覚があった。しかし、私にはキャリアがないし、大手SIだったので、そんなにガッツリ自分で開発もしていない。今はいいけど、近い将来やばいんじゃないか。だから、ガチのプログラマとしては通用しないと思うので、プレゼン力とか、トランスフォーメーション力がとても有効で、しかも技術力も成長できるDevOps のエバンジェリストの職はまさに私が求めていたものだった。

f:id:simplearchitect:20170618225239j:plain

たった1年で起こったマイクロソフトのトランスフォーメーション

 最初の1年目は私はとても良い成果を出すことができた。皆さんのご協力、そして持ち前のトランスフォーメーション力もあり、とてもいい事例も作れた。プレゼンも神のようなレベルの人に直接教えてもらえて上達したし、プレゼンの評判もありがたいことに、とても良かった。当時のエバンジェリストの評価は色々あったが、最重要の指標の一つは、プレゼンなどを実施した時の「顧客満足度評価」の指標だった。技術力は、人前で話をしたり、デモをしたりというレベルで良かったので、頑張って学んで実践していれば、対応することもできた。ところが、技術のデモやプレゼンをして人々に、新しい技術を広めるという「エバンジェリスト」の職業は、たった1年でまるっきり評価基準が変わったのだ。

ハックフェストと技術力がエバンジェリストの世界を支配した

 期が変わると、評価基準が一転した。プレゼンや、「顧客満足度評価」はもはや、エバンジェストの評価としては、ほぼ意味がなくなり、お客様のところに行って、ハックフェストというイベントを実施して、最も難しい問題を「コード」で解決してくること評価に変わった。ハックフェストは、3−5日で、お客様の環境でガチでコードを実装したり、自動化したりするようなイベントだ。そして、例えば、世界で誰も解いていない問題を解いたり、オープンソースにコントリビュートするようなことが「インパクトがある」という考え方に変わった。  これはとても大きな変化だ。開発者ではないので、マーケティングのような技術者のような中間のセンスが要求されたエバンジェリストは、そこまで正直技術レベルを要求されなかった。ところが、この方針では、かなりのテクニカルスキルを要求されるようになる。プログラマとして3流の私は死ぬ気で頑張るしかない。

米国のハックフェストで感じていたレベルの高さ

 日本では、正直なところ、新しい技術や方法を導入するためには、技術力というよりその前にステークホルダーの人をうまく巻き込んだり、モチベートしたりといった「技術以外の要素」が実際に技術を導入する前に必要とされることが多いように感じる。私はそういうのがとっても得意だ。だから、日本では活躍ができた。

 ところが、米国で先の「ハックフェスト」を実施すると、様子が日本と全く違うことに気づいてきた。お客様のレベルが平均的レベルが非常に高い。

 日本でハックフェストをやると、例えば、最初の数日は、新しい技術のハンズオンみたいな感じになる。だから、達成できることもあまり多くないことが多いが、米国でのハックフェストの場合、お客様は、チュートリアルはおろか、新しい技術でも、すでにガンガンに本番に適用していて、基本的なことはみんなわかっていて、実際使っていて、その上で、「難しい問題」をお客様と一緒に解決することになるので、インターネットで探しても解決しない「世の中で未解決」の問題に向き合うことになる。

f:id:simplearchitect:20161202162159j:plain

米国では、「技術以外の要素」の重要度は低い

 日本では、このような「ハックフェスト」を実施する前に、たくさんの準備、訪問、説明などような「種まき」が必要だが、米国だと、「お客様」の方からリクエストが来るので、日本で必要な「技術以外のこと」があまり必要なく、「技術力そのもの」がお客様に求められる。

 また、入門レベルのことも、米国の場合はお客様が自分で勝手にやってくる。世の中にチュートリアルや、ビデオは散々あるのでそういう情報は、ハックフェストの場では、我々に特に求められない。これに関しては「英語」のハードルも違うかもしれないし、向こうの人は、基本的にコンピュータサイエンスを出ていることも関係しているかもしれない。だから、プレゼンとか、デモとかの重要度が下がって、「ガチの問題を一緒に解決してくるれる技術イケメン」への需要が高まっているのもうなづける。現にマイクロソフトの本社の「//Build」で多く発表しているのは、プロダクションチームが多く、エバンジェリストではない。(ただ、キーノートのデモとかは、エバンジェリストが作っていたりする)

f:id:simplearchitect:20170618230921j:plain

マネージメントスタイルの違いと技術

 マイクロソフトに入ると、そもそも「コードが書けない」マネージャは、少なくとも私の上には存在しなかった。当たり前かもしれないが、技術のプロジェクトをやるのに、技術がわからなければマネジメントもクソもない。だから、彼らと話をしても、「あー、技術わかってないねんなー」とか「勘違いしてはるわ、、、」と言う場面に全く出会ったことがなく不思議だった。日本ではそんな場面はしょっちゅうなのに。だから、会話もすごくかんたんで、日本で必要な「上司の説得」みたいな場面は必要ない感じだ。

 また、このブログでも触れているように、少なくともマイクロソフトでは、「サーバントリーダーシップ」というマネジメントスタイルが主流だ。チームを「管理」するのは「チーム自身」そして「個人」が実施するので、彼らを「信じて」「任せる」スタイルだ。彼らが困っている時は、マネージャが、サポートしてくれる。だから、マネージャが指示を出すようなマネジメント方法ではなく、チームが考えて、チームが問題を解決して、マネージャがそれを支援するようなスタイルだ。

 この方法は、生産性的に細かい管理が不要になり、意思決定が高速化するので、圧倒的に高く、メンバーもモチベーションも高くなる。だから、マネージャも、我々をリーディングしてくれたりサポートしてくれるだけではなく、メンバーと一緒になってハックフェストをしたりする。リーダーシップではなく、「管理」だけする人はもはや不要だ。

simplearchitect.hatenablog.com

さらなる技術シフト

 マイクロソフトエバンジェリストチームに入るとさらなる「技術シフト」を感じる。先日も、HackWeekという、本社のエバンジェリストがいろいろなものをハックするイベントが開催されたが、その時に、エバンジェリストの長が発した言葉には驚いた。「マネージャであっても、全員L3を取ること」L3というレベルは、お客様の所で、ガチのプロダクションに使えるソリューション(コード)を書いて貢献すること。という意味だ。つまり、日本でいうと、部長も課長も全員お客様の所でコード書いてバリュー出せるレベルになりましょう。ということだ。

 そのエバンジェリストのトップ(日本でいうと事業部長クラス)は、さらに、そのHackWeekで自ら、CosmosDBなどのハックに参加して、彼自身が時間をとってハックをしていた。

 技術の進展はめまぐるしい。だから、少なくとも米国では、マネージメントであっても、最新の技術をハックしていないと話にならない時代が来ているということだ。もちろん米国にも、プレゼンや、デモが強く、そんな技術力が高くない人もまだいるだろう。去年変わったばかりだから。しかし、急激に、マネージャであっても「技術力」のある人が求められているのは間違いない。

 これは、実は米国では顕著だが、日本でも始まっている気がする。だって、そうでないと、これから、自動翻訳もできて、海外との言語の壁が少なくなると、日本マーケットに、そういう技術力が高い人が押し寄せて勝負をすることになる。

simplearchitect.hatenablog.com

そんな時に、どうやって効率が悪いことをやって勝てるのだろう。

f:id:simplearchitect:20170618225748j:plain

じゃあどうすればいいのだろう

 私のように、SIer出身で、若い頃からPMとかコンサルとかやっていた人はどうしたらいいのだろう?自分の当面の目標は、「世界のどこにいてもご飯が食べられるスキル」を身につけることなのだが、私のスキルは、「日本」にのみ特化している。他では現在のままでは食べられない。ポイントは「技術力」だ。これさえあれば、多少英語がしょぼくても、米国でも通用する。

 しかし、現状の技術力を鑑みると、そもそもこの業界を諦めた方がいいのだろうか、とか色々考えた。今は、マイクロソフトを首になるまで、エバンジェリストとしてスキルアップをひたすら頑張るしかないと考えて、なんとか頑張っている。しかし、私は本社メンバーの仲間に比べると、まだまだなので、いつ首になってもおかしくない。もしかすると、多くの日本のマネージャの人も、薄々技術力が必要になることはわかっていても、何十年もコード書いてないし、新しい技術はバンバン出てくるしどうしたらいいのだろうと途方に暮れているかもしれない。私も似たような感じなので、このギャップがここ数年の私の最大の悩みだ。

 プロダクションコードを何年も書いている人に渡り合う為には、自分でチュートリアルをやって、本を読んで自習したところで、到底及ばないだろう。しかし、技術なき人に明日はないと感じる。

Mob Programming の衝撃

 しかし、私は、その解決のための一つのヒントを得た。それは、Mob Programmingだ。Mob Programming はチーム全員が同時に、同じ場所で同じコンピュータを使って同じことをする。1台のコンピュータとプロジェクタ2台を用意して、全員で、1台のコンピュータをシェアして、メンバーがドライバーと呼ばれるキーボードを入力する役とそれ以外の人がどういうコードを書くかを議論するスタイルだ。

f:id:simplearchitect:20170618224052j:plain

 ペアプログラミングを知っている人は、それをチームでやった版だと思うだろう。だから、私も、最初はあまり興味がなかったのだが、実際にMob Programmingを体験したら世界観が一変した。これはものすごいメソッドかもしれない。アジャイルがプログラミングの世界を変えたように、このメソッドがまたプログラミングのやり方を変えるかもしれない。下記のスライドは、楽天の及部さんが発表したスライドでMob Programming とその実際がよくわかる資料なので共有したい。

次の動画は、Mob Programming の提唱者であるWoody の講演

Mob Programming のメリット

 Mob Programming はチーム(たぶん4−5名がベスト)全員で1台のPCなので、従来のマネージャなら、効率が悪いから絶対認めないスタイルかもしれない。しかし、実際にやってみると、むしろ「効率が良く」感じる。よくよく考えると、プログラミングをしていて、最も時間がかかるのは、「悩んでいる」時間だ。何かにどハマりするとか、初めての事、難しい事をやるときに、理解するのに時間がかかるとか。それがMob Programmingでやると、いろんな人が寄ってたかって、いろんな目線で解決を考えるので、詰まったり、ハマったりする事がなく、異常に早く終わる。ペアプログラミングも良かったが、その時とMobとの最大の違いは「心理的安全」かもしれない。

心理的に安全を感じること

 プログラミングをやる時に、現在では毎日のように「未知の技術」に向かわないと いけない。新しいことを覚えて熟練して使えるようになるには時間がかかるし、知らない技術をやらないといけない時は、自分にできるだろうかとか不安になる。先の及部さんと、ラッキーなことに、Mob Programming を体験させてもらえる機会を作っていただいた。

 Mobに最初に参加して衝撃だった一言がある。4人ぐらいのMobを常に実践しているチームがいて、彼らが、PHPを書いていた。彼らが、「Mobに加わりなよ!」って言ってくれたのだが、私は「わしPHP一秒も書いたことないねん」と言った。本当にそうなので。とても、貢献できると思えない。 

ところが彼は、「あー、この前〇〇の会社さんが来て、Mobに参加してコードかいて帰ったけど、彼らもPHP知らんけど、コード書いて帰って行きました」言っていた。

知らない言語でプロジェクトにいきなり貢献する衝撃

 自分が何も知らないチーム、そして知らない言語で構成されたプロジェクトに参加して、初日からコードを書くなどというのは、想像もできないが、Mobではこれが発生するようだ。しかも、続けて彼は言った。

そもそも、俺も、PHP初めてなんですよ」

えーーーーーー!彼曰く、

「Mobだと自分が知らなくても、他の人が知ってたらなんとかなるので、とっても気楽ですね」

 結局私もその日Mobに参加して、コードを書いて帰って来た。コードを書いている時も、不安が何もなかった。だって、自分が知らないこと、遅いことも、他の人がカバーしてくれるし、わからなかったら全員で調べてくれるので早いし、たとえつまづいたとしても、「あー、わからないの俺だけじゃないんだー」と言うことがわかる。つまりむっちゃくちゃ安心感があるのだ。だから、1日終わると、しっかりバリューもでるけど、すごく幸せて楽しい気分で帰ることができた。

Mobの効果はそれだけにとどまらない。

問題 vs 私たちで、問題をフルボッコにする

Mob Programming を実施するとかなり心理的に負担が少ない。今までは自分が初めてのテクノロジーに触れるときは慣れないので、最初に相当ハマることは覚悟しないといけない感じだが、Mob Programming でやると、触れたことのない新しいテクノロジーも全然怖くない。自分のチームに誰か知っている人がいたらものすごくスムースに新しいことを学べる。全員その技術をしらなかったとしても、「あー、知らないのはわしだけじゃないんだ!」と気楽に取り組める。それでも一人でやるときよりよっぽど早いし、ストレスもない。

 なんでかなと考えると、普通の問題だと、一人でハックをしているときは、問題1に対して人間1で1対1の勝負をしている感じだが、Mobだと、問題1に対して例えば人間4なので、問題をよってたかって、フルボッコという感じなので、大抵の問題はボッコボコにできる。

何より楽しい

私は、楽天さんで、Mob Programming を常に実践しているチームがあり、そこにお邪魔させてもらって数回体験させてもらった。理屈抜きに最高に楽しかった。マイクロソフトに帰ってからも、先の「ハックフェスト」を実施するときに、Mob Programming でやってみましょう!と提案してみた。お客様と、マイクロソフトエバンジェリストと Mob Programming をやってみた。最高に詳しいエキスパートがいたこともあり、私が初めてのXamarinの開発であっても、コーディングに参加することができたし、挙動やアーキテクチャもずっと楽に理解できたし、ディスカッションもすることができた。他のメンバーも、Mob Programming を実施して本当に楽しかったという話をしてくれていた。最後にお客様から聞いたハックフェストの感想でも、Mob Programmingへの絶賛にあふれていた。楽しさは、正義だ。

f:id:simplearchitect:20170618230241j:plain

暗黙知を共有できる

 次に暗黙知の共有だ。通常の技術獲得の時に、本を読んだりチュートリアルをしたりすることでは得られない部分が実際のプロジェクトで活躍するためには重要だ。ちょっとした「思考回路」だったり、「ツール」だったり、「ショートカット」かもしれない。どういう習慣で、開発をして、名前をつけて、どうやってコミットログをつけるか。

 これらの形式化できない「暗黙知」は通常自分が長年かけて積み重ねて、得られるものだけど、Mobだと、他人がどのように、考え、行動するのかを共有できる。これは体験してみないとわからないかもしれないが、相当協力だ。普通こんな機会はない。凄く技術的に優れた人がどういう考えで、どういう手順でコードを書くのか。これを共有できることは、チームのレベルアップの上でも最強だ。

詳細な管理が不要になる

 さらに、マネジメントの観点でも革命的なことがある。先の Mob Programming を実践し続けている楽天チームのメンバーが語ってくれたことだが、「タスクを管理する必要がない」なぜなら、常に一緒に作業をしているので、他の人が何をしているか?という情報交換や、シェアの時間が必要ないのだ。この工数はバカにならないし、伝わらない。それぞれがやったことを「レビュー」しなくても、そもそも常にレビューしている感じだから、そんなことも必要ない。

 彼らの壁にタスクKanban が張り出されていたが、「それはもう使っていない。Mob をやり始めてからいらなくなった」とのことだ。これって、実はものすごい事じゃないだろうか?もう細かい管理など必要ない。アジャイルやDevOpsの時代からすでに不要だったが、それを上回るほど管理が必要なくなってくる。

マネージャが本物の技術スキルを身に着けるためにも Mob をする

 Mob Programming はチームのためであり、マネージャのためのものではない。ただ、チームが Mob Programming に移行すると、私や、今まで技術をあまりやっていなかったマネージャで、本当に技術を今から身に着けたいと思っている人にも最高の仕組みだ。

 今まで自分が「管理」していたチームが Mob Programmingに移行して、自分が指示するかわりに、チームが全員で意思決定して、Mob Programming を実施すると、細かい管理は不要になる。その工数をどうしたらいいかというと、リーダーシップと、自分もMobに参加するようにしたらいいのだ。

 例えば、技術を本気で学びたい人がいたとしたら、自分で本を読んでコードを書いたり、チュートリアルはやるだろう。しかし、それでも「プロダクション」のコードに対応するためには、「現在のアーキテクチャによる本番でコードを書いて運用する経験」が必要になってくる。これは「独学」では体験できないし、体験したければ、技術力を身に着けるしかなく、卵が先か、鶏が先かという話になってしまう。

Mob Programming が日本の技術力不足を解消するかもしれない

 しかし、Mobであれば、自分で勉強は必要だが、Mob Programming に参加できれば、かなり心理的障壁低く、本物のプロジェクトに参加することができ、今の技術でどういうコードを書けばいいかも理解できるようになる。しかもかつてないほど参加への障壁が低い。日本では私含めて、実際こういう人がとても多いと思う。やる気は必要だが、そういう人が仕事をしながら「技術力」を身に着けるための、最高の方法なのではないかと思う。そして、自分のチームの技術を理解できるのだから、リーダシップを発揮したり、チームを助ける際も的確な行動がとれるようになるだろう。簡単ではないが、日本がソフトウェア技術的にも優秀になるためのチャンスがここにはあるのかもしれない。チームからしても、一人モブに加わったからといって生産性を損なうとかないので、この目的で考えると最高のツールだと思う。

simplearchitect.hatenablog.com

おわりに

私も今後は、楽天さんで教えていただいた Mob Programming をより実践して日本が、自分が世界でも勝てる方法を継続して探っていきたい。メソッド屋としては、最高にワクワクする方法を体験できて最高に幸せだ!是非皆さんも試していただきたい。

 私、もしくはマイクロソフトエバンジェリストのメンバーと、世界で誰も解いてない問題を、Azureで解決したいと思う方は是非私とハックフェストをMob Programming の形式で実施して、その威力を味わっていただきたい。楽天の先ほどのメンバーは現時点で日本最高のMob実践チームだ。NECの方面でも実践しているチームがあると聞く。皆様も是非 Mob Programmingの威力を実感していただきたい。Mob Programming でこの業界を変えよう!

新技術導入を米国並みに!働き方を変えて生産性を高めるための8つの習慣

クロスカルチャーの専門家のロッシェル・カップさんと共同でマイクロソフトの投資の元作成した「働き方を変えて生産性を高める8つの習慣」だが、動画シリーズが完成したので、各習慣の動画をここで整理しておきたい。楽しんでもらえる内容になっているので、是非楽しんでご覧ください!また、すべての項目について、私が過去にこのブログで書いた、各習慣に関するポストへのリンクを整理しておいたので本ブログの集大成になっている。

f:id:simplearchitect:20170212213702j:plain

元々本シリーズは、日本でも、DevOps や Agile を米国並みに実践したいという考えから考察されたものですが、働き方を変えて変化対応性と、生産性を向上させるためのもので、どなたにも楽しんでもらえる内容になっております。早速各習慣のビデオをご紹介させてください。それぞれ10数分以下のサイズになっています。

序章:イントロダクション

8つの習慣をなぜ作成したのか?どういう効果があるのか?ということについて解説しています。

私が8つの習慣を作成するにあたり、感じたこと、思ったことはこのあたりのエントリに起因している。

simplearchitect.hatenablog.com

simplearchitect.hatenablog.com

simplearchitect.hatenablog.com

次からは、各習慣についての動画をリストしておきます。補足のブログや動画へのリンクをつけておきます。またブログの最後に動画で使用したプレゼンテーションをつけておきました。

第1の習慣 Be Lazy

simplearchitect.hatenablog.com

simplearchitect.hatenablog.com

simplearchitect.hatenablog.com

第2の習慣 リスクや間違いを快く受け入れる

simplearchitect.hatenablog.com

第3の習慣 不確実性を受入れる

simplearchitect.hatenablog.com

simplearchitect.hatenablog.com

第4の習慣 サーバント・リーダーシップ

サーバント・リーダーシップに関してはもう一つビデオがあります。従来は、通常のマネジメントをしていたマネージャが、どのようにサーバント・リーダーシップに変わっていったか、恐れは、そしてその効果やトレードオフについての体験をインタビューしたビデオがあります。こちらもよろしければご覧ください。

Takahiro Kaihara さん、 Mitsunori Seki さん、撮影ご協力ありがとうございました!

simplearchitect.hatenablog.com

第5の習慣 セルフマネジメントチーム

simplearchitect.hatenablog.com

simplearchitect.hatenablog.com

第6の習慣 従業員への信頼

simplearchitect.hatenablog.com

simplearchitect.hatenablog.com

第7の習慣 個人の自信

simplearchitect.hatenablog.com

simplearchitect.hatenablog.com

simplearchitect.hatenablog.com

simplearchitect.hatenablog.com

第8の習慣 階層関係のパワーバランス

simplearchitect.hatenablog.com

プレゼンテーション

おわりに

西洋文化インストールという8つの習慣は変化への対応や、生産性を高めるための習慣を、マインドセットとして整理できたと思っております。是非楽しんで学んでみてください。ロッシェル・カップさん、本当にご協力ありがとうございました!皆さんの生産性が向上しますように!