ID:66708さん

## 概要 - 4名チームのマネージャーとして、プロジェクト管理・育成・人事評価・コードレビューなど、マネジメント業務全般を担当 ## 担当 - 基本設計 - プロジェクト進捗管理 - ピープルマネジメント - 人事評価 - 人材育成 - コードレビュー - 機能レビュー ## 使用技術 - PHP, JavaScript, AWS（EC2, RDS, Route53, CloudWatch）, MySQL - BacklogやSlackなどのチーム開発ツールを活用 ## 課題 - チーム内でメンバーの課題や目標が上長に伝わっておらず、育成や支援が行き届いていなかった - プロジェクト進行や品質担保の仕組みが属人的で、再現性に課題があった ## 取り組み - 1on1の仕組みを制度化し、メンバーとの定期的な対話を通じて状態を把握 - コーチングの考え方をベースに内省を支援し、自律的な成長につなげた - PdMと連携し、要件定義や基本設計フェーズから関与することで、仕様の明確化と開発の見通しを改善 - コードレビューに加え、実際に機能を触ってレビューする「機能レビュー」の文化を導入し、顧客視点を強化 - ガントチャートによるタスク・進捗管理で、プロジェクトを納期内に完遂 ## 工夫した点 - 1on1にコーチングの技術を取り入れ、傾聴による対話を実施。本人の考えを本人の言葉で表現してもらうことで、納得感と行動変容が生まれた - 「作るだけ」にならないよう、仕様の背景や目的をチームで共有する場を設け、顧客視点を保ち続けた

## 概要 - 問い合わせ件数の増加を課題と捉え、ユーザー自身がヘルプ検索で自己解決できる仕組みを構築 - RAG（Retrieval-Augmented Generation）を活用したヘルプ検索機能により、検索精度が向上 - 今後は検索頻度の高いカテゴリに対し、FAQやヘルプコンテンツをブラッシュアップする予定 ## 担当 - 要件定義 - 詳細設計 - 実装 - テスト - 運用・保守 ## 使用技術 - PHP, JavaScript, MySQL - AWS（EC2, RDS, CloudWatch） - Azure AI Search, Azure OpenAI Service ## 課題 - お問い合わせ件数が増加傾向にあり、CS対応の負荷が高まっていた - ヘルプ記事の検索精度が低く、ユーザーが自己解決に至れず結果的に問い合わせにつながっていた - FAQや記事の内容に社内の知見が十分反映されていなかった ## 取り組み - 問い合わせ内容を定量的に分析し、CSチームと連携してカテゴリごとに整理 - 社内ナレッジをFAQやヘルプに落とし込み、RAG検索対象として整備 - ベクトル検索による精度向上とキーワード検索の併用で、ユーザーの検索体験を改善 - Azure導入にあたっては費用見積もりを行い、導入承認を取得 - Azure OpenAI Serviceで社内FAQ・ヘルプ記事をベクトル化し、検索基盤を構築 - Azure AI Searchにより、従来のキーワード検索に加え、意味ベースのベクトル検索を可能にした ## 工夫した点 - 表面的に現れている課題だけに着目せず、その先にある本質的なお困りごとを引き出すことを意識 - お困りごとの解決に必要なことを整理し、ロードマップを描いた状態でプロジェクトをスタート - スモールスタートにすることで、工数をかけすぎず最適なアプローチができるようにした - ヘルプの検索ワードを保存することで、今後の改善への情報収集を行った - CSが新しくヘルプ記事やFAQを作成・編集した時に、リアルタイムで検索基盤へ反映させることで、CSの手間を増やさない仕組み作り - ベクトル検索とキーワード検索を併用し、精度とユーザーの検索行動に配慮したUXを実現

## 概要 - 開発初期は単体テストが存在せず、バグの混入やリファクタリングのしづらさが課題となっていた - 長期的な品質向上と開発効率の向上を目的に、テスト環境の整備およびテスト文化の定着に取り組んだ ## 担当 - PHPUnitによる単体テストの導入とルール整備 - CI/CDパイプラインへの自動テスト組み込み - コーディング規約策定や勉強会の実施 - 運用・保守 ## 使用技術 - PHPUnit - AWS CodePipeline / CodeBuild / Step Functions - Slack（通知連携） ## 課題 - 手動テストによる確認コストが高く、バグ混入のリスクも高かった - テストが存在しないことでコードの変更に慎重にならざるを得ず、リファクタリングが進まなかった - チームとしてテストを書く習慣やルールが整っていなかった ## 取り組み - 単体テストの重要性をまとめ、マネージャー層に提案・承認 - PHPUnitを導入し、テスト用のディレクトリ構成や記法ルールを整備 - テストが書きやすい設計を意識することで、テスト駆動を促進 - チーム全体にテストコードの書き方およびテスト導入のメリットを伝える勉強会を開催 - AWS Step Functions・AWS CodePipelineを利用し、プルリクエスト作成時・デプロイ時に自動テスト実行 - テスト失敗時はSlackにメンション付きで通知が届く仕組みを構築 ## 工夫した点 - コーディング規約にテストルールを明記することで、属人化を防止 - CI/CDに自動テストを組み込むことで、テストの有無が開発プロセスの一部として定着 - 「テストがあるから安心してリファクタリングできる」文化づくりを推進

## 概要 - 営業・マーケティング支援SaaSにおいて、ユーザー体験と業務効率を向上させる複数の新規機能開発を担当 - 詳細設計から実装、改善提案まで携わり、ユーザーにとって本当に価値ある機能を追求 ## 担当 - 詳細設計 - 実装 - テスト - 運用・保守 ## 担当機能 - Webパーソナライズ機能の実装（ターゲット別ポップアップ表示） - 名刺画像AI解析によるリード情報の自動登録機能 - Webhook機能の設計・実装とUI改善 - ドメイン駆動設計を参考にした設計・クラス分割による保守性向上 ## 使用技術 - PHP - JavaScript - Azure Document Intelligence（名刺OCR） - AWS EC2 / RDS / CloudWatch - MySQL ## 課題 - 初期実装では1ファイルに複数の責務が集中しており、保守性や拡張性に課題があった - Webパーソナライズ機能のターゲット条件に応じた処理の負荷や複雑性が高く、パフォーマンスやへの配慮が必要だった - UI仕様が不明瞭で、現場の要望を反映しきれていなかった ## 取り組み - 詳細設計以降を一人で担当 - Webパーソナライズ機能においては、属性・行動履歴に応じた出し分けを設計 - パフォーマンスを考慮し、DBへのインデックス追加やメモリ・計算量を意識した実装を実施 - UIについては仕様書をもとに課題を整理し、事業部とPdMに提案し改善を実施 - 名刺AI解析機能では、名刺画像をAzureで解析し、リード情報を自動登録できる仕組みを構築 - Webhookでは、操作に応じた外部連携処理に加え、実行ログ画面の追加提案・実装を行った - 全体を通じてドメイン駆動設計を参考に、業務ルール・データ構造の明確化とクラス設計を実施 ## 工夫した点 - コードの可読性と拡張性を意識し、単一責任の原則を徹底 - ターゲットによって負荷の高い処理を回避するために、DB設計やキャッシュを最適化 - 顧客や事業部の声を直接聞きながら仕様を調整し、納得感のあるUIを提供

## 概要 - 利益率の向上および継続的な開発リソースの確保を目的として、AWSコストの削減に着手 - チーム内にインフラコストを管理する担当者が不在だったため、自発的に取り組んだ ## 担当 - AWSコスト最適化提案 - AWSコスト最適化の実施 - 効果検証と関係者への定期的な報告 ## 使用技術 - AWS（EC2, RDS, CloudWatch, S3, Lambda など） - AWS Cost Explorer ## 課題 - AWSのコストを管理する担当がおらず、コスト意識が低さから不要リソースが放置されていた - ログ出力量が多く、CloudWatch Logs等の運用コストが増大 - オンデマンドインスタンス運用が多く、長期利用に対して割高な構成となっていた ## 取り組み - 実際のコストの分析・整理し、解決策をCTOに提案・承認 - インフラ関係者を巻き込み、コスト削減の取り組みを先導 - AWSの公式ドキュメントや書籍を通じて最適化手法を体系的に学習 - リソース単位で稼働状況を分析し、不要なリソースを停止・削除 - ログ出力設定を見直し、不要なログの抑制・保持期間の最適化を実施 - 長期間稼働が見込まれるEC2インスタンス・RDSインスタンスに対してSavings Plans／リザーブドインスタンスを購入 ## 工夫した点 - コスト削減効果がチーム内で見えるように、月次レポート形式で継続的に共有 - 最適化内容を属人化させず、ドキュメント化してチーム全体で継続的にメンテナンスできるようにした - 削減率などインパクトを示す数字にこだわり、最終的に月間約10%のコスト削減を達成

## 概要 - 社内で使用しているCTIツール（Amazon Connect）と自社プロダクトをリアルタイム連携 - 電話対応時の顧客情報表示とSlack通知を実現 - 対応品質と業務効率の向上 ## 担当 - 実装 - インフラ構築（Lambda、DynamoDB、Amazon Connect、S3） ## 使用技術 - Amazon Connect - AWS Lambda - DynamoDB - Amazon S3 - python ## 課題 - 電話を受けても相手の情報がわからず、対応しながら手作業で顧客情報を調べていた - 対応中の情報取得が不十分で、問い合わせ対応品質に課題があった ## 取り組み - Amazon Connectからのリクエストに応じ、LambdaがDynamoDBに登録された顧客情報（氏名、会社名、案件リンク、アカウント名）を取得し、画面に表示 - 電話に出られなかった場合は、取得した情報をまとめてSlackへ通知 - リアルタイムかつ最小操作で顧客情報を参照可能な仕組みを構築 ## 工夫した点 - 手作業での検索を不要とすることで対応時間とストレスを削減 - Amazon Connectの問い合わせフローを再構築し、お客様体験の向上 - 受電時にクリックひとつで必要情報へアクセスできるUI設計により、業務効率を大幅に改善