はじめに
SWEとして仕事をし始めてから8年目にして初のスクラム開発を経験した．6か月ぐらい経ちその間に2チームでスクラムを経験してきたので所感を述べる．
自分が経験してきた開発手法
過去にいたチームでは，世間一般で言われるスクラム開発*1ではなく
- 毎日チーム内で進捗を確認（いわゆる朝会の運用）
- チケットはカンバンで管理
の２点だけを採用した開発プロセスだった．チームによって「タスクを誰が決めるか」「機能要件と非機能要件のベロシティのバランスをどう取るか」といった細かい点は異なっていたが，基本的には上記の2点だけは必須で行い，あとは割と自由，という感じの開発プロセスを複数の組織で経験してきた．2013年～2020年ぐらいの話である．
今のチーム
2021年にjoinしたチームは教科書どおりのスクラムをやっていた．自分は上述のような「なんちゃってスクラム」みたいな開発経験しかなく，自主的にもちゃんとしたスクラムを学んだことがなかった．そのため，今の組織にjoinした当初は「ストーリーポイントで相対見積もりをする」とか「すべてタスクの優先順位はチーム全員が合意して決める」みたいなプロセスを見た時に正直面食らった．これまでやっていたなんちゃってスクラム開発の延長ではなく，全く新しい手法としてスクラムの価値観をinputしていく必要があった．
スクラムやってみた所感
あらゆることが明文化されている
スクラムに関する所感として，まず感じたのは開発経験が浅いメンバーでもチーム活動に参加しやすいという点だった．スクラムではあらゆるプロセスのやり方が明示的に決められているため，「暗黙の了解で何となくやる」ということがなくなる．そのため成果が属人化しにくいと感じた．リファインメント，プラニングといったイベントですらそれぞれに進め方やゴールが決まっている．組織によってどのようなプロセス・ゴールを設定するかは異なると考えられるが，スクラムはとにかくあらゆるプロセスを明示的に定義することを重視していえるように感じた． また，明文化されていることでSWEとしての経験の差を埋めることができる．「経験10年ぐらいのSWEなら大体何となく知っている」暗黙知に依存すること無くチーム活動が出来るため，経験が少ないSWEでも１メンバーとして参加しやすい気がする．これはチーム間の知識の共有という点でも有効だと感じる．
ストーリーポイントによる相対見積についてはちょっと疑問がある
見積についても相対見積を採用している場合は基準となるチケットをもとに見積もれるので，経験が少なくても見積自体はしやすいと感じた．
ただ，チケットを担当して実施するSWEの力量に応じて実際にかかる工数は異なってくる訳だが，そのギャップをどう扱うかはいまだによくわかっていない．
一般的には見積で各チケットに設定したストーリーポイントの合計と実際に消化できたチケットのストーリーポイントの差が大きくならなければとりあえずは良いらしいのだが，この辺のベロシティの評価方法についてはまだ良くわかっていない． また，実際にチケットに着手する人の力量に応じてかかる時間は異なってくる訳だが，この力量の差はストーリーポイントには反映されておらず，ストーリーポイントがそのスプリントのキャパシティを示す指標として機能しているかは謎である．それでもスプリントを重ねることで「1スプリントで大体これぐらいはできる」という目安としてうっすらとキャリブレーションされてきたので，チームのキャパシティを示す基準になりつつはある．もう少し時間が経てば変わってきそうな気がする．
合意を取らないと何もできないので何でも人と話す必要がある
スクラムの原則は「合意していないことはやらない」だと理解している．これまで述べてきた通り，知識の属人化やスキル差を埋めるための知識共有という目的を考えれば理に叶っている．
一方で，「なんでも合意が必要」という成約は，毎回何かアクションを行う度に多大な合計形成コストを払わねばならないということでもある．
例えば，プラニングで合意に至らなかったチケットがそのスプリントで着手されることはない訳だが，自分としてはどうしてもそのチケットがそのスプリントに必要だと確信したとする．実際大したコストもかからないし手持ちのタスクを全部やっても間に合いそうな気がする．でも合意していないからそういうことは出来ない．正しい手続きとしては，ステークホルダーを全員集めて同期的もしくは非同期的に議論して合意を取らなければならない．例えば1 スプリントで終わる軽いリファクタリングについては，今までいた組織では個人の空き時間で自由にやることが比較的許されていたため，個人でスケジュール管理ができていれば何の問題にならなかった*2．しかしスクラムとなると話は別で，すべてが「チーム」で「合意」されている必要がある．しかも実施したタスクはすべて可視化されていなければならない．よって，個人のスケジュールが空いたならチームで合意したバックログの先頭のタスクをやらなければならないし，勝手にベロシティに計上されないタスクをやることは許されない．そしてリファクタリングといった非機能要件系チケットと新たな機能開発といった機能要件系チケットの優先順位を１つの軸で優先度付けるのってすごく難しい訳で，今いるチームだと機能要件が優先される．KRに定量的な「1 Quoterにおけるリファクタリングチケット数の割合」みたいなものが入ってなければそうなるのが当然である*3．
この点についてはどの程度スクラムに準拠するかという程度問題の気がするが，本当に教科書どおりにやるとこういうことになるらしい．スクラムって厳しいのな．
ただ，自分にとってはあまりに厳しすぎると感じたので，自分から提案してベロシティの10%は自由にバックログから取っていいという合意を得た．
おわりに
スクラムの「何でも明文化」するところは合理的だと感じたし，これまで自分がベストプラクティスだと考えていたものと合致している． 一方で，相対見積における個人の生産性の差の排除やチームの合意形成コストの高さついてはまだ課題を感じている． ただ，少なくとも2021年現在，自社開発をしている日本国内の組織においてはスクラムを採用しているチームが増えていると感じているので*4，今後の開発手法のデファクトスタンダードとしてスクラムは広まっていくだろうと考えられる．そのため今苦しくても苦しんでスクラム開発に慣れていくコストは無駄ではないと考えている．
*1:何が正式なスクラムなのか分かってないが，本記事では「POとScrumMasterがいる」「スクラムイベントを全部やっている」「割り込みは禁止」「チームで合意したこと以外は勝手にやっちゃダメ」「ストリーポイントは相対見積でプランニングポーカーで行われている」「ベロシティを毎週計測する」みたいなスクラムの教科書に書いてある手法に則ったスクラム開発を指す
*2:前職では手が空いている時に限り2週間までは好きにやれ，2週間を超えそうな場合はちゃんとDesignDocを書いてチームを説得せよ，というルールだった
*3:逆にこれをKRに入れてみるのは案外アリな気がしている
*4:同業者の知人との会話などからそう感じた
