ID:74004さん

**＃概要** 製品の修理依頼を受け付け、業務フローに沿ってステータスを管理するシステムの新規開発（Python / Django）。店舗の登録画面、基幹連携用のCSV出力、自社ECからの申込み受付API、倉庫（WMS）との日次連携バッチを開発。「店舗・EC・倉庫」という複数経路の依頼を、共通の業務フロー・ステータスに統合することが中心的な要件。 **＃チーム情報** PMは別に存在。開発は複数名。自分は開発作業のリーダーとして要件定義〜設計・実装・レビューを担当し、全体の約8割を担当（残りは他メンバーと分担）。 **＃A：将来の拡張を見越したデータモデル設計** - 概要／機能：拠点や、ステータス・連携・通知などの土台データを、必要最小限・重複しない単位に分けて設計。拡張時に作り直さず「足すだけ」で対応できる構造を狙った。 - 課題：Ph1.0（実店舗受付）時点でオンライン受付や倉庫システム連携などの拡張が見込まれ、目先の要件だけで作ると拡張のたびに作り直しになる。 - 打ち手：「店舗」を抽象度の高い【拠点】＋役割フラグに抽象化しておき、Ph2.0のオンライン受付は「オンライン受付拠点フラグ」1つの追加で対応できた（モデルの作り直しなし）。同じ考え方で、履歴系もPh2.0の倉庫システム連携・通知記録を既存のステータス変更履歴に手を入れず連ねられた（Django / PostgreSQL）。 **＃B：CSVとDBの変換を「設定」だけで作れる共通基盤** - 概要／機能：マスタのアップロード・ダウンロードで使う、CSV⇔DBの双方向変換を、コードを書かず「設定」を並べて作れる基盤。 - 課題：都度個別に変換コードを書くと似た処理が増えて保守が膨らむ。後続の倉庫システム連携も控え、都度実装では速度・品質が安定しない見込み。 - 打ち手：変換手順を宣言的な「設定」で記述できる基盤にロジックを集約。倉庫システム連携では対応関係をAIに渡すだけで設定を量産でき、「方式を決める（自分）＋量産（AI）」の分業で開発速度が向上（Python / Polars）。 **＃C：フィクスチャー＋ワンコマンドの開発環境セットアップ** - 概要／機能：コマンド1つで正常系データを投入し、誰でも同じ初期状態を再現できる仕組み。 - 課題：各自の手作業だと初期データ準備に手間がかかり、新規参加者ほど立ち上げに時間を取られる。 - 打ち手：前案件で効果を確認済みの方法を再現・発展させワンコマンド化。立ち上げコストを削減し後続作業を効率化。 **＃D：テストコードによる品質担保（行カバレッジ93%）** - 概要／機能：機能実装ごとにテストを並行作成し、サーバーサイド（Python）の行カバレッジ93%を維持。関数単体ではなく、外部の入り口（画面・API・バッチ）から処理が呼ばれる要件ベースのテスト。 - 課題：ステータス管理と外部連携が絡み改修で挙動を壊しやすい。一方、内部構造に密着した単体テストはリファクタのたびに壊れて保守が重い。 - 打ち手：内部構成ではなく「外部から見た挙動」を検証対象にし、(1)挙動変化の検知、(2)リファクタ耐性を両立。回帰バグを抑えつつ継続的に改修できる状態にした（Python / Django）。 **＃E：CI/CDまわりの改善（全社横断／別チーム起源＋自分の改良）** - AIコードレビュー基盤の横展開：別チームが作った仕組み（PR差分＋ルールをAIに渡しインラインコメント）を横展開しやすい共通基盤へ整備。自分の改良は、globによる複数ルール適用と設定配置の自由化、submodule化による複製抑止で、pipeline設定に約10行で導入可能にした点。 - CIコスト最適化（PoC）：ビルド済みDockerイメージをHub経由で再利用（あればpull・無ければbuild＆push）し2回目以降のビルドをスキップ。総実行時間を約50%削減できる見込み（PoC段階）。

**＃概要** 他社ECサイトから商品情報を取得し、クライアント指定形式（CSV）へ変換して提供するシステム（Python / Django）。対象サイトはフォーマットのルールもバリエーションも事前に不明で、商品タイトル・価格などが不定形。 **＃チーム情報** 開発は自分ひとり（要件定義〜設計・実装・レビュー・テスト）。 **＃A：不定形サイトからのスクレイピング** - 概要／機能：対象ページを巡回し、商品タイトル・価格などを収集。 - 課題：フォーマットが不定形で、HTML構造だけに頼ると取得漏れ・崩れが起きやすい。 - 打ち手：Playwright で取得し、後段の正規化に渡す形に設計（Python / Playwright）。 **＃B：AIによるデータ正規化** - 概要／機能：不定形の商品タイトル・価格などを、指定の項目・形式へそろえる正規化。 - 課題：ルール自体が事前に分からず、従来のルールベース（自社の既存変換システム）では条件を書ききれない。 - 打ち手：既存方式で無理をせず、GPT-4o API に正規化を担わせる設計を選択。既存システムでは解けなかった不定形テキストの正規化を実現。AI活用で自社の枠組みを突破した最初の経験（Python / GPT-4o API）。 **＃C：クライアント指定形式へのCSV変換・提供** - 概要／機能：正規化済みデータを、納品先が扱いやすいCSVへ整えて出力。 - 課題：取得元の都合ではなく、受け取る側が使える形にそろえる必要。 - 打ち手：指定形式へのマッピングと出力を実装し、提供までを一貫して自動化（Python / Django）。

**＃概要** 某ブランドの顧客向けメール配信システム（Python / Django）。CSVで配信先・内容を受け取り、予約日時に配信。担当はバックエンド。 **＃チーム情報** チームメンバーとして、バックエンドの設計・実装・レビュー・テストを担当。 **＃A：HTMXの導入提案と適用** - 概要／機能：CSVアップロード・配信予約・状況確認などの画面にHTMXを適用。 - 課題：画面操作のたびにHTML全体が再読み込みされ、体感速度と開発効率に改善余地。 - 打ち手：技術記事をきっかけにHTMXを知り、導入を打診してチームで採用。documentロードがなくなり速度向上。メンバーから「開発効率が上がった」「楽しかった」の反応（HTMX / Django）。 **＃B：性能改善** - マルチスレッド採用で、バッチ約30%・CSVアップロード画面約50%改善。 - 最適でない `bulk_update` を `update` と `bulk_update` に分割し更新処理を約50%高速化。 - 別案件のN+1対策の仕組みを活用し、ある画面を10倍以上高速化（Python / Django / PostgreSQL）。

**＃概要** ECの商品在庫を管理するシステム（Python / Django）。自社の既存システムをPython/Djangoへリプレースし機能拡張。在庫確認（引当）API、倉庫連絡・出荷指示バッチ、管理画面で構成。 **＃チーム情報** チームメンバーとして、詳細機能設計・実装・レビュー・テストを担当。 **＃A：N+1問題をテストで自動検知する仕組み＋ORM拡張** - 概要／機能：テスト時にN+1を検知して失敗させる仕組みと、根本対策のORM拡張。 - 課題：DjangoのORMは書き方次第でN+1が起きやすく、注意やレビュー頼みだと再発しやすい。 - 打ち手：「人の注意」ではなく仕組みで止める方針。`unittest.mock` で `ForwardManyToOneDescriptor.get_object` を「呼ばれたら例外」に差し替えテストで検知。根本策としてORMを拡張し常に外部キーをJOIN（不要JOINのトレードオフを理解の上、開発者が意識せず済むことを優先）。 **＃B：運用状況を再現するテストツール** - 概要／機能：稼働中の旧システムの運用を、リプレース後で再現するDjangoコマンド。 - 課題：リプレースは実運用と同じ負荷・パターンで検証しないと不具合が出やすく、手作業での再現は困難。 - 打ち手：旧システムのAPIログを解析し、同じ日時・API・内容でリクエストを再送。前システムのリーダーから「ずっと欲しかったが諦めていた」「おかげでリリース前に多くのバグを検知できた」との評価（Python / Django）。

**＃概要** アパレル系ECサイトの開発（10案件程度・約4年10ヶ月／PHP・Laravel）。「ベースサイト」を改造しクライアントごとのECを構築。DBは内包せず別システムをAPI参照、ストレージはRedis。 **＃チーム情報** チーム開発。3年目頃からリードエンジニア的なポジションで中心的役割。要件見積もり、機能設計、実装方針の決定、実装、レビュー、テスト設計・実施を担当。 **＃A：サイトの多態化（ソースコード複製の防止）** - 概要／機能：1リポジトリを複数ドメインにデプロイし機能を出し分け、4サイトの約9割を同一ソースで構築。 - 課題：「サイトごとにリポジトリを分ける」案があり、そのままだとコピペが増え保守性が低下。 - 打ち手：メインに全機能を実装し、各サイトは「使う／使わない」を選ぶだけの構造を考案・主導（PHP / Laravel）。 **＃B：GTM／GAのデータ収集実装（3名チームのリード）** - ※自分単独ではなく、自分がリーダーを務めた3名チームでの実施。 - 概要／課題：構成が複雑な4サイトの計測タグ実装。複雑だと実装漏れ・計測ミスが起きやすい。 - 成果：提携他社のテストで「こんなにバグの少なかったことは初めてです！」との評価。

**＃概要** カーナビの地図データ更新機能を開発するチームに常駐派遣で参加（約6年10ヶ月／C言語）。 **＃チーム情報** チーム開発。チームメンバーとして基本設計・詳細設計・実装・テストを担当。 **＃A：RSA暗号化まわりの環境依存不具合の解決** - 概要／機能：地図データ複製防止の暗号化（既存RSAモジュール利用）に関する不具合対応。 - 課題：実機でのみ復号に失敗し、ローカルで再現せず調査が難航。 - 打ち手：環境差の観点で切り分け、RSAが使う別モジュールに環境依存（演算子の優先順位が環境依存）を特定。式を `()` で囲み優先順位を固定して解決（C言語）。

ドコモ系回線向け通信交換機の機能追加と改修を目的とした業務システムの受託開発に携わりました。 バックエンドエンジニアとして、通信交換機の機能追加に関する詳細設計、C言語によるコーディング、及び単体テストを担当しました。

派遣としてソフトウェアテスト業務を中心に担当し、テスト設計・実施や随時の実装対応に従事。最終年には北海道NECでJavaサーブレットとTomcatによるWebアプリケーション開発に設計・実装から携わり、業務システム開発の設計・実装経験を得た。