Mobile Developer｜羽田 健太郎
新卒でヤフー株式会社に入社し、インフラのオペレーション改善や、iOSアプリ開発に従事。プライベートではハッカソンに参加したり、Go言語でWebサービス開発をしているマルチプレイヤー。2016年RareJobで唯一のMobile Developerとして入社し、ネイティブアプリケーション(iOS/Android)を担当。WebRTC技術を活用したサービス化のエンジニア責任者として、日本フィリピンを横断し、ブロダクト企画から開発、運用まで担っている。
降って湧いた大きな裁量
「羽田くん、Skypeなくしてよ」
月一の上長とのMTGでなんとなく言われたその一言。
しかも「プロジェクト化は、今のとこないんだけど。」と仰る。え？1人？？？
最初はとんちかと思って、
「iPhoneで屏風にskype出してVRでなんとかするアプリ」を作ろうと思っていたが、
どうやら私のボスは「10年レアジョブが使い続けたSkypeをなくせ」と申す。ウケる。
でも・・・目を見るとマジだし・・・、何か思惑もありそう。
世話になっているのでやれるだけ頑張ってみようと思った。
～～～ 4ヶ月後 ～～～
「Skypeを使わないWebRTCを使ったレッスン機能」を一部のお客様向けにリリースし、検証を始められました。100名規模の10年続いたベンチャーに転職して急に降って湧いた大きな裁量。
「スタートアップやベンチャーは裁量あるぞ！圧倒的成長！」みたいな話は吐いて捨てるほど巷に溢れてますが、あまり語られないその実像。
今回は泥臭くも、エンジニアとして工夫のし甲斐があった担当プロジェクトについてお伝えします。
そもそも
そもそもすでに裁量のある仕事をさせてもらえています。
上場企業においてアプリの領域を全て任されています、1年ほど働いてますが0からアプリを作り、
マーケ・デザイン・グロースをワンストップで担当しています。
50万人の会員がいるwebサービスのユーザーさんをアプリでもっと気軽に英会話できるように日々頑張ってます。
まだまだ至らない部分はありますが、しつこくアップデートしてテスト回しているおかげで、アプリからのレッスンの予約数をめちゃめちゃ増やしました。ほぼ自分で完結するプロジェクトなので、自分のコンディション以外にほとんどボトルネックのない改善を回せていました。
ヤバみ
そんな中で、急にサービスの根幹に手を入れる感じのオーダーを受けました。
新しいことをするのは好きだし、得意なんですが、今回やることは、
「古いものを新しくする、しかもそれはサービスの根幹」、まさに「ジェンガの一番下の真ん中に刺さっているやつを綺麗にする仕事」。しかもそれは10年かけて作られたジェンガでヤバい。
・Skypeを前提とした運用
・Skypeを前提としたDB Scheme
・Skypeを前提としたテスト
・Skypeを前提としたアプリケーション
・Skypeを前提とした営業・・・
人との調整も多分に予測される、特に弊社ではフィリピンと一緒に開発をしている関係上、
webの開発も入るし、新技術の導入だし、絶対国をまたいだ調整とボールの投げ合いが生まれるはず。
いかにうまくやろうともコミュニケーションの都合上、ボトルネックが生じるのでヤバい。
「仕様これでいいですか？」「デザインここ直せますか？」「数字出してもらっていいですか？」
「お話聞きたいのでご飯行きませんか？」「Salamat po…」
落ち着いて、冷静に全体を俯瞰して、やることを整理して、精神を落ち着かせ、向こう三ヶ月くらいの
タスクをシミュレーションしてみた結果。
やっぱりとてもヤバいことに気づきました。不意に投げられたボールのデカさに受け取ってから気づき、このころ「裁量」という字を見るたびにいろんな事を考えてました。今は「さいりょうだな」って思います。
整理するところから始める
整理することはとてもいいことです。把握と問題の抽出が可能です。
まずは「skypeをなくす」というオーダーを具体的な結果としてイメージするために、今のユーザーストーリーを整理して、変更後のストーリーを何パターンか考えました。
Lean User Story Template
https://medium.com/product-punk/lean-user-story-template-d3fdafe094df
色々な手法がありますが、下記の図のようにタイムラインに並べて何パターンか書いておくと、色々なユーザーさんを想定することができました。（雑な図ですいません、実物はもっと雑です）
これが整理できると具体的にどの体験に手を入れて、どんなユーザーさん達に影響があるのかを具体的に把握できます。
次にKPIツリーで、ファネルを見ました。
今までアプリの企画ベースでのファネルを見ることはしていましたが、改めてサービス全体のファネルをみて見ることで、「なぜ本登録率が低いのか？」「過去どうだったのか？」「繁忙期だとどうなのか？」など定性的な疑問が多く生まれ、「何を解決するべきで、それにはどの数値を目標に上げるべきなのか？」が明確になりました。
整理していく中で、Skypeをなくすことでインパクトのありそうな本登録/無料体験周辺のコンバージョンを追い、私の得意分野のスマホアプリから始める計画を立てました。
MVPを作る（数字）
最小限効果があることを検証するためのよく用いられる手法の一つにMVP(Minimum Viable Product)があるかと思います、説明は省きますが、自分が最もコントーラブルな領域でMVPを作ることで、
製品の価値を検証することが「↑数字を計測できる、最低限の製品を最短で作れる」と考えました。
ここで計測したい数値の落とし込み、観測にはre:dash を使い、既存のバックエンドツールやアプリケーションを汚すことなく、可視化と予約時のアラートを設定でしました。
既存のサービスにMVPを導入するとき、既存の要件をなるべく汚さず運用設計することはスケールを広げるためにも狭めるためにもとても重要だと考えています。
またアプリケーションとして実数値に落とすほどではないイベントログや検索結果の件数などの情報は、Flurry/Firebaseといった外部のツールに落とすことで、KPI設定している数値周辺の数値についても、あとから考察要素に使えるように準備をしました。
Firebaseを選択した理由の一つに、StreamViewがあります。リアルタイムにユーザーのイベントログを見ることができるので、「ユーザーさんがどこでどう詰まっているか？」などを考えるのに役立ちます。想像では限界もあるし実際のユーザーさんの環境で何が起きているかを知るのは重要です。
MVPを作る（モノ）
数字とストーリーを整理できたことで、いよいよプロダクトを考えます。
何と言っても早くリリースしたかったので、プラットフォームは私の主戦場であるアプリです。
これが一番プロダクト的に疎らだし、もしwebで対応する未来が来てもAPIを対応しておけば流用できると考えたからです。
サァ作るぞ！というとき、とりあえず実装から始めることが多かったのは昔の話。
設計をしっかりしておかないとやはり速度は出ません。
この時もユーザーストーリーを考えておくと、アプリでは仕様を考えやすいです。
ユーザーの行動を、そこから変化する状態をまとめておくことで、のちの設計やデザインに活用できます。
ここで抽出できた状態と、ストリーベースに画面のデザインをします。
何種類もプロトタイプを作るので、画面の抜け漏れが出がちなので何度もユーザーストーリーから抽出した状態を元に、抜け漏れない画面仕様を作りながらプロトタイプの実装までやっちゃいました。
また厳密に状態を定義していたことで、仕様 → デザイン → 実装への反映がスムーズに進んだと思います。MVVM + RxSwiftの恩恵を生かして、複雑な状態変化や追加に耐えれる実装を心がけました。
MVPを作る（ヒト）
数字が整理できて、製品が見えて来たので、デザインを作るちょい前から人を巻き込み始めます。
とりあえず協力してくれそうで強そうな人を入れてチャットを作ります。強い人は、とても強力です。
あとはかっこいい資料をシェアします。
元DeNAの強いPMの人とフィリピンの強い人を巻き込みました。
2人合わせて4回くらいしか喋ったことなかったですが、一緒に仕事してみたかったので呼んだら手伝ってくれました。
強い人を巻き込み、新しいことが好きそうな上司に一緒に話したおかげでトントン拍子でPJ化しました。これによりPMとなり、フィリピン側に講師側のWebRTCでのレッスン機能を作ってもらう依頼などができるようになりました。よかったですね。
MVPを作る（ヒト）
ヤバいと思ってましたが、ものづくりの流れはシンプルで
2. ストーリーに即してKPIを整理する
3. 新しい体験をここに入れて考える
4. 仕様（状態・行動）を抽出する
5. 強い人に頼む
6. 作る
というステップを4ヶ月くらいですごい勢いで実施して、「ジェンガの一番下の真ん中に刺さっているやつを綺麗にする仕事」が無事にローンチしました。講師側の開発でフィリピン行ったり、いろんな人を巻き込んだり紆余曲折はあったんですが、大変だったので美談にしたくなっちゃうので控えます。
今思い返せば、丸投げ 溢れんばかりの裁量がある状況というのはただ何もないわけじゃなくて、
意思決定一つで、協力してくれる優秀なメンバーを集められて、それを認めてくれるボスがいることだなーと考えさせられるプロジェクトでした。
エンジニアとしてマネージャになるというより、
目線高く事業貢献できるエンジニアリングプレイヤーになることを考えているのであれば、
自分のスキルの強い部分を武器にして様々なツールや仕組みを使いつつ、強い人を巻き込みながらプロダクトに貢献するのが楽しいと思いますし、そういうことができる環境に身を置くのが、エンジニアとして楽しくやれるんじゃないでしょうか。
幸いなことに100人規模はそれがうまい具合にできるいい感じのスケール感でした。
まだプロジェクトは始まったばかりですが、より本質的にユーザーさんの
英語学習体験をよくできるようなプロダクトの改善を今後も進めていきたいと思います。
