はじめに

経理社員として働きながら、独学でプログラミングを行なっています。
昨日、興味のあったスクラム開発についての勉強会に参加しました。
参加して学んだことと、異業種の人間として感じたことを書きたいと思います。
スクラムマスターを知ろう in Agile Shinano

勉強会の概要

テーマ

「スクラムマスターを知ろう」
　・スクラムマスターの役割は何か？
　・スクラムマスターについて議論すべきことは何か？

学習形式

OST (Open Space Technology)形式での議論を行ないました。
OSTの概要をWikipediaから引用します。

5人から2000人といった小人数から大人数にまで一堂に会して行えるのが特徴である。参加者が課題を提案してミーティングを行う仲間を募り、課題を解決するプロジェクトを創出することができる。参加者の当事者意識や自発性を喚起するとともに、参加者の主体的な発案、対話を促す。

全員が発言権を持ち、自由に議論を進めましょうという形式で行ないました。
実務で起きた話を聞いたり、「こんな開発メンバーはイヤだ」の大喜利が始まったりと色々な話が聞けるオモロな方法でした。

進行方向

全体で約100分の勉強会でした。

1. 動画の視聴（スクラムマスターについて）
   The Power of Scrum - Legendado - YouTube

2. 一人ずつ、今回の勉強会で議論したい内容を提示
   「ラガーシャツ着なきゃダメ？」（動画内のスクラムマスターがラガーマンの服装だった）から「スクラムマスターに求められる素質は？」まで多様でした。

3. 全員投票で議題を決定し、テーブルごとに議論する内容を設けて自由に話し合う
   参加人数16名で2テーブル、各テーブル2テーマ、各テーマ40分ずつくらい。途中で別テーブルへの移動も可。

4. 各人がFun/Learn/Doneの振り返りを行ない、付箋をホワイトボードに貼る

議題

1. 「スクラムマスターにはどんな権限があるか？」

• 具体的な決定権は持たないのではないか？
  • プロダクトを決めるのは顧客とプロダクトオーナーであり、タスクの割り振りなど進行方法は開発チームが自律的に決めることが望ましい
  • 決まりを守らせる風紀委員的な役割であって、決まりを作る役割ではない
• 開発メンバーがタスクに集中できる環境作り
  • 開発チームの進捗把握（デイリースクラム、要所要所でのヒアリングなど）
  • マルチタスクにならないよう他部署リーダーからの干渉から守る（マルチタスクは生産性低下をもたらすリスクが高い）
  • プロダクトオーナーと開発チームの認識齟齬を防ぐ（あるべきプロダクトデリバリーに導く）

2. 「スクラムを困難にする開発メンバーがいた場合、スクラムマスターがすべきことは？」

• 風紀委員として開発チームの自己組織化を促す
  • デイリースクラムの時間厳守、スプリントレビュー時の目的理解を求める
  • 状況に応じてコーチングの機会を設ける
• 特定のメンバーの存在がチームの生産性低下に繋がる場合は、他プロジェクトへのリアサインを根回しする
  • あくまで最終手段

3. 「スクラムマスターに求められる素質は？」

• プロダクトの価値最大化を目的として開発チームの支援を行なうことができる
  • スプリントゴールを念頭に置き大局観を持つ
  • プロダクトオーナーや、クライアントとの折衝能力(時にはNoと言えること)
  • 技術指導やコーチングを通じて開発チームのサポート（開発メンバーの技術力が乏しい場合）
• 不満や不安を伝えたときに建設的な話ができる
  • 話を聴いてくれる、話しかけてくれる

4. 「スクラムマスターと開発チームのコミュニケーションの取り方」

• 開発チームの不満を隠さないような雰囲気作り
  • 今後のスプリントで心配なことない？など、将来の不安の芽を摘む
• プロダクトの内容について開発チームと合意をこまめに取る
  • デイリースクラムの遂行
• 多様な働き方に対する理解と調整
  • 育児フレックスやフルリモートの働き方への理解、プロダクトバックログの見直し

異業種の人として感じたこと

アジャイル/スクラム開発について

• アジャイル/スクラムへの認識として、ウォーターフォール型に比べて仕様変更など変動の多い労働環境と思っていた。プロダクトオーナー、スクラムマスターとの絶え間ないコミュニケーションが無いとしんどい現場になりがちなのかな。
• とはいえデイリースクラム以外でコミュニケーションに時間を割き過ぎれば生産性は落ちるし、そのジレンマに戸惑う事例は多そう。デイリースクラムでしか連絡を取らないという参加者もいればやたら打ち合わせの場があるという参加者もいたことから、人次第。

エンジニアという職業について

• エンジニアはプロダクトをどうやって作るかにフォーカスする職人気質な人が多いのかな。プロダクトを使ったビジネスのスケールとか収益化を考える経理、経営企画のほうが僕は好きかもしれない。※様々なエンジニアがいるので、人によることは承知しています
• とはいえ、モノを作る人ってかっこいい！
• 情報共有、ビジョン共有としてのコミュニケーションはエンジニアになっても大事。

スクラムの考え方は異業種でも使える

• 異業種でもスクラムの考え方、方法は通用する。
• 決められた納期、成果物に対してタスクを細分化し、メンバーに振り分け、進捗管理するというのは現職でも行なっている。
• 「タスクに集中できる環境作り」という視点は現職でも取り入れてみたい。他の人に仕事を割り振る際の用途（何に使う資料か）、納期（いつまでに終わればいいか）、内容（何が明確化されていればいいか）についての合意を心がけたい。それが相手の生産性を損なわないマナーであり、チームの生産性を損なわないことに繋がる。

参照リンク

OST(オープン・スペース・テクノロジー)
https://ja.wikipedia.org/wiki/オープン・スペース・テクノロジー

スクラムガイド
https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf