mkdir blog && cd $_

ITエンジニアの雑感

会社のテックブログを始めるときに考えたこと

会社にテックブログはあるが、日常的に運用されていない。アドベントカレンダーの時期だけ投稿がされる。 これから今後のテックブログ運用を再考していくようだ。

前の会社には入社した時にテックブログはなかった。 自分が開発チームの責任者になってから始めた。その時に考えた事を思い出して簡単にまとめておく。

目的

テックブログには以下の目的があった。

  • 会社の認知度・理解度を向上させる(採用活動への貢献)
    • 求職者への期待値調整。入社してからの自分が想像でき、入社後にイメージと乖離がないようにする
  • 社内に対してのナレッジ共有
    • 自分のチーム以外のことは、何をしているかを知らないことがある。それをブログを通じて情報を知ってもらう

意義を共有する

テックブログを始めるにあたってメンバーには、目的や意義を伝える。 意義を認識してもらうことで、「やらせるだけ」にならないようにする。

テックブログで会社のプレゼンスを向上させる取り組みは以下の意義があると思う。

  • エンジニア個人にとってのブランディグ向上になる
  • ブログを読むことで優秀なメンバーの採用に繋がれば、自分のスキルを向上させることにも繋がる

また、開発以外の部署にも協力してらもう必要がある。エンジニアの最優先事項はプロダクト開発である。

しかし昨今の採用難から採用活動の一貫であるブログ投稿も、業務の一貫してビジネスサイドにも理解してもらわないといけない。 巡り巡ってそれがビジネスの停滞を防ぐことになる。

内容について

なるべく会社に関連する内容であることが好ましい。会社でのナレッジを社内外に共有・発信する。

もしくは個人的な取り組みでも、エンジニアの人柄が分かるような内容であれば構わない。

投稿する事とそれを継続する事に重点を置く。

投稿内容のレビューについては以下のような最低限のチェックをして、カジュアルに投稿ができるようにした。

  • 著しく何かを毀損することがないこと。炎上するような内容ではないこと
  • 技術的な誤りや、偽りがないこと

運用方法

  • 隔週で記事を公開する
  • チームでローションをする。(Aチーム -> Bチーム -> Cチーム -> ...)
    • 担当をチームとすることで、個人が担当するよりも負担が軽減されるのではないかと考えた
    • 各チーム間での情報共有に繋がる
    • チームによって人数の多寡があるので、ある程度頻度は調整する
    • もちろんローションのタイミング以外で記事を書いても良い
  • 業務でどうしても忙しいようなら担当を交換することや1週ズラすなどはOKとする
  • Githubで記事を管理する
    • 文章フォーマットはCIでLintを動かしてチェックする
    • 2名以上のapproveをもらう

インセンティブ・ペナルティ

最初は、投稿数、シェア数・閲覧数などを目標設定に組み込んだ。 しかしアンコントローラブルな指標もあり、それらが高くても何も変わらないのでなくした。

あと目標になくても次第に意義も伝わり、書く事が当たり前のようになったのもある。

最後に

ブログが読まれる機会は、以下の時が多い。

  • 求職者がスカウトを受け取る
  • 求職者が面談・面接を受ける前
  • カンファレンスのスポンサーで会社を知った

その時に会社に対して自分とマッチしているかを感じ取れることが重要だと思う。

テックブログを始めてから、求職者と面談して「テックブログが定期的に更新されている事で、御社が技術に投資しているイメージを持った」といったニュアンスの言葉を多くもらった。

とりあえず定期的な投稿を始めてみるというのが一番大事だったなと感じた。そうしないと成果も課題も見えてこないので。