tewi_log

受託 / SES で Web アプリやモバイルアプリをフルスタックで開発しています

Mint60 を組み立てました

mint-60

キーボードはいままで「HHKB Studio」や「KeyChron K8 Pro」のような既製品を利用していましたが、姿勢改善のために左右分割キーボードを導入したいと考えていました。

自作キーボードに入門するにあたり、どのようなキーボードがあるのかを見てみたいという思いで、2/8に開催された 天下一キーボードわいわい会 Vol.10 に参加したのですが、自作キーボードの入門として名前をよく目にする Mint60 が組み立て工具以外がすべて同梱された福袋として売られていたため、今回はこちらを購入させて頂きました。

組み立て

Mint60の組み立て手順１ – Lilakey

組み立て手順通りで問題なく進めることができましたが、1点注意点として、「6. キースイッチ実装」時の画像には基盤にピンヘッダが実装されていますが、コンスル―ピンヘッダを使用するため、ピンヘッダの実装は必要ありません。文中には補足がありますが、迷ったため注意が必要です。

手順にはありませんがノイズ軽減のためにスタビライザーにグリスを塗りました。

Amazon.co.jp: キーボード 10g GPL 205G0を備えたキーボード潤滑油キット、および10個の使い捨て潤滑油ブラシ、キースイッチおよびプレート取り付けスタビライザー用のスイッチ潤滑油、メカニカルキーボード用のユニバーサルキーボード潤滑剤 : 産業・研究開発用品

自作キーボードの「スタビライザー」

今回のキットにはいくつかのキースイッチが同梱されていたため、打鍵感を比べてみたかったこともあり一部のキーは別々のスイッチを実装しました。

keyswitch

キースイッチを基板に嵌めるとき、スイッチによっては挿しにくいものがあるため、はんだ付け前に横から見てしっかりとささっているか確認した方が良いです。

私は社用PCと私用PCを頻繁に挿し変える都合上、抜き挿しによる ProMicro の破損を防ぐため、L字の短いケーブルを間に常時接続して運用することにしました。

Amazon.co.jp: ELECOM OTGケーブル 逆L字 microB-Aメス-USB2.0 ブラック 0.1m TB-MAEMCBR010BK : パソコン・周辺機器

キーマップ

Mint60キーアサインの変更方法（Remap使用） – Lilakey

Remap は記事内に貼られている最新バージョンでは警告メッセージが出たため、 QMK 0.18.17 バージョンを利用する必要がありました。

keymap1 keymap2

キー配列はこのようにしており、ベースは JIS配列ですが、Esc を左下に Enter を親指で押せる位置に配置、なるべくホームポジションから離れずに操作できるようにしています。 Fn キー押下時は hjkl でカーソル移動ができるようにしています。

使用感

初めての分割キーボードでしたが、肩を広げた形で打鍵できるため負担が軽くなったと思います。

今後はマウス操作もホームポジションから離れずに行いたいため、 Nape Pro のようなトラックボールデバイスを別途導入するか、KeyBall 系のトラックボール付きの分割キーボードを検討しています。

Blender ファイルのバージョン管理 (Git / SVN) 容量効率検証

本記事は misskey.dev ユーザー Advent Calendar 2025 14日目の記事です。（大遅刻） misskey.dev ユーザー Advent Calendar 2025 - Adventar

はじめに

最近、趣味として Blender で 3Dモデリングを触ることがあるのですが、3Dモデリングの作業には取り返しのつかない操作があるため、バージョン管理がしたいと思うようになりました。

業務では主に Git を使用していますが、ドキュメントなどのバイナリファイルを扱うと、リポジトリ容量がどんどん肥大化していってしまうという経験があります。
バイナリファイルの取り扱いには SVN の方が向いているという話を目にすることが多いので、SVN と Git での容量の違いについて調べてみました。

  • 想定する使い方
    • 個人での履歴管理を目的とする
    • .blend ファイルや画像ファイルなどのバイナリファイルを管理する
  • 想定しない使い方
    • チームなど複数人で利用する
    • リモートリポジトリを外部に公開する
    • 複数のブランチを使用した運用

Git と SVN の基本的な違い

Git と SVN の最も大きな違いは、分散型と集中型というアーキテクチャの違いです。

Git

分散型バージョン管理システム

SVN

集中型バージョン管理システム

SVN はローカルリポジトリがないため、Git に比べてシンプルな構成になります。

検証

Blender で少しずつ変更を加えていき、バージョンごとに容量を計測していきます。

環境

ファイルリネーム

保存時にファイル名を変更して保存する方法です。
フォルダ構成は以下。

work/
├── 001.blend
├── 002.blend
├── 003.blend
└── 004.blend

総容量はファイル容量の合計

Git

リモートリポジトリは考慮せず、ローカルのみで計測します。
フォルダ構成は以下。

work/
├── .git
└── 001.blend
git init
git add 001.blend
git commit -m "first commit"

# 001.blend 更新
git add 001.blend
git commit -m "2"

総容量は 001.blend ファイルと .git フォルダの合計。

SVN

フォルダ構成は以下。

path/to/repos/project/ # リポジトリ
~~~
work/
├── .svn/
└── 001.blend
# リポジトリを作成
mkdir /path/to/repos/project
svnadmin create /path/to/repos/project

# 作業ディレクトリ
mkdir work
svn co file:///path/to/repos/project work

cd work

svn add 001.blend
svn commit -m "first commit"

# 001.blend を更新
svn commit -m "2"

総容量は 001.blend と .svn の合計と、 リポジトリ repos/project の容量を計測

結果

バージョン リネーム Git SVN(ローカル) SVN(リポジトリ)
1 932,388 1,091,349 1,987,662 230,571
2 1,919,692 1,298,750 3,029,882 360,915
3 2,961,696 1,524,975 4,126,586 442,528
4 4,058,400 1,770,207 5,277,990 496,555

最終的なファイルリネームに対する割合は以下。

Git SVN(ローカル) SVN(ローカル + リポジトリ)
0.436 1.291 1.423

SVN のリポジトリの容量を除いても、Git で管理した方が容量効率が良いという結果になりました。
検証前は SVN の方が効率よく管理ができるイメージであったため、想定外の結果となりました。

差分が取りにくいファイルでも試す

差分圧縮が効きにくいファイルの場合どうなるのか調べるため、暗号化 Zip で調べてみました。

バージョン リネーム Git SVN
1 1,048,938 2,125,149 3,326,603
2 2,097,881 3,174,921 5,425,427
3 3,146,821 4,224,692 7,524,288
4 4,195,761 5,274,465 9,623,111
5 5,244,701 6,324,237 11,721,934
6 6,293,641 7,374,007 13,820,757
7 7,342,581 8,423,778 15,919,623
8 8,391,521 9,473,548 18,018,445
9 9,440,461 10,523,320 20,117,268
10 10,489,401 11,573,095 22,216,175

差分圧縮が効かず、ほぼファイル分の容量がそのまま蓄積される結果となりました。

結論

今回の検証から以下のことが分かりました。

  • バイナリファイルであっても、ファイルの性質によって圧縮効率は変わる
    • Blender ファイルは Git でも効率的に差分管理できた
    • 暗号化ファイルは差分圧縮が全く効かない
  • SVN を使ったからといって、必ずしも効率的にバイナリファイルを管理できるわけではない
    • 今回のケースでは Git の方が容量効率が良かった
    • SVN はリポジトリとワーキングコピーの両方で容量を消費する
  • 個人でのローカル利用においては Git が有効

この結果を踏まえ、Blender での作業には Git を用いてバージョン管理を行おうと思います。

受託開発で働いて6年経ちました

振り返り 受託 SES

はじめに

2019年8月に受託開発企業に転職してプログラマとしての働き始めてから6年が経ちました。 いろいろと状況が変わってしまったので、この機会にこれまでの振り返りをしてみます。

転職が決定した時点のエントリーはこちらです。 tewir.hatenablog.com

入社した当初は「ついていけなくなるんじゃないか」、「仕事としてやり続けたら興味が無くなるんじゃないか」という不安がありましたが、コードを書くことは今も変わらず楽しいです。

会社について

入社当初は最大50人ほどの規模でしたが、現在は10人ほどに縮小しています。

入社当初は社内のコミュニケーションがほとんどなく、業務も1〜2名の少人数チームで進めることが多い環境でした。その後、懇親会や勉強会などのイベントを定期的に実施するようになり徐々に交流が生まれています。

働き方について

  • 入社直後（2019年〜）: 入社してすぐにフルリモートで働き始めました。 週1回程度、客先に常駐する案件もありましたが、基本的にはリモート中心の働き方でした。
  • コロナ禍（2020年〜2022年頃）: 客先常駐の案件もなくなり、完全にフルリモートでの勤務となりました。
  • 現在: コロナ禍が落ち着き、出社を求める案件が増えているようです。現在は完全出社で勤務をしています。

携わったプロジェクト

この6年間で、主にWebサービスの開発に携わってきました。途中1年ほどはモバイルアプリの開発も経験しました。

業務範囲としては、基本的にフルスタックで、フロントエンドからバックエンド、さらにはサーバーの環境構築まで一通りを担当してきました。案件の内容は新規開発と既存システムの保守運用がおおよそ半々の割合でした。

入社から2〜3年目までは比較的小規模な案件を数多く手がけ、短期間で様々な技術や業務領域に触れることで経験値を積んでいきました。4年目以降は、より規模の大きな長期プロジェクトに携わるようになりました。

最近では特に、古くなった VB や Windows Form で作られた業務用アプリケーションを、Webシステムへと更改する案件に携わることが多くなっています。これらのプロジェクトでは、既存システムの仕様を理解し、新しい技術スタックで再構築するという、技術的にも業務的にも挑戦的な内容に取り組んでいます。

使用した技術

上から順に使用した時間が長いです。

社内の技術スタックが PHP に偏っているため、PHP 系の案件が多かったです、また愛知県は自動車業界が盛んなため、その影響で C# と Java の需要が高い印象があります。

また受託開発では、理想的な技術選定ができない場面に多く直面します。

新規案件であっても、VB や Windows Form で業務アプリケーションを開発していた会社が元請けとなる場合、Webアプリケーション開発における技術スタックを十分に持っていないケースがあります。

例えば、開発効率や保守性を考慮して TypeScript や Vue.js を提案したくても、「そもそも npm が何かわからない」と言われてしまい、JavaScript (jQuery) での開発になることがあります。同様に、ユニットテストの導入を提案しても、工数やコストの観点から見送られるケースが頻繁にあります。

先方の納得を得られる範囲でできる限りの提案を行ったり、保守性の高いコードを書くようルール決めを行うことが肝です。

学習・技術習得について

基本的には現場で働きながら技術を習得してきました。 未経験で入社した直後、Ruby on Railsで構築された Webサービスの保守運用に一人で配属されましたが、当時は経験不足からクソでか PR を作成してしまったり、jQuery を使って実装してしまって、レビュワーの方に渋い顔をされたりと失敗を重ねてしまいました。

向こうからしてみれば、「何故雇っている人に教えなければならないのか」という不満もあったと思うので申し訳ない気持ちがあります。

入社から数年後には、社内でも勉強会が定期的に開催されるようになり、技術的な知識を共有する文化が醸成されていきました。

資格について

会社で資格取得に関する評価制度が導入されたため、年1回のペースで資格を取得してきました。

資格の必要性については議論が分かれるところですが、体系的な知識を効率的に習得できるという点で有用だと考えています。実務で断片的に覚えた知識をより広い文脈で理解し直すきっかけにもなりました。

書籍

最近は完全出社のため通勤時間に本を読んでいることが多いです。
以下は最近読んだ/読んでいる本です。

  • Software Design
    • 気になる号やトピックをつまみ食いして読んでいます。

Software Design (ソフトウェアデザイン) 2025年10月号 [雑誌]

Software Design (ソフトウェアデザイン) 2025年10月号 [雑誌]

Amazon

  • SOFT SKILLS　ソフトウェア開発者の人生マニュアル
    • 技術書というより開発者生きていくために必要なことを、仕事以外にも体づくりとか不動産取引など様々なトピックで書かれている変わった一冊です。

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

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

Amazon

  • ソフトウェア開発現場の「失敗」集めてみた。 42の失敗事例で学ぶチーム開発のうまい進めかた
    • 企画からリリース後まで、物語形式で失敗事例が書かれています。

ソフトウェア開発現場の「失敗」集めてみた。 42の失敗事例で学ぶチーム開発のうまい進めかた

ソフトウェア開発現場の「失敗」集めてみた。 42の失敗事例で学ぶチーム開発のうまい進めかた

Amazon

  • バックエンドエンジニアのためのインフラ・クラウド大全
    • インフラに触れる機会が限られるため、知識の補強を目的として読んでいます。

バックエンドエンジニアのためのインフラ・クラウド大全【リフロー型】

バックエンドエンジニアのためのインフラ・クラウド大全【リフロー型】

Amazon

心がけていること・気をつけていること

プロダクトへの責任感

単に言われたことをこなすだけでなく、より良いプロダクトになるよう積極的に提案を行うことを心がけています。私は、すべてのプロダクトはユーザーのためにあると考えており、この視点を常に持ち続けることが重要だと感じています。

「政治」への対処

複数の会社が関わるプロジェクトでは、会社間の「政治」が存在する場合があります。情報の統制や管理区分が分けられていることが多く、意図せず越権行為をしてしまうリスクがあります。このような案件では、事前に十分な情報収集を行い、避けるべき領域や配慮すべき関係性を把握することが重要です。

技術選定における配慮

技術選定では、自分一人で判断すると新しい技術を取り入れたくなりがちですが、以下の点を常に考慮するようにしています。

  • 他のメンバーがメンテナンスできること
  • 自分が触りたいだけの技術ではなく、要件に適した選択であること

成果の可視化

自身の貢献を適切に評価してもらうために、成果が見える位置に記録を残すことは重要です。

  • 他のメンバーが閲覧できる場所に日報を残すことで、進捗やタスクを透明化する
  • DM でのやり取りを避けること

DM での仕事を振られることを許容していると、PM などから進捗状況が見えず、適切な評価を受けられない場合があります。

受託開発で働くことについて

この6年間の経験を通じて、受託開発という働き方のメリット・デメリットを実感してきました。

メリット

業界や規模の異なる様々なプロジェクトに携わることで、幅広い業務知識とシステム要件を学ぶことができました。
また、案件ごとに異なる技術スタックが求められるため、自然と多くの技術に触れる機会があり、技術的な引き出しを増やすことができました。

デメリット

自社開発と比較すると、どうしてもプロダクトに対する熱意や愛着を持ちにくい面があります。短期間で次の案件に移ることも多く、長期的な改善や成長を見届けることが難しいのが現実です。

さいごに

入社してから1年ほどの時に振り返り記事を書いたのですが、下書きのまま公開していませんでした。 投稿し忘れたのか、思うところがあって非公開にしたのか、記憶が曖昧です。

これまでの経験を活かし、今後はできることの幅をさらに広げていきたいと考えています。特に、技術選定の段階から主体的に関わり、プロジェクト全体のアーキテクチャ設計や技術的な意思決定に携われるようになることが目標です。 受託開発の制約の中でも、より良いプロダクトづくりに貢献できるエンジニアとして成長していきたいと思います。

Windows アプリ 「Groupy」 の再インストール方法

以前「Groupy」というウィンドウをタブ化することができる Windows アプリを Steam で購入した。

www.stardock.com

エクスプローラーをタブ化したり、Unity と SourceTree をグループ化して交互に切り替えたりできて便利だったのだが、設定をいじっていたらバグってしまい、正常に動作しなくなってしまった。

普通に起動して設定画面も出るがタブ化機能が一切動作しないという症状で、何回か再インストールを試してみたりしたが治らなかったので放置していた。

最近改めて調べたところ、公式フォーラムで見つけた再インストール手順で無事使えるようになったので、備忘録として残しておく。

手順

  1. 公式フォーラムからの Purging Tool をインストールする。

    https://forums.stardock.com/488142/groupy-support-faq#reinstalling

  2. バッチファイルを管理者権限で実行する。

  3. Steam でアンインストールする。

  4. PC を再起動する。

  5. Steam でインストールする。

Windowsでの開発環境について

Windows 開発環境

8月からエンジニアとして働いている（@tewi_r）です。
基本的にリモートワークで、自宅の4Kモニタに支給PC（Windows10 Home）を接続して業務を行っています。
初めてWindowsで開発を行うに当たり、導入したソフトウェアを書いていきます。

ユーティリティ系

Wox

www.wox.one

macOSのAlfredライクなランチャー。
似たようなモノとしてHainもある。（開発が終了してる？）

Station

getstation.com

主要なWebアプリケーションを1カ所にまとめることが出来るアプリケーション。
少し前のアップデートで対応していないアプリケーションも自分で追加出来るようになりました。
現在は以下のアプリを管理してます。

Chrome拡張（後述）を使用したかったのでTrelloはChromeで見ています。

thilmera 7

www.thilmera.com

リソースモニタ。
4K表示にも対応していてくれて嬉しい。

ChangeKey & AutoHotKey

forest.watch.impress.co.jp

www.autohotkey.com

キーバインドをMac風に変更する為に使用。
詳しい設定は後日書きます。

タスク管理系

Trello

trello.com

プロジェクト管理にTrelloを使い始めました。
次のアプリ/拡張を使用しています。

Pomello - Stay focused. Accomplish more.

Trelloにポモドーロタイマーを追加してくれるアプリケーション。

Elegantt : Awesome Gantt charts for Trello

Trelloにガントチャートを追加してくれるChorme拡張。

開発系

Git for Windows

gitforwindows.org

これがないと始まらない。
インストール時は改行コードを変更しないように設定すること。
（デフォルトだとLF -> CR+LFへの変更が行われる）

Vagrant ( + VirtualBox)

www.vagrantup.com www.virtualbox.org

Hyper-Vが使えないためVagrantを使用。
Ubuntu18.04をインストールし開発環境を構築しています。

構築時に色々詰まりました。

RLogin (ターミナル)

nanno.dip.jp
多機能で色々いじれるので使い勝手が良いです。
フォントの設定が分かりにくかった。

（参考：RLogin のフォント設定まとめ - 余白の書きなぐり）

CmderやConEmuといったコンソールエミュレータもあり、これはコマンドプロンプトやPowerShellをタブ表示できるので便利なのですが、Powerlineフォントが正しく表示されなかったのでRLoginを使っています。

Visual Studio Code

code.visualstudio.com Ubuntuの開発環境にはRemote Developmentでアクセスしています。

Zeal

zealdocs.org

オフラインドキュメントアプリ。
macOSアプリのDashにインスパイアされたらしいですが、殆どDashそのまんまです。

A5:SQL Mk-2

a5m2.mmatsubara.com SQLクライアント。使いやすい。

WinSCP

forest.watch.impress.co.jp

FTPクラインアント

参考

おわりに

macOSと比べると、改行コードや日本語ユーザー名ファイル権限あたりが原因で良くトラブルが起きるのでしんどいです。

Windowsでの開発経験は殆どないので「こういうの便利だよ！」っていうのあれば教えて頂けると嬉しいです。

WindowsでのDocker環境の構築について

Docker Windows

8月から受託開発企業で Web エンジニアとして働いています。
それに伴い開発環境がmacOSからWindowsになり、四苦八苦しながら開発をしています。

今回Dockerを導入するにあたって色々と詰まったので書きます。

環境

結論

Vagrant上のUbuntu 18.04にインストールしました。

試した方法

1. Docker Desktop for Windows (旧 Docker for Windows)

Get started with Docker for Windows | Docker Documentation

Hyper-Vが必要なため、Homeエディションでは使えませんでした。

  • System Requirements:
    • Windows 10 64bit: Pro, Enterprise or Education (Build 15063 or later).
    • Virtualization is enabled in BIOS. Typically, virtualization is enabled by default. This is different from having Hyper-V enabled. For more detail see Virtualization must be enabled in Troubleshooting.
    • CPU SLAT-capable feature.
    • At least 4GB of RAM.

引用元 : Install Docker Desktop for Windows | Docker Documentation

2. Docker Toolbox on Windows

Install Docker Toolbox on Windows | Docker Documentation

1の方法が使えない時に使う方法です。

docker、docker-composeコマンドともに動作はしましたが、docker-compose up時にvolumesで指定したフォルダがマウントされない問題が発生しました。

結局原因は分からず、エラーも出ないため手詰まりでした。

3. WSLにDockerをインストールする

docker-composeが動きませんでした。

WSL2では動くそうです。
参考 : wsl2でdocker-composeの風を感じてみる - 無気力生活 (ノ ´ω｀)ノ ~゜

Dockerインストール時には以下の点に注意しないと動きません。

4. Vagrant (Ubuntu 18.04)にインストールする

PCのユーザー名が日本語だったためインストールで手間取ったり、一度作成したVMが消滅しかけたりしましたが、現在は問題無く動いています。

vagrant up時に以前作ったVMが読み込まれない時の対処法（Windows） - Qiita

VSCodeのRemote Developmentを使って開発しています。

おわりに

Docker Desktop for Windowsを使いたかった。
WSLの登場でWindowsでの開発は楽になると思っていたので残念。
SSDをまっさらにしてArch Linuxを入れたい。

大手通信企業を退職し、web系受託企業へ転職します

転職

2月に前職の大手通信企業を退職してから、およそ5ヶ月が経ちました。

長かった無職期間を終え、8月からweb系受託企業で働くことになりましたので、
転職活動の振り返りを書いていこうと思います。

概要

  • 勤務地は中部地区 or 関西地区
  • 前職ではSE（上流工程業務）を経験
  • いわゆる未経験からのweb系企業への転職
    • フロントエンド or バックエンド
    • 自社サービス/受託開発は問わない
  • 裁量大きく様々なスキルが身につけられる業務を希望

転職理由

  • コードを書くエンジニアとしてのキャリアにチャレンジしたかった
  • 技術が好きでIT業界を志望したが、前職ではどんどん技術から離れていってしまう
  • IT業界の人材不足がいつまでも続くとは思えず、早い段階で動かなければ一生このままだと思った

前職の不満点などは大きな理由ではないです。

大手特有のしがらみや古臭さは嫌いでしたが、その代わり福利厚生や手厚い研修などがあり、鈍重ながら会社を変えていこうという動きもあり、総合的には非常に良い企業だったと思います。

タイムライン

  • 11月：転職活動開始（エージェント登録）
  • 1月：応募開始
  • 2月：前職を退職
  • 3月：スキルの棚卸し、過去実績の整理など
  • 4月：Webアプリケーションの学習
  • 5月：ポートフォリオの作成 / 作り直し
  • 6月：応募開始
  • 7月：内定

スキル

  • 大学での研究活動（3年）
    • C++ / OpenGL / GLFW / PointCloudLibrary / Intel RealSense / Blender
    • 研究室でロボットのCG描画プログラムを開発
  • 前職（11ヶ月）
    • TCP/IPの基礎知識
    • ネットワーク構築の基礎知識
  • 独学（3ヶ月）

結果

フェーズ 件数
書類落ち/経験不足 8
応募後反応なし 5
面接落ち 4
選考辞退 2
内定 2
合計 21

都内と比べて圧倒的に求人が少ないため苦労しました。
いくつか気になる企業からもスカウトが来ていたのですがほとんど東京の企業でした。
最終的に内定を頂いた企業の内、条件や業務内容が合致する企業を選びました。

転職サービスについて

サービス名 件数
Wantedly 11
Paiza EN:TRY 2
転職エージェント 7
その他 3

Wantedly

「話を聞きに行きたい」ボタンを押すだけで簡単にエントリーをする事が出来ます。

ただし返信が無いことが殆どで、エントリーから返事が来るまで数週間掛かることもあり日程調整に苦労しました。

面談をして頂ける場合、事前に制作物やブログを事前に目を通して頂いていることが多く、ポートフォリオに対するフィードバックなども頂けたので非常に嬉しかったです。

Paiza EN:TRY

未経験からのエンジニア転職サイトです。

ランクに応じて応募できる案件が決まっており、応募できる場合そのまま面談までほぼ確定で進めるので楽です。

企業とのやりとりや日程調整などもやって頂けるので大変ありがたいです。

転職エージェント

大手とIT業界特化の二つのエージェントを利用していました。

大手エージェントはポートフォリオもなかった時期に、転職相談も兼ねて登録しました。

最初の面談で有名web企業の求人をいくつか持ってきて、「とにかく応募してみるのが大事です」と言われたので応募してみましたが、案の定全部書類で落ちました。
以降の求人はSIerばかりで、試しに一つだけ面接に行きましたが業務内容に魅力を感じなかったので辞退しました。

大手は案件自体は多いですが、殆どがSIerや派遣で、ノイズ（飲食店の店長候補等）が混じっている上、同じ企業が何回も出てくるので次第に見なくなりました。

もう一つのエージェントは私が未経験であったことと、サービスが持っている求人が殆ど都内であった合ったことから、数社しか紹介して頂けませんでした。また、サービスの質としては大手の方が良かったです。 メール返ってこないし。

ポートフォリオについて

ポートフォリオの作成はほぼ必須だと思いますが、ただ作るだけでは無くGitHubの使い方なども意識するようにした方が良いです。

ポートフォリオ自体の質もそうですが、コミットの粒度やプレフィックス、ブランチの切り方など、どれだけ実業務を意識して運用しているかという部分を見られます。
言語は使い慣れているものを使用すれば良いと思います。

また作成するにあたっての「思い」や「目的」があった方が、受けが良いですし作成のモチベーションも保ちやすいと思います。

履歴書 / 職務経歴書について

履歴書

履歴書は事実を書くだけなので特に考えることはないです。
私は履歴書メーカーを使用して作成しました。

職務経歴書

書類選考やその後の面接で重要になるのが職務経歴書です。

面接は職務経歴書かWantedlyのプロフィールを見ながら行われることが殆どでした。
私の場合職務経歴が殆どないため、自己PR欄にアルバイトやポートフォリオについて書けるだけ書きました。

Wantedlyのスキル欄に「Paiza Aランク」と書いておいたのですが、「Aランクあれば比較的すぐに業務についてこられるようになると思う」という評価も頂いたので書いておいて良かったと思います。

面接について

カジュアル面談ではメモをPCで取っていました。
前職ではメモは基本的に紙で取っていたのですが、PCの方が書きやすい上、成果物をその場で見せられるという利点もあるので途中でPCに切り替えました。
「PCでメモを取ってもよろしいでしょうか？」と聞いて、断られたことは無かったです。

「カジュアル面談」は企業によって捉え方が違い、会社説明とほぼ同義の場合もあれば、がっつり採用面接の体をなしているものもありました。

それに伴い選考フローもまちまちなので、早い段階で確認しておいた方がスケジュールを組みやすいです。

具体的には以下の様な選考フローがありました。

  • 「カジュアル面談」-> 内定
  • 「カジュアル面談」=「一次面談」 -> 「二次・三次面談」-> 内定
  • 「カジュアル面談」=「会社説明」 -> 「書類選考」->「一次面談」-> 「二次・三次面談」-> 内定

通常の採用面接では、もともとあがり症であったこともあり、うまく情報を伝え切れなかった部分が多かったような気がします。
ポートフォリオ作成も重要ですが、私の場合、面接対策に比重を置くべきだったかもしれません。

最後に

新卒で間違えたのでずいぶんと時間が掛かってしまいましたが、ようやくエンジニアとしてのキャリアをスタートすることが出来ます。

今回の転職活動では新卒時代の流れ作業とは違い、様々な社風や雇用形態があり面白かったです。いますぐ転職するつもりでない方も、視野を広げるために転職活動をしてみるのはありかもしれません。

求人数や勉強会の数などが圧倒的に違うため、可能であれば都内での就職を考えた方が良いです。