良い会社の技術ブログはどう運営されているのか
(danluu.com)魅力的な技術ブログの共通点
-
承認が簡単、またはほとんど不要
-
承認/編集プロセスが、エンジニアにとって投稿をより魅力的なものにする
-
Cレベルの支援
魅力のない技術ブログの共通点
-
遅くて承認プロセスが多い
-
技術職ではない側の承認も必要
-
承認/編集プロセスは主にリスクを取り除いたり、特定内容のリファレンスを削除したり、投稿を曖昧にしてエンジニアにとって面白くないものにしてしまう
-
ハイレベルの支援がない
インタビューを通じて整理した、うまく運営されている3社のプロセス
Heap
▪ 誰かが記事を書くアイデアを持ったら
▪ 執筆者(エンジニア)は、記事を編集して承認してくれる「バディ」とペアを組む
▫ バディは、良い文章を書いた実績のあるエンジニア
▫ 何度かのラウンドを経るうちに、記事の要点(thrust)が変わることもある
▪ CTOが読んで承認
▫ たいていは軽微なフィードバック
▫ 「デザイナーがこのグラフをもう少し見やすくできそうですね」程度の提案
▪ 記事を公開
-
最初の編集段階で草案をSlackチャンネルに共有し、誰でもフィードバックできるようにしていたが、
あまり良い体験ではなかったため、このような段階で「フィードバックが多すぎる」状態にならないようプロセスを設計
Segment
▪ 誰かが記事を書くアイデアを持ったら
▫ しばしば社内文書、外部発表、公開したプロジェクト、自社開発のオープンソースなどから持ってくる
▪ 執筆者(エンジニア)が草案を作成
▫ シニアエンジニアが草案作成を手伝うこともある
▪ 最近まではフィードバックプロセスがなかった
▫ 共同創業者とエンジニアリングマネージャーが主にフィードバック
▫ マネージャーおよび技術リードたちからフィードバック
▫ たいてい3稿目くらいで完成
▫ フルタイム編集者が編集を開始
▪ 技術チームに知らせ、15〜20人ほどからフィードバックを受ける
▪ PRと法務チームが確認し、軽い承認段階を経る
-
1週間ブログ執筆の時間を取る「Blogging Retreat」制度
-
Writing と Speaking が成果評価およびキャリアラダーで報われるよう、明示的な基準を策定
CloudFlare
▪ 誰かが記事を書くアイデアを持ったら
▫ 社内ブログ文化が社内文化の一つであり、いくつかの投稿は社内ブログから持ってくる
▪ CTOはすべての記事を読み、他の人たちも読んでコメント
▫ CTOが記事を承認
▪ CEOがブログ運営の後援者
▪ 「非常に速い」法務承認プロセス、1時間以内のSLO
▫ あまりに軽く、実際に存在するのか分からないほど
3社だけをもとに書かれた内容なので、これで一般化するのは危険だが、経営陣の支援は重要
5件のコメント
内容そのものへの指摘よりも、どう書けば読みやすくなるかという観点で見てくれるフルタイムの編集者がいれば、本当に助かるでしょうね。
国内では、Market Kurlyが最近書かれた記事がありますが、GeekNewsにはまだありませんね。関連してあわせて見るとよいです。
"技術ブログを再デザインしながら" https://helloworld.kurly.com/blog/redesign-tech-blog/
スタートアップ技術ブログまとめ 開発後記 https://ja.news.hada.io/topic?id=1536
作られた国内スタートアップ技術ブログまとめサイトのアドレスが変わりましたね
https://metapost.dev/
良い記事をありがとうございます :)
記事の修正はモバイルではできないのでしょうか?
ああ、GeekNewsには修正機能がありません ^^;;
ああ、そうなんですね (T_T)
教えていただきありがとうございます