ID:78386さん

## 開発期間 2023年~2025年11月 ## 概要 4000〜5000人利用を想定した社内ポータルの全面リプレースプロジェクト。 ## 体制 * **規模**: 50〜60人ほど * **アプリチーム**: 10人ほど（自身がバックエンドリードを担当） * ※ 自身はアプリケーションレイヤーのみを担当（インフラ・UI/UX改善は別会社） ## 目的 “社員が必要な情報に最短距離で辿り着ける状態”の実現をテーマとしました。 単なる再構築ではなく、運用者・利用者の双方にとって迷いのない情報体験を構築するため、以下の4点を軸に開発をリードしました。 * 情報設計（複雑なアクセス制御と階層構造の整理） * パフォーマンス向上（検索体験・表示速度の改善） * UI/UX改善（表示内容と設定構造の一貫性） * 拡張性・保守性の確保（将来的な組織改編や制度変更への耐性） ## 担当 * アプリケーション開発 ※ バックエンド中心にフロントエンド/インフラ領域も部分部分で横断的に対応。 * 主要機能の設計 * ユーザー要件ヒアリング * 設計レビュー / コードレビュー ## 技術 ### バックエンド * Symfony(Drupal) * Drupal(PHP) ### フロントエンド * TypeScript / Storybook ### インフラ(アプリ連携) * AWS: ECS, OpenSearch, Lambda, SQS, DynamoDB, S3, Aurora(Serverless MySQL), StepFunctions * CI: Github Actions, CodeBuild(AWS) ### ツール * Datadog * Jira * BitBucket * GHE * Slack * Confluence ## 成果と挑戦 ### 1. 要件定義〜開発までの一貫したコミット 担当領域はアプリケーション開発でしたが、デザインチーム・インフラチームと密に連携し、システム全体の目的達成に向けて**要件定義フェーズから参画**しました。 特に注力したのは、複雑な組織構造（所属・雇用形態・拠点など）に基づく権限制御要件の整理です。 業務担当者へのヒアリングを通じて要件を深掘りし、**アクセス制御ロジックの抽象化**、**UI設計**、**管理画面の情報構造の見直し**を実施。 結果として、属人化や設定ミスを構造的に防ぎ、運用者が「誰が何を見られるか」を直感的に把握できる自律的な運用システムを実現しました。 開発のみならず要件定義から主導して携わることができた経験は、「業務ドメインを捉えた設計・開発」や「現場の声を反映する情報設計」の実践を通じ、コーディングスキルの向上だけでなく、設計力・対話力・提案力の重要性を再認識するきっかけになりました。 「単に動くものを作る」のではなく、**プロダクト体験を設計する視点**へと成長でき、エンジニアとしての視座を一段引き上げる経験となりました。 ### 2. アーキテクチャ刷新の主導 開発初期は、Drupal（CMS）のエコシステム内で完結させる方針を掲げておりました。 しかし、「要件の複雑さと求められるシステムの柔軟性」を強引にエコシステムの枠組みで賄おうとした結果、**拡張性の低下**や**不具合の多発**、**パフォーマンスへの影響**といった課題が顕在化しました。 そこで、Drupalの強力なAPIを活かしつつも、継承元であるSymfony（PHPフレームワーク）の設計思想を強く意識した**「Drupalをフレームワークとして活用する」アプローチ**を提案いたしました。 この方針転換はチームにとって大きな決断でしたが、導入の結果、**高いパフォーマンス**と**複雑な業務ドメインの的確なコード化**を両立することに成功しました。 また、Drupal標準のキャッシュ機構に加え、Varnish/Redisを用いた**粒度の高いキャッシュ戦略**も導入し、大量アクセス時にも安定したレスポンスを維持できる構成を実現しました。 UI要件も高いプロジェクトであったため、バックエンド中心の役割でありながらも、フロントエンド側の機能設計にも横断的に関与し、情報設計とUX観点の改善にも貢献しました。 短期間でドメインや技術基盤をキャッチアップし、プロジェクト中後期では主要機能の設計・実装に加え、設計レビュー・コードレビュー・技術提案などプロジェクトの中核メンバーとしての役割を担う経験を得ました。 ### 3. バッチ処理の高速化 基幹システムとのデータ連携バッチにおいて、データ量の増加に伴い処理時間が45分を超過し、始業時に最新データが反映されていないリスクがありました。 本課題に対しインフラ強化は行わず、アプリケーションコードの改善のみで解決しました。 * **施策**: ループ内でのDB問い合わせ（N+1）を廃止し、探索アルゴリズムを見直し。データをメモリ上に展開してハッシュマップで照合するロジック（**O(N^2) → O(N)**）へ書き換え。 * **成果**: 処理時間を **45分 → 20秒（約135倍）** に短縮し、業務影響が出る前にボトルネックを解消。 自己研鑽で取り組んでいた**「アルゴリズム力・計算量への意識」**を実務の課題解決に直結させることができ、エンジニアとしての自信に繋がった経験です。

## 開発期間 2025年08月 ~ 2025年12月 ## 概要 顧客の声（フィードバック）を収集・分析し、プロダクト改善に活かすためのBtoB SaaSプロダクトの新規立ち上げ。 **「リリース前時点で4社への導入決定」**というビジネス成果に向け、要件定義からアーキテクチャ設計、インフラ構築、実装までを一人称でリード。 特定のクライアント向けカスタマイズではなく、汎用的な**マルチテナント/SaaS型プロダクト**として設計・開発。 ## 体制 * **規模**: 2名(PM 1名 / エンジニア 1名) * **担当**: 要件定義、技術選定、アーキテクチャ設計、アプリケーション開発、インフラ構築(IaC) * ※ 技術領域の全責任者として、設計から実装・デプロイまでを一人称で完遂。 ## 技術スタック | カテゴリ | 詳細 | | :--- | :--- | | **言語** | **Go** (1.25) | | **フレームワーク** | Gin, sqlc | | **データベース** | PostgreSQL | | **インフラ** | AWS CDK (Go), API Gateway, Lambda, Aurora Serverless, S3, CloudFront | | **アーキテクチャ** | Clean Architecture, Unit of Work Pattern | | **外部連携** | Stripe (決済・サブスクリプション管理) | | **フロントエンド** | Next.js (TypeScript) | ## 成果と技術的挑戦 ### 1. 0→1開発におけるビジネス成果とスピード感 企画者であるPMと連携しながらMVP（Minimum Viable Product）の要件をスピード感を持って策定。 ビジネス要件が流動的なフェーズにおいて、変更に強いドメイン設計と、デプロイサイクルを高速化するIaC環境を初期から構築しました。 結果、営業段階でデモ可能な品質のプロダクトを短期間でリリースし、**リリース前に4社の受注を確定**させました。 ### 2. Go言語における堅牢なアーキテクチャ設計（Clean Architecture） Go言語の実務採用は本プロジェクトが初でしたが、長期的な保守性とスケーラビリティを担保するため、**厳格なレイヤードアーキテクチャ**を採用しました。 * **依存関係逆転の原則 (DIP)**: Domain（ビジネスルール）を中心に据え、DBや外部APIへの依存を完全に排除。インターフェースを用いた疎結合な設計により、単体テストの容易性と将来的な技術変更への耐性を確保しました。 * **防御的ドメイン設計**: 全てのIDやパラメータにValue Objectを採用し、生成時にバリデーションを強制。「不正な値がドメイン層に存在できない」状態を保証することで、バグの混入を構造的に防いでいます。 ### 3. 高度なトランザクション管理と整合性担保 SaaSとしてデータの整合性が生命線となるため、フレームワーク機能に頼らず、信頼性の高いデータ処理基盤を構築しました。 * **Unit of Workパターンの独自実装**: * ドメイン層がトランザクションの詳細（`Begin`, `Commit`, `Rollback`）を意識せず、宣言的に扱えるインターフェースを構築。 * ユーザー登録、契約管理、ログ記録といった複数のリポジトリに跨る更新処理において、ACID特性を厳密に担保しています。 * **Stripe連携における冪等性（Idempotency）の担保**: * 決済システム（Stripe）からのWebhook処理において、ネットワーク起因のリトライによる「二重課金」や「処理重複」を防ぐため、イベントログテーブルを用いた冪等性制御を実装。分散システムにおけるデータの整合性課題を解決しました。 ### 4. AWS CDKによる完全なIaC化と開発効率化 インフラ構成（API Gateway, Lambda, DB等）をすべて**Go言語によるAWS CDK**でコード化しました。 * **環境複製の自動化**: コマンド一つでStaging/Production環境を複製できる体制を構築し、インフラ変更のレビューもプルリクエストベースで実施可能にしました。 * **スキーマ駆動開発**: `sqlc` を採用し、SQLとGoコードの型整合性をコンパイル時に保証。実行時エラーを極小化し、開発体験（DX）と品質を両立させました。 Go言語未経験の状態からスタートしましたが、言語仕様だけでなくエコシステムや設計思想まで深くキャッチアップし、シニアエンジニアから**「特定の言語に依存しない、普遍的で堅牢な設計力がある」**との評価を獲得しています。