CRM/SFAを外部委託から内製化へ！2つのポイントと回避策を紹介

リンクアンドモチベーションではDX実現に向けた取り組みの１つとしてCRM/SFA（Salesforce）の外部委託を内製化しました。
初期に起こった問題から解決までの取り組みを書きたいと思います。

1.つまづきやすい会社の特徴

リンクアンドモチベーションは11社のグループ企業を持ち、BtoBからBtoCまで幅広く事業を展開しているために比較的システムもプロセスも複雑になりやすい傾向にあります。会社の規模に関わらずこういった特徴がある会社も多いのではないでしょうか。

• 異なるビジネスの会社が参画したり新規事業を立ち上げることで、違うビジネスプロセスが後から発生する

• 人事異動により「利用者」「システム管理者」のノウハウが継承されづらい

2.内製化ではじめにつまづくポイント

内製化をはじめた当初、システムの利用ルールや仕様の全体を把握出来ていなかった現実に直面しました。データ移行や改修時にエラーやデータ不整合が頻発した結果、影響の分からない改修を避けるようになりました。

経験の少ないシステム管理者を中心に置くと図のような負のサイクルが起こります。

起こった問題として具体的なことを挙げます。

-エラーを頻発することでシステム利用率が下がる

導入から時間が経つと利用方法が変わり想定していないデータ登録がされていたり、開発を繰り返すことでロジックに矛盾が生じてエラーが頻発していました。
「オンラインホワイトボードのツールで特定の文字列を登録するとボードに表示されたデータが消えます」と言われたらどうしますか？多少の使い勝手よりもリスク回避できる安全なツールを使いたいと思うでしょう。
CRM/SFAでも同様に一括移行はせず手入力をすることや管理自体をスプレットシートに戻すなど自分達が最も安心できる手段に戻っていました。システム導入で一時的に業務効率が上がっても導入後時間が経った機能のエラーは継続性においては致命的なのです。

-システムや業務影響が分からない改修を避ける

長期的に外部委託開発を繰り返していたために全体のシステム構造がわかりづらく、システムの利用状況も把握出来ていませんでした。システムと業務のどちらも影響が分からないことが多く改修がなかなか進みませんでした。

3.つまづきの回避策

つまづきを回避するポイントは利用者を中心に置くことです。
利用者の利便性を損なわない（制限しない）こと。但し、制限をしないことで生じるリスクへの「予防」は必要です。また継続性のあるシステム開発をするためには技術力だけではなく利用者の文化や事業の理解が大事です。
「共通の目的」を達成するために強力な協力関係を築くこと、先ずは相互理解が大切なのです。

・利用者の利便性を損なわない（制限しない）　
　→ リスクへの予防
・継続性を保つ（開発技術力と利用者の文化や事業の理解）
　→ 技術✕業務人材のチーム制

-リスクへの予防

リスクへの予防には先ず２つ取り組んでいます。

（１）データ不整合の予防

特定部門でのみ利用されたり顧客影響が起きない機能は「システム管理者」だけでなく「利用者」も一括入力も出来るようにしていきました。データ移行で「エラーが出ないデータを準備する」「間違ったデータを登録しない」ために入力規則とデータ型や選択リスト値等の確認方法を説明したりフォーマットを作成したりしました。
リスクを回避するあまり権限を制限することに留まらず、どうすれば権限を解放出来るかを考えることやリスクを正しく理解して使いこなせるための情報を伝える努力をすることが大切です。

（２）エラーの予防

「システム管理者」が開発時に影響する自動処理の利用状況を素早く確認出来るようにしました。開発経験者がいなかったため、技術職として中途入社してすぐに業務も分からないまま先ずは処理フローを日本語化しています。

開発のハードルが下がりリードタイムが短くなっただけではなく、開発判断や工数見積りの妥当性を「利用者」と「システム管理者」双方での理解や納得感が生まれました。

-技術✕業務人材のチーム制

社内の人員だけで開発するには時間がかります。
技術人材の中途採用ではシステム仕様は理解できても業務まではすぐに把握出来ませんでした。技術人材の採用と自社事業の知見がある社員とのチーム制をとることで、内製化の立ち上げと改善が短期間で行うことが出来ました。

4.なぜ内製化なのか

外部委託のままでは何故いけないのか？という疑問があると思います。弊社がなぜ内製化したのかも簡単に説明します。

-課題の解消

外部委託を継続していたことで起こっていた課題がありました。
①拡張性がない
②システム構造が複雑
③ノウハウが継承されない

①拡張性がない
依頼時点での要求通りにシステム構築がされる。ビジネスの拡大や方針転換によりビジネスプロセスが変わってもすぐに対応が出来ない

②システム構造が複雑
技術力が高いために設計段階でノンコーディング以外の選択肢も簡単にとれてしまう。その結果、開発を発注する回数が増えるごとに現状のシステム構造を考慮しきれず複雑性が増す

③ノウハウが継承されない
外部委託工数を見込んだ体制でチームが作られるため社員の人数が少なく人事異動などによりノウハウが形骸化する。技術が継承されないだけでなく 社員の異動で推進／改善も進まない

これを解消するために標準機能に寄せた社内開発を行うことにしました。

-目的の実現

ビジネスの拡大や方針転換により常に変化していく中で最も重視したのが素早くBPM(Business Process Management)のPDCAを回すことでした。ビジネスを拡大するための見直しだけでなく今あるプロセスも細かく見直すことでデータをもとに分析してとるべき行動を決める。
そのために選択したのがプロセスを標準化に寄せた社内開発と推進です。

5.内製化して良かったこと

機能もプロセスも標準化によせた内製化をすることで課題解消や目的実現に向かいつつあります。
特段すぐに効果が出たことを挙げます。

・ノンコーディングに寄せることで改修期間のリードタイムが短くなった
・事業実態に合わせてビジネスプロセスを細かく見直せるようになった
・経営判断に合わせて注力すべき案件にすぐに対応できるようになった
・ビジネスプロセスや技術両方のノウハウが社内に蓄積されるようになった

最後に

「共通の目的」を達成するためには目的に合わせた組織体制が必要であり、そのためのコミュニケーションを円滑にするためには共通言語やフレームが効果的です。
同じような課題や目的を持っている方や内製化を検討している方に読んでいただいて少しでも参考になれば嬉しいです。