最近PL/PMすることが増えたので、チーム系の本(+マネジメント系の本)を読んだ。

チームが機能するとはどういうことか ― 「学習力」と「実行力」を高める実践アプローチ

作者:エイミー・Ｃ・エドモンドソン
発売日: 2014/09/05
メディア: Kindle版

作者:ハーバード・ビジネス・レビュー編集部
発売日: 2019/03/07
メディア: 単行本（ソフトカバー）

また、これらはチームに関して共通した運用方法・哲学なので DSプロジェクト自体の方法としていったんアジャイル系の本を読んだ。理由としては、近年色々なところでDSチームのアジャイル運用の話を聞くため。アジャイル自体はソフトウェア開発のプロジェクト運用フレームワークなので、そのまま運用はできないので、そもそもの哲学や使える場所を考える、という観点で読んだ。

SCRUM BOOT CAMP THE BOOK【増補改訂版】スクラムチームではじめるアジャイル開発

作者:西村直人,永瀬美穂,吉羽龍太郎
発売日: 2020/05/20
メディア: Kindle版

アジャイルサムライ――達人開発者への道

そのため、本記事では「DSでアジャイルにプロジェクトをすすめるにはどうしたらいいか」を考えるための前段として既存の使えそうなフレームワークを簡潔にまとめる。次回にそれらを踏まえた自分なりのアジャイルな分析案件の進め方をまとめる。

次回

knknkn.hatenablog.com

分析フレームワーク

分析プロジェクトの既存フレームワークとしてCRISP-DMやKDDが存在する。

CRISP-DM

「ビジネス課題にはじまり、分s系により得られた利権をビジネス価値の向上に結びつけていく」という発想のフレームワーク。「ビジネス理解」「データ理解」「データ準備」「モデリング」「評価」「共有・展開」の6つのステップに分け、それぞれをいったりきたりする。計画立案や、コードの整理などをおこなうときこのステップに分けて分割するときれいになることが多い。

f:id:chito_ng:20200814074612p:plain — https://en.wikipedia.org/wiki/Cross-industry_standard_process_for_data_mining

dev.classmethod.jp

lib-arts.hatenablog.com

KDD(Knowledge discovery in databases)

データ分析部分に特化して定義されたフレームワーク「データ獲得」「データ選択」「前処理」「変換」「データマイニング」「解釈・評価」の6ステップに分かれる。

アジャイル

「不確実性をなくす」ために、考えられる全てのことを見える化・推定・認識のすり合わせをおこなうためのフロー。
基本的には「ソフトウェア開発」のための手法。

具体的には、「インセプションデッキの作成」「ユーザーストーリーの作成」「工数概算見積もり」「計画づくり」といった準備のもと、毎スプリントで「各ストーリーの設計(深堀り)」「開発」「テスト」「成果物発表」「フィードバック」という手順をおこなっていく。

この際、アジャイルチーム全員で各手順を一眼となって作成することで、チームメンバー内での認識の齟齬をなくすことができる。同時に、多くの手順ではクライアントとも一緒におこなうことで期待値コントロールも可能になる。

機能(todo)は1スプリント内で「設計→開発→実装」全てがおこなわれるとともに、クライアントからのフィードバックがセットでついてくる。そのため、期待値コントロールや要件とのズレの修正など柔軟性がある。

また、余談だが「共通の目的意識を持ち」「透明性がある」「公平性がある（それぞれが大切な役割を持つ）」「よりよい成果物を提供するために自己学習していく」というアジャイルの特徴は「チームが機能するとはどういうことか」など、チーム系の本で共通して出てくる良いチームの特徴となっている。つまり、不確実性をなくすだけではなくチーム運用も考えられたフレームワークとなっている。

DSにアジャイルが向いている部分向いてない部分

Data Science and Agile: What works and what doesn’t work

Data Science and Agile (Frameworks for Effectiveness)

ではアジャイル開発でDSに向いている部分向いてない部分を以下のようにまとめられている

向いている部分

スプリント開始時の優先度付けと実行計画
タスクを明確化する
各スプリント終了時のデモと振り返り

DSの作業でよくある間違いとして なんとなく分析をして本質と関係がない気になる箇所に時間を使ってしまう ということがよくある。
これを回避するために上述の3点をおこなうことで「目的をしっかり認識して」「それに必要な作業のみを洗い出し」「時間内に終わらす」ことができるし、認識のズレも極力なくすことができる*1。

向いてない部分と回避策

見積もりが困難

プロセスはある程度明確だが、各工程がどれくらいかかるかはデータによるため不明確。

これに対して、ストーリーポイントや工数を先に設定することでそれら実験をタイムボックス化することで回避する。

スコープや要求が変わりやすい

分析の過程でわかった内容をもとに、ステークホルダーから深堀りして欲しいという要求が生まれることが多い。

これに対して、常にステークホルダーと定期的な優先順位決めをおこない整理することで回避する。

各スプリントでデモをおこなう成果物が出しづらい

デモに必要な受け入れ基準、精度や改善インサイトはどれくらいでできるかスコープが切りづらい

これに対して、そもそもアジャイルはソフトウェア開発のフレームワークなので、DS作業では動くソフトウェアを出せないことを理解すること。代わりに、どういう実験をしたか、それを踏まえたネクストアクションはどうするか、といったような「そのスプリントでの実験と考察」をスプリント成果物として報告する。

スクラムは短絡的

クライアントの優先順位を優先したり期限を切ることで、根本が別だったりでより良くできることもスコープの範囲内での結果になってしまう

これに対して、例えばGoogleの20%ルールのようにイノベーションを起こすための時間を確保することで 効率的になりすぎる ことを回避できる。

DS向けアジャイル

前述の記事では、DSに適用した「タイムボック化されたスイテレーション(Time-boxed Iterations)」を用いたアジャイルを提言している。

Time-boxed Iterations

内容毎にフェーズ（タイムボックス）を分け、その中でいくつかのタスクを定める。各フェーズ内で満足する結果になったら次のフェーズへ、満足しなかったら再度そのフェーズを反復する。
フェーズ毎にフィードバックをもらう（特に不明瞭さが多い初期ステージ

1. Feasibility Assessment

ステークホルダーと要件（問題・要求・成果物・制約条件など）を定める
ざっくりおこなうとどれくらいのパフォーマンス（精度）が出せそうか（ベースライン）
2~4week

2.Proof of Concept (POC)

最小実行可能なベースラインを作り、ステークホルダーに共有
性能要件を満たしているか、追加リソースが必要そうかを検証
4~8week

3. Deploy to Production

本番環境への移行
保守性・パフォーマンス・スケーラビリティ・保守性などのためにリファクタリングやドキュメント化
3-9ヶ月

4.Operational Maintenance

保守や新機能実装のメンテナンス

f:id:chito_ng:20200813111357p:plain — https://towardsdatascience.com/data-science-and-agile-1cdfb1667789

アジャイルにデータサイエンス案件をやる

基本的な流れは、アジャイルのところに書いた

具体的には、「インセプションデッキの作成」「ユーザーストーリーの作成」「工数概算見積もり」「計画づくり」といった準備のもと、毎スプリントで「各ストーリーの設計(深堀り)」「開発」「テスト」「成果物発表」「フィードバック」という手順をおこなっていく。

で問題ないと思う。
ただし、 成果物 がソフトウェア開発では機能なので、ここを分析結果となる。また、分析は工数が見積もりづらいので「工数概算見積もり」「計画づくり」に少し修正を加えることことが必要になるし、テストも「データ系のテストとは？」、成果物はなに？といったようにちょくちょくDS向けのやり方があるように思う。

これらを踏まえて、具体的になにをするか次回で記載する。

なお、内容は「アジャイルサムライ」をベースに記載する。