これは、はてなアドベントカレンダーの25日目の記事です。昨日は 
id:nabeop による Hatena Developer Blog 編集部の活動の紹介 でした。
こんにちは。CTO の 
id:motemen です。CTO としては、はてなにおけるエンジニア組織全体を見ています。この機会に、はてなの技術組織が現在どのようであるか、について概観を書いてみます。
はてなのプロダクトたち
はじめにこの話の前提として、はてなの事業やこれまでの組織について軽く触れておきます。
会社情報ページにあるように、はてなは「コンテンツプラットフォーム」「コンテンツマーケティング」「テクノロジーソリューション」という3つの分野でサービスを展開しています。それぞれ、
が代表的なプロダクトです。これらを70人ほどのエンジニアで見ているので、意外とプロダクトあたりの人数が少ない、と驚かれることもあります。
事業構造はそれぞれ違っていて、システム的には似てるものもあればぜんぜん違うものもあり、というところですが、「知る」「つながる」「表現する」というはてなのミッションとのリンクと、ドッグフーディングの文化があること、それと長くメンテしているプロダクトが多いのはどれも共通しているところだと思います。
プロダクトオーナーシップ
もともと、20年前に「はてな」と名前のついた自社サービスで起業し、そのサービスを横展開してきた会社であったので、古くから UGC サービスを素早く作るための社内フレームワークが発達していました。各サービス開発チームに必要なインフラリソースを調達するチームが存在して、画一的なインフラの構築からアプリケーションのデプロイまでを一気通貫で行うことができるモデルです。当時のウェブ界隈の状況もありますが、開発開始から本番デプロイまで数日、というスピード感も実現できていました。
ただその後、先述のように事業の種類が増えていき、求められるシステムの質や要求が変化していくなかで、しだいにインフラチームの対応しなければならないシステムが複線化していくことになります。いわゆる Devs と Ops の分断も始まっていて、チームの負荷が高まり、提供する基盤システム自体の更新が困難になっていました。
そこで社内では、4年ほど前から「プロダクトオーナーシップ」ということを言いはじめました。開発チームがインフラも含めてプロダクトのオーナーシップを持っている状態をめざす、という取り組みです。
まずはプロダクトの運用をチームで行えるようになる、そして既存の基盤からクラウドに移行していく、というのがその柱です。チームでオーナーシップを持って進められるよう、ひとチームに集約されていた Ops を Embedded SRE としてチームに配置しました。また、それまで言語やフレームワークのレベルでゆるやかに統一していた技術選択はそれぞれのプロダクト開発チームに委ねることにしました。技術スタックのページを見ると、結構さまざまになっていることが分かります。
自律と同期
そうして、近年では当初想定していたオーナーシップの掌握ができている状態になりましたが、それぞれのチームのレベルではよくても、全体として見ると非効率な状況でした。あるチームと別のチームで似たような技術を使っているのに、コードやノウハウのレベルでも共有されているものがないとか、同じ課題を解決するのに再発明をしているとか、そういうことです。これまでは基盤移行が急務で、チームは個別に努力をしてきたのだからそれはそうで、ただ全体として統制を取っていこうという話です。
そこで今度は「自律と同期」を目指して体制を変えていくことにしました。新しいスローガンです。各チームが事業をやっていくのに必要な能力を具えるための自律であり、それでありながらチーム間の技術やプロセスにレバレッジを効かせるための同期です。
標準化
同期のひとつの柱として標準化を進めています。同期の点で言うと、週一で開催している社内の技術勉強会や、分野別のサブ会で情報の共有はできていたんですが、会社として推奨したり、ときには強制する技術を決めることで、それらをチーム横断の共有物として育てていこうということです。もちろんオーナーシップはチーム側にあるのですが、標準に乗ることで大きな恩恵を得られるようなエコシステムを狙います。
標準はまずそういうトピックがあると分化するところからはじまり、個人やチームの知識として蓄えられたものを、何らかの形で文書やプロセスに落としていくことで定めます。最近は TypeScript が標準になったようです。これはデファクトにお墨付きを与えた形ですね。
ものによっては、実際に利用可能なコードやツールを提供することで標準としようとしているものもあります。SRE で定める標準では、Docker イメージや Terraform モジュールなど、すぐ使えるものになりそうです。
エンジニアリングマネージャ
これまでは、チーフエンジニアと呼ばれるエンジニアのマネージャが職種横断組織に数人いて、この数人で評価／育成／採用／異動など、個人の側面でのエンジニアのマネジメントをおこなっていました。これもはてなにおいては伝統的なものでしたが、エンジニアの規模が大きくなるにつれて、管掌範囲の広さと目配りの薄さが問題になってきました。
そこで現在は、ひろく職種全体を管掌するのではなく、事業グループにつくマネージャとしてエンジニアリングマネージャの役割を作り、事業の成功へのコミットを求めるよう進めています。人間のマネジメントだけでなく、デリバリやコストなどのマネジメントなど、明に暗にチームで行われていたエンジニアリングにまつわる営みを一箇所に集中させることで、より事業の成功にコミットしやすくなる狙いもあります。事業に必要な能力をグループ内に育成していく、自律の取り組みです。
これまでジェネリックなマネージャとして組織設計・技術マネジメント・大小さまざまな企画や雑用を受け持っていたチーフエンジニアは、一部は事業と組織を見る EM に、一部は先ほども言及した SRE のように技術を見るエンジニアのリーダーにと、仕事を分化しています。
はてなで一緒に働く仲間を探しています
まだまだ書き足りないこともありますが、最近の大きな変化はこんなところです。
今年は INSPIRED って本を再読がてら社内で輪読し、プロダクトマネジメントって大変だな、大変すぎるな、という思いを新たにしました。技術と組織のマネジメントを通じて、プロダクトマネージャとともにプロダクトを成功させていきたいですね。
最後になりますが、はてなではエンジニア職やマネージャ職に興味のある方をいつでも募集しています。興味のある方はどうぞ以下からご連絡ください。
あわせて、こちらの採用サイトもご覧ください。
