実務で向き合ってきたのは、派手な新規開発より、複雑な業務を壊れにくい形へ整える仕事です。
ここでは、そのときの判断と工夫をケーススタディとして紹介します。
実務で向き合ってきた課題を、成果ベースで抜き出しました。詳細は各ケーススタディで紹介しています。
福祉API連携
個別実装が3社分並存していたAPI連携を、4社目追加を機にAdapterパターンで統一基盤へ再設計。以後の追加はAdapterクラス1本で完結。
EC-CUBEプラグイン開発
20本以上を単独で設計〜リリース。3年間で本体バージョンアップ時の影響0件。
医療機関向け在庫管理
既存仕様を読み解き、最小変更で不具合修正。伝票操作UIのコード重複を80%削減。
建設業向け作業日報
4年前に自分が作ったシステムを再設計・UI刷新。入力動線の見直しで日報入力の手間を大幅削減。
自社パッケージリプレイス設計
設計専任としてUMLクラス図20枚以上を作成。実装を伴わない設計成果物で価値を提供。
受託開発で手がけた主要プロジェクト
福祉・介護 ｜ マルチテナント構成
福祉・介護領域の外部API連携で、個別実装が3社分並存していた。各APIはデータ形式もエラーハンドリングも異なり、連携先が増えるたびに保守コストが膨らむ構造だった。
外部APIの差異を吸収する設計方針の整理から、実装方針の決定、Adapter層の設計まで担当。顧客ヒアリングは20回以上、Redmineチケットの作成数はプロジェクト最多。
個別実装のままではAPI追加のたびにビジネスロジック層へ影響が出る構造。テスト範囲も毎回拡大し、リグレッションリスクが高い状態だった。また、現場スマホ利用率60%に対応するレスポンシブ設計も求められた。
4社目の連携追加を機に、個別実装の継ぎ足しをやめて統一基盤への再設計を決断。API差異の吸収にはAdapterパターンを選択した。Facadeパターンも検討したが、各APIの仕様差が大きく、個別のAdapter内で変換処理を完結させる方が保守性に優れると判断した。
各APIを個別のAdapterクラスでラップし、統一インターフェースを定義。ビジネスロジック層がAPIの違いを意識しない構造を実現。エラーハンドリングもAdapter層で正規化。空き時間検索アルゴリズムを独自実装し、Docker開発環境を構築・標準化して新メンバーのセットアップ時間を大幅短縮した。
以後の連携追加がAdapterクラス1本の追加で完結し、ビジネスロジック側の修正が不要な構造を実現。GoogleMap連携、外部API連携、添付ファイル用ストレージ移行なども担当。
抽象化は多ければよいわけではなく、差異が出る場所を正しく見極めることが重要。設計パターンは「知っている」と「実務で効かせる」の間に大きなギャップがある。
この案件で示せる強み
小売・EC ｜ 単独で設計〜リリース
EC-CUBE4をベースとしたECサイト構築で、標準機能では対応できないカスタマイズが多数必要だった。
要件整理、設計、実装、リリースまでを一貫して単独で担当した。
本体コードを直接改修すると、EC-CUBEのバージョンアップ時にすべての変更箇所を検証し直す必要がある。カスタマイズが増えるほど追従コストが膨らむ構造だった。
Open/Closed原則を徹底し、すべてのカスタマイズをプラグインとして実装する方針を選択。本体コードに手を入れないことで、バージョンアップ追従とカスタマイズの独立性を両立させた。
Symfonyのイベントディスパッチャーを活用したフック設計。PCI DSS対応の3Dセキュア認証（JWS/JWT）決済プラグイン、TCPDFによる注文書PDF生成・メール添付機能、カート追加アニメーション（Ajax非同期処理）、店舗休業日を考慮した配送日時制御ロジックなど、幅広い要件に対応。プラグイン間の依存関係を最小化する設計を心がけた。
20本以上のプラグインを単独でリリースし、3年間で本体バージョンアップ時に影響を受けたプラグインは0件。プラグイン単位での展開が可能になったため、複数クライアントへの機能適用がプラグイン導入のみで完結し、展開スピードが大幅に向上した。
制約の強い環境ほど、拡張ポイントを見極める設計力が問われると実感した。「本体に触らない」という制約が、結果として壊れにくい設計を生む。
この案件で示せる強み
医療 ｜ 新規開発・長期保守
医療機関で消耗品・医療材料を管理する在庫管理システムの新規開発および長期保守を担当。入出庫管理や発注業務を支援する機能の拡充が求められていた。
既存仕様の読解、不具合原因の切り分け、機能追加時の影響確認、保守改善を担当した。
入出庫の履歴が追いにくく、発注に必要なデータの抽出も手作業が多い状態。伝票操作UIにコード重複が多く保守コストが高い状態だった。また、在庫計算ロジックにエッジケースで不正な結果を返す不具合が潜んでいた。
在庫計算の不具合は、既存コードを丹念に読み解いて原因を特定するアプローチを取った。安易にロジックを書き直すのではなく、既存の設計意図を理解した上でピンポイントに修正することで、影響範囲を最小限に抑えた。
入出庫の履歴を一覧・検索できる画面を新規構築。発注用データの出力機能を実装し、手作業での転記を不要に。PHPExcel → PhpSpreadsheetへの移行を実施。bakeコマンドのカスタマイズによるコード自動生成効率化も行った。
伝票操作UIリファクタリングでコード重複80%削減。発注業務はCSV→Excel手加工の流れが、Excelファイルの直接ダウンロードのみで完結するように。需要計算に基づく発注伝票自動生成機能を実装し、在庫計算の不具合修正でシステムの信頼性も確保した。
保守では、全面的な作り直しよりも、意図を理解した上での最小変更が価値になる場面が多い。「なぜこう書かれているか」を理解してから手を入れることが、保守の品質を左右する。
この案件で示せる強み
建設 ｜ 初期構築・UI刷新
建設業の現場で使われる作業日報の管理システム。入社直後に初期構築を担当し、4年後にUI刷新・機能追加で再び携わった。
2019年の初期構築から設計・実装を担当。2023年のUI刷新でも同じシステムのリファクタリングと機能追加を主導した。
日報の入力に時間がかかり、現場からの不満が多かった。また、週報・月報は手作業で集計しており、管理コストが高い状態だった。
4年前の自分の設計を見直す機会となった。当時の設計判断の良い点を活かしつつ、入力UIは全面的に刷新する方針を取った。
日報入力UIを全面刷新。日報の入力値を週報の初期値へ自動反映するなど入力動線を再設計し、入力の手間を大幅に削減した。
自分が作ったシステムを4年後に自らリファクタした経験。当時の設計判断の良い点と悪い点の両方が見え、「未来の自分が保守する前提の設計」の重要性を実感した。
この案件で示せる強み
環境保全 ｜ 短期集中開発
環境保全領域の管理システム。入社直後に既存システムの改修・機能追加を担当し、3年後に大規模な機能追加プロジェクトで設計・実装リードを務めた。
設計・実装リードとして、顧客打合せの宿題をチケット化し要件を精緻化するプロセスを確立した。
年間予定の管理が手作業で行われており、点検履歴の追跡も困難な状態だった。顧客の要望が曖昧で、要件の精緻化が必要だった。
曖昧な要望をチケットベースで精緻化するプロセスを導入。月100h超×4ヶ月の集中稼働で、短期間に大量の要件を整理し形にするアプローチを取った。
年間予定自動生成ロジックを設計・実装し、手作業での予定管理を解消。点検履歴管理機能の実装により、過去データの追跡が容易に。顧客打合せの宿題を都度チケット化して要件を構造化し、曖昧な要望を仕様に落とし込んだ。
短期集中で大量の要件を整理し形にした経験。顧客の曖昧な要望を、チケットベースで精緻化するプロセスを確立した。
この案件で示せる強み
物流 ｜ 新規開発・基盤設計
軽貨物運送業向けの業務支援システムを新規開発。業務フローの整理からシステム化の要件定義、基盤設計までを担当した。
基本設計・詳細設計を担当。育休直前まで月100h超で稼働した直近の主力案件。
既存の業務フローが属人的で、システム化の要件が明確でなかった。ゼロベースでの新規開発のため、基盤設計の判断が求められた。
既存改修が中心だったキャリアの中で、ゼロベースの設計判断が求められる案件。技術選定から基盤設計まで、将来の拡張性を見据えた設計方針を策定した。
業務フローを整理し要件を定義。新規システムの基盤設計を担当し、8ヶ月・累計547hでシステムの基本設計・詳細設計を完遂した。
ゼロからの新規開発で設計に関わった経験。ゼロベースの設計判断を求められる場面が多く、技術選定の引き出しが広がった。
この案件で示せる強み
実装を伴わない設計フェーズの成果
自社プロダクト ｜ 設計専任
自社パッケージソフトウェアのフルリプレイスにおいて、設計フェーズを2年間にわたって担当。既存システムの構造を分析し、新アーキテクチャの設計を主導した。
設計専任として、UMLによるシステム構造の可視化、ER図によるデータベース設計、見積提示・画面遷移設計を主導した。
draw.ioを用いたUMLクラス図の作成、組織管理・タスク管理・シフト管理機能の詳細設計、ER図によるデータモデリングなど、設計ドキュメントを中心としたアウトプット。
UMLクラス図を20枚以上作成し、システム全体の構造を設計。組織管理・タスク管理・シフト管理機能の詳細設計、ER図によるデータベース設計、見積提示・画面遷移設計を主導した。
実装なしの設計フェーズのみでも成果を出せる能力を証明した。2年間にわたって設計の精度を追求し、「コードを書かない成果物」で価値を生む経験を積んだ。
この案件で示せる強み
業務外で取り組んだ自主開発
個人開発 ｜ AI × データ設計
4人の子育て中の家計管理。データはあるが「全体像が見えない」「意思決定に使えない」状態だった。
家計簿アプリでは「月次の収支」は見えるが、資産全体のバランスシートやキャッシュフロー、将来のライフプランシミュレーションまでは可視化できなかった。
自前でダッシュボードを作るのではなく、AIに「正しい問い」を投げることで可視化を実現するアプローチを選択。データの前処理と構造化をエンジニアが担い、チャート生成はClaude（AI）に委ねた。
B/S（貸借対照表）・CF（キャッシュフロー）・ライフプランなど19種類のチャートを体系的に設計。エンジニアのデータ設計力 × AIの可視化力で、家計の多角的な「見える化」を実現。
支出構造の偏りを発見し、固定費を10%前後削減。月次の家計見直しが10分程度で完結するようになり、19種類のチャートが家族との対話のベースになるデータに。この取り組みはLab記事としても公開中。
AIは「問いの質」で出力が変わる。エンジニアとしてのデータ設計力が、AI活用の精度を左右すると実感した。
この案件で示せる強み
設計判断の詳細は Lab の記事でも紹介しています。