GitHub: @y0ssh1
 Twitter: @ysn514
 2021/01/21
 の新規事業部で を採用するまで

目次
 1. 自己紹介
 2. AppBrewについて
 3. 新規事業部について
 4. 新規事業①の話(iOSネイティブアプリ)
 5. 新規事業②でFlutterを採用した話
 6. まとめ


1.自己紹介
 名前: 吉野 克基(よしの かつき）
 
 Twitter: @ysn514
 GitHub: @y0ssh1
 Flutter歴: 1年程
 その他言語/FW: Rails,Swift,TypeScript,Kotlin
 趣味: バイク、猫、なろう系のアニメ鑑賞
 経歴: AppBrewでLIPS3年（iOS、Rails、レコメンド周りなど）
 → 新規事業部1年くらい（現在進行系）
 
 
 


2.AppBrewについて


2.AppBrewについて
 対象領域
 (サービス)
 エンジニア
 （社員）
 LIPS（プロダクトチーム）
 新規事業部
 アプリ(flutter)
 サーバ(Rails)
 web?
 インフラ
 アプリ（swift/kotlin)
 web(Rails)
 サーバ(Rails)
 セールス開発
 レコメンド基盤
 インフラ..etc
 
 
 （兼務しているので境界は曖昧） 
 アプリ・サーバ: 6名
 web: 1名
 セールス開発: 3名
 レコメンド基盤: 1名
 （採用中です!!）
 
 
 全部: 1 or 2名
 チーム
 色々とやらないといけない


3.新規事業部について
 ①仮説立案 ②MVPの開発 ③マーケ検証 ④仮説検証 ・いけそうな領域を探す ・リーンキャンバス書く ③ができるまでの状態をとりあえず目指す
 ・一ヶ月くらいを目処にストアに 出せるよう機能などを絞り開発 をする ・社内でドッグフーディングしつ つ ・ の審査が通らずに精神 が病むので強い気持ちをもつ ・ 広告などでいくつか訴 求を試してみて、ユーザーが獲 得できるかを見る ・ここで無理そう（ が悪 そう）なら などを改良する ・それでも無理そうならアプリの 情報設計を見直し ・いくつかの細かい指標はみつ つ基本は継続率を見る

4.新規事業①の話
 バチャリー 音声通話 カジュアルゲーム 米での のようなもの

4.新規事業①の話
 検証の流れ
 ①Web検証 （2ヶ月くらい） ②App(iOS)検証 (3ヶ月くらい) ③マーケ検証 （1ヶ月くらい） ④仮説検証 ・ で での体験版みた いなものを作った ・ はそこそこ低めであること を確認した ・継続率はそこまでないが にして通知やコンテンツがたま るような仕組みにすればいい かも？ ・継続率を上げるため、通知、 オンボーディング、通話周りな どを結構作り込んだ ・ゲーム部分は と使い回せ るように変更したりした ・運用型広告などでいくつか訴 求を検討してみたが のとき とあまり変わらず ・オンボーディングを入れるな どコンバージョン（ゲームをだ れかとやる）させるための仕組 みづくり ・訴求に合わせたゲームづくり など ・③があまりうまくいかずに、仮 説自体が良くなかったか、そも そも仮説に対して作ったものが 複雑すぎた ↑初期の開発だけで4,5ヶ月くらいかけてしまっていた 


4.新規事業①の話
 新規事業①での反省点
 - アプリリリースまでに時間がかかりすぎた
 - iOSのフレームワーク（PushKit/CallKit）周りを使うなどネイティブ側のFramework を結構使うなど作りこみすぎていた
 - Webのマーケ検証の結果を少し甘く見ていたのでアプリの初期機能を増やしすぎ た
 
 - Nuxt.js(ゲーム部分), Swift, Rails(+ WebSocketのSaaS)など人数に対していじるもの が多かった
 マーケ検証までの時間をとにかく短くしたい


5.新規事業②でFlutterを採用した話
 ポケトリ 旅行の 旅行の追体験ができるように 旅行記が投稿できる スポット単体の投稿もできる

5.新規事業②でFlutterを採用した話
 ①MVP開発 (2.3週間くらい) ・投稿一覧、位置情報詳細画面、投稿作 成画面、プロフィール など一般的な っぽい機能だけ付けてリリース ・データなどは さんの力を借りつつ 用意した ・リリース周りはそこまで躓くことなく、普通 に両 にできた（ には を使用） ・獲得自体は悪くないが継続率が低い ・新規投稿やそもそも蓄積されているコン テンツの量の問題かも ・インフルエンサーさんなどに頼み継続的 に投稿してもらうなどしてコンテンツを定期 的に流れるように 蓄積していく ・いくらか初期の旅行記の集めようとした が、お金を払ってもなかなか難しい ・コロナの影響でそれどころではなかった ②マーケ検証 ③仮説検証 (アプリが簡単というのはありつつ)2,3週間でiOS/Androidアプリを出せた!


5.新規事業②でFlutterを採用した話
 Flutterの採用理由
 - LIPS側でAndroidの開発がiOSに追従できず結構苦労しているのを見てきた
 - iOSで実装した細かいUI変更などは追従しなくていいか...という積み重ねがあった
 - クライアントサイドのビジネスロジックを両OSで合わせるのが辛い
 
 - Reactは特に明るくなかったのでReactNativeはプラクティスの肌感なく微妙かも？と 思った
 
 - 周囲でFlutterを採用している企業があった（困ったときに聞けた）
 
 - （話題だったので使ってみたかった（2019年12月くらい））


5.新規事業②でFlutterを採用した話
 Flutterを採用した感想(ポジ)
 - フレームワーク/Pluginによって両OSの差分が
 吸収されているのが良い
 - 通知: FCMのpluginによって通知許可(iOS)なども取れる
 - 写真選択: image_pickerナド
 - キーボード: viewのpaddingとして扱われる
 - SafeArea: Widgetになっており宣言するだけ
 
 - デフォルトのコンポーネント（Widget)などが
 豊富でUIの開発効率が高い（ハーフモーダルが楽）
 https://tech.appbrew.io/entry/2020/12/08/004043
 
 - アーキテクチャで迷うことが少ない
 - 状態管理やbindingなど、provider、state_notifier、
 riverpodなど使っておけば問題はないという感じはある
 
 


5.新規事業②でFlutterを採用した話
 Flutterを採用した感想(ネガ)
 - Dartそのものがちょっとつらい（コード生成系でどうにかなることが多い）
 - そろそろnull-safeがstable 
 - Kotlinのdata classがほしい
 - enumにassociate valueがほしい
 - enumのコンパイル時の網羅性チェックが効かない
 
 - 新しい良いpluginとか数ヶ月くらいのスパンで出たりして忙しない
 （一旦落ち着いた気もする...?)
 
 
 
 
 
 
 


5.新規事業②でFlutterを採用した話
 お困りポイント: グルーピングなどをカスタムした写真選択画面がほしい...
 https://pub.dev/packages/multi_image_picker 近いものはあるが足りない↑


5.新規事業②でFlutterを採用した話
 お困りポイント: グルーピングなどをカスタムした写真選択画面がほしい...
 A.写真データのみを取得するインターフェースを自作する
 https://pub.dev/packages/image_picker https://tech.appbrew.io/entry/2020/07/14/121431 Android赤ちゃんでもネイティブ部分を参考にしつつ...

6.まとめ
 - Flutterを使うとUIの開発が（MaterialDesignに従うという前提のもと）楽になる
 
 - pluginも豊富なので直接ネイティブ側を触ることはあまりない
 - Firebase: 基本的にはPluginあり
 - WebRTC: SkyWayは公式のpluginなし、Agoraというのがあります
 
 - 仮に自作のpluginを作るとしてもネイティブのAPIをちょっと調べる or 既存のライブラリ を参照すればどうにかなる
 
 - ネイティブのFrameworkに頼るとかでなければ基本的に困ることはない（はず）
 
 相当ネイティブのAPIに依存するとかでなければFlutter使いそう 


No content