データサイエンスにスクラムを適用するために

執筆の背景

• 筆者はデータ分析の会社に勤めている。自チームでスクラムを適用・運用しているが自分自身の理解が浅く、うまく扱えている気がしていない。日本語記事もあまりヒットしなかったので色々調べてアウトプットすることにした。

データサイエンスプロジェクトで選択するプロセス

この記事によると、CRISP-DMの次に選ばれた手法となっている。一方、スクラムを「使用する」ほとんどのデータサイエンスチームは、このフレームワークから逸脱することがよくある。例えばスクラムを使用していると報告しているが、スクラムマスターがいない、一般的にいくつかのセレモニー (特にスプリント レビューと振り返り) を省略している、といったこともある模様。

適用のメリット

スクラム適用によって7つのメリットを受けることができる。それぞれについて述べる。

• 実証的証拠
  • データサイエンスと同様に、スクラムは既知の事実に基づく実行の原則に基づいています。（簡単に言えば、何かを提供する。何が機能するかを確認する。何が機能しないかを確認する。）それに応じて計画を調整する。
• 顧客重視
  • スクラムは顧客価値の提供に重点を置いている。スクラムは開発作業を顧客の視点から組み立て、スプリントレビューなどのプラクティスを通じて関係者が継続的にフィードバックを提供するように促します。
• 規則性
  • 厳格な時間制限によりチームは定期的な作業リズムに慣れることができる。
• 自律性
  • チームに自己管理の幅広い自律性を与えることで、チームはより生産的で、より積極的になれる。
• 検査による改善
  • チームは、特に各スプリントの終わりのレトロスペクティブにて常に自分自身を内政する。これまでのサイクルから学び、適応することで、各開発サイクルを通じてパフォーマンスを向上させます。
• 説明責任
  • 個人はチームメンバーに対して説明責任をもつ。これは、スクラムの透明性と、チーム メンバーが常に作業内容を示す毎日のスタンドアップ（デイリースクラム）やスプリント レビューなどの実践によって強化されます。
• 緊急感
  • 期限が常に迫っているため、成果を出す意欲が高まる。

適用するときの課題

この記事に下記以外の課題も含まれていたが、データサイエンスに限らないスクラムの課題のように感じたため除外した。

• タイムボックスの課題:

  • ほとんどのデータサイエンスの問題に対するソリューションを実装するために必要な時間は曖昧で、データ取得、データ品質の疑わしい点、信号とノイズを区別する未テストの能力など、未知の要素に依存する。この状況下で期限に間に合わせるよう迫られた結果、テストが不完全になったり、分析が急がれたり、不要な技術的負債が生じたりする可能性がある。

• 会議の時間の課題:

  • スクラムにはデイリーやプランニングなど様々な会議があり、通常週に約4時間か必要とする。さらに、ストーリーの洗練とバックログ管理のための時間も必要となる。これらの会議は避けるべきオーバーヘッドと見なされる可能性があると考えている。

• 「完了の定義」の課題:

  • スクラムでは、事前に定義された「完了の定義」を満たす製品増分を提供するようにチームに指示しているが、スクラムの共同創設者1人であるJeff Sutherlandは、「私が調査したシリコンバレーの何百ものチームのうち80%はこれを実行できませんでした」と報告している。(Sutherland、2015)。この課題は、データサイエンスにとって特に困難であり、必要でない可能性もある。実際、特に初期の探索フェーズにおけるチームの作業の多くはデータサイエンスチーム外へのリリースを考慮していない可能性がある。

推奨事項

上記の課題を認識し、チームのニーズに合わせてスクラムを調整する計画を考案する必要がある。考えられる解決策は次のとおり。

• 「スパイク」を優先する

  • スパイクとは開発に潜む「未知」を「既知」に変えるためのひとつの手法のこと。
  • 調査と発見を可能にするために、チームはバックログ内の項目であるスパイクを作成し、特定のトピックについて集中的に調査するための調査時間を確保できる。これらのスパイクは、バックログ内の製品増分アイデアと並んで配置されます。指定された調査目標が達成されるか、期限が切れると、「完了」と見なされます。

• 分割して征服する

  • タスクにどれだけの労力が必要かを把握していないことがよくあるため、作業増分を”定義可能で見積もることができる小さな部分”に分割することです。

• スプリントを短縮する

  • Daniel Mezick曰く「何かが混乱に近づけば近づくほど、何をすべきかを把握する方法は、頻繁な検査です」と述べている。彼は、より頻繁な検査を強制するために、より短いスプリントサイクルを使用することを推奨しています。

• 時々「完了の定義」を緩める

  • 探索的な作業や概念実証は、完全に「完了」する必要がないことがよくある。そのため、チームは特定のストーリーの完了の定義を緩めることに同意できます。ただし、チームは、「コア成果物の品質の低い出力を受け入れる」という危険な道に陥らないようにする必要があります。

• スプリント中に作業を再交渉する

  • スプリント計画はスプリント計画時に固定されるわけではない。チームは必要に応じて「スプリント バックログの範囲を交渉」する必要がある。

• 最も理解されていない作業を最初に行う

  • Akred は、チームに「理解していない部分を最初に処理し、能力に自信が持てるようになったら、その部分を実際に使用可能なシステムに変えるものの構築を開始する」ことを推奨しています (Akred、2015)。チームが妥当なサイクル数内で実現可能性を証明できない場合は、他の作業に再び焦点を当てることができます。

• 「アーキテクチャ ランウェイ」を構築する

  • 新しい大規模なアーキテクチャを必要とするチームは、慎重な事前計画の方が効果的であると感じる場合があります。スクラムの顧客中心の焦点から逸脱することにはなるが、Scaled Agile Framework (SAFe) の概念を取り入れ、最初のスプリントのいくつかをアーキテクチャの開発に充てることで上手くいく可能性がある。」

• 別フレームワークとの統合

  • CRISP-DM または別のデータサイエンスライフサイクルをスクラムと統合して、プロジェクトを管理する。

所感

まとめて感じたことを雑に書きます。

• 曖昧な要件に対して「何をもって終了とするか」の具体化が重要にように感じる。
• 自分たちのチームの特性・状況に応じて柔軟な動きを取り入れる。
• 時には大原則を無視するなど柔軟な動きを行って課題解決を行う勇気が必要。