ID:66681さん

| 項目 | 内容 | |------|------| | 期間 | 2026年6月 〜 現在 | | カテゴリ | Webサービス / SaaS / 業務システム | | 担当工程 | 要件定義・設計・実装・テスト・インフラ運用 | | 役割 | バックエンド・フロントエンド・インフラ・テックリード | | チーム編成 | PM 1名 / 開発者 3名（自身 + インド人エンジニア 2名）/ ビジネスチーム 2名 | | 使用技術 | PHP (Laravel) / React / Inertia.js / TypeScript / Go / MySQL / AWS / Docker / Caddy / Claude Code | **概要** リリース済みの EOR（Employer of Record）プラットフォームにおいて、**顧客に最適な候補者を提案するマッチング機能**の新規開発を、2026年6月の入社直後から要件定義フェーズより主導しています。バックエンド・フロントエンド・インフラを横断的に実装し、インド人エンジニアと日本側ビジネスチームの橋渡し役を担っています。 **課題（背景）** 候補者提案の質は、プラットフォーム内の構造化データだけでは高めきれませんでした。候補者の実態を判断する文脈（スキル感・やり取りの質）の多くが Gmail や Slack に散在し、活用できていなかったためです。加えて本機能は私の入社と同時に始まった新規取り組みで、ビジネスチームが持つ暗黙的な選定基準を言語化するところから始める必要がありました。 **工夫したこと（取り組みと思考）** - **日印混成チームで英語ベースのコミュニケーションを徹底した** 日本側ビジネスチームとインド人エンジニアが混在する環境では、日本語主体で進めるとインドチームが置き去りになり認識齟齬が生まれると考え、会議・Slack・対面のいずれでもなるべく英語で会話することを徹底しました。仕様書も日英で用意し、双方が同じ理解で開発に入れる状態を作ることで手戻りを抑えました。 - **システム外の分散データを共通モデルで統合した** Gmail・Slack のデータをソースごとに個別対応すると実装が膨らむと判断し、共通データモデル（CDM）に正規化して束ねるミドルウェア層を設計・実装。将来のソース追加に耐える拡張性を優先しました。 - **AIコーディングエージェントで開発速度を高めた** Claude Code を日常のワークフローに組み込み、実装・調査を高速化。AWS への本番移行を見据え、Contabo VPS 上に Caddy / Sentry / Resend で基盤を構築・運用しています。 **成果** - 暗黙知だった候補者選定基準を、システムで扱える要件・データモデルとして定義しました。 - Gmail・Slack など**システム外に散在するデータ**を候補者選定に活用する統合基盤を設計・実装し、構造化データだけでは得られない文脈を提案に反映できる土台を構築しました。

| 項目 | 内容 | |------|------| | 期間 | 2025年（フリーランス参画期間内） | | カテゴリ | Webサービス / 音声認識システム | | 担当工程 | 要件定義・設計・実装・テスト・リリース | | 役割 | バックエンド・フロントエンド・プロジェクトリード | | チーム編成 | PM 1名 / 開発者 4名 / QA 1名 | | 使用技術 | Ruby on Rails / Go / React / TypeScript / GitLab / GitLab CI/CD / AWS / Azure | **概要** 会議参加者を声紋で自動識別するユーザー識別機能を、要件定義からリリースまでプロジェクトリーダーとして主導しました。音声処理という専門性の高い領域を含むため、技術調査から設計・実装・品質管理まで一貫して牽引しました。 **課題（背景）** 声紋による話者識別は、音声処理という専門性が高く不確実性の大きい領域で、「どこまでの精度なら実用に足るのか」「識別を誤ったときにどうリカバリするのか」が決まっていない状態からのスタートでした。仕様が固まらないまま実装に入ると開発者が判断に迷い手戻りが増えるため、技術的に何が実現可能かを見極めた上で、チームが迷わず実装できる仕様に落とし込むことが最大の課題でした。 **工夫したこと（取り組みと思考）** - **不確実な領域をまず技術調査で見極めてから仕様化した** 精度を最初から求めすぎると実現不能になり、緩すぎると実用に耐えないと考え、技術調査で実現可能な精度・処理フローの当たりをつけた上で、識別失敗時のエラー対処方針まで含めて仕様に明文化しました。「実装者が判断に迷わない粒度まで落とすこと」を要件定義のゴールに置きました。 - **専門領域だからこそフェーズを区切って遅延リスクを早期検知した** 不確実性が高い領域は後半で問題が顕在化しやすいと判断し、要件定義・設計・実装・テストの各フェーズにマイルストーンを設定。日々の進捗から遅延の兆候を早期に検知し、優先順位を調整しながら進めました。 - **本機能の開発を機にレガシー仕様を整理・資産化した** 未整理だった既存システムの仕様を、本機能の開発を進める過程でドキュメント化し、チーム全体の知識共有と後続開発の効率化につながる資産として残しました。 **成果** - 技術的難易度の高い声紋識別機能を、要件定義からリリースまで期日通りに完遂しました。 - 実装者が迷わない粒度まで仕様を落とし込んだことで、専門領域でありながら手戻りを抑えた開発を実現しました。 - レガシー仕様のドキュメント化により、チームの知識共有と継続的な開発基盤の強化に貢献しました。

| 項目 | 内容 | |------|------| | 期間 | 2025年（フリーランス参画期間内） | | カテゴリ | Webサービス / 音声認識システム | | 担当工程 | 要件定義・設計・実装・テスト | | 役割 | バックエンド・フロントエンド | | チーム編成 | PM 1名 / 開発者 4名 / QA 1名 | | 使用技術 | Ruby on Rails / React / TypeScript / GitLab / AWS | **概要** 会議の音声から自動生成される要約機能に対して、ユーザーが要約方法をカスタマイズできる機能の追加開発を担当しました。テストフェーズでの不具合が1件のみという高品質な納品を実現しました。 **課題（背景）** 「ユーザーが要約方法を変更できるようにする」という要件は、一見シンプルながらオプションの種類・UI挙動・バックエンドへの保存方法が曖昧なままで、この状態で実装に入るとオプションの組み合わせによる考慮漏れやバグが後工程で噴出するリスクがありました。2000社以上に提供される機能のため、リリース後の不具合が与える影響が大きく、テストフェーズで問題を出し切る品質担保が求められました。 **工夫したこと（取り組みと思考）** - **曖昧な要件を設計段階で潰し切ることに時間を投資した** 手戻りは実装が進むほどコストが跳ね上がると考え、「要約方法を変更できる」という抽象的な要件を、具体的なオプションの種類・UI挙動・バックエンドへの反映方法まで設計段階で詳細に詰めました。実装前に仕様を固め切ることで実装中の手戻りを未然に防ぎました。 - **連携部分のバグを減らすため前後を一人で一貫実装した** バグはバックエンドとフロントエンドの境界で起きやすいと判断し、オプション設定の保存ロジック（Rails）と選択UI（React）を自身で一貫して実装。責任範囲を分割せず通しで持つことで連携部分の不整合を最小化しました。 - **オプションの組み合わせを網羅したテスト設計** カスタマイズ機能は入力パターンが増えるほど抜けが出やすいため、要約オプションの組み合わせを網羅するテストケースを設計し、想定される分岐を事前に検証しました。 **成果** - テストフェーズでの不具合を**1件のみ**に抑え、高品質な納品を実現しました。 - 2000社以上に提供される要約機能に、リリース後も安定して稼働するカスタマイズ機能を追加しました。

| 項目 | 内容 | |------|------| | 期間 | 2025年（フリーランス参画期間内） | | カテゴリ | Webサービス / 音声認識システム | | 担当工程 | 実装・単体テスト・保守運用 | | 役割 | バックエンド | | チーム編成 | PM 1名 / 開発者 4名 / QA 1名 | | 使用技術 | Ruby on Rails / RSpec / GitLab / GitLab CI/CD / AWS | **概要** 音声認識システムのテストカバレッジが約20%と低く、品質が不安定な状態でした。既存コードの仕様を整理しながら RSpec による単体テストを体系的に実装し、カバレッジを約70%まで引き上げました。 **課題（背景）** テストカバレッジが約20%と低く、リリースのたびに既存機能のデグレが起きうる不安定な状態でした。さらにコードベースはドキュメントが整備されておらず、既存コードが「何を正としているのか」が不明なため、そもそもテストで担保すべき期待値を定義できないという二重の課題を抱えていました。単にテストを足すだけでは再現性のある品質改善にはならないと考えました。 **工夫したこと（取り組みと思考）** - **テストを書く過程でレガシー仕様を整理・ドキュメント化した** 期待値が定義できないままではテストが書けないと判断し、既存コードの動作を読み解いて仕様を整理しながらテストを設計しました。テストコード自体が仕様のドキュメントとして機能するよう意識し、品質改善と知識の資産化を同時に進めました。 - **場当たり的な追加ではなく設計方針を定めて体系化した** カバレッジの数値だけを追うと形だけのテストになると考え、正常系・異常系・境界値を網羅する設計方針を先に定義。チームの誰が書いても同じ観点で品質を担保できる、再現性のある仕組みとして整えました。 **成果** - テストカバレッジを**約20% → 約70%**へ引き上げ、システム品質を安定化させました。 - リリース後の不具合発生件数を大幅に削減し、継続的な機能追加に耐える開発基盤を構築しました。 - レガシーコードの仕様がテストとして明文化され、チーム全体の理解と保守性の向上に寄与しました。

| 項目 | 内容 | |------|------| | 期間 | 2023年4月 〜 2023年11月（約8ヶ月） | | カテゴリ | Webサービス | | 担当工程 | 実装・単体テスト・結合テスト・保守運用 | | 役割 | バックエンド・フロントエンド | | チーム編成 | PdM 1名 / 開発者 4名 / デザイナー 1名 / PJ全体 20名 | | 使用技術 | Ruby on Rails / Vue.js / JavaScript / MySQL / DynamoDB / AWS / Docker / GitHub | **概要** 社内の業務効率化を目的として、SNS投稿機能と活動記録管理機能を追加開発しました。メンバーとして実装フェーズ以降を担当し、後輩の技術的サポートやコードレビューも行いました。 **取り組みのポイント** - **公式ドキュメントを活用した自律的な情報収集** 技術記事がほとんど存在しない領域のため、公式ドキュメントを積極的に参照し、irb での動作確認を繰り返しながら実装を進めました。DynamoDB 連携では AWS 公式サイトや Dynamoid gem のソースコードまで遡って正確な理解に努めました。 - **コードレビューへの真摯な対応** 経験豊富な先輩からのレビューで指摘を受けた際、答えられない部分は自分で深く調べ直した上で再レビューを依頼しました。複雑な処理には説明コメントを加え、意図が伝わるコードに整理しました。 - **RSpec による単体テストでコード品質を担保** 複雑な処理が多かったため、単体テストを詳細に設計することでブラックボックステストを回避し、コードの信頼性を確保しました。

| 項目 | 内容 | |------|------| | 期間 | 2024年4月 〜 2024年10月（予定） | | カテゴリ | Webサービス / 業務システム / 受託開発 | | 担当工程 | 要件定義・設計・実装・テスト・保守運用 | | 役割 | バックエンド・フロントエンド・エンジニアリングマネージャ | | チーム編成 | PdM 1名 / PM 1名 / 開発者 2名 / PJ全体 4名 | | 使用技術 | Ruby on Rails / JavaScript / MySQL / AWS / Docker | **概要** 不動産仲介会社への販売管理システム導入により、業務効率化を実現するプロジェクト。4名の少人数チームの一員として、顧客との要件定義から導入まで全工程に携わりました。 **取り組みのポイント** - **業務フロー図を起点とした要件整理** 現在手動で行っている業務をシステムにどう落とし込むかを業務フロー図ベースで整理しました。ビデオ通話では伝わりにくい細かい要件は顧客先へ直接訪問して対話することで、満足度の高い仕様に仕上げました。 - **開発効率を重視した環境構築** webpack から vite への移行など、開発スピードを上げる環境構築を積極的に提案・実施しました。ドキュメントは細かく作り込むより、開発がスムーズに進むことを優先した最低限の資料作りを徹底しました。

| 項目 | 内容 | |------|------| | 期間 | 2023年12月 〜 2024年（複数フェーズ） | | カテゴリ | Webサービス | | 担当工程 | 要件定義・設計・実装・テスト・保守運用 | | 役割 | バックエンド・フロントエンド・インフラ・PM | | チーム編成 | PdM 1名 / PM 1名 / 開発者 3名 / PJ全体 15名 | | 使用技術 | Ruby on Rails / JavaScript / jQuery / PostgreSQL / AWS / Docker | **概要** 大手銀行の行員向けシステムを利用企業ごとにカスタマイズ追加開発し、新たな販路を開拓するプロジェクト。PMおよびメンバーとして要件定義フェーズから参画し、顧客ヒアリング・設計・実装・テスト・納品まで一貫して担当しました。 **取り組みのポイント** - **抽象的な要望を実現可能な仕様に落とし込む** 顧客から提示される抽象的なシステムイメージを、既存機能を参考にしながら技術的裏付けのある提案として具体化しました。リポジトリが分岐したシステムでも、共通システムの構成を維持しながら要件通りの実装を実現しました。 - **工数見積もりと優先順位づけによる進捗管理** 機能単位で工数を見積もってメンバーをアサインし、回収インパクトの大きい機能から着手する優先順位づけを実施。GitHub Issues の消化率で進捗を可視化しました。 - **運用を想定した高品質なテスト設計** 複雑な操作フローを含むため、顧客ヒアリングで得た知見をもとに最適なテストケースを設計。単体テストカバレッジ 95% 以上を達成し、納品品質を確保しました。