Githubは遊園地

しかも入場無料。遊び放題。ディズニーランドよりも楽めるんじゃないだろうか。

コードを読んだり動かしたり、IssueやPRを送ったり。そんなことを繰り返していると、永遠にGithubだけで遊べそうな気がしてくる。事実、そのとおりなんだろう。

Githubは「設計図共有サイト」である以前に、無料の遊園地だ。今さらながらそのことに気付く。こいつはすごい遊び場だと。

何も真面目くさって考える必要はない。遊園地なんだから。

 

僕らは「OSSへの貢献」の意味を履き違えていないか

Contributeとは、まさにその名の通り、貢献するという意味だ。

人の役に立つ。尽くす。助ける。それが本質であり、全て。

僕らはそもそも、ここを勘違いしていないだろうか。

たとえば就職に関して言うと、OSSへの貢献を採用基準にしているIT企業も多いかもしれない。たしかに分かりやすい基準ではある。

だけど本当は、エンジニアとしてのキャリア、技能、ステータス、そんなものはOSSへの貢献とはまるで関係ない。「貢献」の本質はそんな場所には存在しない。

なぜ Contribution という言葉が使われているのかを、考え直してみよう。

「OSSへの貢献」というと、僕自身も以前は、どことなくハードルが高いイメージを持っていた。

「すごい人達が、すごい開発をしてるんだろうな」というイメージ。

だが違う。実際のところは、もっとフランクに、雑多に話し合うかのように開発を進めているレポジトリが多いように思う。

貢献の形は色々ある。

たとえば1個のスクリプトに、裏技指定みたいな、隠れた環境変数指定を見つけた。それをREADMEに1行追加する。それだけでも「貢献」だろう。

たとえば動作に問題を感じた部分に関して、黙らずにIssueを送る。これも貢献のひとつだ。逆に問題を見つけたのに黙って見過ごすことは、悪のような気がする。

Contributionは人のためならず?

たとえば、あなたのPRがマージされた時に「認められた気持ち」になるかもしれない。「やったぜ、OSSに貢献してやった!」と思うかもしれない。

だけどごくストイックに言えば、それもどこかおかしい。OSSへの貢献とは、別に自分が認められたわけじゃない。「人の役に立てた」。ただそれだけだ。

僕らエンジニアは、もっと本来の「貢献」にコミットして良いはずだ。

 

「理想のエンジニア像」なんて答えられたらいいね

僕には、理想のエンジニア像なんか存在しなかった。なので不意に聞かれるといつも困っていた。

やろうと思えば、てきとうに聞こえの良い言葉を用意しておいて、てきとうに並べ立てることだって出来るだろう。だけど小細工で何を言っても、本当には思っていないことを言うことになる気がしてた。

だが今日ふいに、言葉が浮かんできた。

「子供みたいに、プログラミングや問題解決を楽しめるエンジニア」

これがしっくりと来たし、腑に落ちた。

言葉が思い浮かんでから5分経っても、10分経っても、まだ意識の反発が起きていない。

今まで思い浮かんだ言葉は全て、思い浮かんだ瞬間には「これだ」と思ったものの、全て10秒ほどで腐ってしまっていたのに。それらとは歴然の差だ。

この言葉を見返すと、なんだか噛みしめるように、じわじわと喜びが溢れる感じがする。

これは僕にとって現時点で、たぶん最も真実味のある理想像なのだろう。

ところでなぜ「エンジニアの理想像」って答えるのが難しいんだろう。

それはそもそも、自己定義が難しいからだと思う。

たとえばチームでも、インセプションデッキが難産になることがあるように、自己定義は骨の折れる作業だ。そして、最初から答えがあるとも限らない。チームならばどこかには必ず目的があるだろうが、個人がエンジニアをやっている理由なんて、実はあってないようなものかもしれない。

そして答えを出そうとすると、固定観念が邪魔をする。どんな答えを出したって、なんだか自分には合わないような気がしてくる。

陶芸家が壺を作っては割るかのごとく

これは全ての自己定義によくあることだが、答えは意外なところから出てくる。世間的に正しそうなイメージや、流布しているイメージではなく、自分の中から出てくる、真実の声をもとにするのだから。

「これも真実じゃない」「あれも真実じゃない」と何度も答えを捨てていくのだ。そしていつか出てくるかもしれないし、出てこないかもしれない。頑張って探している時には見つからないが、準備が整えば自然と見つかるようなもの。自己定義は、どこに消えたかわからない忘れ物みたいだ。あるとき部屋の片隅からひょっと出てくる。

嫌にならない程度に真剣に、忘れてしまわないぐらい程度にゆるっと、自己定義する準備ぐらいはしておきたいもの。

君はGithubに草を生やしているか

自分の場合、今は publicでの contributions がほとんどない状態。外から見た時になんとも寂しい感じ。以前、自分用のpublicレポジトリを一気に整理して消してしまったのが悔やまれる。なので今後はどんな無為に思えるレポジトリだって良いから残しておこうかなと考えている。

プライベート勉強用のレポジトリ向けでもなんでも良いので、草を生やしておきたいと思った。「コード書いてますよ!」と外から分かるようにしておきたい。それに、自分で芝生を見るだけでもモチベーションが上がるし、楽しくなる。どうせならエンジニアの勉強は楽しい方が良い。

個人勉強用レポジトリに気軽にPRを作ったり、OSSのちょっと気になるIssueを送ったり、どんどんやろう。エンジニアにはきっと気軽さが必要だ。

github.com/YumaInaura

private レポジトリを含めた時

スクリーンショット 2018-06-30 12.31.40.png

private レポジトリを含めなかった時

スクリーンショット 2018-06-30 12.31.54.png

 

 

 

若いうちの環境構築の苦労は買ってでもしろ

たとえばオフで勉強のモチベーションが上がらないとしたら、うまく動く環境がないせいじゃないだろうか。

快適な動作環境さえ作ってしまえば、こっちのものだ。動作環境というか、快適に手を動かせる準備さえ整ってしまえば。あとはやりたい放題。ハイウェイに乗ったみたいなものだ。

エンジニアの勉強でも、渋い部分と、甘い部分があるということに気付いているか。単に苦しいだけでもなく、単に楽しいだけでもない。今が苦い味わいだからと言って、ずっとそうだとは限らない。なので僕らはいち早く甘い部分に到達したい。そして掘り進む渋皮のトンネルを。

最初に苦労を味わっておけば、あとは甘い部分を堪能できる。ボーナスステージに移行する。環境構築の苦労は買ってでもしろ。

まあ、むしろ最初の苦労さえ甘く感じられたなら、そいつが最高なのだけど。

精進あるのみ。

背伸びしないエンジニア。なるべく難易度の低い技術書を読もう。

読まない技術書より、読む技術書。

永遠に読みこなせない般若心経より、読める瀬戸内寂聴の新書。

スクリーンショット 2018-06-27 8.12.22.png

自分の実力を過信しない。

自分自身、昔は「難しい技術書を読みこなせた方が格好良い」と思っていた時期がある。

技術書を読むことはただの自分に対するポーズで、なんとなく「エンジニアっぽいことをする」ための、漠然と行為だった。

洋書のマズい翻訳の読みにくささえ、ありがたがっていたかもしれない。今思うと。

だけど現実的な課題のために技術書を読む時は、難易度は低ければ低いほど良い。「自分は頭が良くて、難しい本でも読みこなせるはず」なんていう妄想さえ捨てれば、謙虚になり、小さな入り口を見つけられるはずだ。

まずは「自分は何も分かっていない」「優しい手ほどきが必要だ」という見地に立とう。何も知らないからこそ学習する。自分だけでは分からないからこそ、人の手、書籍の手を借りるのだから。

低い山から登り始めた方が良いし、まずは低い山を見つけないと、山登りは先送りされ続ける。

 

 

自己陶酔できるエンジニアほど成長する

たとえば、今さら jquery のチュートリアルなどをやってみる。そして「HTML要素を操作することができたぜ!」 という満足感にひたってみる。

言い方は悪いかもしれないが、こういった低レベルな事柄に、どれぐらい満足を感じられるかということ、自己陶酔できるかということが、エンジニアの成長の鍵なんじゃないだろうか。

「まだチュートリアルの基本中の基本をこなしただけじゃないか」「何が出来てもほとんどライブラリの力じゃないか」「jqueryを極めるには一体これから、どれぐらいの時間をかけなければいけないのだろう」「今更jqueryなんか学んでも、何の役にも立たないかもしれない」なんていうことを考えていると、目の前の達成感なんかは、ものの数秒で吹き飛んでしまう。

特に僕のように厭世的な性格だと、なかなか一個ずつの達成を喜ぶことが難しい。一瞬の達成感のあとに、その10倍もの自己否定がチェーンしてくるからだ。

だけど最近は思う。そんなに未来のことまで見通さなくても良い。頭の中でめぐる未来は、どうせ皮算用にすぎない。それならば、どうせなら、目の前の低レベルな達成を祝おうじゃないか。「俺すげー」という錯覚にあえて浸ろうじゃないかと。たぶんきっと、それが答えだ。エンジニアに必要なのは達成感だ。原始的な欲求が満たされることだ。

ところで低レベルという言葉は、エンジニアの世界では必ずしも悪口じゃない。単にレイヤーの違いを言い表しているだけだ。

もっと低レベルなことを喜ぼう。自己陶酔しよう。ほんの小さな全能感に浸ろうじゃないか。

エンジニアの仕事を好きになるコツは、自分の本能、好き嫌いに敏感になることだ

たとえばGithubのコードを見ると落ち着く、特にJavascriptのコードを読むと、なんていうことに気付くかもしれない。だけど逆にdockerのドキュメントを読むと頭がくらくらする。というような違いがあるかもしれない。SSL周りの話を聞いていると興奮するかもしれないし、Go langを触っていると退屈するかもしれない。「What is Fluentd?」を読んでまるで冒険に出るような、果てしない浪漫を感じるかもしれない。

これらは全て例だ。個人の趣味趣向やコンテキスト、習熟度によっても反応が千差万別に変わるということなど、説明するまでもない、と説明する。

エンジニア自己啓発。エンジニアリングをしながら「心が落ち着く」「刺激を感じる」「面白い」「楽だ」というシチュエーションを探してみよう。自分の好き嫌いに敏感になろう。たとえそれが一見、分かりづらいものだとしても、ちょっとばかり複雑な条件分岐があるとしても、もし法則性があるのならば、理解することだって可能なはずだ。もしダンジョンに宝箱があるのなら、開くことだって可能なはずだ。

僕らはエンジニアの仕事が本当に好きなのだろうか。それとも嫌いなのだろうか。だけどここでお考える。「エンジニアの仕事が好き」とか「嫌い」とか、そんなざっくりとしていて、広範囲な分類は、あまりにもざっくりと無意味だ。「エンジニア」という1単語にまとめられる要素なんて、幾百万通りあると思っているのだ。どうだ。

本当に重要なのは、自分の本能に忠実になること。損得勘定を捨てて、プリミティブな本能を磨いてゆくこと。原始的な欲求、初期衝動を大事にすること。結局はそれが究極的な得なんじゃないだろうか。

そうエンジニアの仕事は、常に自分の本能と向き合う仕事だ。僕らが向き合っているのが抽象的なコードや、白黒に点滅するコンソールだからこそ、なおさらに動物的な本能が必要なのだ。逆説的に。と僕は思う。君はどうだ。

 

スクリーンショット 2018-06-25 20.12.07.png

エンジニア同士の競争をやめて 太陽を浴びるように成長しよう

人とは競争しないほうが良い。競争には限界がある。あまりにも副作用が強すぎる。常に疲弊、自己嫌悪、憎悪、嫉妬がつきまとう。

だが特にエンジニアという仕事は、何かと人と比べてしまいがちな仕事だ。上には上がいるし、またその上がいる。例えば1万人のうち9999人は1位を取ることは出来ない。これが100万人であれば999999人は首位を取ることは出来ない。自明の理である。

「他のエンジニアとの競争」という概念に取り憑かれたが最後、この呪いは強力だ。競争をし始めたが途端に、僕らは成長に支障をきたす。毒薬だ。ポイズン。

いまじんおーるざぴーぷる。仮に生まれたばかりの樹木が樹齢100年の大木を見て「僕はあんな風にはなれない」と考えたら、成長することなどまず出来はしない。競争という毒薬のおかげで、僕らは太陽を浴びて、すくすくと成長することさえ出来ない。もっとエンジニアリングを太陽のように崇めて、何比べることもなく成長できたのなら良いのに。

僕らエンジニアは別の種類の植物なので生長の早い遅いには違いがある。育ち方もまるで違えば、種の付け方も違う。「世界で一つだけの樹」と言えば安直にすぎるが、まさに多様性こそがエンジニアリングの鍵である。太陽を浴びるように成長したい。それが僕のエンジニアとしての願いだ。

キルフェボンに花束を。

日曜の夜だ。少し酔っている。惜しまれる気持ちを残しながら、日曜日を終える。悪くない終わり方だ。プログラミング言語のことを考えながら、眠りにつくなんて、エンジニア冥利に尽きる。

ところで今日は昼寝をしながらtd-agentがログを吐き出す夢さえ見ていた。脳とログファイルが一緒くたになったような変性意識と出会ていた。ボーイ・ミーツ・ガール。

この日曜夜になって、この休日中、pythonを触れなかったという思いが脳裏によぎる。そう、エンジニアならば、勉強をしたいことや、勉強すべきことは山のようにある。こいつを苦と感じるか楽と感じるか。この山々を、たとえば、ホールケーキのように感じるのならば、エンジニアという仕事は毎日がケーキを食べ続ける日々だ。

エンジニアおいしん坊。エンジニア食いしん坊バンザイ。エンジニアは美味しい仕事。キルフェボンに花束を。