テックブログに関わる人に読んで欲しい、「エンジニアの文章をレビューする」技術
気がつけば久々のnoteになってしまいましたが、私は元気です。
近況は...最近鍛えながら健康やせしたのでプロフィール写真を撮影し直しました、そのうちnoteに書こうと思います。
それはさておいて、4月に「週刊はてなブログ」さんの企画でこんなインタビューに答えました。
もうすぐ7年目を迎える個人技術ブログ「Lean Baseball」および、所属するJX通信社の「JX通信社エンジニアブログ」の話をメインに、「自分が書きたいことを書くことによって自分のキャリアにもつながるしなんだったら人のキャリアにもいい影響あるんやで」という話をしました（究極に端折るとそういう話です）。
補足で書いた番外編を含め、色々と好反響を頂き嬉しかったですありがとうございます。
一人のエンジニアであり、一人の技術ブロガーである私の物語としてはこれはこれで良いのですが、
テックブログに関わる人達が、エンジニアの気持ちを察して
いい感じにする話ってそもそも聞いたこと無いよな🤔
と最近思いました。ここ最近、何故か何人かの友人から「テックブログをやりたいのだがいいと思いますか?」「エンジニア採用で困ってるので助けて」とメッセを貰ったからでしょうか🤪
このテーマ（エンジニア広報とかブログ系の話題）は私からすると「テックブログなんてやめておけ」という個人としての本音（ちなみに現職のブログは僕自身がファンなので喜んで運営手伝ったり書いたりしてます）を含め、言いたいことは結構あったりします（的な話題をマガジンにしています）。
とはいえ、テックブログはやりたいでしょうし、やらざるを得ないなんてことは多々あると思います。
前置きが長くなりましたが、このエントリーは一言で言うと
ある日突然テックブログの管理人とか文章のレビューしろ！って言われた時に身につけておくといいかもしれない、「エンジニアの文章をレビューする」技術
を紹介したいと思います。
このエントリーの想定読者&この記事を書いている人
会社のテックブログに関わっている人たちすべて
ブログを書くエンジニア（に限らずデザイナーとかプロダクトマネージャーとかも）はもちろんそうなのですが、
・テックブログを会社ではじめると検討 or はじめたばっかりである
・すでにテックブログがあるのだが、思った効果がでない
・記事が少なくて困っている
...等の課題を抱えている経営層および採用・広報担当だったりエンジニアリングマネージャーの方に特に刺さるように書いています。
なお、（エンジニア以外の人が最も気になるであろう）「どうやったらウチのエンジニアはブログの記事を書いてくれるか？（どうやったらいい感じにお願いできるか？）」については書きません・触れません！
（会社・チーム・個人の事情で異なるので一言では言えないのが理由です）
なのでこの記事では「エンジニアが記事を書いてくれたとして」という想定で話を進めます。
また、この記事を書いている私は最初の紹介の通りガッツリとエンジニアをしていて個人ブログも会社ブログも書いていてかつ、会社ブログの方は2019年10月からすべての記事のレビューもしくは執筆に関与しています（つまり、技術ブログを書く人で読む人）。
【大前提】最初のレビューですべきこと
これはもうシンプルに、
よく書いてくれた！！ありがとう！！！
という気持ちを込めて「お疲れ様」「感謝」というお気持ちを表明することです。
↑はウチの会社のブログのSlackチャンネルからの引用ですが、読んだら肯定的なスタンプを押すだけでもかなり効果ありますし、書き手としてもすごく嬉しいです。
技術ブログって、書く前に事前調査（記述内容の裏付けとか）だったり、サンプルのコード（ときには動くアプリ丸っと一本ってこともあります）を書いたり、アイキャッチの画像を作ったりetc...ということを「早く新機能作ってクレメンス」「あのバグ治ったんだったけ？」というような普段の開発タスクの合間にこなしながら準備をして書くものです（これはこれでまあまあハードです）。
私は書き手としてもこの大変さを知ってるので（よほどおかしな内容じゃない限り）褒めることからスタートするようにしています。
もちろん、誤字脱字が気になるとか、単語・文章がわからない（技術のことはともかく、国語的な意味でというのも含む）とか、思わずいいたくなることも多々あると思います（ちなみにこの辺はエンジニアもしくはエンジニア上がりの人がよくやってしまうやつでもあります）。
が、このへんは一旦「よかったよ」「書いてくれてありがと！」とか間を置いた後に言ってあげるのがベストです、今すぐ直さないと死ぬものでも無いので。
ネガティブなフィードバックはどう伝える?
「よく書いてくれた！」「頑張った！！」...という気持ちを最初に伝えるとお互いハッピーだよという話を前の章でしましたが、とはいえレビューは必要ですし、時にはネガティブなフィードバックもしないといけません。
・誤字・脱字
・文章の構成がおかしくて読めない
・同じエンジニアからみても専門的すぎてついていけない
・著作権的にこれ大丈夫かな?
・これってまだオープンじゃない情報（社外秘）なのでは？
などなどの理由で、どうしても「直して欲しい」「書き直して」という機会は絶対出てきます。
この辺の対処方法は色々あると思いますが、私がよく使っているのは
「私からの提案」という感じで話をして、書き手に自分で考えてもらう
ようなフィードバックをよくしています。
・誤字脱字
・社外秘情報
・著作権・肖像権など権利・法令系のリスク
といった明確（ややブラックよりのグレーゾーンも含む）はピンポイントで直接言っちゃっていいと思っています（間接的に伝えるとミスリードにつながる可能性もあるので）が、
・文章構成
・表現
・「間違いじゃないんだけど、自分はこう思う」的なフィードバック（つまり意見）
あたりは、書き手・レビュアーの価値観・個性の違いや、得意不得意（エンジニアの技術的な事以上に、文章力というか文章を書き慣れてるかどうかという所が大きい）があったりするので、
・「私なら最初に結論を書いてから本文で説明するけど、結論が最後に来てるのは何かの考えがあって狙ってやってるのかな？」
・「クレメンス」ってのはなんJの(ry
・自分だったら文章より、絵図にしたほうが伝わると思いますが如何でしょう?
など、「執筆者の考え・意図を伺う」ような提案・問いかけができると最高です。
ちなみにこれはレビューする人の腕の見せどころです、鍛えていきましょう💪
技術的な話は躊躇せず人に振る
また、技術的な話でわからない部分は躊躇せず外の人にお願いしちゃうのがベストです（セカンドオピニオンって奴ですね）
私の場合、
・サーバーサイドとかデータサイエンスは自分でもわかるのでみる
・フロントエンドは少し自信ないので社内のフロントエンドの人にも見てもらう
・アプリは全くわからんので、技術文章の全体的な視点でコメントしつつ、専門部分は他のアプリのエンジニアに見てもらう
少人数のスタートアップとかだと、「フロントエンド一人で自分しかいない」みたいなのもあると思うので、信頼できる友人・元同僚に頼るでもいいと思います。
エンジニアじゃない、採用・広報担当の方がされるときはなおのこと躊躇せずエンジニアに振っちゃってください。
出した後に過ちや未熟な所に気がついちゃうと、メディアとしての質が...という所も問われちゃうので地味に大事な話です。
まとめ
ここまで書いたことを総括すると、
・最初のレビューは感謝から入ろう
・ネガティブなフィードバックは書き手に聞く感じのフィードバックを
（ただし、誤字脱字等の明確なものは直接言ってOK）
・技術・専門的な部分はセカンドオピニオンを確実にやる
これだけやればひとまず大丈夫だと思います、テックブログの立ち上げ2回、立て直しを2回やった私としては自信を持って言えます。
これってでもよく考えてみれば、「普段から言いたいことを言える・コミュニケーションとれるように、チームとしていい雰囲気・いい環境でやれるようにいい感じにしような」っていう話なんですよね。思いっきり心理的安全性の話にも繋がりますし。
なにかのご参考になれば幸いです&テックブログ云々の話はマガジンの方もよろしくです📖
頂いたサポートは、書籍購入・コミュニティ支援および、個人プロダクト（開発中）のリソースとして活用させていただきます。