はじめに
※本記事は、レセプトチームでスクラムを導入した後の葛藤を描いています。それまでの経緯はこちらを読んでください。
半年先の大規模リリースを見据えたプロジェクトの中で、スクラムのリファインメントをどのように進めていくか——。それは単なる見積もりや作業分解の話にとどまらず、「チームをどう育てたいか」という問いと深く結びついていました。
今回の取り組みを通して、私自身が立ち返った原点、そしてリーダーとしてのあり方について、少し振り返ってみたいと思います。
指針をつくり、渡す。そこにあった"違和感"
もともと私は、「強いチームをつくりたい」という思いを持って、今の会社に入社しました。だからこそ、大規模開発という難所を前に、「どうやってリファインメントを効率よく完了させるか」ばかりに意識が向いていた自分に、ある時ふと違和感を持ちました。
リファインメントの場では、リーダーである私がPBIを用意し、仕様も切り方も決めた上で、あとはチームに渡す——。確かにプロジェクトとしては前に進んでいましたが、チームとして"育っている"感覚がありませんでした。
そんな中、レトロスペクティブの中でメンバーからの一言。
「PBIのスコープに何が入ってるか、久保田さんの頭の中にしかないから」。
その一言が、リファインメントを見直すきっかけでした。
"今、やらなきゃ"。ゴール達成とチーム成長の両立へ
大規模開発は、ゴールに向けた実行力が問われる一方で、チームが前進するための大きなチャンスでもあります。
「やるなら今だ」
そんな感覚に突き動かされるようにして、私はリファインメントの方針転換に踏み切りました。
もちろん不安はありました。今までは、ウォーターフォールの開発手法で設計やどんな作業単位でタスクを振り分けるかはリーダーで決定、スクラムに移行して間もない頃もPBIを切るのはリーダーの仕事。そんな状況から大きく舵を切り、PBIを切るところからすべてを、チームに丸ごと委ねることになるからです。でも、振り返りの場でメンバーが率直に声を上げてくれていたこと、そして一緒に進めているリーダー陣が背中を押してくれたことが、大きな支えになりました。
取り組みの変化と、手応え
新しいリファインメントの進め方は、次のような方針に基づいています：
-
リファインメントは「知識共有」と「学習」の場
-
リーダーはストーリーのみ提示し、PBIの切り出しはチームで
-
スケジュールに縛られず、納得できるまで対話を行う
具体的には、機能の背景や詳細を事前にドキュメントで共有し、会議の中では10分間の黙々タイムで個人が咀嚼。その後、Confluenceのホワイトボードを使ってチームで疑問点を出し合い、十分に納得したうえでストーリーポイントを見積もる流れに変えました。
以前よりも時間はかかるようになりましたが、PBIに対する理解度は格段に上がり、「あの機能って入ってましたっけ？」というような確認も減ってきています。
そして何より、メンバーから自発的な発言や提案が増えてきたことに、確かな手応えを感じています。
チームの文化を育てるということ
このリファインメントの変化は、単なるプロセス改善ではなく、チームの文化を見直す機会でもありました。
私が目指しているのは、メンバー一人ひとりが自ら手を挙げ、発信し、推進できるチームです。そのためには、ただ任せるだけでなく、お互いを尊重し合い、安心して対話できる土壌が必要です。
それが積み重なって、やがて"強いチーム"を形づくるものになるのだと思っています。
おわりに
リファインメントのやり方を変えたことで、リーダーである自分自身も変わっていく必要がありました。手を離す勇気、仲間を信じること、そして対話を重ねること——。
プロジェクトが進む中で、私自身がいま改めて実感しているのは、「目的に立ち返ることの大切さ」です。
組織やチームをある程度経験してきたからこそ、あえて自分のやり方を問い直す。その積み重ねが、次のステージへの一歩になるのかもしれません。
Discussion