おさらい
製品哲学のない製品と「緩やかに死んでいくシステム」を考える - Qiita
愛される製品の、製品哲学をまなぶ - Qiita
製品哲学の言語化にいどむ。「カタログ」概論 - Qiita
もちろん製品もいつか死ぬ、沈むものかもしれないと考えます。とはいえ長く続くものに理由はあるとも思います。
以上を考えたところで、愛される製品は製品哲学に「カスタマーサクセス」が組み込まれているのではという説（仮説） についてです。
「カスタマーサクセスとは何か」
カスタマーサクセスは「農耕（ファーミング）」
「カスタマーサクセスとは何か 日本企業にこそ必要な『これからの顧客との付き合い方』」 という本があります。非エンジニアと勉強会したりする際にも有用でした。本から要点をピックアップすると以下です。
アマゾンにとって利用者が「アマゾンなしでは生活できない！」と思うほど無くてはならない存在になること、それが究極の目的。
「カスタマーオブセッション」
利用者がそれなしでは生きていけない域にまでなること
モノの所有→成果志向へ
利用成果中心の価値観へ
いつでもやめられる、いつでも最新
利用者は利用者自身のデータを引き渡せる。見知らぬ人と繋がってコミュニティができる。
データ侵略、継続的働きかけの日常化
利用者の成長や、境遇の変化、心境の変化などにも柔軟なのがサブスク型やSaaS。
利用者の成長や、境遇の変化、心境の変化に提供者も付き合っていくということ。なるほど開発者も同じマインドで、ユーザーの変化を意識して付き合っていけるようにしないといけない
Appleは変わっていく、秀丸エディタは変わらない。しかしいずれも愛される。
変わる変わらないが問題なのではなく、そのユーザーに対して製品としてどうお付き合いしていくか。
ユーザーの目的を、製品に組み込んでどう達成するか。
カスタマーサクセスとはそういうことなのかなと考えます。
イソップ物語
イソップにはこんな話があります。狐と鶴のご馳走 - Wikipedia
意地悪好きのキツネがツルに「ご馳走するからいらっしゃい」と招待し、やって来た鶴にわざと_平たい皿_に入れたスープを差し出す。鶴はクチバシが長いため飲めない。それを見ながら狐はおいしそうにスープを飲む。
しばらく後、鶴は狐に「先日はご馳走をありがとう、今度は私がご馳走するからいらっしゃい」と言って、訪れた狐に_細長い口の壷_に入れた肉を差し出す。狐はクチバシがないのでそれを食べられない。それを見ながら鶴はおいしそうにクチバシで中の肉をつまんで食べる。
- キツネは浅いお皿で料理を食べたい
- ツルは深い瓶で料理を食べたい
キツネとツル、両方の要件を満たすにはどうしたら良いだろう。どう考えられるでしょうか。
とある製品は、キツネ向けのフラグを立てる、あるいは、ツル向けのフラグを立てる、いずれかを選択させる設定画面を用意してきたようです。
ツルはツル向けの機能だけ使えれば良い、キツネはキツネ向けの機能だけ使えれば良いはずです。
ツルにキツネ向けの皿を出したら怒られるし、キツネにツル向けの皿を出したら怒られます。
考えてみると、実は他にも、おサルやキリンやゾウやお魚などという、お客様がいます。
とある解決策のなかには、ツル、キツネ、おサルやキリンやゾウやお魚向けの機能全部を網羅して「フィーチャーフラグ」で切り替えられるようにする、というものもありそうです...。
しかし難しいのはカエルさんから、トカゲ向けの機能にちょっと機能要望リクエストを貰ったとき。開発者もその要望をきいて良いのか断ったほうが良いのかもはや、わからなくなってしまう。
全部に答えようとしてしまえば、工数があふれてしまいます。ドメインエキスパートは誰なんだという状況でもあるし、取捨選択、モデリングのむずかしさというやつなのかもしれない、言うは易く行うは難し...。
三河屋さん
話を「カスタマーサクセスとは何か 日本企業にこそ必要な『これからの顧客との付き合い方』」 に戻すと、カスタマーサクセスとは。
サザエさんにでてくる三河屋の三平さん、分かりますか？彼がしていたことの現代版ですよ
そんな一節が出てきました。衝撃です。
カスタマーサクセスは「御用聞き」でも「ルート営業」でもない。しかしその本質には共通点がある。その共通点と相違点はカスタマーサクセスの本質に関わる。
カスタマーサクセスは「農耕（ファーミング）」であって「狩猟（ハンティング） 」ではない。
買ってくれたという事実と具体的な人格や利用歴が存在する「うちのプロダクトを使っている××さん」であり、使い続けてほしい人という想いを込めて使う。
カスタマーを虜（ファン）にし、「この素晴らしさを広めたい！」という理屈を超えた愛着感情に基づく行動（口コミや紹介など）を引き出す。
成功 ＝ カスタマーの事業へ実際にもたらされた成果・業績（生活者の場合は「生活上の成果」）。「成功」はプロダクトが利用し尽くされているという事実でも、プロダクトがもたらす直接的な結果でもない。「成功」はカスタマーの事業が成長する（ないし生活がより良くなる）ことに直結する現実の成果。 成功を届けられない相手には売らない覚悟と仕組みをもつ。
開発者がカスタマーである状況に置き換えて想像するならば、開発者採用活動と共通しているかもしれません。チームに合わない人を採用しない。採用過程よりも、むしろ加入してからが大事である。オンボーディングで「ワオ！」を素早く届ける。会社なんて一生居るものじゃなく、いくらでも乗り換えていいと考えたらいいわけです。エンプロイーサクセスなどという言葉も聞きます。
対象に成功を届けるということ。そう考えるとわかりやすいのではないでしょうか。参考: ITエンジニア採用入門
もちろん「SaaS」は簡単ではない
Apple to discontinue the iPod after 21 years - BBC News
iPod終了のお知らせ。音楽は溜め込むものじゃなく、ストリーミングになったということから、役割を終えたのだろうというのと同様、ソフトウェアもクラウドな時代なことを考えるとしみじみします。
- 自社パッケージ販売からサブスクリプション型サービス展開する際に考えるべきこと（随時更新） - Qiita
- SaaS 向け SLA ガイドライン 経済産業省
- クラウド アプリケーションのベスト プラクティス - Azure Architecture Center | Microsoft Docs
- 知られざる「マルチテナントアーキテクチャ」（1）～SaaSはみんな同じではない？ － Publickey
- SaaSビジネスは儲かるのか？ SaaSの基礎と仕組み- Baremetrics Japan
- SaaS スタートアップ創業者向けガイド | セールスフォース・ジャパン
達人プログラマー(第2版): 熟達に向けたあなたの旅 にはこんな事が書かれています。
- 自ら欲しているものを正確に認識している人などいない
- プログラマーの仕事は、人々自身が欲しているものを気づいてもらえるように支援すること
- 要求はフィードバックループの中で学んでいくものである
- ユーザーとともに働き、ユーザーのように考える
- 枠にとらわれずに考えるのではなく、枠を見つけ出す
- ともに働く
そしてこの記事:
非マネジメントのパッケージエンジニアが考える製品の設計思想について - Qiita
エンジニアとして、
- 顧客の価値を創造する
- 価値創造の速度を高速にする
- 時代の変化に柔軟に対応する
これらを意識し続けることでただの保守開発業務ではなく価値あるエンジニアとしての業務に変わっていくと考えている。
設計思想という面で
- コードは重要だが、コードだけではだめ
- プロセスは重要だが、プロセスをこなすことが重要なわけではない
- 複雑な機能群で難解な仕様は10年前はウケたが、今はウケない
まとめ
三河屋さんになることは簡単ではない。
大事なのはその機能の説明のし直しを長いお付き合いの中でしていくこと。
愛される製品は製品哲学に「カスタマーサクセス」が組み込まれているのでは説
ではないだろうか、とおもいました。
製品哲学のない製品と「緩やかに死んでいくシステム」を考える - Qiita
愛される製品の、製品哲学をまなぶ - Qiita
製品哲学の言語化にいどむ。「カタログ」概論 - Qiita
製品哲学を言語化していきたい...
つづく。