子供が産まれた & 育休を取得しております！
TL;DR
- タイトルの通り、2026年4月に男の子が産まれました！
- お産を支えてくれた病院、最後まで頑張った妻、子育てを手助けしてくれてる親など全ての人に感謝します！
- 育休に入っており、絶賛育児を頑張っております！合間に勉強したりもしてます！
男の子誕生
2026年4月に男の子が産まれました！
幸い妊娠から出産まで大きなトラブルなく終えることができました。 出産予定日の数日前からお休みをもらっていたこともあり、無事、出産にも立ち会うことができました。
とはいえ、妻の立会いに自分が間に合ったのは奇跡で、自宅待機をしていようとほぼ決めていた時にふと「いやもしかしたらもうすぐ産院から呼ばれるかもしれんし、近くのカフェにいるか」という考えが生じ、そこで待機している最中に本当に産院から電話をもらい急ぎ足で駆けつけました。自分が分娩室に着いてから2,3回目のいきみで息子が誕生したので、本当にギリギリでした…
子供が産まれた瞬間、とても嬉しかったです。「あぁ自分はこの子に出会うために奥さんと結婚したんだな」とか、「奥さん本当によく頑張った！あなたは素敵だ！偉い！」とか色々な言葉が頭の中を駆け巡りました。
またお世話になった病院の方々にも感謝してもしきれません。無事に子供が健康で誕生すること自体が奇跡だと思いますし、本当にいい病院・先生・助産師さん達に巡り会えてよかったなと思います。ありがとうございました。
また子供誕生と同時に育休を取得させていただいてます。会社には迷惑をかけることになることは理解してましたが、取得を認めていただき本当にありがとうございました😭
育休開始
妻と交代制のシフトを組んで24時間子供の面倒を見てます。また自分の母親に料理を作ってもらったり少しだけ子供を見てもらったりと様々なサポートをしてもらってなんとかやれている感じです…子育て大変や！みんなこんな大変なことを乗り越えてきたんかい！
一度子供が寝てくれるとやっと自分のプチ自由時間が取れるので、そこでYouTube観たりテック関連の勉強をしてます。最近の勉強の内容は機械学習(主にTransformer関連、LLMやViT)、ハーネスエンジニアリング周りが多いです。
エンジニアという職業に対する将来的な展望ですが、個人的には「ITに詳しいことを武器にした総合格闘家」という言葉がしっくりきていて、元々自分が主戦場としていたWeb開発とかに閉じず色々なことを勉強するようにしております。
あとほぼ同じタイミングで子供が産まれた友人と頻繁に連絡とっていてお互いの子供の話ができて面白かったり、週末に時間を作って会ってくれた友人なども本当にありがとうございやす…！赤ちゃんって人間ではあるものの意思疎通は取れないのでどうしても少し孤独感を感じやすく、こういったイベントがめちゃくちゃ気晴らしになりますな😂
そんな感じですかね！ちなみに子供は本当に可愛くて、大変さを感じながらも幸せな毎日を過ごせています。家族がみんな今後も健康でいれたらと思います。
HTTPS・TLS証明書・TLSハンドシェイクを改めて理解する
0. はじめに
最近は LLM を活用した vibe coding の進化がめざましく、私自身も日々の業務でかなり助けられています。プロトタイプの実装から設計のアイデア出しまで、これまで以上にスピード感を持って開発を進められるようになりました。
ただ一方で、基礎技術の理解がこれまで以上に重要になってきたとも感じています。なぜなら、LLM が書くコードや提示する設計は、結局これまで積み重ねられてきた基礎知識に依存しているからです。最終的にその良し悪しを判断するのは私たちエンジニア自身であり、基礎が曖昧だと適切な判断ができません。
私自身今年の春くらいからはこのような意識を強く持つようになり、トレンドの技術だけを追わずに普遍的な基礎技術のより深い理解に時間を割くようになりました。
そこで今回は、Web の根幹を支える技術のひとつである TLS証明書と暗号化通信 をテーマに、実際に Chrome でどのように確認できるかを紹介します。
1. HTTPSとTLSの関係
HTTP は「暗号化されていない通信プロトコル」です。盗聴や改ざんのリスクがあるため、現代ではほぼ使われていません。
HTTPS は「HTTP over TLS」。つまり HTTP 通信を TLS で暗号化したもの です。
TLS は以下を実現します：
HTTPS という表記は「HTTPがTLSに包まれている状態」を示しており、TLS証明書がその基盤になっています。
なお、アクセスしているWebサイトがHTTPSによって接続できており、かつそのTLS証明書による認証がパスしていることは以下のように確認することができます。
2. じゃあそのTLS証明書って何？
公開鍵証明書 (Public Key Certificate) の一種で、インターネット上のサーバーが「自分はこのドメインの正当な持ち主です」と証明するためのデジタル文書です。
内容には次のような情報が入っています：
- サーバーの ドメイン名（例: example.com）
- 公開鍵（暗号化のために使う）
- 証明書を発行した機関（CA = Certificate Authority）
- 有効期限や署名 つまり「この公開鍵は本当に example.com のものだよ」と保証しているのが TLS 証明書です。
私のポートフォリオサイトだと以下のような情報が含まれていますね。
- サーバードメイン（CN: *.vercel.app）
- 公開鍵
- 発行元 CA（Let's Encrypt）
- 有効期限（2025年6月24日〜2025年9月22日）
3. TLSハンドシェイクの流れ
HTTPSの通信開始時には、ブラウザとサーバーの間で「TLSハンドシェイク」が行われます。現時点での最新は TLS 1.3が採用されているようです。
TLS 1.3 の簡易ステップ
- ClientHello
- ブラウザがサーバーに接続要求
- サポートする暗号スイートを提示
- ServerHello + 証明書送信
- サーバーが暗号方式を選び応答
- 証明書を送信（公開鍵を提示）
- 証明書検証（ブラウザ側）
- 発行元（CA）が信頼できるか
- ドメイン名が一致するか
- 有効期限が切れていないか
- 鍵交換 (ECDHEなど)
- 公開鍵を利用してセッション鍵を生成
- Finished
- 双方が「準備OK」を確認
- 以降の通信は対称鍵暗号で暗号化（AESなど）
このフローで気になるのは「サーバー証明書に入っている公開鍵」でそのまま暗号化通信を継続すれば良さそうなのに、わざわざ 新しくセッション鍵（共通鍵） を作るのはなぜか？ というところです。それは以下ような背景から理解することができます。
1. 公開鍵暗号は「重い」から
- 公開鍵暗号方式（RSAやECDHE）は計算コストが高く、処理が遅いです。
- 通信データすべてを公開鍵暗号で暗号化すると、大量アクセスに耐えられず非効率になります。
- 一方で共通鍵暗号（AESなど）は高速で、大容量データのやり取りに向いています。
なのでTLS では「最初だけ公開鍵暗号を使い、以降の通信は高速な共通鍵暗号に切り替える」という設計になっています。
2. 前方秘匿性（Forward Secrecy）のため
- もし公開鍵そのもので暗号化し続けていたら、後からサーバーの秘密鍵が漏洩した場合に過去の通信も全部解読されてしまう危険があります。
- ECDHE（楕円曲線ディフィー・ヘルマン）などを使って「毎回ランダムに生成するセッション鍵」を交換することで、セッションごとに鍵が変わり、過去の通信は守られる仕組みになっています。
これが Forward Secrecy（前方秘匿性） と呼ばれるセキュリティ上の重要な性質です。
4. そもそもなぜHTTPS / TLS証明書が必要になったのか？
インターネットが普及し始めた頃（1990年代〜2000年代初期）、多くのサイトは HTTP をそのまま使って通信していました。HTTPはプレーンテキストで通信するため、以下のような問題がありました：
盗聴されるリスク
公衆Wi-Fiやプロバイダの途中経路で、送受信している内容（ログインID・パスワード・クレジットカード番号など）がそのまま見えてしまう。
改ざんされるリスク
中間者（攻撃者やプロバイダ）が通信途中でデータを書き換え、偽ページへ誘導したり、広告を勝手に差し込んだりできる。
なりすましのリスク
悪意あるサーバーが「自分は example.com です」と偽っても、クライアントは本物か偽物か判別できない。
なお、HTTP利用時の盗聴は本当に簡単です。Wireshark のようなネットワーク解析ツールを使えば、LANやWi-Fiの通信を簡単にキャプチャできます。HTTPでやり取りされている場合、パケットの中身は暗号化されていないので文字列がそのまま読める状態です。
ちなみに私は新卒の企業の研修で実際にWiresharkを利用してHTTPを傍受することでセキュリティホールを体感しました。「セキュリティリスクに対する知識を上げるためには実際に攻撃者になってみるのが一番いい」ということを学ぶことができたことを今でも覚えています。
5. しかしHTTPS接続をしていれば「絶対安全！」というわけではない
ここまで見てきたように、HTTPSは通信を暗号化し、証明書によって正当なサーバーであることを保証してくれます。しかし、HTTPSを使っているからといって常に安全とは限らない点には注意が必要です。
フィッシングサイトでもHTTPSは使える
Let's Encrypt などの無料CAによって、攻撃者が用意した偽サイトでも容易に証明書を取得できます。ブラウザのアドレスバーに「鍵マーク」が出ていても、そのドメイン自体が本物かどうかは別問題です。ユーザー自身がURLを確認する習慣が求められます。
中間者攻撃（MITM）とEvil Twinの応用
攻撃者は TLS ハンドシェイクを強制的にダウングレードさせたり、偽のアクセスポイント（Evil Twin）に誘導することで依然としてMITM攻撃を試みられます。
特に注意すべきは、カフェのフリーWi-Fiです。例えば、本物のSSIDが Cafe_WiFi なのに、攻撃者が Cafe_Free_WiFi という偽物を用意しておきます。利用者は「無料のカフェWi-Fiだ」と思って接続しますが、実際には攻撃者の用意したアクセスポイントを経由して通信している状態です。この時HTTPSであっても「偽サイトに誘導される」など別の形で攻撃を受ける可能性があります。
【React】大量データフィルタ＆描画の遅延最適化：Reactの遷移APIを体感する
1. 導入（イントロ）
React.jsでヘヴィな描画処理をする際に、UIが重くなりUXを損ねるケースがあります。本記事では、ポートフォリオに掲載している「Heavy Filter」実験ページを例に、
useState & useTransition & useDeferredValueの比較を通じて、ユーザー体験がどのように改善されるかを解説します。
2. 実験ページの概要
- Heavy Filterの概要
- 初期状態で数値1～10000を並べたリストを描画。
- テキスト入力時にその入力にマッチする数値を即時フィルター＆再描画する仕組み。
- 実装構成：従来の
useStateまたはuseTransition／useDeferredValueによる状態制御で比較。
3. 各方式の特徴と操作感
3.1. useState による実装
ユーザーが入力するたびに即座に状態が更新され、再レンダリングが起こります。
大量リストだとフィルター処理や再描画に重さが出て、タイピングと表示に遅延が発生しがち。特に、インプットに「1234」を入力したり、その状態から「Deleteキー」を長押ししてフィルターを解除してみるとわかるのですが、インプットテキストに入力する体験がかなり悪い。
3.2. useTransition の導入
React 18から導入された「遷移（Transition）API」です。「遷移可能な状態更新」としてラベルづけし優先度を下げることで、インタラクションの妨げを避けつつ描画が追従されます。
具体的には、低優先度のフィルタ処理を遷移として扱うことで、入力のたびのUI応答性が向上しており、useStateだけで実装されたパターンとインプットの入力応答性はかなりマシになっているのではないでしょうか？
また、遅延状態を isPendingという変数で扱うことができるので、useStateだけで実装されたパターンと比較してUIに描画待ちであることを表示することもできるようになっていますね。
3.3. useDeferredValue の利用
状態の更新結果（＝フィルター後のリスト）を 遅延値（deferred value） として取得するフックです。
主目的はuseTransitionと同じですが、useTransitionが状態更新のタイミングを制御するのに対してuseDeferredValue は値の参照タイミングを制御していることがわかります。
また、遅延状態の表現ですが、useDeferredValueの場合は「元の値」と「遅延された値」を比較して判定することが可能です。
const isDeferred = deferredValue !== originalValue;
これにより、useTransitionと同様にUIに描画待ちであることを表示することができています。
4. とはいえそもそも10000件のレコードを描画しようとしちゃダメ
フロントエンドでの描画最適化は重要ですが、根本的なパフォーマンス改善はデータ量削減から始まりますね。(突然)
そもそも、毎回フロントエンド側で 10,000 件のデータをフィルタリングするのは、CPU 負荷やメモリ消費が大きくなります。JavaScript はイベントループによる効率的な非同期処理が可能ですが、今回のような単純な配列操作（filter など）は基本的にシングルスレッドで実行されます。そのため、もし 100,000 件規模のレコードを毎回フィルタリングするようなケースになると、UI の応答性が著しく低下することは容易に予想できます。
ネットワーク通信でも大きなJSON配列を毎回送ると遅延や帯域浪費につながります。
したがって、エンジニアとして考えるべきはやはり以下のような対応です。快適なUXの実現はフロントエンドの最適化だけでは終われませんね。
- サーバーサイドフィルタリング
- APIのクエリパラメータでフィルタ条件を渡し、結果を絞り込んで返す。
- ページネーション（Pagination）や無限スクロール（Infinite Scroll）
- 必要な分だけ順次取得し、不要なデータを送らないようにする。
2024年の振り返り
もう年末かい！本当に最近時間が過ぎるのが早いです。 と言う訳で、2024年の振り返りです。
TL;DR
- リードフロントエンドエンジニアとして引き続き頑張っている
- Golangもインプット・アウトプットともに結構できました
- ランニングが新しい趣味になりました、ランニングはいいぞ
フロントエンド
2024年は、現職で行ったアーキテクチャ刷新の効果を非常に感じる１年になりました。コードの見通しは良くなり、開発速度は大きく向上し、本番障害の数もほぼゼロまで下がり…と言った感じです。顧客体験・オペレーション改善に紐づく機能追加も沢山実施することができました。
元々現職の入社動機の１つに
- アーリーなスタートアップで0 -> 1のフロントエンド開発（環境構築からディレクトリ構成・設計、状態管理戦略あたりを全て考える）がしたい
というものがあったんですが、この自分の欲求を満たせたし、アーキテクチャ刷新のようなPJが開発生産性・品質にどれだけ良い影響をもたらすのか、と言うことを肌で感じることができたのがとても良かったです。フロントエンドエンジニアとしてアーキテクチャ刷新 => 保守フェーズでのアーキテクチャ評価みたいなことが仕事で出来たのはとても貴重な経験になりました。
構成も綺麗にしたし監視も入れたし、ドキュメントに構成の背景もしっかり書けたので
今後フロントエンドで入ってくれるようなメンバーがいても「ふ〜ん、なかなか綺麗にできてるじゃん」と思ってくれるはず。とにかく、ここに関しては自信を持って会社に貢献できたな、と思えます。どうしようそんなことなかったら。
バックエンド
2023年の振り返りで「Golangも業務で書いてフルスタック寄りの動きを…」と書いたのですが、こちらもそれなりに達成できました。会社の個人目標としても書いたし、業務外の勉強によるインプットも積極的に行うことができたと思います。元々人材系メガベンチャーでLaravel/PHPを書くバックエンドエンジニアをやっていたのでいつかは貢献範囲をフルスタックに寄せようと思っていましたが、その経験を活かすことができたかなと思います。
ちなみに、A Tour of Goの次に取り組んだのは以下のUdemyの講座です。 クリーンアーキテクチャの丁寧な説明から入った上で、Echo(Go)を使用したREST APIの実装方法を学べます。非常にいい教材でした。
今は実用 Go言語を読み進めています。Goのベストプラクティスが細かく書かれてて、現場でも活かせそうなTipsが詰まった本です。まだ読み終えてないですが圧倒的におすすめ。
あと、他には以下のような本を読み直しました。どちらもWebアプリケーションを作るエンジニアなら鉄板の名著だと思います。３年前くらいに読んだことがありますが、今読むからこそ発見した新しい気づきがボチボチあったのが良かったです。
ランニングにハマった
現在、週2-3回の頻度で5-6kmほど走ることが習慣になりました。きっかけは運動脳と言う本です。全てのホワイトワーカーが読むべき名著だと思います。
簡単に本書の主張を箇条書きすると
- 運動は脳の老化を防ぐ
- 運動で集中力が高まる
- 運動によりストレスが減る
- 理想は週3回45分以上のランニング
といった感じです。まさにエンジニアに必要な副作用ではないですか？
「走りさえすれば、ITエンジニア35歳定年説なんか関係ないんじゃないか⁉️」とさえ思わせてくれる本でした。
私の場合、2024年8月ごろに2-3kmくらいをゆっくり走るところからスタートさせました。
そして2ヶ月ほど継続するうちに上記のメリットを実感値として感じるようになり、走り続けるうちに距離・スピード共に伸びていき、今は週2-3回の頻度で１度に5-6kmほど走れるようになりました。今はなんなら走らないと気持ち悪ささえ感じます！
2025年の目標
また別で記事を書こうと思いますが、以下のような感じになると思います。
2024年もとても楽しかったです！
2023年の振り返り
明けましておめでとうございます！
TL;DR
- 転職して楽しく働いてます
- 関東に帰りました
- 今年は引き続き技術と英語を頑張ります
転職
2023年4月に現職である株式会社Yoiiにフロントエンドエンジニアとして転職しました！入社して1年弱経ちますが楽しく働いています。 転職の動機は
アーリーなスタートアップで0 -> 1のフロントエンド開発（環境構築からディレクトリ構成・設計、状態管理戦略あたりを全て考える）がしたい
今後のキャリアを社内公用語が英語の環境で積みたく、それを満たす会社に行きたい
というところでしたが、今年についてはこれらの欲求を全て満たすことができたので楽しく働けました。
また、現在社内のフロントエンド専任のエンジニアが１人という環境なのもあり、「ほぼ全て自分が責任を持って決めなきゃいけない」という環境がより自分を成長させてくれたかな、と振り返ると思います。社内のコンポーネントライブラリのレポジトリを0ベースから構築できたことも良い経験になりました。
これはカルチャー的なところになりますが、弊社は現在週３出社がルールとなってますが、ブロッカーとなる予定がない限りはみんなで外でランチに行くことが多く個人的にはこれが楽しくて出社が楽しみになってるところがグッドです。
関東に戻った
2023年8月に1年間住んでいた石川県から関東に戻りました。
家庭の事情が理由の100%ですので、特に詳細は語りませんが、関東に帰ってから会いたかった友人に会えるようになったことや、会社にも出社できるようになったので戻ってきてよかったなと思うことが多いです。
今年の抱負
引き続き当分は社内で１人のフロントエンドエンジニアとして働くことが想定されるので、自発的に最新技術のキャッチアップを行うことや、社内ドキュメントの整備なども意識的にコミットすることでチーム全体のフロントエンド周りに貢献できたらなぁと考えています。
また、バックエンド開発に関してもそろそろ業務でコミットしたい、とも最近感じてます。もう2年以上は業務で触っていないのですが、最近UdemyなどでGolangでのバックエンド開発の勘所は学習したので、チャンスがあり次第こちらも貢献したいです。
また組織体制の話になりますが現在PdMが不在です。自分としてはプロダクトのリファクリングPJを通してドメイン知識についてはかなり詳しくなったのもあり、自分が要件定義の上流部分にコミットすることが増えるのでPdMのような仕事も担当すると思います。この辺りの業務内容は、NRIで仕事をしていた際に英語で要件定義を行いドキュメントを書く経験はある程度積んだので、積極的に取り組んでいこうかなと思います(というか去年の末からこの辺りはすでに手を出し始めました。笑)
あとAtCoderも引き続き頑張ります。
長期的なキャリアでいうと、当分は社内公用語が英語で多国籍な会社でのキャリアを積んでいこうかなぁと考えているので、英語力についても今年の１年でもっと改善できたらなと考えています。英会話スクールに通うかオンライン英会話を始めるかなど、選択肢が多すぎてどれを始めるか悩んでいるところ…
仕事でも英語を使っているので少しずつは改善していくとは思いますが、意識的に勉強することの必要性を最近感じることが多いです。また、日本人同士での会話で日本語を使ってしまう癖があるので、なるべくEnglish-Only Policyを自分に課していく必要がありますね🥺
【ChatGPT】【GraphQL】ChatGPT-4に教えてもらいながらポートフォリオにGraphQLを爆速導入してページ追加してみた【20分で完了】
はじめに
この記事では、ChatGPT-4を利用した開発がどれだけの生産性向上に寄与するのか、というのをざっくり試したものになります。 今回は、あまり自分が詳しくないGraphQLで試してみました。
やってみたこと
試したことは以下の通りです。前提として私は業務上でのGraphQLの利用経験は一度もありませんし、そもそもGraphQLを個人開発などでも利用したことがありません。
また、一応事前にPlaygroundを通してGraphQLのクエリの書き方などは簡単に学びました(その際も疑問点はほぼ全てChatGPT-4に聞いた・・)
- GraphQLをNext.jsで構成されたポートフォリオに導入する
- https://graphql-pokemon2.vercel.app に対するクライアントを作成する
- ポケモン一覧を取得するクエリを作成する
- クエリ結果を一覧として表示するページを作る(スタイリングなども全て任せる)
最終的に出来上がったページが以下です。ちなみにコンテンツ以外の部分は元々存在していたコンポーネントを再利用しています。
なお実装に要した時間は20分ほどです。
https://lamechang-dev.vercel.app/playground/pokemon_graphql
ざっくり振り返り
仮に１から自分が取り組むのであれば様々ググりながら進めていくとして、見積もりに1時間半-2時間ほどを設定すると思います。
が、今回 20分ほど で完了してしまいました。はっきり言って強力すぎますね。。。 しかもChatGPT-4って回答に周辺ライブラリの利用背景とかも完結に説明してくれていて非常に分かりやすいんですよね。開発体験がとても良かったです。とんでもないものが誕生してしまった気がします。
【英語】私の英語学習のこれまでとこれからを晒す
TL;DR
私は自分に甘く、興味が湧かないものについては必然性がないと努力をし続けることができない愚かな人間なのです…
これまで
〜高校卒業
大学受験をしているので英語は予備校を通ってちゃんと（？）勉強をしていました。参考になるか謎ですが、河合塾の最後の模試では英語の偏差値で65前後だったと記憶しています。
なお、学習時間は読む・書くにほぼ全て突っ込んでました。英語自体は特別得意だったり好きという訳ではなかったですが、嫌いではなかった、といった感じです。
大学在学中
大学１年次に入学と同時にTOEICを受けたのですが、確か500点くらいでした。大学の講義の中にも英語関連のものはありましたが、当時はモンスターハンターがとても楽しかったので事前学習や予習・復習などは特にしませんでした。そのまま大学３年次まで過ごします。
大学４年次に、英語を集中的に勉強したいと思うきっかけが生まれ、フィリピン留学に４ヶ月ほど行きました。ちなみにそれまで海外経験はほぼゼロで、物心ついてから以降の初海外でした。特に行きのフライトは信じられないくらい揺れて本当に死ぬのかと思った。
留学先から事前に課された勉強スケジュールを日本でこなしてからフィリピンに行ったので、現地に着く直前に受けたTOEICで800点ほどを取ることができ、なんだかんだで大学入学直後から300点ほどスコアを上げることができました。読む・書くは受験勉強の資産もあってかキャッチアップしやすく、留学期間は苦手だった聞く・話すにかなりフォーカスできたことが振り返ると良かったです。
留学を通して日常会話レベルなら聞く・話すはできるようになり、また現地で受けたTOEICで 900点ほどを取れました🥶TOEICのスコアに満足してからは、フィリピン人講師との授業はフリートークをメインにしたり適当にご飯食べに遊びに行ったり、TOEFL対策などをしたりしていました。なお結局学士で卒業 => 就職を選んだので結局TOEFLは受けてません。
フィリピン留学は私にとって本当に大切な思い出です🌝🌝
英語力が上がったことももちろん理由の１つですが何より現地での生活は楽しかったし、ちょっとクレイジーな社会人の先輩がたくさんおり、そういった方々から聞けた話から学生ながら価値観を大きく広げることができました。
まぁ簡単にいうと「人生って大体どうにかなるんだなぁ」ってことを理解できたと思います🌝なおこの留学をきっかけに海外旅行にドップリハマるようになります。
社会人
SIer在籍時
留学経験をよく話して就職活動をしたので、１社目のSIerでは運良く英語を使う部署に配属されました。開発パートナーはインド人のメンバーで構成され、業務の半分弱ほどを英語で２年半ほど行いました。
正直新卒入社時点で英語力は日常会話程度であったので入社直後は結構苦労しました。が、インドメンバーが日本人特有のブロークンイングリッシュに理解があるメンバーだったので、業務で絶望するほど困ったことはなかったです。
２年半の業務期間中、英語を集中的にインプットすることは一度もなく業務をしながら「あれ、こういう時ってどう表現すればいいんだろう？」という場面に出くわすたびにググる => 使うを繰り返してちょっとずつ話せる内容のバリエーションを増やした感じかと思います。こういったプロセスのお陰か、システム周りの細かい議論が業務特性上多かったのでその辺りについては苦手意識はなくすことができたのかな、と思います。
Webエンジニア転向以降
聞く・話すでは一切使わなくなってしまいました。また、読む・書くについても頻度が落ちたことが影響してスピード・理解度ともに下落傾向にあることを感じています。英語で書かれた技術系のリファレンスをたまに読みますが毎回衰えを感じてちょっと凹みます。。。
ただ、映画を英語音声で見るときに「あれ、今の単語なんて意味だ？」みたいなことを都度ググったり聴き直ししたりはしたので、完全に使わなくなった訳ではないかもです。
すいません、「ゆーてサボってた訳じゃなくて映画を通して活きた英語学習をしてたで？」みたいなことを突然書いてしまいました。本当はこの期間も本腰を入れて英語学習をする余暇の時間はいくらでもありましたし、正直勉強をあまりしてこなかったことを後悔してます。。
これから
と、ダラダラとこれまでの英語学習の経緯を話してきたんですが結局今回のエントリーで何を伝えたかったというと私は自分に甘いので、あまり興味が湧かないものについては強烈な必然性がないと努力をし続けることができない人間であり、これまでも必然性が生まれる環境に身を置くことでどうにかして何かを習得してきたということです。
ちなみに英語学習はぶっちゃけ好きではないです。が、私は１社目やフィリピンでの経験から多国籍な組織・文化での活動や就労にずっと興味があり、それはWebエンジニアに転向してからも変わりません。
実は海外就職にもずっと興味はありましたが、運悪くコロナが大流行したり結婚を機に価値観が変わったりと、そう言った理由で少し興味が薄れていました。
ただ、日本にいながらも多国籍 & 英語環境で自分が好きな領域でのアプリケーション開発に没頭できるような組織は実はあるんじゃないかとフワッと最近思っていたのですが、最近運良くこれに該当するスタートアップさんからお誘いいただき、入社することになりました。
今回の記事は転職エントリーだとは思ってないので細かい転職理由は触れませんが、運良くまた英語環境でのエンジニアの業務ができることを非常に楽しみにしています。
また、改めて自分のスタイルは わざと自分を追い込んで、背水の陣の状態でどうにか頑張って成長するというところにあるな、と思ったので今後も英語学習はそう言ったスタイルで継続していこうと思います🤢
補足
ちなみに そもそもなぜ英語を学習するのかですが、これは以下のような理由になります。上から優先度が高いです🙏🏻
- エンジニアにおける技術や情報のインプット・アウトプットに関して、
読む・書く・聞く・話すの４技能全てにおいて英語でストレスなく行えるようにしたい - 年齢も性別も国籍も人種も関係ないような多様性・透明性のある組織での仕事に興味があるので、そう言った組織で採用されてるであろう英語を自由に扱えるようになりたい
- 2024年公開予定の
ストレンジャー・シングス 未知の世界 シーズン５を英語音声・英語字幕で楽しみたい♥️
