テクノロジーアップデート情報の伝え方

2023.12.09 XIMIX 中根

CCoE_image 日本情報通信の中根です。

本記事はCCoEクリスマス！クラウド技術を活用して組織をカイゼンした事例を投稿しよう！ by KINTOテクノロジーズ Advent Calendar 2023の9日目の記事となります。

はじめに

私はGoogle Cloudを取り扱うチームに所属しており提案から導入から保守まで一気通貫ご支援をさせていただいております。
クラウド利活用推進/CCoEとしてもご支援させていただいております。

本記事ではCCoEに技術パートナーとして期待されることが多いテクノロジーアップデート情報をどう伝えていくかをテーマにお伝えしたいと思います｡

情報ソース

テクノロジーアップデートというとどのような情報が公表されているでしょうか。

クラウド事業社が出しているリリースノート

大本営情報となります。
ここに書いていない変更は(基本的には)ないのでまずは押さえましょう。
＊まれにサイレントアップデートやそのアオリによる影響もありますが割愛します。

クラウド事業社が出しているブログ

リリースノートはサービスの仕様や変更が網羅的に掲載されています。
リリースノートは「xxxができるようになりました。」といったように非常にシンプルであり、それができることで何ができるかは書いていないです｡

一方ブログは何かしらのテーマに沿って記事化されているためとっつきやすいです。
エンジニアよりエンドユーザーに近い方ほどこちらのほうが有用に感じる方が多いかと思います｡

よりエンドユーザーに近くなればなるほどどのように良くなるか、といった付加情報がまとめられていることが重要です。
ですのでブログに掲載されるような企業事例であったりハンズオンのような形式のほうがより親近感を持ってもらえることが多いです｡
もちろんブログなのでそこまで詳しくは載っていないことが多いのですがユーザー部門から挙がる、やってみたいという要望はこういったところから生まれることが多いです｡

企業・個人テックブログ

先ほどの事業者ブログと同じように親近感をもてる、もしくはまさにこれに困っていた、というような情報に出会えます｡
チュートリアルからピンポイントなトラブルシューティングまで多種多様な内容が取得できます｡

ただし考慮点としては背景となる環境やルールが必ずしもマッチしない場合があることに注意してください｡
エンドユーザーから「この記事に書いてある内容をやってみたいけどできる?」というような問い合わせがあっても、セキュリティルール等で「それは難しい or できないです、、、」といったことがままあります｡

ガイドラインの見直し等につながるきっかけにもなる一方、ガイドラインの根幹を揺るがしかねないような場合もなくはないので注意が必要です｡

SNS

SNSは情報の内容としては非常に少ないですがなにより即時性があります｡
テクニカルアップデートですと大きなイベントの速報などがあります。

非公開情報

インターネットには出ていないような社内情報やパートナー企業からの情報となります。
1次情報ソースとしてそのまま周知することはあまりないですが情報が錯綜しないようにうまく連携をとることが重要となります｡

まれに伝言ゲームのように誤った情報が拡散されることもあるので気をつけましょう。
例) xxxの新機能がMM月に一部地域でプライベートプレビューされるようだ→xxxの新機能がMM月に使えるらしい

情報の伝え方

次に重要なことは情報の伝え方です｡
観点としては誰に、なぜ見てほしいか、どのように伝えるかの3点となります｡

誰に

お気づきかと思いますがこれらの情報は日々大量に通知されます｡
能動的に情報を集めてくれるユーザーはごくわずかであることに気をつけましょう。
テック大好きな方へは前述の情報ソースのRSSやアンテナサイトのようにまとめたものを提供するだけで良い場合もあります｡
しかしながら多くの人は見てくれない、使われない情報となってしまいます。
ですので情報を誰に伝えるか、誰に見てほしいかを明確にすることがは非常に重要となります｡

なぜ見てほしいのか

次になぜ見てほしいのかです。
テクノロジーアップデートを伝えることでどのようなメリットがあるか、伝えたことでどうしてほしいのかを明確にすることが重要です。
これは私の経験上3つにまとめられると思います｡

コストへの改善
技術への改善
ビジネスへの改善

例えば安定性が改善した改修があった場合はビジネスの品質が向上しますし、コストフレンドリーなメニューが増えたら言わずもがなコスト改善に繋がります｡

情報を発信する側からどのようなメリットがあるかを整理することで受取側の理解度が変わってきます｡
すべての情報に対して実施することはまず難しいですがこれは、といった内容にはタグ付けをするであったり優先度をあげるといった営みができるとよいでしょう｡

どのように伝えるのか

さて、前段の誰に、なぜ伝えるのかが整理できたら伝え方はある程度パターン化できます｡

1. 情報ソースが生の状態に近い状態での提供

当たり前ですが情報ソースを全員が知っていること、だれでもアクセスできることです｡
多くの場合はガイドラインやWebサイト等にリンク集等で共有しているかと思います｡
この情報は能動的に情報を集めてくれる方や困ったときに最初の窓口になります｡

2. ある程度のカテゴリに分類・タグ付けされた状態での提供

こちらはサービスの用途や目的に応じてタグ付けしたりキュレーションした状態での提供となります｡
例えばデータ分析・AIをフォーカスしたり、事例系の記事をピックアップしたりです｡

サービス毎のリリースノートやブログのタグ等をうまく使うことで対応ができる範囲となります｡
ただ細かくすればするほどメンテナンスやユーザーが情報にたどり着けなくなることがあるので注意が必要です｡
個人的にはアプリ・インフラ・開発・データ/AIといったサービス分類やコストや事例といったビジネス分類のような整理が良いかと思います｡