メソッド屋のブログ

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

アメリカで、ソフトウェアエンジニアの日本人がインパクトのある仕事をする方法

アメリカに移住してもうすぐ4ヶ月ぐらいになるけど、こちらに来てから面白いほど成果が出ていない。

f:id:simplearchitect:20190327181937j:plain

最初の2ヵ月ぐらいはなんやかんやで仕事にならんやろうなと思っていたから、気にもしなかったが、そろそろ4ヵ月なので、流石に焦りを感じて来た。何一つ仕事が完了しない。日本で仕事をしていた時はこんなことは発生しなかった。こっちの方が一緒に働いている人が同じタイムゾーンだし、近いし、やりやすいはずなのに何故だろう?焦っていても何も改善しないので、直接仕事をしているクリスと、日本人エンジニアの先輩の河野さんに話を聞いてみた。自分の会社限定かもしれないけど、学んだことの記録と、もしかすると誰かの役にたつかもしれないから書いておこうと思う。

仕事が完了しない焦り

何だろう、この仕事の完了しないっぷりは。いくつか、終えたらインパクトがある仕事があるのだが、これがまた完了しない。一緒に働いているエンジニアの人はみんな超絶忙しい感じで、声をかけるのも気を使う感じ。だから、何かのブロッカーの質問があったとしたら、彼らにメールなり、メッセなり、PRのコメント欄に書いたりするのだけれど、全く反応がなかったりすることもしょっちゅうある。自分のPRのコードがイマイチだからダメなんだろうか?それとも単に忙しすぎてみる暇がない?そもそも反応がないのだからどうしようもない。

f:id:simplearchitect:20190327175641j:plain

でも、その質問がクリアされないと前に進まないしどうしたらいいんだろう?いろんなことがそんな感じで止まってしまう。勝手に先に進める?しかし、大きな手戻りが発生する可能性が高い。しかも、日本と違って、仕事は勝手に降ってこない。自分でゲットするもののようだ。誰かがインストラクションしてくれたりするわけでもない。そんなものと思ってやってたけど、ここまで成果がでないと焦って来た。

インパクトが停滞する

そんな折、私が2ヵ月ぐらい使って分析して、インプリした大きめの機能追加があって、それがマージされると結構なインパクトだし、貢献と思うのだけど、それはまだだ。というか、レビューもしてもらっていない。アポとってデモした時は、結構好評だったように感じて、次はPRレビューすると言ってたのに、しばらくしてもするそぶりがないので、何度かメールを送ったり、PRにメンションしたりするけど、反応がない。どうしたらいいんだろう。しかも別のドキュメント系の仕事も、あるアーキテクチャのディスカッションのポイントが合意できないと、書いても意味ないので、自分には時間があるのに前に進めない。先ほどのPRも何か一つでも反応があり、不満な点があれば速攻で対応する準備があるのに無反応だから何もしようもない。どうしたらええのよ。こんなの日本ではありえない状態やわ。しかし、これ以上プッシュしたら流石にうざいだろう。もうどうしたらいいのかわからない。

f:id:simplearchitect:20190327174551j:plain

とあるイケてるエンジニアのスムーズな仕事ぶり

そんな折、私よりよっぽど後にムッチャ難しい機能に着手しためっちゃイケてるエンジニアがいた。彼は、私たちの前で、初めて1週間ぐらいでさっと最初のデモを作り、毎週、更新しては、みんなに見せて来た。正直めっちゃカッコいい機能。次のリリースの目玉のような機能だ。そして、1ヵ月ちょっとぐらいで、着想からからのでっかいPRはマージされた。もの凄くスムーズだった。彼が超優秀というのもあるし、この機能だったらみんな夢中で、優先順位上がっているというのもあるけど、たった一人でめっちゃスムーズにインパクトを出した。なんて優秀な人なんやろ。

f:id:simplearchitect:20190327182212j:plain

クリスにフィードバックを聞いてみる

多分自分の仕事の仕方に問題があると思ったので、仕事をしている相手のクリスに話を聞いてみることにした。自分の仕事の仕方に問題があるからフィードバックをくれないかと言って時間をもらった。意外なことに、私の仕事の仕方には問題がないというので、私は、反応がなくて困ってて、たとえ今無理でも、何時頃に時間取れるとかそんなことだけでもわかったらええのに、それすら難しい、これ以上ピングしたら日本人的には、失礼だと思ってしまうという話もした。すると彼は、それは多分みんな忙しくて、単に時間がなくて後回しになって忘れているだけやと言ってくれた。彼のアドバイスでは、メールでダメなら、メッセでピング、それでダメならこちらから会議を設定、それでダメなら直接乗り込んで、話をすると。なんやそれ、大阪のおばちゃんのような厚かましさやんけ、、、でもそれでええらしい。ただし、相手に尊敬を持って。そんなもんらしい。日本ではあんまし相手がたまにメール見落としてるとかあるけど、もう一回ピングしたら無視されるとかは普通無いからそれは凄い違いだ。クリスは、自分が相手であってもそうしてくれたら良いよって言ってくれた。

f:id:simplearchitect:20190327180320j:plain

日本人の河野さんにも聞いてみる

たまたまクリスと同じビルに河野さんがいて、さっきちょっと話したので、「そうだ河野さんに聞いてみよう」と思い立って、少し時間をいただけませんか?とメッセをしたら程なくしたらカフェテリアのコーナーに来てくれた。私が、上記のような事に困っているというと河野さんはいくつも重要なアドバイスをくれた。河野さんはとても優秀な人で、私の会社でも製品的にも、技術的にも、チーム的にも中核の最高のチームでずっとサバイバルしている、つまりめっちゃ優秀な人なんだけど、これまためっちゃいい人で、日本でも凄くいい講演をされていて記事にもなっている。河野さんに聞いたら何かいいヒントが得られるんじゃ無いか?と思って藁にもすがる感じで聞いてみた。

logmi.jp

日本人を捨てる事

全く意外な事に、河野さんも、今ぐらいの頃私と全く同じ問題で悩んでいたらしい。当時の彼の上司のトルコ人に河野さんが相談したら、以外にもトルコの文化は日本と似ていて、控えめな文化なので、「俺が、これやりました、見てみて!」みたいな事をしないらしい。そんな彼が、USに来てから、トルコ人である事を捨てて、アメリカ人のように振る舞うようにしたらしい。日本人の自分ならきっとやらないような、「俺これやった!見てみて」「俺これやらんといけ無いから、時間作って」みたいなことをガンガンにやるようになったらしい。河野さんもそれを聞いてそういう風にするようにされたらしい。ただし、それがちゃんと出来るには3ヵ月ぐらいかかったともお話されていたので、そんなに直ぐには日本人癖は抜けないのだろう。常時大阪のおばちゃんレベルの厚かましさになることから始めよう。

f:id:simplearchitect:20190327180616j:plain

コミュニケーションとビジビリティ

河野さんに褒めてもらったのは、私が毎週プロダクトチームの定例に参加していること。これは、コミュニケーションの面でもいいことだけど、ビジビリティにも良いと教えてくれた。他の人に自分が何をやっているのかを見せないと、誰もそれに気づかない。だから、相手に自分が何をやってるのか見せるのが重要で、そしたら気づいてもらえる。スクラムのイベントとかも、ビジビリティをあげる効果があるという話もされていた。自分的にはコンサル時代から「価値を出したら、それを見える化しないと行けない」と言われていたのでその概念は直ぐに理解できたけど、純粋なソフトウェアエンジニアの世界でもそれは同じという事を教えてもらった。

f:id:simplearchitect:20190327181857j:plain

周囲と比べず、周囲の人をリソースと考える

次に教えてもらったのが、周囲の人をリソースとして考えるという考え方。周りの人は物凄く優秀な人が多い。本当にスーパーマンのよう。しかも英語とか読んで理解するのも自分より何倍も早い。だから、正直自分はガチでダメやなとしょっちゅう思っていたけど、河野さんも最初は同じだったらしい。比較したら落ち込むだけだ。だから、昨日の自分と比較して、成長しているかだけを考えて、周りの人はリソースだと思って、わからないことは質問しまくる。

仕事は降ってこない。自分で作る

次の問題として、仕事が降ってこない問題がある。日本の場合は、マネージャとかいるので(こちらにもいるが)仕事は基本的に降ってくる場合が多い。自分は能動的に動くほうだが、それでも、基本的にミッションとかあって、達成することが明確であることが多い。ところが、こちらのソフトウエアエンジニアリングでは、自分のスコープぐらいは決まっているかもしれないけど、仕事は自分で作らないと無い。ゼロ。だから自分で動いて、なんか作ってみるとか、貢献してみるとかしないと行けない。だから自分が作っていいと思ったものは、どんどん周りの人に見せていく。もし、何人かが、あまり興味なかったとしても、さらに他の人にもデモしてみたりする。リンクや動画を送っただけではダメで、目の前で時間をもらって、俺これ作ったぐらいすると、誰かが興味を持ってくれるかもしれない。  そんな事をしていて、周囲にも聞きまくっているうちに得意分野が出来てきて、だんだん忙しくなっていくという感じのようだ。

f:id:simplearchitect:20190327181740j:plain

マネージャは使うもの

日本にいるときはマネージャは管理したり、何か指示を出す人だけど、こちらでは、全くそんな事はない。河野さん曰く、すごく良い作戦としては、マネージャを使う事だと言っていた。私も感じているけど、こちらのマネージャはガチで優秀。技術もよく知っているし、困ったら本当に助けてくれる。だから、先頭にあったような、反応してくれない問題も、マネージャに相談すると、一緒に解決したり、自分がアプリを作ったらまずマネージャにデモすると、それを広めるのを助けてくれたりすると言った具合に、とても助けてくれる。だから、こちらではマネージャに「使われる」のではなく、マネージャは「使うもの」だとアドバイスをくれた

ものづくりを楽しむ

これはアドバイスではないのだが、最後に河野さんが言っていたのが、電子工作興味ありますか?楽しいですよ?と言われた。そういえば、実力をあげよう、あげようとばかり考えていて、技術を楽しんだり、自分でなんか作ったりとかそういう感覚って忘れていた。自分のツール作るの最高に楽しいし、面白いアプリ作るのも面白いな。楽しい事やってる方が人間上達するよね。そんな事を思い出しながら、河野さんに去年作ったStrikes をご紹介した。復活して継続開発しようかな!ラズパイも楽しそうだから買っててやってないので、そろそろ魂を吹き込んでみるかな。

f:id:simplearchitect:20190328012313j:plain

最後に

あの河野さんでも自分と同じような事を感じていたのかとびっくりするのと同時に、物凄く適切なアドバイスをいただけた。ガチで世界中で使われまくっている、自分の会社の中核のサービスを開発をしている本物、本当に私が目指している本物のエンジニアが時間をくれてアドバイスをもらえた。今回のブログは誰のためでもなく、自分のためなんだけど、私や河野さんが感じたような事を感じている人のためにこちらでもシェアしてみる事にした。誰かのために役に立つと幸いです。

アメリカに住んで初めてわかった「最大級」の違い

昨年の年末にアメリカに移住して、今はシアトルの近くの Kirkland というところに住んでいる。大体三か月たって、いろんなことを体験した。移住した理由は単純で、コンピューターサイエンスの世界ではアメリカがどう考えても一番進んでいるので、そこで修行して通用するようになったら楽しいかなと思ったからだ。他にも他国の人を観察しているととても生産性が高い。特にアメリカの人は生産性が高い傾向が高い。なんでこんなにアメリカはコンピューターの世界が向いているのだろう?その一旦を感じた気がしたので久々にこのブログを書いてみることにした。

f:id:simplearchitect:20190311151850j:plain
Kirklandの風景

自分へのご褒美を買う

アメリカに移住すると、当然日本にいる友達とかと会えなくなる。私は一人でもさみしくない人だけど、さすがにこたえるだろうと思った。だから大好きなバンドをまたやろうと思った。ただ、こっちは正直レベル高いし、私はヴォーカリストだから、さらにハードルが高い(英語という意味で)。だから、移住した時に何か自分にご褒美を買おうと思っていた。最初はアメリカは家が広いだろうから、歌も、楽器もやりたい放題じゃないか?とおもったけど、アパートに住むと、そうでもないので、高い機材を買うより、思いっきり歌って、楽器を弾ける環境を作ることにした。ヴォーカルブースという一人用の防音室があるからこれを買おうと思い立った。これでがっつり練習しよう。ちなみにこんな感じのものだ。

f:id:simplearchitect:20190311152949j:plain
Silver Series VocalBooth

www.vocalbooth.com

ドキドキの銀行振り込み

と、ここまではいいのだが、実際に行動に移してみるとコテコテにトラブルに巻き込まれた。私の住んでいるのはアパートなので、そもそも入るかとても心配だった。だから、Vocal Booth の人にちゃんと分解されてくるか?とかの質問を投げたが、彼曰く「大丈夫、分解してくるからアパートも大丈夫。家用だし、Philips (プラスドライバーのこと) があれば簡単に組み立てられるよ。」その一言を聞いて注文した。高い買い物なのでドキドキだ。アメリカやし。

f:id:simplearchitect:20190311172955j:plain
こんな感じかな?

直接銀行口座に振り込むようになっていたけど、アメリカ人の友人がリサーチしたほうがいいと。だまされる可能性があるからとのことのようだ。しかも、振り込みをしようとした銀行のアプリも、「口座振り込みは詐欺に気を付けましょう」とか出てくる。ググったけど悪い評判ないし、ええい、やってしまえ!と振り込んだ。メールもちゃんと返してくれたが、ブースを作っているオレゴンでは、雪が降っていて交通がマヒしているようで、すぐに出荷できないといわれる。先の詐欺の件もあるので、ドキドキだ。数日間後、出荷したと連絡が入った。それと同時にメールで、注意書きを読んでおいてね。といわれた。人を二人用意してね、ドリルとかあったほうがいいかもね?クレートをトラックの上で開けておろすようにしてね。ドアは重いから、二人で運んでねと。なんやねんクレートとか、ドリルって?まー、何とかなるやろ。

日本の宅配の凄さ

こっちにいると、宅配の遅れみたいなのはしょっちゅうだし、適当だし、翌日配送とかありえない。昔は Amazonすげーって思っていたけど、あれ凄いの佐川とか、黒ネコだわ、、、とこちらでもAmazonを利用して実感した

f:id:simplearchitect:20190311173237j:plain
日本の宅配は神

。だから、今回も遅れとかはありがちかなーとおもったけど、今回のはなかなかディープだった。この荷物は受け取りの時に絶対に自宅にいとくようにとインストラクションがあったので、宅配予定(昼の1-6時のどこかで配送)の日は、自宅作業にした。その日の終わりになって電話がかかってきて、「ごめん、今日配送無理だわ」と電話がかかってきた。まーそんなこともあるだろう。次の日も自宅待機にして宅配をまっていたら、夕方にメールが入っていて、「おまえの電話番号つながらんから、配達無理やわ。連絡しとって」と。オペレーターさんに電話して、電話番号を伝えて次の日。あれ、まだこない。するとメールが入っていて「電話がつながらんから無理や。連絡して。と、いや、昨日伝えたし、、、」、と思いつつもまたオペレータさんに電話した。そこで衝撃の一言を聞くことになる。

フォークリフトを持っていますか?

オペレータさんに電話をすると、言われたことが、「Do you have a fork lift?」「えっ」、、、流石にそんなこと人生で言われたこと無い。どう考えてもわしの住所アパートやねんけど、、、彼女曰く、めっちゃ重い荷物があるから、フォークリフト無いと無理で、オプションとして、トラックの上で分解する方法もあると。そして、宅配で届く予定の荷物の詳細を見てかなり不安な気持ちになった。「920lbs」大体 480 kg 。何かが間違っている。そういえば、Vocal Booth のインストラクション意味が理解できなかったけど、今頃事態を把握した。これ、一般の家庭で買ったらあかんやつちゃうん、、、

f:id:simplearchitect:20190311173508j:plain
フォークリフト持ってません、、、

キャンセルに備える

Vocal Booth はガチで欲しいものだったけど、こんなもの買ったら引っ越しの時どうするねんとか、そもそも入るのか?ということが頭をよぎった。これ買った俺がアホやったんちゃうか、、、別の用事のついでにアパートの事務所によって聞いてみた。ここのアパートの天井の高さはどれぐらいですか?と。すると、彼女はこう答えた。「そうねー。ようしらんけど、8-9 (inch) の間ぐらい」そして、VocalBoothのスペックを調べると、「8.8 inch」こんなん絶対無理やん!ということで、Vocal Booth に電話をした。キャンセルした時の、返金の手続きとかについて教えてもらうためだ。キャンセルをしようとしている自分に若干安堵する。お金は失うけど、ひどい目にあうことはないだろう。

f:id:simplearchitect:20190311173946j:plain
微妙な高さの天井

自分だって英語で電話するのはつらいものがあるが、やるしかない。「高さが多分無理なので、キャンセルしたいんだけど、リファンドとかあるの?」と聞くと、彼は「そうか、残念だね。1000ドルぐらいは負担になるけど、そんなひどい目には合わないし、リファンドするよ。単にコンテナを送り返すように指示をしたらいいよ。だけど、このVocalBoothは、何千台も出荷しているけど、一回たりとも高さが問題になったことがない。8インチあれば組みあがるよ。」彼の口調もだましているようには感じなかったので、素直に信じてみることにした。せっかくアメリカに来たのだからこうなったらやってみよう。「ドアが重いから、それだけは二人で持ってね。あとは、Phillipsがあれば、大丈夫。ドリルもなくても大丈夫だよ、30分ぐらいでトラックの上でクレート(コンテナ)を分解して中身をとりだせるよ。」とのことだった。

友人を手配

同じ職場の友人が、手伝ってくれるというので、宅配会社に電話をして、なんとか、時間を狭めることに成功して、5-6時に来るらしい。友人が4:00頃こっちに向かってると電話をくれた。私が待っていると、トラックの運転手さんから電話かかってきて「ごめん、今日無理だわ」 orz 今まではともかく友達が向かってきてくれっるのに30分前にってなによ、、、、家に来てくれた友達に事情を話したら明日は家族旅行だから、昼までなら手伝えるとのこと。宅配会社と交渉して明日朝に持ってきてもらうことにした。

絶望

次の日は、9-12時のスポットなので、友人には、トラックの運転手さんから連絡は要ったら連絡するわと言ってある。ところが、今回はいつもとは逆に突然電話がかかってきて「ついたから、どうすればいい?」とのトラックの運転手さんの電話だった。「へ?あ、了解」友人に、メッセージを送ったり、電話を掛けたりしたけどつながらない。どうするよ!もう一人手伝ってくれるといってくれた友人にもメッセするが反応がない。やるしかない。そして、トラックに向かった。オペレータさんにトラックの上で分解するようにするという話をしていたのだが(彼女からもそう提案があった)、実際に来たトラックの運転手さんは、時間ないから、さっさとおろすね、多分このツール使えばおろせるよ。と言われて私茫然。

f:id:simplearchitect:20190311174324j:plain
トラック到着(イメージ)

「こんなクソ重いのどうしたらいいの?」と聞くと「あー、それ君のコンテナやから、君のビジネスだよ」と。ちなみに、運転手さんは意地悪そうではなくて、親切なかんじだけど、彼もどうしたらいいのかわからない様子。私の眼前には、ドカッとおかれた920 lbs のコンテナが。脳内イメージでは、プラスドライバーで簡単に組みあがる、分解パーツなので、IKEAの家具みたいなのをイメージしていたが、実物はこれだった。友人もいない、雨も降っている。よくわからんが、とにかく分解するしかない。中身抜いた後もこのコンテナどうやって処理したらいいかわからんけど、とりあえず開けようと、ドライバーを片手に開けてみる。

f:id:simplearchitect:20190311161602j:plain
コンテナ(実物)

後悔

この巨大なコンテナと中に入っていた工場施設のようなパーツを見つめながら、「無理じゃね、、、」と心の中でつぶやく自分がいた。「やっぱ昨日の時点でキャンセルが一番正しかったなぁ。」で、これどうするよ、、、たった一人で、、、しばらくすると、友人二人が反応があって、わざわざ来てくれた。

Brent の一言

同僚であり、友人のブレントは、いろんなツールを貸してくれた。ドリルだとか、トンカチだとか、ノコギリだとか。彼は南アフリカから私と同じように来た超絶ナイスガイ。彼にも、もう一人の日本人の友人にも、こんなだから、入らなかったらキャンセルも考えてるんだという話をした。高さも多分無理だし。すると、Brentは、「メジャーで入るかどうかはかってみよう。折角君が楽しむために買ったんだから、入ると絶対いいよな」といって、メジャーで天井まではかってくれた。結果は 9.4 inch 。Brentは、「絶対入る。君が、このブースをエンジョイするのを楽しみにしてるよ」といって時間になったので、家族旅行に旅立った。家族旅行の前に仕事でもなんでもないようなこんなんを一生懸命手伝ってくれるなんてなんていい人なんだろう。ホンマ感謝しかない。

再び挫折

さて、2人で運べるといってたので、パーツを残りの友人と運んでいたが、2人でないと無理と言っていたドアが出てきた。友人が持ち上げようとすると、まったく持ち上がらない。私は筋トレをしているので、持ち上がるがかなりの重さ。そして、超でかい。これが自分の自宅の曲がりくねった玄関をちゃんと通過するんやろか?これは、2人では絶対無理という感じになって、自分のアパートの事務所にいって、手伝ってくれる人を探すことにした。自分の気持ちとしては、心の奥底で、誰かに「無理、だめ」って言ってほしかったような気がする。事務所の人だと、「こんな重いものを家に上げたらだめですよ」とかいう反応も想定しながら声をかけてみた。すると気楽にてつだってくれることになった。ローリーという道具までもってきてくれて、3人がかりで運ぼうとしたが、デカすぎるのと、重すぎるので、すぐにアパートの壁に大穴を開けそうになる。頑張ったが、そもそも、普通にエレベータに乗らないのがわかった。中に仮に入ったとして、組み立てなんて2人で絶対無理だわ。エレベータは斜め上にしてあげたらいけるかもしれんけど、機械つかって3人でも無理な重さだ。

f:id:simplearchitect:20190311174718j:plain
重すぎた

どこのだれが、2人で十分って言ってるんねんほんま。とうとう私たちはエレベータに詰めることもできず、スタックした彼は「人でを調達したほうがいいよ。ローリーは貸してあげる。」とアドバイスをくれて「自分にはアイデアがある。この扉のパーツは、扉が重いから、これを外せば、かるくなるからインストールできるんじゃないか?」そういいながら、彼は仕事に戻った。しかし彼は「こんな重いものは無理だ」とか、「こんなのここのアパートに入れたらだめだわ、傷がついちゃう」とか言いそうなものだが、「どうやったらできるか」を必死にかんがえてくれた。

f:id:simplearchitect:20190311174745j:plain
ホンマにこんな気分だった

彼が去った後、くっそおもいローリーが邪魔なので、なんとかアパートの扉の外に戻して、にっちもさっちもいかなくなって、日本人の友人につぶやいた「自分がアホでした。やっぱり昨日キャンセルしとけばよかった。」彼は「この国の経験値があったと思いましょう。」そして、彼に、キャンセルの相談をしていると、まずは、宅配会社を呼ぶ前に、VocalBoothに連絡をして、リファンドの指示をもらわないといけないよと言ってくれた。だから、VocalBoothに再度電話をして、キャンセルのプロセスを教えてもらうことにした。

周囲の住民の反応

さて、このクソ重い、そして、デカい防音室の扉がアパートの前にローリーにくくりつけられて立ってる。こんなものを見たら、日本の同じアパートの人だと「大家さんに相談したほうがいいんじゃない?こんなのは入らないよ。」「邪魔だし、無理だよ」「迷惑です」とかいわれそうなものだが、絶望している私に何人もが話しかけてきて、「おー、これ、めっちゃいいやつやん、俺もギター弾いてるんだよ、君がうらやましいな!」とかおばちゃんも「防音室だねー。エンジョイしてね!」誰一人あきらめろとか、迷惑とか言わなくて、「めっちゃいいね」と言ってくるのだ。自分は絶望しているのに。もうキャンセルしたいって。

f:id:simplearchitect:20190311175018j:plain
ポジティブなご近所さん

Vocal Booth の一言

キャンセルの指示を聞くためにVocalBoothに電話をしてみた。高さは大丈夫だけど、扉が重いし、エレベータに乗らないし、どうしようもないという話をしていた。そしたら、彼が、「そうなんだ、普通は2人でいけるんだけどなぁ。」私「ちなみに、ドアを取り外して軽くするとかできる?」彼「お勧めしないない、だけど、ピンでとれるよ。こういう時は、うちは、People Readyというところにいつもお願いしているよ。」キャンセルもできるけど、最後の望みで、そこに電話をかけてみることにした。すると、そこは、人を派遣してくれるような会社さんて、「今すぐなんだけど、大人2人2時間手配できる?ものすごく重い家具を運んで組み立てるのを手伝ってほしいんだけど。」「いつがいいですか?」「できればなるはやで」すると1時間ぐらいで2人を派遣してくれた。

屈強のナイスガイ

すると、2人のかなりごっついナイスガイがやってきた。時間差で来たので、最初に来たナイスガイと私で、重くないけど、扉と同じサイズのものをためしに上げてみることにした。一応家には入った。ただし、扉は重いし厚い。この人が2人来てもあの重さやし、無理やったらキャンセルやな。と思っていた。もう一人のナイスガイもやってきて、とうとう扉にチャレンジすることになった。3人がかり+機械で無理やったやつだ。それが、なんと2人のタフガイは、機械も使わず普通に運んだ!マジっすか? エレベーターも斜めにして、通過して、曲がりくねった入口もさすがに大変そうだったけど、私も手伝ってなんと家の中に運搬できた。ホントかよ!すごすぎるこのナイスガイは!

f:id:simplearchitect:20190311175256j:plain
屈強なナイスガイ

手際のいいナイスガイ

するとナイスガイは、Vocal Booth の説明書を読みながら、苦労はしながらも着々とめっちゃ重いブースを組み上げていく。重さを知っているだけに、信じられない光景だ。私も筋トレをしているが、なにか根本が違う。引っ越し系のプロ凄い!俺はプログラミング頑張ります。ごめんなさい。という気分になりながらも、何回も挫折して絶対無理だと思っていたものが目の前で組みあがる光景は感動的だった。しかも、アメリカではあるあるなのだが、Vocal Booth の組み立ての説明書が、間違っている。私は Silver を買ったのに、Gold の説明になっている。これはわかるはずないわ。でも、ナイスガイは、そんなことはものともせず、たぶんこうだと文句ひとつ言わず、組み上げていく。そして完成。

f:id:simplearchitect:20190311175447j:plain
完成!

さらなる不可能を現実に

最後の大仕事は、コンテナだ。中身を抜いたものだが、めっちゃ重いし、そもそも、これ、どうするの?どこに捨てるの?という感じだ。先のどのBrent が去る前に相談したら。コンテナは2つにおって捨てるといいよと言われた。彼も経験があるらしい。アメリカどんな国やねん、、、

しかし、このコンテナは各段に硬いし重い。しかしナイスガイたちは、ガンガンにトンカチでたたいたり、上に乗ったりして、コンテナをぶっ潰してゴミ箱にぶち込んだ。あんたら凄すぎやろ、、、ナイスガイと感激の握手をして、のこりの日本人の友人と家に帰って、出来立ての Vocal Booth を試してみることにした。

人生で最も良い買い物

私は音楽をやっていて、長年いろんなものを買ってきた。少しでもうまくなりたくて、いい音がだしたくて、いろいろ買ってきた。しかし、この目の前にあるVocal Booth は人生で買ったものの中で最も素晴らしいものと断言できるものだった。ミュージシャンにとって、一番のストレスは、「音を出せないこと」で、歌にしても、家だと近所迷惑なので思いっきり歌えないし、ギターのアンプも小さくしないといけない。そうなるといろいろ違うので、実際にやるときとは違うし、歌も大きな声で歌わないと、うまく練習にならない。それが、なんの気兼ねもなく全力で歌って、ギターも相当デカい音で鳴らしてもTVぐらいだし、あれだけ昔苦情をいわれたアコースティックギターもTVよりもちっさいぐらいの音になる。ヴォーカルに至ってはシャウトしてもめっちゃ小さいおとしかしない。もう最高、最高だ。自分の家に音を出せるスタジオがあるのがこんなに素晴らしいことと思わなかった。人生で一番いい買い物だ。マジで。めちゃくちゃいろいろあったけど、あきらめなくて本当によかった。いや、私はあきらめてたんだけど、他の人が背中を押してくれた。

f:id:simplearchitect:20190311175529j:plain
思いっきり歌えるし、弾ける!

最大級の違い

今回はめっちゃくちゃ苦労したので、思い入れがありすぎて、長くなってしまったが、今回の一連の事件で最も衝撃だったことは、こんなタフなことを起こっても、Facebookの上の人を含めて誰一人「おまえアホやなー」「無理やろ」「諦めさない」とか言わなかった。全員が「絶対にできるよ」とか、「これ、めっちゃいいやつだよね!」「つよしが、ヴォーカルブースでエンジョイできることを楽しみにしてるよ」とか、どんな立場の人でも言ってきた。こんな環境で生きているからかもしれないけど、相当困難なチャレンジもきっと彼らにとっては普通で、それより、その先にまっている楽しいことを考えているし、失敗したらどうしようとか誰も考えていない。自分は日本人の中では相当チャレンジな人やと思ってたけど、やっぱ日本人なんだなとおもった。やっぱ失敗が怖いんだ。失敗を避けたいんだなぁと。こういう話を後で友人のDavidにして、日本人は失敗さけたいから、先に予見しようとして、時間がかかるんやと思ったわ。みたいな話をしたら、「そういう場面やと、自分はメジャーで測りもしないわ。やってみたらわかるやん」と返してきた。タフすぎるw つまり、私だけかもしれないが、自分のような日本人はそういうのが体に染みついているから、出来るほうに倒してしまうのだけど、こっちの人は、失敗するかもしれない難しいことにサクッとチャレンジして、それが普通で、周りの人もそれを歓迎してくれるんだ。だから、自分は、自分にそういうのが染みついていることを意識して、難易度ではなくて、「こういうことを実現したい」ということに対して難しそうに見て得てもチャレンジするようにするように選択を倒すのが必要と思った。

ソフトウェアもチャレンジング

そういえば、ソフトウェアでも、こちらの事例はチャレンジングなのが多い。昔マイクロサービスのハックをこちらでやったときも、出たばかりの製品を本番どころか、普段クラウドで使うところをオンプレで使ったりしていた。どんだけチャレンジャーやねん。と当時は思っていたが、そういう無理目なことをするから、失敗も多分あるけど、技術力が上がるし、うまくいったときの成果も自分にとってのVocal Booth のように、感動的なものになるのかもしれない。そういえば、Davidもスノーボードのコースも日本だったらそもそも入れないような区域に余裕で滑りに行っていた。つまり、結局のところ、困難なチャレンジをしないと本当にインパクトがある結果など出せない。それができている国民性がアメリカというところなのかと思った。確かにGitとかでも酷い目にあったときに新しいコマンドを覚えて使えるようになよな。上記のようにすべてが素晴らしいわけではないが、プロフェッショナルとしての腕を磨くには最高の環境かもしれない。

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

この学びを日本で生かすにはどうしたらいいだろう?少なくともソフトウェアにおいては自分には、相当な「失敗への恐怖」と、「チャレンジの回避」の傾向があることを自覚するだけでも、かなりいろんな効果があるかもしれない。そういう視点で、他国の人を観察してみよう。日本にいても例えば、GitHubとかのプルリクエストでどんな会話をしているか?とか、観察するチャンスはいろいろある。そういえば、そういう方面でも、失敗を恐れて何かしないとかほぼ見たことないことに気が付く。だから、自分が思ってるよりもかなり困難なことをを実施しても出来てしまうかもしれない。自分が無理でも、私の出会ったAmazingなマッチョなナイスガイが手伝ってくれたら自分が想像だにしていなかったことを実現できるかもしれない。どうするかは人それぞれやけど、自分は、プログラミングの方でも「Vocal Booth」のような人生に何回もであえないような感動的な体験をしてみたいと思う。

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

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

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%の妥協なしアジャイルチームを実際にやってみるのをおすすめします。