Diverse developer blog

株式会社Diverse(ダイバース) 開発者ブログです。

かいはつ室のこれからの歩み

youbrideのリードエンジニア→かいはつ室のかいはつ室長になった@SAMUKEIです。

 

普段はサービスの話が多いのですが、今回はDiverseの「かいはつ室」という事業部についての話になります。

さて、いきなりですが、「かいはつ室」というのは、あまり聞き慣れないですよね?まずは簡単に説明します。

 

「かいはつ室」とは?

  • インフラ管理、エンジニア採用などプロダクトを横断的に作業が発生するものを見る
  • 突発的に発生するLPのマークアップなど
  • 開発部隊の居ないプロダクトの運用保守
  • 名前が「ひらがな」なのは可愛いからʕ•̫͡•ʔ

 と、Diverseにとって大事なことをやっています。

 

かいはつ室の立ち位置としては、各事業部と横並びになります。

f:id:SAMUKEI:20190902170608p:plain

 

組織変更により、私が室長になりメンバーも増えることになりました。

そこで、かいはつ室の役割の曖昧だった部分を明確にし、今後の歩みを決めるために行ったことをお話します。

 


 

最初に取り掛かったのは、「かいはつ室はやることはなんとなくは決まっているけど、ふわっとしていた」という点で、本来あるべき役割を明確にすべく定義する必要がありました。

かいはつ室の本来の役割

Diverse・サービスの成長のためには、サービスの価値を高め、「強いプロダクト」にすることが必要です。

ただ、プロダクトだけを優先すればサービスの価値が上がるわけではありません。

 

f:id:SAMUKEI:20190830102038p:plain

 

プロダクトチームだけでは優先度が低くなってしまうISSUEを解決するということが必要になります。


f:id:SAMUKEI:20190829200942p:plain

 

サービスの価値を高めるには、「運用・保守」「データ分析」「インフラ」などそれぞれも優先度を高く取り組んでいく必要があります。そこを「かいはつ室」の役割として、再定義を行いました。

f:id:SAMUKEI:20190829201308p:plain

  

これからの歩み

次に歩みを進めるために、それぞれの役割をグループとして明確に設定しました。

■ グループを定義 

  • SREグループ
  • プロダクトサポートグループ
  • マークアップグループ
  • 分析グループ

ただ、これだけではやっていること変わらず名前をつけただけになります。

そこで、ミッションを明確に設定しました。

■ ミッションを設定

かいはつ室のあるべき姿からミッションを考え 

f:id:SAMUKEI:20190829200741p:plain

と定義しました。しかし、これで終わり。だと絵に描いた餅です。

次にミッションを達成するための道筋を定義しました。

■ ミッションを達成するために何をやっていくのか?

3カ年の計画をし、達成のため着実に推進しています。

現在は、サービスをスケールさせるための土台強化に取り組み、オンプレミスからAWSへの移行作業をSREグループの最大の目標として進めています。

 

■ 最後に・・・

 20年の運用実績があるサービスをさらにスケールさせるチャレンジ一緒にコミットしてくれる人を大募集 しています!

 

herp.careers

 


 

興味は湧いたけど応募はちょっと・・・という方は、@SAMUKEI にお気軽にDMやリプライをください!

まずはご一緒にご飯を食べにいきましょう!! 

 

 

 

 

 

 

DiverseはiOSDC Japan 2019に初めてゴールドスポンサーとして協賛します

こんにちは、広報の山崎です。

iOS関連技術をコアのテーマとした技術者のためのカンファレンス "iOSDC Japan 2019"が、今年も早稲田大学理工学部西早稲田キャンパスにて開催されます。

Diverseは本カンファレンス初めてゴールドスポーンサーとして協賛するほか、弊社エンジニアも登壇します!ぱちぱち

今回はDiverseがどんなことを行うのかご紹介させていただきます!

ブース出展

f:id:incheon-special:20190903191039j:plain

(※写真は製作途中のものです)

ブース出展します! 

マッチングアプリをより身近に感じてもらえるよう、データから見えてきた「写真だけでモテる㊙︎テク」が分かるクイズ等を実施する予定! みなさんとマッチングアプリに関するリアルなお話もさせてもらえたらうれしいです!

クイズやアンケートに参加してくださった方全員に、感謝の気持ちを込めてささやかですがDiverseオリジナルノベルティをプレゼントしますぜひ覗きに来てくださいね 

登壇者 

f:id:incheon-special:20190903173229j:plain

弊社から1名がトークセッション登壇します 

  • 登壇者:今泉智博 @imaizume(マッチングアプリPoiboy iOS版開発担当
  • 日時:2019年9月7日(土)10:30〜  Track Dレギュラートーク
  • タイトル:スナップショットテスト実戦投入
  • コメント:アプリの開発で、条件ごとのレイアウト確認や意図しない表示崩れに苦労した経験はありませんか?スナップショットテストを使えば、XCTestでスクリーンショットの撮影を行い、さらに表示崩れも自動で検知してくれます。本トークでは、概要から既存プロダクトへの導入時にハマったポイント、ちょっと便利なTipsまで、あなたのプロダクトへのスナップショットテスト導入に役立つ情報をまるっとお届けします!

当日はぜひトークセッション並びにDiverseブースまでお越しください ♪

たくさんの方にお会いできるのを楽しみにしております ^^

f:id:incheon-special:20190903195810j:plain

Diverseブースは緑のバックパネルが目印です!

 おまけ: トークンは 「#出会いのプラットフォームDiverse」 です。

Flutter Meetup Tokyo #10で歴史あるプロダクトにFlutterが採用されたお話をしました

実は最近はAndroid開発に戻りました、 id:kikuchy です。

去る7/16に開催されたFlutter Meetup Tokyo #10にて、19年もの歴史がある弊社のサービスyoubrideにてFlutterが採用された話をさせていただきました。

flutter-jp.connpass.com



発表資料はこちら。


以前にこのブログで紹介させていただいた内容よりも、もう少し突っ込んだ内容をお伝えすることをテーマに色々詰め込んでみました。

developer.diverse-inc.com


結果として、設計の話からエンジニアが備えていると良い能力までと話題が盛々になってしまいましたが、
プロダクションでFlutterを採用したいあなたのお役に立てれば幸いです。



まだFlutterがプロダクションで採用されるのが一般的になるまではもうしばらく時間がかかるかな、と勝手に思っていたのですが、意外とあちこちの企業さんでFlutterを採用し始めている(世に出ているかどうかは別)、というお話を聞いてかなりの衝撃を受けました。



FlutterのDeveloper Experience (DX) は目を見張るものがあります。
HotReloadをはじめ、マルチプラットフォーム対応、豊富なデフォルトのWidget群、宣言的なレイアウト作成、賑わっているエコシステムなど…
安定性やパフォーマンスについてはまだ疑問の余地があるかも知れませんが、単純なアプリの場合はそんなに問題にならないケースも多く、むしろ慢性的にエンジニア不足な状態に対する一つの解決策として、多くの方にとって魅力的なものだと思っています。

今後はDartの文法改善、FFI対応、PlatformViewの品質向上などが進むでしょうから、ますます採用しやすくなっていくと思われます。



懇親会では、他の会社さんの状況をおうかがいしたり、ライブラリ作者さんとご挨拶できたりと、楽しい交流ができました。

次回はGoogleさんでの開催ということで、どんなコアなお話を伺えるのか、今から楽しみにしています。


Flutterでマッチングアプリの開発をしてみたい方は @kikuchy または他の弊社エンジニアへ、お気軽にDMやリプライをください!
まずはご一緒にご飯を食べにいきましょう!!

Matching Dev Meetup #4 でコーディング以外のエンジニアリングについてお話しました

どうもこんにちは、暑くて食欲が減退しているのに体重は落ちない @imaizume です。

暑さのせいでついつい進むビールが原因ですね(笑)

 

さて先月17日に、株式会社イグニスさんにて "Matching Dev Meetup #4" が開催されました。

matching-dev-group.connpass.com

Matching Dev Meetupは、マッチングサービスを運営する企業が主催する開発者向けの勉強会です。

過去の回でも弊社の社員が発表をしています。

diverse-tech.hateblo.jp

note.mu

 

4回目となる今回のテーマはズバリ「エンジニアリング全般」。

私は10分LTにて、入社時から2年半程携わっているPoiboyでのプロジェクトマネジメントにまつわるお話をさせていただきました。

speakerdeck.com

 

内容は、Poiboyで実際に取り組んできた新旧のプロジェクトマネジメント手法を比較しつつ「エンジニアリングとは何か」を改めて考えるといったものになっています。

この話をしたのは、普段Poiboyで仕事をする中で「そもそもエンジニアリングとは何だったっけ??」という疑問を抱いていたことがきっかけでした。

プログラミングを仕事にしていると、普段「エンジニアリング=プログラミング」という認識でいることもあるかと思います。

 

そんな折、発表中にも引用した「エンジニアリング組織論への招待」という本を読んだのですが、その中に「エンジニアリングとは『曖昧さを減らす行為』」であると書かれていました。

人は見えないものや知り得ないものに対しては対処ができないため、そうした曖昧な要因を減らすことで生産的にプロジェクトを進めることができるというのです。

 

詳細は同書を読んでいただきたいのですが、プログラミングも曖昧さを減らす行為の1つではあるものの、それ以外でも曖昧さを減らすことは可能ということになります。

今日開発手法の主流となっているスクラム開発で行うプランニングやKPTといった手法も、この「曖昧さを減らす」ことが一つの目的となっているわけです。

例えば1スプリント内にこなせる・こなした具体的なタスク量が見えるように可視化することや、タスクの優先度の決定基準を特定の人の中ではなく全員が認識できる外に置くことなどです。

 

そのためエンジニアリングは「エンジニアだけが行うこと」ではなく「誰でもできること」という認識を持つべきではないかと思いました。

また最終的な目的が曖昧さの削減であれば、それを達成するために行動することこそが真のエンジニアリングであるということをお話させていただきました。

 

参加者の方からも多くのフィードバックをいただきました。

 

他には、実際に取り組んでいる開発プロセスの改善活動やフレームワークなどの紹介、大規模なチーム構成におけるマネジメント・情報共有手法などについての発表がありました。

弊社でやったことがない手法も多く取り上げられていたので、今後のプロダクト開発に取り入れていきたいものがたくさんありました。

f:id:incheon-special:20190808181912j:plain

株式会社イグニスさんのイベント会場

なお会場のイグニスさんですが、イベントスペースが大変きれいで司会進行もスムーズにされていたのが印象的でした。

またノベルティのステッカーが大変可愛らしかったです ‼️

 

今後マッチング業界を盛り上げていくため、Diverseはこれからも社内の取り組みを積極的に発信していきます!

TreasureData主催 PLAZMA 2019 KANDA にてLookerとの共同セッションに登壇しました


こんにちは、次の技術書典が近いのに前回買った本を全く読み進められていないiOSエンジニアの @imaizume です。

7月16日に神田明神ホールにて行われたPLAZMAに私と熊埜御堂の2名が登壇したので今回はそのご報告になります。

f:id:kmnmm:20190718144147j:plain

plazma.red

PLAZMAはTreasureDataが主催するユーザー向けイベントで、Diverseでも以前より社内DBとしてTreasureDataを使用していました。

また今回のイベントはDiverseが昨年から導入しているBIツールであるLookerがスポンサーをしていたことから、合同セッションでの登壇機会をいただくこととなりました。

なおLookerの概要や導入経緯についてはwantedlyでも紹介していますので併せてご覧ください。

www.wantedly.com

セッションでははじめにLookerからの概要説明や導入実績等が紹介されました。

現在は日本でも20社以上が導入していて、その中でもDiverseは最初期の段階で導入しているという点もお話させていただきました。

その後Diverse側にバトンタッチし、Lookerの導入背景や抱えていた課題、導入の効果や利用時のノウハウなどを紹介しました。

(残念ながら当日のスライドについては現時点では非公開です)

 

Lookerを導入する以前は、ビジネスで必要なデータがある場合、都度エンジニアにSQL発行を依頼していたため、クエリーの属人化が進んでいました。

また可視化のためスプレッドシートで管理されているデータも多く、集計時のバグ修正や計算ロジックの管理ができないといった課題を抱えていました。

さらにビジネス側の要件で算出条件を変更する場合には、複雑なクエリを修正する手間がありました。

 

しかしLookerではクエリの条件をWeb UI上で入力することでLookMLにより自動的にSQLが発行されるため、クエリの属人性を下げることができます。

Spreadsheetに頼っていた可視化も、ダッシュボード機能を使うことで常に最新のデータを必要な形で見れるほか、普段見たい情報が集約されるため必要なシートを探す手間がなくなりました。

加えて、条件修正もLookMLでの定義追加やWeb UI上での設定変更で実現するためSQLの修正が不要となり、エンジニア以外のメンバーでもほしいデータを容易に取得することができるようになりました。

 

このようにデータの活用が難しかったDiverseが、Lookerによりデータドリブンな企業に近づいていることをお伝えしました。

当日はエンジニア以外にマーケティングや分析の担当者をはじめ様々な方が参加されており、登壇後の懇親会でも導入を検討してる企業の方から質問を受けるなど好評をいただくことができました。

 

DiverseでもまだLookerで見れないデータや扱える人が限定されているといった問題がありますが、こうした課題も今後徐々に解消していくため日々努力を続けています。

ぜひこうしたデータドリブンなサービス作りに興味がある方は、ぜひDiverseの社員までお声がけください。

PORT Firebase × Flutter を開催しました

id:kikuchy です。

先日開催されたStampさんのイベント PORT Firebase × Flutter を弊社Diverseオフィスで開催 & kikuchyが登壇いたしました。

stamp.connpass.com

PORTは主にFirebase関連の勉強会を企画されているイベントプロジェクトで、過去にも様々な企業やテクノロジとのコラボ回を実施されています。
今回はFirebaseとFlutterの組み合わせ、というテーマでした。


(当日のライブストリーミング)


kikuchyは『Flutter x Firebase Crashlytics』というタイトルで、
FlutterアプリケーションにクラッシュレポートサービスのCrashlyticisを導入して運用した際に判明した問題とTipsを紹介させていただきました。


導入対象のアプリは、先日このブログでもお伝えした、婚活サービスのyoubrideです。

developer.diverse-inc.com

実務で使用する際の運用方法についてお話できたので、Flutter開発のお役にたてば、と思います。




次の登壇者のパネルディスカッションでは、アプリのアーキテクチャ、youbirdeアプリでのテスト構成、CIの構成、クロスプラットフォーム採用の是非などについてもお話させていただきました。

FlutterはFirebaseなどを使ったプロトタイピングと相性が良いので、ビジネスロジックの状態をStatefulWidgetに押し込めたりしがちです。
BLoCパターンやScopedModelパターンなどでWidget外にビジネスロジックの状態を切り出し、StatefulWidgetには表示ロジックの状態管理に徹してもらうようにすると、状態の抽象化や結合度の低下に貢献できるでしょう。


youbrideではBitriseをCIに使用していて、PR作成時にテストの実行、PRのマージ時にビルドとデプロイを自動で行うようにしています。
ビジネスロジックの単体テストを自動で行っており、実行も2〜3分程度で終わるようになっています。

プロジェクトの開始時に、まずは「ビルドが通るか」だけを確認するタスクのみでもCIを導入して、使えるようにしておくと良いでしょう。
後からCI環境を整備すると面倒になりがちであったり、リポジトリに動作しない状態のコードを混ぜる危険性を少なくできるためです。


また、FlutterはワンソースでiOS/Android両方に対応できることがウリの一つですが、結局プラットフォーム依存の機能を使用する場合やビルド周りなどでそれぞれの知識が必要になります。
そのため、慣れていないのであれば、iOS/Androidのどちらか一方に注力する選択肢を取ったほうが無難でしょう。
(youbrideチームは、クライアント開発できるエンジニアが全員iOS/Android両方ともできたのでうまく行っています)




懇親会ではクライアントでのgRPC採用の話題で大いに盛り上がりました。



(懇親会の様子)



gRPCは共通の定義ファイルから、サーバー/クライアントのRPCに関わるコードを自動生成してくれるため、
APIの定義から実装をとても楽に行なえます。
また、やり取りするデータはProtocolBuffersでシリアライズされているため、JSONと比べると軽量で、通信時間の短縮も見込めます。

youbrideでは将来的にWebサイトもPWA化し、フロント <-> サーバの通信はgRPC Web(ブラウザ上で使用するgRPC)で行う案も出てきていたので、
gRPC Webではまだ双方向のリアルタイムストリーミングができていない、などの制限があるというお話を聞くことができて大変助かりました。


Flutterでマッチングアプリの開発をしてみたい方は @kikuchy または他の弊社エンジニアへ、お気軽にDMやリプライをください!
まずはご一緒にご飯を食べにいきましょう!!

歴史ある婚活サービスyoubrideがFlutterを採用しました

最近はすっかりFlutterエンジニアになってます。id:kikuchy です。
Diverseが提供するサービスの一つに、youbrideという婚活サービスがあります。

youbride.jp


この6月に、youbrideはAndroidアプリのデザインリニューアルを行いました。

f:id:kikuchy:20190613192344p:plain
youbrideアプリのデザインが大きく変わりました!


変わったのは見た目だけではありません。
新アプリには、マルチプラットフォームフレームワークのFlutterを採用しています。

flutter.dev

近々、iOSアプリもFlutterで開発したバージョンに置き換える計画が進行中です。

そして、APIサーバーもRuby on Railsを使ったものに置き換えています。

rubyonrails.org


サーバーとクライアント間の接続にはgRPCを使用しています。

grpc.io


f:id:kikuchy:20190613200308p:plain
構成はこうなっています


なぜyoubrideでFlutter / Ruby on Rails / gRPCを採用することになったのか?
それは、youbrideに発生していた種々の問題を解決するためでした。

youbrideを取り巻いていた問題

仕様の複雑化とコードの複雑化

youbrideは今年で運営19年目を迎える、長寿サービスの一つです。
私達、今のチームが運営を手がけるより前にも、複数の会社を渡り歩き、複数のチームが開発・運営に携わっていました。

歴史あるサービス故に、サービス方針などで迷走した時期もあったのでしょう。
複雑な仕様や把握が難しい仕様が存在し、それを表現するコードも複雑になっていました。
複雑故に依存関係も読みきれず、不要かどうかわからないコードが放置されデッドコードになっている箇所もあります。

エンジニアの人数が少ない問題

現在、youbride担当チームは以下のメンバーで構成されています。

  • エンジニア …(サーバー/クライアント合わせて、外部委託の方も合わせて)5人
  • デザイナー … 1人
  • PO兼PM … 1人

膨大な仕様とコードに対して、対応できる人員が少なすぎます。
そんな状況だったので、一つの機能改修をするための影響範囲の調査だけで半日〜数日かかることもあり得る状況でした。

求人

youbrideのサーバーアプリケーションのコードはPerlで書かれていました。

Perlでの開発・運用をしたいエンジニアさんの数は少なく、採用の現場ではPerlエンジニアの募集がとても難しい、という声も上がっていました。

問題解決のために

コードの削減

少人数での開発を可能にするには、保守する対象のコードを削減する必要があります。

特にクライアントアプリケーションについては、マルチプラットフォーム開発ができる仕組みを使うことで、UIに関するコードやビジネスロジックをiOS/Androidの間で一本化できます。

また、ツールによる補助などを使用して、省力化できる部分は省力化したいところです。

仕様の単純化

利用者の皆様に御迷惑をかけてしまうため、サービス仕様については急に大きな変更をすることはできません。
せめてプログラム的な内部仕様は単純化したいものです。

そこで、サーバー - クライアント間の通信仕様の管理を簡単にできるものを探すことになりました。

人気の言語の採用

求人の対象は主に日本国内で、特にサーバーサイドで人気が高く、応募者が集まりやすい言語を選定することになりました。


技術選定

上記の要件に合致するものとして、最終的に以下のものを選択しました。

クライアント

Flutterを採用しました。

決定当時に普及の兆しが見え始めていたこと、
ロジックだけでなくUIも共通のコードで記述できること、
エコシステムが強力だったこと、
いざとなればプラットフォームの機能を簡単に使用できることなどが主要因です。

PWAにすることも検討されていましたが、iOS SafariではまだPush APIを使用できないことから、不採用となりました。

サーバー

Ruby + Ruby on Railsを採用しました。

国内の求人数が多いこと、
モダンな言語であり人気があること、
開発メンバーが慣れていることなどが主要因です。

JVM言語(KotlinやJavaなど)の使用も検討されていましたが、
メンバーのJVMサーバーのチューニングなどの運用経験が皆無であることなどから見送りとなりました。

インターフェイス

サーバ - クライアント間のインターフェイスにはgRPCを使用することになりました。

サーバーとクライアントの間での共通認識が作りやすいこと、
バイナリベースなプロトコルで、HTTP 2.0を使用できて高速に通信できること、
通信部分の実装をほとんど自動生成できることが主な要因です。

Swagger (OpenAPI)も俎上に上がりましたが、通信速度などの点でgRPCに軍配が上がりました。

実際に採用してみて

クライアント

途中経過の話は、以前にQiitaに投稿したことがありますので、合わせてご覧ください。

qiita.com

Developer Experience

FlutterはとてもDeveloper Experienceの良いフレームワークだと感じています。

アプリを実行したままコードの変更を反映させるHot Reloadがとにかく高速で、
これを経験してしまうと、通常のAndroidアプリのビルド時間にも耐えられなくなってしまうほどです。

また、(React風の)宣言的UI構築はとても直感的で、Viewの現在の状態を考える必要がなく、楽にコードを書くことができました。

高速な動作、使い勝手

Androidのアプリケーションとしてリリースを行いました。
FlutterデフォルトのLook & FeelがMaterial Designであるということもあり、通常のAndroidアプリケーションと使い勝手は何ら遜色ありません。

ビルド後のサイズも、今まで公開していたAndroidクライアントと全く変わらないサイズ(約15MB)になっています。
FlutterアプリケーションはDartのエンジンなどを積んでいるため、サイズは大きくなることを覚悟していましたが、軽く済んだのはとても嬉しい誤算でした。

サーバー

再設計による疎結合化、単純化

Perlで書かれていたサーバはいわゆるFat Controllerな設計になっており、適切なレイヤー化ができていませんでした。

今回、サーバーのコードもリライトする際にレイヤーを見直すことで疎結合な実装を実現でき、テスト駆動開発ができるようになりました。

同時に、Perlでは多用されていたメタプログラミングを廃し、IDEによる補助を強力に受けられるようになりました。

ちょっとした動作確認が簡単

Ruby on Railsの採用で、rails cコマンドによる対話的環境で、簡単な動作確認が手元で行えるようになりました。
テストを書くほどではなく、少し値の形式を確認したいだけ…など、といったときに、心理的なハードルを低くして動作させることができるようになっています。

これまではサーバーを立ち上げて、試したいコードパスを通るリクエストを投げなければいけませんでした。


インターフェイス

gRPCは通信にHTTP/2を、データフォーマットにProtocol Buffersを使用したRemote Procedure Callの仕組みです。
共通のインターフェース記述言語(IDL)を用意し、そこからサーバー、クライアント用の実装を自動生成します。

インターフェースの曖昧さ解消

これまで、サーバー - クライアント間ではREST(っぽい)APIを定義し、HTTP/1を介してJSONフォーマットでデータをやり取りしていました。

また、Perlの値を安直にJSONへシリアライズすると、真偽値が"1"/"0"と、数値も文字列型として出力されてしまいます。
以前のクライアントアプリケーションはこれをなんとなく変換して使っていたのですが、
以前のメンテナがいなくなってしまった今は、果たしてこの値が真偽値として扱うことを期待されているのか、そうでないのか、判別できません。

gRPCには共通のIDLに型宣言でき、Enumも定義できることから、値域について混乱することがなくなりました。

実装の簡略化

gRPCはIDLからサーバー/クライアント向けのコードを生成できるため、具体的な通信にかかるコードを記述する手間をほとんど無くすことができました。

IDLの.protoファイルは専用のリポジトリで管理しています。
このリポジトリでPull Requestが通ると、CIでコードの生成を行い、サーバーとクライアントのリポジトリに自動的に生成したファイルを含んだPull Requestを生成するようにしました。

f:id:kikuchy:20190611155053p:plain
protoファイルの変更から自動生成されたPR

ドキュメントもGithubリポジトリのWikiに自動でPushされるようにしています。

f:id:kikuchy:20190703204200p:plain
ファイルの変更後、自動的に更新されるRPCのWiki

ファイルの生成について特別気にすることがないため、とても開発が楽になりました。

課題

抱えていた問題のだいたいを解決することができましたが、新しい要素の採用故に生じた問題もあります。

クライアントの課題

言語

Flutter SDKはDart言語で記述されており、Hot Reloadなどの仕組みもDart言語を前提に作られています。
Flutterが出た当初はDartに対する不満も多く見られましたが、バージョン2.3になってだいぶ改善してきたように思います。

しかし現状ではまだ大規模開発を行う上で不満は残ります。

特に現在のDartはnull安全ではなく、予期しない入力によってnullを期待しないメソッド引数にnullが入ってしまった場合などに簡単に例外が生じます。
人間はミスをしがちな生き物であり、人間の注意だけでこうしたミスを防ぐのは困難なので、できれば型システムでnullが入る可能性があるのか否かを明示してほしいと切に感じます。
null安全性については今後のDart言語のバージョンアップでの採用が決まっているため、
プロダクションで採用するならば、個人的にはnull安全が導入された後のタイミングをおすすめします。

しかし悪い言語だということではありません。
言語仕様レベルでの非同期処理のサポート、クラスとインターフェイスの同時宣言、Collection If/Forなどコードを書きやすい機能も揃っています。

クラッシュレポート

現在はFirebase Crashlyticsにクラッシュレポートの蓄積を行っています。
(現在、Firebase CrashlyticsはFlutterを公式にはサポートしていません)

レポートの送信はfirebase_crashlyticsプラグインを用いて行っていますが、例外によってはDartのスタックトレースが送信されていないケースがままあります。
(スタックトレースを得られない原因は目下調査中)

また、スタックトレースが得られても、Widgetのレンダリングプロセスの途中で起きた例外は、Flutter SDKのクラス名が並ぶばかりで、ユーザーコードのどこで例外が起きたのかわからないこともあります。

そのため、現在は例外の原因究明に大きなコストがかかっています。
Firebase CrashlyticsがFlutterに正式に対応してくれるのを待っています。

gaurunとfirebase_messagingの相性

youbrideはgaurunを用いてPushサーバーを運用しています。

AndroidアプリケーションがリモートからのPush通知を受けるにはFirebase Cloud Messagingを使う必要があり、firebase_messagingプラグインはFlutterでのPush受信のデファクトスタンダードになっています。

ところが、firebase_messagingはFirebaseのコンソールなどから送信された形式のペイロードを想定した作りになっているため、gaurunが送信するペイロードとは形式が合わず、gaurunからPush通知を送ってもクライアント側で表示されません。
gaurun側の修正予定もない、とのこと)

結局、プラグインに頼らずに、Push通知の受信を実装することになりました。

サーバーの課題

gRPCの運用経験

弊社内でgRPCを使用したプロダクトはyoubrideが初めてです。
そのため、大規模サービスでのgRPCの運用経験がありません。

インフラ構成なども手探りで進めているので、今後なにかトラブルがあったら怖いのは間違いないです。

ただ、大事故に至らないように調査はしていますし、今後知見をためていくことができれば不安は小さくなるでしょう。

インターフェースの課題

サーバーがCPUを使い切らない?

現在はgrpc gemを使用していますが、どうやらgrpc gemにはCPUを使い切ってくれない問題があるようです。

今のところはまだこれが問題にはなっていませんが、そのうちに問題になる時が来るかもしれません。



youbrideチームは、iOSアプリもFlutterで作ったものに置き換えるべく作業を続けています。

これだけ歴史の長い大きなサービスでFlutterを採用しているケースは、国内初なのではないかと思います。
今後もDiverseはコミュニティに知見を還元してゆきます\\ ٩( 'ω' )و //