機械学習はアジャイル開発の夢を見るか?

ふと気が付くと期末を迎え(弊社は 7 月締めなのです)、本プロジェクトも Closing の時期になっていました。控えめに言って放置気味だったこのブログですが、最後に何か書いておこうと思います。

はじめに

機械学習プロダクトの開発をアジャイルで行うのはどうなのか?について、実際に私たちがトライした経験をベースに、個人的に思うところをつらつらと書いてみます。(ここからは、アジャイル=スクラムと読み替えてもらって差し支えありません)

本エントリとは別に『ソフトウェアエンジニアが機械学習にトライするためには?』という内容で報告書をまとめているのですが、そこで書ききれなかった内容が少し入ります。

fdp-blog.hatenablog.com

何をしてきたのか?

最初にこんなことを決めました。

  • 機械学習のプロダクト開発を通じで機械学習を学ぶ
  • 活動はスクラムで行う

そして一年間、こんなことを実践してきました。

  • 3 か月 ×2 回で 2 つのプロダクト開発を行った
  • 最初から最後まで、基本にかなり忠実なスクラムで活動した

fdp-blog.hatenablog.com

その結果として思うところ

機械学習はトライ&エラーだからアジャイルがマッチする?

No。

アジャイルが狙っている不確実性とは『やってみないと分からない』だと思っています。これは逆に言うと、やってみれば分かるので、その結果を見ながら計画をアジャストし続けようという作戦です。

一方で機械学習が直面する不確実性は『できるかどうかサッパリ分からない』です。乱暴に言うと、『イチかバチか』もしくは『下手な鉄砲も数撃ちゃ当たる』的な世界です。(異論は認めます、エンジニアのスキルに依るところも大きいかも)

やってみた結果、運が良ければ一発目で正解のモデルが見つかるかもしれないし、運が悪ければ 100 万回トライしても精度が出ないかもしれません。こういう不確実性に対して『とりあえず 1 スプリントやってみる』という作戦は、あまり有効に機能しません。また『このタスクどの位で終わりそう?』という見積もりも立てることができません。

※これに対してはMLOps という仕組みがあるのですが、これも本質は『どれだけ効率的に鉄砲を撃つか』だと思っています。

つまり、機械学習でトライ&エラーをやるための繰り返しと、アジャイル開発のスプリントとして知られている繰り返しとは、本質的に異なるものです。

これを理解せずに『機械学習は繰り返しでしょ。ならアジャイルがピッタリだね!』という安易な考えでアジャイルと組み合わせると、良いことはないんじゃないかな、というのが今の私の解釈です。

探索&学習型プロジェクトにはアジャイルがマッチする?

Yes。

今回の私たちのプロジェクトは、実際にお客さんから要求が受けるものではなく、学習のための社内プロジェクトであり、自分たちでやることを探しながら&考えながら進めていくというスタイルでした。

カッコよく言えば『探索型プロジェクト』、正直には『行き当たりばったり型プロジェクト』とも言えるかも知れません(怒られそうだ)。

このような案件では、例えば事前に年間の作業計画を立てることなど不可能です。しかしながら、従来の計画型プロジェクト管理手法では、まず計画がないと一歩も踏み出すことができません。無理に始めようとするなら、予見が不可能な事象に対して何か月もかけてそれらしい(=誰にも怒られない)計画を作成し、始めてみたら全員の予想通り炎上してあの数か月はドブに捨てたね、ということになっていたでしょう。どこかで見たことある風景ですね。

ここでアジャイルの『最初に全ての計画を立てなくても走りだして良い』、言い換えると『見切り発車が可能で、かつ途中でゴールを動かしても許される』という特性が、消極的ではありますが、探索型プロジェクトにマッチすると言えるでしょう。あるいは、アジャイルがマッチするというよりは、ウォーターフォール(言っちゃった)だと確実にロスが出てしまう、と言った方が正確かも知れません。

さらにアジャイルの繰り返しによって、チームはフィードバックを得て成長するチャンスがあります。これは未知の領域にチャレンジする行き当たりばったり型の案件にとっては明らかなアドバンテージですし、ましてチームやメンバの成長が目的である学習型プロジェクトにとっては、うってつけとも言えます。

アジャイル開発は要求されるスキルレベルが高いので上級者向けと言われます。私もこれには同意ですが、一方でメンバの成長を促すという一面も確実に存在し、これが学習型プロジェクトにマッチするのは間違いありません。

学習型プロジェクト(教育目的プロダクト)については、POによるこちらのエントリも参考にしてください。

fdp-blog.hatenablog.com

fdp-blog.hatenablog.com

1 週間スプリントはきつくない?

Yes。 正直ちょっときつかった。

スクラムでは 1 週間スプリントがデファクトになっている感があり、事実スクラムガイドにもそう書いてあります。しかし今回のように、機械学習の初学者がトライする場合、いくつかの理由で厳しいと感じる場面がありました。

一つには、単純に機械学習に不慣れなことにより、思った程には開発スピードがでないという問題です。5 日間のうち 1 日はスクラムイベントで埋まるとすると、残りの 4 日間で、データ収集して、特徴量を抽出して、モデルを作成して評価するといった、いわゆる機械学習のプロセスを回すことは難しいです。

では 4 日でこなせるサイズまでタスクを小さくすれば良いのでは?と思いましたが、実際にはそれも難しいのです。上記の機械学習のプロセスは、データ収集~評価まで行って初めて完了したかどうか?の判定が可能になります。これを例えば、データ収集だけのタスクとした場合、そのタスクの完了条件(Definition of Done)を設定することができないのです。

これが慣れ親しんだソフト開発であれば、例えば設計と実装を別のタスクに分けてしまい、最初のスプリントは設計を、次のスプリントでは実装を、ということ不可能ではありません。(突っ込みたくなる人はいるでしょうが)

つまり、分解できるタスクの最小サイズが制約されるために、今の私たちの開発力では 1 週間スプリントを上手く回すことができないケースが発生したのです。

もう一度やるとしたらどうする?

アジャイルでやります。

今期のプロジェクト期間中は、いろんなことに意識が発散しすぎてしまい(言い訳)、アジャイル/スクラムのプロセス自体を見つめ直したり、それを磨き上げることにリソースを充てられていませんでした。最終日前日になってこのエントリを書きながら、なるほどそういうことだったのか~と納得している始末です。言語化マジ大事。

でもカイゼンこそがアジャイルの最大の武器です。 もう一度やるとしたら、きっと『強くてニューゲーム』状態で無双できるんじゃないか? そんなことを考えています。

さいごに

と言っても、来期は別のメンバにバトンタッチです。

私たち42期のチームBoatがやってきたことが、少しでも次のチームの手助けになれば良いな、と願っています。