PyCon JP 2025 に初参加してきました！
はじめに
（参加レポートを書くのが大変遅くなりましたが）昨年9月に行われた Python の国内最大のカンファレンスである PyCon JP 2025 に初めて参加しました。
PyCon JP とは、プログラミング言語 Python に関する日本最大級のカンファレンスで、一般社団法人PyCon JP Association によって運営されています。
開催期間はこれまで金曜・土曜の2日間で、PyCon JP 2024 までは東京開催だったそうですが、今回参加したPyCon JP 2025 は地方の広島で開催されました。
Python とのかかわり
業務で2024年から FastAPI フレームワークを使い始めました。
2024年は主に threading を使ったマルチスレッドプロセスの開発を、2025年から今に至るまでは FastAPI を使ったアプリケーション開発（生産計画指示・実績登録アプリ）をしています。 歴は1年ちょっとです。
また、最近はご無沙汰ですが、一時期 AtCoder に仲間とのめり込み、Python を選択したこともあって、基本文法は習得済みです。 （ちなみにランクは茶色まではがんばりました。）
参加を決めた理由
PyCon JP の存在自体は、昨年5月に参加した TSKaigi 2025 の懇親会でお話しした方から教えてもらいました。
以下の TSKaigi 参加ブログにも書いたのですが、RubyKaigi に今年2回目の参加をしたことで、
「仕事で使わないRubyのカンファレンスに2回も行ったのだし、業務で普段使っている TypeScript や Python のカンファレンスがどんなものなのか一度は行ってみたい」
という思いが芽生えました。
ただ、開催場所が広島であることや、それ以上に Kaigi on Rails 2025 と日程が完全に丸かぶりしていたため参加を悩みましたが、FastAPI の生みの親である Sebastián Ramírez 氏がキーノートスピーチすることになり、参加することに決めました。
やっぱり普段使っている仕事道具の開発者の生の声を聞ける機会はとても大切だと思ったためです。
Ruby の Matz のようにさまざまな媒体でインタビューをしているわけでもない（僕の知る限りでは）ので、どういうことを考えて開発しているのかに興味がありました。
参加した感想
特に印象に残っている発表
キーノートスピーチ
Sebastián Ramírez氏
まず同時通訳がとても助かりました。事務局には本当に感謝です。
話されていることは終始一貫していて、
- 「問題（Problem）ありき」で開発する姿勢
ここに伝えたいことがほぼ集約されている気がしました。 プログラミング言語もWebアプリケーションもIT技術も、「誰かの問題を解決する」ために生まれているのだと再確認できました。
懇親会でもお話しさせていただく機会があり、
- なぜバージョン1をリリースしないのか？
について伺えたのは貴重な経験でした。
以降業務で使う際には FastAPI に対しこれまで以上に愛着と感謝の気持ちを持てている気がいます。
大塚あみ氏
メディアによく掲載されているのを見かけていたので（書籍のことも）、この方の存在自体は知っていました。 正直そこまで期待はしていなかったのですが、いざ話を聞いてみると熱量がものすごい高い方で、ものの数分で引き込まれました・・・！
課題をサボるためにAIを使い倒した話を聞いて、「これはプログラマー三大美徳そのものだ！」と思ったし、注目されることで容姿への批判もあったけどそれを反骨心に変えて一層奮起した話を聞いて、力強さや勇気をもらいました。
僕は40代なので、いろいろ年齢や家族を理由に自分を卑下することもあったのですが、それを言い訳にチャレンジしないわけにはいかないな、と考えさせられました。
あとこの PyCon JP で発表するために開発したメモアプリの動機も「メモできないくらい自分が多動ですぐにやったことを忘れちゃうから」という話も、行動力が本当にすごいな！と思いました。
眞鍋秀吾氏（Recustomer CTO）
本カンファレンスで最も面白いと感じた発表でした。 会場もいちばん盛り上がっていたと思います。
「そもそもGILって何？」
というレベルだったので、
- GILとはGlobal Interpreter Lockの略で、Pythonのプログラムが同時に1つのCPU（スレッド）でしか動かないように制限する機能であること
- なぜGILの概念が生まれたか？（他スレッドがメモリを書き換えないようにするため）
- そのGILが3.13から実験的に解除できるようになったこと
- 似た状況のRubyの立場について
などなど、知らないことばかりでとても面白い内容でした。
スライドだけでも目を通す価値ありです！（特にRubyistの方も）
GILについて知れたことで、少し前に公開されたこちらの記事（I/Oバウンド、CPUバウンドについて各言語で比較されています）も楽しく読むことができました。 （Goが異なるアプローチを取っていることも知りました）
nikkie(にっきー)氏
普段から使っているけどいまいち複雑でよく理解できていないloggingロギングライブラリについて、その構造とおすすめの使い方を提案した内容で、今後取り入れたいと思える実践的な内容でした。
- ロギングを構成する4つのレゴパーツ
- ロガー（Logger）・・・窓口。プログラムのあちこちで「何が起きたか」を受け付ける。
- ハンドラ（Handler）・・・出力先。ログを「コンソールに出すのか」「ファイルに書き込むのか」を決める。
- フォーマッタ（Formatter）・・・見た目。ログを「どんな形式（時刻、内容など）にするか」を整える。
- フィルタ（Filter）・・・選別。特定の条件のログだけを通したり止めたりする。
- ログの伝播（Propagate）。すべての子ロガーで発生したイベントはルートロガー＝親ロガーに渡される。★重要
- おすすめの使い方は子ロガー（ライブラリなど）で細かく設定しないこと。これでシンプルになる！
※実は同時間に面白そうなセッションがあり参加を迷っていたのですが、参加してよかったです
fujidomoe氏
似たような内容が他にもあったのですが、PythonはWebエンジニアだけでなくデータエンジニアにも使われる言語なので、データエンジニアが書いたべた書きコードをどう責務分割し、DDD、クリーンアーキテクチャに寄せていくかという内容で、勉強になる発表でした。
その他（全体を通して）
初学者を受け入れる雰囲気
非エンジニア（医師やビジネス担当など）向けの発表がかなり目立ちました。 やはりWebにとどまらず科学計算や簡単なツールを作りたいときなど、Pythonを広く触ってもらいたいというカンファレンスの空気感をとても強く感じました。
この点は4ヶ月前に参加した TSKaigi とはかなり対照的だと思いました。（TSKaigi はつよつよなフロントエンドエンジニアがとにかく多かったです）
セッションが多い
1つの時間枠で4つの講演があり、これは TSKaigi や Kaigi on Rails と比べても多いと感じました。 ただ、レベル感がばらけている（非エンジニア向け、学術向けなど）ためにどれに参加しようか迷うことはほぼなかったです。
参加費が安い、弁当付き
参加費がわずか5000円、かつ豪華弁当付き（だいたい余るので食べたい人は2つ以上普通にもらえるｗ）。 これは TSKaigi とまったく同じレベルでした。 やはり Python だからかスポンサーが強い印象を受けました。
他言語のカンファレンスと比較して
同じ2日間（金、土）であることからTSKaigi（2025年に参加）と Kaigi on Rails（2023年に参加）と比べた個人的な印象を簡単ですが書いてみると、以下の感じかなと思います。
※ Rubyのカンファレンスは RubyKaigi ですが、3日間開催だったり、内容が低レイヤー寄りでアプリケーション（＝応用）寄りでは全くないため、比較対象からは除外しています
※ 記憶のみ、印象のみで書いているので違っていたらすみません
Python（PyCon JP）
- 門戸が広い。非エンジニア大歓迎。
- 反面ガチで難しい内容はやや少なめ。
- 分野が広い。Webは半分くらい？
- 参加費安い。5000円。2日弁当付き。
- 地方開催（広島）。 ←来年以降も広島みたいです
＿|￣|○
TypeScript（TSKaigi）
- 門戸はわりと狭い。ガチなフロントエンドエンジニア向けで、自分のような「一応React触ってます」レベルのハンパ者ではちょっとハードル高いです。型パズルになるともはや手も足も出ませんｗ
- けどその分、レベルの高い発表が多く、中級者以上でも十分楽しめる内容。DDDやクリーンアーキテクチャの内容も多め。
- 分野は完全にWebのみ。
- TSとなっているが完全にTSに関係ないReact（またはVue）に関する内容のものもわりと多い。なので「フロントエンドKaigi」とかでもいいのでは？という気がちょっとした
- けどサーバーサイドTSもあるにはある。
- （PyCon JP同様）参加費安い。5000円。弁当の豪華さもPyCon JP並。
- 東京開催で行きやすい。
Ruby（Kaigi on Rails）
- 門戸は広い。PyCon JP ほどじゃないけど学習中の未経験でも十分に楽しめるレベル感。
- 上2つにはない大きな特徴として、Railsの枠にとどまらないDBやネットワーク、非同期の話や、パフォーマンス改善の話などWebにまつわる話が聞けるので、Rubyistでなくても全然楽しめる。
- 分野はWebのみ（TSKaigiと同様）
- 参加費用が高い。15000円。弁当なし？（2023年はなかったです）
- 東京開催で行きやすい。
終わりに
広島という遠方ながらも（ありがたいことに交通費と宿泊費の約5万円を援助いただきました）初めて参加できてとても有意義な時間を過ごすことができました。
TSKaigi や RubyKaigi ほど消化不良にならない反面、少しばかり物足りなさも感じた部分はあるかもしれません。
今年（2026年）も予定が合えばぜひ参加したいと思います！（こんどは自費で）
2025年の振り返りと2026年の目標
はじめに
この記事はCloud Pratica アドベントカレンダー 21日目の記事です。
（自分の記事はさておき、どの方の記事も非常にハイレベルで読み応えあるのでおすすめです！）
Cloud Pratica はりょうま（@engineer_ryoma）さん / Xが運営している現役エンジニア向けテックリード養成スクールで、受講生全員が仕事をしながら学習に励んでいます。
（詳しいカリキュラムは以下より確認できます。あまりの膨大さに白目むくと思います）
※本記事は Cloud Pratica のアドベントカレンダー記事ですが、今の部署が社内アプリ開発が中心かつクラウドが使えない職場のため、クラウドやSREに関する話は今年やったことの中には基本出てきません🙏
この記事を読んでほしい人
- CPの方（特に自分のように今はアプリ開発メインだけど今後クラウド案件へのJOINを目指して学習中の方）
- きたろうのことを知っていて、今年どんな開発をしていたのか興味を持ってくれた方
- 「こうするともっとサービスがよくなりそう」と温かい目で読んでくださる方
- （IT業界でない）製造業界のWebエンジニアがどんなことをやっているか知りたい方
- 未来の自分ｗ（来年の今の時期にこの記事を見返して成長をしたなぁと思いたい）
- はじめに
- この記事を読んでほしい人
- 自己紹介
- 2025年振り返りまとめ（仕事）
- 取り組んだこと（仕事編）
- 取り組んだこと（学習編）
- 取り組んだこと（プライベート編）
- 2026年の目標
- さいごに
自己紹介
- 40代。専業主婦の妻と中1、小4の息子がいます。持ち家有り
- 大学院卒（名大）で今の勤め先（某製造業）に機械系で入社。30代後半に社内転職でソフトウェアエンジニアに転向
- 本社直轄の生産技術部門として、全国各地に点在する事業所や生産工場（グループ会社含む）のデータ活用や分析アプリの開発や要件定義のサポートなどを行う
- エンジニア歴は3年程度。Next.js、FastAPI。（会社が統合サーバー（Windows Server または CentOS）を基本用意しそこにデプロイするためクラウドは使わせてもらえない環境）
- フィヨルドブートキャンプ（以下FBC）というスクールで学んでもうじき3年（最近は本業が忙しくあまり活動できていません・・）
- Cloud Praticaには今年10月末に入会（まさか自分が審査にパスできてびっくりしました）
2025年振り返りまとめ（仕事）
年明け1週間ほどマイペースに仕事していたら、いきなり今のテーマにアサインされ、翌々週から宇都宮に駆り出されるという嵐のような日々から2025年が始まりました。
（去年までの主担当が1月末で急遽異動になった ＆ PMの先輩の身内に不幸があり自分しか現場対応するメンバーがいなくなったため）
| 時期 | やったこと |
|---|---|
| 1〜2月 | 市販ソフト（試用版）の試験導入、現場の御用聞き |
| 3月 | 要件定義、UI設計、DB設計、技術選定 |
| 4月 | プロト開発 |
| 5〜8月 | 機能開発（RFID連携、Excel作業手順書連携など）、パフォーマンス検証、リファクタリング |
| 9〜10月 | 現場実証、バグ修正、機能追加要望対応 |
| 11〜12月 | 全体進捗管理ダッシュボード開発 |
取り組んだこと（仕事編）
生産スケジューラとは？
簡単に言うと「製造現場で使われる自動計画作成ソフト」です。
人や設備、工具などの資源情報と、A工程、B工程などの作業情報を与えることで、極力無駄が発生しないような計画（いつ、誰が、どの設備、工具を使って、この作業を行うのがよいか）を自動で算出してくれます。
国内No.1シェアの 生産スケジューラ Asprova APS | アスプローバ株式会社 などを見てもらえればどんなものかイメージがつくかと思います。
（注：実際にどの製品を我々が採用したかはここでは控えます）
今回対象としている事業部（半導体関連）では以下の課題、
- 生産台数を今よりもっと増やしたい（着手から完了までのリードタイムが1ヶ月以上かかるような大型装置）
- けど昨今の人手不足でなかなか人を採用できない（特に地方では深刻）
に直面しており、生産スケジューラを使って、人を増やすことなく、今の人員の最適配置と再教育によって、生産量を増やそうという野心的な取り組みであり、期待も大きいです。
具体的な施策としては、
- ボトルネック工程を特定
- 作業者のスキルマップを策定し、各工程ごとの基準作業時間に対しその人がどれだけ早くこなせるor時間がかかるかをスケジューラが日々自動チェックして、得意な作業をやらせるようにしたり、多能工化することで、同じ製品を同じ人員数でより短い期間で出荷できるようにする
- 結果、増産につながる
というのが生産スケジューラ導入の狙いです。
ここでKPI（製造リードタイム〇〇％減など）を達成できれば事業効果も数億、数十億にのぼることが期待され、ここでの成功事例を他の事業部にも水平展開できる可能性も秘めています。
そんな事業インパクト大で非常にやりがいあるテーマですが、開発の実働部隊は自分とPMの先輩のたった2人です。笑
とまあ、そんな感じの環境で今年1年は馬車馬のごとく頑張ってきました。
1〜2月：市販ソフト（試用版）の試験導入、現場の御用聞き
市販ソフト概要（DB丸抱え、スケジューラ部とUI部（作業指示・実績登録部）が別売り）
ざっくりシステム概要を書くとこんな感じです。
- スケジューラ部とUI部はそれぞれ別売り（1ライセンスあたり3桁万円を軽く超えます）
- 統合サーバーにスケジューラをインストールして使用
- スケジューラには膨大な数のAPIが用意されており、好きな言語（C#以外にPython、TypeScript、Javaなど）でアドイン機能を開発可能（データを外出ししたり分析したり、やろうと思えばやりたいことはだいたい何でもできる印象）
- 作業者が作業内容をチェックしたり、開始/完了を入力するアプリはデスクトップアプリを各作業者PCにインストール。（こちらは何台でも無料）
- マスタデータ（工程モデルや作業者、設備、工具、勤務カレンダーなど）は統合サーバーにリモートデスクトップ接続してファイルをアップロードする運用
実際に試験導入したらUI部がいまいち→UI部のみ自前開発することに
市販ソフト一式でうまくいけばめでたしめでたしでしたが、そんなうまいことは事が運ばず、実際は（特に）UI部で不満が噴出しました笑
- 先の予定を見たいのに（Xなどにあるような）無限スクロール方式になっていて、どれだけスクロールしても翌日の作業すらなかなかたどり着けない！
- 必要な情報が載っていないから作業できない！（工程記号だけではわからない、工程名も載せてくれないと）
- （作業者を選択しないと作業が表示されない仕様なので）全体計画がどうなっているのか、どこまで進んでいるのかが俯瞰してわからない！
- 計画に作業が割り付いているけど、実際はものがない（＝前工程から材料が来ていない）ので実施できない！
- ・・・
などなど、挙げれば20くらいあった気がします。
色んな作業者から同じ不満をこれでもかこれでもかと聞かされて（しかも暑苦しいクリーンルーム）、なかなかハードな2ヶ月を過ごしました・・・
（下の方で少し触れますが、息子の中学受験が1月早々に決まってくれたことでかなり救われました。下手すると自分が長期不在で家庭崩壊するところでした）
3月：要件定義、UI設計、DB設計、技術選定
試験運用で上がった課題を解決するために、UI部は自前で開発することになりました。
システム的には、
- DBを市販システムから外出しして、PostgreSQLを使う（アドイン開発で実現）
- DBをI/Fにして、UI部がDBから作業計画を GET して表示 ＆ 作業者が実績入力したら POST or PUT
- マスタデータのやりとりは、スケジューラで別途アドインを開発し、Excelマクロ（VBA）からスケジューラに流し込めるように
としました。
要件
1〜2月の現場検証で上がった改善内容を列挙するとこんな感じ。
- 職場全員分の作業を一覧で見られるようにしたい（主に職場長向けだが作業者も）
- 作業実績を登録できる
- 作業を中断・再開できる
- 作業者や使用する装置を計画上のものから変更できるようにしたい
- 他の人が行った実績登録を即座に自分の画面に反映したい
UIイメージ
以下を基本形としました。（前回のブログでも書いているのでここではざっくりとだけ）
- 黒背景にして空港発着案内板をイメージ
- ひとつの作業にはだいたい前段取り（工具や被加工物の取り付け、位置出しなど） → 製造（装置による自動加工） → 後段取り（工具や被加工物の取り出し、測定など）がセットで存在するため、それらを横並びで表示するように
- それぞれのステップ（前段取り、製造、後段取り）には計画上の開始・完了時刻と、開始ボタン・完了ボタン（ボタンをクリックすると押した時刻に変わり、DBに実績が登録される）、作業者プルダウン、装置プルダウン（計画上の作業者が表示されるが実績登録時に変更可能）をUIにもつ
- 遅延アラート機能（計画開始時刻or完了時刻に対し◯◯分遅れていたらボタン色が橙色に変わる）
DB設計
まずひとつ大きな判断ポイントとして、すべての工程が（加工職場のように）前段取り、製造、後段取り、とあればよいのですが、実際は（組立工程のように）製造工程しか存在しない職場もあるため、汎用性を持たせるために、計画テーブル（task_plans）のIDとしての主キーを以下の複合主キーとしました。
製品オーダーID（UUID）工程ID（UUID）作業ステップ（前段取りのS（Setup）、製造のM（Manufacturing）、後段取りのT（Teardown）のいずれか）計画バージョン（20251221080000のようにスケジュール作成した日時をBigintで管理）
上2つがUUIDなのは、今回は職場ごとにスケジューラおよびDBサーバーを分ける運用としていますが、将来的にこれらが統合する可能性も考え、バッティングしないようにUUIDを選定しています。
3つめの作業ステップですが、こうすることで、前段取り・製造・後段取りを横並びにするビュー（データベースのViewです）の作成が容易になります。
ビュー作成のイメージとしては、まず計画テーブル全体から製品オーダーIDカラムと工程IDカラムのみをDISTINCTで取り、そのCTE（WITH句でつくるやつ）に対して作業ステップがS, M, Tそれぞれで絞ったテーブルをLEFT JOINする要領です。
4つめの計画バージョンですが、各計画バージョンで最大6万レコードが存在する想定ですが（1製品あたり3ヶ月区切り想定）、たとえば作業者の突発休暇などでスケジューラがリスケするたびに6万のレコード群がどんどん増えていくイメージです。
（仮にスケジューラが1日平均4回リスケし、そのたびに6万件ずつ増えていくとすると、6万×3ヶ月×4回/日＝2160万レコード）
つまり、一意の「製品オーダーIDと工程IDと作業ステップの組み合わせ」が、計画バージョンの数だけ存在することになります。
次に計画に紐づける実績テーブル（task_records）ですが、これは計画バージョンがいくつあっても実績はひとつだけになるので、
- 製品オーダーID
- 工程ID
- 作業ステップ
の3カラムでユニークとし、計画テーブル（task_plans）に実績テーブル（task_records）をLEFT JOINすることで、実績開始・完了時刻がNULLのときはボタン表示を「開始」「完了」とUIに表示し、NOT NULLのときには「timestamp型で格納された時刻」を表示するようにしました。
技術選定
前回のブログ であれこれ書きましたが、技術選定は完全に自由にできる環境の中、「Next.js＋FastAPI」としました。
- Next.js・・・React+Viteでもよかったけど機能が増えていくにつれSSG、サーバーコンポーネントなどの手札が多いNext.jsをとりあえず選定しました。自分がいなくなったときの引き継ぎもしやすいこともあります
- FastAPI・・・フロントエンドがNext.jsなのでNode.js（サーバーサイドTypeScript）にしようかと思ったのですが、開発初期（というか今も）DB設計がころころ変わるのに追従しやすい（例えばAとBとCは親-子-孫の関係だと思っていたら、実はドメイン知識を深く掘っていくと「AとBは実は多対多だった・・！」とわかり、A-C、B-C の親子関係に作り直すなど）、あとこのAPIはNext.js以外にも別システムが使ったりエンドポイントを生やしたりすることも多く、Next.js側のことを気にせず個別にエンドポイントを生やしやすいようにする点、から採用しました。
4月：プロト開発
「GW明けまでに動くものを見せる」という目標のもと、スピード重視で実装しました。
Reactは学習（前回ブログ参照）でしか触れたことがなかったものの、モダンJSの学習で学んだ配列処理（map関数やMap()・Set()オブジェクトへの理解など）を理解していたことで、今回の要件に対しては割とスムーズに進められました。
ポーリング機能やマスタデータのfetchを SWR でシンプルに書けたことも大きかったです。
動くものを依頼元課長に見せて、「いいね〜」と肯定的なフィードバックをもらうことができました。
5〜8月：機能開発、パフォーマンス検証、リファクタリングなど
大小いろいろな機能を開発しましたが、特に印象に残っている以下に触れます。
MQTTプロトコルを用いたRFIDによる自動実績登録システム
本機能が必要になった要件として、
- 「部品庫の作業はオーダーあたりの作業数が多い（5分くらい）のでボタンぽちぽちはしんどい。自動化してくれ」
という要望が現場より上がったのがきっかけでした。
RFIDについてもっともわかりやすい例を挙げるなら、ユニクロの無人レジかなと思います。
（画像引用）ユニクロの無人レジとは｜導入の背景・仕組み・特許訴訟の行方も | 無人販売ナビ
今回使用したRFIDリーダーはこちらの製品を選定。
PCにUSB接続して使い、同製品が用意したSDKを使って検出したRFIDタグを取得して、APIに投げています。
※C#など限られた言語のSDKしか用意がなく、製造業におけるC#の存在感を改めて実感しました
APIに投げるプロトコルはHTTPも候補に上がったのですが、当初は MQTT でないと実現が難しい機能要件（＝始めからリーダーの検出範囲内にある台車も自動登録させたい）があったために MQTT になりました。（今は要件が変わり、HTTPでもよくなりました）
MQTTは今回初めて触ったのですが、思ったよりシンプルでIoTまわりでは使いやすい通信プロトコルだと感じました。Pub/Subの理解も少し明るくなりました。
システム構成は以下。
FastAPI側でMQTT対応のライブラリも用意されていて、MQTTメッセージ受信をトリガーにDBへのINSERTやUPDATE処理も可能です。
苦労したこととして（今も苦労中）、
- ユニクロのようには全然いかない笑
なかなか思うようにいかず、レイアウトからきちんと考える事の大切さを学びました。
運用イメージの図を（雑ですが）つくってみました。
また、RFIDタグをDBに登録する際にはWebSocketを使って機能を実装しました。
非常に簡単な要件ですが、WebSocketも今回の開発で初めて必要になり使ったことで、どんなものかのイメージが付きました。
- 登録したいRFIDタグを用意
- RFIDタグに紐づけたい部番の登録ボタンをクリック（部番とタグIDは1対多の関係）
- ポップアップが出る（このときWebSocket接続中）
- APIがタグ登録用のRFIDリーダーからタグを受信すると、DBのテーブル（rfid_tags）に部番IDとタグIDが登録される。またはUIのキャンセルボタンが押される
- WebSocketが切断され、ポップアップが消える
ポップアップ表示中でないときにRFIDリーダーからAPIがタグを受信してもDBには登録されないことになります。
Excel作業手順書に計画IDを動的埋め込み
これも今でこそ安定運用できていますが、軌道に乗せるまでがかなり大変でした。
- 「すでに運用中のExcel作業手順書」に上で触れた作業計画のユニーク情報（製品オーダーID、工程ID、作業ステップの組み合わせ）を動的に埋め込み、
- これまでどおりに作業手順書を開いてページをめくるだけで、進捗率が更新されていく
- Excelを閉じたら自動で完了実績が登録される
という仕組みを確立しました。
これはPythonのExcelマクロを埋め込めるライブラリ xlwings Documentation を用いることで実現できました。（埋め込むVBAコードは試行錯誤を重ね、ファイルダウンロードの速度を現場運用に耐えうるレベルに持っていくのに苦労しました）
あまり対外的にアピールできる成果ではないですが、この仕組みを構築できたことで、2000あるExcel作業手順書1ファイルごとに実績登録APIへのHTTPリクエスト処理コードを（現場の方が残業時間で）埋め込むことを想定していたので、その工数約100時間以上相当を削減できた、個人的に胸を張れる残る成果になりました。
画面イメージとしてはこんな感じです。（上で紹介したUIは前後段取りが前提でしたが、Excel作業手順書を用いて生産している組立職場においては、前後段取りは存在しないので、職場ごとにひとつのリポジトリでUI表示を変えるようにして保守コストを下げています。
特徴として、
- 開始ボタンを押すと、サーバーに保管された工程記号が一致するExcel作業手順書を探し出す
- 見つけたExcelファイルを内部でコピーして計画データとAPIを叩くVBAスクリプトを埋め込む
- ブラウザ右上にダウンロードダイアログが表示されるので開く。開始実績がPOST送信され、開始ボタンが開始時刻に変わる
- 作業者は今までどおり作業手順書を見ながら作業する。ページをめくるごとに進捗率の数字を「現ページ番号/総ページ数」から計算し、結果をPUT送信する→画面の進捗率の数字が更新される
- 最後のページまでめくった後にファイルを閉じると完了実績がPUTされ、完了ボタンが完了時刻に変わる
この機能、実はとても厄介なトラップが潜んでおり特定に苦労したので、マニアックですが頑張ったタスクとして書いておきます。
FastAPIを手動で起動させたときにはこの問題が起きないのですが、タスクスケジューラ（Windowsの定期実行ツール）でFastAPIを起動させるときの設定を「システム起動時」にすると、管理者権限でアプリが実行されないことになり、現場からは「手順書がダウンロードできない」というクレームにつながりました。
原因は、「システム起動時」だとユーザーがAdminに定まっていないらしく、その状態でFastAPIを起動するとExcel操作を意図した操作にならない（ファイル名の重複エラーが起きてしまいコピーファイルを作成できない）ことで、これはかなり原因を見つけるのに苦労したバグでした。
今は安定稼働している現場からも喜ばれている機能なので、頑張った甲斐があった機能ですが、対外的に頑張りがアピールしにくい内容でもあるのが悩ましいです笑
9〜10月：現場実証、バグ修正、機能追加要望対応
いよいよ9月、年初につづき泊まり出張で現場に張り付く日々が始まりました。
ここでバグがあったり、機能改善要望のフィードバックをダイレクトにユーザーである作業者からもらえてやりがいがあった反面、スケジューラが作成した計画に従わなければならないことに反発する作業者も少なからずいて、UIから開始・完了ボタンの入力を面倒がってなかなかやってもらえないケースもありました。
そんな中発生したパフォーマンス問題の対応に追われることになったのが大変だったので紹介します。
パフォーマンス悪化に対する取り組み
これまでは開始・完了ボタン連打されることを想定した作りにしていなかったので、実績登録後の最新状態を即座に画面に反映させるために、処理のあとに SWRの mutate()（ミューテーションと再検証） を行っていました。
それがまずく、リアルタイムの実績登録を面倒がった怠惰な作業者が、上から下にボタンを一斉に連打して一度の操作で済まそうとした結果、膨大な量のmutate()が走ることになり、あっという間に統合サーバー（Windows Server）のCPU・メモリ負荷率がパンクしてしまい、職場長や管理職など他のユーザーに迷惑がかかり、結果DBコネクションが設定最大値をオーバーしてエラーになる、みたいな副次的なトラブルも発生するなど、カオスな状況が頻繁に起こりました笑
行った施策としては、実績登録後のmutate()をやめる以外にもいくつか行いました。
ポーリング周期（5秒）ごとに大量データをfetchするのをやめ、最新更新時刻保持用のテーブルを作成し、そこを見に行くようにした
テーブル構成はこんな感じ。
id（FastAPIのORMのための便宜上。1のみ）updated_at
ひとりの人が連続して開始・完了ボタンを押されてもfetchを連続してしまわないように、更新されるのはこのupdate_atのみとなるようにしました。
次に10〜20台（職場によっては今後もっと増える予定）ある作業者のブラウザが5秒ごとにfetchするのはこのupdate_atの値のみとし、この値に変更があり（各ブラウザでuseMemoで保持した値と比較）、かつ now() との差が5秒以上だった場合、に画面更新に必要な計画テーブルに実績テーブルと各マスタテーブルを LEFT JOIN した結果をAPIから受け取るようにすることで対応しました。
画面UI描画に必要なデータを取得するAPIを高速化
上記により、画面UI描画データをfetchするAPIへのアクセス頻度を減らすことができましたが、上記updated_atカラムの値が更新されると数十のブラウザが一度に画面UI描画データ用APIにfetchする状況は変わらないため、ここを改善するために予めテーブルを作成することにしました。
具体的には
- マテリアルビュー＋（実績テーブルに変更があれば）5秒ごとにリフレッシュ
- POST、UPDATEトリガーを実績テーブルに付加し、トリガー機能により画面UI更新データAPIがfetchする「計画テーブルに実績テーブルと各マスタテーブルを LEFT JOIN した」テーブル（
task_summary）を更新する
を検討し、後者を取りました。
PostgreSQLのトリガー機能を使うのは初めてでしたが、実績テーブルが1件でも追加または更新されると、もれなくtask_summaryも更新されることを確認できました。
これらの施策により、現在は落ち着きを見せていますが、今後もパフォーマンス改善のアイデアがあれば問題になる前に事前に策を打ちたいと思っています。
（EXPLAINを読んで最適なインデックスを張ったり、パフォーマンス改善に有意な機能追加が行われた PostgreSQL 18 へのアップデートはもちろん行いました）
11〜12月：全体進捗管理ダッシュボード開発
これは経営層が欲した機能で、時間が限られる中突貫で作り、なんとか先方の「12月頭にはほしい（見た目はあとからでもいいので」という要望に応えることができました。
（自分がこれで監視される側だったらなかなかしんどい気がします…）
右下の設定ボタンで遷移する設定画面からは以下の項目を変更できるようにしていますが、中でも以下の要件の実装は勉強になりました。
無効なIPアドレスが入力されたときの対応（Promise.allSettled関数）
これはひとつ勉強になったことですが、設定画面から無効なIPアドレスを一度入力されると、それぞれの統合サーバーのIPアドレスを取得してPromise.all([A課のURL, B課のURL, ...])でデータfetchしていたため、ひとつのURLでfetchに失敗するとすべてで失敗したと見なされ、エラー画面になるという問題がありました。
今回新たにPromise.allSettled()関数というものを知り、成功したものだけ表示させるような処理をres.status === "reject"の条件分岐で処理できることを学びました。
毎日の計画遵守率を算出して格納する日次バッチ処理の定期実行時刻の動的変更
今回日次バッチ処理を行う内容は「DB間データ移動」だったので、APIは作らずDBのFUNCTIONを作成し、それをタスクスケジューラからpsqlコマンドで毎日◯時に呼ぶようにしました。（Linuxだったらpg_cronという拡張が使えたようですが、Windows用のPostgreSQLではインストールできないことを知りました）
設定画面から設定値をPATCH処理する際に、FastAPIからタスクスケジューラの設定変更を行うコマンド操作（schtasks）を行うようにしたことで、所望の動作をすることを確認できました。
取り組んだこと（学習編）
Cloud Pratica
10月末に入会してから、平日も休日もほぼ1日も欠かすことなくAWSの学習をハイペースで継続してきました。（10月以降少し落ち着き、残業しなくて済んだのも大きかったです）
入会前にもAWSの資格学習はCLF、SAAとしていたのですが、用語暗記の要素が強く、「これがどのような機能要件や非機能要件で役に立つのだろう？」という疑問が晴れず、モチベーション高く学習できていたとは言えなかったと思います。
それが、Cloud Pratica ではりょうまさんが「（僕が6年の試行錯誤で見つけた）ベストプラクティスはこうです。なぜなら◯◯◯だから」といった感じで理論的かつ体系的に学ぶことができるので、理解の深まり方が独学でやっていたときとはまるで違うし、何より他の多くの受講生も言っているように、「中毒性のあるように絶妙な塩梅で課題の粒度や難易度が考え抜かれている」と本当に思います。
その中でも特に、ECSについてはECSどころかDockerすらそこまで詳しくない自分がこんなにスムーズに理解できるとは思ってもなかったので、動画解説に出てくる例えだったり、理解のために最低限押さえておくべきワードだったりの解説が本当にすばらしいなと思いました。
ECSタスクをECSサービスに乗せて運用することで、ECSタスクがまるで生き物のように、生まれたり消えたり、タスク定義のバージョンを変えてデプロイしたら新しいバージョンのタスクがにょきっと生まれ出してはその後に古いバージョンのタスクが消えていく様子だったり（＝ローリングアップデート）、すごく楽しい学習体験でした。
これは独学だったら間違いなくありえない学びだったと思います。
それだけでなく、AWSにデプロイするバックエンドのソースコード（Goで書かれています）がまた学びの宝庫なのも驚いています。
ひとつはMakefileによるDockerイメージのビルドからECRへのプッシュまでを効率化したり、コマンドを細分化して分割しやすい設計だったり、複数の階層にMakefileを置き、継承（include）させて必須の処理とアプリごとに必要な処理を分ける設計など、仕事でAWSやクラウドを使っていなくても今の現場のソースコード管理に活かせそうだと思いました。
（というかすでにCI/CDの改善方針が見えてきているので来年早々に取り組みたい内容が浮かんできています）
もうひとつはクリーンアーキテクチャについての学びで、今までレイヤードアーキテクチャとクリーンアーキテクチャの違いがいまいちわかっていなかったのが、知らない人に説明できるレベルにはなれたかなと思います。
これはりょうまさんが勧めている、Cursorに課金してソースコードをひたすらAIに壁打ちする、という指針を出してくださったおかげで迷いなく課金してフル活用できていると思います。
そのほかにもグレースフルシャットダウンとゴルーチンについての知識だったり、Go言語のポインタについての理解も少しばかり深まり、2026年は腰を据えてGoの習得に力を入れたいと思っています。
FBC
年初は「今年中に卒業」を掲げていましたが、ダメでした・・・笑
というか去年にも増して仕事が忙しくなったことに加え、下に書いたプライベートも色々あったため、チーム開発を半分くらい進められただけでも自分としてはよくやった方かなと思います。
印象に残っているイシューは以下で、自分が「あったらいいな」と思う機能を実装してそれを他の方にも喜んでいただけたことがとてもうれしかったのと、機能追加するためにDBスキーマを変更してそのDBマイグレーションを本番環境にも適用する一連の流れを学べたことが実践的でとても良かったです。
検索に「自分のもののみ」に限定する機能が欲しい · Issue #8274 · fjordllc/bootcamp · GitHub
卒業後に就職したかどうかなどを登録できるようにしたい · Issue #8176 · fjordllc/bootcamp · GitHub
そのほか、「マスタリングTCP/IP 入門編」「コンピュータシステムの理論と実装」の2つは継続して輪読会を続けてこれたのは、モチベーションの高いメンバーに恵まれているからだと思うので、本当にメンバーには感謝しています。
（自分だったらここまでの深掘りや考察はとてもできないと思うので）
取り組んだこと（プライベート編）
2025年は例年にくらべて色々ありました。
持ち家を法人名義に
2025年最大の成果がこちら。 これによりお金の心配がかなり小さくなりました。
持ち家にかかる住宅ローン返済や、修繕積立金などが高額で、自分のサラリーだけでは2人子どもを私立中高一貫に通わせることが厳しい状況でしたが、それを丸々法人が肩代わりするようにできたことで、個人収支がかなり楽になりました。
（その分法人は大赤字ですが、10年めいっぱい赤字を積み上げて、自宅なり所有不動産を売却した利益と損益通算するので問題なしと考えています）
法人に対し社宅購入費用として融資（金利は住宅ローンの0％台から2％台に上がりましたが）してくださった某信用金庫様には本当に感謝です。
長男の中学受験合格
奇跡的に？！長男が第一志望の私立中学に合格できました。
小5に急に「受験したい」と言い出し、その時点の偏差値は35。←SAPIX偏差値じゃないです苦笑
自分は教育熱心でもなく子どものやりたいようにやらせるスタンスですが、さすがに見兼ねて冬休みは毎日算数の鬼特訓をするはめになりました（自分の冬休みの学習計画がパァになりました）
年100万円の学費が6年間かかるのは痛いですが、子どももゆとりの私立でのびのびと彼女も作って楽しんでいるようでよかったです。
ひたすら大阪万博へ通いつめた
万博へは合計12回も行くことができました。ほぼ毎月2回ずつ安定して通っていたと思います。
きっかけは会社の抽選で当たったことでまだ空いていたGWに一度行き、その後通期パスを家族全員分買って通い倒せたのはいい思い出になりました。
途中で万博アプリをハックできることに気づいてしまい（簡単なITスキルで）、大人気パビリオンである「モンハン」にも2回行けたりなど、ITに詳しくなると人生も豊かになるんだと今の職に就いてよかったと思えましたｗ
10歳の息子とヨーロッパ2人旅
某ルートで会社員をしながらスペインのデジタルノマドビザが取れるかもしれない可能性に賭けて、はるばるスペインまで足を運びました。
ひとりで行くつもりでしたが、小4の息子が「僕も行きたい」ということで父子2人旅に行ってきました。（一緒に塾に行っている友達が毎年スペインにサッカー留学しているのに感化されたみたいです）
詳しいことは年末執筆予定のブログ（note）に書く予定なので、とりあえず画像を仮置きしておきます笑
カンファレンスに色々行った
RubyKaigiとTSKaigiの参加ブログは書いたのですが、PyCon JPのブログはまだ書けていないので、年末休みに必ず書きます。（PyCon事務局様より往復交通費と宿泊費用を援助いただき感謝です）
RubyKaigi 2025 に行ってきました（2023に続き2回目） - 40代プログラマーの世界線
TSKaigi 2025 に初参加してきました！ - 40代プログラマーの世界線
2026年の目標
新しい部署に異動する（2026年最大の目標！）
どんなことをやっている部署？
ひと言でいうと「クラウドのデータ分析基盤を開発している」部署です。
- 自社製品からのデータを収集し、
- Google Cloud のBigQuery や VertexAI、生成AI の Gemini などを使って可視化・解析し、
- 製品企画や販社にわかりやすい形でフィードバック
を担っています。
この部署は人を募集しており、
などを進めたいらしいです。
実はこの部署（というか本部）、僕が今の職場に異動になる前にも狙っていたのですが、当時は経験豊富なメンバーしか門を開けてないと言われ、断念した経緯があります。
ただ、それから今の部署でそれなりの経験は積めたので、満を持して再チャレンジしようと思っています。
（異動を確実に成功させるために）面接でアピールできる学習経験を得る
募集要項は以下が書かれています。（※ぼかしています）
- 求める人材
- 今後必要な知識・スキル例
- ソフトウェアエンジニアリングの知識や実践経験があるとなお良い
- ソフトウエア設計・実装に関する知識・経験 （Python、java、kotlin、Javascript、Objective-C/Swift等）
- クラウドシステムに関する基礎知識、開発経験（AWS、GCP、Azure等）
新しい部署で必要な知識は Cloud Pratica のカリキュラムですべて学べる気がしています。なので以下の目標でカリキュラムを進めていくつもりいます。
- 年末までに・・・AWS実践コース修了
- 2026年2月末までに・・・Terraform 2コース修了
- 2026年3月末までに・・・Google Cloud基礎コース修了、実践コースをいけるところまで、異動願いを出す
- 2026年4月・・・面接に挑む
ほか、
に加えて、Cloud Pratica で以下を学びさらにバックエンド-インフラ領域（上の募集要項にある「ソフトウェアエンジニアリング」）に磨きをかけて面接に臨みたいと思っています。
今の開発アプリを手離れさせる
2026年7月からの異動を狙っているので（Cloud Pratica の学習が順調に進んだら前倒しする可能性あり）、それまでに今抱えている開発を手離れさせる必要があります。
「きたろうのコード、めちゃくちゃやん・・・」
と思われて離れたくはないので、以下の項目はきちんと整備して発ちたいと思っています。 （もちろん新規開発は来年もずっと続くので合間見て、にはなりますが）
CI/CD
今はそれぞれ統合サーバー（Windows Server）にリモートデスクトップ接続して、
- Next.js・・・ビルドしたファイルを入れ替え
- FastAPI・・・ローカルのコードをそのまま上書き保存し、アプリケーションを再起動
としていますが、この作業は間違いなくCI/CDパイプライン構築により効率化できると思うので、mainにマージしたら自動で置き換わるような方法を構築したいです。
自動テスト
言いにくいですが現状自動テストをまだ書けていません汗。
3日ほど、つかの間の休息ができてそこで書きたかったのですが、CI環境下でpush時に自動テストを実施する基盤構築のためにDocker化するつもりでしたが、社内プロキシを突破できずにまた忙しくなりそのまま放置している状況なのを異動までになんとかします。
Docker化
上に書いたように、デプロイ先がWindows Serverであっても、CI/CDに乗せるためには必要なので 入門 Docker で学びつつ進めます。
Cloud Praticaの課題
異動が決まった（or決まらなかった）後もCloud Praticaで学べる技術は山ほどあるので、（特にまだ両手で数えるくらいの受講生しか突破できていないという）Kubernetes応用コースはなんとか食らいついて突破したいです。できれば全冠達成したい！
FBCを卒業する
チーム開発でパフォーマンス改善のイシューをやらせてもらっているので、普段なかなかできないオブザーバビリティを学ぶチャンスと捉えてしっかりやり切りたいと思います。
自作サービスについてはすでにエレベーターピッチで OK をいただいている、LLM関連のサービスとして（ヤフコメに出てくるような）「要約すると◯◯」を毎日配信するDiscord Bot を作る予定です。
FBCを卒業する最大のメリットはいっしょに輪読会できる頼もしい仲間の存在だと思うので、なんとか卒業してコミュニティにあやかりたいと思います。
さいごに
昨年に書いた2024年の振り返り記事では、わりと絶望というか諦めムードが漂っていました。
そこから1年が経ち、お金の問題は持ち家を法人名義にできたことでだいぶ軽減されました。
技術面、キャリア面ではりょうまさんがCloud Praticaを立ち上げてくださったことで40代の自分でも目指せそうなロールモデル（＝一筋の光）が見えたのはとても大きかったですし、審査にパスしてCloud Praticaで学べる環境に飛び込めたのはとても大きな変化になりそうな気がしています。
入会時の面談でりょうまさんが話してくださった、「きたろうさんはせっかく大手にいるので焦って転職するより今の職場でスキルアップして、大手のクラウド開発職を渡り歩くキャリアを歩んだほうがいい」という言葉がとても刺さりました。
日々の学習サポートも含めりょうまさんにはとても感謝しています。
40代なこと、加えて生成AIまわりの進化の激しさも増しているので、この先何もしないとどんどん市場価値は下がっていくと思うので、2026年も足を止めずに走り続けたいと思います。
最後まで読んでいただきありがとうございました！
フィヨルドブートキャンプでReactを学んだおかげで本業の新規アプリ開発にReact（Next.js）を採用できた話
※本記事は フィヨルドブートキャンプ Advent Calendar 2025 | Fjord Calendar の3日目の記事です
2日目の記事は今年めでたく卒業された kyokucho1989 さんの フィヨルドブートキャンプの卒業とこれからのこと - マトリョーシカ的日常 です
2025年は本業でがっつりReact（Next.js）を触れた1年でしたが、プログラミングスクール FJORD BOOT CAMP（フィヨルドブートキャンプ）（以下FBC）で React のカリキュラムを学べたおかげでスムーズに採用できたと思うので、その経緯やこんなアプリを作ってるよ〜の紹介をしたいと思います。
自己紹介
某メーカー（大手です）で新卒から働いている正社員・40代の きたろう といいます。
埼玉住みなのに今年は大阪万博に通期パス買って12回行きましたｗ
職場は生産技術本部のソフト開発部隊で老若男女20名ほど、北は青森、南は大分まで全国に拠点があるInc.やグループ会社の生産データ（センサデータや装置データ、人作業など）を収集・分析・可視化するアプリやデータ基盤の開発や、ネットワーク構築をメインにやっています。
いわゆる生産現場の DX を進めている職場になります。
職場で使っている技術は最近だとReact（Next.js）、Vue、Python（FastAPI含む）、TypeScript、Node.js、C#（WPF、.NET Framework）、PostgreSQL、Grafana、KNIMEなどなど。
自分の技術スタックは2025年初でVue 2年、FastAPI 1年、C#1年。React経験なし。
FBCに2023年1月に入会してRailsやJavaScriptを学んでもうじき3年になります。
FBCでのReactプラクティスの概要
公式チュートリアルの チュートリアル：三目並べ – React と Reactを学ぶの「UI の記述」「インタラクティビティの追加」「state の管理」「避難ハッチ」をひたすら読みます。
正直50時間以上はかかったと思います。とてもしんどかったのを覚えています。
けどこの土台作りをおろそかにしなかったおかげで、後に用意されているメモアプリ（カスタムフック切り出しやContextAPIによるログイン機能あり）を作成するのですが、Reactを学ぶにすべてやり方が載っているのでインデックスのごとく戻って確認するだけであっさりできたのを覚えています。
そのあとは SWR というライブラリのドキュメントをこれまたひたすら読んでいきます。
これも「React を学ぶ」ほどではないのですが、それなりの量でした。
そんな中で見つけたポーリングに関する機能（自動再検証 – SWR）が当時の自分にとって衝撃だったのを今でも覚えています。
「こんなことがライブラリの機能ひとつでできてしまうのか・・・」と。
このときの体験が、このあとに説明する本業の新規アプリ開発で生きることになります。
※ちなみにFBCの学習プラットフォームにもプッシュ通知機能がよくて気になりメンターの駒形さんに質問したことがあるのですが、SWRを使っているとのことでした （フォローしている受講生が日報を提出したときなどに即座に通知として反映されます）
本業で今年開発することになったアプリの紹介
ひとことで言うと、「社内向けの作業指示・実績登録アプリ」です。
画像のイメージはこんな感じ↓ （空港の発着案内板をイメージしました）
- 共通（職場長向けUI）
- TaskBoardコンポーネントに始まり、大きくTaskFilterコンポーネントとTaskListコンポーネントからなる
- TaskFilterで日付や職場、作業者などを選択して作業を絞り込み
- 作業者を選択すると下記の作業者用UIに切り替わる
- TaskListでは選択した日に開始または完了予定の作業（とまだ終わっていない前日以前の作業も）が並ぶ
- 各作業に対し計画上の開始時間、完了時間と、開始ボタン・完了ボタン、中断ボタンが表示されている
- 開始ボタンを押すと「開始」の文字が押した時刻に変わる。完了ボタンも同様。
- 実績テーブルにPOST・PUT送信される
- 開始や完了は同ボタンで取り消しも可能
- 中断ボタンを押すと再開ボタンに変わり、中断テーブルに中断時刻および再開時刻記録される（実作業時間をあとで集計するのに使用）
- ポーリング周期は5秒
- この機能の実装に上で触れたSWRに大変助けられています
- 作業者は手順書（Excelマクロ）を別ウインドウで開いていることが多いので、非アクティブでも表示が即時反映されるのはUX的によいと感じます
- 計画に対し◯◯分（設定ファイルで外出し）だけ開始、完了が遅れたらボタンの色が変わる（青→橙）
- 前工程が完了していないと（作業をできないことを作業者が見た目でわかるように）ボタンの色が薄色になる
- 主に2画面を三項演算子で分け、下位コンポーネント（開始ボタン、完了ボタンなど）は極力同じものを使う
- 画像は「前段取り」「生産」「後段取り」となっているが、職場によっては「生産」のみの職場もあるため、職場フィルタでUIを切り替える
- 日付（デフォルトは今日）を選択すると、先の予定も表示される（その分描画は遅くなる）
- 「完了済み」チェックボックスで完了済みの過去作業も表示できる
- 開始ボタン、完了ボタンを押したら（見た目上は）即座に更新され、裏でデータベースのPOST、PUTが行われ、ポーリングで表（フロントエンド）と裏（バックエンド）が一致する ←これを楽観的UIということを知りました
- これには苦労話があり、ボタンクリック→即mutate（ミューテーションと再検証 – SWR）と当初していたら、ある作業者が（入力作業をまとめてやろうと）ばーっとボタンを次々に押していった際にCPU・メモリ負荷が激増して固まってしまったり一部データ入力を取りこぼしたりするなどが起きたためこのような対応を取りました💦
- 作業者向けUI
- 作業者選択時に表示
- 職場長UIのような横並びではなく、前段取りや後段取りも縦並びになる
- 将来的にタブレット化を見据えるため、フォントサイズやボタンサイズをどでかくする
React採用に至るまで
今振り返ると、ここまで機能が潤沢になる（注：まだまだIssueは山積みです）ことが想定ができていれば React（or Vue）一択なのですが、当時は想定できていなかったので、「ダッシュボードといえばGrafanaでしょ」という自職場のムーブにあやうく乗っかるところでした💧
Grafana: オープンでコンポーザブルなオブザーバビリティプラットフォーム | Grafana Labs
上のような画面UIを当時はGrafanaでAPI叩いたりできるのかな〜などと構えていたのですが、そんな機能はなく、データベース操作をするには生のSQLを埋め込むしか方法はなさそうでした。 その作業を鬼のように存在する開始ボタン・完了ボタンに埋め込む方法なんかもどう考えても難しそうなかんじです。
1日Grafanaを触ってみて、こりゃだめだとさじを投げ、JavaScript（TypeScript）でやることに早々に舵を切りました。
Vue or React？
自分は実務経験ではReactなし、Vueは2年ほど（うすくですが）触ってきました。 双方向レンダリングのよさもMVVMで以前C#アプリを書いていた経験から知っていたし、Vue2からVue3へリプレイスするという超苦行も経験しています。（思い出したくないくらいに地獄でサービス残業を何十時間もやりました・・・）
そんなスキルセットの自分ですが、それなりにモダンJavaScriptを学ぶと、Reactの方が覚えることが少なくて配列の取り回しをよりJavaScriptぽく書けるのが魅力的だなとはFBCで学習していて感じていました。
くわえてキラーライブラリであるSWR（上述）の存在。
あとはReactに明るい同僚がそれなりにいることもあり、実務未経験ですがReactを採用することにしました。
結果的にはこれがよかったと今でも思いますし、機能拡張がVueにくらべて楽だな〜という実感があります。（もちろんコンポーネント設計をしっかりできていればですが）
ちなみに、FBCではHotwireなるものがとても流行していますが、こちらは以下の理由で候補に上がりませんでした。
- 職場にRuby、Railsを使っている人がひとりもいない
- ポーリングや開始ボタンの機能を動的に実績登録用、実績取り消し用、と切り替えられるイメージが湧かない（or湧いたとしても学習コストがReactよりはるかに高くつきそう）
- 仮にHotwireで作り上げたとしても属人化してこの先引き継げなくなりそう
- 個人的にRubyよりTypeScriptの方が書きやすくて好き（TypeScript >>> Python ≒ Ruby）
React（Next.js）でアプリ開発してみて
結果的にReactで書くことの楽しさを感じています。 羅列すると、
- Next.jsについては、機能的にVite + React でもよかったと思うけど、AppRouterやSSRがどんなものかを知ってみたかった（残念ながらまだサーバーコンポーネントの出番はなし）
- SWRが便利で、よしなにキャッシュしてくれたりもするので、今のところUX（ユーザー体験）のよいアプリにできているのはまちがいなくこの人のおかげ🙏
- （付属で付いている）TailwindCSSも最初は使いづらかったけど、使っていくうちにこれさえあればUIフレームワークなしで十分業務アプリレベルならリッチにできることを理解しました。
おわりに
業務で必要になってから学ぶというのもひとつの考えだし、その方がきっと効率よく技術獲得できるとは思います。
実際、仮にFBCでReactを学んでいなかったとしても、Vueでなんとかしていたと思います。
それでも100時間という時間をかけてしっかりReact学習の備えができたおかげで、
- SWRという職場でReactを書いているメンバーも知らないようなライブラリのよさを先んじて知れた
- 依頼元や一緒に仕事を回しているチーフ（注：アプリ開発は実質ひとりでやっています）の満足いくスピードで開発できている
- キャッチアップコストに追われることがないので精神的なしんどさなく楽しく開発できている
- AIを活用で開発していて、あきらかに可読性が悪かったり、設計がいまいちなコードを提示してくることもまだまだ多く、自ら知識をもっておくことで「ここの部分は◯◯の理由でこうしてほしいんだけど？」と軌道修正する監修スキルは知識がまったくないと提案できないと感じる
などのメリットは、FBCでがっつり学べたおかげなので、（特にカリキュラムにSWRを入れてくださったこと）とても感謝しています🙏
さいごに、本アプリは期待されている社内プロジェクト活動の一環であり、具体的には、
- 人作業を可視化してスキルマップを日々更新する仕組みづくり（たとえば標準時間1時間の作業をAさんは30分でできてBさんは1時間かかる場合、Aさんは2、Bさんは1とマッピングされる）
- スケジューラによりボトルネック工程を見える化（その工程ができる人を育成すれば製造リードタイムがどれだけ短縮できるかをシミュレーションする等）
- 今年すでに数職場に導入済みで、来年以降も対象職場の拡大が見込まれ、それだけ期待も大きい
という感じで、とてもやりがいのあるテーマに携われています。
今日話したことはUIのごく一部で、UI以外にもデータ構造やAPIのクエリのパフォーマンスチューニングやPostgreSQL機能の活用（マテビューやトリガー、cronなど）、RFIDによる自動実績登録機能で採用したMQTTやWebSocketについてなどなど書きたいことが山ほどありますが、それは別の記事で書きたいと思います（余裕あれば）。
※明日、 フィヨルドブートキャンプ Advent Calendar 2025 | Fjord Calendar の4日目の記事はマスタリングTCP/IPの輪読会も一緒にしている よこさん が担当します！
楽しみにしましょう〜🙌
※12月4日追記：公開されたのでリンク貼りました！
TSKaigi 2025 に初参加してきました！
先月のRubyKaigi 2025 につづき、TSKaigi 2025 に参加してきました。
私は某製造業で社内向けアプリの開発を（実質ひとり体制で）しており、今年から（正確には先月から）作業指示を表示したり実績を登録できるアプリをNext.jsで書き始めており、TypeScriptを1年以上ぶりに触っています。
そんな感じでTypeScript歴は浅いのですが、前から気になっていたTSKaigiに今回初めて参加したので、そこで感じたことや学んだことを早いうちに書きたいと思います。
参加のきっかけ
uhyoさんのXポストで案内を見かけました。
「（仕事で使わないのに）RubyKaigiに2回も参加するんだし、（一応仕事で使っている）TSKaigiもせっかくだし参加してみよう」くらいの気持ちで『懇親会あり』での参加を決めました。
金額が5,000円（懇親会別途+3,000円）と安価だったこと、仕事を1日休むだけで参加できる金・土日程かつ東京開催だったことも後押しになりました。
私のTS歴
- uhyoさんのブルーベリー本は読了済
- 仕事で一応TypeScriptは触っている（保守運用中のVueアプリや先月から開発しているNext.jsアプリはTSモードON）
- が、プリミティブ型やオブジェクト型（DBスキーマに沿った形）以外使いこなせないany大好きマン
- 当然型パズルは読むことも作ることもできない
というレベル感なので、講演の内容がついていけるか不安だったし、懇親会ではぼっちになる可能性も覚悟しての参加でした。
（なので間違ったことを書いてしまうかもしれませんが、間違いを見かけた際にはご指摘いただき次第速やかに修正したいと思います）
事前準備、予習
一切せずに臨みました。
強いて言えばプログラミングスクール（フィヨルドブートキャンプ）内でブルーベリー本輪読会がちょうど6章の後半だったので、参加させていただき、タグ付きユニオン型、keyof型、Mapped Types、Conditional Typesなどを復習しました。
今振り返れば、直前勉強会くらいは参加すればよかったと思います。
参加してみて
技術トレンド
参加するまで知らなかったのですが、「tsgo」、つまりTypeScriptコンパイラが JavaScriptベースのtsc からGo言語ベースに変わることに、界隈は相当ざわついている様子でした。
※以下のスライド（2日目基調講演のberlysiaさんのスライド）の24ページ目がわかりやすいです
※Microsoftからの発表内容
このGoに置き換えることでコンパイル速度が格段に上がる話は、先月参加したRubyKaigiでもあったのですが（pixiv末吉さんの発表）、「MicrosoftのTypeScript」が「GoogleのGo」を採用するという意思決定が不思議というか面白いなと感じました。
このTypeScriptの流れについて、uhyoさんも以下のように呟かれていました。（Xポストを見つけられなかったため、ニュアンスが違っているかもしれません）
今後しばらくTypeScriptは停滞期に入るかもしれない
上記について、直接uhyoさんに伺ったところ、TypeScriptのメンテナの多くのリソースがGoリプレイスに割かれており、今後も当面それが続く状況からすると、新規機能のリリースはその間そこまでされなくなるだろう、とのお考えでした。
また、懇親会でお話しした方の中には、「結局TypeScriptも低レイヤーのGoやRustになってしまうのか…」と懸念されている意見もありました。
これについては、以下のスライドにあるように、「TypeScript自体が見えなくなる」方向に行くのかな、と理解しました。（内部では動いているけど開発者には見えない？ちょっと難しい…）
笑った#TSKaigi2025 pic.twitter.com/nBeJdH0t2I
— 鹿野 壮 Takeshi Kano (@tonkotsuboy_com) 2025年5月23日
また、前回のRubyKaigiの記事でも書きましたが、Go言語（特にゴルーチン）についてはすでに「Web技術入門」で触り始めていますが、今年は本気で学ばないとな、という気持ちでいます。
まずは懇親会で知り合った方に教えてもらった「Effective Go」から取り掛かりたいと思います。（年末）
学んだ知見
コンポーネント設計について
以下の発表で、「論理的凝集より機能的凝集」という話から始まり、「論理的凝集がよくないのは当たり前だよね」と思っていたところ、以下のクイズ？でまんまと「そりゃAでしょう。上の処理がコピペで重複しているしDRYじゃないし。」とまんまとハマりました（実際仕事で書いているコードもAのように書いているコンポーネントがありました）。
というわけで明日からさっそくリファクタリングしようと思います。
クリーンアーキテクチャ、関数型プログラミング
クリーンアーキテクチャと関数型プログラミングは個人的に学んでいて興味ある分野だったので、以下2セッションに参加しました。
『Pragmatic Functional Programming in TypeScript』（※資料未公開）
クリーンアーキテクチャや関数型プログラミングについて丁寧に解説してくれ、お二方ともt-wadaさんのこちらのスライドをおすすめされていた点で、クリーンアーキテクチャと関数型プログラミングがTypeScriptのバリデーションやコンポーネント設計において有効なプログラミング手法であることを感じることができました。
クリーンアーキテクチャについては、プレゼンテーションの分離とDB層の分離については理解できたのですが、ドメインロジックの分離について理解を深められたら、仕事のコードをもっとよくできる気がしているので、資料をあとでじっくり読み込みたいと思います。
同様に、関数型プログラミングを使ってのリファクタリングにもチャレンジしたいと思うので、こちらまだ資料未公開ですが公開されたら関数型プログラミングの原則のところから理解を深めたいと思います。（「なっとく！関数型プログラミング」はだいぶ積読のままなので読もうという動機になりました）
AI活用
生成AIを使った発表も目立ちました。
自分でも存じ上げているmizchiさんの発表はとても面白く、本当に30分があっという間でした。
- TDDがAIコーディングにおいてますます重要になっていく
- プロンプトエンジニアリングがますます重要になっていく
が特に刺さりました。
https://tskaigi.mizchi.workers.dev/
tskaigi の感想というか雰囲気
— mizchi (@mizchi) 2025年5月25日
- AIは使ってるのはもはや前提。前置きなし
- 登壇側は理解度はともかく checker.ts を読もうとしてる
- 型パズル/CompilerAPI/ts-morph のAST操作が華
- 例外処理どうするかの共通認識があり大抵 neverthrow 試してウーン状態
- 誰もclass使ってない
また、Ubieが少し前に記事を書かれていた「デザインシステム」というワードが印象に残りました。
具体的には以下の発表で、「プロンプトにより『解空間』を狭めていく」という考え方がなるほど〜と思いました。
mizchiさんの「プロンプトエンジニアリングが大事」という主張と近い気がしました。
懇親会やサブイベントについて
朝ヨガイベント（stmn社主催）
ヨガを初めて行い、「呼吸の大切さ」と「呼吸をするときの姿勢の大切さ」を知ることができ、参加してよかったです。
また、スタッフの女性と少しお話しさせていただいたのですが、その方は先月から営業から未経験エンジニアとして挑戦されているとのことで、同じく異業種から学習中の立場として興味を持ちました。
聞くところでは、CTOの方が「2年やってものになるか試してみるプロジェクトの第一号であること」「生成AIが進んだので一人前にできるかもしれない」との考えのもと白羽の矢が立ったとのことで、今後がとても気になりました。
※ちなみに私が学んでいるフィヨルドブートキャンプでは「生成AIは禁止」というガイドラインができて日が浅いので、尚のこと気になります
企業ドリンプアップ
Diniiさんが提携しているお店『俺の魚を食ってみろ 神田店』で、同社のアプリから注文し放題（つまり好きなメニュー食べ放題）でとても気前がよかったので、同社のことは覚えました！
プチミートアップ（Day2 17:10〜17:50）
私と同じく「異業種からの転職者」の方とお話しさせていただきました。
話しやすい雰囲気を設定してくださり、運営の方に感謝します。
トークテーマは「TypeScriptまわりで困っていること」をポストイットで各人がどんどん出していく形式で、
- Reactの勉強会が少ない（Vue Fesのようなものがない）
- 簡単な型しか使えない（複雑な型を書けない・読めない）
- リファクタリングをやらせてもらえない
- React技術の移り変わりが早く不安がなくならない
などが挙がり、わいわい楽しくお話しできました。
その他雑感
発表者の方が発表直前にスライドを共有してくれることが多い
RubyKaigiでは（私の観測範囲では）ひとりも見かけなかったのですが、こうしてくれるスピーカーの方が多くて助かりました。 ChatGPTに食わせて、要約を出力させることで、理解の助けになりました。
ランチ弁当が豪華
豪華弁当が4種類から選べて、2日間配られ（しかも余るので2つ3つと食べていいし持ち帰りもOK）、RubyKaigiやKaigi on Railsしか参加したことのない自分にとってはとても太っ腹だなと思いました。
これからについて
仕事
すぐに仕事のアプリに活かせる技術がいくつもあったので、さっそく取り入れたいと思います。
flat config
主に ESLint に関する文脈で登場する言葉で、2023年に正式導入された 新しいESLintの設定方式 従来の .eslintrc.json などの階層構造ベース（layered config）とは異なり、JavaScriptのコード（eslint.config.js）で設定を直接記述するフラットなスタイルにできる
Style Dictionary
JSONで定義されたデザインルール（色・余白・フォントなど）を、TypeScript向けのコード（ts, scss, json, css, android, iosなど）に自動生成するツール
Zod と Serializer
Zod を入力検証として使うだけでなく、出力整形（シリアライズ）にも使うという設計上の工夫。DBから取得した不要なカラム値を取り除いたり、UIに表示させる形式を整えられる。
ts-pattern（ライブラリ）
タグ付きユニオン型と組み合わせて分岐できる。ネストされた構造に対してもマッチ可能。
学習
今TypeScriptでいちばん課題感を持っているのは「表現豊かな型を自分で設計できるようにしたい」なので、以下の発表にあるような「JSの関数に置き換えて理解するやり方」や「Type Challengesを解くこと」はぜひ取り組みたいと思いました。
（後者のKanonさんは「問題を3周解いたら自分でも問題を作りたくなり、PRを出したらメンテナに就任した」という素敵な話も聞くことができました）
また、tsgoが使われるようになると（v6で試験導入？v7で本格導入の予定との事）、ブラウザが読み込めるためにあえてJavaScriptにコンパイルしているけど、ブラウザが進化してGoやRustを直で読めるようになったらJavaScript自体要らなくなったりするのかな、と感じたりもしました。
そうなるとGoやRustのようなネイティブ寄りの言語を修めておくことは今後ますます重要になっていきそうな気がしました。
イベント参加
React TOKYO というイベントを教えていただいたので、どこかのタイミングでオフラインイベントに顔を出したいと思います。
また、今年は「Kaigi on Rails 2025」に参加予定でしたが、なんとPyCon（Pythonの国内最大のカンファレンス）が同日に設定されていることを知り、どちらに参加しようかチケットが売り出されるまで悩みたいと思います。
さいごに
TSKaigi、思った以上に楽しめました。
来年もぜひ参加したいと思ったのと、TypeScriptやTSKaigiについての情報をこれまで以上にウォッチしたい思いが強くなりました。
最後まで読んでいただきありがとうございました😊
（明日から出社→残業が始まるので今日のうちに公開できてよかった…）
RubyKaigi 2025 に行ってきました（2023に続き2回目）
昨日まで RubyKaigi 2025 に参加してきました。
RubyKaigi は 2023 以来に2回目でした。
今回も前回同様、フィヨルドブートキャンプ（以下FBC）が用意してくれた「フィヨブーハウス」に無償で泊まらせていただきました🙏
2023 に参加したときは、まだRubyを学び始めて間もなく、FBC受講生やメンターの方と親睦を深めるのを主目的で参加しました。
そのときのブログ↓
今回は、以下の覚悟を持って参加しました。
今回が最後の RubyKaigi 参加になるかもしれないつもりで、今年中に卒業するんだという気持ちを奮い立たせること
そのため、初参加の2023のときから以下の「KPT」の意識をもって会に臨みました。
Keep
Problem
- 無理のないスケジュールで動く
前回は飛ばし過ぎたために3日間の長丁場に耐え切れず、3日目の途中で疲れ果てて帰ってしまいました。
この反省をうけ、今回は聴くセッションはなるべく詰め詰めにせず、無理なく3日間参加できるように努めました。
Try
新しい交流
前回はFBC生との親睦を深められた一方で、FBC生で固まるしかできませんでした。
今回は、FBC外の人と積極的にコミュニケーションをとることを目標に掲げ、FBC生がそこまで多くなさそうなイベントに参加申し込みしました。
また、我らが代表の駒形さんとはこれまで直接お話ししたことがなかったので（正直まだオフラインではちょっとこわい）、お話しすることもひとつのミッションとして掲げました。新しいイベント参加
今回が最後の RubyKaigi になるかもしれないので、（この手の陽キャイベントは陰キャの自分は苦手なのですが）「RuryMusicMixin 2025」に参加することにしました。
conference.pixiv.co.jp事前予習
今回はRubyKaigi参加にあたり、
に参加したり、読書したりしました。 中でも、udzuraさんのスライド↓はRubyのしくみがとてもわかりやすく説明されていて、VMやParserのセッションを聴いてみようと思えました。
- AIツールの活用
今回は、知らない言葉が出たときはすぐにAI（ChatGPT）に聞くようにしました。
学んだこと
仕事で、M5Stack（未定）を使った製造業の作業者が持ち歩く用の作業指示・ ＆作業実績入力（作業開始/終了など）用端末のシステム開発を予定していることもあり、今回は組み込みRubyについての内容がもっとも学びになりました。
- 書記素クラスター
ima1zumiさんのキーノートスピーチで出てきた言葉で、「人間が『1文字』として認識する単位のこと」。特にコンピュータ上でのテキスト処理において、「見た目は1文字だけど、実は複数のコードポイントから構成されているもの」（例．🧑🧑🧒の絵文字）を扱う時に重要な概念。
※デーヴァナーガリーの文字は合字（例：「क」＋「ष」＝「क्ष（kṣa）」）からなること - チョムスキー階層
- 言語 2. 文法 3. オートマトン 4. パーサ の4つに形式言語を分類したもの
- LexerとLex State
- Lex State・・・Lexer（文字列をトークンに分類）が文字を読みながら、どのように解釈するかを決める状態のこと
- (C)Rubyとmrubyとmruby/c
- (C)Ruby・・・1MB（PC）
- mruby・・・128KB（ラズパイ）
- mruby/c・・・20KB（マイコン）←OS不要（ベアメタル）
- picoruby・・・ラズパイPico向け。も、yuuuさん発表によりESP32に拡張！
- M5StackでRubyを動かすなら「mruby/c」一択
- mruby/cの競合
- MicroPython・・・Pythonを小型マイコン向けに再実装。ESP32では定番中の定番？メモリ消費でmruby/cに劣る
- JerryScript・・・JavaScriptをIoT用に極小化。Samsungが開発
- Lua・・・非常に軽量かつ高速。C連携が簡単。記述がマニアック？
- 上記競合に対するmruby/cの優位性
- ESP32
中国の Espressif Systems社 が開発した、WiFi・Bluetooth内蔵の高性能マイコンチップ。Wi-FiとBluetoothに対応している点がラズパイPicoにない長所。
- Rubyにおける静的型チェックの3本柱
- WasmとWardite
- GC（ガベージコレクション）
- Immix ・・・「Mark-RegionとBump-Pointerのハイブリッド」によるガベージコレクション（GC）方式
- LXR・・・Lazy Exact Region-based Garbage Collection の略。主に研究論文などで提案された、新しい リージョンベースGC方式
印象に残っていること
- 訳者の島田さん（えにしテック代表）から直接システム設計本を購入させていただいたこと
「システムアーキテクトの意思決定術」は発売前から気になっていた本だったので、@.bookstore at RubyKaigi 2025 で見つけて買おうか迷っていたのですが、「よい本ですよ〜」と声かけいただいたのがまさかの島田さんだったので、これはご縁だと思いその場で購入しました。
同書をRubyKaigi中も休憩スペースや宿で読んでいました。
同書で説明されている「マクロアーキテクチャ」を- コーディネーション（つまりシーケンス図で表されるような処理のフロー）
- 一貫性
- セキュリティ
- 高可用性とスケーラビリティ
で考えれば大枠をつかめることが知れたので引き続きじっくり読みたいと思います。
pixivの末吉さんのGoのGoroutineの話
さいきんGoに興味を持っていることもあり、こちら聴いたのですが、GoのGoroutineを使うことで、従来のRactorの100倍30倍 の処理効率を実現したという話には驚きました。
と同時に（並行処理を驚くほど簡単に書けるという）Goroutineについてきちんと学んでみたくなりました。FBC卒業生の方に意外と認知してもらえていること
ふだんから何気なくXポストにはいいねをしているからか、自分のアイコンを見せると「あ、知ってます」「一方的に知っています」（←むしろこちらが一方的に存じ上げていると思っていた方でした）と言ってくださり、うれしかったです。
Xいいねの草の根活動？をこれからも継続していきます！RubyMusicMixinでの雑談
FBC現役生の方から、「きたろうさんはAIのイメージ」と言っていただけたことで、「やっぱり自作サービス（FBCでの卒業制作にあたるもの）はAIがいいのかも…」と思い至り、その後AIで実現できそうな面白いサービス案が帰りの飛行機内で浮かびました。
少し前に、「MCP（がいかに優れているか）を理解したいから使ったサービスをつくりたいがアイデアが浮かばない…」と日報に書いたところ、メンター（兼FBC代表）の駒形さんに、「使いたい技術をベースに考えたら失敗する。困っていることや解決したい課題から考えるように」との助言をいただいたのですが、ちゃんと課題ありきで考えられたので、実現できればなかなか面白いサービスになりそうな気がします。フィヨブーハウスメンバーの人となりについて知れたこと
対面しないとなかなか話せないような過去のバックボーンなどを知ることができ、共感できる点や見習いたい点がいくつもありました。
話してくれてうれしかったです。企業ブース
前回参加時は、「40代でも採用してもらえるか？」をいろんな企業ブースで聞いていましたが、今回は、技術スタックはシステム構成についてを中心に質問させていただき、勉強になりました。
（多くの自社開発企業では「Next.js＋Rails APIモード」、AWSではECSでKubernetesまでは使っていない、DBはAurora、一部でDynamoを使っているが負債になってしまっているケースも、AIエンジニアは複数のLLMを適材適所使いこなし日々最新モデルの検証をしている、など）やっぱり「FBC」という印籠
知らないアウェイなテーブルでも「FBCで学んでいます」と言うと話が広がるのでありがたかったです。日本一のサウナ「喜助の湯」
2023年、2024年と2年連続日本一のサウナがあることを現地のRubyistの方より教えてもらい、行ってきましたが最高でした。
3種類のサウナがあり、110度の赤の鬼サウナや、炭酸の湯に薬膳湯、さらには休憩スペースで漫画やデスクワークスペースもありました。
さいごに
RubyKaigiに出発する直前では、仕事が進んでいなかったこともあり、「やっぱり申し込まなきゃよかった😭」などと思ったりもしましたが、今回参加したことで思わぬ知識（組み込みRuby）を得られたり、Rubyの技術の幅が広がったり、ふだん話せない人との話やオンラインではできないような濃い話などができて、参加してよかったです。
（門外漢のRubyKaigiに2度も参加するくらいなのだからと）来月TSKaigiに勢いで懇親会付で申し込みましたが、「RubyKaigiはほかのカンファレンスとはちょっと違う」とも聞くので、今回参加して感じた熱量をもって来月のTSKaigiの雰囲気を感じてこようと思います。
2024年振り返り。第一線で活躍するのは少し厳しいかなと感じた1年。
昨年につづき今年も書きます。
40代でもWebエンジニアに転職できるんだ、と希望に満ちていた2023年。
2024年は主に忙しさから気持ちがトーンダウンしてしまい、
- 適性面
実務、FBC（フィヨルドブートキャンプ）のプラクティス両面において、開発力が圧倒的に欠けていると感じた。プログラミングに関する勉強やコツコツ継続することは好きだけど、技術をキャッチアップしたり深掘りする力や、それに対する興味が少し弱いことがわかった。 - 支出面
子ども2人が私立に行きたいという気持ちに応えるには年収は下げられない状況であり、加えて、今年は自宅マンションの修繕積立金が大幅増に（+2.5万円/月） - 収入面
スキルに見合わない年収をもらってしまっている状況（円安によるボーナス増と残業代で昨年から70万円増、ただし当然ながら上司からの評価は高くないので来年は怪しい）
から、今の会社からの転職はなかなか難しいかも・・・と感じるようになったことがこの一年の変化だったように思います。
英語を学び、外資で働く目標は諦めていませんが、どうやって実現するかについての戦略が破綻してしまったので、来年考え直したいと思っています。
続きを読む