4d Process Model Version 1.0
2019.4 菊地玄摩
4d Process Model の背景と目的
4d Process Model は、ひとつのプロダクトが着想され、形を与えられて世に出るまでに辿るプロセスのモデルを提供する。
現実のプロダクト開発の進行プロセスは複雑で、不可視的で、予測や計画になじまない現象である。個別の状況を把握してその時点での最善の判断を行い、実行に移すことの繰り返しが、開発プロジェクトの実践であるといえる。認知、判断、実践は、1 回きり、ひとりきりで行うのであれば、個人の直感と努力によって適切なものにすることはできる。しかし、5 人、10 人と関係者がおり、10 回、20 回と繰り返すときには、その複雑さ、考慮すべき条件の多様さに個人的に対処することは難しい。
4d Process Model は、プロジェクトチームの認知と共通理解の基盤として機能することで、開発プロジェクトの進行プロセス、個人の取り組み、各種の手法の適用効果などを検証可能にすることを意図している。特に、不可視的であるために認知することが難しい中間的な成果の存在や、ひとつの現象の複数の側面、それを生み出す特別なスキルや実践の存在を明らかにし、その関係性を明確にすることで、チームが共有する認知を助けることを目指している。
また複数のプロジェクトを横断して評価、研究を行うための道具立てを行うことも、意図している。
フェーズ
4d Process Model では、プロダクト開発を以下の 4 つのフェーズ (段階) に分割して表現する (図1) 。
図1discover (d1)
成立条件や背景についてリサーチを行い、目的 (プロダクトのドメイン) を明確にするフェーズ
define (d2)
場面とエピソードを具体化し、ユーザの心の動きのリアリティある仮説 (プロダクトが実現するゴール) をつくるフェーズ
develop (d3)
エピソードに対応するプロダクトの振る舞いやユーザのアクションを実現 (プロダクトとして形にする) するフェーズ
deliver (d4)
プロダクトの振る舞いを整え、目的に沿うようチューニングを行ってリリース (プロダクトの振る舞いを最適化) するフェーズ
Diverge と Converge
4d Process Model では、成果を得るための働きを 2 つ定義する。成果を直接生み出すためのすべての活動は、Diverge または Converge のいずれかに分類される。
Diverge は思考の範囲を拡大する動きであるため「広げる」イメージを、Converge は検討の結果をひとつの点に結晶化する動きであるため「閉じる」イメージを、それぞれダブルダイヤモンドの表現から借用して表現している (図 1) 。
Diverge
実現可否にかかわらず、可能性の範囲を把握するために探索する動きを Diverge と呼ぶ。
例- 複数のプロダクト名の候補を挙げる
- 複数の UI のデザイン候補を挙げる
- 複数の設計方法の候補を挙げる
Converge
探索した可能性から、内容を絞り込む動きを Converge と呼ぶ
例- 複数候補の中からひとつのプロダクト名を選ぶ
- UI デザイン候補から採用するデザインを選ぶ
- 設計方法を選ぶ
discover (d1) フェーズの取り組み
命名、キャッチコピーや概要の記述によって、ユーザに提供する根源的な価値の明確化を行う。広い範囲から、プロダクトの立ち位置を探索し、発見する (discover) フェーズ。
Diverge
ユーザの暮らしの研究、競合の分析など、ドメインの周辺のリサーチ
Converge
根源的な価値と、それを象徴する記述や命名の提示
define (d2) フェーズの取り組み
ユーザシナリオ、ペルソナの記述、ラフなプロトタイプの制作によって、ユーザとプロダクトの振るまいの典型例 (プロトタイプ) を提示する。プロダクトが実現したい価値のために目指す、具体的な目標を定める (define) フェーズ。
Diverge
ペルソナを描くためのリサーチ、シナリオや仮の構造による場面検証
Converge
ユーザとプロダクトの振るまいの典型例 (プロトタイプ) の提示
develop (d3) フェーズの取り組み
ユーザーのアクションとプロダクトのもつ機能を実際に作り、プロダクトの基本的な動作を実現する。目標に到達するための具体的な方法を見つけ、作り出す (develop) フェーズ。
Diverge
具体的な設計・デザインの検討、MVPs の妥当性検討
Converge
動作するプロダクトの提示
deliver (d4) フェーズの取り組み
現実のリリース条件への適合やテスト結果に対する調整を行い、プロダクトの詳細な動作を最適化する。ユーザが実際にプロダクトの価値を経験するために必要なことを実践する (deliver) フェーズ。
Diverge
フィードバックの収集、エッジケースのリサーチ、テストと修正の実施
Converge
チューニングとリリース
成果モデル
フェーズごとのアウトプットの関係を、成果モデルとして同心円状に表現する (図 2) 。一般に、円の中心が定められることによってプロダクトの価値が明確になり、輪郭 (外側の円の範囲) が定められることによって、プロダクトとしての振る舞いが明確になる。図 1 の Output の行にその変化を示す。
図2Domain
プロダクト全体の中心となる価値。(d1 フェーズの成果)
広い現実世界のどこにプロダクトが存在するかの定義、または実現として機能する。
ドメインがわずかでも移動すれば、ゴール以下すべての再調整が必要になる。
Goal
プロダクトのドメインが現実化するための具体的な目標。(d2 フェーズの成果)
誰が、どんな場面でその価値を享受するかについての定義、または実現として機能する。
同じドメインでも、異なる目標を設定し得るため、プロダクト以下すべてを規定する。
Product
プロダクトが一般的に持つ機能、基本構造。(d3 フェーズの成果)
プロダクトの持つ機能と、その機能によってユーザがどんなアクションを行うかについての定義、または実現として機能する。
同じゴールに向けても、複数の設計、デザインが可能。
プロダクトが可能なビヘイビアを規定する。
Behavior
エッジケースを含めた、プロダクトの具体的な振る舞い。(d4 フェーズの成果)
プロダクトの現実の姿、輪郭の定義、または実現に対応する。
現実に、具体的に存在するプロダクトの姿と同義。
Double Diamond との共通点について
4d Process Model は、デザインのプロセスを説明するために英国デザインカウンシルが提唱した「ダブルダイヤモンド」を解釈し、変更を加えたものである (The Design Process: What is the Double Diamond? | Design Council)
特に、Diverge と Converge については、ダブルダイヤモンドからそのまま拝借している重要な概念になる。Problem から発して Solution に至る構造と、先行するフェーズが仮説を与えることで、続くフェーズが成果を出せるという前後関係も同様である。これらの点は、問題解決の一般的なプロセスとして有用であると考えている。
ただし、ダブルダイヤモンドは「デザイン=設計」を行うところまでを対象としている。4d Process Model が対象とする「プロダクト開発」はより広範な作業を対象とするため、変更を加える必要がある。特に Develop (d3) と Deliver (d4) については大幅に拡大解釈して、Develop はソフトウェア等の実装、Deliver はプロダクトの実際の振る舞いを取り込む形にしている。
4d Process Model は、この操作によって、「デザイン」が問題解決をするために持っている思考パターンを、ソフトウェア開発等に適用しようとするものと言える。
2018 年版からの改訂について
新しく Define にも Diverge と Converge が存在するという説 (Reduce risk/cost by fusing Design Sprints and the Double Diamond process)) を取り入れた。結果として、d2 は独立した Diverge - Converge の過程を持つことになり、「ダイヤモンド」が 3 つになった。また、ダブルダイヤモンドでは Problem をスタートと位置づけているが、Problem の明確化そのものが創造的で、Diverge と Converge なしには成り立たないプロセスの一部である (Problem が明確でなければプロダクト開発に着手できないモデルは脆弱である) という考えのもと、Discover のプロセスにも Diverge - Converge の過程を取り入れた。都合、「ダイヤモンド」は 4 つになった。結果的に、Discover 、Define 、Develop 、Deliver がそれぞれ可能性の探索と、結晶化を行うという独立性が強調されることになったが、これは妥当と考えている。フェーズごとに成果があり、結晶化した中間成果を生むためには Diverge - Converge が必要である、と考えれば自然な表現である。ダブルダイヤモンドはフェーズ数と中間成果の数の不一致が矛盾になっている可能性がある。
また d1 の Output を Motivation から Domain にあらためている。これは、Motivation は成果とは言えないため。Motivation の位置づけを明確にする成果として Domain を再設定した。また d4 の Output を Product から Behavior にあたらめている。これは、フェーズごとの成果を強調し、ダイヤモンドが増える過程で、Deliver の成果を明確化するために行った。Product の一般化された機能や振る舞い (Product) と、具体的で個別的な動作 (Behavior) を区別するためにも良い変更と考えている。