Articles tagged with: メール配信

事例:株式会社ファンドレックス様


SalesForceで運用していたリードから商談、受注処理、メール配信をkintoneに移行

  Topへ↓

株式会社ファンドレックス様は、ソーシャルセクター(NPO・ソーシャルビジネス、財団、大学、行政、企業など社会にプラスの変化を生み出したいと願う人や組織)の支援を専門としておられます。
・調査・分析
・インパクトマネジメント
・戦略策定
・研修・人材育成
・ICTによる経営の高度化
・実行支援
を業務の軸として、ソーシャルセクターが持続的に活動していくための各種コンサルティング活動を行っておられます。

ソーシャルセクターは、利益だけを目的としていないために課題が多種多様です。ファンドレックス様の的確なコンサルティングによって事業が継続するお客様が、また別の組織や個人に利他の精神を伝達していきます。ファンドレックス様の活動は社会のあらゆる層に価値を届ける起点となるのです。

ファンドレックス様から顧客に対して情報を届けるため、顧客管理はとても大切です。
お問い合わせフォームからのリード(見込み顧客)獲得から、各種セミナー集客、商機をつかむための各種配信。ファンドレックス様の営業活動の肝となるのが顧客管理です。

使っておられたSalesForceからkintoneへ顧客管理を移管したい。弊社にご相談をいただいたのは、この点でした。

SalesForceからのデータ移行

  Topへ↑

SalesForceの内容を拝見したところ、カスタマイズはそこまで行われていませんでした。
ただし、カスタマイズオブジェクトやカスタマイズ項目はたくさん追加されていました。

SalesForceからkintoneへのデータ移行については、弊社は何度も経験を積んでいました。
リード(見込み顧客)や商談、顧客情報や担当者情報の構造も理解していました。
そのため、データ移行については初期移行と差分移行を何回か行うことで苦戦せずに完了しました。

苦戦はしなかったのですが、注意を払った点があります。それは項目名です。
SalesForceは項目を区別するためnameプロパティがあります。kintoneでいうところのフィールドコードです。ただし、nameの文字列に使えるのはアンダースコアと英数字のみ。日本語は認められていません。日本語が使えるのは別のlabelプロパティです。kintoneでいうところのフィールド名です。

kintoneはフィールド名とフィールドコードの両方に日本語が使えるため、弊社の開発ポリシーではその二つは原則として合わせます。そうすることで後々のプログラミングの生産性は上げられます。
ですが、移行にあたっては差分取り込みを考慮すると、kintoneとSalesForceの情報を合わせておかねばなりません。そのため、しばらくはkintone上のフィールドラベルと名称をSalesForceの値に合わせておきます。

kintoneのフィールド名とフィールドコードをどの時点で日本語に切り替えるか。
今回はそのタイミングの調整に気を使いました。

外部からのウェブフォームからの取り込みはSalesForceのWeb-to-リードを使っておられました。
フォームについてもkintoneに移行した後も使えるようにする必要があります。
今回は、後々の保守性を考慮してトヨクモ社のFormBridgeを提案しました。

FormBridgeを利用することで、フィールド名とフィールドコードを日本語に切り替えるタイミングで影響が少ないようにしました。

ただ、この後述べるメール配信プログラムとの連携においてはタイミング毎にプログラムの修正が発生しました。

メール配信について各種サービスの検討を行う

  Topへ↑

ファンドレックス様はメール配信をSalesForceの機能を使って頻繁に行っておられました。

つまり今回の移行の肝は、メール配信をどうやって円滑に移行させるかありそうです。
SalesForceからkintoneに移管した後も変わらずに、ファンドレックス様の多くの顧客やリードに対してメール配信を行う。それが必ず超えるべきミッションでした。

そこでkintoneのさまざまなメール配信サービスを検討しました。
その結果、Benchmarkを採用しました。kintoneとBenchmarkは双方が持つRest APIを使って連携させることに決まりました。

kintoneエコシステムの中には有名なメール配信サービスがあります。
その中でBenchmarkを採用したのは、ステップメールが送れることや、メール配信・開封状況が管理できることなどが理由です。

メール配信運用について、抱いておられる不安を払拭していただくことに注力

  Topへ↑

Benchmarkとkintoneの連携開発は弊社でもすでに実績がありました。
ただ、kintoneに移行した後にもメールの配信が円滑に行えなければなりません。

そのため、メール配信については、運用担当者もまじえて何回か話し合いの機会を持ちながら進めました。
ファンドレックス様はかなり長い期間SalesForceのユーザーでいらっしゃいました。
そのため、弊社ではkintoneやBenchmarkの信頼性がSalesForceに劣らないことを説明し、信頼を抱いてもらうことに注力しました。

また、Benchmarkはメール配信サービスです。重複メールアドレスの扱いなど、メール配信サービス特有の仕様についてもご理解を深めていただきました。
もちろん、弊社でもさらにBenchmark自体の仕様を理解するとともにAPIの理解も深めました。

また、どの項目をメールに埋め込むのかについても様々な工夫を凝らしました。
Benchmarkは埋め込み設定ができる仕様ですが上限が定められています。配信するメールごとに埋め込む項目を考えると上限にぎりぎりになってしまうため、そのやりくりをどうするかはシステム側の課題でした。
そうした連携について、APIを駆使してkintoneからBenchmarkへの連携実装のめどを付けました。

その結果、メール配信の運用開始のテスト期間をへて、無事に移管が完了しました。

弊社がこの部分はまったく関与せず、ファンドレック様によりメールの配信は運用していただいています。

ファンドレックス様ありがとうございました。

ファンドレックス様より

導入までの日々と現在をファンドレックス社の長谷川様はこう語ってくださいました。

私はkintoneへの移管の担当ではありましたが、設計や作業のためのまとまった時間がなかなか取れず、アクアビットさんにはいつも五月雨な相談の仕方でした。それでも
しっかり寄り添ってご対応いただけたことが、大変ありがたかったです。

相談の最初では、kintoneを中心としたシステムでできることと実装としてオススメでないことを分けてお話してくださったので、導入のガイドになりました。
今まで私が経験していたシステム開発では、ウォーターフォール型で最初に要件整理業務設計そして開発と進むものでしたが、kintoneの特性として実装しながら修正していく方法に頭に切り替えるのが大変でした。その中で、色々と相談しながら進めることができたことが、とても良かったです。

kintoneは使いながら育てるシステムなので、今でも業務でやりたいことを考えたり社内の意見を取り入れながら修正しておりますが、行き詰ったらまたアクアビットさんに相談しようと思っております。どうぞ引続き、よろしくお願いいたします。

ファンドレックス様のご紹介

社名 株式会社ファンドレックス
所在地 〒108-0075 東京都港区港南2-16-1 品川イーストワンタワー762号室
連絡先 03-6894-2147
役員 シニアパートナー 井上 義雄
パートナー 平尾 千絵
パートナー 相澤 順也
創業 2008年7月1日
URL https://fundrex.co.jp/

今さらメールがすごいと言われても


先日、フォーブスジャパンのオンライン版でこんな記事を見つけました(SNS時代でも、メールがやっぱりすごい理由)。メールを礼賛するようなタイトルに、この期に及んでメール?と逆に興味をもって読んだのですが、正直いってあまりにも現状にさからった記事内容にがっかりしました。

メールって、コミュニケーションツールだったはずですよね?普通、コミュニケーションといえば、双方向のやり取りを指すはず。ところがこの記事を読むと、双方向の視点が見事に欠けています。双方向ではなく一方通行のツール。それも配信業者にとって都合の良い配信手段として。この記事の中で礼賛されるメールとはコミュニケーションツールではなく配信手段でしかありません。送り手側に都合のよいだけの一方通行のコミュニケーション手段の可能性を力説されても、シラケてしまいます。

私の感覚では、メールはもはや主流のコミュニケーションツールではありません。もちろん、私もコミュニケーション手段としてメールは残しています。一部のお客様とはいまだにメールでやり取りしているので。

おそらくオンライン上で行う双方向のやりとりの手段として、メールはもうしばらく生き残るでしょう。ですが私が技術者同士のやり取りでメールを使うことはほぼありません。chatworkやLINE、Facebook メッセンジャーやSlackで仕事のやりとりはほぼ事足ります。メールに頼らずともお手軽なコミュニケーション手段は十分用意されているのです。

なぜメールが使われなくなったのか。その理由を知りたければ最適な情報があります。それはサイボウズ社が以前展開していたNo email キャンペーンです。この中に理由が書かれています。(キャンペーンサイトは無くなってしまったようですが、スライドシェア上にアップされています)。
・整理されない
・引き継げない
・取り消せない
・添付できない
・集計できない
・経緯を追いづらい
・見落とす

サイボウズ社の主力製品の一つはグループウエアやんか、アンチemailの主張は差し引いて受け取らなあかん、という声もあるでしょう。でもここに列挙したアンチemailの理由は今もなお有効です。少なくともフォーブスジャパンの記事にはここに挙げたemailの欠点を補う記述は見当たりませんでした。

それどころかフォーブスジャパンの記事にはこう書かれています。「ウェブサイトのデザインに使われるHTML5やCSS3などの技術が進化し、メールは一方通行の「読み物」から、ウェブサイトばりにインタラクティブなツールになった」。ところが、こういったインタラクティブなHTMLメールは、メーラーによっては完全に読めません(こちらに英文ですがメーラーのCSS対応状況が掲載されています)。メールでやりとりする上で不可欠なメーラーが、インタラクティブなHTMLメールに対応し切れておらず、しかもそれが改善される気配がない。これは、メール市場の拡大を謳うこの記事の説得力を完全に損なっています。もう一つフォーブスジャパンの記事に抜けていると思ったのが暗号化への対応です。実はほとんどのメーラーでは暗号化設定が実装されています。ですが、メールサーバーの設定によって利用者がメーラーの設定を変えねばなりません。それなのに、フォーブスジャパンの記事にはそのことに触れていません。そもそも双方向性が考慮されていないため、暗号化の問題に触れる必要がないのでしょう。でも、この点はメールの将来性にとって不可欠な視点のはず。

なぜメーラー開発各社がHTMLメール対応に本腰を入れないのか。それは私見ですが、ひとたびその機能を許せば通信データ量を食うHTMLメールによる一方的な配信が増大し、通信料も莫大になるからではないでしょうか。No emailキャンペーンでは触れられていませんが、そもそもメールとは送信者が受信先のアドレスさえ知っていれば、自由な内容、自由な容量のメールが送り放題です(メールサーバーを持っていれば流量制限も無尽蔵です)。それに比べて、LINEやchatworkやSlackでメッセージを送るには、受信者側の許可が必要です。

そういう許可制が敷かれたプラットホームでは、メール配信会社は大量配信が出来なくなります。この点を抜きにしたフォーブスジャパンのこの記事には、配信会社の思惑を感じずにはいられません。

とはいえ、フォーブスジャパンの記事にはメールの優位性として情報量を盛り込める点が指摘されています。これはchatworkやLINEにない利点であることは認めざるをえません。また、記事内に登場するハイムス社の紹介では、効果的なメール配信を行う仕組みを備えているそうです。だとしたら一目置くべきかもしれません。ですから、一概にメールを否定するのもまた賢い対応ではないのです。どうにか双方の良い点を兼ね備えたコミュニケーション手段ができればいいのに、と常々思います。

もし、フォーブスジャパンの記事にあるような配信業者が、本気でメールプラットホームに未来を賭けたいのであれば、まずは下手な鉄砲も数撃ちゃ式手法より、本当に記事が読まれるべき内容にすべきだし、対象も絞るべきではないでしょうか。一方通行ではなく、読み手からも適切なフィードバックが戻るようなツールであるべきだと思います。そのためにはメーラーにも改善の余地があります。上に書いたようにメーラーのCSS対応もまだまだです。本来ならばウェブサイトと同じレベルでCSSによるデザインが施されたページが読まれるべきでしょう。ですが今の対応状況は発展途上もいいところです。それ以外にもメーラーでできることがあるはずです。例えばメルマガの末尾には配信停止のリンクが記載されています。これをもう少し改善し、メーラー側に配信停止機能を持たせるというのはどうでしょうか。その都度メール末端のURLをクリックして配信停止を行わせるのではなく、メール一覧から右クリックで配信停止を実現する機能。この機能をメーラーが実装するだけで、余分な一方通行メールが減るのではないかと思います。

コミュニケーションツールにはまだまだ改善の余地がありそうです。これを読んだIT技術者の方。よかったら改善に取り組んでみられてはいかがでしょうか? え? おまえがやれって? うむむ、興味はありますが、多分私一人には荷が重いですね。もし興味がある方、一緒にやりませんか?