LegalOn Technologiesの長内毅志さん

はじめに

DevRelに関わる人たちは増えている一方で「なぜDevRelに関わるようになったのか」「どういったキャリアを歩んで現在があるのか」については、あまり明らかにされていません。それぞれ異なるキャリアを歩んできていますが、その共通項を探っていこうというのが本連載の目的です。DevRelとしてのキャリアに興味がある方に、ぜひ読んでほしいです。

第3回目となる今回は、LegalOn Technologiesでカスタマーリレーショングループリーダーを務める長内毅志さんに、これまでのキャリアとDevRelとの関わりについてお話を伺いました。

長内さんは営業としてキャリアを始めた後、技術営業、テクニカルディレクター、DevRel、エンジニアリングマネジメント、そして現在のカスタマーリレーション領域へと、複数の役割を横断してきた人物です。その歩みをたどることで、長内さんのキャリアの軸が見えてくるはずです。

営業から技術領域へ
自分の力で仕事をするための転機

長内さんのキャリアは、アスキーの営業職から始まりました。新卒で入社してゲーム事業に関わり、ファミコンやパソコンゲームの営業・マーケティングを担当していたといいます。その後、出版社の立ち上げを経てネットドリーマーズへ転職。そこでは、エンタープライズ向けCMSの技術営業として、要件定義や機能定義、サーバーのキッティングや運用支援まで担当していました。この時期に、長内さんは「技術的スキルを大きく鍛えられた」と振り返ります。

その後、キャリアレップを経てテクニカルディレクターとして小さなWeb制作会社へ移り、本格的にエンジニア寄りの仕事へと足を踏み入れました。営業から技術側へと進んだ理由について、長内さんは「所属する組織と関係なく、自分の力で仕事ができるか試してみたいというのが一番大きかったです」と話します。自分のスキルで独り立ちできるかを試したかった。その思いから、技術の世界に足を踏み入れました。

コミュニティと一緒に取り組んだ
シックス・アパートでのDevRel活動

長内さんがDevRelと出会うきっかけとなったのは、コミュニティに関わった経験です。

Web制作会社時代、長内さんはMovable Typeに詳しくなり、そのユーザーコミュニティにも参加するようになりました。それ以前にも、別なCMSのユーザーコミュニティに関わっており、オープンソースやコミュニティの力に可能性を感じていたといいます。

Movable Typeのコミュニティでは、記事執筆やプラグインを作るなど、自分なりのコントリビューション(貢献)を続けていました。

シックス・アパート入社後は、プロダクトマネージャーを経て2014年からDeveloper Relationsを担当することになりました。当時、DevRelやDeveloper Relationsという言葉は、まだ一般的ではありませんでした。長内さん自身も最初は「コミュニティマネージャーのようなものだ」と捉えていたそうです。しかし、会社からはユーザー支援を担う新しいロールとして提案され、Developer Relationsという役割に就くことになります。

シックス・アパート時代の長内さんは、ユーザーグループの支援やWebサイトの翻訳、ハンズオン、セミナー登壇などに取り組みました。新しいバージョンが出たときには、以前と何が変わったのか、どう使うのか、技術的な要素がどう変化したのかを伝える役割も担いました。

当時はREST APIやクラウドといった新しい技術の理解も求められる時期でした。長内さんはAPIを使うと何ができるのか、クラウドにCMSをインストールして使うとどんなメリットがあるのかを、制作者やWeb技術者に伝えていきました。

ユーザーコミュニティの支援にも携わり、全国のユーザーコミュニティの運営に協力したり、登壇を行うなど、各地を歩き回り、全国各地のユーザーグループの発展をお手伝いしました。

ユーザーコミュニティ主催の大きなイベントも開催されました。「MTDDC Meetup」です。

「ベンダー万歳のイベントにはならないで欲しい、と思っていました。Web制作者やWeb技術者にとって嬉しいコミュニティになって欲しかったし、それをサポートしていこうと考えました。その結果、Movable Typeというサービスを愛してもらえれば、と考えていました」

Movable Typeの話だけでなく、他のCMSや技術、デザインの話をしても良い。そうした共存共栄を目指したイベントとして位置づけていたといいます。

現在もユーザーコミュニティの活動が続いていることもあり、長内さんは手応えを感じているとのこと。シックス・アパート時代の取り組みは大きな成果だったと振り返ります。

シチズンデベロッパーに向き合うDevRel

その後長内さんはfreeeに移り、Developer Relations Managerとして、APIの普及促進を担当することになります。「freeeは現場の裁量が大きな会社で、色々な施策を任せていただきました。今考えても、懐の広い会社だったと思います」

freeeでのDevRelは、シックス・アパート時代とは異なる性質を持っていました。freeeではAPIチームの中で、シチズンデベロッパー(市民開発者)向けのマーケティング施策を担当していたといいます。

対象となるのは職業エンジニアだけではありません。税理士、公認会計士、経理担当者、個人事業主など、業務上の必要からfreeeのAPIを使いたいと考える人たちでした。

「純粋な技術畑の方やエンジニアだけではなく、シチズンデベロッパーに対して何ができるかを問われたキャリアだったなと思います」

そのため、APIの使い方を説明するナレッジコンテンツやハンズオン、開発コンテストなどを通じて、非エンジニアにも理解できる情報提供を行いました。OAuth、APIのGET/POST、トークンといった概念を単に専門用語として伝えるのではなく、なぜ必要なのか、どう扱うべきなのかをステップバイステップで伝える必要がありました。APIキーやシークレット、トークンの扱いが問題になりやすく、セキュリティ上の注意点を丁寧に伝えることもDevRelの重要な役割でした。

freeeでの活動は、新型コロナウイルスの流行とも重なりました。本来であればユーザーコミュニティ支援にも取り組みたかったものの、対面での活動は難しくなります。そのため、APIに関するナレッジの集積場所を整えたり、オンラインカンファレンスを開いたりと、オンラインでできる活動へシフトしていきました。

長内さんは、直接会って同じ時間を過ごすことで人と人との関係性は強まると考えていました。その時間を持てなかったことはつらかったとしつつ、オンラインで情報を流通させる方法を模索した時期だったと振り返ります。

DevRelで培った幅広い技術理解が
カスタマーリレーションに活きる

現在、長内さんはLegalOn Technologiesでカスタマーリレーショングループのリーダーとして働いています。役割は大きく2つあります。1つは、サービスを利用する顧客の現場で技術的なトラブルが起きた際に、何が問題でどう解決すべきかを支援するカスタマーリライアビリティエンジニア(CRE)としての役割。もう1つは、ユーザーサポート、CRE、データオペレーションなどをまとめるグループのマネジメントです。

管理職とエンジニアの両方を担っている現在の仕事でも、DevRelの経験は大きく活きているといいます。

顧客環境で発生する技術的なトラブルはサービス単体ではなく、複数のサービスや環境の組み合わせで起きることが多くあります。ネットワーク、プロキシ、IP、認証認可、ブラウザ設定など、複数の技術的な知識を組み合わせなければ原因にたどり着けないケースもあります。

「DevRelは単にコードを書くだけではなく、クラウドやネットワークなど広範な知識を知っておく必要があります。DevRel時代に勉強したことが役立っています」

DevRel時代に培った幅広い技術理解とユーザーの状況を見ながら仮説を立てる力が、現在のトラブルシューティングにもつながっているのです。

DevRelとは正しく理解し、正しく伝える仕事

長内さんがDevRelとして大事にしていることは「正しく理解した上で、正しく伝えること」だと語ります。

会社から渡された言葉をそのまま伝えるだけではユーザーには届きません。仕様書を掲載するだけでも十分には伝わりません。自分自身で実際に手を動かして仕組みやフレームワークを理解し、それを自分の言葉に置き換える必要があります。

長内さんが得意だと感じているのは、リレーションとしての橋渡しです。つまり、開発チームが作ったものにはどのような意図があるのかをユーザーに伝える。逆に、ユーザーや開発者が何に困っていて、何を必要としているのかを開発チームに伝えるといった両者の中間に位置する存在です。

ただし、それは単なる伝書鳩のような動き方ではありません。双方の状況や文脈を理解した上で、正しく橋渡しすることが重要です。例えば開発者の言葉をそのまま伝えても、シチズンデベロッパーには難解でうまく伝わりません。一方で、噛み砕きすぎたり省きすぎたりすると、誤った情報になる可能性があります。

この「間違えずに、相手に伝わる言葉へ変換する力」が長内さんのDevRel観の中心にあります。

DevRelに必要な伝える工夫と
コントリビューションの意識

これからDevRelに関わりたい人に必要な素養について、長内さんはまず「コミュニケーションの工夫」を挙げます。ちゃんと伝わる文章を作ること、伝え方に気を配ること。ユーザーが何に困っているのか、開発側が何を伝えたいのかを理解し、その間をつなぐ努力が必要です。

単に会社や開発チームの言葉をそのまま伝えるだけでは、DevRelとは言えません。相手が本当に知りたいことを理解し、解決につながる形で届けることが求められます。

もう1つ、長内さんが強調するのが「コントリビューション」の意識です。

「自分にできることで、自分が所属するチームや組織、そして仲間たちに貢献しようという意思です」

オープンソースのコミュニティへ参加していた時にコントリビューションという概念に気がついたと言います。コントリビューションはコードを書くことだけではありません。困っている人にドキュメントの場所を教えること、英語の情報を日本語で説明すること、新しい機能について分かりやすく伝えることも立派な貢献です。

長内さん自身もMovable Typeやオープンソースのコミュニティに関わってきたことが、DevRelへの道につながりました。だからこそ、これからDevRelを目指す人にも、まずは自分にできる形でコミュニティに参加し、アウトプットやコミュニケーションを大事にしてほしいと話します。

AI時代にも求められるスキル

今後の目標について、長内さんは「年齢を重ねた今だからこそ学び続けることが必要」だと語ります。特定の領域だけの知識や経験だけでは、このAI時代は生き残れない。最後まで新しいことを学び、理解しようとし、挑戦し続けなければならないと考えています。

「AIがやるからいい、ではなくて、AI時代に何ができるかを常に考え続けたいなと思っています」

一方で、AI時代になってもなくならない仕事もあると長内さんは見ています。それが、トラブルシューティングやユーザーとのコミュニケーションです。

仕様的な質問にはAIが答えられるようになってきています。それでも、ユーザーの環境で複数のシステムが組み合わさり、前例のない状況が発生するとAIだけでは解決できないことがあります。そうした場面では、問題や課題を解決する力やユーザーときちんとコミュニケーションを取る力、状況を整理して伝える力が必要になります。

単にコーディングだけをする仕事は、AIに置き換わる部分もあるかもしれません。しかし、基礎となる技術力に加えてユーザー理解や問題解決、橋渡しの力を持つことで、これからのキャリアを作っていけるのではないか、長内さんはそう考えています。

キャリアの軸は「技術と人をつなぐ」こと

長内さんのキャリアは営業から始まり、DevRelを経由してカスタマーリレーションへと変化してきました。一見すると複雑に見えますが、その根底には技術を理解して人に伝え、ユーザーと開発の間をつなぐという一貫した姿勢があります。

DevRelは純粋なエンジニアリング力だけで成り立つ職種ではありません。技術支援やコミュニティ、ドキュメント、サポートなど、さまざまな経験を土台にできます。長内さん自身も「自分の基礎をプラスアルファで広げる職種」と捉えています。

長内さんの話からは、DevRelという仕事が単なる広報やイベント登壇ではなく、技術と人、ユーザーと開発、現在の課題と未来のキャリアをつなぐ仕事であることが伝わったのではないでしょうか。