CLOSE

はてなのエンジニアリングマネジメント これまでとこれから(全1記事)

「不可視だった役割を発見し、組織のかたちを作りあげてきた」 はてなCTOが語る、エンジニアの人数増加に伴う新たなロール誕生の歴史

「Hatena Engineer Seminar #26 エンジニアリングマネージャー編」は、開発組織のエンジニアを統括するCTOとはてなブックマーク・マンガ投稿の開発を担当するチームの3名のEMが、組織づくりの観点または各人のキャリアやチームで実践した取り組みについて紹介するイベントです。ここで株式会社はてなCTOのmotemen 氏が登壇。株式会社はてなにおける、エンジニアの人数増加に伴ったロールの変化の歴史について発表します。

motemen氏の自己紹介

motemen氏:こんにちは。motemenです。「はてなのエンジニアリングマネジメント、これまでとこれから」というタイトルでお話をします。よろしくお願いします。最初に自己紹介ですが、株式会社はてなでCTOをしています。motemenです。よろしくお願いします。

時間もそんなに長くないのでサクサクといきたいと思いますが、今回のエンジニアセミナーはエンジニアリングマネージャー編ということで、最近新しく誕生した3人のエンジニアリングマネージャーに話をしてもらいます。

私は前座として、はてなにEMが誕生するまでの経緯を見ていこうと思っています。組織のどんなかたちも歴史的な経緯があって今の状態になっていると思うので、そういうコンテキストを紹介することで、これからの話を理解する手助けになればと思っています。

株式会社はてなが提供しているサービスについて

最初にそもそも(のお話)ですが、はてなという会社について紹介しておきます。はてなという会社はWebサービスやアプリを作ってご飯を食べているような会社で、だいたい3種類の事業を僕らは抱えていると思っています。1つはコンテンツプラットフォーム、もう1つはテクノロジーソリューション、そしてコンテンツマーケティングという3つを僕らとしてはやっているつもりです。

わかりやすいところだけを紹介しようと思っています。「Webサービスとかアプリでどんなものを作っていますか」という話ですが、1つは「はてなブログ」「はてなブックマーク」みたいな、コンテンツプラットフォームと呼んでいるサービスで、ユーザーさんがはてなIDを取って使えるようなサービス。

あとは、はてなブログやはてなブックマークを企業向けに提供するコンテンツマーケティングもやっています。

他にはサーバー監視サービスでSaaSとして作っている「Mackerel」とか、マンガビューワの「GigaViewer」のWebとアプリ版。あとは小説投稿サイトみたいなものを開発・運用・運営しております。

はてなの「大西部時代」

駆け足ではてなについて紹介した上で、はてなのエンジニアリングマネジメントの歴史を見ていこうと思います。はてなのベンチャー初期時代、最初期時代です。

(スライドを示して)この頃は「大西部時代」と書いているんですが、はてなという会社というかサービスの方向性はありつつも、それぞれのエンジニアがサービスにとって良いことを考えて自分で実装していくような、カウボーイの集まりとしての組織というかたちを取っていました。

2000年代だったので、それで成り立ってしまっているところはあり、その時に作っていたサービスがユーザーに受け入れられて、はてなという会社は大きくなってきたと思います。

エンジニア15人の時に始まった「チーム化」

エンジニア人数・規模をベースに見ていこうかなと思うんですが、エンジニアがだいたい15人ぐらいになった時に、チーム化が始まったかなと記憶しています。

僕もちょうどこの時に入社したんですが、サービスがけっこう使われて大きくなってきた頃に「サービスリニューアルをそろそろ考えたいね」みたいな大きなことをやろうとしていくと、エンジニアとかデザイナー1人の力では難しくて。「それらをチームとして束ねて大きなプロジェクトをやっていきましょう」というニーズが出てきました。そういうところで、企画とか進行を行うディレクターという役割が発生してきたと思っています。

これがいろいろな課題のきっかけでもあったかなと思っています。ディレクターがエンジニアとデザイナーを取り持ったり、彼らとコミュニケーションをしたりする役割になっていて。今考えると“超人になりがち問題”ですかね。

今で言うと、プロダクトマネジメントとかプロジェクトマネジメント、ピープルマネジメントみたいな、いろいろな仕事をディレクターが一手に引き受けるというかたちになっていたんですが、これらを「ディレクターに押し付ける」と考えていたわけではなくて、これらの仕事は、当時のはてなにおいては未発見だったと思っています。知らなかったんですね。

逆に言うと、エンジニアリングマネジメントの歴史というのは、ディレクターに内包されていたり未発見の仕事を見つけていくという歴史だったかなというふうに思います。

エンジニア30人の時に「シニアエンジニア」というロールを導入

エンジニアの人数が30人ぐらいになってきた時、開発チームとは別に横軸のエンジニア職能組織があって、エンジニアの育成やケアはそこが担当していたんですが、当時のリーダー2人では見切れなくなっていました。

その時に、シニアエンジニアというロールを導入しました。これの1つの目的としては、エンジニアの中にラダーを作るという目論見もあったんですが、それとは別に、具体的にやってもらう仕事として、「メンティーを持って、1on1とかメンタリングをしてください」ということをお願いしています。この仕事は今も続く重要な役割になっています。

エンジニア45人の時に「テックリード」という役割が生まれた

それからエンジニアの人数が45人ぐらいに成長した時に、私がCTOに就任しました。その時の課題感として、「エンジニアとディレクターに距離感がある」というような課題感(のこと)は話してました。

この頃にはディレクター以外にもプランナーみたいな仕事も出ていて、エンジニアにしろディレクター、プランナーにしろ各職種の練度が上がっていて、専門性が高まった結果、それぞれ独立している感じが少しずつ出てきていたということで、エンジニアのチーム内リーダーとしてテックリードという役割を各チームに配置するようにしました。

これはディレクターと開発チームの間の意思疎通役であったり、大きなプロジェクトをやっていく中で、品質とか納期に責任を持つ役割としてエンジニアのリーダーを置きましょうということで、当時も話題になっていたテックリードという役割が生まれてきたというような運びです。

エンジニア60人の時に「デリバリーリード」というロールが誕生

そしてエンジニアの人数が60人になる頃には、最初に紹介したとおり、もともとはてなはtoCから始まったんですが、自社toCサービス以外の事業がけっこう比重としても増えるようになっていて、toBでSaaSをやるであったり、受託というかたちでサービス開発するであったりということで、プロジェクトやプロダクトにかかるプレッシャーや守らなきゃいけないことも変わってきました。

チームのサイズも大きくなってくるし、大きなプロジェクト、長めなプロジェクトをやった経験も増加していて、エンジニアの中の課題感としても、「開発プロセスやチームビルディングに関する知見を自分たちでもっと高めていかないといけないよね」という話がよく出るようになっていて。

社内でそういう知見をチームを越えて共有したり議論する会、はてなの中では「すくすく開発会」と呼んでいて、テックブログにも時々名前が出てくるんですが、そういう会が誕生して、かなり活発に活動するようになっていました。

そこで生まれて派生して出てきたチーム内のロールとして、デリバリーリードというものが最近誕生しています。一般的にはよく言われるものでいうと、スクラムマスター的な振る舞いを取ることが多いんですが、ただそういう専門の職種というわけではなくて、エンジニアとしての側面も持っていて、エンジニアに限らず、誰でもできる仕事としてデリバリーリードという役割をチーム内に置いたり、そういう役割があるよという認識を培われたりするようになってきました。

エンジニア80人規模になり「エンジニアリングマネージャー」というロールを作成

(スライドを示して)ここはもう最近ですね。80人規模になってきた頃に、シニアエンジニアが人を見て、テックリードが技術を見て、デリバリーリードがデリバリーを見るみたいな感じで、エンジニアが開発チームの中でいろいろなロールを持って、いろいろプロダクト開発を改善していこうという話をしていたわけです。

ですが、エンジニアサイドに留まった動きだけで事業への本当の貢献ができるわけではないということで、そういう側面を全部包括して事業につなげていく役割として、エンジニアリングマネージャーというロール、職種を作りました。

この職種のミッションは、ソフトウェア開発の側面から事業の成功に貢献することです。まぁ非常にザックリとしているんですが、ソフトウェア開発にまつわる諸々を全部束ねて事業につなげていくという、ザックリとしているが難しくておもしろいロールが最近ようやく誕生しました。

構造としては、プロダクトチームにつくEMと、さらにそれを束ねるチーフEMという2段階になっていて、今日(このイベントで)話す3人は、プロダクトとかチームにつくEMの3人になっています。

もともとエンジニアの育成やケアの役割を職種組織で担っているという話をしましたが、エンジニアが80人とか100人になってくると、だんだん他のチームが何をやっているかがわからなくなってくる。

なので、そこはシニアエンジニアをEMの下に置くという再配置を行って、育成やケアをする時に、ちゃんとコンテキストが高く保たれていて効果も高くなるようにということで、ピラミッド化していくかたちにして、EMによる組織の分割統治ができるようになってきたということが最近のEMの登場(による影響)であります。

不可視だった役割を発見・切り出して組織のかたちがようやくできた

というわけで、駆け足ではてなのEM誕生の歴史を見ていったんですが、軽く振り返っておくと、初期には不可視だった役割、見えていなかった役割を発見して切り出していって、組織としてのかたちがようやくできてきたなというのが、EMが登場した今(の状態)かなと思います。

もともとEM的な動きをしていた人にEMになってもらったというところもあって、ここが大きな変化というよりは、良いかたちにちゃんと名前を付けられたという感覚はあります。

ただ、結果(が出るの)はこれからだと思うし、これからの3人の話を聞いてもらって、縦の組織はどんな感じなのかを感じてもらえればと思っています。

最後に宣伝させてください。EMの話をしていますが、事業とかチームにつくEMの候補を募集中ですということと、便乗ですが、私と一緒に技術組織の開発・改善をやっていくマネージャーも募集中です。ぜひよろしくお願いします。

じゃあ私からは以上です。ありがとうございます。

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

関連タグ:

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • 大変な現場作業も「動画を撮るだけ」で一瞬で完了 労働者不足のインフラ管理を変える、急成長スタートアップの挑戦 

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!