デザイナーのPivotal Labs体験記②：開発プロセス

こんにちは。富士通デザインの吉川です。

アジャイル開発のハンズオンレクチャーを行うPivotal Labsでの学びをまとめています。

今回は開発プロセスについて紹介します。

実はプロジェクトに参画することが決まった時点では、Pivotal Labsでどんなことが行われているのかほとんど知りませんでした。しかし実際にジョインしてみると、リーンスタートアッププロセスを実践するチームとして理想的であることがよくわかりました。

そのプロセスを紹介することで、私自身の学びの整理と、今後Pivotal Labsに行かれる方の参考になればと思います。

本記事は私が関わったプロジェクト事例を個人的に整理したものです。
Pivotal Labsの公式なものではありません。

プロジェクト概要

まずは私たちのプロジェクト概要です。

・業種：金融(BtoB)
・内容：新規事業(プラットフォーム)の立ち上げ。0→1。
・フェーズ：お客様で具体的な事業仮説を持っており、ビジネスとして成立する手応えをある程度掴んでいる状況。

今回のプロジェクトが特徴的だったのは、お客様自身で世界中のターゲットユーザーに対し仮説提案を行なっていたところです。

アイデア段階での提案も含め、その回数なんと200回以上！
しかも簡易なモックアップも制作されており、操作体験をともなったインタビューをされていました。

その反応から「これはいけるんじゃないか」という実感を得て、本格的なプロトタイプ開発が決定されました。そしてその手段としてアジャイル開発を採用されました。

プロダクト概要を聞いたとき、素人の私からみても大変価値があり、業界を前進させるプロダクトだと思えるものでした。

ちなみにプロジェクトの発起人で、イントレプレナーでもある方の話しでは「20の事業アイデアがあったとしても、この段階まで進むのは1、2個程度」という話です。

Pivotal Labsでの開発プロセス

さて、Pivotal Labsでプロジェクトを進めていると、主に2つのサイクルを同時に進めていることに気がつきました。ここではそれぞれ以下の呼び方とします。

仮説検証サイクル

リーンスタートアッププロセスを実践するサイクル。プロジェクトが成功するための条件、または失敗に導く可能性の高いリスクを洗い出し、それらを検証していきます。

アジャイル開発サイクル

Extreme Programing(XP)と呼ばれる開発手法でソフトウェアを開発するサイクル。XPには全員同席、ペアプログラミング、インクリメンタル設計、テスト駆動開発…といった特徴があります。

※プロジェクト開始時のワーク（プロダクトビジョン策定、ユーザーストーリーマッピングなど）は省略しています。

以下それぞれ説明します。

仮説検証サイクル

1.ペルソナ設定

ターゲットユーザーを明確化します。Fact, Behavior, Needs&Goalの側面から記述します。名前をつけ簡単なイラストも添えます。ここでつけた名前は以降のフェーズでガンガン使われます。

2.リサーチ計画の立案

今回のリサーチにおいて検証したい仮説や、検証するための方法を考えます。Assumptionと呼ばれる「検証されてはいないが、正しいと思っている仮説、または思い込み」を言語化し、優先度をつけて検討します。

3.シナリオ設定

ペルソナがどのように対象サービスを使っているかを記載します。

4.プロトタイピング

シナリオ上必要となるであろうUIを作成します。Figmaなどのプロトタイピングツールを使います。リサーチに必要な部分のみ作成し、それ以外は作成しません。適宜PdMやDeveloperと確認しながら制作し、大きな手戻りがないように進めます。

5.スクリプト作成

ユーザーリサーチ（インタビュー）で使う、トークスクリプトを作ります。

6.リサーチ実施

スクリプトに沿ってユーザーリサーチ（インタビュー）を行います。

7.シンセサイズ（仮説検証）

リサーチ結果をまとめ、当初の仮説は正しかったのか、新しいインサイトやニーズは発見できたかなど整理します。分析結果から次のアクションアイテムを導きます。
図ではその後ペルソナ策定に進んでますが、実際は個々の検証結果に応じて異なるステップに進みます。完全なループではありません。

アジャイル開発サイクル

プロダクトの開発（プログラミング）はDeveloperが行いますが、Designer視点だとざっくり以下の流れになります。

1.ストーリーの作成

ストーリーとは断片化されたユーザーの要求事項のことで、誤解を恐れず言うとDeveloperへの依頼事項となります。システムの仕様に関わるストーリーはPdMが記述し、デザイン（スタイルやアニメーションなど）に関わるストーリーはDesignerが記述します。なおアジャイル開発では「要件」という言葉は使いません。

2.開発

Developerがストーリーにそって開発します。テスト駆動開発（TDD）と呼ばれる方法で開発していますが、細かいところまではDesignerは関与しません。いろいろなポイントがありますがいったんここでは省略します。

3.ストーリーのアクセプト

開発されたストーリーが当初の意図を満たしているかを確認します。ビルドを確認しOKであればアクセプトし完了します。ここでも機能に関するストーリーはPdMが確認し、デザインに関するストーリーはDesignerが確認します。

仮説検証サイクルからアジャイル開発サイクルへのジャンプ

２つのサイクルがあると話しましたが、仮説検証サイクルからアジャイル開発サイクルに行くための基準はなにでしょうか。この点についてPivotal Labsではシンプルに、

チームが「自信がある」と判断したもの

としています。リサーチの結果、ほぼ全てのユーザーが問題なく操作できたり、彼らの業務に沿っていることが確認できたものは「自信があるもの」になります。

自信と書くと「感覚的だ」「定量的でない」と思われるかもしれませんが、私はとても「うまいな」と思いました。

ものづくりの現場では、全てを論理的、定量的に判断することは難しい局面があります。例えば、ユーザーの5人中1人しか指摘しなかったコメントがとても的を得ており、全ユーザーにとって有益であると考えられる場合はストーリーに組み込むことがあります。

反対に全員が「良いと思う」と言った場合でも、ふに落ちないのであればさらに検証を続けることができます。

チームで議論して決める余地があるほうが、柔軟な判断ができると思います。

まとめ

仮説検証サイクルは学びのプロセスとも言えます。自分たちが想定していたことが正しかったのか、誤りだったのか明確に知ることができます。仮説が誤っていたとしても凹む必要はありません。正しい結果が分かることがなによりの成果です。

仮説検証サイクルを回すことで、チームは「正しいものを作っている」という自信が得られます。その結果プロジェクトがさらにユーザー中心になり、より良いユーザー体験をもたらすプロダクトを開発することができます。

アジャイル開発サイクルは、Developerとのコラボレーションのプロセスです。彼らが作業しやすいよう、自分たちのデザインを簡潔でわかりやすいストーリーに落とし込みましょう。
また開発するものがユーザーにとってどんな価値があるのか丁寧に伝えましょう。そしてDeveloperからのアイデアやフィードバックを真摯に受け止め、プロダクトに取り込みましょう。