がみぶろ

@jumpei_ikegami

Web系に転職したいエンジニアが「N予備校」の「Webアプリ入門」をやるべき5つの理由

しがないラジオパーソナリティのgamiです.

N予備校のプログラミングコースを始めて、 「Webアプリ入門」コースがすごく良かったので、紹介します.

N予備校ってなあに?

www.nnn.ed.nico

ドワンゴが提供するeラーニングサービスです.

主にN高等学校向けに作られているようですが、一般向けにも提供されています.

無料体験もできますが、基本的には月額1,000円を払うと全てのサービスが使えるようになります.

上記URLにアクセスすると、「ネットで志望校へ一直線!」とか出てくるので不安になりますが、高校生の親から主に収益を得ているサービスだと思うので、そこに最適化されているだけです.

N予備校のプログラミングコース

www.nnn.ed.nico

N予備校は主に高校生向けなので、英語とか社会とかの受験科目のコースも当然あります.

ただし、プログラミングコースの力の入れ方がすごいです.

2017年の9月にはてな匿名ダイアリーの記事がバズったので、知っている人も多いかもしれません.

anond.hatelabo.jp

ドワンゴがやっているので、Webアプリケーション開発の講義がメインです.

受講生の中から、普通に「未踏Jr.採択者」とかも輩出しているらしいので、実績も出てきています.

詳しくは、N高等学校 Advent Calendar 2017の1日目の記事で、担当責任者の@sifueさんが説明しています.

qiita.com

「プログラミングしたいけどそもそもつくりたいものが無い生徒に必要なのは、対話でした」など、プログラミング教育論としても非常に良い記事です.

Web系に転職したいエンジニアが「N予備校」の「Webアプリ入門」をやるべき5つの理由

前述のように、一般にはN予備校のコースは高校生向けに作られています.

ただし、実際に「プログラミング入門 Webアプリ」コースを受講してみて、これからWebエンジニアとしてのキャリアを始めようとしている人にとってもすごく良いと思いました.

その理由を5つ捻り出したので、以下に書いていきます.

なお、N予備校の授業は基本的に「動画」と「Web教材(テキスト)」のセットで提供されていますが、私はほぼ後者の「Web教材(テキスト)」しか使ってないので、その点はご了承ください.

1. 前提知識が要らない

世の中の初心者向け技術書の多くは、ある一定の前提知識を要求してきます.

これは、技術書出版業界のセオリーとして、「『入門』という言葉を付けると売上が上がる」という話があるのが1つの原因です.

一方で、N予備校の授業はPCを使ったことがないレベルまで想定して作られています.

例えば、Chromeのインストール方法や、( の入力方法から丁寧に説明されています.

2. Webの知識が網羅的に身につく

「Webエンジニアになるぞ!」となったときに、身につけるべき知識の範囲というのは、結構広いです.

ざっと考えても、以下のようなトピックについて薄っすらとでも知っておく必要があります.

  • Linuxと環境構築
  • シェルプログラミング
  • 通信とネットワーク
  • GitとGitHub
  • サーバーサイド言語1つ
  • HTML/CSS/JavaScript
  • DBとSQL
  • 認証
  • アプリケーション設計
  • Webフレームワーク
  • テスト
  • セキュリティ
  • Hostingサービス
  • CI

それぞれ別個の入門書が出ているようなトピックばかりです.

「Webアプリ入門」コースは、これらを全て網羅した内容になっています. 20冊近い本を積み上げて勉強するよりは、モチベーションが保ちやすいと思います.

3. 手を動かしながら実践的に学べる

N予備校のプログラミング授業では、ほとんど全ての章で実際に手を動かしながら学べるようになっています.

VagrantUbuntuを立てて、エディタでコードを修正して結果を見ながら、問題なければgit commitしていきます.

「概念は知っている」よりも、「実際に手を動かして実装したことがある」の方が、仕事で触るときの心理的なハードルがグッと下がります.

例えば、OAuth2.0の存在は知っていましたが、実際にnpmライブラリを使って実装してみると、もっと身近に感じられました.

4. 比較的モダンな開発環境に慣れることができる

私がSIerのF社でSEをやっていたときは、開発環境がかなりレガシーでした.

そのため、転職後にWebエンジニアになったとき、使っている言語やツールがすべてガラッと変わって、慣れるまで辛かった覚えがあります.

N予備校のプログラミングコースは、以下のような比較的モダンな環境を使うので、実作業の中でそれらに慣れることができて良いと思います.

ちなみに私の前職は、COBOL + サクラエディタ + VSS + その他F社製品でした. エディタとかは宗教戦争ありそうですが、サクラエディタよりはVSCodeの方が圧倒的にWeb開発には向いているしWebエンジニアの間での普及率も高いでしょう.

なお、これらの「モダン」な開発環境も日々廃れていきますが、コース名に「2017年」と書いてあったので、毎年教材の改訂を行なっていくみたいです.

5. GitHubアカウントの見栄えをよくできる

Web系の企業で中途採用選考を受ける場合、GitHubアカウントを見られることが多いです.

もしWeb系への転職を考えていてGitHubアカウントも持っていないような状態であれば、GitHubの見栄えを良くすることは、テクニックの一つとしてはありかなと思います.

N予備校のプログラミング入門コースでは、すべての演習のソースコードがISCライセンスで公開されています.

github.com

教材に沿ってこれらのソースコードを写経して、自分のGitHubリポジトリのmasterにpushしていけば、GitHubに学習の成果が反映されます.

もちろん最初から自分のプロダクトを作れれば一番いいですが、何もしていない人とは差別化できるでしょう.

なお、GitHubのContributionsに草を生やしたい場合、以下の記事とかを参考にするといいかと思います.

qiita.com

教材の通りにやると、多分master-2017ブランチ等にpushすることになるので、草が生えない恐れがあります.

また、ISCライセンスに従って、『「無保証」であることの明記と著作権およびライセンス条文自身の表示』が必要になるので、たぶんREADME.mdとかに書いておけば大丈夫だと思います.

(ライセンス周りは詳しくないので、問題だ!という指摘があれば教えてください)

まとめ

  • これからWebエンジニアになる、なったけど自信がない、という人は、「N予備校」の「Webアプリ入門」をやると最低限の知識と経験が身に付く
  • 特に、SIerなどの文化が違うところからの転職だと、慣れるためにも、「これやりました!」と面接で言うにも、良さそう

プログラミングに限らず、こういったサービスがたくさん出てきて、学習コストがどんどん下がっていくといいですね.

「白と黒のとびら オートマトンと形式言語をめぐる冒険」を読んでオートマトン学習モチベがMAXになった話

こんにちは、 しがないラジオ パーソナリティのgamiです.

友人から借りて、オートマトン形式言語をファンタジー調で解説した本を読みました.

内容は物語ですが、研究者である著者が、東京大学出版会というガチガチなところから出しているので、技術的な裏付けのある書籍です.

3行で感想

  • めちゃくちゃ読みやすい
  • オートマトン形式言語を学び始めたい人が最初に読むとよさそう
  • 実用の話まではされていないので、もやもやしてちゃんとオートマトンとか勉強したくなる

あらすじ

主人公は魔術師アルドゥインの弟子のガレットです.

ただし、師匠からはいっこうに魔法を教えてもらえず、毎日よくわからない言語の勉強をさせられます.

古代ルル語や古代クフ語という古代の言語で、文字は○と●の2文字しかありません.

しかし、各地で不思議な遺跡と出会い、それらを探索する中で、古代語を学ぶ意味に気付いていきます.

遺跡は白と黒のとびらのついた部屋の集まりから構成されていて、とびらを開ける順番を誤ると、二度と出てこられないものもあります.

ガレットは古代語の文法と遺跡の関係についての謎を紐解いていき...

オートマトン形式言語

各古代語には、それぞれ固有の文法があります. 例えば、第三十三古代クフ語は、「偶数個の○と●の文字からなる回文」のみを、正しい文とみなします.

そして、各遺跡にも、どの状態で、どの行動をしたら、どの部屋に飛ばされるか、といったルールがあります.

古代語や遺跡などのよくわからないけどものから、こうした固有のルールを、読者もガレットと一緒に見つけ出していくような作りになっています.

巻末には、物語の解説がまとめられています.

物語の中の要素との対応としては、実は

を表していることがわかります.

また、オートマトン形式言語の「現実世界」での発展に沿って、物語のストーリーが組まれています.

その対応関係も、解説を読んだときに後から知らされるので、「そうだったのか!」という感覚が味わえます.

オートマトン形式言語を学ぶ意味

この本を読む前は、「オートマトンとかよく聞くけど、ライフゲームみたいなやつでしょ」くらいの知識でした(雑).

読んだ後は、かなりオートマトン学習モチベが上がりました.

こちらも解説に書いてある内容ですが、オートマトン形式言語は、とってもとっても大事な基礎理論らしいです.

オートマトン理論および形式言語理論は、情報科学、数学、また言語学その他の認知科学の分野における、重要な基礎理論です。

情報科学も数学も、漠然と「学び足りてないなあ」と思っているので、その基礎を知れるというのは良いなあ.

また、オートマトン形式言語を深く学ぶことによって、以下のような問いに対して答えることができるとのこと.

  1. 「計算」とはそもそも何なのか?
  2. 計算機械にできることと、できないことの境目はどこにあるのか?
  3. 人間の脳を一種の「計算機械」と見なした場合、私たちの持つ言語能力をどのように説明することができるか?

個人的には、特に「2. 計算機械にできることと、できないことの境目はどこにあるのか?」という問いにはすごく興味があります.

この本の終盤のテーマも、「何でもできそうな計算機械でも、実はできないことがある」という点にあります. こうした「直感に反する事実を論証する」というところに、理論の強さがある気がします.

最近の機械学習/ディープラーニング熱の高まりを見ていると、「もうAIが全部決めてくれればいいのに」と思うことがあります.

しかし、実際には、その「全部」という領域の範囲は、理論上は「全部」ではないかもしれない?ということなんですかね.

こんな感じでもやもやしてくるので、この本はオートマトン形式言語の入門書として、最適な本だと思いました.

自己肯定感を爆上げする、MRM(Morning Routine Management)を始めてみた

f:id:jumpei_ikegami:20180104090945p:plain

あけましておめでとうございます.

しがないラジオ パーソナリティのgamiです.

2018年になるにあたって、今年の目標を何にしようかなーと考えました. やっぱり「普段やりたくてもできていないこと」を、まずはちゃんとできるようにしたいなあと.

例えば、Webエンジニアなので趣味でコード書きたいですし、昨年で15kg太ったので運動したいです. 家の掃除とかも、ついサボって埃だらけになります.

MRMってなあに?

唐突ですが、MRM(Morning Routine Management)という概念があります.

特に仕事以外で日々やるべきことを、毎日のルーチンに分割して、朝の時間ですべてやるための習慣マネジメント手法です.

さっき私が考えました.

ネーミング自体は先ほど5分くらいで考えたのですが、構想は3年前くらいから持っていた気がします. ただし、ちゃんと実践できていなかったので、今年はこれをちゃんとやっていきたいなと思うわけです.

なぜ朝なのか?

朝活と夜活のどっちがいいのかという論争は、ググるとたくさん出てきます.

私は朝活派です.

毎日決まったことをやろうとするとき、夜だとどうしても予定が入ってしまう日が多く、まとまった時間が取りにくいです. 一方、朝であれば、起きる時間と出社時間は(頑張れば)固定できるので、毎日2時間とか3時間とか確保できます.

なので、決まったルーチンをやるなら、朝の方がいいと思いました.

これまでのMRM実践

これまでもMRMっぽいことを実践しては、うまくいったり挫折したりしてきました.

私はむかし公務員試験を受けて失敗したりしているのですが、そのときは自己肯定感が大変なことになったので、リカバリのために数ヶ月間、毎朝ランニングをしました. 特に複数のルーチンを管理するには至りませんでしたが、毎朝同じことをすることの良さを実感しました.

また、2016年には、Google SpreadSheetに朝やるべき習慣をすべて書き出して、それをスマホで見ながら毎日こなしていくということをしました. そのときは、掃除、洗濯などの家事から、爪切りなどの週一タスクも曜日限定ルーチンみたいにして管理していた気がします.

これも、何も考えずにSpreadSheetに書いてあることを上から順番にやるだけで、自然と運動できるし、部屋は毎日きれいだし、最高でした.

ただし、SpreadSheetをスマホで見るという運用が地味にめんどくさくて、やめてしまいました.

MRMのプロセス

というわけで、これまでの実践から、 「日々の生活でやるべきことを毎朝のルーチンとして細かい粒度ですべて定義し、その通りにやっていく行為」 はすごくいいという結論に至りました.

ただし、その行為を何と呼べばいいかわからなかったので、今回、MRMという呼称を付けました.

私の中のMRMプロセスをざっくり定義すると、以下のようになります.

1. 日々の生活の中で、やるべきこと、やりたいことを洗い出す

感覚値では、以下のように分けると出しやすいです

すでに毎朝やっている当たり前のこと

    • 「朝起きて立ち上がる」
    • 「トイレに行く」
    • 「シャワーを浴びる」
    • 「歯を磨く」
    • 「服を着る」

やるべきだけどできていない家事など

    • 「洗濯をする」
    • 「掃除機をかける」
    • 「皿を洗う」
    • 「爪を切る」

自己成長のためにやりたいこと

    • 「読書する」
    • 「ブログを1記事書く」
    • 「趣味の開発でcommitする」

2. 毎朝やるルーチンとして正規化する

毎朝何も考えずに同じルーチンを回すために、以下の3要素を適切な度合いに調整します.

  • ルーチンの「頻度」
  • ルーチンの「粒度」
  • ルーチンの「程度」

「頻度」の調整

例えば、「爪を切る」は毎日やると深爪になってしまいます.

そこで、曜日別ルーチンを作成し、例えば「爪を切る」をその月曜日に割り当てます. イメージとしては、ある1つのルーチンの中身が曜日によって変わる感じです.

「粒度」の調整

例えば、「シャワーを浴びる」というルーチンは、私の場合、以下の子ルーチンを含んだ複雑なものです.

  • 「下着とタオルを持って浴室に行く」
  • 「服を脱ぐ」
  • 「シャワーを浴びる」
  • 「身体を拭く」
  • 「服を着る」
  • 「浴槽を掃除する」

こうした大きな粒度のルーチンを、適切な粒度まで分割します. 「どの粒度だと、『何も考えずに』実行できるか」を考えると、いい感じになります.

「程度」の調整

例えば、「ブログを1記事書く」というルーチンは、毎朝やるには重いです. 仮に実行しても、薄めの記事が量産されてしまうことになりそうです.

「どのくらいやるのか?」が不明確なルーチンについては、毎朝やれる/やるべき量を設定します.

ブログの例で言えば、「30分間以上書く」など時間の長さで定義したり、「50行以上書く」などアウトプットの量で定義したりします.

3. 朝起きる時間を決める

朝起きる時間を決めることで、毎朝のルーチンにどのくらいの時間を割けるか決まります.

私は毎朝6時に起きます(宣言).

4. どのルーチンをどの順番でやるかを決める

効率性やモチベーションの観点から、ルーチンをどの順番でやるかを決めます. 時間内に終わらないルーチンは、程度を下げたり消したりします.

最初は仮置きで決めて、やりながら調整すればいいです.

5. 毎朝決まった時間に起きることを決心し、実行する

一番大事です. これができると、勝ちます.

6. 毎朝PDCAを回す

毎朝決めたルーチンを淡々とこなしつつ、順番や内容をチューニングしていきます.

うまくできない、そもそも朝起きられない、というときは、自分が悪いのではなくルーチン設定が悪いと考えて、ひたすら改善します.

私のルーチンリスト

ということで、2018年1月現在の私のルーチンは以下です. 再開してすぐなので、ちょこちょこ変わると思います.

  1. 立ち上がる
  2. ポッドキャストを聴き始める
  3. 1日の予定を確認する
  4. トイレに行く
  5. 20分以上ランニングする
  6. 体重計にのる
  7. 布団をしまう
  8. commitする(=プログラミングする)
  9. 筋トレする(毎日部位を変える)
  10. Slackに筋トレ報告
  11. COMPとプロテインとサプリを飲む
  12. 皿を洗う
  13. タオルと着替えをもつ
  14. イヤホンを外す
  15. シャワーを浴びる
  16. イヤホンをつける
  17. 浴室をシャワーで掃除する
  18. スクイージーをかける
  19. 髭を剃る
  20. 歯を磨く
  21. 髪を乾かす
  22. 歯をジェットウォッシュする(ドルツEW-DJ61-W)
  23. 掃除機をかける
  24. 1 tweetする
  25. ブログ20分以上書く
  26. 服を着る
  27. 家を出る

30個弱あります. すごいですね.

数日続けた感じ、最初のランニングさえできれば、他は結構いける気がします. ランニングモチベを上げるために、3万円のスニーカーを買いました.

あと、起きた瞬間に出発できるように、夜は靴下とウィンドブレーカーを身に付けて寝ています.

筋トレは、ダンベルとフラットベンチが家にあるので自宅でやります.

ダンベル ラバータイプ (40kgセット)

ダンベル ラバータイプ (40kgセット)

ファイティングロード (FIGHTINGROAD) フラットベンチPRO

ファイティングロード (FIGHTINGROAD) フラットベンチPRO

トレーニング内容は、石井直方先生を信奉しているので、この本をやっています.

まだ洗濯とかゴミ出しとかがルーチンに入ってないので、今後どっかに混ぜ込みます.

MRMの効用

MRMを少し実践してみた感じ、すごくいいです. もうちょっと言語化します.

QOLが上がる

掃除や皿洗いなどを毎日ちゃんとやるので、部屋がきれいな状態で保たれてQOLが上がります.

「やるべきだけどやれてない」感が減る

QOLと似てますが、より精神的なメリットです.

仕事から帰ってきて、家が埃まみれだったり、洗っていない皿が大量にあったりすると、「やってねえ...でも疲れた...」という気持ちになって意志力とかが削られます. そういう「やるべきだけどやれてない」感からくる精神ダメージを軽減できます.

自己肯定感が上がる

自分で決めたことをその通りにこなすと、「自分をコントロールできている」という感覚から自己肯定感が上がります. また、単純に学習やアウトプットに時間を割けるので、スキルや周囲からの評価も上がります.

良いこと尽くめですね!

MRM実践のために諦めること

とはいえ、毎朝MRMをちゃんと実践して上記のメリットを得るには、何かを捨てなければいけません. ここは、選択と意志の問題です.

夜更かしする

確保したい睡眠時間にも依りますが、家で夜更かしできなくなります. 私は23時には寝ます(予言).

夜の飲み会でお酒をたくさん飲む

上と同じですが、飲んで終電で帰るとかができなくなります. 「飲んだ翌朝は休む!」と決めてもいいですが、飲み会が続くとグダグダになります.

「ちょっと朝のランニングがあるので...」とか言って颯爽と飲み会を抜け出しましょう. 飲み過ぎると寝坊するので、お酒も控え目にします(自戒).

朝、布団の中でゴロゴロする

微睡みの中で布団と蜜月の時間を過ごすことができなくなります.

特に冬はまだ日の出前に目覚ましに叩き起こされて、運動を強いられたりして辛いです.

MRMを実現するための強い味方

MRMを実現するときに私が使っているものです.

ルーチンを記録するアプリケーション

ルーチンを脳内に記録し続けるのは辛いので、外部化します.

むかしはGoogle SpreadSheetを使っていましたが、辛いので今は自分でアプリケーションを作っています. 自分がエンジニアで良かった、良かった.

kesamoというスマホ向けWebアプリです.

app.kesamo.tech

ルーチンを1つずつ表示させることができたり.

f:id:jumpei_ikegami:20180104082942p:plain

一覧から編集や並び替えができたりします. f:id:jumpei_ikegami:20180104082950p:plain

使いたい方は、どうぞ! まだ開発中で大きな仕様変更がありうるので、ご了承ください!

ポッドキャスト

ランニングや家事の最中は耳が暇なので、ずっとポッドキャストを聞いています. 好きなポッドキャストが見つかると、「ポッドキャストを聴くために運動する」みたいに主従が逆転するので、ハードなルーチンでも心理的ハードルが下がるという効用もあります.

私はエンジニアなので、Tech系のポッドキャストをガシガシ消費してます.

同じくエンジニアの方なら、まずはこのポッドキャストが軽くておすすめです(PR).

shiganai.org

自分がポッドキャスターで良かった、良かった.

マジレスすると、エンジニアならまずはRebuildを全部聞けばいいと思います.

非エンジニアなら、バイリンガルニュースとかを聞けば英語の勉強になっていいんじゃないでしょうか(適当).

まとめ

  • 日々やれてないことにモヤモヤしてるなら、MRMおすすめ!

2018年の目標

ということで、2018年はMRMのプロセスの中で、以下をやっていきます.

  • 毎日運動する(そして10kg痩せる)
  • 毎日コード書く
  • 毎日ブログ書く(週1回くらいでshipする)

(なんかラジオで言ったやつから変わった気がする)

今年もしがないラジオとがみぶろと @jumpei_ikegami をよろしくお願いします.

We Are JavaScripters!@14th まとめ

We Are JavaScripters!@14thに参加したので、その内容についてまとめました! プレゼント企画などもあって楽しかった!

イベント自体の詳細は、こちら!

wajs.connpass.com

LT1: node.jsでプレゼンツールつくったお話 @ykyk1218

資料

speakerdeck.com

自己紹介

twitter.com

  • ニワトリのアイコン

qiita.com

悩み

  • 勉強会で質問しにくい
  • 勉強会に登壇しても、反応がわかりにくい

SlideChat

http://slide-chat.com/

  • 作った
  • pdfをアップロードし、スライド形式に変換
  • プレゼン中にコメントできる
  • なるほどボタンで、なるほど数を表示できる

スタック

  • Meteor(node.js)
    • Mongoとの相性がいい
    • フロントエンド周りの環境を整えるのが楽
      • webpackなどを別途用意する必要がない
  • React.js
  • PDF.js
  • MongoDB

Qiitaスライドで使いたい!

  • QiitaスライドをpdfにするChrome拡張作った

chrome.google.com

LT2: Nuxt.jsで始めるPWA @takanorip

資料

speakerdeck.com

自己紹介

twitter.com

  • 株式会社スマートドライブ
  • Polymer-Japan翻訳チーム

Service Worker

  • networkとcacheからいい感じにデータ取ってきてくれる

Nuxt.js

  • ユニバーサルVue.jsアプリ
  • SSR
  • ルーティング便利

導入は簡単!

  • pwa-moduleを使う
    • ライブラリをNuxt用にモジュール化したもの
  • nuxt.config.js
    • 設定ファイル
  • gitignoreにsw.*を追加

プッシュ通知

  • One Signalを使う
    • モバイルAppもWebPushも
    • Uberも使っている
  • nuxt.config.jsにonesignalモジュールを登録し、設定を追記
  • デフォルトの通知設定ダイアログを出す前に、確認をはさまないとユーザービリティ的にだめ!
    • OneSignalで、確認用の独自UIを出せる

まとめ

  • Nuxt.jsでPWAの導入が簡単!

LT3: (スポンサー)アライドアーキテクツのサービスで使わているJavaScriptの話 @oremega

資料

speakerdeck.com

自己紹介

twitter.com

  • デザイナー
  • 社内で1人なので、UI,UX,HTML,CSS,JSなんでもやる

アライドアーキテクツ

monipla

cp.monipla.com

  • 企業と人をつなぐ

Brand Touch Manager

www.aainc.co.jp

  • 企業が、自社とつながっている人を可視化

技術スタック

告知

  • フロントエンドエンジニアとデザイナーを募集しています!

www.wantedly.com

LT4: jquery? state管理? どっち使えばいいの? @fukaminmin

資料

www.slideshare.net

自己紹介

twitter.com

  • 運営メンバーの1人
  • Taskey.inc
  • よつばと、漫画、テニス
  • 国際SEO
  • WeJS, CLEM
  • peepというアプリをリリース

画面から友達を削除する

jQuery

  • セレクタ指定で、友達かどうかを判定
  • ajaxでデータ更新
  • 画面もセレクタ指定で更新
  • つまり
    • DOMに依存しすぎる

state管理

  • state側のデータを判別して、そっちをいじればいい

使用基準

  • jquery
    • LP
    • 動きがないページ
    • animation
  • vue, knockout
    • ポップアップやコメント一覧
  • react, angular
    • 1ページで色々したい
    • フルSPA

デメリット

おすすめ

  • 最初に始めるなら、Vue!

スポンサーセッション

twitter.com

forkwell.com

LT5: facebookのフロントエンド開発 @boiyaaaaaa

資料

speakerdeck.com

自己紹介

twitter.com

  • Persol P&T
  • フロントエンドエンジニア
  • ITスペシャリストに昇格

Facebookでのフロントエンド開発

  • StackShareによるスタック
    • React, Flux, Relay
    • Jest
    • Phabricator
    • Jenkins
    • Nuclide(内製エディタ)
  • Mercurialの単一リポジトリにぶち込んでいる

弟に訊いてみた

パッケージ管理

  • 全社でYarnを使っている
  • 必要なモジュールを全て内製している

Facebook製のものしか使えない?

  • 強制ではない
  • Nuclideが自社構成だと使いやすい

nuclide.io

品質管理

  • Flowで型チェック
  • Jest

facebook.github.io

YarnやJestは書き換えた?

  • 1週間でソースがほとんど変わることがある

バンドラは?

  • 内製

Facebookの開発者になるためには?

LT6: SlackはどうやってBrowserViewに乗り換えたか @tipo159

twitter.com

資料

speakerdeck.com

内容

  • 以下の内容に沿って、Slackの実装上の変化を紹介

slack.engineering

WebViewからBrowserViewへの乗り換え

  • まだβ版
  • webViewよりもChromeのタブに近い動作
  • Electronで維持管理できる

electronjs.org

複数Redux Storeの同期

  • 前は必要だったが、不要になった

非同期Actionによる副作用

  • redux-observableを使い、非同期Actionとユーザー操作に伴うActionを一元化

リファクタリング

LT7: 関数の話 @chikoski

twitter.com

資料

speakerdeck.com

function宣言とアロー関数式

  • 書き方が色々

関数適用

  • 関数を呼ぶ方法
  • add(1,2)

パイプライン演算子

  • 最近議論されている仕様
  • value = 7 |> double |> addOne

関数適用は遅い

  • 普通に演算子で書いた方が早い
    • 関数呼び出し時にローカル変数を使ったりするので、メモリ操作が多い
  • でも、関数で書いた方が読みやすい

末尾呼び出し

  • ES6の仕様で、内部的に演算子で展開してくれる
  • なかなか実装されなかった

関数

  • 手続きの列に名前をつけたもの

関数はオブジェクト

  • つまり、関数 = モノ

クロージャ

  • 外の変数を使って定義できる

部分適用

  • クロージャがあると、関数の一部分だけを固定した別の関数ができる
  • utilityが簡単に作れる

ロジックのパラメータ化

  • map, reduceなど、ロジックを引数で渡せる
  • 部分適用と組み合わせるといい

シューティングゲームに使ってみる

  • 当たり判定の計算をしてみる
  • Enemyクラスに、ColliderとRendererのプロパティを設ける例

LT8: アウトプットしよう! @brn0227

自己紹介

twitter.com

  • V8のコントリビュータになった!

新卒時代

  • JS書けるだけで即戦力に

転職

  • CAへ
  • 上司に勉強会を勧められるが、嫌いだった
    • 発表内容も大したことないし...
    • 懇親会が苦手...

インプット

  • ひたすらインプット
  • babelよりも前にトランスパイラを作ったが、公表せずに殺した

世間から消える

  • 社員数が多いと、知られていないことも多い
  • フロントエンドテックリードになったが、自分を知っている人があまりいなかった

行き詰まり

  • インプットだけを続けても、成長が見えなくなってきた
  • OSSはPR送っていたが、遠い存在に感じていた

2017年

  • 月に2〜4登壇を目標
  • 23登壇した
  • speaker deckが2ページになった

感じたこと

  • 世界が広がった
  • 勉強会駆動勉強
  • 自分はまだまだ
  • 執筆や登壇の縁ができた
  • OSSの作者やコミッターと話す機会が増えた
  • OSSコントリビュートする意識が増えた

伝えたいこと

  • 明日からでもアウトプットすべき
  • 自分の価値を高めるのは、自分の責務
  • 社会から受けた恩を返していこう
  • 立ち止まっている間に、ベテラン達はさらに先に行ってしまう

伝えたいこと2

  • インプットとアウトプットのバランスをとる
  • アウトプットがあるから新鮮な情報に触れられる
  • 自分の情報の鮮度を確認できる
  • 「十分な目玉があれば、全てのバグは深刻ではない」

知見

  • ありとあらゆる知見は、価値がある
  • 自分にとって取るに足らない内容でも、他の人にとってはとても価値がある

方法

  • 片っ端からLT枠に申し込む
  • 申し込んでから内容を考える
  • 喋る練習をする
  • 懇親会で人と話す
  • ブログ頑張る

まとめ

  • 迷う必要はない!

Vue.js Tokyo v-meetup #6まとめ

Vue.js Tokyo v-meetup #6に参加したので、その内容についてまとめました!

イベント自体の詳細は、こちら! vuejs-meetup.connpass.com

セッション枠1: Future of Vue.js

@kazu_pon

資料

speakerdeck.com

自己紹介

  • Vue.jsコアチームメンバー

爆発した2017年

  • Google Trendで2016/10にReactを抜いた
  • GitHub Starsも、reactに近づく
  • VueConf2017が開催@ポーランド
  • v2.2〜2.5の4つのリリース
  • エコシステム
    • NUXT, onsenUIなど
  • コアチームメンバーの増加
  • AWA with Vue.js Teamの開催(9月)
    • 「コアチームメンバーだけでなんか聞きたいことある?」

Vue Project Roadmap

公式スタイルガイド提供

  • 公式ドキュメントに公開済み

Cookbook

  • よくある落とし穴への対処をドキュメント化
  • 着手はこれから

eslint-plugin-vue

  • Vue.js向けのコードをLint
  • v4.0.0-beta.2
  • 公式スタイルガイド対応中

vue-test-utils

  • Vueの単体テストツールを公式でサポート
  • v1.0.0-beta.7
  • 日本語ドキュメントもほぼ揃っている

vue-component-compiler

  • バンドラにとらわれないAPIの提供
  • ツール毎に実装されたSFCコンパイルロジックの重複除去
  • WIP
  • parcelも対応するかも?

vue-cli

  • 楽に環境構築できるツール
  • v2.9.2
  • 課題
    • テンプレートのメンテが大変
    • CLIから問われる質問が難しい
  • 3.0アーキテクチャ
    • プリセットモデルの採用
    • オンデマンドでプリセット追加
    • プリセット毎にnpmで管理
    • browserifyを廃止し、webpackテンプレートへ
    • configファイルによる集中管理
    • vue-cliの分離(vue buildコマンドが分離される)

Core

  • v3.0?
  • 2.x系と並行してメンテされる
  • ネイティブにES2015をサポートするブラウザのみサポート
  • リアクティブシステムの改善

WebComponents対応

  • SFCから変換するCLIを提供?

クラスベースのAPI提供?

WebAssemly対応?

  • DOMアクセスできるようになったらあるかも

2018カンファレンス

  • Vue.js Conference Amsterdm
  • UI
  • London
  • EU
  • 日本でも!

セッション枠2: eslint-plugin-vue

@mysticatea

資料

docs.google.com

自己紹介

  • 長島徹
  • ESLintのメンテナの1人
  • Vue.jsのESLintチームメンバー

目次

  1. 開発動機
  2. 今まで
  3. 使い方
  4. templateタグを検証するルールの書き方

1. 開発動機

  • polumerで開発していたときのtypoを見つけて欲しかった
  • React/JSXでは、静的検証が優れていた
  • Vueでも欲しい

2. 今まで

課題

  • .vueファイルはHTML形式だが、ESLintはHTMLを扱えない
  • カスタムパーサーを作った

検証

  • 試しに25個の検証ルールを作成

開発

3. 使い方

  • 以下のサイトで試用できる

Vue.js ESLint Demo

  • configファイルに設定を記載

4. templateタグを検証するルールの書き方

  • みんなで新しいルールを書こう!

qiita.com

  • 基本的にはESLintのルール作成と同じ

    • 既存ルールに悪影響を与えないためにtemplateタグ部分の AST は分離されているため、特別な関数を使ってアクセスする必要あり
  • ここで、試しに1つのルールを作ってみる(ライブコーディング)

  • ローカルのルールを利用する場合は、--rulesdir指定が必要

$ eslit src/*.vue --rulesdir eslint-rules
  • プロジェクト独自のルールを作成すると、生産性が上がるかも?
  • 自動修正もする場合は、ルールを定義するjsファイル内で、fix関数を定義

質問

  • プリプロセッサへの対応についてどう考えているのか?
    • pugはサポートしようとしているが、他のものは検討していない

LT1枠: vue-test-utils

lmiller1990

資料

スライド

github.com

デモ

lt-demo

自己紹介

  • Lachlan Miller

コンポーネントのテスト

  • データを正しく表示するか?
  • ユーザーのアクションに合わせて正しく動作するか?

API

  • レンダーとマークアップ
  • 状態・関数を設定
  • モック、スタブ、インタラクトの登録

DEMO

  • コンポーネントレンダリングする
  • 状態を設定したり、clickなどのアクションをシミュレートする
    • テキストボックスの入力シミュレーションもできる
  • 想定する状態かどうかテストする

LT2枠: Vue.jsとともにいきる

@lovalottaplus

資料

docs.google.com

自己紹介

  • エンジニアかつデザイナー

エンジニアとデザイナー

  • お互いに話す言葉が違う
  • ハイブリッドタイプ
  • jQuery帝国を捨てて、Vue.js王国に来てください!!!

デザイン現場では意外と使われてないもの

  • Vue
  • Gulp
  • Webpack
  • SASS
  • ループや分岐 -関数構造家 -エディタ
  • 外部データ通信
  • git

デザイナーにVue.jsを広める辛さ

  • 「世間のデザイナーから見れば、下北沢のインディーズバンドと同じレベルの知名度

jQuery帝国とVue.js王国の考え方の違い

デザイナーがVue.jsを使うまでの3つのハードル

  • データをかくない
  • Vue.js難しい
  • DOMを見てくれない
    • F12を知らない

5つの工夫

  • Vue.jsのドキュメントは読まなくてもいい
  • コンポーネント定義をHTML側に寄せる
  • ディレクティブという概念を隠蔽
  • 非同期データ通信を無くす

良かったこと

  • 変更に強くなった
  • 将来の見通しがよくなった
    • Vueのdataを考えるようになった

デザイナーが覚えたVue.jsの機能

  • 3%

私以外のメンバーがウェブサイトを作った分量

  • 92%

開発効率

  • 2,000%

質問

なぜVue.jsか?

  • Angularを使ったら疲弊した

ソースコード管理はどのようにやっているか?

  • プルリクベースはやめて、masterのみ
    • gitのログがあるだけですごい!という世界

LT3枠: 10年前のレガシーシステムをVue.js TypeScript Elementでフルリニューアルしている話

@maeharin

資料

speakerdeck.com

自己紹介

リニューアル前

  • RAILS
  • 管理画面: Java10年もの
  • サテライトサイト: Java 7年もの
  • 約100テーブル重複

リニューアル後

  • フロントをVue.js + Element + TypeScript + Rails
  • APIサーバーをKotlin

Element

  • Vue.jsのデスクトップUIフレームワーク
  • 2.0.0でTypeScript型定義がバンドルされた
  • フォーム部品周りが豊富
  • Vue.js系のUIフレームワークで一番人気
  • i18n対応
  • Vetur(VSCodeプラグイン)もサポート
    • 補完が効く
  • rulesにバリデーションルールを記載できる
  • パーツが豊富で、少ない手数でリッチなUIを構築できる

TypeScript

  • Vue.js2.5でサポート
  • オブジェクト構文でも、thisの型が推論されるようになった!
  • APIの1エンドポイントのプロパティが50個あったりするので、型定義が欲しい
  • Kotlin側の型定義から、TSの型定義を自動生成

開発の流れ

  1. APIサーバーのエンドポイントを書く
  2. swagger-codegenを実行
  3. RubyとTSのコードが自動生成
  4. Ruby側のコードを書く
  5. Vue.jsのコードを書く(TypeScript)

まとめ

  • 管理画面開発にElementはおすすめ
  • Vue.jsのTypeScriptサポート強化は嬉しい
  • swagger-codegenでTypeScriptの型定義自動生成をするのは、あり

LT4枠: VS Code&TypeScript&Vue.js

日本マイクロソフト 井上章様 @chack411

自己紹介

VSCode

TypeScript

ライブデモ

github.com

8つのSIer退職エントリから学ぶ、日本のSIerの実態

この記事は、しがないラジオAdventCalender8日目の記事です。

私は、「SIerのSEからWeb系エンジニアに転職したんだが楽しくて仕方がないラジオ」という、全国のSIerを敵に回すようなタイトルのポッドキャストをやっています。

タイトルを決めた理由の1つとして、よく「SIer退職エントリ」がはてなのホットエントリーに入っているのを知っていたことがあります。

SIやばいよ、SIやめたよ、みたいな話は、界隈で興味や関心を得やすいのだなあという感覚もあってのタイトルです。

そこで改めて、富士通の退職者の1人として、「SIer退職エントリ」をまとめてみます。

ざっと探して見つかったものに限るので、偏りがあるかもしれません。 また、SIerの営業職/コーポレート部門などについては、本エントリのスコープから外しています。

ネガティブ寄り

まずは、SIerに対してネガティブな感情が滲みでているエントリたちです。

2016-04-13: 富士通を退職した話 (1256ブクマ)

はてブ界隈の話題を席巻したエントリ.

入社する前は大学の情報系学部に通い、大学院まで進学して専門分野の研究にそれなりに熱意をもって取り組んでいた。 (中略) 自分の希望についてはしっかりと主張したつもりだったけれど、 入社して1週間後に告げられた自分の配属先は、山奥の工場でメインフレームを主とするシステムの開発・保守を行う関連会社への出向だった。

多くの大企業では、採用部門と事業部が切り離されていて、入社時の希望と全く違う配属になることがあります。 この現象を、私は「大企業ガチャ」と呼んでいます。

20代そこそこの新卒社員が化石みたいなプラットフォームの世話を押し付けられるなんて想像だにしていなかった (中略) せめて担当業務はオープンプラットフォームにしてほしいとか、COBOLは嫌だとか、ついでに可能であれば山奥の工場に押し込まれるのも勘弁してほしいとか、できる限り主張をしつつ、しばらくの間実際に働いてみてから身の振り方を決めることにした。

直感的には、ちゃんと情報科学を学んできた20代にCOBOLを書かせるのはもったいないと思います。 その辺りの感覚が日本の大手SIerの中にどのくらいあるのか、非常に気になります。

2011-12-04: 2年半務めたSIerを退職しプログラマとして再スタートを切ることにしました (82ブクマ)

プログラマに憧れて就活をしたけれど、SI業界ではPGは地位が低いという話を聞いてSEになった人の退職エントリ。

どうにもプログラマというのは飯が食えないらしい、 日本においては価値が低い職業として位置づけられているらしい、ということが見えてきました。

今にして思えば、それは「SI業界における下請け専門のPG」の話でしたが、 当時は「それがPG」だという風に見えてしまい(後略)

一般的にはモノを作れるプログラマーの方が価値が高そうですが、SIerではPGが単純労働とみなされ、 SE > PGという明確な身分差を付ける文化がある印象です。

一番大きく感じた違和感は 上流SIerのSEってITスキルなんて皆無でもやっていける、という点です。

特に大手SIerにいるような上流のSEは、技術職ではなく「技術系総合職」です。

技術が好きでコードを書きたい人は、上流SEになるとミスマッチになりやすいです。

2016-04-24: 富士通を退職して思うこと (1104ブクマ)

3年で辞められた、公共系SEの方。 富士通の悪いと感じた点が章立てで記述されていて、強い思いを感じます。

1.成果主義を謳いながら実態は年功序列主義

富士通には、人材キャリアフレームワークという社員評価制度があり、現場には、入社何年目はこのレベルの仕事、といった暗黙の了解がある。 本人の能力や意欲とは全く無関係に、入社後の経過年数で、仕事の裁量の幅が大きく制限される。

富士通成果主義について深く知りたい方は、こちらの本がオススメです。文体に癖がありますが、生々しくて面白いです。

Amazon | 内側から見た富士通「成果主義」の崩壊 (ペーパーバックス) | 城 繁幸 | 企業動向

2.社内既得権益集団が絶対に損をしないルール

富士通という会社には多数の既得権益集団がいる。そして、社内のルールは彼らが決して不利にならないように作られている。 なぜなら、ルールを作る権限は、先頭を走る集団、1980年代に大成功を収めた既得権益層がガッチリ握っているからだ。

これは日本の社会保障制度がヤバいのと非常に似た理由で、大手SIerには若い人が一線を退いた世代を支えなければならない構造があります。 日本から脱出するのは大変ですが、SIerから若者が脱出するのは比較的簡単です。

こちらも深く知りたい方は、こちらの本がオススメとのこと。

若者はなぜ3年で辞めるのか? 年功序列が奪う日本の未来 (光文社新書) | 城 繁幸 |本 | 通販 | Amazon

4.発展途上国レベルの業務標準化の原因

ここにおいて、ITシステムが業務に合わせるのではなく、ITシステムに合わせて業務の方を変えていかなくてはいけないのだ。 (中略)

富士通は、既存顧客の業務標準化およびデファクト・スタンダードとなるITシステムの開発の陣頭指揮をとる役割を果たすべきだが、その望みは期待できない。 なぜなら関係が深い企業において、業務が効率化すると大量の社内失業者を出すことになるからだ。

これは日本全体の問題で、自治体や事業会社が業務をシステムに合わせて変えられれば全ての組織が同じパッケージを使うだけで済むので効率的ですが、現状はSIerがシステムを各組織の業務に合わせてカスタマイズしているので、生産性も利益率も全然上がらないという話です。

カスタマイズで関係性や利益を得るのは短期的にはいいですが、利益率が下がる割に保守コストがどんどん膨れあがるので、長期的には社会にも会社にも望ましくないです。

最近、新興企業を中心に業務でもSaaSの利用が進んでいるのは、良い傾向だと思います。

2013-09-01: SIerを退職しました - hotchemi.ja.blog (707ブクマ)

1年半で退職して、より技術寄りのキャリアにチェンジした方。

強いて言えば、下記の様な問題を考え続けた結果、転職という選択肢が自分にとって最善であると感じたという事です。

・業界の方向性に疑問を感じた。開発をアウトソーシングしマージンを抜くといったビジネススタイルでは開発者が幸せになれないと感じた

・エンジニアとして生きていく上で技術から取り残される焦りを感じた

わかる。

実際に現場に入ってみて「楽しくなさそうにプログラミングをしている人が多いな」と感じたのも事実です

多くのSIerの中で、プログラミングは仕様書をプログラムに落とし込む単純労働とみなされており、「プログラミング楽しい!」という人は少ない印象です。

人月(必ずしも悪だとは思いませんが)、一括納品のビジネスモデル、多重請負構造、ディフェンシブな開発体制(この辺りの思想は倉貫さんに強く影響を受けています)…パッと思いつくだけでもSIerの受託開発には多くの問題や矛盾が存在しています。 (中略)

未熟な頭で必死に考えた結果、上記の問題を解決する為には、2つの道があるのではないかと考えます。 ・永和システムマネジメントやソニックガーデンなど、新しい受託開発を提案できる環境に身を置く。リスクを丸投げしてくるような発注をそもそも受けない。 ・ユーザー企業(敢えて幅広い言い方をしています)に身を置き、既存のSIではない事例を作っていく

これも同意で、多くの場合はユーザー企業とSIerのパワーバランスは顧客の方が上なので、無理な発注を受けざるを得ない状況があります。

この状況が変えるためには、やはり

  • 他の会社には持っていない技術やノウハウをもった「強い受託会社」が増えてユーザー企業側の目を覚まさせる
  • SIerのような受託会社ではなくユーザー企業側に多くの開発者が移る

のどちらかだと思います。

ちなみに、米国では日本と違い、ユーザー企業側に多くの開発者がいるようです。 paiza.hatenablog.com

また、本エントリでも言及されていますが、「納品のない受託開発」に取り組む株式会社ソニックガーデンさんは、まさに「強い受託会社」である印象で、受託IT業界に燦然と輝く光です。

www.sonicgarden.jp

2016-02-29: SI企業を退職しました - 無理なご乗車はおやめ下さい。

SIerに2年11ヶ月勤めて辞めた人のエントリ。 自分で仕事を取りに行ったと書いてあるので、たぶん会社の規模は小さめ。

私が文系出身でありながらこの世界に来たのは、サラリーマンとしてのビジネス力を磨きたかったのではなく、技術をもっと追い求めたかったから。「システムなんて中身がどうであれ、とにかく動けばいい」ではなかったはず。エンドユーザのシステムを理解・把握し、新規事業の提案をして、開発を外注に投げて私はその管理だけをするということがしたかったわけではないはず。

ウォーターフォールの受託開発だと、要件を実現することだけが優先されやすく、作っているシステムをもっと使いやすくするための努力をしにくいです。

この会社にいて得られる技術力は?VBCOBOLや古い仕様のままのCといった枯れた技術は必要悪、エンタープライズ向けシステムには不可欠な技術だけど、でもそれを私は習得したかった?違う。

VBCOBOLを書く人はまだ日本に必要だけど、それを自分が書くべきか、という問題。安い給料でCOBOLを書く若いエンジニアがいる限り、COBOLは死なない。

2015-10-04: 中小SIerを退職しました記事。 - るがぶろぐ (111ブクマ)

2年半勤めたSIerを辞めて、一旦無職になった方。 まず辞めてから考える勇気!

一番大事なのはやっぱり給与。諸々不満があったとしても、十分な報酬貰えてるなら文句言わず働くよねっていう。 (中略) 特に私の場合は、入社以来、何回も表彰されてた (個人でも、プロジェクト単位でも) っていう実績があって、「若手の期待の星」みたいなことも経営層から (対面では) 言われてたので、なのに昇給が同期と変わらず、無いも同然っていうのは…っていう感じでした。評価してるっていうなら形で示してください。これ大事。

これはSIerだけの問題ではないと思いますが、利益率の低さや年功序列が原因であることがある気がします。

ポジティブ寄り

次に、新しいチャレンジをしたいという理由で転職をしたケースと、転職後に辞めたことを後悔しているケースです。

どちらも、SEではなく研究開発寄り。

2014-01-20: 富士通を退職してGunosyにjoinしました - Ryoの開発日記 (298ブクマ)

スパコン向けのミドルウェア開発などをされていた方。 受託案件ではなく、研究や製品開発周りであれば、大手SI系の企業でも活き活き働いている人が多いイメージです。

前職に大きな不満があったわけではありません。 学生時代から興味のあった*6 データマイニングの技術を活用するGunosyのキュレーション事業に関わってみたい、スタートアップのベンチャーで自身の能力を活かしてみたい、身近で使われるようなB2Cの事業に関わってみたいという思いが日増しに強くなり、決断した次第です。

ポジティブな転職理由。

2013-12-21: 退職します. 拝承 - テストステ論 (987ブクマ)

こちらも、非常に話題になった日立退職エントリ。エントリ自体はネガティブ。

その攻撃的な内容に公開当時も話題になったが、何よりもその後筆者がTwitterで「転職は完全に失敗だった」「土下座で謝るので日立に戻りたい」と手のひらを返したところまで含めて多くの人の興味を引いた。

なお、転職後のTweetについては、以下の記事に詳しいです。本人のTwitterアカウントも調べましたが、凍結されている模様。

netgeek.biz

ざっくりまとめ

SIerに対するよくある批判や不満

  • 開発言語や環境が古い(メインフレームCOBOLなど)
  • 実際に開発をするプログラマの方が、SEより地位が低い
  • SEは「システムエンジニア」なのに開発させてもらえない
  • ユーザー企業の業務をITシステムに合わせて変えるケースが少なく、カスタマイズが絶えない
  • プログラミングを楽しんでいる人が少ない
  • システムの品質や使いやすさを追求しにくい
  • 給料が安い(特に若手)

わかったこと

  • プログラミングが好きで仕事にしたい人は、SIerのSEになってはいけない
  • SIer界隈では、業界の構造的な問題として、生産性の低い開発を強いられるケースが多い
  • 大手SIerの研究開発部門であれば、技術的に凄い人に囲まれてスキルアップできる環境はあるかも
  • 富士通は他の大手SIerに比べて退職エントリーが圧倒的に多い

以上です。

SIerに限らず、日系企業や大企業にありがちな問題も含まれていますが、おおよそSIerの負の側面については、網羅できた気がします。

ただし、退職エントリを書いた人の意見しか記述されていないので、だいぶバイアスがかかった内容だと思います。

実際、私の富士通時代の同期の中では、SEとして活き活きと働いている友人がたくさんいます。

そのため、辞めた側の一つの意見として、誰かの参考になれば幸いです。

大手SIerでCOBOLを書いていた私が新卒2年目でWeb系スタートアップに転職するまで

しがないラジオパーソナリティのgamiです。

しがないラジオAdvent Calendar2017 2日目の記事です。

adventar.org

これを書くために、ブログを始めました。きっかけ大事。

SIerからWeb系への転職エピソードのアドベントカレンダー」ということで、自分の転職話を書きます。

私は富士通にSEとして入社してから、1年半でWeb系スタートアップであるプレイドに転職しました。 ポッドキャストでもこの辺の回で話しましたが、1年越しの転職エントリを赤裸々に書いていきます。

転職活動

富士通時代は、ブラックSIerとは真逆の働き方をしていました。 ほぼ毎日定時で帰っていて、累計残業時間も10時間以下です。

ホワイト労働だったのには、以下の理由があります。

  • 自治体向けのビジネスだったので、そこまでハードじゃなかった
  • パッケージ開発元のチームだったので、顧客から距離が遠かった

なので、転職に関して特に強い思いをもっていた訳ではなく、スキルアップに関するもやっとした不安だけを抱えて働いていました。

本格的に転職活動をし始めたのは、2つのきっかけがありました。

ベンチャーへの会社訪問

ある日、エンジニアとして働いていた大学の同期が、遊びに誘ってきました。

「転職サイトでスカウト受けた会社に遊びに行くけど、一緒に来る?」

当時の私にとって、会社に遊びに行くとはどういう概念なのか、全く理解できませんでした。 会社とは、お金とスキルを得るために働くところで、遊ぶところではありません。

ましてや、スカウトを受けているのは友人の方なので、「なんだこの金魚のフンみたいなやつは」と思われるのがオチです。

当然、そんな気乗りしない誘いは断ってもよかったのですが、なぜか行くことになりました。

この頃の記憶はあいまいですが、漠然とした不安に突き動かされて、何でもいいから「会社と家の往復以外のこと」がしたかったのかもしれません。

職場のあった海浜幕張から目黒までの電車では、現職の人への軽い罪悪感と、一歩踏み出せた自分への高揚感が入り混じった不思議な気持ちでした。

訪問した会社は、ラクスルという主に印刷サービスを提供するスタートアップです。 raksul.com

他の多くのWeb系スタートアップがそうであるように、ラクスルのオフィスは空中庭園を模した遊び心のある空間でした。

正直、友人がCTOと話している内容は半分もわかりませんでしたが、「世の中を変えるために遊ぶように働く人たちがいるのだ」という当たり前の事実に、震えました。

仲の良い同期の転職

ちょうど同じ時期に、仲の良い同期が転職してWebエンジニアになるという話を知りました。

そのときは、長い研修を終えて配属されてから、まだ1年もたっていませんでした。

「とりあえず3年」という言葉を信じてはいませんでしたが、何となく「今辞めるのは、世間体的に早すぎるかなあ」と思っていました。

そんな中で、同期が転職を決めたという話を聞いて、もう辞めてもいいんだな、という思いなおしました。

その同期とは、今も一緒にポッドキャストをする仲です。

twitter.com

転職活動を始める

Web系の会社に転職をしようと決心をしましたが、まず壁にぶち当たりました。

自分が何をやりたいのか、そして世の中にどんな会社があるのかも、全くわからなかったのです。

漠然と、「世の中を良くしている実感を持ちながら」、「エンジニアとして」働きたいと思っていました。

しかし、転職サイトを見ると、その条件に当てはまりそうな会社は星の数ほどあるのでした。

スカウトサイトに登録する

そこでまず、スカウトサイトに登録して、自分の経歴を詳細に書きました。 Wantedly、キャリアトレック、Greenあたり。

www.wantedly.com

すると何件かスカウトが来るので、カジュアル面談の予約をします。

  • どの会社がいいのかわからない
  • 技術力に自信がない

というのが目下の課題だったので、「スカウトしたのはそっちじゃん」という言い訳ができることを重視しました。

今思うと消極的ですが、とにかく自信がなかったので、まずはそこから。

選り好みせずに面談を重ねていくと、結構いいことがありました。

  • 自分のことを話すのに慣れる
  • 興味のある会社とない会社の特徴がわかる
  • (選考が通れば)自信がつく

やりたいこと、いきたい会社があいまいなときは、とにかくたくさん面談すると見えてくるものがあります。

とりあえず転職活動をしてみる、というのは、辞める確証がなくてもオススメです。

イケてるエージェントに登録する

面談慣れしたころに、Goodfind Careerの転職エージェントと面談をしました。

career.goodfind.jp

エージェント経由だと、自分の経歴や適性をみて合う会社を探してくれるので、実際に会社の人と面談をしてみても、マッチング度合いが高かったです。

今働いているプレイドも、そのときのエージェントの方に紹介してもらった会社です。

ただし、大手の転職エージェントはベンチャー界隈とのつながりが弱い印象です。 ベンチャーに転職をしたいなら、同じく人材系ベンチャーを頼った方がいいと思います。

転職活動のためにやったこと

定時退社で暇だったので、少しでも有利に働くよう、転職活動以外にも色々やっていました。

勉強する

COBOLJavaで開発してます!」というのは全くアピールにならないということは、薄々感じていました。 そこで、Web系の企業で多く使われている技術を勉強しました。

どの言語を学んでいいかわからなかったので、とりあえずRailsチュートリアルをやりました。

railstutorial.jp

一通りこなすだけで、Rubyはもちろん、Git、Heroku、TDDなどWebアプリケーション開発に必要な知識をざっと学べるので非常に良いです。

今だったら、N予備校 プログラミングコースをやると思います。

www.nnn.ed.nico

何か作って公開する

Wordpressのカスタムテーマから自作したWebサイトを公開したりしました。

当時、全くPHPは理解していませんでしたが、コピペ開発でどうにか見れるものを作りました。

もう公開されてないと思ったらまだあったので、黒歴史ですが貼っておきます。

jinriki-nanapi.net

コンセプトは、「俺が効率的に生きるためのノウハウを1人の力で書き溜めてnanapi超えるわ」みたいな感じでした。 今見ると色々とやばいですが、皆さんのアウトプットのハードルが下がれば幸いです。

Tech系ポッドキャストを聴く

何かのきっかけで知ったRebuild.fmを、通勤中に狂ったように聞いていました。

rebuild.fm

聴き始めた当初は、話していることの1/5もわかりませんでしたが、「これが自分の目指す世界の言語なんだ」と念じて耐えていました。

Web寄りのTech系ポッドキャストを聴くのは、他業界からWeb系への転職するときには、とても良いと思います。

  • Web界隈で勉強しなければいけない内容がなんとなくわかる
  • Web界隈で最近話題のトピックを知れる

採用面接でも、Rebuildで仕入れた知識を、さも昔から知っていたかのように話していました。 「この人は話が通じるな」と思ってもらえるのは大事です。

最初は背伸びしているように感じたとしても、当たり前の界隈の知識を、ポッドキャストの力を借りて、ひたすら脳にインストールしました。

今だったら、しがないラジオを聴くと思います。(宣伝)

そんな感じで、Web系スタートアップに転職しました。

FAQ

書いていたら、読者の方からの質問が頭に浮かんできたので、その妄想に勝手に答えます。

新卒2年目でSIerを辞めるのは早かったか?

いいえ。

もちろん会社に依りますが、Web系の会社は、長くSIerにいた人を採用するのを嫌う傾向にあります。 カルチャーや開発環境にギャップがあるのが、その理由だと思います。

また、Web界隈は複数社経験する人がゴロゴロいるので、すぐに会社を辞める人へのマイナスイメージはかなり薄いです。

長くいるメリットはない気がしています。

ほぼ未経験でWeb系エンジニアになるのは技術的に大変か?

勉強が好きなら、なんとかなります。

また、技術以外のスキルやカルチャーマッチを重視する会社も多いので、自分に合った会社を見つければ大丈夫だと思います。

転職して楽しいですか?

楽しくて仕方がないです。

そんな訳で、楽しくて仕方がないラジオ、今後ともよろしくお願いしますー

shiganai.org