開発が先か、マーケットリサーチが先か

私が以前ご支援した案件の中に、法人向けサービスの新規企画・開発プロジェクトというものがありました。
商材が特殊だったため、いわゆる既存市場のようなものはハッキリとは存在していない一方、簡単な事前調査から、一定割合で潜在ニーズは見込めそうだということだけは分かった状態で、プロジェクトは開始されました。
本サービスはアジャイル型の開発方針を取っていたため、「最初は最低限の機能を持たせてリリースし、順次必要な機能を追加実装する」というのがこのサービスの大まかな方針でした。

ところが詳細なサービス開発の方針を決めるにあたり、営業部と開発部の間で、モメにモメたのです。
その最大の要因が、「開発が先か、マーケットリサーチが先か」というものでした。

まず、開発部の言い分はこうでした。

営業部がセールスポイントを増やすために、あれもこれも機能を実装したい気持ちは分かる。ただ、予算も工数も限られており、無駄な機能を開発したくない。
端的に言えば、「売れないモノは作りたくない」

これに対して、営業部はこう返しました。

このサービスはまだマーケットが確立しておらず、お客様の中にどのようなニーズがあるか明確には分かっていない。それでも営業を行っていくためには、まずモノをある程度作ってくれないと、売り込みに行けない。
端的に言えば、「何が売れるか分からないから、まずはモノを作れ」

どちらの言い分も、決して間違ってはいません。
ただ残念ながら、互いの主張が思いっきり相反しており、いわゆる「タマニワ状態（タマゴが先か、ニワトリが先か）」になっていたのでした。

当然ですが、顧客になってくれそうな企業を訪問し、マーケットリサーチを行わなければ、売れるために必要な機能が何なのかは分かりません。一方で、潜在顧客に営業を行うためには、ある程度セールスポイントになりそうな機能を実装した状態でないと、そもそも売り込みに行けません。
開発方針を決める会議は、なかなか集約しませんでした。

タマニワ問題は何故起こるのか

両者の主張が食い違う背景には、そもそも各部が置かれた状況が違うことが挙げられます。

開発部にとって、最重要視されるのは「QCDを守った開発の実施」となります。
Q: Quality(品質)は担保しつつ、C: Cost(費用)とD: Delivery(納期)は守るということが開発部の評価指標となっているため、まずは費用と納期を抑えようとします。
今回のプロジェクトの場合、予算は既に決まっていたため、開発部としては納期を抑えることでしか、品質の担保ができない状況でした。

そのため、無駄な機能を開発することは、工数的に許されない状況です。
売り上げに直結するようなMUST機能の開発に注力し、「あったらいいな」的な機能(nice to have)は極力避けようとします。
その結果として、先ほどの発言に至ったというわけです。

一方営業部にとって最重要視されるのは、「売り上げの数字達成」となります。
予算申請の際に提示した見込み売上高を達成することは必達であり、そのために出来るだけ顧客の要望に応えようとします。

営業からすれば開発コストの心配よりも、顧客が必要としている機能を少しでも早く提供できるかどうか、そこが問題となります。もちろん顧客に刺さらない機能は不要ですが、どの機能に対して魅力を感じてもらえるかは営業しないと分からないため、各機能がMUSTかnice to haveなのかは、判断がつかないのが実態です。

上記のように、開発部と営業部では、それぞれ最重要とされる項目が異なります。
各部ではそれぞれの目標に従って組織運営を行うため、「部分最適化」が進められることになります。
実はこれこそが、タマニワ問題の根本的な要因です。

部分最適化は、その部門内では何一つ問題にはなりません。
しかし、他の部門における部分最適化も実施する際、両部での部分最適化は必ずしも同時に達成できるとは限らないのです。

よくある例として、在庫保有における調達部と営業部の考え方に違いが挙げられます。
調達部は在庫コストを出来るだけ下げることがKPI(Key Performance Indicator: 業績評価指標)となっている一方、営業は納期短縮がKPIとなっています。このため、在庫を薄くすると短納期に応えられなくなり、逆に顧客への納期短縮に対応すると、在庫を厚く持たざるを得ないという、ある種のジレンマ的な状態が形成されます。
今回のプロジェクトにおける状況も、これに似たようなところがあります。

部分最適化の視点では、"企業全体としてどうすべきか"という、全体最適化の視点が往往にして欠けがちです。
タマニワ状態が発生している際は、ほぼ100%の確率で、全体最適に必要な他の重要事項を見落としています。

例えば在庫の例では、金額的な影響の話が抜けています。
在庫コストが財務に影響する度合いが大きければ、多少納期を遅らせたとしても、在庫を薄くすべきです。一方、売上高の大きな得意先に対しては、多少コストが嵩んだとしても、在庫を厚く持っておくべきです。
この数字感が見えない限り、両部でタマニワ問題を論じていても、堂々巡りにしかならないのです。

タマニワ問題を越えるために

それではタマニワ問題が発生した際、折り合いをつけて問題を超えていくにはどうしたらよいのでしょう。
私の考えでは、「全体最適化を推進する責任者を決める」というのが、もっとも現実的な方法だと感じています。

営業部と開発部の話に戻ります。
実はあの問題には、企画部という第三の部門が存在します。本プロジェクトの発案のみならず、プロジェクト稟議の提出・予算獲得も、すべて企画部が行なっています。つまり、企画部がプロジェクトオーナーというわけです。
しかしプロジェクトが開始してみると、営業部と開発部の堂々巡りの議論が熱を帯びてしまい、企画部はだんだんと存在感を失っていきました。両部ともプロジェクトの成功を真剣に考えているからこその議論であったため、どちらかを立てるということは、企画部には出来ないでいたのです。

このプロジェクトにおいて、企画部にとっての部分最適は、「本プロジェクトにおける利益の確立」でした。
売上高にもコストにも責任を負っている唯一の部門であり、また、会社としての責任と部門責任が合致している唯一の部門でした。
つまり、企画部は全体最適化のミッションを課されている部門というわけです。

私たちコンサルがアサインされたのはプロジェクトが開始されてから少し経った後でしたので、まず行なったことは「企画部に全体最適化の旗振り役になってもらう」ことでした。
営業部と開発部の議論には、「利益を最大化する開発を行う」という、中間的な視点が欠けていました。そのため、なかなか先が見えない中でも、コストパフォーマンスが良いと判断される機能に優先度をつけて、『エイヤ！』で進める決断を行う仕事を、企画部に担ってもらったのです。
開発部に機能毎の開発コスト概算を出してもらう一方、営業部から企業訪問時の肌感を直接聞いて、ニーズの"アタリ"をつけていきました。そして双方を考慮した結果、最も妥当だと思われる開発プランを作成し、両部にその方針で動いてもらうようにしました。
元々「正しい答え」は誰も知らない状況なので、この時につけた"アタリ"が正しかったかどうかは分かりませんでした。しかし少なくとも「自分たちは全体最適化に向けて動けている」という共通認識がプロジェクトメンバ間で持てたことで、部門ごとの部分最適にあまり拘らず、前向きに議論することが出来るようになりました。

全体最適化を進めるには、2つポイントがあります。

１つめは「正しい人に責任者になってもらうこと」です。
たまに起こることとして、体制図上の責任者と、実態上の責任者が異なっている場合があります。この場合、現場を回すのは後者で良いですが、全体最適化を推し進める責任者には、必ず体制図上の責任者にやってもらう必要があります。もしプロジェクトとしての正しい体制図がどこにもない場合は、まず体制図を整備して、承認してもらうところから始める必要があります。

２つめは「部分最適化にもある程度配慮すること」です。
全体最適化を推し進めるあまり、各部の部分最適化を全く考慮せずに進めてしまうと、それぞれの部のメンバが不利な目に遭うことが多いです。そのため、基本的には全体最適を達成する方向で検討しつつも、個別の論点においては必要に応じて「立てるべきところを立てる」ことも必要になります。

プロジェクトリーダーの能力や、個々の状況によって一概には言えませんが、
少なくとも上記2ポイントに配慮できていれば、タマニワ問題に一定の折り合いをつけて進められるのではないでしょうか。

まとめ

・部門ごとの部分最適化は、互いに相反する内容を含んでいることがあり、同時に達成することは難しい

・全体最適化を進める旗振り役を設置し、全体最適の方針を全員の基本方針に設定することが、タマニワ問題を越えるためには必要

・「体制図上の正しい責任者の任命」と「ある程度の部分最適化への配慮」が、円滑な全体最適化を実施するためのポイント