イテレーティブな開発 = スクラム と捉えると生じ得る誤解

不確実性に向き合うためのイテレーティブな開発

何がユーザーにとって価値があるのかを事前に推測することが難しいような不確実性の高いプロダクトを作るとき、なるべく早くフィードバックを得て機敏に方向転換ができるように、スクラムではイテレーティブ(反復的)な開発スタイルを採用しています。具体的には、スクラムガイドを道標としながら、スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブといった4つのイベントを1~4週間ほどの固定スプリントで繰り返し、スプリントごとに「動くソフトウェア」を作りフィードバックをもらうことを仕組み化します。またアジリティを最適化するためにチームメンバーの役割を3つに分け、つまり「何を」「なぜ」「どの順番で」作るのかに責任を持つPOと、優先度が高いものから順番に「いつ」「どのように」作るかに責任を持つ開発メンバー、そしてこのスクラム全体が上手く回るようにチーム内外とコミュニケーションすることに責任を持つスクラムマスターがおり、それぞれが自分の職務に集中しながらチームとしてプロダクトとチーム自体に対する学習を続けることでアウトカムを最大化していきます。

なんのためのスクラム？

つまりスクラムではイテレーティブな開発を取り入れます。

しかし必ずしも逆は真ではないと思います。

つまり、イテレーティブな開発を取り入れているかといって、それがスクラムとは限りません。

なぜこのようなことを言うかというと、別に自分がスクラム原理主義者で、「スクラムのフレームワークに従ってないのにスクラムって呼ぶなんてケシカラン！！」と言いたいからではありません。

場合によっては、「不確実性の高い状況で反復的かつ漸進的に開発する」ことを目的としない場合でもイテレーティブな開発を取り入れたくなることがあり、そういう時に「イテレーティブな開発＝スプリントを取り入れる=スクラム」のような構図で「スクラムをやろう」とすると、「スクラムをやるんだからスクラムガイドに従おう、でもPOやSMが...」などと悩みに繋がる可能性があります。

例えば私が今いるチームでは、元々は特にプロジェクト管理のようなものはしていなく、そこからバックログを可視化するためにまずはカンバンを採用し、少し慣れた頃にメンバーから「スクラムを導入したい」と意見がありました。そのメンバーはスクラムの経験があります。

しかし今のチームの開発内容は、不確実性の高いプロダクトを開発しているわけではなく、既に運用されている自社の業務用アプリのバグ修正や軽微な機能改善が中心で、いわば「何を開発をすれば良いか分かっている」状態のものが多いですし、一つ一つの開発内容が独立していることが多く、「どういう順番で開発するか」の判断もそこまで高度で専門性のいるものではありません。まだまだ規模が小さい弊社では現在POというポジションの人はいないのですが、敢えてPOを新規で立てるほどでもないかな、という状態です。(しかし、一つの開発チームで10個以上のプロダクトを管理しているため、プロダクト間の依頼の優先度判断が難しいことはあります)

また同様の理由で、スプリントレビューも現段階ではそこまで要らないかなと思っています。

一方で、スクラムガイドには

ここで概要を述べたように、スクラムフレームワークは不変である。スクラムの⼀部だけを導⼊することも可能だが、それはスクラムとは⾔えない。すべてを備えたものがスクラムであり、その他の技法・⽅法論・プラクティスの⼊れ物として機能するものである。

~スクラムガイド2020の「最後に」より引用~

と書いてあり、POやスクラムマスターがいなかったりスプリントイベントをどれかスキップしていたりすると、それはスクラムとは言えないそうです。

なので、メンバーから「スクラムしたい」となったときに、スクラムガイドにある意味での"スクラム"を想像しているのか、スクラム導入によりどんな課題を解決したいのかをヒアリングしてみました。

すると、課題として出てきたことは、複数あるプロダクトを一つのチームでカンバンスタイルで開発していると様々なところからバグ報告や機能追加の依頼が飛んできてどれも差し込みのような扱いになってしまい、そうするとWIPが増えてスイッチングコストがかかり、かつ各タスクがいつ完了するかも見通しがつきにくく疲弊してしまうことが課題でした。なのでその課題を解決するためにスプリントの概念を導入してその期間内はプランニングで計画したことだけに集中してなるべくWIPを減らすことが狙いで、この反復的な期間の概念を導入することを、「スクラムしたい」と表現していたようでした。

WIPを最小化しスイッチングコストを減らすためのイテレーティブな開発

そうすると、目的はあくまで「今はこれに集中する」という状態を作り周囲にもそれを可視化することで精神的に余裕を持って開発することなので、必ずしもスクラムガイドにあることに全て従う必要はないことがあります。そもそも”スクラム”を導入したいわけではないので。

しかし、そうした考察がない状態で「スクラムやりましょう」となると、「スクラムガイドに従おう」という方向に力学が動き、「スクラムガイドに書いてる内容と自分たちの実態とのギャップ」に悩み、まるで自分たちが何か欠損しているチームのように感じてしまうのではないでしょうか。

一方で、スクラムやスプリントという言葉が普及し、「イテレーティブな開発　＝ スクラム」のような図式が出てしまうことは少なからずあるように思いますし、それにより余計な懸念が生まれてしまうこともあると思います。

なので、こういう場合は「スクラム」とは呼ばず、「イテレーティブ開発」とだけ呼ぶのが良いんじゃないかな、などと考えていました。