ユーザーに学びながら
柔軟に開発を進める
アジャイル型開発をご提供します。
Webアプリケーション開発において最も多い失敗は、「ユーザーが欲しがらない機能をコストをかけて作ってしまう」ことです。
多くのヒトとお金と時間というリソースが投入される開発であるからこそ、作り手の情熱とユーザーが解決したい課題とのギャップをしっかりと埋めて、Webアプリケーションが「明るい廃墟」になってしまうのを防ぐことが大切との考えから、以下の流れで開発を行っています。
開発の流れ
｢何を作るか」を考える段階からユーザーの声を取り入れながら
｢小さく生んで大きく育てる｣、以下のステップでの開発を行います
-
- アイディアについて仮説を立てるIdea Verification
- 開発するWebアプリケーションについて、「リーンキャンバス」と呼ばれるフレームワークを用いて、「誰のどのような課題を解決する機能で、ビジネス的にはどういった立ち位置・収益構造なのか」といったプロジェクトの全体像を記したプランAを設計します。
-
- 課題設定が正しいか検証するCustomer-Problem Fit (CPF)
-
人間誰しも、自分で思いついたアイディアは素敵に見えます。しかしながら「アプリケーションの機能の7割は使われていない」※ という調査結果にもあるとおり、アイディアの検証を経ずに開発を行うと、ユーザーにとって魅力的なアプリケーションになる確率は低いと言えます。
そのためこのステップでは、プランAで想定したユーザーに対する調査を通じて、機能のアイディアと、ユーザーが実際に解決したい課題のギャップを埋めていきます。※ 田所雅之著『起業の科学』
日経BP社より - ターゲットユーザーのことを知る
-
- ｢ペルソナ」と呼ばれるフレームワークを用いて、ターゲットユーザーのワークスタイル、ライフスタイル、趣味嗜好などを調査し、チームで共有します。
- ユーザーが実際にどのように考え行動をしているか、「共感マップ」と呼ばれるフレームワークを用いて明らかにします。
- ｢カスタマージャーニーマップ」と呼ばれるフレームワーク用いて、ユーザーがそのWebアプリケーションとどのように出会い、どういったシチュエーションで利用するのか、具体的なイメージを作ります。
- ターゲットユーザーが本当に困っていることを知る
-
- ｢ジャベリンボード」と呼ばれるフレームワークを用いて、アイディアの検証を行います。
- 1をもとにしてアイディアのブレインストーミングを行い、アイディアを進化させます。
- 2のアイディアをもとに再度、ユーザーインタビューを行います。
- ｢KJ法」と呼ばれる手法を用いて、ユーザーインタビューの結果を分析し、次のステップに進みます。
-
- 課題解決の精度を上げるProblem-Solution Fit (PSF)
- 前のステップまでで、Webアプリケーションが解決しようとしている課題が本当に正しいのか検証を行いました。このステップでは、これまでに洗い出したユーザーの課題をもとに、実際の機能を含めた課題解決の方法にフォーカスしていきます。
-
- 開発する機能を洗い出し、タスクと目的、進捗を見える化した「プロトタイプカンバンボード」を作ります。
- その機能があったら本当に使いたいと思うか、ユーザーインタビューを実施します。
- チームの意識統一のため、「エレベーターピッチ」と呼ばれる手法を用いて、Webアプリケーションの特長を30秒で説明できるようにします。
- 画面遷移図、Webアプリケーションの青写真となる「UXブループリント」を作成します。
- UXブループリントをもとにプロトタイプを作成します。
- プロトタイプを実際にユーザーに触ってもらいフィードバックを受けながら、プロトタイプの精度を上げていきます。
-
- 小さく生んで、ユーザーの理想に近づけていくProduct-Market Fit (PMF)
-
- ｢MVP (Minimum Viable Product)」と呼ばれる必要最小限の機能を持ったWebアプリケーションをリリースします。
- ｢スプリントキャンバス」と呼ばれる手法を用いてユーザーからのフィードバックを反映し、小さなPDCAサイクルを高速に回してWebアプリケーションを磨き込んでいきます。
- ユーザーインタビューによる定性分析を加え、さらに改善していきます。
-
- ビジネス面において軌道に乗せる採算の健全化（ユニットエコノミクス）
- 顧客獲得単価（CPA）を下げて、顧客生涯価値（LTV）を上げるために、「グロースハック」と呼ばれるマーケティング施策および、Webアプリケーション改善のPDCAサイクルを回していきます。
開発の進め方について
ソフトウェア開発の世界では従来、要件定義→設計→実装→テストという流れで大きなPDCAサイクルを一度回す「ウォーターフォール型」という方式が主流でした。しかしながら、ウォーターフォール型の開発には以下のような問題点がありました。
- 要件定義が終わった後は基本的に変更がきかないため、開発段階で学んだこと、思いついたアイディアを反映することができない。
- ｢動くもの」が最後に完成するので、ユーザーのフィードバックは、完成してから初めて得ることができる。ユーザーが欲しかったものと、実際に完成したものにギャップがあった場合、その段階で初めてわかる。
- 一度予算と納期を決めると変更できないため、金銭的にも時間的にもベンダー側に過剰なバッファーを取るインセンティブが生まれる。結果、昨今のビジネスで求められるスピードが実現できない。
そのような問題を解決するために生まれたのが、前述の「開発の流れ」のような「アジャイル型」と呼ばれる開発の方式です。
その中でも私たちは、トヨタ生産管理方式から生まれたスクラムと呼ばれる手法での進行をおすすめしています。この手法は、国内では日本経済新聞社、リクルート、富士通などですでに採用事例があります。
ご請求方法について
私たちはWebアプリケーション開発において、ウォーターフォール型開発で一般的な、最初に要件を固めて「初期構築費用いくら、保守費用毎月いくら」という形でのご請求方法は採用しておりません。
前述の「開発の流れ」のように、ユーザーのフィードバックを随時得ながら要件自体がプロジェクトの中で柔軟に変化していくアジャイル型開発では、金額はご相談のうえで月額定額制にて請求させていただく形をお願いしています。｢開発の流れ」における1から5のフェーズの中で、細かくブレイクダウンしたタスクとその見積りを提示させていただき、設定した月の定額予算の中で、毎月何をやるか決定する形を取らせていただいています。
要件を柔軟に変化させるアジャイル型開発では、固定予算のように不確実なことが起きたときのための大量のバッファーを見積りに折り込まずに済むので、長期的な視点で見た場合、お客様への請求額は固定予算に比べて安くなることがほとんどです。
Webアプリケーションの最初のリリースまでの概算目処の提出や、上限となる予算に合わせてタスクを調整することは可能ですので、ご相談ください。
技術スペック
- プロジェクトマネジメントツール
- GitHub
- ZenHub
- Trello
- Jira
- コミュニケーションツール
- Slack
- Zoom
- 対応可能な技術、フレームワークなど
- HTML/CSS・Sass/JavaScript
- WordPress
- jQuery
- Nuxt.js・Vue.js
- Firebase
- Ruby on Rails
- Heroku
- HubSpot
