「CTOという立場にとらわれ過ぎていた」はてなmotemen氏が、今あえて現場でコードを書く理由

ブログサービス「はてなブログ」やソーシャルブックマークサービス「はてなブックマーク」、SaaS型サーバー監視サービス「Mackerel」などの有名サービスを開発・運営する株式会社はてな。

同社は他にも、株式会社KADOKAWAと共同で小説投稿サイト「カクヨム」を、株式会社集英社と共同でマンガ家のための作品投稿・販売プラットフォーム「マンガノ」を開発するなど、技術力やシステム構築の実績を活かして大手企業との協業を積極的に行っています。

はてなのCTOである大坪弘尚（通称：motemen）さんは、2008年に同社へと新卒入社して以来、15年近くにわたりプロダクト開発を支え続けてきました。そんな大坪さんに、過去に行った組織的・技術的意思決定のなかで印象に残るものを聞きました。

エンジニア自身がプロダクトオーナーシップを持てるように

――今回のインタビューでは、過去に取り組んだ組織的・技術的意思決定のなかで印象に残るものや、そこから得た学びを話していただきたいです。

大きな意思決定としてまず思い浮かぶのは、社内で「プロダクトオーナーシップ」と呼んでいた動きですね。ここに至った経緯なんですが、はてなはかつて「はてなブックマーク」や「はてなブログ」に限らず、もっとたくさんの「はてな○○」サービスをたくさん作っていました。はてなスタッフのアイデアで面白いサービスを多く、素早く世に出す、というのが会社としての戦略だったのだと思います。そうしたサービス開発を支えるための共通システム基盤が社内には構築されており、それを運用するチームもありました。

その後、はてなはtoB事業の「Mackerel」や、toCだけれど他社と共同で開発した「ジャンプルーキー！」のように、性質の異なるプロダクトも徐々に作るようになりました。本来であれば「はてな」サービス向けの基盤はそれらの新しいプロダクトにはミスマッチなわけで、事業の変化に合わせて、開発や運用のありかたも変わっていくのが望ましいはずです。ですが、そうはならなかった。当時のはてなはいわゆるDevとOpsの分断が起きていました。

システム基盤が進化していくにつれ、開発メンバーの運用に対する意識が薄くなってしまっていたんですね。そういう状態で開発したシステムを運用チームに渡すことを続けてきた結果、運用チームの負荷が高くなっていきました。運用チームは本当ならば基盤を進化させたいのにその余力がなく、一方で開発チームは運用を半ば手放してしまったことで、自分たちが選定する技術の責任を取れない状態になっていました。

そこで、この状態を是正するためのプロジェクトを推進しました。このプロジェクトで目指したのは、開発チームがプロダクト全体のオーナーシップを持てるようになることです。技術選定や開発、運用という一連のプロセスを、すべて開発チームが担うことを目指しています。これによって運用チームの業務負荷を下げて、運用チームは基盤そのものの進化に力を注げるようにしようと考えました。

具体的には、まず障害発生時の一次対応を開発チームに担ってもらうことから始めました。もちろん、調査したうえで技術的にわからないことがあれば、運用チームが助けにいきます。ただ、この施策を推進したものの、移行途中は組織のみんなにすごく大変な思いをさせてしまいました。

苦労の多い運用を開発チームも担うようになったので、移行途中はむしろ“組織全体としての大変さ”が膨らんでいるような状態だったんですね。その期間はみんながすごく疲弊していましたし、私はそれをうまくサポートできていませんでした。

――大変さの原因は何にあったのでしょうか？

「プロダクトオーナーシップ」というゴール自体はよいものだったと思っています。ただ、その正しい目標にみながそれぞれ全力で取り組んでしまうこととなり、全体としてどういう経路で、どういうテンポで進んでいくのか、という統制や具体的な計画が欠けてしまっていました。

――もし、今の大坪さんが、当時と同じ状況に置かれたらどうしますか？

自分自身も開発チームに参画して、彼らと同じ仕事をすると思います。当時の私は、ゴールを示すのが自分の仕事だと勘違いしていたんですね。つまり、抽象度高く会社や組織の方針を策定して、実行はメンバーに任せることがCTOのあるべき姿だと思っていました。でも、解像度高くチームのことを理解するには、実際に現場に入らなければなりません。

それから、開発組織以外の部署との調整もうまくできていませんでした。その頃の私は、エンジニアとのコミュニケーションが中心だったんですね。ですが、エンジニアの業務負荷や開発・運用体制が変わるということは、事業やプロダクトにも確実に影響が出ます。その点について説明し、協力を取り付けるといった全社レベルでの巻き込みが足りていませんでした

結局、途中でこのプロジェクトの再編成をして、エンジニアだけではなく事業部全体を巻き込んで進めるように変えたんですね。その結果、時間はかかりましたが、今では各開発チームのメンバーがプロダクトオーナーシップを持ったと言える状態になっています。

「事業の成功に責任を持つ立場」として、エンジニアリングマネージャーを設置

――他の事例はいかがでしょうか？

他の大きな変更は、エンジニアリングマネージャーの設置ですね。はてなは開発組織が80人規模になるまで、職種横断でエンジニアの評価・育成・採用などに責任を持つチーフエンジニアという役割の人間はいたものの、プロダクトやチームを管轄するエンジニアリングマネージャーを置いていなかったんです。それを、プロダクトチームにつくエンジニアリングマネージャーと、さらにそれを束ねるチーフエンジニアリングマネージャーを設置するという構造に変えました。

――体制を変更した背景は？

もともと、はてなにはプロダクトを開発する部署がひとつしかありませんでした。それが、2022年の組織変更で「はてな○○」系のサービスを作る事業部と、toBプロダクトや他社との協業を担う事業部に分割されたんです。かつ、先ほどのプロダクトオーナーシップにより、決まったインフラ基盤からシステムが解き放たれたこともあり、各プロダクトチームの独立性は今後さらに高まるだろうと考えました。

また話が前後しますが、その前の段階からtoCサービス以外の事業の比重が増えるにつれて「規模の大きなプロジェクトをうまく進めていく知見が必要だ」ということで、プロダクトのデリバリー（高品質なプロダクトをスピーディーに作り、ユーザーへ届けること）の練度を高める機運がエンジニアを中心に高まっていました。

ですが、開発チームがエンジニアリングだけに注目してデリバリーを改善できたとしても、それだけでは本当の意味で事業への貢献ができるわけではありません。そこで、エンジニアリングに軸足を置きつつ事業の成功に責任を持てる人として、エンジニアリングマネージャーを配置しました。

――具体的にエンジニアリングマネージャーはどのような動き方をするのでしょうか？

事業のボトルネックによって変わります。たとえば技術的な観点での計画を事業計画とすり合わせ、長期的な価値につながるよう調整したり、プロダクトのディスカバリー（何を作るかを決定すること）とデリバリーをうまくつないだりといった仕事ですね。

エンジニアリングのことだけを考えるのではなくて、もし仮に事業としてのボトルネックがプロダクトマネジメントやディスカバリーにあるならば、そちら側にも積極的に関与する役割です。また、こうした業務を担いつつ各エンジニアがモチベーション高く働けるようなタスクの割り振りや育成などの役割も果たすことになります。

――「事業に関心を持つこと」を苦手とするエンジニアも多いですが、どうすればその視点を身に付けられるでしょうか？

もちろん、最初から事業について全容を把握しようとするのは難しいので、まずはユーザーのことをきちんと想像しながらプロダクトを作るのが、事業視点を持つための第一歩だと思います。

自分たちの仕事はプロダクトを作って終わりではなくて、ユーザーに対して何かしらの価値を提供するまでがゴールです。ユーザーがどのような人たちなのか、プロダクトがどのように使われているのかなどを開発チームが知る必要があります。開発組織のなかでは、ユーザーインタビューを積極的にしているチームも出てきており、こういった動きを社内でより広めていくことを目指したいです。

もともと、はてなが作っているのはtoCのプロダクトがほとんどでしたし、toBにしてもMackerelのように、エンジニア自身がそのプロダクトのユーザーであるケースも多いです。だからこそ、特別なことをしなくてもユーザーのことを理解できるのが当たり前、という感覚もあります。

ですが、最近は扱っているプロダクトも多様化しています。「もしかしたら、自分はユーザーのことを正しく理解できていないのかもしれない」という前提のもと事業と向き合わないと、いつの間にか視野が狭くなっている可能性があると思います。

「あるべき論」に盲従しない。使える手段はすべて使う

――他の事例も教えてください。

CTOである自分自身が、開発チームに入って手を動かしていることですね。最近機会があって、いちエンジニアとして開発チームのヘルプに入りました。そして、実際に手を動かしてみると、「はてなの技術」というものが現場に近い解像度で見えた感覚がありました。これが意外と、自分にとって大きな発見でした。実は開発チームの技術のことを、全くわかっていなかったんだと気づいたんです。

その経験をすることで、はてなとして技術的により良くできそうな部分や今後の課題になりそうな部分が、肌で感じられました。これを皮切りに、そのチームのヘルプを終えた後には、いくつかのチームを順に回っています。もちろん、私が開発にかけられる時間は少ないですし、チームの技術をキャッチアップできていないところはあります。それでも、組織の状況を知るうえで価値の高い活動なので、今も続けています。

――開発組織のマネージャーやCTOのなかには「自分はなるべく手を動かさず、マネジメントに集中しなければ」と考えている方もいると思います。大坪さんの経験を踏まえてアドバイスはありますか？

マネージャーのポジションになったからといって仕事の幅を狭める必要はなくて、使える手段はすべて使うほうがいいということですね。よく言われる、エンジニアがマネージャーになったらなるべく手を動かさないという「あるべき論」にとらわれ過ぎないほうがいいです。自分が使える手段があるのならば、それをシャットアウトしてはならないと思います。

抽象的なインプットからは、抽象的な判断しかできません。そのインプットだけでは自分が適切に判断できないならば、もっと現場や一次情報を見て、ある程度の手触りがある状態にしておく必要があります。私の場合は、おそらくCTOになってすぐの頃はそういった感覚が残っていたのだと思います。ですが、マネジメントに注力し続けているうちに感覚が鈍ってしまい、組織の変化に自分が追いつけていなかったのかもしれないですね。

はてなの遺伝子を今後も残していきたい

――この先、はてなをどのような会社にしていきたいですか？

これは、私がこの会社に入社した理由にも通じるんですが、はてなはエンジニアが面白いものを作って、それが世の中に受け入れられて大きくなった会社です。そのブランドや遺伝子を、今後も残していきたいです。昔とは違って、プロダクトを作るにあたって考慮すべきことは相当に増えました。かつては、Webサービスを作って、ヒットさせて、広告を貼るというシンプルなモデルで収益を上げられましたが、世の中にサービスが増えている昨今ではそう簡単にはいかなくなっています。

事業やプロダクトのアイデアを検証して、世に出して大きくすることは昔よりずっと難しくなりましたが、その高い壁にエンジニアが挑戦していけるようにしたいです。要するに、「システムを作って終わり」とか「自分の好きな技術を扱えたから満足」ではなくて、プロダクトによって世の中に価値を発揮することに、エンジニアが主体となって取り組んでいきたいですね。

――最後に伺いたいのですが、「what we use」で掲載するインタビューやコラムは「組織的・技術的な意思決定」をテーマにしています。エンジニアがこういった事例を学ぶことには、どのような意義があると思われますか？

「経験しなければ学べない」と、私はずっと思っています。今回、インタビューを受けるにあたって過去の事例などを事前に振り返ったんですが、その過程で「昔の自分はなんて浅い考えだったんだろう」と実感しました。逆に言えば、その分いろいろな経験をして、そこから多くを学んできたのかなと思います。

そうした各種の事例について、書籍やWeb記事などを通じて追体験することは、すごく大事です。自分と似たような立場や境遇の人々がどのような課題に直面して、何を考えて方針を選んだのか、その結果どうなったのかなどを学べることには意義がありますね。

取材・執筆：中薗昴

撮影：石田博紀

提供：株式会社Haul