弊社ではTableauダッシュボード作成を支援させていただいておりますが、ご提案時やプロジェクト中に「プロジェクト完了後はどのような支援が可能か」というご質問をよくいただきます。

そこで本記事では、ダッシュボード作成プロジェクト完了後における主な対応内容と、その契約形態についてご紹介します。

ダッシュボード作成プロジェクト完了後における主な対応内容

ダッシュボード作成プロジェクトの完了後(検収後)の主なご支援内容は、以下の5つに大きく分類されます。

  • 1. データ更新対応(手動更新が必要な場合)
  • 2. 利用・運用時の質問対応
  • 3. 利用者および運用者からのフィードバックに対する改修検討・実装
  • 4. ダッシュボード利用推進に関する調査・相談対応
  • 5. 不具合が発生した場合の調査・対応

1. データ更新対応(手動更新が必要な場合)

最近では設計段階からデータソースが自動更新される構成や運用について検討することが主流ですが、それでも環境の都合により手動更新が残る場合や、そもそもローカルデータソースのみを用いることが前提となっているダッシュボードを作成することもあります。

その更新作業についてご担当者様による対応が難しい場合、弊社側で対応することが可能です。

また、更新作業の省力化や自動化が作成プロジェクト中ではスコープ外となっていた場合、改めて可能かを検討し、改修を行う場合もあります。

2. 利用・運用時の質問エスカレーション対応

ダッシュボードが使われ始めると、利用者から質問が来るようになります。多くの質問はダッシュボード作成を通して仕様を把握されているご担当者様にてご対応いただける内容ですが、質問の中には詳細な仕様や技術的な確認を要することもあります。その場合、エスカレーション先としてお問い合わせいただき、その回答を行います。

3. 利用者および運用者からのフィードバックに対する改修検討・実装

実際に運用していく中で、利用者から要望が来たり、ご担当者自身で機能追加を検討されたりすることがあります。

改修内容の例

  • 文字が小さくて読みづらいので大きくして欲しい
  • グラフの色を変えて欲しい
  • ◯◯◯の機能も追加したい
  • ■■のデータも表示したい

それらのフィードバックに対して、実装可否や実装工数の検討を行い、さらに表示速度への影響がないかなど確認をするテスト実装も挟みながら対応を決めていきます。

4. ダッシュボード利用推進に関する調査・相談

ダッシュボードが作成された後の一番の問題は、「作ったものの利用されない」ということです。

利用推進のための第一歩として、たとえばTableau Serverにパブリッシュされているダッシュボードであれば、「ビューへのアクセス量」「特定のユーザーによるアクション」といった機能を利用し、Tableau Serverの利用状況を調査できます。

また利用者のTableauに対するリテラシーが利用推進の妨げとなっている場合は、別途研修・トレーニングをご提案させていただくこともございます。

5. 不具合が発生した場合の調査・対応

ダッシュボードの表示にエラーが生じた場合、その原因がどこにあるのか調査を行い、対応を行います。比較的多く発生する事象としては以下のような例があります。

データが最新ではない

  • データマート側の更新が止まっていた
  • ダッシュボードの抽出更新が失敗していた
    • 参照先のテーブルに変更が生じていた・消失していた
    • 抽出更新の所要時間が延び、上限時間に達し停止していた

グラフが正しく表示されない

  • 作成時には無かった項目がデータに追加されてエラー表示となった
  • 軸の範囲を固定していたが、値がその範囲を超えるようになった

ダッシュボードを開くまでに時間がかかるようになった

  • データ量が増えた(ライブ接続)
  • 期間経過により表示させるデータ量が増えた

実際の例として、Tableau Serverにパブリッシュされているダッシュボードの閲覧者から「データが最新の日付分まで含まれていない」と連絡が入り、下記のような対応が発生したケースがあります。

該当するダッシュボードを確認し、事象・対象範囲を確認

事象は当該ダッシュボードのみに発生していた。抽出の更新が正常に完了しているかを確認。

抽出の更新は正常に完了していた。データソース側に問題が生じていないか確認。

ダッシュボードがデータソースとして参照しているデータベースのテーブルを確認するも、更新状況に異常はなかったため、テーブルの構成を確認し原因を調査。

テーブルの作成に用いられているマスタテーブルの状況について担当者に確認したところ、更新が停止しており最新の状態ではないことが判明。

マスタテーブルの更新を担当者に依頼。対応いただいた後、抽出の更新を手動実行。データが正常に表示されたことを確認。

上記の経緯を含め、ダッシュボード閲覧者宛に報告。

上の例のように、原因によっては数日から数週にわたり複数部署との調整やデータ周りの確認が必要となるため、柔軟な対応が求められます。

運用フェーズの契約形態

前述の通り、ダッシュボードは作成後もさまざまな対応が求められますが、対応範囲が広くかつ不確定なため事前に作業内容を正確に把握することが困難です。

弊社では基本的にご契約形態は準委任契約とさせていただいておりますが、このような場合は「成果物を報酬の対象とする成果完成型」では難しいため、「労働時間を報酬の対象とする履行割合型=工数契約」をご提案しております。

工数契約の場合、総工数 = 「月次での想定稼働工数」×「契約月数」となりますので「月次での想定稼働工数」を算出する必要があります。算出するための主な確認項目は以下の3点です。

1. 作業工数

対応予定の作業・課題について洗い出し、各作業の予定工数を算定します。

しかし、対応予定作業の詳細が定まっていないからこそ、柔軟性のある工数契約が選択されることが多いため、作業の発生頻度を大まかに想定し「週◯h × 週数 = 月次工数」のように定めることもあります。資料作成の予定がある場合、その工数も含めます。

2. ミーティング工数(社内外)

作業内容に応じて、進捗報告や諸確認などのためにミーティングを行います。一般的には週次や隔週で実施します。

工数算定式は「1回あたりの時間 × 1ヶ月あたりの頻度(回数)× 参加人数」となります。場合によっては想定した定例ミーティングとは別に臨時でミーティングが行われることもあるため、作業工数含め事前にどのような想定となるかを検討・相談しておくことが必要です。

また、定期・断続的に作業やミーティングがある場合、作業方針検討・進捗確認等のため弊社内でもミーティングを行います。その頻度も上記ミーティングに応じて定めます。

3. プロジェクト管理工数

1と2に含まれない工数の例として、たとえばミーティングの準備やタスク管理、関係者調整などのミーティング以外での(Slack・Teams・メール等での)社内外コミュニケーションがあります。プロジェクトマネージャーがアサインされている場合はその稼働も含まれます。

プロジェクト管理工数は一般的に10%から20%が目安と言われていますが、プロジェクトごとに適正な値は変わるため、1、2と同様に可能な限り正確に見積を提示できるように努めています。

まとめ

今回は、ダッシュボード作成プロジェクト完了後のフェーズにおける主な対応内容と、その契約形態についてご紹介しました。

実は、今回触れていない内容として「新しくダッシュボードを作成したい場合」があります。こちらについては、要件定義の分担や成果物の取り決め、作成頻度と納期など、総合的に判断する必要はありますが、工数契約型が選択される場合もあるということを補足しておきます。

弊社ではダッシュボードの作成後も、運用や活用面で継続的にご支援させていただいていた事例が数多くございます。ダッシュボード作成後のフェーズも含めてサポートできるパートナーをお探しの方はぜひお気軽にご相談ください。

お気軽にご質問、ご相談ください

上村栄

大手電機グループのICTサポートベンダーにてフィールドエンジニア・研修講師として従事。その後、店舗・商業施設等の人流解析を行うベンチャー企業にてプリセールス&設計・導入担当を経て、プリンシプルに入社。

関連ブログ