ID:65981さん

### プロジェクト概要 某企業の業務系システムを、既存環境からWebアプリケーションへ移行するプロジェクトに開発メンバーとしてアサインされました。 ### チーム体制と担当範囲 - プロジェクト全体の画面数は約10画面。その中で私の所属チームは3画面を担当しました。 - 私はチーム内で1画面を主担当として受け持ち、フロントエンドのコーディングおよびテストを中心に推進しました。 - 使用技術：React.js（フロントエンド） / Java（バックエンド）。Java側のAPIから受け渡されるデータをフロントエンドで描画する構成です。 ### 担当機能とその開発内容 #### 1. 検索条件入力欄のアコーディオン化 - **課題**：画面内に検索条件の入力欄が多く、常時展開していると画面が縦に間延びし、データ表示領域を圧迫していました。検索条件を折りたたみ可能にし、必要なときだけ展開できるようにする必要がありました。 - **アプローチ**：プロジェクト内で整備されていた共通コンポーネント化済みのカスタムフックを採用。独自実装ではなく共通フックを選んだのは、他画面とのUI挙動の一貫性を保ち、保守コストを下げる狙いがありました。 - **工夫**：検索条件欄をJSXタグでラップして折りたたみ対象とし、共通フックの開閉ロジックと組み合わせることで、最小限の実装でアコーディオン機能を実現しました。 - **成果**：データ表示領域を確保しつつ、検索条件の視認性と操作性を両立。プロジェクト共通の作法に沿った実装としたことで、レビューや後続の保守がしやすい状態を保てました。 #### 2. 入力フォーム・送信ボタン（データ送信／検索機能） - **課題**：ユーザーが入力した検索条件をバックエンドへ送信し、その結果データを呼び出して画面に表示する機能を実装する必要がありました。 - **アプローチ**：アコーディオンと同様に、プロジェクトの共通コンポーネント化されたカスタムフックを活用し、フォーム入力・送信・データ取得の一連の処理を実装しました。 - **工夫**：画面上の表示確認だけでは「フロントエンドとバックエンドの間で本当に正しくデータが受け渡されているか」までは保証できないと考え、ブラウザのデバッガでウォッチ式を用い、各パラメータの値をAPIの送受信単位で追跡しました。これにより、表示は正常に見えても内部のデータ連携に問題があるケースを早期に切り分けられる状態を作りました。 - **成果**：見た目の挙動と内部のデータ整合性の両面を検証したうえで機能を完成させ、フロントエンド・バックエンド間の連携不具合を防ぐことができました。 ### テスト・品質改善での取り組み フロントエンド領域のテストを担当し、エビデンス作成と、実装後の動作確認や他社からチケート報告されたバグの修正を行いました。 - **自社起因の軽微なバグ**：入力フォームのサイズが不揃いになっていた表示崩れを修正し、画面全体のUIの統一感を改善しました。 - **他社画面の不具合（処理順序起因）**：他社担当画面において、処理順序の変更により、設計書に定義されたある処理の実行後に入力フォームへフォーカスが当たらなくなる不具合が発生していました。設計書の仕様と実際の処理フローを突き合わせて原因を特定し、フォーカス制御が意図したタイミングで動くよう修正しました。 - **成果**：自社・他社双方の不具合に対応し、設計書の仕様に沿った正しい挙動を担保。担当画面を越えてプロジェクト全体の品質向上に貢献しました。 ### このプロジェクトで得たこと 共通コンポーネントを活用しながら、UIの一貫性と保守性を意識した機能開発を経験しました。また、ウォッチ式によるデータ連携の検証や、設計書と実装を突き合わせた原因特定を通じて、「表面的な動作確認で終わらせず、内部の整合性まで確認する」という品質に対する姿勢を実践できました。

### プロジェクト概要 上司と部下の1on1を支援する社内向けビデオ通話アプリケーションの新規開発に、開発メンバーとして参画。 単なる通話機能にとどまらず、部下から上司への「心理的安全性スコア」を収集・蓄積し、 スコアの推移や傾向を可視化・分析することで、マネジメント改善につなげることを目的としたプロダクト。 ### チーム構成・開発体制 - 全体5名（PM 1名 / シニアエンジニア 1名 / 開発メンバー 3名） - アジャイル開発（短サイクルでの実装・レビュー・改善を反復） - 担当フェーズ：開発〜単体・結合テスト --- ### 担当機能①：心理的安全性スコアのチャート可視化機能 **解決すべき課題** 上司が自分のマネジメント状態を客観的に把握する手段がなく、1on1で集めたスコアが 「蓄積されるだけで活用されない」状態になりがちだった。スコアを直感的に理解でき、 時系列での変化に気づける形で提示することが求められた。 **実装内容** - 担当する部下から収集した心理的安全性スコアを集計し、チャートとして表示する画面機能を実装 - 期間（推移）や項目別の切り口でスコアを可視化し、上司が自身の傾向を把握できるUIを構築 **工夫した点** - スコアという定量データを「数値の羅列」ではなく時系列チャートで見せることで、 上司が変化や異常値に気づきやすいUIを意識した - データ取得・整形ロジックと表示コンポーネントを分離し、 集計仕様の変更に表示側を巻き込まずに対応できる構成とした - 描画パフォーマンスやデータ未登録時（0件）の表示など、エッジケースを洗い出して実装に反映 **成果** - 上司が1on1の成果を定量的に振り返れる仕組みを提供し、プロダクトの中核価値の一つを実現 - スコアが「収集して終わり」ではなく、マネジメント改善のアクションにつながる導線を構築 --- ### 担当機能②：心理的安全性スコアに基づく分析機能 **解決すべき課題** スコアを可視化するだけでは「で、どうすればいいのか」が伝わらない。 収集したスコアを分析・評価し、上司が次のアクションを考えられる情報として提示する必要があった。 **実装内容** - 心理的安全性スコアをもとにした分析・評価ロジックを画面機能として実装 - スコアの傾向から示唆を引き出し、上司向けに分かりやすく表示する画面を構築 **工夫した点** - 「分析結果をどう見せれば上司の行動につながるか」という観点で表示設計を検討し、 PM・シニアと仕様をすり合わせながら実装を進めた - 分析ロジックを再利用しやすい単位に切り出し、機能①のチャートとデータ基盤を共通化 **成果** - スコアの「可視化」から一歩進んだ「分析・示唆の提示」までを担い、 プロダクトのコアバリューに直接貢献した --- ### 品質保証への取り組み - Jest による単体テスト、Playwright による結合（E2E）テストを実装し、担当機能の品質を担保 - スコア集計・チャート表示といったデータ駆動の機能に対し、 正常系だけでなく異常系・境界値ケースを意識したテストケースを設計 ### 使用技術・得た知見 - フロントエンド：React ベースのフレームワーク - テスト：Jest（単体）、Playwright（E2E） - アジャイル開発の中で、実装〜テストまでを一貫して担当し、 モダンなフロントエンド開発・テスト手法の実践経験を獲得

## プロジェクト概要 Live配信システムの新規開発に、設計・開発・テスト・本番対応まで一貫して携わった。配信中に字幕やテキスト・図形をリアルタイムで表示・操作でき、配信前に画面レイアウトをテンプレートとして用意できる「編集画面」と、実際の配信を制御する「配信画面」の2つを中核機能として開発。EC（Shopify）との連携により、配信からの購買導線も実現した。 ## チーム構成・開発体制 - **チーム規模**：3名（全体3名） - **開発手法**：アジャイル - **担当フェーズ**：設計 / 開発 / 単体・結合テスト / 本番対応 - **役割**：開発に加え、機能単位での進捗管理・メンバーマネジメント、および非エンジニア顧客との要件・仕様調整を担当 --- ## 担当機能①：編集画面（配信レイアウトのオーサリング機能） ### 課題・背景 配信ごとに字幕・テキスト・図形のレイアウトを毎回ゼロから作るのは運用負荷が高く、非エンジニアである顧客の運用担当者が直感的に操作できる仕組みが求められていた。 ### 開発した機能 - 字幕・テキスト・図形の追加／編集機能 - レイヤー機能（要素の重なり順の制御） - レイアウトの保存機能 - テンプレートの作成・読み込み機能 ### 工夫したこと（思考プロセス・課題解決） - **要素管理をレイヤー構造で抽象化**：字幕・テキスト・図形を個別実装するのではなく、共通の「レイヤー」という概念に統一して扱う設計にした。これにより重なり順の制御や追加要素の拡張が容易になり、機能追加時の改修コストを下げられた。 - **テンプレートによる運用負荷の削減**：「保存したレイアウトを再利用したい」という顧客の運用課題を、レイアウト状態を構造化データとして保存・復元するテンプレート機能として実装。配信準備の作業を毎回の作り込みから「選んで読み込むだけ」に変えた。 - **非エンジニア顧客との仕様調整**：操作する顧客がエンジニアではないため、仕様書（画面設計書・詳細仕様書）を専門用語に頼らず作成し、想定される操作フローを画面イメージとともに提示して認識齟齬を防いだ。 ### 成果 配信準備の作業時間を削減し、運用担当者が技術知識なしでレイアウトを構築・再利用できる状態を実現した。 --- ## 担当機能②：配信画面（リアルタイム配信制御機能） ### 課題・背景 ライブ配信では、配信者・参加者の映像表示と、配信中の字幕切り替えをリアルタイムかつ安定して行う必要があった。 ### 開発した機能 - 配信者ビデオの表示機能 - 参加者ビデオの表示機能 - 字幕送り機能（配信中に字幕を順次切り替える機能） ### 工夫したこと（思考プロセス・課題解決） - **編集画面で作成したテンプレートとの連動**：配信画面が編集画面で作成したレイアウト・字幕データをそのまま読み込めるようにデータ構造を共通化し、「事前に作る／本番で出す」の2画面をシームレスにつないだ。 - **配信中の操作性を優先した字幕送り設計**：配信オペレーターが本番中に迷わず操作できるよう、字幕を順送りで切り替える専用UIとして実装。リアルタイム操作の確実性を重視した。 ### 成果 編集画面で準備したレイアウトを配信画面で即座に反映できる一貫したワークフローを構築し、配信本番での操作ミスのリスクを抑えた。 --- ## 担当機能③：外部サイト（Shopify）連携 ### 課題・背景 配信を視聴から購買につなげるため、Live配信システムとECサイト（Shopify）を連携させる必要があった。 ### 開発した機能 - ショップサイト（Shopify）との連携機能 ### 工夫したこと（思考プロセス・課題解決） - **外部API仕様のキャッチアップと設計反映**：自社管理外であるShopifyのAPI仕様を調査し、取得できるデータ・制約（レスポンス形式、認証、レート制限など）を踏まえて連携部分の設計を行った。 - **障害切り分けを意識した実装**：外部サービス連携は障害点が増えるため、自システム側の不具合とShopify側起因の問題を切り分けやすいよう連携処理を分離して実装した。 ### 成果 配信とECを接続する購買導線を実現し、Live配信からの商品閲覧・購入を可能にした。 --- ## このプロジェクトで得た知見 - 非エンジニア顧客・デザイナーとの仕様調整の進め方（専門用語を避けた合意形成、画面イメージベースのコミュニケーション） - 外部API（Shopify）連携における仕様調査・設計・障害切り分けの考え方 - レイヤー／テンプレートといった「共通概念での抽象化」によって機能拡張に強い設計を行う設計判断

### プロジェクト概要 大手コンサルティング企業向けの社内管理システムの新規開発に、開発〜単体・結合テストフェーズで参画。社内のグループ管理および組織アドレス帳機能の実装を担当した。 ### チーム構成・開発体制 - 開発チーム：3名（全体3名） - 開発手法：アジャイル - 担当範囲：開発、単体テスト、結合テスト --- ### 担当機能①：グループ管理機能 **課題 / 目的** 社内グループ（部門・チーム単位の組織）の情報を、システム上で登録・更新・削除できる仕組みが必要だった。 **実装内容** - 社内グループの登録・更新・削除（CRUD）機能を実装 **工夫した点** 〔要確認：実際に工夫した点を記載〕 例： - 削除時に紐づくメンバー・下位グループが存在する場合の整合性をどう担保したか（論理削除 / 物理削除の判断、外部キー制約の扱いなど） - 更新時の排他制御や入力バリデーションの設計 - テストケースの観点（境界値、異常系の洗い出し方） **成果** 〔要確認：定量・定性の成果を記載〕 例：単体・結合テストを通じて〇〇件の不具合を早期検出 など --- ### 担当機能②：組織アドレス帳機能 **課題 / 目的** 企業・部門・グループが階層構造を持つため、利用者が組織構造を直感的に辿りながら対象グループのメンバー情報を確認できるUI／データ構造が求められた。 **実装内容** - 各企業・部門に紐づくグループを**ツリー構造**で表示するアドレス帳を実装 - ツリーで選択したグループに対応するメンバー情報を表示する機能を実装 - **Azure Data Factory** を用いた既存データの移行対応を実施 - あわせて**日次バッチ**を構築し、データの自動同期を実現 **工夫した点** 〔要確認：実際に工夫した点を記載〕 深掘りされやすいポイントなので、下記のような観点で具体化を推奨： - 階層構造データをどう表現したか（隣接リスト / 経路列挙 / 入れ子集合モデルなど、どのテーブル設計を選び、なぜそれを選んだか） - ツリー表示時のパフォーマンス対策（再帰取得の負荷、N+1の回避、遅延読み込みなど） - データ移行時に直面した課題（移行元と移行先のスキーマ差異、データクレンジング、移行失敗時のリカバリ設計など） - 日次バッチの設計（冪等性の担保、差分更新 vs 洗い替え、エラー時の通知・再実行） **成果** 〔要確認：定量・定性の成果を記載〕 例：手作業で行っていた組織情報の更新をバッチ化し、運用工数を削減 など --- ### 得られた知見 - Azure Data Factory を用いたデータ移行・バッチ処理の設計・実装経験 - AI駆動開発（GitHub Copilot / Claude Code 等）を活用した開発プロセスの実践

### プロジェクト概要 ファンド運用業務における各種データの管理・閲覧・帳票出力を担うファンド管理システムの新規開発。投資ファンドに関わる情報を一元管理し、運用担当者が日々の業務で必要とする一覧参照・データ更新・通知書類の出力までを一つのシステム上で完結できることを目指したプロジェクト。 ### チーム構成・開発体制 - チーム規模: 3名（全体3名） - 開発手法: アジャイル - 担当フェーズ: 詳細設計・開発・単体/結合テスト 少人数体制のため、設計から実装、テストまでを一貫して担当。仕様の検討段階から関与できる体制を活かし、後工程を見据えた設計判断を行いながら開発を進めた。 --- ### 取り組んだ機能とその詳細 #### 1. Feature-Based Architecture によるコンポーネント設計 **課題** 画面数が20に及ぶ規模のシステムにおいて、機能追加や仕様変更のたびに影響範囲が広がり、保守コストが増大することが懸念された。技術レイヤー単位（components / hooks / utils など）でディレクトリを分割する従来構成では、一つの機能改修に複数ディレクトリの横断が必要となり、変更の見通しが悪くなる。 **工夫・解決アプローチ** 機能（Feature）を単位としてコードを凝集させる Feature-Based Architecture を採用。各機能に関わるコンポーネント・ロジック・型定義を機能ディレクトリ内に閉じ込めることで、「どこを変更すれば何に影響するか」を局所化した。共通利用される要素のみを上位の共有層に切り出すルールを定め、機能間の依存方向を一方向に保つよう設計した。 **成果** 機能単位でコードの所在が明確になり、改修時の影響範囲調査と変更作業を効率化。新規画面の追加時にも既存パターンを踏襲することで、実装の一貫性と開発スピードを両立できた。 #### 2. 一覧表示機能の実装（対応画面数: 20） **課題** ファンド管理に必要な多様なデータ種別それぞれに対し、一覧画面を提供する必要があった。画面ごとに表示項目や絞り込み条件は異なる一方、ページング・ソート・検索といった基本的な振る舞いは共通しており、画面ごとに個別実装すると重複が大量に発生する。 **工夫・解決アプローチ** 一覧表示の共通的な振る舞いを抽象化し、各画面は表示項目の定義と固有の条件のみを記述すれば動作する構成とした。共通部分と画面固有部分の責務を明確に分離することで、20画面分の一覧機能を一貫した品質と操作性で実装。 **成果** 20画面すべてで統一されたUX・操作感を実現しつつ、共通化により実装・テストの工数を削減。利用者にとっても画面ごとの操作の学習コストが下がる設計とした。 #### 3. 編集・更新機能の実装（対応画面数: 18） **課題** 一覧表示した20画面のうち18画面では、データの編集・更新が求められた。更新処理には入力値の妥当性検証や、更新失敗時の状態整合性の担保が必要で、画面ごとにばらつきが出るとデータ品質に直結するリスクがあった。 **工夫・解決アプローチ** 編集・更新フローを共通パターンとして整備し、各画面はそのパターンに沿って実装。バリデーションや更新時のエラーハンドリングの方針を統一することで、画面間で挙動の差異が生じないようにした。 **成果** 18画面で安定した更新処理を実現。共通パターン化により、レビュー観点も統一でき、不具合の混入リスクを抑えた。 #### 4. Excel 出力機能の実装 **課題** ファンド運用業務では、通知書や各種データを Excel 形式で外部へ提出・共有する場面が多く、システム上のデータを所定のフォーマットに沿った Excel ファイルとして出力する機能が求められた。 **工夫・解決アプローチ** 業務で要求される帳票レイアウト（通知書フォーマット等）を満たす形でデータを Excel に書き出す機能を実装。出力対象のデータ取得から整形、ファイル生成までの処理を整理し、帳票種別が増えても拡張しやすい構成を意識した。 **成果** 運用担当者が必要とする通知書・データを、システムから直接 Excel として出力できるようになり、手作業での転記や帳票作成の負担を軽減した。 --- ### 工夫した点（横断的な取り組み） #### AI駆動開発に向けた環境整備 開発の生産性向上を目的に、AIコーディングツール（Claude Code 等）を活用しやすい開発環境を整備した。 - **リファクタリング方針の整備**: AIにリファクタリングを任せる際の指針を明文化し、一貫した方針でコンポーネント改善・クリーンアーキテクチャへの書き換えを進められるようにした。場当たり的な修正ではなく、設計意図に沿った改善を AI を用いて再現可能にした点を重視。 - **テスト・SKILL等の設定整備**: AI駆動開発の効果を最大化するため、テスト方針やプロジェクト固有のルール（SKILL等）を整備。AIが生成するコードがプロジェクトの規約・品質基準に沿うよう、前提となる設定を整えた。 **得られた成果・知見** AIを単なるコード生成ツールとしてではなく、設計方針に沿って活用するための「土台づくり」が品質と速度の両立に効くことを実感。コンポーネント設計・リファクタリングの知見に加え、AI駆動開発を前提とした環境設計のノウハウを獲得した。 --- ### このプロジェクトで得た学び - 機能単位でコードを凝集させる設計が、画面数の多いシステムの保守性に大きく寄与すること - 共通化と画面固有実装の責務分離が、品質の均一化と工数削減を同時に実現すること - AI駆動開発では、ツールの導入そのものより「AIが正しく動くための方針・設定の整備」が成果を左右すること