ID:82065さん

### 【チーム情報】 - チーム規模：10名（例：PL 1名 / SE 9名） - 自分の役割：バックエンド担当（設計修正〜実装〜テスト） - 担当範囲：法改正対応に伴う画面・業務ロジック改修を、設計修正〜実装・テストまで一通り担当（個人担当範囲） ### 【使用技術（使用場面）】 - Java：既存業務ロジックの解析、改修、共通処理の切り出し（メソッド化）によるリファクタリングを実施 - SQL：改修前後のデータ整合性確認、テスト観点の洗い出しに利用 - Linux：サーバ上ログ確認・動作確認（障害発生時の一次切り分けや原因調査の補助） - （その他あれば）既存FW / テストツール：プロジェクト標準に準拠して利用（例：JUnit 等） ### 【概要】 法改正に伴う業務要件変更に対応するため、既存業務システムの画面・ロジック改修を担当。 ### 【どのような機能の開発・実装か】 - 既存画面への入力項目追加・仕様変更 - 業務ロジックの改修 - 単体テスト〜総合テストの実施 ※ 設計修正〜実装・テストまでを個人で担当 ### 【課題・問題点】 - 同一・類似の共通処理が複数箇所に重複して実装されており、 修正漏れや将来的な保守性の低下が懸念される状態だった - 法改正対応のため修正箇所が多く、変更影響を最小限に抑える必要があった ### 【打ち手・使用した技術】 - 既存コードを調査し、重複している共通処理を洗い出し - 共通ロジックを関数として切り出し、再利用可能な形にリファクタリング - Javaを用いて既存処理を整理し、呼び出し元の修正範囲を最小化 - リファクタリング後に単体テスト・結合テストを実施し、既存機能への影響がないことを確認 ### 【成果】 - 重複コードを削減し、保守性・可読性を向上 - 修正時の影響範囲が明確になり、以降の改修作業がしやすい構造に改善 - 法改正対応を期限内に完了し、本番リリースまで問題なく対応

### 【チーム情報】 - チーム規模：約8名（PM1名 / 設計4名 / 開発3名） - 自身の役割：要件定義担当 - 担当範囲：申請機能および表示仕様整理 ### 【使用技術（使用場面）】 - Java：既存仕様確認・設計観点整理 - 業務フロー図作成：申請〜表示までの流れを図式化 - 設計資料作成：画面遷移図・項目定義書作成 ### 【概要】 保険医・保険薬剤師が保有する紙の資格者証をデジタル化し、 マイナポータル上から確認できる仕組みを導入するための オンライン申請機能および表示仕様に関する要件定義工程を担当。 ### 【どのような機能の開発・実装か】 - デジタル資格者証を発行・利用するための申請機能に関する要件整理 - マイナポータル上での資格者証表示内容・表示条件の整理 - 画面遷移や入力項目に関する要件定義資料の作成 ※ 要件定義工程を中心に担当（チーム作業） ### 【課題・問題点】 - 紙で運用されてきた資格者証をデジタル化するにあたり、 業務フローとシステム要件の整理が複雑 - 非エンジニアの関係者も多く、要件の認識齟齬が起きやすい状況 ### 【打ち手・使用した技術】 - 業務フローを整理し、申請〜表示までの流れを図式化 - 表示内容について「何を表示するか」「どの条件で表示されるか」を整理し、 要件定義資料として明文化 - 関係者との打ち合わせを通じて認識をすり合わせ、仕様を確定 ### 【成果】 - 申請機能および表示仕様に関する要件を整理し、設計工程へスムーズに引き継ぎ - 関係者間の認識齟齬を最小限に抑え、手戻りの少ない要件定義を実現

### 【チーム情報】 - チーム規模：約7名（PL1名 / 設計2名 / 開発3名 / テスト1名） - 自身の役割：基本設計担当（外部IF部分） - 担当範囲：API送受信仕様変更整理 ### 【使用技術（使用場面）】 - Java：既存API仕様確認 - SOAP電文：送受信項目の変更差分整理 - 設計書レビュー：API仕様書と設計書の突合確認 ### 【概要】 電子決済サービスにおいて、外部システム（銀行・クレジットカード会社）との連携仕様変更に対応。 ### 【どのような機能の開発・実装か】 - 外部APIの送受信項目変更に伴う設計修正 - 基本設計書への反映・仕様整理 ※ 設計ドキュメント整備を中心に担当（個人作業） ### 【課題・問題点】 - 外部システムとのIF変更は影響範囲が広く、認識ズレが障害につながりやすい - 電文仕様が複雑で、正確な理解が必要 ### 【打ち手・使用した技術】 - 既存の電文仕様をもとに、変更点（追加・削除・変更）を整理 - 関係者と仕様をすり合わせながら設計書に反映 - API仕様書・設計書を突き合わせ、齟齬がないかを確認 ### 【成果】 - 大きな仕様トラブルなく基本設計工程を完了 - 後続工程に引き継げるドキュメントを整備

### 【チーム情報】 - チーム規模：約10名（PL1名 / 開発4名 / テスト3名 / インフラ2名） - 自身の役割：総合テスト支援担当 - 担当範囲：動作確認・障害一次切り分け ### 【使用技術（使用場面）】 - Java：改修箇所の挙動確認 - Linux：ログ解析、環境差異確認 - SQL：データ整合性確認 ### 【概要】 官公庁向けシステムのサーバー更改に伴う総合テスト工程に参画し、 システム全体の動作確認および障害発生時の対応支援を担当。 ### 【どのような機能の開発・実装か】 - サーバー更改後のシステム動作確認 - 総合テスト・負荷テストにおけるテスト支援 - 障害発生時の一次切り分けおよびエスカレーション対応 ※ 総合テスト工程を中心に担当（チーム作業） ### 【課題・問題点】 - サーバー更改により、ミドルウェアや環境差異による 想定外の挙動が発生する可能性があった - 負荷テスト時には障害発生時の迅速な状況整理と共有が求められた ### 【打ち手・使用した技術】 - 事前に設計書・構成資料を確認し、変更点や影響範囲を把握 - 障害発生時にはログや状況を整理し、関係者へ正確に共有 - 監視担当者や開発メンバーと連携し、原因切り分けを支援 ### 【成果】 - 総合テスト工程を大きなトラブルなく完遂 - 障害発生時も迅速な情報共有により、対応の遅延を防止 - 次フェーズの改修に向けた課題整理に貢献

### 【チーム情報】 - 個人開発（設計〜実装〜デプロイまで一貫対応） ### 【使用技術（使用場面）】 - Python 3.13 / Django 4.2：バックエンド実装 - PostgreSQL 16：データ設計 - Docker Compose：開発環境構築 - Heroku：デプロイ - JavaScript：フロントバリデーション - Git/GitHub：バージョン管理 ### 【概要】 実務において設計・仕様整理に携わる機会が多かった一方で、 実装経験が限定的である点を課題と感じ、Django を用いた EC サイトの個人開発に取り組んでいる。 商品閲覧から購入・注文確定、確認メール送信までの一連の処理を実装し、 Webアプリケーション全体の流れを意識したバックエンド開発を行っている。 - GitHub： https://github.com/ngimixin/django_ec - デプロイURL： https://django-ec-staging-005009c332da.herokuapp.com/ ### 【どのような機能の開発・実装か】 - 商品一覧・商品詳細表示 - カート機能（セッションを用いた状態管理） - チェックアウト処理 - 注文確定処理および確認メール送信 - プロモーションコード機能 - 管理者向け機能 - Django admin を用いた商品・注文管理 - Basic 認証による管理者専用ページのアクセス制御 - データベース設計（商品・注文・注文明細 等） - Docker を用いた開発環境構築 - Heroku へのデプロイ ※ 設計〜実装・デプロイまで個人で対応 ### 【課題・問題点】 - ECサイトとして、認証・購入・DB更新・メール送信といった 一連の処理を整合性を保ったまま実装する必要があった - 購入途中の状態管理や、注文確定タイミングの設計を 明確に意識する必要があった ### 【打ち手・使用した技術】 - Django の MVT 構成を意識し、責務を分離した設計を実施 - セッションを用いてカート情報を管理し、購入フローの状態遷移を整理 - チェックアウト処理では、注文確定時点でのみ データベースが更新されるよう処理順を設計 - Docker によりローカル開発環境を統一し、 Heroku にデプロイして実際の動作を確認 ### 【成果】 - 商品一覧〜カート〜チェックアウト〜注文確定・確認メール送信までの 基本的な EC サイト機能を一通り実装 - Webアプリケーションにおけるリクエスト処理、 状態管理、DB更新の流れを実装を通じて理解 - 実務においても、設計・レビュー時に実装視点で考えられるようになった