こんにちは。
atama plus株式会社の @kzk-maeda です。
最近VPoE始めました。
あと最近テクニカルライターになりました。
この記事では、エンジニアチームで技術ブログを執筆する文化を促進するために開催した「みんなでTechBlog書いてみようWorkshop」の取り組みとその成果について紹介します。
また、その際に作成した記事のカタ「TechBlog執筆指南書」全文も併せて公開しますので、みなさんの記事作成の一助になれば幸いです！
「TechBlog執筆指南書」は末尾に記載するのでぜひご参照ください！
Workshop開催についての話
Workshop開催の発端
Engineering Management室という、atama plusのEngineering Manager陣を集めたチームの推進テーマの一つに「技術広報の促進」が掲げられていました。
この活動の目的は、単に採用プレゼンスの向上を図るだけではなく、エンジニア個人やチームに対し、学習や研鑽の機会を提供することにあります。
具体的には、以下のような効果を期待しています。
- 体系的な知識の習得：外部での登壇や記事執筆の機会において、体系的かつ深い知識が必要とされるため、学習の促進につながる
- 成果の振り返り：自分やチームの成果を新たな角度から振り返る機会になる
しかし、いざ「TechBlogを書いてみよう」としても、筆が進まない状況が続いていました。
私たちが推測した課題は以下の2つです。
- 執筆の時間確保が難しい：日々の業務の中で記事を書くための時間を見つけるのが難しい
- 何を書けばいいかわからない：これまで積極的に登壇や寄稿を行ってきた人が少なく、執筆テーマに迷う人が多い
これに対して、まずは第1の課題を解決するために、8月末から9月にかけて「寄稿強化期間」を設け、業務時間の中で一回記事を書いてみようと呼びかけました。
それでも、なかなか記事が出てこないという状況に対し、第2の課題である「何を書けばいいかわからない」問題にアプローチするために、同期的に「みんなで記事を書いてみよう」というWorkshopを開催することにしました。
Workshop開催に向けた準備
TechBlog執筆指南書の作成
Workshopを開催するにあたり、ただ時間を押さえて「さあ、どうぞ書いてください」では、なかなか執筆が進まないと感じました。そこで、次のような2つのステップで進められるようなWorkshop設計を行いました。
- テーマの壁打ち：何を書けばいいのかわからない人向けに、執筆テーマの選定をサポートする
- カタに沿った執筆：執筆方法がわからない人向けに、カタ（形式）に沿って執筆を進める
このTechBlogのカタとして「TechBlog執筆指南書」を作成しました。この指南書は、普段の業務の中で行った課題解決をテーマにして、以下のステップで初版記事を書けるように設計されています。
- 書く対象を決める
- 対象に関する知識を補完する
- 起承結の流れで情報を整理する
- 箇条書きで流れを作り、生成AIで文章を補完する
- 図表を用意して清書する
- タイトルを決める
実際にこの「カタ」を使って、自ら記事を書いてみてある程度使えることを確認したうえで、Workshopを実施する準備が整いました。
ちなみに「カタ」を使って実験的に書いてみた記事がこちらです。全くの白紙状態から、大体2時間弱で書けた気がします。
Workshopの開催
Workshopは、「カタ」に沿って2時間で初稿を作成することを目標に開催しました。
予想を超えるメンバーが集まり、それぞれが初稿を無事に完成させることができました。
みんなでmiroに集まってワイワイ書いている様子
参加者からも、「このカタを使えば、今後も継続して記事が書けそう」「人生が変わりました」といったポジティブな感想をいただきました。
忌憚のない感想の一例
Workshopの結果
Workshopを通じて、これまで以上のペースでTechBlogの寄稿が進みました。
※5月の寄稿数は、他媒体からの移植です。5月からZennをTechBlog媒体として利用することにしたため見かけ上数が増えています。
特に大きな成果は、普段の業務で何気なく行っている課題解決を、TechBlog執筆を通じて深く学び直す機会が生まれたことじゃないかな、と思っています。
これにより、対外発信の文化が一歩前進したと感じています。
実際、寄稿強化期間が終わった後も、少しずつ寄稿してくれるメンバーが現れ（エンジニアだけでなく、QAやUXなど他職種の方も寄稿してくれています！）、その際にも「カタ」を活用してくれています。
おまけのエピソード
10月初めに公開した記事が、強化月間全期間のPVを上回るペースで読まれるなど、思わぬ成果も得られました。
1記事で13,000PVを叩き出した記事はこちら：
こうした予想外の反響も、TechBlog活動の面白さの一つだと感じています！
記事のカタ: TechBlog執筆指南書全文
では、実際にWorkshopで、またそれ以降のいくつかの記事にも利用してもらっている「カタ」について共有します。
目的
白紙の状態からTechBlogを書いていくのが難しい場合、どのような出発点から最終的なアウトプットに繋げていけばいいかの参考になるであろう指針を書きます
また、GAIツールを利用して効率化するTipsについても記載します
対象となる記事
業務の中で対処したなんらかの課題解決にフォーカスした記事の書き方を対象にします
技術を触ってみた系とか、イベントレポートなどは随筆的側面が大きいので、書きたいように書いてもらえたらいいかな？
思考プロセス
書く対象を決める
まずは何について書くかを決める。なるべく情報鮮度が高く、解決のために紆余曲折したとか、工夫が必要だったテーマが好ましいです
「最近の自分の仕事で、これは苦労したけどなんとかなったなー」と思ったこととか、「これ結構いい感じでできたから自慢したいな？」と思ったこととかが良さそう
書く対象を知る
対象を決めたら、その対象について知っていることと知らないことを整理します
課題の発生〜解決までの縦の流れは体験しているので解像度が高いことが多いが、その課題はどういった時に発生することが多いのかや、解決策で採用した技術の周辺知識など、横の知識は仕事の中でリーチできないことも多いので、そういった情報を集めます
調べた内容をmiroに並べていきます（ここでは有機的な繋がりは一旦気にしない）
sample
起承結の流れで情報を整理する
集めた情報を文章構成の流れで整理し、付箋を並べ替えます
課題や周辺知識を起承結の流れでマッピングし、「起：どんな課題があって、承：どういう思考や知識を経て、結：どう解決して結果どうなったか」のストーリーになっているかを確認します
ここで足りない情報があれば上の「書く対象を知る」ステップに戻り、追加調査を行います
sample
アウトラインと箇条書きで書く
整理した情報をドキュメントツールに書き出していき、再度流れを確認します
アウトラインは起承結とし、各段階にマッピングした付箋を箇条書きの形で再整理します
# 起
- 前提知識
- どんな課題が発生し、解決しようとしたモチベーションは何か
- 例）データ基盤を移行したら転送料金が高騰した
# 承
- 解決のために調べたこと
- 課題解決のプロセス（うまくいったこと、いかなかったこと）
- 工夫したこと
- 例）datastreamの料金設計を調べ、BQ更新頻度にリニアに影響されることを特定
- 例）具体的にどこにコストがかかっているかを詳細に分析し、ドキュメントと突合
- 例）更新頻度変更の対処法について調べ、まともに対応しようとすると非効率なのでツール化
# 結
- 結果どうなったか
- 今後どうしたいか
- 例）転送コストが圧縮された（グラフを貼る）
- 例）テーブル単位で更新頻度を可変にする、BQの料金プランを調整する、などして更なる最適化を目指す
箇条書きで整理できると、起承結の各アウトラインに仮トピックを命名しやすくなります
sample
# 前提
- データ基盤を移行した（別記事に誘導）
# 基盤を移行したら転送料金が想定のN倍になる事象が発生
- データ基盤を移行したら転送料金が高騰した
# 転送コストを1/4にするためにやったこと
## 1. コストがかかっているポイントの特定
- datastreamの料金設計を調べ、BQ更新頻度にリニアに影響されることを特定
- 具体的にどこにコストがかかっているかを詳細に分析し、ドキュメントと突合
- （脱線）最初はdataformのview更新にコストがかかっている仮説で調べたが、的外れだった
## 2. 同期間隔を一括で変更する
- 更新頻度変更の対処法について調べ、まともに対応しようとすると非効率なのでツール化
## 3. 影響のモニタリング
- 変更直後からコストが下がっていることを確認（グラフを貼る）
# 成果と今後の課題
- 転送コストが圧縮された
- テーブル単位で更新頻度を可変にする、BQの料金プランを調整する、などして更なる最適化を目指す
図表を作成する
ストーリー説明に必要となる図表を作成したり、スクリーンショットを集めたりします
業務中に作成した図をそのまま貼ったり、ツールのスクリーンショットを並べたりするだけでもOKです
清書する
箇条書きの状態から、文章に整形します
このとき、一度ChatGPTやClaudeなどのGAIツールに箇条書き文章を渡して、文章化してもらってから不自然な表現を修正するなどすると効率的に記事が書けると思います
prompt sample
あなたは優秀なテクニカルライターです。
XXXという課題を解決した技術ブログを公開したいです。
必要な情報は以下に箇条書きで記載しているので、これを構造化された、技術ブログに適した文章にして出力してください。
構成やストーリーの流れが曖昧な箇所は勝手に補完せずに、意図を質問し返してください。
出力はmarkdown形式にしてください。
===
（箇条書き）
その後、自己紹介や結びの言葉などの半テンプレート情報を追記するのを忘れないようにしましょう
タイトルを決める
全体を眺めてタイトルを決めます
シンプルにやったことを一文で示すだけでもいいが、何について書いているのかはわかるよう、メインの技術単語は含むようにします
工夫を凝らすなら少し時間を取って以下の点など参考にしたタイトルを考えましょう
- 数字を入れる（XX%削減した、XX％高速化した、など）
- 疑問系にする（XXにはどうすればいい？、など）
推敲・レビューをする
一旦ここまでで形にできているはず！お疲れ様です！
今頭の中は記事に書いたことでいっぱいなので、一旦記事から離れて別の作業をしたり、翌日まで寝かせたりして距離を置きましょう。その後、クリアな頭で最初から読んで、わかりづらいところ、過不足、AI感が残っているところ、などを推敲していきましょう
セルフ推敲を終えたら、技術的な正確性をチーム内などその領域に詳しい人へ、大枠を技術広報チームへレビュー依頼して、複数人の目を通して記事の品質を担保をします
公開！
好きなサービス（一応個人のZennを推奨）に転記して公開！今度こそお疲れ様です！！！
miroテンプレート
miroで使えるテンプレートも作成しました。が、public templateとしては公開できなかったのでスクリーンショットで公開します。
さいごに
自己学習、プレゼンス向上などを目的として記事執筆を推進したいケースは多いと思いますが、かなり具体の実施例に踏み込んで、どうやってみんなが最初の一歩を踏み出せるようにしたか、という工夫について公開してみました。
うちではこんな工夫してるよーみたいな事例などあれば、ぜひコメント等で教えていただきたいです！
Discussion