「クリーンアーキテクチャ」選択を残して開発をするための設計
気づいたら時は流れ、アドカレ16日と＋X日になっていた...
というわけで最近また話題になっていたクリーンアーキテクチャについてです。
書籍『Clean Architecture』を読んで理解すると「クリーン・アーキテクチャで作りました」という発言は出なくなる。わかる。 pic.twitter.com/LkrWiNF1IP
— Takuto Wada (@t_wada) 2024年1月11日
このツイート、私も実際にクリーンアーキテクチャを読了して「わかる！！！」となったので、その辺りを話せればなと思います。
このよく見るあの図だが、本書では1度しか登場していません。 また、文脈としてもヘキサゴナルアーキテクチャやDCIアーキテクチャ、BCEなど様々なアーキテクチャの特性を統合したものとしている。
すなわち、「クリーンアーキテクチャ」というアーキテクチャというものはそもそも存在していません。では、本書が語っているクリーンアーキテクチャとは何なのか、なぜ行うのからに触れながら個人的に気になったところを書いていこうと思います。
なぜ設計を考える必要があるのか
ソフトウェアアーキテクチャの目的は、求められるシステムを構築・保守するために必要な人材を最小限に抑えることである。
様々な設計に関する本で語られている様に、この書籍でも技術的負債を溜め込まずリリースごとに労力が増えるといった状態になるのを回避することを考えている。
変更の難易度は、変更の形状ではなく、変更のスコープに比例しなければいけない。
これは非常によくある悪い状況の見方だなと感じる。
例えば画面に表示する1文を変更する要望があったとする。コードを見てみると、その文字列を別のところでも使っていてそっちの修正も必要になってきて、あれDBにも保存している？という厄介な問題になることがある。
これは変更の形状に対して、難易度が圧倒的に高い。よく設計が出来ていればスコープを文字程度簡単に修正し、ビジネスロジックの大きな変更など大変だと思われるものに、その通りの難易度が伴う形になる。
関心事の分離と依存関係のコントロール
個人的にこの書籍で最も語りたいところがこの部分だと感じる。
よく見るアーキテクチャもこの部分の影響を強く表しているという風に感じますね。
関心事をドメインなのか・技術なのかに分離し、ドメインが技術に依存しない様にコントロールする。これをするために、オブジェクト指向の様々な手法を使うことが記載されているのが本書になります。
この様に関心事を分離し、依存関係のコントールをすることで"ドメインに関してはフレームワークも含め、全てから独立させるべき"ということが実現します。
さてこれができると何がいいのか、ドメインにフレームワークやライブラリなどが依存している場合、それらの影響を受けることになります。それがバージョンアップならばまだ良いですが、放棄でもされた時には溜まったものではありませんからね。
また、ドメインを独立させるためにフレームワークの選定にも注意を促しています。
フレームワークの作者にとって、自分の作った基底クラスを大勢のユーザーが継承することほど、自尊心が満たされることはない。
少しマサカリのようだが、この様な記載がある。一旦モヤモヤを取り払い、性善説的に「大勢が基底クラスを継承することで新たな価値を提供しやすくなるために基底クラスを継承させたがっている」とでも解釈しておこう。
フレームワークをドメインに依存させない方法は簡単で、Entitiesなど内側に入れないこと、円の外側に対してのみ使用する。
関心事の分離と選択肢
この書籍はソースコードレベルの話ではなく、DBや提供する方法も含め"変更を容易にする設計をどの様にするか"という話になっています。
その中でデプロイという話も入っており、昨今のマイクロサービスの話が脳裏をよぎった。さて、ここでマイクロサービスでサービスを作った時、いざリリースの時に起動のタイミングなどが重要になったりする。
関心事を適切に分離することで、DBや提供方法といった"プロダクトの価値以外の選択肢を残すことができる"ことも利点となります。
クリーン・アーキテクチャで作りましたと言えなくなるについて
私個人の感想ですが、「作りました」と言っている時点でクリーンアーキテクチャではないと言えるのでは？と感じました。
なぜならばクリーンアーキテクチャとは、選択肢を常に残すことでプロダクトの提供方法といったビジネス的な決定や、技術選定を遅らせたり、移行のしやすさを保っているソフトウェアだからです。
なので、クリーンアーキテクチャかどうかは実際に運用に乗せ様々な課題を軽く往なせるかというところで判断するしかないのだと私は思っています。
「失敗から学ぶRDBの正しい歩き方」いつの間にか辛いを避ける歩き方
アドカレ15日目
プロダクトコードの負債より、DBの負債の方が大変だと感じています。DBの負債を変える場合、プロダクトコードにあるDBの読み込み・更新まで全て変更する必要がありますからね。
そういった点でも、いつの間にか沼地に迷い込んでいたということが起きないような道標になる良本です。
MySQLはjoinでNLJしか対応していない
Nested Loop Joinの略で参照される行数分だけループが行われるというもの。
JOINの対象となるカラムにINDEXを貼ると速くなるのは参照去れる行数が減ることだったらしい。逆にFORCE INDEXで安定して早くなる理由も納得がいった。こういうのはやはり実装などをみておかないといけないなーと感じたところ。
Ruby on Railsなどは外部キーを作ると自動でインデックスも貼ってくれて、本当に意識せずに全部やってくれるなぁと感心する。
Viewテーブルかサマリーテーブルか
複雑なSelectクエリの発効が余儀なくされる場合の選択肢として、個人的にはViewを使うことが多いです。理由としてはやはり変更に強いこと。
サマリーテーブルはトリガーのタイミングなどを含め、実装が非常に複雑になる場合が多かったり、いざ即時のデータが欲しくなると時間がかかったりと痛い目を見たことが多いというのもあります。
Viewテーブルも参照時にクエリが走るなど辛くなってくる段階があるので、「そもそももっと使いやすい形にできないか」を考えてDB設計を考える必要がありますね。この辺はカーディナリティなどの話でも出てきますがデータの偏りなどを予想する必要が多いので「どのような特性のデータか」というところは十分に理解してからDBを設計する必要があるし、腕の見せ所だよなーとなるところ
クラウドやツールの大切さ
バックアップからログ、DBのモニタリングまで本当にクラウドの恩恵を受けていたのだなと感じるクラウド世代でした。
特にDBのチューニングなどは監視ツールを入れることで、スロークエリの順位なども見れるので立ち向かい方が変わってきます。特に、1ユーザーだけ特殊のデータの偏りをしていてインデックスが効いていないなど面白いことが見つかりますし、コンクションプーリングができていないなどの早期発見にもつながります。
本当に監視ツールは偉大。また、どこを監視するかについては監視入門などの書籍に譲ろうと思います。
また、クラウドの利点として「強制的にバージョンを上げさせられる」というものもありますね。19章の塩漬けのバージョンの対策にもなります。強制的にバージョンをあげるので、単なる利点とも言えませんが怠惰を重んじるエンジニアにとって、こういう強制性は重要になってきますね。
フレームワークと実行計画
ここで筆者のツイッターを見てみましょう。
— そーだい@初代ALF (@soudai1025) 2018年5月28日
そう。ORMの作るクエリは人類には厳しすぎるんです。Ruby on Railsの作るクエリなどをみていると「え、何このクエリ。え、でも実行計画はいい感じだな」となることがあります。これは正しく外部キー制約が貼られているおかげでもありますね。
ただ、フレームワークのORMに依存しすぎて、実際のクエリをみない人がそこそこいるのも悲しいことです。どのようなクエリが作られ、どのような実行計画になるのかは常に確認するようにしようね！！！
状態を管理する
アンチパターンの1つだがとても見る。ユーザーテーブルにある権限のカラム、受注テーブルにある受注状況のカラムなど様々な状態を管理するカラムを見てきたし戦ってきた。
特定の状態毎にテーブルを作るのが良いのは本書を読めばよくわかるが、なぜそれをしないのか・思いつかないのかを考えていく。状態ごとによって持つ情報が変わること知らない知識の不足もあるし、単純に実装の容易さもあるだろう。また、論理削除と同様に考えるというのもありそう。何より状態が増えるたびにテーブルが増えるということも問題となるのだと思う。
人間の記憶の特性として、7つ以上のものは記憶や理解が辛くなってくる。そのため、状態毎のテーブルやそれに関係するテーブルが自身の理解できる範囲内に収めようという思考が働くように感じる。命名などで群として捉え易くするなど、人間が情報処理しやすい命名や設計も重要になりそうだ。
他にも
ロックなどいろいろなことが書かれているので是非
MySQLのギャップロックなど、DBによる特殊な挙動など専門書を読むとより詳しく書かれているのでそちらを読むと良さそうです
「問いのデザイン」数多の角度から問題を見るための本
アドカレ14日目〜
改めてエンジニアの本というのは問題をどのようにみるかがよく語られているなーと、様々な本の1節を思い出す本でした。
その分、エンジニアは問題を様々な角度から見る力が非常に重要でそのサポータとしていかに振る舞うかという話にもなっています。
前提についての問い
問いについて考える前に、問いの前提を問い直さなければならない。問いが必要な硬直した場面では、少々強引に視点や視座を変える必要がある。そのために、前提を問い直す必要がある。
この辺りの話はエンジニアリング組織論への招待でも近いことがいわれている。
・「愛のパズル」なので、（感情的に固執していて）解けない・「パズルを抱いて」いるので、（客観視できずに）解けない・「解けないパズル」なので、（前提を変えない）と解けない
前提について考え直すために必要なアクションが対話となる。異なる前提の人と対話することで、自分の前提をリフレーミングすることができる。異なる前提の人とはビジネスメンバーやCSメンバーのように知識が違うメンバー、技術的なことならば別プロジェクトのエンジニアメンバーに聞いてみるのもありだろう。
また、仲間も重要になる。前提を考える問いというのは、これまでやってきたを捨てる可能性が常に出てくる。これはアジャイルでは重要とされるものの、強い精神負荷がかかる。また、前提を変えるともなれば捨てる量も多く、デザイン思考のカオスな状態とも言える。
そのため、仲間と共に、変化の序盤にある痛みを乗り越える必要がある。
認識の固定化の病
自身の認識を固定化させようとする動き。現状維持バイアスの一種のような気がする。これがあると課題の再認識が難しくなる。
一方で、当事者からすれば「わかった(と思っている)こと」を実はわかっていなかったとなるので負担も大きいし、ある程度固定化した上で課題を深掘りするフェーズもあるため、認識の固定化が毒か薬かは結果論に近いと感じている。ただ、認識の固定化という存在を意識できるだけでも十分変わるだろう
ファシリテートは、メンバーがより深く核心へ導くのを深めるのが仕事
ファシリテートの役目は単に司会だけでなく多岐にわたる。書籍には以下が書かれている。
普段とは異なる視点から発想する。対話による学びと創造の方法 故に、非日常性・共同・民主性・実験性が重要になる
そのため、話しやすい場作りやアイスブレイク・話しやすい問いの設定がファシリテートの大切な仕事になってくる。また、成功体験の演出も重要で、先に制約条件をつけて議論をした後、制約条件を外させることでアイデアを広げるなどマッチポンプ的だが「自分たちで考えた・閃いた」という体験がさらに進めようという気持ちにつながってくる。
非日常性はこの書籍では空間デザインとして省かれてはいるが、個人的にはとても重要だと思っている。非日常性とは、普段とは違う場所や違う状態でMTGを行うことを指す。
例えばオフラインならば普段は使わないMTGルームを使う、席の形を変えてみるなどだ。お菓子を準備するのもいいとされているが、日本人の性なのかお菓子に手をつけようとしない人も多いのでジュースなどがいいだろう(本来お菓子を使うのは、食べる＝口を動かすで会話をしやすくするという意図がある)。
一方で、オンラインとなると環境を変えることができないので少し大変になる。使うツールを変えてみると使い勝手に手こずったりもする。そのため、音楽を流す・(顔出しが文化の会社なら)エフェクトを使うといったところから普段とは異なるフレームワークを使うというのもある。フレームワークに関しては、使うことでメンバーにバイアスをかけることにもつながるので何を目的とするかによって慎重に考える必要はある。
最後に：みんなで読むことの勧め
ファシリテートにあたって必要なスキル(説明力・観察力・即興力など)や場のコントロール方法などが語られている。特にスキルやコントロール方法は人によって違うので強みを活かしていくといい。
ありたがたいことに前職で仲のいい人と読んでいたが「〇〇はこのタイプだよねー」という自分でも無意識にしていた振る舞いで自身のファシリの特性に気づくことができた。
5,6章だけでもファシリテートをするメンバーが集まって読むと面白いかもしれない
「単体テストの考え方/使い方」テストをドキュメントにしたい
アドカレ13日目！折り返しですね。日付がずれているのはご愛嬌。
本書は以下の項目を満たす理想のテストコードの書き方を考える本である。そのために様々なテストの手法やテストのしやすいアーキテクチャ、リファクタリングの手法についても記載されている。
- バグを検出できる
- リファクタリングに耐性がある
- 実行速度が速い
- 保守がしやすい
一方で、悲しいかなこれらを全て満たす銀の弾丸は存在せず、様々な天秤についても語られている。
テストにも、プロダクトや組織の特徴を理解する必要性があるのだと感じられる一冊。
テストと設計の関係性
テストが書きやすいコードは密結合ではないコードである。そのため、テストを書くことでプロダクトコードは疎結合にせざるをえなくなる。
実際に本書でもテストコードを書くにはリファクタリングが必要であり、ヘキサゴンアーキテクチャの紹介などもされている。
一方で、これは副産物的なものでしかない。テストを書く=疎結合になる。だけで、設計が完全に良くなるわけではない。とは言いつつも、テストコードを書くことで関心の分離などに思考が向きやすくなるためプロダクトコードの可読性はグッと上がるだろう。
特に、テストを書く時に「出力値ベースのテスト棚」「状態ベースのテストだな」と認識できるだけでプロダクトコードに対しての認識も変わってきそうなところ
AAAパターン
テストコードを以下の3要素に分けて、可読性を向上させる手法です。
- Arrange（準備）
- Act（実行）
- Assert（アサーション）
実際に実装するとこのような形になります。
class UserBooking extends TestCase
{
public function ユーザーが予約する(Booking $bookingDate, bool $expected): void
{
//Arrange
$user = new User(1);
//Act
$actual = $user->cancelBooking($bookingDate);
//Assert
$this->assertSame($expected, $actual);
}
}
可読性だけでなく、Actに該当する要素が複数あるとカプセル化に失敗しているなど、プロダクトコードや設計を見直す機会になるのも魅力。
これを読んだ時真っ先に思い浮かんだのがBDDだ。BDDはTDDから派生したテストパターンの1つで、ユースケースに注目しておりAAAパターンと近くテストコードを以下の3つに分割しています。
BDDは統合テストで使うことが多いとされており、要件やユースケースをテストする際に使い、AAAパターンは単体テストという使い分けになる感じですかね。
- Given：最初の文脈（前提）があって、
- When：イベントが発生した場合、
- then：なんらかのアウトプットを保証する。
テストでは結果のみを確認する
テストの流派には古典派・ロンドン派の2つの派閥があり、ロンドン派はモックを多用する。
このモックが「プロダクトコードの振る舞い」をテストしている場合、振る舞いを変えた時にテストコードがエラーになるようになる。こうなるとリファクタリングで結果は同じでも、プロダクトコードの振る舞いが変わっている場合テストが落ちるようになる。
これは望ましい状態ではなく、モックを使う時は外部サービスの呼び出しなどに留め、テストでは「プロダクトコードの果たした結果」に注目すべきという考え方だ。
テストコードの命名
これについてはAAAパターンやBDDのようにユースケースを日本語で命名するのが良いと思っている。
本書でも近く、面白いと思ったのは「テスト対象や協力者メソッドなどをテストメソッド名に含める」というもの。このような命名をしている時は、モックで振る舞いをテストしようとしている可能性が高いため見直すべきだと言う。
また、英語でShoudを使うなということも言われているが根本的に日本語を使えば問題はない。さて、なぜ日本語化なのだが、日本語の方が理解がしやすい・テストコードくらいエンジニアではないビジネスサイドでも意味がわかる状態であるべきという持論があるからである。
一方で、最近はChatGPTでテストを自動生成をする時は英語のほうが便利という話を聞く。ただ、この場合はカバレッジのみをとった形になるため、そもそもこのようなテストを書くべきではないだろう。
「エンジニアのための見積もり実践入門」見積もりで心理的安全を増やそう
アドカレ12日目！
見積もりだと工数の見積もりなどが出がちですが、こちらは工数だけでなくフリーランスに向けてコストの見積りなど非常に多岐な見積もりが含まれています。また、いい点として合著になっており様々な業種の見積もりを知ることができるのが魅力の1つです。
お気に入り箇所
2点見積もりをする
最低と最大の2つの見積もりをだすことで、最大の場合どのようなタスクや課題が見えやすくなる。2点見積もりにすることで、課題を多角的にみることができる。
そして、早く終わった時はモチベーションの向上につながる。ただ、この方法は使ったことはないのが本音。
なぜ逆に何故1点見積もりがいいのかを考えてみると以下のことが考えられそう。
- 考えることが減る
- 気軽にバッファを詰める
- 1スプリント内でのタスクを詰め込みやすい
どれも「考える」ことを放棄している。特に、全てのタスクが最小で終わった時に何をするか？という動的なタスクの動かしを考えたくないという場合が多い気がする。
安全マージンとは「心理的安全性に対する余裕時間」
よくバッファを取ることの善悪が盛り上がったりしますが、本書では善とされています。
発注者と受注者で分けた時、受注者がバッファを取ることは発注者から見れば「過剰に時間をとって楽をしている」と思われがちですが、心理的にも安全な環境を作ることでミスが減り、時間が余ればテストやリファクタなどをすることで結果的に両者得になるという考え方です。
余った時間でテストやリファクタをするかは、性善説によるところでもあるのですが心理的に安全な環境を作ることでミスを減らすというのは重要だと感じます。ミスだけでなく、要件の抜け漏れの対応などもできるためより質の高い成果は挙げられるでしょう。
「検証済みの手持ちの札をどれだけしていけるか」ということが生命線になります。
見積もりを行う時に、事前に技術をリサーチし使えるようにしておくことを言っています。
私はどちらかというと逆で、必要に応じて学ぶタイプだったので少し考え方が変わるポイントでした。
また、新しい技術を学ぶ時に実務で使えるような明確なアウトプットも出すというのも面白く。ただ調べて終わりではなく、実際に実装して何らかの課題を解決するところまでやることの重要性を改めて感じるところですね。そう言った点からも、新しい技術に対して「この技術は何を解決できるのか」をみていく審美眼も磨かれていきそうです。
設計書の見た目にこだわらない
設計書の見た目やレイアウトは無限にこだわれるのでこだわるなとのこと。
確かにER図やワークフローなど書こうと思えば無限に描くことができますし、設計もどこまでも詳細に書くことができます。この辺りの「どこまでやるのか」は働いてきた会社の色が出るところではあると思います。
個人的にはMarkdownを中心に、必要なら各種図をてきとーに書いて説明しながら質問があったところを追記していく方針をとっています。
説明しながら質問があったら追記というのは、メンバーによって理解度が異なるため「そのメンバーにあった最低限の設計書を作る」というために使っています。
「最低限の設計書だと、後々のドキュメント性が下がらないか？」というところもありますが、この辺は組織文化との兼ね合いで「ドキュメントの維持コストより、コードが設計書となるようにする」という文化だったので上記の手法をとっていました。
他にもアジャイルに見積もり見積の精度を上げる、タスクを小さくして見積もりをしやすくするなど「あるある〜」という話もあるので、見積もりをする機会に目を通すと良い本でした。
「カスタマーサクセス実行戦略」
アドカレ11日目〜
10月に完全版がでいたらしいのですが、読んでいた当時は増補改訂版だったので悪しからず。
著者の方は元エンジニアということでエンジニア畑でも読みやすい作りになっています。なので青本や赤本を読むよりもエンジニアの人はここから読み始めるのがいいかもしれません。特に青本は翻訳の癖が強くインド人の同僚曰く「英語版の方が読みやすい」という感じなので
お気に入り箇所
サービスに対する進化要件を提供者に訴えなくても勝手にそのサービスが進化してくれる
SaaSをユーザーから見たときの特性。買い切りやSI型と違って、勝手に成長していくのは魅力的。SlackやGithubなどはまさしくその恩恵を感じる。
一方で、Twitter(X)など、期待していない方に進化することもあるので顧客がどの方向に進化して欲しいかと感じ取れるかが重要になってくる。
カスタマーサクセスの本質は、問題が発生してからそれに対処する「守り」の姿勢ではなく、そもそも問題を発生させない「攻め」の姿勢
ここは昨日の「おもてなし幻想」に通ずるところの努力させない体験の重要さになってくる。また、自力での解決だけでなく問題を発生させないというプロダクト自体の可用性に関する部分も含まれており、カスタマーサクセスとプロダクト・エンジニアのつながりが重要になってくる。
カスタマーサクセス組織の成熟度とサブスクリプションモデルの利益には明確な相関関係があり、「その利益追求をカスタマーサクセス組織のKPIとすべき」
よくエンジニアの活動はKPIで測りづらいとされている。というのも、エンジニアの作った機能が利益になるのは大概機能を作ってから少し先になったり、そもそも可用性や負荷の軽減などUXの改善と直接的な利益につながらないからだ。
カスタマーサクセス組織のKPIもかなり近い特色がある。単純にカスタマーサービスの質や自己解決できる環境が向上しても、競合のプロダクトが勢力を伸ばし顧客がそちらに流れればKPIが未達になってしまうからだ。
そう考えると、この「カスタマーサクセス組織」というものが単純にカスタマーサクセスだけでなく、プロダクト開発やエンジニアも含めて考えていくべきだろう。
「オンボーディング対象者をいかに効率的に捌くか」がカスタマーサクセス組織を次のステップに進める試金石になる
オンボードの失敗がチャーンにつながることが多いため、オンボードの改善・効率化がカスタマーサクセスとして重要視されることが多い。「オンボードこそがカスタマーサクセスである」という人もいるが、あっていると思う。
自然に使うことのできるUI・自己解決できる環境・いかに早く「出来た」という体験を与えるかという体験設計などオンボーディングにはさまざまな要素があり、もっとも改善ができるところだろう。
SaaSが売れている以上、何かしらの費用対効果が生まれている。それらを明確に認識し、アプローチできるようにしておく。
要するにはプロダクトの価値の明確化と、それを数値化する方法を見つけることである。これができると、企業ごとに点数がつけやすくなり改善のアポも取りやすくなってくる。
逆に点数が高い人はどのように使っているのか、どのくらいの頻度で使っているのかを分析することにも役立ってくる。
プロダクトフィードバックの機構の1つに、四半期に一度、社内のビジネスサイドのメンバーに「リリースしてよかった機能」のアンケートとを取るという施策があります。
これはやってみるととても面白いです。というのも「要望の声が大きい機能」と「小声だがざわついている機能」があり、前者のリリースが重視される傾向があります。一方で、ビジネスメンバーにヒアリングをすると後者の方が「問い合わせが減った」「この機能のおかげで契約が取れた」という声が聞けます。
もちろん、声が大きい機能も重要ですが小声に耳を傾ける必要もあります。なんにしろ、こういった企画は社内でのコミュニケーションにもつながるのでやって損はありません。
使用方法が固定化した利用歴の長い顧客ほど最新情報に鈍感になり、「プロダクト・サービスは進化しているのに多くの顧客はそのことをしらない」という状態が発生します。
これあるんですよね。「こんな機能ありますか？」「最近できました」というユーザーとCSのログを見たことがあります。
鈍感になる原因も色々考えるところがあるでしょう。例えば、作業が完全にテンプレート化されておりパートに任せている場合は、テックタッチで教えてもよっぽどモチベーションのあるパートでない限りテンプレートが改善されることはないでしょう。
一方で、逆に正社員が手癖で作業をしている場合です。これもちょくちょくあり、こちらは手ぐせのミスの防止のために気づくと使ってくれるでしょう。
鈍感から一歩先に進み、何故この人はこの機能を使わないのだろう・誰が使っているのだろうと考えてみるのも面白いところだと思います。
PLGにおけるパーソナライズの必要性
PLGとは、プロダクトレッドグロースの略で顧客がプロダクトの価値を感じて自発的に有償化・クロス、アップセルをしてくれるような状態です。
そのためにUIのパーソナライズが重要とされ、機能の表示のON/OFFやSlackのハドルなど有料ではないと使えない表示などの契約ごとの動きが重要になります。
これらを外部SaaSで行うのも良いですが、できればSwitting Toggleなど自社で開発できると柔軟にできていいですねー
カスタマーサクセスの最終目的はカスタマーサクセスをなくすことだ
カスタマーサクセスのあり方も複数あり、これはカスタマーサクセスがプロダクトに近い場合の理想と書かれています。 カスタマーサクセスがプロダクト近い場合、その役割は顧客からのFBや改善を素早く提案することになります。即ち情報のパイプラインとしての動きになります。
もし、カスタマーサクセスの文化がプロダクトやエンジニアにも広がれば、情報のパイプラインを自分たちが担うようになり生の声を元に改善が行われるようになります。
もちろん、カスタマーサクセスがカスタマーサポートに近い型・カスタマーサクセスが中心にある型もあり何を使うかは会社のフェースによって異なるとされていますが「カスタマーサクセス」という文化はもっと広まれと思っています。
「おもてなし幻想」おもてなしとは、顧客の努力を減らすこと
アドカレ10日目！
- 期待以上のサービスを提供することでロイヤリティは高まる
- カスタマーサポートと顧客のやりとりがロイヤリティが高まる
これらは幻想。
おもてなしなどということはなく、「顧客が楽に解決できるようにする」こととその方法が書かれた本
お気に入り箇所
顧客はただ約束されたものが手に入ればそれでとても満足していることがわかった。だから何か問題が起こったら、それをあっさりと迅速に解決すればいい。
特別なサービスは必要ない。ユーザーは何かの問題を解決するために商品を購入する。その問題が一刻も早くかつ最も簡単に解決されればよいのだ。
「特別なサービス」という幻想があるが、そんなものより問題があったときに迅速に対応してくれた。ソフトウェアのバグの解決が早いという信頼感こそが解約の防止になる。
顧客が求めるものは必要のない山ほどのオプション機能ではなく、顧客が望まない限り会社に電話する必要のない、シンプルで直感的な、問題を解決へと導くセルフサービスエクスペリエンスだ
この辺はUNIXの哲学の「小さいものは美しい」「過度の対話的インターフェースを避けよ」と通ずるものがある。
よくカスタマーサービスでユーザーへの架電数を指標にしてしまうが本当はさらに根本的な「なぜ説明しないと使えないのか」というところを考えていく必要がある。
初回の問い合わせでの解決の先を見越す
顧客が初回問い合わせをする時、必ず次の問題に引っ掛かります。それを回避することを「次の問題回避」と本書では言われています。
「ライトついてますか」の言葉を覚えていますか？「すべての解答は次の問題の出所」です。
問題の解決が次の問題にぶつかる可能性を示唆しているならば、事前にキャッチアップすることでユーザーの連絡頻度を減らすことができる。そのために、ユーザーの問い合わせやマニュアルサイトがあるならどういう動きをしているかを把握する必要がある。
なにより、「次の問題」がわかっているならばUIなどで改善することも考えるべきだ。ただ、利便性のためではなくブランドの向上にもつながることも忘れずに。
顧客のタスクに基づくガイダンス
顧客を導く方法の中で最も良いとされる手法。それがタスク試行なので、イメージとしてはチャットボットがそれに当たる。
ここでも面白いのが昨今で流行りのオブジェクト指向UIとは真逆のところである。オブジェクト指向UIは、それらの知識がある場合は非常に有効に働くが、知識がない場合は「どこになにがあるかわからない」という状況が発生する。
これらの「ユーザーが何を操作すれば解決できるか」を知っているかどうかで理想のUIが変わる。以下の記事は面白い考察になっている。
注意深く選択した言葉遣いで会話をコントロールしてその舵を取り、告げられている内容を顧客がどう解釈するかを改善する
顧客の体験の向上方法である。この本の面白いところだが、ソフトスキルや親切さというものは使わず、技術によって解決していく姿勢が強い。もちろん、その方が型を作りやすいので当然だろう。
アドボカシーや肯定的な言葉を使うなど意図的な言葉遣いで印象を操作するといったことが挙げられている。
私はCSのメンバーと話をすることが多く、前職から仲の良い人もいるがその方達は上記に加えてPCにどの程度知識があるかで使う言葉を切り替えているという。こういったユーザーの言外を汲み取る能力というのは本当に尊敬する。
2つの用語が出ているので軽く解説を、
「CQ」は立ち直りが早く、バーンアウトせず、責任をもて、建設的な批判に肯定的に反応でき、長時間でも集中できる人材のことであり
「AHT」は応答率やそれを図るためのチェックリストなどのことを指す。
即ち、チェックリストや応答時間の記載など業務をなくすことでCQが向上するとされている。これは従業員エクスペリエンスの向上に伴い、CQが向上されることが示唆されている。自分が好きなものでないと売れないのと同じように、従業員体験が良くないのに顧客体験が良くなることはないのだと思う。
