Date.today > Date.yesterday は必ずしも真ではなかった

Ruby on Railsの話です。

まとめ

もうすこし詳しく

Date.today に関してはまとめに書いた以上の説明は特になし。

Date.yesterday に関して少しだけ。

    # Returns a new Date representing the date 1 day ago (i.e. yesterday's date).
    def yesterday
      ::Date.current.yesterday
    end

https://github.com/rails/rails/blob/5f3ff60084ab5d5921ca3499814e4697f8350ee7/activesupport/lib/active_support/core_ext/date/calculations.rb#L37-L40

Date.current に対してyesterdayを呼んでる。Date.currentはこう。

    # Returns Time.zone.today when <tt>Time.zone</tt> or <tt>config.time_zone</tt> are set, otherwise just returns Date.today.
    def current
      ::Time.zone ? ::Time.zone.today : ::Date.today
    end

https://github.com/rails/rails/blob/5f3ff60084ab5d5921ca3499814e4697f8350ee7/activesupport/lib/active_support/core_ext/date/calculations.rb#L47-L50

アプリケーションでタイムゾーンが設定されている場合は Time.zone.today を返す。

気づいたきっかけ

お仕事。

%m/%d のようなフォーマットで渡されるStringをDateに変換し、その日付が今日より前だった場合に特定の処理を実施する、というロジックがあった。

date_string = '01/29' # 外部から渡される(CSVファイルとか...

if date_string.to_date < Date.today
  # do something
end

対象のシステムはUTCで動いているので、この処理をJSTの1月30日00:00~08:59に実行すると Date.today は「1月29日」になる。 そのため date_string.to_date < Date.todayfalse になる。

これは想定した挙動ではなかった。

気づいたのはたまたま朝9時前にテストコードを実行した日があり、CIがfailしていたからだった。

テストコードでは date_stringDate.yesterday.strftime('%m/%d') で生成していた。
アプリケーションのタイムゾーンの設定はJSTになっているため、このテストをJSTの1月30日00:00~08:59に実行すると、タイムゾーンが考慮されてDate.yesterdayは1月29日になる。

気づけてラッキーだった〜。

で、こういう修正をした。

- if date_string.to_date < Date.today
+ if date_string.to_date < Time.zone.today
  # do something
end

アプリケーションのタイムゾーンを考慮して「今日」を判定できるようになったのでおっけ。

ひとこと

Date.today > Date.yesterday が真とは言い切れないの、時空が歪んでいる感じがしてすごい。

おしまい。

犬好きのためのSUZURI 2020

SUZURI Advent Calendar 2020 - Adventar の6日目。

5日目の記事はこちら↓

scrapbox.io

2020年はリモートワークになって人生においてもとても大きな変化だったなぁ。 リモートワークの整備はみんなでやってきたけど、とりわけshimojuさんが率先して進めてくれてとても助かった。本当に大感謝。

リモートワークに加えて、個人的な「2020年の大きな変化」は、9月からゴールデンレトリバーを飼い始めたこと。

めっちゃかわいい。

f:id:tanaken0515:20201205163548j:plain

この記事では犬好きのためのSUZURI情報を書いていく〜。

犬を飼っている人にオススメのアイテムベスト3

直近の数ヶ月間を犬と過ごしてみて「オススメしたい!」と感じたSUZURIのアイテムたち。

第3位: ブランケット

https://suzuri.heteml.net/suzuri/blanket2-6.jpg

忍者スリスリくん ( surisurikun ) の「 新アイテム【ブランケット】の詳細情報公開!!! 」というジャーナル ∞ SUZURI(スズリ)

12月に入って一気に寒くなった。冬、本気出してきた。寒いと感じているのは人間だけでなく犬も同じ。犬が寝るときにブランケットが1枚あると安心。

好きなデザインのブランケットに包まれている犬の寝顔、最高〜〜〜

第2位: ウエストポーチ

https://d233sqxsrf11cu.cloudfront.net/img/1.9bc97e0.jpg

軽くて大容量。SUZURIのウエストポーチ ∞ SUZURI(スズリ)

犬のお散歩は地味に荷物が多い。犬用の携帯ドリンク容器、ウンチをした時に使うエチケット袋、子犬の場合は訓練用(ごほうび)のオヤツ、などなど。お散歩中にウンチをしたら、エチケット袋で回収して持ち帰る必要もある。

そういった荷物を運ぶ際にウエストポーチが便利。荷物を持つ手が空くのでしっかりとリードを持ってお散歩を楽しむことができる🐕

荷物の手が空くという点ではサコッシュもオススメだけど、ウンチ入りのエチケット袋を運ぶ際にはかなり豊潤な香りがするので、個人的にはファスナー付きのウエストポーチの方が適しているかなと。

第1位: アノラック

https://suzuri.heteml.net/suzuri/journal/2019SS/02.JPG

忍者スリスリくん ( surisurikun ) の「 [NEW]アノラックについて。(SUZURI X) 」というジャーナル ∞ SUZURI(スズリ)

これめちゃくちゃ良い!

まずは大きなポケット。これがあるので散歩用品の一部をここに入れることができて便利。

つぎに撥水効果。お散歩中に休憩でお水を飲ませる時、アクシデントで水がこぼれて服にかかっちゃうのはありがち。そんな時に水を弾く!濡れない!

つづいて防風(?)。風が強い日にお散歩をすることもある。このアノラック、風を通さない力が結構すごい。冬場でも、温かいパーカーやスウェットを着てその上にアノラックを着ればバッチリ◎

さいごに防 "噛み癖"。うちのワンコ、噛み癖がすごいのだよなぁ。様々な衣類が被害にあっているのだけど、このアノラックは生地がとてもしっかりしていてまだ穴が空いていない。すごい。噛まれても大丈夫!(噛まないように訓練中)

個人的なお気に入り犬ショップベスト3

犬関連アイテムを販売しているお気に入りのショップたち。 

第3位: OOKIIINUさん

suzuri.jp

大型犬にまつわる魅力的なアイテムを販売しているショップ。

小型犬も好きだけど、やっぱり大型犬のもふもふ感が好き。身体は大きくてどっしりしていても心はヤンチャだったりする、そのギャップもかわいい。やっぱり大型犬だよな〜。

で、このショップで気になっているアイテムはこのグラス。かわいくて、かつ、ちょっと勉強になるテクニックが書いてあって素敵だな〜。

f:id:tanaken0515:20201205160019p:plain:w480

OOKIIINU TECHNICS / OOKIIINUのグラス通販 ∞ SUZURI(スズリ)

第2位: もんとみ( •ө• )さん

suzuri.jp

犬のあるあるなワンシーンのアイテムを販売しているショップ。

このショップといえばこれかな〜!この状態の柴犬ときどき見かけるわ〜、というやつ。首元がぶにゅっとなっていて、シッポはくるんと丸まっていて、かわいい。

f:id:tanaken0515:20201205153930p:plain:w480

散歩から帰りたくない柴犬 / もんとみ( •ө• ) ( shigemochi_kun )のTシャツ通販 ∞ SUZURI(スズリ)

第1位: efrinmanさん

suzuri.jp

主にゴールデンレトリバーのエフちゃんコメちゃんをモチーフにしたアイテムを販売しているショップ。

ゴールデンレトリバー好きにはたまらないアイテムがたくさんある。

思い出のアイテムは、以前のスマホの時に使っていたこのスマホケース。一生懸命クツを運んでいる様子が愛らしい。うちのワンコもクツを運んでくれないかな〜 🐕

f:id:tanaken0515:20201205162518p:plain:w480

師匠と弟子(ネイビー) / efrinman ( rinman )の手帳型スマホケース通販 ∞ SUZURI(スズリ)

まとめ

この記事では犬好きのためのSUZURI情報を書いた。

SUZURIの犬アイテムをもっとみたい方はこちらからどうぞ(犬が飛びます) https://suzuri.jp/search?q=犬

ではまた。

犬の散歩を始めたら道端のゴミが気になるようになった

飼っている愛犬(ラテちゃん)の予防接種を終えて、2020-10-13から毎日お散歩をしている。

f:id:tanaken0515:20201129194018j:plain

いまは1回30〜40分のお散歩を1日2回、朝と夕方にやっている。 心身のリフレッシュになっていてとても良い。なによりラテちゃんがかわいい。

ラテちゃんは好奇心旺盛で、お散歩中に出くわすすべてのものに興味があり、何でもかんでも咥えて食べようとしてしまう。

落ち葉や生えている雑草、花壇のお花、プラスチックの破片やタバコなど、本当になんでも食べようとする。

食べさせたくないので、食べようとしたらリードを引いて止めるか、咥えてしまったらなんとかしてクチから取り出す。

視点が変わるとモノの見え方が変わる

ラテちゃんとのお散歩を始める前までは何も感じなかったのに、お散歩を始めてから道端のゴミがすごく気になるようになった。

特にタバコの吸い殻は絶対に食べさせたくなくて、そういう気持ちで道を眺めると想像以上に落ちていることに気づく。

タバコのポイ捨て、ダメ、ゼッタイ。

これまではタバコの吸い殻が道端に落ちているのを見つけたときに、「よくないな〜」と思うに留まって、これがどんな実害に結びつくかまでは考えていなかった。

いまは、犬や小さな子どもが食べたら死んじゃうかもしれないじゃん!という実害にしっかりと結びついている。

視点の切り替えを意識する

視点の切り替えについて、たまたま関連がありそうな記事を2つ読んだ。*1

両方ともとても面白い記事で、物事への向き合い方や立場を強制的に切り替えることで思考の広がりが生まれている様子が伺える。

面白いな〜と感じると同時に、「自分は物事への偏った向き合い方や偏った立場での思考や言動をしていないだろうか...?」と怖くなった。

ある物事について考えたり会話したりする際に、

  • 自身がその物事に対してどのような向き合い方をしているか
  • どの立場で思考しているか

を意識しようと思った。

意識というか、この2つを明示した状態で考えたり会話したりすることしよう。

これをやると、より良い思考や会話になっていくと思う。

*1:きっかけはキマグレエフエムのエピソード17で、デイリーポータルZの與座ひかるさんの記事が紹介されていたこと。與座さんの記事をいくつか読んでいった中にこの2つがあった。キマグレエフエム、いつも聴いています。

tanakenの考えるCREとその行動指針

以前書いた CREとはなんなのかを考えている - tanaken’s blog の記事で、CREを次のように定義した。

顧客の不安をゼロに限りなく近づけるために、課題を把握・計測し、技術的なアプローチでその課題の解決に役立つものを実現していくこと

この定義では「顧客の不安をゼロに限りなく近づける」「課題を把握・計測」「技術的なアプローチ」「解決に役立つものを実現」などのキーフレーズで、CREとしてやるべきことのエッセンスを提示することができたと考えている。

一方で、この定義は抽象的であり、いまいち実態を掴みにくい。

この定義に基づいて考えると、CREの業務は多岐にわたる。それゆえに、具体的な業務内容について共通認識を作ることが難しいと感じている。

共通認識を生みやすい状態にする1つの手段として「CREの業務内容をなんらかの方法で分類する」というアプローチを採ってみる。

CREの多岐にわたる業務内容がいくつかのまとまりに分類されることで、話題のスコープが小さくなり、その結果として具体的なイメージがわきやすい(=共通認識を生みやすい)状態になることを期待する。

この記事では、①CREの業務内容の分類とそのプロセス、②その各分類における業務内容の具体例、③そのうえでtanakenのCREとしての行動指針、について述べる。

CREの業務内容の分類

分類の方針

CREの業務内容を分類するにあたって、CREの定義にもう一度立ち返ってみることにする。

CREの目的は「顧客の不安をゼロに限りなく近づける」ことである。

その目的に沿って考えると、CREの活動は「顧客の不安が発生し得るシーン」に対してアプローチをしている、と捉えることができそう。

顧客の不安は、サービスとの様々な接点において発生する(接点がなければ発生しない)と考えられるので、「サービスと顧客との接点」という観点でCREの業務内容を分類してみようと思う。

分類のプロセス

プロダクト

顧客との接点として、まず思いついたのは「プロダクト」だった。 顧客はPCやスマートフォン等の端末でプロダクトを利用している。

f:id:tanaken0515:20201031173459p:plain

プロダクト以外

おそらく多くのサービスにおいて、顧客との接点は「プロダクト」だけではないだろう。 顧客の獲得や関係性の構築をする「営業活動」や、顧客のお問い合わせを解決する「お問い合わせ対応」も顧客との接点である。 また、顧客は様々なメディアでサービスの「広告」を見聞きしているだろうし、「SNS」の公式アカウントの情報を見ている可能性もある。 そのほかにも接点はあるかもしれない。

f:id:tanaken0515:20201031174701p:plain

運営組織

そして、それらの接点を生み出す人間たちとその組織がある。 f:id:tanaken0515:20201031180810p:plain

運営組織自体が直接顧客と関わることは少ないかもしれないが、顧客が運営組織の実態(例えば金銭の管理や個人情報の取り扱い、システムの開発フローや障害発生時の対応フローなど)を知ることで「顧客の不安」が発生するケースはある*1

分類結果

以上のように「プロダクト」「営業活動」「お問い合わせ対応」「広告」「SNS」等の様々な顧客との接点とそれらを生み出す「運営組織」があり、それぞれについて 顧客の不安をゼロに限りなく近づけるために、課題を把握・計測し、技術的なアプローチでその課題の解決に役立つものを実現していくこと がCREである、と捉えることができる。

また、各接点での顧客とのコミュニケーションに不整合がある場合、顧客の不安に繋がる可能性があることから、各接点で一貫性のあるコミュニケーションを取るために「ブランディング・サービスデザイン」の観点で技術的なアプローチをしていくこともCREの役割であると考えるに至った。

最終的に図にすると次のようになる。

f:id:tanaken0515:20201031194353p:plain

各分類における業務内容の具体例

上に示した図の各分類における業務内容の具体例を思いつくまま書いてみる*2

  • 「プロダクト」
    • アクセスデータを分析してどの画面で利用が滞っているのかを把握する
    • 利用を促進するようにその画面のUIを変更する
  • 「営業活動」
    • 営業先の情報をスクリプトを組んで収集する
    • 営業先に伝えたい情報を営業担当者からヒアリングし、データを集計・可視化して提供する
  • 「お問い合わせ対応」
    • お問い合わせの情報を集計し、発生頻度の高いお問い合わせを把握する
    • お問い合わせの要因となっている処理のロジックを修正する
    • 社内向けの顧客管理画面を改修し、問い合わせ対応を省力化する
  • 「広告」
    • 広告経由での利用者について、その後のプロダクトの利用状況を計測する
    • 計測結果に基づいて広告運用担当者にフィードバックする
  • SNS
    • SNSの投稿に対する反応を分析し、SNS運用担当者にフィードバックする
  • 「運営組織」
    • お金の管理状況を可視化し、管理フローを定めて運用する
    • 顧客データの修正に対してルールを定めて運用する
  • ブランディング・サービスデザイン」
    • 各接点で利用する単語の表現と定義が揺れないようにテキストを自動検査する仕組みを作る

どうだろう。分類する前と比較して、具体的な業務内容をイメージできるようになっただろうか。

個人的には脳内が整理しやすくなって便利だな〜と感じている。

CREとしての行動指針

以上を踏まえて、CREとしての自身の行動指針を記載しておく。記載しておくことで、迷った時にここに立ち返って考えることができるようにする。

担当サービスのCREとして

自分はいまSUZURIというサービスを担当している。

SUZURIのCREとして、直近では「運営組織」「お問い合わせ対応」「プロダクト」「営業活動」の4つに注力していきたいと考えている。

f:id:tanaken0515:20201101160350p:plain

まずは「運営組織」について。
SUZURIはここ2,3年で急成長しているサービスであり、それに伴って組織の規模も拡大してきた。 組織の拡大に応じて、運用ルールや管理フローの整備が必要な状況にある。 売上規模の拡大によって社会へのインパクトが大きくなった分、サービスとしての責任も大きくなっている。 まさに運営組織の信頼性をあげる活動が必要だ。
直近の自分の動きは主にこれで、内部統制の運用ルールやフローを整備したり、お金周りのロジックを精査してより健全な状態を作ることをメインの業務として実施してきた。センシティブな案件が多く、開発規模が大きなものも控えており、決して楽ではない(正直かなりしんどい)が、引き続き着実に対応を進めていく。

次に「お問い合わせ対応」について。
SUZURIへのお問い合わせの件数には波がある*3。 問い合わせが混雑している時期では、かなり長い間ユーザをお待たせしてしまう状況となっている。この状況を解消するために、お問い合わせのタネとなる事象を減らす、その事象が発生してもユーザが自己解決できるように画面や機能を見直す、多数のお問い合わせが来ても省力で対応できるようにする(結果的にお待たせ時間を削減する)、等をやっていく。
また、SUZURIのお問い合わせ対応チームのメンバーも増員したため、お問い合わせ関連業務においてこれまで属人化していたものや暗黙知化していたものを構造化・自動化することにも取り組み、増員に強いチームづくりを支援していく。

続いて「プロダクト」について。
データを活用したプロダクトの改善サイクルを回すことができていない。また、取り組んだ方が良いとは思いつつ取り組めていないことがたくさん溜まっていて棚卸しや優先順位づけも後回しになっている。
今後はデータを活用してユーザの不安の発生箇所を捉えることや、ユーザとの信頼関係を築くという視点で取り組めていない案件の棚卸しと優先順位づけを実施して順次取り組んでいく。

最後に「営業活動」について。
SUZURIでは、すでにサービスを使ってくれているクリエイターさんと協力してイベントを開催したり、まだSUZURIを利用していないクリエイターさんにSUZURIを紹介したりといった営業活動がある。
この営業活動の中でクリエイターさんに与える不安が小さくなるよう、営業活動を支援するための情報の提供や機能開発に取り組んでいく。

以上の4つを注力ポイントとして、ユーザとの信頼関係を築きながらサービスの長期的な成長に貢献したいと考えている。 また、これらの活動を通じて、「実現したいこと」や「解決したい課題」に対してユーザと共に向き合っていく*4サービスでありたいと考えている。

f:id:tanaken0515:20201101172304p:plain

所属会社のCREとして

自分はいまGMOペパボ株式会社(以下、ペパボ)に所属している。ペパボにはいくつかの事業部があり、それぞれの事業部でサービスを展開している。

f:id:tanaken0515:20201101173834p:plain

ペパボでCREをやっていく上で事業部内に閉じて各サービスに特化した活動を実施していくことも重要だが、事業部を横断して協力して活動することも重要であると考えている。
その理由として、1つは共通している課題に対しては共通したソリューションを適用した方が省力で済むため。もう1つは、ペパボと顧客という見方をした場合に一貫性のあるコミュニケーションを取るために、事業部を横断した視点が必要であると考えられるためである。

f:id:tanaken0515:20201101175925p:plain

この観点で、事業部を横断したCREメンバーの情報共有会やソリューションの共通化に取り組んでいく。

CREに携わるひとりのエンジニアとして

CREの活動は、様々なサービス・様々な企業で実施されている。

前項でも述べたが、共通している課題については共通したソリューションを適用した方が省力で済む。 そのため、CREとしての経験・知見・ソリューションは、他の企業にも適用可能な形で発信していこうと考えている。

また、企業を超えたCREのコミュニティづくりにも取り組んでいく。このコミュニティによって企業を超えた情報交換が促進され、各社のCREとしての活動がより洗練化されたものになる状態を目指したい。

まとめ

この記事ではCREの多岐にわたる業務内容を「顧客との接点」の観点で分類し、その各分類について具体例を挙げたうえで、自身のCREとしての行動指針を述べた。

CREとして活動されている方やCREに興味を持っている方にとって役立つことが少しでもあれば嬉しいなぁと思う。

*1:tanakenの観測範囲での具体的な事例としては「セブンペイの事件を受けて運営組織への不安が高まり、セブンイレブンの利用を控えるようになった」という話を耳にする

*2:挙げたのはあくまで一例であり、また、なるべく一般化して書いたつもりなのでその分詳細が曖昧で意味が通っていないものもあるかもしないが、ご容赦願いたい。

*3:セールや有名クリエイターさんの利用開始の影響で突発的に注文件数が増え、それに伴なってお問い合わせの件数が増える、という傾向がある。

*4:GoogleがCREを提唱した記事の言葉を借りるなら「運命共同体」になっていく

センキュー9月

9月2日からゴールデンレトリバーを飼い始めました。 6月23日生まれの男の子、名前はラテです。

ここ数ヶ月はとても忙しくて、9月になってやっと落ち着きました。

9月は好きです。夏から秋に変わっていく感じが好きです。 ちょっと涼しくなってきたね〜、と言うのが好きです。

2020年も残すところ3ヶ月ですね。実質今年も終わりなのでふりかえりをします。

2020-01..2020-03

趣味

正月は初めてニューイヤー駅伝をみました。毎年箱根駅伝は応援に行っている(地元が小田原なので)のだけど、今年は勤め先のチームが出場するとのことで大応援しました。あとはSwitchばっかりやってました。

1/1(水・祝)ニューイヤー駅伝で5位入賞! - GMOアスリーツ

あとはこの頃競技プログラミングにハマっていて、毎日解くぞ〜という感じでやってました。 ブログも書きました。地味にアクセス数が多くて競プロすごい。

なぜ競技プログラミングを楽しいと感じるのか - tanaken’s blog

あとは、Gemを作るのもなんだか楽しいなぁと感じていて、自然言語処理APIのGemを作ったりしてました。 API Client の rubygem を作ってみた - tanaken’s blog

いま思うと色々やってたなぁ。

生活

COVID-19の感染拡大に備えて在宅勤務が始まりました。

GMOインターネットグループ、新型コロナウィルスの感染拡大に備え在宅勤務体制へ移行 | GMOインターネット株式会社

この頃は、こんなに長期で在宅勤務をすることになるとは思っていなかったなぁ。 他国でCOVID-19の感染が広がり始めている、という事実すら認識していなかったので会社に「マジ感謝」という気持ちです。

匂いを気にしなくて良いという理由で毎日のように納豆を食べていました。

あとは、大好きなカレー屋さんが移転してしまうとのことで泣きながら食べるなどしました。

移転先でも泣きながら食べました。

お仕事

この頃のお仕事内容としては、

写真共有サービス 30days Albumに、SMSによる本人確認の機能を実装したり、

自分だけのオリジナルアイテムを手軽に作成・販売 | SUZURI(スズリ)バケットハットを追加していました。

suzuri.jp

あとは

という気持ちがあり、ご縁があってかんたん募集サービス bosyuの開発をお手伝いし始めました。

bosyuでは主にユーザに見えない社内向けの画面の機能開発やデザイン刷新をやっていました。全面的にVue.jsにしてElement UIに書き換えていくのは良い経験になりました。

2020-04..2020-06

趣味

チャーシューを煮込み始めました。

ラーメンを食べるのが楽しみになりました。

生活

緊急事態宣言がありました。外出を控えねばならないの、こんなにもストレスなのだなぁと思いました。ふらっとカフェに行ったりできない、選択肢を減らされている感覚がなんともモヤモヤでした。

会社がリモートワークを基本とする体制になりました。

pepabo.com

「いつかは去年のように毎日会社に行く日々になる」という前提がなくなり、「これからはリモートワークでやっていくぞ」という方針を定めてくれたので、住む場所の選択肢が広がって嬉しかったです。諸々の制度を整えてくださった社内の皆さんに大感謝。

お仕事

CREという考え方に出会いました。 出会うというか、もともと知ってはいたんですが、その考え方にちゃんと向き合うようになった、という感じです。

CREとはなんなのかを考えている - tanaken’s blogの記事で考えたことを、いまの現場でやっていくにはどういうアクションになるだろう...、というのを常に考えていました。あらゆることをCREの観点で考えていく思考になりました。

「7月以降はもっと体系的にCREな仕組みを作っていくぞ〜〜」という気持ちになっていました。

2020-07..2020-09

趣味

散歩をするようになりました。

歩きながらPodcastを聞くのが好きになりました。

生活

引っ越しをしました。都心から少し離れましたが、引っ越し前と同程度の家賃で一部屋多い物件に引っ越すことができたので大満足です。

そして最高にかわいいラテちゃんを飼うことが出来ました。

お仕事

期日の決まった大事なお仕事がガッと来たのでめちゃくちゃ忙しい時期でした(引っ越しとも被せてしまったし)

具体的には忍者スリスリくん ( surisurikun ) の「 トリブンのお振り込みの仕様変更について 」というジャーナル ∞ SUZURI(スズリ)に関する実装と、所属部署の内部統制に関して現状のシステムの仕様をドキュメント化したり目指すべき状態を制度に落とし込むための対応フローづくりをしていました。すごく大変で、疲れました。 なんとか期日内に終えることが出来て良かったです。

bosyuでは社内向けの画面の案件がひと通り落ち着いたので、ユーザ向けの画面をいくつか実装しました。 例えばハッシュタグの画面(エンジニアの募集一覧 | bosyuとか)やSEO関連の実装をしました。

まとめ

2020年をふりかえってみました。

意外といろんなことやってるじゃん、という感想でした。 ずっと家にいるのでなんとなく変化のない毎日のように感じてしまうけど、意外といろんなことやってました。

でもこれは意識的に何かやろうというエネルギーがあったからだよなぁと、過去の自分、結構やるじゃん、と。そんな感覚です。

8月末まで疲れすぎていて、9月も疲れを引きずっているうちに終わってしまったような気がするので、10月からは切り替えてやっていこうと思います。

やってくぞ〜〜!センキュー9月!!

読んだ「カスタマーサクセスの実現のためCustomer Reliability Engineering(CRE)チームを立ち上げました | FiNC Tech Blog」

カスタマーサクセスの実現のためCustomer Reliability Engineering(CRE)チームを立ち上げました | by 小林毅志 | FiNC Tech Blog | Jul, 2020 | Mediumを読んだ。

読みながらマインドマップを作った。

f:id:tanaken0515:20200803084808p:plain

https://www.mindmeister.com/ja/1579107296/finc-cre

感想

ブログ記事の「課題」の部分、自分にとってはあまり読みやすくなかった(並列ではない事柄が並んでいるように見えた)

「新規機能の開発で手一杯」と「本質的な改善に動く余裕がなかった」は結局どうやって解決したのか分からなかった

  • CREチームが誕生した時点ですでに解決していた?
  • 人員を増やす、新規機能の開発を止める(優先度を下げる)、あたりのアクションが必要そうだと感じる
    • 「今ではPM1名、バックエンドエンジニア4名、iOSエンジニア1名とチームのメンバーも増えてきました」
    • すごい。このメンバーたちがいるから解決した、ということかな?

問い合わせ件数が半分になったのすごい

  • DAUを伸ばしつつお問合わせ件数半分とのこと
  • ここでの「お問い合わせ」はユーザからCSへのお問い合わせかな
    • 「当然、エンジニアにくる問い合わせ自体も減っています。」という記載があるから、そうっぽい
    • ユーザ -> CS -> エンジニア のどの矢印のことを指しているのか分かりやすく書けるともっとよさそう
  • ユーザに困りごとを発生させない、あるいは、お問い合わせをしなくても困りごとを解決できる、という状態を目指していきたい
    • これは結果的にユーザからCSへのお問い合わせの件数に反映されるはず
    • 一方で、お問い合わせの件数が減ったからといって、本当に困りごとが解決していると言い切れるのか?という話もある
    • 本当に困りごとが解決しているのかどうかを、把握できるようにする必要がありそう

「信頼」について考える

心理的安全ジャーニー Slackで安全を実装する5つの手法 - Speaker Deck を読んだ。 「心理的安全性」という言葉について、Googleによる定義に基づいて図解を織り交ぜながら分かりやすく説明してくれている。

今回は、この資料の後半に出てくる「信頼」という言葉について考えたい。

なぜ「信頼」について考えるか

いま自分が取り組んでいるCustomer Reliability Engineering(CRE : 顧客信頼性エンジニアリング)の活動においても「信頼」という言葉が出てくる。

➡︎CREについての記事はこちら: CREとはなんなのかを考えている - tanaken’s blog

けど「信頼」という言葉自体について考えたことなかった。

今回の資料での「信頼」は「チーム内の対人関係における信頼」なので、これをそのまま「CREにおける信頼」として解釈するのは適切ではないかもしれない。

とはいえ同じ「信頼」という言葉なので、ヒントとなる考え方はありそうな気がしている。

信頼とは何か

f:id:tanaken0515:20200729083042j:plain 引用: 心理的安全ジャーニー Slackで安全を実装する5つの手法 - Speaker Deck

  • 自分に何か困ったことが発生した時、何かに悩んでいる時、誰かに頼りたい時、相手が相談に乗ってくれる、一緒に解決策を考えてくれる、そういう行動をしてくれると信じること = 信頼 なのだなぁ
    • その問題の解決に至るかはここでは議論されていない(もちろん解決できた方が良いと思うけど)
  • CREの観点で考えてみると、登場人物は「顧客」と「サービス運営者」がいる。「サービス運営者」としては「顧客」に次のように感じてもらう(=信じてもらう)ことを目指したいなと思った。
    • 問い合わせをしたらすぐに相談に乗ってくれそう
    • 一緒に解決策を考えてくれそう
    • 実現したいことを手助けしてくれそう
  • 「顧客」のことを信じるという観点も忘れずにいたいなと思った
    • 相互に「信頼」を築きたい

信頼に至るまで

f:id:tanaken0515:20200802094142j:plain 引用: 心理的安全ジャーニー Slackで安全を実装する5つの手法 - Speaker Deck

  • 信頼への道のりには「親和」と「尊重」がある
  • のりを早く進むには「感謝」も大事っぽい

親和について

f:id:tanaken0515:20200729090816j:plain 引用: 心理的安全ジャーニー Slackで安全を実装する5つの手法 - Speaker Deck

f:id:tanaken0515:20200729091514j:plain 引用: 心理的安全ジャーニー Slackで安全を実装する5つの手法 - Speaker Deck

  • 「親和」を築くには「コストを払ってまで友好関係を築きたい」という意思を相手に伝えることが大事らしい
    • ちょっと恩着せがましいような印象もある...
    • でもまあわからなくもない
      • ちょっとしたことで「こんなことしてくれるんだ〜」と嬉しくなる瞬間はある
      • 例えば、スタバでカップにお絵描きしてくれるやつとか
        • 自体自分にとっては特に利益にはならない
        • けど、なんとなく「悪い気はしないな〜」みたいな
          • 相手がちょっとしたコスト(時間)を払ってくれているからなのかな?(わからない)
  • CREの観点で考えてみると、「サービス運営者」は「顧客」との親和を築くためにコストを払って何かやってみよう、ということかな。
    • 例えばいま自分が携わっているSUZURIだと、このメールとかはまさにそれかもしれない

尊重について

f:id:tanaken0515:20200802094136j:plain 引用: 心理的安全ジャーニー Slackで安全を実装する5つの手法 - Speaker Deck

f:id:tanaken0515:20200802094131j:plain 引用: 心理的安全ジャーニー Slackで安全を実装する5つの手法 - Speaker Deck

  • 「静かな人に声を与える」の大事そう&むずそう
    • その場では考えを言わないけど別の場では言うとか、頭の中だけに留めてしまうとか、そういうケースあると思う
    • なぜそうなるのか?
      • たぶん「自分の考えを伝えても意味ないや」とか、「自分が意見を言うような話ではなさそう」とか、考えてしまう
    • どうすれば?
      • 「意見の尊重」をするのが大事
    • どうなる?
      • 「自分の考えを汲み取ってくれる」とか、「自分の意見がヒントになるかも」とか、考えるようになる
  • CREの観点では、「サービス運営者」は「顧客」に対して「意見の尊重」をしている姿勢を示す必要がありそう
    • 例えば「こんなご意見をいただきました!」のリストを開示するとか?
      • まずは意見がちゃんと届いていることを伝える
    • 意見に対する対応方針も示せるとよさそう(対応しない場合も含めて)

感謝について

f:id:tanaken0515:20200802094155j:plain 引用: 心理的安全ジャーニー Slackで安全を実装する5つの手法 - Speaker Deck

f:id:tanaken0515:20200802094149j:plain 引用: 心理的安全ジャーニー Slackで安全を実装する5つの手法 - Speaker Deck

  • 「感謝」に「同様の行為を返報として約束する」という解釈もあるのか。知らなかった。
  • 協力してもらった時その相手に感謝を伝えると、相手は「自分が同じような状況になったときに協力してもらえそう」と感じる(=信じる)ということだな。
    • これはつまり「信頼」だ
  • 感謝を伝えることで「信頼」が増える
  • CREの観点だと、「サービス運営者」と「顧客」の間で感謝を伝え合う仕組みがあるとよさそう

まとめ

「チーム内の対人関係における信頼」について語られた資料をみながら「CREにおける信頼」について考えてみた。

ヒントになることがいくつかあったのでよかった。実践していきたい。