ID:82546さん

# 商圏分析Webアプリの機能改修と不具合対応 ## 概要 - 商圏分析Webアプリのフロントエンド改修。**利用企業20社**が出店判断・エリアマーケティングの意思決定に日常利用するBtoB業務システム。 - 商圏データの絞り込み・比較を画面操作で行うため、**操作性の不具合が分析作業の効率と、そこから導かれる出店判断の確度に直結する**性質のシステム。 - 現行運用中のアプリに対し、リリース当初から放置されていた既存不具合の調査・修正を担当。放置された不具合が利用企業の業務に与える影響を評価したうえで着手。 ## 担当 - フロントエンドエンジニアとして参画。期間 1ヶ月。 - チーム規模 フロントエンド2名 / バックエンド2名。 ## 使用技術 - Next.js 12（Pages Router）/ React 16 / TypeScript 4 - 状態管理：Recoil、スタイリング：CSS-in-JS - インフラ：AWS（CloudFront + S3） - Claude Code（不具合の原因調査に併用） --- ## 取り組み①｜ブラウザサイズ依存のクリック不具合調査・修正 ### 課題 - ブラウザの表示サイズを縮小すると、ボタンのクリック挙動が変化するという不具合が存在。 - **業務影響**：意図しない要素がクリックされるため、利用企業のユーザーが操作をやり直す手間が発生。ノートPCや、地図・資料と画面を並べての作業時に顕在化しやすく、**候補エリアの絞り込み作業における誤操作・再操作・問い合わせの温床**になっていた。条件指定の取り違えに気づかないまま分析結果を読む懸念もあった。 - この不具合はプロジェクトの初期実装時点（自分の参画前）のテストで既に検知されていたが、**致命的ではないと判断され初回リリースから除外**され、その後約1〜2年放置されていた。 - 発生条件がブラウザサイズという特殊な軸に依存しており、原因の見当がつきにくい状態だった。 ### 打ち手 - Claude Codeに頼る前に、まず手動で再現検証と仮説立てを実施。 - 通常サイズでは正常にクリックできるが、縮小時のみ異常になる、という条件を確認。 - 「ブラウザサイズによってJSの挙動が変わるとは考えにくい」ため、CSSのスタイル設定側に原因があると仮説を立てた。 - 仮説を踏まえ、Claude Codeにソースコードを渡し、**スタイル関連を重点的に調査するよう指示**。加えて、同様のパターンが他画面にも影響していないか、影響範囲まで併せて調査させた。 - 原因は、**z-indexの重なり順の考慮不足**。縮小時のレイアウト変化により、本来はボタンより背面にあるべきチェックボックス要素がボタンより手前に配置され、クリックを奪っていた。 ### 成果 - 約1〜2年放置されていた不具合を解消。 - **ユーザー体験・業務価値**：画面サイズに依存せず意図どおりにクリックできる状態にし、**商圏の絞り込み作業における誤操作と操作のやり直しを防止**。作業中断とサポート問い合わせの発生を抑制するとともに、**意図した条件で分析結果を得られる状態**を担保した。 - **プロダクト価値**：業務システムとして前提となる「押したボタンが押せる」水準の操作信頼性を回復し、**画面サイズを問わず同じ手順で業務を進められる状態**を担保。 - 手動で仮説を立ててから調査範囲を絞った状態でClaude Codeに渡したことで、**原因特定に要した時間は約5分**。「原因不明のまま丸投げする」のではなく、当たりをつけてから調査を依頼する進め方が、調査時間の短縮に直結した。 - 同様のz-index起因の不具合が他画面に潜んでいないか、影響範囲まで確認した状態で修正を完了。**同種の不具合の再発・潜在化を予防**。 --- ## 取り組み②｜存在しないページで404が表示されない不具合の原因調査・対応方針の検討 ### 課題 - 存在しないURLにアクセスした際、本来表示されるべき404画面が表示されない。 - **ユーザー体験上の影響**：画面上に `Access Deny` のXMLがそのまま表示され、**利用企業のユーザーが「システム障害か、自分の権限不足か」を判断できない状態**だった。URLの打ち間違いや古いブックマークからの遷移時に、正しい導線へ戻る手段が提示されない。 - **プロダクト価値上の影響**：内部のストレージ構成が露出した生のエラーが業務システムの画面に出ることは、体裁・信頼性の面で望ましくなく、原因切り分けのつかない問い合わせを誘発しうる状態。 - ローカル環境では正常に404画面へ遷移するため、**アプリケーションコードではなくインフラ側（CloudFront + S3）の問題**と切り分けた。 - 存在しないページに対応するS3オブジェクトを探しに行った結果、S3側のエラーレスポンスがそのままユーザーに返っていることが原因と特定。 - リリース当初（約2年前）から存在していたが、不正な操作につながるものではなかったため、これまで対応が見送られていた。 ### 打ち手 - ローカル環境と本番環境の挙動差分から、原因をインフラ層（CloudFront / S3のルーティング・エラーハンドリング）に切り分けた。 - 対応方針として、**CloudFront Functions と KVS（Key-Value Store）を組み合わせた実装を検討・立案**。存在しないパスへのリクエストをCloudFront層で判定し、S3への到達前に適切な404レスポンスを返す構成を設計した。 - 単なる画面の見栄え改善ではなく、**「ユーザーを正しい導線に戻す」「適切なHTTPステータスを返す」という2点を対応のゴールとして定義**し、方針を関係者に説明できる形に整理。 ### 成果 - アプリケーションコードではなくインフラ層（CloudFront + S3のエラーレスポンス）に原因があることを特定し、約2年間原因不明だった不具合の所在を明確化した。 - **ユーザー体験・業務価値（実装により実現する状態）**：存在しないURLへ遷移した場合でも、内部エラーではなく**アプリケーションとしての404画面で案内を返し、ユーザーが自力で正しい画面へ復帰できる状態**にする。原因不明の画面表示に起因する問い合わせを抑制。 - **プロダクト価値**：正しいHTTPステータスを返すことで、エラーレスポンスの適正化とクローラ・監視系に対する挙動の正常化を図る方針を確立。 - CloudFront Functions + KVSによる解決方針を具体的な構成レベルまで設計。実装フェーズに進める状態まで整理した。 --- ## 工夫した点 - **不具合を「コードの誤り」ではなく「業務への影響」として評価し、対応要否・優先度を判断した。** 2つの不具合はいずれも長期間放置されていたが、それぞれ「致命的ではないと判断され初回リリースから除外」「不正操作につながらないため見送り」という異なる経緯を確認したうえで着手。放置の背景と、実際に利用企業の業務・体験に生じている影響を突き合わせて優先度を決めた。 - **Claude Codeに丸投げせず、先に手動で再現条件を絞り仮説を立ててから調査を依頼した。** 「ブラウザサイズでJSの挙動は変わりにくいはずだからCSS起因だろう」という当たりをつけたうえで、調査範囲をスタイル関連に絞って指示したことで、原因特定を約5分に短縮。仮説なしに丸ごと調査させるより、絞り込みの精度と速度の両方を確保できるアプローチ。 - **ローカルと本番の挙動差分から、原因の切り分けをアプリケーションコードとインフラの間で明確に行った。** 「ローカルでは再現しない」という事実を、追加調査を進める前の切り分け材料として使い、無駄なアプリケーションコードの精査を避けた。 - **修正対象の画面単体で完結させず、横展開の確認まで含めて完了とした。** z-index起因の同種不具合が他画面に潜んでいないかを確認し、同じ原因による再発を防いだ。

# 不動産向け用地管理アプリの投資開発 ## 概要 - 既存の不動産事業者向け用地管理サービスのフロントエンド開発。地図上に物件情報や用途地域、防災情報などをレイヤー表示し、対象区画の情報を検索・照会するBtoB業務システム。**不動産業界15社が業務で利用**。 - 既存画面の分割・API差し替え、フォーム state 管理の是正、表示崩れの修正、テスト仕様の設計・実施、およびテスト自動化基盤の構築を担当。 ## 担当 - フロントエンドエンジニアとして参画。期間 約1年。 - チーム規模 12名（フロントエンド3名 / バックエンド4名 / インフラ3名 / PM1名 / プロジェクトオーナー1名）。 - 画面の設計・実装、既存機能の不具合調査・修正、テスト仕様書の作成・実施、リリース後の運用保守までを担当。 ## 使用技術 - React 16.14 / TypeScript 4 - 状態管理：Redux / Redux-Saga、フォーム：Formik、UIコンポーネント：MUI - 地図：OpenLayers + MapLibre GL JS（OpenLayers上でMapLibreのスタイルを扱うモジュールを併用） - 背景地図をラスタタイルからベクタタイルへ差し替え（描画速度改善） - レイヤの追加・重なり順・表示切替の実装 - テスト自動化：Playwright / Claude Code（Playwright MCP） --- ## 取り組み①｜Formik の state 管理不備による表示不整合と過剰な再描画の是正 ### 課題 入力項目30個を持つフォーム画面で、2つの問題が同時に発生していた。 - **入力値と画面表示・エラー表示が食い違う。** 調査の結果、フォーム state 管理に Formik を採用していたにもかかわらず、Formik が内部管理する `values` オブジェクトを直接書き換える実装になっていた。オブジェクトの参照が変わらないため React が更新を検知できず、画面に反映されない。これを回避するため、変更イベントを手動で発火させて強制的に再描画させる実装が入っており、値の更新とバリデーション実行の順序が保証されない状態になっていた。 - **1項目の入力で画面全体が再描画される。** Formik の Context を生成する箇所で、1項目が変更されるたびにフォーム全項目の値を保持するオブジェクトを丸ごと再生成し、state にセットしていた。Context の value の参照が毎回変わるため、値を購読する全コンポーネントが再描画されていた。 ### 打ち手 - React DevTools の Profiler で再描画の影響範囲を計測し、1項目の入力に対してどのコンポーネントまで再描画されているかを特定。原因を推測ではなく計測から突き止めた。 - Formik の state 直接書き換えと手動発火トリガーを廃止し、`setFieldValue` / `setValues` など Formik の公式APIに統一。イミュータブルな更新とバリデーションが正しい順序で実行される状態に是正した。 - 全項目分のオブジェクトを都度再生成する実装を改め、変更対象のみを更新する形に修正。Context の value が不必要に参照変更されない構造にした。 ### 成果 - 入力値と表示内容の不整合を解消。 - 回避実装（手動発火トリガー）を削除したことで、以後の改修時に同種の不整合が再発しない構造にした。 - 入力ごとに発生していたフォーム全体の再描画を、変更対象の範囲に限定した。 --- ## 取り組み②｜表示崩れの修正と、優先度判断基準の設計 ### 課題 - 特定条件下でのレイアウト崩れが存在。具体例： - 一覧テーブルのレスポンシブ対応が不十分で、狭幅端末では列が見切れて情報が読めない - 地図上のコントロールの押下範囲が狭く、クリックに失敗する - スピナーのレイヤーが見切れる、フォントサイズが画面間で不統一 - 工数が限られるなか、どこから着手するかの判断基準がチーム内で共有されていなかった。 ### 打ち手 - **優先度基準を「その不具合で操作が完了できるか」に統一**して整理した。 - 高：押下範囲が狭くクリックできない、テーブル列が見切れて情報が読めない → 操作が完了しない - 低：フォントサイズの不統一、スピナーレイヤーの軽微な見切れ → 違和感はあるが操作は完了する - 判断材料として、アプリを初めて操作するユーザーの目線で全画面を通しで操作し、詰まる箇所を洗い出した。 - 重なり順・条件分岐を精査し、z-index をレイヤー単位で整理したうえで修正。 ### 成果 - 起票済みの表示崩れ3件を、上記基準に沿って優先度付けし解消。修正後の再起票は発生していない。 - 場当たり的な対応で終わらせず、以後の不具合起票時にも適用できる判断基準として整理した。 --- ## 取り組み③｜既存検索画面の機能分割・API差し替えとUI改善 ### 課題 - 1つの画面に「建物名検索」と「企業名検索」という性質の異なる2機能が混在しており、**どちらの検索をしているのか分かりにくいという不満がユーザーから上がっていた**。 - 画面のUI設計が直感的でなく、入力の動線が伝わらない状態だった。 - 必須入力項目が画面上部になく、何から入力すべきか分からない - クリック可能な入力欄にプレースホルダがなく、操作可能な箇所が判別できない - 不要な余白が多く、その分だけ入力フォームの幅が圧迫されて短くなっていた - 併せて、画面が参照するAPIの差し替えが必要だった。 ### 打ち手 - 混在していた2機能を**機能単位で2画面に分割**。ユーザーが「今どちらの検索をしているか」が画面上で自明になる構成に変更した。 - コンポーネントを「UIの表示責務」と「ロジック・状態管理責務」に分離する方針で再構成し、分割後の再利用性・保守性を確保。 - UI改善として、必須入力項目を上部に並び替え、クリック可能な箇所にプレースホルダを追加して動線を明示、不要な余白を削除して入力フォームの幅を確保した。 - **APIを4本差し替え**、レスポンスの型をAPI仕様をもとに手動で定義。併せて Props の型設計も整備し、既存機能との統合時の型安全性を担保した。 ### 成果 - 機能混在によるユーザーの混乱を、画面分割という構造的な変更で解消。 - API 4本の差し替えを、型定義の整備により実行時エラーを発生させずに完了。 - 入力の動線を明示する改善を行い、初見ユーザーが操作に迷う箇所を解消した。 --- ## 取り組み④｜テスト仕様の設計・実施 ### 課題 - 新規画面追加および新規機能（実装は他メンバー担当）に対し、品質を担保するテスト仕様が不足していた。 - 既存のテスト仕様書は確認内容が曖昧で、テストとして機能していない箇所があった。例：「正しく検索されること」——何をもって正しいとするかが定義されておらず、実施者によって判定が変わる状態。 ### 打ち手 - 既存のテスト仕様書をベースに、新規画面・新規機能に対応するテスト仕様書を新規作成。 - 既存仕様書の曖昧な確認内容を、**確認観点を言語化する形に書き換え**た。「正しく検索されること」を、入力条件・期待される結果件数・表示項目・表示順といった判定可能な粒度に分解し、実施者が変わっても同じ判定になる状態にした。 - 作成した仕様書に基づきテストを実施。 ### 成果 - **新規作成したテスト仕様書 7件（テストケース 200〜300件）** - **既存テスト仕様書 3件を更新（テストケース 約50件）** - **実施したテスト仕様書 10件（テストケース 約500件）** - 確認観点の言語化により、実施者による判定のブレを排除した。 --- ## 取り組み⑤｜手動テストのPlaywright自動化（現在進行中） ### 課題 - ④のテストは全て人力実施が前提であり、リリースのたびに**約500ケース**の実施コストが発生していた。1ケースあたりの所要時間は30秒〜5分で、全ケースを通しで実施すると**数時間〜数十時間規模**となる。リリース頻度を上げるうえで、継続的な品質担保の運用が限界に近づいていた。 - 対象アプリには、自動テストのロケータ指定を困難にする構造的な問題があった。 - **属性のIDがビルドごとに採番される**ため、ID指定でのロケータが機能しない - **MUI を使用しており、クラス名がライブラリの仕様で変動する**ため、クラス名指定も不可 - **アクセシビリティ対応が不十分**（`aria-role` 未設定、ラベル名の欠落など）で、ロール・ラベルベースのロケータも使えない ### アプローチ Claude Code + Playwright MCP を用い、テスト仕様書の自然言語手順から自動テストコード（`spec.ts`）を生成する仕組みを構築中。 初期に「テスト仕様書を読み取って自動テストを実装して」と単純に指示する方式を試したが、**トークンを消費し切る／正常に動作しないテストコードが生成される**結果となった。原因を、参照すべき情報量が過大なことと、ロケータ選定の判断材料がアプリ側に存在しないことの2点と分析し、生成の前段でコンテキストを構造化する方針に切り替えた。 - **テスト仕様書（Excel）を Markdown に変換**し、読み取りコストを削減。 - **テストコード生成の前に POM（Page Object Model）を作成**する2段階構成に変更。 - まず画面名を指定して Claude Code に POM を生成させ、生成結果を人手で修正して確定させる。 - 以降のテストコード生成では**必ずPOM経由でのみ要素にアクセスするルールを設定**。最も判断が揺れるロケータ選定を、確定済みのPOMに集約した。 - **テスト仕様書側の曖昧な手順・確認内容を明示化**。④で行った確認観点の言語化が、そのまま自動化の前提条件として機能した。 - 地図の描画確認など**視覚的判断が必要なテストは対象外**として切り分け、自動化可能な範囲を先に固めた。 ### 現時点の成果と今後の展開 - **テストケース20件の自動化に成功**し、上記アプローチが機能することを検証済み。単純に指示を投げるだけでは1件も安定生成できなかった状態からの改善。 - 自動化した20件は手動実施で10〜100分相当。これがリリースごとの繰り返し作業から外れた。 - 残り約480ケースへの横展開が可能な構造（POM + Markdown化した仕様書）を先に整備しており、全ケース自動化時には**リリースごとに数時間〜数十時間規模の削減**を見込む。 - 今後の目標： - 全画面のテストを自動化し、CIに組み込む（現状はローカル実行のみ） - 視覚的な確認は参考画像との比較（ビジュアルリグレッションテスト）で機械的に判定できるようにする --- ## 工夫した点 - **不具合の原因を推測ではなく計測から特定した。** React DevTools の Profiler で再描画の影響範囲を可視化し、「1項目の変更のたびに全項目分のオブジェクトを再生成して Context の参照を変えている」という根本原因まで辿ったうえで修正したため、対症療法的なメモ化の追加で終わらせずに済んだ。 - **回避実装を暫定対応のまま残さず、ライブラリの想定する使い方に戻した。** 手動発火トリガーは動作してはいたが、以後の改修のたびに同種の不整合を生む構造だったため、公式APIに統一して構造ごと解消した。 - **バグ対応の優先度を、見た目の違和感ではなく「操作が完了できるか」で線引きした。** 初見ユーザーの目線で全画面を通しで操作して詰まる箇所を洗い出し、限られた工数をUXへの影響が大きい順に配分した。 - **LLMへの丸投げが失敗した後、制約設計に切り替えて自動化を成立させた。** テストコード生成では、モデルの能力ではなく与えるコンテキストの構造が成否を分けると判断し、仕様書のMarkdown化・POMの事前確定・POM経由アクセスの強制という3段の制約を設けた。最も判断が揺れるロケータ選定を人間が確定させたPOMに集約することで、生成結果の再現性を確保した。 - **テスト仕様書の確認観点を言語化した作業が、そのまま自動化の前提として効いた。** 「正しく検索されること」のような曖昧な記述は、人間が実施する場合も自動生成する場合も判定不能である点は同じ。手動テストの品質改善と自動化の下準備を、同じ作業で兼ねる形にした。

# 空間情報データ処理の月次手動作業ツール化 ## 概要 -空間データの月次手動作成作業のツール化。対象エリアは都心部（東京・千葉・埼玉・神奈川・大阪・京都・奈良・福岡）。 - Excel VBA・C#・Python を組み合わせた自動化ツールの設計・開発、ツール化の過程で発覚した潜在バグの調査・修正、属人化していた業務手順のドキュメント整備を担当。 ## 担当 - データエンジニアとして参画。期間 2020.12〜2024.04（約3年4ヶ月）。チーム規模5名。 - ツール開発に加え、潜在バグの調査・修正、業務ドキュメントの整備までを一貫して担当。 ## 使用技術 - Python / C# / Excel VBA - 開発期間：約2週間（既存マクロの固定値化されていた箇所を引数呼び出し可能な形に改修し、一から作り直すことはせず既存資産を活用） --- ## 取り組み①｜月次手動作業のツール化 ### 課題 月次で発生する地図データの変換・加工処理が、担当者の手作業に全面依存していた。 - Excelマクロツールの実行やテストのため、**Excelへのコピペ**や**所定フォルダパスへのログファイルの手動配置**が必要で、ファイル名やコピペ位置が少しでもずれると結果が狂う、精度を要求される手順だった。 - マクロの検査結果はExcel上に**数百セル規模**で出力され、実施者・チェッカーによる目視確認が必要だった。熟練者であれば手順自体のミスはほぼ発生しないが、**この大量セルの見逃しが3ヶ月に1回程度のペースで発生**していた。 - 手順が複雑なため、業務に精通した人を固定でアサインする必要があり、担当交代のたびに手順を覚えるまでに時間がかかっていた。結果として、対応できる人材が限られる状態が続いていた。 ### 打ち手 - 処理内容を整理し、適材適所で言語・ツールを選定。定型的なデータ加工はPython、既存の業務フローとの親和性が高い部分はExcel VBA、より複雑な処理が必要な箇所はC#で実装。 - 既存マクロの中で固定値になっていた箇所を、引数として外部から呼び出せる形に改修。ゼロからの作り直しを避け、既存資産を活かしながら自動化した。 - 開発期間は約2週間。 ### 成果 - **月次作業の工数を、担当者6人日 → 2人日に削減**。 - 目視確認による**見逃しミスを、3ヶ月に1回程度の発生からほぼゼロに削減**。 - ツール化により手順の複雑さが解消され、**業務に不慣れな人材（派遣社員・アルバイト）でも作業を任せられる**体制に変わった。特定の熟練者に依存しない運用が可能になった。 - 開発したツールは、**現在も継続して社内で利用**されている。 --- ## 取り組み②｜潜在バグの調査・修正 ### 課題 - ツール化にあたり既存マクロの処理内容を洗い出す過程で、比較対象データに問題があることが判明。 - 本来は前月データと比較すべき処理が、発覚時点で**3年前のデータと比較**されたまま動作していた。 - この処理は前任者を含め**誰も中身を明確に把握できていない**状態で長年運用されており、ツール化のために内部処理を精査したことで初めて発覚した不具合だった。 - 影響として、**ユーザー報告用データの一部に誤りが生じていた**（当該データの利用頻度が低かったため、実害としては大事に至らなかった）。 ### 打ち手 - データの更新フローを追いかけ、比較対象データが更新されずに古いまま参照され続けていた原因箇所を特定。 - 発覚後、**即日で修正対応**。以降の処理が正しい比較対象データをもとに動作する状態に是正した。 ### 成果 - 数年単位で気づかれずに残っていたデータ品質の問題を解消。 - ツール化を「作業の置き換え」で終わらせず、既存処理の内容を精査する過程として活用したことで、手作業運用のままでは発見されなかったであろう不具合を検出・是正できた。 --- ## 取り組み③｜業務ドキュメントの整備 ### 課題 - 業務手順は、それまでメモ帳に**約200行**書かれている程度で、初見の担当者では到底再現できない状態だった。 - ドキュメント不足により、**納品物のフォルダ構成を誤る**といったミスも発生していた。 ### 打ち手 - ツール開発と並行し、業務手順をExcelでドキュメント化。**事前準備・ツール実行・テスト・納品物作成**というフェーズごとに整理し、**全10ページ**にまとめた。 - ツールの使い方だけでなく、前提条件・注意点までセットで記載し、担当者が変わっても同じ手順・同じ品質で再現できることを意識して整備。 ### 成果 - 属人化していた業務を、**メモ書き200行 → 体系化されたドキュメント10ページ**に整理。 - フォルダ構成ミスのような、手順不備に起因するミスの再発を防止できる状態にした。 - 担当者交代時の引き継ぎコストを削減し、取り組み①の「不慣れな人材でも作業可能」な体制を、手順面から支える基盤とした。 --- ## 工夫した点 - **ゼロから作らず、既存マクロの資産を活かして自動化した。** 固定値になっていた箇所を引数化するという最小限の改修で自動化を実現し、開発期間を約2週間に抑えた。全面的な作り直しではなく、既存の枠組みの中で置き換え可能な部分を見極めるアプローチを取った。 - **ツール化の過程そのものを、ブラックボックス化した既存処理の点検機会として使った。** 前任者すら把握していなかった比較ロジックの中身を、自動化のために精査したことで、手作業運用のままでは発見されなかった潜在バグを検出できた。「自動化する」と「中身を理解する」が同じ作業として機能した。 - **属人化の解消を、ツールとドキュメントの両輪で実現した。** ツール化だけでは「操作は簡単になったが、なぜそうするかは分からない」状態が残る。前提条件・注意点までドキュメント化することで、実際に不慣れな人材へ作業を任せられる体制にまで落とし込んだ。

# 社内ツール開発｜Windowsイベントログ自動出力ツール ## 概要 - インターネット非接続の専用PCでの作業を対象とした、顧客提出用の作業証跡（イベントビューアログ）自動出力ツール。 - 元々はWindows標準のイベントビューアを目視・手動で確認し証跡化していたが、その手間を解消するため**新規に個人開発**し、課内承認を得て正式運用ツールとして導入。 ## 担当 - 個人開発者として、企画・調査・開発・課内承認取得・運用まで一貫して担当。 - 開発期間：**1週間以内**。 - チーム規模：**1名（自分単独）**。 ## 使用技術 - PowerShell - Windowsイベントビューア --- ## 取り組み①｜証跡取得作業の自動化と不正ログイン検知の仕組み構築 ### 課題 - 顧客への作業証跡提出が必須要件であり、厳密性が求められる案件。 - 従来はイベントビューア標準機能を目視・手動で確認・証跡化しており、**1回あたり30〜45分**を要していた。作業は不定期受注だが、受注月は**月4回程度**発生。 - 顧客提出物である以上、未承認ユーザ（社員であっても）のPCログイン痕跡も検知する必要があり、目視作業では**見落としがリスク**になっていた。 ### 打ち手 - イベントビューアの必要な設定やPowerShellの使い方など知識がない状態から1から調査し、実装。 - **ADFS認証による社員番号で承認ユーザを識別**し、正常動作のログと不正ログイン検知ログをフォルダ分離する仕組みを構築。 - 通知機能の実装は行わず、PC自体が厳格なセキュリティ体制で保管されていたことを踏まえ、**作業有無に関わらず担当者が毎日不正ログフォルダを目視確認**する運用でカバーする方針を採用（顧客との合意は担当者が費用対効果をもとに交渉）。 ### 成果 - 証跡取得作業を**30〜45分から約5分に短縮**。 - 誤って不正ログインしてしまった社内の人間も、作業時に検知できる体制を実現。 - 課内承認を得て正式運用ツールとして採用。

# 個人受注開発 | LINE Notifyを利用した自動配信Webアプリ作成 ## 概要 - 副業として個人で受注したBtoC向けWebアプリの**新規開発**案件 - LINE Notifyを利用し、通知メッセージをスケジュール配信・即時配信できるアプリ。配信履歴管理、LINEユーザー単位の配信制御を実装 - **顧客折衝・要件定義・技術選定・設計・実装・インフラ構築・リリースまでを単独で完遂**。開発工程の一部ではなく、案件全体に責任を持つ立場で推進 ## 担当 - 役割：受注者兼開発者（要件定義〜リリース、リリース後の対応まで**全工程を一人で担当**） - 参画期間：**2.5カ月** - チーム構成：自分のみ（顧客と直接やり取り。社内レビュー・上流担当者なし） ## 使用技術 - 言語・フレームワーク：PHP（Laravel）、JavaScript - 外部API：LINE Notify - インフラ：ロリポップ（レンタルサーバー）、独自ドメイン取得・設定 --- ## 取り組み①｜顧客が要件化できていない領域を先回りして設計に落とし込んだ ### 課題 - 顧客の要望は「LINEで配信したい」の一点のみ。**再送制御・管理UI・配信先の制御といった、実運用に不可欠な要素が要件として一切存在しない状態** - 上流工程を担う人間が自分以外におらず、要件の抜けをそのまま実装すれば運用開始後に破綻するリスクがあった ### 打ち手 - 「配信したい」の裏にある運用シーンを想定し、不足機能（誤配信防止のための配信先制御、失敗時の再送、履歴確認、管理画面の操作性）を自ら洗い出して提案 - **文章だけでは認識齟齬が生まれると判断し、モックを作成してキャプチャを共有**。動くイメージを見せながら合意形成を進めた - 一度で決めきらず、小刻みに確認を挟むことで手戻りを最小化 ### 成果 - 顧客が当初想定していなかった機能を含めて要件を確定させ、**認識齟齬による大きな手戻りなくリリースまで到達** - 発注側の言語化されていないニーズを引き出し、要件として構造化する進め方を確立 ## 取り組み②｜スケジュール配信・即時配信を単一基盤で成立させる設計 ### 課題 - 「指定日時での配信」と「即時配信」という性質の異なる2方式を、レンタルサーバーという実行環境の制約下で両立させる必要があった - 外部API（LINE Notify）依存のため、通信失敗時に配信が欠落する構造的リスクを抱えていた ### 打ち手 - **Laravelのタスクスケジューラ（cron）とキューを組み合わせ**、2方式を同一の配信処理基盤に集約する構成を設計。処理の重複実装を避け、保守性を確保 - LINEユーザーごとにアクセストークンをDBで管理し、**ユーザー単位の配信可否制御**を実装。意図しない相手への配信を構造的に防止 - 配信失敗時の**リトライ処理とエラー通知**を組み込み、外部API起因の配信漏れを検知・回復できる状態に ### 成果 - スケジュール配信・即時配信・失敗時リトライまでを含む配信基盤を単独で設計・実装しリリース - 障害が「起きない前提」ではなく「起きても気づける・回復できる」設計に落とし込み、運用負荷を抑えた ## 取り組み③｜コスト制約下での技術選定と未経験領域の自走キャッチアップ ### 課題 - 顧客から**月額ランニングコストを可能な限り抑えたい**という制約。クラウド前提の構成は選択肢から外れた - ロリポップは別案件で触った経験があったが、**アプリをデプロイするのは初めて**。手順もノウハウも無く、相談できる相手もいない状態 ### 打ち手 - 制約を踏まえPHP（Laravel）＋レンタルサーバー構成を選定。技術的な好みではなく**顧客のコスト要件から逆算して意思決定** - Udemy・Laravel公式ドキュメントで不足知識を補い、検証を繰り返してデプロイ手順を自力で確立 - ドメイン取得・DNS設定を含むインフラ周りを一貫して対応 ### 成果 - 追加のランニングコストを発生させず、**顧客の予算制約を満たした構成でリリースを実現** - 未経験の領域を、期限内に自走でキャッチアップして本番稼働まで持ち込む進め方を実証

# 航空会社向け基幹システム導入プロジェクト（PM補佐） ## 概要 - 1億円規模の航空会社向け基幹システム導入プロジェクトにPM補佐として参画。 - ユーザとの仕様調整、テストスケジュールの策定・進捗管理、結合テストのケース作成、導入作業手順書の精査、リリース立ち合い、導入後の問合せ対応まで一貫して担当。 ## 担当 - PM補佐として参画。期間 2016.05〜2017.04（約1年）。チーム規模20名。 - 開発フェーズのテスト管理から、リリース、稼働後の問合せ対応までプロジェクトのライフサイクル全体に関わった。 ## 使用技術 - C# / PL-SQL / Oracle / Object Browser - 進捗管理：Excel --- ## 取り組み①｜結合テストの管理と、テストケース・手順書の品質改善 ### 課題 - 仕様調整後、結合テストのスケジュール策定・進捗管理・作業割り振りを担当。テスト期間は約2ヶ月。 - テストケースや作業手順書に、**「ボタンをクリックして成功すること」のように成功判定の観点が明記されていない**という共通の問題があった。実施者によって「成功」の判断基準がぶれる状態で、品質担保として機能しづらい状態だった。 ### 打ち手 - 結合テストのケース作成にあたり、実施者が変わっても同じ判定になるよう、成功観点を明記する形に是正しながら整備。 - Excelで進捗管理を行い、作業の割り振りとスケジュール管理を担当。 ### 成果 - 判定基準が曖昧なテストケースを解消し、抜け漏れのない品質担保につなげた。 - 約2ヶ月のテスト期間を計画通りに完了。 --- ## 取り組み②｜過去リリースの問題点の体系的な洗い出しとリスク低減 ### 課題 - 過去のリリースで発生した問題が十分に整理・共有されておらず、同様のトラブルが再発するリスクがあった。 ### 打ち手 - 社内外の関係者を巻き込み、過去リリースで発生した問題点を体系的に洗い出してリスト化。 - **洗い出した内容を、導入作業手順書そのものに反映**。手順の曖昧さを解消し、判定観点を明記する形で手順書を作り直した。 - これにより、**システムに詳しくない担当者でもリリース作業を実施できる**水準まで手順書の精度を引き上げた。 ### 成果 - 再発防止策を手順に事前に組み込み、同種の作業ミスによる手戻りを抑制。 - 属人的な知識に頼らずリリース作業を遂行できる体制を、手順書という形で残した。 --- ## 取り組み③｜リリース当日の立ち合いと導入後の問合せ対応 ### 課題 - リリース当日、現地での問題発生時に即時対応できる体制を用意する必要があった。 - システム稼働後、現場ユーザからの問合せを適切にトリアージし、社内で迅速に共有・調査できる窓口が必要だった。 ### 打ち手 - リリース当日は立ち合いを実施。①②で精査した手順書に沿って作業を進行した。 - 稼働後は問合せ窓口を担当。**稼働後1ヶ月で約8件**の問合せに対応。実際の不具合はそのうち1割程度で、残りは使い方に関する要望や、一見不具合に見えるが仕様通りの挙動だった。 - 説明の際は文章だけでなく、**時系列が分かる図をExcelに添付**して説明することで、状況の理解齟齬を防いだ。 - 実際に発生した不具合の1件（夜間バッチのトランザクション処理で、SQLの取得対象データが0件のケースへの仕様考慮漏れ）を説明する際は、「DB」「トランザクション」といった技術用語を使わず、顧客が業務で使っている「売上」「仕訳」といった用語に置き換えて説明した。 ### 成果 - リリース当日は手順書の精度が功を奏し、トラブルなく進行。**予定より約20分作業が前倒しで完了**し、余裕を持って作業を終えられた。 - 技術的な不具合内容を非エンジニアに伝わる言葉で説明することで、現場ユーザの不安を早期に解消し、システムの定着を促進した。 --- ## 工夫した点 - **「成功判定の観点が書かれていない」という、テストケースと手順書に共通する根本原因を見つけて、両方に同じ是正を適用した。** 個別のケースを場当たり的に直すのではなく、判定基準の明記という共通の型を持ち込むことで、品質担保の水準を横断的に引き上げた。 - **過去の失敗をリスト化するだけで終わらせず、実際に手順書へ反映して「詳しくない人でも作業できる」水準まで落とし込んだ。** 知見の共有を情報として残すだけでなく、誰が実施しても再現できる形に変換した。 - **技術的な内容を、相手の使っている言葉に翻訳して説明した。** 夜間バッチのトランザクション処理という技術的な不具合を、「DB」「トランザクション」ではなく顧客の業務用語（「売上」「仕訳」）に置き換えて説明し、図も併用することで、非エンジニアとの認識齟齬を防いだ。

# オフライン待ち合わせアプリ（個人開発 / Web アプリ） ## 概要 - 「迷ったらここに集合しよう」を地図上のピン一つで伝えるための待ち合わせ Web アプリ。BtoC 想定の個人開発プロダクト - 待ち合わせの合流は、電話・文字による口頭説明では場所の認識ズレが起きやすく、**電波が不安定な場所では地図アプリ自体が開けない**という前提の弱さがある。本アプリは事前ダウンロードにより、通信不能な状況でも「どこに集合するか」を全員が同じ画面で確認できる状態を担保する - 対象ユーザーはスマホ操作に不慣れな友人・家族を含む幅広い層。難しい操作なしに地図と目的地へ到達できることを最優先の設計方針とした - 企画・要件定義から設計・実装・デプロイまでを一人で担当した新規開発 ## 担当 - 役割：設計・開発（フルスタック） - 参画期間：2026年3月 - チーム構成：1名（個人開発） ## 使用技術 - フロントエンド：React / TypeScript / MapLibre GL JS / Zustand（状態管理） - オフライン基盤：Service Worker / IndexedDB - バックエンド・インフラ：Supabase / Firebase Hosting / GitHub Actions（CI） - テスト：ユニットテストによる TDD（ドメイン層・hooks・リポジトリ実装） --- ## 取り組み①｜地図・目的地のオフライン対応 ### 課題 - 待ち合わせ場所は、山間部・地下・イベント会場など**電波が不安定な場所であることが多く**、既存の地図アプリは通信が切れた時点で地図もピンも確認できなくなる - **業務影響**：合流直前の一番必要なタイミングで地図が開けず、「どこに行けばよいか分からない」状態が発生。結果として電話やメッセージでの口頭案内に逆戻りし、待ち合わせのやり直し・合流の遅延につながる ### 打ち手 - 「現地で通信できない」前提を受け入れ、**通信できるうちに必要なデータを端末へ移しておく**方式を採用 - Service Worker で fetch をインターセプトし、地図タイルと目的地データをオンライン時に IndexedDB へ保存。以降はネットワーク状態に依存せず同じ描画経路で表示されるよう設計 - 地図・目的地・マーカーをドメインモデルとして定義し、データ取得元（Supabase / IndexedDB）の差異をリポジトリ層に隔離。上位のコンポーネントがオンライン・オフラインを意識せずに動作する構造にした ### 成果 - **ユーザー体験価値**：電波の届かない環境でも、ダウンロード済みの地図とピンをそのまま閲覧できる状態を実現。現地で「地図が開かない」ことによる合流の停滞を回避できる - **プロダクト価値**：オンライン／オフラインで描画ロジックを分岐させず、ネットワーク状態に関わらず一貫した表示体験を提供する構造とした - 通信断をエラーではなく想定内の状態として扱うことで、アプリの前提となる信頼性を確保 ## 取り組み②｜スマホ操作に不慣れな層でも完了できる導線設計 ### 課題 - オフライン対応は「事前準備」を伴うため、通常はユーザーに手順（範囲選択・保存操作など）を求めることになる - **業務影響**：準備の手順が複雑だと、デジタルに不慣れな家族・友人が準備を完了できず、結局オフラインで地図を開けない。**機能があっても届けたい相手に届かない**という状態になる ### 打ち手 - 準備操作を「用意された地図をタップする」だけに絞り込み、範囲指定やズーム調整といった判断をユーザーに求めない設計にした - 目的地はピンで登録し、URL で共有する形式を採用。受け取る側はリンクをタップするだけで同じ地図・目的地を確認・保存でき、アプリ導入や会員登録を挟まない - 目的地カテゴリ（レストラン / カフェ / トイレ / ショップ等）をアイコンで表現し、文字を読まずに識別できるようにした ### 成果 - **ユーザー体験価値**：招待された側は「リンクを開く → タップする」のみで準備が完了。操作説明を送る側の手間と、受け取る側の操作つまずきの双方を抑制 - **プロダクト価値**：オフライン機能の利用率が事前準備の難易度に左右されない構造とし、機能価値が実際に発揮される状態を担保 ## 取り組み③｜TDD とクリーンアーキテクチャによる保守性の確保 ### 課題 - 個人開発かつ継続的な機能追加（対応地図の拡充・認証認可）を前提としており、**時間を空けて再着手した際に仕様と設計意図を思い出せないと、変更コストが跳ね上がる** - 地図描画（MapLibre）・永続化（Supabase / IndexedDB）と外部依存が多く、ライブラリ都合がドメインロジックに侵食すると差し替え・修正が困難になる ### 打ち手 - ドメインロジック（Destination / Map / LngLat 等）を TDD で実装し、**テストコードが設計ドキュメントとして機能する**状態を意識した - レイヤードアーキテクチャ（domains / application / infrastructure）とフィーチャーアーキテクチャ（features 単位）を組み合わせ、責務分離とファイル構成の見通しを両立 - 地図ライブラリとデータストアはインターフェース経由で利用し、実装をインフラ層に隔離 ### 成果 - **将来コスト**：外部ライブラリ・データストアの差し替え時の影響範囲をインフラ層に限定できる構造とした - リグレッションをテストで検知できる状態とし、機能追加時の手動確認工数を抑制 - GitHub Actions による CI を整備し、変更のたびに品質チェックが自動で回る状態を構築 --- ## 工夫した点 - **制約を要件として先に固定する**：「現地では通信できない」を回避すべき例外ではなく前提条件として設計に組み込み、事前キャッシュ方式という解に到達した - **機能価値は到達率まで含めて評価する**：オフライン機能は「準備してもらえて初めて価値が出る」ため、機能実装と同等の比重で準備導線の単純化に工数を割いた - **想定ユーザーを最も操作に不慣れな層に置く**：一番手前のユーザーが完了できる操作数を基準に UI を削り込み、判断を伴う設定項目を排除した - **一人開発でも設計の説明可能性を残す**：TDD とレイヤ分離により、期間を空けた再着手や第三者への引き継ぎに耐える状態を維持した ## 公開 - Firebase Hosting でデプロイ、GitHub でソースコード公開 - 技術記事として Qiita に実装内容を公開（[記事](https://qiita.com/shun123/items/91a65bfbe41aea8dbbda) / [リポジトリ](https://github.com/shun144/meeting-map)） ## 今後の展望 - 地図スタイル・UI の改善 - 対応地図の拡充 - 認証認可による機能拡張