11月1日

に書いたことにしとこう。

内定もらったのがちょうど去年の10月28日（火）23:22。電話にて。条件付きではあったものの、ただただ嬉しくて師匠にすぐ連絡した気がする。

それはおいといて、そこから実務でエンジニアとしてやっていくための準備が始まりました。

それまではCakePHPとjQueryとRailsをほんの少し触っていたものの、いざ業務となると話は別です。

内定もらってすぐ会社に行って、こんな本読んだらいいよ！みたいなのを教えてもらって修行が始まりました。

いわゆるfreeeへの闘争というやつです。

前職では引継ぎや挨拶回りした後有給に突入し、それから入社まで大体の時間は課題図書を読んだり、ものをつくったりして過ごしました。

今回はこの1年で
・どんな勉強して（何読んで）
・何ができるようになって
・何ができてないのか

を書きたいと思います。業務より少し広い範囲でエンジニアとしての道のりを定点観測する大事な時期だったり。

入社前の課題（11月〜1月半ば）

内定とほぼ同時に言い渡された（表現的に受け身ですがとてもとてもありがたかったです）課題図書、3ヶ月でマスターしようシリーズ。

毎週会社に報告に行ってKPTを振り返り、今週はこんだけやります！って宣言してまた次の週、みたいなのを繰り返してました。

そのときの内容、Evernoteに「精神と時の部屋@freee」ってタイトルで丸々残っててそっ閉じせざるをえなかったです。

Webサイト

Railsチュートリアル4.0版
jnchitoさんのRspecに関するQiitaまとめ
Railsガイド

書籍

Everyday Rails

ものづくり

・二次会会場検索
・端末管理システム
・書籍管理システム

まず最初の1週間でRailsチュートリアルをやりました。実質4日くらいでひーひー言いつつ…。

途中から全然わからなくなってきて、でもこれ次行くときまでに最後まで動かせんかったら未来はないと思え…みたいなテンションでとりあえず出てくるエラーを潰しつつ最後までやりました。

結局半年くらいで4周写経しました。

1周の写経と写経の間にいろんな知識が身についてて（Rspec勉強する時期がったり、都度Rubyのメソッド調べたり）、やるたびに理解は深まってるのを感じたものの、最後に写経したとき、最後の方やっぱ難しいと思った覚えがあります。

1周目で
・マジRspecわかんねぇ
・RailsとRubyの境目どこだよ…

って思ったので、次に
jnchitoさんのRspecに関するQiitaまとめを読んだ上でEveryday Rails（Rspecのチュートリアル的な本の邦訳PDF。先に書いたjnchitoさんが翻訳）とパーフェクトRubyをやるという流れです。

こんな感じで特にわからないと感じた部分に関連する関連書籍を週3冊程度、それぞれ100〜250pずつくらい読み進めました。

11月末からは社内の端末を管理するシステムを設計して作り、Rspecも足してみるというのをやり、正月には書籍管理システムと作りながら年越しました。

バーコードリーダーでISDN読んで楽天APIをたたいて書籍名を引いてくる、というのをどうしてもやりたくて（こんくらいできないと未来はないと思えと思いながら）必死だった気がします。

1月からは業務も始まりつつということで、12月までに大体読み終えて（わからんものはわからんと割り切って）入社という形になりました。

当時通っていたプログラミングのスクールは年末でゼミが終わるということで卒業制作に勤しんでました。

こっちはこっちで必死で、
・食べログAPI
・GooleMapAPI
・ページ下部でクリックしたら上部まで戻るjQuery
・非同期通信
・UIの何かしらのライブラリ
をなんとか使いたくて、これはやる！って言ったものはとりあえず全部動かしたと思います。

結果できたのが、現在の近くにある飲み屋さんをマップ上に表示しれくれる、二次会会場検索サービス各参（かくさん）。※ふりではない

Github
各参

Qiita teamとか振り返ってみると、なんかすごい遠慮してる感じ…（1月半ば〜3月）

入社してすぐはあまりにもコード書けなくて、このままではあれですね的な面談を受けつつ社内向けの機能をリリースしたりしてた気がします。

private APIをいじって、クライアントも準備してみたいな感じでチームをまたぐ開発をしました。一歩一歩調べつつ。

コードの実行を途中で止めてデバッグする、というのを最初に教えてもらっていっぱい止めて動きを追いかけてました。

一方でどういう書き方がいいものか他社のコーディング規約を読んだりしたり、リファクタリングの本読んだりしたものの、
・cookpadコーディング規約

周りの人に相談してやっぱ手動かさないとどうにもならんよねってことで基礎振り返りつつとにかく写経してたっぽい。
・パーフェクトRuby（再）
・楽しいRuby
・パーフェクトRuby on Rails

あと、メタプログラミングRubyとか読んでて、よくわからんかった。

2015年10月10日に新版発売。

転職3ヶ月経った直後の記事、こちら。

ただ、なんかこの辺りのQiita teamの記事1つ1つに空回り感というか、できない負い目みたいなのを感じられて胸がすごい苦しくなった。

まわりを頼れ！！！（4〜５月）

上でも触れたものの、なんかこうできない自分の負い目で過度に遠慮してまわりにあまりもの聞けないみたいな時期があって。

もちろんコード書くのはまだまだだったものの、それ以上に仕事のスタンスとしてある程度調べてわからなかったら周りに頼って聞く。自分で調べてどうにかするのが大事なんじゃなくて、ちゃんとリリースすること、聞くことを通じて爆速で成長することが大事やから！っていう話をしてもらった。

その流れもあって全社の朝会と社内イベント企画みたいの担当させてもらうことになった。

そこから少し肩の力が抜けて変わり始めた気がします。

この時期は
・Railsチュートリアルもう1周
・リファクタリング案件向けにEveryday Railsもう1周
・Code SchoolのRubyシリーズ講座毎晩
・お決まりの書き方が知りたくてRails3レシピブック
・Growing Rails Applications in Practice訳して読んだ
をやってました。

やることががらっと変わる（6〜8月）

紆余曲折を経てチームが変わりました。それまで馴染みのあまりなかったseleniumをたくさんたくさんたくたくさん触って、コードを書く量は少し増えたと思います。

それにプラスして、同じ技術を使って他のチームをサポートするコードを完全に自力で書き、その過程で技術選定もやってみました。

それまでは既存のコードに足して機能を追加したり、リファクタリングしたり、バグ直したり、調査したりと一から書くことはあまりなかったのでものすごい勉強になりました。

通常業務にもだいぶいい影響があったり、もう少しインフラ周りも勉強しないとと実感したり。

そのとき一番お世話になったのがこの本でめちゃくちゃ面白かったです。

それと、Railsチュートリアルよりももう少し実践的で具体的なサンプルあるもの写経したいと思ってこの本やりました。

プロジェクトでも目にするような設計になぜなっているのかシンプルな作りのものを作り変えながら進めていくのですごいよかったです。これはもう2周くらいしたい。

続編はKindleのみ。

あとseleniumの基礎とQAについて。

自分が主に育てていく領域をもつ（9〜10月）

新しいチームにも漸く慣れ始めてきたとき、それまで使ったことのない、型のある言語でクライアントアプリを書くことに。

わからないながらも短期間であほほど調べて何とかリリースを重ねるうちに、いつの間にがこれまでで一番大きな開発をやることになっていました。

まだ出たばかりのものを引き継いで、単にコード書くだけでなく拡張性を考慮して設計したり、修正のフローやサポートのしかたを考えていく楽しいプロジェクトです。

周りには何年もプログラミングを経験している人がいる中で思い切った開発させてもらうにはきっと社内に知見がそんなにない分野でもオーナーシップをもって諦めずにやりきるしかなくて、チャンスがあれば食い気味に案件取りに行くしかないと思っています。

そうやってもらった案件には愛着しかなくて毎日楽しいです。

最近はこの本も読んでて、本当に楽しい。

ある程度馴染みのある分野ならなかなか手を出せなかったJavaScriptとも仲良くなれるかも…という淡い期待があるからこその楽しみですが、QA的な分野にも活かせたらなぁなんて思っています。

ただ、やっぱりJavaScript書くならがっつりフロントやりたくてまだまだ距離あるなぁと感じつつ。

今の案件だとそこまでフロント書く感じではないですが、apiがっつり触れるタスクやらせてもらって詳しくなった上で、それ使いこなしてフロントへ…みたいな流れになるようお仕事もらおうと企んでます。

そういう意味だと.NETのWPFがけっこうイベントイベントしているので前よりは理解しやすくなってるのではとも期待しています。

身に付いたこと

という流れでこの1年で何が身についたんでしょう？

Rubyの基礎

・とりあえず今やりたいことは普通に調べて出てくる程度のメソッドでやりくりできる程度。
・メタメタしていると一切理解不能。

Railsの基礎

・処理の流れはbinding.pry挟みながら何とか追える程度。
・Railsコミュニテイで盛んな設計（formとかpresenterとかserviceとか）は何となく真似する程度。
・いやでも画面とかフロントエンド絡むと途端に手止まるなぁ…

まとめると、処理の流れは何とか追って既存のコードの真似して何とかコード書いているものの、設計思想とかパターンへの理解が曖昧で書くのも読むのもいまいち確信が持てない状態。

フロントはからっきしダメ。

直近身に付けたいこと

オブジェクト指向

・C#書いててどかっと新しい機能足すときに「ザ・オブジェクト指向」なところで完全に手が止まる。

設計

・こういうときはこういう設計するよね、みたいなの知りたい。
・なんでこういうフォルダの切り方するの？みたいなの普通によくあるデザインパターンだったみたいな事例があった。

フロントエンド

・この期待感を形にする

まとめると、少し実装は追えるようになったきたからこそなぜそうなっているのかを理解して自由度を上げたい。

身につけるべきこと

あれもこれも多すぎてもはや分野列挙することしかできない…
・CSS
・テスト
・SQL
・UNIX
・DB、モデリング
・git
・コンピュータのしくみ
・セキュリティ
・ネットワーク
・サーバ、インフラ

うわぁ…テストとCSSはさすがに情けなくなってきたので早めに…

まとめ

できるようになってきたかも…！みたいに思い始めてきたことって単にひたすら似たようなこと繰り返してるだけで以上でも以下でもないです。

だからこそ特定の分野は割り切ってその期間ひらすら没頭して成果を上げて、新しいことできる機会があれば絶対逃さないの繰り返しの気がします。

なんとなく全体感の中で足りないこと、足らせたいことは意識しつつ。

結局最高に気持ち良く没頭できることがしたい、できるようになって気持ちよくなりたいに尽きる。

10月18日（日）

転職してから9ヶ月とちょっと。そして何より面接を受けて1年が経ちました。

Wantedlyで話を聞いてみたい！みたいなのを押したらどこよりも早く返事がきたfreee。

早速オフィスに言ってカジュアル（半）に話を聞き、面接を受けてみることに、みたいなやりとりしてたのがちょうど10月の半ばでした。

当時、こんなサービス作って〜みたいな感じで話していたサービス、今コード見てみたら何書いてるのかわからないというか何も書いてなくてよくこれでエンジニアなるって言ったな！笑みたいな気持ちになる。

けど当方はそれでいて楽しくてしかたがなくて、先方はよくわからんが目を輝かせて何か言ってる若者に何かしら可能性を見出したんやからもうええやろって思う。

職業としてのエンジニア

営業（というラベルのついた何かしらの仕事）をやりつつ、週末や平日仕事から帰ってからコードを書く。人と一緒にサービスを育てる。

限りある時間の中で精一杯やってきたものの、これから仕事でやるのとまた違うはず。

学生を終えて社会に出る直前に見た、ビジネスも作れてプログラムも書ける人への憧れ。

会社から提示された条件は何の心配もなかったと言えば嘘になるけど、それ以上に自分の憧れるエンジニアになれるのか、職業としてのエンジニアに違和感なく没頭し続けられるのか。

そっちの方が遥かに本質的な関心事項でした。

1年経って

実際どうやろう。

まず仕事を仕事と感じずにしている感があります。

もちろん、リリースの日はリリースの日だし、サービスを守り、未来を築いていく責務はあります。

駄菓子菓子、かつてプログラミングに感じていた、小さい頃1日無心で組み立てたレゴとか、発表会の前だけひらすら練習したピアノとか、そういう類の没頭感。

週末プログラマーのときに感じたものはそのままに、体力的に問題なければずっと触れていたい程度には好きみたいです。

よかったよかった。

憧れ

エンジニアであることに違和感ななくとも、憧れのエンジニアになれているか。

それは何重にもダメなところがあるなぁと思ってます。

「自分の手でサービス作れる人かっこいい！」という憧れは目指すには必要な要素が多すぎるし、具体的に考えてもないし。

「技術寄りでサービスを考え、作り、変え、大きくしていくことができるエンジニア」になりたい！！とか言ってエンジニアになったものの、それが測れる程度に考えてもない。

それゆえ漠然と成長足りてないなぁとか思うのはそれ自体ダメダメやなぁと思うものの、1年経ったらもう少し色々できるものと思ったのも事実です。

闘争

だからこそ目の前のお仕事しっかりやる！分野好き嫌いせず！というのは当然としてプラスで色々やってみたいと思いやってたりやってなかったりします。

メンテ系のタスクが重なると、コード自体は書くしプルリクもいっぱい出すしで仕事している気になります。

エラーでサービス受けられない人減らしていくのそれはそれで大事。

でもより大きな価値を届けたり、エンジニアとして成長するにはそれだけでは足りない…

そういうわけでいろいろと。

・他のチームのお仕事請け負う
メインのタスクには絶対支障出さない！絶対！絶対出さない！！という（個人的な）約束の下で1つのプロジェクト。

メインのタスクと近い分野でも、そこまでの設計にする必要なかったり、そもそもメインのタスクのアーキテクチャってなんでそうやってるんやっけ？みたいなことを調べたり、技術選定したりしながらほぼ一から構築。

コード書けばとりあえずは目の前の成果が出るという劇薬的な性格も相俟って、最初の方は土日も朝手つけ始めて気づいたら夜だったみたいな感じでした。

7月末に声をかけてもらって、「試しでやります！やりたいっす！」と言ったもののほんとにできるかわからず、無理なら外部に…みたいな状況だったので、なんとか形にできてよかった。

新しく立ち上がったプロジェクトがいい感じに進んでいくのは最高だし、日常のタスクにもいい影響があって、何というか
ほんとにやってよかったです。

・予約管理システム請負
社外案件ですが、できないかなぁ？みたいな話があり。上のとは若干毛色が違って、一から設計して業務システム作って運用まで持っていくみたいな機会なかなかなさそう！的なもの。何があっても本業優先という条件付きで受けようとしたものの、当面は無料のシステム使うことになりいったんペンディング。

作りたくなりがちではあるけれども、ユーザが気持ちよくサービス受けられて事業運営がうまくいくのが本旨。無料システムが思うようにいかなければ改めて一から構築する意義があるし、そもそもの業務フローってどうなんでしょ？って話もシステムありきでなくできると思うので見守ってます。

・新しいプロジェクト
これはメインのタスクですが、自身の経験の無い技術を使用しているかつ立ち上がりたてのプロジェクトを引き継いでサポート体制含め作っていくみたいなプロジェクトにアサインしてもらいました。

数字を見て改善しながらサービスを作り、変え、大きくしていくってまさに自分がやりたかったことで、経験豊富なエンジニアがたくさんいる中で携われるとは思ってませんでした。

だからこういう案件が並びでは、何としても新しいプロジェクトはやり切って成功させたいと思ってます。

成功させた日には少しだけ憧れのエンジニアに近づいてる気がします。

前回の記事の最後に触れた次の目標はまさにこれ。

は？みたいなこともなくはないし、触れたこと無い技術ではまったときの絶望感はすごいけど、求めた場所で理想的な挑戦ができて幸せやなぁと思います。

ひと息

同じように自身のアウトプットに不足を感じている人がいて、話していたら、
今週はここまでできたらOKとか決めて毎週振り返ったら少しでも進んでる感もあって健全！自分を認めるのも大事！
というすごく前向きな意見をもらいました。

素敵やと思います。

ただ、週次のまとめで、あれ？今週俺なんもやってない風？みたいにならない程度の客観性も確保してがんばりたい〜

SIerの営業をやめ、職業としてプログラミングに携わるようになって半年が経ちました。

SIer企画営業をやめ、クラウド会計ソフトのfreeeでエンジニアとして働きます

転職して3ヶ月が経ちました。もっと速く修正したい。

いや、経ってしまったとか、経たれた（受け身）とか、そういう感じです。

半年経って何ができるようになって、何ができるようになってるはずだったのにできてないんでしょう。

近況報告

まだ働かせてもらってます。

タスクの期限に間に合わなかったり、思うように価値を生み出せなかったりする度に明日自分はこの会社にいるのだろうか…なんてよく思ってましたが、その辺の心配はもう少ししたらいらなくなりそうです。

その部分は改めて来月くらいに。

6月の2週目から新しいチームで開発しています。

最初の1ヶ月を冷や汗かきながら過ごしたチーム、いよいよ会計に関わる部分に携わったチームに引き続き3チーム目です。

組織の形は会社が大きくなったり、集中すべき部分が新しくなったりするタイミングで最適なもの（を模索しつつ）変わり、人は柔軟に動く。

前の会社では配属以来2年以上ずっと全く同じ（周りは変わりつつ…）プロジェクトだったのでコントラストがすごいですが、もはや何にも動じなくなってきました。

もう何でもやります、喜んで！みたいな感じです。

最初は変化に対して、これからどうなっていくんだろう…みたいなことは多少は思うものの束の間で、行く先にはチャンスしかないことを知る。

まだまだ改良の余地があったり、仕組みが整備途上のものだったり、自分がやり遂げることですごい喜ぶ人がいる。

「もう何でもやります、喜んで！」という言葉は別にそう思ってなくても言えるし、本心でいつかそう言えたらな、みたいな思い出無理無理口にすることがずっとずっと前にはあったかもしれないけれど、今は本心で言えるなぁなんて思います。

フォーカスすべきこと

何でもやるし、誰でも人が喜んでくれたらそれはとても素晴らしいです。

大事なのは、最終的に生み出される価値です。

駄菓子菓子、やっぱり、何でもよくないと思っているし、誰でもよくないと思っているのだと思います。

ただ、それが合理的にであり得るのは、そういう選り好みをすることによって人がより喜び、その喜びと自分（たち）の手段がよく結びついているときだけです。

リスクをとって価値ある大きな挑戦をしようとしている人を自分も一プレイヤーとして支えたい。プレイヤーとしてはエンジニアとしていられたら最高。みたいな感じです。

この自分の核のようなものは本心も含まれているのだろうし、判断基準がほしくて半ば強引に標語化しているところもあるだろうし、脆い。

特に「エンジニアとして」の意図するところが曖昧すぎて大事な部分ですごく判断がぶれています。

というのは、自分の思うエンジニアとしての行為が思ったより発達が遅い負い目のようなものがきっとあること、そもそもエンジニアとしての行為に対する思想な未熟なことがあるのだろうと思っています。

エンジニアって何？技術って何？

エンジニアとして生きる！なんて言うものの、プログラミングは没頭出来てめっちゃ楽しい！くらいの感覚しかないたぶん。

それでも、求める結果を得るための手段自体が没頭できるものであれば、最終的にその手段で生み出せる結果が他の手段でやるよりも高くなると期待している。

期待しているというか、わからないので試しているという状況です。

好きなことやってる方が生命としていきいきしているし、直感的に成果は高くなる気がする。けどそれは直感でしかない。

ただ、それを手段とする、と言っても
・その手段で何をやるのか（アプリを作る、インフラを支える、テスト体制を作る、エンジニアの生産性を高める）
・どの程度頼るのか（ツール作る程度、コードで息をする、運用でカバー、ドキュメントや会話でカバー）

とか、やることなすことものすごい変わる気がする。

今自分は駆け出しだし、とは言え半年でこれというのはちょっと出直してきた方がいい気もするし、人と話すのもドキュメント（文章）を書くのもすごい好きだし、意識しなければコードバリバリ書けてハックできる人、には絶対ならないと思う。

それでいいのか？それでも人が喜べばいいのか？

結果を求める手段としての技術との距離感を測りかねています。

単に技術技術ーと言っていても厳しそうなのは下の記事を読むと如実に感じます。

まつもとゆきひろ氏が「生涯プログラマー」でやっていきたい若手に贈る3つの言葉【特集:エンジニア育成の本質】

さらに、「プレイヤーとして生き残るために必要な3つのこと」読めば技術技術ーとかでわけわからなくならないだろうし、本来の目的だったり、そもそも解決したいものは何か、解決することで人はどうなるのかにフォーカスすることがよさそうというのが伝わってきます。

その上で新しいことはそつなく使いこなして、前提としてコンピュータサイエンスやれと。

コンピュータサイエンスって何の捻りもなく何だろう！！！

自分がフォーカスすべきこと

以上を踏まえて自分がとるべきスタンスを考えると、
・まずはどうあってほしいかを考える
・それを達成するための手段を選ぶ基準として、「今はやや技術に重みをつけて」考える。安易に「ドキュメント書けばなんとかなる！」とか、「根性でなんとかする！」とかしない。
・基礎なるものを身につける。やってるときに焦らない焦らないって10回言う。
・そのときそのときの中核技術をとことんやる。たとえばselenium使うならseleniumラップしたメソッド使うだけでなくで、そもそも何で生まれたのか、どういう実装があるのか、とかまでたどる。

みたいなのがいいと思いました。

技術だけで生きるなんて言えないし、技術だけで生きるのは幻想なんて言ってたら技術身につかなさそうだし、今は多少遅くなっても技術力を高めるべき。

悩むのおしまい。

今年の目標

毎年設定してるはずなのに、今年はしてない。きっとする余裕なかったんやと思う。

そう思いつつも、きっと会社の一員（少なくとも形式的な）として認められることだけ考えていたはず。

次は「これ主に自分が技術駆使してやりとげました！」みたいなのを新しく作るというのをやりたい。

闘争は続く。