2015年前半の振り返り

2015年も折り返しを迎えました．

転職などもあり，環境の変化によってステップアップもできた半年でした．

年初に立てたアクションアイテムを元に，2015年前半を振り返ってみます．

Next Action Item 5

年初に**2015年心がけたいこと**をまとめたら，約50個出てきました．

その50個は，2014年一年間日々メモをしていたノートで「☆」をつけていた項目．

 

それらを踏まえて特に注力する5つをアクションアイテムとしてまとめました．

 

① ABC

ABC = Always Be Coding これはComputer Science の学位なしにGoogleのエンジニアになった方のブログ「[ABC: Always Be Coding How to Land an Engineering Job.](https://medium.com/@davidbyttow/abc-always-be-coding-d5f8051afce2 "ABC: Always Be Coding How to Land an Engineering Job.")」からの引用．

学歴の不足は経験などを通じて後々埋められるが，ABCは努力でなんとかなるようなものではない．ABCが楽しくない人，苦痛な人は，たとえCSの学位を持っていても，その資質の不足が後々トラブルになり得る．一方，長時間，常にコードを書いていても苦にならない，問題を解決するのが楽しいという人であれば，Tipsやテクニックも覚えれば，チャンスをつかむ確率がグンと高くなるということです．

実際にコードを書くことに加え，コードを記述するプログラミング言語やフレームワークの設計思想を理解したり，OSSのソースコードを読むことを意識してやっていました．日々「なぜ」ということを探求していった結果，気づいたら全体を俯瞰して理解していて，結果的にいいコードが書けるようになっていた実感があります．Wikipediaを見てたらリンクからリンクへ飛んで読んでいるような感じで．

覚えているかどうかもわからないようなことが後々繋がって，理解するみたいなことも多かったので，面白いと思ったものはその時々でハマってみるの大事です．

② 情報発信

• Contribute to OSS
• Stack Over Flow

情報発信から得られる体験（インプット＋FB）がよい成長材料になるという意味で，OOSにContributeする，Stack Over Flow で質問する・質問に答えるということを漠然と情報発信と思って挙げていました．

結論，半分くらいできた．

できたこと

• OSSのコードを読む
• OSSのバグを見つけて報告する
• Github上で質問してみる．
• SOFで調べて問題解決につなげる
• OSSを公開する

できなかったこと

• SOFで質問する
• SOFの質問に回答する
• 活発なOSSにコミットする

調べる過程で，同じ問題にハマっている人は多く大体調べると解決できる．そのため，自分で新たに質問しなくても解決できることが多かったです．AngularJS, Ruby, Railにしろ，ハマってるところは大体同じなんだなと感じました．活発なOSSにコミットするのはできなかった．というより，何をコミットすれば良いか活発なOSSの場合理解が追いついていない．ソースの隅まで理解してないとコミットできない気がしてなんとなく億劫な感じです．ライトなOSSから，TOTOをみて出来そうなものがあったらやってみることから，始めてみようと思います．

AngularのOSS「ng-pixel」を公開してみて，公開までのステップも意外に面倒で，公開してからも様々なFBを得られて勉強になった．最近機能拡張できていないので，ガンバリマス．

③ スキルセットを証明する

シリコンバレーの技術者すごいっていうじゃないですか．何言ってんのこれって思ってたんですけど，一度行ってみなきゃとも思っていてとりあえず行ってみたんです．彼らのすごいところは，こういうことやったから技術があるっていう，自分の技術を証明する手段を持っているんです．シリコンバレーの技術者は，日本の新卒採用みたいに入って教えられたことをやるんじゃ無くて，自分はこういうことができるからこういうことやらせろっていうスタンスなんです．そのために自分のスキルセットを高めて，自分のやりたいことをやるためにスキルセットを証明する手段を作っているのがすごいと感じました．でも技術がめちゃくちゃ優秀かっていうとそうでもないし，僕たちでもこんな風になれるんだなと．あそこへ行って僕が強く感じたのは，自分がこういうことやりたいなら，それを実行するための力をつけて，周りが納得できるだけの実績を積むってことが大事だということ．([Gunosy開発チーム根掘り葉掘りインタビュー](http://gigazine.net/news/20130417-gunosy/ "Gunosy開発チーム根掘り葉掘りインタビュー")より)

④ 英語を使う

「英語を勉強する」 四半期の目標設定で，挙げたはいいものを，Skype英会話などを始めても続かない，という失敗体験を繰り返してきました（笑 ）．もはや英語は手段であるにも関わらず，それを勉強するということが目標というのは，如何なものかと思いつつもそれを繰り返していた気がします．

なので，2015年は「勉強する」から「使う」というアクションに切り替えました．

転職して，英語に触れる機会（触れざるを得ない機会）が増えました．

海外のディープリンクベンダーのブログを毎日チェックすること，WWDC, Google I/OなどでiOS, Androidの最新情報をキャッチアップすることをやるようになりました．日本語翻訳をまっていたり，字幕を見ていたって，情報のキャッチアップは遅くなります．英語を読んで，理解して，それをアウトプットするということに時間がかかりすぎていて，明らかに英語がネックになっています．

使用する開発言語・フレームワークの変化も大きかったです． Ruby, Rails, AngularJS, AWSを日々使うことになって，OSSのドキュメント（英語）を読んで理解する機会が圧倒的に増えました．また，社内に参考にできるソースコードがない（いい意味でも悪い意味でも）ため，自ずと理解するための情報がインターネット上の公式ドキュメント（英語）が中心になりました．

英語を使うためにやっていることをまとめます．

端末の言語設定を英語に まずやったのは，iphone, Macの設定を全て英語にすることです．

毎日起きている時間の90%くらいはiPhoneかMacに触れています．つまり，それらを使用する環境を英語にすることで１日の大半を英語に触れられることになります．とりあえず単語レベルでもわかっていればなんとかなるので，オススメです．

英語でググる

検索キーワードに日本語を使わない（極力）を自分に課してみました．

日本語でググると，技術系ならQiitaや個人ブログ，公式ドキュメント(英語)の翻訳など，ほとんど日本語の記事でしょう．（個人ブログは特に）メンテナンスされてなくて古い情報もあり，公式ドキュメントの翻訳を待ってたら，最新の情報はいつまでたっても得られない．

英語でググるようになって，英語の方がやはり情報量が多く（公式ドキュメント＋Stack Over Flow），問題解決までのスピードは明らかに上がった気がする．

英英辞典で調べる

高校生のときにやった方がいいと言われていたアレです．

英語の本を読む これは最近はじめました．読むスピードは遅いけど，これ読んでます．

ReadingやWritingは割とできるようになってきましたが，やはりSpeakingが課題です．強制的に英語を喋らざるを得ない環境に飛び込みたい．

⑤ 最初から正しくやる

[@vvakame](https://twitter.com/vvakame "@vvakame")さんから教えてもらった考え方です．

後から構造の変更がおこりにくいようにやる，エンバグしにくいようにやる，高コストなことは早めに処理する，単純作業を生み出す，調査は必要なとこだけ早くやる，最初から正しくやっておくと後々いい意味で楽ができるということです．

最初から正しくやれてないとき（後からああしとけばよかったと後悔するとき）は，大抵，理解が不十分なまま進めているのが原因でした．その理解の対象は，開発言語やフレームワークのことはもちろん，システムで実現するビジネスドメインのこともです．「手戻り」が発生するのは理解不十分による考慮モレが多かった．最初から正しくやるためには，細かいところにも気を配って，一つ一つ理解を積み重ねることで，徐々に正しくやれるようになる気がします．

まとめ

[退職エントリー](http://yutarotanaka.com/blog/job-change/ "退職エントリー")で「**実践でやってからできないことを補充した方がはやい**」ということを書きましたが，2015年前半はまさにこの通りでした．実践でやって足りないことを埋めていくスタイルで，密度の高い半年で，ホリエモンさんが「ビジネスの世界ではいくら勉強しても失敗する確率は減らない」と言っていたのを実感した気がします．

2015年後半は，Ruby, Rails, Angularをより深めること + インフラ周りの経験すること，英語を使うことに注力したいと思います．

今後もよろしくお願いします．