はじめに
CyberAgent Developers Blog では4回目の記事となる吉田慶章 ( @kakakakakku ) です.最近,社名変更をした「株式会社マクアケ」でインフラ/サーバサイド/スクラムマスターなどを担当しつつ,今回のメインテーマでもある「技術広報」を兼任しています.ところで,皆さんのサービスには「技術広報」を担当するメンバーはいますか?
技術広報とは?
最近「技術広報」を担当している人が増えてきているように感じますが,業務として明確な定義はなく,各社それぞれに独自の役割があると思います.例えば以下のような活動が挙げられると思いますが,広義で言えば「サービスをもっと知ってもらうための技術的なマーケティング活動」と言えるのではないでしょうか.
- 記事執筆
- イベント登壇
- イベント開催
- 採用活動
- エバンジェリスト活動
- などなど
この中でも,私の技術広報としてのミッションは主に以下でした.
- 記事執筆
- イベント登壇
- イベント開催
比較的珍しいと感じるのは「日々サービスの開発/運用を担当するエンジニア自身が技術広報を担当すること」だと思います.兼任の難しさなどはありますが,エンジニアだからこそわかる技術広報の勘所なども多くあり,メリットは大きいと感じています.私は技術広報を兼任して,先月で「1年」となりました.この1年間を振り返るとともに,技術広報の必要性,そしてエンジニア自身が技術広報を兼任するメリットを整理したいと思います.
キッカケ
私が技術広報を担当することになったのは,ちょうど1年前の2016年10月でした.キッカケは私が所属する株式会社マクアケの中山社長から「もっと技術的なプレゼンスを高めていくにはどうしたら良いか?」という相談をもらったことで,その具体的なアクションの1個として,私自身が技術広報を兼任することを提案しました.当時の状況としては,社外どころか,サイバーエージェント社内でもサービスに対する技術的な認知度が低く,話をすると「外注で開発をしていると思っていた」と言われることもしばしばありました.このような状況を打破するべく,技術広報案に Go サインが出ました.
もともと,私は継続的にアウトプットをすることが好きで,個人ブログを書くことはもう10年間も続くほどの習慣になっています( kakakakakku blog ).また,大人数の前で登壇(プレゼンテーション)をするのも好きでしたので,私は技術広報に適したメンバーだったように思います.
ゴール設定
まず,技術広報として「前期 (6ヶ月)」と「後期 (6ヶ月)」のゴール設定をしました.ポイントは「採用」を直接的なゴール設定に含めない点でした.本質的には「技術的なプレゼンスを高めること」でしたので,「採用」はその成果として二次的に付随するものだと考えていました.
- 前期ゴール (2016/10 – 2017/03) : サイバーエージェント社内での認知度を上げる
- アクション : 毎月1件以上のアウトプットをする
- 後期ゴール (2017/04 – 2017/09) : サイバーエージェント社外での認知度を上げる
- アクション : 毎月1件以上のアウトプットをする
このゴール設定を前提に「定量 KPI」と「定性 KPI」を設定しました.しかし,技術広報として KPI を追うことは比較的難しく,ある意味で「感覚的な」形に落ち着きました.
- 定量 KPI
- アウトプットしたブログ記事と登壇資料のメトリクス(数値は割愛)
- PV 数
- はてブ数
- Facebook シェア数
- アウトプットしたブログ記事と登壇資料のメトリクス(数値は割愛)
- 定性 KPI
- エンジニアにサービスを知ってもらえていること
- 導入している技術スタックを知ってもらえること
- 「あの人よく見る!」という状況を作れていること
アウトプット紹介
上記のような「ゴール設定」と「KPI 設定」をした上で,1年間を通してどのようなアウトプットをしてきたのか,紹介したいと思います.
前期
前期はデザイン/インフラ/組織マネジメントをメインテーマにして記事執筆を行いました.「社内」をターゲットにしていたため,社内限定メディアでの記事執筆や社内の合同勉強会実施も積極的に行いました.
- 2016/11
- (弊社佐藤)記事 : ブランドをデザインする ー クラウドファンディングプラットフォーム Makuake
- 2016/12
- (弊社佐藤)記事 : 社内限定メディア(非公開)
- 2017/01
- (吉田)記事 : Well-Architected を目指した改善と組織文化への影響
- (吉田)登壇 : Tech Meetup / grafana-zabbix 活用術
- 2017/02
- 2017/03
- (吉田)記事 : 社内限定メディア(非公開)
- 合同勉強会の開催 : goa、HoloLens、Lambda + Apex他「LT Thursday」Vol.16
後期
後期は「社外」をターゲットにしていたこともあり,とにかく登壇にフォーカスしていました.「プレゼン芸人」と呼ばれるようになったのもこの時期ですが「あの人よく見る!」という状況を多少なりとも作れたのではないかなと思います.
特に July Tech Festa 2017 での登壇資料は現時点で「はてブ数 : 260」と「PV 数 : 5500」も獲得できており,定量 KPI を大きく超えることができました.
- 2017/04
- (吉田)記事 : Aurora 移行をキッカケに大きく改善したデータベース運用
- 2017/05
- (吉田)登壇 : Data Migration Night / どのように MySQL on EC2 から Aurora に移行したのか
- 2017/06
- 合同勉強会の開催 : 「急成長スタートアップ x 技術的負債」タップル誕生 x Makuake 合同勉強会
- 2017/07
- (吉田)登壇 : AWS Solution Days 2017 / Makuake の急成長を支える Aurora 移行事例
- (吉田)登壇 : JAWS-UG コンテナ支部 #9 / ECS x Mackerel
- 2017/08
- (吉田)登壇 : July Tech Festa 2017 / 急成長するサービスを支える DevOps 戦略と組織変革へのアプローチ
- 2017/09
- (吉田)登壇 : CROSS 2017 / Serverless Ninja Warriors
- (吉田)登壇 : CA.io #1 / Amazon ES に移行をしたら幸せになれるのか?
- (吉田)登壇 : XP 祭り 2017 / 全ては Fearless Change から学んだ,開発組織の変革を支えた実践的アプローチ
アウトプットのコツ
このように,1年間アウトプットを続けてきましたが,個人的に常に意識しているアウトプットのコツがあるので紹介したいと思います.それは「最初にストーリーを決めること」です.どんな開発プロジェクトを担当するときも,最初にストーリーを決めていました.ストーリーというのは開発プロジェクトに対する「5W1H」のようなものです.もっと具体的に表現すれば,アジャイルサムライに出てくる「インセプションデッキ」をイメージしてもらえると良いかもしれません.
- 施策の背景は何か?何が課題なのか?
- どのような技術で解決するのか?
- どのメトリクスがどこまで改善することで成功と言えるのか?
- どんなところに苦労したのか?(苦労しそうか?)
- などなど
組織でよく見かける光景としては,開発プロジェクトの途中で「そういえば,なぜこの開発が必要なんだっけ?」とモチベーションの部分がスタート地点に戻ってしまうことです.特に必要ではないけど「技術的に試してみたかったから」という理由だけで開発プロジェクトを進めてしまうと,このような状態になりがちだと今までの経験で感じています.よって,ストーリーを決めることが重要です.
ただし,ストーリーを決めるメリットは技術広報に限った話ではありません.私はストーリーを決めるのと同時に行える一工夫として「アウトプットの下書き」を先に用意しています.
- 記事の場合
- 記事のアウトラインと概要を最初に執筆する
- 成果の部分も期待している形で書く
- 登壇の場合
- 登壇資料(僕は Keynote が大好きです)のアウトラインと箇条書きを最初に作る
- 成果の部分も期待している形で書く
ここまで準備しておくことで「あとはゴールに向かって進むだけ!もう誰にも止められない!」という状況ができ,実際に開発プロジェクトが終わった後に,すぐにアウトプットの準備に着手することができます.もはや開発プロジェクトの「完了の定義」にアウトプットも含めてしまうようなイメージです.
登壇準備もスプリント計画に含める
技術広報との兼任をうまく回す方法として,技術広報タスク(例えば,登壇資料の作成など)も Issue として管理していました.こうすることにより,スプリント中の WIP 制限に乗せることができ「登壇資料を作っていたので他のタスクに着手できませんでした」という不透明な報告から「今日は登壇資料の作成に集中させてもらいます」という前向きな報告に切り替えることができます.
(ZenHub で技術広報タスクを Issue 管理している画像)
メリット
今回の記事で伝えたかったこととして,技術広報の必要性とエンジニア自身が技術広報を兼任するメリットを整理したいと思います.
まず「組織として技術的チャレンジに取り組んでいることを伝えることができる」ことから,技術広報は必要だと考えています.どんなにサービスの事業ドメインが面白くても,技術的に面白くなければ,注目されません.また技術だけではなく「どんな人が働いているのか」を伝えることができる点も技術広報のポイントだと考えています.
次にエンジニア自身が技術広報を兼任するメリットですが,既に記載した通り「開発プロジェクトを担当する前にストーリーを決めてアウトプット前提で進めることができる」点にあると思います.さらに技術的負債などマイナスをプラスに転換していくようなテーマを積極的にアウトプットできるのも,エンジニアならではの勘所だと思います.
そして何よりも,アウトプットの頻度が高まり「あの人よく見る!」という状況を作ることにより,技術的に勢いがあることを伝えられます.するとより一層,技術的負債の解消に注力できたり,新技術を導入したりなど,次のチャレンジに繋がりメンバーのモチベーションアップにも貢献します.さらに,アウトプットをすることによって +α のアドバイスをもらえる場面も増えたこともメリットに挙げられます.サイバーエージェント社内には多くのプロフェッショナルがいるので,技術的な戦略に対してディスカッションをする機会が得られるというのは,非常に嬉しいことでした.
逆にデメリットは無いのか?と聞かれたら,当然ながら「兼務の多忙さ」は挙げられると思います.私はインフラ運用をメインに担当していますし,さらに最近リリースをした「Makuake iOS 版アプリ」の開発では,インフラ運用とサーバサイド開発とスクラムマスターを担当しました.並行して登壇準備をするのは非常に大変でしたが,既に記載したような方法でタスク管理をし,うまく回していました.
まとめ
私はこれまで1年間,技術広報を兼任してきました.今回の記事では,この1年間の活動を振り返るとともに,アウトプットの紹介,アウトプットのコツ,技術広報のメリットなどを紹介しました.今期もまた別のゴール設定をして技術広報を兼任していきます.
もし今後,技術広報に取り組みたいと考えている場合は,会社ブログなど記事執筆から始めるのが良いと思います.さらに個人的な感覚ではありますが,比較的バズるテーマがあるため,3種類紹介します.
- 新技術導入/抜本的リニューアル系の記事
- 対象 : エンジニア
- 「スゴイ!尊敬!」を呼び込む
- 技術的負債系の記事
- 対象 : エンジニア
- 「ツライ!共感!」を呼び込む
- 組織マネジメント系の記事
- 対象 : 経営層/エンジニアリングマネージャー
- 「人間って難しい!共感!」を呼び込む
少しでも参考になれば嬉しく思います.
登壇資料
今回紹介した一部の登壇資料を載せておきます.