Less is more!

Less is more. エンジニアリングに携わっている方は、この言葉を聞いたり見たりしたことがあるかと思います。日本語に訳すと少ないほうが豊かになるかと。

私もこの言葉を強く信じていて、著書のChapter4ではこの言葉を背景にした内容を随所に述べています。

ソリューションエンジニアの教科書

この記事では、私が何故、ソリューションエンジニアリングにおいてLess is moreが大切と唱えているのかをまとめています。

私は、ソリューションエンジニアリングとは、顧客の根本的な課題を探り当てて解決策を組み立てることと、かつ決められた期間内にビジネスをクローズすること理解しています。

これらの活動を阻む最も大きな活動の1つに、技術論争があるかと考えています。技術論争とは、ある特的にテーマについて、顧客側・ベンダ側が熱く議論することです。

生成AIにような一般的に注目されているトピックスになると、積極的に勉強している人も多く、かつ正確に理解されていない技術的な要素が多いため、技術論争になり易いのではと推測しています。

技術論争そのものは、議論に参加することで、自身の理解が不足したり間違って理解していたりすることに気づくことができるため、良い活動かと思います。

一般的に技術論争は、複数人が参加して長い時間をかけて行う活動になります。テーマによっては数ヶ月以上続くことも珍しくないかと。

ソリューションエンジニアリングの定義を再度確認してみます。

顧客の根本的な課題を探り当てて解決策を組み立てることと、かつ決められた期間内にビジネスをクローズすること

数ヶ月以上も延々と続く技術論争を行っていては、決められた期間内にビジネスをクローズすることが難しくなります。

技術論争はお客様の根本的な課題の掘り起こしとは無関係につき、これらを継続していても根本的な課題の掘り起こしにはならないですね。

人な何かと詳細を必要以上に知りたくなるかと思います。ソフトウェアエンジアやセキュリティアナリスト等、何らかのエンジニアリングを生業にしている人はその傾向が顕著かもしれません。

商談の早い段階で技術論争に突入していては、次から次へと技術的な興味をそそるテーマが勃発してしまし、"あれも知りたいこれも知りたい"　といった感情を引き起こしてしまい、ソリューションエンジニアリングのゴールを達成することが困難になってしまいます。

技術論争になりそうなサインとそれらを回避するための会話例です。顧客は、商談の決定権を持っていないセキュリティエンジニアを想定しています。

顧客：貴社のセキュリティ分析SaaSと、SplunkやCloud Trail等が持つ各種テレメトリーの情報はAPIで連携しているのですか?  認可の仕組みを詳細に教えて下さい

ベンダ：ご質問ありがとうございます。ご認識のとおりAPIで連携しているものもあります。連携するテレメトリーによってはAPI以外での連携もサポートしています。

顧客：なるほど。詳細な仕組みはどのようになっているのですか？認可の仕組みが気になっているのですが。

ベンダ：了解しました。差し支えなければ、認可の仕組み詳細が気になっている背景をお伺いしてもよろしいでしょうか？

顧客：(やや困った様子で)いや、特に背景と言えるほどのことは無くて。たまたま最近OAuthを勉強していて、APIは認可の仕組みが大切だと思っていて。

ベンダ：お答えい頂きありがとうございます。承知しました。弊社のセキュリティ分析SaaSの認可詳細の仕組みについては、製品の機密情報に関わる内容につき、現時点では開示を控えさせて下さい。認可の仕組み以外で、困っていることやお悩みをお教え頂けないでしょうか？

顧客：了解しました。(まあ確かに詳細は今関係ないか)　困っていることですねぇ。(別にないかなぁ。SPLが複雑過ぎて勉強が大変ってぐらいかなぁ)

この例では、"製品の機密情報"といった言葉を使って、相手の課題解決に認可の詳細な仕組みは無関係であることを伝えて、"他に困っていることは？"と投げかけて、会話の焦点を課題発掘にシフトしていますね。

Less is more. ソリューションエンジニアリングの過程で相手に伝える情報は必要最小限にして、相手の課題発掘に焦点を当てる　これが鉄則です。