非エンジニアで、いつの間にかソフトウェアエンジニア向けのコンポーネント業界で仕事をしている私です。国内外の優秀なソフトウェアエンジニアの方と仕事でお付き合いし、一緒に働き、その「ソフトウェアが世界を回している」という自負や「最後はクリエイティブな人間はすごい」という人間賛歌に惚れ込んでしまっております。非エンジニアのマネージャがエンジニアチームと上手くやる方法みたいな記事をちょっと昔に書いたりしました。

ということでソフトウェアエンジニア向けの開発コンポーネントを提供しているわけですが、エンジニアさん・開発者さんがビジネス側との軋轢で苦労されているなと思うところがあります。そんな軋轢に対して、ソフトウェア提供元が適切な情報提供を行い、軋轢を回避してもらうサポートをすることもDevRel の大事な側面だと思い始めました。もしソフトウェアで世界を動かしたいと思うなら、先に進んだソフトウェアがビジネス側に与える歪を乗り越えることが必要なのです。

ちょっと弊社のドメインであるWeb API・データ連携を例にこのテーマを考えてみました。本記事はDevRel Advent Calendar 2020 の20日目の記事です。

メディアの煽るバズワードと技術情報の中間の情報提供

ガートナーのテクノロジーのハイプサイクルってご存じですよね。テクノロジーは、出てきたときに期待がわっと過度に上昇して、その後実際に定着して広く実利用される前に幻滅の谷を経験するというもの。

これはある程度自然なんですが、実はメディアやベンダーが煽っていてその過度な期待を高くしている面があります。いわゆるバズワードというやつです。少し前のAI、なんでも自動化できるRPA、今のデジタルトランスフォーメーション（DX）みたいなもの。我々の業界でも「API」「API エコノミー」というワードが流行っていました。なにやらAPI を公開すると、飛行機と家のドアと会社のシステムがつながって無限にビジネスが広がりますよ、という絵を見たことはありませんか？期待してしまいますが、現実に自社のアプリと飛行機と家のドアが関係ありますか？

実はこれは、決済はロケーションなどの汎用的な機能のAPI ファーストなAPI と業務アプリのデータアクセスのためのデータAPI がごっちゃにされているだけで。業務アプリのデータAPI 公開により新規にAPI だけを利用する顧客を獲得できるという話ではなさそうです。でも、ただAPI の機能をURIとか4つのメソッドとかセキュリティの話をされても非テックなビジネス側には伝わりません。技術情報の後に伝えるべき情報はその中間の情報です。API 公開で言えば、API 公開やその後に目指すべきは地道なBI、ETL ツールやExcel との連携、業務の前後の他のSaaS との連携や、ユーザーの基幹システムとのデータ統合のサポートといった情報です。飛行機や家のドアとつながる可能性からは下がりますが、基幹システムに連携したSaaS は大きく解約率が下がるので、LTV を大きく向上させることができます。

このようにメディアやベンダーが煽り立てているバズワードに乗っかり過度な期待で儲けようとするよりも、何が過度で何が現実的なのかをベンダー側でも見切り、それを言語化してユーザーであるエンジニアに伝えることが良いと思います。言語化してあげることでエンジニアは自社内で正しくビジネス側とコミュニケーションができ、社内の信頼を得ることができるでしょう。

導入した場合に起こりえる軋轢を先読みして、エンジニアをサポート

DX とは言わずとも、良い開発ソリューションを使った、一気に10倍ぐらい企業のソフトウェアの開発が進みます。ソフトウェア側が進めば、社内の他の部署はびっくりしてしまいます。なぜかというとビジネスを考える経営層、ソフトウェアを扱う社内ユーザー、ソフトウェア企業なら販売する営業やマーケは、従来のペースに慣れており、ソフトウェア側の急な加速について来れないからです。

一つの例としては、弊社が提供しているドライバー製品をBI やETL ベンダーに導入していただくと今までオンプレのDB やCSV だけにしか対応していなかったツールが数十・数百のSaaS データに対応できます。もしくは年に2-3個の新規データソースに対応していたものが急に対応データソースが増えます。ところが「データソースが増えたら、営業がフォローしきれない」という声が聞こえることがあります。これは、新しいソフトウェアがロングテールなクラウドデータ対応をしているにも関わらず、営業やマーケティングで人的リソースをまんべんなく丁寧に振り分けてしまっては破綻するからです。

弊社では、製品のユーザー側のエンジニアからビジネスサイドを動かせるようにこう言った軋轢を言語化し、解決策を示すような記事を書いています：

ロングテールなSaaS 連携は足で売らずにWeb で売る～営業の現実と製品サイドのギャップを埋めるCData OEM サポート

テクハラに注意して、ビジネスの人をエンジニア側にじわじわと取り込むメニューを用意

エンジニアというペルソナを相手にする場合、ある程度共通した性質がありますね。そこに対して、いろいろな施策を打っていきます。トライアルまでの時間やハードルを短くすること、サンプルやドキュメントを充実させること、テクニカルサポートを充実させること、製品が早いタイミングで改良されていくこと。しかし、「Dev だから、エンジニアだから」と言いすぎることは、非テックな人にはなにやらドヤられているようで、少し鼻につきます。ソフトウェアが、エンジニアがビジネスを動かそうとすればするほど、テックじゃない人がいじめられているように感じる「テクハラ（？）」を感じることが増えてしまいます。では、ソフトウェアが世界を動かすべきではないかというとそうではありません。解決策はテックをハラスメントにせずに、今まで非テックだと感じていた人をテックの世界に取り込むことがベストではないでしょうか？

そう、テックが世界を支配するためには、一旦優位に立ったからには非テックと和する必要があります。

やり方は、テックな製品を手で触ってもらうこと、に尽きます。とにかくハードルを下げて「自分にもできる。しかもやってみたら便利」という喜びを味わってもらうしかありません。そのために、ベンダーは自社の製品が技術的に難しくても、非テックな人でも扱えるお試しメニューを用意することは重要です。テックな製品のユーザーであるエンジニアが社内に持ち帰って、非テックな人たちにその製品の良さを感じてもらえるように。

ただし、一つだけ気を付けるのは、非テックな人がテクノロジーを試すときにいきなりレベルをあげたりしないことです。手を動かせばいいし、必要なら手助けをしましょう。そこで急に高いレベルを求めたり、ググれ、なんて言おうものならテクハラです。例えば、家事の得意じゃない人がたまに家で料理を作ったり掃除をしたりしたときにパートナーに「そうじゃない。なんでアンタはこんなこともできないの？よけいなことばかりして！」なんて言われたらいやじゃないですか。それでやる気をなくしてはお互いに損をします。テックに入ってきたことに感謝して、褒める！そしてサポートする！

最終的には非テックな人をテックに上手に引きずり込むのがDevRel の究極ではないでしょうか？それを本質的なデジタルトランスフォーメーション（DX）と呼ぶのです。