「スタートアップの前にまずは受託開発をしたほうが良い？」というよくある相談とその回答

この1, 2年、「いずれ急成長型のスタートアップを始めたいと思っているが、最初からスタートアップをするべきか、それとも最初は受託ソフトウェア開発から始めるべきか迷っている」という相談を学生・若手の方々から受けることがかなり増えました。

最近では週2回ぐらいの頻度で受けることもあり、類似した話をすることが増えてきたので、ブログ記事として残しておきます。

「スタートアップから始めるべきか、受託ソフトウェア開発から始めるべきか」への回答

「スタートアップから始めるべきか、受託ソフトウェア開発から始めるべきか」への回答は、場合にもよりますが、「ハイグロース・スタートアップを目指しているのなら、受託ソフトウェア開発での起業を経由するよりも、最初から副業的にプロダクトを作ったり、ハイグロース・スタートアップを直接始める道のほうが良いのではないでしょうか」というのが個人的によく行う回答です。

ただしこの回答にも様々な前提や条件があります。

「受託ソフトウェア開発で起業がしたい」のであれば、その起業はやれば良いと思いますし、「ある程度のお金を儲けたい」というのであれば受託ソフトウェア開発は選択肢の一つだと思います。その判断自体に反対したいわけではありません。

ただ、最終的な目的に「いずれハイグロース・スタートアップをやりたい」という言葉が入ってくると、少し前提が変わるため、その際に受託を挟むことは目的と沿わないのではないか、と感じることが多いため、本記事をまとめています。

目的と沿わない、と思う理由を以下で解説します。

受託ソフトウェア開発のステップを挟む目的

スタートアップを志していて、最初は受託ソフトウェア開発（以下、受託開発）から始めたほうがよいという相談が来た際には、基本的にその理由をお伺いするようにしています。そしてその理由でよくあるのが、以下の 7 つです。

1. 探索のため
2. 会社のキャッシュのため
3. 個人の資産のため
4. 製品開発のため
5. 能力開発のため
6. 経歴のため
7. 参入のため

確かにそれらの理由は一見すると「そうかもしれない」と思えるときもあるものの、一方で、それぞれで少し目的と手段にずれがあったり、回り道のように聞こえるときもあります。その結果、「それならスタートアップを直接した方が良いのでは」という回答になることが多くなります。

それぞれの理由に対する回答と、その理路は以下の通りです。

(1) 探索のための受託開発

「アイデアや市場のニーズなどの探索のために受託から始めようと思っている」と相談を受けることがあります。

理由としては正しく聞こえはするのですが、その目的であれば、他の手段で代替できないかは考えた方が良いように思います。

たとえば、どういったニーズがあるかは顧客インタビューなどの代替手段でもある程度把握できます。また、業界知識を身につけたいのであれば、受託開発のような外部からの関わりよりも、業界で働いた方が良い洞察が得られるでしょう。アイデア全体であれば、他の起業家等に相談したりするのも一つの手です。

受託開発が最も効率の良いアイデアやニーズの探索手段だと結論づけてその選択肢を採っているのであれば良いとは思いますが、他の手段の方がコストパフォーマンスに優れていることも多いものです。受託開発はかなりの労力がかかる探索手段なので、探索目的であれば他の手段も積極的に検討しても良いように思います。やるのであれば、せめて、「どの市場」で戦うのかを決めたり、「どの技術」を使うかはある程度ピン留めしたうえで、探索していくことをお勧めします。

それに気をつけたほうが良いのは、受託開発自体で分かるニーズは「個社のニーズ」かつ「今のニーズ」を反映したものであり、さらにPoCなどの受託開発なら「ぼんやりとしたニーズ」という場合も多いことです。これらはプロダクトを作っていくために必要なニーズと少し異なります。

ハイグロース・スタートアップを狙うときには、「数年後の市場」の「複数社で共通のニーズ」を見つける必要があります。その中でも、足元では「バーニングニーズ」が大事になってきます。これらが受託で見つかるかというと、そういうときも勿論ありますが、必ずしも直線的につながるわけではありません。

それにプロダクト型のハイグロース・スタートアップ狙いの人たちには、研究開発系のPoCの案件を受けることはあまりお勧めしていません。特に大企業の研究開発チームや新規事業部からのPoC案件は『偽のトラクション』になることも多いからです。多くの方々は真面目にやっていらっしゃるものの、研究所や新規事業部のニーズはどうしても、スタートアップ側が探したい事業側の実ニーズと乖離があることも多くあります。せめて事業部が欲しているリアルな案件に関わらなければ、最終的な製品を作るための洞察は得られづらいでしょう。

例外として、「最先端の課題を持つ最先端の顧客」に出会えるのであれば、多くの会社が持つ数年先のニーズを知り、その解決の手段を先に知ることができるかもしれないチャンスだと思います。Facebook社内のタスク管理ツールがAsanaになったように、です。また「大きなことを為そうとしている顧客」であれば、それについて行くことで漁夫の利を得られる可能性もあります。ただそうした顧客を意識的に選ぶ必要があります。また、そうした案件が降りてくるかはそれなりの幸運が必要で、運に託すよりは自分の努力でなんとかなるインタビュー等で探索した方が良いのでは、とも思います。

(2) 会社のキャッシュのために受託開発から始める

会社としてある程度安定したキャッシュフローを作るために受託開発をする、という人もいます。それも一つの選択肢だと思います。

ただ、受託開発チームが回り始めた後に製品開発チームを作ると、異なるゴールを持つ2つの組織ができることになり、組織マネジメントが難しくなるという点は予め押さえておく必要があるでしょう。たとえば、キャッシュを生み出す受託開発チームと、キャッシュを溶かす製品開発チームの仲が悪くなることはしばしば聞く話です。また、受託開発に必要な人材のマインドセット・スキルと、製品開発に必要な人材のマインドセット・スキルは少し異なるため、意外と人材の配置転換がしづらい点にも注意が必要です。そうした組織運営のリスクには留意した上で進めた方が良いでしょう。

稼ぐ事業を作った「後」に製品を作るのではなく、稼ぐ事業と製品開発とを「並行」して同時に行う会社もあります。「会社は社長が受託開発やコンサルで稼ぎ、並行して誰か他の人に製品開発をしてもらう」というのがよくあるパターンです。そういう社長業をやってでも成し遂げたい何かがあれば問題ないのですが、モチベーションや社長の能力開発という観点では少し不安定のようにも見えます。

将来VC等の外部投資家を入れることを想定しているときにも注意が必要です。VCは製品の急成長に賭けたいことが多いため、受託事業があることが逆にリスクに見えるときがあるからです。場合によっては、製品開発に集中してもらうために、分社化等をお勧めされることもあるかもしれません。

なお、ずっと自社の自己資金や借入で資金をやりくりしながら、時間をかけて徐々に会社を大きくしていく戦略であれば、足元のキャッシュを稼ぐ事業を作るのは良い一手だと思います。それも素晴らしい事業の在り方の一つですし、ほとんどの事業はその方が向いているように思います。

ただ、中長期的に同一の会社で、出資での資金調達を考えているのであれば、最初から製品開発に集中した方が良いのでは、と考えています。特に10年ぐらい前とは違い、シード段階のリスクマネーの供給は増えているので、最初からスタートアップという選択肢は採りやすくなっているのでは、と思います。

(3) 個人資産のために受託開発から始める

個人の資産を作ってから、二度目の起業などで大きな挑戦をするために、受託開発会社を作って売却（イグジット）したい、という話を聞くこともあります。個人的なセーフティネットがあることで、大きな挑戦ができるというロジックや、そうしたい気持ちはとても分かるので、こうした道を検討するのは一つの手だと思います。

ただ、受託開発企業を売って得られる想定資産額と次の挑戦に必要な金額、そしてイグジットまでにかかる時間と、そこからの時間についてはやや誤解があるようにも感じています。

受託ソフトウェア開発の企業は、ある程度の利益が出ている状態で、おおよそ売上と同じぐらいの企業価値で売りに出ることが多いようです。受託で1億円の売上を達成する会社を売却しても、得られる個人資産は1億円程度です。

一方、ハイグロース・スタートアップを作ろうとしたら、多くの場合、数十億の資金が必要です。仮に1億円の個人資産があれば、確かにシード投資分ぐらいは自己資金のみでいけるかもしれませんが、いずれにせよシリーズA以降は外部からの資金調達は必要になります。

また、そもそも数億円規模の受託開発の会社を作るのは簡単ではなく、M&Aも簡単に行われるわけではありません。タイミングもかなり買い手依存です。それに受託開発企業を買収するのは、多くの場合、資産というよりは人材獲得が目的です。そう考えるとM&A後にはキーマンにそれなりのロックアップ期間が発生します。

こうしたことを考えると、うまくいったら資金はほどほど得られるかもしれないけれど、その期待値はあまり高くなく、時間という観点だと、企業成長にかかる時間と売却先の不確実性、売却後にかかる時間は思っている以上に長くなります。それに使う年数を考えたら、その時間を買って経験を得て自己成長するためにも、多少の希薄化はしても良いと考えて、VC等から調達した方が良いのでは、と答えることも多いです。

(4) 製品開発のために受託開発から始める

製品開発の一環のために受託開発をするというのも、もっともらしく聞こえるのですが、多くの場合、受託開発で依頼される機能と、製品に必要な機能は多くの場合異なります。そのため、相当意識して受託開発案件を取らなければ、作りたい製品に活かせる機能というのはなかなか作れません。

また、受託開発をしていると、自分の時間の使い方などがどうしても受託側に偏ってしまって、自社の製品開発に時間をほとんど使えない、というのもよく聞く話です。受託開発はそんなに手離れはよくはありません。PMを自分がやり続けなければならない状況だと、なかなか製品開発に時間を割けないという悩みはよく聞きます。

「いやいや、自分たちは違う。うまくやれる」と言う人も多いのですが、どうしても同じような顛末に至ってしまっているように見えます（『ファスト＆スロー』で紹介されている教科書の執筆プロジェクトのように）。

ただ、戦略的にうまくやっている会社もあります。自分たちの製品開発が進むような受託案件を取ったり、そうした受託案件になるよう、顧客側を誘導するような手練れの人たちです。最終的な製品像が見えていて、製品開発と受託開発がアラインしている状況を作れるなら、とても良い選択肢だと思います。

(5) 能力開発と自己成長のために受託開発から始める

ビジネス経験を積み、自己成長をして、次回の起業時に大きな挑戦をするために受託開発から始める、という話も聞きます。

確かにビジネス経験は積めますが、気をつけてほしいのは、受託ソフトウェア開発で身につく経営能力は、あくまで受託ソフトウェア開発の経営能力ということです。

受託開発で培われる筋肉と、製品開発で培われる筋肉は少し異なります。他の人の言葉を借りれば「受託開発と製品開発は、スポーツという枠では一緒なものの、野球と水泳ぐらい違う」ということです。

より具体的には、受託開発では「特定の顧客の声を聞く」ことと、それをうまく技術的な言葉に代えて、それに合った開発をすることが主です。一方、製品開発は「市場の声を聞いて、自分の仮説に基づいて製品を通り、市場に問う・売る」ということを行います。ソフトウェア開発をする、という点では一緒なものの、事業側の動きは色々と異なります。

起業して組織がそれなりには大きくなったのであれば、「大きな組織をマネージする」という能力は培われますが、一方で製品を持つ事業の組織マネジメントと、受託の組織マネジメントとはやや異なります。

むしろ、資金の利用やリスクの取り方という点では、受託開発で培った考え方を一度アンラーンする必要な場面も出てくるでしょう。

人は環境に適応していくものなので、受託開発を引き受ける側に立つと、優秀であればあるほど、その立場に最適化していきます。それに経営者同士のネットワークも、同じ業種の人と付き合うことが増えるので、自分の身を置いた場所に即した能力開発が加速していきます。とある大企業に身を置いた友人が、その企業の文化に染まって、その企業のやり方に最適化されていく（善し悪し両方の面で）、というのを傍目で見た人も多いのではと思いますが、それは起業をしても同様に起こることです。

なので、もし能力開発のステップを挟む場合は、本当にその経験が次の挑戦につながりそうかをきちんと考えた方が良い場合が多いように思いますし、スタートアップをするために能力開発をしたいのであれば、最初からスタートアップの道を選んだ方が良いのでは、と思います。

(6) 経歴のために受託開発から始める

受託開発を経て売却したあと、シリアル・アントレプレナーになれば、大きな資金調達ができるから、そうしたトラックレコードを作りたいと思っている人もいるようです。しかしそこにも誤解があるように思います。

大きな資金調達をしているシリアル・アントレプレナーの諸先輩方は、プロダクト型のハイグロース・スタートアップを経験し、その会社で数十億円を集めてグローバルや大きな市場で戦った経験があるからこそ、2回目、3回目のスタートアップを始めるときに最初から数十億円を最初から集められています。何でもいいから起業してシリアル・アントレプレナーという看板を得たからお金を集められたわけではありません。看板ではなく、その内実である過去の経験こそが評価されています。

たとえば、受託会社で起業したシリアル・アントレプレナーと、商社等でグローバルなビジネス経験をして、その業界について十分なネットワークのある人とを比べると、後者の方がより大きな資金調達ができる可能性すらあるように思います。それに「受託開発でスモールイグジットできたから、次はグローバルでのディープテックで成功できます」と言ったとして、それをそのまま受け取ってくれる人はそう多くはないでしょう（いないわけではないですが）。経験を活かそうにも、両者の事業領域が結構遠いからです。

受託開発領域での起業の経歴が、プロダクト型のハイグロース・スタートアップで高く評価されるかというと、必ずしもそうではない、ということです。実際、受託ソフトウェア開発の起業経験の経歴がある人が応募してきても、私たちのようなハイグロース・スタートアップ支援のプログラムでは別段プラスにはなりません。

なので、どのような経歴が次の挑戦に活きそうなのかはきちんと考えた上で、受託開発を選んだほうがよいのかなと思います。

(7) 参入のために受託開発から始める

何かしらの戦略を持って、市場の参入のために受託開発から始めることが有効なときがあります。この場合、きちんと事業戦略のステップを考え、その受託案件がその次、さらにその次にどうつながるかを説明できる状態である必要があるでしょう。つまり、なぜ受託で入るのか、その角度（アングル）で入ることで何が得られるのか、をきちんと整理できているかどうかです。

「まずは商流に入ることで、そこからニーズを見つける」というのも有効なときもあります。今後十数年の間に地殻変動が起きそうであれば、それは一つの選択肢です。特に10年を超える長期スパンでその業界にコミットでき、かつ、しばらくの間、他の競合が出てきそうにないのであればなお有効だと思います。

ただ、受託開発でのソフトウェア領域に参入してからハイグロース・スタートアップを狙うのは、昔ほどお勧めできるわけではなく、この数年で徐々に難しくなってきているような印象があり、その点は注意してください。スタートアップに向いた領域・戦略の変化などがその背景としてあります。

「小さな成功」よりも「大きな挑戦の経験」

以上、相談の中でよくある理由とそれに対する反応を書き連ねてきました。

まとめていえば、大きな挑戦をするときにあると良い経験や経歴は、一般的な起業経験や成功経験ではなく、大きな挑戦や大きなビジネスをした経験・経歴です。そして多少自己の資産を作ろうとも、大きな挑戦をするとしたら外部の資金を活用する必要はいずれにせよ出てきます。なので種銭となる自己資金を大きくする方法よりも、他人の資金をどう獲得するかのスキルを伸ばした方が結果的に良いように思います。

そうした個人の能力開発という観点でも、自分の人生の時間を使って自分をどう成長させるか、ということを考えたとき、特定の領域での能力開発が、別の領域ではプラスにならないどころか、逆にマイナスになる可能性もあるため、それにも注意が必要です。

こうした観点を考えて、最終的にハイグロース・スタートアップのような大きなことをしたいのであれば、「小さく成功してから大きなことをする」のではなく、最初から大きな挑戦をした方が良いのでは、と答えることが多いです。

そのほうが仮に挑戦して失敗しても、経験は得られますし、その領域での製品アイデアの探索ができます。その過程で必要な人脈も得られるでしょう。それに大きな挑戦をする人は希少なので、応援してくれる人は多くなります。

そうした経験を積める第一歩を考えた結果、その結論が受託開発なのであれば、自信を持ってその道を選ぶと良いと思います。

（全体最適の観点）

現状、スタートアップに適した良いアイデアが見つけづらくなっているので、こうした相談が増えているのかもしれないと思っています。

ただ、今後の日本の産業のことを考えると、優秀な人材の多くは機会の探索へと配置した方が公益は最大化されるのでは、と個人的に思っています。一方、受託開発はあくまで現在のニーズに基づく作業であり、将来の大きな製品へとつながることはそう多くはないように思います。特に受託の案件は国内大企業が多いのも、短期的な外貨獲得という観点では課題です。多くの場合は国内大企業から国内中小企業への所得移転の効果となるでしょう。

そして受託開発は労働集約のビジネスです。一つの受託会社が作られると、そこに優秀な人材も大量に確保されてしまいます。その結果、優秀な人がさらに探索に配置されなくなっていく、という別の影響もあるように思います。

個人の幸せを追い求めることは個人の自由なので良いと思いますし、その経過の中で経済的効果を生むのは素晴らしいことです。一方で今後の日本の産業のことを考えたとき、優秀な人がより大きな挑戦を最初からしていくようなインセンティブ構造を作っていく必要があるように思いますし、そうした大きな挑戦をする人たちにこそ、支援を増やしていったほうがよいだろうと思います。

（小さな挑戦への支援をなくせというわけではなく、あくまで支援の強弱の話であることには注意してください。よく誤解されるので…）

まとめ

「起業をしたい」というのであれば、受託ソフトウェア開発は間違いなく一つの選択肢です。受託開発は、「目の前の分かりやすいニーズ」があり、コスト構造も分かりやすいビジネスです。うまく技術的な知識のアービトラージを活かせば、ある程度稼げるでしょう。その道を選ぶこと自体を否定しているわけではないということは、再度強調させてください。

ただ、この記事で書いているのは「ハイグロース・スタートアップを見据えたときに」、という前提を置かれたときの話です。その場合、受託開発をうまく使えば良いこともたくさんありますが、一方で、受託開発が回り道である可能性もそれなりに高いのでは、と考えています。

（同様に、ハイグロース・スタートアップが常にベストな道かというと、そんなこともありません。）

大きな物事を成し遂げるためにステップを踏むことは大事ですが、そのステップが本当に次の挑戦へとつながっているかを確認することも大事です。それを考える際に、本記事が参考になれば幸いです。

もし選択に迷ったときは、周りの様々な人の意見を聞きながら進めてください。そのとき、近くの人の意見だけではなく、少し遠くの人の意見もセカンドオピニオン的に聞いてみることもお勧めです。近くのコミュニティには同じ意見の人たちしかいないことも多いからです。私のこのブログの意見も一意見でしかありません。

ただ、もし大きなことへと挑戦したい、という人はぜひ支援したいと思っています。Climate Tech で、世界の GHG を 1% 削減するような事業をお考えであれば相談に乗れますし、応援もできます。何かあれば連絡してください。

『需要家のファーストペンギン』への支援

シリコンバレーがソフトウェア業界で強い理由の一つは、優れた需要家がいるからだと思っています。

シリコンバレーには大企業からスタートアップまで、ソフトウェア業界の最先端を走る人たちがたくさんいます。そうした人たちは事業上を進める中で、最先端の課題にいち早くぶつかります。

もしスタートアップがその課題に気づき、課題解決につながる製品をうまく作ることができれば、その製品は売れます。顧客企業が大きくなればなるほど、製品の売上げも上がり、顧客と一緒に自分たちも成長していけますし、その他の企業にもその製品を売れるようになり、さらにスタートアップは成長できます。

同様に、アメリカの防衛産業の強さや先進性も、アメリカ軍という先進的な顧客がいるからでしょう。

「必要は発明の母」と言われますが、「質の良い必要」を生むことが「質の良い発明」へとつながる、ということです。そして、以前記事にもまとめましたが、顧客開発やリーンスタートアップの方法論が「アメリカで特に」有効なのは、顧客が優れているからという面も大きいでしょう。

イノベーションというと、私たちは研究開発や人材などの供給サイドに目が行きがちです。しかし同時に、どのように質・量ともに優れた需要を作るのか、という点も重要です。

需要を作り、安定化させる政策

特に「グリーンの領域」において、質・量ともに優れた需要を作り出すことは大切だと考えています。

ただ、IT等とは異なり、このグリーンの領域での需要は自然に任せていれば生まれるというものではありません。政策的に生み出していく側面がかなり強くあります。なぜなら、グリーンではない代替品のほうが経済的コストだけを見たときには費用対効果が高いため、営利企業の多くはグリーンではない製品を購入するからです（ただしその分、気候変動が進む等の社会的なコストが発生するため、政策的な是正が必要です）。

そうした問題を解決しようと、世界中で規制を含めた様々な需要喚起政策が行われていますし、日本でも需要の量、需要の金額、需要の予見可能性などは政策ですでに多くの手が打たれています。

より具体的にはたとえば以下のようなものが、エネルギー領域の需要側の政策のツールセットとして挙げられます。

https://bipartisanpolicy.org/report/demand-side-support-for-energy-technologies/

これらも有効であるように思いますし、必要なのは間違いありません。

一方、支援の現場にいて感じていることとして、もう少し支援があっても良いと思うのは、スタートアップの製品を「最初」に買ってくれる需要家側のファーストペンギンを生み出す政策です。

最初の需要家をうまく作り、成功させることで、次々と買い手が現れ、上記のような政策も効果的に使われ始めるのだろうと思います。

「最初の需要」を作る難しさ

顧客が「最初」に製品に手を出すインセンティブはそう多くはありません。二番手や三番手のほうが、リスクも低く、製品のコストも安いことが多いからです。最初のものだからこそ、調達への安定性も不安でしょう。

ITのスタートアップの世界では、「バーニングニーズを見つける」と言われます。しかしグリーンのような領域では、グリーンプレミアムの乗っていない安い代替品があると、バーニングニーズには中々なりません。

実証実験は最初の需要と近い概念かも知れませんが、実験期間が終わったら使われなくなる実証実験の需要と、少量であれそれ以降も使われるものとでは、投資家から見たときの需要の質も異なります。実証実験をできたからといって、そこに需要があるわけではないからです。実際、POC地獄という言葉があるなど、実証実験で留まるケースは多くあります。

つまり、初物の製品の最初の買い手になるには、顧客側に相当の課題感か、相当のインセンティブがなければなかなか最初に手をつけようとは思わないということです。逆に、最初に手を出してくれる顧客は相当のリスクテイカーでもあります。

ここをどうしていくのかが需要政策における一つの山なのだろうと思います。それはある意味、「イノベーティブな需要家をどう作るか」、そのための支援は何かという問題です。

最初の需要をどう作るか

できれば対策案まで書きたかったのですが、最初の需要を作るための政策を調べてみたものの、あまり良いアイデアは見つからなかったため、問題意識だけまとめておきます。

一応ラフなアイデアとしては以下のようなものがあります。ただ、あまり良いものではないと感じているので、海外の良い事例があればぜひ教えてください。

称賛する

まず称賛することです。イノベーティブな需要家をきちんと称賛することは、地味ですが多少なりとも有効であるように思います。

ただ、最初の需要家になった、というブランディングが有効な市場かどうかはまた別に議論する必要があるでしょう。

マイクロソフトやGoogleなどは、グリーンなエネルギーを調達するために、まだ発電できていないエネルギー系のスタートアップと購買契約をしています。その背景や契約内容は詳しく分かりませんが、豊富な資金という背景に加えて、グリーンなエネルギーが将来足りなくなる可能性と、ブランドとしての方向性があるようにも思います。

投資と組み合わせる

Vargas Holdingの生み出したスタートアップがやっているように、需要家が投資家にもなる仕組みも一つの方法であるように思います。うまくいけば製品が手に入るだけでなく、投資リターンも得られるからです。もし失敗すれば購買しなければ良く、ダウンサイドは投資したお金のみという契約もできるでしょう。

割引にも使える補助金？

一般的な需要家支援と、ファーストペンギンの支援は異なります。ファーストペンギン向けには多少割り引いても提供できるようにしておく、という補助金を供給者側に枠として渡しておくのもありうるのではないかと思っています。

実際、IT系だと、初回の顧客には大幅に割り引いて実績を作る、ということをしていたところも聞いています。しかしグリーン系ではそれがしづらい状況です。なぜなら、製品を作ることにIT系と異なり相応のコストが発生することからです。さらにスタートアップであれば割引の原資となる資金がありません。

現在の補助金は基本的に研究開発にしか使えませんが、その差額をスタートアップの持ち出しでできる補助金の枠を設定しておくことで、需要家側にもインセンティブになるかもしれないと思っています。

イノベーションバウチャー？

海外のイノベーションバウチャーは主にSMB向けのサービス購入（R&Dやサポート）の施策で使われているように見えますが、これをグリーンな製品の購入にも使えないか、という案になります。

先んじて需要を生み出したい特定の領域や企業の製品のみ対象にしておき、1年ごとにバウチャーの購買額が下がっていくようにしておけば、早く購入するインセンティブが作れるかも知れません。

まとめ

昨今は日本国内の需要の弱さも一因となり、日本企業でも多くの会社が海外で研究開発や生産をし、海外で得た利益を日本に戻さずさらに海外に再投資する動きが盛んになっていると聞きます。これは企業として合理的な行動なので非難するべきではありませんし、環流のための減税などで多少は戻ってくるのかも知れませんが、日本国内に需要の量・質がなければ大きな流れを変えることはできないでしょう。

人口減によって需要の総量が下がってくるのは避けられないと思うので、せめて需要の質、特に先進的な需要をどう作り、研究開発をこの地に誘引するのかを考えたほうがよいのだろうと思います。そのための政策的なイノベーションを試す場として、グリーンの領域は様々なトライアルが行われても良いのでは、と思う次第です。

どの摩擦をなめらかにするか

課題解決をしようとしたとき、私たちは根本的な原因ではなく、つい見えやすい課題に目を向けてしまします。その中でも目を向けてしまいがちなのが摩擦です。

その摩擦は優先度の高い摩擦か

たとえば、「コンテストへの応募のプロセスがスムーズではない」といった『摩擦』は確かに課題です。ただ、多くの場合、「その摩擦を減らすこと」が優先度の高い課題であることは少ないよう思います。コンテストであれば、応募が少ないのはそもそもの賞金や対象などが悪いことのほうが多いでしょう。

しかし摩擦はザラザラして気持ち悪く、課題としても分かりやすくて目につきやすいので、私たちはついそれを解決しようとしてしまいます。コンテストであれば、コンテストの設計そのものに手をつけるのではなく、Webサイトの改善や文言の調整などに取り込むなどです。

もちろん、全体の流れの中で最も摩擦が生まれている部分であれば、その摩擦を減らすことは大きな課題解決につながります。ボトルネックの部分をなめらかにして、全体のスループットを上げることになるからです。

しかし、すべての摩擦がボトルネックなわけではありません。

だから、私たちが摩擦を感じたときは、「その摩擦は全体の中で優先度の高い摩擦(課題)なのか」を考える必要があるように思います。

(1) 全体

「その摩擦は全体の中で優先度の高い摩擦(課題)なのか」と書きましたが、また、気にするべきことは「全体」です。どこからどこまでを全体として捉えるか、いわばスコープをどこからどこまでにするかによって、どこが一番ボトルネックになっているかは変わるからです。

そしてスコープをどう捉えるかは、目的によって異なります。

スタートアップの政策であれば、『投資家の利益を最大化する』ということを目的にすればスコープは投資家の利潤の最大化になり、その中で最も摩擦がある部分を解消すれば良いでしょう。

しかし『スタートアップの数を最大化する』ということを目的にする場合は、スタートアップが生まれるサイクル全体をスコープとして見てみる必要があります。その場合、投資家の感じている摩擦は、最も重要な摩擦というわけではないかもしれません（その可能性もあるかもしれませんが）。

ただ、そうした全体の中の一つの摩擦も課題であることに変わりはなく、また投資家の声は大きい傾向にあるため、投資家の摩擦が本来よりも大きく聞こえてしまい、その課題を解こうとしてしまうこともあると思います。政治資源が豊富である場合は、そうした課題を解いても良いと思いますが、政治資源に限りがある場合は、やはり本当に重要な摩擦の部分を解消するために資源（時間や人力）を使うべきでしょう。

(2) 順序

とはいえ、最初から最もボトルネックとなっている部分にアプローチできないこともあります。そのときは、できるだけ最短の順序で、ボトルネックに対してアプローチをすることを心がける必要があります。

一個目の摩擦を解決すれば、次の摩擦を解決でき、そのあとにボトルネックとなっている摩擦が解決できるのであれば、最初の摩擦は小さなものでも良いかもしれません。

また多くの場合は、たった一つの原因があるわけではなく、複数の問題を同時に解く必要があることもあるでしょう。しかし、それでもやはり順序は意識する必要があります。

もし順序を考えられなければ、全体を把握できていないということです。そのときは、その全体を把握するように努めることが、最初にやるべきことかもしれません。それがなければ、手当たり次第の摩擦を解いていくことになります。

(3) 種類

もう一つ気をつけたいのは、「その摩擦は本当に解決するべき摩擦か」ということです。特にこれまでとは異なる種類の課題に取り組むときや、一桁大きな課題に取り組むときは、単に摩擦を解消し続けるだけでは解決に辿り着けず、構造自体を大きく変えるような取り組みが必要とされるのだろうとも思います。

工場の生産ラインの摩擦を解消すれば確かに商品の生産量は増えます。しかし、もしこれまでと異なる商品が市場から必要とされていたら、その摩擦の解消によって得られるのは大量の売れない商品、大量の在庫です。本来やるべきなのは、摩擦の解消ではなく、違う種類の製品を作ることです。

摩擦は目につきやすいものの、本当に解決するべき摩擦かどうかは、立ち止まって考えた方が良いでしょう。

まとめ

摩擦の一つ一つが課題であることに疑いはありません。しかし、限られた資源の中では、すべての摩擦を解消することもできません。だからこそ、摩擦は摩擦として把握しつつも、優先順位をつけて取り組む必要がありますし、摩擦を解消するべきかどうか（＝生産するものそのものを変える必要があるかどうか）も考える必要があります。

もし摩擦を解消したほうがよい、というときにも、どのようなスコープで全体を把握して、どのような順序で取り組むべきか、を考える必要があるように思います。

課題解決の基本とは言え、私も時折忘れてしまいがちです。ただ、少し政策関係のことを見ていて少し思ったところがあったので、メモがてら書いてみました。