J.B.Goode .Accountの職種についてご紹介します。
一般には営業・セールスと呼ばれるポジションです。
この仕事を人に説明するとき、いつも少し困ります。
「システム開発の営業です」と言うと、
たいてい「エンジニアじゃないんですか?」か「じゃあ売り込みの人ですね」のどちらかの反応が返ってくる。
どちらも半分くらいは当たっていて、でもどちらも本質ではない。
売る「モノ」がない営業
私たち受託開発の営業には、カタログがありません。
車のディーラーなら、目の前に車がある。SaaSの営業なら、機能一覧とプランと料金表がある。
でも受託開発の商談が始まる時点で、「売るもの」はこの世に存在していません。これから一緒に決めて、これから一緒に作るものだからです。
だから最初の商談で「弊社のサービスは……」と話し始めることは、ほとんどありません。代わりにやるのは、ひたすら聞くことです。
- なぜ今、システムを作ろう（あるいは作り直そう）と思ったのか
- その背景にある事業の状況はどうなっているのか
- 現場では誰が、何に困っているのか
- 経営としては、どこに数字のインパクトを期待しているのか
「在庫管理システムを作りたい」という依頼の裏には、「欠品が多くて機会損失が出ている」という事業課題があり、さらにその奥には「拠点が増えて、属人的な勘での発注が回らなくなった」という経営の変化があります。営業が最初にやるのは、その一番奥にある課題まで降りていくことです。
ここを浅く済ませると、あとで必ず痛い目を見ます。表面のオーダーどおりに作ったものが、納品後に「思っていたのと違う」となる。受託開発における失敗の多くは、コードの品質ではなく、この最初の解像度の低さから生まれます。
まず与える、という順番
J.B.Goodeには「算用」という指針があります。算用とは本来、損得の計算のこと。それをあえて「損得を超えて、まず価値を提供する」という意味で使っています。Giveの精神、と言い換えてもいい。
営業の現場でこれが何を意味するかというと、契約前の段階で出し惜しみをしない、ということです。
ヒアリングで課題が見えてきたら、「うちに発注してもらえれば解決します」ではなく、その場で考えられる整理や選択肢を先に出す。場合によっては「それはシステムを作るより業務の順番を変えたほうが早いです」と、自社の売上にならない答えを返すこともあります。
一見、営業として損に見える。でも受託開発で長く付き合うクライアントは、例外なくこの段階で「この人たちは自分たちの課題を本気で考えてくれている」と感じてくれた相手です。順番は、先に価値、あとで対価。この順番を守れるかどうかが、受託開発の営業の信頼の土台になっています。
「解決へ導く」の主語は、営業ではない
課題が見えたら、次はそれをどう解決するかの設計です。
ここで大事なのは、営業がひとりで答えを出さないことです。私たちの仕事は「クライアントの経営・事業課題をヒアリングし、クリエイティブの力で解決へ導く」ことだと定義しています。主語はあくまで「クリエイティブの力」、つまり設計や開発を担うチームです。
営業がやるのは、現場で汲み取った市場のニーズや顧客の声を、チームが使える形に翻訳して渡すこと。「クライアントはこう言っていました」と議事録を転送するだけでは翻訳になりません。「この発言の背景にはこういう業務フローがあって、本当に痛いのはここだと思う」まで噛み砕いて、はじめてチームは良い提案を出せる。
逆方向もあります。エンジニアから「そこはLLMで自動化できる余地があります」「そのレガシー、全部作り直すより段階的に剥がすほうが安全です」といった技術的な選択肢が出てきたら、それをクライアントの言葉に戻して伝えるのも営業です。技術と事業のあいだで、両方向の通訳をし続ける。
この往復で意識しているのが、残りふたつの指針です。
ひとつは「始末」。シンプルに、という意味で使っています。クライアントの要望をそのまま積み上げると、システムはどんどん複雑になります。本当に必要なものだけに削ぎ落とし、シンプルな形で課題を解く。それができる提案は、作るのも、使うのも、あとで直すのも楽です。営業の翻訳が雑だと、この「削る」判断ができなくなります。
もうひとつは「才覚」。卓越したものを、という意味です。シンプルであることと、凡庸であることは違う。削ぎ落とした先に、チームの技術力でしか出せない解を置く。営業が現場の声を正確に届けるのは、チームがこの才覚を発揮するための前提条件でもあります。
課題と技術と市場の空気が混ざって、最初は誰も想定していなかった提案が立ち上がる瞬間。受託開発の営業をやっていて、いちばん面白いのはこの瞬間だと思っています。
受注はゴールではなく、「第一想起」への入口
見積を出し、提案が通り、契約する。ここで営業の仕事が終わる会社もあるかもしれませんが、受託開発ではむしろここからが本番です。
開発が始まれば、要件は変わります。クライアントの事業環境も動きます。「最初に聞いていた話と違う」は起こるものとして、そのたびに経営・事業の視点から「じゃあ今、何を優先すべきか」を一緒に判断する。プロジェクトマネージャーが工程を守り、営業が事業側の文脈を守る、という分業です。
そして納品後。システムは使われ始めてから本当の評価が決まります。運用に入って初めて見えてくる課題、次に着手すべき領域、事業の次のフェーズ。そこに継続して伴走できるかどうかで、「一度発注した会社」なのか「ビジネスパートナー」なのかが分かれます。
J.B.Goodeは「世界一のソフトウェア会社になる」というビジョンを掲げています。ただし、その基準は従業員数でも時価総額でもありません。クライアントがソフトウェアで何かを解決しようと思ったとき、最初に頭に浮かぶ存在になること。「第一想起」される会社になることです。
これは営業の仕事の目標そのものです。第一想起は広告で買えるものではなく、一件ごとの案件で「先に価値を出し、シンプルで卓越したものを届け、納品後も逃げなかった」という積み重ねの結果としてしか手に入らない。受注から継続的なリレーション構築までを担うというのは、この積み重ねの一番前に立つ、ということです。
ある案件の話
ある案件についてご紹介します。
無数の制約を満たしながら、一年間の予定を組み上げるシステム開発の案件です。別部門にはすでにシステム化されていたが、この部門の予定は担当の方が手で組んでいた。毎年数週間かけてベストな一案を作成していた。
最初のオーダーは「システム化した上で、AIを使って、作成を簡単にしたい」。ここで言うAIは、ChatGPTやGeminiのようなLLMのことでした。
ただ、聞いていくと違う話が出てきます。予定には会場の空き、移動の負担、連続日数の上限…といったルールが三十近くあり、それを同時に満たす組み合わせは数十億通り。担当の方が欲しかったのは「AIが作った予定」そのものではなく、手組みでは無理な回数の試行を、AIの力で回せることでした。
社内のエンジニアとは、この話は最初から噛み合っていました。数十億通りから条件を満たす組み合わせを探すのは、LLMに頼む話ではなく、そのためのアルゴリズムを構築する話です。LLMは、条件を変えて何パターンも回し、結果を比べる反復のほうで使う。答えを出す道具ではなく、人が選ぶための試行回数を増やす道具です。
ズレていたのは技術ではなく、先方の「AI」という言葉と中身でした。営業がやったのは、その二つをつなぎ直すことです。
一つ正直に書くと、最終的に先方の稟議を通す段では「AIを使っている」という建前がやはり必要でした。既存システムを作り直す予算には、その一言が要る。私たちはそれを否定せず、中身を正しく伝えたうえで、その言葉が嘘にならない提案に仕上げました。
オーダーの言葉と、その奥にある要望は、同じ形をしているとは限らない。この案件でそれを改めて教わりました。
社内外を巻き込む、という仕事
改めて整理すると、受託開発の営業がやっていることはこうなります。
- クライアントの経営・事業課題を、表面のオーダーの奥まで聞き取る
- 契約の前から、まず価値を出す（算用）
- 現場の声を開発チームに翻訳し、技術の選択肢を事業の言葉に戻す
- シンプルで卓越した解を、チームと一緒に組み立てる（始末・才覚）
- 受注後も事業側の文脈を守り、納品後も伴走して次の価値をつくる
どの工程も、ひとりでは完結しません。クライアントの経営層と現場、社内のエンジニアやデザイナー、場合によっては協力会社。社内外の人たちを巻き込んで、ひとつのビジネスを前に進める。だからこの仕事は「売り込みの人」でも「エンジニアの手前にいる窓口」でもなく、事業を成長させる核心的なポジションなのだと思っています。
最後に
「営業」という言葉のイメージと、受託開発の営業の実態は、かなり離れています。売るのはモノではなく、まだ形のない未来。相手にするのは購買担当ではなく、事業そのもの。武器は話術ではなく、聞く力と、聞いたものを一枚の絵にする力。そして、先に与える姿勢。
受託開発の営業は、売る仕事ではありません。クライアントと一緒に「こうなったらいい」というビジョンを描き、それをチームの力で現実にしていく仕事です。この面白さが少しでも伝わったなら、うれしいです。
■ 営業の仕事に、立ち止まっている方へ
「売ることには慣れた。でも、クライアントの未来を描けているだろうか」「良い絵が見えても、それを形にする力が社内になくて、結局は無難な着地になる」。そんな感覚を持ったことがあるなら、私たちと一度話してみてください。
J.B.Goodeの営業は、売る仕事ではなく、ビジョンを描く仕事です。クライアントの課題の奥にある「叶えたい未来」を一緒に見つけ、それを提案という一枚の絵にする。そして、ここには描いた絵をそのまま現実にできる実現力のあるクリエイターが揃っています。AI/LLMもレガシー刷新も分散システムも、あなたの提案に技術が追いつかない、ということがない。だから遠慮なく、大きな絵を描けます。
スマートな面接ではなく、お互いが「どんな未来を描きたいか」を語り合う時間にしたいと思っています。
■ 制作・開発のご相談をご検討の方へ
「AIを使って何かしたいが、現場の泥臭い課題が解決できない」「型にはまったコーポレートサイトやシステムに限界を感じている」「そもそも何を作るべきかまだ決まっていない」。御社の『消えない付箋』を、ぜひ私たちに教えてください。この記事に書いたとおり、まず聞くところから始めます。