株式会社スリーシェイク Sreake事業部 部長 手塚卓也氏
経営を意識せずに技術に専念している自分が「甘えてる」と感じました――松本亮介氏の分岐点
――あらためて簡単な自己紹介をお願いします。
手塚：手塚卓也と申します。当初はスタートアップでインフラ系エンジニアをしていて、スリーシェイクに転職してからはクラウドネイティブ領域に特化し、SREの支援やコンサルティングをしています。最近ではエンジニア半分、残りは自社プロダクトの成長にフォーカスすることが増えてきました。
松本：松本亮介です。学生時代にインターネットに興味を持ち、大学で研究を続けたい気持ちもありましたが、世の中を知らずに研究することに抵抗があり、一度はレンタルサーバーなどを提供している企業へ新卒として入社しました。数年して大学の博士課程でインフラ周辺の研究をしながら外部へアウトプットするうちに縁があり、前職のGMOペパボへ。そこでエンジニアとしてだけではなく、企業研究の立ち上げ、研究者として論文執筆、プロダクト開発に関わるなどしてきました。
もう少し研究にフォーカスしたいと考え、2018年にさくらインターネット研究所に移りました。コロナ以降は研究の意義などを考えるうちに、企業の組織、事業、プロダクトの成功、研究者のマネジメントの必要性に気づき、組織設計や評価制度にも関わるようになりました。
同時並行でバイオ系のスタートアップの取締役で経営にも携わっています。「お金も人もいないけど、やりたいプロダクトがある」というのは、今までとは違う面白さを感じているところです。
――近年エンジニアが事業やプロダクトの成功にも貢献するようになってきています。その背景とキャリアへの影響について教えていただけますか。
手塚：自分自身、そんなに長いキャリアはないのですが、現在と比べると、恐らくかつてはエンジニアの選択肢はあまりなくて、より職人職が強いというか技術に限定した仕事がほとんどだったのかなと思っています。近年ではSaaSビジネスが加速していて、エンジニアリングした先を見通せて、選べる時代になってきているのだと考えています。
キャリアの影響を考えると、私はインフラエンジニアを経てSREになりましたが、インフラでキャリアを積んできたエンジニアはシステム目線で考えるのが「当たり前」でした。一方で、SREはユーザー目線でシステムのデータを捉えて設計します。ここはぼくのSREの好きなところです。プロダクトを成長させるためのエンジニアリングをすることで、キャリアとして評価されて市場価値が上がるということが起こるという気がします。
松本：ぼくは2005年前後から就職活動を通じて業界を見てきました。当時エンジニアやプログラマという職業の見せ方は「プロダクトや事業を成功させる」ではなく、役割分担で定められた技術実装に特化していて、開発と運用の分業も明確でした。コミュニティも変化してきています。かつては技術力を高めることにフォーカスしていました。
今では「みんなでチームとして、プロダクトの価値を高め続けよう」となっています。今となっては当たり前ですが、かつては運用と開発はあまり連携することなく、エンジニアにプロダクトの成功や経営的な貢献を要求しない前提がありました。徐々にエンジニアが価値を高めることを考えるようになり、2010年前後からインフラのコード化やDevOpsが始まることで、「一緒にやったほうが、会社もエンジニアも幸せになれる」という発想へと結実してきたと思います。
そうしたあたりから、スタートアップへの注目も高まってきたのでは。実際にスタートアップだとお金もないし、人も簡単に雇えず、事業を最小構成からうまく育てて、成功させなくてはいけません。そうなると分業ができないから、いろいろとできる人と一緒にやらないといけないという背景もあるかと。
――ご自身の体験ではどのような影響がありましたか
松本：技術顧問としていろんな会社やスタートアップと関わるなかで、会社のことをあまり真剣に考えずに技術に専念している自分が「甘えてる」と感じました。そう思えたのは、ちょうど技術だけでなく、経営や資金調達、プロダクトの価値創出周りに強く興味が生じていた時期だったからかもしれません。スタートアップのように資金調達しなくてもいいのかとか、いかに自分の取り組みを会社や社会への貢献に繋げていかなくてもいいのかとか。どちらが良いとかではなく、資金があるからこそできることに対して全力を尽くしておらず、ぬるま湯に浸かっているように思えたのです。エンジニアリングや研究をするからには、何らかの価値に繋げて社会に還元したい。最初はそれが論文やソフトウェアだと思っていましたが、それでは足りない、遠い気がして。
スタートアップから始めた手塚さんもそうですが、もっともがいている人がたくさんいるという現実を見て「これはすごい！」という驚嘆と尊敬があり、自分の分岐点になりました。それが2019年ごろ。次は新しい環境作りとか、それを通じて社会に価値を還元することが2020年代のテーマになっています。
――エンジニアは技術力があるから、社会貢献を考えると、そうした作用が生まれてくるのですね
松本：実践している人たちを見て気づかされました。スタートアップだと技術力やスピードを高めていかないと競争に負けてしまいますし。
手塚：ぼくは逆かもしれませんね。エンジニアを始める前からスタートアップや事業に興味がある人間でした。エンジニアリングは手法としか捉えてなくて、エンジニアとして残るためというよりは、エンジニアリングを主軸としながら事業をどうするかにフォーカスしています。
自分なりに技術を追求していくなかで、自分たちの実装が松本さんはじめ大きな巨人（研究成果）の上に載っているんだなと実感しています。善し悪しは関係なく、経験していることの違いはありつつも、互いにリスペクトをする必要があるなと感じています。
さくらインターネット研究所 主席研究員 松本亮介氏
エンジニアがプロダクトや事業への理解を深める方法
――エンジニアが事業やプロダクトの成長に貢献することを考えた時、具体的に何から始めたらいいか分かりづらいと思います。何を足がかりにするといいでしょうか。
手塚：エモい表現ですが、事業やプロダクトに愛があるかだと思います。愛があるから、もっとこうしたい、よくしたいとか出てきて行動が変わってくる。愛がないなかで、事業やプロダクトをよくしようという発想はなかなか出てこない。プロダクトをわが子のように思うのは最初の前提として必要かなと思います。
――プロダクトマネジャーにお話を聞くと、プロダクトへの愛を重視する方は多いです。エンジニアがプロダクトに愛を持つためにどこに着目するか、何から始めるか、ご提案はありますか？
松本：自分のチャレンジでもあるのですが、エンジニアリングをしながら事業やプロダクトを自分ごとのように意識できるようになることは「没頭するにはどうすれば」という問いだと思います。
エンジニアに愛を持ってもらうには、プロダクトをまとめる人がプロダクトの情報を提供することや、どこが面白くて、なぜ自分が熱意を持てるのかを言語化して伝えられるかが大きいと思います。
だからエンジニアの問題ではなく、マネジメントや経営によるものだと思っています。先述した通り、かつてはエンジニアに伝わる情報が少なかった。まだその流れがあるなかで、エンジニアに経営目線を持てというのは無理が出てきます。そうした目線や文化を醸成していきたいのであれば、事業の情報を持つ人が情報を提供して情報の格差をなくす。かつそこにどれだけ熱意を込められるかが最初にやるべき大きなことかと思います。
手塚：とても大事なことですね！
――エンジニアからできることがあるとしたら、事業に通じる人たちと積極的にコミュニケーションとることになるのでしょうか
松本：そうですね。反応や関心がないなかで情報を与え続けるのはしんどいですから。もしエンジニアで事業やプロダクトに興味があり、キャリアのために何をすればいいかと考えているなら、機会があれば興味があることや、熱意をもって反応していくと、相手もより多く情報を出してくれるようになると思います。双方の努力や歩み寄りが必要ですね。
手塚：そのあたりはコロナで難しくなりましたよね。難しい話題を伝えるにしても、反応や熱量が分かりにくい。そうすると発信する側として迷いも生まれますし。「ただやめたら終わり」というのも分かるので、情報を発信し続けるのは重要です。
松本：オープンソースのコードを書いて、使ってもらう、反応してもらう時の楽しさは事業やプロダクトにも共通していると思います。プロダクトを実際に使ってもらった時の反応に触れてみるとか、そういう体験をするのもいいかと思います。
――組織のプラクティスというところまで視点を拡げると、何かポイントはありますか？
松本：ぼくだとスタートアップの人たちと関わったことが転機でした。事業やプロダクトの楽しさもあり、制限があるなかで技術もプロダクトも両方考えなくてはならない。お金がなかったら誰かにお願いするか、収益を上げる方法を考えなくてはならない。そうした苦労に直面している人たちと関わることで多くの学びがありました。すぐにはできないかもしれませんが、スタートアップのエンジニアまたはスタートアップに関わるエンジニアと接する機会があるといいかもしれません。目から鱗が落ちると思いますよ。最も刺激的な方法ではないかと思います。
手塚：これまでの流れと逆流するようで難しいのですが、これまで愛とスピードで突き進んできましたが、資金調達などを通じて「できないことができるように」なってきています。
企業の規模が大きくなるなかで生産性を高めることを考えると、（松本さんが言うように情報を与えるのとは対照的に）他の認知を与えずに集中する環境を作ることも大事な要素だと思っています。それぞれの職人が職人らしく仕事に没頭できる環境も重要だと思っていて、チームトポロジーの話になるのですが、無駄なコミュニケーションを必要としない組織設計も規模が大きくなるにつれて重要になると考えています。明確な答えはないのですけど。
自分のパフォーマンスを価値に繋げるために、データと正しく付き合う
――ここまではマインドセットでしたが、もう少し具体的なことを。事業やプロダクトの成功を導くために、どのように指標を立てていくかなどのポイントはありますか。
手塚：SRE領域に絞ると、ユーザー体験や一連の処理（クリティカルユーザージャーニー）に基づいたSLOを作成し、そのユーザーに対してシステムの信頼性がどの程度達成できているかのKPIを作ります。それをもとに運用と開発の優先順位をつけていきます。これはエラーバジェットを通じた手法になります。
ただしこれを教科書通りにやれば大丈夫とも言い切れません。世の中に大きな影響を与えるシステム障害を見れば分かると思いますが、自分たちで設定したSLOとしては大丈夫だったとしても、社会やお客様が心情的に許してくれない場合もあります。そういう意味ではSLOの設定の誤りとも言えますが、社会やユーザーが本当に求めていることは何か、常にステークホルダーを見ながら継続的に組み替えていく必要はあると思います。
また、そのプロダクトが何を実現したいかにもよります。例えばぼくらのセキュリティ商材だと、いかに多くのユーザーに多様なユースケースで使用してもらえるかにKPIを置いている状態で、そのなかで磨いています。
アジャイル開発では、スプリントのバックログから開発量のKPIを取るのですが、運用していて粒度の設定で難しさを感じています。一方でユーザーからのフィードバックがどういう成果になるかにKPIを置くと、いいかもしれません。
よく思うのは、指標は状況次第であり、スタートアップも大企業でも共通して言えるのは「ないなかでどう戦うか」。どこも足りないものがあるなか、いろいろ工夫したり、採用の入口を用意したり。試行錯誤しながらKPIを増やしていくことになるかもしれません。
松本：頷きながら聞いていました。スタートアップで資金調達の根拠を考える時にいろいろと指標やストーリーが必要になります。KPIや何らかの指標に落とし込まないまでも、エンジニアが事業やプロダクトに貢献するための具体策を考えてみることですね。
例えばぼくが所属するところではビジネスコンテストを実施していまして、優勝したら会社から援助が出ます。個人が社内で資金調達に挑むような感じです。自分がやってみたいビジネスについて、コンセプトや必要な資金を15分くらいの資料にまとめるのはかなり大変ですが、こういうことにチャレンジする機会があれば挑戦してみるといい勉強になると思います。社会や事業に貢献したいと思うと、すごくいい資料ができあがったりします。
ですので「やりたい」と意欲があるなら、一歩を踏み出すしかありません。ビジネスコンテストに参加したり、スタートアップやプロダクト立ち上げに参画したり、プロダクトマネジャーが近くにいるなら関わりを増やしてみたりするのもいいかと思います。自分のやる気と行動力を試すことにもなります。
そこを超えたら実際にKGIやゴールからどんどん分解して、具体的なKPIなどの指標に落とし込んでいけます。技術力があるなら、技術ベースで設定していけば自分の取り組みがどのゴールに影響するかも見えてきます。実際の取り組みとしては多少の劇薬感はありますが、まずは行動に移してみることですね。
――これまで出てきたものをエンジニアやエンジニア組織はどのように活用していくといいでしょうか。
手塚：指標はあくまでデータでしかありません。データとなる結果が生まれる背景には構造（組織構造や仕組み）があり、そこに何らかの力（実際の活動）を与えることで結果に繋がります。単なる数値を追っていたとしても的確にその構造と力の与え方を分析しないと道を踏み外しかねないなと思っています。
スプリントの数字がよくなかったら、体制を増やすなどの安易な対応に走りがちですが、開発効率を落とすようなメカニズムがあるはずなので、そこに目を向けていくべきです。チケットの切り方が大きすぎたからそう見えただけだったのか、何らかのトラブルが起きていたのかとか。
――パフォーマンスに関するデータの蓄積、分析、可視化でいいプラクティスはありますか？
手塚：パフォーマンスを発揮しているかどうかは抽象的な捉え方をする傾向があると思います。あるお客様はGitで何回コミットしたか、記事を書いたか、トークしたかのデータをとっています。ただし結果を判断するためではなく、推移の傾向を捉えるために使っています。「パフォーマンスが落ちてる？」と思った時に、データを見ながらその要因を分析するといった具合です。
松本：他でも聞いたことがあります。個人のパフォーマンスをデータから見ると、反感を買います。ケアに使うことが大事です。数字からパフォーマンスが落ちていると見えたとしても、現場をよく見るとそれを誘発する要因があります。数字は障害を取り除くためのケアや振り返りのための参考にするのがいいです。
――それでは最後に読者へメッセージをお願いします。
松本：今回はエンジニアの愛や内発的なものが出ましたが、興味を持とうとしているエンジニアの後押しやサポートをするのが自分の仕事であり、それこそがマネジメントだと思い始めているところです。だからぼくからエンジニアに事業やプロダクトに貢献するために「こうしてほしい」はあまりなくて、エンジニアを支援できるように先進的な大企業の評価を参考にしています。事業統括や経営の人たちはいろいろ試してもらいたいです。
手塚：いろいろと偉そうに話しましたが、できてないところがたくさんあって悩ましいところです。事業やプロダクトをリードする側の伝え方がエンジニアのパフォーマンスや愛に影響してきますので。まずは自分から！
