はじめまして。医療プラットフォーム本部プロダクト開発室エンジニアの小形（ @ogaclejapan ）です。 普段は、オンライン診療・服薬指導アプリ「 CLINICS 」の開発を担当しています。 近々、転職の入社エントリーも会社の 公式 note に公開されますので、ぜひ読んでみてください。 さて、昨年 12 月に CLINICS アプリは UI のフルリニューアル を行いました。 少し経ちましたが、「 CLINICS アプリのリニューアルの裏側(iOS 編) 」に続く、Android 編ということで裏話を書いていきます。 コミットグラフから振り返るアプリ開発史 リニューアルを終えた直近のコミットグラフから CLINICS の Android 版アプリの歴史を振り返ると、大きく 4 つの時代を超えてきました。 立ち上げ期：2016/7 - 閑散期：2018/4 - 再始動期：2020/5 - リニューアル期： 2021/5 - 2021/12 1. 立ち上げ期 記念すべき PR#1 は、2016 年 7 月でした。すでにコミットグラフの表示期間外なのであまり詳しく追えていませんが、1〜2 名がメインで関わりつつ、他のエンジニアの方のコミットもちらほらとありました。 私のようにネイティブアプリ開発を中心に経験してきた人は、まだ社内に少ないですが、フロントエンドからバックエンドまで幅広くできる人がとても多いのも納得です。 実装は SmartUI と名がつけられた アンチパターンの ように、ネットワーク通信から画面の表示制御まで単一のファイル内にすべて書かれていました。 アプリ経験者不在の中で開発を続けてきたことに尊敬の念を抱きつつも、リニューアル開発で全面的にコードを書き直すまで色々なツラみがありました…。R.I.P. FatActivity 🛐 2. 閑散期 2018 年から約 2 年ほど開発がほぼ止まっていました。もともとオンライン診察機能のために開発された経緯があり、この期間は電子カルテのシステム開発にリソースを注力していたようです。 3. 再始動期 2020 年 5 月から再びアプリ開発は活発になり、オンライン服薬指導機能を提供する調剤薬局窓口支援システム「 Pharms 」と連携する開発などが 1〜2 名で行われていました。 2020 年度通期の 決算説明資料 を読んでみると、患者（≒ アプリ）を中心にプロダクトラインナップを増やしていく医療 PF 事業投資の図が初登場していました。 この事業計画に沿って、Pharms 連携やお薬手帳機能など患者向けアプリを強化する動きが加速し、2016 年から引き継がれてきた UI デザインや拡張性をゼロベースで見直すべく、翌年のリニューアル開発へ繋がっていきます。 余談ですが、今年の 2 月に歯科業務支援システム「 Dentis 」をリリースして、4 月からアプリとの連携も試験的に開始しています。 リニューアル開発が完了していたからこそ、新規プロダクトへの連携にもスムーズに対応できました。 4. リニューアル期 リニューアル開発は、2021 年 5 月下旬頃から本格的に実装を開始し、同年 12 月に無事リリースすることができました。 当初、Android アプリ開発メンバーの頭数が足りておらず、私と協力会社の社外エンジニアのみで進めていく状況でしたが、6 月途中からアプリ開発経験のある社内エンジニアが 1 名異動してきてくれたおかげでピーク時を乗り切れました。 リニューアル後のアプリ内モジュール構成と技術スタックはこんな感じです。 今年の 3 月に 刷新された公式のアプリアーキテクチャガイド に近く、最低限データアクセス部分を分離したレイヤー構成としました。 モノクロではない色付きの技術スタックが今回新たに導入したものになります。 次章からリニューアル開発で取り組んだことについて、詳しく書いていきます。 リニューアル開発で取り組んだこと リニューアル開発のアプリをリードしていく役割で意識的に取り組んだことは次の 3 つです。 未来像を描く PoC を作成する 期間と機能の折り合いをつける 未来像を描く 当たり前のことですが、リニューアル開発が最終的な自分たちのゴールではありません。 この点を意識しながら、最初に iOS アプリをリード したエンジニアの世嘉良さんとメドレーに合ったアプリ開発のあるべき姿を一緒に描きました。 ざっくりとした図ですが、202X 未来像をメンバーと共有できたのは良かったと思っています。 事業的な観点や技術的な視点から自分たちがこの先に向かいたい方向性が明確になりました。 私が入社したときからすでに Web、iOS、Android の 3 つのプラットフォームを横断するチーム体制だったこともあり、今後も横断しながら効率的に取り組める開発スタイルを目指しています。 最終的には、未来と現在を結ぶ通過点として今回のリニューアルを据え、期間や体制面などから実現可能な範囲を話し合って決めました。 当時、私は入社 2 ヶ月目でコードの理解がまだ浅かったので、認識ズレのギャップを埋めることにもこの図が役立ちました。 PoC を作成する 開発するメンバー間の経験差が気になるときや実現性に不安が残るときは、PoC（Proof of Concept）モデルとして 1 つ以上の主要な実装パターンを事前に検証しておくと不確実性を低減できます。 今回は自分がリードする立場であり、Android 開発経験が豊富なメンバーが揃ってガンガンと進めていける感じではなかったので、入念に事前準備してリニューアル開発に臨みました。 PoC で検証できた実装方針は、メンバーにも既存 1 画面の書き換えを試してもらい、実際に PR をレビューして本番環境へ投入しています。 5 年前のコードベースが多く残るアプリをどのように移行させるか検証は少し大変でしたが、この事前準備の甲斐あって、リニューアル開発の期間中は技術的な要素でハマることなくタスクに集中できました。 期間と機能の折り合いをつける PoC モデルを作成して技術的な実現性への不安を解消できましたが、リニューアル開発を進めていく期間と仕様面で、まだいくつかの不安要素は残っている状況でした。 私自身、入社 2 ヶ月目で既存の業務ロジックは一部しか把握できてない ⇒ 　業務の仕様を理解しながら新しい画面へ書き換えていくので時間かかるかも…🧑‍💻 要素しか決まっていない画面が多数あり、画面デザインが並行して進んでいた ⇒ 　どのタイミングで要素を取得するべきなのか、デザイン次第で変わりそう…🎨 協力会社から一緒に手伝ってくれる社外エンジニアの実力値が未知数だった ⇒ 　軽く感覚は掴んでもらったものの、良しなにタスクを進められるだろうか…🧗‍♀️ いくら経験を積んだエンジニアでも不確実性を多く含むタスクの工数は正確に見積もれません。 そこで、リニューアルに関するアプリの開発定例で「もし想定する期間に間に合わなかったときにどうするか？」という議題を提起しました。 当たり前の話になっちゃいますが、うまくいかないときに取る行動を全員が共通認識しておくことは大切だと思っています。結論の候補は次のどちらかになるのではないでしょうか。 リリース日を延ばして計画したリニューアルのタスクはすべてやりきる 一部機能を落としてリリース日はずらさない 今回のリニューアル開発では、後者にあたるリリース日を死守する結論になりました。 ただし、一部の機能を落とすのではなく、既存の旧画面をスタイル調整してでも機能は出したいという要望があり、この点を設計やスケジュールのタスク優先度に折り込みました。 12 月に無事リリースできた Android アプリの裏側には、事業サイドとのこのような合意がありました。 実際、予定外のことも起きて一部の機能はリニューアル後に回しましたが、取る行動を決めておいたことで終盤あたふたすることなく、安定したものをリリースできました。 これから ここまでお読みいただきありがとうございました。同じような立場でこれからリニューアル開発を進めていく方のヒントになったら幸いです。 コードは 1 行も載せていませんが、Android アプリ開発者なら図の構成でなんとなく想像が付くと思い、今回は進め方にフォーカスしてみました。 さて、患者アプリはリニューアルが無事完了し、モダンな技術スタックで効率良く開発できる状態になりましたが、まだまだ技術的な視点で取り組みたいことはたくさんあります。 Kotlin Multiplatform／Kotlin Multiplatform Mobile の活用[^1] ⇒ 　 iOS、Android（可能なら Web も）のロジック統合など生産性を上げる 宣言的 UI への移行（iOS はすでに SwiftUI） ⇒ 　 UI アーキテクチャ構成やコンポーネント化など UI の共通感覚を高める 一方、患者アプリのビジネス視点では、オンライン診療を主軸とした予約・フォローアップの体験向上が 1 つの役目になります。 私自身は、「オンライン診療の実施に当たっての基本理念[^2]」に沿った成長路線がより良い患者体験につながると考えています。 Ⅳ オンライン診療の実施に当たっての基本理念 ① 患者の日常生活の情報も得ることにより、医療の質のさらなる向上に結び付けていくこと ② 医療を必要とする患者に対して、医療に対するアクセシビリティ（アクセスの容易性）を確保し、よりよい医療を得られる機会を増やすこと ③ 患者が治療に能動的に参画することにより、治療の効果を最大化すること この基本理念の 3 項目をアプリが満たすべき姿としたのが次の 2 つの状態です。 医療を身近に行動できる状態（基本理念の ① と ③ に該当） ⇒ 　「探す」「知る」「伝える」といった行動手順の簡素化 必要とする人が適切に使えている状態（基本理念の ② に該当） ⇒ 　アクセシビリティへの配慮、分かりやすい UI（≒ ユニバーサルデザイン） このような領域に興味のあるエンジニアやデザイナーさんがおりましたら、ぜひお近くのメドレーへ。 医療ヘルスケアの未来を一緒につくりませんか？ https://www.medley.jp/jobs/ 最後までお読みいただきありがとうございました。 [^1] Flutter や React Native といった選択肢もありますが、現時点では外部 SDK 含めた既存コードとの親和性や時間的な制約から段階的に移行できる技術を重視しています [^2] 厚生労働省が公開する「 オンライン診察の適切な実施に関する指針 10 ページ目 」より抜粋

はじめまして。医療プラットフォーム本部プロダクト開発室エンジニアの小形（ @ogaclejapan ）です。 普段は、オンライン診療・服薬指導アプリ「 CLINICS 」の開発を担当しています。 近々、転職の入社エントリーも会社の 公式 note に公開されますので、ぜひ読んでみてください。 さて、昨年 12 月に CLINICS アプリは UI のフルリニューアル を行いました。 少し経ちましたが、「 CLINICS アプリのリニューアルの裏側(iOS 編) 」に続く、Android 編ということで裏話を書いていきます。 コミットグラフから振り返るアプリ開発史 リニューアルを終えた直近のコミットグラフから CLINICS の Android 版アプリの歴史を振り返ると、大きく 4 つの時代を超えてきました。 立ち上げ期：2016/7 - 閑散期：2018/4 - 再始動期：2020/5 - リニューアル期： 2021/5 - 2021/12 1. 立ち上げ期 記念すべき PR#1 は、2016 年 7 月でした。すでにコミットグラフの表示期間外なのであまり詳しく追えていませんが、1〜2 名がメインで関わりつつ、他のエンジニアの方のコミットもちらほらとありました。 私のようにネイティブアプリ開発を中心に経験してきた人は、まだ社内に少ないですが、フロントエンドからバックエンドまで幅広くできる人がとても多いのも納得です。 実装は SmartUI と名がつけられた アンチパターンの ように、ネットワーク通信から画面の表示制御まで単一のファイル内にすべて書かれていました。 アプリ経験者不在の中で開発を続けてきたことに尊敬の念を抱きつつも、リニューアル開発で全面的にコードを書き直すまで色々なツラみがありました…。R.I.P. FatActivity 🛐 2. 閑散期 2018 年から約 2 年ほど開発がほぼ止まっていました。もともとオンライン診察機能のために開発された経緯があり、この期間は電子カルテのシステム開発にリソースを注力していたようです。 3. 再始動期 2020 年 5 月から再びアプリ開発は活発になり、オンライン服薬指導機能を提供する調剤薬局窓口支援システム「 Pharms 」と連携する開発などが 1〜2 名で行われていました。 2020 年度通期の 決算説明資料 を読んでみると、患者（≒ アプリ）を中心にプロダクトラインナップを増やしていく医療 PF 事業投資の図が初登場していました。 この事業計画に沿って、Pharms 連携やお薬手帳機能など患者向けアプリを強化する動きが加速し、2016 年から引き継がれてきた UI デザインや拡張性をゼロベースで見直すべく、翌年のリニューアル開発へ繋がっていきます。 余談ですが、今年の 2 月に歯科業務支援システム「 Dentis 」をリリースして、4 月からアプリとの連携も試験的に開始しています。 リニューアル開発が完了していたからこそ、新規プロダクトへの連携にもスムーズに対応できました。 4. リニューアル期 リニューアル開発は、2021 年 5 月下旬頃から本格的に実装を開始し、同年 12 月に無事リリースすることができました。 当初、Android アプリ開発メンバーの頭数が足りておらず、私と協力会社の社外エンジニアのみで進めていく状況でしたが、6 月途中からアプリ開発経験のある社内エンジニアが 1 名異動してきてくれたおかげでピーク時を乗り切れました。 リニューアル後のアプリ内モジュール構成と技術スタックはこんな感じです。 今年の 3 月に 刷新された公式のアプリアーキテクチャガイド に近く、最低限データアクセス部分を分離したレイヤー構成としました。 モノクロではない色付きの技術スタックが今回新たに導入したものになります。 次章からリニューアル開発で取り組んだことについて、詳しく書いていきます。 リニューアル開発で取り組んだこと リニューアル開発のアプリをリードしていく役割で意識的に取り組んだことは次の 3 つです。 未来像を描く PoC を作成する 期間と機能の折り合いをつける 未来像を描く 当たり前のことですが、リニューアル開発が最終的な自分たちのゴールではありません。 この点を意識しながら、最初に iOS アプリをリード したエンジニアの世嘉良さんとメドレーに合ったアプリ開発のあるべき姿を一緒に描きました。 ざっくりとした図ですが、202X 未来像をメンバーと共有できたのは良かったと思っています。 事業的な観点や技術的な視点から自分たちがこの先に向かいたい方向性が明確になりました。 私が入社したときからすでに Web、iOS、Android の 3 つのプラットフォームを横断するチーム体制だったこともあり、今後も横断しながら効率的に取り組める開発スタイルを目指しています。 最終的には、未来と現在を結ぶ通過点として今回のリニューアルを据え、期間や体制面などから実現可能な範囲を話し合って決めました。 当時、私は入社 2 ヶ月目でコードの理解がまだ浅かったので、認識ズレのギャップを埋めることにもこの図が役立ちました。 PoC を作成する 開発するメンバー間の経験差が気になるときや実現性に不安が残るときは、PoC（Proof of Concept）モデルとして 1 つ以上の主要な実装パターンを事前に検証しておくと不確実性を低減できます。 今回は自分がリードする立場であり、Android 開発経験が豊富なメンバーが揃ってガンガンと進めていける感じではなかったので、入念に事前準備してリニューアル開発に臨みました。 PoC で検証できた実装方針は、メンバーにも既存 1 画面の書き換えを試してもらい、実際に PR をレビューして本番環境へ投入しています。 5 年前のコードベースが多く残るアプリをどのように移行させるか検証は少し大変でしたが、この事前準備の甲斐あって、リニューアル開発の期間中は技術的な要素でハマることなくタスクに集中できました。 期間と機能の折り合いをつける PoC モデルを作成して技術的な実現性への不安を解消できましたが、リニューアル開発を進めていく期間と仕様面で、まだいくつかの不安要素は残っている状況でした。 私自身、入社 2 ヶ月目で既存の業務ロジックは一部しか把握できてない ⇒ 　業務の仕様を理解しながら新しい画面へ書き換えていくので時間かかるかも…🧑‍💻 要素しか決まっていない画面が多数あり、画面デザインが並行して進んでいた ⇒ 　どのタイミングで要素を取得するべきなのか、デザイン次第で変わりそう…🎨 協力会社から一緒に手伝ってくれる社外エンジニアの実力値が未知数だった ⇒ 　軽く感覚は掴んでもらったものの、良しなにタスクを進められるだろうか…🧗‍♀️ いくら経験を積んだエンジニアでも不確実性を多く含むタスクの工数は正確に見積もれません。 そこで、リニューアルに関するアプリの開発定例で「もし想定する期間に間に合わなかったときにどうするか？」という議題を提起しました。 当たり前の話になっちゃいますが、うまくいかないときに取る行動を全員が共通認識しておくことは大切だと思っています。結論の候補は次のどちらかになるのではないでしょうか。 リリース日を延ばして計画したリニューアルのタスクはすべてやりきる 一部機能を落としてリリース日はずらさない 今回のリニューアル開発では、後者にあたるリリース日を死守する結論になりました。 ただし、一部の機能を落とすのではなく、既存の旧画面をスタイル調整してでも機能は出したいという要望があり、この点を設計やスケジュールのタスク優先度に折り込みました。 12 月に無事リリースできた Android アプリの裏側には、事業サイドとのこのような合意がありました。 実際、予定外のことも起きて一部の機能はリニューアル後に回しましたが、取る行動を決めておいたことで終盤あたふたすることなく、安定したものをリリースできました。 これから ここまでお読みいただきありがとうございました。同じような立場でこれからリニューアル開発を進めていく方のヒントになったら幸いです。 コードは 1 行も載せていませんが、Android アプリ開発者なら図の構成でなんとなく想像が付くと思い、今回は進め方にフォーカスしてみました。 さて、患者アプリはリニューアルが無事完了し、モダンな技術スタックで効率良く開発できる状態になりましたが、まだまだ技術的な視点で取り組みたいことはたくさんあります。 Kotlin Multiplatform／Kotlin Multiplatform Mobile の活用[^1] ⇒ 　 iOS、Android（可能なら Web も）のロジック統合など生産性を上げる 宣言的 UI への移行（iOS はすでに SwiftUI） ⇒ 　 UI アーキテクチャ構成やコンポーネント化など UI の共通感覚を高める 一方、患者アプリのビジネス視点では、オンライン診療を主軸とした予約・フォローアップの体験向上が 1 つの役目になります。 私自身は、「オンライン診療の実施に当たっての基本理念[^2]」に沿った成長路線がより良い患者体験につながると考えています。 Ⅳ オンライン診療の実施に当たっての基本理念 ① 患者の日常生活の情報も得ることにより、医療の質のさらなる向上に結び付けていくこと ② 医療を必要とする患者に対して、医療に対するアクセシビリティ（アクセスの容易性）を確保し、よりよい医療を得られる機会を増やすこと ③ 患者が治療に能動的に参画することにより、治療の効果を最大化すること この基本理念の 3 項目をアプリが満たすべき姿としたのが次の 2 つの状態です。 医療を身近に行動できる状態（基本理念の ① と ③ に該当） ⇒ 　「探す」「知る」「伝える」といった行動手順の簡素化 必要とする人が適切に使えている状態（基本理念の ② に該当） ⇒ 　アクセシビリティへの配慮、分かりやすい UI（≒ ユニバーサルデザイン） このような領域に興味のあるエンジニアやデザイナーさんがおりましたら、ぜひお近くのメドレーへ。 医療ヘルスケアの未来を一緒につくりませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp 最後までお読みいただきありがとうございました。 [^1] Flutter や React Native といった選択肢もありますが、現時点では外部 SDK 含めた既存コードとの親和性や時間的な制約から段階的に移行できる技術を重視しています [^2] 厚生労働省が公開する「 オンライン診察の適切な実施に関する指針 10 ページ目 」より抜粋

はじめまして。医療プラットフォーム本部プロダクト開発室エンジニアの小形（ @ogaclejapan ）です。 普段は、オンライン診療・服薬指導アプリ「 CLINICS 」の開発を担当しています。 近々、転職の入社エントリーも会社の 公式 note に公開されますので、ぜひ読んでみてください。 さて、昨年 12 月に CLINICS アプリは UI のフルリニューアル を行いました。 少し経ちましたが、「 CLINICS アプリのリニューアルの裏側(iOS 編) 」に続く、Android 編ということで裏話を書いていきます。 コミットグラフから振り返るアプリ開発史 リニューアルを終えた直近のコミットグラフから CLINICS の Android 版アプリの歴史を振り返ると、大きく 4 つの時代を超えてきました。 立ち上げ期：2016/7 - 閑散期：2018/4 - 再始動期：2020/5 - リニューアル期： 2021/5 - 2021/12 1. 立ち上げ期 記念すべき PR#1 は、2016 年 7 月でした。すでにコミットグラフの表示期間外なのであまり詳しく追えていませんが、1〜2 名がメインで関わりつつ、他のエンジニアの方のコミットもちらほらとありました。 私のようにネイティブアプリ開発を中心に経験してきた人は、まだ社内に少ないですが、フロントエンドからバックエンドまで幅広くできる人がとても多いのも納得です。 実装は SmartUI と名がつけられた アンチパターンの ように、ネットワーク通信から画面の表示制御まで単一のファイル内にすべて書かれていました。 アプリ経験者不在の中で開発を続けてきたことに尊敬の念を抱きつつも、リニューアル開発で全面的にコードを書き直すまで色々なツラみがありました…。R.I.P. FatActivity 🛐 2. 閑散期 2018 年から約 2 年ほど開発がほぼ止まっていました。もともとオンライン診察機能のために開発された経緯があり、この期間は電子カルテのシステム開発にリソースを注力していたようです。 3. 再始動期 2020 年 5 月から再びアプリ開発は活発になり、オンライン服薬指導機能を提供する調剤薬局窓口支援システム「 Pharms 」と連携する開発などが 1〜2 名で行われていました。 2020 年度通期の 決算説明資料 を読んでみると、患者（≒ アプリ）を中心にプロダクトラインナップを増やしていく医療 PF 事業投資の図が初登場していました。 この事業計画に沿って、Pharms 連携やお薬手帳機能など患者向けアプリを強化する動きが加速し、2016 年から引き継がれてきた UI デザインや拡張性をゼロベースで見直すべく、翌年のリニューアル開発へ繋がっていきます。 余談ですが、今年の 2 月に歯科業務支援システム「 Dentis 」をリリースして、4 月からアプリとの連携も試験的に開始しています。 リニューアル開発が完了していたからこそ、新規プロダクトへの連携にもスムーズに対応できました。 4. リニューアル期 リニューアル開発は、2021 年 5 月下旬頃から本格的に実装を開始し、同年 12 月に無事リリースすることができました。 当初、Android アプリ開発メンバーの頭数が足りておらず、私と協力会社の社外エンジニアのみで進めていく状況でしたが、6 月途中からアプリ開発経験のある社内エンジニアが 1 名異動してきてくれたおかげでピーク時を乗り切れました。 リニューアル後のアプリ内モジュール構成と技術スタックはこんな感じです。 今年の 3 月に 刷新された公式のアプリアーキテクチャガイド に近く、最低限データアクセス部分を分離したレイヤー構成としました。 モノクロではない色付きの技術スタックが今回新たに導入したものになります。 次章からリニューアル開発で取り組んだことについて、詳しく書いていきます。 リニューアル開発で取り組んだこと リニューアル開発のアプリをリードしていく役割で意識的に取り組んだことは次の 3 つです。 未来像を描く PoC を作成する 期間と機能の折り合いをつける 未来像を描く 当たり前のことですが、リニューアル開発が最終的な自分たちのゴールではありません。 この点を意識しながら、最初に iOS アプリをリード したエンジニアの世嘉良さんとメドレーに合ったアプリ開発のあるべき姿を一緒に描きました。 ざっくりとした図ですが、202X 未来像をメンバーと共有できたのは良かったと思っています。 事業的な観点や技術的な視点から自分たちがこの先に向かいたい方向性が明確になりました。 私が入社したときからすでに Web、iOS、Android の 3 つのプラットフォームを横断するチーム体制だったこともあり、今後も横断しながら効率的に取り組める開発スタイルを目指しています。 最終的には、未来と現在を結ぶ通過点として今回のリニューアルを据え、期間や体制面などから実現可能な範囲を話し合って決めました。 当時、私は入社 2 ヶ月目でコードの理解がまだ浅かったので、認識ズレのギャップを埋めることにもこの図が役立ちました。 PoC を作成する 開発するメンバー間の経験差が気になるときや実現性に不安が残るときは、PoC（Proof of Concept）モデルとして 1 つ以上の主要な実装パターンを事前に検証しておくと不確実性を低減できます。 今回は自分がリードする立場であり、Android 開発経験が豊富なメンバーが揃ってガンガンと進めていける感じではなかったので、入念に事前準備してリニューアル開発に臨みました。 PoC で検証できた実装方針は、メンバーにも既存 1 画面の書き換えを試してもらい、実際に PR をレビューして本番環境へ投入しています。 5 年前のコードベースが多く残るアプリをどのように移行させるか検証は少し大変でしたが、この事前準備の甲斐あって、リニューアル開発の期間中は技術的な要素でハマることなくタスクに集中できました。 期間と機能の折り合いをつける PoC モデルを作成して技術的な実現性への不安を解消できましたが、リニューアル開発を進めていく期間と仕様面で、まだいくつかの不安要素は残っている状況でした。 私自身、入社 2 ヶ月目で既存の業務ロジックは一部しか把握できてない ⇒ 　業務の仕様を理解しながら新しい画面へ書き換えていくので時間かかるかも…🧑‍💻 要素しか決まっていない画面が多数あり、画面デザインが並行して進んでいた ⇒ 　どのタイミングで要素を取得するべきなのか、デザイン次第で変わりそう…🎨 協力会社から一緒に手伝ってくれる社外エンジニアの実力値が未知数だった ⇒ 　軽く感覚は掴んでもらったものの、良しなにタスクを進められるだろうか…🧗‍♀️ いくら経験を積んだエンジニアでも不確実性を多く含むタスクの工数は正確に見積もれません。 そこで、リニューアルに関するアプリの開発定例で「もし想定する期間に間に合わなかったときにどうするか？」という議題を提起しました。 当たり前の話になっちゃいますが、うまくいかないときに取る行動を全員が共通認識しておくことは大切だと思っています。結論の候補は次のどちらかになるのではないでしょうか。 リリース日を延ばして計画したリニューアルのタスクはすべてやりきる 一部機能を落としてリリース日はずらさない 今回のリニューアル開発では、後者にあたるリリース日を死守する結論になりました。 ただし、一部の機能を落とすのではなく、既存の旧画面をスタイル調整してでも機能は出したいという要望があり、この点を設計やスケジュールのタスク優先度に折り込みました。 12 月に無事リリースできた Android アプリの裏側には、事業サイドとのこのような合意がありました。 実際、予定外のことも起きて一部の機能はリニューアル後に回しましたが、取る行動を決めておいたことで終盤あたふたすることなく、安定したものをリリースできました。 これから ここまでお読みいただきありがとうございました。同じような立場でこれからリニューアル開発を進めていく方のヒントになったら幸いです。 コードは 1 行も載せていませんが、Android アプリ開発者なら図の構成でなんとなく想像が付くと思い、今回は進め方にフォーカスしてみました。 さて、患者アプリはリニューアルが無事完了し、モダンな技術スタックで効率良く開発できる状態になりましたが、まだまだ技術的な視点で取り組みたいことはたくさんあります。 Kotlin Multiplatform／Kotlin Multiplatform Mobile の活用[^1] ⇒ 　 iOS、Android（可能なら Web も）のロジック統合など生産性を上げる 宣言的 UI への移行（iOS はすでに SwiftUI） ⇒ 　 UI アーキテクチャ構成やコンポーネント化など UI の共通感覚を高める 一方、患者アプリのビジネス視点では、オンライン診療を主軸とした予約・フォローアップの体験向上が 1 つの役目になります。 私自身は、「オンライン診療の実施に当たっての基本理念[^2]」に沿った成長路線がより良い患者体験につながると考えています。 Ⅳ オンライン診療の実施に当たっての基本理念 ① 患者の日常生活の情報も得ることにより、医療の質のさらなる向上に結び付けていくこと ② 医療を必要とする患者に対して、医療に対するアクセシビリティ（アクセスの容易性）を確保し、よりよい医療を得られる機会を増やすこと ③ 患者が治療に能動的に参画することにより、治療の効果を最大化すること この基本理念の 3 項目をアプリが満たすべき姿としたのが次の 2 つの状態です。 医療を身近に行動できる状態（基本理念の ① と ③ に該当） ⇒ 　「探す」「知る」「伝える」といった行動手順の簡素化 必要とする人が適切に使えている状態（基本理念の ② に該当） ⇒ 　アクセシビリティへの配慮、分かりやすい UI（≒ ユニバーサルデザイン） このような領域に興味のあるエンジニアやデザイナーさんがおりましたら、ぜひお近くのメドレーへ。 医療ヘルスケアの未来を一緒につくりませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp 最後までお読みいただきありがとうございました。 [^1] Flutter や React Native といった選択肢もありますが、現時点では外部 SDK 含めた既存コードとの親和性や時間的な制約から段階的に移行できる技術を重視しています [^2] 厚生労働省が公開する「 オンライン診察の適切な実施に関する指針 10 ページ目 」より抜粋

はじめまして。医療プラットフォーム本部プロダクト開発室エンジニアの小形（ @ogaclejapan ）です。 普段は、オンライン診療・服薬指導アプリ「 CLINICS 」の開発を担当しています。 近々、転職の入社エントリーも会社の 公式 note に公開されますので、ぜひ読んでみてください。 さて、昨年 12 月に CLINICS アプリは UI のフルリニューアル を行いました。 少し経ちましたが、「 CLINICS アプリのリニューアルの裏側(iOS 編) 」に続く、Android 編ということで裏話を書いていきます。 コミットグラフから振り返るアプリ開発史 リニューアルを終えた直近のコミットグラフから CLINICS の Android 版アプリの歴史を振り返ると、大きく 4 つの時代を超えてきました。 立ち上げ期：2016/7 - 閑散期：2018/4 - 再始動期：2020/5 - リニューアル期： 2021/5 - 2021/12 1. 立ち上げ期 記念すべき PR#1 は、2016 年 7 月でした。すでにコミットグラフの表示期間外なのであまり詳しく追えていませんが、1〜2 名がメインで関わりつつ、他のエンジニアの方のコミットもちらほらとありました。 私のようにネイティブアプリ開発を中心に経験してきた人は、まだ社内に少ないですが、フロントエンドからバックエンドまで幅広くできる人がとても多いのも納得です。 実装は SmartUI と名がつけられた アンチパターンの ように、ネットワーク通信から画面の表示制御まで単一のファイル内にすべて書かれていました。 アプリ経験者不在の中で開発を続けてきたことに尊敬の念を抱きつつも、リニューアル開発で全面的にコードを書き直すまで色々なツラみがありました…。R.I.P. FatActivity 🛐 2. 閑散期 2018 年から約 2 年ほど開発がほぼ止まっていました。もともとオンライン診察機能のために開発された経緯があり、この期間は電子カルテのシステム開発にリソースを注力していたようです。 3. 再始動期 2020 年 5 月から再びアプリ開発は活発になり、オンライン服薬指導機能を提供する調剤薬局窓口支援システム「 Pharms 」と連携する開発などが 1〜2 名で行われていました。 2020 年度通期の 決算説明資料 を読んでみると、患者（≒ アプリ）を中心にプロダクトラインナップを増やしていく医療 PF 事業投資の図が初登場していました。 この事業計画に沿って、Pharms 連携やお薬手帳機能など患者向けアプリを強化する動きが加速し、2016 年から引き継がれてきた UI デザインや拡張性をゼロベースで見直すべく、翌年のリニューアル開発へ繋がっていきます。 余談ですが、今年の 2 月に歯科業務支援システム「 Dentis 」をリリースして、4 月からアプリとの連携も試験的に開始しています。 リニューアル開発が完了していたからこそ、新規プロダクトへの連携にもスムーズに対応できました。 4. リニューアル期 リニューアル開発は、2021 年 5 月下旬頃から本格的に実装を開始し、同年 12 月に無事リリースすることができました。 当初、Android アプリ開発メンバーの頭数が足りておらず、私と協力会社の社外エンジニアのみで進めていく状況でしたが、6 月途中からアプリ開発経験のある社内エンジニアが 1 名異動してきてくれたおかげでピーク時を乗り切れました。 リニューアル後のアプリ内モジュール構成と技術スタックはこんな感じです。 今年の 3 月に 刷新された公式のアプリアーキテクチャガイド に近く、最低限データアクセス部分を分離したレイヤー構成としました。 モノクロではない色付きの技術スタックが今回新たに導入したものになります。 次章からリニューアル開発で取り組んだことについて、詳しく書いていきます。 リニューアル開発で取り組んだこと リニューアル開発のアプリをリードしていく役割で意識的に取り組んだことは次の 3 つです。 未来像を描く PoC を作成する 期間と機能の折り合いをつける 未来像を描く 当たり前のことですが、リニューアル開発が最終的な自分たちのゴールではありません。 この点を意識しながら、最初に iOS アプリをリード したエンジニアの世嘉良さんとメドレーに合ったアプリ開発のあるべき姿を一緒に描きました。 ざっくりとした図ですが、202X 未来像をメンバーと共有できたのは良かったと思っています。 事業的な観点や技術的な視点から自分たちがこの先に向かいたい方向性が明確になりました。 私が入社したときからすでに Web、iOS、Android の 3 つのプラットフォームを横断するチーム体制だったこともあり、今後も横断しながら効率的に取り組める開発スタイルを目指しています。 最終的には、未来と現在を結ぶ通過点として今回のリニューアルを据え、期間や体制面などから実現可能な範囲を話し合って決めました。 当時、私は入社 2 ヶ月目でコードの理解がまだ浅かったので、認識ズレのギャップを埋めることにもこの図が役立ちました。 PoC を作成する 開発するメンバー間の経験差が気になるときや実現性に不安が残るときは、PoC（Proof of Concept）モデルとして 1 つ以上の主要な実装パターンを事前に検証しておくと不確実性を低減できます。 今回は自分がリードする立場であり、Android 開発経験が豊富なメンバーが揃ってガンガンと進めていける感じではなかったので、入念に事前準備してリニューアル開発に臨みました。 PoC で検証できた実装方針は、メンバーにも既存 1 画面の書き換えを試してもらい、実際に PR をレビューして本番環境へ投入しています。 5 年前のコードベースが多く残るアプリをどのように移行させるか検証は少し大変でしたが、この事前準備の甲斐あって、リニューアル開発の期間中は技術的な要素でハマることなくタスクに集中できました。 期間と機能の折り合いをつける PoC モデルを作成して技術的な実現性への不安を解消できましたが、リニューアル開発を進めていく期間と仕様面で、まだいくつかの不安要素は残っている状況でした。 私自身、入社 2 ヶ月目で既存の業務ロジックは一部しか把握できてない ⇒ 　業務の仕様を理解しながら新しい画面へ書き換えていくので時間かかるかも…🧑‍💻 要素しか決まっていない画面が多数あり、画面デザインが並行して進んでいた ⇒ 　どのタイミングで要素を取得するべきなのか、デザイン次第で変わりそう…🎨 協力会社から一緒に手伝ってくれる社外エンジニアの実力値が未知数だった ⇒ 　軽く感覚は掴んでもらったものの、良しなにタスクを進められるだろうか…🧗‍♀️ いくら経験を積んだエンジニアでも不確実性を多く含むタスクの工数は正確に見積もれません。 そこで、リニューアルに関するアプリの開発定例で「もし想定する期間に間に合わなかったときにどうするか？」という議題を提起しました。 当たり前の話になっちゃいますが、うまくいかないときに取る行動を全員が共通認識しておくことは大切だと思っています。結論の候補は次のどちらかになるのではないでしょうか。 リリース日を延ばして計画したリニューアルのタスクはすべてやりきる 一部機能を落としてリリース日はずらさない 今回のリニューアル開発では、後者にあたるリリース日を死守する結論になりました。 ただし、一部の機能を落とすのではなく、既存の旧画面をスタイル調整してでも機能は出したいという要望があり、この点を設計やスケジュールのタスク優先度に折り込みました。 12 月に無事リリースできた Android アプリの裏側には、事業サイドとのこのような合意がありました。 実際、予定外のことも起きて一部の機能はリニューアル後に回しましたが、取る行動を決めておいたことで終盤あたふたすることなく、安定したものをリリースできました。 これから ここまでお読みいただきありがとうございました。同じような立場でこれからリニューアル開発を進めていく方のヒントになったら幸いです。 コードは 1 行も載せていませんが、Android アプリ開発者なら図の構成でなんとなく想像が付くと思い、今回は進め方にフォーカスしてみました。 さて、患者アプリはリニューアルが無事完了し、モダンな技術スタックで効率良く開発できる状態になりましたが、まだまだ技術的な視点で取り組みたいことはたくさんあります。 Kotlin Multiplatform／Kotlin Multiplatform Mobile の活用[^1] ⇒ 　 iOS、Android（可能なら Web も）のロジック統合など生産性を上げる 宣言的 UI への移行（iOS はすでに SwiftUI） ⇒ 　 UI アーキテクチャ構成やコンポーネント化など UI の共通感覚を高める 一方、患者アプリのビジネス視点では、オンライン診療を主軸とした予約・フォローアップの体験向上が 1 つの役目になります。 私自身は、「オンライン診療の実施に当たっての基本理念[^2]」に沿った成長路線がより良い患者体験につながると考えています。 Ⅳ オンライン診療の実施に当たっての基本理念 ① 患者の日常生活の情報も得ることにより、医療の質のさらなる向上に結び付けていくこと ② 医療を必要とする患者に対して、医療に対するアクセシビリティ（アクセスの容易性）を確保し、よりよい医療を得られる機会を増やすこと ③ 患者が治療に能動的に参画することにより、治療の効果を最大化すること この基本理念の 3 項目をアプリが満たすべき姿としたのが次の 2 つの状態です。 医療を身近に行動できる状態（基本理念の ① と ③ に該当） ⇒ 　「探す」「知る」「伝える」といった行動手順の簡素化 必要とする人が適切に使えている状態（基本理念の ② に該当） ⇒ 　アクセシビリティへの配慮、分かりやすい UI（≒ ユニバーサルデザイン） このような領域に興味のあるエンジニアやデザイナーさんがおりましたら、ぜひお近くのメドレーへ。 医療ヘルスケアの未来を一緒につくりませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp 最後までお読みいただきありがとうございました。 [^1] Flutter や React Native といった選択肢もありますが、現時点では外部 SDK 含めた既存コードとの親和性や時間的な制約から段階的に移行できる技術を重視しています [^2] 厚生労働省が公開する「 オンライン診察の適切な実施に関する指針 10 ページ目 」より抜粋

はじめに こんにちは。技術広報・エンジニアの平木です。最近使っている 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 エンジニアの方はもちろん、その他プロダクトを作るということに関わる方はぜひ、アーカイブを視聴してみてください!

はじめに こんにちは。技術広報・エンジニアの平木です。最近使っている 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 のリニューアルについて書かせていただきました。 引き続き、情報発信などをしていきメドレー開発組織について、皆さんに知っていただければと思います。 最後になりますが、医療ヘルスケアのプロダクト開発に(このようなブログ製作も)関わっていきたい!という方はぜひ下記よりご応募お待ちしております! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 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