はじめに
はじめまして、学習管理プラットフォーム「Studyplus」を運営していますスタディプラス株式会社のCTOの島田です。
この度、弊社でも開発者ブログを始めることになりました。
最初の記事として、このブログを始めるにあたって考えた事を書きたいと思います。
目的
ブログの大きな目的としては採用活動への貢献があります。
その他にも以下のような事が目的として上げられると思っています。
- スタディプラスという会社の認知度・理解度のUP
- 求職者への期待値調整。実際に入社したがギャップがありガッカリするといったことがないようにする
- 採用活動中以外での定期的な外部への発信
- メンバーが発信を意識した業務への取り組み
- 社内でのナレッジ共有
- 技術的チャレンジの促進と技術力の向上
方向性
どんな内容の記事を投稿し、どういったブログにしていきたいかを考えました。 いきなりハードルの高いところを求めておらず、どれくらいの時間軸でどうなりたいかをメンバーと共有しました。
- スタディプラスに関連することが望ましい。会社でのナレッジを社内外に共有・発信する
- 他社ブログを指標にして投稿内容のイメージを持ち、段階的な成長を目指す。
例)
- ブリ：C社、M社
- ワラサ：S社、M社
- イナダ：E社、S社
- ワカシ：K社、A社
- 魚卵：弊社
懸念・問題
弊社でもご多分に漏れず、以下のようなブログ運用の懸念事項がありました。
- 記事執筆にリソース(人、時間)を割けないのではないか？
- 記事執筆・公開のサイクルが回らなくなり、ブログが放置されるのでは？
- 品質チェックは？
- 書くネタがない場合は？
解決方法
懸念事項に対して解決を考えてから始めないと、ブログ公開自体が逆効果になるので、そこを解決する運用方法を決めました。
リソース問題
これは、言い換えると優先度の問題とも言えると思います。
多くのエンジニアの最優先事項はプロダクト開発です。そこに会社のためとはいえブログ執筆をなんの考課もなく実施することは負担を生むだけとなってしまいます。
ブログで会社のブランディングを向上させる取り組みは、エンジニア個人にとってもブランディグをあげる事にも繋がり、更にそこから優秀なメンバーの採用に繋がればエンジニアのスキル、生産性を向上させることに繋がるのではないかと思いました。
なので、ブログ投稿を各エンジニアの目標に設定し評価の対象にしました。
評価は段階的な評価軸を決めて、以下のような運用を導入しました。(以下は簡略化した概要)
- A: 投稿が話題となる(n件シェアされる。ただし炎上はダメ)
- B: 投稿する
- C: 投稿しない
公開サイクル問題
投稿数をコントロールしやすくするため、各チームでのローテーションとしました。 スタディプラスでは、以下のようにチームが分かれています。
- CTO室
- サーバーグループ
- アプリグループ
- ForSchoolチーム
担当をチームとすることで個人が担当するよりも負担が軽減されるのと、各チーム間での情報共有に繋がると考えました。 そして、隔週でエンジニア全員が集まる、Engineering All Hands MTGで発表する事にしました。
品質問題
投稿前のレビューについては以下のような最低限のチェックをして、カジュアルに投稿ができるようにしようと思いました。
- 著しく会社を毀損することがないか
- 技術的に誤りがないか
ブログを始めたばかりという事もあり、まずは投稿する事とそれを継続する事に重点を置こうと思いました。
やってみなければ課題や問題がわからないので、適切に振り返りをして、失敗を恐れずにチャレンジして行こうと考えています。
ネタがない問題
- たまにであれば緩い内容のものでも良い。開発に直接関係なくても中にいるエンジニアの人柄が分かる内容でもOK。
- 弊社では情報共有にesaを利用しているのですが、そこに「ネタ帳」ページを作成しストックする事にしました。
最後に
ブログについては若干の見切り発車感は否めないですが、何事もやってみなければ分からず、かつ採用に通じる事は全てトライしていこうと思っています。
これから、本ブログでスタディプラスの魅力を発信していこうと思いますので、よろしくお願いします。
また、話を直接聞きたいという方もお待ちしております。
