iOSとAndroidでアーキテクチャを揃えた話です。

1. クロスプラットフォームはまだ早い！
既存のアプリをクロスプラット
フォームっぽくする方法

2. 自己紹介
●
○
●
●

3. 話すこと
● モバイルアーキテクチャ決定のプロセス
● と の違い
● ドキュメント化

4. クロスプラットフォームにしたい

5. クロスプラットフォームフレームワークに憧れる
● 現状、モバイル向けアプリで と に対応しないはありえない
● 両 でほぼ同じロジックを別々に開発するのは非効率
● アプリだけでは実装できないことも多々ある
○ 弊社の例だと、歩数計等のセンサー周りなど

6. クロスプラットフォームを導入するメリット
● 実装 実行サイクルが圧倒的に早い
○ や での話
○ 動作確認に 分以上も消費してしまう開発体験は卒業したい
● ビジネスロジックを共通化できる
● 部分も共通化できる
○ ただし、失敗しているアプリも多いのでここは様子見

7. クロスプラットフォームを導入できる状況
にあるか？

8. ！

9. 現実は厳しい

10. クロスプラットフォーム導入できる状況にあるか？
● 新規で機能が小さければ十分あり
● 既存のアプリを移行できるか？
○ 移行にかかる調査・実際に移行する際の見積もり
○ 巨大に膨れ上がったアプリ
■ それに伴う負債
○ 移行する工数に見合うメリットを得られるのか？

11. 容赦ない現実が
襲いかかってくる

12. 何を解決するべきなのか？

13. そもそも何を解決したいのか？
● バグを抑えたい
● 品質を上げたい
● 開発効率を上げたい

14. 現状を整理する
● 各 で実装が違う
● 各 で使っている アーキテクチャが違う
● 各 で同じ機能なのに使っているデザインパターンが違う
● バグの温床
● ごとに設計して、無駄な工数がかかる

15. 設計を揃える

19. とか

20. （とか）
ってなんだよ！

21. 現状を把握する
●
○
●
○ 画面単位で使われている アーキテクチャが違った
○ 主に が使われていた
○ 秩序はなかった

22. あるべきアーキテクチャを考える
● と チームで認識を揃える必要がある
● プロジェクトはかなり巨大
○ ビジネスロジック部分もアーキテクチャを入れる必要がある

23. アーキテクチャを決定する
● を採用
●
○ 既に 側が を採用していた
○ も の登場があって導入しやすい状況にあった
●
○ プロジェクトが巨大だった
○ ビジネスロジック部分もちゃんとレイヤ化しないと辛い

24. ライブラリを決定する
● 、 を採用した
● は？
○
■ 検討当時はまだ実験段階
○
■ 現在もまだない

25. ドキュメント化
● 各チーム全体で認識を揃えるためにも必ずやるべきこと
○ ドキュメントツール を活用して、参照しやすいようにする
● 特に の認識や知識がまだ足りなかった
○ 用語の認識にズレがあると議論のときに不便
● サンプルコードがあると理解が早くなる
○ と の両方のサンプルを用意
○ サンプルコードベースで実装のレビューが可能

26. ドキュメント化の例

27. ドキュメント化の例

28. 実装を揃える

29. 用語や言語の違い
● と
○ ほぼ同じ役割なのだが、議論のときに混乱の元となる
● と の扱い
○ が便利過ぎて
● お互いの言語の違いをわかっていると議論がスムーズに進行する

30. 例： 実装の違い
あれ？
に 制御って
無いの？？
エンジニア

31. 例： 実装の違い
そんなものはない
エンジニア

32. お互いの実装背景
とか言語背景を知る
違いや対応表もドキュメント化する

33. 実際運用してみて

34. 実際運用してみて
● 設計で迷うとかの時間がかなり減った
○ これはドキュメント化の功績がかなり強い
● 両 エンジニアがお互いにレビューできる環境になった
○ デザインパターンを使用するかどうかでしっかり議論ができた

35. まとめ

36. まとめ
● 設計・認識を揃えるだけで、開発効率や品質は向上する
● 両 のエンジニアが互いに知見を交換できる環境が作れる
● ドキュメント化は正義

37. おまけ

38. これでいいのでは？？？

39. うんとはいえ、色々事情がある

40. 将来的な話
●
○ ビジネスロジック部分は で実装して、 部分は各 で実装
○ エンジニア側で調べた結果、 対応が現状イマイチなので見送ってる
○ 将来的に使う可能性は高い
●
○ 既に一部で導入している。こちらにある程度のロジックを寄せることも可能
○ 詳しくは の さんの発表を参照のこと

41. 氏による技術よりな解説もあります