こんにちは。医療プラットフォーム本部プロダクト開発室エンジニアの中畑です。主にオンライン診療・服薬指導アプリ CLINICS の開発を担当しています。 今回は CLINICS アプリ内で扱う処方箋プレビューに透かし(watermark)を入れた話を紹介したいと思います。なぜ実施したのか、実装方法、パフォーマンスチューニングの 3 本立てでお送りしたいと思います。 課題と解決方針 まず、なぜ処方箋プレビューに透かしを入れることにしたのか。 CLINICS では診察後に患者が希望すると、かかりつけ薬局支援システム Pharms を導入している調剤薬局にてオンライン服薬指導を受けることができます。その際に医療機関から処方箋の画像ファイルや PDF をアップロードし、患者は CLINICS アプリを通じて、オンライン服薬指導を受けたい調剤薬局に処方箋データを送る必要があります。 患者はオンライン服薬指導を予約する前に医療機関からアップロードされた処方箋画像をプレビューできます。この処方箋プレビューは原本とは扱いが異なるため、患者がアプリ内でそれぞれを明確に区別できるような対応を入れる必要があり、その手段として処方箋プレビューに透かしを入れることにしたというのが理由となります。 実現・実装方法 まずは画像に透かしを入れる方法を考え、それからシステム上でどのタイミングで透かしを入れるか検討しました。前提条件ですが、処方箋プレビュー画像は以下のような形で保存されています。 フォーマット: JPEG, PNG, GIF, PDF(画像以外もある) 保存場所: S3 画像に透かしを入れる方法 透かしは技術的には 2 枚の画像をアルファブレンド 1 を使って合成した画像となります。 アルファブレンドの実現方法は言語やライブラリによっていろいろありますが、今回は処方箋を扱うシステムが Go を利用しているので、Go の以下の標準ライブラリを使って実装しました。また、画像には向き( orientation )の情報が保持されているのですが、向きを意識しないと合成時におかしくなることがあります。端末やツールによって取り扱いが異なる部分が多いので、それを解消してくれる disintegration/imaging パッケージを利用しました。 image パッケージ : ベースライブラリ ximage パッケージ : 描画処理 disintegration/imaging パッケージ : 読み込み時に向きを補正 詳細は省きますが、以下のようなコードで合成できます func Watermark ( srcFile string ) { // 元画像 imgb , _ := os . Open ( srcFile ) var img image . Image img , _ = imaging . Decode ( imgb , imaging . AutoOrientation ( true )) defer imgb . Close () // 上に重ねる透かし画像 wmb , _ := os . Open ( "watermark.png" ) watermark , _ , _ := image . Decode ( wmb ) defer wmb . Close () // 透かしを配置する場所 (画像サイズによって異なるため、実際は計算が必要) watermarkRect := image . Rectangle { image . Point { 100 , 100 }, image . Point { 200 , 300 }} // 合成処理（ここではバイリニア補間で実施） b := img . Bounds () m := image . NewNRGBA ( b ) draw . Draw ( m , b , img , image . ZP , draw . Src ) draw . BiLinear . Scale ( m , watermarkRect , watermark , watermark . Bounds (), draw . Over , nil ) // 合成画像の出力（JPEG 出力。他のエンコーダーを利用すれば他の画像形式も可） imgw , _ := os . Create ( "/tmp/dest.jpg" ) jpeg . Encode ( imgw , m , & jpeg . Options { Quality : jpeg . DefaultQuality }) defer imgw . Close () } PDF に透かしを入れる方法 また、今回の要件には PDF ファイルにも透かしを入れる必要がありました。PDF にはレイヤーという概念があり、元の PDF に対して透かしを入れるレイヤーを追加すれば実現できます。Go には PDF を標準で扱えるパッケージがなかったので、今回は pdfcpu を利用しました。 透かしのレイヤーを追加する関数が用意されており、以下のコードだけで実現できて大変便利です。 2 wm , _ := api . ImageWatermark ( "watermark.jpg" , "sc:.8 rel, rot:0" , onTop , update , pdfcpu . POINTS ) api . AddWatermarksFile ( "src.pdf" , "dest.pdf" , nil , wm , nil ) S3 画像に透かしを入れる方法 AWS を利用していると S3 に各種ファイルを保存することも多いと思います。 基本的には S3 画像を読み込んで透かし処理をすれば実現できますが、AWS には S3 のレスポンスを加工するマネージメントサービスがいくつかあり、今回は S3 Object Lambda を利用しました。 S3 Object Lambda を利用することで S3 からファイルを取得する際に Lambda による処理を実行したうえで返却することができます。これを利用して、元の画像に Lambda で透かしを入れて返却することができます。 処方箋プレビューに透かしを入れる前の構成は以下のようなイメージです。 アプリサーバーにて処方箋プレビューの S3 presigned URL（署名付き URL）を発行 クライアントに返す クライアントは受け取った URL にアクセス。処方箋プレビューが表示される これに S3 Object Lambda を利用して透かしを入れると以下のようになります。 アプリサーバーにて処方箋プレビューの S3 Object Lambda Access Point の presigned URL（署名付き URL）を発行 クライアントは受け取った URL にアクセス S3 Object Lambda Access Point は透かし処理を行う Lambda 関数を実行。その際に S3 Access Point の署名付き URL を発行し、リクエストパラメータに設定 Lambda Function は受け取った URL にアクセスし処方箋プレビューの元画像を取得して透かしを入れて返却 透かし入りの処方箋プレビューが表示される 新たに S3 Object Lambda Access Point , Lambda Function , S3 Access Point を用意する必要があって少しややこしいですが簡単に説明すると以下のような役割のものとなります。 icon title description S3 Access Point S3 Bucket に対する alias。S3 Object Lambda は必ずこれを経由して S3 にアクセスする必要がある Lambda Function S3 のファイルに対してなんらかの処理を実施する関数 S3 Object Lambda Access Point S3 Access Point に対して Lambda 関数を実行するためのアクセスポイント 透かし処理を実際呼び出す際は、アプリケーション側からは S3 の presigned URL から S3 Object Lambda Access Point の presigned URL に切り替えるだけなので、透かしありなしの切り替えも簡単です。 S3 presigned URL: https://[bucket-name].s3.ap-northeast-1.amazonaws.com/prescription.jpg?[signature] ↓ S3 Object Lambda Access Point presigned URL: https://[s3-object-lambda-access-point]-[account-id].s3-object-lambda.ap-northeast-1.amazonaws.com/prescription.jpg?[signature] S3 Object Lambda を利用することで以下のようなメリットがあります。 追加のインフラ構築が不要 既存サーバーのリソース追加や、新たに透かし処理用のサーバーを用意する必要がない。既存のアプリサーバーへの影響を軽微にできる Lambda が自動的にスケールを実施してくれるので負荷対策が容易 利用した分だけの課金となる（S3 Get + Lambda + S3 Object Lambda の利用料） 透かしを入れた処方箋プレビュー画像を事前に用意する必要がない 事前に用意するとリリース前に保持した画像に対しても処理する必要が出てくる (ただし、今回は特定のユーザーのみのアクセスなので不特定多数のアクセスが見込まれる場合は事前生成したほうがよいかもしれません) もちろん画像だけではなく、テキストデータなど他のものにも利用できるので、S3 に保管した機密情報等をフィルタリングして返したい用途などにもマッチします。 AWS 公式ドキュメントに詳細な解説と様々なユースケースのチュートリアルがありますので、興味がある方は是非御覧ください。 S3 Object Lambda を使用したオブジェクトの変換 パフォーマンス・チューニング ここまでで、処方箋プレビューに透かしを入れる処理自体は完成しました。ここで気になってくるのがパフォーマンスについてです。今までは S3 の画像を表示するだけでしたが透かし処理に S3 Object Lambda を使うことになったため、速度と料金が気になるところです。 様々なチューニングポイントがありますが、今回は Lambda のメモリ設定に焦点を絞ってお話したいと思います。 Lambda の CPU パフォーマンス Lambda はメモリ設定しかできませんが、メモリ量に比例して CPU 性能が向上する仕組みとなっています。 公式ドキュメント 上では 1769MB あたり 1vCPU であるとされていて、MAX の 10240MB で 6vCPU 使えるとしています。実際に Lambda の vCPU の設定を調べたブログ ( SENTIA tech blog ) では以下のようになっていたそうです。 Memory vCPUs 128 - 3008 MB 2 3009 - 5307 MB 3 5308 - 7076 MB 4 7077 - 8845 MB 5 8846 - 10240 MB 6 ただし、メモリをいくら増やしたところで関数自体がマルチスレッド・マルチプロセス化されていない場合はパフォーマンス向上が見込めないということにもなります。適切に並列処理が実装されていれば、vCPU が増える境目で大きな性能向上が期待できます。 Lambda の料金 東京リージョン(ap-northeast-1)において、2022 年 10 月現在は以下のような料金となります。 3 無料枠: 1 ヶ月あたり 100 万リクエスト、40 万 GB-秒(仮に 1 GB で動かしたとして 40 万秒使える) 128 MB だと 320 万秒、 10240 MB だと 4 万秒 有料枠: 100 万リクエストあたり 0.20 USD, GB-秒あたり 0.00001666667 USD 1 億リクエストあたり 20 USD 128MB で 1 万秒 使うと 0.02083 USD 1024MB で 1 万秒 使うと 0.16666 USD 上記は x86(amd64) の値段、arm だと 2 割引 arm は CPU パフォーマンスも 2 割向上すると言われているので、可能であれば arm を選択すると更にコスパ向上が期待できる このように見てみると、サーバーやコンテナを利用した場合はどんなに最小構成でも冗長化を考えると数十ドルはかかるので、特に頻繁に実行されない機能は Lambda によるサーバーレス化を検討すると良さそうです。 また、時間あたりで料金がかかるということは、API などネットワークアクセスで時間を使った場合も料金がかかることに注意が必要です。外部 API のパフォーマンスに依存してしまうので、なるべく Lambda は CPU を使った処理が支配的になるとコスパよく利用することができます。 ベンチマーク Lambda のパフォーマンス計測には、 AWS Lambda Power Tuning を利用しました。AWS Lambda Power Tuning は Step Functions と Lambda を使って Lambda の速度とコストを計測できるツールです。 Step Functions と Lambda をデプロイした上で、Step Functions の state machine に計測したい Lambda の ARN, memory 設定, 実行回数, payload を入力することでベンチマーク結果を取得できます。 実行すると最終結果に URL が出力され、その URL をブラウザで表示することで、グラフで結果とスコアボードで結果が可視化されます。また 2 つの結果を比較して表示することもできますので改善後に比較することも容易です。 4 AWS Lambda Power Tuning の導入 リポジトリのドキュメント に従い導入していきます。 今回は AWS Serverless Application Repository(SAR) を使って導入しました。AWS Serverless Application Repository(SAR) とはその名の通り、サーバーレスアプリケーションを管理するリポジトリですが、組織内に限らず公開することも可能で、他の人も再利用可能になっています。また、導入する際は公開ページの Deploy ボタンをポチるだけで自身の AWS アカウント上にデプロイされ、 CloudFormation の Stack として管理されます。削除も CloudFormation の Stack を削除するだけで実施できます。 AWS Lambda Power Tuning は こちらから 自身のアカウントにデプロイできます。 また、AWS や個人だけでなく Datadog や New Relic など他のパブリッシャーもサーバーレスアプリケーションを公開しているので、他にも使いたいものがないか探してみるとよいかもしれません。 AWS Lambda Power Tuning の実行 デプロイが完了すると、AWS Step Functions 上に state machine があるので、state machine にパラメータを入力することで計測ができます。 リポジトリのドキュメント にいくつかやり方が記載されています。ここでは 実行パラメータを定義した json ファイルを用意してスクリプトから実行する方法を紹介します。 まずは、 AWS Lambda Power Tuning リポジトリ を git clone し、 scripts/sample-execution-input.json を編集します。 { "lambdaARN" : "arn:aws:lambda:ap-northeast-1:123456789012:function:lambda-performance-tuning" , "powerValues" : [ 128 , 256 , 512 , 832 , 1024 , 1536 , 1769 , 1770 , 2048 , 3008 ], "num" : 100 , "payload" : { "body" : "{ \" id \" : \" 123 \" , \" name \" : \" performance \" }" , "path" : "/api/performance" , "httpMethod" : "GET" , "isBase64Encoded" : false , "multiValueHeaders" : { "Accept" : [ "application/json" ] } }, "parallelInvocation" : false } 入力値の詳細は以下の通りです。 5 lambdaARN: Lambda Function の ARN powerValues: 計測したい Lambda のメモリを指定 num: メモリごとの Lambda 実行回数 payload: Lambda Function にわたす Event JSON の内容 parallelInvocation: ベンチマークを並列実行する 次に、 scripts/execute.sh を実行すると、ベンチマークが開始され、最後に結果 URL が出力されます。デプロイ時の設定によって、CloudFormation の Stack Name が違う場合もありますので、必要に応じて書き換えてください。 $ sh ./scripts/execute.sh -n Execution started... -n . : -n . SUCCEEDED Execution output: { "power" :128, "cost" :8.4E-9, "duration" :3.6706666666666674, "stateMachine" : { " executionCost ":4.0E-4," lambdaCost ":1.0178708203125003E-4," visualization ":" https://lambda-power-tuning.show/#gAAAAQACQAMABAAG6QbqBgAIwAs = ; NOxqQP9GmkDFII5AbxKBQLErfECGXW1AWDmGQNNNjkBpSo1ARf1nQA = = ; l08QMn1jtDJ9YzQz1pCSM5dPkDNjd9gzb9AbNPzmGzR9YzQ05vRTNA = ="}} 計測方法は以上、簡単ですね 👌 AWS Lambda Power Tuning の結果確認 計測結果を確認します。関数によって傾向は異なりますが、ここでは 2 種類のパターンを紹介します。 DB や API アクセスなど外部処理が支配的なケース(Network-intensive) Lambda 内の処理が外部処理で占めている場合は、 以下のようなグラフ になります。 赤色の実行時間がどのメモリ設定でも 4ms 前後と大きな変化がなく、青色のコストだけが右肩上がりになっています。 この場合は、Lambda の最低メモリである 128MB が最適ということになります。 CPU 実行時間が支配的なケース(CPU-intensive) Lambda 内の処理が内部処理で占めている場合は、 以下のようなグラフ になります。透かし処理は画像合成処理に多くの CPU を利用するので、こちらのパターンとなりました。 メモリが少ないと速度が出ておらず、メモリを増やすに連れて速度も改善しており、コストの増加も緩やかです。ただし、今回はプログラムがマルチスレッド・マルチプロセス対応はしていないため、コア数が増える 1770MB 以降は大きな速度改善は見られず、コストが上がる結果となっています。 よって、このケースではコストだけを考えたら低メモリが有利ですが、速度も考えたら 1024MB ~ 1770MB あたりにすることを検討すると良さそうです。 まとめ 処方箋プレビューに透かしを入れることになった背景、実現方法を紹介いたしました。 透かし処理はアルファブレンド処理を実施することで実現でき、PDF については透かし用のレイヤーを重ねることで実現できます。 S3 Object Lambda を利用することで、追加のサーバー構築をすることなく、S3 のファイルに対してフィルタリングをかけることができます。 Lambda のパフォーマンス・チューニングについては、AWS Lambda Power Tuning を利用して可視化できます。外部 API などネットワーク依存(Network-intensive)ではなく、CPU 処理が中心(CPU-intensive)になると、コスパよく利用することができます。 S3 のファイルに対してなんらかの処理を実施したいと考えてる方は、一度 S3 Object Lambda の利用を検討してみてはいかがでしょうか？ また、Lambda のチューニングポイントは色々ありますが、AWS Summit Online で紹介された以下のセッションがおすすめなので、もっと深くチューニングしたい方は是非ご覧ください！ AWS Lambda Performance Tuning Deep Dive〜本当に知りたいのは”ここ”だった〜 さいごに メドレーでは、医療分野の社会課題を IT にて解決するために日々邁進しております。医療という分野においては、機微な情報を扱ったり診療という大事な業務を止めないよう、可用性、パフォーマンス、セキュリティともに高いサービスレベルを求められます。興味がある方は是非ご連絡ください。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp Footnotes 元画像に直接文字や図形などを描画することももちろん可能ですが、透かしを画像データとしてデザイン、管理したいこともあり、今回はアルファブレンドを選択した。 アルファブレンド - wikipedia ↩ pdfcpu API document: watermark example ↩ ただし最初の 60 億 GB 秒/月。昨今は円安なのでドル建てで利用しているインフラコストも上がっており、USD 表記だとコストが変わらないようにみえるので要注意。 AWS Lambda 料金 ↩ この UI は AWS Lambda Power Tuning UI というツールで別途提供されており、 lambda-power-tuning.show ドメインでアクセスできるので、自前で用意する必要はない。URL は https://lambda-power-tuning.show/#AAEAAgADAAQ=;xKDwRUqaakU5+RtFcXLqRA==;UqkHOPJCBDjA6AM46DAEOA==;AAEAAgADAAQ=;aYP6RdyeeUUQKiVFuC76RA==;ZDoNOJy3DDiJrQs4zhENOA==;100;50 のような形式でデータが URL のパスパラメータにエンコードされている。 ↩ この他にも strategy など様々なパラメータがある: aws-lambda-power-tuning: README-INPUT-OUTPUT.md ↩

はじめに みなさん、こんにちは。エンジニアの新居です。クラウド診療支援システム CLINICS が 8 月から大幅に アップデート して、より患者と医療機関が密接に繋がるようになりました。 今回のアップデートで中心になっている機能領域として PRM(Patient Relationship Management) というものがあります。 この PRM が一体どういったものなのか、プロジェクトはどのように進んでいったのかを関係者にインタビューしていきました。 メドレーで大規模なプロジェクト開発をどのように行なっているかの一端をお見せできればと考えています! インタビュイー紹介 宍戸さん 医療プラットフォーム第一本部 プロダクト開発室第二グループに所属。クラウド診療支援システム CLINICS の開発責任者。前職は株式会社サイバーエージェントでサーバサイドエンジニアとして従事。2017 年メドレー入社。 酒井さん 医療プラットフォーム第一本部 プロダクト開発室第二グループに所属。クラウド診療支援システム CLINICS の UI/UX 全般を担当。本プロジェクトのリード。前職は受託開発会社で様々なサイトやシステムのデザインに従事。2019 年メドレー入社。 田中さん 医療プラットフォーム CTO。医療プラットフォームの開発統括をしながら、自身は患者統合基盤の開発を担当。前職までは SIer や IT コンサルタントを経て、株式会社サイバーエージェントでサーバサイドエンジニアとして従事。2016 年メドレー入社。 来田さん 前職まではクリニックで精神科医として従事。CLINCS オンライン診療の立ち上げ時から関わる。現在は CLINICS のディレクションを中心として事業部と開発の架け橋となっている。 PRM とはどういうものなのか? 新居 : では今回中心となった PRM とはいったい何なのかというところから解説していただいて良いですか? 一般的にはそこまで知られてない言葉なのではないかと思うのですが…。 宍戸 : 元々 CRM(Customer Relationship Management)というマーケティングなどの文脈の用語があります。これは「自社サービスや商品を使っている顧客」と「サービスや商品を提供している企業」との関係性を管理することを指しますが、それをもとに適切なアクションをおこなうことで最終的には利益向上を目指すものと考えられます。 PRM は CRM と同様に医療機関と患者さんの関係性を管理することで必要なサービスを提供する ためのもの、と考えています。 CLINICS で基幹システムである電子カルテなどではなく、 オンライン診療・予約・問診など患者接点となる機能をターゲットにしてそれらを強化・改善 していったのが、CLINICS の今回の PRM プロジェクトになります。 CLINICS 開発責任者 宍戸さん 新居 : 確かに CRM は最近良く聞く言葉でしたが、PRM は患者と医療サービスを使う医療機関との関係を深めるためのものなんですね。 PRM プロジェクトの始まり CLINICS に感じていた課題とは 新居 : このプロジェクトは半年ほどかけていると聞きましたが、「PRM をやっていこう」となったのが半年前からだったんでしょうか? 宍戸 : 元々 CLINICS はオンライン診療のシステムとして 2016 年からサービスを提供してきました。2018 年からは CLINICS カルテとして電子カルテシステムも提供を開始しましたが、そのタイミング以降はオンライン診療部分に関してはそこまで大きくアップデートはしてこなかったんです。 現在はクラウド診療支援システムとして販売していますが、これまでは電子カルテなど基幹部分の強化がメインになっていたからです。しかし、数年開発・運用してきた中で、本来医療機関の診察のメインである対面診療の予約については課題が積み残されていたり、昨今の状況から来る オンライン診療のニーズなどを始めとして、患者接点を強化していく必要がある ということになり、今回取り組むことになりました。 酒井 : PRM というと本当にここ最近の潮流なのですが、 CLINICS はもともと「患者とつながる」をコンセプト としており、今回の機能強化などもこのコンセプトに基づき実施しています。その上で、患者とのタッチポイントで抜けていた部分や強化したほうが良い部分をより作り込んでいったという形です。 例えば、CLINICS は元々オンライン診療のシステムとして始まっており、対面診療予約に関して使いづらさを感じるケースがあったため、対面診療予約をより行いやすくするよう改修を行うなどです。 CLINICS デザイナー 酒井さん 新居 : 元々あったものをさらに患者とのタッチポイントを強化するために、改修・改善していったんですね。 プロジェクトの背景 どのくらいの規模のプロジェクトだったのか 新居 : 半年のプロジェクトということですが、規模としてはどの位の大きさだったんでしょうか? 酒井 : 私が経験したプロジェクトの中でも関わる部署など考えると一番大きかったと思います。開発はもちろんですが、CLINICS チームの セールス・カスタマーサクセス・マーケティング、広報もなのでほぼ CLINICS の全部署と関わっていました 。 田中 : 他にも、サービスとしては患者統合基盤・ 患者向けアプリ・ Dentis が関係しています。 宍戸 : QA チームにもしっかり入ってもらって QA を行なったりしてもらったので、本当に 医療プラットフォームのほぼ全てのチームと関わって開発していった 感じです。最終的にプロダクトの見せ方や売り方なども含めて調整していったので事業部とも密接に関わって作り上げていきました。 新しい PRM 機能をどうやって、プロダクトに融合させたのか 新居 : そこまで大きい規模のプロジェクトだということで、PRM の各種機能をどうやって上手くプロダクトに落としこむのか、実際にはどのようにみなさん推進されていったんでしょう。 宍戸 : プロジェクトの推進という意味では、最初は来田さんや( Dentis の運営を行なっている)プロダクト戦略室の平山さんと スモールスタートで意見を出し合いながらモックを作っていき、まずはビジュアル面から機能のイメージなどを刷り合わせ ていくのに、酒井さんに手を動かしてもらいながら進めていました。 その過程でこのプロジェクトにおける重要な意思決定がありました。CLINICS ではログイン不要のシンプルな予約機能を以前より提供していました。この機能は患者アプリとは元々違うドメインで運営していたものでしたが、今回のタイミングでこの両者のアプリケーションを患者アプリと同じドメインに統合して運営していこうという決定をしました。 患者アプリは CLINICS チームとは別チームで運営しているという背景もあり、チーム間の連携が格段に増え 、考えなければいけない事柄も多くなります。プロジェクトとして関係者が多くなってきたので、 今までの考え方を 1 度リセットしてプロジェクトの進め方を新しく模索する必要がありました 。 この点がかなり自分の中では大変でした。来田さんも大変だったと思います。こうした全体像を描いたり、全体スケジュールを決めたりというところでは、田中さんにアドバイスをもらいながらプロジェクトを進めていきました。 プロジェクトを推進するために必要だったこと 難しい意思決定をどのようにしていた? 新居 : 途中から一気にプロジェクトがスケールアップしたということなんですね。今回のプロジェクトは色々な部署も関わるし、たくさんの機能や改修が入っています。開発側と事業部側との意識合わせが、かなり必要だったんではないかと思うのですが、その辺はいかがだったでしょうか。 来田 : 例えば、今まで CLINICS では対面診療予約の際に患者のクレジットカード登録を必須としていたのですが、今回の改修でクレジットカード登録を不要に変更できるように対応を行いました。この対応は、CLINICS オンライン診療の初期から念願の機能だったりします。自分は事業部長である田中大介さんと今年の年明けくらいから話をして、メンバーに「よし、このプロジェクトをやっていこう」という話を持っていくようにしていました。やっぱり、大変なプロジェクトだというのはあったのでスタートを切れる状態に徐々にしていった感じです。 プロジェクトが佳境に入ってからは自分は各部署との調整がメインの業務でした。開発側と事業側とか CLINICS と Dentis だとかそういった立場の違いから来る要求の違いを納得できる仕様に落とし込む作業です。やっぱり、それぞれの立場でベストを尽くそうとみんな考えているんですが、全部を取り入れることはできないので。私が調整するときには それぞれ反対の立場の人たちの考えをきちんと伝えるようにということをしながら、仕様を決めていく ことを念頭に置いていました。 具体的な調整の例としては、開発する機能とセールスする際のプランの刷り合わせだったりですね。「機能としてはこうしたほうが使いやすいよね」というだけだと、セールス側としては「どこをウリにして売っていくのかというのが見えてこない」という話になったんですね。これはどちらの言い分も一理あるものなんですが、こういうところを時間をかけて 双方納得行くように決めていきました 。 CLINICS ディレクター・医師 来田さん 酒井 : この例でやったことは、まず現在のプランと機能を全部書き出して、組み合わせを整理するということでした。これをベースにして話を刷り合わせていったんですが、文字ベースだと人間分かった気になるんですが、実はそこまでピンと来ない。ですので、 LP のモックを作ってこれを見た顧客が導入したくなるようなウリになっているのかをすぐに判断できる状態 にしました。 宍戸 : こうしてちゃんと機能を解いていって細かい部分も含めて、時には CLINICS のコンセプトに立ち返って事業部・開発双方で時間をかけて認識を合わせることができたのは、大変でしたが良かったですね。 リリースまでのプロセスで顧客の声を反映 新居 : やはりここまでのプロジェクトだと最初の段階でちゃんとリリースまでを見据えた意識合わせをチーム内で行なっていたんですね。開発が進行していって、リリースするまではどのようにプロジェクトは進んでいったんでしょう。 宍戸 : リリースをする直前も、単純に仕様や機能について文書で説明しても理解するのは難しいので、酒井さんにディレクションをしてもらいながら、開発環境を使って QA チームやカスタマーサポートチームと一緒に認識合わせやリリースに向けた準備を行なっていきました。 来田 : あとは関係が構築できている 顧客に実際機能を見てもらって反応を伺う ということもしていきました。色々な使い方をしている顧客 10 件くらいにモックをベースにヒアリングをかけていきました。価格や導入時期なども含めた話を聞いていって、そこをすぐにプロジェクトにフィードバックする体制を構築していました。 酒井 : 実際に顧客の声をこうして聞けるというのは本当にプロダクトにとってありがたいことでした。特にこういう使い勝手などに直接関わる部分では、こうしたフィードバックの有無で完成度が違ってきます。 機能の正式リリース前から機能評価に協力していただける医療機関がいるのは、カスタマーサポートの皆さんが顧客と良好な関係を築けているおかげ だと思っています。こういった点はメドレーの強みだと思います。 プロジェクトで大切にしたこと 新居 : 開発段階からユーザーの声を吸い上げていけるのは、本当に良いですね。プロダクトの改善スピードなんかも段違いに早くなりそうです。他に大切にしていた部分などありますか? 酒井 : 今回の機能開発においては、プロジェクトの責任者として、開発以外のメンバーともしっかりコミュニケーションし合意形成を図ることを意識してプロジェクトを推進しました。 先ほどの話にも出ましたが 1 つの機能を実装するとなっても、実際の医療現場での使い勝手や、メドレーでのサポート、売り方など色々な視点で考えないといけないプロジェクトでした。そのため、そういったところをカスタマーサクセスのメンバー含む 10 人ほどと毎週 1 つ 1 つ納得がいくように詰めていくという作業をしていったりしました。 来田さんのように現役の医師の意見、顧客の意見なども取り入れられますし、カスタマーサポートには医療事務経験者の方もいらっしゃるので、多方面の視点を総合的に取り入れられるコミュニケーション を心がけていました。 手段はテキストや Figma でのデザイン、実際の実装を見せるなど適切な手段を選んでコミュニケーションコストを低くするようにして進行していました。 実際の機能実装にあたってはエンジニアも自身で考えて細かいボールを拾ったりしながら、実装 していってもらいました。この辺りはこのプロジェクトだからというよりも、メドレーの開発のベースになっている部分なので良いですよね。 メンバーのイメージ合わせがプロジェクト成功の鍵 新居 : 先ほどもお話がありましたが、プロジェクト途中の意思決定で関わるプロダクトが多くなったのでスイッチングが大変だったということでしたが、実際にそのタイミングになったときに全体のシステム設計なんかも変わったりしたんでしょうか。 田中 : 私はプロジェクトの途中から入ったんですが、そのタイミングで、宍戸さんや来田さんがちょうどシステム設計を考え直していたり、プロジェクト計画の引き直しをしているところでした。そこでまずは全体像を把握したいと考えてドキュメントなどを見せてもらったんです。各機能の細かい要件は分かったのですが、このプロジェクト全体としての各システムの責務や依存関係などがいまいち分かりづらく、メンバー間の認識も若干ズレが発生しているように感じました。なのでまずは**メンバーの認識を合わせ、各チームが何をするべきかを明確化するために、各システムの責務など全体感の整理整頓をして「見える化」**することから始めました。 このプロジェクトに限らずですが、プロジェクトとして抽象度の高い段階でのドキュメントは、文章のみの記載だと実は関係者にしっかりと伝わっていなかったということが多々あります。各自が頭の中でイメージした図に差異が発生している状態です。自分はそういう際に良く言っているのが**「大枠で良いので、まずは整理結果を図にしてみんなのイメージを合わせる**」ということです。こうして認識を合わせることで各チームが進めやすくなり後戻りリスクも軽減されるので、この段階でしっかりとイメージをすりあわせる事がとても重要だと考えています。 医療プラットフォーム CTO 田中さん 新居 : たしかにテキストで仕様なんかを書きながら説明しても、実は認識に齟齬があった…という経験があります。その後はどのようなプロセスでプロジェクト推進したんですか? 田中 : その後は各プロダクトにて実装予定の機能で、プロダクト間で共通化できそうな機能を共通サービスとして切り出すかどうかをみんなと考えていきました。結果として大きな機能では「ビデオ通話」部分を共通化するという意思決定をしました。他にも「問診票の提供」機能が候補としてあがっていましたが、共通化せずに各プロダクトの責務としてそれぞれ実装するという結論となりました。同じような機能に見えても、医科と歯科という業務ドメイン毎のコンテキスト差異を十分に検討した上での判断でした。 その差異がプロダクト機能としての強みとなり、安易な共通化はプロダクト成長の足枷となるリスクも存在 するためです。この判断も先ほどの全体の依存関係などが整理されたからこそ、意思決定できるものでした。 酒井 : 機能実装時に実感しましたが、やはり医科と歯科では細かい部分の要件などが異なる部分が多かったので、この段階で共通化の判断ができたのは大変助かりました。 PRM プロジェクトの大きな成果 新居 : 最後になりますが、このプロジェクトが終わっての成果はどのように考えていますか? 宍戸 : 冒頭に話した CLINICS の課題に関してはある程度、解決ができたと思います。 医療機関の業務に沿った形でプロダクトが進化 できた点はよかったと思います。特に問診周りなどは発熱外来などニーズの多様化に即して使い勝手が良くなったと思っています。 酒井 : 他にもビデオ通話部分など「オンライン診療」を提供するプロダクトとして「対面診療」だけではなく、もっと有用なプロダクトにできたかと思っています。 来田 : まだリリースしたばかりですが、初月の販売実績も期待していたよりも良く、そうした意味でも マーケットフィットした機能を出せたなという手応え が実感としてもありますね。 田中 : 予約やオンライン診療もドメインを統一した結果、会員登録数が増えていますので、そうした点も成果と言えます。 酒井 : あとは直接の成果というわけではないのですが、今回のプロジェクトの副産物として CLINICS の機能を整理整頓していった結果、 改めて「一気通貫で医療機関の業務をサポートできる」というトータルでの機能提供と各機能のシームレスな連携は CLINICS の強み だ、というのが再確認できたのは大きいです。 新居 : これからのさらなる CLINICS の発展に期待できますね!本日は長い時間お話ありがとうございました! おわりに メドレーとしてもかなり大規模なプロジェクトだった今回の PRM プロジェクトでしたが、みなさんのお話を聞いて各部署・各プロダクトで綿密に連携しながらプロジェクトを成功させようとしている様子が感じられるインタビューでした。 特にプロジェクト進行の話は非常に参考になりました。皆さんのご参考になる部分があれば幸いです。 こうしたプロジェクトで自分の力を発揮したい!と思った方はぜひお気軽に下記からご応募ください。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの新居です。クラウド診療支援システム CLINICS が 8 月から大幅に アップデート して、より患者と医療機関が密接に繋がるようになりました。 今回のアップデートで中心になっている機能領域として PRM(Patient Relationship Management) というものがあります。 この PRM が一体どういったものなのか、プロジェクトはどのように進んでいったのかを関係者にインタビューしていきました。 メドレーで大規模なプロジェクト開発をどのように行なっているかの一端をお見せできればと考えています! インタビュイー紹介 宍戸さん 医療プラットフォーム第一本部 プロダクト開発室第二グループに所属。クラウド診療支援システム CLINICS の開発責任者。前職は株式会社サイバーエージェントでサーバサイドエンジニアとして従事。2017 年メドレー入社。 酒井さん 医療プラットフォーム第一本部 プロダクト開発室第二グループに所属。クラウド診療支援システム CLINICS の UI/UX 全般を担当。本プロジェクトのリード。前職は受託開発会社で様々なサイトやシステムのデザインに従事。2019 年メドレー入社。 田中さん 医療プラットフォーム CTO。医療プラットフォームの開発統括をしながら、自身は患者統合基盤の開発を担当。前職までは SIer や IT コンサルタントを経て、株式会社サイバーエージェントでサーバサイドエンジニアとして従事。2016 年メドレー入社。 来田さん 前職まではクリニックで精神科医として従事。CLINCS オンライン診療の立ち上げ時から関わる。現在は CLINICS のディレクションを中心として事業部と開発の架け橋となっている。 PRM とはどういうものなのか? 新居 : では今回中心となった PRM とはいったい何なのかというところから解説していただいて良いですか? 一般的にはそこまで知られてない言葉なのではないかと思うのですが…。 宍戸 : 元々 CRM(Customer Relationship Management)というマーケティングなどの文脈の用語があります。これは「自社サービスや商品を使っている顧客」と「サービスや商品を提供している企業」との関係性を管理することを指しますが、それをもとに適切なアクションをおこなうことで最終的には利益向上を目指すものと考えられます。 PRM は CRM と同様に医療機関と患者さんの関係性を管理することで必要なサービスを提供する ためのもの、と考えています。 CLINICS で基幹システムである電子カルテなどではなく、 オンライン診療・予約・問診など患者接点となる機能をターゲットにしてそれらを強化・改善 していったのが、CLINICS の今回の PRM プロジェクトになります。 CLINICS 開発責任者 宍戸さん 新居 : 確かに CRM は最近良く聞く言葉でしたが、PRM は患者と医療サービスを使う医療機関との関係を深めるためのものなんですね。 PRM プロジェクトの始まり CLINICS に感じていた課題とは 新居 : このプロジェクトは半年ほどかけていると聞きましたが、「PRM をやっていこう」となったのが半年前からだったんでしょうか? 宍戸 : 元々 CLINICS はオンライン診療のシステムとして 2016 年からサービスを提供してきました。2018 年からは CLINICS カルテとして電子カルテシステムも提供を開始しましたが、そのタイミング以降はオンライン診療部分に関してはそこまで大きくアップデートはしてこなかったんです。 現在はクラウド診療支援システムとして販売していますが、これまでは電子カルテなど基幹部分の強化がメインになっていたからです。しかし、数年開発・運用してきた中で、本来医療機関の診察のメインである対面診療の予約については課題が積み残されていたり、昨今の状況から来る オンライン診療のニーズなどを始めとして、患者接点を強化していく必要がある ということになり、今回取り組むことになりました。 酒井 : PRM というと本当にここ最近の潮流なのですが、 CLINICS はもともと「患者とつながる」をコンセプト としており、今回の機能強化などもこのコンセプトに基づき実施しています。その上で、患者とのタッチポイントで抜けていた部分や強化したほうが良い部分をより作り込んでいったという形です。 例えば、CLINICS は元々オンライン診療のシステムとして始まっており、対面診療予約に関して使いづらさを感じるケースがあったため、対面診療予約をより行いやすくするよう改修を行うなどです。 CLINICS デザイナー 酒井さん 新居 : 元々あったものをさらに患者とのタッチポイントを強化するために、改修・改善していったんですね。 プロジェクトの背景 どのくらいの規模のプロジェクトだったのか 新居 : 半年のプロジェクトということですが、規模としてはどの位の大きさだったんでしょうか? 酒井 : 私が経験したプロジェクトの中でも関わる部署など考えると一番大きかったと思います。開発はもちろんですが、CLINICS チームの セールス・カスタマーサクセス・マーケティング、広報もなのでほぼ CLINICS の全部署と関わっていました 。 田中 : 他にも、サービスとしては患者統合基盤・ 患者向けアプリ・ Dentis が関係しています。 宍戸 : QA チームにもしっかり入ってもらって QA を行なったりしてもらったので、本当に 医療プラットフォームのほぼ全てのチームと関わって開発していった 感じです。最終的にプロダクトの見せ方や売り方なども含めて調整していったので事業部とも密接に関わって作り上げていきました。 新しい PRM 機能をどうやって、プロダクトに融合させたのか 新居 : そこまで大きい規模のプロジェクトだということで、PRM の各種機能をどうやって上手くプロダクトに落としこむのか、実際にはどのようにみなさん推進されていったんでしょう。 宍戸 : プロジェクトの推進という意味では、最初は来田さんや( Dentis の運営を行なっている)プロダクト戦略室の平山さんと スモールスタートで意見を出し合いながらモックを作っていき、まずはビジュアル面から機能のイメージなどを刷り合わせ ていくのに、酒井さんに手を動かしてもらいながら進めていました。 その過程でこのプロジェクトにおける重要な意思決定がありました。CLINICS ではログイン不要のシンプルな予約機能を以前より提供していました。この機能は患者アプリとは元々違うドメインで運営していたものでしたが、今回のタイミングでこの両者のアプリケーションを患者アプリと同じドメインに統合して運営していこうという決定をしました。 患者アプリは CLINICS チームとは別チームで運営しているという背景もあり、チーム間の連携が格段に増え 、考えなければいけない事柄も多くなります。プロジェクトとして関係者が多くなってきたので、 今までの考え方を 1 度リセットしてプロジェクトの進め方を新しく模索する必要がありました 。 この点がかなり自分の中では大変でした。来田さんも大変だったと思います。こうした全体像を描いたり、全体スケジュールを決めたりというところでは、田中さんにアドバイスをもらいながらプロジェクトを進めていきました。 プロジェクトを推進するために必要だったこと 難しい意思決定をどのようにしていた? 新居 : 途中から一気にプロジェクトがスケールアップしたということなんですね。今回のプロジェクトは色々な部署も関わるし、たくさんの機能や改修が入っています。開発側と事業部側との意識合わせが、かなり必要だったんではないかと思うのですが、その辺はいかがだったでしょうか。 来田 : 例えば、今まで CLINICS では対面診療予約の際に患者のクレジットカード登録を必須としていたのですが、今回の改修でクレジットカード登録を不要に変更できるように対応を行いました。この対応は、CLINICS オンライン診療の初期から念願の機能だったりします。自分は事業部長である田中大介さんと今年の年明けくらいから話をして、メンバーに「よし、このプロジェクトをやっていこう」という話を持っていくようにしていました。やっぱり、大変なプロジェクトだというのはあったのでスタートを切れる状態に徐々にしていった感じです。 プロジェクトが佳境に入ってからは自分は各部署との調整がメインの業務でした。開発側と事業側とか CLINICS と Dentis だとかそういった立場の違いから来る要求の違いを納得できる仕様に落とし込む作業です。やっぱり、それぞれの立場でベストを尽くそうとみんな考えているんですが、全部を取り入れることはできないので。私が調整するときには それぞれ反対の立場の人たちの考えをきちんと伝えるようにということをしながら、仕様を決めていく ことを念頭に置いていました。 具体的な調整の例としては、開発する機能とセールスする際のプランの刷り合わせだったりですね。「機能としてはこうしたほうが使いやすいよね」というだけだと、セールス側としては「どこをウリにして売っていくのかというのが見えてこない」という話になったんですね。これはどちらの言い分も一理あるものなんですが、こういうところを時間をかけて 双方納得行くように決めていきました 。 CLINICS ディレクター・医師 来田さん 酒井 : この例でやったことは、まず現在のプランと機能を全部書き出して、組み合わせを整理するということでした。これをベースにして話を刷り合わせていったんですが、文字ベースだと人間分かった気になるんですが、実はそこまでピンと来ない。ですので、 LP のモックを作ってこれを見た顧客が導入したくなるようなウリになっているのかをすぐに判断できる状態 にしました。 宍戸 : こうしてちゃんと機能を解いていって細かい部分も含めて、時には CLINICS のコンセプトに立ち返って事業部・開発双方で時間をかけて認識を合わせることができたのは、大変でしたが良かったですね。 リリースまでのプロセスで顧客の声を反映 新居 : やはりここまでのプロジェクトだと最初の段階でちゃんとリリースまでを見据えた意識合わせをチーム内で行なっていたんですね。開発が進行していって、リリースするまではどのようにプロジェクトは進んでいったんでしょう。 宍戸 : リリースをする直前も、単純に仕様や機能について文書で説明しても理解するのは難しいので、酒井さんにディレクションをしてもらいながら、開発環境を使って QA チームやカスタマーサポートチームと一緒に認識合わせやリリースに向けた準備を行なっていきました。 来田 : あとは関係が構築できている 顧客に実際機能を見てもらって反応を伺う ということもしていきました。色々な使い方をしている顧客 10 件くらいにモックをベースにヒアリングをかけていきました。価格や導入時期なども含めた話を聞いていって、そこをすぐにプロジェクトにフィードバックする体制を構築していました。 酒井 : 実際に顧客の声をこうして聞けるというのは本当にプロダクトにとってありがたいことでした。特にこういう使い勝手などに直接関わる部分では、こうしたフィードバックの有無で完成度が違ってきます。 機能の正式リリース前から機能評価に協力していただける医療機関がいるのは、カスタマーサポートの皆さんが顧客と良好な関係を築けているおかげ だと思っています。こういった点はメドレーの強みだと思います。 プロジェクトで大切にしたこと 新居 : 開発段階からユーザーの声を吸い上げていけるのは、本当に良いですね。プロダクトの改善スピードなんかも段違いに早くなりそうです。他に大切にしていた部分などありますか? 酒井 : 今回の機能開発においては、プロジェクトの責任者として、開発以外のメンバーともしっかりコミュニケーションし合意形成を図ることを意識してプロジェクトを推進しました。 先ほどの話にも出ましたが 1 つの機能を実装するとなっても、実際の医療現場での使い勝手や、メドレーでのサポート、売り方など色々な視点で考えないといけないプロジェクトでした。そのため、そういったところをカスタマーサクセスのメンバー含む 10 人ほどと毎週 1 つ 1 つ納得がいくように詰めていくという作業をしていったりしました。 来田さんのように現役の医師の意見、顧客の意見なども取り入れられますし、カスタマーサポートには医療事務経験者の方もいらっしゃるので、多方面の視点を総合的に取り入れられるコミュニケーション を心がけていました。 手段はテキストや Figma でのデザイン、実際の実装を見せるなど適切な手段を選んでコミュニケーションコストを低くするようにして進行していました。 実際の機能実装にあたってはエンジニアも自身で考えて細かいボールを拾ったりしながら、実装 していってもらいました。この辺りはこのプロジェクトだからというよりも、メドレーの開発のベースになっている部分なので良いですよね。 メンバーのイメージ合わせがプロジェクト成功の鍵 新居 : 先ほどもお話がありましたが、プロジェクト途中の意思決定で関わるプロダクトが多くなったのでスイッチングが大変だったということでしたが、実際にそのタイミングになったときに全体のシステム設計なんかも変わったりしたんでしょうか。 田中 : 私はプロジェクトの途中から入ったんですが、そのタイミングで、宍戸さんや来田さんがちょうどシステム設計を考え直していたり、プロジェクト計画の引き直しをしているところでした。そこでまずは全体像を把握したいと考えてドキュメントなどを見せてもらったんです。各機能の細かい要件は分かったのですが、このプロジェクト全体としての各システムの責務や依存関係などがいまいち分かりづらく、メンバー間の認識も若干ズレが発生しているように感じました。なのでまずは**メンバーの認識を合わせ、各チームが何をするべきかを明確化するために、各システムの責務など全体感の整理整頓をして「見える化」**することから始めました。 このプロジェクトに限らずですが、プロジェクトとして抽象度の高い段階でのドキュメントは、文章のみの記載だと実は関係者にしっかりと伝わっていなかったということが多々あります。各自が頭の中でイメージした図に差異が発生している状態です。自分はそういう際に良く言っているのが**「大枠で良いので、まずは整理結果を図にしてみんなのイメージを合わせる**」ということです。こうして認識を合わせることで各チームが進めやすくなり後戻りリスクも軽減されるので、この段階でしっかりとイメージをすりあわせる事がとても重要だと考えています。 医療プラットフォーム CTO 田中さん 新居 : たしかにテキストで仕様なんかを書きながら説明しても、実は認識に齟齬があった…という経験があります。その後はどのようなプロセスでプロジェクト推進したんですか? 田中 : その後は各プロダクトにて実装予定の機能で、プロダクト間で共通化できそうな機能を共通サービスとして切り出すかどうかをみんなと考えていきました。結果として大きな機能では「ビデオ通話」部分を共通化するという意思決定をしました。他にも「問診票の提供」機能が候補としてあがっていましたが、共通化せずに各プロダクトの責務としてそれぞれ実装するという結論となりました。同じような機能に見えても、医科と歯科という業務ドメイン毎のコンテキスト差異を十分に検討した上での判断でした。 その差異がプロダクト機能としての強みとなり、安易な共通化はプロダクト成長の足枷となるリスクも存在 するためです。この判断も先ほどの全体の依存関係などが整理されたからこそ、意思決定できるものでした。 酒井 : 機能実装時に実感しましたが、やはり医科と歯科では細かい部分の要件などが異なる部分が多かったので、この段階で共通化の判断ができたのは大変助かりました。 PRM プロジェクトの大きな成果 新居 : 最後になりますが、このプロジェクトが終わっての成果はどのように考えていますか? 宍戸 : 冒頭に話した CLINICS の課題に関してはある程度、解決ができたと思います。 医療機関の業務に沿った形でプロダクトが進化 できた点はよかったと思います。特に問診周りなどは発熱外来などニーズの多様化に即して使い勝手が良くなったと思っています。 酒井 : 他にもビデオ通話部分など「オンライン診療」を提供するプロダクトとして「対面診療」だけではなく、もっと有用なプロダクトにできたかと思っています。 来田 : まだリリースしたばかりですが、初月の販売実績も期待していたよりも良く、そうした意味でも マーケットフィットした機能を出せたなという手応え が実感としてもありますね。 田中 : 予約やオンライン診療もドメインを統一した結果、会員登録数が増えていますので、そうした点も成果と言えます。 酒井 : あとは直接の成果というわけではないのですが、今回のプロジェクトの副産物として CLINICS の機能を整理整頓していった結果、 改めて「一気通貫で医療機関の業務をサポートできる」というトータルでの機能提供と各機能のシームレスな連携は CLINICS の強み だ、というのが再確認できたのは大きいです。 新居 : これからのさらなる CLINICS の発展に期待できますね!本日は長い時間お話ありがとうございました! おわりに メドレーとしてもかなり大規模なプロジェクトだった今回の PRM プロジェクトでしたが、みなさんのお話を聞いて各部署・各プロダクトで綿密に連携しながらプロジェクトを成功させようとしている様子が感じられるインタビューでした。 特にプロジェクト進行の話は非常に参考になりました。皆さんのご参考になる部分があれば幸いです。 こうしたプロジェクトで自分の力を発揮したい!と思った方はぜひお気軽に下記からご応募ください。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの新居です。クラウド診療支援システム CLINICS が 8 月から大幅に アップデート して、より患者と医療機関が密接に繋がるようになりました。 今回のアップデートで中心になっている機能領域として PRM(Patient Relationship Management) というものがあります。 この PRM が一体どういったものなのか、プロジェクトはどのように進んでいったのかを関係者にインタビューしていきました。 メドレーで大規模なプロジェクト開発をどのように行なっているかの一端をお見せできればと考えています! インタビュイー紹介 宍戸さん 医療プラットフォーム第一本部 プロダクト開発室第二グループに所属。クラウド診療支援システム CLINICS の開発責任者。前職は株式会社サイバーエージェントでサーバサイドエンジニアとして従事。2017 年メドレー入社。 酒井さん 医療プラットフォーム第一本部 プロダクト開発室第二グループに所属。クラウド診療支援システム CLINICS の UI/UX 全般を担当。本プロジェクトのリード。前職は受託開発会社で様々なサイトやシステムのデザインに従事。2019 年メドレー入社。 田中さん 医療プラットフォーム CTO。医療プラットフォームの開発統括をしながら、自身は患者統合基盤の開発を担当。前職までは SIer や IT コンサルタントを経て、株式会社サイバーエージェントでサーバサイドエンジニアとして従事。2016 年メドレー入社。 来田さん 前職まではクリニックで精神科医として従事。CLINCS オンライン診療の立ち上げ時から関わる。現在は CLINICS のディレクションを中心として事業部と開発の架け橋となっている。 PRM とはどういうものなのか? 新居 : では今回中心となった PRM とはいったい何なのかというところから解説していただいて良いですか? 一般的にはそこまで知られてない言葉なのではないかと思うのですが…。 宍戸 : 元々 CRM(Customer Relationship Management)というマーケティングなどの文脈の用語があります。これは「自社サービスや商品を使っている顧客」と「サービスや商品を提供している企業」との関係性を管理することを指しますが、それをもとに適切なアクションをおこなうことで最終的には利益向上を目指すものと考えられます。 PRM は CRM と同様に医療機関と患者さんの関係性を管理することで必要なサービスを提供する ためのもの、と考えています。 CLINICS で基幹システムである電子カルテなどではなく、 オンライン診療・予約・問診など患者接点となる機能をターゲットにしてそれらを強化・改善 していったのが、CLINICS の今回の PRM プロジェクトになります。 CLINICS 開発責任者 宍戸さん 新居 : 確かに CRM は最近良く聞く言葉でしたが、PRM は患者と医療サービスを使う医療機関との関係を深めるためのものなんですね。 PRM プロジェクトの始まり CLINICS に感じていた課題とは 新居 : このプロジェクトは半年ほどかけていると聞きましたが、「PRM をやっていこう」となったのが半年前からだったんでしょうか? 宍戸 : 元々 CLINICS はオンライン診療のシステムとして 2016 年からサービスを提供してきました。2018 年からは CLINICS カルテとして電子カルテシステムも提供を開始しましたが、そのタイミング以降はオンライン診療部分に関してはそこまで大きくアップデートはしてこなかったんです。 現在はクラウド診療支援システムとして販売していますが、これまでは電子カルテなど基幹部分の強化がメインになっていたからです。しかし、数年開発・運用してきた中で、本来医療機関の診察のメインである対面診療の予約については課題が積み残されていたり、昨今の状況から来る オンライン診療のニーズなどを始めとして、患者接点を強化していく必要がある ということになり、今回取り組むことになりました。 酒井 : PRM というと本当にここ最近の潮流なのですが、 CLINICS はもともと「患者とつながる」をコンセプト としており、今回の機能強化などもこのコンセプトに基づき実施しています。その上で、患者とのタッチポイントで抜けていた部分や強化したほうが良い部分をより作り込んでいったという形です。 例えば、CLINICS は元々オンライン診療のシステムとして始まっており、対面診療予約に関して使いづらさを感じるケースがあったため、対面診療予約をより行いやすくするよう改修を行うなどです。 CLINICS デザイナー 酒井さん 新居 : 元々あったものをさらに患者とのタッチポイントを強化するために、改修・改善していったんですね。 プロジェクトの背景 どのくらいの規模のプロジェクトだったのか 新居 : 半年のプロジェクトということですが、規模としてはどの位の大きさだったんでしょうか? 酒井 : 私が経験したプロジェクトの中でも関わる部署など考えると一番大きかったと思います。開発はもちろんですが、CLINICS チームの セールス・カスタマーサクセス・マーケティング、広報もなのでほぼ CLINICS の全部署と関わっていました 。 田中 : 他にも、サービスとしては患者統合基盤・ 患者向けアプリ・ Dentis が関係しています。 宍戸 : QA チームにもしっかり入ってもらって QA を行なったりしてもらったので、本当に 医療プラットフォームのほぼ全てのチームと関わって開発していった 感じです。最終的にプロダクトの見せ方や売り方なども含めて調整していったので事業部とも密接に関わって作り上げていきました。 新しい PRM 機能をどうやって、プロダクトに融合させたのか 新居 : そこまで大きい規模のプロジェクトだということで、PRM の各種機能をどうやって上手くプロダクトに落としこむのか、実際にはどのようにみなさん推進されていったんでしょう。 宍戸 : プロジェクトの推進という意味では、最初は来田さんや( Dentis の運営を行なっている)プロダクト戦略室の平山さんと スモールスタートで意見を出し合いながらモックを作っていき、まずはビジュアル面から機能のイメージなどを刷り合わせ ていくのに、酒井さんに手を動かしてもらいながら進めていました。 その過程でこのプロジェクトにおける重要な意思決定がありました。CLINICS ではログイン不要のシンプルな予約機能を以前より提供していました。この機能は患者アプリとは元々違うドメインで運営していたものでしたが、今回のタイミングでこの両者のアプリケーションを患者アプリと同じドメインに統合して運営していこうという決定をしました。 患者アプリは CLINICS チームとは別チームで運営しているという背景もあり、チーム間の連携が格段に増え 、考えなければいけない事柄も多くなります。プロジェクトとして関係者が多くなってきたので、 今までの考え方を 1 度リセットしてプロジェクトの進め方を新しく模索する必要がありました 。 この点がかなり自分の中では大変でした。来田さんも大変だったと思います。こうした全体像を描いたり、全体スケジュールを決めたりというところでは、田中さんにアドバイスをもらいながらプロジェクトを進めていきました。 プロジェクトを推進するために必要だったこと 難しい意思決定をどのようにしていた? 新居 : 途中から一気にプロジェクトがスケールアップしたということなんですね。今回のプロジェクトは色々な部署も関わるし、たくさんの機能や改修が入っています。開発側と事業部側との意識合わせが、かなり必要だったんではないかと思うのですが、その辺はいかがだったでしょうか。 来田 : 例えば、今まで CLINICS では対面診療予約の際に患者のクレジットカード登録を必須としていたのですが、今回の改修でクレジットカード登録を不要に変更できるように対応を行いました。この対応は、CLINICS オンライン診療の初期から念願の機能だったりします。自分は事業部長である田中大介さんと今年の年明けくらいから話をして、メンバーに「よし、このプロジェクトをやっていこう」という話を持っていくようにしていました。やっぱり、大変なプロジェクトだというのはあったのでスタートを切れる状態に徐々にしていった感じです。 プロジェクトが佳境に入ってからは自分は各部署との調整がメインの業務でした。開発側と事業側とか CLINICS と Dentis だとかそういった立場の違いから来る要求の違いを納得できる仕様に落とし込む作業です。やっぱり、それぞれの立場でベストを尽くそうとみんな考えているんですが、全部を取り入れることはできないので。私が調整するときには それぞれ反対の立場の人たちの考えをきちんと伝えるようにということをしながら、仕様を決めていく ことを念頭に置いていました。 具体的な調整の例としては、開発する機能とセールスする際のプランの刷り合わせだったりですね。「機能としてはこうしたほうが使いやすいよね」というだけだと、セールス側としては「どこをウリにして売っていくのかというのが見えてこない」という話になったんですね。これはどちらの言い分も一理あるものなんですが、こういうところを時間をかけて 双方納得行くように決めていきました 。 CLINICS ディレクター・医師 来田さん 酒井 : この例でやったことは、まず現在のプランと機能を全部書き出して、組み合わせを整理するということでした。これをベースにして話を刷り合わせていったんですが、文字ベースだと人間分かった気になるんですが、実はそこまでピンと来ない。ですので、 LP のモックを作ってこれを見た顧客が導入したくなるようなウリになっているのかをすぐに判断できる状態 にしました。 宍戸 : こうしてちゃんと機能を解いていって細かい部分も含めて、時には CLINICS のコンセプトに立ち返って事業部・開発双方で時間をかけて認識を合わせることができたのは、大変でしたが良かったですね。 リリースまでのプロセスで顧客の声を反映 新居 : やはりここまでのプロジェクトだと最初の段階でちゃんとリリースまでを見据えた意識合わせをチーム内で行なっていたんですね。開発が進行していって、リリースするまではどのようにプロジェクトは進んでいったんでしょう。 宍戸 : リリースをする直前も、単純に仕様や機能について文書で説明しても理解するのは難しいので、酒井さんにディレクションをしてもらいながら、開発環境を使って QA チームやカスタマーサポートチームと一緒に認識合わせやリリースに向けた準備を行なっていきました。 来田 : あとは関係が構築できている 顧客に実際機能を見てもらって反応を伺う ということもしていきました。色々な使い方をしている顧客 10 件くらいにモックをベースにヒアリングをかけていきました。価格や導入時期なども含めた話を聞いていって、そこをすぐにプロジェクトにフィードバックする体制を構築していました。 酒井 : 実際に顧客の声をこうして聞けるというのは本当にプロダクトにとってありがたいことでした。特にこういう使い勝手などに直接関わる部分では、こうしたフィードバックの有無で完成度が違ってきます。 機能の正式リリース前から機能評価に協力していただける医療機関がいるのは、カスタマーサポートの皆さんが顧客と良好な関係を築けているおかげ だと思っています。こういった点はメドレーの強みだと思います。 プロジェクトで大切にしたこと 新居 : 開発段階からユーザーの声を吸い上げていけるのは、本当に良いですね。プロダクトの改善スピードなんかも段違いに早くなりそうです。他に大切にしていた部分などありますか? 酒井 : 今回の機能開発においては、プロジェクトの責任者として、開発以外のメンバーともしっかりコミュニケーションし合意形成を図ることを意識してプロジェクトを推進しました。 先ほどの話にも出ましたが 1 つの機能を実装するとなっても、実際の医療現場での使い勝手や、メドレーでのサポート、売り方など色々な視点で考えないといけないプロジェクトでした。そのため、そういったところをカスタマーサクセスのメンバー含む 10 人ほどと毎週 1 つ 1 つ納得がいくように詰めていくという作業をしていったりしました。 来田さんのように現役の医師の意見、顧客の意見なども取り入れられますし、カスタマーサポートには医療事務経験者の方もいらっしゃるので、多方面の視点を総合的に取り入れられるコミュニケーション を心がけていました。 手段はテキストや Figma でのデザイン、実際の実装を見せるなど適切な手段を選んでコミュニケーションコストを低くするようにして進行していました。 実際の機能実装にあたってはエンジニアも自身で考えて細かいボールを拾ったりしながら、実装 していってもらいました。この辺りはこのプロジェクトだからというよりも、メドレーの開発のベースになっている部分なので良いですよね。 メンバーのイメージ合わせがプロジェクト成功の鍵 新居 : 先ほどもお話がありましたが、プロジェクト途中の意思決定で関わるプロダクトが多くなったのでスイッチングが大変だったということでしたが、実際にそのタイミングになったときに全体のシステム設計なんかも変わったりしたんでしょうか。 田中 : 私はプロジェクトの途中から入ったんですが、そのタイミングで、宍戸さんや来田さんがちょうどシステム設計を考え直していたり、プロジェクト計画の引き直しをしているところでした。そこでまずは全体像を把握したいと考えてドキュメントなどを見せてもらったんです。各機能の細かい要件は分かったのですが、このプロジェクト全体としての各システムの責務や依存関係などがいまいち分かりづらく、メンバー間の認識も若干ズレが発生しているように感じました。なのでまずは**メンバーの認識を合わせ、各チームが何をするべきかを明確化するために、各システムの責務など全体感の整理整頓をして「見える化」**することから始めました。 このプロジェクトに限らずですが、プロジェクトとして抽象度の高い段階でのドキュメントは、文章のみの記載だと実は関係者にしっかりと伝わっていなかったということが多々あります。各自が頭の中でイメージした図に差異が発生している状態です。自分はそういう際に良く言っているのが**「大枠で良いので、まずは整理結果を図にしてみんなのイメージを合わせる**」ということです。こうして認識を合わせることで各チームが進めやすくなり後戻りリスクも軽減されるので、この段階でしっかりとイメージをすりあわせる事がとても重要だと考えています。 医療プラットフォーム CTO 田中さん 新居 : たしかにテキストで仕様なんかを書きながら説明しても、実は認識に齟齬があった…という経験があります。その後はどのようなプロセスでプロジェクト推進したんですか? 田中 : その後は各プロダクトにて実装予定の機能で、プロダクト間で共通化できそうな機能を共通サービスとして切り出すかどうかをみんなと考えていきました。結果として大きな機能では「ビデオ通話」部分を共通化するという意思決定をしました。他にも「問診票の提供」機能が候補としてあがっていましたが、共通化せずに各プロダクトの責務としてそれぞれ実装するという結論となりました。同じような機能に見えても、医科と歯科という業務ドメイン毎のコンテキスト差異を十分に検討した上での判断でした。 その差異がプロダクト機能としての強みとなり、安易な共通化はプロダクト成長の足枷となるリスクも存在 するためです。この判断も先ほどの全体の依存関係などが整理されたからこそ、意思決定できるものでした。 酒井 : 機能実装時に実感しましたが、やはり医科と歯科では細かい部分の要件などが異なる部分が多かったので、この段階で共通化の判断ができたのは大変助かりました。 PRM プロジェクトの大きな成果 新居 : 最後になりますが、このプロジェクトが終わっての成果はどのように考えていますか? 宍戸 : 冒頭に話した CLINICS の課題に関してはある程度、解決ができたと思います。 医療機関の業務に沿った形でプロダクトが進化 できた点はよかったと思います。特に問診周りなどは発熱外来などニーズの多様化に即して使い勝手が良くなったと思っています。 酒井 : 他にもビデオ通話部分など「オンライン診療」を提供するプロダクトとして「対面診療」だけではなく、もっと有用なプロダクトにできたかと思っています。 来田 : まだリリースしたばかりですが、初月の販売実績も期待していたよりも良く、そうした意味でも マーケットフィットした機能を出せたなという手応え が実感としてもありますね。 田中 : 予約やオンライン診療もドメインを統一した結果、会員登録数が増えていますので、そうした点も成果と言えます。 酒井 : あとは直接の成果というわけではないのですが、今回のプロジェクトの副産物として CLINICS の機能を整理整頓していった結果、 改めて「一気通貫で医療機関の業務をサポートできる」というトータルでの機能提供と各機能のシームレスな連携は CLINICS の強み だ、というのが再確認できたのは大きいです。 新居 : これからのさらなる CLINICS の発展に期待できますね!本日は長い時間お話ありがとうございました! おわりに メドレーとしてもかなり大規模なプロジェクトだった今回の PRM プロジェクトでしたが、みなさんのお話を聞いて各部署・各プロダクトで綿密に連携しながらプロジェクトを成功させようとしている様子が感じられるインタビューでした。 特にプロジェクト進行の話は非常に参考になりました。皆さんのご参考になる部分があれば幸いです。 こうしたプロジェクトで自分の力を発揮したい!と思った方はぜひお気軽に下記からご応募ください。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの新居です。クラウド診療支援システム CLINICS が 8 月から大幅に アップデート して、より患者と医療機関が密接に繋がるようになりました。 今回のアップデートで中心になっている機能領域として PRM(Patient Relationship Management) というものがあります。 この PRM が一体どういったものなのか、プロジェクトはどのように進んでいったのかを関係者にインタビューしていきました。 メドレーで大規模なプロジェクト開発をどのように行なっているかの一端をお見せできればと考えています! インタビュイー紹介 宍戸さん 医療プラットフォーム第一本部 プロダクト開発室第二グループに所属。クラウド診療支援システム CLINICS の開発責任者。前職は株式会社サイバーエージェントでサーバサイドエンジニアとして従事。2017 年メドレー入社。 酒井さん 医療プラットフォーム第一本部 プロダクト開発室第二グループに所属。クラウド診療支援システム CLINICS の UI/UX 全般を担当。本プロジェクトのリード。前職は受託開発会社で様々なサイトやシステムのデザインに従事。2019 年メドレー入社。 田中さん 医療プラットフォーム CTO。医療プラットフォームの開発統括をしながら、自身は患者統合基盤の開発を担当。前職までは SIer や IT コンサルタントを経て、株式会社サイバーエージェントでサーバサイドエンジニアとして従事。2016 年メドレー入社。 来田さん 前職まではクリニックで精神科医として従事。CLINCS オンライン診療の立ち上げ時から関わる。現在は CLINICS のディレクションを中心として事業部と開発の架け橋となっている。 PRM とはどういうものなのか? 新居 : では今回中心となった PRM とはいったい何なのかというところから解説していただいて良いですか? 一般的にはそこまで知られてない言葉なのではないかと思うのですが…。 宍戸 : 元々 CRM(Customer Relationship Management)というマーケティングなどの文脈の用語があります。これは「自社サービスや商品を使っている顧客」と「サービスや商品を提供している企業」との関係性を管理することを指しますが、それをもとに適切なアクションをおこなうことで最終的には利益向上を目指すものと考えられます。 PRM は CRM と同様に医療機関と患者さんの関係性を管理することで必要なサービスを提供する ためのもの、と考えています。 CLINICS で基幹システムである電子カルテなどではなく、 オンライン診療・予約・問診など患者接点となる機能をターゲットにしてそれらを強化・改善 していったのが、CLINICS の今回の PRM プロジェクトになります。 CLINICS 開発責任者 宍戸さん 新居 : 確かに CRM は最近良く聞く言葉でしたが、PRM は患者と医療サービスを使う医療機関との関係を深めるためのものなんですね。 PRM プロジェクトの始まり CLINICS に感じていた課題とは 新居 : このプロジェクトは半年ほどかけていると聞きましたが、「PRM をやっていこう」となったのが半年前からだったんでしょうか? 宍戸 : 元々 CLINICS はオンライン診療のシステムとして 2016 年からサービスを提供してきました。2018 年からは CLINICS カルテとして電子カルテシステムも提供を開始しましたが、そのタイミング以降はオンライン診療部分に関してはそこまで大きくアップデートはしてこなかったんです。 現在はクラウド診療支援システムとして販売していますが、これまでは電子カルテなど基幹部分の強化がメインになっていたからです。しかし、数年開発・運用してきた中で、本来医療機関の診察のメインである対面診療の予約については課題が積み残されていたり、昨今の状況から来る オンライン診療のニーズなどを始めとして、患者接点を強化していく必要がある ということになり、今回取り組むことになりました。 酒井 : PRM というと本当にここ最近の潮流なのですが、 CLINICS はもともと「患者とつながる」をコンセプト としており、今回の機能強化などもこのコンセプトに基づき実施しています。その上で、患者とのタッチポイントで抜けていた部分や強化したほうが良い部分をより作り込んでいったという形です。 例えば、CLINICS は元々オンライン診療のシステムとして始まっており、対面診療予約に関して使いづらさを感じるケースがあったため、対面診療予約をより行いやすくするよう改修を行うなどです。 CLINICS デザイナー 酒井さん 新居 : 元々あったものをさらに患者とのタッチポイントを強化するために、改修・改善していったんですね。 プロジェクトの背景 どのくらいの規模のプロジェクトだったのか 新居 : 半年のプロジェクトということですが、規模としてはどの位の大きさだったんでしょうか? 酒井 : 私が経験したプロジェクトの中でも関わる部署など考えると一番大きかったと思います。開発はもちろんですが、CLINICS チームの セールス・カスタマーサクセス・マーケティング、広報もなのでほぼ CLINICS の全部署と関わっていました 。 田中 : 他にも、サービスとしては患者統合基盤・ 患者向けアプリ・ Dentis が関係しています。 宍戸 : QA チームにもしっかり入ってもらって QA を行なったりしてもらったので、本当に 医療プラットフォームのほぼ全てのチームと関わって開発していった 感じです。最終的にプロダクトの見せ方や売り方なども含めて調整していったので事業部とも密接に関わって作り上げていきました。 新しい PRM 機能をどうやって、プロダクトに融合させたのか 新居 : そこまで大きい規模のプロジェクトだということで、PRM の各種機能をどうやって上手くプロダクトに落としこむのか、実際にはどのようにみなさん推進されていったんでしょう。 宍戸 : プロジェクトの推進という意味では、最初は来田さんや( Dentis の運営を行なっている)プロダクト戦略室の平山さんと スモールスタートで意見を出し合いながらモックを作っていき、まずはビジュアル面から機能のイメージなどを刷り合わせ ていくのに、酒井さんに手を動かしてもらいながら進めていました。 その過程でこのプロジェクトにおける重要な意思決定がありました。CLINICS ではログイン不要のシンプルな予約機能を以前より提供していました。この機能は患者アプリとは元々違うドメインで運営していたものでしたが、今回のタイミングでこの両者のアプリケーションを患者アプリと同じドメインに統合して運営していこうという決定をしました。 患者アプリは CLINICS チームとは別チームで運営しているという背景もあり、チーム間の連携が格段に増え 、考えなければいけない事柄も多くなります。プロジェクトとして関係者が多くなってきたので、 今までの考え方を 1 度リセットしてプロジェクトの進め方を新しく模索する必要がありました 。 この点がかなり自分の中では大変でした。来田さんも大変だったと思います。こうした全体像を描いたり、全体スケジュールを決めたりというところでは、田中さんにアドバイスをもらいながらプロジェクトを進めていきました。 プロジェクトを推進するために必要だったこと 難しい意思決定をどのようにしていた? 新居 : 途中から一気にプロジェクトがスケールアップしたということなんですね。今回のプロジェクトは色々な部署も関わるし、たくさんの機能や改修が入っています。開発側と事業部側との意識合わせが、かなり必要だったんではないかと思うのですが、その辺はいかがだったでしょうか。 来田 : 例えば、今まで CLINICS では対面診療予約の際に患者のクレジットカード登録を必須としていたのですが、今回の改修でクレジットカード登録を不要に変更できるように対応を行いました。この対応は、CLINICS オンライン診療の初期から念願の機能だったりします。自分は事業部長である田中大介さんと今年の年明けくらいから話をして、メンバーに「よし、このプロジェクトをやっていこう」という話を持っていくようにしていました。やっぱり、大変なプロジェクトだというのはあったのでスタートを切れる状態に徐々にしていった感じです。 プロジェクトが佳境に入ってからは自分は各部署との調整がメインの業務でした。開発側と事業側とか CLINICS と Dentis だとかそういった立場の違いから来る要求の違いを納得できる仕様に落とし込む作業です。やっぱり、それぞれの立場でベストを尽くそうとみんな考えているんですが、全部を取り入れることはできないので。私が調整するときには それぞれ反対の立場の人たちの考えをきちんと伝えるようにということをしながら、仕様を決めていく ことを念頭に置いていました。 具体的な調整の例としては、開発する機能とセールスする際のプランの刷り合わせだったりですね。「機能としてはこうしたほうが使いやすいよね」というだけだと、セールス側としては「どこをウリにして売っていくのかというのが見えてこない」という話になったんですね。これはどちらの言い分も一理あるものなんですが、こういうところを時間をかけて 双方納得行くように決めていきました 。 CLINICS ディレクター・医師 来田さん 酒井 : この例でやったことは、まず現在のプランと機能を全部書き出して、組み合わせを整理するということでした。これをベースにして話を刷り合わせていったんですが、文字ベースだと人間分かった気になるんですが、実はそこまでピンと来ない。ですので、 LP のモックを作ってこれを見た顧客が導入したくなるようなウリになっているのかをすぐに判断できる状態 にしました。 宍戸 : こうしてちゃんと機能を解いていって細かい部分も含めて、時には CLINICS のコンセプトに立ち返って事業部・開発双方で時間をかけて認識を合わせることができたのは、大変でしたが良かったですね。 リリースまでのプロセスで顧客の声を反映 新居 : やはりここまでのプロジェクトだと最初の段階でちゃんとリリースまでを見据えた意識合わせをチーム内で行なっていたんですね。開発が進行していって、リリースするまではどのようにプロジェクトは進んでいったんでしょう。 宍戸 : リリースをする直前も、単純に仕様や機能について文書で説明しても理解するのは難しいので、酒井さんにディレクションをしてもらいながら、開発環境を使って QA チームやカスタマーサポートチームと一緒に認識合わせやリリースに向けた準備を行なっていきました。 来田 : あとは関係が構築できている 顧客に実際機能を見てもらって反応を伺う ということもしていきました。色々な使い方をしている顧客 10 件くらいにモックをベースにヒアリングをかけていきました。価格や導入時期なども含めた話を聞いていって、そこをすぐにプロジェクトにフィードバックする体制を構築していました。 酒井 : 実際に顧客の声をこうして聞けるというのは本当にプロダクトにとってありがたいことでした。特にこういう使い勝手などに直接関わる部分では、こうしたフィードバックの有無で完成度が違ってきます。 機能の正式リリース前から機能評価に協力していただける医療機関がいるのは、カスタマーサポートの皆さんが顧客と良好な関係を築けているおかげ だと思っています。こういった点はメドレーの強みだと思います。 プロジェクトで大切にしたこと 新居 : 開発段階からユーザーの声を吸い上げていけるのは、本当に良いですね。プロダクトの改善スピードなんかも段違いに早くなりそうです。他に大切にしていた部分などありますか? 酒井 : 今回の機能開発においては、プロジェクトの責任者として、開発以外のメンバーともしっかりコミュニケーションし合意形成を図ることを意識してプロジェクトを推進しました。 先ほどの話にも出ましたが 1 つの機能を実装するとなっても、実際の医療現場での使い勝手や、メドレーでのサポート、売り方など色々な視点で考えないといけないプロジェクトでした。そのため、そういったところをカスタマーサクセスのメンバー含む 10 人ほどと毎週 1 つ 1 つ納得がいくように詰めていくという作業をしていったりしました。 来田さんのように現役の医師の意見、顧客の意見なども取り入れられますし、カスタマーサポートには医療事務経験者の方もいらっしゃるので、多方面の視点を総合的に取り入れられるコミュニケーション を心がけていました。 手段はテキストや Figma でのデザイン、実際の実装を見せるなど適切な手段を選んでコミュニケーションコストを低くするようにして進行していました。 実際の機能実装にあたってはエンジニアも自身で考えて細かいボールを拾ったりしながら、実装 していってもらいました。この辺りはこのプロジェクトだからというよりも、メドレーの開発のベースになっている部分なので良いですよね。 メンバーのイメージ合わせがプロジェクト成功の鍵 新居 : 先ほどもお話がありましたが、プロジェクト途中の意思決定で関わるプロダクトが多くなったのでスイッチングが大変だったということでしたが、実際にそのタイミングになったときに全体のシステム設計なんかも変わったりしたんでしょうか。 田中 : 私はプロジェクトの途中から入ったんですが、そのタイミングで、宍戸さんや来田さんがちょうどシステム設計を考え直していたり、プロジェクト計画の引き直しをしているところでした。そこでまずは全体像を把握したいと考えてドキュメントなどを見せてもらったんです。各機能の細かい要件は分かったのですが、このプロジェクト全体としての各システムの責務や依存関係などがいまいち分かりづらく、メンバー間の認識も若干ズレが発生しているように感じました。なのでまずは**メンバーの認識を合わせ、各チームが何をするべきかを明確化するために、各システムの責務など全体感の整理整頓をして「見える化」**することから始めました。 このプロジェクトに限らずですが、プロジェクトとして抽象度の高い段階でのドキュメントは、文章のみの記載だと実は関係者にしっかりと伝わっていなかったということが多々あります。各自が頭の中でイメージした図に差異が発生している状態です。自分はそういう際に良く言っているのが**「大枠で良いので、まずは整理結果を図にしてみんなのイメージを合わせる**」ということです。こうして認識を合わせることで各チームが進めやすくなり後戻りリスクも軽減されるので、この段階でしっかりとイメージをすりあわせる事がとても重要だと考えています。 医療プラットフォーム CTO 田中さん 新居 : たしかにテキストで仕様なんかを書きながら説明しても、実は認識に齟齬があった…という経験があります。その後はどのようなプロセスでプロジェクト推進したんですか? 田中 : その後は各プロダクトにて実装予定の機能で、プロダクト間で共通化できそうな機能を共通サービスとして切り出すかどうかをみんなと考えていきました。結果として大きな機能では「ビデオ通話」部分を共通化するという意思決定をしました。他にも「問診票の提供」機能が候補としてあがっていましたが、共通化せずに各プロダクトの責務としてそれぞれ実装するという結論となりました。同じような機能に見えても、医科と歯科という業務ドメイン毎のコンテキスト差異を十分に検討した上での判断でした。 その差異がプロダクト機能としての強みとなり、安易な共通化はプロダクト成長の足枷となるリスクも存在 するためです。この判断も先ほどの全体の依存関係などが整理されたからこそ、意思決定できるものでした。 酒井 : 機能実装時に実感しましたが、やはり医科と歯科では細かい部分の要件などが異なる部分が多かったので、この段階で共通化の判断ができたのは大変助かりました。 PRM プロジェクトの大きな成果 新居 : 最後になりますが、このプロジェクトが終わっての成果はどのように考えていますか? 宍戸 : 冒頭に話した CLINICS の課題に関してはある程度、解決ができたと思います。 医療機関の業務に沿った形でプロダクトが進化 できた点はよかったと思います。特に問診周りなどは発熱外来などニーズの多様化に即して使い勝手が良くなったと思っています。 酒井 : 他にもビデオ通話部分など「オンライン診療」を提供するプロダクトとして「対面診療」だけではなく、もっと有用なプロダクトにできたかと思っています。 来田 : まだリリースしたばかりですが、初月の販売実績も期待していたよりも良く、そうした意味でも マーケットフィットした機能を出せたなという手応え が実感としてもありますね。 田中 : 予約やオンライン診療もドメインを統一した結果、会員登録数が増えていますので、そうした点も成果と言えます。 酒井 : あとは直接の成果というわけではないのですが、今回のプロジェクトの副産物として CLINICS の機能を整理整頓していった結果、 改めて「一気通貫で医療機関の業務をサポートできる」というトータルでの機能提供と各機能のシームレスな連携は CLINICS の強み だ、というのが再確認できたのは大きいです。 新居 : これからのさらなる CLINICS の発展に期待できますね!本日は長い時間お話ありがとうございました! おわりに メドレーとしてもかなり大規模なプロジェクトだった今回の PRM プロジェクトでしたが、みなさんのお話を聞いて各部署・各プロダクトで綿密に連携しながらプロジェクトを成功させようとしている様子が感じられるインタビューでした。 特にプロジェクト進行の話は非常に参考になりました。皆さんのご参考になる部分があれば幸いです。 こうしたプロジェクトで自分の力を発揮したい!と思った方はぜひお気軽に下記からご応募ください。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの新居です。クラウド診療支援システム CLINICS が 8 月から大幅に アップデート して、より患者と医療機関が密接に繋がるようになりました。 今回のアップデートで中心になっている機能領域として PRM(Patient Relationship Management) というものがあります。 この PRM が一体どういったものなのか、プロジェクトはどのように進んでいったのかを関係者にインタビューしていきました。 メドレーで大規模なプロジェクト開発をどのように行なっているかの一端をお見せできればと考えています! インタビュイー紹介 宍戸さん 医療プラットフォーム第一本部 プロダクト開発室第二グループに所属。クラウド診療支援システム CLINICS の開発責任者。前職は株式会社サイバーエージェントでサーバサイドエンジニアとして従事。2017 年メドレー入社。 酒井さん 医療プラットフォーム第一本部 プロダクト開発室第二グループに所属。クラウド診療支援システム CLINICS の UI/UX 全般を担当。本プロジェクトのリード。前職は受託開発会社で様々なサイトやシステムのデザインに従事。2019 年メドレー入社。 田中さん 医療プラットフォーム CTO。医療プラットフォームの開発統括をしながら、自身は患者統合基盤の開発を担当。前職までは SIer や IT コンサルタントを経て、株式会社サイバーエージェントでサーバサイドエンジニアとして従事。2016 年メドレー入社。 来田さん 前職まではクリニックで精神科医として従事。CLINCS オンライン診療の立ち上げ時から関わる。現在は CLINICS のディレクションを中心として事業部と開発の架け橋となっている。 PRM とはどういうものなのか? 新居 : では今回中心となった PRM とはいったい何なのかというところから解説していただいて良いですか? 一般的にはそこまで知られてない言葉なのではないかと思うのですが…。 宍戸 : 元々 CRM(Customer Relationship Management)というマーケティングなどの文脈の用語があります。これは「自社サービスや商品を使っている顧客」と「サービスや商品を提供している企業」との関係性を管理することを指しますが、それをもとに適切なアクションをおこなうことで最終的には利益向上を目指すものと考えられます。 PRM は CRM と同様に医療機関と患者さんの関係性を管理することで必要なサービスを提供する ためのもの、と考えています。 CLINICS で基幹システムである電子カルテなどではなく、 オンライン診療・予約・問診など患者接点となる機能をターゲットにしてそれらを強化・改善 していったのが、CLINICS の今回の PRM プロジェクトになります。 CLINICS 開発責任者 宍戸さん 新居 : 確かに CRM は最近良く聞く言葉でしたが、PRM は患者と医療サービスを使う医療機関との関係を深めるためのものなんですね。 PRM プロジェクトの始まり CLINICS に感じていた課題とは 新居 : このプロジェクトは半年ほどかけていると聞きましたが、「PRM をやっていこう」となったのが半年前からだったんでしょうか? 宍戸 : 元々 CLINICS はオンライン診療のシステムとして 2016 年からサービスを提供してきました。2018 年からは CLINICS カルテとして電子カルテシステムも提供を開始しましたが、そのタイミング以降はオンライン診療部分に関してはそこまで大きくアップデートはしてこなかったんです。 現在はクラウド診療支援システムとして販売していますが、これまでは電子カルテなど基幹部分の強化がメインになっていたからです。しかし、数年開発・運用してきた中で、本来医療機関の診察のメインである対面診療の予約については課題が積み残されていたり、昨今の状況から来る オンライン診療のニーズなどを始めとして、患者接点を強化していく必要がある ということになり、今回取り組むことになりました。 酒井 : PRM というと本当にここ最近の潮流なのですが、 CLINICS はもともと「患者とつながる」をコンセプト としており、今回の機能強化などもこのコンセプトに基づき実施しています。その上で、患者とのタッチポイントで抜けていた部分や強化したほうが良い部分をより作り込んでいったという形です。 例えば、CLINICS は元々オンライン診療のシステムとして始まっており、対面診療予約に関して使いづらさを感じるケースがあったため、対面診療予約をより行いやすくするよう改修を行うなどです。 CLINICS デザイナー 酒井さん 新居 : 元々あったものをさらに患者とのタッチポイントを強化するために、改修・改善していったんですね。 プロジェクトの背景 どのくらいの規模のプロジェクトだったのか 新居 : 半年のプロジェクトということですが、規模としてはどの位の大きさだったんでしょうか? 酒井 : 私が経験したプロジェクトの中でも関わる部署など考えると一番大きかったと思います。開発はもちろんですが、CLINICS チームの セールス・カスタマーサクセス・マーケティング、広報もなのでほぼ CLINICS の全部署と関わっていました 。 田中 : 他にも、サービスとしては患者統合基盤・ 患者向けアプリ・ Dentis が関係しています。 宍戸 : QA チームにもしっかり入ってもらって QA を行なったりしてもらったので、本当に 医療プラットフォームのほぼ全てのチームと関わって開発していった 感じです。最終的にプロダクトの見せ方や売り方なども含めて調整していったので事業部とも密接に関わって作り上げていきました。 新しい PRM 機能をどうやって、プロダクトに融合させたのか 新居 : そこまで大きい規模のプロジェクトだということで、PRM の各種機能をどうやって上手くプロダクトに落としこむのか、実際にはどのようにみなさん推進されていったんでしょう。 宍戸 : プロジェクトの推進という意味では、最初は来田さんや( Dentis の運営を行なっている)プロダクト戦略室の平山さんと スモールスタートで意見を出し合いながらモックを作っていき、まずはビジュアル面から機能のイメージなどを刷り合わせ ていくのに、酒井さんに手を動かしてもらいながら進めていました。 その過程でこのプロジェクトにおける重要な意思決定がありました。CLINICS ではログイン不要のシンプルな予約機能を以前より提供していました。この機能は患者アプリとは元々違うドメインで運営していたものでしたが、今回のタイミングでこの両者のアプリケーションを患者アプリと同じドメインに統合して運営していこうという決定をしました。 患者アプリは CLINICS チームとは別チームで運営しているという背景もあり、チーム間の連携が格段に増え 、考えなければいけない事柄も多くなります。プロジェクトとして関係者が多くなってきたので、 今までの考え方を 1 度リセットしてプロジェクトの進め方を新しく模索する必要がありました 。 この点がかなり自分の中では大変でした。来田さんも大変だったと思います。こうした全体像を描いたり、全体スケジュールを決めたりというところでは、田中さんにアドバイスをもらいながらプロジェクトを進めていきました。 プロジェクトを推進するために必要だったこと 難しい意思決定をどのようにしていた? 新居 : 途中から一気にプロジェクトがスケールアップしたということなんですね。今回のプロジェクトは色々な部署も関わるし、たくさんの機能や改修が入っています。開発側と事業部側との意識合わせが、かなり必要だったんではないかと思うのですが、その辺はいかがだったでしょうか。 来田 : 例えば、今まで CLINICS では対面診療予約の際に患者のクレジットカード登録を必須としていたのですが、今回の改修でクレジットカード登録を不要に変更できるように対応を行いました。この対応は、CLINICS オンライン診療の初期から念願の機能だったりします。自分は事業部長である田中大介さんと今年の年明けくらいから話をして、メンバーに「よし、このプロジェクトをやっていこう」という話を持っていくようにしていました。やっぱり、大変なプロジェクトだというのはあったのでスタートを切れる状態に徐々にしていった感じです。 プロジェクトが佳境に入ってからは自分は各部署との調整がメインの業務でした。開発側と事業側とか CLINICS と Dentis だとかそういった立場の違いから来る要求の違いを納得できる仕様に落とし込む作業です。やっぱり、それぞれの立場でベストを尽くそうとみんな考えているんですが、全部を取り入れることはできないので。私が調整するときには それぞれ反対の立場の人たちの考えをきちんと伝えるようにということをしながら、仕様を決めていく ことを念頭に置いていました。 具体的な調整の例としては、開発する機能とセールスする際のプランの刷り合わせだったりですね。「機能としてはこうしたほうが使いやすいよね」というだけだと、セールス側としては「どこをウリにして売っていくのかというのが見えてこない」という話になったんですね。これはどちらの言い分も一理あるものなんですが、こういうところを時間をかけて 双方納得行くように決めていきました 。 CLINICS ディレクター・医師 来田さん 酒井 : この例でやったことは、まず現在のプランと機能を全部書き出して、組み合わせを整理するということでした。これをベースにして話を刷り合わせていったんですが、文字ベースだと人間分かった気になるんですが、実はそこまでピンと来ない。ですので、 LP のモックを作ってこれを見た顧客が導入したくなるようなウリになっているのかをすぐに判断できる状態 にしました。 宍戸 : こうしてちゃんと機能を解いていって細かい部分も含めて、時には CLINICS のコンセプトに立ち返って事業部・開発双方で時間をかけて認識を合わせることができたのは、大変でしたが良かったですね。 リリースまでのプロセスで顧客の声を反映 新居 : やはりここまでのプロジェクトだと最初の段階でちゃんとリリースまでを見据えた意識合わせをチーム内で行なっていたんですね。開発が進行していって、リリースするまではどのようにプロジェクトは進んでいったんでしょう。 宍戸 : リリースをする直前も、単純に仕様や機能について文書で説明しても理解するのは難しいので、酒井さんにディレクションをしてもらいながら、開発環境を使って QA チームやカスタマーサポートチームと一緒に認識合わせやリリースに向けた準備を行なっていきました。 来田 : あとは関係が構築できている 顧客に実際機能を見てもらって反応を伺う ということもしていきました。色々な使い方をしている顧客 10 件くらいにモックをベースにヒアリングをかけていきました。価格や導入時期なども含めた話を聞いていって、そこをすぐにプロジェクトにフィードバックする体制を構築していました。 酒井 : 実際に顧客の声をこうして聞けるというのは本当にプロダクトにとってありがたいことでした。特にこういう使い勝手などに直接関わる部分では、こうしたフィードバックの有無で完成度が違ってきます。 機能の正式リリース前から機能評価に協力していただける医療機関がいるのは、カスタマーサポートの皆さんが顧客と良好な関係を築けているおかげ だと思っています。こういった点はメドレーの強みだと思います。 プロジェクトで大切にしたこと 新居 : 開発段階からユーザーの声を吸い上げていけるのは、本当に良いですね。プロダクトの改善スピードなんかも段違いに早くなりそうです。他に大切にしていた部分などありますか? 酒井 : 今回の機能開発においては、プロジェクトの責任者として、開発以外のメンバーともしっかりコミュニケーションし合意形成を図ることを意識してプロジェクトを推進しました。 先ほどの話にも出ましたが 1 つの機能を実装するとなっても、実際の医療現場での使い勝手や、メドレーでのサポート、売り方など色々な視点で考えないといけないプロジェクトでした。そのため、そういったところをカスタマーサクセスのメンバー含む 10 人ほどと毎週 1 つ 1 つ納得がいくように詰めていくという作業をしていったりしました。 来田さんのように現役の医師の意見、顧客の意見なども取り入れられますし、カスタマーサポートには医療事務経験者の方もいらっしゃるので、多方面の視点を総合的に取り入れられるコミュニケーション を心がけていました。 手段はテキストや Figma でのデザイン、実際の実装を見せるなど適切な手段を選んでコミュニケーションコストを低くするようにして進行していました。 実際の機能実装にあたってはエンジニアも自身で考えて細かいボールを拾ったりしながら、実装 していってもらいました。この辺りはこのプロジェクトだからというよりも、メドレーの開発のベースになっている部分なので良いですよね。 メンバーのイメージ合わせがプロジェクト成功の鍵 新居 : 先ほどもお話がありましたが、プロジェクト途中の意思決定で関わるプロダクトが多くなったのでスイッチングが大変だったということでしたが、実際にそのタイミングになったときに全体のシステム設計なんかも変わったりしたんでしょうか。 田中 : 私はプロジェクトの途中から入ったんですが、そのタイミングで、宍戸さんや来田さんがちょうどシステム設計を考え直していたり、プロジェクト計画の引き直しをしているところでした。そこでまずは全体像を把握したいと考えてドキュメントなどを見せてもらったんです。各機能の細かい要件は分かったのですが、このプロジェクト全体としての各システムの責務や依存関係などがいまいち分かりづらく、メンバー間の認識も若干ズレが発生しているように感じました。なのでまずは**メンバーの認識を合わせ、各チームが何をするべきかを明確化するために、各システムの責務など全体感の整理整頓をして「見える化」**することから始めました。 このプロジェクトに限らずですが、プロジェクトとして抽象度の高い段階でのドキュメントは、文章のみの記載だと実は関係者にしっかりと伝わっていなかったということが多々あります。各自が頭の中でイメージした図に差異が発生している状態です。自分はそういう際に良く言っているのが**「大枠で良いので、まずは整理結果を図にしてみんなのイメージを合わせる**」ということです。こうして認識を合わせることで各チームが進めやすくなり後戻りリスクも軽減されるので、この段階でしっかりとイメージをすりあわせる事がとても重要だと考えています。 医療プラットフォーム CTO 田中さん 新居 : たしかにテキストで仕様なんかを書きながら説明しても、実は認識に齟齬があった…という経験があります。その後はどのようなプロセスでプロジェクト推進したんですか? 田中 : その後は各プロダクトにて実装予定の機能で、プロダクト間で共通化できそうな機能を共通サービスとして切り出すかどうかをみんなと考えていきました。結果として大きな機能では「ビデオ通話」部分を共通化するという意思決定をしました。他にも「問診票の提供」機能が候補としてあがっていましたが、共通化せずに各プロダクトの責務としてそれぞれ実装するという結論となりました。同じような機能に見えても、医科と歯科という業務ドメイン毎のコンテキスト差異を十分に検討した上での判断でした。 その差異がプロダクト機能としての強みとなり、安易な共通化はプロダクト成長の足枷となるリスクも存在 するためです。この判断も先ほどの全体の依存関係などが整理されたからこそ、意思決定できるものでした。 酒井 : 機能実装時に実感しましたが、やはり医科と歯科では細かい部分の要件などが異なる部分が多かったので、この段階で共通化の判断ができたのは大変助かりました。 PRM プロジェクトの大きな成果 新居 : 最後になりますが、このプロジェクトが終わっての成果はどのように考えていますか? 宍戸 : 冒頭に話した CLINICS の課題に関してはある程度、解決ができたと思います。 医療機関の業務に沿った形でプロダクトが進化 できた点はよかったと思います。特に問診周りなどは発熱外来などニーズの多様化に即して使い勝手が良くなったと思っています。 酒井 : 他にもビデオ通話部分など「オンライン診療」を提供するプロダクトとして「対面診療」だけではなく、もっと有用なプロダクトにできたかと思っています。 来田 : まだリリースしたばかりですが、初月の販売実績も期待していたよりも良く、そうした意味でも マーケットフィットした機能を出せたなという手応え が実感としてもありますね。 田中 : 予約やオンライン診療もドメインを統一した結果、会員登録数が増えていますので、そうした点も成果と言えます。 酒井 : あとは直接の成果というわけではないのですが、今回のプロジェクトの副産物として CLINICS の機能を整理整頓していった結果、 改めて「一気通貫で医療機関の業務をサポートできる」というトータルでの機能提供と各機能のシームレスな連携は CLINICS の強み だ、というのが再確認できたのは大きいです。 新居 : これからのさらなる CLINICS の発展に期待できますね!本日は長い時間お話ありがとうございました! おわりに メドレーとしてもかなり大規模なプロジェクトだった今回の PRM プロジェクトでしたが、みなさんのお話を聞いて各部署・各プロダクトで綿密に連携しながらプロジェクトを成功させようとしている様子が感じられるインタビューでした。 特にプロジェクト進行の話は非常に参考になりました。皆さんのご参考になる部分があれば幸いです。 こうしたプロジェクトで自分の力を発揮したい!と思った方はぜひお気軽に下記からご応募ください。 https://www.medley.jp/jobs/

はじめに みなさん、こんにちは。エンジニアの新居です。クラウド診療支援システム CLINICS が 8 月から大幅に アップデート して、より患者と医療機関が密接に繋がるようになりました。 今回のアップデートで中心になっている機能領域として PRM(Patient Relationship Management) というものがあります。 この PRM が一体どういったものなのか、プロジェクトはどのように進んでいったのかを関係者にインタビューしていきました。 メドレーで大規模なプロジェクト開発をどのように行なっているかの一端をお見せできればと考えています! インタビュイー紹介 宍戸さん 医療プラットフォーム第一本部 プロダクト開発室第二グループに所属。クラウド診療支援システム CLINICS の開発責任者。前職は株式会社サイバーエージェントでサーバサイドエンジニアとして従事。2017 年メドレー入社。 酒井さん 医療プラットフォーム第一本部 プロダクト開発室第二グループに所属。クラウド診療支援システム CLINICS の UI/UX 全般を担当。本プロジェクトのリード。前職は受託開発会社で様々なサイトやシステムのデザインに従事。2019 年メドレー入社。 田中さん 医療プラットフォーム CTO。医療プラットフォームの開発統括をしながら、自身は患者統合基盤の開発を担当。前職までは SIer や IT コンサルタントを経て、株式会社サイバーエージェントでサーバサイドエンジニアとして従事。2016 年メドレー入社。 来田さん 前職まではクリニックで精神科医として従事。CLINCS オンライン診療の立ち上げ時から関わる。現在は CLINICS のディレクションを中心として事業部と開発の架け橋となっている。 PRM とはどういうものなのか? 新居 : では今回中心となった PRM とはいったい何なのかというところから解説していただいて良いですか? 一般的にはそこまで知られてない言葉なのではないかと思うのですが…。 宍戸 : 元々 CRM(Customer Relationship Management)というマーケティングなどの文脈の用語があります。これは「自社サービスや商品を使っている顧客」と「サービスや商品を提供している企業」との関係性を管理することを指しますが、それをもとに適切なアクションをおこなうことで最終的には利益向上を目指すものと考えられます。 PRM は CRM と同様に医療機関と患者さんの関係性を管理することで必要なサービスを提供する ためのもの、と考えています。 CLINICS で基幹システムである電子カルテなどではなく、 オンライン診療・予約・問診など患者接点となる機能をターゲットにしてそれらを強化・改善 していったのが、CLINICS の今回の PRM プロジェクトになります。 CLINICS 開発責任者 宍戸さん 新居 : 確かに CRM は最近良く聞く言葉でしたが、PRM は患者と医療サービスを使う医療機関との関係を深めるためのものなんですね。 PRM プロジェクトの始まり CLINICS に感じていた課題とは 新居 : このプロジェクトは半年ほどかけていると聞きましたが、「PRM をやっていこう」となったのが半年前からだったんでしょうか? 宍戸 : 元々 CLINICS はオンライン診療のシステムとして 2016 年からサービスを提供してきました。2018 年からは CLINICS カルテとして電子カルテシステムも提供を開始しましたが、そのタイミング以降はオンライン診療部分に関してはそこまで大きくアップデートはしてこなかったんです。 現在はクラウド診療支援システムとして販売していますが、これまでは電子カルテなど基幹部分の強化がメインになっていたからです。しかし、数年開発・運用してきた中で、本来医療機関の診察のメインである対面診療の予約については課題が積み残されていたり、昨今の状況から来る オンライン診療のニーズなどを始めとして、患者接点を強化していく必要がある ということになり、今回取り組むことになりました。 酒井 : PRM というと本当にここ最近の潮流なのですが、 CLINICS はもともと「患者とつながる」をコンセプト としており、今回の機能強化などもこのコンセプトに基づき実施しています。その上で、患者とのタッチポイントで抜けていた部分や強化したほうが良い部分をより作り込んでいったという形です。 例えば、CLINICS は元々オンライン診療のシステムとして始まっており、対面診療予約に関して使いづらさを感じるケースがあったため、対面診療予約をより行いやすくするよう改修を行うなどです。 CLINICS デザイナー 酒井さん 新居 : 元々あったものをさらに患者とのタッチポイントを強化するために、改修・改善していったんですね。 プロジェクトの背景 どのくらいの規模のプロジェクトだったのか 新居 : 半年のプロジェクトということですが、規模としてはどの位の大きさだったんでしょうか? 酒井 : 私が経験したプロジェクトの中でも関わる部署など考えると一番大きかったと思います。開発はもちろんですが、CLINICS チームの セールス・カスタマーサクセス・マーケティング、広報もなのでほぼ CLINICS の全部署と関わっていました 。 田中 : 他にも、サービスとしては患者統合基盤・ 患者向けアプリ・ Dentis が関係しています。 宍戸 : QA チームにもしっかり入ってもらって QA を行なったりしてもらったので、本当に 医療プラットフォームのほぼ全てのチームと関わって開発していった 感じです。最終的にプロダクトの見せ方や売り方なども含めて調整していったので事業部とも密接に関わって作り上げていきました。 新しい PRM 機能をどうやって、プロダクトに融合させたのか 新居 : そこまで大きい規模のプロジェクトだということで、PRM の各種機能をどうやって上手くプロダクトに落としこむのか、実際にはどのようにみなさん推進されていったんでしょう。 宍戸 : プロジェクトの推進という意味では、最初は来田さんや( Dentis の運営を行なっている)プロダクト戦略室の平山さんと スモールスタートで意見を出し合いながらモックを作っていき、まずはビジュアル面から機能のイメージなどを刷り合わせ ていくのに、酒井さんに手を動かしてもらいながら進めていました。 その過程でこのプロジェクトにおける重要な意思決定がありました。CLINICS ではログイン不要のシンプルな予約機能を以前より提供していました。この機能は患者アプリとは元々違うドメインで運営していたものでしたが、今回のタイミングでこの両者のアプリケーションを患者アプリと同じドメインに統合して運営していこうという決定をしました。 患者アプリは CLINICS チームとは別チームで運営しているという背景もあり、チーム間の連携が格段に増え 、考えなければいけない事柄も多くなります。プロジェクトとして関係者が多くなってきたので、 今までの考え方を 1 度リセットしてプロジェクトの進め方を新しく模索する必要がありました 。 この点がかなり自分の中では大変でした。来田さんも大変だったと思います。こうした全体像を描いたり、全体スケジュールを決めたりというところでは、田中さんにアドバイスをもらいながらプロジェクトを進めていきました。 プロジェクトを推進するために必要だったこと 難しい意思決定をどのようにしていた? 新居 : 途中から一気にプロジェクトがスケールアップしたということなんですね。今回のプロジェクトは色々な部署も関わるし、たくさんの機能や改修が入っています。開発側と事業部側との意識合わせが、かなり必要だったんではないかと思うのですが、その辺はいかがだったでしょうか。 来田 : 例えば、今まで CLINICS では対面診療予約の際に患者のクレジットカード登録を必須としていたのですが、今回の改修でクレジットカード登録を不要に変更できるように対応を行いました。この対応は、CLINICS オンライン診療の初期から念願の機能だったりします。自分は事業部長である田中大介さんと今年の年明けくらいから話をして、メンバーに「よし、このプロジェクトをやっていこう」という話を持っていくようにしていました。やっぱり、大変なプロジェクトだというのはあったのでスタートを切れる状態に徐々にしていった感じです。 プロジェクトが佳境に入ってからは自分は各部署との調整がメインの業務でした。開発側と事業側とか CLINICS と Dentis だとかそういった立場の違いから来る要求の違いを納得できる仕様に落とし込む作業です。やっぱり、それぞれの立場でベストを尽くそうとみんな考えているんですが、全部を取り入れることはできないので。私が調整するときには それぞれ反対の立場の人たちの考えをきちんと伝えるようにということをしながら、仕様を決めていく ことを念頭に置いていました。 具体的な調整の例としては、開発する機能とセールスする際のプランの刷り合わせだったりですね。「機能としてはこうしたほうが使いやすいよね」というだけだと、セールス側としては「どこをウリにして売っていくのかというのが見えてこない」という話になったんですね。これはどちらの言い分も一理あるものなんですが、こういうところを時間をかけて 双方納得行くように決めていきました 。 CLINICS ディレクター・医師 来田さん 酒井 : この例でやったことは、まず現在のプランと機能を全部書き出して、組み合わせを整理するということでした。これをベースにして話を刷り合わせていったんですが、文字ベースだと人間分かった気になるんですが、実はそこまでピンと来ない。ですので、 LP のモックを作ってこれを見た顧客が導入したくなるようなウリになっているのかをすぐに判断できる状態 にしました。 宍戸 : こうしてちゃんと機能を解いていって細かい部分も含めて、時には CLINICS のコンセプトに立ち返って事業部・開発双方で時間をかけて認識を合わせることができたのは、大変でしたが良かったですね。 リリースまでのプロセスで顧客の声を反映 新居 : やはりここまでのプロジェクトだと最初の段階でちゃんとリリースまでを見据えた意識合わせをチーム内で行なっていたんですね。開発が進行していって、リリースするまではどのようにプロジェクトは進んでいったんでしょう。 宍戸 : リリースをする直前も、単純に仕様や機能について文書で説明しても理解するのは難しいので、酒井さんにディレクションをしてもらいながら、開発環境を使って QA チームやカスタマーサポートチームと一緒に認識合わせやリリースに向けた準備を行なっていきました。 来田 : あとは関係が構築できている 顧客に実際機能を見てもらって反応を伺う ということもしていきました。色々な使い方をしている顧客 10 件くらいにモックをベースにヒアリングをかけていきました。価格や導入時期なども含めた話を聞いていって、そこをすぐにプロジェクトにフィードバックする体制を構築していました。 酒井 : 実際に顧客の声をこうして聞けるというのは本当にプロダクトにとってありがたいことでした。特にこういう使い勝手などに直接関わる部分では、こうしたフィードバックの有無で完成度が違ってきます。 機能の正式リリース前から機能評価に協力していただける医療機関がいるのは、カスタマーサポートの皆さんが顧客と良好な関係を築けているおかげ だと思っています。こういった点はメドレーの強みだと思います。 プロジェクトで大切にしたこと 新居 : 開発段階からユーザーの声を吸い上げていけるのは、本当に良いですね。プロダクトの改善スピードなんかも段違いに早くなりそうです。他に大切にしていた部分などありますか? 酒井 : 今回の機能開発においては、プロジェクトの責任者として、開発以外のメンバーともしっかりコミュニケーションし合意形成を図ることを意識してプロジェクトを推進しました。 先ほどの話にも出ましたが 1 つの機能を実装するとなっても、実際の医療現場での使い勝手や、メドレーでのサポート、売り方など色々な視点で考えないといけないプロジェクトでした。そのため、そういったところをカスタマーサクセスのメンバー含む 10 人ほどと毎週 1 つ 1 つ納得がいくように詰めていくという作業をしていったりしました。 来田さんのように現役の医師の意見、顧客の意見なども取り入れられますし、カスタマーサポートには医療事務経験者の方もいらっしゃるので、多方面の視点を総合的に取り入れられるコミュニケーション を心がけていました。 手段はテキストや Figma でのデザイン、実際の実装を見せるなど適切な手段を選んでコミュニケーションコストを低くするようにして進行していました。 実際の機能実装にあたってはエンジニアも自身で考えて細かいボールを拾ったりしながら、実装 していってもらいました。この辺りはこのプロジェクトだからというよりも、メドレーの開発のベースになっている部分なので良いですよね。 メンバーのイメージ合わせがプロジェクト成功の鍵 新居 : 先ほどもお話がありましたが、プロジェクト途中の意思決定で関わるプロダクトが多くなったのでスイッチングが大変だったということでしたが、実際にそのタイミングになったときに全体のシステム設計なんかも変わったりしたんでしょうか。 田中 : 私はプロジェクトの途中から入ったんですが、そのタイミングで、宍戸さんや来田さんがちょうどシステム設計を考え直していたり、プロジェクト計画の引き直しをしているところでした。そこでまずは全体像を把握したいと考えてドキュメントなどを見せてもらったんです。各機能の細かい要件は分かったのですが、このプロジェクト全体としての各システムの責務や依存関係などがいまいち分かりづらく、メンバー間の認識も若干ズレが発生しているように感じました。なのでまずは**メンバーの認識を合わせ、各チームが何をするべきかを明確化するために、各システムの責務など全体感の整理整頓をして「見える化」**することから始めました。 このプロジェクトに限らずですが、プロジェクトとして抽象度の高い段階でのドキュメントは、文章のみの記載だと実は関係者にしっかりと伝わっていなかったということが多々あります。各自が頭の中でイメージした図に差異が発生している状態です。自分はそういう際に良く言っているのが**「大枠で良いので、まずは整理結果を図にしてみんなのイメージを合わせる**」ということです。こうして認識を合わせることで各チームが進めやすくなり後戻りリスクも軽減されるので、この段階でしっかりとイメージをすりあわせる事がとても重要だと考えています。 医療プラットフォーム CTO 田中さん 新居 : たしかにテキストで仕様なんかを書きながら説明しても、実は認識に齟齬があった…という経験があります。その後はどのようなプロセスでプロジェクト推進したんですか? 田中 : その後は各プロダクトにて実装予定の機能で、プロダクト間で共通化できそうな機能を共通サービスとして切り出すかどうかをみんなと考えていきました。結果として大きな機能では「ビデオ通話」部分を共通化するという意思決定をしました。他にも「問診票の提供」機能が候補としてあがっていましたが、共通化せずに各プロダクトの責務としてそれぞれ実装するという結論となりました。同じような機能に見えても、医科と歯科という業務ドメイン毎のコンテキスト差異を十分に検討した上での判断でした。 その差異がプロダクト機能としての強みとなり、安易な共通化はプロダクト成長の足枷となるリスクも存在 するためです。この判断も先ほどの全体の依存関係などが整理されたからこそ、意思決定できるものでした。 酒井 : 機能実装時に実感しましたが、やはり医科と歯科では細かい部分の要件などが異なる部分が多かったので、この段階で共通化の判断ができたのは大変助かりました。 PRM プロジェクトの大きな成果 新居 : 最後になりますが、このプロジェクトが終わっての成果はどのように考えていますか? 宍戸 : 冒頭に話した CLINICS の課題に関してはある程度、解決ができたと思います。 医療機関の業務に沿った形でプロダクトが進化 できた点はよかったと思います。特に問診周りなどは発熱外来などニーズの多様化に即して使い勝手が良くなったと思っています。 酒井 : 他にもビデオ通話部分など「オンライン診療」を提供するプロダクトとして「対面診療」だけではなく、もっと有用なプロダクトにできたかと思っています。 来田 : まだリリースしたばかりですが、初月の販売実績も期待していたよりも良く、そうした意味でも マーケットフィットした機能を出せたなという手応え が実感としてもありますね。 田中 : 予約やオンライン診療もドメインを統一した結果、会員登録数が増えていますので、そうした点も成果と言えます。 酒井 : あとは直接の成果というわけではないのですが、今回のプロジェクトの副産物として CLINICS の機能を整理整頓していった結果、 改めて「一気通貫で医療機関の業務をサポートできる」というトータルでの機能提供と各機能のシームレスな連携は CLINICS の強み だ、というのが再確認できたのは大きいです。 新居 : これからのさらなる CLINICS の発展に期待できますね!本日は長い時間お話ありがとうございました! おわりに メドレーとしてもかなり大規模なプロジェクトだった今回の PRM プロジェクトでしたが、みなさんのお話を聞いて各部署・各プロダクトで綿密に連携しながらプロジェクトを成功させようとしている様子が感じられるインタビューでした。 特にプロジェクト進行の話は非常に参考になりました。皆さんのご参考になる部分があれば幸いです。 こうしたプロジェクトで自分の力を発揮したい!と思った方はぜひお気軽に下記からご応募ください。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの新居です。クラウド診療支援システム CLINICS が 8 月から大幅に アップデート して、より患者と医療機関が密接に繋がるようになりました。 今回のアップデートで中心になっている機能領域として PRM(Patient Relationship Management) というものがあります。 この PRM が一体どういったものなのか、プロジェクトはどのように進んでいったのかを関係者にインタビューしていきました。 メドレーで大規模なプロジェクト開発をどのように行なっているかの一端をお見せできればと考えています! インタビュイー紹介 宍戸さん 医療プラットフォーム第一本部 プロダクト開発室第二グループに所属。クラウド診療支援システム CLINICS の開発責任者。前職は株式会社サイバーエージェントでサーバサイドエンジニアとして従事。2017 年メドレー入社。 酒井さん 医療プラットフォーム第一本部 プロダクト開発室第二グループに所属。クラウド診療支援システム CLINICS の UI/UX 全般を担当。本プロジェクトのリード。前職は受託開発会社で様々なサイトやシステムのデザインに従事。2019 年メドレー入社。 田中さん 医療プラットフォーム CTO。医療プラットフォームの開発統括をしながら、自身は患者統合基盤の開発を担当。前職までは SIer や IT コンサルタントを経て、株式会社サイバーエージェントでサーバサイドエンジニアとして従事。2016 年メドレー入社。 来田さん 前職まではクリニックで精神科医として従事。CLINCS オンライン診療の立ち上げ時から関わる。現在は CLINICS のディレクションを中心として事業部と開発の架け橋となっている。 PRM とはどういうものなのか? 新居 : では今回中心となった PRM とはいったい何なのかというところから解説していただいて良いですか? 一般的にはそこまで知られてない言葉なのではないかと思うのですが…。 宍戸 : 元々 CRM(Customer Relationship Management)というマーケティングなどの文脈の用語があります。これは「自社サービスや商品を使っている顧客」と「サービスや商品を提供している企業」との関係性を管理することを指しますが、それをもとに適切なアクションをおこなうことで最終的には利益向上を目指すものと考えられます。 PRM は CRM と同様に医療機関と患者さんの関係性を管理することで必要なサービスを提供する ためのもの、と考えています。 CLINICS で基幹システムである電子カルテなどではなく、 オンライン診療・予約・問診など患者接点となる機能をターゲットにしてそれらを強化・改善 していったのが、CLINICS の今回の PRM プロジェクトになります。 CLINICS 開発責任者 宍戸さん 新居 : 確かに CRM は最近良く聞く言葉でしたが、PRM は患者と医療サービスを使う医療機関との関係を深めるためのものなんですね。 PRM プロジェクトの始まり CLINICS に感じていた課題とは 新居 : このプロジェクトは半年ほどかけていると聞きましたが、「PRM をやっていこう」となったのが半年前からだったんでしょうか? 宍戸 : 元々 CLINICS はオンライン診療のシステムとして 2016 年からサービスを提供してきました。2018 年からは CLINICS カルテとして電子カルテシステムも提供を開始しましたが、そのタイミング以降はオンライン診療部分に関してはそこまで大きくアップデートはしてこなかったんです。 現在はクラウド診療支援システムとして販売していますが、これまでは電子カルテなど基幹部分の強化がメインになっていたからです。しかし、数年開発・運用してきた中で、本来医療機関の診察のメインである対面診療の予約については課題が積み残されていたり、昨今の状況から来る オンライン診療のニーズなどを始めとして、患者接点を強化していく必要がある ということになり、今回取り組むことになりました。 酒井 : PRM というと本当にここ最近の潮流なのですが、 CLINICS はもともと「患者とつながる」をコンセプト としており、今回の機能強化などもこのコンセプトに基づき実施しています。その上で、患者とのタッチポイントで抜けていた部分や強化したほうが良い部分をより作り込んでいったという形です。 例えば、CLINICS は元々オンライン診療のシステムとして始まっており、対面診療予約に関して使いづらさを感じるケースがあったため、対面診療予約をより行いやすくするよう改修を行うなどです。 CLINICS デザイナー 酒井さん 新居 : 元々あったものをさらに患者とのタッチポイントを強化するために、改修・改善していったんですね。 プロジェクトの背景 どのくらいの規模のプロジェクトだったのか 新居 : 半年のプロジェクトということですが、規模としてはどの位の大きさだったんでしょうか? 酒井 : 私が経験したプロジェクトの中でも関わる部署など考えると一番大きかったと思います。開発はもちろんですが、CLINICS チームの セールス・カスタマーサクセス・マーケティング、広報もなのでほぼ CLINICS の全部署と関わっていました 。 田中 : 他にも、サービスとしては患者統合基盤・ 患者向けアプリ・ Dentis が関係しています。 宍戸 : QA チームにもしっかり入ってもらって QA を行なったりしてもらったので、本当に 医療プラットフォームのほぼ全てのチームと関わって開発していった 感じです。最終的にプロダクトの見せ方や売り方なども含めて調整していったので事業部とも密接に関わって作り上げていきました。 新しい PRM 機能をどうやって、プロダクトに融合させたのか 新居 : そこまで大きい規模のプロジェクトだということで、PRM の各種機能をどうやって上手くプロダクトに落としこむのか、実際にはどのようにみなさん推進されていったんでしょう。 宍戸 : プロジェクトの推進という意味では、最初は来田さんや( Dentis の運営を行なっている)プロダクト戦略室の平山さんと スモールスタートで意見を出し合いながらモックを作っていき、まずはビジュアル面から機能のイメージなどを刷り合わせ ていくのに、酒井さんに手を動かしてもらいながら進めていました。 その過程でこのプロジェクトにおける重要な意思決定がありました。CLINICS ではログイン不要のシンプルな予約機能を以前より提供していました。この機能は患者アプリとは元々違うドメインで運営していたものでしたが、今回のタイミングでこの両者のアプリケーションを患者アプリと同じドメインに統合して運営していこうという決定をしました。 患者アプリは CLINICS チームとは別チームで運営しているという背景もあり、チーム間の連携が格段に増え 、考えなければいけない事柄も多くなります。プロジェクトとして関係者が多くなってきたので、 今までの考え方を 1 度リセットしてプロジェクトの進め方を新しく模索する必要がありました 。 この点がかなり自分の中では大変でした。来田さんも大変だったと思います。こうした全体像を描いたり、全体スケジュールを決めたりというところでは、田中さんにアドバイスをもらいながらプロジェクトを進めていきました。 プロジェクトを推進するために必要だったこと 難しい意思決定をどのようにしていた? 新居 : 途中から一気にプロジェクトがスケールアップしたということなんですね。今回のプロジェクトは色々な部署も関わるし、たくさんの機能や改修が入っています。開発側と事業部側との意識合わせが、かなり必要だったんではないかと思うのですが、その辺はいかがだったでしょうか。 来田 : 例えば、今まで CLINICS では対面診療予約の際に患者のクレジットカード登録を必須としていたのですが、今回の改修でクレジットカード登録を不要に変更できるように対応を行いました。この対応は、CLINICS オンライン診療の初期から念願の機能だったりします。自分は事業部長である田中大介さんと今年の年明けくらいから話をして、メンバーに「よし、このプロジェクトをやっていこう」という話を持っていくようにしていました。やっぱり、大変なプロジェクトだというのはあったのでスタートを切れる状態に徐々にしていった感じです。 プロジェクトが佳境に入ってからは自分は各部署との調整がメインの業務でした。開発側と事業側とか CLINICS と Dentis だとかそういった立場の違いから来る要求の違いを納得できる仕様に落とし込む作業です。やっぱり、それぞれの立場でベストを尽くそうとみんな考えているんですが、全部を取り入れることはできないので。私が調整するときには それぞれ反対の立場の人たちの考えをきちんと伝えるようにということをしながら、仕様を決めていく ことを念頭に置いていました。 具体的な調整の例としては、開発する機能とセールスする際のプランの刷り合わせだったりですね。「機能としてはこうしたほうが使いやすいよね」というだけだと、セールス側としては「どこをウリにして売っていくのかというのが見えてこない」という話になったんですね。これはどちらの言い分も一理あるものなんですが、こういうところを時間をかけて 双方納得行くように決めていきました 。 CLINICS ディレクター・医師 来田さん 酒井 : この例でやったことは、まず現在のプランと機能を全部書き出して、組み合わせを整理するということでした。これをベースにして話を刷り合わせていったんですが、文字ベースだと人間分かった気になるんですが、実はそこまでピンと来ない。ですので、 LP のモックを作ってこれを見た顧客が導入したくなるようなウリになっているのかをすぐに判断できる状態 にしました。 宍戸 : こうしてちゃんと機能を解いていって細かい部分も含めて、時には CLINICS のコンセプトに立ち返って事業部・開発双方で時間をかけて認識を合わせることができたのは、大変でしたが良かったですね。 リリースまでのプロセスで顧客の声を反映 新居 : やはりここまでのプロジェクトだと最初の段階でちゃんとリリースまでを見据えた意識合わせをチーム内で行なっていたんですね。開発が進行していって、リリースするまではどのようにプロジェクトは進んでいったんでしょう。 宍戸 : リリースをする直前も、単純に仕様や機能について文書で説明しても理解するのは難しいので、酒井さんにディレクションをしてもらいながら、開発環境を使って QA チームやカスタマーサポートチームと一緒に認識合わせやリリースに向けた準備を行なっていきました。 来田 : あとは関係が構築できている 顧客に実際機能を見てもらって反応を伺う ということもしていきました。色々な使い方をしている顧客 10 件くらいにモックをベースにヒアリングをかけていきました。価格や導入時期なども含めた話を聞いていって、そこをすぐにプロジェクトにフィードバックする体制を構築していました。 酒井 : 実際に顧客の声をこうして聞けるというのは本当にプロダクトにとってありがたいことでした。特にこういう使い勝手などに直接関わる部分では、こうしたフィードバックの有無で完成度が違ってきます。 機能の正式リリース前から機能評価に協力していただける医療機関がいるのは、カスタマーサポートの皆さんが顧客と良好な関係を築けているおかげ だと思っています。こういった点はメドレーの強みだと思います。 プロジェクトで大切にしたこと 新居 : 開発段階からユーザーの声を吸い上げていけるのは、本当に良いですね。プロダクトの改善スピードなんかも段違いに早くなりそうです。他に大切にしていた部分などありますか? 酒井 : 今回の機能開発においては、プロジェクトの責任者として、開発以外のメンバーともしっかりコミュニケーションし合意形成を図ることを意識してプロジェクトを推進しました。 先ほどの話にも出ましたが 1 つの機能を実装するとなっても、実際の医療現場での使い勝手や、メドレーでのサポート、売り方など色々な視点で考えないといけないプロジェクトでした。そのため、そういったところをカスタマーサクセスのメンバー含む 10 人ほどと毎週 1 つ 1 つ納得がいくように詰めていくという作業をしていったりしました。 来田さんのように現役の医師の意見、顧客の意見なども取り入れられますし、カスタマーサポートには医療事務経験者の方もいらっしゃるので、多方面の視点を総合的に取り入れられるコミュニケーション を心がけていました。 手段はテキストや Figma でのデザイン、実際の実装を見せるなど適切な手段を選んでコミュニケーションコストを低くするようにして進行していました。 実際の機能実装にあたってはエンジニアも自身で考えて細かいボールを拾ったりしながら、実装 していってもらいました。この辺りはこのプロジェクトだからというよりも、メドレーの開発のベースになっている部分なので良いですよね。 メンバーのイメージ合わせがプロジェクト成功の鍵 新居 : 先ほどもお話がありましたが、プロジェクト途中の意思決定で関わるプロダクトが多くなったのでスイッチングが大変だったということでしたが、実際にそのタイミングになったときに全体のシステム設計なんかも変わったりしたんでしょうか。 田中 : 私はプロジェクトの途中から入ったんですが、そのタイミングで、宍戸さんや来田さんがちょうどシステム設計を考え直していたり、プロジェクト計画の引き直しをしているところでした。そこでまずは全体像を把握したいと考えてドキュメントなどを見せてもらったんです。各機能の細かい要件は分かったのですが、このプロジェクト全体としての各システムの責務や依存関係などがいまいち分かりづらく、メンバー間の認識も若干ズレが発生しているように感じました。なのでまずは**メンバーの認識を合わせ、各チームが何をするべきかを明確化するために、各システムの責務など全体感の整理整頓をして「見える化」**することから始めました。 このプロジェクトに限らずですが、プロジェクトとして抽象度の高い段階でのドキュメントは、文章のみの記載だと実は関係者にしっかりと伝わっていなかったということが多々あります。各自が頭の中でイメージした図に差異が発生している状態です。自分はそういう際に良く言っているのが**「大枠で良いので、まずは整理結果を図にしてみんなのイメージを合わせる**」ということです。こうして認識を合わせることで各チームが進めやすくなり後戻りリスクも軽減されるので、この段階でしっかりとイメージをすりあわせる事がとても重要だと考えています。 医療プラットフォーム CTO 田中さん 新居 : たしかにテキストで仕様なんかを書きながら説明しても、実は認識に齟齬があった…という経験があります。その後はどのようなプロセスでプロジェクト推進したんですか? 田中 : その後は各プロダクトにて実装予定の機能で、プロダクト間で共通化できそうな機能を共通サービスとして切り出すかどうかをみんなと考えていきました。結果として大きな機能では「ビデオ通話」部分を共通化するという意思決定をしました。他にも「問診票の提供」機能が候補としてあがっていましたが、共通化せずに各プロダクトの責務としてそれぞれ実装するという結論となりました。同じような機能に見えても、医科と歯科という業務ドメイン毎のコンテキスト差異を十分に検討した上での判断でした。 その差異がプロダクト機能としての強みとなり、安易な共通化はプロダクト成長の足枷となるリスクも存在 するためです。この判断も先ほどの全体の依存関係などが整理されたからこそ、意思決定できるものでした。 酒井 : 機能実装時に実感しましたが、やはり医科と歯科では細かい部分の要件などが異なる部分が多かったので、この段階で共通化の判断ができたのは大変助かりました。 PRM プロジェクトの大きな成果 新居 : 最後になりますが、このプロジェクトが終わっての成果はどのように考えていますか? 宍戸 : 冒頭に話した CLINICS の課題に関してはある程度、解決ができたと思います。 医療機関の業務に沿った形でプロダクトが進化 できた点はよかったと思います。特に問診周りなどは発熱外来などニーズの多様化に即して使い勝手が良くなったと思っています。 酒井 : 他にもビデオ通話部分など「オンライン診療」を提供するプロダクトとして「対面診療」だけではなく、もっと有用なプロダクトにできたかと思っています。 来田 : まだリリースしたばかりですが、初月の販売実績も期待していたよりも良く、そうした意味でも マーケットフィットした機能を出せたなという手応え が実感としてもありますね。 田中 : 予約やオンライン診療もドメインを統一した結果、会員登録数が増えていますので、そうした点も成果と言えます。 酒井 : あとは直接の成果というわけではないのですが、今回のプロジェクトの副産物として CLINICS の機能を整理整頓していった結果、 改めて「一気通貫で医療機関の業務をサポートできる」というトータルでの機能提供と各機能のシームレスな連携は CLINICS の強み だ、というのが再確認できたのは大きいです。 新居 : これからのさらなる CLINICS の発展に期待できますね!本日は長い時間お話ありがとうございました! おわりに メドレーとしてもかなり大規模なプロジェクトだった今回の PRM プロジェクトでしたが、みなさんのお話を聞いて各部署・各プロダクトで綿密に連携しながらプロジェクトを成功させようとしている様子が感じられるインタビューでした。 特にプロジェクト進行の話は非常に参考になりました。皆さんのご参考になる部分があれば幸いです。 こうしたプロジェクトで自分の力を発揮したい!と思った方はぜひお気軽に下記からご応募ください。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの新居です。クラウド診療支援システム CLINICS が 8 月から大幅に アップデート して、より患者と医療機関が密接に繋がるようになりました。 今回のアップデートで中心になっている機能領域として PRM(Patient Relationship Management) というものがあります。 この PRM が一体どういったものなのか、プロジェクトはどのように進んでいったのかを関係者にインタビューしていきました。 メドレーで大規模なプロジェクト開発をどのように行なっているかの一端をお見せできればと考えています! インタビュイー紹介 宍戸さん 医療プラットフォーム第一本部 プロダクト開発室第二グループに所属。クラウド診療支援システム CLINICS の開発責任者。前職は株式会社サイバーエージェントでサーバサイドエンジニアとして従事。2017 年メドレー入社。 酒井さん 医療プラットフォーム第一本部 プロダクト開発室第二グループに所属。クラウド診療支援システム CLINICS の UI/UX 全般を担当。本プロジェクトのリード。前職は受託開発会社で様々なサイトやシステムのデザインに従事。2019 年メドレー入社。 田中さん 医療プラットフォーム CTO。医療プラットフォームの開発統括をしながら、自身は患者統合基盤の開発を担当。前職までは SIer や IT コンサルタントを経て、株式会社サイバーエージェントでサーバサイドエンジニアとして従事。2016 年メドレー入社。 来田さん 前職まではクリニックで精神科医として従事。CLINCS オンライン診療の立ち上げ時から関わる。現在は CLINICS のディレクションを中心として事業部と開発の架け橋となっている。 PRM とはどういうものなのか? 新居 : では今回中心となった PRM とはいったい何なのかというところから解説していただいて良いですか? 一般的にはそこまで知られてない言葉なのではないかと思うのですが…。 宍戸 : 元々 CRM(Customer Relationship Management)というマーケティングなどの文脈の用語があります。これは「自社サービスや商品を使っている顧客」と「サービスや商品を提供している企業」との関係性を管理することを指しますが、それをもとに適切なアクションをおこなうことで最終的には利益向上を目指すものと考えられます。 PRM は CRM と同様に医療機関と患者さんの関係性を管理することで必要なサービスを提供する ためのもの、と考えています。 CLINICS で基幹システムである電子カルテなどではなく、 オンライン診療・予約・問診など患者接点となる機能をターゲットにしてそれらを強化・改善 していったのが、CLINICS の今回の PRM プロジェクトになります。 CLINICS 開発責任者 宍戸さん 新居 : 確かに CRM は最近良く聞く言葉でしたが、PRM は患者と医療サービスを使う医療機関との関係を深めるためのものなんですね。 PRM プロジェクトの始まり CLINICS に感じていた課題とは 新居 : このプロジェクトは半年ほどかけていると聞きましたが、「PRM をやっていこう」となったのが半年前からだったんでしょうか? 宍戸 : 元々 CLINICS はオンライン診療のシステムとして 2016 年からサービスを提供してきました。2018 年からは CLINICS カルテとして電子カルテシステムも提供を開始しましたが、そのタイミング以降はオンライン診療部分に関してはそこまで大きくアップデートはしてこなかったんです。 現在はクラウド診療支援システムとして販売していますが、これまでは電子カルテなど基幹部分の強化がメインになっていたからです。しかし、数年開発・運用してきた中で、本来医療機関の診察のメインである対面診療の予約については課題が積み残されていたり、昨今の状況から来る オンライン診療のニーズなどを始めとして、患者接点を強化していく必要がある ということになり、今回取り組むことになりました。 酒井 : PRM というと本当にここ最近の潮流なのですが、 CLINICS はもともと「患者とつながる」をコンセプト としており、今回の機能強化などもこのコンセプトに基づき実施しています。その上で、患者とのタッチポイントで抜けていた部分や強化したほうが良い部分をより作り込んでいったという形です。 例えば、CLINICS は元々オンライン診療のシステムとして始まっており、対面診療予約に関して使いづらさを感じるケースがあったため、対面診療予約をより行いやすくするよう改修を行うなどです。 CLINICS デザイナー 酒井さん 新居 : 元々あったものをさらに患者とのタッチポイントを強化するために、改修・改善していったんですね。 プロジェクトの背景 どのくらいの規模のプロジェクトだったのか 新居 : 半年のプロジェクトということですが、規模としてはどの位の大きさだったんでしょうか? 酒井 : 私が経験したプロジェクトの中でも関わる部署など考えると一番大きかったと思います。開発はもちろんですが、CLINICS チームの セールス・カスタマーサクセス・マーケティング、広報もなのでほぼ CLINICS の全部署と関わっていました 。 田中 : 他にも、サービスとしては患者統合基盤・ 患者向けアプリ・ Dentis が関係しています。 宍戸 : QA チームにもしっかり入ってもらって QA を行なったりしてもらったので、本当に 医療プラットフォームのほぼ全てのチームと関わって開発していった 感じです。最終的にプロダクトの見せ方や売り方なども含めて調整していったので事業部とも密接に関わって作り上げていきました。 新しい PRM 機能をどうやって、プロダクトに融合させたのか 新居 : そこまで大きい規模のプロジェクトだということで、PRM の各種機能をどうやって上手くプロダクトに落としこむのか、実際にはどのようにみなさん推進されていったんでしょう。 宍戸 : プロジェクトの推進という意味では、最初は来田さんや( Dentis の運営を行なっている)プロダクト戦略室の平山さんと スモールスタートで意見を出し合いながらモックを作っていき、まずはビジュアル面から機能のイメージなどを刷り合わせ ていくのに、酒井さんに手を動かしてもらいながら進めていました。 その過程でこのプロジェクトにおける重要な意思決定がありました。CLINICS ではログイン不要のシンプルな予約機能を以前より提供していました。この機能は患者アプリとは元々違うドメインで運営していたものでしたが、今回のタイミングでこの両者のアプリケーションを患者アプリと同じドメインに統合して運営していこうという決定をしました。 患者アプリは CLINICS チームとは別チームで運営しているという背景もあり、チーム間の連携が格段に増え 、考えなければいけない事柄も多くなります。プロジェクトとして関係者が多くなってきたので、 今までの考え方を 1 度リセットしてプロジェクトの進め方を新しく模索する必要がありました 。 この点がかなり自分の中では大変でした。来田さんも大変だったと思います。こうした全体像を描いたり、全体スケジュールを決めたりというところでは、田中さんにアドバイスをもらいながらプロジェクトを進めていきました。 プロジェクトを推進するために必要だったこと 難しい意思決定をどのようにしていた? 新居 : 途中から一気にプロジェクトがスケールアップしたということなんですね。今回のプロジェクトは色々な部署も関わるし、たくさんの機能や改修が入っています。開発側と事業部側との意識合わせが、かなり必要だったんではないかと思うのですが、その辺はいかがだったでしょうか。 来田 : 例えば、今まで CLINICS では対面診療予約の際に患者のクレジットカード登録を必須としていたのですが、今回の改修でクレジットカード登録を不要に変更できるように対応を行いました。この対応は、CLINICS オンライン診療の初期から念願の機能だったりします。自分は事業部長である田中大介さんと今年の年明けくらいから話をして、メンバーに「よし、このプロジェクトをやっていこう」という話を持っていくようにしていました。やっぱり、大変なプロジェクトだというのはあったのでスタートを切れる状態に徐々にしていった感じです。 プロジェクトが佳境に入ってからは自分は各部署との調整がメインの業務でした。開発側と事業側とか CLINICS と Dentis だとかそういった立場の違いから来る要求の違いを納得できる仕様に落とし込む作業です。やっぱり、それぞれの立場でベストを尽くそうとみんな考えているんですが、全部を取り入れることはできないので。私が調整するときには それぞれ反対の立場の人たちの考えをきちんと伝えるようにということをしながら、仕様を決めていく ことを念頭に置いていました。 具体的な調整の例としては、開発する機能とセールスする際のプランの刷り合わせだったりですね。「機能としてはこうしたほうが使いやすいよね」というだけだと、セールス側としては「どこをウリにして売っていくのかというのが見えてこない」という話になったんですね。これはどちらの言い分も一理あるものなんですが、こういうところを時間をかけて 双方納得行くように決めていきました 。 CLINICS ディレクター・医師 来田さん 酒井 : この例でやったことは、まず現在のプランと機能を全部書き出して、組み合わせを整理するということでした。これをベースにして話を刷り合わせていったんですが、文字ベースだと人間分かった気になるんですが、実はそこまでピンと来ない。ですので、 LP のモックを作ってこれを見た顧客が導入したくなるようなウリになっているのかをすぐに判断できる状態 にしました。 宍戸 : こうしてちゃんと機能を解いていって細かい部分も含めて、時には CLINICS のコンセプトに立ち返って事業部・開発双方で時間をかけて認識を合わせることができたのは、大変でしたが良かったですね。 リリースまでのプロセスで顧客の声を反映 新居 : やはりここまでのプロジェクトだと最初の段階でちゃんとリリースまでを見据えた意識合わせをチーム内で行なっていたんですね。開発が進行していって、リリースするまではどのようにプロジェクトは進んでいったんでしょう。 宍戸 : リリースをする直前も、単純に仕様や機能について文書で説明しても理解するのは難しいので、酒井さんにディレクションをしてもらいながら、開発環境を使って QA チームやカスタマーサポートチームと一緒に認識合わせやリリースに向けた準備を行なっていきました。 来田 : あとは関係が構築できている 顧客に実際機能を見てもらって反応を伺う ということもしていきました。色々な使い方をしている顧客 10 件くらいにモックをベースにヒアリングをかけていきました。価格や導入時期なども含めた話を聞いていって、そこをすぐにプロジェクトにフィードバックする体制を構築していました。 酒井 : 実際に顧客の声をこうして聞けるというのは本当にプロダクトにとってありがたいことでした。特にこういう使い勝手などに直接関わる部分では、こうしたフィードバックの有無で完成度が違ってきます。 機能の正式リリース前から機能評価に協力していただける医療機関がいるのは、カスタマーサポートの皆さんが顧客と良好な関係を築けているおかげ だと思っています。こういった点はメドレーの強みだと思います。 プロジェクトで大切にしたこと 新居 : 開発段階からユーザーの声を吸い上げていけるのは、本当に良いですね。プロダクトの改善スピードなんかも段違いに早くなりそうです。他に大切にしていた部分などありますか? 酒井 : 今回の機能開発においては、プロジェクトの責任者として、開発以外のメンバーともしっかりコミュニケーションし合意形成を図ることを意識してプロジェクトを推進しました。 先ほどの話にも出ましたが 1 つの機能を実装するとなっても、実際の医療現場での使い勝手や、メドレーでのサポート、売り方など色々な視点で考えないといけないプロジェクトでした。そのため、そういったところをカスタマーサクセスのメンバー含む 10 人ほどと毎週 1 つ 1 つ納得がいくように詰めていくという作業をしていったりしました。 来田さんのように現役の医師の意見、顧客の意見なども取り入れられますし、カスタマーサポートには医療事務経験者の方もいらっしゃるので、多方面の視点を総合的に取り入れられるコミュニケーション を心がけていました。 手段はテキストや Figma でのデザイン、実際の実装を見せるなど適切な手段を選んでコミュニケーションコストを低くするようにして進行していました。 実際の機能実装にあたってはエンジニアも自身で考えて細かいボールを拾ったりしながら、実装 していってもらいました。この辺りはこのプロジェクトだからというよりも、メドレーの開発のベースになっている部分なので良いですよね。 メンバーのイメージ合わせがプロジェクト成功の鍵 新居 : 先ほどもお話がありましたが、プロジェクト途中の意思決定で関わるプロダクトが多くなったのでスイッチングが大変だったということでしたが、実際にそのタイミングになったときに全体のシステム設計なんかも変わったりしたんでしょうか。 田中 : 私はプロジェクトの途中から入ったんですが、そのタイミングで、宍戸さんや来田さんがちょうどシステム設計を考え直していたり、プロジェクト計画の引き直しをしているところでした。そこでまずは全体像を把握したいと考えてドキュメントなどを見せてもらったんです。各機能の細かい要件は分かったのですが、このプロジェクト全体としての各システムの責務や依存関係などがいまいち分かりづらく、メンバー間の認識も若干ズレが発生しているように感じました。なのでまずは**メンバーの認識を合わせ、各チームが何をするべきかを明確化するために、各システムの責務など全体感の整理整頓をして「見える化」**することから始めました。 このプロジェクトに限らずですが、プロジェクトとして抽象度の高い段階でのドキュメントは、文章のみの記載だと実は関係者にしっかりと伝わっていなかったということが多々あります。各自が頭の中でイメージした図に差異が発生している状態です。自分はそういう際に良く言っているのが**「大枠で良いので、まずは整理結果を図にしてみんなのイメージを合わせる**」ということです。こうして認識を合わせることで各チームが進めやすくなり後戻りリスクも軽減されるので、この段階でしっかりとイメージをすりあわせる事がとても重要だと考えています。 医療プラットフォーム CTO 田中さん 新居 : たしかにテキストで仕様なんかを書きながら説明しても、実は認識に齟齬があった…という経験があります。その後はどのようなプロセスでプロジェクト推進したんですか? 田中 : その後は各プロダクトにて実装予定の機能で、プロダクト間で共通化できそうな機能を共通サービスとして切り出すかどうかをみんなと考えていきました。結果として大きな機能では「ビデオ通話」部分を共通化するという意思決定をしました。他にも「問診票の提供」機能が候補としてあがっていましたが、共通化せずに各プロダクトの責務としてそれぞれ実装するという結論となりました。同じような機能に見えても、医科と歯科という業務ドメイン毎のコンテキスト差異を十分に検討した上での判断でした。 その差異がプロダクト機能としての強みとなり、安易な共通化はプロダクト成長の足枷となるリスクも存在 するためです。この判断も先ほどの全体の依存関係などが整理されたからこそ、意思決定できるものでした。 酒井 : 機能実装時に実感しましたが、やはり医科と歯科では細かい部分の要件などが異なる部分が多かったので、この段階で共通化の判断ができたのは大変助かりました。 PRM プロジェクトの大きな成果 新居 : 最後になりますが、このプロジェクトが終わっての成果はどのように考えていますか? 宍戸 : 冒頭に話した CLINICS の課題に関してはある程度、解決ができたと思います。 医療機関の業務に沿った形でプロダクトが進化 できた点はよかったと思います。特に問診周りなどは発熱外来などニーズの多様化に即して使い勝手が良くなったと思っています。 酒井 : 他にもビデオ通話部分など「オンライン診療」を提供するプロダクトとして「対面診療」だけではなく、もっと有用なプロダクトにできたかと思っています。 来田 : まだリリースしたばかりですが、初月の販売実績も期待していたよりも良く、そうした意味でも マーケットフィットした機能を出せたなという手応え が実感としてもありますね。 田中 : 予約やオンライン診療もドメインを統一した結果、会員登録数が増えていますので、そうした点も成果と言えます。 酒井 : あとは直接の成果というわけではないのですが、今回のプロジェクトの副産物として CLINICS の機能を整理整頓していった結果、 改めて「一気通貫で医療機関の業務をサポートできる」というトータルでの機能提供と各機能のシームレスな連携は CLINICS の強み だ、というのが再確認できたのは大きいです。 新居 : これからのさらなる CLINICS の発展に期待できますね!本日は長い時間お話ありがとうございました! おわりに メドレーとしてもかなり大規模なプロジェクトだった今回の PRM プロジェクトでしたが、みなさんのお話を聞いて各部署・各プロダクトで綿密に連携しながらプロジェクトを成功させようとしている様子が感じられるインタビューでした。 特にプロジェクト進行の話は非常に参考になりました。皆さんのご参考になる部分があれば幸いです。 こうしたプロジェクトで自分の力を発揮したい!と思った方はぜひお気軽に下記からご応募ください。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの山田です。 今年も新卒入社で 6 人のメンバーがエンジニアとして入社しており、現在も絶賛新卒研修中となっています。毎年、新卒研修はプロセスやコンテンツを見直しているのですが、今年度は初めて Quality Assurance(以下 QA)についての講座を取り入れるようにしました。 今回は講師をお願いした QA エンジニアお二人にどのようなことを念頭に講義を実施したのかをインタビューしてみました。 今年から QA 講座を新卒研修のカリキュラムとして取り入れた理由について インタビュー本編をお届けする前に、今回 QA 講座を新卒研修に取り入れた理由について研修企画担当の 1 人としてご説明します。 QA 講座を新卒研修のカリキュラムに取り入れたいと思ったきっかけは、昨年の「開発実践研修」でアプリケーション開発の一環としてテスト設計も含めて実施していましたが、メンターとしてレビューをしている際「 せっかくメドレーには QA のスペシャリストがいるんだから、今回のレビューにも加わってもらえば良かった …」と感じたことでした。 今年はメンターではなく、新卒研修の企画・運営を主に担当することになり、昨年よりもさらに研修の質を上げるためにはどうするかを考えた時、上記のきっかけもあり QA エンジニアの皆さんには「開発実践研修」のテスト設計レビューを含め、座学による講義もお願いしたいと思うようになりました。 講義をお願いしたいと思った理由として大きく 3 つあります。 1. QA の経験不足を補う 全体的な傾向として弊社の新卒エンジニアは、インターンや学校の活動などで開発経験は相応にあるのですが、テスト設計をはじめとする QA を特に力を入れてやった経験が浅いという事実があります。その上でこれから先メドレーでプロダクト開発をする上では、テストや QA などについて自走して考え実施することができるようにしたかったため。 2. QA に対する認識を揃え、意識を高める 「QA とは何ぞや?」という話を専門性を持った QA エンジニアから新卒エンジニアに伝えてもらいプロダクトの QA に対して意識を高めてもらいたかったため。 3. 社内勉強会の内容がとても為になると感じた 弊社では、TechLunch という社内勉強会を開催していますが、その中で今回インタビューした QA エンジニアお二人の発表内容が大変良かったので、その内容をぜひ新卒エンジニアにも伝えてほしいと感じたため。 このような理由により、今年度からは QA 講座を研修の一部として開くことになりました。 さて、前置きが長くなりましたがそんな QA 講座を担当してくださった QA エンジニアのお二人へのインタビューをご覧ください。 インタビュイー紹介 上村さん 医療プラットフォーム第一本部 プロダクト開発室 第一開発グループに所属。クラウド診療支援システム CLINICS の医療機関側システム（カルテ、オンライン診療など）の品質向上活動を担当。 米山さん 医療プラットフォーム第一本部 プロダクト開発室 第一開発グループに所属。オンライン診療・服薬指導アプリ CLINICS のアプリ・ Web ・基盤を扱う開発チームで QA プロセス全般を担当。 左から上村さん・米山さん・筆者 QA 講座を担当した QA エンジニアのインタビュー チームの雰囲気 山田 : 早速ですが、お二人とも医療プラットフォームで QA を担当されていますが、所属しているチームの雰囲気はどんな感じなんでしょうか? 上村 : チームというよりもメドレーのエンジニア・デザイナーの皆さんに共通している話かもしれませんが、 セルフマネジメントできている方がとても多い と感じます。そういった方達なので視野を広く持っていて、開発の時にメンバー間で落ちそうなボールを自分でさっと拾って担当したりを自然にやっていますね。後は CLINICS の特に電子カルテは開発に必要なドメイン知識が広範囲で、私も入社して 2 年強経ちますが、未だに分かっていない部分などが出てくることもあり、そんな時でも 気軽に周囲のメンバーに聞ける雰囲気 なのが良いです。 山田 : 現在は QA エンジニアとして、仕様策定のフェイズから関わっていることが多いんでしょうか? 上村 : 関わり方はプロジェクトや時期により違っています。メインで担当するプロジェクトは最初から入って仕様レビューから関わる場合もありますし、複数のプロジェクトが平行している時は要所でアドバイス的な形を取る場合もあります。現在は開発中の大きいプロジェクトでの活動に振り切っているフェイズになっているところです。 山田 : 米山さんのチームの雰囲気などはいかがですか? 米山 : 上村さんとは違うチームに所属していますが、似た印象を持っています。一言で言うと「大人が集まっている」チームだと思います。ミーティングなどでも 本質を捉えた議論が多く、皆さん人格者で仕事ができる方々 だと感じています。今所属してるのが患者さんが使うアプリの開発チームで、Android / iOS / Web と 3 プラットフォームのプロダクト開発をしているのですが、1 人のエンジニアが 3 プラットフォーム全てを実装したりするのはこのチームの特徴の一つ かもしれません。他社さんと比較すると珍しい体制ではないかと思います。 山田 : なるほど。リソース効率を考えた結果のチーム運営なんですね。 研修のオファーの打診がされた時に考えたこと 山田 : 今回お二人に QA 講座の担当をオファーさせていただいた訳ですが、オファーを受けた時にどのような思いでしたか? 上村 : 「ついにこの時が来たか…!」と思いました w 山田 : QA の啓蒙をされている上村さんとしては、やはり講師のオファーを待ち望んでいたわけなんですね。 上村 : はい、私が入社したのが一昨年の 4 月だったので当時の新卒研修カリキュラムはもう決まっていたと思うのですが、もしその時にオファーが突然あっても大丈夫でした。去年はオファーが無かったので「まだ早いのかな」と少し残念だったのですが、 今年オファーがあって良かった です。 米山 : メドレーは元々プロダクト品質に対する意識が高いと感じているので、お話をもらった時に違和感はなかったです。こういった意識の高さは、経験豊富なメンバー達が作ってきた開発文化が社内に浸透しているからだと思います。ですので、 入社時にこうした研修を通して目線を合わせるという意味で良い取り組み だと考えています。 QA 研修コンテンツの準備 山田 : 今回の研修コンテンツを作る上で、工夫されていた点や意識されたポイントなどは、どのようなものがありましたか? 上村 : 準備段階で私のほうで素案を作ってから、直属の上司で研修の責任者でもある田中(医療 PF CTO)に相談したところ、「品質というのがプロダクトに取ってどれだけ重要なのかを教えてほしい」というオーダーを頂きました。 その後に米山さんと、どのように講義を分けるかを話し合い、私は QA の重要性や **QA とは?**をテーマにテスト技法の演習を通して、まずは「品質」という観点がいかにプロダクトを作る上で大事なのかという大枠を話すことになりました。一方で米山さんはより実務に即した観点から、メドレーでの具体的な取り組みや自動テスト、開発プロセスとの関わり方などを話すことになりました。 こんな形で役割分担はスムーズに決まりましたので、まずは研修目的を新卒のスキルレベルから考えて設定しました。研修全体では田中から「メドレーのエンジニアに求めること」の講座があり、内容としてはマインドセットなど抽象度が高めの内容になります。その後に具体的な「開発基礎研修」が続くので、ちょうどその中間的な抽象度になるように今回の講座は作るように意識しました。 私が考えるカリキュラムで大事にしているのは、 講義中にも手を動かしたり、自分でも考えてもらいながら参加してもらう 所なので、そこも意識しています。 山田 : ちょうど良い抽象度で QA の重要性を全般的に分かるようにまとめていったんですね。米山さんは、どんな点が挙げられますか? 米山 : 来年以降でも使えるようなコンテンツにしたい と考えていました。前職でも非 QA エンジニア向けの研修があったのですが、講義の感想で「もっと現場での実際の話なども聞いてみたかった」というような意見があるのを見ていたので、私のコンテンツでは抽象度が高い話だけではなく、実際のプロジェクトでの事例なども盛り込むようにしました。 また、 テスト自動化 なども人によって考え方も様々だったりするので、テストピラミッドの話なども含めて現実的な考え方や活用方法などを講座には入れています。 QA 研修講座について紹介 山田 : そのように工夫をして作っていただいた講座ですが、それぞれどのような内容だったのか教えていただけますか? 上村 : 一般的に知られる障害の事例として例えば「 チャレンジャー号爆発事故 」などを挙げて、まず**「品質」がプロダクトに与える影響について知ってもらう**ようにしました。事業ドメインなどが違う事例をいくつか挙げています。 後半では、具体的にどのように「品質を上げること」ができるかという部分にスポットを当てて紹介をしています。 上村の発表スライド 米山 : 私は具体的なメドレーでの品質向上のためにやっている取り組み（ Magic Pod 導入の話 など）や、品質とテストに対する考え方などをお話しました。またメドレーのメンバーの良い取り組み事例として ホットフィックスでも、きちんとテストコードを追加してリリース している部分などを、どう考えてこの対応をしたのだろうかというような事も講義内容に入れています。 講座についての手応え 山田 : お話を聞いていると、すごくバランスが取れた講座に仕上がってる印象を持ちました。講義をした手応えとしては、どんなものがありましたか? 米山 : 今回の講義はオンライン形式だったこともあり、少し一方通行で終わってしまったかもしれないなと思いました。もう少しカジュアルに質疑応答も含めてインタラクティブに新卒メンバーと交流できたら、もっと良かったかなと思います。( 編注: 今年はコロナ対策として、オンラインで研修を行ないました ) 上村 : 途中少し問いかけのタイミングなどもつくったんですけどもね。 山田 : 研修の時期的に新卒メンバーの緊張なんかもあったんでしょうね。話は変わりますが、今回 1 講座をお二人に担当していただきましたが、新卒研修全体へのお二人の印象などはどんなものでしょうか? 上村 : 羨ましいなと思っちゃいますね w 自分が IT 業界で働き始めた時は特に「即 OJT」という感じでしたので、コンテンツがとても充実していて、実業務に入る時にハードルが低くなると思います。 米山 : 規模がとても大きい企業で充実した研修というのは分かるのですが、現在のメドレーの規模でここまで充実した研修をしているのは凄いなと感じます。去年までに入社した新卒メンバーも配属後にすごく活躍しているのを見ているので、充実した研修が活きているのではないでしょうか。 自分が QA エンジニアのキャリアを始めた時にも、複数の研修を受けたのですが、今でもちゃんと記憶に残っている研修というのがあるので、講師側としてはそういった研修にできるようにしていきたいですね。 来年に向けて 山田 : これからの話もちょうど出てきたところなので、来年の QA 講座はどのようにバージョンアップしていきたいというアイディアはありますか? 上村 : 今回のように 90 分も良いのですが、 できれば 1 日ワークショップをやってみたい なと考えていました。それだけ時間があれば他にもやりたいことが盛り込めるなと思います。それだけの時間が確保できるかが課題なのですが…。あとは来年はできれば対面で実施できれば良いなと思います。 米山 : 新卒メンバーは私達の研修の後に「開発実践研修」で実際にプロダクトを作るフェイズがあるので、来年はその開発実践研修の内容とリンクさせて、 すぐに活用できるような実践的な話もできたらと考えています 。 上村 : 確かに何かアプリを触ってもらって、テスト観点はどういったものがあるかなんかを考えてもらうなども良いですね。 具体的なテスト技法とか考え方なんかは検索すれば出てくるものですが、実際にそれらをどう使うか、いつ使うかという点が難しいところなので、きちんと伝えていきたいです。 米山 : あとは中長期的な目標としては、こうした研修をしていくことによって 社内で QA エンジニアを志望する方が出てくるような講座 ができれば良いなという願望があります w 山田 : なるほど、社内スカウトができるように充実した研修にするということですね w 本日はありがとうございました。 おわりに 今年初めての試みである QA 新卒講座をどのように作っていったのかを、お送りしました。 メドレーでは QA エンジニアだけが品質に責任を持つというわけではなく、開発に携わる全員が責任を持っていくというスタイルでプロダクト開発をしているため、そうした姿勢を新卒メンバーに伝える上でも今回の講座はとても有用だったと考えています。 このような開発スタイルで日々プロダクトを作っているメンバーに興味が出て話を聞きたい! という方はぜひカジュアルにお話できればと思います。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの山田です。 今年も新卒入社で 6 人のメンバーがエンジニアとして入社しており、現在も絶賛新卒研修中となっています。毎年、新卒研修はプロセスやコンテンツを見直しているのですが、今年度は初めて Quality Assurance(以下 QA)についての講座を取り入れるようにしました。 今回は講師をお願いした QA エンジニアお二人にどのようなことを念頭に講義を実施したのかをインタビューしてみました。 今年から QA 講座を新卒研修のカリキュラムとして取り入れた理由について インタビュー本編をお届けする前に、今回 QA 講座を新卒研修に取り入れた理由について研修企画担当の 1 人としてご説明します。 QA 講座を新卒研修のカリキュラムに取り入れたいと思ったきっかけは、昨年の「開発実践研修」でアプリケーション開発の一環としてテスト設計も含めて実施していましたが、メンターとしてレビューをしている際「 せっかくメドレーには QA のスペシャリストがいるんだから、今回のレビューにも加わってもらえば良かった …」と感じたことでした。 今年はメンターではなく、新卒研修の企画・運営を主に担当することになり、昨年よりもさらに研修の質を上げるためにはどうするかを考えた時、上記のきっかけもあり QA エンジニアの皆さんには「開発実践研修」のテスト設計レビューを含め、座学による講義もお願いしたいと思うようになりました。 講義をお願いしたいと思った理由として大きく 3 つあります。 1. QA の経験不足を補う 全体的な傾向として弊社の新卒エンジニアは、インターンや学校の活動などで開発経験は相応にあるのですが、テスト設計をはじめとする QA を特に力を入れてやった経験が浅いという事実があります。その上でこれから先メドレーでプロダクト開発をする上では、テストや QA などについて自走して考え実施することができるようにしたかったため。 2. QA に対する認識を揃え、意識を高める 「QA とは何ぞや?」という話を専門性を持った QA エンジニアから新卒エンジニアに伝えてもらいプロダクトの QA に対して意識を高めてもらいたかったため。 3. 社内勉強会の内容がとても為になると感じた 弊社では、TechLunch という社内勉強会を開催していますが、その中で今回インタビューした QA エンジニアお二人の発表内容が大変良かったので、その内容をぜひ新卒エンジニアにも伝えてほしいと感じたため。 このような理由により、今年度からは QA 講座を研修の一部として開くことになりました。 さて、前置きが長くなりましたがそんな QA 講座を担当してくださった QA エンジニアのお二人へのインタビューをご覧ください。 インタビュイー紹介 上村さん 医療プラットフォーム第一本部 プロダクト開発室 第一開発グループに所属。クラウド診療支援システム CLINICS の医療機関側システム（カルテ、オンライン診療など）の品質向上活動を担当。 米山さん 医療プラットフォーム第一本部 プロダクト開発室 第一開発グループに所属。オンライン診療・服薬指導アプリ CLINICS のアプリ・ Web ・基盤を扱う開発チームで QA プロセス全般を担当。 左から上村さん・米山さん・筆者 QA 講座を担当した QA エンジニアのインタビュー チームの雰囲気 山田 : 早速ですが、お二人とも医療プラットフォームで QA を担当されていますが、所属しているチームの雰囲気はどんな感じなんでしょうか? 上村 : チームというよりもメドレーのエンジニア・デザイナーの皆さんに共通している話かもしれませんが、 セルフマネジメントできている方がとても多い と感じます。そういった方達なので視野を広く持っていて、開発の時にメンバー間で落ちそうなボールを自分でさっと拾って担当したりを自然にやっていますね。後は CLINICS の特に電子カルテは開発に必要なドメイン知識が広範囲で、私も入社して 2 年強経ちますが、未だに分かっていない部分などが出てくることもあり、そんな時でも 気軽に周囲のメンバーに聞ける雰囲気 なのが良いです。 山田 : 現在は QA エンジニアとして、仕様策定のフェイズから関わっていることが多いんでしょうか? 上村 : 関わり方はプロジェクトや時期により違っています。メインで担当するプロジェクトは最初から入って仕様レビューから関わる場合もありますし、複数のプロジェクトが平行している時は要所でアドバイス的な形を取る場合もあります。現在は開発中の大きいプロジェクトでの活動に振り切っているフェイズになっているところです。 山田 : 米山さんのチームの雰囲気などはいかがですか? 米山 : 上村さんとは違うチームに所属していますが、似た印象を持っています。一言で言うと「大人が集まっている」チームだと思います。ミーティングなどでも 本質を捉えた議論が多く、皆さん人格者で仕事ができる方々 だと感じています。今所属してるのが患者さんが使うアプリの開発チームで、Android / iOS / Web と 3 プラットフォームのプロダクト開発をしているのですが、1 人のエンジニアが 3 プラットフォーム全てを実装したりするのはこのチームの特徴の一つ かもしれません。他社さんと比較すると珍しい体制ではないかと思います。 山田 : なるほど。リソース効率を考えた結果のチーム運営なんですね。 研修のオファーの打診がされた時に考えたこと 山田 : 今回お二人に QA 講座の担当をオファーさせていただいた訳ですが、オファーを受けた時にどのような思いでしたか? 上村 : 「ついにこの時が来たか…!」と思いました w 山田 : QA の啓蒙をされている上村さんとしては、やはり講師のオファーを待ち望んでいたわけなんですね。 上村 : はい、私が入社したのが一昨年の 4 月だったので当時の新卒研修カリキュラムはもう決まっていたと思うのですが、もしその時にオファーが突然あっても大丈夫でした。去年はオファーが無かったので「まだ早いのかな」と少し残念だったのですが、 今年オファーがあって良かった です。 米山 : メドレーは元々プロダクト品質に対する意識が高いと感じているので、お話をもらった時に違和感はなかったです。こういった意識の高さは、経験豊富なメンバー達が作ってきた開発文化が社内に浸透しているからだと思います。ですので、 入社時にこうした研修を通して目線を合わせるという意味で良い取り組み だと考えています。 QA 研修コンテンツの準備 山田 : 今回の研修コンテンツを作る上で、工夫されていた点や意識されたポイントなどは、どのようなものがありましたか? 上村 : 準備段階で私のほうで素案を作ってから、直属の上司で研修の責任者でもある田中(医療 PF CTO)に相談したところ、「品質というのがプロダクトに取ってどれだけ重要なのかを教えてほしい」というオーダーを頂きました。 その後に米山さんと、どのように講義を分けるかを話し合い、私は QA の重要性や **QA とは?**をテーマにテスト技法の演習を通して、まずは「品質」という観点がいかにプロダクトを作る上で大事なのかという大枠を話すことになりました。一方で米山さんはより実務に即した観点から、メドレーでの具体的な取り組みや自動テスト、開発プロセスとの関わり方などを話すことになりました。 こんな形で役割分担はスムーズに決まりましたので、まずは研修目的を新卒のスキルレベルから考えて設定しました。研修全体では田中から「メドレーのエンジニアに求めること」の講座があり、内容としてはマインドセットなど抽象度が高めの内容になります。その後に具体的な「開発基礎研修」が続くので、ちょうどその中間的な抽象度になるように今回の講座は作るように意識しました。 私が考えるカリキュラムで大事にしているのは、 講義中にも手を動かしたり、自分でも考えてもらいながら参加してもらう 所なので、そこも意識しています。 山田 : ちょうど良い抽象度で QA の重要性を全般的に分かるようにまとめていったんですね。米山さんは、どんな点が挙げられますか? 米山 : 来年以降でも使えるようなコンテンツにしたい と考えていました。前職でも非 QA エンジニア向けの研修があったのですが、講義の感想で「もっと現場での実際の話なども聞いてみたかった」というような意見があるのを見ていたので、私のコンテンツでは抽象度が高い話だけではなく、実際のプロジェクトでの事例なども盛り込むようにしました。 また、 テスト自動化 なども人によって考え方も様々だったりするので、テストピラミッドの話なども含めて現実的な考え方や活用方法などを講座には入れています。 QA 研修講座について紹介 山田 : そのように工夫をして作っていただいた講座ですが、それぞれどのような内容だったのか教えていただけますか? 上村 : 一般的に知られる障害の事例として例えば「 チャレンジャー号爆発事故 」などを挙げて、まず**「品質」がプロダクトに与える影響について知ってもらう**ようにしました。事業ドメインなどが違う事例をいくつか挙げています。 後半では、具体的にどのように「品質を上げること」ができるかという部分にスポットを当てて紹介をしています。 上村の発表スライド 米山 : 私は具体的なメドレーでの品質向上のためにやっている取り組み（ Magic Pod 導入の話 など）や、品質とテストに対する考え方などをお話しました。またメドレーのメンバーの良い取り組み事例として ホットフィックスでも、きちんとテストコードを追加してリリース している部分などを、どう考えてこの対応をしたのだろうかというような事も講義内容に入れています。 講座についての手応え 山田 : お話を聞いていると、すごくバランスが取れた講座に仕上がってる印象を持ちました。講義をした手応えとしては、どんなものがありましたか? 米山 : 今回の講義はオンライン形式だったこともあり、少し一方通行で終わってしまったかもしれないなと思いました。もう少しカジュアルに質疑応答も含めてインタラクティブに新卒メンバーと交流できたら、もっと良かったかなと思います。( 編注: 今年はコロナ対策として、オンラインで研修を行ないました ) 上村 : 途中少し問いかけのタイミングなどもつくったんですけどもね。 山田 : 研修の時期的に新卒メンバーの緊張なんかもあったんでしょうね。話は変わりますが、今回 1 講座をお二人に担当していただきましたが、新卒研修全体へのお二人の印象などはどんなものでしょうか? 上村 : 羨ましいなと思っちゃいますね w 自分が IT 業界で働き始めた時は特に「即 OJT」という感じでしたので、コンテンツがとても充実していて、実業務に入る時にハードルが低くなると思います。 米山 : 規模がとても大きい企業で充実した研修というのは分かるのですが、現在のメドレーの規模でここまで充実した研修をしているのは凄いなと感じます。去年までに入社した新卒メンバーも配属後にすごく活躍しているのを見ているので、充実した研修が活きているのではないでしょうか。 自分が QA エンジニアのキャリアを始めた時にも、複数の研修を受けたのですが、今でもちゃんと記憶に残っている研修というのがあるので、講師側としてはそういった研修にできるようにしていきたいですね。 来年に向けて 山田 : これからの話もちょうど出てきたところなので、来年の QA 講座はどのようにバージョンアップしていきたいというアイディアはありますか? 上村 : 今回のように 90 分も良いのですが、 できれば 1 日ワークショップをやってみたい なと考えていました。それだけ時間があれば他にもやりたいことが盛り込めるなと思います。それだけの時間が確保できるかが課題なのですが…。あとは来年はできれば対面で実施できれば良いなと思います。 米山 : 新卒メンバーは私達の研修の後に「開発実践研修」で実際にプロダクトを作るフェイズがあるので、来年はその開発実践研修の内容とリンクさせて、 すぐに活用できるような実践的な話もできたらと考えています 。 上村 : 確かに何かアプリを触ってもらって、テスト観点はどういったものがあるかなんかを考えてもらうなども良いですね。 具体的なテスト技法とか考え方なんかは検索すれば出てくるものですが、実際にそれらをどう使うか、いつ使うかという点が難しいところなので、きちんと伝えていきたいです。 米山 : あとは中長期的な目標としては、こうした研修をしていくことによって 社内で QA エンジニアを志望する方が出てくるような講座 ができれば良いなという願望があります w 山田 : なるほど、社内スカウトができるように充実した研修にするということですね w 本日はありがとうございました。 おわりに 今年初めての試みである QA 新卒講座をどのように作っていったのかを、お送りしました。 メドレーでは QA エンジニアだけが品質に責任を持つというわけではなく、開発に携わる全員が責任を持っていくというスタイルでプロダクト開発をしているため、そうした姿勢を新卒メンバーに伝える上でも今回の講座はとても有用だったと考えています。 このような開発スタイルで日々プロダクトを作っているメンバーに興味が出て話を聞きたい! という方はぜひカジュアルにお話できればと思います。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの山田です。 今年も新卒入社で 6 人のメンバーがエンジニアとして入社しており、現在も絶賛新卒研修中となっています。毎年、新卒研修はプロセスやコンテンツを見直しているのですが、今年度は初めて Quality Assurance(以下 QA)についての講座を取り入れるようにしました。 今回は講師をお願いした QA エンジニアお二人にどのようなことを念頭に講義を実施したのかをインタビューしてみました。 今年から QA 講座を新卒研修のカリキュラムとして取り入れた理由について インタビュー本編をお届けする前に、今回 QA 講座を新卒研修に取り入れた理由について研修企画担当の 1 人としてご説明します。 QA 講座を新卒研修のカリキュラムに取り入れたいと思ったきっかけは、昨年の「開発実践研修」でアプリケーション開発の一環としてテスト設計も含めて実施していましたが、メンターとしてレビューをしている際「 せっかくメドレーには QA のスペシャリストがいるんだから、今回のレビューにも加わってもらえば良かった …」と感じたことでした。 今年はメンターではなく、新卒研修の企画・運営を主に担当することになり、昨年よりもさらに研修の質を上げるためにはどうするかを考えた時、上記のきっかけもあり QA エンジニアの皆さんには「開発実践研修」のテスト設計レビューを含め、座学による講義もお願いしたいと思うようになりました。 講義をお願いしたいと思った理由として大きく 3 つあります。 1. QA の経験不足を補う 全体的な傾向として弊社の新卒エンジニアは、インターンや学校の活動などで開発経験は相応にあるのですが、テスト設計をはじめとする QA を特に力を入れてやった経験が浅いという事実があります。その上でこれから先メドレーでプロダクト開発をする上では、テストや QA などについて自走して考え実施することができるようにしたかったため。 2. QA に対する認識を揃え、意識を高める 「QA とは何ぞや?」という話を専門性を持った QA エンジニアから新卒エンジニアに伝えてもらいプロダクトの QA に対して意識を高めてもらいたかったため。 3. 社内勉強会の内容がとても為になると感じた 弊社では、TechLunch という社内勉強会を開催していますが、その中で今回インタビューした QA エンジニアお二人の発表内容が大変良かったので、その内容をぜひ新卒エンジニアにも伝えてほしいと感じたため。 このような理由により、今年度からは QA 講座を研修の一部として開くことになりました。 さて、前置きが長くなりましたがそんな QA 講座を担当してくださった QA エンジニアのお二人へのインタビューをご覧ください。 インタビュイー紹介 上村さん 医療プラットフォーム第一本部 プロダクト開発室 第一開発グループに所属。クラウド診療支援システム CLINICS の医療機関側システム（カルテ、オンライン診療など）の品質向上活動を担当。 米山さん 医療プラットフォーム第一本部 プロダクト開発室 第一開発グループに所属。オンライン診療・服薬指導アプリ CLINICS のアプリ・ Web ・基盤を扱う開発チームで QA プロセス全般を担当。 左から上村さん・米山さん・筆者 QA 講座を担当した QA エンジニアのインタビュー チームの雰囲気 山田 : 早速ですが、お二人とも医療プラットフォームで QA を担当されていますが、所属しているチームの雰囲気はどんな感じなんでしょうか? 上村 : チームというよりもメドレーのエンジニア・デザイナーの皆さんに共通している話かもしれませんが、 セルフマネジメントできている方がとても多い と感じます。そういった方達なので視野を広く持っていて、開発の時にメンバー間で落ちそうなボールを自分でさっと拾って担当したりを自然にやっていますね。後は CLINICS の特に電子カルテは開発に必要なドメイン知識が広範囲で、私も入社して 2 年強経ちますが、未だに分かっていない部分などが出てくることもあり、そんな時でも 気軽に周囲のメンバーに聞ける雰囲気 なのが良いです。 山田 : 現在は QA エンジニアとして、仕様策定のフェイズから関わっていることが多いんでしょうか? 上村 : 関わり方はプロジェクトや時期により違っています。メインで担当するプロジェクトは最初から入って仕様レビューから関わる場合もありますし、複数のプロジェクトが平行している時は要所でアドバイス的な形を取る場合もあります。現在は開発中の大きいプロジェクトでの活動に振り切っているフェイズになっているところです。 山田 : 米山さんのチームの雰囲気などはいかがですか? 米山 : 上村さんとは違うチームに所属していますが、似た印象を持っています。一言で言うと「大人が集まっている」チームだと思います。ミーティングなどでも 本質を捉えた議論が多く、皆さん人格者で仕事ができる方々 だと感じています。今所属してるのが患者さんが使うアプリの開発チームで、Android / iOS / Web と 3 プラットフォームのプロダクト開発をしているのですが、1 人のエンジニアが 3 プラットフォーム全てを実装したりするのはこのチームの特徴の一つ かもしれません。他社さんと比較すると珍しい体制ではないかと思います。 山田 : なるほど。リソース効率を考えた結果のチーム運営なんですね。 研修のオファーの打診がされた時に考えたこと 山田 : 今回お二人に QA 講座の担当をオファーさせていただいた訳ですが、オファーを受けた時にどのような思いでしたか? 上村 : 「ついにこの時が来たか…!」と思いました w 山田 : QA の啓蒙をされている上村さんとしては、やはり講師のオファーを待ち望んでいたわけなんですね。 上村 : はい、私が入社したのが一昨年の 4 月だったので当時の新卒研修カリキュラムはもう決まっていたと思うのですが、もしその時にオファーが突然あっても大丈夫でした。去年はオファーが無かったので「まだ早いのかな」と少し残念だったのですが、 今年オファーがあって良かった です。 米山 : メドレーは元々プロダクト品質に対する意識が高いと感じているので、お話をもらった時に違和感はなかったです。こういった意識の高さは、経験豊富なメンバー達が作ってきた開発文化が社内に浸透しているからだと思います。ですので、 入社時にこうした研修を通して目線を合わせるという意味で良い取り組み だと考えています。 QA 研修コンテンツの準備 山田 : 今回の研修コンテンツを作る上で、工夫されていた点や意識されたポイントなどは、どのようなものがありましたか? 上村 : 準備段階で私のほうで素案を作ってから、直属の上司で研修の責任者でもある田中(医療 PF CTO)に相談したところ、「品質というのがプロダクトに取ってどれだけ重要なのかを教えてほしい」というオーダーを頂きました。 その後に米山さんと、どのように講義を分けるかを話し合い、私は QA の重要性や **QA とは?**をテーマにテスト技法の演習を通して、まずは「品質」という観点がいかにプロダクトを作る上で大事なのかという大枠を話すことになりました。一方で米山さんはより実務に即した観点から、メドレーでの具体的な取り組みや自動テスト、開発プロセスとの関わり方などを話すことになりました。 こんな形で役割分担はスムーズに決まりましたので、まずは研修目的を新卒のスキルレベルから考えて設定しました。研修全体では田中から「メドレーのエンジニアに求めること」の講座があり、内容としてはマインドセットなど抽象度が高めの内容になります。その後に具体的な「開発基礎研修」が続くので、ちょうどその中間的な抽象度になるように今回の講座は作るように意識しました。 私が考えるカリキュラムで大事にしているのは、 講義中にも手を動かしたり、自分でも考えてもらいながら参加してもらう 所なので、そこも意識しています。 山田 : ちょうど良い抽象度で QA の重要性を全般的に分かるようにまとめていったんですね。米山さんは、どんな点が挙げられますか? 米山 : 来年以降でも使えるようなコンテンツにしたい と考えていました。前職でも非 QA エンジニア向けの研修があったのですが、講義の感想で「もっと現場での実際の話なども聞いてみたかった」というような意見があるのを見ていたので、私のコンテンツでは抽象度が高い話だけではなく、実際のプロジェクトでの事例なども盛り込むようにしました。 また、 テスト自動化 なども人によって考え方も様々だったりするので、テストピラミッドの話なども含めて現実的な考え方や活用方法などを講座には入れています。 QA 研修講座について紹介 山田 : そのように工夫をして作っていただいた講座ですが、それぞれどのような内容だったのか教えていただけますか? 上村 : 一般的に知られる障害の事例として例えば「 チャレンジャー号爆発事故 」などを挙げて、まず**「品質」がプロダクトに与える影響について知ってもらう**ようにしました。事業ドメインなどが違う事例をいくつか挙げています。 後半では、具体的にどのように「品質を上げること」ができるかという部分にスポットを当てて紹介をしています。 上村の発表スライド 米山 : 私は具体的なメドレーでの品質向上のためにやっている取り組み（ Magic Pod 導入の話 など）や、品質とテストに対する考え方などをお話しました。またメドレーのメンバーの良い取り組み事例として ホットフィックスでも、きちんとテストコードを追加してリリース している部分などを、どう考えてこの対応をしたのだろうかというような事も講義内容に入れています。 講座についての手応え 山田 : お話を聞いていると、すごくバランスが取れた講座に仕上がってる印象を持ちました。講義をした手応えとしては、どんなものがありましたか? 米山 : 今回の講義はオンライン形式だったこともあり、少し一方通行で終わってしまったかもしれないなと思いました。もう少しカジュアルに質疑応答も含めてインタラクティブに新卒メンバーと交流できたら、もっと良かったかなと思います。( 編注: 今年はコロナ対策として、オンラインで研修を行ないました ) 上村 : 途中少し問いかけのタイミングなどもつくったんですけどもね。 山田 : 研修の時期的に新卒メンバーの緊張なんかもあったんでしょうね。話は変わりますが、今回 1 講座をお二人に担当していただきましたが、新卒研修全体へのお二人の印象などはどんなものでしょうか? 上村 : 羨ましいなと思っちゃいますね w 自分が IT 業界で働き始めた時は特に「即 OJT」という感じでしたので、コンテンツがとても充実していて、実業務に入る時にハードルが低くなると思います。 米山 : 規模がとても大きい企業で充実した研修というのは分かるのですが、現在のメドレーの規模でここまで充実した研修をしているのは凄いなと感じます。去年までに入社した新卒メンバーも配属後にすごく活躍しているのを見ているので、充実した研修が活きているのではないでしょうか。 自分が QA エンジニアのキャリアを始めた時にも、複数の研修を受けたのですが、今でもちゃんと記憶に残っている研修というのがあるので、講師側としてはそういった研修にできるようにしていきたいですね。 来年に向けて 山田 : これからの話もちょうど出てきたところなので、来年の QA 講座はどのようにバージョンアップしていきたいというアイディアはありますか? 上村 : 今回のように 90 分も良いのですが、 できれば 1 日ワークショップをやってみたい なと考えていました。それだけ時間があれば他にもやりたいことが盛り込めるなと思います。それだけの時間が確保できるかが課題なのですが…。あとは来年はできれば対面で実施できれば良いなと思います。 米山 : 新卒メンバーは私達の研修の後に「開発実践研修」で実際にプロダクトを作るフェイズがあるので、来年はその開発実践研修の内容とリンクさせて、 すぐに活用できるような実践的な話もできたらと考えています 。 上村 : 確かに何かアプリを触ってもらって、テスト観点はどういったものがあるかなんかを考えてもらうなども良いですね。 具体的なテスト技法とか考え方なんかは検索すれば出てくるものですが、実際にそれらをどう使うか、いつ使うかという点が難しいところなので、きちんと伝えていきたいです。 米山 : あとは中長期的な目標としては、こうした研修をしていくことによって 社内で QA エンジニアを志望する方が出てくるような講座 ができれば良いなという願望があります w 山田 : なるほど、社内スカウトができるように充実した研修にするということですね w 本日はありがとうございました。 おわりに 今年初めての試みである QA 新卒講座をどのように作っていったのかを、お送りしました。 メドレーでは QA エンジニアだけが品質に責任を持つというわけではなく、開発に携わる全員が責任を持っていくというスタイルでプロダクト開発をしているため、そうした姿勢を新卒メンバーに伝える上でも今回の講座はとても有用だったと考えています。 このような開発スタイルで日々プロダクトを作っているメンバーに興味が出て話を聞きたい! という方はぜひカジュアルにお話できればと思います。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの山田です。 今年も新卒入社で 6 人のメンバーがエンジニアとして入社しており、現在も絶賛新卒研修中となっています。毎年、新卒研修はプロセスやコンテンツを見直しているのですが、今年度は初めて Quality Assurance(以下 QA)についての講座を取り入れるようにしました。 今回は講師をお願いした QA エンジニアお二人にどのようなことを念頭に講義を実施したのかをインタビューしてみました。 今年から QA 講座を新卒研修のカリキュラムとして取り入れた理由について インタビュー本編をお届けする前に、今回 QA 講座を新卒研修に取り入れた理由について研修企画担当の 1 人としてご説明します。 QA 講座を新卒研修のカリキュラムに取り入れたいと思ったきっかけは、昨年の「開発実践研修」でアプリケーション開発の一環としてテスト設計も含めて実施していましたが、メンターとしてレビューをしている際「 せっかくメドレーには QA のスペシャリストがいるんだから、今回のレビューにも加わってもらえば良かった …」と感じたことでした。 今年はメンターではなく、新卒研修の企画・運営を主に担当することになり、昨年よりもさらに研修の質を上げるためにはどうするかを考えた時、上記のきっかけもあり QA エンジニアの皆さんには「開発実践研修」のテスト設計レビューを含め、座学による講義もお願いしたいと思うようになりました。 講義をお願いしたいと思った理由として大きく 3 つあります。 1. QA の経験不足を補う 全体的な傾向として弊社の新卒エンジニアは、インターンや学校の活動などで開発経験は相応にあるのですが、テスト設計をはじめとする QA を特に力を入れてやった経験が浅いという事実があります。その上でこれから先メドレーでプロダクト開発をする上では、テストや QA などについて自走して考え実施することができるようにしたかったため。 2. QA に対する認識を揃え、意識を高める 「QA とは何ぞや?」という話を専門性を持った QA エンジニアから新卒エンジニアに伝えてもらいプロダクトの QA に対して意識を高めてもらいたかったため。 3. 社内勉強会の内容がとても為になると感じた 弊社では、TechLunch という社内勉強会を開催していますが、その中で今回インタビューした QA エンジニアお二人の発表内容が大変良かったので、その内容をぜひ新卒エンジニアにも伝えてほしいと感じたため。 このような理由により、今年度からは QA 講座を研修の一部として開くことになりました。 さて、前置きが長くなりましたがそんな QA 講座を担当してくださった QA エンジニアのお二人へのインタビューをご覧ください。 インタビュイー紹介 上村さん 医療プラットフォーム第一本部 プロダクト開発室 第一開発グループに所属。クラウド診療支援システム CLINICS の医療機関側システム（カルテ、オンライン診療など）の品質向上活動を担当。 米山さん 医療プラットフォーム第一本部 プロダクト開発室 第一開発グループに所属。オンライン診療・服薬指導アプリ CLINICS のアプリ・ Web ・基盤を扱う開発チームで QA プロセス全般を担当。 左から上村さん・米山さん・筆者 QA 講座を担当した QA エンジニアのインタビュー チームの雰囲気 山田 : 早速ですが、お二人とも医療プラットフォームで QA を担当されていますが、所属しているチームの雰囲気はどんな感じなんでしょうか? 上村 : チームというよりもメドレーのエンジニア・デザイナーの皆さんに共通している話かもしれませんが、 セルフマネジメントできている方がとても多い と感じます。そういった方達なので視野を広く持っていて、開発の時にメンバー間で落ちそうなボールを自分でさっと拾って担当したりを自然にやっていますね。後は CLINICS の特に電子カルテは開発に必要なドメイン知識が広範囲で、私も入社して 2 年強経ちますが、未だに分かっていない部分などが出てくることもあり、そんな時でも 気軽に周囲のメンバーに聞ける雰囲気 なのが良いです。 山田 : 現在は QA エンジニアとして、仕様策定のフェイズから関わっていることが多いんでしょうか? 上村 : 関わり方はプロジェクトや時期により違っています。メインで担当するプロジェクトは最初から入って仕様レビューから関わる場合もありますし、複数のプロジェクトが平行している時は要所でアドバイス的な形を取る場合もあります。現在は開発中の大きいプロジェクトでの活動に振り切っているフェイズになっているところです。 山田 : 米山さんのチームの雰囲気などはいかがですか? 米山 : 上村さんとは違うチームに所属していますが、似た印象を持っています。一言で言うと「大人が集まっている」チームだと思います。ミーティングなどでも 本質を捉えた議論が多く、皆さん人格者で仕事ができる方々 だと感じています。今所属してるのが患者さんが使うアプリの開発チームで、Android / iOS / Web と 3 プラットフォームのプロダクト開発をしているのですが、1 人のエンジニアが 3 プラットフォーム全てを実装したりするのはこのチームの特徴の一つ かもしれません。他社さんと比較すると珍しい体制ではないかと思います。 山田 : なるほど。リソース効率を考えた結果のチーム運営なんですね。 研修のオファーの打診がされた時に考えたこと 山田 : 今回お二人に QA 講座の担当をオファーさせていただいた訳ですが、オファーを受けた時にどのような思いでしたか? 上村 : 「ついにこの時が来たか…!」と思いました w 山田 : QA の啓蒙をされている上村さんとしては、やはり講師のオファーを待ち望んでいたわけなんですね。 上村 : はい、私が入社したのが一昨年の 4 月だったので当時の新卒研修カリキュラムはもう決まっていたと思うのですが、もしその時にオファーが突然あっても大丈夫でした。去年はオファーが無かったので「まだ早いのかな」と少し残念だったのですが、 今年オファーがあって良かった です。 米山 : メドレーは元々プロダクト品質に対する意識が高いと感じているので、お話をもらった時に違和感はなかったです。こういった意識の高さは、経験豊富なメンバー達が作ってきた開発文化が社内に浸透しているからだと思います。ですので、 入社時にこうした研修を通して目線を合わせるという意味で良い取り組み だと考えています。 QA 研修コンテンツの準備 山田 : 今回の研修コンテンツを作る上で、工夫されていた点や意識されたポイントなどは、どのようなものがありましたか? 上村 : 準備段階で私のほうで素案を作ってから、直属の上司で研修の責任者でもある田中(医療 PF CTO)に相談したところ、「品質というのがプロダクトに取ってどれだけ重要なのかを教えてほしい」というオーダーを頂きました。 その後に米山さんと、どのように講義を分けるかを話し合い、私は QA の重要性や **QA とは?**をテーマにテスト技法の演習を通して、まずは「品質」という観点がいかにプロダクトを作る上で大事なのかという大枠を話すことになりました。一方で米山さんはより実務に即した観点から、メドレーでの具体的な取り組みや自動テスト、開発プロセスとの関わり方などを話すことになりました。 こんな形で役割分担はスムーズに決まりましたので、まずは研修目的を新卒のスキルレベルから考えて設定しました。研修全体では田中から「メドレーのエンジニアに求めること」の講座があり、内容としてはマインドセットなど抽象度が高めの内容になります。その後に具体的な「開発基礎研修」が続くので、ちょうどその中間的な抽象度になるように今回の講座は作るように意識しました。 私が考えるカリキュラムで大事にしているのは、 講義中にも手を動かしたり、自分でも考えてもらいながら参加してもらう 所なので、そこも意識しています。 山田 : ちょうど良い抽象度で QA の重要性を全般的に分かるようにまとめていったんですね。米山さんは、どんな点が挙げられますか? 米山 : 来年以降でも使えるようなコンテンツにしたい と考えていました。前職でも非 QA エンジニア向けの研修があったのですが、講義の感想で「もっと現場での実際の話なども聞いてみたかった」というような意見があるのを見ていたので、私のコンテンツでは抽象度が高い話だけではなく、実際のプロジェクトでの事例なども盛り込むようにしました。 また、 テスト自動化 なども人によって考え方も様々だったりするので、テストピラミッドの話なども含めて現実的な考え方や活用方法などを講座には入れています。 QA 研修講座について紹介 山田 : そのように工夫をして作っていただいた講座ですが、それぞれどのような内容だったのか教えていただけますか? 上村 : 一般的に知られる障害の事例として例えば「 チャレンジャー号爆発事故 」などを挙げて、まず**「品質」がプロダクトに与える影響について知ってもらう**ようにしました。事業ドメインなどが違う事例をいくつか挙げています。 後半では、具体的にどのように「品質を上げること」ができるかという部分にスポットを当てて紹介をしています。 上村の発表スライド 米山 : 私は具体的なメドレーでの品質向上のためにやっている取り組み（ Magic Pod 導入の話 など）や、品質とテストに対する考え方などをお話しました。またメドレーのメンバーの良い取り組み事例として ホットフィックスでも、きちんとテストコードを追加してリリース している部分などを、どう考えてこの対応をしたのだろうかというような事も講義内容に入れています。 講座についての手応え 山田 : お話を聞いていると、すごくバランスが取れた講座に仕上がってる印象を持ちました。講義をした手応えとしては、どんなものがありましたか? 米山 : 今回の講義はオンライン形式だったこともあり、少し一方通行で終わってしまったかもしれないなと思いました。もう少しカジュアルに質疑応答も含めてインタラクティブに新卒メンバーと交流できたら、もっと良かったかなと思います。( 編注: 今年はコロナ対策として、オンラインで研修を行ないました ) 上村 : 途中少し問いかけのタイミングなどもつくったんですけどもね。 山田 : 研修の時期的に新卒メンバーの緊張なんかもあったんでしょうね。話は変わりますが、今回 1 講座をお二人に担当していただきましたが、新卒研修全体へのお二人の印象などはどんなものでしょうか? 上村 : 羨ましいなと思っちゃいますね w 自分が IT 業界で働き始めた時は特に「即 OJT」という感じでしたので、コンテンツがとても充実していて、実業務に入る時にハードルが低くなると思います。 米山 : 規模がとても大きい企業で充実した研修というのは分かるのですが、現在のメドレーの規模でここまで充実した研修をしているのは凄いなと感じます。去年までに入社した新卒メンバーも配属後にすごく活躍しているのを見ているので、充実した研修が活きているのではないでしょうか。 自分が QA エンジニアのキャリアを始めた時にも、複数の研修を受けたのですが、今でもちゃんと記憶に残っている研修というのがあるので、講師側としてはそういった研修にできるようにしていきたいですね。 来年に向けて 山田 : これからの話もちょうど出てきたところなので、来年の QA 講座はどのようにバージョンアップしていきたいというアイディアはありますか? 上村 : 今回のように 90 分も良いのですが、 できれば 1 日ワークショップをやってみたい なと考えていました。それだけ時間があれば他にもやりたいことが盛り込めるなと思います。それだけの時間が確保できるかが課題なのですが…。あとは来年はできれば対面で実施できれば良いなと思います。 米山 : 新卒メンバーは私達の研修の後に「開発実践研修」で実際にプロダクトを作るフェイズがあるので、来年はその開発実践研修の内容とリンクさせて、 すぐに活用できるような実践的な話もできたらと考えています 。 上村 : 確かに何かアプリを触ってもらって、テスト観点はどういったものがあるかなんかを考えてもらうなども良いですね。 具体的なテスト技法とか考え方なんかは検索すれば出てくるものですが、実際にそれらをどう使うか、いつ使うかという点が難しいところなので、きちんと伝えていきたいです。 米山 : あとは中長期的な目標としては、こうした研修をしていくことによって 社内で QA エンジニアを志望する方が出てくるような講座 ができれば良いなという願望があります w 山田 : なるほど、社内スカウトができるように充実した研修にするということですね w 本日はありがとうございました。 おわりに 今年初めての試みである QA 新卒講座をどのように作っていったのかを、お送りしました。 メドレーでは QA エンジニアだけが品質に責任を持つというわけではなく、開発に携わる全員が責任を持っていくというスタイルでプロダクト開発をしているため、そうした姿勢を新卒メンバーに伝える上でも今回の講座はとても有用だったと考えています。 このような開発スタイルで日々プロダクトを作っているメンバーに興味が出て話を聞きたい! という方はぜひカジュアルにお話できればと思います。 https://www.medley.jp/jobs

はじめに みなさん、こんにちは。エンジニアの山田です。 今年も新卒入社で 6 人のメンバーがエンジニアとして入社しており、現在も絶賛新卒研修中となっています。毎年、新卒研修はプロセスやコンテンツを見直しているのですが、今年度は初めて Quality Assurance(以下 QA)についての講座を取り入れるようにしました。 今回は講師をお願いした QA エンジニアお二人にどのようなことを念頭に講義を実施したのかをインタビューしてみました。 今年から QA 講座を新卒研修のカリキュラムとして取り入れた理由について インタビュー本編をお届けする前に、今回 QA 講座を新卒研修に取り入れた理由について研修企画担当の 1 人としてご説明します。 QA 講座を新卒研修のカリキュラムに取り入れたいと思ったきっかけは、昨年の「開発実践研修」でアプリケーション開発の一環としてテスト設計も含めて実施していましたが、メンターとしてレビューをしている際「 せっかくメドレーには QA のスペシャリストがいるんだから、今回のレビューにも加わってもらえば良かった …」と感じたことでした。 今年はメンターではなく、新卒研修の企画・運営を主に担当することになり、昨年よりもさらに研修の質を上げるためにはどうするかを考えた時、上記のきっかけもあり QA エンジニアの皆さんには「開発実践研修」のテスト設計レビューを含め、座学による講義もお願いしたいと思うようになりました。 講義をお願いしたいと思った理由として大きく 3 つあります。 1. QA の経験不足を補う 全体的な傾向として弊社の新卒エンジニアは、インターンや学校の活動などで開発経験は相応にあるのですが、テスト設計をはじめとする QA を特に力を入れてやった経験が浅いという事実があります。その上でこれから先メドレーでプロダクト開発をする上では、テストや QA などについて自走して考え実施することができるようにしたかったため。 2. QA に対する認識を揃え、意識を高める 「QA とは何ぞや?」という話を専門性を持った QA エンジニアから新卒エンジニアに伝えてもらいプロダクトの QA に対して意識を高めてもらいたかったため。 3. 社内勉強会の内容がとても為になると感じた 弊社では、TechLunch という社内勉強会を開催していますが、その中で今回インタビューした QA エンジニアお二人の発表内容が大変良かったので、その内容をぜひ新卒エンジニアにも伝えてほしいと感じたため。 このような理由により、今年度からは QA 講座を研修の一部として開くことになりました。 さて、前置きが長くなりましたがそんな QA 講座を担当してくださった QA エンジニアのお二人へのインタビューをご覧ください。 インタビュイー紹介 上村さん 医療プラットフォーム第一本部 プロダクト開発室 第一開発グループに所属。クラウド診療支援システム CLINICS の医療機関側システム（カルテ、オンライン診療など）の品質向上活動を担当。 米山さん 医療プラットフォーム第一本部 プロダクト開発室 第一開発グループに所属。オンライン診療・服薬指導アプリ CLINICS のアプリ・ Web ・基盤を扱う開発チームで QA プロセス全般を担当。 左から上村さん・米山さん・筆者 QA 講座を担当した QA エンジニアのインタビュー チームの雰囲気 山田 : 早速ですが、お二人とも医療プラットフォームで QA を担当されていますが、所属しているチームの雰囲気はどんな感じなんでしょうか? 上村 : チームというよりもメドレーのエンジニア・デザイナーの皆さんに共通している話かもしれませんが、 セルフマネジメントできている方がとても多い と感じます。そういった方達なので視野を広く持っていて、開発の時にメンバー間で落ちそうなボールを自分でさっと拾って担当したりを自然にやっていますね。後は CLINICS の特に電子カルテは開発に必要なドメイン知識が広範囲で、私も入社して 2 年強経ちますが、未だに分かっていない部分などが出てくることもあり、そんな時でも 気軽に周囲のメンバーに聞ける雰囲気 なのが良いです。 山田 : 現在は QA エンジニアとして、仕様策定のフェイズから関わっていることが多いんでしょうか? 上村 : 関わり方はプロジェクトや時期により違っています。メインで担当するプロジェクトは最初から入って仕様レビューから関わる場合もありますし、複数のプロジェクトが平行している時は要所でアドバイス的な形を取る場合もあります。現在は開発中の大きいプロジェクトでの活動に振り切っているフェイズになっているところです。 山田 : 米山さんのチームの雰囲気などはいかがですか? 米山 : 上村さんとは違うチームに所属していますが、似た印象を持っています。一言で言うと「大人が集まっている」チームだと思います。ミーティングなどでも 本質を捉えた議論が多く、皆さん人格者で仕事ができる方々 だと感じています。今所属してるのが患者さんが使うアプリの開発チームで、Android / iOS / Web と 3 プラットフォームのプロダクト開発をしているのですが、1 人のエンジニアが 3 プラットフォーム全てを実装したりするのはこのチームの特徴の一つ かもしれません。他社さんと比較すると珍しい体制ではないかと思います。 山田 : なるほど。リソース効率を考えた結果のチーム運営なんですね。 研修のオファーの打診がされた時に考えたこと 山田 : 今回お二人に QA 講座の担当をオファーさせていただいた訳ですが、オファーを受けた時にどのような思いでしたか? 上村 : 「ついにこの時が来たか…!」と思いました w 山田 : QA の啓蒙をされている上村さんとしては、やはり講師のオファーを待ち望んでいたわけなんですね。 上村 : はい、私が入社したのが一昨年の 4 月だったので当時の新卒研修カリキュラムはもう決まっていたと思うのですが、もしその時にオファーが突然あっても大丈夫でした。去年はオファーが無かったので「まだ早いのかな」と少し残念だったのですが、 今年オファーがあって良かった です。 米山 : メドレーは元々プロダクト品質に対する意識が高いと感じているので、お話をもらった時に違和感はなかったです。こういった意識の高さは、経験豊富なメンバー達が作ってきた開発文化が社内に浸透しているからだと思います。ですので、 入社時にこうした研修を通して目線を合わせるという意味で良い取り組み だと考えています。 QA 研修コンテンツの準備 山田 : 今回の研修コンテンツを作る上で、工夫されていた点や意識されたポイントなどは、どのようなものがありましたか? 上村 : 準備段階で私のほうで素案を作ってから、直属の上司で研修の責任者でもある田中(医療 PF CTO)に相談したところ、「品質というのがプロダクトに取ってどれだけ重要なのかを教えてほしい」というオーダーを頂きました。 その後に米山さんと、どのように講義を分けるかを話し合い、私は QA の重要性や **QA とは?**をテーマにテスト技法の演習を通して、まずは「品質」という観点がいかにプロダクトを作る上で大事なのかという大枠を話すことになりました。一方で米山さんはより実務に即した観点から、メドレーでの具体的な取り組みや自動テスト、開発プロセスとの関わり方などを話すことになりました。 こんな形で役割分担はスムーズに決まりましたので、まずは研修目的を新卒のスキルレベルから考えて設定しました。研修全体では田中から「メドレーのエンジニアに求めること」の講座があり、内容としてはマインドセットなど抽象度が高めの内容になります。その後に具体的な「開発基礎研修」が続くので、ちょうどその中間的な抽象度になるように今回の講座は作るように意識しました。 私が考えるカリキュラムで大事にしているのは、 講義中にも手を動かしたり、自分でも考えてもらいながら参加してもらう 所なので、そこも意識しています。 山田 : ちょうど良い抽象度で QA の重要性を全般的に分かるようにまとめていったんですね。米山さんは、どんな点が挙げられますか? 米山 : 来年以降でも使えるようなコンテンツにしたい と考えていました。前職でも非 QA エンジニア向けの研修があったのですが、講義の感想で「もっと現場での実際の話なども聞いてみたかった」というような意見があるのを見ていたので、私のコンテンツでは抽象度が高い話だけではなく、実際のプロジェクトでの事例なども盛り込むようにしました。 また、 テスト自動化 なども人によって考え方も様々だったりするので、テストピラミッドの話なども含めて現実的な考え方や活用方法などを講座には入れています。 QA 研修講座について紹介 山田 : そのように工夫をして作っていただいた講座ですが、それぞれどのような内容だったのか教えていただけますか? 上村 : 一般的に知られる障害の事例として例えば「 チャレンジャー号爆発事故 」などを挙げて、まず**「品質」がプロダクトに与える影響について知ってもらう**ようにしました。事業ドメインなどが違う事例をいくつか挙げています。 後半では、具体的にどのように「品質を上げること」ができるかという部分にスポットを当てて紹介をしています。 上村の発表スライド 米山 : 私は具体的なメドレーでの品質向上のためにやっている取り組み（ Magic Pod 導入の話 など）や、品質とテストに対する考え方などをお話しました。またメドレーのメンバーの良い取り組み事例として ホットフィックスでも、きちんとテストコードを追加してリリース している部分などを、どう考えてこの対応をしたのだろうかというような事も講義内容に入れています。 講座についての手応え 山田 : お話を聞いていると、すごくバランスが取れた講座に仕上がってる印象を持ちました。講義をした手応えとしては、どんなものがありましたか? 米山 : 今回の講義はオンライン形式だったこともあり、少し一方通行で終わってしまったかもしれないなと思いました。もう少しカジュアルに質疑応答も含めてインタラクティブに新卒メンバーと交流できたら、もっと良かったかなと思います。( 編注: 今年はコロナ対策として、オンラインで研修を行ないました ) 上村 : 途中少し問いかけのタイミングなどもつくったんですけどもね。 山田 : 研修の時期的に新卒メンバーの緊張なんかもあったんでしょうね。話は変わりますが、今回 1 講座をお二人に担当していただきましたが、新卒研修全体へのお二人の印象などはどんなものでしょうか? 上村 : 羨ましいなと思っちゃいますね w 自分が IT 業界で働き始めた時は特に「即 OJT」という感じでしたので、コンテンツがとても充実していて、実業務に入る時にハードルが低くなると思います。 米山 : 規模がとても大きい企業で充実した研修というのは分かるのですが、現在のメドレーの規模でここまで充実した研修をしているのは凄いなと感じます。去年までに入社した新卒メンバーも配属後にすごく活躍しているのを見ているので、充実した研修が活きているのではないでしょうか。 自分が QA エンジニアのキャリアを始めた時にも、複数の研修を受けたのですが、今でもちゃんと記憶に残っている研修というのがあるので、講師側としてはそういった研修にできるようにしていきたいですね。 来年に向けて 山田 : これからの話もちょうど出てきたところなので、来年の QA 講座はどのようにバージョンアップしていきたいというアイディアはありますか? 上村 : 今回のように 90 分も良いのですが、 できれば 1 日ワークショップをやってみたい なと考えていました。それだけ時間があれば他にもやりたいことが盛り込めるなと思います。それだけの時間が確保できるかが課題なのですが…。あとは来年はできれば対面で実施できれば良いなと思います。 米山 : 新卒メンバーは私達の研修の後に「開発実践研修」で実際にプロダクトを作るフェイズがあるので、来年はその開発実践研修の内容とリンクさせて、 すぐに活用できるような実践的な話もできたらと考えています 。 上村 : 確かに何かアプリを触ってもらって、テスト観点はどういったものがあるかなんかを考えてもらうなども良いですね。 具体的なテスト技法とか考え方なんかは検索すれば出てくるものですが、実際にそれらをどう使うか、いつ使うかという点が難しいところなので、きちんと伝えていきたいです。 米山 : あとは中長期的な目標としては、こうした研修をしていくことによって 社内で QA エンジニアを志望する方が出てくるような講座 ができれば良いなという願望があります w 山田 : なるほど、社内スカウトができるように充実した研修にするということですね w 本日はありがとうございました。 おわりに 今年初めての試みである QA 新卒講座をどのように作っていったのかを、お送りしました。 メドレーでは QA エンジニアだけが品質に責任を持つというわけではなく、開発に携わる全員が責任を持っていくというスタイルでプロダクト開発をしているため、そうした姿勢を新卒メンバーに伝える上でも今回の講座はとても有用だったと考えています。 このような開発スタイルで日々プロダクトを作っているメンバーに興味が出て話を聞きたい! という方はぜひカジュアルにお話できればと思います。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの山田です。 今年も新卒入社で 6 人のメンバーがエンジニアとして入社しており、現在も絶賛新卒研修中となっています。毎年、新卒研修はプロセスやコンテンツを見直しているのですが、今年度は初めて Quality Assurance(以下 QA)についての講座を取り入れるようにしました。 今回は講師をお願いした QA エンジニアお二人にどのようなことを念頭に講義を実施したのかをインタビューしてみました。 今年から QA 講座を新卒研修のカリキュラムとして取り入れた理由について インタビュー本編をお届けする前に、今回 QA 講座を新卒研修に取り入れた理由について研修企画担当の 1 人としてご説明します。 QA 講座を新卒研修のカリキュラムに取り入れたいと思ったきっかけは、昨年の「開発実践研修」でアプリケーション開発の一環としてテスト設計も含めて実施していましたが、メンターとしてレビューをしている際「 せっかくメドレーには QA のスペシャリストがいるんだから、今回のレビューにも加わってもらえば良かった …」と感じたことでした。 今年はメンターではなく、新卒研修の企画・運営を主に担当することになり、昨年よりもさらに研修の質を上げるためにはどうするかを考えた時、上記のきっかけもあり QA エンジニアの皆さんには「開発実践研修」のテスト設計レビューを含め、座学による講義もお願いしたいと思うようになりました。 講義をお願いしたいと思った理由として大きく 3 つあります。 1. QA の経験不足を補う 全体的な傾向として弊社の新卒エンジニアは、インターンや学校の活動などで開発経験は相応にあるのですが、テスト設計をはじめとする QA を特に力を入れてやった経験が浅いという事実があります。その上でこれから先メドレーでプロダクト開発をする上では、テストや QA などについて自走して考え実施することができるようにしたかったため。 2. QA に対する認識を揃え、意識を高める 「QA とは何ぞや?」という話を専門性を持った QA エンジニアから新卒エンジニアに伝えてもらいプロダクトの QA に対して意識を高めてもらいたかったため。 3. 社内勉強会の内容がとても為になると感じた 弊社では、TechLunch という社内勉強会を開催していますが、その中で今回インタビューした QA エンジニアお二人の発表内容が大変良かったので、その内容をぜひ新卒エンジニアにも伝えてほしいと感じたため。 このような理由により、今年度からは QA 講座を研修の一部として開くことになりました。 さて、前置きが長くなりましたがそんな QA 講座を担当してくださった QA エンジニアのお二人へのインタビューをご覧ください。 インタビュイー紹介 上村さん 医療プラットフォーム第一本部 プロダクト開発室 第一開発グループに所属。クラウド診療支援システム CLINICS の医療機関側システム（カルテ、オンライン診療など）の品質向上活動を担当。 米山さん 医療プラットフォーム第一本部 プロダクト開発室 第一開発グループに所属。オンライン診療・服薬指導アプリ CLINICS のアプリ・ Web ・基盤を扱う開発チームで QA プロセス全般を担当。 左から上村さん・米山さん・筆者 QA 講座を担当した QA エンジニアのインタビュー チームの雰囲気 山田 : 早速ですが、お二人とも医療プラットフォームで QA を担当されていますが、所属しているチームの雰囲気はどんな感じなんでしょうか? 上村 : チームというよりもメドレーのエンジニア・デザイナーの皆さんに共通している話かもしれませんが、 セルフマネジメントできている方がとても多い と感じます。そういった方達なので視野を広く持っていて、開発の時にメンバー間で落ちそうなボールを自分でさっと拾って担当したりを自然にやっていますね。後は CLINICS の特に電子カルテは開発に必要なドメイン知識が広範囲で、私も入社して 2 年強経ちますが、未だに分かっていない部分などが出てくることもあり、そんな時でも 気軽に周囲のメンバーに聞ける雰囲気 なのが良いです。 山田 : 現在は QA エンジニアとして、仕様策定のフェイズから関わっていることが多いんでしょうか? 上村 : 関わり方はプロジェクトや時期により違っています。メインで担当するプロジェクトは最初から入って仕様レビューから関わる場合もありますし、複数のプロジェクトが平行している時は要所でアドバイス的な形を取る場合もあります。現在は開発中の大きいプロジェクトでの活動に振り切っているフェイズになっているところです。 山田 : 米山さんのチームの雰囲気などはいかがですか? 米山 : 上村さんとは違うチームに所属していますが、似た印象を持っています。一言で言うと「大人が集まっている」チームだと思います。ミーティングなどでも 本質を捉えた議論が多く、皆さん人格者で仕事ができる方々 だと感じています。今所属してるのが患者さんが使うアプリの開発チームで、Android / iOS / Web と 3 プラットフォームのプロダクト開発をしているのですが、1 人のエンジニアが 3 プラットフォーム全てを実装したりするのはこのチームの特徴の一つ かもしれません。他社さんと比較すると珍しい体制ではないかと思います。 山田 : なるほど。リソース効率を考えた結果のチーム運営なんですね。 研修のオファーの打診がされた時に考えたこと 山田 : 今回お二人に QA 講座の担当をオファーさせていただいた訳ですが、オファーを受けた時にどのような思いでしたか? 上村 : 「ついにこの時が来たか…!」と思いました w 山田 : QA の啓蒙をされている上村さんとしては、やはり講師のオファーを待ち望んでいたわけなんですね。 上村 : はい、私が入社したのが一昨年の 4 月だったので当時の新卒研修カリキュラムはもう決まっていたと思うのですが、もしその時にオファーが突然あっても大丈夫でした。去年はオファーが無かったので「まだ早いのかな」と少し残念だったのですが、 今年オファーがあって良かった です。 米山 : メドレーは元々プロダクト品質に対する意識が高いと感じているので、お話をもらった時に違和感はなかったです。こういった意識の高さは、経験豊富なメンバー達が作ってきた開発文化が社内に浸透しているからだと思います。ですので、 入社時にこうした研修を通して目線を合わせるという意味で良い取り組み だと考えています。 QA 研修コンテンツの準備 山田 : 今回の研修コンテンツを作る上で、工夫されていた点や意識されたポイントなどは、どのようなものがありましたか? 上村 : 準備段階で私のほうで素案を作ってから、直属の上司で研修の責任者でもある田中(医療 PF CTO)に相談したところ、「品質というのがプロダクトに取ってどれだけ重要なのかを教えてほしい」というオーダーを頂きました。 その後に米山さんと、どのように講義を分けるかを話し合い、私は QA の重要性や **QA とは?**をテーマにテスト技法の演習を通して、まずは「品質」という観点がいかにプロダクトを作る上で大事なのかという大枠を話すことになりました。一方で米山さんはより実務に即した観点から、メドレーでの具体的な取り組みや自動テスト、開発プロセスとの関わり方などを話すことになりました。 こんな形で役割分担はスムーズに決まりましたので、まずは研修目的を新卒のスキルレベルから考えて設定しました。研修全体では田中から「メドレーのエンジニアに求めること」の講座があり、内容としてはマインドセットなど抽象度が高めの内容になります。その後に具体的な「開発基礎研修」が続くので、ちょうどその中間的な抽象度になるように今回の講座は作るように意識しました。 私が考えるカリキュラムで大事にしているのは、 講義中にも手を動かしたり、自分でも考えてもらいながら参加してもらう 所なので、そこも意識しています。 山田 : ちょうど良い抽象度で QA の重要性を全般的に分かるようにまとめていったんですね。米山さんは、どんな点が挙げられますか? 米山 : 来年以降でも使えるようなコンテンツにしたい と考えていました。前職でも非 QA エンジニア向けの研修があったのですが、講義の感想で「もっと現場での実際の話なども聞いてみたかった」というような意見があるのを見ていたので、私のコンテンツでは抽象度が高い話だけではなく、実際のプロジェクトでの事例なども盛り込むようにしました。 また、 テスト自動化 なども人によって考え方も様々だったりするので、テストピラミッドの話なども含めて現実的な考え方や活用方法などを講座には入れています。 QA 研修講座について紹介 山田 : そのように工夫をして作っていただいた講座ですが、それぞれどのような内容だったのか教えていただけますか? 上村 : 一般的に知られる障害の事例として例えば「 チャレンジャー号爆発事故 」などを挙げて、まず**「品質」がプロダクトに与える影響について知ってもらう**ようにしました。事業ドメインなどが違う事例をいくつか挙げています。 後半では、具体的にどのように「品質を上げること」ができるかという部分にスポットを当てて紹介をしています。 上村の発表スライド 米山 : 私は具体的なメドレーでの品質向上のためにやっている取り組み（ Magic Pod 導入の話 など）や、品質とテストに対する考え方などをお話しました。またメドレーのメンバーの良い取り組み事例として ホットフィックスでも、きちんとテストコードを追加してリリース している部分などを、どう考えてこの対応をしたのだろうかというような事も講義内容に入れています。 講座についての手応え 山田 : お話を聞いていると、すごくバランスが取れた講座に仕上がってる印象を持ちました。講義をした手応えとしては、どんなものがありましたか? 米山 : 今回の講義はオンライン形式だったこともあり、少し一方通行で終わってしまったかもしれないなと思いました。もう少しカジュアルに質疑応答も含めてインタラクティブに新卒メンバーと交流できたら、もっと良かったかなと思います。( 編注: 今年はコロナ対策として、オンラインで研修を行ないました ) 上村 : 途中少し問いかけのタイミングなどもつくったんですけどもね。 山田 : 研修の時期的に新卒メンバーの緊張なんかもあったんでしょうね。話は変わりますが、今回 1 講座をお二人に担当していただきましたが、新卒研修全体へのお二人の印象などはどんなものでしょうか? 上村 : 羨ましいなと思っちゃいますね w 自分が IT 業界で働き始めた時は特に「即 OJT」という感じでしたので、コンテンツがとても充実していて、実業務に入る時にハードルが低くなると思います。 米山 : 規模がとても大きい企業で充実した研修というのは分かるのですが、現在のメドレーの規模でここまで充実した研修をしているのは凄いなと感じます。去年までに入社した新卒メンバーも配属後にすごく活躍しているのを見ているので、充実した研修が活きているのではないでしょうか。 自分が QA エンジニアのキャリアを始めた時にも、複数の研修を受けたのですが、今でもちゃんと記憶に残っている研修というのがあるので、講師側としてはそういった研修にできるようにしていきたいですね。 来年に向けて 山田 : これからの話もちょうど出てきたところなので、来年の QA 講座はどのようにバージョンアップしていきたいというアイディアはありますか? 上村 : 今回のように 90 分も良いのですが、 できれば 1 日ワークショップをやってみたい なと考えていました。それだけ時間があれば他にもやりたいことが盛り込めるなと思います。それだけの時間が確保できるかが課題なのですが…。あとは来年はできれば対面で実施できれば良いなと思います。 米山 : 新卒メンバーは私達の研修の後に「開発実践研修」で実際にプロダクトを作るフェイズがあるので、来年はその開発実践研修の内容とリンクさせて、 すぐに活用できるような実践的な話もできたらと考えています 。 上村 : 確かに何かアプリを触ってもらって、テスト観点はどういったものがあるかなんかを考えてもらうなども良いですね。 具体的なテスト技法とか考え方なんかは検索すれば出てくるものですが、実際にそれらをどう使うか、いつ使うかという点が難しいところなので、きちんと伝えていきたいです。 米山 : あとは中長期的な目標としては、こうした研修をしていくことによって 社内で QA エンジニアを志望する方が出てくるような講座 ができれば良いなという願望があります w 山田 : なるほど、社内スカウトができるように充実した研修にするということですね w 本日はありがとうございました。 おわりに 今年初めての試みである QA 新卒講座をどのように作っていったのかを、お送りしました。 メドレーでは QA エンジニアだけが品質に責任を持つというわけではなく、開発に携わる全員が責任を持っていくというスタイルでプロダクト開発をしているため、そうした姿勢を新卒メンバーに伝える上でも今回の講座はとても有用だったと考えています。 このような開発スタイルで日々プロダクトを作っているメンバーに興味が出て話を聞きたい! という方はぜひカジュアルにお話できればと思います。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの山田です。 今年も新卒入社で 6 人のメンバーがエンジニアとして入社しており、現在も絶賛新卒研修中となっています。毎年、新卒研修はプロセスやコンテンツを見直しているのですが、今年度は初めて Quality Assurance(以下 QA)についての講座を取り入れるようにしました。 今回は講師をお願いした QA エンジニアお二人にどのようなことを念頭に講義を実施したのかをインタビューしてみました。 今年から QA 講座を新卒研修のカリキュラムとして取り入れた理由について インタビュー本編をお届けする前に、今回 QA 講座を新卒研修に取り入れた理由について研修企画担当の 1 人としてご説明します。 QA 講座を新卒研修のカリキュラムに取り入れたいと思ったきっかけは、昨年の「開発実践研修」でアプリケーション開発の一環としてテスト設計も含めて実施していましたが、メンターとしてレビューをしている際「 せっかくメドレーには QA のスペシャリストがいるんだから、今回のレビューにも加わってもらえば良かった …」と感じたことでした。 今年はメンターではなく、新卒研修の企画・運営を主に担当することになり、昨年よりもさらに研修の質を上げるためにはどうするかを考えた時、上記のきっかけもあり QA エンジニアの皆さんには「開発実践研修」のテスト設計レビューを含め、座学による講義もお願いしたいと思うようになりました。 講義をお願いしたいと思った理由として大きく 3 つあります。 1. QA の経験不足を補う 全体的な傾向として弊社の新卒エンジニアは、インターンや学校の活動などで開発経験は相応にあるのですが、テスト設計をはじめとする QA を特に力を入れてやった経験が浅いという事実があります。その上でこれから先メドレーでプロダクト開発をする上では、テストや QA などについて自走して考え実施することができるようにしたかったため。 2. QA に対する認識を揃え、意識を高める 「QA とは何ぞや?」という話を専門性を持った QA エンジニアから新卒エンジニアに伝えてもらいプロダクトの QA に対して意識を高めてもらいたかったため。 3. 社内勉強会の内容がとても為になると感じた 弊社では、TechLunch という社内勉強会を開催していますが、その中で今回インタビューした QA エンジニアお二人の発表内容が大変良かったので、その内容をぜひ新卒エンジニアにも伝えてほしいと感じたため。 このような理由により、今年度からは QA 講座を研修の一部として開くことになりました。 さて、前置きが長くなりましたがそんな QA 講座を担当してくださった QA エンジニアのお二人へのインタビューをご覧ください。 インタビュイー紹介 上村さん 医療プラットフォーム第一本部 プロダクト開発室 第一開発グループに所属。クラウド診療支援システム CLINICS の医療機関側システム（カルテ、オンライン診療など）の品質向上活動を担当。 米山さん 医療プラットフォーム第一本部 プロダクト開発室 第一開発グループに所属。オンライン診療・服薬指導アプリ CLINICS のアプリ・ Web ・基盤を扱う開発チームで QA プロセス全般を担当。 左から上村さん・米山さん・筆者 QA 講座を担当した QA エンジニアのインタビュー チームの雰囲気 山田 : 早速ですが、お二人とも医療プラットフォームで QA を担当されていますが、所属しているチームの雰囲気はどんな感じなんでしょうか? 上村 : チームというよりもメドレーのエンジニア・デザイナーの皆さんに共通している話かもしれませんが、 セルフマネジメントできている方がとても多い と感じます。そういった方達なので視野を広く持っていて、開発の時にメンバー間で落ちそうなボールを自分でさっと拾って担当したりを自然にやっていますね。後は CLINICS の特に電子カルテは開発に必要なドメイン知識が広範囲で、私も入社して 2 年強経ちますが、未だに分かっていない部分などが出てくることもあり、そんな時でも 気軽に周囲のメンバーに聞ける雰囲気 なのが良いです。 山田 : 現在は QA エンジニアとして、仕様策定のフェイズから関わっていることが多いんでしょうか? 上村 : 関わり方はプロジェクトや時期により違っています。メインで担当するプロジェクトは最初から入って仕様レビューから関わる場合もありますし、複数のプロジェクトが平行している時は要所でアドバイス的な形を取る場合もあります。現在は開発中の大きいプロジェクトでの活動に振り切っているフェイズになっているところです。 山田 : 米山さんのチームの雰囲気などはいかがですか? 米山 : 上村さんとは違うチームに所属していますが、似た印象を持っています。一言で言うと「大人が集まっている」チームだと思います。ミーティングなどでも 本質を捉えた議論が多く、皆さん人格者で仕事ができる方々 だと感じています。今所属してるのが患者さんが使うアプリの開発チームで、Android / iOS / Web と 3 プラットフォームのプロダクト開発をしているのですが、1 人のエンジニアが 3 プラットフォーム全てを実装したりするのはこのチームの特徴の一つ かもしれません。他社さんと比較すると珍しい体制ではないかと思います。 山田 : なるほど。リソース効率を考えた結果のチーム運営なんですね。 研修のオファーの打診がされた時に考えたこと 山田 : 今回お二人に QA 講座の担当をオファーさせていただいた訳ですが、オファーを受けた時にどのような思いでしたか? 上村 : 「ついにこの時が来たか…!」と思いました w 山田 : QA の啓蒙をされている上村さんとしては、やはり講師のオファーを待ち望んでいたわけなんですね。 上村 : はい、私が入社したのが一昨年の 4 月だったので当時の新卒研修カリキュラムはもう決まっていたと思うのですが、もしその時にオファーが突然あっても大丈夫でした。去年はオファーが無かったので「まだ早いのかな」と少し残念だったのですが、 今年オファーがあって良かった です。 米山 : メドレーは元々プロダクト品質に対する意識が高いと感じているので、お話をもらった時に違和感はなかったです。こういった意識の高さは、経験豊富なメンバー達が作ってきた開発文化が社内に浸透しているからだと思います。ですので、 入社時にこうした研修を通して目線を合わせるという意味で良い取り組み だと考えています。 QA 研修コンテンツの準備 山田 : 今回の研修コンテンツを作る上で、工夫されていた点や意識されたポイントなどは、どのようなものがありましたか? 上村 : 準備段階で私のほうで素案を作ってから、直属の上司で研修の責任者でもある田中(医療 PF CTO)に相談したところ、「品質というのがプロダクトに取ってどれだけ重要なのかを教えてほしい」というオーダーを頂きました。 その後に米山さんと、どのように講義を分けるかを話し合い、私は QA の重要性や **QA とは?**をテーマにテスト技法の演習を通して、まずは「品質」という観点がいかにプロダクトを作る上で大事なのかという大枠を話すことになりました。一方で米山さんはより実務に即した観点から、メドレーでの具体的な取り組みや自動テスト、開発プロセスとの関わり方などを話すことになりました。 こんな形で役割分担はスムーズに決まりましたので、まずは研修目的を新卒のスキルレベルから考えて設定しました。研修全体では田中から「メドレーのエンジニアに求めること」の講座があり、内容としてはマインドセットなど抽象度が高めの内容になります。その後に具体的な「開発基礎研修」が続くので、ちょうどその中間的な抽象度になるように今回の講座は作るように意識しました。 私が考えるカリキュラムで大事にしているのは、 講義中にも手を動かしたり、自分でも考えてもらいながら参加してもらう 所なので、そこも意識しています。 山田 : ちょうど良い抽象度で QA の重要性を全般的に分かるようにまとめていったんですね。米山さんは、どんな点が挙げられますか? 米山 : 来年以降でも使えるようなコンテンツにしたい と考えていました。前職でも非 QA エンジニア向けの研修があったのですが、講義の感想で「もっと現場での実際の話なども聞いてみたかった」というような意見があるのを見ていたので、私のコンテンツでは抽象度が高い話だけではなく、実際のプロジェクトでの事例なども盛り込むようにしました。 また、 テスト自動化 なども人によって考え方も様々だったりするので、テストピラミッドの話なども含めて現実的な考え方や活用方法などを講座には入れています。 QA 研修講座について紹介 山田 : そのように工夫をして作っていただいた講座ですが、それぞれどのような内容だったのか教えていただけますか? 上村 : 一般的に知られる障害の事例として例えば「 チャレンジャー号爆発事故 」などを挙げて、まず**「品質」がプロダクトに与える影響について知ってもらう**ようにしました。事業ドメインなどが違う事例をいくつか挙げています。 後半では、具体的にどのように「品質を上げること」ができるかという部分にスポットを当てて紹介をしています。 上村の発表スライド 米山 : 私は具体的なメドレーでの品質向上のためにやっている取り組み（ Magic Pod 導入の話 など）や、品質とテストに対する考え方などをお話しました。またメドレーのメンバーの良い取り組み事例として ホットフィックスでも、きちんとテストコードを追加してリリース している部分などを、どう考えてこの対応をしたのだろうかというような事も講義内容に入れています。 講座についての手応え 山田 : お話を聞いていると、すごくバランスが取れた講座に仕上がってる印象を持ちました。講義をした手応えとしては、どんなものがありましたか? 米山 : 今回の講義はオンライン形式だったこともあり、少し一方通行で終わってしまったかもしれないなと思いました。もう少しカジュアルに質疑応答も含めてインタラクティブに新卒メンバーと交流できたら、もっと良かったかなと思います。( 編注: 今年はコロナ対策として、オンラインで研修を行ないました ) 上村 : 途中少し問いかけのタイミングなどもつくったんですけどもね。 山田 : 研修の時期的に新卒メンバーの緊張なんかもあったんでしょうね。話は変わりますが、今回 1 講座をお二人に担当していただきましたが、新卒研修全体へのお二人の印象などはどんなものでしょうか? 上村 : 羨ましいなと思っちゃいますね w 自分が IT 業界で働き始めた時は特に「即 OJT」という感じでしたので、コンテンツがとても充実していて、実業務に入る時にハードルが低くなると思います。 米山 : 規模がとても大きい企業で充実した研修というのは分かるのですが、現在のメドレーの規模でここまで充実した研修をしているのは凄いなと感じます。去年までに入社した新卒メンバーも配属後にすごく活躍しているのを見ているので、充実した研修が活きているのではないでしょうか。 自分が QA エンジニアのキャリアを始めた時にも、複数の研修を受けたのですが、今でもちゃんと記憶に残っている研修というのがあるので、講師側としてはそういった研修にできるようにしていきたいですね。 来年に向けて 山田 : これからの話もちょうど出てきたところなので、来年の QA 講座はどのようにバージョンアップしていきたいというアイディアはありますか? 上村 : 今回のように 90 分も良いのですが、 できれば 1 日ワークショップをやってみたい なと考えていました。それだけ時間があれば他にもやりたいことが盛り込めるなと思います。それだけの時間が確保できるかが課題なのですが…。あとは来年はできれば対面で実施できれば良いなと思います。 米山 : 新卒メンバーは私達の研修の後に「開発実践研修」で実際にプロダクトを作るフェイズがあるので、来年はその開発実践研修の内容とリンクさせて、 すぐに活用できるような実践的な話もできたらと考えています 。 上村 : 確かに何かアプリを触ってもらって、テスト観点はどういったものがあるかなんかを考えてもらうなども良いですね。 具体的なテスト技法とか考え方なんかは検索すれば出てくるものですが、実際にそれらをどう使うか、いつ使うかという点が難しいところなので、きちんと伝えていきたいです。 米山 : あとは中長期的な目標としては、こうした研修をしていくことによって 社内で QA エンジニアを志望する方が出てくるような講座 ができれば良いなという願望があります w 山田 : なるほど、社内スカウトができるように充実した研修にするということですね w 本日はありがとうございました。 おわりに 今年初めての試みである QA 新卒講座をどのように作っていったのかを、お送りしました。 メドレーでは QA エンジニアだけが品質に責任を持つというわけではなく、開発に携わる全員が責任を持っていくというスタイルでプロダクト開発をしているため、そうした姿勢を新卒メンバーに伝える上でも今回の講座はとても有用だったと考えています。 このような開発スタイルで日々プロダクトを作っているメンバーに興味が出て話を聞きたい! という方はぜひカジュアルにお話できればと思います。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの山田です。 今年も新卒入社で 6 人のメンバーがエンジニアとして入社しており、現在も絶賛新卒研修中となっています。毎年、新卒研修はプロセスやコンテンツを見直しているのですが、今年度は初めて Quality Assurance(以下 QA)についての講座を取り入れるようにしました。 今回は講師をお願いした QA エンジニアお二人にどのようなことを念頭に講義を実施したのかをインタビューしてみました。 今年から QA 講座を新卒研修のカリキュラムとして取り入れた理由について インタビュー本編をお届けする前に、今回 QA 講座を新卒研修に取り入れた理由について研修企画担当の 1 人としてご説明します。 QA 講座を新卒研修のカリキュラムに取り入れたいと思ったきっかけは、昨年の「開発実践研修」でアプリケーション開発の一環としてテスト設計も含めて実施していましたが、メンターとしてレビューをしている際「 せっかくメドレーには QA のスペシャリストがいるんだから、今回のレビューにも加わってもらえば良かった …」と感じたことでした。 今年はメンターではなく、新卒研修の企画・運営を主に担当することになり、昨年よりもさらに研修の質を上げるためにはどうするかを考えた時、上記のきっかけもあり QA エンジニアの皆さんには「開発実践研修」のテスト設計レビューを含め、座学による講義もお願いしたいと思うようになりました。 講義をお願いしたいと思った理由として大きく 3 つあります。 1. QA の経験不足を補う 全体的な傾向として弊社の新卒エンジニアは、インターンや学校の活動などで開発経験は相応にあるのですが、テスト設計をはじめとする QA を特に力を入れてやった経験が浅いという事実があります。その上でこれから先メドレーでプロダクト開発をする上では、テストや QA などについて自走して考え実施することができるようにしたかったため。 2. QA に対する認識を揃え、意識を高める 「QA とは何ぞや?」という話を専門性を持った QA エンジニアから新卒エンジニアに伝えてもらいプロダクトの QA に対して意識を高めてもらいたかったため。 3. 社内勉強会の内容がとても為になると感じた 弊社では、TechLunch という社内勉強会を開催していますが、その中で今回インタビューした QA エンジニアお二人の発表内容が大変良かったので、その内容をぜひ新卒エンジニアにも伝えてほしいと感じたため。 このような理由により、今年度からは QA 講座を研修の一部として開くことになりました。 さて、前置きが長くなりましたがそんな QA 講座を担当してくださった QA エンジニアのお二人へのインタビューをご覧ください。 インタビュイー紹介 上村さん 医療プラットフォーム第一本部 プロダクト開発室 第一開発グループに所属。クラウド診療支援システム CLINICS の医療機関側システム（カルテ、オンライン診療など）の品質向上活動を担当。 米山さん 医療プラットフォーム第一本部 プロダクト開発室 第一開発グループに所属。オンライン診療・服薬指導アプリ CLINICS のアプリ・ Web ・基盤を扱う開発チームで QA プロセス全般を担当。 左から上村さん・米山さん・筆者 QA 講座を担当した QA エンジニアのインタビュー チームの雰囲気 山田 : 早速ですが、お二人とも医療プラットフォームで QA を担当されていますが、所属しているチームの雰囲気はどんな感じなんでしょうか? 上村 : チームというよりもメドレーのエンジニア・デザイナーの皆さんに共通している話かもしれませんが、 セルフマネジメントできている方がとても多い と感じます。そういった方達なので視野を広く持っていて、開発の時にメンバー間で落ちそうなボールを自分でさっと拾って担当したりを自然にやっていますね。後は CLINICS の特に電子カルテは開発に必要なドメイン知識が広範囲で、私も入社して 2 年強経ちますが、未だに分かっていない部分などが出てくることもあり、そんな時でも 気軽に周囲のメンバーに聞ける雰囲気 なのが良いです。 山田 : 現在は QA エンジニアとして、仕様策定のフェイズから関わっていることが多いんでしょうか? 上村 : 関わり方はプロジェクトや時期により違っています。メインで担当するプロジェクトは最初から入って仕様レビューから関わる場合もありますし、複数のプロジェクトが平行している時は要所でアドバイス的な形を取る場合もあります。現在は開発中の大きいプロジェクトでの活動に振り切っているフェイズになっているところです。 山田 : 米山さんのチームの雰囲気などはいかがですか? 米山 : 上村さんとは違うチームに所属していますが、似た印象を持っています。一言で言うと「大人が集まっている」チームだと思います。ミーティングなどでも 本質を捉えた議論が多く、皆さん人格者で仕事ができる方々 だと感じています。今所属してるのが患者さんが使うアプリの開発チームで、Android / iOS / Web と 3 プラットフォームのプロダクト開発をしているのですが、1 人のエンジニアが 3 プラットフォーム全てを実装したりするのはこのチームの特徴の一つ かもしれません。他社さんと比較すると珍しい体制ではないかと思います。 山田 : なるほど。リソース効率を考えた結果のチーム運営なんですね。 研修のオファーの打診がされた時に考えたこと 山田 : 今回お二人に QA 講座の担当をオファーさせていただいた訳ですが、オファーを受けた時にどのような思いでしたか? 上村 : 「ついにこの時が来たか…!」と思いました w 山田 : QA の啓蒙をされている上村さんとしては、やはり講師のオファーを待ち望んでいたわけなんですね。 上村 : はい、私が入社したのが一昨年の 4 月だったので当時の新卒研修カリキュラムはもう決まっていたと思うのですが、もしその時にオファーが突然あっても大丈夫でした。去年はオファーが無かったので「まだ早いのかな」と少し残念だったのですが、 今年オファーがあって良かった です。 米山 : メドレーは元々プロダクト品質に対する意識が高いと感じているので、お話をもらった時に違和感はなかったです。こういった意識の高さは、経験豊富なメンバー達が作ってきた開発文化が社内に浸透しているからだと思います。ですので、 入社時にこうした研修を通して目線を合わせるという意味で良い取り組み だと考えています。 QA 研修コンテンツの準備 山田 : 今回の研修コンテンツを作る上で、工夫されていた点や意識されたポイントなどは、どのようなものがありましたか? 上村 : 準備段階で私のほうで素案を作ってから、直属の上司で研修の責任者でもある田中(医療 PF CTO)に相談したところ、「品質というのがプロダクトに取ってどれだけ重要なのかを教えてほしい」というオーダーを頂きました。 その後に米山さんと、どのように講義を分けるかを話し合い、私は QA の重要性や **QA とは?**をテーマにテスト技法の演習を通して、まずは「品質」という観点がいかにプロダクトを作る上で大事なのかという大枠を話すことになりました。一方で米山さんはより実務に即した観点から、メドレーでの具体的な取り組みや自動テスト、開発プロセスとの関わり方などを話すことになりました。 こんな形で役割分担はスムーズに決まりましたので、まずは研修目的を新卒のスキルレベルから考えて設定しました。研修全体では田中から「メドレーのエンジニアに求めること」の講座があり、内容としてはマインドセットなど抽象度が高めの内容になります。その後に具体的な「開発基礎研修」が続くので、ちょうどその中間的な抽象度になるように今回の講座は作るように意識しました。 私が考えるカリキュラムで大事にしているのは、 講義中にも手を動かしたり、自分でも考えてもらいながら参加してもらう 所なので、そこも意識しています。 山田 : ちょうど良い抽象度で QA の重要性を全般的に分かるようにまとめていったんですね。米山さんは、どんな点が挙げられますか? 米山 : 来年以降でも使えるようなコンテンツにしたい と考えていました。前職でも非 QA エンジニア向けの研修があったのですが、講義の感想で「もっと現場での実際の話なども聞いてみたかった」というような意見があるのを見ていたので、私のコンテンツでは抽象度が高い話だけではなく、実際のプロジェクトでの事例なども盛り込むようにしました。 また、 テスト自動化 なども人によって考え方も様々だったりするので、テストピラミッドの話なども含めて現実的な考え方や活用方法などを講座には入れています。 QA 研修講座について紹介 山田 : そのように工夫をして作っていただいた講座ですが、それぞれどのような内容だったのか教えていただけますか? 上村 : 一般的に知られる障害の事例として例えば「 チャレンジャー号爆発事故 」などを挙げて、まず**「品質」がプロダクトに与える影響について知ってもらう**ようにしました。事業ドメインなどが違う事例をいくつか挙げています。 後半では、具体的にどのように「品質を上げること」ができるかという部分にスポットを当てて紹介をしています。 上村の発表スライド 米山 : 私は具体的なメドレーでの品質向上のためにやっている取り組み（ Magic Pod 導入の話 など）や、品質とテストに対する考え方などをお話しました。またメドレーのメンバーの良い取り組み事例として ホットフィックスでも、きちんとテストコードを追加してリリース している部分などを、どう考えてこの対応をしたのだろうかというような事も講義内容に入れています。 講座についての手応え 山田 : お話を聞いていると、すごくバランスが取れた講座に仕上がってる印象を持ちました。講義をした手応えとしては、どんなものがありましたか? 米山 : 今回の講義はオンライン形式だったこともあり、少し一方通行で終わってしまったかもしれないなと思いました。もう少しカジュアルに質疑応答も含めてインタラクティブに新卒メンバーと交流できたら、もっと良かったかなと思います。( 編注: 今年はコロナ対策として、オンラインで研修を行ないました ) 上村 : 途中少し問いかけのタイミングなどもつくったんですけどもね。 山田 : 研修の時期的に新卒メンバーの緊張なんかもあったんでしょうね。話は変わりますが、今回 1 講座をお二人に担当していただきましたが、新卒研修全体へのお二人の印象などはどんなものでしょうか? 上村 : 羨ましいなと思っちゃいますね w 自分が IT 業界で働き始めた時は特に「即 OJT」という感じでしたので、コンテンツがとても充実していて、実業務に入る時にハードルが低くなると思います。 米山 : 規模がとても大きい企業で充実した研修というのは分かるのですが、現在のメドレーの規模でここまで充実した研修をしているのは凄いなと感じます。去年までに入社した新卒メンバーも配属後にすごく活躍しているのを見ているので、充実した研修が活きているのではないでしょうか。 自分が QA エンジニアのキャリアを始めた時にも、複数の研修を受けたのですが、今でもちゃんと記憶に残っている研修というのがあるので、講師側としてはそういった研修にできるようにしていきたいですね。 来年に向けて 山田 : これからの話もちょうど出てきたところなので、来年の QA 講座はどのようにバージョンアップしていきたいというアイディアはありますか? 上村 : 今回のように 90 分も良いのですが、 できれば 1 日ワークショップをやってみたい なと考えていました。それだけ時間があれば他にもやりたいことが盛り込めるなと思います。それだけの時間が確保できるかが課題なのですが…。あとは来年はできれば対面で実施できれば良いなと思います。 米山 : 新卒メンバーは私達の研修の後に「開発実践研修」で実際にプロダクトを作るフェイズがあるので、来年はその開発実践研修の内容とリンクさせて、 すぐに活用できるような実践的な話もできたらと考えています 。 上村 : 確かに何かアプリを触ってもらって、テスト観点はどういったものがあるかなんかを考えてもらうなども良いですね。 具体的なテスト技法とか考え方なんかは検索すれば出てくるものですが、実際にそれらをどう使うか、いつ使うかという点が難しいところなので、きちんと伝えていきたいです。 米山 : あとは中長期的な目標としては、こうした研修をしていくことによって 社内で QA エンジニアを志望する方が出てくるような講座 ができれば良いなという願望があります w 山田 : なるほど、社内スカウトができるように充実した研修にするということですね w 本日はありがとうございました。 おわりに 今年初めての試みである QA 新卒講座をどのように作っていったのかを、お送りしました。 メドレーでは QA エンジニアだけが品質に責任を持つというわけではなく、開発に携わる全員が責任を持っていくというスタイルでプロダクト開発をしているため、そうした姿勢を新卒メンバーに伝える上でも今回の講座はとても有用だったと考えています。 このような開発スタイルで日々プロダクトを作っているメンバーに興味が出て話を聞きたい! という方はぜひカジュアルにお話できればと思います。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの新居です。 今回は 2021 年新卒入社のエンジニア 5 人に対し、 新卒研修 を終えてからこれまでにプロダクト開発業務を進めている中で、どのように新卒研修が活きているのかを振り返ってもらおうという座談会の様子をお送りしようと思います。 今までブログでお伝えしてきた新卒研修はメンター側の立場で書かれていましたが、当時メンティーだった 2021 年新卒メンバーの紹介をしながら、初めての試みとしてメンティー側はどのようなことを当時考えていたのかをお伝えできればと思います。 2021 年新卒入社メンバー紹介 (左から)筆者 / 内田さん / 高橋さん / 堀内さん / 佐々岡さん / 寺内さん 高橋さん 医療プラットフォーム第一本部 プロダクト開発室 第二開発グループ所属。CLINICS の開発を担当。現在は周辺領域拡張プロジェクトに携わる。 佐々岡さん 人材プラットフォーム本部 プロダクト開発室 第一開発グループ所属。ジョブメドレーの開発を担当。現在は求職者側の UI/UX 改善などの開発に携わる。 寺内さん 人材プラットフォーム本部 プロダクト開発室 第三開発グループ所属。介護のほんねの開発を担当。定常開発や新機能開発に携わる。 堀内さん 人材プラットフォーム本部 プロダクト開発室 第一開発グループ所属。ジョブメドレーの開発を担当。現在は求職者側の UI/UX 改善などの開発に携わる。 内田さん 医療プラットフォーム第一本部 プロダクト開発室 第四開発グループ所属。CLINICS の開発を担当。現在は CLINICS カルテの基幹システムの開発に携わる。 チームの雰囲気について メドレー入社後 1 年が経ち、5 人の皆さんはどのような雰囲気のチームで働いているかを話してもらいました。 高橋 : CLINICS の中でもうちのチームは 出社頻度が高めで対面でコミュニケーションを取る機会が多い ですね。新規機能を中心に開発しているので、細かな調整がしやすくスピード感を持って開発できています。 内田 : 自分は別のチームなんですが、夕会をスタンディングでやっているのを見てカッコいいなと思っていて羨しいです w 佐々岡 : ジョブメドレーチームの雰囲気としては結構リモートで開発している方の割合が多めです。 家庭持ちの方とかは家で実装していたりすることが多い です。デザイナーとエンジニアはすごく近い距離で仕事をしています。 その中で自分は、主に求職者の応募体験を良くするための改善などを行なっています。 寺内 : 介護のほんねは、プロダクト開発チームがコンパクトなので他のみんなと違い明確に担当が分かれているということはないです。自分は社内ツールの業務改善系の開発を担当することが多いです。 社内ツールの非効率な部分を改善したり、定常業務で必要になるシステム改善や修正を主に手がけています。 サーバーサイドの開発が主で、必要に応じてフロントエンドの開発も行なっています。チームの雰囲気は、 締めるところは締める雰囲気 です。MTG なども少なめなので、実装や考えることに時間を使っていける環境です。 佐々岡 : 寺内はチームのプロダクト責任者が直接メンタリングしてくれるのが良いなーと思っています。 寺内 : そうですね。 直属の上司にレビューを含め、メンタリングなどもしていただいている ので、ありがたいです。 堀内 : 自分も佐々岡と一緒でジョブメドレーの開発を担当しています。自分が思うチームの雰囲気ですが、「温和なチーム」と感じています。 心理的安全性が高いチームですね。 自分が今担当しているのは求職者側の UI/UX 改善であったり、ページのパフォーマンス改善などです。開発の特徴としては、開発案件を進めるときに すぐにプロダクトマネージャやリードエンジニアといった方々と会話して進めていける 部分でしょうか。 ジョブメドレー自体、サービスとしては 10 年選手です。ですから、業務フローが大変成熟したものになっています。 洗練された企画・開発フローを実際に体感しながら開発できる、という環境がとても勉強になります ね。 またこのフローは ドキュメントドリブン という考え方で作られた資料に基いていますので、後から蓄積された知見をキャッチアップすることも容易ですし、リモートの人と出社している人との間で齟齬が起きることなく仕事が進められています。 内田 : CLINICS 電子カルテの基盤チームで開発しています。基盤チームでは本当にこれぞカルテという部分を扱っているので、レセプトに関係する部分なども担当しています。 チームの特徴としては、チーム構成として デザイナーやディレクターといった職種の方達がいるんですが、彼らと一緒に会話をしながら、開発を進めていく ということでしょうか。 職種で分けずに全員で認識を揃えながらの開発ができています。あとはメドレーのデザイナーは多かれ少なかれ全員そうだと思うのですが、特に今のチームのデザイナーは自分でフロントエンドの React.js のコードを書いているので、手戻りなども無くすごく仕事がやりやすい環境です。こうした環境で自分が要件から考えて実装していくという開発をできているのが、とてもやりがいがあります。 それぞれ配属されているチームが違うこともあり、チームの雰囲気などはやはり色々と違うようです。しかし、共通してチームで動きながら職種に囚われずに要件定義から関わって開発をしているというところは、全員が感じているようですね。 今までのプログラミング経験 次の話題として、21 年入社メンバーの入社前のプログラミング経験について聞いてみました。みなさんどんな形でプログラミングに関わってきたんでしょうか? 高橋 : プログラミングを始めたのは高校 1 年生の頃からです。 中学生のころからコンピュータに触れはじめて漠然とプログラミングの勉強がしたい という思いから、情報系学科に入学してゲームプログラミングから始めたのが最初です。 大学時代は、実践型のプロジェクト学習に力を入れている公立はこだて未来大学で様々な開発経験を積みました。学部 3 年生の 1 年間は、4 大学合同でチーム開発をするという講義の中で iOS アプリケーションの開発を経験しました。 学部 4 年生からは、都内にある SIer 企業の社内システムを開発する学内プロジェクトに参加しました。他にもエンジニアとして働けるサマーインターンにも参加しました。 内田 : 自分達と同世代だと中学生のときくらいに、例えば PSP を始めとした ゲーム機だとか、家のパソコンを触っていくことをきっかけにして、プログラミングに興味を持つ という人が多い印象です。この 5 人の共通の思い出として、やっぱりこの辺の話題が出てきたりします。 佐々岡 : 自分が プログラミングを始めたのは、情報系の大学に入ってから でした。始めてからは Ruby on Rails での開発や Python の Django での開発をアルバイトで経験を積んでいきました。サークルでも PHP を使った Web アプリケーションを作ったりと、のめり込んでいました。 堀内 : 自分は大学では情報系学科ではなく、経済学部を専攻しました。高校のときは理系コースで「理系の大学に行くんだ」と頑張っていたんですが、どちらかというと文系科目の方が好きだったので、数学の知識も使いつつ文系である経済学を選んだ形です。 プログラミングの原体験は Web になります。もうサービスは無くなってしまったんですが、 中学生のときに Yahoo!ジオシティーズというホームページを簡単に作れるというサービスに夢中になった 時期がありました。 このサービスはエディタにテキストを入れると HTML が生成されるというシステムだったんで、そこでこういった感じで Web が出来るんだなと思い面白いなと思ったのがきっかけです。そこから色を変えたいから CSS を勉強する、クジ引きアプリ作りたいから JavaScript を勉強するみたいな感じで、のめり込んでいきました。 中高くらいにスマホが出てきたんですが、当時カスタムされた OS が流通していて、そういうのも面白いと触っていました。同時期にブログを運営していたのでその時に PHP での開発をしていきました。一通り Web プログラミングが出来るようになってからは、個人事業主として開発や保守を受託することが多く、その時のお仕事で、フロント / バックエンド / インフラ 満遍なく貴重な経験をさせて頂けたと思います。 内田 : 僕は 小学校 3~4 年生くらいに最初にプログラミングに触れました 。当時、宇宙がすごく好きでちょうど JAXA が小学生向けのプロジェクトやっていてそれがロボットの開発をするというものだったんです。そのロボットの制御をするためにプログラミングが必要になって触り始めたのが最初です。 中学生で Web プログラミングに触れまして。ちょうど YouTube が盛り上るくらいのタイミングだったんで、今でいう YouTuber っぽい活動していてその宣伝のためのホームページを作るためにサイトを作ったりしていました。 でも、そこからはあんまりプログラミングに触れていなくて、大学 2 年生くらいになって部活でアプリ開発をやり始めて、それがスケールアップして起業もしました。 その会社は儲からなくて閉じたんですが、そこからある程度プログラミング経験が積めたなと思ったので、医療系を含む、色々な企業でインターンとしてプログラミングをしていました。そこからメドレーに入社しました。 寺内 : 僕も佐々岡と一緒で大学に入ってからでした。高校のときは遺伝子に興味があったんですが、Web 広告で プログラマーについて知ってこっちの方がより面白そうだと思って情報系学科に入る ことにしました。 サークルで知りあった人にインターンをおすすめされたので、1 年生の後半あたりからずっとインターンとしてプログラミングをしていました。その中にメドレーもありました。 話を聞くと皆さん大分早い段階からプログラミングに興味を持ち出していますね。大学でインターンを有効活用してスキルアップしてきた人も多いです。最近あまり言わないですが、デジタルネイティブという印象です。 メドレーに入社を決めた理由 そうした経験を積んできた 5 人はどんな理由でメドレーの入社を決めたのかが気になるので、聞いてみました。 高橋 : 就活の軸として、社会的な課題を解決するプロダクトの開発に携わりたいという思いがありました。 この軸は、大学時代までに個人開発やプロジェクトを通して開発してきた成果物が、思うような価値を生み出せなかったという悔しさが原体験としてあったためです。そこから課題解決が好きだったこともあり、エンジニアリングを通して大きな社会課題を解決したいという考えを持つようになりました。 最終的には、インターンシップや就活を通して社員の方々から話を伺った中で「医療ヘルスケアの未来をつくる」という メドレーのミッションに強く惹かれ 入社を決めました。 佐々岡 : 生活のインフラに直結する分野の社会課題を解決するという所が良かったので、メドレーに入社しました。もう一つの理由としてはメドレーの「ドキュメントドリブン」という文化に心惹かれたからです。 色々 社内の知見などをきちんとドキュメント化している ので、そういったドキュメントを参考にしていれば、自分の成長スピードも早くなるのではと思いました。 内田 : 他の人と同じで、医療という大きいドメインでの課題解決をしているという点はもちろんなんですが、働いている エンジニアの方々が少数精鋭でレベルが高いなと感じた のも大きいです。 そんな中で、新卒入社のエンジニアの人数もそこまで多くはないので、入社したらそんな方達と一緒に仕事ができるようになるなと感じたからです。 堀内 : 就活の軸として、自分が成長できそうか・風通しが良いか・合理的な社風かなどを軸として探していました。将来的には経営をしたいと考えているので、 ビジネス側と開発側の距離が近い ことも考えて総合的にメドレーが良さそうだと考えて入社しました。 寺内 : 私はメドレーの夏の インターンシップに参加したのですが、医療・ヘルスケアドメインの課題の多さと、それに正面から向き合うメドレーという会社が非常にエキサイティングだと感じた のが、きっかけです。 そこから自分の医療の原体験というのを考えたときに、高校の時に親族が難病かもしれないという疑いが出てきたという出来事がありました。結局は大丈夫だったのですが、その時に医療情報などの探しにくさなどを実感したことを思い起しました。メドレーはそうした問題に取り組んでいる会社だというのが一番の理由でした。もちろん優秀な方が働いているというのもあります。 メドレーが「医療」という分野での事業をしているということに共感して入社している方が多いですね。共通して自分が作ったものが、社会にインパクトを生み出せるか?ということを意識しているメンバーが多いと思いました。 2021 年度新卒研修の感想 ここからは、新卒研修を受けた感想を 1 年越しに聞いてみたいと思います。特にチームとして開発をしていった「開発実践研修」について中心に聞いてみました。当時は大変なこともあったと思いますが、経験を積んだ今はどのような感想を持っているのでしょうか。 研修で良かったこと 佐々岡 : 開発実践研修で良かったのはまず、 要件定義からリリースまで一気通貫にできたので自分のその時点での不足している部分というのが可視化されたこと でした。 また開発するツールはそのまま社内で使い続けていくものだったので、レビュアーの方にも親身になってレビューしていただけたり、そういった所が良かった所です。 開発実践では React.js を使って開発をしていたんですが、配属されてからも業務として使って活きている部分です。 メドレーで開発業務をするということが、どういうものかをこの研修を通じて勉強 できました。 おかげで、配属された後も違和感なく実務ができるようになりました。 高橋 : エンジニアとしてこれからプロとして開発をしていく上で自信が付いたのが良かったです。 学生のときは作って終わりというプロダクトが多かったのですが、 社会人になって初めて作ったプロダクトが今も毎日稼動しているということで、エンジニアとしての自信に繋がりました 。 この経験のおかげで、現在の業務でも自分が違和感などを感じたりしたときには、「間違ってるかな」などと臆せずにズバズバと言えるようになっています。 現在のプロジェクトは要件の固まりきっていない新機能を開発しているフェーズなので、日々の業務に活かせている実感があります。 堀内 : 今に繋がってるなと思っているのは チームがちゃんと目標を持っているときと、そこがあやふやだったときのチームのパフォーマンスの出方が全然違うというのを体験 できた点です。 開発中は自分はチームリードとして、チームビルディングを中心に行っていたのですが、ちゃんと目標をイメージできる形にする・そのイメージをチームで認識が揃うまでしっかりと擦り合せる、という 2 点に注意していました。 最初の目的をちゃんと話しあって固めた後は、朝会などでちゃんとメンバーの作業について共有していくようにしたら、上手くチームが回り始めました。最初にイメージを固めたら、MTG を小まめにしなくてもちゃんと作業が進んでいきました。 寺内 : 「開発実践研修」の前に受講した外部研修の「ビジネススタンス研修」が良かったです。研修の序盤に受けられて 社会人としてのスタンスが学べたのが良かった です。ここで習ったことが、開発実践研修でチームで話し合う場でもきちんと応用できましたし、もちろん業務をしている今でもちゃんと活きていると実感しています。研修の全メニューが良かったと感じているのは言うまでもないかもしれませんが w 研修で大変だったこと 佐々岡 : 最初の段階での要件定義のときに課題設定が想定と違ってきたことが一番大変でした。 研修企画側から予め提示されていた課題と自分達が考えた要件定義とのズレを、 Miro を使ってのミーティングを繰り返して修正するまでに、時間がかかってしまいました。そうしたミーティングなどで課題の解決方法などを構造化して考えたりしていき、ようやく修正できました。 この経験で 最初の課題設定も正しいかどうかを鵜呑みにせずに、ちゃんと自分達で調べて納得するような形にしないといけない ということを学べました。 高橋 : やはり要件定義フェイズでした。当初の予定より大分伸びてしまいました。これは着地点が不明確なまま、議論が進んでしまっていたのが原因でした。 対応として 全員でちゃんとコンセンサスを取りながら、着地点を明確にして要件定義をやり直した 結果立て直すことができました。要件定義をしっかりやるというのはこの研修が初めてに近い状態だったので、大変でした。 当時フワフワとした状態で進めてしまったところが反省点だったので、不明な部分などは自分の中で全部つぶした上で開発するということが大事なんだということが学べました。 内田 : 要件定義していた最初の 1 週間は本当に進みが悪くて大変でした。1 週間経ってようやく**「自分達がオーナーシップを取らないと開発が進まない」ということを実感**したので、そこから勢いが付いた感じです。それまではどこか自分事として捉えられてなかったんだと思います。 寺内 : 最初のほうではメンバーの向き不向きとか性格などがやはり分からなかったので、お互いの期待値調整が大変だったなと思います。 最初の時点で目的に対する姿勢も、メンバーごとに温度感が違いました。そこで、全員でお互いの得意・不得意などや期待することを、擦り合せる時間を作ってようやく役割分担もできました。 これで、ようやくスタートラインに立ってゴールもそこに至る道筋も明確になりました。自分は 今のチームでも上司や同僚に自分の情報を開示しつつ、期待値を把握して仕事をする ことによって目指すべき場所が認識できるようになり、仕事が円滑に進むようになった実感があります。 研修については、皆さんそろっての初の共同作業ということもあり、苦労も達成感も感じていますね。 現在の業務にも、きちんと活きているというのは嬉しい限りです。要件定義から自分達でオーナーシップを持って目的を持ってチームで開発をするという、実践的な研修を心がけていたので、ちゃんとそこを経験してもらっているようです。 今後について 最後にメンバーそれぞれの皆さんにこれから目指すエンジニア像を聞いてみました。 佐々岡 : 今後は ビジネス側の知見・現場の課題感・プロダクトのあるべき姿という 3 つの視点をきちんと身につけていけるエンジニア になっていきたいと思っています。 現時点ではまだまだという自覚があるので、これから色々な先輩方の背中を追いかけつつ、成長していきたいと思います。 高橋 : 今はプロダクトマネージャやリーダーがプロダクトの根本的な基本要件を考えて、そこから詳細要件を自分達が考えて実装しているのですが、行く行くはそうした 基本要件から自分で考えて、周りと連携しつつ実装していけるようになりたい です。 ここまで出来るようになると、自分が社会にインパクトを与えるプロダクトを作ったと胸を張って言えるんじゃないかなと思っています。 堀内 : 将来的には経営者の道を目指そうと思っています。ただ、プロダクト開発をしっかり理解し、一定の技術力を身につけていない状態では、人も付いてこないと思うんです。 ですので、 説得力を持てるくらい技術力を身につけていきたい と思います。まだ出来てないと自覚しているのですが、自分が勉強させて頂いている部分を、早くチームの方達に恩返しできるようにしてきたいです。 内田 : 元々課題解決するプロダクトを作りたいという思いで入社しましたが、実現するためには 3 つやることがあると思っています。 1 つは「解決のために最適解を選択できること」です。これは幅広い技術を身につけたエンジニアになることかなと思っています。 2 つ目は「ちゃんとドメイン知識を習得すること」です。最適解を選ぶのにも業務知識が無いままだと絶対に良い選択をできないと考えています。 最後は「自分の考えをきちんと推し進められるビジネススキル」です。色々と関わる人にちゃんとコミュニケーションを取って、自分が良いと思うものを広められればと考えています。メドレーは 自分が凄いと思ったエンジニアの方達がたくさんいらっしゃるので、行く行くは自分もそう思われる位になれたら …と思います。 寺内 : なりたいエンジニア像については、既にみんなに言いたいことを言われているんですが w 直近の目標は、マネージャから見ても「一人前である」と思われる実力を身につけたエンジニアになることです。 また、内側に目を向けられるエンジニアになることも目標です。新機能や定常業務の開発だけではなく、部署内の 開発以外の人達が気持ち良く働けるようになる開発をしていけば、顧客などにも良い影響が出て、結果として事業の成長になる のではないかと考えています。 ですので、部署の皆さんにも喜んでもらえるような一人前のエンジニアになっていきたいですね。 現在は技術や仕事の仕方などを吸収しながらぐんぐんと成長している皆さんですが、最終的な目標はプロダクトに貢献できるようにという背景を感じます。ちゃんとビジネス面も分かったエンジニアにという考え方を持っていてメドレーでエンジニアに求められる部分を意識しているなと思いました。 おわりに 21 年入社エンジニアの座談会はいかがでしたでしょうか。 メドレーの新卒研修を受けた側の感想を公開するのは初めての試みでしたが、自分もインタビューをしていて改めて当時メンバーの皆さんが苦悩していた部分や、現在に活きている部分などを聞けて勉強になりました。 今年も既に 22 年新卒入社のエンジニアメンバーが研修をしている真っ最中ですが、こうした経験などを後輩に伝えてもらうと、より良い組織になっていくのではないかと思っています。 最後に 一緒に医療の未来を作っていく仲間を募集 しているので、この記事を読んでメドレーに興味が湧いた方はぜひ、話をしましょう! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの新居です。 今回は 2021 年新卒入社のエンジニア 5 人に対し、 新卒研修 を終えてからこれまでにプロダクト開発業務を進めている中で、どのように新卒研修が活きているのかを振り返ってもらおうという座談会の様子をお送りしようと思います。 今までブログでお伝えしてきた新卒研修はメンター側の立場で書かれていましたが、当時メンティーだった 2021 年新卒メンバーの紹介をしながら、初めての試みとしてメンティー側はどのようなことを当時考えていたのかをお伝えできればと思います。 2021 年新卒入社メンバー紹介 (左から)筆者 / 内田さん / 高橋さん / 堀内さん / 佐々岡さん / 寺内さん 高橋さん 医療プラットフォーム第一本部 プロダクト開発室 第二開発グループ所属。CLINICS の開発を担当。現在は周辺領域拡張プロジェクトに携わる。 佐々岡さん 人材プラットフォーム本部 プロダクト開発室 第一開発グループ所属。ジョブメドレーの開発を担当。現在は求職者側の UI/UX 改善などの開発に携わる。 寺内さん 人材プラットフォーム本部 プロダクト開発室 第三開発グループ所属。介護のほんねの開発を担当。定常開発や新機能開発に携わる。 堀内さん 人材プラットフォーム本部 プロダクト開発室 第一開発グループ所属。ジョブメドレーの開発を担当。現在は求職者側の UI/UX 改善などの開発に携わる。 内田さん 医療プラットフォーム第一本部 プロダクト開発室 第四開発グループ所属。CLINICS の開発を担当。現在は CLINICS カルテの基幹システムの開発に携わる。 チームの雰囲気について メドレー入社後 1 年が経ち、5 人の皆さんはどのような雰囲気のチームで働いているかを話してもらいました。 高橋 : CLINICS の中でもうちのチームは 出社頻度が高めで対面でコミュニケーションを取る機会が多い ですね。新規機能を中心に開発しているので、細かな調整がしやすくスピード感を持って開発できています。 内田 : 自分は別のチームなんですが、夕会をスタンディングでやっているのを見てカッコいいなと思っていて羨しいです w 佐々岡 : ジョブメドレーチームの雰囲気としては結構リモートで開発している方の割合が多めです。 家庭持ちの方とかは家で実装していたりすることが多い です。デザイナーとエンジニアはすごく近い距離で仕事をしています。 その中で自分は、主に求職者の応募体験を良くするための改善などを行なっています。 寺内 : 介護のほんねは、プロダクト開発チームがコンパクトなので他のみんなと違い明確に担当が分かれているということはないです。自分は社内ツールの業務改善系の開発を担当することが多いです。 社内ツールの非効率な部分を改善したり、定常業務で必要になるシステム改善や修正を主に手がけています。 サーバーサイドの開発が主で、必要に応じてフロントエンドの開発も行なっています。チームの雰囲気は、 締めるところは締める雰囲気 です。MTG なども少なめなので、実装や考えることに時間を使っていける環境です。 佐々岡 : 寺内はチームのプロダクト責任者が直接メンタリングしてくれるのが良いなーと思っています。 寺内 : そうですね。 直属の上司にレビューを含め、メンタリングなどもしていただいている ので、ありがたいです。 堀内 : 自分も佐々岡と一緒でジョブメドレーの開発を担当しています。自分が思うチームの雰囲気ですが、「温和なチーム」と感じています。 心理的安全性が高いチームですね。 自分が今担当しているのは求職者側の UI/UX 改善であったり、ページのパフォーマンス改善などです。開発の特徴としては、開発案件を進めるときに すぐにプロダクトマネージャやリードエンジニアといった方々と会話して進めていける 部分でしょうか。 ジョブメドレー自体、サービスとしては 10 年選手です。ですから、業務フローが大変成熟したものになっています。 洗練された企画・開発フローを実際に体感しながら開発できる、という環境がとても勉強になります ね。 またこのフローは ドキュメントドリブン という考え方で作られた資料に基いていますので、後から蓄積された知見をキャッチアップすることも容易ですし、リモートの人と出社している人との間で齟齬が起きることなく仕事が進められています。 内田 : CLINICS 電子カルテの基盤チームで開発しています。基盤チームでは本当にこれぞカルテという部分を扱っているので、レセプトに関係する部分なども担当しています。 チームの特徴としては、チーム構成として デザイナーやディレクターといった職種の方達がいるんですが、彼らと一緒に会話をしながら、開発を進めていく ということでしょうか。 職種で分けずに全員で認識を揃えながらの開発ができています。あとはメドレーのデザイナーは多かれ少なかれ全員そうだと思うのですが、特に今のチームのデザイナーは自分でフロントエンドの React.js のコードを書いているので、手戻りなども無くすごく仕事がやりやすい環境です。こうした環境で自分が要件から考えて実装していくという開発をできているのが、とてもやりがいがあります。 それぞれ配属されているチームが違うこともあり、チームの雰囲気などはやはり色々と違うようです。しかし、共通してチームで動きながら職種に囚われずに要件定義から関わって開発をしているというところは、全員が感じているようですね。 今までのプログラミング経験 次の話題として、21 年入社メンバーの入社前のプログラミング経験について聞いてみました。みなさんどんな形でプログラミングに関わってきたんでしょうか? 高橋 : プログラミングを始めたのは高校 1 年生の頃からです。 中学生のころからコンピュータに触れはじめて漠然とプログラミングの勉強がしたい という思いから、情報系学科に入学してゲームプログラミングから始めたのが最初です。 大学時代は、実践型のプロジェクト学習に力を入れている公立はこだて未来大学で様々な開発経験を積みました。学部 3 年生の 1 年間は、4 大学合同でチーム開発をするという講義の中で iOS アプリケーションの開発を経験しました。 学部 4 年生からは、都内にある SIer 企業の社内システムを開発する学内プロジェクトに参加しました。他にもエンジニアとして働けるサマーインターンにも参加しました。 内田 : 自分達と同世代だと中学生のときくらいに、例えば PSP を始めとした ゲーム機だとか、家のパソコンを触っていくことをきっかけにして、プログラミングに興味を持つ という人が多い印象です。この 5 人の共通の思い出として、やっぱりこの辺の話題が出てきたりします。 佐々岡 : 自分が プログラミングを始めたのは、情報系の大学に入ってから でした。始めてからは Ruby on Rails での開発や Python の Django での開発をアルバイトで経験を積んでいきました。サークルでも PHP を使った Web アプリケーションを作ったりと、のめり込んでいました。 堀内 : 自分は大学では情報系学科ではなく、経済学部を専攻しました。高校のときは理系コースで「理系の大学に行くんだ」と頑張っていたんですが、どちらかというと文系科目の方が好きだったので、数学の知識も使いつつ文系である経済学を選んだ形です。 プログラミングの原体験は Web になります。もうサービスは無くなってしまったんですが、 中学生のときに Yahoo!ジオシティーズというホームページを簡単に作れるというサービスに夢中になった 時期がありました。 このサービスはエディタにテキストを入れると HTML が生成されるというシステムだったんで、そこでこういった感じで Web が出来るんだなと思い面白いなと思ったのがきっかけです。そこから色を変えたいから CSS を勉強する、クジ引きアプリ作りたいから JavaScript を勉強するみたいな感じで、のめり込んでいきました。 中高くらいにスマホが出てきたんですが、当時カスタムされた OS が流通していて、そういうのも面白いと触っていました。同時期にブログを運営していたのでその時に PHP での開発をしていきました。一通り Web プログラミングが出来るようになってからは、個人事業主として開発や保守を受託することが多く、その時のお仕事で、フロント / バックエンド / インフラ 満遍なく貴重な経験をさせて頂けたと思います。 内田 : 僕は 小学校 3~4 年生くらいに最初にプログラミングに触れました 。当時、宇宙がすごく好きでちょうど JAXA が小学生向けのプロジェクトやっていてそれがロボットの開発をするというものだったんです。そのロボットの制御をするためにプログラミングが必要になって触り始めたのが最初です。 中学生で Web プログラミングに触れまして。ちょうど YouTube が盛り上るくらいのタイミングだったんで、今でいう YouTuber っぽい活動していてその宣伝のためのホームページを作るためにサイトを作ったりしていました。 でも、そこからはあんまりプログラミングに触れていなくて、大学 2 年生くらいになって部活でアプリ開発をやり始めて、それがスケールアップして起業もしました。 その会社は儲からなくて閉じたんですが、そこからある程度プログラミング経験が積めたなと思ったので、医療系を含む、色々な企業でインターンとしてプログラミングをしていました。そこからメドレーに入社しました。 寺内 : 僕も佐々岡と一緒で大学に入ってからでした。高校のときは遺伝子に興味があったんですが、Web 広告で プログラマーについて知ってこっちの方がより面白そうだと思って情報系学科に入る ことにしました。 サークルで知りあった人にインターンをおすすめされたので、1 年生の後半あたりからずっとインターンとしてプログラミングをしていました。その中にメドレーもありました。 話を聞くと皆さん大分早い段階からプログラミングに興味を持ち出していますね。大学でインターンを有効活用してスキルアップしてきた人も多いです。最近あまり言わないですが、デジタルネイティブという印象です。 メドレーに入社を決めた理由 そうした経験を積んできた 5 人はどんな理由でメドレーの入社を決めたのかが気になるので、聞いてみました。 高橋 : 就活の軸として、社会的な課題を解決するプロダクトの開発に携わりたいという思いがありました。 この軸は、大学時代までに個人開発やプロジェクトを通して開発してきた成果物が、思うような価値を生み出せなかったという悔しさが原体験としてあったためです。そこから課題解決が好きだったこともあり、エンジニアリングを通して大きな社会課題を解決したいという考えを持つようになりました。 最終的には、インターンシップや就活を通して社員の方々から話を伺った中で「医療ヘルスケアの未来をつくる」という メドレーのミッションに強く惹かれ 入社を決めました。 佐々岡 : 生活のインフラに直結する分野の社会課題を解決するという所が良かったので、メドレーに入社しました。もう一つの理由としてはメドレーの「ドキュメントドリブン」という文化に心惹かれたからです。 色々 社内の知見などをきちんとドキュメント化している ので、そういったドキュメントを参考にしていれば、自分の成長スピードも早くなるのではと思いました。 内田 : 他の人と同じで、医療という大きいドメインでの課題解決をしているという点はもちろんなんですが、働いている エンジニアの方々が少数精鋭でレベルが高いなと感じた のも大きいです。 そんな中で、新卒入社のエンジニアの人数もそこまで多くはないので、入社したらそんな方達と一緒に仕事ができるようになるなと感じたからです。 堀内 : 就活の軸として、自分が成長できそうか・風通しが良いか・合理的な社風かなどを軸として探していました。将来的には経営をしたいと考えているので、 ビジネス側と開発側の距離が近い ことも考えて総合的にメドレーが良さそうだと考えて入社しました。 寺内 : 私はメドレーの夏の インターンシップに参加したのですが、医療・ヘルスケアドメインの課題の多さと、それに正面から向き合うメドレーという会社が非常にエキサイティングだと感じた のが、きっかけです。 そこから自分の医療の原体験というのを考えたときに、高校の時に親族が難病かもしれないという疑いが出てきたという出来事がありました。結局は大丈夫だったのですが、その時に医療情報などの探しにくさなどを実感したことを思い起しました。メドレーはそうした問題に取り組んでいる会社だというのが一番の理由でした。もちろん優秀な方が働いているというのもあります。 メドレーが「医療」という分野での事業をしているということに共感して入社している方が多いですね。共通して自分が作ったものが、社会にインパクトを生み出せるか?ということを意識しているメンバーが多いと思いました。 2021 年度新卒研修の感想 ここからは、新卒研修を受けた感想を 1 年越しに聞いてみたいと思います。特にチームとして開発をしていった「開発実践研修」について中心に聞いてみました。当時は大変なこともあったと思いますが、経験を積んだ今はどのような感想を持っているのでしょうか。 研修で良かったこと 佐々岡 : 開発実践研修で良かったのはまず、 要件定義からリリースまで一気通貫にできたので自分のその時点での不足している部分というのが可視化されたこと でした。 また開発するツールはそのまま社内で使い続けていくものだったので、レビュアーの方にも親身になってレビューしていただけたり、そういった所が良かった所です。 開発実践では React.js を使って開発をしていたんですが、配属されてからも業務として使って活きている部分です。 メドレーで開発業務をするということが、どういうものかをこの研修を通じて勉強 できました。 おかげで、配属された後も違和感なく実務ができるようになりました。 高橋 : エンジニアとしてこれからプロとして開発をしていく上で自信が付いたのが良かったです。 学生のときは作って終わりというプロダクトが多かったのですが、 社会人になって初めて作ったプロダクトが今も毎日稼動しているということで、エンジニアとしての自信に繋がりました 。 この経験のおかげで、現在の業務でも自分が違和感などを感じたりしたときには、「間違ってるかな」などと臆せずにズバズバと言えるようになっています。 現在のプロジェクトは要件の固まりきっていない新機能を開発しているフェーズなので、日々の業務に活かせている実感があります。 堀内 : 今に繋がってるなと思っているのは チームがちゃんと目標を持っているときと、そこがあやふやだったときのチームのパフォーマンスの出方が全然違うというのを体験 できた点です。 開発中は自分はチームリードとして、チームビルディングを中心に行っていたのですが、ちゃんと目標をイメージできる形にする・そのイメージをチームで認識が揃うまでしっかりと擦り合せる、という 2 点に注意していました。 最初の目的をちゃんと話しあって固めた後は、朝会などでちゃんとメンバーの作業について共有していくようにしたら、上手くチームが回り始めました。最初にイメージを固めたら、MTG を小まめにしなくてもちゃんと作業が進んでいきました。 寺内 : 「開発実践研修」の前に受講した外部研修の「ビジネススタンス研修」が良かったです。研修の序盤に受けられて 社会人としてのスタンスが学べたのが良かった です。ここで習ったことが、開発実践研修でチームで話し合う場でもきちんと応用できましたし、もちろん業務をしている今でもちゃんと活きていると実感しています。研修の全メニューが良かったと感じているのは言うまでもないかもしれませんが w 研修で大変だったこと 佐々岡 : 最初の段階での要件定義のときに課題設定が想定と違ってきたことが一番大変でした。 研修企画側から予め提示されていた課題と自分達が考えた要件定義とのズレを、 Miro を使ってのミーティングを繰り返して修正するまでに、時間がかかってしまいました。そうしたミーティングなどで課題の解決方法などを構造化して考えたりしていき、ようやく修正できました。 この経験で 最初の課題設定も正しいかどうかを鵜呑みにせずに、ちゃんと自分達で調べて納得するような形にしないといけない ということを学べました。 高橋 : やはり要件定義フェイズでした。当初の予定より大分伸びてしまいました。これは着地点が不明確なまま、議論が進んでしまっていたのが原因でした。 対応として 全員でちゃんとコンセンサスを取りながら、着地点を明確にして要件定義をやり直した 結果立て直すことができました。要件定義をしっかりやるというのはこの研修が初めてに近い状態だったので、大変でした。 当時フワフワとした状態で進めてしまったところが反省点だったので、不明な部分などは自分の中で全部つぶした上で開発するということが大事なんだということが学べました。 内田 : 要件定義していた最初の 1 週間は本当に進みが悪くて大変でした。1 週間経ってようやく**「自分達がオーナーシップを取らないと開発が進まない」ということを実感**したので、そこから勢いが付いた感じです。それまではどこか自分事として捉えられてなかったんだと思います。 寺内 : 最初のほうではメンバーの向き不向きとか性格などがやはり分からなかったので、お互いの期待値調整が大変だったなと思います。 最初の時点で目的に対する姿勢も、メンバーごとに温度感が違いました。そこで、全員でお互いの得意・不得意などや期待することを、擦り合せる時間を作ってようやく役割分担もできました。 これで、ようやくスタートラインに立ってゴールもそこに至る道筋も明確になりました。自分は 今のチームでも上司や同僚に自分の情報を開示しつつ、期待値を把握して仕事をする ことによって目指すべき場所が認識できるようになり、仕事が円滑に進むようになった実感があります。 研修については、皆さんそろっての初の共同作業ということもあり、苦労も達成感も感じていますね。 現在の業務にも、きちんと活きているというのは嬉しい限りです。要件定義から自分達でオーナーシップを持って目的を持ってチームで開発をするという、実践的な研修を心がけていたので、ちゃんとそこを経験してもらっているようです。 今後について 最後にメンバーそれぞれの皆さんにこれから目指すエンジニア像を聞いてみました。 佐々岡 : 今後は ビジネス側の知見・現場の課題感・プロダクトのあるべき姿という 3 つの視点をきちんと身につけていけるエンジニア になっていきたいと思っています。 現時点ではまだまだという自覚があるので、これから色々な先輩方の背中を追いかけつつ、成長していきたいと思います。 高橋 : 今はプロダクトマネージャやリーダーがプロダクトの根本的な基本要件を考えて、そこから詳細要件を自分達が考えて実装しているのですが、行く行くはそうした 基本要件から自分で考えて、周りと連携しつつ実装していけるようになりたい です。 ここまで出来るようになると、自分が社会にインパクトを与えるプロダクトを作ったと胸を張って言えるんじゃないかなと思っています。 堀内 : 将来的には経営者の道を目指そうと思っています。ただ、プロダクト開発をしっかり理解し、一定の技術力を身につけていない状態では、人も付いてこないと思うんです。 ですので、 説得力を持てるくらい技術力を身につけていきたい と思います。まだ出来てないと自覚しているのですが、自分が勉強させて頂いている部分を、早くチームの方達に恩返しできるようにしてきたいです。 内田 : 元々課題解決するプロダクトを作りたいという思いで入社しましたが、実現するためには 3 つやることがあると思っています。 1 つは「解決のために最適解を選択できること」です。これは幅広い技術を身につけたエンジニアになることかなと思っています。 2 つ目は「ちゃんとドメイン知識を習得すること」です。最適解を選ぶのにも業務知識が無いままだと絶対に良い選択をできないと考えています。 最後は「自分の考えをきちんと推し進められるビジネススキル」です。色々と関わる人にちゃんとコミュニケーションを取って、自分が良いと思うものを広められればと考えています。メドレーは 自分が凄いと思ったエンジニアの方達がたくさんいらっしゃるので、行く行くは自分もそう思われる位になれたら …と思います。 寺内 : なりたいエンジニア像については、既にみんなに言いたいことを言われているんですが w 直近の目標は、マネージャから見ても「一人前である」と思われる実力を身につけたエンジニアになることです。 また、内側に目を向けられるエンジニアになることも目標です。新機能や定常業務の開発だけではなく、部署内の 開発以外の人達が気持ち良く働けるようになる開発をしていけば、顧客などにも良い影響が出て、結果として事業の成長になる のではないかと考えています。 ですので、部署の皆さんにも喜んでもらえるような一人前のエンジニアになっていきたいですね。 現在は技術や仕事の仕方などを吸収しながらぐんぐんと成長している皆さんですが、最終的な目標はプロダクトに貢献できるようにという背景を感じます。ちゃんとビジネス面も分かったエンジニアにという考え方を持っていてメドレーでエンジニアに求められる部分を意識しているなと思いました。 おわりに 21 年入社エンジニアの座談会はいかがでしたでしょうか。 メドレーの新卒研修を受けた側の感想を公開するのは初めての試みでしたが、自分もインタビューをしていて改めて当時メンバーの皆さんが苦悩していた部分や、現在に活きている部分などを聞けて勉強になりました。 今年も既に 22 年新卒入社のエンジニアメンバーが研修をしている真っ最中ですが、こうした経験などを後輩に伝えてもらうと、より良い組織になっていくのではないかと思っています。 最後に 一緒に医療の未来を作っていく仲間を募集 しているので、この記事を読んでメドレーに興味が湧いた方はぜひ、話をしましょう! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの新居です。 今回は 2021 年新卒入社のエンジニア 5 人に対し、 新卒研修 を終えてからこれまでにプロダクト開発業務を進めている中で、どのように新卒研修が活きているのかを振り返ってもらおうという座談会の様子をお送りしようと思います。 今までブログでお伝えしてきた新卒研修はメンター側の立場で書かれていましたが、当時メンティーだった 2021 年新卒メンバーの紹介をしながら、初めての試みとしてメンティー側はどのようなことを当時考えていたのかをお伝えできればと思います。 2021 年新卒入社メンバー紹介 (左から)筆者 / 内田さん / 高橋さん / 堀内さん / 佐々岡さん / 寺内さん 高橋さん 医療プラットフォーム第一本部 プロダクト開発室 第二開発グループ所属。CLINICS の開発を担当。現在は周辺領域拡張プロジェクトに携わる。 佐々岡さん 人材プラットフォーム本部 プロダクト開発室 第一開発グループ所属。ジョブメドレーの開発を担当。現在は求職者側の UI/UX 改善などの開発に携わる。 寺内さん 人材プラットフォーム本部 プロダクト開発室 第三開発グループ所属。介護のほんねの開発を担当。定常開発や新機能開発に携わる。 堀内さん 人材プラットフォーム本部 プロダクト開発室 第一開発グループ所属。ジョブメドレーの開発を担当。現在は求職者側の UI/UX 改善などの開発に携わる。 内田さん 医療プラットフォーム第一本部 プロダクト開発室 第四開発グループ所属。CLINICS の開発を担当。現在は CLINICS カルテの基幹システムの開発に携わる。 チームの雰囲気について メドレー入社後 1 年が経ち、5 人の皆さんはどのような雰囲気のチームで働いているかを話してもらいました。 高橋 : CLINICS の中でもうちのチームは 出社頻度が高めで対面でコミュニケーションを取る機会が多い ですね。新規機能を中心に開発しているので、細かな調整がしやすくスピード感を持って開発できています。 内田 : 自分は別のチームなんですが、夕会をスタンディングでやっているのを見てカッコいいなと思っていて羨しいです w 佐々岡 : ジョブメドレーチームの雰囲気としては結構リモートで開発している方の割合が多めです。 家庭持ちの方とかは家で実装していたりすることが多い です。デザイナーとエンジニアはすごく近い距離で仕事をしています。 その中で自分は、主に求職者の応募体験を良くするための改善などを行なっています。 寺内 : 介護のほんねは、プロダクト開発チームがコンパクトなので他のみんなと違い明確に担当が分かれているということはないです。自分は社内ツールの業務改善系の開発を担当することが多いです。 社内ツールの非効率な部分を改善したり、定常業務で必要になるシステム改善や修正を主に手がけています。 サーバーサイドの開発が主で、必要に応じてフロントエンドの開発も行なっています。チームの雰囲気は、 締めるところは締める雰囲気 です。MTG なども少なめなので、実装や考えることに時間を使っていける環境です。 佐々岡 : 寺内はチームのプロダクト責任者が直接メンタリングしてくれるのが良いなーと思っています。 寺内 : そうですね。 直属の上司にレビューを含め、メンタリングなどもしていただいている ので、ありがたいです。 堀内 : 自分も佐々岡と一緒でジョブメドレーの開発を担当しています。自分が思うチームの雰囲気ですが、「温和なチーム」と感じています。 心理的安全性が高いチームですね。 自分が今担当しているのは求職者側の UI/UX 改善であったり、ページのパフォーマンス改善などです。開発の特徴としては、開発案件を進めるときに すぐにプロダクトマネージャやリードエンジニアといった方々と会話して進めていける 部分でしょうか。 ジョブメドレー自体、サービスとしては 10 年選手です。ですから、業務フローが大変成熟したものになっています。 洗練された企画・開発フローを実際に体感しながら開発できる、という環境がとても勉強になります ね。 またこのフローは ドキュメントドリブン という考え方で作られた資料に基いていますので、後から蓄積された知見をキャッチアップすることも容易ですし、リモートの人と出社している人との間で齟齬が起きることなく仕事が進められています。 内田 : CLINICS 電子カルテの基盤チームで開発しています。基盤チームでは本当にこれぞカルテという部分を扱っているので、レセプトに関係する部分なども担当しています。 チームの特徴としては、チーム構成として デザイナーやディレクターといった職種の方達がいるんですが、彼らと一緒に会話をしながら、開発を進めていく ということでしょうか。 職種で分けずに全員で認識を揃えながらの開発ができています。あとはメドレーのデザイナーは多かれ少なかれ全員そうだと思うのですが、特に今のチームのデザイナーは自分でフロントエンドの React.js のコードを書いているので、手戻りなども無くすごく仕事がやりやすい環境です。こうした環境で自分が要件から考えて実装していくという開発をできているのが、とてもやりがいがあります。 それぞれ配属されているチームが違うこともあり、チームの雰囲気などはやはり色々と違うようです。しかし、共通してチームで動きながら職種に囚われずに要件定義から関わって開発をしているというところは、全員が感じているようですね。 今までのプログラミング経験 次の話題として、21 年入社メンバーの入社前のプログラミング経験について聞いてみました。みなさんどんな形でプログラミングに関わってきたんでしょうか? 高橋 : プログラミングを始めたのは高校 1 年生の頃からです。 中学生のころからコンピュータに触れはじめて漠然とプログラミングの勉強がしたい という思いから、情報系学科に入学してゲームプログラミングから始めたのが最初です。 大学時代は、実践型のプロジェクト学習に力を入れている公立はこだて未来大学で様々な開発経験を積みました。学部 3 年生の 1 年間は、4 大学合同でチーム開発をするという講義の中で iOS アプリケーションの開発を経験しました。 学部 4 年生からは、都内にある SIer 企業の社内システムを開発する学内プロジェクトに参加しました。他にもエンジニアとして働けるサマーインターンにも参加しました。 内田 : 自分達と同世代だと中学生のときくらいに、例えば PSP を始めとした ゲーム機だとか、家のパソコンを触っていくことをきっかけにして、プログラミングに興味を持つ という人が多い印象です。この 5 人の共通の思い出として、やっぱりこの辺の話題が出てきたりします。 佐々岡 : 自分が プログラミングを始めたのは、情報系の大学に入ってから でした。始めてからは Ruby on Rails での開発や Python の Django での開発をアルバイトで経験を積んでいきました。サークルでも PHP を使った Web アプリケーションを作ったりと、のめり込んでいました。 堀内 : 自分は大学では情報系学科ではなく、経済学部を専攻しました。高校のときは理系コースで「理系の大学に行くんだ」と頑張っていたんですが、どちらかというと文系科目の方が好きだったので、数学の知識も使いつつ文系である経済学を選んだ形です。 プログラミングの原体験は Web になります。もうサービスは無くなってしまったんですが、 中学生のときに Yahoo!ジオシティーズというホームページを簡単に作れるというサービスに夢中になった 時期がありました。 このサービスはエディタにテキストを入れると HTML が生成されるというシステムだったんで、そこでこういった感じで Web が出来るんだなと思い面白いなと思ったのがきっかけです。そこから色を変えたいから CSS を勉強する、クジ引きアプリ作りたいから JavaScript を勉強するみたいな感じで、のめり込んでいきました。 中高くらいにスマホが出てきたんですが、当時カスタムされた OS が流通していて、そういうのも面白いと触っていました。同時期にブログを運営していたのでその時に PHP での開発をしていきました。一通り Web プログラミングが出来るようになってからは、個人事業主として開発や保守を受託することが多く、その時のお仕事で、フロント / バックエンド / インフラ 満遍なく貴重な経験をさせて頂けたと思います。 内田 : 僕は 小学校 3~4 年生くらいに最初にプログラミングに触れました 。当時、宇宙がすごく好きでちょうど JAXA が小学生向けのプロジェクトやっていてそれがロボットの開発をするというものだったんです。そのロボットの制御をするためにプログラミングが必要になって触り始めたのが最初です。 中学生で Web プログラミングに触れまして。ちょうど YouTube が盛り上るくらいのタイミングだったんで、今でいう YouTuber っぽい活動していてその宣伝のためのホームページを作るためにサイトを作ったりしていました。 でも、そこからはあんまりプログラミングに触れていなくて、大学 2 年生くらいになって部活でアプリ開発をやり始めて、それがスケールアップして起業もしました。 その会社は儲からなくて閉じたんですが、そこからある程度プログラミング経験が積めたなと思ったので、医療系を含む、色々な企業でインターンとしてプログラミングをしていました。そこからメドレーに入社しました。 寺内 : 僕も佐々岡と一緒で大学に入ってからでした。高校のときは遺伝子に興味があったんですが、Web 広告で プログラマーについて知ってこっちの方がより面白そうだと思って情報系学科に入る ことにしました。 サークルで知りあった人にインターンをおすすめされたので、1 年生の後半あたりからずっとインターンとしてプログラミングをしていました。その中にメドレーもありました。 話を聞くと皆さん大分早い段階からプログラミングに興味を持ち出していますね。大学でインターンを有効活用してスキルアップしてきた人も多いです。最近あまり言わないですが、デジタルネイティブという印象です。 メドレーに入社を決めた理由 そうした経験を積んできた 5 人はどんな理由でメドレーの入社を決めたのかが気になるので、聞いてみました。 高橋 : 就活の軸として、社会的な課題を解決するプロダクトの開発に携わりたいという思いがありました。 この軸は、大学時代までに個人開発やプロジェクトを通して開発してきた成果物が、思うような価値を生み出せなかったという悔しさが原体験としてあったためです。そこから課題解決が好きだったこともあり、エンジニアリングを通して大きな社会課題を解決したいという考えを持つようになりました。 最終的には、インターンシップや就活を通して社員の方々から話を伺った中で「医療ヘルスケアの未来をつくる」という メドレーのミッションに強く惹かれ 入社を決めました。 佐々岡 : 生活のインフラに直結する分野の社会課題を解決するという所が良かったので、メドレーに入社しました。もう一つの理由としてはメドレーの「ドキュメントドリブン」という文化に心惹かれたからです。 色々 社内の知見などをきちんとドキュメント化している ので、そういったドキュメントを参考にしていれば、自分の成長スピードも早くなるのではと思いました。 内田 : 他の人と同じで、医療という大きいドメインでの課題解決をしているという点はもちろんなんですが、働いている エンジニアの方々が少数精鋭でレベルが高いなと感じた のも大きいです。 そんな中で、新卒入社のエンジニアの人数もそこまで多くはないので、入社したらそんな方達と一緒に仕事ができるようになるなと感じたからです。 堀内 : 就活の軸として、自分が成長できそうか・風通しが良いか・合理的な社風かなどを軸として探していました。将来的には経営をしたいと考えているので、 ビジネス側と開発側の距離が近い ことも考えて総合的にメドレーが良さそうだと考えて入社しました。 寺内 : 私はメドレーの夏の インターンシップに参加したのですが、医療・ヘルスケアドメインの課題の多さと、それに正面から向き合うメドレーという会社が非常にエキサイティングだと感じた のが、きっかけです。 そこから自分の医療の原体験というのを考えたときに、高校の時に親族が難病かもしれないという疑いが出てきたという出来事がありました。結局は大丈夫だったのですが、その時に医療情報などの探しにくさなどを実感したことを思い起しました。メドレーはそうした問題に取り組んでいる会社だというのが一番の理由でした。もちろん優秀な方が働いているというのもあります。 メドレーが「医療」という分野での事業をしているということに共感して入社している方が多いですね。共通して自分が作ったものが、社会にインパクトを生み出せるか?ということを意識しているメンバーが多いと思いました。 2021 年度新卒研修の感想 ここからは、新卒研修を受けた感想を 1 年越しに聞いてみたいと思います。特にチームとして開発をしていった「開発実践研修」について中心に聞いてみました。当時は大変なこともあったと思いますが、経験を積んだ今はどのような感想を持っているのでしょうか。 研修で良かったこと 佐々岡 : 開発実践研修で良かったのはまず、 要件定義からリリースまで一気通貫にできたので自分のその時点での不足している部分というのが可視化されたこと でした。 また開発するツールはそのまま社内で使い続けていくものだったので、レビュアーの方にも親身になってレビューしていただけたり、そういった所が良かった所です。 開発実践では React.js を使って開発をしていたんですが、配属されてからも業務として使って活きている部分です。 メドレーで開発業務をするということが、どういうものかをこの研修を通じて勉強 できました。 おかげで、配属された後も違和感なく実務ができるようになりました。 高橋 : エンジニアとしてこれからプロとして開発をしていく上で自信が付いたのが良かったです。 学生のときは作って終わりというプロダクトが多かったのですが、 社会人になって初めて作ったプロダクトが今も毎日稼動しているということで、エンジニアとしての自信に繋がりました 。 この経験のおかげで、現在の業務でも自分が違和感などを感じたりしたときには、「間違ってるかな」などと臆せずにズバズバと言えるようになっています。 現在のプロジェクトは要件の固まりきっていない新機能を開発しているフェーズなので、日々の業務に活かせている実感があります。 堀内 : 今に繋がってるなと思っているのは チームがちゃんと目標を持っているときと、そこがあやふやだったときのチームのパフォーマンスの出方が全然違うというのを体験 できた点です。 開発中は自分はチームリードとして、チームビルディングを中心に行っていたのですが、ちゃんと目標をイメージできる形にする・そのイメージをチームで認識が揃うまでしっかりと擦り合せる、という 2 点に注意していました。 最初の目的をちゃんと話しあって固めた後は、朝会などでちゃんとメンバーの作業について共有していくようにしたら、上手くチームが回り始めました。最初にイメージを固めたら、MTG を小まめにしなくてもちゃんと作業が進んでいきました。 寺内 : 「開発実践研修」の前に受講した外部研修の「ビジネススタンス研修」が良かったです。研修の序盤に受けられて 社会人としてのスタンスが学べたのが良かった です。ここで習ったことが、開発実践研修でチームで話し合う場でもきちんと応用できましたし、もちろん業務をしている今でもちゃんと活きていると実感しています。研修の全メニューが良かったと感じているのは言うまでもないかもしれませんが w 研修で大変だったこと 佐々岡 : 最初の段階での要件定義のときに課題設定が想定と違ってきたことが一番大変でした。 研修企画側から予め提示されていた課題と自分達が考えた要件定義とのズレを、 Miro を使ってのミーティングを繰り返して修正するまでに、時間がかかってしまいました。そうしたミーティングなどで課題の解決方法などを構造化して考えたりしていき、ようやく修正できました。 この経験で 最初の課題設定も正しいかどうかを鵜呑みにせずに、ちゃんと自分達で調べて納得するような形にしないといけない ということを学べました。 高橋 : やはり要件定義フェイズでした。当初の予定より大分伸びてしまいました。これは着地点が不明確なまま、議論が進んでしまっていたのが原因でした。 対応として 全員でちゃんとコンセンサスを取りながら、着地点を明確にして要件定義をやり直した 結果立て直すことができました。要件定義をしっかりやるというのはこの研修が初めてに近い状態だったので、大変でした。 当時フワフワとした状態で進めてしまったところが反省点だったので、不明な部分などは自分の中で全部つぶした上で開発するということが大事なんだということが学べました。 内田 : 要件定義していた最初の 1 週間は本当に進みが悪くて大変でした。1 週間経ってようやく**「自分達がオーナーシップを取らないと開発が進まない」ということを実感**したので、そこから勢いが付いた感じです。それまではどこか自分事として捉えられてなかったんだと思います。 寺内 : 最初のほうではメンバーの向き不向きとか性格などがやはり分からなかったので、お互いの期待値調整が大変だったなと思います。 最初の時点で目的に対する姿勢も、メンバーごとに温度感が違いました。そこで、全員でお互いの得意・不得意などや期待することを、擦り合せる時間を作ってようやく役割分担もできました。 これで、ようやくスタートラインに立ってゴールもそこに至る道筋も明確になりました。自分は 今のチームでも上司や同僚に自分の情報を開示しつつ、期待値を把握して仕事をする ことによって目指すべき場所が認識できるようになり、仕事が円滑に進むようになった実感があります。 研修については、皆さんそろっての初の共同作業ということもあり、苦労も達成感も感じていますね。 現在の業務にも、きちんと活きているというのは嬉しい限りです。要件定義から自分達でオーナーシップを持って目的を持ってチームで開発をするという、実践的な研修を心がけていたので、ちゃんとそこを経験してもらっているようです。 今後について 最後にメンバーそれぞれの皆さんにこれから目指すエンジニア像を聞いてみました。 佐々岡 : 今後は ビジネス側の知見・現場の課題感・プロダクトのあるべき姿という 3 つの視点をきちんと身につけていけるエンジニア になっていきたいと思っています。 現時点ではまだまだという自覚があるので、これから色々な先輩方の背中を追いかけつつ、成長していきたいと思います。 高橋 : 今はプロダクトマネージャやリーダーがプロダクトの根本的な基本要件を考えて、そこから詳細要件を自分達が考えて実装しているのですが、行く行くはそうした 基本要件から自分で考えて、周りと連携しつつ実装していけるようになりたい です。 ここまで出来るようになると、自分が社会にインパクトを与えるプロダクトを作ったと胸を張って言えるんじゃないかなと思っています。 堀内 : 将来的には経営者の道を目指そうと思っています。ただ、プロダクト開発をしっかり理解し、一定の技術力を身につけていない状態では、人も付いてこないと思うんです。 ですので、 説得力を持てるくらい技術力を身につけていきたい と思います。まだ出来てないと自覚しているのですが、自分が勉強させて頂いている部分を、早くチームの方達に恩返しできるようにしてきたいです。 内田 : 元々課題解決するプロダクトを作りたいという思いで入社しましたが、実現するためには 3 つやることがあると思っています。 1 つは「解決のために最適解を選択できること」です。これは幅広い技術を身につけたエンジニアになることかなと思っています。 2 つ目は「ちゃんとドメイン知識を習得すること」です。最適解を選ぶのにも業務知識が無いままだと絶対に良い選択をできないと考えています。 最後は「自分の考えをきちんと推し進められるビジネススキル」です。色々と関わる人にちゃんとコミュニケーションを取って、自分が良いと思うものを広められればと考えています。メドレーは 自分が凄いと思ったエンジニアの方達がたくさんいらっしゃるので、行く行くは自分もそう思われる位になれたら …と思います。 寺内 : なりたいエンジニア像については、既にみんなに言いたいことを言われているんですが w 直近の目標は、マネージャから見ても「一人前である」と思われる実力を身につけたエンジニアになることです。 また、内側に目を向けられるエンジニアになることも目標です。新機能や定常業務の開発だけではなく、部署内の 開発以外の人達が気持ち良く働けるようになる開発をしていけば、顧客などにも良い影響が出て、結果として事業の成長になる のではないかと考えています。 ですので、部署の皆さんにも喜んでもらえるような一人前のエンジニアになっていきたいですね。 現在は技術や仕事の仕方などを吸収しながらぐんぐんと成長している皆さんですが、最終的な目標はプロダクトに貢献できるようにという背景を感じます。ちゃんとビジネス面も分かったエンジニアにという考え方を持っていてメドレーでエンジニアに求められる部分を意識しているなと思いました。 おわりに 21 年入社エンジニアの座談会はいかがでしたでしょうか。 メドレーの新卒研修を受けた側の感想を公開するのは初めての試みでしたが、自分もインタビューをしていて改めて当時メンバーの皆さんが苦悩していた部分や、現在に活きている部分などを聞けて勉強になりました。 今年も既に 22 年新卒入社のエンジニアメンバーが研修をしている真っ最中ですが、こうした経験などを後輩に伝えてもらうと、より良い組織になっていくのではないかと思っています。 最後に 一緒に医療の未来を作っていく仲間を募集 しているので、この記事を読んでメドレーに興味が湧いた方はぜひ、話をしましょう! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp