Patのブログ

プログラミング、英語、科学的学習法、日々の勉強記録

プログラミング未経験のアラフォーがプログラマーとして転職するまでの758時間(+α)の全勉強記録を公開します

f:id:pat68:20200823204111p:plain

はじめに

私が通っていたフィヨルドブートキャンプというプログラミングスクールでは、その日に勉強したことを報告する「日報」と言うシステムがあった。

私はその日報を8ヶ月間、毎日1日も欠かさず書き続けた。

おかげで当時勉強していた内容や勉強時間を正確に知ることができるので、ここで公開してみたいと思う。

ただ惜しいことに、日報は昨年の12月までで途絶えている。

そこから転職に成功するまではさらに3ヶ月以上はかかっているが、その期間は記録が残っていないので記述も感覚的なものになってしまうことをお詫びしておく。

アラフォー未経験からプログラマーへ転職するまでに、いつ、何を、どれくらい勉強したのか、できるだけ詳細に書いてみるので、未経験転職を目指している人は読んでみると役に立つかもしれない。

f:id:pat68:20200823183610p:plain
フィヨルドブートキャンプのプロフィール画面

当時の状況

  • 中学教員としてフルタイムで働く
  • 勤務時間は朝の7時から夜の7時まで

平均勉強時間

平日: 1〜2時間 休日: 6〜8時間

2019年5月~6月

主に勉強したこと

使用教材

当時の状況

プログラミングに夢中になっていた時期

この頃は仕事にやりがいを感じにくくなっていた時期で、とにかく何か新しいことに挑戦したいと思っていた。

「俺はTOEICマスターになる!」といきり立ってTOEIC満点を目指したり、「いや、やっぱり通訳になる!」と資料をかき集めたり、なにをとち狂ったのかいきなりけん玉を練習し始めたり、とにかく迷走していた。

いま思えば、仕事が単なるルーティーンの繰り返しとしか感じなくなってきてしまったことに対する無意識的な防衛反応だったのだろう。

そんな中、ふと2年前に生徒管理アプリを作ろうと思って少しだけプログラミングをかじったことがあったのを思い出し、勢いでフィヨルドブートキャンプに体験入会してみた。

すぐに夢中になった。

卒業までに必要なプラクティスが最初からすべて提示されていて、それを自分のペースで一つ一つこなしていけばいい、というシステムが自分にあっていたのだと思う。

初めの方のプラクティスはハードルが低く設定されていて、どんどん進むのも気持ちよかった。

気付いたら、仕事以外の時間はすべてプログラミングに捧げるようになっていた。

できるようになったこと

  • 最低限のターミナルの操作
  • マークダウンでのテキスト作成
  • HTMLをセマンティックに書く
    • HTMLの基本的な書き方を学ぶだけでなく、HTMLはセマンティックに書くべきとか、alt属性には画像の説明を書くべきではない、とかHTMLの思想・意義について初めからしっかりと学ぶことができたのはよかった。
  • CSSで三角形を表現する
    • CSSの最終課題で出てきたのだが、鬼のように難しかった記憶がある。おかげで力はついたが。
  • 標準入出力、SSHSSLの仕組みを説明できる
    • Linuxは自分は結構ささっと通り抜けてしまったが、業務についてからこの辺の知識がバンバン要求されるので、もっときちんと勉強しておけば良かったと後悔している。
  • Rubyで動く簡単なプログラムが書ける。
    • Rubyは『プロを目指す人のためのRuby入門』(通称:チェリー本)をメインに勉強したが、この時点では到底すべてを飲みこめているとは言えず、自作サービスを作っているうちにようやく理解できるようになってきた。
    • チェリー本を読みながら並行して「lsコマンドを作る」という課題に取り組んだ。これは、unixコマンドであるlsと同じような機能をrubyで実装してみよう、という課題なのだが、最初は何から手をつけていいか1ミリもわからず、途方にくれた覚えがある。試行錯誤でなんとか完成させたときには、Rubyでプログラムを書くということの意味が分かったような気がした。
    • この時期は、とりあえず動くプログラムが書けるという段階で、まだクラスやオブジェクト指向などは全然理解できていなかった。

こうしておけばよかった

  • HTML/CSSはこのとき学んでから自分の自作サービスを作るまで全然触れていなかったので、すっかり忘れてしまっていた。一月おきくらいにこれまでやったことの復習をするべきだった
  • Linuxの知識は業務では前提知識となっていると感じる。『新しいLinuxの教科書』をもっと読み込んでおくべきだった

2019年7月〜10月

主に勉強したこと

使用教材

当時の状況

プログラミングの難しさにぶち当たる

この頃は仕事も忙しく、なかなか時間が取れないことにもどかしさを感じる毎日だった。

プログラミング学習がどんどん楽しくなってくるのに比例して、仕事の方の情熱は次第に薄れていった。

転職を本格的に考え出したのもこの辺りだと思う。

平日にはせいぜい行き帰りの満員電車の中でiPhoneを使って参考書を読むくらいだった。

その代わり休日には最低でも8時間は勉強していたと思う。

少ない勉強時間を可能な限り効率的にしようと、これまで生徒に教えてきた認知科学にもとづいた勉強法を自分でも実践してみた。

具体的には「間隔を最適化した復習」を可能にしてくれるAnkiというフラッシュカードアプリを使うことで、電車内での学習を受動的なものにしないように工夫していた

ただ、この頃読み始めた『オブジェクト指向実践ガイド』という本がとにかく難しかった。

チェリー本でもクラスの章がいまいちピンときていなかったので、オブジェクトという概念をあまり理解できていなかったんだと思う。

1日中取り組んでも解決しないエラーに遭遇するようになったのもこのころで、楽しさだけではないプログラミングの難しさに直面した時期だった。

できるようになったこと

  • Rubyの基本的な文法(配列、ハッシュ、ブロック、クラスなど)を理解する。
  • Railsで基本的なCURD機能を実装できる。
  • Deviseによるログイン認証機能、OmniauthによるGithub認証、i18n、ActiveStorageによる画像投稿機能、ポリモーフィズムを利用したコメント機能、を実装できる。
  • 基本的なSQLとER図を書ける。

こうしておけばよかった

オブジェクト指向実践ガイド』はざっと読んで、ぼんやりとオブジェクト指向をイメージできたらさっさと先に進むべきだったと思う

ベテランプログラマーの方たちが口を揃えていう「無理に覚えようとするのではなく、あとから検索できるようにインデックスを作っておく」ような勉強法を取り入れるべきだった。

2019年11月~12月

主に勉強したこと

使用教材

当時の状況

学ぶべきことの多様さにクラクラしながらも突き進む

この時期から設計やインフラ、チーム開発の手法なども入ってきて、毎日めまいを覚えながら勉強していたことを思い出す。

JavaScriptやVue.jsなどはかけ足になってしまい、浅い学習になってしまった。

のちにチーム開発の中でJavaScriptを書く課題を与えられときに、ほとんど最初から再学習する羽目になり「もっときちんと勉強していればなぁ」と反省した。

でも当時はそれで精一杯だったのだろう。

デプロイはとにかく難しかった。

設定が一つでもおかしいとうまくいかないのだが、ログを読んでもうまく解決できず、ググってもなかなか引っかからなかったり、とにかく大変だった。

「この苦労がエラー解決のためのとても貴重な経験になる」ということは頭ではわかっているし、実際にそうだったという実感もあるのだが、でも解決できないとやはりつらいものだ。

まったく前に進まないときなどは、イライラして思わず机を強打してしまうようなこともあった。

ただ、メンターの方から「プロでも2、3日ハマるとかはザラ」という言葉をいただき、「そういうものか」と思ってからはイライラすることも少なくなっていったように思う。*1

できるようになったこと

  • クラス図を書ける。
  • JavaScriptで簡単なプログラムを書ける(カレンダー表示プログラム)
  • Vue.jsでtodoアプリを作れる。
  • CapistranoVPSにデプロイできる。
  • CircleCIを使ってCI/CD環境を構築できる。
  • アジャイル開発の基本を理解する。

こうしておけばよかった

JavaScriptはDOM操作をもっと集中的に勉強しておけばよかった

というのは、その後のチーム開発や自作サービスを作る際に常にハードルになったのが、JSによるDOM操作だった。

最終的に何がしたいのかを見据えた上で、いま何を勉強すべきかを選択し、強弱をつけて勉強すべきだった

2020年1月~4月

主に勉強したこと

当時の状況

退職し背水の陣で転職に挑む

12月いっぱいで退職し1月からは無職になったので、勉強時間はたっぷりととることができた。

実は日報を毎日書いていたのは12月までで、それ以降はほとんど書いていない。

したがって勉強時間の記録もないのだが、大体毎日最低でも8時間はプログラミングと向き合っていたと思う。

1〜2月は、主にフィヨルドブートキャンプのwebアプリの開発に取り組んでいた。

これまで生徒として使ってきたアプリを、今度は開発者として機能追加やバグ修正していくというプラクティスで、これがとても面白かった。

すでに自分が慣れ親しんでいるアプリなので仕様は理解できているし、愛着も湧いてきているので、開発に参加するハードルは低く、開発の意義も感じることができた。

具体的にやったことは、特定の箇所にユーザーの名前を表示する、textareaのバグ修正、jQueryで書かれたコードを素のJSで書き直す、などのタスクをこなした。

同時にフィヨルドの最後の課題である自作サービスにも取り掛かり始めた。

この課題はよくあるような技術を見せびらかすためのポートフォリオ作りではなく、実際にユーザーの抱える問題を解決するサービスを作ることが目標になっている

そのため、アイデアをひねり出す段階から「競合との差別化はできているか」「そのサービスは自分の抱えている問題を解決しているか」「そもそもそのサービスを利用する人はいるのか」などとバンバンダメ出しを受ける。

もっとも自分の場合はとくにダメ出しを受けることもなくすんなり合格できたのだが、これは教員時代に自分が欲しくてたまらなかったものだったことが功を奏したのかもしれない。*2

問題とその解決法をロジカルに考えることはそのまま面接対策にもなったので、このときメンターの方から色々質問いただけたことは本当に貴重な経験だったと思う。

自作サービスが完成間近の4月に転職活動を初め、最初に応募した企業から内定をもらったのでそのまま卒業となった。

就職先が決まったときは完全に力が抜けて、それからしばらくは廃人のようになってしまった。

退職後は自分が思っていた以上に緊張していたんだと思う。

できるようになったこと

  • アジャイル開発の進め方
  • JavaScriptによるDOM操作
  • 非同期通信によるデータのやりとり
  • エレベーターピッチの書き方
  • プログラミングによる問題解決の方法を考えられる
  • 「カンバン」を用いたタスク管理
  • AWS(EC2, RDSなど)を使ったデプロイ

こうしておけばよかった

自作サービスの開発に時間をかけすぎた。

前職を辞めてからずっと3ヶ月は家にこもって開発をしていたが、もう1ヶ月くらい早くできたと思う。

「年齢のハンデを考えるとレベルの高い作品を作らないと」という意識が強すぎて、未経験の分野に手を出しすぎてしまった。

最初から完璧を目指すのではなく、「コアな機能を実装したらとりあえずリリースしてしまって、ユーザーからフィードバックをもらったら修正する」というフローにすべきだった。

ポートフォリオは充実しているに越したことはないと思うが、いろいろな機能を盛り込んでいるが何を解決したいのかわからない作品より、「自分が抱えるこういう問題を解決したいからこのサービスを作った」ということをロジカルに説明できる作品を作る方が、採用側には魅力的に映ると思う。

まとめ

まとめると、自作サービスを作り始めるまでに758時間、そこからチーム開発と自作サービス開発に500時間以上はかかっていて、合計すると軽く1000時間は超えることになる。

周りの人たちを見ても、未経験から転職するには700時間くらいの勉強は最低ラインという感じだ。

これを多いと感じるか少ないと感じるかは人によるだろうが、たとえば英語を身につけるのに最低必要な勉強時間が2000時間と言われているのに比べたら大したことはないと思えるのではないか。

しかも、2000時間程度の勉強量で身に付く英語力程度では転職は厳しいが、プログラミングの場合それより半分の勉強量で転職できてしまう。

こんなにコスパのいい職業はあまりないのではないか。

少しでも興味があるのならばどんどん学んでみればいいと思う。

もし合わないなと感じたら途中で気づくはずだし、そこまでの経験はこれからの時代絶対に無駄にならない。

ただし、短時間の学習で就職することを目的とするのは、個人的にはおすすめできない。

まず、そのような短時間の勉強でも就職できるようなところは自社開発企業ではなくSES企業が多いし、たとえ自社開発企業に就職できたとしても最低限の基礎がないと実務についていけないので、精神的に病んでしまって辞めてしまうリスクも高まる。

もし転職する理由が「スキルを身につけて人生の主導権を握りたい」とか「好きなプログラミングで食べていきたい」などであったら、すぐに就職と焦るのではなく、1年間くらいじっくり腰をすえて勉強して自社開発企業に入った方が、幸せになれる確率が高まると思う。

しかし、働きながら1000時間もの勉強をするのは大変なのもたしか。

今後は「どうやったら働きながら勉強を継続できるか」、「少ない時間でも効果的に記憶できる方法」なども紹介していけたらと思う。

*1:イライラしてもしょうがないくらいハマり倒すようになったから、という方が正確かもしれない。

*2:小テスト自動作成サービスを作った。

アラフォー未経験から転職して1ヶ月経ったプログラマーの仕事内容さらしてみる

前回書いた記事が突然バズって、その反響の大きさに驚いた。

「感動した」「胸が熱くなった」などの好意的なコメントも多くいただき、とても嬉しかった。

昔の自分が知りたいと思っていたことを書いただけだったのだが、この辺の情報を知りたいと思っている人は多いのかもしれない。

ということで今回は、昔の自分が知りたかったことシリーズの第2弾として、web系プログラマーの仕事内容について書いてみたいと思う。

あくまでも1ヶ月しか経験のない立場からしか書けないが、逆に1ヶ月目ならではの視点というのもあるだろうから、そこらへんをできるだけリアルに書き残しておきたい。

以下に該当するような人には役立つかもしれない。

  • web系プログラマーの仕事内容を知りたい
  • 未経験から転職して最初に振られる仕事のレベル感を知りたい
  • チームで開発ってどうやるのか知りたい

ざっくりどんな仕事してんの?

自社webサービスの開発・保守。資料作成や会議なども含まれる。

勤務形態は?

正社員。6月はしばらく出社していたが、コロナ感染者数増加のため7月からはずっとリモートワークが続いている。

リモートになる判断も迅速で「感染者が増えてきた。じゃあリモートにしよう」という感じでとくに何の支障もなく切り替わった。*1

この辺の柔軟性はプログラマーという職種ならではというところがある。

ちなみに全面的にリモートになっているのは開発者だけで、他の部署では出社しているところもある。

典型的な1日は?*2

9:00 業務開始、朝会(今日やることの確認、懸念事項の共有など)

「朝会でわからないところ質問したら、このあと教えてくれることになった。ラッキー!」

9:30 ペアプロでスタッフ追加機能のロジックを教わる

「丁寧に教えてくれたおかげでコードの意味がよくわかった。上から目線がないのって本当に素敵だなぁ。」

12:00 休憩、お昼

「テック系YouTuberの動画でも見ながら昼飯食べるかな」

13:00 勉強会(技術書読書会、ハンズオン講習など)

「開発チームみんなでJavaScriptの本を読む。つよつよプログラマーの方たちによる一言注釈がためになるわー」

14:00 コード書く

「pluckってどんなメソッドだっけ?ああ、そうか、だからこれがこうなって。ふむふむ。ということはこうすれば動くかな?あれ?おかしいなぁ。binding.pryで変数の中身を確かめると...あ!slackにサービスのエラー通知がきてる!自分はまだ関われないけれど、対応が大変そうだ...。」

17:00 夕会(今日やったことの確認など)

「エラーの対応で皆さん疲弊気味だな。聞きたいことあったけど、ちょっと控えておこう...」

18:00 業務終了

「業務終了!子供が帰ってくる前に夕食作らないと...」

プログラマーの仕事って具体的にどんなことすんの?

主に要件定義・設計、開発、保守などの仕事があり、いま自分が担当しているのは主に開発と保守の仕事だ。

プログラマーになる前に疑問だったのが「サービスをリリースしたあとは何をしているの?」ということだった。

メインの機能ができてしまえば、あとはやることなどそう多くはないのではないかと思っていた。

これがとんだ間違いだった。

具体的には以下のような仕事をすることになる。*3

UI(見た目)の変更

具体例

  • ロゴの位置を少し変える
  • リンク先を変更する
  • ボタンの色を変える
  • 文面を変える

クライアントや営業からの要望などでUIを変えることはけっこうある。

サービスを利用するなかで「もっとこうしたら見やすい・使いやすいのに」という声が出てくるのは普通のことだからだ。

ちなみに自分が初めて割り振られた仕事も「リンク先のURLを変更する」というものだった。*4

ただ今の会社ではデザイナーがいるので、開発者が一からCSSを書くようなことは少ない。

新機能の追加

具体例

  • 管理者がユーザーを追加できるようにする
  • 記事にタグを付けられるようにする
  • 最近よく読まれている記事が上位に現れるようにする

これもクライアントや営業から「こんな機能があればもっと便利になるのに」という声を受けて追加することになる。*5

リリースから何年も経ち運用も安定しているサービスの場合、新機能追加は相対的に少なくなるが、それでも定期的に新機能の要望というのはあるもので、「すべてやり尽くしてしまってやることがない」などという状態にはなかなかならない。

保守

具体例

IT技術の流行り廃れは早いので、来年からこの技術は使えなくなる、なんてことがよく起こる。

「家が老朽化したのでレノベーションする」みたいなイメージだが、webの世界ではそれが数年のスパンで起きる。

バグの修正

具体例

  • 投稿ボタンをダブルクリックすると二重投稿されてしまう。
  • 注文中に日付が変わるとエラーになってしまう。
  • 通知設定しているのに通知がこない

バグはサービスの価値と信用に直結するので、最優先で対応される。

正直、自作サービスを作っている段階ではバグについてそれほど深刻にとらえていなかったのだが、業務について初めてその怖さがわかった。

「エラーが出ています。お客さまの〜件の注文に失敗しています」などの通知がくると、まだ直接関係するわけではないにもかかわらず、背筋が凍る思いがする。

さいわい、開発者や開発に近い人たちは皆、バグに対して優しい気がする。

バグが誰にでも起きうることであることをよく理解しているからだろう。

もしこれが「お前なにをやっているんだ!」と叱責されるような環境であったとしたら、相当つらいだろうなと思う。

雑務

具体例

サービスの価値に直結するわけではないが、長い目で見ればやった方がいい仕事のこと。

リファクタリングプログラマーにとってはとても大切に思えるが、ユーザーからすると価値に直結するわけではないので雑務として扱われる。

自分はまだ開発で貢献できる領域が少ないので、ドキュメントを書く機会が比較的多い。

ただ、優秀なプログラマーほど誰に頼まれるでもなく他者のために率先してドキュメントを書いていたりするので、初心者だけがやる仕事ということでもない。

新規サービスの設計・開発

これはまだ自分は経験していないのでわからないが、新規サービス開発もどんどんされているようだ。

凄腕のプログラマーたちが徹底的に議論しあって新しいサービスを作り上げていく様を見ていると、傍目にもその熱気が伝わってきてワクワクする。

チーム開発の仕方

基本的にはアジャイル開発というやり方で進めていく。

これは仕様書通りに開発することを目的とするのではなく、関係者で話し合いながらその都度計画を修正していく柔軟な開発スタイルのこと。

今の会社では3人から5人くらいのチームを組んでいる。

2週間に1回スプリント会議というものがあり、次の2週間でやるべきタスクを話し合いで決めている。

もしタスクが終わらなくても責められるようなことはなく、むしろそれはチームの責任なので次回の会議で計画が修正されるだけだ。

アジャイル開発など日本の現場ではほとんど行われていないという噂も聞いていたが、ほとんど本で読んだ通りの開発が行われていた。

個人的にこのアジャイル開発はエンジニアになってから特に気に入っているもので、開発者に過剰なプレッシャーをかけないし、心理的安全性が確保されている点が素晴らしい。

チーム運営についてこれほど構造化された手法は少ないと思うので、他業種でも多いに参考になると思う。

レベルは高すぎない?ついていけてる?

今はまだ本格的な業務に入ったばかりなので、ペアプロなどで教わりながら進めてもらっている。

大量のコードを読んで理解しないといけないのは大変だが、今の自分のレベルにあったタスクを与えてもらえているので、なんとかついていけている。

自分と同じように未経験から転職した人が同僚にいたり、チャットでわからないところを質問すると誰かが必ずコメントをくれるという環境にいるのも大きい。

仕事はコードを書くだけ?

コードを書く以外にも仕事はたくさんある。

たとえば、自分が書いたコードを他者にわかりやすく説明する文章は、コードとセットで必ず書かなければならない。

他にも他部署からの質問にチャット上で答えたり、自分はまだやったことがないが会議用の資料作成もしないといけない。

会議の時間は役職によって大きく違うが、いまの自分の場合、だいたい全体の1〜2割といったところだろう。

仕事内容に満足している?

想像以上にプログラミングに関わる時間が多く満足している。

仕事のレベルも今の自分のレベルにあったタスクを選んでもらえているので、まるで良質なパズルゲームを解いているみたいに問題解決の過程を楽しめている。

アジャイルによるチーム開発はとくに気に入っていて、開発者の主体性と心理的安全性が確保されているところがいい。

リモートワークも、自宅環境によっては生産性を維持するのが大変という側面もあるが、通勤時間から解放されるというのは想像以上に人生の幸福度を高めてくれる。*6

プログラマーの働き方は先進的

ここまで書いたことは、たった一ヶ月の経験しかない新米プログラマーの観察日記に過ぎない。

一口にweb系プログラマーの仕事といっても、会社の種類や規模、経験年数や役職などによって相当違ったものになるだろう。

それにもかかわらず今回プログラマーの仕事内容について書いたのは、自分が就職するにあたってその辺の情報が少ないと感じていたからだ。

プログラマーの働き方というのはとても合理的で、これからの時代を先取りしているところがあるのに、一般的にはそれほど知られていない。

私のプログラマーのイメージも、上司に叱責されながら納期に追われ日夜残業のブラック労働といったものだった。

そういう現場もあるのかもしれないが、そうでないところもある。*7

プログラマーの働き方についてプログラマー自身が発信することで、「プログラマーって楽しそう!」と思う人が少しでも増えるといいなと思っている。

*1:もちろん私の知らないところでは色々あったのかもしれないが。

*2:実際にあったことそのままは書けないので、現実に似せたフィクションにしてある

*3:ここで出している具体例はあくまでも業務に似せた例であり、実際の業務そのままではない。

*4:誰にでもできる仕事だが、マージされた瞬間はジーンと来るものがあった。

*5:もちろんそうした声のすべてを反映させるわけではなく、開発側からも意見を述べて両者が合意した時点で開発に着手することになる

*6:ただしリモートはずっと続く予定ではなく、コロナ禍のなかでの限定的な措置のようだ。

*7:もし私が働いている会社について知りたいという人がいましたら、お名前を明記したうえでTwitter経由で私までDMいただければ返信いたします。

アラフォーからプログラマーに転職して1ヶ月経ったけど、正直な感想書いてみる。

前職から転職して1ヶ月がすぎたので、現時点での個人の感想を記しておく。

以下に該当するような人にはひょっとしたら役立つかもしれない。

  • 30代だけどプログラマーに転職したい。
  • 自社開発企業に転職したい。
  • プログラミングスクールに通うべきか迷っている。   
  • 未経験から転職してついていけるか不安。

前職は何をしていたか

前提として、前職のことについて簡単に書いておく。

前職は中学の教員だった。

専任教員だったので、担任も持っていたし、生徒指導もしていたし、部活動も担当していた。

そう書くとブラックなイメージがあるかもしれないが、私立進学校だったのでそれほどハードでもなかった。

生徒は荒れているどころかおとなしすぎるくらいだし、部活も18時までには終わっていた。

朝は8時からなので早いが、それでも頑張れば9時間労働で帰ることもできた。*1

夏休みは1ヶ月以上あったし(ただし部活動や夏季講習で3分の2は潰れる)、教員食堂はあったし、福利厚生もしっかりしていた。

年収も40代後半で1000万越えするくらい高給だった。(追記: 自分は30代なのでそれよりは全然少ない)*2

労働時間は長いので、これをブラックとみるかどうかは人によるだろうが、搾取されているという感じを受ける人は少ないのではないだろうか。*3

そんないい条件で働けていたのに、どうして転職したのかということは今回は書かない。

とにかくそういう学校で働きながら、フィヨルドブートキャンプというプログラミングスクールで半年間勉強したあと、学校は退職。

しばらく転職活動をしていたが、都内の自社開発企業から内定をもらい、6月から働いている。

どういう会社にいるか

情報通信サービス系の自社開発企業。この業界のなかではそこそこ歴史もあって、経営も安定している。

サービスのほとんどはRuby on Railsで構築されていて、サーバはAWS、CI/CDにCircleCIなど、スタートアップで多いような構成だと思う。

ただ、年齢層はこの業界では比較的高め。

上司が自分より年齢が上なので、やりやすいといえばやりやすいのかもしれない。

給与は未経験にしては高めの額をもらえていると思う。

それでも前職と比べれば年収で200万以上はダウンした。

労働時間はきっかり8時間。

遅くまで残業するようなことはまずない。

福利厚生はしっかりしているし、コロナ禍によるリモートへの切り替えも早い。

まあどう考えてもホワイト企業だと思う。

入社から1ヶ月間何をしてきたか

いきなり開発の参加するということはなく、新入社員用のプロジェクトを進めている。

これは、簡単なタスク管理アプリをRailsで作る、というものだが、Railsでの開発を一から勉強するというものではなく、 主に実務でのチーム開発の作法を知り、会社でのやり方に慣れるためという位置付けのようだ。

プログラミングスクールを卒業したとはいえ、いきなり実務に飛び込むのは相当不安があったので、今のシステムはかなりありがたい。

レビューもたくさんしてもらえている。

プルリクを投げてレビューしてもらい、二人以上から承認されたらOKということになっているのだが、自分一人では気づけないような点が多く、とても勉強になる。

正直、いまはお金をもらいながら勉強させてもらっているようなもので、ありがたいとともに申し訳ない気持ちにもなる。

前職との違い

生活が安定している

毎日決まった時間に帰れるようになり、夕食を家族で食べられるようになった。

休日が部活で潰れるということがなくなった。

精神が安定している

生活が安定すると、当然ながら精神も安定してくる。

不測の事態で心が乱されるということがほぼなく、毎日平穏に過ごせている。

自分でコントロールできる範囲が大きい

プログラマーは成長するもしないも自分次第。

そして能力があれば評価されるので、努力次第で自分の価値を高めることができる。

これはつまり、自分の人生を自分でコントロールできる範囲が広いということ。

教員という仕事は、いくら自分の技術を高めても、それが即結果にはつながらないという難しさがあった。*4

人と喋らない

一日中ほとんど声を発さない日もある。

人によってはつらいだろうが、自分はまったく気にならない。むしろ楽。

チームワークが基本

前項と矛盾するようにみえるが、いろいろな機能が複雑に絡み合ったサービスを作るのに、個人が好き勝手にやっていたら連携などできるはずもない。

したがって、ソフトウェア開発はアジャイルとかスクラムなどのチーム開発のフレームワークに沿って開発するのが基本になる。

これらのフレームワークは人間的な柔軟性を重視するので、何かあればすぐにチャット上での議論が始まる。

単に「直接話すことが少ない」だけで、実はslackなどのチャットでの会話は非常に盛んだ。*5

リモートワークができる

6月からしばらくは出社していたが、状況が変わりまた今はリモートワークが中心になっている。

教員でリモートワークは、将来的にはさておき今のところ厳しいだろう。

勉強会がある

日々たゆまず勉強することが求められる職業なので、業務時間内に勉強会が毎週ある。

勉強しながらお金をもらえるのは素晴らしいし、勉強することに価値を感じている人たちと一緒に働けるのは楽しい。

前職とそれほど変わらないところ

コミュニケーション大事

教員には共感力などの感性的コミュニケーション能力が、プログラマーには説明力などのロジカルなコミュニケーション能力が必要とされているように感じる。

いずれにせよ、プログラマーだから人と話さなくてもいい、なんてことはまったくない。

会議がけっこうある

教員時代には「教員とはなんて会議が多い職業なんだ」と思っていたが、現職もわりと会議は多い。

タスクの洗い出しや割り当てを行うスプリント会議、他部署との会議、会社イベントの企画会議など、けっこう盛り沢山。

ただ、会議の進め方が構造化されていて、その目的と必要性が理解できるので嫌な感じはしない。

esaというツールを使って、みんなでワイワイ議事録を同時編集したりするのとか、普通に楽しい。

求められている能力

コミュニケーション力

チームの中で溶け込んでやっていける能力、というか態度・姿勢。

といっても普通に話せる能力があれば大丈夫だと思う。

説明力

自分の考えを他者に正確かつわかりやすく伝えられる能力。これが一番大事な気がする。

自走力

質問すればすぐに誰かが答えてくれるような環境ではあるが、当然ながら業務もあるわけで、一から手取り足取り教えてくれることを期待してはいけない。

すぐに「教えてくれ」ではなく、まずはいろいろ自分で問題解決のトライをしてみる、という態度が必要とされる。*6

求められていない力

圧倒的な技術力

そもそも未経験に技術面での期待などそれほどしていないように感じる。

未経験の場合、「俺の技術すげーだろアピール」をするよりも「今までの経歴からこういうポテンシャルがありますよ」というところをアピールした方が得策かもしれない。

年齢は関係するか

ほとんど関係ない

就職する前は年齢が大きな壁になるのではないかと思っていたが、入ってみると年齢をやたら気にするのは自分だけだった。

自分から話題にしない限り年齢のことなどあまり話題にもならない。

40代の人も普通にいるし、そもそも中途採用も多いのでそんなに特殊なことではない。

もちろん今の会社のことしか知らないので、どこまで一般化できるかはわからないが、「30代からの未経験プログラマ転職は難しい」なんていう意見には耳を貸す必要はない。

業務についていけているか

わからない

上にも書いたが、まだ今は研修段階のようなものなので、ついていけるかどうかはまだわからない。

会議に出ると、訳のわからないカタカナ英語が飛び交い、宇宙語のようで不安になる。

もちろんその都度メモを取り、あとから調べているので徐々にわかるようになってきた。

そういえば最近、基本情報技術者試験用の本を読んでいるのだが、会議で出てくる用語がけっこう出てくるので、この辺の基礎を抑えておくと楽になるかもしれない。

プログラマーはどんな人に向いてそうか

なってみて思ったのは、人を選ぶだろうなということ。

プログラマーを目指すような人ならたぶんわかっているとは思うが、基本的に一日中黙々とコードを書いているので、人と積極的に交流したい、というような人には向いていない。

逆に、けっこうコミュニケーション力が必要とされるので、人とまったく交流したくないという人にも向いていない。*7

あとは空気を吸うように勉強しないといけないので、勉強が嫌いという人にも向いていない。

文系でも大丈夫かどうかが気になる人がいるかもしれないが、いわゆる数学などの理系的知識は、少なくともweb系の場合はたぶんそれほど必要ない。

むしろ他者にわかりやすく説明できる能力が求められるので、文章力のような文系的能力の方が重要かもしれない。

正直、プログラマーになってみてどうか

最高。いまのところ楽しいことしかない。

自分が日々成長できていると実感できるし、成長することに価値があると思っている人たちと一緒に働けることがうれしい。

休日も自分のためにコードを書いている。

最近少しずつだが自分自身の問題をコードを書くことで解決できるようになってきた。

将来的には自分でサービスも作りたい。

イデアを出しているだけでワクワクしてくる。

自分の人生を自分でコントロールできるんだという実感が湧いてきて、それが幸福感につながっているのを感じる。

プログラマーになるまでには働きながら1年間勉強する必要があったが、こんなに楽しくて将来性もあって、幸福感を高めてくれる職業にその程度の努力でなれるなら大したコストではない。

未経験からプログラマーを目指して勉強中の人は、どうか周りの雑音に振り回されずにがんばってほしいと思う。*8

*1:ただ、実際には職員会議や組合会議、分掌会(生徒会とか進路とか)に生徒指導も入ったりして、10時間で終われればいいほうだった

*2:すべての私立校がこのレベルだというわけではない

*3:これで年収が低ければブラックに近づくとは思う。もちろん、労働時間の問題はこの学校に限ったものではなく、日本の学校一般に言えることである。

*4:教員時代は「クラスの雰囲気をいい感じにする」などの、変数が多すぎてコントロールするのが難しい仕事が苦手だった。逆に「成績を上げる」など、変数が比較的少なくコントロールしやすいところは得意だった。

*5:仕事に関するコミュニケーションの量自体は、教員時代よりもはるかに多い。教員は基本的に一匹狼だった。雑談はするが、授業に関する情報交換などはあまりなく、お互いの授業で何をやっているかはブラックボックスだった。もちろんすべての教員がそうというわけではないし、すべての学校がそうと言っているわけでもない。

*6:この辺はフィヨルドで鍛えられた。

*7:そもそもそういう人のための職業ってあるのか?

*8:そしてもし本気でプログラマーになりたいと思っているのなら、フィヨルドブートキャンプで学ぶことを強くおすすめします!!

Hamlの書き方

Hamlとは、Rubyを含むHTMLを簡略化して書けるマークアップ言語のこと。

今の勤め先ではHamlが使われている。

slimは使ったことがあるが、Hamlは初めてだったので調べてみた。

hamlの書き方

タグは%タグ名で表す。閉じタグは必要ない。 以下のように書くと、

%div
  %p
    Hello, Haml!

次のようにコンパイルされる。

<div>
  <p>
    Hello, Haml!
  </p>
</div>

通常のHTMLを書きたい場合はそのまま書けばよい。

%p
  <div id="main">日報</div>

は以下のようにコンパイルされる。

<p>
  <div id="main">日報</div>
</p>

クラスはドット(.)、idは#で表す。

<strong class="code" id="message">Hello, World!</strong>
%strong.code#message Hello, World!

Rubyコードを評価して欲しい場合は=を用いる。

<strong><%= item.title %></strong>
%strong= item.title

ネストはスペースで表す。

<div id='content'>
  <div class='left column'>
    <h2>Welcome to our site!</h2>
    <p><%= print_information %></p>
  </div>
  <div class="right column">
    <%= render :partial => "sidebar" %>
  </div>
</div>
#content
  .left.column
    %h2 Welcome to our site!
    %p= print_information
  .right.column
    = render :partial => "sidebar"

参照 : http://haml.info/tutorial.html

新規Railsプロジェクトを立ち上げるときの手順

最新のRubyをインストールする手順

To upgrade to the latest rbenv and update ruby-build with newly released Ruby versions, upgrade the Homebrew packages:

最新のrbenvにアップグレードし、ruby-buildを新しくリリースされたルビーのバージョンと一緒にアップデートするためには、Homebrewパッケージをアップグレードします。

$ brew upgrade rbenv ruby-build

手順

  1. $ brew upgrade rbenv ruby-build
  2. $ rbenv install --list
  3. $ rbenv install 2.7.1
  4. $ rbenv versions
  5. $ rbenv local 2.7.1

最新のRailsをインストールする手順

  1. $ gem install rails
  2. $ rails -v

その他

コミットメッセージを変更したい!

$  git commit --amend --allow-empty -m "commit message"
  • commitするものが何もない場合は--allow-emptyオプションをつける。

ミーティングに参加できないつらさ

リスニングができない

今の職場は割とミーティングがしっかりとある方だと思うのだけれど(比較はできないが)、知らないことだらけなのでとにかく言っていることがわからない。

わからないわからない言っててもしょうがないから用語をメモろうとするのだが、どれからメモしたらいいのかわからないくらいわからない。

というか、そもそも理解していないとリスニング能力すら落ちるらしく、何を言っているのか日本語が聞き取れない。

まあ、未経験からエンジニアに就職するとこういう感じになるのはしょうがないのだろうが、それにしても無力感に苛まれるので早く戦力になりたい。

黙々とアップデート。初マージも。

与えられた課題の方はまずまず順調。

今日は前回に引き続きインストールやアップデートでほぼ時間を取られた。

chefが何ものなのか全然わかっていないので、明日調べよう。

初マージも果たした。単にサーバ接続の設定をgithubにあげただけだが、それでも嬉しかった。

この辺でほとんどつまづくことがなかったのは、ひとえにフィヨルドブートキャンプのおかげだろう。

勉強会は楽しい

聴いているだけだったが、勉強会は割と理解できることも多く、サービスの理解にもつながるとても有意義なものだった。

こういうチャンスが週に2回もあるのは本当に恵まれている職場だと思う。

将来的には自分も発言することで貢献できるようにしたい。

エンジニア人生2日目にやったことすべて

今日やったこと

自社開発企業のエンジニアとして2日目が終わった。

当然ながらまだ研修段階なので、実際の開発業務ではなくPCのセッティングなどをこなした。

バレットジャーナルで大体ログは取ってるので、以下にやったことを記しておく。

8:00 出社・ZOOMで朝会(コロナのため早めの出勤になっている)

8:10 入社手続き(勤怠管理ソフトの登録、健康診断の手続きなど)

9:00 会社のシステム・今後やることの説明(使用ツールの導入など )

12:00 お昼

13:00 使用ツールの導入を進める

13:30 説明の続き(PC設定の方法、社内見学など)

14:30 PCの設定

15:30 夕会

15:40 PCの設定

18:00 退社

黙々と作業を進められる幸せ

今日は昨日よりはPCに触れられる時間が増えたため、とても楽しかった。

エンジニアなら当たり前なのかもしれないが、自分のペースで黙々と作業を進められるのがとても心地いい。

教員は授業があってその時間は必ず拘束されるし、空き時間もあってないようなものだった(そのぶん充実感はあったが)。

自分でコントロールできる時間が多い今の環境は、自分の性格的に合っていると思う。

バレットジャーナルも慣れてきて、できるだけやったことのメモを取り、振り返るようにしている。

自分でコントロールできる時間が増えるというのは、逆から見ればいくらでもダラダラと過ごせてしまうということ。

常に意識的な時間の使い方をしていきたい。

使用ツール・勉強会

とにかく色々な使用ツールがあってすべては飲み込めていないのだが、これは良さそうと思ったのが、 オンラインホワイトボードサービスのmiro(カンバンのビジュアルがとっても綺麗)、情報共有ツールのesaGoogleカレンダー(こんなに便利だなんて知らなかった!)など。

esaとか早速使い出して、デザインも機能性も抜群でいいサービスだなぁと感心している。

こういうサービスを自分でも作れるようになりたい!

あと、週2に2回、社内で勉強会が開かれているのがとてもいいと思った。

しかも業務時間内なので、勉強しつつお金がもらえるということ。

これは、社員の教育はサービスの価値を高めると会社が信じているということであり、そういう会社はいい会社に違いない。

とにかく人がやさしい

どの人もすぐに「大丈夫?わからなかったらいつでも質問してね」と言ってくれる。

チャットで質問すると1分以内に答えがかえってくる。

5時をすぎてまだ作業していると、「どうしたの?早く帰りなよ」と言ってくれる。

間違いなくホワイトです。

課題

PCの設定などすぐにできるだろう、とタカをくくっていたが、これが結構昔のMacでアップグレードするだけでも結構苦労した。

やはり見積もりは自分が当初に思った3倍はかかると思った方がいいのだろう。

明日は少しバッファを意識してスケジュールを組みたい。