ID:7856さん

# どのようなサービスか 訪日外国人の方が、英語、中国語をはじめとしたさまざまな言語での問診が可能な医師にオンラインでリアルタイム医療相談を受けられるサービスです。 医療相談はビデオチャット・テキストチャットの形式で受けることができます。 また、本サービスでは訪日外国人を受け入れられることを表明した医療機関をマップ上に表示する機能もあります。 本サービスは患者向け、医師向けに分けて、ターゲットごとに以下の形で提供されます。 患者向け - モバイルアプリ（iOS, Android）（React Native） 医師向け - デスクトップアプリ（Windows, macOS）（Electron） - モバイルアプリ（iOS, Android）（React Native） # 行ったこと 基本的に、React Native を用いた患者向けモバイルアプリの開発を担当しました。 また、Web API 設計（REST）、データベースのスキーマ定義、バックエンド改修も行いました。 # 技術選定について ## React Native 本サービスはモバイルアプリとして iOS, Android × 患者向け、医師向けという4つの提供方法があるのですが、当時の人員状況では、ネイティブアプリエンジニアが各 OS に対して患者向け、医師向けの知識を持って開発することが厳しいと判断されました。 そこで患者向け、医師向けの知識を持って iOS, Android の両プラットフォームのアプリを開発することができる React Native の採用を提案しました。 当時の React Native のバージョンは 0.56 ほどで安定していないことが予想されたため、弊社のネイティブアプリエンジニアが有事の際にバックアップできることを確認したうえで React Native を採用することになりました。 React Native についての知見は以下を書きました。 [React Native をプロダクションで採用した知見を共有します \| Snow Robin's Tech](https://www.wantedly.com/companies/snowrobin/post_articles/136002) ## MobX サービス最初期は状態管理として Redux を採用していたのですが、当時 TypeScript と相性が悪い（型記述量が増える）ことに不満を持っていました。 そんな中、見つけた MobX という状態管理ライブラリが TypeScript と相性が良く、素朴に使う分には使いやすいことが分かりました。 担当するアプリのコードベースはすべて自分が書いたものであったので、2日ほどで Redux から置き換えることができました。 以降、サービスが自分の手を離れるまで MobX を使っていたのですが、書きやすく、見通しのよいコードになったかと思います。当時、Redux から置き換えてよかったと実感しました。 ※ 2019年11月現在では Redux と TypeScript の相性が良くなっているため、この内容は当てはまらないかもしれません このように比較的新しい技術に注目し、スピード感を持って開発体験を向上させる動きを行いたいと思っております。

# どのようなサービスか 委託元の会社さまで活動報告共有に使用される Web サービスを開発しました。 イメージとしては Backlog などの課題管理ツールのように、トピックに対してスレッドで会話を行うという雰囲気です。 UI デザインとパフォーマンスの観点からシングルアプリケーションであることが要件として求められていました。 # 行ったこと フロントエンドチーム（3人）のうちリード業務をメインとして、Web API 設計、データベースのスキーマ設計、バックエンド実装行いました。 ## アーキテクチャ フロントエンド部分ではアーキテクチャ設計に注力しました。 具体的には、DDD の戦術的な部分を取り込んだクリーンアーキテクチャもどきを取っていました（View, UseCase, Store（MobX を使った状態ストア）, Repository, Entity などが登場する）。 画面数が十数個からなるアプリケーションであり、フロントエンドが複雑になることが予想されたためです。 結果としては、良い面と悪い面がありました。 良い面 - 役割をハッキリさせたことで、各実装を置く部分が明確になったこと - 後に要求されたスマートフォン対応に比較的スムーズに済んだ 悪い面は、画面の状態を基本的に Store に寄せたため、実装の規模が大きくなってしまったことです。 現在、作り直す・リファクタする機会があるとしたら画面・コンポーネントで閉じている状態はそのコンポーネントの状態として実装するかもしれません。 ## Atomic Design を用いたコンポーネント分類 前述したように規模の大きめな SPA だったため、コンポーネント分類のルールとして Atomic Design を適用しました。 Atomic Design は実装レベルで言うと、人によって揺らぎがあるかと思いますが、本プロジェクトでは以下のようにな分け方を適用しました。 - Atom - HTML 要素をラップしたコンポーネント - Molecule - 複数の Atom を組み合わせたコンポーネント - Organism - アプリケーション上の文脈に則ったコンポーネント - MobX の store を購読する - Page - 画面と対応するコンポーネント これもおおよそうまくいき、開発の落ち着いた今では新しい画面が発生してもコンポーネントの流用で実装が済んでしまうことが多いです。 ただし、上流工程からもらったデザインは Atomic Design に則って作られたものではなかったため、振る舞いとしては似ているが見た目が大きく違うために、似たような名前のコンポーネントがいくつかできてしまったという問題がありました。

# どのようなサービスか 企業面接に特化したビデオチャットサービス 特化というところで、応募者や選考ステップの管理などができます。 また、企業の面接官と応募者の、少数対少数のビデオチャットもあれば、説明会として 1:多数の配信機能もあります。 # プロジェクトにおいて行ったこと 主にフロントエンド実装を行い、Go で書かれた BFF サーバーへの実装も行いました。 このプロジェクトの特徴として、コロナ禍において状況に応じたニーズにすばやく応えるために、役割に分かれていくつかのサービスがありました。 - classic: リリース済み版 - lite: 軽量版（説明会機能がある。応募者・選考管理機能がない） - リニューアル: classic のリニューアル版（当時リリースされておらず、リニューアル計画） これらには共通する機能があり、それをいかに少ない工数と高いメンテナンス性で作っていくかがフロントエンドとしての悩みでした。 ## 動作確認機能のパッケージ化 共通する機能の代表として動作確認があります。 選択したカメラ、マイクが動作していることを UI の通じてユーザーに示すことや、OS, ブラウザ、ネットワークの種類からビデオチャットを許可するか判別する機能です。 この機能をどう共通化するかとして、UI までパッケージングしたコンポーネントを作成しました。 これまで社内では全画面に表示される UI までをコンポーネント化したことはありませんでしたが、この決定によって lite, リニューアルの各アプリケーションで非常に簡単に動作確認機能を導入することができ、少ない工数で実現することができました。 ## デザインシステムコンポーネントライブラリの運用 Figma をデザインシステムの基にして、lite, リニューアルなど各アプリケーションから使われるコンポーネントライブラリを作成しました。 コンポーネントライブラリを作成したことで、lite からリニューアルの流用機能が手軽に作られる、デザインシステムを作ったことで UI の独自性を実現できました。 ただし、自分たちのコンポーネントライブラリを作成することはなかなか労力がかかることで、独自性のある UI が必須でなければ、既存のコンポーネントライブラリを使用し、機能など別の点に注力してもよかったかもしれません。 ## リニューアルにあたってビデオチャット機能の設計・実装 フロントエンドをメインに設計・実装を行いました。 classic, lite での知見を活かしながら取り組むことができました。 特に面接官・応募者それぞれのロールに応じて redux の store を作り分けるところや、冗長な props バケツリレーを防ぐための積極的な React Context の使用はうまくいき、現在のビデオチャットツールの構造基盤となっています。