どうすればエンジニアを巻き込めるかを考える　Developer Successチームが進める「アウトプットさせること」

エンジニアと非エンジニア、どちらが向いているか

桃木耕太氏（以下、桃木）：ではここから、オープンディスカッションというかたちで。正直こんなに質問がくると思っていなかったのですが、まず一番上の質問から。

「エンジニア組織を支えている人は、現（or元）エンジニアの必要がありますか？」。この中でエンジニアバックグラウンドがあるのは2人ですか。藤原さんと祥子さんはエンジニアバックグラウンドがあって、櫛井さんと三木さんと僕はまったくエンジニアキャリアがないです。

藤原聖氏（以下、藤原）：まあどっちかと言うと、これちょっと後で話されるかもしれませんが、エンジニアである必要は特にはないかなっていうことと。なのでエンジニアからくる場合は、どういったものがあるといいかと言うと、さっきのミッションにあるように、なんて言うかサポーティブな心とか、なんかそういったのがあるといいんじゃないかなと私は思っています。

桃木：どうなんすか。祥子さん、サポーティブな気持ちがありますか。

佐藤祥子氏（以下、佐藤）：はい。私はとてもサポーティブな心を持ち合わせていると思うんですけど（笑）。

藤原：ははは（笑）。

櫛井優介氏（以下、櫛井）：自分で言うの（笑）？　

佐藤：1つ思うのは、やはりエンジニアリングの知識があると、何をやっているのかもキャッチアップしやすいですし、会話がしやすくなったりします。特に私は、インタビューとかやっていたりする中で「あ、こういうことやっているんだ」っていうのを深掘りして、どんどん聞いていけるというところはあるかなと思います。

とはいえ、やっぱりやっている分野によっては全然わからないこと、すごく難しいことやっている組織が多かったりするので、そこも自分自身が、例えばエンジニアリングが好きだったらもっと吸収していこうみたいなモチベーションもプラスになったりするので、すごく良いかなと思っています。

桃木：逆に非エンジニア属性の場合はどうかというと。自分からしゃべっちゃうと、わかんないことはわからないで「これって技術的にすごいんですか」とか「何がいいんですか」はエンジニア側に教えてもらい、決めてもらって、そこを崩さないようにアウトプットしたりしています。

とはいえ、やっぱり「こういうのが嫌だよな」みたいなことや「こういうのはいいポイントなんだろう」っていうのは、なんとなくでも想像して、そこらへんの感覚を付けるようには意識しています。僕はこの中では一番技術から縁遠いところからきているので、そこらへんはすごく意識してたりしています。

4年、5年やってきて、さすがにあんまり地雷を踏むことは減ったかなと思いますが、けっこう初期はマジでわかんなかったです。

櫛井：私は、もともとWebディレクターというのをやっていたので、当時から直接エンジニアと仕事する機会が多かったんですね。なので私が企画を考えて「ページ遷移とかこういうふうにやりたいんだ」っていうのをエンジニアに伝えて、「そんなこと、できねえよ」みたいなことを直接言われたりした経験があるので。

彼らの大事にしているものや、優先順位みたいなことは、その時けっこう学んだので、今の仕事にはそこはすごくプロトコルを近づけるというか、彼らが何を大事にしていて、何を嫌っているかみたいなところのニュアンスは、そこでかなり掴んだかなという感じはしますね。

桃木：でも結局、そこら辺を想像してとか、何がよくて何が嫌かっていう感覚をつかみにいくみたいなところの繰り返しですよね。

櫛井：そうですね。うん。

KPIをどう決めているか

桃木：はい。ではいっぱい質問あるので次にいきましょう。「チームのKPI的なものはどんなものですか？」　最初に入れたKPIをどう決めているかっていう話なんですが。ざっくり言ってしまうと、さっき言っていた活動や領域ごとに、この項目に対してこういう数字を追いましょう、みたいなことは年度の頭に決めたりはしています。

ただその数字を追うことがすべてではないと思っているのと、やっぱりそれ自体が実質効果になるか、どちらかというと、ブランディング活動は効果が見えないことが多かったりするので、わりと置いている項目も、アクションKPIみたいなものが多いかなと。ブログを何本出そう、イベントをどれぐらいやろうみたいな、自分たちの活動に対して数の目標値を決めることが多いかなあとは思っています。

これが守れなかったから評価が下がるとかは、もしかしたら今後あるかもしれないですが、そういう評価ではないかなと思っていて。結果、まあそのあたりを目指しながら、どれぐらい貢献できた、いい活動ができた、アウトプットができたみたいなところが、わりと求められる雰囲気が強いかなと思っているんですけど。

藤原：あと、他社の人からよく聞かれることがありますが、さきほど桃木さんが言っていたように、私たちの活動は効果が見えづらいものが多いじゃないですか。なので、定性的な判断軸でいろいろ決めてたりもしますが、さきほど桃木さんが言っていたように、活動量をKPIに置くことがほとんどだし、それで私もいいと思っています。

桃木：それと、このアクションすることでこれって何になるの？　採用何人採れるの？　みたいなことを聞かれることはもちろんありますが、そのうちというか、もちろん採用につながることもあれば、これを見てその半年後、1年後にエントリーしてくれる人もいるので、わりとKPIを決めすぎないという論法がメチャクチャあるチームだと思っています。アクションに巻き込むっていうところにはコミットしながら、その先に関しては、そこを追いすぎないみたいなところで、バランスを個々に取っているのかなあとは思います。

藤原：はい。全体的にその活動量みたいなKPIを置いている関係で、パッと外から見た時に、「LINEはちゃんと活動しているね」っていうのが、（外からは）見えているのかな、とは思っていますけどね。

どうやってTwitterのフォロワーを増やしたのか

桃木：ありがとうございます。次の質問です。「どうやってTwitterのフォロワーを増やしたのか、ナレッジをうかがいたいです」。ナレッジ。基本、投稿量だと思っているんのですが、櫛井さん、どうでしょう。

櫛井：はい。これは開設するタイミングで、私と桃木さんで一緒に立ち上げたやつで、フォロワーの数がなかなか増えなくて当時は大変だったのですが。

まず決めたのは、ルールをいろいろ決めました。これは発信する、これは発信しないというのを決めて。本当に技術より直接関係ないものは、どこからの圧力があってもツイートしないみたいなのはありました。

そういうルールを決めるというのと、あとはやっぱり話題になるってことは大事かなと思っていて。開設当初いろいろやったのは、技術イベントのスポンサーをする時に「このアカウントをフォローして、こういうことをしてくれたら、こういう楽しい企画があるので一緒にやりましょう」みたいな。まずフォローしてもらって、そこからコミュニケーションしましょうみたいなことを、けっこう意識的にやっていましたね。

ブースに来ていただいて、当時で言うとLINE CLOVAのスマートスピーカーなどを用意して、これをツイートしてくださいみたいなお願いしたりも、けっこうやったのは覚えていますね。

桃木：あとあれですね、まあいろいろツイートしていて、LINEの開発者向けのプロダクトのアップデート情報からイベント告知から採用情報とかやっていたりするのと。たぶんご覧になられた方も多いと思いますが、最近はTwitterで採用広告も出してたりするので、それに紐づけてフォロワーが増えてたりしてたりもします。

あと1個、特殊なことをやったのでそれについて言うと、LINEのエンジニアのみなさんに、「私はLINEのエンジニアだよ」って言ってもらったらいいなっと思ったことがあって。3年ぐらい前の11月29日、いい肉の日に「このツイートを『LINEのエンジニア』って言いながらリツイートして名乗ってくれたら、焼肉奢るよ」企画をTwitter上でやって、それでガッと増えたみたいなこともあったりしました。

なので、基本まじめにやりつつ、たまにふざけてフォロワー増やしたり、LINE DEVELOPER DAYみたいなイベントでガッとフォロワーを増やすみたいなこともあったりするかなあとは思います。たぶん2020年に10,000人いったんですよね。

櫛井：そうです。

桃木：なので、年1,000人増えるか増えないかぐらいで純増はしているかなとは思っていますね。

櫛井：ちょっと心残りは、1,000人とか5,000人とか、10,000人とか、きりのいいタイミングで何かしらキャンペーンをやろう、プレゼントキャンペーンをやろうとか、毎回言うんですけど、毎回微妙にいろいろ外してしまって「ちょっと今できないね」みたいな時が重なってしまって。

桃木：そうですね。それどころじゃないという時がほとんどですね。今あと少しで11,111になるんで、いいアイデアがある方はコメントください。次行きます。

技術広報の優先順位

桃木：「技術広報として自社ブログ、エンジニアブログ、スポンサー、勉強会主催、カンファレンス主催等々で、優先順位が高いものはどれですか」。優先順位の考え方ってどうなのでしょうか。

三木鉄平氏（以下、三木）：これは1年のタイムラインの中で、何に今比重を置いて、その状況に応じてどこに注力するかというのは、その時々によって変わるので、回答としては「全部がんばっています」としか言いようがない気がしますね。アクションのねらいが違うじゃないですか。

桃木：なんか手法に優先順位を設けるというか、どうにかして、いい情報をいいところにアウトプットするようなことを、わりとフラットに日々判断していて、みたいな感じのほうが近いんですかね。

三木：そうですね。

藤原：その部門の課題に応じてそれぞれが判断してやっている、というのが正解なんじゃないですか。

桃木：例えば僕で言うと、優先順位や情報の質もありますが、その担当している部門や相手の何が得意か、これは面倒くさがっていて、これは乗り気で、みたいなところも合わせて、アウトプットしやすいもの、できるものを選んでいる気がします。祥子さんは、こういう優先順位ってどう決めています？

佐藤：その時のタイミングとかもあったりすると思うんですよ。カンファレンスも、年間でいつとかあると思いますし、勉強会に関しても、他の部署でやっていたり、重ならないようにであったり、エンジニアの人が登壇しやすいタイミングなど、いろいろあると思うので、全体的に何を優先というよりは、そのタイミングで何が一番的確か、何をすべきかというところを、その時に判断してやっていくところだと思っています。

桃木：そうですね。僕らは旗振り役なので、僕らの中で優先順位を決めるというよりかは、優先順位を付けてそれっぽく見せて、「これをがんばりましょう」って言うことはありますが、あんまりここを決めて縛ったり、チームで固定するみたいなことはしたくないと思っています。わりと個々の判断だったり、その時の状況で、コントロールしているところは大きいかなあと思います。

技術広報の課題

桃木：次の質問。「チームから見た、今のLINEエンジニア組織の課題トップ3はなんですか？」　ではいきなりですが、課題トップ3。1人1個ずつ言いましょうか。では祥子さん。

佐藤：はい。やっぱり1つ思うのは、よく私が担当している部署でも聞きますが、LINEって多国籍の方が多いじゃないですか。なので、そういった言語のところ。英語話者が、ちょっと日本語を理解できないと、開発していくのが難しかったりとか、そういったところがまだまだ課題としてあるのかなと思っていますね。それはけっこう大きいかなと思っていたり。

桃木：なるほど。働く人の中でそういうグループに対して、アクセシビリティ的なものの差が出ないとか、逆に英語話者をサポートしてあげたり、英語話者のための企画を作ってあげるみたいなこともしていますよね。

佐藤：そうです、はい。

桃木：なるほど。三木さんはどうですか？

三木：最近の課題というと、さっき私の説明パートで言ったような、今コロナでリモートワークになって、情報がいき届かなかったり。あとはZホールディングスと経営統合して、会社の方針が見えづらい、人が多くなって顔がわからないなどはあるとは思うんですけど。

ずーっとある課題としては、今祥子さんが述べられたような、いろいろな国籍の人がいるので、社内のコミュニケーションもそうですし。あとは、私が5年前に入った時も、ミステリーカンパニーというか、外の人からしたらLINEの人ってどんな人なの？　みたいな部分があって。どんなエンジニアがいるかわからないから、すっごく情報をネットで調べたんですよね。個人では有名だけど、LINEの肩書きではあまり外に出ていなかったりしていたので。

それが、さきほどTwitterのフォロワー数をどうやって増やしてきたかという質問かありましたが、少しずつ情報発信の工夫を積み重ねてきて、今わりと組織的に、こういった活動ができるようになったかなと思うんです。今は今で、規模は大きくなりましたが、ここからワンステップと言うか。グローバルの会社として、あともう1つインプレッション出していくためにどうしたらいいかなっていうのが、私たちの問題としてあります。

桃木：たぶん三木さんが入ってきたタイミングや、僕が本格的に異動したタイミングよりは、今は組織的に出せる量や手段も増えている気がしますが、それでもまだぜんぜんカバーできてないし、知られていない部分が多すぎるみたいなのはやっぱりありますよね。

三木：そうですね。

桃木：たぶんその手前にエンジニア組織をどう巻き込むかなど、いろいろ課題はあるんですが。結局のところ、まだぜんぜんアウトプットが足りていないことと、あと人の手も足りていないので、そういうこともあります。たぶんまだ知ってもらえていない部分が多すぎて、そこは1個課題だなあとは思っています。だから僕らがいる意味があるのかなあ、というところですよね。最後、櫛井さん、それっぽい何かガンとした課題を1個もらっていいですか。

櫛井：課題ですか。そうですね。やっぱり僕らが企画する側なので、年中こういうことやりたいだったり、こうやったら効果的だよねっていうのは、ものすごくあるんですね。「全社的に課題ってこうだよね」ということをみんなで洗い出して、その上で「じゃあエンジニアの組織って今こうだよね。じゃあ私たちはこれをしたほうがいいよね」っていうのを、戦略って言うとよくないかもしれませんが、わりと大きな俯瞰から入ってやっているっていうのはあります。

「企画はできるが、実行する手が足りない」というのが僕らの課題かなと思っていて。エンジニアのことがわかって、かつプロジェクトマネージメントができて、というのはけっこう稀有な存在らしくって、あんまりいないと聞くので。

桃木：エンジニア組織の課題というか、僕たちの課題ですね。

櫛井：そうですね。エンジニア組織自体はすごくうまくいって、なんて言えばいいかわからないですが、僕らがもっとできることがあるよな、と日々感じてはいますね。

桃木：こういうことをやれる人や、逆に言うとエンジニアに開発に集中してもらうためにみたいなところも含めて、もうちょっと機能と人数を強化したいなと思っています。

一番Successした事例

桃木：次の質問。これ、難しいですね。「一番Successした事例を教えてください。」

櫛井：SuccessしたいからSuccessチームにしている。

桃木：これからSuccessするチームなんですか。

櫛井：そうです、はい。

桃木：僕はバズったものを言うと、さっきの焼肉企画は社内で評判良くて、翌年も「今年はやらないんですか」って聞かれたりしたんで、焼肉の人として覚えられていたみたいですね。三木さんは何かあります？　社内外も含めて。

三木：LINE DEVELOPER DAYが終わった後に、スピーカーの人から「登壇させてもらってありがとうございました」って言葉をいただくことがあります。感謝するのはこっち側なのですが、自分たちの技術の発信の場を、スポットライト当たる場でいろいろな人に見られること自体が、エンジニアによっては価値ある場だったりするので、そういう言葉をもらった時はうれしいですよね。

桃木：そうですね。LINE DEVELOPER DAYで言うと、2019年までのオフラインでやっていた時は、僕らも含めて達成感あったし、いい企画やったし、なんかモチベーション共有できたりみたいなところはあって。

やっぱり2020年にオンラインイベントになってそこがちょっと薄かったよなみたいなところもあって。僕たちLINE DEVELOPER DAYやったはいいけど、カメラの前でしゃべっても、リアクションがあまり受け取れず、当日懇親会的なものもなかったりするんで。

櫛井さんが言っていましたが、まだまだそんなにクリティカルにSuccessできていないていうのが正直あって。日々活動を支えているので、これからちゃんと大きな成果とか出していかないといけないのですが、まだ種まきだったり、基礎を作っているみたいな感覚のほうが近いんですかね。

藤原さん、すごいヒットってなにかあります？

藤原：また食事ネタで申し訳ないのですが、DevRelランチもけっこう良かったと思います。

櫛井：ああ、あれはよかった。

桃木：これは、ふだんってやっぱりリードの方とか、マネージャーから話を聞いて、要件だったり、こういうことやりたいですってコミュニケーションをやるのですが、そういうのじゃなくて、ちょっと部署の現場の方をピックアップし、あんまり話す機会のない方や、最近入った方と、僕らが2人対エンジニアが5人ぐらいでランチをして、ぶっちゃけどうですかみたいな話を聞いて。

それから実際に企画につながったものとかもあったりすします。今こういったご時勢なんでなかなか難しいですが、そういうものをやって、上からのオーダー、僕らがやりたいことだけではなく、みんながやってほしいこととかみたいなことは汲み取るようにはしていこうかなとは思っています。これから大きなSuccessを作るための、たぶん活動の1個かなと思います。なので、ぜひ大きなSuccessを作りたい方はエントリーをお願いします。

櫛井：一緒にScuccessしましょう。

桃木：あんまり言うとよくないですね。

桃木：DevRel（Developer Relations）とDevSuc（Developer Success）、これは組織の改変的な問題だなあ。

藤原：命名者が説明しょうか。2つの言葉を使っている理由に、まず組織図的な話があって。組織図でいうと、日本の組織はDeveloper Relations室という大きな箱があって、その下に私たちDeveloper Successチームがいる組織になっています。

もともとDevRelは、私が冒頭で説明したように、LINEにおいてはDeveloper Success的な意味合いがすごく強くて。それをメインに、韓国のチームも、台湾のチームも、同じような動き方をしていて、LINEにおいてDeveloper Relationsのメインの活動がDeveloper Success的な話でありました。

日本では、組織をちょっと大きくする際に、チーム名を付けてほしいって言われて、ならばDeveloper Successかなあと思って付けた感じですかね。

桃木：最近社内になんたらSuccessという組織がすごく増えてきていますが。基本目標というか、そこの領域でいいことをしようみたいなことで横断的に動く役割を求められていました。

もともといわゆるテックエヴァンジェリズム、外のみなさんがいうDeveloper Relationsも同じ室内にあったのですが、組織の目的だったり、ちょっと構想を変える時に別部署になったぐらいのかたちで。説明するとそういう構造の変化があって、といった感じなのですが、僕らはそれをDevRelと言ったり、DevSucと呼んだりしている感じですかね。

藤原：社内的にはほぼ同義ですよね。

エンジニアブログの発信数を増やすための工夫

桃木：次、「エンジニアブログの発信数を増やすための工夫が知りたいです。」

櫛井：お、これ桃木さん担当じゃないですか。

桃木：そうですね。苦労していますね。エンジニアをどう巻き込むかとか、エンジニアに執筆の時間をどう取ってもらうかはすごく苦労しています。

さきほど、ちょっと三木さんの話にもありましたが、1カルチャーの会社では正直なくて。例えば「これをやりましょう」と言ったら、みんながそっちを向いてやるというより、それぞれ独自の文化や雰囲気を大事にしながら、成り立っているみたいなところがあって。それはいいところだと思うのですが、僕たちが「エンジニアブログをぜひ書いてください」って言っただけで動くものではないかなあと思っていて。

ちょっと前にやったものでいうと、「どういうものを書いていいかわかんないから」って言われたので「こういうものは書いていいですよ」「こういうふうに書きましょう」「例えばこういう構成サンプルがあります」ってガイドを作ったりしました。

あと今やっているのは、僕や櫛井さんや三木さん、祥子さんなどが、さっきから出ている各部門の担当みたいな感じになって、窓口営業のように「最近いいネタないですか」みたいなことで話を聞いて、「ああ、じゃあこれはブログに書きましょう」「これはイベントをやりましょう」みたいなかたちで、ネタを抽出するサポートをしてたり。

今準備しているもので言うと、エンジニアブログにインタビュー記事をけっこう載せていますが、そういうものも増やしたいと思っています。ただ、あくまでエンジニアブログはエンジニアブログなので、インタビューのタブを別で設けて、エンジニアブログはもうちょっと純粋にピュアなものにしつつ、インタビュー的なアウトプットも増やしていくようなこともしています。

ただ、基本的には、現場というか、書いてくれる人への働きかけをどんだけ効果的にできるかがすべてな気がしています。祥子さんはブログを増やすためになにかしていることはあります？

佐藤：そうですね。もっとやっぱり、自発的にというか自由に書きたいと思えるような感じにしていきたいなとは思っているんですが。そこはやっぱり課題がありますね。

桃木：組織が大きいからこそ、その意思だったり、思いが行き届かなくて、なかなかうまくいっていない部分なので、うまくいっているところの方法をぜひ教えてもらえると。この間別のイベントで一緒に話したM3さんがすごくうまくやっていて、その手のやつをまとめていたブログがあったはずなので、ぜひ検索してみてください。めっちゃ参考になります。

アフターコロナでイベントはどうなるか

桃木：次の質問は、「イベントがオンライン化しましたが、アフターコロナでのイベント配信については、どのように考えていますか？」　大きいもの、小さいものがあるとは思うのですが、櫛井さんがさっき説明したDeveloper Meetupでいうと、基本（イベントは）増えた？

佐藤：増えていると思います。

櫛井：僕らがやっている分で言うと、増えているし、開催本数も増えているし、参加者も増えてはいます。ただやっぱり課題はあると思っていて。オンラインでやるのは、すごく便利でいいんですが、その時間にリアルタイムで参加することの意義がけっこう失われがちなので、そこはなかなか苦労しているというところかなと思っていますね。

桃木：そうですね。エントリーはしてくれるけど、当日来ないとか。あと聞いてはいるけどたぶん耳だけで、グリップしていないみたいなことはけっこうあるかなと思います。三木さん、このあたりはどうですか。

三木：オンラインにオフライン、あとハイブリッドで両方やっていくという選択肢はあると思うのですが、最適解はもちろんないですし、運営リソースにも関わってくるとは思います。

コロナが落ち着いたら、やっぱりオフラインのイベントはやったほうが、これまでコミュニティ活動が好きで、そういったところに集まってくれていた人は、渇望感というか飢餓感があると思うのですよね。そういう人たちに対して、情報発信をオフラインでやっていきたいというか、必要だとは思いますね。

それとは並行して、オンラインの情報発信の知見はいろいろな人が工夫しながら積んでいると思うので、その資産は利用したい。言うなればメディアが違うじゃないですか。だから両方で情報発信していくべきかなというのが答えですかね。

桃木：海外だったり地方からの参加者が気軽にアクセスできたり、そういったところも含めて、あとキャパを気にしなくてよくなったりみたいなところはあると思いますが、やっぱり懇親会とかで話すからこそみたいなところもあるからってことですよね。

三木：そうですね。リーチできるターゲットがやっぱり変わってきますし、コンテンツの楽しみ方も変わってくると思うので。両方ともやっていて楽しいですし、両方とも価値があると思います。

桃木：そうですね。2021年のDEVELOPER DAY考える中でも、タッチはできるけどグリップできないオンラインイベントの性質みたいなところあるので、どうしたらリアルタイムにグリップできるのか、企画やコンテンツを今ちょうど考えてたりします。オンラインイベントでも熱量持って参加していただけるように、オンライン、オフライン使い分けみたいなところは悩んでいるかな。祥子さん、プライベートでもイベントをやっていますが、アフターコロナはどうしていきますか。

佐藤：ハイブリッドだと思っていますね。特に私は、コミュニティは東京に限らず、いろいろなところから来て見ていただけるコンテンツを用意しているので。そこがオンラインになったことで、より多くの人に見てもらえるのはプラスになったんですね。

ですが、やはり東京でオフライン開催すると、偶然の出会いだったり、場所の温度感ってぜんぜん違うじゃないですか。そこも大事にしていきたい。やはりそうなるとハイブリッドで、オンラインも大事にするし、オフラインも大事にするかたちで作っていきたいなと思っていますね。

ブランディングのイメージで注力しているポイント

桃木：ありがとうございます。さて、次の質問は、「何かブランディングのイメージで注力しているみたいなポイントはありますか？」 どうなんだろう。

櫛井：とくにないと思いますが皆さんどうですか？

桃木：でも基本技術力が高いなどのベースはありませんか。もちろん高いレベルをやっていることは伝えてほしいし、低いレベルだと思われないようにというところは、逆にマイナスがないように気をつけている部分だとは思うのですが。どうなんだろう。

櫛井：書いてもらっているものは全部そうだとは思いますが、かといって、それが世界で一番すごいかと言われるとそうでもない感じはするので、そこだけ一点突破で「うちはここがすごいです」ということはしないですよね。

桃木：そうですね。その一点突破でどうこうできるものではないと思っているのと、これはさっきも言いましたが、基本多面的にいろいろ知ってもらうことが僕らの活動だと思っているので、ここだけやっていればいい、これをやると他にもすごく有機的に働くみたいなことはあんまりないかなあとは思います。三木さん、なんかあります？

三木：たぶんこれ順番というか、そんな明確に優先度が付けられるわけではないんですが。やっぱり技術力は高いっていうのとオープンな文化っていうのは、私たちが一番力を入れて発信していかなきゃいけない企業文化的だと思うんですよね。

LINEって大きな会社なので、これがスタートアップフェーズだったら技術力の高さ一点突破とかやると思うのですが、いろいろな属性の方がいて、いろいろなキャリアのステージの方がいるので、いろいろな方を大事にしている、その多様性みたいなところはしっかりと情報発信していかなきゃいけなくて。四角形の全部の点を広げていくみたいなような感じじゃないですかね。

桃木：基本はできているが、完全にできていると思える項目がないので、「どれもがんばんなきゃ」みたいなところあるのと、やっぱり「特にこのへんは」みたいなところや、推しポイントがあれば良いのですが、あんま長期的にこれをがんばりましょうとか、さっきも言ったんですけど「チームでこれをがんばりましょう」みたいなところは、そこまでないかなとは思ってたりしますね。ちょっと回答になっているか怪しいですが、次に行きましょう。

エンジニアの協力を得るために、個人的に工夫していること

桃木：さっきから何回か出てきていますが、「エンジニアの協力を得るために、個人的に工夫していることはあったりしますか？」 それぞれ個人的なノウハウを聞きましょうか。櫛井さん、どうしています？

櫛井：私はけっこうこれ系のやつを長くやっていて、どちらかと言うと、仕事として「じゃあこれお願いします」みたいなアサインされるのもいいのですが、やっぱりいいコンテンツって、もっと能動的に出てくることのほうが大事だなあと思っています。みなさんに協力をお願いする時は、協力する前に、自分からいろいろなことをエンジニアに対してやってあげるという言い方は変ですが、「こういうことをやったら、きっとエンジニアはうれしいだろうな」っていうことをひたすらやり続けて。

なので、言葉は直接的過ぎますが、恩を売っておくじゃないですけど、その関係値を高めておくみたいなことは、ふだんからものすごく意識してやっていますね。

桃木：さっきの非エンジニア的な話もそうですが、やっぱり役に立つ存在だと思われ続けることって。けっこう大事だなと思いますよね。

櫛井：そうですね。「こいつ使える」って思われないと、彼らと一緒に仕事する意味がないので、僕らが「使えるやつだよ」っていうのをふだんからアピールするというか、ちゃんと実績も出していくのは大事かなと思ってやっていますね。

桃木：そうですね。逆に言うと、なんか要望をもらった時には、それに100パーセント応えられるようにみたいなところと、何かお願いする時にも、相手側の状況を少しでも把握したうえであたったり、ベネフィットをちゃんと伝えた上でコミュニケーションかなと思います。三木さん、この辺Tipsあります？

三木：そうですね。この会社ってそういう意味で言うと、すごいやりやすい会社だなと思うのですが。

桃木：どういう点で？

三木：基本的に何かアクションを提案するとき、稼働工数とか費用対効果とか、どういうメリットがあって何がエンジニア組織にとってうれしいのかとか、明確に示す必要があると思うんですよね。

ただこの会社って、まずやってみようっていう前提で「あ、じゃあやりましょうよ」「どういう設計にしましょうか」みたいに、エンジニアと会話しながら進んでいったりすることもけっこう多いので、すごく協力的というか、わりと性善説な会社なんじゃないかなっていう気がします。答えにぜんぜんなっていないけど（笑）。

だからエンジニア組織、そのレイヤーのエンジニアにとって、どういうメリットがあるのか説明することが大事ですよね。それはいつでも考えますよね。

桃木：あとは個々人や組織ごとにやっぱりツボが違うので、そのあたりを意識することはけっこうあるのかなって思っていて。この人はここらへんに言う、みたいなのやっぱある気がするんで、やっぱり日々のコミュニケーションがけっこう大事だなとは思います。

どうでしょう、祥子さんも何か。

佐藤：日頃の人間関係の構築っていうのも大事かもしれないのですが、やはり業務として協力してくれた時に、仕事だから当たり前だよね、と思わずに、本当に協力してくれて感謝している気持ちを、もう真摯にほんとに伝えるというか。「本当にありがとうございました」と、本当に思っていることを伝えるようにしています（笑）。

桃木：僕、逆もあると思っていて。なんか言い方はアレかもしれないですが、やっぱりエンジニア、その一緒にやっていただくエンジニアの組織であったり、その個人にとっても回り回ってチームのメンバーが増えるとか活性化すれば、役に立つことだと思うので。

こっちから頭を下げて頼み込んでやるもんでもないよなと思うものはあるので、いかに価値を感じてもらうかとか。あとは僕らのアクションにどれだけ賛同してもらうかみたいなところはけっこう大きいし。

とはいえ、人間なので、感謝をされたらうれしいみたいなことや「あいつら気前がいい感じだったから、もっかいなんかあったら付き合ってやるか」って思われ続けること、両方大事なんじゃないかなとは思いますけどね。

佐藤：うんうん。

桃木：ここらへんで言うと、僕は個人的には変に下手に回りすぎても嫌だなと思う部分があるので、成果とかアクション自体に価値を感じてもらうことは意識してたりするかなとは思います。みんなそうだと思いますが、表現のというか、特に祥子さんはホスピタリティが強いということだと思います。

藤原：あと1個、みなさんが言っていないことで言うと、たぶんみなさんがそういう感じで活動した結果でもあると思うのですが、エンジニア組織側の、うちで言うと執行役員や組織のトップの人たちが、私たちの活動に対してまず理解を示してくれていて、かつ「そういった活動にみなさん協力しましょうね」っていうのをわりと言ってくれているのも、けっこう大きいのかなって思っています。

それが、さっき三木さん言ったやりやすさにもつながっているかなとは思うので、ちょっと会社によってフェーズは違うと思いますが、技術側のトップというか、技術組織側の人たちの協力が、まずは重要とは思います。

桃木：あんまり使わないですけど、たまにCTOに連絡して「すみません、ここでこういうこと言ってもらっていいですか」って、CTO砲と呼んでいるんですけど、それをぶっ放して「これは全体でやるべきことなんだ」って認知させるみたいなこともやっていたりします。

櫛井：（笑）

エンジニアのモチベーションアップ

桃木：次ですかね。「LINEのエンジニアさんは非常に優秀ですが、残業や時間外において、貴社のジュニアエンジニアのモチベーションアップはどうしていますか？」 ジュニアというか、これから育っていくレベルの方が、勉強に当てる時間とかをどうしているか、みたいな感じかなと。

これちょっと僕らというか組織的なものなんで、藤原さん、こういうのって、構造とか制度的にどうなっているんでしたっけ。

藤原：これは難しい質問ですね。どっちかと言うと、桃木さんが言われたとおり、エンジニア組織側の、マネジメント側の意識な気がしていて。

直接かどうかはわかんないですけど、自己学習をしてキャリアアップしたら、それがその人にとって、例えば評価されるとか、個人にとってのキャリアアップになるように、うまくマネジメントしていくしかないのかなと思います。

LINEは幸いにして、たぶんこのあたりは最初の文化として、そもそも自己学習にポジティブなエンジニアが多い文化になっているので、私たちは幸せながら、あまり悩んだことがないっていう感じですかね。

桃木：あれですよね。採用の基準でも、やっぱり技術などを自分でそうやって勉強、知識を付けることが好き、それを活かすことが好きみたいな部分は、明文化されているわけではないですが、やっぱり求めることが多かったりするのと。

新卒でも、やっぱりそういう成長性、自分で成長していけるかどうかみたいなことがけっこうあるので、お答えのとおり、そういう方しか入らないようになっているってのが正直なところかなと思います。むしろ機会をもっと提供していかないといけない。こういうのも勉強できてうれしいみたいな制度だったり企画は、こっち側がやっていかないといけない部分かなと思いますが、わりと自分で積極的に自己学習される方が多いかなあっていうのが強いですかね。

佐藤：でも1個思うのですが、優秀であれば、自己学習しなくてもいいんじゃないって思うんですけど。

桃木：今優秀ですけど、来年優秀じゃないかもしれないから、そういう意味でアップデート欠かさない人が多いと思っていて。今の技術で一生飯を食うみたいなやつはあんまりというか、うちの会社のエンジニアっぽくないかなあと思いますが。

櫛井：はい。

桃木：ではそんな感じですね。けっこうそれはシニアだろうがジュニアだろうが、変わらず知識のアップデートとかインプットに関してはポジティブな方がほとんどなのがうちの会社かなあと思います。そこに僕たちが苦労することはあんまりないかなあと思います。

あと1個か2個ぐらい答えます。「PRの大変さを僭越ながら感。ネタ探しはDevSucがやっているのか、部署などによってカルチャーなどはありますか？　表現の仕方で気をつけていることなど。」

ネタ探しは、どうなんでしょうかね。さっきもいろいろありましたが、僕らが持ちかけるものがあれば「これやりたいんだけど」というのもあって、わりと半々というか、それに近いバランスぐらいかなあと思っているんですが、どうなんでしょう。

櫛井：ものによるというか、イベントドリブンな時もあると思っていて。例えば僕はセキュリティとインフラの担当していますが、対外的に大きなイベントはそれぞれあるんですね。そこのイベントに対して、僕らが「こういうことをアピールしたいから、こういう取り組みしませんか」っていうふうに、こっちから呼びかけることもあるし。

あとは「こういう新しい技術が出たから、ここら辺をPRしていきたいので、何かしらいい手法ない？」みたいな。半々ぐらいですかね、やっぱり。

桃木：きっかけはこっち側が「なんかこういうのネタないですか」と問いかけて出してもらったり、「この辺がおもしろいんでアウトプットしませんか」みたいなのもあるとは思いますが。僕らがハブとして機能するけど、ネタを現場の人に全部聞いて回ってみたいな感じではないので、きっかけは与えるけど、基本は出してもらうみたいな感覚ですかね。祥子さんはなにかあります？

佐藤：定期的に部門の方々とコミュニケーションを取りながら、「今どういうことをやっていますか」や「どういうことができますか」というのはヒアリングをしているので、2週間に1回はそれぞれの部門の方とお話しして、キャッチアップはしていますね。

桃木：なるほど。基本的には協力してやっているのと、ネタ探しというか、ネタが出てくるようなコミュニケーションをけっこう密にやっているところがあるかな。

佐藤：うんうん。

桃木：あと部署、カルチャーの違いはまあありますね。やっぱり外国籍の方が多いところもあれば、日本人がほとんどみたいな部署もあったり、情報発信に積極的、消極的みたいなのもどうしてもあったりするので。

特定のどの表現の仕方を気をつけているなどはないですが、やはりモチベーションどう持ってもらうかのために、工夫というか表現を変えているみたいなところはあるかなあとは思います。このあたりで三木さんはどうですか。

三木：これはたぶんけっこう私たちの仕事にとって大事なことかなと思っていて。エンジニアの属性によって、マナーがぜんぜん違うじゃないですか。

フロントエンドやクライアント、サーバーサイドのエンジニア、セキュリティ業界のハッカー、機械学習、コンペティション出ているようなKagglerの人たち。あとはアカデミアの人たちなど。

もう全部それぞれコミュニケーションスタイルを変えなきゃいけないと思うんですよね。それは社内にしろ社外にしろ、どういうふうな話をすれば価値があると思ってもらえるかとか、何がうれしいかなど、やっぱ大事にしていることが違うので、それぞれの担当部署の人たちも、業務分担している私たちも、理解しているんじゃないですかね。

桃木：なのでむしろ違いがあることが当たり前で、それが前提で、画一したコミュニケーションにならないようにというか。ここはAの部署で通用したからBでも、ていう感じではなく、表現の仕方を気をつけるのが仕事だと思ってやっている感覚のほうが強いのかなあと思います。

さて、ラストですね。「協賛の、予算以外のハードルというか、要件。協賛しない判断みたいなのは、どういう時にしているんですか?」　これちょっと表現を誤ると語弊がありそうなんで、正確に誰か言ってほしいのですが。

藤原：協賛しない時は、自社にあまりにも関係のないもの。自分たちが使っていない技術に対しては、完全にやらないというのがありますね。それぐらいじゃないですかね。あとは、もう時と場合によるというか。

桃木：あとはエンジニアに聞くのもけっこうありますよね。「このイベントからオファーが来ているんですけど、どうですか？」「そこはちょっと、自分は行かないかな」などを参考にしたりはけっこうあるかなと。

藤原：目的にもよりますが、その業界への貢献なのか、あとは採用したいのかによって違って、採用したい時はもう現場のエンジニアに聞いて、ロールモデルに近い人が「ここには参加していないよ」って言われたら「じゃあ今回見送りましょう」という判断はありますね。

桃木：わりと財布的にはガバガバというか、使えるものはあるんですけど、「ここはメリットないよね？」となったら別にしない、みたいなところはあるし。イベントの性質が変わっていくところでも、過去にやっていたものを止めることもあれば、新しくどんどん始めるみたいなこともある。その辺もわりと個人の裁量で「これはいいと思います」が通ったりはします。個々人で総合的に判断して提案というか、みんなに共有・相談していることが多いかなあと思います。

予定通りしゃべりすぎたので、締めに入りたいと思うんですけれども。

LINE Developer Successでのやりがい

櫛井：見ていて、これはぜひ答えたいなっていうのがあったので、それを答えたいなという気はしますけどね。

桃木：どれですか。

櫛井：「支える側にとって、エンジニアサポートのやりがいとか楽しみって何ですか」っていうやつとか？

桃木：ああ、なるほど。祥子さん、やりがいはありますか。

佐藤：やりがいというか、それが得意だからと私は思っていて。そこで一番自分の力が発揮できるからこそやっている、というところはありますね。

桃木：そうですね。僕も別に案件がエンジニアじゃなくてもいいんだろうなと思う部分もありますが、やはりここをやれる人は少ないし、こういうところでやれて、自分は明確な成果はないが貢献できているなって感覚はあるので、そこがけっこう大きいかなと。

別にイベントに人がいっぱい来たり、採用でなんか人が集まったり、作った情報がリーチしたりなど、いろいろあるとは思いますが、それの積み重ねかなあって思うのと、まだ大きな成功はないです。はい、櫛井さん。

櫛井：はい（笑）。やりがいや楽しみって実はそんなにはなくて、それをモチベーションにすると続かないというか、一定のパフォーマンスを出し続けられないなと思っているので。あればあったでいいのですがそこではなくて、どちらかというと、私はエンジニア全体、業界全体がもっとよくなるように一緒にやっていきたいので、そこに対して何ができるか、LINEの中では何ができそうかなどを考えてやっているっていう感じですね。答えになっていないかもしれないですが。

桃木：はい。三木さんは？

三木：やりがいは、私たちはその技術フィールドでマーケティングやPR、人事っぽいことをやっているわけじゃないですか。で、今でこそ技術広報やエンジニア採用、エンジニアサポートみたいな職種ってけっこういろいろな会社が採用職種として出していると思うのですが。

やはりそういうのって、情報がそこまで昔はなかったと思うんですよね。だからわりと手探りでいろいろやらなきゃ何があたるかわからなかった。まあみんなたぶんそうだと思うのですが、そういうアクションを通して、いろいろ手探りで今まで知見を積んできた、そういう答えがないことをやっていることが一番のやりがいですかね。

桃木：まあそうですね。この会社に限って言うと、やっぱりお金の面もそうですが、あまり守備範囲が限定されないので「これやったらええやん」をけっこうやれるのは、働く上でのやりがいかなとは思いますね。手段を問わないというか「これやったほうがいいですよね」が拾えるのはいいかなと思います。最後、藤原さんのやりがいはなんですか？

藤原：みなさん言ったところと近いですけど、エンジニアってやはりコード書く、ものづくりの仕事が多いかもしれないですが、こういうサポートの仕事って組織全体に影響を与えられるな、と思っていて。で、私たちがやったことが、その組織全体がよくなれば、その組織が強くなるかなっていうのが一番のやりがいかな。

あと、LINEでよく使われる言葉だと思いますが、「速く行きたいなら1人で行け。遠くに行きたいならみんなで行け」と。みんなで行く、そのサポートができるのが私たちかなと思っています。

桃木：あまりチーム内で使わない言葉が出たのでびっくりしましたが、そういうことですね。あとこのチームとして感覚の近い人たちと協力してやれるみたいなところもけっこうあるのと、背中預けられるみたいなところはあるかなあとは思いますが。

ガッツリ30分以上押したので、いい加減締めたいと思います。ありがとうございました。