Takeshi Inoue

### プロジェクト概要 このプロジェクトではVue.jsで書かれた画像管理機能をReactにリプレイスした。 歯科治療の過程で撮影する口腔内の写真を管理しやすくするサービスである。 ### 人数 フロントエンドエンジニア3名(自分を含む)、バックエンドエンジニア2名、デザイナー1名、プロダクトオーナー 1名 フロントエンドを担当した。 ### 課題1 -コンポーネント化 【背景】 旧版は短納期の中で急ピッチで作成された経緯があり、１つのファイルに膨大な量のコードが詰め込まれ、見通しが悪いものだった。メンテナンスしやすく書き直すことが求められた。 【取り組み】 Reactの流儀に基づいて、UIをコンポーネントの階層構造に落とし込むことからはじめた。 例えばCardImageとCardActionButtonsからなるCardのコンポーネントを作成し、それをImageListPageの中でmapするといったように、役割の詰め込まれすぎたコードを、単一の責任を持つコンポーネントに切り分けていった。 【結果】 影響範囲が特定しやすく、機能追加・改修の手を入れやすい構成になった。 ### 課題2 -単体テスト 【背景】 既存の仕様を壊さないでリプレイスすることが難しかった。写真を組むレイアウトを変更する機能や、組んだ写真を単一のJPGに変換し出力する機能などロジックが多かった。 【取り組み】 開発された方に旧版の仕様について確認しながら、Jestでその仕様を満たすテストを書いた。そのテストが通るように実装していった。 【結果】 仕様がテストコードとしてまとまり、メンテナブルになった。バグは0というわけではなかったが、致命的ではないもの1つに留めることができ、堅実なアプリケーションがリリースできた。

### プロジェクト概要 このプロジェクトは歯科医院向けに問診票の作成機能を提供し、予約時に患者さんのメールアドレス(またはSMSやネイティブアプリ「私の歯医者さん」)を通じて問診票を送付できるサービスである。 ### 人数 フロントエンドエンジニア2名(自分を含む)、バックエンドエンジニア2名、プロダクトオーナー1名。 フロントエンドを担当した。 ### 使用技術 Amplify, Apollo, GraphQL, graphql-codegen, TypeScript, React, ContextAPI + useReducer, emotion ### 課題1-ドラックアンドドロップ 【背景】 操作性の観点から、問診票の個々の質問項目の順番をドラックアンドドロップで入れ替えらるようにしてほしいという要望が上がっていた。プロジェクトの納期を考えると、ドラックアンドドロップによる入れ替え操作の機能をいちから作る時間はなかった。 【取り組み】 GitHubのスター数、ドキュメントの整備具合、ReactHooksへの対応の有無などの観点から総合的に判断し、ReactDnDというライブラリを用いることでドラックアンドドロップでの入れ替え機能を実装した。さらに、ホバーした時に{cursor: 'grab'}当てるなど、操作性の面でも工夫を凝らした。 【結果】 この問診票はGoogleFormにも近いUIを実現し、医院様からも他社製のものよりも使いやすいという喜びの声をいただいた。 ### 課題2-複雑なデータ構造 【背景】 問診票のデータは、①1つの問診票が複数の質問を配列で持つ、②各質問は回答形式のタイプ(短文、長文、ラジオボタン、チェックボックス)と、選択肢がある場合には選択肢を配列で持つ、③各選択肢は選択肢とともに、フリーフォーム(その他、病名を記入(”ここがフリーフォーム”))をネストしたオブジェクトで持つことができる、という三重にネストした複雑な構造を持っていた。 【取り組みa】 こうした複雑な構造を持つ問診票を作成するため、フォームのstateをContextAPI✖️useReducerというReduxライクな状態管理の仕組みで管理した。さらに、ネストの深いデータをimmutableに変更する際にコードが冗長になるのを避けるために、immerを活用した。 【取り組みb】 データの複雑さによってバグが生じたりコードが難読化するのを避けるため、型安全性について心を配り、型がドキュメントの役割を担うようにした。また、graphql-codegenを用いてAPIからTypeScriptの型を自動生成することでAPI周りの型の記述ミスを防いだ。 【結果】 データ構造は複雑であるものの、データの流れを単方向で動きの把握しやすく、型安全な設計にすることができた。Web問診票ではリリース後も継続的に機能追加の要望が上がったが、この土台があったため改修が容易になった。