こんにちは!

PRIME ORDERの内藤です。

事業において、お客様の顧客情報を管理する重要なシステムである顧客管理システム(CRM)。私自身様々な企業様の顧客管理の IT化に携わっていますが、プロジェクトにアサインされる方は必ずシステム開発に精通した方ばかりではありません。

新規事業開発の担当の方だったり、マーケティング担当の方だったり、部署異動で突然プロジェクト担当になった方だったり・・・。

顧客管理システムの構築を成功させるために必要な考え方や一連の流れ、ポイントを抑えておくとプロジェクトは進めやすくなります。

この記事では、顧客管理システム(CRM)を自社用に開発構築することになった場合に、プロジェクトの責任者として知っておくべき知識や、注意すべき失敗例について解説しています。

これらの内容は、私が20年間、200件以上のシステム開発経験を受託する中で培ったノウハウや、現場で実際に見聞きした事例をベースに構成しています。

顧客管理システムとは

文字通り、顧客の情報を管理するシステムです。その規模は導入企業によりピンキリですが、顧客管理システムと呼ばれるものはいずれも次の要件を満たしていることが必須となります。

* 顧客情報を記録しておき、検索照会することができる

この最小限の要件を備えた上で、導入組織ごとに様々なニーズを列挙し、それに応える機能を搭載していきます。それらはたとえば、次のようなものです。


* 特定の条件を満たす顧客にLINEメッセージを送る

* 顧客をランク分けできる

* 顧客ごとの営業履歴を記録し共有する

* 出先からスマートフォンで利用できる

* 所属拠点や権限レベルで照会できる顧客情報の範囲を制限する

* 売上データを分析活用できる

* お問い合わせフォームからの問い合わせを見込み顧客として自動登録する

* 顧客と取り交わした契約書などの重要文書のファイルを管理できる

* ログインパスワードは30日に一度変更しないと利用できないなど、セキュリティ対策が万全


あなたの組織に必要な顧客管理システムがどのようなものか。まずはこうしたニーズの洗い出しから始めて、全体像を浮かび上がらせていきます。これを要求定義といいます。その具体的な進め方は、後述のプロジェクトの流れで解説します。

顧客管理システムを構築する方法は2つ

どのようにしたらあなたの組織に顧客管理システムを導入することができるでしょうか。

必ずしも1から顧客管理システムを開発する必要はありません。今日ではたくさんのクラウドサービス(SaaS。かつてはパッケージと呼ばれた既製品ソフトウェア分野)が提供されているので、それらを活用する企業も多くなっています。クラウドサービスを利用する場合のメリットは、なんといっても導入までのスピードの速さです。また、最初からたくさんの機能が備わっているのもメリットです。一方で、備わっているものの使用しない余分な機能がたくさんあることが、ユーザーに敷居を感じさせ現場の導入を鈍らせることがあります。また、既製品という都合上どうしても汎用的なつくりになっており、企業の文化とあわない、かゆいところに手が届かないなど、現場の不満がたまりがちです。こうした場合、クラウドサービスの提供元にカスタマイズをしてもらい対応できるケースもありますが、その実現自由度は非常に限定的で、期待していたものとは異なる解決策になりがちです。にもかかわらず費用はかなり高額なものとなります。

こうしたことから、事業の独自性や組織のカルチャーが強い企業の場合には、クラウドサービスではなく完全オリジナルのシステムを1から構築するのがセオリーとなっています。

ちなみに、独自のシステムを1から構築するアプローチをスクラッチ、あるいはフルスクラッチ開発と呼びます。もともとは完全に1からプログラムを開発することを指す言葉ですが、実際はベースとなる開発フレームワーク(Laravel、Symfony、CakePHPなど)を利用することがほとんどで、車輪の再発明をすることのないよう、合理化が進んでいます。クラウドサービスの進化がある一方、スクラッチ開発の分野での進歩も大きなものがあり、事業の根幹を支えるITシステムだからこそ、競合他社とは違う独自システムを開発構築するという選択肢は、今もなお重要な検討事項となっています。

【クラウドサービスとスクラッチ開発の比較】

顧客管理システムにおけるクラウドサービスとスクラッチ開発の比較

顧客管理システム開発プロジェクトの流れ

社内で正式にGoがかかった後、実際にどのようにプロジェクトが進んでいくのか、一般的な事例をもとに簡単に説明します。

※PRIME ORDERではアジャイル開発を採用していますが、アジャイル開発に対応しているシステム開発会社はまだまだ少ないのが実情です。ですので、この説明では一般的なウォーターフォール開発での流れを説明しています。


1:要求定義

今回開発する顧客管理システムにどのようなことが期待されているのか、しっかりと洗い出しをします。CSチームやセールス部門などの現場担当者に直接会って、現在の管理方式での課題や、取り入れている工夫、こわだりなどをヒアリングします。課題の解決は当然のことながら、現場の工夫やこだわりにこそ、自社の強みや独創性が詰め込まれているケースが多いので、しっかりと聞き出すことが大切です。ここを拾い上げていないと、システム完成後現場の導入が浸透しない恐れがあるので注意です。

衝突しあう要求を見つけ、どうすべきか現場を巻き込んでしっかりとコンセンサスを形成していきます。


2: 要件定義

1で洗い出した要求を満たすよう、システムに求められるスペック(要件)を言語化していきます。これを要件定義といいます。要件定義で書かれた内容は、この後の工程で取り組む内容そのものになっていくので、漏れがないようしっかり網羅する必要があります。次の工程である設計を担当するチームが、何を設計するべきなのか正しく伝わる内容でないといけないので、要件定義書というのはどうしても文字数が多くなりがちです。


3:設計

2で仕上がった要件定義書の要件一つ一つに対して、どのような機能として実現するのかを設計していきます。設計する内容は、画面UI設計のようにユーザーにもわかりやすいものもあれば、画面のないバッチジョブと呼ばれるデータ処理の仕様設計(アルゴリズム設計といいます)や、データを出し入れするデータベースの設計など多岐にわたります。こうした内容から想像できるとおり、システムエンジニアと呼ばれる専門職が遂行する工程です。


4:実装

3で様々な設計書が完成します。その設計書を実装チームに渡し、設計書通りのシステムとなるよう実際にプログラミングをしていきます。実装する段階になってわかる仕様の矛盾や課題などもあるので、そうしたものが見つかったら設計チームに戻して設計の修正をする必要になります。


5:テスト

4で実装されたプログラムが、設計書通りに動作するか検証していきます。ここで見つかった不具合は、一つ一つ実装チームに共有して修正をしてもらいます。システム導入後にたくさんの不具合が見つからないように、この工程で十二分なテストを行う必要があります。


6:受入検査

5でテストをしましたが、これらはあくまで設計書通りに動くかどうかのテストでした。本当に作るべきものが出来上がったのかどうかを、しかるべき責任者(プロジェクトリーダーやその上役など)が最終チェックをします。具体的には、要件定義で列挙された要件ひとつひとつがどのように実現されたか、それぞれを検証していく作業になります。もしも、要件を満たしていない機能が見つかった場合は、原因は実装あるいは設計にありますのでその機能については実装もしくは設計まで戻って修正を行っていきます。


7:システム導入説明

完成したシステムを現場に導入するため、その使い方をしっかりと現場ユーザーたちに説明します。この説明会の段階で現場から機能に対する変更要求が出たとしたら、1の要求定義が十二分でなかった可能性があります。実際、ここで現場の発言権のある人から、根底を覆すような意見が出ることもあります。そうなると相当のやり直しが発生し、最悪の場合導入見送り(お蔵入り)の可能性もあります。1の要求定義をしっかり行うことが重要であることがおわかりいただけると思います。


8:システム運用開始

いよいよ、顧客管理システムの運用を開始します。古いシステムから切り替える場合には、一定期間両方のシステムを利用する並行運用を行うケースもあります。万が一新システムで業務が回せない問題が見つかった場合でも、旧システムに切り戻す選択肢を残すことができます。ただし、現場は新旧二重のオペレーションを強いられることになるので、そのコスト感には注意が必要です。

運用開始直後は、もっとも問題が出やすい傾向があります。不具合の摘み残しがあったり、想定していたより現場とフィットしないなどでユーザークレームが多く発生するためです。3ヶ月ほどすると、不具合も少なくなってきて、現場も新システムに馴染んでくるはずです。安定運用期というキーワードがシステム担当者から出てくれば、一安心と言えます。ただし、運用開始からもう数ヶ月も経つのにトラブルは一向に収まらない、という場合は危険な徴候です。いつまでも開発が終わらないというデスマーチに発展している恐れがあります。


失敗の仕方を知る

残念ながら、顧客管理システム開発の失敗率は非常に高いものがあります。

以下、いくつかの典型的な失敗パターンを解説します。先に失敗の仕方を詳細に知っておくことで、あなたのプロジェクトが二の舞を演じることを防いでいただければと思います。

A:現場の反発

顧客管理システムの開発の失敗例

これは前章でも触れました。大変に多いケースなので、改めて解説しておきたいと思います。要求定義の段階でしっかりと現場ユーザ層を巻き込んでいなかったり、あるいは開発に時間がかかりすぎて、要求定義を行った頃と現場や市場、事業方針が変わってしまった場合に発生する失敗ケースです。

要求定義のフェーズでのミーティングでは静かだった現場責任者が、システム導入説明会になると急に大きな声を上げるというのは、よくあることです。その理由は実に簡単です。要求定義フェーズでは主に文字資料での意見吸い上げだったの対し、システム導入説明会では実際に完成した画面を見ながら説明を聞いているからです。評価対象物の具体度レベルが天と地ほどの差があるため、この段階になって現場ユーザーの要求意見はかなり明確で強いものとしてあがってきます。

導入説明会が紛糾すると赤信号です。その場で上がった要求、たとえば「KPIを自由に追加定義できる機能」「顧客へのアンケートを実施する機能」「外部システムからの顧客データ自動同期機能」が機能として実現されないと現場では導入できない、したくない、する意味がない、などの意見に押し切られ、追加改修をせざるを得なくなります。

ここでの追加改修は、自社開発であればまだしも、外部のシステム開発会社に委託しているケースでは悲惨なことになります。外部のシステム開発会社からすれば、要件定義で列挙されたことを実現していれば納品の義務を満たしていることになり、後から出てきた要求はすべて追加費用を請求することができるからです。また、プロジェクト開始前ではコンペだったっこともありあなたの希望する予算ラインを意識した金額設定をしてくれていたかと思いますが、納品後の追加改修になると強気の価格設定で見積もりを出してくるケースが多いのです。足元を見る、とまでは言いませんが、今さら他のシステム開発会社に乗り換えることができないことは明白なので、交渉上の優位性はどうしてもシステム開発会社に寄りがちです。こうして当初の想定を大きく超えるコストがかかることで、あなたのプロジェクト評価に大きな影を落とす可能性があります。

この失敗を回避するためにはどうすればよいのでしょうか。

たとえば、導入直前の現場の意見など黙殺して導入を推し進めるというトップダウン方式があります。多くの現場ユーザーは変化を嫌うものなので、半年も使えばなじんでくれるだろう、という考え方はあります。ただ、あなたの組織が独創性に強みを持っていたり、現場の属人的な工夫に優位性の側面があったとすると、失うものが多い可能性があります。かつて現場にあった、独創性に根ざしたアイデアや工夫の余地が、業務の進め方をシステムに無理やりはめ込むうちに失われていく危険性があります。

そうならないためには、現場ユーザーと十二分なディスカッションと検討を経て顧客管理システムを作るしかありません。先程のシステム導入説明会の風景を思い浮かべてください。現場ユーザーから熱量の高い意見を出してもらうために大切なものはなんでしたか?文字ベースの資料ではなく、実際に動く画面でしたね。しかし、従来型のウォーターフォール開発では、作る前に作るべきものを決めないといけないので、開発途中の動く画面を見てもらいながら現場ユーザーに意見をもらって反映することはできません。現場ユーザーが意見を言えるのは、開発着のずっと前、要求定義フェーズまでなのです。

ではどうするか。ウォーターフォール開発の課題を克服するために生み出された、アジャイル開発の採用がその答えです。アジャイル開発であれば、数週間という短期間で実際に動くものを現場ユーザーに届け、フィードバックをもらうことが可能です。現場ユーザーからヒアリングした要求を、4週間程度の短い期間で実際に動く機能に変えることができます。

顧客管理システム開発プロジェクトは、システムの完成と導入自体に意味があるのではありません。現場の顧客管理業務をより合理化、加速化し、事業上の効果を上げることにこそ意味があります。アジャイル開発なら、数週間ごとの小さなリリースを繰り返し、現場の意見を反映させながら、組織にとって本当に意味のあるシステムを作り上げることができます。

B:外部委託先の選定ミス

顧客管理システムの開発失敗例 システム開発会社の選定ミス

続いて紹介するケースは、実際わたしたちPRIME ORDERに、「困ってまして、相談に乗ってください」とお問い合わせをいただくことが最も多いケースです。

あなたが、顧客管理システムの開発を外部委託することにしたとします。当然、数社に声をかけて十分な吟味をして業作選定を行うかと思います。運悪く業者選定でハズレを引いてしまうというのがこのケースです。

(もし外部委託は検討していなくて、自社内で開発業務を完結する予定の場合は読み飛ばしていただいて大丈夫です)

業者選定の決め手としてよく挙げられるのはこれらのものです。


・a: 金額の安さ

・b: 納品スケジュール

・c: 担当者の人柄、能力

・d: 開発実績


これらのうち、もしあなたがaの金額の安さを必須条件として、オプション項目としてb,c,dを評価しようとするなら、この失敗を踏む可能性があるので注意です。

複数の業者から見積もりをとったのに、価格の差が生まれる理由はなんだと思いますか?長年この業界でたくさんの競合企業としのぎを削ってきた私ですが、価格差の理由は主に次のとおりであると断言できます。


【見積もり価格が高い業者】

・[1]多重請負構造で、費用がかさんでいる。

・[2]サービスが高品位。作るべきものを見落としていないので、積み上げて高くなっている。

・[3]あまり良く考えていない


[1]は、大手や中堅SIerでよく見られる見積もりです。開発されるシステムの品質は、一般的に請負次数が増えるごとに低下すると考えられます。ですので、高い割に品質はがっかり、という例もあります。ただし、看板と資金力には安心感がありますので、品質に問題がある場合は何度もクレームを伝えることで、対応してくれる例がほとんどです。そのかわり、スケジュールの長期化、およびあなたの心労が非常に大きくなることを覚悟する必要があります。

[2]は、妥当な価格設定をしているのだと考えるべきです。出された見積もりから、不要な機能や過度に高度な機能想定があれば、それらを省いてもらうことでトータルの費用は下がっていきます。

[3]は、一番おすすめできません。提案資料や見積書に説得力や熱量を感じなければ、どんなに担当者の人柄が魅力的でも、選択肢から排除すべきです。このような業者に発注すると、先方のあまりの考慮不足に唖然とすることになります。そしてそれは、多額の追加費用という形でさらにあなたを苦しめることになるでしょう。


【見積もり価格が安い企業】

・[1] オフショア開発で原価を低くできている

・[2] 案件が不足しており、格安でも受注したいと考えている

・[3] あまり良く考えていない


[1]のオフショア開発は、価格が安くなる理由が明解なので、積極的に検討したくなるかもしれません。ただ、プロジェクトの成否はブリッジSEと呼ばれる、現地のチームを采配する人材の優劣に大きく依存します。この人材は開発ベンダーにより選定されるわけですが、その優劣をあなたが事前にチェックすることは容易ではありません。非常にチャレンジングな選択肢となることを覚悟する必要があります。また、日本の商習慣やトレンドを共有できない人たちに開発を進めてもらうことも、十分理解しておくべきです。日本人なら言わなくてもわかることがわかってない。時差をまたいで余計なコミュニケーションが多く発生するリスクがあることを覚悟しておくべきです。

[2]は、お買い得と考える方もいるでしょう。たしかにうまくいくケースもあります。ただ、そのシステム開発会社に案件がない理由も探る必要があります。わたしたちPRIME ORDERもそうですが、一定以上のサービス品質を持っているシステム開発会社のもとには、案件のご相談が多く集まってきます。一方で案件不足のシステム開発会社は、何かしら案件が集まらない理由があると考えるべきです。技術力が低い、サービス品質が悪い、担当者のコミュニケーション力が低い、などなど。不良品を安く購入しないよう、慎重に品定めをすることをおすすめします。

[3]高い業者でもでてきましたが、同じパターンです。あなたのプロジェクトに必要な要求のスケールをちゃんと把握していないので、発注後は追加費用の見積書が立て続けに送られてきます。よく考えてないようで安く出してきたぞ、ラッキー・・・ということには絶対になりませんので、どうか注意してください。

結論として、外部委託先を選定する際に大切なことは以下の通りだと思います。

・見積もり金額の妥当性(どのようにその金額になったのか)をしっかりと探ること

・価格を抑えるためにリスクを冒すべきか、しっかり自問すること

顧客管理システムの開発を成功させるための法則

顧客管理システムの開発プロジェクトには、失敗の入口がたくさんあることをご理解いただけたと思います。と同時に、不安な気持ちが膨らんでしまったかもしれません。

でも、成功のための法則はこれらの失敗ケースの中にこそ隠れています。

開発業務、本当に外部に委託していいの?

まず、システム開発を外部に委託して、プロジェクト成否の責任を丸投げすることは危険だということを認識する必要があります。委託先業者は、究極的には、要件定義書通りに納品して請求書を送ることが目的です。あなたの目的とは随分違うはずです。あなたの目的にしっかりと伴走できる開発チームを手に入れようと思ったら、社内にチームを作ることがベストです。社内チームであれば、自身が所属する組織のために情熱を注いで開発にいそしんでくれるはずです。

そして、現場ユーザーとのコンセンサスを形成しながらプロジェクトを進めるために、ぜひアジャイル開発を採用しましょう。IT先進国(残念ながら、もはや日本はここに含まれてないと考えるべきです)では、顧客管理システムの開発には、古典的なウォーターフォール方式ではなくアジャイル開発を採択することが当然となっています。

高い技術力と、アジャイル開発への深い造詣。それらを有したメンバーで構成された、情熱的な開発チームがいるだけで、最高の顧客管理システムを確実に構築することができます。

これで、あなたの顧客管理システム開発プロジェクトは成功まちがいなしです。是非、最高の開発体験を楽しんでください。

・・・という結論で、悩みが解消してスッキリされた方は、ここから先は読んでいただかなくて大丈夫です。油断することなく、情熱的なチームとアジャイル開発プロジェクトを進めていってください。一方、そんな社内チームを編成できるはずがない、それができるなら悩んでいない、そう思われるので方にはこの続きを読んでいただきたいです。

まるで社内チーム。最高のアジャイル開発チームをすぐに手に入れる方法

PRIMEORDERのアジャイル開発

夢のような方法に聞こえたら、わたしたちも嬉しいです。世の中には困っていることがさまざまあり、それを解決するさまざまなサービスがあるわけですが、自社の課題解決や事業推進のためにアジャイル開発チームがほしい、そんなお困りごとにも、それを解決すべく情熱的なアジャイル開発チームを提供するサービスがあります。

それが、わたしたちPRIME ORDERが提供する、月額制アジャイル開発サービスです。

どんなサービスなのか、以下事例をまじえてご紹介いたします。

事例:不動産業界の顧客管理システム開発事例

クライアントは不動産業界で賃貸物件の仲介を事業の中核とされるW社。それまで既存のクラウドサービスを利用して顧客管理をしていたのですが、他社と一線を画す独創的な営業スタイルが特徴の同社にとって、既存のクラウドサービスには多くの不満や課題がありました。ターゲット層が20代から30代となるため、メールではなくLINEでコミュニケーションを取りたい。物件情報が別システムになるため二重管理でコストがかかっている。大小さまざまなアクションを記録してKPIとして利用したい。そのような様々な要求、課題を一緒に整理させていただき、月額制アジャイル開発で強力にプロジェクトを推進しました。忙しい現場のユーザー、たとえば営業スタッフの方々からも、実際に動く画面をご自身のスマートフォンで操作体験いただき、現場ならではの意見の早々にフィードバックいただきました。最終的には、新規採用した正社員のエンジニアさんもチームに合流し、一緒にシステムを作り上げながら、引き継ぎを同時進行。最後はPRIME ORDERなしでシステムの運用開発ができる体制になっていきました。システムを作りながらそれをメンテナンスできるチームも一緒に育てるという、まさにPRIME ORDERならではの開発プロジェクトとなりました。

まとめ

あなたがこれから顧客管理システムを開発するにあたり、実際に失敗を体験することなく、リアルな失敗体験を手に入れていただけたとしたら、私たちとしても幸いです。私たちPRIME ORDERのミッションは、「日本のシステム開発の失敗をなくす」だからです。紙面の都合上、わたしたちのサービスについては詳しくお話できていませんが、もしご関心をいただけましたら、どうぞお気軽にお問い合わせください。

あなたの組織の顧客管理システムの導入の成功と、その後の大きな事業効果を祈っています。