先代が社長室の椅子から立ち上がったその日から、あなたは会社のすべてを引き継いだことになっている。株式も、取引先との関係も、そして「先代が何十年もかけて積み上げてきたシステム」も。

ところが、いざ社内システムに目を向けてみると、拍子抜けするほど何も分からない。経理システムは誰が契約したものか。受発注に使っているソフトは、どこの会社が作ったのか。サーバーの管理者パスワードは誰が知っているのか。先代に聞こうにも、まだ現場に残っている場合は聞きにくく、完全に引退してしまった場合はもう聞けない。

これは、あなた一人の問題ではありません。中小企業庁の「事業承継ガイドライン」でも、事業承継で引き継ぐべき経営資源は「人」「資産」「知的資産」の3つに分類され、その中でも属人化した業務ノウハウの見える化が承継準備の重要な柱として位置づけられています。裏を返せば、多くの会社でこの見える化が後回しにされたまま承継が進み、後継者が就任後にゼロから調べ直す羽目になっているということです。

株式や役員変更の手続きには、専門家という「頼れる相手」がいます。税理士は税務を、司法書士は登記を、弁護士は契約書を見てくれます。ところが、社内システムについては相談先が驚くほど曖昧です。開発会社は「先代との契約」の範囲でしか動いてくれないことが多く、情報システム部門を持たない中小企業では、誰に聞けばいいのか自体が分からない、という状態に陥りがちです。

この記事では、会社を継いだ最初の1週間で、先代のシステムをどう調査し、何を優先して手を付けるべきかを、時系列に沿って具体的に解説します。専門的なIT知識がなくても、順番通りに進めれば「最低限、業務が止まらない状態」までは持っていけます。

なお、この記事が扱うのは「承継直後にまず何を確認するか」という初動に限った話です。実際に古いシステムを刷新するかどうかの判断や、先代の代からの開発会社との関係をどう見直すかといったテーマは、承継から数ヶ月〜数年かけて取り組む別の課題になります。まずは焦らず、この1週間でやるべきことに集中してください。

この記事で分かること

会社を継いだ直後、先代が使っていた社内システムの実態が分からない状態から、最初の1週間で何を確認し、何を後回しにしてよいかを時系列で整理します。就任初日にやるべき「止血」の作業、3日目までに終えたい全体像の把握、1週間で仕上げたい最低限の管理体制づくりまでを順に扱います。

会社を継いだ最初の1週間を止血・可視化・応急体制の3段階で進める全体スケジュール図。

先に結論を言うと、最初の1週間でやることは大きく3つです。この3つを意識するだけで、手当たり次第に動いて時間を浪費するのを防げます。

  • 止血: 先代の退任・引退をきっかけに業務が止まる、情報が漏れるといった最悪の事態を防ぐ
  • 可視化: 先代の代から何がどこで動いているかを一覧にする
  • 応急の体制: 先代・古参社員の誰に何を聞けばよいか、確認できる状態を確保する

完璧な引き継ぎを1週間で終わらせる必要はありません。むしろ、承継したばかりの社長が「先代のようにすべてを把握しなければ」と気負いすぎることのほうが危険です。焦らず、一つずつ順番に進めていきましょう。

まず深呼吸する。先代の代からのシステムを壊す方が怖い

会社を継いだばかりの社長は、「先代が何十年もかけて作り上げたものを、自分の代で壊してしまうのではないか」という重圧を強く感じがちです。この重圧が、かえって危険な行動につながることがあります。

分からないまま管理画面を触って設定を変えてしまう、「もう使っていないだろう」と判断してアカウントやサーバーを止めてしまう。こうした操作は、取り返しのつかないトラブルに発展しかねません。何年も前に先代の指示で構築され、当時の担当者も退職していて誰も仕組みを覚えていないレガシーシステムほど、一見動いていないように見える部分が実は裏で重要な処理をしている、ということが珍しくないからです。

最初の1週間でやるべきことは「触ること」ではなく「知ること」です。以下の順番を守ってください。

  1. 何が動いているかを調べる(触らない)
  2. 誰が何を管理しているかを調べる(触らない)
  3. 先代・古参社員への確認ルートを確保する(触らない)
  4. ここまで終えてから、必要最小限の操作をする

焦って何かを止めたり削除したりする前に、まず全体像をつかむ。これが、先代のシステムを引き継ぐ際の大原則です。

就任初日にやること(1) 先代の社長室・引き出しの中を確認する

先代が完全にゼロから何も残していない、ということは実はあまりありません。多くの場合、断片的な情報が社長室の引き出し、経理の書類棚、先代のパソコンのデスクトップなどに散らばっています。焦らず、順番に探していきましょう。

まず確認すべき場所を挙げます。

  • 先代の社長室・デスクの引き出し(契約書控え、名刺、業者とのやり取りのメモ)
  • 先代が使っていたパソコンのデスクトップ・ドキュメントフォルダ
  • 経理部門が保管している支払い明細(口座振替やクレジットカードの引き落とし記録から、契約中のサービスを逆引きできる)
  • 顧問税理士・顧問社労士が把握している契約関係(会計ソフト・給与計算ソフトなどは顧問先経由で契約しているケースが多い)
  • 過去の年賀状・お中元のリストにある「取引先」欄(システム開発会社が単なる「取引先」として記録されていることがある)
実務上のコツ: 承継直後は、先代自身も「何をどこに任せているか」を正確には覚えていないことが少なくありません。特に、先代が現場から退いてから年数が経っている場合、記憶よりも紙の記録のほうが正確です。経理の支払い明細は、感情的なやり取りを挟まずに事実を確認できるという意味でも、最初に当たるべき情報源です。

この段階では「整理して台帳を作る」ところまではまだやりません。とにかく手がかりになりそうな紙・データをかき集める、それだけに専念してください。

集めた紙・データは、この時点でシュレッダーにかけたり削除したりしないでください。「これはもう使っていないだろう」と思っても、後になって重要な手がかりだったと分かることがあります。段ボール一箱でも構わないので、一旦まとめて保管しておく場所を確保するところから始めるとスムーズです。

また、先代の代のパソコンやメールアカウントは、承継後すぐに初期化・解約せず、最低でも数ヶ月は保持しておくことを強くおすすめします。開発会社とのやり取りの履歴、サービスの登録メールアドレスなど、パソコンやメールボックスの中にしか残っていない情報は想像以上に多く、後から必要になって「もう消してしまった」となるケースが後を絶ちません。

就任初日にやること(2) 先代・古参の担当者への確認を試みる

先代がまだ会長・相談役として社内に残っている場合、あるいは完全に引退していても連絡が取れる場合は、要点を絞って確認するのが最も効率的です。

ただし、承継直後は先代との距離感に気を遣う場面が多く、「システムのことで根掘り葉掘り聞く」のは気が引ける、という声もよく聞きます。ここは割り切って、以下のように事務的な質問に留めるとやり取りがスムーズです。

  • 「経理・受発注で使っているシステムは、それぞれどこの会社が担当していますか」
  • 「サーバーやドメインの契約者名義は、会社名になっていますか、それとも個人名義ですか」
  • 「パスワードやアカウント情報をまとめたものはありますか」

先代が既に完全に引退し、連絡が取りづらい場合は、当時システム対応をしていた古参の経理担当者や総務担当者に聞くという手もあります。先代よりも実務の細部を把握していることも珍しくありません。

一方で、先代や古参社員への確認は、あくまで「補助線」として使うべきです。相手の記憶違いや、当時と契約内容が変わっている可能性もあるため、聞いた内容は必ず契約書や請求書といった一次情報で裏取りする前提で進めてください。1〜2回の問い合わせで要点を確認したら、それ以上は自力で調べる方針に切り替えることをおすすめします。従業員数が少ない会社では、そもそも「誰から先に聞くべきか」の順番自体で悩むこともあります。従業員10人未満の承継1年目は、誰に聞くかを最初の1ヶ月で決め切るも参考にしてください。

よくある2つの失敗パターン

承継直後の対応でつまずくパターンには、いくつか共通する傾向があります。先に知っておくことで、同じ失敗を避けやすくなります。

パターン1: 「先代に申し訳ない」が先に立ち、確認が遅れる

先代がまだ会社に関わっている場合、「継いだばかりなのに、いきなりシステムのことで質問攻めにするのは気が引ける」と感じ、確認を先延ばしにしてしまうケースがよく見られます。気持ちは理解できますが、この遠慮が長引くほど、後から確認するハードルはむしろ上がっていきます。

先代が現場に残っている期間は限られています。相談役として残る期間は会社によって異なりますが、いずれにせよ「聞ける相手がいる」状態がずっと続くわけではありません。事務的な質問であれば、承継直後のこのタイミングこそ、最も聞きやすい時期だと捉え直してください。

パターン2: 良かれと思って独断で契約を解約・変更してしまう

逆のパターンとして、承継したばかりの社長が「自分の代でしっかりやろう」と意気込み、内容をよく理解しないまま契約を解約したり、担当者を変えたりしてしまうケースもあります。

たとえば、毎月の保守費用が高いと感じて、内容を確認せずに解約を申し出た結果、実は障害対応やデータのバックアップまで含まれた契約だったと後から判明する、といった事例です。契約の解約や変更は、必ず「今、何にいくら払っていて、それが何を含んでいるか」を洗い出したあとに検討してください。この判断を急ぐ必要は、承継直後の1週間にはありません。

古参社員への最初の一声のかけ方

システムの調査を進めていくと、古参社員に協力を求める場面が出てきます。ここでの最初のコミュニケーションの取り方が、その後の関係性に影響することもあります。

古参社員の多くは、先代の時代からのやり方に愛着や誇りを持っています。「このシステム、古くて使いにくいですよね」といった否定から入ると、たとえ事実であっても、身構えられてしまいがちです。承継直後のこの段階では、システムの良し悪しを評価することが目的ではなく、あくまで「現状を正確に知る」ことが目的だと伝わるように話すことが大切です。

「先代の時代からのやり方を否定するつもりはなく、まず何がどう動いているかを把握したい」という趣旨を最初に伝えたうえで、具体的な質問に入ると、協力を得やすくなります。古参社員との本格的な関係構築や、システム刷新への合意形成そのものは、この記事の範囲を超える別のテーマですが、承継直後の第一印象がその後の土台になることは意識しておいて損はありません。

Windows ServerなどのEOL(サポート終了)だけは初週に確認する

これまでの手順は基本的に「調査」にとどめる方針で説明してきましたが、一つだけ例外があります。それが、OS・サーバーのサポート終了、いわゆるEOL(サポート終了)の状況です。

サポートが終了したOS・サーバーは、動作自体は継続しますが、新たに見つかった脆弱性が修正されないまま使い続けることになり、サイバー攻撃の標的になりやすくなります。IPAが公開する情報セキュリティの脅威動向でも、古いシステムの放置は毎年上位の脅威として扱われています。

先代の代から使われてきたサーバーやOSがいつまでサポートされるのかは、契約している開発会社・保守会社に「このサーバーのOSは、いつまでメーカーのサポートを受けられますか」と確認するだけで済みます。すぐに刷新する必要はありませんが、サポート終了時期だけは初週のうちに把握し、期限が近い場合は経営層への報告事項に加えてください。

2日目〜3日目 動いているシステムの全体像を洗い出す

初日で集めた手がかりをもとに、2〜3日目は「今、何が動いているか」の全体像づくりに時間を使います。ここでの目的は精緻な資料作りではなく、「抜け漏れのない一覧」を作ることです。

洗い出すべき項目

以下の項目を、分かる範囲で構わないので一覧化していきます。

項目確認する内容
システム名経理、受発注、勤怠、顧客管理など、業務別に何を使っているか
開発・保守会社どの会社が作った・保守しているか、連絡先はあるか
契約者名義会社名か、先代個人の名義か
サーバー・ドメイン誰が契約し、どこで管理しているか
管理者アカウントログイン情報を誰が知っているか
契約金額・支払い方法月額・年額はいくらで、どこから引き落とされているか

分からない項目は、無理に埋めようとせず「要調査」と記入して先に進みます。完璧な一覧を初日から目指すと、かえって作業が止まってしまいます。

「動いているのに誰も知らない」システムに要注意

洗い出しの過程で、時折「今も動いているが、社内の誰も詳しい経緯を知らない」というシステムが見つかります。先代が個人的な判断で導入し、担当を割り振らないまま先代自身が実質的な管理者になっていたケースです。これは属人化の典型例で、承継のタイミングでまとめて表面化しやすい問題でもあります。

こうしたシステムが見つかった場合、稼働を止める前に必ず「止めたら何が起きるか」を確認してください。古い受発注システムが実は請求書発行の唯一の手段だった、といったケースは珍しくなく、単一障害点(SPOF)になっているシステムを不用意に停止すると、業務全体が止まりかねません。

判断に迷った場合の目安として、「そのシステムが止まったら、今日・明日の業務のどこが止まるか」を古参社員に一言確認してみてください。専門的な説明を求める必要はなく、この一言だけでも、優先度を見極めるための十分な材料になります。仕様書が残っておらず、動きから仕様を推測するしかないシステムが見つかった場合は、仕様書がない先代システムの仕様を、動きから逆算して復元する方法が参考になります。

見落としがちなSaaS・クラウドサービスの契約棚卸し

これまでの説明は、先代の代から使われてきた基幹システムやサーバーを念頭に置いたものだったが、近年はもう一つ、見落とされやすい領域がある。クラウド会計、名刺管理、チャットツール、オンラインストレージといった、月額課金のSaaS(クラウドサービス)の契約だ。

なぜSaaSは見落とされやすいのか

サーバーや自社システムであれば「大きな買い物」として社内で記憶に残りやすいが、月額数千円〜数万円のSaaSは、先代や特定の担当者が個人の判断で契約し、クレジットカードの明細に埋もれたまま誰にも共有されていないことがある。特に、先代が個人名義のクレジットカードで契約していた場合、承継後にカードを止めた途端、サービスが突然使えなくなるという事態が起こりうる。

洗い出しの進め方

先ほど紹介した「先代システム管理台帳」に、以下の観点でSaaS・クラウドサービスの項目を追加しておくと、後々の管理がしやすくなる。

  • 法人・個人どちらのクレジットカード・銀行口座から引き落とされているか
  • 契約者のメールアドレスは誰のものか(退職済み社員のアドレスのままになっていないか)
  • 無料プランから有料プランへ自動的に切り替わる設定になっていないか
  • 似た機能のサービスを重複して契約していないか(乗り換え時に解約し忘れているケース)

すぐに解約や整理をする必要はない。承継直後の1週間では、「どんなSaaSが、誰の名義で、何のために契約されているか」を一覧にすることまでで十分だ。使っていないサービスの解約や、重複契約の整理は、全体像が見えてから落ち着いて進めればよい。

3日目〜5日目 セキュリティの最低限を確保する

全体像が見えてきたら、次はセキュリティ面での最低限の対応に進みます。ここで焦って全てを一新する必要はありません。あくまで「承継のタイミングで生じやすいリスク」を塞ぐことが目的です。

退任者・退職者のアカウントを確認する

先代が完全に会社を離れる場合、先代個人が保有していたシステムのアカウントが有効なままになっていないかを確認します。特に、クラウド会計ソフトや銀行のインターネットバンキングなど、金銭に関わるシステムは優先度が高い項目です。

いきなり完全に削除するのはおすすめしません。アカウントを削除すると、紐づくメールの履歴やファイルの所有権ごと失われる場合があります。まずログインできない状態への無効化にとどめ、業務への影響がないことを確認してから、後日あらためて削除を検討してください。

同様に、先代の代で退職した過去の担当者のアカウントが、削除されずに残っているケースもよく見つかります。承継のタイミングは、こうした古い残存アカウントを棚卸しする良い機会でもあります。

パスワード・管理者権限の所在を確認する

先代しか知らない、あるいは先代と特定の古参社員しか知らないパスワードがある場合、承継後できるだけ早い段階で共有を受けておく必要があります。会社の代表者が交代したにもかかわらず、システムの管理者権限が個人に紐づいたままというのは、事業継続の観点で大きなリスクです。

パスワードの共有を受ける際は、口頭のメモではなく、社内で決めた安全な方法(パスワード管理ツール、施錠できる場所での書面保管など)で記録を残すようにしてください。

契約更新のタイミングを先に把握しておく

洗い出しの過程で、更新時期が近い契約が見つかった場合は、他の項目より優先して確認してください。特に自動更新の契約は、内容を見直す間もなく次の期間へ突入してしまうことがあります。承継直後で全体像がつかみきれていない段階では、「今すぐ解約・変更を判断する」のではなく、「更新日をカレンダーに控えておき、期限までに内容を確認する」というだけでも十分な備えになります。

業務別に見る、承継直後に特に確認しておきたいシステム

洗い出しの優先順位に迷った場合の目安として、業務別によく見られる注意点を挙げておきます。すべてを同時に調べる必要はありません。自社の業種で影響が大きそうなものから着手してください。

承継直後に業務別に確認すべきシステムを整理したチェックリスト図。

経理・会計システム

先代の代から使われている会計ソフトは、税理士事務所とセットで契約されているケースが多く、社内に契約書が残っていないことがあります。まずは顧問税理士に「契約主体は誰か、更新時期はいつか」を確認するのが早道です。インターネットバンキングの管理者権限も、この段階で必ず確認しておきたい項目の一つです。

受発注・在庫管理システム

製造業や卸売業では、先代の代から使い続けている受発注システムが、取引先とのFAX・専用端末でのやり取りと一体化していることがあります。システムそのものだけでなく、「そのシステムを介して、どの取引先とどんなやり取りをしているか」まで把握しておかないと、稼働を止めた際の影響範囲を見誤ります。

給与・勤怠管理システム

給与計算は、社会保険労務士事務所が代行しているケースと、社内の総務担当者が先代の指示のもとで運用しているケースに分かれます。いずれの場合も、承継のタイミングで「誰が最終的な承認者になるか」を明確にしておく必要があります。先代が退任後も慣例的に承認フローに残ったままになっている、という状態は早めに整理しておいたほうが安全です。

顧客管理・営業支援システム

先代が長年の勘と経験で顧客対応をしてきた会社ほど、顧客情報がシステムではなく先代の手帳や記憶の中にとどまっているケースが目立ちます。この場合、システムそのものの調査よりも、先代が個人的に持っている顧客との関係性をどう引き継ぐかという、より難しい課題に直面することになります。この記事の範囲を超えるテーマですが、システムの調査と並行して意識しておく価値はあります。

製造業の生産管理・品番管理システム

製造業では、先代が独自に構築した生産管理システムや、Excelで管理している品番・工程台帳が、実は特定の取引先の仕様に合わせて作り込まれていることがある。担当者の頭の中にしかない「この品番はこの工程を飛ばしてよい」といった例外ルールが多く、システムの調査と並行して、こうした例外運用の存在に気づいておくことが重要になる。取引先ごとの特殊な検収基準や、金型・治具の管理台帳の所在も、この段階で合わせて確認しておきたい項目だ。

いずれの業務領域についても、承継直後の1週間ですべてを深掘りする必要はありません。まずは「何がどこにあるか」の見取り図を作ることを優先し、個別の業務の細部は、台帳が形になったあとに順を追って詰めていく進め方が現実的です。

5日目〜7日目 分かったことを「先代システム管理台帳」としてまとめる

1週間の終わりに向けて、これまで集めた情報を一覧表としてまとめます。IPA(情報処理推進機構)が公開している「中小企業の情報セキュリティ対策ガイドライン」にも、企業の情報資産を管理するための資産管理台帳のひな形が付録として用意されており、こうした汎用フォーマットを土台にするのも一つの方法です。

台帳には、少なくとも以下の情報を記録してください。

  • システムの名称と用途
  • 開発・保守を担当している会社の名前と連絡先
  • 契約者名義(会社名か個人名か)
  • 契約金額・更新時期
  • 管理者アカウントの情報(保管場所)
  • 「要調査」として残っている未解決の項目

この台帳は、いわゆるシステム管理台帳の第一版です。1週間で作る段階では粗くて構いません。重要なのは、承継直後の時点で分かっていること・分かっていないことを、後から見返せる形で記録しておくことです。数ヶ月後、実際にシステムの刷新や見直しを検討する際に、この台帳が土台になります。この1週間で作った粗い台帳を、その後どう本格的な記録として育てていくかについては、引き継ぎ書がない会社が承継後すぐに始めるシステム記録術で詳しく扱っています。

1週間で目指すのは「完璧」ではなく「最悪を防ぐ状態」

ここまで紹介した内容を1週間ですべて完璧にこなせる後継者は、まずいません。目指すべきは、次の3つの状態が最低限確保されていることです。

1週間の承継対応で目指すゴールが「完璧な把握」ではなく「最悪の事態を防ぐ状態」であることを示す概要図。

  • 動いているシステムの一覧が(粗くても)ある
  • 緊急時に誰に連絡すればよいかが分かっている
  • 退任者・退職者の重要アカウントが無効化されている

分からない部分は「要調査」として記録し、経営層や役員会には「分かったこと」と「分かっていないこと」を正直に報告してください。恒久的な立て直しは、このあと数ヶ月かけて取り組むテーマです。

ここで「分からないことがある」と正直に報告することを恥じる必要はありません。先代がすべてを把握した状態で承継したケースのほうがむしろ稀で、多くの後継者が同じ状態からスタートしています。分からないことを分からないと言えることは、むしろ現状を正確に把握しようとしている証拠でもあります。

古いシステムを「延命するか、作り直すか」といった本格的な判断や、先代の代からの開発会社との関係の見直しは、この1週間で決める必要はありません。まずは現状を正しく把握することに専念し、判断はそのあとで構いません。

同様に、社内システムの本格的な刷新を検討するタイミングも、承継直後である必要はありません。まずは1週間かけて現状を把握し、そのうえで数ヶ月〜1年程度かけて、何から手をつけるべきかをじっくり見極めていく進め方のほうが、多くの会社にとって現実的です。焦って大きな意思決定をする前に、まずは足元を固めることを優先してください。

よくある質問

Q. 引き継ぎ書が全くない場合、何から手をつければよいですか。

まずはシステムを触らず、社長室の引き出しやパソコン内、経理の支払い明細から手がかりを集める「情報収集」から始めてください。次に退任者・退職者アカウントの無効化などの最低限のセキュリティ対応を行い、そのあとで動いているシステムの洗い出しに進みます。この順番を守ることが重要です。

Q. 先代にシステムのことを聞いてよいものか迷います。

先代がまだ現場や相談役として関わっている場合、契約者名義や管理者アカウントの保管場所など、要点を絞って事務的に確認するのは現実的な手段です。ただし、聞ける期間には限りがあるため、遠慮しすぎず承継直後のタイミングで確認しておくことをおすすめします。

Q. 1週間で全部を把握しきれない場合はどうすればよいですか。

1週間で目指すのは完璧な把握ではなく「最悪の事態を防ぐ状態」を作ることです。分からない部分は台帳に「要調査」として記録しておき、経営層には分かったことと分かっていないことを正直に報告してください。恒久的な立て直しは、その後数ヶ月かけて取り組むテーマです。

Q. 先代個人の名義になっている契約が見つかった場合、どうすればよいですか。

サーバーやドメイン、クラウドサービスの契約が会社名ではなく先代個人の名義になっているケースは珍しくありません。すぐに名義変更を進める必要はありませんが、「誰の名義で契約されているか」を台帳に記録しておき、名義人である先代と連絡が取れるうちに、変更の必要性について相談しておくことをおすすめします。

まとめ

会社を継いだ直後は、株式や経営権だけでなく、先代が積み上げてきたシステムという見えにくい経営資源も同時に引き継ぐことになります。中小企業庁の事業承継ガイドラインが「人・資産・知的資産」の引継ぎを承継準備の柱に位置づけているように、システムの実態把握は本来、承継前から進めておきたいテーマです。とはいえ、それが果たされないまま承継が進んでしまった場合でも、最初の1週間で「止血・可視化・応急の体制」の3つを押さえれば、致命的な事態は避けられます。

焦って先代のシステムに手を加える前に、まず知ることから始めてください。それが、承継後のあらゆる判断の土台になります。

承継直後は、株主総会や取引先への挨拶回り、金融機関との面談など、システム以外にもやるべきことが山積みの時期です。その中でシステムの調査にまとまった時間を割くのは簡単ではありませんが、この最初の1週間で最低限の全体像さえつかんでおけば、その後の数ヶ月は落ち着いて優先順位を組み立てられるようになります。逆に、この初動を後回しにしたまま数ヶ月が過ぎると、「今さら聞きにくい」状態のまま、いつか大きなトラブルとして表面化するリスクを抱え続けることになります。

先代から受け継いだのは、会社の看板や取引先との信頼関係だけではありません。目に見えにくいシステムという資産も、同じように大切に引き継ぐべきものの一つです。最初の1週間を、その第一歩として使ってください。

この記事で紹介した手順は、あくまで承継直後の初動に限った内容です。実際にシステムを刷新するかどうかの検討、古参社員を巻き込んだ合意形成の進め方、先代の代からの開発会社との関係の見直しといった、より踏み込んだテーマについては、それぞれ別の記事で詳しく扱っています。まずはこの1週間の初動を終えたうえで、次のステップに進んでください。