こんにちは、人材プラットフォーム本部 プロダクト開発室 第一開発グループ所属の森川です。医療介護求人サイト「 ジョブメドレー 」の開発チームの一員として、現在はインフラタスクをメインに取り組んでいます。 今年（2021 年）の 6 月の話ではありますが、ジョブメドレーの連携サービスにて使用しているデータベースを、通常の RDS（ Amazon RDS for MySQL ）から Aurora（ Amazon Aurora ）に移行しました。 タイトルは自分でも大きく出たなと思ってはいるのですが、サービスの特性に助けられたところはありつつも、ダウンタイムなく移行することができました。今回はそのいきさつについてお話させていただこうと思います。 本稿では Amazon RDS for MySQL を「通常の RDS」、Amazon Aurora を「Aurora」と表記させていただきます。 ジョブメドレーの連携サービスについて ジョブメドレーは医療介護従事経験者が運営する就職・復職・転職のための求人サイトです。このジョブメドレーの連携サービスとして医療・介護・福祉・歯科従事者向けの情報サービスを他社と共同運営しています（以降、本サービス）。 本サービスはアプリケーションシステムのバックエンドの開発フレームワークとして Ruby on Rails（以降、Rails）を使用し、弊社で開発・運用を行っています。表示コンテンツは他社から共有していただくものを表示する形となっています。 発端 今年の 1 月末に AWS から以下のようなメールが届きました（内容を一部抜粋しています）。 Amazon RDS は、MySQL メジャーバージョン 5.6 の廃止 (EOL) プロセスを開始しています。 お客様は古いバージョンで実行されている RDS MySQL インスタンスを１つ以上お持ちであるように見受けられます。 Amazon RDS for MySQL 5.6 は、UTC 協定世界時間の 2021 年 8 月 3 日に廃止されます。 公式のお知らせは こちら です。 EOL 通知はドキッとします。できれば見たくないものです。 この対象となっていたのが、本サービスで使用している RDS の MySQL v5.6.39（当時）でした。 対応方針として以下を考えました。 通常の RDS のまま MySQL のバージョンを 5.7 に上げる 通常の RDS から Aurora への変更も行いつつ、MySQL のバージョンを 5.7 に上げる MySQL のバージョンを 8 まで上げる MySQL 8 系へのバージョンアップは対応範囲が大きくなりすぎるため今回は断念しました。5.6 の EOL 期限が迫っているため時間の余裕はあまりありません。また、もし 8 系に上げるとしても、5.7 へのバージョンアップは挟む必要がありそうです。 ジョブメドレー本体のシステムにおいても、性能やメンテナンス性の向上の観点から、通常の RDS から Aurora への移行を計画しております。その足がかりとして、関連アプリケーションの中でも比較的システム規模の小さいものから、先行して移行作業をしておきたいという要望がありました。 これらを加味して、今回のミッションは「 通常の RDS から Aurora への変更も行いつつ、MySQL のバージョンを 5.7 に上げる 」となりました。 検証 インフラ構成に変更を加える際には言うまでもなく検証が必要です。インフラ関連タスクに取り組むにあたって大きなウェイトを占めるのが検討・検証なのではないかと個人的には考えています。 Aurora への乗り換え検証のために、新たに DB インスタンスを用意しました。既存相当のスペックの通常 RDS とそれよりも少しスペックの落とした Aurora です。正確な比較を行う場合であれば、両 DB インスタンスのスペックは揃えるべきかとは思いますが、現行の RDS がオーバースペックであることも課題のひとつであったため、検証段階から Aurora のスペックを落として検証を行っています。よって検証結果による成否判断としては「著しい悪化が見られないか」という観点になっています。 既存相当の RDS のスペックは db.m4.large 、Aurora のスペックは暫定的に db.t3.medium を選択しました。また、データベースに流し込むデータは本番相当のものを個人情報などはマスクした上で用意しています。 検証の項目は以下の 4 点です。 レスポンスタイム検証 SQL ごとの速度検証 実行計画の検証 フェイルオーバー後に元 writer に対する接続が継続される問題への対応検証 レスポンスタイム検証 まずは、レスポンスタイムの影響について確認しました。 本サービスにおける主要なページの URL を選出します。それぞれのページに対して数回のリクエストを行い「低負荷状態」でのレスポンスタイムを比較しました。Aurora の方が一桁ミリ秒程度遅いという結果となりました。 次に Apache Bench を用いて短時間に並列でのリクエストを行い「高負荷状態」を再現して比較を行いました。本サービスはスパイクで負荷が高まるような性質ではないため、普段のアクセス頻度を元に「高負荷状態」がどの程度かを想定して定義しています。結果として、一部のページにて 1 秒ほど遅くなっていることが分かりました。スペックを上げることで解決ができるのかを調査するため、インスタンスサイズを db.t3.medium から db.t3.large に変更して改めて試しました。しかし Aurora の方が遅いという結果に変化は見られませんでした。アプリケーション側の調査を進めると、データベースの問題ではなくアプリケーション側の問題であることが分かり、別途対応ということになりました。 以上より、Aurora への移行によるレスポンスタイムへの影響としては、多少の性能の低下は見られたものの許容範囲内であり、大きな問題は見られないことが分かりました。 SQL ごとの速度検証 こちらはレスポンスタイムの検証に近しい検証ではありますが、生の SQL の速度の調査も行いました。アプリケーションを通して実行される SQL の中でも実行される頻度の高いものを選出し、アプリケーションを介さずクライアントツールから実行しています。 こちらも大きな問題は見られませんでした。 実行計画の検証 この検証でもアプリケーションの中で実行される頻度が高いクエリを選出し調査を行いました。使用したのはお馴染みの EXPLAIN ステートメントです。 実行計画に差分は見られなかったため問題はありませんでした。 フェイルオーバー後に元 writer に対する接続が継続される問題への対応検証 Rails アプリケーションへの Aurora 導入において、必ずと言ってよいほど障壁となるのがこの問題かと思います。 Aurora のフェイルオーバーと Rails への影響 Aurora の特徴や通常の RDS との差分については様々なサイト・記事で詳しくまとまっている情報ですので本稿での詳解は割愛しますが、Aurora のフェイルオーバーについてのみ概要を説明させていただきます。 マルチ AZ での Aurora DB クラスターのプライマリ DB インスタンス（writer と呼ばれる）において障害が発生した場合、フェイルオーバー（待機システムへの切り替え）が自動で実行されます。プライマリ DB インスタンスのリードレプリカ（reader と呼ばれる）を配置していた場合は、それが次のプライマリへと昇格し、エンドポイントも切り替わってくれます。 次に Rails の ActiveRecord のコネクションプールについてです。ActiveRecord はデータベースへの接続情報を保持し、そのコネクションを再利用することで接続時のオーバーヘッドを解消し、高速化を図る仕組みを保有しています。本サービスにおいて MySQL のクライアントとして使用している mysql2 では、コネクションがアクティブであることを mysql_ping が判定してくれるようです。しかし残念なことに Aurora 側でのフェイルオーバーの発生までは検知することができないようです。 したがって、フェイルオーバーが発生すると、プライマリから降格した元 writer 現 reader である DB インスタンスに対してコネクションが張り続けられてしまうため、書き込みのリクエストに対してはエラーとなってしまう状態になります。 対応策 対応策としては以下を考えました。 Aurora 用のクライアント Gem を使用する Mysql2::Error が発生した場合、サーバーエラーにしつつコネクションを切断して再接続を促す 一定回数リクエストを処理するごとに再接続させる 今回採用したのは上記の 3 の「一定回数リクエストを処理するごとに再接続させる」対応です。 当初は対応策 1 の Gem の使用を検討しておりましたが、トランザクション中にフェイルオーバーが発生した際の挙動が本サービスには適合しないことが分かりました。またいくつかの対応策を複合して実装するという方法も考えられました。 今回においては、実装工数や、サービスの規模から考えうる必要十分の最小値を検討した結果、この判断としています。 再接続の度に発生するオーバーヘッドによる速度影響についても低負荷・高負荷の状態で検証を行いましたが、数値的には軽微であり、少々の遅延は許容することになりました。 この対応は、Aurora への移行の前、つまり通常の RDS で稼働している状態であってもリリースして問題ないものだったため、事前に実装・リリースを行うことができました。 料金 「現行の RDS がオーバースペックであることも課題のひとつ」と上記しておりましたが、その是正による料金の合理化についても副次的効果として期待していました。 Aurora の料金形態には、通常の RDS と同じ「DB インスタンス時間従量課金」「ストレージ時間従量課金」に加え、「I/O リクエスト数従量課金」という項目が追加されているため、比較を行う際は注意が必要です。 移行前後の条件は以下の通りです。 通常の RDS（移行前） オンデマンド RDS で稼働しているのは本番環境のみ db.m4.large ストレージ 100GB Aurora（移行後） オンデマンド 本番環境だけでなく検証環境も Aurora で稼働させる 本番環境 db.t3.medium, 検証環境 db.t3.small ストレージ 100GB（両環境とも） 移行前の通常の RDS では本番環境のみで月々 4 万円以上かかっていたコストですが、移行後は本番環境に加え検証環境においても Aurora を使用するようにしても合計 3 万円以下という計算となりました。月々 1 万円、年額 12 万円の節約になります。さらにはオンデマンドからリザーブドへ変更することも今後検討ができるため、コストカットの余地がまだ残されているのも嬉しいところです。 リリースに向けた準備 リリース作業のキモとなるデータベースの切り替えは、「リードレプリカからの昇格」という方法を採ることとしました。MySQL のバージョンアップについては、プライマリが通常の RDS から Aurora に切り替わった後に、Aurora インスタンスの MySQL バージョンを上げるための変更を実行します。 これらの作業をデータの不整合を発生させることなく完遂させるためには、 データベースへの書き込み動作をすべて停止させる 必要がありました。 これを実現するためには、データベースへの書き込み処理が発生するケースをすべて洗い出さなければいけません。調査をしたところ、本サービスでは「社内管理画面」と「バッチ処理」でのみ書き込み処理が実行されていることが分かりました。 つまり、一般ユーザからの書き込み処理は本サービスでは保有していないため、書き込みが行われるタイミングを把握・調整することが可能でした。したがって、一般ユーザが見ることのできるページをメンテナンスモードに切り替えるなどの「サービスのダウンタイム」を発生させることなく Aurora への移行と MySQL のバージョンアップを行える、ということになります。 リリース時に影響が生じる周辺情報の洗い出しも一通り済んだところで、次に「手順書」の作成に取り掛かりました。必要な全ての操作について順序に沿って詳細にまとめます。その中には、各段階にて万が一障害が発生した場合の切り戻し手順についても記載しています。 手順書を元に、検証環境にて同様の手順を実行し、予行演習を行いました。これによって、本番での作業を鮮明にイメージすることができます。また大抵の場合、手順書の不備やブラッシュアップできるところが見つかります。予行演習は本番作業を滞りなく実行するための最も重要なファクターのひとつかと思います。 実際に使用した手順書（一部抜粋） リリース作業 リリースで行った作業の要点をまとめると以下となります。 本番用データベースのリードレプリカを Aurora で作成 データベースへの書き込みを停止 社内管理画面の操作を停止いただくよう社内へのアナウンス バッチ処理の実行をすべて停止 レプリカ Aurora をプライマリへ昇格 データベースのコネクション更新のためサーバ 1 台ずつアプリケーションの再起動 バッチ処理の再開 動作確認 大きめのリリース作業はアクセスの多い時間帯を避けて行われることもあるかと思いますが、今回はサービスのダウンタイムなく作業を行えるケースであるため午前中からの作業開始となりました。また作業を行う自分の隣には先輩社員が構えており、ダブルチェックをしていだきました。 手順書の作成と予行演習の甲斐もあって、本番リリースを問題なく進めることができました。 まとめ サービスの特性に助けられたところは大きいですが、サービス停止などのダウンタイムを発生させることなく通常の RDS から Aurora への移行を完了させることができました。 スティーブ・ジョブズは数分のプレゼン発表のために数百時間の準備をしていたといいます。プレゼンで言うところのシナリオの作成とリハーサルの実行もそうですが、サービス特性の理解や検証を綿密に行うことも本番を成功させるためには欠かせません。準備を怠らないエンジニアでありたい、と執筆しながら改めて感じているところです。 さいごに メドレーでは「医療ヘルスケアの未来をつくる」というミッション実現のため、日々開発・運営を行っています。エンジニア・デザイナーをはじめ多くのポジションでメンバーを募集しております。もし少しでもご興味をお持ちいただけましたら、ぜひお気軽にお話しさせていただければと思います。 最後までお読みいただき、ありがとうございました。 https://www.medley.jp/jobs/

こんにちは、人材プラットフォーム本部 プロダクト開発室 第一開発グループ所属の森川です。医療介護求人サイト「 ジョブメドレー 」の開発チームの一員として、現在はインフラタスクをメインに取り組んでいます。 今年（2021 年）の 6 月の話ではありますが、ジョブメドレーの連携サービスにて使用しているデータベースを、通常の RDS（ Amazon RDS for MySQL ）から Aurora（ Amazon Aurora ）に移行しました。 タイトルは自分でも大きく出たなと思ってはいるのですが、サービスの特性に助けられたところはありつつも、ダウンタイムなく移行することができました。今回はそのいきさつについてお話させていただこうと思います。 本稿では Amazon RDS for MySQL を「通常の RDS」、Amazon Aurora を「Aurora」と表記させていただきます。 ジョブメドレーの連携サービスについて ジョブメドレーは医療介護従事経験者が運営する就職・復職・転職のための求人サイトです。このジョブメドレーの連携サービスとして医療・介護・福祉・歯科従事者向けの情報サービスを他社と共同運営しています（以降、本サービス）。 本サービスはアプリケーションシステムのバックエンドの開発フレームワークとして Ruby on Rails（以降、Rails）を使用し、弊社で開発・運用を行っています。表示コンテンツは他社から共有していただくものを表示する形となっています。 発端 今年の 1 月末に AWS から以下のようなメールが届きました（内容を一部抜粋しています）。 Amazon RDS は、MySQL メジャーバージョン 5.6 の廃止 (EOL) プロセスを開始しています。 お客様は古いバージョンで実行されている RDS MySQL インスタンスを１つ以上お持ちであるように見受けられます。 Amazon RDS for MySQL 5.6 は、UTC 協定世界時間の 2021 年 8 月 3 日に廃止されます。 公式のお知らせは こちら です。 EOL 通知はドキッとします。できれば見たくないものです。 この対象となっていたのが、本サービスで使用している RDS の MySQL v5.6.39（当時）でした。 対応方針として以下を考えました。 通常の RDS のまま MySQL のバージョンを 5.7 に上げる 通常の RDS から Aurora への変更も行いつつ、MySQL のバージョンを 5.7 に上げる MySQL のバージョンを 8 まで上げる MySQL 8 系へのバージョンアップは対応範囲が大きくなりすぎるため今回は断念しました。5.6 の EOL 期限が迫っているため時間の余裕はあまりありません。また、もし 8 系に上げるとしても、5.7 へのバージョンアップは挟む必要がありそうです。 ジョブメドレー本体のシステムにおいても、性能やメンテナンス性の向上の観点から、通常の RDS から Aurora への移行を計画しております。その足がかりとして、関連アプリケーションの中でも比較的システム規模の小さいものから、先行して移行作業をしておきたいという要望がありました。 これらを加味して、今回のミッションは「 通常の RDS から Aurora への変更も行いつつ、MySQL のバージョンを 5.7 に上げる 」となりました。 検証 インフラ構成に変更を加える際には言うまでもなく検証が必要です。インフラ関連タスクに取り組むにあたって大きなウェイトを占めるのが検討・検証なのではないかと個人的には考えています。 Aurora への乗り換え検証のために、新たに DB インスタンスを用意しました。既存相当のスペックの通常 RDS とそれよりも少しスペックの落とした Aurora です。正確な比較を行う場合であれば、両 DB インスタンスのスペックは揃えるべきかとは思いますが、現行の RDS がオーバースペックであることも課題のひとつであったため、検証段階から Aurora のスペックを落として検証を行っています。よって検証結果による成否判断としては「著しい悪化が見られないか」という観点になっています。 既存相当の RDS のスペックは db.m4.large 、Aurora のスペックは暫定的に db.t3.medium を選択しました。また、データベースに流し込むデータは本番相当のものを個人情報などはマスクした上で用意しています。 検証の項目は以下の 4 点です。 レスポンスタイム検証 SQL ごとの速度検証 実行計画の検証 フェイルオーバー後に元 writer に対する接続が継続される問題への対応検証 レスポンスタイム検証 まずは、レスポンスタイムの影響について確認しました。 本サービスにおける主要なページの URL を選出します。それぞれのページに対して数回のリクエストを行い「低負荷状態」でのレスポンスタイムを比較しました。Aurora の方が一桁ミリ秒程度遅いという結果となりました。 次に Apache Bench を用いて短時間に並列でのリクエストを行い「高負荷状態」を再現して比較を行いました。本サービスはスパイクで負荷が高まるような性質ではないため、普段のアクセス頻度を元に「高負荷状態」がどの程度かを想定して定義しています。結果として、一部のページにて 1 秒ほど遅くなっていることが分かりました。スペックを上げることで解決ができるのかを調査するため、インスタンスサイズを db.t3.medium から db.t3.large に変更して改めて試しました。しかし Aurora の方が遅いという結果に変化は見られませんでした。アプリケーション側の調査を進めると、データベースの問題ではなくアプリケーション側の問題であることが分かり、別途対応ということになりました。 以上より、Aurora への移行によるレスポンスタイムへの影響としては、多少の性能の低下は見られたものの許容範囲内であり、大きな問題は見られないことが分かりました。 SQL ごとの速度検証 こちらはレスポンスタイムの検証に近しい検証ではありますが、生の SQL の速度の調査も行いました。アプリケーションを通して実行される SQL の中でも実行される頻度の高いものを選出し、アプリケーションを介さずクライアントツールから実行しています。 こちらも大きな問題は見られませんでした。 実行計画の検証 この検証でもアプリケーションの中で実行される頻度が高いクエリを選出し調査を行いました。使用したのはお馴染みの EXPLAIN ステートメントです。 実行計画に差分は見られなかったため問題はありませんでした。 フェイルオーバー後に元 writer に対する接続が継続される問題への対応検証 Rails アプリケーションへの Aurora 導入において、必ずと言ってよいほど障壁となるのがこの問題かと思います。 Aurora のフェイルオーバーと Rails への影響 Aurora の特徴や通常の RDS との差分については様々なサイト・記事で詳しくまとまっている情報ですので本稿での詳解は割愛しますが、Aurora のフェイルオーバーについてのみ概要を説明させていただきます。 マルチ AZ での Aurora DB クラスターのプライマリ DB インスタンス（writer と呼ばれる）において障害が発生した場合、フェイルオーバー（待機システムへの切り替え）が自動で実行されます。プライマリ DB インスタンスのリードレプリカ（reader と呼ばれる）を配置していた場合は、それが次のプライマリへと昇格し、エンドポイントも切り替わってくれます。 次に Rails の ActiveRecord のコネクションプールについてです。ActiveRecord はデータベースへの接続情報を保持し、そのコネクションを再利用することで接続時のオーバーヘッドを解消し、高速化を図る仕組みを保有しています。本サービスにおいて MySQL のクライアントとして使用している mysql2 では、コネクションがアクティブであることを mysql_ping が判定してくれるようです。しかし残念なことに Aurora 側でのフェイルオーバーの発生までは検知することができないようです。 したがって、フェイルオーバーが発生すると、プライマリから降格した元 writer 現 reader である DB インスタンスに対してコネクションが張り続けられてしまうため、書き込みのリクエストに対してはエラーとなってしまう状態になります。 対応策 対応策としては以下を考えました。 Aurora 用のクライアント Gem を使用する Mysql2::Error が発生した場合、サーバーエラーにしつつコネクションを切断して再接続を促す 一定回数リクエストを処理するごとに再接続させる 今回採用したのは上記の 3 の「一定回数リクエストを処理するごとに再接続させる」対応です。 当初は対応策 1 の Gem の使用を検討しておりましたが、トランザクション中にフェイルオーバーが発生した際の挙動が本サービスには適合しないことが分かりました。またいくつかの対応策を複合して実装するという方法も考えられました。 今回においては、実装工数や、サービスの規模から考えうる必要十分の最小値を検討した結果、この判断としています。 再接続の度に発生するオーバーヘッドによる速度影響についても低負荷・高負荷の状態で検証を行いましたが、数値的には軽微であり、少々の遅延は許容することになりました。 この対応は、Aurora への移行の前、つまり通常の RDS で稼働している状態であってもリリースして問題ないものだったため、事前に実装・リリースを行うことができました。 料金 「現行の RDS がオーバースペックであることも課題のひとつ」と上記しておりましたが、その是正による料金の合理化についても副次的効果として期待していました。 Aurora の料金形態には、通常の RDS と同じ「DB インスタンス時間従量課金」「ストレージ時間従量課金」に加え、「I/O リクエスト数従量課金」という項目が追加されているため、比較を行う際は注意が必要です。 移行前後の条件は以下の通りです。 通常の RDS（移行前） オンデマンド RDS で稼働しているのは本番環境のみ db.m4.large ストレージ 100GB Aurora（移行後） オンデマンド 本番環境だけでなく検証環境も Aurora で稼働させる 本番環境 db.t3.medium, 検証環境 db.t3.small ストレージ 100GB（両環境とも） 移行前の通常の RDS では本番環境のみで月々 4 万円以上かかっていたコストですが、移行後は本番環境に加え検証環境においても Aurora を使用するようにしても合計 3 万円以下という計算となりました。月々 1 万円、年額 12 万円の節約になります。さらにはオンデマンドからリザーブドへ変更することも今後検討ができるため、コストカットの余地がまだ残されているのも嬉しいところです。 リリースに向けた準備 リリース作業のキモとなるデータベースの切り替えは、「リードレプリカからの昇格」という方法を採ることとしました。MySQL のバージョンアップについては、プライマリが通常の RDS から Aurora に切り替わった後に、Aurora インスタンスの MySQL バージョンを上げるための変更を実行します。 これらの作業をデータの不整合を発生させることなく完遂させるためには、 データベースへの書き込み動作をすべて停止させる 必要がありました。 これを実現するためには、データベースへの書き込み処理が発生するケースをすべて洗い出さなければいけません。調査をしたところ、本サービスでは「社内管理画面」と「バッチ処理」でのみ書き込み処理が実行されていることが分かりました。 つまり、一般ユーザからの書き込み処理は本サービスでは保有していないため、書き込みが行われるタイミングを把握・調整することが可能でした。したがって、一般ユーザが見ることのできるページをメンテナンスモードに切り替えるなどの「サービスのダウンタイム」を発生させることなく Aurora への移行と MySQL のバージョンアップを行える、ということになります。 リリース時に影響が生じる周辺情報の洗い出しも一通り済んだところで、次に「手順書」の作成に取り掛かりました。必要な全ての操作について順序に沿って詳細にまとめます。その中には、各段階にて万が一障害が発生した場合の切り戻し手順についても記載しています。 手順書を元に、検証環境にて同様の手順を実行し、予行演習を行いました。これによって、本番での作業を鮮明にイメージすることができます。また大抵の場合、手順書の不備やブラッシュアップできるところが見つかります。予行演習は本番作業を滞りなく実行するための最も重要なファクターのひとつかと思います。 実際に使用した手順書（一部抜粋） リリース作業 リリースで行った作業の要点をまとめると以下となります。 本番用データベースのリードレプリカを Aurora で作成 データベースへの書き込みを停止 社内管理画面の操作を停止いただくよう社内へのアナウンス バッチ処理の実行をすべて停止 レプリカ Aurora をプライマリへ昇格 データベースのコネクション更新のためサーバ 1 台ずつアプリケーションの再起動 バッチ処理の再開 動作確認 大きめのリリース作業はアクセスの多い時間帯を避けて行われることもあるかと思いますが、今回はサービスのダウンタイムなく作業を行えるケースであるため午前中からの作業開始となりました。また作業を行う自分の隣には先輩社員が構えており、ダブルチェックをしていだきました。 手順書の作成と予行演習の甲斐もあって、本番リリースを問題なく進めることができました。 まとめ サービスの特性に助けられたところは大きいですが、サービス停止などのダウンタイムを発生させることなく通常の RDS から Aurora への移行を完了させることができました。 スティーブ・ジョブズは数分のプレゼン発表のために数百時間の準備をしていたといいます。プレゼンで言うところのシナリオの作成とリハーサルの実行もそうですが、サービス特性の理解や検証を綿密に行うことも本番を成功させるためには欠かせません。準備を怠らないエンジニアでありたい、と執筆しながら改めて感じているところです。 さいごに メドレーでは「医療ヘルスケアの未来をつくる」というミッション実現のため、日々開発・運営を行っています。エンジニア・デザイナーをはじめ多くのポジションでメンバーを募集しております。もし少しでもご興味をお持ちいただけましたら、ぜひお気軽にお話しさせていただければと思います。 最後までお読みいただき、ありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは、人材プラットフォーム本部 プロダクト開発室 第一開発グループ所属の森川です。医療介護求人サイト「 ジョブメドレー 」の開発チームの一員として、現在はインフラタスクをメインに取り組んでいます。 今年（2021 年）の 6 月の話ではありますが、ジョブメドレーの連携サービスにて使用しているデータベースを、通常の RDS（ Amazon RDS for MySQL ）から Aurora（ Amazon Aurora ）に移行しました。 タイトルは自分でも大きく出たなと思ってはいるのですが、サービスの特性に助けられたところはありつつも、ダウンタイムなく移行することができました。今回はそのいきさつについてお話させていただこうと思います。 本稿では Amazon RDS for MySQL を「通常の RDS」、Amazon Aurora を「Aurora」と表記させていただきます。 ジョブメドレーの連携サービスについて ジョブメドレーは医療介護従事経験者が運営する就職・復職・転職のための求人サイトです。このジョブメドレーの連携サービスとして医療・介護・福祉・歯科従事者向けの情報サービスを他社と共同運営しています（以降、本サービス）。 本サービスはアプリケーションシステムのバックエンドの開発フレームワークとして Ruby on Rails（以降、Rails）を使用し、弊社で開発・運用を行っています。表示コンテンツは他社から共有していただくものを表示する形となっています。 発端 今年の 1 月末に AWS から以下のようなメールが届きました（内容を一部抜粋しています）。 Amazon RDS は、MySQL メジャーバージョン 5.6 の廃止 (EOL) プロセスを開始しています。 お客様は古いバージョンで実行されている RDS MySQL インスタンスを１つ以上お持ちであるように見受けられます。 Amazon RDS for MySQL 5.6 は、UTC 協定世界時間の 2021 年 8 月 3 日に廃止されます。 公式のお知らせは こちら です。 EOL 通知はドキッとします。できれば見たくないものです。 この対象となっていたのが、本サービスで使用している RDS の MySQL v5.6.39（当時）でした。 対応方針として以下を考えました。 通常の RDS のまま MySQL のバージョンを 5.7 に上げる 通常の RDS から Aurora への変更も行いつつ、MySQL のバージョンを 5.7 に上げる MySQL のバージョンを 8 まで上げる MySQL 8 系へのバージョンアップは対応範囲が大きくなりすぎるため今回は断念しました。5.6 の EOL 期限が迫っているため時間の余裕はあまりありません。また、もし 8 系に上げるとしても、5.7 へのバージョンアップは挟む必要がありそうです。 ジョブメドレー本体のシステムにおいても、性能やメンテナンス性の向上の観点から、通常の RDS から Aurora への移行を計画しております。その足がかりとして、関連アプリケーションの中でも比較的システム規模の小さいものから、先行して移行作業をしておきたいという要望がありました。 これらを加味して、今回のミッションは「 通常の RDS から Aurora への変更も行いつつ、MySQL のバージョンを 5.7 に上げる 」となりました。 検証 インフラ構成に変更を加える際には言うまでもなく検証が必要です。インフラ関連タスクに取り組むにあたって大きなウェイトを占めるのが検討・検証なのではないかと個人的には考えています。 Aurora への乗り換え検証のために、新たに DB インスタンスを用意しました。既存相当のスペックの通常 RDS とそれよりも少しスペックの落とした Aurora です。正確な比較を行う場合であれば、両 DB インスタンスのスペックは揃えるべきかとは思いますが、現行の RDS がオーバースペックであることも課題のひとつであったため、検証段階から Aurora のスペックを落として検証を行っています。よって検証結果による成否判断としては「著しい悪化が見られないか」という観点になっています。 既存相当の RDS のスペックは db.m4.large 、Aurora のスペックは暫定的に db.t3.medium を選択しました。また、データベースに流し込むデータは本番相当のものを個人情報などはマスクした上で用意しています。 検証の項目は以下の 4 点です。 レスポンスタイム検証 SQL ごとの速度検証 実行計画の検証 フェイルオーバー後に元 writer に対する接続が継続される問題への対応検証 レスポンスタイム検証 まずは、レスポンスタイムの影響について確認しました。 本サービスにおける主要なページの URL を選出します。それぞれのページに対して数回のリクエストを行い「低負荷状態」でのレスポンスタイムを比較しました。Aurora の方が一桁ミリ秒程度遅いという結果となりました。 次に Apache Bench を用いて短時間に並列でのリクエストを行い「高負荷状態」を再現して比較を行いました。本サービスはスパイクで負荷が高まるような性質ではないため、普段のアクセス頻度を元に「高負荷状態」がどの程度かを想定して定義しています。結果として、一部のページにて 1 秒ほど遅くなっていることが分かりました。スペックを上げることで解決ができるのかを調査するため、インスタンスサイズを db.t3.medium から db.t3.large に変更して改めて試しました。しかし Aurora の方が遅いという結果に変化は見られませんでした。アプリケーション側の調査を進めると、データベースの問題ではなくアプリケーション側の問題であることが分かり、別途対応ということになりました。 以上より、Aurora への移行によるレスポンスタイムへの影響としては、多少の性能の低下は見られたものの許容範囲内であり、大きな問題は見られないことが分かりました。 SQL ごとの速度検証 こちらはレスポンスタイムの検証に近しい検証ではありますが、生の SQL の速度の調査も行いました。アプリケーションを通して実行される SQL の中でも実行される頻度の高いものを選出し、アプリケーションを介さずクライアントツールから実行しています。 こちらも大きな問題は見られませんでした。 実行計画の検証 この検証でもアプリケーションの中で実行される頻度が高いクエリを選出し調査を行いました。使用したのはお馴染みの EXPLAIN ステートメントです。 実行計画に差分は見られなかったため問題はありませんでした。 フェイルオーバー後に元 writer に対する接続が継続される問題への対応検証 Rails アプリケーションへの Aurora 導入において、必ずと言ってよいほど障壁となるのがこの問題かと思います。 Aurora のフェイルオーバーと Rails への影響 Aurora の特徴や通常の RDS との差分については様々なサイト・記事で詳しくまとまっている情報ですので本稿での詳解は割愛しますが、Aurora のフェイルオーバーについてのみ概要を説明させていただきます。 マルチ AZ での Aurora DB クラスターのプライマリ DB インスタンス（writer と呼ばれる）において障害が発生した場合、フェイルオーバー（待機システムへの切り替え）が自動で実行されます。プライマリ DB インスタンスのリードレプリカ（reader と呼ばれる）を配置していた場合は、それが次のプライマリへと昇格し、エンドポイントも切り替わってくれます。 次に Rails の ActiveRecord のコネクションプールについてです。ActiveRecord はデータベースへの接続情報を保持し、そのコネクションを再利用することで接続時のオーバーヘッドを解消し、高速化を図る仕組みを保有しています。本サービスにおいて MySQL のクライアントとして使用している mysql2 では、コネクションがアクティブであることを mysql_ping が判定してくれるようです。しかし残念なことに Aurora 側でのフェイルオーバーの発生までは検知することができないようです。 したがって、フェイルオーバーが発生すると、プライマリから降格した元 writer 現 reader である DB インスタンスに対してコネクションが張り続けられてしまうため、書き込みのリクエストに対してはエラーとなってしまう状態になります。 対応策 対応策としては以下を考えました。 Aurora 用のクライアント Gem を使用する Mysql2::Error が発生した場合、サーバーエラーにしつつコネクションを切断して再接続を促す 一定回数リクエストを処理するごとに再接続させる 今回採用したのは上記の 3 の「一定回数リクエストを処理するごとに再接続させる」対応です。 当初は対応策 1 の Gem の使用を検討しておりましたが、トランザクション中にフェイルオーバーが発生した際の挙動が本サービスには適合しないことが分かりました。またいくつかの対応策を複合して実装するという方法も考えられました。 今回においては、実装工数や、サービスの規模から考えうる必要十分の最小値を検討した結果、この判断としています。 再接続の度に発生するオーバーヘッドによる速度影響についても低負荷・高負荷の状態で検証を行いましたが、数値的には軽微であり、少々の遅延は許容することになりました。 この対応は、Aurora への移行の前、つまり通常の RDS で稼働している状態であってもリリースして問題ないものだったため、事前に実装・リリースを行うことができました。 料金 「現行の RDS がオーバースペックであることも課題のひとつ」と上記しておりましたが、その是正による料金の合理化についても副次的効果として期待していました。 Aurora の料金形態には、通常の RDS と同じ「DB インスタンス時間従量課金」「ストレージ時間従量課金」に加え、「I/O リクエスト数従量課金」という項目が追加されているため、比較を行う際は注意が必要です。 移行前後の条件は以下の通りです。 通常の RDS（移行前） オンデマンド RDS で稼働しているのは本番環境のみ db.m4.large ストレージ 100GB Aurora（移行後） オンデマンド 本番環境だけでなく検証環境も Aurora で稼働させる 本番環境 db.t3.medium, 検証環境 db.t3.small ストレージ 100GB（両環境とも） 移行前の通常の RDS では本番環境のみで月々 4 万円以上かかっていたコストですが、移行後は本番環境に加え検証環境においても Aurora を使用するようにしても合計 3 万円以下という計算となりました。月々 1 万円、年額 12 万円の節約になります。さらにはオンデマンドからリザーブドへ変更することも今後検討ができるため、コストカットの余地がまだ残されているのも嬉しいところです。 リリースに向けた準備 リリース作業のキモとなるデータベースの切り替えは、「リードレプリカからの昇格」という方法を採ることとしました。MySQL のバージョンアップについては、プライマリが通常の RDS から Aurora に切り替わった後に、Aurora インスタンスの MySQL バージョンを上げるための変更を実行します。 これらの作業をデータの不整合を発生させることなく完遂させるためには、 データベースへの書き込み動作をすべて停止させる 必要がありました。 これを実現するためには、データベースへの書き込み処理が発生するケースをすべて洗い出さなければいけません。調査をしたところ、本サービスでは「社内管理画面」と「バッチ処理」でのみ書き込み処理が実行されていることが分かりました。 つまり、一般ユーザからの書き込み処理は本サービスでは保有していないため、書き込みが行われるタイミングを把握・調整することが可能でした。したがって、一般ユーザが見ることのできるページをメンテナンスモードに切り替えるなどの「サービスのダウンタイム」を発生させることなく Aurora への移行と MySQL のバージョンアップを行える、ということになります。 リリース時に影響が生じる周辺情報の洗い出しも一通り済んだところで、次に「手順書」の作成に取り掛かりました。必要な全ての操作について順序に沿って詳細にまとめます。その中には、各段階にて万が一障害が発生した場合の切り戻し手順についても記載しています。 手順書を元に、検証環境にて同様の手順を実行し、予行演習を行いました。これによって、本番での作業を鮮明にイメージすることができます。また大抵の場合、手順書の不備やブラッシュアップできるところが見つかります。予行演習は本番作業を滞りなく実行するための最も重要なファクターのひとつかと思います。 実際に使用した手順書（一部抜粋） リリース作業 リリースで行った作業の要点をまとめると以下となります。 本番用データベースのリードレプリカを Aurora で作成 データベースへの書き込みを停止 社内管理画面の操作を停止いただくよう社内へのアナウンス バッチ処理の実行をすべて停止 レプリカ Aurora をプライマリへ昇格 データベースのコネクション更新のためサーバ 1 台ずつアプリケーションの再起動 バッチ処理の再開 動作確認 大きめのリリース作業はアクセスの多い時間帯を避けて行われることもあるかと思いますが、今回はサービスのダウンタイムなく作業を行えるケースであるため午前中からの作業開始となりました。また作業を行う自分の隣には先輩社員が構えており、ダブルチェックをしていだきました。 手順書の作成と予行演習の甲斐もあって、本番リリースを問題なく進めることができました。 まとめ サービスの特性に助けられたところは大きいですが、サービス停止などのダウンタイムを発生させることなく通常の RDS から Aurora への移行を完了させることができました。 スティーブ・ジョブズは数分のプレゼン発表のために数百時間の準備をしていたといいます。プレゼンで言うところのシナリオの作成とリハーサルの実行もそうですが、サービス特性の理解や検証を綿密に行うことも本番を成功させるためには欠かせません。準備を怠らないエンジニアでありたい、と執筆しながら改めて感じているところです。 さいごに メドレーでは「医療ヘルスケアの未来をつくる」というミッション実現のため、日々開発・運営を行っています。エンジニア・デザイナーをはじめ多くのポジションでメンバーを募集しております。もし少しでもご興味をお持ちいただけましたら、ぜひお気軽にお話しさせていただければと思います。 最後までお読みいただき、ありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは、人材プラットフォーム本部 プロダクト開発室 第一開発グループ所属の森川です。医療介護求人サイト「 ジョブメドレー 」の開発チームの一員として、現在はインフラタスクをメインに取り組んでいます。 今年（2021 年）の 6 月の話ではありますが、ジョブメドレーの連携サービスにて使用しているデータベースを、通常の RDS（ Amazon RDS for MySQL ）から Aurora（ Amazon Aurora ）に移行しました。 タイトルは自分でも大きく出たなと思ってはいるのですが、サービスの特性に助けられたところはありつつも、ダウンタイムなく移行することができました。今回はそのいきさつについてお話させていただこうと思います。 本稿では Amazon RDS for MySQL を「通常の RDS」、Amazon Aurora を「Aurora」と表記させていただきます。 ジョブメドレーの連携サービスについて ジョブメドレーは医療介護従事経験者が運営する就職・復職・転職のための求人サイトです。このジョブメドレーの連携サービスとして医療・介護・福祉・歯科従事者向けの情報サービスを他社と共同運営しています（以降、本サービス）。 本サービスはアプリケーションシステムのバックエンドの開発フレームワークとして Ruby on Rails（以降、Rails）を使用し、弊社で開発・運用を行っています。表示コンテンツは他社から共有していただくものを表示する形となっています。 発端 今年の 1 月末に AWS から以下のようなメールが届きました（内容を一部抜粋しています）。 Amazon RDS は、MySQL メジャーバージョン 5.6 の廃止 (EOL) プロセスを開始しています。 お客様は古いバージョンで実行されている RDS MySQL インスタンスを１つ以上お持ちであるように見受けられます。 Amazon RDS for MySQL 5.6 は、UTC 協定世界時間の 2021 年 8 月 3 日に廃止されます。 公式のお知らせは こちら です。 EOL 通知はドキッとします。できれば見たくないものです。 この対象となっていたのが、本サービスで使用している RDS の MySQL v5.6.39（当時）でした。 対応方針として以下を考えました。 通常の RDS のまま MySQL のバージョンを 5.7 に上げる 通常の RDS から Aurora への変更も行いつつ、MySQL のバージョンを 5.7 に上げる MySQL のバージョンを 8 まで上げる MySQL 8 系へのバージョンアップは対応範囲が大きくなりすぎるため今回は断念しました。5.6 の EOL 期限が迫っているため時間の余裕はあまりありません。また、もし 8 系に上げるとしても、5.7 へのバージョンアップは挟む必要がありそうです。 ジョブメドレー本体のシステムにおいても、性能やメンテナンス性の向上の観点から、通常の RDS から Aurora への移行を計画しております。その足がかりとして、関連アプリケーションの中でも比較的システム規模の小さいものから、先行して移行作業をしておきたいという要望がありました。 これらを加味して、今回のミッションは「 通常の RDS から Aurora への変更も行いつつ、MySQL のバージョンを 5.7 に上げる 」となりました。 検証 インフラ構成に変更を加える際には言うまでもなく検証が必要です。インフラ関連タスクに取り組むにあたって大きなウェイトを占めるのが検討・検証なのではないかと個人的には考えています。 Aurora への乗り換え検証のために、新たに DB インスタンスを用意しました。既存相当のスペックの通常 RDS とそれよりも少しスペックの落とした Aurora です。正確な比較を行う場合であれば、両 DB インスタンスのスペックは揃えるべきかとは思いますが、現行の RDS がオーバースペックであることも課題のひとつであったため、検証段階から Aurora のスペックを落として検証を行っています。よって検証結果による成否判断としては「著しい悪化が見られないか」という観点になっています。 既存相当の RDS のスペックは db.m4.large 、Aurora のスペックは暫定的に db.t3.medium を選択しました。また、データベースに流し込むデータは本番相当のものを個人情報などはマスクした上で用意しています。 検証の項目は以下の 4 点です。 レスポンスタイム検証 SQL ごとの速度検証 実行計画の検証 フェイルオーバー後に元 writer に対する接続が継続される問題への対応検証 レスポンスタイム検証 まずは、レスポンスタイムの影響について確認しました。 本サービスにおける主要なページの URL を選出します。それぞれのページに対して数回のリクエストを行い「低負荷状態」でのレスポンスタイムを比較しました。Aurora の方が一桁ミリ秒程度遅いという結果となりました。 次に Apache Bench を用いて短時間に並列でのリクエストを行い「高負荷状態」を再現して比較を行いました。本サービスはスパイクで負荷が高まるような性質ではないため、普段のアクセス頻度を元に「高負荷状態」がどの程度かを想定して定義しています。結果として、一部のページにて 1 秒ほど遅くなっていることが分かりました。スペックを上げることで解決ができるのかを調査するため、インスタンスサイズを db.t3.medium から db.t3.large に変更して改めて試しました。しかし Aurora の方が遅いという結果に変化は見られませんでした。アプリケーション側の調査を進めると、データベースの問題ではなくアプリケーション側の問題であることが分かり、別途対応ということになりました。 以上より、Aurora への移行によるレスポンスタイムへの影響としては、多少の性能の低下は見られたものの許容範囲内であり、大きな問題は見られないことが分かりました。 SQL ごとの速度検証 こちらはレスポンスタイムの検証に近しい検証ではありますが、生の SQL の速度の調査も行いました。アプリケーションを通して実行される SQL の中でも実行される頻度の高いものを選出し、アプリケーションを介さずクライアントツールから実行しています。 こちらも大きな問題は見られませんでした。 実行計画の検証 この検証でもアプリケーションの中で実行される頻度が高いクエリを選出し調査を行いました。使用したのはお馴染みの EXPLAIN ステートメントです。 実行計画に差分は見られなかったため問題はありませんでした。 フェイルオーバー後に元 writer に対する接続が継続される問題への対応検証 Rails アプリケーションへの Aurora 導入において、必ずと言ってよいほど障壁となるのがこの問題かと思います。 Aurora のフェイルオーバーと Rails への影響 Aurora の特徴や通常の RDS との差分については様々なサイト・記事で詳しくまとまっている情報ですので本稿での詳解は割愛しますが、Aurora のフェイルオーバーについてのみ概要を説明させていただきます。 マルチ AZ での Aurora DB クラスターのプライマリ DB インスタンス（writer と呼ばれる）において障害が発生した場合、フェイルオーバー（待機システムへの切り替え）が自動で実行されます。プライマリ DB インスタンスのリードレプリカ（reader と呼ばれる）を配置していた場合は、それが次のプライマリへと昇格し、エンドポイントも切り替わってくれます。 次に Rails の ActiveRecord のコネクションプールについてです。ActiveRecord はデータベースへの接続情報を保持し、そのコネクションを再利用することで接続時のオーバーヘッドを解消し、高速化を図る仕組みを保有しています。本サービスにおいて MySQL のクライアントとして使用している mysql2 では、コネクションがアクティブであることを mysql_ping が判定してくれるようです。しかし残念なことに Aurora 側でのフェイルオーバーの発生までは検知することができないようです。 したがって、フェイルオーバーが発生すると、プライマリから降格した元 writer 現 reader である DB インスタンスに対してコネクションが張り続けられてしまうため、書き込みのリクエストに対してはエラーとなってしまう状態になります。 対応策 対応策としては以下を考えました。 Aurora 用のクライアント Gem を使用する Mysql2::Error が発生した場合、サーバーエラーにしつつコネクションを切断して再接続を促す 一定回数リクエストを処理するごとに再接続させる 今回採用したのは上記の 3 の「一定回数リクエストを処理するごとに再接続させる」対応です。 当初は対応策 1 の Gem の使用を検討しておりましたが、トランザクション中にフェイルオーバーが発生した際の挙動が本サービスには適合しないことが分かりました。またいくつかの対応策を複合して実装するという方法も考えられました。 今回においては、実装工数や、サービスの規模から考えうる必要十分の最小値を検討した結果、この判断としています。 再接続の度に発生するオーバーヘッドによる速度影響についても低負荷・高負荷の状態で検証を行いましたが、数値的には軽微であり、少々の遅延は許容することになりました。 この対応は、Aurora への移行の前、つまり通常の RDS で稼働している状態であってもリリースして問題ないものだったため、事前に実装・リリースを行うことができました。 料金 「現行の RDS がオーバースペックであることも課題のひとつ」と上記しておりましたが、その是正による料金の合理化についても副次的効果として期待していました。 Aurora の料金形態には、通常の RDS と同じ「DB インスタンス時間従量課金」「ストレージ時間従量課金」に加え、「I/O リクエスト数従量課金」という項目が追加されているため、比較を行う際は注意が必要です。 移行前後の条件は以下の通りです。 通常の RDS（移行前） オンデマンド RDS で稼働しているのは本番環境のみ db.m4.large ストレージ 100GB Aurora（移行後） オンデマンド 本番環境だけでなく検証環境も Aurora で稼働させる 本番環境 db.t3.medium, 検証環境 db.t3.small ストレージ 100GB（両環境とも） 移行前の通常の RDS では本番環境のみで月々 4 万円以上かかっていたコストですが、移行後は本番環境に加え検証環境においても Aurora を使用するようにしても合計 3 万円以下という計算となりました。月々 1 万円、年額 12 万円の節約になります。さらにはオンデマンドからリザーブドへ変更することも今後検討ができるため、コストカットの余地がまだ残されているのも嬉しいところです。 リリースに向けた準備 リリース作業のキモとなるデータベースの切り替えは、「リードレプリカからの昇格」という方法を採ることとしました。MySQL のバージョンアップについては、プライマリが通常の RDS から Aurora に切り替わった後に、Aurora インスタンスの MySQL バージョンを上げるための変更を実行します。 これらの作業をデータの不整合を発生させることなく完遂させるためには、 データベースへの書き込み動作をすべて停止させる 必要がありました。 これを実現するためには、データベースへの書き込み処理が発生するケースをすべて洗い出さなければいけません。調査をしたところ、本サービスでは「社内管理画面」と「バッチ処理」でのみ書き込み処理が実行されていることが分かりました。 つまり、一般ユーザからの書き込み処理は本サービスでは保有していないため、書き込みが行われるタイミングを把握・調整することが可能でした。したがって、一般ユーザが見ることのできるページをメンテナンスモードに切り替えるなどの「サービスのダウンタイム」を発生させることなく Aurora への移行と MySQL のバージョンアップを行える、ということになります。 リリース時に影響が生じる周辺情報の洗い出しも一通り済んだところで、次に「手順書」の作成に取り掛かりました。必要な全ての操作について順序に沿って詳細にまとめます。その中には、各段階にて万が一障害が発生した場合の切り戻し手順についても記載しています。 手順書を元に、検証環境にて同様の手順を実行し、予行演習を行いました。これによって、本番での作業を鮮明にイメージすることができます。また大抵の場合、手順書の不備やブラッシュアップできるところが見つかります。予行演習は本番作業を滞りなく実行するための最も重要なファクターのひとつかと思います。 実際に使用した手順書（一部抜粋） リリース作業 リリースで行った作業の要点をまとめると以下となります。 本番用データベースのリードレプリカを Aurora で作成 データベースへの書き込みを停止 社内管理画面の操作を停止いただくよう社内へのアナウンス バッチ処理の実行をすべて停止 レプリカ Aurora をプライマリへ昇格 データベースのコネクション更新のためサーバ 1 台ずつアプリケーションの再起動 バッチ処理の再開 動作確認 大きめのリリース作業はアクセスの多い時間帯を避けて行われることもあるかと思いますが、今回はサービスのダウンタイムなく作業を行えるケースであるため午前中からの作業開始となりました。また作業を行う自分の隣には先輩社員が構えており、ダブルチェックをしていだきました。 手順書の作成と予行演習の甲斐もあって、本番リリースを問題なく進めることができました。 まとめ サービスの特性に助けられたところは大きいですが、サービス停止などのダウンタイムを発生させることなく通常の RDS から Aurora への移行を完了させることができました。 スティーブ・ジョブズは数分のプレゼン発表のために数百時間の準備をしていたといいます。プレゼンで言うところのシナリオの作成とリハーサルの実行もそうですが、サービス特性の理解や検証を綿密に行うことも本番を成功させるためには欠かせません。準備を怠らないエンジニアでありたい、と執筆しながら改めて感じているところです。 さいごに メドレーでは「医療ヘルスケアの未来をつくる」というミッション実現のため、日々開発・運営を行っています。エンジニア・デザイナーをはじめ多くのポジションでメンバーを募集しております。もし少しでもご興味をお持ちいただけましたら、ぜひお気軽にお話しさせていただければと思います。 最後までお読みいただき、ありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは、人材プラットフォーム本部 プロダクト開発室 第一開発グループ所属の森川です。医療介護求人サイト「 ジョブメドレー 」の開発チームの一員として、現在はインフラタスクをメインに取り組んでいます。 今年（2021 年）の 6 月の話ではありますが、ジョブメドレーの連携サービスにて使用しているデータベースを、通常の RDS（ Amazon RDS for MySQL ）から Aurora（ Amazon Aurora ）に移行しました。 タイトルは自分でも大きく出たなと思ってはいるのですが、サービスの特性に助けられたところはありつつも、ダウンタイムなく移行することができました。今回はそのいきさつについてお話させていただこうと思います。 本稿では Amazon RDS for MySQL を「通常の RDS」、Amazon Aurora を「Aurora」と表記させていただきます。 ジョブメドレーの連携サービスについて ジョブメドレーは医療介護従事経験者が運営する就職・復職・転職のための求人サイトです。このジョブメドレーの連携サービスとして医療・介護・福祉・歯科従事者向けの情報サービスを他社と共同運営しています（以降、本サービス）。 本サービスはアプリケーションシステムのバックエンドの開発フレームワークとして Ruby on Rails（以降、Rails）を使用し、弊社で開発・運用を行っています。表示コンテンツは他社から共有していただくものを表示する形となっています。 発端 今年の 1 月末に AWS から以下のようなメールが届きました（内容を一部抜粋しています）。 Amazon RDS は、MySQL メジャーバージョン 5.6 の廃止 (EOL) プロセスを開始しています。 お客様は古いバージョンで実行されている RDS MySQL インスタンスを１つ以上お持ちであるように見受けられます。 Amazon RDS for MySQL 5.6 は、UTC 協定世界時間の 2021 年 8 月 3 日に廃止されます。 公式のお知らせは こちら です。 EOL 通知はドキッとします。できれば見たくないものです。 この対象となっていたのが、本サービスで使用している RDS の MySQL v5.6.39（当時）でした。 対応方針として以下を考えました。 通常の RDS のまま MySQL のバージョンを 5.7 に上げる 通常の RDS から Aurora への変更も行いつつ、MySQL のバージョンを 5.7 に上げる MySQL のバージョンを 8 まで上げる MySQL 8 系へのバージョンアップは対応範囲が大きくなりすぎるため今回は断念しました。5.6 の EOL 期限が迫っているため時間の余裕はあまりありません。また、もし 8 系に上げるとしても、5.7 へのバージョンアップは挟む必要がありそうです。 ジョブメドレー本体のシステムにおいても、性能やメンテナンス性の向上の観点から、通常の RDS から Aurora への移行を計画しております。その足がかりとして、関連アプリケーションの中でも比較的システム規模の小さいものから、先行して移行作業をしておきたいという要望がありました。 これらを加味して、今回のミッションは「 通常の RDS から Aurora への変更も行いつつ、MySQL のバージョンを 5.7 に上げる 」となりました。 検証 インフラ構成に変更を加える際には言うまでもなく検証が必要です。インフラ関連タスクに取り組むにあたって大きなウェイトを占めるのが検討・検証なのではないかと個人的には考えています。 Aurora への乗り換え検証のために、新たに DB インスタンスを用意しました。既存相当のスペックの通常 RDS とそれよりも少しスペックの落とした Aurora です。正確な比較を行う場合であれば、両 DB インスタンスのスペックは揃えるべきかとは思いますが、現行の RDS がオーバースペックであることも課題のひとつであったため、検証段階から Aurora のスペックを落として検証を行っています。よって検証結果による成否判断としては「著しい悪化が見られないか」という観点になっています。 既存相当の RDS のスペックは db.m4.large 、Aurora のスペックは暫定的に db.t3.medium を選択しました。また、データベースに流し込むデータは本番相当のものを個人情報などはマスクした上で用意しています。 検証の項目は以下の 4 点です。 レスポンスタイム検証 SQL ごとの速度検証 実行計画の検証 フェイルオーバー後に元 writer に対する接続が継続される問題への対応検証 レスポンスタイム検証 まずは、レスポンスタイムの影響について確認しました。 本サービスにおける主要なページの URL を選出します。それぞれのページに対して数回のリクエストを行い「低負荷状態」でのレスポンスタイムを比較しました。Aurora の方が一桁ミリ秒程度遅いという結果となりました。 次に Apache Bench を用いて短時間に並列でのリクエストを行い「高負荷状態」を再現して比較を行いました。本サービスはスパイクで負荷が高まるような性質ではないため、普段のアクセス頻度を元に「高負荷状態」がどの程度かを想定して定義しています。結果として、一部のページにて 1 秒ほど遅くなっていることが分かりました。スペックを上げることで解決ができるのかを調査するため、インスタンスサイズを db.t3.medium から db.t3.large に変更して改めて試しました。しかし Aurora の方が遅いという結果に変化は見られませんでした。アプリケーション側の調査を進めると、データベースの問題ではなくアプリケーション側の問題であることが分かり、別途対応ということになりました。 以上より、Aurora への移行によるレスポンスタイムへの影響としては、多少の性能の低下は見られたものの許容範囲内であり、大きな問題は見られないことが分かりました。 SQL ごとの速度検証 こちらはレスポンスタイムの検証に近しい検証ではありますが、生の SQL の速度の調査も行いました。アプリケーションを通して実行される SQL の中でも実行される頻度の高いものを選出し、アプリケーションを介さずクライアントツールから実行しています。 こちらも大きな問題は見られませんでした。 実行計画の検証 この検証でもアプリケーションの中で実行される頻度が高いクエリを選出し調査を行いました。使用したのはお馴染みの EXPLAIN ステートメントです。 実行計画に差分は見られなかったため問題はありませんでした。 フェイルオーバー後に元 writer に対する接続が継続される問題への対応検証 Rails アプリケーションへの Aurora 導入において、必ずと言ってよいほど障壁となるのがこの問題かと思います。 Aurora のフェイルオーバーと Rails への影響 Aurora の特徴や通常の RDS との差分については様々なサイト・記事で詳しくまとまっている情報ですので本稿での詳解は割愛しますが、Aurora のフェイルオーバーについてのみ概要を説明させていただきます。 マルチ AZ での Aurora DB クラスターのプライマリ DB インスタンス（writer と呼ばれる）において障害が発生した場合、フェイルオーバー（待機システムへの切り替え）が自動で実行されます。プライマリ DB インスタンスのリードレプリカ（reader と呼ばれる）を配置していた場合は、それが次のプライマリへと昇格し、エンドポイントも切り替わってくれます。 次に Rails の ActiveRecord のコネクションプールについてです。ActiveRecord はデータベースへの接続情報を保持し、そのコネクションを再利用することで接続時のオーバーヘッドを解消し、高速化を図る仕組みを保有しています。本サービスにおいて MySQL のクライアントとして使用している mysql2 では、コネクションがアクティブであることを mysql_ping が判定してくれるようです。しかし残念なことに Aurora 側でのフェイルオーバーの発生までは検知することができないようです。 したがって、フェイルオーバーが発生すると、プライマリから降格した元 writer 現 reader である DB インスタンスに対してコネクションが張り続けられてしまうため、書き込みのリクエストに対してはエラーとなってしまう状態になります。 対応策 対応策としては以下を考えました。 Aurora 用のクライアント Gem を使用する Mysql2::Error が発生した場合、サーバーエラーにしつつコネクションを切断して再接続を促す 一定回数リクエストを処理するごとに再接続させる 今回採用したのは上記の 3 の「一定回数リクエストを処理するごとに再接続させる」対応です。 当初は対応策 1 の Gem の使用を検討しておりましたが、トランザクション中にフェイルオーバーが発生した際の挙動が本サービスには適合しないことが分かりました。またいくつかの対応策を複合して実装するという方法も考えられました。 今回においては、実装工数や、サービスの規模から考えうる必要十分の最小値を検討した結果、この判断としています。 再接続の度に発生するオーバーヘッドによる速度影響についても低負荷・高負荷の状態で検証を行いましたが、数値的には軽微であり、少々の遅延は許容することになりました。 この対応は、Aurora への移行の前、つまり通常の RDS で稼働している状態であってもリリースして問題ないものだったため、事前に実装・リリースを行うことができました。 料金 「現行の RDS がオーバースペックであることも課題のひとつ」と上記しておりましたが、その是正による料金の合理化についても副次的効果として期待していました。 Aurora の料金形態には、通常の RDS と同じ「DB インスタンス時間従量課金」「ストレージ時間従量課金」に加え、「I/O リクエスト数従量課金」という項目が追加されているため、比較を行う際は注意が必要です。 移行前後の条件は以下の通りです。 通常の RDS（移行前） オンデマンド RDS で稼働しているのは本番環境のみ db.m4.large ストレージ 100GB Aurora（移行後） オンデマンド 本番環境だけでなく検証環境も Aurora で稼働させる 本番環境 db.t3.medium, 検証環境 db.t3.small ストレージ 100GB（両環境とも） 移行前の通常の RDS では本番環境のみで月々 4 万円以上かかっていたコストですが、移行後は本番環境に加え検証環境においても Aurora を使用するようにしても合計 3 万円以下という計算となりました。月々 1 万円、年額 12 万円の節約になります。さらにはオンデマンドからリザーブドへ変更することも今後検討ができるため、コストカットの余地がまだ残されているのも嬉しいところです。 リリースに向けた準備 リリース作業のキモとなるデータベースの切り替えは、「リードレプリカからの昇格」という方法を採ることとしました。MySQL のバージョンアップについては、プライマリが通常の RDS から Aurora に切り替わった後に、Aurora インスタンスの MySQL バージョンを上げるための変更を実行します。 これらの作業をデータの不整合を発生させることなく完遂させるためには、 データベースへの書き込み動作をすべて停止させる 必要がありました。 これを実現するためには、データベースへの書き込み処理が発生するケースをすべて洗い出さなければいけません。調査をしたところ、本サービスでは「社内管理画面」と「バッチ処理」でのみ書き込み処理が実行されていることが分かりました。 つまり、一般ユーザからの書き込み処理は本サービスでは保有していないため、書き込みが行われるタイミングを把握・調整することが可能でした。したがって、一般ユーザが見ることのできるページをメンテナンスモードに切り替えるなどの「サービスのダウンタイム」を発生させることなく Aurora への移行と MySQL のバージョンアップを行える、ということになります。 リリース時に影響が生じる周辺情報の洗い出しも一通り済んだところで、次に「手順書」の作成に取り掛かりました。必要な全ての操作について順序に沿って詳細にまとめます。その中には、各段階にて万が一障害が発生した場合の切り戻し手順についても記載しています。 手順書を元に、検証環境にて同様の手順を実行し、予行演習を行いました。これによって、本番での作業を鮮明にイメージすることができます。また大抵の場合、手順書の不備やブラッシュアップできるところが見つかります。予行演習は本番作業を滞りなく実行するための最も重要なファクターのひとつかと思います。 実際に使用した手順書（一部抜粋） リリース作業 リリースで行った作業の要点をまとめると以下となります。 本番用データベースのリードレプリカを Aurora で作成 データベースへの書き込みを停止 社内管理画面の操作を停止いただくよう社内へのアナウンス バッチ処理の実行をすべて停止 レプリカ Aurora をプライマリへ昇格 データベースのコネクション更新のためサーバ 1 台ずつアプリケーションの再起動 バッチ処理の再開 動作確認 大きめのリリース作業はアクセスの多い時間帯を避けて行われることもあるかと思いますが、今回はサービスのダウンタイムなく作業を行えるケースであるため午前中からの作業開始となりました。また作業を行う自分の隣には先輩社員が構えており、ダブルチェックをしていだきました。 手順書の作成と予行演習の甲斐もあって、本番リリースを問題なく進めることができました。 まとめ サービスの特性に助けられたところは大きいですが、サービス停止などのダウンタイムを発生させることなく通常の RDS から Aurora への移行を完了させることができました。 スティーブ・ジョブズは数分のプレゼン発表のために数百時間の準備をしていたといいます。プレゼンで言うところのシナリオの作成とリハーサルの実行もそうですが、サービス特性の理解や検証を綿密に行うことも本番を成功させるためには欠かせません。準備を怠らないエンジニアでありたい、と執筆しながら改めて感じているところです。 さいごに メドレーでは「医療ヘルスケアの未来をつくる」というミッション実現のため、日々開発・運営を行っています。エンジニア・デザイナーをはじめ多くのポジションでメンバーを募集しております。もし少しでもご興味をお持ちいただけましたら、ぜひお気軽にお話しさせていただければと思います。 最後までお読みいただき、ありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。医療介護求人サイト「ジョブメドレー」の開発を担当しているエンジニアの山田です。 今年の新卒エンジニア研修において、メンターを担当しました。 メドレーでは 2019 年度から新卒採用を行なっており、今年 2021 年度は 5 名の新卒がエンジニアとして入社しました。 例年と同じく 4 月から 9 月にかけて、約 5 ヶ月間の新卒エンジニア研修を実施しましたので、その取り組みを、研修受講者である新卒からの声も交えてご紹介します。 新卒研修の概要 今年の新卒研修の最終ゴールは、「 メドレーのエンジニアとして、 Our Essentials (※) を体現し、顧客へ価値提供できるようになるための基礎を身につけ、経験を得ること 」として掲げました。 ※) メドレーの行動原則 メドレーの新卒エンジニア研修では、技術を身につけることだけではなく、ビジネスパーソンとしての基礎を身につけ、メドレーが大切にしている価値観を理解し、体現する意識をもって、顧客への価値提供について自分の言葉で話せるようになることまでを目指してもらいます。 研修は昨年同様、大きく分けて、4 つのフェーズに区切って行いました。 また、全研修期間を通じて、各新卒にはメンターを一人ずつ付けました。メンターは、一週間に 1~2 回のペースで新卒と 1on1 ミーティングを実施し、フィジカルとメンタルの両面を気遣い、個別にフォローを行いました。 新卒研修の内容 フェーズ 1：社会人&メドレー基礎研修 リスク研修 インサイダー取引防止研修 コンプライアンス研修 情報セキュリティ研修 ビジネス研修 ビジネスマナー研修 ビジネススキル研修 ビジネススタンス研修（外部研修） フェーズ 1 では、 成果を出し、価値を発揮するために必要なビジネスパーソンとしての基本的な仕事の型を身につけること をゴールとしました。 リスク研修では、メドレー社員として、社会人として、身の周りで起こりうるリスクについて考え、いかにそれらのリスクと向き合うかを講義形式で学んでもらいました。 ビジネス研修では、社会人としての最低限のマナーを学び、論理的思考力、コミュニケーション力など、エンジニア職に限らない課題解決力へつながるポータブルな知識を、座学とワークショップを通じて定着してもらうことを図りました。 また、社会人の基準で仕事と向き合い、適切な報連相によって周囲と協働していくことの重要性についても学んでもらいました。 新卒からの声 質の高い、多量のインプット・アウトプットができた 伝わるメールの書き方、名刺の渡し方など、社会人に必須のマナーやスキルを認識できた ワークを通じて、言葉では理解していても行動するとできないことを洗い出せた フェーズ 2：エンジニア基礎研修 開発基礎 1 メドレーエンジニアとして求めること 事業（ジョブメドレー ・ CLINICS ・介護のほんね）の概要説明 開発基礎研修（Ruby on Rails チュートリアル） 開発実践 （要件定義〜リリースまで） 開発基礎 2 技術書の輪読会 ドキュメンテーションスキル研修 プレゼンテーションスキル研修 中間レポート作成 中間報告会 フェーズ 2 では、新卒研修後に開発業務に入ってもらえるよう、 エンジニアとしての基礎を身につけること をゴールとしました。 メドレーエンジニアとして求めること 開発に関わるこのフェーズにおいても、要件定義を含む汎用的な技術的スキルは勿論のこと、メドレーエンジニアが共通して持つべき価値観などを共有するため、フェーズ 2 初日は「 メドレーエンジニアとして求めること 」と題して、エンジニアの執行役員 田中が講義を行いました。 講義では、「 エンジニア とは、 エンジニアの価値 とは、 プロエンジニア とはなんでしょうか？」という問いから始まり、講義の終わりにはもう一度同じ問いかけをして締めくくり、新卒がメドレーの求めるエンジニア像について自身の言葉で話せるように考えてもらいました。 メドレーが求めるエンジニア像については、CTO 平山の メドレー平山の中央突破: THE エンジニア にも書かれていますので、よろしければ、あわせてご覧ください。 さらに、メドレーが展開する各事業および関連するプロダクトの概要説明をプロダクトマネージャーが行い、メドレーで開発する意義をあらためて認識してもらいました。 開発基礎研修 2 日目より、 Ruby on Rails チュートリアル （以下、「Rails チュートリアル」）を教材とした、開発基礎研修に移りました。 メドレーのプロダクトは Rails で作られているものが多く、Web アプリケーションを開発するための基礎を身につけるためにも、Rails チュートリアルの内容を実施してもらいました。 単純に、Rails チュートリアルの内容に沿って、ダラダラと写経するのではなく、随時、学んだことは Confluence にまとめ、GitHub 上で Pull Request を作成する形で、ソースコードを共有してもらいました。 学んだことを自分の言葉に置き換えてアウトプットすることで反復学習を促し、Pull Request を作成してもらうことで GitHub の使い方に慣れてもらうことを図りました。 また、デイリーで朝会と夕会を実施しました。朝会は仕事のリズムを整えるための顔合わせ、夕会は新卒から質問・成果を共有してメンターがそれに対してフィードバックをする場としてそれぞれ実施しました。 研修前に既に Rails チュートリアルを一周していた新卒もいましたが、二周目を実施して新たな気付きを得たり、AWS を用いてクラウド上に環境構築し、作成した Web アプリケーションをデプロイするまでを実践してもらうなど、インフラに関しても理解を深めてもらうことができました。 新卒からの声 システムのパフォーマンスを上げるための工夫を知ることができた バグ発生〜原因特定〜修正、というデバッグのスピードが、研修序盤から飛躍的に上がった プロダクトで利用している AWS の各種サービスの概要を理解できたことに加え、サービス間の繋がりやネットワークの流れに関しても理解を深めることができた 開発実践 開発基礎研修にて Web アプリケーション開発の基礎を学んだ後は、「 メドレー/グループ会社で使う来訪者受付システム 」を開発題材として、開発実践研修を行いました。 開発業務全体の流れを把握することで、 チームで開発（課題解決）することを経験し、今後の仕事に役立たせること を目的としました。 本研修で達成すべきこととして掲げていたものは主に、次の通りです。 プロジェクト管理能力を身につけること 開発する対象を体系的に整理できる能力を養うこと システム設計に関する基礎的な物事を理解すること チーム開発を理解すること 品質を理解すること 既に決まりきった仕様書に沿って開発するのではなく、新卒自身が現状の問題把握や課題整理を行って、ユーザーへ価値提供するために何を作るべきかを考えることから始まり、リリース後の運用方法やランニングコストのことまで考え提案してもらいました。 開発実践研修は約 1 ヶ月の期間をかけて行いました。大まかな流れとしては、次の通りです。 要件定義（ヒアリング・現状把握・課題整理・要求分析・機能/非機能要件の洗い出し・ UI 草案） プロジェクト計画（役割分担・ WBS/ガントチャート作成） 設計（画面設計・機能設計・データモデリング・方式設計・インフラ設計） 開発（実装・コードレビュー） QA（テスト設計・テスト） 成果発表（成果物を関係者へプレゼン・リリース） 方式設計の一部として、開発に使用する言語などの選定も新卒自身が行いました。 今回作成した社員向け管理画面と来訪者向け画面はいずれも SPA（一部、PWA）のアーキテクチャを採用し、主なライブラリ/フレームワークに関して、フロントエンドは TypeScript , React , Next.js , Chakra UI , Ionic Framework 、バックエンドは Ruby on Rails（API モード）をそれぞれ利用することとなりました。 選定理由としては主に、次の通りです。 TypeScript, React（両画面共通） ロジックからテンプレートまでの全てのコードを静的型付けで書くことができ、堅牢性に優れているため Next.js, Chakra UI（社員向け管理画面） ゼロコンフィグでビルドやレンダリングを最適化できるため アクセシビリティに優れたリッチな UI を素早く構築できるため Ionic Framework（来訪者向け画面） iPad 上で、ネイティブアプリのような UI/UX を提供するため Ruby on Rails API モード フロントエンドとバックエンドを分離して疎結合にするため 短期間で構築するため 社内でもよく使われておりメンテナンスしやすいため インフラは AWS を採用し、EC2, S3, RDS, CloudFront, Route53, CloudWatch などのサービスを利用しました。 結果的に、本研修プログラムの成果物としてリリースされたシステムは「 Medley Entrance 」という名前で、社内ツールとして現在、毎日稼働しており、ユーザーとしてメドレー/グループ社員だけではなく、来訪者の方々にも使っていただいています。 Medley Entrance（上：社員向け管理画面、下：来訪者向け画面） チームで課題解決に臨み、価値提供までの実績を残せたことは自信につながり、開発実践研修のやりがいとして、感じてもらえたのではないでしょうか。 要件定義などの期間中、想定よりもスムーズに進められなかった時も他責にせず、各々がリーダーシップを発揮し、建設的に進めていく新卒の様子をメンターの一人として傍で見させてもらいました。 この 1 ヶ月間の開発実践研修を通じて、技術力はさることながら、課題解決に対する十分な熱意と主体性を新卒から感じられ、とても頼もしい印象として残りました。 新卒からの声 開発の中での方針を意識して設計/実装することができた(シンプルにする) QA とはそもそも何かというリサーチから入り、有識者の考え方を軸に方針を決めてから始められた 各々が最適なパフォーマンスを発揮できる環境づくりを意識して、高速な意思決定が可能な体制を整えることができた 要件が決まりきっていない中で設計するのは難しかった 開発タスクが集中していた時に、プロジェクト全体の現状を把握できていなかった 文章を作るスキルが足りていない 技術書の輪読会 フェーズ 2 の開発基礎 2 の輪読会では、 『Web を支える技術 -HTTP、URI、HTML、そして REST』 を題材書籍として、7 日間に渡って毎日、次の手順で実施しました。 参加者が同じパートをあらかじめ読んでおき、書籍から学んだこと、ネットなどで調べても解消しきれなかった疑問点などをまとめる その内容をもとに、夕方のミーティング時において、各自が発表してディスカッションを行う ディスカッションした内容は議事録にまとめる 輪読会は他者からの学びを共有してもらうことで、自分にはなかった視点・気付きを獲得し、その書籍への理解をより深められる効果があります。 本研修プログラムにおける輪読会の目的としては、 Web サービスを開発していく上で必要となる知識へ触れることにより、今後獲得していくべき知識のベースラインを理解すること でしたが、輪読会ならではのメリット・楽しさを新卒に実感してもらえたことも、副次的な効果としてあったと思います。 新卒からの声 Web の基本的な知識を「なぜ登場したのか」を理解しながら網羅的に学ぶことができた 文書でまとめた後に、口で説明することが学んだ内容の定着に良いと感じた これまでなんとなく実装していたことの仕組みを学ぶことで、知識として定着することができた 中間報告会 フェーズ 2：エンジニア基礎研修最後の研修プログラムである中間報告会に向けて、ドキュメンテーションスキル研修、プレゼンテーションスキル研修を実施しました。 上記スキルが必要となる背景は、次の通りです。 エンジニアリングを通じた課題解決とはプログラムを書くだけでは解決しない場面もある 背景、目的を正しくステークホルダーへ共有しながらチームとして取り組んでいくことになる 伝えたいことを文章として整理し、他者へ分かりやすく伝えていくことが求められる また、メドレーの行動原則 Our Essentials を構成する要素として、「ドキュメントドリブン」「全てを明確に」という項目が含まれており、これらを実現するためにも、とても重要なスキルとしてメドレーは考えています。 新卒研修が終わった後も、エンジニアとして技術的なスキルを身につける機会は日常的に多くありますが、上記のようなスキルをまとめて習得する機会は少ないため、このような研修を社会人のはじめから受けておくことで、その後の伸びしろが違ってくるのではないかと思います。 研修が終わった後は、各自で報告会用の資料を作成し、研修講師からの添削を受けました。 中間報告会は各部署の開発マネージャーを発表相手として、当日は程よい緊張感をもって、良い雰囲気で報告会を終えられました。 フェーズ 3：事業部 OJT 事業部研修 取締役豊田からの講義 CLINICS 事業部研修 ジョブメドレー事業部研修 開発 OJT システム全体像説明 環境構築 各プロダクトの開発チームでの OJT フェーズ 3 では、 顧客の課題と、顧客への価値提供のための各チームの連携を体感し、メドレーの顧客提供価値を自分の言葉で話せるようになること をゴールとしました。 フェーズ 3 のはじめに、取締役豊田による日本の医療の課題とメドレーの取り組みに関する講義を受講してもらいました。 持続可能な医療体制を構築していくためにメドレーが成すべきことなどの話を聞いた後に、新卒からの質問の受け答えによって理解を深め、メドレーの社会的意義をあらためて認識してもらい、エンジニアとしてだけではなく、 メドレー社員としての自覚 を強めてもらいました。 事業部研修 開発 OJT で手を動かす前に、自分たちが何のために開発するのかを具体的にイメージできるよう、次のように、各現場に参加してもらいました。 見込顧客への架電業務見学 商談前の社内ミーティング参加 商談現場同席 定例会議参加 事業部のスタッフが、顧客の課題に対して、どのような対応をしていて、どのようにプロダクトを説明しているのか、事業部の各チームが、どのように連携して最終的に顧客に価値を届けるのかの全体観を知ってもらうことを狙いとしていました。 開発チームのエンジニアは業務上、プロダクトのエンドユーザーである顧客の声などを商談のタイミングから聞ける機会はなかなか無いので、研修を通じて話を聞けたことは、今後の開発モチベーションにも影響する良い機会だったと思います。 新卒からの声 ユーザー、顧客、事業部が抱える課題を確認できたことで、開発以外にも目を向けるきっかけになり良かった 各部署が KPI として定めている数字を知ることができ、開発に降りてきている施策の影響箇所がどの部分かを理解できた上で、開発に取り組むことができるようになった 各部署のミーディングに参加することで、各部署がどのような考えで何を目指しているのかを理解でき、メドレー全体として目指している方向性が掴めた 開発 OJT 事業部研修に続く開発 OJT では、 ジョブメドレー 、 CLINICS 、 介護のほんね の開発チームに分かれて、研修を実施しました。 OJT 配属先では、メンターとは別に、トレーナーを付けて業務の進め方などをサポートしました。トレーナーは配属先の先輩エンジニアが担当しました。 OJT の流れとしては、初日に、プロダクトがどのように動いているのか、システム全体像を把握することから始まり、各自、ドキュメントに沿って、PC にローカル開発環境をセットアップしました。 その後は、他の先輩エンジニアと同様に、GitHub Issue で管理されている課題を解消することを日々の目標としてこなしてもらいました。ただし、単に Issue に書かれている課題をクリアしようとするのではなく、 そもそも、なぜそれをやるのか、Issue の背景や起票者の意図を十分に理解した上で、プロダクトのあるべき姿に導く ことを意識してもらいました。 Issue に書かれている内容の理解が不十分だったり、解決方針がうまく定まらない場合は随時、ミーティングの時間を設けて、Issue 起票者やトレーナーと認識合わせを行い、認識の相違から生まれるミスコミュニケーションを極力減らすよう、取り組みました。 技術的な質問に関しても、定期的に質問タイムを設けたり、複雑になりそうな実装や、つまずきポイントとなりそうな箇所に関しては、 画面共有を用いてレビュー を行い、疑問点に関してもその場で確認して、解消してもらいました。 緊急事態宣言期間中だったため、会社全体で原則、在宅勤務の体制となっており、対面でのコミュニケーションが希薄になりがちでしたが、朝会、夕会を含め、たとえ新卒から質問が無くても質問タイムでのミーティングは定期的に実施するなど、 できるだけ頻繁に顔合わせして、新卒本人の声と顔を確認する よう心がけました。 Issue へのアサインから始まって、実装 -> レビュー依頼 -> QA -> リリース -> Issue 起票者への報告まで、一連の開発フローを経験してもらい、チーム内での開発業務に慣れてもらうことができました。 フェーズ 4：最終報告 新卒研修最後のプログラムとして、メドレー役員陣に向けた最終報告会を実施しました。 最終報告会の目的としては、次の通りです。 学んだことの知識を深化させる 自らの得手・不得手を捉え、将来の成長計画を立てる 体系的に整理・文書化して他者へ伝えるスキルを向上させる 役員陣に向けてプレゼンすることで、本配属に向けた決意表明として区切りを付ける 役員陣への発表であることに加え、一人あたりの発表時間にも制限が設けられており、当日の緊張はかなりのものだったと思います。 前日に発表会場を下見して、リハーサルを入念に行うなど、当日の発表会を成功させるため、メドレーのエンジニアとしての自覚を持って、発表準備に取り組んでいました。 技術志向とプロダクト志向の両輪を目指すエンジニア募集中 メドレーの研修では、技術的な講義や実践だけで終わるのではなく、ビジネスパーソンとして必要な基礎も身につけ、なぜ開発するのかを追究し、プロダクトを通じた課題解決を実体験してもらうことを重視しています。 メドレーでは、医療ヘルスケア分野の課題解決に挑みたいエンジニアを募集しています。 新卒の学生に限らず、中途採用も行っているので、エンジニアの方で少しでも興味を持っていただけたら、是非、面談でお話ししましょう。 最後までお読みいただき、誠にありがとうございました。 P.S. 昨年、一昨年の新卒研修の様子はこちらより、それぞれご覧いただけます。 2020 年度新卒エンジニア研修について 2019 年度新卒エンジニア研修について 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。医療介護求人サイト「ジョブメドレー」の開発を担当しているエンジニアの山田です。 今年の新卒エンジニア研修において、メンターを担当しました。 メドレーでは 2019 年度から新卒採用を行なっており、今年 2021 年度は 5 名の新卒がエンジニアとして入社しました。 例年と同じく 4 月から 9 月にかけて、約 5 ヶ月間の新卒エンジニア研修を実施しましたので、その取り組みを、研修受講者である新卒からの声も交えてご紹介します。 新卒研修の概要 今年の新卒研修の最終ゴールは、「 メドレーのエンジニアとして、 Our Essentials (※) を体現し、顧客へ価値提供できるようになるための基礎を身につけ、経験を得ること 」として掲げました。 ※) メドレーの行動原則 メドレーの新卒エンジニア研修では、技術を身につけることだけではなく、ビジネスパーソンとしての基礎を身につけ、メドレーが大切にしている価値観を理解し、体現する意識をもって、顧客への価値提供について自分の言葉で話せるようになることまでを目指してもらいます。 研修は昨年同様、大きく分けて、4 つのフェーズに区切って行いました。 また、全研修期間を通じて、各新卒にはメンターを一人ずつ付けました。メンターは、一週間に 1~2 回のペースで新卒と 1on1 ミーティングを実施し、フィジカルとメンタルの両面を気遣い、個別にフォローを行いました。 新卒研修の内容 フェーズ 1：社会人&メドレー基礎研修 リスク研修 インサイダー取引防止研修 コンプライアンス研修 情報セキュリティ研修 ビジネス研修 ビジネスマナー研修 ビジネススキル研修 ビジネススタンス研修（外部研修） フェーズ 1 では、 成果を出し、価値を発揮するために必要なビジネスパーソンとしての基本的な仕事の型を身につけること をゴールとしました。 リスク研修では、メドレー社員として、社会人として、身の周りで起こりうるリスクについて考え、いかにそれらのリスクと向き合うかを講義形式で学んでもらいました。 ビジネス研修では、社会人としての最低限のマナーを学び、論理的思考力、コミュニケーション力など、エンジニア職に限らない課題解決力へつながるポータブルな知識を、座学とワークショップを通じて定着してもらうことを図りました。 また、社会人の基準で仕事と向き合い、適切な報連相によって周囲と協働していくことの重要性についても学んでもらいました。 新卒からの声 質の高い、多量のインプット・アウトプットができた 伝わるメールの書き方、名刺の渡し方など、社会人に必須のマナーやスキルを認識できた ワークを通じて、言葉では理解していても行動するとできないことを洗い出せた フェーズ 2：エンジニア基礎研修 開発基礎 1 メドレーエンジニアとして求めること 事業（ジョブメドレー ・ CLINICS ・介護のほんね）の概要説明 開発基礎研修（Ruby on Rails チュートリアル） 開発実践 （要件定義〜リリースまで） 開発基礎 2 技術書の輪読会 ドキュメンテーションスキル研修 プレゼンテーションスキル研修 中間レポート作成 中間報告会 フェーズ 2 では、新卒研修後に開発業務に入ってもらえるよう、 エンジニアとしての基礎を身につけること をゴールとしました。 メドレーエンジニアとして求めること 開発に関わるこのフェーズにおいても、要件定義を含む汎用的な技術的スキルは勿論のこと、メドレーエンジニアが共通して持つべき価値観などを共有するため、フェーズ 2 初日は「 メドレーエンジニアとして求めること 」と題して、エンジニアの執行役員 田中が講義を行いました。 講義では、「 エンジニア とは、 エンジニアの価値 とは、 プロエンジニア とはなんでしょうか？」という問いから始まり、講義の終わりにはもう一度同じ問いかけをして締めくくり、新卒がメドレーの求めるエンジニア像について自身の言葉で話せるように考えてもらいました。 メドレーが求めるエンジニア像については、CTO 平山の メドレー平山の中央突破: THE エンジニア にも書かれていますので、よろしければ、あわせてご覧ください。 さらに、メドレーが展開する各事業および関連するプロダクトの概要説明をプロダクトマネージャーが行い、メドレーで開発する意義をあらためて認識してもらいました。 開発基礎研修 2 日目より、 Ruby on Rails チュートリアル （以下、「Rails チュートリアル」）を教材とした、開発基礎研修に移りました。 メドレーのプロダクトは Rails で作られているものが多く、Web アプリケーションを開発するための基礎を身につけるためにも、Rails チュートリアルの内容を実施してもらいました。 単純に、Rails チュートリアルの内容に沿って、ダラダラと写経するのではなく、随時、学んだことは Confluence にまとめ、GitHub 上で Pull Request を作成する形で、ソースコードを共有してもらいました。 学んだことを自分の言葉に置き換えてアウトプットすることで反復学習を促し、Pull Request を作成してもらうことで GitHub の使い方に慣れてもらうことを図りました。 また、デイリーで朝会と夕会を実施しました。朝会は仕事のリズムを整えるための顔合わせ、夕会は新卒から質問・成果を共有してメンターがそれに対してフィードバックをする場としてそれぞれ実施しました。 研修前に既に Rails チュートリアルを一周していた新卒もいましたが、二周目を実施して新たな気付きを得たり、AWS を用いてクラウド上に環境構築し、作成した Web アプリケーションをデプロイするまでを実践してもらうなど、インフラに関しても理解を深めてもらうことができました。 新卒からの声 システムのパフォーマンスを上げるための工夫を知ることができた バグ発生〜原因特定〜修正、というデバッグのスピードが、研修序盤から飛躍的に上がった プロダクトで利用している AWS の各種サービスの概要を理解できたことに加え、サービス間の繋がりやネットワークの流れに関しても理解を深めることができた 開発実践 開発基礎研修にて Web アプリケーション開発の基礎を学んだ後は、「 メドレー/グループ会社で使う来訪者受付システム 」を開発題材として、開発実践研修を行いました。 開発業務全体の流れを把握することで、 チームで開発（課題解決）することを経験し、今後の仕事に役立たせること を目的としました。 本研修で達成すべきこととして掲げていたものは主に、次の通りです。 プロジェクト管理能力を身につけること 開発する対象を体系的に整理できる能力を養うこと システム設計に関する基礎的な物事を理解すること チーム開発を理解すること 品質を理解すること 既に決まりきった仕様書に沿って開発するのではなく、新卒自身が現状の問題把握や課題整理を行って、ユーザーへ価値提供するために何を作るべきかを考えることから始まり、リリース後の運用方法やランニングコストのことまで考え提案してもらいました。 開発実践研修は約 1 ヶ月の期間をかけて行いました。大まかな流れとしては、次の通りです。 要件定義（ヒアリング・現状把握・課題整理・要求分析・機能/非機能要件の洗い出し・ UI 草案） プロジェクト計画（役割分担・ WBS/ガントチャート作成） 設計（画面設計・機能設計・データモデリング・方式設計・インフラ設計） 開発（実装・コードレビュー） QA（テスト設計・テスト） 成果発表（成果物を関係者へプレゼン・リリース） 方式設計の一部として、開発に使用する言語などの選定も新卒自身が行いました。 今回作成した社員向け管理画面と来訪者向け画面はいずれも SPA（一部、PWA）のアーキテクチャを採用し、主なライブラリ/フレームワークに関して、フロントエンドは TypeScript , React , Next.js , Chakra UI , Ionic Framework 、バックエンドは Ruby on Rails（API モード）をそれぞれ利用することとなりました。 選定理由としては主に、次の通りです。 TypeScript, React（両画面共通） ロジックからテンプレートまでの全てのコードを静的型付けで書くことができ、堅牢性に優れているため Next.js, Chakra UI（社員向け管理画面） ゼロコンフィグでビルドやレンダリングを最適化できるため アクセシビリティに優れたリッチな UI を素早く構築できるため Ionic Framework（来訪者向け画面） iPad 上で、ネイティブアプリのような UI/UX を提供するため Ruby on Rails API モード フロントエンドとバックエンドを分離して疎結合にするため 短期間で構築するため 社内でもよく使われておりメンテナンスしやすいため インフラは AWS を採用し、EC2, S3, RDS, CloudFront, Route53, CloudWatch などのサービスを利用しました。 結果的に、本研修プログラムの成果物としてリリースされたシステムは「 Medley Entrance 」という名前で、社内ツールとして現在、毎日稼働しており、ユーザーとしてメドレー/グループ社員だけではなく、来訪者の方々にも使っていただいています。 Medley Entrance（上：社員向け管理画面、下：来訪者向け画面） チームで課題解決に臨み、価値提供までの実績を残せたことは自信につながり、開発実践研修のやりがいとして、感じてもらえたのではないでしょうか。 要件定義などの期間中、想定よりもスムーズに進められなかった時も他責にせず、各々がリーダーシップを発揮し、建設的に進めていく新卒の様子をメンターの一人として傍で見させてもらいました。 この 1 ヶ月間の開発実践研修を通じて、技術力はさることながら、課題解決に対する十分な熱意と主体性を新卒から感じられ、とても頼もしい印象として残りました。 新卒からの声 開発の中での方針を意識して設計/実装することができた(シンプルにする) QA とはそもそも何かというリサーチから入り、有識者の考え方を軸に方針を決めてから始められた 各々が最適なパフォーマンスを発揮できる環境づくりを意識して、高速な意思決定が可能な体制を整えることができた 要件が決まりきっていない中で設計するのは難しかった 開発タスクが集中していた時に、プロジェクト全体の現状を把握できていなかった 文章を作るスキルが足りていない 技術書の輪読会 フェーズ 2 の開発基礎 2 の輪読会では、 『Web を支える技術 -HTTP、URI、HTML、そして REST』 を題材書籍として、7 日間に渡って毎日、次の手順で実施しました。 参加者が同じパートをあらかじめ読んでおき、書籍から学んだこと、ネットなどで調べても解消しきれなかった疑問点などをまとめる その内容をもとに、夕方のミーティング時において、各自が発表してディスカッションを行う ディスカッションした内容は議事録にまとめる 輪読会は他者からの学びを共有してもらうことで、自分にはなかった視点・気付きを獲得し、その書籍への理解をより深められる効果があります。 本研修プログラムにおける輪読会の目的としては、 Web サービスを開発していく上で必要となる知識へ触れることにより、今後獲得していくべき知識のベースラインを理解すること でしたが、輪読会ならではのメリット・楽しさを新卒に実感してもらえたことも、副次的な効果としてあったと思います。 新卒からの声 Web の基本的な知識を「なぜ登場したのか」を理解しながら網羅的に学ぶことができた 文書でまとめた後に、口で説明することが学んだ内容の定着に良いと感じた これまでなんとなく実装していたことの仕組みを学ぶことで、知識として定着することができた 中間報告会 フェーズ 2：エンジニア基礎研修最後の研修プログラムである中間報告会に向けて、ドキュメンテーションスキル研修、プレゼンテーションスキル研修を実施しました。 上記スキルが必要となる背景は、次の通りです。 エンジニアリングを通じた課題解決とはプログラムを書くだけでは解決しない場面もある 背景、目的を正しくステークホルダーへ共有しながらチームとして取り組んでいくことになる 伝えたいことを文章として整理し、他者へ分かりやすく伝えていくことが求められる また、メドレーの行動原則 Our Essentials を構成する要素として、「ドキュメントドリブン」「全てを明確に」という項目が含まれており、これらを実現するためにも、とても重要なスキルとしてメドレーは考えています。 新卒研修が終わった後も、エンジニアとして技術的なスキルを身につける機会は日常的に多くありますが、上記のようなスキルをまとめて習得する機会は少ないため、このような研修を社会人のはじめから受けておくことで、その後の伸びしろが違ってくるのではないかと思います。 研修が終わった後は、各自で報告会用の資料を作成し、研修講師からの添削を受けました。 中間報告会は各部署の開発マネージャーを発表相手として、当日は程よい緊張感をもって、良い雰囲気で報告会を終えられました。 フェーズ 3：事業部 OJT 事業部研修 取締役豊田からの講義 CLINICS 事業部研修 ジョブメドレー事業部研修 開発 OJT システム全体像説明 環境構築 各プロダクトの開発チームでの OJT フェーズ 3 では、 顧客の課題と、顧客への価値提供のための各チームの連携を体感し、メドレーの顧客提供価値を自分の言葉で話せるようになること をゴールとしました。 フェーズ 3 のはじめに、取締役豊田による日本の医療の課題とメドレーの取り組みに関する講義を受講してもらいました。 持続可能な医療体制を構築していくためにメドレーが成すべきことなどの話を聞いた後に、新卒からの質問の受け答えによって理解を深め、メドレーの社会的意義をあらためて認識してもらい、エンジニアとしてだけではなく、 メドレー社員としての自覚 を強めてもらいました。 事業部研修 開発 OJT で手を動かす前に、自分たちが何のために開発するのかを具体的にイメージできるよう、次のように、各現場に参加してもらいました。 見込顧客への架電業務見学 商談前の社内ミーティング参加 商談現場同席 定例会議参加 事業部のスタッフが、顧客の課題に対して、どのような対応をしていて、どのようにプロダクトを説明しているのか、事業部の各チームが、どのように連携して最終的に顧客に価値を届けるのかの全体観を知ってもらうことを狙いとしていました。 開発チームのエンジニアは業務上、プロダクトのエンドユーザーである顧客の声などを商談のタイミングから聞ける機会はなかなか無いので、研修を通じて話を聞けたことは、今後の開発モチベーションにも影響する良い機会だったと思います。 新卒からの声 ユーザー、顧客、事業部が抱える課題を確認できたことで、開発以外にも目を向けるきっかけになり良かった 各部署が KPI として定めている数字を知ることができ、開発に降りてきている施策の影響箇所がどの部分かを理解できた上で、開発に取り組むことができるようになった 各部署のミーディングに参加することで、各部署がどのような考えで何を目指しているのかを理解でき、メドレー全体として目指している方向性が掴めた 開発 OJT 事業部研修に続く開発 OJT では、 ジョブメドレー 、 CLINICS 、 介護のほんね の開発チームに分かれて、研修を実施しました。 OJT 配属先では、メンターとは別に、トレーナーを付けて業務の進め方などをサポートしました。トレーナーは配属先の先輩エンジニアが担当しました。 OJT の流れとしては、初日に、プロダクトがどのように動いているのか、システム全体像を把握することから始まり、各自、ドキュメントに沿って、PC にローカル開発環境をセットアップしました。 その後は、他の先輩エンジニアと同様に、GitHub Issue で管理されている課題を解消することを日々の目標としてこなしてもらいました。ただし、単に Issue に書かれている課題をクリアしようとするのではなく、 そもそも、なぜそれをやるのか、Issue の背景や起票者の意図を十分に理解した上で、プロダクトのあるべき姿に導く ことを意識してもらいました。 Issue に書かれている内容の理解が不十分だったり、解決方針がうまく定まらない場合は随時、ミーティングの時間を設けて、Issue 起票者やトレーナーと認識合わせを行い、認識の相違から生まれるミスコミュニケーションを極力減らすよう、取り組みました。 技術的な質問に関しても、定期的に質問タイムを設けたり、複雑になりそうな実装や、つまずきポイントとなりそうな箇所に関しては、 画面共有を用いてレビュー を行い、疑問点に関してもその場で確認して、解消してもらいました。 緊急事態宣言期間中だったため、会社全体で原則、在宅勤務の体制となっており、対面でのコミュニケーションが希薄になりがちでしたが、朝会、夕会を含め、たとえ新卒から質問が無くても質問タイムでのミーティングは定期的に実施するなど、 できるだけ頻繁に顔合わせして、新卒本人の声と顔を確認する よう心がけました。 Issue へのアサインから始まって、実装 -> レビュー依頼 -> QA -> リリース -> Issue 起票者への報告まで、一連の開発フローを経験してもらい、チーム内での開発業務に慣れてもらうことができました。 フェーズ 4：最終報告 新卒研修最後のプログラムとして、メドレー役員陣に向けた最終報告会を実施しました。 最終報告会の目的としては、次の通りです。 学んだことの知識を深化させる 自らの得手・不得手を捉え、将来の成長計画を立てる 体系的に整理・文書化して他者へ伝えるスキルを向上させる 役員陣に向けてプレゼンすることで、本配属に向けた決意表明として区切りを付ける 役員陣への発表であることに加え、一人あたりの発表時間にも制限が設けられており、当日の緊張はかなりのものだったと思います。 前日に発表会場を下見して、リハーサルを入念に行うなど、当日の発表会を成功させるため、メドレーのエンジニアとしての自覚を持って、発表準備に取り組んでいました。 技術志向とプロダクト志向の両輪を目指すエンジニア募集中 メドレーの研修では、技術的な講義や実践だけで終わるのではなく、ビジネスパーソンとして必要な基礎も身につけ、なぜ開発するのかを追究し、プロダクトを通じた課題解決を実体験してもらうことを重視しています。 メドレーでは、医療ヘルスケア分野の課題解決に挑みたいエンジニアを募集しています。 新卒の学生に限らず、中途採用も行っているので、エンジニアの方で少しでも興味を持っていただけたら、是非、面談でお話ししましょう。 最後までお読みいただき、誠にありがとうございました。 P.S. 昨年、一昨年の新卒研修の様子はこちらより、それぞれご覧いただけます。 2020 年度新卒エンジニア研修について 2019 年度新卒エンジニア研修について 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。医療介護求人サイト「ジョブメドレー」の開発を担当しているエンジニアの山田です。 今年の新卒エンジニア研修において、メンターを担当しました。 メドレーでは 2019 年度から新卒採用を行なっており、今年 2021 年度は 5 名の新卒がエンジニアとして入社しました。 例年と同じく 4 月から 9 月にかけて、約 5 ヶ月間の新卒エンジニア研修を実施しましたので、その取り組みを、研修受講者である新卒からの声も交えてご紹介します。 新卒研修の概要 今年の新卒研修の最終ゴールは、「 メドレーのエンジニアとして、 Our Essentials (※) を体現し、顧客へ価値提供できるようになるための基礎を身につけ、経験を得ること 」として掲げました。 ※) メドレーの行動原則 メドレーの新卒エンジニア研修では、技術を身につけることだけではなく、ビジネスパーソンとしての基礎を身につけ、メドレーが大切にしている価値観を理解し、体現する意識をもって、顧客への価値提供について自分の言葉で話せるようになることまでを目指してもらいます。 研修は昨年同様、大きく分けて、4 つのフェーズに区切って行いました。 また、全研修期間を通じて、各新卒にはメンターを一人ずつ付けました。メンターは、一週間に 1~2 回のペースで新卒と 1on1 ミーティングを実施し、フィジカルとメンタルの両面を気遣い、個別にフォローを行いました。 新卒研修の内容 フェーズ 1：社会人&メドレー基礎研修 リスク研修 インサイダー取引防止研修 コンプライアンス研修 情報セキュリティ研修 ビジネス研修 ビジネスマナー研修 ビジネススキル研修 ビジネススタンス研修（外部研修） フェーズ 1 では、 成果を出し、価値を発揮するために必要なビジネスパーソンとしての基本的な仕事の型を身につけること をゴールとしました。 リスク研修では、メドレー社員として、社会人として、身の周りで起こりうるリスクについて考え、いかにそれらのリスクと向き合うかを講義形式で学んでもらいました。 ビジネス研修では、社会人としての最低限のマナーを学び、論理的思考力、コミュニケーション力など、エンジニア職に限らない課題解決力へつながるポータブルな知識を、座学とワークショップを通じて定着してもらうことを図りました。 また、社会人の基準で仕事と向き合い、適切な報連相によって周囲と協働していくことの重要性についても学んでもらいました。 新卒からの声 質の高い、多量のインプット・アウトプットができた 伝わるメールの書き方、名刺の渡し方など、社会人に必須のマナーやスキルを認識できた ワークを通じて、言葉では理解していても行動するとできないことを洗い出せた フェーズ 2：エンジニア基礎研修 開発基礎 1 メドレーエンジニアとして求めること 事業（ジョブメドレー ・ CLINICS ・介護のほんね）の概要説明 開発基礎研修（Ruby on Rails チュートリアル） 開発実践 （要件定義〜リリースまで） 開発基礎 2 技術書の輪読会 ドキュメンテーションスキル研修 プレゼンテーションスキル研修 中間レポート作成 中間報告会 フェーズ 2 では、新卒研修後に開発業務に入ってもらえるよう、 エンジニアとしての基礎を身につけること をゴールとしました。 メドレーエンジニアとして求めること 開発に関わるこのフェーズにおいても、要件定義を含む汎用的な技術的スキルは勿論のこと、メドレーエンジニアが共通して持つべき価値観などを共有するため、フェーズ 2 初日は「 メドレーエンジニアとして求めること 」と題して、エンジニアの執行役員 田中が講義を行いました。 講義では、「 エンジニア とは、 エンジニアの価値 とは、 プロエンジニア とはなんでしょうか？」という問いから始まり、講義の終わりにはもう一度同じ問いかけをして締めくくり、新卒がメドレーの求めるエンジニア像について自身の言葉で話せるように考えてもらいました。 メドレーが求めるエンジニア像については、CTO 平山の メドレー平山の中央突破: THE エンジニア にも書かれていますので、よろしければ、あわせてご覧ください。 さらに、メドレーが展開する各事業および関連するプロダクトの概要説明をプロダクトマネージャーが行い、メドレーで開発する意義をあらためて認識してもらいました。 開発基礎研修 2 日目より、 Ruby on Rails チュートリアル （以下、「Rails チュートリアル」）を教材とした、開発基礎研修に移りました。 メドレーのプロダクトは Rails で作られているものが多く、Web アプリケーションを開発するための基礎を身につけるためにも、Rails チュートリアルの内容を実施してもらいました。 単純に、Rails チュートリアルの内容に沿って、ダラダラと写経するのではなく、随時、学んだことは Confluence にまとめ、GitHub 上で Pull Request を作成する形で、ソースコードを共有してもらいました。 学んだことを自分の言葉に置き換えてアウトプットすることで反復学習を促し、Pull Request を作成してもらうことで GitHub の使い方に慣れてもらうことを図りました。 また、デイリーで朝会と夕会を実施しました。朝会は仕事のリズムを整えるための顔合わせ、夕会は新卒から質問・成果を共有してメンターがそれに対してフィードバックをする場としてそれぞれ実施しました。 研修前に既に Rails チュートリアルを一周していた新卒もいましたが、二周目を実施して新たな気付きを得たり、AWS を用いてクラウド上に環境構築し、作成した Web アプリケーションをデプロイするまでを実践してもらうなど、インフラに関しても理解を深めてもらうことができました。 新卒からの声 システムのパフォーマンスを上げるための工夫を知ることができた バグ発生〜原因特定〜修正、というデバッグのスピードが、研修序盤から飛躍的に上がった プロダクトで利用している AWS の各種サービスの概要を理解できたことに加え、サービス間の繋がりやネットワークの流れに関しても理解を深めることができた 開発実践 開発基礎研修にて Web アプリケーション開発の基礎を学んだ後は、「 メドレー/グループ会社で使う来訪者受付システム 」を開発題材として、開発実践研修を行いました。 開発業務全体の流れを把握することで、 チームで開発（課題解決）することを経験し、今後の仕事に役立たせること を目的としました。 本研修で達成すべきこととして掲げていたものは主に、次の通りです。 プロジェクト管理能力を身につけること 開発する対象を体系的に整理できる能力を養うこと システム設計に関する基礎的な物事を理解すること チーム開発を理解すること 品質を理解すること 既に決まりきった仕様書に沿って開発するのではなく、新卒自身が現状の問題把握や課題整理を行って、ユーザーへ価値提供するために何を作るべきかを考えることから始まり、リリース後の運用方法やランニングコストのことまで考え提案してもらいました。 開発実践研修は約 1 ヶ月の期間をかけて行いました。大まかな流れとしては、次の通りです。 要件定義（ヒアリング・現状把握・課題整理・要求分析・機能/非機能要件の洗い出し・ UI 草案） プロジェクト計画（役割分担・ WBS/ガントチャート作成） 設計（画面設計・機能設計・データモデリング・方式設計・インフラ設計） 開発（実装・コードレビュー） QA（テスト設計・テスト） 成果発表（成果物を関係者へプレゼン・リリース） 方式設計の一部として、開発に使用する言語などの選定も新卒自身が行いました。 今回作成した社員向け管理画面と来訪者向け画面はいずれも SPA（一部、PWA）のアーキテクチャを採用し、主なライブラリ/フレームワークに関して、フロントエンドは TypeScript , React , Next.js , Chakra UI , Ionic Framework 、バックエンドは Ruby on Rails（API モード）をそれぞれ利用することとなりました。 選定理由としては主に、次の通りです。 TypeScript, React（両画面共通） ロジックからテンプレートまでの全てのコードを静的型付けで書くことができ、堅牢性に優れているため Next.js, Chakra UI（社員向け管理画面） ゼロコンフィグでビルドやレンダリングを最適化できるため アクセシビリティに優れたリッチな UI を素早く構築できるため Ionic Framework（来訪者向け画面） iPad 上で、ネイティブアプリのような UI/UX を提供するため Ruby on Rails API モード フロントエンドとバックエンドを分離して疎結合にするため 短期間で構築するため 社内でもよく使われておりメンテナンスしやすいため インフラは AWS を採用し、EC2, S3, RDS, CloudFront, Route53, CloudWatch などのサービスを利用しました。 結果的に、本研修プログラムの成果物としてリリースされたシステムは「 Medley Entrance 」という名前で、社内ツールとして現在、毎日稼働しており、ユーザーとしてメドレー/グループ社員だけではなく、来訪者の方々にも使っていただいています。 Medley Entrance（上：社員向け管理画面、下：来訪者向け画面） チームで課題解決に臨み、価値提供までの実績を残せたことは自信につながり、開発実践研修のやりがいとして、感じてもらえたのではないでしょうか。 要件定義などの期間中、想定よりもスムーズに進められなかった時も他責にせず、各々がリーダーシップを発揮し、建設的に進めていく新卒の様子をメンターの一人として傍で見させてもらいました。 この 1 ヶ月間の開発実践研修を通じて、技術力はさることながら、課題解決に対する十分な熱意と主体性を新卒から感じられ、とても頼もしい印象として残りました。 新卒からの声 開発の中での方針を意識して設計/実装することができた(シンプルにする) QA とはそもそも何かというリサーチから入り、有識者の考え方を軸に方針を決めてから始められた 各々が最適なパフォーマンスを発揮できる環境づくりを意識して、高速な意思決定が可能な体制を整えることができた 要件が決まりきっていない中で設計するのは難しかった 開発タスクが集中していた時に、プロジェクト全体の現状を把握できていなかった 文章を作るスキルが足りていない 技術書の輪読会 フェーズ 2 の開発基礎 2 の輪読会では、 『Web を支える技術 -HTTP、URI、HTML、そして REST』 を題材書籍として、7 日間に渡って毎日、次の手順で実施しました。 参加者が同じパートをあらかじめ読んでおき、書籍から学んだこと、ネットなどで調べても解消しきれなかった疑問点などをまとめる その内容をもとに、夕方のミーティング時において、各自が発表してディスカッションを行う ディスカッションした内容は議事録にまとめる 輪読会は他者からの学びを共有してもらうことで、自分にはなかった視点・気付きを獲得し、その書籍への理解をより深められる効果があります。 本研修プログラムにおける輪読会の目的としては、 Web サービスを開発していく上で必要となる知識へ触れることにより、今後獲得していくべき知識のベースラインを理解すること でしたが、輪読会ならではのメリット・楽しさを新卒に実感してもらえたことも、副次的な効果としてあったと思います。 新卒からの声 Web の基本的な知識を「なぜ登場したのか」を理解しながら網羅的に学ぶことができた 文書でまとめた後に、口で説明することが学んだ内容の定着に良いと感じた これまでなんとなく実装していたことの仕組みを学ぶことで、知識として定着することができた 中間報告会 フェーズ 2：エンジニア基礎研修最後の研修プログラムである中間報告会に向けて、ドキュメンテーションスキル研修、プレゼンテーションスキル研修を実施しました。 上記スキルが必要となる背景は、次の通りです。 エンジニアリングを通じた課題解決とはプログラムを書くだけでは解決しない場面もある 背景、目的を正しくステークホルダーへ共有しながらチームとして取り組んでいくことになる 伝えたいことを文章として整理し、他者へ分かりやすく伝えていくことが求められる また、メドレーの行動原則 Our Essentials を構成する要素として、「ドキュメントドリブン」「全てを明確に」という項目が含まれており、これらを実現するためにも、とても重要なスキルとしてメドレーは考えています。 新卒研修が終わった後も、エンジニアとして技術的なスキルを身につける機会は日常的に多くありますが、上記のようなスキルをまとめて習得する機会は少ないため、このような研修を社会人のはじめから受けておくことで、その後の伸びしろが違ってくるのではないかと思います。 研修が終わった後は、各自で報告会用の資料を作成し、研修講師からの添削を受けました。 中間報告会は各部署の開発マネージャーを発表相手として、当日は程よい緊張感をもって、良い雰囲気で報告会を終えられました。 フェーズ 3：事業部 OJT 事業部研修 取締役豊田からの講義 CLINICS 事業部研修 ジョブメドレー事業部研修 開発 OJT システム全体像説明 環境構築 各プロダクトの開発チームでの OJT フェーズ 3 では、 顧客の課題と、顧客への価値提供のための各チームの連携を体感し、メドレーの顧客提供価値を自分の言葉で話せるようになること をゴールとしました。 フェーズ 3 のはじめに、取締役豊田による日本の医療の課題とメドレーの取り組みに関する講義を受講してもらいました。 持続可能な医療体制を構築していくためにメドレーが成すべきことなどの話を聞いた後に、新卒からの質問の受け答えによって理解を深め、メドレーの社会的意義をあらためて認識してもらい、エンジニアとしてだけではなく、 メドレー社員としての自覚 を強めてもらいました。 事業部研修 開発 OJT で手を動かす前に、自分たちが何のために開発するのかを具体的にイメージできるよう、次のように、各現場に参加してもらいました。 見込顧客への架電業務見学 商談前の社内ミーティング参加 商談現場同席 定例会議参加 事業部のスタッフが、顧客の課題に対して、どのような対応をしていて、どのようにプロダクトを説明しているのか、事業部の各チームが、どのように連携して最終的に顧客に価値を届けるのかの全体観を知ってもらうことを狙いとしていました。 開発チームのエンジニアは業務上、プロダクトのエンドユーザーである顧客の声などを商談のタイミングから聞ける機会はなかなか無いので、研修を通じて話を聞けたことは、今後の開発モチベーションにも影響する良い機会だったと思います。 新卒からの声 ユーザー、顧客、事業部が抱える課題を確認できたことで、開発以外にも目を向けるきっかけになり良かった 各部署が KPI として定めている数字を知ることができ、開発に降りてきている施策の影響箇所がどの部分かを理解できた上で、開発に取り組むことができるようになった 各部署のミーディングに参加することで、各部署がどのような考えで何を目指しているのかを理解でき、メドレー全体として目指している方向性が掴めた 開発 OJT 事業部研修に続く開発 OJT では、 ジョブメドレー 、 CLINICS 、 介護のほんね の開発チームに分かれて、研修を実施しました。 OJT 配属先では、メンターとは別に、トレーナーを付けて業務の進め方などをサポートしました。トレーナーは配属先の先輩エンジニアが担当しました。 OJT の流れとしては、初日に、プロダクトがどのように動いているのか、システム全体像を把握することから始まり、各自、ドキュメントに沿って、PC にローカル開発環境をセットアップしました。 その後は、他の先輩エンジニアと同様に、GitHub Issue で管理されている課題を解消することを日々の目標としてこなしてもらいました。ただし、単に Issue に書かれている課題をクリアしようとするのではなく、 そもそも、なぜそれをやるのか、Issue の背景や起票者の意図を十分に理解した上で、プロダクトのあるべき姿に導く ことを意識してもらいました。 Issue に書かれている内容の理解が不十分だったり、解決方針がうまく定まらない場合は随時、ミーティングの時間を設けて、Issue 起票者やトレーナーと認識合わせを行い、認識の相違から生まれるミスコミュニケーションを極力減らすよう、取り組みました。 技術的な質問に関しても、定期的に質問タイムを設けたり、複雑になりそうな実装や、つまずきポイントとなりそうな箇所に関しては、 画面共有を用いてレビュー を行い、疑問点に関してもその場で確認して、解消してもらいました。 緊急事態宣言期間中だったため、会社全体で原則、在宅勤務の体制となっており、対面でのコミュニケーションが希薄になりがちでしたが、朝会、夕会を含め、たとえ新卒から質問が無くても質問タイムでのミーティングは定期的に実施するなど、 できるだけ頻繁に顔合わせして、新卒本人の声と顔を確認する よう心がけました。 Issue へのアサインから始まって、実装 -> レビュー依頼 -> QA -> リリース -> Issue 起票者への報告まで、一連の開発フローを経験してもらい、チーム内での開発業務に慣れてもらうことができました。 フェーズ 4：最終報告 新卒研修最後のプログラムとして、メドレー役員陣に向けた最終報告会を実施しました。 最終報告会の目的としては、次の通りです。 学んだことの知識を深化させる 自らの得手・不得手を捉え、将来の成長計画を立てる 体系的に整理・文書化して他者へ伝えるスキルを向上させる 役員陣に向けてプレゼンすることで、本配属に向けた決意表明として区切りを付ける 役員陣への発表であることに加え、一人あたりの発表時間にも制限が設けられており、当日の緊張はかなりのものだったと思います。 前日に発表会場を下見して、リハーサルを入念に行うなど、当日の発表会を成功させるため、メドレーのエンジニアとしての自覚を持って、発表準備に取り組んでいました。 技術志向とプロダクト志向の両輪を目指すエンジニア募集中 メドレーの研修では、技術的な講義や実践だけで終わるのではなく、ビジネスパーソンとして必要な基礎も身につけ、なぜ開発するのかを追究し、プロダクトを通じた課題解決を実体験してもらうことを重視しています。 メドレーでは、医療ヘルスケア分野の課題解決に挑みたいエンジニアを募集しています。 新卒の学生に限らず、中途採用も行っているので、エンジニアの方で少しでも興味を持っていただけたら、是非、面談でお話ししましょう。 最後までお読みいただき、誠にありがとうございました。 P.S. 昨年、一昨年の新卒研修の様子はこちらより、それぞれご覧いただけます。 2020 年度新卒エンジニア研修について 2019 年度新卒エンジニア研修について https://www.medley.jp/jobs/

こんにちは。医療介護求人サイト「ジョブメドレー」の開発を担当しているエンジニアの山田です。 今年の新卒エンジニア研修において、メンターを担当しました。 メドレーでは 2019 年度から新卒採用を行なっており、今年 2021 年度は 5 名の新卒がエンジニアとして入社しました。 例年と同じく 4 月から 9 月にかけて、約 5 ヶ月間の新卒エンジニア研修を実施しましたので、その取り組みを、研修受講者である新卒からの声も交えてご紹介します。 新卒研修の概要 今年の新卒研修の最終ゴールは、「 メドレーのエンジニアとして、 Our Essentials (※) を体現し、顧客へ価値提供できるようになるための基礎を身につけ、経験を得ること 」として掲げました。 ※) メドレーの行動原則 メドレーの新卒エンジニア研修では、技術を身につけることだけではなく、ビジネスパーソンとしての基礎を身につけ、メドレーが大切にしている価値観を理解し、体現する意識をもって、顧客への価値提供について自分の言葉で話せるようになることまでを目指してもらいます。 研修は昨年同様、大きく分けて、4 つのフェーズに区切って行いました。 また、全研修期間を通じて、各新卒にはメンターを一人ずつ付けました。メンターは、一週間に 1~2 回のペースで新卒と 1on1 ミーティングを実施し、フィジカルとメンタルの両面を気遣い、個別にフォローを行いました。 新卒研修の内容 フェーズ 1：社会人&メドレー基礎研修 リスク研修 インサイダー取引防止研修 コンプライアンス研修 情報セキュリティ研修 ビジネス研修 ビジネスマナー研修 ビジネススキル研修 ビジネススタンス研修（外部研修） フェーズ 1 では、 成果を出し、価値を発揮するために必要なビジネスパーソンとしての基本的な仕事の型を身につけること をゴールとしました。 リスク研修では、メドレー社員として、社会人として、身の周りで起こりうるリスクについて考え、いかにそれらのリスクと向き合うかを講義形式で学んでもらいました。 ビジネス研修では、社会人としての最低限のマナーを学び、論理的思考力、コミュニケーション力など、エンジニア職に限らない課題解決力へつながるポータブルな知識を、座学とワークショップを通じて定着してもらうことを図りました。 また、社会人の基準で仕事と向き合い、適切な報連相によって周囲と協働していくことの重要性についても学んでもらいました。 新卒からの声 質の高い、多量のインプット・アウトプットができた 伝わるメールの書き方、名刺の渡し方など、社会人に必須のマナーやスキルを認識できた ワークを通じて、言葉では理解していても行動するとできないことを洗い出せた フェーズ 2：エンジニア基礎研修 開発基礎 1 メドレーエンジニアとして求めること 事業（ジョブメドレー ・ CLINICS ・介護のほんね）の概要説明 開発基礎研修（Ruby on Rails チュートリアル） 開発実践 （要件定義〜リリースまで） 開発基礎 2 技術書の輪読会 ドキュメンテーションスキル研修 プレゼンテーションスキル研修 中間レポート作成 中間報告会 フェーズ 2 では、新卒研修後に開発業務に入ってもらえるよう、 エンジニアとしての基礎を身につけること をゴールとしました。 メドレーエンジニアとして求めること 開発に関わるこのフェーズにおいても、要件定義を含む汎用的な技術的スキルは勿論のこと、メドレーエンジニアが共通して持つべき価値観などを共有するため、フェーズ 2 初日は「 メドレーエンジニアとして求めること 」と題して、エンジニアの執行役員 田中が講義を行いました。 講義では、「 エンジニア とは、 エンジニアの価値 とは、 プロエンジニア とはなんでしょうか？」という問いから始まり、講義の終わりにはもう一度同じ問いかけをして締めくくり、新卒がメドレーの求めるエンジニア像について自身の言葉で話せるように考えてもらいました。 メドレーが求めるエンジニア像については、CTO 平山の メドレー平山の中央突破: THE エンジニア にも書かれていますので、よろしければ、あわせてご覧ください。 さらに、メドレーが展開する各事業および関連するプロダクトの概要説明をプロダクトマネージャーが行い、メドレーで開発する意義をあらためて認識してもらいました。 開発基礎研修 2 日目より、 Ruby on Rails チュートリアル （以下、「Rails チュートリアル」）を教材とした、開発基礎研修に移りました。 メドレーのプロダクトは Rails で作られているものが多く、Web アプリケーションを開発するための基礎を身につけるためにも、Rails チュートリアルの内容を実施してもらいました。 単純に、Rails チュートリアルの内容に沿って、ダラダラと写経するのではなく、随時、学んだことは Confluence にまとめ、GitHub 上で Pull Request を作成する形で、ソースコードを共有してもらいました。 学んだことを自分の言葉に置き換えてアウトプットすることで反復学習を促し、Pull Request を作成してもらうことで GitHub の使い方に慣れてもらうことを図りました。 また、デイリーで朝会と夕会を実施しました。朝会は仕事のリズムを整えるための顔合わせ、夕会は新卒から質問・成果を共有してメンターがそれに対してフィードバックをする場としてそれぞれ実施しました。 研修前に既に Rails チュートリアルを一周していた新卒もいましたが、二周目を実施して新たな気付きを得たり、AWS を用いてクラウド上に環境構築し、作成した Web アプリケーションをデプロイするまでを実践してもらうなど、インフラに関しても理解を深めてもらうことができました。 新卒からの声 システムのパフォーマンスを上げるための工夫を知ることができた バグ発生〜原因特定〜修正、というデバッグのスピードが、研修序盤から飛躍的に上がった プロダクトで利用している AWS の各種サービスの概要を理解できたことに加え、サービス間の繋がりやネットワークの流れに関しても理解を深めることができた 開発実践 開発基礎研修にて Web アプリケーション開発の基礎を学んだ後は、「 メドレー/グループ会社で使う来訪者受付システム 」を開発題材として、開発実践研修を行いました。 開発業務全体の流れを把握することで、 チームで開発（課題解決）することを経験し、今後の仕事に役立たせること を目的としました。 本研修で達成すべきこととして掲げていたものは主に、次の通りです。 プロジェクト管理能力を身につけること 開発する対象を体系的に整理できる能力を養うこと システム設計に関する基礎的な物事を理解すること チーム開発を理解すること 品質を理解すること 既に決まりきった仕様書に沿って開発するのではなく、新卒自身が現状の問題把握や課題整理を行って、ユーザーへ価値提供するために何を作るべきかを考えることから始まり、リリース後の運用方法やランニングコストのことまで考え提案してもらいました。 開発実践研修は約 1 ヶ月の期間をかけて行いました。大まかな流れとしては、次の通りです。 要件定義（ヒアリング・現状把握・課題整理・要求分析・機能/非機能要件の洗い出し・ UI 草案） プロジェクト計画（役割分担・ WBS/ガントチャート作成） 設計（画面設計・機能設計・データモデリング・方式設計・インフラ設計） 開発（実装・コードレビュー） QA（テスト設計・テスト） 成果発表（成果物を関係者へプレゼン・リリース） 方式設計の一部として、開発に使用する言語などの選定も新卒自身が行いました。 今回作成した社員向け管理画面と来訪者向け画面はいずれも SPA（一部、PWA）のアーキテクチャを採用し、主なライブラリ/フレームワークに関して、フロントエンドは TypeScript , React , Next.js , Chakra UI , Ionic Framework 、バックエンドは Ruby on Rails（API モード）をそれぞれ利用することとなりました。 選定理由としては主に、次の通りです。 TypeScript, React（両画面共通） ロジックからテンプレートまでの全てのコードを静的型付けで書くことができ、堅牢性に優れているため Next.js, Chakra UI（社員向け管理画面） ゼロコンフィグでビルドやレンダリングを最適化できるため アクセシビリティに優れたリッチな UI を素早く構築できるため Ionic Framework（来訪者向け画面） iPad 上で、ネイティブアプリのような UI/UX を提供するため Ruby on Rails API モード フロントエンドとバックエンドを分離して疎結合にするため 短期間で構築するため 社内でもよく使われておりメンテナンスしやすいため インフラは AWS を採用し、EC2, S3, RDS, CloudFront, Route53, CloudWatch などのサービスを利用しました。 結果的に、本研修プログラムの成果物としてリリースされたシステムは「 Medley Entrance 」という名前で、社内ツールとして現在、毎日稼働しており、ユーザーとしてメドレー/グループ社員だけではなく、来訪者の方々にも使っていただいています。 Medley Entrance（上：社員向け管理画面、下：来訪者向け画面） チームで課題解決に臨み、価値提供までの実績を残せたことは自信につながり、開発実践研修のやりがいとして、感じてもらえたのではないでしょうか。 要件定義などの期間中、想定よりもスムーズに進められなかった時も他責にせず、各々がリーダーシップを発揮し、建設的に進めていく新卒の様子をメンターの一人として傍で見させてもらいました。 この 1 ヶ月間の開発実践研修を通じて、技術力はさることながら、課題解決に対する十分な熱意と主体性を新卒から感じられ、とても頼もしい印象として残りました。 新卒からの声 開発の中での方針を意識して設計/実装することができた(シンプルにする) QA とはそもそも何かというリサーチから入り、有識者の考え方を軸に方針を決めてから始められた 各々が最適なパフォーマンスを発揮できる環境づくりを意識して、高速な意思決定が可能な体制を整えることができた 要件が決まりきっていない中で設計するのは難しかった 開発タスクが集中していた時に、プロジェクト全体の現状を把握できていなかった 文章を作るスキルが足りていない 技術書の輪読会 フェーズ 2 の開発基礎 2 の輪読会では、 『Web を支える技術 -HTTP、URI、HTML、そして REST』 を題材書籍として、7 日間に渡って毎日、次の手順で実施しました。 参加者が同じパートをあらかじめ読んでおき、書籍から学んだこと、ネットなどで調べても解消しきれなかった疑問点などをまとめる その内容をもとに、夕方のミーティング時において、各自が発表してディスカッションを行う ディスカッションした内容は議事録にまとめる 輪読会は他者からの学びを共有してもらうことで、自分にはなかった視点・気付きを獲得し、その書籍への理解をより深められる効果があります。 本研修プログラムにおける輪読会の目的としては、 Web サービスを開発していく上で必要となる知識へ触れることにより、今後獲得していくべき知識のベースラインを理解すること でしたが、輪読会ならではのメリット・楽しさを新卒に実感してもらえたことも、副次的な効果としてあったと思います。 新卒からの声 Web の基本的な知識を「なぜ登場したのか」を理解しながら網羅的に学ぶことができた 文書でまとめた後に、口で説明することが学んだ内容の定着に良いと感じた これまでなんとなく実装していたことの仕組みを学ぶことで、知識として定着することができた 中間報告会 フェーズ 2：エンジニア基礎研修最後の研修プログラムである中間報告会に向けて、ドキュメンテーションスキル研修、プレゼンテーションスキル研修を実施しました。 上記スキルが必要となる背景は、次の通りです。 エンジニアリングを通じた課題解決とはプログラムを書くだけでは解決しない場面もある 背景、目的を正しくステークホルダーへ共有しながらチームとして取り組んでいくことになる 伝えたいことを文章として整理し、他者へ分かりやすく伝えていくことが求められる また、メドレーの行動原則 Our Essentials を構成する要素として、「ドキュメントドリブン」「全てを明確に」という項目が含まれており、これらを実現するためにも、とても重要なスキルとしてメドレーは考えています。 新卒研修が終わった後も、エンジニアとして技術的なスキルを身につける機会は日常的に多くありますが、上記のようなスキルをまとめて習得する機会は少ないため、このような研修を社会人のはじめから受けておくことで、その後の伸びしろが違ってくるのではないかと思います。 研修が終わった後は、各自で報告会用の資料を作成し、研修講師からの添削を受けました。 中間報告会は各部署の開発マネージャーを発表相手として、当日は程よい緊張感をもって、良い雰囲気で報告会を終えられました。 フェーズ 3：事業部 OJT 事業部研修 取締役豊田からの講義 CLINICS 事業部研修 ジョブメドレー事業部研修 開発 OJT システム全体像説明 環境構築 各プロダクトの開発チームでの OJT フェーズ 3 では、 顧客の課題と、顧客への価値提供のための各チームの連携を体感し、メドレーの顧客提供価値を自分の言葉で話せるようになること をゴールとしました。 フェーズ 3 のはじめに、取締役豊田による日本の医療の課題とメドレーの取り組みに関する講義を受講してもらいました。 持続可能な医療体制を構築していくためにメドレーが成すべきことなどの話を聞いた後に、新卒からの質問の受け答えによって理解を深め、メドレーの社会的意義をあらためて認識してもらい、エンジニアとしてだけではなく、 メドレー社員としての自覚 を強めてもらいました。 事業部研修 開発 OJT で手を動かす前に、自分たちが何のために開発するのかを具体的にイメージできるよう、次のように、各現場に参加してもらいました。 見込顧客への架電業務見学 商談前の社内ミーティング参加 商談現場同席 定例会議参加 事業部のスタッフが、顧客の課題に対して、どのような対応をしていて、どのようにプロダクトを説明しているのか、事業部の各チームが、どのように連携して最終的に顧客に価値を届けるのかの全体観を知ってもらうことを狙いとしていました。 開発チームのエンジニアは業務上、プロダクトのエンドユーザーである顧客の声などを商談のタイミングから聞ける機会はなかなか無いので、研修を通じて話を聞けたことは、今後の開発モチベーションにも影響する良い機会だったと思います。 新卒からの声 ユーザー、顧客、事業部が抱える課題を確認できたことで、開発以外にも目を向けるきっかけになり良かった 各部署が KPI として定めている数字を知ることができ、開発に降りてきている施策の影響箇所がどの部分かを理解できた上で、開発に取り組むことができるようになった 各部署のミーディングに参加することで、各部署がどのような考えで何を目指しているのかを理解でき、メドレー全体として目指している方向性が掴めた 開発 OJT 事業部研修に続く開発 OJT では、 ジョブメドレー 、 CLINICS 、 介護のほんね の開発チームに分かれて、研修を実施しました。 OJT 配属先では、メンターとは別に、トレーナーを付けて業務の進め方などをサポートしました。トレーナーは配属先の先輩エンジニアが担当しました。 OJT の流れとしては、初日に、プロダクトがどのように動いているのか、システム全体像を把握することから始まり、各自、ドキュメントに沿って、PC にローカル開発環境をセットアップしました。 その後は、他の先輩エンジニアと同様に、GitHub Issue で管理されている課題を解消することを日々の目標としてこなしてもらいました。ただし、単に Issue に書かれている課題をクリアしようとするのではなく、 そもそも、なぜそれをやるのか、Issue の背景や起票者の意図を十分に理解した上で、プロダクトのあるべき姿に導く ことを意識してもらいました。 Issue に書かれている内容の理解が不十分だったり、解決方針がうまく定まらない場合は随時、ミーティングの時間を設けて、Issue 起票者やトレーナーと認識合わせを行い、認識の相違から生まれるミスコミュニケーションを極力減らすよう、取り組みました。 技術的な質問に関しても、定期的に質問タイムを設けたり、複雑になりそうな実装や、つまずきポイントとなりそうな箇所に関しては、 画面共有を用いてレビュー を行い、疑問点に関してもその場で確認して、解消してもらいました。 緊急事態宣言期間中だったため、会社全体で原則、在宅勤務の体制となっており、対面でのコミュニケーションが希薄になりがちでしたが、朝会、夕会を含め、たとえ新卒から質問が無くても質問タイムでのミーティングは定期的に実施するなど、 できるだけ頻繁に顔合わせして、新卒本人の声と顔を確認する よう心がけました。 Issue へのアサインから始まって、実装 -> レビュー依頼 -> QA -> リリース -> Issue 起票者への報告まで、一連の開発フローを経験してもらい、チーム内での開発業務に慣れてもらうことができました。 フェーズ 4：最終報告 新卒研修最後のプログラムとして、メドレー役員陣に向けた最終報告会を実施しました。 最終報告会の目的としては、次の通りです。 学んだことの知識を深化させる 自らの得手・不得手を捉え、将来の成長計画を立てる 体系的に整理・文書化して他者へ伝えるスキルを向上させる 役員陣に向けてプレゼンすることで、本配属に向けた決意表明として区切りを付ける 役員陣への発表であることに加え、一人あたりの発表時間にも制限が設けられており、当日の緊張はかなりのものだったと思います。 前日に発表会場を下見して、リハーサルを入念に行うなど、当日の発表会を成功させるため、メドレーのエンジニアとしての自覚を持って、発表準備に取り組んでいました。 技術志向とプロダクト志向の両輪を目指すエンジニア募集中 メドレーの研修では、技術的な講義や実践だけで終わるのではなく、ビジネスパーソンとして必要な基礎も身につけ、なぜ開発するのかを追究し、プロダクトを通じた課題解決を実体験してもらうことを重視しています。 メドレーでは、医療ヘルスケア分野の課題解決に挑みたいエンジニアを募集しています。 新卒の学生に限らず、中途採用も行っているので、エンジニアの方で少しでも興味を持っていただけたら、是非、面談でお話ししましょう。 最後までお読みいただき、誠にありがとうございました。 P.S. 昨年、一昨年の新卒研修の様子はこちらより、それぞれご覧いただけます。 2020 年度新卒エンジニア研修について 2019 年度新卒エンジニア研修について 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。医療介護求人サイト「ジョブメドレー」の開発を担当しているエンジニアの山田です。 今年の新卒エンジニア研修において、メンターを担当しました。 メドレーでは 2019 年度から新卒採用を行なっており、今年 2021 年度は 5 名の新卒がエンジニアとして入社しました。 例年と同じく 4 月から 9 月にかけて、約 5 ヶ月間の新卒エンジニア研修を実施しましたので、その取り組みを、研修受講者である新卒からの声も交えてご紹介します。 新卒研修の概要 今年の新卒研修の最終ゴールは、「 メドレーのエンジニアとして、 Our Essentials (※) を体現し、顧客へ価値提供できるようになるための基礎を身につけ、経験を得ること 」として掲げました。 ※) メドレーの行動原則 メドレーの新卒エンジニア研修では、技術を身につけることだけではなく、ビジネスパーソンとしての基礎を身につけ、メドレーが大切にしている価値観を理解し、体現する意識をもって、顧客への価値提供について自分の言葉で話せるようになることまでを目指してもらいます。 研修は昨年同様、大きく分けて、4 つのフェーズに区切って行いました。 また、全研修期間を通じて、各新卒にはメンターを一人ずつ付けました。メンターは、一週間に 1~2 回のペースで新卒と 1on1 ミーティングを実施し、フィジカルとメンタルの両面を気遣い、個別にフォローを行いました。 新卒研修の内容 フェーズ 1：社会人&メドレー基礎研修 リスク研修 インサイダー取引防止研修 コンプライアンス研修 情報セキュリティ研修 ビジネス研修 ビジネスマナー研修 ビジネススキル研修 ビジネススタンス研修（外部研修） フェーズ 1 では、 成果を出し、価値を発揮するために必要なビジネスパーソンとしての基本的な仕事の型を身につけること をゴールとしました。 リスク研修では、メドレー社員として、社会人として、身の周りで起こりうるリスクについて考え、いかにそれらのリスクと向き合うかを講義形式で学んでもらいました。 ビジネス研修では、社会人としての最低限のマナーを学び、論理的思考力、コミュニケーション力など、エンジニア職に限らない課題解決力へつながるポータブルな知識を、座学とワークショップを通じて定着してもらうことを図りました。 また、社会人の基準で仕事と向き合い、適切な報連相によって周囲と協働していくことの重要性についても学んでもらいました。 新卒からの声 質の高い、多量のインプット・アウトプットができた 伝わるメールの書き方、名刺の渡し方など、社会人に必須のマナーやスキルを認識できた ワークを通じて、言葉では理解していても行動するとできないことを洗い出せた フェーズ 2：エンジニア基礎研修 開発基礎 1 メドレーエンジニアとして求めること 事業（ジョブメドレー ・ CLINICS ・介護のほんね）の概要説明 開発基礎研修（Ruby on Rails チュートリアル） 開発実践 （要件定義〜リリースまで） 開発基礎 2 技術書の輪読会 ドキュメンテーションスキル研修 プレゼンテーションスキル研修 中間レポート作成 中間報告会 フェーズ 2 では、新卒研修後に開発業務に入ってもらえるよう、 エンジニアとしての基礎を身につけること をゴールとしました。 メドレーエンジニアとして求めること 開発に関わるこのフェーズにおいても、要件定義を含む汎用的な技術的スキルは勿論のこと、メドレーエンジニアが共通して持つべき価値観などを共有するため、フェーズ 2 初日は「 メドレーエンジニアとして求めること 」と題して、エンジニアの執行役員 田中が講義を行いました。 講義では、「 エンジニア とは、 エンジニアの価値 とは、 プロエンジニア とはなんでしょうか？」という問いから始まり、講義の終わりにはもう一度同じ問いかけをして締めくくり、新卒がメドレーの求めるエンジニア像について自身の言葉で話せるように考えてもらいました。 メドレーが求めるエンジニア像については、CTO 平山の メドレー平山の中央突破: THE エンジニア にも書かれていますので、よろしければ、あわせてご覧ください。 さらに、メドレーが展開する各事業および関連するプロダクトの概要説明をプロダクトマネージャーが行い、メドレーで開発する意義をあらためて認識してもらいました。 開発基礎研修 2 日目より、 Ruby on Rails チュートリアル （以下、「Rails チュートリアル」）を教材とした、開発基礎研修に移りました。 メドレーのプロダクトは Rails で作られているものが多く、Web アプリケーションを開発するための基礎を身につけるためにも、Rails チュートリアルの内容を実施してもらいました。 単純に、Rails チュートリアルの内容に沿って、ダラダラと写経するのではなく、随時、学んだことは Confluence にまとめ、GitHub 上で Pull Request を作成する形で、ソースコードを共有してもらいました。 学んだことを自分の言葉に置き換えてアウトプットすることで反復学習を促し、Pull Request を作成してもらうことで GitHub の使い方に慣れてもらうことを図りました。 また、デイリーで朝会と夕会を実施しました。朝会は仕事のリズムを整えるための顔合わせ、夕会は新卒から質問・成果を共有してメンターがそれに対してフィードバックをする場としてそれぞれ実施しました。 研修前に既に Rails チュートリアルを一周していた新卒もいましたが、二周目を実施して新たな気付きを得たり、AWS を用いてクラウド上に環境構築し、作成した Web アプリケーションをデプロイするまでを実践してもらうなど、インフラに関しても理解を深めてもらうことができました。 新卒からの声 システムのパフォーマンスを上げるための工夫を知ることができた バグ発生〜原因特定〜修正、というデバッグのスピードが、研修序盤から飛躍的に上がった プロダクトで利用している AWS の各種サービスの概要を理解できたことに加え、サービス間の繋がりやネットワークの流れに関しても理解を深めることができた 開発実践 開発基礎研修にて Web アプリケーション開発の基礎を学んだ後は、「 メドレー/グループ会社で使う来訪者受付システム 」を開発題材として、開発実践研修を行いました。 開発業務全体の流れを把握することで、 チームで開発（課題解決）することを経験し、今後の仕事に役立たせること を目的としました。 本研修で達成すべきこととして掲げていたものは主に、次の通りです。 プロジェクト管理能力を身につけること 開発する対象を体系的に整理できる能力を養うこと システム設計に関する基礎的な物事を理解すること チーム開発を理解すること 品質を理解すること 既に決まりきった仕様書に沿って開発するのではなく、新卒自身が現状の問題把握や課題整理を行って、ユーザーへ価値提供するために何を作るべきかを考えることから始まり、リリース後の運用方法やランニングコストのことまで考え提案してもらいました。 開発実践研修は約 1 ヶ月の期間をかけて行いました。大まかな流れとしては、次の通りです。 要件定義（ヒアリング・現状把握・課題整理・要求分析・機能/非機能要件の洗い出し・ UI 草案） プロジェクト計画（役割分担・ WBS/ガントチャート作成） 設計（画面設計・機能設計・データモデリング・方式設計・インフラ設計） 開発（実装・コードレビュー） QA（テスト設計・テスト） 成果発表（成果物を関係者へプレゼン・リリース） 方式設計の一部として、開発に使用する言語などの選定も新卒自身が行いました。 今回作成した社員向け管理画面と来訪者向け画面はいずれも SPA（一部、PWA）のアーキテクチャを採用し、主なライブラリ/フレームワークに関して、フロントエンドは TypeScript , React , Next.js , Chakra UI , Ionic Framework 、バックエンドは Ruby on Rails（API モード）をそれぞれ利用することとなりました。 選定理由としては主に、次の通りです。 TypeScript, React（両画面共通） ロジックからテンプレートまでの全てのコードを静的型付けで書くことができ、堅牢性に優れているため Next.js, Chakra UI（社員向け管理画面） ゼロコンフィグでビルドやレンダリングを最適化できるため アクセシビリティに優れたリッチな UI を素早く構築できるため Ionic Framework（来訪者向け画面） iPad 上で、ネイティブアプリのような UI/UX を提供するため Ruby on Rails API モード フロントエンドとバックエンドを分離して疎結合にするため 短期間で構築するため 社内でもよく使われておりメンテナンスしやすいため インフラは AWS を採用し、EC2, S3, RDS, CloudFront, Route53, CloudWatch などのサービスを利用しました。 結果的に、本研修プログラムの成果物としてリリースされたシステムは「 Medley Entrance 」という名前で、社内ツールとして現在、毎日稼働しており、ユーザーとしてメドレー/グループ社員だけではなく、来訪者の方々にも使っていただいています。 Medley Entrance（上：社員向け管理画面、下：来訪者向け画面） チームで課題解決に臨み、価値提供までの実績を残せたことは自信につながり、開発実践研修のやりがいとして、感じてもらえたのではないでしょうか。 要件定義などの期間中、想定よりもスムーズに進められなかった時も他責にせず、各々がリーダーシップを発揮し、建設的に進めていく新卒の様子をメンターの一人として傍で見させてもらいました。 この 1 ヶ月間の開発実践研修を通じて、技術力はさることながら、課題解決に対する十分な熱意と主体性を新卒から感じられ、とても頼もしい印象として残りました。 新卒からの声 開発の中での方針を意識して設計/実装することができた(シンプルにする) QA とはそもそも何かというリサーチから入り、有識者の考え方を軸に方針を決めてから始められた 各々が最適なパフォーマンスを発揮できる環境づくりを意識して、高速な意思決定が可能な体制を整えることができた 要件が決まりきっていない中で設計するのは難しかった 開発タスクが集中していた時に、プロジェクト全体の現状を把握できていなかった 文章を作るスキルが足りていない 技術書の輪読会 フェーズ 2 の開発基礎 2 の輪読会では、 『Web を支える技術 -HTTP、URI、HTML、そして REST』 を題材書籍として、7 日間に渡って毎日、次の手順で実施しました。 参加者が同じパートをあらかじめ読んでおき、書籍から学んだこと、ネットなどで調べても解消しきれなかった疑問点などをまとめる その内容をもとに、夕方のミーティング時において、各自が発表してディスカッションを行う ディスカッションした内容は議事録にまとめる 輪読会は他者からの学びを共有してもらうことで、自分にはなかった視点・気付きを獲得し、その書籍への理解をより深められる効果があります。 本研修プログラムにおける輪読会の目的としては、 Web サービスを開発していく上で必要となる知識へ触れることにより、今後獲得していくべき知識のベースラインを理解すること でしたが、輪読会ならではのメリット・楽しさを新卒に実感してもらえたことも、副次的な効果としてあったと思います。 新卒からの声 Web の基本的な知識を「なぜ登場したのか」を理解しながら網羅的に学ぶことができた 文書でまとめた後に、口で説明することが学んだ内容の定着に良いと感じた これまでなんとなく実装していたことの仕組みを学ぶことで、知識として定着することができた 中間報告会 フェーズ 2：エンジニア基礎研修最後の研修プログラムである中間報告会に向けて、ドキュメンテーションスキル研修、プレゼンテーションスキル研修を実施しました。 上記スキルが必要となる背景は、次の通りです。 エンジニアリングを通じた課題解決とはプログラムを書くだけでは解決しない場面もある 背景、目的を正しくステークホルダーへ共有しながらチームとして取り組んでいくことになる 伝えたいことを文章として整理し、他者へ分かりやすく伝えていくことが求められる また、メドレーの行動原則 Our Essentials を構成する要素として、「ドキュメントドリブン」「全てを明確に」という項目が含まれており、これらを実現するためにも、とても重要なスキルとしてメドレーは考えています。 新卒研修が終わった後も、エンジニアとして技術的なスキルを身につける機会は日常的に多くありますが、上記のようなスキルをまとめて習得する機会は少ないため、このような研修を社会人のはじめから受けておくことで、その後の伸びしろが違ってくるのではないかと思います。 研修が終わった後は、各自で報告会用の資料を作成し、研修講師からの添削を受けました。 中間報告会は各部署の開発マネージャーを発表相手として、当日は程よい緊張感をもって、良い雰囲気で報告会を終えられました。 フェーズ 3：事業部 OJT 事業部研修 取締役豊田からの講義 CLINICS 事業部研修 ジョブメドレー事業部研修 開発 OJT システム全体像説明 環境構築 各プロダクトの開発チームでの OJT フェーズ 3 では、 顧客の課題と、顧客への価値提供のための各チームの連携を体感し、メドレーの顧客提供価値を自分の言葉で話せるようになること をゴールとしました。 フェーズ 3 のはじめに、取締役豊田による日本の医療の課題とメドレーの取り組みに関する講義を受講してもらいました。 持続可能な医療体制を構築していくためにメドレーが成すべきことなどの話を聞いた後に、新卒からの質問の受け答えによって理解を深め、メドレーの社会的意義をあらためて認識してもらい、エンジニアとしてだけではなく、 メドレー社員としての自覚 を強めてもらいました。 事業部研修 開発 OJT で手を動かす前に、自分たちが何のために開発するのかを具体的にイメージできるよう、次のように、各現場に参加してもらいました。 見込顧客への架電業務見学 商談前の社内ミーティング参加 商談現場同席 定例会議参加 事業部のスタッフが、顧客の課題に対して、どのような対応をしていて、どのようにプロダクトを説明しているのか、事業部の各チームが、どのように連携して最終的に顧客に価値を届けるのかの全体観を知ってもらうことを狙いとしていました。 開発チームのエンジニアは業務上、プロダクトのエンドユーザーである顧客の声などを商談のタイミングから聞ける機会はなかなか無いので、研修を通じて話を聞けたことは、今後の開発モチベーションにも影響する良い機会だったと思います。 新卒からの声 ユーザー、顧客、事業部が抱える課題を確認できたことで、開発以外にも目を向けるきっかけになり良かった 各部署が KPI として定めている数字を知ることができ、開発に降りてきている施策の影響箇所がどの部分かを理解できた上で、開発に取り組むことができるようになった 各部署のミーディングに参加することで、各部署がどのような考えで何を目指しているのかを理解でき、メドレー全体として目指している方向性が掴めた 開発 OJT 事業部研修に続く開発 OJT では、 ジョブメドレー 、 CLINICS 、 介護のほんね の開発チームに分かれて、研修を実施しました。 OJT 配属先では、メンターとは別に、トレーナーを付けて業務の進め方などをサポートしました。トレーナーは配属先の先輩エンジニアが担当しました。 OJT の流れとしては、初日に、プロダクトがどのように動いているのか、システム全体像を把握することから始まり、各自、ドキュメントに沿って、PC にローカル開発環境をセットアップしました。 その後は、他の先輩エンジニアと同様に、GitHub Issue で管理されている課題を解消することを日々の目標としてこなしてもらいました。ただし、単に Issue に書かれている課題をクリアしようとするのではなく、 そもそも、なぜそれをやるのか、Issue の背景や起票者の意図を十分に理解した上で、プロダクトのあるべき姿に導く ことを意識してもらいました。 Issue に書かれている内容の理解が不十分だったり、解決方針がうまく定まらない場合は随時、ミーティングの時間を設けて、Issue 起票者やトレーナーと認識合わせを行い、認識の相違から生まれるミスコミュニケーションを極力減らすよう、取り組みました。 技術的な質問に関しても、定期的に質問タイムを設けたり、複雑になりそうな実装や、つまずきポイントとなりそうな箇所に関しては、 画面共有を用いてレビュー を行い、疑問点に関してもその場で確認して、解消してもらいました。 緊急事態宣言期間中だったため、会社全体で原則、在宅勤務の体制となっており、対面でのコミュニケーションが希薄になりがちでしたが、朝会、夕会を含め、たとえ新卒から質問が無くても質問タイムでのミーティングは定期的に実施するなど、 できるだけ頻繁に顔合わせして、新卒本人の声と顔を確認する よう心がけました。 Issue へのアサインから始まって、実装 -> レビュー依頼 -> QA -> リリース -> Issue 起票者への報告まで、一連の開発フローを経験してもらい、チーム内での開発業務に慣れてもらうことができました。 フェーズ 4：最終報告 新卒研修最後のプログラムとして、メドレー役員陣に向けた最終報告会を実施しました。 最終報告会の目的としては、次の通りです。 学んだことの知識を深化させる 自らの得手・不得手を捉え、将来の成長計画を立てる 体系的に整理・文書化して他者へ伝えるスキルを向上させる 役員陣に向けてプレゼンすることで、本配属に向けた決意表明として区切りを付ける 役員陣への発表であることに加え、一人あたりの発表時間にも制限が設けられており、当日の緊張はかなりのものだったと思います。 前日に発表会場を下見して、リハーサルを入念に行うなど、当日の発表会を成功させるため、メドレーのエンジニアとしての自覚を持って、発表準備に取り組んでいました。 技術志向とプロダクト志向の両輪を目指すエンジニア募集中 メドレーの研修では、技術的な講義や実践だけで終わるのではなく、ビジネスパーソンとして必要な基礎も身につけ、なぜ開発するのかを追究し、プロダクトを通じた課題解決を実体験してもらうことを重視しています。 メドレーでは、医療ヘルスケア分野の課題解決に挑みたいエンジニアを募集しています。 新卒の学生に限らず、中途採用も行っているので、エンジニアの方で少しでも興味を持っていただけたら、是非、面談でお話ししましょう。 最後までお読みいただき、誠にありがとうございました。 P.S. 昨年、一昨年の新卒研修の様子はこちらより、それぞれご覧いただけます。 2020 年度新卒エンジニア研修について 2019 年度新卒エンジニア研修について 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。医療介護求人サイト「ジョブメドレー」の開発を担当しているエンジニアの山田です。 今年の新卒エンジニア研修において、メンターを担当しました。 メドレーでは 2019 年度から新卒採用を行なっており、今年 2021 年度は 5 名の新卒がエンジニアとして入社しました。 例年と同じく 4 月から 9 月にかけて、約 5 ヶ月間の新卒エンジニア研修を実施しましたので、その取り組みを、研修受講者である新卒からの声も交えてご紹介します。 新卒研修の概要 今年の新卒研修の最終ゴールは、「 メドレーのエンジニアとして、 Our Essentials (※) を体現し、顧客へ価値提供できるようになるための基礎を身につけ、経験を得ること 」として掲げました。 ※) メドレーの行動原則 メドレーの新卒エンジニア研修では、技術を身につけることだけではなく、ビジネスパーソンとしての基礎を身につけ、メドレーが大切にしている価値観を理解し、体現する意識をもって、顧客への価値提供について自分の言葉で話せるようになることまでを目指してもらいます。 研修は昨年同様、大きく分けて、4 つのフェーズに区切って行いました。 また、全研修期間を通じて、各新卒にはメンターを一人ずつ付けました。メンターは、一週間に 1~2 回のペースで新卒と 1on1 ミーティングを実施し、フィジカルとメンタルの両面を気遣い、個別にフォローを行いました。 新卒研修の内容 フェーズ 1：社会人&メドレー基礎研修 リスク研修 インサイダー取引防止研修 コンプライアンス研修 情報セキュリティ研修 ビジネス研修 ビジネスマナー研修 ビジネススキル研修 ビジネススタンス研修（外部研修） フェーズ 1 では、 成果を出し、価値を発揮するために必要なビジネスパーソンとしての基本的な仕事の型を身につけること をゴールとしました。 リスク研修では、メドレー社員として、社会人として、身の周りで起こりうるリスクについて考え、いかにそれらのリスクと向き合うかを講義形式で学んでもらいました。 ビジネス研修では、社会人としての最低限のマナーを学び、論理的思考力、コミュニケーション力など、エンジニア職に限らない課題解決力へつながるポータブルな知識を、座学とワークショップを通じて定着してもらうことを図りました。 また、社会人の基準で仕事と向き合い、適切な報連相によって周囲と協働していくことの重要性についても学んでもらいました。 新卒からの声 質の高い、多量のインプット・アウトプットができた 伝わるメールの書き方、名刺の渡し方など、社会人に必須のマナーやスキルを認識できた ワークを通じて、言葉では理解していても行動するとできないことを洗い出せた フェーズ 2：エンジニア基礎研修 開発基礎 1 メドレーエンジニアとして求めること 事業（ジョブメドレー ・ CLINICS ・介護のほんね）の概要説明 開発基礎研修（Ruby on Rails チュートリアル） 開発実践 （要件定義〜リリースまで） 開発基礎 2 技術書の輪読会 ドキュメンテーションスキル研修 プレゼンテーションスキル研修 中間レポート作成 中間報告会 フェーズ 2 では、新卒研修後に開発業務に入ってもらえるよう、 エンジニアとしての基礎を身につけること をゴールとしました。 メドレーエンジニアとして求めること 開発に関わるこのフェーズにおいても、要件定義を含む汎用的な技術的スキルは勿論のこと、メドレーエンジニアが共通して持つべき価値観などを共有するため、フェーズ 2 初日は「 メドレーエンジニアとして求めること 」と題して、エンジニアの執行役員 田中が講義を行いました。 講義では、「 エンジニア とは、 エンジニアの価値 とは、 プロエンジニア とはなんでしょうか？」という問いから始まり、講義の終わりにはもう一度同じ問いかけをして締めくくり、新卒がメドレーの求めるエンジニア像について自身の言葉で話せるように考えてもらいました。 メドレーが求めるエンジニア像については、CTO 平山の メドレー平山の中央突破: THE エンジニア にも書かれていますので、よろしければ、あわせてご覧ください。 さらに、メドレーが展開する各事業および関連するプロダクトの概要説明をプロダクトマネージャーが行い、メドレーで開発する意義をあらためて認識してもらいました。 開発基礎研修 2 日目より、 Ruby on Rails チュートリアル （以下、「Rails チュートリアル」）を教材とした、開発基礎研修に移りました。 メドレーのプロダクトは Rails で作られているものが多く、Web アプリケーションを開発するための基礎を身につけるためにも、Rails チュートリアルの内容を実施してもらいました。 単純に、Rails チュートリアルの内容に沿って、ダラダラと写経するのではなく、随時、学んだことは Confluence にまとめ、GitHub 上で Pull Request を作成する形で、ソースコードを共有してもらいました。 学んだことを自分の言葉に置き換えてアウトプットすることで反復学習を促し、Pull Request を作成してもらうことで GitHub の使い方に慣れてもらうことを図りました。 また、デイリーで朝会と夕会を実施しました。朝会は仕事のリズムを整えるための顔合わせ、夕会は新卒から質問・成果を共有してメンターがそれに対してフィードバックをする場としてそれぞれ実施しました。 研修前に既に Rails チュートリアルを一周していた新卒もいましたが、二周目を実施して新たな気付きを得たり、AWS を用いてクラウド上に環境構築し、作成した Web アプリケーションをデプロイするまでを実践してもらうなど、インフラに関しても理解を深めてもらうことができました。 新卒からの声 システムのパフォーマンスを上げるための工夫を知ることができた バグ発生〜原因特定〜修正、というデバッグのスピードが、研修序盤から飛躍的に上がった プロダクトで利用している AWS の各種サービスの概要を理解できたことに加え、サービス間の繋がりやネットワークの流れに関しても理解を深めることができた 開発実践 開発基礎研修にて Web アプリケーション開発の基礎を学んだ後は、「 メドレー/グループ会社で使う来訪者受付システム 」を開発題材として、開発実践研修を行いました。 開発業務全体の流れを把握することで、 チームで開発（課題解決）することを経験し、今後の仕事に役立たせること を目的としました。 本研修で達成すべきこととして掲げていたものは主に、次の通りです。 プロジェクト管理能力を身につけること 開発する対象を体系的に整理できる能力を養うこと システム設計に関する基礎的な物事を理解すること チーム開発を理解すること 品質を理解すること 既に決まりきった仕様書に沿って開発するのではなく、新卒自身が現状の問題把握や課題整理を行って、ユーザーへ価値提供するために何を作るべきかを考えることから始まり、リリース後の運用方法やランニングコストのことまで考え提案してもらいました。 開発実践研修は約 1 ヶ月の期間をかけて行いました。大まかな流れとしては、次の通りです。 要件定義（ヒアリング・現状把握・課題整理・要求分析・機能/非機能要件の洗い出し・ UI 草案） プロジェクト計画（役割分担・ WBS/ガントチャート作成） 設計（画面設計・機能設計・データモデリング・方式設計・インフラ設計） 開発（実装・コードレビュー） QA（テスト設計・テスト） 成果発表（成果物を関係者へプレゼン・リリース） 方式設計の一部として、開発に使用する言語などの選定も新卒自身が行いました。 今回作成した社員向け管理画面と来訪者向け画面はいずれも SPA（一部、PWA）のアーキテクチャを採用し、主なライブラリ/フレームワークに関して、フロントエンドは TypeScript , React , Next.js , Chakra UI , Ionic Framework 、バックエンドは Ruby on Rails（API モード）をそれぞれ利用することとなりました。 選定理由としては主に、次の通りです。 TypeScript, React（両画面共通） ロジックからテンプレートまでの全てのコードを静的型付けで書くことができ、堅牢性に優れているため Next.js, Chakra UI（社員向け管理画面） ゼロコンフィグでビルドやレンダリングを最適化できるため アクセシビリティに優れたリッチな UI を素早く構築できるため Ionic Framework（来訪者向け画面） iPad 上で、ネイティブアプリのような UI/UX を提供するため Ruby on Rails API モード フロントエンドとバックエンドを分離して疎結合にするため 短期間で構築するため 社内でもよく使われておりメンテナンスしやすいため インフラは AWS を採用し、EC2, S3, RDS, CloudFront, Route53, CloudWatch などのサービスを利用しました。 結果的に、本研修プログラムの成果物としてリリースされたシステムは「 Medley Entrance 」という名前で、社内ツールとして現在、毎日稼働しており、ユーザーとしてメドレー/グループ社員だけではなく、来訪者の方々にも使っていただいています。 Medley Entrance（上：社員向け管理画面、下：来訪者向け画面） チームで課題解決に臨み、価値提供までの実績を残せたことは自信につながり、開発実践研修のやりがいとして、感じてもらえたのではないでしょうか。 要件定義などの期間中、想定よりもスムーズに進められなかった時も他責にせず、各々がリーダーシップを発揮し、建設的に進めていく新卒の様子をメンターの一人として傍で見させてもらいました。 この 1 ヶ月間の開発実践研修を通じて、技術力はさることながら、課題解決に対する十分な熱意と主体性を新卒から感じられ、とても頼もしい印象として残りました。 新卒からの声 開発の中での方針を意識して設計/実装することができた(シンプルにする) QA とはそもそも何かというリサーチから入り、有識者の考え方を軸に方針を決めてから始められた 各々が最適なパフォーマンスを発揮できる環境づくりを意識して、高速な意思決定が可能な体制を整えることができた 要件が決まりきっていない中で設計するのは難しかった 開発タスクが集中していた時に、プロジェクト全体の現状を把握できていなかった 文章を作るスキルが足りていない 技術書の輪読会 フェーズ 2 の開発基礎 2 の輪読会では、 『Web を支える技術 -HTTP、URI、HTML、そして REST』 を題材書籍として、7 日間に渡って毎日、次の手順で実施しました。 参加者が同じパートをあらかじめ読んでおき、書籍から学んだこと、ネットなどで調べても解消しきれなかった疑問点などをまとめる その内容をもとに、夕方のミーティング時において、各自が発表してディスカッションを行う ディスカッションした内容は議事録にまとめる 輪読会は他者からの学びを共有してもらうことで、自分にはなかった視点・気付きを獲得し、その書籍への理解をより深められる効果があります。 本研修プログラムにおける輪読会の目的としては、 Web サービスを開発していく上で必要となる知識へ触れることにより、今後獲得していくべき知識のベースラインを理解すること でしたが、輪読会ならではのメリット・楽しさを新卒に実感してもらえたことも、副次的な効果としてあったと思います。 新卒からの声 Web の基本的な知識を「なぜ登場したのか」を理解しながら網羅的に学ぶことができた 文書でまとめた後に、口で説明することが学んだ内容の定着に良いと感じた これまでなんとなく実装していたことの仕組みを学ぶことで、知識として定着することができた 中間報告会 フェーズ 2：エンジニア基礎研修最後の研修プログラムである中間報告会に向けて、ドキュメンテーションスキル研修、プレゼンテーションスキル研修を実施しました。 上記スキルが必要となる背景は、次の通りです。 エンジニアリングを通じた課題解決とはプログラムを書くだけでは解決しない場面もある 背景、目的を正しくステークホルダーへ共有しながらチームとして取り組んでいくことになる 伝えたいことを文章として整理し、他者へ分かりやすく伝えていくことが求められる また、メドレーの行動原則 Our Essentials を構成する要素として、「ドキュメントドリブン」「全てを明確に」という項目が含まれており、これらを実現するためにも、とても重要なスキルとしてメドレーは考えています。 新卒研修が終わった後も、エンジニアとして技術的なスキルを身につける機会は日常的に多くありますが、上記のようなスキルをまとめて習得する機会は少ないため、このような研修を社会人のはじめから受けておくことで、その後の伸びしろが違ってくるのではないかと思います。 研修が終わった後は、各自で報告会用の資料を作成し、研修講師からの添削を受けました。 中間報告会は各部署の開発マネージャーを発表相手として、当日は程よい緊張感をもって、良い雰囲気で報告会を終えられました。 フェーズ 3：事業部 OJT 事業部研修 取締役豊田からの講義 CLINICS 事業部研修 ジョブメドレー事業部研修 開発 OJT システム全体像説明 環境構築 各プロダクトの開発チームでの OJT フェーズ 3 では、 顧客の課題と、顧客への価値提供のための各チームの連携を体感し、メドレーの顧客提供価値を自分の言葉で話せるようになること をゴールとしました。 フェーズ 3 のはじめに、取締役豊田による日本の医療の課題とメドレーの取り組みに関する講義を受講してもらいました。 持続可能な医療体制を構築していくためにメドレーが成すべきことなどの話を聞いた後に、新卒からの質問の受け答えによって理解を深め、メドレーの社会的意義をあらためて認識してもらい、エンジニアとしてだけではなく、 メドレー社員としての自覚 を強めてもらいました。 事業部研修 開発 OJT で手を動かす前に、自分たちが何のために開発するのかを具体的にイメージできるよう、次のように、各現場に参加してもらいました。 見込顧客への架電業務見学 商談前の社内ミーティング参加 商談現場同席 定例会議参加 事業部のスタッフが、顧客の課題に対して、どのような対応をしていて、どのようにプロダクトを説明しているのか、事業部の各チームが、どのように連携して最終的に顧客に価値を届けるのかの全体観を知ってもらうことを狙いとしていました。 開発チームのエンジニアは業務上、プロダクトのエンドユーザーである顧客の声などを商談のタイミングから聞ける機会はなかなか無いので、研修を通じて話を聞けたことは、今後の開発モチベーションにも影響する良い機会だったと思います。 新卒からの声 ユーザー、顧客、事業部が抱える課題を確認できたことで、開発以外にも目を向けるきっかけになり良かった 各部署が KPI として定めている数字を知ることができ、開発に降りてきている施策の影響箇所がどの部分かを理解できた上で、開発に取り組むことができるようになった 各部署のミーディングに参加することで、各部署がどのような考えで何を目指しているのかを理解でき、メドレー全体として目指している方向性が掴めた 開発 OJT 事業部研修に続く開発 OJT では、 ジョブメドレー 、 CLINICS 、 介護のほんね の開発チームに分かれて、研修を実施しました。 OJT 配属先では、メンターとは別に、トレーナーを付けて業務の進め方などをサポートしました。トレーナーは配属先の先輩エンジニアが担当しました。 OJT の流れとしては、初日に、プロダクトがどのように動いているのか、システム全体像を把握することから始まり、各自、ドキュメントに沿って、PC にローカル開発環境をセットアップしました。 その後は、他の先輩エンジニアと同様に、GitHub Issue で管理されている課題を解消することを日々の目標としてこなしてもらいました。ただし、単に Issue に書かれている課題をクリアしようとするのではなく、 そもそも、なぜそれをやるのか、Issue の背景や起票者の意図を十分に理解した上で、プロダクトのあるべき姿に導く ことを意識してもらいました。 Issue に書かれている内容の理解が不十分だったり、解決方針がうまく定まらない場合は随時、ミーティングの時間を設けて、Issue 起票者やトレーナーと認識合わせを行い、認識の相違から生まれるミスコミュニケーションを極力減らすよう、取り組みました。 技術的な質問に関しても、定期的に質問タイムを設けたり、複雑になりそうな実装や、つまずきポイントとなりそうな箇所に関しては、 画面共有を用いてレビュー を行い、疑問点に関してもその場で確認して、解消してもらいました。 緊急事態宣言期間中だったため、会社全体で原則、在宅勤務の体制となっており、対面でのコミュニケーションが希薄になりがちでしたが、朝会、夕会を含め、たとえ新卒から質問が無くても質問タイムでのミーティングは定期的に実施するなど、 できるだけ頻繁に顔合わせして、新卒本人の声と顔を確認する よう心がけました。 Issue へのアサインから始まって、実装 -> レビュー依頼 -> QA -> リリース -> Issue 起票者への報告まで、一連の開発フローを経験してもらい、チーム内での開発業務に慣れてもらうことができました。 フェーズ 4：最終報告 新卒研修最後のプログラムとして、メドレー役員陣に向けた最終報告会を実施しました。 最終報告会の目的としては、次の通りです。 学んだことの知識を深化させる 自らの得手・不得手を捉え、将来の成長計画を立てる 体系的に整理・文書化して他者へ伝えるスキルを向上させる 役員陣に向けてプレゼンすることで、本配属に向けた決意表明として区切りを付ける 役員陣への発表であることに加え、一人あたりの発表時間にも制限が設けられており、当日の緊張はかなりのものだったと思います。 前日に発表会場を下見して、リハーサルを入念に行うなど、当日の発表会を成功させるため、メドレーのエンジニアとしての自覚を持って、発表準備に取り組んでいました。 技術志向とプロダクト志向の両輪を目指すエンジニア募集中 メドレーの研修では、技術的な講義や実践だけで終わるのではなく、ビジネスパーソンとして必要な基礎も身につけ、なぜ開発するのかを追究し、プロダクトを通じた課題解決を実体験してもらうことを重視しています。 メドレーでは、医療ヘルスケア分野の課題解決に挑みたいエンジニアを募集しています。 新卒の学生に限らず、中途採用も行っているので、エンジニアの方で少しでも興味を持っていただけたら、是非、面談でお話ししましょう。 最後までお読みいただき、誠にありがとうございました。 P.S. 昨年、一昨年の新卒研修の様子はこちらより、それぞれご覧いただけます。 2020 年度新卒エンジニア研修について 2019 年度新卒エンジニア研修について 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。医療介護求人サイト「ジョブメドレー」の開発を担当しているエンジニアの山田です。 今年の新卒エンジニア研修において、メンターを担当しました。 メドレーでは 2019 年度から新卒採用を行なっており、今年 2021 年度は 5 名の新卒がエンジニアとして入社しました。 例年と同じく 4 月から 9 月にかけて、約 5 ヶ月間の新卒エンジニア研修を実施しましたので、その取り組みを、研修受講者である新卒からの声も交えてご紹介します。 新卒研修の概要 今年の新卒研修の最終ゴールは、「 メドレーのエンジニアとして、 Our Essentials (※) を体現し、顧客へ価値提供できるようになるための基礎を身につけ、経験を得ること 」として掲げました。 ※) メドレーの行動原則 メドレーの新卒エンジニア研修では、技術を身につけることだけではなく、ビジネスパーソンとしての基礎を身につけ、メドレーが大切にしている価値観を理解し、体現する意識をもって、顧客への価値提供について自分の言葉で話せるようになることまでを目指してもらいます。 研修は昨年同様、大きく分けて、4 つのフェーズに区切って行いました。 また、全研修期間を通じて、各新卒にはメンターを一人ずつ付けました。メンターは、一週間に 1~2 回のペースで新卒と 1on1 ミーティングを実施し、フィジカルとメンタルの両面を気遣い、個別にフォローを行いました。 新卒研修の内容 フェーズ 1：社会人&メドレー基礎研修 リスク研修 インサイダー取引防止研修 コンプライアンス研修 情報セキュリティ研修 ビジネス研修 ビジネスマナー研修 ビジネススキル研修 ビジネススタンス研修（外部研修） フェーズ 1 では、 成果を出し、価値を発揮するために必要なビジネスパーソンとしての基本的な仕事の型を身につけること をゴールとしました。 リスク研修では、メドレー社員として、社会人として、身の周りで起こりうるリスクについて考え、いかにそれらのリスクと向き合うかを講義形式で学んでもらいました。 ビジネス研修では、社会人としての最低限のマナーを学び、論理的思考力、コミュニケーション力など、エンジニア職に限らない課題解決力へつながるポータブルな知識を、座学とワークショップを通じて定着してもらうことを図りました。 また、社会人の基準で仕事と向き合い、適切な報連相によって周囲と協働していくことの重要性についても学んでもらいました。 新卒からの声 質の高い、多量のインプット・アウトプットができた 伝わるメールの書き方、名刺の渡し方など、社会人に必須のマナーやスキルを認識できた ワークを通じて、言葉では理解していても行動するとできないことを洗い出せた フェーズ 2：エンジニア基礎研修 開発基礎 1 メドレーエンジニアとして求めること 事業（ジョブメドレー ・ CLINICS ・介護のほんね）の概要説明 開発基礎研修（Ruby on Rails チュートリアル） 開発実践 （要件定義〜リリースまで） 開発基礎 2 技術書の輪読会 ドキュメンテーションスキル研修 プレゼンテーションスキル研修 中間レポート作成 中間報告会 フェーズ 2 では、新卒研修後に開発業務に入ってもらえるよう、 エンジニアとしての基礎を身につけること をゴールとしました。 メドレーエンジニアとして求めること 開発に関わるこのフェーズにおいても、要件定義を含む汎用的な技術的スキルは勿論のこと、メドレーエンジニアが共通して持つべき価値観などを共有するため、フェーズ 2 初日は「 メドレーエンジニアとして求めること 」と題して、エンジニアの執行役員 田中が講義を行いました。 講義では、「 エンジニア とは、 エンジニアの価値 とは、 プロエンジニア とはなんでしょうか？」という問いから始まり、講義の終わりにはもう一度同じ問いかけをして締めくくり、新卒がメドレーの求めるエンジニア像について自身の言葉で話せるように考えてもらいました。 メドレーが求めるエンジニア像については、CTO 平山の メドレー平山の中央突破: THE エンジニア にも書かれていますので、よろしければ、あわせてご覧ください。 さらに、メドレーが展開する各事業および関連するプロダクトの概要説明をプロダクトマネージャーが行い、メドレーで開発する意義をあらためて認識してもらいました。 開発基礎研修 2 日目より、 Ruby on Rails チュートリアル （以下、「Rails チュートリアル」）を教材とした、開発基礎研修に移りました。 メドレーのプロダクトは Rails で作られているものが多く、Web アプリケーションを開発するための基礎を身につけるためにも、Rails チュートリアルの内容を実施してもらいました。 単純に、Rails チュートリアルの内容に沿って、ダラダラと写経するのではなく、随時、学んだことは Confluence にまとめ、GitHub 上で Pull Request を作成する形で、ソースコードを共有してもらいました。 学んだことを自分の言葉に置き換えてアウトプットすることで反復学習を促し、Pull Request を作成してもらうことで GitHub の使い方に慣れてもらうことを図りました。 また、デイリーで朝会と夕会を実施しました。朝会は仕事のリズムを整えるための顔合わせ、夕会は新卒から質問・成果を共有してメンターがそれに対してフィードバックをする場としてそれぞれ実施しました。 研修前に既に Rails チュートリアルを一周していた新卒もいましたが、二周目を実施して新たな気付きを得たり、AWS を用いてクラウド上に環境構築し、作成した Web アプリケーションをデプロイするまでを実践してもらうなど、インフラに関しても理解を深めてもらうことができました。 新卒からの声 システムのパフォーマンスを上げるための工夫を知ることができた バグ発生〜原因特定〜修正、というデバッグのスピードが、研修序盤から飛躍的に上がった プロダクトで利用している AWS の各種サービスの概要を理解できたことに加え、サービス間の繋がりやネットワークの流れに関しても理解を深めることができた 開発実践 開発基礎研修にて Web アプリケーション開発の基礎を学んだ後は、「 メドレー/グループ会社で使う来訪者受付システム 」を開発題材として、開発実践研修を行いました。 開発業務全体の流れを把握することで、 チームで開発（課題解決）することを経験し、今後の仕事に役立たせること を目的としました。 本研修で達成すべきこととして掲げていたものは主に、次の通りです。 プロジェクト管理能力を身につけること 開発する対象を体系的に整理できる能力を養うこと システム設計に関する基礎的な物事を理解すること チーム開発を理解すること 品質を理解すること 既に決まりきった仕様書に沿って開発するのではなく、新卒自身が現状の問題把握や課題整理を行って、ユーザーへ価値提供するために何を作るべきかを考えることから始まり、リリース後の運用方法やランニングコストのことまで考え提案してもらいました。 開発実践研修は約 1 ヶ月の期間をかけて行いました。大まかな流れとしては、次の通りです。 要件定義（ヒアリング・現状把握・課題整理・要求分析・機能/非機能要件の洗い出し・ UI 草案） プロジェクト計画（役割分担・ WBS/ガントチャート作成） 設計（画面設計・機能設計・データモデリング・方式設計・インフラ設計） 開発（実装・コードレビュー） QA（テスト設計・テスト） 成果発表（成果物を関係者へプレゼン・リリース） 方式設計の一部として、開発に使用する言語などの選定も新卒自身が行いました。 今回作成した社員向け管理画面と来訪者向け画面はいずれも SPA（一部、PWA）のアーキテクチャを採用し、主なライブラリ/フレームワークに関して、フロントエンドは TypeScript , React , Next.js , Chakra UI , Ionic Framework 、バックエンドは Ruby on Rails（API モード）をそれぞれ利用することとなりました。 選定理由としては主に、次の通りです。 TypeScript, React（両画面共通） ロジックからテンプレートまでの全てのコードを静的型付けで書くことができ、堅牢性に優れているため Next.js, Chakra UI（社員向け管理画面） ゼロコンフィグでビルドやレンダリングを最適化できるため アクセシビリティに優れたリッチな UI を素早く構築できるため Ionic Framework（来訪者向け画面） iPad 上で、ネイティブアプリのような UI/UX を提供するため Ruby on Rails API モード フロントエンドとバックエンドを分離して疎結合にするため 短期間で構築するため 社内でもよく使われておりメンテナンスしやすいため インフラは AWS を採用し、EC2, S3, RDS, CloudFront, Route53, CloudWatch などのサービスを利用しました。 結果的に、本研修プログラムの成果物としてリリースされたシステムは「 Medley Entrance 」という名前で、社内ツールとして現在、毎日稼働しており、ユーザーとしてメドレー/グループ社員だけではなく、来訪者の方々にも使っていただいています。 Medley Entrance（上：社員向け管理画面、下：来訪者向け画面） チームで課題解決に臨み、価値提供までの実績を残せたことは自信につながり、開発実践研修のやりがいとして、感じてもらえたのではないでしょうか。 要件定義などの期間中、想定よりもスムーズに進められなかった時も他責にせず、各々がリーダーシップを発揮し、建設的に進めていく新卒の様子をメンターの一人として傍で見させてもらいました。 この 1 ヶ月間の開発実践研修を通じて、技術力はさることながら、課題解決に対する十分な熱意と主体性を新卒から感じられ、とても頼もしい印象として残りました。 新卒からの声 開発の中での方針を意識して設計/実装することができた(シンプルにする) QA とはそもそも何かというリサーチから入り、有識者の考え方を軸に方針を決めてから始められた 各々が最適なパフォーマンスを発揮できる環境づくりを意識して、高速な意思決定が可能な体制を整えることができた 要件が決まりきっていない中で設計するのは難しかった 開発タスクが集中していた時に、プロジェクト全体の現状を把握できていなかった 文章を作るスキルが足りていない 技術書の輪読会 フェーズ 2 の開発基礎 2 の輪読会では、 『Web を支える技術 -HTTP、URI、HTML、そして REST』 を題材書籍として、7 日間に渡って毎日、次の手順で実施しました。 参加者が同じパートをあらかじめ読んでおき、書籍から学んだこと、ネットなどで調べても解消しきれなかった疑問点などをまとめる その内容をもとに、夕方のミーティング時において、各自が発表してディスカッションを行う ディスカッションした内容は議事録にまとめる 輪読会は他者からの学びを共有してもらうことで、自分にはなかった視点・気付きを獲得し、その書籍への理解をより深められる効果があります。 本研修プログラムにおける輪読会の目的としては、 Web サービスを開発していく上で必要となる知識へ触れることにより、今後獲得していくべき知識のベースラインを理解すること でしたが、輪読会ならではのメリット・楽しさを新卒に実感してもらえたことも、副次的な効果としてあったと思います。 新卒からの声 Web の基本的な知識を「なぜ登場したのか」を理解しながら網羅的に学ぶことができた 文書でまとめた後に、口で説明することが学んだ内容の定着に良いと感じた これまでなんとなく実装していたことの仕組みを学ぶことで、知識として定着することができた 中間報告会 フェーズ 2：エンジニア基礎研修最後の研修プログラムである中間報告会に向けて、ドキュメンテーションスキル研修、プレゼンテーションスキル研修を実施しました。 上記スキルが必要となる背景は、次の通りです。 エンジニアリングを通じた課題解決とはプログラムを書くだけでは解決しない場面もある 背景、目的を正しくステークホルダーへ共有しながらチームとして取り組んでいくことになる 伝えたいことを文章として整理し、他者へ分かりやすく伝えていくことが求められる また、メドレーの行動原則 Our Essentials を構成する要素として、「ドキュメントドリブン」「全てを明確に」という項目が含まれており、これらを実現するためにも、とても重要なスキルとしてメドレーは考えています。 新卒研修が終わった後も、エンジニアとして技術的なスキルを身につける機会は日常的に多くありますが、上記のようなスキルをまとめて習得する機会は少ないため、このような研修を社会人のはじめから受けておくことで、その後の伸びしろが違ってくるのではないかと思います。 研修が終わった後は、各自で報告会用の資料を作成し、研修講師からの添削を受けました。 中間報告会は各部署の開発マネージャーを発表相手として、当日は程よい緊張感をもって、良い雰囲気で報告会を終えられました。 フェーズ 3：事業部 OJT 事業部研修 取締役豊田からの講義 CLINICS 事業部研修 ジョブメドレー事業部研修 開発 OJT システム全体像説明 環境構築 各プロダクトの開発チームでの OJT フェーズ 3 では、 顧客の課題と、顧客への価値提供のための各チームの連携を体感し、メドレーの顧客提供価値を自分の言葉で話せるようになること をゴールとしました。 フェーズ 3 のはじめに、取締役豊田による日本の医療の課題とメドレーの取り組みに関する講義を受講してもらいました。 持続可能な医療体制を構築していくためにメドレーが成すべきことなどの話を聞いた後に、新卒からの質問の受け答えによって理解を深め、メドレーの社会的意義をあらためて認識してもらい、エンジニアとしてだけではなく、 メドレー社員としての自覚 を強めてもらいました。 事業部研修 開発 OJT で手を動かす前に、自分たちが何のために開発するのかを具体的にイメージできるよう、次のように、各現場に参加してもらいました。 見込顧客への架電業務見学 商談前の社内ミーティング参加 商談現場同席 定例会議参加 事業部のスタッフが、顧客の課題に対して、どのような対応をしていて、どのようにプロダクトを説明しているのか、事業部の各チームが、どのように連携して最終的に顧客に価値を届けるのかの全体観を知ってもらうことを狙いとしていました。 開発チームのエンジニアは業務上、プロダクトのエンドユーザーである顧客の声などを商談のタイミングから聞ける機会はなかなか無いので、研修を通じて話を聞けたことは、今後の開発モチベーションにも影響する良い機会だったと思います。 新卒からの声 ユーザー、顧客、事業部が抱える課題を確認できたことで、開発以外にも目を向けるきっかけになり良かった 各部署が KPI として定めている数字を知ることができ、開発に降りてきている施策の影響箇所がどの部分かを理解できた上で、開発に取り組むことができるようになった 各部署のミーディングに参加することで、各部署がどのような考えで何を目指しているのかを理解でき、メドレー全体として目指している方向性が掴めた 開発 OJT 事業部研修に続く開発 OJT では、 ジョブメドレー 、 CLINICS 、 介護のほんね の開発チームに分かれて、研修を実施しました。 OJT 配属先では、メンターとは別に、トレーナーを付けて業務の進め方などをサポートしました。トレーナーは配属先の先輩エンジニアが担当しました。 OJT の流れとしては、初日に、プロダクトがどのように動いているのか、システム全体像を把握することから始まり、各自、ドキュメントに沿って、PC にローカル開発環境をセットアップしました。 その後は、他の先輩エンジニアと同様に、GitHub Issue で管理されている課題を解消することを日々の目標としてこなしてもらいました。ただし、単に Issue に書かれている課題をクリアしようとするのではなく、 そもそも、なぜそれをやるのか、Issue の背景や起票者の意図を十分に理解した上で、プロダクトのあるべき姿に導く ことを意識してもらいました。 Issue に書かれている内容の理解が不十分だったり、解決方針がうまく定まらない場合は随時、ミーティングの時間を設けて、Issue 起票者やトレーナーと認識合わせを行い、認識の相違から生まれるミスコミュニケーションを極力減らすよう、取り組みました。 技術的な質問に関しても、定期的に質問タイムを設けたり、複雑になりそうな実装や、つまずきポイントとなりそうな箇所に関しては、 画面共有を用いてレビュー を行い、疑問点に関してもその場で確認して、解消してもらいました。 緊急事態宣言期間中だったため、会社全体で原則、在宅勤務の体制となっており、対面でのコミュニケーションが希薄になりがちでしたが、朝会、夕会を含め、たとえ新卒から質問が無くても質問タイムでのミーティングは定期的に実施するなど、 できるだけ頻繁に顔合わせして、新卒本人の声と顔を確認する よう心がけました。 Issue へのアサインから始まって、実装 -> レビュー依頼 -> QA -> リリース -> Issue 起票者への報告まで、一連の開発フローを経験してもらい、チーム内での開発業務に慣れてもらうことができました。 フェーズ 4：最終報告 新卒研修最後のプログラムとして、メドレー役員陣に向けた最終報告会を実施しました。 最終報告会の目的としては、次の通りです。 学んだことの知識を深化させる 自らの得手・不得手を捉え、将来の成長計画を立てる 体系的に整理・文書化して他者へ伝えるスキルを向上させる 役員陣に向けてプレゼンすることで、本配属に向けた決意表明として区切りを付ける 役員陣への発表であることに加え、一人あたりの発表時間にも制限が設けられており、当日の緊張はかなりのものだったと思います。 前日に発表会場を下見して、リハーサルを入念に行うなど、当日の発表会を成功させるため、メドレーのエンジニアとしての自覚を持って、発表準備に取り組んでいました。 技術志向とプロダクト志向の両輪を目指すエンジニア募集中 メドレーの研修では、技術的な講義や実践だけで終わるのではなく、ビジネスパーソンとして必要な基礎も身につけ、なぜ開発するのかを追究し、プロダクトを通じた課題解決を実体験してもらうことを重視しています。 メドレーでは、医療ヘルスケア分野の課題解決に挑みたいエンジニアを募集しています。 新卒の学生に限らず、中途採用も行っているので、エンジニアの方で少しでも興味を持っていただけたら、是非、面談でお話ししましょう。 最後までお読みいただき、誠にありがとうございました。 P.S. 昨年、一昨年の新卒研修の様子はこちらより、それぞれご覧いただけます。 2020 年度新卒エンジニア研修について 2019 年度新卒エンジニア研修について 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。医療介護求人サイト「ジョブメドレー」の開発を担当しているエンジニアの山田です。 今年の新卒エンジニア研修において、メンターを担当しました。 メドレーでは 2019 年度から新卒採用を行なっており、今年 2021 年度は 5 名の新卒がエンジニアとして入社しました。 例年と同じく 4 月から 9 月にかけて、約 5 ヶ月間の新卒エンジニア研修を実施しましたので、その取り組みを、研修受講者である新卒からの声も交えてご紹介します。 新卒研修の概要 今年の新卒研修の最終ゴールは、「 メドレーのエンジニアとして、 Our Essentials (※) を体現し、顧客へ価値提供できるようになるための基礎を身につけ、経験を得ること 」として掲げました。 ※) メドレーの行動原則 メドレーの新卒エンジニア研修では、技術を身につけることだけではなく、ビジネスパーソンとしての基礎を身につけ、メドレーが大切にしている価値観を理解し、体現する意識をもって、顧客への価値提供について自分の言葉で話せるようになることまでを目指してもらいます。 研修は昨年同様、大きく分けて、4 つのフェーズに区切って行いました。 また、全研修期間を通じて、各新卒にはメンターを一人ずつ付けました。メンターは、一週間に 1~2 回のペースで新卒と 1on1 ミーティングを実施し、フィジカルとメンタルの両面を気遣い、個別にフォローを行いました。 新卒研修の内容 フェーズ 1：社会人&メドレー基礎研修 リスク研修 インサイダー取引防止研修 コンプライアンス研修 情報セキュリティ研修 ビジネス研修 ビジネスマナー研修 ビジネススキル研修 ビジネススタンス研修（外部研修） フェーズ 1 では、 成果を出し、価値を発揮するために必要なビジネスパーソンとしての基本的な仕事の型を身につけること をゴールとしました。 リスク研修では、メドレー社員として、社会人として、身の周りで起こりうるリスクについて考え、いかにそれらのリスクと向き合うかを講義形式で学んでもらいました。 ビジネス研修では、社会人としての最低限のマナーを学び、論理的思考力、コミュニケーション力など、エンジニア職に限らない課題解決力へつながるポータブルな知識を、座学とワークショップを通じて定着してもらうことを図りました。 また、社会人の基準で仕事と向き合い、適切な報連相によって周囲と協働していくことの重要性についても学んでもらいました。 新卒からの声 質の高い、多量のインプット・アウトプットができた 伝わるメールの書き方、名刺の渡し方など、社会人に必須のマナーやスキルを認識できた ワークを通じて、言葉では理解していても行動するとできないことを洗い出せた フェーズ 2：エンジニア基礎研修 開発基礎 1 メドレーエンジニアとして求めること 事業（ジョブメドレー ・ CLINICS ・介護のほんね）の概要説明 開発基礎研修（Ruby on Rails チュートリアル） 開発実践 （要件定義〜リリースまで） 開発基礎 2 技術書の輪読会 ドキュメンテーションスキル研修 プレゼンテーションスキル研修 中間レポート作成 中間報告会 フェーズ 2 では、新卒研修後に開発業務に入ってもらえるよう、 エンジニアとしての基礎を身につけること をゴールとしました。 メドレーエンジニアとして求めること 開発に関わるこのフェーズにおいても、要件定義を含む汎用的な技術的スキルは勿論のこと、メドレーエンジニアが共通して持つべき価値観などを共有するため、フェーズ 2 初日は「 メドレーエンジニアとして求めること 」と題して、エンジニアの執行役員 田中が講義を行いました。 講義では、「 エンジニア とは、 エンジニアの価値 とは、 プロエンジニア とはなんでしょうか？」という問いから始まり、講義の終わりにはもう一度同じ問いかけをして締めくくり、新卒がメドレーの求めるエンジニア像について自身の言葉で話せるように考えてもらいました。 メドレーが求めるエンジニア像については、CTO 平山の メドレー平山の中央突破: THE エンジニア にも書かれていますので、よろしければ、あわせてご覧ください。 さらに、メドレーが展開する各事業および関連するプロダクトの概要説明をプロダクトマネージャーが行い、メドレーで開発する意義をあらためて認識してもらいました。 開発基礎研修 2 日目より、 Ruby on Rails チュートリアル （以下、「Rails チュートリアル」）を教材とした、開発基礎研修に移りました。 メドレーのプロダクトは Rails で作られているものが多く、Web アプリケーションを開発するための基礎を身につけるためにも、Rails チュートリアルの内容を実施してもらいました。 単純に、Rails チュートリアルの内容に沿って、ダラダラと写経するのではなく、随時、学んだことは Confluence にまとめ、GitHub 上で Pull Request を作成する形で、ソースコードを共有してもらいました。 学んだことを自分の言葉に置き換えてアウトプットすることで反復学習を促し、Pull Request を作成してもらうことで GitHub の使い方に慣れてもらうことを図りました。 また、デイリーで朝会と夕会を実施しました。朝会は仕事のリズムを整えるための顔合わせ、夕会は新卒から質問・成果を共有してメンターがそれに対してフィードバックをする場としてそれぞれ実施しました。 研修前に既に Rails チュートリアルを一周していた新卒もいましたが、二周目を実施して新たな気付きを得たり、AWS を用いてクラウド上に環境構築し、作成した Web アプリケーションをデプロイするまでを実践してもらうなど、インフラに関しても理解を深めてもらうことができました。 新卒からの声 システムのパフォーマンスを上げるための工夫を知ることができた バグ発生〜原因特定〜修正、というデバッグのスピードが、研修序盤から飛躍的に上がった プロダクトで利用している AWS の各種サービスの概要を理解できたことに加え、サービス間の繋がりやネットワークの流れに関しても理解を深めることができた 開発実践 開発基礎研修にて Web アプリケーション開発の基礎を学んだ後は、「 メドレー/グループ会社で使う来訪者受付システム 」を開発題材として、開発実践研修を行いました。 開発業務全体の流れを把握することで、 チームで開発（課題解決）することを経験し、今後の仕事に役立たせること を目的としました。 本研修で達成すべきこととして掲げていたものは主に、次の通りです。 プロジェクト管理能力を身につけること 開発する対象を体系的に整理できる能力を養うこと システム設計に関する基礎的な物事を理解すること チーム開発を理解すること 品質を理解すること 既に決まりきった仕様書に沿って開発するのではなく、新卒自身が現状の問題把握や課題整理を行って、ユーザーへ価値提供するために何を作るべきかを考えることから始まり、リリース後の運用方法やランニングコストのことまで考え提案してもらいました。 開発実践研修は約 1 ヶ月の期間をかけて行いました。大まかな流れとしては、次の通りです。 要件定義（ヒアリング・現状把握・課題整理・要求分析・機能/非機能要件の洗い出し・ UI 草案） プロジェクト計画（役割分担・ WBS/ガントチャート作成） 設計（画面設計・機能設計・データモデリング・方式設計・インフラ設計） 開発（実装・コードレビュー） QA（テスト設計・テスト） 成果発表（成果物を関係者へプレゼン・リリース） 方式設計の一部として、開発に使用する言語などの選定も新卒自身が行いました。 今回作成した社員向け管理画面と来訪者向け画面はいずれも SPA（一部、PWA）のアーキテクチャを採用し、主なライブラリ/フレームワークに関して、フロントエンドは TypeScript , React , Next.js , Chakra UI , Ionic Framework 、バックエンドは Ruby on Rails（API モード）をそれぞれ利用することとなりました。 選定理由としては主に、次の通りです。 TypeScript, React（両画面共通） ロジックからテンプレートまでの全てのコードを静的型付けで書くことができ、堅牢性に優れているため Next.js, Chakra UI（社員向け管理画面） ゼロコンフィグでビルドやレンダリングを最適化できるため アクセシビリティに優れたリッチな UI を素早く構築できるため Ionic Framework（来訪者向け画面） iPad 上で、ネイティブアプリのような UI/UX を提供するため Ruby on Rails API モード フロントエンドとバックエンドを分離して疎結合にするため 短期間で構築するため 社内でもよく使われておりメンテナンスしやすいため インフラは AWS を採用し、EC2, S3, RDS, CloudFront, Route53, CloudWatch などのサービスを利用しました。 結果的に、本研修プログラムの成果物としてリリースされたシステムは「 Medley Entrance 」という名前で、社内ツールとして現在、毎日稼働しており、ユーザーとしてメドレー/グループ社員だけではなく、来訪者の方々にも使っていただいています。 Medley Entrance（上：社員向け管理画面、下：来訪者向け画面） チームで課題解決に臨み、価値提供までの実績を残せたことは自信につながり、開発実践研修のやりがいとして、感じてもらえたのではないでしょうか。 要件定義などの期間中、想定よりもスムーズに進められなかった時も他責にせず、各々がリーダーシップを発揮し、建設的に進めていく新卒の様子をメンターの一人として傍で見させてもらいました。 この 1 ヶ月間の開発実践研修を通じて、技術力はさることながら、課題解決に対する十分な熱意と主体性を新卒から感じられ、とても頼もしい印象として残りました。 新卒からの声 開発の中での方針を意識して設計/実装することができた(シンプルにする) QA とはそもそも何かというリサーチから入り、有識者の考え方を軸に方針を決めてから始められた 各々が最適なパフォーマンスを発揮できる環境づくりを意識して、高速な意思決定が可能な体制を整えることができた 要件が決まりきっていない中で設計するのは難しかった 開発タスクが集中していた時に、プロジェクト全体の現状を把握できていなかった 文章を作るスキルが足りていない 技術書の輪読会 フェーズ 2 の開発基礎 2 の輪読会では、 『Web を支える技術 -HTTP、URI、HTML、そして REST』 を題材書籍として、7 日間に渡って毎日、次の手順で実施しました。 参加者が同じパートをあらかじめ読んでおき、書籍から学んだこと、ネットなどで調べても解消しきれなかった疑問点などをまとめる その内容をもとに、夕方のミーティング時において、各自が発表してディスカッションを行う ディスカッションした内容は議事録にまとめる 輪読会は他者からの学びを共有してもらうことで、自分にはなかった視点・気付きを獲得し、その書籍への理解をより深められる効果があります。 本研修プログラムにおける輪読会の目的としては、 Web サービスを開発していく上で必要となる知識へ触れることにより、今後獲得していくべき知識のベースラインを理解すること でしたが、輪読会ならではのメリット・楽しさを新卒に実感してもらえたことも、副次的な効果としてあったと思います。 新卒からの声 Web の基本的な知識を「なぜ登場したのか」を理解しながら網羅的に学ぶことができた 文書でまとめた後に、口で説明することが学んだ内容の定着に良いと感じた これまでなんとなく実装していたことの仕組みを学ぶことで、知識として定着することができた 中間報告会 フェーズ 2：エンジニア基礎研修最後の研修プログラムである中間報告会に向けて、ドキュメンテーションスキル研修、プレゼンテーションスキル研修を実施しました。 上記スキルが必要となる背景は、次の通りです。 エンジニアリングを通じた課題解決とはプログラムを書くだけでは解決しない場面もある 背景、目的を正しくステークホルダーへ共有しながらチームとして取り組んでいくことになる 伝えたいことを文章として整理し、他者へ分かりやすく伝えていくことが求められる また、メドレーの行動原則 Our Essentials を構成する要素として、「ドキュメントドリブン」「全てを明確に」という項目が含まれており、これらを実現するためにも、とても重要なスキルとしてメドレーは考えています。 新卒研修が終わった後も、エンジニアとして技術的なスキルを身につける機会は日常的に多くありますが、上記のようなスキルをまとめて習得する機会は少ないため、このような研修を社会人のはじめから受けておくことで、その後の伸びしろが違ってくるのではないかと思います。 研修が終わった後は、各自で報告会用の資料を作成し、研修講師からの添削を受けました。 中間報告会は各部署の開発マネージャーを発表相手として、当日は程よい緊張感をもって、良い雰囲気で報告会を終えられました。 フェーズ 3：事業部 OJT 事業部研修 取締役豊田からの講義 CLINICS 事業部研修 ジョブメドレー事業部研修 開発 OJT システム全体像説明 環境構築 各プロダクトの開発チームでの OJT フェーズ 3 では、 顧客の課題と、顧客への価値提供のための各チームの連携を体感し、メドレーの顧客提供価値を自分の言葉で話せるようになること をゴールとしました。 フェーズ 3 のはじめに、取締役豊田による日本の医療の課題とメドレーの取り組みに関する講義を受講してもらいました。 持続可能な医療体制を構築していくためにメドレーが成すべきことなどの話を聞いた後に、新卒からの質問の受け答えによって理解を深め、メドレーの社会的意義をあらためて認識してもらい、エンジニアとしてだけではなく、 メドレー社員としての自覚 を強めてもらいました。 事業部研修 開発 OJT で手を動かす前に、自分たちが何のために開発するのかを具体的にイメージできるよう、次のように、各現場に参加してもらいました。 見込顧客への架電業務見学 商談前の社内ミーティング参加 商談現場同席 定例会議参加 事業部のスタッフが、顧客の課題に対して、どのような対応をしていて、どのようにプロダクトを説明しているのか、事業部の各チームが、どのように連携して最終的に顧客に価値を届けるのかの全体観を知ってもらうことを狙いとしていました。 開発チームのエンジニアは業務上、プロダクトのエンドユーザーである顧客の声などを商談のタイミングから聞ける機会はなかなか無いので、研修を通じて話を聞けたことは、今後の開発モチベーションにも影響する良い機会だったと思います。 新卒からの声 ユーザー、顧客、事業部が抱える課題を確認できたことで、開発以外にも目を向けるきっかけになり良かった 各部署が KPI として定めている数字を知ることができ、開発に降りてきている施策の影響箇所がどの部分かを理解できた上で、開発に取り組むことができるようになった 各部署のミーディングに参加することで、各部署がどのような考えで何を目指しているのかを理解でき、メドレー全体として目指している方向性が掴めた 開発 OJT 事業部研修に続く開発 OJT では、 ジョブメドレー 、 CLINICS 、 介護のほんね の開発チームに分かれて、研修を実施しました。 OJT 配属先では、メンターとは別に、トレーナーを付けて業務の進め方などをサポートしました。トレーナーは配属先の先輩エンジニアが担当しました。 OJT の流れとしては、初日に、プロダクトがどのように動いているのか、システム全体像を把握することから始まり、各自、ドキュメントに沿って、PC にローカル開発環境をセットアップしました。 その後は、他の先輩エンジニアと同様に、GitHub Issue で管理されている課題を解消することを日々の目標としてこなしてもらいました。ただし、単に Issue に書かれている課題をクリアしようとするのではなく、 そもそも、なぜそれをやるのか、Issue の背景や起票者の意図を十分に理解した上で、プロダクトのあるべき姿に導く ことを意識してもらいました。 Issue に書かれている内容の理解が不十分だったり、解決方針がうまく定まらない場合は随時、ミーティングの時間を設けて、Issue 起票者やトレーナーと認識合わせを行い、認識の相違から生まれるミスコミュニケーションを極力減らすよう、取り組みました。 技術的な質問に関しても、定期的に質問タイムを設けたり、複雑になりそうな実装や、つまずきポイントとなりそうな箇所に関しては、 画面共有を用いてレビュー を行い、疑問点に関してもその場で確認して、解消してもらいました。 緊急事態宣言期間中だったため、会社全体で原則、在宅勤務の体制となっており、対面でのコミュニケーションが希薄になりがちでしたが、朝会、夕会を含め、たとえ新卒から質問が無くても質問タイムでのミーティングは定期的に実施するなど、 できるだけ頻繁に顔合わせして、新卒本人の声と顔を確認する よう心がけました。 Issue へのアサインから始まって、実装 -> レビュー依頼 -> QA -> リリース -> Issue 起票者への報告まで、一連の開発フローを経験してもらい、チーム内での開発業務に慣れてもらうことができました。 フェーズ 4：最終報告 新卒研修最後のプログラムとして、メドレー役員陣に向けた最終報告会を実施しました。 最終報告会の目的としては、次の通りです。 学んだことの知識を深化させる 自らの得手・不得手を捉え、将来の成長計画を立てる 体系的に整理・文書化して他者へ伝えるスキルを向上させる 役員陣に向けてプレゼンすることで、本配属に向けた決意表明として区切りを付ける 役員陣への発表であることに加え、一人あたりの発表時間にも制限が設けられており、当日の緊張はかなりのものだったと思います。 前日に発表会場を下見して、リハーサルを入念に行うなど、当日の発表会を成功させるため、メドレーのエンジニアとしての自覚を持って、発表準備に取り組んでいました。 技術志向とプロダクト志向の両輪を目指すエンジニア募集中 メドレーの研修では、技術的な講義や実践だけで終わるのではなく、ビジネスパーソンとして必要な基礎も身につけ、なぜ開発するのかを追究し、プロダクトを通じた課題解決を実体験してもらうことを重視しています。 メドレーでは、医療ヘルスケア分野の課題解決に挑みたいエンジニアを募集しています。 新卒の学生に限らず、中途採用も行っているので、エンジニアの方で少しでも興味を持っていただけたら、是非、面談でお話ししましょう。 最後までお読みいただき、誠にありがとうございました。 P.S. 昨年、一昨年の新卒研修の様子はこちらより、それぞれご覧いただけます。 2020 年度新卒エンジニア研修について 2019 年度新卒エンジニア研修について 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめまして。メドレーのエンジニア熊本です。新卒で入社し今年で 3 年目になりまして、 2019 年度エンジニア新卒の研修 を終えてから早 2 年が経とうとしています。 そんな私ですが去年の 11 月頃から先月までの間、とあるプロジェクトのリーダーを任せてもらっていたので、そのお話をさせていただきます。 はじめに 私は新卒研修を終えてから医療介護求人サイト ジョブメドレー のチームで開発をしていましたが、そのジョブメドレーを支える社内管理システムのリニューアルプロジェクトに初期から携わっていました。 こちらのプロジェクトにつきましては、弊社デザイナーの酒井が デザイナーがデザインツールを使わずに、React を使ってデザインした話 を、弊社エンジニアの山田が GraphQL, TypeScript, React を用いて型安全に社内システムをリニューアルした話 を以前ブログにしていますので、よろしければあわせてご覧ください。 その社内管理システムをどのような流れでリニューアルし、その中で自分の役割がどう変化しどう対応したのかなどについて、次の章からお話ししていきます。 プロジェクトについて リニューアルの背景やシステムの概要については上に紹介した記事でも説明しているため割愛しますが、求職者や求人を掲載する顧客に関する業務を行っているシステムをおよそ 1 年半かけて刷新するという大きなプロジェクトでした。 システムの中でも求職者関連を「Phase1」、顧客関連を「Phase2」として分割し、リニューアルを進めました。 プロジェクト内での自分の役割の変遷 Phase1 の最初期は先輩方がアーキテクチャの設計やスケジューリングをしていました。当時まだ新卒 1 年目で未熟な私でしたが、権限管理のテーブル設計をするタスクをアサインしてもらいました。ここでは詳細を省きますが、初めてのテーブル設計で右も左も分からない状態から責任感を持って何とか形にすることができ、（もちろんリニューアル中に多少の見直しはありましたが）大きな達成感を得たことを覚えています。 各種設計、技術選定、開発の進め方などが大方固まり本格的に開発が始まるわけですが、Phase1 の際は先輩社員がプロジェクトリーダーとして引っ張っていただき、自分は開発メンバーの一員として API の作成などに奮闘していました。 GraphQL といった技術やスケジュールが厳密に引かれたプロジェクトでの開発など初めて経験することも多々ありましたが、先輩方にサポートをいただいたり、同期と切磋琢磨しながら取り組めたおかげで、Phase1 を乗り切ることができました。 さて、ここからが本題になりますが、Phase2 になるとプロジェクトメンバーの入れ替えや私自身の目標設定も重なり、プロジェクトリーダーを任せてもらうことになります。まずはプロジェクトリーダーに任命されてから、どういった仕事をしていたのかご紹介します。 プロジェクトリーダーの仕事 プロジェクトリーダーとして期待されていたことは以下の通りです。 プロジェクト管理 システム設計 開発 チームマネジメント これを更に細分化し、私の実業務と照らし合わせながら並べてみると、多少粒度にばらつきがあるかもしれませんが以下のようなことが挙げられます。 要件定義・画面設計（ディレクターとデザイナー主導で進めつつ、エンジニアも実データや既存ロジックを踏まえた観点を持ち合わせて参加しました） 開発方針の検討 開発タスクへの落とし込み 技術調査・選定 API 設計 工数算出・スケジューリング 実装・レビュー QA（Quality Assurance）テスト リリースマネジメント Phase2 は段階的にリリースを行ったため、その度に 1 から 9 までを繰り返していたような流れになります。また、上記に加え、定例ミーティングでの報告や開発メンバーのタスクマネジメントも随時行っていました。 もちろん苦労したことは多く、全部を挙げようとするとキリがないのですが、その中でもいくつかに絞った上で紹介したいと思います。 苦労と工夫 1. 「そもそも何をやればいいのか」 まず最初に苦労したことは「そもそも何をやればいいのかわからない」ということでした。初めから先ほど挙げたような動きをイメージできていたわけではなく、記事や本を読み漁ったり先輩との 1on1 で質問攻めにしたりと基本的な知識を叩き込むわけですが、実際にとった最初の動きとしては「できる部分を見つけてやっていく」ということだったと思います。 自分がリーダーに任命された時点でのプロジェクトの状況としては要件定義や画面設計が進んでいる最中でしたが、これらがまとまるのを待つのではなく「全部決まらないとやれないこと」と「現時点でやれること」を切り分けて動きました。こうしたところから少しずつリズムを作り、最終的に先ほど列挙したような一通りのことがイメージ・実行できるようになったのだと思います。 2. 工数見積もり 一般的に工数見積もりに関する記事は世の中に多く存在しますが、私の場合は工数見積もりの方法がわからなかったというよりも、「どういう思想で見積もったのか、どういう選択肢があるのか」を曖昧にしていたことが当初の問題でした。 初めて見積もった時は単に開発タスクを積み上げた工数を報告して満足してしまいましたが、様々な方のフィードバックを受けプロダクト価値を高めるためにどういう動きができるのかを考える必要があったことを痛感しました。単純に工数を積み上げる場合や事業的な都合を踏まえてミニマムで開発する場合など、いくつかの選択肢をそれぞれの軸で考える必要があったことを学びました（この時期は夜な夜な夢の中で工数見積もりをしていたのも今ではいい思い出です）。 3. 意思決定 これはいつになっても正解が存在する類のものではないのですが、特に意思決定には苦労しました。意思決定といっても開発方針から技術選定まで様々な粒度のものがありますが、特に最初から苦労したのは技術的な決定でした。 それまで先輩に頼ることの多かった私がプロジェクトリーダーになった直後から何もかもできるようになるわけではないことは明々白々ですが、「自分が決めないと」と焦ってしまっていた時期もあったと思います。 そこで一度立ち止まって意識したことは、「何ができて何ができないのかを他者に明示する」ことでした。はっきりと自分に足りていないことを他者に伝えることで、周りもサポートしやすくなると思いますし、自分自身なにがやれることなのか明確になるので単純なことですが効果的であったと思います。他にも開発メンバーの提案で、インセプションデッキを取り入れてみたことも効果的でした。 また、意思決定とは文脈が少し変わってきますが、モブプロやペアプロを実施してチーム力を高め属人化をなくしつつ開発効率を向上させる取り組みも、時間が経てば経つほど効果を実感できて良かったと思います。このようにアジャイル開発の手法からチームにフィットする手法をいくつか取り入れることもできました。 プロジェクトを通して成長したこと これまで小出しで色々とお話しさせていただきましたが、自分が特に成長したと感じていることをまとめさせていただきます。 一通りの経験を通して得られたリード力 「API 設計だけ」ではなく一通り全てを任せていただいたことはとても大きな経験になりました。初めて個人ではなくチーム・プロジェクト全体として効率が良くなる動きを考える経験もできたと思います。 技術力 もちろん実装を通じて得た技術は数えきれないほどありますが、その中でも特に責任を持って他者のコードをレビューしたり、自分が書くコードの影響範囲やスコープを意識し続けたことが大きな糧になっている気がします。 リスク管理力 スケジュール遅延のリスク、方向性がずれてしまうリスク、技術的なリスク、様々ありますがこれらのリスクヘッジを考える力がプロジェクトリーダーには必要です。 リスク管理において「先読みが大切」とよく言われますが、私の場合はある先輩社員から「常に 2 週間先を見据えておけ」という具体的な日数のアドバイスをいただきました。具体的にすることであらゆることが想像しやすくなりましたし、それを 1 年以上毎日意識し実行し続けたことが、プロジェクトをやり切ることができた要因にもなっていると思います。もちろんこの言葉は家宝にしようと思っています。 価値に対する視野 何よりも「プロダクトのユーザーに価値を提供すること」の意味を理解しました。ここまでに書いてきたようなスケジュール管理やリスク管理などは、あくまでプロジェクトを遂行する上で必要な仕事の一つでしかないはずです。プロジェクトを通してシステムを使っている社員、更にはその先の顧客・求職者へ如何に価値を提供できるか考えるべきですが、一時期は「どうやるのか・なにをやるのか」というプロジェクト自体を完遂させることしか考えられていない時期もありました。 視野が狭くなっていたことに周りからの指摘で気づくことができ、それ以降は「そもそも本当にこの機能はいるのか」などユーザーの立場からの観点も徐々に身に付けることができました。これがきっかけとなり、周りとも頻繁に「なぜやるのか」を議論できるようになったと思います。新卒 1 年目で口酸っぱく言われていた「目的意識」をようやく腹落ちさせ体現することができました。 最後に 最後となりますが、プロジェクトリーダーについて語ってきた私ですが、入社するまでは Web 開発未経験でして、メドレーでの成長を非常に実感しています。そんなメドレーではエンジニア・デザイナーをはじめ多くのポジションで新たなメンバーを募集していますので、少しでもご興味をお持ちいただけた方は、是非お気軽にお話しさせていただければと思います！ ここまでお付き合いいただき、ありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめまして。メドレーのエンジニア熊本です。新卒で入社し今年で 3 年目になりまして、 2019 年度エンジニア新卒の研修 を終えてから早 2 年が経とうとしています。 そんな私ですが去年の 11 月頃から先月までの間、とあるプロジェクトのリーダーを任せてもらっていたので、そのお話をさせていただきます。 はじめに 私は新卒研修を終えてから医療介護求人サイト ジョブメドレー のチームで開発をしていましたが、そのジョブメドレーを支える社内管理システムのリニューアルプロジェクトに初期から携わっていました。 こちらのプロジェクトにつきましては、弊社デザイナーの酒井が デザイナーがデザインツールを使わずに、React を使ってデザインした話 を、弊社エンジニアの山田が GraphQL, TypeScript, React を用いて型安全に社内システムをリニューアルした話 を以前ブログにしていますので、よろしければあわせてご覧ください。 その社内管理システムをどのような流れでリニューアルし、その中で自分の役割がどう変化しどう対応したのかなどについて、次の章からお話ししていきます。 プロジェクトについて リニューアルの背景やシステムの概要については上に紹介した記事でも説明しているため割愛しますが、求職者や求人を掲載する顧客に関する業務を行っているシステムをおよそ 1 年半かけて刷新するという大きなプロジェクトでした。 システムの中でも求職者関連を「Phase1」、顧客関連を「Phase2」として分割し、リニューアルを進めました。 プロジェクト内での自分の役割の変遷 Phase1 の最初期は先輩方がアーキテクチャの設計やスケジューリングをしていました。当時まだ新卒 1 年目で未熟な私でしたが、権限管理のテーブル設計をするタスクをアサインしてもらいました。ここでは詳細を省きますが、初めてのテーブル設計で右も左も分からない状態から責任感を持って何とか形にすることができ、（もちろんリニューアル中に多少の見直しはありましたが）大きな達成感を得たことを覚えています。 各種設計、技術選定、開発の進め方などが大方固まり本格的に開発が始まるわけですが、Phase1 の際は先輩社員がプロジェクトリーダーとして引っ張っていただき、自分は開発メンバーの一員として API の作成などに奮闘していました。 GraphQL といった技術やスケジュールが厳密に引かれたプロジェクトでの開発など初めて経験することも多々ありましたが、先輩方にサポートをいただいたり、同期と切磋琢磨しながら取り組めたおかげで、Phase1 を乗り切ることができました。 さて、ここからが本題になりますが、Phase2 になるとプロジェクトメンバーの入れ替えや私自身の目標設定も重なり、プロジェクトリーダーを任せてもらうことになります。まずはプロジェクトリーダーに任命されてから、どういった仕事をしていたのかご紹介します。 プロジェクトリーダーの仕事 プロジェクトリーダーとして期待されていたことは以下の通りです。 プロジェクト管理 システム設計 開発 チームマネジメント これを更に細分化し、私の実業務と照らし合わせながら並べてみると、多少粒度にばらつきがあるかもしれませんが以下のようなことが挙げられます。 要件定義・画面設計（ディレクターとデザイナー主導で進めつつ、エンジニアも実データや既存ロジックを踏まえた観点を持ち合わせて参加しました） 開発方針の検討 開発タスクへの落とし込み 技術調査・選定 API 設計 工数算出・スケジューリング 実装・レビュー QA（Quality Assurance）テスト リリースマネジメント Phase2 は段階的にリリースを行ったため、その度に 1 から 9 までを繰り返していたような流れになります。また、上記に加え、定例ミーティングでの報告や開発メンバーのタスクマネジメントも随時行っていました。 もちろん苦労したことは多く、全部を挙げようとするとキリがないのですが、その中でもいくつかに絞った上で紹介したいと思います。 苦労と工夫 1. 「そもそも何をやればいいのか」 まず最初に苦労したことは「そもそも何をやればいいのかわからない」ということでした。初めから先ほど挙げたような動きをイメージできていたわけではなく、記事や本を読み漁ったり先輩との 1on1 で質問攻めにしたりと基本的な知識を叩き込むわけですが、実際にとった最初の動きとしては「できる部分を見つけてやっていく」ということだったと思います。 自分がリーダーに任命された時点でのプロジェクトの状況としては要件定義や画面設計が進んでいる最中でしたが、これらがまとまるのを待つのではなく「全部決まらないとやれないこと」と「現時点でやれること」を切り分けて動きました。こうしたところから少しずつリズムを作り、最終的に先ほど列挙したような一通りのことがイメージ・実行できるようになったのだと思います。 2. 工数見積もり 一般的に工数見積もりに関する記事は世の中に多く存在しますが、私の場合は工数見積もりの方法がわからなかったというよりも、「どういう思想で見積もったのか、どういう選択肢があるのか」を曖昧にしていたことが当初の問題でした。 初めて見積もった時は単に開発タスクを積み上げた工数を報告して満足してしまいましたが、様々な方のフィードバックを受けプロダクト価値を高めるためにどういう動きができるのかを考える必要があったことを痛感しました。単純に工数を積み上げる場合や事業的な都合を踏まえてミニマムで開発する場合など、いくつかの選択肢をそれぞれの軸で考える必要があったことを学びました（この時期は夜な夜な夢の中で工数見積もりをしていたのも今ではいい思い出です）。 3. 意思決定 これはいつになっても正解が存在する類のものではないのですが、特に意思決定には苦労しました。意思決定といっても開発方針から技術選定まで様々な粒度のものがありますが、特に最初から苦労したのは技術的な決定でした。 それまで先輩に頼ることの多かった私がプロジェクトリーダーになった直後から何もかもできるようになるわけではないことは明々白々ですが、「自分が決めないと」と焦ってしまっていた時期もあったと思います。 そこで一度立ち止まって意識したことは、「何ができて何ができないのかを他者に明示する」ことでした。はっきりと自分に足りていないことを他者に伝えることで、周りもサポートしやすくなると思いますし、自分自身なにがやれることなのか明確になるので単純なことですが効果的であったと思います。他にも開発メンバーの提案で、インセプションデッキを取り入れてみたことも効果的でした。 また、意思決定とは文脈が少し変わってきますが、モブプロやペアプロを実施してチーム力を高め属人化をなくしつつ開発効率を向上させる取り組みも、時間が経てば経つほど効果を実感できて良かったと思います。このようにアジャイル開発の手法からチームにフィットする手法をいくつか取り入れることもできました。 プロジェクトを通して成長したこと これまで小出しで色々とお話しさせていただきましたが、自分が特に成長したと感じていることをまとめさせていただきます。 一通りの経験を通して得られたリード力 「API 設計だけ」ではなく一通り全てを任せていただいたことはとても大きな経験になりました。初めて個人ではなくチーム・プロジェクト全体として効率が良くなる動きを考える経験もできたと思います。 技術力 もちろん実装を通じて得た技術は数えきれないほどありますが、その中でも特に責任を持って他者のコードをレビューしたり、自分が書くコードの影響範囲やスコープを意識し続けたことが大きな糧になっている気がします。 リスク管理力 スケジュール遅延のリスク、方向性がずれてしまうリスク、技術的なリスク、様々ありますがこれらのリスクヘッジを考える力がプロジェクトリーダーには必要です。 リスク管理において「先読みが大切」とよく言われますが、私の場合はある先輩社員から「常に 2 週間先を見据えておけ」という具体的な日数のアドバイスをいただきました。具体的にすることであらゆることが想像しやすくなりましたし、それを 1 年以上毎日意識し実行し続けたことが、プロジェクトをやり切ることができた要因にもなっていると思います。もちろんこの言葉は家宝にしようと思っています。 価値に対する視野 何よりも「プロダクトのユーザーに価値を提供すること」の意味を理解しました。ここまでに書いてきたようなスケジュール管理やリスク管理などは、あくまでプロジェクトを遂行する上で必要な仕事の一つでしかないはずです。プロジェクトを通してシステムを使っている社員、更にはその先の顧客・求職者へ如何に価値を提供できるか考えるべきですが、一時期は「どうやるのか・なにをやるのか」というプロジェクト自体を完遂させることしか考えられていない時期もありました。 視野が狭くなっていたことに周りからの指摘で気づくことができ、それ以降は「そもそも本当にこの機能はいるのか」などユーザーの立場からの観点も徐々に身に付けることができました。これがきっかけとなり、周りとも頻繁に「なぜやるのか」を議論できるようになったと思います。新卒 1 年目で口酸っぱく言われていた「目的意識」をようやく腹落ちさせ体現することができました。 最後に 最後となりますが、プロジェクトリーダーについて語ってきた私ですが、入社するまでは Web 開発未経験でして、メドレーでの成長を非常に実感しています。そんなメドレーではエンジニア・デザイナーをはじめ多くのポジションで新たなメンバーを募集していますので、少しでもご興味をお持ちいただけた方は、是非お気軽にお話しさせていただければと思います！ ここまでお付き合いいただき、ありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめまして。メドレーのエンジニア熊本です。新卒で入社し今年で 3 年目になりまして、 2019 年度エンジニア新卒の研修 を終えてから早 2 年が経とうとしています。 そんな私ですが去年の 11 月頃から先月までの間、とあるプロジェクトのリーダーを任せてもらっていたので、そのお話をさせていただきます。 はじめに 私は新卒研修を終えてから医療介護求人サイト ジョブメドレー のチームで開発をしていましたが、そのジョブメドレーを支える社内管理システムのリニューアルプロジェクトに初期から携わっていました。 こちらのプロジェクトにつきましては、弊社デザイナーの酒井が デザイナーがデザインツールを使わずに、React を使ってデザインした話 を、弊社エンジニアの山田が GraphQL, TypeScript, React を用いて型安全に社内システムをリニューアルした話 を以前ブログにしていますので、よろしければあわせてご覧ください。 その社内管理システムをどのような流れでリニューアルし、その中で自分の役割がどう変化しどう対応したのかなどについて、次の章からお話ししていきます。 プロジェクトについて リニューアルの背景やシステムの概要については上に紹介した記事でも説明しているため割愛しますが、求職者や求人を掲載する顧客に関する業務を行っているシステムをおよそ 1 年半かけて刷新するという大きなプロジェクトでした。 システムの中でも求職者関連を「Phase1」、顧客関連を「Phase2」として分割し、リニューアルを進めました。 プロジェクト内での自分の役割の変遷 Phase1 の最初期は先輩方がアーキテクチャの設計やスケジューリングをしていました。当時まだ新卒 1 年目で未熟な私でしたが、権限管理のテーブル設計をするタスクをアサインしてもらいました。ここでは詳細を省きますが、初めてのテーブル設計で右も左も分からない状態から責任感を持って何とか形にすることができ、（もちろんリニューアル中に多少の見直しはありましたが）大きな達成感を得たことを覚えています。 各種設計、技術選定、開発の進め方などが大方固まり本格的に開発が始まるわけですが、Phase1 の際は先輩社員がプロジェクトリーダーとして引っ張っていただき、自分は開発メンバーの一員として API の作成などに奮闘していました。 GraphQL といった技術やスケジュールが厳密に引かれたプロジェクトでの開発など初めて経験することも多々ありましたが、先輩方にサポートをいただいたり、同期と切磋琢磨しながら取り組めたおかげで、Phase1 を乗り切ることができました。 さて、ここからが本題になりますが、Phase2 になるとプロジェクトメンバーの入れ替えや私自身の目標設定も重なり、プロジェクトリーダーを任せてもらうことになります。まずはプロジェクトリーダーに任命されてから、どういった仕事をしていたのかご紹介します。 プロジェクトリーダーの仕事 プロジェクトリーダーとして期待されていたことは以下の通りです。 プロジェクト管理 システム設計 開発 チームマネジメント これを更に細分化し、私の実業務と照らし合わせながら並べてみると、多少粒度にばらつきがあるかもしれませんが以下のようなことが挙げられます。 要件定義・画面設計（ディレクターとデザイナー主導で進めつつ、エンジニアも実データや既存ロジックを踏まえた観点を持ち合わせて参加しました） 開発方針の検討 開発タスクへの落とし込み 技術調査・選定 API 設計 工数算出・スケジューリング 実装・レビュー QA（Quality Assurance）テスト リリースマネジメント Phase2 は段階的にリリースを行ったため、その度に 1 から 9 までを繰り返していたような流れになります。また、上記に加え、定例ミーティングでの報告や開発メンバーのタスクマネジメントも随時行っていました。 もちろん苦労したことは多く、全部を挙げようとするとキリがないのですが、その中でもいくつかに絞った上で紹介したいと思います。 苦労と工夫 1. 「そもそも何をやればいいのか」 まず最初に苦労したことは「そもそも何をやればいいのかわからない」ということでした。初めから先ほど挙げたような動きをイメージできていたわけではなく、記事や本を読み漁ったり先輩との 1on1 で質問攻めにしたりと基本的な知識を叩き込むわけですが、実際にとった最初の動きとしては「できる部分を見つけてやっていく」ということだったと思います。 自分がリーダーに任命された時点でのプロジェクトの状況としては要件定義や画面設計が進んでいる最中でしたが、これらがまとまるのを待つのではなく「全部決まらないとやれないこと」と「現時点でやれること」を切り分けて動きました。こうしたところから少しずつリズムを作り、最終的に先ほど列挙したような一通りのことがイメージ・実行できるようになったのだと思います。 2. 工数見積もり 一般的に工数見積もりに関する記事は世の中に多く存在しますが、私の場合は工数見積もりの方法がわからなかったというよりも、「どういう思想で見積もったのか、どういう選択肢があるのか」を曖昧にしていたことが当初の問題でした。 初めて見積もった時は単に開発タスクを積み上げた工数を報告して満足してしまいましたが、様々な方のフィードバックを受けプロダクト価値を高めるためにどういう動きができるのかを考える必要があったことを痛感しました。単純に工数を積み上げる場合や事業的な都合を踏まえてミニマムで開発する場合など、いくつかの選択肢をそれぞれの軸で考える必要があったことを学びました（この時期は夜な夜な夢の中で工数見積もりをしていたのも今ではいい思い出です）。 3. 意思決定 これはいつになっても正解が存在する類のものではないのですが、特に意思決定には苦労しました。意思決定といっても開発方針から技術選定まで様々な粒度のものがありますが、特に最初から苦労したのは技術的な決定でした。 それまで先輩に頼ることの多かった私がプロジェクトリーダーになった直後から何もかもできるようになるわけではないことは明々白々ですが、「自分が決めないと」と焦ってしまっていた時期もあったと思います。 そこで一度立ち止まって意識したことは、「何ができて何ができないのかを他者に明示する」ことでした。はっきりと自分に足りていないことを他者に伝えることで、周りもサポートしやすくなると思いますし、自分自身なにがやれることなのか明確になるので単純なことですが効果的であったと思います。他にも開発メンバーの提案で、インセプションデッキを取り入れてみたことも効果的でした。 また、意思決定とは文脈が少し変わってきますが、モブプロやペアプロを実施してチーム力を高め属人化をなくしつつ開発効率を向上させる取り組みも、時間が経てば経つほど効果を実感できて良かったと思います。このようにアジャイル開発の手法からチームにフィットする手法をいくつか取り入れることもできました。 プロジェクトを通して成長したこと これまで小出しで色々とお話しさせていただきましたが、自分が特に成長したと感じていることをまとめさせていただきます。 一通りの経験を通して得られたリード力 「API 設計だけ」ではなく一通り全てを任せていただいたことはとても大きな経験になりました。初めて個人ではなくチーム・プロジェクト全体として効率が良くなる動きを考える経験もできたと思います。 技術力 もちろん実装を通じて得た技術は数えきれないほどありますが、その中でも特に責任を持って他者のコードをレビューしたり、自分が書くコードの影響範囲やスコープを意識し続けたことが大きな糧になっている気がします。 リスク管理力 スケジュール遅延のリスク、方向性がずれてしまうリスク、技術的なリスク、様々ありますがこれらのリスクヘッジを考える力がプロジェクトリーダーには必要です。 リスク管理において「先読みが大切」とよく言われますが、私の場合はある先輩社員から「常に 2 週間先を見据えておけ」という具体的な日数のアドバイスをいただきました。具体的にすることであらゆることが想像しやすくなりましたし、それを 1 年以上毎日意識し実行し続けたことが、プロジェクトをやり切ることができた要因にもなっていると思います。もちろんこの言葉は家宝にしようと思っています。 価値に対する視野 何よりも「プロダクトのユーザーに価値を提供すること」の意味を理解しました。ここまでに書いてきたようなスケジュール管理やリスク管理などは、あくまでプロジェクトを遂行する上で必要な仕事の一つでしかないはずです。プロジェクトを通してシステムを使っている社員、更にはその先の顧客・求職者へ如何に価値を提供できるか考えるべきですが、一時期は「どうやるのか・なにをやるのか」というプロジェクト自体を完遂させることしか考えられていない時期もありました。 視野が狭くなっていたことに周りからの指摘で気づくことができ、それ以降は「そもそも本当にこの機能はいるのか」などユーザーの立場からの観点も徐々に身に付けることができました。これがきっかけとなり、周りとも頻繁に「なぜやるのか」を議論できるようになったと思います。新卒 1 年目で口酸っぱく言われていた「目的意識」をようやく腹落ちさせ体現することができました。 最後に 最後となりますが、プロジェクトリーダーについて語ってきた私ですが、入社するまでは Web 開発未経験でして、メドレーでの成長を非常に実感しています。そんなメドレーではエンジニア・デザイナーをはじめ多くのポジションで新たなメンバーを募集していますので、少しでもご興味をお持ちいただけた方は、是非お気軽にお話しさせていただければと思います！ ここまでお付き合いいただき、ありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめまして。メドレーのエンジニア熊本です。新卒で入社し今年で 3 年目になりまして、 2019 年度エンジニア新卒の研修 を終えてから早 2 年が経とうとしています。 そんな私ですが去年の 11 月頃から先月までの間、とあるプロジェクトのリーダーを任せてもらっていたので、そのお話をさせていただきます。 はじめに 私は新卒研修を終えてから医療介護求人サイト ジョブメドレー のチームで開発をしていましたが、そのジョブメドレーを支える社内管理システムのリニューアルプロジェクトに初期から携わっていました。 こちらのプロジェクトにつきましては、弊社デザイナーの酒井が デザイナーがデザインツールを使わずに、React を使ってデザインした話 を、弊社エンジニアの山田が GraphQL, TypeScript, React を用いて型安全に社内システムをリニューアルした話 を以前ブログにしていますので、よろしければあわせてご覧ください。 その社内管理システムをどのような流れでリニューアルし、その中で自分の役割がどう変化しどう対応したのかなどについて、次の章からお話ししていきます。 プロジェクトについて リニューアルの背景やシステムの概要については上に紹介した記事でも説明しているため割愛しますが、求職者や求人を掲載する顧客に関する業務を行っているシステムをおよそ 1 年半かけて刷新するという大きなプロジェクトでした。 システムの中でも求職者関連を「Phase1」、顧客関連を「Phase2」として分割し、リニューアルを進めました。 プロジェクト内での自分の役割の変遷 Phase1 の最初期は先輩方がアーキテクチャの設計やスケジューリングをしていました。当時まだ新卒 1 年目で未熟な私でしたが、権限管理のテーブル設計をするタスクをアサインしてもらいました。ここでは詳細を省きますが、初めてのテーブル設計で右も左も分からない状態から責任感を持って何とか形にすることができ、（もちろんリニューアル中に多少の見直しはありましたが）大きな達成感を得たことを覚えています。 各種設計、技術選定、開発の進め方などが大方固まり本格的に開発が始まるわけですが、Phase1 の際は先輩社員がプロジェクトリーダーとして引っ張っていただき、自分は開発メンバーの一員として API の作成などに奮闘していました。 GraphQL といった技術やスケジュールが厳密に引かれたプロジェクトでの開発など初めて経験することも多々ありましたが、先輩方にサポートをいただいたり、同期と切磋琢磨しながら取り組めたおかげで、Phase1 を乗り切ることができました。 さて、ここからが本題になりますが、Phase2 になるとプロジェクトメンバーの入れ替えや私自身の目標設定も重なり、プロジェクトリーダーを任せてもらうことになります。まずはプロジェクトリーダーに任命されてから、どういった仕事をしていたのかご紹介します。 プロジェクトリーダーの仕事 プロジェクトリーダーとして期待されていたことは以下の通りです。 プロジェクト管理 システム設計 開発 チームマネジメント これを更に細分化し、私の実業務と照らし合わせながら並べてみると、多少粒度にばらつきがあるかもしれませんが以下のようなことが挙げられます。 要件定義・画面設計（ディレクターとデザイナー主導で進めつつ、エンジニアも実データや既存ロジックを踏まえた観点を持ち合わせて参加しました） 開発方針の検討 開発タスクへの落とし込み 技術調査・選定 API 設計 工数算出・スケジューリング 実装・レビュー QA（Quality Assurance）テスト リリースマネジメント Phase2 は段階的にリリースを行ったため、その度に 1 から 9 までを繰り返していたような流れになります。また、上記に加え、定例ミーティングでの報告や開発メンバーのタスクマネジメントも随時行っていました。 もちろん苦労したことは多く、全部を挙げようとするとキリがないのですが、その中でもいくつかに絞った上で紹介したいと思います。 苦労と工夫 1. 「そもそも何をやればいいのか」 まず最初に苦労したことは「そもそも何をやればいいのかわからない」ということでした。初めから先ほど挙げたような動きをイメージできていたわけではなく、記事や本を読み漁ったり先輩との 1on1 で質問攻めにしたりと基本的な知識を叩き込むわけですが、実際にとった最初の動きとしては「できる部分を見つけてやっていく」ということだったと思います。 自分がリーダーに任命された時点でのプロジェクトの状況としては要件定義や画面設計が進んでいる最中でしたが、これらがまとまるのを待つのではなく「全部決まらないとやれないこと」と「現時点でやれること」を切り分けて動きました。こうしたところから少しずつリズムを作り、最終的に先ほど列挙したような一通りのことがイメージ・実行できるようになったのだと思います。 2. 工数見積もり 一般的に工数見積もりに関する記事は世の中に多く存在しますが、私の場合は工数見積もりの方法がわからなかったというよりも、「どういう思想で見積もったのか、どういう選択肢があるのか」を曖昧にしていたことが当初の問題でした。 初めて見積もった時は単に開発タスクを積み上げた工数を報告して満足してしまいましたが、様々な方のフィードバックを受けプロダクト価値を高めるためにどういう動きができるのかを考える必要があったことを痛感しました。単純に工数を積み上げる場合や事業的な都合を踏まえてミニマムで開発する場合など、いくつかの選択肢をそれぞれの軸で考える必要があったことを学びました（この時期は夜な夜な夢の中で工数見積もりをしていたのも今ではいい思い出です）。 3. 意思決定 これはいつになっても正解が存在する類のものではないのですが、特に意思決定には苦労しました。意思決定といっても開発方針から技術選定まで様々な粒度のものがありますが、特に最初から苦労したのは技術的な決定でした。 それまで先輩に頼ることの多かった私がプロジェクトリーダーになった直後から何もかもできるようになるわけではないことは明々白々ですが、「自分が決めないと」と焦ってしまっていた時期もあったと思います。 そこで一度立ち止まって意識したことは、「何ができて何ができないのかを他者に明示する」ことでした。はっきりと自分に足りていないことを他者に伝えることで、周りもサポートしやすくなると思いますし、自分自身なにがやれることなのか明確になるので単純なことですが効果的であったと思います。他にも開発メンバーの提案で、インセプションデッキを取り入れてみたことも効果的でした。 また、意思決定とは文脈が少し変わってきますが、モブプロやペアプロを実施してチーム力を高め属人化をなくしつつ開発効率を向上させる取り組みも、時間が経てば経つほど効果を実感できて良かったと思います。このようにアジャイル開発の手法からチームにフィットする手法をいくつか取り入れることもできました。 プロジェクトを通して成長したこと これまで小出しで色々とお話しさせていただきましたが、自分が特に成長したと感じていることをまとめさせていただきます。 一通りの経験を通して得られたリード力 「API 設計だけ」ではなく一通り全てを任せていただいたことはとても大きな経験になりました。初めて個人ではなくチーム・プロジェクト全体として効率が良くなる動きを考える経験もできたと思います。 技術力 もちろん実装を通じて得た技術は数えきれないほどありますが、その中でも特に責任を持って他者のコードをレビューしたり、自分が書くコードの影響範囲やスコープを意識し続けたことが大きな糧になっている気がします。 リスク管理力 スケジュール遅延のリスク、方向性がずれてしまうリスク、技術的なリスク、様々ありますがこれらのリスクヘッジを考える力がプロジェクトリーダーには必要です。 リスク管理において「先読みが大切」とよく言われますが、私の場合はある先輩社員から「常に 2 週間先を見据えておけ」という具体的な日数のアドバイスをいただきました。具体的にすることであらゆることが想像しやすくなりましたし、それを 1 年以上毎日意識し実行し続けたことが、プロジェクトをやり切ることができた要因にもなっていると思います。もちろんこの言葉は家宝にしようと思っています。 価値に対する視野 何よりも「プロダクトのユーザーに価値を提供すること」の意味を理解しました。ここまでに書いてきたようなスケジュール管理やリスク管理などは、あくまでプロジェクトを遂行する上で必要な仕事の一つでしかないはずです。プロジェクトを通してシステムを使っている社員、更にはその先の顧客・求職者へ如何に価値を提供できるか考えるべきですが、一時期は「どうやるのか・なにをやるのか」というプロジェクト自体を完遂させることしか考えられていない時期もありました。 視野が狭くなっていたことに周りからの指摘で気づくことができ、それ以降は「そもそも本当にこの機能はいるのか」などユーザーの立場からの観点も徐々に身に付けることができました。これがきっかけとなり、周りとも頻繁に「なぜやるのか」を議論できるようになったと思います。新卒 1 年目で口酸っぱく言われていた「目的意識」をようやく腹落ちさせ体現することができました。 最後に 最後となりますが、プロジェクトリーダーについて語ってきた私ですが、入社するまでは Web 開発未経験でして、メドレーでの成長を非常に実感しています。そんなメドレーではエンジニア・デザイナーをはじめ多くのポジションで新たなメンバーを募集していますので、少しでもご興味をお持ちいただけた方は、是非お気軽にお話しさせていただければと思います！ ここまでお付き合いいただき、ありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめまして。メドレーのエンジニア熊本です。新卒で入社し今年で 3 年目になりまして、 2019 年度エンジニア新卒の研修 を終えてから早 2 年が経とうとしています。 そんな私ですが去年の 11 月頃から先月までの間、とあるプロジェクトのリーダーを任せてもらっていたので、そのお話をさせていただきます。 はじめに 私は新卒研修を終えてから医療介護求人サイト ジョブメドレー のチームで開発をしていましたが、そのジョブメドレーを支える社内管理システムのリニューアルプロジェクトに初期から携わっていました。 こちらのプロジェクトにつきましては、弊社デザイナーの酒井が デザイナーがデザインツールを使わずに、React を使ってデザインした話 を、弊社エンジニアの山田が GraphQL, TypeScript, React を用いて型安全に社内システムをリニューアルした話 を以前ブログにしていますので、よろしければあわせてご覧ください。 その社内管理システムをどのような流れでリニューアルし、その中で自分の役割がどう変化しどう対応したのかなどについて、次の章からお話ししていきます。 プロジェクトについて リニューアルの背景やシステムの概要については上に紹介した記事でも説明しているため割愛しますが、求職者や求人を掲載する顧客に関する業務を行っているシステムをおよそ 1 年半かけて刷新するという大きなプロジェクトでした。 システムの中でも求職者関連を「Phase1」、顧客関連を「Phase2」として分割し、リニューアルを進めました。 プロジェクト内での自分の役割の変遷 Phase1 の最初期は先輩方がアーキテクチャの設計やスケジューリングをしていました。当時まだ新卒 1 年目で未熟な私でしたが、権限管理のテーブル設計をするタスクをアサインしてもらいました。ここでは詳細を省きますが、初めてのテーブル設計で右も左も分からない状態から責任感を持って何とか形にすることができ、（もちろんリニューアル中に多少の見直しはありましたが）大きな達成感を得たことを覚えています。 各種設計、技術選定、開発の進め方などが大方固まり本格的に開発が始まるわけですが、Phase1 の際は先輩社員がプロジェクトリーダーとして引っ張っていただき、自分は開発メンバーの一員として API の作成などに奮闘していました。 GraphQL といった技術やスケジュールが厳密に引かれたプロジェクトでの開発など初めて経験することも多々ありましたが、先輩方にサポートをいただいたり、同期と切磋琢磨しながら取り組めたおかげで、Phase1 を乗り切ることができました。 さて、ここからが本題になりますが、Phase2 になるとプロジェクトメンバーの入れ替えや私自身の目標設定も重なり、プロジェクトリーダーを任せてもらうことになります。まずはプロジェクトリーダーに任命されてから、どういった仕事をしていたのかご紹介します。 プロジェクトリーダーの仕事 プロジェクトリーダーとして期待されていたことは以下の通りです。 プロジェクト管理 システム設計 開発 チームマネジメント これを更に細分化し、私の実業務と照らし合わせながら並べてみると、多少粒度にばらつきがあるかもしれませんが以下のようなことが挙げられます。 要件定義・画面設計（ディレクターとデザイナー主導で進めつつ、エンジニアも実データや既存ロジックを踏まえた観点を持ち合わせて参加しました） 開発方針の検討 開発タスクへの落とし込み 技術調査・選定 API 設計 工数算出・スケジューリング 実装・レビュー QA（Quality Assurance）テスト リリースマネジメント Phase2 は段階的にリリースを行ったため、その度に 1 から 9 までを繰り返していたような流れになります。また、上記に加え、定例ミーティングでの報告や開発メンバーのタスクマネジメントも随時行っていました。 もちろん苦労したことは多く、全部を挙げようとするとキリがないのですが、その中でもいくつかに絞った上で紹介したいと思います。 苦労と工夫 1. 「そもそも何をやればいいのか」 まず最初に苦労したことは「そもそも何をやればいいのかわからない」ということでした。初めから先ほど挙げたような動きをイメージできていたわけではなく、記事や本を読み漁ったり先輩との 1on1 で質問攻めにしたりと基本的な知識を叩き込むわけですが、実際にとった最初の動きとしては「できる部分を見つけてやっていく」ということだったと思います。 自分がリーダーに任命された時点でのプロジェクトの状況としては要件定義や画面設計が進んでいる最中でしたが、これらがまとまるのを待つのではなく「全部決まらないとやれないこと」と「現時点でやれること」を切り分けて動きました。こうしたところから少しずつリズムを作り、最終的に先ほど列挙したような一通りのことがイメージ・実行できるようになったのだと思います。 2. 工数見積もり 一般的に工数見積もりに関する記事は世の中に多く存在しますが、私の場合は工数見積もりの方法がわからなかったというよりも、「どういう思想で見積もったのか、どういう選択肢があるのか」を曖昧にしていたことが当初の問題でした。 初めて見積もった時は単に開発タスクを積み上げた工数を報告して満足してしまいましたが、様々な方のフィードバックを受けプロダクト価値を高めるためにどういう動きができるのかを考える必要があったことを痛感しました。単純に工数を積み上げる場合や事業的な都合を踏まえてミニマムで開発する場合など、いくつかの選択肢をそれぞれの軸で考える必要があったことを学びました（この時期は夜な夜な夢の中で工数見積もりをしていたのも今ではいい思い出です）。 3. 意思決定 これはいつになっても正解が存在する類のものではないのですが、特に意思決定には苦労しました。意思決定といっても開発方針から技術選定まで様々な粒度のものがありますが、特に最初から苦労したのは技術的な決定でした。 それまで先輩に頼ることの多かった私がプロジェクトリーダーになった直後から何もかもできるようになるわけではないことは明々白々ですが、「自分が決めないと」と焦ってしまっていた時期もあったと思います。 そこで一度立ち止まって意識したことは、「何ができて何ができないのかを他者に明示する」ことでした。はっきりと自分に足りていないことを他者に伝えることで、周りもサポートしやすくなると思いますし、自分自身なにがやれることなのか明確になるので単純なことですが効果的であったと思います。他にも開発メンバーの提案で、インセプションデッキを取り入れてみたことも効果的でした。 また、意思決定とは文脈が少し変わってきますが、モブプロやペアプロを実施してチーム力を高め属人化をなくしつつ開発効率を向上させる取り組みも、時間が経てば経つほど効果を実感できて良かったと思います。このようにアジャイル開発の手法からチームにフィットする手法をいくつか取り入れることもできました。 プロジェクトを通して成長したこと これまで小出しで色々とお話しさせていただきましたが、自分が特に成長したと感じていることをまとめさせていただきます。 一通りの経験を通して得られたリード力 「API 設計だけ」ではなく一通り全てを任せていただいたことはとても大きな経験になりました。初めて個人ではなくチーム・プロジェクト全体として効率が良くなる動きを考える経験もできたと思います。 技術力 もちろん実装を通じて得た技術は数えきれないほどありますが、その中でも特に責任を持って他者のコードをレビューしたり、自分が書くコードの影響範囲やスコープを意識し続けたことが大きな糧になっている気がします。 リスク管理力 スケジュール遅延のリスク、方向性がずれてしまうリスク、技術的なリスク、様々ありますがこれらのリスクヘッジを考える力がプロジェクトリーダーには必要です。 リスク管理において「先読みが大切」とよく言われますが、私の場合はある先輩社員から「常に 2 週間先を見据えておけ」という具体的な日数のアドバイスをいただきました。具体的にすることであらゆることが想像しやすくなりましたし、それを 1 年以上毎日意識し実行し続けたことが、プロジェクトをやり切ることができた要因にもなっていると思います。もちろんこの言葉は家宝にしようと思っています。 価値に対する視野 何よりも「プロダクトのユーザーに価値を提供すること」の意味を理解しました。ここまでに書いてきたようなスケジュール管理やリスク管理などは、あくまでプロジェクトを遂行する上で必要な仕事の一つでしかないはずです。プロジェクトを通してシステムを使っている社員、更にはその先の顧客・求職者へ如何に価値を提供できるか考えるべきですが、一時期は「どうやるのか・なにをやるのか」というプロジェクト自体を完遂させることしか考えられていない時期もありました。 視野が狭くなっていたことに周りからの指摘で気づくことができ、それ以降は「そもそも本当にこの機能はいるのか」などユーザーの立場からの観点も徐々に身に付けることができました。これがきっかけとなり、周りとも頻繁に「なぜやるのか」を議論できるようになったと思います。新卒 1 年目で口酸っぱく言われていた「目的意識」をようやく腹落ちさせ体現することができました。 最後に 最後となりますが、プロジェクトリーダーについて語ってきた私ですが、入社するまでは Web 開発未経験でして、メドレーでの成長を非常に実感しています。そんなメドレーではエンジニア・デザイナーをはじめ多くのポジションで新たなメンバーを募集していますので、少しでもご興味をお持ちいただけた方は、是非お気軽にお話しさせていただければと思います！ ここまでお付き合いいただき、ありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめまして。メドレーのエンジニア熊本です。新卒で入社し今年で 3 年目になりまして、 2019 年度エンジニア新卒の研修 を終えてから早 2 年が経とうとしています。 そんな私ですが去年の 11 月頃から先月までの間、とあるプロジェクトのリーダーを任せてもらっていたので、そのお話をさせていただきます。 はじめに 私は新卒研修を終えてから医療介護求人サイト ジョブメドレー のチームで開発をしていましたが、そのジョブメドレーを支える社内管理システムのリニューアルプロジェクトに初期から携わっていました。 こちらのプロジェクトにつきましては、弊社デザイナーの酒井が デザイナーがデザインツールを使わずに、React を使ってデザインした話 を、弊社エンジニアの山田が GraphQL, TypeScript, React を用いて型安全に社内システムをリニューアルした話 を以前ブログにしていますので、よろしければあわせてご覧ください。 その社内管理システムをどのような流れでリニューアルし、その中で自分の役割がどう変化しどう対応したのかなどについて、次の章からお話ししていきます。 プロジェクトについて リニューアルの背景やシステムの概要については上に紹介した記事でも説明しているため割愛しますが、求職者や求人を掲載する顧客に関する業務を行っているシステムをおよそ 1 年半かけて刷新するという大きなプロジェクトでした。 システムの中でも求職者関連を「Phase1」、顧客関連を「Phase2」として分割し、リニューアルを進めました。 プロジェクト内での自分の役割の変遷 Phase1 の最初期は先輩方がアーキテクチャの設計やスケジューリングをしていました。当時まだ新卒 1 年目で未熟な私でしたが、権限管理のテーブル設計をするタスクをアサインしてもらいました。ここでは詳細を省きますが、初めてのテーブル設計で右も左も分からない状態から責任感を持って何とか形にすることができ、（もちろんリニューアル中に多少の見直しはありましたが）大きな達成感を得たことを覚えています。 各種設計、技術選定、開発の進め方などが大方固まり本格的に開発が始まるわけですが、Phase1 の際は先輩社員がプロジェクトリーダーとして引っ張っていただき、自分は開発メンバーの一員として API の作成などに奮闘していました。 GraphQL といった技術やスケジュールが厳密に引かれたプロジェクトでの開発など初めて経験することも多々ありましたが、先輩方にサポートをいただいたり、同期と切磋琢磨しながら取り組めたおかげで、Phase1 を乗り切ることができました。 さて、ここからが本題になりますが、Phase2 になるとプロジェクトメンバーの入れ替えや私自身の目標設定も重なり、プロジェクトリーダーを任せてもらうことになります。まずはプロジェクトリーダーに任命されてから、どういった仕事をしていたのかご紹介します。 プロジェクトリーダーの仕事 プロジェクトリーダーとして期待されていたことは以下の通りです。 プロジェクト管理 システム設計 開発 チームマネジメント これを更に細分化し、私の実業務と照らし合わせながら並べてみると、多少粒度にばらつきがあるかもしれませんが以下のようなことが挙げられます。 要件定義・画面設計（ディレクターとデザイナー主導で進めつつ、エンジニアも実データや既存ロジックを踏まえた観点を持ち合わせて参加しました） 開発方針の検討 開発タスクへの落とし込み 技術調査・選定 API 設計 工数算出・スケジューリング 実装・レビュー QA（Quality Assurance）テスト リリースマネジメント Phase2 は段階的にリリースを行ったため、その度に 1 から 9 までを繰り返していたような流れになります。また、上記に加え、定例ミーティングでの報告や開発メンバーのタスクマネジメントも随時行っていました。 もちろん苦労したことは多く、全部を挙げようとするとキリがないのですが、その中でもいくつかに絞った上で紹介したいと思います。 苦労と工夫 1. 「そもそも何をやればいいのか」 まず最初に苦労したことは「そもそも何をやればいいのかわからない」ということでした。初めから先ほど挙げたような動きをイメージできていたわけではなく、記事や本を読み漁ったり先輩との 1on1 で質問攻めにしたりと基本的な知識を叩き込むわけですが、実際にとった最初の動きとしては「できる部分を見つけてやっていく」ということだったと思います。 自分がリーダーに任命された時点でのプロジェクトの状況としては要件定義や画面設計が進んでいる最中でしたが、これらがまとまるのを待つのではなく「全部決まらないとやれないこと」と「現時点でやれること」を切り分けて動きました。こうしたところから少しずつリズムを作り、最終的に先ほど列挙したような一通りのことがイメージ・実行できるようになったのだと思います。 2. 工数見積もり 一般的に工数見積もりに関する記事は世の中に多く存在しますが、私の場合は工数見積もりの方法がわからなかったというよりも、「どういう思想で見積もったのか、どういう選択肢があるのか」を曖昧にしていたことが当初の問題でした。 初めて見積もった時は単に開発タスクを積み上げた工数を報告して満足してしまいましたが、様々な方のフィードバックを受けプロダクト価値を高めるためにどういう動きができるのかを考える必要があったことを痛感しました。単純に工数を積み上げる場合や事業的な都合を踏まえてミニマムで開発する場合など、いくつかの選択肢をそれぞれの軸で考える必要があったことを学びました（この時期は夜な夜な夢の中で工数見積もりをしていたのも今ではいい思い出です）。 3. 意思決定 これはいつになっても正解が存在する類のものではないのですが、特に意思決定には苦労しました。意思決定といっても開発方針から技術選定まで様々な粒度のものがありますが、特に最初から苦労したのは技術的な決定でした。 それまで先輩に頼ることの多かった私がプロジェクトリーダーになった直後から何もかもできるようになるわけではないことは明々白々ですが、「自分が決めないと」と焦ってしまっていた時期もあったと思います。 そこで一度立ち止まって意識したことは、「何ができて何ができないのかを他者に明示する」ことでした。はっきりと自分に足りていないことを他者に伝えることで、周りもサポートしやすくなると思いますし、自分自身なにがやれることなのか明確になるので単純なことですが効果的であったと思います。他にも開発メンバーの提案で、インセプションデッキを取り入れてみたことも効果的でした。 また、意思決定とは文脈が少し変わってきますが、モブプロやペアプロを実施してチーム力を高め属人化をなくしつつ開発効率を向上させる取り組みも、時間が経てば経つほど効果を実感できて良かったと思います。このようにアジャイル開発の手法からチームにフィットする手法をいくつか取り入れることもできました。 プロジェクトを通して成長したこと これまで小出しで色々とお話しさせていただきましたが、自分が特に成長したと感じていることをまとめさせていただきます。 一通りの経験を通して得られたリード力 「API 設計だけ」ではなく一通り全てを任せていただいたことはとても大きな経験になりました。初めて個人ではなくチーム・プロジェクト全体として効率が良くなる動きを考える経験もできたと思います。 技術力 もちろん実装を通じて得た技術は数えきれないほどありますが、その中でも特に責任を持って他者のコードをレビューしたり、自分が書くコードの影響範囲やスコープを意識し続けたことが大きな糧になっている気がします。 リスク管理力 スケジュール遅延のリスク、方向性がずれてしまうリスク、技術的なリスク、様々ありますがこれらのリスクヘッジを考える力がプロジェクトリーダーには必要です。 リスク管理において「先読みが大切」とよく言われますが、私の場合はある先輩社員から「常に 2 週間先を見据えておけ」という具体的な日数のアドバイスをいただきました。具体的にすることであらゆることが想像しやすくなりましたし、それを 1 年以上毎日意識し実行し続けたことが、プロジェクトをやり切ることができた要因にもなっていると思います。もちろんこの言葉は家宝にしようと思っています。 価値に対する視野 何よりも「プロダクトのユーザーに価値を提供すること」の意味を理解しました。ここまでに書いてきたようなスケジュール管理やリスク管理などは、あくまでプロジェクトを遂行する上で必要な仕事の一つでしかないはずです。プロジェクトを通してシステムを使っている社員、更にはその先の顧客・求職者へ如何に価値を提供できるか考えるべきですが、一時期は「どうやるのか・なにをやるのか」というプロジェクト自体を完遂させることしか考えられていない時期もありました。 視野が狭くなっていたことに周りからの指摘で気づくことができ、それ以降は「そもそも本当にこの機能はいるのか」などユーザーの立場からの観点も徐々に身に付けることができました。これがきっかけとなり、周りとも頻繁に「なぜやるのか」を議論できるようになったと思います。新卒 1 年目で口酸っぱく言われていた「目的意識」をようやく腹落ちさせ体現することができました。 最後に 最後となりますが、プロジェクトリーダーについて語ってきた私ですが、入社するまでは Web 開発未経験でして、メドレーでの成長を非常に実感しています。そんなメドレーではエンジニア・デザイナーをはじめ多くのポジションで新たなメンバーを募集していますので、少しでもご興味をお持ちいただけた方は、是非お気軽にお話しさせていただければと思います！ ここまでお付き合いいただき、ありがとうございました。 https://www.medley.jp/jobs/

はじめまして。メドレーのエンジニア熊本です。新卒で入社し今年で 3 年目になりまして、 2019 年度エンジニア新卒の研修 を終えてから早 2 年が経とうとしています。 そんな私ですが去年の 11 月頃から先月までの間、とあるプロジェクトのリーダーを任せてもらっていたので、そのお話をさせていただきます。 はじめに 私は新卒研修を終えてから医療介護求人サイト ジョブメドレー のチームで開発をしていましたが、そのジョブメドレーを支える社内管理システムのリニューアルプロジェクトに初期から携わっていました。 こちらのプロジェクトにつきましては、弊社デザイナーの酒井が デザイナーがデザインツールを使わずに、React を使ってデザインした話 を、弊社エンジニアの山田が GraphQL, TypeScript, React を用いて型安全に社内システムをリニューアルした話 を以前ブログにしていますので、よろしければあわせてご覧ください。 その社内管理システムをどのような流れでリニューアルし、その中で自分の役割がどう変化しどう対応したのかなどについて、次の章からお話ししていきます。 プロジェクトについて リニューアルの背景やシステムの概要については上に紹介した記事でも説明しているため割愛しますが、求職者や求人を掲載する顧客に関する業務を行っているシステムをおよそ 1 年半かけて刷新するという大きなプロジェクトでした。 システムの中でも求職者関連を「Phase1」、顧客関連を「Phase2」として分割し、リニューアルを進めました。 プロジェクト内での自分の役割の変遷 Phase1 の最初期は先輩方がアーキテクチャの設計やスケジューリングをしていました。当時まだ新卒 1 年目で未熟な私でしたが、権限管理のテーブル設計をするタスクをアサインしてもらいました。ここでは詳細を省きますが、初めてのテーブル設計で右も左も分からない状態から責任感を持って何とか形にすることができ、（もちろんリニューアル中に多少の見直しはありましたが）大きな達成感を得たことを覚えています。 各種設計、技術選定、開発の進め方などが大方固まり本格的に開発が始まるわけですが、Phase1 の際は先輩社員がプロジェクトリーダーとして引っ張っていただき、自分は開発メンバーの一員として API の作成などに奮闘していました。 GraphQL といった技術やスケジュールが厳密に引かれたプロジェクトでの開発など初めて経験することも多々ありましたが、先輩方にサポートをいただいたり、同期と切磋琢磨しながら取り組めたおかげで、Phase1 を乗り切ることができました。 さて、ここからが本題になりますが、Phase2 になるとプロジェクトメンバーの入れ替えや私自身の目標設定も重なり、プロジェクトリーダーを任せてもらうことになります。まずはプロジェクトリーダーに任命されてから、どういった仕事をしていたのかご紹介します。 プロジェクトリーダーの仕事 プロジェクトリーダーとして期待されていたことは以下の通りです。 プロジェクト管理 システム設計 開発 チームマネジメント これを更に細分化し、私の実業務と照らし合わせながら並べてみると、多少粒度にばらつきがあるかもしれませんが以下のようなことが挙げられます。 要件定義・画面設計（ディレクターとデザイナー主導で進めつつ、エンジニアも実データや既存ロジックを踏まえた観点を持ち合わせて参加しました） 開発方針の検討 開発タスクへの落とし込み 技術調査・選定 API 設計 工数算出・スケジューリング 実装・レビュー QA（Quality Assurance）テスト リリースマネジメント Phase2 は段階的にリリースを行ったため、その度に 1 から 9 までを繰り返していたような流れになります。また、上記に加え、定例ミーティングでの報告や開発メンバーのタスクマネジメントも随時行っていました。 もちろん苦労したことは多く、全部を挙げようとするとキリがないのですが、その中でもいくつかに絞った上で紹介したいと思います。 苦労と工夫 1. 「そもそも何をやればいいのか」 まず最初に苦労したことは「そもそも何をやればいいのかわからない」ということでした。初めから先ほど挙げたような動きをイメージできていたわけではなく、記事や本を読み漁ったり先輩との 1on1 で質問攻めにしたりと基本的な知識を叩き込むわけですが、実際にとった最初の動きとしては「できる部分を見つけてやっていく」ということだったと思います。 自分がリーダーに任命された時点でのプロジェクトの状況としては要件定義や画面設計が進んでいる最中でしたが、これらがまとまるのを待つのではなく「全部決まらないとやれないこと」と「現時点でやれること」を切り分けて動きました。こうしたところから少しずつリズムを作り、最終的に先ほど列挙したような一通りのことがイメージ・実行できるようになったのだと思います。 2. 工数見積もり 一般的に工数見積もりに関する記事は世の中に多く存在しますが、私の場合は工数見積もりの方法がわからなかったというよりも、「どういう思想で見積もったのか、どういう選択肢があるのか」を曖昧にしていたことが当初の問題でした。 初めて見積もった時は単に開発タスクを積み上げた工数を報告して満足してしまいましたが、様々な方のフィードバックを受けプロダクト価値を高めるためにどういう動きができるのかを考える必要があったことを痛感しました。単純に工数を積み上げる場合や事業的な都合を踏まえてミニマムで開発する場合など、いくつかの選択肢をそれぞれの軸で考える必要があったことを学びました（この時期は夜な夜な夢の中で工数見積もりをしていたのも今ではいい思い出です）。 3. 意思決定 これはいつになっても正解が存在する類のものではないのですが、特に意思決定には苦労しました。意思決定といっても開発方針から技術選定まで様々な粒度のものがありますが、特に最初から苦労したのは技術的な決定でした。 それまで先輩に頼ることの多かった私がプロジェクトリーダーになった直後から何もかもできるようになるわけではないことは明々白々ですが、「自分が決めないと」と焦ってしまっていた時期もあったと思います。 そこで一度立ち止まって意識したことは、「何ができて何ができないのかを他者に明示する」ことでした。はっきりと自分に足りていないことを他者に伝えることで、周りもサポートしやすくなると思いますし、自分自身なにがやれることなのか明確になるので単純なことですが効果的であったと思います。他にも開発メンバーの提案で、インセプションデッキを取り入れてみたことも効果的でした。 また、意思決定とは文脈が少し変わってきますが、モブプロやペアプロを実施してチーム力を高め属人化をなくしつつ開発効率を向上させる取り組みも、時間が経てば経つほど効果を実感できて良かったと思います。このようにアジャイル開発の手法からチームにフィットする手法をいくつか取り入れることもできました。 プロジェクトを通して成長したこと これまで小出しで色々とお話しさせていただきましたが、自分が特に成長したと感じていることをまとめさせていただきます。 一通りの経験を通して得られたリード力 「API 設計だけ」ではなく一通り全てを任せていただいたことはとても大きな経験になりました。初めて個人ではなくチーム・プロジェクト全体として効率が良くなる動きを考える経験もできたと思います。 技術力 もちろん実装を通じて得た技術は数えきれないほどありますが、その中でも特に責任を持って他者のコードをレビューしたり、自分が書くコードの影響範囲やスコープを意識し続けたことが大きな糧になっている気がします。 リスク管理力 スケジュール遅延のリスク、方向性がずれてしまうリスク、技術的なリスク、様々ありますがこれらのリスクヘッジを考える力がプロジェクトリーダーには必要です。 リスク管理において「先読みが大切」とよく言われますが、私の場合はある先輩社員から「常に 2 週間先を見据えておけ」という具体的な日数のアドバイスをいただきました。具体的にすることであらゆることが想像しやすくなりましたし、それを 1 年以上毎日意識し実行し続けたことが、プロジェクトをやり切ることができた要因にもなっていると思います。もちろんこの言葉は家宝にしようと思っています。 価値に対する視野 何よりも「プロダクトのユーザーに価値を提供すること」の意味を理解しました。ここまでに書いてきたようなスケジュール管理やリスク管理などは、あくまでプロジェクトを遂行する上で必要な仕事の一つでしかないはずです。プロジェクトを通してシステムを使っている社員、更にはその先の顧客・求職者へ如何に価値を提供できるか考えるべきですが、一時期は「どうやるのか・なにをやるのか」というプロジェクト自体を完遂させることしか考えられていない時期もありました。 視野が狭くなっていたことに周りからの指摘で気づくことができ、それ以降は「そもそも本当にこの機能はいるのか」などユーザーの立場からの観点も徐々に身に付けることができました。これがきっかけとなり、周りとも頻繁に「なぜやるのか」を議論できるようになったと思います。新卒 1 年目で口酸っぱく言われていた「目的意識」をようやく腹落ちさせ体現することができました。 最後に 最後となりますが、プロジェクトリーダーについて語ってきた私ですが、入社するまでは Web 開発未経験でして、メドレーでの成長を非常に実感しています。そんなメドレーではエンジニア・デザイナーをはじめ多くのポジションで新たなメンバーを募集していますので、少しでもご興味をお持ちいただけた方は、是非お気軽にお話しさせていただければと思います！ ここまでお付き合いいただき、ありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp