はじめに

スクラムマスターチェックリストの最新版が公開されました。
翻訳に関われたので、報知の意味もかねて、Qiitaで展開しておきます。

以下は抜粋版です。チェック項目を上から順に5個ずつに抜粋してます。
是非、本体のスクラムマスターチェックリストをご覧ください。

注意事項

この記事はあくまで、2018/12/18版の話でしか無いです。
最新版の確認は上記リンクをご覧ください。

スクラムマスターチェックリスト（抜粋版）

フルタイムで関わっていますか？

“まずまずな” スクラムマスター は、一度に2つまたは3つのチームを受け持ちます。
スクラムマスター の役割を「ミーティングの主催」、「タイムボックスの管理」、および「チームから報告された問題への対処」に限定すれば、パートタイマーながらなんとか上手くやることができるでしょう。 そのような状態であってもきっと、チームは組織のベースライン（スクラム前の期待値）を上回っているでしょうし、この先も致命的な問題は発生しないでしょう。

しかし、前人未到な出来事を成し遂げる素晴らしいチームをイメージすることができるなら、（変革した組織の中で）”卓越した” スクラムマスター になれる可能性があります。

“卓越した” スクラムマスター は一度に1つのチームだけを受け持ちます。

スクラム の導入時期においては特に、献身的なスクラムマスターをチーム毎に1人用意することをお勧めします。

特にやることが無いなら、「プロダクトオーナー」「チーム」「開発プロセス」「（チーム外の）組織」を観察してみましょう。 誰にでも効く特効薬では無いですが、スクラムマスターが見落としがちなポイントをまとめてみました。以下のそれぞれのボックスに、 √, ∆, ?, もしくは N/A をつけてみてください。チェックの付け方は一番最後のページに記載しています。

（このQiita記事にはチェックの付け方は書いてません。こちらの最後のページを確認ください。）

Part I -- プロダクトオーナー はどうしてますか?

スクラムマスターがプロダクトバックログやリリースプランの調整の仕方に対してアドバイスなどを行えば、プロダクトオーナーはより効果的に動けるようになるでしょう。(注意：バックログの優先順位づけに対して責任を持つのは、プロダクトオーナーです。)

• ☐ プロダクトバックログは、プロダクトオーナーの最新の考えに基づいて、優先順位付けされていますか？
• ☐ 全てのステークホルダーの要求事項がプロダクトバックログに取り込まれていますか？ （注意：バックログは “徐々に明らかになるもの” です。）
• ☐ プロダクトバックログは管理可能なサイズですか？ PBI（プロダクトバックログアイテム）の数を管理可能な数に調整し、具体的なものを上に、曖昧なものは下にするようにしよう。 あまりにも下位にあるPBIを具体化するのは無駄です。 なぜなら、ステークホルダーや顧客がプロダクトに触れた結果生まれたフィードバックを受けて、あなたの要求は変わるからです。
• ☐ 要件（特に、バックログの上にある要件）は、INVESTなユーザーストーリーとして表現できていますか？INVESTとは、Independent（独立している）・Negotiable（交渉可能である）・Valuable（価値がある）・Estimable（見積可能である）・Small（小さい）・Testable（テスト可能である）であることです。
• ☐ プロダクトオーナーに「技術的負債とは何か」「技術的負債を避ける方法」についてレクチャーしていますか？ 1つの解決策としては、自動テストとリファクタリングを、PBIの「Done」の定義に取り込むことです。

（チェック項目は結構省略してます）

Part II -- 開発チームはどうしてますか?

チームメンバーの協働を推進することがスクラムマスターには求められますが、技術的な作業においてはスクラムマスターが上手く推進できない可能性もあります。 スクラムマスターが担うべき、チームに対しての主要な責任について考えてみましょう。

• ☐ チームは”フロー状態”にありますか？
• ☐ チームメンバーはお互いが好きで、一緒にバカができて、お互いの成功を祝っていますか？
• ☐ チームメンバーはお互いに、高いレベルで責任を持ち、成長を目指して挑戦していますか？
• ☐ 議論するのを極端に不快に思うあまり、議論を避けているような問題はありますか？
• ☐ スプリントレトロスペクティブにおいて、いろんな場所ややり方を試しましたか？

（チェック項目は結構省略してます）

Part III -- 開発プロセスはどうなってますか?

• ☐ 開発中のシステムには誰でも（同じチームはもちろん、別のチームでも）、回帰テストの失敗（前は動いていた機能が壊れた）が簡単に検出できる「プッシュテスト」ボタンがありますか？ 通常、これはxUnitフレームワーク（JUnit、NUnitなど）で実現されます。
• ☐ 自動エンドツーエンドシステムテスト（機能テストなど）と自動単体テストとで、適切なバランスが取れていますか？
• ☐ チームは開発システムと同じ言語でシステムテストとユニットテストの両方を書いていますか？ そのツールだけで使うスクリプト言語や、チームの一部のみがメンテナンス方法を知っているようなツールでは、コラボレーションが強化されることはありません。
• ☐ チームは、システムテストと単体テストの間にある、重要でグレーな領域を明らかにしましたか？
• ☐ 回帰テストが失敗した時、CI（継続的インテグレーション）サーバーは自動的に警告を通知しますか？ また、このフィードバックループを数時間または数分間に短縮できますか？ （「Daily builds are for wimps.（毎日のビルドは弱虫のためのものです）」 - Kent Beck）

（チェック項目は結構省略してます）

Part IV -- チーム外の組織はどうしてますか?

• ☐ チーム間コミュニケーションの量は適切ですか？ 「Scrum of Scrum」はこれを達成するための方法の一つではありますが、多くの場合において最善の方法ではありません。
• ☐ チームは独立して動くソフトウェアを作成できますか？ 技術領域をまたいだチームになっていますか？
• ☐ 複数のスクラムマスターがいる場合、お互いに会話し、組織の課題を一覧化していますか？
• ☐ 組織上の問題はマネージャーのオフィスの壁に貼り付けられていますか？ 市場投入までに浪費した時間や、失った品質や、顧客機会の喪失などのコストを、お金で数値化することはできますか？ （Ken Schwaberの失敗から学びましょう：「A dead ScrumMaster is a useless ScrumMaster.（死んだScrumMasterは役に立たないScrumMasterです）」）
• ☐ チームの目標と、組織の人事制度における評価基準は一致していますか？ テスト、テスト自動化、ユーザードキュメントを犠牲にして、プログラミングやアーキテクチャーの仕事をすることが評価されるような組織であるなら、答えは「いいえ」でしょう。

（チェック項目は結構省略してます）

結論

上記チェック項目のほとんどをチェックしても、まだ時間が残っている場合は、ぜひあなたのお話を聞かせて欲しいです。
人間の創意工夫を生み出す公式はどこにもありません。 このチェックリストに列挙したポイントは、あなたの役立つかもしれないし、役に立たないかもしれません。
差をつけるためにあなたができることに気づいたのに、それを実行に移すのに恐怖を感じているかもしれません。 ただ、その恐怖は、あなたが正しい道を歩み始めた証拠です。

さいごに

正直、スクラムの理解はまだまだ途上ですが、こういった情報を拡散することで、少しでもスクラムの考えが広まれば良いなと思っております。

以上です。