nDiki : 可視化

「5年後のコンタクトセンター」サミット in 東京・夏

株式会社リックテレコム 「コンピューターテレフォニー」編集部 「5年後のコンタクトセンター研究会」主催。コクヨホールにて。

10:00-10:50 基調講演 1万人超の顧客体験に見るコンタクトセンター「真の役割」

J.D.パワー アジア・パシフィック 代表取締役社長 鈴木郁氏。

顧客満足度についての調査をもとに分析した、影響する要因の解説がトピック(主に電話について)。

• 「CS の高さは将来の利益を表す先行指標」。
• コールセンター満足度の高さと、商品・サービスの継続利用意向の関係は正の相関。
• 顧客満足度の構造: 担当者/オペレータの中で一番満足度に影響があるのが「担当者/オペレーターの応対の丁寧さ(31%)」。
• 「すぐに要件を理解された」「電話のお礼を述べてもらった」(とお客様が感じた)場合に満足度向上。
• コールセンターに期待されること「直接話せば確実に要件を済ませられるから」「迅速に解決できるから」。
• 1回の電話で解決できること。

やはり、お客様からみて早く楽に解決できることがコールセンターの満足度に大きく影響するというわかりやすい構造である。

サポートの満足度の高さと、商品・サービスの継続利用意向の相関関係は意識していきたい(因果関係とは限らない)。

10:50-11:30 アメックスが創る「カスタマー・エキスペリエンス」の条件 「顧客満足」から「感動体験」へ

アメリカン・エキスプレス・ジャパン 取締役 兼 ワールドサービス・ジャパン副社長 萬年良子氏。

• カスタマー・サービス(会社が考えたサービス)からカスタマー・エキスペリエンス(お客様の体験)へ。
• 問い合わせは関係を築く機会。
• 権限委譲された社員。
• NPS。日本では文化的に低めに。2010年より業績評価に。全社的な取り組み。
• 1回の電話での解決率80%を目指している。ジョブスキルを統合・権限委譲。1スキルになるためキャリアパスをコールセンター部門を超えて作る。

やはりジョブスキルを統合していろいろ対応できるスタッフを育成していくのが大切そう。

11:30-12:15 ソリューションセッション セールスフォース・ドットコムが「お客様の成功」のために行っていること

株式会社セールスフォース・ドットコム CFL本部 カスタマーサクセス部 シニアディレクター 仲澤輝宏氏。

Salesforce の宣伝。協賛枠。

13:20-14:00 進化する組織を創る! 戦略的コンタクトセンターのすすめ

イー・パートナーズ 代表取締役 谷口修氏。

• なかなかいい人を採用できない時代になっている。
• コールセンターはハブとなるプロフェッショナル集団。
• 予測対応!
• 徹底的にロイヤルユーザーを増やす。ロイヤルなオペレーターを増やす。
• 「あなたは当社の商品・サービスを誰かに薦めますか?」「あなたは月曜日の朝、会社に行きたいですか?」
• 経営者の期待: いい品質でいい仕事をしていれば(「ベスト・サービス」)カスタマーサービスは不要(「ノー・サービス」)

フルフルなコンタクトセンター構築。

14:00-14:40 「経営貢献するコンタクトセンター」のあるべき姿

東京海上日動コミュニケーションズ 執行役員 田口浩氏。

• 「情報処理学会・コンタクトセンターフォーラム」
• コンタクトセンターは不景気になると人が多いからということですぐにコスト削減のターゲットとなる。
• KPI は 150とか160とか。
• 事前にうまく情報を伝えられると、次回コール削減と感動体験になる可能性がある。

問題提起的なぼやっと概論トーク。「経験や勘ではなく」と述べられていたように、プレゼンテーションでも感覚的ではなく数字で具体的な話が聞ければ嬉しかった。

この講演に限らずコンタクトセンターの事例では(あるいは提案における想定の)規模を最初に示していただけるといいなと思う。

15:00-16:30 パネルディスカッション 5年後のコンタクトセンターを考える 「センターの価値を可視化する」効果と実践

DHLジャパン カスタマーサービス本部 カスタマーサービスセンター長 小川 景徳 氏。エンパスリンク 代表取締役 高見 俊介 氏。東京海上日動コミュニケーションズ 執行役員 田口 浩 氏。月刊「コンピューターテレフォニー」編集長 矢島 竜児。

都合により見ず。

コクヨホール

始めてコクヨホールにきたんだけれど、テーブルにコンセントがあるし、座りやすい椅子だし、0001docomo (docomo Wi-Fi) の電波も入っているしいい感じ。なんか空爆を受けているような低音がずっとしているけれど。

PerlCasual #06 - 秋だからPerlとかの話でも #perlcasual

2013年3月29日のPerlCasual #05以来の PerlCasual。 前回と同じ渋谷ヒカリエで今回はディー・エヌ・エーが会場(前回は NHN Japan (現 LINE))。ディー・エヌ・エーが会場のイベントに出るの初めて。横長会場。

• https://atnd.org/events/57398

メモ:

基調講演 @xaicron 氏

• ハッカドールの紹介からのスクレイピング。
• WWW::Mechanize 健在。

Ramen Challenge の可視化 @Niratama 氏

• YAPC::Asia Tokyo 2014 の1日目に @bayashi 氏が提唱した #yapcramen の Twitter 投稿の収集と可視化について。
• vis.js 使ってグラフ表示。
• スライドショーツール remark。
  • http://remarkjs.com
  • https://github.com/gnab/remark

「Perlによるコマンドラインツール開発Tips」 @songmu 氏

• http://songmu.github.io/.../
• 「将来的に壊れる心配が少ない」ココが重要。
• Minilla
• App::FatPacker

「Google BigQueryを使ってみた!」 @yusukebe 氏

• Twitter の statuses/sample を流しこんでみた紹介。

Perl::Lint @moznion 氏

• Perl::Lint 0.10 リリース。
• Perl::Lint 開発で学んだこと。

LT

• @bayashi 氏
  • Benchmarks.pm penchmarks。たしかに Benchmark の使い方は毎回 perldoc して思い出す必要がある。
• @sugyan 氏
  • Emacs で Perl (helm、helm-perldoc、undo-tree など)。そろそろ anything から helm に移行しないとな。
• 「僕がwebアプリケーションのコードを書く時に考えていること 〜短縮版〜」 @dameninngenn 氏
  • http://blog.dameninngenn.com/.../034052
  • 新しいプロジェクトに join する時の話。
• @kfly8 氏
  • Benchmark。@bayashi 氏とまさかのかぶり。
• @akihiro_0228 氏
  • 僕がPerlに慣れるまで。
• @__papix__ 氏
  • Docker 関連。

コールセンター/CRM デモ&コンファレンス2014 in 東京 (第15回) に行ってきた

この業界のほぼ唯一で一番大きいイベントなので去年に引き続き行ってきた。会場は例年通りサンシャインシティ・コンベンションセンター。

朝10:00ちょと過ぎについたせいか、まだ各ブースのコンパニオンやスタッフが元気でパンフレット攻撃がすごかった。朝はもっとまったりかなーとも思っていたのだけれどね。今の課題状況から製品・ソリューションでこれが欲しいというのは今回はなかったので展示はさらりと回っただけにとどめておいた。

今年は特別講演を1本聴講。

特別講演 G-7 「顧客体験のレベルを可視化しよう! ロイヤルティを数値化するNPSの測り方と活かし方」エンパスリンク 高見俊介氏 セミナー会場G

「ロイヤルティリーダーに学ぶ ソーシャルメディア戦略」の著者の方だった。そういえば以前買ってあったっけ。

NPS の概要から入ったので比較的入門編なのかなーと思っていたのだけれど、難易度的にバランスが取れていた講演で良かった。

特に NPS については、「ブランドとしての NPS」と「ユーザーサポートにおける対応についての NPS」についての位置付けについて割にもやもやっとしていたのだけれど、この講演で「トランザクション NPS (後で調べるとトランザクショナル NPS (transactional NPS) という呼び方の方をよく見かけた)」という考え方の触りを聞けたのが良かった。やはり関係性調査とトランザクションについての調査は分けて考えているみたい。

あとは「中立者(8 まで)と 推奨者(9、10)とでは壁がありそこを超えるには別の取り組みが必要」「NPS の調査については2クエスチョン(NPS となぜのコメントのみ聞く)とマルチプルクエスチョンがあるよね」「セグメンテーション、推奨者のコメントからの真実の瞬間の特定、推奨者と中立者・批判者との経済性の比較」や「批判者フォローアップとシックスシグマ、よりプラスにもっていくためのサービスデザイン・従業員エンゲージメント・ブランディング」なんていう話をうかがった。

今後の取り組みのとっかかりに丁度良かったのでこのあたりをキーワードにチェックしていこうと思う。

• コールセンター/CRM デモ&コンファレンス2011 in 東京 (第12回)
• コールセンター/CRM デモ&コンファレンス2013 in 東京 (第14回) に行ってきた

今日のさえずり: NERV の紙袋持って帰ったら、「亀十?」って聞かれた

2014年11月14日

• 07:10 目黒川みんなのイルミネーション2014、11月21日から12月25日。
• 09:24 コールセンター/CRM デモ＆コンファレンス2014 in 東京向かってる。 #cc_tokyo2014
• 09:50 I'm at 池袋駅 (Ikebukuro Sta.) in 豊島区, 東京都 http://4sq.com/1va9Xg6
• 10:08 #cc_tokyo2014 (@ サンシャインシティ コンベンションセンター in 豊島区, 東京都) http://4sq.com/1urtbw4
• 10:09 コールセンター/CRM デモ＆コンファレンス2014 in 東京到着。 #cc_tokyo2014
• 10:57 そろそろ、特別講演 G-7 「顧客体験のレベルを可視化しよう! ロイヤルティを数値化するNPSの測り方と活かし方」エンパスリンク 高見俊介氏 セミナー会場G #cc_tokyo2014
• 10:57 「ロイヤルティリーダーに学ぶ ソーシャルメディア戦略」の著者。 #cc_tokyo2014
• 11:51 トランザクション NPS という考え方を知れたのが良かったです。 #cc_tokyo2014
• 11:57 受付横のベンチで何かいい匂いしてきたなーと思ったら、隣の女性がスパゲッティ食べてた。
• 12:57 出社。 (@ 株式会社ミクシィ (mixi, Inc.) in 渋谷区, 東京都) http://4sq.com/1EICHhJ
• 14:12 お先に席替え完了。
• 14:51 あやうく隣席をエナジードリンク置き場にされるところだった。
• 18:05 デスクにアナログ時計が欲しいな。
• 19:16 トランザクション NPS、トランザクショナル NPS (transactional NPS) と呼ばれる方が多そう。
• 19:55 頭に何かをのせて坐禅している赤い蝶ネクタイの人あちこちで見かけて気になる。
• 19:56 RT @mixi_engineers: あさって2014.11.16開催の、今年2回目のScrap Challenge会場準備が着々と完了。挑戦者のみなさま、お待ちしています! #mixi_scrap http://t.co/pWqna6UPpW
• 20:27 「Naney さん爪切り持ってないですよねー。」「あるよ。いちおうエンジニアだから。」
• 21:07 “技術は手段にすぎない。クックパッド勝間氏が語る、いかにして「ユーザーファースト」を実現するか？ | HRナビ” http://bit.ly/1GVZicp
• 21:08 トランプあったけど、この袋持って電車に乗るのちょっと恥ずかしい。 (@ セブンイレブン 渋谷3丁目六本木通り店 in 渋谷区, 東京都) http://4sq.com/1ut6Z4F
• 21:12 700円毎のくじは缶コーヒー当たった。
• 21:55 NERV の紙袋持って帰ったら、「亀十?」って聞かれた。
• 22:53 詰め合わさってた。 https://flic.kr/p/q1XwtQ
• 23:05 結局咳がまだ止まらないので、前にいつものところでもらって残っていたムコダインとレフトーゼとトランサミン飲んだ。

今日のさえずり: 「とりあえずグラフにすれば可視化」というのを撲滅する

• 08:13 ナショナル電気ファンヒータ出した。
• 08:46 粗大ごみ申し込み完了。
• 11:10 「とりあえずグラフにすれば可視化」というのを撲滅する。
• 12:00 「ギフトラッピングは利用できませんが、車両はラッピング済みです。」 http://amzn.to/1A9a5uI
• 14:16 「問題が発生したため、プロセス『http://com.google.process.gapps』を終了します。」300回ぐらいタップした。
• 15:51 Xperia GX リセットした……。
• 19:41 Google Authenticator に2段階認証8アカウントを設定しなおすという修行をした。
• 20:57 I'm at 株式会社ミクシィ (mixi, Inc.) in 渋谷区, 東京都 http://4sq.com/12IqhIn
• 22:49 し、しばれるー。冬将軍来てるのか?
• 24:58 ようやくある程度 Xperia GX の設定が戻った。

Developers Summit 2015 2日目

昨日に引き続き今日も Developers Summit 2015 で目黒雅叙園へ。セッション会場では(一般人は)机が無かったので、ノート PC は家に置いてきた。

デブサミはほとんどのセッションが撮影可なんだけれど、スライドを公開すると発表者が言っているのに全スライドをシャッターの電子音を鳴らしてながら撮り続ける人がいて昨日は結構ウザかった。

そういった声は多かったようで、今日は進行の人がシャッター音に配慮するように注意を促していてちょっとは減った感じだった。撮りたかったら無音カメラアプリをインストールしてくるとかした方が良いと思う。

再会

会場でばったり zakwa 氏と再会。まさか来ているとは知らなくてびっくり。今はデータ解析やっているとかいっていたかな。良い再会があったのがデブサミ2日目の一番の収穫。こんど同窓会やりましょう。

「GMOプライベートDMP」の開発にあたって取り組んできた DevOps、更にその反省点と現在進行中のカイゼン事例の紹介 山邉哲生氏(GMOインターネット)

朝一番のセッションは昨日の朝に比べて遅い人出。

Docker や Ansible などの話。いろいろ模索し続けている話。インフラ整備専任者が欲しいとのこと。ローカルホストに開発環境を簡単に構築できるというのは良いのだけれど、やはり管理コストが高い印象。

個人的にはやはりどこかのラックに自分の VM がある方が使う側も楽な気がしている。

「DevOps」やってみた。そして、気づいたこと、陥ること、見直すところ。川瀬敦史氏(日本アイ・ビー・エム)

事前の注意とか言い訳についての前置きが長かった。宣伝セッション。

ドメイン駆動設計再入門 和智右桂氏(グロースエクスパートナーズ)

お昼から帰ってきて会場に行ったら、既にまさかの満席だった。あきらめてソファで本を読んだり、kintone CAFE でコーヒー飲んだり。

高速開発を支えるDMMプラットフォームの作り方 ～DMM.makeの場合～ 濱野正樹氏・清酒渉氏(DMM.comラボ)

プラットフォームの刷新にあたり既存のサービスや機能をきちんと UML を用いてモデリングしなおしてあるべき姿の議論を行ったというのが良いなと。

自分の本部でも今いろいろ可視化を行っているグループがあるのだけれど、散文的に書き出すのではなくてきちんとモデンリングするようにしたい。

世界に展開できるウェブサービスのつくり方 下林明正氏(はてな)・矢野幹樹氏(任天堂)

Miiverse におけるマルチリージョン構成や多言語対応についての話。

各リージョンに対してどういったサーバとDB構成にしているのかについての説明は興味深かった。パフォーマンスもそうだけれど、サービスとしてどこの機能・情報をリージョン別に出し分けるかを念頭におく必要があることがわかった。なおコードベースは1つで環境変数で機能の出し分けをしているのだとか。

L10N については具体的な話で良かった。Miiverse 特有の話というよりは一般的に誰もが通る道的な。

Eraser Button Law など世界展開においてはやはり法的な事情があるというのもやはり大変なところのようだ。監視ポリシーは統一していとのこと。また投稿監視は関係会社がやっているとのこと(どこにアウトソーシングしているのかな)。

Miiverse もそうだけれど、どこも独自にコミュニケーションサービスを提供していくので、汎用コミュニティサイトはどういう路線でいくのが良いのかなと考えたり。

琵琶湖を中心とした世界のようなお話 佐藤由紀氏(マイクロアド)

ガラガラだったし、15分ぐらい経っても本題に入らないし琵琶湖の説明が始まったので途中で出てきた。

Agile TED

• 【司会】高柳謙氏・川添真智子氏(ユニファ)
• 及部敬雄氏(楽天)
• 鹿島恵実氏(GMOペパボ)
• 知花里香氏(ディー・エヌ・エー)
• 西村直人氏(永和システムマネジメント/一般社団法人アジャイルチームを支える会)
• 山口鉄平氏(ヤフー/一般社団法人アジャイルチームを支える会)

及部敬雄氏の

Not プロセス導入 自分たちに必要なものは自分たちで選ぶ

という話が良かった。推進者がゴリゴリ推し進めるのではなくきちんとみんなで考えて試行錯誤していくところに本当の学びがあるんだなと。

セッションの一番最後に、スタンディングオベーションの号令があったのでそそくさと退席した。

2日間の発表についての雑感

• 小綺麗に見せるだけの素材写真を多用しているスライド多かった。Flickr の URL と CC に従ったクレジット表示を読み取れない小さな文字で入れている的な。キャッチーだけの飾り。
• 「いついつのイベントで話します」的なのも結構多かった。この発表はこの発表で完結するのが良いと思う。

Todoist や Trello や【日記】

9連休なシルバーウィークが終わりました。晴れてここ最近にしては暑い朝でした。疲れはきっちり取れた感じです。リフレッシュ。

Todoist はいったん細かくプロジェクトを分けるのをやめてしばらくやってみたのですが、やはり分けた方が便利でした。タスクの多いプロジェクトは専用の Todoist プロジェクトに入れた方が見通しが良いです。

あとは久しぶりに Trello にチームとボードを追加。オフ会やちょっとしたイベント運営では雑多な共有タスクがあるので Trello ぐらいの粒度で可視化・管理できると良いので。

第8回 エッセンシャル スクラムを読む会

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会8回目。今日は第8章 技術的負債。

スクラムのコアコンセプトの部でわざわざ技術的負債について1章割くというのがふーんという印象でした。ベロシティに大きな影響を与えるので避けて通れないというところでしょうか。あるいはウォーターフォールと違って返済していくチャンスがあるからでしょうか。

技術的負債

技術的負債。当初は

意図的に手抜きをしてすばやく仕上げるという意味

技術的負債を抱えるということは、今後の作業のための時間を担保にした融資を受けるということだ。

からきていて、後々返済する必要が出てくる代わりに先に経済的効果を得ているものを指しています。単純にまずい設計や実装のことまで技術的負債と世間で呼ばれていることがありますが、個人的には違和感を感じています。本書ではナイーブな技術的負債と呼んでいますね。

技術的負債ですが

大切なのは、どんなプロダクトであっても技術的負債からは逃れられないということだ。私はここで、技術的負債をなくすよう努力しましょうなどと言うつもりはない。仮にそんなことができたとしても、負債をゼロにするためには大変なコストがかかるだろう。

ということで必ずしも罪悪感を感じる必要のあるものではないことがわかります。きちんと把握してコントロールしていくことが重要です。

ただ

技術的負債の経済的意味についての適切な認識

については、正直なところなかなか正確に見積もれることがない気がします。技術的負債を生むという選択をした時にそこまで見積もる余裕がない、あるいはあっても先のことなので詳細化しきれない、そういうケースが多いのではないかと。

技術者レベルでの技術的負債の可視化

• 方法1: 障害管理システムに記録する
• 方法2: 技術的負債を表すプロダクトバックログアイテムを作る
• 方法3: 技術的負債バックログを作る

サイズが大きいものは方法2の方が時間をとって返済しやすく、サイズが小さいものは方法3の方が「フィーチャーよりも優先度が低くていつまでも返済されないということがない」ので返済しやすいようです。

技術的負債の返済

• 作業中に偶発的な技術的負債が見つかれば対応できるところまで対応する。
• スプリントごとに既知の技術的負債のいくつかを返済対象として対応する。価値をもたらすフィーチャーの開発と関連するものを一緒に進めることで金利の高いものから勧められる。

あたりがポイント。

「技術的負債返済スプリント」だとか「リファクタリングスプリント」などといった言葉がチーム内で出てきたら、危険信号だ。

ということで、技術的返済のみに注力するのは価値を提供し続けるというのに反するで望ましくないとありました。

また実際のところ利息がほとんど発生しない技術的負債もあるので、きちんと見極める必要がありますね。

• エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

第22回 エッセンシャル スクラムを読む会

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の22回目。第22章 スプリントレトロスペクティブ。

プロセスをスクラムチームが調査するためのものだ。

2月の第15章 さまざまなプランニング以来、4回目の発表担当です。

半年前に今のチームにスクラムを導入した当初に CSM に「まずはふりかえりをきちんとできるようにしたい」と言われてから、スプリントレトロスペクティブについては結構意識してきたので、あらためてふりかえりのふりかえりという気持ちで読みました。

事前準備

本章の中で事前準備についてけっこう書かれています。ふりかえのために全く事前準備していないので、その利点についてなるほどと感じました。ただ実際のところそこまで時間を費やさなくてもという思いもあります。大きな課題があってそれにフォーカスしたふりかえりをする場合は準備するというようになるかもしれません。

スプリントレトロスペクティブに使う時間

• 60分未満で有益なスプリントレトロスペクティブをするのは難しい。
• 2週間スプリントなら 1.5時間。

と書かれていますが、勉強会で皆の実態を聞いてみると1週間/2週間スプリントで30分から45分ぐらいというのが中心でした。プロセスの改善だけに時間を使いすぎるのに抵抗があるのかもしれません。

インサイトバックログ

付箋紙を使っているとインサイトバックログを残そうとあまり思わないなと。一方 Trello などのデジタルツールを使っている場合は残すという運用をするかもといったぐらい。

アクションの決定

ふりかえり時間・実行できるアクションのキャパシティを考えると、インサイトが多く集まった時は何について議論するかをきちんと絞る必要が出てきます。ここは結構ファシリテーターの腕の見せ所。紹介されているドット投票で機械的に決め手しまうのもさくっと進んで良さそうなので取り入れたいです。

アクションはスプリントバックログへ

改善アクションを扱う最も簡単な方法は、アクションに関連するタスクをスプリントバックログに追加して、新しい機能よりも優先順位を高くすることである。(中略) 改善アクションを実施したいのであれば、分離してはならない。統合すべきである!

なるほど。今は個人に委ねて次回確認ぐらいとなっているのですが、チームで可視化しフォローしていけるようにすべきですね。

• エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

部門のソフトウェアエンジニアスキルマップ

部門としてソフトウェアエンジニアでカバーできていない領域があってどうするかとか、学びたい/育成したい領域がいろいろあるとか、個別に課題感を聞くようになってきた。

可視化しないと合理的な話ができないなと感じたのでスキルマップ(スキル - ソフトウェアエンジニアの表)を作ってみた。習熟度は順序尺度なので誤解しないよう数字ではなく記号で。

表で記号を埋めていくという観点ではなく、コミュニケーションの上での共通理解のツールという観点で使っていきたい。