システム開発というと、

要件定義
↓
設計
↓
開発
↓
完成

という流れをイメージする方が多いと思います。

私自身も、どちらかと言えば、

「最初に完成形を決める」

という感覚を持っていました。

しかし今回、Salesforceを使ってSES営業管理システムを構築しようとする中で、その考え方がかなり変わりました。

そして、その中で強く理解できたのが、

POC（Proof of Concept）

の本当の意味でした。

最初は「スキルシート管理」が目的だった

最初の課題はシンプルでした。

「Excelのスキルシート管理に限界を感じた」

ということです。

エンジニア数が増えると、

• 誰が空いているのか

• 何が得意なのか

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

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

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

結果として、

「探す時間」

が増えていく。

本来、営業が考えるべきなのは、

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

のはずなのに、情報探索に時間を使うようになってしまう。

そこで、

「SalesforceでSES管理をできないか」

を考え始めました。

AIに相談すると、理想的な設計はすぐ出てくる

今はAIがあります。

相談すると、

• スキルDB

• 顧客評価

• 自動提案

• Flow自動化

• ダッシュボード

• 面談管理

• Agentforce連携

など、かなり高度な設計を提案してくれます。

しかも、かなりそれっぽい。

最初は、

「これを作ればいいのか」

と思いました。

でも途中で気づいた

実際に考え始めると、

「本当に必要なのは何か？」

が分からなくなってきました。

例えば、

• 技術検索は必要

• 顧客評価も欲しい

• でも入力項目が多すぎると使われない

• 面談共有はかなり重要

• 現場特性も必要

• でも最初から全部は重い

ということが見えてきた。

そこでStarter Editionという選択

最初から大規模導入ではなく、

Salesforce Starter Edition

を前提に考え始めました。

Starterには制限があります。

例えば：

• レコードタイプ制限

• 高度権限制御の弱さ

• 複雑Flowの限界

など。

しかし逆に、

「本当に必要なものに絞る」

きっかけになりました。

さらにDeveloper EditionでPOCを作ることにした

そして最終的に、

「まずPOC版をDeveloper Editionで作る」

という考えに至りました。

これはかなり大きな気づきでした。

POCは「技術検証」だけではなかった

以前の私は、

POC = 技術的に動くか試すもの

だと思っていました。

しかし実際にやってみると、違いました。

本当は、

「自分たちが本当に欲しいものを確認する作業」

だったのです。

作ってみると、理想が変わる

実際に設計してみると、

最初は必要だと思っていたものが、

「意外と使わなそう」

だったりする。

逆に、

「これは絶対必要」

が後から見えてくる。

例えば今回で言えば：

• 得意分野

• 苦手分野

• 現場特性

• 面談共有メモ

はかなり重要だと分かりました。

これは単なるスキル管理ではありません。

「SES営業の判断」

そのものに近い。

「技術マッチ」だけでは事故る

SES営業では、

「技術が合っている」

だけでは不十分です。

実際には、

• レビュー文化が強い

• 自走力が必要

• 指示が曖昧

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

など、

「現場との相性」

がかなり重要。

だから今回、

現場特性

という概念を入れました。

これは、作りながら初めて見えてきたものです。

POCで重要なのは「小さく間違えること」

今回かなり理解できたのは、

「最初から正解を作る」

のではなく、

「小さく試して、小さく修正する」

ことの重要性でした。

実際、開発で一番高いのは、

「間違った方向へ大きく進むこと」

です。

だからPOCは、

「低コストで間違える」

ためのものでもある。

AI時代は「作る」より「何を作るか」が重要

今はAIのおかげで、

「作るコスト」

はかなり下がっています。

すると重要になるのは、

「何を作るべきか」

です。

今回もAIは非常に良い提案をしてくれました。

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

「営業でどう使う？」

を何度も問い直したことでした。

そして見えてきたこと

今回やっていたことは、

単なるSalesforce導入ではなく、

「武蔵常盤の営業の型を言語化すること」

だったのだと思います。

例えば：

• どういう人を提案するか

• どの現場を避けるか

• どんな案件で事故るか

• 面談で何を伝えるか

こうした暗黙知を、少しずつ構造化していく。

最後に

今回かなり学びになったのは、

「POCは、完成品を作る前段階」

ではなく、

「自社に合う形を発見するプロセス」

だということでした。

そして、中小企業こそ、

「まず小さく作る」

というアプローチは、かなり相性が良いのではないかと思っています。