こんにちは。メドレーのエンジニアの山田です。現在、医療介護求人サイト「ジョブメドレー」のチームで開発を担当しています。 今回、ジョブメドレーの社内スタッフが利用する社内システムをリニューアルした事例をご紹介します。 リニューアル対象はバックエンド領域も含まれますが、本記事ではフロントエンドの話を中心にご紹介します。 また、弊社デザイナー酒井が以前投稿した デザイナーがデザインツールを使わずに、React を使ってデザインした話 も関連しているので、よろしければあわせてご覧ください。 リニューアルの背景 社内システムでは、求人サイト「ジョブメドレー」を利用する求職者に関する情報や求職者の応募状況を管理しています。 前回のリニューアルから時間が経ち、複雑性が高くなってきました。その複雑性に比例して、新機能の追加や改修するためのコストも高くなっていました。 そこで上記の課題を解決するため、状態管理がしやすく、テストコードも書きやすい、メンテナブルなアーキテクチャにすべくリニューアルを実施することにしました。 検証期間も経て、今回のリニューアルにあわせて新規に作成する API は、GraphQL によって実装することを決めました。 型システムを持つため画面に必要なデータを柔軟に過不足なく取得できる、手動でドキュメントに落とし込まなくてもスキーマが定義されていれば API の仕様を簡単に把握できる、等がメリットとして感じられました。 特に、GraphQL が持つ型システムが、TypeScript、Apollo、GraphQL Code Generator のライブラリを組み合わせることで、API に渡すパラメータや、レスポンスにも型が適用され、GraphQL スキーマの変更にクライアントの実装が比較的容易に追従できることが、大きなポイントでした。 フロントエンドの技術的なリニューアル内容 今回は特に、リニューアルに用いられたフレームワークやライブラリ、Apollo Client を用いた状態管理、テストコード実装における Tips 等をそれぞれ部分的にご紹介します。 採用したフレームワークと主要ライブラリ 採用ライブラリ 説明 Next.js React 用のフレームワーク（ボイラープレート） TypeScript JavaScript のスーパーセットで、静的型付け言語 React UI を構築するためのライブラリ（バージョン 16.8.0 でリリースされた hooks を全面的に使用） Apollo Client GraphQL API のクライアントで、アプリケーション全体の状態管理を実施 GraphQL Code Generator GraphQL スキーマから定義ファイル（型、カスタム hooks 等）を生成 emotion + Styled System CSS in JS として利用 formik + yup フォームのビルダー + バリデーター Jest + React Testing Library テストコード実装用のツール群 ESLint + Prettier ルールに基づいたコードの静的解析 + スタイリング TypeScript 今回のリニューアルで求められたことの一つとして、さらなる改善・新規機能追加などをしていく上で、ソフトウェア品質を担保するための、アプリケーションの堅牢さがありました。 そこで、フロントエンド側の開発言語としては、プログラムコード内で宣言された型によって、エラーを未然に防ぎつつ、VSCode をはじめとするエディタのコード補完の恩恵を受けられるメリット等を考慮して TypeScript の採用を決めました。また、他のプロジェクトでも既に TypeScript は部分的に利用し始めていた事情もあり、逆に TypeScript を採用しない、という選択肢はあまり考えられませんでした。 React UI を構築するためのライブラリ/フレームワークは React を採用しました。こちらも、弊社では別プロジェクトで React を既に利用し始めていたこともあり、学習コストの観点から、新たに他のフレームワークを選択するメリットはほぼ無かったためです。しかし、その事を差し引いたとしても TypeScript と GraphQL との相性の良さで、React が優勢でした。 特に、React の場合は、GraphQL スキーマをベースに、GraphQL Code Generator によって型定義ファイルだけではなく、GraphQL API とのやり取りに使えるカスタム hooks も生成して利用できるという点が、大きな利点として考えられました。 Next.js フロントエンド開発環境を素早く構築するため、ボイラープレートとして Next.js を採用しました。 Next.js の具体的な採用ポイントとしては、主に次の３点です。 webpack における、バンドルやコンパイル、ホットリロード等の設定に時間を費やすことなく、ビジネスロジックの実装に集中できる 必要があれば、next.config.js で設定を拡張できる CRA（Create React App）とは異なり、拡張性に優れている pages 配下に置く React Component のディレクトリ構成が、自動的にルーティングとして定義される ルーティングに関する設計作業が不要になる 自動コード分割等によるパフォーマンス最適化をよしなに行ってくれる React Component の分類 component は大きく２つに分類し、 src/components/app/ と src/components/ui/ それぞれのディレクトリに component を置いています。分類は以下の基準で行ないました。 app : 本アプリケーション固有で使用される想定のもので、再利用性が低く、具体的な component ui : 本アプリケーション外でも使用可能な、再利用性が高く、抽象的な component 社内向けシステムではあるものの、Material-UI や Ant Design 等をはじめとする、外部の UI ライブラリは使用せず、カスタマイズがしやすいように、全て自前で作成しました。 app 配下と ui 配下、どちらの component も基本的には コロケーション の考え方でファイルを構成しています。 一般的には、よく一緒に変更するファイルを近くに置いておくのは良いアイディアです。 この原則は、「コロケーション」と呼ばれます。 この考え方でファイルを構成することで、関連するファイルがまとまっていて、作業がしやすくなります。 src/ components/ app/ partials/ ${ component 名} / apollo.cache.ts apollo.query.graphql index.tsx index.test.tsx ... screens/ ${ component 名} / apollo.cache.ts apollo.query.graphql index.tsx index.test.tsx ${子 component 名} / apollo.cache.ts apollo.query.graphql index.tsx index.test.tsx validation.ts src/components/app ディレクトリ配下でさらに、 partials と screens のディレクトリで component を分けています。 screens には、Next.js で route として扱われる src/pages 配下の component から import される component が配置されています。 画面のバリエーションが増える度に、この screens にファイルが追加されていきます。 partials には、app 配下で複数の component から利用される component（画面をまたいで共有されるもの等）を配置しています。 screens と partials それぞれ直下の component で、必要であれば適宜、component を分割して子 component を持つ構成にしています。 apollo.cache.ts と apollo.query.graphql については後述の状態管理の話でご紹介します。 状態管理 アプリケーションの状態管理については、グローバルにアクセスできる状態の管理には Apollo Client の InMemoryCache による cache 機構で行い、特定の component 内に閉じている局所的な状態の管理には useState 等の React Hooks を使って行っています。 状態管理の必要性が生じた際、アプリケーションの複雑性を上げないように、なるべく useState 等の hooks を用いた local state だけで済ませられないかどうかを検討します。 例えば、クリックするとドロップダウンリストが表示されるセレクトボックスの component で、ドロップダウンリストの表示状態をその component 内だけで扱いたいのであれば useState を用いた local state で十分であると考えられます。 親子関係ではない component 同士でのやりとりが必要になった時や、サーバのデータと関連する場合等で、ローカルのデータを一元管理しておいた方が良さそうなケースでは、Apollo Client の cache を利用します。 Apollo Client Apollo に関連するファイルの構成については以下の通りです。 src/ apollo/ cache.ts client.ts types.ts withApollo.ts cache.ts : Apollo における local state の initialState と resolver を全画面分このファイルでまとめて、最終的に Next.js の src/pages/_app.tsx に渡るようにする component 固有の local state に関する initialState および state の updater となる resolver は component 毎の apollo.cache.ts にて、別途定義 client.ts : Apollo Client のインスタンスを生成するファイル types.ts : Apollo 関連の型定義ファイル withApollo.ts : Apllo Client の <ApolloProvider /> でラップして返す Higher-Order Compoents(HOC) 実装については割愛しますが、client.ts と withApollo.ts に関しては、Next.js の example（ with-apollo ）等を参考にしました。 画面固有の Apollo の状態管理に関わるファイルは src/components/**/${component 名}/ 配下に置いています。 こちらもコロケーションの考え方で、component に関わる状態管理は該当の component と同じ場所に置くことを意識しています。 src/ components/ app/ ${ component 名} / apollo.cache.ts apollo.query.graphql apollo.schema.graphql apollo.cache.ts : component 固有の Apollo における local state の initialState および resolver を定義するファイル apollo.query.graphql : クエリを定義するファイル apollo.schema.graphql : local state の GraphQL スキーマを定義ファイル ファイルの命名について、 ディレクトリ階層をできるだけ深くしたくない ので、 apollo 等によるディレクトリは設けていませんが、Apollo 関連のファイル群として認識できるよう、ファイル名に apollo. のプレフィックスをつけて命名しています。 Query と Mutation の実行について GraphQL Code Generator のプラグイン TypeScript React Apollo をインストールして、hooks を生成する設定にした上で、component 毎にそれぞれ GraphQL のスキーマとクエリが記述された .graphql ファイルをもとに、GraphQL Code Generator が生成するカスタム hooks を利用します。 こちらのカスタム hooks を React Component で利用することで、Apollo Client 経由で GraphQL API とローカルの Apollo cache に接続して、データのやり取りを行うことができます。 Query Query の hooks は２種類あり、実行するタイミングによっていずれか適切な方を選んで実行しています。 API 実行タイミング useQuery Component が render されたらクエリ実行 useLazyQuery 任意のイベントをトリガーにしてクエリ実行 use***Query 通常であれば useQuery でクエリの結果を render しますが、GraphQL Code Generator を利用する場合は、それぞれのクエリをラップしたカスタム hooks が生成されるので、 useQuery , useLazyQuery をそのまま使うことはありません。 query AllPosts { allPosts { id title rating } } ↑ のようなクエリを用意すると src/__generated__/graphql.tsx に対して、次のようなカスタム hooks が型と一緒に生成される設定にしています。 // Apollo Client: 2.6.9、GraphQL Code Generator: 1.15.0 の場合の例 export function useAllPostsQuery ( baseOptions ?: ApolloReactHooks . QueryHookOptions & lt ; AllPostsQuery , AllPostsQueryVariables >) { return ApolloReactHooks . useQuery & lt ; AllPostsQuery , AllPostsQueryVariables >( AllPostsDocument , baseOptions ); } export function useAllPostsLazyQuery ( baseOptions ?: ApolloReactHooks . LazyQueryHookOptions & lt ; AllPostsQuery , AllPostsQueryVariables >) { return ApolloReactHooks . useLazyQuery & lt ; AllPostsQuery , AllPostsQueryVariables >( AllPostsDocument , baseOptions ); } React Component では生成されたカスタム hooks を次のように呼び出してサーバーから返ってくる結果を受け取って、データ出力、ローディング状態のチェック、エラーハンドリング等を行います。 const { data , loading , error } = useAllPostsQuery (); Mutation データの書き込みは useMutation で行います。 Query 同様、 GraphQL Code Generator によって生成されたカスタム hooks use***Mutation を使っています。 cache の更新 Mutation が複数エンティティの更新、エンティティの新規作成または削除の場合、Apollo Client の cache は自動更新されず、Mutation の結果が自動的に render されません。 このような場合でも、 useMutation の update option を使えば、 cache オブジェクトを引数に取れる関数を設定できるので、この関数内で直接 cache を更新できます。 また、 update の代わりに refetchQueries の option を使って、任意の Query を実行して、シンプルに cache を更新することもできます。 但し、この方法だと Network 通信によるオーバーヘッドが発生します。 このオーバーヘッドを犠牲にしてでも、サーバーからデータ取得したい Query があるような場合には、この refetchQueries が有効です。 local state の管理 ここからは特定の component の状態管理を local state を使ってどのように管理しているかを、ご説明していきます。 @client を使った Query Next.js のプロジェクトで、local state の管理を Apollo Client で行う場合の例としては、次の通りです。 スキーマ： # src / components / app / Home / apollo . schema . graphql type Home { currentPostId: Int! } extend type Query { home: Home } クエリ： # src / components / app / Home / apollo . query . graphql query HomeCurrentPostId { home @ client { currentPostId } } キャッシュの初期値： // src/components/app/Home/apollo.cache.ts export const cache = { __typename: 'Home' , currentPostId: 0 , ..., }; // src/apollo/cache.ts const caches = { ..., home: home . cache , }; export { ..., caches , }; // src/pages/_app.tsx export const cache = new InMemoryCache (); ... const client = new ApolloClient ({ link , cache: cache . restore ( initialState || {}), resolvers , connectToDevTools: true , }); cache . writeData ({ data: caches }); GraphQL クエリとスキーマが定義されていれば GraphQL Code Generator が use***Query のコードを生成する設定にしています。 ローカルデータの場合、クエリで @client ディレクティブをつけてローカルデータであることを明示します。 @client を使った Mutation local state の更新を GraphQL の Mutation として行う場合の例としては、次の通りです。 スキーマ： # src / components / app / Home / apollo . schema . graphql type UpdateCurrentPostId { currentPostId: Int! } extend type Mutation { updateCurrentPostId(id: Int!): UpdateCurrentPostId } クエリ： # src / components / app / Home / apollo . query . graphql mutation UpdateCurrentPostId ( $id : Int !) { updateCurrentPostId ( id : $id ) @ client { currentPostId @ client } } resolver： // src/components/app/Home/apollo.cache.ts const updateCurrentPostId : MutationResolvers [ "updateCurrentPostId" ] = ( _ , args , { cache } ) => { cache . writeData ({ data: { home: { __typename: "Home" , currentPostId: args . id , }, }, }); return null ; }; export const Mutation = { updateCurrentPostId , }; Query 同様に @client ディレクティブをつけてローカルデータであることを明示します。 実際の Mutation の処理自体は resolver の中に cache.writeData() を使って記述します。 Mutation の命名は、 動詞+名詞の形式で可能な限り意味のある具体的な名前をつける ことを意識しています。 Apollo を使った開発を便利にしてくれるツール Apollo Client を使って開発する際は、ローカルの Apollo cache の状態や、クエリを試しに実行するためのツールとして、Google Chrome の拡張機能 Apollo Client Developer Tools が非常に便利です。 こちらの拡張機能を Chrome にインストールすると、Apollo Client を使って GraphQL API にアクセスするサイトに遷移した状態で Chrome Dev Tools を開くと Apollo のタブが表示されます。そこでクエリの実行や、API 仕様の確認、ローカルの Apollo cache の確認等を行うことができます。 GraphQL 関連のテストコードについて Apollo Client を使った React Component の開発で、Query および Mutation 実行のテストを実施するには、テストフレームワークの Jest、react-testing-library とあわせて、Apollo 公式でも紹介されている MockedProvider を用いる方法が一般的かと思います。 クエリとクエリに対するレスポンスを組み合わせたモックデータを用意しておき、ApolloProvider の代わりに MockedProvider でテスト対象の component をラップすることで、API サーバーや Network 環境に依存せず、モックで指定したクエリがリクエストされると、モックでそれに対応するように用意したレスポンスデータが確実に取得できる仕組みを作れます。 その仕組みと react-testing-library を使って、component で render される UI 上の操作をトリガーにして実行される、クエリのテストを行うことができます。 Query だけではなく Mutation もモックすることができて、便利なツールではありますが、テストケース毎にモックデータは手動で作成しなければならない点が、なかなか骨が折れる作業です。 実際にアプリケーションを動かして、テスト対象の component を render し、Query に渡される variables やレスポンスの値を Console に出力し、ブラウザの Dev Tools 上で一個一個オブジェクトをコピーして、エディタに貼り付けしたりする作業が発生します。 AutoMockedProvider の作成 そこで、わざわざテスト作成やスキーマ変更の度に、手動でモックデータを用意しなくても、GraphQL スキーマで定義されている型を見て、自動でクエリに対するレスポンスをモックしてくれる AutoMockedProvider を、 こちらの記事 を参考にして作成しました。 MockedProvider の代わりに、AutoMockedProvider を用いてテスト対象の Component をラップすることで、MockedProvider を使ってテストしていた内容と同じテストが実施できます。 MockedProvider を使って毎回モックデータを用意し、テストを実施することに疲れている方は是非、お試しください。 （紹介先の記事では、 graphql-tools の makeExecutableSchema() に渡す schemaSDL が json ファイルで定義されていますが、 graphql-tag のライブラリを併用すれば、graphql ファイルでも同様に schemaSDL として適用することも可能です） リニューアルを振り返って 今回のリニューアルでは、GraphQL、TypeScript、React をセットで採用したことにより、フロント側では GraphQL Code Generator を使って、あらかじめ用意しておいた GraphQL スキーマから、TypeScript の型だけではなく、React の Hooks 関数まで生成して利用できたことが、開発効率の向上に非常に影響を与えたと思います。 GraphQL API のクライアントで、アプリケーション全体の状態管理を行う Apollo Client の cache 機構の使い方等を体得するまでに、学習コストは決してゼロではありませんでしたが、TypeScript と GraphQL の型システムの恩恵をフルに受け、Next.js のレールにのっかり、型安全な開発環境を手に入れることができました。 我々、開発者の体験だけではなく、今後のプロダクト全体への生産性にも良い影響を及ぼしてくれると確信しています。 さいごに メドレーではエンジニア・デザイナーを積極募集しています。 「テクノロジーを活用して医療ヘルスケアの未来をつくる」というミッションに共感し、課題解決を行いたい方は是非、ご応募ください。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。メドレーのエンジニアの山田です。現在、医療介護求人サイト「ジョブメドレー」のチームで開発を担当しています。 今回、ジョブメドレーの社内スタッフが利用する社内システムをリニューアルした事例をご紹介します。 リニューアル対象はバックエンド領域も含まれますが、本記事ではフロントエンドの話を中心にご紹介します。 また、弊社デザイナー酒井が以前投稿した デザイナーがデザインツールを使わずに、React を使ってデザインした話 も関連しているので、よろしければあわせてご覧ください。 リニューアルの背景 社内システムでは、求人サイト「ジョブメドレー」を利用する求職者に関する情報や求職者の応募状況を管理しています。 前回のリニューアルから時間が経ち、複雑性が高くなってきました。その複雑性に比例して、新機能の追加や改修するためのコストも高くなっていました。 そこで上記の課題を解決するため、状態管理がしやすく、テストコードも書きやすい、メンテナブルなアーキテクチャにすべくリニューアルを実施することにしました。 検証期間も経て、今回のリニューアルにあわせて新規に作成する API は、GraphQL によって実装することを決めました。 型システムを持つため画面に必要なデータを柔軟に過不足なく取得できる、手動でドキュメントに落とし込まなくてもスキーマが定義されていれば API の仕様を簡単に把握できる、等がメリットとして感じられました。 特に、GraphQL が持つ型システムが、TypeScript、Apollo、GraphQL Code Generator のライブラリを組み合わせることで、API に渡すパラメータや、レスポンスにも型が適用され、GraphQL スキーマの変更にクライアントの実装が比較的容易に追従できることが、大きなポイントでした。 フロントエンドの技術的なリニューアル内容 今回は特に、リニューアルに用いられたフレームワークやライブラリ、Apollo Client を用いた状態管理、テストコード実装における Tips 等をそれぞれ部分的にご紹介します。 採用したフレームワークと主要ライブラリ 採用ライブラリ 説明 Next.js React 用のフレームワーク（ボイラープレート） TypeScript JavaScript のスーパーセットで、静的型付け言語 React UI を構築するためのライブラリ（バージョン 16.8.0 でリリースされた hooks を全面的に使用） Apollo Client GraphQL API のクライアントで、アプリケーション全体の状態管理を実施 GraphQL Code Generator GraphQL スキーマから定義ファイル（型、カスタム hooks 等）を生成 emotion + Styled System CSS in JS として利用 formik + yup フォームのビルダー + バリデーター Jest + React Testing Library テストコード実装用のツール群 ESLint + Prettier ルールに基づいたコードの静的解析 + スタイリング TypeScript 今回のリニューアルで求められたことの一つとして、さらなる改善・新規機能追加などをしていく上で、ソフトウェア品質を担保するための、アプリケーションの堅牢さがありました。 そこで、フロントエンド側の開発言語としては、プログラムコード内で宣言された型によって、エラーを未然に防ぎつつ、VSCode をはじめとするエディタのコード補完の恩恵を受けられるメリット等を考慮して TypeScript の採用を決めました。また、他のプロジェクトでも既に TypeScript は部分的に利用し始めていた事情もあり、逆に TypeScript を採用しない、という選択肢はあまり考えられませんでした。 React UI を構築するためのライブラリ/フレームワークは React を採用しました。こちらも、弊社では別プロジェクトで React を既に利用し始めていたこともあり、学習コストの観点から、新たに他のフレームワークを選択するメリットはほぼ無かったためです。しかし、その事を差し引いたとしても TypeScript と GraphQL との相性の良さで、React が優勢でした。 特に、React の場合は、GraphQL スキーマをベースに、GraphQL Code Generator によって型定義ファイルだけではなく、GraphQL API とのやり取りに使えるカスタム hooks も生成して利用できるという点が、大きな利点として考えられました。 Next.js フロントエンド開発環境を素早く構築するため、ボイラープレートとして Next.js を採用しました。 Next.js の具体的な採用ポイントとしては、主に次の３点です。 webpack における、バンドルやコンパイル、ホットリロード等の設定に時間を費やすことなく、ビジネスロジックの実装に集中できる 必要があれば、next.config.js で設定を拡張できる CRA（Create React App）とは異なり、拡張性に優れている pages 配下に置く React Component のディレクトリ構成が、自動的にルーティングとして定義される ルーティングに関する設計作業が不要になる 自動コード分割等によるパフォーマンス最適化をよしなに行ってくれる React Component の分類 component は大きく２つに分類し、 src/components/app/ と src/components/ui/ それぞれのディレクトリに component を置いています。分類は以下の基準で行ないました。 app : 本アプリケーション固有で使用される想定のもので、再利用性が低く、具体的な component ui : 本アプリケーション外でも使用可能な、再利用性が高く、抽象的な component 社内向けシステムではあるものの、Material-UI や Ant Design 等をはじめとする、外部の UI ライブラリは使用せず、カスタマイズがしやすいように、全て自前で作成しました。 app 配下と ui 配下、どちらの component も基本的には コロケーション の考え方でファイルを構成しています。 一般的には、よく一緒に変更するファイルを近くに置いておくのは良いアイディアです。 この原則は、「コロケーション」と呼ばれます。 この考え方でファイルを構成することで、関連するファイルがまとまっていて、作業がしやすくなります。 src/ components/ app/ partials/ ${ component 名} / apollo.cache.ts apollo.query.graphql index.tsx index.test.tsx ... screens/ ${ component 名} / apollo.cache.ts apollo.query.graphql index.tsx index.test.tsx ${子 component 名} / apollo.cache.ts apollo.query.graphql index.tsx index.test.tsx validation.ts src/components/app ディレクトリ配下でさらに、 partials と screens のディレクトリで component を分けています。 screens には、Next.js で route として扱われる src/pages 配下の component から import される component が配置されています。 画面のバリエーションが増える度に、この screens にファイルが追加されていきます。 partials には、app 配下で複数の component から利用される component（画面をまたいで共有されるもの等）を配置しています。 screens と partials それぞれ直下の component で、必要であれば適宜、component を分割して子 component を持つ構成にしています。 apollo.cache.ts と apollo.query.graphql については後述の状態管理の話でご紹介します。 状態管理 アプリケーションの状態管理については、グローバルにアクセスできる状態の管理には Apollo Client の InMemoryCache による cache 機構で行い、特定の component 内に閉じている局所的な状態の管理には useState 等の React Hooks を使って行っています。 状態管理の必要性が生じた際、アプリケーションの複雑性を上げないように、なるべく useState 等の hooks を用いた local state だけで済ませられないかどうかを検討します。 例えば、クリックするとドロップダウンリストが表示されるセレクトボックスの component で、ドロップダウンリストの表示状態をその component 内だけで扱いたいのであれば useState を用いた local state で十分であると考えられます。 親子関係ではない component 同士でのやりとりが必要になった時や、サーバのデータと関連する場合等で、ローカルのデータを一元管理しておいた方が良さそうなケースでは、Apollo Client の cache を利用します。 Apollo Client Apollo に関連するファイルの構成については以下の通りです。 src/ apollo/ cache.ts client.ts types.ts withApollo.ts cache.ts : Apollo における local state の initialState と resolver を全画面分このファイルでまとめて、最終的に Next.js の src/pages/_app.tsx に渡るようにする component 固有の local state に関する initialState および state の updater となる resolver は component 毎の apollo.cache.ts にて、別途定義 client.ts : Apollo Client のインスタンスを生成するファイル types.ts : Apollo 関連の型定義ファイル withApollo.ts : Apllo Client の <ApolloProvider /> でラップして返す Higher-Order Compoents(HOC) 実装については割愛しますが、client.ts と withApollo.ts に関しては、Next.js の example（ with-apollo ）等を参考にしました。 画面固有の Apollo の状態管理に関わるファイルは src/components/**/${component 名}/ 配下に置いています。 こちらもコロケーションの考え方で、component に関わる状態管理は該当の component と同じ場所に置くことを意識しています。 src/ components/ app/ ${ component 名} / apollo.cache.ts apollo.query.graphql apollo.schema.graphql apollo.cache.ts : component 固有の Apollo における local state の initialState および resolver を定義するファイル apollo.query.graphql : クエリを定義するファイル apollo.schema.graphql : local state の GraphQL スキーマを定義ファイル ファイルの命名について、 ディレクトリ階層をできるだけ深くしたくない ので、 apollo 等によるディレクトリは設けていませんが、Apollo 関連のファイル群として認識できるよう、ファイル名に apollo. のプレフィックスをつけて命名しています。 Query と Mutation の実行について GraphQL Code Generator のプラグイン TypeScript React Apollo をインストールして、hooks を生成する設定にした上で、component 毎にそれぞれ GraphQL のスキーマとクエリが記述された .graphql ファイルをもとに、GraphQL Code Generator が生成するカスタム hooks を利用します。 こちらのカスタム hooks を React Component で利用することで、Apollo Client 経由で GraphQL API とローカルの Apollo cache に接続して、データのやり取りを行うことができます。 Query Query の hooks は２種類あり、実行するタイミングによっていずれか適切な方を選んで実行しています。 API 実行タイミング useQuery Component が render されたらクエリ実行 useLazyQuery 任意のイベントをトリガーにしてクエリ実行 use***Query 通常であれば useQuery でクエリの結果を render しますが、GraphQL Code Generator を利用する場合は、それぞれのクエリをラップしたカスタム hooks が生成されるので、 useQuery , useLazyQuery をそのまま使うことはありません。 query AllPosts { allPosts { id title rating } } ↑ のようなクエリを用意すると src/__generated__/graphql.tsx に対して、次のようなカスタム hooks が型と一緒に生成される設定にしています。 // Apollo Client: 2.6.9、GraphQL Code Generator: 1.15.0 の場合の例 export function useAllPostsQuery ( baseOptions ?: ApolloReactHooks . QueryHookOptions & lt ; AllPostsQuery , AllPostsQueryVariables >) { return ApolloReactHooks . useQuery & lt ; AllPostsQuery , AllPostsQueryVariables >( AllPostsDocument , baseOptions ); } export function useAllPostsLazyQuery ( baseOptions ?: ApolloReactHooks . LazyQueryHookOptions & lt ; AllPostsQuery , AllPostsQueryVariables >) { return ApolloReactHooks . useLazyQuery & lt ; AllPostsQuery , AllPostsQueryVariables >( AllPostsDocument , baseOptions ); } React Component では生成されたカスタム hooks を次のように呼び出してサーバーから返ってくる結果を受け取って、データ出力、ローディング状態のチェック、エラーハンドリング等を行います。 const { data , loading , error } = useAllPostsQuery (); Mutation データの書き込みは useMutation で行います。 Query 同様、 GraphQL Code Generator によって生成されたカスタム hooks use***Mutation を使っています。 cache の更新 Mutation が複数エンティティの更新、エンティティの新規作成または削除の場合、Apollo Client の cache は自動更新されず、Mutation の結果が自動的に render されません。 このような場合でも、 useMutation の update option を使えば、 cache オブジェクトを引数に取れる関数を設定できるので、この関数内で直接 cache を更新できます。 また、 update の代わりに refetchQueries の option を使って、任意の Query を実行して、シンプルに cache を更新することもできます。 但し、この方法だと Network 通信によるオーバーヘッドが発生します。 このオーバーヘッドを犠牲にしてでも、サーバーからデータ取得したい Query があるような場合には、この refetchQueries が有効です。 local state の管理 ここからは特定の component の状態管理を local state を使ってどのように管理しているかを、ご説明していきます。 @client を使った Query Next.js のプロジェクトで、local state の管理を Apollo Client で行う場合の例としては、次の通りです。 スキーマ： # src / components / app / Home / apollo . schema . graphql type Home { currentPostId: Int! } extend type Query { home: Home } クエリ： # src / components / app / Home / apollo . query . graphql query HomeCurrentPostId { home @ client { currentPostId } } キャッシュの初期値： // src/components/app/Home/apollo.cache.ts export const cache = { __typename: 'Home' , currentPostId: 0 , ..., }; // src/apollo/cache.ts const caches = { ..., home: home . cache , }; export { ..., caches , }; // src/pages/_app.tsx export const cache = new InMemoryCache (); ... const client = new ApolloClient ({ link , cache: cache . restore ( initialState || {}), resolvers , connectToDevTools: true , }); cache . writeData ({ data: caches }); GraphQL クエリとスキーマが定義されていれば GraphQL Code Generator が use***Query のコードを生成する設定にしています。 ローカルデータの場合、クエリで @client ディレクティブをつけてローカルデータであることを明示します。 @client を使った Mutation local state の更新を GraphQL の Mutation として行う場合の例としては、次の通りです。 スキーマ： # src / components / app / Home / apollo . schema . graphql type UpdateCurrentPostId { currentPostId: Int! } extend type Mutation { updateCurrentPostId(id: Int!): UpdateCurrentPostId } クエリ： # src / components / app / Home / apollo . query . graphql mutation UpdateCurrentPostId ( $id : Int !) { updateCurrentPostId ( id : $id ) @ client { currentPostId @ client } } resolver： // src/components/app/Home/apollo.cache.ts const updateCurrentPostId : MutationResolvers [ "updateCurrentPostId" ] = ( _ , args , { cache } ) => { cache . writeData ({ data: { home: { __typename: "Home" , currentPostId: args . id , }, }, }); return null ; }; export const Mutation = { updateCurrentPostId , }; Query 同様に @client ディレクティブをつけてローカルデータであることを明示します。 実際の Mutation の処理自体は resolver の中に cache.writeData() を使って記述します。 Mutation の命名は、 動詞+名詞の形式で可能な限り意味のある具体的な名前をつける ことを意識しています。 Apollo を使った開発を便利にしてくれるツール Apollo Client を使って開発する際は、ローカルの Apollo cache の状態や、クエリを試しに実行するためのツールとして、Google Chrome の拡張機能 Apollo Client Developer Tools が非常に便利です。 こちらの拡張機能を Chrome にインストールすると、Apollo Client を使って GraphQL API にアクセスするサイトに遷移した状態で Chrome Dev Tools を開くと Apollo のタブが表示されます。そこでクエリの実行や、API 仕様の確認、ローカルの Apollo cache の確認等を行うことができます。 GraphQL 関連のテストコードについて Apollo Client を使った React Component の開発で、Query および Mutation 実行のテストを実施するには、テストフレームワークの Jest、react-testing-library とあわせて、Apollo 公式でも紹介されている MockedProvider を用いる方法が一般的かと思います。 クエリとクエリに対するレスポンスを組み合わせたモックデータを用意しておき、ApolloProvider の代わりに MockedProvider でテスト対象の component をラップすることで、API サーバーや Network 環境に依存せず、モックで指定したクエリがリクエストされると、モックでそれに対応するように用意したレスポンスデータが確実に取得できる仕組みを作れます。 その仕組みと react-testing-library を使って、component で render される UI 上の操作をトリガーにして実行される、クエリのテストを行うことができます。 Query だけではなく Mutation もモックすることができて、便利なツールではありますが、テストケース毎にモックデータは手動で作成しなければならない点が、なかなか骨が折れる作業です。 実際にアプリケーションを動かして、テスト対象の component を render し、Query に渡される variables やレスポンスの値を Console に出力し、ブラウザの Dev Tools 上で一個一個オブジェクトをコピーして、エディタに貼り付けしたりする作業が発生します。 AutoMockedProvider の作成 そこで、わざわざテスト作成やスキーマ変更の度に、手動でモックデータを用意しなくても、GraphQL スキーマで定義されている型を見て、自動でクエリに対するレスポンスをモックしてくれる AutoMockedProvider を、 こちらの記事 を参考にして作成しました。 MockedProvider の代わりに、AutoMockedProvider を用いてテスト対象の Component をラップすることで、MockedProvider を使ってテストしていた内容と同じテストが実施できます。 MockedProvider を使って毎回モックデータを用意し、テストを実施することに疲れている方は是非、お試しください。 （紹介先の記事では、 graphql-tools の makeExecutableSchema() に渡す schemaSDL が json ファイルで定義されていますが、 graphql-tag のライブラリを併用すれば、graphql ファイルでも同様に schemaSDL として適用することも可能です） リニューアルを振り返って 今回のリニューアルでは、GraphQL、TypeScript、React をセットで採用したことにより、フロント側では GraphQL Code Generator を使って、あらかじめ用意しておいた GraphQL スキーマから、TypeScript の型だけではなく、React の Hooks 関数まで生成して利用できたことが、開発効率の向上に非常に影響を与えたと思います。 GraphQL API のクライアントで、アプリケーション全体の状態管理を行う Apollo Client の cache 機構の使い方等を体得するまでに、学習コストは決してゼロではありませんでしたが、TypeScript と GraphQL の型システムの恩恵をフルに受け、Next.js のレールにのっかり、型安全な開発環境を手に入れることができました。 我々、開発者の体験だけではなく、今後のプロダクト全体への生産性にも良い影響を及ぼしてくれると確信しています。 さいごに メドレーではエンジニア・デザイナーを積極募集しています。 「テクノロジーを活用して医療ヘルスケアの未来をつくる」というミッションに共感し、課題解決を行いたい方は是非、ご応募ください。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。メドレーのエンジニアの山田です。現在、医療介護求人サイト「ジョブメドレー」のチームで開発を担当しています。 今回、ジョブメドレーの社内スタッフが利用する社内システムをリニューアルした事例をご紹介します。 リニューアル対象はバックエンド領域も含まれますが、本記事ではフロントエンドの話を中心にご紹介します。 また、弊社デザイナー酒井が以前投稿した デザイナーがデザインツールを使わずに、React を使ってデザインした話 も関連しているので、よろしければあわせてご覧ください。 リニューアルの背景 社内システムでは、求人サイト「ジョブメドレー」を利用する求職者に関する情報や求職者の応募状況を管理しています。 前回のリニューアルから時間が経ち、複雑性が高くなってきました。その複雑性に比例して、新機能の追加や改修するためのコストも高くなっていました。 そこで上記の課題を解決するため、状態管理がしやすく、テストコードも書きやすい、メンテナブルなアーキテクチャにすべくリニューアルを実施することにしました。 検証期間も経て、今回のリニューアルにあわせて新規に作成する API は、GraphQL によって実装することを決めました。 型システムを持つため画面に必要なデータを柔軟に過不足なく取得できる、手動でドキュメントに落とし込まなくてもスキーマが定義されていれば API の仕様を簡単に把握できる、等がメリットとして感じられました。 特に、GraphQL が持つ型システムが、TypeScript、Apollo、GraphQL Code Generator のライブラリを組み合わせることで、API に渡すパラメータや、レスポンスにも型が適用され、GraphQL スキーマの変更にクライアントの実装が比較的容易に追従できることが、大きなポイントでした。 フロントエンドの技術的なリニューアル内容 今回は特に、リニューアルに用いられたフレームワークやライブラリ、Apollo Client を用いた状態管理、テストコード実装における Tips 等をそれぞれ部分的にご紹介します。 採用したフレームワークと主要ライブラリ 採用ライブラリ 説明 Next.js React 用のフレームワーク（ボイラープレート） TypeScript JavaScript のスーパーセットで、静的型付け言語 React UI を構築するためのライブラリ（バージョン 16.8.0 でリリースされた hooks を全面的に使用） Apollo Client GraphQL API のクライアントで、アプリケーション全体の状態管理を実施 GraphQL Code Generator GraphQL スキーマから定義ファイル（型、カスタム hooks 等）を生成 emotion + Styled System CSS in JS として利用 formik + yup フォームのビルダー + バリデーター Jest + React Testing Library テストコード実装用のツール群 ESLint + Prettier ルールに基づいたコードの静的解析 + スタイリング TypeScript 今回のリニューアルで求められたことの一つとして、さらなる改善・新規機能追加などをしていく上で、ソフトウェア品質を担保するための、アプリケーションの堅牢さがありました。 そこで、フロントエンド側の開発言語としては、プログラムコード内で宣言された型によって、エラーを未然に防ぎつつ、VSCode をはじめとするエディタのコード補完の恩恵を受けられるメリット等を考慮して TypeScript の採用を決めました。また、他のプロジェクトでも既に TypeScript は部分的に利用し始めていた事情もあり、逆に TypeScript を採用しない、という選択肢はあまり考えられませんでした。 React UI を構築するためのライブラリ/フレームワークは React を採用しました。こちらも、弊社では別プロジェクトで React を既に利用し始めていたこともあり、学習コストの観点から、新たに他のフレームワークを選択するメリットはほぼ無かったためです。しかし、その事を差し引いたとしても TypeScript と GraphQL との相性の良さで、React が優勢でした。 特に、React の場合は、GraphQL スキーマをベースに、GraphQL Code Generator によって型定義ファイルだけではなく、GraphQL API とのやり取りに使えるカスタム hooks も生成して利用できるという点が、大きな利点として考えられました。 Next.js フロントエンド開発環境を素早く構築するため、ボイラープレートとして Next.js を採用しました。 Next.js の具体的な採用ポイントとしては、主に次の３点です。 webpack における、バンドルやコンパイル、ホットリロード等の設定に時間を費やすことなく、ビジネスロジックの実装に集中できる 必要があれば、next.config.js で設定を拡張できる CRA（Create React App）とは異なり、拡張性に優れている pages 配下に置く React Component のディレクトリ構成が、自動的にルーティングとして定義される ルーティングに関する設計作業が不要になる 自動コード分割等によるパフォーマンス最適化をよしなに行ってくれる React Component の分類 component は大きく２つに分類し、 src/components/app/ と src/components/ui/ それぞれのディレクトリに component を置いています。分類は以下の基準で行ないました。 app : 本アプリケーション固有で使用される想定のもので、再利用性が低く、具体的な component ui : 本アプリケーション外でも使用可能な、再利用性が高く、抽象的な component 社内向けシステムではあるものの、Material-UI や Ant Design 等をはじめとする、外部の UI ライブラリは使用せず、カスタマイズがしやすいように、全て自前で作成しました。 app 配下と ui 配下、どちらの component も基本的には コロケーション の考え方でファイルを構成しています。 一般的には、よく一緒に変更するファイルを近くに置いておくのは良いアイディアです。 この原則は、「コロケーション」と呼ばれます。 この考え方でファイルを構成することで、関連するファイルがまとまっていて、作業がしやすくなります。 src/ components/ app/ partials/ ${ component 名} / apollo.cache.ts apollo.query.graphql index.tsx index.test.tsx ... screens/ ${ component 名} / apollo.cache.ts apollo.query.graphql index.tsx index.test.tsx ${子 component 名} / apollo.cache.ts apollo.query.graphql index.tsx index.test.tsx validation.ts src/components/app ディレクトリ配下でさらに、 partials と screens のディレクトリで component を分けています。 screens には、Next.js で route として扱われる src/pages 配下の component から import される component が配置されています。 画面のバリエーションが増える度に、この screens にファイルが追加されていきます。 partials には、app 配下で複数の component から利用される component（画面をまたいで共有されるもの等）を配置しています。 screens と partials それぞれ直下の component で、必要であれば適宜、component を分割して子 component を持つ構成にしています。 apollo.cache.ts と apollo.query.graphql については後述の状態管理の話でご紹介します。 状態管理 アプリケーションの状態管理については、グローバルにアクセスできる状態の管理には Apollo Client の InMemoryCache による cache 機構で行い、特定の component 内に閉じている局所的な状態の管理には useState 等の React Hooks を使って行っています。 状態管理の必要性が生じた際、アプリケーションの複雑性を上げないように、なるべく useState 等の hooks を用いた local state だけで済ませられないかどうかを検討します。 例えば、クリックするとドロップダウンリストが表示されるセレクトボックスの component で、ドロップダウンリストの表示状態をその component 内だけで扱いたいのであれば useState を用いた local state で十分であると考えられます。 親子関係ではない component 同士でのやりとりが必要になった時や、サーバのデータと関連する場合等で、ローカルのデータを一元管理しておいた方が良さそうなケースでは、Apollo Client の cache を利用します。 Apollo Client Apollo に関連するファイルの構成については以下の通りです。 src/ apollo/ cache.ts client.ts types.ts withApollo.ts cache.ts : Apollo における local state の initialState と resolver を全画面分このファイルでまとめて、最終的に Next.js の src/pages/_app.tsx に渡るようにする component 固有の local state に関する initialState および state の updater となる resolver は component 毎の apollo.cache.ts にて、別途定義 client.ts : Apollo Client のインスタンスを生成するファイル types.ts : Apollo 関連の型定義ファイル withApollo.ts : Apllo Client の <ApolloProvider /> でラップして返す Higher-Order Compoents(HOC) 実装については割愛しますが、client.ts と withApollo.ts に関しては、Next.js の example（ with-apollo ）等を参考にしました。 画面固有の Apollo の状態管理に関わるファイルは src/components/**/${component 名}/ 配下に置いています。 こちらもコロケーションの考え方で、component に関わる状態管理は該当の component と同じ場所に置くことを意識しています。 src/ components/ app/ ${ component 名} / apollo.cache.ts apollo.query.graphql apollo.schema.graphql apollo.cache.ts : component 固有の Apollo における local state の initialState および resolver を定義するファイル apollo.query.graphql : クエリを定義するファイル apollo.schema.graphql : local state の GraphQL スキーマを定義ファイル ファイルの命名について、 ディレクトリ階層をできるだけ深くしたくない ので、 apollo 等によるディレクトリは設けていませんが、Apollo 関連のファイル群として認識できるよう、ファイル名に apollo. のプレフィックスをつけて命名しています。 Query と Mutation の実行について GraphQL Code Generator のプラグイン TypeScript React Apollo をインストールして、hooks を生成する設定にした上で、component 毎にそれぞれ GraphQL のスキーマとクエリが記述された .graphql ファイルをもとに、GraphQL Code Generator が生成するカスタム hooks を利用します。 こちらのカスタム hooks を React Component で利用することで、Apollo Client 経由で GraphQL API とローカルの Apollo cache に接続して、データのやり取りを行うことができます。 Query Query の hooks は２種類あり、実行するタイミングによっていずれか適切な方を選んで実行しています。 API 実行タイミング useQuery Component が render されたらクエリ実行 useLazyQuery 任意のイベントをトリガーにしてクエリ実行 use***Query 通常であれば useQuery でクエリの結果を render しますが、GraphQL Code Generator を利用する場合は、それぞれのクエリをラップしたカスタム hooks が生成されるので、 useQuery , useLazyQuery をそのまま使うことはありません。 query AllPosts { allPosts { id title rating } } ↑ のようなクエリを用意すると src/__generated__/graphql.tsx に対して、次のようなカスタム hooks が型と一緒に生成される設定にしています。 // Apollo Client: 2.6.9、GraphQL Code Generator: 1.15.0 の場合の例 export function useAllPostsQuery ( baseOptions ?: ApolloReactHooks . QueryHookOptions & lt ; AllPostsQuery , AllPostsQueryVariables >) { return ApolloReactHooks . useQuery & lt ; AllPostsQuery , AllPostsQueryVariables >( AllPostsDocument , baseOptions ); } export function useAllPostsLazyQuery ( baseOptions ?: ApolloReactHooks . LazyQueryHookOptions & lt ; AllPostsQuery , AllPostsQueryVariables >) { return ApolloReactHooks . useLazyQuery & lt ; AllPostsQuery , AllPostsQueryVariables >( AllPostsDocument , baseOptions ); } React Component では生成されたカスタム hooks を次のように呼び出してサーバーから返ってくる結果を受け取って、データ出力、ローディング状態のチェック、エラーハンドリング等を行います。 const { data , loading , error } = useAllPostsQuery (); Mutation データの書き込みは useMutation で行います。 Query 同様、 GraphQL Code Generator によって生成されたカスタム hooks use***Mutation を使っています。 cache の更新 Mutation が複数エンティティの更新、エンティティの新規作成または削除の場合、Apollo Client の cache は自動更新されず、Mutation の結果が自動的に render されません。 このような場合でも、 useMutation の update option を使えば、 cache オブジェクトを引数に取れる関数を設定できるので、この関数内で直接 cache を更新できます。 また、 update の代わりに refetchQueries の option を使って、任意の Query を実行して、シンプルに cache を更新することもできます。 但し、この方法だと Network 通信によるオーバーヘッドが発生します。 このオーバーヘッドを犠牲にしてでも、サーバーからデータ取得したい Query があるような場合には、この refetchQueries が有効です。 local state の管理 ここからは特定の component の状態管理を local state を使ってどのように管理しているかを、ご説明していきます。 @client を使った Query Next.js のプロジェクトで、local state の管理を Apollo Client で行う場合の例としては、次の通りです。 スキーマ： # src / components / app / Home / apollo . schema . graphql type Home { currentPostId: Int! } extend type Query { home: Home } クエリ： # src / components / app / Home / apollo . query . graphql query HomeCurrentPostId { home @ client { currentPostId } } キャッシュの初期値： // src/components/app/Home/apollo.cache.ts export const cache = { __typename: 'Home' , currentPostId: 0 , ..., }; // src/apollo/cache.ts const caches = { ..., home: home . cache , }; export { ..., caches , }; // src/pages/_app.tsx export const cache = new InMemoryCache (); ... const client = new ApolloClient ({ link , cache: cache . restore ( initialState || {}), resolvers , connectToDevTools: true , }); cache . writeData ({ data: caches }); GraphQL クエリとスキーマが定義されていれば GraphQL Code Generator が use***Query のコードを生成する設定にしています。 ローカルデータの場合、クエリで @client ディレクティブをつけてローカルデータであることを明示します。 @client を使った Mutation local state の更新を GraphQL の Mutation として行う場合の例としては、次の通りです。 スキーマ： # src / components / app / Home / apollo . schema . graphql type UpdateCurrentPostId { currentPostId: Int! } extend type Mutation { updateCurrentPostId(id: Int!): UpdateCurrentPostId } クエリ： # src / components / app / Home / apollo . query . graphql mutation UpdateCurrentPostId ( $id : Int !) { updateCurrentPostId ( id : $id ) @ client { currentPostId @ client } } resolver： // src/components/app/Home/apollo.cache.ts const updateCurrentPostId : MutationResolvers [ "updateCurrentPostId" ] = ( _ , args , { cache } ) => { cache . writeData ({ data: { home: { __typename: "Home" , currentPostId: args . id , }, }, }); return null ; }; export const Mutation = { updateCurrentPostId , }; Query 同様に @client ディレクティブをつけてローカルデータであることを明示します。 実際の Mutation の処理自体は resolver の中に cache.writeData() を使って記述します。 Mutation の命名は、 動詞+名詞の形式で可能な限り意味のある具体的な名前をつける ことを意識しています。 Apollo を使った開発を便利にしてくれるツール Apollo Client を使って開発する際は、ローカルの Apollo cache の状態や、クエリを試しに実行するためのツールとして、Google Chrome の拡張機能 Apollo Client Developer Tools が非常に便利です。 こちらの拡張機能を Chrome にインストールすると、Apollo Client を使って GraphQL API にアクセスするサイトに遷移した状態で Chrome Dev Tools を開くと Apollo のタブが表示されます。そこでクエリの実行や、API 仕様の確認、ローカルの Apollo cache の確認等を行うことができます。 GraphQL 関連のテストコードについて Apollo Client を使った React Component の開発で、Query および Mutation 実行のテストを実施するには、テストフレームワークの Jest、react-testing-library とあわせて、Apollo 公式でも紹介されている MockedProvider を用いる方法が一般的かと思います。 クエリとクエリに対するレスポンスを組み合わせたモックデータを用意しておき、ApolloProvider の代わりに MockedProvider でテスト対象の component をラップすることで、API サーバーや Network 環境に依存せず、モックで指定したクエリがリクエストされると、モックでそれに対応するように用意したレスポンスデータが確実に取得できる仕組みを作れます。 その仕組みと react-testing-library を使って、component で render される UI 上の操作をトリガーにして実行される、クエリのテストを行うことができます。 Query だけではなく Mutation もモックすることができて、便利なツールではありますが、テストケース毎にモックデータは手動で作成しなければならない点が、なかなか骨が折れる作業です。 実際にアプリケーションを動かして、テスト対象の component を render し、Query に渡される variables やレスポンスの値を Console に出力し、ブラウザの Dev Tools 上で一個一個オブジェクトをコピーして、エディタに貼り付けしたりする作業が発生します。 AutoMockedProvider の作成 そこで、わざわざテスト作成やスキーマ変更の度に、手動でモックデータを用意しなくても、GraphQL スキーマで定義されている型を見て、自動でクエリに対するレスポンスをモックしてくれる AutoMockedProvider を、 こちらの記事 を参考にして作成しました。 MockedProvider の代わりに、AutoMockedProvider を用いてテスト対象の Component をラップすることで、MockedProvider を使ってテストしていた内容と同じテストが実施できます。 MockedProvider を使って毎回モックデータを用意し、テストを実施することに疲れている方は是非、お試しください。 （紹介先の記事では、 graphql-tools の makeExecutableSchema() に渡す schemaSDL が json ファイルで定義されていますが、 graphql-tag のライブラリを併用すれば、graphql ファイルでも同様に schemaSDL として適用することも可能です） リニューアルを振り返って 今回のリニューアルでは、GraphQL、TypeScript、React をセットで採用したことにより、フロント側では GraphQL Code Generator を使って、あらかじめ用意しておいた GraphQL スキーマから、TypeScript の型だけではなく、React の Hooks 関数まで生成して利用できたことが、開発効率の向上に非常に影響を与えたと思います。 GraphQL API のクライアントで、アプリケーション全体の状態管理を行う Apollo Client の cache 機構の使い方等を体得するまでに、学習コストは決してゼロではありませんでしたが、TypeScript と GraphQL の型システムの恩恵をフルに受け、Next.js のレールにのっかり、型安全な開発環境を手に入れることができました。 我々、開発者の体験だけではなく、今後のプロダクト全体への生産性にも良い影響を及ぼしてくれると確信しています。 さいごに メドレーではエンジニア・デザイナーを積極募集しています。 「テクノロジーを活用して医療ヘルスケアの未来をつくる」というミッションに共感し、課題解決を行いたい方は是非、ご応募ください。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。メドレーのエンジニアの山田です。現在、医療介護求人サイト「ジョブメドレー」のチームで開発を担当しています。 今回、ジョブメドレーの社内スタッフが利用する社内システムをリニューアルした事例をご紹介します。 リニューアル対象はバックエンド領域も含まれますが、本記事ではフロントエンドの話を中心にご紹介します。 また、弊社デザイナー酒井が以前投稿した デザイナーがデザインツールを使わずに、React を使ってデザインした話 も関連しているので、よろしければあわせてご覧ください。 リニューアルの背景 社内システムでは、求人サイト「ジョブメドレー」を利用する求職者に関する情報や求職者の応募状況を管理しています。 前回のリニューアルから時間が経ち、複雑性が高くなってきました。その複雑性に比例して、新機能の追加や改修するためのコストも高くなっていました。 そこで上記の課題を解決するため、状態管理がしやすく、テストコードも書きやすい、メンテナブルなアーキテクチャにすべくリニューアルを実施することにしました。 検証期間も経て、今回のリニューアルにあわせて新規に作成する API は、GraphQL によって実装することを決めました。 型システムを持つため画面に必要なデータを柔軟に過不足なく取得できる、手動でドキュメントに落とし込まなくてもスキーマが定義されていれば API の仕様を簡単に把握できる、等がメリットとして感じられました。 特に、GraphQL が持つ型システムが、TypeScript、Apollo、GraphQL Code Generator のライブラリを組み合わせることで、API に渡すパラメータや、レスポンスにも型が適用され、GraphQL スキーマの変更にクライアントの実装が比較的容易に追従できることが、大きなポイントでした。 フロントエンドの技術的なリニューアル内容 今回は特に、リニューアルに用いられたフレームワークやライブラリ、Apollo Client を用いた状態管理、テストコード実装における Tips 等をそれぞれ部分的にご紹介します。 採用したフレームワークと主要ライブラリ 採用ライブラリ 説明 Next.js React 用のフレームワーク（ボイラープレート） TypeScript JavaScript のスーパーセットで、静的型付け言語 React UI を構築するためのライブラリ（バージョン 16.8.0 でリリースされた hooks を全面的に使用） Apollo Client GraphQL API のクライアントで、アプリケーション全体の状態管理を実施 GraphQL Code Generator GraphQL スキーマから定義ファイル（型、カスタム hooks 等）を生成 emotion + Styled System CSS in JS として利用 formik + yup フォームのビルダー + バリデーター Jest + React Testing Library テストコード実装用のツール群 ESLint + Prettier ルールに基づいたコードの静的解析 + スタイリング TypeScript 今回のリニューアルで求められたことの一つとして、さらなる改善・新規機能追加などをしていく上で、ソフトウェア品質を担保するための、アプリケーションの堅牢さがありました。 そこで、フロントエンド側の開発言語としては、プログラムコード内で宣言された型によって、エラーを未然に防ぎつつ、VSCode をはじめとするエディタのコード補完の恩恵を受けられるメリット等を考慮して TypeScript の採用を決めました。また、他のプロジェクトでも既に TypeScript は部分的に利用し始めていた事情もあり、逆に TypeScript を採用しない、という選択肢はあまり考えられませんでした。 React UI を構築するためのライブラリ/フレームワークは React を採用しました。こちらも、弊社では別プロジェクトで React を既に利用し始めていたこともあり、学習コストの観点から、新たに他のフレームワークを選択するメリットはほぼ無かったためです。しかし、その事を差し引いたとしても TypeScript と GraphQL との相性の良さで、React が優勢でした。 特に、React の場合は、GraphQL スキーマをベースに、GraphQL Code Generator によって型定義ファイルだけではなく、GraphQL API とのやり取りに使えるカスタム hooks も生成して利用できるという点が、大きな利点として考えられました。 Next.js フロントエンド開発環境を素早く構築するため、ボイラープレートとして Next.js を採用しました。 Next.js の具体的な採用ポイントとしては、主に次の３点です。 webpack における、バンドルやコンパイル、ホットリロード等の設定に時間を費やすことなく、ビジネスロジックの実装に集中できる 必要があれば、next.config.js で設定を拡張できる CRA（Create React App）とは異なり、拡張性に優れている pages 配下に置く React Component のディレクトリ構成が、自動的にルーティングとして定義される ルーティングに関する設計作業が不要になる 自動コード分割等によるパフォーマンス最適化をよしなに行ってくれる React Component の分類 component は大きく２つに分類し、 src/components/app/ と src/components/ui/ それぞれのディレクトリに component を置いています。分類は以下の基準で行ないました。 app : 本アプリケーション固有で使用される想定のもので、再利用性が低く、具体的な component ui : 本アプリケーション外でも使用可能な、再利用性が高く、抽象的な component 社内向けシステムではあるものの、Material-UI や Ant Design 等をはじめとする、外部の UI ライブラリは使用せず、カスタマイズがしやすいように、全て自前で作成しました。 app 配下と ui 配下、どちらの component も基本的には コロケーション の考え方でファイルを構成しています。 一般的には、よく一緒に変更するファイルを近くに置いておくのは良いアイディアです。 この原則は、「コロケーション」と呼ばれます。 この考え方でファイルを構成することで、関連するファイルがまとまっていて、作業がしやすくなります。 src/ components/ app/ partials/ ${ component 名} / apollo.cache.ts apollo.query.graphql index.tsx index.test.tsx ... screens/ ${ component 名} / apollo.cache.ts apollo.query.graphql index.tsx index.test.tsx ${子 component 名} / apollo.cache.ts apollo.query.graphql index.tsx index.test.tsx validation.ts src/components/app ディレクトリ配下でさらに、 partials と screens のディレクトリで component を分けています。 screens には、Next.js で route として扱われる src/pages 配下の component から import される component が配置されています。 画面のバリエーションが増える度に、この screens にファイルが追加されていきます。 partials には、app 配下で複数の component から利用される component（画面をまたいで共有されるもの等）を配置しています。 screens と partials それぞれ直下の component で、必要であれば適宜、component を分割して子 component を持つ構成にしています。 apollo.cache.ts と apollo.query.graphql については後述の状態管理の話でご紹介します。 状態管理 アプリケーションの状態管理については、グローバルにアクセスできる状態の管理には Apollo Client の InMemoryCache による cache 機構で行い、特定の component 内に閉じている局所的な状態の管理には useState 等の React Hooks を使って行っています。 状態管理の必要性が生じた際、アプリケーションの複雑性を上げないように、なるべく useState 等の hooks を用いた local state だけで済ませられないかどうかを検討します。 例えば、クリックするとドロップダウンリストが表示されるセレクトボックスの component で、ドロップダウンリストの表示状態をその component 内だけで扱いたいのであれば useState を用いた local state で十分であると考えられます。 親子関係ではない component 同士でのやりとりが必要になった時や、サーバのデータと関連する場合等で、ローカルのデータを一元管理しておいた方が良さそうなケースでは、Apollo Client の cache を利用します。 Apollo Client Apollo に関連するファイルの構成については以下の通りです。 src/ apollo/ cache.ts client.ts types.ts withApollo.ts cache.ts : Apollo における local state の initialState と resolver を全画面分このファイルでまとめて、最終的に Next.js の src/pages/_app.tsx に渡るようにする component 固有の local state に関する initialState および state の updater となる resolver は component 毎の apollo.cache.ts にて、別途定義 client.ts : Apollo Client のインスタンスを生成するファイル types.ts : Apollo 関連の型定義ファイル withApollo.ts : Apllo Client の <ApolloProvider /> でラップして返す Higher-Order Compoents(HOC) 実装については割愛しますが、client.ts と withApollo.ts に関しては、Next.js の example（ with-apollo ）等を参考にしました。 画面固有の Apollo の状態管理に関わるファイルは src/components/**/${component 名}/ 配下に置いています。 こちらもコロケーションの考え方で、component に関わる状態管理は該当の component と同じ場所に置くことを意識しています。 src/ components/ app/ ${ component 名} / apollo.cache.ts apollo.query.graphql apollo.schema.graphql apollo.cache.ts : component 固有の Apollo における local state の initialState および resolver を定義するファイル apollo.query.graphql : クエリを定義するファイル apollo.schema.graphql : local state の GraphQL スキーマを定義ファイル ファイルの命名について、 ディレクトリ階層をできるだけ深くしたくない ので、 apollo 等によるディレクトリは設けていませんが、Apollo 関連のファイル群として認識できるよう、ファイル名に apollo. のプレフィックスをつけて命名しています。 Query と Mutation の実行について GraphQL Code Generator のプラグイン TypeScript React Apollo をインストールして、hooks を生成する設定にした上で、component 毎にそれぞれ GraphQL のスキーマとクエリが記述された .graphql ファイルをもとに、GraphQL Code Generator が生成するカスタム hooks を利用します。 こちらのカスタム hooks を React Component で利用することで、Apollo Client 経由で GraphQL API とローカルの Apollo cache に接続して、データのやり取りを行うことができます。 Query Query の hooks は２種類あり、実行するタイミングによっていずれか適切な方を選んで実行しています。 API 実行タイミング useQuery Component が render されたらクエリ実行 useLazyQuery 任意のイベントをトリガーにしてクエリ実行 use***Query 通常であれば useQuery でクエリの結果を render しますが、GraphQL Code Generator を利用する場合は、それぞれのクエリをラップしたカスタム hooks が生成されるので、 useQuery , useLazyQuery をそのまま使うことはありません。 query AllPosts { allPosts { id title rating } } ↑ のようなクエリを用意すると src/__generated__/graphql.tsx に対して、次のようなカスタム hooks が型と一緒に生成される設定にしています。 // Apollo Client: 2.6.9、GraphQL Code Generator: 1.15.0 の場合の例 export function useAllPostsQuery ( baseOptions ?: ApolloReactHooks . QueryHookOptions & lt ; AllPostsQuery , AllPostsQueryVariables >) { return ApolloReactHooks . useQuery & lt ; AllPostsQuery , AllPostsQueryVariables >( AllPostsDocument , baseOptions ); } export function useAllPostsLazyQuery ( baseOptions ?: ApolloReactHooks . LazyQueryHookOptions & lt ; AllPostsQuery , AllPostsQueryVariables >) { return ApolloReactHooks . useLazyQuery & lt ; AllPostsQuery , AllPostsQueryVariables >( AllPostsDocument , baseOptions ); } React Component では生成されたカスタム hooks を次のように呼び出してサーバーから返ってくる結果を受け取って、データ出力、ローディング状態のチェック、エラーハンドリング等を行います。 const { data , loading , error } = useAllPostsQuery (); Mutation データの書き込みは useMutation で行います。 Query 同様、 GraphQL Code Generator によって生成されたカスタム hooks use***Mutation を使っています。 cache の更新 Mutation が複数エンティティの更新、エンティティの新規作成または削除の場合、Apollo Client の cache は自動更新されず、Mutation の結果が自動的に render されません。 このような場合でも、 useMutation の update option を使えば、 cache オブジェクトを引数に取れる関数を設定できるので、この関数内で直接 cache を更新できます。 また、 update の代わりに refetchQueries の option を使って、任意の Query を実行して、シンプルに cache を更新することもできます。 但し、この方法だと Network 通信によるオーバーヘッドが発生します。 このオーバーヘッドを犠牲にしてでも、サーバーからデータ取得したい Query があるような場合には、この refetchQueries が有効です。 local state の管理 ここからは特定の component の状態管理を local state を使ってどのように管理しているかを、ご説明していきます。 @client を使った Query Next.js のプロジェクトで、local state の管理を Apollo Client で行う場合の例としては、次の通りです。 スキーマ： # src / components / app / Home / apollo . schema . graphql type Home { currentPostId: Int! } extend type Query { home: Home } クエリ： # src / components / app / Home / apollo . query . graphql query HomeCurrentPostId { home @ client { currentPostId } } キャッシュの初期値： // src/components/app/Home/apollo.cache.ts export const cache = { __typename: 'Home' , currentPostId: 0 , ..., }; // src/apollo/cache.ts const caches = { ..., home: home . cache , }; export { ..., caches , }; // src/pages/_app.tsx export const cache = new InMemoryCache (); ... const client = new ApolloClient ({ link , cache: cache . restore ( initialState || {}), resolvers , connectToDevTools: true , }); cache . writeData ({ data: caches }); GraphQL クエリとスキーマが定義されていれば GraphQL Code Generator が use***Query のコードを生成する設定にしています。 ローカルデータの場合、クエリで @client ディレクティブをつけてローカルデータであることを明示します。 @client を使った Mutation local state の更新を GraphQL の Mutation として行う場合の例としては、次の通りです。 スキーマ： # src / components / app / Home / apollo . schema . graphql type UpdateCurrentPostId { currentPostId: Int! } extend type Mutation { updateCurrentPostId(id: Int!): UpdateCurrentPostId } クエリ： # src / components / app / Home / apollo . query . graphql mutation UpdateCurrentPostId ( $id : Int !) { updateCurrentPostId ( id : $id ) @ client { currentPostId @ client } } resolver： // src/components/app/Home/apollo.cache.ts const updateCurrentPostId : MutationResolvers [ "updateCurrentPostId" ] = ( _ , args , { cache } ) => { cache . writeData ({ data: { home: { __typename: "Home" , currentPostId: args . id , }, }, }); return null ; }; export const Mutation = { updateCurrentPostId , }; Query 同様に @client ディレクティブをつけてローカルデータであることを明示します。 実際の Mutation の処理自体は resolver の中に cache.writeData() を使って記述します。 Mutation の命名は、 動詞+名詞の形式で可能な限り意味のある具体的な名前をつける ことを意識しています。 Apollo を使った開発を便利にしてくれるツール Apollo Client を使って開発する際は、ローカルの Apollo cache の状態や、クエリを試しに実行するためのツールとして、Google Chrome の拡張機能 Apollo Client Developer Tools が非常に便利です。 こちらの拡張機能を Chrome にインストールすると、Apollo Client を使って GraphQL API にアクセスするサイトに遷移した状態で Chrome Dev Tools を開くと Apollo のタブが表示されます。そこでクエリの実行や、API 仕様の確認、ローカルの Apollo cache の確認等を行うことができます。 GraphQL 関連のテストコードについて Apollo Client を使った React Component の開発で、Query および Mutation 実行のテストを実施するには、テストフレームワークの Jest、react-testing-library とあわせて、Apollo 公式でも紹介されている MockedProvider を用いる方法が一般的かと思います。 クエリとクエリに対するレスポンスを組み合わせたモックデータを用意しておき、ApolloProvider の代わりに MockedProvider でテスト対象の component をラップすることで、API サーバーや Network 環境に依存せず、モックで指定したクエリがリクエストされると、モックでそれに対応するように用意したレスポンスデータが確実に取得できる仕組みを作れます。 その仕組みと react-testing-library を使って、component で render される UI 上の操作をトリガーにして実行される、クエリのテストを行うことができます。 Query だけではなく Mutation もモックすることができて、便利なツールではありますが、テストケース毎にモックデータは手動で作成しなければならない点が、なかなか骨が折れる作業です。 実際にアプリケーションを動かして、テスト対象の component を render し、Query に渡される variables やレスポンスの値を Console に出力し、ブラウザの Dev Tools 上で一個一個オブジェクトをコピーして、エディタに貼り付けしたりする作業が発生します。 AutoMockedProvider の作成 そこで、わざわざテスト作成やスキーマ変更の度に、手動でモックデータを用意しなくても、GraphQL スキーマで定義されている型を見て、自動でクエリに対するレスポンスをモックしてくれる AutoMockedProvider を、 こちらの記事 を参考にして作成しました。 MockedProvider の代わりに、AutoMockedProvider を用いてテスト対象の Component をラップすることで、MockedProvider を使ってテストしていた内容と同じテストが実施できます。 MockedProvider を使って毎回モックデータを用意し、テストを実施することに疲れている方は是非、お試しください。 （紹介先の記事では、 graphql-tools の makeExecutableSchema() に渡す schemaSDL が json ファイルで定義されていますが、 graphql-tag のライブラリを併用すれば、graphql ファイルでも同様に schemaSDL として適用することも可能です） リニューアルを振り返って 今回のリニューアルでは、GraphQL、TypeScript、React をセットで採用したことにより、フロント側では GraphQL Code Generator を使って、あらかじめ用意しておいた GraphQL スキーマから、TypeScript の型だけではなく、React の Hooks 関数まで生成して利用できたことが、開発効率の向上に非常に影響を与えたと思います。 GraphQL API のクライアントで、アプリケーション全体の状態管理を行う Apollo Client の cache 機構の使い方等を体得するまでに、学習コストは決してゼロではありませんでしたが、TypeScript と GraphQL の型システムの恩恵をフルに受け、Next.js のレールにのっかり、型安全な開発環境を手に入れることができました。 我々、開発者の体験だけではなく、今後のプロダクト全体への生産性にも良い影響を及ぼしてくれると確信しています。 さいごに メドレーではエンジニア・デザイナーを積極募集しています。 「テクノロジーを活用して医療ヘルスケアの未来をつくる」というミッションに共感し、課題解決を行いたい方は是非、ご応募ください。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。メドレーのエンジニアの山田です。現在、医療介護求人サイト「ジョブメドレー」のチームで開発を担当しています。 今回、ジョブメドレーの社内スタッフが利用する社内システムをリニューアルした事例をご紹介します。 リニューアル対象はバックエンド領域も含まれますが、本記事ではフロントエンドの話を中心にご紹介します。 また、弊社デザイナー酒井が以前投稿した デザイナーがデザインツールを使わずに、React を使ってデザインした話 も関連しているので、よろしければあわせてご覧ください。 リニューアルの背景 社内システムでは、求人サイト「ジョブメドレー」を利用する求職者に関する情報や求職者の応募状況を管理しています。 前回のリニューアルから時間が経ち、複雑性が高くなってきました。その複雑性に比例して、新機能の追加や改修するためのコストも高くなっていました。 そこで上記の課題を解決するため、状態管理がしやすく、テストコードも書きやすい、メンテナブルなアーキテクチャにすべくリニューアルを実施することにしました。 検証期間も経て、今回のリニューアルにあわせて新規に作成する API は、GraphQL によって実装することを決めました。 型システムを持つため画面に必要なデータを柔軟に過不足なく取得できる、手動でドキュメントに落とし込まなくてもスキーマが定義されていれば API の仕様を簡単に把握できる、等がメリットとして感じられました。 特に、GraphQL が持つ型システムが、TypeScript、Apollo、GraphQL Code Generator のライブラリを組み合わせることで、API に渡すパラメータや、レスポンスにも型が適用され、GraphQL スキーマの変更にクライアントの実装が比較的容易に追従できることが、大きなポイントでした。 フロントエンドの技術的なリニューアル内容 今回は特に、リニューアルに用いられたフレームワークやライブラリ、Apollo Client を用いた状態管理、テストコード実装における Tips 等をそれぞれ部分的にご紹介します。 採用したフレームワークと主要ライブラリ 採用ライブラリ 説明 Next.js React 用のフレームワーク（ボイラープレート） TypeScript JavaScript のスーパーセットで、静的型付け言語 React UI を構築するためのライブラリ（バージョン 16.8.0 でリリースされた hooks を全面的に使用） Apollo Client GraphQL API のクライアントで、アプリケーション全体の状態管理を実施 GraphQL Code Generator GraphQL スキーマから定義ファイル（型、カスタム hooks 等）を生成 emotion + Styled System CSS in JS として利用 formik + yup フォームのビルダー + バリデーター Jest + React Testing Library テストコード実装用のツール群 ESLint + Prettier ルールに基づいたコードの静的解析 + スタイリング TypeScript 今回のリニューアルで求められたことの一つとして、さらなる改善・新規機能追加などをしていく上で、ソフトウェア品質を担保するための、アプリケーションの堅牢さがありました。 そこで、フロントエンド側の開発言語としては、プログラムコード内で宣言された型によって、エラーを未然に防ぎつつ、VSCode をはじめとするエディタのコード補完の恩恵を受けられるメリット等を考慮して TypeScript の採用を決めました。また、他のプロジェクトでも既に TypeScript は部分的に利用し始めていた事情もあり、逆に TypeScript を採用しない、という選択肢はあまり考えられませんでした。 React UI を構築するためのライブラリ/フレームワークは React を採用しました。こちらも、弊社では別プロジェクトで React を既に利用し始めていたこともあり、学習コストの観点から、新たに他のフレームワークを選択するメリットはほぼ無かったためです。しかし、その事を差し引いたとしても TypeScript と GraphQL との相性の良さで、React が優勢でした。 特に、React の場合は、GraphQL スキーマをベースに、GraphQL Code Generator によって型定義ファイルだけではなく、GraphQL API とのやり取りに使えるカスタム hooks も生成して利用できるという点が、大きな利点として考えられました。 Next.js フロントエンド開発環境を素早く構築するため、ボイラープレートとして Next.js を採用しました。 Next.js の具体的な採用ポイントとしては、主に次の３点です。 webpack における、バンドルやコンパイル、ホットリロード等の設定に時間を費やすことなく、ビジネスロジックの実装に集中できる 必要があれば、next.config.js で設定を拡張できる CRA（Create React App）とは異なり、拡張性に優れている pages 配下に置く React Component のディレクトリ構成が、自動的にルーティングとして定義される ルーティングに関する設計作業が不要になる 自動コード分割等によるパフォーマンス最適化をよしなに行ってくれる React Component の分類 component は大きく２つに分類し、 src/components/app/ と src/components/ui/ それぞれのディレクトリに component を置いています。分類は以下の基準で行ないました。 app : 本アプリケーション固有で使用される想定のもので、再利用性が低く、具体的な component ui : 本アプリケーション外でも使用可能な、再利用性が高く、抽象的な component 社内向けシステムではあるものの、Material-UI や Ant Design 等をはじめとする、外部の UI ライブラリは使用せず、カスタマイズがしやすいように、全て自前で作成しました。 app 配下と ui 配下、どちらの component も基本的には コロケーション の考え方でファイルを構成しています。 一般的には、よく一緒に変更するファイルを近くに置いておくのは良いアイディアです。 この原則は、「コロケーション」と呼ばれます。 この考え方でファイルを構成することで、関連するファイルがまとまっていて、作業がしやすくなります。 src/ components/ app/ partials/ ${ component 名} / apollo.cache.ts apollo.query.graphql index.tsx index.test.tsx ... screens/ ${ component 名} / apollo.cache.ts apollo.query.graphql index.tsx index.test.tsx ${子 component 名} / apollo.cache.ts apollo.query.graphql index.tsx index.test.tsx validation.ts src/components/app ディレクトリ配下でさらに、 partials と screens のディレクトリで component を分けています。 screens には、Next.js で route として扱われる src/pages 配下の component から import される component が配置されています。 画面のバリエーションが増える度に、この screens にファイルが追加されていきます。 partials には、app 配下で複数の component から利用される component（画面をまたいで共有されるもの等）を配置しています。 screens と partials それぞれ直下の component で、必要であれば適宜、component を分割して子 component を持つ構成にしています。 apollo.cache.ts と apollo.query.graphql については後述の状態管理の話でご紹介します。 状態管理 アプリケーションの状態管理については、グローバルにアクセスできる状態の管理には Apollo Client の InMemoryCache による cache 機構で行い、特定の component 内に閉じている局所的な状態の管理には useState 等の React Hooks を使って行っています。 状態管理の必要性が生じた際、アプリケーションの複雑性を上げないように、なるべく useState 等の hooks を用いた local state だけで済ませられないかどうかを検討します。 例えば、クリックするとドロップダウンリストが表示されるセレクトボックスの component で、ドロップダウンリストの表示状態をその component 内だけで扱いたいのであれば useState を用いた local state で十分であると考えられます。 親子関係ではない component 同士でのやりとりが必要になった時や、サーバのデータと関連する場合等で、ローカルのデータを一元管理しておいた方が良さそうなケースでは、Apollo Client の cache を利用します。 Apollo Client Apollo に関連するファイルの構成については以下の通りです。 src/ apollo/ cache.ts client.ts types.ts withApollo.ts cache.ts : Apollo における local state の initialState と resolver を全画面分このファイルでまとめて、最終的に Next.js の src/pages/_app.tsx に渡るようにする component 固有の local state に関する initialState および state の updater となる resolver は component 毎の apollo.cache.ts にて、別途定義 client.ts : Apollo Client のインスタンスを生成するファイル types.ts : Apollo 関連の型定義ファイル withApollo.ts : Apllo Client の <ApolloProvider /> でラップして返す Higher-Order Compoents(HOC) 実装については割愛しますが、client.ts と withApollo.ts に関しては、Next.js の example（ with-apollo ）等を参考にしました。 画面固有の Apollo の状態管理に関わるファイルは src/components/**/${component 名}/ 配下に置いています。 こちらもコロケーションの考え方で、component に関わる状態管理は該当の component と同じ場所に置くことを意識しています。 src/ components/ app/ ${ component 名} / apollo.cache.ts apollo.query.graphql apollo.schema.graphql apollo.cache.ts : component 固有の Apollo における local state の initialState および resolver を定義するファイル apollo.query.graphql : クエリを定義するファイル apollo.schema.graphql : local state の GraphQL スキーマを定義ファイル ファイルの命名について、 ディレクトリ階層をできるだけ深くしたくない ので、 apollo 等によるディレクトリは設けていませんが、Apollo 関連のファイル群として認識できるよう、ファイル名に apollo. のプレフィックスをつけて命名しています。 Query と Mutation の実行について GraphQL Code Generator のプラグイン TypeScript React Apollo をインストールして、hooks を生成する設定にした上で、component 毎にそれぞれ GraphQL のスキーマとクエリが記述された .graphql ファイルをもとに、GraphQL Code Generator が生成するカスタム hooks を利用します。 こちらのカスタム hooks を React Component で利用することで、Apollo Client 経由で GraphQL API とローカルの Apollo cache に接続して、データのやり取りを行うことができます。 Query Query の hooks は２種類あり、実行するタイミングによっていずれか適切な方を選んで実行しています。 API 実行タイミング useQuery Component が render されたらクエリ実行 useLazyQuery 任意のイベントをトリガーにしてクエリ実行 use***Query 通常であれば useQuery でクエリの結果を render しますが、GraphQL Code Generator を利用する場合は、それぞれのクエリをラップしたカスタム hooks が生成されるので、 useQuery , useLazyQuery をそのまま使うことはありません。 query AllPosts { allPosts { id title rating } } ↑ のようなクエリを用意すると src/__generated__/graphql.tsx に対して、次のようなカスタム hooks が型と一緒に生成される設定にしています。 // Apollo Client: 2.6.9、GraphQL Code Generator: 1.15.0 の場合の例 export function useAllPostsQuery ( baseOptions ?: ApolloReactHooks . QueryHookOptions & lt ; AllPostsQuery , AllPostsQueryVariables >) { return ApolloReactHooks . useQuery & lt ; AllPostsQuery , AllPostsQueryVariables >( AllPostsDocument , baseOptions ); } export function useAllPostsLazyQuery ( baseOptions ?: ApolloReactHooks . LazyQueryHookOptions & lt ; AllPostsQuery , AllPostsQueryVariables >) { return ApolloReactHooks . useLazyQuery & lt ; AllPostsQuery , AllPostsQueryVariables >( AllPostsDocument , baseOptions ); } React Component では生成されたカスタム hooks を次のように呼び出してサーバーから返ってくる結果を受け取って、データ出力、ローディング状態のチェック、エラーハンドリング等を行います。 const { data , loading , error } = useAllPostsQuery (); Mutation データの書き込みは useMutation で行います。 Query 同様、 GraphQL Code Generator によって生成されたカスタム hooks use***Mutation を使っています。 cache の更新 Mutation が複数エンティティの更新、エンティティの新規作成または削除の場合、Apollo Client の cache は自動更新されず、Mutation の結果が自動的に render されません。 このような場合でも、 useMutation の update option を使えば、 cache オブジェクトを引数に取れる関数を設定できるので、この関数内で直接 cache を更新できます。 また、 update の代わりに refetchQueries の option を使って、任意の Query を実行して、シンプルに cache を更新することもできます。 但し、この方法だと Network 通信によるオーバーヘッドが発生します。 このオーバーヘッドを犠牲にしてでも、サーバーからデータ取得したい Query があるような場合には、この refetchQueries が有効です。 local state の管理 ここからは特定の component の状態管理を local state を使ってどのように管理しているかを、ご説明していきます。 @client を使った Query Next.js のプロジェクトで、local state の管理を Apollo Client で行う場合の例としては、次の通りです。 スキーマ： # src / components / app / Home / apollo . schema . graphql type Home { currentPostId: Int! } extend type Query { home: Home } クエリ： # src / components / app / Home / apollo . query . graphql query HomeCurrentPostId { home @ client { currentPostId } } キャッシュの初期値： // src/components/app/Home/apollo.cache.ts export const cache = { __typename: 'Home' , currentPostId: 0 , ..., }; // src/apollo/cache.ts const caches = { ..., home: home . cache , }; export { ..., caches , }; // src/pages/_app.tsx export const cache = new InMemoryCache (); ... const client = new ApolloClient ({ link , cache: cache . restore ( initialState || {}), resolvers , connectToDevTools: true , }); cache . writeData ({ data: caches }); GraphQL クエリとスキーマが定義されていれば GraphQL Code Generator が use***Query のコードを生成する設定にしています。 ローカルデータの場合、クエリで @client ディレクティブをつけてローカルデータであることを明示します。 @client を使った Mutation local state の更新を GraphQL の Mutation として行う場合の例としては、次の通りです。 スキーマ： # src / components / app / Home / apollo . schema . graphql type UpdateCurrentPostId { currentPostId: Int! } extend type Mutation { updateCurrentPostId(id: Int!): UpdateCurrentPostId } クエリ： # src / components / app / Home / apollo . query . graphql mutation UpdateCurrentPostId ( $id : Int !) { updateCurrentPostId ( id : $id ) @ client { currentPostId @ client } } resolver： // src/components/app/Home/apollo.cache.ts const updateCurrentPostId : MutationResolvers [ "updateCurrentPostId" ] = ( _ , args , { cache } ) => { cache . writeData ({ data: { home: { __typename: "Home" , currentPostId: args . id , }, }, }); return null ; }; export const Mutation = { updateCurrentPostId , }; Query 同様に @client ディレクティブをつけてローカルデータであることを明示します。 実際の Mutation の処理自体は resolver の中に cache.writeData() を使って記述します。 Mutation の命名は、 動詞+名詞の形式で可能な限り意味のある具体的な名前をつける ことを意識しています。 Apollo を使った開発を便利にしてくれるツール Apollo Client を使って開発する際は、ローカルの Apollo cache の状態や、クエリを試しに実行するためのツールとして、Google Chrome の拡張機能 Apollo Client Developer Tools が非常に便利です。 こちらの拡張機能を Chrome にインストールすると、Apollo Client を使って GraphQL API にアクセスするサイトに遷移した状態で Chrome Dev Tools を開くと Apollo のタブが表示されます。そこでクエリの実行や、API 仕様の確認、ローカルの Apollo cache の確認等を行うことができます。 GraphQL 関連のテストコードについて Apollo Client を使った React Component の開発で、Query および Mutation 実行のテストを実施するには、テストフレームワークの Jest、react-testing-library とあわせて、Apollo 公式でも紹介されている MockedProvider を用いる方法が一般的かと思います。 クエリとクエリに対するレスポンスを組み合わせたモックデータを用意しておき、ApolloProvider の代わりに MockedProvider でテスト対象の component をラップすることで、API サーバーや Network 環境に依存せず、モックで指定したクエリがリクエストされると、モックでそれに対応するように用意したレスポンスデータが確実に取得できる仕組みを作れます。 その仕組みと react-testing-library を使って、component で render される UI 上の操作をトリガーにして実行される、クエリのテストを行うことができます。 Query だけではなく Mutation もモックすることができて、便利なツールではありますが、テストケース毎にモックデータは手動で作成しなければならない点が、なかなか骨が折れる作業です。 実際にアプリケーションを動かして、テスト対象の component を render し、Query に渡される variables やレスポンスの値を Console に出力し、ブラウザの Dev Tools 上で一個一個オブジェクトをコピーして、エディタに貼り付けしたりする作業が発生します。 AutoMockedProvider の作成 そこで、わざわざテスト作成やスキーマ変更の度に、手動でモックデータを用意しなくても、GraphQL スキーマで定義されている型を見て、自動でクエリに対するレスポンスをモックしてくれる AutoMockedProvider を、 こちらの記事 を参考にして作成しました。 MockedProvider の代わりに、AutoMockedProvider を用いてテスト対象の Component をラップすることで、MockedProvider を使ってテストしていた内容と同じテストが実施できます。 MockedProvider を使って毎回モックデータを用意し、テストを実施することに疲れている方は是非、お試しください。 （紹介先の記事では、 graphql-tools の makeExecutableSchema() に渡す schemaSDL が json ファイルで定義されていますが、 graphql-tag のライブラリを併用すれば、graphql ファイルでも同様に schemaSDL として適用することも可能です） リニューアルを振り返って 今回のリニューアルでは、GraphQL、TypeScript、React をセットで採用したことにより、フロント側では GraphQL Code Generator を使って、あらかじめ用意しておいた GraphQL スキーマから、TypeScript の型だけではなく、React の Hooks 関数まで生成して利用できたことが、開発効率の向上に非常に影響を与えたと思います。 GraphQL API のクライアントで、アプリケーション全体の状態管理を行う Apollo Client の cache 機構の使い方等を体得するまでに、学習コストは決してゼロではありませんでしたが、TypeScript と GraphQL の型システムの恩恵をフルに受け、Next.js のレールにのっかり、型安全な開発環境を手に入れることができました。 我々、開発者の体験だけではなく、今後のプロダクト全体への生産性にも良い影響を及ぼしてくれると確信しています。 さいごに メドレーではエンジニア・デザイナーを積極募集しています。 「テクノロジーを活用して医療ヘルスケアの未来をつくる」というミッションに共感し、課題解決を行いたい方は是非、ご応募ください。 https://www.medley.jp/jobs/

初めまして。CLINICS の開発を担当しているエンジニアの平山です。 （同姓ですが CTO ではございません） CLINICS の開発は「スモールチーム制」をとっておりまして、現在そのうちの１つをチームリードしています。 前職は長らく SIer に勤めていました。去年の 12 月にメドレーに JOIN して、間も無く１年経とうとしている。。と思うと、あっという間だったなぁという印象です。 さて、本日はメドレーで隔週開催している社内勉強会（TechLunch）において発表した内容についてご紹介させて頂ければと思います。 はじめに 「技術を使うための技術」というテーマとなりますが、プロダクト開発をしていく上では欠かせない素養と考えています。メドレーに所属しているエンジニアの１人として、どのように日々課題と向き合っているのか。当テーマを通してお伝えできればと思います。 また、この考え方自体は「医療というテーマ」や「事業の背景（ベンチャー・ SIer）」を問わず必要とされる場面があるかもしれません。（自身も前職では様々な場面でお世話になりました…） 即効性のあるものではありませんが、じわじわ効いてくる内容ではないかと思います。よろしければお付き合いください。 本題 「技術を使うための技術」 みなさんはこの言葉から、何を思い浮かべるでしょうか。筆者が試しに Google で検索した際上位にヒットしたのは AI エンジニア IoT といった結果でした。なるほど。少し雑に解釈すると「技術（アルゴリズム等）を使うための技術（機械学習、家電等）」といった感じなのでしょうか。（この結果を拾ってきたというのも、いい意味で Google すごいなって感じました） 筆者が今回のテーマとして指しているのは、下記となります。 ロジカルシンキング 推論 これらの 思考を整理する「手段」 とエンジニアの武器である 技術という「手段」 をかけ合わせることで、大きなテーマである「医療」に向き合っています。 手段を目的にしてはならない 先に挙げたとおり「思考の整理」も「技術」も 「手段」 に過ぎません。これらを用いて、適切な一手を指していく為には「目的」に対する解像度を高く描く必要があります。 筆者の発表から抜粋した「技術を使うための技術」の要素をイメージした図 整理力 目的を達成する為に必要な「情報」を取捨選択するための要素。 SaaS ✖️ toB の世界においては「プロダクトが解決すべき課題か否かを業務の本質を踏まえて取捨選択する」と言い換えられるかもしれません。 業務知識 目的の「解像度」を高めるための要素。 CLINICS においては、医療情報を扱う上での規制（3 省 2 ガイドライン）や、医療機関（医師・医事・診療科の特性）の業務、診療報酬についての知識、法改正、レセコン（ORCA）… と様々あります。 技術知識 目的を達成する為に必要な「指し手」を選択するための要素。 （エンジニアにとっては説明するまでもない内容であると思いますが） ここが欠けてしまうと絵に描いた餅で終わってしまいます。メドレーのエンジニアにおいても日々研鑽し、プロダクトに対してコミットを続けています。 行動力 目的を達成するための「推進力」を高めるための要素。 各種知識と整理した情報を推進力に変えていく為には、その時の状況に応じた動きをする必要があります。ステークホルダーとの調整は当然ですが、組織内連携といった「横の動き」も必要です。 想像力 これまで挙げたそれぞれの手段を適切に利用していくための要素としての土台が「想像力」であると考えています。 課題（Issue）への取り組み例 番号 概要 ① Issue に取り組む際に「本当に解決すべきこと」についての想像を働かせます。Issue に記載されていることが 本当にプロダクトとして解決すべきことなのか を含めて考えます。これまでの運用が必ずしも正しいわけではない。という点がポイントです。 ② ① について「想像のまま」で終わらせてはいけないので、業務知識と照らし合わせて確度を高めていきます。常勤医師やカスタマーサポートにヒアリングしながら、 医療業務としてのあるべき形の解像度を上げていく プロセスです。 ③ ① 及び ② で高めた解像度は言葉の延長線上なので、関係者間の認識のギャップが発生しやすいです。プロトタイプを作成して、視覚・触感レベルでギャップを埋めていくことで、あるべき形に向けて洗練させていきます。 ④ ① 〜 ③ のタイミングを問わず、必要に応じて関係者と相談しながら進めていきます。エンジニアが立てた仮説をデザイナーの目線で評価・ UI/UX 最適化をして頂いたり、大きめの機能については、医療機関にパイロット運用のご協力を仰いだりすることもあります。 ① 及び ② の項に作業のウェイトが偏っているように見えるかと思います。実際、課題を解決する為の半分以上をここに割いています。 理由は「１度作って公開した機能」は、その後１人歩きをして作成者の意図しない方向で利用をされることがあるからです。 そして、利用者がその運用を定着させてしまうと 誤った機能においても「削ぎ落とすことが困難」 です。これは「使われていない機能」よりも直接的な負債といった形でボディブローのように効いてきます。 「どのような使われ方をするか」について想像すること その使われ方が、プロダクトの目指す世界と合っていること エンジニアは技術を形にする上で、常に想像力を働かせて取り組む必要がある。 というのが筆者の持論です。 さいごに 執筆の締めにあたって CTO ブログを見返してみると、大事なことはここに詰まっていました。筆者は前職の SIer 時代に読んだのですが、この記事にすごく共感したのを覚えています。 toppa.medley.jp toppa.medley.jp メドレーでは 医療ヘルスケアの未来を作る という大きな目標、そしてその未来を作る為に解決すべき課題に向かって、今回ご紹介したプロセスや考え方も含め試行錯誤しながら、事業部一丸でプロダクト開発を推進しています。 エンジニアの総合力を発揮して医療ヘルスケアの未来を一緒に作り上げていきたい！という方にお会い出来ることを楽しみにしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

初めまして。CLINICS の開発を担当しているエンジニアの平山です。 （同姓ですが CTO ではございません） CLINICS の開発は「スモールチーム制」をとっておりまして、現在そのうちの１つをチームリードしています。 前職は長らく SIer に勤めていました。去年の 12 月にメドレーに JOIN して、間も無く１年経とうとしている。。と思うと、あっという間だったなぁという印象です。 さて、本日はメドレーで隔週開催している社内勉強会（TechLunch）において発表した内容についてご紹介させて頂ければと思います。 はじめに 「技術を使うための技術」というテーマとなりますが、プロダクト開発をしていく上では欠かせない素養と考えています。メドレーに所属しているエンジニアの１人として、どのように日々課題と向き合っているのか。当テーマを通してお伝えできればと思います。 また、この考え方自体は「医療というテーマ」や「事業の背景（ベンチャー・ SIer）」を問わず必要とされる場面があるかもしれません。（自身も前職では様々な場面でお世話になりました…） 即効性のあるものではありませんが、じわじわ効いてくる内容ではないかと思います。よろしければお付き合いください。 本題 「技術を使うための技術」 みなさんはこの言葉から、何を思い浮かべるでしょうか。筆者が試しに Google で検索した際上位にヒットしたのは AI エンジニア IoT といった結果でした。なるほど。少し雑に解釈すると「技術（アルゴリズム等）を使うための技術（機械学習、家電等）」といった感じなのでしょうか。（この結果を拾ってきたというのも、いい意味で Google すごいなって感じました） 筆者が今回のテーマとして指しているのは、下記となります。 ロジカルシンキング 推論 これらの 思考を整理する「手段」 とエンジニアの武器である 技術という「手段」 をかけ合わせることで、大きなテーマである「医療」に向き合っています。 手段を目的にしてはならない 先に挙げたとおり「思考の整理」も「技術」も 「手段」 に過ぎません。これらを用いて、適切な一手を指していく為には「目的」に対する解像度を高く描く必要があります。 筆者の発表から抜粋した「技術を使うための技術」の要素をイメージした図 整理力 目的を達成する為に必要な「情報」を取捨選択するための要素。 SaaS ✖️ toB の世界においては「プロダクトが解決すべき課題か否かを業務の本質を踏まえて取捨選択する」と言い換えられるかもしれません。 業務知識 目的の「解像度」を高めるための要素。 CLINICS においては、医療情報を扱う上での規制（3 省 2 ガイドライン）や、医療機関（医師・医事・診療科の特性）の業務、診療報酬についての知識、法改正、レセコン（ORCA）… と様々あります。 技術知識 目的を達成する為に必要な「指し手」を選択するための要素。 （エンジニアにとっては説明するまでもない内容であると思いますが） ここが欠けてしまうと絵に描いた餅で終わってしまいます。メドレーのエンジニアにおいても日々研鑽し、プロダクトに対してコミットを続けています。 行動力 目的を達成するための「推進力」を高めるための要素。 各種知識と整理した情報を推進力に変えていく為には、その時の状況に応じた動きをする必要があります。ステークホルダーとの調整は当然ですが、組織内連携といった「横の動き」も必要です。 想像力 これまで挙げたそれぞれの手段を適切に利用していくための要素としての土台が「想像力」であると考えています。 課題（Issue）への取り組み例 番号 概要 ① Issue に取り組む際に「本当に解決すべきこと」についての想像を働かせます。Issue に記載されていることが 本当にプロダクトとして解決すべきことなのか を含めて考えます。これまでの運用が必ずしも正しいわけではない。という点がポイントです。 ② ① について「想像のまま」で終わらせてはいけないので、業務知識と照らし合わせて確度を高めていきます。常勤医師やカスタマーサポートにヒアリングしながら、 医療業務としてのあるべき形の解像度を上げていく プロセスです。 ③ ① 及び ② で高めた解像度は言葉の延長線上なので、関係者間の認識のギャップが発生しやすいです。プロトタイプを作成して、視覚・触感レベルでギャップを埋めていくことで、あるべき形に向けて洗練させていきます。 ④ ① 〜 ③ のタイミングを問わず、必要に応じて関係者と相談しながら進めていきます。エンジニアが立てた仮説をデザイナーの目線で評価・ UI/UX 最適化をして頂いたり、大きめの機能については、医療機関にパイロット運用のご協力を仰いだりすることもあります。 ① 及び ② の項に作業のウェイトが偏っているように見えるかと思います。実際、課題を解決する為の半分以上をここに割いています。 理由は「１度作って公開した機能」は、その後１人歩きをして作成者の意図しない方向で利用をされることがあるからです。 そして、利用者がその運用を定着させてしまうと 誤った機能においても「削ぎ落とすことが困難」 です。これは「使われていない機能」よりも直接的な負債といった形でボディブローのように効いてきます。 「どのような使われ方をするか」について想像すること その使われ方が、プロダクトの目指す世界と合っていること エンジニアは技術を形にする上で、常に想像力を働かせて取り組む必要がある。 というのが筆者の持論です。 さいごに 執筆の締めにあたって CTO ブログを見返してみると、大事なことはここに詰まっていました。筆者は前職の SIer 時代に読んだのですが、この記事にすごく共感したのを覚えています。 toppa.medley.jp toppa.medley.jp メドレーでは 医療ヘルスケアの未来を作る という大きな目標、そしてその未来を作る為に解決すべき課題に向かって、今回ご紹介したプロセスや考え方も含め試行錯誤しながら、事業部一丸でプロダクト開発を推進しています。 エンジニアの総合力を発揮して医療ヘルスケアの未来を一緒に作り上げていきたい！という方にお会い出来ることを楽しみにしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

初めまして。CLINICS の開発を担当しているエンジニアの平山です。 （同姓ですが CTO ではございません） CLINICS の開発は「スモールチーム制」をとっておりまして、現在そのうちの１つをチームリードしています。 前職は長らく SIer に勤めていました。去年の 12 月にメドレーに JOIN して、間も無く１年経とうとしている。。と思うと、あっという間だったなぁという印象です。 さて、本日はメドレーで隔週開催している社内勉強会（TechLunch）において発表した内容についてご紹介させて頂ければと思います。 はじめに 「技術を使うための技術」というテーマとなりますが、プロダクト開発をしていく上では欠かせない素養と考えています。メドレーに所属しているエンジニアの１人として、どのように日々課題と向き合っているのか。当テーマを通してお伝えできればと思います。 また、この考え方自体は「医療というテーマ」や「事業の背景（ベンチャー・ SIer）」を問わず必要とされる場面があるかもしれません。（自身も前職では様々な場面でお世話になりました…） 即効性のあるものではありませんが、じわじわ効いてくる内容ではないかと思います。よろしければお付き合いください。 本題 「技術を使うための技術」 みなさんはこの言葉から、何を思い浮かべるでしょうか。筆者が試しに Google で検索した際上位にヒットしたのは AI エンジニア IoT といった結果でした。なるほど。少し雑に解釈すると「技術（アルゴリズム等）を使うための技術（機械学習、家電等）」といった感じなのでしょうか。（この結果を拾ってきたというのも、いい意味で Google すごいなって感じました） 筆者が今回のテーマとして指しているのは、下記となります。 ロジカルシンキング 推論 これらの 思考を整理する「手段」 とエンジニアの武器である 技術という「手段」 をかけ合わせることで、大きなテーマである「医療」に向き合っています。 手段を目的にしてはならない 先に挙げたとおり「思考の整理」も「技術」も 「手段」 に過ぎません。これらを用いて、適切な一手を指していく為には「目的」に対する解像度を高く描く必要があります。 筆者の発表から抜粋した「技術を使うための技術」の要素をイメージした図 整理力 目的を達成する為に必要な「情報」を取捨選択するための要素。 SaaS ✖️ toB の世界においては「プロダクトが解決すべき課題か否かを業務の本質を踏まえて取捨選択する」と言い換えられるかもしれません。 業務知識 目的の「解像度」を高めるための要素。 CLINICS においては、医療情報を扱う上での規制（3 省 2 ガイドライン）や、医療機関（医師・医事・診療科の特性）の業務、診療報酬についての知識、法改正、レセコン（ORCA）… と様々あります。 技術知識 目的を達成する為に必要な「指し手」を選択するための要素。 （エンジニアにとっては説明するまでもない内容であると思いますが） ここが欠けてしまうと絵に描いた餅で終わってしまいます。メドレーのエンジニアにおいても日々研鑽し、プロダクトに対してコミットを続けています。 行動力 目的を達成するための「推進力」を高めるための要素。 各種知識と整理した情報を推進力に変えていく為には、その時の状況に応じた動きをする必要があります。ステークホルダーとの調整は当然ですが、組織内連携といった「横の動き」も必要です。 想像力 これまで挙げたそれぞれの手段を適切に利用していくための要素としての土台が「想像力」であると考えています。 課題（Issue）への取り組み例 番号 概要 ① Issue に取り組む際に「本当に解決すべきこと」についての想像を働かせます。Issue に記載されていることが 本当にプロダクトとして解決すべきことなのか を含めて考えます。これまでの運用が必ずしも正しいわけではない。という点がポイントです。 ② ① について「想像のまま」で終わらせてはいけないので、業務知識と照らし合わせて確度を高めていきます。常勤医師やカスタマーサポートにヒアリングしながら、 医療業務としてのあるべき形の解像度を上げていく プロセスです。 ③ ① 及び ② で高めた解像度は言葉の延長線上なので、関係者間の認識のギャップが発生しやすいです。プロトタイプを作成して、視覚・触感レベルでギャップを埋めていくことで、あるべき形に向けて洗練させていきます。 ④ ① 〜 ③ のタイミングを問わず、必要に応じて関係者と相談しながら進めていきます。エンジニアが立てた仮説をデザイナーの目線で評価・ UI/UX 最適化をして頂いたり、大きめの機能については、医療機関にパイロット運用のご協力を仰いだりすることもあります。 ① 及び ② の項に作業のウェイトが偏っているように見えるかと思います。実際、課題を解決する為の半分以上をここに割いています。 理由は「１度作って公開した機能」は、その後１人歩きをして作成者の意図しない方向で利用をされることがあるからです。 そして、利用者がその運用を定着させてしまうと 誤った機能においても「削ぎ落とすことが困難」 です。これは「使われていない機能」よりも直接的な負債といった形でボディブローのように効いてきます。 「どのような使われ方をするか」について想像すること その使われ方が、プロダクトの目指す世界と合っていること エンジニアは技術を形にする上で、常に想像力を働かせて取り組む必要がある。 というのが筆者の持論です。 さいごに 執筆の締めにあたって CTO ブログを見返してみると、大事なことはここに詰まっていました。筆者は前職の SIer 時代に読んだのですが、この記事にすごく共感したのを覚えています。 toppa.medley.jp toppa.medley.jp メドレーでは 医療ヘルスケアの未来を作る という大きな目標、そしてその未来を作る為に解決すべき課題に向かって、今回ご紹介したプロセスや考え方も含め試行錯誤しながら、事業部一丸でプロダクト開発を推進しています。 エンジニアの総合力を発揮して医療ヘルスケアの未来を一緒に作り上げていきたい！という方にお会い出来ることを楽しみにしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

初めまして。CLINICS の開発を担当しているエンジニアの平山です。 （同姓ですが CTO ではございません） CLINICS の開発は「スモールチーム制」をとっておりまして、現在そのうちの１つをチームリードしています。 前職は長らく SIer に勤めていました。去年の 12 月にメドレーに JOIN して、間も無く１年経とうとしている。。と思うと、あっという間だったなぁという印象です。 さて、本日はメドレーで隔週開催している社内勉強会（TechLunch）において発表した内容についてご紹介させて頂ければと思います。 はじめに 「技術を使うための技術」というテーマとなりますが、プロダクト開発をしていく上では欠かせない素養と考えています。メドレーに所属しているエンジニアの１人として、どのように日々課題と向き合っているのか。当テーマを通してお伝えできればと思います。 また、この考え方自体は「医療というテーマ」や「事業の背景（ベンチャー・ SIer）」を問わず必要とされる場面があるかもしれません。（自身も前職では様々な場面でお世話になりました…） 即効性のあるものではありませんが、じわじわ効いてくる内容ではないかと思います。よろしければお付き合いください。 本題 「技術を使うための技術」 みなさんはこの言葉から、何を思い浮かべるでしょうか。筆者が試しに Google で検索した際上位にヒットしたのは AI エンジニア IoT といった結果でした。なるほど。少し雑に解釈すると「技術（アルゴリズム等）を使うための技術（機械学習、家電等）」といった感じなのでしょうか。（この結果を拾ってきたというのも、いい意味で Google すごいなって感じました） 筆者が今回のテーマとして指しているのは、下記となります。 ロジカルシンキング 推論 これらの 思考を整理する「手段」 とエンジニアの武器である 技術という「手段」 をかけ合わせることで、大きなテーマである「医療」に向き合っています。 手段を目的にしてはならない 先に挙げたとおり「思考の整理」も「技術」も 「手段」 に過ぎません。これらを用いて、適切な一手を指していく為には「目的」に対する解像度を高く描く必要があります。 筆者の発表から抜粋した「技術を使うための技術」の要素をイメージした図 整理力 目的を達成する為に必要な「情報」を取捨選択するための要素。 SaaS ✖️ toB の世界においては「プロダクトが解決すべき課題か否かを業務の本質を踏まえて取捨選択する」と言い換えられるかもしれません。 業務知識 目的の「解像度」を高めるための要素。 CLINICS においては、医療情報を扱う上での規制（3 省 2 ガイドライン）や、医療機関（医師・医事・診療科の特性）の業務、診療報酬についての知識、法改正、レセコン（ORCA）… と様々あります。 技術知識 目的を達成する為に必要な「指し手」を選択するための要素。 （エンジニアにとっては説明するまでもない内容であると思いますが） ここが欠けてしまうと絵に描いた餅で終わってしまいます。メドレーのエンジニアにおいても日々研鑽し、プロダクトに対してコミットを続けています。 行動力 目的を達成するための「推進力」を高めるための要素。 各種知識と整理した情報を推進力に変えていく為には、その時の状況に応じた動きをする必要があります。ステークホルダーとの調整は当然ですが、組織内連携といった「横の動き」も必要です。 想像力 これまで挙げたそれぞれの手段を適切に利用していくための要素としての土台が「想像力」であると考えています。 課題（Issue）への取り組み例 番号 概要 ① Issue に取り組む際に「本当に解決すべきこと」についての想像を働かせます。Issue に記載されていることが 本当にプロダクトとして解決すべきことなのか を含めて考えます。これまでの運用が必ずしも正しいわけではない。という点がポイントです。 ② ① について「想像のまま」で終わらせてはいけないので、業務知識と照らし合わせて確度を高めていきます。常勤医師やカスタマーサポートにヒアリングしながら、 医療業務としてのあるべき形の解像度を上げていく プロセスです。 ③ ① 及び ② で高めた解像度は言葉の延長線上なので、関係者間の認識のギャップが発生しやすいです。プロトタイプを作成して、視覚・触感レベルでギャップを埋めていくことで、あるべき形に向けて洗練させていきます。 ④ ① 〜 ③ のタイミングを問わず、必要に応じて関係者と相談しながら進めていきます。エンジニアが立てた仮説をデザイナーの目線で評価・ UI/UX 最適化をして頂いたり、大きめの機能については、医療機関にパイロット運用のご協力を仰いだりすることもあります。 ① 及び ② の項に作業のウェイトが偏っているように見えるかと思います。実際、課題を解決する為の半分以上をここに割いています。 理由は「１度作って公開した機能」は、その後１人歩きをして作成者の意図しない方向で利用をされることがあるからです。 そして、利用者がその運用を定着させてしまうと 誤った機能においても「削ぎ落とすことが困難」 です。これは「使われていない機能」よりも直接的な負債といった形でボディブローのように効いてきます。 「どのような使われ方をするか」について想像すること その使われ方が、プロダクトの目指す世界と合っていること エンジニアは技術を形にする上で、常に想像力を働かせて取り組む必要がある。 というのが筆者の持論です。 さいごに 執筆の締めにあたって CTO ブログを見返してみると、大事なことはここに詰まっていました。筆者は前職の SIer 時代に読んだのですが、この記事にすごく共感したのを覚えています。 toppa.medley.jp toppa.medley.jp メドレーでは 医療ヘルスケアの未来を作る という大きな目標、そしてその未来を作る為に解決すべき課題に向かって、今回ご紹介したプロセスや考え方も含め試行錯誤しながら、事業部一丸でプロダクト開発を推進しています。 エンジニアの総合力を発揮して医療ヘルスケアの未来を一緒に作り上げていきたい！という方にお会い出来ることを楽しみにしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

初めまして。CLINICS の開発を担当しているエンジニアの平山です。 （同姓ですが CTO ではございません） CLINICS の開発は「スモールチーム制」をとっておりまして、現在そのうちの１つをチームリードしています。 前職は長らく SIer に勤めていました。去年の 12 月にメドレーに JOIN して、間も無く１年経とうとしている。。と思うと、あっという間だったなぁという印象です。 さて、本日はメドレーで隔週開催している社内勉強会（TechLunch）において発表した内容についてご紹介させて頂ければと思います。 はじめに 「技術を使うための技術」というテーマとなりますが、プロダクト開発をしていく上では欠かせない素養と考えています。メドレーに所属しているエンジニアの１人として、どのように日々課題と向き合っているのか。当テーマを通してお伝えできればと思います。 また、この考え方自体は「医療というテーマ」や「事業の背景（ベンチャー・ SIer）」を問わず必要とされる場面があるかもしれません。（自身も前職では様々な場面でお世話になりました…） 即効性のあるものではありませんが、じわじわ効いてくる内容ではないかと思います。よろしければお付き合いください。 本題 「技術を使うための技術」 みなさんはこの言葉から、何を思い浮かべるでしょうか。筆者が試しに Google で検索した際上位にヒットしたのは AI エンジニア IoT といった結果でした。なるほど。少し雑に解釈すると「技術（アルゴリズム等）を使うための技術（機械学習、家電等）」といった感じなのでしょうか。（この結果を拾ってきたというのも、いい意味で Google すごいなって感じました） 筆者が今回のテーマとして指しているのは、下記となります。 ロジカルシンキング 推論 これらの 思考を整理する「手段」 とエンジニアの武器である 技術という「手段」 をかけ合わせることで、大きなテーマである「医療」に向き合っています。 手段を目的にしてはならない 先に挙げたとおり「思考の整理」も「技術」も 「手段」 に過ぎません。これらを用いて、適切な一手を指していく為には「目的」に対する解像度を高く描く必要があります。 筆者の発表から抜粋した「技術を使うための技術」の要素をイメージした図 整理力 目的を達成する為に必要な「情報」を取捨選択するための要素。 SaaS ✖️ toB の世界においては「プロダクトが解決すべき課題か否かを業務の本質を踏まえて取捨選択する」と言い換えられるかもしれません。 業務知識 目的の「解像度」を高めるための要素。 CLINICS においては、医療情報を扱う上での規制（3 省 2 ガイドライン）や、医療機関（医師・医事・診療科の特性）の業務、診療報酬についての知識、法改正、レセコン（ORCA）… と様々あります。 技術知識 目的を達成する為に必要な「指し手」を選択するための要素。 （エンジニアにとっては説明するまでもない内容であると思いますが） ここが欠けてしまうと絵に描いた餅で終わってしまいます。メドレーのエンジニアにおいても日々研鑽し、プロダクトに対してコミットを続けています。 行動力 目的を達成するための「推進力」を高めるための要素。 各種知識と整理した情報を推進力に変えていく為には、その時の状況に応じた動きをする必要があります。ステークホルダーとの調整は当然ですが、組織内連携といった「横の動き」も必要です。 想像力 これまで挙げたそれぞれの手段を適切に利用していくための要素としての土台が「想像力」であると考えています。 課題（Issue）への取り組み例 番号 概要 ① Issue に取り組む際に「本当に解決すべきこと」についての想像を働かせます。Issue に記載されていることが 本当にプロダクトとして解決すべきことなのか を含めて考えます。これまでの運用が必ずしも正しいわけではない。という点がポイントです。 ② ① について「想像のまま」で終わらせてはいけないので、業務知識と照らし合わせて確度を高めていきます。常勤医師やカスタマーサポートにヒアリングしながら、 医療業務としてのあるべき形の解像度を上げていく プロセスです。 ③ ① 及び ② で高めた解像度は言葉の延長線上なので、関係者間の認識のギャップが発生しやすいです。プロトタイプを作成して、視覚・触感レベルでギャップを埋めていくことで、あるべき形に向けて洗練させていきます。 ④ ① 〜 ③ のタイミングを問わず、必要に応じて関係者と相談しながら進めていきます。エンジニアが立てた仮説をデザイナーの目線で評価・ UI/UX 最適化をして頂いたり、大きめの機能については、医療機関にパイロット運用のご協力を仰いだりすることもあります。 ① 及び ② の項に作業のウェイトが偏っているように見えるかと思います。実際、課題を解決する為の半分以上をここに割いています。 理由は「１度作って公開した機能」は、その後１人歩きをして作成者の意図しない方向で利用をされることがあるからです。 そして、利用者がその運用を定着させてしまうと 誤った機能においても「削ぎ落とすことが困難」 です。これは「使われていない機能」よりも直接的な負債といった形でボディブローのように効いてきます。 「どのような使われ方をするか」について想像すること その使われ方が、プロダクトの目指す世界と合っていること エンジニアは技術を形にする上で、常に想像力を働かせて取り組む必要がある。 というのが筆者の持論です。 さいごに 執筆の締めにあたって CTO ブログを見返してみると、大事なことはここに詰まっていました。筆者は前職の SIer 時代に読んだのですが、この記事にすごく共感したのを覚えています。 toppa.medley.jp toppa.medley.jp メドレーでは 医療ヘルスケアの未来を作る という大きな目標、そしてその未来を作る為に解決すべき課題に向かって、今回ご紹介したプロセスや考え方も含め試行錯誤しながら、事業部一丸でプロダクト開発を推進しています。 エンジニアの総合力を発揮して医療ヘルスケアの未来を一緒に作り上げていきたい！という方にお会い出来ることを楽しみにしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

初めまして。CLINICS の開発を担当しているエンジニアの平山です。 （同姓ですが CTO ではございません） CLINICS の開発は「スモールチーム制」をとっておりまして、現在そのうちの１つをチームリードしています。 前職は長らく SIer に勤めていました。去年の 12 月にメドレーに JOIN して、間も無く１年経とうとしている。。と思うと、あっという間だったなぁという印象です。 さて、本日はメドレーで隔週開催している社内勉強会（TechLunch）において発表した内容についてご紹介させて頂ければと思います。 はじめに 「技術を使うための技術」というテーマとなりますが、プロダクト開発をしていく上では欠かせない素養と考えています。メドレーに所属しているエンジニアの１人として、どのように日々課題と向き合っているのか。当テーマを通してお伝えできればと思います。 また、この考え方自体は「医療というテーマ」や「事業の背景（ベンチャー・ SIer）」を問わず必要とされる場面があるかもしれません。（自身も前職では様々な場面でお世話になりました…） 即効性のあるものではありませんが、じわじわ効いてくる内容ではないかと思います。よろしければお付き合いください。 本題 「技術を使うための技術」 みなさんはこの言葉から、何を思い浮かべるでしょうか。筆者が試しに Google で検索した際上位にヒットしたのは AI エンジニア IoT といった結果でした。なるほど。少し雑に解釈すると「技術（アルゴリズム等）を使うための技術（機械学習、家電等）」といった感じなのでしょうか。（この結果を拾ってきたというのも、いい意味で Google すごいなって感じました） 筆者が今回のテーマとして指しているのは、下記となります。 ロジカルシンキング 推論 これらの 思考を整理する「手段」 とエンジニアの武器である 技術という「手段」 をかけ合わせることで、大きなテーマである「医療」に向き合っています。 手段を目的にしてはならない 先に挙げたとおり「思考の整理」も「技術」も 「手段」 に過ぎません。これらを用いて、適切な一手を指していく為には「目的」に対する解像度を高く描く必要があります。 筆者の発表から抜粋した「技術を使うための技術」の要素をイメージした図 整理力 目的を達成する為に必要な「情報」を取捨選択するための要素。 SaaS ✖️ toB の世界においては「プロダクトが解決すべき課題か否かを業務の本質を踏まえて取捨選択する」と言い換えられるかもしれません。 業務知識 目的の「解像度」を高めるための要素。 CLINICS においては、医療情報を扱う上での規制（3 省 2 ガイドライン）や、医療機関（医師・医事・診療科の特性）の業務、診療報酬についての知識、法改正、レセコン（ORCA）… と様々あります。 技術知識 目的を達成する為に必要な「指し手」を選択するための要素。 （エンジニアにとっては説明するまでもない内容であると思いますが） ここが欠けてしまうと絵に描いた餅で終わってしまいます。メドレーのエンジニアにおいても日々研鑽し、プロダクトに対してコミットを続けています。 行動力 目的を達成するための「推進力」を高めるための要素。 各種知識と整理した情報を推進力に変えていく為には、その時の状況に応じた動きをする必要があります。ステークホルダーとの調整は当然ですが、組織内連携といった「横の動き」も必要です。 想像力 これまで挙げたそれぞれの手段を適切に利用していくための要素としての土台が「想像力」であると考えています。 課題（Issue）への取り組み例 番号 概要 ① Issue に取り組む際に「本当に解決すべきこと」についての想像を働かせます。Issue に記載されていることが 本当にプロダクトとして解決すべきことなのか を含めて考えます。これまでの運用が必ずしも正しいわけではない。という点がポイントです。 ② ① について「想像のまま」で終わらせてはいけないので、業務知識と照らし合わせて確度を高めていきます。常勤医師やカスタマーサポートにヒアリングしながら、 医療業務としてのあるべき形の解像度を上げていく プロセスです。 ③ ① 及び ② で高めた解像度は言葉の延長線上なので、関係者間の認識のギャップが発生しやすいです。プロトタイプを作成して、視覚・触感レベルでギャップを埋めていくことで、あるべき形に向けて洗練させていきます。 ④ ① 〜 ③ のタイミングを問わず、必要に応じて関係者と相談しながら進めていきます。エンジニアが立てた仮説をデザイナーの目線で評価・ UI/UX 最適化をして頂いたり、大きめの機能については、医療機関にパイロット運用のご協力を仰いだりすることもあります。 ① 及び ② の項に作業のウェイトが偏っているように見えるかと思います。実際、課題を解決する為の半分以上をここに割いています。 理由は「１度作って公開した機能」は、その後１人歩きをして作成者の意図しない方向で利用をされることがあるからです。 そして、利用者がその運用を定着させてしまうと 誤った機能においても「削ぎ落とすことが困難」 です。これは「使われていない機能」よりも直接的な負債といった形でボディブローのように効いてきます。 「どのような使われ方をするか」について想像すること その使われ方が、プロダクトの目指す世界と合っていること エンジニアは技術を形にする上で、常に想像力を働かせて取り組む必要がある。 というのが筆者の持論です。 さいごに 執筆の締めにあたって CTO ブログを見返してみると、大事なことはここに詰まっていました。筆者は前職の SIer 時代に読んだのですが、この記事にすごく共感したのを覚えています。 toppa.medley.jp toppa.medley.jp メドレーでは 医療ヘルスケアの未来を作る という大きな目標、そしてその未来を作る為に解決すべき課題に向かって、今回ご紹介したプロセスや考え方も含め試行錯誤しながら、事業部一丸でプロダクト開発を推進しています。 エンジニアの総合力を発揮して医療ヘルスケアの未来を一緒に作り上げていきたい！という方にお会い出来ることを楽しみにしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

初めまして。CLINICS の開発を担当しているエンジニアの平山です。 （同姓ですが CTO ではございません） CLINICS の開発は「スモールチーム制」をとっておりまして、現在そのうちの１つをチームリードしています。 前職は長らく SIer に勤めていました。去年の 12 月にメドレーに JOIN して、間も無く１年経とうとしている。。と思うと、あっという間だったなぁという印象です。 さて、本日はメドレーで隔週開催している社内勉強会（TechLunch）において発表した内容についてご紹介させて頂ければと思います。 はじめに 「技術を使うための技術」というテーマとなりますが、プロダクト開発をしていく上では欠かせない素養と考えています。メドレーに所属しているエンジニアの１人として、どのように日々課題と向き合っているのか。当テーマを通してお伝えできればと思います。 また、この考え方自体は「医療というテーマ」や「事業の背景（ベンチャー・ SIer）」を問わず必要とされる場面があるかもしれません。（自身も前職では様々な場面でお世話になりました…） 即効性のあるものではありませんが、じわじわ効いてくる内容ではないかと思います。よろしければお付き合いください。 本題 「技術を使うための技術」 みなさんはこの言葉から、何を思い浮かべるでしょうか。筆者が試しに Google で検索した際上位にヒットしたのは AI エンジニア IoT といった結果でした。なるほど。少し雑に解釈すると「技術（アルゴリズム等）を使うための技術（機械学習、家電等）」といった感じなのでしょうか。（この結果を拾ってきたというのも、いい意味で Google すごいなって感じました） 筆者が今回のテーマとして指しているのは、下記となります。 ロジカルシンキング 推論 これらの 思考を整理する「手段」 とエンジニアの武器である 技術という「手段」 をかけ合わせることで、大きなテーマである「医療」に向き合っています。 手段を目的にしてはならない 先に挙げたとおり「思考の整理」も「技術」も 「手段」 に過ぎません。これらを用いて、適切な一手を指していく為には「目的」に対する解像度を高く描く必要があります。 筆者の発表から抜粋した「技術を使うための技術」の要素をイメージした図 整理力 目的を達成する為に必要な「情報」を取捨選択するための要素。 SaaS ✖️ toB の世界においては「プロダクトが解決すべき課題か否かを業務の本質を踏まえて取捨選択する」と言い換えられるかもしれません。 業務知識 目的の「解像度」を高めるための要素。 CLINICS においては、医療情報を扱う上での規制（3 省 2 ガイドライン）や、医療機関（医師・医事・診療科の特性）の業務、診療報酬についての知識、法改正、レセコン（ORCA）… と様々あります。 技術知識 目的を達成する為に必要な「指し手」を選択するための要素。 （エンジニアにとっては説明するまでもない内容であると思いますが） ここが欠けてしまうと絵に描いた餅で終わってしまいます。メドレーのエンジニアにおいても日々研鑽し、プロダクトに対してコミットを続けています。 行動力 目的を達成するための「推進力」を高めるための要素。 各種知識と整理した情報を推進力に変えていく為には、その時の状況に応じた動きをする必要があります。ステークホルダーとの調整は当然ですが、組織内連携といった「横の動き」も必要です。 想像力 これまで挙げたそれぞれの手段を適切に利用していくための要素としての土台が「想像力」であると考えています。 課題（Issue）への取り組み例 番号 概要 ① Issue に取り組む際に「本当に解決すべきこと」についての想像を働かせます。Issue に記載されていることが 本当にプロダクトとして解決すべきことなのか を含めて考えます。これまでの運用が必ずしも正しいわけではない。という点がポイントです。 ② ① について「想像のまま」で終わらせてはいけないので、業務知識と照らし合わせて確度を高めていきます。常勤医師やカスタマーサポートにヒアリングしながら、 医療業務としてのあるべき形の解像度を上げていく プロセスです。 ③ ① 及び ② で高めた解像度は言葉の延長線上なので、関係者間の認識のギャップが発生しやすいです。プロトタイプを作成して、視覚・触感レベルでギャップを埋めていくことで、あるべき形に向けて洗練させていきます。 ④ ① 〜 ③ のタイミングを問わず、必要に応じて関係者と相談しながら進めていきます。エンジニアが立てた仮説をデザイナーの目線で評価・ UI/UX 最適化をして頂いたり、大きめの機能については、医療機関にパイロット運用のご協力を仰いだりすることもあります。 ① 及び ② の項に作業のウェイトが偏っているように見えるかと思います。実際、課題を解決する為の半分以上をここに割いています。 理由は「１度作って公開した機能」は、その後１人歩きをして作成者の意図しない方向で利用をされることがあるからです。 そして、利用者がその運用を定着させてしまうと 誤った機能においても「削ぎ落とすことが困難」 です。これは「使われていない機能」よりも直接的な負債といった形でボディブローのように効いてきます。 「どのような使われ方をするか」について想像すること その使われ方が、プロダクトの目指す世界と合っていること エンジニアは技術を形にする上で、常に想像力を働かせて取り組む必要がある。 というのが筆者の持論です。 さいごに 執筆の締めにあたって CTO ブログを見返してみると、大事なことはここに詰まっていました。筆者は前職の SIer 時代に読んだのですが、この記事にすごく共感したのを覚えています。 toppa.medley.jp toppa.medley.jp メドレーでは 医療ヘルスケアの未来を作る という大きな目標、そしてその未来を作る為に解決すべき課題に向かって、今回ご紹介したプロセスや考え方も含め試行錯誤しながら、事業部一丸でプロダクト開発を推進しています。 エンジニアの総合力を発揮して医療ヘルスケアの未来を一緒に作り上げていきたい！という方にお会い出来ることを楽しみにしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

初めまして。CLINICS の開発を担当しているエンジニアの平山です。 （同姓ですが CTO ではございません） CLINICS の開発は「スモールチーム制」をとっておりまして、現在そのうちの１つをチームリードしています。 前職は長らく SIer に勤めていました。去年の 12 月にメドレーに JOIN して、間も無く１年経とうとしている。。と思うと、あっという間だったなぁという印象です。 さて、本日はメドレーで隔週開催している社内勉強会（TechLunch）において発表した内容についてご紹介させて頂ければと思います。 はじめに 「技術を使うための技術」というテーマとなりますが、プロダクト開発をしていく上では欠かせない素養と考えています。メドレーに所属しているエンジニアの１人として、どのように日々課題と向き合っているのか。当テーマを通してお伝えできればと思います。 また、この考え方自体は「医療というテーマ」や「事業の背景（ベンチャー・ SIer）」を問わず必要とされる場面があるかもしれません。（自身も前職では様々な場面でお世話になりました…） 即効性のあるものではありませんが、じわじわ効いてくる内容ではないかと思います。よろしければお付き合いください。 本題 「技術を使うための技術」 みなさんはこの言葉から、何を思い浮かべるでしょうか。筆者が試しに Google で検索した際上位にヒットしたのは AI エンジニア IoT といった結果でした。なるほど。少し雑に解釈すると「技術（アルゴリズム等）を使うための技術（機械学習、家電等）」といった感じなのでしょうか。（この結果を拾ってきたというのも、いい意味で Google すごいなって感じました） 筆者が今回のテーマとして指しているのは、下記となります。 ロジカルシンキング 推論 これらの 思考を整理する「手段」 とエンジニアの武器である 技術という「手段」 をかけ合わせることで、大きなテーマである「医療」に向き合っています。 手段を目的にしてはならない 先に挙げたとおり「思考の整理」も「技術」も 「手段」 に過ぎません。これらを用いて、適切な一手を指していく為には「目的」に対する解像度を高く描く必要があります。 筆者の発表から抜粋した「技術を使うための技術」の要素をイメージした図 整理力 目的を達成する為に必要な「情報」を取捨選択するための要素。 SaaS ✖️ toB の世界においては「プロダクトが解決すべき課題か否かを業務の本質を踏まえて取捨選択する」と言い換えられるかもしれません。 業務知識 目的の「解像度」を高めるための要素。 CLINICS においては、医療情報を扱う上での規制（3 省 2 ガイドライン）や、医療機関（医師・医事・診療科の特性）の業務、診療報酬についての知識、法改正、レセコン（ORCA）… と様々あります。 技術知識 目的を達成する為に必要な「指し手」を選択するための要素。 （エンジニアにとっては説明するまでもない内容であると思いますが） ここが欠けてしまうと絵に描いた餅で終わってしまいます。メドレーのエンジニアにおいても日々研鑽し、プロダクトに対してコミットを続けています。 行動力 目的を達成するための「推進力」を高めるための要素。 各種知識と整理した情報を推進力に変えていく為には、その時の状況に応じた動きをする必要があります。ステークホルダーとの調整は当然ですが、組織内連携といった「横の動き」も必要です。 想像力 これまで挙げたそれぞれの手段を適切に利用していくための要素としての土台が「想像力」であると考えています。 課題（Issue）への取り組み例 番号 概要 ① Issue に取り組む際に「本当に解決すべきこと」についての想像を働かせます。Issue に記載されていることが 本当にプロダクトとして解決すべきことなのか を含めて考えます。これまでの運用が必ずしも正しいわけではない。という点がポイントです。 ② ① について「想像のまま」で終わらせてはいけないので、業務知識と照らし合わせて確度を高めていきます。常勤医師やカスタマーサポートにヒアリングしながら、 医療業務としてのあるべき形の解像度を上げていく プロセスです。 ③ ① 及び ② で高めた解像度は言葉の延長線上なので、関係者間の認識のギャップが発生しやすいです。プロトタイプを作成して、視覚・触感レベルでギャップを埋めていくことで、あるべき形に向けて洗練させていきます。 ④ ① 〜 ③ のタイミングを問わず、必要に応じて関係者と相談しながら進めていきます。エンジニアが立てた仮説をデザイナーの目線で評価・ UI/UX 最適化をして頂いたり、大きめの機能については、医療機関にパイロット運用のご協力を仰いだりすることもあります。 ① 及び ② の項に作業のウェイトが偏っているように見えるかと思います。実際、課題を解決する為の半分以上をここに割いています。 理由は「１度作って公開した機能」は、その後１人歩きをして作成者の意図しない方向で利用をされることがあるからです。 そして、利用者がその運用を定着させてしまうと 誤った機能においても「削ぎ落とすことが困難」 です。これは「使われていない機能」よりも直接的な負債といった形でボディブローのように効いてきます。 「どのような使われ方をするか」について想像すること その使われ方が、プロダクトの目指す世界と合っていること エンジニアは技術を形にする上で、常に想像力を働かせて取り組む必要がある。 というのが筆者の持論です。 さいごに 執筆の締めにあたって CTO ブログを見返してみると、大事なことはここに詰まっていました。筆者は前職の SIer 時代に読んだのですが、この記事にすごく共感したのを覚えています。 https://toppa.medley.jp/02.html メドレーでは 医療ヘルスケアの未来を作る という大きな目標、そしてその未来を作る為に解決すべき課題に向かって、今回ご紹介したプロセスや考え方も含め試行錯誤しながら、事業部一丸でプロダクト開発を推進しています。 エンジニアの総合力を発揮して医療ヘルスケアの未来を一緒に作り上げていきたい！という方にお会い出来ることを楽しみにしております。 https://www.medley.jp/jobs/

こんにちは、第二開発グループエンジニアの西村です。主に CLINICS の開発を担当しています。 はじめに CLINICS は電子カルテ、オンライン診療、予約システム、患者アプリなどを含む統合アプリです。CLINICS がローンチしてから現在に至るまで常に新機能開発と定常改善が行われており、開発環境のメンテナンスは後手になりがちでした。今回はそういった状況を改善すべく、開発環境のメンテナンス、リファクタリングを行った過程から得られたプラクティスについて紹介していこうと思います。 モチベーション プロダクトの新規開発時に行われる技術選定は非常に難しく、業務要件やチーム状況など総合的に考慮してその時点でのベストな選択をする必要があります。 しかし、選択した技術で長期運用をしていくうちに、メンテナンスが行き届かなくなったコードやライブラリが出てしまいます。 CLINICS ローンチ当初はオンライン診療のみを提供していました。SPA で構成されていましたが、１つの package.json で効率的に開発できていました。他に、現在ほど TypeScript が主流ではなかったので JavaScript のコードがメインで実装されてました。 新たなアプリケーション（電子カルテや予約システムなど）を導入するタイミング、すなわちプロダクトが小規模から中規模に変遷するタイミングや、フロントエンドの時流によって、開発環境を改善できた部分もありますが、しきれていない部分も出てきました。 その改善しきれていない部分を残す状態が続くと Developer Experience(DX)の低下に繋がってしまいます。ですので、私たちは改善しきれていない部分を取り除いていき、よりモダンとされる開発環境へリファクタリングをしていこうと考えました。 DX を向上していくことで技術的なノイズに時間を取られないようになります。そして提供する機能そのものについて考える時間が増え、結果的に CLINICS をより良いプロダクトへ進化させていくのが当リファクタリングの目的です。 課題整理 改善していくためには、現状整理、課題整理を行わないことには何も始まりません。フロントエンド開発環境をメンテナンスするタスクは、プロダクトの機能（ユーザに提供される機能）に直接プラスの影響があるわけではありません。自ずと通常の機能開発や定常改善に比べ優先度は落ちるため、スキマ時間で改善をしていくことになります。こうしたスキマ時間を有効活用するためには、タスクの難易度の理解、タスクを適当に分割、フェージングの計画を行うことが極めて大事です。 そのように考慮した課題の中で、本記事で記載するのは以下の２つです。 ライブラリを定期的にアップデートする運用が固まってない 運用方式が固まっていないことで、放置されてしまいがちです。率先してアップデートするメンバーがいたとしても、属人化の課題が残ってしまいます 放置されてしまったことにより、最新版との差分が大きくなりアップデートするコストも大きくなってしまいます 結果的に、ライブラリのセキュリティフィックス対応や新しく提供された機能をすぐに適応できない環境になってしまいます 複数の SPA の依存を１つの package.json で管理している 電子カルテ・オンライン診療、社内管理 Web アプリ、患者 Web アプリはそれぞれ別の SPA として作られています それらを１つの package.json で管理しているためそれぞれの SPA が同じ依存パッケージを使わなくてはなりません。小規模のときはこのような構成で十分でしたが、規模が大きくなるにつれて柔軟性が失われると共に、ライブラリのアップデートがもたらす影響範囲が広がってしまうため、容易にアップデートできなくなってしまいます 本記事では記載しませんが「Redux の書き方が混在している」「フロントエンドのテストが少ない」「網羅的に TypeScript 化できていなく JavaScript がまだ残っている」などの課題も挙げられました。 こういう課題は、どのプロダクトにも存在すると思います。それはローンチ当時の技術流行であったり、プロダクトの期待規模、少数メンバに適した設計など要因は様々あり、プログラムのリファクタリングと同様に プロダクトの成長に伴ってリファクタリングしていくことが正 だと信じています。 モチベーションにて記載した通り、これら複数の課題は開発環境のノイズであり、除去することによって、より良い DX が得られると考えています。他にこのようなリファクタリングを行うことによって、プロダクトをより堅牢にできるという側面もあります。 上記の２つの課題に対してそれぞれ「ライブラリを定期的にアップデートする運用手段を設けた」「package.json を SPA 単位に分割した」話をこれからしていきます。 フロントエンド開発環境のリファクタリング ライブラリの定期的なアップデートをする運用手順を設けた 手動アップデート ライブラリをアップデートするにはコマンドを叩くだけだと考えていましたが、依存している別のライブラリに影響が本当にないかなど調査する必要があると知り、ライブラリのアップデート方法を模索するところから開始しました。 ライブラリではないですが、Node.js のアップデートをしようとすると、node-sass や Firebase が影響していたりして、芋づる式で根っこにあるライブラリのアップデートをする必要が出てきたりするので、一つ一つ問題がないか調査するのが大変でした。 何より、アップデート対象ライブラリのリリースノートに Breaking Changes が書かれていなかったり、semver が守られているかわからなかったりと、プロダクトに影響がないか調べる必要があり、問題の切り分け方が難しかったのです。 ここで得られたライブラリアップデートの安全性担保のプラクティスとして webpack によるビルド結果が変わらないケース と、 QA テストによって担保するケース があることがわかりました。前者は webpack による成果物が変わらないのであれば今回のアップデートが安全であるといえ、後者はエンジニアと QA エンジニアによってライブラリの影響範囲にハレーションがないことを確かめて安全であるといえるというものです。 renovate の運用開始 数カ月間は上記のようにライブラリのアップデートを手動で行っていましたが、確認工数が増えてしまい、他のタスクの時間を圧迫してしまうほどでした。 そこで、アップデートを自動化する renovate  と dependabot を視野に入れました。renovate は、dependabot に比べて高機能でかつ、無料であるという理由で選定しました。 運用当初、renovate が Pull Request を作成してくれたり、diff によりライブラリの変更点が見やすかったりと、恩恵を感じていました。しかし、徐々に「アップデート対象が多く、それぞれがどういうライブラリで、影響範囲がどこなのか」ということの調査に時間が取られるようになってしまいました。 ここで得られた調査時間を短縮するプラクティスとして**「本番影響のあるもの」「開発向け」「ビルド周り」と renovate から来る Pull Request を整理する**ことです。このような整理を行うことで、本番影響のあるものに注力してレビューできるようになり、苦にならずにアップデートをできるようになりました。 結果 ライブラリアップデートの運用手順を設けることによって、今まで以上に堅牢な環境になりました。それから、renovate によって自動的に重要な（本番影響のある）ライブラリのみに集中してレビューを行うことによって、少ない工数でアップデートしていけるようになりました。 package.json を SPA 単位に分割 課題整理で記載した通り、電子カルテ・オンライン診療、社内管理 Web アプリ、患者 Web アプリはそれぞれ別の SPA として作られていますが、１つの package.json で管理しています。ですのでそれぞれの SPA が同じ依存パッケージを使わなければなりません。 弊害として package.json に対して１つの変更があったときにすべての SPA に影響が出てしまいます。ですので、この肥大化した package.json をそれぞれの SPA に分割しようとしました。 package.json を SPA 単位に分割することは 責務分離 という側面もあり、ライブラリだけでなく、共通していた定数、ロジック、コンポーネント、webpack.config.js、babel.config.js と tsconfig.json などすべてをそれぞれの SPA に依存のない形に閉じるようにしました。これらの分割する作業は非常に泥臭いもので、本記事に記載するほどのものではありませんが、得られた結果について記載していこうと思います。 結果 まず、責務分離ができたので、１つの SPA に対する変更があったときに、他の全ての SPA に対する影響が出なくなりました。よって、１つの SPA に対して新たな Web フレームワークやライブラリを試すことが容易になりました。他にも、１つの webpack ですべての SPA をシーケンシャルにビルドしていたのに対して、現在はパラレルでビルドできるようになりビルド時間が短縮されたため、今まで以上にコミットからデプロイまでのイテレーションが小さくなりました。 これらの結果からフロント開発環境の改善および DX 向上が果されました。 今後の課題 持続的なリファクタリングをする仕組み作り 「ライブラリの定期的なアップデートをする運用手順を設けた」はまさに持続的にライブラリをアップデートするための手段です。「package.json を SPA 単位に分割する」もそれぞれの SPA をメンテナンスしやすい環境作りとしては欠かせない作業でした。 しかし、このままリファクタリングを中断すれば、プロダクトの規模が大きくなるときやフロントエンドの時流によって再びメンテナンスしづらい環境になってしまいます。 なので、持続的なリファクタリングをするためには仕組み作りが欠かせないと考えています。そのためには、属人化によらない仕組みづくり、メンテナンスしやすい環境改善、エンジニアそれぞれのフロントエンド開発環境に対するリテラシを高める取り組みを行っていく必要があります。そのため、現在 横軸勉強会 などで CLINICS フロントエンドの実装背景や、リファクタリングしやすい書き方などのナレッジを共有しています。 まとめ フロントエンド開発環境のメンテナンス・リファクタリング自体はあくまでもユーザに新しい機能を提供しているわけではなく、粛々と行っていくものです。しかし、課題を洗い出し、向き合って、解決していったことによって得られたプラクティスは多くあり、フロントエンドのエコシステムに対する理解も多く得られました。 これらのリファクタリングを行うことによって DX が向上していき、技術的なノイズに悩む時間が減り、エンジニアはよりプロダクトの機能開発に専念できるようになっていると信じています。 今回私たちが課題を解決したことによって、持続的にリファクタリングをしやすい土台作りをしたという側面もあると思います。今後の課題として、この土台を基にそれぞれのエンジニアが意識を持ってメンテナンスできるような仕組みづくりも行っていきたいと思います。 最後まで読んでいただきありがとうございました。 www.medley.jp

こんにちは、第二開発グループエンジニアの西村です。主に CLINICS の開発を担当しています。 はじめに CLINICS は電子カルテ、オンライン診療、予約システム、患者アプリなどを含む統合アプリです。CLINICS がローンチしてから現在に至るまで常に新機能開発と定常改善が行われており、開発環境のメンテナンスは後手になりがちでした。今回はそういった状況を改善すべく、開発環境のメンテナンス、リファクタリングを行った過程から得られたプラクティスについて紹介していこうと思います。 モチベーション プロダクトの新規開発時に行われる技術選定は非常に難しく、業務要件やチーム状況など総合的に考慮してその時点でのベストな選択をする必要があります。 しかし、選択した技術で長期運用をしていくうちに、メンテナンスが行き届かなくなったコードやライブラリが出てしまいます。 CLINICS ローンチ当初はオンライン診療のみを提供していました。SPA で構成されていましたが、１つの package.json で効率的に開発できていました。他に、現在ほど TypeScript が主流ではなかったので JavaScript のコードがメインで実装されてました。 新たなアプリケーション（電子カルテや予約システムなど）を導入するタイミング、すなわちプロダクトが小規模から中規模に変遷するタイミングや、フロントエンドの時流によって、開発環境を改善できた部分もありますが、しきれていない部分も出てきました。 その改善しきれていない部分を残す状態が続くと Developer Experience(DX)の低下に繋がってしまいます。ですので、私たちは改善しきれていない部分を取り除いていき、よりモダンとされる開発環境へリファクタリングをしていこうと考えました。 DX を向上していくことで技術的なノイズに時間を取られないようになります。そして提供する機能そのものについて考える時間が増え、結果的に CLINICS をより良いプロダクトへ進化させていくのが当リファクタリングの目的です。 課題整理 改善していくためには、現状整理、課題整理を行わないことには何も始まりません。フロントエンド開発環境をメンテナンスするタスクは、プロダクトの機能（ユーザに提供される機能）に直接プラスの影響があるわけではありません。自ずと通常の機能開発や定常改善に比べ優先度は落ちるため、スキマ時間で改善をしていくことになります。こうしたスキマ時間を有効活用するためには、タスクの難易度の理解、タスクを適当に分割、フェージングの計画を行うことが極めて大事です。 そのように考慮した課題の中で、本記事で記載するのは以下の２つです。 ライブラリを定期的にアップデートする運用が固まってない 運用方式が固まっていないことで、放置されてしまいがちです。率先してアップデートするメンバーがいたとしても、属人化の課題が残ってしまいます 放置されてしまったことにより、最新版との差分が大きくなりアップデートするコストも大きくなってしまいます 結果的に、ライブラリのセキュリティフィックス対応や新しく提供された機能をすぐに適応できない環境になってしまいます 複数の SPA の依存を１つの package.json で管理している 電子カルテ・オンライン診療、社内管理 Web アプリ、患者 Web アプリはそれぞれ別の SPA として作られています それらを１つの package.json で管理しているためそれぞれの SPA が同じ依存パッケージを使わなくてはなりません。小規模のときはこのような構成で十分でしたが、規模が大きくなるにつれて柔軟性が失われると共に、ライブラリのアップデートがもたらす影響範囲が広がってしまうため、容易にアップデートできなくなってしまいます 本記事では記載しませんが「Redux の書き方が混在している」「フロントエンドのテストが少ない」「網羅的に TypeScript 化できていなく JavaScript がまだ残っている」などの課題も挙げられました。 こういう課題は、どのプロダクトにも存在すると思います。それはローンチ当時の技術流行であったり、プロダクトの期待規模、少数メンバに適した設計など要因は様々あり、プログラムのリファクタリングと同様に プロダクトの成長に伴ってリファクタリングしていくことが正 だと信じています。 モチベーションにて記載した通り、これら複数の課題は開発環境のノイズであり、除去することによって、より良い DX が得られると考えています。他にこのようなリファクタリングを行うことによって、プロダクトをより堅牢にできるという側面もあります。 上記の２つの課題に対してそれぞれ「ライブラリを定期的にアップデートする運用手段を設けた」「package.json を SPA 単位に分割した」話をこれからしていきます。 フロントエンド開発環境のリファクタリング ライブラリの定期的なアップデートをする運用手順を設けた 手動アップデート ライブラリをアップデートするにはコマンドを叩くだけだと考えていましたが、依存している別のライブラリに影響が本当にないかなど調査する必要があると知り、ライブラリのアップデート方法を模索するところから開始しました。 ライブラリではないですが、Node.js のアップデートをしようとすると、node-sass や Firebase が影響していたりして、芋づる式で根っこにあるライブラリのアップデートをする必要が出てきたりするので、一つ一つ問題がないか調査するのが大変でした。 何より、アップデート対象ライブラリのリリースノートに Breaking Changes が書かれていなかったり、semver が守られているかわからなかったりと、プロダクトに影響がないか調べる必要があり、問題の切り分け方が難しかったのです。 ここで得られたライブラリアップデートの安全性担保のプラクティスとして webpack によるビルド結果が変わらないケース と、 QA テストによって担保するケース があることがわかりました。前者は webpack による成果物が変わらないのであれば今回のアップデートが安全であるといえ、後者はエンジニアと QA エンジニアによってライブラリの影響範囲にハレーションがないことを確かめて安全であるといえるというものです。 renovate の運用開始 数カ月間は上記のようにライブラリのアップデートを手動で行っていましたが、確認工数が増えてしまい、他のタスクの時間を圧迫してしまうほどでした。 そこで、アップデートを自動化する renovate  と dependabot を視野に入れました。renovate は、dependabot に比べて高機能でかつ、無料であるという理由で選定しました。 運用当初、renovate が Pull Request を作成してくれたり、diff によりライブラリの変更点が見やすかったりと、恩恵を感じていました。しかし、徐々に「アップデート対象が多く、それぞれがどういうライブラリで、影響範囲がどこなのか」ということの調査に時間が取られるようになってしまいました。 ここで得られた調査時間を短縮するプラクティスとして**「本番影響のあるもの」「開発向け」「ビルド周り」と renovate から来る Pull Request を整理する**ことです。このような整理を行うことで、本番影響のあるものに注力してレビューできるようになり、苦にならずにアップデートをできるようになりました。 結果 ライブラリアップデートの運用手順を設けることによって、今まで以上に堅牢な環境になりました。それから、renovate によって自動的に重要な（本番影響のある）ライブラリのみに集中してレビューを行うことによって、少ない工数でアップデートしていけるようになりました。 package.json を SPA 単位に分割 課題整理で記載した通り、電子カルテ・オンライン診療、社内管理 Web アプリ、患者 Web アプリはそれぞれ別の SPA として作られていますが、１つの package.json で管理しています。ですのでそれぞれの SPA が同じ依存パッケージを使わなければなりません。 弊害として package.json に対して１つの変更があったときにすべての SPA に影響が出てしまいます。ですので、この肥大化した package.json をそれぞれの SPA に分割しようとしました。 package.json を SPA 単位に分割することは 責務分離 という側面もあり、ライブラリだけでなく、共通していた定数、ロジック、コンポーネント、webpack.config.js、babel.config.js と tsconfig.json などすべてをそれぞれの SPA に依存のない形に閉じるようにしました。これらの分割する作業は非常に泥臭いもので、本記事に記載するほどのものではありませんが、得られた結果について記載していこうと思います。 結果 まず、責務分離ができたので、１つの SPA に対する変更があったときに、他の全ての SPA に対する影響が出なくなりました。よって、１つの SPA に対して新たな Web フレームワークやライブラリを試すことが容易になりました。他にも、１つの webpack ですべての SPA をシーケンシャルにビルドしていたのに対して、現在はパラレルでビルドできるようになりビルド時間が短縮されたため、今まで以上にコミットからデプロイまでのイテレーションが小さくなりました。 これらの結果からフロント開発環境の改善および DX 向上が果されました。 今後の課題 持続的なリファクタリングをする仕組み作り 「ライブラリの定期的なアップデートをする運用手順を設けた」はまさに持続的にライブラリをアップデートするための手段です。「package.json を SPA 単位に分割する」もそれぞれの SPA をメンテナンスしやすい環境作りとしては欠かせない作業でした。 しかし、このままリファクタリングを中断すれば、プロダクトの規模が大きくなるときやフロントエンドの時流によって再びメンテナンスしづらい環境になってしまいます。 なので、持続的なリファクタリングをするためには仕組み作りが欠かせないと考えています。そのためには、属人化によらない仕組みづくり、メンテナンスしやすい環境改善、エンジニアそれぞれのフロントエンド開発環境に対するリテラシを高める取り組みを行っていく必要があります。そのため、現在 横軸勉強会 などで CLINICS フロントエンドの実装背景や、リファクタリングしやすい書き方などのナレッジを共有しています。 まとめ フロントエンド開発環境のメンテナンス・リファクタリング自体はあくまでもユーザに新しい機能を提供しているわけではなく、粛々と行っていくものです。しかし、課題を洗い出し、向き合って、解決していったことによって得られたプラクティスは多くあり、フロントエンドのエコシステムに対する理解も多く得られました。 これらのリファクタリングを行うことによって DX が向上していき、技術的なノイズに悩む時間が減り、エンジニアはよりプロダクトの機能開発に専念できるようになっていると信じています。 今回私たちが課題を解決したことによって、持続的にリファクタリングをしやすい土台作りをしたという側面もあると思います。今後の課題として、この土台を基にそれぞれのエンジニアが意識を持ってメンテナンスできるような仕組みづくりも行っていきたいと思います。 最後まで読んでいただきありがとうございました。 www.medley.jp

こんにちは、第二開発グループエンジニアの西村です。主に CLINICS の開発を担当しています。 はじめに CLINICS は電子カルテ、オンライン診療、予約システム、患者アプリなどを含む統合アプリです。CLINICS がローンチしてから現在に至るまで常に新機能開発と定常改善が行われており、開発環境のメンテナンスは後手になりがちでした。今回はそういった状況を改善すべく、開発環境のメンテナンス、リファクタリングを行った過程から得られたプラクティスについて紹介していこうと思います。 モチベーション プロダクトの新規開発時に行われる技術選定は非常に難しく、業務要件やチーム状況など総合的に考慮してその時点でのベストな選択をする必要があります。 しかし、選択した技術で長期運用をしていくうちに、メンテナンスが行き届かなくなったコードやライブラリが出てしまいます。 CLINICS ローンチ当初はオンライン診療のみを提供していました。SPA で構成されていましたが、１つの package.json で効率的に開発できていました。他に、現在ほど TypeScript が主流ではなかったので JavaScript のコードがメインで実装されてました。 新たなアプリケーション（電子カルテや予約システムなど）を導入するタイミング、すなわちプロダクトが小規模から中規模に変遷するタイミングや、フロントエンドの時流によって、開発環境を改善できた部分もありますが、しきれていない部分も出てきました。 その改善しきれていない部分を残す状態が続くと Developer Experience(DX)の低下に繋がってしまいます。ですので、私たちは改善しきれていない部分を取り除いていき、よりモダンとされる開発環境へリファクタリングをしていこうと考えました。 DX を向上していくことで技術的なノイズに時間を取られないようになります。そして提供する機能そのものについて考える時間が増え、結果的に CLINICS をより良いプロダクトへ進化させていくのが当リファクタリングの目的です。 課題整理 改善していくためには、現状整理、課題整理を行わないことには何も始まりません。フロントエンド開発環境をメンテナンスするタスクは、プロダクトの機能（ユーザに提供される機能）に直接プラスの影響があるわけではありません。自ずと通常の機能開発や定常改善に比べ優先度は落ちるため、スキマ時間で改善をしていくことになります。こうしたスキマ時間を有効活用するためには、タスクの難易度の理解、タスクを適当に分割、フェージングの計画を行うことが極めて大事です。 そのように考慮した課題の中で、本記事で記載するのは以下の２つです。 ライブラリを定期的にアップデートする運用が固まってない 運用方式が固まっていないことで、放置されてしまいがちです。率先してアップデートするメンバーがいたとしても、属人化の課題が残ってしまいます 放置されてしまったことにより、最新版との差分が大きくなりアップデートするコストも大きくなってしまいます 結果的に、ライブラリのセキュリティフィックス対応や新しく提供された機能をすぐに適応できない環境になってしまいます 複数の SPA の依存を１つの package.json で管理している 電子カルテ・オンライン診療、社内管理 Web アプリ、患者 Web アプリはそれぞれ別の SPA として作られています それらを１つの package.json で管理しているためそれぞれの SPA が同じ依存パッケージを使わなくてはなりません。小規模のときはこのような構成で十分でしたが、規模が大きくなるにつれて柔軟性が失われると共に、ライブラリのアップデートがもたらす影響範囲が広がってしまうため、容易にアップデートできなくなってしまいます 本記事では記載しませんが「Redux の書き方が混在している」「フロントエンドのテストが少ない」「網羅的に TypeScript 化できていなく JavaScript がまだ残っている」などの課題も挙げられました。 こういう課題は、どのプロダクトにも存在すると思います。それはローンチ当時の技術流行であったり、プロダクトの期待規模、少数メンバに適した設計など要因は様々あり、プログラムのリファクタリングと同様に プロダクトの成長に伴ってリファクタリングしていくことが正 だと信じています。 モチベーションにて記載した通り、これら複数の課題は開発環境のノイズであり、除去することによって、より良い DX が得られると考えています。他にこのようなリファクタリングを行うことによって、プロダクトをより堅牢にできるという側面もあります。 上記の２つの課題に対してそれぞれ「ライブラリを定期的にアップデートする運用手段を設けた」「package.json を SPA 単位に分割した」話をこれからしていきます。 フロントエンド開発環境のリファクタリング ライブラリの定期的なアップデートをする運用手順を設けた 手動アップデート ライブラリをアップデートするにはコマンドを叩くだけだと考えていましたが、依存している別のライブラリに影響が本当にないかなど調査する必要があると知り、ライブラリのアップデート方法を模索するところから開始しました。 ライブラリではないですが、Node.js のアップデートをしようとすると、node-sass や Firebase が影響していたりして、芋づる式で根っこにあるライブラリのアップデートをする必要が出てきたりするので、一つ一つ問題がないか調査するのが大変でした。 何より、アップデート対象ライブラリのリリースノートに Breaking Changes が書かれていなかったり、semver が守られているかわからなかったりと、プロダクトに影響がないか調べる必要があり、問題の切り分け方が難しかったのです。 ここで得られたライブラリアップデートの安全性担保のプラクティスとして webpack によるビルド結果が変わらないケース と、 QA テストによって担保するケース があることがわかりました。前者は webpack による成果物が変わらないのであれば今回のアップデートが安全であるといえ、後者はエンジニアと QA エンジニアによってライブラリの影響範囲にハレーションがないことを確かめて安全であるといえるというものです。 renovate の運用開始 数カ月間は上記のようにライブラリのアップデートを手動で行っていましたが、確認工数が増えてしまい、他のタスクの時間を圧迫してしまうほどでした。 そこで、アップデートを自動化する renovate  と dependabot を視野に入れました。renovate は、dependabot に比べて高機能でかつ、無料であるという理由で選定しました。 運用当初、renovate が Pull Request を作成してくれたり、diff によりライブラリの変更点が見やすかったりと、恩恵を感じていました。しかし、徐々に「アップデート対象が多く、それぞれがどういうライブラリで、影響範囲がどこなのか」ということの調査に時間が取られるようになってしまいました。 ここで得られた調査時間を短縮するプラクティスとして**「本番影響のあるもの」「開発向け」「ビルド周り」と renovate から来る Pull Request を整理する**ことです。このような整理を行うことで、本番影響のあるものに注力してレビューできるようになり、苦にならずにアップデートをできるようになりました。 結果 ライブラリアップデートの運用手順を設けることによって、今まで以上に堅牢な環境になりました。それから、renovate によって自動的に重要な（本番影響のある）ライブラリのみに集中してレビューを行うことによって、少ない工数でアップデートしていけるようになりました。 package.json を SPA 単位に分割 課題整理で記載した通り、電子カルテ・オンライン診療、社内管理 Web アプリ、患者 Web アプリはそれぞれ別の SPA として作られていますが、１つの package.json で管理しています。ですのでそれぞれの SPA が同じ依存パッケージを使わなければなりません。 弊害として package.json に対して１つの変更があったときにすべての SPA に影響が出てしまいます。ですので、この肥大化した package.json をそれぞれの SPA に分割しようとしました。 package.json を SPA 単位に分割することは 責務分離 という側面もあり、ライブラリだけでなく、共通していた定数、ロジック、コンポーネント、webpack.config.js、babel.config.js と tsconfig.json などすべてをそれぞれの SPA に依存のない形に閉じるようにしました。これらの分割する作業は非常に泥臭いもので、本記事に記載するほどのものではありませんが、得られた結果について記載していこうと思います。 結果 まず、責務分離ができたので、１つの SPA に対する変更があったときに、他の全ての SPA に対する影響が出なくなりました。よって、１つの SPA に対して新たな Web フレームワークやライブラリを試すことが容易になりました。他にも、１つの webpack ですべての SPA をシーケンシャルにビルドしていたのに対して、現在はパラレルでビルドできるようになりビルド時間が短縮されたため、今まで以上にコミットからデプロイまでのイテレーションが小さくなりました。 これらの結果からフロント開発環境の改善および DX 向上が果されました。 今後の課題 持続的なリファクタリングをする仕組み作り 「ライブラリの定期的なアップデートをする運用手順を設けた」はまさに持続的にライブラリをアップデートするための手段です。「package.json を SPA 単位に分割する」もそれぞれの SPA をメンテナンスしやすい環境作りとしては欠かせない作業でした。 しかし、このままリファクタリングを中断すれば、プロダクトの規模が大きくなるときやフロントエンドの時流によって再びメンテナンスしづらい環境になってしまいます。 なので、持続的なリファクタリングをするためには仕組み作りが欠かせないと考えています。そのためには、属人化によらない仕組みづくり、メンテナンスしやすい環境改善、エンジニアそれぞれのフロントエンド開発環境に対するリテラシを高める取り組みを行っていく必要があります。そのため、現在 横軸勉強会 などで CLINICS フロントエンドの実装背景や、リファクタリングしやすい書き方などのナレッジを共有しています。 まとめ フロントエンド開発環境のメンテナンス・リファクタリング自体はあくまでもユーザに新しい機能を提供しているわけではなく、粛々と行っていくものです。しかし、課題を洗い出し、向き合って、解決していったことによって得られたプラクティスは多くあり、フロントエンドのエコシステムに対する理解も多く得られました。 これらのリファクタリングを行うことによって DX が向上していき、技術的なノイズに悩む時間が減り、エンジニアはよりプロダクトの機能開発に専念できるようになっていると信じています。 今回私たちが課題を解決したことによって、持続的にリファクタリングをしやすい土台作りをしたという側面もあると思います。今後の課題として、この土台を基にそれぞれのエンジニアが意識を持ってメンテナンスできるような仕組みづくりも行っていきたいと思います。 最後まで読んでいただきありがとうございました。 www.medley.jp

こんにちは、第二開発グループエンジニアの西村です。主に CLINICS の開発を担当しています。 はじめに CLINICS は電子カルテ、オンライン診療、予約システム、患者アプリなどを含む統合アプリです。CLINICS がローンチしてから現在に至るまで常に新機能開発と定常改善が行われており、開発環境のメンテナンスは後手になりがちでした。今回はそういった状況を改善すべく、開発環境のメンテナンス、リファクタリングを行った過程から得られたプラクティスについて紹介していこうと思います。 モチベーション プロダクトの新規開発時に行われる技術選定は非常に難しく、業務要件やチーム状況など総合的に考慮してその時点でのベストな選択をする必要があります。 しかし、選択した技術で長期運用をしていくうちに、メンテナンスが行き届かなくなったコードやライブラリが出てしまいます。 CLINICS ローンチ当初はオンライン診療のみを提供していました。SPA で構成されていましたが、１つの package.json で効率的に開発できていました。他に、現在ほど TypeScript が主流ではなかったので JavaScript のコードがメインで実装されてました。 新たなアプリケーション（電子カルテや予約システムなど）を導入するタイミング、すなわちプロダクトが小規模から中規模に変遷するタイミングや、フロントエンドの時流によって、開発環境を改善できた部分もありますが、しきれていない部分も出てきました。 その改善しきれていない部分を残す状態が続くと Developer Experience(DX)の低下に繋がってしまいます。ですので、私たちは改善しきれていない部分を取り除いていき、よりモダンとされる開発環境へリファクタリングをしていこうと考えました。 DX を向上していくことで技術的なノイズに時間を取られないようになります。そして提供する機能そのものについて考える時間が増え、結果的に CLINICS をより良いプロダクトへ進化させていくのが当リファクタリングの目的です。 課題整理 改善していくためには、現状整理、課題整理を行わないことには何も始まりません。フロントエンド開発環境をメンテナンスするタスクは、プロダクトの機能（ユーザに提供される機能）に直接プラスの影響があるわけではありません。自ずと通常の機能開発や定常改善に比べ優先度は落ちるため、スキマ時間で改善をしていくことになります。こうしたスキマ時間を有効活用するためには、タスクの難易度の理解、タスクを適当に分割、フェージングの計画を行うことが極めて大事です。 そのように考慮した課題の中で、本記事で記載するのは以下の２つです。 ライブラリを定期的にアップデートする運用が固まってない 運用方式が固まっていないことで、放置されてしまいがちです。率先してアップデートするメンバーがいたとしても、属人化の課題が残ってしまいます 放置されてしまったことにより、最新版との差分が大きくなりアップデートするコストも大きくなってしまいます 結果的に、ライブラリのセキュリティフィックス対応や新しく提供された機能をすぐに適応できない環境になってしまいます 複数の SPA の依存を１つの package.json で管理している 電子カルテ・オンライン診療、社内管理 Web アプリ、患者 Web アプリはそれぞれ別の SPA として作られています それらを１つの package.json で管理しているためそれぞれの SPA が同じ依存パッケージを使わなくてはなりません。小規模のときはこのような構成で十分でしたが、規模が大きくなるにつれて柔軟性が失われると共に、ライブラリのアップデートがもたらす影響範囲が広がってしまうため、容易にアップデートできなくなってしまいます 本記事では記載しませんが「Redux の書き方が混在している」「フロントエンドのテストが少ない」「網羅的に TypeScript 化できていなく JavaScript がまだ残っている」などの課題も挙げられました。 こういう課題は、どのプロダクトにも存在すると思います。それはローンチ当時の技術流行であったり、プロダクトの期待規模、少数メンバに適した設計など要因は様々あり、プログラムのリファクタリングと同様に プロダクトの成長に伴ってリファクタリングしていくことが正 だと信じています。 モチベーションにて記載した通り、これら複数の課題は開発環境のノイズであり、除去することによって、より良い DX が得られると考えています。他にこのようなリファクタリングを行うことによって、プロダクトをより堅牢にできるという側面もあります。 上記の２つの課題に対してそれぞれ「ライブラリを定期的にアップデートする運用手段を設けた」「package.json を SPA 単位に分割した」話をこれからしていきます。 フロントエンド開発環境のリファクタリング ライブラリの定期的なアップデートをする運用手順を設けた 手動アップデート ライブラリをアップデートするにはコマンドを叩くだけだと考えていましたが、依存している別のライブラリに影響が本当にないかなど調査する必要があると知り、ライブラリのアップデート方法を模索するところから開始しました。 ライブラリではないですが、Node.js のアップデートをしようとすると、node-sass や Firebase が影響していたりして、芋づる式で根っこにあるライブラリのアップデートをする必要が出てきたりするので、一つ一つ問題がないか調査するのが大変でした。 何より、アップデート対象ライブラリのリリースノートに Breaking Changes が書かれていなかったり、semver が守られているかわからなかったりと、プロダクトに影響がないか調べる必要があり、問題の切り分け方が難しかったのです。 ここで得られたライブラリアップデートの安全性担保のプラクティスとして webpack によるビルド結果が変わらないケース と、 QA テストによって担保するケース があることがわかりました。前者は webpack による成果物が変わらないのであれば今回のアップデートが安全であるといえ、後者はエンジニアと QA エンジニアによってライブラリの影響範囲にハレーションがないことを確かめて安全であるといえるというものです。 renovate の運用開始 数カ月間は上記のようにライブラリのアップデートを手動で行っていましたが、確認工数が増えてしまい、他のタスクの時間を圧迫してしまうほどでした。 そこで、アップデートを自動化する renovate  と dependabot を視野に入れました。renovate は、dependabot に比べて高機能でかつ、無料であるという理由で選定しました。 運用当初、renovate が Pull Request を作成してくれたり、diff によりライブラリの変更点が見やすかったりと、恩恵を感じていました。しかし、徐々に「アップデート対象が多く、それぞれがどういうライブラリで、影響範囲がどこなのか」ということの調査に時間が取られるようになってしまいました。 ここで得られた調査時間を短縮するプラクティスとして**「本番影響のあるもの」「開発向け」「ビルド周り」と renovate から来る Pull Request を整理する**ことです。このような整理を行うことで、本番影響のあるものに注力してレビューできるようになり、苦にならずにアップデートをできるようになりました。 結果 ライブラリアップデートの運用手順を設けることによって、今まで以上に堅牢な環境になりました。それから、renovate によって自動的に重要な（本番影響のある）ライブラリのみに集中してレビューを行うことによって、少ない工数でアップデートしていけるようになりました。 package.json を SPA 単位に分割 課題整理で記載した通り、電子カルテ・オンライン診療、社内管理 Web アプリ、患者 Web アプリはそれぞれ別の SPA として作られていますが、１つの package.json で管理しています。ですのでそれぞれの SPA が同じ依存パッケージを使わなければなりません。 弊害として package.json に対して１つの変更があったときにすべての SPA に影響が出てしまいます。ですので、この肥大化した package.json をそれぞれの SPA に分割しようとしました。 package.json を SPA 単位に分割することは 責務分離 という側面もあり、ライブラリだけでなく、共通していた定数、ロジック、コンポーネント、webpack.config.js、babel.config.js と tsconfig.json などすべてをそれぞれの SPA に依存のない形に閉じるようにしました。これらの分割する作業は非常に泥臭いもので、本記事に記載するほどのものではありませんが、得られた結果について記載していこうと思います。 結果 まず、責務分離ができたので、１つの SPA に対する変更があったときに、他の全ての SPA に対する影響が出なくなりました。よって、１つの SPA に対して新たな Web フレームワークやライブラリを試すことが容易になりました。他にも、１つの webpack ですべての SPA をシーケンシャルにビルドしていたのに対して、現在はパラレルでビルドできるようになりビルド時間が短縮されたため、今まで以上にコミットからデプロイまでのイテレーションが小さくなりました。 これらの結果からフロント開発環境の改善および DX 向上が果されました。 今後の課題 持続的なリファクタリングをする仕組み作り 「ライブラリの定期的なアップデートをする運用手順を設けた」はまさに持続的にライブラリをアップデートするための手段です。「package.json を SPA 単位に分割する」もそれぞれの SPA をメンテナンスしやすい環境作りとしては欠かせない作業でした。 しかし、このままリファクタリングを中断すれば、プロダクトの規模が大きくなるときやフロントエンドの時流によって再びメンテナンスしづらい環境になってしまいます。 なので、持続的なリファクタリングをするためには仕組み作りが欠かせないと考えています。そのためには、属人化によらない仕組みづくり、メンテナンスしやすい環境改善、エンジニアそれぞれのフロントエンド開発環境に対するリテラシを高める取り組みを行っていく必要があります。そのため、現在 横軸勉強会 などで CLINICS フロントエンドの実装背景や、リファクタリングしやすい書き方などのナレッジを共有しています。 まとめ フロントエンド開発環境のメンテナンス・リファクタリング自体はあくまでもユーザに新しい機能を提供しているわけではなく、粛々と行っていくものです。しかし、課題を洗い出し、向き合って、解決していったことによって得られたプラクティスは多くあり、フロントエンドのエコシステムに対する理解も多く得られました。 これらのリファクタリングを行うことによって DX が向上していき、技術的なノイズに悩む時間が減り、エンジニアはよりプロダクトの機能開発に専念できるようになっていると信じています。 今回私たちが課題を解決したことによって、持続的にリファクタリングをしやすい土台作りをしたという側面もあると思います。今後の課題として、この土台を基にそれぞれのエンジニアが意識を持ってメンテナンスできるような仕組みづくりも行っていきたいと思います。 最後まで読んでいただきありがとうございました。 www.medley.jp

こんにちは、第二開発グループエンジニアの西村です。主に CLINICS の開発を担当しています。 はじめに CLINICS は電子カルテ、オンライン診療、予約システム、患者アプリなどを含む統合アプリです。CLINICS がローンチしてから現在に至るまで常に新機能開発と定常改善が行われており、開発環境のメンテナンスは後手になりがちでした。今回はそういった状況を改善すべく、開発環境のメンテナンス、リファクタリングを行った過程から得られたプラクティスについて紹介していこうと思います。 モチベーション プロダクトの新規開発時に行われる技術選定は非常に難しく、業務要件やチーム状況など総合的に考慮してその時点でのベストな選択をする必要があります。 しかし、選択した技術で長期運用をしていくうちに、メンテナンスが行き届かなくなったコードやライブラリが出てしまいます。 CLINICS ローンチ当初はオンライン診療のみを提供していました。SPA で構成されていましたが、１つの package.json で効率的に開発できていました。他に、現在ほど TypeScript が主流ではなかったので JavaScript のコードがメインで実装されてました。 新たなアプリケーション（電子カルテや予約システムなど）を導入するタイミング、すなわちプロダクトが小規模から中規模に変遷するタイミングや、フロントエンドの時流によって、開発環境を改善できた部分もありますが、しきれていない部分も出てきました。 その改善しきれていない部分を残す状態が続くと Developer Experience(DX)の低下に繋がってしまいます。ですので、私たちは改善しきれていない部分を取り除いていき、よりモダンとされる開発環境へリファクタリングをしていこうと考えました。 DX を向上していくことで技術的なノイズに時間を取られないようになります。そして提供する機能そのものについて考える時間が増え、結果的に CLINICS をより良いプロダクトへ進化させていくのが当リファクタリングの目的です。 課題整理 改善していくためには、現状整理、課題整理を行わないことには何も始まりません。フロントエンド開発環境をメンテナンスするタスクは、プロダクトの機能（ユーザに提供される機能）に直接プラスの影響があるわけではありません。自ずと通常の機能開発や定常改善に比べ優先度は落ちるため、スキマ時間で改善をしていくことになります。こうしたスキマ時間を有効活用するためには、タスクの難易度の理解、タスクを適当に分割、フェージングの計画を行うことが極めて大事です。 そのように考慮した課題の中で、本記事で記載するのは以下の２つです。 ライブラリを定期的にアップデートする運用が固まってない 運用方式が固まっていないことで、放置されてしまいがちです。率先してアップデートするメンバーがいたとしても、属人化の課題が残ってしまいます 放置されてしまったことにより、最新版との差分が大きくなりアップデートするコストも大きくなってしまいます 結果的に、ライブラリのセキュリティフィックス対応や新しく提供された機能をすぐに適応できない環境になってしまいます 複数の SPA の依存を１つの package.json で管理している 電子カルテ・オンライン診療、社内管理 Web アプリ、患者 Web アプリはそれぞれ別の SPA として作られています それらを１つの package.json で管理しているためそれぞれの SPA が同じ依存パッケージを使わなくてはなりません。小規模のときはこのような構成で十分でしたが、規模が大きくなるにつれて柔軟性が失われると共に、ライブラリのアップデートがもたらす影響範囲が広がってしまうため、容易にアップデートできなくなってしまいます 本記事では記載しませんが「Redux の書き方が混在している」「フロントエンドのテストが少ない」「網羅的に TypeScript 化できていなく JavaScript がまだ残っている」などの課題も挙げられました。 こういう課題は、どのプロダクトにも存在すると思います。それはローンチ当時の技術流行であったり、プロダクトの期待規模、少数メンバに適した設計など要因は様々あり、プログラムのリファクタリングと同様に プロダクトの成長に伴ってリファクタリングしていくことが正 だと信じています。 モチベーションにて記載した通り、これら複数の課題は開発環境のノイズであり、除去することによって、より良い DX が得られると考えています。他にこのようなリファクタリングを行うことによって、プロダクトをより堅牢にできるという側面もあります。 上記の２つの課題に対してそれぞれ「ライブラリを定期的にアップデートする運用手段を設けた」「package.json を SPA 単位に分割した」話をこれからしていきます。 フロントエンド開発環境のリファクタリング ライブラリの定期的なアップデートをする運用手順を設けた 手動アップデート ライブラリをアップデートするにはコマンドを叩くだけだと考えていましたが、依存している別のライブラリに影響が本当にないかなど調査する必要があると知り、ライブラリのアップデート方法を模索するところから開始しました。 ライブラリではないですが、Node.js のアップデートをしようとすると、node-sass や Firebase が影響していたりして、芋づる式で根っこにあるライブラリのアップデートをする必要が出てきたりするので、一つ一つ問題がないか調査するのが大変でした。 何より、アップデート対象ライブラリのリリースノートに Breaking Changes が書かれていなかったり、semver が守られているかわからなかったりと、プロダクトに影響がないか調べる必要があり、問題の切り分け方が難しかったのです。 ここで得られたライブラリアップデートの安全性担保のプラクティスとして webpack によるビルド結果が変わらないケース と、 QA テストによって担保するケース があることがわかりました。前者は webpack による成果物が変わらないのであれば今回のアップデートが安全であるといえ、後者はエンジニアと QA エンジニアによってライブラリの影響範囲にハレーションがないことを確かめて安全であるといえるというものです。 renovate の運用開始 数カ月間は上記のようにライブラリのアップデートを手動で行っていましたが、確認工数が増えてしまい、他のタスクの時間を圧迫してしまうほどでした。 そこで、アップデートを自動化する renovate  と dependabot を視野に入れました。renovate は、dependabot に比べて高機能でかつ、無料であるという理由で選定しました。 運用当初、renovate が Pull Request を作成してくれたり、diff によりライブラリの変更点が見やすかったりと、恩恵を感じていました。しかし、徐々に「アップデート対象が多く、それぞれがどういうライブラリで、影響範囲がどこなのか」ということの調査に時間が取られるようになってしまいました。 ここで得られた調査時間を短縮するプラクティスとして**「本番影響のあるもの」「開発向け」「ビルド周り」と renovate から来る Pull Request を整理する**ことです。このような整理を行うことで、本番影響のあるものに注力してレビューできるようになり、苦にならずにアップデートをできるようになりました。 結果 ライブラリアップデートの運用手順を設けることによって、今まで以上に堅牢な環境になりました。それから、renovate によって自動的に重要な（本番影響のある）ライブラリのみに集中してレビューを行うことによって、少ない工数でアップデートしていけるようになりました。 package.json を SPA 単位に分割 課題整理で記載した通り、電子カルテ・オンライン診療、社内管理 Web アプリ、患者 Web アプリはそれぞれ別の SPA として作られていますが、１つの package.json で管理しています。ですのでそれぞれの SPA が同じ依存パッケージを使わなければなりません。 弊害として package.json に対して１つの変更があったときにすべての SPA に影響が出てしまいます。ですので、この肥大化した package.json をそれぞれの SPA に分割しようとしました。 package.json を SPA 単位に分割することは 責務分離 という側面もあり、ライブラリだけでなく、共通していた定数、ロジック、コンポーネント、webpack.config.js、babel.config.js と tsconfig.json などすべてをそれぞれの SPA に依存のない形に閉じるようにしました。これらの分割する作業は非常に泥臭いもので、本記事に記載するほどのものではありませんが、得られた結果について記載していこうと思います。 結果 まず、責務分離ができたので、１つの SPA に対する変更があったときに、他の全ての SPA に対する影響が出なくなりました。よって、１つの SPA に対して新たな Web フレームワークやライブラリを試すことが容易になりました。他にも、１つの webpack ですべての SPA をシーケンシャルにビルドしていたのに対して、現在はパラレルでビルドできるようになりビルド時間が短縮されたため、今まで以上にコミットからデプロイまでのイテレーションが小さくなりました。 これらの結果からフロント開発環境の改善および DX 向上が果されました。 今後の課題 持続的なリファクタリングをする仕組み作り 「ライブラリの定期的なアップデートをする運用手順を設けた」はまさに持続的にライブラリをアップデートするための手段です。「package.json を SPA 単位に分割する」もそれぞれの SPA をメンテナンスしやすい環境作りとしては欠かせない作業でした。 しかし、このままリファクタリングを中断すれば、プロダクトの規模が大きくなるときやフロントエンドの時流によって再びメンテナンスしづらい環境になってしまいます。 なので、持続的なリファクタリングをするためには仕組み作りが欠かせないと考えています。そのためには、属人化によらない仕組みづくり、メンテナンスしやすい環境改善、エンジニアそれぞれのフロントエンド開発環境に対するリテラシを高める取り組みを行っていく必要があります。そのため、現在 横軸勉強会 などで CLINICS フロントエンドの実装背景や、リファクタリングしやすい書き方などのナレッジを共有しています。 まとめ フロントエンド開発環境のメンテナンス・リファクタリング自体はあくまでもユーザに新しい機能を提供しているわけではなく、粛々と行っていくものです。しかし、課題を洗い出し、向き合って、解決していったことによって得られたプラクティスは多くあり、フロントエンドのエコシステムに対する理解も多く得られました。 これらのリファクタリングを行うことによって DX が向上していき、技術的なノイズに悩む時間が減り、エンジニアはよりプロダクトの機能開発に専念できるようになっていると信じています。 今回私たちが課題を解決したことによって、持続的にリファクタリングをしやすい土台作りをしたという側面もあると思います。今後の課題として、この土台を基にそれぞれのエンジニアが意識を持ってメンテナンスできるような仕組みづくりも行っていきたいと思います。 最後まで読んでいただきありがとうございました。 www.medley.jp

こんにちは、第二開発グループエンジニアの西村です。主に CLINICS の開発を担当しています。 はじめに CLINICS は電子カルテ、オンライン診療、予約システム、患者アプリなどを含む統合アプリです。CLINICS がローンチしてから現在に至るまで常に新機能開発と定常改善が行われており、開発環境のメンテナンスは後手になりがちでした。今回はそういった状況を改善すべく、開発環境のメンテナンス、リファクタリングを行った過程から得られたプラクティスについて紹介していこうと思います。 モチベーション プロダクトの新規開発時に行われる技術選定は非常に難しく、業務要件やチーム状況など総合的に考慮してその時点でのベストな選択をする必要があります。 しかし、選択した技術で長期運用をしていくうちに、メンテナンスが行き届かなくなったコードやライブラリが出てしまいます。 CLINICS ローンチ当初はオンライン診療のみを提供していました。SPA で構成されていましたが、１つの package.json で効率的に開発できていました。他に、現在ほど TypeScript が主流ではなかったので JavaScript のコードがメインで実装されてました。 新たなアプリケーション（電子カルテや予約システムなど）を導入するタイミング、すなわちプロダクトが小規模から中規模に変遷するタイミングや、フロントエンドの時流によって、開発環境を改善できた部分もありますが、しきれていない部分も出てきました。 その改善しきれていない部分を残す状態が続くと Developer Experience(DX)の低下に繋がってしまいます。ですので、私たちは改善しきれていない部分を取り除いていき、よりモダンとされる開発環境へリファクタリングをしていこうと考えました。 DX を向上していくことで技術的なノイズに時間を取られないようになります。そして提供する機能そのものについて考える時間が増え、結果的に CLINICS をより良いプロダクトへ進化させていくのが当リファクタリングの目的です。 課題整理 改善していくためには、現状整理、課題整理を行わないことには何も始まりません。フロントエンド開発環境をメンテナンスするタスクは、プロダクトの機能（ユーザに提供される機能）に直接プラスの影響があるわけではありません。自ずと通常の機能開発や定常改善に比べ優先度は落ちるため、スキマ時間で改善をしていくことになります。こうしたスキマ時間を有効活用するためには、タスクの難易度の理解、タスクを適当に分割、フェージングの計画を行うことが極めて大事です。 そのように考慮した課題の中で、本記事で記載するのは以下の２つです。 ライブラリを定期的にアップデートする運用が固まってない 運用方式が固まっていないことで、放置されてしまいがちです。率先してアップデートするメンバーがいたとしても、属人化の課題が残ってしまいます 放置されてしまったことにより、最新版との差分が大きくなりアップデートするコストも大きくなってしまいます 結果的に、ライブラリのセキュリティフィックス対応や新しく提供された機能をすぐに適応できない環境になってしまいます 複数の SPA の依存を１つの package.json で管理している 電子カルテ・オンライン診療、社内管理 Web アプリ、患者 Web アプリはそれぞれ別の SPA として作られています それらを１つの package.json で管理しているためそれぞれの SPA が同じ依存パッケージを使わなくてはなりません。小規模のときはこのような構成で十分でしたが、規模が大きくなるにつれて柔軟性が失われると共に、ライブラリのアップデートがもたらす影響範囲が広がってしまうため、容易にアップデートできなくなってしまいます 本記事では記載しませんが「Redux の書き方が混在している」「フロントエンドのテストが少ない」「網羅的に TypeScript 化できていなく JavaScript がまだ残っている」などの課題も挙げられました。 こういう課題は、どのプロダクトにも存在すると思います。それはローンチ当時の技術流行であったり、プロダクトの期待規模、少数メンバに適した設計など要因は様々あり、プログラムのリファクタリングと同様に プロダクトの成長に伴ってリファクタリングしていくことが正 だと信じています。 モチベーションにて記載した通り、これら複数の課題は開発環境のノイズであり、除去することによって、より良い DX が得られると考えています。他にこのようなリファクタリングを行うことによって、プロダクトをより堅牢にできるという側面もあります。 上記の２つの課題に対してそれぞれ「ライブラリを定期的にアップデートする運用手段を設けた」「package.json を SPA 単位に分割した」話をこれからしていきます。 フロントエンド開発環境のリファクタリング ライブラリの定期的なアップデートをする運用手順を設けた 手動アップデート ライブラリをアップデートするにはコマンドを叩くだけだと考えていましたが、依存している別のライブラリに影響が本当にないかなど調査する必要があると知り、ライブラリのアップデート方法を模索するところから開始しました。 ライブラリではないですが、Node.js のアップデートをしようとすると、node-sass や Firebase が影響していたりして、芋づる式で根っこにあるライブラリのアップデートをする必要が出てきたりするので、一つ一つ問題がないか調査するのが大変でした。 何より、アップデート対象ライブラリのリリースノートに Breaking Changes が書かれていなかったり、semver が守られているかわからなかったりと、プロダクトに影響がないか調べる必要があり、問題の切り分け方が難しかったのです。 ここで得られたライブラリアップデートの安全性担保のプラクティスとして webpack によるビルド結果が変わらないケース と、 QA テストによって担保するケース があることがわかりました。前者は webpack による成果物が変わらないのであれば今回のアップデートが安全であるといえ、後者はエンジニアと QA エンジニアによってライブラリの影響範囲にハレーションがないことを確かめて安全であるといえるというものです。 renovate の運用開始 数カ月間は上記のようにライブラリのアップデートを手動で行っていましたが、確認工数が増えてしまい、他のタスクの時間を圧迫してしまうほどでした。 そこで、アップデートを自動化する renovate  と dependabot を視野に入れました。renovate は、dependabot に比べて高機能でかつ、無料であるという理由で選定しました。 運用当初、renovate が Pull Request を作成してくれたり、diff によりライブラリの変更点が見やすかったりと、恩恵を感じていました。しかし、徐々に「アップデート対象が多く、それぞれがどういうライブラリで、影響範囲がどこなのか」ということの調査に時間が取られるようになってしまいました。 ここで得られた調査時間を短縮するプラクティスとして**「本番影響のあるもの」「開発向け」「ビルド周り」と renovate から来る Pull Request を整理する**ことです。このような整理を行うことで、本番影響のあるものに注力してレビューできるようになり、苦にならずにアップデートをできるようになりました。 結果 ライブラリアップデートの運用手順を設けることによって、今まで以上に堅牢な環境になりました。それから、renovate によって自動的に重要な（本番影響のある）ライブラリのみに集中してレビューを行うことによって、少ない工数でアップデートしていけるようになりました。 package.json を SPA 単位に分割 課題整理で記載した通り、電子カルテ・オンライン診療、社内管理 Web アプリ、患者 Web アプリはそれぞれ別の SPA として作られていますが、１つの package.json で管理しています。ですのでそれぞれの SPA が同じ依存パッケージを使わなければなりません。 弊害として package.json に対して１つの変更があったときにすべての SPA に影響が出てしまいます。ですので、この肥大化した package.json をそれぞれの SPA に分割しようとしました。 package.json を SPA 単位に分割することは 責務分離 という側面もあり、ライブラリだけでなく、共通していた定数、ロジック、コンポーネント、webpack.config.js、babel.config.js と tsconfig.json などすべてをそれぞれの SPA に依存のない形に閉じるようにしました。これらの分割する作業は非常に泥臭いもので、本記事に記載するほどのものではありませんが、得られた結果について記載していこうと思います。 結果 まず、責務分離ができたので、１つの SPA に対する変更があったときに、他の全ての SPA に対する影響が出なくなりました。よって、１つの SPA に対して新たな Web フレームワークやライブラリを試すことが容易になりました。他にも、１つの webpack ですべての SPA をシーケンシャルにビルドしていたのに対して、現在はパラレルでビルドできるようになりビルド時間が短縮されたため、今まで以上にコミットからデプロイまでのイテレーションが小さくなりました。 これらの結果からフロント開発環境の改善および DX 向上が果されました。 今後の課題 持続的なリファクタリングをする仕組み作り 「ライブラリの定期的なアップデートをする運用手順を設けた」はまさに持続的にライブラリをアップデートするための手段です。「package.json を SPA 単位に分割する」もそれぞれの SPA をメンテナンスしやすい環境作りとしては欠かせない作業でした。 しかし、このままリファクタリングを中断すれば、プロダクトの規模が大きくなるときやフロントエンドの時流によって再びメンテナンスしづらい環境になってしまいます。 なので、持続的なリファクタリングをするためには仕組み作りが欠かせないと考えています。そのためには、属人化によらない仕組みづくり、メンテナンスしやすい環境改善、エンジニアそれぞれのフロントエンド開発環境に対するリテラシを高める取り組みを行っていく必要があります。そのため、現在 横軸勉強会 などで CLINICS フロントエンドの実装背景や、リファクタリングしやすい書き方などのナレッジを共有しています。 まとめ フロントエンド開発環境のメンテナンス・リファクタリング自体はあくまでもユーザに新しい機能を提供しているわけではなく、粛々と行っていくものです。しかし、課題を洗い出し、向き合って、解決していったことによって得られたプラクティスは多くあり、フロントエンドのエコシステムに対する理解も多く得られました。 これらのリファクタリングを行うことによって DX が向上していき、技術的なノイズに悩む時間が減り、エンジニアはよりプロダクトの機能開発に専念できるようになっていると信じています。 今回私たちが課題を解決したことによって、持続的にリファクタリングをしやすい土台作りをしたという側面もあると思います。今後の課題として、この土台を基にそれぞれのエンジニアが意識を持ってメンテナンスできるような仕組みづくりも行っていきたいと思います。 最後まで読んでいただきありがとうございました。 www.medley.jp

こんにちは、第二開発グループエンジニアの西村です。主に CLINICS の開発を担当しています。 はじめに CLINICS は電子カルテ、オンライン診療、予約システム、患者アプリなどを含む統合アプリです。CLINICS がローンチしてから現在に至るまで常に新機能開発と定常改善が行われており、開発環境のメンテナンスは後手になりがちでした。今回はそういった状況を改善すべく、開発環境のメンテナンス、リファクタリングを行った過程から得られたプラクティスについて紹介していこうと思います。 モチベーション プロダクトの新規開発時に行われる技術選定は非常に難しく、業務要件やチーム状況など総合的に考慮してその時点でのベストな選択をする必要があります。 しかし、選択した技術で長期運用をしていくうちに、メンテナンスが行き届かなくなったコードやライブラリが出てしまいます。 CLINICS ローンチ当初はオンライン診療のみを提供していました。SPA で構成されていましたが、１つの package.json で効率的に開発できていました。他に、現在ほど TypeScript が主流ではなかったので JavaScript のコードがメインで実装されてました。 新たなアプリケーション（電子カルテや予約システムなど）を導入するタイミング、すなわちプロダクトが小規模から中規模に変遷するタイミングや、フロントエンドの時流によって、開発環境を改善できた部分もありますが、しきれていない部分も出てきました。 その改善しきれていない部分を残す状態が続くと Developer Experience(DX)の低下に繋がってしまいます。ですので、私たちは改善しきれていない部分を取り除いていき、よりモダンとされる開発環境へリファクタリングをしていこうと考えました。 DX を向上していくことで技術的なノイズに時間を取られないようになります。そして提供する機能そのものについて考える時間が増え、結果的に CLINICS をより良いプロダクトへ進化させていくのが当リファクタリングの目的です。 課題整理 改善していくためには、現状整理、課題整理を行わないことには何も始まりません。フロントエンド開発環境をメンテナンスするタスクは、プロダクトの機能（ユーザに提供される機能）に直接プラスの影響があるわけではありません。自ずと通常の機能開発や定常改善に比べ優先度は落ちるため、スキマ時間で改善をしていくことになります。こうしたスキマ時間を有効活用するためには、タスクの難易度の理解、タスクを適当に分割、フェージングの計画を行うことが極めて大事です。 そのように考慮した課題の中で、本記事で記載するのは以下の２つです。 ライブラリを定期的にアップデートする運用が固まってない 運用方式が固まっていないことで、放置されてしまいがちです。率先してアップデートするメンバーがいたとしても、属人化の課題が残ってしまいます 放置されてしまったことにより、最新版との差分が大きくなりアップデートするコストも大きくなってしまいます 結果的に、ライブラリのセキュリティフィックス対応や新しく提供された機能をすぐに適応できない環境になってしまいます 複数の SPA の依存を１つの package.json で管理している 電子カルテ・オンライン診療、社内管理 Web アプリ、患者 Web アプリはそれぞれ別の SPA として作られています それらを１つの package.json で管理しているためそれぞれの SPA が同じ依存パッケージを使わなくてはなりません。小規模のときはこのような構成で十分でしたが、規模が大きくなるにつれて柔軟性が失われると共に、ライブラリのアップデートがもたらす影響範囲が広がってしまうため、容易にアップデートできなくなってしまいます 本記事では記載しませんが「Redux の書き方が混在している」「フロントエンドのテストが少ない」「網羅的に TypeScript 化できていなく JavaScript がまだ残っている」などの課題も挙げられました。 こういう課題は、どのプロダクトにも存在すると思います。それはローンチ当時の技術流行であったり、プロダクトの期待規模、少数メンバに適した設計など要因は様々あり、プログラムのリファクタリングと同様に プロダクトの成長に伴ってリファクタリングしていくことが正 だと信じています。 モチベーションにて記載した通り、これら複数の課題は開発環境のノイズであり、除去することによって、より良い DX が得られると考えています。他にこのようなリファクタリングを行うことによって、プロダクトをより堅牢にできるという側面もあります。 上記の２つの課題に対してそれぞれ「ライブラリを定期的にアップデートする運用手段を設けた」「package.json を SPA 単位に分割した」話をこれからしていきます。 フロントエンド開発環境のリファクタリング ライブラリの定期的なアップデートをする運用手順を設けた 手動アップデート ライブラリをアップデートするにはコマンドを叩くだけだと考えていましたが、依存している別のライブラリに影響が本当にないかなど調査する必要があると知り、ライブラリのアップデート方法を模索するところから開始しました。 ライブラリではないですが、Node.js のアップデートをしようとすると、node-sass や Firebase が影響していたりして、芋づる式で根っこにあるライブラリのアップデートをする必要が出てきたりするので、一つ一つ問題がないか調査するのが大変でした。 何より、アップデート対象ライブラリのリリースノートに Breaking Changes が書かれていなかったり、semver が守られているかわからなかったりと、プロダクトに影響がないか調べる必要があり、問題の切り分け方が難しかったのです。 ここで得られたライブラリアップデートの安全性担保のプラクティスとして webpack によるビルド結果が変わらないケース と、 QA テストによって担保するケース があることがわかりました。前者は webpack による成果物が変わらないのであれば今回のアップデートが安全であるといえ、後者はエンジニアと QA エンジニアによってライブラリの影響範囲にハレーションがないことを確かめて安全であるといえるというものです。 renovate の運用開始 数カ月間は上記のようにライブラリのアップデートを手動で行っていましたが、確認工数が増えてしまい、他のタスクの時間を圧迫してしまうほどでした。 そこで、アップデートを自動化する renovate  と dependabot を視野に入れました。renovate は、dependabot に比べて高機能でかつ、無料であるという理由で選定しました。 運用当初、renovate が Pull Request を作成してくれたり、diff によりライブラリの変更点が見やすかったりと、恩恵を感じていました。しかし、徐々に「アップデート対象が多く、それぞれがどういうライブラリで、影響範囲がどこなのか」ということの調査に時間が取られるようになってしまいました。 ここで得られた調査時間を短縮するプラクティスとして**「本番影響のあるもの」「開発向け」「ビルド周り」と renovate から来る Pull Request を整理する**ことです。このような整理を行うことで、本番影響のあるものに注力してレビューできるようになり、苦にならずにアップデートをできるようになりました。 結果 ライブラリアップデートの運用手順を設けることによって、今まで以上に堅牢な環境になりました。それから、renovate によって自動的に重要な（本番影響のある）ライブラリのみに集中してレビューを行うことによって、少ない工数でアップデートしていけるようになりました。 package.json を SPA 単位に分割 課題整理で記載した通り、電子カルテ・オンライン診療、社内管理 Web アプリ、患者 Web アプリはそれぞれ別の SPA として作られていますが、１つの package.json で管理しています。ですのでそれぞれの SPA が同じ依存パッケージを使わなければなりません。 弊害として package.json に対して１つの変更があったときにすべての SPA に影響が出てしまいます。ですので、この肥大化した package.json をそれぞれの SPA に分割しようとしました。 package.json を SPA 単位に分割することは 責務分離 という側面もあり、ライブラリだけでなく、共通していた定数、ロジック、コンポーネント、webpack.config.js、babel.config.js と tsconfig.json などすべてをそれぞれの SPA に依存のない形に閉じるようにしました。これらの分割する作業は非常に泥臭いもので、本記事に記載するほどのものではありませんが、得られた結果について記載していこうと思います。 結果 まず、責務分離ができたので、１つの SPA に対する変更があったときに、他の全ての SPA に対する影響が出なくなりました。よって、１つの SPA に対して新たな Web フレームワークやライブラリを試すことが容易になりました。他にも、１つの webpack ですべての SPA をシーケンシャルにビルドしていたのに対して、現在はパラレルでビルドできるようになりビルド時間が短縮されたため、今まで以上にコミットからデプロイまでのイテレーションが小さくなりました。 これらの結果からフロント開発環境の改善および DX 向上が果されました。 今後の課題 持続的なリファクタリングをする仕組み作り 「ライブラリの定期的なアップデートをする運用手順を設けた」はまさに持続的にライブラリをアップデートするための手段です。「package.json を SPA 単位に分割する」もそれぞれの SPA をメンテナンスしやすい環境作りとしては欠かせない作業でした。 しかし、このままリファクタリングを中断すれば、プロダクトの規模が大きくなるときやフロントエンドの時流によって再びメンテナンスしづらい環境になってしまいます。 なので、持続的なリファクタリングをするためには仕組み作りが欠かせないと考えています。そのためには、属人化によらない仕組みづくり、メンテナンスしやすい環境改善、エンジニアそれぞれのフロントエンド開発環境に対するリテラシを高める取り組みを行っていく必要があります。そのため、現在 横軸勉強会 などで CLINICS フロントエンドの実装背景や、リファクタリングしやすい書き方などのナレッジを共有しています。 まとめ フロントエンド開発環境のメンテナンス・リファクタリング自体はあくまでもユーザに新しい機能を提供しているわけではなく、粛々と行っていくものです。しかし、課題を洗い出し、向き合って、解決していったことによって得られたプラクティスは多くあり、フロントエンドのエコシステムに対する理解も多く得られました。 これらのリファクタリングを行うことによって DX が向上していき、技術的なノイズに悩む時間が減り、エンジニアはよりプロダクトの機能開発に専念できるようになっていると信じています。 今回私たちが課題を解決したことによって、持続的にリファクタリングをしやすい土台作りをしたという側面もあると思います。今後の課題として、この土台を基にそれぞれのエンジニアが意識を持ってメンテナンスできるような仕組みづくりも行っていきたいと思います。 最後まで読んでいただきありがとうございました。 www.medley.jp