「データアナリストにデータ可視化を依頼したいが、何をすればいいのかわからない」
「データ可視化を依頼されたが、依頼内容が曖昧なのに差し戻しが多くて困っている」

昨今、専門知識のない利用者が自分で分析・レポート作成をできるセルフBI（Business Intelligence）ツールが発展してきました。これにより、スキルの有無や職責を問わず、データ可視化がより簡易になっています。一方で、BIツールにまつわる業務や課題は複雑多岐にわたり、難易度が高まってきています。

この記事では、BIツールを用いた可視化を依頼する際・依頼される際におさえておきたい要件定義のポイントについて解説します。

データ可視化における要件定義の重要性とは？

データ可視化業務を遂行する上での課題には以下のようなものがあります。

• ・誰が意思決定者かわからないので、正解が不明瞭
• ・意思決定者が作業者に丸投げして責任を負わない
• ・納期が明確ではない
• ・要求が多く、納期に対して過剰業務となっている
• ・第三者の意見をくみ取らないといけない
• ・成果物のダッシュボードやレポートが満足な品質ではない

など

データ可視化業務を成功に導くにはこれらの課題に立ち向かう必要があります。その方法として、ここからは要件定義の重要性を提案していきます。

なお、要件定義の方法論については、プロジェクトマネージャーや、プロダクトマネージャーの要件定義の方法論と合致しています。本記事ではデータ可視化業務における要件定義の方法論について述べます。

役割分担を明確にするDACIモデルのススメ

要件定義の前段として、まずは役割の話をします。データ可視化に携わる関係者が多ければ多いほど、組織やプロジェクトチームに次のような混乱を生じる危険性があります。

• ・責任や役割が曖昧である
• ・意思決定者が誰なのかがわからない
• ・決定事項に対して、後から決定を覆す人がいる

など

こうした混乱を招かないようにするには、関係者の役割や責任範囲を明確にし、業務を円滑に遂行できる体制づくりが必要です。そこで、DACI（ダキ）モデルとよばれるフレームワークを用いて、このような課題を事前に解消する仕組みを作ることをおススメします。

DACIモデルの構成

DACIモデルは、ソフトウェア会社のIntuit社が1980年代に開発した意思決定フレームワークです。DACIとは特定の役割を示す単語の頭文字で、以下の4つで構成されています。

DACIモデルの運用ポイント

DriverとApproverを同一人物が担当しない

データ可視化を行う人と、意思決定者が同一人物の場合、抜け・漏れや見落とし、データの改竄といった事態が容易にできてしまうことがリスクになります。

人数が少ない場合、DriverとApproverを同一人物が担当せざるを得ないかもしれません。その場合はレビュワーとしてContributorを立ててリスクを回避する対策が効果的です。

ContributorとInformedの立ち位置を明確にする

Driverのアウトプットに想像力をかき立てられ、「ほかにこんなデータ分析をできないか？」「ここをもっと深く知りたいからさらに分析してほしい」など、本来の目的から逸脱する意見や要望が大量に発生することがあります。

要望が生まれること自体は良いことです。しかし、すべての要望に応えようとすると、Driverがやるべき本来の業務ができなくなります。そこで、業務を円滑に遂行するために、DriverとApprover以外の人々の役割を明確にする必要があります。

ポイントは、Informedの人々に対して、役割と責任範囲を理解してもらうように調整することです。それでも物申したい人がいる場合は、Contributorに取り込んで業務メンバーに組み込んでしまうのも方法の1つです。

役割の移動を原則禁止する

DACIモデルの失敗事例で多いケースは、業務の途中で役割が変わってしまい、さらなる混乱を招くケースです。業務が遂行できない状況でない限り、DACIモデルの役割の移動は原則禁止というルールを徹底することが重要です。

ミーティングの冒頭で役割の確認をしたり、関係者の人数を減らしてステアリングコミッティのような業務体制にしたりするのもよいかもしれません。

要件定義を明確にするPRDのススメ

プロダクトマネジメントの業務では、担当するプロダクトの要件を整理するPRD（Product Requirements Document：プロダクト要求仕様書）というフォーマットがあります。プロダクト開発はPRDをベースに行 われています。

データ可視化業務においても、PRDフォーマットを用いて要件定義をすることは非常に効率が良く、有用です。そのためぜひとも活用していただきたい方法です。

データ可視化業務の開始時点でPRDを用意することで、関係各所の合意形成を促し、認識齟齬の点を調整することでアプトプットの質を高めることができます。

データ可視化業務の終了後、ダッシュボードやレポートが運用に乗った段階にもPRDは役立ちます。関係者以外がダッシュボードやレポートの設計や可視化の意図を汲み取るには、担当者に質問するよりも、PRDを読んで理解した方が圧倒的にコミュニケーションコストを下げることができます。このように、データ可視化業務の成果物であるダッシュボードやレポートとは別に、成果物としてPRDをドキュメントとして残しておくことをおススメします。

PRD構成例

表に示した「5W3H」を踏襲して基本構成の設計をすると、要件定義で必要な要素を網羅できます。

重要なのは「Why」を明確にすることです。その最大の理由は、一般的に、データ可視化業務の成果物であるダッシュボードやレポートに「なぜ、このデータを可視化したのか？」「なぜ、この分析をしたのか？」の意図を表現することが困難であるからです。

PRDを利用した要件定義プロセスの例

データ可視化業務にPRDを用いた要件定義プロセスを組み込むメリットに 、認識やアウトプットイメージの齟齬に由来する差し戻し工数を最小限に抑えられる点があります。

唯一のデメリットは、プロセス工数を必要とすることです。そのため、アドホックレポートのような速度を優先するような業務には向いていません。

要件定義フェーズ

要件定義フェーズでは、最初から完璧なPRDを作るのではなく、細かいレビューと修正を重ねて作り上げていくことが重要になります。昨今、ビジネス側の要件や要求が複雑化していくなかで、一度のヒアリングで完璧なPRD・ダッシュボード・レポートを用意することは困難です。

また、問題が発生した際のダッシュボードやレポートを作成した後の手戻りよりも、それらの作業前の段階での手戻りの ほうが はるかにダメージは少なくなります。ですので、PRD作成段階で課題をクリアにしておくことが大事です。

PRDを作成したらデータ可視化業務にすぐに移行してもよいのですが、PRDを基にサンプルやモックアップを作成することをオススメします。PRDのみだと、データ可視化のイメージが湧かないことも多いです。担当者間の理解の解像度を上げ、より精緻なアウトプットを提供するために、この段階でサンプルやモックアップがあるとスムーズに業務が遂行できます。

筆者は、PRDにはGoogle Docs、Notion、Confluenceを、サンプルやモックアップにはFigma、Whimsicalといったツールを利用しています。これらのツールはWebブラウザで完結し、複数のユーザーでコラボレーションできて作業効率が上がるので便利です。

もちろん、現場や企業のレギュレーションといった事情もあるので、自分に合ったツールの選定も重要です。

モックアップは落書き程度でも伝わればOK。これはiPadのメモアプリで作成したもの。

Figmaなど、デザインツールを用いるとデータ可視化の解像度が増す。

データ可視化フェーズ

データ可視化フェーズについて述べることは特にはありません。要件定義がない状態のデータ可視化と比べるとやるべきことが明確になっていて、詰まったり手戻りが発生したりといったデータ可視化に直接関連したもの以外の悩みが減るはずです。

それでも問題が発生した場合は、PRDの再検討に戻る選択肢もあります。PRDに問題があるケースは、筆者の実務上では稀でしたが、思い切って戻ることもあると関係者と合意をとっておくのも大切です。

タイムマネジメントが最重要

ここまではフレームワークやテンプレートによる業務の円滑化をはかる施策を紹介しました。ですが、データ可視化業務を行う上で最も重要なポイントは、時間の認識を関係者間で合意することです。

• ・依頼をする人は、決めた納期を超えるような追加依頼はしない
• ・依頼を受けた人は、納期内に収まらない依頼を受けない
• ・納期を超えてしまうような場合は、優先度を定義して、やらないタスクについて合意すること

タイムマネジメントを担当する 役割を担うのはDriverやApproverの人の場合が多いですが、これらの人は業務過多に陥りがちです。タイムマネジメントが破綻することも多いので、他の役割の人が意識的にサポートする体制を構築しておくとよいです。

まとめ

• ・データ可視化に関わる人々の役割を整理してみましょう
• ・要件定義を用意して効率良いデータ可視化業務を目指してみましょう
• ・PRDを使うと捗ります
• ・モックアップもあると関係者の解像度が上がります
• ・タイムマネジメントは最も重要！

BIツールのアハ!体験⑤ビジネスの命運を分けるアウトプット

私がデータアナリストを志したときに決めたルールは、「エグゼクティブ層やマネジメント層を支える作戦参謀となる 立ち回り」を意識することを目指しています。

言葉にするのは簡単ですが、これがなかなかうまくいかないことが多く、日々、挫折・反省・実行の繰り返しです。例えば、レポート・ダッシュボードを100個作成しても、意思決定につながるものは1個あるかないか。なかなかうまくいきません。

それでもビジネスの命運を分けるアウトプットを編み出した際には、この上ない至高の体験として、記憶にも記録にも残っていきます。その体験が忘れられなくてデータアナリストという職と、BIツールの利用をやめることができないのでしょう。

この記事を書いた方
株式会社エウレカ 荒木 和也さん
1982年神奈川県生まれ。受託開発エンジニア、自社パッケージ開発エンジニア、BIツールのプロダクトマネージャーを経て、2017年株式会社ビズリーチでデータアナリストに従事。2020年現職。専門はデータ基盤設計/運用、BIツールの整備/エバンジェリング。BIツール研究所は2019年より参画。
Twitter：https://twitter.com/kazuya_araki_jp
note: https://note.com/jedi_trickstar