Engineering Managerとしての技術ブランディングへの取り組み方 [実践編]

本記事はEngineering Manager Advent Calendar 2021の最終日、25日目の記事です。

あなたは誰？

READYFOR株式会社でVP of Engineeringをしております、いとひろ（ itohiro73 ）と申します。2021年は副業としてプロのコーチとしての活動も始めたので、もし本記事を読んで（？）この人にコーチングを受けてみたいなと感じた方がいたら、お気軽にツイッターからDMをください。コーチングはエンジニアの方でもそうでない方でも受け付けており、無料体験から始めていただけます。ちなみに本記事はコーチングとは全く関係がありませんw

本エントリーの趣旨

実は、全く同じ題名のエントリーを2年前の2019年のアドベントカレンダーで公開しておりました。この内容自体は【理論編】としての立て付けで自分自身で見返してもなかなかよく書けているなと感じているので、本記事を読む前にまずはぜひ一通り目を通していただけると幸いです。

itohiro73.hatenablog.com

さて、上記で言いたかったことは、こちらの文章に集約されています。

この記事で本質的に伝えたかったことは。 技術ブランディングを醸成するための本質的なプロセスは、Engineering Managerが日々対峙している課題解決の積み重ねと同義である ということです。「サービスの課題」であったり「エンジニア組織の課題」であったり「技術的な課題」であったり。それらの課題を解決していくプロセスの中で、実際に解決していった「実績」を「マーケティング」「広告」「PR」していくことで、自然と自社の技術ブランディングは醸成していく。そう私は信じています。

実はこの2年前に記事を公開した少し前にREADYFORでTech Brandingチームと称して技術ブランディングチームを立ち上げたのですが、そこから2年経っての成果が出てきたので、今回は【実践編】として紹介できればと考えています。

まずは成果から

そもそもこの記事を読む価値があるのか、それを感じていただくために、実際に出ている定量的・定性的な成果からご紹介させてもらえればと思います。

（この成果のセクション、思いのほか長くなってしまったのでザーッとスクロールしてもらって「 技術ブランディング醸成、実践編」まで一気に流し見してもらった方が良いかもしれません。 「成果出てるんだね」と感じてもらうのが趣旨なので）

2019年12月時点での状態確認

2019年の時点では、READYFORはこれからエンジニアリングの力でプロダクトを伸ばしていきたい、とエンジニアリングに注力し始めた頃です。この時点ではまだブランディグも確立されておらず、READYFOR=エンジニアリングという認知は社内でも社外でもまだ醸成されていない頃です。

  • エンジニア正社員数: 10人
  • 技術記事アウトプット: 0記事
  • イベント開催: 0回
  • メディア取材: 0回

2021年12月時点でのアウトカム・アウトプット

2021年1年間の定量的な成果としては以下になります。

  • エンジニアリング本部　正社員数: 27人（TPM/デザイナー含む）
  • 技術記事アウトプット: 48記事
  • イベント開催・登壇・その他アクティビティ: 14回
  • メディア取材: 12回

採用活動の成果

2019年10月に私が入社した時点では私含めてエンジニア正社員がまだ10人でした。2年3ヶ月経った2021年12月現在、エンジニア組織の正社員（TPM/デザイナー含む）が27人となっており、2.7倍の成長を遂げています。

アドベントカレンダーLGTM数

2021年Qiitaアドベントカレンダーの企業・学校・団体の部 LGTM数ランキングにて、4位以下を大きく離して第3位！ そして、Qiitaアドベントカレンダー全体でも4位の成績です。

このLGTM数はQiitaで書かれた記事のみがカウントされており、今回半分弱ほどの記事が自社のはてなブログや個人ブログ上で書かれていてLGTMカウントされていないことを鑑みると、かなりの成績といって良いのではないでしょうか。

f:id:itohiro73:20211225030653p:plain

READYFORのエンジニアリングに対してのポジティブな形での言及

READYFORで技術広報活動のアウトカムとしては、実際にポジティブなフィードバックをいただいており、客観的な評価として認識してよいかなと考えています。

例えば2021年1月開催の「【READYFOR】実践！フロントエンド分離戦略」ではものすごいポジティブな反響が多かったです。このイベントはREADYFORで初の技術イベント開催だったわけなのですが、オンライン開催で最大240人を超える方が視聴してくださいました。

togetter.com

また、READYFORでは今年からドメイン駆動設計を活用してのコンテキストマップ作成・モデリング活動・変更容易性向上・エンジニアの設計力向上・技術的負債の解消に取り組み始めています。

その活動の一つであるDDD社内勉強会の入門編をYouTubeで公開したところ1000回を超える再生数を叩き出しました。

www.youtube.com

ここでもポジティブな反響が多く見られました。

また、READYFORでのDDDに関する発信を好意的に取り上げてくださるブログや記事が上がったりもしました。

shinkufencer.hateblo.jp

zenn.dev

技術記事アウトプット（48記事）

見ていただけるとわかりますが、単に記事を量産しているというわけではなく、質の高いアウトプットになっているという自負があります。 tech.readyfor.jp qiita.com

イベント開催・登壇等（14回）

メディア取材（12回）

技術ブランディング醸成、実践編

さて、成果をリストアップするだけでもかなりの量になってしまいましたが、いかがでしょうか。たった2年間で、ほぼ技術的な強みを持っていない組織からここまで強みを表出し認識してもらえるエンジニア組織までどうやって成長してきたのか、気になりませんか？採用にもインパクトがでているので実質は半年くらいから成果は出てきています。技術的なブランディング活動と認知を形成するまでに実際に実践してきたことをここからはご紹介します。

まずやったこと

まず、一番最初にやった大切なことは「技術ブランディング」が目指す状態を明確化することでした。

READYFORでは、Tech Brandingチーム立ち上げの際に明確なビジョン・ミッションを設定しました。

f:id:itohiro73:20211225195138p:plain
Tech Branding Vision/MIssion

このビジョンに近づくために、ミッションに則さないことはやらないという意思決定をする。これがとても大事だと考えました。

ミッションにある「内外にとって」というのはとても大切です。社外の人を魅了するために、実態に則さないことをブランディングするのは全く意味がありません。課題であることは課題として認識し、改善していくことで、その改善プロセスが強みへと昇華していく。強みは強みとして魅力として発信することで、社内のエンジニアにとっても、社外のエンジニアにとっても、魅力的な場となっていく。その地道な積み重ねがとても大切なので、一朝一夕で発信さえすればブランディングが醸成されると考えては本末転倒です。

実際、2019年のTech Brandingチーム立ち上げ直前である11月頃、「エンジニアmeet-upを開催しよう」というアイデアが立ち上がり動き始めていましたが、まさに冒頭の記事で書いたような理由で一時延期としました。

「こうありたい」という想いはあるが、まだそこに達していない領域のブランディング

世の中で技術ブランディングに困っている方たちはこの領域が広いのでは無いかと想像します。だからこそ困っているのでしょう。

「こうありたい」という想いがあるということは、最終的にそこをブランディングできるようになっていきたいということは間違い無いと思います。しかし、まだそこに達していない状態で「マーケティング」「広告」「PR」をしてしまうと、中身が伴わないブランディング活動になってしまいます。この時点でむやみにコミュニティ登壇やブログ記事、OSSなど出しても、無駄死にするだけです。

実際、当時はまだREADYFORは技術的な強みと言えるものは特に言語化されておらず、実際に内情としては技術的負債も多く積み重なり、フロントエンドとバックエンドも分離されておらず密結合な状態かつ体制も整備されておらず、meet-upを開催したところで何も発信することも得ることもできなかったでしょう。

さて、先の記事では「こうありたい」という理想と見比べた時に「現在の状態」を言語化してみましょうと言っていました。

ここでEMの出番です。Engineering Managerの諸氏におかれましては、「こうありたい」という理想と見比べた時の「現在の状態」を言語化してみましょう。そこで言語化されるのは「サービスの課題」かもしれませんし、「エンジニア組織の課題」かもしれませんし、「技術的な課題」かもしれません。

ここからEMが主導する課題解決・技術ブランディングの基本的な型が導き出されます。

  • 理想と現状の差分を言語化する
  • その差分を解消していくための目標設定をする
  • 設定した目標を達成するための体制をつくり実践する
  • 目標が達成できたらそれを自社の強み・成果として発信する　

では、実際にREADYFORで行ってきた課題発見・目標設定・課題解決と技術ブランディングの事例を見ていきましょう。

体制の整備: 職能型組織からスクワッド型組織へ

READYFORでは、2019年の初め頃よりチームや個人の目標設定にOKRを活用していました。

2019年時点のREADYFORではエンジニア10名、ようやくフロントエンドチームとバックエンドチームが分かれ始めたところでした。しかし、これからプロダクト開発にアクセルを踏んでいこうというところでしたが、プロダクト開発のミッションと各チームのOKRとの接続があまりできていないことに気づきました。これは、5人規模のワンチームだったエンジニアチームが10人規模に成長したことでフロントエンドチームとバックエンドチームに分かれてきたことから生じ始めた課題でした。

f:id:itohiro73:20211225202704p:plain
5人規模から10人規模へのエンジニア組織の変遷によるOKRのひずみ

はい、理想と現実の乖離がここで現れましたね。

  • 理想: プロダクト開発として追うべきミッションを最短で達成するために、チームで一貫した目標設定をしたい
  • 現実: 開発のミッションと各チームのOKRがバラバラで歪みのある状態になってしまっている

ここからはEMとしての課題解決ターン、CTOやPdMを巻き込み、現在READYFORが採用しているスクワッド体制の原型となるようなチーム構成の組み立てをしました。

f:id:itohiro73:20211225203129p:plain
スクワッド体制の導入によるミッションとOKRのアライン

これをベースにCTO @amachino が経営陣に対し全社的なスクワッド体制の導入を提案し、2020年から正式な体制制度として採用されたのが現行のREADYFORのスクワッド体制です。

f:id:itohiro73:20211225203848p:plain
2020年1月〜のスクワッド体制

こういった一連の課題解決は、READYFORが大切にしている「乳化」の概念とともに紹介させてもらいました。

tech.readyfor.jp

この時点でいくつかの課題解決の実績とともに、強みとしてのブランディング醸成が積み重なっています。

フロントエンドとバックエンドの分離

さて、体制がととのったので、もうプロダクト開発にアクセルを踏めるでしょうか？いやいや、そうは簡単にはいきません。 この頃は、まだREADYFORの全ての機能がRails上でモノリシックなサービスとして実装されており、フロントエンドもReact on RailsとしてRails上に密結合している状態でした。このままだと、今後エンジニアが増えていったとしても生産性が上がらない状態となってしまいます。はい、来ました、理想と現実の差分。

  • 理想: エンジニアが増えればフロントエンドエンジニアとバックエンドエンジニアが独立して生産性高い開発ができる
  • 現実: フロントエンドとバックエンドが密結合なモノリシックアーキテクチャーになっており、エンジニアが増えても生産性が上がらない

ここからの課題解決はEMが主導するターンですね。実際にプロダクトの優先事項として「クラウドファンディングのプロジェクト編集画面」の機能開発が計画されていたのですが、ここでフロントエンドの分離も合わせて推し進めることが中長期的なプロダクト全体の生産性底上げに寄与すると考え、実際に今ではいくつかの新画面はReact/TypeScript/Next.jsのフロントエンドとRailsのバックエンドが分離された状態で実装されています。

これはまさに冒頭の成果で紹介したポジティブな反響が多かった「フロントエンド分離戦略」がこのストーリーそのままです。実際の課題発見 => 目標設定 => 課題解決 => 成果の発信が一連の流れとして一貫しているからこそ、発信の内容が視聴者に刺さったんだと思います。

tech.readyfor.jp

複雑なドメインとの対峙

READYFORでは、サービスとして表出している画面構成から想像する以上に複雑なドメインを扱っています。

クラウドファンディングにおける「プロジェクト」という概念ひとつとっても、さまざまなコンテキストで扱われています。

f:id:itohiro73:20211225215404p:plain
クラウドファンディングの「プロジェクト」をめぐるさまざまなコンテキスト

このような複雑な概念が、ドメインに潜む深いモデルを適切に蒸留しないまま実装されてしまうとどうなるかというと、こうなりますね。

f:id:itohiro73:20211225215617p:plain
巨大なmodelコード

さあ、これは大きな課題です。理想と現実の差分を言語化してみるとこんな感じでしょうか。

  • 理想: 複雑なコアドメインが深く分析・モデリングされており、変更容易性の高い設計で実装され生産性高いコードになっている
  • 現実: 3700行に及ぶ巨大なモデルコード

この差分は大きいですね。既存のチームにはこれをできるリソースも専門性もまだない状態で、一筋縄ではいかなそうです。

EMとしてはどういった動きをすればよいでしょうか？

実際にOOC（Object Oriented Conference）というカンファレンスのランチスポンサーセッションでやったのは、これです。

f:id:itohiro73:20211225220036p:plain
仲間大募集

READYFORが実際に抱えている課題について公表し、その課題を一緒に解決してくれる仲間を募集したのです。詳しくは下の記事にまとめました。

tech.readyfor.jp

さて、ここからかくかくしかじかあってどうなったかというと、DDD界隈では名高い ミノ駆動 さんや t2kob さんにジョインいただきました。

tech.readyfor.jp

お二人にはREADYFORではまさにOOCで課題として公表した内容について取り組んで下さっています。実際にチャレンジングな課題をあけっぴろげに公表して、取り組みがいのある課題として認識してくださったからこそジョインしてくださったんだと思います（大感謝！！！）。

技術ブランディングの型をドッグフーディングしながら自社の強みを成長させる

さて、EMが取り組む技術ブランディングの型を再掲すると、こんな感じでしたね。

  • 理想と現状の差分を言語化する
  • その差分を解消していくための目標設定をする
  • 設定した目標を達成するための体制をつくり実践する
  • 目標が達成できたらそれを自社の強み・成果として発信する　

EMは普段から4半期や半期で目標設定しているはずなので、どうせなら1年単位で成果を振り返りつつ、翌年の展望も公表しちゃいます。

tech.readyfor.jp

そうすると翌年はEMはその展望に向かって目標設定・実践をどのみちするわけなので、年末に再度振り返ることでさらなるブランディング醸成につなげることができてしまうという仕組みです。

tech.readyfor.jp

冒頭の記事から引用したこれを再度思い出してください。

この記事で本質的に伝えたかったことは。 技術ブランディングを醸成するための本質的なプロセスは、Engineering Managerが日々対峙している課題解決の積み重ねと同義である ということです。「サービスの課題」であったり「エンジニア組織の課題」であったり「技術的な課題」であったり。それらの課題を解決していくプロセスの中で、実際に解決していった「実績」を「マーケティング」「広告」「PR」していくことで、自然と自社の技術ブランディングは醸成していく。そう私は信じています。

ここまで読んでいただいて、このプロセスの力強さを感じていただけたでしょうか？READYFORでは実際にこれらのことを地道に実践し続けた結果、前半にリストしたような成果を出すことができてきています。

また、実践編に細かくは書いていないですが、エンジニアたちが自発的に発信したくなるような環境づくり、場づくりもとても大切になってきます。このあたりはまた別の記事でいつか書いてみようかなと思います。

それでは長くなりましたが、Engineering Manager Advent Calendar 2021の25日目記事としては以上にしたいと思います。

長い記事を最後までご覧いただきありがとうございました！メリークリスマス！