YUMEMI.grow Mobile #6でお話しした物を記事化しました。
はじめに
ここで紹介するのはあくまで一例であり、同じような方法を使うと必ず失敗すると言いたい訳ではありません
銀の弾丸が無いことと同様にチームの規模や技術力などで簡単に結果はひっくり返ると思っています。
やり方
- KMP、Android、iOSで3チームに分かれて分かれて実装を進めた
- GitHubのRepositoryもそれぞれのチーム毎に持っている
- KMPがStateの管理まで行うので、AndroidとiOSは画面と権限取得などのネイティブ独自の実装のみ担当する
僕の想定
工数の予測
Androidの開発20人月、iOSの開発20人月で合計40人月の開発があったとして、
それぞれの10人月分を共通化すれば、
Android(10人月)+iOS(10人月)+KMP(10人月)+共通化することで発生する工数(6人月)のように共通化する部分を増やせば増やすほどお得に工数削減できると思っていました。
※共通化による追加工数はもう少し落とせると思いつつ安全を見てこのくらいの想定
仕事の流れ
初期
KMPチーム:全機能のState管理まで含めて対応しなければならないので忙しい
アプリチーム:KMPの実装ができるまでは、画面の部品作成とか画面の仮実装までしかできなくて余裕がある
中期
KMPチーム:引き続き残機能開発と初期に開発した機能の不具合修正、ある程度開発が進めば実装も慣れてくるので多少余裕が出てくる
アプリチーム:初期にKMPチームが作ってくれた機能の取り込みと残画面の実装で少し忙しくなってくる
後期
全員:不具合修正や残作業を軽くやっつけるだけの簡単なお仕事
実際
初期
KMPチーム:全機能のState管理まで含めて対応しなければならないので忙しい
アプリチーム:KMPの実装ができるまでは、画面の部品作成とか画面の仮実装までしかできなくて余裕がある
こちらは想定通りの流れ
中期
KMPチーム:担当している責務が大きすぎて不具合対応で疲弊する&残りの機能開発もやること盛り沢山
アプリチーム:KMPチームが責務をいっぱい持ってくれているので、不具合対応や残画面の開発を待つことがあり、全力で走ることができない
この時点で想定外・・・
※アーキテクチャも慣れている人が少ない物を採用していることで、立ち上がり工数がかかるので助けを求めにくいこともダメージになる
後期
KMPチーム:中期の残作業が厳しい&テストが始まり対応しなければならない不具合が激増のため厳しい
アプリチーム:不具合修正も大きい責務を持つKMPの対応待ちが多くなるので走りにくい
アプリ開発の流れ
KMP実装
KMPチーム頑張れ！と応援
KMP取り込み作業
アプリチームはここからスタート
KMPの最新版を取り込むPRの作成を行う
自分が関係する機能であれば仕様の理解もあるので簡単に取り込めるが、
基本的に自分が関わっていない機能についての変更も複数行われているので地味に工数がかかる
※KMPの更新頻度も高いので回数も多い
画面への組み込み
Stateの管理までKMPで行なってくれるので仮実装していた画面に対してStateとかイベントの処理を組み合わせてあげれば完了でしょ！簡単簡単！！
と、思っていた時期が僕にもありました。
KMPチームの考えてくれたStateの使い方が分からなかったり、画面表示にどのパラメータを使えばいいか分からないなどでコミュニケーションコストが思ったよりも大きい
※Androidの場合はKMPのコードを見ればコメントが見れるのでマシですが、iOSはコメントが見れないのでより大変
さらにコミュニケーションを進めると項目の不足なども出てくるので、KMP実装から再度やり直しとなる
まとめ
KMPの責務を増やしすぎると
- 作業の分担ができず、負荷がかたよる(アプリチームが一緒に全力疾走したくてもできない)
- KMPの取り込み作業が地味に負荷がかかる
- コミュニケーションコストが大きくなる
対策案
- ドメイン(UseCase)までの共通化が無難そうor画面まで共通化
- 本当に少人数の開発でコミュニケーションが取りやすい環境ならコストは下がる可能性が高そう
- メンバー全員がKMP、Android、iOS全ての実装をできるなら1人が1機能開発のような体制を作れればメリット大きそう
宣伝
DroidKaigi 2023でこちらの記事の内容を詳しくお話しします。
あえて失敗した面にフォーカスした記事を書いたので、実際の作りやメリットについてはDroidKaigiでお話しする予定なので、ぜひ聞いてください
Discussion