2019/12/29こんにちは!Yukoです。TC19のセッションで得た情報を上げる!と言っておきながらすっかり年末になってしまいました...皆様いかがお過ごしでしょうか?今回はCoEが企業に必要な理由についてのセッションを受けてきたのでその情報を共有したいと思います。Excellence(センターオブエクセレンス)組織を横断する部署やチーム、役割のこと。ここでは特にTableauのノウハウなどを集約する役割を持つ人のことを指します。この言葉の由来は1940~50年代にまで遡り、米国カリフォルニア州のスタンフォード大学で当時多くの優秀な学生が東海岸へ流出してしまうことを防ぐため、全米から著名な教授・スタッフを呼寄せ、学究拠点の中心とする施策から来ている。その後、様々な大学や研究機関での施策・拠点として発展、企業においても優秀・有識なリソースを集約し組織運営を向上化・効率化するという形で適用され、ITの分野でも使われるようになった。SessionでSansanの清水さんも本セッションについて言及されていました。TC19ではこうしたCoEの必要性やBlueprint等、組織のデータドリブン化の必要性についてたくさんのセッションで説かれてました。これはTableauが広く浸透し、組織で多くの人に使われるようになった結果と言えるでしょう。複数の人が同じようなVizを作って分析してる...(リソースの無駄)なのにAさんとBさんで売上の数字が違うぞ?(データの乱立)あの部署とこの部署で使われる用語も違うしよーわからん!助けて!(非効率)などなど...書き出したらきりがなさそうですね...。身に覚えのありまくる方も多いのではないでしょうか?今回のこのセッションでは、CoEを作って運営するとこんないいことがあるよ!的な感じで50の理由を紹介されていましたので、備忘も兼ねてまとめたものを紹介していきます!(「え?これも1?」って言うのもあったので正確には50じゃない気がしますが...きりよく50にしておきましょう。何のためにやるのかを一人だけで抱えてはいけません。経営層と現場の価値観と戦略を共有することが何よりも大切です。これから紹介する取り組みは、すぐに結果が出ることではないからです。ステアリンググループであったりシニアリーダーだったり、まずは組織の上の人たちに取り組みを理解してもらいましょう。データを見る人が直接会って話ができる人か、メールで話す人なのか、タイムゾーンの違う相手なのか?相手に届く最善の方法考えます。この時に必要なのは、ガチガチの規律にしないことだそうです。規律が厳しいと誰もやらなくなってしまうからですね。データの管理7.データカタログを使う8.計画的に設計され、Serverに公開された最新のデータソースを活用する9.ロジックを定義し、一貫したデータにする10.透明性のあるレポートでデータ品質を所有する先述した通り、有象無象のデータソースから正しい解を得るのは相当大変ですよね...。組織が大きくなればなるほどデータも大きく、管理する必要があります。弊社でもダッシュボード開発の際、「どのデータソース」に「何のカラム」があり、そのカラムの「データ型は何か」などを極力整理したデータ定義書を作っています。その際、Aのデータマートではこの計算で、Bのデータマートであの計算、等の計算ロジックも整理できていると理想的です。ここまで細かいのを作るのは大変ですが、様式はExcelで簡単なものでいいので、こうしたデータカタログがあると後々絶対助かります!データソースの信頼性も向上しますし、それはすなわち成果物の責任を持つことにも繋がるからです。ベストプラクティス11.組織がどのように開発するか、リリースサイクルなどのプレイブックを開発する12.標準デザインを決めて組織内でスタイルを統一する13.Vizの標準を作って、ポジティブなUXを確保する14.データを使う人、視覚化する人は誰で、誰が問題を抱えているのか、好奇心を持つ15.難しいデザインである必要はなく、シンプルに保つ16.時間やコストの節約、収入を創出できた成功例を記録する17.ライセンス契約の在り方を検討する(直接契約はログインを可能にし、間接契約ではサブスクリプション機能・アラート機能など)18.リソースを監視し、Vizの展開タイミングのベストを考えてサーバーをモニタリングする19.レスポンスタイムやCPU利用率などのパフォーマンスをモニタリングする20.Tableauのユーザー会などのコミュニティコンテンツを活用するより実践的になってきました...。デザインのはなし「組織や部門が異なるとダッシュボードサイズもバラバラだし、あっちではパラメーターやフィルターが上に纏まっててくれたけどこっちでは右のほうに集中してる...」これでは思考が妨げられてしまいますね。Truestarでは、ダッシュボード開発の際、最初にテンプレートを作るようにしています。デザインのベースを最初に決めてしまい、複数人で開発し始めてもデザインがぶれないようにするためです。テンプレートがあれば、開発者が個々でデザインに悩む時間の節約にもなります。デザインについての参考情報として、以下のページや書籍の紹介がありました。dashboard※洋書ですが、個人的にこの本はデザインに悩んだ際に私もよく使っています!サンキーダイアグラムなど、難しくて実装に時間がかかるものが必ずしも必要というわけではありません。皆がより早く正しく、インサイトを得られるデザインが理想的です。「な~んかもっさりしててストレス...」そういうVizはいつしか見てもらえず、埋もれてしまいます...レスポンスタイムがかかるもの、CPU利用率が高すぎるものがないか、あるのなら改善に向けてどうしていくのか考えます。開発者の成長に合わせて、最適な環境を用意してあげる必要があるということですね。Lyonsセッションで紹介されていた開発者の人たちの知見。それらすべてを自分のものにしないとCoEとして名乗ってはいけない!ということはありません。SNS等で彼らの発信をチェックして、チームで活用できるものがあれば検討してみるのも手です。Publicは素晴らしいVizの宝庫として利用しない手はありません。KriebleさんのPublicは参考にできると紹介されていました。google翻訳!って感じですね。いい日本語が見当たらないんです(笑)語彙力...でも要は、ユーザーが初めて見よう見まねで作ったものを見てあげて、よりよくなるように改善点を提案してあげれば、ユーザーは「もっと使ってみよう」と思うはずですよね。Tableauを使って分析したい、と思ったとき、ゴリゴリに使えるヘビーユーザーだけでなく、これから始める人も、データに触れる敷居を低くしてあげるのもCoEとして大切なことだと思います。彼らの取り組みを発表してあげれば、モチベーションアップにもつながるはずです。周りを見てみたら、組織内のどこかで誰かがすでに別の方法でより良い取り組みをしているかもしれません。docomoの木村さんが紹介されていましたが、要は組織の中でゲーム感覚でスキルを向上させる方法です。今の自分のスキルレベルが今どのあたりで、どうすればさらに上にいけるのか、ゲーム感覚でRPGみたいにしている取り組みがあります。suggest...」といったような支援的な言葉遣いを意識的にしているそうです。すると人は守られていると感じ、アイデアをシェアしやすくなります。要は、相手を否定しないこと。バックグラウンドの人が組織にいると思います。みんなスキルも違うし、見えるアングルも十人十色です。失敗があった際は素直にその失敗を認め、別の機会に活かす。躓きポイントやヒヤリハット集みたいなのは、同じであることが多くないですか?大丈夫です、みんな同じ!ROI46.成果は証明できなければならない47.CoEは他のビジネスと同様にROIを証明する必要がある48.ROIを可視化するダッシュボードをTableauで開発する49.組織のプロフィールを紹介し、成功したCoEたちを注目させる50.COEが効果である必要はなく、アジャイルであり続けることで効率的で費用対効果が高くなるCoEの取り組みの結果、どれだけ時間が節約され、コストカットでき、収入を生むようにできたか。結果もTableauでダッシュボードとして共有すれば、もうあなたの組織はデータドリブン化に成功していますね!まとめTableauがBlueprintを声高らかに説いている背景には、多くの企業がデータドリブン化に失敗してきた背景があります。その阻害要因が「People」、「Process」、「Technology」であり、一番には人間だそうです。今後はそうしたガバナンスの部分でも旗振りが必要になっていく、というわけなんですね。繰り返しになりますが、ガチガチにルールを固めて活動を委縮させることがあっては本末転倒です。これらの取り組みは結果が出るのに時間がかかる旨を組織の上層部に理解してもらう必要があります。参考にしていただければ幸いです。