テックブログ運営に意欲的に取り組まれている企業にフォーカスしたインタビュー記事。
「運営体制の構築と運営のコツ」
「目標やゴールをどう描くか」
「アウトプットの促進」
の3つの切り口で、第2回はクラウド型の建築・建設プロジェクト管理サービス「ANDPAD」を提供する、株式会社アンドパッド。
アンドパッドの鳩さんと土方さんにお話を伺います。
■インタビュイープロフィール
株式会社アンドパッド 組織戦略部 技術広報エンジニア
鳩 洋子さん
フリーランスのエンジニアとして8年ほどの活動経験を経て、受託開発会社にて、月額制アジャイル開発チームを提供するサービスの立ち上げを行い、事業企画と事業部CTOを兼任。現在はアンドパッドの組織戦略部にて、技術広報エンジニアとして採用広報・技術ブランディング活動を推進している。
株式会社アンドパッド マネージャー
土方 哲雄さん
エンタメ系企業、通信キャリアサービス系企業などを経て、アンドパッドにジョイン。元々はtoCのサービスをメインとしていたが、現実世界の業務の中で起きている問題をシステムで改善したいという気持ちが強くなり、toB SaaSの領域へ。現在は、エンジニアリングマネージャーとしてアンドパッドのQC（Quality Control）チームを率いるとともに、過去の幅広い知見を生かして採用技術イベントやSOCプロジェクトなどにも携わる。
■ANDPAD Tech Blog
https://tech.andpad.co.jp/
運営体制の構築と運営のコツ：具体例の提示があれば、エンジニアが参加したくなる
ーーまずは、テックブログを始めたきっかけについてお聞かせください。
土方：2019年にカンファレンスのスポンサーをしまして、せっかくなので現地の様子を記事にして発信しようと、テックブログが開設されました。
参考：開始当時の2019年4月の記事
2019-04-01から1ヶ月間の記事一覧 - ANDPAD Tech Blog
ーーその後、2019年は23件だったテックブログの記事数は、2021年は54件公開と倍増しています。どのようにメンバーや記事の発信数を増やしたのでしょうか。
土方：テックブログ運用開始当初はエンジニアによる草の根活動として始まったものでした。
2020年3月にテックブログなどの採用広報の活動を組織としてやっていこう、という方向性を定義し、草の根活動から全社の施策としての活動に変わりました。
テックブログ運営チームを作り、メンバー複数人で分担しながら運営を行えるようになったことが、発信数を増やせている背景だと考えています。
参考：テックブログ編集長になって運営を半年で改善した話 - ANDPAD Tech Blog
ーー現在のテックブログ運営チームはどのような役割を担っていますか？
鳩：2021年の10月ぐらいから採用広報を専任とするプロジェクトチームを発足し、そのプロジェクトチームでリードを担うことになりました。
同時に、テックブログ運営チームも私が編集長として取りまとめることになりました。
前編集長の福間さんの記事、テックブログ編集長になって運営を半年で改善した話にも書かれているような「リマインドをしっかりする」とか「担当表を作る」といったところは引き続き実施しています。
組織の急拡大に伴って次々と新たにエンジニアが入社しているのですが、そのメンバー全員にテックブログを率先して書いてもらうのはとても大変です。
ブログ執筆の辞退は福間さんによる運営改善後にも起こっていたので、より一層ブログを書きたくなるように、モチベーション向上を目指しました。
そのために、ガイドラインとテックブログレポートを導入したことは大きな変化といえます。
ーーガイドラインを作ったきっかけと、どのようなことを明記しているか教えてください。
鳩：前編集長の時代から、テックブログチームがしっかりとレビューする体制がありました。
エンジニア自身が何を書けばいいか、何を書いてはいけないのかを、レビューを受ける前から判断できるよう、ガイドラインを策定しレビューの基準を明文化しました。
当社は非上場企業なので、新規事業や新機能に関する未公開情報はもちろん、タイミングにより控えておきたい情報や表現があります。
エンジニアは、自分たちが開発した機能を外部にリリースしたかどうかは知っていても、どこまでの情報開示をしていいのか明確に把握していない場合があります。
公開NGの基準や概要のみを記載したガイドラインでは、どういったケースであれば公開OKとなるのか？について細かなパターンまで確認できず、不安になる方もいるため、具体的なOK/NG例を複数例示しています。
具体例を提示しておけば、自分で考えて類推したり、応用できるのがエンジニアの特徴だと思います。「あぁ、このパターンね」と判断がしやすくなり、スムーズに書き始められるエンジニアが増えました。
作成したガイドラインを参照しながらレビューを実施します。
また、テックブログ運営チームだけがレビューしているわけではなく、所属する開発チーム内やテックリードからも主に技術面についてレビューしています。
事業やプロダクトに言及している内容のブログの場合は、必要に応じてテックブログ運営チームから、広報に確認を依頼することもあります。
ーーテックブログレポートとは、どのようなレポートですか？
鳩：エンジニアが直近で書いてくれたテックブログの成果をまとめて社内で共有するレポートです。
- 直近で公開されたブログの内容と書いた人
- 特に見られているブログとPV数
- ブックマーク数
などを紹介しています。
忙しいエンジニアは、Slack投稿に添えた外部URLや添付ファイルまで確認する余裕がないことがあるので、パッと目に入るくらいのボリュームでSlack投稿内だけで伝わるように工夫しています。
開始当初はマンスリーで紹介していましたが、現在はクオーターに1回の頻度でSlackで流しています。すごくたくさんブログを書いてくれるので、短く紹介しきれなくて長くなることもありますね。
ーー「1年先まで担当表が埋まっている」というツイートを見かけましたが、スケジュールはどのように作成されていますか？
土方：先ほど「エンジニアに対して具体例を出しておく」というガイドラインの運用方針がありましたが、スケジュールでも応用しています。
私も昔はコード書いてたのでわかるのですが、基本的にエンジニアは「ブログをいつ書くか、自分で決めてカレンダーを埋めてください」と言われてもなかなか腰が重くなりがちです。少なくとも、私はそういうものだと思っています。
じゃあどうしたらいいかというと、具体的なスケジュールを作ります。
社内のエンジニア名簿をランダムに並べ替えて、スケジュール表の各週に1人ずつ埋める担当表を作成しています。人数がかなり増えたので、社内のエンジニアを全員並べると、1年分以上が埋まっている状態になります。
この担当表を全員に公開して「この順番でテックブログを書いていただく想定になっていますので、皆さんよろしくお願いします」と社内で伝えています。
一度提示されたものがあると、エンジニアはそこからの改善が得意なわけです。
順番を入れ替えたいとか、このタイミングは開発が立て込む予定だから無理、という反応を返しやすいので、私は、「担当表はエンジニアによるブログ発信の呼び水のようなもの」だと捉えています。
鳩：担当表というと、強制的なイメージがあるかもしれないですが、完全にランダムで辞退も自由です。
自分の順番ではない場合もネタがあるときは自由に書いていいし、順番の入れ替え希望にも柔軟に対応しています。
順番や期限を具体的に提示することで、ブログ執筆の一つのモチベーションとして活用してもらいたいという意図が強いです。
目標やゴールをどう描くか：知見をシェアして技術を高め合った結果、個と組織の成長につなげる
ーーテックブログ運営の目的をメンバーにどのように伝えていますか？
鳩：採用目的としてテックブログを運営するというケースは多いですが、当社ではテックブログの主な目的は採用ではないと考えています。
大切なことは、自分たちの開発組織において、どういう技術を取り扱っているか、どういうことを成し遂げてきたのかを社外に発信すること。
世の中に対外的に発信していくと、その知見がほかのエンジニアの参考になり、テクノロジーを前に進めること、技術革新へとつながります。
企業としてこの活動に取り組もうというのが、テックブログの本来の姿です。
意義のある知見を社外に残していく活動としてテックブログを企業として運営するうちに、社外のエンジニアに届いて、「この企業の発信いいな、この開発に興味を持ちました、この開発組織に行ってみたい」という気持ちになる候補者が現れます。
エンジニアがエンジニアのために発信して自分の足跡を残すこと、後世に知見を残していくことを目的としていても、結果としては採用に効いてくるので、採用のためにテックブログを書こうという目的を掲げられがちになっているんです。
採用への効果は目的ではなく、モチベーションにして欲しいですね。採用にも効くんだよ、自分たちの仲間になる人にも届くんだよ、だから書こうよ、と。
また、これまで知見をシェアする活動に興味はあっても個人では書けていなかったエンジニアも、テックブログを発信のきっかけとして活用していけるように、書きやすいスケジュールやガイドラインやフォロー体制を用意しています。
ーーエンジニア同士で知見をシェアして技術を高め合う活動を、企業として行っているのがテックブログと捉えているんですね。
土方：当社は Ruby on Rails で開発している比率が高いので、「知見を広めていこう」というRubyのコミュニティ文化の影響を受けていると思います。
ブログに限らず、エンジニアとして得た知見はどんどん発信していこう、イベント登壇していこう、ということを企業として促すようにしています。
アンドパッドのエンジニア組織には、技術コミュニティに積極的に関わりながらアウトプットをエンジニアとしての成長の手段とし、またコミュニティへの貢献に活用していこう、という文化が根づいているように思います。
ーー目標設定や、定量的なKPIの設定はあるのでしょうか？
鳩：テックブログ運営において、採用広報に直接紐付くような目標設定はしていません。
また、どれだけブログを読まれたかという中間指標やKPIもありません。
採用につなげるために、コンバージョンがいくら、PVがいくら必要で、そのためにはエンジニア全員で月に何本以上記事を書かないといけない、という指標は現状では立てていないし、必要ではないと考えています。
できれば毎月1本はブログが公開されている状態を続けたい、とは思っていますが、自分たちがやってきたことを楽しみながら発信していけることが重要です。
エンジニアが楽しんで発信できる場をつくれば、必然的に本数も増えるし、発信内容もクオリティも上がってくるので、認知も拡大していく。
そうやって書いたブログが広がって、PVが増えていった先に、アンドパッドに興味を持つ人が増える、その結果として採用につながっていくものだと捉えています。
アウトプットの促進：協力メリットまで浸透する社内広報で、声をかけあえる文化へ
ーーエンジニアにテックブログを書くことを促進する取り組みとして、どのようなことをしていますか？
鳩：とにかく書いてと一方的に言うのではなく、テックブログの活動に関する社内広報をすることがすごく重要だと思っています。
誰々さんがこういうブログを書いたよという告知をきちんと発信し、所属するエンジニアに認知されるようにしています。
告知のときには、シェアしてくださいと明確に伝えることも心がけていますね。
ーー新しいブログが公開された際に、社内での告知をしっかり行って、シェア依頼も添えるんですね！
鳩：そうですね。ただシェアして欲しいです、と伝えるだけではなく「エンジニアがシェアすると、周囲のエンジニアにたくさん見てもらえるから、候補者の関心を引けますよ」というところまで書くのが重要だと思ってます。
一見、採用活動に消極的に見えるメンバーであっても、自身が協力するメリットや目的が分かれば協力してもらいやすくなります。
メリットがわからないものに対して、あまり協力したくない、と反応する気持ちはすごくよくわかります。目的を明示することで、ブログを書いたりシェアすることがその先の結果につながるということを社内広報してくことが非常に大切です。
自分たちの仲間になる人を呼び込み、新たに優秀なチームメンバーとして採用できる効果がテックブログによって期待できるならば協力しようと思っていただけるものと考えています。
ーーブログを書いた先、シェアの先でどんな効果があるのか、エンジニア自身が協力するメリットをていねいに伝えているのですね！
鳩：ほかには、四半期に1回、テックブログ賞という表彰があります。
3ヶ月の間に公開したブログ記事の執筆者を対象に、テックブログ運営チームが表彰する制度を設けています。
ーーテックブログ賞とはユニークですね。ほかに、テックブログの成果を個人やチームの評価とする機会はありますか？
土方：テックブログの成果を評価制度の対象として組み込むルールは基本的にはないです。
当社の評価の仕組みとしては「あなたにはこういうことを期待しています」という期待値を明らかにして「私はこういうかたちで期待値に応えます」と明確な目標を掲げ、成果をあげることが基本になっています。
「こういう技術を身に付けた証跡として、ブログで発信しました」と成果を伝える手段としてブログを活用することはあります。
鳩：テックブログでまとめてあったらわかりやすいですからね。
「こういうことに取り組んできました」とURL 貼るだけで共有しやすいので、成果を伝える手段においても活用されています。
土方：テックブログがそのまま評価されるためというよりも、目標に対する成果を伝える手段となるから、というモチベーションで書かれていることはありますね。
ーーテックブログの運用を通して、こんな成果を実感できたという具体的なエピソードがあれば教えてください。
鳩：アンドパッドはtoBの事業会社なので、toCと異なって、エンジニアにプロダクトを触ってもらえる機会がありません。触ったことがないとイメージができず、全然興味が湧かないと思います。
ですが、テックブログに書かれた技術的なことについては、エンジニアはイメージができ、興味につながります。
プロダクトに触れる機会がなくても、自分のわかる技術や関心のある開発事例について積極的に発信している企業であれば、開発組織のなかの様子をもっと知りたい、技術の話を詳しく知りたいと感じられるのです。
だからこそ、アンドパッドのようなバーティカルSaaS（業種に特化して提供されているSaaS）においては、どういった技術を採用しており、どういった取り組みを進めているのかをテックブログで発信していくことが非常に重要です。
土方：先ほど、採用が目的ではないとお話ししたことと相反しますが、中途採用に応募してくださる方は、テックブログをきっかけに興味を持っていただくことが数多くあります。
「テックブログを見たのですが、ここはこういうふうに開発しているんですね」と盛り上がることで、候補者の方とのコミュニケーションのきっかけになったり、双方の技術的なマッチングが確認できる機会になります。
我々としては副次的に見ている「採用への寄与」に対して大きな効果があることを実感しています。
ーーテックブログが、認知獲得のきっかけになるだけではなく、技術力を含めた相互理解に役立っているということでしょうか？
土方：そうですね。採用に限らず、社内でも認知獲得や相互理解に役立っているといえます。
社内では知見を書き留めるWikiを運用していますが、発信力やディスカッションのきっかけとなる力は、テックブログのほうが強いと感じています。
組織が大きくなり、お互いのことを知らない場合もあるため、新しく入社した人には「テックブログで入社しての感想を書いてみませんか？」とできるだけ声をかけています。ブログを書いてくださることによって、その人の社内での認知が大きく向上しています。
業務や技術面だけではなく、書いている人がどういう人か理解が深まる効果があるように思います。
鳩：そうですね。人が増えてきて、チームもかなり多いなか、テックブログがお互いのことや他のチームの活動を知る場になっています。
社内向けの文章を書く場合、自分の所属するチームメンバーの業務や技術の理解度を前提とした書き方になりがちです。チームの外から見るとわかりにくい書き方になることもあり、他のチームの文章を読んで理解するにはやや高いハードルがあります。
テックブログを書く場合には、社外の人にも理解していただくための書き方をするので、社内の他のチームの人にとっても、わかりやすく伝わります。
「テックブログを読んだのですが、こういうことをやっているんだったら、教えてもらえませんか？」と他チームのメンバーからミーティングを設定されたという話を社内で聞いたことがあります。
「それいいね！やってみたい！」と他チームで、新しいライブラリや静的解析ツールを導入するきっかけとなった事例もありました。
ーー社内においてもテックブログを通して情報発信をすることで、社内コミュニティのナレッジの向上はもちろん、業務効率の向上や、新技術の導入に役立っているのですね。
鳩：役立ってますね。社内でわからなくて困っているメンバーがいたら「○○さんのテックブログのここに書いてあるよ」と自社のテックブログのURLを共有することで、エンジニア同士でサポートし合う場面を見かけることもあります。
ーーそのほかに、テックブログを書きやすくするアプローチはありますか？
土方：ブログのネタを考えやすくする工夫として、当社のSlackには「テックブログで」というスタンプがあります。
Slackのやりとりのなかで、テックブログ記事にしたら学びになりそうな話題、面白そうな話題には、「スタンプ押してね！」とエンジニア全員に伝えています。
スタンプが押された投稿はSlackのチャンネルにフィードとして集約されるようになっています。
もしもブログに何を書くか困っている場合は、そのチャンネルの投稿から自分のブログで書くネタを考えてもOKという運用にしています。
これは、企業ブログで拝見した、テックブログ盛り上げ施策を真似させていただきました。
ーー普段のSlackのコミュニケーションのなかで、ブログにしたいトピックスをエンジニア全員でひとつのSlackチャンネルにストックしているのですね。
鳩：スタンプを押すだけじゃなく「それ、テックブログにいいんじゃないですか？」というやりとりは日常的に行われています。
先日も社内のエンジニアが「そういえばあのネタ、ブログ書くって言ってたじゃん！」とSlackで声をかけてくれたおかげで、VPoEの下司さんのブログがリリースされました。
テックブログ運営チーム以外のエンジニアも、テックブログの目的や、発信した方がいいことを理解しているので、お互いに「テックブログにした方がいいんじゃないですか？」と声をかけあえる文化になっていると思います。
ーー運営メンバーだけでなく、お互いに背中を押し合って、自発的にテックブログを書くことを推奨しあえているのですね。
鳩：そうですね。テックブログを書いてもらいたいんだけど、書いてもらえない、うまくいってない企業の方がもしいるとしたら、書くエンジニアの気持ちになってみて、施策を考えたり、発信を考えたり、工夫を考えたりするのが、ひとつの突破口かもしれないですね。
ーーありがとうございました！
まとめ
お話を伺っていると、ブログを書いた先に自身やチーム、社会にとってよい変化を生み出そう、お互いの成長を促進しあおうという様子がうかがえました。
また、参加するエンジニア視点やメンバーの主体性を大切にしながら、
- 具体例を含むガイドラインやフォロー体制が用意されているから、書く活動に参加しやすくなる。
- 日常のやりとりからアイデアをストックして、書く内容を決めやすく。
- 採用に止まらない目的や意義を持った活動・運営を心がけ、社内でもお互いに「書こうよ」との声がけや背中押しが発生する。
といったポイントで、テックブログを通じた発信と個人・組織の発展や成長が連動する良いスパイラルが生まれていることがとても印象的でした。
次回も更新をお楽しみに！
