スクラム開発を経験してわかった「やらないほうがいいこと」（開発者目線）
はじめに
開発者としてスクラム開発を経験して、私が感じた**「やらないほうがいいこと」**をスクラムイベントごとにまとめました。
開発者目線だけではなく、スクラムの中の1人のメンバーとしての目線も含まれています。
※ 本記事の内容は内容はあくまで私個人の見解であり、所属企業における立場、戦略、意見を代表するものではありません。
デイリースクラム
「忙しい」を理由にかんばんボードのステータスを更新しないこと
忙しいあなたの状況こそが、デイリースクラムで最も共有されるべき情報です。
進捗が滞っていることを正しく共有して、対策を講じてもらうように働きかけたほうが、その状況が正しく改善されます。
「忙しいから、かんばんボードのステータスの更新に手が回らない」ではなく「かんばんボードのステータスの更新ができていないから、忙しくなる」ということです。
議論すること
デイリーで課題を共有すると議論が発生しがちです。
しかし、デイリーで議論すると議題に関係ない人の時間を奪ってしまいます。
議論になりそうになったら、デイリー以外の時間で関係者のみを集めて、議論したほうがいいです。
【参考】
・「朝会」といってもどうやら流派が存在するらしいので整理してみた
プランニングポーカー
バックログの仕様を理解していないこと
ポーカーではなく仕様の確認にかなりの時間が取られます。
もし、仕様の確認が十分にできていないなら、ポーカーとは別に事前に仕様の確認をする場を設けた方がいいです。
開発力の高い人がつけたポイントに合わせること
開発力の高い人と見積もったポイントがずれていた場合、「自分が誤ったポイントを見積もっている」と感じて、その人のポイントに合わせがちです。
しかし、当たり前のことですが、開発力が高い人ほど見積もるポイントは低くなります。
（もちろん、そうでもない場合もあります。）
そんな人の見積もったポイントに合わせると、チームのベロシティを超えたバックログをスプリントに投入されてしまい、スプリント中にバックログを消化しきれないことになります。
最終的にチームが出すポイントは、一人で開発するのではなく、チーム全体として開発するということを意識して、ポイントをつけた方が安全です。
（単純にリスクヘッジするなら、ポイントが割れた場合はポイントの高い方に合わせた方が安全です。そうして生まれた余力を技術的負債の返済に当てるなどして有効に活用しましょう。そのためにも技術的負債は常に返済できるようにバックログなどで見えやすい場所にリストしておくと良いです。）
スプリントプランニング
バックログの仕様に疑問点があること
この段階で仕様に疑問点があると、スプリントプランニングが仕様についての Q&A 大会になってしまいます。
仕様に関する疑問点は事前にできるだけ解消しておいたほうがいいです。
バックログのボリュームが巨大なままであること
1つのバックログのボリュームが巨大であると、プランニングの際にそのバックログが扱いづらくなります。
プランニングポーカーの段階でボリュームの大きいバックログは事前に把握しているはずなので、そのような巨大なバックログは事前に分割しておくとプランニングの選択肢が広がります。
また、巨大なバックログをひとつのスプリントで対応するのは危険です。理由は不確実性が高いからです。
分割可能であれば、分割して複数のスプリントで少しずつ作っていくこと（＝不確実性の削減をしていくこと）で、途中での軌道修正も比較的簡単に行うことができます。（これこそアジャイル開発の恩恵）
【参考】
・日本にアジャイルが普及しづらい本当の理由〜不確実性に向き合うマネジメント論〜
「Ready」になっていないバックログをスプリントに投入すること
当たり前ですが「Ready」になっていないバックログについては、スプリントが始まってもまともに開発に着手することはできません。
何をもって「Ready」にするかはプロジェクトごとに異なりますが、定めた「Ready」の定義が満たされていないバックログが平然とスプリントに投入されそうになったら、開発者側が表立って声をあげましょう。
スプリントにエントリーされたバックログが完了しなかった場合は、そのバックログを受け入れた開発者側の責任になってしまいます。
スプリント期間中
仕様に対する Q&A に臆すること
そもそも論としては、プランニングポーカー > スプリントプランニングを経ているので、この段階で仕様に関する Q&A が発生するのはおかしいはずです。
しかしながら、実際のところ、実装して初めて気づく仕様の疑問点は山のように出てきます。
『どうして今更そんな質問をするのか？』、『 Q&A はなるべくまとめてお願いします（怒）』と言われがちですが、疑問点があるならば臆せず質問するしかないです。
疑問点を解消せずに都合の良いように解釈して実装を進めると、そういうものに限って、あとで問題が発生することが多いです。
なぜならば、この時点で疑問が生じるということは設計段階でそもそも考慮していない内容である可能性が高いからです。
開発チームに相談せずに機能追加/修正すること
そんなことをするとスプリント開始前に行ったプランニングポーカーやスプリントプランニングが意味をなさなくなり、開発チームのモチベーションが低下します。
そういった場合は必ず開発チームに相談しましょう。
相談された開発チームも「スプリント中の要件の追加は NG です」とすぐにつっぱねるのではなく、プロダクトオーナーと相談し、優先順位の低いバックログの対応を落とすなどして、できるだけ調整して受け入れましょう。
信頼を得るチャンスでもあります。
リファクタリングしないこと
スプリントを終わらすことを優先し、リファクタリングを疎かにすると技術的負債がどんどんたまっていくばかりです。
技術的負債はこまめに返済しないと雪だるま式に膨れ上がり、いずれ、リファクタリング不可能な状況になってしまいます。
そうならないためにも、「リファクタリング用のバックログを設けてもらって一気に返済しよう」などと思うのではなく、気付いたタイミングでこまめにリファクタリングしたほうがいいです。
また、リファクタリングには既存機能を担保するリグレッションテストがセットになり、そのためにもテストの自動化はほぼ必須になります。
マージリクエストをスプリントの最終日に出すこと
マージを優先するため、レビューの質が落ち、結果的に品質が落ちます。
スプリントの期間をのばすこと
予定していた期限にスプリントが終わらないということは、どこかに問題があるということです。
その問題をレトロスペクティブで振り返り、次のスプリントから改善するアクションをとっていかないと、問題は残ったままになります。
つまり、スプリント期間をのばしても、発生している問題は改善されず、スプリント期間の延長が繰り返されるだけです。
【参考】
・スクラムマスターがやること、やらないこと - アジャイルトレーニングの専門家に聞いてみた
スプリントレビュー
業務上あり得ないデータを用いること
スプリントレビューは業務に詳しい関係者が出席することがほとんどだと思います。
業務上あり得ないデータが仮データとして入っているようなアプリのデモを見せると、その機能がスプリントで開発対象かどうかにかかわらず質問が飛んできます。
余計な議論を避けるためにも、スプリントレビューで使用するデータには気を配った方がいいです。
得られたフィードバックの取り扱いを曖昧にすること
バックログに積んで次回のスプリントで対応するのか？、すぐに対応するのか？、すぐに対応するならその期限は？、優先度は？、そもそも対応しないのか？
得られたフィードバックに対してこの辺が曖昧なままスプリントレビューが終了したら、すぐに関係者を集めてその整理を行ったほうがいいです。
そうしないと、得られたフィードバックが空中浮遊したまま誰も手をつけない状態になってしまいます。
【参考】
・スプリントレビューのチェックポイント
スプリントレトロスペクティブ
改善タスクをボランティアにすること
『じゃあ、その改善案の実施を ○○ さんやっておいてくださいね。あ、もちろんそれとは別に、スプリントのバックログもちゃんと消化してね。』
このように「仕事」として認識されない改善タスクは実施されません。
本当に解決したい課題があれば、スプリントのひとつのバックログ（もしくはスパイク）として扱って対応したほうがいいです。
「言ったもん負け」にすること
改善案をあげた人に改善タスクを実施させること =「言ったもん負け」の状態は非常に危険です。
「言ったもん負け」の環境では誰も「改善」の声を出さなくなります。それはすなわちスクラムの終了を意味します。（これはレトロスペクティブに限った話ではないです。）
そして「言ったもん負け」の状態からの脱却は、メンバーの性格や組織の風土に関わるもののため、非常に難しいです。
こうなってしまったら、レトロスペクティブであがった改善タスクに対する運用のプロセスをルール化していくしかないです。
（しかしながら、レトロスペクティブをそのようなプロセスでぎちぎちに固めてしまうと、レトロスペクティブがとても雰囲気の堅いイベントになってしまいます。）
【参考】
雰囲気の堅いレトロスペクティブに是非。
・レトロスペクティブのおすすめアクティビティ
プロダクトバックログリファインメント
やったことないのでわかりません。
さいごに
もちろん、これがすべてではないですし、絶対でもないです。
組まれるスクラムごとに抱える課題が違って、それを改善していくのがスクラムの面白いところでもあるので、ここに書いたことにも囚われずに、Happyなスクラム開発ができたらと思います。
Discussion