失敗談1：終わらないユーザーストーリー
西山氏はまず、1つ目の事例である「終わらないユーザーストーリー」について解説する。このプロジェクトでは、1つのスプリントを2週間に設定した。そして、あるユーザーストーリーを終えるのに3スプリント（約1か月半）も要してしまったという。明らかに、開発が円滑に進んでいない状態だ。
「過去に一緒に仕事をしたスクラムコーチが、『スクラムはチームの今を可視化してくれます。それを生かすも殺すもチーム次第です』と言っていました。だからこそ、なぜユーザーストーリーがこれほど長期にわたったのか、チームのみんなで原因と改善策を考えることにしました」
西山氏は振り返りミーティングで、各スプリントで起きた出来事を可視化しようと試みた。用いたのは、タイムラインという手法である。
この手法では、ホワイトボードの横軸を時間軸に見立て、スプリントごとに期間を区切る。そして、それぞれの期間で起きた出来事を付箋に記載し、貼り付けていく。付箋の内容をもとに議論した結果、「特定のメンバーだけではなく、全員がユーザーストーリーに取り組んでいる」ことが見えてきたという。
「私たちのチームでは、1つのユーザーストーリーに1人のエンジニアをアサインする方針をとっていました。この振り返りを踏まえ、チームのルールとして『不明点がある場合や困っている場合には、すぐに全員で集まって作業する』ことを決めました。
このルールにより、作業に問題があった場合でもメンバーがすぐに集まって解決できるようになりました。作業の効率が良くなり、ユーザーストーリーが3スプリントにまたがることは、ほぼなくなりました」
西山氏は「この取り組みはスクラムの3本柱を体現している」と解説する。スクラムの3本柱とは「透明性」「検査」「適応」という3つの軸のことだ。
透明性は、チームの「今」を見えるようにすること。検査は、課題に対して解決すべきか考えること。適応は、課題を解決するためのアクションをすること。前述のようなチームのルール変更の流れは、まさにこの3要素に当てはまっている。
「スクラムの3本柱を意識して運用を続けることが、スクラムの本質を理解し、プロジェクトを成功に導くために必要なことなのです」
失敗談2：プラクティスが導入できない
2つ目は「プラクティスが導入できない」という事例だ。あるプロジェクトにおいて、3チームにまたがる10人のメンバーで大規模なスクラムを開始した。振り返りミーティングのなかで、あるメンバーが突然「バーンダウンチャートって必要なんですか？」と質問してきたという。突然の問いかけに対し、西山氏は明快な答えを返せなかった。
西山氏はスクラムコーチから、「バーンダウンチャートはタスクの減少を可視化して、どれだけプロジェクトが進んでいるかをわかりやすくするためのもの」と教わってきた。その教えを否定されたような気持ちになったという。結局、紆余曲折があり、バーンダウンチャートは廃止になってしまった。
「この経験から、スクラムのプラクティスを導入するうえで、メンバーに“目的”を伝えることが重要だと学びました。目的を明確に伝えたうえでアクションを提案することで、チームはアクションの意図を理解し、自発的に取り組むようになります。
しかし、目的を伝えてプラクティスを導入しようとしたところメンバー間の温度感を感じ、まずは全員が目指すべき目標が必要だと考えました。そこで私たちは『あるべきチーム像』についてメンバーと議論し、その目標を達成するためにプラクティスを導入する、という流れに変えました」
目標を設定したことで、良い変化が起きた。「○○なチームを目指すために、○○な行動をしよう」という健全な議論が自発的に行われるようになったという。チームを改善しようとするポジティブな雰囲気が、メンバー間に醸成されたのだ。
失敗談3：白熱して追いつけない議論
3つ目の事例は「白熱して追いつけない議論」だ。あるプロジェクトで西山氏を含む4人のチームを組んだ際、ミーティングのなかで「特定の2人が技術的難易度の高い話を続け、もう1人は内容を理解できないまま聞き続ける。2人の議論が終わった後に、西山氏が要約する」という流れが頻発していたという。この状態を続けるのは、チームとして健全ではない。
そこで西山氏は「ミーティング中に議論についていけなくなったら、おもちゃのボールを掲げて話を止める。掲げた人が理解できるまで、周りのメンバーは丁寧に説明する」というアクションを導入した。さまざまな解決策の中から、選択した解決策がチームの目標に近づけるものになっているか、楽しく仕事ができるかという、2つの観点から考えた結果だ。
このアクションに慣れてくると、ボールを使わずに手を挙げるだけのケースも出てきた。さらに慣れると、メンバーも物怖じせずに「内容が理解できません」と言えるようになったという。
「ミーティングのなかで、メンバーが自分の意思をきちんと表明できるようになりました。素晴らしい変化だと感じています。私がこの事例を通じてみなさんに伝えたいのは『どんどん失敗しましょう』ということです。
他の企業やチームでも、同様の事象が起きた際に、おもちゃのボールを掲げてうまくいくかはわかりません。でも、失敗しても構わないのです。重要なのは、うまくいかなかった場合に『何がダメで、どういう点が良かったのか』を振り返っていくことです」
スクラムにおいて、“良いチーム”は一朝一夕に構築できるものではない。西山氏が語ったように、「透明性」「検査」「適応」のプロセスを続けることで、ようやく実現できるものだ。西山氏の解説した3つの事例は、日々の改善の重要性を私たちに教えてくれた。
お問い合わせ
Yahoo! JAPAN
