ID:71294さん

# プロジェクト概要 国内外の顧客、販売代理店、営業担当者が利用する自動車部品検索サイトを、PHPの独自MVCフレームワーク＋Smartyを中心とした既存構成から、WordPress、Laravel、Next.js、TypeScriptを用いた構成へ刷新しました。国内・海外、四輪・二輪向けの複数サイトがあり、既存の検索仕様とURLを維持しながら、新旧システムを段階的に切り替える必要がありました。 私はPL兼検索・アプリケーション領域の担当として、既存仕様の調査、検索APIと業務ロジックの設計・実装、WordPressとの連携、認証共通化、自動テスト、Docker環境構築、Apache設定を含むリリース、障害対応まで担当しました。 # 期間 2025年9月〜2026年6月 主要リリース後も保守・追加対応を継続 # チーム情報 - PM：1名 - PMO：1名 - PL：1名（私） - エンジニア：1名 - WordPress担当：1名 - 外部協力会社：3名 - 全体：8名 外部協力会社には管理画面の実装を分担してもらい、私は共通開発環境、検索・アプリケーション領域、システム間連携を担当しました。 # システム構成 - WordPress：コンテンツ、ヘッダ・フッタ、静的ページの管理 - Laravel：公開検索API、業務ロジック、管理画面、認証基盤 - Next.js／React／TypeScript：公開検索UI - MySQL：製品・適合・互換情報などの業務データ - Docker Compose：ローカル開発環境 - Apache：新旧システムの振り分けと段階移行 Next.jsからDBへ直接アクセスせず、Laravelの公開APIを経由する構成にしました。管理画面はLaravel＋Bladeに寄せ、公開検索UIと管理機能の責務を分離しています。 # 開発・実装内容1 ## 既存検索仕様の調査とLaravel検索APIの実装 ### 課題 既存システムには十分な設計資料がなく、検索条件、製品の表示・除外条件、セット品・互換品の判定がソースコードとSQLへ埋め込まれていました。 また、既存DBには次のような制約がありました。 - 主キーや一意キーが定義されていない業務テーブルがある - 製品種別ごとの品番が複数カラムに横持ちされている - 年式が複数の文字列表記で保持されている - 旧品番と新品番の互換情報がチェーン・分岐する - 同一品番の複数行から、客先区分等に応じて正しい行を選ぶ必要がある ### 自身が行ったこと 既存画面、ソースコード、Smartyテンプレート、SQL、DBデータを照合し、検索条件ごとの処理をフローチャートと基本設計書へ整理しました。Laravelではコントローラを入力検証とサービス呼び出しに限定し、検索ロジックをサービスクラスへ分離しました。規約外の既存テーブルはEloquentではなくQuery Builderで扱い、自分で新規設計した認証系テーブルのみEloquentを使用しました。 検索処理では以下を実装しました。 - 全角半角、記号、大小文字を正規化した品番検索 - 互換品番を世代単位で取得する幅優先探索 - 訪問済み品番と最大世代数による循環・過剰探索の防止 - 製品情報を品番集合で一括取得し、PHP側で突き合わせるN+1対策 - 上限＋1件を取得して検索件数超過を判定する方式 - 曖昧な短文字検索の早期終了 - タイムアウト、検索上限、打ち切り理由の構造化ログ ### 成果 既存コードに埋もれていた検索仕様を可視化し、国内・海外、四輪・二輪の検索機能をLaravel／Next.js構成へ移行しました。 検索結果の整合性を維持しつつ、想定外に広い検索や互換品の分岐があっても、画面が長時間停止せず原因をログから追跡できる構成にしました。 # 開発・実装内容2 ## 検索結果の妥当性を担保する自動テスト ### 課題 検索条件の組み合わせが多く、不具合修正のたびに全パターンを人手で確認するのは困難でした。また、修正によって別の検索条件を壊すリスクがありました。 ### 自身が行ったこと 不具合報告を受けた際は、最初に不具合を再現するテストを追加し、修正後の確認と既存挙動の回帰確認まで残す進め方にしました。PHPUnitとVitestによるテストに加え、次のような不変条件をプロパティベーステストで検証しました。 - 前方一致の結果が入力キーワードで始まること - 互換品として展開した品番が不要な前方一致で混入しないこと - 検索結果の並び順が指定条件を満たすこと また、シード品番収集、互換解決、絞り込み、結果構築の各段階の件数を返す検証用APIを作成し、どの処理で対象が除外されたかを確認できるようにしました。 ### 成果 不具合を再現テストとして残し、修正の影響範囲を継続的に確認できる状態を構築しました。 「期待する品番が表示されない」といった指摘についても、検索処理のどの段階で対象が除外されたかを短時間で切り分けられるようになりました。 # 開発・実装内容3 ## WordPress・Laravel・Next.jsの連携と段階移行 ### 課題 WordPress、Laravel、Next.jsで責務が分かれており、ヘッダ・フッタや管理画面の認証を二重実装せず、一つのサイトとして利用できる構成が必要でした。また、本番稼働中の既存システムを停止せず、同一Apache上で新システムへ段階的に切り替える必要がありました。 ### 自身が行ったこと WordPressのメニューや共通コンテンツをREST APIで配信し、Next.js側で描画する構成にしました。Laravel側にはキャッシュと排他制御を設け、WordPressへの取得に失敗した場合も古い内容を返すフォールバックを実装しました。管理画面ではLaravelを認証元とし、短時間・1回限りの認可コードをサーバー間通信で交換するSSOを実装しました。コードの有効期限、使用済み判定、遷移先検証、レート制限、連鎖ログアウト、構造化ログを設けています。Apache設定は、既存システムを公開したまま新システムをサブパスで検証する段階と、新システムを公開ルートへ切り替える段階に分けました。既存URLはAliasとルーティング補正によって維持しました。 ### 成果 WordPress、Laravel、Next.jsを独立して運用しながら、利用者からは一つのサイトとして操作できる構成を実現しました。 本番稼働中の既存カタログ・受発注システムを停止せず、国内四輪、海外四輪、海外二輪を段階的に新システムへ移行しました。

# プロジェクト概要 登録ユーザー約4,000名の釣具部品修理システムにおいて、基幹システムから連携されるマスタCSVの取込処理をはじめとした保守・性能改善を担当しました。主な実績として、3時間以上経過しても完了しなかった製品構成マスタ取込バッチを、集合処理とバルクDMLを中心とした実装へ全面的に書き換えました。 # 期間 2025年7月〜2025年9月 # チーム情報 - 開発担当：1名（私） - 同一リポジトリを担当する別メンバー：1名 別メンバーによる暫定的な性能対策の後、私は対象バッチの全面書き換え、ログ整備、動作確認、本番反映を担当しました。 # データ規模 - ログインユーザー：約4,100件 - 製品マスタ：約14万件 - 部品マスタ：約16万件 - 製品構成マスタ：約61万件 - 修理受付：約133万件 - 修理報告部品明細：約393万件 # 開発・実装内容1 ## 製品構成マスタ取込バッチの全面書き換え ### 課題 既存バッチはCSVを2回読み込み、各行について製品ID・部品IDを取得するSELECTと、DELETE・INSERTを個別に発行していました。検索に利用する製品コード・部品コードや、削除条件となる製品IDには索引がなく、CSV1行ごとに大規模テーブルの全走査が発生していました。本番稼働中の中核マスタであり、DDL変更の承認が得られなかったため、索引を追加せずに改善する必要がありました。既存処理を実測したところ、3時間以上経過しても完了せず打ち切りました。 ### 自身が行ったこと スキーマを変更せず、SQLの発行方法を行単位から集合単位へ変更しました。 - CSVを1回だけ読み、製品コードと部品コードを集合化 - 800件単位のIN句でコードとIDの対応を一括取得 - 削除対象の製品IDを800件単位のDELETEへ集約 - 800行単位のマルチVALUES INSERTへ変更 - プレースホルダとバインド値を使用 - DELETEからINSERTまでを単一トランザクション化 - 例外時はロールバックし、原因をログへ出力 800件という単位は、1行8列で約6,400プレースホルダとなり、SQL文長とプレースホルダ数を抑えながらDBとの往復を削減できる値として設定しました。最大負荷日のデータ量を基準に、SQL発行数を4万本以上から約40本へ削減しました。 ### 成果 本番ログ358回、約11ヶ月分を集計した結果、以下の実績を確認しました。 - 平均処理時間：1.10秒 - 中央値：1.0秒 - 最長：2.68秒 - 最大取込件数：14,675件 - 異常終了：0件 本番DBの索引を追加せず、3時間以上経過しても完了しなかった処理を、最大負荷時でも3秒以内で完了する状態へ改善しました。 # 開発・実装内容2 ## バッチ結果とマスタ不整合の可視化 ### 課題 既存処理は標準出力への表示のみで、夜間バッチが正常終了したか、何件取り込めなかったかを後から確認できませんでした。 また、基幹側の製品構成CSVに存在するコードが、商品マスタに存在しない場合も、詳細を追跡できませんでした。 ### 自身が行ったこと 正常終了、異常終了、CSV未着の各経路で、以下をログへ出力するようにしました。 - 開始・終了時刻 - 経過秒 - 削除・挿入・スキップ件数 - 引き当てに失敗した製品コード・部品コード - CSV未着、空ファイル、ファイルオープン失敗 - 例外の原因 本番反映前に手動実行で取込結果を確認し、正常動作を確認した翌日から夜間cronへ移行しました。 ### 成果 約11ヶ月の運用で、53回・累計3,009行のマスタ不整合をログから特定できました。 CSV未着時もログを確認して翌朝に手動実行できるようになり、夜間バッチの成否とリカバリ状況を追跡可能な状態にしました。 # 開発・実装内容3 ## 大規模データを扱う保守・性能改善 製品構成バッチ以外にも、次の対応を行いました。 - 約3万件の旧・新部品コード対照データを用い、約150万件規模の更新を3本のSQLとして生成 - 大規模テーブルを結合してサーバー停止の原因となっていた画面SQLから、不要な結合と取得列を削除 - 海外版カタログ向けに、製品構成を事前結合したテーブルからXMLを生成する連携処理を実装 性能問題が発生した際は、SQLの本数、取得列、結合、処理場所を整理し、PHPで実行する範囲とDB側で処理する範囲を判断して対応しました。

# プロジェクト概要 自動車部品購入システムに、外部会社が提供する積載計算APIを連携しました。既存システム内で行っていたコンテナ積載予測に代わり、部品の寸法・重量・数量等を外部APIへ送信し、パレット数、充填率、必要コンテナ数、3D表示を業務画面から確認できる機能を実装しました。 私はPM兼開発担当として、要件整理、API提供会社との仕様調整、送信データ設計、DB設計、API通信、画面・履歴機能、性能問題の切り分けと改善を担当しました。 # 期間 2023年12月〜2024年7月 # チーム情報 - 自社PM兼開発：1名（私） - 自社開発メンバー - API提供会社 - クライアント業務部門 - クライアント情報システム部門 # 開発・実装内容1 ## 複数データソースからのAPI送信データ生成 ### 課題 APIは貨物、パレット、コンテナという単位の入力を必要としていましたが、既存システムが保持しているのは注文明細でした。積載計算に必要なデータは、注文DB、商品マスタ、外装箱マスタ、国別コンテナ重量CSVなど複数のデータソースへ分散していました。また、重量・寸法が未登録または不正な品番も存在しました。 ### 自身が行ったこと API仕様と既存DB・CSVの各項目を照合し、API入力値との対応を整理しました。 - 発注明細を発注IDの集合で一括取得 - 商品マスタを品番の集合で一括取得 - 注文数量を入数で割り、外装箱個数へ換算 - 単体重量、化粧箱重量、外装箱重量から外装箱重量を計算 - 国別CSVからコンテナの最大積載重量を取得 - 不足・不正データを品番単位で判定 - 除外・寸法不足・重量不足・正常の4種類に分類 - 除外または精度低下の可能性がある品番を画面へ表示 マスタ不備のある品番だけを除外し、残りの品番は計算を続行できる構成にしました。 ### 成果 注文DB、商品マスタ、基幹連携CSVを組み合わせ、既存業務データを外部APIの入力形式へ変換できるようにしました。入力不備の原因を利用者が画面から確認できるようになり、計算結果の問題を自社データと外部APIのどちらに起因するか切り分けやすくしました。 # 開発・実装内容2 ## 3D表示と計算履歴 外部APIから返されたパレット数、容積・重量充填率、PO・BO内訳をAjaxで取得し、画面上へ表示しました。3D表示のURLには有効期限があるため、URLそのものではなくAPIの計算ジョブIDをDBへ保存しました。履歴参照時にAPIから新しいURLを取得することで、過去の計算結果からも3D表示を再確認できるようにしました。履歴には実行ユーザー、注文番号、パレット数、コンテナ種別、充填率、3D参照ID等を保存し、保持期限・件数上限とKeep保護を設けました。 # 開発・実装内容3 ## API障害の切り分けと応答時間改善 ### 課題 総合テスト中、特定の注文で「APIがエラーを返す」と報告されました。失敗した送信JSONをAPI提供会社で再実行した結果、APIは正常に計算しており、90秒かかっていることが判明しました。自社側は通信を50秒、画面側を20秒で打ち切っていたため、長時間計算が失敗として扱われていました。また、計算時間は品番数ではなく、外装箱の種類・数量・コンテナ数の組み合わせによって大きく増加していました。 ### 自身が行ったこと 送信JSON、応答、実行時間を揃えてAPI提供会社へ共有し、原因と責任範囲を切り分けました。 API提供会社による計算エンジン改善で90秒から26秒になった後、私は業務部門と次の方針を合意して実装しました。 - BOが40パレット以上の場合は、APIへBOを送らずPOのみで計算 - 40パレットは、通常は単独出荷されるという物流上の運用を根拠に設定 - BOを除外した場合は画面へ注記を表示 - BOの詳細を既存の検索画面で確認できる導線を用意 - 画面側のタイムアウトを見直し - 品番単位のDB取得を集合取得へ変更 BOの事前パレット数算出には、以前私が実装した既存の積載計算ロジックを再利用しました。 ### 成果 同一データの計算時間を、API提供会社側の改善で90秒から26秒、自社側のBO制御によって26秒から13秒へ短縮しました。 私は90秒から26秒の計算エンジン改善そのものではなく、原因の切り分け、API会社との分担、自社側の26秒から13秒への改善を担当しました。外部API、ネットワーク、アプリケーション、マスタデータの問題を分離し、複数組織で対応すべき課題を解決まで進めた経験でした。