ngatangataです。現在、私は以下のような取り組みを行っています。
- 取引内容から勘定科目を推論する機能の精度改善の研究
- 推論モデルを運用するバックエンドサービスの開発と運用保守
このような業務をデュアルトラックスクラムで行うことになった経緯や学びなどをお伝えできればと思います。
デュアルトラックスクラム
スクラムはアジャイル開発の一種で、顧客への価値提供に重きを置いた開発フレームワークです。スクラムにおける作業では、スプリントと呼ばれる短い期間（私たちは2週間）で機能改善し、それを反復しています。
デュアルトラックとは、その名の通り2つのトラックを同時進行させることを指します。2つのトラックとは、仮説検証を行う「Discovery Track」と価値提供を行う「Delivery Track」であり、プロダクトの方向性を見極めたうえで価値提供することで開発のスピードと品質を両立させることができると言われています。
デュアルトラックスクラム*1の事例としてはUX改善が多く、「Discovery Track」でユーザーインタビューを実施し、ユーザーがほしい価値を明確にしたうえで「Delivery Track」で開発とリリースをするケースが多いようです。
デュアルトラックスクラムを研究と開発を行うチームに取り入れた経緯
私たちは既存の推論モデルを組み込んだバックエンドサービスの開発を終えて、推論精度を上げるための研究も実施することになりました。バックエンドサービスの開発はスクラムで行っていましたが、研究も実施するとなると研究タスクがスプリントに導入されることとなります。
このような状態だと、以下1と2のような問題が懸念されました。
1. スプリントで実施する内容が増えて、価値提供までの時間がかかりすぎること
例えば、これまで「設計→開発→テスト→リリース」のようにスプリント内で作業を実施していたとすると、「研究→設計→開発→テスト→リリース」のように進めなければなりません。当然、研究もそれなりに工数を要するため、スプリントが肥大し価値提供の頻度は下がることが想定されます。
2. スプリントで研究成果を価値提供できるとは限らないこと
研究は不確実性が高く、よい成果が出るとは限りません。研究した内容を必ず開発して組み込むとは限らないため、確実にリリースする設計以降のフェーズとは性質が異なります。
研究を行わずに仮説ベースで実装した改善をサービスに組み込むと、勘定科目推論の精度低下を起因としてサービスの利便性を下げることに繋がりかねないため、仮説検証（研究）とその成果の実装を両輪で実施することをチームは望みました。
そこで、「Discovery Track」で研究、「Delivery Track」でリリースまでを実施するデュアルトラックスクラムを導入することになました。
デュアルトラックスクラムの工夫
デュアルトラックスクラムの工夫は「Discovery Track」と「Delivery Track」の比率を固定しないことです。
「Discovery Track」と「Delivery Track」の期間は同期させ、以前の「Discovery Track」で得られた成果を実装・リリースします。また、「Discovery Track」で良い成果が得られなかった場合、「Discovery Track」に取り入れずに破棄されます（下図参考）。そのため、継続的に価値提供するためには研究成果をある程度ストックしておく必要があります。
研究の積み上げがないデュアルトラックスクラム初期や研究テーマが枯渇しそうなタイミングでは、「Discovery Trackのみ」または「Discovery Trackに比重を置いて」価値提供の準備をしています。このようにすることで、例え現行スプリントの研究成果が価値提供に値せず破棄されるものであっても、過去の研究成果から提供する価値をリストアップし選定することで、実装・リリースすることができます。一方で、普段のデュアルトラックスクラムでは、「Delivery Track」の価値提供に比重を置いています。
以上より、「Discovery Track」と「Delivery Track」の比率を固定しないことによって、チームの状況に応じた柔軟な対応が可能となっています。
デュアルトラックスクラムを導入して得られた学び
今回はスクラムからデュアルトラックスクラムへ大規模な開発フレームワークの変更に携わりました。開発フレームワークの変更には時に大きなリスクがあることも前提に、「やってダメなら元の開発フレームワークに戻そう」と勇気を出して実行に移すことの重要性を学びました。
個々人の業務改善やソースコードのリファクタリングなどに加えて、チームの開発生産性に関わる開発フレームワークの改善も継続することで、お客さまに質の良いサービスを早く届けることの大変さについて学べたことも良かったと感じています。
さいごに
アジャイル開発の亜種であるデュアルトラックスクラムを研究開発に取り入れた内容が少しでも読者の皆様の力になれれば幸いです。
www.yayoi-kk.co.jp
弥生のエンジニアに関するnote記事もご覧ください。
note.yayoi-kk.co.jp
*1:ユーザーインタビューはUI/UXのチーム、価値提供は開発のチームで実施など、Discovery TrackとDelivery Trackが別々のチームによって主導されるものは、デュアルトラック『スクラム』ではないため、デュアルトラック『アジャイル』と表記されることが多い。今回導入した開発フレームワークは、チーム内に閉じるためデュアルトラック『スクラム』とする。
