【本】なぜエンジニアは生きづらいのか

最近のお仕事がグダグダで、「あ、今おれ上司に信用されてないな」って思うことが多いのでいろいろ読みました。

うまくいかないときは、自分の考え方や進む方向が間違っていて、どこかから別の考え方を取り入れる必要があるというのが持論です。あと、Mac Book Airが壊れて修理中で、プライベートでプログラミングしづらいので本を読むくらいしかやることがありませんでした。

上司は「顧客」だと思いなさい

直球なタイトルです。一番印象に残っているのはこのくだりです。

しかし、「成長したい」という言葉の背後には、「育ててもらいたい」という受け身の発想が見え隠れしています。これは、仕事のプロとしてはマイナスと言っていいでしょう。

給料をもらって仕事をする以上、それはまぎれもなくプロであり、その仕事ぶりは常に他人から評価される対象となります。 自分がいくらのお金を稼げるのかは、自分が決めるのではなく、常に相手が決めることになります。

最近はWEBアプリやAPIの部分の実装をしていたのですが、自分の得意分野(あくまで周りとの相対評価ですが！)のデータ周りで勝負できないかと誘導したいと思います。また、タスクの整理等を他の人に任せきりで、本当は実装する必要の無い機能に手間を書けてしまったり、周りからみても「与えられた仕事をするだけ」みたいな感じのアレでした。

今の会社はこの本にあるような「実業家」としての考え方が学びやすい環境ではあると思います。ただ、エンジニアとしては成長しづらい環境だなあと思うことがあり（糞みたいな技術的負債があったり、ノウハウが明文化されてなかったり、教育制度が整備中だったり…）、技術志向の強い若手は、もっと腕を評価される別の会社にすぐ移っちゃうんじゃないかと思ってます。

上司は「顧客」だと思いなさい: 出世する人はじつは会社に雇用されてない!

なぜアーティストは生きづらいのか

バンドマンの知り合いの印藤さんにすすめてもらった本です。若手のインディーズバンドマンのサポートもされている方で、この本のイベントにも関わっているそうです。

（余談ですが、特にインディーズのバンドマンには全然WEBでの告知等のノウハウが無いそうで、私も何かの形で手伝えないかと思ってます…が、特になにもできていません。何かアイデアがある方は連絡いただけると嬉しいです。）

エソラブログ更新(ΦωΦ)=3https://t.co/4RBlYNFf9L

『【レポ事。】2016.6.29(水)『なぜアーティストは生きづらいか？』NAGESEN MEETING』#esola pic.twitter.com/Updgif9hcc

— マタヒラ@esola (@esola_matahira) 2016年7月5日

一言でいうと、「練習では遅刻するくせに重要なライブでは絶対に遅刻しない奴とか、自分にとって重要なことにしか集中できないファンキーな性格の奴いるだろ？そういう奴の才能が活かせるように受け入れてこうぜ！」って本です。大学の優秀な先輩がこんな性格だったし、プログラマーにも一定数いるので共感しやすいです。

なぜアーティストは生きづらいのか? 個性的すぎる才能の活かし方

最近私はRubyのプログラマーなので、「多様性は善」という感じで良かったです。

SQLアンチパターン

技術研修と称して、普段の仕事をサボっていろいろ作れるそうなのでDB周りの設計などを勉強しようと思って何冊か読んどきました。

分析用データをいろいろなところから集めるバッチ処理を作った際、「誰だよこんな適当なスキーマ決めた奴は!」「なんでテスト用のDBのテーブルスキーマが間違ってるんだよ！」という憎しみを感じていたので、自分はそういうものを作らない人間になりたいというモチベーションです。

特に面白かったのは、「2章 ナイーブツリー」で、親のコメントに対して子のコメントを残すDBのデザインパターンについての話です。ネットワークの有向グラフの枝リストのようなテーブルを別に用意して、親子関係の木構造を表現するのがエレガントでした。

あと、3章の「railsとかの影響で、とりあえずidってカラムでprimary key設定する人多いけど、ちゃんとユニークになってるキーでprimary key設定しようよ…」って話とか、徳丸本とかにも書いてるSQLインジェクションの話とかも面白かったです。

SQLアンチパターン

こちらの本も読んでいます。（第3まで理解してれば実務上そんなに問題ないと書いてはいましたが）○○正規化が多すぎてよくわかんないです。

達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ

Amazon Web Services 定番業務システム12パターン 設計ガイド

前述の技術研修でAWSのサービスをいろいろ使うことになるので、「とりあえず一発読んどくかー」って感じで読みました。あと、TableauとRedshiftを使った分析基盤の話も載っていたので。

Amazon Web Services 定番業務システム12パターン 設計ガイド

オンラインデートで学ぶ経済学

社会科学系の面白い話が載ってそうだったので読みました。割と無難な感じの内容でした。

オンラインデートで学ぶ経済学

全然関係ないですが、知り合いのアメリカ人のオタク（私のオタク文化の師匠です）が、「今ルームシェアしてる人は、昔プロフサイトに趣味:UNDER17(桃井はること小池雅也の音楽グループ)って書いてる人が他にいなかったから知り合って、日本来る前から友だちだった」って言ってて、「理想のオタクフレンズや…」って感動しました。

情熱プログラマー

「Javaのプロフェッショナルって言ってる人でも、Javaがどう動いてるのか理解してない人多いよね」みたいな感じで煽ってくる本でした。

「何かのスペシャリストであるということを、単にほかのことを知らないという意味で使っている人が多すぎる」

— 黒めだか (@takeshi0406) 2016年7月1日

同期の優秀なRubyハッカー（ポール・グレアムとか好き）が読んでないそうで意外でした。

情熱プログラマー ソフトウェア開発者の幸せな生き方

この中で『達人プログラマー』がしきりに勧められていたので、そちらも読もうと思います。R友だちが達人プログラマーに興味を持ってるそうなので、彼が読み終わったら借りようと思います。

wakuteka.hatenablog.jp

Rubyのしくみ

情熱プログラマーを受けて「普段Ruby使ってるのに、裏の仕組みを全然理解してなかったな」と反省して読んでます。

本当はPythonで似た趣旨の本があればそちらを読みたかったのですが、無かったので、この本を読み終わったらPythonについて勉強しようと思います。Pythonは統計等のツールとして、Rubyは仕組みやコンピュータサイエンスの本も多いのは、言語の文化の違いなのかもしれませんね（単にRubyが日本生まれで詳しいだけなのかもしれませんが）。

Rubyのしくみ -Ruby Under a Microscope-