Reproでエンジニアをしている下村です。
自分はずっとプログラマとしてやってきました。最近はPdM的な動きも増えましたが、今でも機能の設計をして、コードを書いて、レビューもする、いわゆる現場のエンジニアです。
そんな自分が、この1年ほど「商談」に出るようになりました。Reproの導入を検討されているお客さんとの打ち合わせに、開発側の人間として同席する、あれです。最初は「エンジニアが商談に?」と自分でも思っていたのですが、実際に出てみると、これがエンジニアにとってかなり価値のある体験でした。この記事では、なぜ今エンジニアが商談に出る意味があるのか、そして出てみて何を得たのかを書いていきます。
なぜ「今」なのか
まず、なぜ「今」この話をするのか、というところから。
コードを書くこと、ものを作ること自体は、AIによってどんどん安価になってきています。作ること自体は、かなりの部分がコモディティ化してきたのではないでしょうか。極端に言えば、作るだけならAIのおかげでどうにでもなる時代になりつつあります。
そうなると、相対的に価値が上がるのは「たくさん作ること」ではなく「何を作るかを決めること」なのかなと思っています。お客さんにとって価値のないものをいくら大量に作っても仕方がありません。作るコストが下がったぶん、"何を作るか"の意思決定こそがボトルネックになってくる、という感覚があります。
そして、その"何を作るか"を判断するための一次情報は、商談の現場にありました。だから今、エンジニアが商談に出る意味があるのではないか、というのがこの記事で一番お伝えしたいことです。
また、必要なものを作ったところで実際には使われないとか導入できないなんてこともあると思います。そのような状況がなぜ起きるのか、そこを突破するために必要なものが何なのかを見極めるのも一次情報から得られることだったりします。
なぜ出るようになったのか
端的には、現場で本当に必要なものを理解するためです。
きっかけは、自分が主導してメール配信という機能を作ったことでした。Reproはマーケティングオートメーションツールとして、エンドユーザーに対してメールを配信することができます。その機能の導入まわりで技術的な支援が必要になり、お客さんとの打ち合わせに呼ばれるようになった、というのが始まりです。要はプリセールスみたいな立ち位置です。特にtoBでは機能がリリースされたからといって必ずしも自然に使ってもらえるわけではありません。使えるような状態にするための導入までのサポートが重要だったりします。
ただ、呼ばれて受け身で出ていたわけではなく、自分から出たいと思った理由もありました。それが「作った機能が、現場で本当に求められているものと合っているのか」を知りたかったのです。機能開発のフィードバックを、人づてではなく一次情報として、自分の目と耳で取りにいきたい、と考えていました。
出ていた場は、Reproの導入を検討されているお客さんとの打ち合わせです。自分が主に開発している機能の説明やメリット、導入の手順、そして導入にあたっての不安点や疑問点にお答えする、という役割で参加していました。
出てみて何が起きたか
実際に出てみると、想像とはだいぶ違うことが起きました。特に印象的だった3つを書いていきます。
お客さんは「機能」じゃなくて「ユースケース」で会話する
これが一番の発見でした。
エンジニアは、つい機能の説明を準備してしまいます。「この機能はこういう風に使えてですね...」と。ところが、お客さんは機能の使い方のような説明をそこまで求めていません。求められることもあるのですが、本質的には、お客さんは機能で会話しないのです。ユースケースで会話します。
たとえば「この機能はどうつかうんですか？」と聞かれはしませんが、代わりに「こういうことがしたいんですけど」と、やりたいことを話されます。お客さんは、Reproにこういう機能があるということを把握したうえでさらに機能の使い方について尋ねているわけではないのですよね。自分たちの現場でやりたいことがまずあって、それをどう実現できるかを知りたい、という順番です。
ですから、こちらの仕事は機能を並べることや、機能の紹介ではありませんでした。「それなら、今ある機能をこう組み合わせれば実現できます」と、お客さんのやりたいことを自分たちの機能に翻訳して返してあげることだったのです。
Reproのようなマーケティングオートメーションツールの場合、マーケティング活動を行うためのデータを用意することができるのか？が導入において重要な要素の1つになります。例えばメールアドレス。アプリやWebサイト、ECサイトで収集したデータを、メール配信を行うためにReproに連携するにはどういう経路で連携すべきか。メールアドレス変更が起こったときや購読/購読解除が発生したときはどのタイミング、頻度で連携するのか？など、考えるべきことはデータ1つでもたくさんあります。
そのような状況において、機能の説明をするのではなく、機能のライフサイクルやお客さんのシステムを鑑みたうえで実現方法を提案する。こういうことが求められるのです。
この視点は、機能を作る側にいると意外と抜け落ちがちなのではないでしょうか。自分たちは機能単位で世界を見ているけれど、お客さんはやりたいこと単位で世界を見ている。この非対称を体感できたのは、大きかったと思っています。
リアルなペインが発生する背景を得られる
要望や課題は、これまでも営業やCustomerSuccess経由で聞いていました。でも、人づてに届く情報と自分で得る情報とではやはり違いがでてきます。
お客さんは、基本的に「この機能がほしい」とは言いません（言う方もいますが）。代わりに、「なぜそれが必要なのか」「その作業が現場でどれだけ苦しいか」という、生の一次情報をくださいます。この"どれだけ苦しいか"の熱量は、又聞きではなかなか伝わってきません。目の前で、困っているご本人の口から聞いて、初めて分かるものだなと感じました。 また、なぜ必要かをその場でさらに深堀できるのも重要です。私たちが作っているツールをつかって業務を毎日行っている方だからこそでてくる観点や、業務に対する理解不足からピンと来てなかったことをその場で埋めることもできます。
そして、この解像度こそが、機能の優先度を決める材料になります。機能が要るか要らないかの二択なら仕様書でも分かりますが、「どれを先に作るべきか」は、現場を知らないと判断できないのではないでしょうか。
自分は「Reproの人」として見られる
もう一つ、当たり前かもしれませんが、現場で強く実感したことがあります。お客さんから見れば、自分は「担当機能のエンジニア」ではなく「Reproの代表」なのですよね。
ですから、自分が担当していない機能についても、当然のように詳細を聞かれます。お客さんはこちらの担当範囲なんて知りませんし、知る必要もありません。向こうから見れば、自分はReproという製品の代表として座っているわけです。
これは正直、しんどさもあります。守備範囲の外を突然問われて、冷や汗をかきながら答えるなんてこともあったりはします。
一方で、これは製品全体を学ぶ強い動機にもなりました。「自分の担当じゃないので分かりません」では済まされないですし、持ち帰るにしても全部持ち帰っていたらその場にいる意味はない。そのような立場に置かれることで、否応なく製品全体への理解が深まっていった、という側面があります。
そして、何が変わったか
こうした経験を経て、自分の仕事のしかたは確かに変わりました。
まず、リアルなペインを起点に、機能の開発優先度を自分で判断できるようになりました。以前は「言われたから作る」に近かったものが、「これがないと現場の事情によって導入が進まない。だからこれを先に作るべきだ」と、根拠を持って言えるようになった感覚があります。
そして、「お客さんがどのタイミングで、何に困るのか」を自分の言葉で語れるようになりました。これはチーム内でも効いてきます。一緒に開発するエンジニアに「なぜこれを作るのか」を説明するとき、一次情報を持っていると圧倒的に伝えやすいのです。仕様の背景を、体温のある話として共有できるようになりました。
結果として、自社プロダクトへの解像度が一段上がったように思います。
キャリアの観点でも、非常に意味があることと思っています。「作る力」に「現場を知る力」が掛け合わさると、動ける範囲が一気に広がります。よく"掛け算でキャリアが広がる"と言いますが、商談に出る経験は、そのmultiplierの一つになりうるのではないでしょうか。
おわりに
最後に、「エンジニアも商談に出たほうがいい」と思っている自分から、これから出る方へ。
普段行っていることとは違うものを求められる分、当然準備も必要ですし、不安になることもあると思います。ただ、そのようなことを乗り越えてでも得られるものはたくさんあります。
私をはじめ、開発者でもこのような商談に同行させてもらえる文化や環境がReproにはあります。そのような環境で一歩踏み出してみたい、興味を持っていただけたらぜひカジュアルにでもお話しできると幸いです。
