新しい技術を恐る恐る使う。ES6とか。
技術的経験の学びの整理方法
Serverside ES6というタイトルでLTをした。
www.slideshare.net
近頃外部に情報を発信するときはポエムが多く、
どうしても技術的な色が薄かった。
今回はちゃんと技術寄りのトピックを扱ったが、エモさが足りなかった。
技術的な学びよりも、よりポエムっぽい
内容のほうが、より広く学びが共有できる反面、
専門分野での自分の経験値を高くし、
自分より上の専門家の方々からの目線が、
「本当にこいつちゃんとやってんのか？」という
懐疑的なものにならないように、
バランスをとるのは非常に難しい。
ただ一つ分かることとして、まとまったコードを書いた後に、
- 自分がもともとどういうモチベーションでその技術に取りかかり
- その過程でどういう感情を持ったのか
- 結果どういう技術を手にいれたのか
という整理の仕方をして、
配分を2:4:4くらいで整理すればいいのだろうと思い始めた。
LTのほうでは、前述の通り感情面の話が薄かったので、このブログはその補足。
この技術を扱ったモチベーション
結論から書くと、フロントエンドからの逃げだ。
巷で流行りのReact.jsを触っていて、
コンポーネントにバンバンAPI fetch用の関数とかを詰め込んだら、
「責任が分割できてないし、密結合になってるから
これはコンポーネントじゃない」というお叱りを受けたことがある。
それを皮切りに、Fluxデザインパターンを学ぼうと思い、
スター数と成長速度からしてReduxだろうと思い、Reduxを触った。
ただ、途中でreact-routerと一緒に使い始めたあたりから、
stateがどこか無限の宇宙に消えてしまい観測不可能になったので、
もっと軽めのものでトライしたほうが速そうだと思い、Facebookのflux実装を使っていた。
が、徐々に書いていくにつれ、
自分が作りたいと思うアプリがこの技術を必要としていないこと
コード量、かけた時間というコストに対して、得られるものが自分にとって大きくなかったこと
技術自体の流行り廃りが速く、自分の手に余るものだったこと
という課題が表面化してきて、フロントエンドフレームワークの
最前線のキラキラした世界（捉えようによっては逆）から、戦線離脱しなくてはいけなかった。
技術的自己顕示欲
これは自分のやりたいことと技術を結びつけるという
当たり前の手段選択を、「新しい、流行の技術を触ったら、なんだかかっこいいぞ」という
顕示欲に目が眩んで、見事に玉砕したということに他ならない。
自分のコントロール下に置けないファットまたは
流行り廃りの激しいライブラリ・フレームワークを使うことは、
まるでポケモンでジムリーダー３人目を倒した段階で、
友達からレベル100のポケモンを譲り受けて、
結局いうことを聞いてくれないような、手にあまる事態にしかならない。
（フロントエンド界隈の人が自己顕示欲が高いとかいう話ではない。
むしろ流れを追いつつも基礎ができてないと
常にしがみ付くのが難しいはずなので、純粋に敬意しかない。）
ほぼ100%、その課題にぶつかるにもかかわらず、
技術的な顕示欲に目が眩む問題とどう戦うか、
ということを考えるいいきっかけになると思って、
一旦フロントエンドの話を置いて、サーバーサイドで「安全地帯」からES6を学ぼうと思った。
ES6をサーバーサイドで使う
これは正解だったと思う。
というのも、フレームワークという周辺部分にとらわれず、
純粋にES6のシンタックスの便利さを実感する機会になったからだ。
expressのソースコードを大部分ES6に置き換えたが、
特にメリットを実感したのはモデル部分だった。
Arrow Functionとunderscoreの合わせ技のおかげでビジネスロジックが
（見た目上）簡潔に書けるのと、コールバック関数への抵抗感を和らげてくれた。
何よりClassesがあることで、自分は「モデルオブジェクト」を扱っているのだという
感覚を持ちながら、迷うことなくコードが書き進められた。
慎重にドキュメントを読む
今回はドキュメントは公式に近いソースを読むように努めていた。
あるいはソースコードに当たること。
ここでいうと、MDNやそれこそES6のドキュメントだと思う。
もちろんこれはドキュメントが少ないのもあるが、
フロントエンド由来のサンプルコード自体はゴロゴロ転がっていたので、
実際にはサンプルには事欠かなかった。
ただ、それらすべてを一旦置いといて、
できるだけ公式の範囲におさめるのは非常に難しい。
公式のドキュメントが平易なことはそうそうない。
シンタックスや機能の背景についてある程度知ってる周辺記事の方がよっぽど助けになる。
一方で、結局戻ってくる先として公式ドキュメントを使わないと、
こういう鮮度の高い技術は誤解を招く。
例えば今回だと、Generatorsで結構困ったのが、同期的に書けるという記述が多く、
最初のうちはPromiseみたく非同期処理をうまく記述できるものかと思っていた。
実はイテレーター的なものだというのを、ドキュメントをちゃんと読むまではっきりわからなかった。
この問題は最初から公式に当たれば解決するかというと、多分そうではない。
公式ドキュメントは一番わかってる人によるまとめであっても、
それが必ずしも一番わかりやすいとは限らない。
結局は自分の経験値を公式ドキュメントと照らし合わせて、
自分の言葉で言語化する作業が必要だ。
そういう意味で、「手を動かすしかない」ように思えた。
新しい技術に恐る恐る触る
タイトルに補足をすると、ES6自体は、
「その界隈からすれば」別に新しくはないと思う。
でも一旦その界隈から離れてみると、
だいぶ新しい技術として認知されてるようだった。
（まあこの際、ES6は記法であって技術ではないかもしれないが）
安定版が出ている事
一定期間メンテナンスが持続する事
実際に課題を解決をする事
変化が止まっていない事
広く「まあ新しいよね」という印象を持たれている事
の５つの条件を満たすような技術はレア度が高い。
だがそういう技術でない限り、別段触れなくてもいいのだろうと思い始めた。
低レイヤーだったり、設計思想的なところを勉強するのに時間をかけつつ、
いざ上記の条件を満たしてると思われる技術が出た時に飛び付けるように、
情報感度を高く保ち続けたい。
というか今は飛び付けるほどのベース知識が足りてないから、
技術的自己顕示欲を捨てて、できるだけ堅実に学ぶようにしないと今後が辛い。
不自由なプログラミング
プログラミングは自由ではない
ここ最近、 「プログラミングを勉強して自由な働き方を手に入れよう！」 みたいな趣旨の記事や広告を良く見かける。 大方プログラミング教育系の事業が増えてきているからだと思う。
それに対して非常に違和感を感じる。 というのも、自分の中でプログラミングは楽しいものではあっても、 決して自由と近しいものではないと思うからだ。
自由に一番近い職業と言われると、確かにそうかもしれないが、 それでも他の職業と同様にエンジニアは不自由だと思う。 （とはいえ新卒なのでなんとも言えない）
ここ最近プログラミングが楽しくないと感じる機会が少なからずあるので、 その理由と合わせて違和感の原因を整理しておく。 なので、この記事の正確な主旨は、「僕が」プログラミングを不自由に感じる場面とその理由、だ。 （下記は自分の技術力のなさを棚上げしている。このタイミングでまさかりが飛んできたら死ぬ。）
嫉妬やコンプレックス
これが一番大きいと思う。
自分は文系だし、コンパイラを自作したことも、アルゴリズムの授業を受けたこともない。 ハードウェアの話になるとついていけないことが多いし、 「型がぁ〜」「メモリ効率がぁ〜」とか言われると、 相手がどんなユースケースを思い浮かべて話しているのかたまにわからなくなる。 JavaScriptやった後に型が欲しくなるとかならわかるが。
つまりは、相手にあって自分にない、学術的な背景に対して、 僕は大きなコンプレックスなり嫉妬がある。
文系というひとくくりにはできないが、少なくとも理系の人より モラトリアム的な学生生活を送れる可能性が高いことは間違いないと思う。
その分、自分は今の専門と学生時代の専門が離れていることに、 少し寂しさに似たようなものを覚えるし、学校で習ったら 多少違ったものになっていただろうとも思う。
ただ最悪なのが、「 理系に進んでいてもうまくいかなかっただろう 」 という確信に近い考えが、たまに浮かぶことだ。
僕は演繹的な考え方ができない。
ここでいう演繹的な考えというのは、 「理屈を説明されて、そのあとどう応用するかなんとなくでもわかる」という意だ。 特にアルゴリズムを勉強しようとして、何度も挫折している理由はここにある。 以下の記事でいう、「役立つことが分からないと先に進めない子供」というのが僕のタイプだ。 togetter.com
数学とプログラミングの能力はあまり相関がないというが、実際問題 考え方の面では、相関があると思う。 どうしても「これなんの役に立つんですかねえ」という疑問が真っ先に頭の中に浮かぶ。 しかも、その「役に立つ」が、ユーザーから見てどう役に立つのかわからないと全く理解が深まらない。 ページの表示速度が何%早くなったとかならまあまだしも、 「こういう書き方をすれば美しい！」という観点から技術を評価することが、僕にはあまりできない。 （あまりと書いたのは、たまに理解できるからだ。 Rubyでenum.inject(:+)なんて書き方を知ったときには、 さすがにカッコイイなあと感じた。 かっこの中身が梅干し食べた人の顔文字みたいになっていることも含めて。） 理屈で言えばすごいんだ、わかるでしょ？これくらい効率化するんだよ？ と数字や処理の流れを見せられても、そこでどういう 情報が行き来するのか、生きたものを見ない限り理解できない。 そういう意味で僕は帰納的な理解の仕方だと思うし、 演繹的な理解ができるエンジニアの方に対して、 嫉妬心を覚えることが多い。
説明下手
- なんの役に立つのか（前述）
- つまりどういう取引が行われるのか
- というかお前の言っている言葉はなんなんだ
という疑問について、３段階くらい深堀しないと まともな答えが返ってこないことが多い。 これは人に聞いた時よりもググったときの方が多く感じる。
ググれと言われても、ググってわからないことの方が多いから聞いていると言ってもいい。 その分人に聞いてわからないときは、自分の聞き方が悪いのか相手の説明が悪いのか判別がつかない。
「ウェブの原理なんて、元来人同士のコミュニケーションを置き換えたものなのだから、 頭の中で人同士のやりとりに言い換えられたら、理解が捗るんだよ」 と言った某氏がいたが、本当に目からウロコの考え方だった。 ただそういう説明事例は非常に稀である。 あるいは、 howdns.works
このサイトのように、裏側でどういう登場人物が いるのか明らかにしてくれれば、とても理解がはかどるのに、と思う。（めんどくさいけど）
あとは、単純に用語の問題だ。 名前空間とかもっと言い方あったろ。 モジュールとか、レキシカルスコープとか、 最初聞いてもなんだかわからない単語に出会ったとき、 エンジニア特有の衒学的な雰囲気が垣間見えて逃げ出したくなることが多かった。
このように、自分の理解できない説明が多すぎるのと、 それが自分が原因なのか相手が原因なのかわからないことによる ストレスが尋常じゃないため、学びのモチベが下がることがある。
所詮は技術であるということ
世の中には「プログラミングは手段でしかない」と感じる人がいる。それは別に構わないんだけど「プログラミングそのものが目的である」人が相当数いて、かつ、新たなテクノロジーの多くはそういう人がいないと生まれてなかったこともわかってほしいな、と思う。
— Yukihiro Matsumoto (@yukihiro_matz) 2015, 7月 13この言葉を見て、僕は所詮手段としてプログラミングを見ているのだな、と感じた。 とはいえ、自分がエンジニアとして働こうと思ったのは、 技術自体に面白みを感じたという点もなくはないので、むしろ賛成派だ。 プログラミングを完全に手段として見ている and ( 軽くしか触ったことがない or 触ってない )のに、 軽々しく共感の空気を醸し出すビジネスサイドの人がいた場合、ちょっと心の奥で反発してしまう。
ただ、どこまで行っても結局スターになる要因は、技術ではなく事業だと思う。 まれに技術自体を追求した結果、うまくいってる事業があるように見えても、 それはただ単にその技術自体が、ユーザーのニーズに合っていて、 市場規模が十分あったからという話であって、 大概はそうじゃないと思う。
周囲のエンジニアに「将来どうしていくの？」と聞いても、 エンジニアとしての道を追求する人が、 存外多いというか、ほとんどがそうであることに驚いている。
それだけの覚悟があるのを尊敬する一方で、いずれか タイプライターのように消えうる職業にしがみついても 良いものだろうか、と思ってしまう。
何より、サービスという箱庭の中でユーザーがどういう行動を見せるのか、 その満足度を上げて、サービスを確固たるものにするには どうしたらいいのか、形骸化しない、経済効果のある サービスを作るにはどういう仕組みを導入すればいいのか、 というような話の方が、内心はずっと興味がある。
いつか事業サイドに移っていかないと、 泥舟に変わる技術に足を取られたり、 自分が成し遂げたいことを見失ってしまったまま、 事業に従属するパーツとしてのエンジニアになってしまうのでは、と恐怖感を覚える。
それでも、自分に確固たる力がないこと、 技術自体にも魅力があること、その途上にあることをわかっているので、 どこかで踏ん切りをつけなければと思っても、 その目処は全く立たないため、喪失感を伴うジレンマに襲われる。 そのせいか、一歩離れて技術を冷めた目で見てしまう自分がたまにいる。
コードが読めない
僕はコードが読めない、というわけではないが、読むのに苦労する。 なぜ苦労するのかというと、
- 通常の文章のように順序よく読めるものではなく、変数・メソッド単位で縦横無尽に目を移さなければならないこと
- パラグラフ的な読み方がなかなかできない
の２点が原因だと思う。 コードジャンプ機能がないと色々絶望することが多いし、 コメントがない or 変数名がわけわからないと本当に悶絶する。 （名付けは死ぬほど難しいというか自分もできてないが。）
r7kamuraさんのRubotyの初期commit logを追っていた時に、初めから READMEの冠詞にまで気をつけているのをみて、感動に震えたことがある。 ただ、それは極端に良い例で、ほとんどのコードは順序よくひとつなぎで並んでいるわけではないので、 「コードリーディング」というのは、断じて文章読解とは近くないと思う。
加えて、僕自身パラグラフリーディングというのは苦手で、 「ここのコードは適当でいいか」とか、「ここの処理は詳しく読もう」という割り切りが なかなかできない。
概要把握的な読み方をしたいが、だいたい浅い理解で終わっているだけで、 すごい大きなまさかりが飛んできて涙目になることが多い。 ぼちぼち、コードリーディング履歴を記録したり閲覧できるサービスでも 作ってみようかなと思うくらいにはフラストレーションが溜まる。
職業としての普通さ
冒頭の 「プログラミングを勉強して自由な働き方を手に入れよう！」 という触れ込みに戻るが、 働き方としてそこまで自由とは思わない。
恵まれすぎて働き方に身体が肥えてしまったのかわからないが、少なくとも僕の場合、 ノマド的に自分が居座る座標をxからx'に移したところで、モチベーションは特に変わらない。 むしろ、思ったより制約が多いし、前述のようなストレスもあるので、ただのおしゃれな（に見える）職人でしかない。
天才か、あるいはすごい秀才はこれが楽しいのかもしれないが、 それはあくまで強者の特権だと思う。
逃げの手段としてプログラミングを選んだ場合、 不自由どころかひたすら不幸なだけのプログラミングをする 羽目になると思っている。 あるいは、ただの代替可能な労働資源になるだけなので、 他と変わらない普通の職業人になると思う。
だから、どこか矛盾する気もするが、技術自体に興味があったり、 突き動かされるものがないなら、エンジニアになるべきではないんだろうなと思う。 ましてやそういったことを考えずに、ただエンジニアになれと焚き付け煽動するのは、 もう倫理的によろしくないんではないかなと、思ったりする。
おわり
以上のような理由から、 よくプログラミングやりたくねーなーと思うこともあったりするが、 それでもプライベートで好きにコード書いてるときは、 なかなかノったりするので、別に不自由でもエンジニアでいいんじゃね？と思う。 最善の選択肢を取ったことは間違いないが、自分が後々誰かを不自由に追い込まないように覚え書きを残しておきたかった。。
Dropboxみたく、ディレクトリ監視してリモートホストに転送するやつ作った
Rubyのgem。名前はSyncと人っぽい名前を合わせてSynciaにした。
概要
あるディレクトリをデーモンで監視して、変更があったら指定されたリモートホストのディレクトリに転送する。
require 'syncia' syncia = Syncia.new('./local_dir') syncia.set_remote_info('timakin', '123.456.78.91') syncia.set_remote_dir('/home/timakin/remote_dir') syncia.run
作ったきっかけ
- Dropboxがやっているファイル同期の中身が気になったからつくった。
- Boxのリードエンジニアと話したときに、「ああいう難しそうな技術ってどうやって勉強するんですか？」って聞いてみたら、そんな難しくなさそうな反応をされたので、作ってみようかな、という意欲が出た。
- てかなんか微妙な顔されて、自分の不甲斐なさにイラっときたのもある。
- なんか画像ファイルとかたまってきたときに、さくらサーバーとかにぶっとばして保管してくれないかなーとか思った。
学び
Unixプロセス入門とかその辺が何の役にたつ知識なのかわかってなかったが、 実際に触れてみる機会があったことで、そういうレイヤーの技術に関心が向いた。 なんかそれっぽいもの見つけて勉強する。
常々思っていたが、こういう小さいきっかけで、より低いレイヤーへの興味を深掘りしていくの大事だと思う。
テック系ニュースをTerminalから見るコマンド、TechStackを作るついでに、Go入門からHomebrewでの公開まで体験した。
なぜ作った
Goの勉強。
あとRSSで毎日2000記事とか上がってくるのいい加減だるいので、主要サイトの主要記事だけterminalから見たら効率がいいと思った。
Goいい
Nodeのコールバック地獄にはまりかけた後に、goroutineとchannelを使うと至福だった。
@tenntennさんの記事が恐ろしく参考になった。
パッケージ公開
homebrewでインストールできるよ。
brew tapした後に入れてね。
これについては以下を参考にした。
めしのキーワード検索をしてくれるHubot、コックカワサキ(cook_kawasaki)を作った。
教養としてではないプログラミング╭( ･ㅂ･)و ̑̑
お前なんかハッカーじゃない╭( ･ㅂ･)و ̑̑
こういうプレゼンを第９回若手Webでした。すごくエモいプレゼンを
若手精鋭の皆々様の中で、ましてSmartNews様のオフィスでやるとか恐縮千万だった。
お前なんかハッカーじゃない╭( ･ㅂ･)و ̑̑
この記事ではプレゼンに関する詳細と、最近良く見るプログラミングそもそも論に乗じるポストをする。
ただ、僕自身としては謙虚とかではなくまじで本職の方々（おっさん）の指針になるような何かを言える立場には無いと実感しているので、
そこは他者にお任せしたい。代わりに自分の体験から、教養としてのプログラミングから、仕事としてのプログラミングへの溝というか、その門に立つに当たって思った感想を述べていく。
プレゼンに関する補足
BOSSについて
これなんですが、上長ってわけじゃなくて、メンターや先輩社員全員を指します。
本当に仲良くさせていただきました。隣でパイナップルや納豆食っててもなぜ怒らないでいてくださったのかわからない。
感謝の念しかなくて、一人に絞れないほど様々な方に、部署横断的にお世話になりました。
あと後述の某R社ポストでBOSSパクリがあった。絶対に流行らないと思ったから書いたのに、スベる被害者を増やしてしまった。
ググる前に聞くなよボケ問題
大丈夫流石にそこまでアホじゃないです。
心持ちの問題で、ググる前に聞くくらい前のめりで質問したい欲を持たないと、
「うーんもう少しググったり考えてから聞こう…...」でズルズルいって、２時間経過とかあるので、
もうググる前に聞くくらいの勢いを持って丁度いい、ってことです。
インスタンスすらわからんならすぐ聞けよ問題
後述です。
某R社を５日で首になったとかwwwくっそwwww
笑えない。
全然笑えない。僕は３年前おおよそこんな感じだったのだが、本当に良く社長やメンターは
僕に席を用意してくれたままでいたと思う。感謝の念しかないし、貢献できなかったことに対する、申し訳なさみたいなものがある。
まだ「文系エンジニアです！雇って！」みたいな輩（昔の僕みたいな）が蔓延する前だったので、多少多めに見てくれたのだろう。いやほんと勤務時の僕の態度とか思い出すとまじで赤面しかない。絶命したくなる。
クビになったこの知り合いについて
今回のクビになったこの人は、知り合いでもあるので言及したい念にかられた。
全体の所感としては、痛み分けな感じじゃない？と見ている。
まず、当人のレベル感でいうと、傍目から彼を見ていて、うーんまあたしかにGitとかバックエンドの開発は難しそうにしていたなあ、というのが見ていて思ったこと。
Gitでまともに開発ができないのって、Gitを知らないか、既存プロジェクトへのアサイン経験がないかだと思うんですが、前者だとしたらそれ、ドットインストールすらやってないってことですから、それはだめなきがする。
この記事を見るに、やれる資源を徹底的に消費した感じはしない。だってドットインストールですら初期の方でunix操作入門あるので。CLIツール使ったことなくて、GUIだけで過ごしてきたっていう人が多いことに、僕わりと最近驚いてます。エンジニア力が足りないとかじゃないんですよ。あの黒い画面かっこいいじゃないですか。
「個人開発をやっていた」というのも、個人開発環境で、フレームワークで生成されたものに見た目上の付加価値を与えるということをしていて、個人受託とかではなく、普通に「個人で勉強してた」というのの延長線上な気がする。
だから、面接の時に盛ったとかそういうのは存じ上げないが、能力に関するミスコミュニケーションはあったのかもしれないな、と思っている。そこは彼に一因ある。
もしこれが全部会社側の要因のように見えたら、それは彼が被害者意識を強く伝えてしまった結果かもしれないので、そこを誤解させないようにして、もっと別でチーム開発を鍛えてから別のインターンに行った方が、、、と、知り合い（前日にあってたくらいの距離感）という目線から言いたい。
某社側について
ただ、じゃあ某R社の件で会社側に非がないのかというと、それも違う。
就職目的でインターン生を取っているとはいえ、「うーんわかんなかったらググってね」程度でメンタリングしてたのだとしたら、良い印象は持たないな、と思う。
「インターンは子育てする期間じゃなくて、お前ら学生を見極める期間だぞ」なんて意見もあるのだが、同時に「学生が会社を見極める期間」でもある。
即戦力が欲しいんだ！！っていうのは、会社経営してる側からしたら最もだと思うのですが、エンジニアで即戦力な人は、学生で即戦力なんていらないわ〜って言ってる、バンバン中途で超優秀な人が入ってきている会社で技術力アップを目指すから、難しいなと思います。弟子入りみたいな感じですよね。
てか今書いて気づきましたけど、ここら辺わりとむずいですね。わりと最終的にどっちが譲るのかって話になりそう。
某社は学生インターンを多々雇っているので、わいわい言ってる学生があそこに多いのも知ってる（でもサンプル数一桁ですごめんなさい:D）。
そこで感じたのは、「ググってね」という接し方が悪いというより、「ググってね」って言ってわからない人を、「君は即戦力だね！！いいね！！」と言って持ち上げた挙句すっごい勢いで切り捨ててしまう捨て駒感と、それを踏まえて一向にいい人だけ採用するために門戸狭める方針を固めないことに原因があると思っています。
捨て駒感と言ったのは、この会社からお誘い通知が来るエンジニアがやたら多いので、そういう印象を受けたということです。
なのでこの件は、両者ともにミスコミュニケーション問題が絡みあってあんまよくない結末を迎えてしまった感があります。
プログラミングは楽しいかね？
僕は楽しいです。今は。
でも本当に嫌いな時期がありました。
Hello, World!で画面に文字が表示されるのが面白い？僕は面白くありませんでした。むしろこの調子で学んでてエンジニアになれるのか超不安になりました。
多分これはジェネレーションギャップ的なところもあるのですが、小３の時にホームページ（ビルダーで作りました:D）を持ってはいたので、むしろこんなまどろっこしい遠回りをしなくちゃいけないのか、とHTMLに辟易した覚えがあります。そういえばビルダーの下の方に出てたHTMLも怖くていじれなかったなー。
某社で勤務してたとき、納期や下請けの都合上ストレスが溜まってる人を見て、僕はなんて世界に来てしまったんだ、絶対仕事にしないと思いました。
最強に嫌だったのは、ググってもググっても説明ヘッタクソな文章にしか出会わないことですよ。
ググるより先に聞くことが大事ってのは、ある種「ググって最初の３記事くらい読んで、公式ドキュメント読んだら、それ以上ネット上からはいい答え出てこないでしょ」っていう諦めから来た教訓でした。そのせいでメンターにはご苦労おかけして申し訳ないのですが、でもそれくらいが時間を無駄にせず、かつ一応調べましたと言えるラインなのかなと、肌感で感じています。
そんで、僕は上記の彼を応援しつつ、ちょっと不安なのは、そういう闇に深入りしてないままエンジニアっていいよね、って言ってないかな、という点が気になるからです。
意識高い系（企画したい系）へのヘイト
僕がそういう闇でもがきつつ今こうしてエンジニアとして生きようと思ったのは、僕を突き動かした、かつて所属していた学生団体というところの経験があったからです。学生団体ってなんでしょうね。自戒を込めた結果自己収束する究極体かなんかだと思ってるんですが、僕も以前籍を置いていたので、言いにくいところはあります。
ただ、他人の論理よりも自分の論理の方が優れているということで競い合い、かつその結果生まれた成果物（空論）に対しての大人からの評価は、「いいね学生っぽいね」というなんとも温いものだったのは事実です。僕は当時読書癖があって、大学１年の頃はその活動か、1日読書をしているかしかなく、何千冊という本を読んでいた分、触れた知が自分を経由して形になっていない虚無感を覚えました。（こう書くと本は冊数じゃない云々という話があるんですが、それは自己反省してノイローゼになりかけたので勘弁してください:D）
井の中の蛙というのを実感せざるを得なかった。自分が何も物を残せておらず、本当に怖くて堪りませんでした。
ただ、そこの危機感があったからこそ、あくまで続けてこれたんではないかなと思ってます。
教養としてのプログラミング
最近はCode.orgやら、様々な公的な支援のもと、プログラミングが教養としてみなされるように活動がなされているようですね。
すっごい賛成なんですが、現状のままだとこの結果生まれるものって、良くても「働くエンジニアは、こんな道を延々と進んでてすごいな！」って価値観が定着する程度だと思ってます。「クリエイティブな手段だ！プログラミング最高！」は、プログラミングの意味不明さへの憎悪ドリブン開発をしたことがないか、そこを乗り越えた人が言える、極端なポジショニングからの発言だと思っています。もちろん最初から憎悪の種を植え付けたら、スライムにイオナズン的な話で確実に死をもたらすので、門戸を広げて職業観を変えてく一歩でしかないな、そっから何人か職業としてエンジニアを選んでくれれば、大成功ってくらいに心に留めておくべきでしょう。
「１ヶ月くらいでプログラミング勉強したいんだけど、なんかおすすめの資料ある？」
いつもこの質問への答えは決まっています。「ドットインストールやってみるといいよ〜わからなかったら言って〜」です。
ですが、僕はこの質問に対して明らかな負の怨念を抑えつつ、発言しています。その怨念は、「Why あなた オンラインで受けられる講座すら調べない？」とか、「それがあったら苦労しない」という考えもあったりするのですが、それよりも僕個人の学習背景から特に生まれる怨念が一つあるのではないかなと。
つまり、「お前、片手間１ヶ月でエンジニアって本気で言ってんのか」という想いです。
こっから多少感情的になると思うので、読みにくさに関して前もって謝罪させていただきます。まず、この質問の際、「自分で作れる力はいらないんだけど、いざというときエンジニアとコミュニケーションは取りたくてさ」と言われると、僕は悔しさと憎しみに支配されます。僕が今まで見てきたエンジニアの方々のデスクは、技術書がいっぱい積んでありました。その前にはエラーに苦しみレガシーコードに苦しんでいる方々の姿がありました。本当に実力勝負でしかない世界で働いている人の姿は、混沌としていましたし、それを知らずに片手間でできると思って、質問の重みを知らない人がいた時に、僕の心に芽生えるのは殺意しかないです。清濁全て飲み込んで学んできたものを、そんなショートカット的にできるとも思えないし、そんな事実があったら信じたくないという、自己肯定感があるのかもしれません。
そういった「エンジニアの方とコミュニケーションとる」って、どういうコミュニケーションのことを指しているのかがまずもって不明です。コードも書けない地位だけの偉そうなビジネス野郎に虐げられる父の姿を見ているので、感情的になってしまいます。技術トレンドなんてすぐ変化するじゃないですか。設計なんてそんな柔軟にできないじゃないですか。「これをこういう仕様で実装してよ、ユーザーの意見だから」って言って、全部反映させてたらエンジニアがユーザーの声を聞く時間なんてないのに、そのエンジニアに対して、「もっとユーザー目線で」とか言ってくる偉そうな技術かぶれになる気なのか？あるいは人月でエンジニアの価値を測るプログラミングわかっる〜系経営者になりたいのか？と。
なぜエンジニアになりたいのか、と聞いた時に、「作りたいものがあって」とか「こういう問題意識があってさ」って言われれば、いくらでも薦めますし、仲間ができたわいわい！って感じで嬉しいです。でも、前述のタイプに関してはナイフのように鋭い意思をもって対さなければいけないと思ってます。
教養としてではない、仕事としてのプログラミング
僕はまだ、このテーマを書くにあたってふさわしい人間ではないと思います。だってまだ大学４年ですよ。経歴はさっきのスライドや、以下を見てもらえればわかります。
ご覧の通り、僕は社会人としてフルタイムで働いた経験がありません。
インターンとして学生の立場からコミットする際、技術的な学びには限界があります。本番環境のDBをいじれない、大規模なデプロイには関わらないとか、ありますよ。そりゃ大きな企業側からしたら当然です。その決定には全く不満はないです。むしろそれ以前のところで大手を振って学ばせていただいて、本当に感謝です。僕に授業でFORTRAN教えてくれた大学に対しての感謝は微妙ですけどね。
でも、僕ら「教養としてではないプログラミング」の一歩手前にたった人間が意識すべきなのは、自分が学んできた技術が豆粒のような基礎固めでしかないのかもしれない、という可能性です。職業としてのエンジニアに対しての評価軸で、僕が一番危惧しているのは、コンピューターサイエンス的素養です。これは文系エンジニアなんてことを言い訳にできるのは、学部をはっきり意識する大学生の身分までなんだろうな、という自覚があるからです。だからこそ、しっかりCSを学んで、フレームワークやライブラリの移り変わりに（特にフロントエンド）左右されずに、自分はエンジニアだと胸を張れるようにしなくてはならないのだと思います。
いやでもどうなんだろう、DHHに前メールを送ったことがあって、「エンジニアとして過ごしてくにはどういう立ち位置がいいんでしょう...」的なことを聞いたら、「俺レーサーだけど？:D」って返信されてなんとも言えない感じになったことはあります。
最後に、僕はこうしてエモくて自分の技術レベルからして偉そうに聞こえる話を書いたのには、エンジニアとしての意見表明をしなきゃなという勝手な使命感が端を発しています。周りのエンジニアは恐ろしいほど優秀です。今いるTranslimitという会社は、10名規模の会社なのにみんな楽しそうに8ヶ月で1000万ダウンロードかましたBrainWarsというアプリを運用してます。割とこの職場の方はブログを書くのですが、とんでもない技術力をお持ちでありながら、意見表明しないエンジニアは超いっぱいいます。バンバン技術ブログ書いていく人はいるんですが、もっとエモい領域で、共通項の多そうなテーマで意見発信していけば、まだ未熟な僕でも伝わるんではないかなと思っています。これから先もエンジニアの立ち位置を考えつつ締めて、コードを書く手に戻したいと思います。
╭( ･ㅂ･)و ̑̑
