この記事は株式会社エス・エム・エス Advent Calendar 2024 vol.2の12/20の記事です。
エス・エム・エス BPR推進部 EA推進Gr CSF開発チームの藤田と申します。 私は2023年8月にエス・エム・エスへ入社し、社内業務基盤として活用している介護キャリア・介護経営支援向けのSalesforceのシステム保守・エンハンス開発を行うチームのEM（エンジニアリングマネージャー）を担当しています。 前職ではSIerとしてSalesforce導入事業のPMをしていました。かれこれ15年ほどSalesforceに関わっています。 プライベートでは4人の子供を持つ父親です。10歳、8歳、3歳の男の子3人、0歳の女の子1人とバラエティーに富んだ生活送ってます。
CSFってなに？
エス・エム・エスでは現在、Salesforceの組織（環境）を3つ契約しています。 私が入社した段階ではMSF、CSFの2つが存在し、今年第3のSalesforceとしてカイポケM&A用のSalesforceが誕生しました。 MSF？CSF？何が違うの？という声を社内からもよく耳にするのでこの機会に紹介しておきます。
- MSF：医療・介護キャリア向けのマッチングシステム。「M」は「Medical」から取ってます。
- CSF：介護キャリア・介護経営支援向けのSFA/CRM。「C」は「Care」から取ってます。
前職ではSalesforceの新規導入がほとんどだったので、入社直後はSalesforceを複数組織契約していることやSalesforce組織それぞれに呼称をつけているのも新鮮でした！ 今回は我々CSF開発チームが管掌しているCSFについて語っていきたいと思います。
2017年1月に誕生したCSFですが、初期開発当初からなるべく標準機能を使って要件を満たすことをポリシーとしています。 特にUI部分は現在もほとんどが標準機能（フロー）や標準画面を活用しています。 Salesforceの運用や開発に携わったことがある方はご存じだと思いますが、SalesforceではUI部分はVisualforce、LWCといったカスタマイズ開発手法が用意されています。 これらのカスタマイズ開発を行うことでより柔軟な画面機能を実現することが可能な反面、開発コスト、メンテナンスコストが多大にかかることや、標準機能を使用することで得られるメジャーアップデートでの新機能追加の恩恵を受けられないというデメリットもあります。 前職でSalesforce導入をしていた際の自分のポリシーもなるべく標準機能を使うことだったので、このあたりは違和感なくジョインできました！
UIは現在も標準機能を活用する一方で、バックエンド系の処理は元々プロセスビルダーやワークフロールールなどの標準機能を多く活用していたのですが、最近はApexを使ったカスタマイズ開発も増えてきました。 その理由としては大きく2つあり、1つは周辺システムとの連携が増えてきたことです。後述する価値提供先のニーズを満たすため、社内外の周辺システムとのAPI連携にApex開発を用いたり、システム連携方式を検討するうえで保守性や可用性を担保するためにデータ格納先のオブジェクトとは別にシステム連携用のオブジェクトを作成し、Apexトリガーを使ってデータ連携を行ったりを積極的に採用しています。
もう1つはバックエンド処理の複雑化です。元々プロセスビルダーやワークフロールールを積極的に取り入れていたのですが、これらの機能が廃止されフローに統合されることがSalesforce社よりアナウンスされています。それを受けてフローでの処理実装をメインに進めていた時期があったのですが、バックエンド処理をフローのみで構築する場合、複数オブジェクト×複数のループ処理などを実現するのは開発コストだけでなくメンテナンスコスト（他のメンバーが理解する、改修する）も多くかかってしまうことがあり、現在では新規の機能開発の場合は処理内容を踏まえたうえでApex開発を選択することも増えてきました。
CSFの価値提供先はどこ？
記事のタイトルのとおり、複数の介護事業者向けサービスの業務基盤となっているCSFですが、 具体的には主に3つのサービスに対して価値提供をしています。
- 介護/障害福祉事業者向け経営支援サービス「カイポケ」：業務効率化や財務改善など、介護/障害福祉事業者の経営改善に役立つサービスをワンストップで提供するサブスクリプション型のクラウドサービス。カイポケが提供する各サービスについてのフロント/バックオフィス業務に対してリードや商談、ケース、約20ほどのカスタムオブジェクトを使って業務基盤を提供しています。エス・エム・エスではカイポケを利用する介護事業者向けに介護に関する報酬改定について、特設サイトを公開しているのですが、令和6年度の報酬改定ではSalesforceのExperienceCloudを使ってサイトを公開しています！
- ファクタリング（カイポケ早期入金サービス）：エス・エム・エスのファクタリング（早期入金）とは通常、保険請求から2か月後に国保連から入金される介護・診療報酬を請求月に請求額の8割を、残り2割を請求月の2か月後に振り込むサービスのことです。これにより、前倒しで資金調達が可能であり事業者の資金繰りを安定化させることを目的としています。ファクタリングでは商談から契約管理、送金管理までほぼ全ての業務プロセスをCSF内でサポートしています。カスタムオブジェクトを約30ほど使ったCSF内で最も大きなアプリケーションです。
- 介護向け求人情報サービス「カイゴジョブ」：ホームヘルパーや施設介護職員、ケアマネジャー、サービス提供責任者、生活相談員など、介護・福祉の仕事に特化した求人情報を提供しています。最適な事業者とのマッチングを支援するサービスです。カイゴジョブについても商談や見積、ケース、約15ほどのカスタムオブジェクトを使って業務基盤を提供しています。カイゴジョブではカスタマーサクセスの方が使っている業務システムがSalesforce（CSF）/kintoneで分かれています（いつかは統合したい）。使っているシステムが違うことで作業依頼を毎回チャットに転記していたりするので自動で連携したい、や「カイゴジョブ」システムとCSFの情報を同期させて常に最新の状態を参照したい、を解決するためにAWSやETLを介したシステム連携を実現しています。
上記サービスのセールス、マーケティング、カスタマーサクセス、オンボーディング、契約管理、販売管理などの業務プロセスに携わる方々がいかに日々の業務を効率よくこなしていけるか、ほしい情報をほしい粒度で提供できるか、という要望や課題を元に既存の運用や仕組みにとらわれず、事業戦略や将来の変化を見据えたシステムのアーキテクチャをSalesforceというPlatform上で考えられる最善策を検討し実現していくのが我々の価値になっています。
CSF開発チームではどんなことしているの？
一言でいえば「CSFに関するありとあらゆることをやっています！」になるのですが、例としていくつか挙げていきます。
エンハンス開発
- 事業側からの要望を受けて機能追加、機能改修を行っています。 現在我々の部署ではBusinessArchitect（ビジネスアーキテクト）が事業側とシステム開発側の間に立って業務改善を推進してくれているのでBusinessArchitectとタッグを組んで課題解決のためのシステム対応を進めています。 BusinessArchitectについてはこちらの記事で詳しく説明されています！
- 複数サービスが共通のオブジェクトを利用していることも多く、デグレードしないために行う影響調査が最も重要です！
- エンハンス開発は多くの場合、1チケットにつきエンジニア1名で進めていくのですが、エンハンス開発の中でも比較的大きな規模の開発は「大玉案件」としてプロジェクト化して複数名で進めていきます。
- 大玉案件の一例
- カイポケリニューアルプロジェクト：プロダクト開発との初めての大規模な協業です！
- M&Aプロジェクト：カイポケM&Aに特化した第3のSalesforce組織立ち上げではCSFのエンジニアがCSFの知見や実装した機能を活かして実現しました！
- 報酬改定特設サイトプロジェクト：エス・エム・エスの外部公開サイトでは初となるExperienceCloudを活用したWebサイト構築です！カイポケブランドのデザインに準拠するため、標準機能だけでなくLWCも多く活用しています。
- 大玉案件の一例
データメンテナンス
- こちらも主に事業側からの要望を受けての対応になりますが、データを一括で登録/変更したい場合やデータの削除依頼などを日々対応しています！リード情報の一括登録依頼を見ていると事業部の皆さんがめちゃめちゃ頑張ってくれているんだ、と実感してます！
- メジャーアップデート対応
- Salesforceといえばこれ。年3回のアップデートに備えて既存機能が正しく動作するかの確認や新しくリリースされるSalesforceの機能をキャッチアップして取り入れたりしています。
- システム監視
- CSFでは出来るだけSalesforceの標準機能を活用して業務基盤を構築しているのですが、どうしてもニーズを満たすためにApexを使う場面もあります。カスタマイズ開発すれば意図しないエラーなども付いて回るため、エラーが発生した際にはなるべく早く検知し対応するためにSlackでのエラー検知を実装しています。
Slackでのエラー検知を実装する前はSalesforceから届くエラーメールを都度確認していたのですが、チーム内でのコミュニケーションの大半をメールではなくSlackで行っており、メールに気づく人が限られているため初動対応が遅れてしまうなどの課題がありました。今ではエラーが発生した際にはそのスレッド内で即座にチームでやりとりし、原因特定して影響の有無や対応要否を判断した上で迅速に対応するということが実現できています。
- CSFでは出来るだけSalesforceの標準機能を活用して業務基盤を構築しているのですが、どうしてもニーズを満たすためにApexを使う場面もあります。カスタマイズ開発すれば意図しないエラーなども付いて回るため、エラーが発生した際にはなるべく早く検知し対応するためにSlackでのエラー検知を実装しています。
- アカウント管理
- CSFでは現在500名以上の社内ユーザーが利用されています。毎月の入退職によるアカウントの追加/削除の他、部署異動によってCSF内で行う業務が変わる場合などの権限変更対応を行っています。
上記のようにCSF開発チームでは日々さまざまな業務を実施していますが、一部を除き業務の担当者を固定していません。エンハンス開発やデータメンテナンスについてはメンバー1人1人が自分のリソースや作業状況を元にBacklogチケットの中で着手できそうなものを自ら取っていく、という方式にしており、メンバーが自律的に動いて仕事を進めていくことに重きを置いています。もちろん業務の中で想定外のことやうまくいかないこと、ミスしてしまうこともあると思いますが、朝会などの定例やSlack等のコミュニケーション手段を活用して積極的にアラートをあげてもらうことで私自身や他のメンバーがサポートに入りつつチームとして成果をあげていくことを目指しています。
今後の展望
私がエス・エム・エスに入社しEMとなってからCSFに関するOPSの改善等を取り組んできました。 優秀なアドミニストレーター・エンジニアの皆さんのおかげでさまざまなエンハンス開発を進めながらも大きな障害を起こすことなく運用が出来ていますが、まだまだ改善できるところやチームのケーパビリティ向上が図れると考えています。
今後取り組みたい施策としてCI&CDパイプラインの構築やデータストレージ対策（SalesforceConnectの活用）といった大きなものからOPSの改善などの細かいものまでやりたいことがたくさんあります。 また、価値提供先の事業規模も拡大していく中でより柔軟かつスピーディーに要望を実現する開発チームにしていく必要があり、そのためにはエンジニアはもちろん、チームの戦略やOPSを自分事として一緒に考え、周りを巻き込んで自ら実行できる人が必要です。 CSF開発チームでは、アドミニストレーター・エンジニア、テックリードやエンジニアリングマネージャーを募集しています！一緒にチームや仕組みづくりをしていきましょう！ CSF開発チームについてちょっと面白そうと思った方や、もう少し具体的な話を聞きたいと思った方、ほんのちょっとでも興味がある方は下記リンクからご連絡ください！
