パワポを何度も書き直して、やっとの思いで通した提案が、こんなに大変なことになるなんて――。顧客をセグメント分けして提供する価値を探り、競合の出方を予想して対策を取るというビジネス開発プロセスは、「既知のこと」には有効でも、「未知のこと」に取り組む場合は大きな障害になり得ます。1年で100億円の売り上げアップを実現し、リクルートキャリア執行役員兼リクナビNEXT編集長を務めた細野真悟氏の著書『リーンマネジメントの教科書 あなたのチームがスタートアップのように生まれ変わる』から一部抜粋して掲載します。

「既知のこと」を扱うプロセスと問題点

　前回は、「リーン・マネジメント」と「一神教マネジメント」の違いを解説しました。今回は、一神教マネジメントが得意な手法でプロジェクトを進めた場合、どんな問題が生じるかを考えてみます。私がリクルート時代に学んだことをベースに、「既知のこと」を扱う開発プロセスの各フェーズの進め方と、そこにどんな課題があるかを説明します。

　私はリクルートに2000年にシステム担当として入社したのですが、そのときに教えられたのが、「ビジネスの検討をして、要件定義をして、設計して、開発する」といった、ビジネス開発のフレームワークでした。いわゆるウオーターフォール型のビジネス開発です。私が理解したそのやり方を概念的に整理したのが次の図です。

（『リーンマネジメントの教科書』75ページに掲載）
（『リーンマネジメントの教科書』75ページに掲載）
[画像のクリックで拡大表示]

　この一連のプロセスは、大きく分けると「ビジネス検討フェーズ」と「実行フェーズ」の2つに分けることができます。

従来のセグメント分けは役に立たない

　ビジネス検討フェーズでは、まず初めに「セグメント別の提供価値議論」を行います。これは、ユーザー全体に対してどのような価値を提供するかを考えるのではなく、ユーザーをセグメントごとに分けて提供価値を考えるフェーズです。例えば、転職サイトのユーザーであれば営業職、技術職、事務職といった職種ごとにセグメント分けをしているので、それぞれのユーザーセグメントに対して「どのような価値や機能を提供できるのか」が議論の対象になります。

　しかし、セグメントの分け方を「これまで社内で使われてきたメジャーなセグメント分け」にしてしまうと、イノベーションを起こしにくくします。なぜならば、ずっと使われてきたセグメント分けだと、既に考え尽くされたことしか発見できない可能性が高いからです。

　社内で使い古されたセグメント分けを使い続けている企業は多いと思います。その理由は、「決裁者たちが理解しやすい分け方だから」ということに他なりません。決裁者は日々、大量の分析報告やモニタリングデータを目にしていて、日常的に使われているユーザーセグメント分けで考えることに慣れています。新しいユーザーセグメントで起案すると「よくわからないから元の分け方で説明してよ」と言われてしまうのです。

　決裁者にとってわかりやすい従来のセグメント分けでユーザー価値を考えてしまうと、最初の一歩からイノベーションは起こしにくくなる。そこが落とし穴です。

次ページ どんどん機能の追加が必要に