CS

CSの勉強会に参加しました

先日、CSとプロジェクト進行をテーマにした勉強会に参加してきました。

なんで参加したのか

以前、デザインについての勉強会に参加した際に
「カスタマーサクセス」というワードを初めて知り興味を持ったのと
プロジェクトの進め方について情報を得たかったからです。
ワークショップ形式なので参加者と話しやすいだろうという考えもありました。

CSとは

カスタマーサポートまたはカスタマーサクセスを指します。
最近はカスタマーサクセスと呼ばれていることが増えているようです。
UI → UX のような潮流を感じます。

プ譜

「プロジェクト譜」の略でプ譜には以下の5点を記述します。

  1. 獲得目標
  2. 勝利条件
  3. 廟算八要素(人材、予算、技術、品質、納期、環境、競合、外敵)
  4. 中間目的
  5. 施策

プロジェクトの状態に応じてプ譜を改訂し獲得目標を達成に導くという
まさに「プロジェクトの系譜」となるものです。
PDCAを体系的に表せるなと思いながら聞いていました。

詳しいことは以下を参照してください。

ワークショップ(プ譜作成)

架空のカスタマーサポート課に在籍している体で臨みました。

カスタマーサポート課の背景

1
2
3
4
BtoBの会社で、自社製品のお問い合わせサポート窓口となっている。
使い方などに関してはサポート課で回答し、技術的なことは開発に回答をもらっている。
サポート課からの問い合わせに対し、開発のレスポンスが悪い。
近頃、クレームやクレームに発展しそうな問い合わせが増えてきている。

それに対して作成したプ譜の内容

  1. 獲得目標:お客様の問い合わせを通し、会社にいいサイクルをもたらす起点となる。
  2. 勝利条件:
    1. クレームメールの減少
    2. カスタマーサポート課から製品のユーザビリティ向上に寄与
  3. 廟算八要素
    1. 人材:カスタマーサポート課のメンバー(3名)
    2. 予算:特になし
    3. 技術:タスク管理ツール(Redmineなど)
    4. 品質:基本はメールでのやりとりのみ。場合によって電話有
    5. 納期:順次
    6. 環境:同一社内
    7. 競合:-
    8. 外敵:回答/対応の遅い開発チーム
  4. 中間目的
    1. 対応内容の速度の向上
    2. テンプレートなメールを避ける
      • ↑「いい対応」の共有がカスタマーサポート課内で出来ている
  5. 施策
    1. 開発チームと対面で話す場を設ける
      • 温度感の共有
      • 場合によっては開発チームの部長を巻き込む
    2. 自分がプライベートで問い合わせを行った際によかった対応、不愉快だった対応を共有
      • セミナーへの参加
    3. (場合によっては)開発チームの部長を巻き込んで

#書き起こすにあたって文面をキレイにしましたが大筋はズレていません。
短い時間の割には考えられたんじゃないかと。実行できたら素敵。

発表を聞いていると、獲得目標に目標値を明確に打ち出している人が多かったです。
定量的だと評価しやすいもんね。

モデレータの前田さん曰く、獲得目標は定性/定量的どちらでもOKだけど
定性的なほうが自由がきくと話されていました。

個人的には、獲得目標はブレない根幹となるものを定性的に掲げ、
中間目標や勝利条件を評価しやすい定量的な目標にするのがやりやすいかなと感じました。

プロジェクトの過程が体系的に見て取れるのは面白いし大事だと思う。
根気がいるな…

参考

Share

Windows7でiOS11のsafariをデバッグ

仕事でiOSのsafariをデバッグする機会があったので手順を備忘録として残します。

  1. (未インストールの場合) iTunes をダウンロードする
  2. (未インストールの場合) Node.js をインストールする
  3. コマンドプロンプトを管理者権限で起動する
  4. コマンドプロンプト上で npm i -g remotedebug-ios-webkit-adapter を実行
  5. remotedebug-ios-webkit-adapter の zip をダウンロード
  6. %AppData%\npm\node_modules\remotedebug-ios-webkit-adapter\node_modules\vs-libimobile\ios-webkit-debug-proxy-1.8-win64-binという名前のフォルダを作成
  7. 6で作成したフォルダの中に zip の中身を展開
  8. %AppData%\npm\node_modules\remotedebug-ios-webkit-adapter\out\adapters\にあるiosAdapter.jsファイルの132行目あたりのconst proxy=...を以下の値に修正

    1
    const proxy = path.resolve(__dirname, '../../node_modules/vs-libimobile/ios-webkit-debug-proxy-1.8-win64-bin/ios_webkit_debug_proxy.exe');
  9. 確認したいデバイス(iPad など)を接続

  10. コマンドプロンプト上でremotedebug_ios_webkit_adapter --port=9000を実行
  11. Chrome を開き、アドレスバーにchrome://inspect/#devicesと入力
  12. 設定を開き、localhost:9000を追加
  13. 確認したいデバイスの safari の設定(設定 > Safari > 詳細)の
    「Web インスペクタ」を有効化
  14. safari でデバッグしたい url を開く
  15. Chrome の Remote Target に safari で開いた url が表示されるので inspect をクリック
  16. 表出したウィンドウでデバッグ

ブラウザ間の挙動の違いには、いつも泣かされます。。。

【参考】
Debug a Website in iOS Safari on Windows 10

Share

新しい言語に挑戦してみる

5月に突入しました。
来月で2018年の半分が終る…いつもながら時の経過の早さに驚きます。

4月は新入社員と覚しき人達を見かけることが多く
初初しいなぁと微笑ましく見ていました。
そんなフレッシュさに触発され、新しいことを始めるにはいい季節!ということで
先月は新しい言語と経験言語の復習に挑戦しました。

ProgateでRuby,Pthon,Saas,Java,SQLを、
Goは公式サイトでチュートリアル(Basicsまで)をこなし、
AidemyでPython入門に取り組みました。

Progateは各言語で題材が似ているので
途中、食傷気味になりつつも表現の違いが比較しやすく、楽しく学べました。
Saasについて理解していなかったのでやってよかったです。

Golangはなんと言っても速い。
ポインタがあることにびっくりしました。

たまには入門もいいですね。
今後もちょこちょこ続けていこうと思います:)


このブログについてですが、masterブランチが更新されたら
firebaseにデプロイされるようGitlab CIと連携させました。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
#.gitlab-ci.yml

image: node:latest

cache:
paths:
- node_modules/

deploy_production:
stage: deploy
environment: Production
only:
- master
script:
- npm install -g firebase-tools hexo-cli
- npm install
- hexo generate
- firebase use --token $FIREBASE_DEPLOY_KEY production
- firebase deploy -m "Pipeline $CI_PIPELINE_ID, build $CI_BUILD_ID" --non-interactive --token $FIREBASE_DEPLOY_KEY

これで更新が楽になりました〜

【参考】
Automatically deploy to Firebase with Gitlab CI

Share