本記事は『ソリューションエンジニアの教科書』の「Chapter 1 ソリューションエンジニアリングとは」から一部を抜粋したものです。掲載にあたって編集しています。
買うことは売ることより難しい
課題解決策の組み立て
「ソリューションエンジニア」や「セールスエンジニア」といった職種を、LinkedInなどのビジネスSNSを通じた求人媒体でよく目にするようになりました。
元々は外資系ベンダで一般的なタイトルでしたが、最近では日本電気（NEC）やKDDIをはじめとした日本のサービスプロバイダでも募集されている職種になってきました。こうした動きは、それだけ技術的なバックグラウンドをビジネス開発に活かせる人材が市場に求められている証だと感じています。
根本的な課題を探り当てて解決策を組み立てる
昨今はデジタルテクノロジの進化に伴い顧客の課題も複雑化し、課題を分解・構造化することが困難になってきています。結果、自社内の人員だけで自社の課題を深く理解することが難しくなってきました。
自社内の人員も、Z世代と呼ばれる多様な考え方や価値観を持った世代が台頭してきて、これまでの慣習や過去の成功にすがっていては、組織としての合意形成には至りません。
こうしたことを背景に、目や耳に入る表面的な事象をより多角的に捉えながら、課題の本質を突き詰めることが顧客にとって重要になってきました。多角的に捉えるためには特定領域の専門性と顧客に対する理解が不可欠です。
ソリューションエンジニアリングとは、顧客の根本的な課題を探り当てて解決策を組み立てることとここでは定義します。
課題を解決できることが前提
「ITの所有から利用へ」が謳われ始めて十数年が経過し、SaaSを筆頭に○○ソリューションと呼ばれるITサービスが雨後の筍のごとく誕生するようになってきました。
これらのサービスには一般消費財と本質的には変わらない差別化が困難なもの（例：クラウドストレージ、Web会議システム）から、ある特定のビジネス領域に特化した鋭利なものまで（例：データセキュリティポスチャマネジメント）、様々なものが存在します。
どのようなカテゴリのソリューションであっても、顧客の課題を解決できて初めてソリューションと呼べることには違いありません。顧客の課題を解決できなければそれはソリューションではなく、ただのテクノロジサービスです。
セキュリティソリューションの例
ここで顧客の課題を改めて掘り下げてみます。顧客の課題とは経営層が抱えるものから現場レベルの技術課題まで様々です。業種や業態、事業の成熟度や規模によって、各々の課題も細分化されます。
経営層になれば、売上や利益目標を達成して株主の期待に応えなければなりません。しかし、現実には人・物・金の質と量が潤沢でなく、同業他社との差別化も困難で、目標を達成するための見通しが立たないといった課題があるでしょう。
現場レベルであれば、例えば利用しているセキュリティツールが多過ぎて運用コストが高くなり、自社の資産を守るといった本来の目的を遂行することが困難になっているといった課題が存在します。
この課題は、例えば、クラウドセキュリティポスチャマネジメントと呼ばれるSaaSソリューションを導入することで、複数のセキュリティツールの乱立による運用負荷の高騰を解決できるケースがあります。これは顧客の具体的な課題を解決するソリューションと言えます。
課題とは放置しておくと損失に繋がること
ここでは、顧客の課題を、経営層や現場レベルといった区分けはなく、放置しておくと組織としての損失に繋がることと定義します。個々の部門や個人で持っている悩みや希望があったとしても、それらが明確な損失に繋がることが証明できないのであれば、課題とは言えません。
クラウド運用チームの例
例えばクラウド運用チームが、自社が利用しているクラウド環境でどんな資産を管理しているかを把握できていなくて困っているとします。資産を把握できないとどんな脅威にさらされているのか予測することすらできない、といった課題を抱えているはずです。
ITテクノロジに感度が低い経営層からしたら、安易に「そんなの人手で調べてExcelにまとめればよいのでは」といったソリューションを思いつくかもしれませんが、クラウド環境で管理される資産はダイナミックに変化するため人手で調べることは至難の業です。
セキュリティチームの例
サイバー攻撃の驚異も深刻な問題です。サイバー犯罪者は企業の重要資産を不正に搾取し、それらを闇市場で販売したり相手企業を脅迫したりして金銭的な利益を得ることを目的にしています。
自社が利用しているクラウド環境上にどんな資産が管理されていて、日々どんな攻撃を受ける可能性があるのか、または既に攻撃を受けているのかといったことを把握できていないと、適切な対策を打つことはできません。その結果、サイバーセキュリティの事故に遭う確率は格段に高くなることは想像に難くありません。
これがランサムウェアのような悪質な事故であれば、被害額は天文学的な数字にのぼるはずです。この例は典型的なセキュリティチームの課題と言えます。
課題発掘が全ての出発点
先に、課題を解決できることがソリューションの前提であると述べました。つまり、課題発掘が全ての出発点になると言えます。
しかしながら、顧客はある特定領域の専門性を持っているわけではありません。例えばサイバーセキュリティの領域では、サイバーセキュリティフレームワークのような、攻撃者から自社の資産を守るために各フェーズで検討すべきテーマを体系化した枠組みがあります。
多くの顧客はこういった枠組みや考え方に対する知見が乏しく、何が自社の課題なのかを深く理解してそれらの解決策を体系化することができずに困っているケースがほとんどです。
端的な言葉で表現する
人は誰しも各々が異なる事情や悩みを抱えています。顧客も大なり小なり人の集まりのため、顧客各々が異なる事情や悩みを抱えているはずです。
また、表現方法や他人への伝達方法は人によって様々です。十数年前まではEmailやPowerPoint、Wordといったツールを使って、文章や図表を用いて自分の考えを他人に伝えながら、相手に何らかの行動を促すことが一般的でした。SNS全盛の昨今ではSlackのようなチャットツールやnoteのようなブログプラットフォームを利用して、自分の考えを短い文章で表現できるようになりました。
いずれのツールやプラットフォームを利用するにせよ、誰が見たり聞いたりしても誤解が発生しない端的な言葉で表現することが大切です。
先に述べたとおり、顧客はある特定領域の専門性を持っているわけではありません。顧客によっては、自社の重要資産を把握すること（サイバーセキュリティフレームワークの「識別」）が策を決めるための出発点であることを理解せず、闇雲にソリューションを探すかもしれません。
「エンドポイントセキュリティソリューションを導入しようと考えています。御社のSaaSソリューションにはエンドポイントのメモリを保護する機能はありますか？」といった、唐突な質問を投げてくる顧客も少なくありません。
「エンドポイントのメモリを保護する機能」だけでは、サーバやコンテナの仮想メモリ空間の暗号化のことなのか、ファイルレスマルウェアの検出のことなのかどちらにも取れてしまいます。各々の意味合いは全く異なります。
唐突な言葉を一つ一つ紐解いて、顧客の真意を表す意味のある言葉で表現することが課題発掘の第一歩です。顧客の言葉だけでなく、顧客の表情や仕草に正面から向き合いながら、端的な言葉で表現して双方の共通言語としてまとめることは、ソリューションエンジニアの重要な責務の一つです。
原因を探る
顧客の悩みを端的な言葉で表現して双方にとっての共通言語ができたら、次のステップはその悩みの原因を探ることです。
全ての物事には原因があります。根本的な原因を探ることなく、表面的な事柄をもとに解決策を模索したとしても、根本的な解決策にはなりません。『完訳 7つの習慣 人格主義の回復』で謳われている、「処方する前に診断する」と同じ発想です。患者さんの症状ではなくなぜそのような症状が発症しているのか？を探ることで、適切な処方ができます。
顧客がWebで公開している外部情報を事前に調査して、悩みの背景や原因と思われることを自分自身の仮説としてまとめておいて、その仮説をもとに顧客に質問をしながら根本原因を探ります。
根本的と思われる要因が特定できたら、初めに作った双方にとっての共通言語を修正します。この作業を繰り返すことで共通言語の質が向上してより本質的な課題に着目できるようになります。
この時点では、どのようにやるか？は一旦置いておくことがポイントです。顧客は誰しも自社にとっての最適解を探しています。特にある特定領域の専門性を持っていない人や組織は、一足飛びに自分の都合のよい見解や結論を持ち出す傾向があるので、注意が必要です。
影響を定義
顧客の悩みの根本的な原因を探ることができて、双方にとっての共通言語をより意味のあるものに修正できたら、その悩みを放置した場合の影響を定義します。
先に、課題とは放置しておくと組織としての損失に繋がることと定義しました。仮に顧客の根本的な課題を探り当てることができたとしても、その課題を解決しなければならない明確な理由付けができなければベンダのビジネスにはなりません。
顧客は自社にとって利点がないことに時間も労力もお金も割くことはないため、課題を放置した場合の負の影響をより具体的に定義することが大切です。定量化できれば尚良しです。図1は顧客の課題・原因・影響の例です。
課題の解決策を検討する
課題・原因・影響を端的な言葉で文書化できたら、自社のSaaSソリューションでその課題を解決できるかどうかを精査します。課題・原因・影響が明確になっても、自社のSaaSソリューションで解決できなければ顧客にとってはソリューションになりません。
一般的に課題を解決するための策はSaaSソリューション以外にもあって、コンサルティングファームを含むサービスプロバイダは、特定のSaaSソリューションに依存しない課題解決策を提案するケースがあるかと思います。
ここではソリューションエンジニアが取り扱うソリューションはSaaSソリューションと定義しているため、ここで検討する策はSaaSソリューションに限定します。
ユースケースを把握する
ソリューションエンジニアにとって大切なことは、自社のSaaSソリューションのユースケースを正確に把握しておくことです。ユースケースとは、顧客が日々経験する実際のビジネスシーンにおいて、どんな活用方法があるのかを顧客目線で定義した活用例です。
自社のSaaSソリューションが提供するユースケースと、発掘した顧客の課題を突き合わせて、それらの課題をどのユースケースで解決できるかを精査します。
精査の結果、顧客の課題や探しているビジョンと細かなギャップはあるものの、ユースケースに該当して概ね解決できると判断したら、デモや実証実験で具体的な課題解決の方法を顧客と共有します。図2はクラウドネイティブアプリケーションプロテクションプラットフォーム（CNAPP）のユースケースです。
ユースケースはほぼ無限
現時点で、私はサイバーセキュリティソリューションのSaaSベンダに所属していて、業界や同業の動向はLinkedInを中心とした各種SNSやメディアで得ています。私が現在LinkedInでフォローしているサイバーセキュリティ関連企業は800社以上あります。
個々のベンダが持つSaaSソリューションは複数のユースケースを持つことがほとんどで、ユースケースは膨大な数になります。SaaSソリューションは日々新しい機能が開発されてはリリースされることを繰り返すため、顧客から見たユースケースはほぼ無限と言っても過言ではありません。
サイバーセキュリティの市場だけでもクラウドセキュリティ、エンドポイントセキュリティ、ネットワークセキュリティ、アイデンティティセキュリティ、アプリケーションセキュリティ、データセキュリティなど、ありとあらゆるカテゴリが日進月歩の速さで生まれています。
つまり、顧客から見たら同一領域だけでこれだけのソリューションの選択肢が存在するということです。これだけの膨大な選択肢から、特定領域の専門家でない顧客が自社にとってのベストなソリューションを選定することは至難の業です。
顧客は信頼できる理由を探している
顧客が自社にとって必要なユースケースを理解して、それらのユースケースを実現できる最適なソリューションを選定して買うこと。これは売り手が見込み顧客に売ることよりはるかに難しいことと言えるのではないでしょうか。
ベンダが自社のソリューションが最も素晴らしいことを謳った競合ソリューションとの比較資料を持ち出して、顧客に自社のソリューションの契約を促すシーンは、実際のセールスの現場でよく見られる光景です。私はこのアプローチ自体は否定しませんが、これは多くの顧客にとってあまり重要なことではないかと考えています。
顧客は、ソリューションの差別化要因よりも、ベンダやサービスプロバイダを信頼できる理由を探しているからです。信頼できるかできないかの要素は、個々の顧客によって異なりますが、相手の課題に向き合う姿勢や態度は、多くの顧客にとって、信頼できるか否かを判断する共通の要素かと思います。
自社のソリューションが最も素晴らしいと述べるのは当たり前のことで、当たり前のことを謳っていても、顧客の信頼を失うだけです。
自社が顧客の課題を最も深く広く理解している、その課題に適したソリューションを提供することができる、要件に対する細かなギャップはあるがサービスプロバイダと共同でそのギャップを埋める策を準備している。このようなアプローチを取ることで、顧客の信頼を勝ち取ることができるのではないでしょうか。
ソフトウェア開発とセールスの共通点
相手の期待に応える
ソフトウェア開発のプロジェクトで最初に行うことは、最終的なエンドユーザがどんなペルソナで何を求めているのかを調査して、調査結果をもとに開発プロジェクトの全体像をイメージすることです。
全体像をイメージできたらプロトタイプ案をまとめて、実装するために必要なエンジニアリングリソースや期日を整理して、各スプリントで実施するタスクを決定します。
セールスのプロジェクトも同様で、最初に行うことはどんな業種や特性の顧客に注力するのかを、営業担当者をはじめ関係者間でディスカッションしながら決定することです。
サイバーセキュリティSaaSの例
サイバーセキュリティSaaSソリューションであれば、直近の数年で甚大なインシデントを経験してしまった顧客は感度が高く、関連するSaaSソリューションへの積極的投資を検討しているケースが考えられます。このような特性を持つ顧客は、注力する対象になります。
また昨今ではランサムウェアと呼ばれる、悪質なマルウェアの事故も増えてきています。これは顧客の重要資産を、悪意を持って暗号化して、復号のために多額の金銭支払いを要求するというものです。
ランサムウェアによるインシデントを経験してしまった顧客は、マイクロセグメンテーションのような、仮にランサムウェアのインシデントが起きてしまっても被害を最小化できるソリューションを期待していると思われます。
このように、ソフトウェア開発とセールスの最も端的な共通点は、相手の期待に応えることだと言えます。期待に応えるためには具体的に何をなぜ期待しているのか、相手の状況をできるだけ広くかつ素早く理解することが大切です。
ゴールから考える
私がソフトウェアエンジニアリングに携わり始めた駆け出しの頃は、同じプロジェクトチームの先輩の助言や実際に作成されたコードをもとに、見様見真似で開発作業に没頭していました。当時は現在のようなリモートワークはできなかったため、毎日オフィスに出社して、朝から晩までPCに向かって格闘していた記憶があります。
作業に没頭する中でふと、「この開発作業っていったい何のためにやっているのかなぁ？ そもそもこのソフトウェア開発プロジェクトのゴールって何だっけ？」と疑問に思うことがよくありました。
ソフトウェア開発だけでなく、何らかの作業に没頭し過ぎてしまうと本来の目的を見失ってしまうことがあるかもしれません。この節では『地頭力を鍛える』で提唱されている「結論から」「全体から」「単純に」の、「結論から」に倣って、ゴールから考えるアプローチを掘り下げてみたいと思います。
ゴールから考えることで無駄を省くことができる
ソフトウェア開発の根源的なゴールは、ソフトウェアで実装された機能を約束した期日までにリリースすることです。これはいかなる開発プロジェクトでも同じです。
セールスのゴールは、特定の期間に決められた売上や利益の目標値を期間内に達成することです。目標値は期が始まる前に株主やその他の関係者間で合意決定しています。
ソフトウェア開発のゴールと根本的には変わりません。ソフトウェア開発でも、実装する具体的な機能や期日を常に意識して開発作業を計画／実行しないと、ゴール達成と直接関係のない無駄な作業に時間と労力を割いてしまう可能性が高くなります。
これはセールスでも同じです。目標値に対して絶対的なパイプラインの数が足りていないときでも、個人的な関係性だけを頼りに知り合いの顧客とのミーティングを重ねて商談化を狙う営業担当者は多いかもしれません。私はこのアプローチ自体は賛成です。人と人の関係はとても大切だからです。
ただし、絶対的なパイプラインの数を増やすことはゴール達成には不可欠です。知り合いの顧客とのミーティングに注力するより、不特定多数の全く知らない見込み顧客層に向かって、事例紹介のEmailを一斉送信したりする方が得策です。
最近では、見込み顧客の詳細な職務経歴や持っている興味、Emailアドレスなどの個人情報を確認できる、LinkedIn Sales Navigatorのような便利なツールを利用することで効率化を図ることも可能です（図3）。個人の関係に極端に頼ってしまうのは、自分の過去の経験を美化し過ぎていると考えられます。
ゴール達成の阻害要因を予め洗い出す
営業担当者は、現在の商談パイプラインの中に、下記の事項に該当するパイプラインがどれだけあるかを把握します。
- 見込み顧客の課題が明確で意思決定者が課題を認めている
- ○○までに実証実験を終わらせて実証実験が成功したら、月額□□万円の発注を△△までに行うことを顧客と書面で合意している
一般的には、目標値に対して3倍のパイプラインが必要と言われています。この場合、上記に該当するパイプラインが目標値に対して3倍あれば安全と考えてよいということになります。
ソリューションエンジニアは、「実証実験が成功したら」に着目すべきです。仮に100%失敗しそう、または部分的には達成できそうだけど重要なポイントが達成できそうにない場合、営業担当者のゴール達成へのシナリオが崩れてしまいます。
例えば、「2件以上のランサムウェアを検出すること」が実証実験の成功基準の一つになっているとします。先に述べたとおり、ランサムウェアは顧客の重要資産を悪意を持って暗号化し、復号と引き換えに多額の金銭支払いを要求するマルウェアです。被害は拡大しているものの、実証実験の期間内かつ商談相手の顧客側でランサムウェアを検出する確率は低いです。
このような場合は、成功基準を「2件以上のマルウェアを検出すること」と修正します。「マルウェア」とすれば、影響は比較的軽微かつよく感染しているウォームやトロジャンも含まれるため、検出の可能性が高くなります。
ソフトウェア開発でも、ビジネスロジックを実装する前にテストコードを実装することで、ビルドやリリースなど、後続のフェーズに進む前に潜在的なバグを潰すことができると思います。考え方はセールスでも同じです。
