失敗談1：終わらないユーザーストーリー
西山氏はまず、1つ目の事例である「終わらないユーザーストーリー」について解説する。このプロジェクトでは、1つのスプリントを2週間に設定した。そして、あるユーザーストーリーを終えるのに3スプリント（約1か月半）も要してしまったという。明らかに、開発が円滑に進んでいない状態だ。
「過去に一緒に仕事をしたスクラムコーチが、『スクラムはチームの今を可視化してくれます。それを生かすも殺すもチーム次第です』と言っていました。だからこそ、なぜユーザーストーリーがこれほど長期にわたったのか、チームのみんなで原因と改善策を考えることにしました」
西山氏は振り返りミーティングで、各スプリントで起きた出来事を可視化しようと試みた。用いたのは、タイムラインという手法である。
この手法では、ホワイトボードの横軸を時間軸に見立て、スプリントごとに期間を区切る。そして、それぞれの期間で起きた出来事を付箋に記載し、貼り付けていく。付箋の内容をもとに議論した結果、「特定のメンバーだけではなく、全員がユーザーストーリーに取り組んでいる」ことが見えてきたという。
「私たちのチームでは、1つのユーザーストーリーに1人のエンジニアをアサインする方針をとっていました。この振り返りを踏まえ、チームのルールとして『不明点がある場合や困っている場合には、すぐに全員で集まって作業する』ことを決めました。
このルールにより、作業に問題があった場合でもメンバーがすぐに集まって解決できるようになりました。作業の効率が良くなり、ユーザーストーリーが3スプリントにまたがることは、ほぼなくなりました」
西山氏は「この取り組みはスクラムの3本柱を体現している」と解説する。スクラムの3本柱とは「透明性」「検査」「適応」という3つの軸のことだ。
透明性は、チームの「今」を見えるようにすること。検査は、課題に対して解決すべきか考えること。適応は、課題を解決するためのアクションをすること。前述のようなチームのルール変更の流れは、まさにこの3要素に当てはまっている。
「スクラムの3本柱を意識して運用を続けることが、スクラムの本質を理解し、プロジェクトを成功に導くために必要なことなのです」
