2024.10.21
お互い疑心暗鬼になりがちな、経営企画と事業部の壁 組織に「分断」が生まれる要因と打開策
提供:F5ネットワークスジャパン合同会社
リンクをコピー
記事をブックマーク
野崎馨一郎氏(以下、野崎):では、今回共同でレポートの調査をしたTwimbit社の創業者兼CEOのManoj氏による、日本市場についての見解をビデオで共有したいと思います。
(ビデオ開始)
『オープンバンキング最新動向 シンガポールから見た日本』
Manoj Menon氏(以下、Manoj):(今回のインタビューの機会をもらうことができ)感謝しているよ。ありがとう! (2020年のこの調査プロジェクトは)大変だったけど楽しかったよね!
明らかにアジア全域を見てみるとシンガポールと香港はリーダーと言える。一方、日本はそこまでは達していない。
1つの理由に産業への規制について、体制・制度面でシンガポールは非常にプロアクティブと言えるよね。タイムラインを明確に設定して、各金融期間にオープン化を推進するための動機付けも行なった。オープン化のために健全で建設的な金融機関同士の競争も促した。
結果としてシンガポールはオープンバンキングを活用するという意味では市場としてかなり進んだと言えるよね。一方、日本はそこまで規制などの取り組みが進んでいるとは言えない。大手金融機関に対しても規制当局から強い圧力がかかったとは見えない。
それ以外にも、シンガポールと香港は例えばデジタル専業銀行向けのライセンス発行なども始めている。これもオープンバンキングの取り組みを加速した一因かと思っているよ。
Manoj:部分的にシンガポールと日本は共通点があると思っている。1つは大手金融機関がオープン化を推進しはじめた点だよね。一方、シンガポールが最もメリットを教授しているのは数多くのフィンテックのハブであるという点かな。数百、数千の世界中のフィンテックスタートアップがシンガポールをアジア地域へのゲートウェイ(玄関口)とみなしている。
決済系、融資・ローン、新興のデジタルバンクなどがすべて地域の本部機能をシンガポールに置く。これによりシンガポールはその企業の生態系(エコシステム)の構築による恩恵がある。この点はオープンバンキングの重要なドライバー(促進要因)だと思っている。
日本では残念ながら違う状況だよね。極めて国内志向な市場だとみなされている。例えばフィンテックや先進的な企業が日本市場を見てみると、大きい市場規模、世界第3位の経済大国だから魅力を感じるとは思う。それでも同時にクローズド(閉鎖的)で、競争するには十分な環境とは見られないという点はあるよね。
Manoj:僕自身日本に対して最大の尊敬の念を抱いているし、その魅力はすばらしいと思っているよ。僕らは子どもの時からずっとどこの家庭でも憧れはいつもソニー製のテレビを自宅に置くことだったんだ。それこそがブランドだったんだ。品質、信頼性。日本は信頼と最高レベルの品質で知られているだろ?
翻って、金融のエコシステム・生態系にとってそもそも何だと思う? 当然すべて信頼から成り立っているんだよ。自分のお金の安全性。自分の生活の安全性。金融資産の管理性。日本(の製品・サービス)は信頼性を得るという意味ではすばらしい位置付けにすでにいるんだ。少なくとも電気製品、グローバルなB2B(企業間ビジネス)、産業経済界などではね。
ただ日本勢はまだ金融の世界では進んでいないんだ。大きな伸び代が日本のプレイヤーにとってはあるということなんだよ。でもそれを実行するとなると、日本は(市場もプレイヤーも)オープン化しなければいけない。
オープンであることによるメリットを享受しなければ進めない。まさにオープンバンキングが良い例なわけだ。グローバルなプレイヤーが日本市場に参入して事業展開する、そういう状況を推進しなきゃ。
そしてイノベーションを加速させなきゃいけないんだよ。なぜかと言うと、そのイノ……
「Manoj君、止まらないのでここでカットしますm(__)m」
(ビデオ終了)
野崎:はい。松本さん、いかがでしょうか?
松本央氏(以下、松本):いやいや、今からが一番大切なところで、ここから日本で具体的にどうやっていくかのエッセンスが聞けると思ってワクワクしていたのに。
野崎:そうなんですけど。スタートアップの社長さんってイノベーションを話すと長いので編集しきれなくて切っちゃったんですけど。
補足しますね。補足その1は、イノベーションは異なるバックグラウンドや異なる国、地域の違うプレイヤーが一緒にやるから起こるんだというのを彼はかなり長い時間を割いて、編集しきれないくらい言うというのが1つ目ですね。
松本:それは取り入れなきゃいけないですね。
野崎:2つ目ですが、本日実験的にZoom上でビデオを流したのは弊社も初めてでうまくいくか自信がなかったのもあるので、以下にフルバージョンを掲載します。本日ご参加いただいたみなさまにはリンクをお送りいたしますので、松本さんもじっくり5回でも10回でも見直していただければと思います。
松本:これからお客さまといろいろお話しする時にもこの視点は重要だと思います。私にとっても新しい気付きがありますから。やはりこれはぜひぜひ見ないと、この盛り上がった気持ちが収まらない感じがありますね(笑)。
野崎:ではその気持ちのまま、ここからは松本さんからオープンバンキングにまつわるいくつかのアーキテクチャのお話を本日はご紹介いただけるんですかね。よろしくお願いいたします。
松本:ありがとうございます。それでは私松本からは、みなさま実際いろいろなかたちでオープンバンキングに関わられていくと思うんですけれども、特にどのような環境、システムでオープンバンキングを実現する必要があるのかのエッセンスをお伝えできればなと思います。
先ほど野崎さんのスライドでもありましたけれども、8つの提言ですね。ビジネス面、テクニカル面が分かれるというところで、今回私のセッションではテクニカル面についてお話ししようと思いますけれども。この4つの項目が該当すると思います。
オープンバンキングを成功させるためというところですので、テクニカル面ではこちらを満たしながら、今までの話でもあったようにオープンな環境とか、エコシステムを作りながら展開していきます。
どのようなことがポイントになるかを改めて考えてみますと、やはりオープンバンキングの軸はバンキングの概念ですので、そこをデジタルにいかに拡張していくかがポイントになります。
そちらを広げていきながら、やはりお客さまが先にいますので、そのお客さまがどう変わっていけばよりよくなるかとか。どういうふうに生活に影響していけば、より銀行を充実して使っていただけるかを考えていく必要があると考えています。
ですから、このテクニカル面においてはやはりお客さまのニーズをリアルタイムにわかっていくためのデータの獲得と活用がありますし、お客さまのいろいろなシーンを想定しデータを集めると、見えてくるインサイトというのは違ってくると思います。
先ほどDBSさんもおっしゃっていましたけれども、PoCというかたちでサービス、事業を展開しながらニーズをいかに満たしていくかということをやったりします。
すべて自社の中で閉じることも可能な場合はとても幸せな状況だと思いますが、場合によってはコラボレーションや企業買収、新しい部門の立ち上げ、いろいろな方法が市場にはあるかと思います。
オープンバンキングにおいてはコラボレーションを前提としながら連結していくアプリケーションプラットフォームというのがなにより重要なポイントになると考えています。
ではオープンバンキングを実現するためのキーポイントについてご紹介したいと思います。まず1つ目が独立したプラットフォームになります。こちらは少しテクニカル面のお話で、やはりプラットフォームというところですね。
いろいろな環境でアプリケーションを動作させることがあると思いますが、オープンなエコシステムということは外部とつながるというところもありますし、またそこから自由にいろいろな会社さまとつながっていくというところがあります。
将来にわたりどのようなプラットフォームが一番いいかは、なかなかわかりませんので、自由にどこでも選べるように独立したプラットフォームでアプリケーションを実装していくのがよいかなと思います。
そしてモジュール化、高い再利用性というのもポイントになります。やはりいずれの環境でもいろいろなアプリケーションをデプロイしますけれども、それが1回きりであったらなかなかスピード感等々実現できません。
今まさにお客さまのほうで実現したいというニーズを把握しても、アプリケーションの市場投入が遅れてしまうとなかなかビジネスが展開されないという課題があります。そのような場合においてもいろいろなところで再利用できるというのがポイントになっています。
そして銀行さまですと忘れてはいけないのがセキュリティです。こちらも高度なセキュリティを実現しながら、それでいてユーザビリティを下げない。ユーザーさまにが利用する時にポップアップがいっぱい出て「セキュアです」って言っても「なんだ、面倒くさいな」っていきなり使わなくなってしまうので、そういうことを起こさない。だけど裏できちんとセキュリティが高いことが求められます。
そして次にAPIファースト。今までもオープンな仕組みとかエコシステムというキーワードをお伝えできているかと思いますけれども、その中でつながっていくというところで、APIは大変重要なポイントです。
1つの堅牢なシステムを作るというよりは、最初から外部からどう情報を参照されるか、もしくはどういうかたちでインターフェイスを用意して外部と連携するかを前提とした設計が重要になってきます。
そして最後は、先ほどの提言のところでもキーワードに触れましたけれども、トランザクション分析というところで、いろいろなトラフィック、トランザクションが流れる中で最適化していくという視点もあります。また新たなインサイトを得てアプリケーションを拡張するというところがあります。
ですから、オープンバンキングはキーワードのとおりバンキングがコアなのですが、それを実際に作り上げるのは一番左のアプリケーション中心というかたちになってきます。今までの堅牢な銀行のシステムからアプリケーションでいかに変えていくかがキーポイントになってきます。
それでは本日ユースケースを2つお持ちしていますので、まず1つ目、既存の銀行や金融システムの場合で、オープンバンキングのシステムを考えていきたいと思います。
既存ということですので銀行業がすでに行われているということですね。昨今ですとWebで残高を確認したり、いろいろな手続きが個人でもできるようになっていますので、そのようなコアシステムがすでにある状態。これがかなりのキーです。
やはりそれをなくしていきなりビジネスを展開することはできないので、コアシステムがある状態でどうしていくかというところが大切になります。
コアシステムですでにお客さまがいらっしゃいますので、その堅牢性とか、確実性、安定性を維持しながら拡張していくというのが既存銀行、金融システムにおけるポイントになります。
(スライドを示し)そこで求められるシステム要件を下に書いていますが、このコアシステムをその他各種エコシステムといかに安全につないでいくか。そしてまたサービス部門や事業部門それぞれ違ったニーズがありますので、それにどう対応していくか。
そしてまた今堅牢性というところですと、データセンターで事業を展開されているお客さまが多いかなと思いますが、今後新たなクラウド、もしくは既存のクラウドの新しいサービスをいかに取り入れていくか。
それでいてやはり生産性を高く、お客さまのニーズに合わせてジャストで市場に提供できるようなかたちでどういうふうにしていくかというのがポイントになろうかなと思います。
(スライドを示し)こちらをイラストで見てみたいと思います。一番左にお客さまがいらっしゃってパソコンのWebブラウザ、またはスマートフォンなどを使って、オンプレミスの環境にある赤いコアシステムを操作されるという想定になるかなと思います。
緑色の矢印がインバウンドで、お客さまが実際にシステムを利用するトラフィックになっています。
既存の環境においても昨今いろいろな連携があり、銀行間の連携などもありますので、そのコアシステムが外部につながっていくのが、現状置かれている既存の環境と想定しています。
こちらもオープンバンキングを想定して作っていく場合に変化するところなのですが、まずユーザーさまがリッチなWebアプリケーションやスマートフォンのネイティブのアプリケーションなどを利用されるシーンが出てくるかと思います。
その中で、まず1つ目が各サービスチームや開発チームそれぞれが柔軟に環境を使えることがポイントになります。もちろんコアシステムはそのままの安定性、堅牢性と外部との接続などを検討しながら、それとは別にオンプレミスに、Kubernetesのコンテナ環境でのアプリケーションデプロイや、さらにはクラウド環境にアプリケーションをデプロイしていくというような状況が考えられます。
(スライドを示し)それらをユーザーがアプリケーションを使って利用するわけですが、ネイティブアプリケーションというのはその中身自体がUIの操作を行なって何かアクションをすると、その裏でAPIが動いたりします。その機能ごとにそれぞれ別のアプリケーションというのを銀行さまの内部、もしくは外部も含めていろいろ利用する環境になっています。
銀行さまの内部においてはさまざまなAPIがオンプレミス、クラウドどちらにおいても安定して、またクライアントさまには高速にアプリケーションを提供すること。そしてやはりアプリケーションの市場投入は早くできればできるだけお客さまに使っていただく状況も増えてきます。
(スライドの)Proxyの吹き出しにあるWAF、JWT、OIDC、RateLimitなど、アプリケーションをきちっと守るセキュリティというのを実現していきます。そしてアプリケーションはリアルタイムにオンタイムできちっとデリバリーをしながらも、高い堅牢性というのをProxyと言われる装置で提供するのがポイントになってきます。
このオープンバンキングというのは外部に接続するのも大変重要なポイントですので、それぞれのシステムが外部との連携をして新しい情報を得て、さらによいサービスを提供するというところがあります。
なんでもかんでも銀行のシステムが外部に接続するのは決していい状況とは言えません。きっちりProxyなどを置いて、アプリケーションが接続していい状況をあらかじめFQDN、URLなどで管理をした上で外部接続し、各外部の銀行さま、保険さま、サービス行さま、いろいろなシステムと連携していくことが求められます。
もう1つのユースケースがデジタルバンキングさまの場合です。先ほどネオバンクというキーワードがありましたけれども、新しい銀行業さまの場合にはどのようなシステムが求められるかをお話したいと思います。
まずポイントです。ネオバンク、デジタルが前提の銀行さまに関しましては支店などを持ちませんので、すべてインターネット、デジタルで実現されます。ですので、前提は最新のテクノロジーをいかに柔軟に活用しながらサービスを展開していくのかになります。
ポイントはすでにアプリケーションセントリックであり、市場にオンタイムで提供するのが会社の重要なポイントになっていることです。
システム要件としてはリアルタイムAPI、各種システムが柔軟に連携できること。そして最新のセキュリティも最新のシステムも含めて導入しながら高いユーザビリティを両立するというのが、こちらで求められる要件になっています。
(スライドを示し) こちらの場合には先ほどと少し状況が異なるイラストとなります。バブリッククラウドやオンプレミスでもあり得ると思いますが、クラウドネイティブのテクノロジーを前提としてアプリケーションが実装されるかたちになるかと思います。
基本的にアプリケーションにアクセスするフローに関しては、トラフィックが入っていくというところになります。やはりポイントは、(スライドに)前段のAPI Gatewayと書いていますが、ここできちっとSSL/TLS、クライアントサイドでの通信の最適化、そしてセキュリティも実現しながら通信を後段のマイクロサービスに渡していきます。
ネオバンクさまなどでははじめから新しいテクノロジーを取り入れることも可能ですので、CQRSなども取り入れながらアプリケーションのニーズや利用に合わせて、自動で柔軟にスケールアウトしながらサービス拡張できる仕組みも使われています。
さらに下もこのAPI Gatewayで通信されている内容をリアルタイムで把握しながらトランザクションのデータなどを管理して、今まさに自分たちのサービスに何が起こっているかを把握し、また新しいサービスを作っていく改善のライフサイクルがとても早くなっているのがポイントになります。
先ほど外部接続というところがありましたけれども、こちらは基本的に同じような流れですが、やはりアプリケーションを連携していきますので、こちらにおいてもセキュアに安全に管理するところは変わりません。
では、まとめです。オープンバンキングに関しては、最初のセッションでもいろいろな規制というところで、各国さまざまなフェーズにあります。
実装も国によって、例えばコンフィグレーションレベルになるとそれぞれのベストプラクティスはまだまだ議論がある状況です。法整備も各国違う状況ですので、その議論をきちっと追いながら進めていく必要があると思います。
そして、それを前提とした中で柔軟なアプリケーションの接続が求められますので、本日私から2つのユースケース、既存の銀行システムをお持ちの方、またネオバンクというかたちで2つのユースケースを紹介しました。
弊社はさまざまなかたちで業界と密な連携を取っていますので、オープンバンキングに関しましてもいろいろな標準化や実装提案もディスカッションに参加しながら進めています。これからみなさまの具体的なシステムケアにおいてもよりよいかたちでお手伝いできればと考えています。
簡単ではありましたが、ユースケースに関しましては以上です。ありがとうございます。
野崎:松本さんありがとうございました。では残りの時間を使ってQ&Aおよびディスカッションに移らせていただきたいと思います。いくつかQ&Aのほうにいただいています。一番キツいのからいきましょうか。マネタイズの成功例はありますか? と。
松本:ははは(笑)。難しいですね。
野崎:一番キツいやつです。自分でなんでこんなキツい質問を選んだんだろうという話なんですけども。結論から言うと、ないですね。そこまでの大成功は、どこかの国のどこかのデジタルバンクやオープンバンキングでもチャリンチャリン毎日お金が入ってしょうがない、こんなに儲かってしょうがないというニュースはないと思うんですよね。
今回のレポートの調査や、調査したあとの、先ほど出てきたManojさんのTwimbitの人間、あと私はアジア地域の同僚といろいろ話すのでオーストラリアの営業、シンガポールの営業などとも話しました。
どこの国の銀行さんもいろいろ先進的な取り組みをしているけれども、それでも儲かっているフェーズに入っているかというと入っていないというのが私からの回答になります。
その心というのは、私のさっきの資料にも紐づくんですけれども、一部のシンガポールのDBS担当営業と話した時に若干ムッとした顔で「そもそもオープンバンキングのゴールってどこなんだ?」みたいな話が出ました。
「なに? 来年までに何億儲けなきゃいけないっていうのをそもそも目指しているの? だったらそれ用のゴール、それ用の内容でやるべきなんじゃないの?」みたいな話になって。言い換えると、そういうところにゴール設定をしていないプレイヤーもあるのかなと私は思うんですよね。
松本:私はその意見に賛成ですね。今日の野崎さんのスライドにあったDBSさまの件で2つあって。APIをリアルに200も公開しているのに、みなさんからいくらでいいですかって聞いた話、あれもおもしろいですし。
もう1つ、F5がいろいろなパネルディスカッションみたいなかたちをもって、そこで社内を説得するためにPoCをやっているというのがまさにそうなんです。デジタルが先行している世界って答えが出ていないんですね。ただデジタルはそれをいろいろ工夫することにより、新たによりよい環境は作れるところまでがなんとなく見えている。
なので、それがいくらのマーケットになるか、いくらのビジネスになるかってなかなか単純なことではありません。それをPoCをしていった時に価値が定義されていったり、逆を言うと、例えば僕らはiPhoneが出る前にはiPhoneのすごさ、今の席巻状況ってわからなかったように、世界を変えていってから初めてそこでお金に変わるような価値が出てくると思います。
それまでの段階はPoCだし、その金額でのゴールって未来からやって来たドラえもん以外はたぶん答えが言えないと思うんですよね。
野崎:そうなんですよね(笑)。実際にDBSの担当SEからも言われたんですけど、「じゃあ逆に聞くけど、例えばGoogleがgmailを出した時に、gmailで2年後3年後に絶対何億円の儲けを出すってやっていたと思うか?」と。「知らないけどさ、実際のところは」と言われてですね。
いろいろ社内で議論していた時に、DBSの担当営業が明確に言っていたのが、「でもな、野崎な、私毎日のようにDBSさんを訪問しているけれども。最近はDBSさんのエンジニアの人に『おたくの銀行は……』っていう言い方をしたら怒られるんだよ」と。
俺たちはもう銀行じゃないと。「銀行という免許を持っているテックカンパニーで、テックジャイアントが我々のライバルなんだ」という姿勢できているというのが実際あって。おぉ、なるほどと。そろそろこの話題はやめようと思って、私そのままそっと閉じたんですけれども(笑)。そういう側面は正直あるのかなと。
さっきの私のページにチラッと書いてあったゴール設定ですよね。早急にマネタイズしなきゃいけないんだったら、そこに行き着くまでの道筋の中にどこまでオープンバンキングに取り組んで、どこまでリソースかけるかの線引きとか、道の引き直しが必要なところがけっこう出てくるあると思います。そのくらい一筋縄ではいかない世界なのかなと正直私も思うところですね。
たぶん今松本さんがおっしゃったところってそこなのかなと思うんですけれども。
松本:おっしゃるとおりですね。一筋縄ではいかない。オープンバンキングが広すぎるというところ、概念のような定義なので、それもありますけれども。かなり予測性があるということは、やはり過去に似たようなことがある。
例えばビデオレンタルがオンラインになった時に、価格設定って、だいたいみんな同じような金額を月額で払うだろうなと比較できるものがある場合にはそうなります。
オープンバンキングというのはビジネスでお金を儲けるだけを定義するわけじゃなくて、もしかしたら、例えば私がある銀行で、お客さまにもっと愛してほしいみたいなのもオープンバンキングでゴールとして定義してやっていく。そこでもっともっと近い、デジタルなんだけどもっとあたたかい感じを感じてほしいというような定義もあり得るでしょうから。
そこは本当に金額じゃない。自分たちがなんのためにテクノロジーを使って、どういうことを提供したいんだっけ。で、その先にあると思うので。そこまで議論が煮詰まって、ほかに変えるものがない。過去と同じようなものがないところを作っていける場合に、初めて価格設定ができるのかなと。やはり難しいんだと思います。
野崎:そうですね。ありがとうございます。ちょっとお時間もあれなので、最後のお知らせの前に手短に、松本さん向けの質問が2つ来ていますけれども。
松本:Gatewayの件ですか?
野崎:そうです。ユースケースにおけるGatewayはNGINXの使用ケースはありますか? ちょっとお時間の関係で手短に松本さんお願いします。
松本:あります。と言いますのが、こういうオープンバンキングの場合は、何のサービスをどう提供するかってわからない場合がありますが、NGINXというプロダクトは圧倒的にソフトウェアでできること、コンフィグレーションの1つって幅広くあるので。
まずはNGINXで導入して、シンプルなAPI Gatewayをしながら認証をかけていって、セキュリティを上げてというところをしながら、システムを安定してシンプルに実装しながらそのあとで必要な機能をちゃんと導入すればいいので。その根幹にNGINXがいるというのはかなり一般的なかたちだと思います。
野崎:ありがとうございます。
F5ネットワークスジャパン合同会社
2024.11.13
週3日働いて年収2,000万稼ぐ元印刷屋のおじさん 好きなことだけして楽に稼ぐ3つのパターン
2024.11.21
40代〜50代の管理職が「部下を承認する」のに苦戦するわけ 職場での「傷つき」をこじらせた世代に必要なこと
2024.11.20
成果が目立つ「攻めのタイプ」ばかり採用しがちな職場 「優秀な人材」を求める人がスルーしているもの
2024.11.20
「元エースの管理職」が若手営業を育てる時に陥りがちな罠 順調なチーム・苦戦するチームの違いから見る、育成のポイント
2024.11.11
自分の「本質的な才能」が見つかる一番簡単な質問 他者から「すごい」と思われても意外と気づかないのが才能
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.18
20名の会社でGoogleの採用を真似するのはもったいない 人手不足の時代における「脱能力主義」のヒント
2024.11.19
がんばっているのに伸び悩む営業・成果を出す営業の違い 『無敗営業』著者が教える、つい陥りがちな「思い込み」の罠
2024.11.13
“退職者が出た時の会社の対応”を従業員は見ている 離職防止策の前に見つめ直したい、部下との向き合い方
2024.11.15
好きなことで起業、赤字を膨らませても引くに引けない理由 倒産リスクが一気に高まる、起業でありがちな失敗
2024.11.13
週3日働いて年収2,000万稼ぐ元印刷屋のおじさん 好きなことだけして楽に稼ぐ3つのパターン
2024.11.21
40代〜50代の管理職が「部下を承認する」のに苦戦するわけ 職場での「傷つき」をこじらせた世代に必要なこと
2024.11.20
成果が目立つ「攻めのタイプ」ばかり採用しがちな職場 「優秀な人材」を求める人がスルーしているもの
2024.11.20
「元エースの管理職」が若手営業を育てる時に陥りがちな罠 順調なチーム・苦戦するチームの違いから見る、育成のポイント
2024.11.11
自分の「本質的な才能」が見つかる一番簡単な質問 他者から「すごい」と思われても意外と気づかないのが才能
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.18
20名の会社でGoogleの採用を真似するのはもったいない 人手不足の時代における「脱能力主義」のヒント
2024.11.19
がんばっているのに伸び悩む営業・成果を出す営業の違い 『無敗営業』著者が教える、つい陥りがちな「思い込み」の罠
2024.11.13
“退職者が出た時の会社の対応”を従業員は見ている 離職防止策の前に見つめ直したい、部下との向き合い方
2024.11.15
好きなことで起業、赤字を膨らませても引くに引けない理由 倒産リスクが一気に高まる、起業でありがちな失敗