DXのスムーズな推進に最適な「フレキシブルな開発」と「グロースの進め方」とは？

開発フェーズ：フレキシブルな開発の進め方

船山　「フレキシブルな開発」とは、「品質（Quality）」「コスト（Cost）」「納期（Delivery）」「スコープ（Scope）」、すなわち「QCDS」をある程度柔軟に変更できる開発の進め方を言います。

フレキシブルな開発手法の一つであるアジャイルは、最初からスコープが可変です。一般的には納期を固定し、その期間の中で実装可能なものを実装していきます。

対して、QCDSを固定して進める開発手法が「ウォーターフォール」です。ウォーターフォールでは、もしスコープが変動すれば、追加見積もりを取るケースが一般的です。

なぜ新規サービスの開発に「フレキシブルな開発」が適しているのか？ まずテクノロジー、デザイン、ビジネスの観点からは、以下の3つの理由が挙げられます。

• テクノロジー観点：プロジェクトを成功（開発を完遂）するために必要
• デザイン観点：真にユーザーが求めるモノを作り、正しく価値を提供するために必要
• ビジネス観点：ビジネスを継続的に運営し、きちんと利益を上げるために必要

さらに、社内マネジメント観点、ユーザー観点、競合企業観点からは、以下の3つの理由があります。

• 社内マネジメント観点
  プロジェクトを進めるには、社内のステークホルダーとの合意も不可欠です。しかし、設計書やコンセプトだけでは、本当の意味での合意を得ることは難しいため、実際に動くものを見せて、真の合意形成を作る必要があります。

• ユーザー観点
  実は、顧客は、意外と自分のニーズをよく理解していません。開発前にインタビューを行って搭載した機能でも、実際にはほとんど使われなかったというのは、よくある話です。それを回避するためには、きちんと動くものを用いて、顧客が本当に価値を感じてもらえる機能かどうかを検証しながら開発していく必要があります。

• 競合企業観点
  ITサービスは参入障壁が低い分、スピード重視で製品をリリースしていく必要があります。それゆえに、状況に応じて事業やプロダクトを方向転換するような柔軟性も求められます。

これらの6つの観点を押さえながら、プロジェクトの推進やプロダクト開発を行うには「フレキシブルな開発」が必要なのです。

フレキシブルな開発はどう実現するのか

「フレキシブルな開発」はどのようにすれば実現できるのか？ ポイントは3つです。

• 準委任契約に移行する
  請負契約から準委任契約に移行します。この2つの契約の大きな違いは、前者は成果物に対して対価が発生するのに対し、後者は稼働人員に関して対価が発生するということです。契約の特性上、請負契約による開発は、とにかく成果物を作ることが目的になります。準委任契約による開発の場合、使い続けられるプロダクトを作ることが目的になるため、スコープを柔軟に変更しながら開発していくことになります。

• マインドチェンジを行う
  発注者側／受注者側が一丸となったワンチームを構築します。そうでないと、結局、スピード感に欠けることになり、ユーザーへの価値提供が難しくなります。スピード感がなければ競合に競り負ける可能性も高くなります。

• プロセスのチェンジを行う
  アジャイルには、「ライトウイング」と「レフトウイング」という考え方があります。発案者の平鍋健児氏によると、ライトウイングは「CI（継続的インテグレーション）を中心とする技術的なプラクティス」とし、主に開発環境や技術的なこと。一方、レフトウイングは「プロセス的なプラクティス、および、コミュニケーションやモチベーションに属する人間系のチェンジ」としており、チーム環境に関わることとしています。平鍋氏は、アジャイルには、この両ウイングのマインドチェンジが必要だとしています。

フレキシブルな開発において特に注目したいのが、レフトウイングです。いわゆる組織マネジメントに関する概念を包括しており、その中には「スクラム」も含まれます。

スクラムは、アジャイル開発の手法の一つで、スプリントと呼ばれる期間（1～4週間）を定め、その短い期間の中で実際に機能を実装しながら、PDCAを高速で回す方法です。スクラムには、必要最低限のルールしか定められておらず、必要なルールはチームで考えて決めるという根本思想があります。つまり、スクラムを実施するためには、開発の背景や思想までを、チーム全体が理解した状態にする必要があります。

開発フェーズ：失敗事例から見えた組織づくりの課題

宇野　これまで多くのプロジェクトを担当してきた中では、もちろん、うまくいかなかったものもあります。

失敗したプロジェクトの多くは、初期段階に計画が変更し、それに対応できなかったことに端を発していました。すなわち、変化に柔軟に対応できるチームと、プロセスの形成こそが、失敗しないプロジェクトの要諦だと言えます。

変化に柔軟に対応できるチームを作るには、以下の3点を意識する必要があります。

1. 受注者／発注者の枠を超えた1つのチームとして意志決定ができる状態にしておく
2. 要求元と作業者の心理的な距離を近くしておく
3. ゴール設定、およびゴールまでの距離（現状把握）だけでなく、変化が生じた際の対応方針などを、きちんとチームの共通認識にしておく

こうしたチームを作ることで、さまざまな変化に柔軟に対応した「フレキシブルな開発」を実現することができると考えています。

グロースフェーズ：事業成長に有効なグロースの進め方

神田　新サービス開発にとってのゴールは、サービスのローンチではありません。大切なのはその後、どうやって収益を最大化させるかです。そのために有効な方法論がグロースです。

グロースとは、機能横断するさまざまなメンバーが協力し合いながら、顧客がプロダクトのどこに価値を感じているか、あるいは不満点はどこにあるのかを見定めながら、改善策を実装していくプロセスです。これを高速で繰り返すことで、事業成長を進めていきます。

「グロース」は大きく分けて、「グロースのための準備」と、「グロースエンジンをまわす」という2つの段階があります。

グロースのための準備

グロースの準備段階でやるべきことが、PMF（Product Market Fit）の確認と、NSM（North Star Metric）の策定です。前者は、開発したプロダクトをユーザーが受け入れてくるかどうかを確認することを指し、後者は、さまざまな組織から集まったメンバーが同じ方向を向いて走るための指標です。

PMFには、Must-have survey（マストハブ・サーベイ）というアンケート調査のほか、行動データを分析してプロダクトの定着を見極めるなど、さまざまな方法がありますが、ともかく、最初にやるべきは、作ったプロダクトが本当に市場に受け入れられるものなのかどうかを確認することです。受け入れられなければ、それを課題として再びスプリントをまわす。受け入れられれば、NSMの設計に移ります。

NSMとは、多様なメンバーが「顧客提供価値」に注力し、「収益改善」を達成するための指標です。組織横断チームは、開発目線がバラバラになりがちですが、「顧客へどういった価値を提供するか？」という視点に注力することで、チームが一枚岩になれます。以下、指標の策定ポイントとして、3点ご紹介します。

• 顧客提供価値を踏まえて策定
  顧客提供価値とは、「企業は顧客に対してどのような価値を、どう提供できるか？」という問いに対する答えです。それを踏まえて指標を策定することが重要です。

• 売り上げへの先行指標を用いる
  先行指標とは将来のパフォーマンスが予測できるものをいいます。NSMは売上の先行指標の中から選びます。

• 話し合いで納得解を見つける
  実は、NSMには正解がありません。だからこそ、メンバー全員で納得解が得られるまで話し合うことがとても大切です。われわれ電通デジタルも、クライアント企業と一緒になってNSMを策定するワークショップを1～2日かけて行っています。

グロースエンジンをまわす

PMFの確認と、NSMの策定が完了したら、グロースエンジンをまわす段階に移ります。

グロースエンジンは、「分析」「アイデア生成」「優先度整理」「実験」というプロセスを踏みますが、この一連の流れをまわす際に陥りがちなのが、「どこに問題があるか判別できない」、「改善案が思いつかない」ことで、エンジンが止まってしまうケースです。

その際に有効なのが、分析の解像度を上げることです。CVRやCPA、MAUなどをダッシュボードで分析していても、経営判断の材料にはなりますが、新サービス開発という視点で見れば、あくまでもそれは過去の成績表に過ぎません。データをインテリジェンスとして活用し、未来を見定めるヒントとして使っていくという意識に切り替える必要があります。

たとえば、海賊指標（AARRR）を使うと、獲得／活性化／継続／紹介／収益、それぞれのステップにどういった状況でどんな問題があるのかを細かく見ることができます^[注1]。このように詳細に問題点を見つけていくことは、顧客理解を深めることにつながります。

DX時代のサービス開発に求められる共通原則

桑山　ここまで、「構想」「開発」「グロース」と3つのフェーズに分けて、デジタルサービス開発プロセスの紹介をしてきました。最後に、すべてのフェーズに共通する3点の原則と、それに伴う今後取り組むべきテーマを、ご紹介します。

原則1：顧客が中心

最初にご紹介する原則は、顧客が中心であるということです。

今やサービス開発においては、「顧客に価値をもたらすもの」に、組織の目標やKPIを設定することが重要になっています。リリースすること自体が目標なのではなく、リリース後にちゃんと顧客に価値を届けられたかどうかまでをトラッキングしなければなりません。

そのためには、開発プロセスの中で顧客からのフィードバックを得て、それを基に学習し、プロダクトに反映していくプロセスを、開発プロセスの中に組み込む必要があります。

原則2：より速く、より柔軟に

2つ目の原則は、より速く、より柔軟に、です。

デジタルサービス開発において、「速さ」（早さ）は最強の武器です。そのサービスの顧客価値はどこにあるのか、顧客にこのサービスは受け入れられるのか。早く知ることで、早く修正することができます。すなわち、学習速度を上げることで、より顧客にフィットしたプロダクトを、早く届けられるわけです。

学習速度を上げるためには、課題に対して複数の解決案を用意する必要があります。それによって、より当たりのよかったものを選択していきながら、効率的によりスピーディーに開発を進めていくことができます。また、ロードマップなど固定的な計画表を作らざるを得ないときもあります。しかし、長期計画の中であっても、アジャイル的なプロセスを組み込みつつ、速さを意識して進めていくべきです。

原則3：コラボレーション

3つ目の原則は、コラボレーションです。

デザイナー、エンジニア、ビジネス側のマネージャーなど、立場の異なるメンバーが一緒になることで、批判的な姿勢ではなく、協調的なスタンスで新しいサービスを作っていけるような、ともに学んでいけるようなチームを作らなくてはなりません。また、対面でのコミュニケーションが難しい時期だけに、リモート環境でいかにコラボレーションを有機的に行うかといった工夫も必要です。

最後に：完璧を目指す前にまず終わらせろ

これら3つの原則は、皆様の組織に置かれた状況によって取り得る選択肢はいろいろ変わってくると思います。ただ、いずれにせよ、現場での創意工夫が必要だと考えています。

Facebookの共同創業者兼会長兼CEOマーク・ザッカーバーグ氏の言葉に、

というものがありますが、これはある意味、DX時代におけるモノづくりを体現する言葉でもあると思います。こういったアジリティーを重視するマインドセットを組織の中にインストールしていくことが、サービス開発においても、非常に重要です。われわれも、クライアント企業のプロジェクトにおいて、そういったお手伝いもしていきたいと考えております。

注釈