ID:84339さん

# プロジェクト概要 データ連携パッケージ製品を活用したデータ連携基盤の導入支援。 ウォーターフォール型で進行し、製品仕様・設定内容の調査、設計内容・運用ルールの整理、設計資料・利用者向けマニュアルの作成、お客様への説明・仕様確認を担当。 # チーム情報 - **チーム人数**：9名 - **体制**：PM1名、PMO1名、チームリーダー1名、コンサル兼上長1名、開発メンバーほか - **役割**：開発メンバー - **担当工程**：調査、設計、ドキュメント作成、顧客説明・仕様確認 - **開発方式**：ウォーターフォール # 使用技術・ツール - **OS**：Windows - **DB**：Oracle、PostgreSQL - **言語**：SQL、TypeScript - **開発環境**：Visual Studio Code - **バージョン管理**：GitLab - **AIツール**：Claude Code - **ドキュメント作成**：Microsoft Word、Excel、PowerPoint - **コミュニケーション・情報共有**：Microsoft Teams、SharePoint、Box - **その他**：Node.js # 主な担当内容 - 要求事項をもとにした利用者向けマニュアルの作成 - データ連携パッケージ製品の機能・設定内容の調査 - 製品仕様・要求事項を踏まえた設計内容、運用ルールの整理 - 設計資料およびお客様向け説明資料の作成 - 自身が作成した資料を用いたお客様への説明・質疑応答 - 上長およびお客様との仕様確認 - チームミーティングでの進捗・課題・確認事項の共有 # 課題・問題点 製品固有の仕様や運用ルールの中に、要求事項のみでは判断できず、利用者によって解釈が分かれる可能性のある項目が存在。 特に、資産コピー時の扱いや権限設定を考慮したフォルダ構成などについて、製品仕様と実際の利用方法を照らし合わせ、運用時の判断基準を明確にする必要があった。 また、設計資料・利用者向けマニュアル・お客様向け説明資料など複数のドキュメントを扱うため、資料間で用語や記載内容に差異が生じると、利用者やお客様との認識齟齬につながる懸念があった。 # 対応・工夫 - 製品機能・設定内容を調査し、要求事項と照らし合わせながら、判断が必要な項目や仕様上の不明点を洗い出し - 不明点について、前提・論点・確認事項を整理したうえで上長へ確認し、決定内容を設計資料・マニュアルへ反映 - 資産コピー時の扱いや権限設定を考慮したフォルダ構成など、利用者が判断に迷う可能性のある項目について運用ルールを整理 - 設計資料・マニュアル・説明資料間で用語や記載内容を照合し、同一仕様について表現が分かれないよう統一 - 文章のみでは理解しづらい内容について図や表を用い、設定内容や運用ルールを視覚的に把握できるよう資料構成を工夫 - 自身が作成した資料を用いてお客様へ説明し、質疑応答で生じた認識差・追加確認事項を整理。必要に応じて上長へ確認し、結果を資料へ反映 # 成果 - 製品仕様・要求事項をもとに運用上の判断基準を明文化し、利用者が参照できるルールとして整理 - 複数の設計資料・マニュアル・説明資料の用語・記載内容をそろえ、資料間で一貫した内容を確認できる状態を整備 - お客様への説明・質疑応答を通じて曖昧な点や認識差を顕在化し、設計内容・運用ルールの認識合わせにつなげた - 顧客説明で得られた質問・指摘を資料へ反映し、利用者が判断時に参照しやすいドキュメントへ改善 # その他の取り組み - レビューや仕様変更時、対象箇所だけでなく関連する設計資料・マニュアルへの影響も確認 - 不明点・懸念事項を作業中に洗い出し、後工程へ持ち越さないよう早期に共有・確認 - チームミーティングでは進捗だけでなく、課題・仕様確認待ち事項も共有 - 資料作成時は記載内容の正確性に加え、実際の利用者が判断しやすいかという観点でも確認

# プロジェクト概要 Web上でSQL問題を受験し、Gemini APIを利用して回答内容の採点・評価理由・学習フィードバックを生成し、結果を確認できるSQL学習プラットフォームの新規開発。 36名体制のウォーターフォール型プロジェクトで、フロントエンド開発を中心に、AI採点機能、受験結果画面、要件定義書の作成、DB設計の見直しまで担当。 # チーム情報 - **チーム人数**：36名 - **体制**：PM兼チームリーダー1名、開発メンバー25名、QA10名 - **役割**：開発メンバー - **担当工程**：要件定義、設計、実装 - **開発方式**：ウォーターフォール - **タスク管理**：GitHub - **コミュニケーション**：Microsoft Teams # 使用技術・ツール - **OS**：Linux - **DB**：PostgreSQL - **言語**：HTML、CSS、JavaScript、TypeScript - **フレームワーク**：React、Next.js（App Router） - **UI・フォーム**：Tailwind CSS、Radix UI、React Hook Form、Zod、Recharts - **ORM**：Drizzle ORM - **開発環境・管理**：Cursor、GitHub、Docker、Docker Compose - **API・認証**：Gemini API、OpenAPI、Logto - **設計・ドキュメント**：Figma、Google ドキュメント、Notion - **その他**：Node.js、Microsoft Teams # 主な担当内容 ## AI採点・受験結果機能 - Gemini APIを利用したSQL回答のAI採点・フィードバック生成処理の実装 - AIによる採点結果・評価理由・学習フィードバックの取得・表示 - PostgreSQL／Drizzle ORMを用いた受験結果データの取得・表示処理 - TypeScript／Next.js（App Router）を用いた受験画面・受験結果画面の実装 - React Hook Form／Zodを用いた入力管理・バリデーションの実装 ## 要件定義・DB設計 - 要求定義書をもとにした要件定義書の作成 - 受験結果管理・AI評価処理に関するテーブル構成、リレーションの見直し - 上長・開発メンバーとの仕様確認、進捗・課題共有 # 課題・問題点 SQL回答をGemini APIで採点するにあたり、回答SQLのみを入力すると、設問意図や評価観点が十分に伝わらず、期待する観点とは異なる評価となる可能性があった。 また、AIからは採点結果だけでなく、評価理由・学習者向けフィードバックなど複数種類の情報が返却されるため、システム上で扱いやすい形に整理し、画面上でもそれぞれの役割が分かる形で表示する必要があった。 加えて、受験結果・AI評価情報を管理する既存のテーブル構成には、データの役割やリレーションが分かりにくい部分があり、今後の項目追加や機能拡張を考慮した見直しが必要となった。 # 対応・工夫 - Gemini APIへ渡すプロンプトに、回答SQLだけでなく設問内容・設問意図・評価観点を含め、AIが評価時に参照すべき情報を明確化 - AIから返却される情報を、採点結果・評価理由・学習フィードバックに分けて扱えるよう構造化 - AI評価情報を受験結果データと紐づけ、それぞれを画面上で確認できる取得・表示処理を実装 - 受験結果画面では、複数の評価情報を役割ごとに分け、利用者が確認しやすい構成で表示 - 画面仕様・機能要件の不明点を実装前に洗い出し、上長・開発メンバーへ確認したうえで実装方針を決定 - 受験結果・評価情報の役割やデータ間の関係を整理し、テーブル構成・リレーションを再検討 - 要求定義書の内容を、画面・処理・データの観点に分けて要件定義書へ落とし込み # 成果 - 設問意図・評価観点をAIへ明示できるプロンプト構成とし、設問で求める観点を踏まえて採点するための基盤を実装 - AIの返却情報を用途ごとに分離し、採点結果・評価理由・学習フィードバックをシステム上で個別に管理・表示できる構成を実現 - 受験者が採点結果だけでなく、評価理由・学習フィードバックまで確認できる受験結果機能を実装 - 仕様上の不明点を実装前に整理し、関係者間で認識を合わせたうえで開発を進められる状態を構築 - 受験結果・AI評価情報の役割を整理し、今後の項目追加・機能拡張を考慮できるデータ構成へ見直し # その他の取り組み - 担当画面だけでなく、画面・API・DB間のデータの流れを確認しながら実装 - 仕様・設計に不明点がある場合、前提や論点を整理して関係者へ確認 - チームミーティングで進捗に加え、仕様確認事項・実装上の課題も共有 - 要求定義から要件定義への落とし込みでは、画面上の挙動だけでなく必要なデータ・処理内容も含めて整理

# プロジェクト概要 施設メンテナンス向けSaaSにおける新規IoT機能の開発。 5名体制の少人数チームで、新規IoT機能のフロントエンド開発を中心に、実装前の技術調査・PoC、Figmaでの画面デザイン調整、共通コンポーネント設計を担当。 あわせて、既存SaaSリプレイスに伴うシステムテストのテストケース作成を担当。 # チーム情報 - **チーム人数**：5名 - **体制**：PM兼テックリード1名、フルスタック兼デザイナー1名、フロントエンド1名、バックエンド1名、QA1名 - **役割**：フロントエンド開発 - **担当工程**：技術調査、PoC、画面設計、実装、システムテスト設計 - **タスク管理**：Backlog - **コミュニケーション**：Microsoft Teams # 使用技術・ツール - **OS**：Linux - **DB**：PostgreSQL - **言語**：HTML、CSS、JavaScript、TypeScript - **フレームワーク**：React、Next.js（App Router） - **UI・スタイリング**：Ant Design、Tailwind CSS、Recharts - **ORM**：Prisma - **開発環境・管理**：Cursor、GitHub - **API関連**：OpenAPI、Swagger - **デザイン**：Figma - **その他**：Node.js、NotePM、Microsoft Teams、Backlog # 主な担当内容 ## 新規IoT機能のフロントエンド開発 - TypeScript／Next.js（App Router）を用いた画面・UIコンポーネントの実装 - UI実現方法に関する技術調査・PoC - Ant Designを用いた画面・共通コンポーネント設計 - Figmaでの画面デザイン作成・調整 - HTMLからFigmaデザインへ変換するプラグインを活用した既存UIのデザイン化・調整 ## 既存SaaSリプレイスのシステムテスト設計 - 画面仕様・機能仕様をもとにしたテスト観点の整理 - 正常系・例外系を含むシステムテストケースの作成 - 利用シーンを考慮した操作パターン・期待結果の整理 - 仕様不明点の確認・関係者との認識合わせ # 課題・問題点 新規IoT機能では、画面要件に対してどのようなUI構成・ライブラリの利用方法で実現するか事前に確認する必要があり、技術的な制約を把握しないまま実装を進めると、後から実装方針の変更が必要になる可能性があった。 また、デザインと実装を並行して進めるため、Figma上の画面構成と実際のReactコンポーネント構成に大きな差が生じると、実装時の調整が増える懸念があった。 システムテストでは、正常に操作できることだけでなく、実際の利用時に想定される入力・操作パターンや例外条件まで確認できるテストケースを作成する必要があった。 # 対応・工夫 - UI実装前に技術調査・PoCを行い、Ant Designなどを用いた画面要件の実現可否・制約を確認 - PoCで確認した内容をもとに、実装上の懸念点を整理し、チーム内で実装方針を検討 - Ant Designの既存コンポーネントを活用しつつ、画面内で再利用する要素は共通化を意識して設計 - Figma上でも実装時のコンポーネント分割を意識し、デザインとReactコンポーネントの対応関係が分かりやすくなるよう構成 - システムテストでは、画面・機能仕様から確認観点を整理し、正常系に加えて入力値の違い、操作順序、境界・例外ケースを含むテストケースを作成 - 実際の利用シーンを想定し、仕様上可能な操作だけでなく、利用者が行う可能性のある操作もテスト観点へ反映 - 仕様が不明確な箇所は自己判断で確定せず、関係者へ確認したうえで期待結果を整理 # 成果 - PoCによりUI構成・実装方法の実現可否や制約を事前に確認し、検証結果を踏まえて開発へ移行 - デザインと実装の双方でコンポーネント構成を意識し、Figmaから実装へ落とし込みやすい画面構成を作成 - 正常系だけでなく例外ケース・利用シーンを含めたテストケースを作成し、複数の操作パターンを確認できるテスト観点を整備 - テスト設計段階で仕様上の不明点を洗い出し、関係者との認識合わせにつなげた # その他の取り組み - 技術的な不明点は実装前に調査・検証し、判断材料を整理してチームへ共有 - 仕様・デザインの不明点は実装前に確認し、認識を合わせたうえで作業を実施 - Backlogでタスク状況を更新し、Microsoft Teamsで課題・確認事項を共有 - 開発・テストの双方を担当し、実装時にも利用者の操作や後続テストを意識して画面仕様を確認

# プロジェクト概要 婚活アプリの新規開発。 27名体制で、1週間スプリントのスクラム形式にて開発。 フロントエンドメンバーとして、TypeScript／Next.js（App Router）を用いた画面・機能実装を担当。バックエンドAPIやFlutterアプリとの連携を伴う機能開発、不具合修正、Jestによるテストコードの追加・修正を実施。 # チーム情報 - **チーム人数**：27名 - **体制**：ディレクター5名、デザイナー3名、アプリ4名、バックエンド5名、フロントエンド7名、テスター3名 - **役割**：フロントエンド開発 - **開発方式**：スクラム（1週間スプリント） - **タスク管理**：Backlog - **コミュニケーション**：Microsoft Teams # 使用技術・ツール - **OS**：Linux - **DB**：PostgreSQL - **言語**：HTML、CSS、JavaScript、TypeScript - **フレームワーク**：React、Next.js（App Router） - **状態管理・データ取得**：TanStack Query、Zustand - **スタイリング**：Tailwind CSS - **テスト**：Jest - **開発環境・管理**：Cursor、GitLab、Docker、Docker Compose - **API関連**：OpenAPI、Swagger - **デザイン**：Figma - **その他**：Node.js、Notion、Microsoft Teams、Backlog # 主な担当内容 ## AI自己紹介文生成機能 - バックエンドAPIと連携し、AIによって生成された自己紹介文を画面へ表示する機能を実装 - APIから取得した生成結果をユーザーが確認・利用できるUIを構築 ## 未読・既読状態の表示機能 - APIから取得した状態をもとに、タブ単位で未読・既読状態を画面へ反映 - データに応じてバッジ表示などのUIを動的に切り替える処理を実装 ## マイナンバーカードを利用した本人確認フロー - Flutter側と連携し、マイナンバーカードのスキャン認証を利用した本人確認導線を実装 - アプリ側との連携内容・画面遷移を確認しながらWebフロントエンド部分を実装 ## 不具合修正・テスト - 不具合の再現条件・前提データ・操作手順を整理し、原因箇所を調査 - バックエンド担当と連携し、APIレスポンスを含めてフロントエンド／バックエンドの原因を切り分け - 修正内容に応じてJestによるテストコードを追加・修正 # 課題・問題点 バックエンドAPIやFlutterアプリとの連携を伴う機能が多く、フロントエンド単体の仕様だけではなく、API仕様・データ状態・画面遷移など複数の要素を確認しながら開発する必要があった。 また、仕様書やFigmaのデザインだけでは判断できない挙動もあり、不明点を残したまま実装すると、関係者間で認識が異なる可能性があった。 不具合対応では、画面上の事象のみでは原因箇所を判断できないケースがあり、前提データ・再現手順・APIレスポンスを含めて切り分ける必要があった。 # 対応・工夫 - API仕様・画面仕様・Figmaデザインを確認し、実装前に不明点や判断が必要な項目を洗い出し - 仕様上の疑問点は自己判断で進めず、ディレクター・バックエンド・アプリ担当など関係者へ確認 - 複数の処理・画面遷移が関係する機能では、処理の流れをフローチャートで整理し、認識を可視化 - 調査に時間をかけすぎないようタイムボックスを設定し、一定時間で解決できない場合は論点を整理して相談 - 不具合調査では、発生条件・前提データ・操作手順・APIレスポンスを整理し、バックエンド担当と連携しながら原因箇所を切り分け - コーディング規約に沿った命名・フォーマットを意識し、既存コードと一貫した形で実装 - 不具合修正時は既存テストへの影響を確認し、必要に応じてJestのテストコードを追加・修正 # 成果 - AI自己紹介文生成、未読・既読表示、本人確認など、バックエンドAPI・Flutterアプリとの連携を伴う複数機能のフロントエンド実装を完了 - 仕様・デザイン上の不明点を早い段階で関係者へ確認し、認識を合わせながら実装を進行 - 複雑な処理・画面遷移をフローチャートで整理し、実装時に確認すべき処理の流れを明確化 - 不具合発生時に前提条件・再現手順・APIレスポンスを整理し、関係者と原因箇所を切り分けながら修正を実施 - Jestのテストコードを追加・修正し、修正内容をテストで確認できる状態を整備 # その他の取り組み - 1週間スプリントの中でBacklog上のタスク状況を更新し、進捗・課題をチームへ共有 - 不明点を長時間抱え込まないよう、自身で調査する時間と相談へ切り替えるタイミングを設定 - 担当画面だけでなく、API仕様・他画面との遷移も確認し、機能全体の流れを把握したうえで実装 - レビューで得た命名・記述方法の指摘を以降の実装にも反映し、既存コードとの一貫性を意識