はじめに みなさん、こんにちは。医療プラットフォーム本部プロダクト開発室第三開発グループ グループマネージャの太田です。レセコン（電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア）新規開発プロジェクトでレセコンの開発を行っています。 2021 年 9 月 1 日に Tech Studio MATSUE オフィス（以下松江オフィス）が設立された際、他の初期メンバー 4 人と一緒にメドレーに入社しました。 記事を読み終わられた際は、1 人でも多くの方が松江オフィスに興味を持っていただけると嬉しいです。 松江オフィスでやっていること 松江オフィスではレセコン新規開発プロジェクトとして、 CLINICS カルテ に内包されるレセコン部分の開発を Ruby on Rails で行っています。 医療機関でどちらも使われるものですが、電子カルテがドクター向けのアプリケーションなのに対して、レセコンは事務員さん向けのアプリケーションとなります。 レセコンでは電子カルテに登録された診療内容を元に診療報酬の計算を行い、日々の業務としては請求書兼領収書、診療費明細書、処方箋、日報の作成を行い、月次の業務としては、保険者に対しての請求データの作成などの処理を行っています。診療報酬とは我々が医療機関を受診した際に受けた医療行為について、その対価として医療機関に支払われる費用です。医療行為１つ１つに点数が設定されており、この点数を「1 点=10 円」として診療報酬の計算を行います。 電子カルテとレセコンの関連性は強く、2 つのアプリケーションが近い関係であればあるほど、CLINICS の顧客に対してより価値の高いサービスの提供が可能となります。 これらの問題を解決すべく、 Sustainable （維持し続けられる）、Reasonable （合理的である）、Improvable （改善し続ける）、Manageable （管理しやすい）を基本コンセプトにレセコン新規開発プロジェクトが始まり松江でレセコンの開発が行われることになりました。 アプリケーション側で使いやすい API の開発を効率的に進めています。これには、アプリケーション側の開発チームとの関係強化が必須です。このため、東京の CLINICS チームとは日々 Slack や Google Meet などを通じて密に連絡を取り合いながら相互理解に努めることで、信頼関係を強化し、効率的に開発ができるよう取り組んでいます。 松江オフィスで利用してる技術 サービスのバックエンドということもあり、特別な技術スタックは使用せずオーソドックスに Ruby on Rails、MySQL を利用しています。 インフラも同様でサービスがスケールすることを念頭において AWS を利用しています。また IaC として Terraform を利用しています。 各人の開発環境も GitHub や Docker といった極めて一般的なものを採用しています。 新人を除く 5 人は元々別の会社において新規レセコンとは異なるレセコンの開発に携わっていました。当時は COBOL で開発を行っていましたが、レガシーな言語ゆえ、冗長的なコードになったり、同じようなロジックが複数のコードに存在していたりとメンテナンスに大変苦労していました。 現在は Ruby で開発を行っており、Ruby なりの難しさはありますが、 COBOL で同じコードを書いたら 5 倍の量になるなと感じるくらい、当時と比べると開発コストは大幅に下がっていると実感しています。 松江オフィスの雰囲気・文化 松江オフィスがある松江市は中海、宍道湖と大きな湖を 2 つもつことで水の都と言われています。この 2 つの湖を結ぶ大橋川ではシーバス釣りが盛んです。 年に 1 回秋頃にレガッタの大会が行われ、弊社のメンバーもチーム TAGBORTS として参加しています（まだオフィスのメンバーだけではチームが組めないため助っ人をお願いしている状況です…）。去年は 2 回戦敗退と悔しい結果となりましたが、今年は更に上を目指したいと思います。 松江オフィスは事務所のような雰囲気は一切なく、都会的なデザインとなっています。内装は設計・施工を行っていただきました トレイルヘッズ様の HP にてご確認いただくことが可能です。 開発用デスクは周囲が気にならないようにパーティションを設置しています。椅子にはアーロンチェアを採用しており、長時間の作業で体に負担がかからないよう配慮されています。 東京オフィスとのコミュニケーションは Google Meet か Slack がメインのため、電話がかかってくることもなく、集中して開発に取り組むことができる環境となっています。 現在エンジニア 5 名、ディレクター 1 名の計 6 名が在籍しています。 松江オフィスではレセコンに関する業務的な質問や Ruby に関するロジック的な質問など誰とでも気兼ねなく行うことができるように、メンバー間のコミュニケーションが取りやすい環境づくりを心がけています。例えば、今年からの取り組みですが、毎日 10 分程度の朝会を行うようにしました。会の目的としては進捗の遅れや、詰まってることなどを話すきっかけづくりです。 レセコン開発の性質上、エンジニアも診療報酬の知識のインプットが必要です。このため、ディレクターを中心に診療報酬の勉強会も行っています。 以前開発していたレセコンを超えるレセコンを作り上げる。それがメンバーの共通の目標です。 松江オフィスでこんな人と働きたい 以下に当てはまる方、大募集中です。 プログラミング（技術）が大好きで、それを手段として課題に対して積極的に行動できる Our Essentials に共感できる 医療業界に革新を起こす壮大なミッションにチャレンジしてみたい 下記のリンクからご応募お待ちしています。 中途採用は こちら 2024 年度新卒採用は こちら おわりに 簡単ですが、松江オフィスの紹介をさせていただきました。 今後も松江オフィスのメンバー一丸となって レセコン の開発を進め、CLINICS チームと協力して稼働医療機関を増やしていき、より患者が医療にアクセスしやすい環境が作れるように取り組んでいきます！

はじめに みなさん、こんにちは。医療プラットフォーム本部プロダクト開発室第三開発グループ グループマネージャの太田です。レセコン（電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア）新規開発プロジェクトでレセコンの開発を行っています。 2021 年 9 月 1 日に Tech Studio MATSUE オフィス（以下松江オフィス）が設立された際、他の初期メンバー 4 人と一緒にメドレーに入社しました。 記事を読み終わられた際は、1 人でも多くの方が松江オフィスに興味を持っていただけると嬉しいです。 松江オフィスでやっていること 松江オフィスではレセコン新規開発プロジェクトとして、 CLINICS カルテ に内包されるレセコン部分の開発を Ruby on Rails で行っています。 医療機関でどちらも使われるものですが、電子カルテがドクター向けのアプリケーションなのに対して、レセコンは事務員さん向けのアプリケーションとなります。 レセコンでは電子カルテに登録された診療内容を元に診療報酬の計算を行い、日々の業務としては請求書兼領収書、診療費明細書、処方箋、日報の作成を行い、月次の業務としては、保険者に対しての請求データの作成などの処理を行っています。診療報酬とは我々が医療機関を受診した際に受けた医療行為について、その対価として医療機関に支払われる費用です。医療行為１つ１つに点数が設定されており、この点数を「1 点=10 円」として診療報酬の計算を行います。 電子カルテとレセコンの関連性は強く、2 つのアプリケーションが近い関係であればあるほど、CLINICS の顧客に対してより価値の高いサービスの提供が可能となります。 これらの問題を解決すべく、 Sustainable （維持し続けられる）、Reasonable （合理的である）、Improvable （改善し続ける）、Manageable （管理しやすい）を基本コンセプトにレセコン新規開発プロジェクトが始まり松江でレセコンの開発が行われることになりました。 アプリケーション側で使いやすい API の開発を効率的に進めています。これには、アプリケーション側の開発チームとの関係強化が必須です。このため、東京の CLINICS チームとは日々 Slack や Google Meet などを通じて密に連絡を取り合いながら相互理解に努めることで、信頼関係を強化し、効率的に開発ができるよう取り組んでいます。 松江オフィスで利用してる技術 サービスのバックエンドということもあり、特別な技術スタックは使用せずオーソドックスに Ruby on Rails、MySQL を利用しています。 インフラも同様でサービスがスケールすることを念頭において AWS を利用しています。また IaC として Terraform を利用しています。 各人の開発環境も GitHub や Docker といった極めて一般的なものを採用しています。 新人を除く 5 人は元々別の会社において新規レセコンとは異なるレセコンの開発に携わっていました。当時は COBOL で開発を行っていましたが、レガシーな言語ゆえ、冗長的なコードになったり、同じようなロジックが複数のコードに存在していたりとメンテナンスに大変苦労していました。 現在は Ruby で開発を行っており、Ruby なりの難しさはありますが、 COBOL で同じコードを書いたら 5 倍の量になるなと感じるくらい、当時と比べると開発コストは大幅に下がっていると実感しています。 松江オフィスの雰囲気・文化 松江オフィスがある松江市は中海、宍道湖と大きな湖を 2 つもつことで水の都と言われています。この 2 つの湖を結ぶ大橋川ではシーバス釣りが盛んです。 年に 1 回秋頃にレガッタの大会が行われ、弊社のメンバーもチーム TAGBORTS として参加しています（まだオフィスのメンバーだけではチームが組めないため助っ人をお願いしている状況です…）。去年は 2 回戦敗退と悔しい結果となりましたが、今年は更に上を目指したいと思います。 松江オフィスは事務所のような雰囲気は一切なく、都会的なデザインとなっています。内装は設計・施工を行っていただきました トレイルヘッズ様の HP にてご確認いただくことが可能です。 開発用デスクは周囲が気にならないようにパーティションを設置しています。椅子にはアーロンチェアを採用しており、長時間の作業で体に負担がかからないよう配慮されています。 東京オフィスとのコミュニケーションは Google Meet か Slack がメインのため、電話がかかってくることもなく、集中して開発に取り組むことができる環境となっています。 現在エンジニア 5 名、ディレクター 1 名の計 6 名が在籍しています。 松江オフィスではレセコンに関する業務的な質問や Ruby に関するロジック的な質問など誰とでも気兼ねなく行うことができるように、メンバー間のコミュニケーションが取りやすい環境づくりを心がけています。例えば、今年からの取り組みですが、毎日 10 分程度の朝会を行うようにしました。会の目的としては進捗の遅れや、詰まってることなどを話すきっかけづくりです。 レセコン開発の性質上、エンジニアも診療報酬の知識のインプットが必要です。このため、ディレクターを中心に診療報酬の勉強会も行っています。 以前開発していたレセコンを超えるレセコンを作り上げる。それがメンバーの共通の目標です。 松江オフィスでこんな人と働きたい 以下に当てはまる方、大募集中です。 プログラミング（技術）が大好きで、それを手段として課題に対して積極的に行動できる Our Essentials に共感できる 医療業界に革新を起こす壮大なミッションにチャレンジしてみたい 下記のリンクからご応募お待ちしています。 中途採用は こちら 2024 年度新卒採用は こちら おわりに 簡単ですが、松江オフィスの紹介をさせていただきました。 今後も松江オフィスのメンバー一丸となって レセコン の開発を進め、CLINICS チームと協力して稼働医療機関を増やしていき、より患者が医療にアクセスしやすい環境が作れるように取り組んでいきます！

はじめに みなさん、こんにちは。医療プラットフォーム本部プロダクト開発室第三開発グループ グループマネージャの太田です。レセコン（電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア）新規開発プロジェクトでレセコンの開発を行っています。 2021 年 9 月 1 日に Tech Studio MATSUE オフィス（以下松江オフィス）が設立された際、他の初期メンバー 4 人と一緒にメドレーに入社しました。 記事を読み終わられた際は、1 人でも多くの方が松江オフィスに興味を持っていただけると嬉しいです。 松江オフィスでやっていること 松江オフィスではレセコン新規開発プロジェクトとして、 CLINICS カルテ に内包されるレセコン部分の開発を Ruby on Rails で行っています。 医療機関でどちらも使われるものですが、電子カルテがドクター向けのアプリケーションなのに対して、レセコンは事務員さん向けのアプリケーションとなります。 レセコンでは電子カルテに登録された診療内容を元に診療報酬の計算を行い、日々の業務としては請求書兼領収書、診療費明細書、処方箋、日報の作成を行い、月次の業務としては、保険者に対しての請求データの作成などの処理を行っています。診療報酬とは我々が医療機関を受診した際に受けた医療行為について、その対価として医療機関に支払われる費用です。医療行為１つ１つに点数が設定されており、この点数を「1 点=10 円」として診療報酬の計算を行います。 電子カルテとレセコンの関連性は強く、2 つのアプリケーションが近い関係であればあるほど、CLINICS の顧客に対してより価値の高いサービスの提供が可能となります。 これらの問題を解決すべく、 Sustainable （維持し続けられる）、Reasonable （合理的である）、Improvable （改善し続ける）、Manageable （管理しやすい）を基本コンセプトにレセコン新規開発プロジェクトが始まり松江でレセコンの開発が行われることになりました。 アプリケーション側で使いやすい API の開発を効率的に進めています。これには、アプリケーション側の開発チームとの関係強化が必須です。このため、東京の CLINICS チームとは日々 Slack や Google Meet などを通じて密に連絡を取り合いながら相互理解に努めることで、信頼関係を強化し、効率的に開発ができるよう取り組んでいます。 松江オフィスで利用してる技術 サービスのバックエンドということもあり、特別な技術スタックは使用せずオーソドックスに Ruby on Rails、MySQL を利用しています。 インフラも同様でサービスがスケールすることを念頭において AWS を利用しています。また IaC として Terraform を利用しています。 各人の開発環境も GitHub や Docker といった極めて一般的なものを採用しています。 新人を除く 5 人は元々別の会社において新規レセコンとは異なるレセコンの開発に携わっていました。当時は COBOL で開発を行っていましたが、レガシーな言語ゆえ、冗長的なコードになったり、同じようなロジックが複数のコードに存在していたりとメンテナンスに大変苦労していました。 現在は Ruby で開発を行っており、Ruby なりの難しさはありますが、 COBOL で同じコードを書いたら 5 倍の量になるなと感じるくらい、当時と比べると開発コストは大幅に下がっていると実感しています。 松江オフィスの雰囲気・文化 松江オフィスがある松江市は中海、宍道湖と大きな湖を 2 つもつことで水の都と言われています。この 2 つの湖を結ぶ大橋川ではシーバス釣りが盛んです。 年に 1 回秋頃にレガッタの大会が行われ、弊社のメンバーもチーム TAGBORTS として参加しています（まだオフィスのメンバーだけではチームが組めないため助っ人をお願いしている状況です…）。去年は 2 回戦敗退と悔しい結果となりましたが、今年は更に上を目指したいと思います。 松江オフィスは事務所のような雰囲気は一切なく、都会的なデザインとなっています。内装は設計・施工を行っていただきました トレイルヘッズ様の HP にてご確認いただくことが可能です。 開発用デスクは周囲が気にならないようにパーティションを設置しています。椅子にはアーロンチェアを採用しており、長時間の作業で体に負担がかからないよう配慮されています。 東京オフィスとのコミュニケーションは Google Meet か Slack がメインのため、電話がかかってくることもなく、集中して開発に取り組むことができる環境となっています。 現在エンジニア 5 名、ディレクター 1 名の計 6 名が在籍しています。 松江オフィスではレセコンに関する業務的な質問や Ruby に関するロジック的な質問など誰とでも気兼ねなく行うことができるように、メンバー間のコミュニケーションが取りやすい環境づくりを心がけています。例えば、今年からの取り組みですが、毎日 10 分程度の朝会を行うようにしました。会の目的としては進捗の遅れや、詰まってることなどを話すきっかけづくりです。 レセコン開発の性質上、エンジニアも診療報酬の知識のインプットが必要です。このため、ディレクターを中心に診療報酬の勉強会も行っています。 以前開発していたレセコンを超えるレセコンを作り上げる。それがメンバーの共通の目標です。 松江オフィスでこんな人と働きたい 以下に当てはまる方、大募集中です。 プログラミング（技術）が大好きで、それを手段として課題に対して積極的に行動できる Our Essentials に共感できる 医療業界に革新を起こす壮大なミッションにチャレンジしてみたい 下記のリンクからご応募お待ちしています。 中途採用は こちら 2024 年度新卒採用は こちら おわりに 簡単ですが、松江オフィスの紹介をさせていただきました。 今後も松江オフィスのメンバー一丸となって レセコン の開発を進め、CLINICS チームと協力して稼働医療機関を増やしていき、より患者が医療にアクセスしやすい環境が作れるように取り組んでいきます！

はじめに みなさん、こんにちは。医療プラットフォーム本部プロダクト開発室第三開発グループ グループマネージャの太田です。レセコン（電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア）新規開発プロジェクトでレセコンの開発を行っています。 2021 年 9 月 1 日に Tech Studio MATSUE オフィス（以下松江オフィス）が設立された際、他の初期メンバー 4 人と一緒にメドレーに入社しました。 記事を読み終わられた際は、1 人でも多くの方が松江オフィスに興味を持っていただけると嬉しいです。 松江オフィスでやっていること 松江オフィスではレセコン新規開発プロジェクトとして、 CLINICS カルテ に内包されるレセコン部分の開発を Ruby on Rails で行っています。 医療機関でどちらも使われるものですが、電子カルテがドクター向けのアプリケーションなのに対して、レセコンは事務員さん向けのアプリケーションとなります。 レセコンでは電子カルテに登録された診療内容を元に診療報酬の計算を行い、日々の業務としては請求書兼領収書、診療費明細書、処方箋、日報の作成を行い、月次の業務としては、保険者に対しての請求データの作成などの処理を行っています。診療報酬とは我々が医療機関を受診した際に受けた医療行為について、その対価として医療機関に支払われる費用です。医療行為１つ１つに点数が設定されており、この点数を「1 点=10 円」として診療報酬の計算を行います。 電子カルテとレセコンの関連性は強く、2 つのアプリケーションが近い関係であればあるほど、CLINICS の顧客に対してより価値の高いサービスの提供が可能となります。 これらの問題を解決すべく、 Sustainable （維持し続けられる）、Reasonable （合理的である）、Improvable （改善し続ける）、Manageable （管理しやすい）を基本コンセプトにレセコン新規開発プロジェクトが始まり松江でレセコンの開発が行われることになりました。 アプリケーション側で使いやすい API の開発を効率的に進めています。これには、アプリケーション側の開発チームとの関係強化が必須です。このため、東京の CLINICS チームとは日々 Slack や Google Meet などを通じて密に連絡を取り合いながら相互理解に努めることで、信頼関係を強化し、効率的に開発ができるよう取り組んでいます。 松江オフィスで利用してる技術 サービスのバックエンドということもあり、特別な技術スタックは使用せずオーソドックスに Ruby on Rails、MySQL を利用しています。 インフラも同様でサービスがスケールすることを念頭において AWS を利用しています。また IaC として Terraform を利用しています。 各人の開発環境も GitHub や Docker といった極めて一般的なものを採用しています。 新人を除く 5 人は元々別の会社において新規レセコンとは異なるレセコンの開発に携わっていました。当時は COBOL で開発を行っていましたが、レガシーな言語ゆえ、冗長的なコードになったり、同じようなロジックが複数のコードに存在していたりとメンテナンスに大変苦労していました。 現在は Ruby で開発を行っており、Ruby なりの難しさはありますが、 COBOL で同じコードを書いたら 5 倍の量になるなと感じるくらい、当時と比べると開発コストは大幅に下がっていると実感しています。 松江オフィスの雰囲気・文化 松江オフィスがある松江市は中海、宍道湖と大きな湖を 2 つもつことで水の都と言われています。この 2 つの湖を結ぶ大橋川ではシーバス釣りが盛んです。 年に 1 回秋頃にレガッタの大会が行われ、弊社のメンバーもチーム TAGBORTS として参加しています（まだオフィスのメンバーだけではチームが組めないため助っ人をお願いしている状況です…）。去年は 2 回戦敗退と悔しい結果となりましたが、今年は更に上を目指したいと思います。 松江オフィスは事務所のような雰囲気は一切なく、都会的なデザインとなっています。内装は設計・施工を行っていただきました トレイルヘッズ様の HP にてご確認いただくことが可能です。 開発用デスクは周囲が気にならないようにパーティションを設置しています。椅子にはアーロンチェアを採用しており、長時間の作業で体に負担がかからないよう配慮されています。 東京オフィスとのコミュニケーションは Google Meet か Slack がメインのため、電話がかかってくることもなく、集中して開発に取り組むことができる環境となっています。 現在エンジニア 5 名、ディレクター 1 名の計 6 名が在籍しています。 松江オフィスではレセコンに関する業務的な質問や Ruby に関するロジック的な質問など誰とでも気兼ねなく行うことができるように、メンバー間のコミュニケーションが取りやすい環境づくりを心がけています。例えば、今年からの取り組みですが、毎日 10 分程度の朝会を行うようにしました。会の目的としては進捗の遅れや、詰まってることなどを話すきっかけづくりです。 レセコン開発の性質上、エンジニアも診療報酬の知識のインプットが必要です。このため、ディレクターを中心に診療報酬の勉強会も行っています。 以前開発していたレセコンを超えるレセコンを作り上げる。それがメンバーの共通の目標です。 松江オフィスでこんな人と働きたい 以下に当てはまる方、大募集中です。 プログラミング（技術）が大好きで、それを手段として課題に対して積極的に行動できる Our Essentials に共感できる 医療業界に革新を起こす壮大なミッションにチャレンジしてみたい 下記のリンクからご応募お待ちしています。 中途採用は こちら 2024 年度新卒採用は こちら おわりに 簡単ですが、松江オフィスの紹介をさせていただきました。 今後も松江オフィスのメンバー一丸となって レセコン の開発を進め、CLINICS チームと協力して稼働医療機関を増やしていき、より患者が医療にアクセスしやすい環境が作れるように取り組んでいきます！

はじめに みなさん、こんにちは。医療プラットフォーム本部プロダクト開発室第三開発グループ グループマネージャの太田です。レセコン（電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア）新規開発プロジェクトでレセコンの開発を行っています。 2021 年 9 月 1 日に Tech Studio MATSUE オフィス（以下松江オフィス）が設立された際、他の初期メンバー 4 人と一緒にメドレーに入社しました。 記事を読み終わられた際は、1 人でも多くの方が松江オフィスに興味を持っていただけると嬉しいです。 松江オフィスでやっていること 松江オフィスではレセコン新規開発プロジェクトとして、 CLINICS カルテ に内包されるレセコン部分の開発を Ruby on Rails で行っています。 医療機関でどちらも使われるものですが、電子カルテがドクター向けのアプリケーションなのに対して、レセコンは事務員さん向けのアプリケーションとなります。 レセコンでは電子カルテに登録された診療内容を元に診療報酬の計算を行い、日々の業務としては請求書兼領収書、診療費明細書、処方箋、日報の作成を行い、月次の業務としては、保険者に対しての請求データの作成などの処理を行っています。診療報酬とは我々が医療機関を受診した際に受けた医療行為について、その対価として医療機関に支払われる費用です。医療行為１つ１つに点数が設定されており、この点数を「1 点=10 円」として診療報酬の計算を行います。 電子カルテとレセコンの関連性は強く、2 つのアプリケーションが近い関係であればあるほど、CLINICS の顧客に対してより価値の高いサービスの提供が可能となります。 これらの問題を解決すべく、 Sustainable （維持し続けられる）、Reasonable （合理的である）、Improvable （改善し続ける）、Manageable （管理しやすい）を基本コンセプトにレセコン新規開発プロジェクトが始まり松江でレセコンの開発が行われることになりました。 アプリケーション側で使いやすい API の開発を効率的に進めています。これには、アプリケーション側の開発チームとの関係強化が必須です。このため、東京の CLINICS チームとは日々 Slack や Google Meet などを通じて密に連絡を取り合いながら相互理解に努めることで、信頼関係を強化し、効率的に開発ができるよう取り組んでいます。 松江オフィスで利用してる技術 サービスのバックエンドということもあり、特別な技術スタックは使用せずオーソドックスに Ruby on Rails、MySQL を利用しています。 インフラも同様でサービスがスケールすることを念頭において AWS を利用しています。また IaC として Terraform を利用しています。 各人の開発環境も GitHub や Docker といった極めて一般的なものを採用しています。 新人を除く 5 人は元々別の会社において新規レセコンとは異なるレセコンの開発に携わっていました。当時は COBOL で開発を行っていましたが、レガシーな言語ゆえ、冗長的なコードになったり、同じようなロジックが複数のコードに存在していたりとメンテナンスに大変苦労していました。 現在は Ruby で開発を行っており、Ruby なりの難しさはありますが、 COBOL で同じコードを書いたら 5 倍の量になるなと感じるくらい、当時と比べると開発コストは大幅に下がっていると実感しています。 松江オフィスの雰囲気・文化 松江オフィスがある松江市は中海、宍道湖と大きな湖を 2 つもつことで水の都と言われています。この 2 つの湖を結ぶ大橋川ではシーバス釣りが盛んです。 年に 1 回秋頃にレガッタの大会が行われ、弊社のメンバーもチーム TAGBORTS として参加しています（まだオフィスのメンバーだけではチームが組めないため助っ人をお願いしている状況です…）。去年は 2 回戦敗退と悔しい結果となりましたが、今年は更に上を目指したいと思います。 松江オフィスは事務所のような雰囲気は一切なく、都会的なデザインとなっています。内装は設計・施工を行っていただきました トレイルヘッズ様の HP にてご確認いただくことが可能です。 開発用デスクは周囲が気にならないようにパーティションを設置しています。椅子にはアーロンチェアを採用しており、長時間の作業で体に負担がかからないよう配慮されています。 東京オフィスとのコミュニケーションは Google Meet か Slack がメインのため、電話がかかってくることもなく、集中して開発に取り組むことができる環境となっています。 現在エンジニア 5 名、ディレクター 1 名の計 6 名が在籍しています。 松江オフィスではレセコンに関する業務的な質問や Ruby に関するロジック的な質問など誰とでも気兼ねなく行うことができるように、メンバー間のコミュニケーションが取りやすい環境づくりを心がけています。例えば、今年からの取り組みですが、毎日 10 分程度の朝会を行うようにしました。会の目的としては進捗の遅れや、詰まってることなどを話すきっかけづくりです。 レセコン開発の性質上、エンジニアも診療報酬の知識のインプットが必要です。このため、ディレクターを中心に診療報酬の勉強会も行っています。 以前開発していたレセコンを超えるレセコンを作り上げる。それがメンバーの共通の目標です。 松江オフィスでこんな人と働きたい 以下に当てはまる方、大募集中です。 プログラミング（技術）が大好きで、それを手段として課題に対して積極的に行動できる Our Essentials に共感できる 医療業界に革新を起こす壮大なミッションにチャレンジしてみたい 下記のリンクからご応募お待ちしています。 中途採用は こちら 2024 年度新卒採用は こちら おわりに 簡単ですが、松江オフィスの紹介をさせていただきました。 今後も松江オフィスのメンバー一丸となって レセコン の開発を進め、CLINICS チームと協力して稼働医療機関を増やしていき、より患者が医療にアクセスしやすい環境が作れるように取り組んでいきます！

はじめに みなさん、こんにちは。医療プラットフォーム本部プロダクト開発室第三開発グループ グループマネージャの太田です。レセコン（電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア）新規開発プロジェクトでレセコンの開発を行っています。 2021 年 9 月 1 日に Tech Studio MATSUE オフィス（以下松江オフィス）が設立された際、他の初期メンバー 4 人と一緒にメドレーに入社しました。 記事を読み終わられた際は、1 人でも多くの方が松江オフィスに興味を持っていただけると嬉しいです。 松江オフィスでやっていること 松江オフィスではレセコン新規開発プロジェクトとして、 CLINICS カルテ に内包されるレセコン部分の開発を Ruby on Rails で行っています。 医療機関でどちらも使われるものですが、電子カルテがドクター向けのアプリケーションなのに対して、レセコンは事務員さん向けのアプリケーションとなります。 レセコンでは電子カルテに登録された診療内容を元に診療報酬の計算を行い、日々の業務としては請求書兼領収書、診療費明細書、処方箋、日報の作成を行い、月次の業務としては、保険者に対しての請求データの作成などの処理を行っています。診療報酬とは我々が医療機関を受診した際に受けた医療行為について、その対価として医療機関に支払われる費用です。医療行為１つ１つに点数が設定されており、この点数を「1 点=10 円」として診療報酬の計算を行います。 電子カルテとレセコンの関連性は強く、2 つのアプリケーションが近い関係であればあるほど、CLINICS の顧客に対してより価値の高いサービスの提供が可能となります。 これらの問題を解決すべく、 Sustainable （維持し続けられる）、Reasonable （合理的である）、Improvable （改善し続ける）、Manageable （管理しやすい）を基本コンセプトにレセコン新規開発プロジェクトが始まり松江でレセコンの開発が行われることになりました。 アプリケーション側で使いやすい API の開発を効率的に進めています。これには、アプリケーション側の開発チームとの関係強化が必須です。このため、東京の CLINICS チームとは日々 Slack や Google Meet などを通じて密に連絡を取り合いながら相互理解に努めることで、信頼関係を強化し、効率的に開発ができるよう取り組んでいます。 松江オフィスで利用してる技術 サービスのバックエンドということもあり、特別な技術スタックは使用せずオーソドックスに Ruby on Rails、MySQL を利用しています。 インフラも同様でサービスがスケールすることを念頭において AWS を利用しています。また IaC として Terraform を利用しています。 各人の開発環境も GitHub や Docker といった極めて一般的なものを採用しています。 新人を除く 5 人は元々別の会社において新規レセコンとは異なるレセコンの開発に携わっていました。当時は COBOL で開発を行っていましたが、レガシーな言語ゆえ、冗長的なコードになったり、同じようなロジックが複数のコードに存在していたりとメンテナンスに大変苦労していました。 現在は Ruby で開発を行っており、Ruby なりの難しさはありますが、 COBOL で同じコードを書いたら 5 倍の量になるなと感じるくらい、当時と比べると開発コストは大幅に下がっていると実感しています。 松江オフィスの雰囲気・文化 松江オフィスがある松江市は中海、宍道湖と大きな湖を 2 つもつことで水の都と言われています。この 2 つの湖を結ぶ大橋川ではシーバス釣りが盛んです。 年に 1 回秋頃にレガッタの大会が行われ、弊社のメンバーもチーム TAGBORTS として参加しています（まだオフィスのメンバーだけではチームが組めないため助っ人をお願いしている状況です…）。去年は 2 回戦敗退と悔しい結果となりましたが、今年は更に上を目指したいと思います。 松江オフィスは事務所のような雰囲気は一切なく、都会的なデザインとなっています。内装は設計・施工を行っていただきました トレイルヘッズ様の HP にてご確認いただくことが可能です。 開発用デスクは周囲が気にならないようにパーティションを設置しています。椅子にはアーロンチェアを採用しており、長時間の作業で体に負担がかからないよう配慮されています。 東京オフィスとのコミュニケーションは Google Meet か Slack がメインのため、電話がかかってくることもなく、集中して開発に取り組むことができる環境となっています。 現在エンジニア 5 名、ディレクター 1 名の計 6 名が在籍しています。 松江オフィスではレセコンに関する業務的な質問や Ruby に関するロジック的な質問など誰とでも気兼ねなく行うことができるように、メンバー間のコミュニケーションが取りやすい環境づくりを心がけています。例えば、今年からの取り組みですが、毎日 10 分程度の朝会を行うようにしました。会の目的としては進捗の遅れや、詰まってることなどを話すきっかけづくりです。 レセコン開発の性質上、エンジニアも診療報酬の知識のインプットが必要です。このため、ディレクターを中心に診療報酬の勉強会も行っています。 以前開発していたレセコンを超えるレセコンを作り上げる。それがメンバーの共通の目標です。 松江オフィスでこんな人と働きたい 以下に当てはまる方、大募集中です。 プログラミング（技術）が大好きで、それを手段として課題に対して積極的に行動できる Our Essentials に共感できる 医療業界に革新を起こす壮大なミッションにチャレンジしてみたい 下記のリンクからご応募お待ちしています。 中途採用は こちら 2024 年度新卒採用は こちら おわりに 簡単ですが、松江オフィスの紹介をさせていただきました。 今後も松江オフィスのメンバー一丸となって レセコン の開発を進め、CLINICS チームと協力して稼働医療機関を増やしていき、より患者が医療にアクセスしやすい環境が作れるように取り組んでいきます！

はじめに みなさん、こんにちは。医療プラットフォーム本部プロダクト開発室第三開発グループ グループマネージャの太田です。レセコン（電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア）新規開発プロジェクトでレセコンの開発を行っています。 2021 年 9 月 1 日に Tech Studio MATSUE オフィス（以下松江オフィス）が設立された際、他の初期メンバー 4 人と一緒にメドレーに入社しました。 記事を読み終わられた際は、1 人でも多くの方が松江オフィスに興味を持っていただけると嬉しいです。 松江オフィスでやっていること 松江オフィスではレセコン新規開発プロジェクトとして、 CLINICS カルテ に内包されるレセコン部分の開発を Ruby on Rails で行っています。 医療機関でどちらも使われるものですが、電子カルテがドクター向けのアプリケーションなのに対して、レセコンは事務員さん向けのアプリケーションとなります。 レセコンでは電子カルテに登録された診療内容を元に診療報酬の計算を行い、日々の業務としては請求書兼領収書、診療費明細書、処方箋、日報の作成を行い、月次の業務としては、保険者に対しての請求データの作成などの処理を行っています。診療報酬とは我々が医療機関を受診した際に受けた医療行為について、その対価として医療機関に支払われる費用です。医療行為１つ１つに点数が設定されており、この点数を「1 点=10 円」として診療報酬の計算を行います。 電子カルテとレセコンの関連性は強く、2 つのアプリケーションが近い関係であればあるほど、CLINICS の顧客に対してより価値の高いサービスの提供が可能となります。 これらの問題を解決すべく、 Sustainable （維持し続けられる）、Reasonable （合理的である）、Improvable （改善し続ける）、Manageable （管理しやすい）を基本コンセプトにレセコン新規開発プロジェクトが始まり松江でレセコンの開発が行われることになりました。 アプリケーション側で使いやすい API の開発を効率的に進めています。これには、アプリケーション側の開発チームとの関係強化が必須です。このため、東京の CLINICS チームとは日々 Slack や Google Meet などを通じて密に連絡を取り合いながら相互理解に努めることで、信頼関係を強化し、効率的に開発ができるよう取り組んでいます。 松江オフィスで利用してる技術 サービスのバックエンドということもあり、特別な技術スタックは使用せずオーソドックスに Ruby on Rails、MySQL を利用しています。 インフラも同様でサービスがスケールすることを念頭において AWS を利用しています。また IaC として Terraform を利用しています。 各人の開発環境も GitHub や Docker といった極めて一般的なものを採用しています。 新人を除く 5 人は元々別の会社において新規レセコンとは異なるレセコンの開発に携わっていました。当時は COBOL で開発を行っていましたが、レガシーな言語ゆえ、冗長的なコードになったり、同じようなロジックが複数のコードに存在していたりとメンテナンスに大変苦労していました。 現在は Ruby で開発を行っており、Ruby なりの難しさはありますが、 COBOL で同じコードを書いたら 5 倍の量になるなと感じるくらい、当時と比べると開発コストは大幅に下がっていると実感しています。 松江オフィスの雰囲気・文化 松江オフィスがある松江市は中海、宍道湖と大きな湖を 2 つもつことで水の都と言われています。この 2 つの湖を結ぶ大橋川ではシーバス釣りが盛んです。 年に 1 回秋頃にレガッタの大会が行われ、弊社のメンバーもチーム TAGBORTS として参加しています（まだオフィスのメンバーだけではチームが組めないため助っ人をお願いしている状況です…）。去年は 2 回戦敗退と悔しい結果となりましたが、今年は更に上を目指したいと思います。 松江オフィスは事務所のような雰囲気は一切なく、都会的なデザインとなっています。内装は設計・施工を行っていただきました トレイルヘッズ様の HP にてご確認いただくことが可能です。 開発用デスクは周囲が気にならないようにパーティションを設置しています。椅子にはアーロンチェアを採用しており、長時間の作業で体に負担がかからないよう配慮されています。 東京オフィスとのコミュニケーションは Google Meet か Slack がメインのため、電話がかかってくることもなく、集中して開発に取り組むことができる環境となっています。 現在エンジニア 5 名、ディレクター 1 名の計 6 名が在籍しています。 松江オフィスではレセコンに関する業務的な質問や Ruby に関するロジック的な質問など誰とでも気兼ねなく行うことができるように、メンバー間のコミュニケーションが取りやすい環境づくりを心がけています。例えば、今年からの取り組みですが、毎日 10 分程度の朝会を行うようにしました。会の目的としては進捗の遅れや、詰まってることなどを話すきっかけづくりです。 レセコン開発の性質上、エンジニアも診療報酬の知識のインプットが必要です。このため、ディレクターを中心に診療報酬の勉強会も行っています。 以前開発していたレセコンを超えるレセコンを作り上げる。それがメンバーの共通の目標です。 松江オフィスでこんな人と働きたい 以下に当てはまる方、大募集中です。 プログラミング（技術）が大好きで、それを手段として課題に対して積極的に行動できる Our Essentials に共感できる 医療業界に革新を起こす壮大なミッションにチャレンジしてみたい 下記のリンクからご応募お待ちしています。 中途採用は こちら 2024 年度新卒採用は こちら おわりに 簡単ですが、松江オフィスの紹介をさせていただきました。 今後も松江オフィスのメンバー一丸となって レセコン の開発を進め、CLINICS チームと協力して稼働医療機関を増やしていき、より患者が医療にアクセスしやすい環境が作れるように取り組んでいきます！

はじめに みなさん、こんにちは。医療プラットフォーム本部プロダクト開発室第三開発グループ グループマネージャの太田です。レセコン（電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア）新規開発プロジェクトでレセコンの開発を行っています。 2021 年 9 月 1 日に Tech Studio MATSUE オフィス（以下松江オフィス）が設立された際、他の初期メンバー 4 人と一緒にメドレーに入社しました。 記事を読み終わられた際は、1 人でも多くの方が松江オフィスに興味を持っていただけると嬉しいです。 松江オフィスでやっていること 松江オフィスではレセコン新規開発プロジェクトとして、 CLINICS カルテ に内包されるレセコン部分の開発を Ruby on Rails で行っています。 医療機関でどちらも使われるものですが、電子カルテがドクター向けのアプリケーションなのに対して、レセコンは事務員さん向けのアプリケーションとなります。 レセコンでは電子カルテに登録された診療内容を元に診療報酬の計算を行い、日々の業務としては請求書兼領収書、診療費明細書、処方箋、日報の作成を行い、月次の業務としては、保険者に対しての請求データの作成などの処理を行っています。診療報酬とは我々が医療機関を受診した際に受けた医療行為について、その対価として医療機関に支払われる費用です。医療行為１つ１つに点数が設定されており、この点数を「1 点=10 円」として診療報酬の計算を行います。 電子カルテとレセコンの関連性は強く、2 つのアプリケーションが近い関係であればあるほど、CLINICS の顧客に対してより価値の高いサービスの提供が可能となります。 これらの問題を解決すべく、 Sustainable （維持し続けられる）、Reasonable （合理的である）、Improvable （改善し続ける）、Manageable （管理しやすい）を基本コンセプトにレセコン新規開発プロジェクトが始まり松江でレセコンの開発が行われることになりました。 アプリケーション側で使いやすい API の開発を効率的に進めています。これには、アプリケーション側の開発チームとの関係強化が必須です。このため、東京の CLINICS チームとは日々 Slack や Google Meet などを通じて密に連絡を取り合いながら相互理解に努めることで、信頼関係を強化し、効率的に開発ができるよう取り組んでいます。 松江オフィスで利用してる技術 サービスのバックエンドということもあり、特別な技術スタックは使用せずオーソドックスに Ruby on Rails、MySQL を利用しています。 インフラも同様でサービスがスケールすることを念頭において AWS を利用しています。また IaC として Terraform を利用しています。 各人の開発環境も GitHub や Docker といった極めて一般的なものを採用しています。 新人を除く 5 人は元々別の会社において新規レセコンとは異なるレセコンの開発に携わっていました。当時は COBOL で開発を行っていましたが、レガシーな言語ゆえ、冗長的なコードになったり、同じようなロジックが複数のコードに存在していたりとメンテナンスに大変苦労していました。 現在は Ruby で開発を行っており、Ruby なりの難しさはありますが、 COBOL で同じコードを書いたら 5 倍の量になるなと感じるくらい、当時と比べると開発コストは大幅に下がっていると実感しています。 松江オフィスの雰囲気・文化 松江オフィスがある松江市は中海、宍道湖と大きな湖を 2 つもつことで水の都と言われています。この 2 つの湖を結ぶ大橋川ではシーバス釣りが盛んです。 年に 1 回秋頃にレガッタの大会が行われ、弊社のメンバーもチーム TAGBORTS として参加しています（まだオフィスのメンバーだけではチームが組めないため助っ人をお願いしている状況です…）。去年は 2 回戦敗退と悔しい結果となりましたが、今年は更に上を目指したいと思います。 松江オフィスは事務所のような雰囲気は一切なく、都会的なデザインとなっています。内装は設計・施工を行っていただきました トレイルヘッズ様の HP にてご確認いただくことが可能です。 開発用デスクは周囲が気にならないようにパーティションを設置しています。椅子にはアーロンチェアを採用しており、長時間の作業で体に負担がかからないよう配慮されています。 東京オフィスとのコミュニケーションは Google Meet か Slack がメインのため、電話がかかってくることもなく、集中して開発に取り組むことができる環境となっています。 現在エンジニア 5 名、ディレクター 1 名の計 6 名が在籍しています。 松江オフィスではレセコンに関する業務的な質問や Ruby に関するロジック的な質問など誰とでも気兼ねなく行うことができるように、メンバー間のコミュニケーションが取りやすい環境づくりを心がけています。例えば、今年からの取り組みですが、毎日 10 分程度の朝会を行うようにしました。会の目的としては進捗の遅れや、詰まってることなどを話すきっかけづくりです。 レセコン開発の性質上、エンジニアも診療報酬の知識のインプットが必要です。このため、ディレクターを中心に診療報酬の勉強会も行っています。 以前開発していたレセコンを超えるレセコンを作り上げる。それがメンバーの共通の目標です。 松江オフィスでこんな人と働きたい 以下に当てはまる方、大募集中です。 プログラミング（技術）が大好きで、それを手段として課題に対して積極的に行動できる Our Essentials に共感できる 医療業界に革新を起こす壮大なミッションにチャレンジしてみたい 下記のリンクからご応募お待ちしています。 中途採用は こちら 2024 年度新卒採用は こちら おわりに 簡単ですが、松江オフィスの紹介をさせていただきました。 今後も松江オフィスのメンバー一丸となって レセコン の開発を進め、CLINICS チームと協力して稼働医療機関を増やしていき、より患者が医療にアクセスしやすい環境が作れるように取り組んでいきます！

はじめに みなさん、こんにちは。エンジニアの新居です。 今回のインタビューは前回の CTO へのインタビュー に続いて、メドレーの開発組織についてご紹介していきたいと思います。 メドレーでは開発組織をリードするロールとして、CTO の他、「グループマネージャ」(以下、GM)という役職があります。今回は医療プラットフォーム(以下、医療 PF)における開発グループの GM を担う二人に、具体的にどのような役割なのか聞いていきます。 インタビュイー紹介 今回の紹介はインタビュー中で前職からメドレー入社の話を聞いているので、シンプルにお送りします。 平山さん 医療 PF 第一本部 プロダクト開発室 第四開発グループ GM。現在は CLINICS 基幹システムチームのマネジメントを担当。 岡村さん 医療 PF 第一本部 プロダクト開発室 第三開発グループ GM。現在はレセコン(電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア)新規開発チームのマネジメントを担当。 左から岡村さん、平山さん、筆者 前職までの経歴とメドレー入社の理由について 二人の経験について 新居 : 早速始めていきますが、まずはお二人の経歴を教えていただきたいと思います。 平山 : メドレーは 2 社目の会社となります。前職は SIer で 14~5 年くらい受託開発や客先常駐して開発をしていました。SIer というと場合によっては二次請け・三次請けの開発をしているところもあるんですが、自分は一次請けとして直接顧客と関わる形で業務を行っていました。 顧客のサービスをステークホルダーと提案・折衝しながら、技術選定・要件定義から開発、リリースまで行い、そこからの保守運用といった部分までの一連の流れを様々な業態の顧客と関わらせて頂きました。 新居 : ありがとうございます。かなり自社開発と同じ感覚の開発を長年されてきたんですね。それでは、岡村さんお願いします。 岡村 : 新卒で外資系の IT コンサルティング会社で IT コンサルタントとしてキャリアを始めました。その中でも特に「情報系」と呼ばれるデータアナリティクスや BI (Business Intelligence) などを取り扱う部門で業務をしていました。領域的には金融・製薬・省庁など堅めの領域を主に担当していたので、いわゆる Web アプリケーションを作るというよりは SQL をガリガリ書いてデータ分析を基に業務改善していく…という感じの業務が多かったです。 2 社目はスタートアップ企業の立ち上げフェイズにジョインしました。その会社はいわゆる Insure Tech と呼ばれる保険業界 x テクノロジー領域のサービスを作っている会社でした。そこで、その会社でのプロダクトマネージャ業務と、運転資金を確保するために大手保険会社向けのコンサルタント業務に半々で従事していました。 その後にメドレーにジョインするという経歴です。 岡村さん メドレー入社の経緯について 新居 : ありがとうございます、お二人はメドレーに入社してどのくらい経ちますっけ? 平山 : 私は 3 年半ですね。 岡村 : 私は 4 年経ちました。 新居 : もうそんなに経つんですね。みなさんの前職を転職しようと思った動機とはどんなものだったんですか? 平山 : 前職でプレイングマネージャとして業務をしてきましたが、キャリアを重ねてくると徐々にマネジメントの割合が増えてきます。それ自体は自然なことではあるのですが、前職の延長線上でマネジメントに比重を置くことに対して、危機感を感じていたんです。手を動かす部分を含めて、エンジニアとして良いキャリアを積むには別の環境に身を置く必要があると思い、転職を決意しました。 転職に際しては、自分が 身近に感じるサービスで特に自分の家族が関わるような領域が良いと考えており、医療はそうした意味でぴったりな領域 でした。これらの条件で転職エージェントを通じてメドレーに辿りつきました。 平山さん 岡村 : 先程も少し話しましたが、前職は自社プロダクトと他社向けコンサルティングを並行して運営していた会社でした。しかし、途中から経営方針が変わってコンサルティング業務をメインに据えるようになったんです。自分としては、自社プロダクトを作っている点を大事に考えていたため、転職を考えはじめました。 会社選びの軸としては、もちろん自社サービスが事業の主軸である会社というのが一番でした。他の条件としては「上場一歩手前」くらいのフェイズの会社というものがありました。これは、そのくらいのフェイズの会社であれば今までやっていた事業をいきなりピボットするという可能性が限りなく低いのではないかと考えたからです。そんな感じで会社を探していて、LinkedIn の広告経由でメドレーにアプローチして入社しました。 新居 : 岡村さんは次の会社の事業領域は、意識していたんでしょうか? 岡村 : 医療領域を名指しで考えていたわけではないです。しかし、いわゆる 昔ながらの慣習などが多く残るような業界や領域を、自分達が手がけたサービスで変えていくというのが良い という考えでした。これは前職でも考えていたことだったので、引き続き志向していました。 メドレー入社後にどのような仕事をしていたのか 新居 : ありがとうございます。そんな経緯でメドレーに入社したお二人ですが、入社後はどのような業務をされていたんでしょうか。 平山 : 私は入社後から一貫して CLINICS カルテを担当しています。入社後は医療に関する業務知識を身につけながら、周辺業務から徐々に関わっていきシステム面のキャッチアップをしていきました。一番最初に携わったプロジェクトとしては、CLINICS カルテにおける診察業務のコントロールを担う「診療ステータス」の拡張を行うという、カルテ全体に影響のある大きな改修に携わりました。それ以降も、小さいタスクを捌きつつ、中・大規模な施策に携わってきた感じです。 そこから医療 PF 横断のプロジェクトにも関わっていくようになりました。CLINICS というプロダクトは患者が使用するアプリを始め、調剤・歯科のサービスも提供しています。 医療 PF 全体の体験設計を踏まえて、周辺プロダクトとも積極的に関わっていく必要がある という点は特徴的だと思います。 岡村 : 私は入社当時は「社長室コンサル」という役割で入社し、この部署は M&A などをメインに担当していた部署だったんです。そのため最初にアサインされたのが NaCl メディカル社(現在はメドレー本体に統合)の業務面での PMI でした。これと平行して、現在も引き続き携わっている新しいレセコンを作るプロジェクトのプロダクトマネージャを担当してきました。 新規レセコンは CLINICS カルテと連携しているプロダクトなので、平山さんが率いるチームと連携 しながら、このプロダクトを作っている開発チームを率いています。 GM としてのミッションと就任してから変わったこと・変わらないこと 新居 : 話を聞いていると、お二人とも最初の仕事を順調にスケールアップしていったという形で現在の業務に繋っているんですね。さて、ここからは GM に就任してからの自身の業務がどのように変化してきたのかという点を聞きたいのですが、この点どうでしょうか。 平山 : ミッションはやはり変化しました。GM としてのミッションで一番求められるものは「 プロダクトを前進させる 」という部分と考えています。自身の管掌組織は当然ですが、組織を横断する形の取り組みも必要になります。 「ピープルマネジメント」という点も GM としての変化の１つかなと思います。とはいえ、先ほどの話と通じる部分はあり**「プロダクトに軸足を置いて目線を合わせていくこと」が基本**となります。また、組織上の持続可能性という意味においても「任せていく」というところは大事にしています。メンバーに優秀な方が多いので助けられている部分は多いと感じます。 エンジニアリングという意味では、手を動かす量は減りました。手の動かし方という意味では入社当初から横の動きを見るようにはしていたので GM になって変わったという部分は無いですね。 岡村 : レセコン新規開発プロジェクトでの GM のミッションとして、「プロジェクトの完遂」、「チームメンバーのピープルマネジメント」、「Tech Studio MATSUE(島根県にあるメドレーの拠点。レセコン新規開発プロジェクトの開発をしている)の管理」がメインになります。 GM に就任したタイミングは NaCl メディカル社がメドレー本体に吸収合併されたというタイミングでした。就任前はグループ会社ということもあり、開発業務を受発注するという動きに近い感じで協業してきました。GM になってからは、同じ会社になったのでより近い距離でチーム開発をするようになったり、メンバーのピープルマネジメントの割合が多くなるという変化がありました。 担当領域としてはレセコンのプロダクトマネジメントをしているという部分は変わらない部分です。また平山さんがおっしゃっていたように、いつまでも自分が上にいて指揮するという状態を良しとするのではなく、 メンバーの人をどんどんと上のロールに引き上げていくというのが GM の役割の 1 つ かと思うので、そういう意識でメンバーのマネジメントをしています。 エンジニアリングとマネジメントの比率はプロダクトのフェイズによって変わってくるし、変わるべきかなと思っています。現在は 8 対 2 でマネジメントの比率が多くなっています。一方でプロダクトの初期でどんどんと開発をしていかないといけないという場合には自分も含めて人手をかけて開発していくようにします。 新居 : お話をうかがうと、やはり GM 前よりもマネジメントの比率が多くなっているのではないかと思うのですが、葛藤などはありましたか。 平山 : 元々の自分のスタンスとして「自分も駒の一つ」としてプロダクト開発を推進していくという思考があります。GM の話が来たときにも、やれるかなという不安感はありましたが、今の場面においては自身がやった方が良いと感じて受けました。 岡村 : 私は出自がエンジニアではないというのもあって、葛藤のようなものも平山さんとは違って、特にありませんでした。元々 NaCl メディカル社だった松江オフィスとのハブになるのは、自分しかいないと思っていましたので躊躇のようなものも全く無かったです。 GM で苦労したポイント・どう克服していたか 新居 : ありがとうございます。では、GM になって苦労したとか大変だったというところってどんなところがありましたか。 平山 : 自分は口下手な方なんで、以前より喋る機会が増えたのが困ったところですね（笑） 新居 : 平山さんに口下手な印象は全然ありませんが（笑） 平山 : 他には、これはどちらかというと PdM 属性の仕事にも関わってくるんですが、開発計画の策定は大変です(メドレーでは 3 ヶ月ごとに開発計画を立てている)。 大規模な施策の実施と並行して優先度の高いタスクの差し込みを踏まえて、優先度の再設計や施策のフェージングや運用の検討したりしています。 自分で抱え込む必要はないですが、関係者と調整しつつも最終意思決定は自分になるので、様々な葛藤をしながら取り組んでいます 。 新居 : ピープルマネジメント面では何かありましたか。 平山 : 先程お話した「プロダクトに軸足を置いて目線を合わせていくこと」を大切にコミュニケーションを実施し、日々の業務を通してメンバー一人一人でシナジーが出る・良いキャリアが重ねられるようにしたいと考えていますが、先ほどの開発計画の難しさもここにあります。 新居 : ありがとうございます。では岡村さんはいかがでしょう。 岡村 : 平山さんに全く同感ですね（笑） 冗談は置いておいて、計画外の差し込みタスクなどが入ると、どうしてもチームの負荷が高くなってくるので、そこをコントロールしきれずに申し訳ないなと思うことがあります。 他には、メンバーのキャリア形成をどうするかという点が難しいと思います。 メンバーの志向に合わせての将来像を見据えて現在の業務に取り組んでもらいたい のですが、実際のタスクとそうしたキャリアの方向性が必ずしもぴったりと合うときばかりではないので、ここをどう揃えていくかという点にも苦労はしています。 新居 : なるほど、岡村さんの場合は元々として島根と東京という立地間でのマネジメントをされていたと思うんですが、リモートコミュニケーションが中心という環境での苦労は何かありましたか。 岡村 : 実はこれと言って無いんですよ。それでもちゃんと上手く機能している要因としては、2 つあります。1 つは島根の方に現地のメンバーを取りしきってくれるスキルを持ったメンバーが居てくれたことです。ここは今でも本当に助かっています。 また、当初から技術的な部分も含めて私もメンバーと一緒に勉強しながら、新しい取り組みをするというスタンスを持ってプロジェクトを推進できたことです。ですので、離れたところから命令する人のような感じではなく、 チームで一緒にプロジェクトを進める人という認識を持ってもらえた んじゃないかなと考えています。 もちろん、関係値を作れるまでは私が最初の頃は 1 ヶ月に 1~2 回程度島根に出張して、実際にメンバーと会ったりすることもしていましたが。 GM を担う上で、役に立った経験・知識 新居 : ここからは、お二人が今までの業務の中で積んできた経験・知識の内、現在 GM として活動する上で役に立っているものとして、どんなものがあるのか聞ければと思います。 平山 : そうですね、一番役に立っているなと感じているのは前職で経験した「 様々なステークホルダーとの主体性を持った折衝経験 」です。色々な会社や立場の方とコミュニケーションを取ることが多かったんですね。専門性もそれぞれ違う方達とお話して物事を進める経験ができたことは、今の GM という役割に本当に役立っていると思います。 岡村 : 私が役に立っていると感じる経験は、「 一回深く細かいところまで業務を見てみて理解をしてから、改めて俯瞰した視点で業務を見直してメンバーにお願いする 」という習慣です。この相反する方法をバランス良くできるようになっているというのが、良い点なのかなと思っています。また、深く見るというのは自分が興味を持っている分野でないと中々難しいので、何にでも興味を持って業務に取り組むという心持ちも必要になるかと考えています。 こうした形で業務を分解してメンバーにお願いできるところはしながら、GM としては適切に権限委譲していくというのに役立っています。 エンジニアのピープルマネジメントで意識していること 新居 : 今までのお話でも少し出ている話題になるのですが、GM としてエンジニアのマネジメントで意識しているポイントって、どんなことがありますか。 平山 : 自分達が作る プロダクトへの興味関心・解像度を高め、何を作るのか 。という点において各所コミュニケーションを含めて主体的に動くこと。そうした積み重ねの延長線上にあるエンジニアとしてのキャリア形成を意識しています。 この考え方に加えて「プロダクトの持続可能性を高める」というテーマで、エンジニア・デザイナー・ディレクター・ QA エンジニア・カスタマーサクセスといったプロダクトに関わる人達の専門性を踏まえたタスクの再配布・プロジェクト設計を行う。といった体制作りも推進しようとしています。 新居 : 「プロダクトの持続可能性を高める」というのは、すごく難しい試みですよね。 平山 : 確かにとても難しいなと思います。でも打ち手としては色々あるのではないかと考えていて。「属人性の排除」といった点は、分かりやすいのではないかなと思います。誰かに依存した状態は、組織変更や事業スケールの変化に弱くなりがちですよね。 大事なのは「人から組織への移行」「仕組み化」と捉えています。「できる人を増やす」については、大事だけど秘伝のタレが受け継がれるだけになってしまうので、持続可能性の観点では本質的ではないかなと。 一方で「仕組み化するための計画的な属人性」については推奨できると考えてます。新しいことをいきなり「組織に転換」や「人を増やしてローテする」だと、ナレッジが蓄積されづらく、次の一手が打ちづらくなるので。 新居 : そうした取り組みをするのに、例えばエンジニアだと作ってみたものがプロダクトの目指す方向性とズレが生じていたというような事態があると思うんですが、そうしたズレを事前に仕組みで抑えるような事をしているんですか。 平山 : きっちりとした仕組みなどは作ってはいないです。仕組み化というよりも、そうならないように メンバーから上がってきた疑問などに対する壁打ちなどは気軽にできる ようにしています。また、そういった相談を気軽にできるような自分自身のプロデュースといいますか、キャラ作りみたいなものも含めてメンバーが相談しにくいという空気を作らないようにはしていますね。 新居 : ありがとうございます。岡村さんはどんな意識をしていますか。 岡村 : やっぱり平山さんに全く同感ですね（笑） 付け加えると、ソフト面ですが メンバーであるエンジニアが楽しめる環境作り というところを意識しています。楽しさにも色々な種類があるとは思いますが、単にコーディングするだけではなく、やはりプロダクトそれ自体の提供価値というものをしっかりと共有して、プロダクトを作ること自体に楽しさを感じてもらう…というのは重要じゃないかなと思っています。 また楽しさの別側面ですが、新しいテクノロジーなどもどんどんと取り入れることができるような仕組み作りもしています。島根のメンバーは今回のプロジェクトで初めて Ruby を使うというメンバーも多かったので、ここで楽しさを感じられないと、こうしたテクノロジー自体を嫌いになってしまう恐れがあるなと思ったので。 そうした「楽しい仕事」にしていくと「時間をかけなきゃ」ではなく「時間をかけたい」という感じで取り組めるようになると思います。 GM という役割の醍醐味とは 新居 : それでは終盤になってきましたが、GM の「やりがい」や「醍醐味」はどういったものになりますか。 岡村 : 一番は「ピープルマネジメント」になるんじゃないかと考えています。最近、岸田首相の所信表明演説で聞いて感銘を受けたアフリカの諺ですが「早く行きたいなら 1 人で行け、遠くへ行きたいならみんなで行け」という言葉はピープルマネジメントの本質なんじゃないかなと思っています。 メンバーと一緒に遠くに行くために組織作り などをしていけるのが醍醐味だと感じています。 平山 : メンバーの 個人スキルを高めつつ「チーム」に還元してもらうための仕組み を作っていく。というのは、醍醐味と言えるのかなと。CTO インタビューで田中も言っていますが「チームバリュー」は大切だと考えています。 チームといっても、狭義のチームではなくプロダクトに関わる関係者全員を含めたチームという感じで意識しています。開発組織に閉じないバリューの発揮がメンバーそれぞれでできると心強いと思います。 メドレーで GM やリードエンジニアのロールに向いている方 新居 : 最後になるのですが、メドレーで GM やテックリードといったロールに向いているのは、どんな人だと思いますか。 平山 : 基本的に 物事を前に進めるための解像度を高く描ける人 かなと思っています。何を誰のためにというのを体現しつつ、関係者を引っぱっていける人ですね。メドレーの Our Essentials 全般必要だとは思いますが、その中でも「成果を出す」「自分をアップデート」「組織水準を高める」「革新と改善を主導」というところが必要になるかな。困難な状況でも結果を出しつつ、自分の行動も高めていき、結果組織・プロダクトを良くしていける…というのがメドレーのリードと呼ばれているエンジニアかと思います。 やり方としては、マイクロマネジメントではなく、基本となる考え方をちゃんと伝えてメンバーに学んでもらう…という、やり方ができる人が向いていると思います。 岡村 : 困難な状況であっても何とかして前に進めることができる人 でしょうか。無理矢理に進めるというわけではなく、状況の整理や色々な部署との調整などもしたりして、何とか結果という形にしていける能力がある人がリードとしてメンバーを引っぱっていける人だと思います。 もちろん、フェイズによってメンバーとの関わりなどはちゃんと調整していける柔軟さなども必要になると思います。 新居 : なるほど。本日は色々なお話をしていただきまして、ありがとうございました! さいごに メドレーの GM 二人に仕事について聞いていきました。 前回の CTO インタビューでも語られた開発組織の話ですが、より現場に近い GM という立場のメンバーからの話でまた違った雰囲気などを感じていただけたかと思います。 このような GM を「ぜひやりたい!」という方や「こんな上司の元で自分の力を発揮していきたい!」という方はぜひカジュアルにお話ができればと思います。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの新居です。 今回のインタビューは前回の CTO へのインタビュー に続いて、メドレーの開発組織についてご紹介していきたいと思います。 メドレーでは開発組織をリードするロールとして、CTO の他、「グループマネージャ」(以下、GM)という役職があります。今回は医療プラットフォーム(以下、医療 PF)における開発グループの GM を担う二人に、具体的にどのような役割なのか聞いていきます。 インタビュイー紹介 今回の紹介はインタビュー中で前職からメドレー入社の話を聞いているので、シンプルにお送りします。 平山さん 医療 PF 第一本部 プロダクト開発室 第四開発グループ GM。現在は CLINICS 基幹システムチームのマネジメントを担当。 岡村さん 医療 PF 第一本部 プロダクト開発室 第三開発グループ GM。現在はレセコン(電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア)新規開発チームのマネジメントを担当。 左から岡村さん、平山さん、筆者 前職までの経歴とメドレー入社の理由について 二人の経験について 新居 : 早速始めていきますが、まずはお二人の経歴を教えていただきたいと思います。 平山 : メドレーは 2 社目の会社となります。前職は SIer で 14~5 年くらい受託開発や客先常駐して開発をしていました。SIer というと場合によっては二次請け・三次請けの開発をしているところもあるんですが、自分は一次請けとして直接顧客と関わる形で業務を行っていました。 顧客のサービスをステークホルダーと提案・折衝しながら、技術選定・要件定義から開発、リリースまで行い、そこからの保守運用といった部分までの一連の流れを様々な業態の顧客と関わらせて頂きました。 新居 : ありがとうございます。かなり自社開発と同じ感覚の開発を長年されてきたんですね。それでは、岡村さんお願いします。 岡村 : 新卒で外資系の IT コンサルティング会社で IT コンサルタントとしてキャリアを始めました。その中でも特に「情報系」と呼ばれるデータアナリティクスや BI (Business Intelligence) などを取り扱う部門で業務をしていました。領域的には金融・製薬・省庁など堅めの領域を主に担当していたので、いわゆる Web アプリケーションを作るというよりは SQL をガリガリ書いてデータ分析を基に業務改善していく…という感じの業務が多かったです。 2 社目はスタートアップ企業の立ち上げフェイズにジョインしました。その会社はいわゆる Insure Tech と呼ばれる保険業界 x テクノロジー領域のサービスを作っている会社でした。そこで、その会社でのプロダクトマネージャ業務と、運転資金を確保するために大手保険会社向けのコンサルタント業務に半々で従事していました。 その後にメドレーにジョインするという経歴です。 岡村さん メドレー入社の経緯について 新居 : ありがとうございます、お二人はメドレーに入社してどのくらい経ちますっけ? 平山 : 私は 3 年半ですね。 岡村 : 私は 4 年経ちました。 新居 : もうそんなに経つんですね。みなさんの前職を転職しようと思った動機とはどんなものだったんですか? 平山 : 前職でプレイングマネージャとして業務をしてきましたが、キャリアを重ねてくると徐々にマネジメントの割合が増えてきます。それ自体は自然なことではあるのですが、前職の延長線上でマネジメントに比重を置くことに対して、危機感を感じていたんです。手を動かす部分を含めて、エンジニアとして良いキャリアを積むには別の環境に身を置く必要があると思い、転職を決意しました。 転職に際しては、自分が 身近に感じるサービスで特に自分の家族が関わるような領域が良いと考えており、医療はそうした意味でぴったりな領域 でした。これらの条件で転職エージェントを通じてメドレーに辿りつきました。 平山さん 岡村 : 先程も少し話しましたが、前職は自社プロダクトと他社向けコンサルティングを並行して運営していた会社でした。しかし、途中から経営方針が変わってコンサルティング業務をメインに据えるようになったんです。自分としては、自社プロダクトを作っている点を大事に考えていたため、転職を考えはじめました。 会社選びの軸としては、もちろん自社サービスが事業の主軸である会社というのが一番でした。他の条件としては「上場一歩手前」くらいのフェイズの会社というものがありました。これは、そのくらいのフェイズの会社であれば今までやっていた事業をいきなりピボットするという可能性が限りなく低いのではないかと考えたからです。そんな感じで会社を探していて、LinkedIn の広告経由でメドレーにアプローチして入社しました。 新居 : 岡村さんは次の会社の事業領域は、意識していたんでしょうか? 岡村 : 医療領域を名指しで考えていたわけではないです。しかし、いわゆる 昔ながらの慣習などが多く残るような業界や領域を、自分達が手がけたサービスで変えていくというのが良い という考えでした。これは前職でも考えていたことだったので、引き続き志向していました。 メドレー入社後にどのような仕事をしていたのか 新居 : ありがとうございます。そんな経緯でメドレーに入社したお二人ですが、入社後はどのような業務をされていたんでしょうか。 平山 : 私は入社後から一貫して CLINICS カルテを担当しています。入社後は医療に関する業務知識を身につけながら、周辺業務から徐々に関わっていきシステム面のキャッチアップをしていきました。一番最初に携わったプロジェクトとしては、CLINICS カルテにおける診察業務のコントロールを担う「診療ステータス」の拡張を行うという、カルテ全体に影響のある大きな改修に携わりました。それ以降も、小さいタスクを捌きつつ、中・大規模な施策に携わってきた感じです。 そこから医療 PF 横断のプロジェクトにも関わっていくようになりました。CLINICS というプロダクトは患者が使用するアプリを始め、調剤・歯科のサービスも提供しています。 医療 PF 全体の体験設計を踏まえて、周辺プロダクトとも積極的に関わっていく必要がある という点は特徴的だと思います。 岡村 : 私は入社当時は「社長室コンサル」という役割で入社し、この部署は M&A などをメインに担当していた部署だったんです。そのため最初にアサインされたのが NaCl メディカル社(現在はメドレー本体に統合)の業務面での PMI でした。これと平行して、現在も引き続き携わっている新しいレセコンを作るプロジェクトのプロダクトマネージャを担当してきました。 新規レセコンは CLINICS カルテと連携しているプロダクトなので、平山さんが率いるチームと連携 しながら、このプロダクトを作っている開発チームを率いています。 GM としてのミッションと就任してから変わったこと・変わらないこと 新居 : 話を聞いていると、お二人とも最初の仕事を順調にスケールアップしていったという形で現在の業務に繋っているんですね。さて、ここからは GM に就任してからの自身の業務がどのように変化してきたのかという点を聞きたいのですが、この点どうでしょうか。 平山 : ミッションはやはり変化しました。GM としてのミッションで一番求められるものは「 プロダクトを前進させる 」という部分と考えています。自身の管掌組織は当然ですが、組織を横断する形の取り組みも必要になります。 「ピープルマネジメント」という点も GM としての変化の１つかなと思います。とはいえ、先ほどの話と通じる部分はあり**「プロダクトに軸足を置いて目線を合わせていくこと」が基本**となります。また、組織上の持続可能性という意味においても「任せていく」というところは大事にしています。メンバーに優秀な方が多いので助けられている部分は多いと感じます。 エンジニアリングという意味では、手を動かす量は減りました。手の動かし方という意味では入社当初から横の動きを見るようにはしていたので GM になって変わったという部分は無いですね。 岡村 : レセコン新規開発プロジェクトでの GM のミッションとして、「プロジェクトの完遂」、「チームメンバーのピープルマネジメント」、「Tech Studio MATSUE(島根県にあるメドレーの拠点。レセコン新規開発プロジェクトの開発をしている)の管理」がメインになります。 GM に就任したタイミングは NaCl メディカル社がメドレー本体に吸収合併されたというタイミングでした。就任前はグループ会社ということもあり、開発業務を受発注するという動きに近い感じで協業してきました。GM になってからは、同じ会社になったのでより近い距離でチーム開発をするようになったり、メンバーのピープルマネジメントの割合が多くなるという変化がありました。 担当領域としてはレセコンのプロダクトマネジメントをしているという部分は変わらない部分です。また平山さんがおっしゃっていたように、いつまでも自分が上にいて指揮するという状態を良しとするのではなく、 メンバーの人をどんどんと上のロールに引き上げていくというのが GM の役割の 1 つ かと思うので、そういう意識でメンバーのマネジメントをしています。 エンジニアリングとマネジメントの比率はプロダクトのフェイズによって変わってくるし、変わるべきかなと思っています。現在は 8 対 2 でマネジメントの比率が多くなっています。一方でプロダクトの初期でどんどんと開発をしていかないといけないという場合には自分も含めて人手をかけて開発していくようにします。 新居 : お話をうかがうと、やはり GM 前よりもマネジメントの比率が多くなっているのではないかと思うのですが、葛藤などはありましたか。 平山 : 元々の自分のスタンスとして「自分も駒の一つ」としてプロダクト開発を推進していくという思考があります。GM の話が来たときにも、やれるかなという不安感はありましたが、今の場面においては自身がやった方が良いと感じて受けました。 岡村 : 私は出自がエンジニアではないというのもあって、葛藤のようなものも平山さんとは違って、特にありませんでした。元々 NaCl メディカル社だった松江オフィスとのハブになるのは、自分しかいないと思っていましたので躊躇のようなものも全く無かったです。 GM で苦労したポイント・どう克服していたか 新居 : ありがとうございます。では、GM になって苦労したとか大変だったというところってどんなところがありましたか。 平山 : 自分は口下手な方なんで、以前より喋る機会が増えたのが困ったところですね（笑） 新居 : 平山さんに口下手な印象は全然ありませんが（笑） 平山 : 他には、これはどちらかというと PdM 属性の仕事にも関わってくるんですが、開発計画の策定は大変です(メドレーでは 3 ヶ月ごとに開発計画を立てている)。 大規模な施策の実施と並行して優先度の高いタスクの差し込みを踏まえて、優先度の再設計や施策のフェージングや運用の検討したりしています。 自分で抱え込む必要はないですが、関係者と調整しつつも最終意思決定は自分になるので、様々な葛藤をしながら取り組んでいます 。 新居 : ピープルマネジメント面では何かありましたか。 平山 : 先程お話した「プロダクトに軸足を置いて目線を合わせていくこと」を大切にコミュニケーションを実施し、日々の業務を通してメンバー一人一人でシナジーが出る・良いキャリアが重ねられるようにしたいと考えていますが、先ほどの開発計画の難しさもここにあります。 新居 : ありがとうございます。では岡村さんはいかがでしょう。 岡村 : 平山さんに全く同感ですね（笑） 冗談は置いておいて、計画外の差し込みタスクなどが入ると、どうしてもチームの負荷が高くなってくるので、そこをコントロールしきれずに申し訳ないなと思うことがあります。 他には、メンバーのキャリア形成をどうするかという点が難しいと思います。 メンバーの志向に合わせての将来像を見据えて現在の業務に取り組んでもらいたい のですが、実際のタスクとそうしたキャリアの方向性が必ずしもぴったりと合うときばかりではないので、ここをどう揃えていくかという点にも苦労はしています。 新居 : なるほど、岡村さんの場合は元々として島根と東京という立地間でのマネジメントをされていたと思うんですが、リモートコミュニケーションが中心という環境での苦労は何かありましたか。 岡村 : 実はこれと言って無いんですよ。それでもちゃんと上手く機能している要因としては、2 つあります。1 つは島根の方に現地のメンバーを取りしきってくれるスキルを持ったメンバーが居てくれたことです。ここは今でも本当に助かっています。 また、当初から技術的な部分も含めて私もメンバーと一緒に勉強しながら、新しい取り組みをするというスタンスを持ってプロジェクトを推進できたことです。ですので、離れたところから命令する人のような感じではなく、 チームで一緒にプロジェクトを進める人という認識を持ってもらえた んじゃないかなと考えています。 もちろん、関係値を作れるまでは私が最初の頃は 1 ヶ月に 1~2 回程度島根に出張して、実際にメンバーと会ったりすることもしていましたが。 GM を担う上で、役に立った経験・知識 新居 : ここからは、お二人が今までの業務の中で積んできた経験・知識の内、現在 GM として活動する上で役に立っているものとして、どんなものがあるのか聞ければと思います。 平山 : そうですね、一番役に立っているなと感じているのは前職で経験した「 様々なステークホルダーとの主体性を持った折衝経験 」です。色々な会社や立場の方とコミュニケーションを取ることが多かったんですね。専門性もそれぞれ違う方達とお話して物事を進める経験ができたことは、今の GM という役割に本当に役立っていると思います。 岡村 : 私が役に立っていると感じる経験は、「 一回深く細かいところまで業務を見てみて理解をしてから、改めて俯瞰した視点で業務を見直してメンバーにお願いする 」という習慣です。この相反する方法をバランス良くできるようになっているというのが、良い点なのかなと思っています。また、深く見るというのは自分が興味を持っている分野でないと中々難しいので、何にでも興味を持って業務に取り組むという心持ちも必要になるかと考えています。 こうした形で業務を分解してメンバーにお願いできるところはしながら、GM としては適切に権限委譲していくというのに役立っています。 エンジニアのピープルマネジメントで意識していること 新居 : 今までのお話でも少し出ている話題になるのですが、GM としてエンジニアのマネジメントで意識しているポイントって、どんなことがありますか。 平山 : 自分達が作る プロダクトへの興味関心・解像度を高め、何を作るのか 。という点において各所コミュニケーションを含めて主体的に動くこと。そうした積み重ねの延長線上にあるエンジニアとしてのキャリア形成を意識しています。 この考え方に加えて「プロダクトの持続可能性を高める」というテーマで、エンジニア・デザイナー・ディレクター・ QA エンジニア・カスタマーサクセスといったプロダクトに関わる人達の専門性を踏まえたタスクの再配布・プロジェクト設計を行う。といった体制作りも推進しようとしています。 新居 : 「プロダクトの持続可能性を高める」というのは、すごく難しい試みですよね。 平山 : 確かにとても難しいなと思います。でも打ち手としては色々あるのではないかと考えていて。「属人性の排除」といった点は、分かりやすいのではないかなと思います。誰かに依存した状態は、組織変更や事業スケールの変化に弱くなりがちですよね。 大事なのは「人から組織への移行」「仕組み化」と捉えています。「できる人を増やす」については、大事だけど秘伝のタレが受け継がれるだけになってしまうので、持続可能性の観点では本質的ではないかなと。 一方で「仕組み化するための計画的な属人性」については推奨できると考えてます。新しいことをいきなり「組織に転換」や「人を増やしてローテする」だと、ナレッジが蓄積されづらく、次の一手が打ちづらくなるので。 新居 : そうした取り組みをするのに、例えばエンジニアだと作ってみたものがプロダクトの目指す方向性とズレが生じていたというような事態があると思うんですが、そうしたズレを事前に仕組みで抑えるような事をしているんですか。 平山 : きっちりとした仕組みなどは作ってはいないです。仕組み化というよりも、そうならないように メンバーから上がってきた疑問などに対する壁打ちなどは気軽にできる ようにしています。また、そういった相談を気軽にできるような自分自身のプロデュースといいますか、キャラ作りみたいなものも含めてメンバーが相談しにくいという空気を作らないようにはしていますね。 新居 : ありがとうございます。岡村さんはどんな意識をしていますか。 岡村 : やっぱり平山さんに全く同感ですね（笑） 付け加えると、ソフト面ですが メンバーであるエンジニアが楽しめる環境作り というところを意識しています。楽しさにも色々な種類があるとは思いますが、単にコーディングするだけではなく、やはりプロダクトそれ自体の提供価値というものをしっかりと共有して、プロダクトを作ること自体に楽しさを感じてもらう…というのは重要じゃないかなと思っています。 また楽しさの別側面ですが、新しいテクノロジーなどもどんどんと取り入れることができるような仕組み作りもしています。島根のメンバーは今回のプロジェクトで初めて Ruby を使うというメンバーも多かったので、ここで楽しさを感じられないと、こうしたテクノロジー自体を嫌いになってしまう恐れがあるなと思ったので。 そうした「楽しい仕事」にしていくと「時間をかけなきゃ」ではなく「時間をかけたい」という感じで取り組めるようになると思います。 GM という役割の醍醐味とは 新居 : それでは終盤になってきましたが、GM の「やりがい」や「醍醐味」はどういったものになりますか。 岡村 : 一番は「ピープルマネジメント」になるんじゃないかと考えています。最近、岸田首相の所信表明演説で聞いて感銘を受けたアフリカの諺ですが「早く行きたいなら 1 人で行け、遠くへ行きたいならみんなで行け」という言葉はピープルマネジメントの本質なんじゃないかなと思っています。 メンバーと一緒に遠くに行くために組織作り などをしていけるのが醍醐味だと感じています。 平山 : メンバーの 個人スキルを高めつつ「チーム」に還元してもらうための仕組み を作っていく。というのは、醍醐味と言えるのかなと。CTO インタビューで田中も言っていますが「チームバリュー」は大切だと考えています。 チームといっても、狭義のチームではなくプロダクトに関わる関係者全員を含めたチームという感じで意識しています。開発組織に閉じないバリューの発揮がメンバーそれぞれでできると心強いと思います。 メドレーで GM やリードエンジニアのロールに向いている方 新居 : 最後になるのですが、メドレーで GM やテックリードといったロールに向いているのは、どんな人だと思いますか。 平山 : 基本的に 物事を前に進めるための解像度を高く描ける人 かなと思っています。何を誰のためにというのを体現しつつ、関係者を引っぱっていける人ですね。メドレーの Our Essentials 全般必要だとは思いますが、その中でも「成果を出す」「自分をアップデート」「組織水準を高める」「革新と改善を主導」というところが必要になるかな。困難な状況でも結果を出しつつ、自分の行動も高めていき、結果組織・プロダクトを良くしていける…というのがメドレーのリードと呼ばれているエンジニアかと思います。 やり方としては、マイクロマネジメントではなく、基本となる考え方をちゃんと伝えてメンバーに学んでもらう…という、やり方ができる人が向いていると思います。 岡村 : 困難な状況であっても何とかして前に進めることができる人 でしょうか。無理矢理に進めるというわけではなく、状況の整理や色々な部署との調整などもしたりして、何とか結果という形にしていける能力がある人がリードとしてメンバーを引っぱっていける人だと思います。 もちろん、フェイズによってメンバーとの関わりなどはちゃんと調整していける柔軟さなども必要になると思います。 新居 : なるほど。本日は色々なお話をしていただきまして、ありがとうございました! さいごに メドレーの GM 二人に仕事について聞いていきました。 前回の CTO インタビューでも語られた開発組織の話ですが、より現場に近い GM という立場のメンバーからの話でまた違った雰囲気などを感じていただけたかと思います。 このような GM を「ぜひやりたい!」という方や「こんな上司の元で自分の力を発揮していきたい!」という方はぜひカジュアルにお話ができればと思います。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの新居です。 今回のインタビューは前回の CTO へのインタビュー に続いて、メドレーの開発組織についてご紹介していきたいと思います。 メドレーでは開発組織をリードするロールとして、CTO の他、「グループマネージャ」(以下、GM)という役職があります。今回は医療プラットフォーム(以下、医療 PF)における開発グループの GM を担う二人に、具体的にどのような役割なのか聞いていきます。 インタビュイー紹介 今回の紹介はインタビュー中で前職からメドレー入社の話を聞いているので、シンプルにお送りします。 平山さん 医療 PF 第一本部 プロダクト開発室 第四開発グループ GM。現在は CLINICS 基幹システムチームのマネジメントを担当。 岡村さん 医療 PF 第一本部 プロダクト開発室 第三開発グループ GM。現在はレセコン(電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア)新規開発チームのマネジメントを担当。 左から岡村さん、平山さん、筆者 前職までの経歴とメドレー入社の理由について 二人の経験について 新居 : 早速始めていきますが、まずはお二人の経歴を教えていただきたいと思います。 平山 : メドレーは 2 社目の会社となります。前職は SIer で 14~5 年くらい受託開発や客先常駐して開発をしていました。SIer というと場合によっては二次請け・三次請けの開発をしているところもあるんですが、自分は一次請けとして直接顧客と関わる形で業務を行っていました。 顧客のサービスをステークホルダーと提案・折衝しながら、技術選定・要件定義から開発、リリースまで行い、そこからの保守運用といった部分までの一連の流れを様々な業態の顧客と関わらせて頂きました。 新居 : ありがとうございます。かなり自社開発と同じ感覚の開発を長年されてきたんですね。それでは、岡村さんお願いします。 岡村 : 新卒で外資系の IT コンサルティング会社で IT コンサルタントとしてキャリアを始めました。その中でも特に「情報系」と呼ばれるデータアナリティクスや BI (Business Intelligence) などを取り扱う部門で業務をしていました。領域的には金融・製薬・省庁など堅めの領域を主に担当していたので、いわゆる Web アプリケーションを作るというよりは SQL をガリガリ書いてデータ分析を基に業務改善していく…という感じの業務が多かったです。 2 社目はスタートアップ企業の立ち上げフェイズにジョインしました。その会社はいわゆる Insure Tech と呼ばれる保険業界 x テクノロジー領域のサービスを作っている会社でした。そこで、その会社でのプロダクトマネージャ業務と、運転資金を確保するために大手保険会社向けのコンサルタント業務に半々で従事していました。 その後にメドレーにジョインするという経歴です。 岡村さん メドレー入社の経緯について 新居 : ありがとうございます、お二人はメドレーに入社してどのくらい経ちますっけ? 平山 : 私は 3 年半ですね。 岡村 : 私は 4 年経ちました。 新居 : もうそんなに経つんですね。みなさんの前職を転職しようと思った動機とはどんなものだったんですか? 平山 : 前職でプレイングマネージャとして業務をしてきましたが、キャリアを重ねてくると徐々にマネジメントの割合が増えてきます。それ自体は自然なことではあるのですが、前職の延長線上でマネジメントに比重を置くことに対して、危機感を感じていたんです。手を動かす部分を含めて、エンジニアとして良いキャリアを積むには別の環境に身を置く必要があると思い、転職を決意しました。 転職に際しては、自分が 身近に感じるサービスで特に自分の家族が関わるような領域が良いと考えており、医療はそうした意味でぴったりな領域 でした。これらの条件で転職エージェントを通じてメドレーに辿りつきました。 平山さん 岡村 : 先程も少し話しましたが、前職は自社プロダクトと他社向けコンサルティングを並行して運営していた会社でした。しかし、途中から経営方針が変わってコンサルティング業務をメインに据えるようになったんです。自分としては、自社プロダクトを作っている点を大事に考えていたため、転職を考えはじめました。 会社選びの軸としては、もちろん自社サービスが事業の主軸である会社というのが一番でした。他の条件としては「上場一歩手前」くらいのフェイズの会社というものがありました。これは、そのくらいのフェイズの会社であれば今までやっていた事業をいきなりピボットするという可能性が限りなく低いのではないかと考えたからです。そんな感じで会社を探していて、LinkedIn の広告経由でメドレーにアプローチして入社しました。 新居 : 岡村さんは次の会社の事業領域は、意識していたんでしょうか? 岡村 : 医療領域を名指しで考えていたわけではないです。しかし、いわゆる 昔ながらの慣習などが多く残るような業界や領域を、自分達が手がけたサービスで変えていくというのが良い という考えでした。これは前職でも考えていたことだったので、引き続き志向していました。 メドレー入社後にどのような仕事をしていたのか 新居 : ありがとうございます。そんな経緯でメドレーに入社したお二人ですが、入社後はどのような業務をされていたんでしょうか。 平山 : 私は入社後から一貫して CLINICS カルテを担当しています。入社後は医療に関する業務知識を身につけながら、周辺業務から徐々に関わっていきシステム面のキャッチアップをしていきました。一番最初に携わったプロジェクトとしては、CLINICS カルテにおける診察業務のコントロールを担う「診療ステータス」の拡張を行うという、カルテ全体に影響のある大きな改修に携わりました。それ以降も、小さいタスクを捌きつつ、中・大規模な施策に携わってきた感じです。 そこから医療 PF 横断のプロジェクトにも関わっていくようになりました。CLINICS というプロダクトは患者が使用するアプリを始め、調剤・歯科のサービスも提供しています。 医療 PF 全体の体験設計を踏まえて、周辺プロダクトとも積極的に関わっていく必要がある という点は特徴的だと思います。 岡村 : 私は入社当時は「社長室コンサル」という役割で入社し、この部署は M&A などをメインに担当していた部署だったんです。そのため最初にアサインされたのが NaCl メディカル社(現在はメドレー本体に統合)の業務面での PMI でした。これと平行して、現在も引き続き携わっている新しいレセコンを作るプロジェクトのプロダクトマネージャを担当してきました。 新規レセコンは CLINICS カルテと連携しているプロダクトなので、平山さんが率いるチームと連携 しながら、このプロダクトを作っている開発チームを率いています。 GM としてのミッションと就任してから変わったこと・変わらないこと 新居 : 話を聞いていると、お二人とも最初の仕事を順調にスケールアップしていったという形で現在の業務に繋っているんですね。さて、ここからは GM に就任してからの自身の業務がどのように変化してきたのかという点を聞きたいのですが、この点どうでしょうか。 平山 : ミッションはやはり変化しました。GM としてのミッションで一番求められるものは「 プロダクトを前進させる 」という部分と考えています。自身の管掌組織は当然ですが、組織を横断する形の取り組みも必要になります。 「ピープルマネジメント」という点も GM としての変化の１つかなと思います。とはいえ、先ほどの話と通じる部分はあり**「プロダクトに軸足を置いて目線を合わせていくこと」が基本**となります。また、組織上の持続可能性という意味においても「任せていく」というところは大事にしています。メンバーに優秀な方が多いので助けられている部分は多いと感じます。 エンジニアリングという意味では、手を動かす量は減りました。手の動かし方という意味では入社当初から横の動きを見るようにはしていたので GM になって変わったという部分は無いですね。 岡村 : レセコン新規開発プロジェクトでの GM のミッションとして、「プロジェクトの完遂」、「チームメンバーのピープルマネジメント」、「Tech Studio MATSUE(島根県にあるメドレーの拠点。レセコン新規開発プロジェクトの開発をしている)の管理」がメインになります。 GM に就任したタイミングは NaCl メディカル社がメドレー本体に吸収合併されたというタイミングでした。就任前はグループ会社ということもあり、開発業務を受発注するという動きに近い感じで協業してきました。GM になってからは、同じ会社になったのでより近い距離でチーム開発をするようになったり、メンバーのピープルマネジメントの割合が多くなるという変化がありました。 担当領域としてはレセコンのプロダクトマネジメントをしているという部分は変わらない部分です。また平山さんがおっしゃっていたように、いつまでも自分が上にいて指揮するという状態を良しとするのではなく、 メンバーの人をどんどんと上のロールに引き上げていくというのが GM の役割の 1 つ かと思うので、そういう意識でメンバーのマネジメントをしています。 エンジニアリングとマネジメントの比率はプロダクトのフェイズによって変わってくるし、変わるべきかなと思っています。現在は 8 対 2 でマネジメントの比率が多くなっています。一方でプロダクトの初期でどんどんと開発をしていかないといけないという場合には自分も含めて人手をかけて開発していくようにします。 新居 : お話をうかがうと、やはり GM 前よりもマネジメントの比率が多くなっているのではないかと思うのですが、葛藤などはありましたか。 平山 : 元々の自分のスタンスとして「自分も駒の一つ」としてプロダクト開発を推進していくという思考があります。GM の話が来たときにも、やれるかなという不安感はありましたが、今の場面においては自身がやった方が良いと感じて受けました。 岡村 : 私は出自がエンジニアではないというのもあって、葛藤のようなものも平山さんとは違って、特にありませんでした。元々 NaCl メディカル社だった松江オフィスとのハブになるのは、自分しかいないと思っていましたので躊躇のようなものも全く無かったです。 GM で苦労したポイント・どう克服していたか 新居 : ありがとうございます。では、GM になって苦労したとか大変だったというところってどんなところがありましたか。 平山 : 自分は口下手な方なんで、以前より喋る機会が増えたのが困ったところですね（笑） 新居 : 平山さんに口下手な印象は全然ありませんが（笑） 平山 : 他には、これはどちらかというと PdM 属性の仕事にも関わってくるんですが、開発計画の策定は大変です(メドレーでは 3 ヶ月ごとに開発計画を立てている)。 大規模な施策の実施と並行して優先度の高いタスクの差し込みを踏まえて、優先度の再設計や施策のフェージングや運用の検討したりしています。 自分で抱え込む必要はないですが、関係者と調整しつつも最終意思決定は自分になるので、様々な葛藤をしながら取り組んでいます 。 新居 : ピープルマネジメント面では何かありましたか。 平山 : 先程お話した「プロダクトに軸足を置いて目線を合わせていくこと」を大切にコミュニケーションを実施し、日々の業務を通してメンバー一人一人でシナジーが出る・良いキャリアが重ねられるようにしたいと考えていますが、先ほどの開発計画の難しさもここにあります。 新居 : ありがとうございます。では岡村さんはいかがでしょう。 岡村 : 平山さんに全く同感ですね（笑） 冗談は置いておいて、計画外の差し込みタスクなどが入ると、どうしてもチームの負荷が高くなってくるので、そこをコントロールしきれずに申し訳ないなと思うことがあります。 他には、メンバーのキャリア形成をどうするかという点が難しいと思います。 メンバーの志向に合わせての将来像を見据えて現在の業務に取り組んでもらいたい のですが、実際のタスクとそうしたキャリアの方向性が必ずしもぴったりと合うときばかりではないので、ここをどう揃えていくかという点にも苦労はしています。 新居 : なるほど、岡村さんの場合は元々として島根と東京という立地間でのマネジメントをされていたと思うんですが、リモートコミュニケーションが中心という環境での苦労は何かありましたか。 岡村 : 実はこれと言って無いんですよ。それでもちゃんと上手く機能している要因としては、2 つあります。1 つは島根の方に現地のメンバーを取りしきってくれるスキルを持ったメンバーが居てくれたことです。ここは今でも本当に助かっています。 また、当初から技術的な部分も含めて私もメンバーと一緒に勉強しながら、新しい取り組みをするというスタンスを持ってプロジェクトを推進できたことです。ですので、離れたところから命令する人のような感じではなく、 チームで一緒にプロジェクトを進める人という認識を持ってもらえた んじゃないかなと考えています。 もちろん、関係値を作れるまでは私が最初の頃は 1 ヶ月に 1~2 回程度島根に出張して、実際にメンバーと会ったりすることもしていましたが。 GM を担う上で、役に立った経験・知識 新居 : ここからは、お二人が今までの業務の中で積んできた経験・知識の内、現在 GM として活動する上で役に立っているものとして、どんなものがあるのか聞ければと思います。 平山 : そうですね、一番役に立っているなと感じているのは前職で経験した「 様々なステークホルダーとの主体性を持った折衝経験 」です。色々な会社や立場の方とコミュニケーションを取ることが多かったんですね。専門性もそれぞれ違う方達とお話して物事を進める経験ができたことは、今の GM という役割に本当に役立っていると思います。 岡村 : 私が役に立っていると感じる経験は、「 一回深く細かいところまで業務を見てみて理解をしてから、改めて俯瞰した視点で業務を見直してメンバーにお願いする 」という習慣です。この相反する方法をバランス良くできるようになっているというのが、良い点なのかなと思っています。また、深く見るというのは自分が興味を持っている分野でないと中々難しいので、何にでも興味を持って業務に取り組むという心持ちも必要になるかと考えています。 こうした形で業務を分解してメンバーにお願いできるところはしながら、GM としては適切に権限委譲していくというのに役立っています。 エンジニアのピープルマネジメントで意識していること 新居 : 今までのお話でも少し出ている話題になるのですが、GM としてエンジニアのマネジメントで意識しているポイントって、どんなことがありますか。 平山 : 自分達が作る プロダクトへの興味関心・解像度を高め、何を作るのか 。という点において各所コミュニケーションを含めて主体的に動くこと。そうした積み重ねの延長線上にあるエンジニアとしてのキャリア形成を意識しています。 この考え方に加えて「プロダクトの持続可能性を高める」というテーマで、エンジニア・デザイナー・ディレクター・ QA エンジニア・カスタマーサクセスといったプロダクトに関わる人達の専門性を踏まえたタスクの再配布・プロジェクト設計を行う。といった体制作りも推進しようとしています。 新居 : 「プロダクトの持続可能性を高める」というのは、すごく難しい試みですよね。 平山 : 確かにとても難しいなと思います。でも打ち手としては色々あるのではないかと考えていて。「属人性の排除」といった点は、分かりやすいのではないかなと思います。誰かに依存した状態は、組織変更や事業スケールの変化に弱くなりがちですよね。 大事なのは「人から組織への移行」「仕組み化」と捉えています。「できる人を増やす」については、大事だけど秘伝のタレが受け継がれるだけになってしまうので、持続可能性の観点では本質的ではないかなと。 一方で「仕組み化するための計画的な属人性」については推奨できると考えてます。新しいことをいきなり「組織に転換」や「人を増やしてローテする」だと、ナレッジが蓄積されづらく、次の一手が打ちづらくなるので。 新居 : そうした取り組みをするのに、例えばエンジニアだと作ってみたものがプロダクトの目指す方向性とズレが生じていたというような事態があると思うんですが、そうしたズレを事前に仕組みで抑えるような事をしているんですか。 平山 : きっちりとした仕組みなどは作ってはいないです。仕組み化というよりも、そうならないように メンバーから上がってきた疑問などに対する壁打ちなどは気軽にできる ようにしています。また、そういった相談を気軽にできるような自分自身のプロデュースといいますか、キャラ作りみたいなものも含めてメンバーが相談しにくいという空気を作らないようにはしていますね。 新居 : ありがとうございます。岡村さんはどんな意識をしていますか。 岡村 : やっぱり平山さんに全く同感ですね（笑） 付け加えると、ソフト面ですが メンバーであるエンジニアが楽しめる環境作り というところを意識しています。楽しさにも色々な種類があるとは思いますが、単にコーディングするだけではなく、やはりプロダクトそれ自体の提供価値というものをしっかりと共有して、プロダクトを作ること自体に楽しさを感じてもらう…というのは重要じゃないかなと思っています。 また楽しさの別側面ですが、新しいテクノロジーなどもどんどんと取り入れることができるような仕組み作りもしています。島根のメンバーは今回のプロジェクトで初めて Ruby を使うというメンバーも多かったので、ここで楽しさを感じられないと、こうしたテクノロジー自体を嫌いになってしまう恐れがあるなと思ったので。 そうした「楽しい仕事」にしていくと「時間をかけなきゃ」ではなく「時間をかけたい」という感じで取り組めるようになると思います。 GM という役割の醍醐味とは 新居 : それでは終盤になってきましたが、GM の「やりがい」や「醍醐味」はどういったものになりますか。 岡村 : 一番は「ピープルマネジメント」になるんじゃないかと考えています。最近、岸田首相の所信表明演説で聞いて感銘を受けたアフリカの諺ですが「早く行きたいなら 1 人で行け、遠くへ行きたいならみんなで行け」という言葉はピープルマネジメントの本質なんじゃないかなと思っています。 メンバーと一緒に遠くに行くために組織作り などをしていけるのが醍醐味だと感じています。 平山 : メンバーの 個人スキルを高めつつ「チーム」に還元してもらうための仕組み を作っていく。というのは、醍醐味と言えるのかなと。CTO インタビューで田中も言っていますが「チームバリュー」は大切だと考えています。 チームといっても、狭義のチームではなくプロダクトに関わる関係者全員を含めたチームという感じで意識しています。開発組織に閉じないバリューの発揮がメンバーそれぞれでできると心強いと思います。 メドレーで GM やリードエンジニアのロールに向いている方 新居 : 最後になるのですが、メドレーで GM やテックリードといったロールに向いているのは、どんな人だと思いますか。 平山 : 基本的に 物事を前に進めるための解像度を高く描ける人 かなと思っています。何を誰のためにというのを体現しつつ、関係者を引っぱっていける人ですね。メドレーの Our Essentials 全般必要だとは思いますが、その中でも「成果を出す」「自分をアップデート」「組織水準を高める」「革新と改善を主導」というところが必要になるかな。困難な状況でも結果を出しつつ、自分の行動も高めていき、結果組織・プロダクトを良くしていける…というのがメドレーのリードと呼ばれているエンジニアかと思います。 やり方としては、マイクロマネジメントではなく、基本となる考え方をちゃんと伝えてメンバーに学んでもらう…という、やり方ができる人が向いていると思います。 岡村 : 困難な状況であっても何とかして前に進めることができる人 でしょうか。無理矢理に進めるというわけではなく、状況の整理や色々な部署との調整などもしたりして、何とか結果という形にしていける能力がある人がリードとしてメンバーを引っぱっていける人だと思います。 もちろん、フェイズによってメンバーとの関わりなどはちゃんと調整していける柔軟さなども必要になると思います。 新居 : なるほど。本日は色々なお話をしていただきまして、ありがとうございました! さいごに メドレーの GM 二人に仕事について聞いていきました。 前回の CTO インタビューでも語られた開発組織の話ですが、より現場に近い GM という立場のメンバーからの話でまた違った雰囲気などを感じていただけたかと思います。 このような GM を「ぜひやりたい!」という方や「こんな上司の元で自分の力を発揮していきたい!」という方はぜひカジュアルにお話ができればと思います。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの新居です。 今回のインタビューは前回の CTO へのインタビュー に続いて、メドレーの開発組織についてご紹介していきたいと思います。 メドレーでは開発組織をリードするロールとして、CTO の他、「グループマネージャ」(以下、GM)という役職があります。今回は医療プラットフォーム(以下、医療 PF)における開発グループの GM を担う二人に、具体的にどのような役割なのか聞いていきます。 インタビュイー紹介 今回の紹介はインタビュー中で前職からメドレー入社の話を聞いているので、シンプルにお送りします。 平山さん 医療 PF 第一本部 プロダクト開発室 第四開発グループ GM。現在は CLINICS 基幹システムチームのマネジメントを担当。 岡村さん 医療 PF 第一本部 プロダクト開発室 第三開発グループ GM。現在はレセコン(電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア)新規開発チームのマネジメントを担当。 左から岡村さん、平山さん、筆者 前職までの経歴とメドレー入社の理由について 二人の経験について 新居 : 早速始めていきますが、まずはお二人の経歴を教えていただきたいと思います。 平山 : メドレーは 2 社目の会社となります。前職は SIer で 14~5 年くらい受託開発や客先常駐して開発をしていました。SIer というと場合によっては二次請け・三次請けの開発をしているところもあるんですが、自分は一次請けとして直接顧客と関わる形で業務を行っていました。 顧客のサービスをステークホルダーと提案・折衝しながら、技術選定・要件定義から開発、リリースまで行い、そこからの保守運用といった部分までの一連の流れを様々な業態の顧客と関わらせて頂きました。 新居 : ありがとうございます。かなり自社開発と同じ感覚の開発を長年されてきたんですね。それでは、岡村さんお願いします。 岡村 : 新卒で外資系の IT コンサルティング会社で IT コンサルタントとしてキャリアを始めました。その中でも特に「情報系」と呼ばれるデータアナリティクスや BI (Business Intelligence) などを取り扱う部門で業務をしていました。領域的には金融・製薬・省庁など堅めの領域を主に担当していたので、いわゆる Web アプリケーションを作るというよりは SQL をガリガリ書いてデータ分析を基に業務改善していく…という感じの業務が多かったです。 2 社目はスタートアップ企業の立ち上げフェイズにジョインしました。その会社はいわゆる Insure Tech と呼ばれる保険業界 x テクノロジー領域のサービスを作っている会社でした。そこで、その会社でのプロダクトマネージャ業務と、運転資金を確保するために大手保険会社向けのコンサルタント業務に半々で従事していました。 その後にメドレーにジョインするという経歴です。 岡村さん メドレー入社の経緯について 新居 : ありがとうございます、お二人はメドレーに入社してどのくらい経ちますっけ? 平山 : 私は 3 年半ですね。 岡村 : 私は 4 年経ちました。 新居 : もうそんなに経つんですね。みなさんの前職を転職しようと思った動機とはどんなものだったんですか? 平山 : 前職でプレイングマネージャとして業務をしてきましたが、キャリアを重ねてくると徐々にマネジメントの割合が増えてきます。それ自体は自然なことではあるのですが、前職の延長線上でマネジメントに比重を置くことに対して、危機感を感じていたんです。手を動かす部分を含めて、エンジニアとして良いキャリアを積むには別の環境に身を置く必要があると思い、転職を決意しました。 転職に際しては、自分が 身近に感じるサービスで特に自分の家族が関わるような領域が良いと考えており、医療はそうした意味でぴったりな領域 でした。これらの条件で転職エージェントを通じてメドレーに辿りつきました。 平山さん 岡村 : 先程も少し話しましたが、前職は自社プロダクトと他社向けコンサルティングを並行して運営していた会社でした。しかし、途中から経営方針が変わってコンサルティング業務をメインに据えるようになったんです。自分としては、自社プロダクトを作っている点を大事に考えていたため、転職を考えはじめました。 会社選びの軸としては、もちろん自社サービスが事業の主軸である会社というのが一番でした。他の条件としては「上場一歩手前」くらいのフェイズの会社というものがありました。これは、そのくらいのフェイズの会社であれば今までやっていた事業をいきなりピボットするという可能性が限りなく低いのではないかと考えたからです。そんな感じで会社を探していて、LinkedIn の広告経由でメドレーにアプローチして入社しました。 新居 : 岡村さんは次の会社の事業領域は、意識していたんでしょうか? 岡村 : 医療領域を名指しで考えていたわけではないです。しかし、いわゆる 昔ながらの慣習などが多く残るような業界や領域を、自分達が手がけたサービスで変えていくというのが良い という考えでした。これは前職でも考えていたことだったので、引き続き志向していました。 メドレー入社後にどのような仕事をしていたのか 新居 : ありがとうございます。そんな経緯でメドレーに入社したお二人ですが、入社後はどのような業務をされていたんでしょうか。 平山 : 私は入社後から一貫して CLINICS カルテを担当しています。入社後は医療に関する業務知識を身につけながら、周辺業務から徐々に関わっていきシステム面のキャッチアップをしていきました。一番最初に携わったプロジェクトとしては、CLINICS カルテにおける診察業務のコントロールを担う「診療ステータス」の拡張を行うという、カルテ全体に影響のある大きな改修に携わりました。それ以降も、小さいタスクを捌きつつ、中・大規模な施策に携わってきた感じです。 そこから医療 PF 横断のプロジェクトにも関わっていくようになりました。CLINICS というプロダクトは患者が使用するアプリを始め、調剤・歯科のサービスも提供しています。 医療 PF 全体の体験設計を踏まえて、周辺プロダクトとも積極的に関わっていく必要がある という点は特徴的だと思います。 岡村 : 私は入社当時は「社長室コンサル」という役割で入社し、この部署は M&A などをメインに担当していた部署だったんです。そのため最初にアサインされたのが NaCl メディカル社(現在はメドレー本体に統合)の業務面での PMI でした。これと平行して、現在も引き続き携わっている新しいレセコンを作るプロジェクトのプロダクトマネージャを担当してきました。 新規レセコンは CLINICS カルテと連携しているプロダクトなので、平山さんが率いるチームと連携 しながら、このプロダクトを作っている開発チームを率いています。 GM としてのミッションと就任してから変わったこと・変わらないこと 新居 : 話を聞いていると、お二人とも最初の仕事を順調にスケールアップしていったという形で現在の業務に繋っているんですね。さて、ここからは GM に就任してからの自身の業務がどのように変化してきたのかという点を聞きたいのですが、この点どうでしょうか。 平山 : ミッションはやはり変化しました。GM としてのミッションで一番求められるものは「 プロダクトを前進させる 」という部分と考えています。自身の管掌組織は当然ですが、組織を横断する形の取り組みも必要になります。 「ピープルマネジメント」という点も GM としての変化の１つかなと思います。とはいえ、先ほどの話と通じる部分はあり**「プロダクトに軸足を置いて目線を合わせていくこと」が基本**となります。また、組織上の持続可能性という意味においても「任せていく」というところは大事にしています。メンバーに優秀な方が多いので助けられている部分は多いと感じます。 エンジニアリングという意味では、手を動かす量は減りました。手の動かし方という意味では入社当初から横の動きを見るようにはしていたので GM になって変わったという部分は無いですね。 岡村 : レセコン新規開発プロジェクトでの GM のミッションとして、「プロジェクトの完遂」、「チームメンバーのピープルマネジメント」、「Tech Studio MATSUE(島根県にあるメドレーの拠点。レセコン新規開発プロジェクトの開発をしている)の管理」がメインになります。 GM に就任したタイミングは NaCl メディカル社がメドレー本体に吸収合併されたというタイミングでした。就任前はグループ会社ということもあり、開発業務を受発注するという動きに近い感じで協業してきました。GM になってからは、同じ会社になったのでより近い距離でチーム開発をするようになったり、メンバーのピープルマネジメントの割合が多くなるという変化がありました。 担当領域としてはレセコンのプロダクトマネジメントをしているという部分は変わらない部分です。また平山さんがおっしゃっていたように、いつまでも自分が上にいて指揮するという状態を良しとするのではなく、 メンバーの人をどんどんと上のロールに引き上げていくというのが GM の役割の 1 つ かと思うので、そういう意識でメンバーのマネジメントをしています。 エンジニアリングとマネジメントの比率はプロダクトのフェイズによって変わってくるし、変わるべきかなと思っています。現在は 8 対 2 でマネジメントの比率が多くなっています。一方でプロダクトの初期でどんどんと開発をしていかないといけないという場合には自分も含めて人手をかけて開発していくようにします。 新居 : お話をうかがうと、やはり GM 前よりもマネジメントの比率が多くなっているのではないかと思うのですが、葛藤などはありましたか。 平山 : 元々の自分のスタンスとして「自分も駒の一つ」としてプロダクト開発を推進していくという思考があります。GM の話が来たときにも、やれるかなという不安感はありましたが、今の場面においては自身がやった方が良いと感じて受けました。 岡村 : 私は出自がエンジニアではないというのもあって、葛藤のようなものも平山さんとは違って、特にありませんでした。元々 NaCl メディカル社だった松江オフィスとのハブになるのは、自分しかいないと思っていましたので躊躇のようなものも全く無かったです。 GM で苦労したポイント・どう克服していたか 新居 : ありがとうございます。では、GM になって苦労したとか大変だったというところってどんなところがありましたか。 平山 : 自分は口下手な方なんで、以前より喋る機会が増えたのが困ったところですね（笑） 新居 : 平山さんに口下手な印象は全然ありませんが（笑） 平山 : 他には、これはどちらかというと PdM 属性の仕事にも関わってくるんですが、開発計画の策定は大変です(メドレーでは 3 ヶ月ごとに開発計画を立てている)。 大規模な施策の実施と並行して優先度の高いタスクの差し込みを踏まえて、優先度の再設計や施策のフェージングや運用の検討したりしています。 自分で抱え込む必要はないですが、関係者と調整しつつも最終意思決定は自分になるので、様々な葛藤をしながら取り組んでいます 。 新居 : ピープルマネジメント面では何かありましたか。 平山 : 先程お話した「プロダクトに軸足を置いて目線を合わせていくこと」を大切にコミュニケーションを実施し、日々の業務を通してメンバー一人一人でシナジーが出る・良いキャリアが重ねられるようにしたいと考えていますが、先ほどの開発計画の難しさもここにあります。 新居 : ありがとうございます。では岡村さんはいかがでしょう。 岡村 : 平山さんに全く同感ですね（笑） 冗談は置いておいて、計画外の差し込みタスクなどが入ると、どうしてもチームの負荷が高くなってくるので、そこをコントロールしきれずに申し訳ないなと思うことがあります。 他には、メンバーのキャリア形成をどうするかという点が難しいと思います。 メンバーの志向に合わせての将来像を見据えて現在の業務に取り組んでもらいたい のですが、実際のタスクとそうしたキャリアの方向性が必ずしもぴったりと合うときばかりではないので、ここをどう揃えていくかという点にも苦労はしています。 新居 : なるほど、岡村さんの場合は元々として島根と東京という立地間でのマネジメントをされていたと思うんですが、リモートコミュニケーションが中心という環境での苦労は何かありましたか。 岡村 : 実はこれと言って無いんですよ。それでもちゃんと上手く機能している要因としては、2 つあります。1 つは島根の方に現地のメンバーを取りしきってくれるスキルを持ったメンバーが居てくれたことです。ここは今でも本当に助かっています。 また、当初から技術的な部分も含めて私もメンバーと一緒に勉強しながら、新しい取り組みをするというスタンスを持ってプロジェクトを推進できたことです。ですので、離れたところから命令する人のような感じではなく、 チームで一緒にプロジェクトを進める人という認識を持ってもらえた んじゃないかなと考えています。 もちろん、関係値を作れるまでは私が最初の頃は 1 ヶ月に 1~2 回程度島根に出張して、実際にメンバーと会ったりすることもしていましたが。 GM を担う上で、役に立った経験・知識 新居 : ここからは、お二人が今までの業務の中で積んできた経験・知識の内、現在 GM として活動する上で役に立っているものとして、どんなものがあるのか聞ければと思います。 平山 : そうですね、一番役に立っているなと感じているのは前職で経験した「 様々なステークホルダーとの主体性を持った折衝経験 」です。色々な会社や立場の方とコミュニケーションを取ることが多かったんですね。専門性もそれぞれ違う方達とお話して物事を進める経験ができたことは、今の GM という役割に本当に役立っていると思います。 岡村 : 私が役に立っていると感じる経験は、「 一回深く細かいところまで業務を見てみて理解をしてから、改めて俯瞰した視点で業務を見直してメンバーにお願いする 」という習慣です。この相反する方法をバランス良くできるようになっているというのが、良い点なのかなと思っています。また、深く見るというのは自分が興味を持っている分野でないと中々難しいので、何にでも興味を持って業務に取り組むという心持ちも必要になるかと考えています。 こうした形で業務を分解してメンバーにお願いできるところはしながら、GM としては適切に権限委譲していくというのに役立っています。 エンジニアのピープルマネジメントで意識していること 新居 : 今までのお話でも少し出ている話題になるのですが、GM としてエンジニアのマネジメントで意識しているポイントって、どんなことがありますか。 平山 : 自分達が作る プロダクトへの興味関心・解像度を高め、何を作るのか 。という点において各所コミュニケーションを含めて主体的に動くこと。そうした積み重ねの延長線上にあるエンジニアとしてのキャリア形成を意識しています。 この考え方に加えて「プロダクトの持続可能性を高める」というテーマで、エンジニア・デザイナー・ディレクター・ QA エンジニア・カスタマーサクセスといったプロダクトに関わる人達の専門性を踏まえたタスクの再配布・プロジェクト設計を行う。といった体制作りも推進しようとしています。 新居 : 「プロダクトの持続可能性を高める」というのは、すごく難しい試みですよね。 平山 : 確かにとても難しいなと思います。でも打ち手としては色々あるのではないかと考えていて。「属人性の排除」といった点は、分かりやすいのではないかなと思います。誰かに依存した状態は、組織変更や事業スケールの変化に弱くなりがちですよね。 大事なのは「人から組織への移行」「仕組み化」と捉えています。「できる人を増やす」については、大事だけど秘伝のタレが受け継がれるだけになってしまうので、持続可能性の観点では本質的ではないかなと。 一方で「仕組み化するための計画的な属人性」については推奨できると考えてます。新しいことをいきなり「組織に転換」や「人を増やしてローテする」だと、ナレッジが蓄積されづらく、次の一手が打ちづらくなるので。 新居 : そうした取り組みをするのに、例えばエンジニアだと作ってみたものがプロダクトの目指す方向性とズレが生じていたというような事態があると思うんですが、そうしたズレを事前に仕組みで抑えるような事をしているんですか。 平山 : きっちりとした仕組みなどは作ってはいないです。仕組み化というよりも、そうならないように メンバーから上がってきた疑問などに対する壁打ちなどは気軽にできる ようにしています。また、そういった相談を気軽にできるような自分自身のプロデュースといいますか、キャラ作りみたいなものも含めてメンバーが相談しにくいという空気を作らないようにはしていますね。 新居 : ありがとうございます。岡村さんはどんな意識をしていますか。 岡村 : やっぱり平山さんに全く同感ですね（笑） 付け加えると、ソフト面ですが メンバーであるエンジニアが楽しめる環境作り というところを意識しています。楽しさにも色々な種類があるとは思いますが、単にコーディングするだけではなく、やはりプロダクトそれ自体の提供価値というものをしっかりと共有して、プロダクトを作ること自体に楽しさを感じてもらう…というのは重要じゃないかなと思っています。 また楽しさの別側面ですが、新しいテクノロジーなどもどんどんと取り入れることができるような仕組み作りもしています。島根のメンバーは今回のプロジェクトで初めて Ruby を使うというメンバーも多かったので、ここで楽しさを感じられないと、こうしたテクノロジー自体を嫌いになってしまう恐れがあるなと思ったので。 そうした「楽しい仕事」にしていくと「時間をかけなきゃ」ではなく「時間をかけたい」という感じで取り組めるようになると思います。 GM という役割の醍醐味とは 新居 : それでは終盤になってきましたが、GM の「やりがい」や「醍醐味」はどういったものになりますか。 岡村 : 一番は「ピープルマネジメント」になるんじゃないかと考えています。最近、岸田首相の所信表明演説で聞いて感銘を受けたアフリカの諺ですが「早く行きたいなら 1 人で行け、遠くへ行きたいならみんなで行け」という言葉はピープルマネジメントの本質なんじゃないかなと思っています。 メンバーと一緒に遠くに行くために組織作り などをしていけるのが醍醐味だと感じています。 平山 : メンバーの 個人スキルを高めつつ「チーム」に還元してもらうための仕組み を作っていく。というのは、醍醐味と言えるのかなと。CTO インタビューで田中も言っていますが「チームバリュー」は大切だと考えています。 チームといっても、狭義のチームではなくプロダクトに関わる関係者全員を含めたチームという感じで意識しています。開発組織に閉じないバリューの発揮がメンバーそれぞれでできると心強いと思います。 メドレーで GM やリードエンジニアのロールに向いている方 新居 : 最後になるのですが、メドレーで GM やテックリードといったロールに向いているのは、どんな人だと思いますか。 平山 : 基本的に 物事を前に進めるための解像度を高く描ける人 かなと思っています。何を誰のためにというのを体現しつつ、関係者を引っぱっていける人ですね。メドレーの Our Essentials 全般必要だとは思いますが、その中でも「成果を出す」「自分をアップデート」「組織水準を高める」「革新と改善を主導」というところが必要になるかな。困難な状況でも結果を出しつつ、自分の行動も高めていき、結果組織・プロダクトを良くしていける…というのがメドレーのリードと呼ばれているエンジニアかと思います。 やり方としては、マイクロマネジメントではなく、基本となる考え方をちゃんと伝えてメンバーに学んでもらう…という、やり方ができる人が向いていると思います。 岡村 : 困難な状況であっても何とかして前に進めることができる人 でしょうか。無理矢理に進めるというわけではなく、状況の整理や色々な部署との調整などもしたりして、何とか結果という形にしていける能力がある人がリードとしてメンバーを引っぱっていける人だと思います。 もちろん、フェイズによってメンバーとの関わりなどはちゃんと調整していける柔軟さなども必要になると思います。 新居 : なるほど。本日は色々なお話をしていただきまして、ありがとうございました! さいごに メドレーの GM 二人に仕事について聞いていきました。 前回の CTO インタビューでも語られた開発組織の話ですが、より現場に近い GM という立場のメンバーからの話でまた違った雰囲気などを感じていただけたかと思います。 このような GM を「ぜひやりたい!」という方や「こんな上司の元で自分の力を発揮していきたい!」という方はぜひカジュアルにお話ができればと思います。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの新居です。 今回のインタビューは前回の CTO へのインタビュー に続いて、メドレーの開発組織についてご紹介していきたいと思います。 メドレーでは開発組織をリードするロールとして、CTO の他、「グループマネージャ」(以下、GM)という役職があります。今回は医療プラットフォーム(以下、医療 PF)における開発グループの GM を担う二人に、具体的にどのような役割なのか聞いていきます。 インタビュイー紹介 今回の紹介はインタビュー中で前職からメドレー入社の話を聞いているので、シンプルにお送りします。 平山さん 医療 PF 第一本部 プロダクト開発室 第四開発グループ GM。現在は CLINICS 基幹システムチームのマネジメントを担当。 岡村さん 医療 PF 第一本部 プロダクト開発室 第三開発グループ GM。現在はレセコン(電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア)新規開発チームのマネジメントを担当。 左から岡村さん、平山さん、筆者 前職までの経歴とメドレー入社の理由について 二人の経験について 新居 : 早速始めていきますが、まずはお二人の経歴を教えていただきたいと思います。 平山 : メドレーは 2 社目の会社となります。前職は SIer で 14~5 年くらい受託開発や客先常駐して開発をしていました。SIer というと場合によっては二次請け・三次請けの開発をしているところもあるんですが、自分は一次請けとして直接顧客と関わる形で業務を行っていました。 顧客のサービスをステークホルダーと提案・折衝しながら、技術選定・要件定義から開発、リリースまで行い、そこからの保守運用といった部分までの一連の流れを様々な業態の顧客と関わらせて頂きました。 新居 : ありがとうございます。かなり自社開発と同じ感覚の開発を長年されてきたんですね。それでは、岡村さんお願いします。 岡村 : 新卒で外資系の IT コンサルティング会社で IT コンサルタントとしてキャリアを始めました。その中でも特に「情報系」と呼ばれるデータアナリティクスや BI (Business Intelligence) などを取り扱う部門で業務をしていました。領域的には金融・製薬・省庁など堅めの領域を主に担当していたので、いわゆる Web アプリケーションを作るというよりは SQL をガリガリ書いてデータ分析を基に業務改善していく…という感じの業務が多かったです。 2 社目はスタートアップ企業の立ち上げフェイズにジョインしました。その会社はいわゆる Insure Tech と呼ばれる保険業界 x テクノロジー領域のサービスを作っている会社でした。そこで、その会社でのプロダクトマネージャ業務と、運転資金を確保するために大手保険会社向けのコンサルタント業務に半々で従事していました。 その後にメドレーにジョインするという経歴です。 岡村さん メドレー入社の経緯について 新居 : ありがとうございます、お二人はメドレーに入社してどのくらい経ちますっけ? 平山 : 私は 3 年半ですね。 岡村 : 私は 4 年経ちました。 新居 : もうそんなに経つんですね。みなさんの前職を転職しようと思った動機とはどんなものだったんですか? 平山 : 前職でプレイングマネージャとして業務をしてきましたが、キャリアを重ねてくると徐々にマネジメントの割合が増えてきます。それ自体は自然なことではあるのですが、前職の延長線上でマネジメントに比重を置くことに対して、危機感を感じていたんです。手を動かす部分を含めて、エンジニアとして良いキャリアを積むには別の環境に身を置く必要があると思い、転職を決意しました。 転職に際しては、自分が 身近に感じるサービスで特に自分の家族が関わるような領域が良いと考えており、医療はそうした意味でぴったりな領域 でした。これらの条件で転職エージェントを通じてメドレーに辿りつきました。 平山さん 岡村 : 先程も少し話しましたが、前職は自社プロダクトと他社向けコンサルティングを並行して運営していた会社でした。しかし、途中から経営方針が変わってコンサルティング業務をメインに据えるようになったんです。自分としては、自社プロダクトを作っている点を大事に考えていたため、転職を考えはじめました。 会社選びの軸としては、もちろん自社サービスが事業の主軸である会社というのが一番でした。他の条件としては「上場一歩手前」くらいのフェイズの会社というものがありました。これは、そのくらいのフェイズの会社であれば今までやっていた事業をいきなりピボットするという可能性が限りなく低いのではないかと考えたからです。そんな感じで会社を探していて、LinkedIn の広告経由でメドレーにアプローチして入社しました。 新居 : 岡村さんは次の会社の事業領域は、意識していたんでしょうか? 岡村 : 医療領域を名指しで考えていたわけではないです。しかし、いわゆる 昔ながらの慣習などが多く残るような業界や領域を、自分達が手がけたサービスで変えていくというのが良い という考えでした。これは前職でも考えていたことだったので、引き続き志向していました。 メドレー入社後にどのような仕事をしていたのか 新居 : ありがとうございます。そんな経緯でメドレーに入社したお二人ですが、入社後はどのような業務をされていたんでしょうか。 平山 : 私は入社後から一貫して CLINICS カルテを担当しています。入社後は医療に関する業務知識を身につけながら、周辺業務から徐々に関わっていきシステム面のキャッチアップをしていきました。一番最初に携わったプロジェクトとしては、CLINICS カルテにおける診察業務のコントロールを担う「診療ステータス」の拡張を行うという、カルテ全体に影響のある大きな改修に携わりました。それ以降も、小さいタスクを捌きつつ、中・大規模な施策に携わってきた感じです。 そこから医療 PF 横断のプロジェクトにも関わっていくようになりました。CLINICS というプロダクトは患者が使用するアプリを始め、調剤・歯科のサービスも提供しています。 医療 PF 全体の体験設計を踏まえて、周辺プロダクトとも積極的に関わっていく必要がある という点は特徴的だと思います。 岡村 : 私は入社当時は「社長室コンサル」という役割で入社し、この部署は M&A などをメインに担当していた部署だったんです。そのため最初にアサインされたのが NaCl メディカル社(現在はメドレー本体に統合)の業務面での PMI でした。これと平行して、現在も引き続き携わっている新しいレセコンを作るプロジェクトのプロダクトマネージャを担当してきました。 新規レセコンは CLINICS カルテと連携しているプロダクトなので、平山さんが率いるチームと連携 しながら、このプロダクトを作っている開発チームを率いています。 GM としてのミッションと就任してから変わったこと・変わらないこと 新居 : 話を聞いていると、お二人とも最初の仕事を順調にスケールアップしていったという形で現在の業務に繋っているんですね。さて、ここからは GM に就任してからの自身の業務がどのように変化してきたのかという点を聞きたいのですが、この点どうでしょうか。 平山 : ミッションはやはり変化しました。GM としてのミッションで一番求められるものは「 プロダクトを前進させる 」という部分と考えています。自身の管掌組織は当然ですが、組織を横断する形の取り組みも必要になります。 「ピープルマネジメント」という点も GM としての変化の１つかなと思います。とはいえ、先ほどの話と通じる部分はあり**「プロダクトに軸足を置いて目線を合わせていくこと」が基本**となります。また、組織上の持続可能性という意味においても「任せていく」というところは大事にしています。メンバーに優秀な方が多いので助けられている部分は多いと感じます。 エンジニアリングという意味では、手を動かす量は減りました。手の動かし方という意味では入社当初から横の動きを見るようにはしていたので GM になって変わったという部分は無いですね。 岡村 : レセコン新規開発プロジェクトでの GM のミッションとして、「プロジェクトの完遂」、「チームメンバーのピープルマネジメント」、「Tech Studio MATSUE(島根県にあるメドレーの拠点。レセコン新規開発プロジェクトの開発をしている)の管理」がメインになります。 GM に就任したタイミングは NaCl メディカル社がメドレー本体に吸収合併されたというタイミングでした。就任前はグループ会社ということもあり、開発業務を受発注するという動きに近い感じで協業してきました。GM になってからは、同じ会社になったのでより近い距離でチーム開発をするようになったり、メンバーのピープルマネジメントの割合が多くなるという変化がありました。 担当領域としてはレセコンのプロダクトマネジメントをしているという部分は変わらない部分です。また平山さんがおっしゃっていたように、いつまでも自分が上にいて指揮するという状態を良しとするのではなく、 メンバーの人をどんどんと上のロールに引き上げていくというのが GM の役割の 1 つ かと思うので、そういう意識でメンバーのマネジメントをしています。 エンジニアリングとマネジメントの比率はプロダクトのフェイズによって変わってくるし、変わるべきかなと思っています。現在は 8 対 2 でマネジメントの比率が多くなっています。一方でプロダクトの初期でどんどんと開発をしていかないといけないという場合には自分も含めて人手をかけて開発していくようにします。 新居 : お話をうかがうと、やはり GM 前よりもマネジメントの比率が多くなっているのではないかと思うのですが、葛藤などはありましたか。 平山 : 元々の自分のスタンスとして「自分も駒の一つ」としてプロダクト開発を推進していくという思考があります。GM の話が来たときにも、やれるかなという不安感はありましたが、今の場面においては自身がやった方が良いと感じて受けました。 岡村 : 私は出自がエンジニアではないというのもあって、葛藤のようなものも平山さんとは違って、特にありませんでした。元々 NaCl メディカル社だった松江オフィスとのハブになるのは、自分しかいないと思っていましたので躊躇のようなものも全く無かったです。 GM で苦労したポイント・どう克服していたか 新居 : ありがとうございます。では、GM になって苦労したとか大変だったというところってどんなところがありましたか。 平山 : 自分は口下手な方なんで、以前より喋る機会が増えたのが困ったところですね（笑） 新居 : 平山さんに口下手な印象は全然ありませんが（笑） 平山 : 他には、これはどちらかというと PdM 属性の仕事にも関わってくるんですが、開発計画の策定は大変です(メドレーでは 3 ヶ月ごとに開発計画を立てている)。 大規模な施策の実施と並行して優先度の高いタスクの差し込みを踏まえて、優先度の再設計や施策のフェージングや運用の検討したりしています。 自分で抱え込む必要はないですが、関係者と調整しつつも最終意思決定は自分になるので、様々な葛藤をしながら取り組んでいます 。 新居 : ピープルマネジメント面では何かありましたか。 平山 : 先程お話した「プロダクトに軸足を置いて目線を合わせていくこと」を大切にコミュニケーションを実施し、日々の業務を通してメンバー一人一人でシナジーが出る・良いキャリアが重ねられるようにしたいと考えていますが、先ほどの開発計画の難しさもここにあります。 新居 : ありがとうございます。では岡村さんはいかがでしょう。 岡村 : 平山さんに全く同感ですね（笑） 冗談は置いておいて、計画外の差し込みタスクなどが入ると、どうしてもチームの負荷が高くなってくるので、そこをコントロールしきれずに申し訳ないなと思うことがあります。 他には、メンバーのキャリア形成をどうするかという点が難しいと思います。 メンバーの志向に合わせての将来像を見据えて現在の業務に取り組んでもらいたい のですが、実際のタスクとそうしたキャリアの方向性が必ずしもぴったりと合うときばかりではないので、ここをどう揃えていくかという点にも苦労はしています。 新居 : なるほど、岡村さんの場合は元々として島根と東京という立地間でのマネジメントをされていたと思うんですが、リモートコミュニケーションが中心という環境での苦労は何かありましたか。 岡村 : 実はこれと言って無いんですよ。それでもちゃんと上手く機能している要因としては、2 つあります。1 つは島根の方に現地のメンバーを取りしきってくれるスキルを持ったメンバーが居てくれたことです。ここは今でも本当に助かっています。 また、当初から技術的な部分も含めて私もメンバーと一緒に勉強しながら、新しい取り組みをするというスタンスを持ってプロジェクトを推進できたことです。ですので、離れたところから命令する人のような感じではなく、 チームで一緒にプロジェクトを進める人という認識を持ってもらえた んじゃないかなと考えています。 もちろん、関係値を作れるまでは私が最初の頃は 1 ヶ月に 1~2 回程度島根に出張して、実際にメンバーと会ったりすることもしていましたが。 GM を担う上で、役に立った経験・知識 新居 : ここからは、お二人が今までの業務の中で積んできた経験・知識の内、現在 GM として活動する上で役に立っているものとして、どんなものがあるのか聞ければと思います。 平山 : そうですね、一番役に立っているなと感じているのは前職で経験した「 様々なステークホルダーとの主体性を持った折衝経験 」です。色々な会社や立場の方とコミュニケーションを取ることが多かったんですね。専門性もそれぞれ違う方達とお話して物事を進める経験ができたことは、今の GM という役割に本当に役立っていると思います。 岡村 : 私が役に立っていると感じる経験は、「 一回深く細かいところまで業務を見てみて理解をしてから、改めて俯瞰した視点で業務を見直してメンバーにお願いする 」という習慣です。この相反する方法をバランス良くできるようになっているというのが、良い点なのかなと思っています。また、深く見るというのは自分が興味を持っている分野でないと中々難しいので、何にでも興味を持って業務に取り組むという心持ちも必要になるかと考えています。 こうした形で業務を分解してメンバーにお願いできるところはしながら、GM としては適切に権限委譲していくというのに役立っています。 エンジニアのピープルマネジメントで意識していること 新居 : 今までのお話でも少し出ている話題になるのですが、GM としてエンジニアのマネジメントで意識しているポイントって、どんなことがありますか。 平山 : 自分達が作る プロダクトへの興味関心・解像度を高め、何を作るのか 。という点において各所コミュニケーションを含めて主体的に動くこと。そうした積み重ねの延長線上にあるエンジニアとしてのキャリア形成を意識しています。 この考え方に加えて「プロダクトの持続可能性を高める」というテーマで、エンジニア・デザイナー・ディレクター・ QA エンジニア・カスタマーサクセスといったプロダクトに関わる人達の専門性を踏まえたタスクの再配布・プロジェクト設計を行う。といった体制作りも推進しようとしています。 新居 : 「プロダクトの持続可能性を高める」というのは、すごく難しい試みですよね。 平山 : 確かにとても難しいなと思います。でも打ち手としては色々あるのではないかと考えていて。「属人性の排除」といった点は、分かりやすいのではないかなと思います。誰かに依存した状態は、組織変更や事業スケールの変化に弱くなりがちですよね。 大事なのは「人から組織への移行」「仕組み化」と捉えています。「できる人を増やす」については、大事だけど秘伝のタレが受け継がれるだけになってしまうので、持続可能性の観点では本質的ではないかなと。 一方で「仕組み化するための計画的な属人性」については推奨できると考えてます。新しいことをいきなり「組織に転換」や「人を増やしてローテする」だと、ナレッジが蓄積されづらく、次の一手が打ちづらくなるので。 新居 : そうした取り組みをするのに、例えばエンジニアだと作ってみたものがプロダクトの目指す方向性とズレが生じていたというような事態があると思うんですが、そうしたズレを事前に仕組みで抑えるような事をしているんですか。 平山 : きっちりとした仕組みなどは作ってはいないです。仕組み化というよりも、そうならないように メンバーから上がってきた疑問などに対する壁打ちなどは気軽にできる ようにしています。また、そういった相談を気軽にできるような自分自身のプロデュースといいますか、キャラ作りみたいなものも含めてメンバーが相談しにくいという空気を作らないようにはしていますね。 新居 : ありがとうございます。岡村さんはどんな意識をしていますか。 岡村 : やっぱり平山さんに全く同感ですね（笑） 付け加えると、ソフト面ですが メンバーであるエンジニアが楽しめる環境作り というところを意識しています。楽しさにも色々な種類があるとは思いますが、単にコーディングするだけではなく、やはりプロダクトそれ自体の提供価値というものをしっかりと共有して、プロダクトを作ること自体に楽しさを感じてもらう…というのは重要じゃないかなと思っています。 また楽しさの別側面ですが、新しいテクノロジーなどもどんどんと取り入れることができるような仕組み作りもしています。島根のメンバーは今回のプロジェクトで初めて Ruby を使うというメンバーも多かったので、ここで楽しさを感じられないと、こうしたテクノロジー自体を嫌いになってしまう恐れがあるなと思ったので。 そうした「楽しい仕事」にしていくと「時間をかけなきゃ」ではなく「時間をかけたい」という感じで取り組めるようになると思います。 GM という役割の醍醐味とは 新居 : それでは終盤になってきましたが、GM の「やりがい」や「醍醐味」はどういったものになりますか。 岡村 : 一番は「ピープルマネジメント」になるんじゃないかと考えています。最近、岸田首相の所信表明演説で聞いて感銘を受けたアフリカの諺ですが「早く行きたいなら 1 人で行け、遠くへ行きたいならみんなで行け」という言葉はピープルマネジメントの本質なんじゃないかなと思っています。 メンバーと一緒に遠くに行くために組織作り などをしていけるのが醍醐味だと感じています。 平山 : メンバーの 個人スキルを高めつつ「チーム」に還元してもらうための仕組み を作っていく。というのは、醍醐味と言えるのかなと。CTO インタビューで田中も言っていますが「チームバリュー」は大切だと考えています。 チームといっても、狭義のチームではなくプロダクトに関わる関係者全員を含めたチームという感じで意識しています。開発組織に閉じないバリューの発揮がメンバーそれぞれでできると心強いと思います。 メドレーで GM やリードエンジニアのロールに向いている方 新居 : 最後になるのですが、メドレーで GM やテックリードといったロールに向いているのは、どんな人だと思いますか。 平山 : 基本的に 物事を前に進めるための解像度を高く描ける人 かなと思っています。何を誰のためにというのを体現しつつ、関係者を引っぱっていける人ですね。メドレーの Our Essentials 全般必要だとは思いますが、その中でも「成果を出す」「自分をアップデート」「組織水準を高める」「革新と改善を主導」というところが必要になるかな。困難な状況でも結果を出しつつ、自分の行動も高めていき、結果組織・プロダクトを良くしていける…というのがメドレーのリードと呼ばれているエンジニアかと思います。 やり方としては、マイクロマネジメントではなく、基本となる考え方をちゃんと伝えてメンバーに学んでもらう…という、やり方ができる人が向いていると思います。 岡村 : 困難な状況であっても何とかして前に進めることができる人 でしょうか。無理矢理に進めるというわけではなく、状況の整理や色々な部署との調整などもしたりして、何とか結果という形にしていける能力がある人がリードとしてメンバーを引っぱっていける人だと思います。 もちろん、フェイズによってメンバーとの関わりなどはちゃんと調整していける柔軟さなども必要になると思います。 新居 : なるほど。本日は色々なお話をしていただきまして、ありがとうございました! さいごに メドレーの GM 二人に仕事について聞いていきました。 前回の CTO インタビューでも語られた開発組織の話ですが、より現場に近い GM という立場のメンバーからの話でまた違った雰囲気などを感じていただけたかと思います。 このような GM を「ぜひやりたい!」という方や「こんな上司の元で自分の力を発揮していきたい!」という方はぜひカジュアルにお話ができればと思います。 https://www.medley.jp/jobs/

はじめに みなさん、こんにちは。エンジニアの新居です。 今回のインタビューは前回の CTO へのインタビュー に続いて、メドレーの開発組織についてご紹介していきたいと思います。 メドレーでは開発組織をリードするロールとして、CTO の他、「グループマネージャ」(以下、GM)という役職があります。今回は医療プラットフォーム(以下、医療 PF)における開発グループの GM を担う二人に、具体的にどのような役割なのか聞いていきます。 インタビュイー紹介 今回の紹介はインタビュー中で前職からメドレー入社の話を聞いているので、シンプルにお送りします。 平山さん 医療 PF 第一本部 プロダクト開発室 第四開発グループ GM。現在は CLINICS 基幹システムチームのマネジメントを担当。 岡村さん 医療 PF 第一本部 プロダクト開発室 第三開発グループ GM。現在はレセコン(電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア)新規開発チームのマネジメントを担当。 左から岡村さん、平山さん、筆者 前職までの経歴とメドレー入社の理由について 二人の経験について 新居 : 早速始めていきますが、まずはお二人の経歴を教えていただきたいと思います。 平山 : メドレーは 2 社目の会社となります。前職は SIer で 14~5 年くらい受託開発や客先常駐して開発をしていました。SIer というと場合によっては二次請け・三次請けの開発をしているところもあるんですが、自分は一次請けとして直接顧客と関わる形で業務を行っていました。 顧客のサービスをステークホルダーと提案・折衝しながら、技術選定・要件定義から開発、リリースまで行い、そこからの保守運用といった部分までの一連の流れを様々な業態の顧客と関わらせて頂きました。 新居 : ありがとうございます。かなり自社開発と同じ感覚の開発を長年されてきたんですね。それでは、岡村さんお願いします。 岡村 : 新卒で外資系の IT コンサルティング会社で IT コンサルタントとしてキャリアを始めました。その中でも特に「情報系」と呼ばれるデータアナリティクスや BI (Business Intelligence) などを取り扱う部門で業務をしていました。領域的には金融・製薬・省庁など堅めの領域を主に担当していたので、いわゆる Web アプリケーションを作るというよりは SQL をガリガリ書いてデータ分析を基に業務改善していく…という感じの業務が多かったです。 2 社目はスタートアップ企業の立ち上げフェイズにジョインしました。その会社はいわゆる Insure Tech と呼ばれる保険業界 x テクノロジー領域のサービスを作っている会社でした。そこで、その会社でのプロダクトマネージャ業務と、運転資金を確保するために大手保険会社向けのコンサルタント業務に半々で従事していました。 その後にメドレーにジョインするという経歴です。 岡村さん メドレー入社の経緯について 新居 : ありがとうございます、お二人はメドレーに入社してどのくらい経ちますっけ? 平山 : 私は 3 年半ですね。 岡村 : 私は 4 年経ちました。 新居 : もうそんなに経つんですね。みなさんの前職を転職しようと思った動機とはどんなものだったんですか? 平山 : 前職でプレイングマネージャとして業務をしてきましたが、キャリアを重ねてくると徐々にマネジメントの割合が増えてきます。それ自体は自然なことではあるのですが、前職の延長線上でマネジメントに比重を置くことに対して、危機感を感じていたんです。手を動かす部分を含めて、エンジニアとして良いキャリアを積むには別の環境に身を置く必要があると思い、転職を決意しました。 転職に際しては、自分が 身近に感じるサービスで特に自分の家族が関わるような領域が良いと考えており、医療はそうした意味でぴったりな領域 でした。これらの条件で転職エージェントを通じてメドレーに辿りつきました。 平山さん 岡村 : 先程も少し話しましたが、前職は自社プロダクトと他社向けコンサルティングを並行して運営していた会社でした。しかし、途中から経営方針が変わってコンサルティング業務をメインに据えるようになったんです。自分としては、自社プロダクトを作っている点を大事に考えていたため、転職を考えはじめました。 会社選びの軸としては、もちろん自社サービスが事業の主軸である会社というのが一番でした。他の条件としては「上場一歩手前」くらいのフェイズの会社というものがありました。これは、そのくらいのフェイズの会社であれば今までやっていた事業をいきなりピボットするという可能性が限りなく低いのではないかと考えたからです。そんな感じで会社を探していて、LinkedIn の広告経由でメドレーにアプローチして入社しました。 新居 : 岡村さんは次の会社の事業領域は、意識していたんでしょうか? 岡村 : 医療領域を名指しで考えていたわけではないです。しかし、いわゆる 昔ながらの慣習などが多く残るような業界や領域を、自分達が手がけたサービスで変えていくというのが良い という考えでした。これは前職でも考えていたことだったので、引き続き志向していました。 メドレー入社後にどのような仕事をしていたのか 新居 : ありがとうございます。そんな経緯でメドレーに入社したお二人ですが、入社後はどのような業務をされていたんでしょうか。 平山 : 私は入社後から一貫して CLINICS カルテを担当しています。入社後は医療に関する業務知識を身につけながら、周辺業務から徐々に関わっていきシステム面のキャッチアップをしていきました。一番最初に携わったプロジェクトとしては、CLINICS カルテにおける診察業務のコントロールを担う「診療ステータス」の拡張を行うという、カルテ全体に影響のある大きな改修に携わりました。それ以降も、小さいタスクを捌きつつ、中・大規模な施策に携わってきた感じです。 そこから医療 PF 横断のプロジェクトにも関わっていくようになりました。CLINICS というプロダクトは患者が使用するアプリを始め、調剤・歯科のサービスも提供しています。 医療 PF 全体の体験設計を踏まえて、周辺プロダクトとも積極的に関わっていく必要がある という点は特徴的だと思います。 岡村 : 私は入社当時は「社長室コンサル」という役割で入社し、この部署は M&A などをメインに担当していた部署だったんです。そのため最初にアサインされたのが NaCl メディカル社(現在はメドレー本体に統合)の業務面での PMI でした。これと平行して、現在も引き続き携わっている新しいレセコンを作るプロジェクトのプロダクトマネージャを担当してきました。 新規レセコンは CLINICS カルテと連携しているプロダクトなので、平山さんが率いるチームと連携 しながら、このプロダクトを作っている開発チームを率いています。 GM としてのミッションと就任してから変わったこと・変わらないこと 新居 : 話を聞いていると、お二人とも最初の仕事を順調にスケールアップしていったという形で現在の業務に繋っているんですね。さて、ここからは GM に就任してからの自身の業務がどのように変化してきたのかという点を聞きたいのですが、この点どうでしょうか。 平山 : ミッションはやはり変化しました。GM としてのミッションで一番求められるものは「 プロダクトを前進させる 」という部分と考えています。自身の管掌組織は当然ですが、組織を横断する形の取り組みも必要になります。 「ピープルマネジメント」という点も GM としての変化の１つかなと思います。とはいえ、先ほどの話と通じる部分はあり**「プロダクトに軸足を置いて目線を合わせていくこと」が基本**となります。また、組織上の持続可能性という意味においても「任せていく」というところは大事にしています。メンバーに優秀な方が多いので助けられている部分は多いと感じます。 エンジニアリングという意味では、手を動かす量は減りました。手の動かし方という意味では入社当初から横の動きを見るようにはしていたので GM になって変わったという部分は無いですね。 岡村 : レセコン新規開発プロジェクトでの GM のミッションとして、「プロジェクトの完遂」、「チームメンバーのピープルマネジメント」、「Tech Studio MATSUE(島根県にあるメドレーの拠点。レセコン新規開発プロジェクトの開発をしている)の管理」がメインになります。 GM に就任したタイミングは NaCl メディカル社がメドレー本体に吸収合併されたというタイミングでした。就任前はグループ会社ということもあり、開発業務を受発注するという動きに近い感じで協業してきました。GM になってからは、同じ会社になったのでより近い距離でチーム開発をするようになったり、メンバーのピープルマネジメントの割合が多くなるという変化がありました。 担当領域としてはレセコンのプロダクトマネジメントをしているという部分は変わらない部分です。また平山さんがおっしゃっていたように、いつまでも自分が上にいて指揮するという状態を良しとするのではなく、 メンバーの人をどんどんと上のロールに引き上げていくというのが GM の役割の 1 つ かと思うので、そういう意識でメンバーのマネジメントをしています。 エンジニアリングとマネジメントの比率はプロダクトのフェイズによって変わってくるし、変わるべきかなと思っています。現在は 8 対 2 でマネジメントの比率が多くなっています。一方でプロダクトの初期でどんどんと開発をしていかないといけないという場合には自分も含めて人手をかけて開発していくようにします。 新居 : お話をうかがうと、やはり GM 前よりもマネジメントの比率が多くなっているのではないかと思うのですが、葛藤などはありましたか。 平山 : 元々の自分のスタンスとして「自分も駒の一つ」としてプロダクト開発を推進していくという思考があります。GM の話が来たときにも、やれるかなという不安感はありましたが、今の場面においては自身がやった方が良いと感じて受けました。 岡村 : 私は出自がエンジニアではないというのもあって、葛藤のようなものも平山さんとは違って、特にありませんでした。元々 NaCl メディカル社だった松江オフィスとのハブになるのは、自分しかいないと思っていましたので躊躇のようなものも全く無かったです。 GM で苦労したポイント・どう克服していたか 新居 : ありがとうございます。では、GM になって苦労したとか大変だったというところってどんなところがありましたか。 平山 : 自分は口下手な方なんで、以前より喋る機会が増えたのが困ったところですね（笑） 新居 : 平山さんに口下手な印象は全然ありませんが（笑） 平山 : 他には、これはどちらかというと PdM 属性の仕事にも関わってくるんですが、開発計画の策定は大変です(メドレーでは 3 ヶ月ごとに開発計画を立てている)。 大規模な施策の実施と並行して優先度の高いタスクの差し込みを踏まえて、優先度の再設計や施策のフェージングや運用の検討したりしています。 自分で抱え込む必要はないですが、関係者と調整しつつも最終意思決定は自分になるので、様々な葛藤をしながら取り組んでいます 。 新居 : ピープルマネジメント面では何かありましたか。 平山 : 先程お話した「プロダクトに軸足を置いて目線を合わせていくこと」を大切にコミュニケーションを実施し、日々の業務を通してメンバー一人一人でシナジーが出る・良いキャリアが重ねられるようにしたいと考えていますが、先ほどの開発計画の難しさもここにあります。 新居 : ありがとうございます。では岡村さんはいかがでしょう。 岡村 : 平山さんに全く同感ですね（笑） 冗談は置いておいて、計画外の差し込みタスクなどが入ると、どうしてもチームの負荷が高くなってくるので、そこをコントロールしきれずに申し訳ないなと思うことがあります。 他には、メンバーのキャリア形成をどうするかという点が難しいと思います。 メンバーの志向に合わせての将来像を見据えて現在の業務に取り組んでもらいたい のですが、実際のタスクとそうしたキャリアの方向性が必ずしもぴったりと合うときばかりではないので、ここをどう揃えていくかという点にも苦労はしています。 新居 : なるほど、岡村さんの場合は元々として島根と東京という立地間でのマネジメントをされていたと思うんですが、リモートコミュニケーションが中心という環境での苦労は何かありましたか。 岡村 : 実はこれと言って無いんですよ。それでもちゃんと上手く機能している要因としては、2 つあります。1 つは島根の方に現地のメンバーを取りしきってくれるスキルを持ったメンバーが居てくれたことです。ここは今でも本当に助かっています。 また、当初から技術的な部分も含めて私もメンバーと一緒に勉強しながら、新しい取り組みをするというスタンスを持ってプロジェクトを推進できたことです。ですので、離れたところから命令する人のような感じではなく、 チームで一緒にプロジェクトを進める人という認識を持ってもらえた んじゃないかなと考えています。 もちろん、関係値を作れるまでは私が最初の頃は 1 ヶ月に 1~2 回程度島根に出張して、実際にメンバーと会ったりすることもしていましたが。 GM を担う上で、役に立った経験・知識 新居 : ここからは、お二人が今までの業務の中で積んできた経験・知識の内、現在 GM として活動する上で役に立っているものとして、どんなものがあるのか聞ければと思います。 平山 : そうですね、一番役に立っているなと感じているのは前職で経験した「 様々なステークホルダーとの主体性を持った折衝経験 」です。色々な会社や立場の方とコミュニケーションを取ることが多かったんですね。専門性もそれぞれ違う方達とお話して物事を進める経験ができたことは、今の GM という役割に本当に役立っていると思います。 岡村 : 私が役に立っていると感じる経験は、「 一回深く細かいところまで業務を見てみて理解をしてから、改めて俯瞰した視点で業務を見直してメンバーにお願いする 」という習慣です。この相反する方法をバランス良くできるようになっているというのが、良い点なのかなと思っています。また、深く見るというのは自分が興味を持っている分野でないと中々難しいので、何にでも興味を持って業務に取り組むという心持ちも必要になるかと考えています。 こうした形で業務を分解してメンバーにお願いできるところはしながら、GM としては適切に権限委譲していくというのに役立っています。 エンジニアのピープルマネジメントで意識していること 新居 : 今までのお話でも少し出ている話題になるのですが、GM としてエンジニアのマネジメントで意識しているポイントって、どんなことがありますか。 平山 : 自分達が作る プロダクトへの興味関心・解像度を高め、何を作るのか 。という点において各所コミュニケーションを含めて主体的に動くこと。そうした積み重ねの延長線上にあるエンジニアとしてのキャリア形成を意識しています。 この考え方に加えて「プロダクトの持続可能性を高める」というテーマで、エンジニア・デザイナー・ディレクター・ QA エンジニア・カスタマーサクセスといったプロダクトに関わる人達の専門性を踏まえたタスクの再配布・プロジェクト設計を行う。といった体制作りも推進しようとしています。 新居 : 「プロダクトの持続可能性を高める」というのは、すごく難しい試みですよね。 平山 : 確かにとても難しいなと思います。でも打ち手としては色々あるのではないかと考えていて。「属人性の排除」といった点は、分かりやすいのではないかなと思います。誰かに依存した状態は、組織変更や事業スケールの変化に弱くなりがちですよね。 大事なのは「人から組織への移行」「仕組み化」と捉えています。「できる人を増やす」については、大事だけど秘伝のタレが受け継がれるだけになってしまうので、持続可能性の観点では本質的ではないかなと。 一方で「仕組み化するための計画的な属人性」については推奨できると考えてます。新しいことをいきなり「組織に転換」や「人を増やしてローテする」だと、ナレッジが蓄積されづらく、次の一手が打ちづらくなるので。 新居 : そうした取り組みをするのに、例えばエンジニアだと作ってみたものがプロダクトの目指す方向性とズレが生じていたというような事態があると思うんですが、そうしたズレを事前に仕組みで抑えるような事をしているんですか。 平山 : きっちりとした仕組みなどは作ってはいないです。仕組み化というよりも、そうならないように メンバーから上がってきた疑問などに対する壁打ちなどは気軽にできる ようにしています。また、そういった相談を気軽にできるような自分自身のプロデュースといいますか、キャラ作りみたいなものも含めてメンバーが相談しにくいという空気を作らないようにはしていますね。 新居 : ありがとうございます。岡村さんはどんな意識をしていますか。 岡村 : やっぱり平山さんに全く同感ですね（笑） 付け加えると、ソフト面ですが メンバーであるエンジニアが楽しめる環境作り というところを意識しています。楽しさにも色々な種類があるとは思いますが、単にコーディングするだけではなく、やはりプロダクトそれ自体の提供価値というものをしっかりと共有して、プロダクトを作ること自体に楽しさを感じてもらう…というのは重要じゃないかなと思っています。 また楽しさの別側面ですが、新しいテクノロジーなどもどんどんと取り入れることができるような仕組み作りもしています。島根のメンバーは今回のプロジェクトで初めて Ruby を使うというメンバーも多かったので、ここで楽しさを感じられないと、こうしたテクノロジー自体を嫌いになってしまう恐れがあるなと思ったので。 そうした「楽しい仕事」にしていくと「時間をかけなきゃ」ではなく「時間をかけたい」という感じで取り組めるようになると思います。 GM という役割の醍醐味とは 新居 : それでは終盤になってきましたが、GM の「やりがい」や「醍醐味」はどういったものになりますか。 岡村 : 一番は「ピープルマネジメント」になるんじゃないかと考えています。最近、岸田首相の所信表明演説で聞いて感銘を受けたアフリカの諺ですが「早く行きたいなら 1 人で行け、遠くへ行きたいならみんなで行け」という言葉はピープルマネジメントの本質なんじゃないかなと思っています。 メンバーと一緒に遠くに行くために組織作り などをしていけるのが醍醐味だと感じています。 平山 : メンバーの 個人スキルを高めつつ「チーム」に還元してもらうための仕組み を作っていく。というのは、醍醐味と言えるのかなと。CTO インタビューで田中も言っていますが「チームバリュー」は大切だと考えています。 チームといっても、狭義のチームではなくプロダクトに関わる関係者全員を含めたチームという感じで意識しています。開発組織に閉じないバリューの発揮がメンバーそれぞれでできると心強いと思います。 メドレーで GM やリードエンジニアのロールに向いている方 新居 : 最後になるのですが、メドレーで GM やテックリードといったロールに向いているのは、どんな人だと思いますか。 平山 : 基本的に 物事を前に進めるための解像度を高く描ける人 かなと思っています。何を誰のためにというのを体現しつつ、関係者を引っぱっていける人ですね。メドレーの Our Essentials 全般必要だとは思いますが、その中でも「成果を出す」「自分をアップデート」「組織水準を高める」「革新と改善を主導」というところが必要になるかな。困難な状況でも結果を出しつつ、自分の行動も高めていき、結果組織・プロダクトを良くしていける…というのがメドレーのリードと呼ばれているエンジニアかと思います。 やり方としては、マイクロマネジメントではなく、基本となる考え方をちゃんと伝えてメンバーに学んでもらう…という、やり方ができる人が向いていると思います。 岡村 : 困難な状況であっても何とかして前に進めることができる人 でしょうか。無理矢理に進めるというわけではなく、状況の整理や色々な部署との調整などもしたりして、何とか結果という形にしていける能力がある人がリードとしてメンバーを引っぱっていける人だと思います。 もちろん、フェイズによってメンバーとの関わりなどはちゃんと調整していける柔軟さなども必要になると思います。 新居 : なるほど。本日は色々なお話をしていただきまして、ありがとうございました! さいごに メドレーの GM 二人に仕事について聞いていきました。 前回の CTO インタビューでも語られた開発組織の話ですが、より現場に近い GM という立場のメンバーからの話でまた違った雰囲気などを感じていただけたかと思います。 このような GM を「ぜひやりたい!」という方や「こんな上司の元で自分の力を発揮していきたい!」という方はぜひカジュアルにお話ができればと思います。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの新居です。 今回のインタビューは前回の CTO へのインタビュー に続いて、メドレーの開発組織についてご紹介していきたいと思います。 メドレーでは開発組織をリードするロールとして、CTO の他、「グループマネージャ」(以下、GM)という役職があります。今回は医療プラットフォーム(以下、医療 PF)における開発グループの GM を担う二人に、具体的にどのような役割なのか聞いていきます。 インタビュイー紹介 今回の紹介はインタビュー中で前職からメドレー入社の話を聞いているので、シンプルにお送りします。 平山さん 医療 PF 第一本部 プロダクト開発室 第四開発グループ GM。現在は CLINICS 基幹システムチームのマネジメントを担当。 岡村さん 医療 PF 第一本部 プロダクト開発室 第三開発グループ GM。現在はレセコン(電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア)新規開発チームのマネジメントを担当。 左から岡村さん、平山さん、筆者 前職までの経歴とメドレー入社の理由について 二人の経験について 新居 : 早速始めていきますが、まずはお二人の経歴を教えていただきたいと思います。 平山 : メドレーは 2 社目の会社となります。前職は SIer で 14~5 年くらい受託開発や客先常駐して開発をしていました。SIer というと場合によっては二次請け・三次請けの開発をしているところもあるんですが、自分は一次請けとして直接顧客と関わる形で業務を行っていました。 顧客のサービスをステークホルダーと提案・折衝しながら、技術選定・要件定義から開発、リリースまで行い、そこからの保守運用といった部分までの一連の流れを様々な業態の顧客と関わらせて頂きました。 新居 : ありがとうございます。かなり自社開発と同じ感覚の開発を長年されてきたんですね。それでは、岡村さんお願いします。 岡村 : 新卒で外資系の IT コンサルティング会社で IT コンサルタントとしてキャリアを始めました。その中でも特に「情報系」と呼ばれるデータアナリティクスや BI (Business Intelligence) などを取り扱う部門で業務をしていました。領域的には金融・製薬・省庁など堅めの領域を主に担当していたので、いわゆる Web アプリケーションを作るというよりは SQL をガリガリ書いてデータ分析を基に業務改善していく…という感じの業務が多かったです。 2 社目はスタートアップ企業の立ち上げフェイズにジョインしました。その会社はいわゆる Insure Tech と呼ばれる保険業界 x テクノロジー領域のサービスを作っている会社でした。そこで、その会社でのプロダクトマネージャ業務と、運転資金を確保するために大手保険会社向けのコンサルタント業務に半々で従事していました。 その後にメドレーにジョインするという経歴です。 岡村さん メドレー入社の経緯について 新居 : ありがとうございます、お二人はメドレーに入社してどのくらい経ちますっけ? 平山 : 私は 3 年半ですね。 岡村 : 私は 4 年経ちました。 新居 : もうそんなに経つんですね。みなさんの前職を転職しようと思った動機とはどんなものだったんですか? 平山 : 前職でプレイングマネージャとして業務をしてきましたが、キャリアを重ねてくると徐々にマネジメントの割合が増えてきます。それ自体は自然なことではあるのですが、前職の延長線上でマネジメントに比重を置くことに対して、危機感を感じていたんです。手を動かす部分を含めて、エンジニアとして良いキャリアを積むには別の環境に身を置く必要があると思い、転職を決意しました。 転職に際しては、自分が 身近に感じるサービスで特に自分の家族が関わるような領域が良いと考えており、医療はそうした意味でぴったりな領域 でした。これらの条件で転職エージェントを通じてメドレーに辿りつきました。 平山さん 岡村 : 先程も少し話しましたが、前職は自社プロダクトと他社向けコンサルティングを並行して運営していた会社でした。しかし、途中から経営方針が変わってコンサルティング業務をメインに据えるようになったんです。自分としては、自社プロダクトを作っている点を大事に考えていたため、転職を考えはじめました。 会社選びの軸としては、もちろん自社サービスが事業の主軸である会社というのが一番でした。他の条件としては「上場一歩手前」くらいのフェイズの会社というものがありました。これは、そのくらいのフェイズの会社であれば今までやっていた事業をいきなりピボットするという可能性が限りなく低いのではないかと考えたからです。そんな感じで会社を探していて、LinkedIn の広告経由でメドレーにアプローチして入社しました。 新居 : 岡村さんは次の会社の事業領域は、意識していたんでしょうか? 岡村 : 医療領域を名指しで考えていたわけではないです。しかし、いわゆる 昔ながらの慣習などが多く残るような業界や領域を、自分達が手がけたサービスで変えていくというのが良い という考えでした。これは前職でも考えていたことだったので、引き続き志向していました。 メドレー入社後にどのような仕事をしていたのか 新居 : ありがとうございます。そんな経緯でメドレーに入社したお二人ですが、入社後はどのような業務をされていたんでしょうか。 平山 : 私は入社後から一貫して CLINICS カルテを担当しています。入社後は医療に関する業務知識を身につけながら、周辺業務から徐々に関わっていきシステム面のキャッチアップをしていきました。一番最初に携わったプロジェクトとしては、CLINICS カルテにおける診察業務のコントロールを担う「診療ステータス」の拡張を行うという、カルテ全体に影響のある大きな改修に携わりました。それ以降も、小さいタスクを捌きつつ、中・大規模な施策に携わってきた感じです。 そこから医療 PF 横断のプロジェクトにも関わっていくようになりました。CLINICS というプロダクトは患者が使用するアプリを始め、調剤・歯科のサービスも提供しています。 医療 PF 全体の体験設計を踏まえて、周辺プロダクトとも積極的に関わっていく必要がある という点は特徴的だと思います。 岡村 : 私は入社当時は「社長室コンサル」という役割で入社し、この部署は M&A などをメインに担当していた部署だったんです。そのため最初にアサインされたのが NaCl メディカル社(現在はメドレー本体に統合)の業務面での PMI でした。これと平行して、現在も引き続き携わっている新しいレセコンを作るプロジェクトのプロダクトマネージャを担当してきました。 新規レセコンは CLINICS カルテと連携しているプロダクトなので、平山さんが率いるチームと連携 しながら、このプロダクトを作っている開発チームを率いています。 GM としてのミッションと就任してから変わったこと・変わらないこと 新居 : 話を聞いていると、お二人とも最初の仕事を順調にスケールアップしていったという形で現在の業務に繋っているんですね。さて、ここからは GM に就任してからの自身の業務がどのように変化してきたのかという点を聞きたいのですが、この点どうでしょうか。 平山 : ミッションはやはり変化しました。GM としてのミッションで一番求められるものは「 プロダクトを前進させる 」という部分と考えています。自身の管掌組織は当然ですが、組織を横断する形の取り組みも必要になります。 「ピープルマネジメント」という点も GM としての変化の１つかなと思います。とはいえ、先ほどの話と通じる部分はあり**「プロダクトに軸足を置いて目線を合わせていくこと」が基本**となります。また、組織上の持続可能性という意味においても「任せていく」というところは大事にしています。メンバーに優秀な方が多いので助けられている部分は多いと感じます。 エンジニアリングという意味では、手を動かす量は減りました。手の動かし方という意味では入社当初から横の動きを見るようにはしていたので GM になって変わったという部分は無いですね。 岡村 : レセコン新規開発プロジェクトでの GM のミッションとして、「プロジェクトの完遂」、「チームメンバーのピープルマネジメント」、「Tech Studio MATSUE(島根県にあるメドレーの拠点。レセコン新規開発プロジェクトの開発をしている)の管理」がメインになります。 GM に就任したタイミングは NaCl メディカル社がメドレー本体に吸収合併されたというタイミングでした。就任前はグループ会社ということもあり、開発業務を受発注するという動きに近い感じで協業してきました。GM になってからは、同じ会社になったのでより近い距離でチーム開発をするようになったり、メンバーのピープルマネジメントの割合が多くなるという変化がありました。 担当領域としてはレセコンのプロダクトマネジメントをしているという部分は変わらない部分です。また平山さんがおっしゃっていたように、いつまでも自分が上にいて指揮するという状態を良しとするのではなく、 メンバーの人をどんどんと上のロールに引き上げていくというのが GM の役割の 1 つ かと思うので、そういう意識でメンバーのマネジメントをしています。 エンジニアリングとマネジメントの比率はプロダクトのフェイズによって変わってくるし、変わるべきかなと思っています。現在は 8 対 2 でマネジメントの比率が多くなっています。一方でプロダクトの初期でどんどんと開発をしていかないといけないという場合には自分も含めて人手をかけて開発していくようにします。 新居 : お話をうかがうと、やはり GM 前よりもマネジメントの比率が多くなっているのではないかと思うのですが、葛藤などはありましたか。 平山 : 元々の自分のスタンスとして「自分も駒の一つ」としてプロダクト開発を推進していくという思考があります。GM の話が来たときにも、やれるかなという不安感はありましたが、今の場面においては自身がやった方が良いと感じて受けました。 岡村 : 私は出自がエンジニアではないというのもあって、葛藤のようなものも平山さんとは違って、特にありませんでした。元々 NaCl メディカル社だった松江オフィスとのハブになるのは、自分しかいないと思っていましたので躊躇のようなものも全く無かったです。 GM で苦労したポイント・どう克服していたか 新居 : ありがとうございます。では、GM になって苦労したとか大変だったというところってどんなところがありましたか。 平山 : 自分は口下手な方なんで、以前より喋る機会が増えたのが困ったところですね（笑） 新居 : 平山さんに口下手な印象は全然ありませんが（笑） 平山 : 他には、これはどちらかというと PdM 属性の仕事にも関わってくるんですが、開発計画の策定は大変です(メドレーでは 3 ヶ月ごとに開発計画を立てている)。 大規模な施策の実施と並行して優先度の高いタスクの差し込みを踏まえて、優先度の再設計や施策のフェージングや運用の検討したりしています。 自分で抱え込む必要はないですが、関係者と調整しつつも最終意思決定は自分になるので、様々な葛藤をしながら取り組んでいます 。 新居 : ピープルマネジメント面では何かありましたか。 平山 : 先程お話した「プロダクトに軸足を置いて目線を合わせていくこと」を大切にコミュニケーションを実施し、日々の業務を通してメンバー一人一人でシナジーが出る・良いキャリアが重ねられるようにしたいと考えていますが、先ほどの開発計画の難しさもここにあります。 新居 : ありがとうございます。では岡村さんはいかがでしょう。 岡村 : 平山さんに全く同感ですね（笑） 冗談は置いておいて、計画外の差し込みタスクなどが入ると、どうしてもチームの負荷が高くなってくるので、そこをコントロールしきれずに申し訳ないなと思うことがあります。 他には、メンバーのキャリア形成をどうするかという点が難しいと思います。 メンバーの志向に合わせての将来像を見据えて現在の業務に取り組んでもらいたい のですが、実際のタスクとそうしたキャリアの方向性が必ずしもぴったりと合うときばかりではないので、ここをどう揃えていくかという点にも苦労はしています。 新居 : なるほど、岡村さんの場合は元々として島根と東京という立地間でのマネジメントをされていたと思うんですが、リモートコミュニケーションが中心という環境での苦労は何かありましたか。 岡村 : 実はこれと言って無いんですよ。それでもちゃんと上手く機能している要因としては、2 つあります。1 つは島根の方に現地のメンバーを取りしきってくれるスキルを持ったメンバーが居てくれたことです。ここは今でも本当に助かっています。 また、当初から技術的な部分も含めて私もメンバーと一緒に勉強しながら、新しい取り組みをするというスタンスを持ってプロジェクトを推進できたことです。ですので、離れたところから命令する人のような感じではなく、 チームで一緒にプロジェクトを進める人という認識を持ってもらえた んじゃないかなと考えています。 もちろん、関係値を作れるまでは私が最初の頃は 1 ヶ月に 1~2 回程度島根に出張して、実際にメンバーと会ったりすることもしていましたが。 GM を担う上で、役に立った経験・知識 新居 : ここからは、お二人が今までの業務の中で積んできた経験・知識の内、現在 GM として活動する上で役に立っているものとして、どんなものがあるのか聞ければと思います。 平山 : そうですね、一番役に立っているなと感じているのは前職で経験した「 様々なステークホルダーとの主体性を持った折衝経験 」です。色々な会社や立場の方とコミュニケーションを取ることが多かったんですね。専門性もそれぞれ違う方達とお話して物事を進める経験ができたことは、今の GM という役割に本当に役立っていると思います。 岡村 : 私が役に立っていると感じる経験は、「 一回深く細かいところまで業務を見てみて理解をしてから、改めて俯瞰した視点で業務を見直してメンバーにお願いする 」という習慣です。この相反する方法をバランス良くできるようになっているというのが、良い点なのかなと思っています。また、深く見るというのは自分が興味を持っている分野でないと中々難しいので、何にでも興味を持って業務に取り組むという心持ちも必要になるかと考えています。 こうした形で業務を分解してメンバーにお願いできるところはしながら、GM としては適切に権限委譲していくというのに役立っています。 エンジニアのピープルマネジメントで意識していること 新居 : 今までのお話でも少し出ている話題になるのですが、GM としてエンジニアのマネジメントで意識しているポイントって、どんなことがありますか。 平山 : 自分達が作る プロダクトへの興味関心・解像度を高め、何を作るのか 。という点において各所コミュニケーションを含めて主体的に動くこと。そうした積み重ねの延長線上にあるエンジニアとしてのキャリア形成を意識しています。 この考え方に加えて「プロダクトの持続可能性を高める」というテーマで、エンジニア・デザイナー・ディレクター・ QA エンジニア・カスタマーサクセスといったプロダクトに関わる人達の専門性を踏まえたタスクの再配布・プロジェクト設計を行う。といった体制作りも推進しようとしています。 新居 : 「プロダクトの持続可能性を高める」というのは、すごく難しい試みですよね。 平山 : 確かにとても難しいなと思います。でも打ち手としては色々あるのではないかと考えていて。「属人性の排除」といった点は、分かりやすいのではないかなと思います。誰かに依存した状態は、組織変更や事業スケールの変化に弱くなりがちですよね。 大事なのは「人から組織への移行」「仕組み化」と捉えています。「できる人を増やす」については、大事だけど秘伝のタレが受け継がれるだけになってしまうので、持続可能性の観点では本質的ではないかなと。 一方で「仕組み化するための計画的な属人性」については推奨できると考えてます。新しいことをいきなり「組織に転換」や「人を増やしてローテする」だと、ナレッジが蓄積されづらく、次の一手が打ちづらくなるので。 新居 : そうした取り組みをするのに、例えばエンジニアだと作ってみたものがプロダクトの目指す方向性とズレが生じていたというような事態があると思うんですが、そうしたズレを事前に仕組みで抑えるような事をしているんですか。 平山 : きっちりとした仕組みなどは作ってはいないです。仕組み化というよりも、そうならないように メンバーから上がってきた疑問などに対する壁打ちなどは気軽にできる ようにしています。また、そういった相談を気軽にできるような自分自身のプロデュースといいますか、キャラ作りみたいなものも含めてメンバーが相談しにくいという空気を作らないようにはしていますね。 新居 : ありがとうございます。岡村さんはどんな意識をしていますか。 岡村 : やっぱり平山さんに全く同感ですね（笑） 付け加えると、ソフト面ですが メンバーであるエンジニアが楽しめる環境作り というところを意識しています。楽しさにも色々な種類があるとは思いますが、単にコーディングするだけではなく、やはりプロダクトそれ自体の提供価値というものをしっかりと共有して、プロダクトを作ること自体に楽しさを感じてもらう…というのは重要じゃないかなと思っています。 また楽しさの別側面ですが、新しいテクノロジーなどもどんどんと取り入れることができるような仕組み作りもしています。島根のメンバーは今回のプロジェクトで初めて Ruby を使うというメンバーも多かったので、ここで楽しさを感じられないと、こうしたテクノロジー自体を嫌いになってしまう恐れがあるなと思ったので。 そうした「楽しい仕事」にしていくと「時間をかけなきゃ」ではなく「時間をかけたい」という感じで取り組めるようになると思います。 GM という役割の醍醐味とは 新居 : それでは終盤になってきましたが、GM の「やりがい」や「醍醐味」はどういったものになりますか。 岡村 : 一番は「ピープルマネジメント」になるんじゃないかと考えています。最近、岸田首相の所信表明演説で聞いて感銘を受けたアフリカの諺ですが「早く行きたいなら 1 人で行け、遠くへ行きたいならみんなで行け」という言葉はピープルマネジメントの本質なんじゃないかなと思っています。 メンバーと一緒に遠くに行くために組織作り などをしていけるのが醍醐味だと感じています。 平山 : メンバーの 個人スキルを高めつつ「チーム」に還元してもらうための仕組み を作っていく。というのは、醍醐味と言えるのかなと。CTO インタビューで田中も言っていますが「チームバリュー」は大切だと考えています。 チームといっても、狭義のチームではなくプロダクトに関わる関係者全員を含めたチームという感じで意識しています。開発組織に閉じないバリューの発揮がメンバーそれぞれでできると心強いと思います。 メドレーで GM やリードエンジニアのロールに向いている方 新居 : 最後になるのですが、メドレーで GM やテックリードといったロールに向いているのは、どんな人だと思いますか。 平山 : 基本的に 物事を前に進めるための解像度を高く描ける人 かなと思っています。何を誰のためにというのを体現しつつ、関係者を引っぱっていける人ですね。メドレーの Our Essentials 全般必要だとは思いますが、その中でも「成果を出す」「自分をアップデート」「組織水準を高める」「革新と改善を主導」というところが必要になるかな。困難な状況でも結果を出しつつ、自分の行動も高めていき、結果組織・プロダクトを良くしていける…というのがメドレーのリードと呼ばれているエンジニアかと思います。 やり方としては、マイクロマネジメントではなく、基本となる考え方をちゃんと伝えてメンバーに学んでもらう…という、やり方ができる人が向いていると思います。 岡村 : 困難な状況であっても何とかして前に進めることができる人 でしょうか。無理矢理に進めるというわけではなく、状況の整理や色々な部署との調整などもしたりして、何とか結果という形にしていける能力がある人がリードとしてメンバーを引っぱっていける人だと思います。 もちろん、フェイズによってメンバーとの関わりなどはちゃんと調整していける柔軟さなども必要になると思います。 新居 : なるほど。本日は色々なお話をしていただきまして、ありがとうございました! さいごに メドレーの GM 二人に仕事について聞いていきました。 前回の CTO インタビューでも語られた開発組織の話ですが、より現場に近い GM という立場のメンバーからの話でまた違った雰囲気などを感じていただけたかと思います。 このような GM を「ぜひやりたい!」という方や「こんな上司の元で自分の力を発揮していきたい!」という方はぜひカジュアルにお話ができればと思います。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの新居です。 今回のインタビューは前回の CTO へのインタビュー に続いて、メドレーの開発組織についてご紹介していきたいと思います。 メドレーでは開発組織をリードするロールとして、CTO の他、「グループマネージャ」(以下、GM)という役職があります。今回は医療プラットフォーム(以下、医療 PF)における開発グループの GM を担う二人に、具体的にどのような役割なのか聞いていきます。 インタビュイー紹介 今回の紹介はインタビュー中で前職からメドレー入社の話を聞いているので、シンプルにお送りします。 平山さん 医療 PF 第一本部 プロダクト開発室 第四開発グループ GM。現在は CLINICS 基幹システムチームのマネジメントを担当。 岡村さん 医療 PF 第一本部 プロダクト開発室 第三開発グループ GM。現在はレセコン(電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア)新規開発チームのマネジメントを担当。 左から岡村さん、平山さん、筆者 前職までの経歴とメドレー入社の理由について 二人の経験について 新居 : 早速始めていきますが、まずはお二人の経歴を教えていただきたいと思います。 平山 : メドレーは 2 社目の会社となります。前職は SIer で 14~5 年くらい受託開発や客先常駐して開発をしていました。SIer というと場合によっては二次請け・三次請けの開発をしているところもあるんですが、自分は一次請けとして直接顧客と関わる形で業務を行っていました。 顧客のサービスをステークホルダーと提案・折衝しながら、技術選定・要件定義から開発、リリースまで行い、そこからの保守運用といった部分までの一連の流れを様々な業態の顧客と関わらせて頂きました。 新居 : ありがとうございます。かなり自社開発と同じ感覚の開発を長年されてきたんですね。それでは、岡村さんお願いします。 岡村 : 新卒で外資系の IT コンサルティング会社で IT コンサルタントとしてキャリアを始めました。その中でも特に「情報系」と呼ばれるデータアナリティクスや BI (Business Intelligence) などを取り扱う部門で業務をしていました。領域的には金融・製薬・省庁など堅めの領域を主に担当していたので、いわゆる Web アプリケーションを作るというよりは SQL をガリガリ書いてデータ分析を基に業務改善していく…という感じの業務が多かったです。 2 社目はスタートアップ企業の立ち上げフェイズにジョインしました。その会社はいわゆる Insure Tech と呼ばれる保険業界 x テクノロジー領域のサービスを作っている会社でした。そこで、その会社でのプロダクトマネージャ業務と、運転資金を確保するために大手保険会社向けのコンサルタント業務に半々で従事していました。 その後にメドレーにジョインするという経歴です。 岡村さん メドレー入社の経緯について 新居 : ありがとうございます、お二人はメドレーに入社してどのくらい経ちますっけ? 平山 : 私は 3 年半ですね。 岡村 : 私は 4 年経ちました。 新居 : もうそんなに経つんですね。みなさんの前職を転職しようと思った動機とはどんなものだったんですか? 平山 : 前職でプレイングマネージャとして業務をしてきましたが、キャリアを重ねてくると徐々にマネジメントの割合が増えてきます。それ自体は自然なことではあるのですが、前職の延長線上でマネジメントに比重を置くことに対して、危機感を感じていたんです。手を動かす部分を含めて、エンジニアとして良いキャリアを積むには別の環境に身を置く必要があると思い、転職を決意しました。 転職に際しては、自分が 身近に感じるサービスで特に自分の家族が関わるような領域が良いと考えており、医療はそうした意味でぴったりな領域 でした。これらの条件で転職エージェントを通じてメドレーに辿りつきました。 平山さん 岡村 : 先程も少し話しましたが、前職は自社プロダクトと他社向けコンサルティングを並行して運営していた会社でした。しかし、途中から経営方針が変わってコンサルティング業務をメインに据えるようになったんです。自分としては、自社プロダクトを作っている点を大事に考えていたため、転職を考えはじめました。 会社選びの軸としては、もちろん自社サービスが事業の主軸である会社というのが一番でした。他の条件としては「上場一歩手前」くらいのフェイズの会社というものがありました。これは、そのくらいのフェイズの会社であれば今までやっていた事業をいきなりピボットするという可能性が限りなく低いのではないかと考えたからです。そんな感じで会社を探していて、LinkedIn の広告経由でメドレーにアプローチして入社しました。 新居 : 岡村さんは次の会社の事業領域は、意識していたんでしょうか? 岡村 : 医療領域を名指しで考えていたわけではないです。しかし、いわゆる 昔ながらの慣習などが多く残るような業界や領域を、自分達が手がけたサービスで変えていくというのが良い という考えでした。これは前職でも考えていたことだったので、引き続き志向していました。 メドレー入社後にどのような仕事をしていたのか 新居 : ありがとうございます。そんな経緯でメドレーに入社したお二人ですが、入社後はどのような業務をされていたんでしょうか。 平山 : 私は入社後から一貫して CLINICS カルテを担当しています。入社後は医療に関する業務知識を身につけながら、周辺業務から徐々に関わっていきシステム面のキャッチアップをしていきました。一番最初に携わったプロジェクトとしては、CLINICS カルテにおける診察業務のコントロールを担う「診療ステータス」の拡張を行うという、カルテ全体に影響のある大きな改修に携わりました。それ以降も、小さいタスクを捌きつつ、中・大規模な施策に携わってきた感じです。 そこから医療 PF 横断のプロジェクトにも関わっていくようになりました。CLINICS というプロダクトは患者が使用するアプリを始め、調剤・歯科のサービスも提供しています。 医療 PF 全体の体験設計を踏まえて、周辺プロダクトとも積極的に関わっていく必要がある という点は特徴的だと思います。 岡村 : 私は入社当時は「社長室コンサル」という役割で入社し、この部署は M&A などをメインに担当していた部署だったんです。そのため最初にアサインされたのが NaCl メディカル社(現在はメドレー本体に統合)の業務面での PMI でした。これと平行して、現在も引き続き携わっている新しいレセコンを作るプロジェクトのプロダクトマネージャを担当してきました。 新規レセコンは CLINICS カルテと連携しているプロダクトなので、平山さんが率いるチームと連携 しながら、このプロダクトを作っている開発チームを率いています。 GM としてのミッションと就任してから変わったこと・変わらないこと 新居 : 話を聞いていると、お二人とも最初の仕事を順調にスケールアップしていったという形で現在の業務に繋っているんですね。さて、ここからは GM に就任してからの自身の業務がどのように変化してきたのかという点を聞きたいのですが、この点どうでしょうか。 平山 : ミッションはやはり変化しました。GM としてのミッションで一番求められるものは「 プロダクトを前進させる 」という部分と考えています。自身の管掌組織は当然ですが、組織を横断する形の取り組みも必要になります。 「ピープルマネジメント」という点も GM としての変化の１つかなと思います。とはいえ、先ほどの話と通じる部分はあり**「プロダクトに軸足を置いて目線を合わせていくこと」が基本**となります。また、組織上の持続可能性という意味においても「任せていく」というところは大事にしています。メンバーに優秀な方が多いので助けられている部分は多いと感じます。 エンジニアリングという意味では、手を動かす量は減りました。手の動かし方という意味では入社当初から横の動きを見るようにはしていたので GM になって変わったという部分は無いですね。 岡村 : レセコン新規開発プロジェクトでの GM のミッションとして、「プロジェクトの完遂」、「チームメンバーのピープルマネジメント」、「Tech Studio MATSUE(島根県にあるメドレーの拠点。レセコン新規開発プロジェクトの開発をしている)の管理」がメインになります。 GM に就任したタイミングは NaCl メディカル社がメドレー本体に吸収合併されたというタイミングでした。就任前はグループ会社ということもあり、開発業務を受発注するという動きに近い感じで協業してきました。GM になってからは、同じ会社になったのでより近い距離でチーム開発をするようになったり、メンバーのピープルマネジメントの割合が多くなるという変化がありました。 担当領域としてはレセコンのプロダクトマネジメントをしているという部分は変わらない部分です。また平山さんがおっしゃっていたように、いつまでも自分が上にいて指揮するという状態を良しとするのではなく、 メンバーの人をどんどんと上のロールに引き上げていくというのが GM の役割の 1 つ かと思うので、そういう意識でメンバーのマネジメントをしています。 エンジニアリングとマネジメントの比率はプロダクトのフェイズによって変わってくるし、変わるべきかなと思っています。現在は 8 対 2 でマネジメントの比率が多くなっています。一方でプロダクトの初期でどんどんと開発をしていかないといけないという場合には自分も含めて人手をかけて開発していくようにします。 新居 : お話をうかがうと、やはり GM 前よりもマネジメントの比率が多くなっているのではないかと思うのですが、葛藤などはありましたか。 平山 : 元々の自分のスタンスとして「自分も駒の一つ」としてプロダクト開発を推進していくという思考があります。GM の話が来たときにも、やれるかなという不安感はありましたが、今の場面においては自身がやった方が良いと感じて受けました。 岡村 : 私は出自がエンジニアではないというのもあって、葛藤のようなものも平山さんとは違って、特にありませんでした。元々 NaCl メディカル社だった松江オフィスとのハブになるのは、自分しかいないと思っていましたので躊躇のようなものも全く無かったです。 GM で苦労したポイント・どう克服していたか 新居 : ありがとうございます。では、GM になって苦労したとか大変だったというところってどんなところがありましたか。 平山 : 自分は口下手な方なんで、以前より喋る機会が増えたのが困ったところですね（笑） 新居 : 平山さんに口下手な印象は全然ありませんが（笑） 平山 : 他には、これはどちらかというと PdM 属性の仕事にも関わってくるんですが、開発計画の策定は大変です(メドレーでは 3 ヶ月ごとに開発計画を立てている)。 大規模な施策の実施と並行して優先度の高いタスクの差し込みを踏まえて、優先度の再設計や施策のフェージングや運用の検討したりしています。 自分で抱え込む必要はないですが、関係者と調整しつつも最終意思決定は自分になるので、様々な葛藤をしながら取り組んでいます 。 新居 : ピープルマネジメント面では何かありましたか。 平山 : 先程お話した「プロダクトに軸足を置いて目線を合わせていくこと」を大切にコミュニケーションを実施し、日々の業務を通してメンバー一人一人でシナジーが出る・良いキャリアが重ねられるようにしたいと考えていますが、先ほどの開発計画の難しさもここにあります。 新居 : ありがとうございます。では岡村さんはいかがでしょう。 岡村 : 平山さんに全く同感ですね（笑） 冗談は置いておいて、計画外の差し込みタスクなどが入ると、どうしてもチームの負荷が高くなってくるので、そこをコントロールしきれずに申し訳ないなと思うことがあります。 他には、メンバーのキャリア形成をどうするかという点が難しいと思います。 メンバーの志向に合わせての将来像を見据えて現在の業務に取り組んでもらいたい のですが、実際のタスクとそうしたキャリアの方向性が必ずしもぴったりと合うときばかりではないので、ここをどう揃えていくかという点にも苦労はしています。 新居 : なるほど、岡村さんの場合は元々として島根と東京という立地間でのマネジメントをされていたと思うんですが、リモートコミュニケーションが中心という環境での苦労は何かありましたか。 岡村 : 実はこれと言って無いんですよ。それでもちゃんと上手く機能している要因としては、2 つあります。1 つは島根の方に現地のメンバーを取りしきってくれるスキルを持ったメンバーが居てくれたことです。ここは今でも本当に助かっています。 また、当初から技術的な部分も含めて私もメンバーと一緒に勉強しながら、新しい取り組みをするというスタンスを持ってプロジェクトを推進できたことです。ですので、離れたところから命令する人のような感じではなく、 チームで一緒にプロジェクトを進める人という認識を持ってもらえた んじゃないかなと考えています。 もちろん、関係値を作れるまでは私が最初の頃は 1 ヶ月に 1~2 回程度島根に出張して、実際にメンバーと会ったりすることもしていましたが。 GM を担う上で、役に立った経験・知識 新居 : ここからは、お二人が今までの業務の中で積んできた経験・知識の内、現在 GM として活動する上で役に立っているものとして、どんなものがあるのか聞ければと思います。 平山 : そうですね、一番役に立っているなと感じているのは前職で経験した「 様々なステークホルダーとの主体性を持った折衝経験 」です。色々な会社や立場の方とコミュニケーションを取ることが多かったんですね。専門性もそれぞれ違う方達とお話して物事を進める経験ができたことは、今の GM という役割に本当に役立っていると思います。 岡村 : 私が役に立っていると感じる経験は、「 一回深く細かいところまで業務を見てみて理解をしてから、改めて俯瞰した視点で業務を見直してメンバーにお願いする 」という習慣です。この相反する方法をバランス良くできるようになっているというのが、良い点なのかなと思っています。また、深く見るというのは自分が興味を持っている分野でないと中々難しいので、何にでも興味を持って業務に取り組むという心持ちも必要になるかと考えています。 こうした形で業務を分解してメンバーにお願いできるところはしながら、GM としては適切に権限委譲していくというのに役立っています。 エンジニアのピープルマネジメントで意識していること 新居 : 今までのお話でも少し出ている話題になるのですが、GM としてエンジニアのマネジメントで意識しているポイントって、どんなことがありますか。 平山 : 自分達が作る プロダクトへの興味関心・解像度を高め、何を作るのか 。という点において各所コミュニケーションを含めて主体的に動くこと。そうした積み重ねの延長線上にあるエンジニアとしてのキャリア形成を意識しています。 この考え方に加えて「プロダクトの持続可能性を高める」というテーマで、エンジニア・デザイナー・ディレクター・ QA エンジニア・カスタマーサクセスといったプロダクトに関わる人達の専門性を踏まえたタスクの再配布・プロジェクト設計を行う。といった体制作りも推進しようとしています。 新居 : 「プロダクトの持続可能性を高める」というのは、すごく難しい試みですよね。 平山 : 確かにとても難しいなと思います。でも打ち手としては色々あるのではないかと考えていて。「属人性の排除」といった点は、分かりやすいのではないかなと思います。誰かに依存した状態は、組織変更や事業スケールの変化に弱くなりがちですよね。 大事なのは「人から組織への移行」「仕組み化」と捉えています。「できる人を増やす」については、大事だけど秘伝のタレが受け継がれるだけになってしまうので、持続可能性の観点では本質的ではないかなと。 一方で「仕組み化するための計画的な属人性」については推奨できると考えてます。新しいことをいきなり「組織に転換」や「人を増やしてローテする」だと、ナレッジが蓄積されづらく、次の一手が打ちづらくなるので。 新居 : そうした取り組みをするのに、例えばエンジニアだと作ってみたものがプロダクトの目指す方向性とズレが生じていたというような事態があると思うんですが、そうしたズレを事前に仕組みで抑えるような事をしているんですか。 平山 : きっちりとした仕組みなどは作ってはいないです。仕組み化というよりも、そうならないように メンバーから上がってきた疑問などに対する壁打ちなどは気軽にできる ようにしています。また、そういった相談を気軽にできるような自分自身のプロデュースといいますか、キャラ作りみたいなものも含めてメンバーが相談しにくいという空気を作らないようにはしていますね。 新居 : ありがとうございます。岡村さんはどんな意識をしていますか。 岡村 : やっぱり平山さんに全く同感ですね（笑） 付け加えると、ソフト面ですが メンバーであるエンジニアが楽しめる環境作り というところを意識しています。楽しさにも色々な種類があるとは思いますが、単にコーディングするだけではなく、やはりプロダクトそれ自体の提供価値というものをしっかりと共有して、プロダクトを作ること自体に楽しさを感じてもらう…というのは重要じゃないかなと思っています。 また楽しさの別側面ですが、新しいテクノロジーなどもどんどんと取り入れることができるような仕組み作りもしています。島根のメンバーは今回のプロジェクトで初めて Ruby を使うというメンバーも多かったので、ここで楽しさを感じられないと、こうしたテクノロジー自体を嫌いになってしまう恐れがあるなと思ったので。 そうした「楽しい仕事」にしていくと「時間をかけなきゃ」ではなく「時間をかけたい」という感じで取り組めるようになると思います。 GM という役割の醍醐味とは 新居 : それでは終盤になってきましたが、GM の「やりがい」や「醍醐味」はどういったものになりますか。 岡村 : 一番は「ピープルマネジメント」になるんじゃないかと考えています。最近、岸田首相の所信表明演説で聞いて感銘を受けたアフリカの諺ですが「早く行きたいなら 1 人で行け、遠くへ行きたいならみんなで行け」という言葉はピープルマネジメントの本質なんじゃないかなと思っています。 メンバーと一緒に遠くに行くために組織作り などをしていけるのが醍醐味だと感じています。 平山 : メンバーの 個人スキルを高めつつ「チーム」に還元してもらうための仕組み を作っていく。というのは、醍醐味と言えるのかなと。CTO インタビューで田中も言っていますが「チームバリュー」は大切だと考えています。 チームといっても、狭義のチームではなくプロダクトに関わる関係者全員を含めたチームという感じで意識しています。開発組織に閉じないバリューの発揮がメンバーそれぞれでできると心強いと思います。 メドレーで GM やリードエンジニアのロールに向いている方 新居 : 最後になるのですが、メドレーで GM やテックリードといったロールに向いているのは、どんな人だと思いますか。 平山 : 基本的に 物事を前に進めるための解像度を高く描ける人 かなと思っています。何を誰のためにというのを体現しつつ、関係者を引っぱっていける人ですね。メドレーの Our Essentials 全般必要だとは思いますが、その中でも「成果を出す」「自分をアップデート」「組織水準を高める」「革新と改善を主導」というところが必要になるかな。困難な状況でも結果を出しつつ、自分の行動も高めていき、結果組織・プロダクトを良くしていける…というのがメドレーのリードと呼ばれているエンジニアかと思います。 やり方としては、マイクロマネジメントではなく、基本となる考え方をちゃんと伝えてメンバーに学んでもらう…という、やり方ができる人が向いていると思います。 岡村 : 困難な状況であっても何とかして前に進めることができる人 でしょうか。無理矢理に進めるというわけではなく、状況の整理や色々な部署との調整などもしたりして、何とか結果という形にしていける能力がある人がリードとしてメンバーを引っぱっていける人だと思います。 もちろん、フェイズによってメンバーとの関わりなどはちゃんと調整していける柔軟さなども必要になると思います。 新居 : なるほど。本日は色々なお話をしていただきまして、ありがとうございました! さいごに メドレーの GM 二人に仕事について聞いていきました。 前回の CTO インタビューでも語られた開発組織の話ですが、より現場に近い GM という立場のメンバーからの話でまた違った雰囲気などを感じていただけたかと思います。 このような GM を「ぜひやりたい!」という方や「こんな上司の元で自分の力を発揮していきたい!」という方はぜひカジュアルにお話ができればと思います。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。技術広報・エンジニアの平木です。 既に 2 月に 発表 されていますが、4 月より弊社の経営体制を大幅に変更しました。開発組織について大きく変わった部分として CTO 2 名体制になった点があります。そこで、なぜ CTO を 2 名にしたのかや、これからのメドレーの開発組織についてを CTO になった 2 人にインタビューしました。 インタビュイー紹介 稲本さん 執行役員。人材プラットフォーム(以下、人材 PF)CTO。独立系 SIer でのインフラエンジニアに始まり、インターネット企業での様々なサービスのインフラ構築を経て、音楽配信サービスやインターネットラジオサービスのサーバサイドエンジニアとして従事。2014 年メドレー入社後は創業時から運営しているジョブメドレーのプロダクト開発に従事。その後、同サービスのリードエンジニア、開発責任者を経て、2023 年 4 月より現職。 田中さん 執行役員。医療プラットフォーム(以下、医療 PF)CTO。独立系 SIer でのアプリケーションエンジニアや IT コンサルタントを経て、株式会社サイバーエージェントでサーバサイドエンジニアとしてソーシャルゲームや動画サービスなどの開発立ち上げに従事。2016 年メドレー入社後は CLINICS カルテの立ち上げを経験。その後 CLINICS 開発責任者を経て医療 PF プロダクト横断基盤の立ち上げ・開発責任者を経て 2023 年 4 月より現職。 左から田中さん、稲本さん CTO を 2 名体制にして開発組織の体制をアップデートした理由 平木 : さっそくですが、2023 年 4 月よりお二人がそれぞれ人材 PF と医療 PF の CTO に就任されて、改めて開発組織のアップデートがされましたが、どういった背景でこの体制になったんでしょうか。 田中 : 会社全体の組織設計として医療 PF と人材 PF に分かれたというのがまず最初にあったんですが、当初、開発組織は両 PF を横断する形で 1 人の CTO が見ていました。各 PF 内にそれぞれプロダクトがあり開発もプロダクトごとにチームを分けていましたが、それぞれの開発チームが有機的に動きつつも組織全体の小回りの効きやすさなども考えて、こうした体制になっていました。 ただ、時間が経つに連れ段々と開発チームも各 PF 自体 の規模も大きくなってきたので、 1 人の CTO ではマネジメントが難しくなってきました。また医療 PF と人材 PF で共通する開発組織の文化などはありますが、扱っている事業内容の差異から選定技術やプロジェクトの進め方などの違う部分も出てきたので、それぞれの PF で CTO を置いて組織面・技術面の課題に対応しようということになったためです。 稲本 : 開発組織の人数としては 100 名を越えているのですが、それだけではなく就業場所の違いやサービスの多様化など、それぞれの PF で特性が違う課題がこれから先も出てくるだろうということで、先を見据えての開発組織のアップデートの一環として CTO 2 名体制にしたというところですね。 平木 : これからの組織の変化を見据えた動きだということですね。 新しい開発体制になって変わっていく部分・変わらない部分 平木 : 新体制になってまだ日が浅いですが、これから変えていく部分というのはどういったところになっていくんでしょうか。 稲本 : 自分達 2 人が持っている色々な役割を分解していって他のメンバーへ役割を委譲していくことですね。CTO が色々持ちすぎると組織のスケールに対しボトルネックになることは目に見えているので。 それ以外には、役割を担ったチームやメンバーが自身で思考し行動しやすい組織にしていくことで、更なるチャレンジがしやすかったりパフォーマンスを発揮しやすい状態にしていけたらと考えています。 平木 : なるほど。田中さんは何かありますか。 田中 : 「役割の明確化」もその 1 つですが、将来取り組むべき課題に向けて中長期を見据えた開発組織の設計や運営に向き合うフェイズになってきたと感じており、強化していきたいと考えています。 平木 : 将来の課題に対して技術・組織なども先手を打っていくイメージですね。 新体制での開発組織のミッション 平木 : それでは新体制になって改めて開発組織のミッションとしてはどういったものがありますか。 田中 : 会社全体のミッションと基本は一緒ではあります。「医療」という大きい領域の課題に対して、何のために開発をするのかや、その開発をすることによってどういった顧客価値を提供できるのかというところは、ちゃんとミッションに紐付いている部分なので変えずにいきます。 その上で、有効な施策をどれだけ素早くデリバリーできるかというところには今以上に注力していきたいところです。そのためには無駄を省き、やるべき事に集中してより生産性の高い開発を目指します。 プロダクト開発において無駄な機能開発を行なうと、後からそこを削ろうと思っても難しいですし、作った結果誰も幸せにならないということになってしまいます。こうならないためにもスピード感は落とさないで、事業側メンバーと協力しながら適切な要件整理をしたりなど、どうやって顧客へ適切なプロダクトを届けるか?という部分により重きを置いていきたいです。 事業とプロダクト開発の関係性 平木 : さて、次に先程のお話にも出てきましたが、事業とプロダクト開発の関係性についてお聞きします。お二人が考えるこの関係性はどのようなものでしょうか。 田中 : ここも以前から変わらないスタンスですが、改めて定義するなら「テクノロジーを最大限に使って医療領域の課題を解決する」という関係になります。テクノロジーとメドレーの事業である医療領域の課題解決という 2 つの側面のどれが欠けても、プロダクトとして良いものは生まれないと考えています。 平木 : 主に Web のテクノロジーを適材適所で課題解決のために使っていくというスタンスですね。 田中 : そうですね。先に来るのはあくまでも、「医療領域の課題解決をする」という部分になるのですが、その手段として必要な技術は全部使っていこうという姿勢です。なので、まずは開発組織のメンバー一人ひとりが、ドメインの理解をするということが始めの一歩です。そうして課題の本質を見極めて解決に必要な手段は何があるのかを考えていく必要が出てきます。 解決のために最適であれば、その技術の新旧や使用実績などを問わず取り入れて開発していくという心構えですね。そのためにはきちんと技術動向を追っていき日頃からユースケースなどを想像しながら、その技術を触ったりする必要も出てきます。 稲本 : ドメイン知識とテクノロジーを最大限に駆使し、プロダクト開発を通して価値を届けるというのが我々のミッションなのかなと思います。 稲本さん 平木 : 医療領域の未来を変えていくために、技術を最大限に用いたプロダクトドリブンであることが大切ということですね。 田中 : メドレーではそれだけじゃない部分も意識していますね。一言で「プロダクト」と言ってもサービスとそれを作る開発者というだけではなく、顧客接点を持つ事業部などのメンバー全ての動きも合わせて「プロダクト」という意識を持っています。 平木 : なるほど、プロダクトに関わっている人全員を合わせて「プロダクト」だよということですか。 田中 : 例えば開発メンバーが良いプロダクトを提供したとしても、そのプロダクトを使ったユーザーが疑問に思った部分があったとします。そこで問い合わせをしたときに、その体験が良くない場合はやっぱり「プロダクトに関する体験が良くない」という印象になってしまいますよね。これはセールスなど他の領域でも起き得る話ですが、メドレーではそういった部分も含めて「プロダクト開発」という意識を持っているので、他部署だからということではなくトータルでユーザーに価値を感じてもらえるようにしていくということを大切にしています。 平木 : 確かにユーザーはそういった関わるもの全部一緒に「プロダクト」と思いますもんね。 稲本 : 日々の業務の中で直接ユーザーと対話してくれている方々がたくさんいます。 Our Essentials (以下、OE)で特に好きなものの一つで「信頼を獲得する」というものがあります。OE 自体は主に社内向けのメッセージにはなるんですが、日々の業務の中で他者からの信頼を得ることが出来るような振る舞いや成果を出すこと、その信頼の積み重ねがプロダクト全体にも反映され、結果としてユーザーからも信頼される/価値を感じてもらえるプロダクトの提供につながっているのだと感じています。 プロダクトと技術の関係について 平木 : もう少し開発についての話を掘り下げていこうと思います。弊社では現在のところ Ruby や Ruby on Rails(以下 Rails)で作られているプロダクトが大半ではありますが、Go や Node.js などをメインに使っているプロダクトもありますよね。そうした技術選定のときの基本姿勢としてはどういったものがありますか。 田中 : 基本として、「それぞれのプロダクトにとって現時点でこの技術で開発するのが、良いことだよね」というのを大切にしています。組織的に知見が多いということもあって、Rails を使っているプロダクトが多いのはそうなんですが、この技術じゃないとダメという縛りがあるわけではないです。Go や Node.js にしても、そのプロダクトに現状最適だという視点で技術選定をしています。 稲本 : 今までできなかったことが、新しい技術を使ったら解決するのにという場面も結構あると思います。そういうときに「今使ってないから…」というのではなく、その技術を使ったほうがプロダクトにプラスになると判断したら使っていくようにしています。 田中 : ですので、今プロダクトで使っている技術で守っていくというより、個々人でアンテナを張って新しい技術は積極的にキャッチアップしていきながら、チーム内で「これ使うと良さそうだからやっていこう」という感じですね。 平木 : 先程も出てきたユーザーに価値提供を素早くするという要素の一つということですね。そうすると、例えば開発者体験を良くするような技術やフローなんかを取り入れるというのも、そうした志向の一部ということになりますか? 田中 : そうですね。良いものを早くユーザーに届けるという一側面になります。開発者体験を良くするというのが最終的な目的ではなくて、その結果としてチームの生産性が上がるのなら体験を良くすると良いよねという。プロダクトコードの負債解消とかもそうですが、バランスが確かに難しいのですが、こういったところを疎かにすると結果として顧客への十分な価値提供ができなくなってしまうリスクもあるので、短期と中長期できちんとバランシングしつつ開発に取り組んでいきたいと思っています。 田中さん 平木 : 改めてここで現在の開発体制について伺っていければと思います。 田中 : 人材 PF も医療 PF もプロダクトに紐付いて複数のチームに分かれていて、チームの人数規模としてみると多少の上下はあるんですが、プロダクトマネージャ(以下、PdM) やデザイナー、エンジニアを合わせて 10 人前後というチームが多いです。 平木 : そうしたチーム内で、特にエンジニアはどのような役割分担をしていることが多いですか? 稲本 : もちろんチームによっても違ってくるんですが、チームの中に PM と TL を置いて、そのチームの中にメンバーが数人いる形が多いですね。この単位をベースにして toC 向けのプロジェクト、toB 向けのプロジェクトのような感じでチームを分けて開発を行なっています。 田中 : メンバー個々人はサーバサイドやフロントエンド、インフラのような得意領域がありそこを考慮した開発をしていっていますが、サーバサイドだけやる人という形ではなく、得意領域と隣り合う領域についても意識し、可能な限り理解してコラボレーションしていこうというやり方を取っています。これによりコミュニケーションコストが下がることで生産性高く、品質向上にも寄与するというのが理由になります。 もちろんプロとして自分の得意分野で力を存分に発揮はしてもらうというのは大前提ですが、その強みを周囲のメンバーに還元しつつ、得意領域以外はそこが得意なメンバーから還元してもらいながら、良いプロダクトを作っていくというのがメドレーの開発組織のスタンスになります。 開発組織の雰囲気やメンバーの働き方について 平木 : 今まで開発組織の制度的な側面を中心に聞いてきましたが、組織のソフト面についてお聞きします。メドレーの開発組織の雰囲気ですが、どんな雰囲気だったりしますか? 稲本 : 全体的にはわりと和やかな雰囲気は持ちつつも、各自のバリューに対してはストイックな感じかなと思います。 自分たちで決めた期日など守るところはしっかり守ろうという意識を持ちつつ、無理な期日になりそうであればスケジュールやスコープを調整したり、プロジェクトの進め方で上手く行ったこと/行かなかったことを振り返りを通して改善を図ったりするなど、当たり前のことを高い水準でやり遂げていく習慣が根付いていると思います。 コミュニケーションに関しては、非同期コミュニケーションがベースではあります。口頭での相談なんかももちろんしますが、認識がずれないように話したことを issue などに残したりしてます。 雑談みたいなものはミーティングの後半パートにあえて雑談パートを作るなどしていますが、業務中にずっとするようなことはないですね。開発中はそれぞれが集中していることが多いです。 田中 : チームごとに違いますが、朝会や夕会などでちゃんとコミュニケーションが取れるようにしているということが多いですね。なので、あんまり他の時間に雑談みたいなものが必要ないという感じです。 平木 : 和やかながらも、締めるところは締めるという雰囲気ですね。開発チームの皆さんはどんな働き方をしている人が多いですか? 稲本 : これも個々人で違っていますが出社とリモートのハイブリッドな方が多いかと思います。 やはり開発に集中したい場面ではリモートの方が割り込みも少なくなりやすく集中しやすいですし、物事の認識を揃えたり決めていく場合は、ミーティングなどで実際に顔を合わせた方が効率も良いことはあると思いますね。 田中 : 自分のバリューを最大化できるように働いていこうというのが基本になっています。 平木 : 各自ちゃんと考えてプロダクトに貢献できるようにということですね。そうした働き方の先にキャリアパスがあると思いますが、その観点ではどのようなパスがありますか? 田中 : 大きく分けては、マネジメントをメインにするか、テクニカル部分を特化させたスペシャリストとなるかという 2 つになります。役割分担にもちょっと関わりますが、内容としては、例えば PdM を目指していくというのも道としてはありますし、自分の得意領域を最大限に伸ばしてテックリードとして技術をもってプロダクトを引っぱっていくという道なんかもあります。1on1 や評価などでそうした部分は本人と刷り合わせをしていきながら決めていく形になります。 平木 : 評価のお話が出てきましたが、どういった観点で評価されますか? 稲本 : ベースとしては会社として決めた OE に沿ったものになります。OE を踏まえつつ、業務目標や技術的な目標を立ててそれができたかどうかが基準になりますね。 立てた目標が色々な理由で達成できなかったというケースももちろん出てくると思いますが、内容として自分はどういった部分は頑張ったとか、どういう理由で達成できなかったなどの自分なりの説明ができるかというのを重視しています。 田中 : 目標はチームバリューにいかに寄与したかを重視しています。OE に基づきチームとして達成しないといけない目標があってそれをブレイクダウンした上で、自分が寄与できるのはどこかという感じで目標にしてもらいます。一見目に見えにくい動きだったとしても、ちゃんとチームに貢献しているねとなれば、もちろん評価の対象になりますし、逆に例えばいくら頑張って新技術を習得したとなってもチームに貢献してなければ評価はされにくいです。 平木 : ありがとうございます。最後にメドレーで開発することの良さを教えてもらえればと思います。 田中 : メドレーは長期を見据えて課題に取り組んでいる会社であり、泥臭く地道に積み重ねなければいけないこともすごく多いです。そのため短期で結果が見えづらいこともあるかもしれません。ですが、医療領域でどっしりと腰を据えて長期的に本質を捉えた開発をしているため、技術面だけではなくプロダクトデザインとして何のために、どのようなアプローチが適切か、という思考力や設計能力も身に付きやすいのではないかと思います。 稲本 : 長期で課題に取り組むとなると「同じことの繰り返しではないか」と感じる方もいるかもしれませんが、プロダクトが成長すればフェーズも変わりますし、取り組むことにも変化が生じていくので成長や変化を楽しめる人には合っているのではないかと思います。 さいごに 新体制で CTO 2 人にメドレーの開発組織について色々と語ってもらいました。 2 人も話をしていましたが、メドレーでは長期思考・未来志向の考え方をベースに、ユーザーの本質的な課題はなにか、どうすればそれらを解決できるか?という部分にフォーカスを当てて開発をするという志向がとても強いと思います。 そうした環境でじっくりと確実にユーザーに価値を提供できるという仕事だと思いますので、ご興味を持たれた方はぜひカジュアルにお話をさせていただければと思います! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。技術広報・エンジニアの平木です。 既に 2 月に 発表 されていますが、4 月より弊社の経営体制を大幅に変更しました。開発組織について大きく変わった部分として CTO 2 名体制になった点があります。そこで、なぜ CTO を 2 名にしたのかや、これからのメドレーの開発組織についてを CTO になった 2 人にインタビューしました。 インタビュイー紹介 稲本さん 執行役員。人材プラットフォーム(以下、人材 PF)CTO。独立系 SIer でのインフラエンジニアに始まり、インターネット企業での様々なサービスのインフラ構築を経て、音楽配信サービスやインターネットラジオサービスのサーバサイドエンジニアとして従事。2014 年メドレー入社後は創業時から運営しているジョブメドレーのプロダクト開発に従事。その後、同サービスのリードエンジニア、開発責任者を経て、2023 年 4 月より現職。 田中さん 執行役員。医療プラットフォーム(以下、医療 PF)CTO。独立系 SIer でのアプリケーションエンジニアや IT コンサルタントを経て、株式会社サイバーエージェントでサーバサイドエンジニアとしてソーシャルゲームや動画サービスなどの開発立ち上げに従事。2016 年メドレー入社後は CLINICS カルテの立ち上げを経験。その後 CLINICS 開発責任者を経て医療 PF プロダクト横断基盤の立ち上げ・開発責任者を経て 2023 年 4 月より現職。 左から田中さん、稲本さん CTO を 2 名体制にして開発組織の体制をアップデートした理由 平木 : さっそくですが、2023 年 4 月よりお二人がそれぞれ人材 PF と医療 PF の CTO に就任されて、改めて開発組織のアップデートがされましたが、どういった背景でこの体制になったんでしょうか。 田中 : 会社全体の組織設計として医療 PF と人材 PF に分かれたというのがまず最初にあったんですが、当初、開発組織は両 PF を横断する形で 1 人の CTO が見ていました。各 PF 内にそれぞれプロダクトがあり開発もプロダクトごとにチームを分けていましたが、それぞれの開発チームが有機的に動きつつも組織全体の小回りの効きやすさなども考えて、こうした体制になっていました。 ただ、時間が経つに連れ段々と開発チームも各 PF 自体 の規模も大きくなってきたので、 1 人の CTO ではマネジメントが難しくなってきました。また医療 PF と人材 PF で共通する開発組織の文化などはありますが、扱っている事業内容の差異から選定技術やプロジェクトの進め方などの違う部分も出てきたので、それぞれの PF で CTO を置いて組織面・技術面の課題に対応しようということになったためです。 稲本 : 開発組織の人数としては 100 名を越えているのですが、それだけではなく就業場所の違いやサービスの多様化など、それぞれの PF で特性が違う課題がこれから先も出てくるだろうということで、先を見据えての開発組織のアップデートの一環として CTO 2 名体制にしたというところですね。 平木 : これからの組織の変化を見据えた動きだということですね。 新しい開発体制になって変わっていく部分・変わらない部分 平木 : 新体制になってまだ日が浅いですが、これから変えていく部分というのはどういったところになっていくんでしょうか。 稲本 : 自分達 2 人が持っている色々な役割を分解していって他のメンバーへ役割を委譲していくことですね。CTO が色々持ちすぎると組織のスケールに対しボトルネックになることは目に見えているので。 それ以外には、役割を担ったチームやメンバーが自身で思考し行動しやすい組織にしていくことで、更なるチャレンジがしやすかったりパフォーマンスを発揮しやすい状態にしていけたらと考えています。 平木 : なるほど。田中さんは何かありますか。 田中 : 「役割の明確化」もその 1 つですが、将来取り組むべき課題に向けて中長期を見据えた開発組織の設計や運営に向き合うフェイズになってきたと感じており、強化していきたいと考えています。 平木 : 将来の課題に対して技術・組織なども先手を打っていくイメージですね。 新体制での開発組織のミッション 平木 : それでは新体制になって改めて開発組織のミッションとしてはどういったものがありますか。 田中 : 会社全体のミッションと基本は一緒ではあります。「医療」という大きい領域の課題に対して、何のために開発をするのかや、その開発をすることによってどういった顧客価値を提供できるのかというところは、ちゃんとミッションに紐付いている部分なので変えずにいきます。 その上で、有効な施策をどれだけ素早くデリバリーできるかというところには今以上に注力していきたいところです。そのためには無駄を省き、やるべき事に集中してより生産性の高い開発を目指します。 プロダクト開発において無駄な機能開発を行なうと、後からそこを削ろうと思っても難しいですし、作った結果誰も幸せにならないということになってしまいます。こうならないためにもスピード感は落とさないで、事業側メンバーと協力しながら適切な要件整理をしたりなど、どうやって顧客へ適切なプロダクトを届けるか?という部分により重きを置いていきたいです。 事業とプロダクト開発の関係性 平木 : さて、次に先程のお話にも出てきましたが、事業とプロダクト開発の関係性についてお聞きします。お二人が考えるこの関係性はどのようなものでしょうか。 田中 : ここも以前から変わらないスタンスですが、改めて定義するなら「テクノロジーを最大限に使って医療領域の課題を解決する」という関係になります。テクノロジーとメドレーの事業である医療領域の課題解決という 2 つの側面のどれが欠けても、プロダクトとして良いものは生まれないと考えています。 平木 : 主に Web のテクノロジーを適材適所で課題解決のために使っていくというスタンスですね。 田中 : そうですね。先に来るのはあくまでも、「医療領域の課題解決をする」という部分になるのですが、その手段として必要な技術は全部使っていこうという姿勢です。なので、まずは開発組織のメンバー一人ひとりが、ドメインの理解をするということが始めの一歩です。そうして課題の本質を見極めて解決に必要な手段は何があるのかを考えていく必要が出てきます。 解決のために最適であれば、その技術の新旧や使用実績などを問わず取り入れて開発していくという心構えですね。そのためにはきちんと技術動向を追っていき日頃からユースケースなどを想像しながら、その技術を触ったりする必要も出てきます。 稲本 : ドメイン知識とテクノロジーを最大限に駆使し、プロダクト開発を通して価値を届けるというのが我々のミッションなのかなと思います。 稲本さん 平木 : 医療領域の未来を変えていくために、技術を最大限に用いたプロダクトドリブンであることが大切ということですね。 田中 : メドレーではそれだけじゃない部分も意識していますね。一言で「プロダクト」と言ってもサービスとそれを作る開発者というだけではなく、顧客接点を持つ事業部などのメンバー全ての動きも合わせて「プロダクト」という意識を持っています。 平木 : なるほど、プロダクトに関わっている人全員を合わせて「プロダクト」だよということですか。 田中 : 例えば開発メンバーが良いプロダクトを提供したとしても、そのプロダクトを使ったユーザーが疑問に思った部分があったとします。そこで問い合わせをしたときに、その体験が良くない場合はやっぱり「プロダクトに関する体験が良くない」という印象になってしまいますよね。これはセールスなど他の領域でも起き得る話ですが、メドレーではそういった部分も含めて「プロダクト開発」という意識を持っているので、他部署だからということではなくトータルでユーザーに価値を感じてもらえるようにしていくということを大切にしています。 平木 : 確かにユーザーはそういった関わるもの全部一緒に「プロダクト」と思いますもんね。 稲本 : 日々の業務の中で直接ユーザーと対話してくれている方々がたくさんいます。 Our Essentials (以下、OE)で特に好きなものの一つで「信頼を獲得する」というものがあります。OE 自体は主に社内向けのメッセージにはなるんですが、日々の業務の中で他者からの信頼を得ることが出来るような振る舞いや成果を出すこと、その信頼の積み重ねがプロダクト全体にも反映され、結果としてユーザーからも信頼される/価値を感じてもらえるプロダクトの提供につながっているのだと感じています。 プロダクトと技術の関係について 平木 : もう少し開発についての話を掘り下げていこうと思います。弊社では現在のところ Ruby や Ruby on Rails(以下 Rails)で作られているプロダクトが大半ではありますが、Go や Node.js などをメインに使っているプロダクトもありますよね。そうした技術選定のときの基本姿勢としてはどういったものがありますか。 田中 : 基本として、「それぞれのプロダクトにとって現時点でこの技術で開発するのが、良いことだよね」というのを大切にしています。組織的に知見が多いということもあって、Rails を使っているプロダクトが多いのはそうなんですが、この技術じゃないとダメという縛りがあるわけではないです。Go や Node.js にしても、そのプロダクトに現状最適だという視点で技術選定をしています。 稲本 : 今までできなかったことが、新しい技術を使ったら解決するのにという場面も結構あると思います。そういうときに「今使ってないから…」というのではなく、その技術を使ったほうがプロダクトにプラスになると判断したら使っていくようにしています。 田中 : ですので、今プロダクトで使っている技術で守っていくというより、個々人でアンテナを張って新しい技術は積極的にキャッチアップしていきながら、チーム内で「これ使うと良さそうだからやっていこう」という感じですね。 平木 : 先程も出てきたユーザーに価値提供を素早くするという要素の一つということですね。そうすると、例えば開発者体験を良くするような技術やフローなんかを取り入れるというのも、そうした志向の一部ということになりますか? 田中 : そうですね。良いものを早くユーザーに届けるという一側面になります。開発者体験を良くするというのが最終的な目的ではなくて、その結果としてチームの生産性が上がるのなら体験を良くすると良いよねという。プロダクトコードの負債解消とかもそうですが、バランスが確かに難しいのですが、こういったところを疎かにすると結果として顧客への十分な価値提供ができなくなってしまうリスクもあるので、短期と中長期できちんとバランシングしつつ開発に取り組んでいきたいと思っています。 田中さん 平木 : 改めてここで現在の開発体制について伺っていければと思います。 田中 : 人材 PF も医療 PF もプロダクトに紐付いて複数のチームに分かれていて、チームの人数規模としてみると多少の上下はあるんですが、プロダクトマネージャ(以下、PdM) やデザイナー、エンジニアを合わせて 10 人前後というチームが多いです。 平木 : そうしたチーム内で、特にエンジニアはどのような役割分担をしていることが多いですか? 稲本 : もちろんチームによっても違ってくるんですが、チームの中に PM と TL を置いて、そのチームの中にメンバーが数人いる形が多いですね。この単位をベースにして toC 向けのプロジェクト、toB 向けのプロジェクトのような感じでチームを分けて開発を行なっています。 田中 : メンバー個々人はサーバサイドやフロントエンド、インフラのような得意領域がありそこを考慮した開発をしていっていますが、サーバサイドだけやる人という形ではなく、得意領域と隣り合う領域についても意識し、可能な限り理解してコラボレーションしていこうというやり方を取っています。これによりコミュニケーションコストが下がることで生産性高く、品質向上にも寄与するというのが理由になります。 もちろんプロとして自分の得意分野で力を存分に発揮はしてもらうというのは大前提ですが、その強みを周囲のメンバーに還元しつつ、得意領域以外はそこが得意なメンバーから還元してもらいながら、良いプロダクトを作っていくというのがメドレーの開発組織のスタンスになります。 開発組織の雰囲気やメンバーの働き方について 平木 : 今まで開発組織の制度的な側面を中心に聞いてきましたが、組織のソフト面についてお聞きします。メドレーの開発組織の雰囲気ですが、どんな雰囲気だったりしますか? 稲本 : 全体的にはわりと和やかな雰囲気は持ちつつも、各自のバリューに対してはストイックな感じかなと思います。 自分たちで決めた期日など守るところはしっかり守ろうという意識を持ちつつ、無理な期日になりそうであればスケジュールやスコープを調整したり、プロジェクトの進め方で上手く行ったこと/行かなかったことを振り返りを通して改善を図ったりするなど、当たり前のことを高い水準でやり遂げていく習慣が根付いていると思います。 コミュニケーションに関しては、非同期コミュニケーションがベースではあります。口頭での相談なんかももちろんしますが、認識がずれないように話したことを issue などに残したりしてます。 雑談みたいなものはミーティングの後半パートにあえて雑談パートを作るなどしていますが、業務中にずっとするようなことはないですね。開発中はそれぞれが集中していることが多いです。 田中 : チームごとに違いますが、朝会や夕会などでちゃんとコミュニケーションが取れるようにしているということが多いですね。なので、あんまり他の時間に雑談みたいなものが必要ないという感じです。 平木 : 和やかながらも、締めるところは締めるという雰囲気ですね。開発チームの皆さんはどんな働き方をしている人が多いですか? 稲本 : これも個々人で違っていますが出社とリモートのハイブリッドな方が多いかと思います。 やはり開発に集中したい場面ではリモートの方が割り込みも少なくなりやすく集中しやすいですし、物事の認識を揃えたり決めていく場合は、ミーティングなどで実際に顔を合わせた方が効率も良いことはあると思いますね。 田中 : 自分のバリューを最大化できるように働いていこうというのが基本になっています。 平木 : 各自ちゃんと考えてプロダクトに貢献できるようにということですね。そうした働き方の先にキャリアパスがあると思いますが、その観点ではどのようなパスがありますか? 田中 : 大きく分けては、マネジメントをメインにするか、テクニカル部分を特化させたスペシャリストとなるかという 2 つになります。役割分担にもちょっと関わりますが、内容としては、例えば PdM を目指していくというのも道としてはありますし、自分の得意領域を最大限に伸ばしてテックリードとして技術をもってプロダクトを引っぱっていくという道なんかもあります。1on1 や評価などでそうした部分は本人と刷り合わせをしていきながら決めていく形になります。 平木 : 評価のお話が出てきましたが、どういった観点で評価されますか? 稲本 : ベースとしては会社として決めた OE に沿ったものになります。OE を踏まえつつ、業務目標や技術的な目標を立ててそれができたかどうかが基準になりますね。 立てた目標が色々な理由で達成できなかったというケースももちろん出てくると思いますが、内容として自分はどういった部分は頑張ったとか、どういう理由で達成できなかったなどの自分なりの説明ができるかというのを重視しています。 田中 : 目標はチームバリューにいかに寄与したかを重視しています。OE に基づきチームとして達成しないといけない目標があってそれをブレイクダウンした上で、自分が寄与できるのはどこかという感じで目標にしてもらいます。一見目に見えにくい動きだったとしても、ちゃんとチームに貢献しているねとなれば、もちろん評価の対象になりますし、逆に例えばいくら頑張って新技術を習得したとなってもチームに貢献してなければ評価はされにくいです。 平木 : ありがとうございます。最後にメドレーで開発することの良さを教えてもらえればと思います。 田中 : メドレーは長期を見据えて課題に取り組んでいる会社であり、泥臭く地道に積み重ねなければいけないこともすごく多いです。そのため短期で結果が見えづらいこともあるかもしれません。ですが、医療領域でどっしりと腰を据えて長期的に本質を捉えた開発をしているため、技術面だけではなくプロダクトデザインとして何のために、どのようなアプローチが適切か、という思考力や設計能力も身に付きやすいのではないかと思います。 稲本 : 長期で課題に取り組むとなると「同じことの繰り返しではないか」と感じる方もいるかもしれませんが、プロダクトが成長すればフェーズも変わりますし、取り組むことにも変化が生じていくので成長や変化を楽しめる人には合っているのではないかと思います。 さいごに 新体制で CTO 2 人にメドレーの開発組織について色々と語ってもらいました。 2 人も話をしていましたが、メドレーでは長期思考・未来志向の考え方をベースに、ユーザーの本質的な課題はなにか、どうすればそれらを解決できるか?という部分にフォーカスを当てて開発をするという志向がとても強いと思います。 そうした環境でじっくりと確実にユーザーに価値を提供できるという仕事だと思いますので、ご興味を持たれた方はぜひカジュアルにお話をさせていただければと思います! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。技術広報・エンジニアの平木です。 既に 2 月に 発表 されていますが、4 月より弊社の経営体制を大幅に変更しました。開発組織について大きく変わった部分として CTO 2 名体制になった点があります。そこで、なぜ CTO を 2 名にしたのかや、これからのメドレーの開発組織についてを CTO になった 2 人にインタビューしました。 インタビュイー紹介 稲本さん 執行役員。人材プラットフォーム(以下、人材 PF)CTO。独立系 SIer でのインフラエンジニアに始まり、インターネット企業での様々なサービスのインフラ構築を経て、音楽配信サービスやインターネットラジオサービスのサーバサイドエンジニアとして従事。2014 年メドレー入社後は創業時から運営しているジョブメドレーのプロダクト開発に従事。その後、同サービスのリードエンジニア、開発責任者を経て、2023 年 4 月より現職。 田中さん 執行役員。医療プラットフォーム(以下、医療 PF)CTO。独立系 SIer でのアプリケーションエンジニアや IT コンサルタントを経て、株式会社サイバーエージェントでサーバサイドエンジニアとしてソーシャルゲームや動画サービスなどの開発立ち上げに従事。2016 年メドレー入社後は CLINICS カルテの立ち上げを経験。その後 CLINICS 開発責任者を経て医療 PF プロダクト横断基盤の立ち上げ・開発責任者を経て 2023 年 4 月より現職。 左から田中さん、稲本さん CTO を 2 名体制にして開発組織の体制をアップデートした理由 平木 : さっそくですが、2023 年 4 月よりお二人がそれぞれ人材 PF と医療 PF の CTO に就任されて、改めて開発組織のアップデートがされましたが、どういった背景でこの体制になったんでしょうか。 田中 : 会社全体の組織設計として医療 PF と人材 PF に分かれたというのがまず最初にあったんですが、当初、開発組織は両 PF を横断する形で 1 人の CTO が見ていました。各 PF 内にそれぞれプロダクトがあり開発もプロダクトごとにチームを分けていましたが、それぞれの開発チームが有機的に動きつつも組織全体の小回りの効きやすさなども考えて、こうした体制になっていました。 ただ、時間が経つに連れ段々と開発チームも各 PF 自体 の規模も大きくなってきたので、 1 人の CTO ではマネジメントが難しくなってきました。また医療 PF と人材 PF で共通する開発組織の文化などはありますが、扱っている事業内容の差異から選定技術やプロジェクトの進め方などの違う部分も出てきたので、それぞれの PF で CTO を置いて組織面・技術面の課題に対応しようということになったためです。 稲本 : 開発組織の人数としては 100 名を越えているのですが、それだけではなく就業場所の違いやサービスの多様化など、それぞれの PF で特性が違う課題がこれから先も出てくるだろうということで、先を見据えての開発組織のアップデートの一環として CTO 2 名体制にしたというところですね。 平木 : これからの組織の変化を見据えた動きだということですね。 新しい開発体制になって変わっていく部分・変わらない部分 平木 : 新体制になってまだ日が浅いですが、これから変えていく部分というのはどういったところになっていくんでしょうか。 稲本 : 自分達 2 人が持っている色々な役割を分解していって他のメンバーへ役割を委譲していくことですね。CTO が色々持ちすぎると組織のスケールに対しボトルネックになることは目に見えているので。 それ以外には、役割を担ったチームやメンバーが自身で思考し行動しやすい組織にしていくことで、更なるチャレンジがしやすかったりパフォーマンスを発揮しやすい状態にしていけたらと考えています。 平木 : なるほど。田中さんは何かありますか。 田中 : 「役割の明確化」もその 1 つですが、将来取り組むべき課題に向けて中長期を見据えた開発組織の設計や運営に向き合うフェイズになってきたと感じており、強化していきたいと考えています。 平木 : 将来の課題に対して技術・組織なども先手を打っていくイメージですね。 新体制での開発組織のミッション 平木 : それでは新体制になって改めて開発組織のミッションとしてはどういったものがありますか。 田中 : 会社全体のミッションと基本は一緒ではあります。「医療」という大きい領域の課題に対して、何のために開発をするのかや、その開発をすることによってどういった顧客価値を提供できるのかというところは、ちゃんとミッションに紐付いている部分なので変えずにいきます。 その上で、有効な施策をどれだけ素早くデリバリーできるかというところには今以上に注力していきたいところです。そのためには無駄を省き、やるべき事に集中してより生産性の高い開発を目指します。 プロダクト開発において無駄な機能開発を行なうと、後からそこを削ろうと思っても難しいですし、作った結果誰も幸せにならないということになってしまいます。こうならないためにもスピード感は落とさないで、事業側メンバーと協力しながら適切な要件整理をしたりなど、どうやって顧客へ適切なプロダクトを届けるか?という部分により重きを置いていきたいです。 事業とプロダクト開発の関係性 平木 : さて、次に先程のお話にも出てきましたが、事業とプロダクト開発の関係性についてお聞きします。お二人が考えるこの関係性はどのようなものでしょうか。 田中 : ここも以前から変わらないスタンスですが、改めて定義するなら「テクノロジーを最大限に使って医療領域の課題を解決する」という関係になります。テクノロジーとメドレーの事業である医療領域の課題解決という 2 つの側面のどれが欠けても、プロダクトとして良いものは生まれないと考えています。 平木 : 主に Web のテクノロジーを適材適所で課題解決のために使っていくというスタンスですね。 田中 : そうですね。先に来るのはあくまでも、「医療領域の課題解決をする」という部分になるのですが、その手段として必要な技術は全部使っていこうという姿勢です。なので、まずは開発組織のメンバー一人ひとりが、ドメインの理解をするということが始めの一歩です。そうして課題の本質を見極めて解決に必要な手段は何があるのかを考えていく必要が出てきます。 解決のために最適であれば、その技術の新旧や使用実績などを問わず取り入れて開発していくという心構えですね。そのためにはきちんと技術動向を追っていき日頃からユースケースなどを想像しながら、その技術を触ったりする必要も出てきます。 稲本 : ドメイン知識とテクノロジーを最大限に駆使し、プロダクト開発を通して価値を届けるというのが我々のミッションなのかなと思います。 稲本さん 平木 : 医療領域の未来を変えていくために、技術を最大限に用いたプロダクトドリブンであることが大切ということですね。 田中 : メドレーではそれだけじゃない部分も意識していますね。一言で「プロダクト」と言ってもサービスとそれを作る開発者というだけではなく、顧客接点を持つ事業部などのメンバー全ての動きも合わせて「プロダクト」という意識を持っています。 平木 : なるほど、プロダクトに関わっている人全員を合わせて「プロダクト」だよということですか。 田中 : 例えば開発メンバーが良いプロダクトを提供したとしても、そのプロダクトを使ったユーザーが疑問に思った部分があったとします。そこで問い合わせをしたときに、その体験が良くない場合はやっぱり「プロダクトに関する体験が良くない」という印象になってしまいますよね。これはセールスなど他の領域でも起き得る話ですが、メドレーではそういった部分も含めて「プロダクト開発」という意識を持っているので、他部署だからということではなくトータルでユーザーに価値を感じてもらえるようにしていくということを大切にしています。 平木 : 確かにユーザーはそういった関わるもの全部一緒に「プロダクト」と思いますもんね。 稲本 : 日々の業務の中で直接ユーザーと対話してくれている方々がたくさんいます。 Our Essentials (以下、OE)で特に好きなものの一つで「信頼を獲得する」というものがあります。OE 自体は主に社内向けのメッセージにはなるんですが、日々の業務の中で他者からの信頼を得ることが出来るような振る舞いや成果を出すこと、その信頼の積み重ねがプロダクト全体にも反映され、結果としてユーザーからも信頼される/価値を感じてもらえるプロダクトの提供につながっているのだと感じています。 プロダクトと技術の関係について 平木 : もう少し開発についての話を掘り下げていこうと思います。弊社では現在のところ Ruby や Ruby on Rails(以下 Rails)で作られているプロダクトが大半ではありますが、Go や Node.js などをメインに使っているプロダクトもありますよね。そうした技術選定のときの基本姿勢としてはどういったものがありますか。 田中 : 基本として、「それぞれのプロダクトにとって現時点でこの技術で開発するのが、良いことだよね」というのを大切にしています。組織的に知見が多いということもあって、Rails を使っているプロダクトが多いのはそうなんですが、この技術じゃないとダメという縛りがあるわけではないです。Go や Node.js にしても、そのプロダクトに現状最適だという視点で技術選定をしています。 稲本 : 今までできなかったことが、新しい技術を使ったら解決するのにという場面も結構あると思います。そういうときに「今使ってないから…」というのではなく、その技術を使ったほうがプロダクトにプラスになると判断したら使っていくようにしています。 田中 : ですので、今プロダクトで使っている技術で守っていくというより、個々人でアンテナを張って新しい技術は積極的にキャッチアップしていきながら、チーム内で「これ使うと良さそうだからやっていこう」という感じですね。 平木 : 先程も出てきたユーザーに価値提供を素早くするという要素の一つということですね。そうすると、例えば開発者体験を良くするような技術やフローなんかを取り入れるというのも、そうした志向の一部ということになりますか? 田中 : そうですね。良いものを早くユーザーに届けるという一側面になります。開発者体験を良くするというのが最終的な目的ではなくて、その結果としてチームの生産性が上がるのなら体験を良くすると良いよねという。プロダクトコードの負債解消とかもそうですが、バランスが確かに難しいのですが、こういったところを疎かにすると結果として顧客への十分な価値提供ができなくなってしまうリスクもあるので、短期と中長期できちんとバランシングしつつ開発に取り組んでいきたいと思っています。 田中さん 平木 : 改めてここで現在の開発体制について伺っていければと思います。 田中 : 人材 PF も医療 PF もプロダクトに紐付いて複数のチームに分かれていて、チームの人数規模としてみると多少の上下はあるんですが、プロダクトマネージャ(以下、PdM) やデザイナー、エンジニアを合わせて 10 人前後というチームが多いです。 平木 : そうしたチーム内で、特にエンジニアはどのような役割分担をしていることが多いですか? 稲本 : もちろんチームによっても違ってくるんですが、チームの中に PM と TL を置いて、そのチームの中にメンバーが数人いる形が多いですね。この単位をベースにして toC 向けのプロジェクト、toB 向けのプロジェクトのような感じでチームを分けて開発を行なっています。 田中 : メンバー個々人はサーバサイドやフロントエンド、インフラのような得意領域がありそこを考慮した開発をしていっていますが、サーバサイドだけやる人という形ではなく、得意領域と隣り合う領域についても意識し、可能な限り理解してコラボレーションしていこうというやり方を取っています。これによりコミュニケーションコストが下がることで生産性高く、品質向上にも寄与するというのが理由になります。 もちろんプロとして自分の得意分野で力を存分に発揮はしてもらうというのは大前提ですが、その強みを周囲のメンバーに還元しつつ、得意領域以外はそこが得意なメンバーから還元してもらいながら、良いプロダクトを作っていくというのがメドレーの開発組織のスタンスになります。 開発組織の雰囲気やメンバーの働き方について 平木 : 今まで開発組織の制度的な側面を中心に聞いてきましたが、組織のソフト面についてお聞きします。メドレーの開発組織の雰囲気ですが、どんな雰囲気だったりしますか? 稲本 : 全体的にはわりと和やかな雰囲気は持ちつつも、各自のバリューに対してはストイックな感じかなと思います。 自分たちで決めた期日など守るところはしっかり守ろうという意識を持ちつつ、無理な期日になりそうであればスケジュールやスコープを調整したり、プロジェクトの進め方で上手く行ったこと/行かなかったことを振り返りを通して改善を図ったりするなど、当たり前のことを高い水準でやり遂げていく習慣が根付いていると思います。 コミュニケーションに関しては、非同期コミュニケーションがベースではあります。口頭での相談なんかももちろんしますが、認識がずれないように話したことを issue などに残したりしてます。 雑談みたいなものはミーティングの後半パートにあえて雑談パートを作るなどしていますが、業務中にずっとするようなことはないですね。開発中はそれぞれが集中していることが多いです。 田中 : チームごとに違いますが、朝会や夕会などでちゃんとコミュニケーションが取れるようにしているということが多いですね。なので、あんまり他の時間に雑談みたいなものが必要ないという感じです。 平木 : 和やかながらも、締めるところは締めるという雰囲気ですね。開発チームの皆さんはどんな働き方をしている人が多いですか? 稲本 : これも個々人で違っていますが出社とリモートのハイブリッドな方が多いかと思います。 やはり開発に集中したい場面ではリモートの方が割り込みも少なくなりやすく集中しやすいですし、物事の認識を揃えたり決めていく場合は、ミーティングなどで実際に顔を合わせた方が効率も良いことはあると思いますね。 田中 : 自分のバリューを最大化できるように働いていこうというのが基本になっています。 平木 : 各自ちゃんと考えてプロダクトに貢献できるようにということですね。そうした働き方の先にキャリアパスがあると思いますが、その観点ではどのようなパスがありますか? 田中 : 大きく分けては、マネジメントをメインにするか、テクニカル部分を特化させたスペシャリストとなるかという 2 つになります。役割分担にもちょっと関わりますが、内容としては、例えば PdM を目指していくというのも道としてはありますし、自分の得意領域を最大限に伸ばしてテックリードとして技術をもってプロダクトを引っぱっていくという道なんかもあります。1on1 や評価などでそうした部分は本人と刷り合わせをしていきながら決めていく形になります。 平木 : 評価のお話が出てきましたが、どういった観点で評価されますか? 稲本 : ベースとしては会社として決めた OE に沿ったものになります。OE を踏まえつつ、業務目標や技術的な目標を立ててそれができたかどうかが基準になりますね。 立てた目標が色々な理由で達成できなかったというケースももちろん出てくると思いますが、内容として自分はどういった部分は頑張ったとか、どういう理由で達成できなかったなどの自分なりの説明ができるかというのを重視しています。 田中 : 目標はチームバリューにいかに寄与したかを重視しています。OE に基づきチームとして達成しないといけない目標があってそれをブレイクダウンした上で、自分が寄与できるのはどこかという感じで目標にしてもらいます。一見目に見えにくい動きだったとしても、ちゃんとチームに貢献しているねとなれば、もちろん評価の対象になりますし、逆に例えばいくら頑張って新技術を習得したとなってもチームに貢献してなければ評価はされにくいです。 平木 : ありがとうございます。最後にメドレーで開発することの良さを教えてもらえればと思います。 田中 : メドレーは長期を見据えて課題に取り組んでいる会社であり、泥臭く地道に積み重ねなければいけないこともすごく多いです。そのため短期で結果が見えづらいこともあるかもしれません。ですが、医療領域でどっしりと腰を据えて長期的に本質を捉えた開発をしているため、技術面だけではなくプロダクトデザインとして何のために、どのようなアプローチが適切か、という思考力や設計能力も身に付きやすいのではないかと思います。 稲本 : 長期で課題に取り組むとなると「同じことの繰り返しではないか」と感じる方もいるかもしれませんが、プロダクトが成長すればフェーズも変わりますし、取り組むことにも変化が生じていくので成長や変化を楽しめる人には合っているのではないかと思います。 さいごに 新体制で CTO 2 人にメドレーの開発組織について色々と語ってもらいました。 2 人も話をしていましたが、メドレーでは長期思考・未来志向の考え方をベースに、ユーザーの本質的な課題はなにか、どうすればそれらを解決できるか?という部分にフォーカスを当てて開発をするという志向がとても強いと思います。 そうした環境でじっくりと確実にユーザーに価値を提供できるという仕事だと思いますので、ご興味を持たれた方はぜひカジュアルにお話をさせていただければと思います! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。技術広報・エンジニアの平木です。 既に 2 月に 発表 されていますが、4 月より弊社の経営体制を大幅に変更しました。開発組織について大きく変わった部分として CTO 2 名体制になった点があります。そこで、なぜ CTO を 2 名にしたのかや、これからのメドレーの開発組織についてを CTO になった 2 人にインタビューしました。 インタビュイー紹介 稲本さん 執行役員。人材プラットフォーム(以下、人材 PF)CTO。独立系 SIer でのインフラエンジニアに始まり、インターネット企業での様々なサービスのインフラ構築を経て、音楽配信サービスやインターネットラジオサービスのサーバサイドエンジニアとして従事。2014 年メドレー入社後は創業時から運営しているジョブメドレーのプロダクト開発に従事。その後、同サービスのリードエンジニア、開発責任者を経て、2023 年 4 月より現職。 田中さん 執行役員。医療プラットフォーム(以下、医療 PF)CTO。独立系 SIer でのアプリケーションエンジニアや IT コンサルタントを経て、株式会社サイバーエージェントでサーバサイドエンジニアとしてソーシャルゲームや動画サービスなどの開発立ち上げに従事。2016 年メドレー入社後は CLINICS カルテの立ち上げを経験。その後 CLINICS 開発責任者を経て医療 PF プロダクト横断基盤の立ち上げ・開発責任者を経て 2023 年 4 月より現職。 左から田中さん、稲本さん CTO を 2 名体制にして開発組織の体制をアップデートした理由 平木 : さっそくですが、2023 年 4 月よりお二人がそれぞれ人材 PF と医療 PF の CTO に就任されて、改めて開発組織のアップデートがされましたが、どういった背景でこの体制になったんでしょうか。 田中 : 会社全体の組織設計として医療 PF と人材 PF に分かれたというのがまず最初にあったんですが、当初、開発組織は両 PF を横断する形で 1 人の CTO が見ていました。各 PF 内にそれぞれプロダクトがあり開発もプロダクトごとにチームを分けていましたが、それぞれの開発チームが有機的に動きつつも組織全体の小回りの効きやすさなども考えて、こうした体制になっていました。 ただ、時間が経つに連れ段々と開発チームも各 PF 自体 の規模も大きくなってきたので、 1 人の CTO ではマネジメントが難しくなってきました。また医療 PF と人材 PF で共通する開発組織の文化などはありますが、扱っている事業内容の差異から選定技術やプロジェクトの進め方などの違う部分も出てきたので、それぞれの PF で CTO を置いて組織面・技術面の課題に対応しようということになったためです。 稲本 : 開発組織の人数としては 100 名を越えているのですが、それだけではなく就業場所の違いやサービスの多様化など、それぞれの PF で特性が違う課題がこれから先も出てくるだろうということで、先を見据えての開発組織のアップデートの一環として CTO 2 名体制にしたというところですね。 平木 : これからの組織の変化を見据えた動きだということですね。 新しい開発体制になって変わっていく部分・変わらない部分 平木 : 新体制になってまだ日が浅いですが、これから変えていく部分というのはどういったところになっていくんでしょうか。 稲本 : 自分達 2 人が持っている色々な役割を分解していって他のメンバーへ役割を委譲していくことですね。CTO が色々持ちすぎると組織のスケールに対しボトルネックになることは目に見えているので。 それ以外には、役割を担ったチームやメンバーが自身で思考し行動しやすい組織にしていくことで、更なるチャレンジがしやすかったりパフォーマンスを発揮しやすい状態にしていけたらと考えています。 平木 : なるほど。田中さんは何かありますか。 田中 : 「役割の明確化」もその 1 つですが、将来取り組むべき課題に向けて中長期を見据えた開発組織の設計や運営に向き合うフェイズになってきたと感じており、強化していきたいと考えています。 平木 : 将来の課題に対して技術・組織なども先手を打っていくイメージですね。 新体制での開発組織のミッション 平木 : それでは新体制になって改めて開発組織のミッションとしてはどういったものがありますか。 田中 : 会社全体のミッションと基本は一緒ではあります。「医療」という大きい領域の課題に対して、何のために開発をするのかや、その開発をすることによってどういった顧客価値を提供できるのかというところは、ちゃんとミッションに紐付いている部分なので変えずにいきます。 その上で、有効な施策をどれだけ素早くデリバリーできるかというところには今以上に注力していきたいところです。そのためには無駄を省き、やるべき事に集中してより生産性の高い開発を目指します。 プロダクト開発において無駄な機能開発を行なうと、後からそこを削ろうと思っても難しいですし、作った結果誰も幸せにならないということになってしまいます。こうならないためにもスピード感は落とさないで、事業側メンバーと協力しながら適切な要件整理をしたりなど、どうやって顧客へ適切なプロダクトを届けるか?という部分により重きを置いていきたいです。 事業とプロダクト開発の関係性 平木 : さて、次に先程のお話にも出てきましたが、事業とプロダクト開発の関係性についてお聞きします。お二人が考えるこの関係性はどのようなものでしょうか。 田中 : ここも以前から変わらないスタンスですが、改めて定義するなら「テクノロジーを最大限に使って医療領域の課題を解決する」という関係になります。テクノロジーとメドレーの事業である医療領域の課題解決という 2 つの側面のどれが欠けても、プロダクトとして良いものは生まれないと考えています。 平木 : 主に Web のテクノロジーを適材適所で課題解決のために使っていくというスタンスですね。 田中 : そうですね。先に来るのはあくまでも、「医療領域の課題解決をする」という部分になるのですが、その手段として必要な技術は全部使っていこうという姿勢です。なので、まずは開発組織のメンバー一人ひとりが、ドメインの理解をするということが始めの一歩です。そうして課題の本質を見極めて解決に必要な手段は何があるのかを考えていく必要が出てきます。 解決のために最適であれば、その技術の新旧や使用実績などを問わず取り入れて開発していくという心構えですね。そのためにはきちんと技術動向を追っていき日頃からユースケースなどを想像しながら、その技術を触ったりする必要も出てきます。 稲本 : ドメイン知識とテクノロジーを最大限に駆使し、プロダクト開発を通して価値を届けるというのが我々のミッションなのかなと思います。 稲本さん 平木 : 医療領域の未来を変えていくために、技術を最大限に用いたプロダクトドリブンであることが大切ということですね。 田中 : メドレーではそれだけじゃない部分も意識していますね。一言で「プロダクト」と言ってもサービスとそれを作る開発者というだけではなく、顧客接点を持つ事業部などのメンバー全ての動きも合わせて「プロダクト」という意識を持っています。 平木 : なるほど、プロダクトに関わっている人全員を合わせて「プロダクト」だよということですか。 田中 : 例えば開発メンバーが良いプロダクトを提供したとしても、そのプロダクトを使ったユーザーが疑問に思った部分があったとします。そこで問い合わせをしたときに、その体験が良くない場合はやっぱり「プロダクトに関する体験が良くない」という印象になってしまいますよね。これはセールスなど他の領域でも起き得る話ですが、メドレーではそういった部分も含めて「プロダクト開発」という意識を持っているので、他部署だからということではなくトータルでユーザーに価値を感じてもらえるようにしていくということを大切にしています。 平木 : 確かにユーザーはそういった関わるもの全部一緒に「プロダクト」と思いますもんね。 稲本 : 日々の業務の中で直接ユーザーと対話してくれている方々がたくさんいます。 Our Essentials (以下、OE)で特に好きなものの一つで「信頼を獲得する」というものがあります。OE 自体は主に社内向けのメッセージにはなるんですが、日々の業務の中で他者からの信頼を得ることが出来るような振る舞いや成果を出すこと、その信頼の積み重ねがプロダクト全体にも反映され、結果としてユーザーからも信頼される/価値を感じてもらえるプロダクトの提供につながっているのだと感じています。 プロダクトと技術の関係について 平木 : もう少し開発についての話を掘り下げていこうと思います。弊社では現在のところ Ruby や Ruby on Rails(以下 Rails)で作られているプロダクトが大半ではありますが、Go や Node.js などをメインに使っているプロダクトもありますよね。そうした技術選定のときの基本姿勢としてはどういったものがありますか。 田中 : 基本として、「それぞれのプロダクトにとって現時点でこの技術で開発するのが、良いことだよね」というのを大切にしています。組織的に知見が多いということもあって、Rails を使っているプロダクトが多いのはそうなんですが、この技術じゃないとダメという縛りがあるわけではないです。Go や Node.js にしても、そのプロダクトに現状最適だという視点で技術選定をしています。 稲本 : 今までできなかったことが、新しい技術を使ったら解決するのにという場面も結構あると思います。そういうときに「今使ってないから…」というのではなく、その技術を使ったほうがプロダクトにプラスになると判断したら使っていくようにしています。 田中 : ですので、今プロダクトで使っている技術で守っていくというより、個々人でアンテナを張って新しい技術は積極的にキャッチアップしていきながら、チーム内で「これ使うと良さそうだからやっていこう」という感じですね。 平木 : 先程も出てきたユーザーに価値提供を素早くするという要素の一つということですね。そうすると、例えば開発者体験を良くするような技術やフローなんかを取り入れるというのも、そうした志向の一部ということになりますか? 田中 : そうですね。良いものを早くユーザーに届けるという一側面になります。開発者体験を良くするというのが最終的な目的ではなくて、その結果としてチームの生産性が上がるのなら体験を良くすると良いよねという。プロダクトコードの負債解消とかもそうですが、バランスが確かに難しいのですが、こういったところを疎かにすると結果として顧客への十分な価値提供ができなくなってしまうリスクもあるので、短期と中長期できちんとバランシングしつつ開発に取り組んでいきたいと思っています。 田中さん 平木 : 改めてここで現在の開発体制について伺っていければと思います。 田中 : 人材 PF も医療 PF もプロダクトに紐付いて複数のチームに分かれていて、チームの人数規模としてみると多少の上下はあるんですが、プロダクトマネージャ(以下、PdM) やデザイナー、エンジニアを合わせて 10 人前後というチームが多いです。 平木 : そうしたチーム内で、特にエンジニアはどのような役割分担をしていることが多いですか? 稲本 : もちろんチームによっても違ってくるんですが、チームの中に PM と TL を置いて、そのチームの中にメンバーが数人いる形が多いですね。この単位をベースにして toC 向けのプロジェクト、toB 向けのプロジェクトのような感じでチームを分けて開発を行なっています。 田中 : メンバー個々人はサーバサイドやフロントエンド、インフラのような得意領域がありそこを考慮した開発をしていっていますが、サーバサイドだけやる人という形ではなく、得意領域と隣り合う領域についても意識し、可能な限り理解してコラボレーションしていこうというやり方を取っています。これによりコミュニケーションコストが下がることで生産性高く、品質向上にも寄与するというのが理由になります。 もちろんプロとして自分の得意分野で力を存分に発揮はしてもらうというのは大前提ですが、その強みを周囲のメンバーに還元しつつ、得意領域以外はそこが得意なメンバーから還元してもらいながら、良いプロダクトを作っていくというのがメドレーの開発組織のスタンスになります。 開発組織の雰囲気やメンバーの働き方について 平木 : 今まで開発組織の制度的な側面を中心に聞いてきましたが、組織のソフト面についてお聞きします。メドレーの開発組織の雰囲気ですが、どんな雰囲気だったりしますか? 稲本 : 全体的にはわりと和やかな雰囲気は持ちつつも、各自のバリューに対してはストイックな感じかなと思います。 自分たちで決めた期日など守るところはしっかり守ろうという意識を持ちつつ、無理な期日になりそうであればスケジュールやスコープを調整したり、プロジェクトの進め方で上手く行ったこと/行かなかったことを振り返りを通して改善を図ったりするなど、当たり前のことを高い水準でやり遂げていく習慣が根付いていると思います。 コミュニケーションに関しては、非同期コミュニケーションがベースではあります。口頭での相談なんかももちろんしますが、認識がずれないように話したことを issue などに残したりしてます。 雑談みたいなものはミーティングの後半パートにあえて雑談パートを作るなどしていますが、業務中にずっとするようなことはないですね。開発中はそれぞれが集中していることが多いです。 田中 : チームごとに違いますが、朝会や夕会などでちゃんとコミュニケーションが取れるようにしているということが多いですね。なので、あんまり他の時間に雑談みたいなものが必要ないという感じです。 平木 : 和やかながらも、締めるところは締めるという雰囲気ですね。開発チームの皆さんはどんな働き方をしている人が多いですか? 稲本 : これも個々人で違っていますが出社とリモートのハイブリッドな方が多いかと思います。 やはり開発に集中したい場面ではリモートの方が割り込みも少なくなりやすく集中しやすいですし、物事の認識を揃えたり決めていく場合は、ミーティングなどで実際に顔を合わせた方が効率も良いことはあると思いますね。 田中 : 自分のバリューを最大化できるように働いていこうというのが基本になっています。 平木 : 各自ちゃんと考えてプロダクトに貢献できるようにということですね。そうした働き方の先にキャリアパスがあると思いますが、その観点ではどのようなパスがありますか? 田中 : 大きく分けては、マネジメントをメインにするか、テクニカル部分を特化させたスペシャリストとなるかという 2 つになります。役割分担にもちょっと関わりますが、内容としては、例えば PdM を目指していくというのも道としてはありますし、自分の得意領域を最大限に伸ばしてテックリードとして技術をもってプロダクトを引っぱっていくという道なんかもあります。1on1 や評価などでそうした部分は本人と刷り合わせをしていきながら決めていく形になります。 平木 : 評価のお話が出てきましたが、どういった観点で評価されますか? 稲本 : ベースとしては会社として決めた OE に沿ったものになります。OE を踏まえつつ、業務目標や技術的な目標を立ててそれができたかどうかが基準になりますね。 立てた目標が色々な理由で達成できなかったというケースももちろん出てくると思いますが、内容として自分はどういった部分は頑張ったとか、どういう理由で達成できなかったなどの自分なりの説明ができるかというのを重視しています。 田中 : 目標はチームバリューにいかに寄与したかを重視しています。OE に基づきチームとして達成しないといけない目標があってそれをブレイクダウンした上で、自分が寄与できるのはどこかという感じで目標にしてもらいます。一見目に見えにくい動きだったとしても、ちゃんとチームに貢献しているねとなれば、もちろん評価の対象になりますし、逆に例えばいくら頑張って新技術を習得したとなってもチームに貢献してなければ評価はされにくいです。 平木 : ありがとうございます。最後にメドレーで開発することの良さを教えてもらえればと思います。 田中 : メドレーは長期を見据えて課題に取り組んでいる会社であり、泥臭く地道に積み重ねなければいけないこともすごく多いです。そのため短期で結果が見えづらいこともあるかもしれません。ですが、医療領域でどっしりと腰を据えて長期的に本質を捉えた開発をしているため、技術面だけではなくプロダクトデザインとして何のために、どのようなアプローチが適切か、という思考力や設計能力も身に付きやすいのではないかと思います。 稲本 : 長期で課題に取り組むとなると「同じことの繰り返しではないか」と感じる方もいるかもしれませんが、プロダクトが成長すればフェーズも変わりますし、取り組むことにも変化が生じていくので成長や変化を楽しめる人には合っているのではないかと思います。 さいごに 新体制で CTO 2 人にメドレーの開発組織について色々と語ってもらいました。 2 人も話をしていましたが、メドレーでは長期思考・未来志向の考え方をベースに、ユーザーの本質的な課題はなにか、どうすればそれらを解決できるか?という部分にフォーカスを当てて開発をするという志向がとても強いと思います。 そうした環境でじっくりと確実にユーザーに価値を提供できるという仕事だと思いますので、ご興味を持たれた方はぜひカジュアルにお話をさせていただければと思います! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp