本稿は Goodpatch Advent Calendar 2022 の25日目の記事です。 Goodpatchでエンジニアリングマネージャーをしている関矢です。毎年トリの記事を担当しているので、これが書き終わったら仕事納めだ！と言い聞かせてMacのエディタと睨めっこしています。今年は「スクラム」をテーマに書いてみようと思います。
個人的には2012年頃にスクラム開発というものに出会い、それ以来、自チームでのスクラム開発の実践、別チームに移籍後にそのチームへのスクラム開発の導入、クライアントワークにおいてスクラム開発導入の支援など、様々な形でスクラムには関わり続けてきました。また、Scrum Allianceの認定スクラムプロフェッショナル・スクラムマスターでもあります。
本稿では、スクラムとはそもそも何なのか？我々が日々向き合っているスクラム開発はこれでいいのか？と言った自身の疑問からスタートした考察記事になります。この記事が読者の皆さんの組織での取り組みを見直すきっかけになってくれたらいいなと思っています。
スクラムとは？
まず初めにスクラムの一般的な定義から見ていきたいと思います。公式サイトなどの情報によれば、ジェフ・サザーランドとケン・シュエイバーにより1990年代初頭に開発された「複雑な問題に向き合い、価値を生み出すための適応型フレームワーク」と言ったところでしょうか。分かったような分からないような定義ですが、具体的には 各国語に翻訳されたスクラムガイド が提供されているので、スクラムのお作法などに関してはそちらを参考にしてもらえればと思います。ちなみにスクラムは「理解が容易」だけれども「習得は困難」と言われているので、一読して分かったつもりになってもやってみると意外と難しいと感じると思います。そんな時こそスクラムマスターやアジャイルコーチの出番ですので、もしスクラム導入でお困りの場合はお気軽にご相談ください（宣伝）。
スクラムの特徴
さて、先にあげたスクラムガイドに一通りスクラムの役割や各種イベント、作成物などの定義が書かれているので、それらを守ることでまずは「スクラム開発」実践のフェーズに入っていると言えると思います（本当に難しいのはそこからですが）。では、次に何がスクラムをスクラムたらしめているのかについて考えていきたいと思います。
よく、ウォーターフォール vs スクラム（やアジャイル）といった比較を目にすることがあると思いますが、スクラムも（ミクロで見れば）要件定義→設計→開発→テスト→リリースといった開発工程の順序は変わりません（テストファーストのような手法で部分的には変わることはあると思いますが、スクラムのプラクティスではないのでここでは同じとして扱います）。ただし、スクラムでは短い期間でスプリントを繰り返してプロダクトを少しづつ作っていきます。大きな開発工程を短い期間に区切って繰り返している部分には違いがありそうです。
次に、スクラムでよく使われる用語について考えてみます。
- スプリント
- 反復（イテレーティブ）
- 漸増（インクリメンタル）
- ユーザーストーリー
- 振り返り（レトロスペクティブ）
- デイリースクラム
- バックログ
- インクリメント
ざっとリストにしてみると、こういった言葉がよく使われるような気がします（よね？）。では、これらの内で何がスクラムを表す or 特徴づける要素なのかと問われたら、やはりスプリントが繰り返されているところ（よくぐるぐるした絵で表現される部分）ではないでしょうか。読者の皆さんが頷いていると言う前提で次に進みます。
ここで一つの疑問が出てきます。そのぐるぐるしたプロセスをなぜ「スクラム」と呼ぶのでしょうか。
スクラムの由来
ここで、「スクラム」の語源について考えてみたいと思います。知っている方も多いと思いますが、スクラム開発には元になった論文があります。1986年にHarvard Business Reviewに掲載された竹中弘高と野中郁次郎による「The New New Product Development Game」です（本稿では以降、竹中・野中論文と呼びます）。Webでも公開されており、DeepLなどを駆使すると一瞬で読めるので、これを機に是非原典にもあたってもらえたらと思います。この竹中・野中論文では主にハードウェアの新商品開発プロセスの分析を行なっており、そのプロセスに3つのタイプがあることを見出しています。タイプAが開発工程が順次処理されるリレー型、タイプBが前後の工程が重なった刺身型、最後のタイプCが複数の工程がオーバーラップするスクラム型です。当時、世界を席巻していた日本企業では様々な専門性を持ったメンバーが複数の工程を跨いで新商品開発に関わっており、その様子をラグビー選手がボールをチームで前に進めていくスクラムに例えて表現したものがスクラム開発の語源ということになります。
ちなみに、竹中・野中論文ではiterativeと言う単語は2回しか出てきません。代わりに多く使われているのは「rugby approach」という言葉で、これがscrumを表していることになります。
それって本当に「スクラム」ですか？
ようやく本題に辿り着きました。いつも我々が取り組んでいる / 向き合っているスクラム開発では比較的イテレーティブでインクリメンタルな部分に注目しがちですが、スクラムの原点である竹中・野中論文ではむしろ、複数の工程がオーバーラップし、その過程で多様な専門性を持ったメンバーが関わっていく部分に注目していました（スクラムガイドによれば「スクラムチームは作業に必要なすべてのスキルや専門知識を持つ人たちで構成されている」のでそういう意味では竹中・野中論文が注目したのと同じ要素は含まれています）。
本稿では、そのどちらが正しいのかといった議論をするつもりは毛頭ありません。ソフトウェアの開発ではハードウェアとは違ってインクリメンタルな手段をとることが可能であり、それは同時期に誕生したエクストリーム・プログラミングでも取り入れられている有効な手法であることは間違いありません。ただしその一方で、竹中・野中論文が注目しているような、多様性をもったチームメンバーが要件定義からリリースまでの複数の工程に関わっているかどうか、という点も自分たちのやり方を見直すポイントになるのではないでしょうか。
ここで、現場でも見かけるチームのパターンをいくつか見てみたいと思います。
大規模な開発プロジェクト
基本的にスクラムの想定しているスクラムチームのサイズはスクラムガイドにも示されている通り10人以下です。それを大幅に超えるような大規模な組織でスクラムに取り組もうとする場合には、SAFe（Scaled Agile Framework）やLesSS（Large Scale Scrum）、Scrum@Scaleなどいくつかのやり方が提案されています。本稿ではそれぞれの詳細については触れませんが、どんな手法を選んだ場合でも大規模な組織の全員がプロダクトの全貌を知る術はないことは明らかです（例えばLeSSではチームの代表者とそれ以外のメンバーでは触れられる情報量に差が出てしまいます）。このような状態で竹中・野中論文が言うようなスクラムチームを作るのは非常に困難です。この問題に関しては、完全に私見ではありますが、チームを分ける以上一定の分断や個人ごとに持っている / 触れられる情報量の差は受け入れざるを得ないので、逆コンウェイの法則を適用して、プロダクトのアーキテクチャに合わせて組織を構成し、それぞれのチームがフォーカスする領域の情報にメンバー全員がアクセスできる状態を保つのが一つの解決策になるのではないかと思っています。
ただチケットを消化する開発チーム
現場を見ていると、少人数で構成された1チームによるプロダクト開発の場合でも、実質プロダクトオーナーが単独で仕様を決め、開発チームはそれに従ってただ作るだけ（リファインメントが行われていない or 機能していない）というようなケースもあるような気がします。この場合は、イテレーティブでインクリメンタルに開発はしているように見えて、実際には大きな開発計画を小さく分割しているだけで、竹中・野中論文の言うようなスクラムチームにはなれていないということになるかと思います。現行のスクラムガイド（2020年版）にはリファインメントの詳細は触れられていませんが、過去のガイドやWebの記事などを参考にしながらエンジニアも積極的にバックログリファインメントの議論に参加していきましょう。プロダクトマネジメントにスクラムチーム全員が関わっていくことでプロダクトの成功確率も上がっていくはずです。
ここまで開発現場のパターン（と気をつけるポイント）についていくつか見てきましたが、スクラム開発自体はあくまでもHowなのでそれを正しくやれているかどうかは本質的な問題ではないと個人的には考えています（一方、スクラムガイドに載っているものは成功確率を上げるためのものでもあるので従う意味はあるとも思っています）。最終的にチームが目指すゴールである「プロダクトやサービスの成功」の確率を高めるために、竹中・野中論文で示された観点に限らず、チームの状況（メンバー構成やプロダクトの状況、変えられない社内のワークフロー、などなど）に合わせて、やり方を進化させていけると素晴らしいですね。
まとめ
本稿では、主にスクラム開発を行っている際に注目されがちなポイントと、原典である竹中・野中論文において注目されているポイントが違うことを見てきました。ただし、前述した通りスクラムガイドの定義には「スクラムチームは作業に必要なすべてのスキルや専門知識を持つ人たちで構成されている」とされているので、現在のスクラム開発が原典から大きくずれてしまったわけではありません。スクラムガイドはとてもシンプルで読みやすいですが、これまでの様々なプロジェクトの経験値の集合体からエッセンスを抽出したものとなっており、一つ一つのイベントなどにもちゃんとした目的があります。さらっと読んで理解したつもりにならないように、実践していく中で迷った時の羅針盤としてたまに見直すことで新たな発見があったりするかもしれません。年末のこの時期はちょうと良い機会かもしれないですね。
おわりに
最後まで読んでいただきありがとうございました。 それでは、良いお年を！
グッドパッチにはデザイナーとエンジニアという専門性の違うメンバーがアイデアと技術を持ち寄ってトライアンドエラーするようなプロジェクトチームでデザイン、開発を進めています。
デザインも開発も好きだという方、もしご興味をお持ちいただけましたら、気軽にカジュアルに面談からいかがでしょうか。 お待ちしています！😀
