こんにちは、平山です。メドレーのプロダクト開発全般を管掌しています。先日 4/29 (日)に虎ノ門ヒルズフォーラムで開催された CLINICS SUMMIT 2018 と合わせて、3 本のニュースリリースをだしました。 これらのニュースリリースはひとつのストーリーにもとづいているのですが、それぞれを読んだだけではメッセージが伝わりづらいと思いますので、このブログで補足させて頂きます。 ニュースリリース www.medley.jp www.medley.jp www.medley.jp オンライン診療システムのいま まず背景として我々が提供しているプロダクト「CLINICS」について振り返るところから話を進めます。 オンライン診療システム CLINICS は、2015 年 8 月に厚生労働省から示された遠隔診療に関する通知をうけて、2016 年 2 月にプロダクトをローンチしたところからはじまりました。 ローンチ当初はネイティブアプリもなくウェブアプリケーションのみで、オンライン診療の肝となるビデオチャット機能も外部サービスで代替するなど、わかりやすい MVP (Minimum Viable Product) からスタートしました。その後、様々な医療機関で利用頂き、多くの医療機関スタッフの皆様からの叱咤激励をうけながら、プロダクトやオペレーションを磨き進化を続けて参りました。 その結果として、現在では契約医療機関は 800 を超え、1 ヶ月に 100 回以上ものオンライン診療を実施するような医療機関もでてきました。また 平成 30 年度の診療報酬改定 では オンライン診療料が新設 され、オンライン診療というものが正式に医療の現場で認められるようになってきています。 しかし、オンライン診療システムの進化の中で常につきまとう課題がありました。それは 電子カルテや医事会計システムなど医療機関の中心で使われるシステムとの連携 です。  オンライン診療から電子カルテへ 医療現場の業務において中心で使われるシステムはオンライン診療システムではなく、一般的には電子カルテや医事会計システムとなります。 オンライン診療システムは、予約、問診、診察、会計、薬または処方せんの配送、これら一連の業務を対面・オンラインに限らずにワンストップで処理できるという思想で開発を進めてきました。しかし、実際の現場においては、オンライン診療システムでの業務と電子カルテシステムでの業務を連携させるために人手を介在させる必要があり、オンライン診療システムをいれると現場オペレーションが増えてしまうといった課題がありました。 このオンライン診療システムにつきまとう課題を解決するため、昨年より電子カルテに関する調査を進めてきました。他社電子カルテシステムとの連携など様々な選択肢があったなか、この調査を経て 現状の電子カルテをとりまく課題と将来の可能性 を感じ、電子カルテを内製で開発しオンライン診療システムを電子カルテシステムに進化させるという結論に至りました。 おりしも 2017 年は 3 省 4 ガイドラインの改定 (医療情報システムの安全管理に関するガイドライン第 5 版) や、日本医師会 ORCA 管理機構による 日レセクラウド や API 拡張 (HAORI) の提供開始などの動きがあり、医療業界においてもクラウド化の波が確実にきていることを感じました。これが電子カルテ開発の背景です。  患者とつながる電子カルテ「CLINICS カルテ」 開発した電子カルテシステム「CLINICS カルテ」は、医事会計ソフトである ORCA を会計エンジンとして組み込んだ ORCA 内包型のクラウド電子カルテ となります。 医療機関のスタッフは予約から受付、患者管理、診察、オーダリング、会計、請求といった、ひととおりの業務をウェブブラウザだけあれば行うことができます。またオンライン診療の機能が搭載されているため、患者がアプリから予約しチェックインした情報をもとに、医療機関スタッフが患者情報を登録し、そのままオンライン診療を実施し、会計まで進めるということも可能となります(もちろんオンライン診療を実施するための基準を満たしていることが前提です)。 まさに 患者とつながる電子カルテ ということを実現したプロダクトとなります。 もちろんセキュリティ統制の強化についても昨年から本格的に取り組んできておりまして、3 省 4 ガイドラインへの準拠は当然のことながら、第 3 者認証機関による認証取得に向けても動いています ( TRUSTe 取得完了 、ISMS 取得作業中)。   医療 IT の課題とアプローチ しかし、CLINICS カルテをはじめとしたクラウド電子カルテが普及するには時間がかかると考えています。 クラウドサービスに慣れた若い世代が開業し、システム導入の意思決定をするための世代交代に一定以上の時間が必要であるというのはもちろんですが、それ以上に 医療情報システム関連技術の標準化が遅れている ことや、ローカルネットワークを前提とする 院内システムのエコシステムができあがっている ためです。これにより、ウェブ系の新興プレイヤーが参入することが難しくなり、結果として医療業界全体がテクノロジーの進化の恩恵をうけづらくなっているように感じます。 この現状をふまえ、我々は CLINICS カルテの公開とあわせて、医療 IT の世界をオープンにし、様々な新興プレイヤーが参入しやすい土壌をつくることについてもコミットしていきたいと考えています。その思いが**「ORCA API のオープンソース公開」 と 「ブロックチェーンを活用した電子処方せん管理方式に関する特許出願」**という 2 つのニュースリリースにあらわれています。  ORCA API のオープンソース公開 ORCA API は ORCA((正確には ORCA プロジェクトが提供している日医標準レセプトソフト))が提供する API を Ruby から利用するためのライブラリです。ORCA API をオープンソースとして公開することで、ORCA と接続するウェブアプリケーションの開発が促進されることを期待するものです。 github.com ブロックチェーンを活用した電子処方せん管理方式に関する特許出願 電子処方せんに関してはすでに 実装ガイド が作成され指針が示されていますが、この中で認められているように、実装ガイドに基づいて電子処方せんシステムを実装しても実運用で使うにはいくつかの課題が残ります。また、それらの課題を解決するために 今後の方向性についての議論 も行われているようですが、なかなか前に進む気配が見られません。 それに対する我々からのひとつの考えを示してみたのが今回の特許出願となります (我々が独占的に利用するといった意図の特許出願ではありません)。 名称 電子処方せん管理方法、電子処方せん管理システム、及びプログラム 内容 処方せんの電磁的記録による作成、交付及び保存を実施するための電子処方せん管理方法、電子処方せん管理システム、及びプログラム 概要 ＡＳＰサーバを用いずとも、実運用が可能な電子処方せんを実現するもの この 2 つは現状の医療 IT に存在している課題に対してアプローチしたものになりますが、これ以外にも検査結果データの標準化や HPKI のオープン化と促進 (特定プラットフォーム依存性の排除)、SS-MIX の促進など、標準化という観点で医療 IT の世界には取り組むべき課題が多くあります。 標準化においてはトップダウンによるアプローチが理想だと思いますが、トップダウンでの標準化には時間がかかり、 テクノロジーの進化の時間軸との間にギャップ が発生しがちです。我々は今回の ORCA API や電子処方せんブロックチェーンでのアプローチのように、トップダウンでの標準化の動きを待つだけでなく、テクノロジーを活用した ボトムアップの技術提案 も積極的に行っていきたいと考えています。 その結果として、技術の標準化が進み、新興プレイヤーが増え、医療機関間の連携も円滑になり、地域医療構想のような動きも加速され、医療現場の IT 化が進み、医療従事者が診療により専念できる環境がつくられる。 そのような世界の実現にむけて我々は取り組んでいくという意思を明確にするために、今回のニュースリリースを公開させて頂きました。 医療 IT の未来に向けて toppa.medley.jp 以前このブログでも書いたとおり、インターネット業界で活躍してきたような、高い能力をもちプロダクトにこだわりをもって開発をしてきたような人が圧倒的に少ないことが、医療 IT における課題であると私は思っています。 若く優秀なクリエイターたちが医療 IT の世界に参加し、様々な取り組みをすることで、業界内の循環が進み、結果として業界の進化にもつながるものと考えています。まずは我々が積極的に技術をオープンにしていくことで、その流れの起点をつくっていきたいと思います。  メドレーは「医療ヘルスケア分野の課題を解決する」というミッションのもと、医療 IT の世界における標準化の課題に対しても積極的にアプローチしていきます。 さいごに メドレーではこのような医療業界に存在する課題に取り組んでいきたいメンバーをデザイナー・エンジニアを中心に全職種絶賛募集中です。皆さまからのご応募お待ちしております。 www.medley.jp

こんにちは、平山です。メドレーのプロダクト開発全般を管掌しています。先日 4/29 (日)に虎ノ門ヒルズフォーラムで開催された CLINICS SUMMIT 2018 と合わせて、3 本のニュースリリースをだしました。 これらのニュースリリースはひとつのストーリーにもとづいているのですが、それぞれを読んだだけではメッセージが伝わりづらいと思いますので、このブログで補足させて頂きます。 ニュースリリース www.medley.jp www.medley.jp www.medley.jp オンライン診療システムのいま まず背景として我々が提供しているプロダクト「CLINICS」について振り返るところから話を進めます。 オンライン診療システム CLINICS は、2015 年 8 月に厚生労働省から示された遠隔診療に関する通知をうけて、2016 年 2 月にプロダクトをローンチしたところからはじまりました。 ローンチ当初はネイティブアプリもなくウェブアプリケーションのみで、オンライン診療の肝となるビデオチャット機能も外部サービスで代替するなど、わかりやすい MVP (Minimum Viable Product) からスタートしました。その後、様々な医療機関で利用頂き、多くの医療機関スタッフの皆様からの叱咤激励をうけながら、プロダクトやオペレーションを磨き進化を続けて参りました。 その結果として、現在では契約医療機関は 800 を超え、1 ヶ月に 100 回以上ものオンライン診療を実施するような医療機関もでてきました。また 平成 30 年度の診療報酬改定 では オンライン診療料が新設 され、オンライン診療というものが正式に医療の現場で認められるようになってきています。 しかし、オンライン診療システムの進化の中で常につきまとう課題がありました。それは 電子カルテや医事会計システムなど医療機関の中心で使われるシステムとの連携 です。  オンライン診療から電子カルテへ 医療現場の業務において中心で使われるシステムはオンライン診療システムではなく、一般的には電子カルテや医事会計システムとなります。 オンライン診療システムは、予約、問診、診察、会計、薬または処方せんの配送、これら一連の業務を対面・オンラインに限らずにワンストップで処理できるという思想で開発を進めてきました。しかし、実際の現場においては、オンライン診療システムでの業務と電子カルテシステムでの業務を連携させるために人手を介在させる必要があり、オンライン診療システムをいれると現場オペレーションが増えてしまうといった課題がありました。 このオンライン診療システムにつきまとう課題を解決するため、昨年より電子カルテに関する調査を進めてきました。他社電子カルテシステムとの連携など様々な選択肢があったなか、この調査を経て 現状の電子カルテをとりまく課題と将来の可能性 を感じ、電子カルテを内製で開発しオンライン診療システムを電子カルテシステムに進化させるという結論に至りました。 おりしも 2017 年は 3 省 4 ガイドラインの改定 (医療情報システムの安全管理に関するガイドライン第 5 版) や、日本医師会 ORCA 管理機構による 日レセクラウド や API 拡張 (HAORI) の提供開始などの動きがあり、医療業界においてもクラウド化の波が確実にきていることを感じました。これが電子カルテ開発の背景です。  患者とつながる電子カルテ「CLINICS カルテ」 開発した電子カルテシステム「CLINICS カルテ」は、医事会計ソフトである ORCA を会計エンジンとして組み込んだ ORCA 内包型のクラウド電子カルテ となります。 医療機関のスタッフは予約から受付、患者管理、診察、オーダリング、会計、請求といった、ひととおりの業務をウェブブラウザだけあれば行うことができます。またオンライン診療の機能が搭載されているため、患者がアプリから予約しチェックインした情報をもとに、医療機関スタッフが患者情報を登録し、そのままオンライン診療を実施し、会計まで進めるということも可能となります(もちろんオンライン診療を実施するための基準を満たしていることが前提です)。 まさに 患者とつながる電子カルテ ということを実現したプロダクトとなります。 もちろんセキュリティ統制の強化についても昨年から本格的に取り組んできておりまして、3 省 4 ガイドラインへの準拠は当然のことながら、第 3 者認証機関による認証取得に向けても動いています ( TRUSTe 取得完了 、ISMS 取得作業中)。   医療 IT の課題とアプローチ しかし、CLINICS カルテをはじめとしたクラウド電子カルテが普及するには時間がかかると考えています。 クラウドサービスに慣れた若い世代が開業し、システム導入の意思決定をするための世代交代に一定以上の時間が必要であるというのはもちろんですが、それ以上に 医療情報システム関連技術の標準化が遅れている ことや、ローカルネットワークを前提とする 院内システムのエコシステムができあがっている ためです。これにより、ウェブ系の新興プレイヤーが参入することが難しくなり、結果として医療業界全体がテクノロジーの進化の恩恵をうけづらくなっているように感じます。 この現状をふまえ、我々は CLINICS カルテの公開とあわせて、医療 IT の世界をオープンにし、様々な新興プレイヤーが参入しやすい土壌をつくることについてもコミットしていきたいと考えています。その思いが**「ORCA API のオープンソース公開」 と 「ブロックチェーンを活用した電子処方せん管理方式に関する特許出願」**という 2 つのニュースリリースにあらわれています。  ORCA API のオープンソース公開 ORCA API は ORCA((正確には ORCA プロジェクトが提供している日医標準レセプトソフト))が提供する API を Ruby から利用するためのライブラリです。ORCA API をオープンソースとして公開することで、ORCA と接続するウェブアプリケーションの開発が促進されることを期待するものです。 github.com ブロックチェーンを活用した電子処方せん管理方式に関する特許出願 電子処方せんに関してはすでに 実装ガイド が作成され指針が示されていますが、この中で認められているように、実装ガイドに基づいて電子処方せんシステムを実装しても実運用で使うにはいくつかの課題が残ります。また、それらの課題を解決するために 今後の方向性についての議論 も行われているようですが、なかなか前に進む気配が見られません。 それに対する我々からのひとつの考えを示してみたのが今回の特許出願となります (我々が独占的に利用するといった意図の特許出願ではありません)。 名称 電子処方せん管理方法、電子処方せん管理システム、及びプログラム 内容 処方せんの電磁的記録による作成、交付及び保存を実施するための電子処方せん管理方法、電子処方せん管理システム、及びプログラム 概要 ＡＳＰサーバを用いずとも、実運用が可能な電子処方せんを実現するもの この 2 つは現状の医療 IT に存在している課題に対してアプローチしたものになりますが、これ以外にも検査結果データの標準化や HPKI のオープン化と促進 (特定プラットフォーム依存性の排除)、SS-MIX の促進など、標準化という観点で医療 IT の世界には取り組むべき課題が多くあります。 標準化においてはトップダウンによるアプローチが理想だと思いますが、トップダウンでの標準化には時間がかかり、 テクノロジーの進化の時間軸との間にギャップ が発生しがちです。我々は今回の ORCA API や電子処方せんブロックチェーンでのアプローチのように、トップダウンでの標準化の動きを待つだけでなく、テクノロジーを活用した ボトムアップの技術提案 も積極的に行っていきたいと考えています。 その結果として、技術の標準化が進み、新興プレイヤーが増え、医療機関間の連携も円滑になり、地域医療構想のような動きも加速され、医療現場の IT 化が進み、医療従事者が診療により専念できる環境がつくられる。 そのような世界の実現にむけて我々は取り組んでいくという意思を明確にするために、今回のニュースリリースを公開させて頂きました。 医療 IT の未来に向けて toppa.medley.jp 以前このブログでも書いたとおり、インターネット業界で活躍してきたような、高い能力をもちプロダクトにこだわりをもって開発をしてきたような人が圧倒的に少ないことが、医療 IT における課題であると私は思っています。 若く優秀なクリエイターたちが医療 IT の世界に参加し、様々な取り組みをすることで、業界内の循環が進み、結果として業界の進化にもつながるものと考えています。まずは我々が積極的に技術をオープンにしていくことで、その流れの起点をつくっていきたいと思います。  メドレーは「医療ヘルスケア分野の課題を解決する」というミッションのもと、医療 IT の世界における標準化の課題に対しても積極的にアプローチしていきます。 さいごに メドレーではこのような医療業界に存在する課題に取り組んでいきたいメンバーをデザイナー・エンジニアを中心に全職種絶賛募集中です。皆さまからのご応募お待ちしております。 www.medley.jp

こんにちは、平山です。メドレーのプロダクト開発全般を管掌しています。先日 4/29 (日)に虎ノ門ヒルズフォーラムで開催された CLINICS SUMMIT 2018 と合わせて、3 本のニュースリリースをだしました。 これらのニュースリリースはひとつのストーリーにもとづいているのですが、それぞれを読んだだけではメッセージが伝わりづらいと思いますので、このブログで補足させて頂きます。 ニュースリリース www.medley.jp www.medley.jp www.medley.jp オンライン診療システムのいま まず背景として我々が提供しているプロダクト「CLINICS」について振り返るところから話を進めます。 オンライン診療システム CLINICS は、2015 年 8 月に厚生労働省から示された遠隔診療に関する通知をうけて、2016 年 2 月にプロダクトをローンチしたところからはじまりました。 ローンチ当初はネイティブアプリもなくウェブアプリケーションのみで、オンライン診療の肝となるビデオチャット機能も外部サービスで代替するなど、わかりやすい MVP (Minimum Viable Product) からスタートしました。その後、様々な医療機関で利用頂き、多くの医療機関スタッフの皆様からの叱咤激励をうけながら、プロダクトやオペレーションを磨き進化を続けて参りました。 その結果として、現在では契約医療機関は 800 を超え、1 ヶ月に 100 回以上ものオンライン診療を実施するような医療機関もでてきました。また 平成 30 年度の診療報酬改定 では オンライン診療料が新設 され、オンライン診療というものが正式に医療の現場で認められるようになってきています。 しかし、オンライン診療システムの進化の中で常につきまとう課題がありました。それは 電子カルテや医事会計システムなど医療機関の中心で使われるシステムとの連携 です。  オンライン診療から電子カルテへ 医療現場の業務において中心で使われるシステムはオンライン診療システムではなく、一般的には電子カルテや医事会計システムとなります。 オンライン診療システムは、予約、問診、診察、会計、薬または処方せんの配送、これら一連の業務を対面・オンラインに限らずにワンストップで処理できるという思想で開発を進めてきました。しかし、実際の現場においては、オンライン診療システムでの業務と電子カルテシステムでの業務を連携させるために人手を介在させる必要があり、オンライン診療システムをいれると現場オペレーションが増えてしまうといった課題がありました。 このオンライン診療システムにつきまとう課題を解決するため、昨年より電子カルテに関する調査を進めてきました。他社電子カルテシステムとの連携など様々な選択肢があったなか、この調査を経て 現状の電子カルテをとりまく課題と将来の可能性 を感じ、電子カルテを内製で開発しオンライン診療システムを電子カルテシステムに進化させるという結論に至りました。 おりしも 2017 年は 3 省 4 ガイドラインの改定 (医療情報システムの安全管理に関するガイドライン第 5 版) や、日本医師会 ORCA 管理機構による 日レセクラウド や API 拡張 (HAORI) の提供開始などの動きがあり、医療業界においてもクラウド化の波が確実にきていることを感じました。これが電子カルテ開発の背景です。  患者とつながる電子カルテ「CLINICS カルテ」 開発した電子カルテシステム「CLINICS カルテ」は、医事会計ソフトである ORCA を会計エンジンとして組み込んだ ORCA 内包型のクラウド電子カルテ となります。 医療機関のスタッフは予約から受付、患者管理、診察、オーダリング、会計、請求といった、ひととおりの業務をウェブブラウザだけあれば行うことができます。またオンライン診療の機能が搭載されているため、患者がアプリから予約しチェックインした情報をもとに、医療機関スタッフが患者情報を登録し、そのままオンライン診療を実施し、会計まで進めるということも可能となります(もちろんオンライン診療を実施するための基準を満たしていることが前提です)。 まさに 患者とつながる電子カルテ ということを実現したプロダクトとなります。 もちろんセキュリティ統制の強化についても昨年から本格的に取り組んできておりまして、3 省 4 ガイドラインへの準拠は当然のことながら、第 3 者認証機関による認証取得に向けても動いています ( TRUSTe 取得完了 、ISMS 取得作業中)。   医療 IT の課題とアプローチ しかし、CLINICS カルテをはじめとしたクラウド電子カルテが普及するには時間がかかると考えています。 クラウドサービスに慣れた若い世代が開業し、システム導入の意思決定をするための世代交代に一定以上の時間が必要であるというのはもちろんですが、それ以上に 医療情報システム関連技術の標準化が遅れている ことや、ローカルネットワークを前提とする 院内システムのエコシステムができあがっている ためです。これにより、ウェブ系の新興プレイヤーが参入することが難しくなり、結果として医療業界全体がテクノロジーの進化の恩恵をうけづらくなっているように感じます。 この現状をふまえ、我々は CLINICS カルテの公開とあわせて、医療 IT の世界をオープンにし、様々な新興プレイヤーが参入しやすい土壌をつくることについてもコミットしていきたいと考えています。その思いが**「ORCA API のオープンソース公開」 と 「ブロックチェーンを活用した電子処方せん管理方式に関する特許出願」**という 2 つのニュースリリースにあらわれています。  ORCA API のオープンソース公開 ORCA API は ORCA((正確には ORCA プロジェクトが提供している日医標準レセプトソフト))が提供する API を Ruby から利用するためのライブラリです。ORCA API をオープンソースとして公開することで、ORCA と接続するウェブアプリケーションの開発が促進されることを期待するものです。 github.com ブロックチェーンを活用した電子処方せん管理方式に関する特許出願 電子処方せんに関してはすでに 実装ガイド が作成され指針が示されていますが、この中で認められているように、実装ガイドに基づいて電子処方せんシステムを実装しても実運用で使うにはいくつかの課題が残ります。また、それらの課題を解決するために 今後の方向性についての議論 も行われているようですが、なかなか前に進む気配が見られません。 それに対する我々からのひとつの考えを示してみたのが今回の特許出願となります (我々が独占的に利用するといった意図の特許出願ではありません)。 名称 電子処方せん管理方法、電子処方せん管理システム、及びプログラム 内容 処方せんの電磁的記録による作成、交付及び保存を実施するための電子処方せん管理方法、電子処方せん管理システム、及びプログラム 概要 ＡＳＰサーバを用いずとも、実運用が可能な電子処方せんを実現するもの この 2 つは現状の医療 IT に存在している課題に対してアプローチしたものになりますが、これ以外にも検査結果データの標準化や HPKI のオープン化と促進 (特定プラットフォーム依存性の排除)、SS-MIX の促進など、標準化という観点で医療 IT の世界には取り組むべき課題が多くあります。 標準化においてはトップダウンによるアプローチが理想だと思いますが、トップダウンでの標準化には時間がかかり、 テクノロジーの進化の時間軸との間にギャップ が発生しがちです。我々は今回の ORCA API や電子処方せんブロックチェーンでのアプローチのように、トップダウンでの標準化の動きを待つだけでなく、テクノロジーを活用した ボトムアップの技術提案 も積極的に行っていきたいと考えています。 その結果として、技術の標準化が進み、新興プレイヤーが増え、医療機関間の連携も円滑になり、地域医療構想のような動きも加速され、医療現場の IT 化が進み、医療従事者が診療により専念できる環境がつくられる。 そのような世界の実現にむけて我々は取り組んでいくという意思を明確にするために、今回のニュースリリースを公開させて頂きました。 医療 IT の未来に向けて toppa.medley.jp 以前このブログでも書いたとおり、インターネット業界で活躍してきたような、高い能力をもちプロダクトにこだわりをもって開発をしてきたような人が圧倒的に少ないことが、医療 IT における課題であると私は思っています。 若く優秀なクリエイターたちが医療 IT の世界に参加し、様々な取り組みをすることで、業界内の循環が進み、結果として業界の進化にもつながるものと考えています。まずは我々が積極的に技術をオープンにしていくことで、その流れの起点をつくっていきたいと思います。  メドレーは「医療ヘルスケア分野の課題を解決する」というミッションのもと、医療 IT の世界における標準化の課題に対しても積極的にアプローチしていきます。 さいごに メドレーではこのような医療業界に存在する課題に取り組んでいきたいメンバーをデザイナー・エンジニアを中心に全職種絶賛募集中です。皆さまからのご応募お待ちしております。 www.medley.jp

こんにちは、平山です。メドレーのプロダクト開発全般を管掌しています。先日 4/29 (日)に虎ノ門ヒルズフォーラムで開催された CLINICS SUMMIT 2018 と合わせて、3 本のニュースリリースをだしました。 これらのニュースリリースはひとつのストーリーにもとづいているのですが、それぞれを読んだだけではメッセージが伝わりづらいと思いますので、このブログで補足させて頂きます。 ニュースリリース www.medley.jp www.medley.jp www.medley.jp オンライン診療システムのいま まず背景として我々が提供しているプロダクト「CLINICS」について振り返るところから話を進めます。 オンライン診療システム CLINICS は、2015 年 8 月に厚生労働省から示された遠隔診療に関する通知をうけて、2016 年 2 月にプロダクトをローンチしたところからはじまりました。 ローンチ当初はネイティブアプリもなくウェブアプリケーションのみで、オンライン診療の肝となるビデオチャット機能も外部サービスで代替するなど、わかりやすい MVP (Minimum Viable Product) からスタートしました。その後、様々な医療機関で利用頂き、多くの医療機関スタッフの皆様からの叱咤激励をうけながら、プロダクトやオペレーションを磨き進化を続けて参りました。 その結果として、現在では契約医療機関は 800 を超え、1 ヶ月に 100 回以上ものオンライン診療を実施するような医療機関もでてきました。また 平成 30 年度の診療報酬改定 では オンライン診療料が新設 され、オンライン診療というものが正式に医療の現場で認められるようになってきています。 しかし、オンライン診療システムの進化の中で常につきまとう課題がありました。それは 電子カルテや医事会計システムなど医療機関の中心で使われるシステムとの連携 です。  オンライン診療から電子カルテへ 医療現場の業務において中心で使われるシステムはオンライン診療システムではなく、一般的には電子カルテや医事会計システムとなります。 オンライン診療システムは、予約、問診、診察、会計、薬または処方せんの配送、これら一連の業務を対面・オンラインに限らずにワンストップで処理できるという思想で開発を進めてきました。しかし、実際の現場においては、オンライン診療システムでの業務と電子カルテシステムでの業務を連携させるために人手を介在させる必要があり、オンライン診療システムをいれると現場オペレーションが増えてしまうといった課題がありました。 このオンライン診療システムにつきまとう課題を解決するため、昨年より電子カルテに関する調査を進めてきました。他社電子カルテシステムとの連携など様々な選択肢があったなか、この調査を経て 現状の電子カルテをとりまく課題と将来の可能性 を感じ、電子カルテを内製で開発しオンライン診療システムを電子カルテシステムに進化させるという結論に至りました。 おりしも 2017 年は 3 省 4 ガイドラインの改定 (医療情報システムの安全管理に関するガイドライン第 5 版) や、日本医師会 ORCA 管理機構による 日レセクラウド や API 拡張 (HAORI) の提供開始などの動きがあり、医療業界においてもクラウド化の波が確実にきていることを感じました。これが電子カルテ開発の背景です。  患者とつながる電子カルテ「CLINICS カルテ」 開発した電子カルテシステム「CLINICS カルテ」は、医事会計ソフトである ORCA を会計エンジンとして組み込んだ ORCA 内包型のクラウド電子カルテ となります。 医療機関のスタッフは予約から受付、患者管理、診察、オーダリング、会計、請求といった、ひととおりの業務をウェブブラウザだけあれば行うことができます。またオンライン診療の機能が搭載されているため、患者がアプリから予約しチェックインした情報をもとに、医療機関スタッフが患者情報を登録し、そのままオンライン診療を実施し、会計まで進めるということも可能となります(もちろんオンライン診療を実施するための基準を満たしていることが前提です)。 まさに 患者とつながる電子カルテ ということを実現したプロダクトとなります。 もちろんセキュリティ統制の強化についても昨年から本格的に取り組んできておりまして、3 省 4 ガイドラインへの準拠は当然のことながら、第 3 者認証機関による認証取得に向けても動いています ( TRUSTe 取得完了 、ISMS 取得作業中)。   医療 IT の課題とアプローチ しかし、CLINICS カルテをはじめとしたクラウド電子カルテが普及するには時間がかかると考えています。 クラウドサービスに慣れた若い世代が開業し、システム導入の意思決定をするための世代交代に一定以上の時間が必要であるというのはもちろんですが、それ以上に 医療情報システム関連技術の標準化が遅れている ことや、ローカルネットワークを前提とする 院内システムのエコシステムができあがっている ためです。これにより、ウェブ系の新興プレイヤーが参入することが難しくなり、結果として医療業界全体がテクノロジーの進化の恩恵をうけづらくなっているように感じます。 この現状をふまえ、我々は CLINICS カルテの公開とあわせて、医療 IT の世界をオープンにし、様々な新興プレイヤーが参入しやすい土壌をつくることについてもコミットしていきたいと考えています。その思いが**「ORCA API のオープンソース公開」 と 「ブロックチェーンを活用した電子処方せん管理方式に関する特許出願」**という 2 つのニュースリリースにあらわれています。  ORCA API のオープンソース公開 ORCA API は ORCA((正確には ORCA プロジェクトが提供している日医標準レセプトソフト))が提供する API を Ruby から利用するためのライブラリです。ORCA API をオープンソースとして公開することで、ORCA と接続するウェブアプリケーションの開発が促進されることを期待するものです。 github.com ブロックチェーンを活用した電子処方せん管理方式に関する特許出願 電子処方せんに関してはすでに 実装ガイド が作成され指針が示されていますが、この中で認められているように、実装ガイドに基づいて電子処方せんシステムを実装しても実運用で使うにはいくつかの課題が残ります。また、それらの課題を解決するために 今後の方向性についての議論 も行われているようですが、なかなか前に進む気配が見られません。 それに対する我々からのひとつの考えを示してみたのが今回の特許出願となります (我々が独占的に利用するといった意図の特許出願ではありません)。 名称 電子処方せん管理方法、電子処方せん管理システム、及びプログラム 内容 処方せんの電磁的記録による作成、交付及び保存を実施するための電子処方せん管理方法、電子処方せん管理システム、及びプログラム 概要 ＡＳＰサーバを用いずとも、実運用が可能な電子処方せんを実現するもの この 2 つは現状の医療 IT に存在している課題に対してアプローチしたものになりますが、これ以外にも検査結果データの標準化や HPKI のオープン化と促進 (特定プラットフォーム依存性の排除)、SS-MIX の促進など、標準化という観点で医療 IT の世界には取り組むべき課題が多くあります。 標準化においてはトップダウンによるアプローチが理想だと思いますが、トップダウンでの標準化には時間がかかり、 テクノロジーの進化の時間軸との間にギャップ が発生しがちです。我々は今回の ORCA API や電子処方せんブロックチェーンでのアプローチのように、トップダウンでの標準化の動きを待つだけでなく、テクノロジーを活用した ボトムアップの技術提案 も積極的に行っていきたいと考えています。 その結果として、技術の標準化が進み、新興プレイヤーが増え、医療機関間の連携も円滑になり、地域医療構想のような動きも加速され、医療現場の IT 化が進み、医療従事者が診療により専念できる環境がつくられる。 そのような世界の実現にむけて我々は取り組んでいくという意思を明確にするために、今回のニュースリリースを公開させて頂きました。 医療 IT の未来に向けて toppa.medley.jp 以前このブログでも書いたとおり、インターネット業界で活躍してきたような、高い能力をもちプロダクトにこだわりをもって開発をしてきたような人が圧倒的に少ないことが、医療 IT における課題であると私は思っています。 若く優秀なクリエイターたちが医療 IT の世界に参加し、様々な取り組みをすることで、業界内の循環が進み、結果として業界の進化にもつながるものと考えています。まずは我々が積極的に技術をオープンにしていくことで、その流れの起点をつくっていきたいと思います。  メドレーは「医療ヘルスケア分野の課題を解決する」というミッションのもと、医療 IT の世界における標準化の課題に対しても積極的にアプローチしていきます。 さいごに メドレーではこのような医療業界に存在する課題に取り組んでいきたいメンバーをデザイナー・エンジニアを中心に全職種絶賛募集中です。皆さまからのご応募お待ちしております。 www.medley.jp

こんにちは、平山です。メドレーのプロダクト開発全般を管掌しています。先日 4/29 (日)に虎ノ門ヒルズフォーラムで開催された CLINICS SUMMIT 2018 と合わせて、3 本のニュースリリースをだしました。 これらのニュースリリースはひとつのストーリーにもとづいているのですが、それぞれを読んだだけではメッセージが伝わりづらいと思いますので、このブログで補足させて頂きます。 ニュースリリース www.medley.jp www.medley.jp www.medley.jp オンライン診療システムのいま まず背景として我々が提供しているプロダクト「CLINICS」について振り返るところから話を進めます。 オンライン診療システム CLINICS は、2015 年 8 月に厚生労働省から示された遠隔診療に関する通知をうけて、2016 年 2 月にプロダクトをローンチしたところからはじまりました。 ローンチ当初はネイティブアプリもなくウェブアプリケーションのみで、オンライン診療の肝となるビデオチャット機能も外部サービスで代替するなど、わかりやすい MVP (Minimum Viable Product) からスタートしました。その後、様々な医療機関で利用頂き、多くの医療機関スタッフの皆様からの叱咤激励をうけながら、プロダクトやオペレーションを磨き進化を続けて参りました。 その結果として、現在では契約医療機関は 800 を超え、1 ヶ月に 100 回以上ものオンライン診療を実施するような医療機関もでてきました。また 平成 30 年度の診療報酬改定 では オンライン診療料が新設 され、オンライン診療というものが正式に医療の現場で認められるようになってきています。 しかし、オンライン診療システムの進化の中で常につきまとう課題がありました。それは 電子カルテや医事会計システムなど医療機関の中心で使われるシステムとの連携 です。  オンライン診療から電子カルテへ 医療現場の業務において中心で使われるシステムはオンライン診療システムではなく、一般的には電子カルテや医事会計システムとなります。 オンライン診療システムは、予約、問診、診察、会計、薬または処方せんの配送、これら一連の業務を対面・オンラインに限らずにワンストップで処理できるという思想で開発を進めてきました。しかし、実際の現場においては、オンライン診療システムでの業務と電子カルテシステムでの業務を連携させるために人手を介在させる必要があり、オンライン診療システムをいれると現場オペレーションが増えてしまうといった課題がありました。 このオンライン診療システムにつきまとう課題を解決するため、昨年より電子カルテに関する調査を進めてきました。他社電子カルテシステムとの連携など様々な選択肢があったなか、この調査を経て 現状の電子カルテをとりまく課題と将来の可能性 を感じ、電子カルテを内製で開発しオンライン診療システムを電子カルテシステムに進化させるという結論に至りました。 おりしも 2017 年は 3 省 4 ガイドラインの改定 (医療情報システムの安全管理に関するガイドライン第 5 版) や、日本医師会 ORCA 管理機構による 日レセクラウド や API 拡張 (HAORI) の提供開始などの動きがあり、医療業界においてもクラウド化の波が確実にきていることを感じました。これが電子カルテ開発の背景です。  患者とつながる電子カルテ「CLINICS カルテ」 開発した電子カルテシステム「CLINICS カルテ」は、医事会計ソフトである ORCA を会計エンジンとして組み込んだ ORCA 内包型のクラウド電子カルテ となります。 医療機関のスタッフは予約から受付、患者管理、診察、オーダリング、会計、請求といった、ひととおりの業務をウェブブラウザだけあれば行うことができます。またオンライン診療の機能が搭載されているため、患者がアプリから予約しチェックインした情報をもとに、医療機関スタッフが患者情報を登録し、そのままオンライン診療を実施し、会計まで進めるということも可能となります(もちろんオンライン診療を実施するための基準を満たしていることが前提です)。 まさに 患者とつながる電子カルテ ということを実現したプロダクトとなります。 もちろんセキュリティ統制の強化についても昨年から本格的に取り組んできておりまして、3 省 4 ガイドラインへの準拠は当然のことながら、第 3 者認証機関による認証取得に向けても動いています ( TRUSTe 取得完了 、ISMS 取得作業中)。   医療 IT の課題とアプローチ しかし、CLINICS カルテをはじめとしたクラウド電子カルテが普及するには時間がかかると考えています。 クラウドサービスに慣れた若い世代が開業し、システム導入の意思決定をするための世代交代に一定以上の時間が必要であるというのはもちろんですが、それ以上に 医療情報システム関連技術の標準化が遅れている ことや、ローカルネットワークを前提とする 院内システムのエコシステムができあがっている ためです。これにより、ウェブ系の新興プレイヤーが参入することが難しくなり、結果として医療業界全体がテクノロジーの進化の恩恵をうけづらくなっているように感じます。 この現状をふまえ、我々は CLINICS カルテの公開とあわせて、医療 IT の世界をオープンにし、様々な新興プレイヤーが参入しやすい土壌をつくることについてもコミットしていきたいと考えています。その思いが**「ORCA API のオープンソース公開」 と 「ブロックチェーンを活用した電子処方せん管理方式に関する特許出願」**という 2 つのニュースリリースにあらわれています。  ORCA API のオープンソース公開 ORCA API は ORCA((正確には ORCA プロジェクトが提供している日医標準レセプトソフト))が提供する API を Ruby から利用するためのライブラリです。ORCA API をオープンソースとして公開することで、ORCA と接続するウェブアプリケーションの開発が促進されることを期待するものです。 github.com ブロックチェーンを活用した電子処方せん管理方式に関する特許出願 電子処方せんに関してはすでに 実装ガイド が作成され指針が示されていますが、この中で認められているように、実装ガイドに基づいて電子処方せんシステムを実装しても実運用で使うにはいくつかの課題が残ります。また、それらの課題を解決するために 今後の方向性についての議論 も行われているようですが、なかなか前に進む気配が見られません。 それに対する我々からのひとつの考えを示してみたのが今回の特許出願となります (我々が独占的に利用するといった意図の特許出願ではありません)。 名称 電子処方せん管理方法、電子処方せん管理システム、及びプログラム 内容 処方せんの電磁的記録による作成、交付及び保存を実施するための電子処方せん管理方法、電子処方せん管理システム、及びプログラム 概要 ＡＳＰサーバを用いずとも、実運用が可能な電子処方せんを実現するもの この 2 つは現状の医療 IT に存在している課題に対してアプローチしたものになりますが、これ以外にも検査結果データの標準化や HPKI のオープン化と促進 (特定プラットフォーム依存性の排除)、SS-MIX の促進など、標準化という観点で医療 IT の世界には取り組むべき課題が多くあります。 標準化においてはトップダウンによるアプローチが理想だと思いますが、トップダウンでの標準化には時間がかかり、 テクノロジーの進化の時間軸との間にギャップ が発生しがちです。我々は今回の ORCA API や電子処方せんブロックチェーンでのアプローチのように、トップダウンでの標準化の動きを待つだけでなく、テクノロジーを活用した ボトムアップの技術提案 も積極的に行っていきたいと考えています。 その結果として、技術の標準化が進み、新興プレイヤーが増え、医療機関間の連携も円滑になり、地域医療構想のような動きも加速され、医療現場の IT 化が進み、医療従事者が診療により専念できる環境がつくられる。 そのような世界の実現にむけて我々は取り組んでいくという意思を明確にするために、今回のニュースリリースを公開させて頂きました。 医療 IT の未来に向けて toppa.medley.jp 以前このブログでも書いたとおり、インターネット業界で活躍してきたような、高い能力をもちプロダクトにこだわりをもって開発をしてきたような人が圧倒的に少ないことが、医療 IT における課題であると私は思っています。 若く優秀なクリエイターたちが医療 IT の世界に参加し、様々な取り組みをすることで、業界内の循環が進み、結果として業界の進化にもつながるものと考えています。まずは我々が積極的に技術をオープンにしていくことで、その流れの起点をつくっていきたいと思います。  メドレーは「医療ヘルスケア分野の課題を解決する」というミッションのもと、医療 IT の世界における標準化の課題に対しても積極的にアプローチしていきます。 さいごに メドレーではこのような医療業界に存在する課題に取り組んでいきたいメンバーをデザイナー・エンジニアを中心に全職種絶賛募集中です。皆さまからのご応募お待ちしております。 www.medley.jp

こんにちは、平山です。メドレーのプロダクト開発全般を管掌しています。先日 4/29 (日)に虎ノ門ヒルズフォーラムで開催された CLINICS SUMMIT 2018 と合わせて、3 本のニュースリリースをだしました。 これらのニュースリリースはひとつのストーリーにもとづいているのですが、それぞれを読んだだけではメッセージが伝わりづらいと思いますので、このブログで補足させて頂きます。 ニュースリリース www.medley.jp www.medley.jp www.medley.jp オンライン診療システムのいま まず背景として我々が提供しているプロダクト「CLINICS」について振り返るところから話を進めます。 オンライン診療システム CLINICS は、2015 年 8 月に厚生労働省から示された遠隔診療に関する通知をうけて、2016 年 2 月にプロダクトをローンチしたところからはじまりました。 ローンチ当初はネイティブアプリもなくウェブアプリケーションのみで、オンライン診療の肝となるビデオチャット機能も外部サービスで代替するなど、わかりやすい MVP (Minimum Viable Product) からスタートしました。その後、様々な医療機関で利用頂き、多くの医療機関スタッフの皆様からの叱咤激励をうけながら、プロダクトやオペレーションを磨き進化を続けて参りました。 その結果として、現在では契約医療機関は 800 を超え、1 ヶ月に 100 回以上ものオンライン診療を実施するような医療機関もでてきました。また 平成 30 年度の診療報酬改定 では オンライン診療料が新設 され、オンライン診療というものが正式に医療の現場で認められるようになってきています。 しかし、オンライン診療システムの進化の中で常につきまとう課題がありました。それは 電子カルテや医事会計システムなど医療機関の中心で使われるシステムとの連携 です。  オンライン診療から電子カルテへ 医療現場の業務において中心で使われるシステムはオンライン診療システムではなく、一般的には電子カルテや医事会計システムとなります。 オンライン診療システムは、予約、問診、診察、会計、薬または処方せんの配送、これら一連の業務を対面・オンラインに限らずにワンストップで処理できるという思想で開発を進めてきました。しかし、実際の現場においては、オンライン診療システムでの業務と電子カルテシステムでの業務を連携させるために人手を介在させる必要があり、オンライン診療システムをいれると現場オペレーションが増えてしまうといった課題がありました。 このオンライン診療システムにつきまとう課題を解決するため、昨年より電子カルテに関する調査を進めてきました。他社電子カルテシステムとの連携など様々な選択肢があったなか、この調査を経て 現状の電子カルテをとりまく課題と将来の可能性 を感じ、電子カルテを内製で開発しオンライン診療システムを電子カルテシステムに進化させるという結論に至りました。 おりしも 2017 年は 3 省 4 ガイドラインの改定 (医療情報システムの安全管理に関するガイドライン第 5 版) や、日本医師会 ORCA 管理機構による 日レセクラウド や API 拡張 (HAORI) の提供開始などの動きがあり、医療業界においてもクラウド化の波が確実にきていることを感じました。これが電子カルテ開発の背景です。  患者とつながる電子カルテ「CLINICS カルテ」 開発した電子カルテシステム「CLINICS カルテ」は、医事会計ソフトである ORCA を会計エンジンとして組み込んだ ORCA 内包型のクラウド電子カルテ となります。 医療機関のスタッフは予約から受付、患者管理、診察、オーダリング、会計、請求といった、ひととおりの業務をウェブブラウザだけあれば行うことができます。またオンライン診療の機能が搭載されているため、患者がアプリから予約しチェックインした情報をもとに、医療機関スタッフが患者情報を登録し、そのままオンライン診療を実施し、会計まで進めるということも可能となります(もちろんオンライン診療を実施するための基準を満たしていることが前提です)。 まさに 患者とつながる電子カルテ ということを実現したプロダクトとなります。 もちろんセキュリティ統制の強化についても昨年から本格的に取り組んできておりまして、3 省 4 ガイドラインへの準拠は当然のことながら、第 3 者認証機関による認証取得に向けても動いています ( TRUSTe 取得完了 、ISMS 取得作業中)。   医療 IT の課題とアプローチ しかし、CLINICS カルテをはじめとしたクラウド電子カルテが普及するには時間がかかると考えています。 クラウドサービスに慣れた若い世代が開業し、システム導入の意思決定をするための世代交代に一定以上の時間が必要であるというのはもちろんですが、それ以上に 医療情報システム関連技術の標準化が遅れている ことや、ローカルネットワークを前提とする 院内システムのエコシステムができあがっている ためです。これにより、ウェブ系の新興プレイヤーが参入することが難しくなり、結果として医療業界全体がテクノロジーの進化の恩恵をうけづらくなっているように感じます。 この現状をふまえ、我々は CLINICS カルテの公開とあわせて、医療 IT の世界をオープンにし、様々な新興プレイヤーが参入しやすい土壌をつくることについてもコミットしていきたいと考えています。その思いが**「ORCA API のオープンソース公開」 と 「ブロックチェーンを活用した電子処方せん管理方式に関する特許出願」**という 2 つのニュースリリースにあらわれています。  ORCA API のオープンソース公開 ORCA API は ORCA((正確には ORCA プロジェクトが提供している日医標準レセプトソフト))が提供する API を Ruby から利用するためのライブラリです。ORCA API をオープンソースとして公開することで、ORCA と接続するウェブアプリケーションの開発が促進されることを期待するものです。 github.com ブロックチェーンを活用した電子処方せん管理方式に関する特許出願 電子処方せんに関してはすでに 実装ガイド が作成され指針が示されていますが、この中で認められているように、実装ガイドに基づいて電子処方せんシステムを実装しても実運用で使うにはいくつかの課題が残ります。また、それらの課題を解決するために 今後の方向性についての議論 も行われているようですが、なかなか前に進む気配が見られません。 それに対する我々からのひとつの考えを示してみたのが今回の特許出願となります (我々が独占的に利用するといった意図の特許出願ではありません)。 col 1 col 2 名称 電子処方せん管理方法、電子処方せん管理システム、及びプログラム 内容 処方せんの電磁的記録による作成、交付及び保存を実施するための電子処方せん管理方法、電子処方せん管理システム、及びプログラム 概要 ＡＳＰサーバを用いずとも、実運用が可能な電子処方せんを実現するもの この 2 つは現状の医療 IT に存在している課題に対してアプローチしたものになりますが、これ以外にも検査結果データの標準化や HPKI のオープン化と促進 (特定プラットフォーム依存性の排除)、SS-MIX の促進など、標準化という観点で医療 IT の世界には取り組むべき課題が多くあります。 標準化においてはトップダウンによるアプローチが理想だと思いますが、トップダウンでの標準化には時間がかかり、 テクノロジーの進化の時間軸との間にギャップ が発生しがちです。我々は今回の ORCA API や電子処方せんブロックチェーンでのアプローチのように、トップダウンでの標準化の動きを待つだけでなく、テクノロジーを活用した ボトムアップの技術提案 も積極的に行っていきたいと考えています。 その結果として、技術の標準化が進み、新興プレイヤーが増え、医療機関間の連携も円滑になり、地域医療構想のような動きも加速され、医療現場の IT 化が進み、医療従事者が診療により専念できる環境がつくられる。 そのような世界の実現にむけて我々は取り組んでいくという意思を明確にするために、今回のニュースリリースを公開させて頂きました。 医療 IT の未来に向けて toppa.medley.jp 以前このブログでも書いたとおり、インターネット業界で活躍してきたような、高い能力をもちプロダクトにこだわりをもって開発をしてきたような人が圧倒的に少ないことが、医療 IT における課題であると私は思っています。 若く優秀なクリエイターたちが医療 IT の世界に参加し、様々な取り組みをすることで、業界内の循環が進み、結果として業界の進化にもつながるものと考えています。まずは我々が積極的に技術をオープンにしていくことで、その流れの起点をつくっていきたいと思います。  メドレーは「医療ヘルスケア分野の課題を解決する」というミッションのもと、医療 IT の世界における標準化の課題に対しても積極的にアプローチしていきます。 さいごに メドレーではこのような医療業界に存在する課題に取り組んでいきたいメンバーをデザイナー・エンジニアを中心に全職種絶賛募集中です。皆さまからのご応募お待ちしております。 www.medley.jp

こんにちは、開発本部の舘野です。 先日、メドレーで定期開催している社内勉強会「TechLunch」にて、Design System について発表しました。医療介護の求人サイト「 ジョブメドレー 」において、Design System を「小さく始める」手法で導入を進めているので、そのプロセスについて紹介させていただこうと思います。 Design System とは何か Design System とは、Salesforce の Lightning Design System や IBM の Carbon Design System などが代表的な例として挙げられると思いますが、平たく言ってしまうとプロダクト独自の Bootstrap となるものです。 UI 開発の領域では、これまでスタイルガイドを作ることでデザイナーとエンジニア間の共通言語とし、プロダクトの UI の一貫性を保つように努めることが一般的かと思いますが、Design System ではスタイルガイドだけでなくデザインの原則や UI コンポーネントの CSS や JS なども含めてプロダクトのインターフェースに関わる全てを、1 つのプロダクトとする考え方です。 Design System はスタイルガイドと明確にどこが違うのかについて言及しているウェブ上の記事の多くは、Nathan Curtis 氏の 「A Design System isn’t a Project. It’s a Product, Serving Products.」 という言葉を引用して、その差異を示しています。 スタイルガイドがプロダクトにおけるプロジェクト以上の存在ではないのに対して、Design System はプロダクトに対して UI のエコシステムを提供するプロダクトである、ということが Design System の基幹となる考え方だと思います。 ジョブメドレーにおける Design System TechLunch で発表したスライドはこちら。 今回 Design System を段階的に導入しているのは、医療介護の求人サイト「ジョブメドレー」です。 ジョブメドレーのインターフェースが今後より一層色々な形でユーザに使われる場面が増えていくことが想定される中で、プロダクトの UI の一貫性や生産性を担保し続けていくためには、スタイルガイドを作るだけでなく Design System によってより包括的にプロダクトの UI 開発に対する取り組み方を変える必要があるのではと考えていました。 とはいえ最初からプロダクトの UI 全てを Design System に置き換えるというのは変化が大き過ぎるし、Design System がうまく機能せずに失敗する場合も考慮しておく必要があったので、導入がうまくいかないければすぐにやめられるように以下の点を導入前に決めていました。 最初から一気に色々やらない まずは一部だけ導入してみる 上手くいく部分といかない部分を検証する Design System の改善と段階導入を繰り返す Design System はプロダクトに UI のエコシステムを提供するプロダクトなので、一定期間で作って終わりではなく継続して改善を繰り返していくという点では、このような進め方が適切と考えました。 実際のところ、現在のジョブメドレーでは一部分だけジョブメドレーの Design System として npm 化したモジュールから提供するようにしています。 npm 化して Design System から提供するようにしたのは、以下の 3 つのみです。 jmds-tools sass mixin や function を提供するユーティリティモジュール jmds-tokens design tokens（デザイン上の値を信頼できる唯一の情報源として 1 つの場所で定義されるもの） jmds-flex flexbox ユーティリティ プロダクトの UI として見ると、flexbox のユーティリティクラスを Design system から提供するようになっただけです。 ただ、今は全体のごく一部が Design System から提供されていますが、Design System に移行できる UI コンポーネントを選定して段階的に npm 化をしていくことで、プロダクトの UI コンポーネントの多くが Design System から提供されている状態にすることが可能だと思います。 単純に npm 化することが目的ではなく、npm 化した Design System をプロダクトチームでメンテナンスしていくことで、より一貫性のある UI をジョブメドレーのプロダクトに提供していくことが目的です。 まとめ 今回は、TechLunch で発表したジョブメドレーにおける Design System の取り組みについて紹介させていただきました。 今回紹介した Design System が今後デザイナー、エンジニア、プロダクトマネージャーと協力しながら、ジョブメドレーのプロダクトの UI を支える強固な土台へと成長させられるように取り組んでいこうと思います。 お知らせ メドレーでは、医療介護の求人サイト「ジョブメドレー」の他にも、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」、オンライン診療アプリ「 CLINICS 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 ちょっと興味があるという方も、ぜひお気軽にご連絡ください！ メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは、開発本部の舘野です。 先日、メドレーで定期開催している社内勉強会「TechLunch」にて、Design System について発表しました。医療介護の求人サイト「 ジョブメドレー 」において、Design System を「小さく始める」手法で導入を進めているので、そのプロセスについて紹介させていただこうと思います。 Design System とは何か Design System とは、Salesforce の Lightning Design System や IBM の Carbon Design System などが代表的な例として挙げられると思いますが、平たく言ってしまうとプロダクト独自の Bootstrap となるものです。 UI 開発の領域では、これまでスタイルガイドを作ることでデザイナーとエンジニア間の共通言語とし、プロダクトの UI の一貫性を保つように努めることが一般的かと思いますが、Design System ではスタイルガイドだけでなくデザインの原則や UI コンポーネントの CSS や JS なども含めてプロダクトのインターフェースに関わる全てを、1 つのプロダクトとする考え方です。 Design System はスタイルガイドと明確にどこが違うのかについて言及しているウェブ上の記事の多くは、Nathan Curtis 氏の 「A Design System isn’t a Project. It’s a Product, Serving Products.」 という言葉を引用して、その差異を示しています。 スタイルガイドがプロダクトにおけるプロジェクト以上の存在ではないのに対して、Design System はプロダクトに対して UI のエコシステムを提供するプロダクトである、ということが Design System の基幹となる考え方だと思います。 ジョブメドレーにおける Design System TechLunch で発表したスライドはこちら。 今回 Design System を段階的に導入しているのは、医療介護の求人サイト「ジョブメドレー」です。 ジョブメドレーのインターフェースが今後より一層色々な形でユーザに使われる場面が増えていくことが想定される中で、プロダクトの UI の一貫性や生産性を担保し続けていくためには、スタイルガイドを作るだけでなく Design System によってより包括的にプロダクトの UI 開発に対する取り組み方を変える必要があるのではと考えていました。 とはいえ最初からプロダクトの UI 全てを Design System に置き換えるというのは変化が大き過ぎるし、Design System がうまく機能せずに失敗する場合も考慮しておく必要があったので、導入がうまくいかないければすぐにやめられるように以下の点を導入前に決めていました。 最初から一気に色々やらない まずは一部だけ導入してみる 上手くいく部分といかない部分を検証する Design System の改善と段階導入を繰り返す Design System はプロダクトに UI のエコシステムを提供するプロダクトなので、一定期間で作って終わりではなく継続して改善を繰り返していくという点では、このような進め方が適切と考えました。 実際のところ、現在のジョブメドレーでは一部分だけジョブメドレーの Design System として npm 化したモジュールから提供するようにしています。 npm 化して Design System から提供するようにしたのは、以下の 3 つのみです。 jmds-tools sass mixin や function を提供するユーティリティモジュール jmds-tokens design tokens（デザイン上の値を信頼できる唯一の情報源として 1 つの場所で定義されるもの） jmds-flex flexbox ユーティリティ プロダクトの UI として見ると、flexbox のユーティリティクラスを Design system から提供するようになっただけです。 ただ、今は全体のごく一部が Design System から提供されていますが、Design System に移行できる UI コンポーネントを選定して段階的に npm 化をしていくことで、プロダクトの UI コンポーネントの多くが Design System から提供されている状態にすることが可能だと思います。 単純に npm 化することが目的ではなく、npm 化した Design System をプロダクトチームでメンテナンスしていくことで、より一貫性のある UI をジョブメドレーのプロダクトに提供していくことが目的です。 まとめ 今回は、TechLunch で発表したジョブメドレーにおける Design System の取り組みについて紹介させていただきました。 今回紹介した Design System が今後デザイナー、エンジニア、プロダクトマネージャーと協力しながら、ジョブメドレーのプロダクトの UI を支える強固な土台へと成長させられるように取り組んでいこうと思います。 お知らせ メドレーでは、医療介護の求人サイト「ジョブメドレー」の他にも、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」、オンライン診療アプリ「 CLINICS 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 ちょっと興味があるという方も、ぜひお気軽にご連絡ください！ https://www.medley.jp/recruit/creative.html

こんにちは、開発本部の舘野です。 先日、メドレーで定期開催している社内勉強会「TechLunch」にて、Design System について発表しました。医療介護の求人サイト「 ジョブメドレー 」において、Design System を「小さく始める」手法で導入を進めているので、そのプロセスについて紹介させていただこうと思います。 Design System とは何か Design System とは、Salesforce の Lightning Design System や IBM の Carbon Design System などが代表的な例として挙げられると思いますが、平たく言ってしまうとプロダクト独自の Bootstrap となるものです。 UI 開発の領域では、これまでスタイルガイドを作ることでデザイナーとエンジニア間の共通言語とし、プロダクトの UI の一貫性を保つように努めることが一般的かと思いますが、Design System ではスタイルガイドだけでなくデザインの原則や UI コンポーネントの CSS や JS なども含めてプロダクトのインターフェースに関わる全てを、1 つのプロダクトとする考え方です。 Design System はスタイルガイドと明確にどこが違うのかについて言及しているウェブ上の記事の多くは、Nathan Curtis 氏の 「A Design System isn’t a Project. It’s a Product, Serving Products.」 という言葉を引用して、その差異を示しています。 スタイルガイドがプロダクトにおけるプロジェクト以上の存在ではないのに対して、Design System はプロダクトに対して UI のエコシステムを提供するプロダクトである、ということが Design System の基幹となる考え方だと思います。 ジョブメドレーにおける Design System TechLunch で発表したスライドはこちら。 今回 Design System を段階的に導入しているのは、医療介護の求人サイト「ジョブメドレー」です。 ジョブメドレーのインターフェースが今後より一層色々な形でユーザに使われる場面が増えていくことが想定される中で、プロダクトの UI の一貫性や生産性を担保し続けていくためには、スタイルガイドを作るだけでなく Design System によってより包括的にプロダクトの UI 開発に対する取り組み方を変える必要があるのではと考えていました。 とはいえ最初からプロダクトの UI 全てを Design System に置き換えるというのは変化が大き過ぎるし、Design System がうまく機能せずに失敗する場合も考慮しておく必要があったので、導入がうまくいかないければすぐにやめられるように以下の点を導入前に決めていました。 最初から一気に色々やらない まずは一部だけ導入してみる 上手くいく部分といかない部分を検証する Design System の改善と段階導入を繰り返す Design System はプロダクトに UI のエコシステムを提供するプロダクトなので、一定期間で作って終わりではなく継続して改善を繰り返していくという点では、このような進め方が適切と考えました。 実際のところ、現在のジョブメドレーでは一部分だけジョブメドレーの Design System として npm 化したモジュールから提供するようにしています。 npm 化して Design System から提供するようにしたのは、以下の 3 つのみです。 jmds-tools sass mixin や function を提供するユーティリティモジュール jmds-tokens design tokens（デザイン上の値を信頼できる唯一の情報源として 1 つの場所で定義されるもの） jmds-flex flexbox ユーティリティ プロダクトの UI として見ると、flexbox のユーティリティクラスを Design system から提供するようになっただけです。 ただ、今は全体のごく一部が Design System から提供されていますが、Design System に移行できる UI コンポーネントを選定して段階的に npm 化をしていくことで、プロダクトの UI コンポーネントの多くが Design System から提供されている状態にすることが可能だと思います。 単純に npm 化することが目的ではなく、npm 化した Design System をプロダクトチームでメンテナンスしていくことで、より一貫性のある UI をジョブメドレーのプロダクトに提供していくことが目的です。 まとめ 今回は、TechLunch で発表したジョブメドレーにおける Design System の取り組みについて紹介させていただきました。 今回紹介した Design System が今後デザイナー、エンジニア、プロダクトマネージャーと協力しながら、ジョブメドレーのプロダクトの UI を支える強固な土台へと成長させられるように取り組んでいこうと思います。 お知らせ メドレーでは、医療介護の求人サイト「ジョブメドレー」の他にも、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」、オンライン診療アプリ「 CLINICS 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 ちょっと興味があるという方も、ぜひお気軽にご連絡ください！ メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは、開発本部の舘野です。 先日、メドレーで定期開催している社内勉強会「TechLunch」にて、Design System について発表しました。医療介護の求人サイト「 ジョブメドレー 」において、Design System を「小さく始める」手法で導入を進めているので、そのプロセスについて紹介させていただこうと思います。 Design System とは何か Design System とは、Salesforce の Lightning Design System や IBM の Carbon Design System などが代表的な例として挙げられると思いますが、平たく言ってしまうとプロダクト独自の Bootstrap となるものです。 UI 開発の領域では、これまでスタイルガイドを作ることでデザイナーとエンジニア間の共通言語とし、プロダクトの UI の一貫性を保つように努めることが一般的かと思いますが、Design System ではスタイルガイドだけでなくデザインの原則や UI コンポーネントの CSS や JS なども含めてプロダクトのインターフェースに関わる全てを、1 つのプロダクトとする考え方です。 Design System はスタイルガイドと明確にどこが違うのかについて言及しているウェブ上の記事の多くは、Nathan Curtis 氏の 「A Design System isn’t a Project. It’s a Product, Serving Products.」 という言葉を引用して、その差異を示しています。 スタイルガイドがプロダクトにおけるプロジェクト以上の存在ではないのに対して、Design System はプロダクトに対して UI のエコシステムを提供するプロダクトである、ということが Design System の基幹となる考え方だと思います。 ジョブメドレーにおける Design System TechLunch で発表したスライドはこちら。 今回 Design System を段階的に導入しているのは、医療介護の求人サイト「ジョブメドレー」です。 ジョブメドレーのインターフェースが今後より一層色々な形でユーザに使われる場面が増えていくことが想定される中で、プロダクトの UI の一貫性や生産性を担保し続けていくためには、スタイルガイドを作るだけでなく Design System によってより包括的にプロダクトの UI 開発に対する取り組み方を変える必要があるのではと考えていました。 とはいえ最初からプロダクトの UI 全てを Design System に置き換えるというのは変化が大き過ぎるし、Design System がうまく機能せずに失敗する場合も考慮しておく必要があったので、導入がうまくいかないければすぐにやめられるように以下の点を導入前に決めていました。 最初から一気に色々やらない まずは一部だけ導入してみる 上手くいく部分といかない部分を検証する Design System の改善と段階導入を繰り返す Design System はプロダクトに UI のエコシステムを提供するプロダクトなので、一定期間で作って終わりではなく継続して改善を繰り返していくという点では、このような進め方が適切と考えました。 実際のところ、現在のジョブメドレーでは一部分だけジョブメドレーの Design System として npm 化したモジュールから提供するようにしています。 npm 化して Design System から提供するようにしたのは、以下の 3 つのみです。 jmds-tools sass mixin や function を提供するユーティリティモジュール jmds-tokens design tokens（デザイン上の値を信頼できる唯一の情報源として 1 つの場所で定義されるもの） jmds-flex flexbox ユーティリティ プロダクトの UI として見ると、flexbox のユーティリティクラスを Design system から提供するようになっただけです。 ただ、今は全体のごく一部が Design System から提供されていますが、Design System に移行できる UI コンポーネントを選定して段階的に npm 化をしていくことで、プロダクトの UI コンポーネントの多くが Design System から提供されている状態にすることが可能だと思います。 単純に npm 化することが目的ではなく、npm 化した Design System をプロダクトチームでメンテナンスしていくことで、より一貫性のある UI をジョブメドレーのプロダクトに提供していくことが目的です。 まとめ 今回は、TechLunch で発表したジョブメドレーにおける Design System の取り組みについて紹介させていただきました。 今回紹介した Design System が今後デザイナー、エンジニア、プロダクトマネージャーと協力しながら、ジョブメドレーのプロダクトの UI を支える強固な土台へと成長させられるように取り組んでいこうと思います。 お知らせ メドレーでは、医療介護の求人サイト「ジョブメドレー」の他にも、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」、オンライン診療アプリ「 CLINICS 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 ちょっと興味があるという方も、ぜひお気軽にご連絡ください！ メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは、開発本部の舘野です。 先日、メドレーで定期開催している社内勉強会「TechLunch」にて、Design System について発表しました。医療介護の求人サイト「 ジョブメドレー 」において、Design System を「小さく始める」手法で導入を進めているので、そのプロセスについて紹介させていただこうと思います。 Design System とは何か Design System とは、Salesforce の Lightning Design System や IBM の Carbon Design System などが代表的な例として挙げられると思いますが、平たく言ってしまうとプロダクト独自の Bootstrap となるものです。 UI 開発の領域では、これまでスタイルガイドを作ることでデザイナーとエンジニア間の共通言語とし、プロダクトの UI の一貫性を保つように努めることが一般的かと思いますが、Design System ではスタイルガイドだけでなくデザインの原則や UI コンポーネントの CSS や JS なども含めてプロダクトのインターフェースに関わる全てを、1 つのプロダクトとする考え方です。 Design System はスタイルガイドと明確にどこが違うのかについて言及しているウェブ上の記事の多くは、Nathan Curtis 氏の 「A Design System isn’t a Project. It’s a Product, Serving Products.」 という言葉を引用して、その差異を示しています。 スタイルガイドがプロダクトにおけるプロジェクト以上の存在ではないのに対して、Design System はプロダクトに対して UI のエコシステムを提供するプロダクトである、ということが Design System の基幹となる考え方だと思います。 ジョブメドレーにおける Design System TechLunch で発表したスライドはこちら。 今回 Design System を段階的に導入しているのは、医療介護の求人サイト「ジョブメドレー」です。 ジョブメドレーのインターフェースが今後より一層色々な形でユーザに使われる場面が増えていくことが想定される中で、プロダクトの UI の一貫性や生産性を担保し続けていくためには、スタイルガイドを作るだけでなく Design System によってより包括的にプロダクトの UI 開発に対する取り組み方を変える必要があるのではと考えていました。 とはいえ最初からプロダクトの UI 全てを Design System に置き換えるというのは変化が大き過ぎるし、Design System がうまく機能せずに失敗する場合も考慮しておく必要があったので、導入がうまくいかないければすぐにやめられるように以下の点を導入前に決めていました。 最初から一気に色々やらない まずは一部だけ導入してみる 上手くいく部分といかない部分を検証する Design System の改善と段階導入を繰り返す Design System はプロダクトに UI のエコシステムを提供するプロダクトなので、一定期間で作って終わりではなく継続して改善を繰り返していくという点では、このような進め方が適切と考えました。 実際のところ、現在のジョブメドレーでは一部分だけジョブメドレーの Design System として npm 化したモジュールから提供するようにしています。 npm 化して Design System から提供するようにしたのは、以下の 3 つのみです。 jmds-tools sass mixin や function を提供するユーティリティモジュール jmds-tokens design tokens（デザイン上の値を信頼できる唯一の情報源として 1 つの場所で定義されるもの） jmds-flex flexbox ユーティリティ プロダクトの UI として見ると、flexbox のユーティリティクラスを Design system から提供するようになっただけです。 ただ、今は全体のごく一部が Design System から提供されていますが、Design System に移行できる UI コンポーネントを選定して段階的に npm 化をしていくことで、プロダクトの UI コンポーネントの多くが Design System から提供されている状態にすることが可能だと思います。 単純に npm 化することが目的ではなく、npm 化した Design System をプロダクトチームでメンテナンスしていくことで、より一貫性のある UI をジョブメドレーのプロダクトに提供していくことが目的です。 まとめ 今回は、TechLunch で発表したジョブメドレーにおける Design System の取り組みについて紹介させていただきました。 今回紹介した Design System が今後デザイナー、エンジニア、プロダクトマネージャーと協力しながら、ジョブメドレーのプロダクトの UI を支える強固な土台へと成長させられるように取り組んでいこうと思います。 お知らせ メドレーでは、医療介護の求人サイト「ジョブメドレー」の他にも、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」、オンライン診療アプリ「 CLINICS 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 ちょっと興味があるという方も、ぜひお気軽にご連絡ください！ メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは、開発本部の舘野です。 先日、メドレーで定期開催している社内勉強会「TechLunch」にて、Design System について発表しました。医療介護の求人サイト「 ジョブメドレー 」において、Design System を「小さく始める」手法で導入を進めているので、そのプロセスについて紹介させていただこうと思います。 Design System とは何か Design System とは、Salesforce の Lightning Design System や IBM の Carbon Design System などが代表的な例として挙げられると思いますが、平たく言ってしまうとプロダクト独自の Bootstrap となるものです。 UI 開発の領域では、これまでスタイルガイドを作ることでデザイナーとエンジニア間の共通言語とし、プロダクトの UI の一貫性を保つように努めることが一般的かと思いますが、Design System ではスタイルガイドだけでなくデザインの原則や UI コンポーネントの CSS や JS なども含めてプロダクトのインターフェースに関わる全てを、1 つのプロダクトとする考え方です。 Design System はスタイルガイドと明確にどこが違うのかについて言及しているウェブ上の記事の多くは、Nathan Curtis 氏の 「A Design System isn’t a Project. It’s a Product, Serving Products.」 という言葉を引用して、その差異を示しています。 スタイルガイドがプロダクトにおけるプロジェクト以上の存在ではないのに対して、Design System はプロダクトに対して UI のエコシステムを提供するプロダクトである、ということが Design System の基幹となる考え方だと思います。 ジョブメドレーにおける Design System TechLunch で発表したスライドはこちら。 今回 Design System を段階的に導入しているのは、医療介護の求人サイト「ジョブメドレー」です。 ジョブメドレーのインターフェースが今後より一層色々な形でユーザに使われる場面が増えていくことが想定される中で、プロダクトの UI の一貫性や生産性を担保し続けていくためには、スタイルガイドを作るだけでなく Design System によってより包括的にプロダクトの UI 開発に対する取り組み方を変える必要があるのではと考えていました。 とはいえ最初からプロダクトの UI 全てを Design System に置き換えるというのは変化が大き過ぎるし、Design System がうまく機能せずに失敗する場合も考慮しておく必要があったので、導入がうまくいかないければすぐにやめられるように以下の点を導入前に決めていました。 最初から一気に色々やらない まずは一部だけ導入してみる 上手くいく部分といかない部分を検証する Design System の改善と段階導入を繰り返す Design System はプロダクトに UI のエコシステムを提供するプロダクトなので、一定期間で作って終わりではなく継続して改善を繰り返していくという点では、このような進め方が適切と考えました。 実際のところ、現在のジョブメドレーでは一部分だけジョブメドレーの Design System として npm 化したモジュールから提供するようにしています。 npm 化して Design System から提供するようにしたのは、以下の 3 つのみです。 jmds-tools sass mixin や function を提供するユーティリティモジュール jmds-tokens design tokens（デザイン上の値を信頼できる唯一の情報源として 1 つの場所で定義されるもの） jmds-flex flexbox ユーティリティ プロダクトの UI として見ると、flexbox のユーティリティクラスを Design system から提供するようになっただけです。 ただ、今は全体のごく一部が Design System から提供されていますが、Design System に移行できる UI コンポーネントを選定して段階的に npm 化をしていくことで、プロダクトの UI コンポーネントの多くが Design System から提供されている状態にすることが可能だと思います。 単純に npm 化することが目的ではなく、npm 化した Design System をプロダクトチームでメンテナンスしていくことで、より一貫性のある UI をジョブメドレーのプロダクトに提供していくことが目的です。 まとめ 今回は、TechLunch で発表したジョブメドレーにおける Design System の取り組みについて紹介させていただきました。 今回紹介した Design System が今後デザイナー、エンジニア、プロダクトマネージャーと協力しながら、ジョブメドレーのプロダクトの UI を支える強固な土台へと成長させられるように取り組んでいこうと思います。 お知らせ メドレーでは、医療介護の求人サイト「ジョブメドレー」の他にも、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」、オンライン診療アプリ「 CLINICS 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 ちょっと興味があるという方も、ぜひお気軽にご連絡ください！ メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは、開発本部の舘野です。 先日、メドレーで定期開催している社内勉強会「TechLunch」にて、Design System について発表しました。医療介護の求人サイト「 ジョブメドレー 」において、Design System を「小さく始める」手法で導入を進めているので、そのプロセスについて紹介させていただこうと思います。 Design System とは何か Design System とは、Salesforce の Lightning Design System や IBM の Carbon Design System などが代表的な例として挙げられると思いますが、平たく言ってしまうとプロダクト独自の Bootstrap となるものです。 UI 開発の領域では、これまでスタイルガイドを作ることでデザイナーとエンジニア間の共通言語とし、プロダクトの UI の一貫性を保つように努めることが一般的かと思いますが、Design System ではスタイルガイドだけでなくデザインの原則や UI コンポーネントの CSS や JS なども含めてプロダクトのインターフェースに関わる全てを、1 つのプロダクトとする考え方です。 Design System はスタイルガイドと明確にどこが違うのかについて言及しているウェブ上の記事の多くは、Nathan Curtis 氏の 「A Design System isn’t a Project. It’s a Product, Serving Products.」 という言葉を引用して、その差異を示しています。 スタイルガイドがプロダクトにおけるプロジェクト以上の存在ではないのに対して、Design System はプロダクトに対して UI のエコシステムを提供するプロダクトである、ということが Design System の基幹となる考え方だと思います。 ジョブメドレーにおける Design System TechLunch で発表したスライドはこちら。 今回 Design System を段階的に導入しているのは、医療介護の求人サイト「ジョブメドレー」です。 ジョブメドレーのインターフェースが今後より一層色々な形でユーザに使われる場面が増えていくことが想定される中で、プロダクトの UI の一貫性や生産性を担保し続けていくためには、スタイルガイドを作るだけでなく Design System によってより包括的にプロダクトの UI 開発に対する取り組み方を変える必要があるのではと考えていました。 とはいえ最初からプロダクトの UI 全てを Design System に置き換えるというのは変化が大き過ぎるし、Design System がうまく機能せずに失敗する場合も考慮しておく必要があったので、導入がうまくいかないければすぐにやめられるように以下の点を導入前に決めていました。 最初から一気に色々やらない まずは一部だけ導入してみる 上手くいく部分といかない部分を検証する Design System の改善と段階導入を繰り返す Design System はプロダクトに UI のエコシステムを提供するプロダクトなので、一定期間で作って終わりではなく継続して改善を繰り返していくという点では、このような進め方が適切と考えました。 実際のところ、現在のジョブメドレーでは一部分だけジョブメドレーの Design System として npm 化したモジュールから提供するようにしています。 npm 化して Design System から提供するようにしたのは、以下の 3 つのみです。 jmds-tools sass mixin や function を提供するユーティリティモジュール jmds-tokens design tokens（デザイン上の値を信頼できる唯一の情報源として 1 つの場所で定義されるもの） jmds-flex flexbox ユーティリティ プロダクトの UI として見ると、flexbox のユーティリティクラスを Design system から提供するようになっただけです。 ただ、今は全体のごく一部が Design System から提供されていますが、Design System に移行できる UI コンポーネントを選定して段階的に npm 化をしていくことで、プロダクトの UI コンポーネントの多くが Design System から提供されている状態にすることが可能だと思います。 単純に npm 化することが目的ではなく、npm 化した Design System をプロダクトチームでメンテナンスしていくことで、より一貫性のある UI をジョブメドレーのプロダクトに提供していくことが目的です。 まとめ 今回は、TechLunch で発表したジョブメドレーにおける Design System の取り組みについて紹介させていただきました。 今回紹介した Design System が今後デザイナー、エンジニア、プロダクトマネージャーと協力しながら、ジョブメドレーのプロダクトの UI を支える強固な土台へと成長させられるように取り組んでいこうと思います。 お知らせ メドレーでは、医療介護の求人サイト「ジョブメドレー」の他にも、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」、オンライン診療アプリ「 CLINICS 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 ちょっと興味があるという方も、ぜひお気軽にご連絡ください！ メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは、開発本部の舘野です。 先日、メドレーで定期開催している社内勉強会「TechLunch」にて、Design System について発表しました。医療介護の求人サイト「 ジョブメドレー 」において、Design System を「小さく始める」手法で導入を進めているので、そのプロセスについて紹介させていただこうと思います。 Design System とは何か Design System とは、Salesforce の Lightning Design System や IBM の Carbon Design System などが代表的な例として挙げられると思いますが、平たく言ってしまうとプロダクト独自の Bootstrap となるものです。 UI 開発の領域では、これまでスタイルガイドを作ることでデザイナーとエンジニア間の共通言語とし、プロダクトの UI の一貫性を保つように努めることが一般的かと思いますが、Design System ではスタイルガイドだけでなくデザインの原則や UI コンポーネントの CSS や JS なども含めてプロダクトのインターフェースに関わる全てを、1 つのプロダクトとする考え方です。 Design System はスタイルガイドと明確にどこが違うのかについて言及しているウェブ上の記事の多くは、Nathan Curtis 氏の 「A Design System isn’t a Project. It’s a Product, Serving Products.」 という言葉を引用して、その差異を示しています。 スタイルガイドがプロダクトにおけるプロジェクト以上の存在ではないのに対して、Design System はプロダクトに対して UI のエコシステムを提供するプロダクトである、ということが Design System の基幹となる考え方だと思います。 ジョブメドレーにおける Design System TechLunch で発表したスライドはこちら。 今回 Design System を段階的に導入しているのは、医療介護の求人サイト「ジョブメドレー」です。 ジョブメドレーのインターフェースが今後より一層色々な形でユーザに使われる場面が増えていくことが想定される中で、プロダクトの UI の一貫性や生産性を担保し続けていくためには、スタイルガイドを作るだけでなく Design System によってより包括的にプロダクトの UI 開発に対する取り組み方を変える必要があるのではと考えていました。 とはいえ最初からプロダクトの UI 全てを Design System に置き換えるというのは変化が大き過ぎるし、Design System がうまく機能せずに失敗する場合も考慮しておく必要があったので、導入がうまくいかないければすぐにやめられるように以下の点を導入前に決めていました。 最初から一気に色々やらない まずは一部だけ導入してみる 上手くいく部分といかない部分を検証する Design System の改善と段階導入を繰り返す Design System はプロダクトに UI のエコシステムを提供するプロダクトなので、一定期間で作って終わりではなく継続して改善を繰り返していくという点では、このような進め方が適切と考えました。 実際のところ、現在のジョブメドレーでは一部分だけジョブメドレーの Design System として npm 化したモジュールから提供するようにしています。 npm 化して Design System から提供するようにしたのは、以下の 3 つのみです。 jmds-tools sass mixin や function を提供するユーティリティモジュール jmds-tokens design tokens（デザイン上の値を信頼できる唯一の情報源として 1 つの場所で定義されるもの） jmds-flex flexbox ユーティリティ プロダクトの UI として見ると、flexbox のユーティリティクラスを Design system から提供するようになっただけです。 ただ、今は全体のごく一部が Design System から提供されていますが、Design System に移行できる UI コンポーネントを選定して段階的に npm 化をしていくことで、プロダクトの UI コンポーネントの多くが Design System から提供されている状態にすることが可能だと思います。 単純に npm 化することが目的ではなく、npm 化した Design System をプロダクトチームでメンテナンスしていくことで、より一貫性のある UI をジョブメドレーのプロダクトに提供していくことが目的です。 まとめ 今回は、TechLunch で発表したジョブメドレーにおける Design System の取り組みについて紹介させていただきました。 今回紹介した Design System が今後デザイナー、エンジニア、プロダクトマネージャーと協力しながら、ジョブメドレーのプロダクトの UI を支える強固な土台へと成長させられるように取り組んでいこうと思います。 お知らせ メドレーでは、医療介護の求人サイト「ジョブメドレー」の他にも、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」、オンライン診療アプリ「 CLINICS 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 ちょっと興味があるという方も、ぜひお気軽にご連絡ください！ メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

皆さんこんにちは。開発本部の日下です。普段は オンライン診療アプリ「CLINICS」 および オンライン医療事典「MEDLEY」 の開発を担当しています。（昨年、新卒で昨年メドレーに入ったのでエンジニア歴は 1 年弱。ベテランが多いメドレーのエンジニアチームで奮闘しています） 先日開催された エンジニア特化型 Q&A サイト「 teratail 」 さんのイベント、 MANABIYA にメドレーがスポンサーとして協力させていただきました。 エンジニアの平木と参加しましたので、イベント当日の様子をレポートします。 MANABIYA とは teratail はご存知の方も多いかもしれませんが、MANABIYA というイベントをご存じない方もいるかもしれません。 MANABIYA は今回が初開催のイベントで、”疑問” を日本中から集め、カンファレンスを通じて解決策を見出し、”知恵” を生み出すことを目的とし、秋葉原から近い 3331 Arts Chiyoda にて 2 日間に渡って開催されました。 全体の雰囲気 全体的に初開催とは思えないほど人が多く、一部のセッションでは教室が満杯になり、入場制限がかかるほどでした。また、speaker として豪華なメンバー面々が数多く集まっており、最初から最後まで、参加したすべてのセッションで立ち見が出てるほど盛況だったのがとても印象的でした。 また、イベントの名前にもなっているように、学び舎というイメージがぴったりのコンセプトで統一されているのも特徴的でした。 会場自体も元々中学校だったものを利用したアートギャラリーを使用しており、教室や階段など、元を活かした作りになっていたのでイベントの雰囲気ととてもマッチしていました。 元々教室だったところでセッションが行われました セッション セッションは Web、インフラ、DB、プログラミングから、AI、IoT 等の最近話題になっている分野まで幅広く開かれていました。 我々が参加した 2 日目はプログラミング、Web、IoT のセッションが主に開催されていました。 メドレーのプロダクトはすべて Web サービスとして提供されていることもあり、私は、Web 関連のセッションを中心に、時間が空いたら他の分野のセッションもふらっと覗き見るような形で参加しました。 エンジニアとして成長する上で必要な戦略の話や、Service Worker や Web Payments など最近環境が整ってきた技術をプロダクトに組み込んでみた話など、幅広く見ることができました。 入場制限状態でやっと入れたものの立ち見の方の後ろから見ることに 運良く前の方の席が取れましたが、こちらも立ち見の方がたくさんいらっしゃいました 個人的に古川氏による「 Web Application 2018 From Performance Perspective 」は特に勉強になったセッションでした。 Web サイトのパフォーマンスに関してのエッセンスを詰めたようなセッションで、その歴史と共に、その時々のベストプラクティス、そしてその時代のバイブルをまとめ、今どういった背景でどういった対策をするべきか、その指針となるような話聞くことができました。 サイトパフォーマンスの歴史の概要を説明していただきました 特に、Web 側は SPA として動いている CLINICS を開発しているため、 Server rendered pages are not optional という言葉の意味が衝撃的で、帰る途中からずっとそのあたりのことを考えてしまうほどでした。 Speaker Deck にスライドが上がっていますので、気になる方はそちらをご参照ください。 Web アプリケーションのパフォーマンスに関することは個人的に気になっていたものの、どこから手を付けてよいのかわからず理解があまり進んでない分野だったため、必要な知識を 40 分という短い時間で把握することができたのは非常にありがたかったです。 まさにイベントの趣旨である”気になっていること”、「回答」を知りたいがなかなか ”知る機会がなかったこと” という ”疑問” を、カンファレンスを通じて解決策を見出し、”知恵” を生み出す体験ができたのではないかと思っています。 リアル版 teratail も登場 まとめ 大規模かつ幅広い分野を取り扱っており、自分の専門や興味のある分野以外も同時に開催されたため、気軽に参加することができるイベントでした。 初めてエンジニアリングに触れて 1 年弱が経ち、その間に業務などを通じて学んできた過程で言語化できていなかったことが思っていた以上にあったことを、このイベントを通じて改めて知ることができました。 こういった大規模なイベントは初参加だったのですが、多くのことが知れたのでとても良かったです。 次回開催される際は、また行ってみようと思っています。 イベントでメドレーのことを知りご興味持っていただいた方は、お気軽にご連絡ください！ どんなエンジニア・デザイナーが働いているか、どんなことをやっているか等、ぜひ HP をご覧ください。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレー平木の「気になるあの人に聞いてみた」 メドレーのエンジニア平木が、社内の気になる人に仕事内容やこれまで等をゆるりとインタビューするコーナーです。 www.wantedly.com

皆さんこんにちは。開発本部の日下です。普段は オンライン診療アプリ「CLINICS」 および オンライン医療事典「MEDLEY」 の開発を担当しています。（昨年、新卒で昨年メドレーに入ったのでエンジニア歴は 1 年弱。ベテランが多いメドレーのエンジニアチームで奮闘しています） 先日開催された エンジニア特化型 Q&A サイト「 teratail 」 さんのイベント、 MANABIYA にメドレーがスポンサーとして協力させていただきました。 エンジニアの平木と参加しましたので、イベント当日の様子をレポートします。 MANABIYA とは teratail はご存知の方も多いかもしれませんが、MANABIYA というイベントをご存じない方もいるかもしれません。 MANABIYA は今回が初開催のイベントで、”疑問” を日本中から集め、カンファレンスを通じて解決策を見出し、”知恵” を生み出すことを目的とし、秋葉原から近い 3331 Arts Chiyoda にて 2 日間に渡って開催されました。 全体の雰囲気 全体的に初開催とは思えないほど人が多く、一部のセッションでは教室が満杯になり、入場制限がかかるほどでした。また、speaker として豪華なメンバー面々が数多く集まっており、最初から最後まで、参加したすべてのセッションで立ち見が出てるほど盛況だったのがとても印象的でした。 また、イベントの名前にもなっているように、学び舎というイメージがぴったりのコンセプトで統一されているのも特徴的でした。 会場自体も元々中学校だったものを利用したアートギャラリーを使用しており、教室や階段など、元を活かした作りになっていたのでイベントの雰囲気ととてもマッチしていました。 元々教室だったところでセッションが行われました セッション セッションは Web、インフラ、DB、プログラミングから、AI、IoT 等の最近話題になっている分野まで幅広く開かれていました。 我々が参加した 2 日目はプログラミング、Web、IoT のセッションが主に開催されていました。 メドレーのプロダクトはすべて Web サービスとして提供されていることもあり、私は、Web 関連のセッションを中心に、時間が空いたら他の分野のセッションもふらっと覗き見るような形で参加しました。 エンジニアとして成長する上で必要な戦略の話や、Service Worker や Web Payments など最近環境が整ってきた技術をプロダクトに組み込んでみた話など、幅広く見ることができました。 入場制限状態でやっと入れたものの立ち見の方の後ろから見ることに 運良く前の方の席が取れましたが、こちらも立ち見の方がたくさんいらっしゃいました 個人的に古川氏による「 Web Application 2018 From Performance Perspective 」は特に勉強になったセッションでした。 Web サイトのパフォーマンスに関してのエッセンスを詰めたようなセッションで、その歴史と共に、その時々のベストプラクティス、そしてその時代のバイブルをまとめ、今どういった背景でどういった対策をするべきか、その指針となるような話聞くことができました。 サイトパフォーマンスの歴史の概要を説明していただきました 特に、Web 側は SPA として動いている CLINICS を開発しているため、 Server rendered pages are not optional という言葉の意味が衝撃的で、帰る途中からずっとそのあたりのことを考えてしまうほどでした。 Speaker Deck にスライドが上がっていますので、気になる方はそちらをご参照ください。 Web アプリケーションのパフォーマンスに関することは個人的に気になっていたものの、どこから手を付けてよいのかわからず理解があまり進んでない分野だったため、必要な知識を 40 分という短い時間で把握することができたのは非常にありがたかったです。 まさにイベントの趣旨である”気になっていること”、「回答」を知りたいがなかなか ”知る機会がなかったこと” という ”疑問” を、カンファレンスを通じて解決策を見出し、”知恵” を生み出す体験ができたのではないかと思っています。 リアル版 teratail も登場 まとめ 大規模かつ幅広い分野を取り扱っており、自分の専門や興味のある分野以外も同時に開催されたため、気軽に参加することができるイベントでした。 初めてエンジニアリングに触れて 1 年弱が経ち、その間に業務などを通じて学んできた過程で言語化できていなかったことが思っていた以上にあったことを、このイベントを通じて改めて知ることができました。 こういった大規模なイベントは初参加だったのですが、多くのことが知れたのでとても良かったです。 次回開催される際は、また行ってみようと思っています。 イベントでメドレーのことを知りご興味持っていただいた方は、お気軽にご連絡ください！ どんなエンジニア・デザイナーが働いているか、どんなことをやっているか等、ぜひ HP をご覧ください。 https://www.medley.jp/recruit/creative.html https://www.wantedly.com/feed/s/medley-int

皆さんこんにちは。開発本部の日下です。普段は オンライン診療アプリ「CLINICS」 および オンライン医療事典「MEDLEY」 の開発を担当しています。（昨年、新卒で昨年メドレーに入ったのでエンジニア歴は 1 年弱。ベテランが多いメドレーのエンジニアチームで奮闘しています） 先日開催された エンジニア特化型 Q&A サイト「 teratail 」 さんのイベント、 MANABIYA にメドレーがスポンサーとして協力させていただきました。 エンジニアの平木と参加しましたので、イベント当日の様子をレポートします。 MANABIYA とは teratail はご存知の方も多いかもしれませんが、MANABIYA というイベントをご存じない方もいるかもしれません。 MANABIYA は今回が初開催のイベントで、”疑問” を日本中から集め、カンファレンスを通じて解決策を見出し、”知恵” を生み出すことを目的とし、秋葉原から近い 3331 Arts Chiyoda にて 2 日間に渡って開催されました。 全体の雰囲気 全体的に初開催とは思えないほど人が多く、一部のセッションでは教室が満杯になり、入場制限がかかるほどでした。また、speaker として豪華なメンバー面々が数多く集まっており、最初から最後まで、参加したすべてのセッションで立ち見が出てるほど盛況だったのがとても印象的でした。 また、イベントの名前にもなっているように、学び舎というイメージがぴったりのコンセプトで統一されているのも特徴的でした。 会場自体も元々中学校だったものを利用したアートギャラリーを使用しており、教室や階段など、元を活かした作りになっていたのでイベントの雰囲気ととてもマッチしていました。 元々教室だったところでセッションが行われました セッション セッションは Web、インフラ、DB、プログラミングから、AI、IoT 等の最近話題になっている分野まで幅広く開かれていました。 我々が参加した 2 日目はプログラミング、Web、IoT のセッションが主に開催されていました。 メドレーのプロダクトはすべて Web サービスとして提供されていることもあり、私は、Web 関連のセッションを中心に、時間が空いたら他の分野のセッションもふらっと覗き見るような形で参加しました。 エンジニアとして成長する上で必要な戦略の話や、Service Worker や Web Payments など最近環境が整ってきた技術をプロダクトに組み込んでみた話など、幅広く見ることができました。 入場制限状態でやっと入れたものの立ち見の方の後ろから見ることに 運良く前の方の席が取れましたが、こちらも立ち見の方がたくさんいらっしゃいました 個人的に古川氏による「 Web Application 2018 From Performance Perspective 」は特に勉強になったセッションでした。 Web サイトのパフォーマンスに関してのエッセンスを詰めたようなセッションで、その歴史と共に、その時々のベストプラクティス、そしてその時代のバイブルをまとめ、今どういった背景でどういった対策をするべきか、その指針となるような話聞くことができました。 サイトパフォーマンスの歴史の概要を説明していただきました 特に、Web 側は SPA として動いている CLINICS を開発しているため、 Server rendered pages are not optional という言葉の意味が衝撃的で、帰る途中からずっとそのあたりのことを考えてしまうほどでした。 Speaker Deck にスライドが上がっていますので、気になる方はそちらをご参照ください。 Web アプリケーションのパフォーマンスに関することは個人的に気になっていたものの、どこから手を付けてよいのかわからず理解があまり進んでない分野だったため、必要な知識を 40 分という短い時間で把握することができたのは非常にありがたかったです。 まさにイベントの趣旨である”気になっていること”、「回答」を知りたいがなかなか ”知る機会がなかったこと” という ”疑問” を、カンファレンスを通じて解決策を見出し、”知恵” を生み出す体験ができたのではないかと思っています。 リアル版 teratail も登場 まとめ 大規模かつ幅広い分野を取り扱っており、自分の専門や興味のある分野以外も同時に開催されたため、気軽に参加することができるイベントでした。 初めてエンジニアリングに触れて 1 年弱が経ち、その間に業務などを通じて学んできた過程で言語化できていなかったことが思っていた以上にあったことを、このイベントを通じて改めて知ることができました。 こういった大規模なイベントは初参加だったのですが、多くのことが知れたのでとても良かったです。 次回開催される際は、また行ってみようと思っています。 イベントでメドレーのことを知りご興味持っていただいた方は、お気軽にご連絡ください！ どんなエンジニア・デザイナーが働いているか、どんなことをやっているか等、ぜひ HP をご覧ください。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレー平木の「気になるあの人に聞いてみた」 メドレーのエンジニア平木が、社内の気になる人に仕事内容やこれまで等をゆるりとインタビューするコーナーです。 www.wantedly.com

皆さんこんにちは。開発本部の日下です。普段は オンライン診療アプリ「CLINICS」 および オンライン医療事典「MEDLEY」 の開発を担当しています。（昨年、新卒で昨年メドレーに入ったのでエンジニア歴は 1 年弱。ベテランが多いメドレーのエンジニアチームで奮闘しています） 先日開催された エンジニア特化型 Q&A サイト「 teratail 」 さんのイベント、 MANABIYA にメドレーがスポンサーとして協力させていただきました。 エンジニアの平木と参加しましたので、イベント当日の様子をレポートします。 MANABIYA とは teratail はご存知の方も多いかもしれませんが、MANABIYA というイベントをご存じない方もいるかもしれません。 MANABIYA は今回が初開催のイベントで、”疑問” を日本中から集め、カンファレンスを通じて解決策を見出し、”知恵” を生み出すことを目的とし、秋葉原から近い 3331 Arts Chiyoda にて 2 日間に渡って開催されました。 全体の雰囲気 全体的に初開催とは思えないほど人が多く、一部のセッションでは教室が満杯になり、入場制限がかかるほどでした。また、speaker として豪華なメンバー面々が数多く集まっており、最初から最後まで、参加したすべてのセッションで立ち見が出てるほど盛況だったのがとても印象的でした。 また、イベントの名前にもなっているように、学び舎というイメージがぴったりのコンセプトで統一されているのも特徴的でした。 会場自体も元々中学校だったものを利用したアートギャラリーを使用しており、教室や階段など、元を活かした作りになっていたのでイベントの雰囲気ととてもマッチしていました。 元々教室だったところでセッションが行われました セッション セッションは Web、インフラ、DB、プログラミングから、AI、IoT 等の最近話題になっている分野まで幅広く開かれていました。 我々が参加した 2 日目はプログラミング、Web、IoT のセッションが主に開催されていました。 メドレーのプロダクトはすべて Web サービスとして提供されていることもあり、私は、Web 関連のセッションを中心に、時間が空いたら他の分野のセッションもふらっと覗き見るような形で参加しました。 エンジニアとして成長する上で必要な戦略の話や、Service Worker や Web Payments など最近環境が整ってきた技術をプロダクトに組み込んでみた話など、幅広く見ることができました。 入場制限状態でやっと入れたものの立ち見の方の後ろから見ることに 運良く前の方の席が取れましたが、こちらも立ち見の方がたくさんいらっしゃいました 個人的に古川氏による「 Web Application 2018 From Performance Perspective 」は特に勉強になったセッションでした。 Web サイトのパフォーマンスに関してのエッセンスを詰めたようなセッションで、その歴史と共に、その時々のベストプラクティス、そしてその時代のバイブルをまとめ、今どういった背景でどういった対策をするべきか、その指針となるような話聞くことができました。 サイトパフォーマンスの歴史の概要を説明していただきました 特に、Web 側は SPA として動いている CLINICS を開発しているため、 Server rendered pages are not optional という言葉の意味が衝撃的で、帰る途中からずっとそのあたりのことを考えてしまうほどでした。 Speaker Deck にスライドが上がっていますので、気になる方はそちらをご参照ください。 Web アプリケーションのパフォーマンスに関することは個人的に気になっていたものの、どこから手を付けてよいのかわからず理解があまり進んでない分野だったため、必要な知識を 40 分という短い時間で把握することができたのは非常にありがたかったです。 まさにイベントの趣旨である”気になっていること”、「回答」を知りたいがなかなか ”知る機会がなかったこと” という ”疑問” を、カンファレンスを通じて解決策を見出し、”知恵” を生み出す体験ができたのではないかと思っています。 リアル版 teratail も登場 まとめ 大規模かつ幅広い分野を取り扱っており、自分の専門や興味のある分野以外も同時に開催されたため、気軽に参加することができるイベントでした。 初めてエンジニアリングに触れて 1 年弱が経ち、その間に業務などを通じて学んできた過程で言語化できていなかったことが思っていた以上にあったことを、このイベントを通じて改めて知ることができました。 こういった大規模なイベントは初参加だったのですが、多くのことが知れたのでとても良かったです。 次回開催される際は、また行ってみようと思っています。 イベントでメドレーのことを知りご興味持っていただいた方は、お気軽にご連絡ください！ どんなエンジニア・デザイナーが働いているか、どんなことをやっているか等、ぜひ HP をご覧ください。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレー平木の「気になるあの人に聞いてみた」 メドレーのエンジニア平木が、社内の気になる人に仕事内容やこれまで等をゆるりとインタビューするコーナーです。 www.wantedly.com

皆さんこんにちは。開発本部の日下です。普段は オンライン診療アプリ「CLINICS」 および オンライン医療事典「MEDLEY」 の開発を担当しています。（昨年、新卒で昨年メドレーに入ったのでエンジニア歴は 1 年弱。ベテランが多いメドレーのエンジニアチームで奮闘しています） 先日開催された エンジニア特化型 Q&A サイト「 teratail 」 さんのイベント、 MANABIYA にメドレーがスポンサーとして協力させていただきました。 エンジニアの平木と参加しましたので、イベント当日の様子をレポートします。 MANABIYA とは teratail はご存知の方も多いかもしれませんが、MANABIYA というイベントをご存じない方もいるかもしれません。 MANABIYA は今回が初開催のイベントで、”疑問” を日本中から集め、カンファレンスを通じて解決策を見出し、”知恵” を生み出すことを目的とし、秋葉原から近い 3331 Arts Chiyoda にて 2 日間に渡って開催されました。 全体の雰囲気 全体的に初開催とは思えないほど人が多く、一部のセッションでは教室が満杯になり、入場制限がかかるほどでした。また、speaker として豪華なメンバー面々が数多く集まっており、最初から最後まで、参加したすべてのセッションで立ち見が出てるほど盛況だったのがとても印象的でした。 また、イベントの名前にもなっているように、学び舎というイメージがぴったりのコンセプトで統一されているのも特徴的でした。 会場自体も元々中学校だったものを利用したアートギャラリーを使用しており、教室や階段など、元を活かした作りになっていたのでイベントの雰囲気ととてもマッチしていました。 元々教室だったところでセッションが行われました セッション セッションは Web、インフラ、DB、プログラミングから、AI、IoT 等の最近話題になっている分野まで幅広く開かれていました。 我々が参加した 2 日目はプログラミング、Web、IoT のセッションが主に開催されていました。 メドレーのプロダクトはすべて Web サービスとして提供されていることもあり、私は、Web 関連のセッションを中心に、時間が空いたら他の分野のセッションもふらっと覗き見るような形で参加しました。 エンジニアとして成長する上で必要な戦略の話や、Service Worker や Web Payments など最近環境が整ってきた技術をプロダクトに組み込んでみた話など、幅広く見ることができました。 入場制限状態でやっと入れたものの立ち見の方の後ろから見ることに 運良く前の方の席が取れましたが、こちらも立ち見の方がたくさんいらっしゃいました 個人的に古川氏による「 Web Application 2018 From Performance Perspective 」は特に勉強になったセッションでした。 Web サイトのパフォーマンスに関してのエッセンスを詰めたようなセッションで、その歴史と共に、その時々のベストプラクティス、そしてその時代のバイブルをまとめ、今どういった背景でどういった対策をするべきか、その指針となるような話聞くことができました。 サイトパフォーマンスの歴史の概要を説明していただきました 特に、Web 側は SPA として動いている CLINICS を開発しているため、 Server rendered pages are not optional という言葉の意味が衝撃的で、帰る途中からずっとそのあたりのことを考えてしまうほどでした。 Speaker Deck にスライドが上がっていますので、気になる方はそちらをご参照ください。 Web アプリケーションのパフォーマンスに関することは個人的に気になっていたものの、どこから手を付けてよいのかわからず理解があまり進んでない分野だったため、必要な知識を 40 分という短い時間で把握することができたのは非常にありがたかったです。 まさにイベントの趣旨である”気になっていること”、「回答」を知りたいがなかなか ”知る機会がなかったこと” という ”疑問” を、カンファレンスを通じて解決策を見出し、”知恵” を生み出す体験ができたのではないかと思っています。 リアル版 teratail も登場 まとめ 大規模かつ幅広い分野を取り扱っており、自分の専門や興味のある分野以外も同時に開催されたため、気軽に参加することができるイベントでした。 初めてエンジニアリングに触れて 1 年弱が経ち、その間に業務などを通じて学んできた過程で言語化できていなかったことが思っていた以上にあったことを、このイベントを通じて改めて知ることができました。 こういった大規模なイベントは初参加だったのですが、多くのことが知れたのでとても良かったです。 次回開催される際は、また行ってみようと思っています。 イベントでメドレーのことを知りご興味持っていただいた方は、お気軽にご連絡ください！ どんなエンジニア・デザイナーが働いているか、どんなことをやっているか等、ぜひ HP をご覧ください。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレー平木の「気になるあの人に聞いてみた」 メドレーのエンジニア平木が、社内の気になる人に仕事内容やこれまで等をゆるりとインタビューするコーナーです。 www.wantedly.com

皆さんこんにちは。開発本部の日下です。普段は オンライン診療アプリ「CLINICS」 および オンライン医療事典「MEDLEY」 の開発を担当しています。（昨年、新卒で昨年メドレーに入ったのでエンジニア歴は 1 年弱。ベテランが多いメドレーのエンジニアチームで奮闘しています） 先日開催された エンジニア特化型 Q&A サイト「 teratail 」 さんのイベント、 MANABIYA にメドレーがスポンサーとして協力させていただきました。 エンジニアの平木と参加しましたので、イベント当日の様子をレポートします。 MANABIYA とは teratail はご存知の方も多いかもしれませんが、MANABIYA というイベントをご存じない方もいるかもしれません。 MANABIYA は今回が初開催のイベントで、”疑問” を日本中から集め、カンファレンスを通じて解決策を見出し、”知恵” を生み出すことを目的とし、秋葉原から近い 3331 Arts Chiyoda にて 2 日間に渡って開催されました。 全体の雰囲気 全体的に初開催とは思えないほど人が多く、一部のセッションでは教室が満杯になり、入場制限がかかるほどでした。また、speaker として豪華なメンバー面々が数多く集まっており、最初から最後まで、参加したすべてのセッションで立ち見が出てるほど盛況だったのがとても印象的でした。 また、イベントの名前にもなっているように、学び舎というイメージがぴったりのコンセプトで統一されているのも特徴的でした。 会場自体も元々中学校だったものを利用したアートギャラリーを使用しており、教室や階段など、元を活かした作りになっていたのでイベントの雰囲気ととてもマッチしていました。 元々教室だったところでセッションが行われました セッション セッションは Web、インフラ、DB、プログラミングから、AI、IoT 等の最近話題になっている分野まで幅広く開かれていました。 我々が参加した 2 日目はプログラミング、Web、IoT のセッションが主に開催されていました。 メドレーのプロダクトはすべて Web サービスとして提供されていることもあり、私は、Web 関連のセッションを中心に、時間が空いたら他の分野のセッションもふらっと覗き見るような形で参加しました。 エンジニアとして成長する上で必要な戦略の話や、Service Worker や Web Payments など最近環境が整ってきた技術をプロダクトに組み込んでみた話など、幅広く見ることができました。 入場制限状態でやっと入れたものの立ち見の方の後ろから見ることに 運良く前の方の席が取れましたが、こちらも立ち見の方がたくさんいらっしゃいました 個人的に古川氏による「 Web Application 2018 From Performance Perspective 」は特に勉強になったセッションでした。 Web サイトのパフォーマンスに関してのエッセンスを詰めたようなセッションで、その歴史と共に、その時々のベストプラクティス、そしてその時代のバイブルをまとめ、今どういった背景でどういった対策をするべきか、その指針となるような話聞くことができました。 サイトパフォーマンスの歴史の概要を説明していただきました 特に、Web 側は SPA として動いている CLINICS を開発しているため、 Server rendered pages are not optional という言葉の意味が衝撃的で、帰る途中からずっとそのあたりのことを考えてしまうほどでした。 Speaker Deck にスライドが上がっていますので、気になる方はそちらをご参照ください。 Web アプリケーションのパフォーマンスに関することは個人的に気になっていたものの、どこから手を付けてよいのかわからず理解があまり進んでない分野だったため、必要な知識を 40 分という短い時間で把握することができたのは非常にありがたかったです。 まさにイベントの趣旨である”気になっていること”、「回答」を知りたいがなかなか ”知る機会がなかったこと” という ”疑問” を、カンファレンスを通じて解決策を見出し、”知恵” を生み出す体験ができたのではないかと思っています。 リアル版 teratail も登場 まとめ 大規模かつ幅広い分野を取り扱っており、自分の専門や興味のある分野以外も同時に開催されたため、気軽に参加することができるイベントでした。 初めてエンジニアリングに触れて 1 年弱が経ち、その間に業務などを通じて学んできた過程で言語化できていなかったことが思っていた以上にあったことを、このイベントを通じて改めて知ることができました。 こういった大規模なイベントは初参加だったのですが、多くのことが知れたのでとても良かったです。 次回開催される際は、また行ってみようと思っています。 イベントでメドレーのことを知りご興味持っていただいた方は、お気軽にご連絡ください！ どんなエンジニア・デザイナーが働いているか、どんなことをやっているか等、ぜひ HP をご覧ください。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレー平木の「気になるあの人に聞いてみた」 メドレーのエンジニア平木が、社内の気になる人に仕事内容やこれまで等をゆるりとインタビューするコーナーです。 www.wantedly.com