FOLIOに転職してからAndroidアプリリリースまでの出来事（日記）

FOLIO Advent Calendar 2018 15日目の記事です。 昨日はむらみんさんのFOLIO を支えるエンジニアリング組織の七転八倒記: 2018年冬でした。

転職してからAndroidアプリのリリースまで2年くらい経過したので、起きたことや開発体制とかをざっくり振り返ろうと思います。

現在、FOLIOのAndroidアプリの開発者として働いています。 僕が転職したのは2016年8月で、FOLIOのアプリの正式リリース日が2018年8月8日ということで、転職してからアプリをリリースするまでにだいたい2年かかりました。 その2年を箇条書きと補足で時系列順にまとめます。（日記です）

2016年8月：転職

  • FOLIOという証券会社を立ち上げるということを聞いた
  • 「独立系オンライン証券では日本で10年ぶり」とか、当時10人くらいのメンバーのうち4人くらい知り合いがいたとか、その他諸々の理由が重なり転職を決意した

転職はかなり悩んで決めました。

前職では4000人くらいのメガベンチャーで働いていて、チームの方達がとても強く、界隈でも有名で、尊敬できる方達に囲まれていたし、作っているプロダクトもとても楽しかったので、特に辞める理由はなかったです。 当時、辞めた理由をたくさんの人に聞かれましたが、ネガティブな理由は僕は一切なかったです。

2016年8月：Android開発できない問題

  • Web優先
    • Webの開発が進んでいなくそちらを手伝うことになった
  • 週1のアプリ企画MTGも消滅
    • 希望が完全に途絶えた瞬間

金融という難しい分野でまだまだ改善の余地のあるアプリが世の中にはたくさんあると感じていました。FOLIOに転職した直後、自分の中には「お手本になるようなアプリをつくる」という目標がありました。（かなり上から目線な目標・・）

前職ではデザインにこだわり、ユーザー体験をかなり重視した開発が当たり前だったので、世の中のこの分野のアプリの質はもう少し改善の余地がるように思っていました。

しかし、Webの開発が進んでいなかったので、Webを手伝うことになり、そこから1年くらい全くAndroidには触れない日々が続きました・・（「FOLIOのAndroidアプリを作って欲しい」と言われ採用され、Androidやっていくぞと意気込んでいただけに、この出来事がFOLIOに入ってから一番ショックでした😭😭😭）

2016年8月-2017年1月：Web開発の日々

  • 口座開設や設定画面のフォームやバリデーションを作る日々
  • 日本の郵便番号や住所のルールに少し詳しくなった
    • 番地が同じでも複数のビルがある場合がある（例えば、建物名省略して部屋番号だけ入力されても、一意に特定できない）
    • 番地は数字とハイフンとざっくり思っていたが、甲乙丙丁を代表に、数字以外が入ることもある
  • 住所や名前のルールをしっかり決めてほしいと5億回くらい思った
  • React,Reduxでナウい開発を経験できた
  • FlowやTSもなしで、大規模な開発をするのはとても辛かった（もともと厳密な型の世界で生きたい派の人間なので）

基本的には、口座開設処理全般とユーザー情報の変更や忘れた時の画面などの、入力フォームがあるところをメインで触っていた気がします。

日本の戸籍のシステムとか、文字コードの闇を見ました。 マイナンバーは個人に紐づくのではなく、住所に紐づくと知ったのもこの時期です。

この期間は、自分のJS力の低さと日本の戸籍のルールを呪っていました。

2017年2-3月：かなり忙しい時期

  • 年末から個人的なタスク（本の執筆）があった
    • 執筆期間がそもそもかなり短くて :tofu_on_fire:
  • WebのQA期間が始まり、約週1で新しい画面や機能のQAがあった
    • 約週1というのは3-5日に一度QAなので、最悪1週間で2つくらいの機能を完成させて、バグ修正しないといけなかった
    • 今思うと無謀すぎるスケジュールだった

結果として、当然間に合うわけもなく、QAのスケジュールを調整（テスト実施順番を入れ替え、延期など）するのに無駄に工数を使っていたと思います。

やはり、このようなギチギチのスケジュール組むのは精神的にもよくないです。（当たり前）

2017年4月：初のiOSエンジニア入社！

  • iOS強いマンが参戦
  • 自分はまだWebを開発していたが、iOS先行で開発がスタートした
  • ざっくりスケジュール見積もりをしたら、479人日だった
  • D(Design)プロトタイプ、F(Functional)プロトタイプ
  • 目標を各ストアの「Feature枠に乗る」「賞をとる」に設定した

iOSの杉上さんが入社されて、本格的にアプリ開発がスタートしました。

FOLIOでは、スケジュール見積もりは松竹梅で考えることが多いです。 アプリチームの見積もりではこんな感じで見積もりをしていました。

  • 松案
    • アニメーションにもこだわる
  • 竹案
    • 少し簡単なアニメーション
    • 優先度の高いBETTER要件も含む
  • 梅案
    • MUST要件
    • どうしても譲れない部分のこだわり

バッファも考慮して見積もると、松案が479人日、梅案が355人日。 一人が一日も休みなく働いて松案が約1年4ヶ月、梅案が約1年という予測でした。（無理です🙅‍）

WebViewで対応できそうな部分はそれで対応するとしても、さすがに1年は時間がかかりすぎるということになり、人数を考慮した見積もりを行い、採用方針やリリース時期を決めていきました。

（人数を増やした場合は単純に割り算するだけでなく、コミュニケーションコストを考慮し、全体の工数も多めに調整していました）

また、梅案でも開発が間に合わないという話になり、苔案というのも一部で誕生していました。 そして、どうしても譲れない部分のこだわりというのは意外と譲れることが多いです。デザイナーが絶対にこれを見せたいと言っていたアニメーション（僕は要らないと思っていたもの）も、今思うと必要なかったよねとお互い納得しています。

iOS先行でアーキテクチャの選定とプロトタイプの実装を開始しました。 プロトタイプはFプロト、Dプロトという2段階で定義し手を動かしていきました。

  • Fプロト
    • フィーチャーベースのプロトタイピング
    • スケッチングによるブレスト
    • 全画面遷移の洗い出し
  • Dプロト
    • デザインを作っていくプロトタイピング
    • Sketchによるビジュアライズ

Fプロトの段階では紙で書いてProttに取り込み画面遷移の確認などをおこなっていました。

Dプロトの段階からiOSアプリの実装も並列で行うフェーズになりました。
この段階ではAPIを作る余裕がなかったため、Swaggerを使ってモックデータを用意し、開発を行っていました。
Swaggerによる開発は2017年のDroidKaigiで発表したので、そちらをご覧ください => まだAPI定義管理で消耗してるの？〜Swaggerを用いた大規模アプリ時代のAPI定義管理とコードジェネレート〜

個人的には入社直後から目標にしてましたが、チームとして「Feature枠に乗る」「賞をとる」という目標を設定しました。 もちろんそれ自体が目指すべきゴールではないですが、そういうアプリは少なくとも使いやすく、しっかりと作り込まれたものが多いと思うので、そのような目標をたてました。 GooglePlayでいうと、おそらく証券会社でこれらを達成したアプリを僕は見たことがないので、そこを目指していました。

2017年6月：Androidの開発開始

  • 技術選定
  • モックデータとのつなぎ込み、画面実装スタート

アーキテクチャはFlux（正確にはFluxベースに少し手を加えたナニカ）を採用しました。前職でも使ったことがあり、1方向に限定したデータフローはとてもわかり易く、Storeの状態を監視しリアクティブなViewの更新はリアルタイム性が求められるアプリととても相性がいいと思ったからです。（現状リアルタイムなものはそこまで求められていないけど・・）

iOSの技術選定やプロトタイプの実装スタートしていたので、Androidは2ヶ月遅れのスタートとなりました。

2018年7月まで：ベータリリースへ向けた開発

  • Androidの進捗の巻き返し
  • 開発のピークをQA直前よりもちょっと前にずらす
  • 複雑すぎる仕様による戻りの多さ
  • テーブルカンバンでタスク管理

この頃には、Androidが3人、iOSが5人、BFFが1人、デザイナーが1人、ディレクターが1人と合計10人ほどのチームになっていました（ついにリリースされたFOLIOアプリ！細部までこだわったアプリはどんなチームから生まれた？）。 FOLIOアプリチーム

Androidの方が人数が2人少ないにも関わらず、当初2ヶ月遅れでスタートした開発の進捗はiOSを追い越していました。 そこで、Android+BFFが先に実装を行い、地雷を踏み抜き、iOSチームは比較的安全な平地を歩いてもらう作戦で開発を行っていました。（※地雷を踏み抜く＝デザインや仕様の漏れ、再検討したほうがいいことなどを実装しながら探していくこと。また、そのさま。）

QA直前に開発のピークを持ってくると辛いのは1年前に経験していたので、意図的にピークをずらしました。仕様が複雑過ぎて、QA期間もかなり長く、春くらいが一番開発のピークでした。

FOLIOの仕様はかなり複雑で難易度の高いものでした。戻りや漏れも多くてかなり実装に時間がかかっていました。

これは開発途中のとある画面でのエラーパターン表です。（ぼかしているのでほぼ何もわからないｗ）

エラー表

各銘柄の値動きやコーポレートアクション（株式分割、株式併合、株式移転・交換、合併等）、それら銘柄の組み合わせ、取引時間、ユーザーの購入金額などなど、ユーザーはほぼ見ないであろう画面の開発に一番時間を費やしていました。

また、細かい仕様の漏れ・デザインの変更があり誰ボールなのか分からないことも多くなってきた＆デザイナーの隣に座っていたということもあり、お互いのテーブルの境界に付箋を貼りあっていました。 付箋にはタスクを書き、依頼するときは相手のテーブルに貼り付ける。終われば依頼者の机に戻すという感じです。 これをテーブルカンバンと呼んでました。意外とよかったです。

  • ボールの所有者が明確になる
  • 口頭で伝えるだけでは忘れることもあるがそれを防げる
  • オンラインでチケットを作るより楽（チケットを作るのは意外とコストがかかる）

テーブルカンバン

2018年7月23日：ベータ版リリース🎉

  • FOLIOのアプリをこっそりリリースした日

実はリブランディングを行うということが決まっていたのでこっそりリリースしました。 リリースしましたがここで落ち着くことはなく、別ブランチで新しいデザインへの移行を行っていました。

2018年8月8日：正式リリース

  • リブランディングにより、新しいデザインへ移行

1年ちょっと開発したものがリリース後数日で、リブランディングを行い、見た目ががっつり変わりました。

リブランディング後のアプリはよりワクワク感が出ていると思います。

FOLIOのリブランディングに関してはこちらの記事にまとまっています=>FOLIOリブランディングの裏側 ──構想からリリースまでの8ヶ月の軌跡──

リブランディング前後のアプリの比較 ※画像内の金融商品・データは、デザイン紹介のためのサンプルです。

リリースしてから今まで

  • モバイルBFFの開発もアプリチームに
  • 追加機能の開発中
  • GooglePlayのベストオブ2018

リリースまでは、専属のエンジニアがBFFを開発していましたが、今はアプリのエンジニアが開発を行っています。FOLIOのモバイルBFFはかなりアプリの画面に依存した単位で開発されていてるため、コミュニケーションが必要なく効率的に開発できます。（ただ、この方向性は限界を感じており、個人的には将来的に変えていきたいです。N=1ですが。）

そして、つい先日、転職時から言い続けていた目標を達成しましたー🎉 わーいわーい🎉🎉

「Google Play ベスト オブ 2018」ベストアプリとベストゲームを発表

FOLIOのAndroidアプリはGooglePlayのベストオブ2018の「隠れた名作部門」の大賞をいただきました。

おそらく証券会社としては日本初だと思うし、金融という難しいドメインの中で使いやすいアプリ(少なくとも使いにくいアプリではないと判断されていそう)だし、このアプリが知られて他の証券会社や金融機関に参考にしてもらえれば嬉しいなと思っています。

アプリのエンジニアがAndroid,iOSのそれぞれ1人ずつしかいなかった時期からかなり成長し、リリースまでこぎつけました。 個人的にはかなり難易度の高い開発要件に挑戦できたのはとても身になったと思いますし、証券会社の中では一番使いやすいアプリになっていると思っています。

そのアプリが賞をもらえたことは本当にありがたいことだと思います。 （また、前職の上司と同じ舞台にあがって記念撮影したのはとても感慨深いものがありました😭）

まだまだ限られたリソースの中で開発するものはいっぱいあるし、 表彰式でもコメントしたのですが、ぜひ来年は隠れない方の部門で表彰されたいと思います！

アモーレ、FOLIO!!

明日は、前職の同期であり、FOLIO立ち上げ時の唯一のインフラエンジニアで、現在SREとして活躍している@yasuharu529の「docker stop で別のコマンドを実行する」記事です！お楽しみにー！

Google Play ベスト オブ 2018大賞受賞者