前任者のいない状態で開発会社に要件を伝えるための資料の作り方

「情シス担当、よろしく」と言われて肩書きを引き継いだものの、前任者はすでに退職していて連絡が取れない、あるいは在籍はしているが他部署に異動してしまい詳しい話を聞ける状況にない——30〜100人規模の会社でひとり情シスに任命される人の多くが、こうした「引き継ぎゼロ」の状態からスタートします。開発会社に要件を伝えようにも、そもそも今のシステムが何のために、どんな経緯で、誰の判断で作られたのかという土台の情報がありません。

開発会社に渡す要望資料をどんな項目でまとめ、どう書けば伝わるかという書き方そのものについては、すでに別記事で具体的に解説されています。この記事では、その書き方を実践する前段階、つまり「引き継ぎがない状態から、資料に書ける情報をどうやって集めるか」という情報収集のプロセスに焦点を当てます。

この記事で分かること

前任者からの引き継ぎがほとんどない状態で情シス担当になった人が、開発会社に渡す要件資料を作るまでに、何を、どこから、どんな順番で調べればよいかを解説します。

• 前任者がいなくても現状のシステムを把握するための情報源の探し方
• 社内の関係者から必要な情報を引き出すためのヒアリングの進め方
• 集めた断片的な情報を要件資料の形に整理する手順
• 「分からないこと」をそのまま開発会社に伝えることの重要性

要件資料そのものの項目立てや文章の書き方は範囲外とし、資料の材料をどう集めるかに絞って解説します。

引き継ぎゼロは特殊なケースではない

まず押さえておきたいのは、30〜100人規模の会社で情シス業務の引き継ぎが機能していないことは、決して珍しい状況ではないということです。専任の情シス担当者を置く余裕がない会社では、情シス業務は総務や経理の担当者が「片手間」で担ってきたことが多く、その担当者が退職や異動をする際、正式な引き継ぎ資料が作られないまま業務だけが次の人に渡される、という構造が起きやすくなります。

中小企業庁が公表している中小企業白書でも、中小企業がDXを進めるうえでの課題として「DXを推進する人材が足りない」という回答が高い割合を占めることが示されています。人材が慢性的に不足している環境では、担当者の異動や退職のたびに丁寧な引き継ぎ資料を作る余裕自体が生まれにくく、結果として「気づいたら前任者がいなくなっていた」という状況が構造的に発生しやすくなります。これは特定の会社の管理不備というより、限られた人員でシステムを回している中小企業に共通して起きやすい現象だと捉えておくと、必要以上に自分や前任者を責めずに済みます。

前任者を責めても状況は変わりません。重要なのは、「引き継ぎ資料がない」という前提に立ったうえで、自分自身の手でゼロから情報を再構築する手順を持つことです。

情報収集の全体像: 4つの情報源

前任者に直接聞けない場合でも、情報は複数の場所に分散して残っています。次の4つの情報源を順番に当たっていくことで、要件資料に書ける材料を集めることができます。

1. システムそのもの: 実際に稼働している画面、設定、マニュアルの有無
2. 契約書・請求書: 過去にどの会社と、いくらで、何を契約したか
3. 周辺の利用者: 実際にそのシステムを日常的に使っている現場の社員
4. 外部の関係者: 契約している開発会社やベンダーのサポート窓口

情報収集を始める前に心構えとして持っておきたいこと

引き継ぎゼロの状態から情報を集める作業は、地道で報われにくく感じられることがあります。パズルのピースを一つひとつ拾い集めるような作業であり、途中で「本当にこれで正しい情報にたどり着けるのか」という不安がよぎることもあるでしょう。

ここで意識しておきたいのは、目的はあくまで開発会社に要件を伝えられる程度の材料を揃えることであり、社内の情報を100%完璧に復元することではないという点です。前任者が退職前にどんな判断をしていたかをすべて解明する必要はなく、「今、何が課題で、何を解決したいか」という現在進行形の情報さえ集まれば、要件資料としては十分に機能します。過去の経緯を掘り下げすぎて時間を浪費するより、現在と未来に焦点を当てて情報を集める方が、限られた時間の中では効率的です。

情報源1: システムそのものから読み取る

最初に手をつけるべきは、実際に稼働しているシステムそのものです。ログイン画面のURLやドメイン、管理画面に表示されている会社名やサポート連絡先、契約プランの表示など、システムの中に残っている情報は、前任者への確認なしに自分で調べられる貴重な手がかりです。

• 管理画面の「契約情報」「プラン」「サポート」といったメニューを確認する
• 請求メールの送信元アドレスやドメインから、契約している会社を特定する
• パスワード管理ツールやブラウザの保存パスワードから、他に使われているシステムがないか確認する
• デスクトップやファイルサーバーに残っている操作マニュアル、設定手順書がないか探す

こうした作業で全体像がすでにつかめている場合は、システム管理台帳の形でまとめておくと、この後の作業がスムーズになります。まだ台帳自体を作っていない場合は、この機会に簡単な一覧を作っておくことをおすすめします。

システム台帳の最小構成

台帳と聞くと大掛かりな管理表を想像しがちですが、引き継ぎゼロの状態から作る最初の台帳は、次の項目だけで十分機能します。

この表を、社内で確認できたシステムの数だけ横に並べていくイメージです。最初から完璧な情報を埋めようとせず、分かる範囲だけ埋めて空欄はそのまま残しておきます。空欄が多いこと自体が「この会社の情シス管理がどの程度属人化していたか」を示す重要な記録にもなります。

情報源2: 契約書・請求書から経緯をたどる

システムの中身だけでは、「なぜこのシステムを選んだのか」「いつから使っているのか」といった経緯までは分かりません。これを補うのが、経理部門が保管している契約書や請求書です。

経理担当に「システム関連の支払いが分かる資料を見せてもらえますか」と依頼すれば、月額でいくら支払っているシステムがいくつあるか、契約開始時期はいつかといった情報が、比較的短時間で把握できます。契約書が残っていれば、契約形態（買い切りかサブスクリプションか）や、解約時の条件、データの取り扱いに関する条項なども確認できます。稟議を通す段階で予算所属を確認する際にも、この経理担当とのやり取りは役立つため、早い段階で関係を作っておくと後々の作業も進めやすくなります。

情報源3: 現場の利用者からヒアリングする

システムと契約書だけでは、「実際にどう使われているか」「どこに不満があるか」という運用実態までは見えません。ここで頼りになるのが、日常的にそのシステムを操作している現場の社員です。

ヒアリングでは、次のような質問を用意しておくと、断片的な情報を効率よく引き出せます。

• 「このシステムで、普段どんな作業をしていますか」
• 「使っていて困っていることや、面倒だと感じる作業はありますか」
• 「以前、このシステムを導入したときの担当者や経緯を知っていますか」
• 「他に、Excelや紙で管理していて『本当はシステム化したい』と思っている業務はありますか」

現場の社員は、システムの契約経緯までは知らなくても、日々の使い勝手については誰よりも詳しい情報を持っています。特に最後の質問は、要件資料に書くべき「解決したい課題」の材料を直接引き出せるため、時間をかけて聞く価値があります。複数の部署でExcelが乱立している場合は、属人化が進んでいる兆候でもあるため、ヒアリングの過程でその実態も併せて把握しておくとよいでしょう。

誰に聞けばよいか分からないときの探し方

ヒアリング先が分からない場合、最も手っ取り早いのは、そのシステムに関する問い合わせや不具合報告が過去に社内チャットやメールでどこに飛んでいたかを検索することです。「〇〇システム」「エラー」「使い方」といったキーワードで社内のチャットツールを検索すると、過去に困って相談していた社員が浮かび上がってきます。その人に直接連絡を取れば、少なくとも「日常的にこのシステムを触っている人」という条件は満たせます。

また、部署ごとの管理職に「このシステムを一番よく使っている人を教えてほしい」と一声かけるだけでも、ヒアリング対象を効率的に絞り込めます。闇雲に部署全体にアンケートを取るより、キーパーソンを1〜2名特定して深く話を聞く方が、兼任の立場では時間対効果が高くなります。

パスワード管理という別の緊急課題

引き継ぎゼロの状態で情シス業務を引き受けると、要件資料作成の作業と並行して、管理者アカウントのパスワードが誰にも分からなくなっているという事態に直面することがあります。前任者しか知らなかったパスワードが使い回されたまま退職してしまうと、最悪の場合、契約中のシステムにログインできず、解約手続きすら取れなくなります。要件資料作成の前段階として、まずは主要なシステムの管理者アカウントにログインできるかどうかだけでも確認しておくと、後になって身動きが取れなくなる事態を避けられます。

情報源4: 契約先の開発会社・ベンダーに直接問い合わせる

社内の情報だけで足りない部分は、現在契約している開発会社やベンダーのサポート窓口に直接問い合わせることでも補えます。「担当が変わりまして、現在の契約内容や導入時の経緯を確認したいのですが」と伝えれば、多くのベンダーは丁寧に対応してくれます。

このとき、次の情報を確認しておくと、要件資料の土台として役立ちます。

• 現在の契約プランと、契約に含まれる機能の範囲
• カスタマイズの有無（標準機能のままか、自社向けに手が加えられているか）
• ソースコードやデータの所有権が自社にあるか、ベンダー側にあるかどうかの取り扱い
• 解約や乗り換えの際の手続きと、データ移行の可否

特に、ソースコードやデータの権利がどちらに帰属しているかは、新しい開発会社への切り替えを検討する際に極めて重要な情報です。これが不明確なまま新規発注を進めてしまうと、いざ移行しようとした段階で「データを引き出せない」「契約上、他社への引き継ぎができない」といった事態に直面することがあります。特定の会社に依存しすぎている状態はベンダーロックインと呼ばれ、引き継ぎがない状態から情シスを引き受けた担当者ほど、気づかないうちにこの状態に陥っているリスクがあります。

問い合わせ時に身分を証明する準備をしておく

担当者が変わったことをベンダーに伝える際、契約者本人であることの確認を求められる場合があります。会社の登記情報や、以前の担当者名義で契約が結ばれている場合は、名刺や辞令、あるいは上長からの委任を示せる状態にしておくと、問い合わせがスムーズに進みます。特に、退職した前任者個人のメールアドレスで契約されているようなケースでは、本人確認の手続きに時間がかかることもあるため、早めに動き出すことが重要です。

集めた情報を要件資料の「材料」として整理する

4つの情報源から集めた断片的な情報は、そのままでは開発会社に渡せる形になっていません。次のように、情報の種類ごとに仕分けておくと、この後の資料作成がスムーズになります。

この表の「不明点」の欄は、消してしまわずにそのまま残しておくことが重要です。要件資料の作り方そのものは要件のまとめ方: 開発会社に伝わる資料の作り方で詳しく解説されていますが、そこで示されている項目のすべてを、引き継ぎゼロの状態から完璧に埋められることはまずありません。

メール履歴に残る「痕跡」を掘り起こす

前任者本人に連絡が取れなくても、その人が使っていたメールアカウントや共有フォルダが会社に残っている場合、そこに過去のやり取りの痕跡が眠っていることがあります。特に次のようなキーワードでメール検索をかけると、当時の経緯を示す資料が見つかることがあります。

• 「見積もり」「御見積書」「提案書」といった発注関連のキーワード
• 過去に契約したベンダー名や製品名
• 「要件」「仕様」「打ち合わせ議事録」といった検討過程を示すキーワード

過去に一度でもRFP（提案依頼書）やそれに類する資料を作った形跡があれば、たとえ古くても構成の参考になります。ゼロから項目立てを考えるより、過去の資料の骨格を流用して現状に合わせて書き直す方が、作業時間を大幅に短縮できます。RFPという言葉自体に身構える必要はなく、簡易な形で機能する書き方についてはRFPは必要？中小企業の現実的な進め方で解説されています。

前任者のアカウントやフォルダへのアクセス権限がない場合は、総務やシステム管理者権限を持つ人に相談し、業務引き継ぎの一環として閲覧権限を得られないか確認してみる価値があります。個人のプライベートなやり取りではなく、あくまで業務上の記録を探しているという趣旨を明確に伝えれば、多くの場合は協力を得られます。

「分からない」をそのまま書くことの価値

引き継ぎがない状態で要件資料を作る担当者が陥りやすい失敗は、分からないことを無理に埋めようとして、不確かな情報をあたかも確定情報のように書いてしまうことです。これは開発会社に誤った前提を伝えることになり、後になって「聞いていた話と違う」というトラブルの火種になります。

正しい対処は、分からないことは「不明」「要確認」とそのまま明記することです。開発会社は、要件がすべて完璧に固まっている前提で提案しているわけではなく、むしろ「何が分かっていて、何が分かっていないか」が明確な資料の方が、的確な質問や提案を引き出しやすくなります。曖昧な情報を無理に断定して書くよりも、確度の低い情報だと分かる形で残しておく方が、専門家である開発会社にとってもかえって扱いやすい資料になります。

現状の課題: 顧客情報が営業部のExcelと経理部のシステムで別々に管理されており、二重入力が発生している（推定）。

不明点: いつからこの運用になっているか、当時なぜ連携させなかったかの経緯は不明。導入時の担当者は退職済みで確認不可。

このように「推定」「不明」という言葉を使ってでも、正直に情報の確度を書き分けることが、結果的に開発会社との認識のズレを防ぎます。

ヒアリング疲れを避けるための時間配分

兼任で情シス業務を担う立場では、社内の関係者へのヒアリングに割ける時間も限られています。全部署、全担当者に話を聞こうとすると、それだけで数週間かかってしまい、本業に支障をきたします。

優先順位としては、まず日常的にシステムを最も多く使っている部署・担当者に絞って話を聞き、そこで得られた情報をベースに要件資料の骨子を作ってしまうのが現実的です。他部署の意見は、資料がある程度形になった段階で「この内容で合っていますか」と確認する形で後から拾う方が、ヒアリングの往復回数を減らせます。

稟議の段階ですでに現状の課題を簡潔にまとめている場合は、その内容を要件資料の「現状の課題」の欄にそのまま転用できます。稟議と要件資料を別々にゼロから書くのではなく、稟議で使った文章を土台に要件資料へ発展させていくと、二度手間を避けられます。稟議の通し方については30-100人規模で初めて外部に開発を発注するときの社内稟議の通し方で扱っています。

「不明点だらけ」でも動き出してよい理由

要件資料の「不明点」欄がなかなか埋まらないまま、それでも発注に向けて動き出さなければならない場面もあります。ここで足踏みを続けるより、分かっている範囲だけでまず開発会社に相談してしまう方が、結果的に早く前進できることが多いものです。

開発会社にとっても、要件が100%固まった状態で相談が来ることの方がむしろ稀です。特に、いきなり大規模な発注をするのではなく、小さな範囲で試作してみるPoC（概念実証）という進め方を取れば、不明点を抱えたまま大きなリスクを取ることなく、要件を固めながら開発を進めることができます。小さく発注して試す考え方については、小さく発注して試す: PoC発注のすすめで詳しく解説されています。引き継ぎゼロという不利な状況でも、完璧な資料を待たずに専門家の力を借りるという選択肢があることを覚えておくと、精神的な負担も軽くなります。

要件資料ができたら相見積もりへ

情報収集を終えて要件資料の骨子ができたら、次は複数の開発会社に問い合わせて相見積もりを取る段階に進みます。引き継ぎゼロの状態から集めた情報は完璧ではないかもしれませんが、「不明点」まで含めて正直に伝えることで、開発会社側からも適切な質問が返ってきて、要件そのものがブラッシュアップされていきます。1人で相見積もりを効率よく回す具体的な手順はひとり情シスが1人で相見積もりを取って開発会社を比較する実務手順で解説しています。

次の担当者のために記録を残す

情報収集の過程で苦労した経験は、そのまま次に情シス担当が交代するときの資産になります。今回、自分が前任者の不在に苦しめられたのと同じ状況を、次の担当者に繰り返させないために、今回集めた情報はそのまま捨てずに、簡単な引き継ぎメモとして残しておくことをおすすめします。

大掛かりな文書を作る必要はなく、この記事で紹介したシステム台帳の表に、契約経緯や連絡先、パスワード管理の方法などを追記していくだけで十分です。属人化した状態を次の世代に持ち越さないという意識は、単発の要件資料作成にとどまらず、情シス担当としての土台作りにもつながります。属人化そのものの問題点や対処については、用語集の「属人化」の項目でも解説していますが、今回の経験を通じて痛感したその弊害を、自分の代で少しでも解消しておくという姿勢が、長期的には会社全体の資産になります。

開発会社に相談するタイミングを先延ばしにしない

引き継ぎゼロという困難な状況にいると、「もっと情報を集めてから相談しよう」という気持ちになりがちですが、実際には情報収集と並行して、早い段階で開発会社に一度相談してみることをおすすめします。開発会社は、要件が固まりきっていない相談にも日常的に対応しており、むしろ「何が分かっていないか」を一緒に整理してくれることも少なくありません。

初回の打ち合わせで聞かれる質問に答えられるよう、この記事で集めた材料を持参すれば、たとえ不完全であっても建設的な打ち合わせになります。開発会社との初回打ち合わせで聞くべきことについては、開発会社との初回打ち合わせで聞くべきことで整理されているため、事前に目を通しておくと、当日の会話がより実りあるものになります。

よくある失敗パターン

失敗1: 完璧な資料ができるまで開発会社に相談しない

引き継ぎがない状態から100点の要件資料を作ろうとすると、いつまで経っても発注に進めません。7割程度の情報が集まった時点で、一度開発会社に相談してみるという判断も必要です。専門家である開発会社と話すことで、自分では気づけなかった論点が見えてくることもあります。

失敗2: 前任者を探すことに時間をかけすぎる

退職した前任者への連絡を試みること自体は悪くありませんが、連絡が取れない、あるいは協力を得られない場合に、そこに固執して時間を浪費してしまうのは避けるべきです。前任者に頼らず情報を再構築する方法があることを、この記事で示した4つの情報源が裏付けています。

失敗3: 現場へのヒアリングを省略する

システムと契約書の情報だけで要件資料を作ろうとすると、実際の運用実態が抜け落ちた資料になりがちです。手間を惜しんでヒアリングを省略すると、開発会社に伝わる「課題」が机上の空論になり、結果的に的外れな提案を招くことがあります。

情報収集にかかる現実的な期間

ここまで紹介した4つの情報源をすべて当たるには、兼任の立場でどれくらいの期間がかかるものでしょうか。目安として、次のようなスケジュール感で見積もっておくと、本業との両立がしやすくなります。

すべて合わせると、着手から要件資料の骨子ができるまでに、おおよそ3〜5週間程度を見込んでおくと現実的です。焦って1〜2週間で終わらせようとすると、ヒアリングが不十分なまま資料を作ることになり、後で開発会社との打ち合わせの中で「実はこの部分も確認が必要だった」という手戻りが発生しやすくなります。

まとめ

前任者からの引き継ぎがない状態でも、システムそのもの・契約書や請求書・現場の利用者・契約先のベンダーという4つの情報源を順番に当たっていけば、要件資料に書ける材料は着実に集められます。集めた情報に不明点が残っていても、それを隠さずそのまま開発会社に伝えることが、後のトラブルを防ぐ最も確実な方法です。完璧な資料を目指すより、分かっている範囲を正直に整理し、早い段階で専門家である開発会社に相談する姿勢が、引き継ぎゼロという不利な状況を乗り越える近道になります。

そして、今回の情報収集で得た知見は、自分のためだけでなく、次にこの椅子に座る誰かのためにもなります。同じ苦労を繰り返させないための最小限の記録を残しておくことも、引き継ぎゼロの連鎖を断ち切る小さな一歩です。

引き継ぎゼロという状況は、担当者にとって不安の種であると同時に、既存のやり方にとらわれず、現状の課題を一から見つめ直す機会でもあります。前任者の判断を疑いなく踏襲するのではなく、「本当に今のやり方が最適か」を自分の目で確認しながら情報を集めていく過程そのものが、これから開発会社と対等に会話するための土台を作ってくれます。

情報収集の過程で見つかった不整合や属人化の実態は、それ自体が要件資料に書くべき貴重な材料でもあります。「なぜこうなっているのか誰も説明できない」という状態こそが、システム化によって解消すべき本質的な課題であることも少なくありません。焦らず一歩ずつ情報を積み上げていく先に、開発会社に自信を持って渡せる要件資料が見えてきます。

参考にした一次情報

• 中小企業庁「2025年版 中小企業白書」第1部第1章第5節（DX推進人材の不足に関する記述）: https://www.chusho.meti.go.jp/pamflet/hakusyo/2025/chusho/b1_1_5.html