はじめに：準備が整う日は来ない
準備が整う日は来ない。
チャンスが目の前に来たら、まず掴む。
**知識と技術は、掴んだあとに獲得すればいい。**それで問題ない。
この考えに至るまでに、2025年はいろんな意味で“激動”だった。
休職して、自己投資して、環境を変えて、転職し、居住地まで変えた。
Episode 0：前年4月の異動が、すべての前兆だった
会社の都合で異動した。
この時点ではまだ「頑張れば何とかなる」と思っていたけど、今振り返ると、ここから少しずつズレが積み上がっていた気がする。
Episode 1：10〜12月、人間関係で消耗し続けた
10月〜12月にかけて、部署の人間関係で悩み続けた。
年末年始の休みは、休むどころか考えすぎてしまった。
そして迎えた仕事始め。
Episode 2：2025年1月6日、出社目前で引き返した
2025年1月6日。仕事始めの日、職場の近くまで行ったのに、どうしても足が前に出なくて引き返した。
そのまま精神科に向かい、適応障害と診断された。
診断名がついた瞬間、安心より先に来たのは恐怖だった。
「ここからどうなるんだろう」
「キャリアが止まったらどうしよう」
未来が急に真っ白になった感覚がある。
そこから1週間だけ出勤して、1月13日に休職した。
（ちなみに、当時は第三種電気主任技術者（電験三種）まで取っていた。
でも、それでも状況は変わらなかった。“頑張っても報われない”感覚は、思った以上に心を削る。）
学び①：限界になる前に逃げる勇気
この経験で学んだのは3つ。
- 限界を感じる前に、その環境から逃げる勇気を持つ
- 休職は労働者の権利で、使うことは恥じゃない
- 次のステージに行く準備期間として使うのもあり
Episode 3：2月、独学1年半をやめて自己投資した
実は、プログラミングは1年半前から独学していた。
でも、勉強しても「稼げる未来」が見えなかった。自分のロードマップにずっと不安があった。
一緒に学ぶ仲間も少ない。
だから決めた。
「このまま戻っても同じ。環境を変えるしかない」 と。
そして2月、プログラミングスクールに自己投資した。
学び②：独学は下道、スクールは高速
移動に例えるなら、
- 独学：車で下道をコツコツ進む（進むけど遠いし迷いやすい）
- スクール：高速道路で目的地に向かう（再現性があり、迷いが減る）
何より効いたのは、ロードマップと仲間だった。
「次に何をすべきか」が見えるだけで不安は減るし、一緒に走る人がいると継続の難易度が下がる。
Episode 4：4月、さらにレベルの高いコミュニティへ
1つ目のスクールも良かった。
でも、もっと欲しくなった。
- よりレベルの高いコミュニティ
- 転職後も学習できるロードマップ
- SNS発信のスキル
SNSで、同じハッシュタグを付けて発信している“熱量の高い集団”を見かけた（名前は伏せる）。
そこには自分より上がたくさんいて、「この環境で挑戦したい」と思った。
学び③：上が多い環境は、間違いなく伸びる
- 自分より上がたくさんいると、スキルは伸びる
- 基準が上がるから、学習の無駄が減る
- 転職後も学び続けられる設計を手に入れると、目標が「転職」から「価値が上がるエンジニア」に変わる
Episode 5：8月、転職と居住地変更。強くなるために“場所”も変えた
8月、都内スタートアップの自社開発企業でWebエンジニアとして転職し、居住地も変えた。
モダンな環境で実務経験を積みたかった。
強いエンジニアは都心に集まることを知っていた。
エンジニアの母数が多い場所で、交流し、人脈を作れると思った。
そして転職してからの数ヶ月、フロントエンド→バックエンド→一気通貫の開発→現在はAIエージェント開発にも携わっている。
学び④：リスクを見積もって飛び込む。チャンスは一瞬
- 居住地を変えるのは怖い。でもリスク許容度を見極めて飛び込めば、想像以上のリターンがある
- 準備が整うことなんてありえない。チャンスが来たら掴む
- 開発ができるようになるには、爆速で開発できる環境に身を置く。例外はない
Episode 6：転職後（フロントエンド）でやってきたこと
※ここからは、転職後に自分が担当した業務のうち フロントエンド実装 に絞ってまとめる。
6-1. まずは“小さなUI修正”を積み重ねた
実務に入って最初に触ったのは、いわゆる小さな改善が多かった。
- ボタン等の要素の微調整（余白・配置・視認性）
- 表示が崩れていた箇所を、UIとして正しく見える形に修正
- “テーブル表示”になっていない箇所を、テーブルとして見える形に整える
こういう小さな修正は地味に見えるけど、プロダクトの信頼感に直結する。
そして何より、既存コードの癖や、チームの作法、コンポーネントの思想を掴むには最適だった。
6-2. 一番重要なページ（ホーム）のリファクタに着手した
本格的に取り組んだのが、ホームページのリファクタリング。
一番やばかったのは ロジックと表示の混在（肥大化）。
ホームが 500〜1000行 規模で、データ取得・整形・状態・分岐・表示が全部同じファイルに書かれていた。
この状態だと、追加機能を入れるたびに
- どこを触ればいいか分からない
- 影響範囲が読めない
- “ついでに”直したくなるポイントが増えて収集がつかない
結果として、ホームが「触るのが怖いページ」になってしまう。
6-3. リファクタで一番大切なのは“順序”だった
今回のリファクタで一番大切にしたのは、技術選定よりも 順序 だった。
結論はこれ。
先に表示用のコンポーネントを分割し、その後にロジックの分割を考える。
ロジックから先に切り始めると、UIのまとまりが見えないまま分割が始まって、
分割粒度がブレたり、責務が戻って混ざったりして、結局読みやすさが上がらない。
逆に、先に表示を「意味のある単位」で分割しておくと、
- 画面の構造がコード上でも一目で分かる
- どのUIにどのデータが必要かが見える
- 状態をどこで持つべきか判断しやすい
この順で、自然にロジック整理へ進められる。
6-4. 設計で特に気をつけたこと（C/Pパターンの徹底）
ホームは、Container / Presentation パターンに寄せて再構成した。
今回は ページ単位でディレクトリをまとめる 方針だったので、置き場所だけで責務が判断できるように、構造を固定した。
まず、リファクタ後のディレクトリ構造はこうした。
features/
home/
containers/
HomeContainer.tsx
presentations/
HomePresentation.tsx
components/
HeroSection.tsx
KpiSummary.tsx
RecentUpdatesTable.tsx
hooks/
useHome.ts # ※必要なときだけ（切り出しすぎない）
api/
homeApi.ts # ※任意（API呼び出しの責務）
この構造にしたことで、初見でも
- 「ロジックは containers」
- 「表示は presentations」
- 「UIのまとまりは presentations/components」
と迷わず追えるようになった。
次に、C/Pの関係性（呼び出し方向）も 一方向 に固定した。
✅ ここでの重要ルール：C → P のみ
❌ PがPを呼ぶ / CがCを呼ぶ 構造は作らない
（境界が曖昧になり、分割する意味が薄れていくため）
この前提を作った上で、具体的に守ったルールは以下。
① 表示コンポーネントはUIに沿って作成（意味のある単位で適切に分割）
「分割できそう」ではなく、UIのまとまりで切る。
ユーザーが1つの塊として認識する単位に合わせることで、変更に強くなる。
② C/Pの並び順を崩さない（C→P→C→PはOK、C→P→PやC→C→PはNG）
- C→P の関係だけにする
- PがPを呼ぶ / CがCを呼ぶ 形は作らない
理由はシンプルで、そうなると 分割する意味がなくなる から。
境界が曖昧になると、また“混在”に戻っていく。
③ hookに切り出す時は慎重に（何でもかんでも切らない）
hookは便利だけど、切り出し過ぎると責務が散って追いにくくなる。
「再利用が見えている」「責務が固まっている」ときだけ切り出すようにした。
④ ディレクトリ構造はC/Pパターンに遵守する
置き場所で責務が分かるようにする。
containersにロジック、presentationsに表示。迷いを消す。
⑤ 状態管理は“使う側”でできるだけ管理する（原則、ロジック側で持たない）
状態を上に集めすぎると、Containerが肥大化して“神コンポーネント”になる。
だから状態は可能な限り 使用する側のコンポーネント に寄せ、
Containerはページ全体の制御に集中するようにした。
（補足）C/Pパターンとアトミックデザインの違い（今回C/Pを選んだ理由）
今回のホームの課題は、UI部品の再利用よりも 「ロジックと表示の混在で拡張しづらい」 ことだった。
だからまずは 責務で境界を作るC/P を優先した。
図で見ると違いはこう。
C/Pパターン：責務（ロジック/表示）で切る
アトミックデザイン：UI粒度（原子→分子→有機体…）で切る
アトミックデザインは、UIが成熟していて「部品の再利用と統一」を強くしたいときに効く。
一方で、今回の自分の課題は「全部入りホームの解体」だったので、
まずC/Pで責務を分離して拡張性を取り戻すのが最短だった。
6-5. 成果：追加機能が入れやすくなった（拡張性）
リファクタ後に一番良くなったのは、見た目ではなく 拡張性 だった。
- 表示を足すとき：どの表示コンポーネントに足すかが明確
- データを足すとき：Container側で取得して渡せばよい
- 状態を足すとき：使う側に寄せるから影響範囲が小さい
結果として、追加要件が来たときに
「ページ全体を壊さずに差し込める」感覚が持てるようになった。
6-6. リファクタにテストをつけた（…本当は“先に欲しかった”）
ホームのリファクタは構造を大きく変えるぶん、**「見た目は同じでも壊れる」**リスクが高い。
にもかかわらず当時は、リファクタ前から十分なテストが用意されていなかった。
結果として、自分がやったのはかなり泥臭い確認だった。
- 画面を開く
- クリックする
- 入力する
- 想定される導線を一つ一つ動かす
……これを地道に繰り返した。
ただ、手作業だとどうしても漏れが出る。
つまり、言い方は悪いけど 「何も担保されていない状態で進めていた」。
今振り返ると、正直かなり怖い。
HTTPを“横取り”するテストライブラリを導入した
そこで途中から、HTTPリクエストを横取りしてレスポンスを差し替えられるテストライブラリを導入した。
（例：MSW（Mock Service Worker） のような仕組み）
狙いは「内部実装」ではなく、ユーザー視点での振る舞いを担保すること。
// tests/msw/handlers.ts（イメージ）
import { http, HttpResponse } from "msw";
export const handlers = [
http.get("/api/home", () =>
HttpResponse.json({
kpis: [{ label: "Todo", value: 3 }],
recentItems: [{ id: "1", name: "Item A", status: "open", updatedAt: "2026-01-05" }],
})
),
];
// HomeContainer.test.tsx（イメージ）
import { render, screen } from "@testing-library/react";
import { HomeContainer } from "@/features/home/containers/HomeContainer";
test("ホームがAPIの結果を表示する", async () => {
render(<HomeContainer />);
expect(await screen.findByText("Todo")).toBeInTheDocument();
expect(await screen.findByText("3")).toBeInTheDocument();
expect(await screen.findByText("Item A")).toBeInTheDocument();
});
6-7. 失敗：バックで書くべきテストをフロントで書いてしまい、スコープを広げすぎた
これは明確に失敗だった。
本来バックエンド側で担保すべき「仕様の正しさ」や「ドメインルール」まで、フロントで担保しようとしてしまい、結果的にスコープが必要以上に広がった。
- テスト観点が増える
- モックが複雑になる
- ついで修正が増える
- PRの差分が膨大になる
学び：フロントのテストは“画面の振る舞い”に寄せる
今なら役割分担をこう切る。
- バックエンド：ドメインルール・仕様保証（正しさ）
- フロントエンド：表示・導線・入力・状態遷移（振る舞い）
6-8. 本当は「テストを書いてからリファクタ」が正しい（TDDの大切さを知った）
今回いちばん強く感じたのはこれ。
リファクタの前に、まず“壊れてないこと”を保証するテストが欲しい。
当時はテストがほぼ無かったので、地道に手作業で動かして一つ一つ確認した。
ただ、手作業だとどうしても漏れが出る。
つまり 「何も担保されていない怖さ」 を抱えたまま進めていた。
今考えると正直かなり怖い。
逆に、TDD（テスト駆動開発）のように 先に振る舞い（期待値）を固定 できると、やるべきことが明確になる。
- 「この機能は何を満たしていればOKか」が先に決まる
- 実装はあとから変えてもいい（構造は自由に変えられる）
- そして 変更に自信が持てる
そして結果的に、構造を大胆に変える判断もしやすくなる。
次に同じ規模の改修をやるなら、最初に 最低限の振る舞いテスト（重要導線だけ） を作ってから、段階的にリファクタへ入る。
これが自分の中での結論になった。
Episode 9：ケーススタディ（一気通貫）スクール別 / クラス別で受講生CSVを出力する機能
ここからは、自分が フロント〜バックまで一気通貫で実装した機能を、ケーススタディとして深掘りする。
実装したのは スクール別 / クラス別で受講生情報をCSVで出力する機能。
ポイントは3つ。
- UIが違うため、エンドポイントも2本に分けて実装した
- 権限は Pundit（Policyのみ） で「所属スクールのみOK」を担保した
- ビジネスロジックは Serviceに隠蔽し、Controllerは薄く保った
さらに重要な仕様として、どちらのUIでも「フィルターなし＝契約している全受講生の出力」が可能にした。
9-1. 要件整理：UIが2種類 → APIも2本に分けた（迷子にならないための設計）
今回のCSV出力は、見た目が2パターンあった。
- スクール別CSV：スクールを起点に絞り込み、CSVを出すUI
- クラス別CSV：クラスを起点に絞り込み、CSVを出すUI
ここで要件として重要だったのが、どちらのUIでも「フィルターなし＝全件出力」ができること。
- スクール未指定 → 契約している全受講生を出力
- クラス未指定 → 契約している全受講生を出力
- 指定あり → 指定条件で絞って出力
UIが違うのに、無理に1本のAPIにまとめると
クエリや分岐が増え、結果として理解コストが跳ね上がる。
なので自分は割り切った。
エンドポイントは2本に分ける。UIに沿ってAPIも分ける。
学び：巨大なコードベースでは「分ける勇気」が実装速度になる
“きれいに共通化”よりも、
「迷わない」「追える」「レビューできる」を優先したほうが速い。
9-2. 認可（Pundit）：所属スクールのみOKをPolicyで固定する
この機能は、CSVという性質上 情報漏洩リスクが高い。
だから認証（ログイン）だけでは不十分で、認可が必須だった。
仕様はこう。
- 自分の所属スクールのデータだけ出力できる
- それ以外は出力できない
実装では PunditのPolicyのみ を作成し、
Controllerでの場当たりifを避けた。
学び：Punditは“権限の仕様”がコードとして残るのが価値
- 「誰が」「何を」できるかが1箇所に集まる
- レビューでも説明しやすい
- 後から仕様が変わっても追いやすい
9-3. Rails：Controllerは薄く、Serviceにビジネスロジックを隠蔽した
一気通貫で実装して痛感したのがこれ。
Controllerにロジックを入れた瞬間、保守が終わる。
CSV出力は要件が増えやすい（カラム追加・条件追加・例外対応）。
だからこそ、Controllerを太らせない方針にした。
自分の責務分割はこう。
- Controller：入力を受ける / 認可する / 返す（薄く）
- Service：ビジネスロジック（対象抽出・CSV生成・ファイル名など）を隠蔽
- Query（必要なら）：CSVに必要な基本情報を取る（最小限）
今回の出力条件は、最終的にこう整理した。
- フィルターなし → 契約している受講生を全件（※スクール別/クラス別どちらからでも可能）
- スクール指定 → 所属スクール内で絞って出力（Punditで担保）
- クラス指定 → 所属スクール内のクラスで絞って出力（Punditで担保）
「全件」と「絞り込み」を同じ土俵に乗せてService側で吸収すると、
Controller側は薄いままに保てた。
学び：Serviceに寄せると「レビュー」と「修正」が速くなる
- Controllerが薄い＝差分が読みやすい
- ロジックの置き場所が明確＝迷子にならない
- テストもService中心に書きやすい
9-4. フロント（React）：API hookで接続し、UIと責務を分ける
フロント側でやったことは大きく2つ。
- API hookを作って バックと繋ぐ
- UI（スクール別 / クラス別）を実装する
ただ、ここで反省がある。
反省：状態をContainerに寄せすぎてしまった
選択状態やloadingなどをContainer側で持ちすぎて、
Containerが太り、責務が混ざりかけた。
今ならこう切る。
- hook：通信と結果（CSV Blobやレスポンス）だけ
- UI：選択状態（スクール/クラス）とボタン制御
- Container：ページ制御だけ（必要最小限）
学び：状態は“使う側”、通信はhook、制御はContainer
このルールだけで、実装後の修正が一気に楽になった。
9-5. CSV仕様：文字コードはUTF-8に統一、ファイル名は“サニタイズ”で事故を潰す
文字コードは UTF-8に統一する方針にした。
ただ、実務で詰まりやすいのは中身より ファイル名だった。
- ファイル名は「日付＋スクール名」にしたい
- でも、日本語や記号が入ると 環境によって文字化けや崩れが起きやすい
そこで採用したのが、
ファイル名はエンコード/サニタイズ（記号除去）で安全な形にする
「ユーザーが求める意味（スクールが分かる）」は残しつつ、
壊れやすい文字を排除する設計にした。
（実装メモ）サニタイズ例（擬似）
# 例：記号除去＋空白を_に（擬似）
safe_school = sanitize_filename(school_name) # 記号除去/連続空白を_に/長さ制限など
filename = "#{Date.today.strftime('%Y%m%d')}_#{safe_school}.csv"
※ sanitize_filename は「英数字・ハイフン・アンダースコアだけ残す」「空白は _ に寄せる」など、
**“壊れやすい文字を落として事故を減らす”**のが目的。
補足：スクール名を完全に残すより、
**「スクール名（安全化）＋スクールID」**のように “一意性” を足すと運用で困りにくい。
学び：CSVは「生成」より「使われ方」まで含めて完成
- 文字コード
- ファイル名
- ダウンロード時のUX（loading/失敗表示）
ここまで作って初めて“業務機能”になる。
9-6. つまずき → 学び（今回の実装で腹落ちしたこと）
-
Punditが分からない
→ 「書き方」より「権限仕様をPolicyに集約する」が本質だった -
フロントとバックがどう繋がっているか分からない
→ 正体はAPI契約（エンドポイント/入力/出力/権限）だった -
コードベースが大きすぎて関係ない所に悩んだ
→ 「今回触る範囲」を先に決めると迷子が減った -
AIに丸投げして説明できなかった
→ 速さより「レビューで説明できる理解」が必要だった -
PR概要に意図が反映できていなかった
→ コードは読めるが、意図は書かないと伝わらない
9-7. 結論：一気通貫で伸びたのは“実装力”より“設計の判断軸”
この機能を一気通貫でやって、一番伸びたのはここだった。
- UIに合わせてAPIを2本に分ける判断
- 所属スコープをPundit Policyで固定する判断
- Controllerを薄くし、Serviceにロジックを集約する判断
- ファイル名の文字化けをサニタイズで潰す判断
「動いた」より「運用できる」に寄せる。
そのための設計判断が、実務で一番価値になると腹落ちした。
補足：AIエージェント開発については、次回の記事で書く
現在はAIエージェント開発にも関わっているが、ここは本記事のテーマ（2025年の環境変化と実務の学び）から外れるため深掘りしない。
ただ、これは間違いなく自分の次の大きな挑戦になっている。
機会があれば 「AIエージェント開発で学んだこと」 は別記事としてまとめる。
おわりに：2025年1月6日の自分へ
拝啓、2025年1月6日の俺へ。
まず言うわ。
今日が一番若い日。
始めるのは明日でも、1時間先でもない。今から始めろ。
……いや、これ当時の俺に言っても「それどころじゃねえ」ってツッコむよな。分かる。
あの日の朝のこと、いまでも鮮明に思い出せる。
凍てつくような寒さの中、スーツに身を包んで、冷たい自転車のハンドル握って、会社の近くまで走った。
「行ける。行かなきゃ」って思いながら、でも身体の奥のほうが拒否してる感じ。
職場の近くまで来たのに、どうしても足が前に出なくて、引き返した。
そのあと精神科に行って、適応障害って言われて。
名前が付いた瞬間、安心より先に恐怖が来たよな。
「ここからどうなるんだろう」
「キャリア止まったらどうしよう」
未来が一気に真っ白になった、あの感じ。
でもな。先に結論だけ伝える。
引き返して正解だった。
逃げたんじゃない。壊れる前に止まれた。
あれは“負け”じゃなくて、次に進むための判断だった。
休職も、いまなら胸張って言える。
恥じゃない。権利だ。
そして、この期間は「ただ休む時間」じゃなくて、ちゃんと環境を変える時間にできる。
で、ここから先の話を少しだけ教える。
お前はこのあと、独学を手放して自己投資する。
プログラミングスクールに入って、講師やメンターや仲間と出会う。
そこで、変わる瞬間が来る。
「自分はどこまで行っても、一人になることはない」っていう感覚が、
ただの希望じゃなくて、絶対的な自信になって、最後は確信に変わる瞬間。
たぶん、その瞬間から、お前の走り方は変わる。
コンフォートゾーンを何度も突破する。
自分に“いい感じのプレッシャー”を掛け続ける。
目の前のチャンスを「チャンスだ」って信じて、ノールックで掴み切る。
転職後も「自分のしたいこと」を貪欲に求めて、ちゃんと掴み取る。
あと、これは正直な話。
1年半の独学期間については、少し悔しい気持ちも残る。
「もっと早く自己投資できてたら、もっと早くエンジニアとしてスタートできたかも」って。
でも同時に、独学で培った自走力は、今の現場でも確実に生きてる。
人材価値が上がる経験の一つになったのも間違いない。
ただ――これは、万人におすすめできる道じゃない。
お前はたまたま、耐え切っただけだ。
そして、最後にこれだけ書いておきたい。
2025年に出会ったすべての人に、ありがとう。
特に、この記事を読んで「それ俺のことかも」「私のことかも」って思った人へ。
近い距離で関わってくれて、俺の勝手も未熟さも、たぶんたくさんあったのに、許してくれてありがとう。
転職先の皆さんも、正直、生意気だったと思う。間違いない。
それでも受け入れてくれて、場を用意してくれて、育ててくれて、本当にありがとうございます。
……よし。そろそろ締める。
1年前の俺へ。
もし今、お前が「戻れない」「取り返せない」って震えてるなら、言っとく。
震えていい。怖くていい。
でも、ここで止まるな。
今日が一番若い日だ。
始めるのは明日じゃない。今からだ。
そしてこの記事を読んでる、いま挑戦したいと思ってるあなたへ。
準備が整う日なんて、来ない。
不安が消えてから動こうとしたら、一生そのまま。
だから、選べ。
環境を変えろ。
チャンスを掴め。
掴んだあとに、学べ。
大丈夫。完璧じゃなくていい。
不器用でも、進んだ奴が勝つ。
敬具。
追伸：この記事のいちばん最後に、もう一度だけ
準備が整う日は来ない。
チャンスが目の前に来たら、まず掴む。
**知識と技術は、掴んだあとに獲得すればいい。**それで問題ない。
この記事をここまで読んでくれたあなたは、たぶんもう薄々気づいてるはず。
「変わりたい」「挑戦したい」「でも怖い」って。
でもさ、次に成功するのは――あなたかもしれない。
結果は、行動した人にしか分からない。
考えてるだけの世界には、何も起きない。マジで。
そしてもう一回言う。
今日が一番若い日！！
さぁ、挑戦しよう。
で、いつかどこかで、僕と楽しくお酒飲みましょう。
てか、僕といっしょにお酒のんでください！！（笑）
必ず未来は明るい！！！
以上、将来のつよつよエンジニアから皆さんに伝えたいことのすべてです
次の一歩（2026年へ）
2026年は、肩書きじゃなくて 実力で黙らせる年にする。
やることは3つだけ。
- AIエージェント開発を“語れる実装”にする（設計 → 実装 → 運用まで）
- テストを先に敷いて、機能の担保を固めてから実装できる自分になる（最低限の重要導線だけでいい）
-
学んだこと・苦労したこと・うまくいったことを記事にして、世界中に価値提供する
（「自分だけの学び」で終わらせない。次に同じ壁にぶつかる誰かのショートカットにする）
次の記事では、いま関わってる AIエージェント開発のリアルを全部出す。
“すごそう”じゃなく、再現できる形に落として見せる。
ここまで読んでくれたあなたへ。
読むだけで終わる人は、たぶんここで止まる。
でも、やる人はここからだ。
……モタモタしていると置いてっちゃうよ〜
PS. 最後に僕のことに興味が少しでもあるよーってひとは下記の僕のｘのアカウントを見て頂きH◯◯やS◯◯でYouTubeで調べてみてください。
きっと僕の人となりが分かるはずです！！
最後まで読んで頂きほんっっっっっっっとうにありがとうございます！
読者の方々すべてのひとに感謝申し上げます。
今後も有益な情報を記事にしてまいりますので、フォロー、いいねよろしくお願いいたします！！
おまけ
- X（旧Twitter）：啓汰
- GitHub：@Keita-0025