データ分析プロジェクトの進め方
システム開発プロジェクトの経験はあっても、データ分析プロジェクトの経験のない業務担当者やシステム担当者は多いと思います。システム開発プロジェクトでは、プロジェクトの各フェーズにおける作業や成果物が比較的明確であり、ソフトウェア開発方法論も確立されているため、プロジェクトの進め方は容易に想像がつきます。一方で、データ分析プロジェクトについて標準的手法として確立したものはあまり浸透していません。しかし、多くのプロジェクトはデータマイニングの標準プロセスのひとつである、CRISP-DM（参照2）に近い進め方で行われていることが多いように見受けられます。ここでは、そのCRISP-DMをベースに、金融機関における不正検知のためのデータ分析プロジェクトの進め方について説明します（図1）。
1．業務の理解 (Business Understanding)
データの取り扱いをはじめる前に、最も重要なことは不正検知の分析対象の業務をよく理解することです。これは分析上の多くの気づきにつながります。具体的には、業務担当者にヒアリングを行ったり、業務マニュアルを読んだりしながら、As-Isの業務フロー図を描き業務課題を整理する、といった作業を実施します。不正検知モデル構築プロジェクトの場合は、さらにTo-Beの業務フロー図も描いた上で、モデルの利用方法について分析者、業務担当者、システム担当者の3者でよく認識合わせを行います。この作業によって、運用時にモデルを利用するタイミングでは取得できないデータを、分析時に誤ってモデルの入力データとして定義しないようにするなど、後続作業の手戻りを防ぐ効果があります。
2．データの理解 (Data Understanding)
このフェーズでは、業務がどのようにデータに落としこまれているのかを確認します。いつ、誰が、どのような不正を行い、最終的にどう処理されたのか、それらを追うためのデータ項目は何かを整理します。具体的には、まずテーブル定義書などに基づき分析の対象となり得るデータを洗い出します。次にシステムからデータを取得し、金額や回数などの数量データに対しては要約統計量、コードや属性などのカテゴリデータに対しては一元度数表を作成し、データがどのような状態で入力されているのかを確認します。時にはデータそのものをただひたすら眺めて、データの入り方の特徴や癖を捉えようとすることもあります。金融機関ごとにデータの持ち方は様々ですし、既存システムから取得したデータは本来データ分析を行うことを想定しているわけではないため、そのままの状態では分析に利用できないノイズが混在することもあります。このようなデータ上の問題点を整理し、対応方針を検討します。
3．データの準備 (Data Preparation)
整理したデータ上の問題についての対応方針をプログラム化し、データが分析可能な状態となるようクレンジング処理を実施します。また、日付データをある基準日からの日数データに変換したり、カテゴリ数が多い変数のカテゴリを集約したりするなど、分析に利用可能な状態にデータを加工します。さらに、不正を判別する上で有効と考えられる仮説を設定し、複数の変数を組み合わせて仮説をデータ化した加工変数の生成も行います（図2）。不正検知モデル構築を実施する際に、ターゲットとなる不正判別に必要なデータが、フラグのような構造化されたデータではなく、フリーフォーマットのテキストファイルで管理されている場合は、テキストからフラグデータへの変換作業も実施します。
4．モデルの構築 (Modeling)
ようやく統計的手法によるデータ分析のフェーズになりますが、実際はほとんどの作業をデータマイニングツールが自動でやってくれるため、分析者の仕事は適切な分析手法を選択し、ツールにパラメータの設定を行う程度です。
5．評価 (Evaluation)
分析によってどのくらいの不正を検知できるかは残念ながら事前には分かりません。分析の結果、不正が見つからないこともあります。このとき、本当に不正が存在しないのか、もしくはデータ上から見つけられないだけで実は不正が隠れて存在している可能性があるのか、両面から注意深く評価する必要があります。不正が存在するものの、検知できなかったと思われる場合は、今後どのような施策を行い、どのようなデータを更に集める必要があるのかを考察します。逆にモデルを構築した際に不正検出精度が高すぎると思われる場合は、分析手順や使用したデータに誤りがないかを再確認する必要があります。また、モデルのアウトプット（多くの場合、点数や確率の値）の閾値設定を検討したり、期待されるコスト削減効果の算出を行ったりすることもこのフェーズで実施します。
6．適用 (Deployment)
データ分析から得られた知見を業務的な意思決定に反映し、構築した不正検知モデルをシステムに実装して運用を開始するフェーズです。分析結果からどのような業務施策を打つ必要があるのかを業務部門に正しく伝えるためには、業務知識が必要です。一方で、モデルをプログラム化しシステムでの利用方法をシステム部門に正しく伝えるためには、ITスキルが必要です。データサイエンティストが統計分析スキルだけでなく、業務知識とITスキルも必要であるといわれるのは、これらの関係者間の橋渡しをするという役割を担っているからなのです。
７．文書化 (Documentation)
文書化は標準のCRISP-DMのプロセスには含まれていませんが、様々な規制や法令の対応が求められる金融機関においては必須のプロセスです。ドキュメントにはデータ分析プロジェクトを実施した際の体制や、分析に利用したデータに関する情報（データベース上のテーブル名やデータ取得期間など）、またプロジェクトの各プロセスで実施した作業や様々な判断の根拠を詳細に記述します。通常の監査においては正しく文書化ができていなければ、何もしていないことと同じだとみなされてしまうため、注意が必要です。
図1に示したように、これらのプロセスは、サイクルの中で反復して行われます。モデルの構築フェーズでデータの不備に気づき、分析用データを作成しなおしたり、評価の段階で新たな業務上の気づきが生まれ、必要なデータを集めなおしたりすることもあります。実際にはプロジェクトの期間は固定で、限られている場合が多いため、プロジェクトマネージャーはある程度の反復が発生することを見越してスケジュール管理を行います。
データサイエンティストには、統計分析スキルだけでなく、業務知識、ITスキルが必要と書きましたが、本当はもっと大切なことがあります。コミュニケーション能力です。どんなによい分析結果であっても、その意味を伝えることができなければ意味がありません。今回紹介したデータ分析の各プロセスをしっかりと押さえることは基本ですが、不正という深刻な課題を解決するために、プロジェクトを通じてデータ分析者が業務担当者やシステム担当者とよく対話し、寄り添うことがプロジェクトを成功させる最も重要なコツであると筆者は考えています。
次回は、金融機関におけるモデル管理について米国の例を紹介しながら解説します。
参照1: 衆議院予算委員会第2分科会第190回議事録
http://www.shugiin.go.jp/internet/itdb_kaigiroku.nsf/html/kaigiroku/003219020160225001.htm
参照2: Wikipedia / Cross Industry Standard Process for Data Mining
https://en.wikipedia.org/wiki/Cross_Industry_Standard_Process_for_Data_Mining
