ID:47270さん

## 概要 20年以上にわたり提供されてきたオンプレミス型MA（マーケティングオートメーション）ツールのクラウドサービス化の立ち上げに参画しました。 2022年12月にリリースし、その後は新機能の追加開発、運用・保守、インターン生のメンターなどを担当しました。 ## 特徴 - 認証にはAWS Cognitoを使用（ログイン画面は非Hosted UI）。 - UIフレームワークはElement Plusを採用。 - スクラム開発（1週間スプリント）で進行。 - チーム構成：8名（フロントエンドエンジニア4名、バックエンドエンジニア3名、プロダクトオーナー1名） ## 自身の役割 - Figmaを用いた画面設計、Web画面の実装、運用保守、PRレビューを担当。 - プロジェクトの途中から参加し、複数の画面や機能の実装を担当しました。 ## 開発における工夫 - プロジェクトに参加した時点で開発が遅延していたため、以下の工夫を行いました。 - よく使われるダイアログや一覧画面などを共通コンポーネント化し、省力化と工数削減を図りました。 - フロントエンドリーダーに集中していたPRレビュー体制を見直し、ランダムにアサインされたメンバーによる相互レビュー体制を構築し、負荷を分散しました。 ## 開発中の課題と対応 - 外部委託によるデザイン設計が未完成のまま放置されており、各エンジニアが担当機能のUI設計を自分で行う必要がありました。 - そのため実装に入るまでにタイムラグが発生しましたが、設計から実装まで自走して対応しました。 ## プロジェクトへの貢献 - サービスリリース後に、ログイン・認証基盤をAWS Cognitoへ移行するタイミングがありました。 - 前職でのVue + Amplify + 非Hosted UI構成の経験を活かし、不具合や手戻りなくスムーズな移行を実現しました。 - また、自社初のインターン生のメンターも担当し、育成・サポートに貢献しました（詳細はマネジメント能力のページを参照）。 ## 所属会社 スプリームシステム株式会社（現：株式会社GROWTH VERSE）

# 概要 異なるシステムに分散している会員データとLINEアカウントを紐付けるための技術調査を行いました。 調査の一環として、ID連携用のbot serverを開発し、試験運用までを担当しました。 # 調査の背景 LINE Messaging APIを活用してLINE配信を行うには、「LINE ID」と呼ばれる識別子が必要です。 これまではお客様側でLINE IDと顧客IDの紐付けを行い、自社のMAツールに連携してもらっていました。 しかし近年、お客様側での紐付けが難しいケースが増加し、「自社が提供する仕組みの中で紐付けを実現してほしい」というニーズが多数寄せられたことから、技術調査を実施することになりました。 # 特徴 - チーム構成：4名（バックエンドエンジニア2名、プロダクトオーナー1名、自分） # 自身の役割 - LINE ID連携用のbot serverの設計・開発・テスト・運用保守を担当しました。 # 工夫した点 - 当初はフロントエンド側でID連携用の画面を作成する想定でアサインされていましたが、調査を進める中で、公式LINEからのMessaging APIをバックエンドで直接受け取り、連携処理を行う構成が最適であると判断しました。 - 結果としてフロントエンドのタスクは発生しませんでしたが、Go言語の習熟も兼ねてbot serverの開発と試験運用を行いました。 # 所属会社 スプリームシステム株式会社（現：株式会社GROWTH VERSE）

# 概要 PRレビューにかかる時間の削減とコード品質の向上を目的として、AIによるコードレビュー機能の導入を担当しました。 企画から技術検証、導入、運用までを一貫して1名で対応しました。 ## 特徴 - AIコードレビューツールとして「CodeRabbit」を採用。 - コードレビューに加え、PRの差分の要約を自動生成する機能も活用。 - GitHub Actions用のYAMLファイルをリポジトリに追加する形で導入・実装。 - チーム構成：1名（単独対応） ## 自身の役割 - 開発面：実装、動作検証、運用保守を担当。 - 非開発面：サービス調査、費用試算、関係者への導入周知、開発チーム向けの勉強会を開催し、運用方法のトランスファーまでを実施。 ## 導入の結果 - 導入から数か月にわたり、PRのマージ数を継続的に計測した結果、導入前と比較して常に10〜20%の改善効果を確認。 - また、開発チームおよびプロダクトオーナーからもコードの可視化や確認コスト削減に役立つとの好意的なフィードバックを得ることができました。 ## 所属会社 スプリームシステム株式会社（現：株式会社GROWTH VERSE）

## 概要 自社プロダクトであるMAツール（クラウド版）のリリース後フェーズにおいて、新機能開発・運用保守を担当しています。Web/アプリ接客機能やシナリオ承認機能を主担当として開発し、画面仕様レベルの要件整理から設計・実装・単体/結合テストまで一貫して対応。運用面では障害調査・修正や軽微な改善対応も行っています。 また、1週間スプリントで進める開発体制の中で、Epic（機能開発単位。期間は規模により可変）が複数並行して走っており、メンバーが複数Epicを掛け持ちするケースもあります。Epicオーナーは持ち回り制で、同時期に「あるEpicではオーナー」「別Epicでは実装担当」のように役割を兼務しながら、要件整理・仕様決め・進行管理を担っています。 ## 特徴 - 1週間スプリントで開発を進行 - Epic（機能開発単位。期間は開発規模により可変）をベースに複数Epicが並行稼働 - Epicオーナーは持ち回り制で、同時期にオーナーと実装担当を兼務する場合がある - チーム構成：10名（フロントエンド3名、バックエンド2名、デザイナー2名、プロダクトオーナー1名、インターン2名） ## 自身の役割 - フロントエンドエンジニアとして新機能開発（画面仕様の詰め〜設計・実装・単体/結合テスト）および運用保守（障害調査・修正、軽微改善）を担当 - Epicオーナーとして要件整理・仕様決め・進行管理を担当（持ち回り制） - インターン生メンターとしてオンボーディング、タスク設計、週次1on1、PRレビューを担当 ## 開発において行なった工夫（失敗と改善） Web/アプリ接客機能の開発では、当初、納期都合やUX統一の意図、PO/関係者要望、仕様理解不足が重なり、Web向けとアプリ向けを「同じ機能」として一つの画面・内部処理に統合して実装しました。 しかし、開発を進める中で、ターゲティング条件の持ち方やチャネル固有設定など、Webとアプリで必要なオブジェクト構造の差分が想像以上に大きいことが判明。差分を無理に条件分岐で吸収したことで処理が複雑化し、拡張性を損ねる形で負債化しました（片側の修正がもう片側に副作用を出す／テスト観点が肥大化／開発速度低下など）。 改善のタイミングで自ら手を挙げ、破壊的変更を避けるためフラグによる切替と段階リリースを用いながら、新規作成画面の分離 → 管理画面の分離の順に作り直しを実施。併せてAPIおよび内部モデルも段階的に分割し、Web側の変更がアプリ側に波及しない構造へ整理しました。 結果として、機能追加が安全になり、バグが減少しデバッグも容易になりました。この経験から、共通化は見た目の類似だけで判断せず、データ構造と将来拡張を前提に境界を設計すること、負債は早期に手当てして再現性ある形へ戻すことの重要性を学びました。 ## 所属会社 - スプリームシステム株式会社（現：株式会社GROWTH VERSE）

## 背景 - QAチームは元々、正社員2名＋業務委託1名の3名体制。 - 2025年2月頃にQAリーダーが離脱し、同時期に業務委託も契約終了。残った正社員も入社数ヶ月で十分な引き継ぎがない状態だったため、短期間でQA体制が崩壊。 - 契約社員を1名採用したものの、2025年4月頃からリリース後のインシデントが多発し、顧客から「この状態が続くなら解約する」と指摘される状況に。 - これを受け、フロントエンド（自分）とバックエンド各1名が、開発時間の半分を割いてQAチームの立て直しに参画。 ## チーム構成（立て直し期間） - QA：1名（正社員）＋契約社員1名 - 開発支援：フロントエンド1名（自分）／バックエンド1名 - 立ち位置：開発所属のままQA立て直しを支援 ## 担当工程 - テスト方針の策定（品質担保の範囲の明確化） - テスト設計（観点整理、テストケース作成） - 不具合管理フローの整備（起票〜優先度〜トリアージの運用設計） - テストケース管理の整備（ツール／テンプレ／運用ルールの整備） ## 経験した職種・役割 - QAプロセス改善（開発所属での支援） - フロントエンドエンジニア（開発と兼務） ## 概要 QA体制が急激に縮小し、リリース後インシデントが多発した状況で、開発チームから自分とBEの1人が稼働の50%を割いてQAチームの立て直しに参画しました。 当初は、既存テストケースの最新版が判別できず、回帰テストで利用していたMagicPodについても「稼働しているもの／修正が必要なもの」が整理されていない状態でした。 その中で、毎週発生するEpic（機能開発単位）に対して最低限の品質を担保しつつリリースを継続する必要があったため、短期はマンパワーでQA対応しながら、並行して運用を立て直す方針で推進しました。 ## 進め方（段階的な立て直し） ### 1. 緊急対応（4〜5月） - 週次リリースを止めない前提で、既存仕様を踏まえた受け入れ観点を整備 - 受け入れ基準（完了条件）の明文化、バグ運用（優先度・トリアージ）の再設計 - QA/開発の役割分担を整理し、抜け漏れを抑止 ### 2. 基盤整備（〜6月） - テストケースを棚卸しし、「最新／要更新／不要」を分類 - テスト観点を整備し、EpicごとのQAで再現性が出る形に標準化 - 6月頃にテストケース整理が一段落し、自動化に着手できる状態へ移行 ### 3. 自動化の推進（6月〜12月） - MagicPodを用いた回帰テストの整備・拡充を推進 - 当初はMCPサーバー＋MagicPod組み込みのAIエージェントへ仕様書を読み込ませ、テストケース自動生成を狙ったが、AI性能およびトークン制約の観点から実運用は断念 - 代替として、まず「単体回帰テストの網羅」に方針転換し、2025年12月末までに整備を完了 ## 開発において行なった工夫 - リリース継続と立て直しを両立するため、「基準・運用の整備」→「ケースの棚卸し」→「自動化」の順で段階的に推進 - 役割分担と受け入れ基準を明文化し、属人化と品質のブレを抑制 - 自動化は「理想」から始めつつも、制約（AI性能／トークン）を踏まえて実現可能なゴールへ迅速に方針転換 ## 成果 - 定量的な指標の計測は未実施だが、体感としてリリース後インシデントはほぼ発生しなくなり、顧客からの問い合わせも減少した。 ## 所属会社 - スプリームシステム株式会社（現：株式会社GROWTH VERSE）

# 概要 タクシー配車アプリの保守・継続開発を担当しました。新機能の追加やバグ修正、パフォーマンス改善などを通じて、サービスの品質向上に貢献しました。 # 特徴 - 一部のシステムは10年以上保守されており、複数のリポジトリやデータベースが複雑に絡み合う構成でした。特にSQLの難読化が顕著で、理解と保守に高度な読解力が求められました。 - 開発フローは2段階のコードレビュー方式を採用しており、まず自社内での相互レビューを行い、その後お客様側の開発チームによるレビューを経てマージされるプロセスでした。 # 自身の役割 - アサイン当初の約4ヶ月間はアプリおよびサーバーサイドの保守・バグ修正を担当。 - その後、開発体制の再編に伴い、提携タクシー会社向けの業務支援システムの新規開発に参加し、サーバーサイドおよびフロントエンドの開発を担当しました。 # 保守対応時の実績 - GitHubにて管理されるIssueに基づき、お客様から週次で割り振られるタスクに対応。 - 主にiOSアプリのバグ修正を担当。 - 例：文言の見切れ修正、地図画面に表示されるピンの位置ずれの解消など。 - 一部、Rails製APIサーバーの改修も担当。 - レスポンスデータやバッチ処理の修正を実施。 - 難読化されたSQLの簡略化を行い、パフォーマンスを改善。 - 初めての実務経験であったため、積極的にメンバーのサポートを受けながらタスクの理解を深め、スピード感のある対応を心がけました。 - 結果として、アサインから2ヶ月後には、週次のタスクを水〜木曜中に完了・マージし、追加のタスクを任せていただけるようになりました。 # 業務支援システム開発時の実績 - Scalaを用いたAPI開発、TypeScriptを用いた業務用画面の開発を担当。 - 例：タクシードライバーの一覧表示画面の作成、ページング・ソート・削除機能の実装。 - 既存のシステム構成を理解しつつ、ユーザー体験の向上を意識したUI実装を行いました。 # 所属会社 株式会社ソニックス

# 概要 BLE通信で電動バイクと連携するスマートフォンアプリの開発・運用を担当しました。 # 特徴 - 他社が開発した初期バージョンを引き継ぎ、継続的にバージョンアップ・機能追加を行い、各種アプリストアにリリース。 - 各バージョンのリリース後に、Trelloを活用したKPT形式の振り返り会を実施し、継続的改善を図りました。 # 自身の役割 - 設計（FigmaによるUI設計、draw.ioによるフロー図作成）、アプリ開発（Android/iOS両対応）、API開発、DB修正、テスト、運用保守まで幅広く担当。 - アプリ開発ではAndroid/iOSの両方を担当し、対応比率はほぼ半々。 - マイナーアップデートの途中からプロジェクトにアサイン。 - アプリ開発には約1年半のブランクがあったため、言語学習や既存コード・資料の読み込みを通じて知識を補完し、独力で開発を進められる体制を整えました。 # 開発における工夫 - 実装者ごとのスキル差や、iOS/Android間の仕様差が原因で、マネージャーの想定と異なる実装が行われるケースがあり、手戻りが発生していました。 - この課題に対し、「マネージャーは大枠の設計のみ行い、実装担当者が詳細設計を作成 → テックリーダーとマネージャーがレビュー」というプロセスを導入。 - 実装者の意図や考えを可視化することで、認識齟齬を減らし、手戻り・修正の頻度を大幅に削減しました。 # メンバーへの働きかけ - 当プロジェクトでは使用技術やライブラリが多岐にわたり、新規参画時のハードルが高いという課題がありました。 - メジャーアップデートのタイミングで新メンバーが増員された際には、オンボーディング支援・開発力向上・レビュー観点の共有を目的に、モブプログラミングを提案・実施しました。 # 学び・得られた知見 - MapboxやChartsといった新しいライブラリを活用したことで、アプリ開発における表現力・技術スタックを広げることができました。 # 所属会社 株式会社ソニックス

# 概要 e-bike連動アプリの利用者に対して、利用規約の改定や新サービス開始のお知らせを通知するための、メール送信予約システムを新規開発しました。 # 特徴 - 既存のユーザー管理画面に対する機能追加として実装。 - 納品期限は約1ヶ月半と短期間で、フロントエンド・バックエンド各1名の2名体制での開発。 - 画面デザインなどの指定はなく、ゼロベースでのUI/UX設計・開発。 - ユーザー検索画面から条件に合致した利用者を抽出し、最大約20万通の一斉送信が可能。 - ユーザーがアプリで設定している言語に応じて、各ユーザーに適した言語でメールを送信。 - 対応言語は9言語（英語、スペイン語、ドイツ語、フランス語、イタリア語、オランダ語、日本語、簡体字、繁体字）。 # 自身の役割 - 画面設計（Excel）、DB定義書の作成、Swaggerを用いたAPI設計、Web画面（Vue + TypeScript）の実装を担当。 - Vue + TypeScriptの実装経験が浅かったため、休日を活用してチュートリアルやマイクロサービス開発を行い、技術理解を深めつつ開発を遂行しました。 # 開発における工夫 - バックエンド担当と連携し、テーブルレイアウトの設計からボトムアップで開発を進行。 - 設計段階では、成果物をお客様へ都度共有し、フィードバックを取り入れることで、完成イメージの齟齬をなくし、実装時の手戻りを最小化することを心がけました。 # 学び・得られた知見 - Swaggerを用いたAPI設計の実務経験を通して、設計段階での精度向上の重要性を学びました。 - Vue + TypeScript構成での実装経験を積み、SPA開発における基本的なアーキテクチャ理解を深めることができました。 # 所属会社 株式会社ソニックス

# 概要 モバイルアプリから外部ブラウザでアクセスするマイページおよび、管理者向けアドミン画面の開発を担当しました。 - マイページ：プロフィール編集、マイレージクラブ連携、無料・課金プランの選択、決済機能などを提供。 - アドミン画面：ポイントレートの設定やユーザーへのお知らせ配信などの管理機能を提供。 # 特徴 - 認証にはAWS Cognitoを使用。 - アドミン画面はHosted UI、マイページは非Hosted UI構成で実装。 - フロントエンドはUIフレームワークにVuetifyを採用。 - マイページは主にスマートフォン（特にiOS）からの利用を想定したレスポンシブ設計、アドミン画面はWeb専用。 - Stripeを利用した課金プランの決済処理を実装。 - 開発期間は1ヶ月半と限られた中で、マイページ画面12枚、アドミン画面16枚を実装。 # 自身の役割 - マイページ画面の実装全般を担当。 - お客様対応（進捗報告、質疑応答など）を行い、設計の不明点を逐次解消。 - アドミン画面については、工数見積もり、タスク割り振り、進捗確認、技術サポート、PRレビューなどのマネジメント業務を担当。 # 開発における工夫 - プロジェクト開始時点で、お客様側の設計（画面デザイン、DB定義、API設計）が未確定だったため、Slackで密に連携を取りながら柔軟に対応していきました。必要に応じてハドル通話を活用し、認識齟齬の防止に努めました。 - 限られた期間内での開発完了を実現するため、Composition APIを用いてメソッドの共通化を進め、工数削減に努めました。 # 開発中の課題と学び - Vue + Amplify + 非Hosted UI構成の実装事例が少なく、加えてCognitoの不具合が発生したことで、調査・対応に多くの時間を要しました。 - その過程で、AmplifyとCognitoを組み合わせた場合の制限や挙動に関する貴重な知見を得ることができました。 # 所属会社 株式会社ソニックス