アプリエンジニア徹底解剖！アプリ開発のエキスパートたちが語る開発現場の実情とは？環境構築と開発の問題点も考察
2020年4月22日に行われたFLEXY主催CTOmeetupのテーマはアプリ開発です。今回は初の試みとして、オンラインで開催。リアルタイムで視聴者のコメントも見ながらディスカッションを行いました。
4名のネイティブアプリ開発のエキスパートたちが語る、開発現場の実情とはどのようなものなのでしょうか。アプリの技術選定やマルチプラットフォーム、UI/UXについても熱い議論が交わされました。
また、昨今のテレワーク、リモートワーク化した開発現場から見る業界の働き方のトレンドの変化にも触れています。
ぜひチェックしてみてください。
アプリエンジニア徹底解剖 パネラーとモデレータ紹介
開発環境の課題と改善について
ネイティブアプリ開発者たちの開発の進め方
Virapture株式会社 伊藤 大樹さん（以下、伊藤）：本日はよろしくお願いします。まずはみなさんのアプリ開発環境についてざっくばらんにお話しできればと思います。まず阿部さんは隙間バイトアプリの「タイミー」を開発していますが、開発の経緯などを軽くお伺いしても良いでしょうか。
株式会社タイミー CTO 阿部 勇一郎さん（以下、阿部）：タイミーは最初にiOSアプリをリリースし、約1年遅れでAndroid版をリリースしました。iOSが先行した理由はいろいろあるのですが、端的に言うと僕が書けるのがiOSだけだったからです。
伊藤：リソース的な問題なんですね。アーキテクチャはどういったものですか？
阿部：リリース時はカオスな状況でしたよ。5人のチームだったのですが、1人のベテランエンジニアを除くと中堅か初心者ばかりで、それぞれが一斉に画面を作ってバラバラに実装していました。統一性は全くなく、「とりあえず動いているからOK」という感じでしたね。 その状態を僕がキャッチアップしてリファクタリングを重ね、いわゆるMVVMのような形に落とし込みました。リリースから1～2ヶ月くらいのタイミングです。API層やModel層にあたる部分は一番技術のある方が補修することで、なんとかリリースできました。開発期間が1ヶ月ほどしかなかったため、このような戦法にせざるを得なかったんです。
伊藤：時間が無いと必死になりますよね（笑）。サービス運用にあたってCIなどのツールはどういうものを使っているんですか？
阿部：今はBitriseを使っていて、中はfastlaneが動いています。
伊藤：宇山さんは現在お一人で様々な案件に関わっていると思うのですが、どのように言語やアーキテクチャの選定をしていますか？
ウヤマドットコーヒー 代表 宇山 寛さん（以下、宇山）：古すぎるフレームワークやあまり流行っていないものは使っていません。ただ、最近は新規立ち上げの案件が多いので、モダンなものよりは枯れた技術を選ぶようにしています。新規案件は後から人を集めるパターンになりやすいからです。人が集まりやすそうな言語やアーキテクトで設計をしているということですね。 一方でクライアントの雰囲気にも左右されるところもあります。担当者の方に「新技術を使っていろいろやりたい」という志向があれば出たばかりのフレームワークを試すことがありますし、堅めのエンジニアが必要そうな現場ならPHPやJavaを選んだりします。
伊藤：柳田さんは位置情報SNSの「neeboor」を作成されていますが、どのように開発をしていますか？いつも自分がどんな風に開発を進めているのかという観点でも構いません。
neeboor, Inc 代表 柳田 昌弘 さん（以下、柳田）：自分がイニシアチブを持って開発を進めている場合は、宇山さんと同じで新しいもの好きという感じの選定はしません。自分が組む自信がある技術や、ほかの人から見たときの可読性を重視します。 複数人で行う、あるいは引き継ぎが発生するような開発であれば、アーキテクチャはMVCやMVVCです。ドメイン駆動設計（DDD）は理解するのが大変そうなので。 また、テストは書かない派です。サービスが大きすぎて一人のエンジニアだけでは全容を把握できない場合はテストを書いてもいいと思いますが、クライアントサイドでテストを書くと少し危険です。テストを書くことによって思考停止に陥り、逆にチェックが甘くなるというデメリットもありますね。
伊藤：テスト駆動開発においてはテストを書いていくことでコードの保証をしますが、書かないほうがいいのでしょうか？
柳田：ある程度レベルが高いエンジニアによる少数精鋭のチームであれば不要だと思います。人から聞いた話ですが、例えばメルカリさんはiOSエンジニアだけで10人いて、学校を出たばかりのメンバーもいるそうです。そういう場合はもちろんテストが必要です。でも、iOSやAndroidでそれぞれ2～3人という規模であればどうだろうか、ということですね。あくまで僕の意見ですが。
伊藤：僕はある程度コードの保証もしつつ、開発速度も落とさないようにしたいというところで重要な部分はテストを書く派です。
メンバー同士で仕様をどう擦り合せるのか
伊藤：アプリが成長するとチームにもいろいろな方が入ってきますよね。例えばプロダクトに対して今までの設計を根底から覆すようなリファクタリングの新しいプルリクが来たとしたら、チーム内での同意も必要です。 こういった状況において、阿部さんはどうやってメンバー同士で擦り合せますか？
阿部：僕はどちらかというと提唱者側として動くことが多いですね。ホワイトボードに設計やその意図を書いて提示し、改善案を出してもらうようにしています。
伊藤：みんなでわいわい話しながら同意を得ていく形ですか？
阿部：そうですね。大体のイメージを伝えてから実際にコードを出して話し合うといった感じです。一部導入してみて、ダメなら捨てればいいですし。
伊藤：宇山さんはいかがですか？
宇山：人数が少ないチームが多いのと、リファクタリングなどのコード改善はボトムアップで意見をもらうパターンが圧倒的なので、あまり話し合って決める感じではありませんね。最近は意見が上がってきたらすぐに採用することが多いです。話し合いも無しにいきなりマージされることもあります。
伊藤：事後報告だと後から「そんなの聞いてない」ということもありそうですが……。
宇山：そういう雰囲気になったことは無いですね。「あのメンバーならやりそうだ」という空気感がある上でのことなので、実際にマージされても納得します。
伊藤：柳田さんは一人で開発することが多そうですが、チームで設計を話し合うことはありますか？
柳田：大体は宇山さんがおっしゃったような感じです。例えば「ここの処理はこういうパターンが増えてきたからシングルトンでマネージャを挟みたい」とか「ここに線を一本入れたい」といったことは誰かが言ったらすぐに採用しますし、事後報告もあります。
伊藤：意見が対立することはありますか？
柳田：そこまで熱くはなりませんが、ありますよ。大体はトレードオフの内容です。そのくらいのやり取りがきちんとあったほうがいいのかなとは思います。逆にそういった議論が無いのは、メンバーのレベル感が揃っていないということもあるのかもしれません。
学習コストなどを鑑みて安易な新技術導入は避ける
伊藤：僕個人は新技術を導入しようとして失敗した経験もあるのですが、みなさんは新技術を形骸化させないように運用時に大事にしていることはありますか？タイミーさんは新規事業にもいろいろと取り組まれているかと思いますが、新技術の導入はされているのでしょうか。
阿部：スピード優先なので、今は特に予定していませんね。 仮に導入するとすれば、浸透のために頑張って口酸っぱく言いますね（笑）。なぜそれを導入したのか、どういうメリットがあるのかを伝える必要があります。ただ、それだけでは理解できないので実際に触ってもらい、慣れ親しんでもらうようにもします。
伊藤：宇山さんはクライアントに新技術導入の提案をすることはありますか？
宇山：ありますよ。僕はIIJの水田IoT関連事業に携わっているのですが、「最新技術を使おう」という雰囲気だったので、AWSを使ったサーバーレスな環境にしました。
伊藤：新技術は頑張って調査しないといけないことも多いと思いますが、どういった感じで提案をするのでしょうか？
宇山：調査に時間がかかるものはやはり学習コストも高いので、そもそも提案しません。導入はしたものの難しすぎたからやめるというパターンもあります。IIJの場合はすんなり導入できそうだったから提案できたという感じです。
伊藤：いかにシンプルにできるものかというところがポイントですね。柳田さんは先日neeboorをリニューアルしたそうですが、技術刷新は行われたのでしょうか？
柳田：あれはObjective-Cで開発していてだいぶ古かったので、全部作り直しました。iOSとAndroid、API、フロント、サーバー、管理画面など含めて僕が30万行書きました。1年半かかりましたよ（笑）。
伊藤：すごい（笑）。気をつけた点はありますか？
柳田：それこそ現在のステーブルな技術をベースとしながら、こだわりを入れるようにしました。エンジニアというよりプロデューサーのような視点かもしれませんね。UIもきちんと書きました。
開発現場から見る今後の業界のトレンド
伊藤：今後のトレンドについてもお伺いできればと思います。今回のイベントもコロナの影響を受けてオンライン開催ということになりましたが、業界的にもいろいろと変化が出てくると思います。阿部さんはここ最近で運用が変わった部分はありますか？
阿部：オンラインがメインになったことで、全員がドキュメント化を強く意識しながら働いているなと感じます。ものごとを明文化する動きが強まっているということですね。後からいろいろな要件を見直さなければいけないケースが増えてきました。
伊藤：なるほど。宇山さんはいかがですか？お客さんとのやりとりや仕事の進め方は今後変わっていくのでしょうか。
宇山：コロナによる情勢を迎える以前からリモートだけで済む現場は多かったですし、この機会にさらに増えるのではないでしょうか。ビデオチャットでコンサルをするようなサービスも流行るんでしょうかね。
伊藤：1時間だけコンサルをするような仕事はお手軽にできそうですよね。
柳田さんには技術面をお伺いしたいのですが、iOSは最近Combineが登場したり、Androidはアーキテクチャ コンポーネントの中でMVVMを取り入れる流れが見られるかと思います。今後、アプリのアーキテクチャはMVVMが主流になっていくのでしょうか？
柳田：僕が考える限りは特にデメリットも無いので、今後主流になっていくんじゃないでしょうか。それなりに使いこなせる人が増えてくれば問題無いと思います。 アプリのサービス仕様にもよりますけどね。そこまでUIを弄る必要が無いのなら不要かもしれませんから、何を作りたいのかを踏まえての選択になります。
伊藤：全体を見たときに最適なものを選ぶということですね。
柳田：やはり意図が欲しいですよね。エンジニアの人はどうしても新しかったり自分の好みだったりする技術を推したくなってしまいますから。
※当日のオンラインCTOmeetupイベントは、Youtubeライブで行われました。
オンライン上で質問を募集、質疑応答タイム
マルチプラットフォーム開発のメリットとデメリット
伊藤：では、質疑応答に移ります。「FlutterやReact Nativeなどのマルチプラットフォームを使用することはありますか？導入を検討しているのですが、どういったときに導入したら効果が高いのでしょうか」という質問が来ています。みなさん、まずFlutterやReact Nativeを使ったことはありますか？
宇山：僕は本格的に使ったことはありません。
阿部：Flutterのver1.0が出た頃に少し触ったくらいですね。
柳田：うちもありません。僕はそもそもマルチプラットフォームをかなり懐疑的に見ています。ただ、どういったときに導入するのが適しているのかという話であれば、シンプルなサービスやベーシックなアプリを開発するときだと思います。iOSとAndroidは全く違うUIの書き方をするケースがあり、Flutterでは対応できないはずですよね。なのでHPを制作する際にWordPressを使うか使わないかに近い感覚です。
伊藤：宇山さんはどう思われますか？
宇山：BtoBだとさほど見た目を気にされることが無いので、そういうときはiOSとAndroidを両方同時に出せるのがマルチプラットフォームのメリットになると思います。 僕は技術選定をする際に少しだけ弄りましたが、普通にiOSやAndroidで開発をスタートするよりも、ある程度学習コストや環境整備に時間がかかります。そういった点が判断基準になるかもしれません。
柳田：情報も少なくありませんか？
宇山：少ないですね。新旧の情報が混在しているので、探した情報の通りにやってみたら実は古いバージョンの内容だったということが多かったです。更新が早くて追いつかないんですよね。React Nativeは歴史があるフレームワークなので新しいバージョンでは廃止になっている機能がありますし、Flutterは今はまだ探り探りでいろいろと実装しているようなので、アーキテクチャレベルから変わることがあります。素早く情報をキャッチアップしないと上手く使いこなせなさそうだという所感です。
伊藤：阿部さんはそのあたりいかがでしょう？
阿部：僕は完全にリソースに依存すると考えています。潤沢なリソースがあるならやりたい技術を使えばいいんじゃないでしょうか。我々の場合はSwiftしか書けないからネイティブにせざるを得ないという状況ですし。 どうしてもJavaScript かTypeScriptで書きたいという人がいるなら、新しくSwiftやKotlinを学習するよりもReact Nativeを選択したほうが学習コストは安いですよ。 FlutterはDartに若干癖があるのでそれを受け入れられるかどうかですね。あとはGoogleへの信仰心が厚ければアリかもしれません（笑）。Googleは新しいOSを作っているので、そういうものの開発を将来的にやりたい人にもいいかもしれません。
宇山：僕はGoogle信者なんですが、ちょっとDartは心折れかけています（笑）。
伊藤：企業のフェーズにもよるかもしれませんね。要件としてiOSとAndroidをとにかく爆速で出したいということであればマルチプラットフォームは選択肢に乗りそうです。その後の運用をどうするのかという問題はありますが、そういったフェーズや人的リソースで言語は決まる気がします。
新規アプリ開発をスピーディに行うなら最小構成を定義せよ
伊藤：「新規アプリの開発期間はどれくらいですか？」という質問にも答えたいと思います。みなさんいかがですか？
宇山：僕はプロトタイプしか作らないので、長くても1ヶ月程度です。短いと1週間で作るパターンも多いですよ。
柳田：僕が受託開発をしていた頃はリリースまで2～3ヶ月くらいかかることが一番多かったです。コードを3万行くらい書く規模感ですね。2ヶ月は早いほうだと思います。中の下くらいまでの規模の開発であれば、3ヶ月前後が現実的なラインではないでしょうか。
阿部：タイミーの場合は1ヶ月で作りました。今新規でやっているものは2ヶ月しか時間がありません。
伊藤：基本的には1～2ヶ月で作って検証する形なんですね。
阿部：それが一番いいと思いますよ。
柳田：ただケースバイケースな部分もあります。自分がベンチャーとして会社を立ち上げたときは開発に結構時間をかけました。例えばスマートニュースさんなんかもリリースまでに2年かけて、かなり作り込んだそうです。
伊藤：それはプロダクトがヒットする見込みがあったから時間をかけられたのでしょうか？
柳田：試行錯誤もあったと思います。ベンチャー系は勢いでプロダクトをリリースする会社が多いのですが、そうではない会社も一部にはあるということですね。開発してから会社を設立してリリースという形なら開発していても事業計画なんて関係無いですし、社員に迷惑がかかるわけでもありません。余裕があります。
伊藤：なるほど。もう一つ聞きたいのですが、アプリを早く作るコツはあるんでしょうか？
宇山：作っているとあれもこれもと機能をつけたくなるのですが、そこを割り切れるかどうかですね。常に最低限必要なものだけを考えるようにしています。
柳田：僕の場合はiOSやAndroidに今まで使ってきたコードがあるので、それを上手く使い回してスピードを出すようにしています。
伊藤：経験量が物を言う感じですね。
柳田：知らないことをいちいち調べるのはやはり大変ですから、経験は大事だと思いますよ。ちょっとずるいかな（笑）。
伊藤：大事です（笑）。阿部さんはいかがですか？
阿部：お二人の言うことが全てのような気がしますが、僕自身はMVPを最初に決めて最小構成を定義し、そこから削れるところを削っていきます。機能追加はリリース後です。これを徹底しないと、特にフロントでアニメーションなんかをやり始めると無限に時間が溶けていきますからね。「ここはやらない」と振り切ります。UIロジックを減らせば減らすだけ早くなりますよ。
機種依存とUIデザインについて
iOS・Androidアプリ開発の共通点と違い
伊藤：柳田さんは例えば物量が多い開発をしなければいけないとき、iOSとAndroidのどちらから作ることが多いですか？
柳田：僕はiOSからですね。得意ですし、iOSは端末が限られているのでとりあえずのチェックがしやすいという点もあります。
伊藤：僕の中でSwiftとKotlinは似ていて、一度Swiftで書けばKotlinは若干変えるだけで良いと考えています。あまりコストはかからないのかなと思いますが、その辺りはいかがでしょうか？
柳田：そう思いますよ。ただ、一人で両方作るのは特殊なケースです。普通のプロジェクトはiOSとAndroidエンジニアが最低一人ずついて、同時に作る前提ですよね。同時進行は設計がブレず、同じようなプログラムにできるのがメリットだと思います。
伊藤：両方のOSを一人で書くにあたって気をつけている点はありますか？
柳田：伊藤さんがおっしゃったようにSwiftとKotlinは言語的にさほど変わらないので、特にありません。僕はあまり継承を使わないので、例えばリスト系のアイテムには共通のプロトコルやインターフェースをつけたりします。処理系も同じなんですよね。iOSはDelegateでKotlinはListenerです。Genericsも両方使えますし。 ただ、UIは多少どう表現するべきかという視点がありますね。特に遷移です。iOSは横にスワイプしてAからBに遷移しようとしたときにスワイプ途中で戻ることができますが、Androidの場合は遷移途中でポーズができません。そういうところに気をつけるくらいです。
伊藤：宇山さんはどういった基準で言語やOSの選定をしますか？
宇山：Androidはapkファイルにして内部でシェアできるので、今は比較的Androidが多いです。apkで渡して開発を進めるということですね。
伊藤：なるべく早くお客様に届けて使ってもらえるようにするということでしょうか？
宇山：そうですね。App Storeでは公開したくないということもあります。
伊藤：ちなみに、既存のプロダクトから別OS版を作ることはありますか？
宇山：ありますよ。最近はiOSとAndroidのクラスが同じような仕様になってきたので、クラス名とメソッド名だけを変えれば動くというパターンもあります。
伊藤：コピペで作る感じですか？
宇山：そこまではいきませんが、近いですね。
柳田：ただ、Androidは一つだけiOSと比べてコード的に面倒なところがあります。ListenerのRecyclerViewやListViewを利用するときにAdapterをオーバーライドするのですが、そのときにListenerのResponder Chainのようなものの階層が一つ深くなるんです。これはiOSではそこまで起きない問題です。人によってはイベントバスを気軽に使いますね。
伊藤：阿部さんはiOSがメインということですが、タイミーで最初にiOS版をリリースし、後からAndroid版をリリースすることになったときにiOSとAndroid間で共有した知見はありますか？
阿部：基本的にはAndroidチームに丸投げする方針でした。一つだけ、モデルのAPIリクエスト回りはレスポンスの型の治安があまり良くないので、柔軟に作っておかないと平気で破壊的な変更が発生してきて辛いということは伝えましたね。あるリクエストには存在するのに、あるリクエストでは存在しないパラメータがあるといった現象が頻発したんです。
柳田：そういう場合はプロトコルを使うと上手くいきますよね。
阿部：そうですね。だからそういうことを考えて作っておいたほうがいいというアドバイスだけはして、あとは丸投げしました（笑）。
伊藤：新機能やAPIが増える際は、iOSとAndroidで作成するエンティティなどの意識を合わせながら開発を進める感じでしょうか？
阿部：そうですね、今はサーバーサイドと連携して型の整備を進めているところです。サーバーベースで型定義をして使い回していこうという強い意志をサーバーサイドに伝えています。型について意識しているのがiOSとAndroidチームなので、両者も連携しながらという感じです。
ネイティブがマルチプラットフォームより優れているポイント
伊藤：マルチプラットフォームについては1部でも少し触れましたが、柳田さんはマルチプラットフォームに比べてネイティブのほうが優れているのはどんな所だと思いますか？
柳田：厳密に数字を確認したわけではありませんが、ネイティブのメリットは完全にパフォーマンスの良さですね。細かいグラフィックやアニメーションの描画もクロスプラットフォームでは絶対にできない部分だと思います。
伊藤：凝った作りにしようと思うと、やはりネイティブのほうに分があるということですね。
柳田：手間をかけたくないということであればReact Nativeのほうがいいのかもしれません。一人で二つのアプリを作れるわけですから、そこはトレードオフだと思います。
伊藤：宇山さんはこれまでマルチプラットフォームを提案したことはありますか？
宇山：今のところはありませんが、今後提案する可能性はあります。実際に採用されているシーンも増えていると実感していますしね。堅めの現場でも提案してみるのはアリかもしれません。
伊藤：阿部さんはマルチプラットフォームを展開する予定はありますか？
阿部：予定は全くありませんが、B向けのアプリを作るとなったら選択肢に挙がると思います。B向けの場合、iOSとAndroidで挙動を変えたくないからです。
宇山：React Nativeなら1種類のマニュアルで済むというのはあるかもしれませんね。
UI/UXにどこまでこだわるべきかはアプリの性質に依存する
伊藤：次はUI/UXについてディスカッションしていきたいのですが、柳田さんはUI/UXの改善で意識していることなどはありますか？
柳田：C向けでコンテンツ系のサービスの場合はできるだけOSSを使わない、自分できちんと定義するという部分を強く意識しています。例えばダイアログを一つ出すにしても、OSのデフォルトのアラートビューを出すと世界観が崩れてしまうことがあります。ゲームなら必ずオリジナルのダイアログですよね。ゲームは極端な例だとしても、そういった部分を考えたりします。
伊藤：では、UIを作るにあたって良い描画をするためのコツはありますか？
柳田：現在は言語レベルでも拡張がたくさんあるので、そういうものを使うといいですよ。iOSならUIView.animateでもDampingなど豊富なアニメーションがありますし、Androidも自分で書くことができます。伊藤さんはデザイナーが作ったデザインをそのまま動かしたり制御できるLottieが好きですよね（笑）。
伊藤：割と好きです（笑）。
柳田：あと、僕はiOSでMacawというライブラリを使っています。これはCore Animationのラッパーですね。Core Animationはベタ書きでCA○○や○○setといったものが登場するのですが、Macawはこれらをオブジェクト指向のようにしてくれるOSSです。こういうものは導入しています。
伊藤：なるほど。宇山さんはクライアントに対してUI/UXをどういう形で提案していますか？
宇山：最近はB向けが多いので、マテリアルデザインに準拠したものをおすすめしていますね。UIをわざわざ実装する時間はなるべく少ないほうがいいので、仮にデザインを起こすにしても基本的にネイティブの標準デザインに合ったものにしたほうがいいとお話しします。 特にB向けの場合はデザイナーさんが不在で、使っている色数が多かったりパターンを使っていたりするんですよ。なるべく色味を統一して、グラデや角丸は使わないようにしてもらいます。
伊藤：タイミーさんの場合はどういう風にデザインを決めているんですか？
阿部：うちはiOSでデザインを組んでもらい、実装しにくいところはAndroidエンジニアにリクエストをもらって折り合いをつけています。凝ったデザインにしようと思えばできるけれど、UXが変わらないなら安いほうがいいだろうという話になることが多いです。
伊藤：Androidで作成したデザインをiOSに逆輸入することはありますか？
阿部：ありますよ。Androidチームが「こうしたほうがスマートになる」と提案してきて、デザイナーが同意した上でiOSチームに伝わり実装したりしました。
伊藤：臨機応変にお互いの良いところを切磋琢磨しながら導入しているんですね。
阿部：その辺りのコミュニケーションは多いですね。
ライブ中に質問を募集、リアルタイムに回答
今後はReact Nativeが採用される場面が増えていく
伊藤：では第2部の質疑応答に移ります。「フリーランスの友人に聞くとReact Nativeの案件が増えているそうですが、みなさんの印象はあまり良くない感じでしょうか？」という質問が来ています。フリーランスの立場として宇山さんはどう思われますか？
宇山：増えていますね。Android Javaを扱っていたような会社が普通にReact Nativeエンジニアを採用しているので、特にBtoBの領域では今後もっと増えていくと思います。
伊藤：FlutterとReact Nativeはどちらが増えていくと思いますか？
宇山：React Nativeだと思います。FlutterはやはりDart言語のハードルが高いですから。React Nativeは言語自体はJavaScriptでいけるので、既にJavaScriptのエンジニアを抱えている企業でも採用がしやすいというイメージがあります。
伊藤：柳田さんはどう思われますか？
柳田：受託系のサービスであれば選択肢として増えてくると思います。例えばタイミーさんはタイミーという会社の名前で、タイミーという名前のサービスを出していますよね。会社とプロダクトが一心同体というレベルであれば、アプリもネイティブでかなり精密に作らなければいけないと思います。でも、普通の会社でキャンペーンアプリを作るとか、業務フローを行うアプリくらいであればそこまでこだわる必要はありませんから。
伊藤：阿部さんはいかがですか？
阿部：React Nativeに対応する理由に、JavaScriptやTypeScriptで書けるという要素はやはりあると思います。React Nativeを選定すれば当然Webのフロントが書けるし、node.jsがあるのでサーバーサイドも書ける。一つの言語で開発の全体を見れるようになるんですよね。 ただ、こう言うと一見学習コストは低いようにも思えるのですが、実際は各領域で学ぶべき内容は全く違うので、それほどではないだろうというのが僕の所感です。
宇山：おっしゃる通りだと思います（笑）。
阿部：それでも選定するという人は多いと思うので、多くはなると思います。僕自身はTypeScriptなら書いてもいいかなという感じですね。でもやはりSwiftが好きなのでSwiftで書きたいというだけで、印象が悪いということは無いです（笑）。
アプリ開発最大の難関はAppleの審査？
伊藤：「アプリ開発をする中で新規企画、開発、テスト、リリースをするまでの苦労を教えてください」という質問はいかがでしょうか。これは僕も聞いてみたいですね。
阿部：うちはテストがひたすらに大変ですね。タイミーはマッチングアプリなので、案件がマッチングして初めて現れる画面が存在しています。ドメインに依存したテストは苦労します。
伊藤：専門のQAチームなどはあるんですか？
阿部：そこまで人材がいないですね。基本的には実装者がテストをして、大規模なリリースのときは全員で頑張ります。
伊藤：テストをするときはテスト仕様書に従う感じですか？
阿部：そうですね。仕様書を書き出して潰していく形です。UI回りはひたすらスクショを撮って違和感がないかをデザイナーにフィードバックしてもらいます。ただ、一番大変なのはAppleの審査だと言っておきます（笑）。
伊藤：最大の壁ですか（笑）。作ってもリジェクトされるということですよね。
阿部：先日も急に「非ログインユーザーでも案件を見れるようにしなさい」というリジェクトが飛んできて、全てのリリースが止まるという事件が発生しました。
伊藤：どう対処したんですか？
阿部：クリティカルなバグだったので、Appleと交渉してなんとかリリースだけはさせてもらいました。その後頑張って実装し直しましたよ。みなさん、ログインの必要性がないアプリはそれだけでリジェクトされるので気をつけてください（笑）。
伊藤：ありがとうございます。宇山さんは苦労話はありますか？
宇山：要件が複雑だと普通に大変ですよね。それくらいでしょうか。
伊藤：柳田さんはどうですか？
柳田：僕もほとんどありません。
宇山：「これヤバいな」というものはわかるので、事前に避けちゃいますよね。
柳田：大体のことは今まで経験してきたので（笑）。
伊藤：なるほど。では今回のCTO meetupは終了したいと思います。みなさんありがとうございました！
