seri::diary

日常

筑波大学大学院コンピュータサイエンス専攻 専攻公開・入試説明会に参加した

筑波大学のキャンパス来た。緑多くてよい。

www.cs.tsukuba.ac.jp

基本的に、筑波大学の学部向けの説明会だったようだが、学外の人間も参加できたので話を聞いてきた。

筑波大学の特徴として、

  • 国内大学のCS専攻としては講師の数がかなり多い
  • 講師が多いのでCSの分野でカバーしている範囲がかなり広い
  • 希望すれば同じく筑波にある産総研の研究所で指導を受けて研究ができ、筑波大学の単位として換算される
  • 社会人特別選抜枠があり、定員は1回の入試で1名〜2名だが、過去においては6人受験して5人入学してたりすることもあるので定員を超えて採用することもある模様 www.cs.tsukuba.ac.jp
  • enPiT(Education Network for Practical Information Technologies)のビジネスアプリケーション分野での提携大学で、PBL(Project-Based Learning)形式での授業がある
  • 留学生とか企業からの研究生受入が盛んなので社会人が入学しても違和感ないらしい(説明会会場にいた4回生に聞いてみた)

仕事に依存しすぎない方がいいなって思うようになった

エンジニアとして働いていると、どうしても「面白くない」と感じるような作業もやらなければならないことがある。1から10まで、コードの詳細レベルまで明らかに内容がやる前からわかる単純作業などが自分の場合は該当する。明らかに繰り返しの作業になっているものはできるだけDRYに寄せるようにリファクタリングして、そこで自分の技術的な満足は満たすように努めているが、いかんせん時間も無限にある訳ではないし、すでに大量のコードベースが存在している場合にはリファクタリングも時間がかかる。それにリファクタリングより優先度が高いタスクは山のようにある。だから大抵はリファクタリング自体をタスクとして計上することはなかなかできない。

自分はリファクタリングは好きな方だ。コンピュータサイエンスのバックグラウンドがない自分には、計算機的に良いパフォーマンスが出せるコードを書くよりは、可読性やメンテ性の高いコードの構造を考える方がまだ幾分とっつきやすいというか身に着けやすい領域だったからだと思う。

ただ、リファクタが得意です、だけだとソフトウェアエンジニアとしてはそのうち使い物にならなくなるだろうな、とかなんとか。そういうことを30歳になったことを境に考えるようになった。綺麗なコードに書き直すという作業は一円も価値を生まない。いくら技術的負債満載だ、と言われても、ベンチャーの世界では価値のあるサービスを最適なタイミングでリリースすることに心血を注ぐ必要がある。良い機能をリリースして、ユーザーからの信頼を高め、新しいユーザーを獲得し、投資家からの注目を集めることこそがベンチャーにおいては重要だ。それに比べればコードの良し悪しなんてのは二の次三の次の問題だろう。

とは言え、たまには飽きて本当にやる気がなくなることがある。そういう時は自分は以下のように考えるようにしている。

1. 仕事は仕事、趣味は趣味である。満足できないならプライベートで満たせ。

これは自分も20代半ばのころに陥っていたのだが、例えば高度な欲求である「尊厳欲求」や「自己実現欲求」を仕事という手段だけで満たそうとしないことである。

仕事は「自己実現のためにするものだ」というようなことを考えている人もいるかも知れないが、幸いなことにソフトウェアエンジニアは仕事以外でもPC一台あればコードは書ける。しかもタダで。多くの人に使ってもらえるソフトウェアを書きたい、という場合でも余暇の時間のOSS活動でそれを実現できるチャンスがある。githubだってタダで使えるんだし。あと新しいことを勉強したければいくらでもネット上に学習リソースが転がっている。考えてみればこれほど恵まれているこというこは他の分野ではなかなかないのではないだろうか。

自分の過去の転職理由は、おおむね「優秀な人と仕事をして自分を成長させる機会を作りたい」とか「スーツでExcelな環境ではなくバリバリコードが書ける現場で技術を高めたい」みたいなものだった。

しかし、今考えれば、それは少し間違っていたようにも思っていて、別にそれらは転職という手段を使わなくても実現できた訳だし、転職自体がそれらを実現できる銀の弾丸という訳ではない。逆に、転職というか仕事自体だけに解を求めてしまうと、仕事で行き詰ったときに活路が見いだせなくなってしまう、が、仕事はしないと自分の食い扶持がなくなるので辞める訳にはいかない、みたいな絶望と強制力の狭間で苦しむみたいな状況が発生してしまう。

幸いにして今の職場は割と自由度が高いので割と自由にやりたいことをやらせてもらっているが、過去においては何をやっても全く何も変えられない時もあって(当時の自分の未熟さも関係していたが)、そういう時に仕事以外に自分の欲求を満たす代替手段を仕事以外に持っていないのは、やはり危うい状態だったと言わざるを得ない。

なお、最近はrailsをちょっといじる程度のショボいgemを3つぐらい作った

2. 仕事の目的は金銭を得ることが目的であり、それ以上に得られるものがあったらラッキー、ぐらいに考える。

仕事に対しては、もちろん自分のベストは尽くすが、求めるものとしてはこれぐらいの意識でいた方がよいのかなと最近は思うようになった。

学生時代から「日経ビジネスアソシエイト」とかを愛読していてやたら意識が高かった新卒の自分に怒られそうだが、結局仕事のポジションはその辺に置いておいたほうが、心理的な安定性を考えるとよいのではないかと最近は思う。

先に書いたことと関連するが、仕事以外でいくらでも「得る」方法はあるのである。だから、仕事がうまくいかなくても他のことでカバーする、という体制は人生において重要なのではないかと考えるようになった。

だから仕事に多くは求めない。逆に、金銭以外で得るものがあったとしたら、それはとても幸運なことだと思った方がいい。仕事がつまらん?ちゃんと給料出るんだからいいじゃないか、と考えることも時には必要だ。新卒当時の俺よ、分かってくれ…

3. 仕事がつまらんのはお前が悪い

一方で仕事がつまらんのは自分が悪いのではないか?という視点を持つ。自分が面白くする努力を怠っているのではないか?という感じに。

一例だが、「今の仕事で改善できることはないか?」という視点で自分ができることを探し、実際に改善するために動いてみると、それを改善するとこと自体が結果的に自分の満足につながるケースもある。

実際、今の会社に入ってから、所属したチームの仕事の進め方を色々変えてみたのだが、その改善自体が自分にとってはそれなりに面白いものだった。これまで当たり前にやってきていたことがないとどういう問題が発生し、それを改善するためにこの手段は必要だったということの再認識にもつながったし、逆にそれを阻害するものは何なのかという発見もあった。だから、もう一度同じことを導入するときはもっと上手くできそうだという自信にもつながった。

ハイコンテクストな仕事とローコンテクストな仕事

追記

書いてからしばらくして読み返してみたら「ハイコンテクスト」と「ローコンテクスト」の使い方逆じゃないのかもしれないと思った。「仕事の成果を説明する」ためにハイコンテクスト文化の中で技術的な要件は抜きに、実現するビジネス要件だけの説明が求められる仕事と、ローコンテクストな文化で技術的に細かいところまでかなり突っ込んで説明が求められる仕事、という意味合いで分けたつもりだったが、「要件が細かく決められる」とかそういう観点だと意味が逆転するような気がした。いずれにせよ日本語に存在しない概念は使うもんじゃないと反省した…

以下本文↓


自社サービス会社のエンジニアがやるのはだいたいハイコンテクストな仕事のような気がする。私だけだろうか?

少なくとも私が今まで仕事で携わってきた仕事はすべてが「特定のビジネスに特化したシステム」だった。つまり、Aサービスを動かすためのシステム、B企業の社内だけで使われる業務システム、とかそんな感じだ。

そういう仕事で作るwebアプリなりバッチなり画面なりは特定のビジネスモデルとか業界の慣習に特化しており、そういった要素に関連するコンテクストが多分に盛り込まれる。プログラムのソースには業界用語もたくさん含まれてくる(余談だがRestaurantのスペルを正確に綴れるようになったのは飲食業界向けの仕事をするようになってからである)。

ハイコンテクストな仕事において、ビジネス要件は常に毎回異なる。全く同じものを2個作るほど余裕がないというのもあるしそもそも無駄なので我々エンジニアは概ね反対するのだが、サービス開発の場合、要件には常に新しいビジネスモデルや機能が反映される。 その要件を噛み砕いて、予算・スケジュール・人的リソースなど、いろいろなものをパズルのように組み合わせて開発していく。それがハイコンテクストな仕事の特徴といったところか。

時に、知り合いのとあるエンジニアが「サーバーサイドの仕事はDBとjsonを変換する仕事」と言っていた。

REST APIを実装する場合、極論すればそうなのかもしれない。 もちろん、どういうレコードを取得してどのようにjsonを作るかというビジネスロジックは毎回異なるし、やるべきテスト内容も変わってくるわでなんだかんだで毎回苦労しながら実装している。 だから、個人的には毎回違うことをやっているなと思っていたのだが、見え方によってはDBとjsonを変換している、というシンプルな言葉で表現することもできるのかもしれない。

逆に、シンプルな言葉で表現されない、複雑で変化の多いエンジニアの仕事はなんだろうか。

自分の少ない経験から考えると、真っ先に思いつくのは研究職。それこそメーカーの研究所で開発しているような人たちは、コンテクストのレベルは様々だろうが、少なくとも特定の問題だけでなくローコンテクストな普遍的な問題も取り扱っている気がする。

この場合、求められるスキルは、誰かから与えられる要件を噛み砕いてそれを実装するスキルよりは、自分で問題を定義して、その問題を解くためにあれやこれやのアプローチをして解決していくスキルのような気がしていて、それは多分自分がやっている仕事の仕方とはだいぶ違うんだろうなぁということはなんとなく想像がつく。

考えてみれば自分はそういうローコンテクストな仕事をしたことがなかった。すべて誰かに決められた要件に従って開発をしてきた。

  • 横顔でも人物を特定できる顔認識アルゴリズムを考える
  • 特定の匂いをデジタルデータ化してまったく違う場所で再現する方法を考える
  • 大量のデータをほぼリアルタイムに処理する分散処理基盤のアーキテクチャを考える(Apache sparkがすでにあるやんというのは置いといて)
  • AWSVPCのようなprivateなネットワークでの利用に限定したlinuxサーバ間のデータ通信に特化した効率的なネットワークプロトコルを考える
  • 現代のマルチコアで大容量キャッシュを積んだCPUアーキテクチャに最適化するコンパイラを開発する
  • 大量のjsonをやり取りすることに特化した新しい通信プロトコルを考える

というような比較的ローコンテクストでいろいろなアプローチが考えられるような仕事をすると、一体どういう世界が見えるのだろうか。 いつかはそういう仕事もしてみたいが、コンピュータサイエンスの学位すら持ってない自分にできるのだろうかという一抹の不安はありつつも、一方でいくらでも勉強するための資料はあるので余暇の時間の独学でなんとか突破できないかということもいろいろ考えている。

トレタに入社してから3ヶ月経ったので所感など

f:id:serihiro:20160203125035j:plain

本日で3ヶ月間の試用期間を終了し、正式雇用になった。

上の写真はトレタのオフィス。いつもはエンジニアがカウンターの上にPCを置いて立って仕事したりしている。

年度末という訳でもないのだが、いい区切りなので、入社してからの3ヶ月でこれまでに自分がやったことを振り返っておく。

やったこと

開発フロー整備

  • サーバーサイドチームのslack channelを作った
  • 開発支援用のhubotを導入して以下のpluginを入れて開発支援に使うようにした
  • サーバーサイドチーム定例会を導入した(ついでに議事録のフォーマットも決めて定例会までに各自の進捗を記入しておく運用にした)
  • 一人だけが担当していたレビューをチーム全員で分担してやるようにした(前述のhubot-reviewer-lottoで公平に割り当てている)
  • 不定期だったデプロイを週1回決まった曜日の決まった時間にやるようにして、いつまでにマージされたPRがいつdeployされるのかを明確にする1周間単位の開発フローを整備した
  • 既存コードのspecの書き方が微妙だったのでrspecガイドラインを書いてrspec3な書き方をメンバーに啓蒙した(あとDRYにして再利用性を高める方法も)
  • jenkinsで[ci skip]ってcommit logに入れたらbuildをskipするplugin入れた(GitHub pull request builder pluginを使ってなかったので)
  • CI時にCoverageレポートを残すようにした

Railsのコード整備

  • Bugsnag入れてRailsのエラーをslackに通知するようにした
  • rails-erdを導入してER図を生成してesa.ioに置いてあるdocumentに貼り付けた
  • bulletを導入してスロークエリを駆逐した(あまり無かったけど)
  • specでviewの内容をほとんどチェックしていなかったのでrspecのconfigでrender_views = trueにしてviewでエラー出ていないかだけでも検知するようにした
  • 多言語対応のサポートのためにi18n-tasksを導入してlocaleの設定漏れを検知できるようにした
  • ローカル環境でメール本文をチェックする方法がなかったのでletter_opnerを導入してブラウザでメール本文を確認できるようにした
  • config/*.yml系の設定ファイルを整理してRails.envごとにどの値が使われているかわかりやすくした
  • json生成にjbuilderを使っていたのでactivemode-serializerを導入して新規に作るjsonについてはこちらを使うようにした
  • やたら時間がかかるspecを特定してファイル分割したりテスト内容を最適化するなどして高速化した
  • 時間帯とか条件に応じてたまに落ちるspecを修正した

機能開発

  • sidekiq-cron + SNS + SQS + shoryukenで非同期で複数サーバでの分散処理を行うバッチを書いた
  • 特定のmodelが更新されたらsidekiqでSNSにpublishするconcernを書いた
  • Bugsnag入れて見つけたバグを結構なおした
  • 管理画面がいろいろ危なかったのでsubmitボタンにdata: {confirm: '消していい?'}とかdata: { disable_with: '送信中...' }みたいなのを入れまくって安全にした
  • 管理画面からシステム系の設定を色々いじれる画面を追加した
  • 手運用でサポートしていた社内業務のいくつかを管理画面からできるようにしてエンジニアの負担を減らした

その他

  • 新機能の要件定義や設計
  • 営業同行して、実際の営業でどのようにお客様にトレタを説明しているかを見せてもらった
  • サービス連携している他社との打ち合わせに出て連携部分の仕様調整とかをした
  • SEOみたいにwantedlyの求人タイトル変えてみたら何かいいことあるかも」という雑な提案をして文言変えたらちょっとPVと応募が増えた
  • slackに黄色い象さんのアイコンを追加した

仕事以外

  • shoryukenをいじっていてqueueの名前にsymbolを使うと挙動がおかしくなったので簡単なPRを出して無事マージされた(これが人生初のOSS contributeになった)
  • railsのソースを読んでいて思いついたgemを2個納品した github.com github.com

commit logや日報を見ながらまとめてみた。

この3ヶ月という期間だけ見ると、受託開発をしていた頃と比べるとコードを書く量は減った印象で、代わりに開発体制の整備やこまごまとしたコードの整備をしている時間が結構長かった。自由にやらせてもらえたので「これやっといた方がいいな」と思うことは一通りやっておいた。

トレタのサーバサイドチームは現在正社員3名 + 業務委託1名の計4人のメンバーで開発している。 自分が入る前は3人だったから、まだチームとしての開発体制が確立していないようだったので、今後人数が増えても破綻しないように開発フローの整備もやらせてもらった(というか勝手にやったw)。3ヶ月あれこれやってみて、今はだいぶ以前と比べるとチーム全体のスループットが上がったのではないかと思う。今後も継続して開発チームの仕組みづくりの改善をしていきたいと思う。

自分が入社する少し前まで、トレタは主なクライアントであるiPadアプリの機能開発やUI改善を中心に開発が行われてきたが、今年に入ってからはサーバサイド側で完結する開発タスクが増えてきている。サービスの成長と開発チームとしての成長の両面に貢献しながら、気を抜かずにこれからもがんばっていきたい。

トレタは3,000万人の予約を支えるRailsエンジニアやインフラエンジニアやiOSエンジニアを募集しています。

www.wantedly.com www.wantedly.com www.wantedly.com

勉強してること2016年3月版

これは何か

  • 過去を振り返った時に「あの時何勉強してたっけ?」というのが思い出せないし、長期休みなどでいざ時間ができて何か勉強しようとした時に「あれが中途半端になってたのでアレをやろう」という感じでネタを探すのに役立つかと思って、毎月その時勉強していることをまとめてみることにした。

  • 大体月下旬ぐらいのいい感じのところでまとめてみることにする。

CS

  • プログラムの処理内容に応じて、マシンリソースをガッツリ使って高速化する方法に興味を持ったのだが、そもそもCSの知識がないのでいろいろわからない事が多いので1から勉強することにした
  • まずamazonでセール中で半額になっていたヘネパタ本読み始めた
  • ヘネパタ本は難しくてわからない用語が多すぎるので適宜ググりながら読んでる
    • おそらくはパタヘネ本を先に読むべきだったのだろう
    • 意外にも10年ぐらい前の暇な時期に調べたPC自作の知識がかろうじて役に立っている
  • サブ資料として電通大計算機アーキテクチャ基礎論のテキストを読んでいる

Elixir

英語

漠然とした将来への不安に関する対策

rebuild.fmの132回を聴いていて思ったことに関して

rebuild.fm

rebuild.fmの132回の11:25ぐらいからエンジニアのキャリアの話題になっていて、ゲストのhigeponさんから以下の様な話があった。

  • 大企業に勤めてると終身雇用の時代じゃないから不安になる
  • スタートアップは将来ないかもしれないから不安になる
  • アメリカは実力主義だから自分が将来周りと戦えるのか不安になる
  • 自分の将来のロールモデルとなるような人が見つからないのがあるのかも

自分もベンチャーでエンジニアとして働いている身としてすごくわかる気がする。

この問題は、多分2つの不安に分類できて、

  • エンジニアとして働き続けるだけの実力を維持し続けられるかという不安
  • 自分の勤め先がなくならないかどうかという不安

両者を同時に解消する確実な方法が今のところはないのだと思う。

前者は本人の努力や素質が寄与する部分が大きいと思うが、会社から求められるパフォーマンスが出せなくなった時にどうなるのかというビジョンが見えないことに起因する不安、といったところだろうか。

後者は変化の激しい業界ゆえの不安、といったところか。例え大企業(メガベンチャー含む)にいてもいつ何があるか分からない。海外に出ても海外で戦い続けられるかどうかはそれこそ日本で働いていたのでは測りようがない。これはもうどうしようもないんじゃないか。自分の場合はもうこの稼業を続ける限り回避不可能なんだろうなと思っている。行く所がなくなってしまったら、過去に一緒に仕事をさせていただいた会社を回ってフリーランスで食っていくこともうっすらと考えている。

ところで、他の業界だと新卒から定年間近の人まで幅広い年齢レンジの人がいることが多いか、ら退職までのキャリアパスのイメージをつかみやすいのだろうと思う。一方で、スマホwebサービス系の業界はそうでないのだろうなと思う。(もし誰かwebエンジニアのまま定年退職した人がいたらぜひ定年エントリーを書いていただきたい)

自分の場合

自分も同様の不安はいつも感じている。主に前者の問題について。

今自分はこれから作ろうとする機能のアーキテクチャを考えたり、実装したり、レビューしたり、サーバに入って調査をしたり、といったエンジニア的タスクが一番バリューが発揮できる領域だと思っているので、そこに一番力を入れてはいるが、そこでバリューが発揮できなくなったらどうするか。そういうことを時々考える。

もともと、エンジニアのチームマネジメントに興味を持っていたというのあって、マネージャーという肩書ではないにせよ、マネージャーがやりそうなスケジュールの管理とか、他のメンバーの進捗の確認とかの仕事を率先してやったり、チーム開発の仕組み(レビューやデプロイの仕組みの整備、定例mtgなどのコミュニケーションの仕組み化)の改善を進めたりしている。ある種の保険をかけていると言われれば、そうなのかもしれない。

つまり、生来的に自分がコードを書かなくなった時の次の仕事を得るため布石を打っている、ということかもしれない。今やってるマネジメントに近い仕事は、単純にそういうことをする人がいなくて、自分がチームに必要だと思っているからやっているという方が大きいので、何とも言えないが。

ただ、もっと会社が大きくなって、いざ「フルタイムマネージャーがほしいね」となった時に、会社が私をマネージャーに登用する可能性もあるが、外部からマネージャーを新たに採用する可能性も当然ある。だから確実ではない。

明示的に、今から「自分は将来はマネジメントやります」と宣言したところで、将来のポジションは保証してもらえるものではない。会社がそういうフェーズになった時でも、自分のマネジメントスキルや実績が足りなければそのポジションには付けないだろう。だから、今やってることは、短期的には会社にためになったとしても、自分のキャリアには寄与しないかもしれない。社会は厳しい。

別のポジションをシミュレートしてみるのは割とアリでは

なお、これは根拠の無い、自分の勝手な考えに過ぎないが、今やってる仕事に加えて、「もし違う仕事をするとしたら?」という可能性を考えて、そのポジションであるかのように振る舞ってみるというのは方法としてはアリなのではないだろうかと思う。

先に書いた自分の例は、「現場のエンジニア+エンジニアリングマネージャー」という感じだが、例えば「現場のデザイナー+プロダクトマネージャー」、「現場のエンジニア+インハウスマーケティング担当者」、「現場のエンジニア+採用担当者」といった具合に。もちろんそれが許される職場であるという前提だが、むしろベンチャーではこのようにプラスアルファのポジションの仕事をすることが求められるのではないだろうか。今の会社でも、何人かのエンジニアが何らかの会社の別の業務に携わっている。

これも先に書いたが、そんなことをやっていても自分のキャリアにはこれっぽっちも寄与しないかもしれない。しかしもし自分が、社内外を問わず本格的なポジションチェンジをしようとした時に、「自分は○○という肩書で働いたことはないが、○○というポジションのつもりでこういう仕事をして、こういう成果を出していた。だから○○がやれるはずだ」という理論的なアピールをするのには役立つのではないだろうか。

少なくとも自分は、社内外のエンジニアリングマネージャーのポジションに応募するとしたら、前職からそれに近いことはずっと続けていたのでその内容を根拠に自分にはエンジニアリングマネージャーができる、今はスキル不十分かもしれないができるようになる可能性は高いだろう、と自分を売り込むことができる。

まぁそれで採用されるかわからないから不安なんだろうけど、こればかりは人間的な相性や運も絡んでくるのでなんとも言えない話。

という感じに適当にぶん投げてこの話は終わりにしたいと思う。

私は如何にして独学プログラミングでウェッブサービスが作れるようになったか

これ読んでて、自分はどういう風に勉強したのかなと思って独学してた頃のtweetやブログ記事を元にまとめてみた。

blog.livedoor.jp

独学以前

ちゃんと勉強を始める前にもコードを書いた経験があった。これがどれくらい影響しているかは分からないが、「やってみたらそこまで大変じゃないな」という感覚はここで得られたと思う。

大学時代(2006年~2009年)

  • C言語の授業でHelloWorldからbubble sortの実装ぐらいまでをやった。農学部なのになぜか必修だった。
  • 卒業前の暇な頃に基本情報の勉強のために「独習C」を最初から半分ぐらい写経した。
    • 何か作りたかった訳じゃないが「SEとして働くための勉強」という目的があったためかそんなに苦ではなかった。

新人SE研修時代(2009年4月~7月)

  • VB.NETで簡単なフォームを作る方法とDBに接続してクエリを発行する方法だけ教わった。
  • 文法の説明はなかったのでサンプルコードを写しまくってあとはカンで書いてた。

php独学時代

2010年2月~

  • 2010年の2月か3月ぐらいからこの本(の古い版)を買って、自宅のwindowsマシンで夜な夜な勉強し始める。
  • 当時のモチベーションはtwittermixiみたいなBtoC系のwebサービスを作れるスキルを身につけてweb系に転職したい、だった。
  • きっかけは伊藤直也氏の講演を聞いたことだったはずなのに、なぜかperlではなくphpを選んだのはphpが当時流行ってたからだと思う。
  • windowsで開発するのがつらいということにしばらくして気づいて、VMware PlayerにCentOS入れて仮想linux環境上でvimで開発するようになる。
    • 当然linuxの操作なんてロクすっぽわからないので、ひたすら「vmware linux php」みたいなキーワードでググりまくってググり力がついた。
    • php, apache, mysqlをsourceからcompileする方法とかが無駄に身についた。

  • 調子に乗って何も作れないクセにこんなことをつぶやき始める。

2010年10月

  • 「技術ブログ」というものの存在を知り、マネしてこのブログを始めた。
  • 初めて書いたまともな技術エントリーはphpではなく仕事で触っていたjavaに関するエントリーだった。

Finallyとreturnの関係 - seri::diary

2010年11月

  • 全然内容わからなかったけど関東php勉強会とかにも顔を出し始めた。

  • そろそろweb画面も作らなきゃな、ということでhtml, javascript, cssの勉強も始める。

2011年5月

  • twitter APIいじりに飽きてしばらく間が空いた。
  • この頃にCakePHP(1.x)で作ったtwitter likeの謎サービスを世の中に公開する。
  • この頃になるとphp、html、js、cssを一通りいじってwebアプリケーションをラクに作れるようになる。

2011年12月

  • SIerを退職して某制作会社に入社し、コードを書くエンジニアとして働き始める。
  • その後なんやかんやあって現在の会社にいたる。

職業エンジニア時代

2011年12月~現在

  • 以下の言語を仕事で触ってきた
  • 最近は趣味でerlangもいじりだした

考察

今にして思うと、周りに誰もphp書ける人がいない、技術に興味がある人もいない、という状況から独学で勉強できた理由としては2点あると思っている。

「ググればわかる」ということを早い段階で理解していた

「ネットに情報は落ちている」ということをかなり早い段階で知っていた。コードは書かなかったにせよ、SIerの現場で先輩社員が一生懸命ググって調べ物をしていたのを見て、「ITってのはググればだいたいわかるんだ」ということを知ることができたのは大きいと思う。

独学初期にお世話になった媒体としてウノウラボというウノウの技術ブログがある。phpの情報そのものだけでなく、「こういう最新の技術情報をまとめたブログがネットにはたくさん存在する」「イケてるweb企業は技術ブログなるものを持っていてそれはとても参考になる」ということを知ることができたウノウラボには今でも感謝している。

作りたいものが明確だった

最初からwebサービスを作るためにプログラミングを始めた。そのため、勉強しなくてはいけない要素が明確にわかっていたのでそれを順々に学んでいくだけ、というレールを最初に設定できた。
これにより、

  • 「基礎は覚えたけど次にどうすればいいか分からない」
  • 「何に使うか分からない勉強をしてもモチベーションがわかない」

というプログラミング挫折者にありがちな問題をうまく回避することができていたのだと思う。

ちなみに、php独学時代に勉強したことをブレークダウンしてまとめるとこんな感じか。今だとgitとかdeploy toolとかCIとかAWSとかも入ってきて覚えることは当時より遥かに多いと思う。

f:id:serihiro:20160213234927p:plain

今でも新しいことを勉強するときは、最初にゴールを設定してそこに行き着くための要素を細分化して各個撃破していくスタイルは変わっていない。趣味で特定の要素を深掘りしていくこともあるが(例えばdockerのファイルシステムの世代管理の仕組みが気になってUnion-type Filesystemを調べた、とか)、大体は何らかの目的を達成するために勉強しているので必要以上の深掘りはしないように気をつけている。