株式会社はてなは2001年の創業から現在まで、自社サービスの開発や受託・共同開発などを通して、さまざまなプロダクトを提供してきました。一方、事業の成長や時代の流れとともに組織形態は古び、事業に貢献できない事態も発生していたそうです。
はてなは現在に至るまでの間、どのように変化に適用してきたのでしょうか。創業から順を追って、組織の変遷をCTOの大坪 弘尚氏に語っていただきました。

2月10日に開催したCTO meetup「関西CTO/技術責任者10名が語るDX時代のエンジニアリング組織戦略」

CTO meetup初の試みとして2023年2月10日に大阪なんばのイベントスペースFun Space Dinerを貸し切り、関西のCTO/技術責任者10名をお呼びしカンファレンス形式でオフラインイベント「関西CTO/技術責任者10名が語るDX時代のエンジニアリング組織戦略」を開催しました。
採用/育成/技術戦略をはじめとしたエンジニアリング組織戦略を軸に、各社での取り組みをお話しいただきました。

「事業成長とそれに合わせた技術組織の適応について」をテーマにはてなのCTO 大坪 弘尚氏にセッションいただいた内容をご紹介します。

自己紹介

株式会社はてなCTOの大坪と申します。今日は事業成長と技術組織の変化についてお話しさせていただこうと思いますので、よろしくお願いいたします。私はGitHubやTwitterでは@motemenというIDで活動をしています。ghqというツールやgoreというGoのREPLとかを作って遊んでいますが、仕事では技術組織のマネジメントをしております。
私は2008年にはてなに新卒入社し、2016年にCTOに就任して今に至ります。その間に私が見てきた、事業や組織の変化についてお伝えできるかと思っています。

組織概要

コンテンツプラットフォーム＆コンテンツマーケティング

まずは、会社について簡単にご紹介させてください。はてなのミッションは、「知る」「つながる」「表現する」で新しい体験を提供し、人の生活を豊かにすること。Webサービス・スマートフォンアプリを中心に、事業を展開しています。会社全体が200名で、エンジニアは4割ほどを占めます。

事業はコンテンツプラットフォーム、コンテンツマーケティング、テクノロジーソリューションの3種類を展開しています。
コンテンツプラットフォームははてなが創業以来ずっと続けているサービスで、使っていらっしゃる方も多いかと思います。「はてなブログ」や「はてなブックマーク」などを提供しており、ユーザーははてなIDを取得すれば、これらを無料で使えます。

また、近年は企業がマーケティングを行う際にはオウンドメディアなど、顧客とコミュニケーションを取るコンテンツマーケティングが主流になっています。法人向けのCMSや、企業のコンテンツマーケティングの企画立案や記事編集などを行う事業も展開中です。

テクノロジーソリューション

これらとは毛色の異なる、テクノロジーソリューションサービスも提供しています。当社がサービス開発やコミュニティ運営の中で得た技術・知識を、顧客企業に使っていただこうと考えたものです。
その一つが、サーバー監視サービスの「Mackerel」です。はてな社内のサーバー監視管理の知見をSaaSにパッケージングし直して提供している、BtoBサービスですね。「GigaViewer」という漫画ビューワーも開発しています。これは、漫画原稿の入稿やメディア名の変更、漫画の更新などを一気通貫で実現するシステムで、さまざまなメディアに導入されています。そのほか、漫画のポートフォリオが作れる「マンガノ」、編集部に自分の漫画を読んでもらえる「ジャンプルーキー！」、KADOKAWAさんと共同開発した小説投稿サイト「カクヨム」などをリリース。小説投稿サイト「魔法のiらんど」のリニューアル案件も手掛けています。 任天堂さんともゲーム関係でつながりがあり、スマブラやスプラトゥーンのゲーム連動サービスの開発も行っています。

最後に少し、最近リリースされたものも宣伝させてください。はてなブログはさまざまな企業の技術ブログに使っていただくことが多く、その数は300～400社ほどにのぼります。その企業の技術ブログだけをまとめたら面白いだろうと考えて、昨年作成しました。「企業技術ブログ」で検索すると出てきますので、ぜひご覧になってください。

組織の変遷

2001年（創業期）～2007年：Web2.0企業としてサービス創出

ここからは時計の針を戻して、創業時代からはてなの事業がどんな風に変わっていったのかをお話しします。
創業は2001年で、10年ほどは自社サービスを中心に展開しました。「人力検索はてな」や「はてなアンテナ」、「はてなダイアリー」、「はてなカウンター」など、「はてな◯◯」というサービスをどんどん作っていきました。現在コーポレートサイトに掲載されているサービス名は10前後ですが、消えていった小規模なものも含めると、さらに10以上のサービスが存在しました。
当時はいわゆるWeb2.0企業として、ユーザーにとって面白いサービスを創出することがはてなの価値につながっている時代でしたし、実際にそれで収益も出ていました。

組織には、サービス開発チームとインフラチームがありました。開発チームに関しては、システムのドメイン知識がほとんど共通していて、例えばログインやメッセージ送信などのシステムも共通部分が多かったような状態です。そこをカバーする形で存在する、社内のフレームワークを前提に開発を推進。チーム間でエンジニアの互換性があり、ほかのサービスがどうなっているのかも想像がつく形でした。
インフラには会社独自の「はてなフレームワーク」用いており、例えばLinuxとApache、MySQL、Perlをセットアップしてすぐにサーバーをフルセットで構築可能でした。サービス開発から1週間ほどで本番に出せるぐらいのスピード感がありましたね。はてなフレームワーク専用のサーバーにどっぷり浸かった形で、サービスがどんどん増えていくようなイメージです。

2008年～2017年：リーマンショックをきっかけに起きた転機

2008年が転機でした。はてなの本社が京都に移転したタイミングで、私もこのときに入社しています。
世界的に大きなイベントとして起きたのがリーマンショックで、世の中が全体的に不景気に。私たちのサービスは広告収益で利益を得ていたのですが、景気の影響をダイレクトに受けたため、事業のほとんど全てで収益がガクッと下がってしまいました。当時新卒で入社したばかりで「何かすごいことが起きているなあ」と感じた程度でしたが、今考えると本当に大変な時期でしたね。

自社サービスだけを増やしても不安定になるということで、ここからの10年は舵取りを方向転換し、さまざまな形態のサービス提供を進めました。事業ポートフォリオを変えて、多角的に収益を得られる形にしようとしたわけです。
2008年に任天堂さんと一緒に開発した「うごメモはてな」を皮切りに、Wii Uから使えるコミュニティサービスの受託開発もしましたね。先ほどもご紹介したMackerelやカクヨム、GigaViewerなど、現在のはてなを支えている主力サービスの数々が、この時期に誕生しています。

開発チームは独自の新しいフレームワークを使うようになったため、社内フレームワークからの脱却が進みました。また、企業向けのサービスが増えたことで耐用性に対する関心度合いが高まり、技術選定やコードの傾向もかなり変わりました。
インフラチームは「基盤チーム」と名前を変えましたが、やっている内容は同じです。ただ、サービスごとに要求内容が変わってきたため、Infrastructure as Codeをやりつつ管理をしていました。これを開発チームが直接触ることは稀です。

つまり、フレームワークが乗ったサーバーにサービスが乗るケースはごく少数になり、主にサーバー上に自分たちでサービスを構築していく形になったわけです。ここでサービスとサーバーが離れた結果、さまざまな苦しみが生まれるようになりました。

2017年：組織に発生した技術の停滞

この頃会社全体には、技術の停滞が広がっていました。開発チームがインフラのことを詳しく把握できていなかったため、技術導入の責任が取りにくかったのです。新規技術を導入したとしても規模が小さく、事業インパクトを与えられませんでした。保守的な技術を使おうとした結果、 社内でも「数年遅れの技術を使っている」なんて言われることもありました。運用チームは基盤を提供する仕事があったはずなのですが、サービス数が多く運用業務に手を取られすぎていて基盤そのものを進化させられず、EOLが迫っても対処が後手に回っていました。
当時、はてなは学生向けにインターンを実施して技術的な講義を行っていたものの、学生向けに話している最新技術の内容と社内で実際に使っている技術にズレがあったことからも、遅れは明らかでした。

こうした状態を招いた原因の一つは、2008年までの「とにかくサービスを作る時代」の遺物のコストですね。ユーザーに長く使ってもらえるサービスを開発するのが美徳とされていたので、ユーザーが少しでも残っているサービスを終了すべきかどうか、メンテナンスコストと比較した判断ができていませんでした。
サービスの多角化に、基盤が追従できていなかった部分もあります。IaCは一つの境界線になりえたのですが、開発と運用の共有領域のどこに境界線を引くべきなのか、上手く設定できませんでした。
逆説的ですが、サービスの品質向上も停滞の原因でした。ベンチャー時代はアプリケーションエンジニアがコードを書いて、デプロイ後に障害が発生したら自分たちですぐに直していたため、開発・運用の知識が集約されていました。ところが、障害が発生しづらくなったために、対応事例が減少。結果的に開発チームがシステムのことを理解できなくなってしまったのではと思っています。

2018年：プロダクトオーナーシップを提唱

そこで2018年頃から、プロダクトオーナーシップを唱えはじめました。開発チームが運用まで含めたプロダクト全体のオーナーシップを持ち、技術選定や障害対応、インフラの構築やミドルウェアの増員まで、自分たちの責任で行えるようにしようという考えです。これは先ほど述べた通り、はてなの組織が小さかった頃はエンジニア全員が当然のようにできていたことだったんです。昔の状態に戻していこう、というメッセージでした。
これに1.5年かけて取り組み、開発の意志決定スピードを向上し、技術の幅を広げ、プロダクトの価値も直接的に高められることを期待しました。基盤チームの負担を取り除いて、サービス開発のための基盤構築ができるようにするのも狙いの一つです。

プロダクトオーナーシップの実現に向けて、まずは障害が発生したときの一次対応を開発チームが実施しました。自分たちでシステムのことを考えるために、基盤チームからエンジニアを派遣して知識の移転も行っています。
それに合わせて、基盤チームでは「開発が運用しやすい基盤を作る」をミッションとして再定義しました。職種も「Webオペレーションエンジニア」から「SRE」に変更しています。
また、開発エンジニアの言語やライブラリの縛りを撤廃。各サービスで必要な言語を選ぶだけではなく、どういうディスカッションの結果選定された技術なのか記録を残すことによって、技術的な選択の幅をぐっと広げました。

しかし、1.5年が経過したとき、そこには混乱する組織の姿がありました。今思い出しても辛かったですね。全体的にリソースが不足していたために、組織が疲弊していたのです。
大局的に見ると、基盤チームから開発チームに負担を移しただけになっていましたし、負担の総量も増えていました。方針は正しかったものの、エンジニアがサービス全体を見るにあたって何をどの順番で、どれぐらいのペースで進めるべきなのかを上手く提示できていなかったんです。

そこで一旦仕切り直すことにして、プロジェクトの旗振りは事業本部長に渡しました。事業計画と技術ロードマップを擦り合わせ、必要な運用コストに合わせて採用をするといった形で、事業全体のオーナーシップを事業側が持てるようにしたわけです。

2019年～現在：SRE文化の浸透

結果的に、2021年頃までに組織は良い状態になりました。インフラ基盤を刷新し、基本的にクラウドサービスを採用。クラウド化やコンテナ化、マネージド化によって運用がしやすくなり、サービス独自の技術選定も普通に行われるようになっています。

ここまでやってこれた要因としてはメンバーの頑張りもありますが、SRE文化の浸透が大きかったと感じています。SRE側のリーダーが、SREは「開発速度と可用性のバランスを取るツールだ」ということを、事業責任者側に説明していったんです。すると事業責任者側も、「開発速度や可用性は自分たちでコントロールできるものなのだ」と認識してくれました。 また、各チームにSREを埋め込んで、Embedded SREという形で活躍してもらいました。彼らはもともと基盤チーム間で横のつながりがあったので、各開発チームでのやり方や困ったことを共有し合う中で、運用業務を開発チームに上手く渡していけたのだと思います。

その後の話とまとめ

当社はプロダクトオーナーシップを開発チームに移すために技術の自由度を高めましたが、その分、現在はチームごとの技術が発散している状態です。オーナーシップはさらに整理する流れになっています。もともと一つだった事業本部を二つに分けることになり、各チームの独立性はさらに高まっていくでしょう。

今は次のテーマである「自律と同期」に向けて、組織体制を変えていこうとしています。もともとエンジニアのマネージャーは「組織のマネージャー」という立ち位置でしたが、新たにエンジニアリングマネージャーを立て、「事業に所属する立場」として事業や技術そのものを分割統治できるようにしていく予定です。
分散してしまった技術の集約に向けては、技術的な共有物を社内に作っていこうとしています。「技術の標準化」がテーマで、例えばデプロイフローや言語、ライブラリのベストプラクティスなど、共有できる領域について議論し、はてなのベースとなる技術のテキスト化、コード化を目指しています。

はてなの技術組織の変遷は、大変でしたがやって良かった事例です。大きな変化が定着するには時間が必要であり、今後も変化は発生しますが、そこを予期しつつコントロールしていきたいですね。次回は上手くやりたいというのが反省です。
今回の話が参考になれば幸いです。ありがとうございました。

まとめ

2001年の創業から現在まで、さまざまなプロダクトを開発・提供してきたはてながどのように組織変遷してきたのかをCTOの大坪氏にお話しいただきました。
また、今後の課題として「技術の標準化」への取り組みについても触れていただいたので、今後もよかった事例をお聞きしていきたいと思います。

他のセッションのレポートもご覧ください。

• 「ビジネス成長に不可欠なプロダクト組織のあり方について」Chatwork株式会社 執行役員CTO兼プロダクト本部長 春日 重俊氏
• 「手芸屋50年 ハマヤのDX ～DX人材の採用と教育について～」株式会社ハマヤ 代表取締役 CTO 若井 信一郎氏
• 「事業成長・事業拡大による技術負債と解消。それからの事業成長。」株式会社 TENTIAL 執行役員CTO 市來 晟弥氏
• 「DXの鍵は開発組織改革。Synergy! のモダナイゼーションの3年を振り返る。」シナジーマーケティング株式会社 最高技術責任者 馬場 彩子氏
• 「組織で課題解決！ 初めてのDX！」合同会社リーンアウト CEO / CTO 宮田 延昌氏
• 「コロナからの復活。半年で10人増やしたエンジニア組織とコロナ禍中の葛藤」株式会社YOLO JAPAN 取締役 CTO 田端 孝至氏
• 「2040年へのビジョン。受託制作企業からの脱却。そしてSaaSプロダクト開発へ。ワントゥーテンの3年間の歩み。」株式会社ワントゥーテン 取締役副社長 CTO 長井 健一氏
• 「技術広報戦略～エンジニアにとって魅力的な会社にするには～」株式会社ハマヤ 代表取締役 CTO 若井 信一郎氏／株式会社はてな CTO 大坪 弘尚氏／シナジーマーケティング株式会社 最高技術責任者 馬場 彩子氏／株式会社ゆめみ 技術担当取締役 渡部 陽太氏／株式会社ゆめみ 執行役員/テクニカルエバンジェリスト 桑原 聖仁氏