大手SFAサービスからフルスクラッチでリプレイス【株式会社fundbook様】

1-1. M&A仲介業界の特徴

M&A仲介の業務は、一般的な営業職の業務フローと比べても格段に複雑です。まず、クライアント企業（売り手・買い手）が非常に多様であり、それぞれが置かれている経営環境や要望が異なります。また、M&Aの性質上、法務・財務・税務など、専門領域ごとのチェックが多岐にわたるため、案件管理には膨大なドキュメントと確認プロセスが発生します。さらに、複数のステークホルダーとの連絡・調整が連鎖的に生じるため、進捗管理と情報共有が円滑に行われないと、交渉の停滞やミスコミュニケーションに繋がりやすい分野です。 こうしたM&A仲介特有の複雑な業務フローを管理する上で、SFAやCRMといったシステム活用は不可欠です。顧客データベース管理や案件ステータスのトラッキング、担当者間のタスク共有など、一元管理による効率化は大きなメリットとなります。しかし、それが十分に活用されていない場合や、システムが現場の使いにくさを抱えてしまった場合、かえって業務効率に悪影響を及ぼすケースもあります。

1-2. SFAの導入と拡張

株式会社fundbookでも、当初は大手のクラウド型SFAを導入していました。世界的に実績のあるプラットフォームであり、標準機能だけでも多くの業務フローをカバーできます。一方で、会社規模が大きくなるにつれ、ライセンス費の高騰は看過できない問題へと発展していきました。 また、M&A仲介業界固有の複雑な業務フローを実現しようとすると、既存SFAを標準のままで使うだけでは不十分となり、どうしても高度なカスタマイズが必要になります。しかし、SFA上で次々とカスタマイズを行ううちに、画面遷移が多くなり、ユーザーインターフェースが煩雑化してしまいました。特に現場の営業担当者からは「どの画面で何を入力すればよいのか分かりにくい」「本来自分がやりたい処理にたどり着くまでのステップが多い」といった声が上がっており、システムが本来の目的である業務効率化を妨げている状態でした。 結果として、会社が拡大するにつれてライセンス費は年々増え続け、しかもカスタマイズによる使い勝手の悪さが顕在化し、コスト面でも運用面でもストレスが高まっていたのです。

2-1. 課題の明確化

開発前にfundbook様が直面していた主な課題は次のとおりです。

1. ライセンス費の増大 会社規模拡大に伴い、SFAのユーザーライセンス費が大きくなり、将来的にはさらに大幅なコスト増加が見込まれていた。
2. 業務フローの複雑化 標準機能だけでは足りず、頻繁なカスタマイズを実施した結果、ユーザーインターフェースや操作フローが煩雑になった。必要な情報にたどり着くまでのステップが増えたことで、現場担当者の負担が増大していた。
3. 使い勝手の悪化 カスタマイズによってシステム全体が分かりづらくなり、特にM&A仲介に特化した情報の管理やフローが標準機能にうまく収まらない部分があった。加えて、外部との電話連携など、現場レベルで「この機能があればいいのに」と思う細かな機能が実装されておらず、不便を強いられていた。

2-2. 新システムに求められる要件

同社が次に構築すべきシステムとして明確にした要件は、以下の3点に集約されます。

1. コスト削減 ライセンス型SFAを利用し続けることで生じる中長期的なコストを削減するため、ライセンス型の課金モデルから脱却すること。
2. 自社の業務フローへの完全最適化 M&A仲介特有の複雑なフローに加え、同社が培ってきたノウハウをシステムに取り込み、かつユーザーインターフェースを簡潔に保つ必要がある。これを実現するために、フルスクラッチでの開発を選択肢とした。
3. 使いやすさと拡張性 単に業務を処理するだけでなく、現場担当者がストレスなく利用できるUI/UXを追求する。さらに、将来的に業務範囲や企業規模が拡大した際にも、柔軟に拡張可能な設計にすること。

3-1. プロジェクト体制

新SFAシステムの開発は、弊社と二人三脚での開発プロジェクトとなりました。プロジェクトマネージャーを中心に、要件定義フェーズではM&A仲介事業の担当者や管理部門のキーパーソンを巻き込み、現状の業務フローや課題を徹底的に洗い出し、必要な機能を精査しました。既存のSFA設定やデータ構造を分析しながら、新たに構築すべきデータモデルや画面設計の方針を固めていきます。

3-2. 開発期間とフェーズ

プロジェクトには13ヶ月という比較的長期の期間が割り当てられました。その内訳は以下のとおりです。

1. 要件定義（3ヶ月）
   • 現在の業務フローの洗い出し
   • 既存SFAでどのようなカスタマイズを行っていたかのヒアリング
   • 新システムで必須となる機能と優先度の整理
   • 使用技術やUI/UXの方向性を概念設計段階で検討
2. 基本設計・詳細設計（3ヶ月）
   • データモデルの策定（M&A案件、クライアント情報、タスク管理、進捗状況など）
   • 画面レイアウトのワイヤーフレーム作成
   • PC・スマホ連携や外部サービスとのAPI連携仕様の確定
   • セキュリティ・権限設計の策定
3. 開発・単体テスト（4ヶ月）
   • フロントエンド・バックエンドの実装
   • DB設計に基づくテーブル作成とスクリプト開発
   • 単体テストでの機能レベル検証
   • カスタマイズ要望の微調整
4. 統合テスト・移行準備（2ヶ月）
   • 既存SFAデータの移行テスト
   • 開発環境と本番環境の整合性確認
   • 業務担当者による受け入れテスト（UAT）
   • 操作マニュアルや利用ガイドラインの作成
5. 本番リリース・運用開始（1ヶ月）
   • 本番反映とデータ最終移行
   • 運用体制の確立
   • リリース後の初期トラブル対応と安定運用へ移行

4-1. フルスクラッチ開発による柔軟なUI/UX

今回のシステム開発では、「本当に使いやすいUI/UX」の実現を最重視しました。既存SFAでの運用時に生じていた「画面遷移が多く、入力項目が散らばっている」「ワンクリックで行きたい場所に行けない」といった不満を解消するためです。

4-2. PC→スマホ通話へのシームレスな連携

M&A仲介業務では、クライアント企業との連絡が頻繁に発生します。新システムでは、SFA画面上に表示されるクライアントの電話番号をワンクリックまたはタップでスマートフォンの発信画面に連携できる仕組みを整備しました。こうした「痒いところに手が届く」細かなUI/UXの改善が、現場担当者からは特に高く評価されています。

4-3. 担当者ごとの権限管理とセキュリティ

M&A仲介情報は機密性が高く、データの閲覧・更新権限には厳密な管理が求められます。フルスクラッチ開発によって、担当者の部署、役職、プロジェクトへの関わり度合いなど、多角的な条件を組み合わせた柔軟なロール設計が可能になりました。データベース側でも高度な暗号化とログ管理を実装し、アクセス監査を徹底しています。

4-4. 今後の拡張を見据えたアーキテクチャ

新システムのアーキテクチャ設計ではAPIファーストの考え方を取り入れ、内外のシステム連携を容易にする実装を行いました。フロントエンドとバックエンドを疎結合に保つことにより、UI部分のリニューアルや追加機能の実装を柔軟に行えるようにしています。

5-1. 大幅なコストカットの実現

最大のメリットのひとつが、ライセンス型からの脱却による中長期的なコスト削減です。初期開発費用こそ一定程度かかったものの、以後は毎月のライセンスコストがほとんどかからなくなりました。結果として、5年、10年のスパンで見たときにライセンス費を払い続けるよりも、はるかに費用対効果が高いとの試算が出ています。

5-2. 業務効率と担当者満足度の向上

従来のSFA利用時に比べると、業務画面の遷移回数が大幅に削減されました。複数の画面を行ったり来たりする必要がなくなり、入力項目も極力まとめられているため、現場担当者のストレスが著しく減っています。担当者のシステム利用頻度が増え、結果的に顧客データがより正確かつ網羅的に蓄積される好循環が生まれました。

5-3. 正確な情報蓄積と経営判断のスピード化

フルスクラッチの新システムでは、M&A仲介に必要なあらゆる情報を一元管理できるようになっています。経営層がダッシュボードを確認してリアルタイムに案件の状況を把握し、戦略的な意思決定を下すことが可能になります。

5-4. 運用の内製化とスピーディーな改修

フルスクラッチであれば機能追加やバグ修正を自社判断でスピーディに行える点が強みです。これは急成長フェーズにある企業にとって、日々変化する要件に俊敏に対応できる大きなアドバンテージと言えます。