問題解決の捉え方と用語の理解

これまで問題解決に関する本や記事をいくつか読んだことがあるが、いまいちそれぞれの概念や考え方が噛み合っている感覚がなかったので、今回自分なりに問題解決を捉えてその中での位置付けを考えてみた。

問題解決の捉え方

自分は問題解決を下記のように捉えるのが良いのではないかと思う。

  • 目標の状態： f'(x)=w_{1}x'_{1} + w_{2}x'_{2} + w_{3}x'_{3}..
  • 現状：　　　 f(x)=w_{1}x_{1} + w_{2}x_{2} + w_{3}x_{3}..

xは結果（f）に影響を与える要素（=要因）を表しており、wは結果に対する各要因の重みを表している。そして個々の要因はさらに下位の要因によって構成されている。
この表現は、「それぞれ別個の重みを持つ要因に働きかけ、その状態を変化させることで問題を解決する」という問題解決の特徴を表せていると思う。

もちろん実際にはそれぞれの要因を1次次元で表すべきでなかったり、単純な足し算の関係ではないことも多いと思うが（例えば車が動かないという問題があったとして要因をパーツごとに分解した場合、上記では上手く表現できない）、少なくとも問題の解決には要因の状態を変化させることが必要であり、またそれぞれの要因には重みがあるということは感じられると思う。
似たようなものをツリー構造で表現されているケースがをよく見るが、ツリー構造では要因に働きかけてその状態を変化させることで問題を解決するという繋がりの部分や、各要因が重みを持っているということを表現できていない。

用語の理解

上の表現で問題解決を捉えた場合に、各用語が問題解決の文脈において何を指しているかを考えていく。

問題

現状と目標の状態の差分でありf(x) - f'(x)のギャップのことである。

課題

問題を解決するために状態を変更することを決めた要因の現状と目標の状態との差分のことである。課題は要因のうち解決可能性やその解決の程度、そして解決した時のインパクト（重み）を踏まえて決められる。

打ち手

要因の状態を変更するための新しい行動のことである。

真の問題の特定

真の問題を特定するというのは、1段上位の課題もしくは問題に目を向けるということである。この行動が必要のなのは、課題は上位から下位まで連鎖しており、上位の課題に目を向けて改めて要因を分解したところ、当初考えていた課題よりもより良い課題が見つかることがあるためである。

問題の明確化・解像度を上げる

問題を要因に分解し、その要因をさらにサブの要因に分解していき、それぞれの重みを考える作業のことである。

真の原因の特定

要因のうち、現状の状態と期待していた状態に差があり、その重みも考慮した時に問題に大きな影響を与えている要因のことである。元々期待していた要因の状態がなければ原因は特定しようがない。

最後に

改めて問題解決そのものについて捉え直し、その中で各用語を理解することができてすっきりした。

このように問題解決自体に関する理解を深めるのも大事だが、実践において最も差が出るのは、どのように要因に分解するかやインパクトの大きい打ち手を思いつくかの部分だと思う。より優れた問題解決を行うためには、その部分で発想の飛躍が必要である。どうすればそういった作業において優れたアイディを生み出せるのかについても改めて考えてみたい。

アジャイル開発についての整理

年末にアジャイル開発について考えたことがあったので忘れないうちにまとめておこうと思う。

アジャイル開発では大事だとされている価値観や行動指針のようなもの(短いイテレーション・カスタマーファースト・計画に従うよりも変化への対応など)が多数存在するが、自分の中でどうもそれぞれの関係性や位置付けが見えておらず腹落ち感がなかった。改めて年末に少し考えてみたところ、不確実性への対処という目的のもとに整理できるように感じたのでそれについて書いていこうと思う。

 

プロジェクトにおける不確実性の問題は下記の2つに分けることができる。

  • A - 予想・計画していなかった悪いことが起きてしまう
  • B - 予想・計画していなかった良いことを起こせない

アジャイル以前の開発手法であるウォータフォール開発は、上記のどちらも苦手としている。

まずAに対してウォータフォール開発は下記の3つの問題がある。

  • 1 - 予想外・計画外の出来事に気づく活動がなく、気づくまでに時間がかかる
  • 2 - 事前の計画に固執し、気づいたあとの計画の変更に時間がかかる
  • 3 - 予想外の出来事が起きた場合に不要になってしまう活動（詳細なドキュメントの作成や緻密なプランニング）に時間をかけすぎる

これにアジャイル開発の価値観や行動指針は下記のように対応している。

  • 1に対して - 顧客との対話・素早いデリバリー
  • 2に対して - 計画よりも適応・短いイテレーション
  • 3に対して - 少ないドキュメント・少ない計画・シンプルさの追求

Bについてウォータフォール開発では、事前に立てた計画の遂行がチームの主な関心ごとであり、チームメンバーから計画外の創造的なアイディアが出ない・採用されないという問題がある。
そこに対してはアジャイル開発では

  • モチベーションの高い個人の重視
  • face-to-faceでのコミュニケーション
  • ビジネスメンバーと開発者のコラボレーション

といった価値観や行動指針で解決しようとしている。

下記は全体を整理した表である。

このように不確実性への対応という目的のもと整理することができた。
自分なりに整理することでアジャイル開発に関するモヤモヤが少しすっきりしてよかった。

アジャイルの考え方は不確実性に向き合うあらゆる場面で活用できそうだが、一方で「予想・計画外の悪いことが起きる」に関してメインで想定されているのは、作ったものがユーザ・クライアントに刺さらないという不確実性であり、そもそも作りたいものを作れるかに不確実性がある機械学習プロジェクトでの適用はどうなるのかについても改めて考えてみたい。

どういったプロダクトがコンパウンドスタートアップのやり方を採用すべきか

以前こちらの記事でコンパウンドスタートアップとは何か、なぜ今コンパウンドスタートアップの採用が増えているかについて書いた。
そちらの記事では主に外部的な要素（顧客ニーズ・競争環境・実効環境）の面からコンパウンドスタートアップの採用が増えている理由を考えたが、プロダクト自体の持つ性質もそこに影響を与えているように思う。

今では当たり前のように言われている"初期のスタートアップはひとつのプロダクトにフォーカスすべき"という（コンパウンドスタートアップとは逆の）考えが常識になっていった2000年-2010年代の代表的なスタートアップのプロダクトといえば、Facebook, Uber, Airbnbなどが浮かぶ。
一方でここ数年で伸びてきたプロダクトはSlack, Zoom, HubSpotなどである。
前者と後者のプロダクト群では、リソースの投下量とプロダクトの価値向上の関係に違いがある。
前者のプロダクト群はユーザの数自体がプロダクトの価値に直接つながるものであり、プロダクトの価値を高めるために開発への投資に加えてユーザ獲得のための投資が必要になってくる。ここに必要な投資は初期のスタートアップが調達できる資金より大きいものであり、全てを投下してもまだ伸びの余地を大きく残すものである。そしてその伸びが指数関数的であることを踏まえると後半のリソース投下の方が価値向上により繋がりやすいとも言える。
一方で後者のプロダクト群はユーザ数の増加とプロダクトの価値との間の関係性は薄く、開発に投資した分がそのままプロダクトの価値として反映されていく。そして開発は本質的に重要な機能の開発から行われるため、開発が進んでいくとプロダクトの価値への貢献は徐々に低減をしていく。前者と比較した場合、比較的に少ないリソース投下の段階で価値の向上が低減していくのである。そして昨今のスタートアップの中にはその価値向上の低減が始まるタイミング以上のリソースを初期から確保できるところが出てきている。

イメージとしては下図のような感じである。

上記を踏まえると、前者のプロダクトにおいては他プロダクトへの投資を行うよりも一つのプロダクトに資金を集中させることが合理的である。
一方で資金調達力の高いスタートアップで後者のタイプのプロダクトを開発しているところでは、一つのプロダクトに資金を集中しても後半ではプロダクトの価値向上の効率が落ちていってしまう。一定以上のリソースを確保できるのであれば、複数のプロダクトに同時に投資することは合理的に見える。そして複数あるプロダクト同士がお互いの価値をさらに高められるコンパウンド戦略を採用することもまた合理的に思える。

コンパウンドスタートアップについて

（noteから移行した記事）

最近よく耳にするのでコンパウンドスタートアップについて簡単に調べて整理した。

コンパウンドスタートアップとは

コンパウンドスタートアップは立ち上げ時から複数プロダクトを同時に作るというものであり、一般的に言われている"スタートアップは初期ひとつのプロダクトにフォーカスすべき"という言説に反したやり方である。
ただし、単に複数プロダクトを立ち上げるというものではなく、下記２つの特徴を持っている。

- 特定のデータ（従業員データなど）を中心にその周りにプロダクトを立ち上げる
- プロダクト間の連携を価値としている。（このアイディアを提唱したRipplingのCEOは“the product is the integration”と発言している）

なぜいまコンパウンドスタートアップなのか？

これには顧客ニーズ、競争環境、実行環境の3つのポイントがある。

顧客ニーズ
一般にプロダクトのバンドル->アンバンドルは繰り返すと言われている。
例えばバンドル化されたプロダクトが支配的なタイミングでは、1点突破でより価値の高いポイントソリューションが複数出現し、それぞれの領域でバンドル化されたプロダクトを置き換えていく（アンバンドル化）。しかし、一旦その置き換えが進むと、各ソリューション間での連携の課題感が増え、バンドル化したプロダクトへのニーズが増える。というのを繰り返すということである。
ここ十数年はオンプレで導入されていたバンドルプロダクトをクラウドSaaSのポイントソリューションが置き換えてきていた。
特にコロナ初期はポイントソリューションの導入が一気に進んだ印象である。しかしその後の調査の中で、各ソリューション間の連携に摩擦があり、結局業務が効率化されていないと感じている企業が多数いることが分かっており、今は揺り戻しでバンドル化へのニーズが高まっている。

競争環境
競争環境の高まりからシングルプロダクトのMoatについての懸念があり、何かしらの形でMoatを高める必要が認識されるようになった。Microsoftによって苦しんでいるSlackやZoomがよく出る例であるが、シングルプロダクトでは、市場が大きくなったタイミングでBig Tech等が参入し苦戦を強いられてしまう可能性がある。コンパウンド化により、より強固なMoatを築くことができる。

実行環境
一方でコンパウンドスタートアップはやろうと思えばできるというものではなく、２つの変化がコンパウンドスタートアップを支えている。

① 資金調達環境の変化
多少の上下はあれど基本的にスタートアップの資金調達環境がよくなっていっている。潤沢な資金を必要とするコンパウンドスタートアップに重要な要素である。

② 開発効率の向上
AWSやGCPといったクラウドの出現による開発効率の向上も、潤沢な資金を必要とするコンパウンドスタートアップを可能にしていると思われる。

コンパウンドスタートアップのメリット

  1. プロダクト間のスムーズな連携を実現可能
    まさに顧客側が困っている問題であり、in-houseで複数プロダクトを開発することで解決できる問題である。

  2. 複数プロダクトで同一のUX/UIを提供できる
    同一もしくは似たUX/UIを提供できるので、顧客側の学習コストをさげることができる。Microsoftのoffice製品が思い浮かぶ。

  3. 安価な値段で提供できる
    バンドルで売ることができ、かつ内部で共通モジュールを使いながら開発効率を挙げられるので、1プロダクト単位でみると競合よりも安価で提供することができる。

  4. 精度の高いMLモデルを構築することができる
    特定のデータを中心にプロダクトを立ち上げているので、関連したデータが溜まっていきモデルの学習に寄与する。MLの活用が進む中で大きなメリットとなる。

コンパウンドスタートアップのデメリット

デメリットは基本的にはその難易度である。
スタートアップはフォーカスすべきと言われ続けていたのは、資金面で劣るスタートアップが勝つには１点突破しかないからである。そこを分散させるというのであれば、より潤沢な資金を集めそれをより効率的に使う必要がある。資金調達環境が年々良くなり、開発効率が向上しているからとはいえ、難易度はまだかなり高い印象である。

上記の課題をクリアするために

資金調達面
立ち上げ初期から潤沢な資金調達を行うのはかなり難しく、コンパウンド戦略を選択したスタートアップ、RipplingやLayer Xなどはどちらも連続起業家であり、一つ前の起業を成功させている。そうでなければ必要な量の資金を集めるのはかなり難しいように思う。

資金効率面
効率的な開発を行うことができるように、複数プロダクトから使用できる共通基盤の開発を行っている。これは先述した顧客側のインターフェースに現れる部分には限らない、裏側でのみ使われるものも含まれている。ここをいかにうまく行えるかが一つポイントになりそうな印象である。

所感

ざっと調べただけの所感だが、このモデルは本当に上手に作らないといずれ開発効率が落ちていきそうな印象である。共通モジュールを各所に作るということは、外部環境の変化に合わせて特定のプロダクトのみを変更したくなったときにモジュールとの互換性のためにできないとか、もしくは共通モジュールをアップデートするのに影響範囲が尋常じゃないみたいなことが起きる可能性がある。
あらゆるスタートアップが採用すべきという類の戦略ではなく、上述した4つのメリットが最大限活きる領域（例えばBtoB SaaSなど）で選択を検討すべきものだと感じる。

スタートアップはニッチから始めるべきか

（2023/2/18に書いたnoteから移行した記事）

最近こちらのtweetを目にして、①の箇所が一般的に良いとされているスターアップのアイディアとの違い気になったので少し思考を巡らせてみた。

スタートアップはニッチな課題からスタートすべきと言われる理由

一般的にスタートアップはニッチで深い課題からスタートすべきだと言われている。

例えばPaul Grahamも理想的な課題の狭さと深さについてこちらのブログで井戸に例えて説明している。

なぜ井戸のような課題が良いのだろうか

スタートアップの課題を下記のようにカテゴライズしてみる。

1の領域は問題が明らかであり解決も簡単であるが、それゆえにたくさんの競合・サービスがすでに存在している。魅力的で分かりやすいため資本を持った大手も入って来やすい。
そういった競争を避けるためにスタートアップはその他の領域に出ていく必要がある。
他領域では2が一番挑戦しやすく魅力的に映る。特別な専門性や技術が不要だからである。アイディア一本で勝負できる可能性がある。おそらくスタートアップの数としては2>3,4という感じだろう。
そして領域2において課題を見つけるための１つの方法が、井戸の形をした課題を見つけるというものである。範囲が狭いがゆえに見つかりづらい。
上記のような必要性と実現可能性の観点から多くの起業家は、ニッチ領域を見つけるように言われるのだろう。

ちなみにMVP検証において課題ニーズ検証が一番大事という言説を割と見かけるが、これも上記の構造が原因だと思われる。3が多ければ技術の不確実性に言及したものが増えるはずだ。

スタートアップはニッチな課題からスタートすべきか

上の図からも分かるように必ずしもそうではない。
カミナシのCEOの方の話に出てくる下記の方法も十分にあり得る。（領域3に当たるもの）

課題で尖りすぎず、取り組む市場規模は大きい方がいい。課題は普遍的で大きなものに取り組み、ソリューションで尖るのがいい

*1

どの領域を選ぶべきか

カテゴリごとの良し悪しは無く、どの領域にもそれぞれのリスク・不確実性があり、それを認識しておくことが大事だと思う。採用すべき人材や力をいれるべき検証項目が変わってくる。

領域2であれば、選んだ課題からその先の広がりがないリスク、見つけた問題が実は問題ではなかったというリスクがあり得る。
領域3であればソリューションを作りきれないというリスクがある。
そして4にはその両方のリスクがある。
もちろん4が良くないということではない。結局はバランスや不確実性の量の問題である。個人的には最近日本でもよく話題になるvertical SaaSは領域4に位置するイメージだが（課題の発見がそのドメイン外からは難しく、かつ解決が難しい）、選び方次第では不確実性の量が2や3より少ないケースもたくさんあると思う。伸びているvertiacal SaaSは、executionのハードルは高いが使っている技術自体はそこまで目新しくないものというケースが多い印象である。

今後どうなるか

おそらく最近のAIブームで、少なくとも一時的には3の領域にトライするスタートアップが増えるのではないだろうか。
その際には課題ニーズ検証よりも技術検証（作りきれるか）という部分によりフォーカスが移るだろうと思われる。

自分も仕事ではAR,AIを扱っているので、課題ニーズのほうで不確実性を取りすぎないように気をつけたい。

*1:https://twitter.com/coral_capital/status/1625828520357421056