69
20

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

iOSエンジニアが考えるBtoBサービス開発の面白さ

Posted at

トレタ Advent Calendar 2016の12日目です。

はじめに

最近スタートアップでもBtoBサービスが盛り上がってきましたね。BtoB、BtoCと書くと読むのがちょっとつらいので以下、toB・toCと呼ぶことにします。

タイトルにはざっくりtoBと書いていますが、主にSaaS型toBサービスの話になります。また、toBサービスも意外と面白いんだよーという話であって、どちらが良くてどちらが悪いという話ではありません。僕もやっぱりtoCが面白そうだなって思うことは多々あります。友達が使ってくれてたりしたら最高ですよね。(誰かtoCの面白さについて書いてくれると嬉しいです)

面白いところ

お客さんが一方向➡️

toCの悩みでよく聞くのが、ユーザーと広告主さんの両方を見なければいけないということです。使い勝手を考えると広告は無い方が良いですし、とはいえマネタイズを考えると載せないわけにもいかないという板挟み状態です。つらいですよね。

toBの場合は基本的に有料で使っていただくことになるので広告を載せるような必要もありません。これの何が良いかというと、マネタイズと改善でぶつからないんですね。開発だけでなく、他の部署含め全員がサービスを良くすることに集中できるということです。

もちろん、ただtoBであればいいかと言うとそうではありません。お金を払って使っていただいていることもあり、カスタマイズ要望が出てきたりもします。これについては後述します。

直接フィードバックを頂ける🙋‍♂️

フィードバックの方法としてはトレタの場合ですと、下記3パターンがあります。

  • 営業経由
  • サポート経由
  • 直接ヒアリングに伺う

経由しているのにあえて「直接」と付けたのは、相手がどこの誰かが分かるからです。toCの場合は、そのフィードバックをしてくれたユーザーさんがどんな人かは中々分からないものですよね。toBの場合は当然ながら相手が分かるので、より具体的にフィードバックの内容を知ることが出来ます。

また、嬉しい声を聞くことも多々あります。その場合も「◯◯店の店長さんがこの改善でとても喜んでくれていました!」の様に、使ってくれている人のことをリアルに思い浮かべることができるんですよね。

レビューやシェアしてもらうことも、もちろんとても嬉しいのですが、相手のことをリアルに想像できるとまたその重みが違ってくるんです。

何かあった時に直接見に行ける👀

ユーザーがどこの誰かがわかっているので、万が一何か不具合が発生した時に社内のスペシャリストが駆けつけることが出来ます。実際に僕も何度かお店に駆けつけたことがあります。その場で解決できたこと・できなかったことありますが、何かしらの回避策を提供したりと対応をさせて頂きました。

トレタではクラッシュレポートと一緒に店舗名を送信するようにしているので、頻繁にクラッシュするようなことがあれば店舗さまに連絡し、実際にヒアリングに伺うこともあります。

ASO(アプリストア最適化)を気にしなくて良い👆

iOSアプリを使ったtoBサービスの多くはアカウント登録はウェブ上で行い、アプリはクライアントとして利用することがほとんどです。そのため、toCアプリに比べてランキングなどを過度に気にする必要はありません。

検索しても出てこないのは問題外ですが、実際に僕は順位やDL数などは全く見てません。App Storeにはスターとレビューもありますが、たまに覗くくらいのことはあってもルーチンで確認するようなことはしていません。

単純にタスクが一個減るということ以上に、変に気にしなくて良いというのが精神衛生上とても良いです。

Apple推奨の直近2つだけのOSサポートが可能に!🎉

直近2つのOSをサポート、Deployment Targetは最新のアップデートバージョンに

toCの場合は少しでも多くのユーザーさんに使っていただくためにサポートバージョンを幅広く取っていることが多いと思います。これはこれで一つの戦略だと思うのですが、エンジニアとしては少しつらい部分がありますよね。

toBの場合はユーザーと直接連絡が取れるので、必要であればiOSのアップデートのお願いすることもできちゃったりします。これってエンジニアとしては結構魅力的ですよね。

大変なところ

面白いところがあればもちろん大変なところもあります。でもそんなところもやりがいだったりするんですよね。

業務で使っているのでサービスが止まると業務も止まる😱

考えただけで恐ろしいですよね。。もちろんtoCなら止まっても良いというわけではありません。ただ、toBの場合はお客様の業務を実際に止めてしまうことになるので、よりいっそう神経質にならないといけないところです。

インフラはもちろんですが、iOSアプリはリリースに審査が必要になので、すぐに修正してアップデート出来ないというのが辛いところです。(一度韓国に遊びに行ってる時にアプリが立ち上がらないという問題が起きたことも。その時は結局アプリの問題ではなかったので事なきを得たのですが。。)

そのためテストにはかなりコストを割いていますし、サポート体制も万全にしています。さらに、実際に障害は起きるものと考え、起きた時にどうするかということも考えています。例えばアプリですと、入力中にクラッシュしてしまった場合はクラッシュ前の状態で復元できるようにしています。

業務で使っているので使いにくくても使い続けてしまう⏩

これだけ聞くと「え、使ってくれるんだからいいんじゃないの?」って思ってしまいませんか?

短期的には良いのかもしれません。しかし、長い目で見るとサービスの生死に関わるくらい重要なことだと考えています。使いにくくても使い続けてるという状態は、DAU/MAUなどに現れにくいので気付くことが難しかったりします。

つまり、改善を怠ると気付かないうちに緩やかに死に向かって進んでいき、気付いた時には手遅れという状態になってしまいます。こうならないためには新しいことだけでなく、常に改善のサイクルを回しておくことが大切だと思っています。

また、改善しているつもりでも実は余計なものを追加しているだけで、むしろしないほうが良かったということもあるので判断が非常に難しいところです。

個人的にアプリ開発で一番気を付けているのがこのバランス感かもしれません。「足りないなら足せるけれど、足したものは引けない」ということを常に頭に置いて開発に取り組んでいます。

避けては通れないカスタマイズ要望🛠

toBサービスにはカスタマイズ要望が付きものです。僕は単純にやるのが悪くてやらないのが良いという話ではないと思っていて、ここは経営判断だと思っています。(エンジニアとしてはやると辛いなぁというのはもちろんあります)

これに関してはKihiraさんという方がCTO増井との話をとても良くまとめてくださっています。とてもおもしろい内容なので是非一度読んでいただきたいです。
トレタの増井さんに聞く、B2Bサービスのカスタマイズ

現在のトレタは一切のカスタマイズを受け入れていない

増井を筆頭に、弊社には37signals本が好きなメンバーが多いので自然とこの様な考え方になっているのかもしれません。僕がトレタに入社を決めたのもこの辺の考え方がとてもいいなぁと思ったからだったりします。

ドッグフーディングの難しさ🐶

これはサービス次第ではあるのですが、トレタの場合は飲食店向けサービスなので、会社をやめて飲食店でも始めない限りまず使うことはありません。toCに比べて自分が使わないサービスというのは多い気がします。

この、ユーザーの気持になれないというところはとてももどかしく感じます。しかし、そこはプロフェッショナルとして要望を取り入れるだけでなく、ユーザーが思いつかない様な新しい価値を作り出していかないといけないと思っています。

とても難しい分、やりがいに繋がる部分でもあると思っています。

まとめ

ざっとtoBサービス開発の面白さについて書いてみましたが少しでも興味持って頂けたでしょうか。もちろん全てのtoBサービスがこれに当てはまることはないですし、結構トレタ寄りな話になってしまったかもしれません。

僕もそんなにたくさんのサービスを経験しているわけではないので偏ってる部分もあると思います。もし、うちではこうだよーとか。これは違うんじゃないかなぁ、とか意見があればコメント頂けるとうれしいです。

69
20
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
69
20

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?