はじめに
過日、「認定資格スクラムマスター研修 for Women」というスクラムマスター養成の研修を受けてきました。
そのときの所感はこちら
本記事では、研修を経て、スクラムのエッセンスやイベントでここは取り入れたらチームの開発がもっとやりやすくなるかも、と思った点を列挙していきます。
かなり私が所属するチームに沿った内容になっているので、一事例としてご覧いただければと思います。
これ以降、スクラムの基本的な部分はあまり説明せずに専門用語が飛び出します。ご容赦ください。
目次
- 自チームの状況
-
研修を経て、導入を検討したいと感じたもの
- プロダクトビジョンの形成知化
- リリースまでに必要な作業を洗い出して別のバックログアイテムとして切り出す
- タスクのポイント付けにプランニングポーカーを導入する
- 複数スプリントにわたるバックログアイテムはイテレーション単位で細分化する
- チーム外へ依頼が必要なタスクの扱い方を決める
- 受け入れ条件を可能な限り先に決める
- スプリントの進捗状況をプロダクトベースで確認する機会を増やす
- スウォーミングを活用して優先度の高いタスクから完了させていく
- 割り込みの計測を開始する
- チームのベロシティとバッファを加味した計画を練られるようにする
- ハピネスを計測してみる
- プロダクトオーナー・スクラムマスターの役割を分ける
- 人事評価をする人はスクラムチームにいない方がよいかを自チームや自社の他チームにも訊いてみる
- ここまで挙げたものをチームのバックログに積み、他タスクとあわせて優先順位をつける
自チームの状況
研修を経て、導入を検討したいと感じたものに記載する内容は、弊チームの状況に応じたものです。
弊チームでは、2023年7月頃に現チームのマネジメントに本格着手して以降、いくつかの手を打ってきたため、それらをスクラムの文脈に合わせて具体的に記載しておきます。
実際に検討している内容を知りたいんだけど、という方は、研修を経て、導入を検討したいと感じたものにジャンプしてください。
チーム編成
1つの開発グループの中に大きく3つのプロダクトがあり、スクラムチームとしてもふんわりと3つに分かれています。
- Aチーム：POかつSM1人、開発者4人（うち1人はCチームと兼務）
- Bチーム：POかつSM1人、開発者3人（うち1人はCチームと兼務）
- Cチーム：POかつSM1人、開発者2人（全員別チーム兼務、新規開発はしないチーム）
「ふんわり」分かれている理由は、各チームに1人は別チーム兼務者がいるためです。人数的に兼務せざるを得ないのが現状です。
PO・SMは全チーム同一人物、かつ、PO・SMは3チーム兼任しています（すなわちわたし1人・・・）。
3チームは全く以てばらばらなドメインを扱っているわけではありません。
大枠は1つのドメインを扱いつつ、細かなターゲット業務やターゲットユーザー層が異なる3つのプロダクトをそれぞれ担当しています。
↩目次に戻る
チームのタスクはGitHub Projectsに（ほぼ）集約
Redmine、Trac、GSS、ユーザー問い合わせ対応用の内製ツール、メンバーの脳内に散らばっていたタスクをGitHub Projectsに集約し、ほぼ一元管理しています。
ほぼと言っている所以として、フロント部門からの問い合わせ対応については全社共通のツールを利用している、かつ1件あたりのライフサイクルが短いため、引き続き別ツールで管理しています。
約4週間スプリントでスクラムイベントを実施
プロダクト開発部門全体の開発サイクルが1ヶ月単位のため、それに合わせて動いています。
ただ、1ヶ月は長くてちょっと見通しが悪いので、実際の作業は1週間単位で管理しています。
具体的には、This Weekというビューをスプリントビューとは別に管理して、今週対応するタスクを並べています。デイリースクラムではこのThis Weekというボードを利用しています。
↩目次に戻る
スプリントプランニングは3チーム合同で実施、かつ開始時点で各タスク担当者がある程度決まっている
毎月前スプリントが終わった3営業日後に3チーム合同で実施しています。
間隔空け過ぎじゃない？と思われるかもしれませんが、スプリント終了後はスプリントを締めるために優先度調整をしていた問い合わせ対応や諸作業を片付けたり、次スプリントで実施するタスクの整理の時間として設けようとチームで決めました。
兼務メンバーが実際今スプリントに何をやるのかを把握するためには、3チーム合同で開催した方が見通しがよいため、この開催形式をとっています。
PO/SMが私1人で、チームに対する施策も1チームで実施予定のことを他チームにも共有したり、3チーム一挙に展開したりしていくことが多いため、まとめて共有したいという背景もあります。
プランニング時はタスクのアサインはされていない状態で、ただ優先度順にタスクが並んでいるのが理想とされていますが、私たちのチームではプランニングMTG開始の段階ですでに各メンバーがタスクを取った状態で開催されます。
↩目次に戻る
デイリースクラムは3チーム合同
以下の理由により、デイリースクラムは3チーム合同です。
- PO・SMが3チーム兼任のため、チーム施策や部署全体の共有をまとめて実施したい
- 3チームはゆるやかに業務がつながっており、合同でやることでチーム間の相談や連携がしやすい
スクラムにおけるデイリースクラムのセクションは15分以内に収まっています。
それ以外に、問い合わせ対応の振り分け、各種情報共有、PRモブレビューなども地続きで実施しており、正味1時間開催しています。
デイリースクラムのファシリテーターはメンバーで持ち回り
PO/SMにあたるのは私1人ですが、デイリーのファシリテーターは私以外のチームメンバーで持ち回りにしています。
「場を回す」ということに慣れてもらうのと、発言機会を増やすことを主な目的としています。
↩目次に戻る
バックログリファインメントは3スプリントごとにがっつり、週次で軽量版を開催
がっつリファインメント（3スプリントごと）
3スプリントに1度、割としっかり目のリファインメントを、チーム単位で実施します。チーム規模に応じて1～1.5時間取っていますが、それでも足りないことも間々あります。
大まかに以下の流れです。
- 新規で挙がってきたタスクを、タスクの背景を知っているメンバーが簡単に説明
- 3ヶ月以内にやるか、1年以内にやるか、それ以降か、たぶんやらないかをざっくり振り分け
- 3ヶ月以内にやると決めたものの優先順位をつける
- 3か月以内にやると決めたもののポイント数をつける
タスクの細分化については、スポットの不具合修正や軽めの機能強化はある程度対応の流れが決まっているため、お決まりのタスクが自動でリスト化されます。
＋αで調査が必要なタスクや、お決まりの型にはまらないようなタスクの場合は、タスクのゴールを決め、何をしていくべきかをその場でみんなで洗い出します。
このとき、何を以てタスクを完了とするかの受け入れ条件があいまいな状態のままになってしまっていることがしばしばあります。特に定型がないタスクに多いと感じます。
ポイント付けにはTシャツサイズ＋フィボナッチ数（XS-2など）を割り当てたものを使っていますが、プランニングポーカーは導入していません。
あっさリファインメント（週次）
週あたまのデイリースクラムをデイリースクラム拡張版としており、各チームのバックログに3か月以内のタスクが差し込まれていた場合に優先度付けとポイント付けを実施しています。
デイリースクラムの中の1セクションとして実施しているため、3チーム合同です。
あまり重いタスクが差し込まれないこともあり、新規タスクの中身をしっかり見て受け入れ条件を決めて、などはせず、並んでいるタスクのうちだったらここだね、という順番の指定をする程度です。
↩目次に戻る
スプリントレビューは実施しきれていない
そのスプリント内でリリース予定の機能強化タスクについては、タスク単位で機能レビューを実施しています。
機能レビューそのものはお披露目の場に近く、スプリントレビューの目的に近しいですし、開発部門長やドメインエキスパートは参加します。
しかし、より顧客やステークホルダーに近いフロント部門のメンバーは参加しないことがほとんどです。
また、機能強化案件以外のタスク（不具合修正など）の機能レビューは実施しません。
↩目次に戻る
スプリントレトロスペクティブは全然できていない
振り返り＋プランニングをまとめて1つのMTG内で実施しています。このMTGは、前スプリントで実施したことを確認し、できなかったことを今スプリントに回す、ということに留まっています。
そこに対する課題を確認して次スプリントで改善タスクを実施する、ということはできていません。
何かチームに対して実験的に実施している施策については、振り返り時ではなくスポットで改善案を出して回しています。
研修を経て、導入を検討したいと感じたもの
ここからは、研修を経てチームに導入を検討したいものを列挙していきます。
なお、各セクション、私の独断で以下の2ポイントを5段階評価でつけてみました。
- 導入難易度：★が多いほど難易度が高い
- やりたい度：★が多いほどやりたい意欲が強い
↩目次に戻る
プロダクトビジョンの形成知化
- 導入難易度：★★☆☆☆
- やりたい度：★★★★★
プロダクトビジョンとは、平たく言うと「プロダクトにおいて『達成したい将来の状態』を要約したもの」だと捉えています。
プロダクトが進む先という意味で、北極星にも例えられるそうです。
私たちチームでは、リリースから10年超え、20年超えの長寿プロダクトを保守・機能強化しており、現チームではプロダクトビジョンというものが明確に決まっていません。かつてはあったと思いますが、断絶してしまっています。
もちろん右も左もわからないまま突き進んでいるわけではなく、なんとなく「たぶんこういう感じだよね～」という方向性は暗黙のうちに形成されています。
ただしこの状態だと、新規メンバーが来た場合にビジョンをキャッチアップするのに相当な時間がかかります。また、本当にチームメンバー全員が同じビジョンを持っているかは測ることはできません。
暗黙知となっているプロダクトビジョンを、今いるメンバーの認識を結集しつつ、今ある機能と利用ユーザーを見て、形成知に昇華させる必要があると思いました。
そのうえで、改めてチームみんなでプロダクトの未来を見据えて進んでいきたいなと。
どうやるか
以下のいずれかで実施してみようかな～と思います。1の方が豊かなビジョンができそうな気がしています。
- メンバーどうしで「プロダクトの進むべき方向ってどんなんだと思う？」とお題を出して、オンラインホワイトボードなどを使って意見を出し合って形成していく
- POとしてプロダクトビジョンのたたき台を作ったうえで、開発メンバーとブラッシュアップする
↩目次に戻る
リリースまでに必要な作業を洗い出して別のバックログアイテムとして切り出す
- 導入難易度：★☆☆☆☆
- やりたい度：★★★★★
スプリント終了時点ではまだやらなくてもいいけど、リリースまでにはやらなければいけない作業っていくつかあります。
たとえば機能に関するマニュアル作成や、リリース時に必要な追加データの作成などです。
これらのタスクの作り方をちゃんと定義できていませんでした。
その結果、そのときによって完了したはずのスプリントバックログアイテムの最後の1タスクに残り続けてなかなかクローズできない、そもそもタスク化を忘れて後から慌てて追加するということが発生することがありました。
タスクの不必要な停滞やリリースタスク漏れを起こさないように、ルールを決める・フローに組み込むなどの対応をしようと思います。
どうやるか
- お決まりの残作業が発生するバックログアイテムは「ここまでやったらあとは別タスク化してクローズする」と決める
- GitHubのIssue Templateで1タスクとして管理し、「これより上がすべて対応完了したら別Issueを切る」などのコメントをしておく
- 「あとこれだけやったらクローズできる」がしばらく残ってタスクが停滞している場合は別タスク化してクローズするかの判断を入れる
- スプリント終了後に行うMTGなどで以下を確認し、リリースまでに必要な作業をタスク化して元アイテムはクローズする
- 完了したバックログアイテムにリリースまでに必要な作業が残っていないか
- 未完了のバックログアイテムでリリースまでに必要な作業だけが残っていないか
↩目次に戻る
タスクのポイント付けにプランニングポーカーを導入する
- 導入難易度：★☆☆☆☆
- やりたい度：★★★★☆
プランニングポーカーは、正確な相対見積もりを出すための手法です。やり方は至ってシンプル。
- ターゲットとなるタスクについて、有識者が簡単に説明する（内容、発生するであろうタスク、要注意ポイントなど）
- フィボナッチ数列（1, 2, 3, 5, 8, 13, 21）の書かれたカードをメンバー全員が持ち、各タスクで必要なポイントに見合うカードをせーので出す
- メンバー間で誤差が並び合う3つの数字以内だった場合、メンバー全員が出した数字の平均値を出す
- その平均値がそのタスクの見積もりポイントとなる
- 数字の間隔が4つ以上空いている場合は、最小値と最大値を出したメンバーにその根拠を言ってもらう（議論はしない）。他メンバーはそれを聞いたうえで、再度カードをせーのでだす（最大2回までやり直す）
- 根拠を聞いたからと言って、無理に歩み寄ろうとする必要はない。あくまでもそれを踏まえて再度カードを出せばOK
- 合計3回実施しても3つ以内の範囲に収まらない場合は、最大値と最小値を覗いた数の平均値をとる
現状プランニングでポイントを付けるとき、私や主担当になるであろう開発者にまずポイントを出してもらうという状況が多いです。
でも、誰かが発言したことで遠慮して言わなかったけれど、実は他のメンバーは全然違う見積もりをしている可能性はあると思います。
見積もりがばらけた際の根拠を聞くことで、タスクへの共通認識を持つことと、現段階で不確実な部分がないかの確認ができるため、効果が大きそうです。
また上記のやり方だと、PO/SMと開発担当者の 1 : 1 の会話に終始しがちです。全員が参加するプランニングポーカーを実施することで、メンバー全員のMTGへの当事者意識が今以上に出そうだなと感じました。
あと、研修でLEGOを題材にプランニングポーカーをやったら、シンプルに盛り上がってシンプルにめちゃくちゃ楽しかったです。
チームの仲をさらに深めるためのゲーム感覚でやるでもいいんじゃないかなーと思っています。
どうやるか
- プランニングポーカーの手順に記載のとおりではある
- プランニングはGoogle Meetで実施しているので、Meetのチャット欄に数字を入力してもらって、せーのでEnter押す、がシンプルでいいかも
- 最初から本タスクでやろうとすると堅くなってしまうかもしれないので、研修の題材を借りてLEGOでお試しプランニングポーカーやってみてもいいかも
↩目次に戻る
複数スプリントにわたるバックログアイテムはイテレーション単位で細分化する
- 導入難易度：★★☆☆☆
- やりたい度：★★★★☆
複数スプリントにわたるタスク、特に不透明ながらも模索しながら進むしかない類のタスクは、どうしてもスプリントをまたぎがちで、タスクも変動しがちですよね。
研究開発をしながらの実装、既存仕様を読み解きながらの技術的負債解消、レビューを繰り返しつつどこまでも突き詰められるドキュメント作成やデザインの模索などです。
こういったタスクはまず手を付けてみる、手を付けていく中で目途が立ったところからタスクを細分化していくとしていくしかないかなと思っています。
とはいえ、実際に手を動かす開発者としては、不明確な巨大タスクを、何スプリントにもわたって対応していくことになります。
そんな中で別のタスクなどが差し込まれたりすると、長期スパンでやっている巨大タスクは一旦置いて、差し込みタスクに手を付けて、さらに巨大タスクは遅延して・・・など、ずるずると長期化してしまいがちです。
少しずつでもタスクを積み上げて前進させる、前進している実感を開発者が持てるようにするのが肝要だなと思いつつ、スクラム的にはどう扱うのだろう？と疑問だったので講師の方に質問してみました。
その回答としては、「期間（スプリント、スプリントの半分など）でタスクを区切り、そのタイミングでできたところまでをレビューするようにする」でした。それで積み上げていくしかない、と。
それを踏まえて、どうしていくのがいいか、現時点での考えを書いておきます。
どうやるか
- 巨大タスクそのものを今スプリントに置き続けない
- 「次スプリントに送る」という行為そのものが精神負担になる
- 直近やろうとしていることだけでも子タスク化し、それだけを今スプリントに並べる
- 期間（スプリント、スプリントの半分など）でタスクを区切り、そのタイミングでできたところまでをレビューするようにする
- タスクのログとして、その期間内にどんなことをやっていたのか、どこで躓いていたのかを書いてみる
- 何も残していないと、ただ「終わらなかった」という事実だけが残ってしまい、精神衛生上よろしくない。躓いた箇所がわかると、少なくとも無意味に過ごしたわけではないと目で見てわかる
- タスクを担当していないメンバーも、そのタスクで何をしているかが見えるようになる
↩目次に戻る
チーム外へ依頼が必要なタスクの扱い方を決める
- 導入難易度：★☆☆☆☆
- やりたい度：★★★☆☆
これも、スクラム的にどう扱うのが一般的？というのが気になったので確認しました。いただいた回答のとおり進めるのがよさそうだと感じたので、どうやるかのセクションにそのまま記載します。
どうやるか
- スプリント内で返ってくる内容の場合：返ってくるまでは置いておく
- スプリントをまたぐ場合：依頼前後でタスクを分ける
↩目次に戻る
受け入れ条件を可能な限り先に決める
受け入れ条件とは、個々のバックログアイテムがどこまでできていれば完了と見なせるかを定めたものです。
各バックログアイテムの目的に応じて受け入れ条件を設定する必要があります。
たとえば社内でモックアップが見せられればいいのか、実際に機能をリリースするのかなど、ターゲットによって、受け入れ条件は変わってきます。
機能リリースに向けた実装タスクの場合、受け入れ条件がテスト観点になっていきます。
もともと会社で定義されている品質要件があるので、まずはそこをクリアすることが最低条件です。
加えて、弊社の新規開発／機能強化案件の場合、開発者が実際にどんな機能を作っていくのかを決めるフェーズがあります。まずそのフェーズだけでタスクを切り、そのタスクの中でどんな機能を作るのかが決まった後は、実装に向けて受け入れ条件を改めて記載する。これにより、実装時のブレも少なく、PRや機能レビュー、テストケース作成の指標にもなります。条件が揃えばテスト駆動開発を行うことも可能です。
現状、まだまだ手動テストの実行が多いこともあり、出てきたPRをベースにテスト観点を洗い出し、テストを作成しています。
もちろん受け入れ条件を先んじて定めるようにしたとしても、PRベースでの観点チェックは必要だと思いますが、先んじて観点が明文化できていれば、それを指標に実装やレビューができるようになるので、可能な限り受け入れ条件を先に決める癖をつけていくところから始めたいです。
どうやるか
- いくつか製品全体で定義されているお決まりの品質要件があるので、受け入れ条件のテンプレートに組み込む。まずこれを受け入れ条件の最低ラインとする
- 新規開発／機能強化の案件では、作る機能を決めるフェーズと実装のフェーズでタスクを細分化する。決めるフェーズが終わった段階で実装フェーズの受け入れ条件を決める
- 実装タスクの場合、受け入れ条件＝テスト観点として捉え、実装に先んじて観点を考えられる仕組みを作る
- 各種実装タスクはテンプレートによって自動起票されているので、そのテンプレートの中に受け入れ条件を考える、を組み込むのがよさそう
- テスト観点及び実際のテストを受け入れ条件ベースで記載する
↩目次に戻る
スプリントの進捗状況をプロダクトベースで確認する機会を増やす
- 導入難易度：★★★☆☆
- やりたい度：★★★☆☆
スクラムでは人にタスクをアサインするのはプランニングではなくデイリースクラムの段階がセオリーです。
しかし私たちのチームでは、プランニング段階、何ならその前段階でメンバーにタスクをアサインしているのが現状です。
その結果、人単位での状況確認をしてしまっており、じゃあ今プロダクト単位でのタスク状況はどうなの？という確認ができていないと感じました。
1つの開発グループの中に3つのチームが入っており、1人のマネージャーがそれを見ているという状況も相まって、管理のしやすさからメンバー単位での確認になってしまっているなとも思います。
とはいえ、急に「今スプリントから人へのアサインはしません！」となっても大混乱をきたすので、まずはメンバー単位ではなくプロダクト単位でタスクの進捗を確認する癖をつけたいです。
どうやるか
- 週ごとやスプリントごとに見るプロダクト単位のボードを用意し、意図をチームメンバーに説明する
- 週ごとやスプリントごとにプロダクト単位のボードを確認する時間を設ける
↩目次に戻る
スウォーミングを活用して優先度の高いタスクから完了させていく
- 導入難易度：★★★★☆
- やりたい度：★★★★☆
スウォーミングとは、虫が群がることです。転じて、スクラムの文脈では、優先度の高いタスクから順にチーム一丸となって取り組むことを指します。
弊チームでは、現状、人にタスクがアサインされている状態になっています。
かつ1つのプロダクトに対して複数案件が同時進行している状況なので、どうしても1案件1人アサイン状態になっています。
RSMの研修では、スウォーミングのあるべき姿を学びましたが、弊チームの状況でスウォーミングから始めるのは無理じゃないか・・・？と思っていました。
そんな中で、スウォーミングの実践として以下の記事を読みました。
詳細は上記記事を読んでいただきたいですが、上記方法であれば、ある程度個人でタスクを進めつつ、必要なタイミングでペア／モブによって優先度の高いタスクにスウォーミングできそうだと感じました。
どうやるか
- プランニングやデイリースクラムで、優先度の高いものはこれ、だからこのタスクに関する（＝このタスクを担当している人からの）相談・PRレビュー・モブプロ依頼は最優先で！とチームで共通認識を作っておく
- 優先度の高いタスクからの号令がかかったら他メンバーは最優先で対応する
- だからと言って、それ以外のタスクでペア／モブなどをやっちゃダメということではもちろんないんだよ、ということにも共通認識を持っておく
↩目次に戻る
割り込みの計測を開始する
- 導入難易度：★★★☆☆
- やりたい度：★★★★★
割り込みタスクについては、割り込みタスク用のバッファをあらかじめ設けていくのがスクラムパターンの1つです。
私たちのチームは日々少なからず割り込みタスクを捌きながら業務を実施しています。
私が考える割り込みタスクは以下のあたりです。
- サポート開発、フロント部門を経由したユーザーからの問い合わせ対応1
- インシデント対応
- チーム横断タスク
- 全社向け講座受講
- 人事評価入力、キャリア面談
- 予定外の不具合修正
これらは多かれ少なかれじわじわと差し込まれてくるものの、実際にどのくらいの数と分量が来ているのかはわかっていません。
計画段階ではやりたいタスクがたくさんあるので、できるだけ詰め込みたくなります。その際に割り込みタスクのことは都合よく頭から抜けているはずです。
その状態で計画を練ったら、仮に割り込みタスクを捌きながら予定通りにリリースできたとしても、大体メンバーに無茶を強いているはずです。
そのため、まずは割り込みタスクがどのくらいの数来ていて、各ポイントはどの程度なのかを把握する必要があります。
どうやるか
- 特に問い合わせ対応について、タスクを簡単に収集できる仕組みを作る
- 問い合わせ対応はGitHub Projectsとは別ツールで管理しているため、収集方法を検討する必要がある
- 割り込みの計測を開始し、数スプリント様子を見る
- Projectsで管理する割り込みタスクに付与するラベルを決め、付与する
- 上記で挙げた割り込みタスクに、事後でいいからポイントをつける
- 問い合わせ対応などはむしろ事後じゃないとボリューム感がわからないものがほとんど
↩目次に戻る
チームのベロシティとバッファを加味した計画を練られるようにする
- 導入難易度：★★★★☆
- やりたい度：★★★☆☆
これらを軌道に乗せることに成功してしばらくたったら、チームとしてスプリント単位でのベロシティが見えてきて、バッファ2として積むべきポイントが見えてくるはずです。
そうなれたら、計画を立てることが目的にならないようにしつつ、それらのポイントに沿ってスプリント計画を立ててみたいです。
↩目次に戻る
ハピネスを計測してみる
- 導入難易度：★☆☆☆☆
- やりたい度：★★☆☆☆
ハピネス（幸福指標）はパフォーマンスの先行指標と言われています。
やりかたはとても簡単で、以下の3つの観点について、1～5でスコアを付けます。
- 自分自身の役割についてどう感じる？（Self）
- 自チームについてどう感じる？（Team）
- 自社についてどう感じる？（Company）
各メンバー個人の感覚でOKで、人と比べるものではありません。
ハピネスは生産性に関わってくる指標で、計測を続けることで見えてくるものがあります。
たとえば普段よりもハピネスが下がっていた場合、なにか問題が隠れている可能性が高いです。
個人やチーム全体のハピネスが下がってしばらく経つと、その人やチームの生産性そのものが下がってしまう、いわゆる問題の兆候になるらしいです。
とても手軽に導入できますし、継続する価値があるかは、計測を続けることで判断できる類の指標だと思うので、やってみてもいいなと感じました。
どうやるか
- どの単位で計測するかを決める
- 基本は1スプリントごとでいい気がするが、長すぎるなら1週間ごとでもいいかもしれない
- 計測したデータをどう管理するかを決める
- スプレッドシートでの管理
- 簡単だが、GitHub Projectsと動線が離れてしまう
- GitHub Projects内での管理
- ハピネス計測用のFieldを作る（Self・Team・Company）
- 通常IssueでもFieldが表示されてしまうのが玉に瑕
- スプリントの振り返り用のIssueをメンバー単位で切って、ハピネス計測Fieldに値を入れる
- このIssueを作ると振り返りにも使えそう
- Insightsにハピネス計測用のチャートを用意する
- ハピネス計測用のFieldを作る（Self・Team・Company）
- スプレッドシートでの管理
↩目次に戻る
プロダクトオーナー・スクラムマスターの役割を分ける
- 導入難易度：★★★★★
- やりたい度：★★☆☆☆
弊社の開発組織の多くは、もともとチームのマネージャーがいてその配下に開発メンバーがいるという組織構造をしています。マネージャーは配下のメンバーの開発状況を確認しつつ、最終的にどの開発物をリリースできるかの判断をしています。
その状況でスクラムライクな運営をしようとすると、よほど強い意志を働かせない限りはもともとプロセスとプロダクトの両方に責務があるマネージャーが、POとSMを兼任したままチームが走っていきます。
一般的に、POとSMの兼任はアンチパターンと言われています。
このままではスプリントレビューまでに間に合わないとなったとき、POとSMを兼任していると、POの責務を重視しがちになってしまうからです。これはRSMの研修でも改めて言われました。
これはたしかに実感としてあります。
この機能、スプリントレビューに間に合わないかも・・・でもここまでにリリースしないとユーザーの稼働に間に合わないと言われている・・・となったとき、つい「なんとかリリースさせたい」という気持ちが先に来てしまいます。それは、開発者に無理を強いることになります。
役割が分かれていれば、SMから明確に「このままでは間に合わない。顧客やステークホルダーと交渉が必要だからPO頼む」という会話がされるはずですが、そこが無意識にすっ飛ばされてしまいます。
そのため、以下の役割を分けたほうがいいのは間違いないです。
- チーム運営に重きを置くSM的役割
- 機能をリリースしプロダクトをユーザーに届けることに重きを置くPO的役割
が、ちょっと王道スクラムチームとは異なる、変化球なやり方が必要かもなと思っています。
RSMの研修を受けてもなお、私たちのプロダクトや製品の性質や、弊社のプロダクト開発の醍醐味的な部分と、スクラムがマッチしない部分があると感じているからです。
どうやるか
- まず自分はどちらがやりたいかを考えてみる（現状どちらも楽しいが、どちらも中途半端な印象があるので）
- チーム内でスクラムにおける役割と、役割分担によるメリットを布教する
- 中長期的にSM／POを任せることができるメンバーを増やす
- これは弊社の開発スタイル的に、開発者として成長していくにつれてどちらも養われると思っている
↩目次に戻る
人事評価をする人はスクラムチームにいない方がよいかを自チームや自社の他チームにも訊いてみる
- 導入難易度：★★☆☆☆
- やりたい度：★☆☆☆☆
研修の中で、実務でスクラムを実践されている方から、「人事評価をする上司でありながらスクラムチームのプロダクトオーナーやスクラムマスターとしてチームにいると、議論のハードルが上がって話しづらい・・・」という意見をいただきました。ですよねえ。
弊社は360度評価＋MBO評価、特に開発者には360度評価が重要視されているものの、それでもMBO評価をする上司という立場にいる私がスクラムチームのプロダクトオーナーやスクラムマスター的な立場でチームにいると、やはり議論のハードルは上がってしまうのかな・・・と悩ましかったです。
自チームやの自社の他チームでスクラムを実践している開発者のメンバーにも意見を訊いてみたいと感じました（真っ向から訊かれてても答えづらいだろうなあとは思いますが）。
↩目次に戻る
ここまで挙げたものをチームのバックログに積み、他タスクとあわせて優先順位をつける
- 導入難易度：★☆☆☆☆
- やりたい度：★★★★★
ここまで挙げてきたものすべてを一気に進めるのは不可能です。
まずチームで導入したり試したりできそうか、やるとしたらどのタイミングがよいか、全チーム一斉にやるのか、どこかのチームがパイロット的に実施してみるのかなどを考えるタスクが必要です。
その後、各タスクをバックログに並べて、優先度をチームメンバーと決めていきたいです。
↩目次に戻る
おわりに：どこまでスクラムを導入するかはまだ迷っている
ここまで、スクラムマスター研修を受けた中で、チーム内に導入したい・導入を検討したいと思った内容を並べてみました。なっがい。
ただ、スクラムマスター研修を受けてもなお、スクラムをどこまで導入するかは悩んでいます。
弊社のプロダクトは、ノーカスタマイズの大企業向けERPパッケージシステムとして、20年以上前から「ユーザーのニーズに基づいて機能強化をし続ける」という、アジャイル的な考え方を取り入れており、ウォーターフォールの開発手法とは明確に異なります。
かといって、開発手法として厳密かつ明確にスクラムを導入しようとしてきたわけではなかったため、開発スタイルとしてはスクラムのエッセンスも持ちつつ独自進化を遂げています。
その手法の中には、スクラムとしてはアンチパターンかもしれないけれど、よさだと感じている部分もあり、それらを排除してむりやりスクラムを導入したいとは思いきれない部分もあります。
なので引き続き、ここは確実にチームにとってプラスになりそう、試してみる価値があるな、と思った点を導入してみて、ちゃんとスクラムやってみたい！とチームでなったタイミングで変えようかなと思っています。