はじめに

TIG DXユニットの真野です。フューチャー技術ブログの運営の1人です。未来報を運営している岡田さんなどと一緒に、気持ちは草の根活動で外部発信に携わっています。

IT企業の技術ブログ運営は、ある一定の質をキープしながらも、投稿頻度を高め・それを継続することが求められ、周囲の期待値もあるので中々気を抜けない仕事だと思います。単発ならともかく、継続することは忍耐が必要なので特に大変です。運営していてこれはナレッジだなと感じたことをまとめていきます。

2020/09/08 続編を公開しました: フューチャー技術ブログで行っている連載企画が良いよって話

技術ブログの大変なところ≒記事ネタを探すところ

熱心な寄稿者が複数いて、運営からの声掛け無しで記事が集まるのであれば非常に楽ですが、たいていの組織やチームはそうでないと思います。また、本業は記事を書くことではなく、自社プロダクトの開発やシステム開発（当社だとITコンサルティングサービス）であるため、そちらが忙しい場合は、当然技術ブログへの優先度がどうしても下がってしまいます。また、余力があってもそれぞれのプライベートや、OSS、競技プログラミング、個人サービス開発、資格取得、執筆などなど、興味がバラバラであって必ずしも執筆に関心があるとは限りません。

そこでブログ運営はブログ記事の種を探すことになると思います。ブログ運営者が全エンジニアの動きを補足することは不可能なので、通常は「何かネタがあったら書いてください～」といった依頼にとどまることが限界な気がします。今回はこの辺りの声掛けも含めていくつかやって良かった工夫点がまとまってきたので説明してきます。

フューチャー技術ブログは開設して4年位経過しますが、最初は月2,3ペースだったのが、最近は週2,3ペース（多いときは週5もザラ）に上がってきています。2019年の4月くらいから体制が変わって明らかに改善したのでここの話もします。

チームごとの当番制はアンチパターン

ブログ開設2年ほどはIT技術部署ごとにローテーションを回す制度にしていました。これの理由ですが、ブログ運営者的にはどのそれぞれのチームレベルはともかく個人レベル何をしているかサッパリ分かっていなかったということと、仮に入稿スケジュールを守らなかった人に対して、ブログ運営者が業務調整するとか、マイナス評価にするとかはできないので、それだったらそのリーダー経由にしたほうが楽なんじゃないか？っていう割とネガティブな理由からです。

これはこれで最低限上手く回ったのですが、想定していた以上の投稿頻度にはなりませんでした。また、途中で組織変更が発生したのですが、ブログ運営はそれに追随できず途中から形骸化しました。

このため、途中からはチームローテーションを無くして、ブログ運営者が直接メンバーに声を書けて記事を書きなぐるスタイルに変更しました。チームごとの当番制などという概念も消えました。

これはとても上手く回りました。体制変更だけが理由ではなく色々幸運が重なった結果ですが説明していきます。

2年間で会社のAdvent Calendarなどを複数回こなし、記事を書くことに慣れたメンバーが増えたこと
200名ほど参加している社内チャットグループができて、情報収集がしやすくなったこと
2年ほど部署単位でローテーションを回したことである程度各人の技術を志向を理解していたので、運営者が読みたいなと思った技術テーマについて各人にダイレクトにお願いできたこと

本当に読みたい記事に対してはだれかを経由せず直接熱意を伝えた方が良いなと思ってます。また、当番制はブログを書くのがつまらない仕事になってしまうのがNGポイントだなと思います。有志で何かをやる分には良いですが、義務感が生じた瞬間にやる気がなくなるアレですね。当番制でチームリーダーがブログ化を指示する強制力が自発的なブログ投稿の気持ちを抑制していたかも？と今となっては思います。

フューチャーの技術ブログを取り巻く制度

ブログを通した外部発信自体を経営が価値を認めてくれており、また**やることをやっていれば他は好きにすれば良いんじゃない？ **というフューチャーの価値観が前提としてあります。

コンサル業界ではお客様に直接的に貢献する活動が優先されることが常識になってますが、フューチャーでの技術ブログの執筆活動はマーケティング活動や自己研鑽活動の一貫として社内に認知されており、大事な業務の1つとして扱わされています。社内用語で言うとチャージコードがちゃんと準備されています。これは新卒、キャリア採用面接とか、新人研修とか、OJTとかなどと並ぶ重要な業務として、現場のコンサルタントも認識できるので、非常に良いなと思います。

「リーダーによってはブログ執筆時間を嫌がるんじゃない？」とたまに外部の人に聞かれますが、ぶっちゃけあると思います。チームリーダーのポリシーによっては、チーム内Wikiに非常に力を入れていたりもします。また、そもそもやろうとしていることがチャレンジャブルなゆえに質・量ともに難しい案件が多いので、ブログ書くよりチームのタスクを消化してくれよ。苦笑って思っている人も（直接言われたことは一度も無いですが）多いと思います。

とは言え、先ほど言ったとおりやることをやっていれば（宣言してリーダーと合意したアウトプットを出せば）割と後は自由にやって良いフューチャーの文化があるのか、あまりとやかく言われません。

投稿ネタの発見と予約の確定

前の章で少し触れましたが、社内チャットはネタの宝庫だなと思います。様々な社内チャットを徘徊しましょう。もしチャットがなければ導入しましょう。Slackの無料プランであれば今すぐ有料プランに加入して、ログが消えないようにしましょう。冗談のようですが半分以上は本気です。

チャット上で「今○○が理解できずN時間溶かしている」→「解決した！」といったコメントがあればチャンスです。すかさずその知見をブログに残しませんか？とささやきましょう。鉄はアツいうちが良いです。解決して何かしらの脳内麻薬がでている状態ですので、「ぜひやりましょう！」と回答してくれると思います。このときのコツですが、そこで終わりではなく「では再来月の○日はどうでしょう？備忘に会議通知を送っておきますね」と続けます。これが大事です。期間は1.5~2ヶ月がちょうどよいです。1ヶ月だと書く側の気持ち的にはすぐだなって思ってしまいます。2ヶ月より長いと、内容を忘れてしまう気がします。また、依頼自体も時間が経過すると、ハマった本人としても大したことが無いネタだわと脳内変換してしまうので、まさにハマって解決したよ！という瞬間を狙っていくのが良いです。

フューチャーだと、Slack以外にも「Go相談室」「クラウドアーキナレッジ共有会」「💡電子工作部」「☁フロントエンド相談室」「AWS-APNアクティビティ」「OCV(競技プログラミング部)」など多くのGoogle Hangoutチャットルームが存在します。運営的にはなるべく多くのチャネルに入れるくらい友人関係や興味を広げておくとよいでしょう。実際に、GoCloudの連載を始めとするいくつかの連載記事は、「Go相談室」で盛り上がって開始したり、GCP連載は「クラウドアーキナレッジ共有会」でだれかのGCPを勉強したいというちょっとしたコメントがキッカケです。

Go相談室の例です。50人くらい参加していて割とアクティブに相談が行われています。

だれかの疑問はブログネタの種ですし、初心者の基本的な質問も歓迎する雰囲気を出すのが重要ですよね。

こっちは「電子工作部」という公認社内サークルの様子です。

ミニ四駆も最高ですが、AWS DeepRacerを買いたいですが技適が..というわけで、無いものは作る精神でHWから設計。第1回社内ロボコン開催記-ライントレーサー編- という記事に繋げていました。執筆者の勝村さんはチャット画像の筒井さんとともに電子工作部を支えるエース達ですが、実はAIの方が専門という人生2週目かな？って感じです。筒井さんは他にもソフトとハードの垣根を越えろ - IoTハードウェアの開発をソフト屋視点で解説しますという記事で、IoTで獣害問題に取り組んだ記事も書いており、強いです。

抽出キーワードを学ぶ

毎日のようにチャットを徘徊する余裕が無いという方が大半だと思うので、チャットを検索しましょう。これは組織風土やチームの文化に完全に依存しますが、例えば、「学び」「知見」「ナレッジ」などのキーワードで検索してみると、何かしら新しい発見をしたメンバーの生の声が知れると思います。その内容が良いなと思ったらブログ執筆依頼をしてみると良いかなと思います。

Slackであれば、リアクションのスタンプ（Add reaction）を持つコメントも検索できます。例えば「知見」という絵文字が :chiken で使えるのであれば、 has::chiken: で検索できます。

中々記事が集まらない場合は、こういったスタンプトリガーに記事候補を見繕うことも有効だなと思います。

プロジェクト独自の成果物にチャンスあり

フューチャーは社内にいるとやることをやっていれば自由度が高く、ベンチャー感がありますが法的には大企業に分類されています。背景にはそういうリッチな開発リソースがあるからか、社内には生産性を高めるために多くの仕組み（ライブラリ、設計ツール、テストツール、方法論、コンポーネント、etc）が存在します。その中でもPJで独自に作られる標準規約などはネタの宝庫だなと思います。

チームで機能設計するためのPlantUML標準化やスキーマファースト開発のためのOpenAPI（Swagger）設計規約といった、よくそれをまとめる工数があったな..!!と自分でも思うようなアウトプットが、ある1つのPJのために作成されたりします。こういったものでもちろん知財的に問題ないものは、ドンドン汎化して外部公開できないか交渉すると良いかなと思います。TypeScript教育用コンテンツ公開のお知らせの記事は逆に最初から外部公開を視野に入れて作成されたようです。色々な流れがありますね。

こんなの需要ないでしょ？と思うくらいの方が、出してみると意外と反応があり面白いです。実はこういう規約が作られた事自体、通の人間しか知らずにそのまま埋もれることも多いです。社内に浸透させるためには、逆説的に社外に一般公開して、Googleのインデックスに引っかかるようにしたほうが、結果的には社内の別のPJから「これ良い規約だからそのままうちでも流用したよ」といった声も増えた実感があります。

社内イベントはチャンス

フューチャーは、個人プレゼン決勝戦や、年末のBPYなどなど社内イベントが盛りだくさんです。特にこういったある程度競い合うイベントに登壇してくる人は、もれなく各チームのエース級が出てくるので、チャンスの塊感があります。

ちょっとでもこの人の話の続きを聞きたい、と思ったらブログ化の依頼をしましょう。アツいうちにチャットでDMを送りましょう。大体優しく答えてくれるので、間髪入れず会議通知を入れて既成事実化しましょう。

他にも、有志の勉強会や輪読会などチャンスは多いです。

社内技術書輪読会とSite Reliability Engineering の記事はたまたまオライリー本を読んでいたグループに混ざって書いてもらいましたが、書き出すと色々ナレッジがあって良い知見を世に出せた気がします。また、Goの標準ライブラリのコードリーディングのすすめも同様に有志の勉強会の様子を記事化してもらったものです。個人的には、完走してからではなく、中間の段階で記事を書くと、その後の社内の募集時も楽になる効果があるのでオススメです。

テーマを決めて募集する

「何か書いて」という自由度の高い依頼ベースだと中々記事が集まりにくいです。そのため何かしらのテーマを決めると経験上良いです。もし、テーマ募集でも集まらない場合は、テーマに興味がある人が少ないかしっくり来ていないことが多いのかなと思います。フューチャー技術ブログだと、半分くらいが企画連載モノが締めているくらい、重要な取り組みです。

この辺りの内容は、”フューチャー技術ブログで行っている連載企画が良いよって話”の記事を近々公開して、そちらに詳しく書きますので、ぜひ公開後に参考にしてみてください。

アルバイトerやインターン生に就職活動ネタとして書いてもらう

フューチャーでは多くのアルバイトerやインターン生を受け入れています。中にはNDA（秘密保持契約書）を結んで業務してもらう方もいるそうですが、それ以外のOSS開発などに携わってもらっているメンバーには、就職活動でも使えるようにドンドン記事を書いてもらっています。アルバイトやインターンの業務内容の生の声を外部に発信できて、多分フューチャー的にもハッピー、きっと世の中にある幸せの総量を増やせます。

最初はUnity未経験者がHoloLensアプリの開発をしてみたの澤田さん（その後入社を決めてくれた）が1つ目でこれは3年前くらいの事例です。最近だと日本製HeadlessCMSのmicroCMSを触ってみたの三村さんなど、様々です。もちろんQiitaなど別のブログ媒体にも、業務で得たプログラミングなど汎用的な内容はドンドン書くように背中をおしています。

Advent Calendar時期の運営

フューチャー技術ブログの出自は、Qiita Organizationにあるため、当然のようにQiitaのAdvent Calendarに毎年参加しています。

この12月は技術ブログ界隈では、豊作の月と呼ばれ(要出典)、言い換えればレッドオーシャンです。また社員の多くが様々なカレンダーに参戦していたり、そもそも12月はBPYや評価時期と重なり当社の繁忙期です。そのためこの時期にはあまり活動をしないように心がけています。フューチャーとしてもAdvent Calendarに参加するけど、その記事はQiita上に直接書いてもらうことを基本としています。Qiita記事を書いたことがない人にもカジュアルに記事を書いてもらうことを期待もしています。

Advent Calendarの前月11月は凪の月と呼ばれ（要出典)、気持ち技術ブログ界での投稿が減るので、逆張りで11月に投稿スケジュールを寄せる工夫をしています。

依頼のコツ

「とりあえず書いてください」というテイストだと、頼まれた側も何を書いて良いか分からないので、なるべく具体的に○○にハマった内容について書いてくださいとか、チームのリポジトリ構造についての工夫について書いてくださいとか、細かくリクエストを出したほうが経験的に反応は良かったです。

リモートワークを促進させるDaily Stand-up Meetingの記事は、あるチームが毎日15分くらいのショート朝会をしている風景を見て（まだコロナが無かった頃です）、聞いてみると色々作戦があり面白そうだったので記事化を依頼しました。これを依頼したときは、「良いテーマを見つけてくれてありがとうございます！」と逆に感謝され新鮮な気持ちになりました。ブログを書きたいけどネタをうまく思いつけない人もいて、客観的な立場からネタを引き出してあげる能力も大事なのかもな、と思った記憶があります。もしかするとネタを見つけるのも一種の創造性が求められる仕事かもしれません。

企業IT技術ブログですが、純粋なプログラミングの内容以外にも、実践Drawioのようなツールの使い方など、幅はかなり広いと思います。自分が知らなくて勉強になったことは、常に世に公開して貢献できないか教えてくれた人に相談すると良いと思います。

ベテランを味方に付ける

かなりのステレオタイプが入っているかも知れませんが、フューチャー中で30中盤を超えてテクノロジーに人生を掛けている勢は控えめにいってかなり強いです。生存バイアスかも知れません。彼らはおそらく技術ブログの記事レベルを底上げしてくれるその道の専門家集団だと思いますが、中には全く技術発信に興味がない人がいます。どのように依頼すべきでしょうか？書いて欲しいテーマについて具体的にお願いすればよいのでしょうか？スキルも実績も文句ないので、ぜひ1本だけでも..1本だけでも書いて欲しいと思う気持ちはあります。

残念ながら、経験上ですがこの手の興味の無いベテラン勢に執筆を依頼しても一度も成功した試しが無いのです。押すだけ無駄です。その労力があるなら別のところに注いだ方がお互い幸せです。ちょっとでも嫌そうなオーラを感じたら即時撤退しましょう。多分、大人なだけにマイルドに包んでいるだけで本当に嫌がっています。ベテランになるとIT技術以外に仕事の進め方が上手くなり、優先度付けもレベルが高い人が多いです。必要になったら本人から何か書こうか？（というよりこの○○の記事を出したいけど良いかな？って感じです）って言ってくれるので、のんびり待ちましょう。繰り返しますがその時が来ない限り、頼み込んでも書いてくれることはほぼ無いです。逆に時が来れば尖った記事を出してくれます。まるで大自然、荒ぶる神のようですね。

また、こういった気質の人は、本当に一匹狼気質もいますが、自分の知見を世界に公開するよりどちらかと言えば目の前のメンバー育成に興味を持っている気がします。もしメンバー育成に興味を持っている人であれば、メンバーサイドに記事を書けそうな人がいないか紹介もらったほうが良いでしょう。このへんはエンジニアマネージャーが良い紹介役といったところと共通していると思います。

もちろん、中には執筆に協力的な方もいらっしゃるので、そういう諸先輩には全力でオネダリしていきましょう。

入稿が遅れた時

もし、入稿が遅れるという連絡があった時ですが、基本的に業務優先なので気にしないです。大体1週間くらいスケジュールをズラしたいと言われますが、そんなに余力がない中で1週間後だと、アクシデントが発生した時にブラック企業モードに陥る恐れがあります。本当にあとちょっとだったら良いですが、1週間と言わず1ヶ月ズラしてホワイト化しようと意識しています。

もし、連絡が無くてスルーしているときですが、チャットのDMでチラってコメントを送っています。大体悪気は無いので、リスケするかどうか確認して、これは1.5ヶ月くらい後ろにしています。あまり1人に頼る公開スケジュールを立てると、崩壊した時にリスクが大きく精神的にもよろしくないです。そのため、大体3人くらいの冗長性を持ってスケジュールを計画すると良いかなと思います。

🚩繰り返されるリスケの図

大先輩の杉江さんを晒したようですが、SQL実行時のブルームフィルタ(Bloom Filter)アルゴリズムという記事を過去に書いていて、こういった感じの大作を書くタイプゆえに、執筆に時間がかかるという理由があります。他にもプライベートのアレコレがあったり個人の事情は様々ゆえ、とてもじゃないですが強権的に記事を書いて！とは言えません。

原稿について

レビューですが運営が全ての技術に精通しているわけではないので（憧れますが）、基本的に文章チェック以外は有識者にレビューを依頼します。この時、レビューが得意な人とそうでない人はどうしても存在するので、信頼できるレビュアーは自分の中で持っておきましょう。だれに聞くかは非常に大事です。

原稿でよく追記のお願いするポイントがいくつかあります。まず、一言でも自己紹介を書いて欲しいこと（執筆者のブランディングに繋げたい）や、記事内で別の記事を紹介してリンクを貼ってもらうことです。後者はブログ内の回遊率を上げたい取り組みですが、Googleアナリティクスを見るとあまりうまく行ってはいないようです。

個人的に辛い系の原稿レビューは、テキストアナリティクスシンポジウム開催報告&ACL2019参加報告を始めとしたデータサイエンス系の記事です。フューチャーのAIチームの専門性が高すぎていつも涙目になっています。セクショナリズムは敵ですが、餅は餅屋でもあるので、１人で抱え込みすぎずチーム内レビューをしてもらうなど状況に応じて対応を変えています。

FAQを作る

技術ブログで章立てなどにお作法が無いのか？は非常によく聞かれるポイントです。その他注意事項やよく聞かれるポイントがあればFAQという形でまとめましょう。
フューチャー技術ブログだと、GSuiteが導入されているので、だれでも見れる環境にDocumentを配備しています。共同編集もできるためオススメです。

公開後の宣伝

記事の公開ですが、宣伝は運営者自らが行いましょう。公開だけして自社や外部向けの告知は、執筆者本人に依頼して任せるのはNGです。もちろん執筆者か自発的に宣伝してくれるのはWelcomeです。理由はいくつかあります。

執筆者が自分で自分の記事を自チームに宣伝するのは恥ずかしがる人もいる（書いたぜアピールが強くなりすぎる）
特に初投稿の場合、リアクションに緊張する（反応がゼロだったらどうしようとか、反論が来たらどうしようとか）
純粋に宣伝が慣れていないので、時間がかかる。だったら運営がやったほうが依頼するやり取りが減る分、効率的

面倒ですがなるべく多くのチャネル（社内の複数のチャットグループ、複数のSNSなど）に投稿しましょう。

🚩200人超えの社内チャットに宣伝する図

🚩Twitterに宣伝している図

Goのパッケージ構成で悩んでいる人にオススメの記事を公開しました✨ / あなたのGoアプリ/ライブラリのパッケージ構成もっとシンプルでよくない？ https://t.co/Mi8nvhQpfz
— フューチャー技術ブログ🥢 (@future_techblog) May 28, 2020

公開後に反応があった場合

良い内容であればドンドン広く共有したほうが良いです。Twitterで「○○に関して良い記事だった」といった具体的であればあるほど、ドンドン社内でシェアしましょう。繰り返すと記事を書くことに対して、社内がポジティブに捉えてくれるようになります。

バズった時は礼賛する

はてなブックマークなどのホットエントリーに入った場合や大量にRTされた場合には、ドンドン画像ごと社内にシェアしています。この時、書いた本人を含めて「おめでとうございます！ 🎉」と礼賛することが非常に大事だなと思います。

🚩少しでもバズった気配があればすかさずアピールする図

こういった国内IT業界を技術発信で貢献したりリードする人が社内にいて一緒に仕事をできるということは、若手にとってもベテランにとっても嬉しいことですし、さらに記事を公開することに対してポジティブに捉えてくれるようになります。とにかく入社1年以内の若手の人からもブログ活動に興味を持ってもらえるくらい、ドンドン新規の執筆者候補を作ることが、継続したブログ運営に繋がると思います。分かりやすい成果が出た場合は書いた人を称える気持ちでシェアしていきましょう。

1年ほど繰り返すと

こういった取り組みを1年ほど繰り返すと、気がつけばチームSlackでも、多くの人が何か事あるたびに、「これはブログネタ」と言ってくれるようになりました。

そうするとさらに外部公開を意識したビジネス的、技術的なチャレンジが取りやすい文化が醸造されてきた気がします。上の画像の中のコメントにも書いていますが、チャレンジした結果だめだった場合でも、「ブログで供養すれば良いじゃない」といった形です。失敗がダメというよりその後の改善や、失敗するなら早く失敗するための工夫をしようよとマインドも変わってきます。良いサイクルですね。

今後の施策

いくつか追加でやりたいテーマがありますが、気張りすぎずやれる範囲でって気持ちです。

フューチャー社外の人にも記事を書いてもらう
1の延長ですが、社外の人と技術テーマで話すインタビュー記事を作る
YouTubeやポッドキャストで、技術談義をして公開する
HACK TO THE FUTUREとのコラボ
未来報とコラボ記事

直近は増えてきている連載企画を社内に定着するよう、色々発信していこうと思っています。

マーケティングや質と量の論議

コンテンツマーケティングを囓ったことがある人によく言われることですが、読者のペルソナを作ってSEOWordを気にして…etc. など色々言ってくれる人もいますが、こういったことは全く手が回っていません。今は面白いと思ったネタをなるべく社内から抽出して生み出そうという意識です。本当は導線分析などをしたほうが良いよね、とはECサイトの構築など経験豊富な星さんとたまに話しています。

コンテンツでいうと、まずは投稿量を増やそうと思っています。フューチャー技術ブログは200記事くらいでまだ道半ばです。心が折れない限り500記事くらいは継続したいと思います。量を増やすとSNSでも注目される記事が増えてきました。質はtypoや日本語の言い回しなどはチェックしますが、技術レベルはあまり気にしていません。というのも、ブログのコンセプトとして、初心者～習熟者まで楽しめるメディアにしたいというのがあるからです（そういう意味だと、対象読者は学生さん～社会人の若手エンジニアです）。まずは500記事くらいまではこのまま勢いで走り抜きたいと思っています。その中で順次足りないところでかつ面白いアイデアが浮かんだら実行していくと言った考えです。

こういう意見は流すに限る、よく言われがちなこと

2点だけ、経験上なぜか年次が上の人から言われがちなアドバイスがあるので注意喚起します。

「記事を書くメリットが欲しい」
たまに今でも言われます。インセンティブを作ったほう良いんじゃない？と同義です。実は過去、この意見に従い実際に社内で使えるマイルポイントみたいなのを面倒な調整をして付与できるようにしました。しかし、実際にメリットがあってもそういった人は一人も書かなかったことを、声を大にして残しておきます。本当にだれも書かなかったし、むしろ今まで書いてくれた人が時給換算で〇〇円か、とテンションが下がっていたのが印象的です。

そもそも物理的な報奨は原資に限りがあるのでやめたほうが良いです。文化的な報奨（つまり礼賛すること）に移行したほうが原資が無限大なので、こちらの仕組みを上手く作ることにフォーカスしましょう。

「運営を持ち回り制にしたほうが良いのでは？」
ブログ開設期に何度か言われました。運営者に負荷がかかりすぎないようにしたいというマネジメント的な意図だと思います。しかし、持ち回り制は個人的に悪魔の囁きだと思っています。なぜならブログの運営タスクをこなすことは、最初に立ち上げた人以外にメリットが少なく、最初は有志で回せても、代を経るごとにいつしかいつの間にか増えたタスクになりがちです。こういった開設時の思いが失われたタスクは、ある時、感謝とともに別れを告げられることになるでしょう。また、そうでなくても持ち回り制だと運営のナレッジが蓄積されません。本当に改善の余地が無く陳腐化したタスク（例が適切かわからないですが経費申請とか）であれば別ですが、創意工夫の余地が多分にあるチームのエンジニア文化を高めて外部に上手く発信するブログ運営という役割は、まだまだ熱量のある有志で運営したほうが良いと思います。

まとめ

社内チャットなどで勉強になったり独特だなと思ったことを見つける
書いてくれそうな人に頼んで、会議通知を送る
入稿が遅れても気にしない。承諾してくれただけで協力者として感謝しかない

＞フューチャーの皆さん

企業ブログ運営もその位置づけをどう捉えるかによって、創造的だし面白いし学びも多いと思います。興味がある方はぜひ一緒に盛り上げていきましょう。運営スタッフ募集しています。

フューチャー技術ブログの運営で心がけていること