過去の資産(コンテンツ)が信頼性構築の足かせに?「DevRel負債」とは

はじめに

DevRel活動は、広告などと異なり中長期的な活動が求められます。そして、活動の多くはアウトプットやコミュニケーションになります。長くDevRelを行っていると、徐々にアウトプットされるコンテンツが広がっていくでしょう。

そんな中で考えなければならないのが「DevRel負債」です。「技術的負債」というのはエンジニアであれば誰もが耳にする言葉だと思いますが、DevRelについても同じように負債が溜まります。今回は、このDevRel負債とは何か、そしてどのように向き合うべきかを解説します。

DevRel負債とは

DevRel負債とは、プロダクトやサービスの継続的な開発に伴って、過去のコンテンツが利用できない、または間違ったものになってしまった情報のことです。

これは、多くの場合アウトプット活動によって発生します。例えば、以下のようなコンテンツです。

• ブログ記事
• プレゼン資料
• 翻訳
• 動画
• チュートリアル
• ハンズオン資料
• GitHubリポジトリ
• ソーシャルメディアの投稿

ここでドキュメントを除外しているのは、ドキュメントはチームとして定期的にメンテナンスし、常に正しい状態を保たなければならないからです。メンテナンスされていないドキュメントや間違っているものは修正すべきです。

さらに、自社が生み出しているコンテンツだけでなく、ユーザーやコミュニティメンバー、パートナーが作成したコンテンツもDevRel負債になってしまうことがあります。外部の方々が作ったコンテンツについては、特にコントロールが難しいです。

よくあるDevRel負債の例

それでは、いくつかのパターンでコンテンツが負債になってしまう例を紹介します。

ブログ記事

ブログ記事で、古い情報により間違った使い方を解説してしまうことがあります。APIのバージョンが古かったり、リクエスト内容が異なっている、SDKのメソッド名が違うなどです。これはユーザーにとって大きな混乱をもたらします。

また、これは自社のSDKなどに限りません。ReactやVueなどのバージョンアップで使い方が変わっているケース、AWSやGCPなどのパブリッククラウド、SaaSの使い方が変わることも多々あります。プログラミング言語のバージョンアップも同様です。

他にも、まとめ記事で取り上げているサービスが終了してしまっていたり、紹介している料金体系が変わっているケースもあります。

スライド資料

スライド資料では、コードの記述などが変わってしまっているケースもありますが、あまり問題にはならないでしょう。スライドのコードよりも、ドキュメントやブログ記事の方がたどり着きやすく、参照されやすいからです。

スライドで問題になるのは、サービス立ち上げ時と機能が変わっていたり、当時は実装予定だった機能がGAされているケースです。それを知らない人にとっては、スライドの内容を信じて機能がないと判断してしまうかも知れません。

翻訳

ドキュメントの翻訳は、最初の翻訳よりもメンテナンスの方が工数がかかります。差分を読み取り、翻訳先に反映する作業は大変です。しかし、言語によって説明が異なると、ユーザーの大きな混乱につながってしまいます。

英語圏のサービスを日本国内で展開する際、日本語ローカライズはとても求められるでしょう。しかし、将来的なメンテナンス工数を考えずに公開すると、後々大変なことになります。現在はAIによって機械翻訳も進化しているので、自動翻訳に任せてしまうのも1つの手です。

動画

動画はテキストコンテンツと違って、容易には修正できないのが問題です。YouTubeなどで一度公開した動画は、一部だけ差し替えることはできません。一部をカットしたり、ぼかすことはできますが、それ以上の編集の場合は再アップロードが必要です。

YouTube Studioの画面

動画は作成、編集ともに工数がかかります。そのため、バージョンが古くなったからと言って一部だけ差し替えるのは難しいでしょう。多くの場合、収録し直しになります。

チュートリアル・ハンズオン資料

チュートリアルやハンズオンの資料も、サービスやSDK、依存ライブラリのバージョンアップなどに伴って使えないものになります。チュートリアルは、はじめてサービスを利用するユーザー向けに、丁寧に細かく説明を行います。画像も多く利用されていることも多く、例えば管理画面の見た目が変われば、画像差し替えが必要です。

ハンズオンの場合、フレームワークのバージョンが上がったり、書き方のトレンドが変わっていると、そのままでは使いづらいものになります。特にフロントエンド界隈では変化が激しく、メンテナンスが大変です。

ソーシャルメディアの投稿

意外と注意が必要なのがソーシャルメディアへの投稿です。今は問題がなくても、放置しておいたために突然批判が来たり、言質として責められることがあります。

ソーシャルメディアの場合は後から編集できないことがほとんどなので、過去のものは削除するくらいの対応しかできません。しかし、削除する行為自体が問題になるケースもあるので、慎重に対応する必要があります。

DevRel負債の解消方法

DevRel活動では多くのアウトプットが求められるので、常に最新の状態に保つのは容易ではありません。メンテナンスだけで時間を多く使ってしまうでしょう。そのため、DevRel負債を解消する方法を考えておきましょう。

ブログ記事・動画などの場合

ブログ記事では、いつ時点の情報であるか明示しましょう。また、1年以上経った情報については過去の情報である旨通知が出ると良いでしょう。Qiitaなどであれば自動で通知が出るようになっていますし、はてなブログでも同様の機能を実現できます。WordPressであれば、プラグインや自分でコードを書くことで実現できます。

Qiitaの古い記事対応

技術記事は年月が経てば古くなってしまい、それだけ間違った情報になる可能性があります。完全に使えなくなった情報については削除するか、リライトして新しい記事として公開すると良いでしょう。

動画の場合は、新しい動画を投稿して過去の動画は消すか、説明文に注意書きを書くようにしましょう。また、動画内で「この動画は2021年の情報です」といった注意書きを入れると良いでしょう。

GitHubリポジトリ・ハンズオン資料などの場合

GitHubリポジトリは、非公開にする必要はありませんが、アーカイブする必要はあるでしょう。アーカイブすればユーザーは過去のコードであることを認識できますし、それでも参考になりそうなコードは確認できます。

アーカイブしたリポジトリ

DevRel負債を放置した場合の問題

古いアウトプットを放置した場合には、どういった問題が起こるでしょうか。ここでは、よくある問題を紹介します。

ユーザーの信頼性を損なう

古い情報を信じて実装した結果、うまく動かなかったらユーザーとしてどういった気分になるでしょうか。本来信頼性を構築するためにあるコンテンツが、逆に信頼性を損なう結果になりかねません。

こうしたユーザーの多くがプログラミング初学者であったり、あなたのサービスについて詳しくない方たちです。うまく動かない場合に自分で解決できれば良いですが、それができない場合は、もうあなたのサービスを利用しようとは思わないはずです。

サポートコストを増加

有償サポートを締結している場合、うまく動かないコードについて質問が寄せられることもあるでしょう。その度に「古い情報です」と説明したり、もうサポートされていない機能であることを説明しなければなりません。これはサポートにとっては無駄な負担です。

このようなコンテンツはビジネス的にもマイナスになるので、削除またはリライトすべきです。

DevRel負債の解決策

それでは、DevRel負債について、どのように取り組むべきかを解説します。

定期的なメンテナンス

予算が十分にある場合には、定期的なメンテナンスが可能でしょう。しかし、これまでに行ったアウトプット全体を網羅的にメンテナンスし続けるのは困難です。筆者が経験したケースではサービスのリブランディング、ドメイン変更などに伴う一括見直しがあります。これは定期的なものではなく、一時的に大きな工数をかけて行ったものになります。

翻訳については、外資系のサービスでは、元のドキュメントが一部でも修正されたら一旦英語版に切り替えることが多いようです。そして、最新版を翻訳対応したらローカライズ版を表示するようにします。真は常に英語版であり、ローカライズ版があるときだけそちらを採用するという方法です。

また、翻訳メモリを使う方法もあります。これは、英語版のドキュメントにおいても一覧表などで管理する方法です。この方法はグローバルで共通の方法が利用できる半面、一部だけ英語(原文)が表示されてしまうという問題があります。

一元管理する

これはMicrosoft Learnが好例です。必要な情報を1つの場所にまとめて管理しています。他のプラットフォームをあまり利用せず、GitHubやYouTubeなどに限定しています。アウトプット先を絞り込むことで、メンテナンス時の工数を軽減できます。

DevRelの観点で言えば、開発者がいるプラットフォームを選んでアウトプットしたくなります。そうすることでリーチが容易になるからです。しかし、後先考えずに手を広げてしまうと管理が煩雑になるのは当たり前です。特にパブリッククラウドなど情報が日々アップデートされる環境では、管理面を考慮する必要があります。

アクセス解析・問い合わせを利用する

すべてのコンテンツを対象にするのではなく、よく見られているものや参照されているもの、問い合わせが多いものから対応するという方法もあります。その場合には、アクセス解析の利用や実際の問い合わせに合わせて対応します。外部サービスではアクセス状況が分からない場合もあるので、自分たちが知らない間に信頼を損なってしまうのがリスクと言えるでしょう。

楽観主義になる

スタートアップやDevRelにかけられる予算が多くない場合には、楽観的に構えるケースもあります。古い情報は古いものとして無視するというものです。これは予算的に厳しい場合には有効な方法です。Web検索では新しい情報が優先されるケースが多いので、次々と新しいコンテンツを提供することで古い情報を埋めてしまう方法もあります。

サードパーティーコンテンツ・UGCの対応

ユーザーやパートナーが作ってくれたコンテンツ(UGC。ユーザージェネレーティッドコンテンツとも)は対応が難しいでしょう。時間が経ってしまったコンテンツは、現在の状況にそぐわないものになってしまっている可能性があります。とはいえ、削除して欲しいとも言えないですし、修正工数は作成してくれたユーザーの負担になってしまいます。

ある程度の関係性が構築できている場合には、その修正案を提示しながら依頼するのが良いでしょう。調べ直して修正するのは大変ですが、正しいコードや情報を提供されれば、負担は大きくありません。コンテンツを通じたコミュニケーションもでき、関係性を深めるのにもつながります。

おわりに

今回は、アウトプットに伴うDevRel負債の問題について取り上げました。アウトプットはとても大事ですが、古い情報が思わぬ障害につながってしまうリスクがあることを知っておいてください。

情報の消費速度は加速度的に増しており、最新の情報もあっという間に陳腐化して、間違った内容になってしまいます。最初のアウトプットはもちろん、その後のメンテナンスも重要です。DevRel負債を増やしすぎないよう、適切な対応を心がけましょう。