サービス開発における5つの“不確実性”パターン　曖昧さをコントロールするために、ユーザーストーリーを活用する

炭田氏の自己紹介と本日のアジェンダ

炭田高輝氏（以下、炭田）：それでは、「アジャイルで不確実性に向き合うための開発タスクの切り方」の発表をします。よろしくお願いします。

はじめに自己紹介をさせてください。BASE株式会社でネットショップ作成サービス「BASE」のエンジニアリングマネージャーをしている炭田高輝といいます。BASEには2020年に入社して、エンジニアリングマネージャーはかれこれ1年くらいやっています。

（スライドを示して）本日のアジェンダはこちらです。最初に「不確実性とは何か」について説明して、次に「受け渡し型開発の構造的な課題」も見ていきたいと思っています。最後に「ユーザーストーリーでバッチサイズを小さくする」にはどうすればいいかを見ていければと思っています。

不確実性とは何か

まず「不確実性とは何か」ですが、まず定義として一般的に挙げられるのは、このようなかたちだと思っています。白黒はっきりつけられない、曖昧さ、確率が残っている状態や状況のことを指すことが多いかと思います。

なので、不確実性を減らすということは、つまり確率をどちらかに寄せる作業。白黒つけたりすることです。例えば、この実装で負荷の問題が起きるのか起きないのか、どちらなのか答えを出して結論を出すことで、曖昧さがなくなって不確実性が減ったとみなすことができると思います。

サービス開発における不確実性は、主に有名なところでいくと、目的不確実性と方法不確実性があるということです。

不確実性は実際チャンスでもあると思っていて、サービスが売れるのか売れないのかについて白黒つけることができればビジネスチャンスですし、アーキテクチャを決定できれば、そのプロダクトにとってすごく大きな前進になると思います。

不確実性は厄介なものになっていると思いますが、すべてが悪いわけではなく、むしろチャンスになり得ると自分は思っています。不確実性があるという現実は変えられないので、そこに振り回されずにコントロールしながら白黒つけていくことが重要じゃないかと思っています。

不確実性に振り回される5つのパターン

不確実性に振り回される5つのパターンを考えてきたので、ここでみなさんと一緒に見ていこうと思っています。

まずは突発パターン。突然新たな不確実性が噴き出してくるようなパターンがあると思っています。例えば「差し込みでこの対応をお願いしたい」という会話を、みなさん聞いたことがあるんじゃないかと思います。

2つ目が手戻りパターン。出した結論がちょっと間違っていて、不確実性が高い状態に逆戻りしてしまう。「あれ？　これってお願いしていたものとちょっと違うんですけど」みたいな会話が出てくるんじゃないかと思います。

3つ目は大群パターン。不確実性がある事象の多さにちょっと圧倒されて、どこから手をつけていいかわからないような状態です。

4つ目は氷山の一角パターン。不確実性の大きさを正しく観測できない。例えば「思ってたよりぜんぜんやること多いじゃん」みたいな。僕も言ったことがありますが、そういう状態のことです。

最後が忘却パターン。前に不確実性を減らしたのに、その知識が失われてしまったパターンです。この5つがあるかなと思っています。

この発表では、これら5つのパターンに関して、不確実性に振り回されずにコントロールするための開発タスクの切り方を紹介していきたいと思っています。

不確実性の解釈の仕方や「自分はこう思っている」というのはみなさん思い思いに持っていると思うので、もしよければZoomのチャットに、「僕はこういうふうに不確実性を捉えています」「こういう解釈をしていたブログがおもしろかった」みたいなものがあれば共有してください。後で僕も読みますので、ぜひお願いします。

各パターンにおける受け渡し型開発の構造的な課題

次に進みます。「受け渡し型開発の構造的な課題」について見ていこうと思っています。

受け渡し型とは何かというと、工程間で成果物やデザインができたので、次にスケジュール見積もりをお願いして、スケジュール見積もりの後、バックエンドの実装（を始める）というように、成果物を受け渡していく開発のことを、この発表では「受け渡し型の開発」と呼ぼうと思います。ウォーターフォールやシーケンシャル開発、リレー形式の開発と呼んだりもします。

この受け渡し型開発には、どうしても避けられない構造的な課題があると思っています。それは、要件定義からリリースまでの間に、一度に多くの作業を行わざるを得ないことだと思っています。

着手からリリースに至るまでの作業量が多いことを、この発表の中では「バッチサイズが大きい」と表現しようと思っています。これから、バッチサイズが大きいとどう不確実性に振り回されるのかを具体的に見ていこうと思っています。

まずは、先ほど出てきた1つ目の突発パターン。突然新たな不確実性がドンと噴き出てくるパターンです。「差し込みでこの対応をお願いしたいんですが、きりの良いタイミングないかな？」と言われた時に、受け渡し型の開発だと「うーん、ないね」となることが多いと思います。

バッチサイズが大きいと、基本的にリリース前後しか良いタイミングがないと思うので、タイミングが少ないか、そもそもないことになってしまって、無理に入れるとさらにバッチサイズが大きくなってしまいます。

手戻りパターンでは「あれ、これってお願いした機能と違うのですが」とテストで気づくことが多いと思います。判明した時点で前の工程の作業が無駄になるので、バッチサイズが大きい分、無駄になってしまう作業も大きくなってしまいます。

大群パターンを見ていくと、一度に多くの機能を実装して、最後にドンと結合テストを行うので、その結合テストや受け入れテストで多くの不具合や仕様変更のコメントがあって、一気に不確実性に襲われてしまい、「どうすれば良いかわからない」と思うこともあるかと思います。

あとは氷山の一角です。「見積もりの内容よりぜんぜんやること多い」ということがよくあると思っています。僕もこのようにしゃべったことがありますが、どうしてもバッチサイズが大きいと含まれる不確実性の大きさを見極めることが難しくて、その結果として、実体より小さく見積もってしまうことが多いと思います。

最後は、忘却パターンです。結合テストで、「あれ？　これって前に話した気がするんですけど、結論はなんでしたっけ？」みたいな会話が交わされることがよくあると思っています。バッチサイズが大きいと、やはり情報が活用されるまでの期間が長くなって忘れてしまうことが多いと思っていて、最悪の場合、再び調査したりする必要があります。

実際の現場ではこれらが複合し、複雑に絡み合って出てくることが多くて、今まで見てきたパターンでは、バッチサイズの大きさゆえにこの5つのパターンが発生しやすかったり、対応しにくいことがあると僕は思っています。

ユーザーストーリーを活用したパッチサイズを小さくする方法

どうにかしてバッチサイズを小さくできないかと考えます。そこで、ユーザーストーリーが使えるということを見ていこうと思います。

まず、受け渡し型開発のコード上の課題はバッチサイズの大きさだったので、開発タスクの切り方を工夫することで、バッチサイズを小さくすることにトライします。

バッチサイズを小さくする上で一番大切なのが、工程を分けず、すべての工程を含むように開発タスクを小さくしていくことです。

よくあるのが、バックエンドのタスクファイルを細かくしてAPIの実装・設計、データストアの設計などに分けていくパターンだと思いますが、これはバッチサイズが大きくなってしまうので避けるべきだと思っています。すべての工程を含むように、横に切らずに縦に切るイメージで開発タスクを小さくしていきます。

その時に、ユーザーストーリーを使って、最低でも受け入れテストを必ず含むように小さく分割していくのがおすすめめです。よくあるスクラムやアジャイルでいくと「その都度リリースして」みたいに言われることが多いですが、なかなか難しい場合もあるんじゃないかと思っています。

ただ、受け入れテストまでであれば、頻繁に行うことを許容できるチームが多いのではないかと思っていて。それによってユーザー目線に近いチェックを入れることができます。

（スライドを示して）ユーザーストーリーとは実際に何かというと、フォーマットでこんな感じに書くことが多くて、「ユーザーとしてアクションをしたい」「それはビジネスメリットのためだ」とシンプルに書けます。

ユーザーストーリーを使うことでどんないいことがあるかというと、結局ビジネスメリットが達成できるかどうかを受け入れテストで確認することができます。ユーザーストーリーに分割する、イコール自然なかたちで、受け入れテストまでの全工程を含むかたちに開発タスクを分割できるようになります。

ユーザーストーリーでの分割

ここで実際に分割するところを見ていこうと思っていますが、まずは、ToDo管理アプリケーションの簡単な例を見ていきます。

その前に比較として、受け渡し型開発の場合の話をしようと思います。よくあるのが、登録用のAPI開発、ステータス更新用のAPI開発というように細かく分けていくことだと思っていますが、残念ながら構造上、ユーザー相当の検査が行われるまでバッチサイズを小さくすることはできません。

対して、ユーザーストーリーを分けていく。まずは、最初の大きなユーザーストーリーを見ていこうと思います。「ユーザーとしてToDo管理をしたい、やる必要があるタスクを忘れずに実行し完了させたいからだ」ということで、最初のユーザーストーリーができました。

これを細かく分けていくと、登録と状態の更新と削除の3つに分けることができました。

次のスライドで、一番上の登録についてもさらに分割していきます。「ユーザーとしてタスクのタイトルを登録したい、ユーザーとしてタスクの詳細を登録したい、なぜなら……」と続いています。もちろん、ほかにもサブタスクや実施日など、いろいろなケースが浮かび上がると思いますが、このようにユーザーストーリーを保ったまま着手可能な大きさになるまで開発タスクを小さくしていくことで、バッチサイズを小さくすることができます。

バッチサイズが小さいとなにがいいのかというと、先ほどの5つのパターンに対応しやすくなります。例えば、きりの良いタイミングをユーザーストーリーごとに作ることができるし、手戻りが起きた場合でも捨てられるのは1つのユーザーストーリーだけ。あとは、少しずつ処理するので、どこかで一気に不確実性の大群が襲ってくることはまれです。

また、作業単位が小さいことで不確実性のサイズを捉えやすい。氷山の一角の氷山をできるだけ小さくするイメージです。また、期間が短いことで着手からリリースまでの忘却の発生も抑えることができます。

ということで、バッチサイズを小さくすることで、方向転換が簡単になったり無駄が少なくなったりして、リーンでアジャイルなチームに近づくことができると僕は思っていますが、そのためには工程に分けずに、受け入れテストを含むようなかたちで開発タスクを分割することがおすすめです。

とはいえ分割にも慣れが必要かなと思っているので、困った場合はぜひ近くのスクラムマスターに相談してほしいと思っています。（スライドを示して）もしくは、ここにあげているような書籍やブログが参考になるので、見てみてもらえるとうれしいです。

分割で不確実性をコントロールしやすくなる

最後にまとめです。工程に分けて成果物を受け渡していくような開発は、どうしてもバッチサイズが大きくなってしまって、不確実性をコントロールするのが構造的に得意ではないことがわかったと思います。

そこで、全工程を含むように小さく分割することで無駄が減って、不確実性をコントロールしやすくなります。ぜひみなさま参考にしてもらえるとうれしいです。

ご清聴ありがとうございました。

（次回に続く）