ID:78345さん

## 概要 - SalesforceでClassic環境で運用している企業からのLightning環境への移行案件。Sales Cloud を使用して、受注管理から仕訳生成までをSalesforceで行っている。現行環境を旧Salesforce組織として残しつつ、新Salesforce環境をLightningで構築。 ## プロジェクト背景 - Classicで運用していたが、保守会社の保守状況が芳しくないため、ビジネスの変化にシステムが対応できていないことが課題となっていた。そのため、開発体制を再整備し、今後のシステムをよりアップグレードさせるために新規にLightning 環境へ切り替えることにした。 ## チーム構成 PM1人、エンジニア3人 ## 担当した役割 - 開発リーダーとして参画設計 - 設計、技術的課題の解決、開発、メンバーの開発支援 ## 課題 - 既存の処理を流用したいところであったが、新規にパッケージ(ソアスク)を導入したため、オブジェクト構造などが一部既存の資材と差異があり、そのまま処理を利用するということができない状況だった - Classic 環境では、Visualforce、Apexの個別カスタマイズを用いたUIで業務を行う運用方法が確立していて、Lightningへの移行時にVisualforceからLightning web Component や画面フローに適宜リプレイスする必要があった - 開発資産に対するドキュメントが一切残っておらず、元々導入をした受託企業に問い合わせても、各機能の仕様が明確にならない状況だった - メンバーの中にコーディング開発経験のある者がいない状況だったため、各機能の設計を行いつつ、VisualforceやApexの既存処理のリーディングおよびコーディング開発を並行で担当する必要があった - 旧環境側で経費精算などの計算処理が行われているため、計算結果を仕訳作成をしている新環境側へ連携する必要があった ## 課題に対するアクション - 既存処理の仕様ドキュメントがないため、まずはリプレイスする必要がある機能のコードリーディングを行い、仕様を書き起こし、PMと連携をして既存の資材とソアスクの資材のマッピングを行った - 元々Visualforceで動いていた画面は、「画面フロー」、「画面フロー＋Apex」、「LWC」の3つの形式に分類して、画面フローの部分を他メンバーに担当してもらった - 旧SF環境と新SF環境にそれぞれ接続アプリケーションを構築し、Oauthのクライアントクレデンシャルフローを用いて連携処理を実装 ## 成果 - 現在はスモールスタートで、一部の運用に関しては新環境でスタートしてもらっている。今後随時旧環境で行っている業務を新環境で運用できるように開発していく想定。

## 開発目的 - 無償で顧客にプロダクトを利用してもらうことで、認知や受注率を上げていきたいという考えがあったが、社内のセールスのリソースにも限りがあるため、「顧客がプロダクトを利用できるまで」を自動化したいという目的があり、本アプリケーションの開発が始まった。 ## プロジェクト概要 - チーム構成 - エンジニア2人 - プロダクトオーナー1人 - デザイナー1人 - 担当した役割 - 要件定義、設計、開発、進捗管理、テスト - 課題 - オンライン申し込みがあった内容を社内プロダクトのDBへの連携と併せてSalesforce側へ商談情報および商品情報を自動登録する必要があり苦労した ## 技術的なポイント - BackendはAPI GWとLambdaのサーバーレス構成で、CICDでCodeBuildを使い、GIthubへのPushでリリースが走るように整備 - PythonのFW ## 成果 - 顧客が申し込みをすると、自動で社内プロダクトへテナントが作成され、Salesforce上へ企業情報および商談情報などが登録され、かつ申し込みの内容がスラック通知されるまでのフローを全て人手を介さない形で実現した

## 開発目的 - アプリケーションのE2Eテストに従来は退職者が作成した独自ツールを使用していたが、メンテナンスが困難になったため、Playwrightを用いて自チームで管理可能な新しいE2Eテスト基盤を構築。 ## プロジェクト概要 - チーム構成 - エンジニア2名 ## 担当した役割 - 企画、設計、タスクの切り出し、開発 ## 課題 - テストを導入するリポジトリが複数あるため、複数のリポジトリにテストケースが散財してしまうと保守が困難になる - 一部のアプリケーションはAWSのセキュリティグループ（以下SGと呼称）とALBのターゲティンググループでIPアドレスによるアクセス制限をしているため、IPアドレスの制限を突破する仕組みが必要になる ## 技術的なポイント - Reusable Workflowを用いてテストコードを一元管理。 - GitHub Actions上でE2Eテストを実行するため、専用リポジトリでActionを定義し、他の複数リポジトリから呼び出し可能に設計。 - IPアドレス制限があるアプリケーションへのE2Eテスト実行のため、AWS CLIを利用してActionsサーバーのIPをALBのSGおよびターゲティングルールに動的に追加・削除する処理を実装。 ## 成果 - 退職者が作成した独自ツールをもとに行っていたE2Eテストを全て置き換えることに成功 - テストケースの追加が容易になった

## 開発目的 - プロダクトの契約が解約されると、顧客に払い出しているテナントの利用停止するために解約処理を行う必要がある。解約処理は手動で行われていて、0.2人/月くらいの工数がかかっていた。解約処理の工数削減と手動によるヒューマンエラーの防止も兼ねて解約処理を自動化するため開発が始まった。 ## プロジェクト概要 - チーム構成 - エンジニア1人 - プロダクトオーナー1人 - 担当した役割 - 要件定義、設計、開発、進捗管理、テスト - 課題 - マルチテナンシー設計のため、誤って解約処理対象外のテナントに影響が出ないように設計をする必要があった - すでに解約となっているが自動解約対象に含めたくないという要望があったので、解約処理チームが手動で解約処理対象に含めるか否かの機能を含める必要があった - テナントの解約情報は、Salesforce上に管理しているため、解約処理結果をSalesforceに連携する必要があるが、どういった情報を残せば適切かを検討する必要があった ## 成果 - 今まで手動で行われていた解約処理が自動化され、工数の削減だけでなく、ヒューマンエラーの入る余地もなくすことができた

## 概要 - 大手保険会社にて自社で開発したオンプレミスのサーバーで動くチャットサービスを利用していたが、システムの規模が膨らんできて、小さな変更をする際も既存機能に影響を与えないようにリリースを行う必要があり、要求から反映までのリードタイムが多くかかってしまっていた。よって、チャット機能をSalesforceで置き換え、かつCRMシステムとして自社システム情報と連携することでクラウド型のコンタクトセンターシステム構築を行うこととした。 ## プロジェクトのフェーズ - POC＋要件整理フェーズ - 主要な現行業務フローを抜粋して、Salesforceで実装したらどのようになるのかのPOCフェーズをアジャイル開発で実施 - 要件定義フェーズ - Salesforceの導入が確定したので、改めて要件定義とスコープの策定。スコープとしては一旦、チャット機能のみをSalesforceに構築することを決定。その他のチャネルは、追加開発としてスコープアウト。本フェーズはウォーターフォールで実施。 - 設計＋開発 ＋単体テストフェーズ - 設計、開発、テストをアジャイル開発で実施。開発しつつ、改善要求などがあれば工数を積んで改善開発を同時に行った。 - 結合テスト＋UATフェーズ - リリース ## 規模感 - プロジェクト全体の規模 - コンサルタント含め50人規模 - 自身のチーム構成（6人） - PM - PL - 開発リーダー - 開発メンバー - 担当した役割 - 開発リーダー ## 課題 - 「設計＋開発 ＋単体テストフェーズ」では、スプリントレビューの際に出た改善要求のタスクが初期は多数出たので、開発工数が膨らみ、当初予定していたリリース時期からは少し延伸してしまった - 一部 Lightning Web Component ではサポートされていない Service Cloud の組み込みAPIがあるので、その場合はAura Component　で作成する必要があった ## 成果 - 現在は、チャット機能が無事リリースすることができ、運用が障害もほとんどなく安定稼働している。担当者からも変更を要求してから反映までの速度が従来と比べて格段に速いことに満足していただいている。