まえがき(読み飛ばし推奨)

冗長であんまり面白くないので折りたたみ化

新卒でIT企業に入ってから7年、ずっとアジャイルないしスクラム(という体の)のチームで開発を行ってきました。
しかし、一貫したアジャイルやスクラムに関する知識・理解を持った人がおらずだんだんやり方が崩壊していきなんちゃってアジャイル・なんちゃってスクラムになってしまうことが常でした。

これではだめだと思い、スクラムに対する一貫した知識・理解を得るため一念発起してこの認定スクラムマスター研修に行ってきました¹。

認定スクラムマスター研修開催のお知らせ(開催日：2019年5月23-24日) | Attractor Inc.

受講の感想としては非常に良かったです。
特に受講者と講師のガビィ先生・原田先生の間のQAが非常に勉強になり、以前から抱いていた問題の回答が得られていたり誤解していたことに気付かされることが数多くありました。

この記事ではその講義の中で得られた気付きや従来誤解していたことを列挙します。私と同じようにスクラムに悩むエンジニアの助けになれば幸いです。

免責

以下の疑問・誤解に関する回答は基本的に研修での原田先生・ガビィ先生と参加者間の問答・回答を基に書いていますが、私の記憶・メモから文字を起しており仮に間違った記述や発言が書かれていた場合はすべて私の責任ですのでご了承ください。

研修を受けて解消した疑問・誤解一覧

アジャイル ≒ スクラム？

A. スクラムはアジャイル開発の手法の一つです。つまり アジャイル ∋ スクラム

スクラムの他にLeanやXP, Crystal, Kanbanなどがアジャイル開発として挙げられます。
研修中に何度かスクラムのやり方とアジャイルソフトウェア開発宣言の関係性について言及されましたがスクラムの精神性とアジャイルソフトウェア開発宣言は相反するものではなく、スクラム開発はアジャイルソフトウェア開発宣言へ完全に基づいています。

スクラムチームのメンバーは全員フルスタックエンジニアである必要がある？

A. 個別のメンバーがフルスタックである必要はありません。チーム総体としてフルスタック ≒ 機能横断的であればOKです

比較的よくある誤解だと思います²。

スクラムガイドによると

機能横断的チームは、チーム以外に頼らずに作業を成し遂げる能力を持っている。
...
機能横断的である。インクリメントを作成するスキルをチームとしてすべて備えている。

と書かれていますが チームとして という部分がポイントで、いわばチームメンバー全員の合算としてフルスタックであれば個々のメンバーがフルスタックである必要はありません。
極端なことを言えばチームに必要な技能³それぞれを最低１人が遂行できるならOKとなります。
逆にだめな例を挙げるとインクリメントを作成するために必要なデザインなどをチーム外⁴に委託している場合です⁵。

リファクタリングをスクラムのタスク・ストーリーとして扱って良い？

A. 駄目ですが、それはリファクタリングをしない・しなくてよい・するべきでないという意味ではありません。

講義中での回答はストーリー・タスクの中で必要なリファクタリングは常に行えという回答でした。

これはアジャイル宣言の背後にある原則の以下に基づいているそうです。

アジャイル･プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。

継続的なリファクタリングなしには開発プロセスを長期的に持続可能にはできないことはもはや常識です。
スクラムという開発フレームワークにおいてリファクタリングを特別に扱うメソッドはありませんが、開発を長期的に維持可能にするためには常にリファクタリングをする必要があるということです。

ただし、上記のような持続可能な開発の視点をチームで共有できていないとタスク・ストーリーの消化に執着するあまりリファクタリングを後回しにしがちなため、チーム全体での正しい理解と実践が必要です⁶。

大規模なアーキテクチャ変更やMVCからDDDにコードを変えるなどの大規模なリファクタリングはどうするのか

これについては直接の質問がなかったので上記原則に照らし合わせて僕が出した結論になります。

まず第一に、これらはユーザーに直接的な価値を届けないためスクラムのストーリー・タスクとして扱うことは正しくありません⁷。
つまりスクラムというフレームワークの扱う対象の外、範疇外になります。
一方でそれらの変更は今後の持続可能な開発に必要なはずです⁸。

主な対策は2つあると思います。

1つは通常のスプリントの裏で徐々に改善していく方法です。
スクラムで可視化されないため状況が見えにくいですが、通常のインクリメントを維持しつつ漸近的に目的を達成できます。
またそのためにベロシティが下がる・下げることはやむを得ないと思います。

どうしても大規模な修正を一度にする必要があるケースでは⁹、一時的にスプリントを止めることが考えられます。
スプリントを停止している間、集中的にアーキテクチャやコード状況を改善して可能な限り早くスプリントに戻るアプローチです。
しかしこれによるスクラムチームへのダメージは想像できないのでできる限り回避したほうが良いと思います。

既存のコード・アーキテクチャがひどすぎてスクラム開発の障害になっている

これも実際の質問はありませんでした & スクラムガイドなどでそれについて明確に扱ったトピックはないため、講義中に聞いたこととスクラム・アジャイルの原則に照らし合わせて私が導いた結論になります。

まず、この問題は 持続的な開発が可能かどうか で2種類に大別できると思います。

現状でもまだ持続的な開発 = インクリメントの作成が可能な場合、徐々にスプリントの裏で改善していく手があります。

現状で持続的な開発 = インクリメントの作成が不可能またはほとんど不可能なレベルでひどい場合、もはやその状態はスクラムの範疇外でスクラムの枠組みでは扱えません。
スクラム開発を始める前に集中的に直してしまうのは一つですが、既存のコード・アーキテクチャをすべて捨てて使えるデータ・コード部分のみ引き継いで一から開発を行う方が良いと思います。⁹。

スクラムは短期的なプロジェクト用？

A. いいえ、中長期的なプロダクトの育成プロジェクト用です

スプリントという言葉が短距離走のイメージを誘発するためか、受託開発のような短期的なプロジェクトにスクラムが向いているという勘違いがたまにあります。
スクラム開発にこれができたら終了といった最終ゴールはなく、プロダクトオーナーが定めたプロダクトのビジョンがありますがそれは完了する性質のものではありません。

スクラムでは10人を超える大規模開発はできない？

A. いいえ、LeSS、Scrum at Scale、Scrum of Scrumsなどの手法がすでにあり、自動車製品用のソフトウェアを数百人規模のスクラムで開発したというような成功事例もすでに存在するそうです¹⁰

チームは開発効率を上げるためベロシティ = より多くのストーリーポイントの消化を追い求めるべき

A. いえ、チームが追い求めるのはアウトカム(=成果、DAUや売上、DL数など具体的な指標)であってアウトプット(実装した機能数・修正数)ではありません¹¹

前述の通り、従来の手法では実装する機能の2/3は使われないことになります。
スクラムチームは月当たりの新機能数やコード記述数を減らしてでも、ユーザーが必要としている機能はなにかを考え、実装します。

よいチームは必ずベロシティが高いですがベロシティが高いチームは必ずしも良いチームとは限りません。ベロシティはあくまで指標です。
ベロシティを高めることを目標とすると、人間どうしても徐々にストーリーポイントの基準がぶれて同じぐらいの難易度のストーリーでもどんどんストーリーポイント見積もりがインフレしていくという話でした。

プロジェクト開始時のサーバの用意やCI・CD環境構築、開発環境準備などもスクラムのタスクとして扱う？

A. 扱いません。プロジェクトのためにホワイトボードや付箋、機能横断に必要なメンバーをチームへ集めることと同様にスクラムの範疇外になります

人や本によってはスプリント0としてこれを扱うことにしている場合がありますが、スクラムが定めるスプリントの定義から外れるのであまり良くないというのが原田先生の意見でした。
スクラムに対する理解はただでさえ混乱や誤解が多いので¹²、余計な混乱を避けるために僕もスプリント0という単語は使わないほうが良いと感じました。
単に「スクラム開発の準備」と呼べばいいと思います。

リモートでスクラムすることは可能？

A. 可能であり、成功事例もたくさんありますが基本的にオンサイトでの開発より難易度は上がります

最初からリモートでスクラムを行うことは難しいという話で、失敗談も結構あるようでした。
そのようなときに解決する手段が一旦同じ場所に一定期間いて開発を行い、その後リモートへ移行するとうまくいきやすいそうです。
いわゆるキックオフ合宿やオンボーディングと言われるプロセスのようです¹³。

弁当が美味しい

関係ないですが、研修中に出たお昼のお弁当が美味しかったです。3~4種類ぐらいありかつなかなかお高いお弁当でした。

Jiraなどのツールを最初から使うべきではない

特に初心者スクラムマスターはふせんを使うことを強く推奨されました。
Jiraを使ってプロダクトバックログ・スプリントバックログを管理することは無論できるのですが、特に初心者スクラムマスターは道具に踊らされがちであり¹⁴、
またあらゆるPB, SB管理の基本はふせんというのがその理由だそうです。

スクラムマスターは開発メンバーと兼任してOK？

A. 駄目です、初心者スクラムマスターは特に兼任してはいけません。

スクラムマスターは特にチーム組成直前~直後からチームが上手く回るまでの間の負荷が高く、とても初心者スクラムマスターが開発の片手間で行えるものではありません。
もし初心者スクラムマスターが開発を最初から兼任した場合¹⁵、以下のどれかになるそうです。

スクラムマスターが正しく自分の役割を果たすことができず、チームが壊れる
正しいスクラム開発ができず、妥協してなんちゃってスクラム開発になる
スクラムマスターの負荷が高くなりすぎて本人が健康状態を壊す

少なくともチームが十分に軌道に乗るまでは(原田先生によるとうまく行ったパターンのスクラムチームが1から軌道に乗るまでだいたい3ヶ月ぐらいだそうです)開発メンバーとスクラムマスターを兼任することはやめましょう。

朝会に参加しないメンバー、やる気のないメンバー、スクラム開発へ強弁に反対するメンバーはどうする？

A. スクラムマスターは問題の解決に動きますが、一方で問題原因がスクラム外にある場合はスクラムの範疇外です

スクラムマスターは原則的にスクラムで発生するあらゆる問題に対処する義務があるため、朝会に参加しないメンバーなどに対してはまず本人に理由を聞くことから始めます。
例えばそれが家庭の事情や本人の健康状態などが理由で参加できないようなら、時間を変更する、リモートで参加できるようにするなどの対策を行います。
やる気のないメンバーはスクラム開発の背景や意義・意味の理解が足りないかもしれません。もしそうならスクラムマスターは改めて説明する必要があります。

一方で問題原因をスクラム内で解決できない場合があります。
例えば特定のメンバーを不当に低い賃金で雇用している、アンフェアな契約で縛っている、本人のキャリア志向と現在の役割が一致していない、などです。
このようなケースはスクラムマスターとして解決することはできません。
スクラムの枠組みではなく単なる同僚・上長として問題の解決に当たるか、さらに上長へ解決を依頼することになると思いますが、そこはスクラムの定める枠組みの外側です。

スクラム対象のプロダクトに関係しないが開発メンバーが行っているタスク(そのメンバーが過去に関わったプロダクトの保守作業など)をバックログに追加していい？

A. いいえ、バックログには対象のプロダクトに関係したストーリー・タスクのみ追加します

スクラムはプロジェクトマネージメントではなくプロダクトマネージメントなので、人中心ではなくプロダクトを中心にします。
そのためそのようなスクラムに関係しない作業はスクラムの枠組み外でそのメンバーが行うことになるでしょう。

スクラムチームはそのメンバーがその保守作業を行うことを織り込んだ上でのベロシティになりますが¹⁶、
スクラムマスターはそれを障害と捉えて解決に向かったほうがよいかもしれません。

スクラムマスターはチームに干渉しすぎない

スクラムマスターはスクラムに関してメンバーがわからないこと、知らないこと、間違っていることなどは積極的な助言を与えますが、
発生している問題の原因推測や問題に対する解決案などは与えません。それらはメンバー自身に考え、調査し、推測し、決定することを促します。

そのために5 Whys aka なぜなぜ分析といったテクニックや、必要と感じたときに何時間でも沈黙して自ら考えることを促したり、あえてデイリースクラム・スプリントレビューに参加しなかったり¹⁷します¹⁸。

逆にそういったことをしないと意思決定がスクラムマスターに依存してしまい、チームのものになりません。メンバーの責任感も希薄なままになってしまいます。

完成の定義(Definition of Done)と受け入れ条件(Acceptance Criteria)の違いは？

A. 完成の定義は開発チームが管理するもので全インクリメント共通。受け入れ条件はプロダクトオーナーが主体的に決めるものでストーリー毎に固有

完成の定義は開発チームが管理するもので、例えば以下のものが挙げられます。この内どれらを選択するかはチームに寄ります。

新規コードの単体テストが存在
単体テストをすべて通過
テストカバレッジがXX%以上
新規コードの受け入れテストが存在
受け入れテストをすべて通過
新規機能のドキュメントが書かれている
負荷テストがに合格している
クラス図が更新されている
・・・

これらはすべてのインクリメントで共通したもので、ストーリー毎に代わることはありません。

一方受け入れ条件はストーリー毎に固有のものです。
これを満たしたストーリーはリリース判断可能であると見なします。
これはプロダクトオーナーが責任を持って決めます。

スプリントゴールはどうやって決める？

A. まずプロダクトオーナーがそのスプリントで達成したいゴールを決めます。その後それを達成するために必要なプロダクトバックログアイテムをスプリントバックログへ入れます

今までのなんちゃってスクラムでは、まず過去のベロシティ実績を上限にプロダクトバックログアイテムを優先順位の高い順に無条件でスプリントバックログに入れていました。
その後ゴールを決めるため、ゴールがプロダクトバックログアイテムの総和になり非常に長くなったり特定のPBIにのみ言及されたものになった結果、スクラムの価値基準である集中(フォーカス)が失われていました。
ひどいときにはその結果ゴールを決めること自体をやめたこともあります。

ゴールとPBI(プロダクトバックログアイテム)は相互に関係していますが、基本的にゴールが上位の概念でそれを実現するための詳細がPBIです。
そういった決め方をするには、プロダクトオーナーは次に達成したいゴールを考慮しつつ日頃からプロダクトバックログアイテムを充実させておく必要があるでしょう。

スクラムの導入に上長やCXOが前向きでないけどどうすれば？

まずスクラムマスターの責任として、ステークホルダーたる彼らに十分スクラムを説明する必要があります。
その上で十分な理解が得られれば問題ありません。

もしそれでCXOが不安を感じていたり導入に反対である場合は空間的・時間的な部分で導入することが提案されていました。
例えば全社的に導入することはリスクが大きいため、まず1チームを社内で組織して見てトライアルしてみる、
1チーム内で変える場合は一旦3ヶ月間スクラムにしてみる、などです。
ただし、ごく短期間のスクラムで成果を出すことは難しいので最低でも2ヶ月以上は行ったほうがいいように思えます(特にスクラム初心者ばかりの場合は)。

スクラムは経験主義に基づいているので個人の経験・意見を強く反映させる

A. 間違いです。個人ではなく客観的な実験・観察に基づいて判断を行います

経験主義についてのありがちな勘違いです。

以下経験論 - Wikipedia(= 経験主義)からの抜粋です。

経験論における「経験」という語は、私的ないし個人的な経験や体験というよりもむしろ、客観的で公的な実験、観察といった風なニュアンスである。したがって、個人的な経験や体験に基づいて物事を判断するという態度が経験論的と言われることがあるが、それは誤解である。

スプリントレビューで受け入れ条件を満たせなかったPBIはどうなる？

A. バックログに戻して再度見積もります

そのため、仮にそのPBIを将来達成したとしてもそこに注ぎ込んだ時間はベロシティに反映されることなく失われることになります。
私見ですが、これはスプリント毎にPBIを完成させることの心理的インセンティブを上げる仕組みなのではないかと考えています。

イテレーション？スプリント？

A. スクラム的にはスプリントです¹⁹。

スクラムでは同じことを繰り返さず(イテレートせず)。スプリント毎に毎回前回よりも改善していきます。
トヨタの片山さん的には「改善のサイクル」と呼んだほうがいいんじゃないかとのこと。

蛇足

こちらにより雑多なメモと認定スクラムマスター研修参加の詳細な感想を書いていますので興味が湧いた人はどうぞ。

スクラムマスター研修受けてきた - kbigwheelのプログラミング・ソフトウェア技術系ブログ

会社を説得することが手間でしたので私費で行ったんですが、この先社内でスクラム体制を強力に取っていくためには最初から会社側に初期投資をしてもらった方が良かったかもしれません。 ↩
これについては実際は研修受講前に知っていましたが、つい最近まで誤解していました ↩
例えば設計、アプリ開発、ウェブフロントエンド開発、バックエンド構築、API設計、UIUXデザイン、テスト、CICD構築など ↩
文字通りチーム外の時点でNGで移譲先が社内だろうがだめです ↩
ただし、後述のスクラムマスターの行いにより、よいスクラムチームは全メンバーがだんだんフルスタックに近くなります ↩
その正しい理解へ導くのはスクラムマスターの責務なんですけどね。 ↩
アーキテクチャの改善によりレスポンスタイムが2割改善するからユーザーに価値が届いているよね？だからストーリーにしようという屁理屈をたまに聞きますがこれはバッドプラクティスだと思います。というのはそうやってこじつけたメリットはプロダクトオーナー・ステークホルダーにとって優先度が高いものではなく、たいてい開発チームの都合でストーリーの優先度がトップに置かれるんですがPO以外がストーリーの優先度を変えることはスクラムの原則を大きく歪めるためです。 ↩
でないとそれらが必要となるはずないですよね ↩
この手のビッグバンアプローチが必要だというのは、特にクラウド環境を使っている場合はほとんどの場合勘違いで大抵徐々に変えていく方法があります ↩
ただ、僕自身そのような大規模プロジェクトに関わったことがなく関わる予定もあまりないのでここに関する関心は薄めでした。裏取りや詳細調査もしていませんのでここは講師さんの受け売りのままです ↩
アウトプットではなくアウトカムというのは研修中に聞いた最も印象深いキーワードの一つでした ↩
ごく最近に出てきた概念ですのでしょうがないですが ↩
なのでここでの解決策はスクラム固有のものではなく、リモート開発に共通するものかもしれません ↩
JiraでXXできる？この機能ある？これをするにはどうすれば？というように本質でないJiraの仕様に踊らされて本来のPB・SB管理の目的をよく見失ってしまうそうです ↩
すごくありがちな話ですよね。過去の私が経験したなんちゃってスクラムはすべてこのパターンでした。 ↩
決してスクラムでそのメンバーの基本就業時間すべてを使わせ、その他のタスクを残業としてやらせるようなことをしてはいけません。それは開発が持続可能でなくなります。 ↩
ScrumMaster Incognito - Published Patterns 地面に倒れ込んでデイリースクラムに参加しないスクラムマスターの図 ↩
無論十分な信頼関係を構築してかつスクラムに対する説明を十分行った後である前提です。特になぜなぜ分析は使い方を間違えると失敗したものに対する詰問になってしまうので心理的安全性を確保した上で行いましょう ↩
スクラムガイドより ↩

認定スクラムマスター研修を受けて解消したスクラムに関する私の21個 + αの疑問・誤解