皆様こんにちは。 プロダクト開発室 エンジニアの濱中です。 新型コロナウイルス感染症が猛威を振るっておりますが、皆様いかがお過ごしでしょうか。先日の緊急事態宣言を受けて、メドレーも全社員が原則リモートで業務に当たっています。オンライン医療事典「MEDLEY」にも、 コロナウイルス関連の特集 が組まれていますのでぜひご覧ください。 さて先日、社内勉強会 TechLunch にて、弊社の提供するクラウド診療支援システム「CLINICS」のサービス運営で使われている監視ツール群について発表したので、ご紹介させていただきます。 CLINICS の概要と、サービスにおける監視の立ち位置について 公式ページ で「クラウド診療支援システム」と銘打っている CLINICS ですが、より詳細には、電子カルテシステム・オンライン予約システムも提供しています。これら予約・診療・カルテの 3 プロダクトで医療現場の業務を一手に引き受けることを目的としたサービスが CLINICS です。 このうち、電子カルテシステムは、「 日医標準レセプトソフト ORCA 」という製品を内包する形で提供しており、ORCA 自体は独立した環境で動作しています。 当然ながら、ORCA 自体が CLINICS とは独立した 1 プロダクトであるため、CLINICS 側に問題がなくても ORCA サーバがパフォーマンス低下や不具合を起こしてしまったり、あるいは CLINICS の web サーバとの通信がうまくいかなくなるケースも考えられます。 電子カルテシステムは医療機関の診察・会計といった日常業務の重要なパートを担っており、ここで障害が発生すると業務が止まってしまいます（最悪、患者さんをお待たせしてしまうこともあります）。 そのため、業務に大きな影響を与える箇所を中心に、複数の監視ツールでアプリケーションの動作状況をチェックしています。 監視ツールあれこれ ここからは実際に CLINICS で利用しているツールを簡潔にご紹介していきます。 Sentry Application Performance Monitoring & Error Tracking Software Application performance monitoring for developers & software teams to see errors clearer, solve issues faster & continue learning continuously. sentry.io 弊社の他プロダクト（「 ジョブメドレー 」、「 介護のほんね 」）でも利用している監視ツールです。 基本的には、アプリケーションで例外が発生すると自動でアラートを投げてくれますが、アプリケーション側で catch してしまうものや、例外ではないが通知したいイベントについて、任意にアラートをあげることも可能です。 CLINICS では例えばアカウント ID やアクセスした API エンドポイント・パラメータなど渡して、エラー調査に活用しています。 Mackerel Mackerel（マカレル）: 始めやすくて奥深い、可観測性プラットフォーム Mackerel(マカレル)は誰でも簡単に始めやすく奥深い可観測性プラットフォーム。運用をイージーにするオブザーバビリティを高め、未知の問題に立ち向かう開発者に力を与えます。サーバー監視をMackerelではじめてみませんか？無料プランや2週間のトライアルもあります。 mackerel.io GUI で簡単に監視設定が可能なサービスです。 前職で使っていた時は GUI でできるところまでしか触っていなかったのですが、設定ファイルを手製すれば、自作スクリプトの出力をチェックしたり、チェックに失敗した時何か処理をしたり…といったマニュアルな監視も可能です。 現在 CLINICS においては、ORCA インスタンスがそれぞれ独立して動作していますが、Mackerel ではこの ORCA インスタンスを監視しています。また監視するだけでなく、動作不良を起こした時の再起動処理なども担当しています。 AWS CloudWatch & Lambda Amazon CloudWatch（リソースとアプリケーションの監視と管理）| AWS Amazon CloudWatch は、AWS リソースと AWS で実行するアプリケーションのモニタリングサービスです。様々なメトリクスやログを収集・追跡することで、システム全体のリソース使用率、アプリケーションパフォーマンス、およびオペレーションの状態について可視化することができます。 aws.amazon.com AWS Lambda（イベント発生時にコードを実行）| AWS AWS Lambda を使用すれば、サーバーのプロビジョニングや管理なしでコードを実行できます。課金は実際に使用したコンピューティング時間に対してのみ発生し、コードが実行されていないときには料金も発生しません。 aws.amazon.com どちらも AWS の提供するツールです。 CloudWatch は主にログの記録と監視を行うためのツールです。複数の機能がありますが、CLINICS では主に Logs, Metrics, Alarm を使用しています。 Logs はその名の通り、主に AWS のツールが発行するログを収集・検索・閲覧する機能で、問題発生時の HTTP リクエストのパラメータを確認する時などに利用しています。 Metrics は、「プロダクト（EC2 ならインスタンス, RDS なら DB インスタンスなど製品の一単位）」×「メトリクス種別（CPU 利用率など）」を一単位として、統計情報を可視化するツールです。 それらに閾値を設け、超えた場合にアラートを発行するのが Alarm…という位置付けです。 対して Lambda は、そもそも監視ツールではありません。定期実行、あるいは何かのイベント（S3 に何かアップロードされた、など）をトリガーとして、処理を行うツールです。処理した結果を、さらに別のツールへ連携（Slack 通知などの外部連携も含む）させることも可能です。 CLINICS では、上記アラート通知のほか、 SessionManager 経由でインスタンスに ssh ログインした時の通知や、時間のかかるインポートタスクなどが終了した時の通知などにも利用しています。 New Relic スタック全体をモニタリング、デバッグ、改善 登録は無料、クレジットカードは不要です。New Relic Oneとクイックスタートでインスタントオブザーバビリティを手に入れれば、インストゥルメントを数クリックで実行できるようになります。 newrelic.co.jp New Relic は、CLINICS ではパフォーマンス評価ツールとして利用しています。 メインとなるのは APM(Application Performance Monitoring)で、アプリケーション内のどの処理にどれだけ時間がかかったかなどを閲覧することができます。 医療機関は時間によって診察ペースが大きく変わるため、1 回 1 回は少しの遅延であっても、業務フローのコアな部分に絡んでいる場合、遅延が響いてくることはあります。 このような、「エラーは出ないけど、レスポンスが遅い」というご連絡を受けた時の調査・メンテナンスに主に活躍してくれます。 Sentry のようにエラー検知を行なったりもでき、ツール自体の多機能さから取得できる情報の多さが段違いといった印象です。 Firebase Crashlytics Firebase | Google's Mobile and Web App Development Platform Firebase は、デベロッパーがユーザーに人気のアプリやゲームを開発できるよう支援する Google のモバイルおよびウェブアプリ開発プラットフォームです。 firebase.google.com Firebase もまた”多機能な”ツールですが、CLINICS では監視機能として Crashlytics を使っています。 CLINICS では、患者さんが予約・オンライン診療を行うためのアプリを iOS / Android で公開しており、医療機関向けの Web アプリケーション側と連携して動作します。このネイティブアプリで発生したクラッシュを集計しているのが Crashlytics です。 Android の場合は build.gradle に設定を追記してアプリをビルド、iOS の場合は cocoapods で外部ライブラリとしてインストールすることで集計が可能になります。Unity アプリにも対応しているとのことです。 その他、監視ではないですがアプリを利用している端末や OS バージョンなどの統計情報の収集も可能です。 PagerDuty による監視集約 PagerDuty｜インシデント管理プラットフォーム｜PagerDuty株式会社 PagerDuty（ペイジャーデューティ）はシステムのインシデント対応を一元化するプラットフォームです。DX時代におけるオペレーショナル・レジリエンスを高め、障害対応に費やす時間を軽減することで、貴重なエンジニアリソースをビジネス拡大に充てることができます。 ja.pagerduty.com CLINICS ではここまでに挙げてきたツールを使って監視を行っておりますが、昨年、複数の監視ソースからのアラートを一本化すべく、インシデント管理サービス PagerDuty を導入しました。 導入後は、全てのアラートツールはアラートを一旦 PagerDuty に集約し、PagerDuty から Slack 通知を行うという形式になりました。 また、PagerDuty が出すアラートは、担当者が確認してレスポンスを返す（acknowledge）ことを行わずに一定時間が過ぎた場合、電話や SMS での通知へ展開していくように設定することができます。これによって、クリティカルなエラーの見落としを確実に防げるようになりました。 まとめ CLINICS で利用している監視ツール+α を紹介させていただきました。 これらのツールを駆使しながら、ユーザの皆様に安心してお使いいただけるようサービスの安定稼動に尽力しています。 ご覧いただきありがとうございました。

皆様こんにちは。 プロダクト開発室 エンジニアの濱中です。 新型コロナウイルス感染症が猛威を振るっておりますが、皆様いかがお過ごしでしょうか。先日の緊急事態宣言を受けて、メドレーも全社員が原則リモートで業務に当たっています。オンライン医療事典「MEDLEY」にも、 コロナウイルス関連の特集 が組まれていますのでぜひご覧ください。 さて先日、社内勉強会 TechLunch にて、弊社の提供するクラウド診療支援システム「CLINICS」のサービス運営で使われている監視ツール群について発表したので、ご紹介させていただきます。 CLINICS の概要と、サービスにおける監視の立ち位置について 公式ページ で「クラウド診療支援システム」と銘打っている CLINICS ですが、より詳細には、電子カルテシステム・オンライン予約システムも提供しています。これら予約・診療・カルテの 3 プロダクトで医療現場の業務を一手に引き受けることを目的としたサービスが CLINICS です。 このうち、電子カルテシステムは、「 日医標準レセプトソフト ORCA 」という製品を内包する形で提供しており、ORCA 自体は独立した環境で動作しています。 当然ながら、ORCA 自体が CLINICS とは独立した 1 プロダクトであるため、CLINICS 側に問題がなくても ORCA サーバがパフォーマンス低下や不具合を起こしてしまったり、あるいは CLINICS の web サーバとの通信がうまくいかなくなるケースも考えられます。 電子カルテシステムは医療機関の診察・会計といった日常業務の重要なパートを担っており、ここで障害が発生すると業務が止まってしまいます（最悪、患者さんをお待たせしてしまうこともあります）。 そのため、業務に大きな影響を与える箇所を中心に、複数の監視ツールでアプリケーションの動作状況をチェックしています。 監視ツールあれこれ ここからは実際に CLINICS で利用しているツールを簡潔にご紹介していきます。 Sentry Application Performance Monitoring & Error Tracking Software Application performance monitoring for developers & software teams to see errors clearer, solve issues faster & continue learning continuously. sentry.io 弊社の他プロダクト（「 ジョブメドレー 」、「 介護のほんね 」）でも利用している監視ツールです。 基本的には、アプリケーションで例外が発生すると自動でアラートを投げてくれますが、アプリケーション側で catch してしまうものや、例外ではないが通知したいイベントについて、任意にアラートをあげることも可能です。 CLINICS では例えばアカウント ID やアクセスした API エンドポイント・パラメータなど渡して、エラー調査に活用しています。 Mackerel Mackerel（マカレル）: 始めやすくて奥深い、可観測性プラットフォーム Mackerel(マカレル)は誰でも簡単に始めやすく奥深い可観測性プラットフォーム。運用をイージーにするオブザーバビリティを高め、未知の問題に立ち向かう開発者に力を与えます。サーバー監視をMackerelではじめてみませんか？無料プランや2週間のトライアルもあります。 mackerel.io GUI で簡単に監視設定が可能なサービスです。 前職で使っていた時は GUI でできるところまでしか触っていなかったのですが、設定ファイルを手製すれば、自作スクリプトの出力をチェックしたり、チェックに失敗した時何か処理をしたり…といったマニュアルな監視も可能です。 現在 CLINICS においては、ORCA インスタンスがそれぞれ独立して動作していますが、Mackerel ではこの ORCA インスタンスを監視しています。また監視するだけでなく、動作不良を起こした時の再起動処理なども担当しています。 AWS CloudWatch & Lambda Amazon CloudWatch（リソースとアプリケーションの監視と管理）| AWS Amazon CloudWatch は、AWS リソースと AWS で実行するアプリケーションのモニタリングサービスです。様々なメトリクスやログを収集・追跡することで、システム全体のリソース使用率、アプリケーションパフォーマンス、およびオペレーションの状態について可視化することができます。 aws.amazon.com AWS Lambda（イベント発生時にコードを実行）| AWS AWS Lambda を使用すれば、サーバーのプロビジョニングや管理なしでコードを実行できます。課金は実際に使用したコンピューティング時間に対してのみ発生し、コードが実行されていないときには料金も発生しません。 aws.amazon.com どちらも AWS の提供するツールです。 CloudWatch は主にログの記録と監視を行うためのツールです。複数の機能がありますが、CLINICS では主に Logs, Metrics, Alarm を使用しています。 Logs はその名の通り、主に AWS のツールが発行するログを収集・検索・閲覧する機能で、問題発生時の HTTP リクエストのパラメータを確認する時などに利用しています。 Metrics は、「プロダクト（EC2 ならインスタンス, RDS なら DB インスタンスなど製品の一単位）」×「メトリクス種別（CPU 利用率など）」を一単位として、統計情報を可視化するツールです。 それらに閾値を設け、超えた場合にアラートを発行するのが Alarm…という位置付けです。 対して Lambda は、そもそも監視ツールではありません。定期実行、あるいは何かのイベント（S3 に何かアップロードされた、など）をトリガーとして、処理を行うツールです。処理した結果を、さらに別のツールへ連携（Slack 通知などの外部連携も含む）させることも可能です。 CLINICS では、上記アラート通知のほか、 SessionManager 経由でインスタンスに ssh ログインした時の通知や、時間のかかるインポートタスクなどが終了した時の通知などにも利用しています。 New Relic スタック全体をモニタリング、デバッグ、改善 登録は無料、クレジットカードは不要です。New Relic Oneとクイックスタートでインスタントオブザーバビリティを手に入れれば、インストゥルメントを数クリックで実行できるようになります。 newrelic.co.jp New Relic は、CLINICS ではパフォーマンス評価ツールとして利用しています。 メインとなるのは APM(Application Performance Monitoring)で、アプリケーション内のどの処理にどれだけ時間がかかったかなどを閲覧することができます。 医療機関は時間によって診察ペースが大きく変わるため、1 回 1 回は少しの遅延であっても、業務フローのコアな部分に絡んでいる場合、遅延が響いてくることはあります。 このような、「エラーは出ないけど、レスポンスが遅い」というご連絡を受けた時の調査・メンテナンスに主に活躍してくれます。 Sentry のようにエラー検知を行なったりもでき、ツール自体の多機能さから取得できる情報の多さが段違いといった印象です。 Firebase Crashlytics Firebase | Google's Mobile and Web App Development Platform Firebase は、デベロッパーがユーザーに人気のアプリやゲームを開発できるよう支援する Google のモバイルおよびウェブアプリ開発プラットフォームです。 firebase.google.com Firebase もまた”多機能な”ツールですが、CLINICS では監視機能として Crashlytics を使っています。 CLINICS では、患者さんが予約・オンライン診療を行うためのアプリを iOS / Android で公開しており、医療機関向けの Web アプリケーション側と連携して動作します。このネイティブアプリで発生したクラッシュを集計しているのが Crashlytics です。 Android の場合は build.gradle に設定を追記してアプリをビルド、iOS の場合は cocoapods で外部ライブラリとしてインストールすることで集計が可能になります。Unity アプリにも対応しているとのことです。 その他、監視ではないですがアプリを利用している端末や OS バージョンなどの統計情報の収集も可能です。 PagerDuty による監視集約 PagerDuty｜インシデント管理プラットフォーム｜PagerDuty株式会社 PagerDuty（ペイジャーデューティ）はシステムのインシデント対応を一元化するプラットフォームです。DX時代におけるオペレーショナル・レジリエンスを高め、障害対応に費やす時間を軽減することで、貴重なエンジニアリソースをビジネス拡大に充てることができます。 ja.pagerduty.com CLINICS ではここまでに挙げてきたツールを使って監視を行っておりますが、昨年、複数の監視ソースからのアラートを一本化すべく、インシデント管理サービス PagerDuty を導入しました。 導入後は、全てのアラートツールはアラートを一旦 PagerDuty に集約し、PagerDuty から Slack 通知を行うという形式になりました。 また、PagerDuty が出すアラートは、担当者が確認してレスポンスを返す（acknowledge）ことを行わずに一定時間が過ぎた場合、電話や SMS での通知へ展開していくように設定することができます。これによって、クリティカルなエラーの見落としを確実に防げるようになりました。 まとめ CLINICS で利用している監視ツール+α を紹介させていただきました。 これらのツールを駆使しながら、ユーザの皆様に安心してお使いいただけるようサービスの安定稼動に尽力しています。 ご覧いただきありがとうございました。

皆様こんにちは。 プロダクト開発室 エンジニアの濱中です。 新型コロナウイルス感染症が猛威を振るっておりますが、皆様いかがお過ごしでしょうか。先日の緊急事態宣言を受けて、メドレーも全社員が原則リモートで業務に当たっています。オンライン医療事典「MEDLEY」にも、 コロナウイルス関連の特集 が組まれていますのでぜひご覧ください。 さて先日、社内勉強会 TechLunch にて、弊社の提供するクラウド診療支援システム「CLINICS」のサービス運営で使われている監視ツール群について発表したので、ご紹介させていただきます。 CLINICS の概要と、サービスにおける監視の立ち位置について 公式ページ で「クラウド診療支援システム」と銘打っている CLINICS ですが、より詳細には、電子カルテシステム・オンライン予約システムも提供しています。これら予約・診療・カルテの 3 プロダクトで医療現場の業務を一手に引き受けることを目的としたサービスが CLINICS です。 このうち、電子カルテシステムは、「 日医標準レセプトソフト ORCA 」という製品を内包する形で提供しており、ORCA 自体は独立した環境で動作しています。 当然ながら、ORCA 自体が CLINICS とは独立した 1 プロダクトであるため、CLINICS 側に問題がなくても ORCA サーバがパフォーマンス低下や不具合を起こしてしまったり、あるいは CLINICS の web サーバとの通信がうまくいかなくなるケースも考えられます。 電子カルテシステムは医療機関の診察・会計といった日常業務の重要なパートを担っており、ここで障害が発生すると業務が止まってしまいます（最悪、患者さんをお待たせしてしまうこともあります）。 そのため、業務に大きな影響を与える箇所を中心に、複数の監視ツールでアプリケーションの動作状況をチェックしています。 監視ツールあれこれ ここからは実際に CLINICS で利用しているツールを簡潔にご紹介していきます。 Sentry Application Performance Monitoring & Error Tracking Software Application performance monitoring for developers & software teams to see errors clearer, solve issues faster & continue learning continuously. sentry.io 弊社の他プロダクト（「 ジョブメドレー 」、「 介護のほんね 」）でも利用している監視ツールです。 基本的には、アプリケーションで例外が発生すると自動でアラートを投げてくれますが、アプリケーション側で catch してしまうものや、例外ではないが通知したいイベントについて、任意にアラートをあげることも可能です。 CLINICS では例えばアカウント ID やアクセスした API エンドポイント・パラメータなど渡して、エラー調査に活用しています。 Mackerel Mackerel（マカレル）: 始めやすくて奥深い、可観測性プラットフォーム Mackerel(マカレル)は誰でも簡単に始めやすく奥深い可観測性プラットフォーム。運用をイージーにするオブザーバビリティを高め、未知の問題に立ち向かう開発者に力を与えます。サーバー監視をMackerelではじめてみませんか？無料プランや2週間のトライアルもあります。 mackerel.io GUI で簡単に監視設定が可能なサービスです。 前職で使っていた時は GUI でできるところまでしか触っていなかったのですが、設定ファイルを手製すれば、自作スクリプトの出力をチェックしたり、チェックに失敗した時何か処理をしたり…といったマニュアルな監視も可能です。 現在 CLINICS においては、ORCA インスタンスがそれぞれ独立して動作していますが、Mackerel ではこの ORCA インスタンスを監視しています。また監視するだけでなく、動作不良を起こした時の再起動処理なども担当しています。 AWS CloudWatch & Lambda Amazon CloudWatch（リソースとアプリケーションの監視と管理）| AWS Amazon CloudWatch は、AWS リソースと AWS で実行するアプリケーションのモニタリングサービスです。様々なメトリクスやログを収集・追跡することで、システム全体のリソース使用率、アプリケーションパフォーマンス、およびオペレーションの状態について可視化することができます。 aws.amazon.com AWS Lambda（イベント発生時にコードを実行）| AWS AWS Lambda を使用すれば、サーバーのプロビジョニングや管理なしでコードを実行できます。課金は実際に使用したコンピューティング時間に対してのみ発生し、コードが実行されていないときには料金も発生しません。 aws.amazon.com どちらも AWS の提供するツールです。 CloudWatch は主にログの記録と監視を行うためのツールです。複数の機能がありますが、CLINICS では主に Logs, Metrics, Alarm を使用しています。 Logs はその名の通り、主に AWS のツールが発行するログを収集・検索・閲覧する機能で、問題発生時の HTTP リクエストのパラメータを確認する時などに利用しています。 Metrics は、「プロダクト（EC2 ならインスタンス, RDS なら DB インスタンスなど製品の一単位）」×「メトリクス種別（CPU 利用率など）」を一単位として、統計情報を可視化するツールです。 それらに閾値を設け、超えた場合にアラートを発行するのが Alarm…という位置付けです。 対して Lambda は、そもそも監視ツールではありません。定期実行、あるいは何かのイベント（S3 に何かアップロードされた、など）をトリガーとして、処理を行うツールです。処理した結果を、さらに別のツールへ連携（Slack 通知などの外部連携も含む）させることも可能です。 CLINICS では、上記アラート通知のほか、 SessionManager 経由でインスタンスに ssh ログインした時の通知や、時間のかかるインポートタスクなどが終了した時の通知などにも利用しています。 New Relic スタック全体をモニタリング、デバッグ、改善 登録は無料、クレジットカードは不要です。New Relic Oneとクイックスタートでインスタントオブザーバビリティを手に入れれば、インストゥルメントを数クリックで実行できるようになります。 newrelic.co.jp New Relic は、CLINICS ではパフォーマンス評価ツールとして利用しています。 メインとなるのは APM(Application Performance Monitoring)で、アプリケーション内のどの処理にどれだけ時間がかかったかなどを閲覧することができます。 医療機関は時間によって診察ペースが大きく変わるため、1 回 1 回は少しの遅延であっても、業務フローのコアな部分に絡んでいる場合、遅延が響いてくることはあります。 このような、「エラーは出ないけど、レスポンスが遅い」というご連絡を受けた時の調査・メンテナンスに主に活躍してくれます。 Sentry のようにエラー検知を行なったりもでき、ツール自体の多機能さから取得できる情報の多さが段違いといった印象です。 Firebase Crashlytics Firebase | Google's Mobile and Web App Development Platform Firebase は、デベロッパーがユーザーに人気のアプリやゲームを開発できるよう支援する Google のモバイルおよびウェブアプリ開発プラットフォームです。 firebase.google.com Firebase もまた”多機能な”ツールですが、CLINICS では監視機能として Crashlytics を使っています。 CLINICS では、患者さんが予約・オンライン診療を行うためのアプリを iOS / Android で公開しており、医療機関向けの Web アプリケーション側と連携して動作します。このネイティブアプリで発生したクラッシュを集計しているのが Crashlytics です。 Android の場合は build.gradle に設定を追記してアプリをビルド、iOS の場合は cocoapods で外部ライブラリとしてインストールすることで集計が可能になります。Unity アプリにも対応しているとのことです。 その他、監視ではないですがアプリを利用している端末や OS バージョンなどの統計情報の収集も可能です。 PagerDuty による監視集約 PagerDuty｜インシデント管理プラットフォーム｜PagerDuty株式会社 PagerDuty（ペイジャーデューティ）はシステムのインシデント対応を一元化するプラットフォームです。DX時代におけるオペレーショナル・レジリエンスを高め、障害対応に費やす時間を軽減することで、貴重なエンジニアリソースをビジネス拡大に充てることができます。 ja.pagerduty.com CLINICS ではここまでに挙げてきたツールを使って監視を行っておりますが、昨年、複数の監視ソースからのアラートを一本化すべく、インシデント管理サービス PagerDuty を導入しました。 導入後は、全てのアラートツールはアラートを一旦 PagerDuty に集約し、PagerDuty から Slack 通知を行うという形式になりました。 また、PagerDuty が出すアラートは、担当者が確認してレスポンスを返す（acknowledge）ことを行わずに一定時間が過ぎた場合、電話や SMS での通知へ展開していくように設定することができます。これによって、クリティカルなエラーの見落としを確実に防げるようになりました。 まとめ CLINICS で利用している監視ツール+α を紹介させていただきました。 これらのツールを駆使しながら、ユーザの皆様に安心してお使いいただけるようサービスの安定稼動に尽力しています。 ご覧いただきありがとうございました。

皆様こんにちは。 プロダクト開発室 エンジニアの濱中です。 新型コロナウイルス感染症が猛威を振るっておりますが、皆様いかがお過ごしでしょうか。先日の緊急事態宣言を受けて、メドレーも全社員が原則リモートで業務に当たっています。オンライン医療事典「MEDLEY」にも、 コロナウイルス関連の特集 が組まれていますのでぜひご覧ください。 さて先日、社内勉強会 TechLunch にて、弊社の提供するクラウド診療支援システム「CLINICS」のサービス運営で使われている監視ツール群について発表したので、ご紹介させていただきます。 CLINICS の概要と、サービスにおける監視の立ち位置について 公式ページ で「クラウド診療支援システム」と銘打っている CLINICS ですが、より詳細には、電子カルテシステム・オンライン予約システムも提供しています。これら予約・診療・カルテの 3 プロダクトで医療現場の業務を一手に引き受けることを目的としたサービスが CLINICS です。 このうち、電子カルテシステムは、「 日医標準レセプトソフト ORCA 」という製品を内包する形で提供しており、ORCA 自体は独立した環境で動作しています。 当然ながら、ORCA 自体が CLINICS とは独立した 1 プロダクトであるため、CLINICS 側に問題がなくても ORCA サーバがパフォーマンス低下や不具合を起こしてしまったり、あるいは CLINICS の web サーバとの通信がうまくいかなくなるケースも考えられます。 電子カルテシステムは医療機関の診察・会計といった日常業務の重要なパートを担っており、ここで障害が発生すると業務が止まってしまいます（最悪、患者さんをお待たせしてしまうこともあります）。 そのため、業務に大きな影響を与える箇所を中心に、複数の監視ツールでアプリケーションの動作状況をチェックしています。 監視ツールあれこれ ここからは実際に CLINICS で利用しているツールを簡潔にご紹介していきます。 Sentry Application Performance Monitoring & Error Tracking Software Application performance monitoring for developers & software teams to see errors clearer, solve issues faster & continue learning continuously. sentry.io 弊社の他プロダクト（「 ジョブメドレー 」、「 介護のほんね 」）でも利用している監視ツールです。 基本的には、アプリケーションで例外が発生すると自動でアラートを投げてくれますが、アプリケーション側で catch してしまうものや、例外ではないが通知したいイベントについて、任意にアラートをあげることも可能です。 CLINICS では例えばアカウント ID やアクセスした API エンドポイント・パラメータなど渡して、エラー調査に活用しています。 Mackerel Mackerel（マカレル）: 始めやすくて奥深い、可観測性プラットフォーム Mackerel(マカレル)は誰でも簡単に始めやすく奥深い可観測性プラットフォーム。運用をイージーにするオブザーバビリティを高め、未知の問題に立ち向かう開発者に力を与えます。サーバー監視をMackerelではじめてみませんか？無料プランや2週間のトライアルもあります。 mackerel.io GUI で簡単に監視設定が可能なサービスです。 前職で使っていた時は GUI でできるところまでしか触っていなかったのですが、設定ファイルを手製すれば、自作スクリプトの出力をチェックしたり、チェックに失敗した時何か処理をしたり…といったマニュアルな監視も可能です。 現在 CLINICS においては、ORCA インスタンスがそれぞれ独立して動作していますが、Mackerel ではこの ORCA インスタンスを監視しています。また監視するだけでなく、動作不良を起こした時の再起動処理なども担当しています。 AWS CloudWatch & Lambda Amazon CloudWatch（リソースとアプリケーションの監視と管理）| AWS Amazon CloudWatch は、AWS リソースと AWS で実行するアプリケーションのモニタリングサービスです。様々なメトリクスやログを収集・追跡することで、システム全体のリソース使用率、アプリケーションパフォーマンス、およびオペレーションの状態について可視化することができます。 aws.amazon.com AWS Lambda（イベント発生時にコードを実行）| AWS AWS Lambda を使用すれば、サーバーのプロビジョニングや管理なしでコードを実行できます。課金は実際に使用したコンピューティング時間に対してのみ発生し、コードが実行されていないときには料金も発生しません。 aws.amazon.com どちらも AWS の提供するツールです。 CloudWatch は主にログの記録と監視を行うためのツールです。複数の機能がありますが、CLINICS では主に Logs, Metrics, Alarm を使用しています。 Logs はその名の通り、主に AWS のツールが発行するログを収集・検索・閲覧する機能で、問題発生時の HTTP リクエストのパラメータを確認する時などに利用しています。 Metrics は、「プロダクト（EC2 ならインスタンス, RDS なら DB インスタンスなど製品の一単位）」×「メトリクス種別（CPU 利用率など）」を一単位として、統計情報を可視化するツールです。 それらに閾値を設け、超えた場合にアラートを発行するのが Alarm…という位置付けです。 対して Lambda は、そもそも監視ツールではありません。定期実行、あるいは何かのイベント（S3 に何かアップロードされた、など）をトリガーとして、処理を行うツールです。処理した結果を、さらに別のツールへ連携（Slack 通知などの外部連携も含む）させることも可能です。 CLINICS では、上記アラート通知のほか、 SessionManager 経由でインスタンスに ssh ログインした時の通知や、時間のかかるインポートタスクなどが終了した時の通知などにも利用しています。 New Relic スタック全体をモニタリング、デバッグ、改善 登録は無料、クレジットカードは不要です。New Relic Oneとクイックスタートでインスタントオブザーバビリティを手に入れれば、インストゥルメントを数クリックで実行できるようになります。 newrelic.co.jp New Relic は、CLINICS ではパフォーマンス評価ツールとして利用しています。 メインとなるのは APM(Application Performance Monitoring)で、アプリケーション内のどの処理にどれだけ時間がかかったかなどを閲覧することができます。 医療機関は時間によって診察ペースが大きく変わるため、1 回 1 回は少しの遅延であっても、業務フローのコアな部分に絡んでいる場合、遅延が響いてくることはあります。 このような、「エラーは出ないけど、レスポンスが遅い」というご連絡を受けた時の調査・メンテナンスに主に活躍してくれます。 Sentry のようにエラー検知を行なったりもでき、ツール自体の多機能さから取得できる情報の多さが段違いといった印象です。 Firebase Crashlytics Firebase | Google's Mobile and Web App Development Platform Firebase は、デベロッパーがユーザーに人気のアプリやゲームを開発できるよう支援する Google のモバイルおよびウェブアプリ開発プラットフォームです。 firebase.google.com Firebase もまた”多機能な”ツールですが、CLINICS では監視機能として Crashlytics を使っています。 CLINICS では、患者さんが予約・オンライン診療を行うためのアプリを iOS / Android で公開しており、医療機関向けの Web アプリケーション側と連携して動作します。このネイティブアプリで発生したクラッシュを集計しているのが Crashlytics です。 Android の場合は build.gradle に設定を追記してアプリをビルド、iOS の場合は cocoapods で外部ライブラリとしてインストールすることで集計が可能になります。Unity アプリにも対応しているとのことです。 その他、監視ではないですがアプリを利用している端末や OS バージョンなどの統計情報の収集も可能です。 PagerDuty による監視集約 PagerDuty｜インシデント管理プラットフォーム｜PagerDuty株式会社 PagerDuty（ペイジャーデューティ）はシステムのインシデント対応を一元化するプラットフォームです。DX時代におけるオペレーショナル・レジリエンスを高め、障害対応に費やす時間を軽減することで、貴重なエンジニアリソースをビジネス拡大に充てることができます。 ja.pagerduty.com CLINICS ではここまでに挙げてきたツールを使って監視を行っておりますが、昨年、複数の監視ソースからのアラートを一本化すべく、インシデント管理サービス PagerDuty を導入しました。 導入後は、全てのアラートツールはアラートを一旦 PagerDuty に集約し、PagerDuty から Slack 通知を行うという形式になりました。 また、PagerDuty が出すアラートは、担当者が確認してレスポンスを返す（acknowledge）ことを行わずに一定時間が過ぎた場合、電話や SMS での通知へ展開していくように設定することができます。これによって、クリティカルなエラーの見落としを確実に防げるようになりました。 まとめ CLINICS で利用している監視ツール+α を紹介させていただきました。 これらのツールを駆使しながら、ユーザの皆様に安心してお使いいただけるようサービスの安定稼動に尽力しています。 ご覧いただきありがとうございました。

皆様こんにちは。 プロダクト開発室 エンジニアの濱中です。 新型コロナウイルス感染症が猛威を振るっておりますが、皆様いかがお過ごしでしょうか。先日の緊急事態宣言を受けて、メドレーも全社員が原則リモートで業務に当たっています。オンライン医療事典「MEDLEY」にも、 コロナウイルス関連の特集 が組まれていますのでぜひご覧ください。 さて先日、社内勉強会 TechLunch にて、弊社の提供するクラウド診療支援システム「CLINICS」のサービス運営で使われている監視ツール群について発表したので、ご紹介させていただきます。 CLINICS の概要と、サービスにおける監視の立ち位置について 公式ページ で「クラウド診療支援システム」と銘打っている CLINICS ですが、より詳細には、電子カルテシステム・オンライン予約システムも提供しています。これら予約・診療・カルテの 3 プロダクトで医療現場の業務を一手に引き受けることを目的としたサービスが CLINICS です。 このうち、電子カルテシステムは、「 日医標準レセプトソフト ORCA 」という製品を内包する形で提供しており、ORCA 自体は独立した環境で動作しています。 当然ながら、ORCA 自体が CLINICS とは独立した 1 プロダクトであるため、CLINICS 側に問題がなくても ORCA サーバがパフォーマンス低下や不具合を起こしてしまったり、あるいは CLINICS の web サーバとの通信がうまくいかなくなるケースも考えられます。 電子カルテシステムは医療機関の診察・会計といった日常業務の重要なパートを担っており、ここで障害が発生すると業務が止まってしまいます（最悪、患者さんをお待たせしてしまうこともあります）。 そのため、業務に大きな影響を与える箇所を中心に、複数の監視ツールでアプリケーションの動作状況をチェックしています。 監視ツールあれこれ ここからは実際に CLINICS で利用しているツールを簡潔にご紹介していきます。 Sentry Application Performance Monitoring & Error Tracking Software Application performance monitoring for developers & software teams to see errors clearer, solve issues faster & continue learning continuously. sentry.io 弊社の他プロダクト（「 ジョブメドレー 」、「 介護のほんね 」）でも利用している監視ツールです。 基本的には、アプリケーションで例外が発生すると自動でアラートを投げてくれますが、アプリケーション側で catch してしまうものや、例外ではないが通知したいイベントについて、任意にアラートをあげることも可能です。 CLINICS では例えばアカウント ID やアクセスした API エンドポイント・パラメータなど渡して、エラー調査に活用しています。 Mackerel Mackerel（マカレル）: 始めやすくて奥深い、可観測性プラットフォーム Mackerel(マカレル)は誰でも簡単に始めやすく奥深い可観測性プラットフォーム。運用をイージーにするオブザーバビリティを高め、未知の問題に立ち向かう開発者に力を与えます。サーバー監視をMackerelではじめてみませんか？無料プランや2週間のトライアルもあります。 mackerel.io GUI で簡単に監視設定が可能なサービスです。 前職で使っていた時は GUI でできるところまでしか触っていなかったのですが、設定ファイルを手製すれば、自作スクリプトの出力をチェックしたり、チェックに失敗した時何か処理をしたり…といったマニュアルな監視も可能です。 現在 CLINICS においては、ORCA インスタンスがそれぞれ独立して動作していますが、Mackerel ではこの ORCA インスタンスを監視しています。また監視するだけでなく、動作不良を起こした時の再起動処理なども担当しています。 AWS CloudWatch & Lambda Amazon CloudWatch（リソースとアプリケーションの監視と管理）| AWS Amazon CloudWatch は、AWS リソースと AWS で実行するアプリケーションのモニタリングサービスです。様々なメトリクスやログを収集・追跡することで、システム全体のリソース使用率、アプリケーションパフォーマンス、およびオペレーションの状態について可視化することができます。 aws.amazon.com AWS Lambda（イベント発生時にコードを実行）| AWS AWS Lambda を使用すれば、サーバーのプロビジョニングや管理なしでコードを実行できます。課金は実際に使用したコンピューティング時間に対してのみ発生し、コードが実行されていないときには料金も発生しません。 aws.amazon.com どちらも AWS の提供するツールです。 CloudWatch は主にログの記録と監視を行うためのツールです。複数の機能がありますが、CLINICS では主に Logs, Metrics, Alarm を使用しています。 Logs はその名の通り、主に AWS のツールが発行するログを収集・検索・閲覧する機能で、問題発生時の HTTP リクエストのパラメータを確認する時などに利用しています。 Metrics は、「プロダクト（EC2 ならインスタンス, RDS なら DB インスタンスなど製品の一単位）」×「メトリクス種別（CPU 利用率など）」を一単位として、統計情報を可視化するツールです。 それらに閾値を設け、超えた場合にアラートを発行するのが Alarm…という位置付けです。 対して Lambda は、そもそも監視ツールではありません。定期実行、あるいは何かのイベント（S3 に何かアップロードされた、など）をトリガーとして、処理を行うツールです。処理した結果を、さらに別のツールへ連携（Slack 通知などの外部連携も含む）させることも可能です。 CLINICS では、上記アラート通知のほか、 SessionManager 経由でインスタンスに ssh ログインした時の通知や、時間のかかるインポートタスクなどが終了した時の通知などにも利用しています。 New Relic スタック全体をモニタリング、デバッグ、改善 登録は無料、クレジットカードは不要です。New Relic Oneとクイックスタートでインスタントオブザーバビリティを手に入れれば、インストゥルメントを数クリックで実行できるようになります。 newrelic.co.jp New Relic は、CLINICS ではパフォーマンス評価ツールとして利用しています。 メインとなるのは APM(Application Performance Monitoring)で、アプリケーション内のどの処理にどれだけ時間がかかったかなどを閲覧することができます。 医療機関は時間によって診察ペースが大きく変わるため、1 回 1 回は少しの遅延であっても、業務フローのコアな部分に絡んでいる場合、遅延が響いてくることはあります。 このような、「エラーは出ないけど、レスポンスが遅い」というご連絡を受けた時の調査・メンテナンスに主に活躍してくれます。 Sentry のようにエラー検知を行なったりもでき、ツール自体の多機能さから取得できる情報の多さが段違いといった印象です。 Firebase Crashlytics Firebase | Google's Mobile and Web App Development Platform Firebase は、デベロッパーがユーザーに人気のアプリやゲームを開発できるよう支援する Google のモバイルおよびウェブアプリ開発プラットフォームです。 firebase.google.com Firebase もまた”多機能な”ツールですが、CLINICS では監視機能として Crashlytics を使っています。 CLINICS では、患者さんが予約・オンライン診療を行うためのアプリを iOS / Android で公開しており、医療機関向けの Web アプリケーション側と連携して動作します。このネイティブアプリで発生したクラッシュを集計しているのが Crashlytics です。 Android の場合は build.gradle に設定を追記してアプリをビルド、iOS の場合は cocoapods で外部ライブラリとしてインストールすることで集計が可能になります。Unity アプリにも対応しているとのことです。 その他、監視ではないですがアプリを利用している端末や OS バージョンなどの統計情報の収集も可能です。 PagerDuty による監視集約 PagerDuty｜インシデント管理プラットフォーム｜PagerDuty株式会社 PagerDuty（ペイジャーデューティ）はシステムのインシデント対応を一元化するプラットフォームです。DX時代におけるオペレーショナル・レジリエンスを高め、障害対応に費やす時間を軽減することで、貴重なエンジニアリソースをビジネス拡大に充てることができます。 ja.pagerduty.com CLINICS ではここまでに挙げてきたツールを使って監視を行っておりますが、昨年、複数の監視ソースからのアラートを一本化すべく、インシデント管理サービス PagerDuty を導入しました。 導入後は、全てのアラートツールはアラートを一旦 PagerDuty に集約し、PagerDuty から Slack 通知を行うという形式になりました。 また、PagerDuty が出すアラートは、担当者が確認してレスポンスを返す（acknowledge）ことを行わずに一定時間が過ぎた場合、電話や SMS での通知へ展開していくように設定することができます。これによって、クリティカルなエラーの見落としを確実に防げるようになりました。 まとめ CLINICS で利用している監視ツール+α を紹介させていただきました。 これらのツールを駆使しながら、ユーザの皆様に安心してお使いいただけるようサービスの安定稼動に尽力しています。 ご覧いただきありがとうございました。

こんにちは、インキュベーション本部の加藤です。 2019 年に新卒でメドレーに入社し、間もなく 1 年が経とうとしています。 少し時間が経ってしまったのですが、今回は 1 月に行われたプロダクト開発合宿の様子をお届けします。 プロダクト開発合宿の目的 メドレーでは「1 年間の方針を共有すること」「メンバー間の親睦を深めること」を目的とした開発合宿を、毎年年始に行っています。 合宿の恒例行事となっている「1 年間のプロダクト開発の指針」を CTO 平山がプレゼンし、全員で共有する大切な機会です。 また、親睦を深める観点で、集中して一気に何かを開発するような合宿ではなく、普段あまり体験しないであろうアクティビティが中心です。 アクティビティの紹介 そば打ち体験 今年の合宿のアクティビティは、そば打ち体験でした。 「チームでひとつの作業に臨むことで、普段の業務以外でのメンバー間の絆を深めてもらいたい」という理由から、そば打ちがアクティビティに選ばれました。 今回お世話になった 観音亭 さんは、他ではなかなか経験のできない「石臼挽き」から体験できるおそば屋さんです。 石臼挽きを終えたら、挽いたそば粉をこねて伸ばしていきます。 職人さんの説明をよく聞きながら、普段食べている蕎麦の太さになるように薄く生地を伸ばしていきます。 生地が薄くなりすぎると破れてしまうことも…！ 伸ばした生地を大きな包丁で切れば、見慣れた蕎麦の形になっていきます。 自分たちで打ったそばは、少し太さにばらつきはあるものの、その場で茹でていただきとても美味しくいただくことができました。 他のメンバーもそば打ちを楽しむことができたようで、満足した様子でした。 城ヶ崎海岸を散策 そば打ち体験の後は、サスペンスドラマの撮影で使われることでも有名な城ヶ崎海岸に移動し、周辺を散策しました。 門脇吊り橋という大きな吊り橋を渡って少しスリルを味わいつつ、城ヶ崎海岸の絶景を楽しむことができました。 バーベキュー 夕方には宿泊先に到着し、バーベキューを開始！ お酒を飲んだり、雑談したり…時にはプロダクトや組織について熱く語りあったりと楽しい時間を過ごすことができました。 2020 年キックオフ！ バーベキューの後は CTO 平山から 2020 年に向けてのキックオフです。 まず、2019 年の振り返りから。 昨年はメドレーにとってもプロダクトにとっても大きな変化のある 1 年でした。 会社としては創業 10 周年を迎え、東証マザーズへ上場を果たしました。 ジョブメドレーの大幅な デザインリニューアル や CLINICS の グッドデザイン・ベスト 100 の受賞 など様々なことがあった 1 年でした。 続いて 2020 年について。 詳細は記載できず残念なのですが、なにを目指すのか、それをどう実現していくのか…CTO からのメッセージを全員で確認する良い機会となりました。 普段の業務では目の前のタスクばかりに目が向き、つい視野が狭くなってしまうため、日常や業務を離れて少し引いた目でプロダクトや開発組織のこれからについて考える時間も必要なのだと感じることができました。 まとめ 今回はメドレーのプロダクト開発合宿の様子をお届けしました。 私自身、今回初めての合宿参加でしたが、メンバーと同じ時間を過ごすことで、普段見ることのできない一面を知ることができました。 また、これからの 1 年について考える時間ともなり、2020 年、より良い 1 年にしていきたいです。 最後に、今回の合宿の企画運営をしてくださった前田さん・新居さん、本当にありがとうございました！

こんにちは、インキュベーション本部の加藤です。 2019 年に新卒でメドレーに入社し、間もなく 1 年が経とうとしています。 少し時間が経ってしまったのですが、今回は 1 月に行われたプロダクト開発合宿の様子をお届けします。 プロダクト開発合宿の目的 メドレーでは「1 年間の方針を共有すること」「メンバー間の親睦を深めること」を目的とした開発合宿を、毎年年始に行っています。 合宿の恒例行事となっている「1 年間のプロダクト開発の指針」を CTO 平山がプレゼンし、全員で共有する大切な機会です。 また、親睦を深める観点で、集中して一気に何かを開発するような合宿ではなく、普段あまり体験しないであろうアクティビティが中心です。 アクティビティの紹介 そば打ち体験 今年の合宿のアクティビティは、そば打ち体験でした。 「チームでひとつの作業に臨むことで、普段の業務以外でのメンバー間の絆を深めてもらいたい」という理由から、そば打ちがアクティビティに選ばれました。 今回お世話になった 観音亭 さんは、他ではなかなか経験のできない「石臼挽き」から体験できるおそば屋さんです。 石臼挽きを終えたら、挽いたそば粉をこねて伸ばしていきます。 職人さんの説明をよく聞きながら、普段食べている蕎麦の太さになるように薄く生地を伸ばしていきます。 生地が薄くなりすぎると破れてしまうことも…！ 伸ばした生地を大きな包丁で切れば、見慣れた蕎麦の形になっていきます。 自分たちで打ったそばは、少し太さにばらつきはあるものの、その場で茹でていただきとても美味しくいただくことができました。 他のメンバーもそば打ちを楽しむことができたようで、満足した様子でした。 城ヶ崎海岸を散策 そば打ち体験の後は、サスペンスドラマの撮影で使われることでも有名な城ヶ崎海岸に移動し、周辺を散策しました。 門脇吊り橋という大きな吊り橋を渡って少しスリルを味わいつつ、城ヶ崎海岸の絶景を楽しむことができました。 バーベキュー 夕方には宿泊先に到着し、バーベキューを開始！ お酒を飲んだり、雑談したり…時にはプロダクトや組織について熱く語りあったりと楽しい時間を過ごすことができました。 2020 年キックオフ！ バーベキューの後は CTO 平山から 2020 年に向けてのキックオフです。 まず、2019 年の振り返りから。 昨年はメドレーにとってもプロダクトにとっても大きな変化のある 1 年でした。 会社としては創業 10 周年を迎え、東証マザーズへ上場を果たしました。 ジョブメドレーの大幅な デザインリニューアル や CLINICS の グッドデザイン・ベスト 100 の受賞 など様々なことがあった 1 年でした。 続いて 2020 年について。 詳細は記載できず残念なのですが、なにを目指すのか、それをどう実現していくのか…CTO からのメッセージを全員で確認する良い機会となりました。 普段の業務では目の前のタスクばかりに目が向き、つい視野が狭くなってしまうため、日常や業務を離れて少し引いた目でプロダクトや開発組織のこれからについて考える時間も必要なのだと感じることができました。 まとめ 今回はメドレーのプロダクト開発合宿の様子をお届けしました。 私自身、今回初めての合宿参加でしたが、メンバーと同じ時間を過ごすことで、普段見ることのできない一面を知ることができました。 また、これからの 1 年について考える時間ともなり、2020 年、より良い 1 年にしていきたいです。 最後に、今回の合宿の企画運営をしてくださった前田さん・新居さん、本当にありがとうございました！

こんにちは、インキュベーション本部の加藤です。 2019 年に新卒でメドレーに入社し、間もなく 1 年が経とうとしています。 少し時間が経ってしまったのですが、今回は 1 月に行われたプロダクト開発合宿の様子をお届けします。 プロダクト開発合宿の目的 メドレーでは「1 年間の方針を共有すること」「メンバー間の親睦を深めること」を目的とした開発合宿を、毎年年始に行っています。 合宿の恒例行事となっている「1 年間のプロダクト開発の指針」を CTO 平山がプレゼンし、全員で共有する大切な機会です。 また、親睦を深める観点で、集中して一気に何かを開発するような合宿ではなく、普段あまり体験しないであろうアクティビティが中心です。 アクティビティの紹介 そば打ち体験 今年の合宿のアクティビティは、そば打ち体験でした。 「チームでひとつの作業に臨むことで、普段の業務以外でのメンバー間の絆を深めてもらいたい」という理由から、そば打ちがアクティビティに選ばれました。 今回お世話になった 観音亭 さんは、他ではなかなか経験のできない「石臼挽き」から体験できるおそば屋さんです。 石臼挽きを終えたら、挽いたそば粉をこねて伸ばしていきます。 職人さんの説明をよく聞きながら、普段食べている蕎麦の太さになるように薄く生地を伸ばしていきます。 生地が薄くなりすぎると破れてしまうことも…！ 伸ばした生地を大きな包丁で切れば、見慣れた蕎麦の形になっていきます。 自分たちで打ったそばは、少し太さにばらつきはあるものの、その場で茹でていただきとても美味しくいただくことができました。 他のメンバーもそば打ちを楽しむことができたようで、満足した様子でした。 城ヶ崎海岸を散策 そば打ち体験の後は、サスペンスドラマの撮影で使われることでも有名な城ヶ崎海岸に移動し、周辺を散策しました。 門脇吊り橋という大きな吊り橋を渡って少しスリルを味わいつつ、城ヶ崎海岸の絶景を楽しむことができました。 バーベキュー 夕方には宿泊先に到着し、バーベキューを開始！ お酒を飲んだり、雑談したり…時にはプロダクトや組織について熱く語りあったりと楽しい時間を過ごすことができました。 2020 年キックオフ！ バーベキューの後は CTO 平山から 2020 年に向けてのキックオフです。 まず、2019 年の振り返りから。 昨年はメドレーにとってもプロダクトにとっても大きな変化のある 1 年でした。 会社としては創業 10 周年を迎え、東証マザーズへ上場を果たしました。 ジョブメドレーの大幅な デザインリニューアル や CLINICS の グッドデザイン・ベスト 100 の受賞 など様々なことがあった 1 年でした。 続いて 2020 年について。 詳細は記載できず残念なのですが、なにを目指すのか、それをどう実現していくのか…CTO からのメッセージを全員で確認する良い機会となりました。 普段の業務では目の前のタスクばかりに目が向き、つい視野が狭くなってしまうため、日常や業務を離れて少し引いた目でプロダクトや開発組織のこれからについて考える時間も必要なのだと感じることができました。 まとめ 今回はメドレーのプロダクト開発合宿の様子をお届けしました。 私自身、今回初めての合宿参加でしたが、メンバーと同じ時間を過ごすことで、普段見ることのできない一面を知ることができました。 また、これからの 1 年について考える時間ともなり、2020 年、より良い 1 年にしていきたいです。 最後に、今回の合宿の企画運営をしてくださった前田さん・新居さん、本当にありがとうございました！

こんにちは、インキュベーション本部の加藤です。 2019 年に新卒でメドレーに入社し、間もなく 1 年が経とうとしています。 少し時間が経ってしまったのですが、今回は 1 月に行われたプロダクト開発合宿の様子をお届けします。 プロダクト開発合宿の目的 メドレーでは「1 年間の方針を共有すること」「メンバー間の親睦を深めること」を目的とした開発合宿を、毎年年始に行っています。 合宿の恒例行事となっている「1 年間のプロダクト開発の指針」を CTO 平山がプレゼンし、全員で共有する大切な機会です。 また、親睦を深める観点で、集中して一気に何かを開発するような合宿ではなく、普段あまり体験しないであろうアクティビティが中心です。 アクティビティの紹介 そば打ち体験 今年の合宿のアクティビティは、そば打ち体験でした。 「チームでひとつの作業に臨むことで、普段の業務以外でのメンバー間の絆を深めてもらいたい」という理由から、そば打ちがアクティビティに選ばれました。 今回お世話になった 観音亭 さんは、他ではなかなか経験のできない「石臼挽き」から体験できるおそば屋さんです。 石臼挽きを終えたら、挽いたそば粉をこねて伸ばしていきます。 職人さんの説明をよく聞きながら、普段食べている蕎麦の太さになるように薄く生地を伸ばしていきます。 生地が薄くなりすぎると破れてしまうことも…！ 伸ばした生地を大きな包丁で切れば、見慣れた蕎麦の形になっていきます。 自分たちで打ったそばは、少し太さにばらつきはあるものの、その場で茹でていただきとても美味しくいただくことができました。 他のメンバーもそば打ちを楽しむことができたようで、満足した様子でした。 城ヶ崎海岸を散策 そば打ち体験の後は、サスペンスドラマの撮影で使われることでも有名な城ヶ崎海岸に移動し、周辺を散策しました。 門脇吊り橋という大きな吊り橋を渡って少しスリルを味わいつつ、城ヶ崎海岸の絶景を楽しむことができました。 バーベキュー 夕方には宿泊先に到着し、バーベキューを開始！ お酒を飲んだり、雑談したり…時にはプロダクトや組織について熱く語りあったりと楽しい時間を過ごすことができました。 2020 年キックオフ！ バーベキューの後は CTO 平山から 2020 年に向けてのキックオフです。 まず、2019 年の振り返りから。 昨年はメドレーにとってもプロダクトにとっても大きな変化のある 1 年でした。 会社としては創業 10 周年を迎え、東証マザーズへ上場を果たしました。 ジョブメドレーの大幅な デザインリニューアル や CLINICS の グッドデザイン・ベスト 100 の受賞 など様々なことがあった 1 年でした。 続いて 2020 年について。 詳細は記載できず残念なのですが、なにを目指すのか、それをどう実現していくのか…CTO からのメッセージを全員で確認する良い機会となりました。 普段の業務では目の前のタスクばかりに目が向き、つい視野が狭くなってしまうため、日常や業務を離れて少し引いた目でプロダクトや開発組織のこれからについて考える時間も必要なのだと感じることができました。 まとめ 今回はメドレーのプロダクト開発合宿の様子をお届けしました。 私自身、今回初めての合宿参加でしたが、メンバーと同じ時間を過ごすことで、普段見ることのできない一面を知ることができました。 また、これからの 1 年について考える時間ともなり、2020 年、より良い 1 年にしていきたいです。 最後に、今回の合宿の企画運営をしてくださった前田さん・新居さん、本当にありがとうございました！

こんにちは、インキュベーション本部の加藤です。 2019 年に新卒でメドレーに入社し、間もなく 1 年が経とうとしています。 少し時間が経ってしまったのですが、今回は 1 月に行われたプロダクト開発合宿の様子をお届けします。 プロダクト開発合宿の目的 メドレーでは「1 年間の方針を共有すること」「メンバー間の親睦を深めること」を目的とした開発合宿を、毎年年始に行っています。 合宿の恒例行事となっている「1 年間のプロダクト開発の指針」を CTO 平山がプレゼンし、全員で共有する大切な機会です。 また、親睦を深める観点で、集中して一気に何かを開発するような合宿ではなく、普段あまり体験しないであろうアクティビティが中心です。 アクティビティの紹介 そば打ち体験 今年の合宿のアクティビティは、そば打ち体験でした。 「チームでひとつの作業に臨むことで、普段の業務以外でのメンバー間の絆を深めてもらいたい」という理由から、そば打ちがアクティビティに選ばれました。 今回お世話になった 観音亭 さんは、他ではなかなか経験のできない「石臼挽き」から体験できるおそば屋さんです。 石臼挽きを終えたら、挽いたそば粉をこねて伸ばしていきます。 職人さんの説明をよく聞きながら、普段食べている蕎麦の太さになるように薄く生地を伸ばしていきます。 生地が薄くなりすぎると破れてしまうことも…！ 伸ばした生地を大きな包丁で切れば、見慣れた蕎麦の形になっていきます。 自分たちで打ったそばは、少し太さにばらつきはあるものの、その場で茹でていただきとても美味しくいただくことができました。 他のメンバーもそば打ちを楽しむことができたようで、満足した様子でした。 城ヶ崎海岸を散策 そば打ち体験の後は、サスペンスドラマの撮影で使われることでも有名な城ヶ崎海岸に移動し、周辺を散策しました。 門脇吊り橋という大きな吊り橋を渡って少しスリルを味わいつつ、城ヶ崎海岸の絶景を楽しむことができました。 バーベキュー 夕方には宿泊先に到着し、バーベキューを開始！ お酒を飲んだり、雑談したり…時にはプロダクトや組織について熱く語りあったりと楽しい時間を過ごすことができました。 2020 年キックオフ！ バーベキューの後は CTO 平山から 2020 年に向けてのキックオフです。 まず、2019 年の振り返りから。 昨年はメドレーにとってもプロダクトにとっても大きな変化のある 1 年でした。 会社としては創業 10 周年を迎え、東証マザーズへ上場を果たしました。 ジョブメドレーの大幅な デザインリニューアル や CLINICS の グッドデザイン・ベスト 100 の受賞 など様々なことがあった 1 年でした。 続いて 2020 年について。 詳細は記載できず残念なのですが、なにを目指すのか、それをどう実現していくのか…CTO からのメッセージを全員で確認する良い機会となりました。 普段の業務では目の前のタスクばかりに目が向き、つい視野が狭くなってしまうため、日常や業務を離れて少し引いた目でプロダクトや開発組織のこれからについて考える時間も必要なのだと感じることができました。 まとめ 今回はメドレーのプロダクト開発合宿の様子をお届けしました。 私自身、今回初めての合宿参加でしたが、メンバーと同じ時間を過ごすことで、普段見ることのできない一面を知ることができました。 また、これからの 1 年について考える時間ともなり、2020 年、より良い 1 年にしていきたいです。 最後に、今回の合宿の企画運営をしてくださった前田さん・新居さん、本当にありがとうございました！

こんにちは、インキュベーション本部の加藤です。 2019 年に新卒でメドレーに入社し、間もなく 1 年が経とうとしています。 少し時間が経ってしまったのですが、今回は 1 月に行われたプロダクト開発合宿の様子をお届けします。 プロダクト開発合宿の目的 メドレーでは「1 年間の方針を共有すること」「メンバー間の親睦を深めること」を目的とした開発合宿を、毎年年始に行っています。 合宿の恒例行事となっている「1 年間のプロダクト開発の指針」を CTO 平山がプレゼンし、全員で共有する大切な機会です。 また、親睦を深める観点で、集中して一気に何かを開発するような合宿ではなく、普段あまり体験しないであろうアクティビティが中心です。 アクティビティの紹介 そば打ち体験 今年の合宿のアクティビティは、そば打ち体験でした。 「チームでひとつの作業に臨むことで、普段の業務以外でのメンバー間の絆を深めてもらいたい」という理由から、そば打ちがアクティビティに選ばれました。 今回お世話になった 観音亭 さんは、他ではなかなか経験のできない「石臼挽き」から体験できるおそば屋さんです。 石臼挽きを終えたら、挽いたそば粉をこねて伸ばしていきます。 職人さんの説明をよく聞きながら、普段食べている蕎麦の太さになるように薄く生地を伸ばしていきます。 生地が薄くなりすぎると破れてしまうことも…！ 伸ばした生地を大きな包丁で切れば、見慣れた蕎麦の形になっていきます。 自分たちで打ったそばは、少し太さにばらつきはあるものの、その場で茹でていただきとても美味しくいただくことができました。 他のメンバーもそば打ちを楽しむことができたようで、満足した様子でした。 城ヶ崎海岸を散策 そば打ち体験の後は、サスペンスドラマの撮影で使われることでも有名な城ヶ崎海岸に移動し、周辺を散策しました。 門脇吊り橋という大きな吊り橋を渡って少しスリルを味わいつつ、城ヶ崎海岸の絶景を楽しむことができました。 バーベキュー 夕方には宿泊先に到着し、バーベキューを開始！ お酒を飲んだり、雑談したり…時にはプロダクトや組織について熱く語りあったりと楽しい時間を過ごすことができました。 2020 年キックオフ！ バーベキューの後は CTO 平山から 2020 年に向けてのキックオフです。 まず、2019 年の振り返りから。 昨年はメドレーにとってもプロダクトにとっても大きな変化のある 1 年でした。 会社としては創業 10 周年を迎え、東証マザーズへ上場を果たしました。 ジョブメドレーの大幅な デザインリニューアル や CLINICS の グッドデザイン・ベスト 100 の受賞 など様々なことがあった 1 年でした。 続いて 2020 年について。 詳細は記載できず残念なのですが、なにを目指すのか、それをどう実現していくのか…CTO からのメッセージを全員で確認する良い機会となりました。 普段の業務では目の前のタスクばかりに目が向き、つい視野が狭くなってしまうため、日常や業務を離れて少し引いた目でプロダクトや開発組織のこれからについて考える時間も必要なのだと感じることができました。 まとめ 今回はメドレーのプロダクト開発合宿の様子をお届けしました。 私自身、今回初めての合宿参加でしたが、メンバーと同じ時間を過ごすことで、普段見ることのできない一面を知ることができました。 また、これからの 1 年について考える時間ともなり、2020 年、より良い 1 年にしていきたいです。 最後に、今回の合宿の企画運営をしてくださった前田さん・新居さん、本当にありがとうございました！

こんにちは、インキュベーション本部の加藤です。 2019 年に新卒でメドレーに入社し、間もなく 1 年が経とうとしています。 少し時間が経ってしまったのですが、今回は 1 月に行われたプロダクト開発合宿の様子をお届けします。 プロダクト開発合宿の目的 メドレーでは「1 年間の方針を共有すること」「メンバー間の親睦を深めること」を目的とした開発合宿を、毎年年始に行っています。 合宿の恒例行事となっている「1 年間のプロダクト開発の指針」を CTO 平山がプレゼンし、全員で共有する大切な機会です。 また、親睦を深める観点で、集中して一気に何かを開発するような合宿ではなく、普段あまり体験しないであろうアクティビティが中心です。 アクティビティの紹介 そば打ち体験 今年の合宿のアクティビティは、そば打ち体験でした。 「チームでひとつの作業に臨むことで、普段の業務以外でのメンバー間の絆を深めてもらいたい」という理由から、そば打ちがアクティビティに選ばれました。 今回お世話になった 観音亭 さんは、他ではなかなか経験のできない「石臼挽き」から体験できるおそば屋さんです。 石臼挽きを終えたら、挽いたそば粉をこねて伸ばしていきます。 職人さんの説明をよく聞きながら、普段食べている蕎麦の太さになるように薄く生地を伸ばしていきます。 生地が薄くなりすぎると破れてしまうことも…！ 伸ばした生地を大きな包丁で切れば、見慣れた蕎麦の形になっていきます。 自分たちで打ったそばは、少し太さにばらつきはあるものの、その場で茹でていただきとても美味しくいただくことができました。 他のメンバーもそば打ちを楽しむことができたようで、満足した様子でした。 城ヶ崎海岸を散策 そば打ち体験の後は、サスペンスドラマの撮影で使われることでも有名な城ヶ崎海岸に移動し、周辺を散策しました。 門脇吊り橋という大きな吊り橋を渡って少しスリルを味わいつつ、城ヶ崎海岸の絶景を楽しむことができました。 バーベキュー 夕方には宿泊先に到着し、バーベキューを開始！ お酒を飲んだり、雑談したり…時にはプロダクトや組織について熱く語りあったりと楽しい時間を過ごすことができました。 2020 年キックオフ！ バーベキューの後は CTO 平山から 2020 年に向けてのキックオフです。 まず、2019 年の振り返りから。 昨年はメドレーにとってもプロダクトにとっても大きな変化のある 1 年でした。 会社としては創業 10 周年を迎え、東証マザーズへ上場を果たしました。 ジョブメドレーの大幅な デザインリニューアル や CLINICS の グッドデザイン・ベスト 100 の受賞 など様々なことがあった 1 年でした。 続いて 2020 年について。 詳細は記載できず残念なのですが、なにを目指すのか、それをどう実現していくのか…CTO からのメッセージを全員で確認する良い機会となりました。 普段の業務では目の前のタスクばかりに目が向き、つい視野が狭くなってしまうため、日常や業務を離れて少し引いた目でプロダクトや開発組織のこれからについて考える時間も必要なのだと感じることができました。 まとめ 今回はメドレーのプロダクト開発合宿の様子をお届けしました。 私自身、今回初めての合宿参加でしたが、メンバーと同じ時間を過ごすことで、普段見ることのできない一面を知ることができました。 また、これからの 1 年について考える時間ともなり、2020 年、より良い 1 年にしていきたいです。 最後に、今回の合宿の企画運営をしてくださった前田さん・新居さん、本当にありがとうございました！

こんにちは、インキュベーション本部の加藤です。 2019 年に新卒でメドレーに入社し、間もなく 1 年が経とうとしています。 少し時間が経ってしまったのですが、今回は 1 月に行われたプロダクト開発合宿の様子をお届けします。 プロダクト開発合宿の目的 メドレーでは「1 年間の方針を共有すること」「メンバー間の親睦を深めること」を目的とした開発合宿を、毎年年始に行っています。 合宿の恒例行事となっている「1 年間のプロダクト開発の指針」を CTO 平山がプレゼンし、全員で共有する大切な機会です。 また、親睦を深める観点で、集中して一気に何かを開発するような合宿ではなく、普段あまり体験しないであろうアクティビティが中心です。 アクティビティの紹介 そば打ち体験 今年の合宿のアクティビティは、そば打ち体験でした。 「チームでひとつの作業に臨むことで、普段の業務以外でのメンバー間の絆を深めてもらいたい」という理由から、そば打ちがアクティビティに選ばれました。 今回お世話になった 観音亭 さんは、他ではなかなか経験のできない「石臼挽き」から体験できるおそば屋さんです。 石臼挽きを終えたら、挽いたそば粉をこねて伸ばしていきます。 職人さんの説明をよく聞きながら、普段食べている蕎麦の太さになるように薄く生地を伸ばしていきます。 生地が薄くなりすぎると破れてしまうことも…！ 伸ばした生地を大きな包丁で切れば、見慣れた蕎麦の形になっていきます。 自分たちで打ったそばは、少し太さにばらつきはあるものの、その場で茹でていただきとても美味しくいただくことができました。 他のメンバーもそば打ちを楽しむことができたようで、満足した様子でした。 城ヶ崎海岸を散策 そば打ち体験の後は、サスペンスドラマの撮影で使われることでも有名な城ヶ崎海岸に移動し、周辺を散策しました。 門脇吊り橋という大きな吊り橋を渡って少しスリルを味わいつつ、城ヶ崎海岸の絶景を楽しむことができました。 バーベキュー 夕方には宿泊先に到着し、バーベキューを開始！ お酒を飲んだり、雑談したり…時にはプロダクトや組織について熱く語りあったりと楽しい時間を過ごすことができました。 2020 年キックオフ！ バーベキューの後は CTO 平山から 2020 年に向けてのキックオフです。 まず、2019 年の振り返りから。 昨年はメドレーにとってもプロダクトにとっても大きな変化のある 1 年でした。 会社としては創業 10 周年を迎え、東証マザーズへ上場を果たしました。 ジョブメドレーの大幅な デザインリニューアル や CLINICS の グッドデザイン・ベスト 100 の受賞 など様々なことがあった 1 年でした。 続いて 2020 年について。 詳細は記載できず残念なのですが、なにを目指すのか、それをどう実現していくのか…CTO からのメッセージを全員で確認する良い機会となりました。 普段の業務では目の前のタスクばかりに目が向き、つい視野が狭くなってしまうため、日常や業務を離れて少し引いた目でプロダクトや開発組織のこれからについて考える時間も必要なのだと感じることができました。 まとめ 今回はメドレーのプロダクト開発合宿の様子をお届けしました。 私自身、今回初めての合宿参加でしたが、メンバーと同じ時間を過ごすことで、普段見ることのできない一面を知ることができました。 また、これからの 1 年について考える時間ともなり、2020 年、より良い 1 年にしていきたいです。 最後に、今回の合宿の企画運営をしてくださった前田さん・新居さん、本当にありがとうございました！

こんにちは。エンジニアの平木です。 メドレーでは今年度より新卒採用活動を本格化しており、今年はエンジニア 4 名が新卒社員として入社しました。 現在、新卒メンバーは 6 ヶ月の開発研修が無事終了し、各部署で業務に勤しんでいますが、このエントリでは、**初めての新卒研修をどのような視点で計画・実行していったか?**を書いていきたいと思います。 2019 年度新卒入社メンバー 新卒研修を決めるまでやったこと 研修の大枠決定 カリキュラムの大枠を決めるため、まず CTO の平山が「こんなことをやろう」という大枠の方向性を出し、施策レベルに筆者が落としこんでいきました。 決めたことは、以下３点です。 入社後の導入部分 社会人としてのビジネスマナーや考え方の基礎を学ぶ プロダクト開発をする上で必要になる基礎を学ぶ 会社の事業内容を理解する OJT をメインとした各チームへの仮配属 新卒社員へのフォローアップ メンターや部長との定期報告会 半年後に役員陣への成果報告会 エンジニアとして価値を出していくため必要な**「社会の課題を解決するために、日々自身の腕を磨き、純粋に取り組む、ただそれだけ」**という、メドレーが求めるエンジニアとしての姿勢をきちんと体得してもらうことが目標です。 こちらについては平山のブログに詳しく書かれているので、ぜひご参照ください。 https://toppa.medley.jp/05.html 情報収集 社内エンジニアへのヒアリング 前職で新卒研修を受けたことがある社内の 20 代~30 代のエンジニア 4 人を対象に、研修内容についてヒアリングしました。 ヒアリングしたポイントは 研修の期間 研修全体の流れ 各研修メニューの内容 OJT はどういった形で受けたか 研修を受けての感想 など。各社・各年代で個性が出るなという印象を持ちました。 やはり、エンジニアということで座学よりも手を動かすハンズオン形式の方が印象に残ることや、印象的な研修メニューは時間が経っても覚えているという傾向が分かりました。 ネットでの情報収集 ご存知の通り、近年では新卒研修のブログや、学習プログラムに関しては多くの企業様が書かれています。 しかし、内容としては**「アプリ開発をこのような形式で行ないました」という情報が多く、研修全体や社内情勢も踏まえた背景などが書かれているものは意外に少ないな**という印象を持ちました。 そんな中、各社の新卒研修エントリが Gist にまとめられているのを発見しました。 こちらは大変参考になりました。作者の方にはこの場をお借りして感謝させていただきます。 https://gist.github.com/gcchaan/02f4746a323acac4095c30e0783a3912 研修メニュー決定 研修の詳細メニュー ここまでの過程を踏まえ研修メニューを筆者が考え、CTO や開発部部長の田中・副部長の稲本と刷り合わせをしていきました。 結果として、以下のメニュー構成でいくことになりました。 オリエンテーション **[座学]**社会人研修や会社全般の知識の習得を目的にする 開発基礎研修 **[座学]**Web アプリケーション開発の基本や、エンジニアとしての心得、会社の展開するサービスの基本知識を習得することを目的にする 開発実践研修 **[OJT]**社内向けに Web アプリケーションを開発し、チーム開発を実践することを目的にする 開発部 OJT **[OJT]**稼動しているサービスの開発を通して、業務としての開発を実践することを目的にする 事業部 OJT **[OJT]**ビジネスサイドの業務を体験し、開発以外の会社の業務の全体像を理解することを目的にする 特に事業部 OJT は新卒メンバーには必ず理解してもらいたい、と決まった研修項目です。 メドレーではプロダクトファーストで開発しますが、プロダクトの機能や要望は実際のビジネスの流れと密接に関わっています。 新卒メンバーもこういった流れを把握出来ていないと、要点を押さえた開発ができません。 実際にどのような流れで顧客と関わっていき、自分達が開発するプロダクトにどう影響していくかを体験 してもらうために、この事業部 OJT をメニューに組み込みました。 研修期間 研修の期間についても様々な意見が出ましたが、最終的には配属後の業務にスムーズに入ってもらえるように、基礎を重視して長めに研修時間を取ったほうがよいと決め、以下の通り全 6 ヶ月という研修期間を定めました。 オリエンテーション・開発基礎研修・開発実践研修 2 ヶ月 期間中、午前：開発基礎、午後：開発実践 開発部 OJT ・事業部 OJT 4 ヶ月 事業部 OJT は期間中に 2 週間 x 2 つの事業部で実施 メンター 研修全体の統括は筆者になりますが、新卒メンバーがいつでも相談できるように 1 人につき 1 人のメンターを付けています。社会人経験が 3 年以上ある社員をメンターとしました。 最初の 2 週は毎日 1on1 を 15 分程度行ない、以降は毎週金曜日に 1 時間の 1on1 を実施。 また、メンター同士の交流として、2 週に 1 度メンターの共有会を開き、相談や近況報告を行いました。 メンター制自体も初めての試みだったためメンター同士の対応内容や新卒全員の様子が共有される場作りは、実施してよかったです。 研修メニュー内容 各研修内容のご紹介です。 オリエンテーション オリエンテーションは 外部ビジネス研修 コンプライアンス研修 セキュリティ研修 開発環境の整備 開発ツールの解説 がメインです。 Mac を渡されて、「勝手に開発環境作ってね」というのは新卒エンジニアにはハードルが高いので、筆者が付きっきりで時間をかけてフォローしました。 オリエンテーションは約 1 週間程度ですが、ここで「メドレー社員の一人になった」という実感を持ってもらう ことができました。 開発基礎研修 大きく 2 部構成です。最初の部では、メドレーでエンジニアに期待していることや、既存サービスなどのシステム構成・ビジネスの流れなどを座学で実施しました。 もう一つの部では書籍の輪読をしました。この輪読は、Web サービスの基本の仕組みと、Web サーバ自体を支える OS である Linux の基本を覚えてもらいたいという趣旨で開催しました。 メドレーについて こちらの部では CTO 平山から「メドレーのエンジニアとして求めること」と題して、求められるエンジニアリングとは何なのか?自分達のキャリアパスなどをディスカッションしました。 その後は、 ジョブメドレー ・ CLINICS ・ 介護のほんね などメドレーが提供しているプロダクトについて、システムの概要やビジネスモデルとシステムの対応について講義。 メドレーでのエンジニアは各々専門性がある技術領域を持ちつつ、その領域に限定せずに広い分野で開発をしていますし、プロダクトを第一に考え開発しますが、そのために技術を武器としていくバランス感覚が必要になります。 この段階でまずこうした メドレーでエンジニアとして働くとはどういうことなのか という知識や考え方を新卒メンバーに勉強してもらいました。 エンジニアとは何か エンジニアの価値は何か プロエンジニアとは何か エンジニアではない職種との違いは何か といった基本的な話から、 2030 年のみんなはどうなっているのか、どうなっていたいのか 先輩エンジニアはどのようなことに悩み、どのようにアプローチをして、力をつけてきたのか、それを超えるためのヒントはどこにあるか メドレーのエンジニアとして求めたいことは何か といった踏み込んだ話も含め、個人ワークやグループワークも交えながら伝えていきました。 導入があることで、これからのカリキュラムを実施していく上での心構えができる期間だったのではないかと思います。 輪読会 座学でプログラミングのことを勉強させるのではなく、主体性を持ち、基礎知識を習得してほしいと考えていたので、 プランを作っている初期段階から輪読会をすることを決めていました。 参考にさせていただいたのは ドワンゴさんの 2016 年の研修の記事 です。 輪読で使用する本の選定は悩んだのですが、弊社で使っている Ruby や Ruby on Rails のことや、JavaScript などの技術より、基本となる Web 自体についての知識や、Web サーバで使う Linux の事などを習得してもらいたいということを考えて以下の 2 冊で輪読を行いました。 Web を支える技術 ── HTTP，URI，HTML，そして REST（WEB+DB PRESS plus シリーズ） Go ならわかるシステムプログラミング 「Web を支える技術」の輪読の形式は毎回決まった章を筆者が講義しつつ、時折質問などをメンバーに投げかけたりしながら理解を深めました。 議事録も新卒メンバー全員で順番を決めてもらうという、自主性に基づくスタイルにしました。 まず輪読の雰囲気になれてもらうこと、それから議事録を取りつつドキュメンテーションの練習をすること を狙いとしています。 最初はぎこちなかった部分もありましたが、回を重ねるにつれて、自分の経験や知識も含めたディスカッションにも発展するようになり、全員自主性を持ちながら実施できました。 対して「Go ならわかるシステムプログラミング」については 新卒メンバーに章を割り当てて、各自講師をしてもらいました。 元々レポートを 3 回発表することを予定していたので、本の内容を読んできちんと理解した上で、 他人へ伝える力を養う ことをサブ目標にしています。 さらなる自主性も必要になる上、本の性質上ほとんどのメンバーが触っていない Go 言語を使ってプログラムを書いてシステムのことを理解しないといけない為、プログラムの本質的な部分に触れることもできたのではないかと思います。 開発実践 開発実践は上記の開発基礎と並行して午後から実施しました。 1 日の午前が開発基礎、午後が開発実践というスケジュールです。 実践は新卒メンバーで社内ツールを実際の業務形式で開発してもらいました。 題材は**「メドレーの使い方に合ったビルの予約システムを作る」**というものです(以前 SmartHR さんが同じビルだったので少しアプローチが違いますが ブログ に書いてました)。 メドレーでの業務開発と同じ形式で ユーザーからの要望をヒアリング 要件定義 開発計画の策定 システム設計 チームで分担してながらの開発 ベータ版としてリリースしたものをブラッシュアップ 実稼働するための環境整備をしながらリリースする という一連のプロセスで開発しました。 「開発自体どうやって進めるか」「仕様をどうするか」など基本的な所から、全行程を新卒メンバー主体で考えて実行してもらい、メンター陣は所々 MTG や PR をレビューしながら、アドバイスをするという形式で行いました。 新卒メンバー全員が同じスキルセットを持っているわけでもないですし、得意・不得意も違う為、まず最初に彼ら自身にリーダーを決めてもらい、リーダーがオーナーシップを持って開発を進めてもらいました。 チームでの開発というのはほとんど全員が初めてだったため、かなり困惑しているところもありましたが、研修の過程で理解した互いのスペシャリティを活かして、役割分担をしつつ、決まった納期にきちんとリリースすることができました。メンターとしてそばで見ていましたが、新卒メンバー全員の成長を実感しましたし、純粋に凄いと感じました。 途中で納期に間に合わせるための要件の取捨選択をしなければならなかったり、自分達が考えた仕様が必ずしもベストというわけではなく、さらに色々と考える要素が必要だったりという 開発のリアルを経験できた のは次の OJT に活きたと思います。 余談ですが、こちらの元々のシステムを調査する上で「Web を支える技術」の知識が早速役に立つという場面が多く、やはり 基本は大事だな、と思った 次第です。 開発部 OJT 基礎研修が終わってから、既存サービスにジョインしての OJT 実施となりました。 ここまでの研修で、ある程度の知識や業務の進め方などは習得していたので、何をすればよいか分からないということはありませんでした。 メンバーによってはここで時間を取って Ruby on Rails について習得をしてもらいました。 大きい失敗なども特にはなく粛々と進められたのは良かったのではないかと思います。 事業部 OJT 開発部 OJT の途中で 2 週間ずつ時間を取って、人材プラットフォーム事業と医療メディア事業での事業部 OJT を行いました。 **どこで顧客とコンタクトし、お金をいただき、どのような形で自分達が作ったシステムに関わっていくのか?**というのをこの時期に体験してもらうことが目的です。 研修はビジネスの流れに沿って行ないました。研修メニューは、事業部の主要メンバーにコンセプトの共有をし、メニューを考えて実施してもらいました。（ありがとうございます！） 実際に電話でアポイントを取ったり、顧客のサポートを電話やビデオチャットでしたり、営業をどうやっているのかを体験したり…などを 2 週間かけて新卒メンバーに体験してもらいました。 この後に実際**「このシステムの機能はこういうときに使うのかと実感した」とか「やっていてこのような仕様のほうが良いと思った」などの感想**をそれぞれのメンバーが持っていて、やはり実施して良かったなと強く感じました。 レポート発表 それぞれの研修の終わりにはレポート発表の時間を設け、一人一人振り返りを書いてもらいます。その為に週報の提出も義務付けました。また研修期間の終了時には弊社役員陣にプレゼンする最終レポート発表の時間を取りました。 ひたすら研修内容をこなしていくという形になりがちなので、 振り返りの期間を設けて記録を付けていき、自分の成長や反省などを可視化したい という目的です。 また、メドレーでは ドキュメントドリブンで開発に限らず全社員が Confluence でドキュメントを書いていく文化 なので、文書を誰にでも分かるように論理的に書く技術が求められます。こういったレポートの記述やそのフィードバックから文書技術を高めてほしいという目的もありました。 レポートに関してはメンター陣やマネージャ陣に発表してもらうという形にしていたので、発表自体やレポートのまとめ方などに都度フィードバックをするようにしました。 最初はレポートが読みづらいなどもありましたが、回を重ねるごとに段々洗練されたレポートや発表になってきたのが印象的 です。 最終レポートは代表を始めとした経営陣に向けてレポートを発表してもらいました。今まで自分達がやってきた全ての業務を、前提の知識がない聴衆に向けて発表するということで、各自が趣向を凝らしての発表になり、経営陣からも高評価をもらっていました。 まとめ メドレーで初の新卒研修は以上のような形で終わることができました。 かなりのハードスケジュールだったとか、開発部 OJT をもう少し現場と色々と話しあったほうが効果的だったかもなど反省点もありますが、現在新卒メンバーが 10 月から実際の業務で活躍しているところを見ているので、ある程度の成功を収めることができたのではないかと思います。 来年度のメニューはまた違ったものになる可能性がありますが、今年の研修でも重視した**「メドレーでエンジニアとして働くことに対する意義を感じながら業務をしてもらう」**という部分はズラさずに実施していければと思います。 長々とお付き合いいただきありがとうございました。

こんにちは。エンジニアの平木です。 メドレーでは今年度より新卒採用活動を本格化しており、今年はエンジニア 4 名が新卒社員として入社しました。 現在、新卒メンバーは 6 ヶ月の開発研修が無事終了し、各部署で業務に勤しんでいますが、このエントリでは、**初めての新卒研修をどのような視点で計画・実行していったか?**を書いていきたいと思います。 2019 年度新卒入社メンバー 新卒研修を決めるまでやったこと 研修の大枠決定 カリキュラムの大枠を決めるため、まず CTO の平山が「こんなことをやろう」という大枠の方向性を出し、施策レベルに筆者が落としこんでいきました。 決めたことは、以下３点です。 入社後の導入部分 社会人としてのビジネスマナーや考え方の基礎を学ぶ プロダクト開発をする上で必要になる基礎を学ぶ 会社の事業内容を理解する OJT をメインとした各チームへの仮配属 新卒社員へのフォローアップ メンターや部長との定期報告会 半年後に役員陣への成果報告会 エンジニアとして価値を出していくため必要な**「社会の課題を解決するために、日々自身の腕を磨き、純粋に取り組む、ただそれだけ」**という、メドレーが求めるエンジニアとしての姿勢をきちんと体得してもらうことが目標です。 こちらについては平山のブログに詳しく書かれているので、ぜひご参照ください。 toppa.medley.jp toppa.medley.jp 情報収集 社内エンジニアへのヒアリング 前職で新卒研修を受けたことがある社内の 20 代~30 代のエンジニア 4 人を対象に、研修内容についてヒアリングしました。 ヒアリングしたポイントは 研修の期間 研修全体の流れ 各研修メニューの内容 OJT はどういった形で受けたか 研修を受けての感想 など。各社・各年代で個性が出るなという印象を持ちました。 やはり、エンジニアということで座学よりも手を動かすハンズオン形式の方が印象に残ることや、印象的な研修メニューは時間が経っても覚えているという傾向が分かりました。 ネットでの情報収集 ご存知の通り、近年では新卒研修のブログや、学習プログラムに関しては多くの企業様が書かれています。 しかし、内容としては**「アプリ開発をこのような形式で行ないました」という情報が多く、研修全体や社内情勢も踏まえた背景などが書かれているものは意外に少ないな**という印象を持ちました。 そんな中、各社の新卒研修エントリが Gist にまとめられているのを発見しました。 こちらは大変参考になりました。作者の方にはこの場をお借りして感謝させていただきます。 研修資料まとめ.md GitHub Gist: instantly share code, notes, and snippets. gist.github.com 研修メニュー決定 研修の詳細メニュー ここまでの過程を踏まえ研修メニューを筆者が考え、CTO や開発部部長の田中・副部長の稲本と刷り合わせをしていきました。 結果として、以下のメニュー構成でいくことになりました。 オリエンテーション **[座学]**社会人研修や会社全般の知識の習得を目的にする 開発基礎研修 **[座学]**Web アプリケーション開発の基本や、エンジニアとしての心得、会社の展開するサービスの基本知識を習得することを目的にする 開発実践研修 **[OJT]**社内向けに Web アプリケーションを開発し、チーム開発を実践することを目的にする 開発部 OJT **[OJT]**稼動しているサービスの開発を通して、業務としての開発を実践することを目的にする 事業部 OJT **[OJT]**ビジネスサイドの業務を体験し、開発以外の会社の業務の全体像を理解することを目的にする 特に事業部 OJT は新卒メンバーには必ず理解してもらいたい、と決まった研修項目です。 メドレーではプロダクトファーストで開発しますが、プロダクトの機能や要望は実際のビジネスの流れと密接に関わっています。 新卒メンバーもこういった流れを把握出来ていないと、要点を押さえた開発ができません。 実際にどのような流れで顧客と関わっていき、自分達が開発するプロダクトにどう影響していくかを体験 してもらうために、この事業部 OJT をメニューに組み込みました。 研修期間 研修の期間についても様々な意見が出ましたが、最終的には配属後の業務にスムーズに入ってもらえるように、基礎を重視して長めに研修時間を取ったほうがよいと決め、以下の通り全 6 ヶ月という研修期間を定めました。 オリエンテーション・開発基礎研修・開発実践研修 2 ヶ月 期間中、午前：開発基礎、午後：開発実践 開発部 OJT ・事業部 OJT 4 ヶ月 事業部 OJT は期間中に 2 週間 x 2 つの事業部で実施 メンター 研修全体の統括は筆者になりますが、新卒メンバーがいつでも相談できるように 1 人につき 1 人のメンターを付けています。社会人経験が 3 年以上ある社員をメンターとしました。 最初の 2 週は毎日 1on1 を 15 分程度行ない、以降は毎週金曜日に 1 時間の 1on1 を実施。 また、メンター同士の交流として、2 週に 1 度メンターの共有会を開き、相談や近況報告を行いました。 メンター制自体も初めての試みだったためメンター同士の対応内容や新卒全員の様子が共有される場作りは、実施してよかったです。 研修メニュー内容 各研修内容のご紹介です。 オリエンテーション オリエンテーションは 外部ビジネス研修 コンプライアンス研修 セキュリティ研修 開発環境の整備 開発ツールの解説 がメインです。 Mac を渡されて、「勝手に開発環境作ってね」というのは新卒エンジニアにはハードルが高いので、筆者が付きっきりで時間をかけてフォローしました。 オリエンテーションは約 1 週間程度ですが、ここで「メドレー社員の一人になった」という実感を持ってもらう ことができました。 開発基礎研修 大きく 2 部構成です。最初の部では、メドレーでエンジニアに期待していることや、既存サービスなどのシステム構成・ビジネスの流れなどを座学で実施しました。 もう一つの部では書籍の輪読をしました。この輪読は、Web サービスの基本の仕組みと、Web サーバ自体を支える OS である Linux の基本を覚えてもらいたいという趣旨で開催しました。 メドレーについて こちらの部では CTO 平山から「メドレーのエンジニアとして求めること」と題して、求められるエンジニアリングとは何なのか?自分達のキャリアパスなどをディスカッションしました。 その後は、 ジョブメドレー ・ CLINICS ・ 介護のほんね などメドレーが提供しているプロダクトについて、システムの概要やビジネスモデルとシステムの対応について講義。 メドレーでのエンジニアは各々専門性がある技術領域を持ちつつ、その領域に限定せずに広い分野で開発をしていますし、プロダクトを第一に考え開発しますが、そのために技術を武器としていくバランス感覚が必要になります。 この段階でまずこうした メドレーでエンジニアとして働くとはどういうことなのか という知識や考え方を新卒メンバーに勉強してもらいました。 エンジニアとは何か エンジニアの価値は何か プロエンジニアとは何か エンジニアではない職種との違いは何か といった基本的な話から、 2030 年のみんなはどうなっているのか、どうなっていたいのか 先輩エンジニアはどのようなことに悩み、どのようにアプローチをして、力をつけてきたのか、それを超えるためのヒントはどこにあるか メドレーのエンジニアとして求めたいことは何か といった踏み込んだ話も含め、個人ワークやグループワークも交えながら伝えていきました。 導入があることで、これからのカリキュラムを実施していく上での心構えができる期間だったのではないかと思います。 輪読会 座学でプログラミングのことを勉強させるのではなく、主体性を持ち、基礎知識を習得してほしいと考えていたので、 プランを作っている初期段階から輪読会をすることを決めていました。 参考にさせていただいたのは ドワンゴさんの 2016 年の研修の記事 です。 輪読で使用する本の選定は悩んだのですが、弊社で使っている Ruby や Ruby on Rails のことや、JavaScript などの技術より、基本となる Web 自体についての知識や、Web サーバで使う Linux の事などを習得してもらいたいということを考えて以下の 2 冊で輪読を行いました。 Web を支える技術 ── HTTP，URI，HTML，そして REST（WEB+DB PRESS plus シリーズ） Go ならわかるシステムプログラミング 「Web を支える技術」の輪読の形式は毎回決まった章を筆者が講義しつつ、時折質問などをメンバーに投げかけたりしながら理解を深めました。 議事録も新卒メンバー全員で順番を決めてもらうという、自主性に基づくスタイルにしました。 まず輪読の雰囲気になれてもらうこと、それから議事録を取りつつドキュメンテーションの練習をすること を狙いとしています。 最初はぎこちなかった部分もありましたが、回を重ねるにつれて、自分の経験や知識も含めたディスカッションにも発展するようになり、全員自主性を持ちながら実施できました。 対して「Go ならわかるシステムプログラミング」については 新卒メンバーに章を割り当てて、各自講師をしてもらいました。 元々レポートを 3 回発表することを予定していたので、本の内容を読んできちんと理解した上で、 他人へ伝える力を養う ことをサブ目標にしています。 さらなる自主性も必要になる上、本の性質上ほとんどのメンバーが触っていない Go 言語を使ってプログラムを書いてシステムのことを理解しないといけない為、プログラムの本質的な部分に触れることもできたのではないかと思います。 開発実践 開発実践は上記の開発基礎と並行して午後から実施しました。 1 日の午前が開発基礎、午後が開発実践というスケジュールです。 実践は新卒メンバーで社内ツールを実際の業務形式で開発してもらいました。 題材は**「メドレーの使い方に合ったビルの予約システムを作る」**というものです(以前 SmartHR さんが同じビルだったので少しアプローチが違いますが ブログ に書いてました)。 メドレーでの業務開発と同じ形式で ユーザーからの要望をヒアリング 要件定義 開発計画の策定 システム設計 チームで分担してながらの開発 ベータ版としてリリースしたものをブラッシュアップ 実稼働するための環境整備をしながらリリースする という一連のプロセスで開発しました。 「開発自体どうやって進めるか」「仕様をどうするか」など基本的な所から、全行程を新卒メンバー主体で考えて実行してもらい、メンター陣は所々 MTG や PR をレビューしながら、アドバイスをするという形式で行いました。 新卒メンバー全員が同じスキルセットを持っているわけでもないですし、得意・不得意も違う為、まず最初に彼ら自身にリーダーを決めてもらい、リーダーがオーナーシップを持って開発を進めてもらいました。 チームでの開発というのはほとんど全員が初めてだったため、かなり困惑しているところもありましたが、研修の過程で理解した互いのスペシャリティを活かして、役割分担をしつつ、決まった納期にきちんとリリースすることができました。メンターとしてそばで見ていましたが、新卒メンバー全員の成長を実感しましたし、純粋に凄いと感じました。 途中で納期に間に合わせるための要件の取捨選択をしなければならなかったり、自分達が考えた仕様が必ずしもベストというわけではなく、さらに色々と考える要素が必要だったりという 開発のリアルを経験できた のは次の OJT に活きたと思います。 余談ですが、こちらの元々のシステムを調査する上で「Web を支える技術」の知識が早速役に立つという場面が多く、やはり 基本は大事だな、と思った 次第です。 開発部 OJT 基礎研修が終わってから、既存サービスにジョインしての OJT 実施となりました。 ここまでの研修で、ある程度の知識や業務の進め方などは習得していたので、何をすればよいか分からないということはありませんでした。 メンバーによってはここで時間を取って Ruby on Rails について習得をしてもらいました。 大きい失敗なども特にはなく粛々と進められたのは良かったのではないかと思います。 事業部 OJT 開発部 OJT の途中で 2 週間ずつ時間を取って、人材プラットフォーム事業と医療メディア事業での事業部 OJT を行いました。 **どこで顧客とコンタクトし、お金をいただき、どのような形で自分達が作ったシステムに関わっていくのか?**というのをこの時期に体験してもらうことが目的です。 研修はビジネスの流れに沿って行ないました。研修メニューは、事業部の主要メンバーにコンセプトの共有をし、メニューを考えて実施してもらいました。（ありがとうございます！） 実際に電話でアポイントを取ったり、顧客のサポートを電話やビデオチャットでしたり、営業をどうやっているのかを体験したり…などを 2 週間かけて新卒メンバーに体験してもらいました。 この後に実際**「このシステムの機能はこういうときに使うのかと実感した」とか「やっていてこのような仕様のほうが良いと思った」などの感想**をそれぞれのメンバーが持っていて、やはり実施して良かったなと強く感じました。 レポート発表 それぞれの研修の終わりにはレポート発表の時間を設け、一人一人振り返りを書いてもらいます。その為に週報の提出も義務付けました。また研修期間の終了時には弊社役員陣にプレゼンする最終レポート発表の時間を取りました。 ひたすら研修内容をこなしていくという形になりがちなので、 振り返りの期間を設けて記録を付けていき、自分の成長や反省などを可視化したい という目的です。 また、メドレーでは ドキュメントドリブンで開発に限らず全社員が Confluence でドキュメントを書いていく文化 なので、文書を誰にでも分かるように論理的に書く技術が求められます。こういったレポートの記述やそのフィードバックから文書技術を高めてほしいという目的もありました。 レポートに関してはメンター陣やマネージャ陣に発表してもらうという形にしていたので、発表自体やレポートのまとめ方などに都度フィードバックをするようにしました。 最初はレポートが読みづらいなどもありましたが、回を重ねるごとに段々洗練されたレポートや発表になってきたのが印象的 です。 最終レポートは代表を始めとした経営陣に向けてレポートを発表してもらいました。今まで自分達がやってきた全ての業務を、前提の知識がない聴衆に向けて発表するということで、各自が趣向を凝らしての発表になり、経営陣からも高評価をもらっていました。 まとめ メドレーで初の新卒研修は以上のような形で終わることができました。 かなりのハードスケジュールだったとか、開発部 OJT をもう少し現場と色々と話しあったほうが効果的だったかもなど反省点もありますが、現在新卒メンバーが 10 月から実際の業務で活躍しているところを見ているので、ある程度の成功を収めることができたのではないかと思います。 来年度のメニューはまた違ったものになる可能性がありますが、今年の研修でも重視した**「メドレーでエンジニアとして働くことに対する意義を感じながら業務をしてもらう」**という部分はズラさずに実施していければと思います。 長々とお付き合いいただきありがとうございました。

こんにちは。エンジニアの平木です。 メドレーでは今年度より新卒採用活動を本格化しており、今年はエンジニア 4 名が新卒社員として入社しました。 現在、新卒メンバーは 6 ヶ月の開発研修が無事終了し、各部署で業務に勤しんでいますが、このエントリでは、**初めての新卒研修をどのような視点で計画・実行していったか?**を書いていきたいと思います。 2019 年度新卒入社メンバー 新卒研修を決めるまでやったこと 研修の大枠決定 カリキュラムの大枠を決めるため、まず CTO の平山が「こんなことをやろう」という大枠の方向性を出し、施策レベルに筆者が落としこんでいきました。 決めたことは、以下３点です。 入社後の導入部分 社会人としてのビジネスマナーや考え方の基礎を学ぶ プロダクト開発をする上で必要になる基礎を学ぶ 会社の事業内容を理解する OJT をメインとした各チームへの仮配属 新卒社員へのフォローアップ メンターや部長との定期報告会 半年後に役員陣への成果報告会 エンジニアとして価値を出していくため必要な**「社会の課題を解決するために、日々自身の腕を磨き、純粋に取り組む、ただそれだけ」**という、メドレーが求めるエンジニアとしての姿勢をきちんと体得してもらうことが目標です。 こちらについては平山のブログに詳しく書かれているので、ぜひご参照ください。 toppa.medley.jp toppa.medley.jp 情報収集 社内エンジニアへのヒアリング 前職で新卒研修を受けたことがある社内の 20 代~30 代のエンジニア 4 人を対象に、研修内容についてヒアリングしました。 ヒアリングしたポイントは 研修の期間 研修全体の流れ 各研修メニューの内容 OJT はどういった形で受けたか 研修を受けての感想 など。各社・各年代で個性が出るなという印象を持ちました。 やはり、エンジニアということで座学よりも手を動かすハンズオン形式の方が印象に残ることや、印象的な研修メニューは時間が経っても覚えているという傾向が分かりました。 ネットでの情報収集 ご存知の通り、近年では新卒研修のブログや、学習プログラムに関しては多くの企業様が書かれています。 しかし、内容としては**「アプリ開発をこのような形式で行ないました」という情報が多く、研修全体や社内情勢も踏まえた背景などが書かれているものは意外に少ないな**という印象を持ちました。 そんな中、各社の新卒研修エントリが Gist にまとめられているのを発見しました。 こちらは大変参考になりました。作者の方にはこの場をお借りして感謝させていただきます。 研修資料まとめ.md GitHub Gist: instantly share code, notes, and snippets. gist.github.com 研修メニュー決定 研修の詳細メニュー ここまでの過程を踏まえ研修メニューを筆者が考え、CTO や開発部部長の田中・副部長の稲本と刷り合わせをしていきました。 結果として、以下のメニュー構成でいくことになりました。 オリエンテーション **[座学]**社会人研修や会社全般の知識の習得を目的にする 開発基礎研修 **[座学]**Web アプリケーション開発の基本や、エンジニアとしての心得、会社の展開するサービスの基本知識を習得することを目的にする 開発実践研修 **[OJT]**社内向けに Web アプリケーションを開発し、チーム開発を実践することを目的にする 開発部 OJT **[OJT]**稼動しているサービスの開発を通して、業務としての開発を実践することを目的にする 事業部 OJT **[OJT]**ビジネスサイドの業務を体験し、開発以外の会社の業務の全体像を理解することを目的にする 特に事業部 OJT は新卒メンバーには必ず理解してもらいたい、と決まった研修項目です。 メドレーではプロダクトファーストで開発しますが、プロダクトの機能や要望は実際のビジネスの流れと密接に関わっています。 新卒メンバーもこういった流れを把握出来ていないと、要点を押さえた開発ができません。 実際にどのような流れで顧客と関わっていき、自分達が開発するプロダクトにどう影響していくかを体験 してもらうために、この事業部 OJT をメニューに組み込みました。 研修期間 研修の期間についても様々な意見が出ましたが、最終的には配属後の業務にスムーズに入ってもらえるように、基礎を重視して長めに研修時間を取ったほうがよいと決め、以下の通り全 6 ヶ月という研修期間を定めました。 オリエンテーション・開発基礎研修・開発実践研修 2 ヶ月 期間中、午前：開発基礎、午後：開発実践 開発部 OJT ・事業部 OJT 4 ヶ月 事業部 OJT は期間中に 2 週間 x 2 つの事業部で実施 メンター 研修全体の統括は筆者になりますが、新卒メンバーがいつでも相談できるように 1 人につき 1 人のメンターを付けています。社会人経験が 3 年以上ある社員をメンターとしました。 最初の 2 週は毎日 1on1 を 15 分程度行ない、以降は毎週金曜日に 1 時間の 1on1 を実施。 また、メンター同士の交流として、2 週に 1 度メンターの共有会を開き、相談や近況報告を行いました。 メンター制自体も初めての試みだったためメンター同士の対応内容や新卒全員の様子が共有される場作りは、実施してよかったです。 研修メニュー内容 各研修内容のご紹介です。 オリエンテーション オリエンテーションは 外部ビジネス研修 コンプライアンス研修 セキュリティ研修 開発環境の整備 開発ツールの解説 がメインです。 Mac を渡されて、「勝手に開発環境作ってね」というのは新卒エンジニアにはハードルが高いので、筆者が付きっきりで時間をかけてフォローしました。 オリエンテーションは約 1 週間程度ですが、ここで「メドレー社員の一人になった」という実感を持ってもらう ことができました。 開発基礎研修 大きく 2 部構成です。最初の部では、メドレーでエンジニアに期待していることや、既存サービスなどのシステム構成・ビジネスの流れなどを座学で実施しました。 もう一つの部では書籍の輪読をしました。この輪読は、Web サービスの基本の仕組みと、Web サーバ自体を支える OS である Linux の基本を覚えてもらいたいという趣旨で開催しました。 メドレーについて こちらの部では CTO 平山から「メドレーのエンジニアとして求めること」と題して、求められるエンジニアリングとは何なのか?自分達のキャリアパスなどをディスカッションしました。 その後は、 ジョブメドレー ・ CLINICS ・ 介護のほんね などメドレーが提供しているプロダクトについて、システムの概要やビジネスモデルとシステムの対応について講義。 メドレーでのエンジニアは各々専門性がある技術領域を持ちつつ、その領域に限定せずに広い分野で開発をしていますし、プロダクトを第一に考え開発しますが、そのために技術を武器としていくバランス感覚が必要になります。 この段階でまずこうした メドレーでエンジニアとして働くとはどういうことなのか という知識や考え方を新卒メンバーに勉強してもらいました。 エンジニアとは何か エンジニアの価値は何か プロエンジニアとは何か エンジニアではない職種との違いは何か といった基本的な話から、 2030 年のみんなはどうなっているのか、どうなっていたいのか 先輩エンジニアはどのようなことに悩み、どのようにアプローチをして、力をつけてきたのか、それを超えるためのヒントはどこにあるか メドレーのエンジニアとして求めたいことは何か といった踏み込んだ話も含め、個人ワークやグループワークも交えながら伝えていきました。 導入があることで、これからのカリキュラムを実施していく上での心構えができる期間だったのではないかと思います。 輪読会 座学でプログラミングのことを勉強させるのではなく、主体性を持ち、基礎知識を習得してほしいと考えていたので、 プランを作っている初期段階から輪読会をすることを決めていました。 参考にさせていただいたのは ドワンゴさんの 2016 年の研修の記事 です。 輪読で使用する本の選定は悩んだのですが、弊社で使っている Ruby や Ruby on Rails のことや、JavaScript などの技術より、基本となる Web 自体についての知識や、Web サーバで使う Linux の事などを習得してもらいたいということを考えて以下の 2 冊で輪読を行いました。 Web を支える技術 ── HTTP，URI，HTML，そして REST（WEB+DB PRESS plus シリーズ） Go ならわかるシステムプログラミング 「Web を支える技術」の輪読の形式は毎回決まった章を筆者が講義しつつ、時折質問などをメンバーに投げかけたりしながら理解を深めました。 議事録も新卒メンバー全員で順番を決めてもらうという、自主性に基づくスタイルにしました。 まず輪読の雰囲気になれてもらうこと、それから議事録を取りつつドキュメンテーションの練習をすること を狙いとしています。 最初はぎこちなかった部分もありましたが、回を重ねるにつれて、自分の経験や知識も含めたディスカッションにも発展するようになり、全員自主性を持ちながら実施できました。 対して「Go ならわかるシステムプログラミング」については 新卒メンバーに章を割り当てて、各自講師をしてもらいました。 元々レポートを 3 回発表することを予定していたので、本の内容を読んできちんと理解した上で、 他人へ伝える力を養う ことをサブ目標にしています。 さらなる自主性も必要になる上、本の性質上ほとんどのメンバーが触っていない Go 言語を使ってプログラムを書いてシステムのことを理解しないといけない為、プログラムの本質的な部分に触れることもできたのではないかと思います。 開発実践 開発実践は上記の開発基礎と並行して午後から実施しました。 1 日の午前が開発基礎、午後が開発実践というスケジュールです。 実践は新卒メンバーで社内ツールを実際の業務形式で開発してもらいました。 題材は**「メドレーの使い方に合ったビルの予約システムを作る」**というものです(以前 SmartHR さんが同じビルだったので少しアプローチが違いますが ブログ に書いてました)。 メドレーでの業務開発と同じ形式で ユーザーからの要望をヒアリング 要件定義 開発計画の策定 システム設計 チームで分担してながらの開発 ベータ版としてリリースしたものをブラッシュアップ 実稼働するための環境整備をしながらリリースする という一連のプロセスで開発しました。 「開発自体どうやって進めるか」「仕様をどうするか」など基本的な所から、全行程を新卒メンバー主体で考えて実行してもらい、メンター陣は所々 MTG や PR をレビューしながら、アドバイスをするという形式で行いました。 新卒メンバー全員が同じスキルセットを持っているわけでもないですし、得意・不得意も違う為、まず最初に彼ら自身にリーダーを決めてもらい、リーダーがオーナーシップを持って開発を進めてもらいました。 チームでの開発というのはほとんど全員が初めてだったため、かなり困惑しているところもありましたが、研修の過程で理解した互いのスペシャリティを活かして、役割分担をしつつ、決まった納期にきちんとリリースすることができました。メンターとしてそばで見ていましたが、新卒メンバー全員の成長を実感しましたし、純粋に凄いと感じました。 途中で納期に間に合わせるための要件の取捨選択をしなければならなかったり、自分達が考えた仕様が必ずしもベストというわけではなく、さらに色々と考える要素が必要だったりという 開発のリアルを経験できた のは次の OJT に活きたと思います。 余談ですが、こちらの元々のシステムを調査する上で「Web を支える技術」の知識が早速役に立つという場面が多く、やはり 基本は大事だな、と思った 次第です。 開発部 OJT 基礎研修が終わってから、既存サービスにジョインしての OJT 実施となりました。 ここまでの研修で、ある程度の知識や業務の進め方などは習得していたので、何をすればよいか分からないということはありませんでした。 メンバーによってはここで時間を取って Ruby on Rails について習得をしてもらいました。 大きい失敗なども特にはなく粛々と進められたのは良かったのではないかと思います。 事業部 OJT 開発部 OJT の途中で 2 週間ずつ時間を取って、人材プラットフォーム事業と医療メディア事業での事業部 OJT を行いました。 **どこで顧客とコンタクトし、お金をいただき、どのような形で自分達が作ったシステムに関わっていくのか?**というのをこの時期に体験してもらうことが目的です。 研修はビジネスの流れに沿って行ないました。研修メニューは、事業部の主要メンバーにコンセプトの共有をし、メニューを考えて実施してもらいました。（ありがとうございます！） 実際に電話でアポイントを取ったり、顧客のサポートを電話やビデオチャットでしたり、営業をどうやっているのかを体験したり…などを 2 週間かけて新卒メンバーに体験してもらいました。 この後に実際**「このシステムの機能はこういうときに使うのかと実感した」とか「やっていてこのような仕様のほうが良いと思った」などの感想**をそれぞれのメンバーが持っていて、やはり実施して良かったなと強く感じました。 レポート発表 それぞれの研修の終わりにはレポート発表の時間を設け、一人一人振り返りを書いてもらいます。その為に週報の提出も義務付けました。また研修期間の終了時には弊社役員陣にプレゼンする最終レポート発表の時間を取りました。 ひたすら研修内容をこなしていくという形になりがちなので、 振り返りの期間を設けて記録を付けていき、自分の成長や反省などを可視化したい という目的です。 また、メドレーでは ドキュメントドリブンで開発に限らず全社員が Confluence でドキュメントを書いていく文化 なので、文書を誰にでも分かるように論理的に書く技術が求められます。こういったレポートの記述やそのフィードバックから文書技術を高めてほしいという目的もありました。 レポートに関してはメンター陣やマネージャ陣に発表してもらうという形にしていたので、発表自体やレポートのまとめ方などに都度フィードバックをするようにしました。 最初はレポートが読みづらいなどもありましたが、回を重ねるごとに段々洗練されたレポートや発表になってきたのが印象的 です。 最終レポートは代表を始めとした経営陣に向けてレポートを発表してもらいました。今まで自分達がやってきた全ての業務を、前提の知識がない聴衆に向けて発表するということで、各自が趣向を凝らしての発表になり、経営陣からも高評価をもらっていました。 まとめ メドレーで初の新卒研修は以上のような形で終わることができました。 かなりのハードスケジュールだったとか、開発部 OJT をもう少し現場と色々と話しあったほうが効果的だったかもなど反省点もありますが、現在新卒メンバーが 10 月から実際の業務で活躍しているところを見ているので、ある程度の成功を収めることができたのではないかと思います。 来年度のメニューはまた違ったものになる可能性がありますが、今年の研修でも重視した**「メドレーでエンジニアとして働くことに対する意義を感じながら業務をしてもらう」**という部分はズラさずに実施していければと思います。 長々とお付き合いいただきありがとうございました。

こんにちは。エンジニアの平木です。 メドレーでは今年度より新卒採用活動を本格化しており、今年はエンジニア 4 名が新卒社員として入社しました。 現在、新卒メンバーは 6 ヶ月の開発研修が無事終了し、各部署で業務に勤しんでいますが、このエントリでは、**初めての新卒研修をどのような視点で計画・実行していったか?**を書いていきたいと思います。 2019 年度新卒入社メンバー 新卒研修を決めるまでやったこと 研修の大枠決定 カリキュラムの大枠を決めるため、まず CTO の平山が「こんなことをやろう」という大枠の方向性を出し、施策レベルに筆者が落としこんでいきました。 決めたことは、以下３点です。 入社後の導入部分 社会人としてのビジネスマナーや考え方の基礎を学ぶ プロダクト開発をする上で必要になる基礎を学ぶ 会社の事業内容を理解する OJT をメインとした各チームへの仮配属 新卒社員へのフォローアップ メンターや部長との定期報告会 半年後に役員陣への成果報告会 エンジニアとして価値を出していくため必要な**「社会の課題を解決するために、日々自身の腕を磨き、純粋に取り組む、ただそれだけ」**という、メドレーが求めるエンジニアとしての姿勢をきちんと体得してもらうことが目標です。 こちらについては平山のブログに詳しく書かれているので、ぜひご参照ください。 toppa.medley.jp toppa.medley.jp 情報収集 社内エンジニアへのヒアリング 前職で新卒研修を受けたことがある社内の 20 代~30 代のエンジニア 4 人を対象に、研修内容についてヒアリングしました。 ヒアリングしたポイントは 研修の期間 研修全体の流れ 各研修メニューの内容 OJT はどういった形で受けたか 研修を受けての感想 など。各社・各年代で個性が出るなという印象を持ちました。 やはり、エンジニアということで座学よりも手を動かすハンズオン形式の方が印象に残ることや、印象的な研修メニューは時間が経っても覚えているという傾向が分かりました。 ネットでの情報収集 ご存知の通り、近年では新卒研修のブログや、学習プログラムに関しては多くの企業様が書かれています。 しかし、内容としては**「アプリ開発をこのような形式で行ないました」という情報が多く、研修全体や社内情勢も踏まえた背景などが書かれているものは意外に少ないな**という印象を持ちました。 そんな中、各社の新卒研修エントリが Gist にまとめられているのを発見しました。 こちらは大変参考になりました。作者の方にはこの場をお借りして感謝させていただきます。 研修資料まとめ.md GitHub Gist: instantly share code, notes, and snippets. gist.github.com 研修メニュー決定 研修の詳細メニュー ここまでの過程を踏まえ研修メニューを筆者が考え、CTO や開発部部長の田中・副部長の稲本と刷り合わせをしていきました。 結果として、以下のメニュー構成でいくことになりました。 オリエンテーション **[座学]**社会人研修や会社全般の知識の習得を目的にする 開発基礎研修 **[座学]**Web アプリケーション開発の基本や、エンジニアとしての心得、会社の展開するサービスの基本知識を習得することを目的にする 開発実践研修 **[OJT]**社内向けに Web アプリケーションを開発し、チーム開発を実践することを目的にする 開発部 OJT **[OJT]**稼動しているサービスの開発を通して、業務としての開発を実践することを目的にする 事業部 OJT **[OJT]**ビジネスサイドの業務を体験し、開発以外の会社の業務の全体像を理解することを目的にする 特に事業部 OJT は新卒メンバーには必ず理解してもらいたい、と決まった研修項目です。 メドレーではプロダクトファーストで開発しますが、プロダクトの機能や要望は実際のビジネスの流れと密接に関わっています。 新卒メンバーもこういった流れを把握出来ていないと、要点を押さえた開発ができません。 実際にどのような流れで顧客と関わっていき、自分達が開発するプロダクトにどう影響していくかを体験 してもらうために、この事業部 OJT をメニューに組み込みました。 研修期間 研修の期間についても様々な意見が出ましたが、最終的には配属後の業務にスムーズに入ってもらえるように、基礎を重視して長めに研修時間を取ったほうがよいと決め、以下の通り全 6 ヶ月という研修期間を定めました。 オリエンテーション・開発基礎研修・開発実践研修 2 ヶ月 期間中、午前：開発基礎、午後：開発実践 開発部 OJT ・事業部 OJT 4 ヶ月 事業部 OJT は期間中に 2 週間 x 2 つの事業部で実施 メンター 研修全体の統括は筆者になりますが、新卒メンバーがいつでも相談できるように 1 人につき 1 人のメンターを付けています。社会人経験が 3 年以上ある社員をメンターとしました。 最初の 2 週は毎日 1on1 を 15 分程度行ない、以降は毎週金曜日に 1 時間の 1on1 を実施。 また、メンター同士の交流として、2 週に 1 度メンターの共有会を開き、相談や近況報告を行いました。 メンター制自体も初めての試みだったためメンター同士の対応内容や新卒全員の様子が共有される場作りは、実施してよかったです。 研修メニュー内容 各研修内容のご紹介です。 オリエンテーション オリエンテーションは 外部ビジネス研修 コンプライアンス研修 セキュリティ研修 開発環境の整備 開発ツールの解説 がメインです。 Mac を渡されて、「勝手に開発環境作ってね」というのは新卒エンジニアにはハードルが高いので、筆者が付きっきりで時間をかけてフォローしました。 オリエンテーションは約 1 週間程度ですが、ここで「メドレー社員の一人になった」という実感を持ってもらう ことができました。 開発基礎研修 大きく 2 部構成です。最初の部では、メドレーでエンジニアに期待していることや、既存サービスなどのシステム構成・ビジネスの流れなどを座学で実施しました。 もう一つの部では書籍の輪読をしました。この輪読は、Web サービスの基本の仕組みと、Web サーバ自体を支える OS である Linux の基本を覚えてもらいたいという趣旨で開催しました。 メドレーについて こちらの部では CTO 平山から「メドレーのエンジニアとして求めること」と題して、求められるエンジニアリングとは何なのか?自分達のキャリアパスなどをディスカッションしました。 その後は、 ジョブメドレー ・ CLINICS ・ 介護のほんね などメドレーが提供しているプロダクトについて、システムの概要やビジネスモデルとシステムの対応について講義。 メドレーでのエンジニアは各々専門性がある技術領域を持ちつつ、その領域に限定せずに広い分野で開発をしていますし、プロダクトを第一に考え開発しますが、そのために技術を武器としていくバランス感覚が必要になります。 この段階でまずこうした メドレーでエンジニアとして働くとはどういうことなのか という知識や考え方を新卒メンバーに勉強してもらいました。 エンジニアとは何か エンジニアの価値は何か プロエンジニアとは何か エンジニアではない職種との違いは何か といった基本的な話から、 2030 年のみんなはどうなっているのか、どうなっていたいのか 先輩エンジニアはどのようなことに悩み、どのようにアプローチをして、力をつけてきたのか、それを超えるためのヒントはどこにあるか メドレーのエンジニアとして求めたいことは何か といった踏み込んだ話も含め、個人ワークやグループワークも交えながら伝えていきました。 導入があることで、これからのカリキュラムを実施していく上での心構えができる期間だったのではないかと思います。 輪読会 座学でプログラミングのことを勉強させるのではなく、主体性を持ち、基礎知識を習得してほしいと考えていたので、 プランを作っている初期段階から輪読会をすることを決めていました。 参考にさせていただいたのは ドワンゴさんの 2016 年の研修の記事 です。 輪読で使用する本の選定は悩んだのですが、弊社で使っている Ruby や Ruby on Rails のことや、JavaScript などの技術より、基本となる Web 自体についての知識や、Web サーバで使う Linux の事などを習得してもらいたいということを考えて以下の 2 冊で輪読を行いました。 Web を支える技術 ── HTTP，URI，HTML，そして REST（WEB+DB PRESS plus シリーズ） Go ならわかるシステムプログラミング 「Web を支える技術」の輪読の形式は毎回決まった章を筆者が講義しつつ、時折質問などをメンバーに投げかけたりしながら理解を深めました。 議事録も新卒メンバー全員で順番を決めてもらうという、自主性に基づくスタイルにしました。 まず輪読の雰囲気になれてもらうこと、それから議事録を取りつつドキュメンテーションの練習をすること を狙いとしています。 最初はぎこちなかった部分もありましたが、回を重ねるにつれて、自分の経験や知識も含めたディスカッションにも発展するようになり、全員自主性を持ちながら実施できました。 対して「Go ならわかるシステムプログラミング」については 新卒メンバーに章を割り当てて、各自講師をしてもらいました。 元々レポートを 3 回発表することを予定していたので、本の内容を読んできちんと理解した上で、 他人へ伝える力を養う ことをサブ目標にしています。 さらなる自主性も必要になる上、本の性質上ほとんどのメンバーが触っていない Go 言語を使ってプログラムを書いてシステムのことを理解しないといけない為、プログラムの本質的な部分に触れることもできたのではないかと思います。 開発実践 開発実践は上記の開発基礎と並行して午後から実施しました。 1 日の午前が開発基礎、午後が開発実践というスケジュールです。 実践は新卒メンバーで社内ツールを実際の業務形式で開発してもらいました。 題材は**「メドレーの使い方に合ったビルの予約システムを作る」**というものです(以前 SmartHR さんが同じビルだったので少しアプローチが違いますが ブログ に書いてました)。 メドレーでの業務開発と同じ形式で ユーザーからの要望をヒアリング 要件定義 開発計画の策定 システム設計 チームで分担してながらの開発 ベータ版としてリリースしたものをブラッシュアップ 実稼働するための環境整備をしながらリリースする という一連のプロセスで開発しました。 「開発自体どうやって進めるか」「仕様をどうするか」など基本的な所から、全行程を新卒メンバー主体で考えて実行してもらい、メンター陣は所々 MTG や PR をレビューしながら、アドバイスをするという形式で行いました。 新卒メンバー全員が同じスキルセットを持っているわけでもないですし、得意・不得意も違う為、まず最初に彼ら自身にリーダーを決めてもらい、リーダーがオーナーシップを持って開発を進めてもらいました。 チームでの開発というのはほとんど全員が初めてだったため、かなり困惑しているところもありましたが、研修の過程で理解した互いのスペシャリティを活かして、役割分担をしつつ、決まった納期にきちんとリリースすることができました。メンターとしてそばで見ていましたが、新卒メンバー全員の成長を実感しましたし、純粋に凄いと感じました。 途中で納期に間に合わせるための要件の取捨選択をしなければならなかったり、自分達が考えた仕様が必ずしもベストというわけではなく、さらに色々と考える要素が必要だったりという 開発のリアルを経験できた のは次の OJT に活きたと思います。 余談ですが、こちらの元々のシステムを調査する上で「Web を支える技術」の知識が早速役に立つという場面が多く、やはり 基本は大事だな、と思った 次第です。 開発部 OJT 基礎研修が終わってから、既存サービスにジョインしての OJT 実施となりました。 ここまでの研修で、ある程度の知識や業務の進め方などは習得していたので、何をすればよいか分からないということはありませんでした。 メンバーによってはここで時間を取って Ruby on Rails について習得をしてもらいました。 大きい失敗なども特にはなく粛々と進められたのは良かったのではないかと思います。 事業部 OJT 開発部 OJT の途中で 2 週間ずつ時間を取って、人材プラットフォーム事業と医療メディア事業での事業部 OJT を行いました。 **どこで顧客とコンタクトし、お金をいただき、どのような形で自分達が作ったシステムに関わっていくのか?**というのをこの時期に体験してもらうことが目的です。 研修はビジネスの流れに沿って行ないました。研修メニューは、事業部の主要メンバーにコンセプトの共有をし、メニューを考えて実施してもらいました。（ありがとうございます！） 実際に電話でアポイントを取ったり、顧客のサポートを電話やビデオチャットでしたり、営業をどうやっているのかを体験したり…などを 2 週間かけて新卒メンバーに体験してもらいました。 この後に実際**「このシステムの機能はこういうときに使うのかと実感した」とか「やっていてこのような仕様のほうが良いと思った」などの感想**をそれぞれのメンバーが持っていて、やはり実施して良かったなと強く感じました。 レポート発表 それぞれの研修の終わりにはレポート発表の時間を設け、一人一人振り返りを書いてもらいます。その為に週報の提出も義務付けました。また研修期間の終了時には弊社役員陣にプレゼンする最終レポート発表の時間を取りました。 ひたすら研修内容をこなしていくという形になりがちなので、 振り返りの期間を設けて記録を付けていき、自分の成長や反省などを可視化したい という目的です。 また、メドレーでは ドキュメントドリブンで開発に限らず全社員が Confluence でドキュメントを書いていく文化 なので、文書を誰にでも分かるように論理的に書く技術が求められます。こういったレポートの記述やそのフィードバックから文書技術を高めてほしいという目的もありました。 レポートに関してはメンター陣やマネージャ陣に発表してもらうという形にしていたので、発表自体やレポートのまとめ方などに都度フィードバックをするようにしました。 最初はレポートが読みづらいなどもありましたが、回を重ねるごとに段々洗練されたレポートや発表になってきたのが印象的 です。 最終レポートは代表を始めとした経営陣に向けてレポートを発表してもらいました。今まで自分達がやってきた全ての業務を、前提の知識がない聴衆に向けて発表するということで、各自が趣向を凝らしての発表になり、経営陣からも高評価をもらっていました。 まとめ メドレーで初の新卒研修は以上のような形で終わることができました。 かなりのハードスケジュールだったとか、開発部 OJT をもう少し現場と色々と話しあったほうが効果的だったかもなど反省点もありますが、現在新卒メンバーが 10 月から実際の業務で活躍しているところを見ているので、ある程度の成功を収めることができたのではないかと思います。 来年度のメニューはまた違ったものになる可能性がありますが、今年の研修でも重視した**「メドレーでエンジニアとして働くことに対する意義を感じながら業務をしてもらう」**という部分はズラさずに実施していければと思います。 長々とお付き合いいただきありがとうございました。

こんにちは。エンジニアの平木です。 メドレーでは今年度より新卒採用活動を本格化しており、今年はエンジニア 4 名が新卒社員として入社しました。 現在、新卒メンバーは 6 ヶ月の開発研修が無事終了し、各部署で業務に勤しんでいますが、このエントリでは、**初めての新卒研修をどのような視点で計画・実行していったか?**を書いていきたいと思います。 2019 年度新卒入社メンバー 新卒研修を決めるまでやったこと 研修の大枠決定 カリキュラムの大枠を決めるため、まず CTO の平山が「こんなことをやろう」という大枠の方向性を出し、施策レベルに筆者が落としこんでいきました。 決めたことは、以下３点です。 入社後の導入部分 社会人としてのビジネスマナーや考え方の基礎を学ぶ プロダクト開発をする上で必要になる基礎を学ぶ 会社の事業内容を理解する OJT をメインとした各チームへの仮配属 新卒社員へのフォローアップ メンターや部長との定期報告会 半年後に役員陣への成果報告会 エンジニアとして価値を出していくため必要な**「社会の課題を解決するために、日々自身の腕を磨き、純粋に取り組む、ただそれだけ」**という、メドレーが求めるエンジニアとしての姿勢をきちんと体得してもらうことが目標です。 こちらについては平山のブログに詳しく書かれているので、ぜひご参照ください。 toppa.medley.jp toppa.medley.jp 情報収集 社内エンジニアへのヒアリング 前職で新卒研修を受けたことがある社内の 20 代~30 代のエンジニア 4 人を対象に、研修内容についてヒアリングしました。 ヒアリングしたポイントは 研修の期間 研修全体の流れ 各研修メニューの内容 OJT はどういった形で受けたか 研修を受けての感想 など。各社・各年代で個性が出るなという印象を持ちました。 やはり、エンジニアということで座学よりも手を動かすハンズオン形式の方が印象に残ることや、印象的な研修メニューは時間が経っても覚えているという傾向が分かりました。 ネットでの情報収集 ご存知の通り、近年では新卒研修のブログや、学習プログラムに関しては多くの企業様が書かれています。 しかし、内容としては**「アプリ開発をこのような形式で行ないました」という情報が多く、研修全体や社内情勢も踏まえた背景などが書かれているものは意外に少ないな**という印象を持ちました。 そんな中、各社の新卒研修エントリが Gist にまとめられているのを発見しました。 こちらは大変参考になりました。作者の方にはこの場をお借りして感謝させていただきます。 研修資料まとめ.md GitHub Gist: instantly share code, notes, and snippets. gist.github.com 研修メニュー決定 研修の詳細メニュー ここまでの過程を踏まえ研修メニューを筆者が考え、CTO や開発部部長の田中・副部長の稲本と刷り合わせをしていきました。 結果として、以下のメニュー構成でいくことになりました。 オリエンテーション **[座学]**社会人研修や会社全般の知識の習得を目的にする 開発基礎研修 **[座学]**Web アプリケーション開発の基本や、エンジニアとしての心得、会社の展開するサービスの基本知識を習得することを目的にする 開発実践研修 **[OJT]**社内向けに Web アプリケーションを開発し、チーム開発を実践することを目的にする 開発部 OJT **[OJT]**稼動しているサービスの開発を通して、業務としての開発を実践することを目的にする 事業部 OJT **[OJT]**ビジネスサイドの業務を体験し、開発以外の会社の業務の全体像を理解することを目的にする 特に事業部 OJT は新卒メンバーには必ず理解してもらいたい、と決まった研修項目です。 メドレーではプロダクトファーストで開発しますが、プロダクトの機能や要望は実際のビジネスの流れと密接に関わっています。 新卒メンバーもこういった流れを把握出来ていないと、要点を押さえた開発ができません。 実際にどのような流れで顧客と関わっていき、自分達が開発するプロダクトにどう影響していくかを体験 してもらうために、この事業部 OJT をメニューに組み込みました。 研修期間 研修の期間についても様々な意見が出ましたが、最終的には配属後の業務にスムーズに入ってもらえるように、基礎を重視して長めに研修時間を取ったほうがよいと決め、以下の通り全 6 ヶ月という研修期間を定めました。 オリエンテーション・開発基礎研修・開発実践研修 2 ヶ月 期間中、午前：開発基礎、午後：開発実践 開発部 OJT ・事業部 OJT 4 ヶ月 事業部 OJT は期間中に 2 週間 x 2 つの事業部で実施 メンター 研修全体の統括は筆者になりますが、新卒メンバーがいつでも相談できるように 1 人につき 1 人のメンターを付けています。社会人経験が 3 年以上ある社員をメンターとしました。 最初の 2 週は毎日 1on1 を 15 分程度行ない、以降は毎週金曜日に 1 時間の 1on1 を実施。 また、メンター同士の交流として、2 週に 1 度メンターの共有会を開き、相談や近況報告を行いました。 メンター制自体も初めての試みだったためメンター同士の対応内容や新卒全員の様子が共有される場作りは、実施してよかったです。 研修メニュー内容 各研修内容のご紹介です。 オリエンテーション オリエンテーションは 外部ビジネス研修 コンプライアンス研修 セキュリティ研修 開発環境の整備 開発ツールの解説 がメインです。 Mac を渡されて、「勝手に開発環境作ってね」というのは新卒エンジニアにはハードルが高いので、筆者が付きっきりで時間をかけてフォローしました。 オリエンテーションは約 1 週間程度ですが、ここで「メドレー社員の一人になった」という実感を持ってもらう ことができました。 開発基礎研修 大きく 2 部構成です。最初の部では、メドレーでエンジニアに期待していることや、既存サービスなどのシステム構成・ビジネスの流れなどを座学で実施しました。 もう一つの部では書籍の輪読をしました。この輪読は、Web サービスの基本の仕組みと、Web サーバ自体を支える OS である Linux の基本を覚えてもらいたいという趣旨で開催しました。 メドレーについて こちらの部では CTO 平山から「メドレーのエンジニアとして求めること」と題して、求められるエンジニアリングとは何なのか?自分達のキャリアパスなどをディスカッションしました。 その後は、 ジョブメドレー ・ CLINICS ・ 介護のほんね などメドレーが提供しているプロダクトについて、システムの概要やビジネスモデルとシステムの対応について講義。 メドレーでのエンジニアは各々専門性がある技術領域を持ちつつ、その領域に限定せずに広い分野で開発をしていますし、プロダクトを第一に考え開発しますが、そのために技術を武器としていくバランス感覚が必要になります。 この段階でまずこうした メドレーでエンジニアとして働くとはどういうことなのか という知識や考え方を新卒メンバーに勉強してもらいました。 エンジニアとは何か エンジニアの価値は何か プロエンジニアとは何か エンジニアではない職種との違いは何か といった基本的な話から、 2030 年のみんなはどうなっているのか、どうなっていたいのか 先輩エンジニアはどのようなことに悩み、どのようにアプローチをして、力をつけてきたのか、それを超えるためのヒントはどこにあるか メドレーのエンジニアとして求めたいことは何か といった踏み込んだ話も含め、個人ワークやグループワークも交えながら伝えていきました。 導入があることで、これからのカリキュラムを実施していく上での心構えができる期間だったのではないかと思います。 輪読会 座学でプログラミングのことを勉強させるのではなく、主体性を持ち、基礎知識を習得してほしいと考えていたので、 プランを作っている初期段階から輪読会をすることを決めていました。 参考にさせていただいたのは ドワンゴさんの 2016 年の研修の記事 です。 輪読で使用する本の選定は悩んだのですが、弊社で使っている Ruby や Ruby on Rails のことや、JavaScript などの技術より、基本となる Web 自体についての知識や、Web サーバで使う Linux の事などを習得してもらいたいということを考えて以下の 2 冊で輪読を行いました。 Web を支える技術 ── HTTP，URI，HTML，そして REST（WEB+DB PRESS plus シリーズ） Go ならわかるシステムプログラミング 「Web を支える技術」の輪読の形式は毎回決まった章を筆者が講義しつつ、時折質問などをメンバーに投げかけたりしながら理解を深めました。 議事録も新卒メンバー全員で順番を決めてもらうという、自主性に基づくスタイルにしました。 まず輪読の雰囲気になれてもらうこと、それから議事録を取りつつドキュメンテーションの練習をすること を狙いとしています。 最初はぎこちなかった部分もありましたが、回を重ねるにつれて、自分の経験や知識も含めたディスカッションにも発展するようになり、全員自主性を持ちながら実施できました。 対して「Go ならわかるシステムプログラミング」については 新卒メンバーに章を割り当てて、各自講師をしてもらいました。 元々レポートを 3 回発表することを予定していたので、本の内容を読んできちんと理解した上で、 他人へ伝える力を養う ことをサブ目標にしています。 さらなる自主性も必要になる上、本の性質上ほとんどのメンバーが触っていない Go 言語を使ってプログラムを書いてシステムのことを理解しないといけない為、プログラムの本質的な部分に触れることもできたのではないかと思います。 開発実践 開発実践は上記の開発基礎と並行して午後から実施しました。 1 日の午前が開発基礎、午後が開発実践というスケジュールです。 実践は新卒メンバーで社内ツールを実際の業務形式で開発してもらいました。 題材は**「メドレーの使い方に合ったビルの予約システムを作る」**というものです(以前 SmartHR さんが同じビルだったので少しアプローチが違いますが ブログ に書いてました)。 メドレーでの業務開発と同じ形式で ユーザーからの要望をヒアリング 要件定義 開発計画の策定 システム設計 チームで分担してながらの開発 ベータ版としてリリースしたものをブラッシュアップ 実稼働するための環境整備をしながらリリースする という一連のプロセスで開発しました。 「開発自体どうやって進めるか」「仕様をどうするか」など基本的な所から、全行程を新卒メンバー主体で考えて実行してもらい、メンター陣は所々 MTG や PR をレビューしながら、アドバイスをするという形式で行いました。 新卒メンバー全員が同じスキルセットを持っているわけでもないですし、得意・不得意も違う為、まず最初に彼ら自身にリーダーを決めてもらい、リーダーがオーナーシップを持って開発を進めてもらいました。 チームでの開発というのはほとんど全員が初めてだったため、かなり困惑しているところもありましたが、研修の過程で理解した互いのスペシャリティを活かして、役割分担をしつつ、決まった納期にきちんとリリースすることができました。メンターとしてそばで見ていましたが、新卒メンバー全員の成長を実感しましたし、純粋に凄いと感じました。 途中で納期に間に合わせるための要件の取捨選択をしなければならなかったり、自分達が考えた仕様が必ずしもベストというわけではなく、さらに色々と考える要素が必要だったりという 開発のリアルを経験できた のは次の OJT に活きたと思います。 余談ですが、こちらの元々のシステムを調査する上で「Web を支える技術」の知識が早速役に立つという場面が多く、やはり 基本は大事だな、と思った 次第です。 開発部 OJT 基礎研修が終わってから、既存サービスにジョインしての OJT 実施となりました。 ここまでの研修で、ある程度の知識や業務の進め方などは習得していたので、何をすればよいか分からないということはありませんでした。 メンバーによってはここで時間を取って Ruby on Rails について習得をしてもらいました。 大きい失敗なども特にはなく粛々と進められたのは良かったのではないかと思います。 事業部 OJT 開発部 OJT の途中で 2 週間ずつ時間を取って、人材プラットフォーム事業と医療メディア事業での事業部 OJT を行いました。 **どこで顧客とコンタクトし、お金をいただき、どのような形で自分達が作ったシステムに関わっていくのか?**というのをこの時期に体験してもらうことが目的です。 研修はビジネスの流れに沿って行ないました。研修メニューは、事業部の主要メンバーにコンセプトの共有をし、メニューを考えて実施してもらいました。（ありがとうございます！） 実際に電話でアポイントを取ったり、顧客のサポートを電話やビデオチャットでしたり、営業をどうやっているのかを体験したり…などを 2 週間かけて新卒メンバーに体験してもらいました。 この後に実際**「このシステムの機能はこういうときに使うのかと実感した」とか「やっていてこのような仕様のほうが良いと思った」などの感想**をそれぞれのメンバーが持っていて、やはり実施して良かったなと強く感じました。 レポート発表 それぞれの研修の終わりにはレポート発表の時間を設け、一人一人振り返りを書いてもらいます。その為に週報の提出も義務付けました。また研修期間の終了時には弊社役員陣にプレゼンする最終レポート発表の時間を取りました。 ひたすら研修内容をこなしていくという形になりがちなので、 振り返りの期間を設けて記録を付けていき、自分の成長や反省などを可視化したい という目的です。 また、メドレーでは ドキュメントドリブンで開発に限らず全社員が Confluence でドキュメントを書いていく文化 なので、文書を誰にでも分かるように論理的に書く技術が求められます。こういったレポートの記述やそのフィードバックから文書技術を高めてほしいという目的もありました。 レポートに関してはメンター陣やマネージャ陣に発表してもらうという形にしていたので、発表自体やレポートのまとめ方などに都度フィードバックをするようにしました。 最初はレポートが読みづらいなどもありましたが、回を重ねるごとに段々洗練されたレポートや発表になってきたのが印象的 です。 最終レポートは代表を始めとした経営陣に向けてレポートを発表してもらいました。今まで自分達がやってきた全ての業務を、前提の知識がない聴衆に向けて発表するということで、各自が趣向を凝らしての発表になり、経営陣からも高評価をもらっていました。 まとめ メドレーで初の新卒研修は以上のような形で終わることができました。 かなりのハードスケジュールだったとか、開発部 OJT をもう少し現場と色々と話しあったほうが効果的だったかもなど反省点もありますが、現在新卒メンバーが 10 月から実際の業務で活躍しているところを見ているので、ある程度の成功を収めることができたのではないかと思います。 来年度のメニューはまた違ったものになる可能性がありますが、今年の研修でも重視した**「メドレーでエンジニアとして働くことに対する意義を感じながら業務をしてもらう」**という部分はズラさずに実施していければと思います。 長々とお付き合いいただきありがとうございました。

こんにちは。エンジニアの平木です。 メドレーでは今年度より新卒採用活動を本格化しており、今年はエンジニア 4 名が新卒社員として入社しました。 現在、新卒メンバーは 6 ヶ月の開発研修が無事終了し、各部署で業務に勤しんでいますが、このエントリでは、**初めての新卒研修をどのような視点で計画・実行していったか?**を書いていきたいと思います。 2019 年度新卒入社メンバー 新卒研修を決めるまでやったこと 研修の大枠決定 カリキュラムの大枠を決めるため、まず CTO の平山が「こんなことをやろう」という大枠の方向性を出し、施策レベルに筆者が落としこんでいきました。 決めたことは、以下３点です。 入社後の導入部分 社会人としてのビジネスマナーや考え方の基礎を学ぶ プロダクト開発をする上で必要になる基礎を学ぶ 会社の事業内容を理解する OJT をメインとした各チームへの仮配属 新卒社員へのフォローアップ メンターや部長との定期報告会 半年後に役員陣への成果報告会 エンジニアとして価値を出していくため必要な**「社会の課題を解決するために、日々自身の腕を磨き、純粋に取り組む、ただそれだけ」**という、メドレーが求めるエンジニアとしての姿勢をきちんと体得してもらうことが目標です。 こちらについては平山のブログに詳しく書かれているので、ぜひご参照ください。 toppa.medley.jp toppa.medley.jp 情報収集 社内エンジニアへのヒアリング 前職で新卒研修を受けたことがある社内の 20 代~30 代のエンジニア 4 人を対象に、研修内容についてヒアリングしました。 ヒアリングしたポイントは 研修の期間 研修全体の流れ 各研修メニューの内容 OJT はどういった形で受けたか 研修を受けての感想 など。各社・各年代で個性が出るなという印象を持ちました。 やはり、エンジニアということで座学よりも手を動かすハンズオン形式の方が印象に残ることや、印象的な研修メニューは時間が経っても覚えているという傾向が分かりました。 ネットでの情報収集 ご存知の通り、近年では新卒研修のブログや、学習プログラムに関しては多くの企業様が書かれています。 しかし、内容としては**「アプリ開発をこのような形式で行ないました」という情報が多く、研修全体や社内情勢も踏まえた背景などが書かれているものは意外に少ないな**という印象を持ちました。 そんな中、各社の新卒研修エントリが Gist にまとめられているのを発見しました。 こちらは大変参考になりました。作者の方にはこの場をお借りして感謝させていただきます。 研修資料まとめ.md GitHub Gist: instantly share code, notes, and snippets. gist.github.com 研修メニュー決定 研修の詳細メニュー ここまでの過程を踏まえ研修メニューを筆者が考え、CTO や開発部部長の田中・副部長の稲本と刷り合わせをしていきました。 結果として、以下のメニュー構成でいくことになりました。 オリエンテーション **[座学]**社会人研修や会社全般の知識の習得を目的にする 開発基礎研修 **[座学]**Web アプリケーション開発の基本や、エンジニアとしての心得、会社の展開するサービスの基本知識を習得することを目的にする 開発実践研修 **[OJT]**社内向けに Web アプリケーションを開発し、チーム開発を実践することを目的にする 開発部 OJT **[OJT]**稼動しているサービスの開発を通して、業務としての開発を実践することを目的にする 事業部 OJT **[OJT]**ビジネスサイドの業務を体験し、開発以外の会社の業務の全体像を理解することを目的にする 特に事業部 OJT は新卒メンバーには必ず理解してもらいたい、と決まった研修項目です。 メドレーではプロダクトファーストで開発しますが、プロダクトの機能や要望は実際のビジネスの流れと密接に関わっています。 新卒メンバーもこういった流れを把握出来ていないと、要点を押さえた開発ができません。 実際にどのような流れで顧客と関わっていき、自分達が開発するプロダクトにどう影響していくかを体験 してもらうために、この事業部 OJT をメニューに組み込みました。 研修期間 研修の期間についても様々な意見が出ましたが、最終的には配属後の業務にスムーズに入ってもらえるように、基礎を重視して長めに研修時間を取ったほうがよいと決め、以下の通り全 6 ヶ月という研修期間を定めました。 オリエンテーション・開発基礎研修・開発実践研修 2 ヶ月 期間中、午前：開発基礎、午後：開発実践 開発部 OJT ・事業部 OJT 4 ヶ月 事業部 OJT は期間中に 2 週間 x 2 つの事業部で実施 メンター 研修全体の統括は筆者になりますが、新卒メンバーがいつでも相談できるように 1 人につき 1 人のメンターを付けています。社会人経験が 3 年以上ある社員をメンターとしました。 最初の 2 週は毎日 1on1 を 15 分程度行ない、以降は毎週金曜日に 1 時間の 1on1 を実施。 また、メンター同士の交流として、2 週に 1 度メンターの共有会を開き、相談や近況報告を行いました。 メンター制自体も初めての試みだったためメンター同士の対応内容や新卒全員の様子が共有される場作りは、実施してよかったです。 研修メニュー内容 各研修内容のご紹介です。 オリエンテーション オリエンテーションは 外部ビジネス研修 コンプライアンス研修 セキュリティ研修 開発環境の整備 開発ツールの解説 がメインです。 Mac を渡されて、「勝手に開発環境作ってね」というのは新卒エンジニアにはハードルが高いので、筆者が付きっきりで時間をかけてフォローしました。 オリエンテーションは約 1 週間程度ですが、ここで「メドレー社員の一人になった」という実感を持ってもらう ことができました。 開発基礎研修 大きく 2 部構成です。最初の部では、メドレーでエンジニアに期待していることや、既存サービスなどのシステム構成・ビジネスの流れなどを座学で実施しました。 もう一つの部では書籍の輪読をしました。この輪読は、Web サービスの基本の仕組みと、Web サーバ自体を支える OS である Linux の基本を覚えてもらいたいという趣旨で開催しました。 メドレーについて こちらの部では CTO 平山から「メドレーのエンジニアとして求めること」と題して、求められるエンジニアリングとは何なのか?自分達のキャリアパスなどをディスカッションしました。 その後は、 ジョブメドレー ・ CLINICS ・ 介護のほんね などメドレーが提供しているプロダクトについて、システムの概要やビジネスモデルとシステムの対応について講義。 メドレーでのエンジニアは各々専門性がある技術領域を持ちつつ、その領域に限定せずに広い分野で開発をしていますし、プロダクトを第一に考え開発しますが、そのために技術を武器としていくバランス感覚が必要になります。 この段階でまずこうした メドレーでエンジニアとして働くとはどういうことなのか という知識や考え方を新卒メンバーに勉強してもらいました。 エンジニアとは何か エンジニアの価値は何か プロエンジニアとは何か エンジニアではない職種との違いは何か といった基本的な話から、 2030 年のみんなはどうなっているのか、どうなっていたいのか 先輩エンジニアはどのようなことに悩み、どのようにアプローチをして、力をつけてきたのか、それを超えるためのヒントはどこにあるか メドレーのエンジニアとして求めたいことは何か といった踏み込んだ話も含め、個人ワークやグループワークも交えながら伝えていきました。 導入があることで、これからのカリキュラムを実施していく上での心構えができる期間だったのではないかと思います。 輪読会 座学でプログラミングのことを勉強させるのではなく、主体性を持ち、基礎知識を習得してほしいと考えていたので、 プランを作っている初期段階から輪読会をすることを決めていました。 参考にさせていただいたのは ドワンゴさんの 2016 年の研修の記事 です。 輪読で使用する本の選定は悩んだのですが、弊社で使っている Ruby や Ruby on Rails のことや、JavaScript などの技術より、基本となる Web 自体についての知識や、Web サーバで使う Linux の事などを習得してもらいたいということを考えて以下の 2 冊で輪読を行いました。 Web を支える技術 ── HTTP，URI，HTML，そして REST（WEB+DB PRESS plus シリーズ） Go ならわかるシステムプログラミング 「Web を支える技術」の輪読の形式は毎回決まった章を筆者が講義しつつ、時折質問などをメンバーに投げかけたりしながら理解を深めました。 議事録も新卒メンバー全員で順番を決めてもらうという、自主性に基づくスタイルにしました。 まず輪読の雰囲気になれてもらうこと、それから議事録を取りつつドキュメンテーションの練習をすること を狙いとしています。 最初はぎこちなかった部分もありましたが、回を重ねるにつれて、自分の経験や知識も含めたディスカッションにも発展するようになり、全員自主性を持ちながら実施できました。 対して「Go ならわかるシステムプログラミング」については 新卒メンバーに章を割り当てて、各自講師をしてもらいました。 元々レポートを 3 回発表することを予定していたので、本の内容を読んできちんと理解した上で、 他人へ伝える力を養う ことをサブ目標にしています。 さらなる自主性も必要になる上、本の性質上ほとんどのメンバーが触っていない Go 言語を使ってプログラムを書いてシステムのことを理解しないといけない為、プログラムの本質的な部分に触れることもできたのではないかと思います。 開発実践 開発実践は上記の開発基礎と並行して午後から実施しました。 1 日の午前が開発基礎、午後が開発実践というスケジュールです。 実践は新卒メンバーで社内ツールを実際の業務形式で開発してもらいました。 題材は**「メドレーの使い方に合ったビルの予約システムを作る」**というものです(以前 SmartHR さんが同じビルだったので少しアプローチが違いますが ブログ に書いてました)。 メドレーでの業務開発と同じ形式で ユーザーからの要望をヒアリング 要件定義 開発計画の策定 システム設計 チームで分担してながらの開発 ベータ版としてリリースしたものをブラッシュアップ 実稼働するための環境整備をしながらリリースする という一連のプロセスで開発しました。 「開発自体どうやって進めるか」「仕様をどうするか」など基本的な所から、全行程を新卒メンバー主体で考えて実行してもらい、メンター陣は所々 MTG や PR をレビューしながら、アドバイスをするという形式で行いました。 新卒メンバー全員が同じスキルセットを持っているわけでもないですし、得意・不得意も違う為、まず最初に彼ら自身にリーダーを決めてもらい、リーダーがオーナーシップを持って開発を進めてもらいました。 チームでの開発というのはほとんど全員が初めてだったため、かなり困惑しているところもありましたが、研修の過程で理解した互いのスペシャリティを活かして、役割分担をしつつ、決まった納期にきちんとリリースすることができました。メンターとしてそばで見ていましたが、新卒メンバー全員の成長を実感しましたし、純粋に凄いと感じました。 途中で納期に間に合わせるための要件の取捨選択をしなければならなかったり、自分達が考えた仕様が必ずしもベストというわけではなく、さらに色々と考える要素が必要だったりという 開発のリアルを経験できた のは次の OJT に活きたと思います。 余談ですが、こちらの元々のシステムを調査する上で「Web を支える技術」の知識が早速役に立つという場面が多く、やはり 基本は大事だな、と思った 次第です。 開発部 OJT 基礎研修が終わってから、既存サービスにジョインしての OJT 実施となりました。 ここまでの研修で、ある程度の知識や業務の進め方などは習得していたので、何をすればよいか分からないということはありませんでした。 メンバーによってはここで時間を取って Ruby on Rails について習得をしてもらいました。 大きい失敗なども特にはなく粛々と進められたのは良かったのではないかと思います。 事業部 OJT 開発部 OJT の途中で 2 週間ずつ時間を取って、人材プラットフォーム事業と医療メディア事業での事業部 OJT を行いました。 **どこで顧客とコンタクトし、お金をいただき、どのような形で自分達が作ったシステムに関わっていくのか?**というのをこの時期に体験してもらうことが目的です。 研修はビジネスの流れに沿って行ないました。研修メニューは、事業部の主要メンバーにコンセプトの共有をし、メニューを考えて実施してもらいました。（ありがとうございます！） 実際に電話でアポイントを取ったり、顧客のサポートを電話やビデオチャットでしたり、営業をどうやっているのかを体験したり…などを 2 週間かけて新卒メンバーに体験してもらいました。 この後に実際**「このシステムの機能はこういうときに使うのかと実感した」とか「やっていてこのような仕様のほうが良いと思った」などの感想**をそれぞれのメンバーが持っていて、やはり実施して良かったなと強く感じました。 レポート発表 それぞれの研修の終わりにはレポート発表の時間を設け、一人一人振り返りを書いてもらいます。その為に週報の提出も義務付けました。また研修期間の終了時には弊社役員陣にプレゼンする最終レポート発表の時間を取りました。 ひたすら研修内容をこなしていくという形になりがちなので、 振り返りの期間を設けて記録を付けていき、自分の成長や反省などを可視化したい という目的です。 また、メドレーでは ドキュメントドリブンで開発に限らず全社員が Confluence でドキュメントを書いていく文化 なので、文書を誰にでも分かるように論理的に書く技術が求められます。こういったレポートの記述やそのフィードバックから文書技術を高めてほしいという目的もありました。 レポートに関してはメンター陣やマネージャ陣に発表してもらうという形にしていたので、発表自体やレポートのまとめ方などに都度フィードバックをするようにしました。 最初はレポートが読みづらいなどもありましたが、回を重ねるごとに段々洗練されたレポートや発表になってきたのが印象的 です。 最終レポートは代表を始めとした経営陣に向けてレポートを発表してもらいました。今まで自分達がやってきた全ての業務を、前提の知識がない聴衆に向けて発表するということで、各自が趣向を凝らしての発表になり、経営陣からも高評価をもらっていました。 まとめ メドレーで初の新卒研修は以上のような形で終わることができました。 かなりのハードスケジュールだったとか、開発部 OJT をもう少し現場と色々と話しあったほうが効果的だったかもなど反省点もありますが、現在新卒メンバーが 10 月から実際の業務で活躍しているところを見ているので、ある程度の成功を収めることができたのではないかと思います。 来年度のメニューはまた違ったものになる可能性がありますが、今年の研修でも重視した**「メドレーでエンジニアとして働くことに対する意義を感じながら業務をしてもらう」**という部分はズラさずに実施していければと思います。 長々とお付き合いいただきありがとうございました。

こんにちは。エンジニアの平木です。 メドレーでは今年度より新卒採用活動を本格化しており、今年はエンジニア 4 名が新卒社員として入社しました。 現在、新卒メンバーは 6 ヶ月の開発研修が無事終了し、各部署で業務に勤しんでいますが、このエントリでは、**初めての新卒研修をどのような視点で計画・実行していったか?**を書いていきたいと思います。 2019 年度新卒入社メンバー 新卒研修を決めるまでやったこと 研修の大枠決定 カリキュラムの大枠を決めるため、まず CTO の平山が「こんなことをやろう」という大枠の方向性を出し、施策レベルに筆者が落としこんでいきました。 決めたことは、以下３点です。 入社後の導入部分 社会人としてのビジネスマナーや考え方の基礎を学ぶ プロダクト開発をする上で必要になる基礎を学ぶ 会社の事業内容を理解する OJT をメインとした各チームへの仮配属 新卒社員へのフォローアップ メンターや部長との定期報告会 半年後に役員陣への成果報告会 エンジニアとして価値を出していくため必要な**「社会の課題を解決するために、日々自身の腕を磨き、純粋に取り組む、ただそれだけ」**という、メドレーが求めるエンジニアとしての姿勢をきちんと体得してもらうことが目標です。 こちらについては平山のブログに詳しく書かれているので、ぜひご参照ください。 toppa.medley.jp toppa.medley.jp 情報収集 社内エンジニアへのヒアリング 前職で新卒研修を受けたことがある社内の 20 代~30 代のエンジニア 4 人を対象に、研修内容についてヒアリングしました。 ヒアリングしたポイントは 研修の期間 研修全体の流れ 各研修メニューの内容 OJT はどういった形で受けたか 研修を受けての感想 など。各社・各年代で個性が出るなという印象を持ちました。 やはり、エンジニアということで座学よりも手を動かすハンズオン形式の方が印象に残ることや、印象的な研修メニューは時間が経っても覚えているという傾向が分かりました。 ネットでの情報収集 ご存知の通り、近年では新卒研修のブログや、学習プログラムに関しては多くの企業様が書かれています。 しかし、内容としては**「アプリ開発をこのような形式で行ないました」という情報が多く、研修全体や社内情勢も踏まえた背景などが書かれているものは意外に少ないな**という印象を持ちました。 そんな中、各社の新卒研修エントリが Gist にまとめられているのを発見しました。 こちらは大変参考になりました。作者の方にはこの場をお借りして感謝させていただきます。 研修資料まとめ.md GitHub Gist: instantly share code, notes, and snippets. gist.github.com 研修メニュー決定 研修の詳細メニュー ここまでの過程を踏まえ研修メニューを筆者が考え、CTO や開発部部長の田中・副部長の稲本と刷り合わせをしていきました。 結果として、以下のメニュー構成でいくことになりました。 オリエンテーション **[座学]**社会人研修や会社全般の知識の習得を目的にする 開発基礎研修 **[座学]**Web アプリケーション開発の基本や、エンジニアとしての心得、会社の展開するサービスの基本知識を習得することを目的にする 開発実践研修 **[OJT]**社内向けに Web アプリケーションを開発し、チーム開発を実践することを目的にする 開発部 OJT **[OJT]**稼動しているサービスの開発を通して、業務としての開発を実践することを目的にする 事業部 OJT **[OJT]**ビジネスサイドの業務を体験し、開発以外の会社の業務の全体像を理解することを目的にする 特に事業部 OJT は新卒メンバーには必ず理解してもらいたい、と決まった研修項目です。 メドレーではプロダクトファーストで開発しますが、プロダクトの機能や要望は実際のビジネスの流れと密接に関わっています。 新卒メンバーもこういった流れを把握出来ていないと、要点を押さえた開発ができません。 実際にどのような流れで顧客と関わっていき、自分達が開発するプロダクトにどう影響していくかを体験 してもらうために、この事業部 OJT をメニューに組み込みました。 研修期間 研修の期間についても様々な意見が出ましたが、最終的には配属後の業務にスムーズに入ってもらえるように、基礎を重視して長めに研修時間を取ったほうがよいと決め、以下の通り全 6 ヶ月という研修期間を定めました。 オリエンテーション・開発基礎研修・開発実践研修 2 ヶ月 期間中、午前：開発基礎、午後：開発実践 開発部 OJT ・事業部 OJT 4 ヶ月 事業部 OJT は期間中に 2 週間 x 2 つの事業部で実施 メンター 研修全体の統括は筆者になりますが、新卒メンバーがいつでも相談できるように 1 人につき 1 人のメンターを付けています。社会人経験が 3 年以上ある社員をメンターとしました。 最初の 2 週は毎日 1on1 を 15 分程度行ない、以降は毎週金曜日に 1 時間の 1on1 を実施。 また、メンター同士の交流として、2 週に 1 度メンターの共有会を開き、相談や近況報告を行いました。 メンター制自体も初めての試みだったためメンター同士の対応内容や新卒全員の様子が共有される場作りは、実施してよかったです。 研修メニュー内容 各研修内容のご紹介です。 オリエンテーション オリエンテーションは 外部ビジネス研修 コンプライアンス研修 セキュリティ研修 開発環境の整備 開発ツールの解説 がメインです。 Mac を渡されて、「勝手に開発環境作ってね」というのは新卒エンジニアにはハードルが高いので、筆者が付きっきりで時間をかけてフォローしました。 オリエンテーションは約 1 週間程度ですが、ここで「メドレー社員の一人になった」という実感を持ってもらう ことができました。 開発基礎研修 大きく 2 部構成です。最初の部では、メドレーでエンジニアに期待していることや、既存サービスなどのシステム構成・ビジネスの流れなどを座学で実施しました。 もう一つの部では書籍の輪読をしました。この輪読は、Web サービスの基本の仕組みと、Web サーバ自体を支える OS である Linux の基本を覚えてもらいたいという趣旨で開催しました。 メドレーについて こちらの部では CTO 平山から「メドレーのエンジニアとして求めること」と題して、求められるエンジニアリングとは何なのか?自分達のキャリアパスなどをディスカッションしました。 その後は、 ジョブメドレー ・ CLINICS ・ 介護のほんね などメドレーが提供しているプロダクトについて、システムの概要やビジネスモデルとシステムの対応について講義。 メドレーでのエンジニアは各々専門性がある技術領域を持ちつつ、その領域に限定せずに広い分野で開発をしていますし、プロダクトを第一に考え開発しますが、そのために技術を武器としていくバランス感覚が必要になります。 この段階でまずこうした メドレーでエンジニアとして働くとはどういうことなのか という知識や考え方を新卒メンバーに勉強してもらいました。 エンジニアとは何か エンジニアの価値は何か プロエンジニアとは何か エンジニアではない職種との違いは何か といった基本的な話から、 2030 年のみんなはどうなっているのか、どうなっていたいのか 先輩エンジニアはどのようなことに悩み、どのようにアプローチをして、力をつけてきたのか、それを超えるためのヒントはどこにあるか メドレーのエンジニアとして求めたいことは何か といった踏み込んだ話も含め、個人ワークやグループワークも交えながら伝えていきました。 導入があることで、これからのカリキュラムを実施していく上での心構えができる期間だったのではないかと思います。 輪読会 座学でプログラミングのことを勉強させるのではなく、主体性を持ち、基礎知識を習得してほしいと考えていたので、 プランを作っている初期段階から輪読会をすることを決めていました。 参考にさせていただいたのは ドワンゴさんの 2016 年の研修の記事 です。 輪読で使用する本の選定は悩んだのですが、弊社で使っている Ruby や Ruby on Rails のことや、JavaScript などの技術より、基本となる Web 自体についての知識や、Web サーバで使う Linux の事などを習得してもらいたいということを考えて以下の 2 冊で輪読を行いました。 Web を支える技術 ── HTTP，URI，HTML，そして REST（WEB+DB PRESS plus シリーズ） Go ならわかるシステムプログラミング 「Web を支える技術」の輪読の形式は毎回決まった章を筆者が講義しつつ、時折質問などをメンバーに投げかけたりしながら理解を深めました。 議事録も新卒メンバー全員で順番を決めてもらうという、自主性に基づくスタイルにしました。 まず輪読の雰囲気になれてもらうこと、それから議事録を取りつつドキュメンテーションの練習をすること を狙いとしています。 最初はぎこちなかった部分もありましたが、回を重ねるにつれて、自分の経験や知識も含めたディスカッションにも発展するようになり、全員自主性を持ちながら実施できました。 対して「Go ならわかるシステムプログラミング」については 新卒メンバーに章を割り当てて、各自講師をしてもらいました。 元々レポートを 3 回発表することを予定していたので、本の内容を読んできちんと理解した上で、 他人へ伝える力を養う ことをサブ目標にしています。 さらなる自主性も必要になる上、本の性質上ほとんどのメンバーが触っていない Go 言語を使ってプログラムを書いてシステムのことを理解しないといけない為、プログラムの本質的な部分に触れることもできたのではないかと思います。 開発実践 開発実践は上記の開発基礎と並行して午後から実施しました。 1 日の午前が開発基礎、午後が開発実践というスケジュールです。 実践は新卒メンバーで社内ツールを実際の業務形式で開発してもらいました。 題材は**「メドレーの使い方に合ったビルの予約システムを作る」**というものです(以前 SmartHR さんが同じビルだったので少しアプローチが違いますが ブログ に書いてました)。 メドレーでの業務開発と同じ形式で ユーザーからの要望をヒアリング 要件定義 開発計画の策定 システム設計 チームで分担してながらの開発 ベータ版としてリリースしたものをブラッシュアップ 実稼働するための環境整備をしながらリリースする という一連のプロセスで開発しました。 「開発自体どうやって進めるか」「仕様をどうするか」など基本的な所から、全行程を新卒メンバー主体で考えて実行してもらい、メンター陣は所々 MTG や PR をレビューしながら、アドバイスをするという形式で行いました。 新卒メンバー全員が同じスキルセットを持っているわけでもないですし、得意・不得意も違う為、まず最初に彼ら自身にリーダーを決めてもらい、リーダーがオーナーシップを持って開発を進めてもらいました。 チームでの開発というのはほとんど全員が初めてだったため、かなり困惑しているところもありましたが、研修の過程で理解した互いのスペシャリティを活かして、役割分担をしつつ、決まった納期にきちんとリリースすることができました。メンターとしてそばで見ていましたが、新卒メンバー全員の成長を実感しましたし、純粋に凄いと感じました。 途中で納期に間に合わせるための要件の取捨選択をしなければならなかったり、自分達が考えた仕様が必ずしもベストというわけではなく、さらに色々と考える要素が必要だったりという 開発のリアルを経験できた のは次の OJT に活きたと思います。 余談ですが、こちらの元々のシステムを調査する上で「Web を支える技術」の知識が早速役に立つという場面が多く、やはり 基本は大事だな、と思った 次第です。 開発部 OJT 基礎研修が終わってから、既存サービスにジョインしての OJT 実施となりました。 ここまでの研修で、ある程度の知識や業務の進め方などは習得していたので、何をすればよいか分からないということはありませんでした。 メンバーによってはここで時間を取って Ruby on Rails について習得をしてもらいました。 大きい失敗なども特にはなく粛々と進められたのは良かったのではないかと思います。 事業部 OJT 開発部 OJT の途中で 2 週間ずつ時間を取って、人材プラットフォーム事業と医療メディア事業での事業部 OJT を行いました。 **どこで顧客とコンタクトし、お金をいただき、どのような形で自分達が作ったシステムに関わっていくのか?**というのをこの時期に体験してもらうことが目的です。 研修はビジネスの流れに沿って行ないました。研修メニューは、事業部の主要メンバーにコンセプトの共有をし、メニューを考えて実施してもらいました。（ありがとうございます！） 実際に電話でアポイントを取ったり、顧客のサポートを電話やビデオチャットでしたり、営業をどうやっているのかを体験したり…などを 2 週間かけて新卒メンバーに体験してもらいました。 この後に実際**「このシステムの機能はこういうときに使うのかと実感した」とか「やっていてこのような仕様のほうが良いと思った」などの感想**をそれぞれのメンバーが持っていて、やはり実施して良かったなと強く感じました。 レポート発表 それぞれの研修の終わりにはレポート発表の時間を設け、一人一人振り返りを書いてもらいます。その為に週報の提出も義務付けました。また研修期間の終了時には弊社役員陣にプレゼンする最終レポート発表の時間を取りました。 ひたすら研修内容をこなしていくという形になりがちなので、 振り返りの期間を設けて記録を付けていき、自分の成長や反省などを可視化したい という目的です。 また、メドレーでは ドキュメントドリブンで開発に限らず全社員が Confluence でドキュメントを書いていく文化 なので、文書を誰にでも分かるように論理的に書く技術が求められます。こういったレポートの記述やそのフィードバックから文書技術を高めてほしいという目的もありました。 レポートに関してはメンター陣やマネージャ陣に発表してもらうという形にしていたので、発表自体やレポートのまとめ方などに都度フィードバックをするようにしました。 最初はレポートが読みづらいなどもありましたが、回を重ねるごとに段々洗練されたレポートや発表になってきたのが印象的 です。 最終レポートは代表を始めとした経営陣に向けてレポートを発表してもらいました。今まで自分達がやってきた全ての業務を、前提の知識がない聴衆に向けて発表するということで、各自が趣向を凝らしての発表になり、経営陣からも高評価をもらっていました。 まとめ メドレーで初の新卒研修は以上のような形で終わることができました。 かなりのハードスケジュールだったとか、開発部 OJT をもう少し現場と色々と話しあったほうが効果的だったかもなど反省点もありますが、現在新卒メンバーが 10 月から実際の業務で活躍しているところを見ているので、ある程度の成功を収めることができたのではないかと思います。 来年度のメニューはまた違ったものになる可能性がありますが、今年の研修でも重視した**「メドレーでエンジニアとして働くことに対する意義を感じながら業務をしてもらう」**という部分はズラさずに実施していければと思います。 長々とお付き合いいただきありがとうございました。