※本記事は フィヨルドブートキャンプ 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日追記：公開されたのでリンク貼りました！
