はじめに みなさん、こんにちは。エンジニアの新居です。 今回は 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 年新卒入社のエンジニアメンバーが研修をしている真っ最中ですが、こうした経験などを後輩に伝えてもらうと、より良い組織になっていくのではないかと思っています。 最後に 一緒に医療の未来を作っていく仲間を募集 しているので、この記事を読んでメドレーに興味が湧いた方はぜひ、話をしましょう! https://www.medley.jp/jobs/

はじめに みなさん、こんにちは。エンジニアの新居です。 今回は 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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