ID:68115さん

#### プロジェクト概要 [HR 系の Sass](https://nalysys.jp/service/)の開発（マイクロサービス）<br> #### 役割 （2022.12〜2023.11）[サービス共通の基盤プロダクト](https://support.nalysys.jp/admin/)チームの開発メンバー<br> （2023.11〜2024.2）上記プロダクトチームのリーダー<br> （2024.2〜2024.4）新規タレントマネジメントプロダクトの開発メンバー、のちに開発リーダーとしてプロジェクトマネジメント、プロダクトマネジメント、チームマネジメント #### 担当業務（経験した業務） プロダクトエンジニア、開発リーダーとして、プロダクトマネジメント、プロジェクトマネジメント、チームマネジメント、開発、法人営業の経験あり。<br> #### 使用技術 React | Next.js | TypeScript | NestJS | GraphQL | Terraform | Google Cloud #### 発揮したバリュー 1 ##### 【状況】 配属効率化のための機能の一部として、上司と部下の性格相性をもとにマッチングを行い最適な配属案を自動で提案するという企画が立案された。 ##### 【行動】 プロダクトマネジメント・プロジェクトマネジメントに加え、営業活動まで一貫して担当。 - 競合差別化の核として、社内人事部門を巻き込み、性格検査に基づく相性定量化アルゴリズムを開発。その新規性と独創性が評価され、発明として特許を出願。 - バックエンド 1 名、フロントエンド 1 名、デザイナー 1 名という少人数構成の中、2 ヶ月での開発完了を目標に QCD 管理を徹底。スコープ・スケジュール・品質・リスクマネジメントを担い、安定した進行を実現。 - プロダクトの市場価値を自ら検証するため、従業員 3,000 名以上のエンタープライズ企業 170 社へアウトバウンドコールを実施し、4 件の商談を創出。自身が獲得した商談は自ら出席し提案。他営業担当が獲得した案件にも開発（プロダクト）責任者として同席し、技術的・企画的な観点から価値提案を行った。 - 自ら商談していく中で、「相性だけでは訴求が弱い」という課題を早期に発見し、「新卒の早期離職率改善」というより経営課題・人事部門の課題に直結する訴求軸への戦略転換を営業チームに提言。 - ユーザーインタビューや商談から得た顧客の生の声を分析。配属効率化というニーズは実際にあったのでそのニーズを満たすための機能開発は引き続き続行。業界を問わず共通していた「配属先部署の必要人数も考慮したマッチング」という要件を特定し、開発工数対効果（ROI）を考慮した上で、最優先で実装すべき機能として企画・提案。 - 一方、ROI の観点から費用対効果の低い機能開発については、開発チームやプロダクトマネージャーを巻き込んで開発中止を提案。技術的負債の発生を未然に防ぎ、開発リソースの最適化を実現。 - 全社導入を検討してもらった大手顧客から要望を受けた際は、AI コーディングエージェントを活用し、数時間でプロトタイプを開発。高速な仮説検証サイクルを回し、顧客の潜在ニーズを引き出すことで、全社導入の確度向上に貢献。 ##### 【結果】 一連の取り組みにより、本機能に魅力を感じてくれたエンタープライズ企業 1 社の正式導入と自プロダクト単体での初受注が決定。 #### 発揮したバリュー 2 ##### 【課題・状況】 有償利用顧客がゼロの状態からのスタートで、ある企業の担当者が「毎月の組織図の更新作業が Excel では煩雑で手間がかかる」と課題を抱えていることが判明した。 ##### 【行動】 この状況に対して、まず目の前の顧客の課題を解決して自プロダクト初の売上を獲得するために、プロダクトマネージャー兼プロジェクトマネージャーとして企画・要件定義・開発マネジメントを一貫して担当。 - まずは n=1 の顧客にフォーカスし、ニーズを深掘り。売上獲得と顧客満足の最大化を両立するため、業務フローに深く入り込み、実際の課題を反映した組織図編集機能の実現を目指した。 - ヒアリングを複数回実施し、課題を温度感の高い順に整理。実現可能性とインパクトのバランスを踏まえて機能を決定。 - MVP（Minimum Viable Product）思考で開発スコープを明確化。must と nice-to-have を切り分け、顧客と合意を取りながら初期スコープを圧縮。早期リリースとフィードバックループの高速化を図った。 - 要件定義段階からエンジニア・デザイナーと連携し、技術面・UX 面での妥当性を検証。編集者間のコンフリクト管理においては、事業部で前例のなかった技術的アプローチが必要だったため、テックリードと共に早期に設計方針を決定し、実装リスクを最小化。 - 開発体制は、バックエンド 2 名・フロントエンド 1 名・技術サポート 1 名、デザイナー 1 人の構成で、2 ヶ月半というタイトなスケジュールの中でプロジェクト運営を実施。 - 新たに参画したバックエンドエンジニア 2 人との認識の統一のため、自らドメインモデルの初期叩き台を作成し、開発チーム全体でのドメインモデリングを主導。 - コスト削減の観点では、開発前段階でのスコープ調整、最小限のリソースによる開発推進、加えて QA チームの打鍵作業を自ら巻き取ることで QA リソースの削減を行なった。 - クオリティ向上の観点では、QA チームへのテスト設計作成依頼、フロントエンド・バックエンド含めたコードレビューを行なった。 - スケジュール遵守に向けては、初期スコープ調整・顧客との進行管理・チームメンバーの進捗確認に加えて、遅延発生時には自らが一部開発タスクを巻き取ることでリカバリー対応を実施。 ##### 【結果】 スケジュール優先から途中でクオリティ優先への方針転換を行いながらも、難易度の高い技術要件や新規メンバーとの協業といった不確定要素の多い状況下でもプロジェクトを安定運用し、最終期日内に高品質なリリースを実現。<br> 顧客からは「これまで話してきた内容が正確に反映されていて良い」とのフィードバックを獲得。<br> その後、顧客の予算都合により当該案件での売上にはつながらなかったが、別の顧客で他プロダクトとのクロスセルではあるが導入が実現し自ブロダクトに初売上をもたらした。 #### 発揮したバリュー 3 ##### 【課題・状況】 既存機能ではサーベイ（アンケート）をメールで一斉配信していたが、メールに気づかず未回答となる従業員が一定数存在していた。複数の顧客から「チャットツールでも通知したい」との要望があり、回答率向上と管理工数削減が期待されていた。 ##### 【行動】 本件において企画・要件定義・画面設計・基本設計・開発・リリースまでを一貫してリード。 - 【企画立案】 PdM と連携しつつ、「本当にやる価値があるのか」をゼロベースで検討。以下の観点から、プロダクトとしての価値が高く、かつビジネスインパクトが大きいと判断し、自ら提案・企画。 - 回答率向上はプロダクトの価値向上に直結する - 実際の営業商談動画から複数の顧客要望が確認できた - 海外文献や実データを調査し、チャット連携により回答率が上昇した事例が多数あることを確認 - 【要件定義】 顧客価値の早期提供を重視し、MVP 設計を意識してスコープを明確化。 - 顧客層が IT 企業中心である点から、初期実装は Slack に絞り、他ツール連携は将来的な拡張とした - 競合の類似機能については実装価値を再評価し、PdM と交渉の上、初期リリースでは非対応とし開発負荷を最適化 - 【画面設計】 自らワイヤーフレームを作成し、デザイナーと連携。PdM・デザイナーとディスカッションを重ね、プロダクト思想に沿った画面にブラッシュアップ。 - 【基本設計・開発】 他チームのプロダクトとの連携を要する複雑な構成だったが、BE 領域を 1 人称で担当。具体的な技術的取り組みは以下。 - Slack App の作成および認証処理 - Cloud KMS によるアクセストークンの暗号化 - Slack API を用いた通知処理の設計・実装 - 特に予約通知のスケーラビリティに課題があり、Slack API の Rate Limit 回避のために Cloud Tasks を用いた時間差通知処理を設計。これにより数千人規模のユーザーへの安定通知を実現 - DB 設計および API 開発 - 関連する Terraform 定義の整備・更新 - FE 実装のコードレビュー対応 【リリース・運用】 他チーム・ビジネス部門と連携してスケジュールを調整し、リリースまでを完遂。リリース後の不具合調査・改修までを一貫して対応。 ##### 【結果】 社内での結果 - 回答率の上昇（90%→92%） - マネージャー層が未回答者に人力でリマインドしていたものが自動でリマインドされるようになり工数削減 #### 発揮したバリュー 4 ##### 【課題・状況】 事業部内で他開発チーム、他職種とのコミュニケーションが少なかった。 ##### 【行動】 定期的に他開発チームや他職種を交えたランチや MTG を開催。具体的には以下。<br> - 2 週間に 1 回、異なる開発チームからメンバーを集め、今やっている業務や各チームの雰囲気について話題を振って各人の関係づくりやナレッジの共有ができるような場を醸成 - 1 ヶ月に 1 回、営業と開発を交えたランチを開催。各職種のメンバーに対してチームの状況や課題感について話題を振って各人の関係づくりや職種を超えた情報交換ができるような場を醸成 - 自分が開発した機能について、チーム内だけではなく営業も含めてレビュー会（機能お披露目会）を実施して、実際に機能を触ってもらったフィードバック（FB）を回収。いただいた FB については優先度や対応の可否を PdM と相談し、対応した FB については対応した旨、対応しなかったいくつかの FB については対応しなかった理由を営業に共有することで、開発と営業の信頼関係構築に貢献。 #### 発揮したバリュー 5 ##### 【課題・状況】 フロントエンドで CSS のデグレが起きたり、レビュワー・レビュイーともにデグレの人力確認で工数がかかっていた。 ##### 【行動】 仕組みで解決するために画面単位のビジュアルリグレッションテストを自ら導入。<br> 具体的には、Playwright で全画面のスクリーンショットを撮影、スクリーンショットを GCS（Cloud Storage）に保存、最新のブランチのスクリーンショットと比較し差分があれば検知してくれる仕組みを CI で構築。 ##### 【結果】 やってみたが、画面全体のスクリーンショットの撮影だと CI の実行が遅いこと、Flaky なテストになってしまったからあまり有効的には活かせなかった。ただ、結合テストで行なった方が CI の実行時間が短く有用であるという知見は得ることができた。 #### 発揮したバリュー 6 マイクロサービスの新規プロダクト開発において以下を主導で行なった。 - BFF の構築 - Google Cloud・Terraform を用いて開発環境とテスト環境の構築 - CI/CD パイプラインの整備 - エラーログの Slack への通知 - Compute Engine の高可用性対応 #### 発揮したバリュー 7 ##### 【課題・状況】 ① BE のリポジトリにおいて、長年アップデートされていないことで、脆弱性の指摘やサポートがもうすぐ切れるライブラリが複数存在していた。<br> ② アップデートしようにも他のライブラリが依存、そのライブラリにも別のライブラリが依存しているなど、依存関係が複雑に絡みあっていて（ex. peer-dependencies のエラーが 10 個ほど出る）容易にアップデートできない。<br> ③ アップデートすると破壊的変更が起きる（ex. TypeORM 0.2→0.3、Apollo Server v2→v4）。 上記の理由からバックエンドのあるマイクロサービスで技術的負債となっていた。 ##### 【行動】 ① を受けてライブラリのバージョンアップに着手。<br> ② に対しては、ライブラリをアップデートしたときに吐き出されるエラーから、どのライブラリがどのライブラリに依存しているか、どのバージョンなら解決できるかを紐解いて整理。<br> アップデートする際に対応していないライブラリが出てきた場合は、そのライブラリの代わりに別のライブラリをインストール。<br> これを繰り返して全ての依存関係のエラーを解消。<br> また、更新が止まっていそうなライブラリが存在した場合は、将来的なリスクも鑑みライブラリを使わない独自実装に切り替えた。<br> ③ については、ライブラリの GitHub や公式ドキュメントのマイグレーションガイドから変更箇所を読み解き、既存のコードに合う形にコードを修正。<br> また、アップデートにより変更があった箇所や修正していく中で詰まった箇所は、解決法とともにドキュメントにまとめ他チームに展開することでナレッジの共有をおこなった。 ##### 【結果】 1 ヶ月ほどかけてライブラリをバージョンアップし、脆弱性を大きく減らすことができたともに技術的負債の解消に貢献した。 #### 発揮したバリュー 8 ##### 【課題・状況】 セキュリティの観点から、事業部内の全チームでファイルアップロードの実装方法の変更と新規のマイクロサービスへの移行が必要になった。 ##### 【行動】 自チームの移行・実装を担当。 具体的には - FE、BE、インフラ含め影響範囲を洗い出し - FE、BE、インフラをどの順番でどのような実装に修正すればダウンタイムなしで移行できるか整理しタスクを細分化 - 整理した事項に基づき、以下を全て一人称で担当 - インフラ：移行にあたって必要な Terraform の修正や Google Cloud の設定を追加 - BE：新規のマイクロサービスへの移行、API の修正・新規作成 - ︎FE：修正した API の繋ぎ込み部分を修正 #### 発揮したバリュー 9 ##### 【課題・状況】 2000 件のデータを取得する API の実行時間が 25 秒ほどかかっており UX が低下している箇所があった ##### 【行動】 フロントエンドとバックエンドの両方から改善を試みた。 フロントエンドでは、API を実行している関数を React の hooks を用いて最適化、使用していない値をそもそも API で取得しないように修正することでオーバーフェッチングを解消。 バックエンドでは、API で取得している値の中でいくつか n+1 問題が起きていたので、dataloader を用いて SQL のチューニングを実施。 ##### 【結果】 フロントエンドの改善で約 5 秒、バックエンドの改善で約 10 秒ほど、計 15 秒ほど実行時間を短くすることができた。