ID:84252さん

① どんなサービス・システムか 　教育事業グループ横断データ基盤構築 ② あなたは何を担当したか チーム体制： PM1名、Saesforce エンジニア2名、MulesoftおよびHeroku Postgresエンジニア2名の合計5名体制。 私はSalesforceエンジニアとしてプロジェクトに開発工程終盤から参加。 主担当はSalesforce領域の開発業務に携わった。また、副担当としてHeroku Postgresのデータ連携領域のテスト実施および支援も行った。 担当領域： A：Heroku Postgres 　A-1：外部結合テストの実施 　A-2：データ退避機能の設計、実装、テスト B：Salesforce領域の機能開発 　B-1：権限管理の仕様変更対応 C：Salesforce環境構築 　C-1：カスタマイズ資材の一覧化、Git管理の整備 　C-2：Integration Sandbox、UAT Sandboxと本番環境の構築 　C-3：資材デプロイの手順化と手順のテスト ③ どんな技術を用いたか A：Heroku Postgres 　・Heroku Postgres 　・ストアドプロシージャ 　・DBeaver 　・Claude Code B：Salesforce Service CloudおよびSalesforce Experience Cloudのカスタマイズ 　・Apex／Apexトリガー／LWC／Lightningページ／カスタムメタデータ／SOQL 　　／カスタムオブジェクト／入力規則／Flow／カスタム表示ラベル／静的リソース 　　／権限セット／公開グループ／組織の共有設定／共有セット／共有ルール 　　／カスタムタブ／カスタムオブジェクト 　・Claude Code C：Salesforce環境構築 　・Salesforce CLI 　・Claude Code ④ どんな機能を開発したか/⑤ どんな課題に取り組んだか/⑥ どんな工夫をしたか A：Heroku Postgres 　・A-1：機能開発無し。テスト実施のみ。 　・A-2：データ退避機能の開発。外部システムから受領したデータをHeroku Postgresで再ロードできるように退避テーブルとデータの退避処理を作成。合わせて退避テーブルからの再ロード処理を作成。さらに、CSVを直接退避テーブルへロードするためのスクリプトを作成。(外部システムからHeroku Postgresへデータ連携する機能が使えない場合のフォールバック用途) B：Salesforce Service CloudおよびSalesforce Experience Cloudのカスタマイズ 　・B-1：ログインユーザーの権限設計機能の再設計 　　　　　Salesforceに構築するアプリケーションの会員情報の参照方針転換に伴い、各グループの会員情報のみ参照できるように権限を再設計し、管理機能の実装とテストを実施。 　　　　　【データ参照範囲の変化点】 　　　　　asis：ログインユーザーは会員がどのグループ企業の情報を全て参照可能。 　　　　　tobe：ログインユーザーは、自身が所属する企業のサービスを利用している会員情報のみ参照可能とする。 　　　　　このため、公開グループ、組織の共有設定、共有ルール、共有セット、Apex、Apexトリガーといった機能を組み合わせて、データ参照範囲の変更に対応。 C：Salesforce環境構築 　C-1：開発Sandboxで開発した機能の一覧が作成化されておらず、試作機能やデモ用の仮実装が混在していたため、各種資料とメタデータの内容から管理対象ファイルの一覧を作成。Gitも使用していなかったため、管理対象をGitに登録し、Readmeにファイル構成とブランチ戦略を出力。 　C-2：開発 Sandbox以外が未整備だったため、Integration Sandbox、UAT Sandbox、本番組織を整備し、初期設定を行って運用可能な状態を構築。 　C-3：Service Cloud、Experience Cloudに加えてSalesforce Data 360も使用しているため、それぞれの依存関係を調べてデプロイ手順を作成。また、開発時はSalesforce CLIを使用してデプロイしていたが、顧客には難しいと判断し変更セットベースのデプロイ手順を作成。 ⑦ どんな成果を出したか A：Heroku Postgres 　A-2：連携元システムは、連携用テストデータを生成から7日間で物理削除されてしまう制限があったが、データ退避機能によりその制限を気にせずテストを進められた。実際過去データの再ロードが必要になった場面があったが、退避データからデータを再作成できたため、連携元システムでテストデータの再出力させるといった追加作業無くテストを進められた。 B：Salesforce Service CloudおよびSalesforce Experience Cloudのカスタマイズ 　B-1：プロジェクトリリース2か月前に、システム全体に関わる変更であったが、無事に改修を終えて、ユーザーの適切なデータ参照範囲を実現した。 C：Salesforce環境構築 　C-1：管理対象ファイルが明確化された結果が、機能改修時に改修対象や改修範囲が明確になり、修正漏れが減った。B-1の仕様変更対応は、ファイルの全量管理が可能となったためAIを使用して影響調査および改修計画の効率的に作成し、仕様変更内容のユーザー確認から機能実装、テスト完了まで2週間で完了させることができた。 　C-2：Integration Sandbox、UAT Sandbox、本番組織と3つの環境を整備したためリリースパイプラインが明確になった。また、試作機能などの無いクリーンな環境を構築したことで、その後の資材を差分管理可能となった。 　C-3：依存関係を明らかにしたことで、安全なデプロイ手順の作成が可能となった。