justInCaseTechnologies (以下、JICT) のエンジニアの kondei です

当社のテックブログを設立したので、その目的と、廃墟にならず運営するためにはどうすればよさそうか考察したので記事にしてみます

現状

エンジニアの採用に苦労している
そもそも応募者が少ない気がしている
社員のイベント登壇や社員が書いた記事などの情報が集約されておらず、散逸していて探せない状況になっている
- 社員のツイートなどはあるが流れていってログとしての機能が弱い

採用上の問題の仮説

JICTのエンジニアが何をやっているかわかりづらいし、技術力やメンバーのブランド力による訴求力が弱いので応募に至らない潜在的候補者がいるのではないか
JICTのコーポレートサイトが必要最低限で、情報がないし正直技術力も感じさせないので応募に至らない潜在的候補者がいるのではないか
1. JICTが保険システムを提供している少額短期保険会社であるJICのコーポレートサイトは内容が充実しているが、 justInCaseTechnologies で検索すると上のが最上位にヒットするので、応募を考えた方はそちらを見ることも多いはず
2. JICのコーポレートサイトのデザインに合わせることができていない（2021年9月時点）ので困惑を生んでいる可能性があった

また、コロナ前は在職者が候補者と一緒に飲みに行って親密度を高めることがあったけど、今はご時世的に無いので、上記のようなオンライン情報の重要度が少し上がってるのではないか

残念ながらこれらを直接検証する方法はないものの、議論の中で「採用候補者の方にアンケートして、どの情報が良かった・もっと欲しい情報が何か　などの情報を集める」ことはできるという話が上がったため、余談ですがそれも派生して行うことになりました

対策として考えたこと

JICTエンジニアに関する集約された情報がないことへの対策

何らかのサービスを用いてテックブログを作る（低〜中コスト）
コーポレートサイトにテックブログの仕組みを実装する（高コスト）

結論として、低コストな外部サービスでテックブログを試しに作ってみることにしました

後述するかなりの懸念はありましたが、対策は講じる上で、廃墟になったら閉じるということも視野に入れて、試すことを優先しました

JICT側のコーポレートサイトがイケてないことへの対策

コーポレートサイトを作り直す（中〜高コスト）
いっそコーポレートサイトを消す（低コスト）
- 場合によってはテックブログに会社情報を移転？

結論として、JIC側と違ってJICT側のサイトはまだレガシーなコードベースになっているので、組織だって対策することは一旦保留になりました

しかし当社の Otani がデザインを一致させる改修をしたことで、混乱を生むデザインの違いは解消されました

足りない部分があれば改修を続けるようにはしたいと思います

テックブログをどうすれば続くのかについて考察

以下、テックブログに関してのみ記述します

テックブログを廃墟にせず運用することを考えるにあたって、次の記事は大いに参考になりました

note.com

共感した部分を引用すると

採用担当1人ではできず、協力を仰いだ数名でも続かない。全社的に巻き込まないと達成されない

や

「会社を盛り上げるために協力してくれ」で始まったブログは多く見ましたが、概ね最初の一ヶ月盛り上がって終わります。私が観察した範囲では、下記の要素のうち2項目くらい揃ったら直ちに危篤状態になります。

・編集長が居ない／転職する

・誰がいつ投稿するか決めない、スケジュールがない、締切がない

・濃密すぎる文章チェック・法務チェック

・（上記とは逆に）チェックが皆無で内容がしょぼく、社内外にディスブランディングとなって「投稿したら負け」という雰囲気になる

・（ヘッドハンティング対策で）完全匿名にする

・業務時間外に書かせる

・PV、LGTM、応募者などKPIを設ける

・社内に称える文化がない

・他職種から遊びに見えるような立て付け

があります

それに対する対策を考えたものが以下になります

低コストなものをなるべく書く

イベント登壇ログを簡単な文章で投稿
- 「○○が○○に登壇しました」
- 発表資料も置いときたい
QiitaとかZennに書いた技術記事（not 義務）があれば、リンクを簡単に投稿
- 「○○が技術記事を投稿しました https://~~ 」
ADR書いたら投稿
- 社内向けに作ったのを転記するだけなら低コストのはず

高コストなものは義務化しない

よくある（会社の名を背負っての）気合の入った技術記事
- 当然運用上は歓迎だが、義務にはしない

いつ、誰がやるか明瞭にする

最初は定期ブログ会（月1,2回で、1回15分とか）でネタを話して執筆担当者を決める事を考えました

しかし全員を巻き込みたいのに全員の入ったミーティングを作ることは無理というジレンマから、以下のようなSlackメンションを2週間に1回飛ばすことでスレッドで話す運用にしました

@エンジニア全員へのメンション

テックブログのネタ出しのリマインドです
書きたい/書きます/自分のコレどう？/他人のアレどう？　というネタがあればスレッドに記載・相談してください
例）
• 技術記事
• Qiitaなど外部に書いた記事へのリンク
• 登壇・発表の記録、発表資料
• ADR
• 開発環境やツールなどエンジニア的ネタ
記事は随時基本的に自由に書いていいので、書いた記事の事後報告も歓迎です

その他

特定の誰か（テックブログ発足を推進した自分とか、CTOとか、テックリード達とか）の意欲や頑張りに依存しない体制にする
業務であるという意識を共有する
書くことにインセンティブが生じるようにする
- 技術記事であれば、筆者名（ハンドル名）を明示することで個人の技術的経歴が増えるようにする
発信したら評価になるようにする
コーポレートサイトからリンクする

また、当社の Ogasawara から寄せられた面白い案としては以下のものがありました

個人が書いたものに、当社の求人を載せるというのはどうか？

逆に言えば、求人を貼るのであれば休日や朝晩に書いた記事であっても稼働を請求して良いものとする。

会社がなくなった時に記事がなくなるリスクもなくせる。

終わりに

当社ではエンジニアが個人的に記事を書いたり発表したりすることは既に行われています

しかしそれを集約した場が無いと、発見されず勿体ないという思いが僕にはあります

運用は変わっていくかも知れませんが、テックブログによって当社のエンジニア組織や技術力の魅力がより多く伝わるようになれば良いなと思います

また潜在的な候補者だけでなく、営業の際の技術上の訴求力向上にも繋がると良いなと思います

justInCaseTechnologiesのテックブログ

テックブログ始めました。その経緯と今後運用を続けるための考察

現状