ID:84071さん

# SaaS CRMプロダクトの機能開発・改修・リプレイス ## プロジェクト経験概要 自社CRMプロダクトにおいて、機能追加・不具合改修・リプレイスを継続的に担当。日常的な改修業務に加え、既存機能のTypeScript移行・API化、新機能の要件定義から実装まで一人称で対応した。 ## チーム情報 - 担当：複数名（プロジェクトにより異なる） - 役割：バックエンド開発・要件定義・設計・実装・テスト・運用保守 --- ## 開発・実装内容 ### 【概要】 自社SaaS CRMプロダクトの継続的な機能開発・改修・リプレイスを担当。標準パッケージの機能追加・不具合対応を日常業務として行いながら、大きな改修プロジェクトにも並行して関与した。 ### 【どのような機能の開発・実装か】 **日常的な改修・機能追加** - 既存機能の不具合調査・修正 - 顧客からの要望に基づく機能改修・追加 - 標準パッケージへの機能フィードバック **主要プロジェクト** - PHP/ZendFrameworkで実装されていた顧客データ処理をTypeScriptベースのAPIへリプレイス（要件定義を主担当・設計実装の一部を担当） - CRM顧客データの変更履歴機能を要件定義から設計・実装・リリースまで一貫して担当 - 営業メール向けGmailワンクリック配信停止（List-Unsubscribeヘッダー）機能の追加 ### 【課題・問題点】 **既存実装の保守性** PHP/ZendFrameworkの実装は型保証がなく、コードの規模が大きくなるにつれて変更の影響範囲が把握しにくくなっていた。改修のたびに影響範囲の調査に時間がかかり、開発効率を下げる構造的な課題があった。 **TypeScript移行・API化** 既存はバッチで一括処理する実装だったが、社内外のシステムから任意のタイミングで呼び出せる構造に変える必要があった。社内用途と外部（顧客向け）の両方から利用するため、認証・権限管理・レスポンス設計を用途に応じて整理することも求められた。 **新機能の要件定義** 変更履歴機能など、顧客の運用フローに直結する機能の要件定義では、顧客担当者との認識齟齬をなくしながら仕様を確定する必要があった。 ### 【打ち手・使用した技術】 **日常的な改修対応** - 不具合の原因をログ・データベースで調査し、影響範囲を特定したうえで修正・テスト・リリース - 標準パッケージの改修は影響範囲が広いため、既存機能への影響確認を丁寧に実施 **TypeScript移行・API化（4名チームで担当）** - 要件定義を主担当として進め、既存PHPの処理フローを整理・TypeScriptでの型定義・構造設計の一部を担当 - 顧客データ処理ロジックをTypeScriptで実装し、社内外から呼び出せるAPIとして切り出し - 内部・外部それぞれの用途に応じたエンドポイント設計・認証処理を実装 - 既存バッチのロジックをAPIに適した形で分割・整理し、任意タイミングでの呼び出しを実現 **新機能開発** - 変更履歴機能：顧客の運用フローをヒアリングしながら要件を確定し、設計・実装・リリースまで一貫担当 - Gmail配信停止機能：List-Unsubscribeヘッダーの仕様を調査・実装し、Gmailのワンクリック配信停止に対応 **使用技術：** PHP / ZendFramework / TypeScript / Node.js / MySQL / Amazon Aurora / AWS EC2 / AWS Lambda / Amazon ECS / Amazon ECR / Amazon S3 / Amazon Athena / Amazon CloudWatch / Docker / GitHub ### 【成果】 - 型安全なTypeScriptへ移行し、変更時の影響範囲の把握が容易になった - バッチ処理だった機能をAPI化し、社内外のシステムから任意のタイミングで呼び出せる柔軟な構造に変更 - 変更履歴機能・Gmail配信停止機能など、顧客の運用フローに直結する機能を要件定義から一貫して実装

# エンタープライズ向けCRMデータ外部システム連携基盤の構築 ## プロジェクト経験概要 自社CRMが保有する顧客データを、エンタープライズ顧客が利用する外部システム（Salesforce・基幹システム）へ一方向に連携する基盤を構築。要件定義・仕様策定・設計・実装・テスト・リリース・保守までを一人称で担当。顧客担当者との直接折衝もエンジニアとして主導した。 ## チーム情報 - 担当：1名（自分のみ） - 役割：顧客折衝・要件定義・設計・実装・テスト・リリース・保守を一貫して担当 --- ## 開発・実装内容 ### 【概要】 自社CRMの顧客データをSalesforceおよび基幹システムへ定期バッチで一方向同期する連携機能の構築。標準パッケージでは対応できないエンタープライズ顧客向けのカスタム開発として実施。 ### 【どのような機能の開発・実装か】 - 自社CRMが保有する顧客データを定期バッチで外部システムへ送信する連携基盤 - 連携先：顧客の基幹システム（2システム） - 連携方式：バッチによる定期実行（一方向・外部への送信のみ） - 逆方向（外部システム→自社CRM）の取り込みはスコープ外とし、データの責任範囲を明確化 ### 【課題・問題点】 **① 項目マッピングの複雑さ** 自社CRMのデータ構造と外部システムのデータ構造は異なるため、どの項目をどの形式で連携するかをケースごとに顧客と一つずつ確定する必要があった。顧客の要望は多岐にわたり、対応可能なものと不可能なものを整理する作業に時間がかかった。 **② 顧客要望の取捨選択と合意形成** 顧客から「この項目もこの形式で出してほしい」という要望が複数あったが、自社CRMのデータ構造上、技術的に対応できないケースも存在した。「できない」と伝えるだけでは顧客の納得を得られないため、なぜ不可能なのかをデータ構造の観点から説明し、代替案を提示しながら合意を取る必要があった。 **③ エラー・連携失敗ケースの事前設計** リリース後に「データが連携されていない」「件数が合わない」などの問い合わせが発生することが想定された。リリース後の対応方針をあいまいなままにしておくと、障害発生時に顧客との認識齟齬が生じるリスクがあると判断した。 ### 【打ち手・使用した技術】 **要件定義・仕様策定のアプローチ** - 連携する項目・形式・タイミングをケースごとにリスト化し、顧客と1項目ずつ確認・合意 - 対応不可能な要望には、データ構造・システムの制約を図や言葉で説明し、代替案（近似する別項目での代替・出力形式の変更など）を提示して合意を取得 - 合意内容はドキュメントに記録し、後工程での認識齟齬を防止 **非機能要件の事前合意** - エラー発生時・連携件数が合わない場合の対応フローをリリース前に顧客と合意 - 「どのエラーは自社で対応するか」「どのエラーは顧客側で確認が必要か」を切り分けてドキュメント化 - リリース後の問い合わせ対応フローをサポートチームにも共有し、エスカレーションラインを整備 **実装方針** - 定期バッチによる一方向データ送信 - 連携失敗時のリトライ設計・ログ保存による追跡可能性の確保 **使用技術：** PHP / MySQL / Aurora / AWS（ec2） ### 【成果】 - 顧客との要件合意から保守まで一人称で完結し、リリース後も安定稼働 - エラーケースの事前合意により、リリース後の問い合わせ対応をスムーズに運用 - 仕様策定プロセスをドキュメント化し、後続の連携案件で再利用可能なテンプレートとして社内展開

## プロジェクト経験概要 リーダー職ではない立場から、5名チームの全体進捗管理と工数調整を自発的に担当。タスクの依存関係と工数を洗い出し、週次スケジュール共有会を自ら立ち上げてファシリテート。ボトルネックとなるタスクの早期特定と担当者間の作業分散を提案し、PM不在時には意思決定の代行や関係者への連絡・調整も行った。その結果、「リーダー職でなくても動ける人」として認識され、この役割を継続して担った。 ## チーム情報 - 担当：5名チームのスケジュール管理を1名（自分）で担当 - 役割：進捗管理・工数調整・ファシリテーション（正式なリーダー職ではない立場から自発的に担当） --- ## 開発・実装内容 ### 【概要】 SaaSプロダクトの保守対応と受注案件の開発を並行して担う5名チームにおいて、スケジュール管理の構造的課題を特定し、仕組みとして解決した。 ### 【どのような取り組みか】 - 全案件のタスク・依存関係・工数・担当者をClickUpで可視化 - 週次スケジュール共有会を自ら立ち上げ、ファシリテーションを継続担当 - ボトルネックの早期特定と担当者間の作業分散提案 - PM不在時の意思決定代行・関係者への連絡調整 ### 【課題・問題点】 **保守工数がスケジュールに含まれていなかった構造的問題** チームの業務は「受注案件の開発」と「保守対応（問い合わせ・インシデント対応）」の2種類だったが、スケジュールには受注案件の工数しか計上されていなかった。保守対応は「なんとなく」こなしている状態で、工数として明示されていなかった。 保守対応が含まれていなかった理由は、問い合わせ件数が時期によって大きく変動するためで、「工数として出しにくい」という認識が続いていた。この構造により、保守対応が発生するたびに受注案件の工数を圧迫し、スケジュールが後ろ倒しになる問題が繰り返されていた。 ### 【打ち手】 **保守工数を「最低限のバッファ」として明示化** 変動があるからといって工数をゼロにするのは誤りと判断し、「平均的に最低これだけは発生する」というミニマムの工数を定義してスケジュールに必ず組み込む方式を提案。過去の保守対応の傾向をもとに「週あたりの最低保守工数」を設定し、マネージャー・リーダーへ説明・合意を取った上でスケジュールの前提として組み込んだ。 **受注工数は保守バッファを引いた残りで計算する順序に変更** 保守工数を確保した上で、残りのキャパシティに対して受注案件の工数を割り当てる順序に変更。それまでは受注案件ありきで工数を組んでいたため、保守対応が発生するたびに詰まっていた構造を解消した。 **ClickUpで全体を可視化・週次共有会を運営** 各メンバーのタスク・工数・期日をClickUp上で管理し、週次でチーム全員が現状を確認できる場を設けた。負荷の偏りをリアルタイムで把握し、作業分散を提案できる状態を維持した。 **使用ツール：** ClickUp ### 【成果】 - 保守バッファの導入により、スケジュールが実態に即した形で組まれるようになり、受注案件の遅延が減少 - メンバーの負荷状況が数字として可視化され、作業分散の提案がしやすくなった - リーダー職ではない立場から継続して担う存在として認識され、PM不在時の意思決定代行も任された

# 本番インシデント対応・保守運用 ## プロジェクト経験概要 サポートチームからエスカレーションされる本番インシデントに対して、原因特定から暫定対応、恒久対応、再発防止策の策定まで対応。CloudWatchやログ解析、データベースを用いて原因を分析し、暫定対応でサービス影響を最小化。設計レベルでの恒久対応を実装・テストし、リソース制約で即時の根本解決が難しい場合はサポートチームと連携して運用回避策を策定し、顧客への案内まで推進。インシデントレポートを作成し、チームへ横展開することでナレッジを共有。3年6ヶ月で約100件の問い合わせ対応し、根本原因の解消によって再発件数を低減し、対応フローのドキュメント化で属人化を解消した。 ## チーム情報 - 担当：複数名（自分を含む） - 役割：インシデント対応・原因分析・恒久対応実装・再発防止策策定 --- ## 開発・実装内容 ### 【概要】 自社CRMプロダクトの本番インシデント対応を継続的に担当。3年6ヶ月で約100件に対応し、対応フローの整備と属人化解消を実現。 ### 【どのような機能の開発・実装か】 - サポートチームからエスカレーションされるインシデントの原因特定・対応 - 暫定対応・恒久対応・再発防止策の一連の対応フロー - インシデントレポートの作成とチームへのナレッジ横展開 - 対応フローのドキュメント化による属人化解消 ### 【課題・問題点】 - 本番障害発生時に原因特定から対応完了まで一貫して担う必要があった - リソース制約で根本解決が即座にできないケースでは、顧客への影響を最小化しながら運用で対処する必要があった - 対応ナレッジが属人化しており、担当者によって対応品質にばらつきがあった ### 【打ち手・使用した技術】 **インシデント対応フロー** - CloudWatch・ログ解析・データベースを用いた原因分析 - 暫定対応でサービス影響を最小化しつつ、設計レベルでの恒久対応を実装・テスト - 根本解決が難しい場合はサポートチームと連携し、運用回避策を策定して顧客へ案内 **再発防止・ナレッジ共有** - インシデントレポートを作成し、チームへ横展開 - 対応フローをドキュメント化し、誰でも対応できる体制を整備 **使用技術：** Amazon CloudWatch / MySQL / Amazon Athena ### 【成果】 - 3年6ヶ月で約100件のインシデントに対応 - 根本原因の解消によって再発件数を低減 - 対応フローのドキュメント化で属人化を解消