About Me

微生物学からソフトウェアエンジニアへ。 好奇心と必要に導かれた歩み。

これまでの歩み

大学

微生物学を専攻。 科学的方法論と分析的思考の土台を築いた。

飼料業界 (7 年)

営業 (2 年) と 購買 (5 年) を経験。 社内外の関係者と密に連携・交渉・コミュニケーションを取りながら、 ビジネス側のスキルを培った。

このころ、 趣味でプログラミングを楽しむようになる 💻

転機

子の誕生をきっかけに、 一念発起して ソフトウェアエンジニアへキャリアチェンジ。

プロジェクトマネージャ (1.5 年)

スマートフォンアプリ開発プロジェクトを率いる。 技術要件と業務要件の橋渡し、 部門横断のチーム調整を担当。

Web エンジニア (3 年)

Laravel で Web アプリケーションを開発。 PHP / MVC アーキテクチャ / モダン Web 開発の実践を深く経験。

Salesforce エンジニア (2 年 〜 現在)

Apex 開発に注力。 業務改善と機能開発に取り組みながら、 コードと アーキテクチャ の両面から問題を解くスタイルを大切にしている。

特に テスト容易性、 保守性、 そして 責務の明確な分離 を重視しています。

AI が当たり前になる時代だからこそ、 ビジネス経験のなかで培ったヒューマンスキルは、 技術力と並んで欠かせないものになると考えています。

ApexEloquent 誕生のストーリー

プロジェクト着任

Apex 開発者として、 初めての Salesforce プロジェクトに参画。

プロジェクトの危機

コードベースに目を通すと、 崩壊の一歩手前 という状態だった。

アーキテクチャの不在

オブジェクト指向設計を無視した手続き型スクリプトの山

形だけのテスト

アサーションが 1 行もない、 カバレッジ稼ぎだけのテストクラス

N+1 問題

あちこちに散らばるクエリ問題が、 パフォーマンスと信頼性を蝕んでいた

モダン Web 開発で当然のように大切にされている基本が、 ここには一切残されていなかった。

調査と分析

Salesforce 開発でよく起きる課題 (テストの書きにくさ / データ依存 / ビジネスロジックの肥大化) を体系的に洗い出した。 モダン Web 開発のパターンを、 Salesforce プラットフォーム上にどう適応できるかを探る。

ブレイクスルー

これが目を覚ますきっかけになった。 Salesforce 開発の現場には、 より良いパターンと実践が必要だ、 と確信した瞬間。

Decided to build

ApexEloquent

自前のフレームワークを作る。 ここから Apex Stem 全体への構想が始まった。

中心に据えたのが Query Delegation Pattern。 ドメインロジックを I/O から切り離し、 モック中心の高速な単体テストを書けるようにする設計です。

フレームワーク開発

ApexEloquent を組み上げ、 磨き続けた。 Query Delegation Pattern の実装、 詳細なドキュメント整備、 複雑な業務シナリオ (請求書管理など) を想定したサンプル実装まで、 一通り揃えた。

姉妹 OSS の登場

ApexEloquent だけでは解決しきれない領域 (結合テストデータ生成 / Usecase のライフサイクル追跡 / 基盤ユーティリティ) があると分かり、 続けて 3 つの OSS を順次設計した。

  • ApexBlueprint: 結合テストデータを宣言的に組み立てる OSS
  • ApexTrace: Usecase のライフサイクルログとテストの経路検証
  • ApexTools: TriggerHandler 基底クラスと、 DI 対応の HTTP リクエストラッパー

こうして 4 つの OSS が揃った。

Handler-Usecase Architecture の考案

4 つの OSS を 1 つの開発フローで統合運用するための設計が必要になり、 Handler (エントリポイント) と Usecase (業務ロジック) の 2 段構えのアーキテクチャを考案した。 この 4 OSS + アーキテクチャ全体を Apex Stem としてまとめ、 一貫した思想で運用できるようにした。

知見の共有

同じ課題に直面する開発者にこのアプローチを届けたくて、 このサイトを立ち上げました。 堅牢で、 スケールしやすく、 テストしやすい Salesforce アプリケーションを作るための、 より良いやり方を探求しつづけています。