プロダクト開発プロセスの設計・導入

＜背景・目的＞
N社では、プロダクト開発における共通プロセスや判断基準が十分に整備されておらず、ディスカバリー1とデリバリー2が一貫した流れとして確立していない状況がありました。そのため、プロジェクトの進め方や意思決定が担当者ごとの経験や裁量に依存し、品質や生産性にばらつきが生じていました。
1 ディスカバリー ・・・ プロダクトを作る前に、不確実性やリスクを下げるために、価値・技術・事業の観点で成立性を検証する。「価値の発見」を意味する。
2 デリバリー ・・・ プロダクトを通じて顧客に価値を提供するために、検証済みの前提に基づき、システムを開発・リリースする。「価値の提供」を意味する。

主な課題は以下の通りです。
1. 仮説を十分に検証しないまま開発に進んでしまうこと
2. 進め方や判断が属人化し、再現性を担保しにくいこと
3. 不十分な要求整理や優先順位付けにより、不要な開発や手戻りが発生すること
これらは、開発工数の増加だけでなく、プロダクト本来の目的達成を難しくする要因にもなっていました。

AX Consultingでは、N社のプロダクト開発をより健全で再現性の高いものにするため、プロダクトのディスカバリーとデリバリーをフェーズとして区分しながら、両者を一貫したプロセスとして接続する仕組みづくりを支援しました。顧客や業務における問題を定義したうえで、早期に顧客価値・技術的実現可能性・事業成立性を検証し、その結果をソリューションの構築・提供につなげることで、組織として判断・学習・改善を積み重ねられるプロダクト開発プロセスの設計・標準化を目的としました。




＜進め方＞
AX Consultingでは、N社の複数プロジェクトにアジャイルコーチとして伴走し、ディスカバリーからデリバリーまでの実践を支援しました。プロセスデザインやファシリテーション、メンバーへのレクチャーを行いながら、価値検証、要求整理、優先順位付け、開発プロセス、意思決定の進め方を現場で整備しました。

広く普及している標準的なプロダクト開発の方法論に加えて、実際のプロジェクト支援を通じて得られたノウハウを反映し、N社の体制やプロジェクト特性に合わせた標準プロセスとしてガイドライン化しました。有識者レビューを経て内容の妥当性を高め、関係者へのナレッジ共有を行うことで、他プロジェクトにも横展開しやすくしました。




＜ディスカバリーフェーズ＞
ディスカバリーフェーズでは、課題の特定や価値の探索を行い、「なぜ作るか」「何を作るか」を判断する流れを整理しました。一般的にPoCは「概念実証」として広い意味で使われますが、本プロセスでは検証活動を価値・技術・事業の3つの観点に分け、それぞれPoV・PoC・PoBとして定義しました。よって、本プロセスのPoCは、主に技術的な実現可能性を検証する狭義のPoCとして扱っています。

この3つの観点は、IDEOが提唱するDesirability（顧客は望んでいるか）、Feasibility（実現できるか）、Viability（事業として成立するか）とも対応します。PoV・PoC・PoBは互いに影響し合うため、順番に進めるのではなく、並行して進めるプロセスとして設計しました。
PoV（Proof of Value） ・・・ 価値実証（顧客にとって価値があるか、課題解決につながるかを検証する活動）
PoC（Proof of Concept） ・・・ 技術実証（技術的に実現できるかを検証する活動）
PoB（Proof of Business） ・・・ 事業実証（事業として成立するかを検証する活動）




＜デリバリーフェーズ＞
デリバリーフェーズでは、検証済みの前提に基づき、「どうやって作るか」にフォーカスし、スクラムに技術プラクティスを組み込みながら、短いサイクルで開発を進め、品質・セキュリティ・リリースまでを意識した価値提供のプロセスを定義しました。

また、スクラムを適用しても、プロジェクトとしての立ち上げや開発に向けた準備には一定期間が必要となります。そのため、開発が始まるSprint 1の前にSetupとSprint 0を設け、以下の4段階でプロセスを整理しました。
Setup ・・・ デリバリーフェーズの立ち上げ。インセプションデッキや要求整理などを行う
Sprint 0 ・・・ Sprint 1以降の開発に備える準備スプリント。環境整備、アーキテクチャ設計、リリースプランニングなどを行う
Sprint 1〜n ・・・ 開発スプリント。2週間単位でスクラムイベントと開発作業を行い、MVPリリースを目指す
Sprint n+1〜 ・・・ 継続開発スプリント。リリース後の機能追加・改修・保守を行う。運営方法はSprint 1〜nと同様



＜手法＞
本支援では、リーン＆アジャイルやプロダクトマネジメントをベースに、以下の方法論やアプローチを組み合わせてプロセスを設計しました。
・デザイン思考
・リーンスタートアップ
・スクラム
・DevSecOps

要所要所で上記方法論のエッセンスを盛り込んでいますが、手法に関してはフェーズやプロセスごとに様々なプラクティスを取り上げ、より多くの選択肢を提供するようにしました。各手法をどの局面でどのように活用するかまで、ガイドライン内で解説していますが、ここでは割愛します。


＜工夫・成果＞
わかりやすいアウトプットとして日本語版・英語版のプロセスガイドラインを作成し、N社内に公開しました。

ガイドラインは形式的なルール集にせず、現場で使える実践的なプロセスにすることを重視しました。プロジェクトの規模や不確実性、制約に応じて柔軟に活用できるよう、フェーズ構成、役割分担、判断基準、開始・完了条件、主要な成果物を整理しました。

また、ディスカバリーとデリバリーのフェーズを分けるだけでなく、検証結果を開発判断につなげる流れを明確にしました。これにより、開発前の検証不足や後工程での手戻りを抑え、関係者間の合意形成を進めやすくしました。

その結果、N社ではプロジェクトごとにばらついていた進め方や判断基準が整理され、関係者間でプロセスに対する共通理解が形成されました。担当者の経験や裁量に依存しないプロセスが整備されたことで、他プロジェクトへの横展開ができるようになり、プロダクト開発における品質の安定化、生産性の向上、組織学習を支える基盤となりました。