読者です 読者をやめる 読者になる 読者になる

ボクココ

サービス開発を成功させるまでの歩み

私と会社の目指す方向性について

ども、@kimihom です。

「ボクココ読んでるよ!」と言ってくれると、やはり嬉しいものだね。こうしてまた筆?を進めることができる。さて今回は唐突だけども、私が今どんなことを考えてどんなことを目指しているのかを共有したいと思う。

顧客との良好な関係を継続させる

究極的な質問だが、「御社のサービスを使ってみたいのだが、一度デモを見てみたい」という問い合わせと「いつも使ってる御社のサービスの調子が悪いようだが調べてくれないか」という問い合わせが同時に来た時、あなたはどちらの選択をするだろうか。

私なら迷わず後者を最優先タスクとして取り掛かり、問題の解決に取り掛かる。既存顧客がサービスを愛して使ってくれているというのは、それだけで価値のあることなのだ。そのことだけを考えて全力で仕事に取りかかっている。単に使ってくれるだけのレベルの顧客が多ければ多いほどいいとは思わない。本当に自分のサービスを使う価値のある顧客にサービスを使い続けてくれることが、サービスを提供する私の喜びだと感じている。

いわゆる信頼関係ってやつだ。実際、エンジニアの私でも顧客に何かあった時は電話で対応するし、必要なら現地にまで伺うことだってある。そうやって既存顧客に全力で接すると、やはり顧客はサービスを使い続けてくれるし、信頼してくれる。「誰かに必要とされ続ける」っていうのが、実際めちゃめちゃ嬉しいことだと知ったのは最近のこと。"それがないと困る"ってレベルのサービスを運営すること。一部の人でもそう思ってくれるなら、大小は関係ない。

規模拡大を意識しすぎると、間違いなく先ほどの問いに対して前者を選ぶだろう。それでも、たくさん取った顧客の一部が喜んでくれれば、それで価値があるものという考え方もある。それはそういう考えだから否定するつもりはない。ただ単に私の場合は、自分たちで既存顧客を確実に支え続けられるような体制を整えながらも、着実に成長していくスタイルを好んでいるということに過ぎない。

シンプルを追い求め続ける

シンプルさこそ、ビジネスにおいて大切な要因だと私は考えている。

シンプルなサービスは使っていて気持ちの良いものだし、わかりやすさがある。そして余計な機能がないのでバグは起きにくいし、メンテナンスがしやすいのでアップデートが辛くならない。

シンプルな人員構成であれば、最低限の意思決定で素早く行動できる。それぞれが自分の役割を担って最強メンバーを構築できる。意思疎通がうまくいかなくて間違った行動をとることがない。余計なことに時間を割かれることがない。

シンプルであれば、無駄がなくなる。

よくいう話なんだけども、私はサービス運営において激務を一切していない。自分の開発時間をしっかりとコントロールし、できる限りの範囲で仕事に取り組んでいる。サービス開発も基本的に"~日まで"という概念はないので、自分が満足いかなかったらどれだけでも遅らせるし、早くできれば早くリリースできる。これもシンプルさに通じるものがあると思っている。自分のサービスで必要な機能開発や改善に"フォーカス"することによって、開発に無駄な時間を割く必要がなくなるのだ。これから作る機能は、本当に顧客が満足してくれるものだろうか?一部のお客さんがあったらいいレベルのものではないのか。その程度の機能だったら作らないという選択をした方がいいのだ。

エンジニアが開発の空き時間を作るなんてもったいない、と考える方がいるかもしれない。私は開発と同じくらい、発信することは重要だと思っている。なぜなら、開発している本人が、サービスに対してどんな思いを込めて作っているのかを語れば、それを読んだ顧客は、よりサービスを知った上で使ってもらえるからだ。Apple を見てみてほしい。彼らが CM など莫大な費用をかけて、 "Apple はデザインを極めたプロダクト"というのを発信しているのだ。だからこそ、私たちはApple の思いが伝わり、Apple 信者となっていくのである。私は発信することを、開発することと同じくらい大事な仕事として、取り組んでいる。まぁボクココの執筆は半ば趣味みたいなものだから、仕事しているって感覚はほとんどないのだけども。

ちなみに今までの内容はうちの会社の理念にみんな書いてある。この理念は、私たちメンバーが心の底から思っているミッションである。

次の世代の起業家の夢となる存在になる

私は、ゆくゆくは「誰もが自己資本で自社サービスを運営すること(ブートストラップ経営)が可能である」ということを証明していきたい。きっと今後の起業する人にとって、重要な選択肢の一つになるからだ。従業員やお客さんの幸せにフォーカスを当て、この2者だけがより幸せな道を模索し続ける生き方にも価値があると思っているのだ。私はこのような自己資本で自由に企業を運営したいという考えで起業する人ってのも意外と多いんじゃないかと思ってる。自分の提供するサービスで顧客をシンプルに幸せにしたいという純粋な欲求だ。

自己資本の反対にいるのは、投資を受けて、ずば抜けた成長で自分のビジネスをたくさんの人に使ってビッグになるという目的になるだろう。それ自体は決して否定するつもりもないし間違っていない。ただし、今の若い起業家が、 Web やアプリで起業するなら投資を受けるのが当たり前という偏った考え方しか知らないという点に問題を感じている。もちろん投資を受けるって選択もあるけど、自己資本でやっていく方法もあるんだよということを私が示していきたい。

これには大きな問題がある。 まずは自己資本で成功したというロールモデルが必要なのだ。それがなければ机上の空論で終わってしまう。現状として、日本でブートストラップで成功して、ブートストラップを普及している人が誰もいないということに最大の課題を感じている。だからこそ、まずは私たちがそういう存在になる必要があると考えている。私たちがそのロールモデルとなって、次なる起業家に新しい選択肢を与えたい。こうして Web サービスで起業する方法もあるんだよ、ということを示していきたい。この点に関して最終的に決めるのは起業した本人なんだから、スタートアップになるのかブートストラップになるのかという選択を増やすのは良いことである。

終わりに

ひとまず現時点で思っているのはこんな感じだ。現時点で、私は今の自分の仕事に満足している。これからもこうして働き続けたいという思いを持つことができている。

人の思いってのは簡単に変えられるけど、ずっと変わらない思いにすることもできる。将来のことはわからないけど、私としてはこの思いを今後も持ち続けていきたいな、と感じている次第だ。

登壇履歴と資料

日時 イベント 資料
2016/11/30 第3回スタートアップRails勉強会 Startup Rails で知って追いたい方がいいかもしれない 5 つのこと Tech編
2016/09/28 第7回 サポート勉強会 Zendesk マクロ/自動化 徹底解剖
2016/09/27 第一回スタートアップRails勉強会 Startup Rails で知っておいた方がいいかもしれない6つのこと
2016/09/17 SoftLayer Bluemix Community Festa 2016 クラウドを活用した WebRTC コールセンターの最前線
2016/06/30 Twilio の新サービス「Twilio Sync」勉強会 IP メッセージングと Video でサービス作ってる話
2016/08/24 Heroku Meetup #14 ReBorn Heroku にかけた男のロマン
2016/06/28 第4回 サポートUX勉強会 Advanced Slack ~ Slack がもっと好きになる7つの Tips ~
2016/05/26 第3回 サポートUX勉強会 Intercom を使ってみた
2016/04/28 Twilio Video 勉強会 Twilio Video の概要
2016/03/07 第1回 サポートUX勉強会 コールセンターを知る
2016/02/26 Twilio API 勉強会 WebのリアルタイムとIPメッセージング
2016/02/08 Startup Geeks 私の考える Startup Geeks
2015/12/08 Twilio API 勉強会 Vol.28 サーバーレスアーキテクチャで Twilioを安全に運用しよう!
2015/12/04 kintone devCamp 2015 クラウド電話サービス “Twilio” のご紹介
2015/11/21 AWSモバイル/IoTサービス徹底攻略!! ライトニングトーク スタートアップが AWS Lambda を本番導入した理由

私の考えるうまくいくサービスのシンプルな条件

スタートアップ

ども、@kimihom です。

色々なスタートアップ界隈の方と話すと、やっているビジネスについて話を聞くことがよくある。私としては何でも思ったことを素直に言うことが、そのサービスにとって有益であろうと思っているので、悪いこともバンバン言うようにしている。それで最終的に決めるのは実際にサービスをやっているその人本人だからね。

では私が色々な方のビジネスモデルについて聞くときに、「それは微妙じゃね?」とか「それはいい!」ってなる時ってのはどんな条件かってのを挙げようと思う。とてもシンプルな条件だ。

ユーザーはどのくらいの頻度でそこに訪れるか

大抵の BtoC サービスは安価でたくさんのユーザーを抱えるサービスであるはずだ。高級なネットショップで利益率が高いとかでない限り、ネットで最終的にうまくいくにはたくさんのユーザーが訪れてもらう必要がある。

「たくさんのユーザーが」っていう条件で最も大切なのが、1人1人のユーザーがそのサービスを訪れる頻度であると私は考えている。その頻度が高ければ高いほど、ユーザーにとってそのサービスが身近になり、やがて人にも薦めるようになるからだ。月に1回とか年に1回くらいしか訪れる機会のないサービスに愛着を持足せることはなかなか難しい。

ユーザーが"訪れる"ってのが大事で、"使われる"必要はここでは特に大事ではない。その代表例として Airbnb を見てみよう。あれはユーザーとしては使う頻度はそこまで多くはないと思う。せいぜい3か月とかに1回くらいだろう。使われる頻度としてはとても少ない。だが、 Airbnb のあの美しい写真によって、Airbnb 自体は使わなくとも、ユーザーが色々な場所の写真を見に"訪れる"ことを実現しているのだ。そうすると Airbnb で旅行に行く前に写真をたくさん見ることが習慣になり、旅行に行く時は必ず Airbnb を使う、といった決断になってくるのだ。ちなみに Airbnb の写真に対するこだわりはハンパない。設立当初は綺麗な写真を撮るために、社員自らがその場所へ行って、高画質カメラで撮り編集をしていたそうだ。それほどまでに彼らは綺麗な写真を掲載し、ユーザーに訪れてもらうサイトを目指していたのである。

Airbnb に関しては旅行っていう割と単価の高いものを扱っているために、1ユーザーの使う頻度が少なくても問題はない。しかし例えば1回の取引で100円くらいしか手数料が取れないものだったり広告だけのビジネスモデルだと、もっとたくさんの頻度で使われるような工夫をしないといけない。その"もっと"ってのは100万ユーザーが週に何回も訪れるとか、そういうレベルになってしまうのでとても難しいものがある。

ユーザーが訪れる理由が SEO だったり広告だったりするような場合は即刻ビジネスモデルを考え直したほうがいい。その戦略は時代の流れや競合に簡単に影響を受けてしまうからだ。ユーザーがブックマークしてでもそのサイトに再び訪れたい理由を作ることが大事だ。

毎回そのサービスに訪れる理由が理に適っていれば、そのサービスは本当にすごいと思う。でも実際に話を聞いて毎回思うのは、「確かにたまにあれば便利だと思うけど、そんなにしょっちゅう使いたいとは思わないよね。しかもその掲載料や手数料だとユーザー数がいくつになったらうまくいくの?」っていう疑問である。

だから私が何か突っ込む時は BtoC の場合はこれしかない。

継続課金の場合は、続けなければならない理由があるか

最近は継続課金型のビジネスが流行っている。このビジネスをやっているという場合に気になるのが、「なんでそのサービスを使い続けなきゃいけないの?」という問いである。例えばオンライン英会話を例とすると、あれを使い続ける理由ってのは自分のモチベーションにかかっている。だからいつでも止められるので解約率はかなり高くなってしまう。定期購読の米とか野菜も同様の理由で継続が難しい。

私が一番うまいな、と思ったのは Zendesk だ。これはカスタマーサポート用のサービスなんだけど、その中に FAQ を構築できるホームページビルダーみたいなのがある。メイン機能はメール対応を効率化するツールなんだけど、あえて FAQ を構築できる機能を用意しているのだ。ユーザーが "確かに FAQ もカスタマーサポートの一つか"、と思ってこの FAQ 構築機能を利用したとしよう。そうしてどんどんFAQを貯めていくと、もう Zendesk 以外の類似サービスに移ることができなくなってしまうのだ。移るとなったら、今まで書いた FAQ を全部コピーなどして移していかないといけない。そんな面倒なことは誰もしたくない。だから使い続けるしかなくなってしまう。

最近は色々なデータをサービス内で蓄積させることで、その使うことの価値を高めているサービスが多いように思う。これは一番手っ取り早い方法であるので、まずはデータを蓄積することで他に移りにくくなるような価値を提供できるサービスを考えると良いだろう。

ここで一つ注意したいのは、続けなければならない理由を作ってユーザーを抱えた際には、そもそもユーザーに「他に移りたい」と決して思われないような素晴らしいサービスを継続して提供し続ける義務を負ったことを自負しなければならないということだ。だからこそ継続課金型のビジネスをやる場合はしっかりと責任を持ってやってほしいと願っている。

これは BtoB で大事な点だ。

終わりに

私が気にする点は至ってシンプルだけど、まぁそれが難しいってのがある。

懇親会で何かお話しする機会があれば、この2つの条件を満たした素晴らしいビジネスモデルに出会えるといいなと思っている。私は投資家ではないけど、そういう話は好きだし、頑張っている人を応援するのも好きなので機会があればお話できれば幸いだ。

Startup Rails で知っておいた方がいいかもしれない 5 つのこと Tech編

ども、@kimihom です。

今回はこのイベントで発表させていただいた。

第3回スタートアップRails勉強会 - connpass

そのスライドは以下。

以下はいつも通りの補足的なことを書こうと思う。

1, form_for を使おう

form_for。これこそが Rails においてのキーワードであり、Rails のレールに乗る一番の方法だと考えている。その理由はスライド上に書いてあるんだけど、より具体的なところを解説しようと思う。

Routing。これを突き詰めると、 new と edit でかく form_for を同一のものにできる。Rails Guide に載ってるんだけど、ここはほとんどの人は見逃していると思う。

## 新しい記事の作成
# 長いバージョン
form_for(@article, url: articles_path)
# 短いバージョン(レコード識別を利用)
form_for(@article)
 
## 既存の記事の修正
# 長いバージョン
form_for(@article, url: article_path(@article), html: {method: "patch"})
# 短いバージョン
form_for(@article)

いちいち Form用の HTML を書いている時点で、何か設計がうまくいっていないことになる。

Model。 form_for の中で各項目で設定する f.text_field ** といったところ。ここで、もし form_for で指定したオブジェクトに値が入っていれば、デフォルトでその値を入れることができる。こういうのも勝手にやってくれるのは、本当に便利でわざわざ一個ずつフォームの Value に 対応する Model の値を入れていたりしたら、あなたはもう Rails のレールに乗っていない。

I18N 。locales に以下のようにいれれば、検証エラー時にその値を表示してくれる。エラー内容もモデルの Vallidation を入れてあげれば、そのモデルに erros が入っている。この messages 内にそのエラーメッセージを勝手に生成してくれる。とても便利だ。エラーメッセージを自前で表示している時点で、あなたはもう Rails のレールに乗っていない。

  activerecord:
    attributes:
      contact:
        name: 名前
        company: 会社名
        email: メールアドレス
        memo: メモ

Ajaxform_forremote: true をするだけで、Ajax の POST や PUT が実現できる。私たちがしなければならないのは、そのあとの ajax:success などのイベントを定義し、そのコールバック処理を書いてあげればいいだけなのだ。これを、jQuery や他のフレームワークで ajax でやっている時点で、あなたはもう Rails のレールに乗っていない。

ActiveModel

ActiveRecord の上位概念的な形として、 ActiveModel がある。これの使いどきとして、データとして保存はしたくないのだけど、何らかのデータの塊を作りたいって場合に便利だ。例えば Form のパラメータ管理などだ。例えば会員登録のフォームとかは、一気にたくさんの情報を入れるため、テーブルが分かれていて対応するモデルが複数あるときがあるだろう。そんな時はひとまず 会員登録用パラメータとして ActiveModel を定義し、そこで検証内容を諸々定義した上で form_for のオブジェクトに入れる。そうすればたくさんのモデルが関連するフォームのパラメータを綺麗に扱うことが可能だ。

class RegisterParam
  include ActiveModel::Model
  include ActiveModel::Validations::Callbacks

  attr_accessor :name, :company, :email, :email_confirm, :tel 

  before_validation :set_default

  validates :name, presence: true, length: {maximum: 255}
  validates ....

  def user_param
    {name: self.name}
  end

  def company_param
    {name: self.company, tel: self.tel}
  end

こんな感じで ActiveModel 内にメソッドを定義してあげれば、検証が通った後にそれぞれの ActiveRecord オブジェクトに渡して作成すれば良いのだ。そうすれば、複雑なフォームでも Rails のレールに乗ることができる。

ActiveModel に関しての記事はこちら。

www.bokukoko.info

ActiveRecrod のスコープ

これに関しては割と資料どおりかな。ともかく controller を肥大化させないために、そしてより美しくレールに乗るために、カスタムスコープを定義しよう。

特に Where 系や Order 系は、他のコントローラ内でも呼び出すことが多く、その度に定義するのは大変だ。かといって一つ一つの ActiveReocrd の Select 系の処理を Model 内に書いてしまえば、どんどん Model が肥大化してしまう。

まるでパズルのように カスタム Scope を定義してあげよう。それが美しい Rails コードにつながってくる。

Memory Bloat

Controller から View に渡す時に、 @users みたいな形で @で定義すれば渡すことができる。ただそれに甘えてしまって、何でもかんでも @ でViewに渡してしまうと、その分メモリを消費するので、遅くなるしメモリの消費が激しくなる。

View に渡す @ は必要なものだけ渡すようにしよう。

S3のダイレクトアップロード に関しても、まずは JavaScript の File APIでファイルの内容や容量を検証し、その後に S3 にダイレクトアップロードしよう。ここら辺の記事に関しては、このブログで紹介している。

www.bokukoko.info

効率的で、コードとしても美しいし、サーバーとしても美しいコードを書こう。

N + 1 クエリ

まず検証なんだけど、もう Scout を入れれば容易に発見できる。

Scout や Bullet で見つけた N + 1に対応するために、 ActiveRecord の preload, eager_load を使おうと言うことだ。他にも includes があるけど、これはうまい具合にやってくれるって感じなので、ちゃんと使い分けがわかっていれば preload, eager_load のどちらかを使うべきだと考えている。

ぜひ適切な ActiveRecord のクエリを書くようにしよう。

destroy 系の処理に関しては、対応の id だけを持っておいてバックグラウンドで処理させるか、AWS Lambda などで別で実行させるようにする。こうすれば delete_allが書けて N+1 を解決する削除系の処理を実現できる。

Rails のレールに乗らない選択は悪いことか?

んでここがブログ記事の特別編。Rails のレールに乗らない選択ってのが最近流行ってるけど、それに関して私の思うところがある。

一言で言えば、レールから外れることは全く悪くない。これは、まさにレールなのか砂利道なのかって話である。レールに乗れば遠くまで行けるけど人の敷いたレールまでしかたどり着けない。レールに乗り切った後にレールを外れて、より良い道を模索するってのは Rails を突き詰めていけばきっとあるはずだ。

ではなぜ私があえて今一度 Rails のレールに乗ることが大事だと強調しているのか。私が危惧しているのは、他の企業の事例を聞いて、レールから外れることが当たり前だと考え、本来はレールに乗るべきだった選択を見誤ってしまう初心者・中級者の方が多く見受けられる点があるためだ。Rails のレールに乗らない選択をするからにはそれなりの覚悟がいることなんだけど、そうじゃない雰囲気を最近は感じてしまうのである。

私は Rails のレールに乗って極限まで遠くまで行けた後に、自分だけの小道を切り開いていった方がいいと感じている。遠くまで行く前に自分の道を切り開いてしまうと、そこまでたどり着くことができないからだ。

終わりに

私だけ初心者向け Tip って感じだったけど、参考になった方が一人でもいたようでよかった。でも本来は LT はインスピレーションを与えるって目的が一番正しいような気がしている。その点が今回の個人的な反省点。

より良い発表テーマが見つかれば、また発表したいと思う。

Startup Rails は3回連続で参加しているので、これからも機会があれば参加したい。

サービスの炎上について思うこと

ども、@kimihom です。

最近はサービス運営やマーケティング手法に関する話の炎上が盛り上がり、ネットがちょっと怖い雰囲気になっている感じがする。それに乗っかるつもりは全くないんだけど、こういう機会じゃないと考えるきっかけも生まれないので素直に思ったことを書くとする。

一斉に叩きが入る世界

何か問題が発覚した時に、今や SNS を中心に一斉に日本中から叩かれるようになってきた。それは一つ、世知辛い世の中になったという側面もあるかもしれないが、これは真面目にやっている人にとっては逆にいい傾向なんだとポジティブに捉えている。

問題になるケースってのは、たいてい自分の利益や名声を優先するあまり、他人に迷惑がかかっている。もしくは不平等が生じている。そして当事者がそれを見て見ぬ振りして、継続されている場合に発生するものだと思うのよね。んでそのちょっとした問題の継続がいつしか誰かによって露呈され、記事がバズって問題が世の中に明るみになるってパターンだ。何かしら自分都合のことだけやり続けていれば、いつか終わりが来るのである。

でもちゃんと真面目にやっている企業にとっては何も恐れる必要がないってわけ。ちゃんとやってれば、「あの会社やサービスはしっかりしている。すごい。」という評判がインターネット中を駆け抜け、愛され続けるサービスや企業ってのが生まれるのだ。

日本は、特に批判的な人格だと言われている。それは別に悪いことじゃないと思うんだよね。良いものは良くて悪いものは悪い。みんながそう思ってやり続けていれば、最終的に良いものだけが残り続けていくんだもの。だからこそ日本は100年も続く企業がたくさんあるし、そこで働く人たちは働きがいを感じ、真面目に長くその会社に勤め続けるのだ。そこに 「Why Japanese people!?」 なんて言われたところで、「あなたにはその信頼関係の大事さがわかってないんでしょうね」っていう答えで終わりだ。その批判的な性格が、日本の企業や文化、サービスをより良くさせているってのは一理あると思うのだ。

もちろん今回炎上したような関係者の方も、別に悪気があったわけではないと思う。薄々そう感じながらも、株主からの徹底した利益追求によって生まれてしまった問題なんだと思う。だからそこの社員を批判してはいけないと私は思っている。批判しなければならないのは利益主義の経営方針であり、それを強く求める株主なんじゃないか。

京都の人から聞いた話

京都市って町がある。歴史ある国日本の中でも、最も由緒のある地であることは誰も疑う余地はないだろう。そんな京都に、私は憧れていた。貴重な文化に触れて、その中で最先端を追いかけるような生活をしてみたいと密かに考えていた。(実は今もかすかに思っている)

そんな折に京都に住んでいた方に聞いたところによると、「あそこはよそのものが住む場所じゃないよ。本当に気難しい人たちばかりだから」と、みんな口を揃えて言うのだ。京都に住むことに憧れている私もそう言われるとちょっと引いてしまった。憧れは憧れのままのほうがいいのかなぁ、と思ってしまったものだ。

これって悪いことなのだろうか?もっとよそ者に優しくするような人たちが増えるべきなのだろうか?私はそうは思わない。 京都のよそ者ではなく、そこに住み続けている人たちをいちばん大切にする文化があるからこそ、京都ってのが今も歴史ある由緒ある地として残り続けているのではないか。そんなことを思ったのだ。

日本人は批判的な人格だからこそ、悪いものは淘汰され、良いものだけが愛され残り続ける。それこそが日本人って感じがするし、その究極が京都に住む方々なんじゃないかな。改めて思うと、京都に住む人たちってすげーなって思う。

んで、これってサービスに通じるものがあるような気がするのよね。

Web でも良いものだけが残り続ける世界を

話を戻そう。今回の話でも、ちょっと周りの人が違和感を感じていたものが明るみになったことで、また一つ日本の Web が明るくなったのではないか。そうして陰で頑張り続けてきた他のサービスが称賛されるような土台が整い始めた。みんなからの批判も受けないような真面目で素敵なサービスであれば、きっとたくさんの人に読まれたり使われたりする Web サイトが頭角を現し、残り続けるだろう。

私はそんな愛され続ける Web サービスって素敵だな、と思う。アメリカンドリームのような一発逆転ホームランではなく、日本の真面目で勤勉で、素直なサービスが残り続ける文化を Web でも再現できたらと、密かに考えている。

そう、これこそが Japanese People だ!

Slack の美しさから学ぶ地味な改善の重要性

スタートアップ

ども、@kimihom です。

f:id:cevid_cpp:20161127224436p:plain

皆さんは Slack を使っているだろうか?使ったことがない方は、試しに使ってみてほしい。Web の世界における、洗練された美しさというのを感じ取ることができる。世界中の人々を魅了する Slack。チャットツールってだけなら他にもたくさんあるのに、なぜこのサービスはここまで凄いのか。私自身、チャットツールをちょろっと作っている立場から、UI 的な視点でその凄さについて例をあげたいと思う。

Slack の徹底したこだわりは、なんとなくの使い心地としてだけ人の心に刺さり、それが愛されてやまないサービスにさせている。地味な改善が究極まで研ぎ澄まされているように感じられる。

徹底した無駄の排除

Slack のキャッチコピーは "Be less busy " だ。煩雑なことをやめて忙しさから解放されるような徹底っぷりが UI の機能まで落とし込めている。例えば人の発言のところ。1行ずつ Enter を押してメッセージ送信をしている。

f:id:cevid_cpp:20161127224905p:plain

本来なら、メッセージの時間ごとに日時が表示されるはずだ。この写真で言えば、それぞれ1行ずつ Enter キーを押しているので、 10:48pm と発言者のアイコンがそれぞれに表示されるはずである。しかし、当然そのような重複を Slack が許すわけもなく、2つ目以降は簡素化された表示となっている。

これ、実際に実装するとなると、2つ目以降のメッセージの日時を非表示だけで済む話じゃね?って思われるかもしれない。しかし、1つ目だけ名前やアイコンが表示されているので、2つ目以降の行間などの空白の調整が明らかに変わってくる。Slack のリアクションがなぜ文から少し浮いているのか。それは、アイコン表示のある1つ目のメッセージでも省略された2つ目以降のメッセージでも、共に元のメッセージに被らないようにするためだ。名前の右奥にそのままボタンを埋め込んでしまえば、2つ目以降のメッセージは文にかぶってしまうか、無駄にスペースができて行間が整わなくなってしまうのである。

f:id:cevid_cpp:20161127225139p:plain

2つ目以降の日時に関しても、マウスオーバーで美しく整理されているのがわかる。

f:id:cevid_cpp:20161127225341p:plain

このような綺麗な収まり具合が人々にとって「使っていて気持ち良い」という感覚レベルの感動を覚えさせるのだ。

日時の表示

Slack の日時の表記も徹底した無駄の排除が行われている。以下の動画をご覧いただきたい。

メッセージは基本的に日時は同じものの塊であるから、メッセージごとに日時の表示をするなんてことは無駄につながる。 Slack はここにも徹底したこだわりで、上部に固定してスクロールしてもそれより下のメッセージがいつのメッセージだかを把握できるようにしている。

このアニメーションでの日時の切り替えのこだわりも感じる。こういう UI は実際に同じことを実装しようとしてもなかなか苦戦する。この徹底っぷりはさすがの一言だ。

美しくあり続ける

最初は美しかったのに、どんどん機能が追加されて汚くなってしまったプロダクトってのが後を絶たない。Slack もたくさん機能があるのにもか関わらず、未だに「シンプル」であるということが言割れ続けている。なぜ Slack はここまで美しさをキープできているのか。

ユーザーの90%は最低限の基本機能しか使わない。だからこそ、その基本機能だけをその画面に止めさせておいて、あとは Slack コマンドや Bot 、 API といったところで熟練者向けに隠し機能的な感じで提供しているのだ。これは、奥を知っていきたい開発者をワクワクさせてくれる。まるで宝探しのような気持ちだ。そういうワクワクを感じる人にだけそのような機能も提供しているというのが、非開発者向けに説明するにはちょうどいいかもしれない。

また、アイコンだけのUIに関しては、マウスオーバーをすれば必ず補足の説明が表示される。この表示タイミングのアニメーションも心地よいレベルで最適化されていると感じる。だからこそ初めて触った人でも、後から触った人でも、常に使いやすいをキープできているのだ。

個人的な所感

私は "AI" に代表されるような大々的な新機能よりも、このようなユーザーにストレスを与えない徹底した UI を極めつけたプロダクトを評価したい。この地味すぎる KAIZEN は、いつかユーザーに目に見えない感動を与えられるようになる。

病みつきになるようなサービスってのは、投資家受けするビッグで大胆なことをするよりも、目の前のことを究極まで考え使いやすさを徹底したプロダクトである。日本の車がそうであったように、私たち日本 Web エンジニアも、このような KAIZEN を目指してみてはいかがだろうか。

そんなサービスが増えていけば、日本からも Slack 並みに成功する企業が出てくると思うのである。

言葉は人を傷つけるけども。

雑談

ども、@kimihom です。

今回はちょいとポエムっぽい話。

f:id:cevid_cpp:20161125095540j:plain

言いたいことを言えるか

上司との会話や友人との会話の何気ない一言でお互いの関係を壊してしまうことってのがある。だから上司や友人に嫌われないように、自分の意見は抑えて、相手に同調した方が失敗しないと思われる方は多いかもしれない。こうやって文にしなくても、無意識のうちにそのような"性格"になっていたってのはよくある話だ。

でもより良い関係を作りたいのであれば、悪いことでもお互いが言い合えるような関係を目指すべきだと思う。人の考えなんて 100% 同じなんてのはありえないんだから、「あの人はこう思ってるけど、自分はこう思っている。」というように、多様性を共用できる人になれたらいいなと思っている。

私は圧倒的に自分の思ったことを率直に話す。それがどんなに上司でも年が離れていても関係ない。何度か喧嘩をしたこともある。そんでそれ以降一切口を聞かないなんてこともあった。でも、本当に素敵な人なら、喧嘩した後でもちゃんと他の話ができるし、意見が同じだった時には喜びも感じられる時もある。むしろ、普段は意見が違ってケンカばかりするけど、たまに意見が一致した時の喜びってのもあるね。その反動がむしろ感動するっていうか。とにかく、「自分の意見をしっかりと持っている人」ってのは私にとって魅力を感じる人の特徴である。

もちろん、私のような"扱いにくいタイプ"ってのは馬が合わない人が多い。私自身は別にそれはそれでいいと思っている。一番大事にしたい価値観を共有できる人と一緒に行動すればいいだけの話だからね。そんなこんなで今までもやってきているし、素直に言うことが間違っているとは決して思わない。何でも素直に話せる人達と一緒にいると、愚痴を語るなんてことは100%起きない。自分がやろうとしていることや、信じていることを話せる関係ってのはとても楽しくて希望が持てる。私はそういうことをしゃべれる人が素敵だなと思うね。

ブログの魅力

私はブログは自分の意見を発信する場として利用している。ブログってのは便利なもんで、誰から言われなくても自分で好き勝手にしゃべることのできる場だ。自分の意見をひたすら書いていくことができる。

基本的に私のブログのネタは、リアルで起きたことに対して後で思いだしたことから生まれることが多い。素直な感情をブログでは表現できる。最近は友人や同僚もたまにブログを読んでるよ、と言ってくれることがある。たまに叱責してくれることもあるから嬉しいものだね。たまに言いすぎて炎上することもあるけど、それはそれで Web の魅力としてポジティブに捉えようと考えている。

当然、私の意見だから読んでいる友人や同僚と意見が違うことだってある。でも、私はそれでも発信を続けて、私がどう思っているのかを記事にすることは価値あることだと思う。時には読者の方と全く意見が一致しないこともあるし、結果的には同じことじゃね?ってこともある。それでいいのだ。

私の記事を読んだ時に、「自分はこう思うけどな」って感情を持ってもらえたら嬉しい。別に私の意見を全員に同調してもらおうとなんて思っていないのだからね。

終わりに

言葉は人を傷つける。まさにその通りで私はたぶんいろいろな人を傷つけてきただろう。でも、言わないと自分の殻に閉じこもるようになり、ストレスを抱えるようになるし、何よりお互い本音で語れないと時間の無駄ってのがある。

正直にお互いが話せるような関係をこれからも築いていきたい。