デザイナーとしてスクラムチームにどっぷり浸った３年間を振り返る
こんにちは。atama plusというAI×教育のスタートアップでUXリサーチャー・UXデザイナーをしている野澤です。
１年ほど前に「アジャイル開発×UXデザイン」という切り口でLean UXについてnoteを書きました。嬉しいことに、このnoteは多くの方に読んでいただいて、読者の方から質問もいただきました。
自分自身がアジャイル開発を学ぶ中で、PdM/デザイナーが参加するアジャイル開発を実践するポイントとその難しさについてはまだまだ記事が少ないと感じています。
Lean UXのnoteではデザイナーとしてMVPを設計することの難しさ・大切さを主に書きました。私が記事を執筆してから１年間スクラムによるアジャイル開発を実践したことで、当時からさらに解像度を上げることができました。atama plusに入ってスクラムを実践し始めてからは3年がたったことになります。
そこで、デザイナーとして3年間スクラムによるアジャイル開発を実践して学んだことのまとめとして「デザイナーとしてスクラムを実践するということは、エンジニア・QAとチームを組んで役割を超える連携プレーで開発をすること。このスタイルはデザイナーにとってめっちゃ開発しやすい！この開発スタイルはサッカーをプレーすることに例えると捉えやすい」ということをお伝えしたいです。
対象とする読者の方
・すでにスクラムでアジャイル開発を実践されているPdM/デザイナーの方
※atama plusのUXデザイナーはPdMのロールとオーバーラップすることが多いため、PdM/デザイナーの方に向けて書きます。
アジャイル開発とは
認識を揃えるために、アジャイル開発を私がどう捉えているかごく簡単に紹介します。アジャイル（Agile)は英語で「素早い、機敏な」という意味です。
「小さく繰り返す」というイメージを既にお持ちの方も多いと思いますが、「要件定義→設計→開発→テスト」という開発工程を小さいサイクルで反復する（イテレーションを回す）ことが特徴です。
これに対してウォーターフォールは「要件定義→設計→開発→テスト」の工程をそれぞれ一度だけという大きなサイクルで開発を行います。
LeanUXのnoteでも触れましたが、アジャイル開発はリリースしてその反応を学びながらプロダクトを開発していけることと、要件定義からリリースまでのサイクルが短いことから変化・リスクに強いというメリットがあります。
入社前、私はウォーターフォールでの開発を約8年経験してきました。atama plusに入ってから、スクラムという手法でアジャイル開発を実践し始め、約3年間経験しました。アジャイル開発の考え方が大好きで、今後もアジャイル開発を続けるつもりです。
一方で、アジャイル開発を実践することにはウォーターフォールとは別の難しさがあると感じました。
これについて、ウォーターフォールをリレー、アジャイル開発のスクラムをサッカーという例えを使って詳細を説明します。
ウォーターフォールをリレーと捉える
ウォーターフォールはリレーだと思うようになったのは、私がatama plusに入社してスクラムに挑戦し始めたばかりの頃、スクラムイベントでチーム活動に貢献できていないと感じていた時期があったからです。
例えば、スクラムではスプリントの最後に「レトロスペクティブ」というチームでの振り返りを行うのですが、当時の私が出す意見は「◯◯なことがあって反省しました」のような自分個人の振り返りに閉じたものばかりだったのに対し、同じチームのエンジニアさんは「今スプリントに◯◯ということがあったけど、チームとしてこれってどうなんだろ？みんなどう思う？」とチーム全体を見て考えていることに自分との視座の違いを感じ、大きな衝撃を受けました。
atama plusではデザイナー・Dev・QAがすべてのスクラムイベントを一緒に行っているのですが、活躍されている方は他の職種の方のパートにも適切なコメントをしていたのに対し、私は集中して聞くのも難しいほどで落ち込む日々でした。
この要因についてスクラムマスターに相談したり、「なぜだろう？」と周囲を観察しながら考えた結果、私が長年やってきたウォーターフォールとスクラムはそもそもスポーツでいえば競技が異なるため大事なことも大きく違うのだと考えるようになりました。
私が考えたのは、ウォーターフォールという開発手法はリレーに似ているということです。スタート地点からゴールに向かって、各選手が自分の領域を走り、次の選手にバトン（ドキュメント）を渡します。
リレーの特徴
最終ゴールはスタート時に決まっている
スタートとゴールの間には既にコースが引かれている
選手は決まったコースを全力で一人で走る
決まった地点でバトンを受け渡す
リレーでは、一度バトンを受け取ったら相手に戻してはいけない
リレーで勝つために大切なのは、相手がバトンを受け取りやすいように渡す技術だと言われています。リレーでは転んだり失敗をしてはいけません。そのリカバリは基本的には自分でする必要があります。
そして前の人が遅い、もしくは転んだ場合にチームとして勝つためには後ろの人がより速く走る必要があります。
この特徴はウォーターフォールによく似ていると思います。少なくとも私が関わっていたウォーターフォールの開発では、最初に今回の開発で最終的に実現したいこと（ゴール）を決め、デザイナーが要件やワイヤーフレームを１人でドキュメントにまとめ、そのドキュメント（バトン）をエンジニアに受け渡します。
エンジニアはデザイナーが決めたとおりに実装を行います。その間には明確な役割分担があり、デザイナーのドキュメントにはエンジニアから質問やツッコミが入らなければ入らない（バトンが戻されないように、ドキュメントをまとめる）ほどよいとされます。
デザイナーが要件定義している間にエンジニアとコミュニケーションする機会はドキュメント（バトン）の受け渡しのときくらいで、エンジニアにドキュメントを渡す前にデザイナーに自分で確認して欲しいことのチェックリストがあったりと、デザイナーが１人で要件定義やワイヤーをしっかりとドキュメントだけで理解できるようにまとめることが求められていると思います。
ウォーターフォールの実際とモヤモヤ
最初私はリレーは個人競技だと考えていましたが、実はリレーも団体競技と考えられています。思い返してみれば、ウォーターフォールでも前工程や後工程のチームメンバーやパートナーの方がいらっしゃり、よく助けていただき、チームとして働いていました。
私がatama plusに入る前にウォーターフォールで開発をしていたときは多くのチームメンバー・パートナーに助けていただきましたが、特に後工程となるエンジニア・QAメンバーの「ハートの強さ」が印象的でした。
リレーに似て、ウォーターフォールのプロジェクトではリリース日が動かせないような場合、前工程の遅延・考慮漏れを後工程の人が巻き取ることが多くあります。
また顧客から「動く形になったら思ってたのと違った」とFBが来た場合、エンジニアの方にお願いして実物を見ながら直していただくこともあり、それでもチームの後工程の方には「仕方ない！」と引き受けていただけることが多く本当にありがたかったです。
一方でそういう状況に、モヤモヤすることも多くありました。
バトンの受け渡しとなるレビューのタイミングでのやりとりには、前工程と後工程という距離感がありましたし、どれだけ関係が良くても、自分の工程を仕上げるのは自分一人の責任だと思っていました。
手戻りが発生したら申し訳ない気持ちになり、考え直すのも自分一人で行うものだと考えていました。もちろんエンジニアのメンバーに相談する機会もありましたが、機会は限られていました。
そして、一度エンジニアへバトンを渡したあとはどれだけ大変でも私は手伝えることがないことにも寂しさを感じていました。
スクラムによるアジャイル開発をサッカーと捉える
前置きが長くなりましたが、PdM/デザイナーとして、ウォーターフォールをリレーと捉えたときに、スクラムによるアジャイル開発はエンジニア・QAとの役割を越えた連携プレー、つまりサッカーチームを組んでいると捉えると開発効率が上がり、PdM/デザイナー自身の幸福度も上がるのではないかと考えています。
様々な方が読んでくださることを想定して、まずスクラムのおさらいをしたいと思います。スクラムはアジャイル開発を実現するためのフレームワークの１つです。
2020年版のスクラム公式ガイドでは、スクラムはスプリントでの４つのイベント（プランニング、デイリー、レビュー、レトロスペクティブ）と３つのロール（プロダクトオーナー、開発者、スクラムマスター）を定義しています。
イベントとロールについての説明は公式ガイドを見ていただければと思いますが、スクラムが機能するための３本の柱として「透明性」、「検査」、「適応」という概念を挙げています。それぞれざっくりと、以下に説明します。
透明性
他の人から見て誰が何をしてるか分かる状態と捉えていただければと思います。
検査
ゴールに向けて上手く行っているかのチェックです。
適応
うまくいっていないことを改善する、検査で学んだことを活かすことです
こう説明すると「抽象的で難しそう」と思われる方もいらっしゃるかもしれません。私も最初はコツがつかめませんでした。ですが、「私は今サッカーをしているのだ」と考えるようになってから、一気にうまく動けるようになりました。
一言で言えば、サッカーをプレイするためには、コートのどこに誰がいるか観察して（透明性がある）、今どういう状況なのかを読み（検査する）、チームとして勝つために必要ならば役割から染み出して今一番必要な行動を取る（適応する）ことだと考えています。
あらかじめ決められたルートを一人で全力で走り切るリレーと違い、サッカーでは試合の戦略・戦術はありながらも、勝利（アウトカム）にむけて常にお互いの様子を見ながら柔軟性を持って動きます。
スクラムの難しさとは
スクラムの難しさもサッカーで説明すると分かりやすいと思います。自分のやることやバトンパスのタイミングが明確なリレーと比較すると、サッカーでは試合中に取れる動きの自由度が高くチームメンバーとの高度な連携プレーも多くなります。
試合の間も状況が変わって、予期せぬ出来事が起きる、相手が変えてきた戦術（ビジネス状況の変化、競合の出現）へ対応が求められるなど、試合の流れを読んで打ち手を打つ力も求められます。
私はキャリアの初期にウォーターフォール開発で定評のある会社で経験を積ませていただいたのですが、そこで学んだのはウォーターフォールのPdM/デザイナーとして大切なのは、前工程として自分の役割を一人で完璧に全うして、最後に相手にバトンをしっかり渡すということです。
一方、私がatama plusでスクラムを3年間実践して学んだのは、PdM/デザイナーはエンジニアやQAといったチームメンバーの動きを常に見ながら、チームの状況の変化を察知し、密に互いに協力しあうことが大切だということです。必要と思えば自分の役割から染み出すこともあります。
リレーに比べると複雑な連携プレーのスキルが必要なため、スクラムを始めたばかりのときはこのギャップに戸惑い、マインドセットを変えるのにかなり苦労しました。
サッカー選手のように協力し合うatama plusのスクラムチーム
今までお話させていただいたようにスクラムチームで大切なのは、サッカー選手のように役割から染み出して協力し合うということだと私は考えています。atama plusのスクラムチームはPdM/デザイナー、エンジニア、QAで構成されていますが、まるで１つのサッカーチームのように役割から染み出して互いに協力し合いながらスプリントを回しています。
スクラムイベントも１チームとして全て一緒に出ていて、私もエンジニア・QAのメンバーの状況は常に見るようにしていますが、エンジニア・QAのメンバーもPdM/デザイナーの状況をよく見てくれていて、思わず「神！」と叫びたくなるほどのタイミングで、提案を投げかけたり、助けに来てくれます。
PdM/デザイナーとエンジニア、QAの間で感謝をし合うことが多く、感謝のニュアンスを伝えるためのSlackのスタンプもバリエーションが多く作られています。
具体的なatama plusのスクラムチームの動き方
チームとしての成果を最大化するため、エンジニア・QAのメンバーがPdM/デザイナーを積極的にサポートしてくれるので本当に助かっています。
例えば、より早くより良いプロダクトを作るために要件定義フェーズからエンジニア・QAが参加し、技術的・品質観点から一緒に要件を固めてくれたり、UXリサーチにもエンジニア・QAが積極的に同行してくれたりします。
デザイン段階の中でもイテレーションを繰り返すのは当たり前で、実装の手前でエンジニアやQAと一緒にいろんな視点から仕様の確実性を上げていけます。
さらに実装に入ってからも「こういう仕様の方がいいかも？」となれば、そこでメンバーで話し合いながら改善していけます（同じチームとして常に背景が共有され続けているため、目指すユーザー体験像の認識も揃っていて非常にやりやすいです）。
QAはPdM/デザイナーが多くの案件にリソースを避けるように、案件の詳細なケース出しをリードしてくれたり、実装するものの細かい要件についてエンジニアとの認識合わせもリードしてくれたりします。
PdM/デザイナーがエンジニアやQAに指示を出し、お願いして回るというより、チームとしてスプリントで達成すべきことを達成できるように、全メンバーがお互いの動きをよく見ていて、役割に軸足をおきつつも囚われすぎずに「これは自分がやったほうが良い」と考えたことを自らやるという感じです。
デザイナーだからここまでしかやらない、エンジニア・QAだからここまでしかやらないという考え方ではなく、お互いに染み出して協力しあいます。
LeanUXのnoteを書いたときにもこのような動きはあったのですが、このような役割を染み出して協力し合う動きは「アジャイルテスティング」という考え方の導入で大きく加速しました。
役割の染み出しを推進するアジャイルテスティングの考え方を導入
以前から、atama plusのスクラムチームにはQAも入っていくれていたのですが、関わり方はデザイナー・エンジニアからは少し遠く、要件が固まったら開発内容を把握し、最後にまとめてテストする事が多く、「テストして品質担保するのはQAの責任」とテストはQAにバトンを渡す形になりがちで、後工程となってしまったためにテストが終わらないということもありました。
アジャイルテスティングとはQAが品質を担保するという考え方とは異なり、「プロダクトの品質はチーム全員の責任」という考え方です。QAが欠陥を見つけてくれる番人と考えるのではなく、チーム全員で欠陥を防ぐことを学ぼうという考え方になります。
この考え方がチームに導入されてからは、チーム一丸となってのプロダクト開発の動きがますます強まりました。
要件定義段階でのバグの作り込みを防ぐために、今まで以上にQAが要件定義の議論に参加する動きが増えました。また「ふるまい」の考え方を導入したことで（後述）、デザイナー・エンジニア・QAで仕様の認識を合わせるところもQAにサポートいただくことも増えました。
そのおかげで、チーム内のコミュニケーションは今まで以上に円滑になり、開発のスピードを上げながらプロダクト開発の品質も上げていくことが出来ました。
実際に不具合修正のタスクも大幅に減少しています。
「ふるまい」を書くとは
BDD（ふるまい駆動開発）と呼ばれる開発手法の一部で、以下のようなフォーマットでユーザーストーリーを具体的に表現します。
このようにQAのリードでふるまいを書いてチームで認識を合わせるようになってから、PdM／デザイナーからエンジニア・QAに仕様をただのテキストで伝えていたときよりも、認識のずれが減りました。
また、実例を使って話すことにより、不明瞭だった点を洗い出して議論の土台に乗せることができるのはとてもありがたいです。
例えば、atama＋のプロダクトではユーザーと一口に言っても、atama＋社員、教室長、講師、高校生、中学生などさまざまなユーザーが存在します。「ユーザー」という概念を「ふるまい」で実例を記載しようとすると、どのユーザーを対象にしているかが不明瞭だったことに気付けるため、とても助かっています。
役割から染み出して必要なことは何でもやるマインドセットの加速
アジャイルテスティングの導入によって品質はチーム全員で担保するものというマインドセットがそれまで以上に加速し、QAが１人でやっていたテスト工程の設計・実行も、テストがスプリント内に終わらなそうであれば、PdM/デザイナーも一緒にテストをするようになりました。
チーム一丸となってスプリントを回す動きが増え、実装まではしたもののスプリント内にテストが終わらないということも減っていきました。
エンジニア・QAと常にお互いの様子を見ながら助け合ってスプリントを回しているため、PdM/デザイナーもプロダクト開発でそのとき一番大切だと思うことによりフォーカス出来るようになりました。
アジャイルテスティングの詳細はatama plusのエンジニア・QAのメンバーもまとめてくれていますので、よろしければそちらの資料もご覧ください。
チームとして強くなるためにatama plusがしていること
読書会をしてチームで大切なことの目線を合わせる
atama plusのスクラムチームが協力して動くことが出来るのは、チームとして大切なことを目線合わせするための読書会の力も大きいと思います。LeanUXのnoteでも読書会の効能ややり方を書きましたが、読書会としてチームで１つの本を読むことでプロダクト開発で大切なことについての認識を全員で揃えることができます。
atama plusでは、LeanUXやスクラムガイドは読書会を続けるうちに読書会として本を読まなくても実践できるようになってきたため、現在はアジャイルテスティングの読書会を定期的に開催しています。
私もアジャイルテスティングの読書会を通じて、「プロダクト開発はテストも含めチーム全員で行うもの」という思いを強めることができました。
その他にもチームとして強くなるために職種横断で様々な読書会をしています。もしよければ読書会についての記事もご覧ください。
振り返りを重ねてチームとして強くなる
スクラムにはレトロスペクティブというスプリントの振り返りのイベントがありますが、サッカーチームの試合後の反省会に近いなと思います。振り返りについても効果的に行えるように各チーム工夫を重ねています。チームで工夫していることも記事にまとめていますので、よろしければそちらもご覧ください。
まとめ
この記事では、スクラムで大切なのはサッカー選手のように役割に軸足を起きつつも染み出してチーム一丸となって連携して動くことではないかということを、atama plusのPdM/デザイナー・エンジニア・QAのメンバーの動きも交えてご紹介させていただきました。
スクラムの難しさもご紹介しましたが、3年やってもスクラムって本当に面白いなと飽きることがありません。
スクラムで開発するPdM/デザイナーと開発チームの動き方について模索されている方にとって、この記事が開発のためのポイント・面白さについて、少しでもお役に立つことができたら幸いです。
ご参考
ちなみに、スクラムという言葉自体が、ラグビーのスクラムから来ています。サッカーとラグビーはどちらもルーツがフットボールと言われているので、スクラムをサッカーと捉えるのは遠くない例えではないかなと考えています。
またスクラムに影響を与えた野中郁次郎先生も担当チームがバトンを渡すように進む開発スタイルをリレーと仰っていたので、よければ合わせてご覧いただければ幸いです。
いただいたサポートは、日本のデザインリサーチャー・UXリサーチャーの実践に役立つ活動に使わせていただきます。