アイスリーデザインが考える「プロジェクトをデザイン」する重要性

こんにちは。
アイスリーデザインプロジェクトデザイン部マネージャーの平です。
私たちアイスリーデザインは、総合デジタルプロデュース企業として、ソフトウェアのUI/UXデザインおよび開発を中心にサービス展開をしておりますが、2023年に「プロジェクトデザイン」に特化した部門（プロジェクトデザイン部）を設立しました。ソフトウェア開発において「プロジェクトマネジメント」は聞き慣れていても「プロジェクトデザイン」はあまり聞き慣れない方も多いのではないでしょうか。
本記事では、アイスリーデザインにおけるプロジェクトデザインの定義と、その重要性、具体的な実施プロセスについて説明します。

1 はじめに
- 1.1 改めて「プロジェクト」とは？
- 1.2 「プロジェクトマネジメント」とは？
2 「プロジェクトをデザインする」とは？
- 2.1 プロジェクトデザインが重要となった背景
- 2.2 アイスリーデザインが「プロジェクトをデザイン」できる理由
3 不確実性がある中で「行き先を定める」プロセス
- 3.1 プロジェクトデザインに必要な3つの要素
- 3.2 具体的な実施プロセスの一例
4 おわりに
- 4.1 すべては成果の実現のために

はじめに

改めて「プロジェクト」とは？

プロジェクトデザインについて説明をする前に改めて「プロジェクト」の定義について確認をしたいと思います。

米国プロジェクトマネジメント協会（PMI）が制定している国際的な標準知識体系「PMBOK®️」によると、プロジェクトは以下のように定義されています。

“独自のプロダクト、サービス、または所産を創出するために実施する有期的業務”

さらにプロジェクトの語源について「webilo辞書」で調べると、ラテン語の pro + ject であり、意味は「前方（未来）に向かって投げかけること」とされています。

言い換えると、やるべきことが既に決まっている、日常的に繰り返し行う定型業務（ルーティーンワーク）ではなく「不確実性がある中で、モノゴトを前に進める業務」とも解釈できます。

「プロジェクトマネジメント」とは？

プロジェクトの進行管理については従来「プロジェクトマネジメント」という概念が存在します。近代的なプロジェクトマネジメントの手法が確立されたのは20世紀中期と言われており、実際に活用された例として1960年代の「アポロ計画」があります。有人宇宙飛行という極めて不確実性の高い内容、数えきれないであろう大勢のステークホルダー、膨大なタスクとスケジュールの中で「QCD（品質・コスト・納期）」の管理を行うためにプロジェクトマネジメントが必要とされたことは想像に難くありません。一般的によく知られている「WBS（Work Breakdown Structure）」もこの時代に作られたと言われており、現代のソフトウェア開発プロジェクトにおいても広く利用されています。

「プロジェクトをデザインする」とは？

前述の通り、プロジェクトの進行管理についてはプロジェクトマネジメントという概念が存在しますが、アイスリーデザインでは、一般的に知られるプロジェクトマネジメントとは別の概念として「ゴール（未来）に向かうためのプロセス設計」を「プロジェクトデザイン」と定義しました。

定められた期日とスコープ（範囲）に対して進行管理するプロジェクトマネジメントに対し、そもそもプロジェクトがどこに向かうべきか、何を達成すべきかを明確化する活動をプロジェクトデザインと位置付けています。

プロジェクトデザイン

・コンセプト（提供価値）の定義

・手法の選定、プロセスの設計

プロジェクトマネジメント

・スケジュール、タスク管理

・チーム運営

プロジェクトデザインが重要となった背景

あくまで私たちの体感ではありますが、2020年頃を境にお客様からアイスリーデザインにご相談いただく内容として「やりたいこと（例：モバイルアプリを作りたい）は決まっているが、具体的な目的、目標までは十分に定まっていない」「搭載機能の優先順位を決めかねている」もしくは「アプリを作ってみたは良いが、運用できていない」「あまりユーザーに使われていない」といったケースが非常に増えてきました。

「作っただけ」ではユーザーに使われない時代

このようなご相談が増えた背景として、大きく以下の2点の理由があると考えます。

2010年代からスマートフォンによるインターネット利用が急速に進んだ一方で、コモディティ化も同時に進んだことにより、Webサイトやアプリケーションのモバイル最適化だけでは競合他社との差別化が難しくなった。
コロナ禍やAI技術の台頭といった外部要因により、生活環境が一変した状況。環境変化で生じたビジネス機会に対する施策選定と、変化の速度に応じたPDCAサイクルが求められるようになった。

参考：インターネット利用率（個人）の推移

（出典）総務省「通信利用動向調査」

この状況を踏まえ、今後のデジタルサービスにおいて以下の3点が重要になると考えました。

小さく早くリリースする
- 世の中に出してみないとフィードバックは得られないため、初期リリースにあたっては最小限の機能（＝コアの価値）に絞ってリリースをする
ユーザーを理解し、利用状況を把握する
- 定量／定性ともにユーザーの利用状況を取得して、機能（施策）のチューニングを実施する
ビジネスのKGI/KPIから優先度を定める
- 機能（施策）検討にあたり、ビジネスの目標を達成するかどうかを基準に優先度付けを行う

いわゆる「プロダクトマネジメント」の手法になりますが、私たちアイスリーデザインのようなソフトウェア開発企業としても、依頼された要求や要件そのままに開発、納品するだけではビジネスの成功に十分貢献することはできず「何のために作るのか（提供価値は何か）」「ユーザーは誰なのか」「どのようにグロースするか」を明確化する活動、すなわちプロジェクトデザインが重要であるという見解に至りました。

アイスリーデザインが「プロジェクトをデザイン」できる理由

もともとアイスリーデザインでは「flamingo」をはじめとする自社プロダクトを10年以上サービス展開しており、プロダクトマネジメントの経験、ナレッジが社内に十分に蓄積されていたことから、プロダクトマネジメントの手法をプロジェクトデザインとして活かすことがスムーズにできたと考えます。

不確実性がある中で「行き先を定める」プロセス

プロジェクトデザインの基本的なプロセスは、対象サービスにおける「ユーザー要求」「ビジネス要求」をそれぞれ理解し、かつ現実的な「システム制約」を把握した上で「どこへ向かうか」の指針＝コンセプト定義をするものになります。

プロジェクトデザインに必要な3つの要素

BtoC向けサービス、BtoB向けサービス共に、プロジェクトデザインにあたっては、以下の3つの要素の考慮が必要です。

1. ユーザー要求

ユーザーが利用する価値があると思えるモノ・コト。
（例：必要な情報を素早く見たい、お得に商品を購入したい）

2. ビジネス要求

ビジネス上達成したい目的や戦略。それらを達成するために必要な要求。
（例：会員獲得、利用促進、解約抑止、サービス拡大）

3. システム制約

既存システムの利活用や業務プロセスなどの制約条件。
（例：基幹システムとの連携、外部APIの利用）

ユーザー要求だけを考慮してもビジネスの目的は達成できず、反対にビジネス要求だけを考慮してもユーザーには使われない。なおかつシステム制約を考慮しないとそもそもサービスとして成立しないため、それぞれを考慮することが非常に重要となります。

具体的な実施プロセスの一例

【ユーザー要求の理解】

ユーザー調査・分析

定量/定性の両方の調査を実施します。定量調査については、お客様が保有している既存サービスの利用状況などを確認、分析します。定性調査については、サービス利用想定ユーザー複数名に対しインタビューを行い、傾向を導き出します。

インタビューの発話内容の分析（グルーピング）の様子

ペルソナ作成

ユーザー調査で得られた行動・振る舞いのパターンを基にユーザーのモデルを作成します。ペルソナを作ることで「そのサービスがどんなユーザーのゴールをどのように満たすのか」を可視化できます。

【ビジネス要求の理解】

ヒアリング

サービスの前提となるビジネス理解のため、お客様へのヒアリングを実施します。ここでは既知の課題を共有いただき、改めてサービスで目指すべき事業目標（KGI、KPI）について理解を深めます。

【システム制約の把握】

お客様が既存で用いられているシステム（例：会員情報システム）や連携が必要な外部サービス、現行の業務フローについて把握し、サービス開発における現実的な前提条件を洗い出します。

【コンセプト定義】

コンセプトの言語化

ユーザー要求、ビジネス要求を元に、サービスのコンセプトを言語化します。作成したコンセプトはプロジェクト関係者が共通の目標に向かって走るための羅針盤となります。

指標策定（ノーススターメトリック）

長期的なサービスの成長を導き出す為の指標として「ノーススターメトリック」と呼ばれるフレームワークを用います。KGIとKPIの中間に配置され、プロダクトが目指すべき目標=ノーススター（北極星）を定めます。

【MVP（Minimum Viable Product）のリリース】

コンセプトを元に、サービスで実現する具体的な機能の優先度を定め、MVP（Minimum Viable Product）を定義し、早期のリリースを実現します。MVPはその名の通り「最小限の実行可能な製品」であり、機能を最小限にすることで、より市場への早期投入を優先する考え方ですが、これは全ての要件は仮説ベースで検討されたものであり、世の中に出してみないとユーザーからのフィードバックは得られないためです。