営業データベース導入を入社1年半で3度やった時のお話
データベース導入/移行のお仕事を短期間に繰り返したことで、営業データベース（以下DB）の導入・移行PJ時の思考法と行動法について自分の中で一旦型化できたのでまとめてみようと思います！
ベンチャーで限られたお金と人(主要メンバー1~4名くらい)で導入・移行するような状況を想定いただければ幸いです。
尚PJの進め方については別の記事にまとめてありますので併せてご覧ください！ここでは営業DBの導入・移行PJということに特化した発信とさせていただきます！
ちなみに僕が実際に行った3回は以下のようなものです。
①スプレッドシート/SalesforceにあったSaaS事業のIS・営業・CSの営業データをSalesforceに移行
②スプレッドシート/Salesforce/kintoneにあった3事業部の営業データをkintoneに統合
③スプレッドシート/kintoneにあった人材紹介事業の営業データに対してマッチングッドを導入
1. 目的・目標・予算・期限・その他制約条件の設定
まずAsIs-ToBeとGISOVのフレームワークに基づきPJの概要を端的に言語化することをおすすめします。
AsIs-ToBeは現状と理想を可視化しそのギャップをIssue(課題)として設定し、解決につなげる問題解決のフレームワーク、
GISOVはGoal・Issue・Solution・Operation・Valueについて可視化しPJを完遂に導くフレームワークです。
特にValueをシャープに言語化しておくことが後々重要になってきます。Valueとは「Goalに到達することで誰がどのようにうれしいのか」を言語化したものですが、ここが明示できていないとPJに対する理解が得にくくなり、周囲の人から協力も得られにくくなり、苦しくなります。PJを進めている張本人からすると「Issueが解決しGoalに到達したら絶対うれしいし価値あるじゃん！」と思うのですが、周りからすると意外と「お、おう。なんか解決するんだねー」という認識で止まっていて、そこから一歩進んで「それがどのような意味があるのか自分にどのような価値がもたらされるのか」までは意外と捉えていないものです。明示してあげましょう！
GISOVについては下記の本がわかりやすくおすすめです。
GISOVだけでもいいのですが、”現状”に対する認識の解像度が低いと自ずとIssueの解像度も落ちてしまうので敢えてAsIs-ToBeについても書きました。
＊このフェーズにおける注意点
・PJのスコープ（目的/目標×時間軸）は明確に！
・見積の1.3~1.5倍は時間がかかると想定し、想定外を想定内に収める
∵サブのPJは人員がとれない（兼務でやられる方が多いと社外でも聞く）
∵想定外のことは必ず起きるもの
・関係各位の責任者・影響力の大きい人としっかりすり合わせする（途中で邪魔が入らないようにリスクヘッジしておく）
2. WBS(Work Breakdown Structure)を作成する
目標達成に必要な要素を洗い出し、表にします。
主な構成要素は下記です。
教訓としては企画・設計の段階でエンジニアの目を入れておくことです！ビジネスサイドだけで設計すると業務OPSの最適化に引っ張られてしまい、中長期的に見た時に生産性高く、データ管理のリスクも低い状態が作りづらくなってしまいます。また実装の段階で内部開発やシステム間のAPI連携が必要な際にエンジニアの方の協力は不可欠になります。早めにPJに巻き込めると吉です。
上記のプロセスをざっくり時間軸を加味してWBSを作成します。
PJが進むにつれて見えてくる景色は変わるので進みながら徐々にTODOを精緻化していきましょう！
参考までにWBSはこんなかんじです！
3. 具体作業1：要件定義→設計
該当する企画・設計の部分のプロセスを詳細に書くと下記のようなイメージです！
ここではシステム選定について省略しましたが、スマートキャンプさんが運営するボクシルはシステムの比較をしてくれていて参考になります！
要件定義ではまずDBに関わる全プレイヤー属性について業務フローやIssue、要望をヒアリングします。例えば僕が3事業部の営業DBを統合するPJのPMをした際は機能×過去現在未来×3事業部という3軸でヒアリングしました。
ここで注意すべきは4点です。
①各事業の状態をファクトで抑えること（機能は何があるか（営業・IS・営業推進・CS etc）、商品はいくつあるのか、売りが発生するタイミングはいつか、KGI/KPI/KBI(行動指標)は何か→DBのデータを基にしてダッシュボードで数値を見たいというニーズが出ることは容易に予想できる）
②社内の使い手が抱えるIssueと要望を網羅的に把握すること（ある機能の人にはヒアリングをかけていなかった！などということのないように。PJ終盤に「そんな話聞いてない！」となり、頓挫するともったいないし、何より偏った視点で要件定義したことで使えないDBを生んでしまう懸念がある）
③拾い上げたIssueがなぜIssueのままなのかその原因を過去の変遷を元に理解すること（理想だけを語っても実現できないと意味がないのでこれまでの歴史に敬意を表しつつ改善していくこと）
④拾い上げた要望を事業としてのあるべき姿と照合し、今後の事業展開の拡張性を意識した上で設計すること（全ての要望に応えるわけではないことをヒアリング時に伝えておく。また事業の成長に伴いニーズがすぐ変わる可能性が高いのなら優先度を下げたり、即席の機能で対応するようにしていく）
特に④の視点は重要です。使い手へのヒアリングではどうしても現状の困り事ばかりが上がってくるのでそれを全て反映させようとすると近視眼的で個別最適なシステムになってしまいます。システムはある程度長期間使用し、変えにくいものです。そのため、ヒアリングの結果を反映させ、随所で使い手にトライアルしてもらいFBを得て要件に反映させることは必要ですが、全てを叶えることはできないというスタンスを貫き、中長期的な全体最適を目指して取捨選択していきましょう！！このスタンスをブレずに貫くためにも1で設定したGoal、Valueを指針として掲げ続けることが重要です。
上記4点を意識したヒアリングを基に理想のオペレーションを設計します。これをシステム構造に反映させていきます。
次にシステム構造の中で必要なデータ項目を洗い出し、既存システムと移行先システムでのデータ項目の対応表を作っていきます。
その際、各データ項目の入力規則もセットで決めることをおすすめします。入力規則とはフリーテキストなのか、プルダウン選択なのか、チェックボックスなのか、といったデータの型のことです。
入力規則の決め方はそのデータをどのように使いたいかに依存します。そのデータを使って、検索したい！分析をかけたい！というニーズがあるのならフリーテキストではなくプルダウンやチェックボックスで表記揺れを無くしておきます。ただ、あまりに項目が細分化すると使い手に記入労力がかかり、記入が徹底されないので項目の細分化は最小限におさえるのがいいでしょう。
データは活用できる形で取得できないと無意味だし、そもそも取得できないと（使い手が記入してくれないと）意味がないのです！気を付けましょう！
設計が終わり、システムのセキュリティ評価等のリスク評価も終えたら、少ない件数でデータ移行してみてちゃんと設計通りに機能するか、検証してから次の最大関門”データ移行”に進みましょう。
4. 具体作業2：データ移行（ここが地獄）（元のデータの成形・補完→移行！！）
まず対応表を元にデータ成型・補完をしていきます。既存のデータは新規DBに入れる上でクリーニングが必要なケースも多いですが、ここを丁寧にやらないとそもそもDBにデータ移行できないので慎重に行います。（フリーテキストをプルダウンにするとか）
特にスプレッドシートやExcelで属人的に管理していたデータを移す際はめちゃめちゃしんどい。。。。。。
ですが正直このフェーズは丁寧に作業することと、関数を駆使することでなんとかでき、一定の論理的思考力・構造化思考力があればできます。できるのですが、時間がかかり、単純作業も多く最もしんどいフェーズです。頑張って乗り切りましょう！
このフェーズで使う関数や便利ツールはネットにたくさん落ちてます。
例えば、下記のようなもの↓
5. 運用
いよいよ最後のフェーズです。ここは2点に大別できます。
①使い手に対しての対応と②システムに対しての対応です。
①対使い手に対してはインプット会の実施を行い、必要に応じてマニュアルの読み合わせもしながら、実際に使ってもらいます。実務で使用していく中で分からかないことがあれば質問できる窓口も設置しておくと導入がスムーズでしょう。データの漏れや移行ミスも起こりうるのでこの窓口では移行後のデータ修正依頼等も受けます。
②対システムに関しては不具合が起きた時の対応や定期メンテナンスだけでなく、DBにおける権限管理（データの閲覧・入力・削除・DB自体の更新など権限は分かれていて機能や役職ごとに権限を分けておくのがベター）やアカウント管理を行います。また移行後すぐに全てを自動化することがは難しいかもしれないのでDBのデータ更新やメンテナンス担当をつけておくのもいいでしょう。
いかがでしたでしょうか！営業DBを導入したい、移行したい、統合したいと思っているが、進めていない方への一助となれば幸いです！！
よろしければサポートよろしくお願いいたします！