こんにちは。ノベルチームでデザイナーをしている 
id:murata_s です。先日カクヨムでは、新しいバージョンのアプリをリリースしました（iOS、Android）。読む専用のビューワーアプリとして、名称も「カクヨムViewer」と改めています。
開発面では、これまでネイティブとWebViewで構成されていたアプリに、React Nativeという技術が加えられたことが大きなトピックです。技術方面での具体的な使用感などについては一緒に開発を担当したエンジニアさんが別の機会に発表してくださるとのことですので、本稿ではデザイナー目線で触った感想を述べたいと思います。
やったこと
この度のアプリ開発で導入されたReact Nativeですが、個人的にも初めて触る技術でした。どのようなものなのかまず知ろうということで『Atomic Design』という本を読んで予習することにしました。この時点では、どうやらJavaScriptでiOS/Androidの両プラットフォームのアプリが作れるらしいということがわかりました。何事もそうですが、新しいものに触れるときはわくわくしますね。Atomic Designのコンポーネント設計の考え方は普段のウェブ開発でも馴染みのあるものでしたので納得感がありました。
レイアウトに関して、デザイナーがイチからReact Nativeを書き始めるのは難しいので、チームの方針として、大きなレイアウトをエンジニアさんに先に組み上げてもらい、その後細かなレイアウトやトーンの調整などをデザイナーが担当するというような進め方で開発がはじまりました。
少しずつコードを触っていく中で、自分の中でもReact Nativeのコツをつかんでいきます。さて、実際どのような粒度でコミットをしていたのか、印象に残っている例を交えて紹介したいと思います。
StyleSheet.create
React Nativeでは StyleSheet.create にスタイルを書いていくのですが、ここを触ってデザインを調整していくことがメインの仕事になりました。利用可能なプロパティもCSSとほぼ一緒のものですのでウェブの知識をそのまま活かせました。ドキュメントを見れば使えそうなプロパティが探せます。flexboxも見慣れたものです。
const styles = StyleSheet.create({ container: { flexDirection: 'row', alignItems: 'flex-start', justifyContent: 'flex-start', paddingVertical: 14, paddingHorizontal: 16, }, })
Platform.select
ひとつのコードで2つのプラットフォームのレイアウトができるというのは大変便利なものですが、たまに別の値を指定したくなることがあります。例えば罫線の太さです。下記の例では変数にしてありますが、慎重に調整したい場所はこうして Platform.select を使って作り分けることができるようになっているのは助かります。
const borderWidth = Platform.select({ ios: StyleSheet.hairlineWidth, android: 1 }) const borderColor = Platform.select({ ios: '#999', android: '#ddd' })
TouchableHighlight
タップした領域の背景色が変わる TouchableHighlight というコンポーネントがあります。似たコンポーネントに TouchableOpacity というものもありますが、これらをコンテキストに応じて入れ替えたりしました。TouchableOpacity とは違って TouchableHighlight は直近の子要素として一つの要素しか持てませんので、View を増やす簡単な仕事もしました。
<TouchableHighlight onPress={this._onPress} underlayColor={underlayColor}> <View style={styles.container}> … </View> </TouchableHighlight>
などなど、今回はこのくらいの粒度でReact Native開発に関わらせていただきました。
感想
ウェブを主な領域としている私でもすんなり取り組めたというのが一番の感想でした。XcodeやAndroid Studioでネイティブ画面のデザイン調整も経験がありますが、それらをこなす上で避けて通れないのがある程度の初期的な学習コストなのかなと思います。チームのリソースに余裕があればじっくり取り組めるのですが、常にそのような状況に恵まれるとも限りません。その点React NativeはHTML/CSSの知識があればそのコストを抑えてデザイナーがシュッとアプリ開発に参画できるという点はひとつ魅力だと思いました。
ガイドラインとの距離性
アプリを作るときにはいつも考えるのですが、それぞれのプラットフォームのデザインガイドラインにどこまで則るかという話題があります。React Nativeを利用する時点で作り分けはしませんので、ある程度汎用的なUIを検討する必要が出てきます。私の場合は基本的にはガイドラインは参考程度に参照しつつ、ゼロからデザインを考えるというスタンスでおりますが、今回はシンプルなリスト表示を実現することにフォーカスしていたので、この点スムーズに設計できました。そもそもウェブではガイドラインは自らの手で作っていかなければならないものですから、ウェブ的な思考の延長で、プラットフォームの思想との折り合いを探っていくという作業だったのかなと思います。
変更の確認が早い
作業中はmarginを少し変更しただけでも画面を更新したくなるものですが、一度ビルドしてしまえば、あとは画面更新のショートカットキー（Macならば⌘+r）を入力するだけで素早く画面が更新できます。これは従来のアプリ開発と比べると大きなメリットで、変更のたびにビルドをして数十秒待つというようなことがなく、すばやく試行錯誤ができて快適でした。
Storybook
Storybookという、ひとつひとつのコンポーネントを任意の状態ごとにプレビューできるツールを導入していただきました。大まかなレイアウトをエンジニアさんが組み上げてから細かな調整をするという手順でしたので、有り難いことに私が触る頃には画面全体でそれぞれのコンポーネントのスタイルが調和しているかどうかを確認していくフェーズになっており、私個人の利用頻度は高くありませんでした。コンポーネントの特定の状態が現れるように、手で状況を再現する必要がなく、様々な状態を一覧できるのはとても便利だと思いますし、エンジニアさんもコンポーネントの設計段階で重宝したと仰っていました。
さいごに
今回の開発はざっくり言うと、WebViewの画面をReact Nativeで作り直すというようなことをしたのですが、スワイプ操作による連続的な画面遷移が行えるようになったり、アプリらしいインタラクションを取り入れたりしたことで、これまでよりもリッチな使い心地のアプリに仕上がったと思います。アプリで表現したい内容とReact Nativeの特性とがマッチしたからでしょうか、デザイン面での妥協も少なく、順調にプロダクションのリリースまでこぎつけることができました。
新しい技術利用の挑戦も含んだアプリ開発でしたが、今後も挑戦的な姿勢を持ちつつ、サービスがより良くなるようにデザイン面での支援をしていきたいと思います。
