見出し画像

デザイナーPOが見たスクラム開発

マドレーヌ

はじめまして。B2Bプロダクトのインハウスデザイナーをしているマドレーヌです。今日はスクラム開発に参加したときの葛藤や体験について話します。

0 前提

0.1 書いた人
後のSM、radioc@tさんとの会話の流れでPOになったデザイナー
・インハウスデザイナーとして、B2Bプロダクトのユーザビリティ開発を3年くらいやってる
・フロントエンド開発者と言える水準のコードは書けない
・UMLちょっと書く
・UXちょっとできる

0.2 対象読者
・スクラム開発になんとなく希望を抱くデザイナーの方
・プロダクトオーナーってプロジェクトマネージャーみたいなもん？と思っている方


1 学びながら始めたスクラム開発

1.1 …の前にデザインスプリント
スクラム開発に先行し、デザイナー側で開発前にデザインスプリントを実施しました。HCDとUX方面の教科書を読みつつ、ユーザーインタビューとチームでのプロトタイピングを実践しました。
ここでほぼ全ての画面とUIを作り込んでいたために、後でいろいろ困ることになろうとはその時は考えもしませんでした…
つくったもの：
・ウォーターフォーリーなRFP（その後は全然役に立たなかった）
・ユーザーストーリーマップ
・親和分類法で作った価値マップ
・Figmaの動く画面遷移図

1.2 ストーリーをPBIへ落とし込む
UXDの文脈で「ユーザーストーリー」や「価値」を理解していたので、初期のバックログはそれほど抵抗感なく組み立てられました。
・慣れ親しんだTrelloを使った
・ユーザーストーリーマップからバックログ作るのはスムーズ
・PBIにはFigmaで作った画面遷移図を画像として貼った

1.3 すぐに暗雲が立ち込み初めた
出だしは順調に進みました。が、デザインスプリントで計画的にプロダクトの全貌をデザインしていたがために、すぐ色々な問題が噴出しました。


2 分割？やめてくれ！

スクラムではバックログリファインメントやスプリント計画を通じて、直近でやるPBIを詳細化します。

2.1 ストーリー分割が価値を損ねると思った
デザインスプリントの成果物であるプロトタイプと価値マップは、連続した体験による価値の提供を前提としていました。これとPBIを単位とするスクラム開発の兼ね合いは、夢に出てくるほど頭を悩ませました。
スプリント毎で価値の最大化を試みれば、提供できない別ストーリーが増える
ミニマムな実装を複数組み合わせても、非機能要求でいう使用性が十分に保てない。そのため、価値からトップダウンで想定したUXが提供できたと言えない
UXDでは、カスタマージャーニーマップやユーザーストーリーを手がかりに、つながりのある体験をデザインすることが一般的となっています。

UXDでは、体験の連続性ありきでデザインすることがよくあるため、「依存関係や前後関係はなるべく排除 」を前提とするINVESTの方針は関連するストーリーが片手落ちになって、高次の価値の提供を妨げると当時思っていました。

2.2 せっかく作ったデザインスプリントの成果物が…
今思うと、UIデザイナーとしての成果物が具現化されず無駄になることについての恐れがスクラム開発に抱く違和感の源泉だったのかも知れません。そういった内因的な心の動きもあってか、エンジニアと議論しても着地点は見つかりませんでした。埒が明かないのでいったん有耶無耶にして進めました。

2.3 モーダルな操作体系になってしまった
今度はIAとインタラクションデザインの問題です。

この開発に投入できるリソースには限りがありました：
・社内で初めて扱う言語とプラットフォーム
・全員スクラム初心者
・フェーズ分けされた短納期

これら三重苦により、想定しうる代替ユースケースと補助画面をすべて削り取って最後に残ったのは、ウィザードのような一方向の操作を強要するタスクベースUIでした。
これは、デザイナーとしては許容し難いものだったかもしれません。
しかし、POはプロダクトをまず提供できないと役割が全うできません。

A. デザイナーが満足な操作体系を作っても間に合わないならガラクタ

B. リリース後にプロダクトが好評だったらいつか直せばいいや

上の２つを下記のように解釈して、自分を納得させました。

A”: UIにこだわることで支払う遅延コストは、
    プロダクトを早く提供することよりもリターンが見込めるか？

B”: 事実に基づかない計画や予測を盲信せず、
    実際にデータを集めてから判断したほうがいい（HCDのイメージも混ざってる）

2.4 トップダウンでしかデザインしたことなかった
全体を俯瞰してトップダウンで整合性をもたせるのが、ビジュアルとUIのデザインの素朴なやり方です。対して、ストーリーは個別に提供されます。すこし気を抜くとちぐはぐな画面になりがちです。
ビジュアルとUIの振る舞いに限っては、アトミックデザインを実践するのが最も無難な気がします。コードのリファクタリングのように何スプリントかおきに、UIを整えるのも良いかもしれません。
結局リソースが限られていた当時は、最後に数回だけUI修正を実施することで収まりました。つまり、トップダウンデザインのままです。


3 どうやら皆が通ってきた道らしい

「UX in Scrum」とかで検索すると、アジャイル的な開発とUXD的デザインプロセスの軋轢や苦悩がたくさんヒットします。
ここまで私が感じたモヤモヤに対して、どうやら現時点で銀の弾丸はない模様です。

3.1 まずはお客様感覚から卒業した
ストーリー分割 と遅延コスト の２キーワードを意識することは、デザイナーとしてプロダクトへ関わる姿勢を変えました。
ストーリーの分割から「提供すべき本当の価値はどんなものか？」を自問自答する習慣が身につき、遅延コストを意識することが分割したストーリーへの優先順位づけの動機となりました。このようなマインドセットが出来上がったのは、デザイナーなりにスクラムの価値観を内面化した結果かもしれません。
なんにせよ、今までとは違う視点のシビアさでデザインと向かい合っています。

一方で、細部へこだわりたい気持ちも捨てられません。これをスクラムで適応的に実現するにはどうしたらいいか？

下記をずっと考えてきました：
・POでなくUIデザイナーとしてスクラムに参加する
・開発チームの横で超速でビジュアルデザインする
・デザインシステムを背景にしてすぐ使えるUIコンポーネントを1スプリント先回りして用意する
・なんならプロダクション品質のフロントエンド実装ができる

どれを試すにせよ相当なマッチョさと高いスキルが求められます。いつか挑戦してみたくはありますが…。

少なくとも、POはWhat（業務システムではドメインがその中心）にこだわるべきだし、そうではなくデザイナーとして細部の美しさを実現したいなら、外からゴチャゴチャ言わず開発チームのスピード感で一緒に血と汗にまみれる他ありません。
従来型開発のように、プロダクトの知識が乏しい開発初期段階で絵に描いた餅をエンジニアに渡しても逃げ切れないからです。

我々はプログラムをすべて一度に設計し、仕様書を書き、印刷して、壁越しにプログラマに投げ渡して家に帰る


3 順応する

物事の解決の目処が全くない場合、さっさと逃げてしまうか順応することが私のモットーです。

3.1 まずは教科書通りにやる
上のとおり、実装寄りでないデザイナーがスクラムに参加するとよくモヤるらしい。それならば、そのまま雰囲気で進むと同じ轍を踏むことは明らかです。
自分の直感とは過去の経験に基づく主観なので、まずは意図的に無視して王道を「なねぶ」ことからはじめました：
・方針で迷ったらスクラムガイドに立ち返る
・開発チームと議論になったら吉羽さんに助けてもらう
・スクラムブートキャンプを読む

3.2 ビジュアルにとらわれない工夫をする
作り込みは計画主導の従来型開発だけでなく、伝統的なデザインの美徳でもあります。

作り込みの程度をきちんとハンドリングするため、アジャイル以前のイテレーティブな開発手法、ICONIXのメソッドを拝借しました。ユースケース記述です。
ユースケースは画面に依存せず、画面のプロトタイプと交互に行き来して反復的に定めていきます。プロトタイプを計画的な「画面設計」のように作り込みたがる、デザイナーならではの内なるバイアスの押さえ込みを試みました。
ユースケースを実現するために、取りうる画面遷移を柔軟に考えられるようになって、なぜ「プロトタイプ」であるべきなのか納得できた気がします。

3.3 直近のPBIは粉々に分解する
全員初心者だから、認識齟齬を最小限にしたい。
仕様書然とした小難しい説明書きと綺麗な画面をいくら用意しても、作られないと意味がありません。POはエンジニアをマネジメントしないので、開発チームが納得してやってくれないならストーリーは絵に書いた餅のままです（SMと相談するとかは置いといて）
初めの頃は、価値で切ってもまだPBIが大きく、技術レイヤーでも分割していた気がします。それでも、伝わらないよりマシです。

3.4 ビジュアルデザインをPBIに切り出す
ビジュアルデザインはほとんど直さなかったのですが、（当時はそう自覚してなかったけど）スプリントのボトルネックになる可能性をはらむデュアルトラックを一旦見送り、「UIレビュー」としてビジュアル調整のPBIを足しました。

例：意図と方針だけ明文化し、交渉の余地を残したPBIこのように、UIデザインに当然含まれるビジュアルデザインをデザインプロセスから分離することで見えてきたことがあります。

ギャレットの有名なUXの5段階モデルとPOのデザイン範囲を対応させてみましょう：

・墨の文字が私の体感したデザインにおけるPOの責務です、ビジュアルに先立ってデザイナーが考えるべきことがやはりある。
・ビジュアルより上のレイヤーのデザインがしっかりしていれば、従来型開発でなければビジュアルを後から変えることに気負いがなくなる。
・ストーリーポイントが付くからには、デザインは無料じゃない。結局すべてはデザイナーとエンジニアが時間と労力をかけて実現する。

4 振り返って

4.1 デザインスプリントの進め方
デザインスプリントでは、従来型開発のデザイン版の的な進め方をしてしまいました。計画的で詳細なデザインと「要求の在庫」を作りすぎないスクラムの価値観はぶつかります。今ならデュアルトラックを採用し１スプリント先読みでインクリメンタルにUXDを実施すると思います。
ビジュアルデザインも求めるなら、POとは別に開発チームにUIデザイナーを入れ、正当なリソースとして開発の見積に算入すべきです。デザインは無料じゃないので、放っておいても開発チームとPOの忖度でいい感じになることは有り得えません¯\_(ツ)_/¯

4.2 価値の粒度
価値マップを作るときに粒度に注意を払うべきでした。親和分類法をモノにしたくてなんとしてでも高次の価値を導出しようと躍起になっていた気がします。
下記のような方針が良いかも知れません：
・高次の価値が必ずしも一発で提供できないことを認める
・KJ方で見つけたハイレベルの価値より、個別の価値を吟味する

4.3 唯一神のようなペルソナをやめる
B2Cでのユーザーは、業務上で定められた役割を演じます。PBIを書いているうちに、概念化されすぎたペルソナは断定的すぎると思い始めました。これはユーザー調査を十分に行っても同じになりそうです。なぜなら、定められた役割を演じるユーザーは、それぞれ別々のバウンダリを通じてアプリと対峙しているからです。
アクターを使ったほうが調子が良さそうに感じています：
・ユースケースとドメインモデルに登場するアクターを、ストーリーに出す
・コンテキスト図を使い、どのアクターがどこまでのドメインに関わっているか明らかにする
・アクターにペルソナ的な肉付けをする

4.4 受入の基準
ユースケースのシナリオを、そのまま受入の基準にするのが調子良いと思っています。これは、認定スクラムプロダクトオーナーの研修で得たアイデアです。
・事後条件と前提を簡素に明文化できる
・システム要求の説明のような長い文章を書くよりずっといい
・ユースケースに現れない要求は普通に受入の基準に書けばいい

POとしての観点を明確にでき、かつ具体的な機能の実現方法に干渉せず済みます。事後条件と前提を書くことを強制することで、考慮漏れがある程度抑えられます。

5 終わりに

ここでは話題をPOと開発チーム、デザインに絞っています。実際は、ステークホルダーや従来型開発を前提とした他部門との調整など、難題が山積みでした。
こういうのかける機会があればまた！