開発振り返り - 2025 年 11 月 29 日

総評

今週は、単にコードを書くこと以上に「なぜその実装が必要なのか？」という設計意図やアーキテクチャへの理解を深めることに注力した。特にバックエンドとフロントエンドの役割分担（バリデーション）や、Vue.js におけるロジックの再利用性（Composables）について、プロの視点を学べたのが大きな収穫。

できたこと・よかったこと

1. バリデーション設計の理解深化

内容: 「なぜ FE だけでなく BE でもバリデーションが必要なのか」について、セキュリティやデータ整合性の観点から言語化できるようになった
成果: FE は UX のため、BE はセキュリティと整合性のためという役割の違いを明確に理解し、実装の意図を汲めるようになった

2. Vue.js の設計パターン習得（Composables）

内容: Vue のコンポーネントからロジックを切り出す composables の概念とメリットを学習
成果: UI とロジックを分離し、再利用性とテスト容易性を高める「モダンな Vue の書き方」の基礎を習得

3. コーディング規約と可読性への意識向上

内容: Python の PEP 8 や、インポート順序、行の長さなど、読みやすいコードを書くためのルールを再確認
成果: 「動けばいい」ではなく、チーム開発を見据えた「他人が読みやすいコード」への意識が向上

自分の特性について（1on1 での FB）

今週はサブリーダーとの 1on1 があり、自分の特徴と課題についてフィードバックをもらった。

強み

エンジニアとしての素養: 好奇心・探究心があり、気になったことはすぐに調べる癖がある
謙虚さ・真面目さ: 丁寧に仕事に向き合う姿勢
注意力・繊細さ: 細部まで気を配れる
興味関心・自走能力: 単体テストに関して意欲的に、必要なケースや方法を自ら考えていた

期待されていること

技術力の向上: 業務・自己研鑽を通じて課題解決能力を高める（個人・組織ともに）
設計スキルの習得: 設計力があれば実装前に設計でき、影響調査能力も上がる
チームとの協働: 任されたタスクをやり切ることを積み重ね、信頼を獲得する
判断力の強化: 要点整理力、問題整理力、レビューへの根拠ある返信ができるようになること

目指す姿

社会人 4 年目として会社の中核を担い、「お前がいないと成り立たない」と言われる存在になる
技術中心ではあるが、「組織」「プロダクト」に自分がどう貢献できるかを日々考える
下期中に貢献の実績を出す

学んだこと

1. 入力値バリデーションを FE だけでなく BE でも行う理由

「FE でチェックしているのに、なぜ BE でもやるの？」という疑問に対する回答（優先度順）:

優先度	理由	詳細
1	セキュリティ	FE は信頼できない。JS 無効化や curl 等で簡単にバイパス可能
2	データ整合性	FE のバグやバージョン違いから DB を守る最後の砦
3	テスト容易性	BE（Model 層）なら一元管理でき、自動テストもしやすい
4	仕様の統一	FE/BE でルールの食い違いを防ぐため、API 側を「正」とする
5	将来の拡張性	iOS/Android 等クライアント増加時も品質を担保できる

結論: FE バリデーションは UX のため、BE バリデーションは信頼性・セキュリティ・データ整合性を守るため。

先輩からのアドバイス toC 向けシステムでは BE バリデーション必須。社内ツール等で影響度が低い場合は、工数との兼ね合いで FE のみにすることもある（ケースバイケース）。

2. Vue.js: Composables とデータフロー

Composables とは: Vue コンポーネントから状態管理・メソッド・副作用などを独立した「関数」として切り出したもの。

メリット:

ロジックの再利用: 同じ処理を複数箇所で使い回せる
テスト容易性: UI に依存しないため単体テストが簡単
可読性: コンポーネントが UI 記述に集中できてスッキリする

データフローのベストプラクティス: 「データは親コンポーネントで取得し、子に Props で渡す」が基本。

3. コーディング規約（Python）

項目	ルール
PEP 8	Python 公式スタイルガイド。可読性と一貫性のために遵守
インポート順序	標準ライブラリ → サードパーティ → 自作モジュール（外から内へ）
行の長さ	長すぎると可読性が落ちるため、適切な位置で改行

4. 例外とエラーハンドリングについて

FE の業務でエラーハンドリングを行うタスクがあり、例外処理について同期に教えてもらった。

例外の分類:

分類軸	種類	説明
発生源	システムエラー	ネットワーク障害、サーバーダウンなど
発生源	業務的例外	バリデーションエラー、権限不足など
予測可能性	予期するエラー	想定内のエラー（入力ミス等）
予測可能性	予期しないエラー	想定外のエラー（バグ等）

検討すべき視点:

どういった時にこのエラーは出るのか？
出た場合どのように対応するのが適切か？

この視点でエラーハンドリングを設計しないといけないが、知見不足を痛感した。

課題・改善点

Git の操作ミスによる工数ロス

現状: ブランチの命名規則を間違えたまま作業を進め、修正に時間を要した
改善策:
- ブランチを切る前に命名規則を指差し確認
- 間違えた場合の修正手順（git branch -m 等）を手元に用意しておく

来週の目標

BE バリデーション実装時、網羅的なテストケース（正常系・異常系）を意識して書く
Vue コンポーネント実装時、共通ロジックがあれば composables への切り出しを検討
Git 操作時は一呼吸置き、ブランチ名やコミット先を確認する癖をつける

まとめ

今週は、実装の「How」だけでなく「Why」を多く学べた一週間だった。特にバリデーションや設計パターンに関する知識は、今後の開発すべての基礎になる重要な部分。

また、Git のミスという反省点もあったが、これも開発プロセスの一部として捉え、同じミスをしないようフローを見直していく。