こんにちは！TECH Street編集部です！
2024年2月27日（火）に開催した、 「アジャイル開発エンジニア勉強会」のイベントレポートをお届けします。今回は各社のアジャイル開発に携わるエンジニアが集まり、それぞれの知見を発表し、学びあう勉強会を開催いたします。
登壇者はこちらの方々！
小熊坂謙太（くまさん）／株式会社ベネッセi-キャリア
出井 彰記／株式会社LIXIL
北島 和茂（きたじー）／パーソルキャリア株式会社
早速、内容を紹介いたします！
最初は、小熊坂さんの発表です。
新米スクラムマスターがいきなりLeSSを任された話
小熊坂：この発表では「新米スクラムマスターがいきなりLeSSを任された話」について話したいと思います。まずは、プロダクトを開発しているチームについて、簡単にご紹介させていただきます。
開発体制（2022年秋ごろ）
2022年の秋頃、フロントエンドとバックエンドを開発しているチームが大きくなり、これを1つのスクラムとして機能させるのはよくない、という判断になりました。そこで、フロントエンドとバックエンドのチームをLeSSで 2 つに分けました。
しかし、この体制で開発を進めていく中で、「チケット精度の問題」が表面化していきました。
開発体制（2023年3月時点）
実際にスプリントを始めるタイミングで要件定義ができていないチケットがそれぞれのチームに落ちてきてしまい、そこから見積もりをしても、結局要件が固まっていないので、作業量がすごい増えてしまったり、要件が決まっていないので、品質も上がらず、それに付随してインシデントや障害に繋がりやすくなる、などと悪いサイクルが起きました。下図がその悪いサイクルです。
開発体制（2023年4月〜）
そこで「これではいけない、何とかしないと！」という危機感から、LeSSチームのエンジニアから「専任スクラムマスター設置」の提言があり、そのLeSSチームに専任のスクラムマスターとして、当時インフラチームに所属していた私が入りました。
新米スクラムマスターがやったこと（2023年4月〜）
しかし、私はスクラムマスターを務めた経験がないので、「何をすれば良いのか？」「何ができるんだろうか？」と、いろいろと悩みました。
悩んだ結果、まずは、以下のようなインプットを行いました。
- スクラムガイドのドキュメントを読む
- スクラムマスター研修に参加する
それと、開発者やプロダクトオーナー、もしくはこのステークホルダーの方など、いろんな方ととにかく対話をし続けました。
LeSSイベントの見直し
またLeSSイベントの見直しを行いました。すると以下のことに気づきました。
- スプリントプランニングが、計画というよりも開発者たちが要件を確認をする場になっていること。
- プロダクトバックログリファインメントが、ただの進捗確認MTGのようになっていること。
- レトロスペクティブのMTGの時間が、チームレトロと全体レトロ合わせて1時間しかなく、表面的な話し合いに終始している印象で、やや形骸化を感じたこと。
そこで、「本来のあるべき姿ってなんだっけ？」とスクラムガイドを読んで確認しました。そして、
- 『プロダクトバックログアイテムは、スプリントプランニングの時には選択の準備ができている。』（下図の赤枠の部分から引用）
つまり、スプリントプランニング前にリファインメントは終えた状態であり、開発者たちもプロダクトオーナーもみんな同じ目線できちんと選ぶことができる状態になっているべきである、と再認識しました。
そして、主に以下の3つについて取り組みました。
スプリントプランニング
- 全体パート：見積・リファインメント済のバックログのみチームへ割り振る
- チームパート：割り振られたチームバックログをタスクに細分化
プロダクトバックログリファインメント（PBR）
- 全体パート：POが開発者が理解するまで要件を説明、見積不可なら差し戻す
- チームパート：開発者がポイントを見積る
→最初は合計3時間以上かかったが、今では2時間程度
レトロスペクティブ
- 全体パート：15分を1時間に伸ばし、全体でプロセスの調整点を検討
- チームパート：45分を1時間に伸ばし、成果物ではなくプロセスを議論するように啓蒙
開発体制（2023年9月ごろ）
このような見直しと改善を行ったことで、半年ぐらいかけて、少しずつ良い方向のサイクルが回り始めました。
- 要件定義済の状態でスプリント開始
- 作業量安定。技術負債へアプローチ開始
- 開発の大幅遅延が減る
- 改善プロセスがチーム&全体で回り始める
一方で、チーム外に目を向けてみると、LeSSを採用したため、他チームとの連携がより複雑になってしまっていました。
そうして、コミュニケーションの課題が生まれたことで、以下のような声も上がったのです。
- 「インフラチームに依頼しましたが、進捗が出てきません」
- 「WebとAPIは実装終わりましたが、アプリは分かりません」
この状況を改善させるため、
「LeSSチームのフロントエンドとバックエンド以外のチームもこのLeSSチームの中に収めていって、一緒にLeSSを作っていこう」という方向性に持っていきました。
それと、下図のドキュメントにあるように「Just Talk」を徹底しました。つまり、「他のチームに行き、とにかく喋る」という、この指針に従ってコミュニケーションを増やしてもらうように各チームに啓蒙しました。
開発体制（2023年11月）
以上、様々な取り組みを行ってきましたが、一番大きな変更は「LeSSをやめたこと」でした。
今まで、バックエンドとフロントエンドのチームで、LeSSチームを作って組んできたわけですが、そのチームの人数が若干減ったタイミングで、むしろそこは統合しようという話になりました。
そして、LeSS開発は統合し、他チームと（緩やかな）LeSSを開始し、新LeSS開発を始めました。（下図参照）
このように、開発体制を変えたことでうまくいっていることもあれば、まだ課題があるところもあります。例えば、
- 各チームLeSSの中に入ったが、その中で自己組織化したスクラムチームって難しい‥‥
- LeSSで繋がったが、果たしてLeSSが正解？他のフレームワークを使った方が正解？
など、どういうチーム構成がいいか、というところについてはまだ悩みがあります。
そのため、このような課題を乗り越えて、「TECH Street」でまた知見共有をする機会があれば嬉しいです。以上で発表を終了させていただきます。
小熊坂さん、ありがとうございました！
続いては、出井さんの発表です。
スクラムマスターとプロダクトオーナーを両方経験した話
出井：この発表では「スクラムマスターとプロダクトオーナーを両方経験した話」ということで、皆様にお伝えしたいと思います。
スクラムの導入背景
まず、スクラムの導入背景を説明させていただきます。
弊社のデジタル部門では「LIXIL Behaviors」という 3 つの指針があります。この指針を率先して実践するエキスパート集団となることを目指しました。
正しいことをする
- 法律や倫理を遵守し、かつ当事者意識を持つ
- 過去の事例や既存のやり方にとらわれず、誠実に正しく判断し、意思決定する
- 信念を持って行動する
敬意を持って働く
- 経緯を持つために、まずは相手を理解するように努める
- 性別、役職、資格、経験に関わらずオープンかつ公平にアイデアや意見を交わす
- 相互理解によって一体感が生まれ、向かうべき方向が明確になる
実験し、学ぶ
- 小さな実験を繰り返し、スピードを持った行動につなげる
- 失敗はイノベーションへの重要な投資になり得ることを認識する
- 実験から学んだ教訓を、更なる実験のきっかけとする
このLIXIL Behaviorsを実践する、体系的な仕事のフレームワークとして、スクラムが適していると判断され、導入していく流れになりました。
アジャイルな組織への変革
従来の組織（役割別階層）からアジャイルな組織（小さなチームのネットワーク組織）へ変革しました。
- 部門を超えた連携を促進し、機動的な対応ができるアジャイルな組織へ
- マーケットに一番近いチームが自ら判断して行動し、チーム同士が自律的に連携
デジタル部門のスクラムのビジョンステートメント
デジタル部門の方で、スクラムのビジョンステートメントを以下に掲げました。
- ユーザーに寄り添い、素晴らしい価値を早く届けることを楽しもう！！
私が担当しているプロダクトのご紹介
ここからは、私が担当しているプロダクトのご紹介をしたいと思います。
提案見積もりシステム
- SR・営業・パートナーが利用します。
- LIXILの商品を3Dで見ながら、見積もることができるシステムです。
かんたんプラン選び
- エンドユーザー向けにプランを探すことができるサービス、現在LIXILのHPで公開中。頑張ってプロダクトを成長させています！ぜひ使ってみてください。
自身の経歴と当時のマインド
2019 年にデジタル部門でスクラムを導入し、パイロットチームとして参画しました。その当時は、以下のような想いを持っていました。
- まずはスクラムに慣れよう！
- 心理的安全性を向上しよう！
- ユーザーに早く価値を提供しよう！
- 仕事を楽しもう！
このような想いを持って、 3 年ぐらいスクラムマスターをやりました。そして、2022 年に役割がプロダクトオーナー（PO）となり、そうなると今までと動き方が変わり、
- プロダクトバックログの優先順をどうやって決める？
- SMのときと立ち振る舞いの違いは？
- プロダクトマネジメントの知識も乏しい
などの悩みが出てきました。
そこで、以下のようなことを意識することにしました。
スクラムマスターとして意識したこと
- チームのサーバントリーダーであり、スクラムを芯まで理解したコーチである
- チームの障害をなくし、開発チームやPOに役割を全うしてもらう
- チームを俯瞰して見て、どのようにすればチームが良くなるか常に考え、行動する
- とにかくアジャイル開発を楽しんで、それをチーム全体に伝染させる
スクラムマスターとして何を取り組んだか
実際にスクラムマスターとして、以下の3つの軸を中心に取り組みました。
他チーム連携強化
- SM連携強化（SoS、CoP）
- PO連携強化（MS）
- チームを跨いだチームビルディング
自チーム強化
- スクラムの守破離の守を意識強化
- 各メンバーの強み・弱みを理解
- 各メンバーの価値観を理解
- スキル・ノウハウのナレッジ化
仕組み・運用強化
- CI/CDパイプライン導入
- ツール類の有効活用（JIRA、Confluenceなど）
- 技術的負債の棚卸しと実行
- プロダクト利用実績データ可視化
スクラムマスターのときのチームの状態
スクラムマスターをしてチームの状態がどうなったかと言いますと、以下のような効果がありました。
- チームのベロシティは約1.5倍
- チームの幸福度はほぼ5まで向上
現在、プロダクトオーナーとして何を意識しているか
では、スクラムマスターを経験して、その後プロダクトオーナーに役割が変り、どんなことを意識したかと言いますと以下になります。
- データ可視化をしていたため、プロダクト価値を最大化できるようデータドリブンに優先順位を決める
- チームが理解し、動きやすいように、バックログのwhy・whatの伝え方を工夫し、チームメンバーとともにブラッシュアップする
- プロダクト開発だけではなく、チームの改善の重要性を理解していたため、バックログの優先順位にはチームメンバーの意見も必ず取り入れる
- プロダクトに愛着を持ってもらうため、様々な手法を取り入れ、ステークホルダーやチームメンバーと一緒にプロダクトを作っていく
プロダクトオーナーとして何を取り組んだか
プロダクトオーナーとして何に取り組んだかと言いますと、「目的意識の醸成」と「運用強化」です。
目的意識醸成
- ユーザーストーリーマップ・ペルソナ
- インセプションデッキ
- OKR・NSMを活用した目標管理
運用強化
- ユーザー要求と複数チームのプロダクト開発をJIRAで運用管理
- 実績データ活用・分析による優先度決定
両方経験したことによる気づき
両方経験したことによる、気づきは以下になります。
- チームとの関係性が構築されており、コミュニケーションが円滑、ただしSMとPOではコミュニケーションの質が違う
- プロダクトの価値を高めることをメンバー自身が楽しむことで、自然とチームが一体となり、自律的チームになっていくと感じる
- チーム全体がプロダクトに愛着を持ち、理解すること、メンバーの相互理解が重要
- 自律的チームになると、メンバーが改善を繰り返すため、よりチームが良い方向に進んでいく
両方経験したことによる悩み
一方、両方経験したことによる、悩みは以下になります。
- ユーザー要求とチームの改善はどちらも重要だと思う反面、優先度をつけるときにどちらを優先するべきか未だに悩む
- プロダクトオーナーにも関わらず、スクラムマスターのような動きをしてしまうことがある（癖が抜けません。。）
- 自身がスクラムマスターだったこともあり、後任のスクラムマスターの動きが気になってしまうことがある（アドバイスすることもあるが、見守ることも必要ですね）
私の報告は以上となります。ありがとうございました。
出井さん、ありがとうございました！
続いては、北島さんの発表です。
駆け出しのスクラムマスター
北島：本日は、dodaの開発に携わり、そこで新米スクラムマスターとして務めた私の「学び」や「気づき」を中心にお話できればと思っております。
アジェンダ
- dodaサイト開発チームとは
- dodaの開発について
- 入社後SMに就任した自身の苦労
- アジャイルQAとアジャイル開発チーム
- 最後に
dodaサイト開発チームとは
まずは、dodaサイトの開発チームの紹介をします。
体制としてはスクラムチームを組んでおり、スクラムマスター（SM）とデベロッパー（Dev）で開発を回しています。
そして、POと呼ばれる企画者（ディレクター）の方が複数人いて、開発が進んでいる形になっています。
開発の変遷
続いてdodaの開発について、開発の変遷を紹介させていただきます。
- 2018年までは外部ベンダー様中心の開発を行ってきました。
- 2019年：初期スクラムを導入。
- 2020年：内製エンジニア採用を強化。
- 2021年：開発チームの個別最適化が行われ、チームによってはスクラム廃止。
- 2022年：スクラム導入再検討
- 2023年：スクラム再導入（自己組織化を目指して再スタート）
スクラムマスターに就任した自身の苦労
続いて、私がスクラムマスターに就任して苦労したことを紹介します。
課題1：チームがバラバラ！
チーム発足したての頃に色んな事が重なり、SM（私自身）がチーム状態の把握や目標などを示すことができず、ただ乱暴にスクラムを押し付けるような形になってしまいました。
課題2：振り返りとアクションの時間が足りない！
チームの雰囲気が良くなっていくと共にレトロの質も上がっていきましたが、そうすると今度は課題や触れるべきトピックが多くなってきました。
課題3：定量的な指標がない！
開発も安定的に回り出してきたという実感はありつつも、定量的な指標がないので、何がどう良くなってるのかが明確ではありませんでした。
課題4：品質担保の仕組みが無い！
スクラム以前からではあるが、テストが大味で実施結果等もろくに管理されていない状態でした。開発プロセスも明確に整備されておらず、ヒヤリハットや障害の発生率も高い状態でした。
課題5：小さなウォーターフォール
同時に進む施策が複数存在し、1人に1施策が割り当てられ、1人1人が小さなウォーターフォールのように実施していたことです。
1人1人が別々のことをしていて、「助け合いがないとできない」みたいなことも多く、例えば、担当者が体調不良で休んでしまうと、その施策自体が止まってしまう事が起きました。
これらの5 つの課題に対して自分が行ったことを以下の 3 つのポイントから振り返りたいと思います。
- チームビルディング
- 開発プロセス
- 心境の変化
チームビルディング
チームとして目指すもの（文化）の共有はとても大事だと学びました。これがちゃんとできていれば、走り出しはまとまるのだと感じました。
アイスブレイク
私のチームでは、アイスブレイクを大事にしています。気兼ねなく話せたり、相談しやすい関係性を構築するのが目的です。誰か1人がネタを喋るよりは全体に話を振りながらみんなで会話するのが効果的だったと感じています。
それぞれメンバーの人となりを知ったり、どんどんコミュニケーションが円滑になっていったので良かったなと感じています。
期待のマネジメント
「エンジニアからディレクター」「ディレクターからエンジニア」などと、各役割に対して期待していること、期待されていると思っていることを書き出しました。そうすることで、各役割で力を発揮する場所が明確になりました。
ある程度関係性の構築ができた段階でこの取り組みを始めたので、それが効果的だったのかと思ってます。
開発プロセス
開発プロセスでは、以下のスクラムイベントを1週間スプリントで回しています。
デイリー
参加者：PO/Dev/SM
リファインメント/スプリントビュー
参加者：PO/Dev/SM
プランニング
参加者：Dev/SM
レトロスペクティブ
参加者：PO/Dev/SM
続いて、スクラムの価値基準は「確約」「集中」「公開」「尊敬」「勇気」と5 つありますが、その中で、確約と公開の部分については、以下のようなルールを作りました。
【確約】勤務時間8時間の内6時間を稼働時間とする
日々のMTGの時間や開発相談などの時間を確保できるようにしました。詰まっている他のメンバーのフォローにまわりやすくしたりヘルプの声も上げやすくなったと思います。
【公開】施策内容のやりとり（質問等）は全体チャット
質問の回答などが個人間で留まらないようにしました。
担当者が不在だと最終的な決定事項が不明等の状態を排除しました。
1人1施策の脱却（リソース効率→フロー効率）
リソース効率
doda開発では1人のエンジニアが1施策を担当するやり方が主流となっており複数施策がエンジニアの人数分並列に遂行されます。
フロー効率
1施策に2人以上のエンジニアをアサインし、共同調査やモブプロ/ペアプロ、開発相談などを交え、リードタイムの短縮や品質担保の強化等を目指しました。
続いて心境の変化についてです。
やはり、チーム発足当初はとても焦っていました。
- 「早く期待に応えないと‥‥」
- 「開発リーダーとしてたくさんリリースしないと‥‥」
- 「スクラムマスターとしてチームを強くしていかないと‥‥」
などです。
しかし、スクラムマスターをやっていく中で、徐々に心境にも変化が出てきました。
- 「やれることには限界がある。優先度をつけてやれることをやっていく！」
- 「リリース数より効果（質）があるものを出す！」
- 「チームは着実に強くなっている！」
それと、チームの関係性が出来上がっていくとともに、徐々に心に余裕が生まれてきたところが一番大きかったかなと思っています。
アジャイルQAとアジャイル開発チーム
doda開発での品質課題
現状、以下のようなシステムが長年の開発により複雑に絡み合っており、影響調査の難易度が高く、不具合が発生しやすい状態となっている。
- カスタマー（個人顧客様）向けのシステム
- クライアント（法人様）向けのシステム
- 基幹システム
また、外部委託で開発してきた経験もありナレッジやノウハウも失われていたり、在職期間の長いTL層の知見による属人的な開発プロセス等にも課題がありました。
そんな中、アジャイルQA組織が立ち上がりました。
品質保証っていう言葉だけを見ると、以下のように思われるかもしれません。
- 「メンバーとしてテスト工程を担当するの？」
- 「各チームの品質管理的なところを担当するの？」
しかし、dodaの QA は違います！
現状、以下のような各スクラムチームのサポートがメインになっています。
- プロセス改善の補佐
- 健全性モニタリング（環境の整備）
- 不具合検出率のモニタリング（環境の整備）
- 定量評価基盤の整備
品質と障害
QA組織と協力し、バグ管理ツールを導入しました。
導入にあたって苦労した点
- PO側への協力依頼
- 使い始めのフォーマット等への慣れ
導入してできるようになった事
- 項目書の一元管理
- レビュー指摘や実施結果、バグの見える化
- バグ分析、検出工程のシフトレフト
品質と障害に関して、我々のチームでは、バグのシフトレフトの改善を重点的に目指してきました。
バグのシフトレフト
チーム発足当初は本番障害やヒヤリハットを数回発生させてしまいましたが、現状だと本番障害や後工程でのバグ検出の割合が他チームと比べても低くなりました。
仕組み/ルール
- 方式設計をmiroで見える化し、メンバーからのフィードバックを受けやすくしました。
- 隔週でバグ内容共有と検出タイミングを振り返る場を作りました。
メンバーの成長
- 施策共有時点で要件考慮漏れ等を指摘したり潰せるようになってきています
- 調査段階で複雑になりそうな機能がマストなのかみたいな相談が起きるようになりました（トレードオフ）
- 開発相談の時間で課題に対して、参加者全員で話せています。
最後に
「変化の激しい世の中で、できるだけ早く、安全に、価値体験を提供する」といったところを我々は目指しています。
そのために、以下のような対策を行い、変化に対応し価値提供し続けられるチーム作りを目指します。
- 各スクラムチームの自己組織化
- メンバー個人個人の主体性の醸成
- 属人的リスクの排除
発表は以上です！
北島さん、ありがとうございました！
続いては、Q&Aのコーナーです。
Q&Aコーナー
（Q）スクラムマスターは開発チームやプロダクトオーナー側から出すのではなく第三者的な立場から出すのが良いのでしょうか。
小熊坂：スクラムマスターとエンジニアを兼任すると、エンジニア業が忙しく、スクラムマスターがおざなりになることがあったり、しがらみが改善の邪魔をしたりするかもしれません。
プロダクトオーナー側からの場合は、事業サイドの視点が強く反映され、開発チームが戸惑ってしまうことが起こりえます。
今回は、しがらみがなく客観視できる、第三者的な立場の人を新たに立たせることは有効だったと思います。ただ、適任者が見つかるかどうかという問題もあるので、ケースバイケースかもしれないです。
（Q）いきなりスクラムマスター任命されたのは、どんな事情があったのでしょう？？立候補ではないですもんね。
小熊坂：立候補ではなく、いきなり部長に呼ばれました。（笑）前職も現職でもアジャイル開発（カンバン）の経験があり選ばれた、という背景があります。
（Q）うまく回っているとき、他部門のMTGも含め、スクラム関係のMTGはどの程度発生していたのでしょうか。週何時間をMTGに使っていたのでしょうか。
小熊坂：突発的なMTGが煩雑に発生するとうまくいかないので、できるだけスクラムイベントで完結できるよう意識しています。
基本的には２週間で スプリントプランニング に２時間、プロダクトバックログリファインメントに２時間、スプリントレビューに１時間、レトロスペクティブに２時間の時間割で進行しています。
（Q）スクラムマスターをするにあたって、協力者はいたんでしょうか?? 教えてもらう人や、リソース確保、権限付与などの面です。
小熊坂：「事業会社の中での内製化でアジャイルに開発したい、そのためにスクラムを手段として採用している」という事業サイドとの共通理解があったので、よかったのだと思います。スクラムの改善に向けて、事業サイド・開発サイドのコミュニケーション面改善の協力体制もありました。反対する人もおらず、スクラム研修を受けさせてもらえたのもよかったです。
（Q）開発じゃないマーケとかでも採用しているのがむっちゃ気になります。どんな感じなんだろう？推進は横串な部署とかあるんですか？
出井：アジャイルプラクティスというコーチがいます。導入のタイミングで研修をする、この研修を受けたチームが立ち上がっています。
（Q）アジャイル開発をほぼ知らない者になりますが、アジャイル開発はどういった開発でも適用できるものなのでしょうか？ ご講演を見ると、Webアプリのようなソフトオンリーのようなところが合っているように見えていて、ソフトハード混在のシステム開発にも適用できるものなのでしょうか？
出井：弊社ではマーケ、営業、研究部門にも展開されています。バックログとしてはソフトウェアの開発が成果物ではなく、各々のタスクの成果物がスプリントゴールになっています。
（Q）スクラムチームが社内に広がっているというお話ですが、スクラムチームのメンバーは基本的にすべて自社のメンバーなのでしょうか？
出井：チームによっては自社メンバーのみのチームもありますが、ほぼ自社以外のパートナー会社のメンバーと構成されたチームが多いです。
（Q）いろいろな部署でスクラムとのことですが、JIRAとかのツール類は全チーム統一ですか？そういった選定はチームに寄りけりですか？ツール選定とか評価は専門部署ですか？
出井：弊社のツールとしては基本、JIRAを活用しています。ツール選定はデジタル部門内で評価して選定しています。
（Q）バックログのWhy・Whatの伝え方の工夫について、現在のベストな内容や書き方をおしえてください。
出井：ベストかどうかは分からないですが、Whyは目標に対してどのKPIを上げたいか、そのためにWhatは何をしたいのかを書いています。私のチームではあくまでWhatはやりたいことで、Howは含まないように意識しています。
（Q）プロダクトに愛着を持ってもらうためにしたことで、印象に残っている施策を教えて欲しいです!!
出井：対面で集まって、ユーザーストーリーマップなどをつくりあげていく。プロダクトオーナーが作るのではなく、全員でワークをこなしていくのが大切だと思います！ツールを使うのは大事！
（Q）@出井さん 提案見積システムのアジャイル開発は、初期開発から適用したのでしょうか。それとも開発後の既存のシステムに対して、価値向上を継続的に進めているのでしょうか
出井：初期開発では導入してなく、開発後の導入です。
（Q）性格診断等ではMBTI診断が有名ですが、メンバーの理解を深める上で使用されたフレームワークは具体的に何を使われておりましたでしょうか？
出井：最近MBTI診断使ってみました！チームを立ち上げるときに、それぞれのペインとゲインを出し合って、お互いにフォローしあう認識をつけました。エンゲージメントガードをつかって価値観の認識合わせも行いました。
（Q）ベロシティや幸福度を測っているグラフが非常に気になりました！なんのツールを使っていますか？
出井：グラフはスプレッドシートで実施しています。推進チームに作ってもらっていて、スクラムマスターがスプリントが終わるたびに入力しています。
（Q）皆さんに質問ですが、スクラムマスターのロールで動くときはどのようにチームに関わりますか？ 具体的に何を話したり、何をリードしていますか？ 逆に何が起きているときはあえて静観(あえて放って置く)していますか？
出井：プロダクトに関わる障害やナレッジを他から連絡を受けたときに、迅速にチームに共有します。また、各種スクラムイベントはスクラムマスターがファシリテートしています。メンバーが話に参加できるように議題や状況を見ながら話を振ったりします。あえて静観するのはメンバー同士がスウォーミングや議論になっているときはある程度静観し、議題が発散したり、時間をオーバーしそうなときに適宜、交通整理します。
（Q）プロダクトオーナーがやってはいけないことはありますか？
出井：プロダクトオーナーはROIに責任を持つため、Why・Whatに対してプロダクトの将来像を考え、内容を整理して、メンバーに伝えます。そこでHowまでは意識的に書きません。そこはチームが責任を持つためです。あとはあくまでチームはフラットな関係でいる必要がありますので、役職は上下関係だとしても指示したりはしていません。
（Q）スクラムのチームに入れる人は、スクラムへの向き不向きで選んでいますか？それとも、だれでもできるという感覚でしょうか？
出井：誰でもできるとは思いますが、チームで働くということが大前提のため、その人の特性などを理解した上でコミュニケーションが難しいなどチームとしての障害になる場合は、リソース調整を上長にエスカレすることはあると思います。
（Q）SMが開発チームのTLとのことですが、SMと開発者との間に上下意識が生まれ、チームの自律化の妨げにならなかったでしょうか。
北島：なってるんじゃないかなと思うこともあります。意識的にSMとして身を引くべきことはあると思います。口出ししたくなりますが、時にはお任せしてみるのも良いです。
（Q）スクラムに対してネガティブなメンバーのマインドはどうやって変えましたか？
北島：上司の協力も得ながら、今の率直な気持ちをヒアリングしていく。何に対してネガティブなのか？をきちんと向き合う。ここはしっかり時間をかけて実施しました。
（Q）課題がリアルでいいですね。良い課題分析。逆に、今後発生しそうな課題（リスク）ってありますか？
北島：細かいものから組織横断的な大きなものもある。スクラムチームで大きなものを担当することもあるが、そこを分断して実施しないと、ノイズになりかねないと危惧しています。
（Q）チームビルディング大事ですね、新たに要員入ってくるタイミングなんかではやはり性格診断なんかも必須でやっているのですか？また、チームビルディングに役立っているおすすめツールなんかもあればお聞かせください。
北島：MBTIは参考にしています！これをもとにアイスブレイクで会話してみたり。
どんな価値観や気質を持った人なのか共有されていることは大事だなと思います。
ツールは特に利用していないですが、レトロスペクティブの中で些細なことでもメンバー間で感謝を伝え合うなど、各イベントで意識的なコミュニケーションを実施しています。
（Q）アジャイルあるある、みなさんあるかと思います。つらかったあるある聞きたいです。あと、アジャイル最高！と思った話なんかも
小熊坂：スクラム＋カンバンが好き。MVPやPoCのように小規模からはじめて、大きくスケールアップしていくのに適した手法だと感じているからです。
辛かったことは、外部から「アジャイルだからすぐできるんでしょ」と言われること。
また既に納期と作るものが決まっているものをアジャイルに頑張って載せたけど、最初からウォーターフォールにしておけばよかったなと後悔したこともあります。
出井：パイロットチームだった。他部門への理解を深めるために説明から入らないといけなかったので、そこはつらかったです。ただ、自身のMBTIがエンターテイナーなので、周囲に伝染させることができたと思っています。
また、パートナーの方と最初は契約上の壁がありましたが、現在では自社の人かと思うくらいプロダクトへの意識が高まって、アジャイル最高だと思いました！
北島：転職してきて間もなく、周りの人のこともよく知らないなかで、「スクラムをやりたいです」を提案していくのは、苦労しました。
「こんな取り組みをしてみました」といっても、すぐに結果が出ないときには不安を感じることもあります。
だけど、成果が見えてくると、やっぱりアジャイル最高！と思えます。
（Q）せっかく3社さんいるので「これはウチ独特な気がする」な推進があれば聞いてみたい
小熊坂：社員エンジニアの人数がそんなに多くないので、事業面でのビジョンにコミットしてもらうことに課題があります。コロナ以降はフルリモートなので、来期に全員オンサイトで一日だけ集まって、同じ方向を向いて一年間の開発を進めていくべく取り組みを推進しています。
出井：トップダウンからのスタートなので、スピード感はありました。導入するにあたり、プロモーションビデオを作って、社内SNSを通じて共有し、広報活動も積極的に行いました。
北島：POさんと呼ばれる人がいっぱいいる。ディレクター組織としてメンバーが沢山いるのが、独特なところかなと思います。
いかがでしたでしょうか、レポートの内容は以上です。
次回のイベントレポートもお楽しみに♪
