POSTD PRODUCED BY NIJIBOX

POSTD PRODUCED BY NIJIBOX

ニジボックスが運営する
エンジニアに向けた
キュレーションメディア

POSTD PRODUCED BY NIJIBOX

POSTD PRODUCED BY NIJIBOX

ニジボックスが運営する
エンジニアに向けた
キュレーションメディア

FeedlyRSSTwitterFacebook

本記事は、原著者の許諾のもとに翻訳・掲載しております。

この手紙は、”熟練者”ならではの知識を語るものではありません。新人かベテランかに関わらず、私たちの誰もが繰り返し学び、覚えておくべきことについて書いています。ここでは、一般的な傾向や、聞けばなるほどと思うような傾向、重要とされていることを新たに学んで興奮している時に見られる傾向を紹介します。また、学んだことの面白さや重要性を人にきちんと伝わるように話すことの難しさについてもお伝えします。この手紙はかなり具体的に書いています。一般的な話をするなら具体的なことも併せて話さなければ理解してもらえないと悟ったからです。これは代数的構造やその他の抽象的な概念についても言えることですね。この手紙には、私が頭に入れておきたい、また皆さんに共有したいアドバイスが詰まっています。インターネット上で適切とは言えない振る舞いをしている人に出くわした時、そんなことはめったにないでしょうが、そんな時に思い出したい内容です。

あなたは最近、厳密に型指定された関数型プログラミングの世界を知り、これはすごいものだと思いましたね。プログラムを1、2回書いたりとか、ライブラリを1、2回作成したりとかの経験を経て、コツをつかみつつあるでしょう。IRCを始め、毎日新しい用語や考えに触れていることでしょう。学ぶべき概念、探索すべきライブラリ、コードのリファクタリングを行う方法やインスタンスを作成するための型クラスなど、新たに学ぶことは尽きません。

あなたは社交的な人ですから、前に進み出て自分の学んできた素晴らしいことを周りの人と共有したいでしょう。また、十分勉強したおかげでステートメントが真(true)か偽(false)かの区別もつくようになり、世の中から偽のステートメントを消し去りたいと思っているでしょう。

本当にそれがあなたのやりたいことですか? あなたがしたいのは、人を助けたり、人に素晴らしいことを教えたりすることですか? 自分が面白いと思ったことを人と共有したいのですか? それとも、自分が成長していると感じ、プログラミングが上達していると確信し、人より知的で多くの知識を持っていると実感したいとか、また主流な言語に一石投じることで、自分がニッチな言語に執着しているのは間違いではないという確証を得て安心したいのでしょうか? もちろん、あなたがやりたいのは前者ですよね。でもきっと後者を望んでいるあなたもいるはずです。私の経験では、誰だってそういう部分を持っていますから。これは私たちのエゴであり、すごいことをする原動力にもなりますが、でも同時に私たちを邪魔したり、私たちに馬鹿なことをさせたり、最悪の場合、本当に大切なことを話し合う時の妨げになる可能性もあります。

Haskellには素晴らしいアイデアが詰まっていますが、そのアイデアを基盤にしているわけではありません。アイデアをどのように扱うかという教養を基に構築されています。他人を蹴落とすことではなく、自分のやり方を探るという考え方に基づいているのです。ダメなアイデアをけなすのではなく(どれだけダメでも)、結論としてダメなアイデアを回避する方法を例示するのです。

関数型プログラミングでは、証明は否定によってではなく構築によって成されます。関数型プログラミングを教え広めたいと思うなら、また、ライブラリやプロジェクトを作っている同業者たちと生産的な議論をしたいなら、この倫理を知っておくとよいでしょう。

何かしらを学んできたあなたですから、隣に座っている開発者よりも知識があるでしょう。もしくはそう自負しているでしょう。では、周りの人にも学びたいと思わせるにはどうしますか? Haskellは頭がいい人のための言語だと相手に伝えるなんてことはしないでしょう。この言語を使えるんだから自分は頭がいいなどとも言わないでしょう。こう伝えるのです。人は間違えやすいから、そういう私たちのためにこのような型があるのだと。ソフトウエアは複雑化していて、私たちの古い頭では対応しきれないから、論証して間違いを見つけるのにはこの型に一役買ってもらおうと言うのです。もし相手が間違いを見つけるのに型など必要ないと言うようであれば、あなたは型を必要とする自分よりもずっと賢いんですねと言いましょう。さらに、コンパイラの力を借りれば、あなたが型を使わないで済むために費やしている能力の全てを、もっと素晴らしく、壮大でクリエイティブなアイデアを生む方に注げるのにと伝えるのです。

Haskellを使うことでスマートなことができますが、だからといってこれが賢い人のための言語というわけではありません。この言語はシンプルさとスマートさを併せ持つ言語であり、私たちは時にシンプルさを求め、時にはスマートさを求めます。でも私たちは賢くあることに特別に重きを置いてはいません。クロスワードパズルを解いたり、難しいバッハの前奏曲を弾いたり、タンゴを学んだりするみたいに、ただ楽しいだけの場合もあります。難しいことを可能にするために、シンプルなものはシンプルなままにしておきたいのです。

Haskellは”より数学的な”言語などではありません。そう、本来の意味では、プログラミングというのは数学なのです。ただし、誰かがこれに対して異論を唱えたとしても、それはその人が馬鹿だからでも意地悪だからでもありません。プログラミングは数学じゃないと反論するのは、過去に数学に対して嫌なイメージを植え付けられてしまったせいなのです。そのイメージがどういうものかというと、人々が”数学”という言葉を盾に、彼らが優秀でない、学習能力がない、考え方を理解していない、と責め立てるというものです。でも、ここには大きな勘違いがあります。数学自体は計算ではありません(それはコンピュータがすることです)。あるいは、単なる抽象的な記号でもないですし、Haskellの必須条件というわけでもありません。それどころか、Haskellを使うことで、数学の面白さを発見できる可能性もあります。”数学が難しい=プログラミングも難しい”といったような等式は捨て去りましょう。むしろ、プログラミングは楽しいものであり得るし、だから数学だって楽しいはずだ、と考えるべきです。ここで一部の人は、プログラミングの要素は数学だけではないと反論するかもしれません。もちろんプログラミングには、設計や創造性、それに足したり引いたりする作業の側面もあるでしょう。でも意外に、教科書的な発想の外に出ると、これらもまた数学の実践的な要素であると考えることができますよね。

知人にHaskellの優れたプログラマで、コンピュータサイエンティストとしても有能な人物がいます。でも、彼の線形代数の知識は非常に限られており、圏論も習得していません。つまり、線形代数や圏論はもちろん1つの手段 ではありますが 、だからといって優れたHaskellプログラマになるための 必須条件 ではないということです。圏論が必要になってくる唯一の場面は、世界から巨大なカテゴリ的、及び数学的コンセプトを拾い上げ、他の人が同じ苦労をしなくても済むよう、それをプログラムとして落とし込む時くらいでしょうか。あなたが待つのさえ厭わなければ、この作業はする必要もありません。いずれは誰かがあなたの代わりにやってくれるはずですからね。

知識を伝えて普及させるための最も重要な点(最も難しい点というわけではありません)は、それが 全ての人 を対象にしているということを強調することです。年齢も経験も、こだわりが強くても興奮しやすくても、あるいは数学の素養が不十分であっても関係ありません。それから、たとえ場を荒らすような人が現れても、全ての人を信じ、誰も責めないでください ^(1) 。誰かを攻撃すれば、それがゆくゆくは中傷やへりくつの土壌を作ってしまうことになります。そうなると、次の荒らしも現れるでしょう。結果的に、他意のない第三者が少し間違ったことを言うだけで、後味の悪い口論へとつながることになってしまうのです。

最も難しく、2番目に重要な点としては、自分のプライドをかなぐり捨てるということでしょう。教える立場となれば、相手の考え方や感じ方に共感しなければなりません。知識を広めることが第一の目標であれば、教える際の自分の言動に対しては、絶えず批判的な目を持つことが重要です。そして、それができているかの評価を下すのは自分ではなく他人です。あなたは他人の意見を信じるしかありません。これは難しいことですよね。もし誰かがあなたに反感を覚えているようであれば、それは紛れもなくあなたの責任です。あなたの発した一言が、誰かを傷つけたり攻撃的であったりした場合も、その相手を怒らせたりがっかりさせた原因はあなたにあります。今は宇宙的な真理として、”傷つける”という言葉の抽象的概念を論じているのではありませんよ。あなたが、自分の望むようなコミュニケーションを取ることに、具体的に失敗したということを論じているのです。ですので、批判があればそれを受け入れ、気分を害した人がいれば(怒らせたという事実だけでなく、その原因となったあなたの言動についても)謝罪してください。そして、そのいきさつと結果を、以降の糧にしましょう。

ちなみに、もし誰かを不快にさせてしまった場合、既にあなたに対する評価はがた落ちでしょうから、不快になった理由まで相手が説明してくれるかは分かりません。この時、相手に理由を丁寧に尋ねる分には構いませんが、説明を強要するのは避けましょう。相手の振る舞いや態度を見れば、その人がどのような状態にあるかは予想が付くはずです。大抵の場合、相手がどのように感じたかの理由まで知る必要はありません。とにかく相手がそう感じたという事実を認識し、それを重く受け止めてください。どうしても何らかの答えが欲しければ、自分自身に聞いてみましょう。答えが見つかれば、それが自分を変えられるか考えてみるのも手です。見つからない場合は、答え探しを諦めることも覚えてください。

注意してほしいのは、相手はあなたの言動を不快に思っただけであって、存在そのものを不快に感じているのではないということです。これをはき違えると、保身的な反応を取ってしまうことになります。”戦うか逃げるか”という姿勢は、明快な考えと共感する能力の障害になるだけです。場当たり的な反応をしないためにも、気持ちが高ぶっているのであれば、少し散歩でもして気分を落ち着けてください。

これで納得できましたか?人によるかもしれませんね。あなたの目標が、全てを理解し、客観的な真実については全ての人の同意を得たい、ということであれば、まだ納得はされていないでしょう。逆にあなたの目標が、可能な限り幅広く多様で、感じがよく楽しいHaskellのコミュニティを作り、思慮に満ちて相互に敬意を払うような雰囲気の中でお互いに交流したい、ということであれば先に述べた内容は、まさにうってつけだったと思います。

仮に、ほんのささいな(と自分では思う)ミスをした場合でも、それを社会的な交流の場において、あるいは技術的な具体性を持って、迅速に謝り、ミスした言動を撤回しましょう。そして、その際は率直に行うようにしてください。失うものといえば、あなたのプライドくらいでしょうか。そんなことを気に掛けるのはあなたくらいのものです。では、逆に得るものといえば?それは誠実さです。他人をこき下ろしたり、視点をずらしたりする安っぽいつかの間のスリルよりも、この誠実さこそがあなたに達成感をもたらしてくれるものとなるでしょう。

どんな理由にせよ、時にはあなたたちの会話が言い争いへと変わることもあるでしょう。そうなった時点で、相手はあなたと話したくないと思うかもしれません。相手が悪いのか、自分が悪いのか、それともどちらも悪いのか、そんなことはどうでもいいのです。言い争いから身を引くことができるようになりましょう。経験から、より良いコミュニケーションの取り方や険悪なコミュニケーションの避け方、常に明るく前向きでフレンドリーでいる方法を学びましょう。人の陰口を言ってはいけません。ろくでもない衝動的な行為を誘発してしまうだけです。その代わりに、どうやって自分が変われるかを考えるのです。

あなたは自分の自尊心に手を差し伸べる必要ありません。自分自身を証明する必要性を感じるかもしれませんが、その必要はないのです。大抵の場合、他の人はあなたを評価するよりも他にやることがあります。あなたにはそう思えない場合でもです。あなたは自分には才能があり、知識を得てプログラムを構築し、それがじきに世間で認識されるということが分かっています。ですが、誰もあなたからそれを聞きたくありません。そうしたことを聞けば聞くほど、人々はあなたの話を信じなくなり、あなたが 本当に 望んでいることは遠のいていきます。あなたが望んでいるのは、エゴを満たすことでも偉くなることでもなく、何かすごいことを 成し遂げる ことです。もしくは何かすごいことを純粋に人と 共有する ことかもしれません。むしろ手を差し伸べる必要があるのは、あなたが話している相手の自尊心です。彼らは自分の能力や価値に自信があればあるほど、新しいことを進んで学ぼうとするでしょう。その結果、他の人と同様に、自分の知識には限りがあり偏っているということを前向きに認識するのです。あなたも新たなことを積極的に学ぶためには自分を信じなくてはいけませんが、より多くの学習者を育成したいのであれば、彼らにも自分自身を信じるよう教えていかなくてはいけません。

知識とは強制的なものではなく、楽しいものです。時間とやる気があれば、誰でも身に付けることができます。教えるばかりでなく、学び続ける姿勢が必要です。知らないことはまだたくさんあるのですから(知らないことがなくなってしまったら絶望的です。次に何を学べばいいのでしょうか?)。あらゆる意見を尊重できるようになりましょう。どれも経験に基づいた意見であり、そうした経験は私たちに何かを教えてくれます。動的型付けの推奨によりJIT技術は飛躍的に成長しました。数値の最適化に興味があるのなら、C++やFortranで開発されたプログラムに目を向けましょう。あなたと同じく私もHaskellで書く派ですが、大切なのは ツール ではなく アイデア であり、アイデアはあらゆるところから見つけることができます。

実際、学ぶことは山ほどあるため、私たちは特定のツールや領域、言語やコミュニティについては時間を費やす価値がないと言って排除し、学ぶ方向性を決めてしまいます。そうしたものから学ぶことが何もないのではありません。あまりにも多くのオプションを一度に評価しなくて済む抜け道として、そう言っているのです。確かに深く掘り下げていくには知識の領域を狭めることも必要です。ですが、他の人たちが別の領域を進んでいることには感謝しましょう。彼らの知識が後に役に立つかもしれません。

ネット上でプログラミングについて話している人がいたら、彼らは最先端を走り技術や知識に興味があるのだといえます。たとえあなたの意見が彼らと同じではなくても、互いに学べることは必ずあります。時間や場所によってはアイデアを共有できず言い争いに発展してしまうこともあるかもしれませんが、それでいいのです。また別の機会があるかもしれませんし、ないかもしれません。大きなネット上の世界にはたくさんの人がいます。その全員と友達になる必要も、全員の指導者になる必要もありませんが、誰かの敵になることは避けましょう。あなたの時間も相手の時間も貴重なのですから、新しくて素晴らしいことを学ばずに嫌な思いをして過ごすのは時間の無駄です。

このアドバイスは一度限りのものではありません。新たな知識を人と共有したい時、いつも私たちは世間で受け入れられている知識を、声高々に一気に覆したい気持ちになります。そして、その知識がお粗末であればあるほど躍起になります。ですが、自分が寛大な聞き手であり熱心な先生であれば、より良い知識を教え広めるだけでなく、その過程の中で、より学び、楽しむことができるでしょう。Rilkeの『若き詩人への手紙』の1節を少し変えると、”必要から湧き出た知識は良質である。知識に対する評価は、その発端の本質にあり、他にはない”

この記事をより良いものにするために手を貸してくれたHaskellに関わる皆さんに感謝します。皆さんからのサポートを具体的に示唆するのは控えたいと思いますし、私のこの個人的な意見が幅広いグループの方たちの意見であるとはまだ言えず、グループ内や私に対しても個々の点で意見が分かれていると思うので、皆さんの名前は伏せておきます。


  1. このアドバイスは普遍的ではないと指摘を受けました。明らかに、このアドバイスには偏見や徹底的な嫌がらせ、悪意のある行為といった、より辛らつな反応を受けるに値する部分もあるでしょう。ですので、このパラグラフは技術的な課題について語る場合にのみ当てはまるものであり、 私よりも いいアドバイスができる人がいる他の多くの領域には当てはまらないものと見なしてください。

監修者
監修者_古川陽介
古川陽介
株式会社リクルート プロダクト統括本部 プロダクト開発統括室 グループマネジャー 株式会社ニジボックス デベロップメント室 室長 Node.js 日本ユーザーグループ代表
複合機メーカー、ゲーム会社を経て、2016年に株式会社リクルートテクノロジーズ(現リクルート)入社。 現在はAPソリューショングループのマネジャーとしてアプリ基盤の改善や運用、各種開発支援ツールの開発、またテックリードとしてエンジニアチームの支援や育成までを担う。 2019年より株式会社ニジボックスを兼務し、室長としてエンジニア育成基盤の設計、技術指南も遂行。 Node.js 日本ユーザーグループの代表を務め、Node学園祭などを主宰。