聖永宗玄
Software Engineer

まず、設計時に一貫して意識している判断軸は以下の 4 点でございます。 1. 失敗時の安全性 — 冪等性・排他制御・データ保全（特にバッチ・決済領域） 2. 責務分離 / 凝集度 — Clean Architecture、Package by Feature、UseCase 層の導入 3. PR・変更単位の分割戦略 — レビュー可能な粒度で安全に置換できる単位に切る 4. 型と静的解析でガードする — TypeScript strictest、Lint、CI ゲートでの担保 具体例としては、以下のような設計経験がございます。 ① 某新規サービス立ち上げ案件 月次継続課金バッチ 約 4,200 行のサブスクリプション課金バッチを単独で設計・実装いたしました。月次課金は障害時の影響が大きいため、冪等性・再実行性・二重決済防止を設計の中核に据えております。処理済みデータは status=complete で管理し、再実行時にも安全に再開可能な構成とし、MySQL の LOCK TABLES で二重実行・競合を防止しております。 → 「障害時の影響が大きい領域では、再実行しても壊れない設計を最優先する」という基準を体現した事例でございます。 ② 某新規サービス立ち上げ案件 退会機能 論理削除フラグではなく、Archive テーブルへ退避する方式 を採用いたしました。データ保全性・運用性（後追いでの追跡可能性）を優先した判断でございます。 ③ 某不動産系 SaaS 案件 API 設計リファクタ 汎用 delete mutation を、リソースごとの個別 mutation に 3 分割 PR でリファクタリングいたしました。責務の明確化と、フロント・バック横断でレビュー可能な PR 粒度を両立させることを基準としております。 ④ 某大手電機メーカー R&D 案件 ディレクトリ構成 書籍『Bulletproof React』を参考に "Package by Feature" を提案・採用し、ESLint Flat Config 約 300 行を新規整備いたしました。機能単位での凝集を高め、スケール時の検索容易性・保守性を優先しております。 ⑤ 某大手グルメサービス 外国語版予約機能 Clean Architecture を意識したレイヤード構成に、Redux Toolkit と React Testing Library を導入いたしました。長期運用への耐性とテスタビリティを基準とした設計でございます。 いずれも「対象領域のリスクと寿命に応じて、どの基準を優先するか」を判断した上で設計しており、設計手法そのものを目的化しないことを意識しております。

2 件のプロジェクトでリーダーを経験しております。 ① 某大手航空会社向け 保険システム 運用保守フェーズ 10 名以上のチームのリーダーとして、Laravel / PHP / Vue.js を用いた開発に加え、要件定義・設計書作成・タスクの割り振り・スケジュール管理・品質管理を担当いたしました。 ② 某暗号資産取引所 サイトリリース案件 Web コーダー 3〜5 名のチームの進行管理とマネジメントを担当し、サイトリリースまでをやり切りました。 いずれもスコープ管理（タスクの割り振り、スコープのコントロール）と品質管理（2 人以上のチェック・ブラウザチェックの義務付け）を意識したチーム運営を実践しております。