ボ カ ロ で 懐 か し い 名 曲 は

【動画】ボ カ ロ で 一 番 の 神 曲 は：ひまねっと

便乗して書いた。反省はしていない。

自分が一番ボカロを聞いてた2007年～2009年の頃に好きだった曲（一部）を集めてみた。

本当はplay!2.1.1 + DBFluteの構成でアプリを作ってみたエントリーを書こうと思ったが次回に持ち越しである。

2013年振り返り

今年は社会人として、エンジニアとして色々と「初めて」なことの多い１年だった。

社会人として

フラットな関係で仕事を依頼する、されるようになった

今まではSIer,web制作会社にいたので、仕事の依頼はお客様からの「受注」でやっていて、何かを依頼する時はこちらから「発注」する形で他社のエンジニアやデザイナと一緒にやってきた。なので、どことなく金銭のやりとりが発生することから「上下」関係みたいなものがあって、その中でコミュニケーションを取って仕事をしてきた。別に下請けに傲慢な態度を取るとかってことはしなかったけど（お客様から見たら自分だって下請けだ）、それでもなんか一定の距離というか遠慮というか、そっちの事情はそっちの事情、みたいな所があって、同じものを作ろうとしてるのに違和感というか残念な感じがあった。

それが今年からは事業会社に転職し、営業・マーケ・デザイナ・エンジニアが全て自社の人間になった。その中で仕事をお互いに依頼する/されるようになり、そのコミュニケーションの仕方に最初戸惑った。どのように依頼すればいいのか、されればいいのか。入社した直後は他部署に何かを頼む場合（例えばこれこれの画面の確認をしてくれ、とか）も随分と堅苦しいもの言いをしていたように思うし、何が何でも期日を守らなければならないとか、言われたことは無理でも全部やらなきゃならないとか、受託開発で食ってきた人間のクセが抜け切れていなかった。

でもやってくうちに、事業会社の場合はみんなが同じ方法で利益を追い求めるのだから、個々の都合ではなく全体最適でタスクを捉えてどう進めるかを議論すべきだ、ということに気づいた。つまり、言われたから全部やる、ではなく、それが会社の為にどういう意味があるのか？を考えて議論して、やる内容や優先順位付けをできるようになってきた。他の部署もそういうものの考え方をして話をしてくれる。たまにそうでない人もいたりするが、その上司は分かってくれるので非常にやりやすい。一方で、受託開発と違ってその施策をやって、必ずしも売上が上がる訳ではないので、本当に効果があるかどうかビビりながらやったり、逆に数値が下がって慌てて切り戻すなんてこともある。それでも、今のフラットな関係で、みんなで同じ目的を達成するために議論しながら仕事を進める今のスタイルが好きだと思う。

 新卒氏のOJTをした話

今年の夏頃から諸事情で営業から異動になった今年入社の新卒のOJTを担当した。

後輩を持つのもOJTを担当するのも、社会人になってから５年目にして初めての経験で、仕事として人からプログラミングを教えてもらった経験が殆んど無かった自分としては色々不安があったのだが、その分得るのものが大きい経験だった。

最初の一ヶ月半は教育期間ということでjava初心者本の写経、webアプリ開発のための基礎知識として自分が講師をやった座学を数回、webアプリ開発課題をやってもらった。

本当はjavaの基礎に加えて、webサーバ・APサーバ・DBの連携部分などのwebアプリの基礎をじっくり教えてから課題に取り組んでもらいたかったけど、すでに他の新卒は業務に入っていた時期で時間がなかった。なので、Webアプリケーションの登場人物や、静的なホームページとWebアプリケーションの違い、データーベースの概要なんてのを座学でわずかにフォローしたに過ぎなかった。課題がギリギリ出来る程度の。

しかし、後に業務に入ってもらってから、この辺はもっと時間をかけてじっくりやっておけば良かったと感じた。業務に入ってからの共通言語になるこれらのレイヤーの知識が頭に入っていないと、タスクの内容も正しく把握できないこともあるし、「何となく」ロジックを直して動いた、で終わってしまっていたなと思うこともあった。この辺は反省材料として来年の新卒教育カリキュラムに活かしていく予定。

業務に入ってからは、スキル差というかベースとなるIT関係の知識の無さが問題になることが多かった。元々中途入社で固めてきた会社だったので、「エンジニアとしての常識」みたいなものがあることを前提に業務を回してきたけどそういうのが全くないメンバーへの対応は非常に難しいものがあった。主に自分がチケットを管理して新卒氏に振って自分がレビューする、スケジュールも管理する、みたいなことをやっていたが、Webアプリというものはサーバ側もフロント側のhtml,js,css、さらには使ってる外部のミドルウェアまで広く知らないといじれないもので、その辺をつまみ食いしながらタスクをこなしてもらっている状態で中々体型づいた知識の蓄え方をさせてやれなかった。

毎日３０分その日のタスクの振り返りをして、技術的に足りない部分はQA形式や自分個人が必要だと思うことを教える形でフォローしたけど、本当はここも週単位でテーマを決めてそれに基づいて講義形式で技術を叩き込むべきだったのだと思う。あまりにも言語の知識も足りてなかったし、コードを書く上での「作法」とかコードを追う上での勘所が分かっていないようだった。自分が激務で週２，３は終電帰りとかで時間がなかったと言い訳をしてしまえばそれまでなんだけど、申し訳ないことをしたと思う。教育担当になったのだから、自分のタスクを減らすことを上司に交渉してでも教育に専念すべきだったのだと思う。けど自分の仕事の裁量が大きくなってきた時期とも重なっていて、責任ややり甲斐が大きくなってきた中で、自分の業務を減らしたくないという思いもあった。結果として、中途半端になってしまって申し訳ないことをしたと思う。

結局そんな状況だったので、見かねた会社の教育＋サポート専門で入ってもらっているフリーランスのエンジニアにサポートをどっぷり頼む形となった。自分の至らなさを認めなくてはならず凄く辛かったけど、結果としては新卒氏のスキルアップという意味では良かったのだと思う。１２月末頃までにはwebアプリの機能保守という点では業務が出来るようになった。まだゼロベースで作れるほどではないが、前より大分総合的なスキルが深まったように思う。

11月末頃にエンジニア内でチーム再編があって、新卒氏は自分とは違うチームになって業務的にチケットを振ることは無くなって実質お役御免になった。ただ、週１でフォローアップをする時間を作ってそこでのフォローは続けている。そこでは、今やってるチケットの相談とか、チームの愚痴を聞いたりとか、UI設計やjsやフロントの実装がまだ弱いのでその辺の技術的なフォローをしたり、その新卒氏と他のエンジニアも交えて「javascript本格入門」の読書会を初めたりした。決して良いOJTトレーナーではなかったけど、次の新卒が入ってくる頃まではフォローを続けて、自分自身の「教えるスキル」の向上に努めたい。

エンジニアとして

人のソースをレビューするようになった

前職ではほぼ１人デコードを書いて自分でテストして自分でリリースするような感じだったのだが、現職からは１０数名のチームで開発している。

そこで当然のごとくお互いのソースをレビューするのだが、初めての経験だったのでどこまで突っ込んだレビューをしていいのか戸惑った。

とりあえず目的を満たしていればいいのか、クラス設計の適切さやメソッド名や変数名の適切さとかの細かい部分まで突っ込むべきのか、時間の成約があるなかでどこまでやるべきか迷った。明確な基準がある訳ではなく、個々人の裁量に任されていたので自分でそこは決めなければならない。

最初はチェックアウトしてローカルで動作させて問題なければ大方OK、ソースを見て「まぁこんなもんだろ」でLGTMとしていて、動作がおかしければ「大体ここがおかしいでーす」とかの大雑把な指摘で今年前半は良かった。メンバーのスキルも仕様理解度も高いメンバーで構成されていたからツーカーの会話で大体済ませられたし、どちらかと言えばこの頃は俺の方がマサカリを投げられまくっていた。

それが、チーム内のメンバーがどんどん他事業に行ったり中途で入ってきたりして入れ替わってきて、今年初頭と比べて殆んどのメンバーが入れ替わった今年後半においては、プログラミングのスキルが低かったり仕様の理解が不十分なメンバーが増えて、レビューでの突っ込みどころが凄く増えてきた。このクラスはこのパッケージに置いちゃダメなルールなの！Wikiに書いてあるでしょーが！とか、この処理はApache CommonsのUtil使って～みたいなレベルのツッコミをしなければならないことが増えたので、スキル底上げも兼ねて細かい実装レベルでレビューをするようになった。

先に書いた新卒氏のレビューなんかもそうである。レビューする時にRedmineのチケットのソースに延々と細かい駄目だしとなぜそれが必要なのか？を書くようになった。jsのイベントのbindの仕方がミスってて「ここでonでbindしたらajaxでリロードした時にbindされないから$(document).onでやった方がよくて、その場合もさらに。。」みたいな感じのことを書いたり。

他にも何度も使用するmatcherをクラスのフィールドで初期化しないとダメな理由を本人とっ捕まえてコンコンと説明したりしなくちゃいけないような場面も増えたが、結局チーム全体のスキルを底上げしていかないと良い仕事なんて出来ないので、レビューは今後も「細かく」「地道に」やる方針で続けていこうと思う。

オブジェクト指向をちゃんと意識するようになった

javaをガッツリ書くようになって、ポリモーフィズムの重要さとかデザインパターンの有用さとかがようやく分かった気がする。１年前まではクラスはせいぜい処理を一定の単位でまとめたものぐらいにしか思ってなくて、インターフェース？美味しいのそれ？って感じだったのだが、今は特定の機能を「いかに差し替え可能な実装にするか」を考えてクラス設計したり、必要に応じてインターフェース作ったり、ということが自然にできるようになった。たまに、今触ってるソースでも過剰に抽象化し過ぎているクラスもあったりもするが、抽象化し過ぎたものを具象化し直すのはそれ程難しくないが、その逆は凄くめんどくさい。一度、「こうやって作ったけど処理の最初の方で実装クラス分けて処理書くようにしたら内部の分岐がシンプルになるじゃん」みたいなケースがあって、ほぼ終わってたがそこからインターフェース書いて実装クラス作りなおしてやり直したみたいなことをしたことがある。テストも全部やり直しでめんどーくさいのだが、後から保守していく上では業務ドメインを細かく分けておいた方がやりやすくなった。ドメイン分析大事。けどDDDはまだ良くわからないので来年勉強して、部分的でも取り入れていきたい。

2013年に読んだ本

2013年の振り返りということで、今年読んだ本を読んだ順にまとめてみる。

amazonの購入履歴と後は個人的な記憶に基づいてまとめるので多少の過不足はご勘弁を。こうやって見ると今年はあまり本を読んでなかった。ネットの情報に非常に頼りまくっていた感がある。

紙媒体でしか得られない知識はまだ沢山あるので来年はもっと読まなないとなーと思う。

Java関係

 Effective Java

EFFECTIVE JAVA 第2版

2012年12月頃に購入。

javaやってる出来る人はみんなこの本読んでるイメージ。ピアソン社の日本撤退により日本語版が絶版になってしまったが、また来年２月に丸善出版から再販されるらしい。

昨年１２月に今の会社に転職して初めてまともにjavaを書き始めたのできちんとjavaを勉強しようと思ったのだが、javaの入門書は大体がプログラミング初心者をターゲットとしているので、説明過多で自分が知りたい「他の言語との違い」みたいな所が掴みづらい本が多かった。なので初心者向けじゃなくて、ちょっと知ってる人向けのjavaの本が欲しかった。

 なんていうリクエストを職場の先輩にぶつけてみたら紹介してもらったのがこの本。頭から読まず、ジェネリクスとアノテーションの章から読み始めた。この章だけはjava1.5からの新機能ということもあって、入門的に丁寧に書いてあった。

なぜジェネリクスとアノテーションが必要か？そもそもそれらはどういう役割なのか？どう使うのか？みたいなことが書いてあって非常に分かりやすかった。これ読まなかったら「Eclipse先生に叱られるから」程度の理由でジェネリクス使ってたし、アノテーションは「おまじない」ぐらいにしか思わなかったと思う。まぁ自分でclassからアノテーションを参照するコード書いてみればおまじないじゃないってことぐらい分かるけど、業務ロジックだけ書いてるとそういう機会も殆ど無いのでアノテーションの仕組みを一度はきちんと勉強してみることは大事だと思う。

それ以外の章については始業の１時間ぐらい前に会社に来て黙々と読み進めて１ヶ月で半分ぐらいまで読んだのだが、段々１人では理解がしんどくなってきて、そもそも自分の理解が正しいのか自信が持てなくなってきた。そこで今年の春ぐらいから週一回、業務時間外に社内読書会という形で同僚と一緒に読み進めることにした。参加していたのは自分と同じぐらいのスキルのメンバーだったので、何でもわかってる先生という感じでもないので「これはこういう意味じゃね？」「これは作者言い過ぎじゃね？」とかあーだーこーだと議論しながら進めた。あと、Effective javaの読書会議事録はネットの至るとことにアップされているのでそれらを参照することもあった。

中々これは楽しかったのだが、参加メンバーは自分含めて最初５人ぐらいいたはずが、１人来なくなり２人来なくなり、今では自分ともう一人しかいない。別に退職したとかじゃなくて、仕事が忙しいとか朝早く来るのがしんどいとか、そんな理由でモチベーションが落ちてしまったのだと思う。自分は「継承よりコンポジションを選ぶ」に衝撃を受けて、今までガンガン継承使って共通処理をまとめる実装をしてたのを、デザパタを適用する時以外は殆んど継承を使わないようになるとかの影響を受けているのだが、クラス設計レベルの話に興味が無い人には面白く無い本なんだと思う。

OOP言語使ったプログラミングにおいて、クラス設計・インターフェース設計が一番大事だと個人的には思っているので、Effective javaを来年以降も読み込んでもっと良い設計が出来るようになりたい。

Seasar 2 徹底入門 SAStruts/S2JDBC 対応

Seasar 2 徹底入門 SAStruts/S2JDBC 対応

2012年12月頃に購入。

入社してからずっと関わっているプロジェクトはStruts2なのだが、Struts2の日本語本が無かったのと、他のプロジェクトではSAStrutsを拡張したフレームワークを使ってたり、社内にSeaserコミッタの人がいたりもするので勉強のために買った。

大体コレ一冊でSeaser2のDIコンテナの仕組みからSAStruts使ったwebアプリの開発までいける。2010年と古めの本だが今でもSASturtsでwebアプリを作るならまだまだ使える本。

ただ、書籍内ではDolteng使ってSASturtsプロジェクトのひな形を作る方法が紹介されているが、今作るんだったらMavenのarchetype使った方がいいと思う。
そっちのがラクなのと最初からmavenプロジェクトとしてimportできるので何かと良い。自分の環境では、Doltengで作ってからMavenプロジェクトにコンバートしたらプロジェクト自体がおかしくなったことが何度かあった。Maven使わないでアプリ作るとか昨今のjavaではあり得ないので何でも最初からgenerate : archetypeで作るようにしている。

Spring2.0入門 Java・オープンソース・Web開発自由自在

Spring2.0入門 Java・オープンソース・Web開発自由自在

2012年12月頃に購入。関わっているプロジェクトでSpringのDIコンテナだけ使っているのだが、Springのbean.xmlの定義複雑過ぎワラタwwwということで購入。bean定義のオプション書く時にリファレンス代わりに使っている。上記のリンクはSpring2.0だが、今は新しくSpring3.0入門が出ているので、今買うならSpring3.0で良いかも。自分は関わっているプロジェクトのバージョンに併せてSpring2.0の方を買った。

sprint mvcは使ってないのでスルーしてるがぼちぼち使ってる人がいるみたいなのでそのうちやってみようかと思う。

実装パターン

実装パターン

2013年5月ぐらいに購入（多分）。

java-ja DDDの講演資料のスライド↓で紹介されてたので購入。javaを書くようになってオブジェクト指向が何となく板に付いてきたが、それでもやっぱり自信なかったのでクラス設計やメソッドの分割粒度の決め方について知りたくて購入した。

書籍の内容については初心者に毛が生えた程度～中級者向がOOPを使いこなして良い設計や実装をするためのノウハウ集といった形。最初の第一章～第四章まではプログラミング全般において設計に気を付ける目的とか理由といったことが書いてあって、第五章からは各論（クラス、コレクション、例外等）について書いてある。

良い所として、全章を通じて、理論上の話だけでなく具体例を上げて説明しているので解りやすい。第三章なんかは、メソッドの名前付けについて実際のコードを例にダメな点と改良すべき方向について述べた上で、段々とサンプルのコードが改良されていく流れの構成になっており、名前付けに関して著者がどういう思考をしているのかトレースできる。

余談になるが、この「誰かの思考をトレースする」ことは技術学習においては大事だと思っていて、例えば「名前付けはより具体的な名前を付けた方が良い」という情報があっても、それを受け取った人が「具体的な名前ってなんだ？どうやって自分のコードを改善していけばいいんだ？」となるわけで、大事なのは「具体的な名前を付けるべき」ということではなく、「どういう観点で具体的な名前を探していけば良いのか」ということである。この書籍の良い所は後者の点が凄く丁寧に述べられている点である。納得しながら読み進めることができるので頭にすんなり入るし、作者の思考をトレースして背景がしっかり分かっているから応用を効かせやすい。

読み物系

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

2013年7月に購入。

「チームビルディング」や「チームマネジメント」の話。開発がしんどくて行き詰っていた頃に読んでいたが、これを読んでから何となくチーム内での自分の立ち位置とか、動かない人を動かす方法とか、周りからの見られ方とか考えるようになった。色々書いてあったけど、結局はエンジニアも人間なのよというお話。多分エンジニア以外の人が読んでも面白い。

 Webサービスのつくり方 ~「新しい」を生み出すための33のエッセイ

Webサービスのつくり方 ~「新しい」を生み出すための33のエッセイ (Software Design plus)

 2013年夏ぐらい？

ゆーすけべーさんの書籍。Webサービスを作るためのアイデアの考え方から実装のコツ、宣伝、運用まで。一冊あればWebサービス作って回せるぐらいにはなりそうな本。

何か作りたいーけど作るものがないーという人は是非「第一章　心構えと下準備」を読んで欲しい。最初の一歩を踏み出すきっかけをくれるんじゃないかなーと思う。技術的には最後の章のtwitter APIを例にしたOAuth認証の実装はなかなか細かく書かれていてOAuth認証するアプリを書いたことない人には凄くためになると思う。

そういや今年はGithub認証なんかも試して会社のエンジニアブログに書いたりした。

 Yコンビネーター シリコンバレー最強のスタートアップ養成スクール

Yコンビネーター シリコンバレー最強のスタートアップ養成スクール

少なくとも2013年中には買った。

 読み物。「ハッカーと画家」や「On Lisp」で有名なポールグレアムがたちが上げたベンチャーファンドである「Yコンビネーター」の取材記録のような形でまとめられている。このファンド、ただ資金提供するだけでなく、有望なスタートアップ（或いはスタートアップになりそうなサービスを作ってる学生グループ）を集めて、住む場所と少額の資金提供を行って自立したスタートアップとして育てるという珍しい取り組みをしている。タイトルに「スタートアップ養成スクール」と入っているのはそのため。

本書内では、面接の様子から始まり、実際に「授業」としてポール・グレアムとの問答をしている場面や定期的に行われる「夕食会」様子を通して、Yコンビネーターや昨今のスタートアップに関する事情を述べている。

所感としては、自分自信は起業に興味がある訳ではなかったが、スタートアップのメンバーがどういうことを考えてサービスを開発しているかという点で色々勉強になることが多かった。

BtoCオンリーのサービスは非常に難しいので資金繰りを考えたらBtoBでスタートすべきだ、というグレアムの言葉が印象的だった。自分も思いつくのは大体BtoCだが、マネタイズの部分でいつも詰まってそこで「アイデア」レベルで止まってしまう事が多い。BtoBでマネタイズまで含めて考えて、そこからBtoCに拡大することも出来るわけで、そういう考え方をしないとビジネスとしてサービスを作るのは難しいと感じた。

デザイン

 ノンデザイナーズ・デザインブック

ノンデザイナーズ・デザインブック [フルカラー新装増補版]

2013年９月ぐらい。

フロント側の実装案件が増えて、いい加減自分でもまともなUIが組めないといけなくなったのでデザインの原則を学びたくて購入。

デザインってセンスだと思ってたけどどちらかと言えば「パターン」や「原則」をいかに多く知っていて、それらをどういう時に使うかを知ってるかどうか、だと感じた。色の意味やフォントの効果は確かにセンスかも知れないが、全体の構成とかは完全にパターンがあるのでそれを守ってUIを作ることが大切だと感じた。

 Ruby関係

 今年に入ってから、個人的な勉強に始まり、自分で作ってるサービス、会社でのちょっとした社内システムでRuby + Railsを書いている。

Railsの本は。例によって例のごとく「プログラミング初心者向け」の本ばかりだったので一切買わなかった。それにバージョンが3.x系ばかりだったし、rubyも1.8系前提が多かった。ナウなヤングである自分はRuby2.0系とRails4.x系を使い、最初Macports + rbenvで挑んでドハマりしたものである（遠い目）。それ以来brewとrvmの組み合せが最もトラブルが無く、gemsetも使えて最高だということに気づいた。

自分はRailsチュートリアルとRailsの日本語ドキュメントとGithubでpublicになっているRailsプロジェクトのソースを読んで勉強した。

Railsは大きなプロジェクトになった時にどこに何のファイルを置けばよいのかが最初よく分からなかったが、クックパッドの中村さんのソース等を参考に色々考えてやっている。（来年もお世話になります！qchan期待してます！）

勉強に使った書籍をも何冊かあるのでまとめておく。 

パーフェクトRuby (PERFECT SERIES 6)

初めてのRuby

プログラミング言語 Ruby

Rubyアプリケーションプログラミング

元々自分はPHPerなので（このブログの過去記事がPHPネタだらけなのもそういう理由）javaよりも取っ付き易く、それでいてPHPよりOOPの原則を守っていて例外もちゃんと投げてくれるし（PHPの大体の組み込み関数は未だにエラー時に例外を投げてくれない）、型指定が不要な分、javaより簡潔にいろんなのが書ける。
何よりブロックを引数として渡せるのが凄く便利でコードを完結にしてる。java8はよ来い。

というような感じでこれからも長く付き合って行きたい言語である。

エンジニアの心の闇を祓うマサカリ療法

この記事は闇 Advent Calendar 2013の４日目です。

@seri_k 闇Advent Calendar書きましょう

— ıɯǝɥɔʇoɥ (@hotchemi) 2013, 12月 2

 心の闇なんてのは大体エンジニアに限らず社会人なら少なからずだれでも貯めこんでしまうものだと思う。どうすれば解決できるかなんて分からない。
４日目の記事では、過去の自分が経験した心の闇の話と、それを祓う方法についてそれとなく書いてみる。

今いる会社のエンジニアは割りと生き生き働いている方だと思うけれど、それでもやはりどこか、斜に構えた考え方や、何かについての強いトラウマみたいなものを会話の中から垣間見ることがある。若いころに辛いデスマを経験した話だったり、顧客が会社に怒りに燃えて乗り込んできた話だったり、特定のミドルウェアのバグで大変な目にあったり、会社や顧客に理不尽な要求をされて喧嘩したり、とかなんとか、色々な闇が垣間見える。今でも一緒に仕事をしていて、その手の地雷をうっかり踏むと、普段は穏やかな先輩が突然人が変わったようになることがある。

かくいう自分も、闇という程でもないが、SEとして働きながら心療内科に通っていた時期がある。新卒で就職した最初の会社にいた頃で、その頃は「仕事がつまらなすぎ」て体を壊すという珍しい経験をした。別に激務だった訳じゃない。ほぼ定時で帰ってた。それなのに、毎日の仕事が退屈過ぎて、周りが全然技術に興味がなくて、ホントにアイティー企業かここは！？みたいな青臭い苛立ちを抱えていた。手を動かしたいけど当時の俺はマネジメント側でコードの１行も書けない。協力会社のバグ調査を手伝う振りしてこっそり書いていたけど、堂々とコードを書かせてもらえない環境に凄く嫌気が差していた。あの時は「心の闇」みたいなものが相当溜まっていたのだと思う。

しかしその状況もいつまでも続いた訳ではなく、体を壊しつつもプライベートで黙々と初心者本を写経しまくり、cakephpでしょっぱいwebサービスを書いて、転職してプログラマとして働き始めた頃にはもう闇は無かった。とにかくコードを書くこと。これが自分にとっての闇を払う方法だった。やりたい事を堂々と仕事としてやれることが何よりも大事だった。

当時はそれで解決した。しかし人は贅沢なもので、どんどん出来る事が増えてくるとやりたい事も出来てきて、それに対する欲求不満みたいなものが大きくなる。自分の場合はそれもまたプライベートでコードを書いて欲求不満を回避する策に出た。プライベートで勉強していたことを仕事に還元できたものもある。サービス作ったり、勉強会に出たりして新しいネタを拾ってそれをまた身に付けたり、勉強会を自分で開催してみたりして闇を祓ってきた。仕事はどうしたって思い通りになんてならない。やりたいサービスがあったって採算が合わなければできるはずがない。だからプライベートでやるんだ、なんてことを考えた。

しかしそれでも闇が拭いきれなくなる時もある。大体そういう時は変な勘違いとかで自分を過信しているような時で、都合が悪いことを色々なことを周りのせいにしていた。少し仕事を覚えてくるとそういうことがあるらしい。自分が尊敬している先輩が同じチームからいなくなってしまった場合なんかにもよくあるらしい。

そんな折、新しい心の闇の払い方を覚えた。「マサカリをぶん投げられて流血する」である。鼻っ柱を折られる、とも言う。たまに勉強会やその後の懇親会でベテランエンジニアと話をしているとたまにこれを食らう。ものによるが、大体凹む。特に基礎レベルの話で「あ、俺これ普段やってることなのに説明できない…」と思ってしまった瞬間がやばくて、自分は所詮仕事で使ってるコードをメンテして動かしてるだけの人間でゼロからものを作ることなど出来ぬ人間なのだ、とか色んなネガティブなことをその場では感じる。

でもこのマサカリこそが大事なのだ。マサカリを投げられることで、投げられたマサカリを投げ返せるようにそ突っ込まれた分野を必死勉強し始めて、次に会った時に少しは成長したなと思われたいと思い始めることが出来た。今だと「webを支える技術」を行き帰りの電車や昼休みに読み直したりしている。

社内ではレビューを受けていてもマサカリは飛んでこない。しかし一歩外に出れば容赦なく刺される。自分がいかに愚かであるか、会社から一歩出たら全く通用しないエンジニアであることが分かると会社でも謙虚になれる。今できることの範囲で、少しでも優れたエンジニアになってもっと良いアウトプットを出そうと思える。

こんなことをしていると大分気持ちがラクになった。自分が何がしたいか分からない、どういうエンジニアを目指せばいいか分からない、というのもここ半年ぐらいずっと悩んでいて禿げそうになっていたが、たまたま最近受けた数回のマサカリにより、まずはエンジニアとして恥ずかしくない仕事が出来るようになろう、と思えるようになって、大分目の前がスッキリしてきた気がする。

10年続くwebサービスを作るために

最初のロンチ時点で長く使えるシステムを作りたい、と思う。

スタートアップだから

時間がないから

お金がないから

「とりあえず」のやっつけ対応で後のことは後の人に任せる。

人も金も無いベンチャーはそうしなきゃ勝てない。凄く分かる。

スタートが凄く大事だ。知名度を得るためにも、資金を調達するためにも。

けど、だからといって一年後に絶対止まるようなリスクを持ったシステムを作って、リスクを共有せずに後継の人に引き継いで、最初に作ったメンバーはごっそり抜けて、他の事業をやっていて「あとよろしく」って。

それが本当に健全なのか凄く疑問に思うようになった。

また、それを「健全だ」と言えないとベンチャーでやっていくのに向いてないのかも知れない、とも思った。

或いは職業エンジニアとしても向いていないのでは、とも思って最近凄く悩むようになった。

データで探る2012年度のIT戦略 - 基幹系の寿命は14.6年に、大規模プロジェクトの3割強で予算超過：ITpro

あるシステムの寿命がどのくらいかなんて誰にもわからない。

半年ぐらいで役目を終えるかも知れないし、１０年経ってもベースがそのまま使われるかも知れない。

でも、だからといって１年後にめちゃくちゃreadが遅くなるのが目に見ているテーブル設計や、データファイルがディスクを食い尽くしてクリティカルな機能が止まり、全システムが突然止まるようなことが目に見えているようなものを作って、そのリスクを一切共有しない。回避策も考えない。

それが本当に正しいのか。

いくら早くサービスを作ってリリースして高い収益を上げられたとしても、後継のエンジニアを不幸にするようなシステムを作ってはいけない。

ユーザーに不快感と迷惑を与えるようなサービスを作っちゃいけない。

いつか会社を不幸にするようなサービスを作っちゃいけない。

最初からユーザーがどこかで増えても簡単には落ちないシステムを最初から設計すべきだ。

いくらAWSを使ってインフラをスケールできるようにしても、根本の設計が間違っていたらいくらインスタンスに投資しても足りない。

ここは実装クラスを差し替えられるようにインターフェース作って抽象化しとくか、実装がばらつかないように早い段階でサンプルを作っておくか、ログは定期バックアップを取るかfluentでどっかに集めてAPサーバのディスクサイズが一定以上超えないようになっているか、使っているミドルウェアのデータファイル増加ペースはこんなもんで、Nagiosで監視する項目はコレで十分か、とかのノウハウ。

沢山貯めて、最初からユーザーが想定の倍以上増えても、スケールする時に全くビビリ必要がない設計のシステムを作って、安定したサービス運用ができるようにしたい。

エンジニアとして、この辺のことを全部把握できるようになりたい。

インフラは相変わらず苦手だが、一つのライブラリのようにミドルウェアをサービスベースで使えるようになった時代なので、それらを活用したシステム設計を身に付けていきたい。

いつか自分が仕事で新しいサービスをゼロから作ることになった時、出来る限りの人を不幸にさせないサービスを作りたいと思う。

興味

自分自身は好きでエンジニアをやっている。

SIerを飛び出したのもプログラミングが好きだったからだ。

毎日誰かの技術ブログやTechcrunchを読んでいるのも好きだからだ。

家にいても気になることがアレばすぐにエディタを立ち上げてコードを書き始めるのも好きだからだ。

好きでやっているもので、好きでないのにエンジニアの仕事をしている人の気持ちが理解出来ない。正直な所。

正直な感想であれど、それでは済まないことも世の中多々あって、どうしても会社に所属していればそういう「好きでない人達」と仕事をしなければならず、それがまぁ辛い。正直な所。

「自分の担当は○○だから××は知らない」とか「これは習ってないからわかりません」とか、そういう感覚が分からなくて、それを注意する正当な理由もないから、「そうですか」とだけ言って、チケットの内容だけを説明して、チケットの担当者をその人に変える。今の会社でに入社してまもない頃、仕様を理解するために始業１時間半前に出社してソースを読んでテーブル定義書を読んで、EffectiveJavaを読み続けた俺には分からない。誰よりも出来ることを多くしようとして、当時１人の担当者がやってたインフラ周りの構成まで覚えて、自社のサービスで使ってるミドルウェアは全部触れるようになった俺には分からない。

何かおかしい。そう思っても何も言えないし、もしかしたらおかしいのは俺の方なんじゃないか？って思う。なんでこんなに技術に興味があるのか、なんでこんなに少しでも「分からないこと」があると許せなくて自分で調べてしまうのか。周りと違いすぎてついて行けない。

かつて自分の周りはそういう人達だけだった。そういう人達に、この会社で今の俺は育ててもらって、色んなことを教えてもらった。

今はそういう人達はもういない。同じ会社にはいる。でもどんどん違う事業に行ってしまった。今は「理解できない」人達だけと仕事をしている。

そういう人達に仕事を振るのが今の俺の仕事。

矛盾

とあるタスクに対して

「ここは○○使って☓☓にした方が将来的に拡張できるし機能的にイケてるからそうしたい」

という思考と

「ここを直してもKPI改善効果は低い他のタスク優先すべきだ」

という思考とがよくぶつかり合うようになった。

それがとてもつらい。

仕事としてコードを書いている以上、後者の視点を常に持ってタスクの優先度を決定していくべきなのだが、それってエンジニアじゃなくても掃除のおばちゃんでも出来るじゃん？っていうケースが多々あって、例えばとあるフォームのtextareaのrowを10から5にすることで、ユーザーが「沢山入力しなきゃいけないの？めんどくせー、ニコ動でも見よ」→"離脱"になるケースを減らして離脱率を上げるとか、デザイナの修正したhtmlをjspやvmに書き換えるお仕事とか、大量のレビューとテストとか、まぁそんなお仕事に毎日忙殺されてて、正直エンジニアとしての自分を持て余してる。(レビューとテストは重要だけども）

自分以外のエンジニアもこの問題に直面するケースってあると思うんだけど、そういう場合は業務外でOSSの開発をしたり、自分のサービスを作ったりして解消するんだろうけど、なんかそういう所で発散されるパワーって世の中をより良く出来る可能性の損失と考えれば勿体無いなと思ったり。

そのパワーを仕事にすることは出来ないのだろうか。つまり、自分が一番パフォーマンスを発揮できることを仕事に出来ないのだろうか。最近そんなことをずっと考えてて、というのも自分の人生、特に脳みそが元気で大量にインプットできる若い時期なんて時間が限られてるわけで、「やりたくねぇことやってる暇はねぇ」な訳。

自分の場合、20代の時間はもうあと３年もなく、30にもなればどういう価値を出せるかがもっとシビアに問われるようになる。正直まだ何もできていないので焦っている。

とりあえずは今自分が作ってるslidesearch.jpでSEO含めた実験とかGAを使うノウハウをためてみたり、railsの不便だと思うところでgemを書いてみたりと、とにかく手を動かす時間を確保しつつ、どうすれば矛盾を解消できるかを考えたい。空き時間をとにかくエンジニアとしての価値を磨くことにコミットする。

そんなことを思った2013年度下期のスタート