nDiki : 可視化

可視化 - visualization

2014年8月26日 (火)

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

naney:14854543499

株式会社リックテレコム 「コンピューターテレフォニー」編集部 「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) の電波も入っているしいい感じ。なんか空爆を受けているような低音がずっとしているけれど。

スポンサード リンク
[ 8月26日全て ]

2014年10月24日 (金)

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

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

メモ:

基調講演 @xaicron 氏

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

Ramen Challenge の可視化 @Niratama 氏

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

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

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

Perl::Lint @moznion 氏

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

LT

  • @bayashi 氏
    • Benchmarks.pm penchmarks。たしかに Benchmark の使い方は毎回 perldoc して思い出す必要がある。
  • @sugyan 氏
    • EmacsPerl (helm、helm-perldoc、undo-tree など)。そろそろ anything から helm に移行しないとな。
  • 「僕がwebアプリケーションのコードを書く時に考えていること 〜短縮版〜」 @dameninngenn 氏
  • @kfly8 氏
    • Benchmark。@bayashi 氏とまさかのかぶり。
  • @akihiro_0228 氏
    • 僕がPerlに慣れるまで。
  • @__papix__ 氏
    • Docker 関連。
[ 10月24日全て ]

2014年11月14日 (金)

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

naney:15605588737

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

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

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

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

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

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

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

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

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

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

2014年11月14日

[ 11月14日全て ]

2014年12月9日 (火)

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

[ 12月9日全て ]

2015年2月20日 (金)

Developers Summit 2015 2日目

naney:15977907243

昨日に引き続き今日も 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日間の発表についての雑感

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

2015年9月28日 (月)

TodoistTrello や【日記】

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

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

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

[ 9月28日全て ]

2016年12月13日 (火)

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

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

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

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

技術的負債

技術的負債。当初は

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

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

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

技術的負債ですが

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

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

ただ

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

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

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

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

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

技術的負債の返済

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

あたりがポイント。

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

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

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

[ 12月13日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィの SNS の企画開発を行うグループでマネージャー・プロダクトオーナーをしています。CS 向上・ユーザーサポート・健全化などにも取り組んでいます。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.06037s / load averages: 0.44, 0.78, 0.79
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker