新規事業のスピードが遅いとき、多くの組織は「担当者の頑張りが足りない」「人が足りない」と考えがちです。しかし実際に時間の使われ方を分解してみると、作業そのものにかかっている時間はわずかで、大半は承認を待つ時間、会議の日程を待つ時間、社内の手続きを待つ時間であることが少なくありません。スピードを上げる鍵は、作業を速くすることではなく、この「待ち時間」を減らすことにあります。
結論として、新規事業を遅らせている社内の詰まりは、測れば特定でき、特定できれば多くは仕組みで解消できます。手順は、まず一つの検証にかかった期間を「作業」と「待ち」に分けて記録し、最も長い待ちがどこで生まれているかを見つけ、その原因に応じて決裁権限の委譲、会議体の見直し、手続きの例外ルールといった手を打つ、という流れです。精神論ではなく、時間の流れを観察して直すことが重要です。
この記事は、新規事業の責任者や担当者で、社内の承認や手続きに時間がかかって検証が進まないと感じている方、新規事業の組織づくりを担う経営企画や経営層の方に向けて書いています。遅さの原因の見つけ方、詰まりの種類ごとの解消法、経営層との合意の取り方、よくある失敗を整理します。
なぜ新規事業ではスピードが重要なのか
新規事業でスピードが求められる理由は、競合に先を越されるからだけではありません。最も大きな理由は、学びの回数が成否を分けるからです。新規事業は、仮説を立て、確かめ、学び、修正するという循環を何度も回すことで、顧客が本当に求めるものに近づいていきます。一回の循環に三か月かかる組織と、二週間で回せる組織とでは、同じ一年で得られる学びの量がまったく違います。
また、時間がかかるほど、検証にかかる費用も増えます。担当者の人件費は待っている間も発生し、外部の協力者を待たせれば追加の費用がかかることもあります。さらに、時間がかかると関係者の関心が薄れ、経営層の期待が失望に変わり、事業そのものが続けにくくなります。
つまり、新規事業のスピードは、効率の問題である以上に、事業が成功する確率を左右する問題です。
遅さの正体は「作業」ではなく「待ち」
ある一つの検証、たとえば「顧客に試作品を見せて反応を確かめる」という活動が、計画から結果の共有までにどれだけの時間がかかったかを分解してみます。架空の一般例として、次のような内訳になることは珍しくありません。
| 工程 | 作業にかかった時間 | 待ちにかかった時間 | 待ちの原因 |
|---|---|---|---|
| 検証計画の作成 | 数日 | 一週間以上 | 上司の確認の予定が合わない |
| 予算の承認 | 半日 | 数週間 | 稟議の回覧、月次の決裁会議待ち |
| 外部への発注 | 一日 | 数週間 | 取引先の登録、契約書の法務確認 |
| 試作品の制作 | 一〜二週間 | 数日 | 仕様の確認待ち |
| 顧客への接触 | 数日 | 一週間以上 | 営業部門の承認、顧客の日程 |
| 結果の共有 | 一日 | 数週間 | 報告会議の開催待ち |
この例では、作業の合計は数週間程度なのに、待ちの合計はその何倍にもなっています。どれだけ担当者が作業を速くしても、待ちが減らなければ全体の期間はほとんど変わりません。全体の流れを止めている箇所、つまりボトルネックを見つけて直すことが、最も効果のある改善になります。
詰まりを特定する手順
まず、自社の新規事業のどこで時間がかかっているかを把握します。感覚ではなく、記録に基づいて特定することが大切です。
- 直近の検証を一つ選ぶ。 計画から結果の共有までが一通り終わった検証を選びます。まだ終わっていなければ、今進めている検証で記録を始めます。
- 工程を書き出す。 計画、承認、発注、制作、顧客接触、結果の共有など、検証を構成する工程を並べます。
- 各工程の開始日と終了日を記録する。 メールやチャットの履歴、稟議の記録、カレンダーから日付を拾います。
- 作業と待ちに分ける。 各工程の期間のうち、誰かが手を動かしていた時間と、何かを待っていた時間を分けます。
- 待ちの原因を書く。 何を、誰を待っていたのかを具体的に書きます。「承認待ち」ではなく「部長の確認、その後の本部長の決裁、月一回の決裁会議」のように分解します。
- 最も長い待ちを特定する。 合計時間が最も長い待ちが、最初に手をつけるべき詰まりです。
- 複数の検証で繰り返す。 一つの検証だけでは偶然の可能性があります。二つ三つの検証で同じ記録を取り、繰り返し現れる詰まりを確かめます。
この作業を一度やるだけで、「何となく遅い」という感覚が、「予算の承認と外部への発注で全体の半分以上の時間を使っている」といった具体的な事実に変わります。事実があれば、経営層に改善を提案する材料にもなります。
記録を取るときの注意点
記録を取る目的は、誰かの責任を追及することではなく、仕組みの問題を見つけることです。「部長の確認に一週間かかった」という記録が、部長個人への批判として受け取られると、協力が得られなくなります。記録を共有するときは、個人名ではなく役割や手続きの名前で書き、「部長が遅い」ではなく「部長が確認できるのは週一回の定例の後しかない」という仕組みの問題として示します。
また、待ちの中には、顧客の日程のように社内では動かせないものもあります。社内で動かせる待ちと、動かせない待ちを分けておくと、改善の対象が明確になります。動かせない待ちについては、その間に別の作業を並行して進めるなど、段取りの工夫で影響を小さくします。
承認する側の事情も理解する
承認に時間がかかる背景には、承認者の側の事情もあります。判断に必要な情報が資料にそろっていない、承認した後に問題が起きると自分の責任になる、そもそも承認の依頼が多すぎて一つひとつに時間を割けない、といった事情です。依頼する側が、判断に必要な情報を一枚にまとめ、想定されるリスクとその抑え方を先に書いておくだけで、承認の時間は短くなることがあります。詰まりを相手のせいにする前に、依頼の仕方で減らせる待ちがないかを確認します。
詰まりの種類と解消の方法
新規事業でよく見られる詰まりを種類ごとに整理し、それぞれの解消の方向性を示します。
承認・決裁の詰まり
最も多いのが、予算や発注、顧客への接触などの承認に時間がかかる詰まりです。承認者が多い、承認の階層が深い、決裁会議の頻度が低い、といった原因が重なっています。
解消の方法として最も効果が大きいのは、決裁権限の委譲です。新規事業の責任者に、一定額までの予算執行や小規模な発注の権限を委ね、その範囲内は事後報告で済むようにします。承認そのものを一つずつ速くするより、承認が不要な範囲を広げるほうが効果は大きくなります。社内の申請・承認の流れそのものをシステムで速くする方法については稟議・申請承認ワークフローのシステム化も参考になりますが、新規事業の場合は流れを速くする前に、そもそも承認が必要かどうかを見直すのが先です。
会議の詰まり
意思決定が定例会議でしか行われないため、会議の日まで判断が保留される詰まりです。月に一回の会議でしか判断できなければ、一つの判断に最大で一か月の待ちが生まれます。
解消の方法としては、判断のための会議を検証の進行に合わせて随時開けるようにする、少人数の判断の場を週次で設ける、判断に必要な資料を事前に配って会議では判断だけを行う、といったものがあります。また、会議で決めなくてよいことを、責任者の判断に委ねることも有効です。
調達・契約の詰まり
外部の会社に仕事を頼もうとしたとき、新しい取引先の登録、与信の確認、契約書の法務確認などに時間がかかる詰まりです。既存事業の大きな取引を前提にした手続きが、小さな検証にもそのまま適用されることで起きます。
解消の方法としては、少額の発注向けの簡易な手続きを設ける、よく使う外部の協力先をあらかじめ登録しておく、契約書のひな形を法務部門と事前に合意しておく、といった方法があります。
セキュリティ・情報管理の詰まり
新しいツールやクラウドサービスを使おうとしたとき、情報システム部門の審査に時間がかかる詰まりです。大企業ほどこの詰まりは大きくなる傾向があります。
解消の方法としては、検証の段階では顧客の個人情報や機密情報を扱わない設計にして審査の範囲を小さくする、検証用の環境を本番の情報から切り離す、情報システム部門と検証段階専用の審査の基準を合意する、といった方法があります。大企業の新規事業で検証用のシステムを作る際の進め方は大企業の新規事業でMVPを作るときの社内調整とセキュリティ審査で詳しく解説しています。
顧客接触の詰まり
既存の顧客にヒアリングや提案をしようとしたとき、営業部門の承認や調整に時間がかかる詰まりです。既存部門が自分たちの顧客との関係を守ろうとするのは自然なことなので、手続きで押し切るのではなく、接触のルールを事前に合意しておくことで解消します。
仕様確認の詰まり
試作や開発の途中で、「この画面はどちらの案にするか」「この機能は今回入れるか」といった判断を誰がするのかが決まっておらず、確認のたびに関係者を集めることになる詰まりです。開発会社を待たせる時間が長くなり、費用にも跳ね返ります。解消の方法は、検証の範囲内の判断をする人を一人に決めておくこと、そして「検証の目的に関係しない部分は最も手間の少ない案を選ぶ」といった判断の基準を事前に合意しておくことです。
詰まりの種類と解消策のまとめ
| 詰まりの種類 | よくある原因 | 主な解消策 |
|---|---|---|
| 承認・決裁 | 承認者が多い、決裁会議の頻度が低い | 一定額までの権限委譲、事後報告への切り替え |
| 会議 | 定例会議でしか判断しない | 随時の判断の場、少人数の週次判断、事前の資料配布 |
| 調達・契約 | 大口取引前提の手続き | 少額発注の簡易手続き、協力先の事前登録、契約ひな形 |
| セキュリティ | 新規ツールの審査が重い | 機密情報を扱わない検証設計、検証段階専用の基準 |
| 顧客接触 | 既存部門との調整 | 接触ルールの事前合意、既存部門への結果の還元 |
| 仕様確認 | 判断者が不在、判断の基準がない | 判断者の明確化、判断の基準の事前合意 |
経営層と「速く動くためのルール」を合意する
詰まりの多くは、既存事業のために作られた社内のルールが、新規事業にもそのまま適用されていることから生まれています。既存のルールには、大きなお金や重要な顧客を守るという正当な目的があります。新規事業のためだけにすべてのルールを外すことはできませんし、すべきでもありません。
そこで必要になるのが、新規事業の検証段階に限った例外のルールを、経営層と合意することです。例外を求めるときには、何を守るためのルールを、どの範囲で緩めるのか、緩めた結果のリスクをどう抑えるのかを、具体的に示します。
たとえば、「検証段階の外部発注は、一件あたりの上限額を決めたうえで、新規事業の責任者の判断で行い、月次でまとめて報告する。上限を超える発注と、本番の顧客情報を扱う発注は通常の手続きに従う」というように、例外の範囲とリスクの抑え方をセットで提案します。こうした権限の設計は、新規事業部を立ち上げる時点で決めておくのが理想です。その進め方は新規事業部の立ち上げ方で解説しています。
合意を得るうえで最も説得力があるのは、前述の手順で記録した「待ち」の事実です。「承認と発注の待ちで、一つの検証に数か月かかっている。これを数週間に縮めれば、一年で回せる検証の回数が何倍にもなる」と、事実と効果を並べて示します。
具体的な場面の例：検証の期間を大きく縮めたケース
架空の一般例で考えます。ある企業の新規事業チームは、法人向けの新サービスの検証を進めていましたが、一つの検証に数か月かかり、一年経っても検証は数回しか回せていませんでした。経営層からは「進みが遅い」と指摘され、チームは疲弊していました。
チームの責任者は、直近の三つの検証について、工程ごとの作業と待ちを記録しました。その結果、最も長い待ちは外部への発注に関わる手続きで、新しい取引先の登録と契約書の法務確認に毎回数週間かかっていることが分かりました。次に長いのは、月一回の決裁会議を待つ時間でした。
責任者は、この記録をもとに経営層に三つの提案をしました。第一に、検証段階の発注は上限額を決めたうえで責任者の判断で行い、月次で報告すること。第二に、よく使う外部の協力先を三社ほど事前に登録し、契約書のひな形を法務部門と合意しておくこと。第三に、決裁会議とは別に、新規事業の判断のための少人数の場を隔週で設けること。
経営層は、上限額と報告の仕組みがあることを条件に、提案を受け入れました。その結果、次の検証は計画から結果の共有までが一か月程度で終わり、以降もそのペースを保てるようになりました。チームは、短期間で検証を回す進め方を身につけ、検証の回数そのものが増えたことで、事業の方向性も早く固まっていきました。短期間で検証用のシステムを作る進め方は短期間でMVPを作る進め方も参考にしてください。
よくある失敗とその避け方
- 担当者の努力でスピードを上げようとする。 作業を速くしても、待ちが減らなければ全体の期間は変わりません。まず待ちを測ります。
- 感覚で詰まりを決めつける。 「法務が遅い」「情シスが厳しい」と思い込んでいても、実際の最大の詰まりは別の場所にあることがあります。記録に基づいて特定します。
- すべてのルールの撤廃を求める。 既存のルールには守るべき目的があります。範囲を限った例外と、リスクの抑え方をセットで提案します。
- 一度の改善で終わる。 一つの詰まりを解消すると、次の詰まりが見えてきます。定期的に記録を取り、改善を続けます。
- 権限を委ねられた後に報告を怠る。 事後報告の約束を守らなければ、委ねられた権限はすぐに取り上げられます。報告を確実に行います。
- スピードのために検証の質を落とす。 速さは学びの回数を増やすための手段です。確かめるべきことを確かめずに速く進んでも意味がありません。
スピード改善のチェックリスト
- 直近の検証の工程を書き出し、作業と待ちに分けて記録した
- 待ちの原因を具体的に書いた
- 最も長い待ちを特定した
- 複数の検証で、繰り返し現れる詰まりを確かめた
- 新規事業の責任者に委ねる権限の範囲と上限を提案した
- 判断の場を検証の進行に合わせて開けるようにした
- 少額発注の簡易手続きや協力先の事前登録を整えた
- 検証段階のセキュリティ審査の基準を情報システム部門と合意した
- 既存顧客への接触ルールを関係部門と合意した
- 例外ルールの運用状況を定期的に報告している
よくある質問
Q. 権限の委譲を経営層に提案しても受け入れてもらえません。どうすればよいですか？
経営層が懸念しているのは、多くの場合、権限を委ねた後に何が起きているか分からなくなることです。上限額、報告の頻度と形式、例外の対象外となる条件をセットで示すと、受け入れられやすくなります。最初は小さな範囲から始め、運用の実績を示してから範囲を広げる方法も有効です。
Q. 会議を減らすと、関係者への情報共有が不足しませんか？
判断のための会議と、情報共有のための場を分けると両立できます。判断は少人数の場で素早く行い、結果は文書やチャットで関係者に共有します。全員が集まる会議でしか情報が伝わらない状態は、それ自体が詰まりの原因です。
Q. 外部の会社に頼むと、手続きの詰まりはなくなりますか？
外部の会社に頼んでも、発注や契約の手続きは社内で必要です。ただし、検証の設計から試作までを一つの契約でまとめて依頼できれば、個別の発注を何度も行う手間は減ります。外部を使う場合も、社内の手続きを事前に整えておくことが前提です。
Q. スピードを上げると、失敗が増えませんか？
一つひとつの検証の規模を小さくしていれば、失敗の影響も小さく抑えられます。むしろ、時間をかけて大きな検証を一度だけ行うほうが、外れたときの損失は大きくなります。小さく速く回すことで、失敗から学ぶ機会を増やすことが新規事業の進め方の基本です。
Otsumuに相談できること
新規事業のスピードを妨げている詰まりの多くは、社内のルールや権限の問題です。記録を取って詰まりを特定し、経営層と例外のルールを合意できる立場にあるなら、外部の支援がなくても改善は進められます。この記事の手順は、そのまま社内で使えるように書いています。
一方で、社内の手続きを整えても、検証の設計や試作そのものに時間がかかっている、検証のたびに開発会社を探して見積もりを取り直している、といった状況では、検証を短期間で回せる外部のパートナーを持つことが助けになります。また、経営層に権限の委譲を提案する際に、短期間で検証を回せた実績があると、説得の材料になります。
Otsumuは、自らも事業を手がける実践者として、新規事業開発コンサルティングで検証の設計と進め方を、新規事業の爆速MVPシステム開発で、AIを活用した少人数・短期間の試作と開発を、構想から運用・改善まで一気通貫で支援しています。一つの契約の中で検証の設計から試作までを進められるため、社内の発注手続きの回数を減らせます。期間を区切って検証を回したい場合は、顧客検証 Sprint（98万円〜・税別、4週間）やPoC / MVP Sprint（300万円〜・税別、6週間を目安に設計）といった進め方もあります。
スピードの改善に向けて何から手をつけるべきか迷っている段階でも構いません。30分の無料相談で、現在の進め方を一緒に確認します。
この記事のテーマに最も近い支援は、新規事業の体制づくり・人材・社内推進支援です。
- 判断・実行・支援の役割を体制図に
- 責任と同じだけの権限を設計
- 採用・外部人材・社内制度まで伴走
まずは30分の無料相談で、状況をお聞かせください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01