こんにちは。モノタロウの八木(t_yagi)です。
普段はフロントエンドのソフトウェアエンジニアをやっているのですが、同時にテックブログの編集にも在籍しています。
IT産業における需要の伸びにエンジニア人材が追い付かず不足が叫ばれている中で、優秀なエンジニアを見つけ出すことが難しくなっています。その背景でエンジニア採用広報の重要性はますます高まっている傾向にあり、たくさんの企業がテックブログを出そういう風潮を生み出しています。その反面、「それしんどくないですか」という感情をもつエンジニアもまた生まれつつあり、どう両立するのが良いのか広報担当の悩みのタネになっています。
この悩みのタネに対しモノタロウでは、量よりも質にフォーカスして取り組むことでエンジニア採用へとつなげています。
というのも、書いてくれるエンジニアに厳しい条件をかけたり、プレッシャーを与えるような方法を取ってるわけではなく、エンジニアの伝えたいことをプロデュースできる体制を整えることで世間的な評価を得ることができています。
今回は私たちがどの様に運用しているのか、テックブログの裏側について書かせていただきました。
編集チームを組んで記事の質を高める
テックブログを組織的に運用する企画が始まったのは2020年11月からでした。
そのため、編集チームを組み始めたのは、ごく最近の話でまだ1年しか経っていません。
企画として立ち上がったのは、大きく４つ目的がありました。
- 求めているエンジニアの採用応募数を増やす
- 自社エンジニアのスキルを向上する
- モノタロウ社内で組織的な業務活用を広げる
- 自社エンジニアの市場価値を高める
企画として立ち上がるまでは社内の有志が記事を書くスタイルを採用していましたが、これら４つの目的を満たすにまでに至らないことが課題としてありました。
知名度が足りない、読者ターゲットが不明など多くの仮説がありましたが、その課題に対して私たちは量よりも質を高めることを答えとして専念することにしました。
編集者も1本記事を書くことで執筆者の気持ちを理解する
量よりも質を高めるといっても、何をもって質を高めたと言えるのかが分かりません。そこで執筆者が内容を書く時の視点を理解するために、編集者自らが記事を執筆することにしました。
そして、その後の運用でも重要なポイントとして次の３つがありました。
- おもしろポイントを主軸にする
- 自社の事例が『価値』になる
- 組織学習を伝える We Learn な記事を目指す
どうしてこの３つが重要なポイントといえるのか、順番に解説していきます。
おもしろポイントを主軸にする
原稿を書くうえで、躓くポイントが２点ほど存在しました。
- 社外に説明する場合、どこまで背景を語ればよいか分からない
- 出来ること、やったことにフォーカスしがちで、伝えたいことが希薄
記事にするネタは、普段の業務の流れがあってのことが多いので、改めてバックグラウンドを考え直す場面がないことが躓く要因でした。そのため、ネタを一から説明するとしても過去に起きたことを並べがちになってしまいます。
これらを解決するためには、読者ターゲットを明確にし、説明してわかるラインを決定する必要がありました。また、その読者ターゲットが何におもしろいと感じるのかを明確に見極めることでネタの主軸を決めることも重要でした。編集者の中ではこれを「おもしろポイント」と呼んでいます。
自社の事例が『価値』になる
アイデアの創出や問題解決はビジネス的な背景や業務で起きた出来事などによって、考え方や仕組みが紆余曲折を経て変化するものです。我々エンジニアも、こうした様々な要因によって一般的に沿わない方法が正しい解決策になることがあります。たとえば世間的な最適解はAでも、特定の要件や条件下ではBが最適解ということもありえます。もしくは、最適解Aにたどり着くまでの道のりが、ビジネスインパクトを考慮すると遠回りをせざるを得ない状況になったりすることも多々あります。このような企業のケーススタディは、その企業でしか起こりえない問題があるからこそ書ける記事なので、希少性が高い記事になります。いわゆる事例紹介などがその部類に入ると思いますが、「どうしてこうなった」が記事の価値を上げる１つのヒントでした。
組織学習を伝える We Learn な記事を目指す
レビュー前提で進める想定だったので、アウトラインを厳密に作成するようにしました。これはコードレビューと同じ要領で、執筆者と編集者の双方の合意を取ったうえでスムーズに進むために必要な工程でした。
また個人ブログと比較して企業ブログにある特徴として、業務に通じる実績を伝えられる事がありました。これをモノタロウでは個人名義で記事として書きあげられることがメリットなので、「I Learn」に閉じず「We Learn」な記事を目指したい気持ちがありました。個人的に学んだ話というのはどの場所でも使える広義的な内容ですが、前述した企業のケーススタディに合わせるような個人の範疇を超えた記事を書くことはできません。そのため、様々な人や事象と関わった経験をもとに学んだことを記事として書ける、組織的に学んだ話にすることが理想的でした。
編集者は企業と執筆者のつなぎ役
「おもしろポイントを主軸にする」、「自社の事例が『価値』になる」そして「組織学習を伝える We Learn な記事を目指す」の３つのポイントを実現するために、編集者は企業と執筆者とのつなぎ役として存在することが望ましく、いかに世間的な評価の高い記事を両者に還元できるかが質の向上につながると考えました。
しかしながら、原稿が既に出来ている状態であったり、そのまま出したいという執筆者の意見も当然ながらあります。モノタロウの記事は個人名義で書いてもらうことを大前提としており、編集者はサポートする立場なため、執筆者の意見を尊重することを一番にしています。業務で通じているようなレビューほどシビアさやプレッシャーを感じさせたくないことや、なによりブログに正解はないことが根底にあります。
こうしたことを学びながらも、編集チームを組んで初めて投稿した記事が以下の記事になります。
結果、投稿してから1週間ほどで、1110PVを獲得することができました。
この記事を元に運用フローを策定し、編集チームとして動くこととなりました。
運用フロー
編集者自らが執筆し、前述に基づいたように質を高めるための鉄則を一文に要約すると次の通りでした。
執筆者の意思を優先し、「誰にとって何がおもしろいのか」を企画として落とし込み、アウトライン段階で伝え方をプロデュースし、希少性の高い記事を個人に還元する。
これを網羅できることが望ましいと考え、私たちは次のように運用フローを策定することにしました。
このフローをベースにモノタロウでは執筆者1名に対し、編集者2名（メイン・サブ）が担当しています。人数はコードレビューなどの要領と同じで、必ず奇数で合意が取れるようにしていることが理由としてあります。
企画会議ではおもしろポイントを決めるために「誰にとって何がおもしろいのかを決める」を主に議論しており、ここからアウトラインへと落とし込みをして決めています。
例えばPython2からPython3への移行を行ったプロジェクトに対する記事を取り上げた際は、アウトラインができた段階では以下のように執筆者と共に落とし込みを行っています。
■題材の面白いところ・アピールポイント
* 学びとしてまとめているところ
* テクニカル面
* 取組みにくさの有無
* バッチのあるべき機能が備わっているか否か
* 新規作成された際にあまり活用されなかった機能だったが、マイグレーション時に必要になった。
（例）ドライラン（出力だけする機能）の機能有無 \
データ更新手前で確認ができる。
実行ログなども同じ。落ちた時にどこまで実行できるかを追えるかなど。
* 考え方・取り組み方
* 実装時は機能要件に偏りがち
* 保守での観点も必要
* 結果として品質を上げる事や適切なリファクタリングにつなげることができる
* アウトプットの向こうの背景は知っておいた方が良い（主軸）
* どういう運用を想定されているのか
* どう使われるのか
* なぜ必要なのか
* そもそも仕様がなかった
* メンバーの考え方や向き合い方が変わった
■読者ターゲット
1. 現在、仕様をもとにコードを実装しているエンジニア
2. １をかかえるチームリーダー（自分と同じような立場の人）
3. 運用・保守向けのエンジニア
■この記事を読むことで読者が得られること(価値)?
* 実装時は機能要件に偏りがちで、保守観点が漏れがち
■読者に面白さをどう伝えたいか（アウトライン）
* when これまでの過去一年間の話
* what Py3化とUTF-8化
* why これまでのMonotaROの背景
* MonotaRoのシステムはPythonで出来ている
* レガシーコードを最新化する必要があった。
* 全部のバッチと向き合わないといけなかった。
* 長年そのままだったので誰が何を担当して、どうして作られたかがわからない。
* why 実装時コードは機能要件に偏りがち（担当者任せ。書く人によってバラバラ）
* バッチのあるべき機能が備わっているか否か
* 新規作成された際にあまり活用されなかった機能だったが、マイグレーション時に必要になった。
* 保守での観点も必要
* how ルールを決めて、PJを進めた
* アウトプットの向こうの背景は知っておいた方が良い
* どうしても必要なものは保守性も直した
* すべて対応できないのでリストを作った
* 何を基準に対応有無を分別したかの考え方（重要度、工数）
* result 結果として品質を上げる事や適切なリファクタリングにつなげることができる
* result その後どうなったか
* ドキュメントができた
* メンバーからの提案が多くなった
* why 後ろと前を知ることで最適解が見つかるようになった
このアウトラインをもとに以下のように記事が完成しています。
記事タイトルはアウトライン作成の段階で決めているのですが、原稿が出来上がった後にSlack上で編集者間で再考しています。というのもタイトルの引きなどをどうするかも最終チェックとして編集者同士で案を出しあって考えていたりしています。
上図で確認しあった記事は最終的MTGを行って以下のような記事タイトルで決定しました。
運用を開始してからの記事
我々、編集チームはTech企業としての知名度を上げたとする指標として、月間1万PVと1記事あたりのはてなブックマークを200取得することを目標として掲げていました。
この運用では沢山レビューを通す必要があるので、1記事にかかる時間が長いです。その分、出した時の当たり外れが大きいことが懸念としてありました。しかし、この運用を開始して徐々にPV数やはてなブックマーク数を伸ばすことができており、運用開始3ヶ月後には460はてなブックマークと目標を大きく上回った記事を出すことが出来ました。またこの記事が出てから常に月間1万PVを達成することができるようになりました。
PV数やはてなブックマーク数が増えるにつれ、SNSから読者たちの声を拾うことができるようになりました。テックブログを通じて、さまざまな人たちに価値を伝えられた事と、世間的な評価を得ることにこの頃から徐々に実現できてきました。
こうした反響が社内でも取り上げられて盛り上がったことで、記事を自ら書き出す人たちも出てくるようになりました。
SoftwareDesignから記事を書くお誘いを受けることもでき、ブログにも掲載できるレベルにまで達することができるなど社内の空気間に相乗効果が生まれ、おかげさまで良い雰囲気を作ることができています。
編集チームを組んで本気でテックブログを運用した結果、累計10万PVを達成することができており、実際の訪問者数（ユーザー数）で絞っても 7ヶ月で7万人が訪れるテックブログ へと成長を遂げることができました。
終わりに
テックブログにまつわる話題として、記事の数を増やして世間的な評価を得る方法を度々見かけることがあります。今回の内容はそれと逆行していますが、記事の数が少なくても質をあげることで世間的な評価を得ることができる１つの手段として紹介させていただきました。
このような編集の仕方をしていると執筆、編集ともに負担が大きいのではと感じる方も多いと思います。たしかに執筆、編集としての負担は大きいですが、普段とは異なる業務や知らない視点をたくさん学べる良い機会なので、記事になっていないバックグラウンドを含めて得られるものが大きいです。こうした学びは執筆していただいた方のこれまでの経験があるからこそ成り立っており、それを蔑ろにすることがないように私たちもそれと同時に二人三脚で全力でサポートしています。
また、モノタロウでは社内カンファレンスを行うなど日々社内においてもアウトプットに取り組んでおり、成功/失敗した経験もすべてをお互いに尊重しあえる文化があります。お互いがお互いを称えあう文化の延長線上で、テックブログでも同じように尊重しあえる温度感でこれからも続けられたら良いなと思っています。
最後に、ここまで読んでくださった方々、本当にありがとうございます。モノタロウのテックブログ記事を１つでも読んでいただけたり、コメントしていただくことが、私たちのモチベーションに繋がっています。これからもより良い記事を公開できるように取り組んでまいりますので、今後ともよろしくお願いいたします。
Techblog運営の裏話をもっと聞きたい方へ
今回のTechblog運営の裏話など、モノタロウの開発チームについて軽く話を聞いてみたい！という方は、カジュアル面談お待ちしております。
