Latest topics - outsider reflex

#しがないラジオ 2 Advent Calendar 2日目：OSSやると英語の訓練になったり公表できる実績積めたりするんじゃないかなって話

しがないラジオ2 Advent Calendarをご覧の方々、初めまして。しがないラジオsp.31でゲストとして出させて頂いた、Piroと申します。自分がどういう背景を持つ人間かについては、しがないラジオの当該回を聞いてみて頂けましたら幸いです。前後編で3時間はありますが……

しがないラジオ2 Advent Calendarの2日目は、「しがない」エンジニアになるためにあると良さそうな「人にアピールできる実績」の積み方についてのお話です。

つよいエンジニアって何だ？

さて。しがないラジオに限らず、エンジニア系Podcastを聞いているとよく「つよいエンジニア」というフレーズを耳にする印象があります。

強いとはどういうことか。人によって解釈にブレはありそうですが、「口だけじゃなく、形として実績が目に見えている」というのはわりと共通して言えそうな気がします。例えば、Googleのような著名企業でサービスやプロダクトの開発を主導しているとか、著名なOSSの作者（開発チームの一員）だとか、そういうプロジェクトに外部からパッチを提供しているとか。あるいは、何かの技術イベントを主催してるとか、技術書を（特に、商業出版の書籍を）書いてるとか。

で、いつかはそうなりたい、そうなるにはどうすればいいんだろう、と憧れを抱いている人が多いのかなと思います。

僕がそういう方にお勧めしたいのが、OSSの開発やコミュニティに実際に関わってみてはどうでしょうか？ という事です。既存のプロジェクトに関わるのも、自分で始めるのもどちらでもOKです。

「いやいや、ああいうのはつよいエンジニアの人がやる事で、自分みたいなペーペーがやるなんておこがましい……」そんなふうに思っていませんか？ だとしたら、それは因果関係が逆です。むしろ、OSSの開発に関わったから、その人は結果的につよいエンジニアになった、という風に考えてみて下さい。

始めるきっかけは些細な物

自分がしがないラジオにゲストで出させていただいた際に、CSSをやったりFirefoxのアドオンをやったりと、色々やってきたという話をしました。

少なくとも、これらをやり始めたときの自分は、決して人に尊敬されるに足る実績のある人物ではありませんでした。自分がやり始めたのはただ単純に、自分が使いたかった拡張機能を作者の人がそれ以上メンテナンスしてくれなかったから、使い続けたければ自分でメンテナンスする以外の道が無かったからです。

駄目で元々、うまくいけば儲け物という程度のつもりで始めた事でした。それで、運良くなんとか形になったので、OSSライセンスを設定して成果を公開した。それが自分にとっての「OSS活動」の原点でした。

ノーリスクで気楽に始められる

そう、僕が強調して伝えたいのはこの部分です。使いたい物がある。でもそれは壊れてしまった。誰も直してくれない。話に聞く限り、それはHTMLとCSSとJavaScriptできているらしい。技術要素の名前だけ聞くと、自分でも分かりそうな気がする。しかも自分でゼロから作らないといけないわけでなく、ついこの前まで動いていた実物のソースコードが目の前にある。駄目で元々、見様見真似で書き換えてみて、もしうまく行って動くようになれば儲け物。失敗しても誰も責めたり馬鹿にしたりしない。もちろん〆切も無い。

社会人になって見て改めて思いますが、仕事では、こんなにハードルの下がりきった状況はなかなか無いんですよね。

しがないラジオのどなたかのゲスト回や、EM.FMなどで度々、「失敗安全性」というフレーズを耳にする事があります。安心して失敗できる状況で、駄目で元々だからやれるとこまでやってみよう、そういう安心感があると人は挑戦ができて成長もする、という話です。EM.FMでは特に、「会社組織はメンバーに失敗安全性を提供するのが務めだ」とも話していたように記憶しています。

それに似た状況が、OSSの世界にはあります。役に立つ物なら少々粗があっても称賛され、役に立たない物は貶される事すら無く忘れ去られるーー恥として残らない。いくらでも失敗してよくて、駄目ならいつでも逃げ出せる。多少みっともない結果になった所で、誰も気にしてなんていません。失うものは、それにかけた自分の時間だけです。

先人に学べる・学べる素材が豊富にある

失敗安全性が高いという以外に、腕試しや学習の題材にする上でOSSにはもう一ついい所があります。それは、「OSSライセンスが設定されている既存プロダクトから、（そのライセンスの条件に従えば）無許可で勝手にコードを引用できるし、改変できるし、そうして作った物を公開もできる」という点です。

どう実装すればいいか分からない部分があれば、似たような事をやっているOSSのソースコードそのものを見て参考にできます。教科書に書かれたサンプルコードでは決して拝めないような膨大な生きた知見が、そこにはあります。

使いたい機能やプロダクトについて、整理されたドキュメントが無い場合も、むしろチャンスだとすら言えます。他人が見ても分かるような形の解説を書くためには、あれこれ調べてきちんと裏付けを取っていく必要があります。ソースコードの中や、コミット履歴、あるいは関連するGitHubのIssueやバグトラッキングシステムのチケットなどに散在している必要な情報を集めてきて、1つの筋の通ったドキュメントを書き上げた時には、そのコードを書いた元の作者の次に、世界で最もそれについての知見がある人になっているという事すらあります。

OSSの英語は難しくない

調べると言っても、Issueやチケットが英語で書かれていたら読めないじゃないか！と思う、英語に対して苦手意識のある方も多いのではないでしょうか。

でも、その心配は思い過ごしです。確かに、OSSについて調べていくとどうしても英語で書かれた文章を読まないといけない場面は多いですが、実はこれが意外と読めます。

何故かというと、APIのリファレンスやチュートリアルで登場する英単語というのは、よくよく見てみれば、自分が普段からカタカナで書いたり読んだりしているフレーズをそのままアルファベット表記しただけの物が非常に多いからです。

また、文法的にも中学高校で習うような素直な書き方の文章が多いです。誤解や誤読を招きやすい皮肉っぽい書き方（読むのに高い英語力が要る）や、凝った言い回しのように読み取るのに頭を使わないといけない文章は、技術文書ではほとんど見かけません。技術英語は「誤解なく簡潔に技術情報を伝えるために書かれる物」なので、これは至極当然の話です。

でも、それに気が付かないで「うわっ英語だ！」とアレルギー反応を示して読む前から拒絶してしまっている人は多いです。その偏見に負けないでちょっと勇気を出して読んでみる、それだけでそういう人達を出し抜く事ができるんです。こんなにおいしい話はそうそう無いでしょう。

同じ事が、自分で書く英語にも言えます。気の利いた言い回しをする必要なんかありません。言葉で説明できないなら、スクリーンショットやスクリーンキャスト（動画）で説明してもいいくらいです。「上手な英語を書こう（話そう）」という事に拘らないようにして、「自分の目の前で起こっている現象を、とにかくカタコト英語ででもいいから伝えよう」「自分の考えている事を伝えよう」という事を第一に考えるようにしてみて下さい。不格好でいいんです、誰も笑ったりはしませんから。

題材・テーマは自分の身の回りに偏在している

とはいうものの、何の目標もなく「何かOSSを作ろう」「何かのOSSプロジェクトに関わってみよう」と言われても、途方に暮れてしまうでしょう。

そこでOSSの世界のもう一つの側面が活きてきます。それは、「まだ他の誰も解決に取り組んでいなかった問題を解決した物が、OSSの世界では重宝され、生き残る」という事です。

自分が何か未解決の問題（この機能が動かない、この動作がバグってる、こういう機能が欲しいのに存在しない、ドキュメントが無い、日本語のロケールがない、などなど……）に遭遇した時に、ちゃんとその原因を突き止めて、報告したりプルリクエストを出したり、あるいは自分で新しくOSSを作って公開したりする。やる前から「自分には絶対に無理だ」と諦めてスルーしたり誰かがやってくれるのを待ったりするのではなく、自分こそがその問題を解決する最初の人になれるという可能性を、常に心の片隅に置いておく。それだけで物の見方はずいぶん変わり、そういう視点を持った瞬間から、この世は未解決の問題に溢れた問題集となります。

その問題集をひたすら解いていくと、実力も付くし、解いた問題の数も積み上がっていって、いずれ「人に見せて恥ずかしくない実績」になります。そうして気がついてみれば、もうあなたも他の人から「つよいエンジニア」の一人と見られるようになっている、という寸法です。

何かに躓いた時にこそ、挑戦・アウトプットのチャンス

「問題」とは、期待される状態と現在の状態にギャップがある事を言います。この世の中は、技術的な事でもそうでない事でも、問題に溢れています。

自分は、「つよいエンジニア」というのは「いつかそうなる憧れの対象」ではなく、「今すぐなれるもの」だと思っています。何故なら自分にとって「つよいエンジニア」というのは、達成された身分や地位を示す物ではなく、「自分が遭遇した問題に対して、解決するために真摯に向き合う」という姿勢や生き方だと思うからです。

近頃、自分の観測範囲で「エンジニアはもっとアウトプットしよう」「アウトプットが成長に繋がる」という空気が強まっているなと感じます。閉じこもっているよりもアウトプットした方が良いという事は自分も同意なのですが、何でもいいからアウトプットすればいいかというと、それはちょっと違うんじゃないかなと思っています。というか、アウトプットする事それ自体を目標・目的と捉えるというのが何か違うと思っています。

何故なら、「アウトプットをするからつよいエンジニア」じゃあないんです。問題に対して真摯に向き合って解決に取り組んだ結果、自然な帰結としてアウトプットが発生するんです。

いや、アウトプットのハードルを無駄に上げたい訳じゃないんです。「このアウトプットは、する意味あるんだろうか……？」と悩むくらいなら、出してしまった方が絶対に良いです。まだアウトプットの経験があまりないという人が、アウトプットする事そのものに慣れるために、練習として何か無理矢理にでもアウトプットするという事も、最初は必要だと思います。

ただ、その練習フェーズは早く卒業した方が良いんじゃないかなと。「アウトプットのためのアウトプット」ばかり繰り返していても、それ以上の進歩は望めないんじゃないかなと。それがこのエントリを通して一番言いたかった事です。

まだ誰も解決してない問題に遭遇したら、ぜひ解決してその成果を公開してみましょう。そしてその時は、つたない英語で構わないので、英語で説明を添えておくといいです。世界中で他にその問題を解決した人がまだ誰もいなかったのなら、Googleがそれをクロールして、同じ問題で困っていた人が検索結果から勝手に見つけてくれて、その人の助けになります。OSSは、そういう事をやるのにとても都合がいいフィールドなのです。

自分一人でその一歩を踏み出してみるのが怖い、という人は、OSS Gateのワークショップに是非足を運んでみて下さい。OSS Gateは、OSS開発コミュニティでの活動経験があるサポーター達が、あなたがOSS開発に関わるための最初の一歩を踏み出す事を手助けする会です。そして、そこで最初の一歩を踏み出したら、今度はあなたもサポーターとなって他の人の一歩を踏み出す手助けをしてあげてください。

そうして問題の解決に真摯に取り組む人が継続的に増え、問題が少しずつ解決されていく事で、世の中は良い方向に回っていくのだと、自分は思っています。

以上、しがないラジオ2 Advent Calendarの2日目でした。これを読んで実際に一歩を踏み出して実績を増やし、「しがない」エンジニアになる人や、しがなくなくても自分の仕事に誇りを持って取り組んでいける人が増えてくれたら、幸いです。次の日の記事も楽しみですね。

あと、アドベントカレンダーとは関係ないのですが、先日のしがないラジオmeetupの懇親会で話した内容に端を発する、目標を持って活動をするという事についての自分の考えをまとめた別のエントリもあります。せっかく書いたものの、午前3時とか4時とかに晒したせいか、あんまり人目に触れてなさそうな感じで涙目なので、よかったら併せてお読み頂ければ幸いです。