組織バックログの対応について

Insurtech研究所所長のたけです。この記事は2023/6月アドベントカレンダー3日目の記事になっています。（「①仲間チームが一体となって成長を実感できる」をテーマに書いています。)

　Insurtech研究所を作るタイミングで組織自体もアジャイルに変化していく組織を目指しました。そのため、開発だけでなく組織運営もスクラムの運営を意識して、プランニングやレトロスペクティブをしながらバックログを消化していく事で、確実に組織として成長できると考えていました。

　ただ、いざ「組織アジャイル」なる活動を始めてみると開発でのアジャイル適用以上にうまくいかないと感じました。

　スクラムガイドでは、『本質的に複雑な作業を必要とするさまざまなドメインでスクラムが採⽤されている』と書いてあり開発以外でもスクラムが有用であることが書かれていますが、実際は開発以外の適用については一筋縄ではいかず、ちょっと組織へのそのままのスクラム適用は無理があるのでは？？といった感想を持ちました。

　今回は組織アジャイルとしてどういったバックログを計画し、対応していくと良いか、うまくいかなかった点とその対策について感想とTipsをまとめたいと思います。

組織バックログがうまくいかない理由

①.ゴールが見えづらい

・プロダクト開発においては、バックログはプロダクトゴールを満たすために洗い出されます。そのため、組織にスクラムを適応するのであれば組織のプロダクトゴールと呼ぶべきイメージが必要となります。

　我々は新しい組織だっとこともあり、ゴールが設定されていない中で運営を開始しました。そのため組織バックログに関しては、ゴールに対してどの程度進んでいるのか？という指針がない中で洗い出したため、結果、バックログを消化しても、自分たちが進んでいるのか進んでいないのかわからない状態に陥り、その事が疲弊に繋がりました。

　また何とかしようと、とりあえずでもゴールを作ればよいと思い、スプリントゴールを設定したのですが、組織に関するタスクは、難易度の高いタスクが多いため、とりあえずのゴールでは簡単な作業はできても、重い作業についてはメンバーが合意できず、簡単な作業はやるが重要な作業は見て見ぬふりをするといった状況に陥りました。

②.バックログの構造化が難しい

　ゴールを設定できたとしても、ゴールに対してそのままバックログに分解するのは筋が悪いと感じています。

　組織の最終的なゴールはミッションやビジョンといったものになると思います。そういった抽象的な概念からバックログに分類するのは、難しく、中々イメージできません。仮に簡単にイメージアップできるとしたら最終ゴール自体がイマイチな可能性もあります。

　我々もゴール設定後にゴールに関連するバックログは出したのですが、バックログを対応してもやはりゴールに対してどの程度進んでいるのか把握できず、どうすればよいかわからないといった状態になり混乱していました。

③.担当の役割分担が難しい

　またバックログを進めていく、担当アサインも難しい問題でした。組織活動を実施する場合はリーダー層が集まって対応することが多くなると思います、リーダー層は別の業務を持っていて、ただでさえ忙しいため、この組織バックログの活動に入れる量には限りがあります。

　そんな中でも割り振られたタスクを頑張って実施するという形で進めていましたが、リーダー層の中で組織バックログのタスクの偏りやメンバーでの優先順位の違いが出て、中々進みませんでした。

　特にスクラムマスターへの負荷感が大きい事がありました。当然スクラムマスターも専任はできないのですが、バックログの見える化やメンバーの調整、ふりかえりやゴール設定のファシリテーション等、タスクは進まないのに、スクラムマスターの負荷だけが大きいみたいな微妙な状態が続きました。

対応方法のTips

①.組織のMVVの及びゴールの設定

　ゴールが見えないという課題については、リーダー層で合宿を実施し、MVVを策定しました。特にビジョンについてはバックログに紐づくような異なる複数の要素を兼ねた６つのビジョンを出すことで、それぞれのビジョンに応じたタスク分解をできるようにしました。

　これは狙って実施したわけではないのですが、なりたい姿の構造化を進めていくうちに結果、『独立しているが、関連性のある６つのビジョン』というビジョンを構造的に描けたのが、バックログを進める対応に大きく寄与していると考えています。

基本的に組織バックログについては上記６つのビジョンのどれかに紐づけるようにしていて、バックログの最初に①～⑥の数字をつけています。そのおかげでバックログとMVVの間に関係が見られ、だいぶわかりやすくなりましたし、ハードなバックログでも対応していくモチベーションに繋がるようになりました。

②.ゴールに対してのバックログの構造化

　組織ゴール達成を目指すのがバックログの意味合いですが、抽象度が高い最終ゴールに対して、そのまま分解してバックログ化することは現実的でありませんでした。そのため、最終ゴールに対してまず、時間軸で分解したゴールを設定しました。上記６つのビジョンに対して、１年後、３ヵ月後、１か月後でそれぞれどうなっているか？を言語化して、直近の３ヵ月の状態(ジャーニーゴール)や１か月後の状態(スプリントゴール)を定義、KPIを定めることで、意味のあるバックログが洗い出せるようになりました。

　ただし、それでもゴールとバックログを整合させることは難しいと感じています。３ヵ月後のイメージを定義したとしても、そのKPIをどのように定義すればよいか答えが分からないからです。

　ここはいったん、仮にでもKPIを定めつつ、スプリント中にゴールとKPI自体を見直すようなタイミングを設け、そのタイミングでふりかえり・むきなおりを実施してゴールを再設定しています。

　スプリント期間内で頻繁にゴールを見直すのはスクラムでは微妙な気がしますが、組織バックログについては難易度や抽象度が高い内容が多いため、KPIを出そうにもKPIとゴールがうまく整合させづらいと感じています。

　仮でもKPIを置いてKPI消化に向けてある程度動いてみて、動いた結果、KPI達成がゴールに本当に紐づくか改めて確認する。という動きは現状の我々のスキルでは必須と感じています。

　しっくりこないKPIでもいったんは定め、動きながらしっくり感じるKPIを定め活動を行う事で、大きく誤った作業を行うリスクを減らせると考えていますし、KPIを定めるスキル自体も徐々に向上していくと思っています。またそのような動き方をするときは、たくさん実施するのではなく、WIP制限などより優先度の高い作業に注力することが重要とも感じています。

③.協働のメンタリティ

　忙しいメンバーが集まらない、一部のメンバーにタスクが偏るといった問題については、『協働のメンタリティ』を意識することで対応しています。

　メンバー間でソーシャルサポートのスキルの重要性を共有し、なるべく助けてもらうように動くこと。また、モブプロの枠を多用し、集まれるメンバーで集まりながら、優先順位が高いバックログタスクについてはタスク担当者とは関係なく、モブ作業で課題解決や計画分割を行う事を意識しています。

　当初、自分一人のタスクという想いが強く、メンバーそれぞれがタスクを持ってしまい、作業が終わらないという状態になってましたが、担当は割り振るものの、『チームのタスク』という意識を持って優先順位が高いものはとにかくモブで倒していくというやり方にしてからやっと運営が回るように感じています。

　またスクラムマスターだけがサーバントリーダーシップを発揮するのではなく、メンバー夫々がサーバントリーダーシップを発揮することもこういった専任できない組織では重要です。

　こういった意識・行動もモブ作業を重視してから徐々にチームに芽生えていっていると感じています。