はじめに
本記事は、Googleデータアナリティクスのプロフェッショナル認定証のプログラムより、参照させて頂いています。興味を持った方は、是非受講してみてください。
課題解決の前に、まずは課題を理解する
その昔、 アルバート・アインシュタインは、 「もし私が地球を救うために 1 時間与えられたとしたら、 59 分を課題の定義に、 1 分をその解決に費やすだろう」と 言いました。 この言葉は極端に思えるかもしれませんが、 課題を解決する前に、 課題を定義することが いかに重要かを示しています。 すぐにデータ分析に取りかかった結果、 チームが間違った課題解決に取り組んでいる、 あるいは適切なデータを持っていないと 数か月後に気づくということは よくあります。
最初から課題を明確に定義しておけば、 解決が容易になり、 多くの時間、費用、リソースを 節約できます。 データアナリストの世界では、 この最初のピースを 課題領域と呼びます。
『課題領域とは、課題に影響を与える、 あるいは影響を受けるすべてを含む 特定の分析領域のこと』
何よりも先に、 まず課題領域とそれに関連するものの 関係性を理解し、 全体のストーリーを把握することが 必要になります。
最初のピースと言えば、 ジグソーパズルを思い浮かべますね。 例えば、あるパズルがあったとします。 そのパズルを課題領域と考えましょう。 500 個のピースはすべて揃っているものの、 箱を紛失してしまいました。 そのため、パズルの完成図が わかりません。 動物でしょうか？ それとも滝？ オレンジ入りのカゴでしょうか？ どんなものであれ、 参考にできるイメージがないと、 組み立てるのは難しいでしょう。 この宇宙で最も優れた パズル名人でさえ、 そのパズルを完成させるには 新たなプロセスと 多くの時間が必要なはずです。
データアナリストも同様の 課題に直面しています。 データアナリストが必ずしも、 プロジェクト開始時に全体像を 把握できているわけではないことは、 記憶に新しいと思います。 データアナリストの仕事の多くは、 構造化されたアプローチを用いて、 クリティカル シンキングを駆使し 最適な解決策を見出すことです。 そのためには、まず課題領域を 理解することが第一歩です。 ここで構造化思考が活躍します。
作業範囲（SOW）と構造化思考
『構造化思考とは、 現在の課題や状況を認識し、 利用可能な情報を整理し、 ギャップや機会を明らかにし、 選択肢を特定するプロセスのこと』
ビジネスの世界では、 チームが重要な課題を解決するために 貴重な時間を何時間も費やしても、 結局は振り出しに戻ってしまうことが よくあります。 最初にあった課題が 解決されていないだけでなく、 解決しないまま何時間も費やしているのです。 このような結末はあなたやあなたのチーム、 そして組織全体に悪影響を及ぼします。 しかしそれらは大抵、未然に防げるのです。 多くの場合、課題を十分に 理解していないことが原因で起こります。
構造化思考では、課題を 高度なレベルで理解し、 より深いリサーチと理解が必要な領域を 特定する ことができます。
課題領域(Problem domain)
構造化思考の出発点は、 「課題領域」です。 具体的な分析領域が理解できれば、 調査を開始する前に、基礎を固め、 すべての要件と仮説を 並べることができます。 基礎がしっかりしていれば、 どのような障害が出てきても 対処できるようになります。 では、どんな障害があるでしょうか？
- 例えば、あるマンションの 将来の価値を予測するように 依頼されたとします。 何百もの変数があり、 そのひとつひとつが分析に欠かせません。 しかし、例えば面積といった、 ある変数が誤って省かれてしまったら どうでしょうか？ せっかくの作業を やり直さなければならなくなります。 変数が抜けると、 誤った結論につながりかねません。
作業範囲(SOW,Scope of work)
構造化思考を実践し、ミスを回避するための もうひとつの方法は、 「作業範囲」の考え方です。
『作業範囲とは プロジェクトで実行する 合意されたタスクの概要のこと』
多くの企業において、 SOW にはタスクの詳細や スケジュール、顧客が期待する レポートなどが含まれます。 データアナリストの場合、 業務範囲はより技術的なものです。 基本的な部分だけでなく、 データの準備、検証、 定量・定性データの分析、 初期分析結果、そして、 ポイントを伝えるために 可視化することなども含みます。
ここで簡単な例を用いて 業務範囲について具体的にご説明しましょう。 あるカップルがウェディングプランナーを 雇ったとします。 ここでは、
- 結婚式への参加者招待
という 一つの作業だけに焦点を当てます。 作業範囲として含むべきなのは、 成果物、タイムライン、マイルストーン、 そしてレポートです。
- まずは、成果物について考えてみましょう。 ウェディングプランナーとカップルは、 どのような招待状にするかを決め、 招待する人のリストを作成し、住所を集め、 招待状を印刷し、封筒に宛名を書き、 切手を貼って、郵送する必要がありますね。
- 次はタイムラインについて考えてみましょう。 日付とマイルストーンは、 計画通りに進めるためのものです。
- 最後に、各ステップがいつ完了したか レポートにすれば、必要なことは完了していると カップルを安心感させることができます。
作業範囲の定義はシンプルなものでも 大きな影響力を持ちます。 しっかりとした作業範囲があれば、 データに関する混乱や矛盾、 疑問を前もって解決することが できるとともに、 進捗が滞るのを防げます。
作業指示書（Statement of Work）と作業範囲（Scope of Work）を混同しないようにしましょう。
どちらも SOW と略され、どちらも成果物やスケジュールを定義するために使用されますが、同じものではありませんし、同じように使用されるべきではありません。
作業指示書とは、ベンダーや請負業者が組織に提供する製品やサービスを明確に特定するための文書です。ここには目的、ガイドライン、成果物、スケジュール、コストなどが含まれます。
一方、作業範囲は、プロジェクトベースで、プロジェクトの期待値と境界線を設定するためのものです。作業範囲は、プロジェクトの成果を定義するために、作業指示書に含まれることもあります。
SOW
なぜ、SOW が必要なのか
データ分析プロジェクトの目的は、ステークホルダーにとって有益な事業タスクを完了することです。SOW を作成することで、アナリストやエンジニア、マネージャー、ステークホルダーなど、関わる人全員がビジネス上の目標は何かや、それを達成するための計画について共通認識を持つことができます。
要件を明確にし、期待値を設定することは、プロジェクトにおいて最も重要なことの一つです。データ分析プロセスの最初の段階である「問いかけ」を思い出してください。
要件、目標、データソース、ステークホルダー、その他関連情報を明確にするための問いかけを重ねる際、SOW はすべての回答と詳細の記録し、形式化することができます。ここでいう「問いかけ（ask）」には 2 つの意味があります。
- まずは SOW を作成する準備にあたってプロジェクトについて必要な情報を得るために問いかけること、
- それと同時に、何を達成するように求められているのか、その「依頼（ask）」の限界や境界線はどこなのかを明確にし、定義すること
でもあるのです。つまり、そのビジネス上の問いかけに対して、あなたが実際に答える責任があるのかないのか、それを区別できなければ、成功を定義することはできません。
よい SOW とは
SOW には標準的な書式はありません。組織やプロジェクトによって大きく異なる場合がありますが、いくつかの基本的な内容は共通しています。
成果物：プロジェクトの成果、どのような作業が行われ、何が生み出されるのかを指します。プロジェクトが完了したとき、ステークホルダーに何を納めることが期待されているでしょうか？
このプロジェクトではデータを収集するのか、その場合どれくらいの量、期間、データを収集するかなど、具体的に書きましょう。
曖昧な表現は避けましょう。例えば「交通問題の解決」では、範囲が特定されていません。道路の穴埋めから新しい高架橋の建設まで、あらゆることが考えられます。数字を使い、測定可能な目標やゴールを具体的に設定しましょう。例えば
- 「市域内の交通規則に関する問題点トップ 10 の特定および、交通渋滞を緩和するために最も費用対効果の高い解決策トップ 3 の特定」
などです。
マイルストーン：これはタイムラインと密接に関係しています。プロジェクトの進捗を示す主なマイルストーンは何か、プロジェクトの一部分を完了したとみなすタイミングはどのように把握するか、などがあります。
マイルストーンは、あなた自身やステークホルダー、またプロジェクトマネージャーなど他のチームメンバーによって定められることもあります。例えば
- 「必要なデータの 50%（ 100 件のアンケート回答）の収集・処理」
- 「初期データ分析レポートを完成させる」
- 「完成したダッシュボードの可視化と分析レポートをステークホルダーに提供する」
タイムライン： タイムラインは、プロジェクトのために作成したマイルストーンと密接に連携します。これは各ステップにどれくらいの時間がかかるかを予想するためのものです。プロジェクトが予定通りに進んでいるか、関係者全員が判断できるように、タイムラインは具体的にしましょう。
成果物はいつ完成するのか、プロジェクトが完了するまでの期間はどのくらいを想定しているか、計画通りに進んだ場合、プロジェクトの各要素にそれぞれどれくらいのかかると予想されるか、あるいは各マイルストーンの達成はいつ頃になると予想されるか、などです。
レポート： よい SOW は、ステークホルダーにいつ、どのように状況を報告するかという基準も定めています。ステークホルダーやスポンサーと進捗状況をどのように、どれくらいの頻度でやり取りするのか、進捗は毎週報告されるのか、それはマイルストーンが完了したときなのか、進捗報告にはどのような情報が含まれるか、などです。
SOW は最低限、上記の点に関連する問いかけに対する答えとなる必要があります。これらの領域は、プロジェクトによって異なる可能性があることに注意してください。
肝心なのは、SOW 文書がその目的を果たすよう、具体的かつ適切で、正確な情報を含むようにすることです。プロジェクトで何かが変更された場合、SOW はそれらの変更を反映する必要があります。
何が業務範囲内で、何が範囲外なのか
SOW には、何がプロジェクトの一部とみなされ何がそうでないのか、具体的な情報を記載する必要があります。
プロジェクトの範囲とは、完了または達成することが期待されているすべてのことであり、あるタスクやアイテムがプロジェクトの一部であるかどうかについて、曖昧さや混乱のないよう詳細なレベルで定義されます。
- 先ほどの交通渋滞の例では、市域を範囲として定義していることに注目してください。ステークホルダーは、地図を見て、ある道路や交差点がプロジェクトの一部となるかどうかを判断する必要があるのです。
要件を定義するのは意外と難しいものです。文書ではできるだけ具体的に、そして可能な限り定量的に記述することが重要です。
- 例えば、ある都市の海岸線の気候変動による環境の影響を調査するプロジェクトを担当することになったとします。海岸線のどの部分を担当し、どの部分を担当しないかをどのように定義すればよいでしょうか。この場合、GPS の位置や 目印を活用して、調査範囲となる地域を定義することが重要です。具体的かつ定量的な記述をすることで、全員が何を期待されるかを明確に理解することができます。