TOPインタビューエンジニアが好きすぎてDevRelになった。タイミーかわまた氏に聞く「開発者が思う存分価値発揮できる組織」のつくりかた

エンジニアが好きすぎてDevRelになった。タイミーかわまた氏に聞く「開発者が思う存分価値発揮できる組織」のつくりかた

2023年12月4日

株式会社タイミー　プロダクト本部DevEnableG　DevRel

かわまた（河又涼）

新卒で株式会社サトーに入社、営業としてラベルプリンターやハンディターミナルを活用したソリューション提案を担当。その後株式会社groovesにて、Forkwell事業部のリードセールスとして活動。セールスと海外事業の兼任を経て、Forkwell DevRel Teamに異動、エンジニア向けのイベント企画とDevRel Specialistとして活動。2023年5月、株式会社タイミーに入社、DevRelとして技術的な認知活動を担う。

エンジニア採用に力を入れる企業が増えてきた昨今、採用を見据えた技術広報的な意味合いを持ちつつ、自社のエンジニア組織を盛り上げる役割を担う「DevRel」というポジションについてよく耳にするようになりました。

タイミー社でDevRelを務めるかわまたさんは、「コードは書けないけど、エンジニアも、その独特な文化も価値観も大好き」と語ります。エンジニアの役に立ちたくてDevRelになり、その本分である技術広報や開発組織の改善に奮闘中です。

かつて営業として働いた経験があるからこそ実感する、「エンジニアが思う存分価値発揮できる組織」とは？お話を聞きました。

keyboard_arrow_down 営業だったからわかる、Googleが掲げた「Don’t be evil」の価値
keyboard_arrow_down 開発組織は「エンジニアの人生に提供するプロダクト」
keyboard_arrow_down 最終目標は「“今日の開発がちょっとよくなる”を繰り返すこと」
keyboard_arrow_down 「ビジネスサイドも専門職」が当たり前になれば、コミュニケーションは好転していく

営業だったからわかる、Googleが掲げた「Don’t be evil」の価値

──いきなりですが、かわまたさんはなぜそんなにエンジニアが好きなんですか？

かわまた：本当にいきなりですね（笑）。僕はエンジニアとして働いたことはありませんが、エンジニアリング業界の空気感がすごく好きなんです。

新卒入社した会社では、法人営業として働いていました。その頃、営業目標を達成しようと数字にコミットしていたものの、短期的な数字ばかり追い続けることにずっとモヤモヤがありました。例えば「お客様のためになるかどうかわからないけれど、来月の受注を今月に計上しよう」など、毎月の数値達成そのものが目的になっていることに、強い違和感を覚えたんです。営業の仕事が楽しくないわけではなかったんですが、目標達成のためにはお客さんにとってメリットの薄い行動をとらなくてはいけないときもあるということに、どうしても上手く折り合いをつけられませんでした。

その後転職して、エンジニア向けポートフォリオサービスを提供するForkwellで法人営業を担当することになり、『アジャイルサムライ』『ハッカーと画家』の2冊を必読書として渡されました。それをきっかけにエンジニアの文化や価値観に触れ、「この世界観こそが、僕の理想形だ」と思ったんです。

エンジニアの文化は、長期的に見て価値の高いプロダクトをつくることに重きを置いているのではないかと、僕は捉えています。短期的な成果を追うのではなく、「プロダクトの価値向上」に徹底的にフォーカスする。営業とのゴールの置き方の違いは、目標にアプローチするうえでの方法論の違いに過ぎないのですが、僕の価値観にはエンジニア的な考え方のほうが合うように感じましたし、かっこいいなと思いましたね。

──エンジニア業界の文化に共感したんですね。

かわまた：はい。業界全体の空気感はもちろん、提唱される価値観やフィロソフィーにも共感しています。とくにGoogleが掲げていた「Don’t be evil（邪悪になるな）」というフィロソフィーが好きですね。

営業だった頃は、売上のために「evil（邪悪）」な指示をする上司や、その指示に何も言わずに従っている先輩社員への違和感を抱え続けていました。

「Don’t be evil」というフィロソフィーは、evilな側面を見て見ぬふりせず、向き合って、どうしようもない時もあるけれど「そうはなるまい」と、エンジニア自身で開発組織全体に言い聞かせ続けているように感じるんです。

しかも、これらがある特定の企業だけの文化ではなく、エンジニア業界全体に浸透しているところが、それ以外の業界にはない特徴なのではないかと思います。Forkwellで働く中で、多くのエンジニアや開発組織と接する機会があったのですが、みんな当たり前のように同じ文化を共有していることに驚きました。

かわまた：たとえばエンジニアの三大美徳とは何かと聞いたときに、どのエンジニアもラリー・ウォールの「怠惰・短気・傲慢」を答えます。これが営業やCS、事務に「三大美徳は？」と聞いても、まず一致することはありません。「美徳」という、人によって考え方が異なるトピックを尋ねたとき、エンジニアだけ完全に一致したものが出てくる。これこそ、エンジニア文化の興味深く魅力的な点だと思っています。

ほかにも、『Team Geek』にあるHRT（謙虚・尊敬・信頼）や、『伽藍とバザール』にあるOSSの成功ロジック、称賛文化や車輪の再発明はしない、という考え方など…。エンジニアの方にとっては常識のようなものばかりかもしれませんが、こうした文化の根底に「問題の本質に向き合う」という強い意識があるように感じ、魅力的に思っています。

こうした独特な魅力を知るうちに、「こんなにおもしろい人たちがいるなら、彼らのために働きたい」と強く思ったんです。

▲取材時にかわまたさんが持っていた本。「『伽藍とバザール』は絶版本。大切なコレクションです」とのこと

開発組織は「エンジニアの人生に提供するプロダクト」

──エンジニアとして働きたいとは思わなかったんですか？

かわまた：よくそう聞かれるんですが、エンジニアになりたいと思ったことはないんです。「HyperCard」「Delphi」や「Ruby」などは触ってみたことはあって、全くできなくはなかったものの、「自分に向いている」とは思えませんでした。

それに、例えばアイドルを推している人の多くが、自分もアイドルになりたい、ステージに立って歌って踊りたい、と思っているわけではないですよね。それと似た感情で、エンジニアさんは僕にとってあくまで「推し」なので、自分がエンジニアになろうとは思わないんです。

僕の場合は、エンジニアとしてコードを書いたり設計したりするよりも、DevRelとして人前に立って話したりイベントを企画したりする方が向いています。だったら僕は僕の「得意」を生かしてエンジニアさんたちに貢献したい。そう考え、DevRelという職業をとことんやってみようと決めました。

──DevRelは日本ではまだ新しいポジションだと思いますが、どんな役割を指すのでしょうか。

かわまた：DevRelが生まれた海外と現在の日本では少し意味合いが異なる気がします。海外ではエンジニア向けのプロダクトを、エンジニアに対してプロモーションするという、エンジニア向けのマーケティングに近い役割を指しています。日本では技術広報とか、エンジニア採用広報の役割を担うことが多いですね。

タイミーは開発者向けプロダクトではないので、僕自身も日本でのDevRelの役割と近い部分を担っています。具体的な活動としては、タイミーの開発組織を知ってもらう、面白いと思ってもらうために、テックイベントの主催やカンファレンスの協賛などを行っています。

ただ、僕にとってタイミーの開発組織は、今タイミーで働いているエンジニア、これから入社してくれるエンジニアの人生に提供するプロダクトです。DevRelという「エンジニアに一番近い、エンジニアではない人」という立場から、開発組織と社外の接点を増やし、開発組織を盛り上げ、よりよくするところまでコミットしていきたいと思っています。

最終目標は「“今日の開発がちょっとよくなる”を繰り返すこと」

──DevRelであるかわまたさんは、開発組織を盛り上げるために必要なことは何だと思いますか？

かわまた：遠回りを恐れないこと、でしょうか。

例えば、タイミーの場合、DevRelとしての最終的な目標を採用人数には置いていないんです。日本ではDevRelの役割って「採用」に置かれがちですけど、採用人数や内定受諾数を最終的な目標にしてしまうと、クォーターごとになんとか内定承諾をもぎとろうとしてしまうなど、数字が目的化してしまう。

それって、evilじゃない？ って思うんです。「本当にエンジニアのためになるんだっけ？本質的に開発組織を盛り上げることにつながるんだっけ？」と。

たとえ開発組織を盛り上げるために様々な取り組みを行って、組織の雰囲気が良くなったり、タイミーのエンジニアリング組織の評判が良くなったりと成果が出ても、KPIに置いた数値を達成できなければ、評価につながらない。それでは、DevRelなのにエンジニアにとってベストな選択ができなくなってしまいます。

──単純な数値での短期KPIを追うとevilになる、まさに陥りがちな落とし穴ですね…。

かわまた：そうなんですよ。だからタイミーではDevRelの最終的な目標を『“今日の開発がちょっとよくなる”を繰り返すこと』に置いています。

そのために、社内なら読書会やLT会、勉強会、社外なら知見を共有し合うためのイベントなどを地道に積み上げているところです。数値目標は置いていません。そのほうが開発組織は盛り上がると思うんですよね。

なんらかの数値を目標にするより、開発組織が盛り上がったり、ひいては世の中の開発生産性が上がったりするほうが、長期的にエンジニア業界全体をより良くすることに貢献できるし、巡り巡っていいことがあるんじゃないかと思うんです。

僕は人事ではなくエンジニアと同じプロダクト本部に所属していることもあって、開発組織が盛り上がるためにはどうすればいいか、エンジニアリング業界全体がより良くなるにはどうすればいいか、という「短期的なKPIにはつながらないけれど、本質的な問いに答えること」に取り組んでいます。

──かわまたさんはタイミーの開発組織はもちろん、業界全体をスコープに入れているんですね。

かわまた：「エンジニア」という、僕にとっての「推し」のみなさんが、幸せに働ける世界をつくりたいんです。それが僕のモチベーションとなっています。

僕は、エンジニアが世の中に提供できる価値の総量は、ものすごく大きいと思っています。極端な例ですが、数人のエンジニアがつくったソフトウェアやアプリケーションが世界を変えるという事例は今まで数多くありましたし、今後も同じようなことが起こる可能性は当然あります。こんなに夢のある職業って、なかなかありませんよね。

だから、彼らがエンジニアリングによって価値を発揮しやすいように、楽しく働いて、幸せでいるために、僕に何かできないかなと。そういう思いで日々働いています。

──ちなみに、開発組織を盛り上げる上で、evilを予防しつつ目標に近づいていくには、KPIをどのように置けばよいと思いますか？

かわまた：最終目的に対して遠回りに思えたとしても、現状から近いステップにKPIを置けば、evilになりづらい構造をつくれるのではないかと思っています。

たとえば「開発組織を盛り上げる」という最終目標を、より具体的に分解し「①自社のエンジニアに、うちの組織はイケてると思ってもらう」、そしてそれを「②社外に向けて発信し伝える」という、2つのステップに分けるとします。

まずは①が果たせているかを測り、その数値にKPIを置きます。一定の期間ごとにアンケートをとって、社内エンジニアがどれくらい「うちの組織はイケてる」「開発が楽しい」「成長できた」と思えているのかを数値化するのもいいですね。

ここである程度成果を得られて、②のステップに移ったら、社外のエンジニアにどれだけ魅力が伝わっているかにKPIを置き直します。自社の開発組織について、社外のエンジニアがどんなイメージを持っているのかをアンケートなどで測って、目標との差を埋めていくんです。

こうして、ひとつひとつのステップを丁寧に踏んで積み上げられるようにKPIを設計できれば、evilを生むことなく最終目的に近づいていけるのではないでしょうか。

「ビジネスサイドも専門職」が当たり前になれば、コミュニケーションは好転していく

──ビジネスサイドとの連携がうまくできているかどうかも、エンジニアの価値発揮のしやすさに関わってくると思います。すれ違いがちな二者が同じ目的に一緒に向き合えるようになるには、どうしたらいいと思いますか？

かわまた：ビジネスサイドがエンジニアと話すとき「自分は専門職なんだ」という意識を持つことが大切なのではないでしょうか。

エンジニアは「自分は専門職だ」と認識しているので、ビジネスサイドとの会話で技術的な話をするとき、知識のない人でも話の内容を理解できるように、初歩的なことから段階を踏んで、難しい言い回しを避けて分かりやすく説明しようとしていると思います。

でも、ビジネスサイドは往々にして「自分は専門職ではない」と考えがちです。そのため、自分にとっての常識を相手も同じように持っている前提で話してしまうことがあります。ビジネスサイドも専門的で高度な仕事をしているのに、その自覚がないことで、相手の知識を過剰に見積もってしまう。これが原因で、エンジニアとビジネスサイドの間のコミュニケーションエラーが起き、協働が難しくなってしまうのではないかと、僕は思っています。

──確かに「営業＝総合職」と呼ばれることが多いからか、「専門職」というイメージは薄かったように思います。

かわまた：そうですよね。でも、コミュニケーションや仕事がどんどん複雑化している今、営業、CSだけでなく、どんな職種も、専門的な知識や経験がないと成果を上げられなくなってきているはずなんです。

例えば営業やCSが持っている「このお客様はここに課題を感じているんだ」というN＝1の視点も、プロダクトの改善にとって重要なファクターで、高い専門性があると思います。

ビジネスサイドも自身の専門性に誇りを持てば、自分の仕事に対する良い意味でのプライドも、自分と異なる専門職に対してのリスペクトも生まれるでしょう。それに、自分にとって当たり前のことが、他の職種にとって当たり前ではないということも実感できるはずです。その前提に立てていれば、説明不足になってしまうことなく、適切にコミュニケーションが取れるようになるのではないかと思います。

その上で、エンジニアリングの技術やフィロソフィーについて理解を深められると、より理想的な連携に近づくのではないでしょうか。