実務で向き合ってきたのは、派手な新規開発より、複雑な業務を壊れにくい形へ整える仕事です。
ここでは、そのときの判断と工夫をケーススタディとして紹介します。
受託開発で手がけた主要プロジェクト
認可方式を変更した後の表示遅延を調査し、セッションのロックを原因として切り分けた。保存先をDBへ変更し、表示速度が戻ることを確認した。
別の性能改善では、検索・並び順・ページ送りへの影響を比較。既存の仕組みを残し、業務上必要な取得範囲について顧客と合意した。
差分配布の仕組み、許可外のpushを止めるGit hookとそのテスト、開発環境のセットアップを整備。ルールを手順と道具に落とし込んだ。
不具合を再現するテストを追加し、段階公開には機能フラグを利用。安定稼働した機能のフラグは外し、不要になった分岐も整理した。
福祉・介護 ｜ マルチテナント構成
既存の通信基盤に別の外部APIを追加する必要があった。共通化できるデータと、業務の流れが異なるデータをどう扱うかが課題だった。現場でのスマホ利用に対応する画面も整えた。
Adapterを介してAPIを切り替える構成を実装。マスタ系は項目を揃え、訪問記録・対応記録は業務フローが異なるため、API固有の項目を残す構成へ見直した。
法人・取得対象ごとに外部APIを切り替えられる構成を実装した。共通入口を用意しつつ、記録系の業務差は呼び出し側でも扱う。連携追加の影響を、境界ごとに確認できる形にした。
2021年に通信処理とエラー処理の共通基盤を整備。2025〜2026年の同期処理・API切替の実装でも、この基盤を利用した。
連携処理の設計・実装、同期処理、Adapter層とテストの整備を担当。顧客との要件整理にも携わった。API切替の実装には生成AIも利用している。
APIの入口を共通化することと、すべてのデータを同じ形にすることは分けて考えた。マスタは共通の項目へ変換し、記録は各APIの項目を保つ。AdapterとService層にテストを追加し、変更を確認する足場を整えた。
項目名が似ていても、業務の流れまで同じとは限らない。共通化を目的にせず、差異を残すほうが保守しやすい部分を見極めることが大切だと学んだ。
この案件で示せる強み
運用の仕組み化 ｜ Webとサーバの接続
2021〜2024年の構築・保守 ｜ API・画面・通知スクリプトを担当
サーバから個別に届くバックアップ結果を、メール通知からWebAPIで集める方式へ変更。通知の受信APIと確認画面、PowerShellの送信モジュール、バックアップ製品との連携を設計・実装した。
人が使う画面と、スクリプトが呼ぶAPIで認証を分離。開始・終了を組にした通知と単発の通知を扱い、成功・失敗・警告・未検知を画面で確認できるようにした。
実機で試すと、ログが日時順に並ぶという前提が誤っていた。直近の実行結果を抽出する処理へ修正し、机上の想定を運用環境で確かめた。
受信データの検証テストも整備。後年にはサーバ間で通知設定に差が生じたため、スクリプトを比較し、共通のものとして整理した。
画面だけでなく、通知を送る側と保守の手順まで揃えて、一つの仕組みとして作る経験になった。
CakePHP 4 / PostgreSQL / Docker / PowerShell / PHPUnit
小売・EC ｜ 単独で設計〜リリース
本体コードを直接改修すると、EC-CUBEのバージョンアップ時にすべての変更箇所を検証し直す必要がある。カスタマイズが増えるほど追従コストが膨らむ構造だった。
Open/Closed原則を徹底し、すべてのカスタマイズをプラグインとして実装する方針を選択。本体コードに手を入れないことで、バージョンアップ追従とカスタマイズの独立性を両立させた。
20本以上のプラグインを単独でリリースし、本体への直接改修を避け、独自機能をプラグインとして分離。プラグイン単位での展開が可能になったため、複数クライアントに適用する独自機能を、プラグイン単位で導入・更新できる形にした。
EC-CUBE4をベースとしたECサイト構築で、標準機能では対応できないカスタマイズが多数必要だった。
要件整理、設計、実装、リリースまでを一貫して単独で担当した。
Symfonyのイベントディスパッチャーを活用したフック設計。リダイレクト型3Dセキュアに対応した決済プラグイン、TCPDFによる注文書PDF生成・メール添付機能、カート追加アニメーション（Ajax非同期処理）、店舗休業日を考慮した配送日時制御ロジックなど、幅広い要件に対応。プラグイン間の依存関係を最小化する設計を心がけた。
制約の強い環境ほど、拡張ポイントを見極める設計力が問われると実感した。「本体に触らない」という制約が、結果として壊れにくい設計を生む。
この案件で示せる強み
医療 ｜ 新規開発・長期保守
入出庫の履歴が追いにくく、発注に必要なデータの抽出も手作業が多い状態。伝票操作UIにコード重複が多く保守コストが高い状態だった。また、在庫計算ロジックにエッジケースで不正な結果を返す不具合が潜んでいた。
在庫計算の不具合は、既存コードを丹念に読み解いて原因を特定するアプローチを取った。安易にロジックを書き直すのではなく、既存の設計意図を理解した上でピンポイントに修正することで、影響範囲を最小限に抑えた。
伝票操作UIリファクタリングで重複していた処理を共通化。発注業務はCSV→Excel手加工の流れが、Excelファイルの直接ダウンロードのみで完結するように。需要計算に基づく発注伝票自動生成機能を実装し、在庫計算の不具合修正でシステムの信頼性も確保した。
医療機関で消耗品・医療材料を管理する在庫管理システムの新規開発および長期保守を担当。入出庫管理や発注業務を支援する機能の拡充が求められていた。
既存仕様の読解、不具合原因の切り分け、機能追加時の影響確認、保守改善を担当した。
入出庫の履歴を一覧・検索できる画面を新規構築。発注用データの出力機能を実装し、手作業での転記を不要に。PHPExcel → PhpSpreadsheetへの移行を実施。bakeコマンドのカスタマイズによるコード自動生成効率化も行った。
保守では、全面的な作り直しよりも、意図を理解した上での最小変更が価値になる場面が多い。「なぜこう書かれているか」を理解してから手を入れることが、保守の品質を左右する。
この案件で示せる強み
建設 ｜ 初期構築・UI刷新
日報の入力に時間がかかり、現場からの不満が多かった。また、週報・月報は手作業で集計しており、管理コストが高い状態だった。
4年前の自分の設計を見直す機会となった。当時の設計判断の良い点を活かしつつ、入力UIは全面的に刷新する方針を取った。
日報入力UIを全面刷新。日報の入力値を週報の初期値へ自動反映するなど入力動線を再設計し、入力の手間を大幅に削減した。
建設業の現場で使われる作業日報の管理システム。入社直後に初期構築を担当し、4年後にUI刷新・機能追加で再び携わった。
2019年の初期構築から設計・実装を担当。2023年のUI刷新でも同じシステムのリファクタリングと機能追加を主導した。
自分が作ったシステムを4年後に自らリファクタした経験。当時の設計判断の良い点と悪い点の両方が見え、「未来の自分が保守する前提の設計」の重要性を実感した。
この案件で示せる強み
環境保全 ｜ 短期集中開発
年間予定の管理が手作業で行われており、点検履歴の追跡も困難な状態だった。顧客の要望が曖昧で、要件の精緻化が必要だった。
曖昧な要望をチケットベースで精緻化するプロセスを導入。月100h超×4ヶ月の集中稼働で、短期間に大量の要件を整理し形にするアプローチを取った。
年間予定自動生成ロジックを設計・実装し、手作業での予定管理を解消。点検履歴管理機能の実装により、過去データの追跡が容易に。顧客打合せの宿題を都度チケット化して要件を構造化し、曖昧な要望を仕様に落とし込んだ。
環境保全領域の管理システム。入社直後に既存システムの改修・機能追加を担当し、3年後に大規模な機能追加プロジェクトで設計・実装リードを務めた。
設計・実装リードとして、顧客打合せの宿題をチケット化し要件を精緻化するプロセスを確立した。
短期集中で大量の要件を整理し形にした経験。顧客の曖昧な要望を、チケットベースで精緻化するプロセスを確立した。
この案件で示せる強み
物流 ｜ 新規開発・基盤設計
既存の業務フローが属人的で、システム化の要件が明確でなかった。ゼロベースでの新規開発のため、基盤設計の判断が求められた。
既存改修が中心だったキャリアの中で、ゼロベースの設計判断が求められる案件。技術選定から基盤設計まで、将来の拡張性を見据えた設計方針を策定した。
業務フローを整理し要件を定義。新規システムの基盤設計を担当し、8ヶ月・累計547hでシステムの基本設計・詳細設計を完遂した。
軽貨物運送業向けの業務支援システムを新規開発。業務フローの整理からシステム化の要件定義、基盤設計までを担当した。
基本設計・詳細設計を担当。育休直前まで月100h超で稼働した直近の主力案件。
ゼロからの新規開発で設計に関わった経験。ゼロベースの設計判断を求められる場面が多く、技術選定の引き出しが広がった。
この案件で示せる強み
実装を伴わない設計フェーズの成果
自社プロダクト ｜ 設計専任
設計専任として、UMLによるシステム構造の可視化、ER図によるデータベース設計、見積提示・画面遷移設計を主導した。
UMLクラス図を20枚以上作成し、システム全体の構造を設計。組織管理・タスク管理・シフト管理機能の詳細設計、ER図によるデータベース設計、見積提示・画面遷移設計を主導した。
自社パッケージソフトウェアのフルリプレイスにおいて、設計フェーズを2年間にわたって担当。既存システムの構造を分析し、新アーキテクチャの設計を主導した。
draw.ioを用いたUMLクラス図の作成、組織管理・タスク管理・シフト管理機能の詳細設計、ER図によるデータモデリングなど、設計ドキュメントを中心としたアウトプット。
実装なしの設計フェーズのみでも成果を出せる能力を証明した。2年間にわたって設計の精度を追求し、「コードを書かない成果物」で価値を生む経験を積んだ。
この案件で示せる強み
設計判断の詳細は Lab の記事でも紹介しています。