仮説検証型アジャイル開発の詳細

メインページに戻る

仮説検証型アジャイル開発とは?

img-agile

失敗はなくすことができないから

失敗とは正しくないことの学びに他なりません。
失敗をなくすことはできませんが、その失敗を学びとして活用することはできますし、また活用できなければプロジェクトの長期的成功は望むことができません。

しかし失敗時の負荷が高すぎる意思決定はなんとしても防ぐべきでしょう。
そこでわたしたちギルドワークスが提唱するのが、仮説検証とアジャイル開発を包括的に提供する仮説検証型アジャイル開発という製品開発フローです。

なぜ仮説検証が必要なのか

企画や取り組みの「採用・却下の失敗」を生み出すのは根拠の薄い意思決定です。こうした決定をしない、あるいは十分な情報を集めるまで決定を遅らせることによって、失敗時のリスクを致命的なものにしないことが重要です。

根拠ある意思決定とは「客観的検証に基づく意思決定」であるといえます。ギルドワークスはさまざまな調査手法を用いて意思決定に必要な材料・情報を集め、それを繰り返し検証することでより確からしい事業仮説を継続的に導き出します。

なぜアジャイル開発が必要なのか

より確度の高い仮説検証には操作・体験できる必要最低限の「仮説の具現化」のための柔軟でスピーディな開発が必要です。ギルドワークスはアジャイル開発を通じて、より質の高い仮説検証・リスクの低い開発体制を実現します。

アジャイル開発とは、イテレーションと呼ばれるごく短い開発期間を反復することで、開発のリスクを最小化するための手法です。サービス手段の作り込みを漸次的・反復的におこなうことで、ユーザー検証や関係者の認識共通化を段階的におこなえるようにします。

仮説検証×アジャイル開発が生み出す価値

仮説検証とアジャイル開発、それぞれを得意とする企業は数ありますが、これらを一貫して実施できる企業はそう多くはありません。しかし本来「正しいものを正しくつくる」ためには仮説検証と開発は密に連携しているべきです。検証と開発単位の回数(=仮説検証の精度と頻度)をそれぞれフレキシブルに調整することで、より成功確度の高いプロジェクト運営をおこなうことが可能です。

Management of the frequency and accuracy for hypothesis testing

仮説検証の「頻度」と「精度」の
マネジメント

仮説検証型アジャイル開発はあなたのプロジェクトがおかれているステージや、ステークホルダーとの関係性、業界や製品ごとの特質によって様々な体制で実施することが可能です。ここでは仮説検証の頻度と精度に応じた3つの開発体制をご紹介します。

タイプ1

仮説検証の頻度を重視…仮説検証重視型

集中すべき領域やテーマがまだはっきりしていない段階のプロジェクトに最適です。検証手段の作り込みより、仮説を試行する回数を重視します。

想定されるクライアント像

メイン事業以外に取り組めていない事業会社(ベンチャー・中小企業)

persona01

  • アイデア創出のノウハウがない
  • 社内に仮説検証のノウハウがない
  • 社内に開発リソースがない
  • 予算制約が厳しい
  • 予算確保のための作戦が漸次的に必要である

方向性がゼロベースのため、仮説検証に時間をかけて方向性づくりを重視する

タイプ2

頻度、精度のバランス重視…検証・開発バランス重視型

⼀定の検証を得て、領域は絞れたが実現⼿段(ソリューション)の⽅向性が決めきれない段階のプロジェクトに最適です。より確度の⾼い検証結果を得るために、サービスの体験ができる程度のプロトタイプを作り込みます。

想定されるクライアント像

成⻑として⼀⼭越えたサービスを抱え次を⽣み出したいベンチャー/上場を⽬指し新規事業⽴ち上げで企業価値を⾼めたいベンチャー

persona01

  • 社内に仮説検証のノウハウがない
  • 社内に新規にあてがう開発リソースがない
  • 上場の計画上、新規⽴ち上げに期限がある

仮説検証とアジャイル開発を適切に繰り返して⽅向性を定め、製品開発に臨む

タイプ3

仮説検証の精度を重視…アジャイル開発重視型

すでに検証段階を得ていて、集中すべき領域やテーマが判断できている段階のプロジェクトに最適です。現実に実行した場合とほぼ同レベルの検証結果を得るために、MVP※を見据えながら検証手段の作り込みをしっかりおこないます。

※MVP・・・実用可能な最小限の範囲でのプロダクト「Minimum Viable Product(MVP)」を指し、ニーズや課題の仮説から学びを得るための手段です。

想定されるクライアント像

事業会社と直取引しているシステムインテグレーター

persona01

  • 社内に仮説検証のノウハウがない、製品の育て⽅がわからない
  • 社内に開発リソースはあるがユーザーコミュニケーションに関わる開発の経験がない

テーマの⽅向性・あるいは利⽤ソリューションの採⽤が前提であるため試⾏錯誤よりプロトタイプ開発を重視する