初めまして。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 の開発を担当しているエンジニアの平山です。 （同姓ですが 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 の開発を担当しています。 はじめに 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

こんにちは、第二開発グループエンジニアの西村です。主に 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

皆様こんにちは。インキュベーション本部エンジニアの濱中です。 9/19〜21 に iOSDC Japan 2020 （以下 iOSDC）が開催されました。 先日の記事 の通り、メドレーは 2017 年より iOSDC に 協賛 しております。 メドレーでは、Swift を利用してオンライン診療／服薬指導アプリ「CLINICS」iOS 版の開発をしています。 CLINICS(クリニクス)　オンライン診療・服薬指導アプリ 5 回目となる今回は、初のオンライン開催となり、主にニコニコ生放送、Discord 上で発表・コミュニケーションが行われました。私が iOS 版 CLINICS の開発に携わっている縁で、今回スポンサー枠として iOSDC に参加させていただきましたので紹介させていただきます。 イベント全体について オンライン開催となったため、会場の様子や企業ブースなど、雰囲気の伝わる写真をお届けできないのが残念ですが、発表の主会場となったニコニコ生放送では、終始穏やかな雰囲気でありつつも活発にコメントがなされ、大いに盛り上がっていました。 前回同様、初日は day 0 として夕方から、2 日目以降は朝〜夕方まで、最大 5 つのチャンネルで並行して発表が行われました。セッションについては事前に録画したものを放送し、LT のみリモートにてリアルタイム発表という形式となっていました。 質疑応答については、各発表の終了直後に Discord チャンネルに発表者が待機して対応していました。初のオンライン開催ということで、イントロダクション動画をはじめとし、各所で積極的なフィードバック・コミュニケーションが奨励されていたように思います（なお、イントロダクション・スポンサー紹介の各動画はナレーションが声優の緒方恵美さん・三石琴乃さんと、とても豪華でした。生放送中のコメントや、 18 年の弊社ブログ を見る限りは毎年恒例のようですね。すごいです！）。 セッションについて 昨年 iOS13 とともに発表された SwiftUI への移行や、コード移行・モジュール分割等、プロジェクトの最適化についてのトピックが多かったように思います。 SwiftUI は、従来 Storyboard で設計していた UI をコードベースで記述できる画期的なフレームワークですが、SwiftUI を使ったアプリは iOS13 未満の端末では利用できなくなってしまうこともあり、アプリの公開対象を広めにもっておきたい場合はなかなか乗り換えづらい印象でした。2020 年 6 月現在で iOS13 のシェアが 9 割以上となったことで、ちょうど iOSDC での発表トピックを決めるころに導入作業を行った（かつ苦労した）というケースが多かったのかな、と思います。 以下、視聴したセッションのうち気になったものをいくつかご紹介いたします。 オープンソースの AltSwiftUI の発表 fortee.jp 楽天のエンジニアの方による、SwiftUI の提供するネイティブコンポーネントに対応しつつ、iOS11 以上で利用可能なオープンソースのフレームワーク AltSwiftUI （ 公式 Doc ）の開発についてのセッションでした。 iOS12 以下の対応を切らずに SwiftUI への乗り換えを進められる（かつ本家と違ってオープンソースである）便利さもそうですが、別途フレームワークが出来上がってしまうあたりに、SwiftUI への移行対応への苦労がしのばれる内容でもありました（ストアにある楽天提供の iOS アプリの数を考えると乗り換えコストが大変そう…）。 「それ、自動化できますよ」: note を支えるワークフロー大全 speakerdeck.com 改修要望が上がってから、実際に改修を行ってアプリをリリースするまでの作業をできる限り自動化した、というセッションです。CLINICS でも、「証明書の有効期限確認、プッシュからのテスト、マージからのリリース準備」は Bitrise のトリガを利用して自動化しています。 上記のような、GitHub 上でのアクション（プッシュ、マージなど）をトリガとする自動化はよく聞く話ではあるのですが、Slack のポストに特定のスタンプつけると Issue 化、はちょっと目新しくて面白いなと思いました（気をつけないと表記揺れで同じような Issue が乱立しそうですが）。 Issue もきちんと管理しておかないとトラブルの起きやすい部分ですよね。起票者と実装者の間でボールが浮いてしまったり、プロジェクトに紐づいていなかったために対応から洩れてしまったり…。 また、このスライドですが終始手書きの挿絵がかわいくて、そういった意味でもコメント欄が盛り上がっていたのが印象的でした。 100 人でアプリをリファクタリングして見えてきた、最強の iOS アプリ設計に求められること fortee.jp アプリを長期に運用していくとほぼ必須となる課題でありながら、人ごとに基準が曖昧だったり、機能開発におされて対応が後手後手になったり…と、何かとつらい話をよく聞くソースコードのリファクタリングに関するセッションでした。 同じ状態のソースコードを多数のエンジニアがリファクタした結果を比較することで、「良いリファクタリングのための考え方」とは何か？を模索した内容です。 ビューとロジックの分割をしっかり行う、というのは PR レビューでエンジニアが口を酸っぱくしてよく言われることではありますが、「ロジックの中でも、アプリの仕様に依存するものとそうでない普遍的なものは分離すべき」というアイデアは個人的には眼から鱗が落ちるものでした。 また、これを説明するリバーシの具体例（「対戦相手が人間か AI か」はアプリ仕様に依存するロジック、「そこに石を置けるか」は普遍的なロジック＝リバーシのルールそのもの）も非常にわかりやすかったです。 そのほか、React / Redux でフロントエンド開発を行っている人にはお馴染みの Action / Reducer を使った単一方向のデータフローの導入なども紹介されています。 新規機能開発からモジュール分割を始めてみる speakerdeck.com 一つのアプリが長期間運用されていくなかで、複数の機能が統合されたスーパーアプリになることがあります。そうなった場合、ソースコードが肥大化 → ビルド・テストも長大化、となってメンテナンス性が低下するため、対策としてコードを分割してテストやビルドの単位を小さくする必要があります。 いきなりアプリ全体をモジュールに分割するのは時間がかかるため、本セッションではまず第一段階として新規に開発する機能を別モジュールとして実装し、その時得た知見について触れられていました。 「分割したモジュール側でのサードパーティ製フレームワークのリンク方法（※リンクを正しく行わないと、ビルドして動作はするのにアーカイブに失敗してリリースできなくなる）」などは、今後の開発にモジュール分割を取り入れていく際に参考になりそうです。 Swift で始める静的解析 speakerdeck.com Swift ソースコードからの構文木の生成、解析を行うライブラリ SwiftSyntax の紹介と、それを用いたソースコード重複検出機能の実装についてのセッションでした。 普段 Xcode を始めとした IDE で開発していると、コード重複、不要なローカル変数、型や Nullable の不一致に変数リファクタリング…等々の便利な機能を気軽に使えてしまいますが、その裏の動作を改めて一つずつ具体的に追っていくと、そのありがたみが身に染みます…。 静的解析そのものは Swift に限らず様々な言語のソースコードに対して適用できるトピックではあるのですが、普段何気なく使ってしまう IDE の機能について考えるよい機会になったため、紹介させていただきました。 まとめ ちょうど業務でも iOS アプリ開発を担当していることもあり、興味深い知見が得られ、よい経験となりました。また、事前録画形式になったことで発表の構成がよく練られ、結果として聞きやすく（皆様かなり気をつけてゆっくり発声されていました）、個性のある発表が多かったように思います。 今回、初のオンラインでの開催ということで、運営委員会の皆様もいろいろと苦労されていらっしゃるようでした。ただ、その甲斐あってか当日の進行はスムーズで、会場はとても盛り上がっていました。関係者の皆様、本当にお疲れ様でした。 情勢を踏まえ、来年度の開催可否・形式は未定とのことでしたが、オンライン・対面のそれぞれの良さを取り入れつつ、より多くの人が参加できる形態になっているとよいなと思います。 公式 YouTube チャンネル で過去の発表を視聴できますので、ご興味のある方はぜひどうぞ（今年の発表分も一ヶ月ほどしたら公開されるとのことでした）。 またメドレーでは iOS / Android ネイティブアプリ開発エンジニアを募集しています。興味がある方、ぜひお気軽にお話しましょう! www.medley.jp

皆様こんにちは。インキュベーション本部エンジニアの濱中です。 9/19〜21 に iOSDC Japan 2020 （以下 iOSDC）が開催されました。 先日の記事 の通り、メドレーは 2017 年より iOSDC に 協賛 しております。 メドレーでは、Swift を利用してオンライン診療／服薬指導アプリ「CLINICS」iOS 版の開発をしています。 CLINICS(クリニクス)　オンライン診療・服薬指導アプリ 5 回目となる今回は、初のオンライン開催となり、主にニコニコ生放送、Discord 上で発表・コミュニケーションが行われました。私が iOS 版 CLINICS の開発に携わっている縁で、今回スポンサー枠として iOSDC に参加させていただきましたので紹介させていただきます。 イベント全体について オンライン開催となったため、会場の様子や企業ブースなど、雰囲気の伝わる写真をお届けできないのが残念ですが、発表の主会場となったニコニコ生放送では、終始穏やかな雰囲気でありつつも活発にコメントがなされ、大いに盛り上がっていました。 前回同様、初日は day 0 として夕方から、2 日目以降は朝〜夕方まで、最大 5 つのチャンネルで並行して発表が行われました。セッションについては事前に録画したものを放送し、LT のみリモートにてリアルタイム発表という形式となっていました。 質疑応答については、各発表の終了直後に Discord チャンネルに発表者が待機して対応していました。初のオンライン開催ということで、イントロダクション動画をはじめとし、各所で積極的なフィードバック・コミュニケーションが奨励されていたように思います（なお、イントロダクション・スポンサー紹介の各動画はナレーションが声優の緒方恵美さん・三石琴乃さんと、とても豪華でした。生放送中のコメントや、 18 年の弊社ブログ を見る限りは毎年恒例のようですね。すごいです！）。 セッションについて 昨年 iOS13 とともに発表された SwiftUI への移行や、コード移行・モジュール分割等、プロジェクトの最適化についてのトピックが多かったように思います。 SwiftUI は、従来 Storyboard で設計していた UI をコードベースで記述できる画期的なフレームワークですが、SwiftUI を使ったアプリは iOS13 未満の端末では利用できなくなってしまうこともあり、アプリの公開対象を広めにもっておきたい場合はなかなか乗り換えづらい印象でした。2020 年 6 月現在で iOS13 のシェアが 9 割以上となったことで、ちょうど iOSDC での発表トピックを決めるころに導入作業を行った（かつ苦労した）というケースが多かったのかな、と思います。 以下、視聴したセッションのうち気になったものをいくつかご紹介いたします。 オープンソースの AltSwiftUI の発表 fortee.jp 楽天のエンジニアの方による、SwiftUI の提供するネイティブコンポーネントに対応しつつ、iOS11 以上で利用可能なオープンソースのフレームワーク AltSwiftUI （ 公式 Doc ）の開発についてのセッションでした。 iOS12 以下の対応を切らずに SwiftUI への乗り換えを進められる（かつ本家と違ってオープンソースである）便利さもそうですが、別途フレームワークが出来上がってしまうあたりに、SwiftUI への移行対応への苦労がしのばれる内容でもありました（ストアにある楽天提供の iOS アプリの数を考えると乗り換えコストが大変そう…）。 「それ、自動化できますよ」: note を支えるワークフロー大全 speakerdeck.com 改修要望が上がってから、実際に改修を行ってアプリをリリースするまでの作業をできる限り自動化した、というセッションです。CLINICS でも、「証明書の有効期限確認、プッシュからのテスト、マージからのリリース準備」は Bitrise のトリガを利用して自動化しています。 上記のような、GitHub 上でのアクション（プッシュ、マージなど）をトリガとする自動化はよく聞く話ではあるのですが、Slack のポストに特定のスタンプつけると Issue 化、はちょっと目新しくて面白いなと思いました（気をつけないと表記揺れで同じような Issue が乱立しそうですが）。 Issue もきちんと管理しておかないとトラブルの起きやすい部分ですよね。起票者と実装者の間でボールが浮いてしまったり、プロジェクトに紐づいていなかったために対応から洩れてしまったり…。 また、このスライドですが終始手書きの挿絵がかわいくて、そういった意味でもコメント欄が盛り上がっていたのが印象的でした。 100 人でアプリをリファクタリングして見えてきた、最強の iOS アプリ設計に求められること fortee.jp アプリを長期に運用していくとほぼ必須となる課題でありながら、人ごとに基準が曖昧だったり、機能開発におされて対応が後手後手になったり…と、何かとつらい話をよく聞くソースコードのリファクタリングに関するセッションでした。 同じ状態のソースコードを多数のエンジニアがリファクタした結果を比較することで、「良いリファクタリングのための考え方」とは何か？を模索した内容です。 ビューとロジックの分割をしっかり行う、というのは PR レビューでエンジニアが口を酸っぱくしてよく言われることではありますが、「ロジックの中でも、アプリの仕様に依存するものとそうでない普遍的なものは分離すべき」というアイデアは個人的には眼から鱗が落ちるものでした。 また、これを説明するリバーシの具体例（「対戦相手が人間か AI か」はアプリ仕様に依存するロジック、「そこに石を置けるか」は普遍的なロジック＝リバーシのルールそのもの）も非常にわかりやすかったです。 そのほか、React / Redux でフロントエンド開発を行っている人にはお馴染みの Action / Reducer を使った単一方向のデータフローの導入なども紹介されています。 新規機能開発からモジュール分割を始めてみる speakerdeck.com 一つのアプリが長期間運用されていくなかで、複数の機能が統合されたスーパーアプリになることがあります。そうなった場合、ソースコードが肥大化 → ビルド・テストも長大化、となってメンテナンス性が低下するため、対策としてコードを分割してテストやビルドの単位を小さくする必要があります。 いきなりアプリ全体をモジュールに分割するのは時間がかかるため、本セッションではまず第一段階として新規に開発する機能を別モジュールとして実装し、その時得た知見について触れられていました。 「分割したモジュール側でのサードパーティ製フレームワークのリンク方法（※リンクを正しく行わないと、ビルドして動作はするのにアーカイブに失敗してリリースできなくなる）」などは、今後の開発にモジュール分割を取り入れていく際に参考になりそうです。 Swift で始める静的解析 speakerdeck.com Swift ソースコードからの構文木の生成、解析を行うライブラリ SwiftSyntax の紹介と、それを用いたソースコード重複検出機能の実装についてのセッションでした。 普段 Xcode を始めとした IDE で開発していると、コード重複、不要なローカル変数、型や Nullable の不一致に変数リファクタリング…等々の便利な機能を気軽に使えてしまいますが、その裏の動作を改めて一つずつ具体的に追っていくと、そのありがたみが身に染みます…。 静的解析そのものは Swift に限らず様々な言語のソースコードに対して適用できるトピックではあるのですが、普段何気なく使ってしまう IDE の機能について考えるよい機会になったため、紹介させていただきました。 まとめ ちょうど業務でも iOS アプリ開発を担当していることもあり、興味深い知見が得られ、よい経験となりました。また、事前録画形式になったことで発表の構成がよく練られ、結果として聞きやすく（皆様かなり気をつけてゆっくり発声されていました）、個性のある発表が多かったように思います。 今回、初のオンラインでの開催ということで、運営委員会の皆様もいろいろと苦労されていらっしゃるようでした。ただ、その甲斐あってか当日の進行はスムーズで、会場はとても盛り上がっていました。関係者の皆様、本当にお疲れ様でした。 情勢を踏まえ、来年度の開催可否・形式は未定とのことでしたが、オンライン・対面のそれぞれの良さを取り入れつつ、より多くの人が参加できる形態になっているとよいなと思います。 公式 YouTube チャンネル で過去の発表を視聴できますので、ご興味のある方はぜひどうぞ（今年の発表分も一ヶ月ほどしたら公開されるとのことでした）。 またメドレーでは iOS / Android ネイティブアプリ開発エンジニアを募集しています。興味がある方、ぜひお気軽にお話しましょう! www.medley.jp

皆様こんにちは。インキュベーション本部エンジニアの濱中です。 9/19〜21 に iOSDC Japan 2020 （以下 iOSDC）が開催されました。 先日の記事 の通り、メドレーは 2017 年より iOSDC に 協賛 しております。 メドレーでは、Swift を利用してオンライン診療／服薬指導アプリ「CLINICS」iOS 版の開発をしています。 CLINICS(クリニクス)　オンライン診療・服薬指導アプリ 5 回目となる今回は、初のオンライン開催となり、主にニコニコ生放送、Discord 上で発表・コミュニケーションが行われました。私が iOS 版 CLINICS の開発に携わっている縁で、今回スポンサー枠として iOSDC に参加させていただきましたので紹介させていただきます。 イベント全体について オンライン開催となったため、会場の様子や企業ブースなど、雰囲気の伝わる写真をお届けできないのが残念ですが、発表の主会場となったニコニコ生放送では、終始穏やかな雰囲気でありつつも活発にコメントがなされ、大いに盛り上がっていました。 前回同様、初日は day 0 として夕方から、2 日目以降は朝〜夕方まで、最大 5 つのチャンネルで並行して発表が行われました。セッションについては事前に録画したものを放送し、LT のみリモートにてリアルタイム発表という形式となっていました。 質疑応答については、各発表の終了直後に Discord チャンネルに発表者が待機して対応していました。初のオンライン開催ということで、イントロダクション動画をはじめとし、各所で積極的なフィードバック・コミュニケーションが奨励されていたように思います（なお、イントロダクション・スポンサー紹介の各動画はナレーションが声優の緒方恵美さん・三石琴乃さんと、とても豪華でした。生放送中のコメントや、 18 年の弊社ブログ を見る限りは毎年恒例のようですね。すごいです！）。 セッションについて 昨年 iOS13 とともに発表された SwiftUI への移行や、コード移行・モジュール分割等、プロジェクトの最適化についてのトピックが多かったように思います。 SwiftUI は、従来 Storyboard で設計していた UI をコードベースで記述できる画期的なフレームワークですが、SwiftUI を使ったアプリは iOS13 未満の端末では利用できなくなってしまうこともあり、アプリの公開対象を広めにもっておきたい場合はなかなか乗り換えづらい印象でした。2020 年 6 月現在で iOS13 のシェアが 9 割以上となったことで、ちょうど iOSDC での発表トピックを決めるころに導入作業を行った（かつ苦労した）というケースが多かったのかな、と思います。 以下、視聴したセッションのうち気になったものをいくつかご紹介いたします。 オープンソースの AltSwiftUI の発表 fortee.jp 楽天のエンジニアの方による、SwiftUI の提供するネイティブコンポーネントに対応しつつ、iOS11 以上で利用可能なオープンソースのフレームワーク AltSwiftUI （ 公式 Doc ）の開発についてのセッションでした。 iOS12 以下の対応を切らずに SwiftUI への乗り換えを進められる（かつ本家と違ってオープンソースである）便利さもそうですが、別途フレームワークが出来上がってしまうあたりに、SwiftUI への移行対応への苦労がしのばれる内容でもありました（ストアにある楽天提供の iOS アプリの数を考えると乗り換えコストが大変そう…）。 「それ、自動化できますよ」: note を支えるワークフロー大全 speakerdeck.com 改修要望が上がってから、実際に改修を行ってアプリをリリースするまでの作業をできる限り自動化した、というセッションです。CLINICS でも、「証明書の有効期限確認、プッシュからのテスト、マージからのリリース準備」は Bitrise のトリガを利用して自動化しています。 上記のような、GitHub 上でのアクション（プッシュ、マージなど）をトリガとする自動化はよく聞く話ではあるのですが、Slack のポストに特定のスタンプつけると Issue 化、はちょっと目新しくて面白いなと思いました（気をつけないと表記揺れで同じような Issue が乱立しそうですが）。 Issue もきちんと管理しておかないとトラブルの起きやすい部分ですよね。起票者と実装者の間でボールが浮いてしまったり、プロジェクトに紐づいていなかったために対応から洩れてしまったり…。 また、このスライドですが終始手書きの挿絵がかわいくて、そういった意味でもコメント欄が盛り上がっていたのが印象的でした。 100 人でアプリをリファクタリングして見えてきた、最強の iOS アプリ設計に求められること fortee.jp アプリを長期に運用していくとほぼ必須となる課題でありながら、人ごとに基準が曖昧だったり、機能開発におされて対応が後手後手になったり…と、何かとつらい話をよく聞くソースコードのリファクタリングに関するセッションでした。 同じ状態のソースコードを多数のエンジニアがリファクタした結果を比較することで、「良いリファクタリングのための考え方」とは何か？を模索した内容です。 ビューとロジックの分割をしっかり行う、というのは PR レビューでエンジニアが口を酸っぱくしてよく言われることではありますが、「ロジックの中でも、アプリの仕様に依存するものとそうでない普遍的なものは分離すべき」というアイデアは個人的には眼から鱗が落ちるものでした。 また、これを説明するリバーシの具体例（「対戦相手が人間か AI か」はアプリ仕様に依存するロジック、「そこに石を置けるか」は普遍的なロジック＝リバーシのルールそのもの）も非常にわかりやすかったです。 そのほか、React / Redux でフロントエンド開発を行っている人にはお馴染みの Action / Reducer を使った単一方向のデータフローの導入なども紹介されています。 新規機能開発からモジュール分割を始めてみる speakerdeck.com 一つのアプリが長期間運用されていくなかで、複数の機能が統合されたスーパーアプリになることがあります。そうなった場合、ソースコードが肥大化 → ビルド・テストも長大化、となってメンテナンス性が低下するため、対策としてコードを分割してテストやビルドの単位を小さくする必要があります。 いきなりアプリ全体をモジュールに分割するのは時間がかかるため、本セッションではまず第一段階として新規に開発する機能を別モジュールとして実装し、その時得た知見について触れられていました。 「分割したモジュール側でのサードパーティ製フレームワークのリンク方法（※リンクを正しく行わないと、ビルドして動作はするのにアーカイブに失敗してリリースできなくなる）」などは、今後の開発にモジュール分割を取り入れていく際に参考になりそうです。 Swift で始める静的解析 speakerdeck.com Swift ソースコードからの構文木の生成、解析を行うライブラリ SwiftSyntax の紹介と、それを用いたソースコード重複検出機能の実装についてのセッションでした。 普段 Xcode を始めとした IDE で開発していると、コード重複、不要なローカル変数、型や Nullable の不一致に変数リファクタリング…等々の便利な機能を気軽に使えてしまいますが、その裏の動作を改めて一つずつ具体的に追っていくと、そのありがたみが身に染みます…。 静的解析そのものは Swift に限らず様々な言語のソースコードに対して適用できるトピックではあるのですが、普段何気なく使ってしまう IDE の機能について考えるよい機会になったため、紹介させていただきました。 まとめ ちょうど業務でも iOS アプリ開発を担当していることもあり、興味深い知見が得られ、よい経験となりました。また、事前録画形式になったことで発表の構成がよく練られ、結果として聞きやすく（皆様かなり気をつけてゆっくり発声されていました）、個性のある発表が多かったように思います。 今回、初のオンラインでの開催ということで、運営委員会の皆様もいろいろと苦労されていらっしゃるようでした。ただ、その甲斐あってか当日の進行はスムーズで、会場はとても盛り上がっていました。関係者の皆様、本当にお疲れ様でした。 情勢を踏まえ、来年度の開催可否・形式は未定とのことでしたが、オンライン・対面のそれぞれの良さを取り入れつつ、より多くの人が参加できる形態になっているとよいなと思います。 公式 YouTube チャンネル で過去の発表を視聴できますので、ご興味のある方はぜひどうぞ（今年の発表分も一ヶ月ほどしたら公開されるとのことでした）。 またメドレーでは iOS / Android ネイティブアプリ開発エンジニアを募集しています。興味がある方、ぜひお気軽にお話しましょう! www.medley.jp

皆様こんにちは。インキュベーション本部エンジニアの濱中です。 9/19〜21 に iOSDC Japan 2020 （以下 iOSDC）が開催されました。 先日の記事 の通り、メドレーは 2017 年より iOSDC に 協賛 しております。 メドレーでは、Swift を利用してオンライン診療／服薬指導アプリ「CLINICS」iOS 版の開発をしています。 CLINICS(クリニクス)　オンライン診療・服薬指導アプリ 5 回目となる今回は、初のオンライン開催となり、主にニコニコ生放送、Discord 上で発表・コミュニケーションが行われました。私が iOS 版 CLINICS の開発に携わっている縁で、今回スポンサー枠として iOSDC に参加させていただきましたので紹介させていただきます。 イベント全体について オンライン開催となったため、会場の様子や企業ブースなど、雰囲気の伝わる写真をお届けできないのが残念ですが、発表の主会場となったニコニコ生放送では、終始穏やかな雰囲気でありつつも活発にコメントがなされ、大いに盛り上がっていました。 前回同様、初日は day 0 として夕方から、2 日目以降は朝〜夕方まで、最大 5 つのチャンネルで並行して発表が行われました。セッションについては事前に録画したものを放送し、LT のみリモートにてリアルタイム発表という形式となっていました。 質疑応答については、各発表の終了直後に Discord チャンネルに発表者が待機して対応していました。初のオンライン開催ということで、イントロダクション動画をはじめとし、各所で積極的なフィードバック・コミュニケーションが奨励されていたように思います（なお、イントロダクション・スポンサー紹介の各動画はナレーションが声優の緒方恵美さん・三石琴乃さんと、とても豪華でした。生放送中のコメントや、 18 年の弊社ブログ を見る限りは毎年恒例のようですね。すごいです！）。 セッションについて 昨年 iOS13 とともに発表された SwiftUI への移行や、コード移行・モジュール分割等、プロジェクトの最適化についてのトピックが多かったように思います。 SwiftUI は、従来 Storyboard で設計していた UI をコードベースで記述できる画期的なフレームワークですが、SwiftUI を使ったアプリは iOS13 未満の端末では利用できなくなってしまうこともあり、アプリの公開対象を広めにもっておきたい場合はなかなか乗り換えづらい印象でした。2020 年 6 月現在で iOS13 のシェアが 9 割以上となったことで、ちょうど iOSDC での発表トピックを決めるころに導入作業を行った（かつ苦労した）というケースが多かったのかな、と思います。 以下、視聴したセッションのうち気になったものをいくつかご紹介いたします。 オープンソースの AltSwiftUI の発表 fortee.jp 楽天のエンジニアの方による、SwiftUI の提供するネイティブコンポーネントに対応しつつ、iOS11 以上で利用可能なオープンソースのフレームワーク AltSwiftUI （ 公式 Doc ）の開発についてのセッションでした。 iOS12 以下の対応を切らずに SwiftUI への乗り換えを進められる（かつ本家と違ってオープンソースである）便利さもそうですが、別途フレームワークが出来上がってしまうあたりに、SwiftUI への移行対応への苦労がしのばれる内容でもありました（ストアにある楽天提供の iOS アプリの数を考えると乗り換えコストが大変そう…）。 「それ、自動化できますよ」: note を支えるワークフロー大全 speakerdeck.com 改修要望が上がってから、実際に改修を行ってアプリをリリースするまでの作業をできる限り自動化した、というセッションです。CLINICS でも、「証明書の有効期限確認、プッシュからのテスト、マージからのリリース準備」は Bitrise のトリガを利用して自動化しています。 上記のような、GitHub 上でのアクション（プッシュ、マージなど）をトリガとする自動化はよく聞く話ではあるのですが、Slack のポストに特定のスタンプつけると Issue 化、はちょっと目新しくて面白いなと思いました（気をつけないと表記揺れで同じような Issue が乱立しそうですが）。 Issue もきちんと管理しておかないとトラブルの起きやすい部分ですよね。起票者と実装者の間でボールが浮いてしまったり、プロジェクトに紐づいていなかったために対応から洩れてしまったり…。 また、このスライドですが終始手書きの挿絵がかわいくて、そういった意味でもコメント欄が盛り上がっていたのが印象的でした。 100 人でアプリをリファクタリングして見えてきた、最強の iOS アプリ設計に求められること fortee.jp アプリを長期に運用していくとほぼ必須となる課題でありながら、人ごとに基準が曖昧だったり、機能開発におされて対応が後手後手になったり…と、何かとつらい話をよく聞くソースコードのリファクタリングに関するセッションでした。 同じ状態のソースコードを多数のエンジニアがリファクタした結果を比較することで、「良いリファクタリングのための考え方」とは何か？を模索した内容です。 ビューとロジックの分割をしっかり行う、というのは PR レビューでエンジニアが口を酸っぱくしてよく言われることではありますが、「ロジックの中でも、アプリの仕様に依存するものとそうでない普遍的なものは分離すべき」というアイデアは個人的には眼から鱗が落ちるものでした。 また、これを説明するリバーシの具体例（「対戦相手が人間か AI か」はアプリ仕様に依存するロジック、「そこに石を置けるか」は普遍的なロジック＝リバーシのルールそのもの）も非常にわかりやすかったです。 そのほか、React / Redux でフロントエンド開発を行っている人にはお馴染みの Action / Reducer を使った単一方向のデータフローの導入なども紹介されています。 新規機能開発からモジュール分割を始めてみる speakerdeck.com 一つのアプリが長期間運用されていくなかで、複数の機能が統合されたスーパーアプリになることがあります。そうなった場合、ソースコードが肥大化 → ビルド・テストも長大化、となってメンテナンス性が低下するため、対策としてコードを分割してテストやビルドの単位を小さくする必要があります。 いきなりアプリ全体をモジュールに分割するのは時間がかかるため、本セッションではまず第一段階として新規に開発する機能を別モジュールとして実装し、その時得た知見について触れられていました。 「分割したモジュール側でのサードパーティ製フレームワークのリンク方法（※リンクを正しく行わないと、ビルドして動作はするのにアーカイブに失敗してリリースできなくなる）」などは、今後の開発にモジュール分割を取り入れていく際に参考になりそうです。 Swift で始める静的解析 speakerdeck.com Swift ソースコードからの構文木の生成、解析を行うライブラリ SwiftSyntax の紹介と、それを用いたソースコード重複検出機能の実装についてのセッションでした。 普段 Xcode を始めとした IDE で開発していると、コード重複、不要なローカル変数、型や Nullable の不一致に変数リファクタリング…等々の便利な機能を気軽に使えてしまいますが、その裏の動作を改めて一つずつ具体的に追っていくと、そのありがたみが身に染みます…。 静的解析そのものは Swift に限らず様々な言語のソースコードに対して適用できるトピックではあるのですが、普段何気なく使ってしまう IDE の機能について考えるよい機会になったため、紹介させていただきました。 まとめ ちょうど業務でも iOS アプリ開発を担当していることもあり、興味深い知見が得られ、よい経験となりました。また、事前録画形式になったことで発表の構成がよく練られ、結果として聞きやすく（皆様かなり気をつけてゆっくり発声されていました）、個性のある発表が多かったように思います。 今回、初のオンラインでの開催ということで、運営委員会の皆様もいろいろと苦労されていらっしゃるようでした。ただ、その甲斐あってか当日の進行はスムーズで、会場はとても盛り上がっていました。関係者の皆様、本当にお疲れ様でした。 情勢を踏まえ、来年度の開催可否・形式は未定とのことでしたが、オンライン・対面のそれぞれの良さを取り入れつつ、より多くの人が参加できる形態になっているとよいなと思います。 公式 YouTube チャンネル で過去の発表を視聴できますので、ご興味のある方はぜひどうぞ（今年の発表分も一ヶ月ほどしたら公開されるとのことでした）。 またメドレーでは iOS / Android ネイティブアプリ開発エンジニアを募集しています。興味がある方、ぜひお気軽にお話しましょう! www.medley.jp

皆様こんにちは。インキュベーション本部エンジニアの濱中です。 9/19〜21 に iOSDC Japan 2020 （以下 iOSDC）が開催されました。 先日の記事 の通り、メドレーは 2017 年より iOSDC に 協賛 しております。 メドレーでは、Swift を利用してオンライン診療／服薬指導アプリ「CLINICS」iOS 版の開発をしています。 CLINICS(クリニクス)　オンライン診療・服薬指導アプリ 5 回目となる今回は、初のオンライン開催となり、主にニコニコ生放送、Discord 上で発表・コミュニケーションが行われました。私が iOS 版 CLINICS の開発に携わっている縁で、今回スポンサー枠として iOSDC に参加させていただきましたので紹介させていただきます。 イベント全体について オンライン開催となったため、会場の様子や企業ブースなど、雰囲気の伝わる写真をお届けできないのが残念ですが、発表の主会場となったニコニコ生放送では、終始穏やかな雰囲気でありつつも活発にコメントがなされ、大いに盛り上がっていました。 前回同様、初日は day 0 として夕方から、2 日目以降は朝〜夕方まで、最大 5 つのチャンネルで並行して発表が行われました。セッションについては事前に録画したものを放送し、LT のみリモートにてリアルタイム発表という形式となっていました。 質疑応答については、各発表の終了直後に Discord チャンネルに発表者が待機して対応していました。初のオンライン開催ということで、イントロダクション動画をはじめとし、各所で積極的なフィードバック・コミュニケーションが奨励されていたように思います（なお、イントロダクション・スポンサー紹介の各動画はナレーションが声優の緒方恵美さん・三石琴乃さんと、とても豪華でした。生放送中のコメントや、 18 年の弊社ブログ を見る限りは毎年恒例のようですね。すごいです！）。 セッションについて 昨年 iOS13 とともに発表された SwiftUI への移行や、コード移行・モジュール分割等、プロジェクトの最適化についてのトピックが多かったように思います。 SwiftUI は、従来 Storyboard で設計していた UI をコードベースで記述できる画期的なフレームワークですが、SwiftUI を使ったアプリは iOS13 未満の端末では利用できなくなってしまうこともあり、アプリの公開対象を広めにもっておきたい場合はなかなか乗り換えづらい印象でした。2020 年 6 月現在で iOS13 のシェアが 9 割以上となったことで、ちょうど iOSDC での発表トピックを決めるころに導入作業を行った（かつ苦労した）というケースが多かったのかな、と思います。 以下、視聴したセッションのうち気になったものをいくつかご紹介いたします。 オープンソースの AltSwiftUI の発表 fortee.jp 楽天のエンジニアの方による、SwiftUI の提供するネイティブコンポーネントに対応しつつ、iOS11 以上で利用可能なオープンソースのフレームワーク AltSwiftUI （ 公式 Doc ）の開発についてのセッションでした。 iOS12 以下の対応を切らずに SwiftUI への乗り換えを進められる（かつ本家と違ってオープンソースである）便利さもそうですが、別途フレームワークが出来上がってしまうあたりに、SwiftUI への移行対応への苦労がしのばれる内容でもありました（ストアにある楽天提供の iOS アプリの数を考えると乗り換えコストが大変そう…）。 「それ、自動化できますよ」: note を支えるワークフロー大全 speakerdeck.com 改修要望が上がってから、実際に改修を行ってアプリをリリースするまでの作業をできる限り自動化した、というセッションです。CLINICS でも、「証明書の有効期限確認、プッシュからのテスト、マージからのリリース準備」は Bitrise のトリガを利用して自動化しています。 上記のような、GitHub 上でのアクション（プッシュ、マージなど）をトリガとする自動化はよく聞く話ではあるのですが、Slack のポストに特定のスタンプつけると Issue 化、はちょっと目新しくて面白いなと思いました（気をつけないと表記揺れで同じような Issue が乱立しそうですが）。 Issue もきちんと管理しておかないとトラブルの起きやすい部分ですよね。起票者と実装者の間でボールが浮いてしまったり、プロジェクトに紐づいていなかったために対応から洩れてしまったり…。 また、このスライドですが終始手書きの挿絵がかわいくて、そういった意味でもコメント欄が盛り上がっていたのが印象的でした。 100 人でアプリをリファクタリングして見えてきた、最強の iOS アプリ設計に求められること fortee.jp アプリを長期に運用していくとほぼ必須となる課題でありながら、人ごとに基準が曖昧だったり、機能開発におされて対応が後手後手になったり…と、何かとつらい話をよく聞くソースコードのリファクタリングに関するセッションでした。 同じ状態のソースコードを多数のエンジニアがリファクタした結果を比較することで、「良いリファクタリングのための考え方」とは何か？を模索した内容です。 ビューとロジックの分割をしっかり行う、というのは PR レビューでエンジニアが口を酸っぱくしてよく言われることではありますが、「ロジックの中でも、アプリの仕様に依存するものとそうでない普遍的なものは分離すべき」というアイデアは個人的には眼から鱗が落ちるものでした。 また、これを説明するリバーシの具体例（「対戦相手が人間か AI か」はアプリ仕様に依存するロジック、「そこに石を置けるか」は普遍的なロジック＝リバーシのルールそのもの）も非常にわかりやすかったです。 そのほか、React / Redux でフロントエンド開発を行っている人にはお馴染みの Action / Reducer を使った単一方向のデータフローの導入なども紹介されています。 新規機能開発からモジュール分割を始めてみる speakerdeck.com 一つのアプリが長期間運用されていくなかで、複数の機能が統合されたスーパーアプリになることがあります。そうなった場合、ソースコードが肥大化 → ビルド・テストも長大化、となってメンテナンス性が低下するため、対策としてコードを分割してテストやビルドの単位を小さくする必要があります。 いきなりアプリ全体をモジュールに分割するのは時間がかかるため、本セッションではまず第一段階として新規に開発する機能を別モジュールとして実装し、その時得た知見について触れられていました。 「分割したモジュール側でのサードパーティ製フレームワークのリンク方法（※リンクを正しく行わないと、ビルドして動作はするのにアーカイブに失敗してリリースできなくなる）」などは、今後の開発にモジュール分割を取り入れていく際に参考になりそうです。 Swift で始める静的解析 speakerdeck.com Swift ソースコードからの構文木の生成、解析を行うライブラリ SwiftSyntax の紹介と、それを用いたソースコード重複検出機能の実装についてのセッションでした。 普段 Xcode を始めとした IDE で開発していると、コード重複、不要なローカル変数、型や Nullable の不一致に変数リファクタリング…等々の便利な機能を気軽に使えてしまいますが、その裏の動作を改めて一つずつ具体的に追っていくと、そのありがたみが身に染みます…。 静的解析そのものは Swift に限らず様々な言語のソースコードに対して適用できるトピックではあるのですが、普段何気なく使ってしまう IDE の機能について考えるよい機会になったため、紹介させていただきました。 まとめ ちょうど業務でも iOS アプリ開発を担当していることもあり、興味深い知見が得られ、よい経験となりました。また、事前録画形式になったことで発表の構成がよく練られ、結果として聞きやすく（皆様かなり気をつけてゆっくり発声されていました）、個性のある発表が多かったように思います。 今回、初のオンラインでの開催ということで、運営委員会の皆様もいろいろと苦労されていらっしゃるようでした。ただ、その甲斐あってか当日の進行はスムーズで、会場はとても盛り上がっていました。関係者の皆様、本当にお疲れ様でした。 情勢を踏まえ、来年度の開催可否・形式は未定とのことでしたが、オンライン・対面のそれぞれの良さを取り入れつつ、より多くの人が参加できる形態になっているとよいなと思います。 公式 YouTube チャンネル で過去の発表を視聴できますので、ご興味のある方はぜひどうぞ（今年の発表分も一ヶ月ほどしたら公開されるとのことでした）。 またメドレーでは iOS / Android ネイティブアプリ開発エンジニアを募集しています。興味がある方、ぜひお気軽にお話しましょう! www.medley.jp

皆様こんにちは。インキュベーション本部エンジニアの濱中です。 9/19〜21 に iOSDC Japan 2020 （以下 iOSDC）が開催されました。 先日の記事 の通り、メドレーは 2017 年より iOSDC に 協賛 しております。 メドレーでは、Swift を利用してオンライン診療／服薬指導アプリ「CLINICS」iOS 版の開発をしています。 CLINICS(クリニクス)　オンライン診療・服薬指導アプリ 5 回目となる今回は、初のオンライン開催となり、主にニコニコ生放送、Discord 上で発表・コミュニケーションが行われました。私が iOS 版 CLINICS の開発に携わっている縁で、今回スポンサー枠として iOSDC に参加させていただきましたので紹介させていただきます。 イベント全体について オンライン開催となったため、会場の様子や企業ブースなど、雰囲気の伝わる写真をお届けできないのが残念ですが、発表の主会場となったニコニコ生放送では、終始穏やかな雰囲気でありつつも活発にコメントがなされ、大いに盛り上がっていました。 前回同様、初日は day 0 として夕方から、2 日目以降は朝〜夕方まで、最大 5 つのチャンネルで並行して発表が行われました。セッションについては事前に録画したものを放送し、LT のみリモートにてリアルタイム発表という形式となっていました。 質疑応答については、各発表の終了直後に Discord チャンネルに発表者が待機して対応していました。初のオンライン開催ということで、イントロダクション動画をはじめとし、各所で積極的なフィードバック・コミュニケーションが奨励されていたように思います（なお、イントロダクション・スポンサー紹介の各動画はナレーションが声優の緒方恵美さん・三石琴乃さんと、とても豪華でした。生放送中のコメントや、 18 年の弊社ブログ を見る限りは毎年恒例のようですね。すごいです！）。 セッションについて 昨年 iOS13 とともに発表された SwiftUI への移行や、コード移行・モジュール分割等、プロジェクトの最適化についてのトピックが多かったように思います。 SwiftUI は、従来 Storyboard で設計していた UI をコードベースで記述できる画期的なフレームワークですが、SwiftUI を使ったアプリは iOS13 未満の端末では利用できなくなってしまうこともあり、アプリの公開対象を広めにもっておきたい場合はなかなか乗り換えづらい印象でした。2020 年 6 月現在で iOS13 のシェアが 9 割以上となったことで、ちょうど iOSDC での発表トピックを決めるころに導入作業を行った（かつ苦労した）というケースが多かったのかな、と思います。 以下、視聴したセッションのうち気になったものをいくつかご紹介いたします。 オープンソースの AltSwiftUI の発表 fortee.jp 楽天のエンジニアの方による、SwiftUI の提供するネイティブコンポーネントに対応しつつ、iOS11 以上で利用可能なオープンソースのフレームワーク AltSwiftUI （ 公式 Doc ）の開発についてのセッションでした。 iOS12 以下の対応を切らずに SwiftUI への乗り換えを進められる（かつ本家と違ってオープンソースである）便利さもそうですが、別途フレームワークが出来上がってしまうあたりに、SwiftUI への移行対応への苦労がしのばれる内容でもありました（ストアにある楽天提供の iOS アプリの数を考えると乗り換えコストが大変そう…）。 「それ、自動化できますよ」: note を支えるワークフロー大全 speakerdeck.com 改修要望が上がってから、実際に改修を行ってアプリをリリースするまでの作業をできる限り自動化した、というセッションです。CLINICS でも、「証明書の有効期限確認、プッシュからのテスト、マージからのリリース準備」は Bitrise のトリガを利用して自動化しています。 上記のような、GitHub 上でのアクション（プッシュ、マージなど）をトリガとする自動化はよく聞く話ではあるのですが、Slack のポストに特定のスタンプつけると Issue 化、はちょっと目新しくて面白いなと思いました（気をつけないと表記揺れで同じような Issue が乱立しそうですが）。 Issue もきちんと管理しておかないとトラブルの起きやすい部分ですよね。起票者と実装者の間でボールが浮いてしまったり、プロジェクトに紐づいていなかったために対応から洩れてしまったり…。 また、このスライドですが終始手書きの挿絵がかわいくて、そういった意味でもコメント欄が盛り上がっていたのが印象的でした。 100 人でアプリをリファクタリングして見えてきた、最強の iOS アプリ設計に求められること fortee.jp アプリを長期に運用していくとほぼ必須となる課題でありながら、人ごとに基準が曖昧だったり、機能開発におされて対応が後手後手になったり…と、何かとつらい話をよく聞くソースコードのリファクタリングに関するセッションでした。 同じ状態のソースコードを多数のエンジニアがリファクタした結果を比較することで、「良いリファクタリングのための考え方」とは何か？を模索した内容です。 ビューとロジックの分割をしっかり行う、というのは PR レビューでエンジニアが口を酸っぱくしてよく言われることではありますが、「ロジックの中でも、アプリの仕様に依存するものとそうでない普遍的なものは分離すべき」というアイデアは個人的には眼から鱗が落ちるものでした。 また、これを説明するリバーシの具体例（「対戦相手が人間か AI か」はアプリ仕様に依存するロジック、「そこに石を置けるか」は普遍的なロジック＝リバーシのルールそのもの）も非常にわかりやすかったです。 そのほか、React / Redux でフロントエンド開発を行っている人にはお馴染みの Action / Reducer を使った単一方向のデータフローの導入なども紹介されています。 新規機能開発からモジュール分割を始めてみる speakerdeck.com 一つのアプリが長期間運用されていくなかで、複数の機能が統合されたスーパーアプリになることがあります。そうなった場合、ソースコードが肥大化 → ビルド・テストも長大化、となってメンテナンス性が低下するため、対策としてコードを分割してテストやビルドの単位を小さくする必要があります。 いきなりアプリ全体をモジュールに分割するのは時間がかかるため、本セッションではまず第一段階として新規に開発する機能を別モジュールとして実装し、その時得た知見について触れられていました。 「分割したモジュール側でのサードパーティ製フレームワークのリンク方法（※リンクを正しく行わないと、ビルドして動作はするのにアーカイブに失敗してリリースできなくなる）」などは、今後の開発にモジュール分割を取り入れていく際に参考になりそうです。 Swift で始める静的解析 speakerdeck.com Swift ソースコードからの構文木の生成、解析を行うライブラリ SwiftSyntax の紹介と、それを用いたソースコード重複検出機能の実装についてのセッションでした。 普段 Xcode を始めとした IDE で開発していると、コード重複、不要なローカル変数、型や Nullable の不一致に変数リファクタリング…等々の便利な機能を気軽に使えてしまいますが、その裏の動作を改めて一つずつ具体的に追っていくと、そのありがたみが身に染みます…。 静的解析そのものは Swift に限らず様々な言語のソースコードに対して適用できるトピックではあるのですが、普段何気なく使ってしまう IDE の機能について考えるよい機会になったため、紹介させていただきました。 まとめ ちょうど業務でも iOS アプリ開発を担当していることもあり、興味深い知見が得られ、よい経験となりました。また、事前録画形式になったことで発表の構成がよく練られ、結果として聞きやすく（皆様かなり気をつけてゆっくり発声されていました）、個性のある発表が多かったように思います。 今回、初のオンラインでの開催ということで、運営委員会の皆様もいろいろと苦労されていらっしゃるようでした。ただ、その甲斐あってか当日の進行はスムーズで、会場はとても盛り上がっていました。関係者の皆様、本当にお疲れ様でした。 情勢を踏まえ、来年度の開催可否・形式は未定とのことでしたが、オンライン・対面のそれぞれの良さを取り入れつつ、より多くの人が参加できる形態になっているとよいなと思います。 公式 YouTube チャンネル で過去の発表を視聴できますので、ご興味のある方はぜひどうぞ（今年の発表分も一ヶ月ほどしたら公開されるとのことでした）。 またメドレーでは iOS / Android ネイティブアプリ開発エンジニアを募集しています。興味がある方、ぜひお気軽にお話しましょう! www.medley.jp

皆様こんにちは。インキュベーション本部エンジニアの濱中です。 9/19〜21 に iOSDC Japan 2020 （以下 iOSDC）が開催されました。 先日の記事 の通り、メドレーは 2017 年より iOSDC に 協賛 しております。 メドレーでは、Swift を利用してオンライン診療／服薬指導アプリ「CLINICS」iOS 版の開発をしています。 CLINICS(クリニクス)　オンライン診療・服薬指導アプリ 5 回目となる今回は、初のオンライン開催となり、主にニコニコ生放送、Discord 上で発表・コミュニケーションが行われました。私が iOS 版 CLINICS の開発に携わっている縁で、今回スポンサー枠として iOSDC に参加させていただきましたので紹介させていただきます。 イベント全体について オンライン開催となったため、会場の様子や企業ブースなど、雰囲気の伝わる写真をお届けできないのが残念ですが、発表の主会場となったニコニコ生放送では、終始穏やかな雰囲気でありつつも活発にコメントがなされ、大いに盛り上がっていました。 前回同様、初日は day 0 として夕方から、2 日目以降は朝〜夕方まで、最大 5 つのチャンネルで並行して発表が行われました。セッションについては事前に録画したものを放送し、LT のみリモートにてリアルタイム発表という形式となっていました。 質疑応答については、各発表の終了直後に Discord チャンネルに発表者が待機して対応していました。初のオンライン開催ということで、イントロダクション動画をはじめとし、各所で積極的なフィードバック・コミュニケーションが奨励されていたように思います（なお、イントロダクション・スポンサー紹介の各動画はナレーションが声優の緒方恵美さん・三石琴乃さんと、とても豪華でした。生放送中のコメントや、 18 年の弊社ブログ を見る限りは毎年恒例のようですね。すごいです！）。 セッションについて 昨年 iOS13 とともに発表された SwiftUI への移行や、コード移行・モジュール分割等、プロジェクトの最適化についてのトピックが多かったように思います。 SwiftUI は、従来 Storyboard で設計していた UI をコードベースで記述できる画期的なフレームワークですが、SwiftUI を使ったアプリは iOS13 未満の端末では利用できなくなってしまうこともあり、アプリの公開対象を広めにもっておきたい場合はなかなか乗り換えづらい印象でした。2020 年 6 月現在で iOS13 のシェアが 9 割以上となったことで、ちょうど iOSDC での発表トピックを決めるころに導入作業を行った（かつ苦労した）というケースが多かったのかな、と思います。 以下、視聴したセッションのうち気になったものをいくつかご紹介いたします。 オープンソースの AltSwiftUI の発表 fortee.jp 楽天のエンジニアの方による、SwiftUI の提供するネイティブコンポーネントに対応しつつ、iOS11 以上で利用可能なオープンソースのフレームワーク AltSwiftUI （ 公式 Doc ）の開発についてのセッションでした。 iOS12 以下の対応を切らずに SwiftUI への乗り換えを進められる（かつ本家と違ってオープンソースである）便利さもそうですが、別途フレームワークが出来上がってしまうあたりに、SwiftUI への移行対応への苦労がしのばれる内容でもありました（ストアにある楽天提供の iOS アプリの数を考えると乗り換えコストが大変そう…）。 「それ、自動化できますよ」: note を支えるワークフロー大全 speakerdeck.com 改修要望が上がってから、実際に改修を行ってアプリをリリースするまでの作業をできる限り自動化した、というセッションです。CLINICS でも、「証明書の有効期限確認、プッシュからのテスト、マージからのリリース準備」は Bitrise のトリガを利用して自動化しています。 上記のような、GitHub 上でのアクション（プッシュ、マージなど）をトリガとする自動化はよく聞く話ではあるのですが、Slack のポストに特定のスタンプつけると Issue 化、はちょっと目新しくて面白いなと思いました（気をつけないと表記揺れで同じような Issue が乱立しそうですが）。 Issue もきちんと管理しておかないとトラブルの起きやすい部分ですよね。起票者と実装者の間でボールが浮いてしまったり、プロジェクトに紐づいていなかったために対応から洩れてしまったり…。 また、このスライドですが終始手書きの挿絵がかわいくて、そういった意味でもコメント欄が盛り上がっていたのが印象的でした。 100 人でアプリをリファクタリングして見えてきた、最強の iOS アプリ設計に求められること fortee.jp アプリを長期に運用していくとほぼ必須となる課題でありながら、人ごとに基準が曖昧だったり、機能開発におされて対応が後手後手になったり…と、何かとつらい話をよく聞くソースコードのリファクタリングに関するセッションでした。 同じ状態のソースコードを多数のエンジニアがリファクタした結果を比較することで、「良いリファクタリングのための考え方」とは何か？を模索した内容です。 ビューとロジックの分割をしっかり行う、というのは PR レビューでエンジニアが口を酸っぱくしてよく言われることではありますが、「ロジックの中でも、アプリの仕様に依存するものとそうでない普遍的なものは分離すべき」というアイデアは個人的には眼から鱗が落ちるものでした。 また、これを説明するリバーシの具体例（「対戦相手が人間か AI か」はアプリ仕様に依存するロジック、「そこに石を置けるか」は普遍的なロジック＝リバーシのルールそのもの）も非常にわかりやすかったです。 そのほか、React / Redux でフロントエンド開発を行っている人にはお馴染みの Action / Reducer を使った単一方向のデータフローの導入なども紹介されています。 新規機能開発からモジュール分割を始めてみる speakerdeck.com 一つのアプリが長期間運用されていくなかで、複数の機能が統合されたスーパーアプリになることがあります。そうなった場合、ソースコードが肥大化 → ビルド・テストも長大化、となってメンテナンス性が低下するため、対策としてコードを分割してテストやビルドの単位を小さくする必要があります。 いきなりアプリ全体をモジュールに分割するのは時間がかかるため、本セッションではまず第一段階として新規に開発する機能を別モジュールとして実装し、その時得た知見について触れられていました。 「分割したモジュール側でのサードパーティ製フレームワークのリンク方法（※リンクを正しく行わないと、ビルドして動作はするのにアーカイブに失敗してリリースできなくなる）」などは、今後の開発にモジュール分割を取り入れていく際に参考になりそうです。 Swift で始める静的解析 speakerdeck.com Swift ソースコードからの構文木の生成、解析を行うライブラリ SwiftSyntax の紹介と、それを用いたソースコード重複検出機能の実装についてのセッションでした。 普段 Xcode を始めとした IDE で開発していると、コード重複、不要なローカル変数、型や Nullable の不一致に変数リファクタリング…等々の便利な機能を気軽に使えてしまいますが、その裏の動作を改めて一つずつ具体的に追っていくと、そのありがたみが身に染みます…。 静的解析そのものは Swift に限らず様々な言語のソースコードに対して適用できるトピックではあるのですが、普段何気なく使ってしまう IDE の機能について考えるよい機会になったため、紹介させていただきました。 まとめ ちょうど業務でも iOS アプリ開発を担当していることもあり、興味深い知見が得られ、よい経験となりました。また、事前録画形式になったことで発表の構成がよく練られ、結果として聞きやすく（皆様かなり気をつけてゆっくり発声されていました）、個性のある発表が多かったように思います。 今回、初のオンラインでの開催ということで、運営委員会の皆様もいろいろと苦労されていらっしゃるようでした。ただ、その甲斐あってか当日の進行はスムーズで、会場はとても盛り上がっていました。関係者の皆様、本当にお疲れ様でした。 情勢を踏まえ、来年度の開催可否・形式は未定とのことでしたが、オンライン・対面のそれぞれの良さを取り入れつつ、より多くの人が参加できる形態になっているとよいなと思います。 公式 YouTube チャンネル で過去の発表を視聴できますので、ご興味のある方はぜひどうぞ（今年の発表分も一ヶ月ほどしたら公開されるとのことでした）。 またメドレーでは iOS / Android ネイティブアプリ開発エンジニアを募集しています。興味がある方、ぜひお気軽にお話しましょう! www.medley.jp