INDEX
「データアナリストにデータ可視化を依頼したいが、何をすればいいのかわからない」
「データ可視化を依頼されたが、依頼内容が曖昧なのに差し戻しが多くて困っている」
昨今、専門知識のない利用者が自分で分析・レポート作成をできるセルフBI（Business Intelligence）ツールが発展してきました。これにより、スキルの有無や職責を問わず、データ可視化がより簡易になっています。一方で、BIツールにまつわる業務や課題は複雑多岐にわたり、難易度が高まってきています。
この記事では、BIツールを用いた可視化を依頼する際・依頼される際におさえておきたい要件定義のポイントについて解説します。
データ可視化業務を遂行する上での課題には以下のようなものがあります。
など
データ可視化業務を成功に導くにはこれらの課題に立ち向かう必要があります。その方法として、ここからは要件定義の重要性を提案していきます。
なお、要件定義の方法論については、プロジェクトマネージャーや、プロダクトマネージャーの要件定義の方法論と合致しています。本記事ではデータ可視化業務における要件定義の方法論について述べます。
要件定義の前段として、まずは役割の話をします。データ可視化に携わる関係者が多ければ多いほど、組織やプロジェクトチームに次のような混乱を生じる危険性があります。
など
こうした混乱を招かないようにするには、関係者の役割や責任範囲を明確にし、業務を円滑に遂行できる体制づくりが必要です。そこで、DACI（ダキ）モデルとよばれるフレームワークを用いて、このような課題を事前に解消する仕組みを作ることをおススメします。
DACIモデルは、ソフトウェア会社のIntuit社が1980年代に開発した意思決定フレームワークです。DACIとは特定の役割を示す単語の頭文字で、以下の4つで構成されています。
| DACIモデルの呼称 | データ可視化に携わる人の役割 | 説明 |
|---|---|---|
| Driver | データ可視化実行者 | データ可視化を実施する人。要件定義からアウトプットまでを高速で展開する役割をもつ。 |
| Approver | 意思決定者またはデータ可視化依頼者 | Driverの結果を用いて意思決定する人。結果に対して責任を持つ。 |
| Contributor | データ可視化実行者補佐 | Driverのアウトプットに対して品質を上げる人。環境構築やレビューに携わる。 |
| Informed | 結果を知らされるだけの人 | 上記の役割の人から結果を共有してもらい、自身の業務に組み込んでいく人。決定事項に関しては何の権限も持たない。 |
データ可視化を行う人と、意思決定者が同一人物の場合、抜け・漏れや見落とし、データの改竄といった事態が容易にできてしまうことがリスクになります。
人数が少ない場合、DriverとApproverを同一人物が担当せざるを得ないかもしれません。その場合はレビュワーとしてContributorを立ててリスクを回避する対策が効果的です。
Driverのアウトプットに想像力をかき立てられ、「ほかにこんなデータ分析をできないか？」「ここをもっと深く知りたいからさらに分析してほしい」など、本来の目的から逸脱する意見や要望が大量に発生することがあります。
要望が生まれること自体は良いことです。しかし、すべての要望に応えようとすると、Driverがやるべき本来の業務ができなくなります。そこで、業務を円滑に遂行するために、DriverとApprover以外の人々の役割を明確にする必要があります。
ポイントは、Informedの人々に対して、役割と責任範囲を理解してもらうように調整することです。それでも物申したい人がいる場合は、Contributorに取り込んで業務メンバーに組み込んでしまうのも方法の1つです。
DACIモデルの失敗事例で多いケースは、業務の途中で役割が変わってしまい、さらなる混乱を招くケースです。業務が遂行できない状況でない限り、DACIモデルの役割の移動は原則禁止というルールを徹底することが重要です。
ミーティングの冒頭で役割の確認をしたり、関係者の人数を減らしてステアリングコミッティのような業務体制にしたりするのもよいかもしれません。
プロダクトマネジメントの業務では、担当するプロダクトの要件を整理するPRD（Product Requirements Document：プロダクト要求仕様書）というフォーマットがあります。プロダクト開発はPRDをベースに行 われています。
データ可視化業務においても、PRDフォーマットを用いて要件定義をすることは非常に効率が良く、有用です。そのためぜひとも活用していただきたい方法です。
データ可視化業務の開始時点でPRDを用意することで、関係各所の合意形成を促し、認識齟齬の点を調整することでアプトプットの質を高めることができます。
データ可視化業務の終了後、ダッシュボードやレポートが運用に乗った段階にもPRDは役立ちます。関係者以外がダッシュボードやレポートの設計や可視化の意図を汲み取るには、担当者に質問するよりも、PRDを読んで理解した方が圧倒的にコミュニケーションコストを下げることができます。このように、データ可視化業務の成果物であるダッシュボードやレポートとは別に、成果物としてPRDをドキュメントとして残しておくことをおススメします。
表に示した「5W3H」を踏襲して基本構成の設計をすると、要件定義で必要な要素を網羅できます。
重要なのは「Why」を明確にすることです。その最大の理由は、一般的に、データ可視化業務の成果物であるダッシュボードやレポートに「なぜ、このデータを可視化したのか？」「なぜ、この分析をしたのか？」の意図を表現することが困難であるからです。
| 5W3H | タイトル | 内容 |
|---|---|---|
| Why（なぜやるのか？） | 対象 | データ可視化を行う明確な理由を明記する。 |
| Who（誰のためにやるのか？） | 意思決定者またはデータ可視化依頼者 | データ可視化をすることで恩恵を受ける人々を明確にする。 |
| What（何をするのか？） | 概要 | どんなデータ可視化を行うのかを概要レベルで記載する。 |
| Where（どこでやるのか？） How（どうやってやるのか？） | 技術要件 | BIツール、IDEなど、データ可視化で使用するツール、実施環境を記載する。 |
| When（いつまでにやるのか？） How many|long（どのくらいの工数がかかるのか？） | リリーススケジュール マイルストーン | 具体的な実施期間と納期を記載する。 |
データ可視化業務にPRDを用いた要件定義プロセスを組み込むメリットに 、認識やアウトプットイメージの齟齬に由来する差し戻し工数を最小限に抑えられる点があります。
唯一のデメリットは、プロセス工数を必要とすることです。そのため、アドホックレポートのような速度を優先するような業務には向いていません。
要件定義フェーズでは、最初から完璧なPRDを作るのではなく、細かいレビューと修正を重ねて作り上げていくことが重要になります。昨今、ビジネス側の要件や要求が複雑化していくなかで、一度のヒアリングで完璧なPRD・ダッシュボード・レポートを用意することは困難です。
また、問題が発生した際のダッシュボードやレポートを作成した後の手戻りよりも、それらの作業前の段階での手戻りの ほうが はるかにダメージは少なくなります。ですので、PRD作成段階で課題をクリアにしておくことが大事です。
PRDを作成したらデータ可視化業務にすぐに移行してもよいのですが、PRDを基にサンプルやモックアップを作成することをオススメします。PRDのみだと、データ可視化のイメージが湧かないことも多いです。担当者間の理解の解像度を上げ、より精緻なアウトプットを提供するために、この段階でサンプルやモックアップがあるとスムーズに業務が遂行できます。
筆者は、PRDにはGoogle Docs、Notion、Confluenceを、サンプルやモックアップにはFigma、Whimsicalといったツールを利用しています。これらのツールはWebブラウザで完結し、複数のユーザーでコラボレーションできて作業効率が上がるので便利です。
もちろん、現場や企業のレギュレーションといった事情もあるので、自分に合ったツールの選定も重要です。
モックアップは落書き程度でも伝わればOK。これはiPadのメモアプリで作成したもの。
Figmaなど、デザインツールを用いるとデータ可視化の解像度が増す。
データ可視化フェーズについて述べることは特にはありません。要件定義がない状態のデータ可視化と比べるとやるべきことが明確になっていて、詰まったり手戻りが発生したりといったデータ可視化に直接関連したもの以外の悩みが減るはずです。
それでも問題が発生した場合は、PRDの再検討に戻る選択肢もあります。PRDに問題があるケースは、筆者の実務上では稀でしたが、思い切って戻ることもあると関係者と合意をとっておくのも大切です。
ここまではフレームワークやテンプレートによる業務の円滑化をはかる施策を紹介しました。ですが、データ可視化業務を行う上で最も重要なポイントは、時間の認識を関係者間で合意することです。
タイムマネジメントを担当する 役割を担うのはDriverやApproverの人の場合が多いですが、これらの人は業務過多に陥りがちです。タイムマネジメントが破綻することも多いので、他の役割の人が意識的にサポートする体制を構築しておくとよいです。
私がデータアナリストを志したときに決めたルールは、「エグゼクティブ層やマネジメント層を支える作戦参謀となる 立ち回り」を意識することを目指しています。
言葉にするのは簡単ですが、これがなかなかうまくいかないことが多く、日々、挫折・反省・実行の繰り返しです。例えば、レポート・ダッシュボードを100個作成しても、意思決定につながるものは1個あるかないか。なかなかうまくいきません。
それでもビジネスの命運を分けるアウトプットを編み出した際には、この上ない至高の体験として、記憶にも記録にも残っていきます。その体験が忘れられなくてデータアナリストという職と、BIツールの利用をやめることができないのでしょう。
この記事を書いた方
株式会社エウレカ 荒木 和也さん
1982年神奈川県生まれ。受託開発エンジニア、自社パッケージ開発エンジニア、BIツールのプロダクトマネージャーを経て、2017年株式会社ビズリーチでデータアナリストに従事。2020年現職。専門はデータ基盤設計/運用、BIツールの整備/エバンジェリング。BIツール研究所は2019年より参画。
Twitter：https://twitter.com/kazuya_araki_jp
note: https://note.com/jedi_trickstar
メルマガ登録をしていただくと、記事やイベントなどの最新情報をお届けいたします。
30秒で理解！インフォグラフィックや動画で解説！フォローして『1日1記事』インプットしよう！
メール会員でできること
