Salesforceを“完璧に作らない”という選択。SES管理をStarter Editionから始めた理由

SES事業を拡大していく中で、私たちは一つの壁にぶつかりました。

「Excelのスキルシート管理だけでは、限界が来る」

ということです。

エンジニア数が少ないうちは回ります。

しかし、

• 誰が空いているのか

• 何が得意なのか

• どの現場に合うのか

• 最近の評価はどうだったのか

• どの案件に提案したのか

こうした情報が、徐々に散らばっていきます。

スキルシート、メール、営業メモ、チャット、個人の記憶——。

すると、営業は「探すこと」に時間を使い始めます。

本来やるべきは、

「この案件に、この人は合うのか？」

を考えることなのにです。

Salesforceを使えば解決する……はずだった

そこで候補に上がったのがSalesforceでした。

しかし、最初に感じたのは、

「できることが多すぎる」

ということでした。

AIに相談すると、

• レコードタイプ

• Flow

• カスタムオブジェクト

• 自動提案

• Agentforce

• 評価スコアリング

• 面談管理

• ダッシュボード

• 自動マッチング

など、非常に高度な構成案を提案してくれます。

確かに理想です。

しかし、ここで重要なのは、

「理想のシステム」
ではなく、

「現場で本当に回るシステム」

でした。

私たちは“Starter Edition”から始めることにした

最初からEnterpriseやUnlimitedではなく、Starter Editionを選択しました。

理由はシンプルです。

「まず、実際に使うこと」

を優先したからです。

現場で必要だったのは、実はそこまで多くない

営業視点で考えると、本当に必要だったのは次の情報でした。

① 技術で検索できること

例えば：

• Java

• Spring Boot

• AWS Lambda

• Salesforce Apex

など。

しかも、

Java
→ Spring Boot
→ REST API

のように、細かく分類したい。

② 直近の評価が見えること

営業は、技術だけで提案していません。

「この人、最近どうだった？」

をかなり見ています。

なので、

• 顧客評価

• 再提案可否

• 営業コメント

は必要でした。

③ 得意・苦手が分かること

SESは、

「技術がある」

だけでは事故ります。

例えば、

• 技術は強いが顧客折衝が苦手

• 指示が曖昧な現場が苦手

• レビュー文化が強い現場は得意

などがあります。

これはスキルシートには載りません。

しかし、営業には非常に重要です。

さらに必要だった“現場特性”

途中で気づいたのは、

「案件」
ではなく、

「現場との相性」

が重要だということでした。

例えば：

• レビューが厳しい

• 指示変更が多い

• 自走力が必要

• コミュニケーション量が多い

こうした現場特性です。

営業は実際には、

「誰を提案するか」

だけではなく、

「事故らない組み合わせ」

を考えています。

面談前共有にも使える

さらに、この情報は面談にも使えます。

例えば：

この現場は技術深掘り型。
Spring Bootの設計経験を具体例で話した方がよい。

というような面談共有メモを作れるようになりました。

すると、エンジニア側も準備ができます。

そして、最初は“最低限”に落とした

ここが重要でした。

AIは非常に高度な設計を提案してくれます。

しかし、そのまま作ると、

「使わない機能」

が大量に生まれます。

そこで私たちは、

「今、本当に必要か？」

を何度も問い直しました。

Starter Editionで割り切ったこと

例えば、本来なら：

SES商談
受託開発商談

は、レコードタイプで分けたい。

しかしStarter Editionでは制約があります。

そこで、

商談種別

という選択リストで分ける設計にしました。

完璧ではありません。

しかし、

「まず回す」

ことを優先しました。

AIに“設計してもらう”のではなく、“対話しながら絞る”

今回、面白かったのはここです。

AIは、かなり良い設計案を出してくれます。

しかし、本当に価値があったのは、

「それ、現場で必要？」

を問い返しながら、一緒に削っていったことでした。

結果として、

• ER図

• オブジェクト定義

• 画面定義

• 実装手順

• CSVデータ

• ダッシュボード

まで、一気に初期版へ到達できました。

そして将来はAgentforceへ

実は、この設計は将来的にAI提案にもつながります。

例えば：

Spring Boot案件で、
レビュー文化強め、
主体性要求高めでも合う人

と聞けば、

候補：
山田太郎

理由：
・Spring Bootスコア11
・レビュー評価高
・自走力高

のような提案ができる未来です。

しかし、それは“最初から作る”ものではありません。

最後に

システム開発で重要なのは、

「理想形」

より、

「現場で回る最初の形」

だと思います。

そして、AIは“全部作る存在”ではなく、

「考えるための壁打ち相手」

として非常に強力でした。

武蔵常盤株式会社では、こうした「現場から逆算するシステム設計」を、これからも実践していきたいと思います。