SERVICE ／ プロダクト構築支援 ／ ビジネスフィット開発
Business-Fit Development ビジネスフィット開発
効くまで、つくる。
要件をすべて決めてから、大きく作って納品する——その進め方では、完成した頃に事業のほうが先に進んでいます。
ビジネスフィット開発は、小さく作って早く動かし、実際の利用から学びながらプロダクトを作り込んでいく開発です。
リリースを終点にせず、必要な状態変化が起こり、事業の成果につながるまでを担います。
このページで言う「効く」とは、必要な状態変化が起こり、その変化が成果につながっている状態のことです。システムが動くこと、使われること自体を指しません。
※ プロダクト構築支援で選べる、進め方のひとつです。
WHY
従来型の開発は、なぜ事業とずれるのか
完成したときには、事業のほうが先に進んでいる。
最初にすべてを決める開発は、「決めた時点の想像」に投資する開発です。作っている数ヶ月のあいだにも、市場も業務も変わり続けます。
長い要件定義
使う前の想像で仕様を決めるため、確度の低い要件に時間と予算を使ってしまう。
過剰な初期機能
「念のため」の機能が膨らみ、使われない機能に開発費の多くが消えていく。
高い開発負荷
すべてを一度に作りきるため、確認・調整・テストが終盤に集中し、現場と開発の負荷が跳ね上がる。
納品して、終わり
リリース後に分かった「本当に必要なこと」を反映する仕組みも予算も、残っていない。
PROMISE
リリースを、納品の終点にしない。
実際に起きた状態変化と成果をたしかめ、次に何を改善するかを選び、プロダクトを磨き続ける。私たちは成果が確認できるまで開発の責任を手放さず、プロダクト開発に必要な全工程——目的の定義、体験設計、開発、リリース、計測、継続改善——を担います。
経営判断そのものを代行するわけではありません。私たちが用意するのは、判断に必要な材料——データと選択肢です。
この約束を支える、3つの決めごと。
ひとつのチーム
目的・体験・開発・データを分断せず、一つの状態変化と成果を見ながら動きます。役割の分断が伝言ゲームと手戻りを生むからです。
共通の判断会議
継続・変更・中止を、状態変化・成果・データ・現場の声をもとに、お客様と一緒に決める場を定期的に持ちます。
学びを報告する定例
定例は作業報告の場ではなく、状態変化・成果・KPIから得られた学びを確認する場にします。
APPROACH
小さく作り、実利用から学ぶ
想像で決めず、実利用で決める。
最初から完成形を当てにいきません。実際の利用、業務の変化、顧客の反応から、次に何を改善すべきかを判断します。
サイクルの起点は、「このプロジェクトで何を実現するのか」と「誰を、どんな状態に変えたいのか」の合意です。その状態変化によって生み出したい成果を定め、成果や変化を確認するためのKPIを置く。
数字は、目的ではなく、実際に何が起きたのかを確かめるために使います。
PROCESS
支援の範囲と進め方
目的・状態変化の定義
このプロジェクトで何を実現するのか。誰を、どんな状態に変えるのか。その結果として生み出したい成果と、それを確認するKPIを合意する。作らないことも、ここで決める。
初期版の設計・開発
状態変化を起こすために必要な最小構成を仮説として設計し、早く形にする。
リリース・計測
実際に使ってもらい、行動・業務の変化と、成果を確認するためのデータを取る。
判断
実際に起きた状態変化、成果、データ、現場の声をもとに、次に作る機能の優先順位をお客様と一緒に見直す。
継続改善
成果につながる変化を見極めながら、必要な機能と体験を作り込む。03へ戻り、状態変化と成果が確認できるまで繰り返す。
FIT
向いているプロジェクト
完成形は、決めきれない。ビジネスは、次に動いているから。
それは準備不足ではなく、当然のことです。事業が動き続ける以上、最初に固めた要件は必ず古くなります。
だからこそ、実際に使いながら「何が事業に効くか」を確かめるこの進め方が効きます。とくに、次のようなプロジェクトで力を発揮します。
最小構成で市場に出す
顧客の反応から育てる。想像で作り込む前に、売れる形を見つける。
業務とのズレを解消する
実際の利用状況と現場の声から、業務に合わない部分を特定し、順に作り替える。
成長に効く改善を重ねる
利用データと顧客の反応をもとに、次の一手を選び続ける。改善の打率を上げる。
実例：経営管理SaaS「BizSuite」── 毎日使い、毎週直す
※ 要件が完全に確定していて今後も変わらない開発は、一括請負型のほうが適している場合があります。その見極めも、最初の相談でお伝えします。
DIFFERENCE
一括請負型の開発との違い
| 一括請負型の開発 | ビジネスフィット開発 | |
|---|---|---|
| 要件 | 最初にすべて確定する | 使いながら見直す |
| 初期投資 | 全機能ぶんを最初に確定 | 最小構成から段階的に |
| リリース | 最後に一度 | 早く、何度も |
| 仕様変更 | 追加費用と調整ごと | 前提として織り込む |
| 成果の確認 | 納品・検収で完了 | 状態変化と成果を、KPIの実測値と現場の事実から確認する |
| 完了の定義 | 仕様どおりに動くこと | ビジネスに効いた状態 |
FAQ
よくある質問
要件が固まっていなくても相談できますか？
はい。むしろ固まっていない段階からが本領です。最初に行うのは要件定義ではなく、「このプロジェクトで何を実現するのか」と「誰を、どんな状態に変えたいのか」の定義です。そこから生み出したい成果とKPIを決めれば、最初に作るべき最小構成を絞ることができます。
既存システムの改善にも使えますか？
使えます。現状の業務とシステムのズレを計測から特定し、効く改善から順に作り込みます。「作り直しありき」ではありません。
費用や契約はどうなりますか？
最初から大きな予算を確定させる必要はありません。小さな単位で始め、成果を確認しながら継続を判断できる形で、案件に合わせて設計します。まずはご相談ください。
途中でやめられますか？
続ける・方向を変える・止めるを判断する機会を、定期的に設けます。撤退の判断が早くできることも、この進め方の利点のひとつです。
まず、「ビジネスに効いた状態」を
一緒に定義しませんか。
資料も要件書もいりません。いま事業で起きていることを、聞かせてください。