ID:74135さん

# プロジェクト概要 自治体向けWebアプリケーション3種（電子申請システム／粗大ごみ申請システム／税務システム）の新規開発・追加機能開発・改修を担当しました。住民が直接使う申請系と、職員が使う内部業務系の両方を扱う構成で、いずれも稼働中システムへの改修が中心のため、既存仕様の把握とデグレ防止が常に前提となる開発でした。 技術構成はJava（Struts2 / Spring Boot）＋ JSP ＋ jQuery ＋ PostgreSQL、バージョン管理はSVNです。 # 担当業務 ・基本設計 / 詳細設計（画面設計・機能設計・テーブル設計） ・実装（Java / Struts2 / Spring Boot / JSP / jQuery） ・テスト仕様書作成、単体テスト・結合テスト ・稼働後の運用保守、障害調査・障害対応 ・改修時の影響調査 ・後輩の指導（設計書・コードレビュー）、担当機能の進捗管理 # 工夫した点・成果 【複数要件が同時に走る改修でのデグレ防止】 自治体システムは複数要件が同一機能に同時に入るため、要件単位で個別に設計するとお互いの前提を壊し合い、後工程でデグレが発覚するという課題がありました。 そこで着手前に関連要件を横断して洗い出し、同じ画面・同じテーブルに触れる要件を一覧化してから設計に入る進め方を取りました。「この要件で追加する項目が、別要件の判定条件に影響しないか」を設計レビュー前に自分で確認し、影響が出る箇所は設計書に明記して必要があれば他メンバーと共有しました。 結果として、自分の担当範囲では改修起因のデグレを出さずにリリースを完了できました。この洗い出しは後輩指導の際にも共有し、レビューでの手戻りを減らすことにつなげています。 【後輩指導】 答えを渡すのではなく、詰まっている箇所を言語化させてからヒントを出す進め方を取り、自力で調査・解決できる状態まで引き上げることを目標に指導しました。

# プロジェクト概要 家電メーカーの引合管理システム（営業案件の引合情報を管理する社内基幹システム）に対する追加機能開発・改修を担当しました。長期運用されている基幹システムのため、業務ルールがフラグや区分値としてコード全体に散在しており、既存仕様の読み解きが開発の中心となる案件でした。 技術構成はJava（WACS）＋ JSP ＋ JavaScript ＋ DB2。私は基本設計からユーザテスト対応、稼働後の運用保守まで一貫して担当しました。 # 担当業務 ・基本設計 / 詳細設計 / テーブル設計 ・実装（Java / WACS / JSP / JavaScript / DB2） ・テスト仕様書作成、単体テスト・結合テスト、ユーザテスト対応 ・稼働後の運用保守、障害調査・障害対応 ・影響調査 ・他メンバーのフォロー # 工夫した点・成果 【フラグ・区分の網羅的な洗い出しによるテスト漏れの防止】 このシステムは業務ルールが多数のフラグと区分値の組み合わせで表現されており、機能単位で素直にテストケースを作ると、実際の業務で発生する組み合わせを取りこぼすという課題がありました。実際、初期のテスト観点では特定の区分値でしか通らない分岐が抜けていました。 そこで、改修対象の処理が参照しているフラグ・区分をコードとテーブル定義の両方から全て抽出し、値の組み合わせを表に展開してからテスト仕様書を書く手順に切り替えました。組み合わせのうち業務上ありえないものは理由を添えて除外し、その判断根拠もドキュメントに残しました。 結果として、結合テスト以降で観点漏れによる差し戻しを発生させずに完了できました。 【業務委託としての立ち上がり】 未経験の独自フレームワークとDB2の環境でしたが、既存コードの実装パターンを整理しながら追うことで、参画後は設計から独力で回せる状態になり、途中からはメンバーのフォローも任されました。

# プロジェクト概要 大学の在籍管理システムの再構築プロジェクトに、実装・単体テスト担当として参画しました。フロントエンドをTypeScript / React、バックエンドをJava / Spring Bootで刷新し、開発環境はDocker、バージョン管理はGitHubという構成です。 私は主にバックエンド、バッチ（Spring Boot / PostgreSQL）を担当し、あわせてフロントエンド（React）の実装も受け持ちました。 # 担当業務 ・実装（Java / Spring Boot / TypeScript / React / PostgreSQL） ・テスト仕様書作成、単体テスト ・Docker上の開発環境での作業 # 工夫した点・成果 【未経験のTypeScript / Reactを短期間でキャッチアップ】 参画時点でTypeScriptとReactはいずれも実務未経験でしたが、短期プロジェクトで学習期間を取れる状況ではありませんでした。 そこで私は、既存実装のコンポーネント構成と状態管理の書き方を整理し、「このプロジェクトでの正しい書き方」に合わせることを優先しました。言語仕様を網羅的に学ぶのではなく、担当機能に必要な範囲（型定義、props、フックの使い方）から先に押さえ、判断に迷う箇所は着手前に有識者の方へ確認して手戻りを防ぎました。 結果として、参画直後から実装タスクを担当でき、フロント側も含めて予定どおり完了させました。 【担当外の前倒し対応でチーム全体の進行を補完】 自分が担当していたJava側の実装が計画より前倒しで完了した時点で、遅延が見えていた他メンバーの担当分を引き取りました。これによりチーム全体としてスケジュール遅延を出さずに済んでいます。

# プロジェクト概要 資格試験の申請管理システムに対する追加機能開発を担当しました。受験者の申請受付から審査までを扱うシステムででした。 技術構成はJava（Struts2）＋ JavaScript ＋ MySQL、バージョン管理はGitHub。全体32名・担当チーム13名という比較的大きな体制で、私は実装と単体・結合テストを担当しました。 # 担当業務 ・実装（Java / Struts2 / JavaScript / MySQL） ・テスト仕様書作成、単体テスト # 工夫した点・成果 【納期が固定された案件で、遅延分を引き取り納期を遵守】 試験スケジュールに紐づくリリース日のため納期を動かせない一方、終盤で他メンバーの担当分に遅れが出ていました。 私は自分の担当タスクを前倒しで消化し、空いた分で遅れていた機能の実装とテストを引き取りました。引き取る際は既存の実装方針から外れないよう、担当者へ設計意図を確認してから着手し、後で書き直しが必要にならないようにしています。 結果として、単体テストフェーズまでの遅延を解消できました。

# プロジェクト概要 家電メーカーのマスタ管理システムにおける障害対応・改修を担当しています。全社の各業務システムがこのマスタを参照しているため、1つの改修が広範囲に波及する構成で、影響調査の精度がそのまま品質に直結する案件です。 技術構成はJava ＋ JavaScript ＋ Oracle、バージョン管理はGitHub。チーム3名の少人数体制で、基本設計から結合テストまでを担当しています。 # 担当業務 ・障害調査・原因特定、改修方針の立案 ・基本設計 / 詳細設計 ・実装（Java / JavaScript / Oracle） ・テスト仕様書作成、単体テスト・結合テスト ・改修に伴う影響調査 # 工夫した点・成果 【SQL・アプリコード・周辺ツールの3観点による影響調査で改修漏れを防止】 マスタ管理システムは参照元が多数あるため、アプリケーションコードだけをGrepして影響範囲を判断すると、SQL内で直接参照している箇所やバッチなどの周辺ツール経由の参照が抜け、リリース後に別システムで障害が出るリスクがありました。 そこで私は、影響調査を次の3観点で行う手順に整理しました。 ・SQL観点：対象テーブル・カラムを参照しているSQLをソース全体から抽出 ・アプリケーション観点：SQLの呼び出し元を追跡 ・周辺ツール観点：バッチなどアプリ外からの参照を確認 各観点の調査結果を一覧にまとめ、レビューで第三者が追跡できる形で残しています。 結果として、担当した改修で改修漏れによる障害を発生させずに対応できています。障害対応が中心の案件のため、原因調査においても「再現条件を先に特定してからコードを読む」順序を徹底し、調査時間の短縮につなげています。