開発もすなるスクラムといふものを、組織開発もしてみむとてするなり

田部井勝彦

2021.12.01

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちわ。てぃーびーです。

従業員体験(EX)の向上に向けて、組織開発を行っていく私達のチームでスクラムを利用しはじめました。運用整備から3イテレーションを終え、大枠の運用フローが確立され、手応えがあり、「継続運用していこう！」という状況になったので、経緯や運用方法について情報をまとめます。

導入経緯

2021年11月1週目のチーム定例にて、どのように仕事をすすめていくかについて話し合っていました。我々の業務のコンテキストとして、

組織開発の業務は複雑で明確な正解がなく、不確実性が高い。仮説を元にアウトプット・プロセス両面に関する試行錯誤をする必要がある。その組織開発業務をこれから継続して実施していく必要がある。

という特徴があり、それに対して

スクラムを用いて組織開発の業務を遂行する。取り組み対象の不確実性の高さはプロダクト開発に類似しており、スクラムが持つ経験主義およびスクラムの価値基準との親和性が高いと考えた。

という意思決定をした形になります。実際にスクラムガイド2020年版ではスクラムがプロダクト開発以外の様々な領域で利用されはじめていることが記されています。例えば、スクラムを教育領域に適用した EduScrum などがあります。

この意思決定内容は以前紹介した ODDR として記録してあります。

ODDR について詳しくはこちらを参照ください。

組織開発の意思決定透明化のために ODDR を試すことにしました

なお、運用開始に至るタイムラインは以下のようになっていて、意思決定のスピード感を感じます。

入社1週目の 2021/11/05 にスクラムの活用を提案。「Start Small の精神でまずは試そう」ということになった
- CLP - Start Small の精神
2021/11/08 〜 2021/11/10 までに運用準備を実施
- スクラムイベントの曜日決めと決定後の日程調整
- スクラムイベントの議事録テンプレート作成
- スクラムの運用ルールに関するポータルページの作成
2021/11/11 からスプリント0を開始

また、11月に入社したばかりである私の提案でも最初から採用してもらえるような環境であることが確認できました。

運用に関して

バックログの管理

プロダクト開発における PB(Product Backlog) / PBI(Product Backlog Item)は, 文脈的に Product が対象ではなく従業員体験(EX)が対象になるため、 EXB(Employee Experience Backlog) / EXBI(Employee Experience Backlog Item) と呼ぶことにしました。中身や運用については教科書通りです。

Employee Experience Backlog(EX Backlog)

Sprint Backlog

スクラムイベント

デイリースクラム - 毎日30分
リファインメント - 週1回月曜 1時間
スプリントレビュー - 週1回水曜 1時間
スプリントレトロスペクティブ - 週1回水曜 1時間
スプリントプランニング - 週1回木曜 1時間

教科書通りの運用です。実施内容も教科書通りで、特筆すべきことはないです。

曜日については、週頭にスプリントを開始して、週末に終えるパターンと週中を境にするパターンがありますが、今回は週中バージョンを選びました。深い理由はなく、まずは試してみようという温度感です。ちなみに、水曜日の夕方にスプリントを終えてから、翌日の夕方にスプリントプランニングをするまで半日程度の隙間がありますが、ここはあえてあけてあり、スプリントに絡まないがすすめたかった細かなタスクや学習にあてることができるようにしてあります。

スプリントレビューに関しては直近アクティブに組織施策が動いているところに関わるステークホルダーには必須で参加いただき、その他のステークホルダーに関しては任意で参加していただく形にしました。組織開発は施策数が増えるとステークホルダーも増えるので、このあたりは運用しつつ試行錯誤になりそうです。

スプリントレトロスペクティブについては、 KPT を実施しています。Keep, Try に関して、心構えに関わるような項目は Notion のチームトップに作成してあるダッシュボードにいつでも確認できるように埋め込んであります。個別のタスクとして対応が必要な Try は EXBI に追加します。

スプリントプランニングでは、今回のスプリントで取組む対象を EXBI から選択し、完了の定義を行います。そして、タスクばらしをしつつ Sprint Backlog に追加していきます。そして、アサインを決定します。さらに、スプリントゴールを設定します。スプリントゴールにはそのスプリントはどのような目的を持ち、インクリメントとして何を提供するかの完了条件を定義します。スプリント内ですべてのタスクが終わらなさそうなときにスプリントゴールの内容を元に何を先送りにするのか判断がしやすくなります。

ロール

スクラムオーナー - エンジニアリング統括室の室長である大橋
スクラムマスター - 明示的にはおかない。役割としてはエンジニアリング統括室のメンバーである髙木、田部井がふたりとも受け持つ
組織開発メンバー - 髙木、田部井
スクラムチーム - スクラムオーナー, スクラムマスター, 組織開発メンバーの全体

おおわく標準的な運用でありますが、小さなチームということもありメンバー二人がスクラムマスターを兼ねることにしました。

ベロシティ

こちらも標準的にフィボナッチ数をもとに 1〜13の間でプランニングポーカーで設定しています。マネージャーであり、プロダクトオーナーである大橋さんも一緒に実施するので、マネージャーからみてチームの状況が把握しやすくなっていますし、ギャップがあればプランニングポーカー時に認識差をお互いに説明し、すりあわせることができるようになっています。

実際の運用

現状3スプリントの実施を終えています。チームのキックオフからの段階ということで、大玉で取組む対象自体これから検討になっています。現状は足回りを整備したり、今後の取り組み対象を選択するための前提タスクをやっていました。その意味では実際に個別の組織課題に対応する中でのスクラム活用なこれからになります。

イベントの設定により、チームの活動にリズムができ、透明化され、コミュニケーションが深まり、課題が明確になり、一つずつ着実に重要な対象から取組むことができています。

その他の運用

MVVB の設定

今後大玉の課題を選択していく上で、エンジニアリング統括室がチームとしてどこを目指し、何を大切にしていくのかという前提が最優先であり、今後の判断軸にもなるということでスプリント0でチームの MVVB を作成しました。

インセプションデッキの作成

MVVB と同様に、今後大玉の課題を進めていく上で「トレードオフスライダー」「やっていかないこと」「おとなりさん」の整理が必要、ということになり、インセプションデッキを作成しました。

ダッシュボードによる可視化

先述のインセプションデッキや KPT からの心がけなど、スクラムチームやステークホルダーが見たい情報を集約して可視化しています。このダッシュボードに関しては、 Thought Works の Single team remote wall をヒントに整備しました。 KGI, KPI は現在検討中で、決まり次第加えていきます。

Notion の徹底活用

様々な場面で Notion の恩恵を受けています

ダッシュボード - Notion のチームトップページに整備。各種情報を埋め込み
スクラムイベント議事録 - Notion のテンプレートを作成し、実施ごとにテンプレートから作成
EX Backlog / Sprint Backlog - Notion のボード機能を活用
スクラムの運用ルール - Notion のページで作成

壁打ちへの感謝

スプリントゴールの扱いについて、チームで疑問がでたとき、 misc-scrum という Slack チャネルで相談したところ、多くのリプライをいただき、疑問が氷解しました。社内にスクラムの経験者が多く、しかも気軽に相談にのっていただけるのがありがたく、自社サービスの Proflly の機能でさっそく関係者に Thanks をおくりました。