頑張りすぎないで！

Jonathan： こんにちは、Exercismポッドキャストへようこそ。私の名前はJonathanです。今日は皆さんをお迎えできることを光栄に思います。そして、GoとJavaScriptトラックのメンテナーの一人であるFranziskaも一緒です。FranziskaがExercismの一員として参加してくれていることをとても嬉しく思います。彼女は何年も関わってくれています。 ですので、もしExercismに馴染みのある方なら、Franziskaに会ったことがあるかもしれません。学習コホートやGo、JavaScriptトラックで。それではFranziska、今日は温かく歓迎します。参加してくれて本当にありがとうございます。早速ですが、どうして今の場所にたどり着いたのか教えてください。

Franziska： はい。わかりました。私はFranziskaです。インターネット上ではJune、あるいはJune Devです。現在はドイツのフランクフルト近郊、市境を少し出た小さな郊外に住んでいます。そして最近、Atlassianで新しい仕事を始めました。Atlassianは、Trello、Jira、Confluenceなど、多くの人に愛されたり嫌われたりしているツールを手がける会社です。 そこで私がしているのは、プロダクトマネージャーの仕事を支援する新しいツールの開発です。というのも、Jiraは開発者に焦点を当てていますが、プロダクトマネージャーがやるべきこと、優先順位をつけることなどにはあまり合っていません。 なので、彼ら専用のものを構築しています。私は言語としてGoが好きです。本当に気に入っています。バックエンドはGoで構築されています。求人広告を見たとき、これは面白いことをやっているなと思いました。応募して、採用されました。まだ30日しか経っていませんが、いい経験になっています。 子どものころから、テック系や自然科学、SF、大のスタートレックファンなど、そういうものにいつも興味がありました。学校では数学や物理が得意だと気づきました。当時、多くの人がコンピューターサイエンスを専攻していて、みんなが「他人がやっていることを専攻するな、後でそういう人が多くなりすぎるから」と言っていました。そこで、コンピューターサイエンスはやめておこう、そういう人が多くなりすぎるから、と思いました。 とにかく、似たようなことをしようと考えました。それで物理学を専攻することにしました。学校で大好きだったからです。コンピューターサイエンスは副専攻のようなものでした。いくつか授業を取りましたが、他の人ほど多くはありませんでした。人生の残りを何に使うのか、どうやってお金を稼ぐのか、本当に好きなことをしてお金を得るにはどうするか、考える時が来ますよね。 そして、勉強の中で一番好きだったのはプログラミングの部分で、自分はそれが得意だと気づきました。もっとそれをやりたかったのです。それに、生活費を稼げるものでもあります。 そこで、当時、古典的なコンピューターサイエンスの学位なしで、どうやってこの分野の仕事に就けるだろうと考えました。もう一つ、当時はC開発者やJava開発者のように、どこかの銀行のバックエンドコードを書くような古臭い仕事にはなりたくないと思っていました。 そこで、どうやってモダンなこと、インターネットやWebを学べるだろうと考えました。それ向けに何か作りたかったのです。すると友人が、開発ブートキャンプというものがあり、3か月どこかに行けば新しいクールなことを教えてくれる、と教えてくれました。 はい。それをやろうと決めました。そうすれば、仕事を見つけるためのより良い足がかりができるだろうと。当時、ドイツにはそういうものはありませんでした。 そう、何年も大学に通うか、あるいは少し働きながら学べる場所もありましたが、何年も教育を受ける大きなプログラムでした。ブートキャンプ的なものは、スタートアップアクセラレーターのようなものだけでした。少しコードを学びますが、マネジメントや経済学なども学ぶもので、私には合いませんでした。それで少し探して、ロンドンに学びたい科目がある良いものを見つけました。

Jonathan： それが動かしているものですか

Franziska： ラップが起きている。ええ、その通り。まさに。クールな新しいことが起きている場所です。ええ、このブートキャンプを見つけて、行きました。本当に素晴らしい経験でした。バックエンドにはNode.jsを使いました。 それからフランクフルトに戻り、Node開発者として仕事を見つけました。会社はとてもクールで、技術も本当にクールで、あっという間にすべてに馴染み、とても楽しかったです。ただ、チームには少し運がありませんでした。大きなエゴを持ったマッチョなチームメンバーがたくさんいて。 会議をすると、一番声が大きい人が議論に勝つような感じでした。それは、いいチームとは言えません。

Jonathan： プログラミングをやろうと志す人が、チームの側面が問題や課題になるとは思っていない、というのはよくある話ですよね。かなりよくあることのように思えます。すみません。

Franziska： ええ。ええ。本当にそうですね。最初はテックの部分を過大評価しがちです。「この仕事は自分のやりたい技術そのものだから大丈夫」と思うのですが、実際にはチームの部分のほうが、やっている技術そのものよりも重要なことさえあります。 それで、2年後、友人がフランクフルトの別の会社でCTOをしていました。彼は「うちも技術スタックを変えたい、何か新しいものを作りたい、でもNode.jsはやりたくない。Goで行きたい」と言いました。何らかの理由でそう決めたそうです。そして「一緒に来ないか」と。 もちろんGoを学ぶ必要があります。最初に少し時間をもらって学ぶことを気にしないなら、やるよと答えました。言語を少し見て、良さそうに思えました。それで会社を変えました。新しい場所のチームは本当にクールでした。 CEOと議論していても、自分の主張のほうが良ければ、それがきちんと評価されるような環境でした。人々がそれに反応してくれる。とても働きやすく、人々もとても面白かったです。そこで5年間働きました。 多くのグロースサービスを作り、ドキュメントやコンセプトの文章も多く書いて、他の開発者のGoへのオンボーディングを助け、フロントエンドの仕事も少しやりました。ですが、5年経つと新しい挑戦を探しますし、転職を考えた理由はCovidの状況もありました。 もともと在宅で働いていて、週に1回ほどオフィスに行く程度でした。それならフルリモートの仕事がたくさんあるし、もっと大きな会社で何かクールなことができるかもしれないと思いました。どうせ在宅で働くなら、より大きくクールな会社で働けるだろうと。 そうして、働きながらAtlassianの仕事を見つけました。

Jonathan： それで私の質問は、パンデミック全体が、フランクフルトだけではない、フランクフルトのスタートアップシーンだけではないかもしれないと考えるきっかけになったのかなと。フランクフルトのスタートアップシーンはどんな空間だったのか聞こうと思っていました。

Franziska： ええ、Covidの点だけ言うと、まずCovidが私に開いてくれたのは、完全リモートで働くという考え方でした。以前はいつもオフィスに行くタイプで、人に直接会うのが好きでしたし、1日の組み立て方もそうでした。でも2年間ほとんど完全リモートでやってみて、大丈夫だとわかりました。 なんとかなります。娘がいて、どうせいつも外に出なければならないので。今は1日に十分な構造があります。これはパンデミックが示してくれたことで、別の場所を探すという考えにつながりました。フランクフルトについては、テックやスタートアップの動きはたくさんありますが、かなり銀行寄りです。 予想されるように、銀行業務に焦点を当てたものが多く、フィンテックもたくさんあります。私は過去にフィンテックで働いたことはありますが、主題として特に情熱を持っているわけではありません。それに、周りにGoの開発者もあまりいません。 フランクフルトに留まらせるもの、フランクフルトのシーンにそこまで惹きつけるものは特にありませんでした。ええ、そういうことです。

Jonathan： いいえ、なるほど。では、フランクフルトが特に注力している言語はありますか？もちろんフィンテックと言えば、それを支える言語があるのでしょうが、それがより焦点になっているのでしょうか？Go開発者としてフランクフルトでは珍しい存在だと感じますか？ それとも増えていますか？どう見えますか？

Franziska： ええ、今増えているかどうかは判断が難しいです。Covidのせいでミートアップなどがあまりなかったですからね。ですので、現在ミートアップに来る人が増えているかどうかはわかりにくいです。ただ、例えばJavaの分野ではもっと多くの動きがあると思います。 正確にどうなっているかは少し難しいですが、例えばJavaScriptはコミュニティをまとめるのがそれほど問題にならないことが多いです。誰もがどこかでフロントエンドをやっていますからね。ですので、バックエンドよりもフロントエンドの世界のほうが通常は活発でした。

Jonathan： それで、おそらくプログラミングを始めてブートキャンプに行ったときには、フロントエンドの側面もあったでしょうし、少しは見たと思います。今はもっとバックエンド中心です。なぜフロントエンドよりバックエンドを好むのですか？それとも私の勝手な推測でしょうか？

Franziska： いいえ、間違いなく、ブートキャンプ中に気づいたことです。私はバックエンドのほうが好きで、そこには収益面もあります。まず、私はデザイナー的な人間ではありません。フロントエンドをやると、自分で判断を下さなければならないことがよくあります。 これはどう見えるべきか？ここで何ができるか？改善するにはCSSをどう書くか、などです。そういう判断をするのは私にはとても難しいです。もちろん実務ではデザインが渡されますが、それでも私は物事に対する審美眼があまりありません。 それを持っていてできるフロントエンド開発者は、仕事をする上でより効果的だと気づきました。それが私には向いていないと思う理由の一つでした。もう一つは、現在フロントエンドの世界が本当に非常に複雑だということです。 周りにあるフレームワーク、よく使われるもののほとんどが本当に難しいです。ある意味で、現在のバックエンドのほうが少し簡単です。可視化しにくいという意味では難しいですが、フロントエンドのように画面を見てこれが最終結果だとわかるわけではありません。 しかし、関わる技術の複雑さから言うと、現在はフロントエンドの世界で起きていることよりむしろ簡単だと感じています。ですので、私はキャリアのどこかでまたフロントエンドもやりたいと思っています。でも、もっと良いフレームワークが出てくるのを待っています。 そして、今の混乱が収まり、何か良いものが出てきたら、またフロントエンドに戻りたいです。

Jonathan： そのフレームワークが出てきたらあなたが決めるのを待って、私も一緒にやるかもしれません。JavaScriptの上に構築されたフレームワークを見ていると、私はあらゆる意味で初心者です。今Goを学ぼうとしていて、楽しいです。でも、必要な概念やイメージだけでも、それ自体がまったく新しい世界です。 それで、最初にプログラミングを始めてJavaScriptを学び、その後Goを学んだとき、どうやってギャップを埋めたのか聞きたいです。というのも、あなたはJavaScriptからGoへ、かなり簡単なプロセスだったように話しているからです。でも実際はどうでしたか？移行するために何をしましたか？

Franziska： ええ。良い質問です。ここで重要なのは、JavaScriptだけが私の言語ではなかったということです。大学では多くの言語を深くやったわけではありませんが、Cを学び、Javaを学び、C++を学び、Malaや、そういう難解な言語も学びました。 ですので、私にとってJavaはすでに5番目くらいの言語で、Goは6番目でした。例えばGoは、ポインターなどについて聞いたことがあるでしょうが、JavaScriptだけから来た人にはまったく新しいもので、それが何なのか学ばなければならなかったでしょう。 でも他の言語を背景に持っていたので、CやC++などからすでに知っていました。ですので、大学で以前に学んだ多くのことに頼ることができ、とても入りやすかったです。Goのもう一つの良い点は、かなりミニマルな言語だということです。 キーワードもそれほど多くなく、構築できる構造もそれほど多くありません。かなり早く通り抜けられます。私はいつも、公式ツアーに行くか、ウェブサイトなどを見て、2週間か3週間で終えられると言います。 そしてしっかり理解できます。JavaScriptではそれは不可能でしょう。基礎をしっかり理解するだけでもずっと長くかかり、さらに学ぶことが山ほどあります。ですので、そういう目標言語だったことも、簡単に移行できた大きな助けになりました。

Jonathan： なるほど。今はAtlassianで働いていて、テックとプロダクトの重なりについて少し話してくれました。フィンテックはあまり自分に合わない、特に興奮しないと言っていましたね。プロダクトの領域や、テックとプロダクトのインターフェースは本当に楽しめる分野ですか？ それとも、テック分野で特に情熱を注いでいることを一言でまとめると何ですか？とても大きな質問ですが、少し話してもらえますか？

Franziska： ええ、私が興味を持っている領域やトピックはいくつかあります。今働いている場所だけではありません。例えば、消費者向けプロダクトのような分野が好きです。Hello Freshのようにクールなことをしている会社があります。 テック関連のクールなこと、あるいは教育分野、Exercismのようなものもたくさんあります。もう一つは、開発者ツールやチーム向けツール周辺です。複数の領域がありますが、これは人々を助けるのに非常に理にかなっていると思えるものの一つでした。 特にプロダクトマネジメントについては、Jeremyの逸話と、前職のCEOの話をできます。新しい仕事と何をするかを伝えたら、Exercismの創設者であるJeremyと同じことを言いました。まったく同じことを言ったのです。「私のプロダクトマネジメントスキルに不満があってこの仕事を選んだのか？」と。つまり、プロダクトマネジメントを改善することは、私が常に情熱を持っていたことなのです。なぜなら、開発者としてどんなに最高のコードを書いても、間違ったものを作っていたら、すべて無駄になるからです。 プロダクトマネージャーが作るべき正しいものを見つける仕事をうまくやっていなければ、市場分析も優先順位付けも不十分で、誰もあなたの作ったものを使わないかもしれません。私は過去の仕事でそれを経験しました。 良い優先順位付けのプロセスがなかったために、日の目を見なかったものをたくさん作りました。ですから、プロダクトマネジメントの分野を全体的に改善することは、世界中の開発者の生活をずっと良くすると思います。そうすれば正しいものを作り、本当に価値を生み出せます。ゴミ箱行きになったり、ユーザーに見られないものを作るのではなく。

Jonathan： ええ、本当に興味深いです。あなたが指摘しているのは、精神的に、テックが得意なら裏方で全部やる、人として日の目を見ない、という固定観念がよくあるということですね。ステレオタイプと言えるでしょう。でもここ数年、テックとビジネス側の重なりが増えているように感じます。私自身は常にアジャイルを概念として考えていました。アジャイルの概念は、ビジネスの考え方や見方を技術チームに押し付けたものだと思います。 正直に言うと、役に立つとは感じますが、アジャイルな環境が成果を時間通りに生み出したのを見たことがありません。うまく管理されていない例しか見ていないからかもしれませんが、開発者がビジネス側にもっと関わりたがる傾向が強まっているように感じます。これはとても興味深く、実際良いことだと思います。全体として意思決定が良くなるからです。

Franziska： ええ、開発者の中にはもっと関わりたい人もいれば、そうでない人もいますが、いずれにせよもっと関わる必要があります。問題は、プロダクトマネジメントが座って全部を分解し、壁の向こうに投げ、開発者が作ればそれで終わり、というわけにはいかないということです。 過去にそれが標準モデルだったときでさえ、うまく機能したためしがありません。今はもっと注目されていますが、開発者とデザイナー、開発者とプロダクトマネージャーの間でより多くの対話を持つことは常に正しいことでした。 また、下流にもっと関わる人たち、例えばサポートチームやメンテナンスをする人たちがいる場合、彼らが緊密に連携し、最良の解決策を一緒に考えれば考えるほど、より多くの価値を一緒に生み出せます。 それは常に真実でした。例えば、今取り組んでいる機能について、プロダクトマネジメントは多くのアイデアを持っています。新しい機能の最初のイテレーションに何を含めるか。しかし彼らだけでは判断できません。これを追加すると、作業が1日増えるのか、それともスコープ全体が膨らんで3か月増えるのか。 彼らには判断不可能です。ですので、最初のイテレーションの良いまとめ方を見つける唯一の方法は、お互いに話し合うことです。「これは追加しやすい」「これは追加が難しい」などと。そして良いスコープを見つけます。Atlassianでの仕事の良い点は、同じように考えてくれるプロダクトマネージャーがいることです。 彼はいつも、スコープは双方的なものだと言います。「私にもアイデアがあるが、何が最も理にかなうかについても意見をくれ」と。そして一緒に解決策を練ります。採用プロセスでも感じましたが、他の人や他のチームとのコミュニケーションというテーマは現在非常に重視されています。多くの人が「他のチームとどう働きましたか？」と聞きます。話しているだけで、どれだけうまく表現できるかを見ています。他のチームが何をしているかを気にかけ、関与することが非常に重要だからです。 そうして初めて、持っている時間を最大限に活かせます。

Jonathan： その意味で、ずっと統合されたアプローチに感じます。そうなると、別の考えが浮かびます。よくあるのは

Franziska： あ、進む前に、アジャイルというトリガーワードを出しましたよね。それに飛びつかずにはいられません。私を挑発するための意図だったのかはわかりませんが。アジャイルについて、私はいつも、そもそもの基本的な考え方、プロセスより人々が大事、というようなずっと前に出てきた基本的なことは今でも十分理にかなっていると思います。 その周りに魔法がたくさんあります。でも、コンサルタントたちが来て、大規模なフレームワークを作り、それを売り、スクラムマスターなどがいます。あなたが言ったように、多くの場合はあまり役に立ちません。例えばプロダクトと開発者がうまくコミュニケーションしていなければ、構造を上に載せるだけでは適切に解決しません。 ですので、私も標準的なスクラムプラクティスやアジャイルプラクティスの大ファンではありませんし、それがうまく機能しているのをどこでも見たことがありません。

Jonathan： 興味深いです。LinkedInでプロダクトオーナーやプロダクトマネージャーを探すと、どこもスクラム、アジャイルばかりです。すごいなと思います。でも面白いのは、私が見てきた中で最も創意工夫に富んだ開発チームはカンバンでした。時間枠内で必ず成果を出さなければというプレッシャーはないけれど、品質は生まれます。個人に責任を戻し、説明責任を負わせる。これは本当に興味深い経験でした。若いチームはアジャイルに行き詰まり、うまくいかないとフラストレーションを感じ、最終的にカンバンにたどり着き、時間をかけて着実に少しずつ進めて、うまくいくのです。 でも、自社プロダクトを持っている場合と、他社のためにプロダクトを作る場合の違いも興味深いです。前職が自社プロダクトだったのか、社内プロダクトだったのかは知りません。Atlassianでは基本的に自社プロダクトを作っていますよね。

Franziska： ええ、私はいつも自社プロダクトを作ってきました。代理店のような場所で働いたことはありません。

Jonathan： ええ。代理店の仕事は悪夢です。開発の1時間ごとにすべてを精査され、「でもわからない。なぜこのボタンに400ドルかかるのか？ここからここに動かしてほしいだけなのに、それはバックエンド全体の作り直しだった」と言われます。 それで、様々なポッドキャストやライブストリームで多くの人に聞いている質問をしたいと思います。 それは、あなたが命をかけて守る丘、つまり技術に関する意見で、絶対に譲れないもの、技術業界全体で見たいと思う価値観や意見は何か、という概念です。これはあなたが必ず持つべき意見と言いたいわけではなく、あなたにとって絶対に重要な価値観や意見で、技術分野全体に広がってほしいものは何か、ということです。 かなり広い質問ですが、技術において強く守りたいことが一つありますか？

Franziska： もっと軽い話になると思っていました。軽い、不人気な意見でいいですか？

Jonathan： ええ、もちろんです。

Franziska： わかりました。命をかけて守るほどの大きな丘はそんなにありません。強く思っていることの一つは、多くの人が個人の開発環境を最適化するように勧めることです。それはほとんど過大評価だと思います。 例えば、Vimを覚えるべきだと言われます。そうすれば二度とマウスに手を伸ばさなくて済む、素晴らしい、などと。そして業界に入ったばかりの人たちはそれを信じます。そして1年かけて魔法のショートカットを学びます。 でも結局、1年で1日分くらいしか節約できません。その1年の苦労は報われません。こういうことはたくさんあります。ターミナルのエイリアスを全部ドットファイルに設定しろとか、ショートカットカードを全部覚えろとか。そういうことを学ぶのに多くの時間を費やしますが、節約できるのはわずかです。ここで起きているのは、仕事でタイピングに費やす時間を過大評価していることだと思います。 さっきも言いましたが、仕事の多くはコミュニケーションです。実際には考えることが仕事の多くを占めます。1日の中で実際に何かをタイプする、コードやコマンドを打つ時間は限られています。多くの人はそのごく一部を最適化しているのです。私の意見では、それが趣味ならやればいいと思います。 あるいは自分にとって同様の価値があるなら。SRE、サイトリリースエンジニアで、サーバーにハックするような人は、Vimを知っていると役立つかもしれません。グラフィカルインターフェースを開けないからです。でも必要ないなら気にしないでください。自分が快適なものを使えばいいのです。 例えばショートカットについて、私はいつも言います。ほとんどのグラフィカルインターフェースは、クリックするものの横にショートカットを表示します。1日に5回クリックするなら、覚える価値があるかもしれません。5分ごとになら、なおさらです。でもそうでなければ、グラフィカルインターフェースで満足して、自分のことをして、実際のプログラミングスキルを向上させることに時間を使ったほうがいいです。演習をしたり、新しい言語を学んだり。 でも、これは新米開発者にいつも言おうとしていることです。古いエディターを使えとか、そこで生産性を最適化しろと言う人たちに怯まないでください。

Jonathan： 面白いですね。人の情熱が混ざり込むことがよくあります。理解はできます。「自分の生活を最適化したからすごく興奮している」という感じで。でも実際に考えると、常に最良とは限りません。私の学習経験もそうでした。人々の推薦が多すぎるのです。 YouTubeで「コードの学び方」を調べると、GitHubの設定方法から始める人、ターミナルの理解から始める人など様々です。ローカルで作業するためのプルやオンラインエディターなど。でも今は、それは本当に良いアドバイスだと思います。かなりシンプルに保つこと。それでは、もっと考える時間を取るなら、問題をどう考え抜きますか？ 仕事で状況がある場合、あるいは一般的に、1日の中で何をしますか？時間を確保しますか？プロセスはどんな感じですか？

Franziska： まず好きなのは、実際に解かなければならない前に問題を少し先に手に入れて、1週間ほど頭の片隅に置いておくことです。シャワー中に少し考え、寝る前に少し考え、頭の中でしばらく転がします。たいてい、いくつかの出発点が見つかります。そこから、特に仕事なら、ポイントを書き出し始めます。書き出すと頭が整理され、例えばプロダクトマネージャーとまだ話す必要がある点が見つかります。顧客にとって何が必要か正確にわからないからです。 すでにわかっていることと解決方法を書きます。また、通常はかなり大きな未解決の質問表を書きます。チームの誰かへのものも、自分自身で解明すべきものも。それが本当に整理に役立ちます。 そして、超ハイレベルな概念から、より具体的なプログラミングタスクに分解します。APIはどう見えるか？このために保存するデータは何か？ストーリーポイントからデータへ、そして戻るまでにどんなロジックが必要か。 状況によります。以前の思考プロセスで解決すべき問題の多くをすでに見つけていることもありますが、コーディングを始めてから予期しなかった新しい問題を見つけることもあります。その場合は一度戻って考え直し、実際のコードに戻ります。そういうこともあります。 でも通常は、まず少し考え抜くシステムです。事前にいくつかの問題を解いておくととても助かります。そうすればコードは素直に書けますし、あるいはさらに問題を見つけて戻ることもありますが、それも問題ありません。

Jonathan： なるほど。いいですね。よく私の頭にあるのは、フルタイムのプログラマーなら文字通りコンピューターの前に座って、朝から晩まで少しずつ作業するというイメージです。でも、問題を考え抜く力、Exercismも重視していることですが、問題をよく考えること、すべての文脈を把握することが大切だと気づきました。そしてコーディング部分は、そのプロセスを実装として表現するだけなのです。Jeremyも同じことを言うでしょう。彼は多くのことを考えてから、かなり短いコードを書くと思います。

Franziska： ええ。それから、よくあるヒントは、コメントにやりたいことを書き出すことです。「まずこれをやる、その結果がこれ、次にこれ」と書いてから、該当する部分のコードを埋めます。それもとても役立ちます。

Jonathan： 面白いですね。今の話を聞いて、絶対に試そうと思いました。プログラミング、特にGoを学ぶときなど、キーボードから入力を受け取り、保存し、「何回推測しました」などを返す演習をやろうとしていました。 でも、その問題を本当に細かいタスクに分解して考えるプロセスは、私にはとても不慣れでした。その種の問題を段階的に考える方法を学ぶのは本当に興味深いです。 ですので、いい小さなヒントをもらいました。ぜひ実践します。

Franziska： それはExercismで多く人が呼びかけていることでもあります。多くの人は言語や構文の理解ではそれほど苦労しません。でも、このやや一般的な問題をどう解くか、というところで苦労します。 Exercismでは、プログラマーとして考えることを学ぶための良いリソースを提供しようと少し試みています。でも、まだ改善できるかもしれません。

Jonathan： いや、本当ですね。そうすると興味深い質問になります。他の人にも何人か聞いたことがあります。プログラムが「わかった」と感じた瞬間はいつですか？そういう感覚がありましたか？ 概念や理論を教科書で学んできて、ある朝目覚めたら突然「ああ、わかった」と思った、という経験は私にもよくあります。あなたにとってそれはいつでしたか？それとも徐々に「少しずつわかってきた」という感じでしたか？

Franziska： ああ、それについて少し考えました。ええ、クリックする瞬間はあったと思います。でも最初から話させてください。最初はクリックしなかったんです。10代の頃、ゲームが入ったおもちゃのノートパソコンを持っていました。Basicでプログラミングできる機能もありました。 祖父が来て、彼はパンチカードでプログラミングを始めた人でした。彼はいつもテックに興味があり、「そこでプログラミングできるなんてクールだ」と言いました。彼は私にプログラミングがクールだと見せたかったのです。そして、誰もが始めるように始めました。 printと入力して「Hello world」と出ました。私は「Hello Worldくらい打てるよ。何を見せたいの？」と思いました。彼は「違う、君が言った通りに動くんだ」と言いました。次に「1+2は」と入力すると3が出ました。私は「電卓でもできるよ。何を見せたいの？」と思いました。理解できませんでした。その後、学校でコンピューターサイエンスのようなものをやりました。Turbo Pascalがあり、小さなタートルが画面に何か描くプラグインのようなものがありました。 そこでは、何かの公式を入力すると、葉っぱのような複雑なフラクタルを描くクールな演習がありました。タートルに何を描くか指示する小さな公式を入力するだけで、それが得られるのです。 それが私にとってクリックした瞬間でした。超単純な指示を与えることで、自分では絶対に作れない複雑なものを作れると気づいたからです。あんなに多くの線は自分では描けませんから。それが「ああ、そうか」と思った瞬間でした。 つまり、自分よりも多くのことができる。でも以前、祖父の説明や見せてくれたものではダメでした。でもこのグラフィカルなものを見て、コンピューターに複雑なことをさせるのに必要な指示がどれほど少ないかを見て、クリックしたのです。

Jonathan： いいですね。私も先日メソッドで同じ経験をしました。「メソッドって一体何なんだ？」と思って、ピンとこなかったのです。化学でも同じでした。2年間学んで、ある日突然周期表が完全に理解できました。当時16歳でした。 「なんてことだ、こんなに簡単なことだったのか。2年間も理解できなかったなんて」と思いました。試験は楽勝でした。答えは全部周期表にあるのです。ちょっとしたことをやればいいだけ。すべてが脳内で同期しました。 そういう瞬間について人と話すのも興味深いです。Rebecca、ExercismのUnisonトラックで知っているかもしれませんが、彼女に聞きました。彼女は英文学の学位を持っていて、どうやって英文学からプログラミングに移ったのか、頭の中で概念化するためにどんな方法を使ったのかと。 彼女は、書いているプログラムを物語として、主人公のいる物語として想像し、関数は登場人物だと言っていました。それはとても興味深いと思いました。そんなふうに考えたことはありませんでした。 本当に

Franziska： ええ。でもそれは、コメントで話していたことに通じますよね。コードの前に書くこと。まず物語を語り、それから追加のコードを書く。まさにそれです。

Jonathan： それを言ってくれて本当にいいですね。実際にコメントで物語を書いているんだと気づくと、絶対に取り入れますよ。

Franziska： この話題でもう一つ。プログラミングが得意な人についての研究があり、言語能力、語彙力などが大きな役割を果たしていることがわかっています。 例えば、プログラミングでは命名が難しいと言われます。扱っているものをうまく説明する良い言葉を考えられる人は、コードがずっと良くなります。つまり数学や分析だけではなく、言葉に強いことも大きく関係しているのです。最初は意外かもしれません。

Jonathan： つまり結局は言語なんですね。興味深い考えです。あなたはドイツ人で、ドイツ語が母語ですが、今Atlassianで英語で開発していますか？以前も英語でしたか？残念ながらすべて英語になっていると思いますが。 英語はお上手ですが、学校で英語を学び、プログラミングはすべてドイツ語でしたか？どうやって学んだのですか？

Franziska： ええ、ほとんどは幸運なことに、プログラミングの多くは英語で、コメントも英語でした。いつも最高の英語ではありませんが、大丈夫です。私自身、学校では英語が得意ではありませんでした。でも大学で1年間、イギリスに交換留学できました。 そこで実際に言語に浸かりました。その後英語はとても上達し、それ以降は楽でしたが、それ以前は本当にひどかったです。その1年間、実際に言語を学んだことが、後にドイツ出身でない同僚とコミュニケーションするのに役立ちました。 それは間違いなく要因です。英語が母語でなければ、適切な名前を争うのが難しくなります。命名はコードのすべての行で行います。常に何かに名前を付け、コードを明確にするために最善の名前を付ける必要があります。

Jonathan： 英語が母語でない人にとって簡単だとは思いません。これは今後変わっていくと思います。先日、インドが現在世界で最も急速に成長しているテック分野だという記事を読みました。英語を使い続けるか、現地の言葉を使うかは別として、インドには多くの言語があります。 そういうことを考えるのは興味深いです。そろそろ1時間になります。本当に楽しかったです。Franziska、もう一つ質問があります。ここであなたが推薦をする番です。Exercismコミュニティへの推薦は何ですか？ 食べ物でも、散歩でも、何でも構いません。今週Exercismコミュニティに推薦したいことは何ですか？

Franziska： ええ、不人気な意見で話した生産性の話に戻ります。私の推薦は、休憩を取ること、いつも見たかったNetflix番組を一気見することなどです。人は一日中生産的であろうと集中しがちです。 それは脳に良くありません。仕事で成果を出し、創造的であるためにそんなに最適化するのは脳に良くありません。脳には休憩が必要です。休憩中に脳がいろいろ処理するからです。ソファに座って番組をぼんやり見るのは良いことです。 脳にバックグラウンドで処理する時間を与えるのです。休憩を取ること、時間を取ることは過小評価されています。それが私の推薦です。休憩してリラックスすることに罪悪感を感じないでください。

Jonathan： いいですね。とても気に入りました。皆さん、これを聞いている方にとって、これがFranziskaからの今週の推薦、アドバイスです。Franziska、お時間をありがとうございました。Exercismに捧げてくれたこと、コミュニティとの関わりや思考に感謝します。 Exercismに多大な関わりを持ち、改善し、助けてくれていることを知っています。本当に感謝しています。ありがとうと言いたかったのです。今朝は時間をくれてありがとう。祝日で外出して楽しむこともできたのに、ここに時間を割いてくれて、とても感謝しています。 録音を止めた後も通話に残っていましたが、本当にありがとう。残りの一日を素敵にお過ごしください。

Franziska： 呼んでくれてありがとう。