「既知のこと」を扱うプロセスと問題点
前回は、「リーン・マネジメント」と「一神教マネジメント」の違いを解説しました。今回は、一神教マネジメントが得意な手法でプロジェクトを進めた場合、どんな問題が生じるかを考えてみます。私がリクルート時代に学んだことをベースに、「既知のこと」を扱う開発プロセスの各フェーズの進め方と、そこにどんな課題があるかを説明します。
私はリクルートに2000年にシステム担当として入社したのですが、そのときに教えられたのが、「ビジネスの検討をして、要件定義をして、設計して、開発する」といった、ビジネス開発のフレームワークでした。いわゆるウオーターフォール型のビジネス開発です。私が理解したそのやり方を概念的に整理したのが次の図です。
この一連のプロセスは、大きく分けると「ビジネス検討フェーズ」と「実行フェーズ」の2つに分けることができます。
従来のセグメント分けは役に立たない
ビジネス検討フェーズでは、まず初めに「セグメント別の提供価値議論」を行います。これは、ユーザー全体に対してどのような価値を提供するかを考えるのではなく、ユーザーをセグメントごとに分けて提供価値を考えるフェーズです。例えば、転職サイトのユーザーであれば営業職、技術職、事務職といった職種ごとにセグメント分けをしているので、それぞれのユーザーセグメントに対して「どのような価値や機能を提供できるのか」が議論の対象になります。
しかし、セグメントの分け方を「これまで社内で使われてきたメジャーなセグメント分け」にしてしまうと、イノベーションを起こしにくくします。なぜならば、ずっと使われてきたセグメント分けだと、既に考え尽くされたことしか発見できない可能性が高いからです。
社内で使い古されたセグメント分けを使い続けている企業は多いと思います。その理由は、「決裁者たちが理解しやすい分け方だから」ということに他なりません。決裁者は日々、大量の分析報告やモニタリングデータを目にしていて、日常的に使われているユーザーセグメント分けで考えることに慣れています。新しいユーザーセグメントで起案すると「よくわからないから元の分け方で説明してよ」と言われてしまうのです。
決裁者にとってわかりやすい従来のセグメント分けでユーザー価値を考えてしまうと、最初の一歩からイノベーションは起こしにくくなる。そこが落とし穴です。
Powered by リゾーム?