← Portal
PDF でダウンロード
← → / click to navigate

AE Sales Enablement

PortX

AE オンボーディング

営業担当者として知っておくべき、PortXの原則・Formulaの伝え方・商談の進め方

株式会社PortX Confidential — PortX, Inc.
02 / 13
PortXとは

PortXは何の会社か

コンサル会社でも、従来型SI会社でも、汎用SaaS会社でもない。

ユーザーと直接向き合い、
顧客の中核業務の課題を構造化し、
動くToBeを提示し、
要求整理から実装、運用接続まで一気通貫で担い、
案件知見を複利で蓄積していく
AIネイティブなエンタープライズSI基盤会社

会社のミッション:大企業のユーザー部門に、中核業務変革の主導権を取り戻し、競争優位そのものを実装すること。

03 / 13
世界の見方

大企業のシステム化で、何が起きているか

SI(システムインテグレーション)の経験がなくても、この構造を理解していれば顧客と話せる。

現場で起きていること

困っている人が、
自分で動けない

大企業では、業務で本当に困っているのは現場の人たち(工場、物流、営業部門など)。

しかし現場にはシステムプロジェクトをやった経験がない。要件の伝え方、設計書の読み方、プロジェクトの進め方——やったことがないから、自分たちでは始められない。

だから、その経験を持つ情報システム部門が発注者になり、現場は「お願いする側」にしかなれない。

従来のやり方の問題

伝言ゲームで、
欲しいものが届かない

従来、システムを作るときは:
現場 → 情シス → 大手SI会社 → 下請け → 開発者
と何人も間に入る。

この過程で「本当に欲しいもの」が薄まっていく。

完成したものを見て「そうじゃない」が起きるのは、この構造のせい。担当者のせいではない。

PortXが入る場所

現場が自分たちで
仕組みを作れる世界

Excelやkintoneでは、現場の複雑な業務に対応できない。

従来のSIに頼ると、重く・遅く・高い。

「現場の人たちが、自分たちの業務を自分たちで仕組みにできる」——その選択肢がこれまでなかった。

PortXとFormulaは、その空白を埋める。

04 / 13
課題の具体例

どんな問題を解いているのか

「たとえば御社でいうとこういう問題です」と自分事化してもらうための具体例。

業務領域
現場で起きていること
Formulaで変わること
在庫管理
在庫数は見えるが、使える在庫か・滞留か・欠品予備軍かわからない
在庫の状態が一目でわかり、判断が属人化しない
納期回答
ベテランの頭の中にある情報で回答。その人が休むと止まる
誰でも同じ精度で即時回答できる
受注・配車
電話→手書きメモ→システム再入力。毎回3往復する
一気通貫で情報が流れ、再入力がなくなる
生産調整
需給調整が属人的で、変動に弱く月末に混乱する
判断ロジックが仕組み化され、変動に強くなる
品質管理
検査記録が紙で、傾向分析ができない
リアルタイムで傾向を把握し、予防的に動ける

ポイント:「中核業務」と抽象的に言わず、相手の業務痛を具体的に挙げてから括る。

05 / 13
Formulaの伝え方

Formulaをどう説明するか

相手の関心フェーズに応じて、説明の粒度を変える。

レイヤー1 / 初回商談

一言で刺す

「SaaSのように手軽に導入できて、フルスクラッチのように貴社の業務に合うテーラーメイドなシステムを作れるAI基盤です」

レイヤー2 / 関心を持った後

なぜ可能かを補足

「AIが、要求整理から設計、動くモック、運用・保守まで一貫して面倒を見るので、従来のSIで必要だった膨大な人手と時間を大幅に減らせます」

レイヤー3 / 比較検討時

他との違いを明確に

汎用ソフト→標準業務向き。簡易ツール→小さい改善向き。従来SI→重く遅く高い。
Formula = SIの本格さ × SaaSの手軽さ

06 / 13
勝ち筋

PortXの5つの勝ち筋

営業活動のすべてが、この5つに接続している。

01

ユーザー直結

ユーザーと直接向き合い、課題やミッションを一緒に定義する

02

ミッション起点

機能要求からではなく、業務状態・意思決定・成果の変化から逆算する

03

早期具体化

営業段階から動くToBeを提示し、要求整理と価値提示を同時に進める

04

一気通貫

要求整理から設計・実装・運用接続まで分断しない

05

複利化

案件のたびに会社資産が積み上がり、次がもっと速く深くなる

市場への入り方:broad vision × narrow entry。在庫・納期・受注配車・生産調整など、顧客が自分事化できる狭く深い業務痛から入る。

07 / 13
AEの役割

AEに求められていること

課題構造化を一人で完結する必要はない。

AEの本質的な役割

顧客との信頼関係を築き、
まだ整理されていない課題や背景を引き出す

顧客に本音で課題を話してもらえる関係を作ること。
それがPortXの全ての起点になる。

要件の構造化やシステム面はFDEとFormulaで補完できる。
AEは「信頼構築力」が最優先。

AEの具体的な動き
1. 顧客の業務痛を聞き出す(narrow wedge)
2. FDEと連携して課題を構造化する
3. Formulaで動くToBeを提示する
4. 顧客と一緒に磨きながら提案を固める
5. 業務・意思決定・成果の変化として価値を伝える
08 / 13
オファリング

何を売るのか

オファリングは機能一覧ではない。顧客の業務がどう変わるかを表すもの。

やってしまいがちなこと

機能を売る

「在庫管理画面を作ります」
「ダッシュボードを提供します」
「AIで自動化します」

→ これでは「便利ツール」の売り込みになり、
PortXの価値が矮小化される。

正しいアプローチ

業務・意思決定・成果の変化を売る

「在庫が使える在庫か滞留在庫か一目でわかる状態を作る」
「納期回答がベテラン依存から脱却できる」
「需給調整の判断品質が属人化しなくなる」

→ 変革後の業務状態で語る。

09 / 13
話法

相手のロールに応じて刺し方を変える

同じFormulaでも、相手によって響くポイントが違う。

ユーザー部門

「御社の業務にぴったり合う」

「たとえば、納期回答に毎回2日かかっていませんか?ああいう仕事を、現場の人たち自身が仕組みにできるようにするのが私たちのやっていることです」

先に具体的な業務痛を出して、後からFormulaにつなげる。

情報システム部門

「SaaS並みの関与度で済む」

「情シスの皆さんがSaaS導入時と同じくらいの関与度で、自社要件に完全に合ったシステムを導入できます」

情シスの負荷が増えないことを強調。

経営層

「競争優位そのものを実装する」

「御社の売上・利益・サービス品質に直結する業務能力を、ソフトウェアとして実装します」

経済価値とのつながりで語る。

10 / 13
禁止事項

営業でやってはいけないこと

A00に反する営業は、短期的に売れても長期的にPortXを壊す。

絶対にやらないこと
× 「速い」「安い」を売り文句にする
× 機能一覧で提案する
× Formulaをツールとして前面に出しすぎる
× ユーザーの中核業務に効かないテーマを受ける
× 看板や間接者に最適化した仕事をする
なぜダメか
→ 価格競争に巻き込まれ、PortXの価値が消える
→ 「便利ツール屋」と位置づけられる
→ 主役は「顧客の課題と変化」であるべき
→ 勝ち筋から外れた仕事が増え、複利が効かない
→ 原体験(構造への怒り)と矛盾する
11 / 13
商談プロセス

商談の進め方

抽象概念からではなく、相手の痛みから入る。

01

業務痛を聞く

「納期回答に毎回
何日かかっていますか?」
から始める

02

課題を構造化

FDEと連携して
業務構造を整理

03

動くToBeを提示

Formulaで
動くモックを
その場で見せる

04

一緒に磨く

顧客のフィードバックで
要件と価値を同時に固める

05

成果で語る

業務・意思決定・
成果の変化として
提案を仕上げる

ポイント:動くものを見るのが「半年後」ではなく「最初」。だから要件のズレが起きにくい。

12 / 13
FAQ

顧客からよく聞かれる質問

回答の型を身につけておく。

「kintoneやノーコードと何が違うの?」
小さい改善には向いている。しかし中核業務は企業固有性が高く、部門横断で、例外が多い。kintoneでは届かない領域をFormulaが担う。
「普通のSIと何が違うの?」
SIとして必要な設計書・レビュー・運用接続は全て満たす。その上で、AIが知的作業を担うことでコスト構造と進め方を根本から変えている。
「AIでコード書くやつでしょ?」
コード生成は一部。Formulaの本質は、要求整理・設計・変更管理・運用保守まで含めてSIプロジェクト全体を成立させること。Vibe Codingとは根本的に違う。
「うちの情シスの承認がいるんだけど」
情シスの方にはSaaS導入時と同等の関与度で済むことを説明する。Formulaが設計・運用の一貫性を担保するので、情シスの負荷は増えない。
13 / 13
D00 判例抜粋

CEOの判断から学ぶ

AEに関係する過去の重要判断。迷ったときの判断基準として使う。

AE採用の優先順位
論理力やシステム理解より、顧客との信頼構築力を優先する。要件構造化はFDEとFormulaで補完できる。
オファリングの切り方
機能一覧ではなく、顧客の業務・意思決定・成果の変化を表すユースケースモデルとして扱う。
サイトでの見せ方
主役は顧客課題と顧客価値。Formulaは「なぜPortXがそれを可能にするのか」の裏付け。ツール売りに見せない。
市場への入り方
broad vision × narrow entry。在庫・受注配車・納期回答など、顧客が強く自分事化できるnarrow wedgeから入る。
Formulaの表現
情シスがSaaS導入時と同等の関与度で、自社要件に完全にmeetしたシステムを導入できること。