Diverse developer blog

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

Matching Dev Meetup#1でクライアントアプリの状態管理と仕様の複雑さについてお話しました

そろそろAdvent Calendarの季節が近づいてきて、勢い勇んで枠だけ取ったものの何を書くのかほとんど決まっていない id:kikuchy です。やばい。


先日、Matching Dev Meetup#1 - iOS / Androidというイベントが開催されました。

マッチングサービスを提供している各社からエンジニアが集まって、マッチングサービスに特有の話題などを共有しよう! という会です。
弊社Diverse(ダイバース)の他にも、Pairsのエウレカさん、タップル誕生のマッチングエージェントさん、withのイグニスさん、CROSS MEのプレイモーションさんなど、たくさんの会社からたくさんの関係者が集まる賑やかな会となりました。

matching-dev-group.connpass.com

マッチングエージェントさんによるブログでも、当日の様子が公開されています。

developers.cyberagent.co.jp



催されたLT会のなかで、私は『男女出し分けと会員状態で画面切り分けが大変な話』というタイトルで、マッチングサービスのクライアントアプリにおける状態管理と仕様の複雑さについてお話しました。



なんの打ち合わせもしていないのに、まるで示し合わせたかのように各社が「マッチングサービスのクライアントアプリは状態管理が鬼門」というLTをしていたのが印象的でした。
それだけ、我々は状態管理に悩まされている訳ですが…

その原因は仕様の複雑さにあります。
マッチングサービスのユーザーは、登録性別やユーザー属性、法的に必須な年齢確認状況など、様々な変数を持っています。
その変数の状態ごとに、運営としてやりたいこと/やらなくてはいけないことが変わってくるのです。
そうなると、「この場合は」「こうする」という仕様が大きくなってゆき、さらにクライアントにつきものの通信処理やそのキャンセルなどが挟まって大変なことになる、という訳です。

エンジニアとしては状態をうまく管理する方法を見つけつつ、サービス運営の中の人としては仕様の単純化と外せない仕様のバランスを上手く取っていくことが、サービス開発の肝となります。

そうしたマッチングサービスの開発の雰囲気が伝われば嬉しい限りです。


懇親会では、CS(カスタマーサービス/カスタマーサティスファクション)も特有の苦労がある話や、「ユーザーに価値を提供するとユーザーが離脱していく」という特性を持った婚活サービスの諸行無常さ(パートナーが見つかると退会する必要があるため)について、各社の関係者さんや、他業界の方と話がはずみました。

またテーマを変えて開催される見込みなので、興味のある方はConnpassのMatching Dev Meetupグループをウォッチしてみてください。

matching-dev-group.connpass.com



状態管理と戦う良い方法の知見をお持ちの方、こうした環境で自分の腕を試したい方は、 @kikuchy または他の弊社エンジニアへ、お気軽にDMやリプライをください!
まずはご一緒にご飯を食べにいきましょう!!