遠征、Elixir、Exercism

Jonathan: こんばんは、みなさん。Exercismポッドキャストへようこそ。今回は**Brian **Underwoodさんをお迎えできて光栄です。**Brian、**今はどちらにお住まいなんですか？　そして、これまでの歩みと、今の場所にたどり着くまでの話を少し聞かせてください。 Brian: はい、もちろんです。呼んでいただきありがとうございます。そうですね、私はスウェーデンのストックホルムにいます。でももともとはアメリカ出身で、オハイオ州で生まれました。なので、そこからすると結構な移動でしたね。 Jonathan: なるほど。 Brian: ええと、というか、私がどこ出身で、その間どんな道のりだったのか、みたいなことを知りたかったんですよね。 Jonathan: ええ、もちろんです。アメリカの真ん中からスウェーデン、スカンジナビアへ、どうやってたどり着いたんですか？　なかなか大きな飛躍ですよね。 Brian: はい。ええ。もちろんです。だって、そこはアメリカの真ん中ですからね。まあ、無理もないですよ。オハイオがどこにあるか、実際ほとんど誰も知りませんからね。そこは本当に、もう、おもしろいところです。そう、それで、私はオハイオ州立大学に進んだんです。コンピューターサイエンスの教育学部のようなところで。楽しかったですよ。とても楽しめました。それで、在学中はずっと、人文学部でテクニカルサポートのようなことをしていました。入学したときにそこで仕事をもらえたのは幸運でしたね。卒業後も2年ほどそのまま続けていました。ええと、でもそのうち、自分がいる場所ややっていることに少し飽きてきたというか、それに彼女にも振られてしまって。なので、その話はやめておきましょう、やめておきましょう。 Jonathan: あまり楽しい思い出ではなさそうですね。 Brian: ええ、まあ、今思えば全部いい経験でしたけどね。でもまあ、それで、こういう感じです。よし、ここでチャンスをもらったな、と。それで数週間ヨーロッパを旅することにしたんです。アメリカをまとまった期間離れたのは、それが初めてでした。それ自体はよかったですよ、ヨーロッパを旅するのは。そして、その前に、引っ越すことを決めていました。どこに引っ越すかは、ボストンにほぼ決めていました。それで、幸運だったのかは分かりませんが、いくつか選択肢があって、私はずっとMacのサポートをやっていたので、それが大きかったんです。ひとつはボストンでのMacのテクニカルサポートの仕事でした。もうひとつは小さなスタートアップで、携帯電話会社向けのソフトウェアを作っていて、店舗の商品陳列をどうするか、みたいなものに関わっていました。それで、私は本当はプログラマーに転身したかったんです。でももう一方の仕事は、自分が長くやってきたことでした。ただ、私はむしろ、よし、新しい生活、自分が望むキャリアに踏み出そう、という側に傾いていました。まあ、その仕事に就けたのは少し運もあったと思います。本当に人手が必要だったようで、そのまま受け入れてもらえたんです。それが結局、何年も続く大きな仕事になりました。ええ、そういう感じで始まったわけです。ざっくり言うと、そこから今の妻と出会って、プロビデンスに引っ越して、そこで結婚しました。それからカリフォルニアに移りました。妻がサンフランシスコで仕事を得たんだと思います。私は「もちろん、ソフトウェア開発者だから、サンフランシスコでも仕事は見つけられる。問題ない」という感じでした。それでうまくいきました。2年ほどオークランドに住んでサンフランシスコで働いていました。でもそのあと、2年ほどあちこち旅をしようということになって、結局2年間、世界を旅することになりました。その時点で2歳半の息子がいたので、彼と一緒に2年ほど旅をしました。それからアメリカに2年ほど戻って、そして、旅の途中でストックホルムを通ったときに、すごく気に入ったね、ということになって、「よし、戻ろう」と。それで、ここ4年ほどはストックホルムにいます。 Jonathan: 奥さんはスウェーデン人なんですか？　それとも、ただストックホルムが気に入っただけ？　ええと、どういう経緯だったんですか？　そこはどんな話なんですか？ Brian: はい、いい質問ですね。よく聞かれる質問です。でも、そうではなくて、私たちはみんなアメリカ人です。息子を含めて3人ともアメリカ人です。ただ、息子は私たちよりずっと上手にスウェーデン語を話します。私たちも頑張っていますけどね。でもそう、とにかく本当に気に入ったんです。旅の途中で訪れた場所の中で、ここに住んでもいいかも、と思った場所がいくつかありました。そのひとつがオークランドで、通りがかりに訪れてとても気に入りました。それってニュージーランド？　オークランド、ニュージーランドのオークランドのこと？　そう、ニュージーランドです。でも少し遠すぎましたね。家族に会うためにオハイオに戻ろうとしたら、それはかなりの道のりになりますから。もちろん、スウェーデンからでも十分遠いんですけどね。 Jonathan: なるほど。それで、コンピュータープログラミングと、失礼、コンピューターサイエンスとプログラミングの違いについて触れていましたよね。その違いは何だったんですか？　私の中では、コンピューターサイエンスはある意味プログラミングだと思っていたんですが、明らかにそうではないんですね。あるいは同じなのか、よく分かりません。その点について、具体的にはどういう意味だったんですか？ Brian: はい。違いが分かっているかと言われると、自信はありません。私はコンピューターサイエンスの学位を取りましたし、それはプログラミングだったと思いますが、ただ、よく言われるように、大学の学位で学べることと、実際の仕事で学んでやることには違いがありますよね。おそらく、私が大学に通っていたころから少し変わっていると思います。もっと実践的な教育に移行してきているのでしょう。たとえば、覚えているのは、当時はCとJavaが主に学ぶ言語でした。特に、ある授業でJavaでやっていたことで、これはとても厳密で、たしか教育手法か、何かのアプローチの仕方だったと思うんですが、自分の関数ひとつひとつにコメントをしっかり書くというもので、「契約による設計」と呼ばれるものでした。それは、法的な契約のように、こう言うんです。「あなたの責任は何ですか？　私の責任は何ですか？」と。つまり、契約によって関数を設計するというのは、こういうことです。「この変数にこれらの値を渡してください。ただし、この値には決して負の数を渡さないでください。そして、この文字列は決して空にしないでください」といった具合に。これらはあなたの責任です。そうしてくれれば、私はこれをやります、これを実現します、と約束する。それで、そういうコメントの書き方があって、私は当時とても混乱して、コメントがどうやら実行されて、プログラムの一部になっているのだと思っていました。だから、私は何日か「いったい何をすればいいんだ？」と考えていたのを覚えています。そしてやがて、これは単なるとても形式的な手法なのだと分かりました。ある意味ではよかったと思います。考え方というのは、頭を形作ることもありますから。関数が、起こり得るあらゆることすべてに対処できるようにしない、というふうに考えるのはいいことです。そうしないと、ただの混沌になってしまいますからね。 Jonathan: それで、コンピューターサイエンスを主な専攻として大学に進まれたわけですよね。それはどうやって決めたんですか？　学校や高校で、より理系の科目に自然と惹かれていただけなのか、それとも「これは自分にぴったりだ」と思った瞬間があったのか。コンピューターサイエンスを学びたいと決めるまでに、どんな経緯があったんですか？ Brian: はい、たぶん、自然と惹かれていたという点では、かなり運がよかったのだと思います。どうでしょう、覚えているのは、ある時点でプログラムの選択肢があって、教養学部のコンピューターサイエンスのコースに進むか、工学部のコンピューターサイエンスのコースに進むか、選べたんです。ひとつは語学の授業が必要で、高校から続けていたスペイン語がそのまま延長になる感じでした。でももうひとつは、外国語はやらなくていい代わりに、物理と数学をもっとやる必要がありました。それで私は「よし、それでお願いします」という感じでした。たぶん、そちらに惹かれていたのだと思います。ただ、よく考えることがあるんですが、これは私が持っている理系の、数学的な興味の特権みたいなものなのかもしれませんが、たぶん、数学をやることについて、多くの人は「数学は苦手」「緊張する」「ストレスだ」というふうに言いますよね。そういうこともあるだろうな、と理解はしています。でも、ときどき思うんです。人によっては、理由はともかく、数学に面白さを見いだせて、わくわくしながら取り組める。かかる手間や解き明かす量は同じでも、ただ楽しいと感じられないだけで。楽しいときは、あまり手間に感じないものですからね。たぶん、正確にはそういうことではないんでしょうけど、私の持論で、おそらく半分くらいしか当たっていないと思います。 Jonathan: でもおもしろいもので、私はイギリスでGCSEの化学を3年間やっていたんですが、最初の2年はGCSEの試験に向けて3年間学んで、16歳で大きな試験を受けることになります。範囲がとても広くて、10科目くらいやるので、なかなかの量です。そのあと「よし、Aレベルを取ろう。数学や理科をもっとやるか、英語や演劇にするか」と決めるわけです。でも私の場合、化学が2年ほど全くピンとこなくて、試験の1週間前くらいになって突然すべてがつながったんです。周期表と、それがどう機能しているかが分かって、ああ、周期表からすべての答えが導けるんだ、クロスワードパズルみたいに、と。電球がパッと点く感覚でした。その瞬間から「これは今までで一番簡単な科目だ」と思ったのを覚えています。でもそこに至るまで2年間もがいたわけです。これがおもしろいのは、私にとってコーディングも似ていると感じるからです。長い時間どっぷり浸かって、そのうち急に分かるようになる。そういう方向に動いていくのを楽しみにしています。ただ、あなたが話していたのは、最初からすぐに理解して、問題解決の部分を学習の中心として楽しんでいる友達を見ていた、ということですよね。とても興味深いと思います。あなた自身もそれを経験したのはよかったですね。 Brian: そういえば、息子がiPadで遊んでいたアプリがあるんです。Dragon Boxという会社か、シリーズのアプリなんですが、聞いたことはありますか？　とてもよくできた教育アプリを作っています。ふだん、私は教育アプリにはかなり懐疑的なんですが、彼らのものはいくつか本当に優れています。そのひとつが幾何の問題で、いや、幾何ではなく代数でした。幾何のものもあります。でも代数のアプリは、代数の概念そのものを教えるのではなく、代数の操作を教えるんです。 Jonathan: この動画がよかったら、高評価をお願いします。そしてチャンネル登録をして、こんな動画をもっと見ていきましょう。 Brian: それで、左右に2つの別々の箱があって、両側で釣り合うようにしなければならないんです。モンスターを片側からもう片側へ動かしたり、ある種類のモンスターを別のものに変えたりします。見たのはしばらく前なので細かいところは忘れましたが、はっきり覚えているのは、彼が何のために、なぜこれをやっているのかは分かっていないのに、代数の操作を学んでいたということです。でもやっていて楽しいし、とても夢中になれる作りになっていました。それがすばらしいと思うんです。彼が代数を始めるときに、もう一度このアプリをやらせたいと思っています。操作そのものを身につけてしまえば、そこまで気にしなくてよくなって、細かいことにストレスを感じずに、もっと高いレベルで考えられるようになるからです。たぶん、あなたが化学で言っていたのもそういうことですよね。あなたもそうだったかは分かりませんが、たぶん、こういう操作やルール、あれこれに、なぜ気を使わなければならないんだ、という感じだったのでしょう。そして、ある地点まで来ると、「よし、ここはなんとか乗り越えた。そろそろ、なぜこれをやっているのかを考えてもいいかな」となるわけです。 Jonathan: ええ、ええ。いや、とても興味深い経験でした。何かを理解するという、そういう過程を初めて通ったからです。その途中で、そうした科目に対して自信をかなり失う時期があって、自分の脳はそういう考え方には向いていないんだ、と思ってしまう。でも実際には、たとえば私がやっていた英文学を見てみると、言語や、それがどう組み立てられているかをとても体系的に追っていくわけですが、そこにはニュアンスがあり、芸術的な性質もあります。開発やコーディングにも同じ芸術的な要素があると言えますよね。人それぞれに少しずつ個性が出ます。そして、何にしても絶対の決まりはなく、すべてはトレードオフなんだ、と最近はますます思うようになりました。いや、とてもおもしろかったです。それで、あなたはコホートを手伝ってくれましたよね。聞いている人に説明すると、私たちはElixirとGolangの学習体験のようなものを実施していて、**Brian、**あなたはElixirのコホートを少し手伝ってくれました。そもそも、どうやってElixirという言語に入っていったんですか？　そこに至る背景はどんなものだったんですか？ Brian: ええ、おもしろいことに、今日ちょうど誰かに同じことを聞かれたんです。というのも、まあ、ある意味ではニッチな言語ですからね。でも私はRubyの世界に長くいて、Rubyの開発者を長くやっていました。Rubyは本当に好きです。私はどちらかというと、物事を片づけたい、難しい問題を片づけたい、と考えるタイプのプログラマーなので、細かいところやポインターの扱いなんかに気を取られていると、難しい問題には取りかかれませんからね。Rubyはその点ですばらしかったです。そしてもちろん、Elixirの作者であるJoseph AlimはRubyの世界から出てきました。彼はRubyの世界ですでに精力的に活動していて、自分で言語を作ることにした、いや、必要だったというより、彼はすごい人なので、自分の言語を作ってそこで存分に活躍しようとして、実際にそれをやり遂げたわけです。それで私は、ある意味その世界に引き込まれていきました。ポッドキャストを聞いていて、ときどきRubyの話をしていたのが、あるとき「これは新しい、Elixirだ」という流れになって。それからたぶん、少し転機というか、根本的な出来事があって。私はちょうどそのころ、しばらくオハイオ州コロンバスに戻っていたんですが、Joseph AleemがコロンバスのRubyグループ、コロンバス・ルビー・ブリゲードに来たんです。彼らは「Joseph Aleemが来て、話したいことを何でも話してくれるなんてすばらしい」という感じでした。そしてもちろん彼は「はい、Elixirについて話します。この言語を作ったのは私ですし、とても楽しみにしています」と。ええ、まさにそんな感じです。よく覚えていますよ。おもしろいことに、ちょうど1年前にその発表の録画を見つけたんです。少しざらついた画質ですが、今でも見られます。そして、私がJosephに質問しているところも見つけられるんです。あのとき、いったいどういう仕組みなのか、混乱していたのを覚えています。 Jonathan: とても楽しみです。 Brian: プロセスを作ると、スーパーバイザーがあれば失敗から復帰できる、といった概念です。彼が正確に何と言ったかは覚えていませんが、私は「それはどういう仕組みなんですか？　エラーから復帰するのは分かりました。でも、そのエラーについて、こちらは何か学べるんですか？　それとも何が起きるんですか？」という感じでした。これは、それがどういう意味なのかを学ぶ、ひとつの大きな過程でした。とても興味深い過程だと思います。当時は、Elixirコミュニティの多くが、こうした概念をどう説明するかに苦労していたと思います。今はブログ記事も増えて、もっと早く理解できる材料がどんどん出てきています。まあとにかく、そういう場所から私は入っていきました。それが大きなきっかけのひとつだったと思います。「おお、おもしろそうだ。Joseがいいと言うなら、試してみよう」という感じでした。 Jonathan: それって、あなたがそこに移るタイミングがちょうどよかった、ということですか？　いろいろなことが重なって、あなたにとって意味があるものになった、と。ほかの言語も探していたんですか？　ポインターの話をしていましたが、それはGoを指しているんですか？　それとも、自分に合う言語を探しているところだった、ということでしょうか？ Brian: そうですね、私は、それぞれの目的に合ったものがある、という考え方が大好きなんです。それで、今はElixirにどっぷり入っています。ただ、たぶん私は少し偏っていて、Elixirはほぼ何にでも使えると思っています。それは完全に正しいわけではないでしょうけどね。ポインターの話は、たぶんCのことを考えていました。大学でCとC++を少しやったんです。たぶん。 そう、それで私は何年か、グラフデータベースのNeo4jを扱っていました。それにすごく入れ込んでいて、Ruby向けのNeo4j gemのメンテナーのひとりでもありました。というのも、それは 細かい話は置いておきますが、グラフデータベースを使うと、ある種のことはより速く、あるいはある面ではより簡単にできるようになります。私にとっては、これは、そう、Neo4jをこういう目的で使う人は多くないんですが、Rubyに似ているところがあって、より高いレベルで物事を考えられるようにしてくれるんです。だから、よりきれいに物事を進められる。でも私は、こういう考え方が好きなんです。「グラフデータベースはこの目的にいい。リレーショナルデータベースはこれに。ドキュメントデータベースはこれに」と。そして「すごく速く動く必要のある小さなサービスを作るなら、RustやGoで書くといいかもしれない。だからそれらの言語も知っておくべきだ」。高レベルなものならRubyやPythonがあり、今はElixirもある。Elixirには実際、たくさんの大きな利点があります。何が何に向いているかを見極めるのはとても難しいことです。言語にはあまりに多くの要素が関わっていますから、ある目的に良いかどうかを判断するのは大変です。それに、私も含めてですが、人は何らかの理由で好きな言語に感情的に入れ込んでしまうものなんです。だから、まあ、難しいんですよね。うん。 Jonathan: それで、**Brian、**仕事で日常的にElixirを使っているんですか？　今のお仕事は何なんですか？　現時点での日常はどんな感じなんですか？ Brian: はい、私はErlang Solutionsのコンサルタントです。それで、Erlang Solutionsのクライアントで、VicAIという会社と仕事をしています。聞いたことがありますか？　Lars Wirthvenが少し手伝って、ブログにも少し書いていたと思います。Elixirの世界では、そこそこ有名な人です。その会社は、他の企業を支援する会社で、人工知能を使って請求書を半自動または全自動で処理するアプリケーションを作っています。ええ、それで、もちろん機械学習モデルもありますが、それらをまとめて調整するElixirのAPIもあります。 Jonathan: なるほど。それで、日々たくさんの異なるクライアントを相手にしているんですか？　それとも、専門のチームと一緒に進めていく感じなんですか？　どういう仕組みなんですか？ Brian: はい、たいていはプロダクトマネージャーと一緒の、機能単位のチームにいます。ウェブ開発者、モバイル開発者、ときにはバックエンド開発者、機械学習チームもいます。それに、プロダクト担当やQAの人がクライアントとやり取りして、ユーザーやクライアントが本当に必要としているもの、最も必要とされているものをうまく引き出してくれることもあって、それはありがたいですね。ただ、少し階層的になっていて、内容にもよりますが、大きな直接のクライアントがひとつあって、それから会計システム、ERPと連携しているんですが、そこにはクライアントの情報を入力する人たちがいます。正直なところ、私はそのあたり、顧客側の仕事にはそれほど多く関わってはいません。でも、クライアントと接する方法はいろいろあって、統合するためにいろいろと工夫する必要があり、それ自体がなかなかおもしろい課題なんです。 Jonathan: では、1週間はかなり変化に富んでいますか？　それとも、わりと予測できる感じですか？ Brian: ええ、そうですね。私はかなり恵まれていると思います。たいていは、取り組んでいるプロジェクトは1つです。たとえば最近だと、請求書を処理する際の計算が正しいかを確認するのを手伝っていました。これはなかなか厄介で、特に、いろいろなベンダーから請求書が届くと、それぞれやり方が違ったりしますから。でも、私たちはコードの品質や、全体的な状態をきちんと保つことを大事にしてくれるので、それは幸運です。だから、よりよいものにする、コードをよくする、改善するための時間をそれなりに取るようにしています。それに、私自身もそういうタイプなんです。少なくとも時間の一部は、そういうことに使うようにしています。たとえば、アプリケーションをDatadogと連携させて、リクエストやバックグラウンドジョブのトレースができるようにしています。それができると、「よし、これで仕事に必要な道具がそろった」という感じになって、とてもうれしいんです。それから、つい最近興味を持ったことで、コードを整理して他のモジュールを参照する方法みたいなものがあって。Elixirの世界にはCredoというツールがあって、コードスタイルのさまざまなルールを強制できるんですが、そのルールを実現するための新しいCredoのルールを書いてみました。どうなるか楽しみにしています。 Jonathan: なるほど、いいですね。正直に言うと、少し私には難しかったですが、きっと分かる人もいるでしょう。でも、以前、少しスタートアップで働いたという話をしていましたよね。テクニカルサポートの仕事と、スタートアップの話が少しありました。そういうのは、今後やってみたいことなんですか？　それとも、いつも頭の片隅にあるものですか？　プログラミングという面で、今後5年、10年の見通しはどうですか？　まだ分からないかもしれませんが、人に聞くとおもしろい質問だと思っていて、「5年後、10年後、自分はどうなっていると思うか」というのは、よく聞くんです。 Brian: はい、いい質問ですね。私はどちらかというと、スタートアップという点では、いつも中小規模の会社の間を行き来してきました。 Jonathan: なるほど。 Brian: 大企業では同じようには幸せにやっていませんでした。コンサルタントという働き方は、最近まで自分にはないと思っていました。でも、いろいろな会社に行って、その問題解決を手伝い、そしてまた別の会社に移る、というのはなかなかおもしろいな、と。まあ、Big Gagの人が聞いていたら、私は不満ではないですよ、とだけ言っておきます。 Jonathan: 「ポッドキャストでそんなことを聞くべきじゃないかな」と思ったんですけどね。でも、まあ、もちろんすべて順調だという前提で。すみません、うちの猫がドアを引っかいています。 Brian: ああ、そうなんですね。うちは1か月ほど前に子犬を迎えたばかりで、もう常に、鳴いていたり、あと1、2回ベッドの上でおしっこをしたりして、「これは対応しないと」という感じです。 Jonathan: うちも迎えたばかりで、もう大変です。毎朝5時、朝の4時30分にベッドに飛び乗って、顔を前足でかいてくるんです。かわいいですよ、本当にかわいい。でも、しばらくすると「もう、いい加減にしてよ」という感じです。でも、そう、ここ数年、今後やりたいことや実現したいことについてですが、どんなことができたらいいなと思いますか？ Brian: はい、いい質問ですね。私は、見つけ出すという考え方が好きなんです。Elixirが私を惹きつける理由のひとつは、まだ少し新しいということかもしれません。だから、新しい道を切り開くにはどうしたらいいか、新しいパターンを見つけるにはどうしたらいいかを考えるのが好きなんです。特に、私はしばらくRubyの世界にいたので、Elixirに来て、「ああ、Rubyのこれは恋しいな。これをこう作れたらいいな」と思うこともあります。でも一方で、「これはRubyではうまくできなかったけど、こうすればできる。Elixirの強みを活かせば、もっとすばらしいものが作れる」ということもあります。そういうことに関心があります。おもしろい使い方を見つけて、それについて話したり、共有したりするのが好きなんです。それは私をいつも刺激してくれるもので、特に実際の使い方について読んだとき、その詳細を見たときはそうですね。「こういうことをやって、こう進めました」だけではなく、コードはどこで見られるのか、詳細はどうなっているのか、というところが知りたいんです。ええ。 Jonathan: 何かを最適化する側面を楽しんでいるように聞こえます。何かを取り上げて、よりよく、より効率的にする新しい方法を切り開く、ということです。少なくともそう聞こえました。そういう理解で合っていますか？ Brian: ええ、そうですね。効率的であることはいいことです。でも、それ以上に、物事を楽しくする方法を見つける、と言いたいかもしれません。問題を解決して、もうそれに対処しなくて済むようにする、という考え方が大好きなんです。たとえばライブラリを作って、「よし、これでこの問題は解決した。次は、もっと時間を有効に使える何かに進もう」というふうに。ですよね？ Jonathan: いえ、もちろんです。よく分かります。私は、特にこの業界全体について、人に聞くのが好きなんですが、というのも、私はIT業界全体としてはかなり新しく、子どものころから開発をしていたような経験があるわけではありません。それでよく思うのは、業界にいる友達からもよく聞くんですが、意見が飛び交っていて、それは確かにその通りだなと。でも、このポッドキャストに出てくれた人たちによく聞く質問があって、それは「テックの世界で、あなたが命を懸けて守る丘は何ですか？」というものです。もちろん、少し冗談めかして聞いています。あなたにも、これは守りたい、という考え方や意見がありますか？　何でもいいんです。いい例だと、メンテナーのひとりのDJは、本当に重要な会話の役割、つまりテックの世界で、善意のある、よく構造化された会話をすることだと言っていました。しっかりした土台の上に成り立つ、たくましく、ときに厳しく問いかける会話を持つことですね。ほかの誰かが何と言ったかも思い出そうとしているんですが、UnisonのRebeccaは、働き者で誠実だけれど才能は少し劣る50人のチームのほうが、一緒に仕事をするのが悪夢のような天才ひとりよりいい、と言っていました。なので、まあ、いい例だと思います。それに、突然そんな質問を振ってしまって、少し意地悪でしたね。あなたにはたぶん、いろいろな考えがあるでしょうから。でも、これは譲れない、というものはありますか？ Brian: うーん。そうですね。そう、まず頭に浮かんだのは、キャメルケースとスネークケースのどちらか、というものでした。でも、そこまでして守るかというと、どうでしょうね。そういう類のことはたぶん、 Jonathan: 私はそこまでは… Brian: ええ、ええ。でもそういうことの多くは、時間とともによりこだわらなくなってきたかもしれません。とはいえ、あなたが言っているような、より高いレベルの話は好きです。たぶん、私は…。ちょっと調べられるか見てみます。あいにく、これは編集されるんですよね。だから私の間は全部消えてしまうと。 Jonathan: それは予定ですね、少なくとも。 Brian: はい。それで、Remote Retroというツールがあって、私は何度も使っていて、本当におすすめです。Elixirで書かれていると知って知ったんですが、それはともかく、とにかくよくできていると思います。使ううちに、どんどんいいツールになっていきました。それは必ず「基本原則」から始まるんですが、今見てみると、Norm Keithから取ったもののようです。ここにwikiのページがあるので、調べられますよ。remote-retro.orgを見れば確認できます。ええと、その基本原則というのは、振り返りの最初に読んで、みんなを正しい心構えにするためのもので、こう書いてあります。「私たちが何を発見しようと、私たちは、誰もがその時点で知っていたこと、自分のスキルと能力、利用できたリソース、そしてその場の状況のもとで、最善を尽くしたと理解し、心から信じています。」ええ、いいと思います。似た話で、いつも…もうひとつ言ってもいいですか。あるインタビューがあって、よければあとでリンクをショーの説明欄に載せておきますね。 Jonathan: ぜひ載せてください。 Brian: ええ、この記事はいつもすすめています。見つけるのがとても難しいんですが、たぶん今では少し埋もれてしまっているでしょうね。でも、こんな男性がいて、アメリカの政府機関、退役軍人省の管理職だった人です。たしか医療制度を担当していました。その人が航空宇宙の世界から来ていて、インタビューで語っていたことの多くは、航空宇宙では、まあどこでも完璧というわけではないでしょうが、彼が経験した多くの現場では、人のせいにせず、プロセスのせいにする、ということでした。何か問題が起きたら、「これは自分のせいではない」と言えます。たとえば私も、本番環境でテーブルを消してしまったことがあります。でも幸い、誰も私を責めませんでした。「よし、ではどうする？」という感じで。それで、本番環境のコンソールに入ると、プロンプトが赤く表示されるようにしたんです。そうすれば、本番環境にいることがはっきり分かりますからね。私がそのミスをしたのは、開発環境だと思っていたからです。ええ、そういうわけで、人ではなくプロセスを責める職場にいられたのは幸運でした。本当によかったです。彼はそれを医療の文脈でも話していました。看護師が患者さんに間違った薬を渡してしまうことがある。でも、ラベルが紛らわしかったり、手順が難しかったり、とにかく理想的ではないことがある。だったら、そこを直そう、そうしよう、と。患者さんを本当に大切に思うなら、間違いが起きにくいプロセスにしよう、というわけです。これは私にとって、とても大きなことなんです。 Jonathan: それはとてもいいですね。ショーノートにぜひ載せます。それはアジャイルから来ているんですか？　アジャイルの方法論を土台にしたものと言えるんでしょうか？　それとも少し違うものですか？　どう思いますか？ Brian: いい質問だと思います。私の印象では、航空宇宙工学のいくつかの界隈では、かなり長い伝統の一部のようです。まあ、航空宇宙では、飛行機を作るにしてもロケットを作るにしても、「これは動かなければならない」という仕事ですからね。そして人を乗せるとなれば、それが宇宙飛行士でも乗客でも、うまくいく可能性を最大限にしたい。その最善の方法は、自分のエゴを脇に置いて、こう問いかけることです。「さて、どうすればいいだろう？」 Jonathan: うん。 Brian: プロセスに従えば、どうすれば毎回できるだけ確実にうまくいくのか、と。それが理由のひとつだと思います。ええ。 Jonathan: Remote Retroを調べていたとき、アジャイルの用語が多く使われているように見えたんです。だから、どこかでそこから変わってきたのかな、と思いました。でも本当にいい話ですね。今まで聞いたことがありませんでした。私が聞いたことのあるのは、チェックリストの話で、特に医療と航空宇宙のものです。パイロットはチェックリストに沿って進め、そこから外れません。医師も同じです。とてもいいですね。**Brian、**そろそろ着陸に入りましょう。今夜、もうひとつだけ質問があります。Exercismコミュニティに向けて、次の1週間のおすすめは何ですか？　ひとつだけアドバイスをするとしたら、何でもいいんです。地元のデリでコンブチャを飲んでみるでも、北極海で走って泳ぐでも、何でも。Exercismコミュニティに「ぜひ試してみて」とすすめるとしたら、今週は何ですか？ Brian: ありがとう！　うーん、そうですね…。ええと、まあ、自分のできる範囲で、ということになります。というのも、みんなに同じアドバイスをするのはいつも難しいですからね。でも、私にとって大きなことのひとつは、以前、突然の頭痛で救急外来に行ったことがあるんです。フラッシュ頭痛という、ときに深刻になり得るものかもしれない、という心配がありました。それで診てもらって、特に問題はなかったんですが、医師が一般的な質問をしていて、「運動はどのくらいしていますか」とか、「普段の活動はどうですか」と聞くわけです。私はアメリカ人なので、「まあ、結構歩いていますよ。1週間に、いや1か月に8000歩、平均で1日あたり、くらいですかね」と答えました。すると医師は「週に3回、45分、本当に汗をかくくらい外に出たほうがいい」と言うんです。すぐにはやらなかったんですが、5、6か月後には、たいてい週に3回、ときには2回、走る習慣が身につきました。これは私の生活の中でも大きな変化でした。とても助けになっています。すごく難しいことですし、私自身も始めるのはとても大変でした。そのときのやり方のひとつは、「よし、外に出よう。途中で75%くらい歩いてしまっても、それでいい。少しずつ積み上げていこう」と決めたことです。 Jonathan: いいですね。それを聞いておもしろいと思ったのは、私たちが… Brian: それを聞いておもしろいと思ったのは、私たちが… Jonathan: いえ、本当にいい話です。というのも、コホートで考えていたことのひとつが、人が成長して学び、前に進み、勢いをつけるには何が必要か、でした。コーディングのジョギングで言うなら、勢いをつけるにはどうしたらいいか、ということです。そのひとつが、1日10分でもいいから外に出て、試してみる立場に自分を置く、ということでした。たいして進まなくても、説明を読んだだけでその日は終わりでも、何らかの形で顔を出すだけで、大きな違いになります。でも、それはすばらしいおすすめですし、私自身、室内にいると体を動かさないので、そろそろ運動を始めないとな、といういいきっかけになりました。聞いている人がいたら、Brianのアドバイスに従って走りに出かけてみてください。でも、ストックホルムはこれから数週間で少し寒くなりますよね。真冬でも走るんですか？　それとも室内で走る感じですか？ Brian: はい、走ります。それに、ついでに言うと、週に3回、1日30分か40分くらい外に出るとして、いちばんいい運動は、自分がいちばん楽しいと思えるものなんですよ。走るのが楽しくないなら、たぶん続きませんからね。まずはそれを言っておきたいです。でも、そう、冬ですが、私は帽子を持っていて、ストックホルムは暗いですからね。妻が反射材が織り込まれた帽子を買ってくれて。いいですよね。それで安全を保てます。それからフェイスマスクと耳あても付けられます。ええ、そういうわけで、しっかり着込まないといけませんが、寒い時期はいい面もあります。寒いとペースを抑えられて、それでも走れるんです。ええ、まさにそのとおりです。 Jonathan: それはすばらしい。それではBrian、今夜はお時間をいただき、本当にありがとうございました。長い一日だったでしょうし、お子さんも仕事も新しい子犬もあって大変だったと思いますが、時間を割いて話を聞かせてくださって感謝しています。聞いてくださっているみなさんには、ショーノートを下の説明欄に載せておきますので、ぜひチェックしてみてください。もし機会があれば、これを聞いている方はElixirのトラックも見てみてください。**Brian **はElixirのトラックでメンタリングをしているかは分かりませんが、もしメンタリングの場にいれば、新しく入ってくる人が試しているところを見かけるかもしれませんね。Elixirについてはいい話をたくさん聞いているので、今後注目のひとつだと思います。それではBrian、よい夜を。録音を止めるときに少しだけお待ちください。でも、今日は本当に来てくれてありがとうございました。Brian Underwoodの生活を少し垣間見せてくれて感謝します。それではみなさん、聞いてくださってありがとうございました。よい夜を。またお会いしましょう。