上村栄・TableauコンサルタントTableauこの記事では、Tableauダッシュボード作成プロジェクトを推進する上で意外に見落とされがちな確認点を、実際のプロジェクトであった例を交えながらご紹介します。前回の要件定義編に続き、今回はプロジェクトのダッシュボード構築段階で気をつけていただきたいポイントを紹介します。前回記事:Tableauダッシュボード作成プロジェクトの落とし穴|要件定義編【実例あり】ダッシュボードを自社で開発される際や、外部依頼時の確認の際のご参考になれば幸いです。用意したデータですべての事象パターンを網羅できていない※実案件の例のため、テーブルやカラムの詳細等については記載しておりません。ある施設のテナント実績ダッシュボードを構築した際、実績データと共に、テナント契約状況データをご連携いただきました。含まれているものです。(詳細は記事「フロアマップでカスタムポリゴンマップを作成する方法と注意点【Tableau】」で紹介)実績データはDWH内に格納されていましたが、テナント契約状況データはデータ連携が行われていなかったため、業務システムから毎月出力いただくファイルをデータソースとして、毎月更新を行う運用が想定されていました。構築を進め、利用ユーザーに確認をいただいたところ、「テナントの情報が表示されなかったり、実態と異なる部分がある」と連絡が入りました。調査を行ったところ一部のテナントで以下のようなケースが確認されました。「*」表示となる空き区画なのに旧テナント名等の情報が表示されるテナント名や契約先企業の情報が異なるここまでの情報で既にピンときた方もいらっしゃるかもしれませんが、原因はデータの粒度と出力タイミングでした。実績データ・ダッシュボードの日付粒度が日次である一方、テナント契約状況データは毎月出力した時点での断面であったため、月の途中で以下のような事象が発生した場合には正しい表示ができない状況となっていました。契約期間中に、テナント名や契約先企業の名称が変更となった解決策:追加データの連携&日付粒度の統一こちらの事象を補完するデータの有無をお客様に確認をしたところ、「契約や情報の変更が発生したタイミングとその内容」を記録したデータが別に存在することが確認できました。その出力ファイルをデータソースとして追加することで、実績データと同じ日粒度でテナントの契約情報を持つことができるようになりました。DWHへの連携優先度が低いとされていたテナント契約情報について、ダッシュボードの運用効率化を図れる旨を弊社からご説明・ご提案させていただきました。後日、DWHへのデータ連携が実現したためダッシュボード側も改修を行い、現在では自動での更新が可能となっています。要件定義の段階で、可視化したい指標・項目とそのために必要なデータの確認は必ず行いますが、可視化を行った段階で例外パターンなどが文字通り見えてくることもあります。お客様側は、必ずしもすべての契約が同じタイミングではなかったり途中解約があったりすることを知っていたとしても、手元にあるデータで可視化が可能かの判断を行うことは難しい場合が多いです。理想は元データの段階で整った構造であることですが、運用中データにありがちな「人が見て分かりやすい表記」が必ずしも「可視化に適したデータ」ではないため、Tableauでの可視化を踏まえた観点で実データの中身を確認・把握することが必要です。作業工程の説明や用語共通化などを後回しにしているTableauダッシュボード作成プロジェクトにはさまざまなポジション・スキルの方が参加されるため、Tableauに対する理解度もさまざまです。いって、Tableauに対しての理解度が低いままプロジェクトの進行だけに目が向いてしまうと、過剰な期待や認識の相違が生じやすくなります。そのような状況を防ぎプロジェクトを円滑にすすめるために、以下の3点を意識してプロジェクト関係者のリテラシー向上に取り組むことをオススメします。プロジェクト内で使用される用語を統一するプロジェクトにおいて頻繁に使用される用語は、プロジェクト中だけでなく見積書やダッシュボード仕様書などの資料中でも使用されるため、理解を深めていただくことで認識の共通化に繋がります。具体的には以下のような用語があります。(ワーク)シート:グラフ・表などのダッシュボードの部品。)で呼ばれることが多いので、むしろ「プロジェクト」や「ワークブック」などの「一般的に見えるがTableauならではの使い方をする用語」を説明しておく方が効果的です。適切な詳細度合いで説明する上記の基本的な用語については1回のインプットでは定着しません。必要に応じた適切な頻度で使用することによって徐々に理解いただけるようになります。「先日の打ち合わせでフィードバックいただいたAダッシュボードのツールヒント部分の修正が完了しました。本番用のプロジェクトにワークブックごとパブリッシュ済みです。」という報告をした際、当初は各用語についての確認が入ることがありますが、最終的には「Aダッシュボードが含まれるワークブック内の他のダッシュボードを含め、本番用のプロジェクトに存在している」というような言外の情報も適切に伝わるようになります。フィードバック・要望のコミュニケーション精度が向上しているか確認するさらに、Tableauの理解が進むとフィードバックや要望のコミュニケーション精度が向上していきます。ここで言う「Tableauの理解」は用語だけでなく、Tableauの作業工程も含まれます。イメージしやすい例がダッシュボードのレイアウトコンテナーです。Tableauのダッシュボードにはレイアウトコンテナーという概念があります。アイテムを一緒にグループ化するので、すばやく配置できます。アイテムは自動的に調整されます。コンテナーは書式設定にも使用できます。コンテナーを使用してアイテムをグループ化する|Tableauヘルプレイアウトコンテナーには「水平」と「垂直」があり、コンテナー内に配置したグラフや表などがどちらの方向に並ぶかを制御できるため、ダッシュボードを構築する際は標準的に用いられます。詳しく知りたい方は上記のリンク先をご覧ください。上記のような説明をしてもTableauに詳しくない方にはピンと来ないので、お弁当箱で例えてみます。ここにお弁当箱があります。このお弁当は、ご飯や複数のおかずで構成されています。このお弁当箱をダッシュボードとしたとき、構成要素であるご飯やおかずが入っている小分けの空間がレイアウトコンテナーです。イラスト上は間仕切りが固定されていますが、Tableauダッシュボードのレイアウトコンテナーは高さや幅を調整することが可能ですので、縦横可変なシリコンカップと思っていただいた方が近いかもしれません。具体的な例として、下記のダッシュボードの場合は、赤枠の垂直コンテナー内に青枠の水平コンテナーが配置されており、さらに下側の水平コンテナー内にも垂直コンテナーが配置されているという入れ子構造になっています(画面左下に構造が示されています)。各コンテナー内にグラフなどのシートが配置されています。このダッシュボードの中で1つだけコンテナー内に配置されていないものがあります。それは、マップ上の色凡例です。ダッシュボードの任意の場所にパーツを配置したい場合、「浮動」という状態で(お弁当のご飯の上にある梅干しのように)配置することがあります。お客様からのレイアウト希望に基づき配置することが多いのですが、「浮動」にはデメリットがあります。それは、コンテナーの動きに連動しないため、ダッシュボードサイズが「自動(表示に使用するウィンドウのサイズによってダッシュボードのサイズが自動的に変更される)」の場合や、他要素の調整を行う際にレイアウトが崩れるという点です。そのような事象が発生した際、ダッシュボードサイズとレイアウトコンテナーについて理解いただいているお客様とは、以下のようなシンプルなコミュニケーションが可能です。お客様「パブリッシュしたダッシュボードを見る場合は基本的にパソコンでしか見ませんが、ディスプレイ設定などを変えている従業員が一定数おり見え方がまちまちなようです。ダッシュボードサイズを自動に変更することは可能ですか?」コンサルタント「貴社ではダッシュボードを印刷する可能性もあると伺っているのでダッシュボードサイズは固定にしています。ご要望により浮動でレイアウトしているオブジェクトがあるため、レイアウトの調整や仕様変更を検討する必要があります。加えて、自動は固定よりも表示速度が遅くなる場合もありますので総合的な判断が必要です。」お客様「自動の場合は表示速度に影響することがあるのですね。印刷要否含め改めて確認します。実際は、ズレの程度と発生頻度および許容度合いをどうするか確認した上で対応を決めていくことになりますが、用語や作業工程についての認識を共有できているため、スムーズに検討できるようになっていきます。ここで誤解のないようにお伝えしておきたいのですが、いわゆる専門用語を多用するだけではコミュニケーションや相互理解に問題が生じてしまいますので、プロジェクト進行において各種ご判断・ご検討をいただく上で必要な事項については、お客様がご理解いただけるようにPM・コンサルタントが分かりやすく説明を行いながら進行を行うことが求められます。その上で、Tableauに対する理解を深めていただけると、とくにスケジュールや工数が逼迫しがちなプロジェクト中盤〜終盤のダッシュボード修正や運用具体化の段階でのリスクを低減させることに繋がります。そのため、先方の理解度合いや認識に相違がないかを定期的に確認することが重要です。まとめ今回はTableauダッシュボード作成プロジェクト内で意外に見落とされがちな点として、実際のプロジェクトでの例を参考に、「データがすべての事象パターンを網羅できていない」と「Tableauについての理解度向上を後回しにしている」についてお伝えしました。実例を元にしているため詳細に記載できなかった部分もありますが、これからダッシュボードを作成される方や、作成プロジェクト最中の方の参考になりましたら幸いです。弊社は多くのお客様のTableauダッシュボード作成を支援させていただいております。お悩み、ご相談等ございましたらお気軽にお問い合わせください。大手電機グループのICTサポートベンダーにてフィールドエンジニア・研修講師として従事。