ボクココ

個人開発に関するテックブログ

仕事で描いている未来について

ども、@kimihom です。

f:id:cevid_cpp:20190416213440j:plain

最近、未来について考える機会が減ってきたってこともあるため、今回は改めて未来について今まで考えてきたこと、そしてこれから実現しようとしていることについて記す。

コミュニケーションの未来を当たり前にする

私が仕事で一貫してやってきたのが、ビジネスにおけるコミュニケーションだ。時代がどんだけ進化しようとも、コミュニケーションがなければ何も始まらない。だからこそ、このコミュニケーションをいかに改善してより次世代の、未来の当たり前を作れるかにチャレンジしている。

1. 電話

コミュニケーションのうち、電話に一つフォーカスを当てている。今時 "電話" と思われるかもしれないが、これだけ LINE が発展してもほとんどの人は個別の電話番号を持っているし、家庭の電話番号や会社の電話番号もあるのが基本である。最近、電話番号を持たないというケースも出てきてはいるが、電話番号自体をなくすという決断が正解だとは思わない。他のほとんどの人が電話番号を持っている中で外すという選択肢になってしまうからだ。これは、LINE をみんな使っているのに自分だけLINEを使わないというのと同じだ。

なぜ電話番号を持たないという選択をするのか?それは、既存の電話機やビジネスフォンが進化しておらず、わざわざそれを用意しなければならないという先入観があるからだと考えている。また、電話は営業電話ばっかりだったり、リアルタイムの会話であるためそれに時間を合わせる必要があるという点もあるだろう。

だがとりわけ顧客を抱える企業が、電話窓口を持たないということは電話をかけたい顧客との通信を遮断することにつながる。最終的に他の手段で連絡するという選択を顧客に強いることになる。それがいい選択だとは思わない。私は電話のデメリットを挙げて使わないという選択をするのではなく、電話そのものを改善して顧客のために電話を使うことを選んだ。

電話機やビジネスフォンをわざわざ買ったりせずとも、気軽に電話ができるようなシステムがあれば解決できると信じている。その電話は、インターネット回線と PCさえあればどこでも電話でき、しかも今まで以上にチャットやメールと密に融合するものだ。

私はそんな理想の電話システムを構築するべく、毎日開発を続けている。電話をなくすのが当たり前ではなく、発達した電話を使うのが当たり前になる未来を作り上げようとしているのだ。現在、既に多くの企業がその利便性に気づき使い続けてくれている。そうした企業を増やして次なる電話を当たり前にしていく。それが「コミュニケーションの未来を当たり前にすること」につながってくる。

2. セミナー

顧客は東京にいるとは限らない。インターネットが発達した今、日本全国に顧客を持つことが当たり前になってきている。そんな中、昔と同じように一社一社会いにいくなんてことは到底できない。

セミナーも同じだ。日本全国にいるから、わざわざ日本全国でセミナーを開かねばならなくなる。そんな非効率が、今は当たり前な行為として広がっている。

私はこの状況を変えるべく、ウェビナーのためのプラットフォームを開発している。どこか1つの拠点から配信した動画を、リアルタイムで日本・世界のどこからでも視聴できて質問が簡単にできる構造だ。これは配信側の移動コストだけでなく、視聴者側にも当然同じメリットを得ることができる。

とりわけ日本では東京に集中して企業が存在するってことで、このウェビナーがまだ一般的になっていない。だけどゆくゆくは日本全国を動き回ることの手間やコストと、リモートで配信することの手軽さを比較した時、後者を選ぶ企業が増えてくると信じている。

なぜ今現在、ここまでウェビナーが広まっていないのか。それは実際にウェビナーをやり始めている企業がまだ少ないことに起因しているだろう。だからこそ、まず私たちがウェビナーを通じて成果を出す必要がある。そして、その成果は着々と出つつある。

既にもう10回はウェビナーをやっていて、必ず参加してくれる方がいるしチャットで積極的に質問をしてくれる。だから今後、ウェビナーが当たり前になってくるという確信があるし、私がその未来を作り上げようとしている。それが「コミュニケーションの未来を当たり前にすること」につながってくる。

終わりに

過去や今じゃなくて、いかに未来について考えられるか。それがビジネスを、人生をワクワクしながら生きることの秘訣だと考えている。

誰かが作った未来の流れに従って今だけを見て生きる。そういう生き方もあるだろう。それとは反対に自分が次なる未来を作り上げる。どちらかと言えば私は後者の生き方を続けていきたい。

とりわけ "コミュニケーション" は引き続き私の大きなテーマとなるだろう。もし未来のコミュニケーションに興味がある場合には、私と共に歩んでいこうじゃないか。

サービス開発における倦怠期を乗り越える

ども、@kimihom です。

f:id:cevid_cpp:20190209180447j:plain

サービス開発をして、ユーザーが増えてきて運用を続けていると必ず訪れるのが倦怠期。最初のイカした刺激のある新機能開発はほとんどなくなって、ありきたりの開発タスクばかり降ってくる時期だ。このフェーズになると「自分の成長が~」といって辞めるエンジニアが後を絶たない。本記事で私がどのようにこの倦怠期を乗り越えようとしているのかについて記すとする。

技術を使うだけを目標にしない

例えば最近流行りの技術を使ったとして、それだけで満足するとすぐにモチベーションの終わりを迎える。技術者としては「その技術がどんな特徴でどう実現するか」ってのを把握できれば、ほぼ技術を身につけたと言える状態になる。自分のスキルやキャリアのプラスにしたいっていう気持ちは満たされることになる。これは、入門書+ちょっと踏み込んだ本を読んで、それが使えそうな小さなシステムを作ったら終わりである。

この状態で倦怠期を迎えると、技術を使うことが満たされたので、後の作業は苦痛でしかない。とっとと他の運用できる人に引き繋いで別のチームへ行くなり転職するなりっていう結末を迎えることになる。もちろん、この考え自体は新しい技術を身につけて持ち幅の広いエンジニアになる!って目的ではある意味正しいと言えるのかもしれない。

だが、私はそれは表面的に技術を身につけたとしか言えないと考える。その技術は今後も進化を続けるから、技術の進化に追従しシステムを最新に保ち続けなければならない。新しく作るプロジェクトなら 最新バージョン を使って当たり前だが、その1年後に次のバージョンアップに追従できるか。これは、一見 地味に見える作業ではあるが、その技術をより詳しく使いこなせるようになるために必要である。それによって、同じ技術でも新しいアップデートは何かっていう最新情報に追従できるようになる。ソフトウェアアップデートを常に行うことが、まずサービス開発の倦怠期を乗り越える上で重要である。「私は A の技術に関しては最新に追従してかなり詳しい」という状態になることができる。

そもそもこうしたアップデートを繰り返すレベルにするには、あなたの作ったサービスを成功させる必要がある。ユーザーがいないサービスをメンテしようなんて誰も思わないからね。だから技術を使うだけって目的で成長しようとするエンジニアはユーザーを抱えられないから永遠にその領域に達することはできないだろう。作ったサービスを必ず成功させるという思い、そしてその思いを現実にして技術に携わり続けることでしか辿り着けない領域である。

コミュニティに貢献する

コミュニティへの貢献によって、例え会社で担当者があなた一人だけだったとしてもモチベーションを保ち続けることが可能だ。コミュニティに出向くと、自分よりよっぽど優秀で詳しいエンジニアと出くわすことができる。一つの技術であっても、使い方などは様々であるから、自分より詳しい分野を持っている人ってのはいるものだ。そういった方々との交流を通じて、技術をより高みへ持っていくことが可能だ。

本当にその技術を極めていきたいってならコミュニティの運営まで携わることをオススメしたい。そこまで貢献すると中の方と日常的に連絡のやり取りもできるし、日頃から技術に対しての意見を運営同士で話し合うことが可能だ。その運営協力によって、次なるイカした技術者が現れて、コミュニティ自体が盛り上がっていく。結果的にその技術がより進歩していく。やがてあなたはその技術の第一人者として世間に認められるようになっていくことだろう。

コミュニティ貢献が、最終的にサービス開発に確実に活きてくる。「あのサービスを開発している人って ~~ さんなんだって!技術コミュニティの運営もしているし、積極的に最新情報を発信している。あの人の運営している技術は最新で間違いないだろう」って印象を持ってもらえるように日頃から技術鍛錬を行い続けよう。

もちろん、これを実現するにはとんでもなく長い時間がかかる。ブログに読者がついて多くの人に読まれるようになる状態になる以上に難しい。それでも、その技術に対しての愛着があり、より良くしていきたいってなら乗り越えられる壁のはずである。

効率化を常に考えよ

サービス開発の倦怠期では、雑用タスクがどんどん舞い込んでくる。これらのタスクをいかにして減らしていくかってのも技術の腕の見せ所である。それを単に「はい」っていって作業するだけのエンジニアは二流である。

自分が関わらなくても、誰か or 勝手に作業が終えられる ようなシステム構成を作り上げよう。こうした運用改善に全力を注ぐことも、倦怠期を乗り越えるモチベーションになり得る。それらの開発は基本的にゼロからまた作り上げるようなケースが多いので、モチベーションの一つになりうるだろう。

それは確かに、求めていた最新技術ではないかもしれない。でもその分野での技術ってのも確実にあるわけで、そっちでまた次なる努力ができるのではないだろうか。

終わりに

今回はサービス開発における倦怠期をどうエンジニアが乗り越えるかについて記した。

実を言うと、私もこの倦怠期によってモチベーションを失っていた時期が一時期あった。でも、上記のような行動によって次第にまたモチベーションが戻り、今では以前と同じように積極的に開発に戻れるようにまでなった。 サービス開発の倦怠期を超えた先にしか見えない世界がある。その新しい世界をあなたにも見に来て欲しい。私はここで待っている。

「もえつき」の処方箋―本当は助けてほしいあなたへ

「もえつき」の処方箋―本当は助けてほしいあなたへ

大企業と中小企業におけるサービス開発の違い

ども、@kimihom です。

f:id:cevid_cpp:20190116190636j:plain

巷でサービスのクローズが話題になることが多くなってきた。そして有名企業の新サービスをクローズを持ち出して、サービス開発は誰もが失敗するみたいな論調で失敗を許容しているような風潮がある。

「有名企業で作った似たようなサービスを小さな組織が開発してもどうせ失敗する」って考え方はあるかもしれないけど、小さな組織が開発することで成功するチャンスも大いにあると考えている。今回はそんな組織によるサービス開発の違いについて記してみる。

有名スタートアップがサービスをクローズする理由

サービスクローズの記事を読んで私が感じるのは、「サービスクローズはもちろん正しい判断であるかもしれないけど、今度新しく出てくるサービスもどうせまたすぐクローズするんだろうなという印象をユーザーに少なからず与えてしまうため、これから新しく作るサービスにも悪影響を及ぼす点を考慮していないように見える」という点がある。

どんどん作ってどんどんクローズするのが正しいか正しくないかはさておき、大きな企業が新サービス開発に失敗する理由は割と明確にあるように思う。

最初から高すぎる目標を掲げる

一つ目に「サービス開発に人件費をかけすぎて、成果に見合った金額が大きくなりすぎる」という点がある。

企業に属しながら新サービス開発にチャレンジするとなると、それにかける人件費や初期投資という考え方が出てくる。サービスを開発してみてその時間や人の投資に見合う成果が挙げられなければ、それはクローズするという判断になるか、赤字でも何かしらの利点を見出して続けるという判断になってくる。

大きな会社にかかわらずスタートアップでも 新サービス開発の目的が "急成長して会社を大きくする" みたいな感じになりがちだ。これを目標にすると途端にサービス開発の目標が本来設定すべき目標とズレてくる。誤った目標によってやがてサービス開発に失敗するのだ。

ここでいう サービス開発の成功ってのは、「サービスが存続し続けて顧客に価値を提供し続けられる」という点にフォーカスしている。小さな組織であれば、人数が少なければ少ないだけ見合った報酬を手に入れる可能性が高まるため、サービスを顧客に提供し続けるという見合った目標を叶えやすくなる。

既に成功したブランドを利用しようとする

有名企業が作ったサービスは、「その企業の名前 + サービス名」というところで打ち出すことが多い。でも実際の利用者は成功したメインサービスの印象しかないため、わざわざ今まで使っていたのを替えてまで新しいサービスを使う気にはならない。その企業のブランド=成功したメインサービスってのが中心にあるため、逆に何が何だか訳がわからなくなるデメリットがある。

また、ユーザーはそのブランドの出した新サービスだからという点でサービスローンチ時点から高い期待をすることになる。てなると、高いクオリティが求められるためにサービス開発からローンチまでは必然的に長く時間をかける必要が出てくる。これもまたサービス開発におけるアンチパターンで、失敗の可能性をぐんと押し上げている。

他のどんな規模の会社でも真似できるようなサービスを作る

大きな組織が新しいことをチャレンジする場合には、小さな組織じゃ絶対に真似できないようなことをするってのがセオリーかと思う。例えば AbemaTV や ZOZOスーツみたいなのだ。こういうのは競合がほとんど出てこないので、やる価値はあるだろう。

そんな中、「そんな大きな会社がなんで誰でも作れるようなサービスをローンチするの?」と思うことがよくある。そういうサービスを大きな組織が作ったところで、差別化できるのは最初の初期投資額の大きさくらいしかない。無駄に広告に費やして見合った成果が出ないからクローズするっていうオチが目に見えてわかる。 だったら最初からその分野でうまくいっている企業を買収した方がよっぽど成果に見合ったリターンを得られるのではないだろうか。

小さな組織での可能性

さて、大きな組織が失敗するようなことを挙げた上で、小さな組織でサービス開発を成功させることのできる領域がある点について言及していこう。これはまさに大きな組織がサービス開発で失敗する理由を逆手に取ればいいだけである。

目標を「大量のユーザーに使われるようなサービスを作る」にしないだけで、だいぶ戦略が変わってくる。

ターゲットを絞る

小さな組織だからこそできる&成功の確率を上げられる点として、ターゲットを絞ることができるという点がある。先の説明のように大企業が新サービスを開発するってなると、どうしても大きなリターンを求めてしまうからターゲットを大きくせざるを得なくなる。大企業でも最近はターゲットを絞ってやるってことをし始めているけど、サービスが大きくなったらターゲットを大きくしないと収益をもっと増やせないので必然的にサービスがどんどん変わっていく運命にある。

そこをユーザーのターゲットを絞って、ユーザーに期待を裏切らないサービスを提供し続けられれば、長く存続するサービスを運営することができる。これは大きな会社が決して真似することのできない方法の一つだ。

必要最小限の人数で開発する

また、人数を絞るという点も大事になってくる。人が多ければ多いほど、そのサービスを大きく成功させないと存続させられないリスクが出てくる。サービスに関わる人数を5人以内に収めることができれば、サービスを存続させなければならない最低の収益も小さく収めることができる。 小規模~大規模の色々なサービス開発に携わったことがある方ならわかると思うが、サービス開発で人が多ければ多いほど、圧倒的に無駄な作業が必要になってくる。だから必要最小限で意思決定を素早くするだけでもサービス開発を成功させる可能性を大きくすることができる。

少数のユーザーを愛する

ユーザーが増えてくると、どうしても一人一人のユーザーと接する機会が少なくなってしまう。小さな組織では少ないユーザーでも運営を続けられる状態に持っていけるため、少数の顧客と密接に関わることができる。これは私がよく記すレストランでいうチェーン店なのか老舗店なのかの違いである。

面会 > ビデオ > 電話 > チャット > メール

って感じでユーザーとの接し方の密度が変わってくる。少人数だからこそできるユーザーとの接し方によって長く愛され続けるサービスを実現できるはずだ。

終わりに

サービス開発をする目的ってのも人それぞれあるだろうけど、一番大事なのは「誰かの役に立って残り続ける」ってことなんじゃないかと思う。その本来のシンプルな目的をより達成しやすくさせるために、少人数で開発するのは有効な方法の一つであろう。

サービスクローズしない、ユーザーの期待を裏切らないサービスを作っていこう。

ボクのサービス開発を語ってきた話

ども、@kimihom です。

s-dev talks という"サービス開発"に関するコミュニティのイベントを見つけたので、この機会にサービス開発の振り返りの話をしてきた。

speakerdeck.com

リンク集

Speaker Deck からだとリンクで辿れないみたいなので、それぞれご紹介する。

Web サービスを自力で作る上で大事な考え方 - ボクココ

スタートアップのサービス開発における「スケールしないこと」とは - ボクココ

1人エンジニアでサービスを成長させるために実施したい4つのこと - ボクココ

Web サービスは機能の多さで勝負してはならない - ボクココ

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

アプリの個人開発の終焉と新たな可能性 - ボクココ

Herokuで成功させるサービス開発 - ボクココ

月額課金モデルの Web サービスの設計方法 - ボクココ

所感

色々な方と話したり聞いたりすると、「他の収入を得たり会社に所属しながらサービス開発をやっている」というケースをよく見かけた。その選択はもちろん間違ってないけど、私のように「半年や一年間の収入を絶って、ゼロから作るサービス開発に全てを捧げる」ような方も出てきてほしい。成功は保証できないけど、私はこの道を選んで良かったと思っている。

引き続きサービス開発において私が信じていることをベースにした記事を提供し続けていきたい。全ての読者にとって正しい内容であることは保証はできないが、読者の一部でも共感して実行まで移していただけることができたのなら、記事を書いた甲斐がある。

ボクココによって、より多くの方がサービス開発で幸せになれれば幸いである。さて、私はお先にその一歩を歩ませてもらうとしよう。

目標とされるような存在への挑戦

ども、@kimihom です。

f:id:cevid_cpp:20181215160125j:plain

久々に仕事に関する話で、「起業して大企業にして有名になる必要がある」って話で断固主張されるケースが出てきたので、これに対して私の考え方について記事にしたいと思う。

憧れる存在になること

ことの発端は、私が「人の目標にされるような存在になることが今の目標の一つ」と発言したことがきっかけだった。

そして言われたのが、「そうなるためには、会社を誰もが知るような大企業にして成功させる必要がある。それなのに、資金調達をせず人員を増やしていかないのは行動が矛盾している」ということだった。

ここで考える必要があるのが、目標とされる存在 = 大企業の社長になること なのかという点だろう。"多くの人に" 目標とされる存在になるには知名度ってのが大事で、大企業の社長にならないとっていう意見はある。実際、多くの人が知っているのは大企業の社長である。

でも、それって単なる手段の一つに過ぎないのではないだろうかってのが私の意見である。私には大企業でない組織で働く存在でいながらも、目標とされる存在になるっていう狙いがある。

私が目指したいのはマクドナルドではなく、百年以上続く日本の老舗店だ。もちろんマクドナルドの社長も世界中で尊敬される社長の一人だったかもしれないが現状はどうだろう。

当然ながら飲食業界と Webサービス業界では違いはあるけども、私は Webサービスで老舗和菓子店のような存在を作れるってことを証明したい。このような会社経営こそがまさに日本らしく、そして昔からある日本の強みだと思っている。最近のアメリカナイズドされた"急成長"っていう誘惑や欲望に狩られず、ひたすら目の前のお客様の幸せだけを考える。そういう企業でなければ、何百年も残り続けるような店にすることはできない。

起業した会社に資金を投資して急成長させる "ベンチャー" 投資/経営の仕組みは、日本発の仕組みではないことは明らかだ。もちろんグローバリゼーションの中で急成長するっていうのは否定するつもりはない。ただその関係者の中に必ず「金儲け」がメインの目的の人たちが出てきてしまう。そしたら必ず関係者の間で利害の不一致が出てきて、衝突が発生する。本当に価値を与えなければならないお客さんが二の次になってしまう。私からすればベンチャーで成功した先に待ってるのは、そんな企業ばかりだ。

世界最多の長寿企業を持つニッポン | nippon.com

百年以上続く老舗和菓子店で多くの人に目標にされるような存在になることは難しいかもしれない。だからこそ、私は誰もが常識だと思うような方法とは別の方法で、私なりに行動する必要がある。

この思いの実現には、他人に左右されない軸を持った人間であり続ける必要がある。

技術に関して、目の前に渡されたクーポンや他の人が使ってるからっていう安易な理由で技術を選定する人が多いけど、本当に必要な技術ってのは人それぞれのはずである。同じように起業したら資金調達して大企業にすることが成功だっていう結論に至る人が多いけど、本当に実現したい企業ってのは人それぞれのはずである。

"ボクはこうした。" 自分で大きな決断をくだし続けられるようにしていかなければならない。

現状を振り返る

そんな想いを持って行動している途中ではあるが、現状はどうだろうか。

私なりに振り返ると、今年の Heroku に関しての書籍執筆は一つの大きな達成の一つだと考えている。この書籍は多くのサービス開発エンジニアの方に読んでいただけたと自負している。

www.bokukoko.info

こういう書籍を執筆するだけでも、それを読んでくれた方が新しい目標としてサービス開発をしてくれるようになるかもしれない。

これは"ボクココ"も同じだ。かつては個人日記に過ぎなかったこのブログが、今では多くのサービス開発エンジニアの方に読んでいただけるようになった。

これは私が先ほど伝えた「目標とされるような存在であり続ける」というところの想いに繋がってくる。別に起業して大企業にするだけが目標とされるような存在ではないよねってことである。

当然これらのブログや書籍の執筆は、メインの仕事で成果を出した上で得られた副産物に過ぎない。とはいえメインの仕事を誰が見ても成功だと思われるには時間がかかる。メインの仕事が成功の途中でも、こうした執筆活動を続けられれば、最終的に目標とされる存在に近づくことができるだろう。

終わりに

起業して大企業にして誰もが知ってる存在になるってのだけが成功じゃない。

私には私なりの成功の定義があって、同じように目指してくれる方が増えれば、目標とされるような存在になることができる。たくさんの人にこのことを知ってもらうことも、自分の会社を大企業にしないとできないことではない。

私の行動が正しかったってことを、これからも証明し続けていく。

エンジニア不足の根本解決は自分で開発することだ

ども、@kimihom です。

f:id:cevid_cpp:20181125135541j:plain

友人と会話をしていると、誰もが「エンジニアが足りない」と嘆いているのを聞く。嘆いているってことは現に良いエンジニアが見つからないのだろう。

果たして本当にそんなにエンジニアが必要なのだろうか?今回はそんなエンジニア不足の問題について私の意見を記してみる。

エンジニアが増えれば組織が成長するわけではない

こう述べる方々は、エンジニアをたくさん雇って開発スピードを上げられれば、事業も成長できるという神話を信じている傾向を感じる。でも、実際にはそんなことは起きない。

エンジニアが多くなればなるほど、彼らをマネジメントするための人材や時間が必要だ。組織がどんどん複雑になっていった先で、開発スピードが向上したり良いサービスが出来上がるのかといえばノーだ。エンジニアは無駄なミーティングに出なきゃならなくなるし、誰かの書いたコードを読む必要があるし、設計書やソースコード、手順書をレビューしなきゃいけなくなる。リリース時には誰かの作業を見守ったり誰かの報告を注視する必要が出てくる。やがて開発に専用のルールやフレームワークみたいなのができあがって、それを守らなければならなくなる。新しく入ったメンバーはそのルールに従って開発することが求められるようになる。そんなガチガチに固められた枠の中で開発をすることが求められるようになる。

エンジニアが本当に欲しいのは、「開発の自由」ではないか。その自由を手に入れられれば、開発スピードは向上する。その究極が、あなた自信の手で開発するという方法である。

自分が全てを作ったので、全ての影響範囲がわかる。だからソースコードを大胆に壊して作り直すこともできるし、機能追加も高速に実現できる。開発の途中で意味不明なエラーに悩まされたり思わぬところでバグが出てくるようなことも少ない。そうして洗練されてできあがったサービスは、10人かけて作ったサービスよりも洗練されていて使いやすいものになる場合がある。

「エンジニアが多くないとサービスは完成させられない」という事実は一切ない。にも関わらず、その迷信を信じてエンジニアが足りないと嘆くケースが後を絶たない。

そうならないようにするために、サービス開発者は何を意識しなければならないのかを挙げてみる。

磨くこと(差別化)に集中する

サービスの1つを磨き上げよう。ここで言う1つってのは、サービスにおける最も重要な要素だ。

んで、大抵の場合はその1つってのが定められずに、ただ闇雲に機能開発をしてしまう。そうなってしまうと、単に多くの機能を追加したり、他の別サービスを作るといった選択をするようになる。

その結果、どんどん(うまくいくかもわからない)新しい何かを作らなきゃいけなくなっちゃって、エンジニアが足りないと嘆くようになる。この場合、新しいエンジニアをうまく雇えたとしても、その先に待っているのはうまくいくかどうかもわからない機能やサービスが増えていくだけだ。やがてエンジニアはその場を離れていって、またエンジニア足りない問題が再発する。

一時的に増えたエンジニアが闇雲に作り上げたサービスと、一人のエンジニアが磨きに磨き上げたサービスとで、どっちが優れたものになるかといえば明らかなことだろう。

磨くことに集中すれば、他にエンジニアが欲しいとは思わなくなる。誰が磨くのかといえば、それを作っているあなた自身である。その磨き上げが、誰にも真似できない強固な基盤のあるサービスとなる。たとえ他の優れた人が同じようなものを作り始めたとしても、あなたが磨き上げた時間のレベルに到達することはできない。

開発能力に自信を持て

サービスを作った超本人が技術力に自信がないから、他のもっと技術力のある人を仲間にした方が早いと判断するケースがある。

もちろん世界を見渡せば、技術力という観点だけで見れば自分より優れた人ってのはいるだろう。でもそれで諦めるべきかっていったら全くそうではない。

そもそもサービスを作ろうと思った張本人こそが、そのサービスを作ることに関して一番モチベーションがある。つまり一番開発を続けられるポテンシャルがあるのだ。最初はひどいコードだったとしても、その開発を続けられさえすれば、どんどんソースコードは綺麗になるし、技術力も上がっていく。

そのモチベーションのない人は自ら開発するってのを諦め、開発者を雇ってマネジメントをする傾向がある。でも雇われたエンジニアはサービスに対して、作り始めたあなたより情熱があるわけではない。彼らは開発を続けるっていう一番大事なモチベーションを(あなたより)持っていない。優秀なエンジニアはいつでもより良い給料を求めて転職することができるし、他の良いサービスを開発する機会があれば進んでそっちに移るようになる。自分が開発を続けた場合と、自分より優秀なエンジニア(高給)がコロコロと変わってサービス開発するのとで、どっちが最終的により物ができるだろう?

あなたより技術力があって、あなた以上に作っているサービスに情熱を傾けられるエンジニアが他に何人いるか。それに対して自信を持ってゼロだと答えられるような状態が理想だ。

少人数開発を実現する Meetup

最後に軽く宣伝を。

そうした少人数でサービスを作り成功させることに情熱を傾ける方々が集まる Bootstrap Night! が開催される。

selfree.connpass.com

彼らがそこまでしてサービス開発に情熱を傾けられ続けられるのは何故だろう?それは給料や地位などではない、全く他のモチベーションがあるからに他ならない。そんな開発の情熱に関して熱く語られる数少ない機会を見逃すな!

サービスの業務連携で意識すべきこと

ども、@kimihom です。

f:id:cevid_cpp:20181117152048j:plain

先日私の運営するサービスCallConnectで、地域電話(0ABJ)番号の取得・移設に対応した。

全国の地域番号(0ABJ番号)を継続利用が可能!フォースネット株式会社のFC-GW(エフシー・ゲートウェイ)は、合同会社selfreeの「CallConnect(コールコネクト)」と連携開始! | フォースネット株式会社 | プレスリリース配信代行サービス『ドリームニュース』

このリリースは、世界で初めて 「Webブラウザで電話をする WebRTC コールセンターにおいて東京03番号を使って非通知なしで受発信できる仕組み」だと自負している(もし執筆時点で他にあれば全力で訂正しますm)。今使っている 03 番号を電話機ではなく Google Chrome とヘッドセットで電話の受発信ができるようになる。そして Slack や kintone など、あらゆる Web サービスと連携することで電話とウェブの垣根をなくすことができる。

WebRTC コールセンター自体は世界中を見渡せば数多く存在する中で、なぜ今回のリリースが世界初だと自負することができるのか。それは、日本の電話回線との接続をサポートしたネットワークの仕組みを提供するのが今までできなかったからだ。そのため、あらゆるWebRTCコールセンターでは地域番号の紐付けのない「050, 0800, 0120」の3種類しかサポートすることができていなかった。さらに 0120 サポートも取得にはいくつかハードルがあるため、ほとんどの WebRTC コールセンターは 050か0800の2種類のみ提供するのが一般的である。

03番号は地域電話番号という種類で、東京にいることを証明する必要がある。また、既存の電話番号を WebRTC で利用できるようにするには国内の電話回線と接続するための仕組みが必要だ。今回の連携先である FC-GW は日本の電話回線を網羅しているということで日本にしかない強みになっている。海外で多くの WebRTC コールセンターがある中で、日本国内の電話網をサポートできる企業は数少ない。

今回のリリースでは入念な準備と検証によって出すことのできたリリースなので、個人的に意識したことを以下に記す。

お互いが汎用的な API として連携できるように実装

全国の地域番号を利用できる FC-GW は、他の WebRTC コールセンターを提供している企業でも実現できるような汎用的な仕組みになっている。なので今後 国内の他の WebRTC コールセンターでも、同様に地域番号が利用できるようになっていくことだろう。

これは両社と顧客のリスク分散って意味でも重要だし、汎用的にすることでビジネスの拡張性を得ることができる。実装において重要なのは、いかにして汎用的な連携の実装ができるかってところだ。デザインパターンで言えば「Strategy パターン」だ。

Strategy パターン - Wikipedia

SaaS をやっている場合にはとりわけこの Strategy 意識は重要になってくる。あらゆる SaaS の API のドキュメントを読み、連携を一つの Strategy として素早く埋め込めるようにする。私はこれまで 20サービス以上の API ドキュメントを読んで実装してきた。そんな経験をしていくと、どんな API がよくてどんな API がイケてないかってのもわかってくる。

www.bokukoko.info

積極的にテストに協力する

今回は特に 03番号を WebRTC で利用する需要があったので、他のコールセンター事業者さんでも利用できるようになる汎用的な技術であっても積極的にテストに協力した。そのおかげでリリース当日に連携を公開して、世界で初めて 03 番号を WebRTC で提供することができるようになった。

最終的にこの活動は業界としても効果が出るようになると考えている。WebRTC コールセンターにおける一つの時代の発展に寄与することができたと考えれば誇らしいことだ。

これに似た話を別の業界で聞いたことがある。何の食材だか忘れたけど某国内 No.1 の食品メーカーが、とある食品の作り方で革新的な方法を編み出したことがあったそうだ。その会社がすごいのは、作り方を企業秘密にしたのではなく、その食品自体を盛り上げるために作り方を競合企業へ公開したらしい。結果的に革新的な旨味を作り出す方法が業界として普及し、業界全体としてその食品の売り上げが伸びたというエピソードがある。私はこの話がすごく好きで、業界 No.1 らしい勇ましい行為だと素直に感動した。

私のモチベーションは全く同じだ。私も(自称) No.1 を自負して積極的に技術を公開していきたい。WebRTC コールセンター自体がまだまだこれからって段階の時に、この03番号をブラウザ(WebRTC)で受発信できる仕組みをウチだけのクローズドにしたところで、 WebRTC コールセンター自体が一般的に広まらなければ意味がないのだ。「ビジネスフォンを会社に置くことが当たり前」っていう風潮が残り続けてしまい、WebRTCコールセンター自体が普及していかないってのが最悪のシナリオなのである。

企業秘密にせず、積極的な情報発信をこれからも意識していきたい。

終わりに

お互いの SaaS を連携するって場合には、汎用性を意識するようにしよう。そして新しい API を使う場合には今後使う企業のためにも積極的にテストに協力しよう。

そうしてできあがった 03 番号を WebRTC コールセンターで利用できるようになった今回のリリースは、業界として大きな一歩になったに違いない。

普段このブログで書いている技術やサービス開発だけでなく、業界の先頭としても「ついて来いよ!」と胸を張って言える立場であり続けたい。私はこれからも新しい挑戦を続けていく所存である。

プラットフォーム革命――経済を支配するビジネスモデルはどう機能し、どう作られるのか

プラットフォーム革命――経済を支配するビジネスモデルはどう機能し、どう作られるのか

UI が複雑なほど自前で実装すべき理由

ども、@kimihom です。

f:id:cevid_cpp:20181014071217j:plain

先日、私の運営するサービスでカレンダーUIの機能をリリースした。開発ストーリー的な話は以下の記事でオフィシャルに記載している。

営業時間設定の改善に込めた想い | selfree

今回のリリースは視覚的に説明しやすいので、本記事で技術寄りの内容を記すとする。

カレンダーUI の概要

まず今回の実装した概要を動画としてキャプチャしたのでご覧いただきたい。

www.youtube.com

この機能の特徴として、以下のような点が挙げられる。

  • 1日だけでなく複数日にまたがって斜めスクロールができる
  • 削除は1日ごと
  • 収縮が可能
  • 1日で複数の期間を登録
  • 一括で上書き可能
  • 期間を各エリアの最上部に表示

このようなドラッグ&ドロップして期間を選択するUI を実現したいとき、あなたならどういう方針で開発を進めていくだろうか。

こだわりがあるほど自前実装

ほとんどの場合、まずはオープンソースのカレンダーライブラリを探すことだろう。自分のやりたいことに近いライブラリがあれば、そのライブラリを読み込んでちょろっと初期設定をすれば完成だ。そんな最適なライブラリがあれば良いのだけど、今回のこだわりUIでは以下のような特徴がある。

  • "祝日"を含めた週間表示だけ
  • 一括選択と一括の上書きができる
  • 削除は一括ではなく1日ごと

ほとんどのカレンダーUIのオープンソースでは、Google Calendar を目指した月間・週間・デイリー表示の3パターンのUIがあったり、祝日の列を追加することが考慮されていなかったり、予定を追加・編集するためのウィンドウといった余計な機能があったりする。そもそも、こうしたカレンダーのオープンソースの目的は "予定を入れるためのUI" だ。今回の "営業時間を設定するUI" とは根本の目的が違う。

にも関わらず、強引にオープンソースだけで乗り切ろうとすると悲惨な結末が待っている。初期設定のカスタマイズで済めば良いのだけど、ほとんどの場合は中のソースコードまでいじる必要が出てくる。結果として、自前実装するよりも膨大な時間と多くのバグを抱えた不安定な機能としてリリースを迎えることになるだろう。

「エンジニアならプルリクせよ」って話が出てくるかもしれないが、こうしたコンセプトから違うUIで機能追加のプルリクするのは良いことではないことは想像に容易い。もしそれがマージされたら、そのオープンソースの設定がファットになって、もはや誰のためのUIコンポーネントだかわからなくなる。実際、最終的にそういうファットなライブラリは結構ある。どんどん重い複雑なライブラリになって、やがて他のシンプルなライブラリが登場して誰も使われなくなる結末を迎えるのだ。

こだわりがあるほど自前実装が必要になるのはそこにある。自前実装すれば、以下のようなメリットが待っている。

  • 本当に必要な機能を実現できる
  • 最小限のソースコードになる
  • 拡張・メンテしやすい
  • サービスの差別化につながる

実際、このカレンダーは300行程度のJavascript で実装されている。何か修正・改善したいって時でも300行程度のソースを読み返すだけなのは心理的にとても良い。「あの部分のソースはもういじりたくない」って箇所をいかに減らしていけるかってのも、エンジニアの腕の見せ所だ。ただし、こうした独自UIの実装はフロントエンドの開発経験がそれなりに必要ではある。UI にこだわりを持ってスキルを磨いていけば、やがてどんなUIでも実現できるようになるだろう。

終わりに

今回は見た目がガラリと変わるほどの大きなUI改善だった。もちろんこの実装をするまでには多くの時間と考慮を必要としたけども、最終的により便利になったことに喜びを感じている。

「不思議と使いやすい」と思っていただけるようなサービスには、サービスに最適なUIがあるからだと信じている。だからこそ、私はフロントエンドの実装をものすごくこだわっている。こだわってやってきたからこそ、今ではどんなUIでも実装できる自信を持って開発することができる。

今回の内容は、どんな業界の "職人" にも同じことが言えるのではないか。職人であればあるほど素材にこだわる。私たちエンジニアで言えばソースコードだ。今後、ユーザーはますます食べ物と同じ感覚で「使いやすさの違い」がわかってくるはずだ。

特にフロントエンドUIに関しては自前実装にこだわるエンジニア職人になろうじゃないか。

強い開発チームに必要な徹底した議論

ども、@kimihom です。

f:id:cevid_cpp:20180930144539j:plain

私は日頃からサービス開発においては人数は少なければ少ないほど良いと述べている。それでもサービス開発には多くの場合、数名のチームを形成して作っていくことになるだろう。そのチーム間では強いチームワークが求められる訳だが、今回はそこに関しての持論を展開していく。

自社サービス運営の会社でも受託マインド?

唐突ではあるが、今のエンジニアの中で「言われたものを作る」ってマインドのエンジニアが多すぎることに課題を感じている。

こうした受託マインドのエンジニアは、自社サービスでもプロデューサーやプロジェクトオーナーが開発の方針を最終的に全部決めるから、自分は言われたことや仕様を忠実に開発することが仕事だと考えている。確かにそれで給料は出るし、チームとして何も問題がないように表面的には見えるけど、実は奥底で致命的な課題を抱えている。

言われたことを忠実に開発するだけなら、開発者があなたである必要が全くない。そして、言いたいことを言えないまま仕事をすることになるので、ベストな成果を出すことができなくなる。他の誰でもなく自分がチームの一員として開発していることを強めるには、チームへの理解と自分の意思でサービス開発することが重要だ。

  • この機能は自分"でも|は"必要だと思うから、開発|改善する。
  • この機能は自分が不要だと思うから、開発しない|削除する)。

自分の意思で仕事をすることで、エンジニアとしての市場価値も上がる。意見をしっかりと言えて改善できる意思のあるエンジニアがサービス開発には必要だ。時にはメンバーと摩擦が起こり、ケンカっぽくなることがあるかもしれない。でもそこを乗り越えない限り、強い開発チームになることはできないのだ。

チームにおける、いちメンバーとしての役割

もちろん、プロデューサーやプロジェクトオーナーが「俺の言うことを聞け」と高圧的に仕切るパターンもあるだろう。開発内容を決めることは彼らの仕事でもあるから、エンジニアに強要させることが多い。だが、その摩擦に妥協して意見を言わないって選択をしてはいけない。自分の考えを信じて徹底的に議論をしていこう。サービスに対する思いをプロデューサーやプロジェクトオーナーに知ってもらえれば、お互いがその後の仕事をより良いものにすることができるようになる。

大企業であればあるほど、自分の意思で開発することは難しい。あらゆる意思決定者がいる中で、自分の意見をメンバーに納得してもらって開発するには時間がいくらあっても足りなくなってしまう。そこでSNSのプロフィール欄では自分の考えを会社に反映できないから「投稿内容は私個人の意見であり、所属企業・部門見解を代表するものではありません。」とかいって責任を逃れるようになる。私があの責任逃れの文章で不快に思うのは、だったらわざわざ勤め先を書かなければいいだけのに、勤め先の会社名を堂々と乗っけてその会社にいるってことだけで見栄を張ろうとしているからだ。でもそういう環境だとしても適している場合があるにはある。そもそもエンジニアリングに対してのこだわりがなかったり、言われた通りのことをやるだけのエンジニアであれば、ある程度の安定した給料をもらえればそれでいいのかもしれない。

私としてはサービス開発の内容に妥協しないエンジニアがもっと増えていって欲しいと願っている。これはかつての私への自戒の念もこもっている。私自身、かつては企業に勤めて給料をもらっているごくごく一般的なエンジニアであったのだ。新卒で入った時には自分の意見を言い続けた尖った新入りだったものの、しばらくして「この会社で自分の意見を言っても、何も変わらない」ことを悟った時、給料をもらうことを優先して言われたことを開発するだけのエンジニアになってしまった。

しばらくして会社を辞めて起業してから、改めてメンバーに対して自分の意見を率直に言うようになった。そこでは当然メンバーとぶつかって何時間も討論することもあった。そんな状態でしばらく仕事を続けていると、次第に良いことが多く起こり始めた。「この人はこう考えている」ってのをメンバーそれぞれが理解するようになったので、その考えを踏まえた意見だとか準備ができるようになっていったのだ。自分の考えをメンバーに理解してもらったり、メンバーの意見に賛同できることは自分もその考えに心から賛同できるようになった。

私は、そんなメンバーの思いを奥底まで理解できている状態こそが、強いチームの条件だと考える。強いチームは、"何も言わなくてもわかる" 状態(チームワーク)になって次第に議論や意識統一が不要になっていく。

人がどんどん入れ替わったるする企業では、その度に人の考えを深くまで知ること必要があるが、それは当然のことながら難しい。採用でマッチする人を入れるって言っても、あくまで表面的な部分でしか測ることはできない。新しい人がどんどん入れ替わりで入ってくるような平均勤続年数が低い企業だと、私の定義する強いチームになることは永遠に不可能だ。また、自分の意見を言わずに我慢するようなタイプの人間がいるような全員YESマンな職場でも、同様に強いチームになることはできない。

リモートワークに対する批判は、そのような強いチームの状態になっていない状態でリモートワークをしちゃって「リモートワークはダメだ」と言っているに過ぎない。近年の会社形態として目立つ、人を一気に集めて一気にサービスを成長させるみたいな急成長マインドを持っている企業は、永遠に強いチームになることはできないのである。率直に意見を言い合って、時間をかけてお互いの考えを深く理解できているチームにだけ、オフィスを捨てられる状態になのである。

強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」

強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」

  • 作者: ジェイソン・フリード,デイヴィッド・ハイネマイヤー・ハンソン,高橋璃子
  • 出版社/メーカー: 早川書房
  • 発売日: 2014/01/24
  • メディア: 単行本
  • この商品を含むブログ (7件) を見る

終わりに

今回は強いチーム形成に必要なマインドについて記した。強いチームになるためにはお互いのメンバーが心の底から思っていることを深く理解する必要がある。その状態になるためには、メンバー同士がいつでも思いを発せられるような環境と、異なる意見に対して納得いくまで時間をかけて議論をして認識を合わせなければならない。

徹底して議論し、メンバーの考えを心の底から共有できたチームになれば、もはやメンバーが近くにいて細々と確認する必要すらなくなっていく。

そんなチームで、あなたは仕事をしたいと思わないか?

サービスローンチ後から始めるべき布教活動

ども、@kimihom です。

f:id:cevid_cpp:20180901164118j:plain

サービスをローンチしてから最初の有料顧客が来るまでには長くの時間を要する。サービス開発の時間をかけた分だけ、この時間は辛く長く感じることだろう。ローンチから1年以上経ってようやく有料顧客を見つけたというケースも少なくない。

そんなサービス開発における"迷える期間"で、コツコツとやっていくべきだと考えているのが「布教活動」である。今回は私の具体例を交えながら、説明していく。

コアなファンはサービスの Why に共感する

最初の顧客をいかに満足して使ってもらい、そのあと使い続けてくれるか。そして顧客が他人へ紹介してくれるようになるのか。単にサービスを使ってくれる顧客ではなく、ファンになってもらえるようにしなければ、その先のサービスの成長を得ることはできない。

サービスのファンになってもらうには、私たち運営者は Why (なぜそのサービスを作ったのか、存在するのか) を伝えて、顧客がそれに共感してもらわなければならない。What(どんな機能があるのか) の説明は、その時点での状況に過ぎないし、他と圧倒的に差別化できる要素ではないからだ。

サービスをローンチしたら、サービスの Why を伝えていく努力をしよう。それはランディングページ内に記載するなのかもしれないし、ブログを通じて発信していくことかもしれない。私の運営するブラウザ電話システム CallConnect の場合は、会員登録時の画面に Why を伝える機会を設けている。なぜそのサービスを作って、どんな人に使って欲しいか。それを理解した上でサービスを使ってくれれば、運営側としては正しい顧客とやりとりをすることができるし、顧客にとっては一種の期待を持っていただくことができる。

ようこそ。 私たちは、顧客と真摯に向き合う企業を応援し、企業の成長に貢献するために、ブラウザ電話システム「CallConnect」を開発しました。 より良い電話サポートを実現していただけるよう、CallConnect は進化し続けます。 顧客との新しい関係をはじめましょう。

それ以外にもメディアやブログを通じて、なぜ今の時代に電話サポートが必要なのかについて情報発信することを心がけている。 通話による即決のサポートは顧客満足度に大きな影響を与える、運営側の都合ではなく顧客にとって最適な連絡方法(電話,メール,チャット,対話)を選べるような状態が理想、電話の対応もメールの対応も一つに統一して情報を共有できるようにすることでサポートの質を飛躍的に向上できるetc。Airbnb の初期は創業者が熱心な電話サポートをしたことで、熱烈なファンを増やしていった。日本でも顧客と丁寧な電話サポートで愛され続ける企業が存在する。このようにサービスの重要性や解決できる課題を知ってもらうことで、顧客は初めてサービスに共感してもらうことができる。この順番でいけば、Why を知った上でのサービス利用をしてくれるのだ。

f:id:cevid_cpp:20180901165245j:plain
カスタマーサポートのことは嫌いでも、カスタマーサクセスは嫌いにならないでください より

この布教活動自体はすぐに成果の出るものではない。しかし、顧客がファンになってもらうには確実に必要なことだ。

自分が成功した後に、顧客を成功させる

最初から顧客が明確な課題を持っているサービスを作っている場合には、単にその解決方法を伝えるだけでいい。しかし顧客が気づかなかったニーズを満たすサービスを提供する場合には、また違った角度から布教させていく必要がある。

顧客が誰もいない段階では、何が成功なのかを伝えることが難しい。だからこそ、まずは自分が自分のサービスを使って成功者になる必要がある。最近ローンチしたライブ配信システム wellcast はまさにそんな状態だ。日本でウェビナーによる顧客教育は、まだほとんどの企業で行われていない。顧客教育するって考え自体が広まっていない背景には、顧客が使い続けてもらうよりも、マーケティングや営業を通じていかに新規顧客を獲得するかにフォーカスしている企業が多いのが背景としてあるように思う。

そんな状況だと顧客はそもそも課題に気づいていないので、サービスの Why を伝えても響きづらい。だからこそ、まずはサービスを運営する私たち自身が成功者となる必要があると考えている。顧客教育によってどんな効果が出たのかを明確に伝えることで、初めて未来の顧客が Why に共感して使い始めてもらえるようになる。

wellcast においては、海外では既に当たり前のようにウェビナーが開催されているし、その必要性を私自身が感じているので、 wellcast を使うことで成功を得られる自信はある。自分たちが使って成功できなかったものを顧客が使って成功できるはずがないから、何が何でも自分たちが使って成功させる必要がある。そしてその試行錯誤の過程をブログ等に記すことで、顧客がより成功させられる基盤を作ることができる。最高の循環(布教活動)を構築すれば、サービスを使わない理由がなくなってくる。そうしてサービスの成長が始まっていくのだ。

終わりに

「サービスを作ってローンチして、いいものだったら勝手に使われる」みたいな夢物語はほとんど存在しない。サービスをローンチした前と後とではやらなきゃならない優先度も変わってくる。そこを勘違いしていつまでも開発ばかり続けているようでは、サービス 0->1 の開発エンジニアとしては不十分であると言わざるを得ない。

布教活動はサービスに関係する全ての社員が取り組むほど価値のある行為だと私は信じている。そんな説明が書かれている以下の本は TED でも有名だが、本書でより詳しく学ぶことができるだろう。

WHYから始めよ!―インスパイア型リーダーはここが違う

WHYから始めよ!―インスパイア型リーダーはここが違う

失敗しない SaaS プライシング設定

ども、@kimihom です。

SaaS でのプライシングは悩みの種としてよく挙げられる項目かと思う。その中で基本的なプライシングにおける3つの軸について紹介し、それらを実際にどう設計/実装していくのかについてご紹介していく。失敗しない SaaS プライシング設計で正しいサービス運営をしていこう。

SaaS プライシング 3つの軸

まず本記事でいう 3つの基本軸は何かというと「機能」、「人数」、「利用量」である。

「機能」は、利用するユーザー層によって提供する機能を変えることである。SaaS のプライシングで最もオーソドックスな方法の一つである「プラン」による分類がこれに該当する。提供する SaaS のユーザー層によって必要になる機能は異なることが多い。起業したばかりの少人数の企業が、細かなレポーティングや機能のカスタマイズなどが必要なケースてのはほとんどない。それなのに大企業向けの高めのプランしかなければ、中小規模の企業はサービスをそもそも利用しないという選択をすることだろう。しっかりとプランを分けて、機能や使える量は少ないけどその分料金が安いものがあれば、多くのユーザー層が適したものを利用できるようになる。当然 より高度な機能を使いたいってなったらその分課金しないといけないってなるのでユーザーの納得感は得られやすい。

「人数」は利用ユーザー毎に毎月課金される形態だ。一般的には「ライセンス」といった言葉で表現されることが多い。その SaaS を使う関係者が多くなればなるほど、そのサービスの必要性は増すので、そのタイミングで追加の課金が必要になれば、追加で料金が発生するのも納得を得られやすい。ただしこのライセンスモデルは、複数アカウントがあるからこそのメリットを掲示できないと、いとも簡単にアカウントの共有ができてしまうので、提供する機能に影響を受けやすい。もしくはアカウント共有するまでもなく、1人でも5人でもそんなに気にならないくらい安い金額(1ユーザー500円程度)の料金体系にしているケースが多く見受けられる。

「利用量」は使った分だけ課金される形態だ。従量課金と呼ばれるこの形態は、ユーザーが何かを使った分だけ毎月かかる金額が変動するタイプである。従量課金は事前に決済される金額が予測できないので、事前に顧客には使ったらどのくらいお金がかかるのかを明快に説明できるようにする必要があるだろう。従量課金は使った分だけお金を払うという公平な金額設定なため、プランや人数など関係なく利用量だけでプライシングを展開できる可能性を秘めている。

提供している SaaS は何の価値を提供しているかが選定のカギ

これら3つの基本軸のどれかを選ばないといけないわけではない。必要に応じて、3つを組み合わせることができる。

例えば、「提供する SaaS の価値は多くのユーザーが使うことで初めて享受できるサービス」の場合、人数ごとの課金はさせたくないことだろう。気にせずたくさんユーザーを招待してもらって使ってくれるようにし、それ以外の部分で課金する形態を取ることになる。となると、プラン毎に機能を分け、サービスを使った分だけの従量課金にするという答えが導かれるかもしれない。

シンプルに単一のコア機能だけを提供する尖ったサービスの場合、使った分だけの従量課金だけで攻める方法が考えられる。これを単一プランで全ユーザー同一金額にしてしまうと、たくさん機能を使ったユーザーと、そこまで使ってないユーザーの間で不公平が生じてしまうためだ。それとは正反対に、毎月一定の金額を支払うことで利用する権利を得ているという考えであれば、不公平が起きたとしても気にしないというケースも考えられる。

プランに関しては機能で差別化する方法以外にも、スペシャルサポート等を提供する方法もある。とりわけ大きな企業を相手にする場合、最終的にすぐに連絡つく人がいるかどうかといった部分も大きなウェイトを占めたりする。今後、提供している SaaS でより裾野を広げていく可能性も考えられるので、プランの設計は最初は1つだったとしても、今後2つ3つと増えていく可能性があることを前提としてサービス設計をしていきたいところだ。

より詳細を知りたい方

2018/08/03(金) に東京で開催される JP_Stripes Tokyo Vol.8 で、今回の話を具体例を交えて登壇する予定だ。もし興味があれば参加を検討していただきたい。SaaS のプライシングについて共有される場ってのはほとんどない状況なので、議論できれば幸いだ。

JP_Stripes (Stripe ユーザーグループ)Tokyo Vol.8|EventRegist(イベントレジスト)

おわりに

今回は SaaS のプライシング周りで検討しなきゃいけない項目について簡単にご紹介した。

プライシングを正しく設定できないと、正しく料金をいただける場面でいただけない状況が生まれ、ビジネスの成長を滞らせてしまうリスクがある。サービスごとに正解が異なるってのと後で変えにくいという難しい課題ではあるが、慎重に設計していってほしい。

SaaSで激変するソフトウェア・ビジネス ~ソフトウェア業界を揺るがす破壊的イノベーション~

SaaSで激変するソフトウェア・ビジネス ~ソフトウェア業界を揺るがす破壊的イノベーション~

サービス開発の成功は一日にしてならず

ども、@kimihom です。

f:id:cevid_cpp:20180708004524j:plain

「自分の作ったサービスが成功した」という状態にまで持っていくのはサービス開発者なら実現したいことの一つのはずだ。私もその想いの途上ではあるが、この件について考えていることを記す。

サービス開発の成功ってなんだろう

どのレベルにまで到達したら、サービス開発が成功したと言えるのだろうか。当然その目標は人それぞれではあるが、以下のようなケースがあるだろう。

  • サービス開発時の想いを実現できた
  • 5年以上サービスが残った
  • 1万ユーザーに使われる状態になった
  • そのサービスだけで食べていけるようになった
  • イグジットできた

上記で共通するのは、「ほとんどの場合、すぐには達成できない」ということである。サービスの成功は1日してならず、だ。

既に成功した(つつある)サービスに途中から入って自分が成功したみたいな雰囲気を醸し出すのは、サービス開発者として違うと言わざるを得ない。それは単なるサービス"運用"であって、あなたが得たサービス開発の成功ではない。サービスをゼロから作り始めて、それを自分の目標にまで到達させることができた。その状態にまで持っていって初めてサービス開発が成功したと胸を張って言えるのである。

作ったサービスをどれだけ "信じ続けられるか"

インターネット関連のサービスを作っていると、ニュースで見るような爆発的な成功がいつかやってくると思っている方は多いかもしれない。しかしそれは本当に一握りの事象であって、ほとんどは不可能だ。そもそも、その超大成功したケースであっても、実は3~5年サービス開発を続けてようやく爆発したみたいなケースばかりである。そこを勘違いして短期での急成長を望みすぎると、一気に余計なところ(広告や事業提携等)に大金をはたいて、会社や事業の存続が危うくなったりする。やがてせっかく作ったサービスや会社をクローズしなければならないという悲劇を迎えてしまうのである。

あなたが作ろうとしているサービスは、ユーザーがほとんどいなくても最低2,3年は愛着を持って育て続けられるか? 単なる勢いだけで作ったサービスの場合はこの期間を耐えることは不可能である。何かしら自分が続けたいと思える理由を持って、着実にサービスを育て続けよう。サービスの成長のための地道な活動こそが、サービスの将来を左右する。

失敗するサービスのほとんどは、この2~3年を耐えることができない。この期間を耐えきれずに、最初の仮説が間違ってたと決めつけターゲットを変えたり広げようとする。そして不安から無駄な開発をして仕事をした気分になってしまう。最初から"3ヶ月で売り上げ~万"とか、"~千ユーザー獲得"だとかいう訳のわからない目標を立ててしまうと、本当に使って欲しい人を見失って、ちんぷんかんなサービスができあがる。早すぎる結果を求めすぎたからこそ生まれる悲劇である。サービス開発の目的を金儲けといった本質的でないものにおいてしまうと確実に失敗する理由でもある。

最初に仮説として立てた理想のユーザーが、サービスを見つけて使い始めてくれるには多くの時間がかかる。なぜ誰も使ったことのない新しいサービスを使わなければならないのか。ほとんどの人は あなたのサービスよりも、既存のちょっと不便で高くても実績のある方を選ぶだろう。その方が間違いなく時間をかけずに課題を解決してくれるからだ。でもその中で、本当に大きな問題を抱えていて、どうしてもあなたのサービスを使わなければならないユーザーが、使い始めてくれる日が(いつか)やってくる。その人が恐る恐る使って愛着を持ってくれて、使い続けてくれるようになってからが、本当の成長の始まりだ。この状態が半年や1年で実現できるはずがないのは自明のことである。あなたの作ったサービスで本当に解決したい課題はなんだろうか。そこを見失わずに開発を続けた先に見えたわずかな光。その光をつかめた人だけが、サービスの成功を手にすることができるのである。

先日お話したサービス開発者の方で、「サービスを作って3年放置してたら導入の相談があって、そこから値段を決めたり、サービス開発を本格的に始めた」っていうエピソードがあった。サービスをクローズさえしなければ 、いつかそうした話が来る日がやってくる可能性がある。ただし、大抵の場合は何かしらの情報発信をすることで顧客を見つけるための努力はできる。例えばその期間で私が意識してきたのは、「自分がそのサービスの分野のスペシャリストである」ということを知ってもらうための努力をしてきた。つまりその分野での情報発信である。するといつの日かその記事を読んだ方がサービスを使ってみようと思ってくれる日がやってくるのである。この信頼を積むための準備にいかに時間をかけられるかが大事になってくる。それをやらずして、単にサービスを運用しているだけだと、理想のユーザーを見つけるのにより多くの時間がかかることになる。いや、もしかしたらずっと巡り会えないかもしれない。

どちらにせよ、時間がかかることをいかに続けられるかがビジネスの将来を左右することは間違いないだろう。

終わりに

サービス開発で夢見がちな急成長の幻想は捨て去ろう。そうじゃなくて地道で確実に信頼を積み上げて、正しい顧客を見つけて使い続けてもらう努力をしよう。その努力はきっと、最初に立てたあなたの目標を達成する源になろう。

目立ったことばかりしたがる人は最終的には成功できず、地味な努力を重ねた人が最終的には成功する。私はそう信じている。

サービスの競合を意識すべきでない理由

ども、@kimihom です。

f:id:cevid_cpp:20180623163040j:plain

サービスをローンチすると、他の方から "競合Aとは何が違うの?" といった質問を受けたりすることがある。また、サービス開発をしている中で、"競合Bはこんな機能があるからうちも欲しい" とか、 "競合C には絶対に負けない" といったような判断をする方がいる。私がそうした競合を意識したサービス開発をすべきではないと思う点について記す。

サービスを作り始めた想いを見失う

なぜあなたがサービスを作ろうと思ったのか? その想いの根本は、あなたが持ち続けなければならないものである。その想いこそがサービスにおいて唯一無二の独自なポイントであり、他者が絶対に真似することができない点だ。例え他に似ているサービスがあったとしても、他の誰でもない"あなた"が持っているあなたなりのモチベーションなのである。

競合を意識し出したら、その想いが薄れてきた証拠だと言えよう。最初から自分の持つ想いが薄すぎた可能性もある。どちらにせよ競合を意識するってのは自分の想いが薄くなっている状況であり、好ましい状態だとは言えない。そして、他者から答えを得ようとする。そんなんで得た答えに一体何の意味があるのだろう。あなたなりのサービスだったのが、そこら辺にあるようなサービスに移り変わっていくのも時間の問題だ。

参考にすべきは競合ではなく顧客の意見である。顧客が感じている課題があるのなら、それを解決するように努力するのがサービス開発者ってもんだ。大抵の場合、その意見ってのは新機能ではなく、既存機能の使い勝手の悪さやわかりづらさだったりする。そういう意見を大事に持って、自分なりの答えを出し続ければ、競合の存在なんてどうでもいいのである。

自分で考えた答えじゃなくなる

競合を意識したサービス開発をすると、それに影響を受けて一つの答えが出てくる。果たして、それで導き出された答えは本当に自分で考え出した答えなのか?競合をヒントにして自分なりに考えたってのは、競合から出した答えに過ぎない。その判断は 100% 間違っていると断言できる。

なぜなら、自分や顧客から意見が出てこなかったってことは、そもそもサービスにおいて必要となるものではないはずだからだ。もし本当に必要だったのなら、自ずと要望や課題として湧き上がってくるはずで、それに向けてどう解決すべきかを自分で調べて実行しているはずなのだ。それができないってことは、自分たちの努力不足に過ぎない。

本当に自分で考え出した答えでないと、サービスがどんどんブレていく。そしてそのブレた開発をユーザーはすぐに感じるとるだろう。

真のオンリーワンを目指し続けたサービスだけが、最後まで残り続ける。決してその努力は無駄にはならず、独自性や強みとしてサービスに反映されていくことだろう。

サービス開発が勝ち負けの世界になる

競合を意識するってのは、サービス開発を勝ち負けの世界に持ってき始めている恐れがある。

でも、サービス開発に勝ち負けなんて存在しないのだ。競合より儲けて人もたくさん雇えれば、それで勝ちなのかといったらそうではない。サービス開発は単純なゲームではないはずだ。

改めてなんでサービス開発を始めたのかを思い返してみよう。

サービス開発の目的を売却や上場などの金儲けのためにやっている人がいるけど、それはやってはならないことだと思う。実際にめちゃめちゃ成功した人が、最初からそんな目的でやっていたはずがない。サービス開発を始めた理由をちゃんと理解し、それに忠実に実行し続けた結果として、あくまでそうした成功を得られたってだけの話だ。単にトレンドに乗っかって起業しました的な人や、金儲けや有名になりたいから起業しましたみたいな人は全く応援する気になれない。

自分のペースでコツコツと着実に前へ進んでいこう。近道なんてのを探ろうとしてはいけない。自分の決めた道こそが正しい道なのである。そうして自分を信じ続けられた人だけが、最終的には本当の成功を得られると信じている。

終わりに

今回はサービス開発でありがちなミスの一つである、「競合を意識する」ことについて想いを記した。

競合を蹴散らそうだとか、競合よりも大きくなるだとか、そんなことを考え始めるのは無意味だし不幸の元だ。自分たちとユーザーが幸せになることだけを考えて、本来のサービス開発の目的を実現させよう。巷でニュースに出てくるような「成功」ってのは、その先に得られた結果に過ぎない。

そんな想いを持った人の作ったサービスを使いたいし、共にサービス開発していきたい。

本当のブランド理念について語ろう 「志の高さ」を成長に変えた世界のトップ企業50

本当のブランド理念について語ろう 「志の高さ」を成長に変えた世界のトップ企業50

企業向けライブ配信システムをローンチした話

ども、@kimihom です。サッカー日本代表、勝利おめでとう!!

そして本日、企業向けライブ配信システム wellcast をローンチしたので、本サービスについて個人的な想いを記す。

企業向けライブ配信システム | wellcast

f:id:cevid_cpp:20180619144707p:plain

サービス概要

wellcast は、リードや顧客育成のための企業向けライブ配信サービスだ。wellcast は appear.in のように、専用の URL を発行し、その URL ですぐにでもライブ配信ができる仕組みになっている。wellcast が発行した URL を、配信を見て欲しい特定の人にメールで伝えるでもいいし、SNS を通じて広くシェアするでもいい。何かしらの方法でその URL を知ってアクセスした人は、簡単な情報(名前とメアド) を入力するだけで、ライブ配信を視聴できる。

配信者は専用のプラグインやソフトウェアをインストールする必要はない。Google Chrome で PC に付属したカメラや USB につないだカメラを使って配信を始めることができる。また、スクリーンシェアを通じてデスクトップの特定の画面を共有することも可能だ。スライドの共有や DEMO をするケースで便利に使えるはずだ。

さらに配信の内容は mp4 形式で録画されるので、ダウンロードした動画をそのまま Youtube にアップして後で見られるようにすることもできる。

よくある質問として、Youtube Live などの他配信サービスと何が違うのかという点がある。そもそも Youtube は BtoC 向けのプロダクトなので、ターゲットが違う。wellcast は企業向けの機能を強化している/する予定だ。視聴者に対して事前に情報を入力してもらうようにすることができるので、ライブ配信を見てもらった人に後でフォローメールを送ったり、面談を依頼するといったような次のビジネスの行動に移すことができる。今後は視聴者の分析機能を拡充したり、CRM との連携を通じて、ビジネス用途に最適化したライブ配信システムにしていきたいと考えている。

金額は毎月の基本料金が800円で、あとは配信量に応じた従量課金になっている。60分の配信を10人が視聴した時におよそ800円くらいになる。その規模のイベントをリアルでやった場合の交通費や会場費、懇親会費などと比べてみていただけたら幸いだ。

開発の背景

wellcast は、まさに私が望んでいたシステムだった。SaaS を運営していると、「進化し続けるサービスを顧客に対してどうやって教えていくか」という課題にぶち当たる。現状では以下のような方法が選ばれていることだろう。

  • FAQ の拡充
  • サポート(メール/電話/チャット)
  • メールやサービス内の通知によるお知らせ
  • リアルイベントの開催

基本的には顧客の不満を解決するために、FAQ やサポート体制を構築するという姿勢になる。それはそれでとても重要なことなんだけど、これらは顧客を育てる という観点ではない。顧客が今まで知らなかったような便利機能や使い方を FAQ やサポートで新しく知ることはできない。なぜなら、新しい発見は顧客の潜在的な課題なので、自分から調べたり問い合わせたりしないからである。

かといってリアルイベントを開催するってのも限界がある。全国各地にいる顧客にどうやって会うかっていったら各地で開催して各地に赴くしかない。それ自体を否定するつもりはないけど、数ヶ月に1回レベルの頻度の開催で "顧客を育てる" という意味で効果的かどうかは疑問である。

顧客育成における付き合い方を模索している中で、ライブ配信は効果的で価値のある方法の一つだと考えている。それを実証するためにも、まずは開発者である私自身が wellcast を使って、さらなる改善を続けていく。主催や共催のイベントで積極的にライブ配信をしたり、自社サービスのウェビナーを通じて、企業におけるライブ配信を普及させていきたい。

技術的な話

現状、Web のテクノロジー(WebRTC)がまだ整備されていないこともあって視聴できるブラウザは基本的に Chrome のみとしている。スマホは Android 端末は古いバージョンでない限り Chrome で見ることができる状態で、iOS はサポートしていない。今後、対応する端末やブラウザを増やしていくのは当然のことだが、現状は wellcast がビジネス向けのサービスであるため、企業のウェビナーやライブ配信を iPhone などのスマホで見ることも少ないだろうという推測がある。

今後、数年以内にあらゆる Web ブラウザで WebRTC が使えるようになるだろうという前提でサービス開発をしている。専用のアプリインストールが不要で、純粋に URL をクリックするだけで配信を視聴できる仕組みを先立って開発している形だ。

終わりに

ライブ配信をビジネスで。

今後、企業がライブ配信を通じて顧客を育成していくことが当たり前になる世の中が必ずやって来る。先頭に立って私がそれを実証していきたい。

もしよければ無料で200円分の配信ができるので、会員登録してみて頂けたら幸いだ。

SaaS 運営で CRM へ保存しておきたい情報一覧

ども、@kimihom です。

f:id:cevid_cpp:20180531211339j:plain

SaaS をやっている方であれば、顧客管理の重要性は誰でも理解していることだろう。メールやチャット、電話の問い合わせが来た時にすぐにその顧客の状態を把握して、迅速に最適な回答を導き出すことが求められている。この回答のスピードが早ければ早いほど、顧客満足度につながってくるので、いかにしてその対応を早くするかを日々考えていることかと思う。

さて、今回は SaaS を運営する方なら CRM で保存しておきたい情報についてまとめてみる。

1, ワンクリックで飛べるリンク

CRM にはあらゆる顧客情報が掲載されていることが前提なので、問い合わせが来た時にいかにその顧客詳細のページへ飛べるかが勝負となってくる。電話 > チャット > メール の順番でより素早いアクセスが求められる。

理想はワンクリックだ。例えば電話が来た時点でそこに表示されたリンクをクリックするだけで CRM の顧客詳細へ飛べる。チャットが来た時点でワンクリックでその顧客の属性や過去のやりとりが閲覧できる。その顧客を検索するために、わざわざ管理ツールで文字で検索しなきゃいけないような状態では遅すぎるということである。

私のサービスの場合は電話メールそれぞれでサポートチャネルを用意している。このどちらも、ページ内でワンクリックで CRM へ飛べるリンクが用意されている。そしてどちらのサポート対応の履歴も CRM で電話番号とメールアドレスを関連づけて保存しているので、統一して閲覧することができる。

こうすれば、電話しながらでも詳細を把握して速攻で問題を解決できるサポートを実現できる。さらに、電話を受けた後にメールでフォローするみたいなことも簡単にできる。これで電話を保留やあとでかけ直したり、メールアドレスを聞き出しているようでは電話サポートでの顧客満足度を実現するには難しい。

2, 外部サービスへのリンク

今の時代、サポートの SaaS 以外にも、あらゆる SaaS を利用してサービス運営をしていることだろう。Mixpanel で行動を分析したり、Stripe で課金処理を実行したりといった具合である。どうしても自社システム内の管理画面でしか表示できない項目もあるかもしれない。例えば現在の決済情報などは CRM 側にもマストで持つべきだけど、細かい情報全てを CRM に集約することは難しい。その場合は、CRM 側で外部リンクを保存し、いつでもすぐにアクセスできるようにしたいところだ。

こうすれば電話やチャットで問い合わせが来た時に、2クリックで該当ページへ遷移できる。これも、外部サービス側で id や名前を検索しているようでは遅すぎるし非効率的だ。

CRM で概要を閲覧できるようにしておき、問い合わせ内容に応じてより詳細のページを見にいくといった具合が理想的だ。

3, プランや MRR, ヘルススコア

CRM 側でプランや MRR, ヘルススコアが管理できる必要がある。大抵の場合、こうした情報は自社の管理ツール内で完結させることが多いかもしれないが、それは最初の暫定対応ではいいかもしれないが、しばらくして管理ツールの開発だけに時間を取られることになる恐れがある。特に、例えば、最終的に欲しいデータをグラフ化して表示できるようにしたいとかいった場合に、ユーザーが見もしない管理ページでグラフ描画の実装をしなきゃいけなくなる。自前で SQL を組み立ててチャート化するツールとかもあるけど、その集計のための学習や用意に時間を取られる。

大抵の CRM では、取引を管理できるようになっていたり、カスタム属性で MRR やヘルススコアを保存できるようになっている。そして、それらを最終的にグラフで描画したり、顧客をフィルタリングしたりできるようになる。

例えば MRR が 10,000円以上の顧客を VIP とした時に、自社の管理ツールですぐに取り出すことができるか。ヘルススコア30以下の顧客一覧を抽出し、フォローメールを送ることができるか。そういった分類と対応をわざわざ自前の管理ツールで実装しているのは、時間がかかりすぎだ。それに時間を割くなら、肝心のサービスの機能の改善をしていこう。

最終的に、それらがカスタマーサクセスとしての指標分析の土台となろう。こうしたデータをしっかりと管理せずに、カスタマーサクセスは不可能だ。そして、この分析をエンジニアがわざわざ自前で作らなくても、誰でも取ってこれるような状態にしなきゃいけない。だからこそ、こうした情報こそ 自社サービスの管理ツールで実現するのではなく、CRM へ保存するようにしよう。

ありがちな顧客管理の方法として、「単一チャネルのサポートだけだからサポートツール(Zendesk/Intercom等)に顧客情報を保存しておく」って対応をするケースがある。これはこれで手軽な部分がある反面、チャート描画や指標管理といったところで不十分になることが起き始める。検索やフィルタリングくらいまでならサポートツールの顧客管理で見られたりするが、そっから先(分析やチャート描画, 通知 etc)のことまで提供をしているものはない。今後、そのサポートツールが機能を提供するようになったとしても、サポート担当者以外の人もそのサービスにライセンス費用を払う必要が出てきたりするので、効果的なのかは怪しいところだ。

4, その他 SaaS 独自の顧客情報

サポートチャネルが複数あったり、マーケティングやセールスにも顧客情報を活用しようとなったら、そのサポートツールだけでは足りなくなってくる。厄介なことにマーケティングツールの SaaS, セールスの SaaS、他には従業員管理の SaaS までなんでも SaaS を利用するケースが出てくる。

それらを最終的に CRM でフィルタリング/分析していくので、本当に必要な情報はやはり連携を駆使して CRM 側へ保存していきたいところだ。あらゆるデータを CRM へ保存し、顧客を分析してより良い成功へ導いていく。これこそが「カスタマーサクセス」なのである。

終わりに

「成功する SaaS は CRM を駆使する。」そんな仮説を私は立てている。

顧客の動向を知り、顧客に最適なサポートを提供し、機能を改善していく。自社SaaS で最適な顧客の動向を定義できれば、その理想の顧客の獲得に集中することができる。顧客を知ることができないと、手当たり次第にサービスや機能を作りまくって一か八かのリリースを繰り返すことになってしまうのだ。

本当の顧客を見つけられるようにするためにも、今一度 CRM の本格運用を検討していこう。

CRM―顧客はそこにいる (Best solution)

CRM―顧客はそこにいる (Best solution)

  • 作者: 村山徹,三谷宏治,アクセンチュア,CRMグループ,戦略グループ
  • 出版社/メーカー: 東洋経済新報社
  • 発売日: 2001/07/01
  • メディア: 単行本
  • 購入: 5人 クリック: 39回
  • この商品を含むブログ (16件) を見る