1人目スタッフエンジニア・kenkoooo氏が語る「技術力」よりも強力な武器

書籍名に使われることも増え、最近たびたび耳にするようになった「スタッフエンジニア」という職種。チームや会社の技術的な方向性をリードする役割を持つことが多く、ピープルマネジメントをしないIC（=Individual Contributor）のキャリアパスです。

日本国内ではまだまだ一般的ではありませんが、株式会社estieではいち早くスタッフエンジニアの役職を設け、今は「実践Rustプログラミング入門」の共著者としても知られるkenkooooさんが活躍しています。

「組織横断の課題を解決するのが僕のミッションです」と語るkenkooooさん。でもそう言われても、“組織横断の課題”のイメージもはっきりとつきづらいし、そもそもそうした課題をどうやって見つけているのでしょう？

kenkooooさんはスタッフエンジニアとしてどんな仕事をしているのか、また「組織横断の課題」を見つけたり解決したりするために、技術力よりも力を発揮する武器について、教えてもらいました。

• keyboard_arrow_down スタッフエンジニア＝組織横断の課題を解決する人
• keyboard_arrow_down 顕在化していない課題を逃さないために「話しかけやすい人」になる
• keyboard_arrow_down 間に立つ立場だからこそ。Slackはほぼ全チャンネルに目を通す
• keyboard_arrow_down 経営をリードするために、同じ視座を目指す

――まずはじめに、kenkooooさんの役職である「スタッフエンジニア」はどんな役割なのか教えてください。

kenkoooo：簡単に言うと、組織横断の技術課題を解決する役割です。複数あるプロダクトや開発チームに横断的に存在し、影響範囲が広い技術課題を、様々な職種の関係者と協力しながら少しずつ対応しています。

――「組織横断の課題」には、具体的にどんなものがありますか？

kenkoooo：この前ちょうど解決できたものとして、全社横断での社内APIの使い方に関する課題を例に挙げますね。

ある時、エンジニアから「社内APIがちょっと使いづらいんだよね」という言葉を耳にしました。詳しく聞いてみると「社内API経由で取得したデータを加工したり見やすく整えたりするためのアプリケーションを開発しているので、そのようなAPIを開発環境でも使いたい。でも機密情報が含まれている以上、外部から気軽にアクセスできるようにするにはリスクが高い。どうすればいいかわからない。」と悩んでいました。このAPIはestieが提供するあらゆるプロダクトで横断的に使っているもので、他のアプリケーション開発に関わるエンジニアも扱い方に悩んでいる可能性が高い。これはまさに全社横断で対処すべき課題でした。

こうした場合、前職のIndeedでは、VPNを使ってプライベートネットワークにもそれ以外にもセキュアに、かつ手軽にアクセスできるようにしていました。しかしこれを再現するにはお金と時間がかかります。そこで、コストを抑え、かつすぐできる解決策として、開発者のAWSアカウントに紐づく権限情報を使い、開発環境からAPIにアクセスするツールを開発しました。

このツールは、APIを使う開発者に付与されているアカウントの権限を利用していて、そのアカウントにログインすることでAPIへのアクセスが可能になる、というものです。アカウントを持っている人しかアクセスできないし、誰がアクセスしたのかすぐにわかりますから、プライベートネットワーク上のデータの安全性を守りつつ、開発者に開かれた状態をつくることができます。

しかしこのツールのベースになっているシステムは本来、AWSに精通した人が使うものなので、他の専門領域のエンジニアにとって使いやすくはないし、使うハードルも高い。使いやすくなるように整えたプロトタイプをつくったところ、口コミで社内に広まりました。それ以降は、使ってくれる人たちと相談しながらより使いやすくブラッシュアップしていきました。

この取り組みにより、機密情報を含むAPIを扱うサービスをつくる際、そうした情報を安全に管理しながら、より本番環境に近い状態で開発を進められるようになりました。

この課題については、僕が入社したときから、将来開発者の人数が増えたら何かしらテコ入れが必要になるだろうと思っていました。開発速度がガタ落ちするなど大きな問題になる前に、良い解決策が見つけられてよかったと思っています。

――組織横断の課題って、そもそもどうやって見つけるのですか？

kenkoooo：組織横断の課題の多くは「言語化しきれていないモヤモヤ」なので、社員との会話から見つかることがほとんどですね。

こうした、顕在化していない課題を見つける手段としては「出社して顔を合わせ、題名のない立ち話のミーティングをする」のが最も効果が高いと思っています。予定されたミーティングではアジェンダが設定されているので、すでに顕在化している課題の話に集中しがち。立ち話のミーティングでは、話す内容が決まっていないからこそ、日頃感じているちょっとしたモヤモヤがぽろっとこぼれてきます。そのモヤモヤこそが「顕在化していない、解くべき課題」であることが多く、それを掘り下げてみると、ある特定の部署だけでなく全社で解決したほうがいい課題だったりするんです。

こうした課題を着実に掴むためには、多くの社員に「話しかけやすい人間だ」と認識される必要があります。社員が困った時に自然と頼ってもらえれば、自分から課題を見つけにいかなくても、課題が舞い込んできますから。

また、職種問わず様々な社員と会話することで、それぞれの仕事への理解度も高まります。すると、別々の人から聞いた話が有機的につながり、課題の正確な影響範囲を掴みやすくなります。

こうして、コミュニケーションによって信頼貯金を貯めておくことが、課題を見つけるためにも、実際に解決するためにも、強力な武器になっています。

――多くの人に話しかけやすいと思ってもらうための関係構築は、どうやっていますか？

kenkoooo：雑談する時間を確保するようにしています。

話すトピックは全く決めていません。仕事に関することも、全く関係ないことも話します。雑談する機会を重ねる中で少しずつ「話しやすいかも」と思ってもらい、本当に困っている時にそのシグナルを取りこぼさないようにしておく、という長期的な取り組みなので、「今まさに何かに困っている」という話を引き出したいとは思っていません。先日はAmazonの倉庫で働いていた経験がある人に、倉庫のオペレーションの話を色々聞きました。

――雑談の機会は、どうやって用意していますか？

kenkoooo：週に2～3日は出社するのですが、出社した日は1日中、色々な社員と話しています。手が空きそうなタイミングで隣に座って「どうすか～？」と声をかけて、しゃべるんです。オンラインだと緊張しがちな人には、必ず対面で声をかけるようにしています。

逆に、オンラインでも対面と同じくらいリラックスして話せる人とは、定期の予定として1カ月に1回程度、カレンダーに予定を入れさせてもらっています。「トピックを問わない、肩肘張らない雑談」という意図が伝わるように、予定のタイトルは「対戦お願いします！」にしています。

この「雑談枠」は必ず確保するものとしていて、1on1など他の予定とのマージはしません。特に1on1は、課題感を拾ってネクストアクションにつなげるものですから、雑談とは目的が違います。相手もそのつもりで来ますから、緊張させてしまうでしょうし。

こうして地道に距離を縮めていくことで、普段のちょっとしたモヤモヤや困ったことをぽろっと話してもらえるようになっているのだと思います。

――雑談のほかに、話しやすい印象をつくるためにやっていることはありますか？

kenkoooo：Slack上にある「褒めてチャンネル」の活用です。このチャンネルは元々、皆が“ほめてほしいこと”を自主的に投稿し、それを見た人が褒めることによって、それぞれの活動の周知や達成感の醸成を行う、という趣旨のチャンネルなのですが、僕は少し違った使い方をしています。

一般的に社会って、失敗したら怒られるけど、できたことをみんなの前で褒めてもらうことってあまりないじゃないですか。これじゃ片手落ちだ、じゃあ僕が褒めなければ！という勝手な使命感から、「褒めてチャンネル」で、僕自身が褒めたいと思ったトピックを1日に何回も投稿していたんです。そうしていたら、いつの間にか「よく誰かを褒めている人だ」と認知されるようになりました。これも「話しかけやすい」と思ってもらうことに一役買っているようです。

――全社横断で影響範囲が広い課題ともなると、いざ取り組もうと思っても、解決のイメージがしづらかったり、何から手をつけるべきかわからなくなってしまうときもありそうです。

kenkoooo：いや、そうなってしまうことはあまりないですね。というのも、大体僕がやるべき課題って、関係者は多いものの、彼らの中に具体的なイメージがある場合がほとんどです。

まずは、関係者の中でも決定権を持つ人を全員集めて、MTGを開いています。MTGでは僕がファシリテーションして、関係者同士の認識を合わせながら、やりたいことを聞き取ったうえで取り組む優先順位をつけます。後はそこで決まった内容を僕が引き取って、形にするだけ。手を動かし始めてから「どうしよう」と悩むことはほとんどないです。

――関係者が集まったMTGで、打ち手を明確にするために必要なことを決めきるために、大切なことは何ですか？

kenkoooo：僕が大切にしているのは、関係者の主張や、それぞれから見えている課題のイメージを、僕自身がちゃんと理解することです。

的確な落としどころを見つける立場である僕が、話の内容を理解できていなければ、関係者同士の認識がずれたまま解決策を探すことになりますし、そうして見つかった解決策は往々にして的確ではありません。みんなで集まって話したのに、僕が手を動かし始めてから別の問題が露呈し、手戻りが発生していてはコスパが悪いんですよね。

僕が全員の主張やその背景を理解できていれば、認識がずれていそうなときに気づけるし、ずれを修正するよう言い換えて伝え直すことができます。MTGで決まった完成形のイメージに迷いも齟齬もないから、すぐ手を動かし始められるし、手戻りもなくなります。

――職種の異なる関係者それぞれの主張を齟齬なく理解するために、取り組んでいることはありますか？

kenkoooo：まずは、関係者みんなの役割や仕事の内容、立場などを理解しようと努めています。どんな仕事をしているのか、貢献したいと思っている対象は何なのか。

後者の「貢献したいと思っている対象」の違いは特に、認識に大きな差が出やすいポイントです。例えば営業であれば、今担当している企業に貢献したいと思っていたり、エンジニアであれば、担当しているプロダクトの内部品質に貢献したいと思っていたりします。最も大切にしているものが違う者同士だと、優先順位が高く感じる部分も、課題を解決したい理由も違ってくるでしょう。

こうした違いを把握するために効いていると感じるのは、Slackのほぼすべてのチャンネルに加入し、流れてくる内容に目を通すことです。営業の商談議事録から、チームでの普段のやりとりまで、ざっくりと流し見しています。

――Slackをそんなに見ているんですか‥！自分と関係のないチャンネルの内容を、うっとうしく感じてしまうときはないのでしょうか。

kenkoooo：昔は、自分と関係ないチャンネルに加入させられるのは本当に嫌でした。上司などに入れられたチャンネルも、関係ないと思ったら勝手に抜けるくらい（笑）。

でも同僚に、全チャンネルをくまなく見ている人がいて。その人が「心から他人事だとおもって読んでいる」と言っていたことから、Slackを見るのが楽しくなったんです。当時の僕は、チャンネルに入ったからには、チャンネル内で語られる内容を全て知ってなくちゃいけないような気がしていました。だから仕事上直接関係のないチャンネルに入れられた時「自分の仕事と関係ないのに、自分ごととしてキャッチアップしなくちゃいけないのか！」と辟易していたんです。でもその人と話して、自分の仕事と関係の浅い内容を単なる「読み物」だと捉えられるようになってから、読む際のプレッシャーを感じなくなりました。

また、その人に「未読一覧画面でエスケープキーを連打すると、参加しているチャンネルの未読メッセージを、一気にサクサク見れるよ」と教えてもらってやってみたら、これが楽しくて。閲覧にまつわるストレスもなくなりました。

今となっては、Slackを見るのは趣味です。知っている人の話しか流れてこないSNSのような感覚で、あらゆるチャンネルを徘徊しています。

――「スタッフエンジニア」と聞いて想像していたよりもずっと「会話」の重要さを感じました。最後に、これからもっと成長していきたい点について教えてください。

kenkoooo：経営と同じ目線で物事を考えるために、視座をさらに高めたいですね。

今は、定期的に経営メンバー、主にCTOと会話をする時間を設け、経営方針と自分の仕事の方向性を合わせていっています。でも本来「スタッフエンジニア」というポジションに求められているのは、今のように経営メンバーに合わせていくことではなく、経営メンバーとともに会社をリードすることだと思います。そうできるようになるために、経営と視座を揃えていきたいです。

実務においては、中長期的な課題に向き合う時間を確保することにもっと注力していきたいと考えています。短期的な課題は、自分ひとりが頑張ればどうにかなることが多いので、自分ひとりの時間を確保すればすぐ対処できます。でも中長期的な課題というのは、影響範囲が広い分、解決のためには色々な関係者を巻き込んでいかなければなりません。だからいまは、関係者1人ずつとじっくり話していく時間を設けることに力を割いています。

estieのより良い未来のために、この仕事や課題と向き合っていければと思っています。

取材・構成・執筆：光松瞳
編集：田村今人