個人事業主の顧客管理｜取引先・担当者・履歴を分けて記録する方法

※本記事にはPRを含む場合があります。

こんにちは。『脱会社員』脱サラを応援し続けるブログ、運営者の『なかびー』です。

個人事業主の顧客管理は、名刺やメールアドレスを一つの表に集めれば完成するわけではありません。同じ会社から別の制作案件を受けたり、途中で担当者が替わったりすると、「今は誰に確認するのか」「以前の合意はどの案件の話か」が分かりにくくなります。最初に整えたいのは、取引先・担当者・案件・やり取りの履歴を区別し、必要な関係だけを結ぶ台帳です。

この記事では、法人向けの資料や画像の制作を請け負う小規模な個人事業を想定します。必要な項目の決め方から、重複の整理、担当変更、保存先の確認、保管の見直しまでを順に解説します。特定のアプリの操作を覚える前に、紙や表計算でも説明できる情報の構造を作ることが目標です。

登場する「架空取引先A」「架空担当者アオ」「制作物甲」などの名称、ID、日付、記入内容は、すべてこの記事の説明用に作った架空例です。実在する人物や企業の情報、受注実績、実測した改善効果ではありません。図版も生成した説明用イメージで、特定製品の画面や公式の台帳様式ではありません。

個人情報に関する公式情報は2026年10月6日（日本時間）時点で確認しています。ここで紹介する項目や点検周期は編集上の提案であり、全業種の法令対応を保証するものではありません。医療など特別な情報を扱う仕事や、国外への情報提供を伴う運用は、個人情報保護委員会の案内や専門家に確認してください。

何のために顧客情報を残すかを先に決める

困った場面から必要な記録を逆算する

台帳を作る前に、最近の仕事で情報を探した場面を書き出してみましょう。例えば、修正の確認先が見つからなかった、同じ会社の別案件を取り違えた、納品後にどの版を渡したか分からなかった、という場面です。「顧客を管理する」という大きな目的を、このような具体的な確認に分けると、何を記録すれば役立つかが見えてきます。

今回の架空例では、資料制作を一人で受託する事業者が、進行中の連絡、納品物の確認、納品後の問い合わせのために記録を残します。仕事の相手が法人でも、担当者の氏名と業務用メールアドレスなどを結び付ければ、個人情報に当たり得ます。会社の仕事の情報だから個人情報ではない、とまとめて判断しないことが大切です。

個人情報保護委員会のQ4-12は、事業の規模にかかわらず、事業用の個人情報データベース等を扱う場合について説明しています。少人数で働く個人事業主だから対象外、という前提では設計しないでください。台帳の便利さと、本人に説明できる取扱いを一緒に考えます。

※表は横にスクロールできます。

この一覧は、この記事の制作受託例に合わせた設計表です。業務によって必要な項目は変わりますが、欄を追加するたびに「どの場面で使うか」を一つ説明する、という考え方は使えます。説明できない欄は、将来役立つかもしれないという理由だけで必須項目にしないようにしましょう。

利用目的は、相手が想像できる具体性にする

利用目的を「サービス向上のため」だけにすると、相手はどんな仕事に情報を使われるのか想像しにくくなります。個人情報保護委員会のQ2-1では、本人が合理的に予測できる程度まで、利用目的を具体化する考え方が示されています。自分が取り扱う制作業務と、連絡・確認・納品後の対応などの用途を対応させて検討します。

ただし、台帳の内側で目的欄を作っただけでは、相手に利用目的を示したことにはなりません。申込書やウェブの入力画面などから本人に記入してもらい、直接取得する場合は、原則として利用目的の明示が必要です。取得状況から目的が明らかな場合の例外もありますが、Q4-17の条件を確認せず、すべてのフォームで説明を省いてよいと考えないでください。

取引の連絡先として登録できたことと、新サービスの案内に自由に使えることも分けます。制作の確認に使う連絡先を、そのまま広告配信用の一覧へ移す前提では設計しません。台帳上は「記録している目的」と「その目的を相手にどのように示したか」の確認場所を分けておくと、別の用途を始めるときに見直しやすくなります。

集めない項目と、持ち込まない資料を決める

便利そうな台帳ひな形に、誕生日、自宅住所、家族、趣味などの欄が付いていても、そのまま採用する必要はありません。今回の法人向け制作例で、業務用の窓口だけで連絡できるなら、私用の連絡先を追加する理由を先に確かめます。空欄をなくすことを優先して、不要な情報を相手へ尋ねるのは本末転倒です。

勤務先で使っていた顧客名簿を独立後の台帳へ転記したり、別の発注者から預かった情報を自分の顧客一覧へ混ぜたりすることも避けます。情報を見られたことと、自分の事業で自由に利用できることは同じではありません。取り扱う根拠や契約上の条件が違う情報は、便利さだけで一つにまとめないでください。

最初の成果物は、前の表のような「目的・使う場面・項目・集めない情報」の一覧で十分です。後から記録が増えたときは、この一覧に戻って、使わなくなった項目と新しい目的を点検します。台帳が大きくなったから項目を増やすのではなく、説明できる業務上の必要が生まれたときに見直します。

取引先・担当者・案件を別の記録にする

一行が何を表すかをそろえる

「架空取引先A・架空担当者アオ・制作物甲」を一つの欄に入れると、初めの一件は分かりやすく見えます。しかし同じ取引先から制作物乙も受けると、会社名や連絡先をもう一度入力することになります。片方の行だけ連絡先を直したとき、どちらが正しいか分からなくなるのが、この形式の弱点です。

そこで、取引先の一行、担当者の一行、案件の一行を別にします。取引先は契約や発注の相手となる組織、担当者は実際に連絡する人、案件は引き受けた仕事のまとまりです。分けるのは表を増やすこと自体が目的ではなく、変更される理由と時期が異なる情報を、同じ欄へ閉じ込めないためです。

さらに、やり取りは「いつ、何について確認したか」を表す別の記録にします。取引先の基本情報は一件でも、担当者や案件、確認の履歴は複数になることがあります。現在の顧客数だけで一枚の表に収まると判断せず、同じ会社から二件目の依頼が来た場合を想像しておくと、作り直しを減らせます。

※表は横にスクロールできます。

IDは、同じ対象を指すための管理用の印です。上のC・P・J・Hはこの記事独自の記号で、法定の番号でも製品共通の仕様でもありません。紙なら見出しにIDを書く、表計算なら参照先のIDを別の列に置くなど、使う媒体に合わせて同じ関係を表せれば十分です。

名前や並び順をIDの代わりにしない

取引先の正式名称が変わっても、それが同じ組織の名称変更なら、台帳のIDまで変える必要があるとは限りません。反対に、名前が似た別法人を、同じ取引先だと決めつけることもできません。表示する名称と、何を同一の対象として扱うかという判断は分け、変更を確認した根拠を残します。

表の上から一番、二番という位置も、安定したIDにはなりません。並べ替えや行の追加で位置が変わるためです。独立したID欄を用意し、発行済みの番号を別の顧客へ使い回さない運用にします。行番号を指していた紙のメモや別ファイルが、別人の情報を開くようになる事故を防ぐための工夫です。

担当者名も、同名の人がいる前提で扱います。架空担当者アオという表示名が取引先Aと取引先Bにあったとしても、名前だけで同一人物にしません。逆に、一人が複数の案件に関わるたびに新しい担当者を作ると、連絡先の変更箇所が増えます。人物そのものと、どの会社・案件にどう関わるかを分けて記録します。

複数の関係は、小さな関連表へ分ける

一件の案件に確認担当と連絡担当がいる場合、担当者の欄へ二人の名前を読点で詰めるだけでは、役割が分かりません。案件ID、担当者ID、役割、有効な期間を組にした関連表を用意すると、同じ人物が別案件では違う役割を持つことも表せます。役割を「重要人物」のような評価にせず、実際の業務上の関係として定義します。

※表は横にスクロールできます。

この三行から、P-002が二つの案件に関わり、J-001には二人の担当者がいると分かります。担当者の連絡先そのものは担当者表に置き、関連表へ毎回コピーしません。連絡先が変更されたときは、どこを更新するのかが一か所に定まり、役割だけを変える場面と区別できます。

企業向けCRMでも、会社・コンタクト・取引などを関連付ける考え方が使われています。HubSpotの公式説明は、この構造を考える参考になります。ただし、関連付けの上限や利用できる機能には契約条件があり、ここで示した自作表を同社の標準テンプレートとして扱わないでください。

設計が合っているかは、架空の二社、同じ表示名の二人、一社に二案件、という小さな例で確かめます。表示名が同じでもIDで区別でき、案件から正しい取引先へ戻れれば基本の関係は表せています。関係を追うために毎回長い自由文を読み解く必要があるなら、独立した欄へ分ける余地があります。

現在の連絡先と、過去のやり取りを分けて残す

基本項目は現在値、履歴は出来事として記録する

現在の連絡先の欄は、今後の業務連絡に使う値を示します。一方、履歴は、ある時点でどの窓口と何を確認したかを示します。この二つを同じ長いメモにすると、最新の連絡先を探すために過去のやり取りを読み返すことになります。現在値へすぐ到達でき、必要ならそこから変更の根拠へ戻れる形にしましょう。

例えば、架空担当者アオの連絡方法が変更された場合、担当者表の現在の連絡方法を更新し、変更の確認日と根拠を残します。過去の履歴には、その時点で確認した内容が書かれているため、すべてを新しい連絡方法で書き換えません。当時の事実まで新しくすると、なぜその連絡経路を使ったかが説明できなくなります。

ただし、履歴として残すという理由で、古い個人情報を際限なく複製する必要はありません。過去の連絡先の全文を保管する必要があるか、変更があった日と根拠の記録で足りるかは、利用目的と保存理由で判断します。履歴を保つことは、受信した文章や添付資料を台帳へ全部貼り付けることとは違います。

※表は横にスクロールできます。

これは台帳を読み違えないための項目辞書です。同じ「更新日」という名前で、情報の確認日と入力日を兼ねると、コピーしただけの古い連絡先まで最新に見えてしまいます。入力した日、出来事があった日、内容を確かめた日が違う場合は、必要に応じて区別してください。

履歴は対象・事実・根拠をそろえて短く書く

一件の履歴には、いつ、どの案件について、誰との確認を記録するのかをそろえます。要点は業務上の事実に絞り、「対応しにくい人」「多分忙しい」などの印象を人物評価として残さないようにします。台帳を後で自分が読む場合も、推測が事実のように見える記録は誤った判断につながります。

次の架空例では、J-001の制作物甲について、確認対象の版が確定したことを記録します。会話の返答文を作るのではなく、後で元資料へ戻れる最小限の索引として履歴を使っています。実際の送信日時や相手の発言を示す記録ではないため、そのまま実績資料へ流用しないでください。

※表は横にスクロールできます。

この形なら、記録した日が一日後でも、出来事の日付がずれません。また、確認対象の版が確定したことと、受領窓口が未確定であることを分けられます。未確認欄を空欄にすると「特に問題がない」と読み違える場合があるので、分からない事項があること自体を明示します。

リンク先と台帳に、同じ秘密を重ねて置かない

元の業務資料を別の保存先で管理しているなら、台帳には所在を示す情報を置きます。ただし、リンクがあれば誰でも見られる設定になっていないかを確認してください。リンクを書いた台帳の権限が狭くても、リンク先のファイルが公開されていれば、資料側の露出は防げません。台帳と資料それぞれの共有状態を点検します。

添付された契約書や納品物の内容を、検索しやすさだけのために自由メモへ全文転記すると、訂正や保存期限の管理が二重になります。台帳には資料名、対象案件、必要な確認事項を置き、詳しい内容は管理された資料を参照する方法を検討します。パスワードや認証情報を顧客メモへ保管する運用は避けてください。

一つの打ち合わせで二案件を扱った場合は、履歴の関係も確かめます。共通の記録に両案件を結び付ける方法と、案件ごとに要点を分けて同じ根拠資料を参照する方法があります。前者では他案件の情報まで見せてよいか、後者では訂正が片方だけに残らないかを確認します。会話の単位と、閲覧を認める単位が一致するとは限りません。

重複登録・担当変更・案件終了を整理する

似た名前を見つけても、すぐに統合しない

顧客名に株式会社の有無、全角と半角、旧社名と新社名が混ざると、同じ相手を二回登録したように見えることがあります。まず行うのは、候補を見つける作業と、同じ相手だと確かめる作業を分けることです。文字を整えて検索するのは候補探しに役立ちますが、表記が一致したことだけで同一と確定しません。

照合には、取引時に確認した組織名、既存の発注書類、連絡先の由来、関係する案件などを使います。メールアドレスが一致しても部署の共有窓口かもしれず、ドメインが同じでも同じ人物とは限りません。逆に異動や名称変更で情報が変わることもあります。一つの項目を万能な本人確認の代わりに使わないことが重要です。

確認できない段階では「重複候補」として保留し、どの点が未確認かを残します。候補を減らすために不確かな統合を進めるより、別々の記録のまま関係を調べた方が、別顧客の履歴を混ぜずに済みます。保留した記録を、送付先として安易に再利用しないよう、確認中であることも分かる表示にします。

ケース1：同じ取引先を二重登録した場合

架空例として、C-001「架空取引先A」とC-009「架空取引先A・略称」が、同じ発注書の相手を指していると確認できた場面を考えます。片方の行を消す前に、両方へ結び付いている案件、担当者、履歴、資料の参照を一覧にします。名称を一つにしただけで関連先が残っていると、情報が途中で途切れます。

統合後に使うIDを決め、どの情報を採用するかを項目単位で確認します。新しい行だから正しい、空欄が少ないから正しい、とは限りません。元資料との照合で現在値を決め、旧IDと新IDの対応、実施日、判断の根拠を記録します。旧記録の扱いは利用する仕組みや復元可能性を確認し、無計画な一括削除で済ませないようにしましょう。

ケース2：案件の途中で担当者が替わった場合

J-001の確認窓口がP-001からP-003へ替わったなら、P-001の人物名を新担当者名へ上書きしません。それでは過去の履歴までP-003の発言や判断に見えてしまいます。P-003の記録を作るか既存記録を確認し、案件との関連付けを変更します。以前の関連には、分かる範囲で担当終了日と変更の根拠を持たせます。

担当変更の連絡があっても、すべての役割が移ったと決めつけないでください。制作内容の確認窓口だけ交代し、納品物の受領窓口は変わらない場合があります。関連表で役割を区別していれば、どこを変更すればよいかが明確になります。新担当者に渡す資料の閲覧範囲も、過去の全案件を一括で共有する前に確かめます。

ケース3：一つの案件が終了した場合

J-001が終了しても、同じ取引先のJ-002が進行中なら、取引先C-001を削除する理由にはなりません。案件の状態を終了にし、未確認事項や保存が必要な資料を点検します。顧客と今後連絡する必要、終了案件の説明に記録が必要な理由、不要になった自由メモを、それぞれ分けて判断します。

「休眠顧客」「取引終了」といった取引先の状態も、案件の終了と同じ欄で管理しない方が混乱を減らせます。相手との取引関係が続いているのか、個別の仕事が終わったのか、台帳の情報を保管する必要があるのかは別の問いです。状態名は、日常で何を判断するための印なのかを定義して使ってください。

※表は横にスクロールできます。

実際に修正する前には、対象と変更内容を小さな確認票にまとめます。「何を同一と判断したか」「変える欄はどこか」「関連先はいくつあるか」「誤りが分かったとき戻せるか」を記入してください。一人事業でも、作業前の自分と作業後の自分が同じ基準で点検できるようになります。

修正後は、変更した一覧だけで終わらせず、案件から担当者へ、担当者から履歴へ、と実際にたどります。件数が合っていても、関係する先が別の人物へずれていれば正しい整理ではありません。迷う統合は保留し、確認できた訂正だけを確実に反映する方が、台帳への信頼を保てます。

保存先と閲覧・編集できる人を確認する

紙・表計算・CRMは、使う場面と管理条件で選ぶ

紙は持ち歩かず決まった場所で確認する用途、表計算は項目と並びを柔軟に整える用途、CRMは複数の記録と関係を継続して扱う用途などが考えられます。ただし、紙なら安全、専用サービスなら更新漏れがなくなる、というものではありません。自分が実際に管理できる保存先と、必要な人へ必要な情報だけを渡せる方法を選びます。

選ぶときは登録件数だけでなく、誰が編集するか、外出先で使うか、資料と関連付けられるか、出力して別の保存先へ移せるかを確認します。無料で始められても、履歴や関連付けを出力できなければ移行に手間がかかります。現在の機能だけでなく、利用を終えるときの出口も最初に調べておくと判断しやすくなります。

※表は横にスクロールできます。

練習サービスに実際の顧客台帳を読み込ませる必要はありません。この記事のような架空の記録で、同名、担当変更、二案件の関連付けを試します。氏名だけ架空へ置き換えても、メールアドレスや履歴に実情報が残っていれば、架空データにはなりません。試すための記録は最初から独立して作ってください。

共有は、見る・直す・持ち出すを分けて点検する

自分以外に制作補助を頼む場合、案件の内容を見てもらう必要があっても、顧客全員の連絡先や過去の契約まで渡す必要があるとは限りません。台帳全体へのアクセスを先に渡すのではなく、その人に必要な案件と項目を確認します。共有の法的な扱いと契約上の条件も検討し、操作上の権限設定だけで済ませないようにします。

閲覧、編集、出力、共有設定の変更は別の能力です。閲覧だけにしたつもりでも、利用する仕組みによってはコピーやダウンロードが可能な場合があります。画面上で不要な列を隠すことと、情報へのアクセスを制限することも同じではありません。自分の管理者画面だけで判断せず、相手側で何ができるかを確かめます。

一人で使う場合も、仕事用のファイルが家族と共用する端末や自動同期先に広がっていないかを見ます。アカウントの認証、端末の更新、紛失時の対応、バックアップの扱いを、自分の環境に合わせて決めてください。個人情報保護委員会のQ10-5は、規模や情報の性質・量などのリスクに応じた安全管理を求めており、小規模なら何もしなくてよいという意味ではありません。

クラウドは、提供者の取扱いと契約を確認する

クラウドへ個人データを置く場合の判断は、単にデータを保存するかどうかだけでは決まりません。Q7-53では、提供事業者が個人データを取り扱うこととなっているかが基準とされています。取り扱わない旨の契約条項と適切なアクセス制御などを確認する必要があり、「クラウド」というサービス名だけで結論を出せません。

その条件で個人データの提供に当たらない場合、同Q&Aでは第三者提供の本人同意や委託先の監督義務の扱いを説明しています。しかし、Q7-54が示すように、利用する事業者自身の安全管理は残ります。契約を読む作業と、共有設定や運用を確かめる作業の両方が必要です。

国外の事業者が提供するクラウドを利用する場合は、提供者の所在地、サーバの所在、情報の取扱いなども調べます。Q10-25は、一定の場合、国内サーバに保存する場合でも外国の制度等の把握が必要になることを説明しています。サーバが日本にあるという一点で、国外に関する確認を終えないようにしてください。

ここまでのQ&Aは、すべてのクラウド利用の適法性を一括で判定するものではありません。提供者が実際に情報を取り扱う契約や、国外への提供を伴う構成など、条件が変われば検討も変わります。契約文から分からない点は、サービス提供者へ取扱条件を確認し、法的な判断は個人情報保護委員会の案内や専門家に相談します。

アクセスを終える日と、復元できる範囲も確認する

外部の補助担当者との作業が終わったら、台帳、根拠資料、共有フォルダなど、アクセスできる経路をまとめて点検します。台帳の招待だけを外しても、資料を別に共有していたり、書き出したファイルを渡していたりすれば、それぞれの取扱いが残ります。始めるときに終了時の確認対象を一覧にしておくと見落としを減らせます。

バックアップについては、取得できたかだけでなく、いつの状態に戻せるか、誰が復元できるか、復元後に古い連絡先が現れないかを考えます。台帳本体と同じ公開設定の場所へコピーを置くだけでは、事故の影響が同時に及ぶ場合があります。保存先の特徴に応じて管理し、復元の練習は架空データで行いましょう。

更新漏れと保管の必要性を定期的に見直す

出来事があった更新と、まとめて行う点検を分ける

担当変更の通知を受けたとき、連絡が届かなくなったとき、案件が終了したときは、その出来事に合わせて関連する記録を確認します。それとは別に、一定の間隔で古い確認日や未解決の項目を点検します。毎日すべての顧客を読み直すより、変更が生じた記録と、長く確認していない記録を区別した方が続けやすくなります。

例えば、進行中の案件は仕事の区切りで確認し、台帳全体の不要な項目や保存理由は月に一度見直す、という運用が考えられます。この周期は法定の期限でも全事業への推奨値でもありません。扱う情報の性質、変化の頻度、件数、自分の業務に合わせて決め、必要な訂正を定期点検まで放置しないことが大切です。

最終確認日が古い記録を見つけても、直ちに本人へ連絡するとは限りません。進行中の案件で必要な窓口なのか、保管だけしている過去の担当なのかを区別します。すでに終了した担当者へ、台帳を埋めるためだけに私的な情報を聞き直す必要はありません。まず自分の業務上の必要と、確認できる根拠を見ます。

※表は横にスクロールできます。

保存期間を、顧客情報すべてに一律で当てはめない

個人情報保護法に「顧客情報はすべて何年保存する」という一律の期間があるわけではありません。個人情報保護委員会のQ5-2は、保存期間や廃棄時期の一律規定はなく、利用する必要がなくなった個人データの消去に努めることを説明しています。保管しておけば安心という理由だけで無期限に残さず、何のために必要かを見直します。

一方で、案件が終わったから関連するものを全部同時に消せばよい、という意味でもありません。法令に基づく保存が必要な帳簿や書類、契約上の確認に必要な資料、単なる自由メモでは、残す理由が異なります。具体的な保存義務は文書の種類や事業の条件に応じて別に確認し、顧客台帳全体に一つの年数を機械的に当てはめないでください。

保管期間を検討する際は、最後の更新日だけから数えるのではなく、何を起点にするかも決めます。契約や法令で確認すべき起点がある資料と、自分が不要になった時点を見直す自由メモを混同しないようにします。台帳には資料の所在と保存理由の確認先を示し、法定保存の判断まで担当者の自由文へ埋め込まない方が扱いやすくなります。

また、Q5-3は、消去の時期について、業務上の必要性や保管の影響、管理のサイクルなどを踏まえる考え方を示しています。自分で決めた点検周期を理由に不要な情報を長期間残し続けないようにしましょう。本人からの請求への対応は、日常の定期整理とは別に必要な確認と判断があります。

移行は件数に加え、関係と意味を確かめる

表計算からCRMへ移すなど保存先を変えるとき、取引先が十件あったから十件入れば成功、とは限りません。担当者が別の会社へ結び付いた、履歴の日付が文字列になった、終了案件が進行中と表示された、といった差分は件数だけでは分かりません。どの項目をどこへ移し、何が移らないかを対応表にします。

最初は架空データで、同名の別人、一社の複数案件、担当交代、終了案件、根拠資料への参照を含む小さな組を試します。移行先で案件を一つ開き、現在の担当者と過去の履歴をたどってみてください。旧IDが保存されるか、移行先の新しいIDへ置き換わるかを確認し、変わる場合は対応を追えるようにします。

実データの移行では、試験中の旧台帳と新台帳の両方へ更新が入り、正しい版が分からなくなる点にも注意します。どの時点の情報を移したか、その後の変更をどこで管理するか、照合が終わるまで何を正式な参照先にするかを決めます。確認のために出力したファイルも顧客情報を含むので、保存場所と不要になった後の扱いを忘れないでください。

旧環境を終える判断は、表示がきれいになったことではなく、必要な記録が読めること、関係が正しいこと、残すべき資料を確保できること、利用終了後のアクセスや保管条件を確認できたことをもとに行います。元に戻せない操作を急ぐ必要はありません。未解決の差分を記録し、確認が済んだ範囲を明確にして進めます。

最初の一件を登録し、変更まで試して完成させる

ここまでの六つの成果物を使えば、台帳を作り始める順番が決まります。まず目的と集めない情報を決め、次に取引先・担当者・案件の関係を作り、現在値と履歴を分けます。その後、重複・担当変更・終了を試し、保存先と権限を確認し、点検する条件を決める流れです。最初から大量の過去データを入力せず、変更に耐えられるかを先に確かめましょう。

• 架空取引先Aに、担当者二人と案件二件を結び付ける
• 一件の確認履歴を書き、案件と当時の担当者へ戻れるか確かめる
• 片方の案件だけ担当者を変更し、もう一方の担当が変わらないことを見る
• 一件を終了にしても、進行中の案件と必要な資料が残ることを確認する
• 架空データを書き出し、別の場所でもIDと関連の意味を読めるか確かめる

この練習で同じ内容を何度も直す必要があるなら、現在値を重複して持っていないか見直します。履歴が読めなくなるなら、人物と役割を一つの欄へ詰めていないかを点検します。ツールを替える前に、どの情報が何を表すかをそろえると、自分に必要な機能も具体的になります。