n_takechi

# 官公庁システム案件（ガバメントクラウド新規開発） 官公庁向けガバメントクラウド案件にて、開発チームリーダーを担当しました。 主にフロントエンドをメインとして、Vue3によるフロントエンド設計、UIフレームワーク選定、Lint導入、レスポンシブ対応、SPA環境でのSEO対策を実装しました。 チームは 12名（PM2 / フロント4 / バックエンド2 / インフラ1 / テスト3） で構成され、要件定義〜運用保守までを一貫して対応しました。 ## 1. フロントエンド（Vue3）設計・実装 / UI基盤整備 ### 【課題】 新規開発のため、UI実装ルールやコンポーネント設計が未整備で、開発が進むにつれて - UIの一貫性が崩れる - 実装コストが増える - レビューが属人化する といった品質・速度の両面でのリスクがありました。 ### 【工夫】 開発初期に「後から直すとコストが爆発する領域」を優先して整備しました。 具体的には以下を実施しました。 1. CSSフレームワーク選定 ・要件（保守性 / レスポンシブ / 実装スピード / 学習コスト）を比較軸に整理し、複数案を検討した上で採用方針を決定 2. コンポーネント設計ルール策定 ・Atomic Designをベースに粒度を揃え、命名・責務分離を統一 ・ESLint導入とルール設計 3. レスポンシブ対応 ・画面仕様の曖昧さを整理し、ブレイクポイント設計を含めて実装方針を決定 ### 【成果】 - UIの一貫性が保たれ、実装・レビューの属人化を抑制 - チーム内で実装品質の基準が揃い、後半フェーズでも手戻りが発生しにくい状態を維持 - 開発リードとして、設計・実装だけでなく「開発の型」を整備する役割を担った ## 2. バックエンド（Lambda + API Gateway） / DynamoDB設計改善 ### 【課題】 APIはサーバレス構成（Lambda + API Gateway + DynamoDB）で構築されていましたが、 DynamoDBのキー設計・アクセスパターンが整理されておらず、クエリ効率やスケーラビリティに懸念がありました。 ### 【工夫】 DynamoDBは後からの修正が難しいため、まずアクセスパターンを洗い出し、 「どの条件で、どの頻度で、どのデータを取得するか」を整理した上で設計を見直しました。 - アクセスパターン整理 → パーティションキー設計の改善 - クエリ設計を見直し、不要なスキャン・フィルタ依存を減らす方針へ変更 - API仕様とデータモデルの整合性を取りながら、実装を進行 ### 【成果】 - データ取得の効率が改善し、スケールを前提とした設計に移行 - 「API実装」だけでなく、データ設計から逆算した構成検討をリードできる経験を得た ## 3. セキュリティ・品質・進行管理 ### 【課題】 官公庁案件のため、セキュリティ要件が厳しく、脆弱性対応や品質担保を継続的に行う必要がありました。 ### 【工夫】 - AWS Inspectorによる脆弱性検知と対応フロー整備 - コードレビューを通して、設計の意図・共通認識をチーム内に浸透 - タスク分解と進行管理を行い、納期と品質を両立 ### 【成果】 - セキュリティ・品質の要求水準を満たしつつ、スケジュール通りに進行 - 技術だけでなく、チームとして成果を出すための推進力を発揮できた

# 社内プロダクト（LINE予約システム） 過去案件ごとに個別対応していたLINE予約機能を汎用化し、2名体制のチームでリアルイベント向けの予約システムとしてプロダクト化を推進しました。 自分：PdM兼フルスタック（Vue3 / Rails）として要件整理〜設計・実装・テストを担当 メンバー：インフラ整備・運用設計・開発サポートを担当 ## 1. 予約機能のプロダクト化（共通化設計） ### 【課題】 案件ごとに予約機能を個別開発していたため、以下の課題がありました。 - 仕様差分の吸収が難しい - 機能追加や改修のたびに開発コストが増える - 案件展開スピードが上がらない ### 【工夫（思考・アプローチ）】 まず「利用シーンの差分」を洗い出し、 - 共通要素（必ず必要になる機能） - 変動要素（案件により変わる部分） を整理した上で、プロダクトとして成立する設計に落とし込みました。 具体的には以下を実施しました。 1. 予約ロジックの抽象化 予約枠、受付条件、キャンセルルール等を設定項目として整理 2. 設定項目の設計 「案件ごとにコード修正が必要な箇所」を減らし、運用で吸収できる形へ寄せた 3. 優先度設計・ロードマップ策定 まずプロダクトとして使える最小機能（MVP）を定義し、段階的に拡張する方針にした ### 【成果】 - 案件差分を設定で吸収できる範囲が増え、再利用性が向上 - 案件ごとの開発コスト削減と、展開スピード向上に貢献 - 「仕様整理→設計→実装」までを横断して進める経験を得た ## 2. 実装・品質担保（Vue3 / Rails / RSpec） ### 【課題】 プロダクト化により、複数案件で継続利用される前提となったため、 一時的に動く実装ではなく、保守性・品質を担保した実装が必要でした。 ### 【工夫】 - Vue3でのUI実装（予約フォーム、管理画面など） - RailsでのAPI開発（予約登録・一覧・キャンセル等） - RSpecでのテスト実装により、主要ロジックの品質を担保 ### 【成果】 - 継続的な利用を前提とした、保守可能な予約システムとして運用に耐える状態にした - PdMロールとしての推進と、エンジニアとしての実装を両立できた ## 3. PdMとしての推進（要件整理・進行管理） ### 【課題】 社内プロダクトとして、技術だけでなく「事業側が求める価値」を満たす必要がありました。 ### 【工夫】 - 要件整理と関係者調整を行い、開発チームが迷わず実装できる状態を作った - スケジュール管理・タスク分解を行い、開発の停滞を防止 - 技術とビジネスの橋渡し役として意思決定を推進 ### 【成果】 - 初めてのPdMロールとして、プロダクト価値を形にする経験を獲得 - 「作る」だけでなく「なぜ作るか」「何を優先するか」まで責任を持って推進できた

# 社内プロダクト導入案件：GUCCI Bamboo Summer（LINE予約システム） 社内で開発したLINE予約システムの初導入案件として、GUCCIのリアルイベント向け予約フローを実装しました。 要件定義〜設計・実装・テストまでを担当し、営業・デザイナー・クライアントと連携しながら、短期間で導入を完遂しました。 ## 1. 初導入案件としての予約フロー実装（Vue3 / Rails） ### 【課題】 社内プロダクトとして初めての導入案件であり、 - 運用に耐える品質 - クライアント要件の実現 - 短期間でのリリース を同時に満たす必要がありました。 また、ハイブランド案件のためWebコンテンツ表現に関するガイドラインが厳格で、演出と実装制約のバランスが難しい状況でした。 ### 【工夫】 「すべてを実現する」ではなく、以下について切り分け、短期間で確実に実装できる落としどころを定義しました。 - 遵守すべき要件（Must） - 運用上許容される範囲（Should / Could） 具体的には以下を行いました。 - 予約導線・画面構成を整理し、ユーザー操作フローとして設計 - Railsで予約ロジック/APIを実装し、Vue3でUIを構築 - 表現ガイドラインを満たしつつ、実装可能な形に調整し反映 ### 【成果】 - 社内プロダクトの初導入を短期間で成功させ、クライアント要件を満たした予約フローを提供 - 初導入案件の成功により、プロダクト導入の価値検証に貢献した ## 2. 関係者調整（営業・デザイナー・クライアント） ### 【課題】 ガイドラインや表現要件が厳しく、仕様を曖昧なまま進めると、手戻りや品質低下、リリース遅延につながるリスクがありました。 ### 【工夫】 - 営業・デザイナー・クライアントと調整しながら、要件を明文化 - 「実現できること / できないこと」を早期に整理し、期待値をコントロール - 制約下での最適解を提案し、実装に落とし込んだ ### 【成果】 - 関係者間の認識齟齬を抑え、スムーズに導入を推進 - 導入後にクライアントから直接評価を得られ、品質と体験の両面で成果を残した ## 3. 学び（プロダクト導入と顧客コミュニケーション） ### 【得られた経験】 本案件を通じて、プロダクトの価値は機能実装だけでなく、「顧客要件の整理」「期待値調整」「導入までの推進」によって成立することを実感しました。 以降のプロダクト展開においても、顧客コミュニケーションを意識した推進を行う土台となりました。

# 社内プロダクト導入案件：Bvlgari Serpenti 75周年（PdM / フルスタック） 社内開発のLINE予約システムをBvlgariのイベント向けに導入し、要件整理〜設計・実装・テストまでをPdM兼フルスタックとして担当しました。 既存プロダクトとして汎用化された領域を活かしつつ、デザイン・表現に強いこだわりを持つクライアント要件に対応するため、必要最小限のカスタマイズを行い導入を成功させました。 ## 1. 既存プロダクトの導入 + 必要最小限の拡張 ### 【課題】 社内プロダクトとして共通化されているLINE予約システムを活用しながらも、 - ブランド表現（UI/演出）に対する要求水準が高い - プロダクトの制約がある中で要望を成立させる必要がある という難しさがありました。 また、安易にカスタマイズを増やすと、プロダクトの保守性が落ちるリスクがありました。 ### 【工夫】 「導入案件を成功させること」と「プロダクトとしての再利用性を維持すること」を両立するため、 要求をそのまま実装するのではなく、以下の観点で整理しました。 - UI仕様 / 設定項目 / 予約ロジックのうち、どこを拡張すべきかを判断 - 既存の共通機能で吸収できる範囲と、拡張が必要な範囲を切り分け - 拡張は「他案件でも再利用できる形」を意識して設計 そのうえで、Railsでロジック/APIを実装し、Vue3でUIを構築しました。 ### 【成果】 - ブランド要件を満たしつつ、プロダクトの構造を崩さない形で導入を成功させた - 導入経験を通じて、プロダクトの制約・設計思想の理解が深まり、以降の案件でも判断精度が向上した ## 2. PdMとしての要件整理・意思決定 ### 【課題】 クライアント要件の中には、プロダクトの仕様・制約と衝突するものもあり、 「どこまで対応するか」を判断しながら進める必要がありました。 ### 【工夫】 - クライアント要望を分解し、必須要件と希望要件を整理 - 実装コストとプロダクト影響を比較し、実現方針を決定 - 関係者と調整しながら、導入スケジュールに落とし込んで推進 ### 【成果】 - 表現要件とプロダクト制約のバランスを取りながら、短期間で導入を完遂 - PdMとしての意思決定と、エンジニアとしての実装を両立できた

# Jimmy Choo LINEスタンプラリー / デジタルガチャ（FE・BE） Jimmy Chooのプロモーション施策として、LINE上で動作するスタンプラリーおよびデジタルガチャのWebアプリについて、要件定義〜設計・実装・テストまで一貫して担当しました。 営業と連携しながら仕様調整を行い、短納期の中でも品質と開発速度の両立を意識して推進しました。 ## 1. LINE上で動作するWebアプリの設計・実装（Vue3 / Rails） ### 【課題】 LINE上で動作するWebアプリは、通常のWebアプリと比べて制約が多く、 - ユーザー導線が途切れやすい - 仕様上の制限（LINE特有の挙動・制約） - 短納期でのリリース要求 が重なり、実装・品質担保が難しい状況でした。 ### 【工夫】 ユーザーが迷わず完了できる体験を最優先に、 フロント（Vue3）とバックエンド（Rails）をセットで設計しました。 - LINE上の動作制約を前提に、ユーザー操作フローを設計 - RailsでAPIおよびロジックを実装し、Vue3でUIを構築 - テスト工程では、バグの早期検出を意識し、仕様に沿った確認観点を整理 ### 【成果】 - LINE特有の制約を考慮したうえで、スタンプラリー・ガチャ機能を実装し、プロモーション施策としてリリースまで完遂 - 短納期案件でも品質を落とさず、開発を進められる経験を得た ## 2. 仕様が揺れる状況での要件整理・認識齟齬の解消 ### 【課題】 プロモーション案件の性質上、途中で仕様が二転三転しやすく、要件が曖昧なまま開発が進むと、 - 手戻りの増加 - バグの増加 - 関係者間の認識齟齬 につながるリスクがありました。 ### 【工夫】 MTG後や仕様変更時に、都度以下を徹底しました。 - Slack / Backlog上で仕様の現状を整理し、文章として明文化 - 決定事項・未決事項を分けて残し、次アクションを明確化 - 開発側の観点でリスクを先出しし、早期に調整を促進 ### 【成果】 - 仕様の認識齟齬を減らし、手戻りを抑制 - 「実装するだけ」ではなく、仕様の不確実性を整理しながら前に進める力を発揮できた ## 3. インフラ以外を一通り担当できる対応範囲 ### 【課題】 限られた体制・短納期の中で、複数領域を横断して開発を進める必要がありました。 ### 【工夫】 - フロント（Vue3）とバックエンド（Rails）の両方を担当し、仕様変更にも迅速に追従 - ユーザー操作フローの設計から、テストでのバグ検出まで一貫して対応 ### 【成果】 - FE/BEを横断して担当することで、仕様変更が多い状況でも開発を止めずに推進

# niaulab by ZOZO LINE予約システム（フロントエンド / QA） ZOZO運営のスタイリング体験施設向けLINE予約システムにて、フロントエンド実装およびQA（E2E自動テスト）を担当しました。 チームは複数名体制で、私は主に Vue3でのUI実装と、CypressによるE2Eテスト設計・実装を担当しました。 ## 1. フロントエンド実装（Vue3） ### 【課題】 LINE上で動作するWebアプリとして、画面遷移・入力・予約完了までの一連の操作を、ユーザーが迷わず完了できるUIが求められました。 ### 【工夫】 - Vue3ベースで画面実装を担当し、予約フローに沿ってUIを構築 - 仕様の曖昧さや抜け漏れがある箇所については、レビューや仕様調整を通じて整理し、実装に反映 ### 【成果】 - 予約フローのUIを実装し、サービス提供に必要な画面機能を完成させた - 仕様の理解・調整を行いながら実装を進めることで、手戻りを抑制した ## 2. CypressによるE2E自動テスト導入・整備 ### 【課題】 予約ロジックが複雑で、手動テストでは確認漏れや品質リスクが発生しやすい状況でした。 また、仕様変更が発生した際にリグレッション（既存機能の破壊）が起きやすい構造でした。 ### 【工夫（思考・アプローチ）】 テストを「画面単位」ではなく「ユーザーの予約体験単位」で設計し、 重要度の高いシナリオを優先してE2Eテストを整備しました。 - 予約ロジックに対応したテストケースを設計（正常系・例外系） - Cypressで主要シナリオのE2Eテストを実装 - 仕様変更時に壊れやすいポイントを意識し、保守しやすい粒度でテストを作成 ### 【成果】 - 重要な予約シナリオを自動化し、品質担保の仕組みを構築 - 変更が発生しても影響を検知しやすくなり、リリース時の不安を軽減した ## 3. 学習・キャッチアップ（品質向上のための自己投資） ### 【課題】 QA領域は経験が浅く、チームへの貢献度を高めるために短期間で知識を補う必要がありました。 ### 【工夫】 - テスト設計・自動化に関するオンラインセミナーを受講し、知見を実務に反映 - 学習した内容をテストケース設計や実装方針に落とし込み、品質向上につなげた ### 【成果】 - QA・自動テスト領域でも自走しながら改善を進められる経験を獲得 - フロント実装と品質担保をセットで考える姿勢を身につけた