初めまして。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

皆様こんにちは。インキュベーション本部エンジニアの濱中です。 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

こんにちは。 ジョブメドレー の開発チームでエンジニアをしている新居です。 はじめに 2020 年 4 月に、新卒エンジニア 3 名が入社しました。 入社後は新卒エンジニア研修を実施し、先日 8 月 25 日の最終報告会をもって終了しました。 コロナウイルスの影響で入社間もなくフルリモート勤務となり、不慣れなところもありましたが、本年度の研修の取り組みを紹介します。 2020 年度新卒エンジニア 研修の概要 メドレーでは昨年度から新卒エンジニアを迎えており、合わせて研修も開始しました。 初めての研修をどのような視点で計画・実施したかについては、昨年平木がこちらにまとめています。 2019 年度エンジニア新卒の研修について - Medley Developer Blog 今年は人事部のご協力もいただきながら、昨年の内容を少しアップデートして行いました。 研修の目的は、 新卒メンバーが同じ空間で互いに刺激し合いながら、社会人への思考転換をはかり、業務遂行に必要となる基礎知識とスキルを習得すること です。 研修は以下の 4 つのフェーズに区切って行いました。 研修のフェーズ 研修の内容 ここから 4 つのフェーズ毎に内容を紹介します。 フェーズ 1：社会人&メドレー基礎研修 1. オリエンテーション メドレーの事業や組織、大切にしている行動規範などの概要説明 セキュリティ研修とコンプライアンス研修 2. ビジネス研修 ビジネスマナー研修 ビジネススキル研修 ビジネススタンス研修（外部研修） フェーズ 1 では「医療ヘルスケアの未来をつくる」メンバーの一員として大切にして欲しいことを学ぶフェーズでした。 社会人としての最低限のマナーやスタンスは勿論ですが、メドレーで働く上で土台となるマインドをここで学び、 医療ヘルスケア分野の課題を解決する一員 として共にプロダクトを作るためのベースを築けたと思います。 フェーズ 2：エンジニア基礎研修 1. 開発基礎 1 講義「メドレーが求めるエンジニアとは」 ジョブメドレー と CLINICS の事業・プロダクトについての概要説明 Ruby on Rails（以下 Rails）の基礎トレーニング 2. 開発実践 チーム開発体験 3. 開発基礎 2 書籍 『Web を支える技術 -HTTP、URI、HTML、そして REST』 の輪読会 ドキュメンテーション研修とプレゼンテーション研修 中間報告会の準備と実施 フェーズ 2 から開発の研修がスタートしました。 開発基礎 1 開発の研修に入る前に、エンジニアの執行役員 田中から「メドレーが求めるエンジニアとは」というテーマで講義を行いました。メドレーがどういうエンジニアを求めているのか、目指すところの視点合わせを行い、これから行う研修に対する意識や取り組みの質を上げることを目指しました。 メドレーが求めるエンジニア像については CTO 平山の記事にも詳しく書いています。 メドレー平山の中央突破: THE エンジニア その後ジョブメドレーと CLINICS の事業・プロダクトについての概要説明、Rails の基礎トレーニングを行いました。メドレーのプロダクトは Rails 製です。Rails やウェブアプリケーション開発に慣れていない新卒メンバーは、Rails の基礎トレーニングで Ruby on Rails チュートリアル を使って基礎からみっちり学びます。 Ruby on Rails チュートリアルの進め方 ここで大切なことは、漠然とひたすら写経してチュートリアルを進めるのではなく、毎日のフィードバック会でしっかりその日の進捗や学びを共有し、不明点はメンターに質問してもらうようにすることです。 メンターは、新卒メンバーが理解が浅いまま進めてたり、理解していて欲しいところがいい加減になってたり、進め方や学びの方向性がズレてる場合などはアドバイスを入れて軌道修正することを心掛けました。 また「実際の開発ではこうだよ」といった実務を踏まえたアドバイスや、意識していることも伝えていきました。 20 新卒 S さんの感想 「毎日のフィードバック会の中で、その日学んだ技術がジョブメドレーではどのように利用されているのか、どういったことに留意して利用しているのかなどを確認できたので、現場の人の感覚を少しずつ知ることができた。」 新卒メンバーは毎日リズム良く進捗を出し、メンターは新卒メンバーのフォローと引き上げを意識し、成果を最大化できるよう努めました。 開発実践 続いて開発実践ではチーム開発を行いました。前回までは各自個別に進めていましたが、ここではジョブメドレーに関する課題解決を目的としたプロジェクトに対して、チームで向き合う研修でした。 開発実践の目的と達成すべきこと 実務ではチーム開発が基本となり、チームメンバーとの協働は必須です。学生時代に業務レベルのチーム開発を経験しているのは稀ですし、実務に入る前にチームでプロジェクト推進するとはどういうことかを知るのは、とても価値があると思います。 加えて、チームで課題をどう解決していくのかも、新卒メンバー同士で話し合って決める必要があるので、課題解決力も養われたと思います。 今回はプロトタイプを作って成果発表するところまででしたが、プロジェクト推進においてはスケジューリング、要件定義、各種設計、開発フローやコミュニケーションフローの整備、実装、テスト、などなど、やることは尽きません。 また、このプロセスの中で密なコミュニケーションが必要不可欠となるので、新卒メンバー間のチームワークも向上し、お互いのことを更に知ることができたと思います。 この段階で、チームでプロジェクトを推進することの全体感を知り、プロジェクト推進の苦悩苦闘を実体験できたのは大きな経験値になったと思います。 20 新卒 O さんの感想 「各機能の影響を互いに受けないためにブランチを細分化するブランチ戦略や GitHub を用いたコード管理について理解できた。一方で、UI を考える際にチームの各メンバーの認識のズレが生じたことや、序盤は各メンバーの進捗の詳細を把握できていなかったことから報・連・相の重要性を再認識した。」 20 新卒 T さんの感想 「初めてのチーム開発であったことから、実装の序盤は、どのファイルなら編集しても他のメンバーの作業に影響がないのか、動作確認のための画面を作るファイルは自由に作成して良いのか、どのテーブルから関係する他のテーブルの情報を含めた情報を取得をするかなどに悩んでいた。今になって振り返るとチーム内で話せば解決することに対して、技術的にも心理的にも難しさを感じた。」 ###開発基礎 2 フェーズ 2 最後の開発基礎 2 では、書籍 『Web を支える技術 -HTTP、URI、HTML、そして REST』 の輪読会を行いました。もっと前のフェーズでの実施も検討しましたが、開発基礎 1 と開発実践を経た後の方が書籍の内容の納得感が高くなるだろうという判断で、この段階での実施となりました。 その後、中間報告会に向けたドキュメンテーション研修とプレゼンテーション研修を行いました。仕事を進めていく上では、背景や目的を正しくステークホルダーへ共有しながら進めていくことが必要で、伝えたいことを適切に文章として整理し、他者へ分かりやすく伝えていくことが求められます。中間報告会では、そういったことを意識しながらこれまでの研修でやってきたことや成果、学びをレポートにまとめ、プロダクト開発室の室長と副室長、メンター陣の前でプレゼンテーションして報告しました。 フェーズ 3：事業部 OJT 1.代表取締役医師 豊田の講義 日本における医療制度の課題とそれに対するメドレーの位置付けについての講義 2.ジョブメドレー開発 OJT ジョブメドレーの実際の開発 Issue に対応し、ジョブメドレーの開発プロセスを体験 フェーズ 3 の最初は豊田代表の講義を受けました。基礎的な研修を終え、ジョブメドレー開発 OJT に入る前にメドレー社の社会的意義などを改めて代表から伝えていただきました。 続いて、ジョブメドレー開発 OJT は以下の狙いを持って進めました。 ジョブメドレー開発 OJT の狙い 実際に行ったことは、手始めに小さい不具合系 Issue の対応に取り組んだ後、サーバーレスポンス改善の Issue に取り組むというものでした。 サーバーレスポンスの改善は、1 人 1 画面を担当し、「プロファイルツールで分析 → 改善できそうな箇所を調査 → 改善方針の検討 → 提案 → 実装 → レビュー → リリース」というサイクルを回しました。 1 つ目の Issue 対応でも心掛けたことですが、言われたものを実装するのではなく、 ある課題を解決するためにどうしたら良いかを自分で主体的に考えることを重視しました。実装力と同じくらい課題解決力も大切にしているためです。 とはいえ成果が何も出せないというのは、精神衛生上良くないので、日々の朝会と夕会にて進捗や状況をしっかり確認しながら適宜フォローやインプットを行い、ヒントになりそうな過去 Issue のリンクを渡して参考にしてもらったり、メンターの適切なバックアップも必要です。 今回の OJT を通じて実務を知ることで、実際にエンジニアとして仕事をするイメージが沸き、同時に仕事をする上で足りないことも明確になります。自分の課題と向き合うことで、直近の自身の学習プランの軌道修正もできます。 課題は簡単なものではありませんでしたが、最終的に 1 人 1 つ以上のサーバーレスポンス改善 PR をリリースすることができました。 S さんの感想 「速度パフォーマンスの悪いコードに対する嗅覚、オブジェクトを生成しすぎていないか、無駄に通信を走らせていないかなどを学べた。」 O さんの感想 「Issue を本質的に解決するメドレーの開発姿勢について学んだ。Issue を表面的に解決するのではなく、背景や目的、関連するコードなどの不明点を調査し、十分に理解・納得した上で修正することの意識付けができた。また、Issue に関連する一部分のコードを修正すれば良いという狭い視野を持たず、修正による影響範囲を考慮した上で全体の最適化を考えることが重要であると学んだ。」 フェーズ 4：最終報告 1. 最終報告会 最終報告会の準備と実施 最後のフェーズ 4 では、これまでの研修でやってきたことや成果、学びをレポートにまとめ、役員陣の前でプレゼンテーションして報告しました。 役員陣の前なので緊張は最高潮になりますが、自分達が研修を通じて何を得てどう成長したか、今後どういうエンジニアを目指していくのか、などを役員陣の前でアピールする貴重な機会となりました。 1 人 10 分の枠内で役員陣にどういう情報をどういう表現でプレゼンテーションするかを考える機会にもなったので、情報整理力や表現力が培われる場にもなりました。 さいごに 2020 年度の新卒エンジニア研修も無事終了することができました。改めて、新卒メンバーのみなさん、関係者のみなさん本当にお疲れ様でした。 振り返ると、メドレー社員としてのマインドや開発の基本的なことをしっかりインプットしつつ、新卒メンバーが主体的に課題解決に取り組む研修ができたように思います。 必要な技術スタックを 1 から 10 まで懇切丁寧に資料に落とし込み、講義形式で行う研修も身になることは多いですが、 メドレーの研修のような課題解決を実体験する研修はより実務に繋がる実践的な研修だと思います。 少しハードな面もあるかもしれませんが、このような研修を乗り越え、医療ヘルスケア分野の課題解決に取り組みたい学生エンジニアのみなさん、少しでも興味を持っていただけると幸いです。 もちろん中途エンジニアの方もぜひお気軽にお話をしましょう。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。 ジョブメドレー の開発チームでエンジニアをしている新居です。 はじめに 2020 年 4 月に、新卒エンジニア 3 名が入社しました。 入社後は新卒エンジニア研修を実施し、先日 8 月 25 日の最終報告会をもって終了しました。 コロナウイルスの影響で入社間もなくフルリモート勤務となり、不慣れなところもありましたが、本年度の研修の取り組みを紹介します。 2020 年度新卒エンジニア 研修の概要 メドレーでは昨年度から新卒エンジニアを迎えており、合わせて研修も開始しました。 初めての研修をどのような視点で計画・実施したかについては、昨年平木がこちらにまとめています。 2019 年度エンジニア新卒の研修について - Medley Developer Blog 今年は人事部のご協力もいただきながら、昨年の内容を少しアップデートして行いました。 研修の目的は、 新卒メンバーが同じ空間で互いに刺激し合いながら、社会人への思考転換をはかり、業務遂行に必要となる基礎知識とスキルを習得すること です。 研修は以下の 4 つのフェーズに区切って行いました。 研修のフェーズ 研修の内容 ここから 4 つのフェーズ毎に内容を紹介します。 フェーズ 1：社会人&メドレー基礎研修 1. オリエンテーション メドレーの事業や組織、大切にしている行動規範などの概要説明 セキュリティ研修とコンプライアンス研修 2. ビジネス研修 ビジネスマナー研修 ビジネススキル研修 ビジネススタンス研修（外部研修） フェーズ 1 では「医療ヘルスケアの未来をつくる」メンバーの一員として大切にして欲しいことを学ぶフェーズでした。 社会人としての最低限のマナーやスタンスは勿論ですが、メドレーで働く上で土台となるマインドをここで学び、 医療ヘルスケア分野の課題を解決する一員 として共にプロダクトを作るためのベースを築けたと思います。 フェーズ 2：エンジニア基礎研修 1. 開発基礎 1 講義「メドレーが求めるエンジニアとは」 ジョブメドレー と CLINICS の事業・プロダクトについての概要説明 Ruby on Rails（以下 Rails）の基礎トレーニング 2. 開発実践 チーム開発体験 3. 開発基礎 2 書籍 『Web を支える技術 -HTTP、URI、HTML、そして REST』 の輪読会 ドキュメンテーション研修とプレゼンテーション研修 中間報告会の準備と実施 フェーズ 2 から開発の研修がスタートしました。 開発基礎 1 開発の研修に入る前に、エンジニアの執行役員 田中から「メドレーが求めるエンジニアとは」というテーマで講義を行いました。メドレーがどういうエンジニアを求めているのか、目指すところの視点合わせを行い、これから行う研修に対する意識や取り組みの質を上げることを目指しました。 メドレーが求めるエンジニア像については CTO 平山の記事にも詳しく書いています。 メドレー平山の中央突破: THE エンジニア その後ジョブメドレーと CLINICS の事業・プロダクトについての概要説明、Rails の基礎トレーニングを行いました。メドレーのプロダクトは Rails 製です。Rails やウェブアプリケーション開発に慣れていない新卒メンバーは、Rails の基礎トレーニングで Ruby on Rails チュートリアル を使って基礎からみっちり学びます。 Ruby on Rails チュートリアルの進め方 ここで大切なことは、漠然とひたすら写経してチュートリアルを進めるのではなく、毎日のフィードバック会でしっかりその日の進捗や学びを共有し、不明点はメンターに質問してもらうようにすることです。 メンターは、新卒メンバーが理解が浅いまま進めてたり、理解していて欲しいところがいい加減になってたり、進め方や学びの方向性がズレてる場合などはアドバイスを入れて軌道修正することを心掛けました。 また「実際の開発ではこうだよ」といった実務を踏まえたアドバイスや、意識していることも伝えていきました。 20 新卒 S さんの感想 「毎日のフィードバック会の中で、その日学んだ技術がジョブメドレーではどのように利用されているのか、どういったことに留意して利用しているのかなどを確認できたので、現場の人の感覚を少しずつ知ることができた。」 新卒メンバーは毎日リズム良く進捗を出し、メンターは新卒メンバーのフォローと引き上げを意識し、成果を最大化できるよう努めました。 開発実践 続いて開発実践ではチーム開発を行いました。前回までは各自個別に進めていましたが、ここではジョブメドレーに関する課題解決を目的としたプロジェクトに対して、チームで向き合う研修でした。 開発実践の目的と達成すべきこと 実務ではチーム開発が基本となり、チームメンバーとの協働は必須です。学生時代に業務レベルのチーム開発を経験しているのは稀ですし、実務に入る前にチームでプロジェクト推進するとはどういうことかを知るのは、とても価値があると思います。 加えて、チームで課題をどう解決していくのかも、新卒メンバー同士で話し合って決める必要があるので、課題解決力も養われたと思います。 今回はプロトタイプを作って成果発表するところまででしたが、プロジェクト推進においてはスケジューリング、要件定義、各種設計、開発フローやコミュニケーションフローの整備、実装、テスト、などなど、やることは尽きません。 また、このプロセスの中で密なコミュニケーションが必要不可欠となるので、新卒メンバー間のチームワークも向上し、お互いのことを更に知ることができたと思います。 この段階で、チームでプロジェクトを推進することの全体感を知り、プロジェクト推進の苦悩苦闘を実体験できたのは大きな経験値になったと思います。 20 新卒 O さんの感想 「各機能の影響を互いに受けないためにブランチを細分化するブランチ戦略や GitHub を用いたコード管理について理解できた。一方で、UI を考える際にチームの各メンバーの認識のズレが生じたことや、序盤は各メンバーの進捗の詳細を把握できていなかったことから報・連・相の重要性を再認識した。」 20 新卒 T さんの感想 「初めてのチーム開発であったことから、実装の序盤は、どのファイルなら編集しても他のメンバーの作業に影響がないのか、動作確認のための画面を作るファイルは自由に作成して良いのか、どのテーブルから関係する他のテーブルの情報を含めた情報を取得をするかなどに悩んでいた。今になって振り返るとチーム内で話せば解決することに対して、技術的にも心理的にも難しさを感じた。」 ###開発基礎 2 フェーズ 2 最後の開発基礎 2 では、書籍 『Web を支える技術 -HTTP、URI、HTML、そして REST』 の輪読会を行いました。もっと前のフェーズでの実施も検討しましたが、開発基礎 1 と開発実践を経た後の方が書籍の内容の納得感が高くなるだろうという判断で、この段階での実施となりました。 その後、中間報告会に向けたドキュメンテーション研修とプレゼンテーション研修を行いました。仕事を進めていく上では、背景や目的を正しくステークホルダーへ共有しながら進めていくことが必要で、伝えたいことを適切に文章として整理し、他者へ分かりやすく伝えていくことが求められます。中間報告会では、そういったことを意識しながらこれまでの研修でやってきたことや成果、学びをレポートにまとめ、プロダクト開発室の室長と副室長、メンター陣の前でプレゼンテーションして報告しました。 フェーズ 3：事業部 OJT 1.代表取締役医師 豊田の講義 日本における医療制度の課題とそれに対するメドレーの位置付けについての講義 2.ジョブメドレー開発 OJT ジョブメドレーの実際の開発 Issue に対応し、ジョブメドレーの開発プロセスを体験 フェーズ 3 の最初は豊田代表の講義を受けました。基礎的な研修を終え、ジョブメドレー開発 OJT に入る前にメドレー社の社会的意義などを改めて代表から伝えていただきました。 続いて、ジョブメドレー開発 OJT は以下の狙いを持って進めました。 ジョブメドレー開発 OJT の狙い 実際に行ったことは、手始めに小さい不具合系 Issue の対応に取り組んだ後、サーバーレスポンス改善の Issue に取り組むというものでした。 サーバーレスポンスの改善は、1 人 1 画面を担当し、「プロファイルツールで分析 → 改善できそうな箇所を調査 → 改善方針の検討 → 提案 → 実装 → レビュー → リリース」というサイクルを回しました。 1 つ目の Issue 対応でも心掛けたことですが、言われたものを実装するのではなく、 ある課題を解決するためにどうしたら良いかを自分で主体的に考えることを重視しました。実装力と同じくらい課題解決力も大切にしているためです。 とはいえ成果が何も出せないというのは、精神衛生上良くないので、日々の朝会と夕会にて進捗や状況をしっかり確認しながら適宜フォローやインプットを行い、ヒントになりそうな過去 Issue のリンクを渡して参考にしてもらったり、メンターの適切なバックアップも必要です。 今回の OJT を通じて実務を知ることで、実際にエンジニアとして仕事をするイメージが沸き、同時に仕事をする上で足りないことも明確になります。自分の課題と向き合うことで、直近の自身の学習プランの軌道修正もできます。 課題は簡単なものではありませんでしたが、最終的に 1 人 1 つ以上のサーバーレスポンス改善 PR をリリースすることができました。 S さんの感想 「速度パフォーマンスの悪いコードに対する嗅覚、オブジェクトを生成しすぎていないか、無駄に通信を走らせていないかなどを学べた。」 O さんの感想 「Issue を本質的に解決するメドレーの開発姿勢について学んだ。Issue を表面的に解決するのではなく、背景や目的、関連するコードなどの不明点を調査し、十分に理解・納得した上で修正することの意識付けができた。また、Issue に関連する一部分のコードを修正すれば良いという狭い視野を持たず、修正による影響範囲を考慮した上で全体の最適化を考えることが重要であると学んだ。」 フェーズ 4：最終報告 1. 最終報告会 最終報告会の準備と実施 最後のフェーズ 4 では、これまでの研修でやってきたことや成果、学びをレポートにまとめ、役員陣の前でプレゼンテーションして報告しました。 役員陣の前なので緊張は最高潮になりますが、自分達が研修を通じて何を得てどう成長したか、今後どういうエンジニアを目指していくのか、などを役員陣の前でアピールする貴重な機会となりました。 1 人 10 分の枠内で役員陣にどういう情報をどういう表現でプレゼンテーションするかを考える機会にもなったので、情報整理力や表現力が培われる場にもなりました。 さいごに 2020 年度の新卒エンジニア研修も無事終了することができました。改めて、新卒メンバーのみなさん、関係者のみなさん本当にお疲れ様でした。 振り返ると、メドレー社員としてのマインドや開発の基本的なことをしっかりインプットしつつ、新卒メンバーが主体的に課題解決に取り組む研修ができたように思います。 必要な技術スタックを 1 から 10 まで懇切丁寧に資料に落とし込み、講義形式で行う研修も身になることは多いですが、 メドレーの研修のような課題解決を実体験する研修はより実務に繋がる実践的な研修だと思います。 少しハードな面もあるかもしれませんが、このような研修を乗り越え、医療ヘルスケア分野の課題解決に取り組みたい学生エンジニアのみなさん、少しでも興味を持っていただけると幸いです。 もちろん中途エンジニアの方もぜひお気軽にお話をしましょう。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。 ジョブメドレー の開発チームでエンジニアをしている新居です。 はじめに 2020 年 4 月に、新卒エンジニア 3 名が入社しました。 入社後は新卒エンジニア研修を実施し、先日 8 月 25 日の最終報告会をもって終了しました。 コロナウイルスの影響で入社間もなくフルリモート勤務となり、不慣れなところもありましたが、本年度の研修の取り組みを紹介します。 2020 年度新卒エンジニア 研修の概要 メドレーでは昨年度から新卒エンジニアを迎えており、合わせて研修も開始しました。 初めての研修をどのような視点で計画・実施したかについては、昨年平木がこちらにまとめています。 2019 年度エンジニア新卒の研修について - Medley Developer Blog 今年は人事部のご協力もいただきながら、昨年の内容を少しアップデートして行いました。 研修の目的は、 新卒メンバーが同じ空間で互いに刺激し合いながら、社会人への思考転換をはかり、業務遂行に必要となる基礎知識とスキルを習得すること です。 研修は以下の 4 つのフェーズに区切って行いました。 研修のフェーズ 研修の内容 ここから 4 つのフェーズ毎に内容を紹介します。 フェーズ 1：社会人&メドレー基礎研修 1. オリエンテーション メドレーの事業や組織、大切にしている行動規範などの概要説明 セキュリティ研修とコンプライアンス研修 2. ビジネス研修 ビジネスマナー研修 ビジネススキル研修 ビジネススタンス研修（外部研修） フェーズ 1 では「医療ヘルスケアの未来をつくる」メンバーの一員として大切にして欲しいことを学ぶフェーズでした。 社会人としての最低限のマナーやスタンスは勿論ですが、メドレーで働く上で土台となるマインドをここで学び、 医療ヘルスケア分野の課題を解決する一員 として共にプロダクトを作るためのベースを築けたと思います。 フェーズ 2：エンジニア基礎研修 1. 開発基礎 1 講義「メドレーが求めるエンジニアとは」 ジョブメドレー と CLINICS の事業・プロダクトについての概要説明 Ruby on Rails（以下 Rails）の基礎トレーニング 2. 開発実践 チーム開発体験 3. 開発基礎 2 書籍 『Web を支える技術 -HTTP、URI、HTML、そして REST』 の輪読会 ドキュメンテーション研修とプレゼンテーション研修 中間報告会の準備と実施 フェーズ 2 から開発の研修がスタートしました。 開発基礎 1 開発の研修に入る前に、エンジニアの執行役員 田中から「メドレーが求めるエンジニアとは」というテーマで講義を行いました。メドレーがどういうエンジニアを求めているのか、目指すところの視点合わせを行い、これから行う研修に対する意識や取り組みの質を上げることを目指しました。 メドレーが求めるエンジニア像については CTO 平山の記事にも詳しく書いています。 メドレー平山の中央突破: THE エンジニア その後ジョブメドレーと CLINICS の事業・プロダクトについての概要説明、Rails の基礎トレーニングを行いました。メドレーのプロダクトは Rails 製です。Rails やウェブアプリケーション開発に慣れていない新卒メンバーは、Rails の基礎トレーニングで Ruby on Rails チュートリアル を使って基礎からみっちり学びます。 Ruby on Rails チュートリアルの進め方 ここで大切なことは、漠然とひたすら写経してチュートリアルを進めるのではなく、毎日のフィードバック会でしっかりその日の進捗や学びを共有し、不明点はメンターに質問してもらうようにすることです。 メンターは、新卒メンバーが理解が浅いまま進めてたり、理解していて欲しいところがいい加減になってたり、進め方や学びの方向性がズレてる場合などはアドバイスを入れて軌道修正することを心掛けました。 また「実際の開発ではこうだよ」といった実務を踏まえたアドバイスや、意識していることも伝えていきました。 20 新卒 S さんの感想 「毎日のフィードバック会の中で、その日学んだ技術がジョブメドレーではどのように利用されているのか、どういったことに留意して利用しているのかなどを確認できたので、現場の人の感覚を少しずつ知ることができた。」 新卒メンバーは毎日リズム良く進捗を出し、メンターは新卒メンバーのフォローと引き上げを意識し、成果を最大化できるよう努めました。 開発実践 続いて開発実践ではチーム開発を行いました。前回までは各自個別に進めていましたが、ここではジョブメドレーに関する課題解決を目的としたプロジェクトに対して、チームで向き合う研修でした。 開発実践の目的と達成すべきこと 実務ではチーム開発が基本となり、チームメンバーとの協働は必須です。学生時代に業務レベルのチーム開発を経験しているのは稀ですし、実務に入る前にチームでプロジェクト推進するとはどういうことかを知るのは、とても価値があると思います。 加えて、チームで課題をどう解決していくのかも、新卒メンバー同士で話し合って決める必要があるので、課題解決力も養われたと思います。 今回はプロトタイプを作って成果発表するところまででしたが、プロジェクト推進においてはスケジューリング、要件定義、各種設計、開発フローやコミュニケーションフローの整備、実装、テスト、などなど、やることは尽きません。 また、このプロセスの中で密なコミュニケーションが必要不可欠となるので、新卒メンバー間のチームワークも向上し、お互いのことを更に知ることができたと思います。 この段階で、チームでプロジェクトを推進することの全体感を知り、プロジェクト推進の苦悩苦闘を実体験できたのは大きな経験値になったと思います。 20 新卒 O さんの感想 「各機能の影響を互いに受けないためにブランチを細分化するブランチ戦略や GitHub を用いたコード管理について理解できた。一方で、UI を考える際にチームの各メンバーの認識のズレが生じたことや、序盤は各メンバーの進捗の詳細を把握できていなかったことから報・連・相の重要性を再認識した。」 20 新卒 T さんの感想 「初めてのチーム開発であったことから、実装の序盤は、どのファイルなら編集しても他のメンバーの作業に影響がないのか、動作確認のための画面を作るファイルは自由に作成して良いのか、どのテーブルから関係する他のテーブルの情報を含めた情報を取得をするかなどに悩んでいた。今になって振り返るとチーム内で話せば解決することに対して、技術的にも心理的にも難しさを感じた。」 ###開発基礎 2 フェーズ 2 最後の開発基礎 2 では、書籍 『Web を支える技術 -HTTP、URI、HTML、そして REST』 の輪読会を行いました。もっと前のフェーズでの実施も検討しましたが、開発基礎 1 と開発実践を経た後の方が書籍の内容の納得感が高くなるだろうという判断で、この段階での実施となりました。 その後、中間報告会に向けたドキュメンテーション研修とプレゼンテーション研修を行いました。仕事を進めていく上では、背景や目的を正しくステークホルダーへ共有しながら進めていくことが必要で、伝えたいことを適切に文章として整理し、他者へ分かりやすく伝えていくことが求められます。中間報告会では、そういったことを意識しながらこれまでの研修でやってきたことや成果、学びをレポートにまとめ、プロダクト開発室の室長と副室長、メンター陣の前でプレゼンテーションして報告しました。 フェーズ 3：事業部 OJT 1.代表取締役医師 豊田の講義 日本における医療制度の課題とそれに対するメドレーの位置付けについての講義 2.ジョブメドレー開発 OJT ジョブメドレーの実際の開発 Issue に対応し、ジョブメドレーの開発プロセスを体験 フェーズ 3 の最初は豊田代表の講義を受けました。基礎的な研修を終え、ジョブメドレー開発 OJT に入る前にメドレー社の社会的意義などを改めて代表から伝えていただきました。 続いて、ジョブメドレー開発 OJT は以下の狙いを持って進めました。 ジョブメドレー開発 OJT の狙い 実際に行ったことは、手始めに小さい不具合系 Issue の対応に取り組んだ後、サーバーレスポンス改善の Issue に取り組むというものでした。 サーバーレスポンスの改善は、1 人 1 画面を担当し、「プロファイルツールで分析 → 改善できそうな箇所を調査 → 改善方針の検討 → 提案 → 実装 → レビュー → リリース」というサイクルを回しました。 1 つ目の Issue 対応でも心掛けたことですが、言われたものを実装するのではなく、 ある課題を解決するためにどうしたら良いかを自分で主体的に考えることを重視しました。実装力と同じくらい課題解決力も大切にしているためです。 とはいえ成果が何も出せないというのは、精神衛生上良くないので、日々の朝会と夕会にて進捗や状況をしっかり確認しながら適宜フォローやインプットを行い、ヒントになりそうな過去 Issue のリンクを渡して参考にしてもらったり、メンターの適切なバックアップも必要です。 今回の OJT を通じて実務を知ることで、実際にエンジニアとして仕事をするイメージが沸き、同時に仕事をする上で足りないことも明確になります。自分の課題と向き合うことで、直近の自身の学習プランの軌道修正もできます。 課題は簡単なものではありませんでしたが、最終的に 1 人 1 つ以上のサーバーレスポンス改善 PR をリリースすることができました。 S さんの感想 「速度パフォーマンスの悪いコードに対する嗅覚、オブジェクトを生成しすぎていないか、無駄に通信を走らせていないかなどを学べた。」 O さんの感想 「Issue を本質的に解決するメドレーの開発姿勢について学んだ。Issue を表面的に解決するのではなく、背景や目的、関連するコードなどの不明点を調査し、十分に理解・納得した上で修正することの意識付けができた。また、Issue に関連する一部分のコードを修正すれば良いという狭い視野を持たず、修正による影響範囲を考慮した上で全体の最適化を考えることが重要であると学んだ。」 フェーズ 4：最終報告 1. 最終報告会 最終報告会の準備と実施 最後のフェーズ 4 では、これまでの研修でやってきたことや成果、学びをレポートにまとめ、役員陣の前でプレゼンテーションして報告しました。 役員陣の前なので緊張は最高潮になりますが、自分達が研修を通じて何を得てどう成長したか、今後どういうエンジニアを目指していくのか、などを役員陣の前でアピールする貴重な機会となりました。 1 人 10 分の枠内で役員陣にどういう情報をどういう表現でプレゼンテーションするかを考える機会にもなったので、情報整理力や表現力が培われる場にもなりました。 さいごに 2020 年度の新卒エンジニア研修も無事終了することができました。改めて、新卒メンバーのみなさん、関係者のみなさん本当にお疲れ様でした。 振り返ると、メドレー社員としてのマインドや開発の基本的なことをしっかりインプットしつつ、新卒メンバーが主体的に課題解決に取り組む研修ができたように思います。 必要な技術スタックを 1 から 10 まで懇切丁寧に資料に落とし込み、講義形式で行う研修も身になることは多いですが、 メドレーの研修のような課題解決を実体験する研修はより実務に繋がる実践的な研修だと思います。 少しハードな面もあるかもしれませんが、このような研修を乗り越え、医療ヘルスケア分野の課題解決に取り組みたい学生エンジニアのみなさん、少しでも興味を持っていただけると幸いです。 もちろん中途エンジニアの方もぜひお気軽にお話をしましょう。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp