はじめに
この記事は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年も足を止めずに走り続けたいと思います。
最後まで読んでいただきありがとうございました！
