テックブログに書くネタがないって本当ですか？から"本当の理由"を科学する 〜マネーフォワードのデータでみる原因と考察〜
この記事は技術広報 Advent Calendar 2022の10日目の記事です。提供はマネーフォワードで技術広報をしている luccafort でお送りします。
昨日の記事は えんじぇる(@sweet_chiho)さん で「社内テックカンファレンス"In da STORES"を開催しました」でした。こちらもぜひお読みください。
[CAUTION]
この記事は luccafort の脳内ダンプなのでおよそ9500文字ある超大作に仕上がってます。歯ごたえのある文章量を読みたい方だけ読みすすめるようご注意ください。
[/CAUTION]
皆さんはカタールで行われているFIFA ワールドカップを観戦されているでしょうか？
ぼくは観戦しています、具体的にはこの記事を書いている12月4日 午前4時のアルゼンチンvsオーストラリア戦を観戦してました。
応援していたアルゼンチンが勝利し、次の試合がなんと誕生日兼アドベントカレンダー担当日に開催されるということでアルゼンチンの勝利という最高のプレゼントを期待し、この記事を書いています。
毎度誕生日にAdvent Calendarを書くふるまいをしているのでこの記事が役に立ったよ！という方は欲しい物リストからなにかプレゼントをください。
誕生日以外に読んでもプレゼントは365日絶賛募集してるのでぜひ。
想定読者
テックブログの運営者
自社の技術ブランディングを強化したい人事・広報
技術広報・採用広報をされている方
本著を書こうと思った発端
「テックブログに書くネタがない」なんて事はそうそうなくて、普通に1ヶ月仕事してれば、1つくらい何か技術的に学びはある。
— 神速 (@sinsoku_listy) October 14, 2022
あるときTwitterで「「テックブログに書くネタがない」なんて事はそうそうなくて、普通に1ヶ月仕事してれば、1つくらい何か技術的に学びはある。」という発言をみかけました。
この発言をみたぼくの反応として「その通りだな！」と同意を示したのですが、少ししてからどうにも周りの反応がそうではないことに気づきます。
「書くネタがない」「書く時間があればね…」という反応がちらほらあり、次のようなことを考えました。
「1ヶ月とは言わずとも数ヶ月、半年あれば何かしらの学びはあるはず。ブログに書くかどうかはさておきネタがないとはどういう状態か？それは本当にネタが思いつかないや時間がないことが原因なのか？」
本記事が届けたい価値
そもそもテックブログが書けないのはなぜか？その書けない"本当の理由"はなにかを考察し、原因を理解することでアウトプットする際の障害の一端を解決できるのではないか？と考えました。
（なんか最近ブログで困るとすぐ「考察して分析してみました！」系の記事を多用している気がする。）
本記事ではテックブログが書けない"本当の理由"を分析し、考察した結果から導き出される仮説とマネーフォワードのデータを元にテックブログが書けない理由を科学したい（※）と思います。
科学的な視点に立って対象を捉え、分析や理解を試みる、といった意味合いで用いられる言い方。「スポーツを科学する」というような言い回しで用いられる。
前提条件
まず前提条件を揃えたいと思います。
サバイバルモードでない組織であること
ブログを書くモチベーションがある人がいること
ある程度インプットする時間があること
サバイバルモードとはエラスティックリーダーシップで「チームに学習する時間が十分にない状態」と定義されている状態です。
またモチベーション（動機）がない人を無理やり書かせることはエンジニアリング組織論への招待に記載されている「不確実性の発生原因」なので対象外とします。
最後に、ブログを書く、というか何かしらアウトプットする際にはそれを支えるインプットが必要です。そのためインプットに全く時間が取れない人や組織は省きたいと思います。
前提として「サバイバルモードでなく」「モチベーションがあり」「ある程度インプットする時間がある」方や組織を対象とします。
よく見聞きする書けない理由の整理
以下がぼくが知る限りでよく見聞きする"書けない理由"です。
テックブログを書く労力が高い（時間がかかる）
情報の裏付けをするのが大変
業務が忙しく時間の確保が難しい
きちんとしたブログは書くこともそうですが、技術的な裏付けの確認や検証、そしてそれらが書かれた一次情報を調べることに多くの時間を要します。
また一番多く上げられる理由は時間のなさでしょう。業務が忙しいとどうしても優先順位が低く、余暇時間で書こうとされるテックブログは後回しになる傾向が高いです。
データで見るマネーフォワードの書けない"本当の理由"
一般的な意見として「テックブログが書けない」には大きく分けて2種類の「書けない理由」があると考えます。
執筆者にとって何かしらの障害・障壁があり「書けない」ケース
ブログ運営者にとって継続的に情報発信されないケース
本記事ではマネーフォワードの事例やデータを元にそれぞれ前者のケースで障害となる理由とその対策について考察と分析をしていこうと思います。
全ての基礎はユーザーヒアリング
マネーフォワード社内でブログを書いたことがない、あるいはブログを書きたいと思っているが書けていない有志によるアンケートをお願いさせてもらいました。
回答結果のサマリーは次になります。
1つ目の設問の意図は「回答者のアウトプットに対する姿勢を確認する」ものです。
書けないという人が「能力や環境的に書けるが書かない」なのか「モチベーションがあるが何かしらの阻害要因で書けない」なのかを確認しています。
会社のテックブログには書きたくないが、個人でブログは書いている
ブログは書かないがそれ以外のアウトプットをおこなっている
そもそも書きたくないと考えている
さまざまな意見が出ましたが4割以上の方がブログを書くという行為自体が未経験であることがわかります。
ブログは書いていないが他のアウトプット手段を選択している人やできれば書きたくない人がそれぞれ1割ほどいることもわかりました。
2つ目の設問は「書けないと本人が考えている理由」についてです。
だいたい1割〜2割で綺麗に意見が別れています。
ブログが書けない理由としてよくあがる「書く時間がない」「書くモチベーションがない」はそれぞれ2割ほどしかなかったのは想定外の結果でした。
過去（2021年3月頃）に似た設問に回答してもらったときは「業務が忙しすぎる（≒時間がない）」が49%だったのでそれに近い数値がでると予想していましたが、数値上は異なる結果となりました。
投票形式が違ったりアンケートの回答者層が異なるので単純な比較はできませんが、書けない理由でよくある時間的な制約は絶対的ではない可能性が出てきました。
データから分析したブログが書けない"本当の理由"の原因
先程のデータが指し示す事実は大きく分けて2つに分類できます。
メンバーの60%はモチベーションはあるが書けていない。
メンバーは執筆時・執筆後の不確実性が非常に高い状態である。
これらについてどのようにすれば障害が取り除けるか考えていきたいと思います。
1.メンバーの60%はモチベーションはあるが書けていない。
データではおよそ2割の回答者が「モチベーションがない」としています。
前提でも書いた通りですが、モチベーション（動機）がないメンバーへのアプローチは本記事では取り扱いません。
理由としては今年開催されたScrumFest Niigataで登壇された内容が非常に簡潔に説明しているのでそのスライドを引用します。
このデータが明確に示すことがあります、それは「書いてもよいとするメンバーはモチベーションを阻害する障害を抱えている」ということです。
当たり前のことですが、事実を見据えて次の分析内容に移っていきたいと思います。
2.メンバーは執筆時・執筆後の不確実性が非常に高い状態である。
先程のデータでは阻害要因に対する情報がありました。
文章を書くのが苦手である
書くネタが思いつかない
ブログが炎上することが怖い
同じテーマが存在する
コストに対してメリットが見合わない
これらを分解すると大きく3つに分けれます。それは「文章構成能力に対する不安」「他者評価による不安」「記事の価値認識の不満」です。
筆者はこれらは全てテックブログを書くという行為に対する不確実性が高い状態になっているために発生していると考えました。
エンジニアリング組織論への招待では不確実性の発生原因を2つだと紹介しています。
不確実性とはつまり「わからないこと」によって生まれます。人間にとって、本質的に「わからないこと」はたった2つしかありません。それは、「未来」と「他人」です。
「文章構成能力に対する不安」に関しては単にスキルの問題なので比較的容易に解決策が見つかると考えます。
テクニカルライティングが低いのであれば、よい論文の書き方が参考になるでしょう。
このような文章は様々な大学機関や教育機関が学問として研究、成果を発表しているのでまずはそのフレームワークに乗るだけで大部分が改善されます。
次に「他者評価による不安」です。
これは2つの要素があります、1つ目は記事に対する価値の生み出し方です。
テックブログのテーマやネタは必ずしも斬新であったり画期的である必要性はありません。以下の引用は論文を対象にしていますが、テックブログも同じであると考えます。
重要なのは「自ら課題を設定し、情報を収集・整理・分析したものに独自の考察と検討から導き出される結論を得ること」です。
研究（卒業）論文の場合には、必ずしも斬新な理論展開や画期的
な成果が要求されているわけではない。
そう考える理由として開発者（エンジニアやデザイナー）が持つ性質は「課題解決者」だからです。
課題を解決するためには何かしらのアウトプットを出すことでアウトカムを達成する必要があります。
そのためアウトプットの質を高める手段の1つとしてテックブログがあると考えています。
先日以下のツイートをたまたま見かけたのですが、個人的にとてもしっくり来る表現だなと感じました。
「読む量は学力の上限を規定し、 書く量は学力の下限を規定する」（岸本先生、百ます計算の方）#Forkwell_Library
— m3hiro3｜まさひろ (@m3hiro3) November 15, 2022
また「技術をアウトプットするところに技術は集まる」性質があるとも考えています。マネーフォワードはテクノロジードリブンをMVVC（Mission/Vision/Value/Calture）に掲げる企業です。
これからもテクノロジードリブンを体現する組織であるためにはブログに限らず様々なアウトプットにチャレンジし続ける必要があります。
これは観測者としての1意見ですが、テーマの重複を気にされている方やネタに困っている人の多くが、記憶にあるテックブログの記事が画期的なアイディアや斬新なテーマであることが多く、そのインパクトに引きずられバイアスが掛かった状態になっているのではないか？と感じることがあります。
プロダクト開発でいうならば突然ある機能をビッグバンリリースをして成功させようとしている状態に近いのではないかと思います。
背伸びをする必要はないので、いまの自分が出せるアウトプットを出してもらい、数年後にふりかえったときに成長を感じてもらえるならそこには十分価値があると考えています。
そのためには現在地を示す指標を何かしらの形でアウトプットしてもらいたいと考えています。その1つの手段としてテックブログを用意しているので利用をしてもらえると嬉しいです。
2つ目は「炎上するのが怖い」ですが、これも炎上する要所を知っておくことである程度防止できます。
前提条件がしっかりと書かれている
事実と意見を明確に区別する
主語を大きくしない（煽らない）
わからないことを「わからない」と書く
自分以外のメンバーがレビューする
テックブログが炎上する多くの理由はコンテキストのミスマッチです。
テックブログの大きなメリットは個人ブログと異なり、社内の同僚やチームメンバーにレビューをもらえることでしょう。
個人ブログのほうが気軽さはありますが、ぼくはより炎上がしにくいのはテックブログではないかと考えています。
ですので、ブログを書いたことがないメンバーにこそテックブログにチャレンジしてほしいです。
では、モチベーションがあるメンバーの不確実性を減らせばテックブログは書かれるようになるのでしょうか？
多くの場合、それだけでは「テックブログが書ける」メンバーは増えないでしょう。
どうすれば「書くことができる」のか？
「テックブログを書く」といった際にいくつかのステップに分類できることに気づきました。
情報収集（インプット）
情報整理（オーガナイズ）
情報構造（ストラクチャー）
情報発信（アウトプット）
評価（フィードバック・アウトカム）
技術広報として執筆者にさまざまなアプローチをしてきましたが一番効果があったのは「2. 情報整理」と「3. 情報構造化」でした。
書き上げる際に「頭の中にある情報を吐き出し切ることができず」、吐き出し切れないので「情報の幅や深さが足りない」ため、書いているうちに「コレジャナイ」感を感じて筆を止めてしまう、あるいはモチベーションが消失してしまうというケースを何度も目にしてきました。
まず「書くことができる」という状態を定義します。
ここでいう「書くことができる」とは……
自らテーマと対象読者を定め、読者にとってのゴールを設定できる
セルフレビューをおこなったときに記事のゴールを達成しているかをふりかえることができる
メンバーにレビュー依頼をするとき、どこに不安を感じているか説明できる
究極的に言うならば「読者にとってのゴール」がなにか？を設定できれば、その他の項目は自ずと決まります。ゴールが明確であればあるほど、テックブログは書きやすくなります。
それはふりかえりをする起点が明確になるからです。いわゆるゴールデン・サークル理論のWhyに該当するものをどれだけ言語化できるかが「書くことができる」状態になる重要な鍵となります。
コレジャナイ感を感じたら考えの視点をズラしましょう。
執筆者や登壇者は話せる・書ける内容から絞り出そうとして迷子になるケースが多いです。もしそうなったら「自分がいま困っている情報はなにか？」「半年前、1年前の自分が困っていたが、いま困っていないことはなにか？」を考えるとよいです。なにかの軸を用意することで発散し続けるアイディアを収束させることができます。
おすすめはKJ法で付箋にアイディアを書き出し、グルーピングして思考を整理する方法です。
これらを意識し、記事が書けなくて困っているメンバーの壁打ち、相談を行った結果、マネーフォワードではぼくが技術広報になってから執筆者数が毎年ほぼ倍増ペースになっています。
技術広報就任前年の執筆者数が27名、技術広報就任1年目が57名、2年目が12月4日現在で75名と増え続け、記事投稿に関しても月平均の記事投稿数が就任前年が平均2記事でしたが、就任後は1年目、2年目ともに月平均8記事を超えています。
この状態になるとビジョナリー・カンパニーの弾み車の法則のように好循環が周りだし、自走する組織へと変化していきます。
このような結果に至ったのは「書くためのWhy」ではなく、「書けない理由のWhy」がなにかを考え、書くための理由ではなく、書くことを阻害している原因の調査と対処を行ったからだと考えます。
また、印象ではなく実際のデータを元に仮説検証をおこない実践してきたことも大きいでしょう。
マネーフォワードの場合は、「エンジニアが自信を持つ」ことが弾み車の原動力になると考えました。
そういった取り組みを少しづつ積み重ねたことでテックブログだけではなく様々なイベントやカンファレンスに登壇してくれるメンバー、プロポーザルを提出してくれるメンバーが増えていますし、他社からイベント共催のお誘いを受ける件数も増え続けています。
特にスポンサードしているカンファレンスのプロポーザル提出数は前年と比較して1.5倍〜2倍ほどに上昇しました。
プロポーザル採択率もそれに比例して上がっており、感覚だけでなく数値上の成果も上がっています。
データドリブン思考で組織のプロダクトオーナーとしてふるまう
実際の開発でもそうですが、ユーザーが開発の課題に対する答えを持っていることはまれです。
重要なことはユーザーの声を聞き、データを元に洞察することで課題を明らかにすることです。
ここでいうユーザとは潜在的にブログを書いてもよいと考えるメンバーを指します。
課題が明らかになればあとは仮説を立て、検証するMVP（Minimum Variable Product）を繰り返していけば自ずと課題に対する解像度が高まっていきます。
「組織の情報発信を強化する」というプロダクトのオーナーとして、あるいはミニVPoE/CTOとしてデータドリブン思考で課題を1つ1つ分析し一番効果のあるものから潰していきましょう。
手が出しやすいものから始めると「労多くして功少なし」になり、疲弊してしまうので注意しましょう！（ぼくはこれをやりがちです。）
「テックブログに書くネタがない」に対する結論
「テックブログに書くネタがない」なんて事はそうそうない
当初の課題に対するぼくの答えとしてはやはり「YES」です。
さまざまなシチュエーションがあるので一概に言えないかもしれませんが書けないのではなく、書くための不確実性を減らせていないのだと思います。
マネーフォワードでは「テックブログが書けない」不確実性がどこにあるのかデータを元に分析し「テックブログが書ける」状態に徐々に変化してきました。
ここまで読んだ方はぜひ「書けない"本当の理由"」を見つけ出し、自分が「書けない"本当の理由"」の不確実性がなにか定義できないか考えてみてください。本記事がそのきっかけになると嬉しいです。
多くの場合、書くことができない"本当の理由"は複合的な要因で構成されています。
できることの範囲広げることで、小さく情報を重ねていきましょう。
開発もブログもその本質は同じです。価値をどのように定義し、ユーザーに届けるかが重要です。
いきなりビッグバンリリースをしようとすると不安に駆られますが、不安の原因を分析し、考察と仮説・検証すれば書く前に感じている不安のほとんどは解消されます。
まとめ
テックブログを書く側の視点からみた書けない理由をマネーフォワードのデータを元に分析、考察してみました。
テックブログは会社の技術資産（ストック）の1つでしかないので、個人的には異なる形での貢献でも構わないと思います。
OSSにPRを出す、イベントに登壇する、カンファレンス運営スタッフとして界隈に貢献する、社内メンターを務めるなど様々な形のアウトプットの仕方があると考えています。
ブログを書くことだけがアウトプットではありませんが、ブログは非常に再利用性が高く個人的におすすめなので、なんとなく苦手意識を持って書いていない方がいたらこの記事を読んで挑戦してもらえればと思います。
Happy Your Blogging!
[余談]書く時間に関する著者の見解
テックブログを書くためにはある程度まとまった時間が必要です。
これは「考えをまとめる」、「調査・検証する」、「書き出す」の全工程において時間がある程度必要になるためです。おそらくこの理由はほぼ全ての人にとって自明だと思います。
そのため、多少の時間的余裕がある人や組織でないと厳しいです。
毎日始発終電で帰るような生活をしている人にブログを書けといっても1日の時間は24時間しかなく、衣食住優先するので難しいでしょう。
時間がないとはそういったレベルの人を指します。
テレビや漫画、アニメなど趣味の活動をされている方はその限りではありません、それは単に優先順位の取捨選択の結果、時間が足りないだけです。どこかの時間を削るかブログを書くのを諦めましょう。
ですので、サバイバルモードな人や組織の場合はまずその状態から抜け出す方を優先すべきでしょう。
今月はできなくても四半期、半年のスパンで書けていればいいと考えるといいでしょう。
ですが、半年立っても自分、もしくは所属するチームや組織がブログを書けない状態になっているならそれはチームが疲弊している兆候です。
すぐに何かしらの手を打てないか検討しましょう。
また、そのような状態で「テックブログを書いてほしい」と頼んでも、さらに負荷を積み上げることになり、書いてもらったあとに退職されるということになりかねません。やってほしいことの対価としてはあまりにも高すぎます。
書く時間は書く優先順位をあげないと絶対に生まれません。
とはいえ、いきなり書け！と言われても困ると思うので、なにから始めればいいかわからないという方へ向けた個人的なおすすめのTipsを紹介します。
人事評価時期にリンクさせる形で「（四半期｜半年｜1年）に1回ブログを書く」と評価査定の計画に組み込む
Dailyで困ったことや調査したことのフロー情報を書き留める
書き留めた日報のサマリーをWeekly（もしくはMonthly）でおこない、KJ法などのフレームワークを用いてグルーピングをおこなう
グルーピングしたものをチームメンバーや同期、上司にみてもらいフィードバックを得る
目標の期限内にブログが達成できそうかふりかえる
これら全てをするのが難しいという方はまず「始業直後か終業直前に30分予定入れて必ずなにか書く」と決めて毎日（少なくとも平日は）やりきることから始めると良いでしょう。
書き出す内容はアウトラインでも書けそうな技術ネタのメモでも社内ドキュメントでも今日（もしくは昨日）調べたことのURLリストでもOKです。
人間の脳内はやったことに対して優先順位の棚卸しをおこないます。
つまり、アクションを起こさない活動の優先順位はずっと停滞するか下がり続けます。なぜならアクションしないことで現状困っていないからです。
ですので、まず脳内でモヤモヤしている状態から書き出すというアクションを行うことで書く行為の優先順位をあげましょう。
プロダクト開発にもいえますが、「ある日突然時間が生まれてシステムリプレイスする余裕が生まれる」ことは基本ありえません。
やると決めて手を動かすから結果として、いま行っている他のタスクの時間を調整したり、時間が圧縮できないか検討し、その先に書く時間が生まれます。
ブログもタスクも時間管理の仕方は同じなのでまず15分〜30分「書く」という行為を毎日のルーティンに組み込みましょう。