MENU

金融機関からスタートアップへ転職して感じた仕事の違い

金融機関からスタートアップへ転職して仕事の違いを考えるビジネスパーソン

金融機関からスタートアップへ移って、私が最も大きく違いを感じたのは、単純な仕事の速さや裁量の大きさではありません。仕事を進めるための前提を、誰がどこまで整えるのかという違いでした。

金融機関では、規程、役割分担、審査、決裁、記録の仕組みが整い、その中で判断の質を高める仕事が多くあります。一方、私が転職後に関わった海外事業、新規事業、事業開発では、目的は決まっていても、担当範囲、必要な情報、社内の進め方まで自分たちで組み立てる場面が増えました。

これは金融機関やスタートアップ全体に共通する法則ではなく、私が経験した会社・部署・事業フェーズでの違いです。それでも、金融機関で長く働いた人が環境を変えるときに、入社後の仕事を想像する材料にはなります。

本記事では、金融機関で約15年間、法人営業、海外業務、プロジェクトファイナンス、提携交渉などを経験した後、スタートアップ・事業会社へ移った立場から、活きた能力、修正が必要だった進め方、転職前に理解しておきたかったことを整理します。金融機関と事業会社の一般的な職務差は、金融機関から事業会社への転職で後悔しない確認項目で別に解説しています。

目次

結論|違いは「速さ」より、仕事の前提を誰が作るかに表れた

転職後に感じた違いを一言で表すと、整った前提の中で判断する仕事から、前提を作りながら判断する仕事へ移ったことです。

金融機関にも新規業務や未整備な案件はあり、スタートアップにも規程や分業があります。したがって、「金融機関は遅い」「スタートアップは自由」と分けるのは正確ではありません。違いは、次のような日々の仕事に表れました。

  • 提案が承認された後も、実行条件や運用方法まで詰める
  • 必要な情報がそろうのを待たず、判断できる最小単位を作る
  • 担当が明確でない仕事の接続点を、いったん自分で埋める
  • 顧客や現場の反応を受けて、計画と優先順位を更新する
  • 専門性を使いながら、自分でも実務を動かす

金融機関で培った慎重さや分析力が不要になったわけではありません。むしろ、限られた情報で論点を整理し、関係者が動ける条件へ変える力として使い直す必要がありました。

金融機関とスタートアップで違った仕事の全体像

私が経験した範囲では、仕事の違いは「速いか遅いか」より、判断の前提、役割の境界、実行後の責任に表れました。

仕事の場面金融機関で多かった進め方転職後に増えた進め方
判断材料定められた資料・手順に沿って精度を高める何が分かれば次へ進めるかを先に決める
役割分担専門部署との境界を確認して進める境界にある仕事の担当と期限を仮置きする
企画と実行承認・契約・実行の工程ごとに役割が分かれる企画した人が実行条件や運用まで持つことがある
優先順位年度計画、規程、組織方針との整合を重視する顧客反応や事業上の制約を受けて更新する
成果の見方判断の妥当性、手続き、再現可能な管理を重視する実行後の学習と次の判断につながったかも重視する

どちらが優れているという比較ではありません。金融機関は、顧客資産、信用、規制対応などの責任を負うため、判断の再現性や牽制が重要です。スタートアップでも事業が成長すれば、標準化や分業が必要になります。違いの背景まで見ると、単純な組織文化の優劣ではないことが分かります。

企画と実行の距離が短くなり、提案後の仕事が増えた

承認を得ることは、仕事の終点ではなく開始条件になった

金融機関でも、提案後の実行や管理は重要です。ただ、組織の中では、審査、契約、事務、管理などの工程ごとに専門部署があり、自分の担当成果が比較的明確でした。

転職後に事業開発へ関わる中では、提案が通った後に、誰が顧客へ説明するか、社内の提供体制をどう組むか、運用上の問題を誰が拾うかまで考える場面が増えました。企画書の論理が正しいだけでは、事業は動きません。実行時に発生する小さな空白を埋めて、初めて次の検証ができます。

顧客の反応が、計画の修正材料として近くなった

事業開発では、顧客や提携先の反応が早い段階で返ってきます。想定していた課題が弱い、説明に時間がかかる、提供側の負担が大きいと分かれば、当初案を守ることより、仮説を修正することが必要です。

この点は、海外営業から事業開発を目指す場合にも共通します。顧客接点を事業の仕組みへ広げる考え方は、海外営業から事業開発へ転職する方法で整理しています。

役割の境界が動き、接続点を自分で埋める場面が増えた

専門外の仕事を抱えるのではなく、次の担当へ渡せる状態を作る

スタートアップでは、必要な機能がすべて専門部署として存在するとは限りません。担当が決まっていない仕事を見つけたとき、「自分の仕事ではない」と切り離すだけでは、案件全体が止まることがあります。

一方で、何でも自分で抱えることが正解でもありません。必要なのは、論点、暫定対応、期限、恒常的な担当候補を整理し、次の人へ渡せる状態を作ることです。私にとっては、担当範囲そのものより、担当と担当の間にある接続点へ目を向けることが増えたのが大きな変化でした。

設計者とプレイヤーを短い周期で行き来する

業務の流れを設計した直後に、自分でも顧客説明、資料修正、関係者調整を行い、その結果を次の設計へ戻すことがあります。管理や企画だけに専念するのではなく、現場で得た情報を使って仕組みを作り直す往復が増えました。

この往復に向くかは、役職名では判断できません。自分で持つ実務と、他者へ任せる実務を分け、どの時点で標準化するかを考える必要があります。

判断の速さより、判断材料の作り方が変わった

情報を集め切るより、次へ進める条件を決める

金融機関で身についた確認の習慣は、転職後も役立ちました。ただし、不確実な新規事業では、必要な情報をすべて集めようとすると、顧客へ確かめる前に時間が過ぎます。

そこで、不可逆な判断か、後から修正できる判断かを分けるようになりました。後戻りしにくい契約、信用、法令、資金に関わる事項は慎重に確認します。一方、修正できる仮説は、小さく試して情報を増やします。

確認すること慎重に決める場面小さく試しやすい場面
後戻りの難しさ契約、信用、法令、資金への影響が大きい停止・変更しても影響を限定できる
必要な情報主要リスクと責任者を確定する次の仮説を選べる最低限をそろえる
進め方反対意見と条件を記録して決める期限と検証項目を決めて実行する
見直し条件違反や重大変化を監視する顧客反応を受けて短い周期で更新する

優先順位を変える理由まで共有する

事業の優先順位が変わると、前に進めていた仕事を止める場合があります。ここで「方針が変わった」とだけ伝えると、現場には手戻りだけが残ります。

何が分かって前提が変わったのか、何を続けて何を止めるのか、既に使った時間や関係者への影響をどう扱うのかまで説明する必要があります。速く変えることより、変更後に組織が動ける状態を作ることが重要でした。

金融機関で身につけた能力のうち、転職後も活きたもの

金融機関の経験は、スタートアップで使えなくなるわけではありません。私が特に活かしやすいと感じたのは、次の三つです。

事業性とリスクを同時に見る

プロジェクトファイナンスなどでは、事業が成立する条件と、成立しない場合の下振れを同時に考えます。転職後も、期待だけで計画を膨らませず、顧客、収益、提供体制、契約、資金のどこが前提になるかを分ける際に役立ちました。

関係者の利害と意思決定条件を整理する

法人営業、海外業務、提携交渉では、同じ案件でも当事者ごとに目的と懸念が異なります。誰が何を決められ、何を避けたいのかを整理する力は、社内外の関係者が多い事業開発でも使えます。

合意事項と未決事項を言葉に残す

人数が少なく会話で進めやすい組織ほど、認識差が後から表面化することがあります。決まったこと、決めていないこと、前提が変わった場合の扱いを短く残す習慣は、意思決定を遅くするためではなく、手戻りを減らすために有効でした。

金融機関で得た力転職後の使い方注意点
財務・事業分析成立条件と主要な下振れを分ける分析だけで顧客需要を決めない
リスク判断不可逆な判断と試せる仮説を分けるリスクを挙げるだけで終わらない
関係者調整目的・懸念・決裁条件を可視化する全員一致を待ち続けない
文書化合意・未決・変更条件を短く残す資料作成自体を成果にしない

金融機関の提携・企画経験を事業開発の言葉へ変える方法は、金融機関から事業開発・新規事業へ転職する方法も参考になります。

金融機関時代から修正が必要だった仕事の進め方

活きた能力がある一方、使い方を変える必要もありました。修正したのは慎重さそのものではなく、慎重さを発揮する順番です。

完成度を上げてから見せるのではなく、論点を早く見せる

資料を十分に整えてから共有すると、前提が違っていた場合の手戻りが大きくなります。転職後は、結論、未確認事項、判断してほしい点を早めに示し、方向が合ってから詳細を詰める場面が増えました。

担当範囲を守るだけでなく、案件全体の停滞を見つける

自分の担当を正確に終えることは大切です。ただし、次の工程の担当が不明、必要情報の入手方法がない、顧客への確認が止まっているといった状態では、担当業務だけを終えても成果につながりません。

自分がすべて引き取るのではなく、停滞の原因を示し、担当と期限を置くところまで関与する必要がありました。

失敗を避けるだけでなく、学習単位を小さくする

新規事業では、最初から正解を当てることが難しい場面があります。失敗を無制限に許容するのではなく、損失を限定し、何を検証するかを決め、次の判断に使える情報を得ることが必要です。

金融機関で得たリスク感覚は、この学習単位を設計するために使うと活きました。避けるべきリスクと、事業を知るために引き受ける不確実性を分ける考え方です。

同じスタートアップでも、違いは会社と事業フェーズで変わる

ここまで述べた内容を、すべてのスタートアップへ当てはめることはできません。創業直後と事業拡大期では必要な仕事が違い、規制産業かどうか、法人向けか個人向けか、資金余力があるかでも変わります。

  • 事業仮説を探している段階か、再現可能な販売方法を作る段階か
  • 専門部署があるか、外部専門家へ依頼するか
  • 経営陣が現場判断へどこまで関与するか
  • 顧客への損失や信用への影響がどの程度あるか
  • 短期の売上と中長期の基盤整備をどう評価するか

転職前に環境差を整理する場合は、大手企業からスタートアップへ転職する前に確認すべきことで、現在使っている資源と入社後に引き受ける責任を比較してください。

金融機関からの転職が向く人と、慎重に考えるべき人

転職の向き不向きは、スピードへの好みだけでは決まりません。専門性をどのような責任へ広げたいかで考えます。

比較する観点向きやすい状態慎重に確認したい状態
仕事の範囲境界にある課題を整理し、担当を作ることに関心がある担当と手順が確定していないと強い負担を感じる
判断不確実な情報から次の検証を設計できる情報不足のまま判断する責任を避けたい
専門性専門知識を実行や顧客価値へ接続したい専門業務へ集中できる環境を優先したい
評価役割変更を含め、事業成果との関係を確認できる長期に固定された職務・評価基準を重視する
転職理由新たに担いたい責任を具体的に説明できる現在の不満から離れることが主目的になっている

現職に残る選択肢と比較できていない場合は、先に転職するか残るか迷ったときの判断基準で、現在の改善可能性と転職後に得たい経験を分けてください。

金融機関に残る判断を選ぶ場合は、金融機関に残る場合のキャリア戦略で、社内評価だけでなく専門性と将来の選択肢を増やす行動まで具体化できます。

転職前に理解しておきたかった四つのこと

1.裁量は、使える資源と結果責任を伴う

決められる範囲が広くても、人員、予算、情報、協力部署が十分とは限りません。裁量という言葉だけでなく、何を使えて、どの結果に責任を持つのかを一組で確認する必要があります。

2.役職名より、プレイング業務の中身が重要になる

管理職や責任者という名称でも、自分で担う実務の割合は会社によって異なります。どの仕事を自ら行い、何人・どの機能と協働し、いつ体制を増やす想定かまで聞く必要があります。

3.変化の多さより、変化の理由と決め方を見る

優先順位が変わること自体は、新規事業では起こり得ます。確認したいのは、顧客や数値などの根拠があるか、誰が決めるか、停止した仕事の影響をどう扱うかです。

4.入社前に仕事の違いを完全には把握できない

面接で確認しても、実際の会議、顧客対応、情報共有の細部までは分かりません。だからこそ、入社後に前提を確かめ直せる上司や経営陣か、役割を修正する対話ができるかを見ます。

個別求人が決まったら、管理職がスタートアップへ転職する前に確認すべき10項目で、任務、権限、資源、経営陣、評価を確認できます。相談先から選びたい場合は、スタートアップ転職で使う転職エージェントの選び方を参考にしてください。

まとめ|専門性を捨てず、仕事の前提を作る側へ移れるかで考える

金融機関からスタートアップへ転職して感じた仕事の違いは、単なるスピードや裁量ではありませんでした。

スタートアップ以外の財務、法人営業、投資審査、リスク管理なども含めて検討する場合は、金融機関から事業会社へ転職する選択肢の全体像で経験別に比較できます。

  • 企画と実行の距離が短く、提案後の仕事が増える
  • 役割の境界にある仕事を見つけ、担当と期限を作る
  • 情報を集め切る前に、次へ進める判断材料を作る
  • 顧客や現場の反応から、優先順位を更新する
  • 金融機関の分析・リスク判断・調整力を、実行のために使い直す

金融機関の経験は、環境を変えると価値がなくなるのではありません。ただし、正確に判断する力だけでなく、その判断を誰がどう実行し、何を学んで次へ進むかまで関わる姿勢が必要です。

転職を決める前に、自分が手放したくない専門性と、新たに引き受けたい責任を分けてください。そのうえで、応募先の事業フェーズ、使える資源、役割の境界が、自分の働き方に合うかを確認することが大切です。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

目次