Engineering Managerとしての技術ブランディングへの取り組み方
本記事はEngineering Manager Advent Calendar 2019の23日目の記事です。
自己紹介
2019年10月からREADYFORというクラウドファンディングの会社でVP of Engineeringを務めております、伊藤と申します。「いとひろ」と呼ばれることが多いです。2005年から12年ほど外資系金融の会社でソフトウェアエンジニアを務めたのち、FinTech系のスタートアップ2社を経て現職に就いております。
Engineering Managerと技術ブランディング
Engineering Manager（以降EM）が取り組むひとつの課題として、エンジニア組織をいかに成長させていくかという課題があると思います。そのためにも採用数を伸ばしていかないといけなかったり、人材流出を防ぐためにリテンション施策をとらないといけないと思います。その中のひとつの施策として技術ブランディングがあります。今回はこの技術ブランディングへのEMとしての取り組み方を記事にしたいと思います。
私と技術ブランディング
私はキャリアの時々でSoftware Developerだったり、Project Managerだったり、Technical Architectだったり、Head of Engineeringだったり、Senior Solution Architectだったり、エンジニアリング戦略だったり、VP of Engineeringだったりと、いろんなロールを経てきているのですが、ひとつ一貫しているのが、全ての会社で技術ブランディングにまつわる活動をしてきたことです。
1社目ではTechnology Marketing、2社目ではクリエーターブランディング、3社目ではdev-branding、4社目（現職）ではTech Brandingという、それぞれ違う名前で技術ブランディング活動に関わってきています。
なぜEMが技術ブランディングに関わるの？それって採用チームや広報チームの仕事じゃないの？
なぜ自分が関わるかというと、働いている会社が大好きなので、エンジニアの皆にもその会社やその会社のエンジニアリングを大好きになってもらいたいという想いがあるからです。
技術ブランディングは、もちろん採用チームや広報チームも関わっていくべきものです。しかし、技術ブランディングの本質的なプロセスは、EMが重要な役割を占めると思っています（ここで言うEMは、CTOやVPoEを含む、エンジニア組織を引っ張っていくロールの人たちすべてを想定しています）。本記事ではここを主眼にお話しできればと思います。
そもそもブランディングとは
ブランディングと、マーケティング/広告/PRなどの施策の違いは下の図によく表されています。
「マーケティング」や、「広告」や、「PR」は、自らもしくは外部の媒体を通じて、自分の魅力を伝えていく施策になります。対して「ブランディング」とは、他者から自らの魅力を認知してもらえた状態をつくる活動すべてを表しています。
では、単にマーケティングや広告やPRをしていけばブランディングは醸成されるのか？そうではないと思います。上記の絵の例で言えば、実際に「頭が良い」という中身や実績が伴って認知され、それらの信頼が積み重なって初めてブランディングは醸成されるものだと思います。
技術ブランディングを醸成するのに大切なポイント
では、企業が取り組む技術ブランディングとは、何をブランディングすればよいのでしょうか？それは言葉通り百者百様でしょう。「何を」ブランディングしていけばよいか理解するために、下記の様な質問にまずは答えてみると良いと思っています。ここでは主にWeb系のサービスを提供している会社の技術ブランディングを主眼と置いています。
- 自社のサービスの強みはどこにあるのか、どうありたいのかがしっかり言語化されているか？
- 上記の自社サービスの強みを実現するために、エンジニア組織全体としてのカルチャーの強みはどこにあるのか、もしくはどうありたいのかがしっかり言語化されているか？
- 上記の自社サービスの強みを実現するために、細分化された技術領域で、自社の強みはどこにあるのか、もしくはどうありたいのかがしっかり言語化されているか？
- プロダクトマネジメントの技術
- UXデザインの技術
- UIデザインの技術
- モバイル技術
- フロントエンド技術
- バックエンド技術
- インフラ・SRE技術
- ドメイン知識をシステムへ落とし込む技術（要求分析、要件定義、仕様策定、設計、等々）
- 開発プロセスの技術（アジャイル、スクラム等々）
- テスト、ソフトウェア品質向上の技術
- セキュリティの技術
- 等々
上記の質問にそれぞれ答えてみて、もし言語化がされていない場合は、まずは言語化を試みましょう。そこがスターティングポイントです。
次に、それぞれの質問に対して言語化を試みてみると、「自社サービス」「自社のエンジニアリング組織」「自社の技術領域」のそれぞれに対して、大まかに2つの領域が存在することが見えてくると思います
- 明確に強みであると言える領域
- 「こうありたい」という想いはあるが、まだそこに達していない領域
もちろん、会社によってこの2つの領域のグラデーションはさまざまで、前者が多い会社もあれば、まだまだ後者の方が多い会社もあるでしょう。
ではそれぞれどうブランディングしていけば良いか見ていきましょう。
明確に強みと言える領域のブランディング
明確に強みと言える領域では、ブランディングは比較的簡単です。明確に強みと言えると言うことは、ほぼ間違いなくその領域でなにかしらの実績を持っていることでしょう。その実績に対して、ひたすら上の「マーケティング」「広告」「PR」をくり返していけば良いのです。
中身は伴っているので、これらのブランディング施策は如実に効いてきます。臆することなく、技術コミュニティでの登壇、ブログ記事やnoteでの記事公開、採用イベントでのPR、OSSの公開等、どんどんやっていきましょう。中身が伴っているのであれば、強みや実績をひたすら売り出せば、自然と皆の信用・信頼は積み重なっていき、認知の拡大につながるでしょう。
本稿ではここに関しては深掘りしません。すでにつよつよなのであればどんどん認知拡大してくださいwというしかありません。もし題名を見てこれらの方法論について知りたいと思っていた方は、期待外れになってしまい申し訳ありません。
「こうありたい」という想いはあるが、まだそこに達していない領域のブランディング
世の中で技術ブランディングに困っている方たちはこの領域が広いのでは無いかと想像します。だからこそ困っているのでしょう。
「こうありたい」という想いがあるということは、最終的にそこをブランディングできるようになっていきたいということは間違い無いと思います。しかし、まだそこに達していない状態で「マーケティング」「広告」「PR」をしてしまうと、中身が伴わないブランディング活動になってしまいます。この時点でむやみにコミュニティ登壇やブログ記事、OSSなど出しても、無駄死にするだけです。
では、どうすれば良いのでしょうか。
ここでEMの出番です。Engineering Managerの諸氏におかれましては、「こうありたい」という理想と見比べた時の「現在の状態」を言語化してみましょう。そこで言語化されるのは「サービスの課題」かもしれませんし、「エンジニア組織の課題」かもしれませんし、「技術的な課題」かもしれません。
「サービスの課題」「エンジニア組織の課題」「技術的な課題」。あれ、これって、どこかで聞いたことありませんか？そう、Engineering Managerの方々が普段解決しようとしている問題領域に他なりません。
つまり、これらの問題領域はEngineering Managerのみなさんが普段取り組んでいる業務そのものなのです。ということは、みなさん、1年なり半期なり4半期なり、目標設定しますよね？「こういう問題領域を課題と思っていて、われわれエンジニアチームはそこを解決するんだ」という目標設定。
で、ここからは逆説的なんですが、これらの課題を公表してしまいましょう。「自分たちはこうありたいと思っているんだけど、こう言う課題があります。でも、それを解決していきたいと思っています！」と高らかに宣言するのです。もし解決の道筋がついているのであればそれも一緒に公表しましょう。ここは「マーケティング」でも「広告」でも「PR」 でもありません。自分たちの課題を共有しているだけです。そうするとどうなるのか。
世の中のエンジニアの大半は、課題が解決したくてしょうがありません。そして、自分が強みを持っている課題解決、または自分がこれから伸ばしたいと思っている課題解決を見つけると、のどから手が出るほどやってみたくなります。
このアプローチの良い点は以下の2点です。
- もし上記の様なエンジニアが課題に興味を持って、会社やエンジニア組織のビジョンにも興味を持ってジョインしてくれれば最強の戦力になります
- どのみちEMが目標設定している課題領域なので、エンジニアチームは取り組む必要があります
どちらの道をたどったとしても、数ヶ月後には何かしらの実績を出していることでしょう。実績が出なかった場合はまた頑張ってください。実績が出た時点で、実際に解決した問題領域（サービスかもしれないし、組織かもしれないし、技術かもしれない）とその解決プロセスを「マーケティング」「広告」「PR」 してしまいましょう。この時点では「中身のある実績」となっているため、その点においてはコミュニティ登壇や、ブログ記事公表等々が、ブランディングとして効いてきます。エンジニアの多くは「〇〇という課題をこうやって解決した」という話が大好きですから。
さて、「こうありたい」という姿に一歩近づいたところで、再び立ち止まって振り返ってみましょう。「こうありたい」という理想と見比べた時の「現在の状態」を再度言語化し、「サービス」や「エンジニア組織」や「技術」の課題をあぶり出していきます。そこからはまたひたすら上記の繰り返しです。
このプロセスを繰り返していると、いつのまにか「こうありたい」という姿に限りなく近づいていて、それが「自社サービス」「自社のエンジニア組織」「自社の技術」の強みに変わっていることでしょう。そして、あなたは合間合間にこれらの強みを中身のある実績として「マーケティング」「広告」「PR」 してきているはずです。
この頃にはすでにあなたの目指していた技術ブランディングが完成し、皆が自社のサービスやエンジニア組織や技術領域の強みを認知してくれている状態をつくれているはずです。
そんなにうまくいくのだろうか？
いえ、現実はそんなにうまくいきません。ここまで読んでいただいて大変申し訳ないですが、上記はすべて私の仮説です。一部私のキャリアを通じて実証できた部分もありますが、いまだに最後の「こうありたいと言う姿にたどりついて技術ブランディングが完成した」という段階まで達したことはありません。
しかし、この記事で本質的に伝えたかったことは。 技術ブランディングを醸成するための本質的なプロセスは、Engineering Managerが日々対峙している課題解決の積み重ねと同義である ということです。「サービスの課題」であったり「エンジニア組織の課題」であったり「技術的な課題」であったり。それらの課題を解決していくプロセスの中で、実際に解決していった「実績」を「マーケティング」「広告」「PR」していくことで、自然と自社の技術ブランディングは醸成していく。そう私は信じています。
おまけ
READYFORでは、「誰もがやりたいことを実現できる世の中をつくる」というビジョンの元、「想いの乗ったお金の流れを増やす」ためのプラットフォームづくりに取り組んでいます。2019年1月の町野CTOのジョインから1年でエンジニア組織が2倍になるくらい急成長していますが、やりたいビジョンの大きさに対して、まだまだエンジニアが足りていません。
READYFORというクラウドファンディング のプラットフォームが稼働し始めてからすでに8年以上たっており、正直な話、レガシーかつモノリシックなつくりになってしまっています。それでもやりたいことの実現のため、スケーラブルなシステムへの変遷を進めつつ、サービス開発を推し進めていきたいと考えています。
課題を解決するのが大好きなあなた、下記のようなキーワードにもしちらっとでも興味を持った方は、ぜひTwitterで itohiro73 までDM等でお気軽にご連絡ください！我々が抱えている課題についてざっくばらんにお話しさせていただきたいと思っています。
- 密結合してしまっているフロントエンド（React）とバックエンド（Rails）の分離を推し進め、React/TypeScriptを用いて疎結合で凝縮度の高いフロントエンドコンポーネントを設計しつつデザインシステムの構築をリードしていきたいフロントエンドテックリード
- 戦略的設計を用いた複雑なドメインのユビキタス言語の発見や境界づけられたコンテクストの設計、型に守られていないRuby on Railsの複雑なモノリシックサービスの大規模リファクタリング等に取り組んだことのあるバックエンドテックリード
- いわゆるSystem of Recordと呼ばれる、サービスのお金の流れが行き着く先の決済・会計領域の堅牢なシステムを構築したいバックエンドエンジニア
- 言語化されていないサービス仕様を明確にし、リファクタリングに備えるためのテスト設計・実施を推し進めることが得意なQAエンジニア
- 他、われこそはという腕利きのエンジニア
ではでは、本記事は以上とさせていただきます。
