記事は増えたのに、成功を説明できない
「この技術ブログは、半年後に何が変わっていれば成功ですか？」
新しく自社の技術ブログを任された担当者は、その仕事を軽く扱っていたわけではありません。記事を書ける社内のエンジニアを探し、本業の工数を調整してもらいながら、原稿を待ちました。誤りが書き手の名前に残らないよう、公開前の事実確認は自分で引き受けていました。週の更新本数を落とさないことを、自分の仕事だと考えていました。
この仕事の重要性は、誰も否定しませんでした。会議では「技術広報は大事だ」と言われ、反対する人もいません。ただ、書く時間は誰の予定にも入っていませんでした。エンジニアにとってブログの執筆は、自分の判断を検索できる形で社外へ置く作業です。書き慣れていないうえ、公開後に誤りが見つかれば、名前と一緒に残ります。心理的なハードルが高く、本業の締切と並べれば優先順位は下がります。
だから担当者の仕事は、頼みごとの形になります。会社として大事だと合意された仕事の締切を、その仕事を後回しにするしかない忙しい相手へ、持っていくことになります。締切前に連絡すると、「今週は無理です」と返ってきます。次の書き手を探すたびに、別の断り文句が増えていきます。会議で公開本数を報告しても、質問は返りません。減った月だけ、理由を聞かれます。
担当者は、返す言葉を持っていませんでした。手を抜いた自覚がないからこそ、答えられませんでした。画面には、公開済みの記事と、伸びた更新本数のグラフが残っていました。「がんばりましたね」とは言われます。労いの言葉はもらえますが、その記事が何を変えたのかは誰も話題にしません。本数は増えたのに、自分で選んで作った手応えだけが薄いです。それでも、半年後に何が変わっていれば成功なのかを、自分の言葉で言えませんでした。
生成AIは、構成案、聞き取った内容の下書き、見出しの候補を短時間で作りました。書き手に白紙を渡さずに済み、仕事の速度はたしかに上がっていました。
しかし、記事を出す作業だけが先行していました。誰のどの状態を良くしたいのか、どこまでを扱うのか、どんな反応が返れば次のテーマを変えるのかは、関係者と言葉にできていません。速くなったのは、記事が出る工程だけでした。
丁寧にやろうとするほど、一記事ごとの作業に時間を使いました。書き手を探し、原稿を待ち、公開前に確かめます。相手の負担を増やしたくないので、「そもそも何のために出すのか」を持ち出す場は、いつも来週へ回りました。それを持ち出せば、忙しい相手の時間をさらに取ります。しかも、この仕事に意味があるのかという話にもなります。誰も答えを持っていないと分かっている問いを、煙たがられている側から差し出すのは難しいことです。約束を守る人で、他人の時間を尊重する人だからこそ、確かめる工程が後ろへ下がっていきます。
一段だけ一般の言葉へ上げます。増えたのは公開済みの記事という蓄積です。増えなかったのは、次の判断に使える根拠と、現場から話が入ってくる関係でした。後者への流入は、望ましい状態を決める会話、材料を受け取る時間、反応を次のテーマへ返す経路です。担当者には、その止まった流入に手をつける権限がありませんでした。
そして、報告に出てくるのは、増えた記事の側だけでした。測っているものと、保ちたいものが別です。しかも記事が誰に届いたかは遅れて分かり、その月の報告には間に合いません。測れるものが早く返り、保ちたいものが遅れて返るとき、評価は早い方へ寄ります。
こう言い直すと、同じ形が別の領域にも出ることが見えます。毎日ジムに通っているのに目標とした体重の変化が出ない人。毎朝30分の英語学習を半年続けたのにスコアが横ばいの人。転職を繰り返すのに、どの職場でも同じ不満を抱える人。どれも、数えられるもの（通った日数、学習時間、転職回数）は積み上がり、保ちたいもの（体組成、使える語彙、関係の結び方）は別の流入を待っています。
もちろん、単に量が足りないだけの場合もあります。ここで見たいのは、量を足しても変わらなかった側です。
これは能力や怠惰だけで説明できる問題ではありません。ここには、成果物の量だけでは見えない構造があります。
