おじんブログ

Webアプリに関する知見とか雑記です

退職してフリーランスエンジニアになるためにやった役所手続き

お断り

これは自分がフリーランスエンジニア(個人事業主)として開業するために行った役所の手続きの記録です。案件の獲得のノウハウはありません。

概ねの場合、これで充分だと思いますが、不安なら市役所の窓口に聞けばだいたい教えてくれます。そこで確認してください。

覚えるのが苦手な人は「退職後2週間以内にやらなきゃいけない手続きがある」と覚えてください。

やったこと

最低限やる必要があるもの

  • 退職直前まで在籍していた会社へ退職証明書発行を依頼 (年金、保険の手続きで使います)
  • 役所で国民健康保険への切り替え (退職してから2周間以内)
  • 役所で国民年金への切り替え (退職してから2周間以内)
  • 開業届を税務署に提出 (実際に仕事するまでに出す必要あり、それより早くてもいい)
    • マイナンバーカードがある場合は電子で申請できます
  • 確定申告 (2月~3月にやるもの、そのための準備を日頃からする)

必須ではないがやっておくと良いもの

  • 仕事用のメールアカウント取得 (Gmail でいいです)
  • 仕事用の口座開設 (ネット銀行で確認できる方がいい)
  • マイナンバーカードの取得
    • 自己証明で使えるため。運転免許証がある人はそちらでもいいです。

やったことの解説

前提

自分はこういう書類や手続きに関してはかなり面倒くさいと感じている方なので、省力化できるなら省力化する方針です。

うっかりミスも多いほうなので、便利なシステムがあるならガンガン利用します。

仕事用のメールアカウントの準備

まずは個人用のメールアカウントと仕事用のメールアカウントは分けましょう。 個人用のメールに埋もれて仕事用のメールを見逃す可能性があります。

また、仕事中にTwitterやYoutubeをうっかり開いて集中できなくなったり、機密情報をSNSにお漏らしするリスクを減らすためです。

メールアカウントはGmailでいいです。寧ろ、Google Meetで商談することも多いため、Gmailアカウントの方がスムーズです。

お金があるなら独自ドメインを発行するのもありですが、ドメイン費用を払い忘れて失効したりとか、独自ドメインでGmailを使うためにGoogle Workspaceのプランに加入するとかでお金がかかるのでGmailで充分です。

開業届を税務署に提出

開業届の書類は freee開業 で作成しました。必要な事項を入力すると、必要書類をPDF形式で出力するので、後は印刷して一部手書きと捺印して完成です。

マイナンバーカードを発行していれば freee 経由で電子申請できるそうなのですが、自分は発行していなかったので税務署に持ち込みしました。

結局後述する年金と保険の件で役所に行ったので、この点は別に気になりませんでした。

www.freee.co.jp

作成した書類は下記のようなジッパー付きのクリアケースに入れて持ち込みました。手続きするための書類を色々まとめる必要があるため、クリアファイルよりはこのような入れ物の方がいいです。

Amazon | コクヨ クラシカル ポーチ A4ケース クリア F-VBF230T | ペンケース | 文房具・オフィス用品

ちなみに開業届を出すと、失業給付金がもらえなくなるので、退職後に暫く休んでから開業したい人は気をつけてください。

厚生年金→国民年金&関東ITソフトウェア健康保険組合(ITS)→国民健康保険への切り替え

役所で手続きしました。この手続きは退職後2周間以内に行う必要があります。

特に保険は忘れると保険適用外で医療費を払うこともあるため、できれば退職した翌日に切り替えするのが望ましいです。

切り替えに必要な書類は地方自治体のWebサイトを参考にしてください。 自分の場合は自己証明の書類として運転免許証があるのでそれを使いました。

年金と国民健康保険の支払いはクレカ、口座引き落としに切り替えができるケースがあります。コンビニ支払いでも可能ですが、忘れると後が大変なのでこれも自動で決済されるようにします。

ITSですが国民健康保険に切り替えず、任意継続もできます。この場合は会社と折半して払っていた保険料を全額自分で払うようになります。

www.its-kenpo.or.jp

自分は2年後に再度手続きするのを忘れそうなのでさっさと切り替えました。

確定申告 & 仕事用の口座開設

来るべき確定申告の記録のためにfreee会計、仕事用の口座はfreeeとの連携のためPayPay銀行を利用しました。

確定申告は過去にやったことがあるのですが、怠い記憶しかありません。また個人事業主のため、収入や経費の記録するツールが必要です。

そこでfreeeを利用することにしました。元々仕事でfreeeを使っており、操作に慣れているためです。

また、開業届の作成をfreeeで作成したため、そのまま会計もエスカレーションした形です。

仕事用の口座はfreeeとの連携を考慮してPayPay銀行にしました。連携に関してはまだ会計を入力していないのでよくわかりませんが、運用してみて気が付いたらまた別のブログ記事として起こす予定です。

PayPay銀行開設の際に屋号を必須で求められていたのでとりあえず「エンジニア」を屋号にしました。

www.paypay-bank.co.jp

まとめ

軽いはずみでフリーランスになったとはいえ、こういう手続きに苦手な意識があって不安でした。しかし、やってみると情報がWebサイトに掲載されていたり、ツールがあるため難しくありませんでした。

来るべき確定申告についてですが、ぶっちゃけ開業や税制について理解があやふやなので、freee開業に登録して届いた開業ガイド読んで勉強します。

3年4ヶ月勤めた受託開発会社を退職して無職になりました

Hasta la vista, baby

退職エントリーです。 2022/07/31 をもって 3年4ヶ月勤めた受託開発の会社を退職しました。

こういう内容を長々書くのはいかがなものか、という意見もありますが、他の人の退職エントリーを読んでて自分も転職の意思が言語化された経由があるので、自分も書きます。

退職した理由は下記に続いています。

会社の事業の方向と自分がやりたいことが噛み合わないため

一番の退職理由です。

会社の方針として非IT系企業のDX支援事業に注力すると発表がありました。具体的はグループウェアの導入提案や補助になる想定で、コードを書いてソフトウェアを開発することから離れそうでした。

一方で、自分は趣味の時間でもコードをガリガリ書いたり、ライブラリをチェックしたりするのが好きです。コードを書いて、プロダクトを開発して、それを改善するサイクルが好きです。

物事の解決に対して、コードを書くという「手段」に拘るのはエンジニアとして不適格かもしれません。ただ自分はコードを書く工程が好きで、それが一番パフォーマンスが出せると思っています。

また、色んな会社のテックブログにて、新入社員が新機能や開発の改善をしました、などの発表をしていることを見かけます。会社に3年もいるのにまともにプロダクト開発ができていない自分からすると衝撃的で「こんな世界もあるんだ」という思いと同時に、歴だけ長くてまともに実務でコードを殆ど書いたことがない自分には、激しい焦燥感が募りました。嫉妬しました。

会社には、そういうチャンスは今後は残されていないか、あってもかなり少ないと思ったため、見切りをつけました。

仕事上の心労から離れるため

詳しいことは省きますが、仕事上の心労が去年あたりから無視できないレベルで酷くなりました。

平日では仕事終わりの時間になると急激に眠くなって残業が辛くなる、寝起きの時間が制御できず寝坊するなどの睡眠リズムの乱れがあったり、休日中も無気力感が強くずっと寝込んで、やっと動けるのが日曜日の午後、というのもありました。

食事をしているときや趣味を楽しんでいるときでもずっと仕事上の悩みが思い浮かんで、辛い気持ちがずっと晴れませんでした。

心療内科にも行こうとしたのですが、4ヶ月待ちと言われて通うのも断念しました。

仕事はずっと忙しく、休職するには診断書がないと言い出しにくかったため、結局無理に仕事を続けて更に悪化しました。

心身がもう限界近かったので、現在の仕事から離れることを決意しました。

受託開発ではなく、自社サービス会社で開発をしたい思いが強くなった

受託開発をしていて自分が辛いなと思ったのは「自分が開発している機能で喜んでいる人数が少ない」ということです。

受託開発の現場では直接のお客さんが居て、その人の要望通りに作ります。 ただ、中には「なんでこんな仕様なの?」「これは前提となる要望が間違っているんじゃないか?」といった無茶な注文もあります。 しかし自分が居た会社で開発するものは、使用者が数人規模であることが多く、断る要因も少なく、部分最適化のような場当たり的実装をやることがしばしばありました。

言われたままのものを作るための場当たり的な実装を何度かやっていて、「もっと汎用性を持った手段を作ってみたい」と要望を抱くことがあり、モチベーションが上がりませんでした。

そういった経験からどうせ手間をかけて開発するなら、実装するものに対して納得感をもって取り組みたいですし、部分最適化よりは広く存在している課題を共通化して汎用性をもたせた解決策を作ってみたいです。 ある程度の汎用性を持った機能を開発できる経験は、多くの人数が使っているソフトウェアの開発ではないと得られないと思っていて、自社サービスの会社にあるんじゃないかと思っています。

今後はどうするのか

8月以降はフリーランスエンジニアとして活躍する予定です。

フリーランスエンジニアには年齢要因で単価や求められる職種があり、30歳という年齢を考えると、バリバリに開発して経験を積んで単価を高めていくチャンスは、今後多く残されていないと感じています。

なので、1年ぐらいお試しでフリーランスをやって、良かったら数年続けて、その後に進路を考えてみたいです。

ただ、エージェントに登録して2ヶ月近く探してもらっても仕事が無いので、フリーランスを諦めるかもしれません。

最後に

8月以降の仕事が決まっていないので、8月は夏休みになりそうです。ちょっとしたバカンスで休みます。

開業届は出しますが、このまま全然フリーランスの仕事がなかったら普通に就職活動する予定です。

30 歳で受託開発会社を退職してフリーランスのエンジニアとして実務の開発経験を積もうとしている

概略

7 月末で 3 年間勤めた受託開発会社を辞めることにしました。

退職理由としては「実務上の開発経験がほとんど詰めず、雑用業務ばかりで、今後もそういうのに関われる可能性が低いため」です。

自分自身は Web 技術が好きで、特にフロントエンドの領域を独学していて面白いと思っているので業務でもそういうことに関わっていきたいと思っていたのですが、案件の運がなさすぎて今の会社ではそういう開発業務に殆ど関われませんでした。

そのため「経験年数の割に、開発経験がない」というのがコンプレックスになっていて、その上、自分のキャリア的には良くないと自覚していました。

そこで色々考えた結果としてフリーランスエンジニアとして転職しました。

退職後の選択としてフリーランスを選択した理由

Web フロントエンドポジションを志望しているのでそのポジションの求人がある会社に転職しようかと思っていたのですが、2 社連続で「開発経験積ませてあげる」と言われて入った会社で開発経験を積むことができなかったため、次に会社選びに失敗して実務の開発経験が積めない場合はキャリア的にも厳しくなります。

会社に所属する以上、「開発だけやってください」とは言い切れず、それとは異なる業務をやってもらう必要が出てくるので仕方ないです。ただ、自分の場合は開発の業務が少ないどころかほぼないため、かなり意欲的には落ち込んでいました。

そのため、事前の面談である程度業務内容を把握して、了承するか否かが選べて、あまりにダメなら案件から降りることができるメリットがあるフリーランスを選択しました。

フリーランスは契約が切れてしまうとその間無収入になるとか、単価交渉をするとか、デメリットもあるのですが、自分にとってはそのデメリットを補ってでも「実務の開発経験が積める」メリットを得たいと思っています。

何故実務の開発経験を求めるのか

趣味で Web 技術で遊ぶのが好きで、暇な時は技術情報サイトや GitHub や気になるライブラリのドキュメントを読んだり、それを元に実装したりするのが好きです。

ただ、実際の開発現場では「実務上で開発経験があるか」がかなり重視されます。これは求人票を見ても「実務の開発経験 3 年以上」というのを何度も見かけた体感からです。

また、フリーランスのエージェントさんとも話したのですが、趣味で学習してポートフォリオにして宣伝できるけど、実務で開発経験の方が強く評価される、ということも聞きました。

というわけで「実務経験を積むための実務経験がない」という悪循環を断ち切りたいために、実務経験を求めています。

退職後のあれこれ

7 月末で退職した後は、1 ヶ月程度休養を取る予定です。

退職を決意できたのも、GW で 10 日ぐらいボーッと現職から離れて正常判断ができたのが大きく、自分には休養が必要だと実感しました。

キャリア的に空白が開くのは良くないと思うのですが、現職で休職するか限界まで迷うぐらいに疲弊したのと、ここ最近の健康状態が全然良くないのでそれを治したいです。

休養後はフリーランスの案件を受注できるように、需要の高い技術や、自分の興味のある技術を独学しながらアウトプットしていきたいです。

サーバーサイドの勉強とか、逃げ続けている AWS/GCP や Rust などを、最低限できるようになりたいです。

余談

フリーランスになるにあたって、自分自身がフロントエンド開発経験積めればいいと思っていたので、あんまり単価を気にしていなかったのですが、現時点の単価予定額を周りに伝えたら「あまりにも安すぎる」「馬鹿すぎる」とボロクソ言われました。フリーランスになる前からフリーランスのことで怒られました。

15%OFFセールに釣られてアーロンチェアを買った

Mr_ozin with Aeron Chair

感想

まだ2日しか使っていませんが、ゲーミングチェアを使っていた時の「ある程度座っていると腰の疲れが溜まって休憩したくなる」というのが無くなって、疲れが溜まらず、ずっと座っていられます。

座面のフレームがガッチリしているため、座る時のポジショニングも迷わずスッと座れて直ぐに集中体制できます。

また、深く座ると背面のポスチャーフィットが当たって直立の姿勢がキープできます。

まとめると、「座り方を矯正されるが、疲れることなく姿勢をキープして集中できる」という感じです。

以下は買うまでの流れです。

筆者の情報

諸般の関係で質量の多い体型になっています。脚はかなり太めです。 がっちり体型の人が座るとどれが合うのか、という参考にしてください。

  • 身長 : 161.9cm
  • 体重 : 100kg
  • 用途 : プログラミング、ゲーム

買った経由

ハーマン・ミラーのゲーミングエディションがセールで15%OFFでした。ちょうどその時使っていたゲーミングチェアが合わないと思い始めた頃なので買いました。

※現在はセール終了しています。

https://jpgaming.hermanmiller.com/

試座したところ

とはいえ20万円を超える椅子を試し座りなしで買うのは抵抗があったのでショールームに行ってきました。

候補

  • ハーマン・ミラーの「アーロンチェア」
    • 候補の中では、一番座れる姿勢の幅が狭い、よく言えば雑に座ってもポジショニングが定まりやすい
    • ベストポジションが50だと、40~60ぐらいの余裕を感じるような作り
    • 暑がりなのでメッシュ素材が助かる
    • 腰椎のサポーターがあるおかげか背筋をシャキッとさせることができる
    • サイズはBが一番ちょうど良かった。Aだと狭く、Cだと座面がデカくて最低にしても脚がつかないです
  • ハーマン・ミラーの「エンボディチェア」
    • アーロンのような座面フレームの出っ張りがないので、脚が太い自分がガニ股で座っても問題なし
    • 背中が椅子の背面の全体で支えられているような構造なので、負荷が分散される感じ
    • メッシュ生地ではないが、サラサラとしていてさわり心地がいい。冬はヒヤッとしなさそう
    • アーロンのようにABCのサイズが無いが、座面は背面を細かく調整できるので問題なし
    • 下半身がかなりがっちりしている、太ももにものが当たるのが嫌、ガニ股になってしまう、ポジショニングに余裕を持ちたい人だとアーロンよりこちらのほうがいいと思います
    • 余談ですが、肘掛けが内側に湾曲しているのでお腹周りが大きい人だと調整中にあたります
  • オカムラの「コンテッサ2」
    • シンプルだけど懐が広く、ポジショニングに余裕があるのにさっと集中できる感じ
    • 座面にアーチがかかっているが、緩やかなので矯正される感じがなく座れる
    • アーロンのように色んなところが細かくチューニングできる、大体の人には合うと思います
    • 試座した段階だと疲れないので正直第一候補に近かった

選んだ結果

候補の中からスッとポジショニングが定まる「アーロンチェア」を選びました。「コンテッサ2」も買おうかと思いましたが、納期が30日以上かかるっぽくて、買いたい気持ちを熱い内に消化したかったでので断念しました。

「エンボディチェア」も「アーロンチェア」と同じぐらい快適だったため、だいぶ迷いましたが、暑がりなのでメッシュ生地を優先しました。

まとめ

高い椅子を買うと腰を労ることができる、というのはよく言われていますが、正しい姿勢が定まりやすくポジショニングを考えずに集中しやすくなる、という側面もあります。

20万円前後するので気楽に買えるものではありませんが、高い椅子は早く買って使うほど対費用効果が高くなるので、早めに手に入れることをお勧めします。

ゆめみ社のフロントエンドコーディング試験をやってみた

取り組んだものは下記です。

notion.yumemi.co.jp

応募する予定はありませんが、フロントエンドの素振りの課題としては面白そうと思って取り組んでみました。

やってみた感想として、適切に作ろうと思うと意外に設計に頭を使うのと、Unit Test の経験値がないことを突きつけられて面白かったです。 自分にはフロントエンドの実務経験が一切ないので、自分の中でバラバラに知見があった ESLint や Prettier、husky や GitHub Actions をアプリケーション開発の中で使用する、経験が得られてよかったです。

また、コミットやブランチの運用も採点対象になるそうなので、普段ものすごい雑にやっていたコミットやブランチ運用に緊張感を持って、他人が見ることを意識して取り組めました。

テストは 100％カバレッジを通そうとしましたが、モチベーションが尽きてしまったのでこれで終了です。

------------------|---------|----------|---------|---------|-------------------
File              | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
------------------|---------|----------|---------|---------|-------------------
All files         |   97.22 |    97.43 |   95.23 |   97.22 |
 src              |     100 |      100 |     100 |     100 |
  setup.ts        |     100 |      100 |     100 |     100 |
 src/components   |     100 |      100 |     100 |     100 |
  Chart.tsx       |     100 |      100 |     100 |     100 |
  Prefectures.tsx |     100 |      100 |     100 |     100 |
  Title.tsx       |     100 |      100 |     100 |     100 |
 src/lib          |   95.02 |    95.83 |     100 |   95.02 |
  client.ts       |     100 |      100 |     100 |     100 |
  constants.ts    |     100 |      100 |     100 |     100 |
  hooks.ts        |   84.84 |     92.3 |     100 |   84.84 | 21-24,45-46,49-52
 src/test         |     100 |      100 |      80 |     100 |
  utils.ts        |     100 |      100 |      80 |     100 |
------------------|---------|----------|---------|---------|-------------------

成果物

着手して 10 日ぐらい経っているが、実動は 24 時間 ( 3 日 ) ぐらい。本業が忙しかったり体調を崩してなかなか進めなかったのと、 Vitest の設定にちょっと苦戦したので思ったより時間がかかってしまった。

population-app-iota.vercel.app

リポジトリ

github.com

注意した点

dependencies を最小にする

  • 脆弱性を極限まで減らすため。また、依存関係をシンプルにして React の知識があれば誰でも読み解けるようにするため
  • 基本的に Web API、React の API だけ使って構築する。Redux も使わない
  • グラフは自作するのが大変なので recharts を使った
  • 最終的に 3 つのライブラリだけ dependencies になった

github.com

Linter と Formatter の設定

  • プロジェクトを作ったら 2 コミット目で設定完了するぐらいの勢いで早めにやっておいた
  • husky と lint-staged を使ってローカルで自動実行できるようにした
    • Unit Test と違ってこの辺りは実行環境に影響されないため
  • 手動実行を信じない、CI の Lint や Formatter で弾かれないようにした

Unit Test

  • テストと実装をセットで考えた
  • Jest に近い API の Vitest を使ってみた
  • 基本的にテストしやすい形で書くので、関数の責務を小さくする必要があった
    • 引数や返り値を適切に設計する必要があった
  • React をテストするのに @testing-library/* 系のテストライブラリの使い方を理解した

CI/CD の設定

  • CI は GitHub Actions で設定
  • 適切にキャッシュを使って実行サイクルを速く下
  • 各ステップ毎に name を振ってどこまで終わったかを分かりやすくした
  • 実行環境に左右されないように、Unit Test は CI で実行し、ローカルでは実行しない方針にした
    • Node.js ではあまり影響はないと思うが、実行環境を統一することでトラブルを減らした
  • CD は Vercel で設定
    • お金をかけたくなかったのと、設定が楽なので採用した。Pull Request にプレビューホスティングされるのありがたい
  • API キーを漏らさないために、ローカルでは .env.local を、CI/CD では環境変数から API キーを渡すようにした
    • アプリケーションを Chrome の開発コンソールの Network タブを見てしまうとバレてしまうが仕方ない

反省点

  • モックを適切に使ってカバレッジ 100％にしたかったが、できなかった。もっと簡単な例で素振りをする
  • Custom Hooks が汎用性のない、ロジックの切り出しになったため、再利用性が薄くなってしまった
    • 重複したところも多い。また、適度な抽象化を行いたい
  • Prop Drilling になってしまったため、素直に React.createContext() でコンテクストを使えばよかった
  • テストの書き方も Example を見つつ書いているが、どこまで書けばいいかわからなかった
    • ここら辺は実務経験がないことがネックになっていると感じる
    • とはいえこれはグループ毎に文化が分かれていそう

まとめ

テックリード職を前提として取り組んだが、フロントエンドのテックリードなら 1 つの JavaScript フレームワークに精通して、Unit Test のテストフレームワークの使い方や書き方を覚えていて当然とは感じた。

複数の JavaScript フレームワークを知っていることより、Linter、Formatter、Unit Test を CI 上に乗せて一連の流れを構築できる方が、開発する側としては大事だと改めて感じた。

個人的に TypeScript に関しては「型があるから JavaScript」より難しいとは思わず、寧ろ実行する前にエラーになる原因が明らかになる点で JavaScript よりは難易度が低いと思っている。

当初の目論見通り、JavaScript のフレームワークの素振りとしてはよかった。

個人だと、どうしても動けばいいレベルで、あまり複雑にならないためテストがおざなりになってしまうので、いい勉強になった。

2022 年度に習得＆復習したい Web 技術

誰向け?

  • 2022 年度内に Web フロントエンドポジションに転職したい自分の整理
    • エンジニアとして 4 年目だけど Web アプリの開発経験があんまりなくて詰みかけている
  • 友人
  • その他、Web フロントエンドのトレンドをざっくり追いたい人

それぞれの技術の詳細は書きませんが、ざっくり気になるポイントを書いてます。

情報源

どんなものが流行っているか、という肌感のチェックに使っている。

フレームワーク＆ライブラリ

React 18

  • 17 は特に大きな変更なしだったが、18 では色々な Hooks が追加されりしている
  • New Feature の項目を見ると使いこなすとパフォーマンスが上がりそうなので試してみる
  • Zenn とかでも解説記事が出回っているので書き方を探っていく

Next.js

  • 何度か個人的に作っているが、React で SG や SSR するならこれ
  • 全体的に Zero config でよしなにやってやる、という圧が相変わらず強い
  • 最近 next/jest Plugin ができたので試してみたい
  • 開発元の Vercel が Svelte や SWC の作者を雇用していたりと OSS の影響が今後も高そう

Svelte

  • ひとまずチュートリアルをやってみたが、極力責任範囲が少ない React よりは実開発向けに機能が考えられている感じ
  • Animation がビルトインされているのが面白い。CSS Animation を吐き出すようにしているにしている模様。
  • Redux や React.createContext っぽいグローバルステート管理もビルトインされている模様。
  • フレームワークの思想は面白いとはいえ癖がある上に採用事例もまだ少ないので日本で使う現場があるかというと微妙。

Prisma

  • Node.js 向け ORM だが、CLI の操作や Client がかなり使いやすい。TypeScript に優しい。
  • schema 定義ファイルに沿って DB を変更したり、現在の DB から schema 定義ファイルを生成することも可能らしい

ツール

Vite

  • フロントエンド開発ツールに No Bundle という風潮を呼び込んだ今一番熱いビルドツール
  • かなり軽量でサクサク動く。今後 SSR しない静的なフロントエンド作るならこれが第一候補になると思われる。
  • The State of JS でも注目度が高い模様。
  • 公式ドキュメントが日本語化されているのもありがたい。
  • Vite 本体だけでなく、Vite で実行するテストフレームワークの Vitest や Storybook の Vite 版みたいな Ladle も出始めているので熱そう。

esbuild

  • TypeScript で書いたスクリプトをサクッと実行するのに使っている。
  • フロントエンドの JS をビルドするのにも使えるらしいが、ちょっとまだできていない
  • 型チェックは tsc でやって実行はこれが主流になると思う
  • Vite 内部でも使われている。

Playwright

Lighthouse

  • ざっくり数字見ていい感じ、ぐらいにしか見てないのでちゃんと読める読めて改善するための指標にする
  • Lighthouse CI で CI に突っ込めるので試してみたい

インフラ＆その他

GitHub Actions

  • CI/CD のパイプラインを初期段階でシュッと作って開発体験を上げてテスト書く習慣を体に馴染ませたい
  • 他人が書いたパイプラインを読めるようにもしたい
  • CI/CD を前提とした開発をしないとどんどん手作業で複雑化する、というのを体感している

Firebase v9

  • v9 で結構 API が変わって TreeShake しやすくなったらしい
  • 業務で使うかは微妙だが、Firebase Auth 試したい試していとずっと思っていたので今年中に試す

AWS Amplify, Lambda, S3, Cloudfront

  • インフラが苦手なので、少なくともフロントエンド関係のサービスは触れるようにしたい
  • Serverless Framework でデプロイ作業をコード化できるのでそれも試す
  • サーバーレスアーキテクチャーと常時稼働のサーバーでどんなメリットデメリットがあるのかは言えるようにしたい

まとめ

自分が Web フロントエンドや自動テストの実務経験がほとんどなく、WordPress でゴニョゴニョして手動テストしたのがまともな実務上の開発経験なので、個人勉強である程度モダンな開発の経験値溜めておきたい。

プログラミング2021年振り返り

プログラミング勉強

全体

自分はフロントエンド得意だと思っていたのですが、「標準のHTMLのフォームでデータ送信するときってどんな感じでやり取りするんだっけ?」「mimeTypeやHeadersって知っているけどどういう仕組みだっけ?」「Web Workerって?シングルスレッドって?」「PWAってどういうものだっけ?」と基礎的なことで詰まっていたため、改めてMDNのHTTPのドキュメントを読んでサンプル書いて勉強していました。

developer.mozilla.org

ブラウザで使えるAPIについても目について面白そうなJavaScriptのAPIやCSSをCodesanboxで書いて試していました。 Codesandboxを使った理由として、WindowsやiPhoneなどの別環境での挙動確認だったりHTTPSでしか動かないAPIを試すために毎回デプロイするのは面倒なので書いてすぐ公開、Webブラウザ上(=閲覧環境)で編集できるためです。

JSのライブラリを使わず素のJSで書いて解決できるとありがたい場面は業務でも時々あるのでこういう素振りは役に立ちました。

developer.mozilla.org

codesandbox.io

アウトプットのリポジトリ

業務では経験できないことをちゃんと学習しようと思ってフロントエンドを中心にサンプルをザクザク作っていました。

github.com

Vite と Redux の学習のために作ったリポジトリ。 このあたりからViteを使い始めたのですが、既存プロジェクト以外はViteで開発するのが主力になるんじゃないかと思う程ビルドが高速でConfigも楽で快適だと思いました。

github.com

去年Next.jsで作った映画を公開順で閲覧するためのサイトですが、GitHub Actions で CI を回せるようにしました。 CI/CD に入門するためにGitHub Actionsを使いましたが、本当に無料でいいの?というぐらい機能が豊富で簡単です。 公式ドキュメントを読んでもいいし、テンプレートを選んでそこからカスタムしてもOK。

github.com

Next.jsのStatic Generateを学習するためにSpace XのAPIを使って作ったサイトです。 外部リンクからの画像最適化ってどうすればいいんだっけ?と頭を悩ませましたがVercelにデプロイする前提で解決しました。 Next.jsはReactベースのフレームワークで、ドキュメントに従って書けばなんでもよしなにやってくれてかなり便利な反面、ECMAScriptの挙動やTypeScript、ReactのHooksの書き方など、基礎的な箇所は意識して勉強しないといいコードにはなりませんね。

仕事

現在の会社に転職して2年8ヶ月経過しました。 転職前は2年半在籍していたのが最長だったので、今まで一番長い期間在籍しています。

前々からTwitterで呟いていたのですが、転職を考えています。

理由としては自分がフロントエンドが比較的得意なのですがそれを活かせる場面がなく、テストコードやCIもなく開発体制もかなり古いというのがずっと続いているためです。 自分である程度社内を改善しなきゃダメだと思って社内研修をするなど頑張っていましたが、あんまり改善できなかったのと、上司から評価されなくて、疲れて諦め気味です。

30歳になったのですが、まともな業務での開発経験がRedmineとWordPressのプラグイン、VBAぐらいしかありません。 そのため、実務でフロントエンドができていないことがコンプレックスになりかけています。

そういう状況で趣味の学習を元手にフロントエンドの開発職を狙うのは絶望的かもしれませんが、頑張っていきたいです。

2022年やりたいこと

  • フロントエンドのトレンドのキャッチアップ
  • Rustの学習入門、ライブラリ作成
  • npmのライブラリの公開パイプラインの構築
  • BFFの構築とGraphQL入門
  • AWSやGCPなどのインフラ構築
  • テストコードいっぱい書く

Rustに関してはJavaScriptのツールチェインがRustベースで書かれていることが最近増えてきたのと、TypeScriptは便利だけどそれ以外の型付きの言語を学習してみたいのと、WASMのパフォーマンスを調べてみたいためです。

npmに関してはnpm publishコマンドで公開してみたのですが、ヒューマンエラーが起きそうで怖いのでGitHub Actionsでmainブランチにマージされたらpublishできるパイプラインを構築して本番に近い形で公開できる方法を練習したいです。 ただ個人で開発しているライブラリならnpm publishで公開になりそうです。

テストコードですが個人プロジェクトだと書く気がどうしても起きないのですが、業務で保守性の高いコードを書くには必要なので、個人勉強の範囲で練習して慣れておきたいです。

まとめ

フロントエンドは移り変わりが激しいと言われていたのは昔で大体ReactかVueかその派生フレーワークを使うことがトレンドで固まっていて、今後もその流れは強くなると思います。 ただReact 18の新機能やSvelteの登場、Web版PhotoshopでWeb ComponentsのライブラリであるLitが使われているそうなので、最先端の部分では動きがあるんじゃないかと思っています。

web.dev

ただ自分はまだ業務では素のJSかjQueryしか書いたことがないので、Reactを使う現場に転職できるように頑張ります。

もしこれを読んでいるをReactを使ったフロントエンドエンジニアを募集しているところがあったらお声掛けしていただけるとありがたいです。

良いお年を!