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

ボクココ

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

カスタマーサポートのコスト時代の終わり

スタートアップ

ども、@kimihom です。

カスタマーサポートの話は他で色々しているんだけども、このブログでも書いておきたいと思ったので書いてみる。まずこの話題を書く気になったのは、以下のメルカリ社のニュースを見て喜びを感じたことから始まる。

カスタマーサポートをプラチナ職種に!福岡オフィスの新スタートをお祝いしました

あのメルカリといえば、非常に多くの人が使っているサービスだ。そのサービスの電話サポートとなるとどれだけの電話がかかって来るのかを想像しただけで身震いがする。個人間取引での間でのトラブルなど解決するのが難しい問題もあったりすることだろう。それでもあえて電話サポートを開設するという決心をされたことに拍手したい。

カスタマーサポートはコストなのか?

カスタマーサポートの品質は悪いし対応も遅いから、決まりきったサポートはどんどん自動化していくべきという考え方がある。

だがほとんどの場合、人が FAQ にも書いてあるのに電話をかけて来るのは、「心配だから」なのである。それに対して、自動化してチャットボットが返信したり機械音声での電話応答だった場合に、顧客は問題を解決できたとしても"心配"を拭うことはできない。逆に信頼を損ねてそのサービスを使い続けたいとは思わなくなる可能性もある。他にちゃんと声を聞いてくれるサービスの方が安心できるので他に移ることだってあるだろう。

顧客の"心配"を"安心"に変えるためにはどうしても生の声を聞くサポートが必要だ。これはどんなに時代が進んだって変わることのない事実だ。顧客の安心を提供することを軽視し効率を求める企業は、顧客もその企業を軽視することになるだろう。顧客はその企業を色々な企業のうちの1社くらいにしか思わなくなり、別にその会社じゃなきゃいけない理由なんてものはなくなって愛され続ける企業になることはできない。

それは気軽に入れるファーストフード店と、ひっそりとした佇まいにある歴史ある名店との違いみたいなものだ。ファーストフード店は徹底して効率を求めるので値段は安く提供できるけど、品質や対応もその程度のもので終わる。歴史ある名店はファーストフード店でやっている効率化をあえて手間暇かけることで、訪れた客に感動を与えてまた来てもらえるようなことを徹底して考えている。この両者の違いは日本人が一番知っているはずの"おもてなし" の概念だ。歴史ある名店がお客をもてなすことを"コスト"だと考えるはずがない。おもてなしをコストだと考えるお店は顧客に選び続けられるための手段がない。

ファーストフード店のような効率を徹底して求めたい人もいるだろう。けれどそういうビジネスってのは一気に登り上がった後に、すぐに競合が出てきてやられる運命にある。あのマクドナルドだって効率化を求めすぎて問題を起こした。愛され続ける名店であれば、100年を超えていつまでも人々に必要とされる存在として残り続けることができる。今の世の中に求められているのはそのような企業ではないだろうか。

顧客対応をいつまでケチるのか

営業やマーケティングに人件費や広告を費やすより、カスタマーサポートに優秀な人材を揃えて 顧客に満足してもらえる仕組みを作ってもらうべき時代がやってきている。

評判の悪いサービスを営業しに行ったりマーケティング費用を費やして、一体誰がそれを使うのだろう?今や誰もが製品をググったり、 SNS などを見て簡単に評判を知ることのできる時代になった。にもかかわらず、その評判を左右する既存顧客を大切にしない (カスタマーサポートに力を入れない) 企業が未だに多い。一体いつまでカスタマーサポート担当者を外注したり、何も知らないアルバイトや新入りの素人に任せたりするような体制を取り続けるのだろうか。成長を追い求めすぎる企業は、自社の評判を気にすることなく突き進んでしまい、その過程で起きた悪評が一気にネットで広まり、崩落していくのである。

カスタマーサポートにはほとんどが単純な質問しかこない? だったらその単純な質問が来ないようにサービスやプロダクトそのものを改良し続ければいいだけの話だ。そうするとまた新しい質問や要望がやって来る。改善を繰り返した先に来る今までになかった質問に対して人工知能が対応できるはずなどない。良いプロダクトにし続けている企業のサポートにロボットが入れる隙間などないのだ。

そんな決まりきった質問しかこないような体制なのであれば、改善する気のないプロダクト自身に問題がある。カスタマーサポートは本来、もっと高度で貴重な仕事になっているはずなのだ。

良いカスタマーサポートは新しい顧客を呼び、良い評判を生み、それが営業やマーケティング以上の効果を生むことになる。顧客はいいサービスか悪いサービスかを判断し、感動すれば SNS に投稿するだろう。そんな友人が評価した情報が実は営業やマーケティング以上に魅力的な新しい顧客を呼ぶことにつながるのだ。

終わりに

今回は改めてカスタマーサポートの重要性について語らせていただいた。

カスタマーサポートを会社全体として大切に思う姿勢があるかどうかにかかっている。カスタマーサポート担当者だけが重要性を理解しているだけでは意味がない。

電話やチャット、メール、対面など、あらゆる顧客接点の一つ一つを大切にするような企業が残り続けることになるだろう。

カスタマーサポートのコスト時代は終わりに近づいている。

月額課金サービスをボクはこう設計した

スタートアップ

ども、@kimihom です。

Stripe Meetup というのが渋谷の Tokyo Otaku Mode さんのオフィスで開催された。そこのイベントでサブスクリプション型サービスの設計について話をした。

speakerdeck.com

こちらの内容は、以下の記事の続編的な感じとしてご紹介した次第である。

www.bokukoko.info

以下は補足

プランのプライシングは慎重に

SaaS サービスをいくらで販売するか? 実際に事業を始める上で重要だけど決めることは難しい。見込み顧客に「いくらなら買いますか?」と聞いてみたところ思っていたよりも安めの金額を言われたり、今後のスケールを考えれば安くてもなんとかなると思って、金額を安めに設定しがちだ。だけども、多くの SaaS サービスは料金設定をミスって(なのかは定かではないが)、あとで値上げするという手段を取る傾向があるようだ。

値上げ自体は顧客の同意が得られるのであれば、どうしてもって場合には致し方ない対応かとは思う。でも、できる限りそうならないようにするためにはどうすればよいのだろうか?

私としては SaaS の料金は自信を持った価格設定にしていいと思っている。 ただ、これには条件がある。あなたの作ったサービスが本当に素晴らしいと自信を持って言えるプロダクトである場合にのみ有効だ。他から高すぎない?と言われた時にでも、ちゃんと理由が言える状態であるとも言えるかもしれない。

それで本当に高すぎたって話だったら、値下げはいくらでもできるのだから。

幸いにも私のプロダクトではローンチ後、一度も値上げをしていない。

追加料金を考慮する

単純に月額1,000円ぽっきりのサービスというケースは意外と少ない。例えばライセンスの追加、アドオンの追加、従量課金制の追加、プレミアムサポートの追加など、追加料金の仕様ってのは確実に生まれると考えておいたほうがいい。

その料金を都度請求するような場合には単発決済の API を投げれば済む話ではある。しかし、月末や月初などに一括で決済するような場合は、決済サービスの API に乗っかって実装するには困難が伴うことだろう。

月初や月末などの月のタイミングで一括で決済する方法は割とメジャーな PaaS や IaaS でも採られている方法だ。でもプラン料金以外に複雑に追加/値引料金が絡み合った実装を決済 API のサブスクリプションの仕組みで実現するのは難しいのではないだろか? 頑張って色々調べて サブスクリプションの決済API を呼べば可能かもしれない。でもそれよりも自前で料金を計算して都度 単発の決済 API を投げたほうが柔軟に、そして確実にサブスクリプション型の決済を成功させることができると考えている。これは私の経験上の話なので議論の余地がある。

トライアル期間は必ず用意する

会ったこともない人が作ったサービスを、顧客が一度も試しで使わずにお金を払うだろうか?

誰かと会わないでもサービスが使えるような SaaS の場合、無料トライアルの期間を用意するべきだ。お金を払った後に使ってみてダメだったという場合に、時間もお金も無駄になってしまう。

トライアル期間はサービスによって異なると考えている。 ドキュメント管理や経費精算など、トライアル期間からお金を払った後でも同様のデータをお客さんが使い続けられるのなら、長いほうが(1ヶ月以上)いいとおもう。反対にサポートツールなどはトライアル期間はあくまで内輪で試してみて、有料にしたタイミングで顧客からの問い合わせを受け付けると言った場合には2週間程度で十分かと思う。サポートツールなどは長くしすぎても結論が先送りになるだけになる恐れがあるからだ。

トライアル期間中に “~の使い方をご紹介します” 的なメールを1日1通レベルで送ってくるサービスがあるけど、あれが良いとは個人的に思わない。そもそもそういうメールは読まないし、メールをたくさん送るたびに、顧客は “あのサービスから送られてくるメールはスパムに近い” と思われるようになる。やがて課金情報などの重要なメールですら読まなくなってしまう。メールは本当に大事な時に送る手段と考えるべきで、メールで教えるよりもログインしてくれた後の機能が説明がいらないくらい明快なサービスにすることに注力すべきではないだろうか。

トライアルでどの機能を提供するのかもじっくりと検討したいところだ。トライアル期間で統計データを見せるような機能は本当に必要か?データがほとんどない状態で検索機能を置く必要はあるか?そして今後、顧客が下位プランにアップグレードした際に、上位プランの機能を知る術はあるか?

トライアル期間に上位プランの機能を使ってみてもらうというのは良いアプローチだと考えている。上位プランのメリットを知った上で下位プランに契約すれば、今後どのタイミングでアップグレードすべきかの判断が顧客が一番理解してくれるからだ。それとは反対に、例えば下位プランを使っている状態で、上位プランの機能のリンクや画像だけ表示させておいて、"上位プランにアップグレードすることで使えます" みたいなアラートを出したりするようなサービスもある。それでは、下位プランを使い続けようとしている人にとっては、単なる無駄なリンクでしかなく、ストレスを与えるだけだ。てことで何かしらの工夫が必要になることだろう。

トライアル期間をいかに満足に使ってもらえるかが、今後の顧客獲得に大きな影響を与えることになるだろう。営業やマーケティングよりも、カスタマーサポートが大事だってことが理解いただけたら幸いである。

終わりに

本記事ではよりサービスのスペシフィックな部分に焦点を当ててみた。今回の Stripe Meetup では料金体系周りの情報共有の場として貴重なものだったと思う。それぞれの月額課金サービスでの悩みや思想を聞くことで、「あ、このサービスはこういう思想があるからこういう料金体系にしているのか」だとか「そのサービスだとうちみたいな料金体系は確かに難しいな」などの新たな発見もあった。

今後もこのような場が増えていくと良いと思った。

英語を学ぶ動機を改めて確認する

English

ども、@kimihom です。

定期的にやってくる英語学習のモチベーション。その波がやってきたのでブログに書くとする。

現在の最大の動機は、再来月の Twilio Signal の参加にある。これは毎年サンフランシスコで開催されるわけだけども、このイベント参加を実りあるものにするためには当然英語を正しく聞き取れるようになる必要がある。

ってことで何度目かわからんけど再び英語熱が出てきた。

自分の現状

前職で TOEIC を強引に勉強させてもらったおかげで、全くできないレベルからそれなりにできるレベルにはなった。 全盛期で TOEIC 780 くらいなので今は 730 くらいかな。

地味に頑張っているのが英語のブログ。ちょっとした英語のセンテンスを1年以上毎日欠かさず書き続けている。今日やったことや感じたことを日記として記している。これのおかげで、基本的な英語であればポンポン喋れるようにはなっているはずだ。ただし長く続けられるようにするために、誰かにチェックしてもらったりとかそういうのをしてもらわずに、ただ自分なりの英語を書き殴っているだけなので、文法ミスとかは多くあるだろう。とはいえそういうの気にするより自分の言いたいことを言えるようになるって方が大事だと思っているので、1年以上続いているのはとても良いことだ。

さて、海外のカンファレンスにおいてライティングやスピーキングは自分が登壇するわけではないので、現地で誰かと話す時くらいになってしまう。カンファレンスにおいて大切なのは当然リスニングだ。

TOEIC 780 レベルなので、一般的な受験英語みたいなやつはそれなりに聞き取れるけど、ネイティブになると途端についていけなくなる。あの受験英語とネイティブ英語の大きな隔たり、あれなんなのほんとw そこの高すぎるハードルに私はいつまでも打ちのめされているのである。

英語ができるようになったら

エンジニアとして英語ができるようになったら、当然いいよね。技術の最新情報は常に英語からだ。わざわざ日本語に翻訳される前に、その情報を得ることができる。思った以上にそれはめちゃめちゃ得なことで、例えば今まで超絶面倒だったことが最新技術を使えばパッとできるようになっちゃったりするわけ。そんなことが日常茶飯事なのがこの世界。

今後はグローバルなサービスとの戦いになるのは必至だ。今でも海外のWebサービスやアプリがどんどん日本にやってきて、侵食されてきている。それはそれでいいことなんだけども、私個人としてのエンジニアリングと世界でやりあっていくためには、まずは共通言語である英語をちゃんと身につけなきゃいけない。自分の作ったサービスも世界に目を向けて作っていくことで、世の中に必要とされるサービスとなり続けることができる。

基本的には web 上にあがっている情報を理解する能力である “リーディング” が求められる。これに関しては自分もそれなりに鍛えてきたつもりでいて、技術英語であれば特段困ることはなくなったし、英語の文章でも目をそらさずに読むようにはなった。最悪 Google 翻訳もあるし、問題ない。

でも"読める"ってだけでは最新および未来を知るのは難しく、"聞き取れる"ようにならなることで得られるものだと考えている。読めるってのはつまるところ文章化されたものを読むことになるので、一歩遅れるからだ。例えばカンファレンスでしゃべっていることを聞き取れるようになれれば、最新情報と未来のことまで知ることができる。

あとやっぱり懇親会でどこの国の人かわからない人と喋ってみたいよね。「君はどこからきたんだい?」「Twilio を使ってどんなことをしているのかい?」 そんなトークをしてみたい。 Twilio ってめちゃめちゃ便利なのに、日本では まだまだ盛り上がりに欠ける部分があるので、海外の先端を突っ走る人たちと情報交換をしてみたいと思う。これには相当の勇気がいることだけども、一歩ずつ英語を学んで自信をつけていくしか方法はないだろう。

勉強の模索中…

さて、アメリカに行くまでにまだ時間はある。英語の勉強を頑張っていこう。

去年の Signal のビデオを Youtube で見たり、丸暗記した DUO をシャドーイングしてリスニング力を鍛えたり、音読パッケージトレーニングで基本的な英語をリピーティングしたりしてコツコツ学んでいる。

DUO 3.0

DUO 3.0

ぐんぐん英語力がアップする音読パッケージトレーニング 中級レベル(CD BOOK)

ぐんぐん英語力がアップする音読パッケージトレーニング 中級レベル(CD BOOK)

だけども、なかなかのツラミを感じる次第である。これを2ヶ月続けられる自信は正直ない。どうにかしなければいけないと思っている。

レアジョブとかやってみたけど、あれも成長を感じられず半年と続かなかった。そう考えると今回の勉強もまた Signal が終わったら止まってしまうのだろう。そうなる前に、毎日書き続けている日記のように寝る前にリスニングをするっていう習慣をつけられるような何かを探してみようと思う。

やろうと思っている時にやる。そうしてちょっとずつでも英語ができるようになると信じている。

(続編)

ポッドキャストを勧めてくれたので、面白そうな英語のポッドキャストを登録してみた。寝る前とか電車乗ってる時とかに聞くようにしてみよう。 ググってお勧めってあったのを適当に追加しただけなので、 Rails とか Startup とか その他諸々いいのあれば追加していきたい。

RR Episodes

Giant Robots Smashing Into Other Giant Robots

5by5 | Quit

Bootstrapped Web - The podcast for founders bootstrapping their startups online

開発手法を学ぶことに意味を感じない件について

エンジニア

ども、@kimihom です。

開発手法について議論されたり、発表するような場があったりする。例えば “弊社ではアジャイル開発手法を用いて最先端の開発を実践しています。” 的な話ね。最近はアジャイルじゃなくて何て言うのかよく知らないけども。 それらの話に関してなぜ私が意味を感じないと思うのかを書いていこうと思う。

事前に一つ注意していただきたいのは、私は開発手法に関する話は1,2冊程度しか読んだことがない。だから開発手法を極めればこんなことができるようになる!みたいなのは是非教えて欲しい。開発手法に関する本を読んで、それが全く見えなかったから興味が沸かなかったので。

それより実際に開発しようぜ

基本的にあまり開発をしない方々が、開発手法に関して話しているような感じがする。開発しない立場でチームの開発をとりまとめる立場であるために、何か良い方法を模索している感が漂ってくる。はて開発手法通りにやったところでチームの技術力が上がったり、良いプロダクトができるのだろうか?他のプロジェクトのやり方を真似したり参考にしたところで、本当に自分たちの開発手法とマッチしているのだろうか。

私は技術力のない集団が先端的な開発手法を取り入れれば良いプロダクトができるなんて思わない。反対に技術力のある集団が、開発手法を学ばなくても良いプロダクトは確実にできると思っている。

例えば開発のできない集団がリリースサイクルを細切れにして継続的にデプロイしますってことをしていても意味がない。開発品質もテスト品質も未熟なので、中途半端な機能を継続的にリリースするだけだろう。それだったらじっくり設計をやってレビューもらって開発してってので1ヶ月時間をかけたほうがいいはずだ。テスト駆動開発やってますって話をしたところで、中途半端なエンジニアが適当なテストコードでカバレッジを満たしていればそれでいいのだろうか。優秀なエンジニアがやるからこそそういう開発手法ってのは意味が出るのであって、ただ単に開発手法だけを学んでプログラミングが不得手な集団がやっていたら何の意味もない。無駄にガチガチのコードになって逆に変更に柔軟に対応できない鎖に結ばれたようなシステムになるだろう。プログラミングをたくさんやってたくさん失敗して学んでいかない限り、開発の理想を実現するのは困難だ。

開発できる人ってのはちゃんと設計してプログラミングしてテストしてってのを繰り返して顧客に価値を届けるってことを当たり前のようにやっている。んで、そういう顧客に価値を届ける開発をたくさんやった経験をした人こそが、開発手法で本来目指していると思われる理想的なチームに次第になっていくのではないだろうか。例えば繰り返しデプロイをやってきた経験を通して、そこは自動化できるよねだとか、毎回同じテストを手動でやってたら、ここはテストコード書いてみようだとか勝手になっていくものではないか。開発手法の理論から始めた人では本当にテストコードを書いたほうがいい理由なんて見えてこない。テスト書こうぜ!って言って同意してくれるのは、実際にテスト書くことに意味を感じたことのあるくらいプログラミングと手動テストをたくさんやってきた人のはずなのだ。

つべこべ言わないでまず開発しようぜってのは、開発し続けた先にこそ、自分たちだけの答えがあるのではないかってことが言いたいからである。そして開発手法を勉強する時間があるくらいなら、プログラミング全般を学んだり、そもそも何かを作るてことをした方が圧倒的に大切だと思うのである。

開発の経験こそが、次なる素晴らしいプロダクトを作り上げる条件だ。 私は実際そう信じて続けてきたことでより良いプロダクトを作り上げることができた。だからこの方法は正解だと今では思っている。

チームとしての開発よりも自律的な開発を

チームとしてみんなで1つのを開発していこうぜ的なアプローチって非常に難しい。何かするたびに変更が入って、メンバーと確認してどうするか決めて・・。みたいな流れが発生することだろう。

こんなことになるくらいだったら優秀な1人のエンジニアが開発したほうがよっぽど早くいいものができたと言われるのがこのパターンである。実際1人で開発するってのは本当にスピーディーに良いものが作れる。では大人数で開発するってことで少人数で開発するよりもパワーが生まれるのはどんなときだろうか。

私の一意見に過ぎないけども、自律的な組織こそがそれを可能にすると考えている。つまり、このシステムは1~3人のあなたたちだけでお願いね と完全に分離させるやり方だ。特に web/api/スマホ などで少人数で分担し、最終的に一つのプロダクトを作り上げるような組織がいいんじゃないかと思う。そうすれば一人一人が主体的になってそれぞれが開発に集中できる環境が生まれる。

結局は優秀な少人数で開発すれば OK って話になってしまうんだけど、結局そういうことだと思う。だからこそ、それぞれが優秀なエンジニアになるためにまずはプログラミングをひたすら学び、開発し失敗しよう。やがてチームごとの開発手法ってのは勝手に生まれてくるものなのだから。今回は言いたかったのはそこんところ。

終わりに

今回は開発手法に関するお話が出てくるたびにモヤってたのでそのことについて書いた。

皆さんの意見を聞かせていただければ幸いである。

私が社内勉強会を好む理由

エンジニア

ども、@kimihom です。

うちの会社では、月一で社内勉強会をやっていて、それが個人的に毎回楽しみなイベントになっている。社内勉強会の素晴らしさをちょっと語らせていただきたい。

勉強会のきっかけ

実は私は大学生の頃から勉強会をやっていた。研究室をまたいで自分の勉強した特定の技術に関して情報をシェアし、議論する。そんな場が好きだった。それは自分が一番興味のある内容について熱く語ることが楽しかったし、誰かの発表を聞いてそれに関して話をするのもまた素晴らしいもののだった。

大学生の頃に興味のあった技術の勉強会があって、そこに参加してみたことがきっかけだった。周りは社会人ばかりだったけど、それぞれの体験や思いについて発表している人たちを目の当たりにした。初めての勉強会の参加ですっかり私はその魅力に気づき、大学でも友達を集めてやってみようとなったものだった。

ありがたいことに、私の提案に乗ってくれる人が 4,5 人いた。それだけで十分だった。週に一回、空いてる教室を使って事前に決めたテーマで勉強した内容をみんなに共有する時間を作った。ありがたいことにみんな参加し続けてくれた。主催者のやる気さえあれば勉強会はいつでも続けられる。卒論が忙しくなってしまった頃に勉強会は終わってしまったが、長々と続いた素敵な時間だった。

社会人になっても、自分は定期的に勉強会に参加していた。ただ社会人の参加する勉強会はいつも聞く側に回ってしまって、それはそれでいいんだけどもやっぱり大学の頃のように自分の思いを語る場も必要だと感じた。

今ではいろんな場所に登壇させていただいているけど、新米エンジニアの頃は自信がなくてなかなか手を挙げることができなかった。

そうして今に至る。

社内勉強会

今の会社では毎月サポート勉強会を開催している。社内勉強会ではあるが社外に公開しても問題ない情報なので、外部の方が参加できる枠も少し用意している。サポートツールを提供する立場から、その業界や自分たちのサポートの改善に活かそうってのが主な目的だ。

このような勉強会の場合、社外の参加者が0人でも全く問題ない。社内の自分たちが成長し、仕事の改善に活かすための勉強になれば OKという明確な勉強会の開催の目的があるからだ。

社内勉強会では「失敗したらどうしよう」とか「いいプレゼンにしなきゃ」とかいった余計なプレッシャーがないため、毎回の発表を通じて常に新しいチャレンジを実行できる。それがまた素敵なんだよね。前の勉強会では一発笑いを取ろうとして見事に滑った経験をしたりもした。これはこれで貴重な経験になって、やってよかったと心から思える。

社内勉強会だからこそできることがある。他の外部の勉強会だと各社の方向性や理念など当然違うし、そこで全員が完全に共感してもらうなんてことはできない。でも社内勉強会なら、同じ方向に向かって一緒にビジネスをやっている関係なので思い切って夢や理想を語り合えるのだ。余計な飾りごとをする必要はない、自分の学んだことや考えたことを率直に語れば良いのである。

私の理想の勉強会は、映画「風立ちぬ」で新しい飛行機について語り合っているあのシーン。予告編ではワンシーンだが 2:21 くらいのところだ。 もし興味あれば全編見て欲しい。今日は 3/11 ではあるけども、この映画はそこから復活していくための勇気を与えてくれる。そう思っている。

始めてみよう

勉強会を開催するのってめちゃめちゃ簡単。ただ単に場所と時間と発表者を決めるだけ。

自分が日頃からどんな思いを持っているのか、思い切って話してみよう。それが同僚に伝われば、日常の業務をより気持ちよく仕事できるだろう。チームワークをより強められるし、同じ目標に向かって頑張って行こうって気になれる。社内勉強会にはそんな魅力があるのだ。

もしそれが社外に公開してもいいような内容なら、外部の参加者も受け入れてみよう。そうしたらより発表に身が引き締まっていいものを作ろうって気になれる。経験則ではあるが、社内勉強会でも来てくれる方ってのはかなり熱い思いを持った素敵な方であるケースが多い。

“勉強会を採用の告知のために参加する。” そういう目的ってのは実は本来の勉強会の目的ではない。もちろんそれはそれで目的を達成するのにいい方法なのかもしれない。けれども時には心から勉強会を楽しむ時間を作ってみてもいいのではないだろうか。発表者が目を輝かせて夢を語る。そんな発表を目を輝かせて聞く聴衆。私にとって最高の勉強会はそんな姿だ。

一人一人の “学びたい” という純粋なモチベーションから生まれた勉強会に、私は今後も参加していきたいと思う。

コードを美しく保つためのたった一つの方法

エンジニア

ども、@kimihom です。

とあるイベントでエンジニアの方々と話していて話題になった “クリーンなコード” について書いていくとする。

結論から言うと、コードを書かない のが最も美しく保つための条件だと考える。

サービス設計レベルでの"美しさ" を極めよう

いくら優秀なエンジニアがサービスを作ったところで、優秀でないプロダクトマネージャーの元で開発をしてはいいコードを保つことはできない。優秀でないプロダクトマネージャーは、機能の多さで他社と差別化をしたり部下の仕事を作ろうとする。この機能が他社サービスにはあるから、うちにも取り入れよう。そんな自社サービスの思想を全く考えない機能をエンジニアに要求するのだ。

その時点で、どんな優秀なエンジニアでも作ったシステムは確実に複雑になる。例えて言うなら、小説家が1冊の本の中にうまく章立てをしてまとめていたのに、全く別の話題をその本に書けと言われているようなものだ。そんな要望があれば、どんなに美しかった本を書き続けたライターでも途端に汚い本を作り上げなければならなくなってしまう。

「このサービスはこのためにあります。」そう明言し既存機能を改善できるビジネス側の人間がいない限り、コードを美しく保つことは不可能だ。これがまずとても重要な前提条件。

某メッセンジャーアプリを見てみよう。基本的に全てのユーザーはメッセンジャーアプリをインストールしたなら、"友達と会話をするため" にそのアプリを起動するだろう。なのにそのアプリ内にゲームだとか情報誌だとかニュースだとか、それらがあってもほとんどのユーザーは使わない。ユーザーにとって"そのサービス=メッセージのやり取り" という明確な意識が根付いているためだ。友達と会話するためにアプリを開いたのに、そこにニュースがあったとして、それを見るだろうか。ほとんどのユーザーは"ニュースアプリ"として切り出されたものを使うだろう。なぜならニュースを見たいと思ったときにそのアプリを開くと言う明確なモチベーションが紐づいているからである。

これは大分類の"機能"ではあるが、小さな意味での"機能"にも同等のことが言える。そのお気に入り機能は本当に必要か?その SNS ちっくな機能は本当に必要か? 軸がブレると手当たり次第に機能追加するというやり方が正当化されてしまう。"開発"した分だけサービスが成長させられると思ってしまう。そんな幻想を抱いている方は、Google 検索や Uber が何故あれだけダントツで成功したか理由を考えて欲しい。"機能追加" ってのは仕事をした感が得られるだけの、何も考えていない証拠である。

機能が大規模になればなるほど複雑になるのは必然だ。コードを共通化したりしていくと、ある機能は動いてある機能は動かなくなる。そんな微調整の連続が始まる。それを嫌がってコードの共通化を行わないと、どんどんコードが肥大化していく。Fat なコードがあると、エンジニアは開発するモチベーションを大きく損ねる。一度でも妥協すると、ドミノ倒しのように崩れていくのだ。第三者がそのサービスの開発担当になったときに、リスクを冒したくなくなる。コードを修正するよりも、新しくコードを追加するという選択に 逃げる ことになる。新しく追加したコードであれば、他の依存関係をあまり考えなくて済むからだ。そんな逃げのコードの連続、そして軸のブレた機能開発こそ、最終的に Fat でメンテナンス困難なコードを生むのだ。

全ては機能を追加することが正義だと思い込んでいる人が最初に生み出す悲劇である。だからこそ、サービスの “Why"、そのサービスは何のために存在するのか をちゃんと理解し、志を持ち続けられる人にしか美しいコードを保ち続けることはできない。

これはサービスを作るエンジニアが優秀かどうか以前の話だ。ちゃんと機能が設計されたサービスであれば、勝手に綺麗になっていくものである。何故なら、闇雲に機能を追加するのではなく、同じ機能を改善/洗練していくことになって既存ソースの修正がしょっちゅう入り、より良いコードにするための仕組みが意図せずとも生み出せるためである。

どんなに優秀なエンジニアだって、ひたすら機能追加していくようなサービスをクリーンに保つことなど不可能だ。最初はそんな機能がない前提で設計していたのに、どんどん追加していけばぐちゃぐちゃになって当然だ。

これから何かを作ろうとする人は、まずそのサービスがなんのために存在するのかを明確にし、その理由に沿った機能を磨き続けることだけに集中すればいいのではないかと思う。

既に Fat なサービスを運営している方へ

多くの機能を提供しているサービスを運営しているなら、確実に Fat な状態になっていることだろう。そんな方へ私が言いたいのは、「コードを思い切って消していく人を賞賛する」文化をつくっていって欲しいと思う。Fat なシステムを削除していけるエンジニアは"勇者"だ。自分の責任を背負って懸命にシステムの依存関係を読み解き、いらないコードを消していく。これには半端ない集中力とシステム全体の理解が必要で、新しく機能を作るよりも何十倍,何百倍も難しい。しかもビジネスサイドの人たちからは賞賛されることのない地味な仕事だ。その仕事を進んでやる人こそ、Fat なシステムを担当することになった場合の最高のエンジニアだ。

コードを消していかないと、確実に理想は届かない。コードを消すって文化のない開発組織は、確実に Fat なシステムになって減退する。

コードを消すことを諦めて作り直すって選択もあるかもしれない。しかし、その作り直した先にはまた機能追加っていう逃げの開発をしてしまって、やがてまた Fat なシステムができあがっていく。そんな無駄な時間の繰り返しが発生する。

コードを消すってことに時間を投下することを容認しないような会社にいる場合は、とっとと辞めるべきだ。機能開発ばかりに目を向いているのはサービスの軸がブレブレである証拠だし、素晴らしいシステムを保ち続けることに理解のない会社なのだから。

終わりに

今回は私の思うコードを美しく保つための方法について記した。もちろんこれにはいろんな意見があるかとは思う。あなたのコードを美しく保ち続けるための秘策を教えて欲しい。私もその理想について一緒に考え続けていきたい。

WebRTC の Media, Stream, Track について

twilio JavaScript

ども、@kimihom です。

最近の週末は Twilio Video を使ってビデオ通話アプリケーションを作成している。Twilio Video は今どんどん進化していて、単なる2,3 人でのビデオ通話をするにとどまらず、面白いことができるようになっている。特にスクリーンシェアの機能を Chorme 拡張機能を使うことで Twilio Video でもデスクトップ画面共有のアプリケーションが作れてしまう。ちなみにデスクトップ画面共有のドキュメントは1週間前に出たばかりなので、最新情報だ。

さて、この デスクトップ画面共有の概念を理解しようとすると、途端に WebRTC の Media, Stream, Track というそれぞれわかりづらい概念をそれなりに理解しなければならなくなる。今回は自分なりに勉強して理解したことをまとめようと思う。

Media, Stream, Track

最初に自分が理解した 図を貼り付けよう。少々見づらいかもしれないがこの点は勘弁してほしい。

f:id:cevid_cpp:20170305215612j:plain

今回は、ローカルのメディア、つまり自分のブラウザ環境だけに焦点を当てている。実際は LocalMedia での Track だけでなく、 Remote つまり相手の Track と合い重なってそれぞれのビデオ通話を可能にしている。

さて、まず全体を取り巻くのが Local Media だ。Media には複数の Stream を持つことができる。WebRTC といえばのメソッド getUserMedia で取ってこれるのは、デスクトップカメラとマイクの2つだ。 これらはそれぞれ VideoTrack, AudioTrack がある。てことで、大抵の WebRTC でのビデオ通話では、1つの Stream で 2つの Track を持った状態で相手と通信をすることになるだろう。

そしてその下、getUserScreen と書いたが、これが Chrome の画面共有などのメソッドとして仮に定義したものである。実際は Chrome 標準で作られているものではないので、Chrome 拡張機能 として getUserScreen を実装しなければならない。んで、getUserScreen を呼ぶと、もう一つの Stream が出来上がり、その中に VideoTrack が作られることになる。こんな感じで一つの Local Media に 2つの Stream が存在することも可能だ。

ここまで説明すれば、というより図を見た時点で Media, Stream, Track が理解できてのではないかと思う。ただ実際に Twilio Video のドキュメントを読んでみると、これらが複雑に絡み合ったようにそれぞれがそれぞれの参照を持つようになるので、何が何だかわからなくなる。こういう図を最初に見ておけば、混乱することもないかと思う。

Twilio Video でのサンプルコード

さて、ここまでくれば、Twilio Video のサンプルコードも理解できるだろう。 Twilio Video でのビデオの初期化はこんな感じで実装できる。

    _localMedia = new Twilio.Video.LocalMedia();
    Twilio.Video.getUserMedia().then(function(mediaStream){
      _localMedia.addStream(mediaStream);
      _localMedia.attach('#video-view');
    });

    getUserScreen(['window', 'screen', 'tab'], "your chrome app id").then(function(stream) {
      _localMedia.addStream(stream);
    }).catch(function(error) {
      console.error("Screen Capture is not instaled!");
    });
  }

2つの MediaStream を add して追加し、Media を div 要素に Attach することで その中に Video や Audio 要素が追加されるようになる。

それぞれ LocalMedia を addStream すると、先ほどの図のように Track ができあがるので、Media#event:trackAdded イベントが呼ばれる。これでそれぞれの Track を管理して、例えば停止したりミュートしたりの操作も可能になるだろう。

終わりに

今回は Twilio Video でデスクトップ共有ができるようになったので、 Media, Stream, Track の3つについて勉強し、学んだことをシェアした。もし誤りなどあれば、指摘してくれると私の勉強にもなるので大変嬉しい。

個人的に Twilio はこのビデオ分野が今アツいと思ってるので、今後も追っかけていく次第である。