目次
■エンジニアの軌跡
2016.09.14 2024.03.28 約6分
さまざまな企業で働くエンジニアとリレー形式で対談を行うDevRelay。vol.7はスマートニュースの坂本卓巳氏（@takus）です。「開発者にとってより使いやすい基盤を作り上げていきたい」と語る坂本氏。本記事ではそんな坂本氏のこれまでのキャリアと今後のビジョンをお聞きしました。坂本さんご指名のリレー相手は、インタビューの最後でご紹介します！
idesaku：前回の株式会社fluct鈴木さんのご紹介で、スマートニュースの坂本卓巳さんにお話しを伺います。どうぞよろしくお願いします。
takus：よろしくお願いします。
idesaku：suzukenさん（鈴木氏）に伺ったところ、大学の学部が一緒だったとか。
takus：ええ、慶應の理工学部です。彼とは大学院も一緒でしたね。
idesaku：前回のsuzukenさんに「takusさんに何を聞いてほしい？」と尋ねたところ、ちょっと考えて「『スマートニュース、面白い？』と聞いてほしい」と言われたのですが……面白いですか？（笑）
takus：面白いと思いますよ（笑）。もちろん、仕事としてやっているので、人が少ない中でいろんなことをやらなければいけないといったような意味で、大変なこともありますけれども。
idesaku：そうですよね（笑）。少しずつ、スマートニュースにジョインするまでの経緯をお伺いしたいと思います。これまでのお話しでは、学生時代に「My365」のインフラ周りを手伝いながら、DeNAのインターンもやりつつ、卒業後はそのままDeNAに入られたということでしたね。そこでの選択肢のひとつとして、My365のチームに加わるというのもあったと思うのですが、DeNAを選ばれたことには、何か理由があったんでしょうか。
takus：当時の僕の興味が、より大規模なサービスをどう運用していくかにあったからです。My365だと、僕が関わっていた当時でダウンロード数が約100万、アクティブユーザー数だとそれよりも少ないといった状況でした。
一方で、DeNAが運営しているMobageは当時から数千万規模でユーザーがいましたし、特にソーシャルゲームというのはトラフィックが多いジャンルでもあります。その規模のサービスは、日本でも多くないですし、それがどうやって運用されているのか、それを支えるインフラはどんなものなのかを内側から知りたいという思いが強かったんです。
idesaku：DeNAでは、インターンとして関わったインフラ担当の部署にそのまま入ったのですね。現在のキャリアにも関わってくる部分だと思いますが、大規模サービスの運用についての勘どころは、そこで学んだのですか。
takus：DeNAには、新卒で入ったエンジニアに、メンターをつけてきちんと育ててくれる環境がありました。
例えば、システム上で何か問題が起きたときに、「とりあえず再起動」してその場をしのぐこともありますが、今後のことを考えたら、やはり「根本原因を特定して、そこを直す」ことが大切です。DeNAでは、システムやプロセスの内部で何が起こっているのかを細かく監視・調査するためのツールを独自にいろいろ作っていて、それらを活用して根本原因をつぶしていました。そういうやり方を、中でしっかり知ることができたのは良かったですね。
idesaku：では、そこからスマートニュースに移られたのは、何がきっかけだったのでしょう。
takus：「スマートニュースという会社の人が、インフラ周りができるエンジニアを探している」という話を共通の知人を通して聞いて、「SmartNews」アプリは自分も知っていたので話を聞いてみたというのが最初です。実際に、社長やエンジニアの方と話をしたのですが、「日本発で海外でもヒットするアプリを作りたい」という思いや、まだ定番が決まっていない「ニュースアプリ」というジャンルで、標準になるものを作っていきたいという所に魅力を感じたのが大きかったです。
idesaku：技術面というよりは、将来的なサービスの展開そのものに魅力があったということですか。
takus：もちろん、入社を決めるにあたって、他にもいろんな要素がありました。例えば、当時はAWSとオンプレの両方を触っていて、「AWSをもっと積極的に使えば、インフラの運用がより楽になるのではないか」と感じていたのですが、そのように自分が思い描いた仕組みを、スマートニュースで作って行けたら面白そうだと感じたのも、大きな要素のひとつです。
あと、スマートニュースには、東大の博士課程で物理や数学を専門に研究されていたような方が何人かいらっしゃるんです。そういう人たちと一緒に働くと、どんなことが起きるんだろうという期待もありました。
まだ、あまり取り組めてはいないのですが、例えば「機械学習」の方法論を「システム運用」と組み合わせると面白いと思っているんです。システム監視の際には、いろんなデータを収集しますが、単に「ある数値が閾値を超えたらアラートを出す」程度のものではなく、蓄積してきたデータの中から機械学習の方法論で何らかの「異常パターン」を早期に検知できれば、より運用が効率的に行えるはずです。
僕自身は、こうしたことを実現するのにどんなアプローチが可能なのか、十分にはイメージできていないのですが、ここにいるエキスパートの方々と情報交換することで、何か新しい仕事の進め方が見えてくるのではないかと思ったというのもありますね。
idesaku：しかし、「社内エンジニアの数が少ない」というのは、ちょっと意外ですね。というのも、takusさんは「Slack」に関する書籍の共同執筆（「Slack入門［ChatOpsによるチーム開発の効率化］」技術評論社刊）をされるなど、Slackに大変お詳しいイメージがあって。
社内にも導入されたとのことだったので、もしかしたら、社内エンジニアの数が急激に増えてきてチーム作業の難易度が上がっているので、それに対応する手段のひとつとして、Slackが挙がったのではないかと勝手に思っていたのですが、そうでもないのですね。
takus：実は、社内にSlackを入れたのは、当時在籍していた別のエンジニアなんですよ。スマートニュースでは、多くの外部のエンジニアの方が開発を手伝ってくれています。こうした環境では、見られるルームを案件に関わるものに限定するといったアクセス制御が必要になりますが、当時使っていたチャットツールではそれがかなりやりづらかったんですね。いろいろ調べてみたところ、そういう使い方なら「Slack」のほうが合っているという話になり、さらに今までできなかったいろんなことができるようになるという期待もあって、一気に入れ替えたといった経緯です。
idesaku：そうだったんですね。いや、今日、ここ来る前に、その本を書店で探して買おうと思っていたんですけれど、見つけられなくて…。
（idesaku、ここで卓上に置かれていた「Slack入門」を手に取り、パラパラとめくりはじめる）
takus：あ、それ、よかったら差し上げますよ。
idesaku：え。ホントですか！ ありがとうございます。あの、よかったら著者ページにサインをいただきたいんですが…。
takus：いやいやいやいや。サインなんかしたことないですよ！ 困ったな。
idesaku：きっと今後、いろんなところでサインを頼まれることになると思いますから、どうか練習だと思って…。
（サインを入れてもらいながら）
takusさんがご担当されたのは、5章の「CIツールとの連携」というところですよね。スマートニュースでも、そういう形で有効活用していらっしゃるんですか。
takus：会社でというより、エンジニアだったらSlackの環境に自分でどんどんインテグレーションを追加できるので、各自が好きなように使っているという状況ですね。スタートアップに来るようなエンジニアって、問題を自分で解決したいという人が多いと思うんですよ。そういう人が何かやりたいときに、いちいち周囲にお伺いを立てなければならないような状況はない方がいいと思っているので、そういう環境を目指しています。
idesaku：職務が厳密に分けられている環境だと、お互いに「お伺いを立て」あうとか、それが億劫だから自分だけでやるといった状況ができがちですよね。
takus：それぞれの作業範囲を明確に分けてしまって、そのルールを徹底したほうがいいという考え方もある一方で、いろんな担当が、それぞれ独自のやり方で仕事を進めるようになると、全体の効率が下がるリスクも高くなると思うんですね。そこには、全体を通して見ないと分かりづらい「ムダ」があるかもしれないですし、ほかの人を手伝おうと思っても、何をやっているかが分からないので、手が出せないという状況が出てきてしまうかもしれない。
そのあたりのバランスをとるために、共通化できるところはしてしまって、その上であれば好きなことをしていい、という環境を作っていくことが重要だと思っています。僕は、この会社でインフラを担当しているわけですけれども、ただデータベースやサーバーのお守りを一所懸命やるという感じではないです。開発担当者が、より開発に専念できる環境を作ること、例えば開発していく中でうっかりシステムの一部を壊しても自動的に復旧する仕組みを設けるとか、そもそも大きくは壊せないような施策を打つといった、そんな基盤を作っていくことを仕事としている意識が強いですね。
idesaku：それぞれの役割を持った人ができることを、完全に限定することで不都合を防ぐという管理体制よりも、ある程度、それぞれにやりたいことができるようにしておいて、もし何かミスがあった場合でも、クリティカルな事態を招かないような環境をあらかじめ作っておくほうが、全体の効率が高まるという考え方なんですね。
takus：スマートニュースには、海外のカンファレンスへの参加やオフィス訪問などを社費で行える制度があるんですが、僕はそれを使って、カリフォルニアで行われた「SREcon」というイベントに参加してきたんです。
「SRE（Site Reliability Engineering）」は、従来の「インフラ管理」の概念を広げて、「サイトの信頼性を向上させるためのエンジニアリング」を実践していこうという取り組みなんです。
で、そのSREconには、NetflixでSREをやっているエンジニアがスピーカーで来ていて「Netflixでは、開発者がインフラ上であらゆる操作ができるようになっている」みたいな話をしていたんです。
とはいえ、開発者側で勝手に全てのEC2インスタンスを止めたり、S3のデータを消したりできたら困りますよね。
idesaku：困りますね。
takus：なので、彼に直接「本当に、そんなに自由なの？」って聞いたんですよ。そしたら、彼が近くにあったMacを指さして「本当だ。やろうと思えば、あそこからNetflixを全部壊せる」って（笑）。
idesaku：「あそこから全部壊せる」（笑）
takus：まぁ、全部壊すことは滅多にないにしても、あまりに開発者側での自由度が高いと、ちょっとした操作ミスやコマンドの間違いで、重要なデータを消してしまったり、システムを壊してしまったりするんじゃないの？と、聞いてみたんです。
すると、彼が言うには「そういうことが起こらないように、NetflixのSREチームは、独自のツールを作って、洗練させている」そうなんですね。ほとんどの開発者は、そのツールを通じて必要な操作を行っていて、それを使っている限りは大きなミスや、致命的な事故には至らないということらしいんです。
Netflixの社風を表す言葉として「自由と責任（Freedom and Responsibility）」というのを良く聞きますよね。サービスを作っている人間が、それを良くしていくための方法を一番分かっているという認識のもとで、「自由」に行動することを後押ししつつ、それが事故に繋がったりしないよう賢く立ち回る「責任」を果たすことも強く期待される、そうした文化をすごく高いレベルで形にしているからこそ、あれだけの規模のサービスを、スピード感を持って展開していくことが可能なんだと感じました。
idesaku：SREconの話が出たので、続けてお聞きしたいのですが、takusさんはスマートニュースのインフラ技術者として「SREチーム」に所属しておられるんですよね。
takus：はい。そうです。
idesaku：最近、メルカリさんやRettyさんをはじめとして、国内でも、ネットサービス企業のインフラチームが、次々と「SRE」を標ぼうしているような印象があります。この「SRE」とは、そもそも何なのでしょうか。
takus：正確な定義ではないのですが、僕が個人的に持っているSREのイメージは「システムの運用上で起こってくる問題を、ソフトウェアの力を使って解決していくアプローチ」です。
例えば、いわゆる旧来の「シスアド」的な管理のアプローチだと、システムの規模が大きくなって、いろんな問題が出てきたときに、どう解決するかというと「関わる管理者を増やす」ことで対応していくようなイメージなのですね。
ところが、GoogleやFacebookでは、世界中にある何千台、何万台のサーバーを運用していかなければならない。こうなると「人を増やす」対応では限界がありますよね。SRE的なアプローチでは、より少ない人数で、巨大なシステムを動かすために「ソフトウェアによる自動化」を最大限に活用することを考えるわけです。実際、Netflixでは、190の国向けのシステムを、たった5人のSREで見ているらしいですよ。
idesaku：なるほど。先ほどのSlack本の出版記念LTイベントで、takusさんは、Slackを使った「Incident Command System」に関する発表をされていましたよね。「検知された障害をインフラ担当が直す」といった、一般的なインシデント対応に留まらず、障害対応プロセスをどうエスカレーションするかという「前後の仕組み」まで設計し、さらにそこにChatOpsなどを活用した「ソフトウェアによる自動化」も積極的に取り入れていました。そうしたところが、従来の「インフラ管理」の枠に収まらない、新しい考え方だなと思いました。
takus：オライリーのSRE本（Site Reliability Engineering: How Google Runs Production Systems）にも、インシデント管理に関する章があって、インシデントに対してどういうアプローチで臨むべきか、振り返りはどうするべきか、といったことがまとめられています。SREでは、そうした部分もスコープに入っていますね。
idesaku：スマートニュースは、海外にオフィスがあるんですよね。
takusええ、サンフランシスコとニューヨークにあります。エンジニアも何人か、海外で働いていますね。
idesaku：そちらで働いていらっしゃる方とも日常的にコミュニケーションを取っていると思うのですが、それもSlackですか。
takus：基本的には、Slackが多いと思うのですが、GitHubあたりを使っているケースもあると思います。
ニュースのサービスを見ているチームは、全員で週次のテレカンをやって、スプリントプランニングをしていますね。あと、マネージャーと向こうのエンジニアで直接話すこともあります。その場合は、Skypeを使うこともあるようです。
idesaku：その中で何か課題はありますか。例えばSlackは、個人的にはちょっと情報の整理がやりづらいかなと感じているのですが。
takus：Slackを運用する際の問題点として、いろんなチャネルを並行して見ていないと、状況がよく分からないというのはありますね。これについては、ある程度、社内でルール決めが必要かなとは思っています。例えば、タイムゾーンをまたいで重要な連絡を行う場合は、Slackだけだと見落としがあるかもしれないので必ずメールも併用するとか。ただ、そうした細かい運用ルールについて、強制はしていないので、人によって対応が変わってくる可能性はありますけれど。
idesaku：そこはもう「相手の状況をよく見てうまくやろう」みたいな感じにせざるを得ませんよね。
takus：ただ、こういった問題は、Slackを使っているどの会社にもあると思うんですよね。幸い、Slackはサードパーティがアプリを作れる環境が整っています。そうしたアプリ開発に対する報奨金制度も始まったようですし、今後、多くのユーザーが「課題」と感じているような部分は、サードパーティアプリが補完していくのではないでしょうか。
idesaku：少しずつ、将来的なことについて聞かせてください。現在、スマートニュースでインフラを作っていらっしゃるわけですが、今後、具体的に「こういったことをやりたい」というようなビジョンはありますか。
takus：僕がスマートニュースに入ったときに考えていた「やりたいこと」のひとつが「プロダクトを作ること」でした。「良いプロダクトを作るためには、良い基盤が必要」という考えで、これまで基盤整備を手がけてきているわけですが、今後は、その経験やノウハウを生かして、面白いプロダクトを作ることをやってみたいと考えています。
idesaku：自分自身で何らかのサービスを設計するということですか。
takus：「プロダクトを作る」という場合、コンシューマー向けのものを作るという方向性もありますが、もうひとつ、デベロッパー向けに「ツールを作る」というアプローチもあると思うんです。DatadogやSlackなどもそうしたものですよね。その方面でやってみるのも面白いのではないかと思っています。
今の仕事では、社内向けのツールをいろいろ作っていますが、社内のユーザーに対して、それを「必ず使え」と思ってはないんですね。例えば、社内では今、PaaSのようなものも作っていますが、Herokuなどと比べて、より使いやすいものを作れば、それは使ってもらえるものになる。「どうプロダクトを作れば、お客さんに使ってもらえるか」を考えるという点では、コンシューマー向けプロダクトを作る場合とあまり変わらないんです。
つまり、自分は今「データプラットフォームというサービスを、社内に向けて提供している」と考えれば、何も「インフラ回りをやっているのでプロダクト開発ができていない」ということにはならないと思うんです。この先、そういう考え方での「プロダクト作り」を突き詰めていくのも面白いと思っています。
idesaku：なるほど。ここまでに伺ったような「開発者が開発に専念できるような基盤作り」や「障害対応前後のプロセスまで視野に入れたインシデントマネジメント環境」といったものも、言われてみれば、かなりサービス寄りの考え方ですよね。そういう意味では、やりたいことを着実に実現されているのですね。
takus：それらをさらに高度なものにしたいという思いは強いですね。既にサービスとして提供されているものとインテグレート可能な形に展開できれば、社内で使っているツールが、より広いユーザーに向けたプロダクトとして成立する可能性もあるわけです。
idesaku：最後に、恒例で次のリレー先になっていただけそうな方をご紹介いただけますか。
takus：ユーザーローカルの三上俊輔君を指名します。これまでに登場された方も何人か参加している「若手Webエンジニア交流会」を始めるきっかけになった1人ですね。学生時代からHadoopを使っていて、データエンジニアリングの分野で実績がある人物です。現在、どんなことに関心を持っているのか、今後どんなことをやりたいと思っているのかについて、改めて聞いてみたいですね。
idesaku：わかりました。ぜひ伺わせていただきます。本日は長い時間、どうもありがとうございました。
執筆：高橋美津
※本記事の内容は掲載当時の情報であり、現在の情報とは異なる可能性がございます。
