【新雲堂】React Native 開発日記

自己紹介

東京コアののムンと申します。
マレーシアクアラルンプール出身です、現在東京に在住しております。
当ブログは自分が担当した当社のアプリ開発の記事を述べています。
宜しくお願い致します。

新雲堂

入社後に初めて上司に任せて頂いた作業は「雲堂」というアプリのiOS版を開発することになりました。その後、お客様から、新しいバージョンのご依頼があり「新雲堂」プロジェクトが開始しました。今回、アプリを着手するにあたり、どのようなモバイルアプリフレームワークがよいかを、上司やエンジニアたちで検討がされました。その結果、「React Native」を採用することにしました。

React Native

Facebookが開発したiOSとAndroidのアプリが作られるJavaScriptのフレームワークです。JavaScript言語一つだけで、OSに関わらず両方のプラットフォームで動くものが作れます。私は当社のReactJSを使っている別の案件をやったことがありましたので、Reactの経験がある人にとって勉強しやすく長い時間が必要ありません。また、JavaScriptはWeb界隈ではよく使う言語なので、他の言語と比べると開発メンバーが集めやすく学習コストも低いです。

開発環境構築

React Nativeの公式サイトによるとプロジェクトの作成は「Expo」と「Building Projects with Native Code」の二つの方法があります。最初は「Expo」の方法を使いましたが、仕組と使い方の勉強はかなり時間がかかりますので、「Building Projects with Native Code」の方式でプロジェクトを始めました。

プロジェクトの作成手順は基本的に以下の通りです（macOS端末向け）。

npmでreact-native-cliをインストール
```
npm install -g react-native-cli
```
＊「Building Projects with Native Code」の場合は予めXcodeとAndroid Studioのインストールが必要です。
ターミナルでプロジェクトを作成
```
react-native init New_Undo
```
実行＆デバッグ
```
react-native run-ios
```
```
react-native run-android
```
この二つコマンドどちらを入力しても動くはず、または各プラットフォームのIDEでネイティブ方式のように実行することも可能です。

＊Androidの場合はアプリ起動する前、エミュレータが起動中の状態が必要です。

React Nativeはアプリ起動中でもリロードする機能があります。
- Xcodeのシミュレータで、Command+Rで実行します。
- Android Studioのエミュレータで、Control+M（macOSの場合はCommand+R）で設定を呼び出して「Enable Hot Reloading」を選択し、ホットリロードを有効にします。

開発体験

React Nativeは基本的にフロントエンドの技術ですが、一部のライブラリを使う時に少しネイティブコードを書くこと場合もあります。ネイティブのコードと言っても、GitHubでそれらのライブラリを作られていた開発者のREADMEに記載があるのでそれに従えば問題ないと思います。

JavaScript開発者が今まで使っていたライブラリはReact Native開発でも適用可能なので、これはJavaScript開発経験がある私にとって優しく親しみがある環境です。この点はReact Native開発において、かなり楽な点だと思います。さらに、Viewのコードを少しだけ変更した場合は再ビルドせず、React NativeのHot reloadingを使うと、コードの変更はシミュレータに伝達され、直ぐ変更後の結果が確認できます。海外だけでなく、日本国内にもReact Nativeのコミュニティが拡がっています。国内は勉強会が常に行っていて、問題に直面し悩む時に、世界中の開発者と意見を交換したり手伝って貰ったりできます。

意外にReact Nativeのアプリを開発する時に足りない部分が多いです。iOSは充実していますが、Android側の方が少なく、コンポーネントが両方でも対応できるライブラリを追加しなければいけないです。例えば、各プラットフォームのUIを補助したければ、UIコンポーネントがまとまった「Native Base」を使います。但し、開発中はライブラリを入れすぎましたら、将来的にどのライブラリがメンテナンスするか、結構大変だと思います。

元々React Nativeは生JavaScript用に開発されましたが、今回は型付きのTypeScriptを使うことにしました。TypeScriptでコードを書くと、当社の他のエンジニアにとってコードを読みやすくなり、良くないコードを未然に防げます。これは将来のプロジェクトメンテナンスに対して、非常に便利で有利です。今回は、TypeScriptを導入する方法として「react-native-typescript-transformer」というライブラリを使いました。

「雲堂」の開発で使っている主なライブラリは以下の通りです：

Native Base – UI補助
React Native Safe Area View – iPhoneX端末対応
React Native Sound – 音声を流す
React Native Splash Screen – スプラッシュ画面
React Native TypeScript Transformer – TypeScript対応
React Navigation – 画面遷移
Redux – 状態管理

注意点

React Nativeを使う時に注意しなければいけないこともあります。個人の開発体験によって簡単に説明します。

慎重にライブラリを選ぶ

相応しい高質なライブラリを選ぶことは検討が必要です。例えば、不具合の発生が多かったり頻繁にメンテナンスしていないライブラリは開発者にとって少し不安があります。他の開発者が勧める人気があるライブラリを採用した方がいいです。その上、ライブラリの使い方がドキュメントではっきり書いてあることも重要です。

各端末のUI対応

端末によって縦横の大きさは違いますので、UIが崩れる場合があります。タブレットとやスマホに関わらず、ユーザに快適なアプリ体験をさせるため、違和感がないUIを表示することは大事です。

画面遷移の設計

XcodeやAndroid Studioを用いたネイティブ開発と違って、Interface Builderや、画面遷移を定義できるツールなどは提供されていません。なので、画面のナビゲーションやデータの渡し方はどういう風に動作するかわかりにくいです。開発を始める前に、予め画面遷移のモックアップを設計した方がいいと思います。それをしなければ、アプリの規模が大きくなると各画面の対応が難しくなってしまいます。

ファイルやディレクトリ構成

プロジェクト作成の最初は垂直分割の構造でしたが、ファイルが散らかっていて、大規模な構成になった時に管理しづらく大変です。水平分割の構造をすると、ファイルがページごとのディレクトリ配下にまとめて管理しやすくなります。ファイルの役割もわかりやすいし、プロジェクトの構造も整理整頓に見えます。

まとめ

近年ではReact Nativeの人気が上がっていますので、経験がある開発者は結構多いです。雲堂の基本実装は二週間程をかかりました。開発完了の時間は思ったより早かったです。自分のフロントエンド能力はあまり得意ではなく、一番難しかったところはReact NativeのLayoutを調整することです。コードから反映した結果は各プラットフォームのUI表示が異なる場合がよく発生します。それだけでなく、アプリの状態管理「Redux」の実装も上手くいかなかったです。公式ドキュメントを読んでも、その仕組をなかなか理解できませんでした。しかし、実際にコードを書くことによって理解することができました。

初めてクロスプラットフォームのアプリを作ったので、開発の過程で色々な知識を身につけました。特にTypeScriptの書き方やデータの状態管理は元々私がやったことがなかったものです。React Nativeを全く触ったことがない私にとっては今回のアプリが作れたことはすごく達成感があります。

【BtoBの企業さま向け】ランディングページを構築するメリットとは？

TV広告に迫る勢いのデジタル広告

ひと昔前までは「広告」と言えば「テレビCM」「新聞・雑誌広告」などが中心でした。

これらマスメディア広告は一度に大勢の方に訴求できる反面、非常に高価で大手企業以外は手を出せないでしょう。

それに対して「Web広告」は、ターゲットを絞って小規模で始めることができるため、マスメディア広告に比べてはるかにリーズナブルです。

また、実際に何人ぐらいの方がホームページを見たのか、そのうちの何％が申し込んだのかなど「効果」を測定しやすく、運用しながらの対策や調整も可能です。

今や多くの企業や店舗がWeb広告で集客し、ダイレクトに売上を上げています。電通の海外本社「電通イージス・ネットワーク」は「世界の広告費成長率予測」で2018年中に「デジタル広告」は「TV広告」を抜いて最大のメディアになる、と予測されています。

（参照：電通イージス・ネットワークが「世界の広告費成長率予測」を発表）

「BtoC」企業では当たり前のWeb広告「ランディングページ」

「ランディングページ（Landing Page、LPと略されます）」をご存知でしょうか。通常のコーポレートサイト（会社概要や沿革などが掲載されている会社の公式ホームページ）とは違い、売りたい商品だけにフォーカスした1枚もの（1ページ）のWeb広告です。

「Web版のちらし」とも言えますが、紙の広告とは下記のような違いがあります。

Webは紙媒体と違ってスペースに制限がないので、商品の特徴や使用するメリット、商品に対する熱い思いを存分に掲載できる。
商品を検索したユーザーだけに広告表示ができるので、ターゲットだけに訴求できる。
「お申込みフォーム」「お問い合わせフォーム」を設置することで、ユーザーの気持ちが高まっている間に申し込みまで完了できる。

今や非常に多くのBtoC企業（中小企業や小さな店舗、個人まで！）がこの「ランディングページ」で売上を上げています。

御社の製品を必要としている企業に向けて、Webで訴求しませんか？

「ランディングページ」は「BtoC企業」では既に当たり前の営業ノウハウとなっていますが、「BtoB企業」ではまだまだ取り入れられていないのが現状です。

「企業向けの製品」であっても、従来型の営業、特に業務を妨げられる「突然の電話」や「訪問営業」には皆嫌気がさしているのではないでしょうか。

パソコン・スマートフォン活用が当たり前の時代、自社に必要な製品があれば皆「検索」して探します。

御社の製品がどんなに素晴らしくても、コーポレートサイトの「商品紹介」だけでは必要としているユーザーに情報を届けることは難しいのです。

「会社情報」とは別に「商品訴求」そして「集客・販売」に特化した「ランディングページ」を持つことで、御社の製品の魅力を必要としているユーザーに届けましょう！

ユーザーに見つけてもらうために大切なこと。

せっかく作ったランディングページも、ターゲットユーザーに見てもらえなければ役目は果たせません。

ユーザーはGoogleやYahooなど検索サイトにキーワードを入力し、お目当ての製品を探します。この時ランディングページを「適切に表示」させ、「クリック」してもらうことが重要です。

そこで「検索結果」ページ上部や右側の目に止まりやすい場所に「広告」として表示させる「検索連動型広告（リスティング広告）」という手法を使います。

大量の不特定多数のユーザーに訴えるマスメディア広告のようなインパクトはありませんが、ピンポイントで表示できるのでニーズに対応しやすく、無駄がありません。

また、通常の「検索連動型広告」は1クリックごとに課金されるクリック課金（Pay Per Click、PPCと略されます）なので、「ページを見てもらえた分だけの費用」になります。

1ヶ月の広告費の上限も設定できるため「毎月◯万円分の広告枠掲載」など、計画的な運用が可能です。

「ランディングページ」についてもっと詳しく知りたい方へ

「せっかく良い製品を作っているのだから、もっと必要とされている企業に知ってほしい、情報を届けたい、そして購入に繋げたい」という企業さま、お気軽にご相談ください！

IP電話クラウドPBXと秘書サービスを導入してみた〜調整編〜

担当のsaitoです。
よろしくお願い致します。

先日、IP電話クラウドPBXと秘書サービス導入のご紹介をさせて頂きました。

導入から数ヶ月が経ち、概ね順調に運用できておりますが、先日秘書サービスに関する「事件」が発生してしまいましたので、その顛末をまとめました。

発端

某日、お客様や関係者から「代表電話にかけても誰も出ない」「何十コールも鳴らしてからようやく応答があった」「営業時間中なのに留守番電話になった」というご指摘を受けました。
私も知らせを受け、試しに携帯電話から代表電話へかけてみると、本来であれば秘書サービスが応答するはずが管理部に直接電話が繋がりました。
このままでは業務に大きな支障が出る「事件」ですので、すぐに調査を開始しました。

原因

原因を調査したところ、秘書サービスが一時的にパンクし、かかってくる電話を捌ききれないという状態になっていました。
当社のための専任のスタッフを配置しているわけではないので、何らかの理由で一時的に電話が混み合い対応できないというケースは考えられる事態です。
秘書サービス側から、この日はインフルエンザで複数のスタッフが急に欠勤し、追加の人員が用意できるまで少ない人数で対応していたため例外的にこのような事態になったと説明がありました。

現在、代表電話の着信は次のようなフローで処理されます。

着信時、まずは秘書サービスの電話を鳴らす
1が一定時間応答ない場合、当社管理部の電話を鳴らす
2が一定時間応答ない場合、留守電になる

そのため、1が普段より時間がかかってしまった結果、2または3が実施され、混乱を招いておりました。

改善

1から2への、秘書サービスから当社管理部への切替時間を当初15秒（5コール）に設定しておりました。通常はこれで問題なく対応できておりましたが、今回の事件を受け、7秒（２コール強）に変更しました。この状態で暫く運用をしておりますが、今の所大きなトラブルは発生しておりません。

しかし、その分いままで秘書サービスが受けていた電話が管理部にかかってくる比率が上がってしまいました。
極力お客様をお待たせしないよう切替時間を短くする一方、管理部の負担が上がることにはなりますので、今後様子を見て最適な設定を探す必要がありそうです。

まとめ

当社は「IT前提経営」のもと、場所や時間に縛られずに働くノマド制を実施しています。
そのため東京コアは3〜4名しか出社しない日もあり、電話が同時にかかってきた場合などにお客様をお待たせしないよう秘書サービスを導入しました。
しかし結果として、秘書サービスの突発的な輻輳の発生と、転送タイミングの設定などの条件が重なり、お客様をおまたせしてしまうことになってしまいました。
そういった突発的な輻輳が発生しても極力影響を受けないよう、今回の調整を行いました。

今後もお客様、当社社員にとってより良い電話環境を目指し、最適な方法を模索していきたいと思います。