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

オールアバウトTech Blog

株式会社オールアバウトのエンジニアブログです。

サービス成功のためにチーム開発でエンジニアができること

こんにちは、オールアバウトの筋トレエンジニア芸人の@musclemikiyaです。 普段はCafeSnapというiOS/Andorid向けのネイティブアプリの開発を行っています。 このアプリは大手チェーン以外の個性光るオシャレカフェの情報が満載なアプリですので、ぜひ使ってみてください。

さて、今回はサービスの成功可能性を高めるために、エンジニアがどのようにサービス開発に関わっていくかです。 エンジニアのサービスへの関わり方は様々だと思いますが、今回はよりサービス運営に近い立場のエンジニア(チーム)を想定しています。

※チームの規模やフェーズによって当てはまらないこともあるので、一意見として参考にしていただければと思います。

コードを書く時間の最大化 ≠ サービスの成功

サービス開発をする上でエンジニアの重要な役割は、コードを書いて機能を実装することだと思います。 そう考えると、コードを書く時間を最大化するのが一番の近道のようにも思えます。もちろん、コードを集中して書く時間は必要です。しかし実際はそれだけだとうまく いかないことが多いように思えます。それはなぜでしょう?

CafeSnapではチーム全体でユーザーやプロダクトの課題を考えることを非常に重視しています。 大きなチームでは全員で課題を考えるのが難しいこともあるとは思いますが、それぞれの与えられた領域の課題を考えるというのは非常に重要だと考えています。

エンジニアが課題から考えるメリット

なぜエンジニア含め、チーム全体で課題を考えることが重要なのでしょうか? いくつかメリットを見ていきたいと思います。

メンバー間で認識のすり合わせに時間がかからない

「Aの機能を実装して下さい」と言われるのと、「ユーザーはXという課題を抱えていて、それを解決するためにAという機能を実装します」というのでは、実装に入る時のイメージが変わりますよね。 さらに、課題を考えるプロセスにも参加しているので、実装しながらエンジニア自身で考えて機能を調整できるようになるはずです。

課題に対して適切な技術選択ができる

エンジニアが課題を考えるプロセスに参加することで、課題を考えると同時にその課題に対してはどのような解決手段があるかをイメージできます。

ここでは、あまり実装方法などを考え過ぎない方が良いでしょう。課題検討中に実装方法を考え過ぎると「それは難しそうだからできない」などといったネガティブな議論につながってしまうこともあります。 課題を考える初期段階では技術については置いておき、ある程度議論が進んだ段階で考えるなど切り替えも必要です。

成果物の質が上がる

これは個人差がある部分かと思いますが、UI/UXやコードの品質が高まってくるということがCafeSnapエンジニア内では起きました。課題をきちんと理解することで、ユーザーがどのように使うのかイメージできるようになったからだと考えています。特にエンジニアがUI/UXの調整にも深く関わるネイティブアプリの場合は、この部分でお互いが指摘し合う時間を減らすことが開発スピードを上げる秘訣にもなります。

チーム内で摩擦が起きにくい

開発をする上で色々な手法は存在しますが、チームでの開発がうまくいかなくなる原因の大半が人間関係だと思います。エンジニア以外の人が企画を考え、エンジニアが実装するだけの関係の場合、 必ずお互いに不満が生まれます。課題を全員が共有することで、方向性が揃い議論もスムーズに進むようになります。

ほんの一例を挙げてみましたが、少なくともエンジニアのチームに1人は課題を理解している人がいることで、開発のスピードは大きく上がります。

課題を発見するには

ではエンジニアが課題を見つけるには何が重要なのかを見ていきます。 ここでは3つ例を挙げて説明します。

1. 実際にサービスを使う

f:id:allabout-techblog:20160913175848j:plain

大前提として、自分たちが開発しているサービスを全く使わずに課題を考えることは不可能と言っても良いかもしれません。 漠然と数値を眺めていても課題は見つかりにくいもので、実際に使った時に感じたことを元に仮説を立て、数字と照らしあわせて課題を洗い出します。 CafeSnapチームでも普段のランチではアプリを使って恵比寿周辺のカフェを検索し、カフェ写真を投稿しています。

気をつけなければいけないのは、自分たちがユーザー目線でサービスを使っているつもりが、いつの間にか運営目線になってしまうことです。 課題を見つけるときは、常にユーザー目線なのか運営目線なのかを意識して切り替えることが重要です。

2. 数字を見る癖をつける

f:id:allabout-techblog:20160819152346j:plain

実際にサービスを使って課題の仮説を立てた場合、必ずその仮説がどの数字に当てはまるかをチェックする必要があります。また、毎日決まった数値を見ることによってユーザーの小さい変化にも敏感になることができます。そのためには、数字を見るハードルを低くするための仕組みづくりも重要です。

CafeSnapでは主に2つの方法で数字を常にウォッチしています。

GoogleAnalytics(以下GA) + スプレッドシート + アドオン

アプリのスクリーンビューやアクションを計測したり、ユーザーセグメントごとのコホート分析などを使って継続率を測ったりしています。スプレッドシートのアドオンを使用して、毎日決まった時間にGAの数値をスプレッドシートに反映し、毎朝前日までの変化をウォッチしています。

本番DataBase(MySQL)+ re:dash

re:dashは最近広まっているBIツールの一つですが、GAでは取得できない値を本番のデータベース(MySQL)やアクセスログをBigQueryにエクスポートしたものなどから 取得してグラフ化したりしています。

3. ユーザーインタビューを実施する

ここでは詳しく説明しませんが、Wantedlyの仲さんが下記の記事でも書いている通り、 ユーザーインタビュー(ユーザーヒアリング)は、あくまでも答え合わせだと思うとよいでしょう。
ユーザーファーストの嘘

しかし、実際に自分が作っているサービスのユーザーに直接会うというのは、様々な発見があったりフィードバックがもらえるので、 開発するモチベーションにも大きく影響します。CafeSnapでもエンジニアが積極的に企画のメンバーに同行しています。

まとめ

ここまでエンジニアがサービス成功のためにチーム開発でできることについて見てきました。どれも簡単にできそうなものですが、案外エンジニアとしてコードを書いていると受け身になっていたり、サービスの成功を最優先に考えていなかったりすることがあります。
今回紹介したのはほんの一例ですが、エンジニアとして何ができるかを常に考えながら、良いサービスになるよう日々取り組んでいきたいですね!