創業1年目のスタートアップがIonicを採用した方が良い5つの理由

株式会社キネカ 共同創業者 CTOの竹口です。開発ブログ第一弾は弊社で採用しているIonicについて、なぜ創業1年目のスタートアップに適しているのか、結局採用して良かったのか、について語ります。

はじめに

結論、Ionicを採用して大正解です。スタートアップでアプリを0→1で立ち上げるならIonicを採用する価値は大いに有ります。

理由は後ほど書くとして、まずは会社概要・自己紹介から。

株式会社キネカ

「新しい当たり前を作る」というビジョンのもと、エンタメ版Uber「pato」やメディア事業、アプリ事業を展開する会社です。現在、新たなマッチングアプリやメディア事業などの新規事業を運営しており、2022年上場と時価総額1000億円企業となることを当面の目標としています。

創業して約1年半、メンバーは先月40人を超えました。「スタートアップは思い出づくり」「事業づくりは仲間づくり」という言葉を大切にしていて、オープンコミュニケーションでポジティブなチームです。

3ヶ月に一度行われるキネカ合宿

エンジニアは10人で、一人で事業を立ち上げられる技術力と自走力を身に付けるため、全員がフルスタックに開発を行なっています。

採用技術

iOS・Android・Web技術 — Ionic、Angular、Cordova
コミュニケーションツール — Slack、GitHub、ZenHub
サーバーサイド言語・フレームワーク — Ruby on Rails
データベース — Cloud SQL（MySQL）、BigQuery
インフラストラクチャ — Redash、Redis、Google Cloud Platform・Firebase各種サービス（Compute Engine、Cloud Storage、Cloud SQL、RealtimeDatabase、Cloud Functions、Firebase Hostingなど）
その他 — CircleCI、Git

wantedlyのfeedも合わせて見ていただけると！

https://www.wantedly.com/companies/company_1138164

自己紹介

• 早稲田大学大学院情報理工学専攻にて言語理論を専攻。
• 2014年DeNAに新卒入社。５つの新規事業（アプリゼミ、SHOWROOM、Dengbel、Pinnote、アプリゼミ幼児版）を経験。
• 2016年7月にDeNAを退職、2017年1月株式会社キネカを共同創業

DeNA時代に数十の新規事業が立ち上がり死んでいく環境の中で、リーン開発のノウハウを叩き込まれました。最高の環境でした。

キネカを創業してから二つのアプリを立ち上げ、現状どちらもPMF（Product Market Fit）に達しつつあり、0→1の立ち上げに成功したように感じています。

IonicはDeNAのときにv1の導入経験があるのと、キネカ創業時から使用しているため、2.5年ほどproduction環境での運用を経験しています。

0 →1の立ち上げを極めたい系エンジニアです。

「0→1を立ち上げるとはどういうことか」についてはまたどこかで書きたいと思います。

Ionicが適している状況

新規サービスを開発する状況下で以下の5項目に当てはまるかを確認してみてください。多いほど、Ionicでの開発が優位になりやすいです。

1. 開発スピードが強く求められる
2. PMF（Product Market Fit）までは高機能にならない
3. パフォーマンス要求が低い
4. アプリの申請リスクが高い
5. マルチプラットフォームで開発する必要がある

見ての通り、1~3までは多くのスタートアップに当てはまる項目ではないでしょうか。4、5についてはサービスのドメイン依存ですが、弊社のアプリではどちらも当てはまります。

一つ一つ深掘ります。

開発スピードが強く求められる

スタートアップはスピードが命です。いかに検証を素早く回し、ピボットを繰り返して、PMFまで最速でたどり着くかが勝負の分かれ道です。そのスピードという観点でIonicは大きく貢献します。

その理由は、IonicはLive Deployが可能だからです。現在は前よりもストアの審査速度が早まっており、数時間で完了する場合もあります。しかし、スタートアップにとってこの数時間が命取りになります。申請にかかるコストも決して軽くはありません。1時間でも惜しい、と考えるべきです。

競合のどこよりも早くユーザーのニーズを発見すること、これが最重要です。

PMF（Product Market Fit）までは高機能にならない

Ionicはネイティブの機能をフル活用するようなサービスには向いていません。ネイティブの機能を使用する場合、CordovaのPluginを探すもしくは作る必要がありますが、これは経験上とてもとても深い闇になる場合が多いです。

リーン開発では、ネイティブの機能をフル活用しないと開発できないようなMVP（Minimum Viable Product）にはほとんどなりません。そうなっているのなら、本当にその機能が必要か？別の検証手段はないか？を再検討した方が良いかもしれません。それほど初期プロダクトはコアバリューを含む最小限の仕様に留めるべきです。

パフォーマンス要求が低い

WebView上で動作するIonicはネイティブアプリと比べるとどうしてもパフォーマンスが低下します。しかし、リーンで開発する場合これは無視できます。

サービスのリリース初期はコアバリューの検証・ピボットが最重要です。コアバリューがターゲットに刺さっているならば、パフォーマンスが低くてもユーザーは代替手段がないため離脱しません。離脱する場合、コアバリューへたどり着いていないか、コアバリューが正しくないのでしょう。パフォーマンスが離脱要因になる場合はピボットの必要があるかもしれません。

反対にPMF以降はパフォーマンス要求が必然的に高くなります。その時、ネイティブへの書き換えは十分に考えられます。PMFに達したということは一定の競合優位性が存在し、多くの機能はFIXに近づいている、という状況なはずです。ピボットを繰り返した結果汚くなったコードを解消しつつネイティブ化するのはとても良い選択肢だと思います。

アプリの申請リスクが高い

弊社が運営するエンタメ版Uber「pato」はCtoCという特性から、申請した時のリジェクトリスクが大変高いです。1日で通過することもありますが、過去最大で2ヶ月ほど申請に時間を費やしたことがあります。

これはCtoCというドメイン依存の課題ですが、IonicによるLive Deployのおかげで申請回数を減少させることができています。申請のリスクが大きい場合、Ionicは大変有用です。

マルチプラットフォームで開発する必要がある

iOS、Android、Web全てをIonicはカバーしています。ネイティブ関連のコードで稀に共通化できない部分はあるにしろ、9割近くのコードが共通化できています。

通常リーン開発の場合、初めからマルチプラットフォームにする必要はない場合が多いです。しかしサービスの特性上その必要がある場合、リソースの少ないスタートアップではネイティブでiOS、Androidを書きつつWebを作るのは不可能に近いため、コードを共通化できることは大きな利点になります。

さらにIonicはPWAをフルサポートしており、即座にPWA化できるという利点もあります。

Ionicコミュニティが活発

Ionicの日本コミュニティはとても活発です。初心者に優しく、気軽に質問でき、レスポンスが大変早いです。いつも本当にお世話になっています。

• connpass：https://ionic-jp.connpass.com/
• slack：https://t.co/K9slM8tvi8

まとめ

Ionicはまだまだ日本で広まっているとは言えないかもしれませんが、スタートアップかつリーン開発においてとても有用なフレームワークです。

XamarinやFlutter、React Nativeなど、他のマルチプラットフォームフレームワークとの違いはまた別途記事にしていきたいと思います。簡単にいうとIonicのみWebViewベースのフレームワークである、というところです。

Ionicの運用経験が2.5年を超えてきたので、今後も一つ一つのノウハウをこの開発ブログにアウトプットしていこうと思います。今後ともよろしくお願いいたします。

一緒に1000億目指すエンジニアを募集中！！

株式会社キネカでは一緒に上場・1000億企業を目指す仲間を常に探しています！道中を全力で楽しみつつ、世の中にない新しい当たり前を一緒に作り上げましょう。

少しでも興味ある方は渋谷にあるオフィスに是非遊びに来てください！！

お問い合わせ先：sys@kineca.jp