お疲れさまです、5月に入社しました西田 (@k_bigwheel )です。先日、エス・エム・エスの開発組織ではZennのPublicationというサービスを導入しました。この記事では、導入の背景と導入開始から完了までの経緯を紹介したいと思います。
Zenn Publicationとは
Zenn Publicationとは、Zennというエンジニア向けナレッジ共有サービスの機能の一つです。
公式の紹介ページに「Zenn上にチームのメディアを開設しよう」とあるように、投稿した記事をPublicationという集合へ結びつけることで、企業や組織としての集まりを表現でき、ブランディングやPRに使えます。
導入活動まで
今回、Zenn Publicationの導入に動き始めたのは5/30で、導入が完了して使えるようになったのは7/18でした。なのでこの1.5ヶ月ほどで導入できたのですが、実はZenn Publicationを導入したい、導入しようという話は去年の3月時点ですでに持ち上がっていました。
社内のesaに複数のページが作られ、導入したい背景やメリデメがまとめられるなどしたのですが、このときは導入に至りませんでした。 その一つの要因は類似サービスとは異なるZenn Publicationの規約の特殊性(書いた記事がエンジニア自身に帰属するようになる)をどう扱うか、社内で整理しきれなかったことにあります。ただ、本質的に進まなかった理由は、Zenn Publicationの導入に大きなモチベーションを持つ人がいなかった点にあるかなと思います。エス・エム・エスではすでにこのテックブログや外部登壇などアウトプットの手段が複数用意されており、Zenn Publicationがなくとも代替の手段がありました。
導入活動開始
その約1年後の5/16に私(西田)が入社します。
私には技術Tipsをインターネット上へアウトプットすることに大きなモチベーションがありました。過去にQiitaや個人ブログへアウトプットしてきたこともありますし、業務中に得られた知見を社会へ還元することに強いモチベーションを持っていたためです。また、前職でそれを可能にするガイドライン整備をした経験もありました(業務中に書いたことを明記することで堂々と社会へ還元する)。
入社直後はこういったTipsを同僚に共有するいい機会なのですが、それをするプラットフォームがまだなく、一方で一年前にZenn Publicationの導入を検討していたことに気づきました。そこで、エス・エム・エスでも同様のガイドライン整備を開始することにしました(5/30)。
導入する上での課題
Zenn Publicationを導入するに当たっては、大きく分けて2つの課題がありました。それが次の2つです:
- 開発組織外との調整(法的リスクやPR文脈でのリスクの管理)
- 開発組織内での調整(既存のアウトプット方法との整合性)
開発組織外との調整(法的リスクやPR文脈でのリスクの管理)
1つ目はZenn Publicationで記事を書く上でのリスクのコントロールです。
Zenn Publicationに書いた記事は社内からだけでなく、インターネットに接続している誰からも閲覧できるため、場にそぐわない内容や誤った内容を投稿すると炎上するリスクがあります。また、前述の通りZenn Publicationは一般的なテックブログなどと異なり、記事が企業ではなく書いたエンジニア本人に帰属します。この辺りを会社のルールや方針とどうすり合わせるかという点も課題でした。
まず前者の広報文脈でのリスクについては、投稿前にエンジニア最低1名のレビューを挟むことで安全装置としました。また、書く内容を純粋に技術的なものに絞ることで会社の文化やルールなどが間違って伝わってしまうリスクをなくしました。ここはもっと安全側に倒そうとすればいくらでもできるのですが(毎回PRチームのレビューを挟むなど)、良い技術Tipsが迅速に世の中で公開されることに価値があること、純粋技術的な話であればリスクはかなり低いことなどを考慮して公開までのステップは必要最低限にしています。
後者の記事の帰属の問題については、時間をかけて準備を行い、リスクマネジメントを担当する部署に理解をしてもらった上でその導入に同意してもらいました。前提として、私含め導入関係者がZenn Publicationのコンセプトの
例えば企業のテックブログでは、多くの企業が更新を続けることに苦労しているようです。その大きな理由として、メンバーのモチベーションを維持することが難しいという点が挙げられると思います。
労力をかけて良い記事を書いても、それは会社の持ち物であり、自分ではコントロールがしづらいものです。たとえ内容の間違いに気づいても、修正することさえ難しいこともあります。
私たちは、記事は著者本人の持ち物であり、退職後も本人が管理できるべきだと考えています。
Publicationを脱退した著者は、Publicationに投稿した記事をそのまま残しておくことも、個人の記事に変更することもできます。どちらを選択しても、記事は著者の成果物としてプロフィールに残ります。
「それでは会社の資産とならない」と心配する経営者もいるかもしれませんが、この自由がメンバーが記事を書くことを促し、より会社のブランディングや採用につながるのではないかと考えています。
に共感していたことがあります。導入を主導した私自身にもこれが正しいという確信があったので、あとはちゃんと伝わる資料を用意してロジカルに説明すれば必ず同意してもらえると信じていました。実際、Slack上でのやり取りは数週間続いたものの、MTGとしては何度もすることなく1度で済んでいます。
※ ただし、ここについては利用規約の読み取りの経験や関連する法律理解が一定ある私が担当していたこともスムーズに進んだ要因だと思います。利用規約をどう解釈してどう対応するかはまったく知識のない者にとってはかなり難しい問題ですので、経験のない人がやる場合はもっと大変だと思ったほうがよいでしょう。
開発組織内での調整(既存のアウトプット方法との整合性)
2つ目は開発組織内での調整です。
エス・エム・エスの開発組織では、これまでにすでにテックブログや外部登壇などの外部アウトプットがあり、社内用ナレッジサービスとしてesaなども導入していました。
そのため、Zenn Publication導入にあたってはテックブログと何が違うのか、社内esaに書くことと比べてのメリット、Zenn Publicationを導入し、維持していくコストとメリットが釣り合っているかなどを整理していきました。
その辺りは必要だろうと予測がついていたのですが、予想外だったのはアウトプットに対する組織の文化・考え方の点です。エス・エム・エスでは従来から業務中に得た知見であっても、個人のブログや登壇で話していい、という文化だったのですが、このZenn Publication導入によって、個人のブログへの執筆などが制限されるのではないかという不安が組織内で起こりました。これは入社1ヶ月未満だった私が知らない文化で事前に想像できておらず、Zenn Publicationのガイドライン作成の中で発覚しました。最終的に既存のアウトプットと整合するものにガイドラインを変えることで対応しました。これが、本格稼働前に発覚して修正できたのはとても良かったと思います(開始してから発覚したらゴタゴタするため)。
余談ですが、年をとって経験を重ねることで社内の法務部・PRチームとのやり取りはどんどん上手くなりましたが、こういった組織の文化・開発文化というものは組織ごとに異なるため、常に未知のものがあるなと思います。前職でも、入社後数年経ってから、アウトプットに関する考え方が組織と自分で大きく異なることに気づく、ということがありました。
導入完了
上記の課題2つが7月にクリアできたため、7/18に晴れて全体チャンネルで利用可能になったことを告知しました。
実際にできたPublicationが以下です。
公開から1ヶ月以上経って、記事数は4とまだまだ*1ですが、これから徐々に増えていけばいいなと思っています。
振り返り
まず組織としての振り返りの観点で考えると、まずは、新たなアウトプットの手段が増えたことが単純に喜ばしいなと思います。エス・エム・エスの社内ではものによってはインターネット上にほぼない、もしくはまったくない知見や技術なども見つかっていますので、そういったものを迅速にアウトプットする手段は長期で見て社会に、そしてエス・エム・エスの開発組織としてもメリットになるでしょう。
個人として振り返ると、この一連の動きで社内の各部署とうまく連携できたこと、これをきっかけにエス・エム・エスの開発文化の理解が進んだことが大きなメリットでした。こういった開発組織の内外を跨いだ動きを苦手とする人も多いと思いますが、私はこの分野に強みがあるため、今回の導入が1.5ヶ月という短時間で大きな手戻りなく達成できたことはよい成功体験になりました。今回のZenn Publication導入のような組織規模での動きはレバレッジが効きやすく効果が高いので、チャンスがあればまたやっていきたいと思います。
*1:この記事の公開時点では6記事。
