スクラムがくれたのはリズムであって、羅針盤ではない

こんにちは。Rimo でソフトウェアエンジニアをしている Prerna Dabi です。多くの開発者と同じように、私もふだんは実装のことを考えている時間が長いのですが、コードを書く前に行われるプロダクトの意思決定に、次第に関心を持つようになりました。マネージャーからの勧めもあり、今回のワークショップに参加することにしました。

会場には40人ほどの参加者がいて、私はその中で最年少でした。Jeff の進め方は好奇心と発言を歓迎するもので、私も期間を通してたくさん質問をしました。この記事では、解決策を作る前の段階にある考え方、前提、そして問題の捉え方を扱います。次の記事では、それを実践に移すための具体的なフレームワークと手法を紹介します。

私が知るかぎり、多くの開発チームは出荷することが得意です。計画し、見積もり、レビューし、デプロイし、期日どおりにスプリントを終える。ですが、その仕事のうち、実際に使う人にとって何かを変えられているものは、どれくらいあるのでしょうか。初回のセッションで、Jeff はその答えを示しました。

Jeff Patton との4日間。その中で繰り返し出てきたのが、次の問いでした。私たちは出荷が得意なはずなのに、なぜ実を結ぶものがこれほど少ないのでしょうか。

初日の途中、Jeff は Marty Cagan の顔写真が載ったスライドを映しました。吹き出しには一文だけが書かれていました。

私たちが出荷するソフトウェアの、およそ50%から80%は、その目的を達成できていない。
Marty Cagan ・『INSPIRED』著者 ・ eBay でプロダクトと UX を10年以上率いた人物

この数字について、少し考えてみてください。プロジェクトの50〜80%が遅延するという話ではありません。50〜80%にバグがあるという話でもありません。実際に出荷され、期日を守り、品質を満たし、レビューされ、マージされ、デプロイされたソフトウェアの半分から5分の4が、本来やるべきだったことをやれていない、という話です。

私たちは「出荷すること」自体は、かなり上手にできています。だからこそ、この数字は考えさせられます。

名目上は CSPO の認定研修でしたが、実際にはこの数字がなぜここまで高いのかを正面から論じる場でした。私は Rimo の研修制度を利用して、日本から、1日4時間の講義を4日間受けました。

Jeff Patton は『User Story Mapping』（オライリー、邦訳『ユーザーストーリーマッピング』）の著者であり、ストーリーマップという手法そのものを生み出した人物です。認定スクラムトレーナー（CST）として、20年近くにわたり、ソフトウェアの作り方ならすでに十分に知っているチームへプロダクト思考を教えてきました。

この点は、この記事の読み方にも関わります。彼が教えているのは「出荷の仕方」ではありません。すでに十分に出荷できているチームに向けて、その前提を問い直す内容でした。

この記事はその前半、つまりどんなプロセスも助けになる前に正しくしておくべき「枠組み」の話です。後編では、目標とするアウトカムから実際にリリースできるものまでを回す、実践的なループを扱います。

研修中はずっと、ブレイクアウトのグループで Marvel Unlimited アプリを題材にした演習が続きました。ここでは私のグループが実際に話した内容を引用しています。ほとんどの場合、Jeff がその概念に名前を与える10分ほど前に、私たち自身が手探りでそこへたどり着いていたからです。その瞬間を見るほうが、定義を読むよりずっと説得力があります。

スクラムは本当はどこから来たのか

Jeff は予想しなかったところから始めました。1986年、竹内弘高と野中郁次郎による Harvard Business Review の論文 The New New Product Development Game です。スクラムという言葉はここから来ています。そしてこれはソフトウェアの話ではまったくありませんでした。ホンダやキヤノンといった企業が、どのように新製品を開発していたのかを調べた研究だったのです。

ラグビーの比喩こそが本質です。スクラムでは、チームはボールを前後にパスしながら一緒にフィールドを進みます。専門家から次の専門家へと順番に受け渡していくのではありません。論文はそうしたチームを機能させている要素を挙げていますが、その一覧は私たちの多くが実践しているものとは違います。

• 組み込まれた不安定さ。要件は変わる前提です。それはプロセスの特性であって、分析の失敗ではありません。

• 自己組織化したチーム。どう進めるかはチームが決めます。

• 重なり合う開発フェーズ。設計が終わってから実装が始まるのではありません。同時に走り、互いに情報を与え合います。

ソフトウェア業界はこの言葉を取り入れ、そして三つ目をおおむね捨てました。儀式とリズムだけを残して、実質的にはフェーズ分割へ戻りました。設計が終わってから開発が始まる。ディスカバリーは前の四半期に別のチームがやった何か。

こうして、デリバリーは本当に優秀なのに、それでも Cagan の言う50〜80%に入ってしまうチームができあがります。

「アウトプットの完了」は「アウトカムの完了」ではない

私にとって、ほかのすべてを組み替えたのはこの区別でした。

アウトプットの完了とは、作られたということです。動き、テストされ、レビューを通り、マージされ、デプロイされた状態。多くの現場で実質的な「完了の定義」になっているものです。

アウトカムの完了とは、リリースされ、人々がそれを見つけ、使い、意図したとおりに行動が変わったということです。

インパクトは、その結果として事業が得るものを指します。

ここが重要な点です。ベロシティは肝心のものを測っていません。Jeff はワークショップ全体の結論を1行にまとめ、ホワイトボードに赤で書きました。作る量を減らすこと。同じ成果をより少ない実装で得られたなら、それが良い仕事です。

持ち帰るとしたら
直近でリリースした5つについて、意図したアウトカムとそれを示す指標を書き出せるでしょうか。そのうち何件について、リリース後に何が起きたかを実際に把握しているでしょうか。

ウェイターか、医者か

チームがステークホルダーとどう向き合うかについての Jeff の枠組みです。自分がどちらに当てはまるかは、すぐに分かりました。

ウェイターは注文を受けます。客は欲しいものを分かっていて、ウェイターはそれを正確に書き取り、頼まれたとおりに届けることが成功です。料理の選択が失敗だったとしても、ウェイターが責められることはありません。

医者は注文を受けません。特定の処方を求めて診察室に入っても、良い医者はまず実際に何が起きているのかを尋ねます。求めたものが出てくることもありますが、多くの場合は違うものが出てきて、そのほうが結果的に良いのです。

Jeff が失敗例に挙げたのは Amazon Fire Phone でした。経営陣の確信を忠実に作り上げ、誰もきちんと問いかけていなかった市場に拒絶されたものです。対照的な例は Spotify の Discover Weekly で、経営陣は懐疑的でしたが、それでもチームを信じました。

ただし Jeff は一点を強調しました。自分で宣言したところで医者にはなれません。ステークホルダーからの信頼が必要で、そのためにはプロダクトを計測し、アウトカムを繰り返し示し続ける必要があります。さらに彼の言う「ベッドサイドマナー」も要ります。下手にステークホルダーに異を唱えれば、扱いにくい人という札が貼られるだけです。

演習にて

私たちの「注文票」

初日、10分間で Marvel Unlimited の問題点をひたすら書き出しました。ボードはすぐに埋まりました。検索が機能しない、キャラクターをまたいでストーリーを追えない、オフラインのダウンロードが失敗する、Android タブレットでの読み込みが遅すぎる、折りたたみ端末で画面を活かせていない、そして紙のコミックを持つ感覚がまるでない。
すべて事実でした。そしてすべて役に立ちませんでした。私たちが作ったのは、きれいに整理された注文票にすぎず、どの問題が誰にとって重要なのかは、どこにも書かれていなかったのです。この空白を埋めることが、残りの日程の目的でした。

そもそも何が「プロダクト」なのか

ここで Jeff は、予想よりずっと広く定義を取りました。プロダクトとは、誰かのために作ったり行ったりするもの全般です。モノでも、サービスでも、その組み合わせでもかまいません。つまり人事もプロダクトです。社内ツールもプロダクトです。自社のエンジニアが使う API もプロダクトです。

重要なのはアウトサイドインで考えることです。作ったもので定義するのではなく、誰かがそこから何を得るかで定義します。

Jeff は組織を玉ねぎの層に見立てました。エンドプロダクト（顧客が実際に買っているもの）、顧客が使うためのプロダクト（アプリ、ウェブサイト）、従業員が使うためのプロダクト（店舗システム、コールセンターの画面）、そして開発チームのためのプロダクト（サービス、API、共通コンポーネント）です。

そして、実務で最も効いてくる区別が「選ぶ人」と「使う人」です。導入を決める人が、必ずしも使う人とは限りません。コンシューマー向けなら大抵は同じ人物ですが、B2B や社内ツール、つまり経営層が買って現場全員が使うようなものでは別人であり、その利害は本当に対立し得ます。

演習にて

そもそも誰のためのものか

3日目、Marvel Unlimited が本当は誰のためのものかで長く議論しました。子どもか。10代か。コミックとともに育った大人か。
そのとき、チームの誰かが自分自身についてこう言いました。

「私は顧客だと思います。物語が好きで、あの冒険と物語が好きだから。でももうユーザーではありません。Marvel に対しては、一生顧客であり続けます」
これがすべてでした。感情的にも金銭的にも深く関わっているのに、アプリは開かない。別のメンバーは、5年後には自分でお金を払う顧客になるという理由で10代を推しました。3人目は、Jeff が先に話していたミルクシェイクの話、つまり親が子どものために買うという例を持ち出し、そこから「親はユーザーでもあり顧客でもある」という結論にたどり着きました。
私たちが議論していたのは「ユーザーは誰か」ではありませんでした。二つの異なる役割を、ひとつの言葉で呼びながら議論していたのです。「選ぶ人」と「使う人」を分けた瞬間、議論は30秒ほどで解けました。

持ち帰るとしたら
自分たちの機能について、選ぶ人と使う人は誰でしょうか。両者が違う場合、私たちは実際にどちらの体験を最適化しているのか、そしてそれは意図した選択だったのでしょうか。

ミッション・ビジョン・戦略というガードレール

Jeff は最初に、これらの言葉については専門家同士でも定義が食い違うこと、自社の経営陣は別の定義を持っているかもしれないことを断りました。彼の定義が役に立つのは、まさに三つがはっきり切り分けられているからです。

ミッションは、その組織がなぜ存在するのかです。常に真であり、完了することはなく、規模や成長の話には決してなりません。IKEA なら、多くの人に手の届く機能的な家具。LEGO なら、明日の作り手を育てること。Tesla なら、持続可能エネルギーへの移行を加速すること。だからこそ Tesla が太陽光パネルや充電網を売るのは、脇道ではないのです。

ビジョンは、まだ存在しない未来において人々がプロダクトからどう価値を得るのかを描いた物語です。少しSFがかっているくらいでちょうどいい。最もよくある失敗は、成長目標がビジョンの衣装を着ているケースです。「2030年までに5万人の受講者」はビジョンではありません。築こうとしている未来について、何も語っていないからです。

戦略は、そのビジョンへ向かう四半期ごとの段階的な計画であり、ビジョンと違って「今できること」でなければなりません。Jeff は Roger Martin の『Playing to Win』を引きます。あらゆる戦略的な賭けは、どこで戦うかとどう勝つかに答えている必要があります。

演習にて

Spotify に存在しないビジョン

Spotify のミッション・ビジョン・戦略を調べる課題が出ました。しかし、本当のビジョン・ステートメントは見つかりませんでした。あったのは戦略の柱の集まりです。膨大なライブラリ、モバイルファースト、そしてディスカバリーへの大きな投資。
面白かったのは矛盾のほうです。Spotify のミッションは人間の創造性を解き放ち、アーティストが自分の作品で生きていけるようにすることです。一方でオフライン体験は、自ら掲げるアクセシビリティの目標を損なうほど出来が悪く、AI生成音楽への進出は、アーティストへの支払いを語るミッションの隣に据わりが悪いまま置かれています。
企業のミッションを実際のプロダクト判断と突き合わせて読むのは、短時間でできる、かなり率直な確認方法でした。自社に当てはめて考えてみたくなりました。

センシング：儀式のない仕事

問題に気づき続けることを、このワークショップではセンシングと呼びます。Jeff の主張は率直でした。顧客とは少なくとも週に一度は話すこと。四半期に一度の調査報告会ではなく、毎週です。

経路はさまざまです。ユーザーインタビュー、実際に働いている様子の観察、プロダクトの指標、サポートへの問い合わせ、営業が繰り返し聞いている声、SNS やフォーラム、競合の動き、そしてドッグフーディング。

この節で強く残ったことが二つあります。ひとつは、プロダクトインタビューの進め方を描いたボードの隅にあった一文、be interested, not interesting（面白い人になろうとせず、興味を持つ人であれ）です。インタビューでは、その領域を理解していることを示したくなります。その本能は間違いです。あなたはそこに、好奇心を持つために座っているのです。

もうひとつは、Q&A に参加した Atlassian の Sherif Mansour の言葉です。

開発者が同席していない顧客インタビューは、私はやりません。ひらめきの数、そして得られる共感の量が、桁違いなんです。
Sherif Mansour ・ Atlassian

私たちのようなチームにとって、この一文はおそらく今回の研修で最も実行に移しやすいものでした。しかもコストはカレンダーの招待だけです。Jeff が映した Leah Buley の言葉とも響き合います。「デザインとはデザイナーが生み出すプロダクトではなく、デザイナーが場をつくるプロセスである」。ユーザー理解についても同じことが言えます。それは誰かが手渡してくれる成果物ではありません。

彼が繰り返した注意がひとつあります。生の不満をそのままバックログに入れないこと。不満はシグナルであって、要件ではありません。

演習にて

回避策は証拠である

本物の不満を探して Reddit を掘っていたとき、アプリの不便さを回避するために、ユーザー自身がサードパーティのツールを作っていることが分かりました。チームの誰かがその意味を言い当てました。ユーザーが自分で作ってしまったということは、需要はすでに証明されている。推測する必要はない、と。
これは手に入るかぎり最も質の高いシグナルです。困っていない問題のために、わざわざ回避策を作る人はいません。もし私たちのユーザーが表計算に貼り付けたり、別のドキュメントを並行して持っていたりするなら、それは癖ではなく仕様です。

チーム・オブ・チームズ

最後の枠組みであり、Jeff が豚の絵で説明したものです。

ひとつのプロダクトチームは、小さなプロダクトを端から端まで受け持ち、速く動けます。プロダクトが育つと、ひとつのチームの頭に収まらなくなり、それぞれが一部を持つプロダクトエリアチームへ分割することになります。Spotify のスクワッドが有名な例です。

分割したときのリスクには名前があります。Frankenware（フランケンウェア）です。技術的には完成しているのに、まるで一度も会話しなかった4つのグループが組み立てたように感じられるソフトウェア。実際そのとおりだからです。各エリアチームが自分の担当部分を最適化し、継ぎ目を誰も持っていなかったのです。

それをつなぎとめるのは、エリアをまたいだ共通のビジョン・戦略・アーキテクチャ・UX です。さらに Jeff は、しばしばひとつに混同される二種類のリーダーシップをはっきり分けました。プロダクトのリーダーシップは何をなぜやるかを決め、職能のリーダーシップは人と技能を育てます。一人が両方を中途半端に担うのは、よくある失敗です。

持ち帰るとしたら
私たちはまだこれが問題にならない規模です。だからこそ、考えるコストが安いタイミングでもあります。すでにどこに継ぎ目があり、それは誰のものでしょうか。

結局、スクラムは何のためのものだったのか

スクラムは私たちにリズムをくれました。無理な頑張りに頼らず、予測可能に、品質を保って届けるためのリズムです。これは本当に価値があり、手放したいとは思いません。

くれなかったのは羅針盤です。スプリントに入っているものが、そもそも存在すべきかどうかを問う儀式はひとつもありません。スプリントプランニングは、誰が選び誰が使うのかを尋ねません。デイリースクラムは、これがどの事業課題につながるのかを尋ねません。レトロスペクティブが問うのは「どう働いたか」であって、「前回のリリースが誰かの行動を変えたか」ではありません。

Cagan の言う50〜80%は、この隙間に住んでいます。悪いエンジニアリングの話ではありません。検証されていないものに向けられた、良いエンジニアリングの話です。

答えは1986年の論文のなかに、私たちが落としてしまったフェーズとして書かれていました。ディスカバリーとデリバリーは、ひとつのチームのなかで、絶えず重なり合うはずだったのです。

後編：アウトプットを最小に、アウトカムを最大に
事業課題から目標とするアウトカムへどうたどり着くか。アイデアをどう出し、どう捨てるか。2×2 の縦横になぜ「工数」ではなく「リスク」を取るべきか。MVP という言葉が指す三つの別物。そしてディスカバリーとデリバリーを同時に回すと、デイリースクラムに何が起きるか。最終日に私がチャットで投げた、私たちの規模にとって最も重要な質問も含めて。