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

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

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

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

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

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

言葉が思い浮かんでから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を触れなかったという思いが脳裏によぎる。そう、エンジニアならば、勉強をしたいことや、勉強すべきことは山のようにある。こいつを苦と感じるか楽と感じるか。この山々を、たとえば、ホールケーキのように感じるのならば、エンジニアという仕事は毎日がケーキを食べ続ける日々だ。

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

エンジニアリングは農業だ。エンジニアの勉強はゆっくりと、農家の心ですれば良い。

休日中にゆっくりと、エンジニアの勉強が出来る幸福を、今日は噛み締めている。

理解が遅くても、どれだけ時間をかけても、誰かに怒られることもない。休日中は1%たりとも「出来るエンジニア」である必要もないし、それを気取る必要もない。自分で自分を許しさえすれば。責めることさえなければ。

なので休日中は、改めて基礎的な勉強をすることが出来る。スターバックスでコーヒーを飲みながら、SSL周りの複雑で入り組んだ世界の扉を開くことも出来る。好きなルートで好きな中腹まで、山を登ることが出来る。いつ折り返したって良い。何でもやりたい放題だ。しかもこれが、仕事にも役立つ副作用があるというのだから。

そもそもエンジニアリングの勉強には時間がかかるものだ。基礎に基礎を基礎で積み上げる世界なのだから。理解できなことは、すぐには理解できない。たとえそrがもどかしくても、一足とびに山の頂上までたどり着くことは出来ない。1個ずつブロックを積み上げる必要がある。エンジニアリングは今季の世界だ。

なので大事なのは、実は悠長な心じゃないだろうか。書き間違いではない。悠長な心だ。エンジニアというものの一般的にイメージに反して、特に重宝する資質というのは、決して切れる頭でも、高スピードの理解力でもない。じわじわと愛情を持って、植物を育てるような農家の心なんじゃないだろうか。

エンジニアリングは農業で、エンジニアは農夫だ。僕らは植物を育てている。種を巻き、季節に感謝し、そしていずれは収穫するのだ。しかし収穫だけが成果ではない。農業の本質は耕すことや、育てることそれ自体にあると思う。

文系エンジニアですが何か?

自分は文系エンジニアだと思う。理系でバリバリのエンジニア気質というわけではない。どちらかというとチームで協力して働くことが好きだ。

だけどエンジニアには文系の能力も必要とされる。理系能力と文系能力のどちらが必要とされるか?よほど技術寄りの仕事でない限りは、この比率は5:5程度ぐらいにはなるんじゃないだろうか。つまり理系能力と同程度には文系能力が必要とされる。

人に説明する能力。人の話をよく聞く習慣。基本的な報連相。チームメンバーを信頼すること。プロジェクトに貢献しようとする気持ち。人間関係を疎かにしないこと。文系能力といった表現が合っているかどうか分からないが、技術的要素以外の能力が非常に大事だ。

それに、実は文系能力というのは広義でのエンジニアリング力にも深く関わっている。たとえば実装理解や要件把握。文系能力が低ければプログラミングは出来ても要件定義は出来ないし、人が何を望んでいるかが分からなければ、満足の行くものを提供することは出来ない。

手段と目的を履き違えるな。「迅速な価値の提供」なんていう格好良い言葉に騙されるな。それは業務のための隠れ蓑だ。実は僕らは仕事をしながら、人の役に立つことがとても好きだ。貢献することは人間の喜びの本質だ。それがエンジニアの世界においては、ちょっとだけ専門的な言葉で、手を変え品を変え説明されているだけという話だ。

閑話休題。ということで僕は自分を文系エンジニアだと思っている。何か問題でも?もしかしたら就職や転職には不利かもしれないが、エンジニアの仕事なんて要するに、覚える必要のあることを覚えれば良いだけ。だいたいどんな仕事でもやれば出来るんじゃないかという自信はある。まあ証明なんてできないが、そもそも人間にはすべてを見通すことは無理なのだから、そんな自信ぐらいは持っておいても良いだろう。

ところでここまで書いたが基本的にエンジニアという仕事は好きだ。エンジニアリングという名の下にMacBookのキーボードを触れているというのは幸福に尽きる。プログラミングは自己表現の一種だと思っている。コードによってインタプリタにメッセージを送り、他の人にメッセージを送るという行為は、自己表現として軽やかだ。純度が高い。す、好きだ。好きです。バスケが。

改めて。文系エンジニアですが何か?人には長所と短所というものが存在する。僕は自分の文系的能力を強みにエンジニアをやっていきたい。いや、強みが文系能力にも存在するということを認識しておいた。しかしそれに頼るな、甘えるな。いちばん大事なのは、いかに広義のエンジニアリングを愛するかということだ。そのためならどんな自己認識だってしよう。