データサイエンス案件とアジャイル② DSに適したアジャイル詳細
データサイエンス案件とアジャイルについて。
前回に各手法についてざっと取り上げた。
- 作者:ＪｏｎａｔｈａｎＲａｓｍｕｓｓｏｎ,西村直人,角谷信太郎
- 発売日: 2017/07/14
- メディア: Kindle版
アジャイルにデータサイエンス案件をやる
アジャイルの哲学は 「不確実性をなくす」ために、考えられる全てのことを見える化・推定・認識のすり合わせをおこなうことで、できるだけその時点での不確実な要素の不確実性を除去して、クライアント・メンバーが満足するものを提供する こと。
そのため、基本的な流れは、アジャイルのところに書いた
具体的には、「インセプションデッキの作成」「ユーザーストーリーの作成」「工数概算見積もり」「計画づくり」といった準備のもと、毎スプリントで「各ストーリーの設計(深堀り)」「開発」「成果物発表」「フィードバック」という手順をおこなっていく。
のままで問題ないと思う。一方でデータサイエンス*1案件では、大枠で考えると「要件定義」に関する部分はソフトウェア開発でおこなうことがそのまま使えるが、「開発」および「成果物発表」はアレンジが必要になる。また「開発」にアレンジが加わるので連鎖的に「工数概算見積もり」「計画づくり」もアレンジが必要になる。
CRISP-DM/KDDとの対応
CRISP-DMの「ビジネス理解」はアジャイルの「インセプションデッキの作成」「ユーザーストーリーの作成」、「各ストーリーの設計(深堀り)」に相当する。
また、「データ理解」「データ準備」(= KDDの「データ獲得」「データ選択」「前処理」「変換」)「モデリング」が「開発」に、「解釈・評価」「共有・展開」が「成果物発表」「フィードバック」に相当する。
そのため、CRISP-DM/KDDを結合した以下のようなフローを考える。
開発
開発に関してソフトウェア開発では各ソフトの機能実装を優先順位に基づいてスプリントに入れていく。分析では機能は分析結果を出す以外はない。そのため、各スプリントではその「分析」をおこなうための各フローをおこなっていく。
より具体的には、下図の各フローの中身をユーザーストーリーベースで考えていくことになる*2。
また、この分析フローは結果を踏まえて何周も回す必要がある。何周もする前提なので、はじめから完璧なモデルを作成するのではなく、まずはベースラインとなる最低限動くモデルを作成し、成果物を発表しフィードバックをもらいその意見を反映しつつ徐々にリッチなモデルへと変えていく*3。
このように、フィードバックをもらうことを前提にしつつ周回をしていくので、1周 = 1スプリントと置くほうが都合が良いのでスプリント期間は1周にかかる期間に応じて考える。
なお、機械学習の場合は以前記事に書いたフローで考えた方がよさそう。
テスト駆動開発
開発する際に、やることは以下の4点となる。
- コードを書く
- テストをする
- リファクタリングをする
- レビューをする
データ分析では前述の分析フローを何周もするという性質上、 同じコードをある程度使いまわしていく。そのため、「テスト」「リファクタリング」「レビュー」が非常に重要となる。
例えば、前処理の「テスト」および「（テストに対する)レビュー」がテキトーだと、何周もした後に前処理がミスをしていたら今まで見ていたモデルの結果が全て意味のないものとなる。
また、同じコードに追加する、例えば前回前処理してできた変数をもとに追加の変数を作成したり、モデルの処理の一部を変えたり、といったことをする際にコードがきたないと追加をする際に非常にコストがかかるので「リファクタリング」および「（リファクタリングに対する）レビューが必要になる。
つまり、1開発につき「テスト」「リファクタリング」「レビュー」はセットでおこなっていく。
そのため、「テスト」「リファクタリング」を素早く回すためにアジャイルサムライで言及されているようにデータ分析でもテスト駆動開発をおこなった方がよい。
前処理・後処理部分でのテストは結局のところ「想定通りのデータとして処理できているか」の検証になるので、元データなどをもとにシンプルなダミーデータを作成してそのデータをもとにテストをおこなう。
ここでのやり方は現在考えているのでそのうち記事にまとめるが、Rの場合はassertを仕込むとテストがおこないやすいし、tidylogを使うと各tidyverse系の処理の過程がわかりやすくなるためこれらを使っておこなっていく。
モデル作成部分はテストのしようがないのでsummaryなどで係数の漏れやパラメータ指定の確認をする程度で、基本的にはレビュー任せか？
工数概算見積もり・計画づくり
前述のように「開発」は、分析結果を出す以外がないのでソフトウェア開発のように優先順位を基に決めることができず、分析フローに沿ったtodoを必要に応じて何周も回す必要がある。
つまり、データサイエンスでは何周するかで工数が変わる。そのため分析は工数が見積もりづらいので「工数概算見積もり」「計画づくり」をアレンジする必要がある。
具体的には分析フローを1周するときに各工程がどれくらいの工数が必要になるのかを見積もる。
そして「計画づくり」は、1周が作業量Xだとするとn周回したら作業量がnXになることをベースに考える。なお、一番初めの周は0から作るので作業量が多く、以降の周回は1周目のコードに手を加えていくことを考えると1周目よりも作業量が少ないことが多い。そのため前者を、後者を
とすると全体作業量は
となる。
ここから、「期限がxxxならn周回すことができる」「n周は最低限必要なので早くてxxxまでにはできあがる」という計画を作成する。
なお、実際は新たなデータを取得せずに既存データを変換して変数を増やしたりモデルを変えることが多く「データ理解」「データ獲得・選択」が発生しない周も多くなることが考えられるので1周目以外のはこれらを抜いた「前処理・モデリング」「解釈・評価」のみの労働量ではじめの計画づくりをした方が良いように思える*4。
また、以前紹介した Data Science and Agile: What works and what doesn’t work で言及されているように、分析では結果を踏まえてスコープや要求が変わりやすいが基本的にベースで労働量が増えるだけなので「残りの期限はxxxなので
から逆算するとこれくらいの追加は可能」という考え方ができる。
成果物発表
ソフトウェア開発では開発をしてできあがったものを動作させるだけでよいが、分析では開発結果(分析結果）だけではうまくいかないことが多い。成果物を発表する意図は「ちゃんと機能実装が完了しているか」「その機能がユーザーストーリーに即しているかのフィードバックを得る」ためにおこなう。
データサイエンスにおいて、なにか見せられる状態 =「ちゃんと機能実装が完了している」なので、この点は自然と終わっているので問題ない。
一方で「その機能がユーザーストーリーに即しているかのフィードバックを得る」は問題がある。
なぜなら、開発結果そのままだとフィードバックを得る際にコードから吐かれる結果をそのまま見せられても聞いている方は結果は見づらいし、そのままでは解釈もない。
そのため、データサイエンスでの「成果物」はコードの結果および解釈をなにかにまとめる必要があるので、「成果物発表」ではその点も加味して作業量を見積もる必要がある、
なお、前述のように成果物はフィードバックを得るために作るので成果物は「どういった分析をするか」「EDAの結果と解釈(モデルをどう作成するかの予定)」「分析結果とその解釈」となる。
つまり、これらの成果物を出し、
- 「どういった分析をするか」であれば分析の考慮漏れやよりよい分析アイデアがフィードバック
- 「EDAの結果と解釈(モデルをどう作成するかの予定)」であればEDAとして見るべき考慮漏れやEDAの結果の解釈やモデルアイデアがフィードバック
- 「分析結果とその解釈」であれば、分析からの知見や解釈、考慮すべき点のフィードバック
を得る。
まとめ
アジャイルはソフトウェア開発を前提に説明されているため、データサイエンスではそぐわない部分がある。しかし、アジャイルの哲学 「不確実性をなくす」ために、考えられる全てのことを見える化・推定・認識のすり合わせをおこなう*ことで、できるだけその時点での不確実な要素の不確実性を除去して、クライアント・メンバーが満足するものを提供する はデータサイエンスでも変わらないのでフレームワークの一部をデータサイエンス向けに変える必要がある。
具体的には「開発」の仕方がKDDベースの固定された内容に変わる。そして、開発はKDDを何周もする必要があるので「工数概算見積もり」「計画づくり」の考え方が変わる。
また、成果物の形態がソフトウェアと異なるため「成果物発表」を少し工夫する必要が生まれる。
まぁ正直やっていること自体はCRISP-DMとほぼ同じだが、「CRISP-DM」の「ビジネス理解」が抽象的だったが「インセプションデッキの作成」「ユーザーストーリーの作成」などより明確になった。更に、どうフローを回していくかといったことや期間の定め方が明確化した。
また、今回は変更がないので詳細は書いてないがその他アジャイルの進め方を模倣することでより不確実性が少なくなる。
このように、一部変更箇所はあるが、アジャイルを取り込むことによって、ソフトウェア開発と同様に不確実性をできるだけ排除したデータサイエンス案件ができるようになる。
その他
今回はあくまで「既存のソフトウェア開発でのアジャイルフレームワークをDSに落とすと際に変わる点」について記載した。
DSが共通部分含む各フレームワークでやることや、DSはどういうことを意識すればいいか、DS的にはどういう効力があるかといったような「DSにアジャイルを組み込むことの効果」は軽くしか書いていない。理由としては、共通部分を書くと「変わる点」がなにかわかりづらくなるため共通部分を書いていないが、そうなると「DSにアジャイルを組み込むことの効果」が書きづらいためあえて書いてない。
それらについては以下の記事が良かったのでご参照ください。