「作って終わり」のDX、そろそろ終わりにしませんか？“ユーザー目線で成長するサービス”の秘訣を株式会社Crew・柳澤龍一氏らに聞く

多くの企業にとって、DXの推進は喫緊の課題となっています。業務効率化のために社内システムを新規開発することもあれば、デジタルな技術を生かした新規事業を立ち上げることもあります。

そこでよくある失敗が、「作って終わり」になってしまうこと。せっかくのシステムを活用しきれなかったり、ビジネス環境の変化によって時代遅れになってしまったりするケースが生じています。

システムや事業は「作ってからが本番」です。今回お話を伺った株式会社Crewは、システム開発やクリエイティブ制作だけでなく、リリース後のフォローまで手厚いサポートを実施。これまでの経験から、「立ち上げはもちろん、作ってからのフォローアップも大切」と強調します。

もともとソーシャルゲームの運営に携わった経験を持つ経営陣だからこそ、ユーザー目線でサービスを育成することの重要性を認識しているCrew。この記事では、そんなCrewのCEO柳澤龍一氏、CTO小松広樹氏、セールス部セールスリーダー五十嵐公輔氏の3人に、ユーザーの声を受け止めて改善していくことがなぜ大切なのかをうかがいました。

「ユーザー」視点を持つことの強み

要望をサービスに落とし込む

――御社はWebサービス開発やクリエイティブ制作からSNSマーケティング、ブロックチェーン関連開発まで幅広く請け負われているそうですね。

五十嵐：はい。当社では現状、システム開発の受託とクリエイティブ制作の2軸をメインにしつつ、お客様の要望ベースで私たちができることを可能な限り提供しています。

お客様は社員数名規模の企業から大手企業までさまざまで、漠然と「〇〇のようなサービスを作りたい」と相談される場合もあれば、しっかり企画書に落とし込まれ、ある程度の要件が出揃っている場合もあります。

そのなかで、たとえば「LPを作りたい」「サイトがほしい」といった要望が出てくれば柔軟に対応しており、お客様からはそうしたフットワークの軽さを評価されることが多いです。

ゲーム開発で培われた「ユーザー視点」

――そんな御社の強みはどのようなところにあるのでしょうか。

五十嵐：まずは、技術力が高いこと。そしてシステムの企画から開発、マーケティングまで一気通貫で対応できることです。

対応範囲が広いので、開発期間や金額は場合によってさまざまですが、ボリュームゾーンとしては開発期間3〜4ヶ月、費用600〜1200万円といったところでしょうか。最近はものづくり補助金や事業再構築補助金を活用することで、これまでDXに予算をあまり取ってこなかった企業からご依頼いただくケースも増えています。

なお、CrewのCEOやCTOには、サイバーエージェントでゲームの開発を行ってきた経験があります。そのため、「ユーザーがサービスを使うには」「ユーザーにこういう体験をさせるには」という観点を強く持っているんですね。そこもお客様からも評価されている点です。

「作って終わり」にせず、ユーザーの反応を数値で追おう

作って放っておくと、ユーザーが離れていく

――特にDXで新規事業を立ち上げるとき、気をつけるべきポイントは何でしょうか？

柳澤：「作って終わり」になりがちなことです。しかし実際の現場は、作って終わりではありません。むしろこれまでの経験からすると、常に「リリースしてからが本番」だと考えなければなりません。

――というのは？

柳澤：ユーザーにサービスやシステムを使い続けてもらうためです。これまでの経験上、ユーザーは「使いづらい」と感じたサービスからは驚くほど速く離れていくことがわかっています。

使いづらい部分が放置されている（保守・運用が適切になされない）サービスであればなおさらです。いっぽうで、はじめこそ使いづらくても、リリース後もこまめに改善されるサービスであればユーザーの信頼を得られることもわかっています。

だからこそWebサービスやシステムにおいては、それを使用するユーザーからの反応を数値的なデータやSNSでの反響からダイレクトにつかみ、改善に生かすことが大切です。

開発からリリースまでが「産む」ことだとすると、リリース後の運用とはそのサービスを「育てていく」こと。そしてサービスを確実に成長させるには、「産む」よりも「育てる」アクションを続けるほうがむしろ大切なのです。

理想的なユーザー行動を数値でキャッチアップ

――「育てる」サイクルを回すために、具体的にどのようなアクションを取ればよいでしょうか？

柳澤：サービス立ち上げ時の目的に立ち返り、その目的を達成するためにユーザーがどういう行動をとるのが理想なのかを定めることです。分かりやすくゲームにたとえれば、「ユーザーが毎日ゲームをプレイしてくれる」のが理想、といったことですね。

そこが定められたら、次は、現状を把握するための数値的な指標を考えていきます。ゲームの例であれば、「ユーザーのログイン頻度（1日あたり○回）」などがひとつの指標になるでしょうか。サービスのジャンルやターゲットによって指標はさまざまに考えられますが、できる限り客観的な指標を立て、理想の状態に近づいているかどうかをモニタリングするようにしましょう。

――納得感のあるお話です。ただ、そもそもどのような指標を立てればよいのか、詳しくない人にとってはピンとこない部分もあります。「これだけは押さえておきたい」という基本的な指標などはあるのでしょうか？

柳澤：適切な指標のあり方は、サービスのジャンルやターゲット層などによって異なります。加えて、そのサービスがリリース直後なのか、それともすでに多くの利用者に親しまれている状態なのかといった成熟度によっても異なってきますので、「この指標さえ達成すれば大成功する」という指標はありません。

たとえば、アパレルのECモールを開発するとします。単価の高い商品が中心のモールなら「一度でも購入したことのあるユーザー数」が重要かもしれませんし、ファストファッション系なら「リピート購入率」や「同時購入商品数」が重要かもしれません。一方、開発するのが「社内の勤怠管理システム」だとしたら、全く別の指標を見ることになりますよね。

このように、見るべき指標は案件によって大きく異なるのがふつうです。だからこそ新規サービスを立ち上げる際には、サービスのコンセプトを徹底的に練るのはもちろん、「このサービスを育てるためには、どういう評価指標を設定すれば良いのか」も含めて考えることが重要になります。

業務システム開発にも増えてきた「使ってワクワクするサービス」への要求

ユーザーに活用されるシステムとは？

――ここまでのお話は主にtoCのサービスが中心でしたが、toBの場合はどのような点が異なるのでしょうか？

小松：toBの代表例といえば業務システムですが、これらは「使わなければならないもの」なので、使ってもらうこと自体にハードルは発生しづらいです。事実、開発するときには、toCは「使って楽しい」、toBは「扱いやすい」を優先するケースが多いですね。

ただ、最近はtoBでもデザインに対する要望が以前より高くなり、いわゆる“お堅い”デザインは敬遠されつつあるのを感じています。デザイン性が高いとユーザーもワクワクしながら活用してくれるので、結果として生産性も上がるんですよね。

実は企業から、「この仕様だとモチベーションが上がらないから何とかしてほしい」といったご依頼をいただくこともあるんです。結局、活用されるシステムは「見やすく、使いやすいサービス」に帰結する。それはtoBでもtoCでも変わりありません。

現場レベルでの本当にやりたいことを実現する

――では、Crew様が考えられる「見やすい」「使いやすい」サービスとは、どんなサービスでしょうか？

柳澤：ユーザーがやりたいと思った行動をそのとおりに実現してあげるサービス、これが「見やすい」「使いやすい」につながると考えています。

たとえば、ある社内ポータルシステムを作るとします。ポータルには経費精算、出退勤管理、社内報などさまざまな機能が搭載されます。ポータルの責任者としては、「すべての機能を使ってほしい！」と思い、すべての機能をトップページに表示しようとします。

ただ、社員の皆さんにとっては「出退勤管理は毎日使うけど、経費精算は月に1回くらいしか使わない。出退勤管理を先に持ってきてほしい」といった具合に、利用頻度や使いたい機能に順番があるはずです。使ってもらいたい側の気持ちと、実際に使う側の気持ちはどうしてもズレが出てきてしまうものです。

また、便利な機能をすべて詰め込めば最高のサービスになる、というわけでもありません。そこがサービス開発の難しさでもあり、開発者が専門家としてアドバイスをしていくべき部分だと考えています。

机上で話を進めず、「見て・触って」をスタートにする

――「見やすい」「使いやすい」サービス開発を行うために、Crew様では何を重視されているのでしょうか？

柳澤：さまざまな取り組みを行っていますが、「プロトタイピング」「PDCA」「Webサービスに触れ続ける」は重視していますね。

まず「プロトタイピング」。サービスの品質を高める上では、実際に使ってみて「ここはこうした方が良い」と議論したり、目に見えるものをベースに改善していったりすることが大きな効果を発揮します。そのため、プロトタイプを早い段階で作ることが大切です。最初に全体的なラフデザインを作り、それをたたき台として改善を繰り返しながら開発を進めていくような形も有効ですね。弊社では、提案現場でもそのようにラフを持って說明するケースも多いです。

また、リリース後のPDCAは、リリース前の開発以上と言っても過言ではないほど重要です。私たちとしては、リリース当初はユーザーが本当に必要としている最低限の機能をシンプルに提供することにとどめ、ユーザーの動向を見ながらUI/UXの改善や機能の追加を検討していくことを推奨しています。

最後に、何と言っても私たちには、自らがあらゆるWebサービスに触れ、さまざまなサービスを知り尽くした専門家であり続けることが求められると自負しています。誰よりもサービスをわかっている専門家だからこそ、自信を持っていいサービスが提案できる。自分たちの技術に慢心することなく、「ユーザー目線」の姿勢を持ち続けることが重要だと思っています。

取材：夏野かおる　執筆：松田小牧