株式会社リックテレコム 「コンピューターテレフォニー」編集部 「5年後のコンタクトセンター研究会」主催。コクヨホールにて。
J.D.パワー アジア・パシフィック 代表取締役社長 鈴木郁氏。
顧客満足度についての調査をもとに分析した、影響する要因の解説がトピック(主に電話について)。
やはり、お客様からみて早く楽に解決できることがコールセンターの満足度に大きく影響するというわかりやすい構造である。
サポートの満足度の高さと、商品・サービスの継続利用意向の相関関係は意識していきたい(因果関係とは限らない)。
アメリカン・エキスプレス・ジャパン 取締役 兼 ワールドサービス・ジャパン副社長 萬年良子氏。
やはりジョブスキルを統合していろいろ対応できるスタッフを育成していくのが大切そう。
株式会社セールスフォース・ドットコム CFL本部 カスタマーサクセス部 シニアディレクター 仲澤輝宏氏。
Salesforce の宣伝。協賛枠。
イー・パートナーズ 代表取締役 谷口修氏。
フルフルなコンタクトセンター構築。
東京海上日動コミュニケーションズ 執行役員 田口浩氏。
問題提起的なぼやっと概論トーク。「経験や勘ではなく」と述べられていたように、プレゼンテーションでも感覚的ではなく数字で具体的な話が聞ければ嬉しかった。
この講演に限らずコンタクトセンターの事例では(あるいは提案における想定の)規模を最初に示していただけるといいなと思う。
DHLジャパン カスタマーサービス本部 カスタマーサービスセンター長 小川 景徳 氏。エンパスリンク 代表取締役 高見 俊介 氏。東京海上日動コミュニケーションズ 執行役員 田口 浩 氏。月刊「コンピューターテレフォニー」編集長 矢島 竜児。
都合により見ず。
始めてコクヨホールにきたんだけれど、テーブルにコンセントがあるし、座りやすい椅子だし、0001docomo (docomo Wi-Fi) の電波も入っているしいい感じ。なんか空爆を受けているような低音がずっとしているけれど。
2013年3月29日のPerlCasual #05以来の PerlCasual。 前回と同じ渋谷ヒカリエで今回はディー・エヌ・エーが会場(前回は NHN Japan (現 LINE))。ディー・エヌ・エーが会場のイベントに出るの初めて。横長会場。
メモ:
この業界のほぼ唯一で一番大きいイベントなので去年に引き続き行ってきた。会場は例年通りサンシャインシティ・コンベンションセンター。
朝10:00ちょと過ぎについたせいか、まだ各ブースのコンパニオンやスタッフが元気でパンフレット攻撃がすごかった。朝はもっとまったりかなーとも思っていたのだけれどね。今の課題状況から製品・ソリューションでこれが欲しいというのは今回はなかったので展示はさらりと回っただけにとどめておいた。
今年は特別講演を1本聴講。
「ロイヤルティリーダーに学ぶ ソーシャルメディア戦略」の著者の方だった。そういえば以前買ってあったっけ。
NPS の概要から入ったので比較的入門編なのかなーと思っていたのだけれど、難易度的にバランスが取れていた講演で良かった。
特に NPS については、「ブランドとしての NPS」と「ユーザーサポートにおける対応についての NPS」についての位置付けについて割にもやもやっとしていたのだけれど、この講演で「トランザクション NPS (後で調べるとトランザクショナル NPS (transactional NPS) という呼び方の方をよく見かけた)」という考え方の触りを聞けたのが良かった。やはり関係性調査とトランザクションについての調査は分けて考えているみたい。
あとは「中立者(8 まで)と 推奨者(9、10)とでは壁がありそこを超えるには別の取り組みが必要」「NPS の調査については2クエスチョン(NPS となぜのコメントのみ聞く)とマルチプルクエスチョンがあるよね」「セグメンテーション、推奨者のコメントからの真実の瞬間の特定、推奨者と中立者・批判者との経済性の比較」や「批判者フォローアップとシックスシグマ、よりプラスにもっていくためのサービスデザイン・従業員エンゲージメント・ブランディング」なんていう話をうかがった。
今後の取り組みのとっかかりに丁度良かったのでこのあたりをキーワードにチェックしていこうと思う。
昨日に引き続き今日も Developers Summit 2015 で目黒雅叙園へ。セッション会場では(一般人は)机が無かったので、ノート PC は家に置いてきた。
デブサミはほとんどのセッションが撮影可なんだけれど、スライドを公開すると発表者が言っているのに全スライドをシャッターの電子音を鳴らしてながら撮り続ける人がいて昨日は結構ウザかった。
そういった声は多かったようで、今日は進行の人がシャッター音に配慮するように注意を促していてちょっとは減った感じだった。撮りたかったら無音カメラアプリをインストールしてくるとかした方が良いと思う。
会場でばったり zakwa 氏と再会。まさか来ているとは知らなくてびっくり。今はデータ解析やっているとかいっていたかな。良い再会があったのがデブサミ2日目の一番の収穫。こんど同窓会やりましょう。
朝一番のセッションは昨日の朝に比べて遅い人出。
Docker や Ansible などの話。いろいろ模索し続けている話。インフラ整備専任者が欲しいとのこと。ローカルホストに開発環境を簡単に構築できるというのは良いのだけれど、やはり管理コストが高い印象。
個人的にはやはりどこかのラックに自分の VM がある方が使う側も楽な気がしている。
事前の注意とか言い訳についての前置きが長かった。宣伝セッション。
お昼から帰ってきて会場に行ったら、既にまさかの満席だった。あきらめてソファで本を読んだり、kintone CAFE でコーヒー飲んだり。
プラットフォームの刷新にあたり既存のサービスや機能をきちんと UML を用いてモデリングしなおしてあるべき姿の議論を行ったというのが良いなと。
自分の本部でも今いろいろ可視化を行っているグループがあるのだけれど、散文的に書き出すのではなくてきちんとモデンリングするようにしたい。
Miiverse におけるマルチリージョン構成や多言語対応についての話。
各リージョンに対してどういったサーバとDB構成にしているのかについての説明は興味深かった。パフォーマンスもそうだけれど、サービスとしてどこの機能・情報をリージョン別に出し分けるかを念頭におく必要があることがわかった。なおコードベースは1つで環境変数で機能の出し分けをしているのだとか。
L10N については具体的な話で良かった。Miiverse 特有の話というよりは一般的に誰もが通る道的な。
Eraser Button Law など世界展開においてはやはり法的な事情があるというのもやはり大変なところのようだ。監視ポリシーは統一していとのこと。また投稿監視は関係会社がやっているとのこと(どこにアウトソーシングしているのかな)。
Miiverse もそうだけれど、どこも独自にコミュニケーションサービスを提供していくので、汎用コミュニティサイトはどういう路線でいくのが良いのかなと考えたり。
ガラガラだったし、15分ぐらい経っても本題に入らないし琵琶湖の説明が始まったので途中で出てきた。
及部敬雄氏の
Not プロセス導入 自分たちに必要なものは自分たちで選ぶ
という話が良かった。推進者がゴリゴリ推し進めるのではなくきちんとみんなで考えて試行錯誤していくところに本当の学びがあるんだなと。
セッションの一番最後に、スタンディングオベーションの号令があったのでそそくさと退席した。
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会8回目。今日は第8章 技術的負債。
スクラムのコアコンセプトの部でわざわざ技術的負債について1章割くというのがふーんという印象でした。ベロシティに大きな影響を与えるので避けて通れないというところでしょうか。あるいはウォーターフォールと違って返済していくチャンスがあるからでしょうか。
技術的負債。当初は
意図的に手抜きをしてすばやく仕上げるという意味
技術的負債を抱えるということは、今後の作業のための時間を担保にした融資を受けるということだ。
からきていて、後々返済する必要が出てくる代わりに先に経済的効果を得ているものを指しています。単純にまずい設計や実装のことまで技術的負債と世間で呼ばれていることがありますが、個人的には違和感を感じています。本書ではナイーブな技術的負債と呼んでいますね。
技術的負債ですが
大切なのは、どんなプロダクトであっても技術的負債からは逃れられないということだ。私はここで、技術的負債をなくすよう努力しましょうなどと言うつもりはない。仮にそんなことができたとしても、負債をゼロにするためには大変なコストがかかるだろう。
ということで必ずしも罪悪感を感じる必要のあるものではないことがわかります。きちんと把握してコントロールしていくことが重要です。
ただ
技術的負債の経済的意味についての適切な認識
については、正直なところなかなか正確に見積もれることがない気がします。技術的負債を生むという選択をした時にそこまで見積もる余裕がない、あるいはあっても先のことなので詳細化しきれない、そういうケースが多いのではないかと。
サイズが大きいものは方法2の方が時間をとって返済しやすく、サイズが小さいものは方法3の方が「フィーチャーよりも優先度が低くていつまでも返済されないということがない」ので返済しやすいようです。
あたりがポイント。
ということで、技術的返済のみに注力するのは価値を提供し続けるというのに反するで望ましくないとありました。
また実際のところ利息がほとんど発生しない技術的負債もあるので、きちんと見極める必要がありますね。
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の22回目。第22章 スプリントレトロスペクティブ。
プロセスをスクラムチームが調査するためのものだ。
2月の第15章 さまざまなプランニング以来、4回目の発表担当です。
半年前に今のチームにスクラムを導入した当初に CSM に「まずはふりかえりをきちんとできるようにしたい」と言われてから、スプリントレトロスペクティブについては結構意識してきたので、あらためてふりかえりのふりかえりという気持ちで読みました。
本章の中で事前準備についてけっこう書かれています。ふりかえのために全く事前準備していないので、その利点についてなるほどと感じました。ただ実際のところそこまで時間を費やさなくてもという思いもあります。大きな課題があってそれにフォーカスしたふりかえりをする場合は準備するというようになるかもしれません。
と書かれていますが、勉強会で皆の実態を聞いてみると1週間/2週間スプリントで30分から45分ぐらいというのが中心でした。プロセスの改善だけに時間を使いすぎるのに抵抗があるのかもしれません。
付箋紙を使っているとインサイトバックログを残そうとあまり思わないなと。一方 Trello などのデジタルツールを使っている場合は残すという運用をするかもといったぐらい。
ふりかえり時間・実行できるアクションのキャパシティを考えると、インサイトが多く集まった時は何について議論するかをきちんと絞る必要が出てきます。ここは結構ファシリテーターの腕の見せ所。紹介されているドット投票で機械的に決め手しまうのもさくっと進んで良さそうなので取り入れたいです。
改善アクションを扱う最も簡単な方法は、アクションに関連するタスクをスプリントバックログに追加して、新しい機能よりも優先順位を高くすることである。(中略) 改善アクションを実施したいのであれば、分離してはならない。統合すべきである!
なるほど。今は個人に委ねて次回確認ぐらいとなっているのですが、チームで可視化しフォローしていけるようにすべきですね。
Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。
nDiki は1999年1月に始めたコンピュータ日誌を前身とする Naney の Web 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。
※内容は個人的見解であり所属組織とは関係ありません。