「CIの改善をスクラムでユーザーストーリーとして扱うか？」を考察する

たまに、Twitter などで 「CIの改善をスクラムでユーザーストーリーとして扱うか？」という疑問の声を聞くことがある。
この問いかけは結構難しいと思っていて、スクラム (もっというとアジャイルの世界) が題材にしているものを考えるきっかけになった。

まずよく見る回答としては、以下がある

• ユーザーストーリーは必ずしも、ユーザーにとっての価値と限定しなくてもいいので開発者への価値と考えてユーザーストーリーに加えてもいいんじゃないか
• スクラムに割く時間をある割合にして20%程度の遊びを持たせることでこういったタスクを着実に消化していくのがいいのでは
• 障害対応などの割り込みタスクとかと同じ扱いをすれば良いのでは
• etc…

これらの答えはそれぞれ一理あるのだが、どちらかというとタスクの扱いの話をしていてなんでそういった扱いでうまくいくのかという話に微妙に触れていないというのが最初の感想だった。

Cynefin Framework と Team Topologies を参考文献として出しながら、「CIの改善をスクラムでユーザーストーリーとして扱うか？」の答えを考察してみる。

参考1 : Cynefin Framework

まずは、古典に立ち返ってみて考える。
1999年に IBM の Dave Snowden が提唱した Cynefin Framework ^{1 2} は、不確実さや複雑さを理解するためのフレームワークである。
Cynefin Framework では問題や扱う現実世界を5つのドメインに分類できるとしてる。

ソフトウェアの世界では、このうち Complicated と Complex の領域を扱っているとされている。

Complicated の領域は、問題の全体像、質問すべき内容、そして答えを得る方法はわかっている状態である。
しかし因果関係は入り組んでいて専門知識を必要とする領域であり、簡単なわけではないということに注意する。
要するにあくまでも答えを自分たちで導くことができる問題領域のことである。
Complicated はウォーターフォールや昔ながら業務システム系の開発が相手にしていた世界である。
複雑ではあるものの、あるゴールに向かってシステムを作り上げていく世界。

一方で Complex の領域は、Complicated とは対照的に、質問すべき内容が全てわかっているわけではない。
事前にどれだけ分析を行ったとしても問題は解決せず、解決策に向かって前進するには実験が必要な領域である。
要するに、答えを自分たちだけで導くことはできず第三者 (アプリケーションやサービスの場合には、概ねユーザー) を巻き込んだ問題解決が必要な問題領域のことである。
Complex はその説明の通りアジャイルの世界が相手にしている領域であることがわかる。
この第三者を巻き込んだ問題解決のために、Lean やスクラムなど不確実性や変化する環境に素早く適用するためのフレームワークや方法論が提案されてきたと想像している。

参考2 : Team Topologies

Team Topologies という参考文献 ³ も紹介する。
Team Topologies では、価値に直結する Stream Aligned Team とそれを様々な形態で支援するチームによってチームを構成するという主張をしている。

以下がそれぞれのチームの簡単な説明である

• Stream Aligned Team : ユーザーに対する価値やサービス自体の価値に直接コミットするチーム
• 支援チーム
  • Enabling Team : 技術的な支援を Stream Aliged Team に対して提供する
  • Complicated Subsystem Team : 単体で複雑なシステム (e.g. ID基盤とか) を担当してAPIなどを Stream Aliged Team に提供する
  • Platform Team : Delivery の支援 (e.g. CI/CD の構築など) を提供する

本の内容自体の詳細な感想は、 Team Topologies - Scrapbox に委ねるとして、ここで触れたいのは、Stream Aligned Team は Complex な世界を相手にしていて、一方で支援チームは Complicated な世界を相手にしているという捉え方ができるというところである。

「CIの改善をスクラムでユーザーストーリーとして扱うか？」

さてここまで Complicated な世界と Complex な世界についての考察を主に行ってきた。
では果たして「CIの改善をスクラムでユーザーストーリーとして扱うか？」 の自分なりの答えはというと、

スクラムは、Complex な世界を相手にするフレームワークであり、CI の改善などは開発チームの中で閉じて答えを導き出せる Complicated な世界の問題なのでスクラムの中で扱うことは不適当だと考える。その上で支援チームのようなチームが用意できるのであればそういったチームがこのような改善を担当するのが良いと思うし、いないのであればスクラムの一部の時間を Complicated な領域を扱うように時間を計画して Complicated な問題として扱う (e.g. スプリントレビューなどで扱わない)べきと考える。

もっと話を広げると、ソフトウェア業界は Complicated が主流だった時代から Complex が主流の時代 (グロースハックやスクラムが大きく注目されていた時代) への変遷が少し前に起こった。そこからさらにまた Complicated が CI/CD などの発展によって勢力を戻してどちらもそれなりの割合を占めるようになったのだと考えている。それに伴い、いわゆる Site Reliability Engineer や モバイルアプリのバックエンド (インフラ層やアーキテクチャ全体) を担当するような (Lyft の Mobile Architecture Team などに台頭されるようなチーム) チームなど Complicated な世界をより意識することが大事になってきてるのかもしれない。