新米スクラムマスターの思考メモ（その１ スクラムマスターになるまで）
はじめに
#今回、縁あって短い期間ではありますが、社内プロジェクトでスクラムマスターを担当することになりました。社内プロジェクトには数か月前から参加していましたが、参加以前はスクラムについて何となく知っている程度でした。当然、スクラムマスターとしての経験はありませんでした。
この記事では、スクラムマスターを担当するにあたって、新米スクラムマスターの視点で感じたことや考えたことなどをまとめてみたいと思います。
スクラムマスターになる前に何をしたか？
#スクラムマスターになる前の準備として取り組んだ内容は以下の通りです。
- スクラム関連資料を読む
- スクラムマスターとしての自分をイメージする
スクラム関連資料を読む
#スクラムの全体像をつかむことを目的に、スクラム関連の資料を読みました。
- SCRUM BOOT CAMP THE BOOK
- スクラムガイド(2020年版)
- アジャイルサムライ
- その他（社内の研修用資料など）
まず、SCRUM BOOT CAMP THE BOOKを一通り読みました。こちらは、社内プロジェクトに参画する前から読んでいましたが、スクラムマスターを務めるにあたり、復習をかねて読み返しました。
スクラムガイドについては、スクラムマスターになってからも繰り返し目を通しています。特にスクラムイベント前後で、どういった点が重要なのかを再認識するために利用しています。
アジャイルサムライについては、実際にスクラムを進めていく中で疑問に思ったり、困ったことがあったときに解決のヒントがないかを探る目的で読むことが多いです。
スクラムガイドは当たり前のことばかり言ってない？
スクラムガイドは繰り返し何度も読みましたが、正直なところ私が読んだ印象としては「全体を通して当たり前のことばかり言ってないか？」です（あくまで個人の感想ですのでご容赦ください）。
このあたりは、私のキャリアも影響しているかもしれません。前職は大学に勤めており、研究ではフィールド実験にも関わっていました。スクラムガイドで記載されている内容は、ある種私の携わっていた研究活動に近いものだと感じています。以下のような感じでしょうか（私が携わった研究での位置づけですので、研究分野やゼミの体制によっては違うところもあると思います）。
| スクラム | 研究 |
|---|---|
| Product Backlog | 実験協力者からの要望 |
| Sprint Backlog | 次のフィールド実験までのToDoリスト |
| Sprint Review | 実験協力者への研究成果の連携、フィードバック |
| Sprint Planning | 研究室内のゼミ（次の実験までの計画を立てる） |
もちろん、毎日実施するDailyScrumに相当する活動がない、スクラムほど明確にスプリントの期間が決められていたわけではないなど違う点も多々あります。しかし、本質的な部分では研究活動とスクラムは通じる部分が多いと感じています。
なお、実際にスクラムガイドにも以下の記述があります。実際、研究に適用しても問題はなさそうです。
当時は、スクラムとは何かも知らず研究に従事していました。議論を通じ真理を探求するプロセスを大学で長い期間経験したからこそ、スクラムガイドに記載された内容は至極当たり前な内容に感じ、スクラムチームに参加しても違和感はほとんど感じなかったのかもしれません。
「スクラムマニュアル」ではなく「スクラムガイド」
もう1つ感じたことは、「スクラムマニュアル」ではなく、「スクラムガイド」であることが、個人的には重要だと思っています。
「スクラムガイド」では、スクラムの定義や理論を中心に説明しており、スクラムを成功させるための具体的な方法論については触れられていません（スクラムガイド中でも、具体的な方法論（プロセス、パターン等）は対象外とする旨の記述があります）。
これ以降は100％私の推測になるのですが、仮に「スクラムマニュアル」として世の中に公開されていたとしたら、マニュアルに則って進めるだけのスクラムチーム、スクラムマニュアルに従うことが目的となってしまい、本質を見失うスクラムチームが量産されるかもしれません。
逆に言えば、100のスクラムチームがあれば、その在り方も100通りあるべきで、マニュアルで特定のパターンに統一化できないとも思います。各チームが、それぞれチームのより良い在り方を模索しつづけることが、スクラムとして正しい姿だと思います。
したがって、「スクラムガイド」としたのかなと勝手に推測しています（笑）。
スクラムガイドを読んでいて、ふと「手段の目的化」という言葉を思い出しました。私も執筆した論文に対してこの指導を受けたことがありますし、実際に学生を指導するときにもよく用いた言葉です。
本来は「業務改善をするためにシステムを作ります」と目的を達成するための手段としてシステム開発があるはずが、「システムを作って業務改善をします」というように、手段ありきになってしまうことを「手段の目的化」と言っています。
IT業界はこの「手段の目的化」の危険性が高いと感じています。新しい技術がどんどん出てきて、その技術を習得すると、人間欲が出て実際に使ってみたいという気持ちにもなるかと思います。
あくまでも顧客の要求・要件を達成することが第一のはずです。今後も手段が目的化していないか、一度立ち止まって気をつけていきたいものです。
そういう意味では、スクラムも「円滑に開発を進めるための1つの手段」に過ぎないと思うので、スクラムありきにならないように気をつけたいと思います。
スクラムマスターとしての自分をイメージする
#スクラムマスターになる前から、「もし自分がスクラムマスターだったら…」ということを意識しながらスクラムイベントに参加していました。具体的には、開発中の議論で、スクラムマスターとしてどのような言葉を発するべきなのか、スクラムイベントの進め方の改善点などを考えていました。
なお、この「もし自分がスクラムマスターだったら…」という考え方は、開発チーム全員がもつべき感覚だと思います。この感覚が、自己管理型のスクラムチームを作るうえで必要な意識だと思います。
おわりに
#新米スクラムマスターの思考メモということで、今回は主にスクラムマスターになるまでの期間で、意識したことをご紹介しました。かなり個人的な意見が色濃く入ってしまいましたね^^;
次回は、Retrospectiveでの思考メモについて記述したいと思います。
