クラウドエース 技術ブログの変遷 クラウドエース株式会社

自己紹介 Shohei Abe（阿部 正平） クラウドエース株式会社 主なミッション: 様々な業界における Google Cloud を主とする システムの設計・構築 保有資格: ● Google Cloud Certified Fellow ● Google Cloud Authorized Trainer ● Champion Innovators : Hybrid Multi-Cloud ● Google Cloud Partner Top Engineer (2022, 2023)

目次 ● クラウドエース技術ブログ黎明期 ● 運用上の問題点 ● コラム立ち上げと棲み分け ● 新技術ブログの立ち上げ ● 初期運用体制の問題点、改善案 ● 現在の運用、今後について

クラウドエース技術ブログ黎明期

クラウドエース技術ブログ黎明期 ● クラウドエースでは「apps-gcp」という 技術ブログを運営していました ● 運営の主な目的は「ビジネスとしての 企業ブランディング」「Google 専業ベン ダーとして No.1 をアピール」 ● apps-gcp は元々、2014 年頃から 吉積情報株式会社が主体で運営 ● クラウドエース発足から 1 年経過した 2017 年 11 月に移管

apps-gcp 移管以降の運営 2018 2019.4 2019.9 2020 ブログ更新頻度が低迷し始める … ブログ更新に関する施策を開始 ( Apps-RPG ) Apps-RPG 施策の終了を宣言 ほぼ更新されないブログに… 上期までの更新頻度は月 5 ～ 6 件(週 1 件以上)だったが、 下期から以降は徐々に頻度が下がり、月 1件も出ない状態に ゲーミフィケーションによるモチベーション向上施策 期間毎に記事更新目標があり、達成できるとボーナス 記事作成数と PV に応じてレベルが上がり、評価に繋がる仕組み 半年運用したが、更新頻度や PV向上に繋がらなかった

運用上の問題点

運営上の問題点① レビューフローの不透明性 メンバーに対して特に説明のないまま なんとなく運用開始 … レビューレスポンスの遅さ レビュアは CEO のみ (ワンオペ) 会社立ち上げ後は多忙の一途 レビューも曖昧なコメントばかり ご多忙だし……、と執筆者も催促や質問が できず、心理的安全性は低下 レビューフローを周知 レビュアを増員 apps-gcp で記事を何度も書いた エース級メンバー複数名 をアサイン (CEO はオブザーバに ) レビューコメントはなるべく丁寧に (心理的安全性をたいせつに) レビュー管理表で運用 　+ Slack 通知機能実装

運営上の問題点② メンバーも忙しくて記事が書けない エンジニア全員がそれなりに案件を受け持ち、 多忙な人が多く、 新技術検証や記事作成する時間がとれない レビュア増員しても レスポンスが改善しない レビュアがエース級メンバーで多忙で、以前ほど ではないが、レビューレスポンスは遅い Apps-RPG 施策を実施 作業時間確保には至らなかった 記事作成の時間確保や、一部のレビュー レスポンスはどうしようもなかった Apps-RPG 施策はあくまで個人のモチ ベーション向上施策に留まり、 根本的に案件作業による多忙までは改善 できなかった モチベーション向上や評価への反映を図る

運営上の問題点③ apps-gcp 固有の問題点 WordPress ベースのブログを使っていたが、 記事レビューでは Google Docs を使用 Google Docs → WordPress への変換は ツール化されておらず手作業 ただでさえ面倒な記事作成に余計な作業が …… 執筆者視点の作成しやすさに 関する改善に至らず WordPress のエディタを Markdown ベースで書けるようにする 試みを実施 ただし、当時の Google Docs は Markdown に変換する手段がなく、 結局手作業は必要

コラム立ち上げと棲み分け

クラウドエースコラム立ち上げと棲み分け ● apps-gcp はマーケティング・ビジネスの 目的もあり、廃れてしまうと問題 ● 2019年以降、ビジネス主眼の技術記事 はコーポレートサイトのコラムに掲載 ● コラム記事はマーケティングチーム主体 で作成・更新するため、エンジニアの案 件かけもち多忙問題は解決 ● apps-gcp の一部記事は、コラム側に転 載 https://www.cloud-ace.jp/column/

コラムによって解決した課題、しない課題 ● ビジネス・マーケティングとして重要な発信の作業時間・工数を保障 ● 技術的な深さよりも経営者・意志決定者に訴求する記事に専念 ○ 経営者・意志決定者は製品の 概要・概念・運用コスト といった部分を知りたい ○ (人にもよるが)エンジニアは技術的好奇心に基づくディープな記事を好む ● 一方で、エンジニア主体の技術ブログは廃れたまま

新技術ブログの立ち上げ

新技術ブログの立ち上げ ● 2022年8月、ついにエンジニア主体の 技術ブログ再スタート ○ 最初の記事: 会社のテックブログを Zenn で再始動します ● 技術ブログは Zenn で運用 ○ 他の候補としては Qiita Team, Medium, 独自サイト, etc… ○ 運営・運用コストが安く、 「GitHub + Markdown」で執筆でき、 エンジニアファーストであることを重視 https://zenn.dev/cloud_ace

新技術ブログの目的 クラウドエースコラムとは独立し、エンジニアが主体的に活動 エンジニア主体の活動を通し、ブランディングや宣伝・採用に繋がることを期待 エンジニアの自己学習機会の場として活用 アウトプット能力の向上 知識の共有 コミュニケーションの活性化

新技術ブログの運用 GitHub のリポジトリに Pull Request を 使って記事を作成し、レビュー依頼 （普段のプログラム開発と同じ手順） 記事の執筆方法 レビュー方法 システム開発部 TUM※ 陣が実施 ● GitHub の自動レビューアサイン機能でラウンドロビン対応 ● 1次レビューは 5 営業日以内を目標 ● レビュー観点を明確にしてルールを公開 ● GitHub Slack 通知を使ってレビュー漏れを検知 ※ユニット＝数人を 1つにした組織単位、一般的な会社の「係」「チーム」「グループ」くらいの規模 ※TUM＝テクニカルユニットマネージャー、ユニットの長 できるだけ執筆者のモチベーションを下げない工夫

新技術ブログの運用の風景 こんな感じで Markdown ファイルを Pull Request Markdown ファイルにレビューコメントし、執筆者が対応

新技術ブログの運営状況 (2022年度) Zennブログの記事公開件数 ● 2022/08: 3 件 ● 2022/09: 12 件 ● 2022/10: 10 件 ● 2022/11: 12件 ● 2022/12: 8 件 9 月以降は月平均 10 件程度の記事作成を維持しており、 リブートとしては十分な実績。

初期運用体制の問題点、改善案

初期運用体制の問題点、改善案 しかし、Zenn ブログの運営も、初めはいくつかの問題点がありました。 レビュアの決定がラウンドロビン方式のため、次のような問題が発生 ● レビュアが専門外の技術のレビュー依頼が来た場合の負担が大きい ● 執筆者と TUM が別ユニットの場合、執筆者とレビュア同士の連携が薄い ● 執筆者とレビュアの連携が薄いと、 互いに多忙なのかわからない 自分の記事がどれくらい注目されているか PV 等が公開されていない 運営内部の利用目的で当初から Google Analytics を有効化していたが、 PV 公開がアンダーマイニング効果 につながる可能性を危惧して公開していなかった

初期運用体制の改善案 問題点については以下のように改善しました！ ラウンドロビン方式を廃止、同じユニットのTUMにレビュー依頼 同じユニットの TUM とメンバー同士であれば、勤怠や業務状況の共有は容易 技術的な専門性も同じユニットであれば期待できる Looker でダッシュボードを公開 アンダーマイニング効果を危惧するより、情報を公開する方がよいという判断 モチベーションについては TUM がフォロー

現在の運用、今後について

現在の運用 GitHub を使った記事執筆の運用は維持 ● Pull Request ベースで記事を執筆 ● レビューは同じユニット内で TUM が対応、長期不在等はディビジョンマネージャー※がフォロー 【施策1】社内の Tech Blog Challenge でモチベーション向上 ● ディビジョン※間で記事作成数で競う ● あくまで補助的な施策 (アンダーマイニング効果にならない程度 ) 【施策2】月毎に CTO による「今月のイチオシブログ」紹介 ● 全体ミーティングで、独自の寸評でお褒めの言葉をもらえる ● 執筆のモチベーションに寄与 …… しているはず ※ディビジョン＝複数ユニットを1つにした組織単位、一般的な会社の「課」に相当 ※ディビジョンマネージャー＝「課長」に相当

現在の運用 施策を実施した 5 月以降、2 倍以上 執筆頻度！ ブログ記事公開数

今後について 直近取り組んでいきたいこと レビューの一部自動化 Zenn 特有のファイル名・ディレクトリのチェック、 Markdown ヘッダ、NG キーワードのチェック →レビュア負荷軽減 より多くのエンジニアに活躍の機会を 特に、新卒・若手に積極的にアウトプットしてもらいたい

今後について ● 今後も、運営していく中で様々な問題点・課題が発生 ○ 組織の規模にも応じて、適切な運営方法は変わるはず ● 企業のブログ運営として、「問題・課題を放置しない」姿勢が大切 ○ クラウドエースでは技術ブログの執筆を必達業務としていないため、 エンジニア個人のモチベーションを低下させない工夫が大事 ○ 業務指示・必達命令としてのブログ記事作成ではなく、 企業文化としてエンジニアの自律的なアウトプットを支援する方向で運営したい

今後について 結論: 運営がんばります

以上