2018年8月24日（金）に開催されたアジャイルひよこクラブのコミュニティイベントに参加しましたので簡単なレポートにまとめたいと思います。
今回のテーマは「スクラムマスター・PO、専任できてる？スクラムチームのロールについて考えよう！」です！
今さら聞けない
アジャイルクラブについて
アジャイルに関わらず開発現場の改善を志す人（ひよこ）が集い、有識者（にわとり）に悩みを相談しつつ、いつの日か「にわとり」になることを目指すコミュニティです。
イベントレポート
会場スポンサートーク
今回のイベント会場はピクスタ株式会社が提供してもらいました。
李さんのスポンサートークで入会コンバージョンゼロの悩みを暴露中ｗ
今後提供していただけるときはコンバージョンアップに貢献できる施策を模索してみます。
LT
LT1: 「ロール、兼任、見えた壁」 (soba_watanabeさん)
- うまくいかないこと
→ マルチタスクが非効率的であるように兼任も非効率的です（非効果的というべきか？）。
→ スクラムマスタの１つの責任として「スクラムの促進」がありますが、専任でも難しいので兼任ならなおさら無理だと結論できます。
→ 自分の中でロールのコンフリクトが生じます：スクラムマスターとして振る舞うべきか、開発メンバーとして振る舞うべきかどちらを選んでももう片方が犠牲になります（チームビルディングが追いつかないなど）。
- 一方メリットがあったこと
→ チームビルディングの効果がすぐわかります。スクラムマスターとして狙った効果がメンバーとして実感できるそうです。
→ チームの弱点が見えやすくなります。メンバーとしてうまくいかないことを自ら実感して、見直すべきところをより早く見つけられます。個人的には兼任しなくてもメンバー同士でそのような思想が持てると理想的だと思いました。
- 兼任サバイバル術
最終的にはやはり専任になることが最重要であるとのことですが、ロール割合を区切り周りに対して明確することでなんとか生き残ると話して頂きました。
LT2: 「プロダクトオーナー２つのタイプ」 (TaroHirayuさん)
プロダクトオーナーはプロダクトの価値の最大化に責任を持ち、チームに明確なビジョンを与えなければなりませんが、プロダクトオーナーの正確やスタイルによってアプローチが変わってくることをテーマに話して頂きました。
プロダクトオーナーは2つのタイプがある
独力タイプ：プロダクトバックログにアイテムをガンガン作り、やることをしっかり管理するタイプです。
→ ビジネス成長と合った優先順位さえ取れていれば、チームが迷わずプロダクトをサクサク作れます。
→ トップダウンアプローチになりやすいように思いますので、メンバーとの信頼関係が構築しづらいリスクがあります。私の経験ですが、メンバーからのインプットを受け付けない傾向もあるかと思います。
→ 新規事業なら向いています。
- 協調タイプ：チームとコラボレーションしながらプロダクトバックログのアイテムを作っていくタイプです。
→ メンバーとの信頼関係が生まれますので初期はスピードがでなくてもあとから安定スピードと品質が維持できるメリットがあります。個人的には最初は我慢してでもこの進め方が望ましいと私は思いました。
→ 既存プロダクトの更改などが向いています（特にドキュメントがなくてビジネスロジックを再発見する必要がある場合）。
- どのプロダクトオーナータイプにおいても、共通認識が大事
→ どのプロダクトオーナータイプでも、良い悪いというよりもそのタイプに合わせて行動することをオススメしています（PO自身が変わって欲しいときも！）。ビジネスの成功を考えたときにどのスタイルが良いかというよりも、全員が共通な認識を持っているかがカギになるとのことです。
LT3: 「スクラムガイドとのdiffを取ってみた」 (藤村 新さん)
藤村さん祭りです。今回のLTをスライドではなくブログの記事で登壇して頂きました。
ある開発チームの支援に入り、スクラムガイドとどう異なっているかを明確にして診断をしてみた話しになります。
- 属人化していないか
- タスクの見積もりが大きすぎないか
- レビューは承認会になっていないか、など
結果として差分が多いので、スクラムをちゃんとやろうと思ってもうまくいくはずがないことを気づきます。
ただ、その差分はあえて選択されたものなのかわからないので、差分を見える化してチームと共有すること第一歩とします。
その後のステップとしては、改善を押し付けるのではなく、チームのメンバー自身に考えてもらいます。
- これらの差分がふりかえりで上がった課題の要因となっていないか
- これらの差分は自ら選択していたことか、なし崩し的にそうなってしまっていないか
- これらの差分が原因で起こり得る課題と、差分を無くすコストを比較して判断できているか
スクラムガイド通りに実践できれいるチームは少ないでしょう。しかし、考えないで完璧に従うよりも現状とはどの点が異なるかを認識し、それぞれの違いを直すことでどんな影響が想定できるか、今後変えることがあるとすればチームメンバー自身が選択できる状況を作ることが大事だと話して頂きました。
メインスピーカー: 「スクラムチームのロールについて考えよう」 (田地さん)
田地さんからメンバー（開発者）兼スクラムマスターの経験を語って頂きます。
もともと開発者として楽しくやっていきたいことからPMと任命されてしまい、結果的に兼任する形になりました。
スクラムのロール整理：プロダクトオーナー、スクラムマスター、チームメンバー
兼任してみてよかったところ
→ ステークホルダーとの調整は別のメンバーに手伝ってもらえたのでチーム内に集中できました（開発環境、POとのやりとり、開発など）。
- 兼任してみて辛かったこと
→ 特に振り返りで立ち位置が難しいです（ファシリテータなのか、メンバーなのか中途半端）。
→ メンバーとして行動を取ったときにスクラムマスターとして行動したと勘違いされやすいです。これは自分も同様な経験をしてことがありますので強く同感しました。自分はさっそく割り切るようにしたことで解消できましたが、これが続くと破壊的だと思います。
→ 妨害リストには課題が溜まる一方です、スクラムマスターとして行動できる時間が限られてしまうからだと思います。
- 楽しく開発するためには
お悩み相談会
今回あがってきた課題の抜粋です：
- Agileを広げるにはどう始めればよいか？
- POがエンジニアがやるべきなのか？
- バグ発生頻度が多い、同改善すればよいか？
- うちのチームにはそもそもSMはいない！結局POの私がやるしかないorz
- SMをやっているが、メンバーにどうスクラムを教えればよいか？SMトレーニングを受けさせるべきか？
- POではなくてSMの自分がPBI？タスク？を切ることになっている
- 上位関係がある状態でSMをやらされている、それを打ち壊したい
そのうち４つをピックアップして、グループディスカッションを行います。
「妨害リストをどう運用する」ディスカッションを絵で書いてみました
振り返り・次回テーマ決め
次のテーマは「みんな教えて！！スクラムアンチパターン」です！また盛り上がりそうな話になりました。
クロージング&集合写真撮影
