Webエンジニアになって3ヶ月が経ちました

Webエンジニア キャリア 働き方

はじめに

Webエンジニアにキャリアチェンジして、3ヶ月が経過しました。

今回は直近約2ヶ月間(6〜7月)の振り返りとなります。

目次

おもな仕事内容と得られた知見

入社直後にアサインされたプロジェクトを、7月のリリース完了まで引き続き担当しました。

(アサイン当初の話はこちら👇)

プロジェクト内で担当する領域としては、LaravelによるバックエンドとVue.jsによるフロントエンドの開発となります。

様々な機能の実装を行なったのですが、その中で特に印象に残ったこととして以下の3点があります。

  • フレームワークの機能の把握
  • 適度なドキュメント整備
  • テストコード

フレームワークの機能の把握

今回のプロジェクトで作る各画面では、社内外のユーザーの権限やデータの状態に応じて、各データへの参照可否や更新可否を制御する必要がありました。

それらをどう実現するか・・・と、Laravelの公式ドキュメントを調べているとGateやPolicyといった認可の機能が見つかったので、これらの使い方を公式ドキュメントで調べながら順次実装していきました。

この認可に関しては自らフレームワークの適切な機能を選択して実装することができましたが、他の認可以外の機能に関してはレビュアーから

「Laravelではこれこれという標準的な機能があるのでそれを使った方が良い」

と指摘を受けることもあったので、フレームワークの様々な機能を幅広く把握しておくことは重要だと感じました。

そのフレームワークを選択しているからには、フレームワークの思想や設計に準じて実装していくことが求められる・・・と考えるからです。

このあたり、経験や知識量が多分に関係してくると思うので、

  • 日頃から公式ドキュメント等でインプットしておく
  • 一方で、そのフレームワークでの開発経験が長い周囲のエンジニアに早めに相談して手戻りの発生を抑える

といったことをバランス良く行うことが大切かな、と思います。

適度なドキュメント整備

前述の認可では、ユーザーの権限やデータの状態、操作内容といった可否の組み合わせが多岐に渡りました。

そのため、実装漏れが無いよう、いったん対応が必要な箇所をドキュメントに洗い出した上で、順次実装していくことにしました。

前職でIT関連の利用部署にいた時は膨大なドキュメントと付き合っており、それに対して現職ではドキュメント作成は必要最低限とする文化にあると思っていますが、この認可の仕様に関しては抜け漏れ防止の面であらかじめドキュメントを整備しておいて良かったと思います。

テストコード

今回のプロジェクトで、最も重要な機能のひとつが、バッチ処理や画面での入力に応じて金額の計算を行う、というものでした。

これに関しては、テスト駆動開発、とまでは行きませんでしたが、金額計算の実装がある程度終わってから、それを追いかけるようにテストコードを書きました。

職場の環境では、開発したコードは必ず自動でテストが実行される仕組みになっています。

ですので、いったん完成した金額計算のコードに新たに追加・修正を行う必要が生じた際も、作成済みのテストがあれば非常に安心感がありました。

適切なテストを書いていれば、追加・修正したコードを起因としてこれまでうまくいっていた金額計算に不備が生じる、ということを避けられるからです。

テストコードに対しては、

「こんな便利なものはもっと早くから書き始めれば良かった・・・」

という思いがあり、テストコードを書き始める前の自分を読者として想定して、チュートリアル風の記事をQiitaに投稿しました。

こちらがありがたいことに好評で、一時期デイリートレンド1位まで獲得し、200以上のいいねをもらうことができました。

社内のSlackでも、トレンド入りを採り上げてもらい、とても励みになりました。

今後について

そんなこんなで3ヶ月目も経過したのですが、このたび職場で新チーム体制の発表があり、私はSREチームへの配属が決まりました。

実際には9月からの配属なので、まだSREとしての実務には入っていないのですが、

  • AWS全般
  • Ansible
  • CI/CD
  • Go

などがキーワードになりそうです。

もともとSREには関心があって、いずれはやってみたいとは思ってたのですが、予想外に早くそのタイミングがやってきましたw

キャッチアップは非常に大変だと思いますが、SREという考え方や自社のインフラを細部まで把握できる(しなければならない)良い機会となるので、何とか頑張っていきたいと思います。

最後に

以上、Webエンジニア3ヶ月目の振り返りでした。

今後SREや、その他エンジニアとして学びや気づきがあった際にはまた報告したいと思います。

Webエンジニアになって1ヶ月が経ちました

Webエンジニア キャリア 働き方

はじめに

今年5月からWebエンジニアとして働き始めたことを以前にブログでお伝えしました。

6月に入り、この1ヶ月でWebエンジニアとしてどんな働き方をしてきたかを簡単に振り返りたいと思います。

目次

配属先

私は6名ほどのチームに配属になりました。

配属後2, 3日程度の間はチームに以前から積み残っていた、比較的優先度の低い改修タスクが割り振られ、それらをこなしていました。

その後は、このチームが抱える7月リリース予定のプロジェクトにアサインされ、その開発を行っています。

仕事の進め方

プロジェクトにおいて開発が必要となる各機能は、GitHub上で一定の粒度でIssue化(課題として登録)されています。

(なお、プロジェクトによってはRedmineで管理されています)

配属当初はリーダーから各Issueを順次アサインしてもらっていましたが、現在は自分でIssueを選んだり、あるいは把握した要件をもとに自らissueを立てて自分自身にアサインしたりしています。

この辺り、ただ与えられたタスクを受け身でこなすのではなく、自ら考えて仕事を組み立ていくことになりますので、一定の裁量があって自分としてはとてもやりやすく感じています。

1日の仕事の流れ

現在はプロジェクトで「何を作るか？」がほぼ明確になっていることもあり、日々の大半はコードを書いています。

だいたい1日に3本程度のIssueに並行して取り組んでいる感じでしょうか。

ひとつのIssueに対するコードを書き終え、GitHub上でレビュー依頼をしたら、別のIssueに取り掛かり、依頼したレビューで指摘コメントが入ったら、今度はその対応に着手して・・・といった具合です。

コードに充分に触れたくてWebエンジニアという職種を選んだので、この環境にはとても満足しています。

なお、7月のリリースを終えて次のプロジェクトが始まったら打ち合わせの比重が高まるかもしれませんが、サービス作りの初期から参画できるので、それはそれで楽しみでもあります。

コードレビュー

書いたコードは、必ず別のエンジニアにレビューをしてもらうルールになっています。

正しく動きさえすればどんなコードでも良い、といったことは全く無く、 今後の保守のしやすさ、読みやすさなど様々な観点から適切なコードが書けているかが厳しくチェックされます。

厳しく、とは書きましたが、こうしたコードレビューから私が感じるのは「ダメ出し」のようなネガティブなものではなくて、より品質の高いものを皆で築き上げていこうという前向きなものです。

レビューが指摘無く一発で通れば、それはそれで嬉しいものなのですが、経験豊富なエンジニアからの指摘、コメントからは(その後ググって色々調べて得る知識も含めて)多くの学びがあります。

なので、(色々と指摘をさせてしまっているレビュアーには申し訳ない気持ちを持ちつつも)指摘、コメントがあれば「ラッキー！」と捉えて、指摘対応に取り組むようにしています。

なお、レビューでのコメント内容についても辛辣なものにはこれまで出会ったことは無くて、レビュアー側も充分に配慮してコメントしてくれているんだろうと思います。

今後について

1ヶ月を振り返ると、とにかくLaravel(PHP)のコードを書いていました。

Laravelに対する理解は以前よりぐっと深まり、それはそれでとても良かったのですが、裏を返すとLaravelの開発が必要となるIssueにばかり手を出していた、ということでもありました。

チームにはフロントエンド(Vue.js)のタスクもごろごろ転がっており、LaravelとVue.jsのどちらも書ける人が多数いますので、自分としても苦手意識のあるフロントエンドに手を出していかなければ・・・と思っています。

冒頭に

現在は自分でIssueを選んだり、あるいは把握した要件をもとに自らissueを立てて自分自身にアサインしたりしています。

この辺り、ただ与えられたタスクを受け身でこなすのではなく、自ら考えて仕事を組み立ていくことになりますので、一定の裁量があって自分としてはとてもやりやすく感じています。

と書きましたが、だからと言って、易きに流れてはいけませんね。。。

その他生活面

Webエンジニアの仕事内容そのものではなく環境面の変化で良かったことになりますが、出社時刻が柔軟なおかげで、こどもの保育園への送りを毎朝担当できています。

Webエンジニアは、他の職種と比べて勤務形態が柔軟なケースが多いと思いますが、こうした点も転職して良かったと感じています。

最後に

以上、Webエンジニアとなって最初の1ヶ月の振り返りでした。

Webエンジニアを目指している方の参考になれば幸いです。

またしばらく時間が経ったら、改めて振り返りをレポートしたいと思います。

Webエンジニアになって初めて使うようになったGitコマンド5選

Git

はじめに

独学でプログラミングを勉強していた頃には全く知らなかったけれど、Webエンジニアに転職してから実務でよく使う便利なGitコマンド/オプションを状況別に5個紹介します。

1位 作業途中の状態から、別のブランチに切り替えたい

ローカルブランチでファイルの更新作業中の場合、別のブランチに切り替えようとgit checkout (ブランチ名)を行っても、エラーが出てブランチを切り替えることはできません。

こんな時、そのエラーメッセージにも表示されているstashが使えます。

stashは、こっそりしまう/隠すといった意味で、自分の作業内容を退避できます。

以下コマンドで、作業内容が退避され、別のブランチに切り替えが可能となります。

git stash save

なお、退避した内容を再び取り出すには、git stash list, git stasg applyを使います。

まず、git stash listとすることで、退避した内容を一覧表示できます。

stash@{0}: WIP on feature/add_foo: 2c4e8b539 fooを追加
stash@{1}: WIP on feature/add_bar: 2c4e8b539 barを追加

次に、ここから取り出したい退避内容を以下コマンドで取り出します。

git stash apply stash@{0}

より詳しい使い方は、以下記事が参考になります。

qiita.com

2位 直前のcommitを無かったことにしたい

以下コマンドで直前のcommitを取り消せます。

commitされていた更新ファイルは、addした状態に戻ります。

git reset --soft HEAD^

3位 直前のcommitメッセージを修正したい

以下コマンドで、commitメッセージが表示されます。

git commit --amend

表示されたcommitメッセージに対して、以下の手順で修正が行えます。

  • iでインサートモードへ
  • commitメッセージを修正
  • escキーでコマンドモードへ
  • :wで修正した内容を書き込む
  • :qで抜ける

4位 ブランチ名を後から修正したい

以下コマンドで現在自分がいるブランチのブランチ名を変更できます。

git branch -m 新ブランチ名

ブランチ名を英語で付けることが開発チームのルールで定められているけれど、いい感じの名前が思いつかない・・・といったような時に、私は適当な名前でとりあえずブランチを作って作業を開始して、リモートリポジトリにpushするまでには正式なブランチ名に変更する、といった使い方をしています。

5位 addを無かったことにしたい

以下コマンドでaddしたファイルをaddする前の状態に戻せます。

git reset HEAD ファイル名

最後に

やはりWebエンジニアとして実務に就くと、独学の頃と比較して覚えることの幅は格段に広がります。

今回採り上げたGitもそのひとつでした。

今回の記事が最近Webエンジニアになった方のお役に立てば幸いです。

blog.shonansurvivors.com

Webエンジニアになって1週間が経ちました

キャリア 転職

はじめに

今年1月からWebエンジニアへの転職活動を行い、2月末に内定を獲得したことを以前にブログでお伝えしました。

転職先の会社にはこの5月の連休明けから入社して働いているので、その簡単な振り返りを報告します。

所感

まだわずか1週間ではありますが、Webエンジニアとして実務に携わった感想としては以下のツイートの通りです。

勉強しなければならないことは膨大にありますが、良い環境に身を置けていると実感しているので、引き続きエンジニアとしての経験を積み、自社のサービスに貢献していきたいと思っています。

入社前にやっておいて良かったこと

ここからは人や会社の事情によりけりですが、入社前にやっておいて良かったと個人的に思っていることを書きます。

今後転職してWebエンジニアとしてのキャリアをスタートさせることになる方の参考になれば幸いです。

1. Dockerに触れること

職場では各自のローカルの開発環境をDockerで構築することになっています。

仮にDockerの経験が無かったとしても、職場が用意してくれた手順に従えば問題無く開発環境は構築できるのですが、いくつかの簡単なコマンドを知っていたり、Dockerfileやdocker-compose.ymlの内容を多少なりとも理解できていたことで、入社初日の環境構築を焦らずに完了させることができました。

2. 職場で使用しているWebアプリケーションフレームワークの予習

Qiitaやtwitterなどでは「Railsを勉強してRailsでポートフォリオを作ってRailsでサービスを作っている企業に就職した」という方をよく見かける気がしますが、私の場合はDjangoで勉強してDjangoでポートフォリオを作成して、最終的にLaravelをメインで使っている企業に就職しているので、より一段とキャッチアップの必要があります。

これに関しては、入社前までの期間を使って書籍のチュートリアルを進めたり、Qiitaに自分で考えたチュートリアルを投稿したりしました。

これをもしやっていなかったとしたら、入社最初の1週間はより苦労していたと思います。

3. 転職先の人との交流

入社前の1ヶ月間は前職の有給消化中だったのですが、そのうちの何日かは転職先の人とランチをしました（そのような機会を設けてもらえました）。

入社前から何名かの人と事前に顔見知りになっていたことは、感じる必要も無い余計な緊張や不安を取り払ってくれました。

最後に

ということで、良い環境であること、事前の準備が役に立ったことで、充実した1週間を過ごすことができました。

今後も引き続きエンジニアとして頑張っていきたいと思います。

平成最後のみんなのPython勉強会で得た知見 〜 正規表現/機械学習/Pyramid/環境構築/Falcon/そして 〜

Python 勉強会

はじめに

先日開催された、みんなのPython勉強会で得られた知見についてまとめます。

startpython.connpass.com

毎月開催されている、この「みんなのPython勉強会」。

2019年4月開催の今回は平成最後ということもあり、司会進行と計6人の登壇者全員が平成生まれ縛りとなっていました。

本ブログ記事は全体としては少し長文なので、概要だけをさっと知りたい方は1.1〜1.6までを参照ください。

その後2.1から各登壇内容の詳細レポートが改めて続きます。

1. 各登壇内容からの知見抜粋

1.1. 正規表現

  • Pythonの正規表現における\wがマッチするのは、[a-zA-Z0-9_](半角英数字とアンダースコア)だけではない

  • それ以外にも、かな漢字、ヘブライ文字、アラビア文字などの非常に多くの(20,000種以上の)Unicode文字にマッチする

1.2. 機械学習

  • 機械学習におけるデータクレンジングでは、実際の状況（今回であればタイタニック号沈没）を想像しながら特徴量として活用できるものを探す

1.3. Pyramid

  • 過去に自身で開発したDjango製アプリを、情報の少ないPyramidで作ることに挑戦

  • 苦戦はしたが、Djangoの良さ、Pyramidの良さ、それぞれ発見があった

1.4. 環境構築

  • 初学者は、Pythonやパッケージのインストール方法をどれか1つだけにするのがおすすめ
    • Pythonのインストール
      • python.orgからのインストールとAnaconda利用の両方などは避ける
    • パッケージのインストール
      • Anaconda利用者であれば、pip installはconda installに読み替える
  • 次のステップとして仮想環境を利用すると良い

1.5. Falcon

  • 同じ軽量フレームワークであるFlaskと比較して10倍以上高速

  • RESTfulな機能を持ち、バックエンドAPI開発に適している

1.6. 持っていないものを見つける話

  • Pythonを含めたオープンソースと、それにまつわるコミュニティは持っていない者の味方

  • 自分の持っていない物が分かれば、自分がどこで活躍すべきかが分かる

目次

2.各登壇内容の詳細レポート

2.1. Pythonにおける正規表現の話 \wとUnicodeの意外な関係

\wは、半角英数字とアンダースコア以外の多くのUnicode文字ともマッチする

  • Pythonの正規表現における\wはany word characterと呼ばれる

  • \wは、[a-zA-Z0-9_](半角英数字とアンダースコア)と同義と説明されている場合があるが、それ以外の非常に多くのUnicode文字にもマッチする

    • 例えば、日本語のかな漢字にもマッチする

    • Python3の公式ドキュメントによれば「unicodedataモジュールで提供されているUnicode データベースでlettersとしてマークされている全ての文字とマッチする」とある

Unicodeにおいては各文字はLetter, Numberなどにカテゴリ分けされている

  • カテゴリはLetter, Number, Punctuationなど

  • それぞれLx, Nx, Pxと表現される

    • Lettersもさらに以下に分類される

      • Lu(Uppercase:大文字)
      • Ll(Lowercase:小文字)
      • Lo(Other:その他)

    • このLoに分類されるのが、かな漢字、ヘブライ文字、アラビア文字などであり、非常に文字数が多い

    • Numberも以下に分けられる

      • Nd(Decimal Digit:10進数)
      • Nl(Letter:ローマ数字などの数を表す文字)
      • No(Other:分数などのその他の文字)

\wは全てのLetter, Numberにマッチするわけではなく、一部例外がある

  • \wは20,000種以上の文字にマッチするが全てのLetter, Numberにマッチするわけではなく一部例外がある

漢字だけマッチさせたい場合は、Unicode文字ブロパティを使うと良い

  • 漢字プラス「々」といった記号だけをマッチさせたい場合は、regexモジュールで漢字のUnicodeエイリアスp{Han}を指定すると良い
>>>import regex
>>>regex.findall(r'p{Han}', '堂々')
['堂', '々']

2.2. Pythonと挑んだtitanic 〜 101回目のsubmit 〜

Kaggleは予測モデリングおよび分析手法関連プラットホーム

  • 企業等がデータを投稿し、世界中の統計家やデータ分析家がその最適モデルを競い合う場

titanicはKaggle内のコンペ

  • 沈没したタイタニック号からの生存者を予測する課題

機械学習モデルの作成では最初にデータのクレンジングを行う

  • 欠損値補完
  • 特徴量作成
  • 不使用の特徴量の削除

データのクレンジングにあたっては、実際の状況(タイタニック号の沈没)を想像しながら特徴量として活用できるものを探す

  • 欠損値の補完の一例

    • 年齢の場合

      • Miss, Mrs, Mrなどの敬称ごとの平均年齢を算出し補完

  • 特徴量の作成の一例

    • まず家族の人数を算出し、そこから更に脱出船に乗れる確率を仮定

      • 父、母、幼い子2人であれば、子どもから優先して脱出船に乗れると想定

今回の予測モデル作成の詳細記事

2.3. DjangoとPyramidで同じアプリを作った話

既存のDjango製アプリを、情報の少ないPyramidで作ることに挑戦した

  • 過去に自身で開発したDjango製アプリを、他のフレームワークで開発するとどうなるのか疑問に思った

  • 他のフレームワークには、資料の少ないPyramidを選定

Pyramidによる開発で苦戦した点

  • フルスタックフレームワークであるDjangoと比較すると、Pyramidでは他のパッケージを利用する必要があり、それらの学習コストを要する

    • 今回は以下パッケージを使用した
      • ORMにOrator
      • テストにPytest

  • Djangoは比較的「こうあるべき」という指針が明示されているが、Pyramidにはそうしたものが無いので実装時に判断に迷うことがあった

Pyramidで好きな点

  • add_request_method
    • リクエストオブジェクトにメソッドまたはプロパティを加える
  • 簡易な計算結果をモジュールひとつでWebブラウザに表示できる
  • 疎結合なアプリケーションを作りやすい
  • viewのテスト実行が早い

Django以外のフレームワークでWeb開発する場合のアドバイス

  • 「Djangoでは◯◯ができるのに」という考えは捨てた方が良い

    • 比較するにはDjangoは用意された機能があまりにも手厚すぎる

  • Django経験者にとっては「車輪の再発明」に思えるような開発をすることもあるかもしれないが、それ自体も楽しもう

2.4. P(ython)&I 最初の落とし穴を避け、成功体験を積むために

自身のPython成功体験を支えたのは環境構築

  • 最初に手に取った本は「退屈なことはPythonにやらせよう」

退屈なことはPythonにやらせよう ―ノンプログラマーにもできる自動化処理プログラミング

退屈なことはPythonにやらせよう ―ノンプログラマーにもできる自動化処理プログラミング

  • 最初の環境構築が上手くいったので、Pythonでの成功体験を積むことができた

Pythonを始めた直後の人は環境構築でつまずきやすい

  • その後、自身がPythonを初学者に教えるようになって、環境構築でつまずく人が多いことに気付いた

  • よく見られるのが、Pythonを重複してインストールしているケース

    • python.orgからのインストールとAnaconda利用の両方など

Pythonのインストール方法はどれか1つだけにしよう

  • 各種チュートリアルの記載の通りに進める姿勢は素晴らしいが、Pythonのインストール方法が自分とは異なる場合は、その部分を読み替えよう

パッケージのインストールはpip installとconda installのどちらかに統一しよう

  • 例えば、python.orgからPythonをインストール済みであるところ、Anacondaを利用した機械学習の解説記事を実践してみたくなったら？

    • この場合、Anacondaを導入することはおすすめしない
    • Anacondaに最初から入っているパッケージ(numpy, scikit-learnなど)は、個別にpip installしよう

  • 逆に、AnacondaでPythonをインストール済みであるところ、python.orgからPythonをダウンロードして環境構築している記事を実践する場合は？

    • 記事中でパッケージをpip installしている箇所は、conda installに読み替えよう

次のステップとして仮想環境を利用しよう

  • venvなどを使う
    • 詳細はPyNyumonテキストを参照
  • Anacondaであれば、conda create, conda activateで環境を作成・切替できる
    • 詳細はpython.jpのCondaコマンドを参照

2.5. FlaskとDjango以外のAPI開発の選択肢

PythonのWebアプリケーションフレームワークの二大巨頭といえばFlaskとDjango

  • Flask
    • 軽量、学習コスト低
  • Django
    • フルスタック、学習コスト高

Flaskの機能は最低限に絞られ、パフォーマンスもさほど良くない

  • 一定の機能を作るには、サードパーティのライブラリをある程度把握する必要あり

  • 他のフレームワークと比べ、パフォーマンスはそれほど良くない

DjangoはバックエンドAPI開発には不要な機能も多い

  • フルスタック故に他のサードパーティライブラリを入れなくても一通りの開発ができるが、学習コストもそこそこあり、ちょっとしたものを開発するのには不向き

  • バックエンドAPI開発には不要な機能も多い

Falconはパフォーマンスの良いAPIを開発するのに適している

  • 最近はフロントエンドのSPA化が進み、フロントとバックエンド分離のニーズは高い

  • FalconはFlaskの10倍以上の速度

  • FalconのResourceという機能(MVCのCに相当)はRESTfulであり、API開発に適している

Falconの課題はサードパーティの少なさと、しっかりとした設計が求められること

  • 同じ軽量フレームワークであるFlaskよりもサードパーティライブラリが少ない

  • Flask同様、構成はしっかりと設計する必要がある

    • DDD（ドメイン駆動設計）のオニオンアーキテクチャ、クリーンアーキテクチャで設計すると良いかもしれない

今後のFalconはASGI対応予定

  • 今後リリース予定の3.0ではASGI対応予定

2.6. 無題（持っていないものを見つける話）

Python, Linux, 初のWebブラウザも平成初期の生まれ

  • Pythonは1991〜1992年生まれ(平成3〜4年)

  • Linuxは1991年生まれ(平成3年)

  • 初のWebブラウザ(NCSA Mosaic)は1993年生まれ(平成5年)

平成時代にPythonでWebアプリを作り続けてきた

  • 学生時代にPythonに出会い、様々なWebアプリケーションを作ってきた

  • 就職後も受託開発や自社サービス開発でWebアプリケーションを作る

  • 自分のスキル（Webアプリ開発経験）と会社の強み（Pythonに特化）を活かし、新規ビジネスとなる自社サービスのWebアプリを作ることができた

Pythonプロフェッショナルプログラミング第3版

Pythonプロフェッショナルプログラミング第3版

持っていない者にとって大切なのは自分らしい物を作ること、オープンソースはそんな持っていない者の味方

  • 大企業のような原資を持たない場合、自社サービスの運営（マーケティングやその他）では制約があるが、そんな中で大切なのは自分たちらしい物を作ること

  • Pythonを含めたオープンソースと、それにまつわるコミュニティは持っていない者の味方であった

  • 自分の持っていない物が分かれば、自分がどこで活躍すべきかが分かる

失われた時代という平成を生きたからこそ、次の令和に作れるものがある

  • 平成には失われた20年（10年とも30年とも）があるといわれ、これを耳にすると平成で生まれ育った自分は消沈してしまう

  • しかし、失われた時代に生きたからこそ、次の令和に作れるものがある

3. 最後に

勉強会終了後の私のツイートより。

本当に素晴らしい勉強会でした。

主催のStart Python Clubの方々、会場提供のリーディングエッジ社さん、登壇者の方々、また懇親会でお話しさせていただいた方々、ありがとうございました！

WEBエンジニアへ転職したい人のための勉強会「転職LT#4 〜春の転職まつり〜」に参加してきました

キャリア 勉強会 転職

はじめに

WEBエンジニアへ転職したい人のための勉強会「転職LT#4 〜春の転職まつり〜」に参加してきたので、そのレポートです。

目次

参加のきっかけ

2019年2月1日(金)に参加したWebエンジニア勉強会#11にも登壇*1されていたVTRyo(@3s_hv)さんが、転職関連の勉強会を過去何度か主催されており、2月の中ごろにconnpass上で新たな勉強会が開催されることが告知された為、早速申し込みました。

申し込み当時、私は転職活動の真っ只中で翌日には最終面接を控えているような緊張した状況でした。

転職活動が上手くいかなかった時に備え、新たな企業との出会いのチャンスもありそうなこの約一月半後の勉強会に申し込んだわけなのですが、結果的には内定を獲得*2し転職活動を終了させた状態で参加することになりました。

とは言え、勉強会では新たな気付きがあったほか、懇親会では私の方から転職活動の経験を他の参加者の方々にお話しすることなどもできましたので、参加して良かったと思います。

会場およびスポンサー企業

会場は、渋谷にある株式会社サポーターズさんの東京オフィスでした。

また、この勉強会は以下の各社さんがスポンサーとなっており、飲食有りでありながら参加費無料というありがたい勉強会となっていました。

登壇内容メモ

未経験だからこそSNS転職

リョッキー(@ryokky59)さん

  • 4ヶ月の転職活動について
  • 0ヶ月目
    • 仕事を辞め、新潟から渋谷のシェアハウスへ
    • プログラミングスクールへ
    • twitterアカウント作成
  • 1ヶ月目
    • 1日8〜10時間必死に勉強。周りから「怖い」と言われるほど。
    • twitterで勉強した内容を毎日ツイート
  • 2ヶ月目
    • オリジナルアプリを作成。楽しい。
    • 週1回Qiitaへの記事投稿にチャレンジ
      • 初学者だからこそ初学者にわかりやすい記事を書ける
    • もくもく会、勉強会に参加
      • スクールは未経験しかいないが、実際に働いているエンジニアの話が聞けた
      • 一方で未経験者もいるから参加しやすい
      • 採用に関する話も転がっているので、懇親会に参加しよう
  • 3ヶ月目
    • 最初はエージェント経由で企業との面接を申し込む
    • 計20回面接し、業界知識が付いたほか、面接慣れした
  • 4ヶ月目
    • Wantedlyで、少しでも技術に興味のある企業に対しては「話を聞きに行く」ボタンを連打
    • 実際に面談できる確率は5割いかないぐらい
  • やって良かったことのまとめ
    • twitterを使ってアウトプットを見せつける
      • Qiitaに投稿したら、勉強会に参加したら、勉強したら、とにかくつぶやく
    • WantedlyにtwitterやGitHubアカウントを連携し、アウトプットを企業に見てもらう為の手間を極力減らす
    • 見てもらえなかったら、アウトプットしていないのと同じ

Qiitaでの転職活動記も話題となったリョッキー(@ryokky59)さんの登壇。

その勉強時間や面接回数は誰もが真似できるものではないかもしれませんが、Wantedlyも含めSNSを活用したアウトプットの積極的アピール方法は大変参考になります。

SNS転職での失敗

おかしん(@okash1n)さん

スライド撮影禁止のややセンシティブな内容でしたので、メモは取らず登壇内容を集中して聴くことにしました。

一言でいうと「転職に際して不義理はNG」ということであり、自分自身も気を付けたいところです。

この「失敗談」、途中までそのストーリーにハラハラしましたが、最終的には登場人物の仲は円満な結果へと落ち着き、ホッとしました。まさに雨降って地固まる、といったお話でした。

面接をイージーモードにするコツ

のみぞん(@nomizooone)さん

  • 「自分のトークに自信ありますか？」
  • 転職歴6回の中で初めての転職活動(半年間)では数十社から不採用となり心が折れ、一度は諦めた
  • しかし、その後、年齢は重ねたものの転職の回数を重ねるごとに慣れていき、今では数社から内定を獲得し、自分が選択できる立場に
  • 職務経歴書を万全にし、職務経歴書に喋らせてしまう
    • よくあるテンプレートを使わず、自分という商品を売り込める内容に
  • よくある質問に対する回答を文字に起こして準備する
    • 自分で納得できる回答であることが大切で、暗記は駄目
  • 最初の自己紹介だけで良いので声に出して録画して練習する
    • 面接の始まりは高確率で自己紹介。最初に良い雰囲気を作れると後が楽。

私も喋りに自信は無いので、よくある質問に対する回答はある程度事前に用意しましたが、ここまでの事前準備はできていませんでした。

でも、この登壇内容の通り、準備すればするほど自信が付いて堂々と受け答えができるんですよね。

また、職務経歴書をここまで整備して採用担当の興味を惹き、これに関する質疑応答の場にしてしまうというのは、面接を応募者側がコントロールしてしまっていますね。凄い。

失敗と改善で進めた転職活動

Tomoki(@tofu511)さん

  • 9ヶ月に渡る失敗と改善の転職活動記
  • 失敗1
    • 書類選考、一次面接は通過するが、その先が続かず
    • 志望理由、モチベーションは認めてもらえるものの最後の一押しが足りなかった
  • 失敗1への改善
    • エンジニアのキャリア関連の勉強会に参加し、有識者に相談
    • ポートフォリオ作成を勧められ、挑戦することに
  • 失敗2
    • Ruby on Railsでポートフォリオ作成を進める
    • しかし、慣れない言語(動的型付け)であることや、わからないことを聞ける知見のある人が周囲にいないことから、エラーにはまり込む
    • モチベーションは地の底へ
  • 失敗2への改善
    • オンラインのプログラミングスクールを使い、わからないことをいつでも聞けるように
    • 経験のあるJavaと同じJVM言語であるScalaを選択
    • モチベーション低下を防ぎ、挫折することなく、ポートフォリオを作成
  • 転職成功
    • ポートフォリオ作成を終えた月から活動再開
    • ポートフォリオの力は絶大で、翌月には第一志望の企業から内定獲得

私は幸いポートフォリオを作成した上で転職活動に臨むことができましたが、それも転職成功事例の情報収集があったからこそ。一人の力は弱くても、情報や有識者、環境といった周囲の力を得ることの大切さを再認識しました。

そして、最終ページの「伝えたいこと」は必見。

最後に

勉強会後の懇親会では、美味しい料理やお酒とともに、登壇者や以下の参加者の方々を中心に楽しく交流することができました。

  • 普段、当ブログをよく見ていただいているいわしまん(@iwasiman) さん

  • Webエンジニア勉強会#11で登壇もされていたみずりゅ(@MzRyuKa)さん

  • SIerからWeb系に転職され、過去にこの転職LTに登壇もされたねっしー(@yuuri_oo00)さん

  • Podcast「成し遂げたいam」をやっている、なべくら(@nabe__kurage)さん、KANE(@higuyume)さん

  • 最近、しがないラジオに出演もされた、なおと(@naoto_7713)さん

主催者のVTRyo(@3s_hv)さん、はっせー(@Dear_you_cry)さん、設営に携わられた方々、登壇者の方々、スポンサー企業の各社さん、ありがとうございました！

SOFT SKILLS　ソフトウェア開発者の人生マニュアル

SOFT SKILLS　ソフトウェア開発者の人生マニュアル

*1:Webエンジニア勉強会#11の参加レポート

*2:実務未経験からのWebエンジニア転職活動の記録

50代の銀行員がプログラミング(Python)を始めた話

Python キャリア 働き方

はじめに

先日、Pythonを始めた50歳銀行員の方についてツイートしたところ、多くの方からの反響がありました。

今回はこの銀行員の方について、少しだけ触れたいと思います。

目次

エピソード

この銀行員の方とは5, 6年前から仕事でのお付き合いがあります。

私は以前からこの方を尊敬していて、

  • 40歳を超えてから初めて社内のIT関連部署へ。配属当初、周囲や発注先のシステムエンジニアが話すシステム開発関連の用語が理解できなかった為、キャッチアップの為に情報処理技術者試験の高度資格であるプロジェクトマネージャを勉強して早々に取得。

  • 私が出会った当時40代半ばでしたが、若手顔負けのエネルギッシュさで、どんな未経験システムのプロジェクトに対してもその都度勉強しながら前向きに取り組む。

といった感じで、自分もこうありたいと思っていました。

私の転職活動を打ち明けたら

その後、私はPythonを学んだことをきっかけに約2ヶ月強に渡るWebエンジニア転職活動を行ったのですが、なんとか内定が出始めて活動終了が見えてきたころ、普段お世話になっているこの銀行員の方に転職活動の話を打ち明けたところ、なんとこの方も冒頭のツイートの通り3ヶ月前からPythonの学習を始めていたのでした。

非常に驚きましたし、お互いがPythonやっていることがわかると、そこからはPythonの話題で大盛り上がりになりました。

Djangoに関しては私の方が先行していましたが、Anaconda, JupyterNotebook, NumPy, Pandasあたりの話は私は頷くことしかできませんでした。

twitterや勉強会などを除けば、リアルな生活の中では私はPythonの勉強をある種孤独に続けてきた為、こんな身近に仲間がいるのであれば早く知りたかったー、と思いました。

ちなみにその方、AI・機械学習のオンライン学習コースを社内で受講できるようになり志望したところ、人気が高く若手が優先されて受講できなかった為、個人で申し込んで最速で修了させたそうです。凄い。

今後について

私が転職することによって、その方と仕事上の繋がりは無くなってしまうのですが、今後も連絡を取ってPythonの勉強会などに一緒に参加していきたいと思います。

その方は、Pythonスタートブックという辻 真吾さんの著書からPythonの勉強を始めたそうなので、辻さんが登壇されることもある勉強会にお誘いできたらと思います。

最後に

プログラミングを学んで*1Webエンジニアにキャリアチェンジ*2するという今回の私の決断について、この方はエールを送ってくださいました。

この方も、このまま機械学習を中心にPythonを学び続けたら、データサイエンス方面に転向してもおかしくないのではないかと私は思っています。

「少なくとも70歳までは働くだろうし人生100年なのだから、いつまでも学びを続けよう！」という志を共有して、今後も切磋琢磨していきたいと思います。

Pythonスタートブック［増補改訂版］

Pythonスタートブック［増補改訂版］

*1:働きながらプログラミングをゼロから学んで半年でWebサービスを作るまでの記録

*2:実務未経験からのWebエンジニア転職活動の記録