見出し画像

円滑なコミュニケーションや決済を支えるスマホアプリ「いい生活Home/Owner/Pay」について、プロダクトオーナーとCTOに語ってもらいました #2

こんにちは!いい生活エンジニア採用・広報担当の黒江です🕊️

今回も、前回に引き続き、いい生活のプロダクトを支えるメンバーと、CTO松崎さんとの対談をお届けします!

CTO対談第3回の今回は、いい生活Home/Owner/Pay(以下:Home/Owner/Pay)のプロダクトオーナーの稲葉さんと松崎さんに、Home/Owner/Payについて語ってもらいました!

今回の対談は3つの記事に分けてご紹介させていただきます!
こちらの記事は中編です!
前編は以下よりご覧ください!


【前回の対談のおさらい】
Homeは入居者と管理会社、Ownerは管理会社とオーナーのコミュニケーションアプリです。また、いい生活Payは入居者と管理会社の決済アプリです。
Home/Owner/Payの共通点は、いい生活唯一のスマホアプリであることです。

プロダクトオーナー兼プロダクトマネージャーの稲葉さんは、プロダクトの立ち上げ初期は開発メンバーでした。
開発メンバーの大変さを理解しているため、技術面なども考慮しながら、メンバーとプロダクトをより良くするための認識を合わせ、開発を進めています。



スマホアプリを開発する大変さ

いい生活のプロダクトで唯一スマホアプリで提供しているプロダクト

松崎さん(以下 松崎):
HomeとOwner は、スマホアプリで提供してるっていうところが特徴だよね。

やっぱり Web アプリと、いわゆるストア配信のスマートフォンアプリだと違う点がいろいろあると思うんだけど、実際開発していて大変なこととかあったりする?

稲葉さん(以下 稲葉):
いくつかありますね。
技術的な面だと、アプリの動きというところがWebと違いますね。
「スマホアプリだったらこういう動きをするよね」っていうデザインを実現するための技術やフレームワークなどが、結構専門性が高いです。
社内にある情報ではなくて、自分たちで調べていかないとなかなかハードルが高いという特徴はありますね。

あと、Web はいわゆるホスティングさえすれば、あとは好きにリンクから使えるようになります。
ですが、スマホアプリだと、ストア配信をするために認証を受けるといったプロセスがあります。
そこで配信するためのガイドラインに従う必要があるところは、スマホアプリ開発固有のところかなと思いますね。

松崎:
ちなみにさ、Google の Playストアのガイドラインと、Apple の App Store のガイドラインだと大体 Apple の方が厳しかったりすると思うけど、実際開発してどうかな?

稲葉:
基本的にやっぱり Apple の方が厳しいですかね。Apple のブランドを大事にしてるっていうところを感じます。
ただ、全体の流れとして、セキュリティ面など「個人情報の取り扱いのために、アプリにこういう機能を追加するように」みたいな要求っていうのは先に Apple から出て、その後 Google でも出てきます。

片方だけ何か要求されてるものがあるかというよりは、両方に要求されていますね。
先に Apple の審査でリジェクトされ対応したことが、数ヶ月後、Googleでも同じ要求をされることもあります。
ですが、既に対応済みなのでその時は特に問題はないですね。

あと開発でいうと、「スマホでバグが起きました」みたいなコメントをストアのレビューに書かれることがあります。
ストアのコメントだけだと、どこの誰がどういう状況で発生したのか全くわからないし、誰に聞いてもわからないので、それは結構歯がゆいというか悩ましいです。

松崎:
筐体固有の問題っていっぱいあるよね。

稲葉:
そうですね。特に画面サイズが大きくなったとか、ノッチと出てきたあたりでそのための実装もしています。
ですが、自分の手元のスマホだと再現しないけど、最新機種だと問題が発生することもあります。

松崎:
そうなるよね。
Apple だけだとバリエーションはそんなにないけど、Android は画面サイズのバリエーションが多いよね。いろんなメーカーがいろんなサイズで出している。

稲葉:
レイアウトの面は、デザイン上ある一つのサンプルで作っていますが、筐体ごとにちょっと幅が違うものに耐えられるレイアウトで実装・確認する必要のあるものは結構増えてます。

CI/CDツール選択と活用

松崎:
あと開発面で、いわゆるビルドっていうことを考えると、特にiOS用のビルドでなかなか CI/CD が乗っけづらいみたいのがあったりするじゃない。
一応 Bitrise 使っているんだっけ?

稲葉:
はい、Bitrise を使用しています。
やはりローカルでビルドして確認するっていうのがあるので、基本的には開発者のマシンは Mac 1択ですね。

松崎:
Xcode が動かないと話にならないもんね。
だから基本的に本番ビルドはちゃんと CI で回せるようにしていると言えますよね。
ローカルビルドのテストは、基本的に開発者個人の Mac で行うという感じだよね。

稲葉:
Bitrise を早期導入してよかったなと思います。
導入当時 iOS のビルドで Bitrise がメジャーだったかっていうとそうではなくて、リモートで Mac のマシンを繋げて、リモートでリードするみたいな。
ローテクなのかハイテクなのか、よくわからないものを使っていましたね。

ですが、Bitrise のちょうどいい波が来てたんで、いいんじゃないかと思い試してみて、今でも使っています。

Mac の OS のバージョンの切り替えなども簡単にできるっていうのは、開発者目線だととても開発しやすいなと思いますね。

松崎:
今はいわゆる CI/CD ツールが増えてきて、いわゆる iOS 向けのビルドやiPadOS 向けのビルド、MacOS 向けのビルドなど、いろんなことができるようになった。
だけど5年ぐらい前だったら、確かに選択肢が限られていたよね。

稲葉:
CI/CD ツールまわりですと、レポジトリの移行を昨年9月に実施したので刷新しています。
元々は drone を自前のサーバー上で動かしていましたが、GitLab 移行に伴い、CI/CD まわりを作り直しています。

ビルドデプロイは元々実施しており、OWSP ZAP の実行も部分的に自動化しています。
刷新の際には、メンバーが少なく知見も不足していたので、SRE チームにエンベデッドな形で入ってもらい、とても助けられました。
現在は基本的に master マージで自動的に staging アップし、tag 付けで本番デプロイする形で落ち着いています。

ネイティブコードとWebベースの開発技術の両立

松崎:
今の開発は Web ベースの開発技術をネイティブアプリにコンパイルしているよね。
でも、純粋なネイティブコードにしたいみたいな欲求とかって、チーム内であったりする?Kotlin で書きたいみたいな。

稲葉:
ありますね。
今は、ネイティブアプリの開発か Web ベースの開発技術でやるべきか、という2つの間の Cordova っていう技術を使っています。

この技術的な面で言うところの、知識情報があんまり多くないので、基本的には新規の知識をまず自ら試してやる必要があり、そこに時間がかかります。
あとは、この先この技術が自分のためになるのかを考えるメンバーもいます。
であれば何かもっとネイティブなんだけど、Web 技術も書けるものを採用したいみたいな思いもあります。

松崎:
Flutter を採用してるのは一つそういう理由かなと思ったね。
ただ確かに、Swift や Kotlin とプラットフォーム用に完全分離するには、チーム規模的にも結構きつい。
だから、どれだけシングルソース、マルチデバイスで開発できるかは結構ポイントになってくると思う。

OSごとのインターフェースの違い

松崎:
一方で、その利用者体験っていう観点で見ると、やっぱり Android にはAndroid 風の UI、iOS に iOS の UI ってやっぱりあると思う。

利用者としては iOS を使っているなら、Apple 的なインターフェースの設計に慣れてるだろうし、Android を使っているなら、やっぱり Android 的なパターンに慣れてるみたいなところがありそう。

実際に実装するときには、Web アプリの雰囲気になるべく寄せて、どちらのOS にも寄らないようなインターフェースを作っていくところにうまく落とさないと、利用者の体験が悪くなるみたいなことが大変なのかな。

稲葉:
はい、でも今は少し変わってきていますね。
今までは「Android の UI だな」や「iOS の UI だな」とか結構あったんですけど、最近は感じにくくなりました。
「これって Web ブラウザと同じようなインターフェイスが実装されているな」というアプリが流行ってることもよく見るので、流れが変わってきたかなと思いますね。

松崎:
なるほどね。
さっき Cordova を使っていると言ってたけど、そういう意味ではユーザーからすると別に違和感を感じにくくなっているのか。

2つの OS 向けに全く別のコードベースを維持することは、当社だけでなく、使ってる技術スタックが別の会社だとしてもやっぱり大変。

だからそれを関連化するためのツール群としていろいろ出てきているし、そういう意味では少しずつ Web に寄っていくのかもね。

稲葉:
Web でできることも増えつつあるので、その影響も大きいのかなと。

もちろんジャイロセンサーを使うとかそういうデバイスのリソースを使うような機能とかであれば、ネイティブの SDK とかを使って開発しないといけないと思います。

ですが、今のところ Home や Owner が提供しているサービス機能だと、Web 技術で替えが利きますね。

松崎:
そうだね。カメラを単に起動するとかは一応できるよね。

でも、例えば生体認証のところにもう少し踏み込むと、どうしてもネイティブ系のもうちょっと深いアクセスが必要になってきて、そういう抽象化レイヤーとかを挟むと使えないみたいなこともありそうだね。

あと、今は Web が進化してきていて、プログレッシブウェブアプリみたいに、逆にWeb アプリに振っちゃうみたいな選択肢もあるとは思うけど、どう?

稲葉:
プッシュ通知に最近対応したっていうことがあるので、ちょっとそこはまだ考えている途中ですね。

ユーザーにより良い価値を届けるために

不動産会社への連絡専用のアプリであることのメリット

松崎:
これは本当にフランクな議論なんだけど、入居者たちも、不動産会社に連絡する専用のアプリをインストールすることって、Web ページにアクセスするよりも心理的ハードルって高いのかな。

稲葉:
そこは、どうなんですかね。
どうやって不動産会社に連絡するのかがわかりやすいっていうのは、よいところだと思います。
管理会社としても、「この QR コードのアプリから連絡してください」と案内しやすいですし。

松崎:
やっぱりアプリであることのメリットってあるわけだ。
あと、スマホのホーム画面にいるわけだもんね。その形で提供することがやっぱりいいんだね。

稲葉:
PCから入ってる人からすると、プログレッシブウェブアプリを入れるっていうのは発想としてあるかもしれないですね。

でも、スマホのブラウザからいきなりホーム画面に追加っていう操作って、なかなかしないと思います。
そういうやり方が流行るとか、ストア経由でプログレッシブウェブアプリをインストールするというような仕組みが来ないと、ちょっと難しいですね。

Google がそういうのを先駆けて配信するみたいな話があるのは耳にしています。

松崎:
そこら辺は様子見なんだね。
逆に言うと、今は Web 技術をベースとした、ネイティブっぽいアプリを提供していることで、実はその時代の変化に対して選択肢を持ち続けられているっていう見方もできるよね。

モニタリングの方法

松崎:
一般生活者、コンシューマーに問題が起きてるみたいなときに、なかなかその状況を拾えないみたいな話がさっきあったよね。
トレーサビリティの確保やログの観測性の向上とかみたいに、どういう風にアプリが使われてるかのモニタリングは、今はどんな感じでやっているの?

稲葉:
Google アナリティクスを入れてありますね。

松崎:
あくまでも、どう使われているかというところにウェイトがかかっているのかな。

稲葉:
そうですね、基本的にはどう使われているかとかですね。

松崎:
Sentry というか、ああいうクライアントサイドのエラー監視のツールは使用していない?

稲葉:
一時期入れようかって検討してみたんですけど、入れていないです。
それは、実際にお客さんの手元で問題が起きていないものが通知されることもあるからですね。
お客さんの困ってないものに対して調査するところにまではなかなか手が回らないので、今これを導入しても対応ができないと判断しました。

松崎:
なるほどね。逆に言うとまだまだちょっとコード品質的に頑張らなきゃいけないところがあるというところなんだね。

稲葉:
そうですね。
「実機でしか起きてないようなエラーっぽいぞ、これは…」というものに対して「一体どの実機だ?」という特定が難しいですね。

松崎:
その辺はまだまだ技術的にも難しいよね。
とはいえ使っていて、そんなに大きな問題が発生しないレベルには仕上げているもんね。

稲葉:
そうですね。
ストアにアプリの広告がされているんですけど、それは収集しやすいようにしています。

あとは、そういう不具合報告とか、フィードバックをできるものをアプリ内に組み込んでいます。
そこでアプリに対してどう思うかをコメントしてもらうと、こちらとしては、どこの誰がどういう時に使って、コメントを残したのかが分かるので、それをもとに、不具合解消や調査ができるようにはなっていますね。

また、障害がなぜ起きたかの深掘りや、そもそもの品質を上げるための活動を週次でテーマを決めてプランとアクションにつなげています。

QA チーム主導で、障害の根本原因、流入を防ぐため開発者ができることは何か、などを話しています。
発生した障害から、今後同じことが起きないようにテスト観点に追加して再発を防ぐことなどを行っています。

Testing Trophy というコンセプトをもとに、障害発生時の自分たちのチームではどうするか、インシデントコマンダー、状況報告、実務担当などフォーメーションを決めて早期解決に努めています。
そして、実際にうまくいったことへの振り返りも実施しています。
この場は、品質というテーマのもと、学びを得る場にもなっていますね。

また、バグ報告とかそのログ管理とかとは話が別ですが、アプリ内の評価はストアに書かれるコメントよりも、ポジティブな意見をフィードバックしてくれるユーザーさんが多いですね。
このような意見をいただくと僕自身その日はずっと気分がいいですし、より良いプロダクトを届けるために頑張ろうと思います。


続きが気になるところですが、今回はここまでとさせていただきます!
読んでいただき、ありがとうございました😉

いい生活では新卒/キャリア採用を行っております!
以下から気軽にご応募ください!


いい生活公式noteの「いいnote」のフォローもお願いいたします!

それでは今回はこちらで失礼します!
次回はこちらの対談の最終回をお届けします!


撮影:杉山 泰之

いい生活では、新卒・中途ともに積極採用中! 採用サイトもぜひご覧ください。