t-keshi

### プロジェクト概要 このプロジェクトは歯科医院向けに問診票の作成機能を提供し、予約時に患者さんのメールアドレス(または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問診票ではリリース後も継続的に機能追加の要望が上がったが、この土台があったため改修が容易になった。

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

### プロジェクト概要 このプロジェクトは、歯科医院の経営者がシステム上でスタッフの権限管理をできるようにするプロジェクトである。 ### 人数 フロントエンドエンジニア1名(自分を含む)、バックエンドエンジニア1名、デザイナー1名、スクラムマスター1名、プロダクトオーナー1名。 フロントエンドを担当した。 ### 課題１-デザイン 【背景】 同様のシステムを作っている他社と比較して、ストランザのシステムは機能が多いものの使い勝手が悪いという声もあった。一方、デザインチームは発足したばかりであり、デザインの改善フローは確立されていなかった。 【取り組み】 デザインに統一感をもたせつつ実装のスピードを上げるためmaterial-uiを導入した。さらに、Storybook+chromaticという環境で、継続的にデザインをブラッシュアップしていけるワークフローを構築することを狙った。 【結果】 フロントエンドエンジニアの実装したUIはデザインチームによってレビューされ、アジャイルに改善されるという仕組みづくりをすることができた。新しい仕組みの導入により、例えばバラバラだった色の使い方には、プライマリカラー/セカンダリカラーといった名前が付けられ、色数が絞られ、整備された。待機中のUIは、スピナーからスケルトンに変わり、ストレスの少ない快適なものになった。 ### 課題2 -バグ監視、エラー対応 【背景】 バックエンドではNewRelicを用いながらバグ監視を行なっていたが、フロントエンドではそうした仕組みを導入しておらず、QAが上がってきてから修正する後手の対応となってしまっていた。 【取り組み】 NewRelic, DataDog, Sentryなどのバグ監視・ログ管理のSaaSを調査し、収集できるログ・料金体系・サポートなどの観点から比較・提案した。チームのリーダーとの話し合いの上で、バグ監視システムをDataDogに統一した。さらに、ErrorBoundaryを用いて、エラーが発生したリクエストのパタメーターやスタックトレースなどのエラーの詳細なログをData Dogに送りつつ、真っ白な画面になる代わりにフィードバックを表示する仕組みを実装した。 【結果】 バグが上がってくるよりも先に、エンジニアがそれに気づき対応できる環境を構築することができた。また、フロントエンドにもエラー監視を導入することで、どのようなケースでエラーが発生しがちなのかナレッジを蓄積し、今後の開発に役立てることができるようになった。