LeSS導入現場から学んだ、心理的安全性を高め、チームを自律させるスクラムナレッジ

1.はじめに

2.プロジェクトの環境

• プロジェクト規模：総勢60名ほどのLeSS。8チーム編成。
• 1チームあたりのメンバー数： 7〜9名
• 1スプリント期間： 1週間
• バックログリファインメント：毎週火曜日に全チームで実施(翌週以降で着手するアイテムを対象に行う)
• スプリントレビュー：毎週金曜日に全チームで実施

3.全体ナレッジ：大人数での会議を効率化し、価値ある案件に集中する

開発発信PBIの「Why」を明確にし、優先度判断を自律化

背景

•  開発側で技術負債解消などの対応を進めたい場合、PBIを作成し全体リファインメントの場で提示する方法を取っていたが、以下のような課題があった。
  • 記載者によってチケット記載内容に差があり、情報不足で他のPBIとの優先度がつけにくいことがある。
  • 開発発信PBIの他、必須でリファインメントすべき事業案件PBIがある場合、リファインメントの場が長時間になる。

実施内容

• チケットに記載すべき内容を明文化し、コンフルに整理
• 「なぜWhy/What/Whoをきちんと書くべきか」という理由も添えて、各自が目的意識も持てるように配慮

• 開発発信PBIについては、バックログの優先度判断についてもルール化
  • PBIの優先順位を決めるのは本来POの役割だが、開発内の細かな対応の優先順位まで判断してもらうことは難しいので、開発側で決められる範囲はPOに依存せず決定することにした
    • PO含めて優先度判断が必要な場合だけ、全体リファインメントで提示する
      • 例：技術負債解消をしたいが、下位OS切りをともなう等でCSへの影響などがあり開発側だけで優先度判断が難しいもの
    • 開発側のみで判断すべき優先度のPBIの場合は、全体リファインメントで提示はせず、開発側でPBIのリファインメントを完結させる
      • 例：アプリの動作に影響がない、不要コード削除対応など
      • このPBIは、各チームのベロシティ内で余ったポイントがあれば、チームの裁量で対応するというスタイル

• 作成したチケット(開発発信PBI)は、各チームのSMがレビューを行うようにした
• 対面で時間を取らなくても良いよう、レビューはSlackのワークフローで構築・実施。

結果

• PBIの記載ルールを明文化・レビュー工程を入れたことにより、PBI(チケット)の質が上がり、どのチームでもチケットが取りやすくなった
• 開発発信のPBIを全体リファインメントの場で提示する必要がほぼなくなったので、全体リファで大人数の時間を割くことなく運用できている

考察

• 全体で話し合う必要があるPBIがどういうものなのか、という線引きがプロジェクト全体で曖昧だった
• 以前は各人の「誰が見てもわかるPBIを書く」という意識が低く、「いずれ自分のチームで対応するから手厚く書かなくても良いだろう」という思い込みがあったと思われる
• 単にルールを決めるだけでなく、各自が目的意識を持つために添えた理由が改善に効果的だったように思う

「なぜWhy/What/Whoをきちんと書くべきか」
スクラムの着手ルールは「価値による優先度順」です。Whyがない案件は優先度のつけようがないため本来着手できません。
そんな中で着手できているのは、POとDevは「Respect」という名の信頼関係で成り立っているためです。
チームがプロジェクトに必要なこと（ROIの高い案件）をやっていると信じているから任されています。
チームのベロシティが高くても、Whyが書かれていない案件をやっている限り、チームの活動がプロジェクトのためになっているのかチームの外からは分からないのです。
Whyが確かな案件を優先度順にこなしていることが見えていれば信頼は積み重ねられます。（一方で、優先度を意識できてないチームが一度信頼を失なうと、何も自由にできなくなります。）

4.チームナレッジ：1週間スプリントを安定して完遂するための5つの工夫

1.デイリースクラム：進捗報告から「ゴール達成の場」へ

背景

• デイリースクラムが単なる進捗報告になってしまい、ゴール未達となることが度々あった。
• 本来の目的である「スプリントゴール達成のために、問題なく進んでいるかを確認」するためにデイリースクラムの改善を図った。
• このチームでは大規模案件を担当することが多く、ゴール未達が続きコード凍結間際に慌てる事もあった。

実施内容

• 自分が担当していない作業であっても当事者意識を持ち、進捗に懸念点・疑問点があれば相互に確認し合う
  • 例えば、Androidの進捗が思わしくない時はiOS担当者であっても積極的に声をかける等
  • 「お互いの作業内容・進捗を意識し合おう」としてWorking Agreement(以下、WA)にも記載
• サブタスクは1日で終わる単位とし、1日以上動きがないものはデイリー時に理由を確認し合う
• 水曜日(スプリント中盤)にゴール達成可否を確認する。達成が難しいと思われるものはその理由などを話し合い、スコープの見直しやチケット分割などを行う

結果

• 動きがないタスクについてデイリーで深掘りすることで、滞りを早期に発見できるようになった
• このルールを全て適用してからまだ間もないが、今の所安定してゴール達成できている
• デイリーでゴールを意識することで、「案件全体の進捗が問題ないか？」も常に配慮できるようになった。

考察

• 改めて考えると、当たり前にやるべきことが、当たり前にできていなかったと実感。
• デイリースクラムが形骸化してしまうのは一般的にもよく発生しがちなケースのようで、以前はお互い以下の要素があったのではと感じている。
  • 他メンバーの進捗への関心が薄かった
  • 他メンバーの進捗に疑問はあったものの、なんとなく言い出しづらかった
• WAにも記載することで、全員がチーム全体の進捗を意識する＆できる方向に持って行けたように思う。

2.プランニング：最大の懸念をプランニングで出し切る

背景

• ゴール達成ができなかった時の原因の１つとして、「プランニング時の見積もり精度が悪い」場合があった。
• 見積もり精度が悪くなる原因として以下のような「プランニング時点の曖昧な情報を見積もりに反映できていない」という課題があったため、より精度を高めるための取り組みを行なった。
  • 思ったより修正が難しかった・規模が大きかった
  • 懸念点(または疑問点)があったがプランニング時にメンバーにうまく伝えられていなかった
    • 懸念点が込み入った内容で、プランニングの時間を長引かせると思い言い出せない
    • 懸念点がすぐ解決するものと考えていて、伝えていなかった（実際には後から問題が出てゴール達成ができなかった）

実施内容

• 「思ったより…」にならないように、修正にあたり不透明な部分はなく、「迷わず進められる状態であるか」を各作業毎に確認する。
  • 課題や疑問点があれば深掘りし、この内容が大きいなら調査チケットなどとして分割する
• 先入観を捨て、些細なことでも懸念点、不明点などがあれば正直にその旨を伝える。
  • 例えば、「修正ボリュームが具体的にどれくらいになるかわからない」という場合は、最大で対応することになりそうな母数をプランニングの場で出して見積もる
  • 母数自体がわからない、というケースは案外少なく、対象になりそうな関数や処理はざっくりでいいのでプランニング時にGrepして母数を出す、という具合

結果

• 以前よりも見積もり精度が上がり、安定的なゴール達成に繋げられている
  • 補足：最大のパターンを見積もるので、場合によってはスムーズに解消して見積もり時よりも少ないポイントで済むこともある。この場合は以下のような対応をしている。
    • 実際にかかったポイントを反映して、チームベロシティの整合性をとる
    • 余裕があれば追加チケットを取って対応する
• 大規模案件などで、長期的にみて顕在化しそうな課題や懸念についてもメンバー間で共有することで、早めに対処できるようになった
• 不安要素があれば遠慮せずに発言して良いというマインドがチーム内に出来上がった（心理的安全性の向上）

考察

• 「迷わず進められる状態であるか」が特に重要で、以前はその意識が薄かった・確認不足だった
• 些細な懸念が大きな問題になることもあるので、先入観は捨てて会話することが大切
  • この時、詳細を事細かに話す必要はなく、ざっくりでも見積もりはできることが勉強になった
• 不透明な事柄の透明度を上げるため、自然とチーム内の発言が促進されたように思う

3.行き詰まり対策：15分の「悩み」でペアプロを開始する

背景

• スプリント期間が1週間のため、通常の2週間スプリントよりもスムーズな問題解決が求められる。
• メンバーが問題を一人で抱え込んでしまい、長時間行き詰まった結果ゴール達成に影響をきたすことがあった。

実施内容

• 悩みに直面した場合、さらに時間をかけても解決に至らないことが多いため、ペアプロやモブプロを積極的に行うことにして、以下をWAにも記載。
  • あらかじめ、複数人で作業した方が効率的とわかっている場合は、初めからペアまたはモブ作業を実施する。
    • 例: 新規機能の追加時のフロー作成、対向先が多い場合のシーケンス図作成など
  • 一人で作業する場合、内容によるが大体15~30分程度で解決できない場合は、ペアプロまたは他メンバーに意見を求める。

結果

• ルールを設けたことで、一人で問題を抱え込む状態が短くなり、問題解消までの時間が短縮された。
  • 複数人で作業する分、他者の時間を使うことになるものの、この取り組みを始めてからの方がゴールの達成は安定している

考察

• 一定の「考える時間」は必要だが、「迷っている/悩んでいる時間」は極力減らしていくという共通認識をチーム内で持てたことがよかった
• 一人で考えていると、自分が考えているのか・悩んでいるかの境界線が曖昧になり、抱え込んでしまっていたと思われる
• 他者と話すことで、見落としていた視点や新たな気づきが得られるため、短期間スプリントでは特に早期に他者と共有することが有効と感じている

4.リーダー連携：相談事項を「提案」に変えて意思決定を速める

背景

• 開発メンバーのみでは判断や進め方に迷う問題が発生した時、チームリーダーが多忙で十分な相談時間を取れず、スクラムチームの進捗を妨げる障害物が回避できない状態が長引いてしまうことがあった。

実施内容

• 限られた時間内で方針を決めるために、以下の取り組みを行った
  • 議論(相談事項)のゴールと複数の対応案(できればメリデメも含めて)をあらかじめまとめる
  • まとめた内容でチームリーダーに相談する
    • 相談する際、特に定期的なタイミングは持たず、ある程度溜まった段階でチャットで投げる方式
• 返信がなかなかもらえない場合は、開発側で最善と思われる方針で、可能な範囲の作業を進めるようにしている

結果

• 事前に議論をまとめることで、チームリーダーとのコミュニケーションが効率化され、迅速な意思決定ができるようになった。

考察

• 以前はチームリーダーに「意見」を求めてしまっていて、話し合いが長くなり結論が決められていなかったように思う
• 今回の取り組みを始めてから、以前よりも開発メンバーが自立して動けるようになったと感じている

5.Working Agreement：形骸化を防ぐ「週一読み合わせ」

背景

• チームのWorking Agreement自体は存在していたものの、定期的に読み合わせを忘れたりして形骸化していた

実施内容

• 毎週金曜日時に実施している振り返りのアジェンダに「Working Agreement読み合わせ」を追加して、全員でWorking Agreementを確認する場を作った

結果

• 毎週読み合わせすることにより、チーム全員の共通認識を新鮮な状態で維持できるため、作業の進め方などにおいてズレが起きにくくなった

考察

• 元々月1回は読み合わせするというルールは決めていたものの、チーム全員で忘れてしまうことが毎度だったので、週一の振り返りのアジェンダに入れたことが効果的だった（振り返り自体を忘れることはないため）
• 毎週読み合わせする際は、追加・是正したい内容はあるか？という観点で見ていて、さほど時間はかからないため、もっと早くこの取り組みを始めればよかった

補足

• チームのWorking Agreementの内容を一部抜粋

＜コミュニケーション＞
・不明点は抱え込まずにすぐ相談しよう
・会議やチャットはこまめにリアクションしよう
・メンバー全員がスプリントゴールを把握できるようになろう
　
＜タスク＞
・スウォーミングできるチームになろう
　役割にとらわれず、自分でできることは自分でやる
　個人タスクよりチームのタスクを優先する
　ポジション問わず、違和感を感じた時は些細なことでも言うようにする
　凍結日を意識して、より早く凍結を迎える方をスウォーミングすることを意識する
　
＜PBI＞
・各々が持っているチケットは退勤前に更新しよう
・サブタスクのタイトルに「調査」「検討」のような曖昧なワードを使わない
　　検討→決定する、合意する
　　調査→理解する、明らかにする
　　※「そのタスクが完了したらどうなるのか」が分かるような名付けを心がける

5.おわりに

• Development
• Scrum / Team

---