はじめに こんにちは。技術広報・エンジニアの平木です。最近使っている Emacs を Spacemacs から Doom Emacs に変更したところ気分も新たにテキスト活動が捗るようになりました。 さて、2022/05/11 に行なわれた 「 QA Night 〜組織内で QA エンジニアがバリューを発揮し、キャリアアップするには〜 」 という QA エンジニア向けイベントで弊社 QA エンジニア米山がパネリストとして登壇しましたので、その様子をイベントレポートとしてお届けしたいと思います。 QA Night とは こちらのイベントは Showcase Gig さんが主催しているイベントである Geek Gig というエンジニアリングについての定期イベントがありまして、そのシリーズの 1 つとして運営されたものです。 今回は Showcase Gig さんも弊社もテスト自動化ツールの MagicPod を使っているというご縁からお声がけいただきイベント開催の運びとなりました。 イベントについて 今回のイベントは、パネルディスカッションとして 2 社の QA についてそれぞれ語る形式になりました。 モデレーターを Showcase Gig ソフトウェアエンジニアで VP of Technology である 菊池さん が行ない、パネリストとして Showcase Gig QA エンジニア 横田さん と、弊社 QA エンジニア米山とでざっくばらんにイベントが進行していきました。 QA エンジニアの方だけではなく、モデレーターにエンジニアの方が入ったことによりバランスが良いパネルディスカッションになっているという感想でした。 こちらのイベントは connpass で公開後、あれよあれよと 140 人まで申し込みがあり、注目度の高さが伺えました。 当日のイベントの様子は下記からご覧いただけますので、ご興味のある方はぜひ。 パネルディスカッション パネルディスカッションは大まかに以下のようなセクションに分かれて実施されました。 パネリスト・モデレーター自己紹介 各社の開発/QA プロセスの理想と現実 QA エンジニアがいなかったらどうなる? QA エンジニアのキャリア これらのセクションに合わせて、パネリストそれぞれの立場で回答をしていきましたが、途中で視聴されている方の質問などは、モデレーターの菊池さんがほぼリアルタイムで拾っていきながらの進行だったので、イベントの一体感が非常に感じられて面白かったです。 自己紹介 横田さんも米山も現職に至るまでの経歴がかなり似ていました。第三者検証会社で様々な業態の会社を顧客として、様々な経験を積み重ねてから、事業会社での QA エンジニアとして特定のプロダクトの品質を高める仕事をしていらっしゃるという点です。 第三者検証会社で様々なニーズに対応したことが、プロダクトへの貢献に活きていそうだと感じました。 各社の開発/QA プロセスの理想と現実 QA を含めた開発体制については、両社で違いがもちろんありますが大きい違いでいうと、現在のメドレーではプロダクト開発チームの一員として QA エンジニアが所属しています。他方、Showcase Gig さんでは複数の開発チームを横断して QA チームが存在しているという部分でしょうか。 メドレーの現在の開発体制では、チーム内で開発メンバーと密接にやり取りをしながら品質を高めていくというプロセスが取られており、別の開発チームのヘルプなども、もちろんありますがアドバイザー的な感じで、実際にはそのチーム内で品質を高めるように動いています。 一方で Showcase Gig さんでは横断チームとして各プロダクトを俯瞰して見れるような体制にしている印象でした。それぞれの開発チームとは要所でシンクアップすることにより会社全体での QA プロセスを統一しながら各チームに展開できるのが良さそうだなと感じました。 理想と現実について そんな両社ですが、共通する部分として事業領域の難しさがありました。 メドレーは医療領域という難しさ、Showcase Gig さんではオンラインとオフラインの両立をしなければならない部分が特に難しいとのこと。 そこから話は QA の理想と現実に移っていきます。メドレーではプロダクトのより上流部分である仕様策定部分からバグを潰せるようにしていくのを目指しつつも、ガチガチな方法や体制にならないように日々 QA を行なっています。また E2E テストの失敗が非常事態だとメンバーが焦るくらいに成功率を高めていきたいという理想がありますが、どうしてもマニュアルでのテストが必要になってくるプロダクトなので、E2E テストだけに頼らないように試行錯誤しています。 Showcase Gig さんでは品質は担保しつつ、今以上にリリース頻度を上げるためにどうしたら良いかという点を開発チームと協業で改善しようとされているそうです。MagicPod を使った E2E テストだけでリリースまでできるようにするのが理想ではありますが、その前にプロセスの制定など前段階の準備を着々としているそうです。 QA エンジニアがいなかったらどうなる? QA エンジニアのイベントで中々出てこないような設問もあり大変面白かったのですが、それがこの「QA エンジニアがいなかったらどうなる?」という設問でした。 興味深かったのはお二人とも同じような返答だったことです。両社とも「リリースは通常通り行なわれるだろうが、リリース後の不具合対応などが増えるかもしれない」ということでした。またこれも共通して「QA エンジニアがいなくても品質保証がされることが理想」というお話でした。 実際に QA エンジニアはいなくてもきちんと高い品質のプロダクトを世に出していける仕組みや体制が理想というのは、関係者に品質についての意識が根差していけるようにするという意気込みのように聞こえ感銘を受けました。 QA エンジニアのキャリア また普段お二人はどのような意識配分で日々の仕事をされているかというのを円グラフで表わす試みが良かったです。 普段どのような事に時間や意識を割いているかというのが分かると自分の仕事の比率と比べてみちゃいますね。 ここから、皆さんが気になる QA エンジニアのキャリアについてお二人が話をされました。 米山は 15 年の QA 経験を持っていますが、その中でアジャイルやテスト自動化などのトレンドには「自分でもできるかな」と思いながら導入をしていったとのことでした。そうしながら、自分の中のプライオリティはあくまでも事業・プロダクトという部分だったので、ここにコミットができる立ち位置での仕事をずっと続けてきたと言います。 先のキャリアとしては、ポジションに捕われず事業価値を高めるように動いていき、どのような状況のチームでも品質を高めるための推進ができるようにしていきたいということでした。 一方の横田さんも今までの経験を踏まえ QA のポジションを高めていけるような動きをしていきたいということでした。テストなどに興味を持つ人の裾野を広げていきたいという意欲を感じました。個人としては UI/UX なども含めて品質を高めるということができればとのことでした。 お二人とも、「自分のキャリア」に留まらず周囲の人間にも、良い影響を与えていきたいということをおっしゃっているのが非常に印象的でした。 最後に 紹介した以外にも現場に即した QA についてや、品質についての考え方の一端が分かるようなイベントでした。自分はエンジニアという立場で視聴していましたが、そうした人間にも大変に示唆に富むお話が多く、あっという間に 1 時間が経過しました。QA エンジニアの方はもちろん、その他プロダクトを作るということに関わる方はぜひ、アーカイブを視聴してみてください!

はじめに こんにちは。技術広報・エンジニアの平木です。最近使っている Emacs を Spacemacs から Doom Emacs に変更したところ気分も新たにテキスト活動が捗るようになりました。 さて、2022/05/11 に行なわれた 「 QA Night 〜組織内で QA エンジニアがバリューを発揮し、キャリアアップするには〜 」 という QA エンジニア向けイベントで弊社 QA エンジニア米山がパネリストとして登壇しましたので、その様子をイベントレポートとしてお届けしたいと思います。 QA Night とは こちらのイベントは Showcase Gig さんが主催しているイベントである Geek Gig というエンジニアリングについての定期イベントがありまして、そのシリーズの 1 つとして運営されたものです。 今回は Showcase Gig さんも弊社もテスト自動化ツールの MagicPod を使っているというご縁からお声がけいただきイベント開催の運びとなりました。 イベントについて 今回のイベントは、パネルディスカッションとして 2 社の QA についてそれぞれ語る形式になりました。 モデレーターを Showcase Gig ソフトウェアエンジニアで VP of Technology である 菊池さん が行ない、パネリストとして Showcase Gig QA エンジニア 横田さん と、弊社 QA エンジニア米山とでざっくばらんにイベントが進行していきました。 QA エンジニアの方だけではなく、モデレーターにエンジニアの方が入ったことによりバランスが良いパネルディスカッションになっているという感想でした。 こちらのイベントは connpass で公開後、あれよあれよと 140 人まで申し込みがあり、注目度の高さが伺えました。 当日のイベントの様子は下記からご覧いただけますので、ご興味のある方はぜひ。 パネルディスカッション パネルディスカッションは大まかに以下のようなセクションに分かれて実施されました。 パネリスト・モデレーター自己紹介 各社の開発/QA プロセスの理想と現実 QA エンジニアがいなかったらどうなる? QA エンジニアのキャリア これらのセクションに合わせて、パネリストそれぞれの立場で回答をしていきましたが、途中で視聴されている方の質問などは、モデレーターの菊池さんがほぼリアルタイムで拾っていきながらの進行だったので、イベントの一体感が非常に感じられて面白かったです。 自己紹介 横田さんも米山も現職に至るまでの経歴がかなり似ていました。第三者検証会社で様々な業態の会社を顧客として、様々な経験を積み重ねてから、事業会社での QA エンジニアとして特定のプロダクトの品質を高める仕事をしていらっしゃるという点です。 第三者検証会社で様々なニーズに対応したことが、プロダクトへの貢献に活きていそうだと感じました。 各社の開発/QA プロセスの理想と現実 QA を含めた開発体制については、両社で違いがもちろんありますが大きい違いでいうと、現在のメドレーではプロダクト開発チームの一員として QA エンジニアが所属しています。他方、Showcase Gig さんでは複数の開発チームを横断して QA チームが存在しているという部分でしょうか。 メドレーの現在の開発体制では、チーム内で開発メンバーと密接にやり取りをしながら品質を高めていくというプロセスが取られており、別の開発チームのヘルプなども、もちろんありますがアドバイザー的な感じで、実際にはそのチーム内で品質を高めるように動いています。 一方で Showcase Gig さんでは横断チームとして各プロダクトを俯瞰して見れるような体制にしている印象でした。それぞれの開発チームとは要所でシンクアップすることにより会社全体での QA プロセスを統一しながら各チームに展開できるのが良さそうだなと感じました。 理想と現実について そんな両社ですが、共通する部分として事業領域の難しさがありました。 メドレーは医療領域という難しさ、Showcase Gig さんではオンラインとオフラインの両立をしなければならない部分が特に難しいとのこと。 そこから話は QA の理想と現実に移っていきます。メドレーではプロダクトのより上流部分である仕様策定部分からバグを潰せるようにしていくのを目指しつつも、ガチガチな方法や体制にならないように日々 QA を行なっています。また E2E テストの失敗が非常事態だとメンバーが焦るくらいに成功率を高めていきたいという理想がありますが、どうしてもマニュアルでのテストが必要になってくるプロダクトなので、E2E テストだけに頼らないように試行錯誤しています。 Showcase Gig さんでは品質は担保しつつ、今以上にリリース頻度を上げるためにどうしたら良いかという点を開発チームと協業で改善しようとされているそうです。MagicPod を使った E2E テストだけでリリースまでできるようにするのが理想ではありますが、その前にプロセスの制定など前段階の準備を着々としているそうです。 QA エンジニアがいなかったらどうなる? QA エンジニアのイベントで中々出てこないような設問もあり大変面白かったのですが、それがこの「QA エンジニアがいなかったらどうなる?」という設問でした。 興味深かったのはお二人とも同じような返答だったことです。両社とも「リリースは通常通り行なわれるだろうが、リリース後の不具合対応などが増えるかもしれない」ということでした。またこれも共通して「QA エンジニアがいなくても品質保証がされることが理想」というお話でした。 実際に QA エンジニアはいなくてもきちんと高い品質のプロダクトを世に出していける仕組みや体制が理想というのは、関係者に品質についての意識が根差していけるようにするという意気込みのように聞こえ感銘を受けました。 QA エンジニアのキャリア また普段お二人はどのような意識配分で日々の仕事をされているかというのを円グラフで表わす試みが良かったです。 普段どのような事に時間や意識を割いているかというのが分かると自分の仕事の比率と比べてみちゃいますね。 ここから、皆さんが気になる QA エンジニアのキャリアについてお二人が話をされました。 米山は 15 年の QA 経験を持っていますが、その中でアジャイルやテスト自動化などのトレンドには「自分でもできるかな」と思いながら導入をしていったとのことでした。そうしながら、自分の中のプライオリティはあくまでも事業・プロダクトという部分だったので、ここにコミットができる立ち位置での仕事をずっと続けてきたと言います。 先のキャリアとしては、ポジションに捕われず事業価値を高めるように動いていき、どのような状況のチームでも品質を高めるための推進ができるようにしていきたいということでした。 一方の横田さんも今までの経験を踏まえ QA のポジションを高めていけるような動きをしていきたいということでした。テストなどに興味を持つ人の裾野を広げていきたいという意欲を感じました。個人としては UI/UX なども含めて品質を高めるということができればとのことでした。 お二人とも、「自分のキャリア」に留まらず周囲の人間にも、良い影響を与えていきたいということをおっしゃっているのが非常に印象的でした。 最後に 紹介した以外にも現場に即した QA についてや、品質についての考え方の一端が分かるようなイベントでした。自分はエンジニアという立場で視聴していましたが、そうした人間にも大変に示唆に富むお話が多く、あっという間に 1 時間が経過しました。QA エンジニアの方はもちろん、その他プロダクトを作るということに関わる方はぜひ、アーカイブを視聴してみてください!

はじめに こんにちは。技術広報・エンジニアの平木です。最近使っている Emacs を Spacemacs から Doom Emacs に変更したところ気分も新たにテキスト活動が捗るようになりました。 さて、2022/05/11 に行なわれた 「 QA Night 〜組織内で QA エンジニアがバリューを発揮し、キャリアアップするには〜 」 という QA エンジニア向けイベントで弊社 QA エンジニア米山がパネリストとして登壇しましたので、その様子をイベントレポートとしてお届けしたいと思います。 QA Night とは こちらのイベントは Showcase Gig さんが主催しているイベントである Geek Gig というエンジニアリングについての定期イベントがありまして、そのシリーズの 1 つとして運営されたものです。 今回は Showcase Gig さんも弊社もテスト自動化ツールの MagicPod を使っているというご縁からお声がけいただきイベント開催の運びとなりました。 イベントについて 今回のイベントは、パネルディスカッションとして 2 社の QA についてそれぞれ語る形式になりました。 モデレーターを Showcase Gig ソフトウェアエンジニアで VP of Technology である 菊池さん が行ない、パネリストとして Showcase Gig QA エンジニア 横田さん と、弊社 QA エンジニア米山とでざっくばらんにイベントが進行していきました。 QA エンジニアの方だけではなく、モデレーターにエンジニアの方が入ったことによりバランスが良いパネルディスカッションになっているという感想でした。 こちらのイベントは connpass で公開後、あれよあれよと 140 人まで申し込みがあり、注目度の高さが伺えました。 当日のイベントの様子は下記からご覧いただけますので、ご興味のある方はぜひ。 パネルディスカッション パネルディスカッションは大まかに以下のようなセクションに分かれて実施されました。 パネリスト・モデレーター自己紹介 各社の開発/QA プロセスの理想と現実 QA エンジニアがいなかったらどうなる? QA エンジニアのキャリア これらのセクションに合わせて、パネリストそれぞれの立場で回答をしていきましたが、途中で視聴されている方の質問などは、モデレーターの菊池さんがほぼリアルタイムで拾っていきながらの進行だったので、イベントの一体感が非常に感じられて面白かったです。 自己紹介 横田さんも米山も現職に至るまでの経歴がかなり似ていました。第三者検証会社で様々な業態の会社を顧客として、様々な経験を積み重ねてから、事業会社での QA エンジニアとして特定のプロダクトの品質を高める仕事をしていらっしゃるという点です。 第三者検証会社で様々なニーズに対応したことが、プロダクトへの貢献に活きていそうだと感じました。 各社の開発/QA プロセスの理想と現実 QA を含めた開発体制については、両社で違いがもちろんありますが大きい違いでいうと、現在のメドレーではプロダクト開発チームの一員として QA エンジニアが所属しています。他方、Showcase Gig さんでは複数の開発チームを横断して QA チームが存在しているという部分でしょうか。 メドレーの現在の開発体制では、チーム内で開発メンバーと密接にやり取りをしながら品質を高めていくというプロセスが取られており、別の開発チームのヘルプなども、もちろんありますがアドバイザー的な感じで、実際にはそのチーム内で品質を高めるように動いています。 一方で Showcase Gig さんでは横断チームとして各プロダクトを俯瞰して見れるような体制にしている印象でした。それぞれの開発チームとは要所でシンクアップすることにより会社全体での QA プロセスを統一しながら各チームに展開できるのが良さそうだなと感じました。 理想と現実について そんな両社ですが、共通する部分として事業領域の難しさがありました。 メドレーは医療領域という難しさ、Showcase Gig さんではオンラインとオフラインの両立をしなければならない部分が特に難しいとのこと。 そこから話は QA の理想と現実に移っていきます。メドレーではプロダクトのより上流部分である仕様策定部分からバグを潰せるようにしていくのを目指しつつも、ガチガチな方法や体制にならないように日々 QA を行なっています。また E2E テストの失敗が非常事態だとメンバーが焦るくらいに成功率を高めていきたいという理想がありますが、どうしてもマニュアルでのテストが必要になってくるプロダクトなので、E2E テストだけに頼らないように試行錯誤しています。 Showcase Gig さんでは品質は担保しつつ、今以上にリリース頻度を上げるためにどうしたら良いかという点を開発チームと協業で改善しようとされているそうです。MagicPod を使った E2E テストだけでリリースまでできるようにするのが理想ではありますが、その前にプロセスの制定など前段階の準備を着々としているそうです。 QA エンジニアがいなかったらどうなる? QA エンジニアのイベントで中々出てこないような設問もあり大変面白かったのですが、それがこの「QA エンジニアがいなかったらどうなる?」という設問でした。 興味深かったのはお二人とも同じような返答だったことです。両社とも「リリースは通常通り行なわれるだろうが、リリース後の不具合対応などが増えるかもしれない」ということでした。またこれも共通して「QA エンジニアがいなくても品質保証がされることが理想」というお話でした。 実際に QA エンジニアはいなくてもきちんと高い品質のプロダクトを世に出していける仕組みや体制が理想というのは、関係者に品質についての意識が根差していけるようにするという意気込みのように聞こえ感銘を受けました。 QA エンジニアのキャリア また普段お二人はどのような意識配分で日々の仕事をされているかというのを円グラフで表わす試みが良かったです。 普段どのような事に時間や意識を割いているかというのが分かると自分の仕事の比率と比べてみちゃいますね。 ここから、皆さんが気になる QA エンジニアのキャリアについてお二人が話をされました。 米山は 15 年の QA 経験を持っていますが、その中でアジャイルやテスト自動化などのトレンドには「自分でもできるかな」と思いながら導入をしていったとのことでした。そうしながら、自分の中のプライオリティはあくまでも事業・プロダクトという部分だったので、ここにコミットができる立ち位置での仕事をずっと続けてきたと言います。 先のキャリアとしては、ポジションに捕われず事業価値を高めるように動いていき、どのような状況のチームでも品質を高めるための推進ができるようにしていきたいということでした。 一方の横田さんも今までの経験を踏まえ QA のポジションを高めていけるような動きをしていきたいということでした。テストなどに興味を持つ人の裾野を広げていきたいという意欲を感じました。個人としては UI/UX なども含めて品質を高めるということができればとのことでした。 お二人とも、「自分のキャリア」に留まらず周囲の人間にも、良い影響を与えていきたいということをおっしゃっているのが非常に印象的でした。 最後に 紹介した以外にも現場に即した QA についてや、品質についての考え方の一端が分かるようなイベントでした。自分はエンジニアという立場で視聴していましたが、そうした人間にも大変に示唆に富むお話が多く、あっという間に 1 時間が経過しました。QA エンジニアの方はもちろん、その他プロダクトを作るということに関わる方はぜひ、アーカイブを視聴してみてください!

はじめに こんにちは。技術広報・エンジニアの平木です。最近使っている Emacs を Spacemacs から Doom Emacs に変更したところ気分も新たにテキスト活動が捗るようになりました。 さて、2022/05/11 に行なわれた 「 QA Night 〜組織内で QA エンジニアがバリューを発揮し、キャリアアップするには〜 」 という QA エンジニア向けイベントで弊社 QA エンジニア米山がパネリストとして登壇しましたので、その様子をイベントレポートとしてお届けしたいと思います。 QA Night とは こちらのイベントは Showcase Gig さんが主催しているイベントである Geek Gig というエンジニアリングについての定期イベントがありまして、そのシリーズの 1 つとして運営されたものです。 今回は Showcase Gig さんも弊社もテスト自動化ツールの MagicPod を使っているというご縁からお声がけいただきイベント開催の運びとなりました。 イベントについて 今回のイベントは、パネルディスカッションとして 2 社の QA についてそれぞれ語る形式になりました。 モデレーターを Showcase Gig ソフトウェアエンジニアで VP of Technology である 菊池さん が行ない、パネリストとして Showcase Gig QA エンジニア 横田さん と、弊社 QA エンジニア米山とでざっくばらんにイベントが進行していきました。 QA エンジニアの方だけではなく、モデレーターにエンジニアの方が入ったことによりバランスが良いパネルディスカッションになっているという感想でした。 こちらのイベントは connpass で公開後、あれよあれよと 140 人まで申し込みがあり、注目度の高さが伺えました。 当日のイベントの様子は下記からご覧いただけますので、ご興味のある方はぜひ。 パネルディスカッション パネルディスカッションは大まかに以下のようなセクションに分かれて実施されました。 パネリスト・モデレーター自己紹介 各社の開発/QA プロセスの理想と現実 QA エンジニアがいなかったらどうなる? QA エンジニアのキャリア これらのセクションに合わせて、パネリストそれぞれの立場で回答をしていきましたが、途中で視聴されている方の質問などは、モデレーターの菊池さんがほぼリアルタイムで拾っていきながらの進行だったので、イベントの一体感が非常に感じられて面白かったです。 自己紹介 横田さんも米山も現職に至るまでの経歴がかなり似ていました。第三者検証会社で様々な業態の会社を顧客として、様々な経験を積み重ねてから、事業会社での QA エンジニアとして特定のプロダクトの品質を高める仕事をしていらっしゃるという点です。 第三者検証会社で様々なニーズに対応したことが、プロダクトへの貢献に活きていそうだと感じました。 各社の開発/QA プロセスの理想と現実 QA を含めた開発体制については、両社で違いがもちろんありますが大きい違いでいうと、現在のメドレーではプロダクト開発チームの一員として QA エンジニアが所属しています。他方、Showcase Gig さんでは複数の開発チームを横断して QA チームが存在しているという部分でしょうか。 メドレーの現在の開発体制では、チーム内で開発メンバーと密接にやり取りをしながら品質を高めていくというプロセスが取られており、別の開発チームのヘルプなども、もちろんありますがアドバイザー的な感じで、実際にはそのチーム内で品質を高めるように動いています。 一方で Showcase Gig さんでは横断チームとして各プロダクトを俯瞰して見れるような体制にしている印象でした。それぞれの開発チームとは要所でシンクアップすることにより会社全体での QA プロセスを統一しながら各チームに展開できるのが良さそうだなと感じました。 理想と現実について そんな両社ですが、共通する部分として事業領域の難しさがありました。 メドレーは医療領域という難しさ、Showcase Gig さんではオンラインとオフラインの両立をしなければならない部分が特に難しいとのこと。 そこから話は QA の理想と現実に移っていきます。メドレーではプロダクトのより上流部分である仕様策定部分からバグを潰せるようにしていくのを目指しつつも、ガチガチな方法や体制にならないように日々 QA を行なっています。また E2E テストの失敗が非常事態だとメンバーが焦るくらいに成功率を高めていきたいという理想がありますが、どうしてもマニュアルでのテストが必要になってくるプロダクトなので、E2E テストだけに頼らないように試行錯誤しています。 Showcase Gig さんでは品質は担保しつつ、今以上にリリース頻度を上げるためにどうしたら良いかという点を開発チームと協業で改善しようとされているそうです。MagicPod を使った E2E テストだけでリリースまでできるようにするのが理想ではありますが、その前にプロセスの制定など前段階の準備を着々としているそうです。 QA エンジニアがいなかったらどうなる? QA エンジニアのイベントで中々出てこないような設問もあり大変面白かったのですが、それがこの「QA エンジニアがいなかったらどうなる?」という設問でした。 興味深かったのはお二人とも同じような返答だったことです。両社とも「リリースは通常通り行なわれるだろうが、リリース後の不具合対応などが増えるかもしれない」ということでした。またこれも共通して「QA エンジニアがいなくても品質保証がされることが理想」というお話でした。 実際に QA エンジニアはいなくてもきちんと高い品質のプロダクトを世に出していける仕組みや体制が理想というのは、関係者に品質についての意識が根差していけるようにするという意気込みのように聞こえ感銘を受けました。 QA エンジニアのキャリア また普段お二人はどのような意識配分で日々の仕事をされているかというのを円グラフで表わす試みが良かったです。 普段どのような事に時間や意識を割いているかというのが分かると自分の仕事の比率と比べてみちゃいますね。 ここから、皆さんが気になる QA エンジニアのキャリアについてお二人が話をされました。 米山は 15 年の QA 経験を持っていますが、その中でアジャイルやテスト自動化などのトレンドには「自分でもできるかな」と思いながら導入をしていったとのことでした。そうしながら、自分の中のプライオリティはあくまでも事業・プロダクトという部分だったので、ここにコミットができる立ち位置での仕事をずっと続けてきたと言います。 先のキャリアとしては、ポジションに捕われず事業価値を高めるように動いていき、どのような状況のチームでも品質を高めるための推進ができるようにしていきたいということでした。 一方の横田さんも今までの経験を踏まえ QA のポジションを高めていけるような動きをしていきたいということでした。テストなどに興味を持つ人の裾野を広げていきたいという意欲を感じました。個人としては UI/UX なども含めて品質を高めるということができればとのことでした。 お二人とも、「自分のキャリア」に留まらず周囲の人間にも、良い影響を与えていきたいということをおっしゃっているのが非常に印象的でした。 最後に 紹介した以外にも現場に即した QA についてや、品質についての考え方の一端が分かるようなイベントでした。自分はエンジニアという立場で視聴していましたが、そうした人間にも大変に示唆に富むお話が多く、あっという間に 1 時間が経過しました。QA エンジニアの方はもちろん、その他プロダクトを作るということに関わる方はぜひ、アーカイブを視聴してみてください!

はじめに こんにちは。技術広報・エンジニアの平木です。最近使っている Emacs を Spacemacs から Doom Emacs に変更したところ気分も新たにテキスト活動が捗るようになりました。 さて、2022/05/11 に行なわれた 「 QA Night 〜組織内で QA エンジニアがバリューを発揮し、キャリアアップするには〜 」 という QA エンジニア向けイベントで弊社 QA エンジニア米山がパネリストとして登壇しましたので、その様子をイベントレポートとしてお届けしたいと思います。 QA Night とは こちらのイベントは Showcase Gig さんが主催しているイベントである Geek Gig というエンジニアリングについての定期イベントがありまして、そのシリーズの 1 つとして運営されたものです。 今回は Showcase Gig さんも弊社もテスト自動化ツールの MagicPod を使っているというご縁からお声がけいただきイベント開催の運びとなりました。 イベントについて 今回のイベントは、パネルディスカッションとして 2 社の QA についてそれぞれ語る形式になりました。 モデレーターを Showcase Gig ソフトウェアエンジニアで VP of Technology である 菊池さん が行ない、パネリストとして Showcase Gig QA エンジニア 横田さん と、弊社 QA エンジニア米山とでざっくばらんにイベントが進行していきました。 QA エンジニアの方だけではなく、モデレーターにエンジニアの方が入ったことによりバランスが良いパネルディスカッションになっているという感想でした。 こちらのイベントは connpass で公開後、あれよあれよと 140 人まで申し込みがあり、注目度の高さが伺えました。 当日のイベントの様子は下記からご覧いただけますので、ご興味のある方はぜひ。 パネルディスカッション パネルディスカッションは大まかに以下のようなセクションに分かれて実施されました。 パネリスト・モデレーター自己紹介 各社の開発/QA プロセスの理想と現実 QA エンジニアがいなかったらどうなる? QA エンジニアのキャリア これらのセクションに合わせて、パネリストそれぞれの立場で回答をしていきましたが、途中で視聴されている方の質問などは、モデレーターの菊池さんがほぼリアルタイムで拾っていきながらの進行だったので、イベントの一体感が非常に感じられて面白かったです。 自己紹介 横田さんも米山も現職に至るまでの経歴がかなり似ていました。第三者検証会社で様々な業態の会社を顧客として、様々な経験を積み重ねてから、事業会社での QA エンジニアとして特定のプロダクトの品質を高める仕事をしていらっしゃるという点です。 第三者検証会社で様々なニーズに対応したことが、プロダクトへの貢献に活きていそうだと感じました。 各社の開発/QA プロセスの理想と現実 QA を含めた開発体制については、両社で違いがもちろんありますが大きい違いでいうと、現在のメドレーではプロダクト開発チームの一員として QA エンジニアが所属しています。他方、Showcase Gig さんでは複数の開発チームを横断して QA チームが存在しているという部分でしょうか。 メドレーの現在の開発体制では、チーム内で開発メンバーと密接にやり取りをしながら品質を高めていくというプロセスが取られており、別の開発チームのヘルプなども、もちろんありますがアドバイザー的な感じで、実際にはそのチーム内で品質を高めるように動いています。 一方で Showcase Gig さんでは横断チームとして各プロダクトを俯瞰して見れるような体制にしている印象でした。それぞれの開発チームとは要所でシンクアップすることにより会社全体での QA プロセスを統一しながら各チームに展開できるのが良さそうだなと感じました。 理想と現実について そんな両社ですが、共通する部分として事業領域の難しさがありました。 メドレーは医療領域という難しさ、Showcase Gig さんではオンラインとオフラインの両立をしなければならない部分が特に難しいとのこと。 そこから話は QA の理想と現実に移っていきます。メドレーではプロダクトのより上流部分である仕様策定部分からバグを潰せるようにしていくのを目指しつつも、ガチガチな方法や体制にならないように日々 QA を行なっています。また E2E テストの失敗が非常事態だとメンバーが焦るくらいに成功率を高めていきたいという理想がありますが、どうしてもマニュアルでのテストが必要になってくるプロダクトなので、E2E テストだけに頼らないように試行錯誤しています。 Showcase Gig さんでは品質は担保しつつ、今以上にリリース頻度を上げるためにどうしたら良いかという点を開発チームと協業で改善しようとされているそうです。MagicPod を使った E2E テストだけでリリースまでできるようにするのが理想ではありますが、その前にプロセスの制定など前段階の準備を着々としているそうです。 QA エンジニアがいなかったらどうなる? QA エンジニアのイベントで中々出てこないような設問もあり大変面白かったのですが、それがこの「QA エンジニアがいなかったらどうなる?」という設問でした。 興味深かったのはお二人とも同じような返答だったことです。両社とも「リリースは通常通り行なわれるだろうが、リリース後の不具合対応などが増えるかもしれない」ということでした。またこれも共通して「QA エンジニアがいなくても品質保証がされることが理想」というお話でした。 実際に QA エンジニアはいなくてもきちんと高い品質のプロダクトを世に出していける仕組みや体制が理想というのは、関係者に品質についての意識が根差していけるようにするという意気込みのように聞こえ感銘を受けました。 QA エンジニアのキャリア また普段お二人はどのような意識配分で日々の仕事をされているかというのを円グラフで表わす試みが良かったです。 普段どのような事に時間や意識を割いているかというのが分かると自分の仕事の比率と比べてみちゃいますね。 ここから、皆さんが気になる QA エンジニアのキャリアについてお二人が話をされました。 米山は 15 年の QA 経験を持っていますが、その中でアジャイルやテスト自動化などのトレンドには「自分でもできるかな」と思いながら導入をしていったとのことでした。そうしながら、自分の中のプライオリティはあくまでも事業・プロダクトという部分だったので、ここにコミットができる立ち位置での仕事をずっと続けてきたと言います。 先のキャリアとしては、ポジションに捕われず事業価値を高めるように動いていき、どのような状況のチームでも品質を高めるための推進ができるようにしていきたいということでした。 一方の横田さんも今までの経験を踏まえ QA のポジションを高めていけるような動きをしていきたいということでした。テストなどに興味を持つ人の裾野を広げていきたいという意欲を感じました。個人としては UI/UX なども含めて品質を高めるということができればとのことでした。 お二人とも、「自分のキャリア」に留まらず周囲の人間にも、良い影響を与えていきたいということをおっしゃっているのが非常に印象的でした。 最後に 紹介した以外にも現場に即した QA についてや、品質についての考え方の一端が分かるようなイベントでした。自分はエンジニアという立場で視聴していましたが、そうした人間にも大変に示唆に富むお話が多く、あっという間に 1 時間が経過しました。QA エンジニアの方はもちろん、その他プロダクトを作るということに関わる方はぜひ、アーカイブを視聴してみてください!

はじめに 皆さん、こんにちは。エンジニア・技術広報の平木です。 以前からご覧になっていただいていた方にはお分かりかと思いますが、3/18 に今ご覧いただいているエンジニア・デザイナーブログを「Developer Portal」という名称に変更して 2017 年以来 5 年ぶりにリニューアルをしました。今回はリニューアルについて、目指すところと若干の技術的な側面をお伝えできればと思います。 ブログトップ新旧比較 旧 新 エンジニア・デザイナーブログリニューアルの背景 まずは、 なぜリニューアルしたか? という背景についてです。弊社のエンジニア・デザイナーブログの変遷と共にお話していきたいと思います。 エンジニア・デザイナーブログの変遷 第 1 期(2016/04 ~ 2017/07) Developer Blog は 2016/04 月に会社公式ブログにエンジニア向けの記事を掲載し始めたころから、しばらくは他の会社情報とともに掲載をしていました。記事内容はエンジニアが登壇したイベント情報や、今も続いている TechLunch(全社横断のエンジニア・デザイナー向け社内勉強会) の発表レポートなどがメインとなっていました。 この頃は開発組織の人数もそこまで多くなかったのですが、メドレーの開発組織を社内の様々な部署の雰囲気と共にお伝えしようという目的がメインでした。まずは、メドレーの開発組織としてのプレゼンスを高め、プロダクトを内製で日々開発をしていることを、外部の皆さんに知ってもらおうという目的が一番大きかったように思います。 このような形で 2017 年中頃までは会社公式ブログでの更新をしていましたが、開発組織が拡大するにつれ、組織として出来ることも増えてきました。それに伴い、これまでのように「開発組織の存在のアピール」や「組織の取り組み」に加えて、純粋に技術的な側面をもっと打ち出していき「医療 x IT」というテーマにメドレーはどのように向きあっているかを知ってもらおうという機運が高まってきました。 第 2 期(2017/07 ~ 2022/03) こうした運びで新しく Medley Developer Blog を 2017/07 月に立ち上げることになりました。会社公式ブログから完全に独立したテックブログということで、目論見通りにそれまで以上に技術的な投稿もできるようになりました。編集方式もこの時から現在までエンジニア・デザイナーが主体となっています。 更新頻度も不定期だったものを月 1~2 回と増やし、コンスタントにメドレーの開発に関する話題を取り扱うようにしました。運営をしていた 5 年の間にいくつかの記事は、おかげさまではてなブックマークなどで 話題 になることもあり、第 1 期よりもさらに皆さんに読んでいただけるようなブログになりました。 この間にメドレーも様々なエンジニア・デザイナーイベントにスポンサードさせていただいたりもして、ブログと合わせて一定のプレゼンスを得ることができてきたのではないかと思っています。特に「医療ヘルスケア業界」という馴染みが無い方にはハードルが高いと思われることが多い業界でのプロダクト開発に、一般的なインターネットテクノロジーを駆使しているという点を、色々な側面からお伝えできるようになったことは大きいと感じています。 現在(2022/03 ~) そんなブログでしたが、開設から 5 年経ち以下のような課題が出てきました。 会社がまだ上場前に作られたデザインだったため、現在のコーポレートサイトなどのトーンとズレが出てきている 会社や組織規模が大きくなり、希薄になりがちな内部で働いている個人にもフォーカスが当てられるようなコンテンツが欲しい 採用的な側面として、メドレーに興味を持った方へ提供できる情報がバラバラになっている 以上の課題を解決するために、ブログのリニューアルをすることになりました。 特に今年から全社的な方針として、メドレーのソフト面での話題にフォーカスしたコンテンツを作っていくということで、改めて公式 note の更新に注力していることもあり、エンジニア・デザイナーブログもこの動きと連動する必要がありました。 以上の理由から、コンテンツとしては従来通りの ブログ記事 、様々なメディアでメンバーが露出している インタビュー記事 、イベントなどで使われた 発表スライド を全て見られるような総合的なサイトにしていくこととなりました。 インタビューはこれまでもメンバーが様々なメディアに出ていたり、スライドも以前から Speaker Deck を更新していたのですが、まとまった形での提供ができていませんでした。 今回のリニューアルで、これらの要素をまとめて皆さんにお届けできるようになったため、「Medley Developer Blog」から「Medley Developer Portal」と名称変更をしました。 これからも、メドレーの開発組織をより外部の皆さんに知ってもらうために、運営ができればと考えていますので、よろしくお願いします。 エンジニア・デザイナーブログリニューアルの技術面について さて、ここまでリニューアルの背景をお伝えしましたが、ここからは今回使った技術面について軽く触れていこうと思います。 使用技術について 旧ブログは「はてなブログ」での運用をしていました。リニューアルにあたって上記の課題を解決するためには、独自にブログを開発したほうがよいと考えました。新ブログは以下の技術を使って開発しました。 Gatsby Emotion TypeScript Netlify Gatsby に決めた理由は大きくは以下でした。 既に弊社内で Gatsby の導入実績があるため、社内のメンバーがいざとなったら触れる ブログ + α のサイトを作るのに十分な柔軟性がある 公式やコミュニティプラグインが充実しており、開発が省力化できる Gatsby は精力的にアップデートが行なわれており、早いサイクルで進化するのも魅力の 1 つでした。 Gatsby 製サイトをどのように公開するかは、悩んだのですが、結果的に事例も多くありデプロイの簡易さや機能の豊富さを考えて Netlify にしました。 はてなブログからの記事移行について 最初から旧ブログでのコンテンツは新ブログに移行することがマストだったので、まずはどのように移行ができるかということを考慮することから始めました。はてなブログは通常のエクスポートだと Movable Type 方式になるので、なんとか Markdown に変換するか…などと考えていました。 しかし、 blogsync というはてなブログの CLI クライアントを通すとローカルに Markdown ファイルとしてブログエントリを同期することが可能だったため、 blogsync で全ての旧ブログコンテンツをローカルに同期(ダウンロード) ローカルに Markdown ファイルとしてダウンロードできたブログコンテンツを Gatsby 製の新ブログにコピー gatsby-source-filesystem でコピーした Markdown ファイルを読み込みブログとして表示 という手順で既存のブログ記事を全て移行することができました。 また、ドメインについては独自ドメインをそのまま新ブログにも移行することとしたため、はてなブログと同じ URL 形式でブログが読み込めるようにルーティングをしました。 苦労した部分 今回の開発で苦労した部分をダイジェストで書いていきます。自分のニーズに合わせて調べてみても、特に深い部分に関して、あまり情報が出てこないというパターンが多かったように思います。 バージョン固有の情報や、プラグインの情報が少なかった 開発当初は Gatsby v4 が出たばかりだったので、何かに困って検索しても公式以外の情報は以前のバージョンで使えないことが多かったです。 またプラグイン関係の情報も調べる内容によっては中々目的の情報が出てこなかったりしました。 gatsby-plugin-image 周りで顕著な印象だったので、画像周りの表示に泣かされることがありました。 他にも Markdown 表示は gatsby-plugin-mdx を使用していますが、従来の gatsby-transformer-remark と情報が混在している印象がありましたので混乱することも。 ページネーションでベストなプラグインが見つからなかった 公式 ガイドを参考にページネーションを自前で作っていたのですが、 GraphQL から持ってきたデータを表示するだけではあまりユーザビリティが良くなかったため、プラグインなど探したのですがこれといったものが見つからなかったです。 公式ガイド参考に作ると延々記事が増えたらページネーションの数も増えていってしまい微妙な感じでした…。自前で制御も考えましたが、最終的には mui/pagination コンポーネントを組み合わせることで対応しました。 OGP 画像自動生成に関して情報が少ない OGP 画像は自動生成にしたいと思いましたが、案外ニーズが無いのか情報が少なかった印象です。最終的に こちら のブログを発見し、 kentaro-m/catchy-image を使って生成するようにしました。 これからやりたいこと 機能の拡充以外だと、今まではできなかった textlint での校正などをして、編集時の負荷軽減などをやっていきたいと考えています。 さいごに 以上、 Developer Portal のリニューアルについて書かせていただきました。 引き続き、情報発信などをしていきメドレー開発組織について、皆さんに知っていただければと思います。 最後になりますが、医療ヘルスケアのプロダクト開発に(このようなブログ製作も)関わっていきたい!という方はぜひ下記よりご応募お待ちしております! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに 皆さん、こんにちは。エンジニア・技術広報の平木です。 以前からご覧になっていただいていた方にはお分かりかと思いますが、3/18 に今ご覧いただいているエンジニア・デザイナーブログを「Developer Portal」という名称に変更して 2017 年以来 5 年ぶりにリニューアルをしました。今回はリニューアルについて、目指すところと若干の技術的な側面をお伝えできればと思います。 ブログトップ新旧比較 旧 新 エンジニア・デザイナーブログリニューアルの背景 まずは、 なぜリニューアルしたか? という背景についてです。弊社のエンジニア・デザイナーブログの変遷と共にお話していきたいと思います。 エンジニア・デザイナーブログの変遷 第 1 期(2016/04 ~ 2017/07) Developer Blog は 2016/04 月に会社公式ブログにエンジニア向けの記事を掲載し始めたころから、しばらくは他の会社情報とともに掲載をしていました。記事内容はエンジニアが登壇したイベント情報や、今も続いている TechLunch(全社横断のエンジニア・デザイナー向け社内勉強会) の発表レポートなどがメインとなっていました。 この頃は開発組織の人数もそこまで多くなかったのですが、メドレーの開発組織を社内の様々な部署の雰囲気と共にお伝えしようという目的がメインでした。まずは、メドレーの開発組織としてのプレゼンスを高め、プロダクトを内製で日々開発をしていることを、外部の皆さんに知ってもらおうという目的が一番大きかったように思います。 このような形で 2017 年中頃までは会社公式ブログでの更新をしていましたが、開発組織が拡大するにつれ、組織として出来ることも増えてきました。それに伴い、これまでのように「開発組織の存在のアピール」や「組織の取り組み」に加えて、純粋に技術的な側面をもっと打ち出していき「医療 x IT」というテーマにメドレーはどのように向きあっているかを知ってもらおうという機運が高まってきました。 第 2 期(2017/07 ~ 2022/03) こうした運びで新しく Medley Developer Blog を 2017/07 月に立ち上げることになりました。会社公式ブログから完全に独立したテックブログということで、目論見通りにそれまで以上に技術的な投稿もできるようになりました。編集方式もこの時から現在までエンジニア・デザイナーが主体となっています。 更新頻度も不定期だったものを月 1~2 回と増やし、コンスタントにメドレーの開発に関する話題を取り扱うようにしました。運営をしていた 5 年の間にいくつかの記事は、おかげさまではてなブックマークなどで 話題 になることもあり、第 1 期よりもさらに皆さんに読んでいただけるようなブログになりました。 この間にメドレーも様々なエンジニア・デザイナーイベントにスポンサードさせていただいたりもして、ブログと合わせて一定のプレゼンスを得ることができてきたのではないかと思っています。特に「医療ヘルスケア業界」という馴染みが無い方にはハードルが高いと思われることが多い業界でのプロダクト開発に、一般的なインターネットテクノロジーを駆使しているという点を、色々な側面からお伝えできるようになったことは大きいと感じています。 現在(2022/03 ~) そんなブログでしたが、開設から 5 年経ち以下のような課題が出てきました。 会社がまだ上場前に作られたデザインだったため、現在のコーポレートサイトなどのトーンとズレが出てきている 会社や組織規模が大きくなり、希薄になりがちな内部で働いている個人にもフォーカスが当てられるようなコンテンツが欲しい 採用的な側面として、メドレーに興味を持った方へ提供できる情報がバラバラになっている 以上の課題を解決するために、ブログのリニューアルをすることになりました。 特に今年から全社的な方針として、メドレーのソフト面での話題にフォーカスしたコンテンツを作っていくということで、改めて公式 note の更新に注力していることもあり、エンジニア・デザイナーブログもこの動きと連動する必要がありました。 以上の理由から、コンテンツとしては従来通りの ブログ記事 、様々なメディアでメンバーが露出している インタビュー記事 、イベントなどで使われた 発表スライド を全て見られるような総合的なサイトにしていくこととなりました。 インタビューはこれまでもメンバーが様々なメディアに出ていたり、スライドも以前から Speaker Deck を更新していたのですが、まとまった形での提供ができていませんでした。 今回のリニューアルで、これらの要素をまとめて皆さんにお届けできるようになったため、「Medley Developer Blog」から「Medley Developer Portal」と名称変更をしました。 これからも、メドレーの開発組織をより外部の皆さんに知ってもらうために、運営ができればと考えていますので、よろしくお願いします。 エンジニア・デザイナーブログリニューアルの技術面について さて、ここまでリニューアルの背景をお伝えしましたが、ここからは今回使った技術面について軽く触れていこうと思います。 使用技術について 旧ブログは「はてなブログ」での運用をしていました。リニューアルにあたって上記の課題を解決するためには、独自にブログを開発したほうがよいと考えました。新ブログは以下の技術を使って開発しました。 Gatsby Emotion TypeScript Netlify Gatsby に決めた理由は大きくは以下でした。 既に弊社内で Gatsby の導入実績があるため、社内のメンバーがいざとなったら触れる ブログ + α のサイトを作るのに十分な柔軟性がある 公式やコミュニティプラグインが充実しており、開発が省力化できる Gatsby は精力的にアップデートが行なわれており、早いサイクルで進化するのも魅力の 1 つでした。 Gatsby 製サイトをどのように公開するかは、悩んだのですが、結果的に事例も多くありデプロイの簡易さや機能の豊富さを考えて Netlify にしました。 はてなブログからの記事移行について 最初から旧ブログでのコンテンツは新ブログに移行することがマストだったので、まずはどのように移行ができるかということを考慮することから始めました。はてなブログは通常のエクスポートだと Movable Type 方式になるので、なんとか Markdown に変換するか…などと考えていました。 しかし、 blogsync というはてなブログの CLI クライアントを通すとローカルに Markdown ファイルとしてブログエントリを同期することが可能だったため、 blogsync で全ての旧ブログコンテンツをローカルに同期(ダウンロード) ローカルに Markdown ファイルとしてダウンロードできたブログコンテンツを Gatsby 製の新ブログにコピー gatsby-source-filesystem でコピーした Markdown ファイルを読み込みブログとして表示 という手順で既存のブログ記事を全て移行することができました。 また、ドメインについては独自ドメインをそのまま新ブログにも移行することとしたため、はてなブログと同じ URL 形式でブログが読み込めるようにルーティングをしました。 苦労した部分 今回の開発で苦労した部分をダイジェストで書いていきます。自分のニーズに合わせて調べてみても、特に深い部分に関して、あまり情報が出てこないというパターンが多かったように思います。 バージョン固有の情報や、プラグインの情報が少なかった 開発当初は Gatsby v4 が出たばかりだったので、何かに困って検索しても公式以外の情報は以前のバージョンで使えないことが多かったです。 またプラグイン関係の情報も調べる内容によっては中々目的の情報が出てこなかったりしました。 gatsby-plugin-image 周りで顕著な印象だったので、画像周りの表示に泣かされることがありました。 他にも Markdown 表示は gatsby-plugin-mdx を使用していますが、従来の gatsby-transformer-remark と情報が混在している印象がありましたので混乱することも。 ページネーションでベストなプラグインが見つからなかった 公式 ガイドを参考にページネーションを自前で作っていたのですが、 GraphQL から持ってきたデータを表示するだけではあまりユーザビリティが良くなかったため、プラグインなど探したのですがこれといったものが見つからなかったです。 公式ガイド参考に作ると延々記事が増えたらページネーションの数も増えていってしまい微妙な感じでした…。自前で制御も考えましたが、最終的には mui/pagination コンポーネントを組み合わせることで対応しました。 OGP 画像自動生成に関して情報が少ない OGP 画像は自動生成にしたいと思いましたが、案外ニーズが無いのか情報が少なかった印象です。最終的に こちら のブログを発見し、 kentaro-m/catchy-image を使って生成するようにしました。 これからやりたいこと 機能の拡充以外だと、今まではできなかった textlint での校正などをして、編集時の負荷軽減などをやっていきたいと考えています。 さいごに 以上、 Developer Portal のリニューアルについて書かせていただきました。 引き続き、情報発信などをしていきメドレー開発組織について、皆さんに知っていただければと思います。 最後になりますが、医療ヘルスケアのプロダクト開発に(このようなブログ製作も)関わっていきたい!という方はぜひ下記よりご応募お待ちしております! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに 皆さん、こんにちは。エンジニア・技術広報の平木です。 以前からご覧になっていただいていた方にはお分かりかと思いますが、3/18 に今ご覧いただいているエンジニア・デザイナーブログを「Developer Portal」という名称に変更して 2017 年以来 5 年ぶりにリニューアルをしました。今回はリニューアルについて、目指すところと若干の技術的な側面をお伝えできればと思います。 ブログトップ新旧比較 旧 新 エンジニア・デザイナーブログリニューアルの背景 まずは、 なぜリニューアルしたか? という背景についてです。弊社のエンジニア・デザイナーブログの変遷と共にお話していきたいと思います。 エンジニア・デザイナーブログの変遷 第 1 期(2016/04 ~ 2017/07) Developer Blog は 2016/04 月に会社公式ブログにエンジニア向けの記事を掲載し始めたころから、しばらくは他の会社情報とともに掲載をしていました。記事内容はエンジニアが登壇したイベント情報や、今も続いている TechLunch(全社横断のエンジニア・デザイナー向け社内勉強会) の発表レポートなどがメインとなっていました。 この頃は開発組織の人数もそこまで多くなかったのですが、メドレーの開発組織を社内の様々な部署の雰囲気と共にお伝えしようという目的がメインでした。まずは、メドレーの開発組織としてのプレゼンスを高め、プロダクトを内製で日々開発をしていることを、外部の皆さんに知ってもらおうという目的が一番大きかったように思います。 このような形で 2017 年中頃までは会社公式ブログでの更新をしていましたが、開発組織が拡大するにつれ、組織として出来ることも増えてきました。それに伴い、これまでのように「開発組織の存在のアピール」や「組織の取り組み」に加えて、純粋に技術的な側面をもっと打ち出していき「医療 x IT」というテーマにメドレーはどのように向きあっているかを知ってもらおうという機運が高まってきました。 第 2 期(2017/07 ~ 2022/03) こうした運びで新しく Medley Developer Blog を 2017/07 月に立ち上げることになりました。会社公式ブログから完全に独立したテックブログということで、目論見通りにそれまで以上に技術的な投稿もできるようになりました。編集方式もこの時から現在までエンジニア・デザイナーが主体となっています。 更新頻度も不定期だったものを月 1~2 回と増やし、コンスタントにメドレーの開発に関する話題を取り扱うようにしました。運営をしていた 5 年の間にいくつかの記事は、おかげさまではてなブックマークなどで 話題 になることもあり、第 1 期よりもさらに皆さんに読んでいただけるようなブログになりました。 この間にメドレーも様々なエンジニア・デザイナーイベントにスポンサードさせていただいたりもして、ブログと合わせて一定のプレゼンスを得ることができてきたのではないかと思っています。特に「医療ヘルスケア業界」という馴染みが無い方にはハードルが高いと思われることが多い業界でのプロダクト開発に、一般的なインターネットテクノロジーを駆使しているという点を、色々な側面からお伝えできるようになったことは大きいと感じています。 現在(2022/03 ~) そんなブログでしたが、開設から 5 年経ち以下のような課題が出てきました。 会社がまだ上場前に作られたデザインだったため、現在のコーポレートサイトなどのトーンとズレが出てきている 会社や組織規模が大きくなり、希薄になりがちな内部で働いている個人にもフォーカスが当てられるようなコンテンツが欲しい 採用的な側面として、メドレーに興味を持った方へ提供できる情報がバラバラになっている 以上の課題を解決するために、ブログのリニューアルをすることになりました。 特に今年から全社的な方針として、メドレーのソフト面での話題にフォーカスしたコンテンツを作っていくということで、改めて公式 note の更新に注力していることもあり、エンジニア・デザイナーブログもこの動きと連動する必要がありました。 以上の理由から、コンテンツとしては従来通りの ブログ記事 、様々なメディアでメンバーが露出している インタビュー記事 、イベントなどで使われた 発表スライド を全て見られるような総合的なサイトにしていくこととなりました。 インタビューはこれまでもメンバーが様々なメディアに出ていたり、スライドも以前から Speaker Deck を更新していたのですが、まとまった形での提供ができていませんでした。 今回のリニューアルで、これらの要素をまとめて皆さんにお届けできるようになったため、「Medley Developer Blog」から「Medley Developer Portal」と名称変更をしました。 これからも、メドレーの開発組織をより外部の皆さんに知ってもらうために、運営ができればと考えていますので、よろしくお願いします。 エンジニア・デザイナーブログリニューアルの技術面について さて、ここまでリニューアルの背景をお伝えしましたが、ここからは今回使った技術面について軽く触れていこうと思います。 使用技術について 旧ブログは「はてなブログ」での運用をしていました。リニューアルにあたって上記の課題を解決するためには、独自にブログを開発したほうがよいと考えました。新ブログは以下の技術を使って開発しました。 Gatsby Emotion TypeScript Netlify Gatsby に決めた理由は大きくは以下でした。 既に弊社内で Gatsby の導入実績があるため、社内のメンバーがいざとなったら触れる ブログ + α のサイトを作るのに十分な柔軟性がある 公式やコミュニティプラグインが充実しており、開発が省力化できる Gatsby は精力的にアップデートが行なわれており、早いサイクルで進化するのも魅力の 1 つでした。 Gatsby 製サイトをどのように公開するかは、悩んだのですが、結果的に事例も多くありデプロイの簡易さや機能の豊富さを考えて Netlify にしました。 はてなブログからの記事移行について 最初から旧ブログでのコンテンツは新ブログに移行することがマストだったので、まずはどのように移行ができるかということを考慮することから始めました。はてなブログは通常のエクスポートだと Movable Type 方式になるので、なんとか Markdown に変換するか…などと考えていました。 しかし、 blogsync というはてなブログの CLI クライアントを通すとローカルに Markdown ファイルとしてブログエントリを同期することが可能だったため、 blogsync で全ての旧ブログコンテンツをローカルに同期(ダウンロード) ローカルに Markdown ファイルとしてダウンロードできたブログコンテンツを Gatsby 製の新ブログにコピー gatsby-source-filesystem でコピーした Markdown ファイルを読み込みブログとして表示 という手順で既存のブログ記事を全て移行することができました。 また、ドメインについては独自ドメインをそのまま新ブログにも移行することとしたため、はてなブログと同じ URL 形式でブログが読み込めるようにルーティングをしました。 苦労した部分 今回の開発で苦労した部分をダイジェストで書いていきます。自分のニーズに合わせて調べてみても、特に深い部分に関して、あまり情報が出てこないというパターンが多かったように思います。 バージョン固有の情報や、プラグインの情報が少なかった 開発当初は Gatsby v4 が出たばかりだったので、何かに困って検索しても公式以外の情報は以前のバージョンで使えないことが多かったです。 またプラグイン関係の情報も調べる内容によっては中々目的の情報が出てこなかったりしました。 gatsby-plugin-image 周りで顕著な印象だったので、画像周りの表示に泣かされることがありました。 他にも Markdown 表示は gatsby-plugin-mdx を使用していますが、従来の gatsby-transformer-remark と情報が混在している印象がありましたので混乱することも。 ページネーションでベストなプラグインが見つからなかった 公式 ガイドを参考にページネーションを自前で作っていたのですが、 GraphQL から持ってきたデータを表示するだけではあまりユーザビリティが良くなかったため、プラグインなど探したのですがこれといったものが見つからなかったです。 公式ガイド参考に作ると延々記事が増えたらページネーションの数も増えていってしまい微妙な感じでした…。自前で制御も考えましたが、最終的には mui/pagination コンポーネントを組み合わせることで対応しました。 OGP 画像自動生成に関して情報が少ない OGP 画像は自動生成にしたいと思いましたが、案外ニーズが無いのか情報が少なかった印象です。最終的に こちら のブログを発見し、 kentaro-m/catchy-image を使って生成するようにしました。 これからやりたいこと 機能の拡充以外だと、今まではできなかった textlint での校正などをして、編集時の負荷軽減などをやっていきたいと考えています。 さいごに 以上、 Developer Portal のリニューアルについて書かせていただきました。 引き続き、情報発信などをしていきメドレー開発組織について、皆さんに知っていただければと思います。 最後になりますが、医療ヘルスケアのプロダクト開発に(このようなブログ製作も)関わっていきたい!という方はぜひ下記よりご応募お待ちしております! https://www.medley.jp/jobs/

はじめに 皆さん、こんにちは。エンジニア・技術広報の平木です。 以前からご覧になっていただいていた方にはお分かりかと思いますが、3/18 に今ご覧いただいているエンジニア・デザイナーブログを「Developer Portal」という名称に変更して 2017 年以来 5 年ぶりにリニューアルをしました。今回はリニューアルについて、目指すところと若干の技術的な側面をお伝えできればと思います。 ブログトップ新旧比較 旧 新 エンジニア・デザイナーブログリニューアルの背景 まずは、 なぜリニューアルしたか? という背景についてです。弊社のエンジニア・デザイナーブログの変遷と共にお話していきたいと思います。 エンジニア・デザイナーブログの変遷 第 1 期(2016/04 ~ 2017/07) Developer Blog は 2016/04 月に会社公式ブログにエンジニア向けの記事を掲載し始めたころから、しばらくは他の会社情報とともに掲載をしていました。記事内容はエンジニアが登壇したイベント情報や、今も続いている TechLunch(全社横断のエンジニア・デザイナー向け社内勉強会) の発表レポートなどがメインとなっていました。 この頃は開発組織の人数もそこまで多くなかったのですが、メドレーの開発組織を社内の様々な部署の雰囲気と共にお伝えしようという目的がメインでした。まずは、メドレーの開発組織としてのプレゼンスを高め、プロダクトを内製で日々開発をしていることを、外部の皆さんに知ってもらおうという目的が一番大きかったように思います。 このような形で 2017 年中頃までは会社公式ブログでの更新をしていましたが、開発組織が拡大するにつれ、組織として出来ることも増えてきました。それに伴い、これまでのように「開発組織の存在のアピール」や「組織の取り組み」に加えて、純粋に技術的な側面をもっと打ち出していき「医療 x IT」というテーマにメドレーはどのように向きあっているかを知ってもらおうという機運が高まってきました。 第 2 期(2017/07 ~ 2022/03) こうした運びで新しく Medley Developer Blog を 2017/07 月に立ち上げることになりました。会社公式ブログから完全に独立したテックブログということで、目論見通りにそれまで以上に技術的な投稿もできるようになりました。編集方式もこの時から現在までエンジニア・デザイナーが主体となっています。 更新頻度も不定期だったものを月 1~2 回と増やし、コンスタントにメドレーの開発に関する話題を取り扱うようにしました。運営をしていた 5 年の間にいくつかの記事は、おかげさまではてなブックマークなどで 話題 になることもあり、第 1 期よりもさらに皆さんに読んでいただけるようなブログになりました。 この間にメドレーも様々なエンジニア・デザイナーイベントにスポンサードさせていただいたりもして、ブログと合わせて一定のプレゼンスを得ることができてきたのではないかと思っています。特に「医療ヘルスケア業界」という馴染みが無い方にはハードルが高いと思われることが多い業界でのプロダクト開発に、一般的なインターネットテクノロジーを駆使しているという点を、色々な側面からお伝えできるようになったことは大きいと感じています。 現在(2022/03 ~) そんなブログでしたが、開設から 5 年経ち以下のような課題が出てきました。 会社がまだ上場前に作られたデザインだったため、現在のコーポレートサイトなどのトーンとズレが出てきている 会社や組織規模が大きくなり、希薄になりがちな内部で働いている個人にもフォーカスが当てられるようなコンテンツが欲しい 採用的な側面として、メドレーに興味を持った方へ提供できる情報がバラバラになっている 以上の課題を解決するために、ブログのリニューアルをすることになりました。 特に今年から全社的な方針として、メドレーのソフト面での話題にフォーカスしたコンテンツを作っていくということで、改めて公式 note の更新に注力していることもあり、エンジニア・デザイナーブログもこの動きと連動する必要がありました。 以上の理由から、コンテンツとしては従来通りの ブログ記事 、様々なメディアでメンバーが露出している インタビュー記事 、イベントなどで使われた 発表スライド を全て見られるような総合的なサイトにしていくこととなりました。 インタビューはこれまでもメンバーが様々なメディアに出ていたり、スライドも以前から Speaker Deck を更新していたのですが、まとまった形での提供ができていませんでした。 今回のリニューアルで、これらの要素をまとめて皆さんにお届けできるようになったため、「Medley Developer Blog」から「Medley Developer Portal」と名称変更をしました。 これからも、メドレーの開発組織をより外部の皆さんに知ってもらうために、運営ができればと考えていますので、よろしくお願いします。 エンジニア・デザイナーブログリニューアルの技術面について さて、ここまでリニューアルの背景をお伝えしましたが、ここからは今回使った技術面について軽く触れていこうと思います。 使用技術について 旧ブログは「はてなブログ」での運用をしていました。リニューアルにあたって上記の課題を解決するためには、独自にブログを開発したほうがよいと考えました。新ブログは以下の技術を使って開発しました。 Gatsby Emotion TypeScript Netlify Gatsby に決めた理由は大きくは以下でした。 既に弊社内で Gatsby の導入実績があるため、社内のメンバーがいざとなったら触れる ブログ + α のサイトを作るのに十分な柔軟性がある 公式やコミュニティプラグインが充実しており、開発が省力化できる Gatsby は精力的にアップデートが行なわれており、早いサイクルで進化するのも魅力の 1 つでした。 Gatsby 製サイトをどのように公開するかは、悩んだのですが、結果的に事例も多くありデプロイの簡易さや機能の豊富さを考えて Netlify にしました。 はてなブログからの記事移行について 最初から旧ブログでのコンテンツは新ブログに移行することがマストだったので、まずはどのように移行ができるかということを考慮することから始めました。はてなブログは通常のエクスポートだと Movable Type 方式になるので、なんとか Markdown に変換するか…などと考えていました。 しかし、 blogsync というはてなブログの CLI クライアントを通すとローカルに Markdown ファイルとしてブログエントリを同期することが可能だったため、 blogsync で全ての旧ブログコンテンツをローカルに同期(ダウンロード) ローカルに Markdown ファイルとしてダウンロードできたブログコンテンツを Gatsby 製の新ブログにコピー gatsby-source-filesystem でコピーした Markdown ファイルを読み込みブログとして表示 という手順で既存のブログ記事を全て移行することができました。 また、ドメインについては独自ドメインをそのまま新ブログにも移行することとしたため、はてなブログと同じ URL 形式でブログが読み込めるようにルーティングをしました。 苦労した部分 今回の開発で苦労した部分をダイジェストで書いていきます。自分のニーズに合わせて調べてみても、特に深い部分に関して、あまり情報が出てこないというパターンが多かったように思います。 バージョン固有の情報や、プラグインの情報が少なかった 開発当初は Gatsby v4 が出たばかりだったので、何かに困って検索しても公式以外の情報は以前のバージョンで使えないことが多かったです。 またプラグイン関係の情報も調べる内容によっては中々目的の情報が出てこなかったりしました。 gatsby-plugin-image 周りで顕著な印象だったので、画像周りの表示に泣かされることがありました。 他にも Markdown 表示は gatsby-plugin-mdx を使用していますが、従来の gatsby-transformer-remark と情報が混在している印象がありましたので混乱することも。 ページネーションでベストなプラグインが見つからなかった 公式 ガイドを参考にページネーションを自前で作っていたのですが、 GraphQL から持ってきたデータを表示するだけではあまりユーザビリティが良くなかったため、プラグインなど探したのですがこれといったものが見つからなかったです。 公式ガイド参考に作ると延々記事が増えたらページネーションの数も増えていってしまい微妙な感じでした…。自前で制御も考えましたが、最終的には mui/pagination コンポーネントを組み合わせることで対応しました。 OGP 画像自動生成に関して情報が少ない OGP 画像は自動生成にしたいと思いましたが、案外ニーズが無いのか情報が少なかった印象です。最終的に こちら のブログを発見し、 kentaro-m/catchy-image を使って生成するようにしました。 これからやりたいこと 機能の拡充以外だと、今まではできなかった textlint での校正などをして、編集時の負荷軽減などをやっていきたいと考えています。 さいごに 以上、 Developer Portal のリニューアルについて書かせていただきました。 引き続き、情報発信などをしていきメドレー開発組織について、皆さんに知っていただければと思います。 最後になりますが、医療ヘルスケアのプロダクト開発に(このようなブログ製作も)関わっていきたい!という方はぜひ下記よりご応募お待ちしております! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに 皆さん、こんにちは。エンジニア・技術広報の平木です。 以前からご覧になっていただいていた方にはお分かりかと思いますが、3/18 に今ご覧いただいているエンジニア・デザイナーブログを「Developer Portal」という名称に変更して 2017 年以来 5 年ぶりにリニューアルをしました。今回はリニューアルについて、目指すところと若干の技術的な側面をお伝えできればと思います。 ブログトップ新旧比較 旧 新 エンジニア・デザイナーブログリニューアルの背景 まずは、 なぜリニューアルしたか? という背景についてです。弊社のエンジニア・デザイナーブログの変遷と共にお話していきたいと思います。 エンジニア・デザイナーブログの変遷 第 1 期(2016/04 ~ 2017/07) Developer Blog は 2016/04 月に会社公式ブログにエンジニア向けの記事を掲載し始めたころから、しばらくは他の会社情報とともに掲載をしていました。記事内容はエンジニアが登壇したイベント情報や、今も続いている TechLunch(全社横断のエンジニア・デザイナー向け社内勉強会) の発表レポートなどがメインとなっていました。 この頃は開発組織の人数もそこまで多くなかったのですが、メドレーの開発組織を社内の様々な部署の雰囲気と共にお伝えしようという目的がメインでした。まずは、メドレーの開発組織としてのプレゼンスを高め、プロダクトを内製で日々開発をしていることを、外部の皆さんに知ってもらおうという目的が一番大きかったように思います。 このような形で 2017 年中頃までは会社公式ブログでの更新をしていましたが、開発組織が拡大するにつれ、組織として出来ることも増えてきました。それに伴い、これまでのように「開発組織の存在のアピール」や「組織の取り組み」に加えて、純粋に技術的な側面をもっと打ち出していき「医療 x IT」というテーマにメドレーはどのように向きあっているかを知ってもらおうという機運が高まってきました。 第 2 期(2017/07 ~ 2022/03) こうした運びで新しく Medley Developer Blog を 2017/07 月に立ち上げることになりました。会社公式ブログから完全に独立したテックブログということで、目論見通りにそれまで以上に技術的な投稿もできるようになりました。編集方式もこの時から現在までエンジニア・デザイナーが主体となっています。 更新頻度も不定期だったものを月 1~2 回と増やし、コンスタントにメドレーの開発に関する話題を取り扱うようにしました。運営をしていた 5 年の間にいくつかの記事は、おかげさまではてなブックマークなどで 話題 になることもあり、第 1 期よりもさらに皆さんに読んでいただけるようなブログになりました。 この間にメドレーも様々なエンジニア・デザイナーイベントにスポンサードさせていただいたりもして、ブログと合わせて一定のプレゼンスを得ることができてきたのではないかと思っています。特に「医療ヘルスケア業界」という馴染みが無い方にはハードルが高いと思われることが多い業界でのプロダクト開発に、一般的なインターネットテクノロジーを駆使しているという点を、色々な側面からお伝えできるようになったことは大きいと感じています。 現在(2022/03 ~) そんなブログでしたが、開設から 5 年経ち以下のような課題が出てきました。 会社がまだ上場前に作られたデザインだったため、現在のコーポレートサイトなどのトーンとズレが出てきている 会社や組織規模が大きくなり、希薄になりがちな内部で働いている個人にもフォーカスが当てられるようなコンテンツが欲しい 採用的な側面として、メドレーに興味を持った方へ提供できる情報がバラバラになっている 以上の課題を解決するために、ブログのリニューアルをすることになりました。 特に今年から全社的な方針として、メドレーのソフト面での話題にフォーカスしたコンテンツを作っていくということで、改めて公式 note の更新に注力していることもあり、エンジニア・デザイナーブログもこの動きと連動する必要がありました。 以上の理由から、コンテンツとしては従来通りの ブログ記事 、様々なメディアでメンバーが露出している インタビュー記事 、イベントなどで使われた 発表スライド を全て見られるような総合的なサイトにしていくこととなりました。 インタビューはこれまでもメンバーが様々なメディアに出ていたり、スライドも以前から Speaker Deck を更新していたのですが、まとまった形での提供ができていませんでした。 今回のリニューアルで、これらの要素をまとめて皆さんにお届けできるようになったため、「Medley Developer Blog」から「Medley Developer Portal」と名称変更をしました。 これからも、メドレーの開発組織をより外部の皆さんに知ってもらうために、運営ができればと考えていますので、よろしくお願いします。 エンジニア・デザイナーブログリニューアルの技術面について さて、ここまでリニューアルの背景をお伝えしましたが、ここからは今回使った技術面について軽く触れていこうと思います。 使用技術について 旧ブログは「はてなブログ」での運用をしていました。リニューアルにあたって上記の課題を解決するためには、独自にブログを開発したほうがよいと考えました。新ブログは以下の技術を使って開発しました。 Gatsby Emotion TypeScript Netlify Gatsby に決めた理由は大きくは以下でした。 既に弊社内で Gatsby の導入実績があるため、社内のメンバーがいざとなったら触れる ブログ + α のサイトを作るのに十分な柔軟性がある 公式やコミュニティプラグインが充実しており、開発が省力化できる Gatsby は精力的にアップデートが行なわれており、早いサイクルで進化するのも魅力の 1 つでした。 Gatsby 製サイトをどのように公開するかは、悩んだのですが、結果的に事例も多くありデプロイの簡易さや機能の豊富さを考えて Netlify にしました。 はてなブログからの記事移行について 最初から旧ブログでのコンテンツは新ブログに移行することがマストだったので、まずはどのように移行ができるかということを考慮することから始めました。はてなブログは通常のエクスポートだと Movable Type 方式になるので、なんとか Markdown に変換するか…などと考えていました。 しかし、 blogsync というはてなブログの CLI クライアントを通すとローカルに Markdown ファイルとしてブログエントリを同期することが可能だったため、 blogsync で全ての旧ブログコンテンツをローカルに同期(ダウンロード) ローカルに Markdown ファイルとしてダウンロードできたブログコンテンツを Gatsby 製の新ブログにコピー gatsby-source-filesystem でコピーした Markdown ファイルを読み込みブログとして表示 という手順で既存のブログ記事を全て移行することができました。 また、ドメインについては独自ドメインをそのまま新ブログにも移行することとしたため、はてなブログと同じ URL 形式でブログが読み込めるようにルーティングをしました。 苦労した部分 今回の開発で苦労した部分をダイジェストで書いていきます。自分のニーズに合わせて調べてみても、特に深い部分に関して、あまり情報が出てこないというパターンが多かったように思います。 バージョン固有の情報や、プラグインの情報が少なかった 開発当初は Gatsby v4 が出たばかりだったので、何かに困って検索しても公式以外の情報は以前のバージョンで使えないことが多かったです。 またプラグイン関係の情報も調べる内容によっては中々目的の情報が出てこなかったりしました。 gatsby-plugin-image 周りで顕著な印象だったので、画像周りの表示に泣かされることがありました。 他にも Markdown 表示は gatsby-plugin-mdx を使用していますが、従来の gatsby-transformer-remark と情報が混在している印象がありましたので混乱することも。 ページネーションでベストなプラグインが見つからなかった 公式 ガイドを参考にページネーションを自前で作っていたのですが、 GraphQL から持ってきたデータを表示するだけではあまりユーザビリティが良くなかったため、プラグインなど探したのですがこれといったものが見つからなかったです。 公式ガイド参考に作ると延々記事が増えたらページネーションの数も増えていってしまい微妙な感じでした…。自前で制御も考えましたが、最終的には mui/pagination コンポーネントを組み合わせることで対応しました。 OGP 画像自動生成に関して情報が少ない OGP 画像は自動生成にしたいと思いましたが、案外ニーズが無いのか情報が少なかった印象です。最終的に こちら のブログを発見し、 kentaro-m/catchy-image を使って生成するようにしました。 これからやりたいこと 機能の拡充以外だと、今まではできなかった textlint での校正などをして、編集時の負荷軽減などをやっていきたいと考えています。 さいごに 以上、 Developer Portal のリニューアルについて書かせていただきました。 引き続き、情報発信などをしていきメドレー開発組織について、皆さんに知っていただければと思います。 最後になりますが、医療ヘルスケアのプロダクト開発に(このようなブログ製作も)関わっていきたい!という方はぜひ下記よりご応募お待ちしております! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに 皆さん、こんにちは。エンジニア・技術広報の平木です。 以前からご覧になっていただいていた方にはお分かりかと思いますが、3/18 に今ご覧いただいているエンジニア・デザイナーブログを「Developer Portal」という名称に変更して 2017 年以来 5 年ぶりにリニューアルをしました。今回はリニューアルについて、目指すところと若干の技術的な側面をお伝えできればと思います。 ブログトップ新旧比較 旧 新 エンジニア・デザイナーブログリニューアルの背景 まずは、 なぜリニューアルしたか? という背景についてです。弊社のエンジニア・デザイナーブログの変遷と共にお話していきたいと思います。 エンジニア・デザイナーブログの変遷 第 1 期(2016/04 ~ 2017/07) Developer Blog は 2016/04 月に会社公式ブログにエンジニア向けの記事を掲載し始めたころから、しばらくは他の会社情報とともに掲載をしていました。記事内容はエンジニアが登壇したイベント情報や、今も続いている TechLunch(全社横断のエンジニア・デザイナー向け社内勉強会) の発表レポートなどがメインとなっていました。 この頃は開発組織の人数もそこまで多くなかったのですが、メドレーの開発組織を社内の様々な部署の雰囲気と共にお伝えしようという目的がメインでした。まずは、メドレーの開発組織としてのプレゼンスを高め、プロダクトを内製で日々開発をしていることを、外部の皆さんに知ってもらおうという目的が一番大きかったように思います。 このような形で 2017 年中頃までは会社公式ブログでの更新をしていましたが、開発組織が拡大するにつれ、組織として出来ることも増えてきました。それに伴い、これまでのように「開発組織の存在のアピール」や「組織の取り組み」に加えて、純粋に技術的な側面をもっと打ち出していき「医療 x IT」というテーマにメドレーはどのように向きあっているかを知ってもらおうという機運が高まってきました。 第 2 期(2017/07 ~ 2022/03) こうした運びで新しく Medley Developer Blog を 2017/07 月に立ち上げることになりました。会社公式ブログから完全に独立したテックブログということで、目論見通りにそれまで以上に技術的な投稿もできるようになりました。編集方式もこの時から現在までエンジニア・デザイナーが主体となっています。 更新頻度も不定期だったものを月 1~2 回と増やし、コンスタントにメドレーの開発に関する話題を取り扱うようにしました。運営をしていた 5 年の間にいくつかの記事は、おかげさまではてなブックマークなどで 話題 になることもあり、第 1 期よりもさらに皆さんに読んでいただけるようなブログになりました。 この間にメドレーも様々なエンジニア・デザイナーイベントにスポンサードさせていただいたりもして、ブログと合わせて一定のプレゼンスを得ることができてきたのではないかと思っています。特に「医療ヘルスケア業界」という馴染みが無い方にはハードルが高いと思われることが多い業界でのプロダクト開発に、一般的なインターネットテクノロジーを駆使しているという点を、色々な側面からお伝えできるようになったことは大きいと感じています。 現在(2022/03 ~) そんなブログでしたが、開設から 5 年経ち以下のような課題が出てきました。 会社がまだ上場前に作られたデザインだったため、現在のコーポレートサイトなどのトーンとズレが出てきている 会社や組織規模が大きくなり、希薄になりがちな内部で働いている個人にもフォーカスが当てられるようなコンテンツが欲しい 採用的な側面として、メドレーに興味を持った方へ提供できる情報がバラバラになっている 以上の課題を解決するために、ブログのリニューアルをすることになりました。 特に今年から全社的な方針として、メドレーのソフト面での話題にフォーカスしたコンテンツを作っていくということで、改めて公式 note の更新に注力していることもあり、エンジニア・デザイナーブログもこの動きと連動する必要がありました。 以上の理由から、コンテンツとしては従来通りの ブログ記事 、様々なメディアでメンバーが露出している インタビュー記事 、イベントなどで使われた 発表スライド を全て見られるような総合的なサイトにしていくこととなりました。 インタビューはこれまでもメンバーが様々なメディアに出ていたり、スライドも以前から Speaker Deck を更新していたのですが、まとまった形での提供ができていませんでした。 今回のリニューアルで、これらの要素をまとめて皆さんにお届けできるようになったため、「Medley Developer Blog」から「Medley Developer Portal」と名称変更をしました。 これからも、メドレーの開発組織をより外部の皆さんに知ってもらうために、運営ができればと考えていますので、よろしくお願いします。 エンジニア・デザイナーブログリニューアルの技術面について さて、ここまでリニューアルの背景をお伝えしましたが、ここからは今回使った技術面について軽く触れていこうと思います。 使用技術について 旧ブログは「はてなブログ」での運用をしていました。リニューアルにあたって上記の課題を解決するためには、独自にブログを開発したほうがよいと考えました。新ブログは以下の技術を使って開発しました。 Gatsby Emotion TypeScript Netlify Gatsby に決めた理由は大きくは以下でした。 既に弊社内で Gatsby の導入実績があるため、社内のメンバーがいざとなったら触れる ブログ + α のサイトを作るのに十分な柔軟性がある 公式やコミュニティプラグインが充実しており、開発が省力化できる Gatsby は精力的にアップデートが行なわれており、早いサイクルで進化するのも魅力の 1 つでした。 Gatsby 製サイトをどのように公開するかは、悩んだのですが、結果的に事例も多くありデプロイの簡易さや機能の豊富さを考えて Netlify にしました。 はてなブログからの記事移行について 最初から旧ブログでのコンテンツは新ブログに移行することがマストだったので、まずはどのように移行ができるかということを考慮することから始めました。はてなブログは通常のエクスポートだと Movable Type 方式になるので、なんとか Markdown に変換するか…などと考えていました。 しかし、 blogsync というはてなブログの CLI クライアントを通すとローカルに Markdown ファイルとしてブログエントリを同期することが可能だったため、 blogsync で全ての旧ブログコンテンツをローカルに同期(ダウンロード) ローカルに Markdown ファイルとしてダウンロードできたブログコンテンツを Gatsby 製の新ブログにコピー gatsby-source-filesystem でコピーした Markdown ファイルを読み込みブログとして表示 という手順で既存のブログ記事を全て移行することができました。 また、ドメインについては独自ドメインをそのまま新ブログにも移行することとしたため、はてなブログと同じ URL 形式でブログが読み込めるようにルーティングをしました。 苦労した部分 今回の開発で苦労した部分をダイジェストで書いていきます。自分のニーズに合わせて調べてみても、特に深い部分に関して、あまり情報が出てこないというパターンが多かったように思います。 バージョン固有の情報や、プラグインの情報が少なかった 開発当初は Gatsby v4 が出たばかりだったので、何かに困って検索しても公式以外の情報は以前のバージョンで使えないことが多かったです。 またプラグイン関係の情報も調べる内容によっては中々目的の情報が出てこなかったりしました。 gatsby-plugin-image 周りで顕著な印象だったので、画像周りの表示に泣かされることがありました。 他にも Markdown 表示は gatsby-plugin-mdx を使用していますが、従来の gatsby-transformer-remark と情報が混在している印象がありましたので混乱することも。 ページネーションでベストなプラグインが見つからなかった 公式 ガイドを参考にページネーションを自前で作っていたのですが、 GraphQL から持ってきたデータを表示するだけではあまりユーザビリティが良くなかったため、プラグインなど探したのですがこれといったものが見つからなかったです。 公式ガイド参考に作ると延々記事が増えたらページネーションの数も増えていってしまい微妙な感じでした…。自前で制御も考えましたが、最終的には mui/pagination コンポーネントを組み合わせることで対応しました。 OGP 画像自動生成に関して情報が少ない OGP 画像は自動生成にしたいと思いましたが、案外ニーズが無いのか情報が少なかった印象です。最終的に こちら のブログを発見し、 kentaro-m/catchy-image を使って生成するようにしました。 これからやりたいこと 機能の拡充以外だと、今まではできなかった textlint での校正などをして、編集時の負荷軽減などをやっていきたいと考えています。 さいごに 以上、 Developer Portal のリニューアルについて書かせていただきました。 引き続き、情報発信などをしていきメドレー開発組織について、皆さんに知っていただければと思います。 最後になりますが、医療ヘルスケアのプロダクト開発に(このようなブログ製作も)関わっていきたい!という方はぜひ下記よりご応募お待ちしております! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに 皆さん、こんにちは。エンジニア・技術広報の平木です。 以前からご覧になっていただいていた方にはお分かりかと思いますが、3/18 に今ご覧いただいているエンジニア・デザイナーブログを「Developer Portal」という名称に変更して 2017 年以来 5 年ぶりにリニューアルをしました。今回はリニューアルについて、目指すところと若干の技術的な側面をお伝えできればと思います。 ブログトップ新旧比較 旧 新 エンジニア・デザイナーブログリニューアルの背景 まずは、 なぜリニューアルしたか? という背景についてです。弊社のエンジニア・デザイナーブログの変遷と共にお話していきたいと思います。 エンジニア・デザイナーブログの変遷 第 1 期(2016/04 ~ 2017/07) Developer Blog は 2016/04 月に会社公式ブログにエンジニア向けの記事を掲載し始めたころから、しばらくは他の会社情報とともに掲載をしていました。記事内容はエンジニアが登壇したイベント情報や、今も続いている TechLunch(全社横断のエンジニア・デザイナー向け社内勉強会) の発表レポートなどがメインとなっていました。 この頃は開発組織の人数もそこまで多くなかったのですが、メドレーの開発組織を社内の様々な部署の雰囲気と共にお伝えしようという目的がメインでした。まずは、メドレーの開発組織としてのプレゼンスを高め、プロダクトを内製で日々開発をしていることを、外部の皆さんに知ってもらおうという目的が一番大きかったように思います。 このような形で 2017 年中頃までは会社公式ブログでの更新をしていましたが、開発組織が拡大するにつれ、組織として出来ることも増えてきました。それに伴い、これまでのように「開発組織の存在のアピール」や「組織の取り組み」に加えて、純粋に技術的な側面をもっと打ち出していき「医療 x IT」というテーマにメドレーはどのように向きあっているかを知ってもらおうという機運が高まってきました。 第 2 期(2017/07 ~ 2022/03) こうした運びで新しく Medley Developer Blog を 2017/07 月に立ち上げることになりました。会社公式ブログから完全に独立したテックブログということで、目論見通りにそれまで以上に技術的な投稿もできるようになりました。編集方式もこの時から現在までエンジニア・デザイナーが主体となっています。 更新頻度も不定期だったものを月 1~2 回と増やし、コンスタントにメドレーの開発に関する話題を取り扱うようにしました。運営をしていた 5 年の間にいくつかの記事は、おかげさまではてなブックマークなどで 話題 になることもあり、第 1 期よりもさらに皆さんに読んでいただけるようなブログになりました。 この間にメドレーも様々なエンジニア・デザイナーイベントにスポンサードさせていただいたりもして、ブログと合わせて一定のプレゼンスを得ることができてきたのではないかと思っています。特に「医療ヘルスケア業界」という馴染みが無い方にはハードルが高いと思われることが多い業界でのプロダクト開発に、一般的なインターネットテクノロジーを駆使しているという点を、色々な側面からお伝えできるようになったことは大きいと感じています。 現在(2022/03 ~) そんなブログでしたが、開設から 5 年経ち以下のような課題が出てきました。 会社がまだ上場前に作られたデザインだったため、現在のコーポレートサイトなどのトーンとズレが出てきている 会社や組織規模が大きくなり、希薄になりがちな内部で働いている個人にもフォーカスが当てられるようなコンテンツが欲しい 採用的な側面として、メドレーに興味を持った方へ提供できる情報がバラバラになっている 以上の課題を解決するために、ブログのリニューアルをすることになりました。 特に今年から全社的な方針として、メドレーのソフト面での話題にフォーカスしたコンテンツを作っていくということで、改めて公式 note の更新に注力していることもあり、エンジニア・デザイナーブログもこの動きと連動する必要がありました。 以上の理由から、コンテンツとしては従来通りの ブログ記事 、様々なメディアでメンバーが露出している インタビュー記事 、イベントなどで使われた 発表スライド を全て見られるような総合的なサイトにしていくこととなりました。 インタビューはこれまでもメンバーが様々なメディアに出ていたり、スライドも以前から Speaker Deck を更新していたのですが、まとまった形での提供ができていませんでした。 今回のリニューアルで、これらの要素をまとめて皆さんにお届けできるようになったため、「Medley Developer Blog」から「Medley Developer Portal」と名称変更をしました。 これからも、メドレーの開発組織をより外部の皆さんに知ってもらうために、運営ができればと考えていますので、よろしくお願いします。 エンジニア・デザイナーブログリニューアルの技術面について さて、ここまでリニューアルの背景をお伝えしましたが、ここからは今回使った技術面について軽く触れていこうと思います。 使用技術について 旧ブログは「はてなブログ」での運用をしていました。リニューアルにあたって上記の課題を解決するためには、独自にブログを開発したほうがよいと考えました。新ブログは以下の技術を使って開発しました。 Gatsby Emotion TypeScript Netlify Gatsby に決めた理由は大きくは以下でした。 既に弊社内で Gatsby の導入実績があるため、社内のメンバーがいざとなったら触れる ブログ + α のサイトを作るのに十分な柔軟性がある 公式やコミュニティプラグインが充実しており、開発が省力化できる Gatsby は精力的にアップデートが行なわれており、早いサイクルで進化するのも魅力の 1 つでした。 Gatsby 製サイトをどのように公開するかは、悩んだのですが、結果的に事例も多くありデプロイの簡易さや機能の豊富さを考えて Netlify にしました。 はてなブログからの記事移行について 最初から旧ブログでのコンテンツは新ブログに移行することがマストだったので、まずはどのように移行ができるかということを考慮することから始めました。はてなブログは通常のエクスポートだと Movable Type 方式になるので、なんとか Markdown に変換するか…などと考えていました。 しかし、 blogsync というはてなブログの CLI クライアントを通すとローカルに Markdown ファイルとしてブログエントリを同期することが可能だったため、 blogsync で全ての旧ブログコンテンツをローカルに同期(ダウンロード) ローカルに Markdown ファイルとしてダウンロードできたブログコンテンツを Gatsby 製の新ブログにコピー gatsby-source-filesystem でコピーした Markdown ファイルを読み込みブログとして表示 という手順で既存のブログ記事を全て移行することができました。 また、ドメインについては独自ドメインをそのまま新ブログにも移行することとしたため、はてなブログと同じ URL 形式でブログが読み込めるようにルーティングをしました。 苦労した部分 今回の開発で苦労した部分をダイジェストで書いていきます。自分のニーズに合わせて調べてみても、特に深い部分に関して、あまり情報が出てこないというパターンが多かったように思います。 バージョン固有の情報や、プラグインの情報が少なかった 開発当初は Gatsby v4 が出たばかりだったので、何かに困って検索しても公式以外の情報は以前のバージョンで使えないことが多かったです。 またプラグイン関係の情報も調べる内容によっては中々目的の情報が出てこなかったりしました。 gatsby-plugin-image 周りで顕著な印象だったので、画像周りの表示に泣かされることがありました。 他にも Markdown 表示は gatsby-plugin-mdx を使用していますが、従来の gatsby-transformer-remark と情報が混在している印象がありましたので混乱することも。 ページネーションでベストなプラグインが見つからなかった 公式 ガイドを参考にページネーションを自前で作っていたのですが、 GraphQL から持ってきたデータを表示するだけではあまりユーザビリティが良くなかったため、プラグインなど探したのですがこれといったものが見つからなかったです。 公式ガイド参考に作ると延々記事が増えたらページネーションの数も増えていってしまい微妙な感じでした…。自前で制御も考えましたが、最終的には mui/pagination コンポーネントを組み合わせることで対応しました。 OGP 画像自動生成に関して情報が少ない OGP 画像は自動生成にしたいと思いましたが、案外ニーズが無いのか情報が少なかった印象です。最終的に こちら のブログを発見し、 kentaro-m/catchy-image を使って生成するようにしました。 これからやりたいこと 機能の拡充以外だと、今まではできなかった textlint での校正などをして、編集時の負荷軽減などをやっていきたいと考えています。 さいごに 以上、 Developer Portal のリニューアルについて書かせていただきました。 引き続き、情報発信などをしていきメドレー開発組織について、皆さんに知っていただければと思います。 最後になりますが、医療ヘルスケアのプロダクト開発に(このようなブログ製作も)関わっていきたい!という方はぜひ下記よりご応募お待ちしております! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに 皆さん、こんにちは。エンジニア・技術広報の平木です。 以前からご覧になっていただいていた方にはお分かりかと思いますが、3/18 に今ご覧いただいているエンジニア・デザイナーブログを「Developer Portal」という名称に変更して 2017 年以来 5 年ぶりにリニューアルをしました。今回はリニューアルについて、目指すところと若干の技術的な側面をお伝えできればと思います。 ブログトップ新旧比較 旧 新 エンジニア・デザイナーブログリニューアルの背景 まずは、 なぜリニューアルしたか? という背景についてです。弊社のエンジニア・デザイナーブログの変遷と共にお話していきたいと思います。 エンジニア・デザイナーブログの変遷 第 1 期(2016/04 ~ 2017/07) Developer Blog は 2016/04 月に会社公式ブログにエンジニア向けの記事を掲載し始めたころから、しばらくは他の会社情報とともに掲載をしていました。記事内容はエンジニアが登壇したイベント情報や、今も続いている TechLunch(全社横断のエンジニア・デザイナー向け社内勉強会) の発表レポートなどがメインとなっていました。 この頃は開発組織の人数もそこまで多くなかったのですが、メドレーの開発組織を社内の様々な部署の雰囲気と共にお伝えしようという目的がメインでした。まずは、メドレーの開発組織としてのプレゼンスを高め、プロダクトを内製で日々開発をしていることを、外部の皆さんに知ってもらおうという目的が一番大きかったように思います。 このような形で 2017 年中頃までは会社公式ブログでの更新をしていましたが、開発組織が拡大するにつれ、組織として出来ることも増えてきました。それに伴い、これまでのように「開発組織の存在のアピール」や「組織の取り組み」に加えて、純粋に技術的な側面をもっと打ち出していき「医療 x IT」というテーマにメドレーはどのように向きあっているかを知ってもらおうという機運が高まってきました。 第 2 期(2017/07 ~ 2022/03) こうした運びで新しく Medley Developer Blog を 2017/07 月に立ち上げることになりました。会社公式ブログから完全に独立したテックブログということで、目論見通りにそれまで以上に技術的な投稿もできるようになりました。編集方式もこの時から現在までエンジニア・デザイナーが主体となっています。 更新頻度も不定期だったものを月 1~2 回と増やし、コンスタントにメドレーの開発に関する話題を取り扱うようにしました。運営をしていた 5 年の間にいくつかの記事は、おかげさまではてなブックマークなどで 話題 になることもあり、第 1 期よりもさらに皆さんに読んでいただけるようなブログになりました。 この間にメドレーも様々なエンジニア・デザイナーイベントにスポンサードさせていただいたりもして、ブログと合わせて一定のプレゼンスを得ることができてきたのではないかと思っています。特に「医療ヘルスケア業界」という馴染みが無い方にはハードルが高いと思われることが多い業界でのプロダクト開発に、一般的なインターネットテクノロジーを駆使しているという点を、色々な側面からお伝えできるようになったことは大きいと感じています。 現在(2022/03 ~) そんなブログでしたが、開設から 5 年経ち以下のような課題が出てきました。 会社がまだ上場前に作られたデザインだったため、現在のコーポレートサイトなどのトーンとズレが出てきている 会社や組織規模が大きくなり、希薄になりがちな内部で働いている個人にもフォーカスが当てられるようなコンテンツが欲しい 採用的な側面として、メドレーに興味を持った方へ提供できる情報がバラバラになっている 以上の課題を解決するために、ブログのリニューアルをすることになりました。 特に今年から全社的な方針として、メドレーのソフト面での話題にフォーカスしたコンテンツを作っていくということで、改めて公式 note の更新に注力していることもあり、エンジニア・デザイナーブログもこの動きと連動する必要がありました。 以上の理由から、コンテンツとしては従来通りの ブログ記事 、様々なメディアでメンバーが露出している インタビュー記事 、イベントなどで使われた 発表スライド を全て見られるような総合的なサイトにしていくこととなりました。 インタビューはこれまでもメンバーが様々なメディアに出ていたり、スライドも以前から Speaker Deck を更新していたのですが、まとまった形での提供ができていませんでした。 今回のリニューアルで、これらの要素をまとめて皆さんにお届けできるようになったため、「Medley Developer Blog」から「Medley Developer Portal」と名称変更をしました。 これからも、メドレーの開発組織をより外部の皆さんに知ってもらうために、運営ができればと考えていますので、よろしくお願いします。 エンジニア・デザイナーブログリニューアルの技術面について さて、ここまでリニューアルの背景をお伝えしましたが、ここからは今回使った技術面について軽く触れていこうと思います。 使用技術について 旧ブログは「はてなブログ」での運用をしていました。リニューアルにあたって上記の課題を解決するためには、独自にブログを開発したほうがよいと考えました。新ブログは以下の技術を使って開発しました。 Gatsby Emotion TypeScript Netlify Gatsby に決めた理由は大きくは以下でした。 既に弊社内で Gatsby の導入実績があるため、社内のメンバーがいざとなったら触れる ブログ + α のサイトを作るのに十分な柔軟性がある 公式やコミュニティプラグインが充実しており、開発が省力化できる Gatsby は精力的にアップデートが行なわれており、早いサイクルで進化するのも魅力の 1 つでした。 Gatsby 製サイトをどのように公開するかは、悩んだのですが、結果的に事例も多くありデプロイの簡易さや機能の豊富さを考えて Netlify にしました。 はてなブログからの記事移行について 最初から旧ブログでのコンテンツは新ブログに移行することがマストだったので、まずはどのように移行ができるかということを考慮することから始めました。はてなブログは通常のエクスポートだと Movable Type 方式になるので、なんとか Markdown に変換するか…などと考えていました。 しかし、 blogsync というはてなブログの CLI クライアントを通すとローカルに Markdown ファイルとしてブログエントリを同期することが可能だったため、 blogsync で全ての旧ブログコンテンツをローカルに同期(ダウンロード) ローカルに Markdown ファイルとしてダウンロードできたブログコンテンツを Gatsby 製の新ブログにコピー gatsby-source-filesystem でコピーした Markdown ファイルを読み込みブログとして表示 という手順で既存のブログ記事を全て移行することができました。 また、ドメインについては独自ドメインをそのまま新ブログにも移行することとしたため、はてなブログと同じ URL 形式でブログが読み込めるようにルーティングをしました。 苦労した部分 今回の開発で苦労した部分をダイジェストで書いていきます。自分のニーズに合わせて調べてみても、特に深い部分に関して、あまり情報が出てこないというパターンが多かったように思います。 バージョン固有の情報や、プラグインの情報が少なかった 開発当初は Gatsby v4 が出たばかりだったので、何かに困って検索しても公式以外の情報は以前のバージョンで使えないことが多かったです。 またプラグイン関係の情報も調べる内容によっては中々目的の情報が出てこなかったりしました。 gatsby-plugin-image 周りで顕著な印象だったので、画像周りの表示に泣かされることがありました。 他にも Markdown 表示は gatsby-plugin-mdx を使用していますが、従来の gatsby-transformer-remark と情報が混在している印象がありましたので混乱することも。 ページネーションでベストなプラグインが見つからなかった 公式 ガイドを参考にページネーションを自前で作っていたのですが、 GraphQL から持ってきたデータを表示するだけではあまりユーザビリティが良くなかったため、プラグインなど探したのですがこれといったものが見つからなかったです。 公式ガイド参考に作ると延々記事が増えたらページネーションの数も増えていってしまい微妙な感じでした…。自前で制御も考えましたが、最終的には mui/pagination コンポーネントを組み合わせることで対応しました。 OGP 画像自動生成に関して情報が少ない OGP 画像は自動生成にしたいと思いましたが、案外ニーズが無いのか情報が少なかった印象です。最終的に こちら のブログを発見し、 kentaro-m/catchy-image を使って生成するようにしました。 これからやりたいこと 機能の拡充以外だと、今まではできなかった textlint での校正などをして、編集時の負荷軽減などをやっていきたいと考えています。 さいごに 以上、 Developer Portal のリニューアルについて書かせていただきました。 引き続き、情報発信などをしていきメドレー開発組織について、皆さんに知っていただければと思います。 最後になりますが、医療ヘルスケアのプロダクト開発に(このようなブログ製作も)関わっていきたい!という方はぜひ下記よりご応募お待ちしております! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは、医療プラットフォーム本部/プロダクト開発室/第一開発グループ所属の世嘉良です。 メドレーには 2018 年の頭に入社しており、今年で 4 年目になります。 当初はサーバーサイドを中心に開発を担当していたのですが、最近は患者エンゲージメントチームという患者様に提供するサービスを開発するチームで主に iOS の仕事を担当することが多いです。 さて去年の 12 月になりますが、 CLINICS アプリ は UI のフルリニューアル を行いました。 今回はリニューアルの裏話 (iOS について) をしていきたいと思います。 これまでの CLINICS アプリについて 本題を書く前に、CLINICS アプリの歴史を紹介します。 ファーストコミットを見てみると、アプリの開発は 2016 年 2 月ごろからスタートし、ファーストリリースが行われたのが 2016 年 5 月でした。 当初、担当していたエンジニアは iOS の経験が豊富な方はおらず、全員で試行錯誤しながら開発を進めていたようです。 しばらくの間は機能の追加などが行われていましたが、 CLINICS カルテ の開発に注力するために大きな開発はストップし、 Pharms との連携が開始される 2020 年 5 月頃まで機能や設計に関する見直しがほとんど行われてきませんでした。 iOS に詳しいエンジニアがいなかったにも関わらず、かなりのスピード感でリリースしていることはさすがの開発力という一言に尽きるのですが、Pharms との連携やお薬手帳といった機能が追加されたり、今後の開発を見据えた際に既存機能や設計の見直しを行いたいと思うようになってきました。 改善したい部分はたくさんあったのですが、対応工数を踏まえ今回のリニューアルでは以下の 2 点の改善に注力することにしました。 Storyboard による View の管理 View とロジックの分離 この 2 点についてそれぞれ詳しく説明します。 1. Storyboard による View の管理 従来の開発では Storyboard を利用して View を作成していました。 Storyboard を使うとレイアウトや画面遷移を簡単に実装することができますが、開発を続けているうちに以下のような問題が目立つようになってきました。 Storyboard が巨大化していき、複数人開発を行う際に支障がでる レイアウトに追加・変更が行われた場合に AutoLayout の再設定に時間がかかる コンポーネント自体にサイズが設定されていることがあり、コンポーネントを再利用できないことがある 課題 こちらは実際にあった Storyboard のキャプチャですが、複数の画面が 1 つの Storyboard 内に詰め込まれた状態となっていました。 Storyboard は Xcode のバージョンにより微妙な差分が発生してしまったり、AutoLayout の調整が必要になる場合があります。 こちらは古い Storyboard の画面を開いた後の差分なのですが、この変更がシステムによって加えられた変更なのか、他人の改修による変更なのかを後から見た時にわかりづらいという問題がありました。 仮に問題が発生した場合は修正を試みるのですが、独自の XML によって表現されているため、iOS の経験が浅い僕にとっては修正が非常に難しかったです。 また、複数人で並行して開発する際にもコンフリクトが起きやすくなってしまい解消に時間がかかるという問題となっていました。 さらに従来の CLINICS アプリは DLS を利用してレイアウトを作成していたのですが、コンポーネントに直接サイズが設定されているものがあり、ある画面では微妙にサイズを調整したい…といった要件に対応できず、せっかくのコンポーネントを再利用できないケースがありました。 解決案 課題に対する解決案は色々と考えられますが、弊社の開発スタイルやエンジニアのスキルを考慮し以下のような方針を立てました。 Storyboard と各画面の実装は 1 : 1 の関係とする 画面遷移の責務も Storyboard から切り離す コンポーネントにアトミックデザインを適用する Storyboard の分割は以下のようなステップで行っていました。 Refactor to Storyboard を使って巨大な Storyboard を分割する SwiftGen を利用し画面生成のコードを自動作成する 2 で生成したものを利用して画面遷移を行う 既存の Segue を削除する まず最初に Xcode 7 から利用可能となった「Refactor to Storyboard」を使って画面を分割するところから始めます。 この機能を利用すると選択した View が新しい Storyboard に切り出され、元の Storyboard には切り出した Storyboard へのリファレンスや Segue 等の接続が保持された状態になります。 次に各画面間の遷移を Segue を使わずに行うようにします。 Segue は便利なのですが、Identifier が単なる文字列であったり、Storyboard を分割してもリファレンスは保持しておく必要がある点が微妙に感じてしまい利用しないことにしました。 Segue を使わずに画面遷移を行う必要があるため、画面生成と画面遷移の方法を自前で実装する必要があります。 今回は画面生成の処理を SwiftGen を利用して自動生成可能にし、VIPER というアーキテクチャの Router を参考にして画面遷移を Storyboard から切り離すことにしました。 ※ SwiftGen の利用方法は SwiftGen#interface-builder を参照ください。 Router の実装は以下の通りです。 実装されたプロトコルを遷移元の VC に継承し、画面遷移のコードを呼び出すだけで画面遷移を行うことができます。 protocol ClinicWireframe : AnyObject { var viewController: UIViewController { get } func presentClinic ( clinicId : String ) func pushClinic ( clinicId : String ) } extension ClinicWireframe { func presentClinic ( clinicId : String ) { let vc = StoryboardScene. Clinic . initialScene . instantiate { ClinicViewController ( coder : $0 , isHeaderEnabled : true ) } let presenter = ClinicPresenter ( view : vc) presenter. setClinicId ( clinicId : clinicId) vc. inject ( presenter : presenter) vc. modalPresentationStyle = . pageSheet let nc = UINavigationController ( rootViewController : vc) viewController. present (nc, animated : true ) } func pushClinic ( clinicId : String ) { let vc = StoryboardScene. Clinic . initialScene . instantiate { ClinicViewController ( coder : $0 , isHeaderEnabled : false ) } let presenter = ClinicPresenter ( view : vc) presenter. setClinicId ( clinicId : clinicId) vc. inject ( presenter : presenter) viewController. navigationController ?. pushViewController (vc, animated : true ) } 最後にコンポーネントの調整についてですが、CLINICS アプリではアトミックデザインを簡略化し、以下のような基準でコンポーネントを実装しています。 Block: UI の最小単位 (他の PJT にも持ち込めそうなレベルまで分解されたもの) Partial: CLINICS の PJT 固有のコンポーネント Layout: ヘルプ用のモーダルやエラー画面など他の画面から呼び出されることで初めて意味をなす画面など Page: 各 ViewController とそれに紐づく Storyboard この管理方法自体は 弊社の別プロダクトの開発を担当しているエンジニアによって考案されたものです。 弊社ではサーバー・フロント分け隔てなく開発を任されることも多く、厳密なアトミックデザインだとコンポーネントの分類に困ることが多かったためこのような管理方法をとっているそうです。 今回のリニューアルに際して CLINICS アプリでもこれを参考にすることにしました。 これまで DLS として管理されていたコンポーネントは Block で実装しなおし、Width / Height といったサイズの設定を行わないようにしました。 このようにコンポーネントの実装レベルを明確にしたことで、実装に一定の指針が生まれ使い回しの効くコンポーネントを作成しやすくなりました。 2. View とロジックの分離 スピード開発が求められた背景を考えると仕方のないことではあるのですが、従来の CLINICS アプリでは ViewController にロジックが記述されており、俗にいう Fat ViewController の状態になってしまっていました。 Fat ViewController の問題点については既にさまざまな方が取り上げていますが、以下の部分が問題と感じています。 UI とロジックが分離されていないため、テストを書くことが難しい 可読性が低くなりがち ロジックが切り出されていないため似たような実装が点在する場合がある 課題 こちらは実際にあった ViewController の一部です。 このコードに関しては以下の部分が問題と感じていました。 通信処理の呼び出しが ViewController の責務になっていること 通信結果を整形するロジックが ViewController の責務になっていること 画面描画のための State 管理が ViewController の責務になっていること 解決案 UI とロジックを分離するための手法はさまざまなものがありますが、弊社のアプリには以下のような特徴があります。 iOS 以外にも複数のプラットフォームをサポートしているためフロントエンドで保持するデータや複雑なロジック自体は少ない (サーバー側でなるべく担保している) 実装時や QA 時に感じた違和感について細かくディレクターと打ち合わせし、その結果次第では仕様を変更することがある これらを考慮すると、プロジェクトの期間的に初期の導入コストが低く、データフローがシンプルなものに留めたいというように考えがまとまってきました。 これらを考慮し、CLINICS アプリでは MVP というアーキテクチャを採用することにしました。 より詳細には MVP の Passive View 方式を採用しており、以下のような形で実装しています。 View は基本的にすべての入力イベントに対応した Presenter の処理を呼び出す Presenter は入力に応じて通信処理などの外部要因となる処理を呼び出し、結果を整形する プレゼンテーションロジックの結果を描画するように View に指示を出す View は Presenter の指示によってのみ描画処理を行い、自身を起点とした描画処理は行わない Model–view–presenter - Wikipedia 既に Router は導入してるため、複雑な処理フローを実装したい場合は Interactor を導入するだけで VIPER アーキテクチャへと発展させることが簡単にできる点も魅力でした。 CLINICS アプリでの ViewController / Presenter の実装を簡単にまとめたものは以下のようになっています。 final class ClinicViewController : UIViewController { private lazy var presenter: ClinicPresenterInput = { fatalError (“Failed to inject presenter”) }() override func viewDidLoad () { super . viewDidLoad () presenter?. refresh () } func inject ( presenter : ClinicPresenterInput) { self . presenter = presenter } // タップされた際に呼び出す func onTapServiceCell ( _ service : ServiceEntity, isTelemedicine : Bool ) { presenter?. didTapServiceButton (service, isTelemedicine : isTelemedicine) } } // MARK: - ClinicPresenterOutput extension ClinicViewController : ClinicPresenterOutput { func reloadData ( clinic : ClinicEntity?) { clinicViewStore. clinic = clinic } func openCreateAppointmentView ( clinic : ClinicEntity, service : ServiceEntity, isTelemedicine : Bool ) // 予約へ進む } func showErrorAlert ( _ error : Error ) { // エラー表示を行う } } protocol ClinicPresenterInput : AnyObject { func refresh () func didTapServiceButton ( _ service : ServiceEntity, isTelemedicine : Bool ) } protocol ClinicPresenterOutput : AnyObject { func reloadData ( clinic : ClinicEntity?) func openCreateAppointmentView ( clinic : ClinicEntity, service : ServiceEntity, isTelemedicine : Bool ) func showErrorAlert ( _ error : Error ) } final class ClinicPresenter { private let clinicRepository: ClinicRepository private var clinic: ClinicEntity? private var cancellables: Set <AnyCancellable> = . init () init ( view : ClinicPresenterOutput, container : DIContainer) { self . view = view clinicRepository = container. resolve () } private func reloadView () { view?. reloadData ( clinic : clinic) } } // MARK: - PresenterInput extension ClinicPresenter : ClinicPresenterInput { func refresh () { guard let clinicId = clinicId else { return } clinicRepository. getClinic ( clinicId : clinicId) . sink ( receiveCompletion : { [ weak self ] completion in guard let self = self else { return } guard case let . failure (error) = completion else { return } self . view ?. showErrorAlert (error) } }, receiveValue : { [ weak self ] response in guard let self = self else { return } self . clinic = response. data self . reloadView () } ) . store ( in : &cancellables) } func didTapServiceButton ( _ service : ClinicsServiceEntity, isTelemedicine : Bool ) { guard let clinic = clinic else { return } view?. openCreateAppointmentView ( clinic : clinic, service : service, isTelemedicine : isTelemedicine) } } ViewController と Presenter は以下のように Router の内部で DI するようにしています。 protocol ClinicWireframe : AnyObject { var viewController: UIViewController { get } func pushClinic ( clinicId : String ) } extension ClinicWireframe { func pushClinic ( clinicId : String ) { let vc = StoryboardScene. Clinic . initialScene . instantiate { ClinicViewController ( coder : $0 , isHeaderEnabled : false ) } let presenter = ClinicPresenter ( view : vc, container : DIContainer ()) presenter. setClinicId ( clinicId : clinicId) vc. inject ( presenter : presenter) viewController. navigationController ?. pushViewController (vc, animated : true ) } } これによって、もともと ViewController にあった処理は以下のように分離されました。 また、View と Presenter はインターフェースを介してしかお互いを知らないため、実装の交換が簡単にできるようになりました。 Presenter を交換することで 1 つの View で別々の処理を表現することが可能となったり、View をテストコードを交換することで Presenter の入出力値をテストすることができるようになっています。 まとめ CLINICS アプリは歴史のあるプロジェクトですが、今回のプロジェクトを通して UI だけでなく裏側の実装も刷新しています。 巨大な Storyboard を分解したことでメンテナビリティが向上し、MVP (+ Router) の導入によって View とロジックの交換が簡単になり、テストなどの実装を取り入れやすくなりました。 さいごに ブログの本編には書けなかったのですが、今回リニューアルされた画面に関しては SwiftUI を利用してフルスクラッチで実装していたり、 Asset の管理方法についても大きな見直しを行いました。 またアーキテクチャの選定にあたり、「 iOS アプリ設計パターン入門 」が大変参考になりました。iOS の開発を行う方はぜひ一読してほしいと思います。 約半年ほどかかった大きなプロジェクトでしたが、患者エンゲージメントチームのメンバー全員で取り組み無事にリリースまで漕ぎ着けることができました。まだまだ手探りな部分もありますが、今後も患者さんにとってより安心して使えるサービスとなるように開発を続けていければと思っています。 長くなりましたが、最後までお読みいただきありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは、医療プラットフォーム本部/プロダクト開発室/第一開発グループ所属の世嘉良です。 メドレーには 2018 年の頭に入社しており、今年で 4 年目になります。 当初はサーバーサイドを中心に開発を担当していたのですが、最近は患者エンゲージメントチームという患者様に提供するサービスを開発するチームで主に iOS の仕事を担当することが多いです。 さて去年の 12 月になりますが、 CLINICS アプリ は UI のフルリニューアル を行いました。 今回はリニューアルの裏話 (iOS について) をしていきたいと思います。 これまでの CLINICS アプリについて 本題を書く前に、CLINICS アプリの歴史を紹介します。 ファーストコミットを見てみると、アプリの開発は 2016 年 2 月ごろからスタートし、ファーストリリースが行われたのが 2016 年 5 月でした。 当初、担当していたエンジニアは iOS の経験が豊富な方はおらず、全員で試行錯誤しながら開発を進めていたようです。 しばらくの間は機能の追加などが行われていましたが、 CLINICS カルテ の開発に注力するために大きな開発はストップし、 Pharms との連携が開始される 2020 年 5 月頃まで機能や設計に関する見直しがほとんど行われてきませんでした。 iOS に詳しいエンジニアがいなかったにも関わらず、かなりのスピード感でリリースしていることはさすがの開発力という一言に尽きるのですが、Pharms との連携やお薬手帳といった機能が追加されたり、今後の開発を見据えた際に既存機能や設計の見直しを行いたいと思うようになってきました。 改善したい部分はたくさんあったのですが、対応工数を踏まえ今回のリニューアルでは以下の 2 点の改善に注力することにしました。 Storyboard による View の管理 View とロジックの分離 この 2 点についてそれぞれ詳しく説明します。 1. Storyboard による View の管理 従来の開発では Storyboard を利用して View を作成していました。 Storyboard を使うとレイアウトや画面遷移を簡単に実装することができますが、開発を続けているうちに以下のような問題が目立つようになってきました。 Storyboard が巨大化していき、複数人開発を行う際に支障がでる レイアウトに追加・変更が行われた場合に AutoLayout の再設定に時間がかかる コンポーネント自体にサイズが設定されていることがあり、コンポーネントを再利用できないことがある 課題 こちらは実際にあった Storyboard のキャプチャですが、複数の画面が 1 つの Storyboard 内に詰め込まれた状態となっていました。 Storyboard は Xcode のバージョンにより微妙な差分が発生してしまったり、AutoLayout の調整が必要になる場合があります。 こちらは古い Storyboard の画面を開いた後の差分なのですが、この変更がシステムによって加えられた変更なのか、他人の改修による変更なのかを後から見た時にわかりづらいという問題がありました。 仮に問題が発生した場合は修正を試みるのですが、独自の XML によって表現されているため、iOS の経験が浅い僕にとっては修正が非常に難しかったです。 また、複数人で並行して開発する際にもコンフリクトが起きやすくなってしまい解消に時間がかかるという問題となっていました。 さらに従来の CLINICS アプリは DLS を利用してレイアウトを作成していたのですが、コンポーネントに直接サイズが設定されているものがあり、ある画面では微妙にサイズを調整したい…といった要件に対応できず、せっかくのコンポーネントを再利用できないケースがありました。 解決案 課題に対する解決案は色々と考えられますが、弊社の開発スタイルやエンジニアのスキルを考慮し以下のような方針を立てました。 Storyboard と各画面の実装は 1 : 1 の関係とする 画面遷移の責務も Storyboard から切り離す コンポーネントにアトミックデザインを適用する Storyboard の分割は以下のようなステップで行っていました。 Refactor to Storyboard を使って巨大な Storyboard を分割する SwiftGen を利用し画面生成のコードを自動作成する 2 で生成したものを利用して画面遷移を行う 既存の Segue を削除する まず最初に Xcode 7 から利用可能となった「Refactor to Storyboard」を使って画面を分割するところから始めます。 この機能を利用すると選択した View が新しい Storyboard に切り出され、元の Storyboard には切り出した Storyboard へのリファレンスや Segue 等の接続が保持された状態になります。 次に各画面間の遷移を Segue を使わずに行うようにします。 Segue は便利なのですが、Identifier が単なる文字列であったり、Storyboard を分割してもリファレンスは保持しておく必要がある点が微妙に感じてしまい利用しないことにしました。 Segue を使わずに画面遷移を行う必要があるため、画面生成と画面遷移の方法を自前で実装する必要があります。 今回は画面生成の処理を SwiftGen を利用して自動生成可能にし、VIPER というアーキテクチャの Router を参考にして画面遷移を Storyboard から切り離すことにしました。 ※ SwiftGen の利用方法は SwiftGen#interface-builder を参照ください。 Router の実装は以下の通りです。 実装されたプロトコルを遷移元の VC に継承し、画面遷移のコードを呼び出すだけで画面遷移を行うことができます。 protocol ClinicWireframe : AnyObject { var viewController: UIViewController { get } func presentClinic ( clinicId : String ) func pushClinic ( clinicId : String ) } extension ClinicWireframe { func presentClinic ( clinicId : String ) { let vc = StoryboardScene. Clinic . initialScene . instantiate { ClinicViewController ( coder : $0 , isHeaderEnabled : true ) } let presenter = ClinicPresenter ( view : vc) presenter. setClinicId ( clinicId : clinicId) vc. inject ( presenter : presenter) vc. modalPresentationStyle = . pageSheet let nc = UINavigationController ( rootViewController : vc) viewController. present (nc, animated : true ) } func pushClinic ( clinicId : String ) { let vc = StoryboardScene. Clinic . initialScene . instantiate { ClinicViewController ( coder : $0 , isHeaderEnabled : false ) } let presenter = ClinicPresenter ( view : vc) presenter. setClinicId ( clinicId : clinicId) vc. inject ( presenter : presenter) viewController. navigationController ?. pushViewController (vc, animated : true ) } 最後にコンポーネントの調整についてですが、CLINICS アプリではアトミックデザインを簡略化し、以下のような基準でコンポーネントを実装しています。 Block: UI の最小単位 (他の PJT にも持ち込めそうなレベルまで分解されたもの) Partial: CLINICS の PJT 固有のコンポーネント Layout: ヘルプ用のモーダルやエラー画面など他の画面から呼び出されることで初めて意味をなす画面など Page: 各 ViewController とそれに紐づく Storyboard この管理方法自体は 弊社の別プロダクトの開発を担当しているエンジニアによって考案されたものです。 弊社ではサーバー・フロント分け隔てなく開発を任されることも多く、厳密なアトミックデザインだとコンポーネントの分類に困ることが多かったためこのような管理方法をとっているそうです。 今回のリニューアルに際して CLINICS アプリでもこれを参考にすることにしました。 これまで DLS として管理されていたコンポーネントは Block で実装しなおし、Width / Height といったサイズの設定を行わないようにしました。 このようにコンポーネントの実装レベルを明確にしたことで、実装に一定の指針が生まれ使い回しの効くコンポーネントを作成しやすくなりました。 2. View とロジックの分離 スピード開発が求められた背景を考えると仕方のないことではあるのですが、従来の CLINICS アプリでは ViewController にロジックが記述されており、俗にいう Fat ViewController の状態になってしまっていました。 Fat ViewController の問題点については既にさまざまな方が取り上げていますが、以下の部分が問題と感じています。 UI とロジックが分離されていないため、テストを書くことが難しい 可読性が低くなりがち ロジックが切り出されていないため似たような実装が点在する場合がある 課題 こちらは実際にあった ViewController の一部です。 このコードに関しては以下の部分が問題と感じていました。 通信処理の呼び出しが ViewController の責務になっていること 通信結果を整形するロジックが ViewController の責務になっていること 画面描画のための State 管理が ViewController の責務になっていること 解決案 UI とロジックを分離するための手法はさまざまなものがありますが、弊社のアプリには以下のような特徴があります。 iOS 以外にも複数のプラットフォームをサポートしているためフロントエンドで保持するデータや複雑なロジック自体は少ない (サーバー側でなるべく担保している) 実装時や QA 時に感じた違和感について細かくディレクターと打ち合わせし、その結果次第では仕様を変更することがある これらを考慮すると、プロジェクトの期間的に初期の導入コストが低く、データフローがシンプルなものに留めたいというように考えがまとまってきました。 これらを考慮し、CLINICS アプリでは MVP というアーキテクチャを採用することにしました。 より詳細には MVP の Passive View 方式を採用しており、以下のような形で実装しています。 View は基本的にすべての入力イベントに対応した Presenter の処理を呼び出す Presenter は入力に応じて通信処理などの外部要因となる処理を呼び出し、結果を整形する プレゼンテーションロジックの結果を描画するように View に指示を出す View は Presenter の指示によってのみ描画処理を行い、自身を起点とした描画処理は行わない Model–view–presenter - Wikipedia 既に Router は導入してるため、複雑な処理フローを実装したい場合は Interactor を導入するだけで VIPER アーキテクチャへと発展させることが簡単にできる点も魅力でした。 CLINICS アプリでの ViewController / Presenter の実装を簡単にまとめたものは以下のようになっています。 final class ClinicViewController : UIViewController { private lazy var presenter: ClinicPresenterInput = { fatalError (“Failed to inject presenter”) }() override func viewDidLoad () { super . viewDidLoad () presenter?. refresh () } func inject ( presenter : ClinicPresenterInput) { self . presenter = presenter } // タップされた際に呼び出す func onTapServiceCell ( _ service : ServiceEntity, isTelemedicine : Bool ) { presenter?. didTapServiceButton (service, isTelemedicine : isTelemedicine) } } // MARK: - ClinicPresenterOutput extension ClinicViewController : ClinicPresenterOutput { func reloadData ( clinic : ClinicEntity?) { clinicViewStore. clinic = clinic } func openCreateAppointmentView ( clinic : ClinicEntity, service : ServiceEntity, isTelemedicine : Bool ) // 予約へ進む } func showErrorAlert ( _ error : Error ) { // エラー表示を行う } } protocol ClinicPresenterInput : AnyObject { func refresh () func didTapServiceButton ( _ service : ServiceEntity, isTelemedicine : Bool ) } protocol ClinicPresenterOutput : AnyObject { func reloadData ( clinic : ClinicEntity?) func openCreateAppointmentView ( clinic : ClinicEntity, service : ServiceEntity, isTelemedicine : Bool ) func showErrorAlert ( _ error : Error ) } final class ClinicPresenter { private let clinicRepository: ClinicRepository private var clinic: ClinicEntity? private var cancellables: Set <AnyCancellable> = . init () init ( view : ClinicPresenterOutput, container : DIContainer) { self . view = view clinicRepository = container. resolve () } private func reloadView () { view?. reloadData ( clinic : clinic) } } // MARK: - PresenterInput extension ClinicPresenter : ClinicPresenterInput { func refresh () { guard let clinicId = clinicId else { return } clinicRepository. getClinic ( clinicId : clinicId) . sink ( receiveCompletion : { [ weak self ] completion in guard let self = self else { return } guard case let . failure (error) = completion else { return } self . view ?. showErrorAlert (error) } }, receiveValue : { [ weak self ] response in guard let self = self else { return } self . clinic = response. data self . reloadView () } ) . store ( in : &cancellables) } func didTapServiceButton ( _ service : ClinicsServiceEntity, isTelemedicine : Bool ) { guard let clinic = clinic else { return } view?. openCreateAppointmentView ( clinic : clinic, service : service, isTelemedicine : isTelemedicine) } } ViewController と Presenter は以下のように Router の内部で DI するようにしています。 protocol ClinicWireframe : AnyObject { var viewController: UIViewController { get } func pushClinic ( clinicId : String ) } extension ClinicWireframe { func pushClinic ( clinicId : String ) { let vc = StoryboardScene. Clinic . initialScene . instantiate { ClinicViewController ( coder : $0 , isHeaderEnabled : false ) } let presenter = ClinicPresenter ( view : vc, container : DIContainer ()) presenter. setClinicId ( clinicId : clinicId) vc. inject ( presenter : presenter) viewController. navigationController ?. pushViewController (vc, animated : true ) } } これによって、もともと ViewController にあった処理は以下のように分離されました。 また、View と Presenter はインターフェースを介してしかお互いを知らないため、実装の交換が簡単にできるようになりました。 Presenter を交換することで 1 つの View で別々の処理を表現することが可能となったり、View をテストコードを交換することで Presenter の入出力値をテストすることができるようになっています。 まとめ CLINICS アプリは歴史のあるプロジェクトですが、今回のプロジェクトを通して UI だけでなく裏側の実装も刷新しています。 巨大な Storyboard を分解したことでメンテナビリティが向上し、MVP (+ Router) の導入によって View とロジックの交換が簡単になり、テストなどの実装を取り入れやすくなりました。 さいごに ブログの本編には書けなかったのですが、今回リニューアルされた画面に関しては SwiftUI を利用してフルスクラッチで実装していたり、 Asset の管理方法についても大きな見直しを行いました。 またアーキテクチャの選定にあたり、「 iOS アプリ設計パターン入門 」が大変参考になりました。iOS の開発を行う方はぜひ一読してほしいと思います。 約半年ほどかかった大きなプロジェクトでしたが、患者エンゲージメントチームのメンバー全員で取り組み無事にリリースまで漕ぎ着けることができました。まだまだ手探りな部分もありますが、今後も患者さんにとってより安心して使えるサービスとなるように開発を続けていければと思っています。 長くなりましたが、最後までお読みいただきありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは、医療プラットフォーム本部/プロダクト開発室/第一開発グループ所属の世嘉良です。 メドレーには 2018 年の頭に入社しており、今年で 4 年目になります。 当初はサーバーサイドを中心に開発を担当していたのですが、最近は患者エンゲージメントチームという患者様に提供するサービスを開発するチームで主に iOS の仕事を担当することが多いです。 さて去年の 12 月になりますが、 CLINICS アプリ は UI のフルリニューアル を行いました。 今回はリニューアルの裏話 (iOS について) をしていきたいと思います。 これまでの CLINICS アプリについて 本題を書く前に、CLINICS アプリの歴史を紹介します。 ファーストコミットを見てみると、アプリの開発は 2016 年 2 月ごろからスタートし、ファーストリリースが行われたのが 2016 年 5 月でした。 当初、担当していたエンジニアは iOS の経験が豊富な方はおらず、全員で試行錯誤しながら開発を進めていたようです。 しばらくの間は機能の追加などが行われていましたが、 CLINICS カルテ の開発に注力するために大きな開発はストップし、 Pharms との連携が開始される 2020 年 5 月頃まで機能や設計に関する見直しがほとんど行われてきませんでした。 iOS に詳しいエンジニアがいなかったにも関わらず、かなりのスピード感でリリースしていることはさすがの開発力という一言に尽きるのですが、Pharms との連携やお薬手帳といった機能が追加されたり、今後の開発を見据えた際に既存機能や設計の見直しを行いたいと思うようになってきました。 改善したい部分はたくさんあったのですが、対応工数を踏まえ今回のリニューアルでは以下の 2 点の改善に注力することにしました。 Storyboard による View の管理 View とロジックの分離 この 2 点についてそれぞれ詳しく説明します。 1. Storyboard による View の管理 従来の開発では Storyboard を利用して View を作成していました。 Storyboard を使うとレイアウトや画面遷移を簡単に実装することができますが、開発を続けているうちに以下のような問題が目立つようになってきました。 Storyboard が巨大化していき、複数人開発を行う際に支障がでる レイアウトに追加・変更が行われた場合に AutoLayout の再設定に時間がかかる コンポーネント自体にサイズが設定されていることがあり、コンポーネントを再利用できないことがある 課題 こちらは実際にあった Storyboard のキャプチャですが、複数の画面が 1 つの Storyboard 内に詰め込まれた状態となっていました。 Storyboard は Xcode のバージョンにより微妙な差分が発生してしまったり、AutoLayout の調整が必要になる場合があります。 こちらは古い Storyboard の画面を開いた後の差分なのですが、この変更がシステムによって加えられた変更なのか、他人の改修による変更なのかを後から見た時にわかりづらいという問題がありました。 仮に問題が発生した場合は修正を試みるのですが、独自の XML によって表現されているため、iOS の経験が浅い僕にとっては修正が非常に難しかったです。 また、複数人で並行して開発する際にもコンフリクトが起きやすくなってしまい解消に時間がかかるという問題となっていました。 さらに従来の CLINICS アプリは DLS を利用してレイアウトを作成していたのですが、コンポーネントに直接サイズが設定されているものがあり、ある画面では微妙にサイズを調整したい…といった要件に対応できず、せっかくのコンポーネントを再利用できないケースがありました。 解決案 課題に対する解決案は色々と考えられますが、弊社の開発スタイルやエンジニアのスキルを考慮し以下のような方針を立てました。 Storyboard と各画面の実装は 1 : 1 の関係とする 画面遷移の責務も Storyboard から切り離す コンポーネントにアトミックデザインを適用する Storyboard の分割は以下のようなステップで行っていました。 Refactor to Storyboard を使って巨大な Storyboard を分割する SwiftGen を利用し画面生成のコードを自動作成する 2 で生成したものを利用して画面遷移を行う 既存の Segue を削除する まず最初に Xcode 7 から利用可能となった「Refactor to Storyboard」を使って画面を分割するところから始めます。 この機能を利用すると選択した View が新しい Storyboard に切り出され、元の Storyboard には切り出した Storyboard へのリファレンスや Segue 等の接続が保持された状態になります。 次に各画面間の遷移を Segue を使わずに行うようにします。 Segue は便利なのですが、Identifier が単なる文字列であったり、Storyboard を分割してもリファレンスは保持しておく必要がある点が微妙に感じてしまい利用しないことにしました。 Segue を使わずに画面遷移を行う必要があるため、画面生成と画面遷移の方法を自前で実装する必要があります。 今回は画面生成の処理を SwiftGen を利用して自動生成可能にし、VIPER というアーキテクチャの Router を参考にして画面遷移を Storyboard から切り離すことにしました。 ※ SwiftGen の利用方法は SwiftGen#interface-builder を参照ください。 Router の実装は以下の通りです。 実装されたプロトコルを遷移元の VC に継承し、画面遷移のコードを呼び出すだけで画面遷移を行うことができます。 protocol ClinicWireframe : AnyObject { var viewController: UIViewController { get } func presentClinic ( clinicId : String ) func pushClinic ( clinicId : String ) } extension ClinicWireframe { func presentClinic ( clinicId : String ) { let vc = StoryboardScene. Clinic . initialScene . instantiate { ClinicViewController ( coder : $0 , isHeaderEnabled : true ) } let presenter = ClinicPresenter ( view : vc) presenter. setClinicId ( clinicId : clinicId) vc. inject ( presenter : presenter) vc. modalPresentationStyle = . pageSheet let nc = UINavigationController ( rootViewController : vc) viewController. present (nc, animated : true ) } func pushClinic ( clinicId : String ) { let vc = StoryboardScene. Clinic . initialScene . instantiate { ClinicViewController ( coder : $0 , isHeaderEnabled : false ) } let presenter = ClinicPresenter ( view : vc) presenter. setClinicId ( clinicId : clinicId) vc. inject ( presenter : presenter) viewController. navigationController ?. pushViewController (vc, animated : true ) } 最後にコンポーネントの調整についてですが、CLINICS アプリではアトミックデザインを簡略化し、以下のような基準でコンポーネントを実装しています。 Block: UI の最小単位 (他の PJT にも持ち込めそうなレベルまで分解されたもの) Partial: CLINICS の PJT 固有のコンポーネント Layout: ヘルプ用のモーダルやエラー画面など他の画面から呼び出されることで初めて意味をなす画面など Page: 各 ViewController とそれに紐づく Storyboard この管理方法自体は 弊社の別プロダクトの開発を担当しているエンジニアによって考案されたものです。 弊社ではサーバー・フロント分け隔てなく開発を任されることも多く、厳密なアトミックデザインだとコンポーネントの分類に困ることが多かったためこのような管理方法をとっているそうです。 今回のリニューアルに際して CLINICS アプリでもこれを参考にすることにしました。 これまで DLS として管理されていたコンポーネントは Block で実装しなおし、Width / Height といったサイズの設定を行わないようにしました。 このようにコンポーネントの実装レベルを明確にしたことで、実装に一定の指針が生まれ使い回しの効くコンポーネントを作成しやすくなりました。 2. View とロジックの分離 スピード開発が求められた背景を考えると仕方のないことではあるのですが、従来の CLINICS アプリでは ViewController にロジックが記述されており、俗にいう Fat ViewController の状態になってしまっていました。 Fat ViewController の問題点については既にさまざまな方が取り上げていますが、以下の部分が問題と感じています。 UI とロジックが分離されていないため、テストを書くことが難しい 可読性が低くなりがち ロジックが切り出されていないため似たような実装が点在する場合がある 課題 こちらは実際にあった ViewController の一部です。 このコードに関しては以下の部分が問題と感じていました。 通信処理の呼び出しが ViewController の責務になっていること 通信結果を整形するロジックが ViewController の責務になっていること 画面描画のための State 管理が ViewController の責務になっていること 解決案 UI とロジックを分離するための手法はさまざまなものがありますが、弊社のアプリには以下のような特徴があります。 iOS 以外にも複数のプラットフォームをサポートしているためフロントエンドで保持するデータや複雑なロジック自体は少ない (サーバー側でなるべく担保している) 実装時や QA 時に感じた違和感について細かくディレクターと打ち合わせし、その結果次第では仕様を変更することがある これらを考慮すると、プロジェクトの期間的に初期の導入コストが低く、データフローがシンプルなものに留めたいというように考えがまとまってきました。 これらを考慮し、CLINICS アプリでは MVP というアーキテクチャを採用することにしました。 より詳細には MVP の Passive View 方式を採用しており、以下のような形で実装しています。 View は基本的にすべての入力イベントに対応した Presenter の処理を呼び出す Presenter は入力に応じて通信処理などの外部要因となる処理を呼び出し、結果を整形する プレゼンテーションロジックの結果を描画するように View に指示を出す View は Presenter の指示によってのみ描画処理を行い、自身を起点とした描画処理は行わない Model–view–presenter - Wikipedia 既に Router は導入してるため、複雑な処理フローを実装したい場合は Interactor を導入するだけで VIPER アーキテクチャへと発展させることが簡単にできる点も魅力でした。 CLINICS アプリでの ViewController / Presenter の実装を簡単にまとめたものは以下のようになっています。 final class ClinicViewController : UIViewController { private lazy var presenter: ClinicPresenterInput = { fatalError (“Failed to inject presenter”) }() override func viewDidLoad () { super . viewDidLoad () presenter?. refresh () } func inject ( presenter : ClinicPresenterInput) { self . presenter = presenter } // タップされた際に呼び出す func onTapServiceCell ( _ service : ServiceEntity, isTelemedicine : Bool ) { presenter?. didTapServiceButton (service, isTelemedicine : isTelemedicine) } } // MARK: - ClinicPresenterOutput extension ClinicViewController : ClinicPresenterOutput { func reloadData ( clinic : ClinicEntity?) { clinicViewStore. clinic = clinic } func openCreateAppointmentView ( clinic : ClinicEntity, service : ServiceEntity, isTelemedicine : Bool ) // 予約へ進む } func showErrorAlert ( _ error : Error ) { // エラー表示を行う } } protocol ClinicPresenterInput : AnyObject { func refresh () func didTapServiceButton ( _ service : ServiceEntity, isTelemedicine : Bool ) } protocol ClinicPresenterOutput : AnyObject { func reloadData ( clinic : ClinicEntity?) func openCreateAppointmentView ( clinic : ClinicEntity, service : ServiceEntity, isTelemedicine : Bool ) func showErrorAlert ( _ error : Error ) } final class ClinicPresenter { private let clinicRepository: ClinicRepository private var clinic: ClinicEntity? private var cancellables: Set <AnyCancellable> = . init () init ( view : ClinicPresenterOutput, container : DIContainer) { self . view = view clinicRepository = container. resolve () } private func reloadView () { view?. reloadData ( clinic : clinic) } } // MARK: - PresenterInput extension ClinicPresenter : ClinicPresenterInput { func refresh () { guard let clinicId = clinicId else { return } clinicRepository. getClinic ( clinicId : clinicId) . sink ( receiveCompletion : { [ weak self ] completion in guard let self = self else { return } guard case let . failure (error) = completion else { return } self . view ?. showErrorAlert (error) } }, receiveValue : { [ weak self ] response in guard let self = self else { return } self . clinic = response. data self . reloadView () } ) . store ( in : &cancellables) } func didTapServiceButton ( _ service : ClinicsServiceEntity, isTelemedicine : Bool ) { guard let clinic = clinic else { return } view?. openCreateAppointmentView ( clinic : clinic, service : service, isTelemedicine : isTelemedicine) } } ViewController と Presenter は以下のように Router の内部で DI するようにしています。 protocol ClinicWireframe : AnyObject { var viewController: UIViewController { get } func pushClinic ( clinicId : String ) } extension ClinicWireframe { func pushClinic ( clinicId : String ) { let vc = StoryboardScene. Clinic . initialScene . instantiate { ClinicViewController ( coder : $0 , isHeaderEnabled : false ) } let presenter = ClinicPresenter ( view : vc, container : DIContainer ()) presenter. setClinicId ( clinicId : clinicId) vc. inject ( presenter : presenter) viewController. navigationController ?. pushViewController (vc, animated : true ) } } これによって、もともと ViewController にあった処理は以下のように分離されました。 また、View と Presenter はインターフェースを介してしかお互いを知らないため、実装の交換が簡単にできるようになりました。 Presenter を交換することで 1 つの View で別々の処理を表現することが可能となったり、View をテストコードを交換することで Presenter の入出力値をテストすることができるようになっています。 まとめ CLINICS アプリは歴史のあるプロジェクトですが、今回のプロジェクトを通して UI だけでなく裏側の実装も刷新しています。 巨大な Storyboard を分解したことでメンテナビリティが向上し、MVP (+ Router) の導入によって View とロジックの交換が簡単になり、テストなどの実装を取り入れやすくなりました。 さいごに ブログの本編には書けなかったのですが、今回リニューアルされた画面に関しては SwiftUI を利用してフルスクラッチで実装していたり、 Asset の管理方法についても大きな見直しを行いました。 またアーキテクチャの選定にあたり、「 iOS アプリ設計パターン入門 」が大変参考になりました。iOS の開発を行う方はぜひ一読してほしいと思います。 約半年ほどかかった大きなプロジェクトでしたが、患者エンゲージメントチームのメンバー全員で取り組み無事にリリースまで漕ぎ着けることができました。まだまだ手探りな部分もありますが、今後も患者さんにとってより安心して使えるサービスとなるように開発を続けていければと思っています。 長くなりましたが、最後までお読みいただきありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは、医療プラットフォーム本部/プロダクト開発室/第一開発グループ所属の世嘉良です。 メドレーには 2018 年の頭に入社しており、今年で 4 年目になります。 当初はサーバーサイドを中心に開発を担当していたのですが、最近は患者エンゲージメントチームという患者様に提供するサービスを開発するチームで主に iOS の仕事を担当することが多いです。 さて去年の 12 月になりますが、 CLINICS アプリ は UI のフルリニューアル を行いました。 今回はリニューアルの裏話 (iOS について) をしていきたいと思います。 これまでの CLINICS アプリについて 本題を書く前に、CLINICS アプリの歴史を紹介します。 ファーストコミットを見てみると、アプリの開発は 2016 年 2 月ごろからスタートし、ファーストリリースが行われたのが 2016 年 5 月でした。 当初、担当していたエンジニアは iOS の経験が豊富な方はおらず、全員で試行錯誤しながら開発を進めていたようです。 しばらくの間は機能の追加などが行われていましたが、 CLINICS カルテ の開発に注力するために大きな開発はストップし、 Pharms との連携が開始される 2020 年 5 月頃まで機能や設計に関する見直しがほとんど行われてきませんでした。 iOS に詳しいエンジニアがいなかったにも関わらず、かなりのスピード感でリリースしていることはさすがの開発力という一言に尽きるのですが、Pharms との連携やお薬手帳といった機能が追加されたり、今後の開発を見据えた際に既存機能や設計の見直しを行いたいと思うようになってきました。 改善したい部分はたくさんあったのですが、対応工数を踏まえ今回のリニューアルでは以下の 2 点の改善に注力することにしました。 Storyboard による View の管理 View とロジックの分離 この 2 点についてそれぞれ詳しく説明します。 1. Storyboard による View の管理 従来の開発では Storyboard を利用して View を作成していました。 Storyboard を使うとレイアウトや画面遷移を簡単に実装することができますが、開発を続けているうちに以下のような問題が目立つようになってきました。 Storyboard が巨大化していき、複数人開発を行う際に支障がでる レイアウトに追加・変更が行われた場合に AutoLayout の再設定に時間がかかる コンポーネント自体にサイズが設定されていることがあり、コンポーネントを再利用できないことがある 課題 こちらは実際にあった Storyboard のキャプチャですが、複数の画面が 1 つの Storyboard 内に詰め込まれた状態となっていました。 Storyboard は Xcode のバージョンにより微妙な差分が発生してしまったり、AutoLayout の調整が必要になる場合があります。 こちらは古い Storyboard の画面を開いた後の差分なのですが、この変更がシステムによって加えられた変更なのか、他人の改修による変更なのかを後から見た時にわかりづらいという問題がありました。 仮に問題が発生した場合は修正を試みるのですが、独自の XML によって表現されているため、iOS の経験が浅い僕にとっては修正が非常に難しかったです。 また、複数人で並行して開発する際にもコンフリクトが起きやすくなってしまい解消に時間がかかるという問題となっていました。 さらに従来の CLINICS アプリは DLS を利用してレイアウトを作成していたのですが、コンポーネントに直接サイズが設定されているものがあり、ある画面では微妙にサイズを調整したい…といった要件に対応できず、せっかくのコンポーネントを再利用できないケースがありました。 解決案 課題に対する解決案は色々と考えられますが、弊社の開発スタイルやエンジニアのスキルを考慮し以下のような方針を立てました。 Storyboard と各画面の実装は 1 : 1 の関係とする 画面遷移の責務も Storyboard から切り離す コンポーネントにアトミックデザインを適用する Storyboard の分割は以下のようなステップで行っていました。 Refactor to Storyboard を使って巨大な Storyboard を分割する SwiftGen を利用し画面生成のコードを自動作成する 2 で生成したものを利用して画面遷移を行う 既存の Segue を削除する まず最初に Xcode 7 から利用可能となった「Refactor to Storyboard」を使って画面を分割するところから始めます。 この機能を利用すると選択した View が新しい Storyboard に切り出され、元の Storyboard には切り出した Storyboard へのリファレンスや Segue 等の接続が保持された状態になります。 次に各画面間の遷移を Segue を使わずに行うようにします。 Segue は便利なのですが、Identifier が単なる文字列であったり、Storyboard を分割してもリファレンスは保持しておく必要がある点が微妙に感じてしまい利用しないことにしました。 Segue を使わずに画面遷移を行う必要があるため、画面生成と画面遷移の方法を自前で実装する必要があります。 今回は画面生成の処理を SwiftGen を利用して自動生成可能にし、VIPER というアーキテクチャの Router を参考にして画面遷移を Storyboard から切り離すことにしました。 ※ SwiftGen の利用方法は SwiftGen#interface-builder を参照ください。 Router の実装は以下の通りです。 実装されたプロトコルを遷移元の VC に継承し、画面遷移のコードを呼び出すだけで画面遷移を行うことができます。 protocol ClinicWireframe : AnyObject { var viewController: UIViewController { get } func presentClinic ( clinicId : String ) func pushClinic ( clinicId : String ) } extension ClinicWireframe { func presentClinic ( clinicId : String ) { let vc = StoryboardScene. Clinic . initialScene . instantiate { ClinicViewController ( coder : $0 , isHeaderEnabled : true ) } let presenter = ClinicPresenter ( view : vc) presenter. setClinicId ( clinicId : clinicId) vc. inject ( presenter : presenter) vc. modalPresentationStyle = . pageSheet let nc = UINavigationController ( rootViewController : vc) viewController. present (nc, animated : true ) } func pushClinic ( clinicId : String ) { let vc = StoryboardScene. Clinic . initialScene . instantiate { ClinicViewController ( coder : $0 , isHeaderEnabled : false ) } let presenter = ClinicPresenter ( view : vc) presenter. setClinicId ( clinicId : clinicId) vc. inject ( presenter : presenter) viewController. navigationController ?. pushViewController (vc, animated : true ) } 最後にコンポーネントの調整についてですが、CLINICS アプリではアトミックデザインを簡略化し、以下のような基準でコンポーネントを実装しています。 Block: UI の最小単位 (他の PJT にも持ち込めそうなレベルまで分解されたもの) Partial: CLINICS の PJT 固有のコンポーネント Layout: ヘルプ用のモーダルやエラー画面など他の画面から呼び出されることで初めて意味をなす画面など Page: 各 ViewController とそれに紐づく Storyboard この管理方法自体は 弊社の別プロダクトの開発を担当しているエンジニアによって考案されたものです。 弊社ではサーバー・フロント分け隔てなく開発を任されることも多く、厳密なアトミックデザインだとコンポーネントの分類に困ることが多かったためこのような管理方法をとっているそうです。 今回のリニューアルに際して CLINICS アプリでもこれを参考にすることにしました。 これまで DLS として管理されていたコンポーネントは Block で実装しなおし、Width / Height といったサイズの設定を行わないようにしました。 このようにコンポーネントの実装レベルを明確にしたことで、実装に一定の指針が生まれ使い回しの効くコンポーネントを作成しやすくなりました。 2. View とロジックの分離 スピード開発が求められた背景を考えると仕方のないことではあるのですが、従来の CLINICS アプリでは ViewController にロジックが記述されており、俗にいう Fat ViewController の状態になってしまっていました。 Fat ViewController の問題点については既にさまざまな方が取り上げていますが、以下の部分が問題と感じています。 UI とロジックが分離されていないため、テストを書くことが難しい 可読性が低くなりがち ロジックが切り出されていないため似たような実装が点在する場合がある 課題 こちらは実際にあった ViewController の一部です。 このコードに関しては以下の部分が問題と感じていました。 通信処理の呼び出しが ViewController の責務になっていること 通信結果を整形するロジックが ViewController の責務になっていること 画面描画のための State 管理が ViewController の責務になっていること 解決案 UI とロジックを分離するための手法はさまざまなものがありますが、弊社のアプリには以下のような特徴があります。 iOS 以外にも複数のプラットフォームをサポートしているためフロントエンドで保持するデータや複雑なロジック自体は少ない (サーバー側でなるべく担保している) 実装時や QA 時に感じた違和感について細かくディレクターと打ち合わせし、その結果次第では仕様を変更することがある これらを考慮すると、プロジェクトの期間的に初期の導入コストが低く、データフローがシンプルなものに留めたいというように考えがまとまってきました。 これらを考慮し、CLINICS アプリでは MVP というアーキテクチャを採用することにしました。 より詳細には MVP の Passive View 方式を採用しており、以下のような形で実装しています。 View は基本的にすべての入力イベントに対応した Presenter の処理を呼び出す Presenter は入力に応じて通信処理などの外部要因となる処理を呼び出し、結果を整形する プレゼンテーションロジックの結果を描画するように View に指示を出す View は Presenter の指示によってのみ描画処理を行い、自身を起点とした描画処理は行わない Model–view–presenter - Wikipedia 既に Router は導入してるため、複雑な処理フローを実装したい場合は Interactor を導入するだけで VIPER アーキテクチャへと発展させることが簡単にできる点も魅力でした。 CLINICS アプリでの ViewController / Presenter の実装を簡単にまとめたものは以下のようになっています。 final class ClinicViewController : UIViewController { private lazy var presenter: ClinicPresenterInput = { fatalError (“Failed to inject presenter”) }() override func viewDidLoad () { super . viewDidLoad () presenter?. refresh () } func inject ( presenter : ClinicPresenterInput) { self . presenter = presenter } // タップされた際に呼び出す func onTapServiceCell ( _ service : ServiceEntity, isTelemedicine : Bool ) { presenter?. didTapServiceButton (service, isTelemedicine : isTelemedicine) } } // MARK: - ClinicPresenterOutput extension ClinicViewController : ClinicPresenterOutput { func reloadData ( clinic : ClinicEntity?) { clinicViewStore. clinic = clinic } func openCreateAppointmentView ( clinic : ClinicEntity, service : ServiceEntity, isTelemedicine : Bool ) // 予約へ進む } func showErrorAlert ( _ error : Error ) { // エラー表示を行う } } protocol ClinicPresenterInput : AnyObject { func refresh () func didTapServiceButton ( _ service : ServiceEntity, isTelemedicine : Bool ) } protocol ClinicPresenterOutput : AnyObject { func reloadData ( clinic : ClinicEntity?) func openCreateAppointmentView ( clinic : ClinicEntity, service : ServiceEntity, isTelemedicine : Bool ) func showErrorAlert ( _ error : Error ) } final class ClinicPresenter { private let clinicRepository: ClinicRepository private var clinic: ClinicEntity? private var cancellables: Set <AnyCancellable> = . init () init ( view : ClinicPresenterOutput, container : DIContainer) { self . view = view clinicRepository = container. resolve () } private func reloadView () { view?. reloadData ( clinic : clinic) } } // MARK: - PresenterInput extension ClinicPresenter : ClinicPresenterInput { func refresh () { guard let clinicId = clinicId else { return } clinicRepository. getClinic ( clinicId : clinicId) . sink ( receiveCompletion : { [ weak self ] completion in guard let self = self else { return } guard case let . failure (error) = completion else { return } self . view ?. showErrorAlert (error) } }, receiveValue : { [ weak self ] response in guard let self = self else { return } self . clinic = response. data self . reloadView () } ) . store ( in : &cancellables) } func didTapServiceButton ( _ service : ClinicsServiceEntity, isTelemedicine : Bool ) { guard let clinic = clinic else { return } view?. openCreateAppointmentView ( clinic : clinic, service : service, isTelemedicine : isTelemedicine) } } ViewController と Presenter は以下のように Router の内部で DI するようにしています。 protocol ClinicWireframe : AnyObject { var viewController: UIViewController { get } func pushClinic ( clinicId : String ) } extension ClinicWireframe { func pushClinic ( clinicId : String ) { let vc = StoryboardScene. Clinic . initialScene . instantiate { ClinicViewController ( coder : $0 , isHeaderEnabled : false ) } let presenter = ClinicPresenter ( view : vc, container : DIContainer ()) presenter. setClinicId ( clinicId : clinicId) vc. inject ( presenter : presenter) viewController. navigationController ?. pushViewController (vc, animated : true ) } } これによって、もともと ViewController にあった処理は以下のように分離されました。 また、View と Presenter はインターフェースを介してしかお互いを知らないため、実装の交換が簡単にできるようになりました。 Presenter を交換することで 1 つの View で別々の処理を表現することが可能となったり、View をテストコードを交換することで Presenter の入出力値をテストすることができるようになっています。 まとめ CLINICS アプリは歴史のあるプロジェクトですが、今回のプロジェクトを通して UI だけでなく裏側の実装も刷新しています。 巨大な Storyboard を分解したことでメンテナビリティが向上し、MVP (+ Router) の導入によって View とロジックの交換が簡単になり、テストなどの実装を取り入れやすくなりました。 さいごに ブログの本編には書けなかったのですが、今回リニューアルされた画面に関しては SwiftUI を利用してフルスクラッチで実装していたり、 Asset の管理方法についても大きな見直しを行いました。 またアーキテクチャの選定にあたり、「 iOS アプリ設計パターン入門 」が大変参考になりました。iOS の開発を行う方はぜひ一読してほしいと思います。 約半年ほどかかった大きなプロジェクトでしたが、患者エンゲージメントチームのメンバー全員で取り組み無事にリリースまで漕ぎ着けることができました。まだまだ手探りな部分もありますが、今後も患者さんにとってより安心して使えるサービスとなるように開発を続けていければと思っています。 長くなりましたが、最後までお読みいただきありがとうございました。 https://www.medley.jp/jobs/

こんにちは、医療プラットフォーム本部/プロダクト開発室/第一開発グループ所属の世嘉良です。 メドレーには 2018 年の頭に入社しており、今年で 4 年目になります。 当初はサーバーサイドを中心に開発を担当していたのですが、最近は患者エンゲージメントチームという患者様に提供するサービスを開発するチームで主に iOS の仕事を担当することが多いです。 さて去年の 12 月になりますが、 CLINICS アプリ は UI のフルリニューアル を行いました。 今回はリニューアルの裏話 (iOS について) をしていきたいと思います。 これまでの CLINICS アプリについて 本題を書く前に、CLINICS アプリの歴史を紹介します。 ファーストコミットを見てみると、アプリの開発は 2016 年 2 月ごろからスタートし、ファーストリリースが行われたのが 2016 年 5 月でした。 当初、担当していたエンジニアは iOS の経験が豊富な方はおらず、全員で試行錯誤しながら開発を進めていたようです。 しばらくの間は機能の追加などが行われていましたが、 CLINICS カルテ の開発に注力するために大きな開発はストップし、 Pharms との連携が開始される 2020 年 5 月頃まで機能や設計に関する見直しがほとんど行われてきませんでした。 iOS に詳しいエンジニアがいなかったにも関わらず、かなりのスピード感でリリースしていることはさすがの開発力という一言に尽きるのですが、Pharms との連携やお薬手帳といった機能が追加されたり、今後の開発を見据えた際に既存機能や設計の見直しを行いたいと思うようになってきました。 改善したい部分はたくさんあったのですが、対応工数を踏まえ今回のリニューアルでは以下の 2 点の改善に注力することにしました。 Storyboard による View の管理 View とロジックの分離 この 2 点についてそれぞれ詳しく説明します。 1. Storyboard による View の管理 従来の開発では Storyboard を利用して View を作成していました。 Storyboard を使うとレイアウトや画面遷移を簡単に実装することができますが、開発を続けているうちに以下のような問題が目立つようになってきました。 Storyboard が巨大化していき、複数人開発を行う際に支障がでる レイアウトに追加・変更が行われた場合に AutoLayout の再設定に時間がかかる コンポーネント自体にサイズが設定されていることがあり、コンポーネントを再利用できないことがある 課題 こちらは実際にあった Storyboard のキャプチャですが、複数の画面が 1 つの Storyboard 内に詰め込まれた状態となっていました。 Storyboard は Xcode のバージョンにより微妙な差分が発生してしまったり、AutoLayout の調整が必要になる場合があります。 こちらは古い Storyboard の画面を開いた後の差分なのですが、この変更がシステムによって加えられた変更なのか、他人の改修による変更なのかを後から見た時にわかりづらいという問題がありました。 仮に問題が発生した場合は修正を試みるのですが、独自の XML によって表現されているため、iOS の経験が浅い僕にとっては修正が非常に難しかったです。 また、複数人で並行して開発する際にもコンフリクトが起きやすくなってしまい解消に時間がかかるという問題となっていました。 さらに従来の CLINICS アプリは DLS を利用してレイアウトを作成していたのですが、コンポーネントに直接サイズが設定されているものがあり、ある画面では微妙にサイズを調整したい…といった要件に対応できず、せっかくのコンポーネントを再利用できないケースがありました。 解決案 課題に対する解決案は色々と考えられますが、弊社の開発スタイルやエンジニアのスキルを考慮し以下のような方針を立てました。 Storyboard と各画面の実装は 1 : 1 の関係とする 画面遷移の責務も Storyboard から切り離す コンポーネントにアトミックデザインを適用する Storyboard の分割は以下のようなステップで行っていました。 Refactor to Storyboard を使って巨大な Storyboard を分割する SwiftGen を利用し画面生成のコードを自動作成する 2 で生成したものを利用して画面遷移を行う 既存の Segue を削除する まず最初に Xcode 7 から利用可能となった「Refactor to Storyboard」を使って画面を分割するところから始めます。 この機能を利用すると選択した View が新しい Storyboard に切り出され、元の Storyboard には切り出した Storyboard へのリファレンスや Segue 等の接続が保持された状態になります。 次に各画面間の遷移を Segue を使わずに行うようにします。 Segue は便利なのですが、Identifier が単なる文字列であったり、Storyboard を分割してもリファレンスは保持しておく必要がある点が微妙に感じてしまい利用しないことにしました。 Segue を使わずに画面遷移を行う必要があるため、画面生成と画面遷移の方法を自前で実装する必要があります。 今回は画面生成の処理を SwiftGen を利用して自動生成可能にし、VIPER というアーキテクチャの Router を参考にして画面遷移を Storyboard から切り離すことにしました。 ※ SwiftGen の利用方法は SwiftGen#interface-builder を参照ください。 Router の実装は以下の通りです。 実装されたプロトコルを遷移元の VC に継承し、画面遷移のコードを呼び出すだけで画面遷移を行うことができます。 protocol ClinicWireframe : AnyObject { var viewController: UIViewController { get } func presentClinic ( clinicId : String ) func pushClinic ( clinicId : String ) } extension ClinicWireframe { func presentClinic ( clinicId : String ) { let vc = StoryboardScene. Clinic . initialScene . instantiate { ClinicViewController ( coder : $0 , isHeaderEnabled : true ) } let presenter = ClinicPresenter ( view : vc) presenter. setClinicId ( clinicId : clinicId) vc. inject ( presenter : presenter) vc. modalPresentationStyle = . pageSheet let nc = UINavigationController ( rootViewController : vc) viewController. present (nc, animated : true ) } func pushClinic ( clinicId : String ) { let vc = StoryboardScene. Clinic . initialScene . instantiate { ClinicViewController ( coder : $0 , isHeaderEnabled : false ) } let presenter = ClinicPresenter ( view : vc) presenter. setClinicId ( clinicId : clinicId) vc. inject ( presenter : presenter) viewController. navigationController ?. pushViewController (vc, animated : true ) } 最後にコンポーネントの調整についてですが、CLINICS アプリではアトミックデザインを簡略化し、以下のような基準でコンポーネントを実装しています。 Block: UI の最小単位 (他の PJT にも持ち込めそうなレベルまで分解されたもの) Partial: CLINICS の PJT 固有のコンポーネント Layout: ヘルプ用のモーダルやエラー画面など他の画面から呼び出されることで初めて意味をなす画面など Page: 各 ViewController とそれに紐づく Storyboard この管理方法自体は 弊社の別プロダクトの開発を担当しているエンジニアによって考案されたものです。 弊社ではサーバー・フロント分け隔てなく開発を任されることも多く、厳密なアトミックデザインだとコンポーネントの分類に困ることが多かったためこのような管理方法をとっているそうです。 今回のリニューアルに際して CLINICS アプリでもこれを参考にすることにしました。 これまで DLS として管理されていたコンポーネントは Block で実装しなおし、Width / Height といったサイズの設定を行わないようにしました。 このようにコンポーネントの実装レベルを明確にしたことで、実装に一定の指針が生まれ使い回しの効くコンポーネントを作成しやすくなりました。 2. View とロジックの分離 スピード開発が求められた背景を考えると仕方のないことではあるのですが、従来の CLINICS アプリでは ViewController にロジックが記述されており、俗にいう Fat ViewController の状態になってしまっていました。 Fat ViewController の問題点については既にさまざまな方が取り上げていますが、以下の部分が問題と感じています。 UI とロジックが分離されていないため、テストを書くことが難しい 可読性が低くなりがち ロジックが切り出されていないため似たような実装が点在する場合がある 課題 こちらは実際にあった ViewController の一部です。 このコードに関しては以下の部分が問題と感じていました。 通信処理の呼び出しが ViewController の責務になっていること 通信結果を整形するロジックが ViewController の責務になっていること 画面描画のための State 管理が ViewController の責務になっていること 解決案 UI とロジックを分離するための手法はさまざまなものがありますが、弊社のアプリには以下のような特徴があります。 iOS 以外にも複数のプラットフォームをサポートしているためフロントエンドで保持するデータや複雑なロジック自体は少ない (サーバー側でなるべく担保している) 実装時や QA 時に感じた違和感について細かくディレクターと打ち合わせし、その結果次第では仕様を変更することがある これらを考慮すると、プロジェクトの期間的に初期の導入コストが低く、データフローがシンプルなものに留めたいというように考えがまとまってきました。 これらを考慮し、CLINICS アプリでは MVP というアーキテクチャを採用することにしました。 より詳細には MVP の Passive View 方式を採用しており、以下のような形で実装しています。 View は基本的にすべての入力イベントに対応した Presenter の処理を呼び出す Presenter は入力に応じて通信処理などの外部要因となる処理を呼び出し、結果を整形する プレゼンテーションロジックの結果を描画するように View に指示を出す View は Presenter の指示によってのみ描画処理を行い、自身を起点とした描画処理は行わない Model–view–presenter - Wikipedia 既に Router は導入してるため、複雑な処理フローを実装したい場合は Interactor を導入するだけで VIPER アーキテクチャへと発展させることが簡単にできる点も魅力でした。 CLINICS アプリでの ViewController / Presenter の実装を簡単にまとめたものは以下のようになっています。 final class ClinicViewController : UIViewController { private lazy var presenter: ClinicPresenterInput = { fatalError (“Failed to inject presenter”) }() override func viewDidLoad () { super . viewDidLoad () presenter?. refresh () } func inject ( presenter : ClinicPresenterInput) { self . presenter = presenter } // タップされた際に呼び出す func onTapServiceCell ( _ service : ServiceEntity, isTelemedicine : Bool ) { presenter?. didTapServiceButton (service, isTelemedicine : isTelemedicine) } } // MARK: - ClinicPresenterOutput extension ClinicViewController : ClinicPresenterOutput { func reloadData ( clinic : ClinicEntity?) { clinicViewStore. clinic = clinic } func openCreateAppointmentView ( clinic : ClinicEntity, service : ServiceEntity, isTelemedicine : Bool ) // 予約へ進む } func showErrorAlert ( _ error : Error ) { // エラー表示を行う } } protocol ClinicPresenterInput : AnyObject { func refresh () func didTapServiceButton ( _ service : ServiceEntity, isTelemedicine : Bool ) } protocol ClinicPresenterOutput : AnyObject { func reloadData ( clinic : ClinicEntity?) func openCreateAppointmentView ( clinic : ClinicEntity, service : ServiceEntity, isTelemedicine : Bool ) func showErrorAlert ( _ error : Error ) } final class ClinicPresenter { private let clinicRepository: ClinicRepository private var clinic: ClinicEntity? private var cancellables: Set <AnyCancellable> = . init () init ( view : ClinicPresenterOutput, container : DIContainer) { self . view = view clinicRepository = container. resolve () } private func reloadView () { view?. reloadData ( clinic : clinic) } } // MARK: - PresenterInput extension ClinicPresenter : ClinicPresenterInput { func refresh () { guard let clinicId = clinicId else { return } clinicRepository. getClinic ( clinicId : clinicId) . sink ( receiveCompletion : { [ weak self ] completion in guard let self = self else { return } guard case let . failure (error) = completion else { return } self . view ?. showErrorAlert (error) } }, receiveValue : { [ weak self ] response in guard let self = self else { return } self . clinic = response. data self . reloadView () } ) . store ( in : &cancellables) } func didTapServiceButton ( _ service : ClinicsServiceEntity, isTelemedicine : Bool ) { guard let clinic = clinic else { return } view?. openCreateAppointmentView ( clinic : clinic, service : service, isTelemedicine : isTelemedicine) } } ViewController と Presenter は以下のように Router の内部で DI するようにしています。 protocol ClinicWireframe : AnyObject { var viewController: UIViewController { get } func pushClinic ( clinicId : String ) } extension ClinicWireframe { func pushClinic ( clinicId : String ) { let vc = StoryboardScene. Clinic . initialScene . instantiate { ClinicViewController ( coder : $0 , isHeaderEnabled : false ) } let presenter = ClinicPresenter ( view : vc, container : DIContainer ()) presenter. setClinicId ( clinicId : clinicId) vc. inject ( presenter : presenter) viewController. navigationController ?. pushViewController (vc, animated : true ) } } これによって、もともと ViewController にあった処理は以下のように分離されました。 また、View と Presenter はインターフェースを介してしかお互いを知らないため、実装の交換が簡単にできるようになりました。 Presenter を交換することで 1 つの View で別々の処理を表現することが可能となったり、View をテストコードを交換することで Presenter の入出力値をテストすることができるようになっています。 まとめ CLINICS アプリは歴史のあるプロジェクトですが、今回のプロジェクトを通して UI だけでなく裏側の実装も刷新しています。 巨大な Storyboard を分解したことでメンテナビリティが向上し、MVP (+ Router) の導入によって View とロジックの交換が簡単になり、テストなどの実装を取り入れやすくなりました。 さいごに ブログの本編には書けなかったのですが、今回リニューアルされた画面に関しては SwiftUI を利用してフルスクラッチで実装していたり、 Asset の管理方法についても大きな見直しを行いました。 またアーキテクチャの選定にあたり、「 iOS アプリ設計パターン入門 」が大変参考になりました。iOS の開発を行う方はぜひ一読してほしいと思います。 約半年ほどかかった大きなプロジェクトでしたが、患者エンゲージメントチームのメンバー全員で取り組み無事にリリースまで漕ぎ着けることができました。まだまだ手探りな部分もありますが、今後も患者さんにとってより安心して使えるサービスとなるように開発を続けていければと思っています。 長くなりましたが、最後までお読みいただきありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは、医療プラットフォーム本部/プロダクト開発室/第一開発グループ所属の世嘉良です。 メドレーには 2018 年の頭に入社しており、今年で 4 年目になります。 当初はサーバーサイドを中心に開発を担当していたのですが、最近は患者エンゲージメントチームという患者様に提供するサービスを開発するチームで主に iOS の仕事を担当することが多いです。 さて去年の 12 月になりますが、 CLINICS アプリ は UI のフルリニューアル を行いました。 今回はリニューアルの裏話 (iOS について) をしていきたいと思います。 これまでの CLINICS アプリについて 本題を書く前に、CLINICS アプリの歴史を紹介します。 ファーストコミットを見てみると、アプリの開発は 2016 年 2 月ごろからスタートし、ファーストリリースが行われたのが 2016 年 5 月でした。 当初、担当していたエンジニアは iOS の経験が豊富な方はおらず、全員で試行錯誤しながら開発を進めていたようです。 しばらくの間は機能の追加などが行われていましたが、 CLINICS カルテ の開発に注力するために大きな開発はストップし、 Pharms との連携が開始される 2020 年 5 月頃まで機能や設計に関する見直しがほとんど行われてきませんでした。 iOS に詳しいエンジニアがいなかったにも関わらず、かなりのスピード感でリリースしていることはさすがの開発力という一言に尽きるのですが、Pharms との連携やお薬手帳といった機能が追加されたり、今後の開発を見据えた際に既存機能や設計の見直しを行いたいと思うようになってきました。 改善したい部分はたくさんあったのですが、対応工数を踏まえ今回のリニューアルでは以下の 2 点の改善に注力することにしました。 Storyboard による View の管理 View とロジックの分離 この 2 点についてそれぞれ詳しく説明します。 1. Storyboard による View の管理 従来の開発では Storyboard を利用して View を作成していました。 Storyboard を使うとレイアウトや画面遷移を簡単に実装することができますが、開発を続けているうちに以下のような問題が目立つようになってきました。 Storyboard が巨大化していき、複数人開発を行う際に支障がでる レイアウトに追加・変更が行われた場合に AutoLayout の再設定に時間がかかる コンポーネント自体にサイズが設定されていることがあり、コンポーネントを再利用できないことがある 課題 こちらは実際にあった Storyboard のキャプチャですが、複数の画面が 1 つの Storyboard 内に詰め込まれた状態となっていました。 Storyboard は Xcode のバージョンにより微妙な差分が発生してしまったり、AutoLayout の調整が必要になる場合があります。 こちらは古い Storyboard の画面を開いた後の差分なのですが、この変更がシステムによって加えられた変更なのか、他人の改修による変更なのかを後から見た時にわかりづらいという問題がありました。 仮に問題が発生した場合は修正を試みるのですが、独自の XML によって表現されているため、iOS の経験が浅い僕にとっては修正が非常に難しかったです。 また、複数人で並行して開発する際にもコンフリクトが起きやすくなってしまい解消に時間がかかるという問題となっていました。 さらに従来の CLINICS アプリは DLS を利用してレイアウトを作成していたのですが、コンポーネントに直接サイズが設定されているものがあり、ある画面では微妙にサイズを調整したい…といった要件に対応できず、せっかくのコンポーネントを再利用できないケースがありました。 解決案 課題に対する解決案は色々と考えられますが、弊社の開発スタイルやエンジニアのスキルを考慮し以下のような方針を立てました。 Storyboard と各画面の実装は 1 : 1 の関係とする 画面遷移の責務も Storyboard から切り離す コンポーネントにアトミックデザインを適用する Storyboard の分割は以下のようなステップで行っていました。 Refactor to Storyboard を使って巨大な Storyboard を分割する SwiftGen を利用し画面生成のコードを自動作成する 2 で生成したものを利用して画面遷移を行う 既存の Segue を削除する まず最初に Xcode 7 から利用可能となった「Refactor to Storyboard」を使って画面を分割するところから始めます。 この機能を利用すると選択した View が新しい Storyboard に切り出され、元の Storyboard には切り出した Storyboard へのリファレンスや Segue 等の接続が保持された状態になります。 次に各画面間の遷移を Segue を使わずに行うようにします。 Segue は便利なのですが、Identifier が単なる文字列であったり、Storyboard を分割してもリファレンスは保持しておく必要がある点が微妙に感じてしまい利用しないことにしました。 Segue を使わずに画面遷移を行う必要があるため、画面生成と画面遷移の方法を自前で実装する必要があります。 今回は画面生成の処理を SwiftGen を利用して自動生成可能にし、VIPER というアーキテクチャの Router を参考にして画面遷移を Storyboard から切り離すことにしました。 ※ SwiftGen の利用方法は SwiftGen#interface-builder を参照ください。 Router の実装は以下の通りです。 実装されたプロトコルを遷移元の VC に継承し、画面遷移のコードを呼び出すだけで画面遷移を行うことができます。 protocol ClinicWireframe : AnyObject { var viewController: UIViewController { get } func presentClinic ( clinicId : String ) func pushClinic ( clinicId : String ) } extension ClinicWireframe { func presentClinic ( clinicId : String ) { let vc = StoryboardScene. Clinic . initialScene . instantiate { ClinicViewController ( coder : $0 , isHeaderEnabled : true ) } let presenter = ClinicPresenter ( view : vc) presenter. setClinicId ( clinicId : clinicId) vc. inject ( presenter : presenter) vc. modalPresentationStyle = . pageSheet let nc = UINavigationController ( rootViewController : vc) viewController. present (nc, animated : true ) } func pushClinic ( clinicId : String ) { let vc = StoryboardScene. Clinic . initialScene . instantiate { ClinicViewController ( coder : $0 , isHeaderEnabled : false ) } let presenter = ClinicPresenter ( view : vc) presenter. setClinicId ( clinicId : clinicId) vc. inject ( presenter : presenter) viewController. navigationController ?. pushViewController (vc, animated : true ) } 最後にコンポーネントの調整についてですが、CLINICS アプリではアトミックデザインを簡略化し、以下のような基準でコンポーネントを実装しています。 Block: UI の最小単位 (他の PJT にも持ち込めそうなレベルまで分解されたもの) Partial: CLINICS の PJT 固有のコンポーネント Layout: ヘルプ用のモーダルやエラー画面など他の画面から呼び出されることで初めて意味をなす画面など Page: 各 ViewController とそれに紐づく Storyboard この管理方法自体は 弊社の別プロダクトの開発を担当しているエンジニアによって考案されたものです。 弊社ではサーバー・フロント分け隔てなく開発を任されることも多く、厳密なアトミックデザインだとコンポーネントの分類に困ることが多かったためこのような管理方法をとっているそうです。 今回のリニューアルに際して CLINICS アプリでもこれを参考にすることにしました。 これまで DLS として管理されていたコンポーネントは Block で実装しなおし、Width / Height といったサイズの設定を行わないようにしました。 このようにコンポーネントの実装レベルを明確にしたことで、実装に一定の指針が生まれ使い回しの効くコンポーネントを作成しやすくなりました。 2. View とロジックの分離 スピード開発が求められた背景を考えると仕方のないことではあるのですが、従来の CLINICS アプリでは ViewController にロジックが記述されており、俗にいう Fat ViewController の状態になってしまっていました。 Fat ViewController の問題点については既にさまざまな方が取り上げていますが、以下の部分が問題と感じています。 UI とロジックが分離されていないため、テストを書くことが難しい 可読性が低くなりがち ロジックが切り出されていないため似たような実装が点在する場合がある 課題 こちらは実際にあった ViewController の一部です。 このコードに関しては以下の部分が問題と感じていました。 通信処理の呼び出しが ViewController の責務になっていること 通信結果を整形するロジックが ViewController の責務になっていること 画面描画のための State 管理が ViewController の責務になっていること 解決案 UI とロジックを分離するための手法はさまざまなものがありますが、弊社のアプリには以下のような特徴があります。 iOS 以外にも複数のプラットフォームをサポートしているためフロントエンドで保持するデータや複雑なロジック自体は少ない (サーバー側でなるべく担保している) 実装時や QA 時に感じた違和感について細かくディレクターと打ち合わせし、その結果次第では仕様を変更することがある これらを考慮すると、プロジェクトの期間的に初期の導入コストが低く、データフローがシンプルなものに留めたいというように考えがまとまってきました。 これらを考慮し、CLINICS アプリでは MVP というアーキテクチャを採用することにしました。 より詳細には MVP の Passive View 方式を採用しており、以下のような形で実装しています。 View は基本的にすべての入力イベントに対応した Presenter の処理を呼び出す Presenter は入力に応じて通信処理などの外部要因となる処理を呼び出し、結果を整形する プレゼンテーションロジックの結果を描画するように View に指示を出す View は Presenter の指示によってのみ描画処理を行い、自身を起点とした描画処理は行わない Model–view–presenter - Wikipedia 既に Router は導入してるため、複雑な処理フローを実装したい場合は Interactor を導入するだけで VIPER アーキテクチャへと発展させることが簡単にできる点も魅力でした。 CLINICS アプリでの ViewController / Presenter の実装を簡単にまとめたものは以下のようになっています。 final class ClinicViewController : UIViewController { private lazy var presenter: ClinicPresenterInput = { fatalError (“Failed to inject presenter”) }() override func viewDidLoad () { super . viewDidLoad () presenter?. refresh () } func inject ( presenter : ClinicPresenterInput) { self . presenter = presenter } // タップされた際に呼び出す func onTapServiceCell ( _ service : ServiceEntity, isTelemedicine : Bool ) { presenter?. didTapServiceButton (service, isTelemedicine : isTelemedicine) } } // MARK: - ClinicPresenterOutput extension ClinicViewController : ClinicPresenterOutput { func reloadData ( clinic : ClinicEntity?) { clinicViewStore. clinic = clinic } func openCreateAppointmentView ( clinic : ClinicEntity, service : ServiceEntity, isTelemedicine : Bool ) // 予約へ進む } func showErrorAlert ( _ error : Error ) { // エラー表示を行う } } protocol ClinicPresenterInput : AnyObject { func refresh () func didTapServiceButton ( _ service : ServiceEntity, isTelemedicine : Bool ) } protocol ClinicPresenterOutput : AnyObject { func reloadData ( clinic : ClinicEntity?) func openCreateAppointmentView ( clinic : ClinicEntity, service : ServiceEntity, isTelemedicine : Bool ) func showErrorAlert ( _ error : Error ) } final class ClinicPresenter { private let clinicRepository: ClinicRepository private var clinic: ClinicEntity? private var cancellables: Set <AnyCancellable> = . init () init ( view : ClinicPresenterOutput, container : DIContainer) { self . view = view clinicRepository = container. resolve () } private func reloadView () { view?. reloadData ( clinic : clinic) } } // MARK: - PresenterInput extension ClinicPresenter : ClinicPresenterInput { func refresh () { guard let clinicId = clinicId else { return } clinicRepository. getClinic ( clinicId : clinicId) . sink ( receiveCompletion : { [ weak self ] completion in guard let self = self else { return } guard case let . failure (error) = completion else { return } self . view ?. showErrorAlert (error) } }, receiveValue : { [ weak self ] response in guard let self = self else { return } self . clinic = response. data self . reloadView () } ) . store ( in : &cancellables) } func didTapServiceButton ( _ service : ClinicsServiceEntity, isTelemedicine : Bool ) { guard let clinic = clinic else { return } view?. openCreateAppointmentView ( clinic : clinic, service : service, isTelemedicine : isTelemedicine) } } ViewController と Presenter は以下のように Router の内部で DI するようにしています。 protocol ClinicWireframe : AnyObject { var viewController: UIViewController { get } func pushClinic ( clinicId : String ) } extension ClinicWireframe { func pushClinic ( clinicId : String ) { let vc = StoryboardScene. Clinic . initialScene . instantiate { ClinicViewController ( coder : $0 , isHeaderEnabled : false ) } let presenter = ClinicPresenter ( view : vc, container : DIContainer ()) presenter. setClinicId ( clinicId : clinicId) vc. inject ( presenter : presenter) viewController. navigationController ?. pushViewController (vc, animated : true ) } } これによって、もともと ViewController にあった処理は以下のように分離されました。 また、View と Presenter はインターフェースを介してしかお互いを知らないため、実装の交換が簡単にできるようになりました。 Presenter を交換することで 1 つの View で別々の処理を表現することが可能となったり、View をテストコードを交換することで Presenter の入出力値をテストすることができるようになっています。 まとめ CLINICS アプリは歴史のあるプロジェクトですが、今回のプロジェクトを通して UI だけでなく裏側の実装も刷新しています。 巨大な Storyboard を分解したことでメンテナビリティが向上し、MVP (+ Router) の導入によって View とロジックの交換が簡単になり、テストなどの実装を取り入れやすくなりました。 さいごに ブログの本編には書けなかったのですが、今回リニューアルされた画面に関しては SwiftUI を利用してフルスクラッチで実装していたり、 Asset の管理方法についても大きな見直しを行いました。 またアーキテクチャの選定にあたり、「 iOS アプリ設計パターン入門 」が大変参考になりました。iOS の開発を行う方はぜひ一読してほしいと思います。 約半年ほどかかった大きなプロジェクトでしたが、患者エンゲージメントチームのメンバー全員で取り組み無事にリリースまで漕ぎ着けることができました。まだまだ手探りな部分もありますが、今後も患者さんにとってより安心して使えるサービスとなるように開発を続けていければと思っています。 長くなりましたが、最後までお読みいただきありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは、医療プラットフォーム本部/プロダクト開発室/第一開発グループ所属の世嘉良です。 メドレーには 2018 年の頭に入社しており、今年で 4 年目になります。 当初はサーバーサイドを中心に開発を担当していたのですが、最近は患者エンゲージメントチームという患者様に提供するサービスを開発するチームで主に iOS の仕事を担当することが多いです。 さて去年の 12 月になりますが、 CLINICS アプリ は UI のフルリニューアル を行いました。 今回はリニューアルの裏話 (iOS について) をしていきたいと思います。 これまでの CLINICS アプリについて 本題を書く前に、CLINICS アプリの歴史を紹介します。 ファーストコミットを見てみると、アプリの開発は 2016 年 2 月ごろからスタートし、ファーストリリースが行われたのが 2016 年 5 月でした。 当初、担当していたエンジニアは iOS の経験が豊富な方はおらず、全員で試行錯誤しながら開発を進めていたようです。 しばらくの間は機能の追加などが行われていましたが、 CLINICS カルテ の開発に注力するために大きな開発はストップし、 Pharms との連携が開始される 2020 年 5 月頃まで機能や設計に関する見直しがほとんど行われてきませんでした。 iOS に詳しいエンジニアがいなかったにも関わらず、かなりのスピード感でリリースしていることはさすがの開発力という一言に尽きるのですが、Pharms との連携やお薬手帳といった機能が追加されたり、今後の開発を見据えた際に既存機能や設計の見直しを行いたいと思うようになってきました。 改善したい部分はたくさんあったのですが、対応工数を踏まえ今回のリニューアルでは以下の 2 点の改善に注力することにしました。 Storyboard による View の管理 View とロジックの分離 この 2 点についてそれぞれ詳しく説明します。 1. Storyboard による View の管理 従来の開発では Storyboard を利用して View を作成していました。 Storyboard を使うとレイアウトや画面遷移を簡単に実装することができますが、開発を続けているうちに以下のような問題が目立つようになってきました。 Storyboard が巨大化していき、複数人開発を行う際に支障がでる レイアウトに追加・変更が行われた場合に AutoLayout の再設定に時間がかかる コンポーネント自体にサイズが設定されていることがあり、コンポーネントを再利用できないことがある 課題 こちらは実際にあった Storyboard のキャプチャですが、複数の画面が 1 つの Storyboard 内に詰め込まれた状態となっていました。 Storyboard は Xcode のバージョンにより微妙な差分が発生してしまったり、AutoLayout の調整が必要になる場合があります。 こちらは古い Storyboard の画面を開いた後の差分なのですが、この変更がシステムによって加えられた変更なのか、他人の改修による変更なのかを後から見た時にわかりづらいという問題がありました。 仮に問題が発生した場合は修正を試みるのですが、独自の XML によって表現されているため、iOS の経験が浅い僕にとっては修正が非常に難しかったです。 また、複数人で並行して開発する際にもコンフリクトが起きやすくなってしまい解消に時間がかかるという問題となっていました。 さらに従来の CLINICS アプリは DLS を利用してレイアウトを作成していたのですが、コンポーネントに直接サイズが設定されているものがあり、ある画面では微妙にサイズを調整したい…といった要件に対応できず、せっかくのコンポーネントを再利用できないケースがありました。 解決案 課題に対する解決案は色々と考えられますが、弊社の開発スタイルやエンジニアのスキルを考慮し以下のような方針を立てました。 Storyboard と各画面の実装は 1 : 1 の関係とする 画面遷移の責務も Storyboard から切り離す コンポーネントにアトミックデザインを適用する Storyboard の分割は以下のようなステップで行っていました。 Refactor to Storyboard を使って巨大な Storyboard を分割する SwiftGen を利用し画面生成のコードを自動作成する 2 で生成したものを利用して画面遷移を行う 既存の Segue を削除する まず最初に Xcode 7 から利用可能となった「Refactor to Storyboard」を使って画面を分割するところから始めます。 この機能を利用すると選択した View が新しい Storyboard に切り出され、元の Storyboard には切り出した Storyboard へのリファレンスや Segue 等の接続が保持された状態になります。 次に各画面間の遷移を Segue を使わずに行うようにします。 Segue は便利なのですが、Identifier が単なる文字列であったり、Storyboard を分割してもリファレンスは保持しておく必要がある点が微妙に感じてしまい利用しないことにしました。 Segue を使わずに画面遷移を行う必要があるため、画面生成と画面遷移の方法を自前で実装する必要があります。 今回は画面生成の処理を SwiftGen を利用して自動生成可能にし、VIPER というアーキテクチャの Router を参考にして画面遷移を Storyboard から切り離すことにしました。 ※ SwiftGen の利用方法は SwiftGen#interface-builder を参照ください。 Router の実装は以下の通りです。 実装されたプロトコルを遷移元の VC に継承し、画面遷移のコードを呼び出すだけで画面遷移を行うことができます。 protocol ClinicWireframe : AnyObject { var viewController: UIViewController { get } func presentClinic ( clinicId : String ) func pushClinic ( clinicId : String ) } extension ClinicWireframe { func presentClinic ( clinicId : String ) { let vc = StoryboardScene. Clinic . initialScene . instantiate { ClinicViewController ( coder : $0 , isHeaderEnabled : true ) } let presenter = ClinicPresenter ( view : vc) presenter. setClinicId ( clinicId : clinicId) vc. inject ( presenter : presenter) vc. modalPresentationStyle = . pageSheet let nc = UINavigationController ( rootViewController : vc) viewController. present (nc, animated : true ) } func pushClinic ( clinicId : String ) { let vc = StoryboardScene. Clinic . initialScene . instantiate { ClinicViewController ( coder : $0 , isHeaderEnabled : false ) } let presenter = ClinicPresenter ( view : vc) presenter. setClinicId ( clinicId : clinicId) vc. inject ( presenter : presenter) viewController. navigationController ?. pushViewController (vc, animated : true ) } 最後にコンポーネントの調整についてですが、CLINICS アプリではアトミックデザインを簡略化し、以下のような基準でコンポーネントを実装しています。 Block: UI の最小単位 (他の PJT にも持ち込めそうなレベルまで分解されたもの) Partial: CLINICS の PJT 固有のコンポーネント Layout: ヘルプ用のモーダルやエラー画面など他の画面から呼び出されることで初めて意味をなす画面など Page: 各 ViewController とそれに紐づく Storyboard この管理方法自体は 弊社の別プロダクトの開発を担当しているエンジニアによって考案されたものです。 弊社ではサーバー・フロント分け隔てなく開発を任されることも多く、厳密なアトミックデザインだとコンポーネントの分類に困ることが多かったためこのような管理方法をとっているそうです。 今回のリニューアルに際して CLINICS アプリでもこれを参考にすることにしました。 これまで DLS として管理されていたコンポーネントは Block で実装しなおし、Width / Height といったサイズの設定を行わないようにしました。 このようにコンポーネントの実装レベルを明確にしたことで、実装に一定の指針が生まれ使い回しの効くコンポーネントを作成しやすくなりました。 2. View とロジックの分離 スピード開発が求められた背景を考えると仕方のないことではあるのですが、従来の CLINICS アプリでは ViewController にロジックが記述されており、俗にいう Fat ViewController の状態になってしまっていました。 Fat ViewController の問題点については既にさまざまな方が取り上げていますが、以下の部分が問題と感じています。 UI とロジックが分離されていないため、テストを書くことが難しい 可読性が低くなりがち ロジックが切り出されていないため似たような実装が点在する場合がある 課題 こちらは実際にあった ViewController の一部です。 このコードに関しては以下の部分が問題と感じていました。 通信処理の呼び出しが ViewController の責務になっていること 通信結果を整形するロジックが ViewController の責務になっていること 画面描画のための State 管理が ViewController の責務になっていること 解決案 UI とロジックを分離するための手法はさまざまなものがありますが、弊社のアプリには以下のような特徴があります。 iOS 以外にも複数のプラットフォームをサポートしているためフロントエンドで保持するデータや複雑なロジック自体は少ない (サーバー側でなるべく担保している) 実装時や QA 時に感じた違和感について細かくディレクターと打ち合わせし、その結果次第では仕様を変更することがある これらを考慮すると、プロジェクトの期間的に初期の導入コストが低く、データフローがシンプルなものに留めたいというように考えがまとまってきました。 これらを考慮し、CLINICS アプリでは MVP というアーキテクチャを採用することにしました。 より詳細には MVP の Passive View 方式を採用しており、以下のような形で実装しています。 View は基本的にすべての入力イベントに対応した Presenter の処理を呼び出す Presenter は入力に応じて通信処理などの外部要因となる処理を呼び出し、結果を整形する プレゼンテーションロジックの結果を描画するように View に指示を出す View は Presenter の指示によってのみ描画処理を行い、自身を起点とした描画処理は行わない Model–view–presenter - Wikipedia 既に Router は導入してるため、複雑な処理フローを実装したい場合は Interactor を導入するだけで VIPER アーキテクチャへと発展させることが簡単にできる点も魅力でした。 CLINICS アプリでの ViewController / Presenter の実装を簡単にまとめたものは以下のようになっています。 final class ClinicViewController : UIViewController { private lazy var presenter: ClinicPresenterInput = { fatalError (“Failed to inject presenter”) }() override func viewDidLoad () { super . viewDidLoad () presenter?. refresh () } func inject ( presenter : ClinicPresenterInput) { self . presenter = presenter } // タップされた際に呼び出す func onTapServiceCell ( _ service : ServiceEntity, isTelemedicine : Bool ) { presenter?. didTapServiceButton (service, isTelemedicine : isTelemedicine) } } // MARK: - ClinicPresenterOutput extension ClinicViewController : ClinicPresenterOutput { func reloadData ( clinic : ClinicEntity?) { clinicViewStore. clinic = clinic } func openCreateAppointmentView ( clinic : ClinicEntity, service : ServiceEntity, isTelemedicine : Bool ) // 予約へ進む } func showErrorAlert ( _ error : Error ) { // エラー表示を行う } } protocol ClinicPresenterInput : AnyObject { func refresh () func didTapServiceButton ( _ service : ServiceEntity, isTelemedicine : Bool ) } protocol ClinicPresenterOutput : AnyObject { func reloadData ( clinic : ClinicEntity?) func openCreateAppointmentView ( clinic : ClinicEntity, service : ServiceEntity, isTelemedicine : Bool ) func showErrorAlert ( _ error : Error ) } final class ClinicPresenter { private let clinicRepository: ClinicRepository private var clinic: ClinicEntity? private var cancellables: Set <AnyCancellable> = . init () init ( view : ClinicPresenterOutput, container : DIContainer) { self . view = view clinicRepository = container. resolve () } private func reloadView () { view?. reloadData ( clinic : clinic) } } // MARK: - PresenterInput extension ClinicPresenter : ClinicPresenterInput { func refresh () { guard let clinicId = clinicId else { return } clinicRepository. getClinic ( clinicId : clinicId) . sink ( receiveCompletion : { [ weak self ] completion in guard let self = self else { return } guard case let . failure (error) = completion else { return } self . view ?. showErrorAlert (error) } }, receiveValue : { [ weak self ] response in guard let self = self else { return } self . clinic = response. data self . reloadView () } ) . store ( in : &cancellables) } func didTapServiceButton ( _ service : ClinicsServiceEntity, isTelemedicine : Bool ) { guard let clinic = clinic else { return } view?. openCreateAppointmentView ( clinic : clinic, service : service, isTelemedicine : isTelemedicine) } } ViewController と Presenter は以下のように Router の内部で DI するようにしています。 protocol ClinicWireframe : AnyObject { var viewController: UIViewController { get } func pushClinic ( clinicId : String ) } extension ClinicWireframe { func pushClinic ( clinicId : String ) { let vc = StoryboardScene. Clinic . initialScene . instantiate { ClinicViewController ( coder : $0 , isHeaderEnabled : false ) } let presenter = ClinicPresenter ( view : vc, container : DIContainer ()) presenter. setClinicId ( clinicId : clinicId) vc. inject ( presenter : presenter) viewController. navigationController ?. pushViewController (vc, animated : true ) } } これによって、もともと ViewController にあった処理は以下のように分離されました。 また、View と Presenter はインターフェースを介してしかお互いを知らないため、実装の交換が簡単にできるようになりました。 Presenter を交換することで 1 つの View で別々の処理を表現することが可能となったり、View をテストコードを交換することで Presenter の入出力値をテストすることができるようになっています。 まとめ CLINICS アプリは歴史のあるプロジェクトですが、今回のプロジェクトを通して UI だけでなく裏側の実装も刷新しています。 巨大な Storyboard を分解したことでメンテナビリティが向上し、MVP (+ Router) の導入によって View とロジックの交換が簡単になり、テストなどの実装を取り入れやすくなりました。 さいごに ブログの本編には書けなかったのですが、今回リニューアルされた画面に関しては SwiftUI を利用してフルスクラッチで実装していたり、 Asset の管理方法についても大きな見直しを行いました。 またアーキテクチャの選定にあたり、「 iOS アプリ設計パターン入門 」が大変参考になりました。iOS の開発を行う方はぜひ一読してほしいと思います。 約半年ほどかかった大きなプロジェクトでしたが、患者エンゲージメントチームのメンバー全員で取り組み無事にリリースまで漕ぎ着けることができました。まだまだ手探りな部分もありますが、今後も患者さんにとってより安心して使えるサービスとなるように開発を続けていければと思っています。 長くなりましたが、最後までお読みいただきありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp