こんにちは、医療プラットフォーム本部/プロダクト開発室/第一開発グループ所属の世嘉良です。 メドレーには 2018 年の頭に入社しており、今年で 4 年目になります。 当初はサーバーサイドを中心に開発を担当していたのですが、最近は患者エンゲージメントチームという患者様に提供するサービスを開発するチームで主に iOS の仕事を担当することが多いです。 さて去年の 12 月になりますが、 CLINICS アプリ は UI のフルリニューアル を行いました。 今回はリニューアルの裏話 (iOS について) をしていきたいと思います。 これまでの CLINICS アプリについて 本題を書く前に、CLINICS アプリの歴史を紹介します。 ファーストコミットを見てみると、アプリの開発は 2016 年 2 月ごろからスタートし、ファーストリリースが行われたのが 2016 年 5 月でした。 当初、担当していたエンジニアは iOS の経験が豊富な方はおらず、全員で試行錯誤しながら開発を進めていたようです。 しばらくの間は機能の追加などが行われていましたが、 CLINICS カルテ の開発に注力するために大きな開発はストップし、 Pharms との連携が開始される 2020 年 5 月頃まで機能や設計に関する見直しがほとんど行われてきませんでした。 iOS に詳しいエンジニアがいなかったにも関わらず、かなりのスピード感でリリースしていることはさすがの開発力という一言に尽きるのですが、Pharms との連携やお薬手帳といった機能が追加されたり、今後の開発を見据えた際に既存機能や設計の見直しを行いたいと思うようになってきました。 改善したい部分はたくさんあったのですが、対応工数を踏まえ今回のリニューアルでは以下の 2 点の改善に注力することにしました。 Storyboard による View の管理 View とロジックの分離 この 2 点についてそれぞれ詳しく説明します。 1. Storyboard による View の管理 従来の開発では Storyboard を利用して View を作成していました。 Storyboard を使うとレイアウトや画面遷移を簡単に実装することができますが、開発を続けているうちに以下のような問題が目立つようになってきました。 Storyboard が巨大化していき、複数人開発を行う際に支障がでる レイアウトに追加・変更が行われた場合に AutoLayout の再設定に時間がかかる コンポーネント自体にサイズが設定されていることがあり、コンポーネントを再利用できないことがある 課題 こちらは実際にあった Storyboard のキャプチャですが、複数の画面が 1 つの Storyboard 内に詰め込まれた状態となっていました。 Storyboard は Xcode のバージョンにより微妙な差分が発生してしまったり、AutoLayout の調整が必要になる場合があります。 こちらは古い Storyboard の画面を開いた後の差分なのですが、この変更がシステムによって加えられた変更なのか、他人の改修による変更なのかを後から見た時にわかりづらいという問題がありました。 仮に問題が発生した場合は修正を試みるのですが、独自の XML によって表現されているため、iOS の経験が浅い僕にとっては修正が非常に難しかったです。 また、複数人で並行して開発する際にもコンフリクトが起きやすくなってしまい解消に時間がかかるという問題となっていました。 さらに従来の CLINICS アプリは DLS を利用してレイアウトを作成していたのですが、コンポーネントに直接サイズが設定されているものがあり、ある画面では微妙にサイズを調整したい…といった要件に対応できず、せっかくのコンポーネントを再利用できないケースがありました。 解決案 課題に対する解決案は色々と考えられますが、弊社の開発スタイルやエンジニアのスキルを考慮し以下のような方針を立てました。 Storyboard と各画面の実装は 1 : 1 の関係とする 画面遷移の責務も Storyboard から切り離す コンポーネントにアトミックデザインを適用する Storyboard の分割は以下のようなステップで行っていました。 Refactor to Storyboard を使って巨大な Storyboard を分割する SwiftGen を利用し画面生成のコードを自動作成する 2 で生成したものを利用して画面遷移を行う 既存の Segue を削除する まず最初に Xcode 7 から利用可能となった「Refactor to Storyboard」を使って画面を分割するところから始めます。 この機能を利用すると選択した View が新しい Storyboard に切り出され、元の Storyboard には切り出した Storyboard へのリファレンスや Segue 等の接続が保持された状態になります。 次に各画面間の遷移を Segue を使わずに行うようにします。 Segue は便利なのですが、Identifier が単なる文字列であったり、Storyboard を分割してもリファレンスは保持しておく必要がある点が微妙に感じてしまい利用しないことにしました。 Segue を使わずに画面遷移を行う必要があるため、画面生成と画面遷移の方法を自前で実装する必要があります。 今回は画面生成の処理を SwiftGen を利用して自動生成可能にし、VIPER というアーキテクチャの Router を参考にして画面遷移を Storyboard から切り離すことにしました。 ※ SwiftGen の利用方法は SwiftGen#interface-builder を参照ください。 Router の実装は以下の通りです。 実装されたプロトコルを遷移元の VC に継承し、画面遷移のコードを呼び出すだけで画面遷移を行うことができます。 protocol ClinicWireframe : AnyObject { var viewController: UIViewController { get } func presentClinic ( clinicId : String ) func pushClinic ( clinicId : String ) } extension ClinicWireframe { func presentClinic ( clinicId : String ) { let vc = StoryboardScene. Clinic . initialScene . instantiate { ClinicViewController ( coder : $0 , isHeaderEnabled : true ) } let presenter = ClinicPresenter ( view : vc) presenter. setClinicId ( clinicId : clinicId) vc. inject ( presenter : presenter) vc. modalPresentationStyle = . pageSheet let nc = UINavigationController ( rootViewController : vc) viewController. present (nc, animated : true ) } func pushClinic ( clinicId : String ) { let vc = StoryboardScene. Clinic . initialScene . instantiate { ClinicViewController ( coder : $0 , isHeaderEnabled : false ) } let presenter = ClinicPresenter ( view : vc) presenter. setClinicId ( clinicId : clinicId) vc. inject ( presenter : presenter) viewController. navigationController ?. pushViewController (vc, animated : true ) } 最後にコンポーネントの調整についてですが、CLINICS アプリではアトミックデザインを簡略化し、以下のような基準でコンポーネントを実装しています。 Block: UI の最小単位 (他の PJT にも持ち込めそうなレベルまで分解されたもの) Partial: CLINICS の PJT 固有のコンポーネント Layout: ヘルプ用のモーダルやエラー画面など他の画面から呼び出されることで初めて意味をなす画面など Page: 各 ViewController とそれに紐づく Storyboard この管理方法自体は 弊社の別プロダクトの開発を担当しているエンジニアによって考案されたものです。 弊社ではサーバー・フロント分け隔てなく開発を任されることも多く、厳密なアトミックデザインだとコンポーネントの分類に困ることが多かったためこのような管理方法をとっているそうです。 今回のリニューアルに際して CLINICS アプリでもこれを参考にすることにしました。 これまで DLS として管理されていたコンポーネントは Block で実装しなおし、Width / Height といったサイズの設定を行わないようにしました。 このようにコンポーネントの実装レベルを明確にしたことで、実装に一定の指針が生まれ使い回しの効くコンポーネントを作成しやすくなりました。 2. View とロジックの分離 スピード開発が求められた背景を考えると仕方のないことではあるのですが、従来の CLINICS アプリでは ViewController にロジックが記述されており、俗にいう Fat ViewController の状態になってしまっていました。 Fat ViewController の問題点については既にさまざまな方が取り上げていますが、以下の部分が問題と感じています。 UI とロジックが分離されていないため、テストを書くことが難しい 可読性が低くなりがち ロジックが切り出されていないため似たような実装が点在する場合がある 課題 こちらは実際にあった ViewController の一部です。 このコードに関しては以下の部分が問題と感じていました。 通信処理の呼び出しが ViewController の責務になっていること 通信結果を整形するロジックが ViewController の責務になっていること 画面描画のための State 管理が ViewController の責務になっていること 解決案 UI とロジックを分離するための手法はさまざまなものがありますが、弊社のアプリには以下のような特徴があります。 iOS 以外にも複数のプラットフォームをサポートしているためフロントエンドで保持するデータや複雑なロジック自体は少ない (サーバー側でなるべく担保している) 実装時や QA 時に感じた違和感について細かくディレクターと打ち合わせし、その結果次第では仕様を変更することがある これらを考慮すると、プロジェクトの期間的に初期の導入コストが低く、データフローがシンプルなものに留めたいというように考えがまとまってきました。 これらを考慮し、CLINICS アプリでは MVP というアーキテクチャを採用することにしました。 より詳細には MVP の Passive View 方式を採用しており、以下のような形で実装しています。 View は基本的にすべての入力イベントに対応した Presenter の処理を呼び出す Presenter は入力に応じて通信処理などの外部要因となる処理を呼び出し、結果を整形する プレゼンテーションロジックの結果を描画するように View に指示を出す View は Presenter の指示によってのみ描画処理を行い、自身を起点とした描画処理は行わない Model–view–presenter - Wikipedia 既に Router は導入してるため、複雑な処理フローを実装したい場合は Interactor を導入するだけで VIPER アーキテクチャへと発展させることが簡単にできる点も魅力でした。 CLINICS アプリでの ViewController / Presenter の実装を簡単にまとめたものは以下のようになっています。 final class ClinicViewController : UIViewController { private lazy var presenter: ClinicPresenterInput = { fatalError (“Failed to inject presenter”) }() override func viewDidLoad () { super . viewDidLoad () presenter?. refresh () } func inject ( presenter : ClinicPresenterInput) { self . presenter = presenter } // タップされた際に呼び出す func onTapServiceCell ( _ service : ServiceEntity, isTelemedicine : Bool ) { presenter?. didTapServiceButton (service, isTelemedicine : isTelemedicine) } } // MARK: - ClinicPresenterOutput extension ClinicViewController : ClinicPresenterOutput { func reloadData ( clinic : ClinicEntity?) { clinicViewStore. clinic = clinic } func openCreateAppointmentView ( clinic : ClinicEntity, service : ServiceEntity, isTelemedicine : Bool ) // 予約へ進む } func showErrorAlert ( _ error : Error ) { // エラー表示を行う } } protocol ClinicPresenterInput : AnyObject { func refresh () func didTapServiceButton ( _ service : ServiceEntity, isTelemedicine : Bool ) } protocol ClinicPresenterOutput : AnyObject { func reloadData ( clinic : ClinicEntity?) func openCreateAppointmentView ( clinic : ClinicEntity, service : ServiceEntity, isTelemedicine : Bool ) func showErrorAlert ( _ error : Error ) } final class ClinicPresenter { private let clinicRepository: ClinicRepository private var clinic: ClinicEntity? private var cancellables: Set <AnyCancellable> = . init () init ( view : ClinicPresenterOutput, container : DIContainer) { self . view = view clinicRepository = container. resolve () } private func reloadView () { view?. reloadData ( clinic : clinic) } } // MARK: - PresenterInput extension ClinicPresenter : ClinicPresenterInput { func refresh () { guard let clinicId = clinicId else { return } clinicRepository. getClinic ( clinicId : clinicId) . sink ( receiveCompletion : { [ weak self ] completion in guard let self = self else { return } guard case let . failure (error) = completion else { return } self . view ?. showErrorAlert (error) } }, receiveValue : { [ weak self ] response in guard let self = self else { return } self . clinic = response. data self . reloadView () } ) . store ( in : &cancellables) } func didTapServiceButton ( _ service : ClinicsServiceEntity, isTelemedicine : Bool ) { guard let clinic = clinic else { return } view?. openCreateAppointmentView ( clinic : clinic, service : service, isTelemedicine : isTelemedicine) } } ViewController と Presenter は以下のように Router の内部で DI するようにしています。 protocol ClinicWireframe : AnyObject { var viewController: UIViewController { get } func pushClinic ( clinicId : String ) } extension ClinicWireframe { func pushClinic ( clinicId : String ) { let vc = StoryboardScene. Clinic . initialScene . instantiate { ClinicViewController ( coder : $0 , isHeaderEnabled : false ) } let presenter = ClinicPresenter ( view : vc, container : DIContainer ()) presenter. setClinicId ( clinicId : clinicId) vc. inject ( presenter : presenter) viewController. navigationController ?. pushViewController (vc, animated : true ) } } これによって、もともと ViewController にあった処理は以下のように分離されました。 また、View と Presenter はインターフェースを介してしかお互いを知らないため、実装の交換が簡単にできるようになりました。 Presenter を交換することで 1 つの View で別々の処理を表現することが可能となったり、View をテストコードを交換することで Presenter の入出力値をテストすることができるようになっています。 まとめ CLINICS アプリは歴史のあるプロジェクトですが、今回のプロジェクトを通して UI だけでなく裏側の実装も刷新しています。 巨大な Storyboard を分解したことでメンテナビリティが向上し、MVP (+ Router) の導入によって View とロジックの交換が簡単になり、テストなどの実装を取り入れやすくなりました。 さいごに ブログの本編には書けなかったのですが、今回リニューアルされた画面に関しては SwiftUI を利用してフルスクラッチで実装していたり、 Asset の管理方法についても大きな見直しを行いました。 またアーキテクチャの選定にあたり、「 iOS アプリ設計パターン入門 」が大変参考になりました。iOS の開発を行う方はぜひ一読してほしいと思います。 約半年ほどかかった大きなプロジェクトでしたが、患者エンゲージメントチームのメンバー全員で取り組み無事にリリースまで漕ぎ着けることができました。まだまだ手探りな部分もありますが、今後も患者さんにとってより安心して使えるサービスとなるように開発を続けていければと思っています。 長くなりましたが、最後までお読みいただきありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは、メドレーのコーポレート本部法務コンプライアンス部で、知的財産関連の業務を担当している鬼鞍です。 1 年ほど前に本ブログで「 特許とはなにか 」というテーマで当社における特許啓蒙活動を紹介させて頂いたのですが、思っていた以上に反響があり、「面白い」とか「わかりやすい」という嬉しいコメントも頂戴しました。 私がメドレーに入社して最初のミッションが知財部門の立ち上げだったので、次はぜひ**「ベンチャーでの知財部門の立ち上げ方」**的なテーマでブログ発信したいと思っていたのですが、当初はまだ具体的な社内事例が少なかったため、実績ができた段階で改めて本ブログで発表したいと思っていました。 それから１年以上が経過して実際に特許も取得するなど知財活動としての実績が蓄積されてきたため、これを機会に ベンチャーで知財部門を立ち上げる際にやるべきことについて、実例に触れながら具体的にまとめてみました。 かなり長いコンテンツになってしまいましたが、 フェーズごとの知財活動計画 であったり、 知財ロードマップの作り方 など、 なかなか表に出てこない知財部門立ち上げストーリーの具体的事例を惜しみなく書かせていただいております ので、ぜひご一読いただき、お役に立てれば幸いです。 知財は開発チームとの信頼関係の構築がまず第一 先ほどは知財部門を立ち上げストーリの中で、知財活動計画とか、知財ロードマップであるとか少し格好つけたような文字が羅列していましたが、実は私が知財専任として初めに配置されて最初にやったことはそんな大それたことではありませんでした。 最初になにをやったかというと、 エンジニアの方とランチに行く、あるいは飲みに行く 、ということでした。当時はまだ Covid-19 が蔓延する前だったので気軽にそういうことができました。入社して最初の 1 ヶ月くらいは週 2 回くらいのペースで誰かとランチか飲みにいくということをしていたと思います。 飲みに行く、というとふざけているとか思われるかもしれませんが、知財部門の立ち上げストーリーを語る上で、このプロセスは無視できないほど重要だと考えています。先に断っておくと私は酒好きでもなければ、家でも一切飲みません。 当たり前のことなのですが、知財というのはプロダクトを生み出す開発組織があって初めて価値を発揮するものです。知財はあくまで事業や開発をサポートするところであって、それ単体で存在意義を発揮することはほぼありません。特に特許活動については開発チームとの連携が非常に重要です。 一緒にご飯を食べることが信頼関係を構築する上で最良の方法、とまでは言いませんが、少なくともご飯を食べない人はいないわけで、時間を無駄にしている感もなければ、オフィスの外で会えば仕事以外のことを話題にし易いので互いの趣味嗜好を知ることができます。みなさんもそうだと思いますが、通常、仲の悪い人とは一緒に食事はしないと思います。 特に、この後にもご紹介する 社内のアイデアを発掘するという発明発掘活動は、話しやすいカジュアルな雰囲気で雑談のような感じでブレストするというのが非常に重要 で、このときに相手がどんな人間かを互いに知っているか、知らないかでは大きな差がでてきます。 また更に、この後にご紹介する知財計画立案や知財ロードマップを作成することも当然重要なのですが、結局仕事というのは人と人との間を思考がやりとりされて実現化されていくものなので、人間関係・信頼関係が全ての基礎であり、実は一番大切にするべきものだと思います。 これは何も知財に限ったことではなく、部門を跨いで仕事をする上で信頼関係は非常に重要ですし、知財の観点で見ても 円滑なコミュニケーションが結果的にいい発明やアイデアを生み出すための土壌づくりに貢献する ものだと考えています。 知財活動計画は、事業の成長フェーズに合わせて設定する 知財部門の設立にあたって、エンジニアとのコミュニケーションと並行して進めたのが、知財活動計画の立案でした。知財活動とは、知財サイクルをうまく事業サイクルにインストールしてサイクルを循環させることであり、更にはこのサイクルが循環するための運用基盤を構築することを指します。また、ここでいう知財サイクルとは、例えば、社内に埋もれたアイデアを発掘し（創発）→ それを知財権化し（保護）→ 権利化した知財を活用し（活用）→ 活用した知財で得られた利益や結果を創発支援に適用できる形に変換する、というものです。 このような知財サイクルを、何の計画や戦略もなしに事業サイクルへインストールしようとするとうまくいきません。なぜなら、事業というのは日々成長し変化していくもので、 事業の成長に応じて知財活動の目的や課題も変化するからです 。 例えば、子会社が増えて事業規模が拡大すると、その子会社の事業領域で既に多くの特許出願がされている場合には、発明発掘活動よりもまずは法的リスクを回避することを最優先にして、他社の特許調査をしっかりやってからプロダクトをリリースする仕組みを作ろう、ということになります。あるいは、事業の成長に伴いプロダクトが成熟してきた場面では、似たようなプロダクトが乱立する結果、尖った機能や最先端技術で差別化をするようになるため、こうした場合には先行した特許取得が重要な目的になってきます。 このように、事業の成長フェーズに応じた知財活動の計画を立案するべく、まずはメドレーのミッションおよびそのミッションを実現するためのプロダクトの性質を把握する必要がありました。 メドレーは「医療ヘルスケアの未来をつくる」というミッションを掲げ、インターネットテクノロジーによる医療のあり方の変革を目指す企業です。 このミッションと向き合いつつ、 事業プラットフォームの成長フェーズごとに知財活動の方向性・目的を３段階にわけて設定し、成長フェーズごとに知財活動計画を立案しました 。 例えば、プラットフォームの創設期においては新規ユーザ獲得が重要となり、使い勝手のいいシンプルな機能に開発の方向性が向いているため、独自性のある技術を特許化するというよりも、まずは守りを固めるべく知財権侵害のリスクを最小限にして法的安定性の確保に軸足を置いた知財活動を推進します。 このような計画は、知財の観点で一方的にできるものではありません。 知財活動の計画に際しては、開発チームを統括するマネージャにプロダクト開発の方向性をヒアリングして特許取得の判断基準を検討したり、経営層に将来の事業の方向性についてヒアリングをして長期志向で目標設定したりして、ブラッシュアップしていきました。 そういった検討や議論を重ねていくうちに自然と、その企業風土や事業ミッションにあった知財活動計画というものができあがってくるのだと思います。 知財活動ロードマップで現在位置を把握しつつ定期的に軌道修正する 長期的な方向性を可視化したら次はそれをどう実行するかという実行計画が必要になってきました。 そもそも自分たちは今何ができていて、何ができていないのか。またどのようなことを今後やっていかなければならないのかが不明確だよね、という話になり、それを具体的に俯瞰するための知財ロードマッピングというものを作成しました。 縦軸に知的財産の種類、横軸に時間軸であるフェーズを設定して、知財活動の内容に過不足ないかをチェックできるようにしました。 定期的に内容を見直してメドレーの事業規模にあった形に修正しながら自分達の現在位置を把握し、今後の方向性を見定めるためのツールとして有効でした。 このようなロードマップがあれば、知財担当者の立場からすると、実績が可視化されるため知財活動を推進していく上での達成感もありますし、逆に知財担当者を評価する立場からしても、明確な評価基準がない中で、知財担当者の評価をする際に役に立ちます。 以上のように、何もないところから他部門と関わりながら知財活動計画を立案し、ロードマップを達成していくのは、知財部門を立ち上げるという業務の面白さの１つでもあります。 初期段階から長期視点で知財素人でも回せる業務運用作りをする 1 人法務や 1 人知財担当という状況は、遅かれ早かれ属人化という問題が必ずやってきます。 属人化は組織運営上、健全ではありません。 そのため、 知財に関する知識がない人間でも、誰でもその業務を回すことができるような状態をつくる ために、知財部門立ち上げの初期段階から、自分が担当している業務でルーチン化できるものは全て仕組み化してドキュメントに落とし込むようにしていました。 例えば「怪しい特許を見つけた場合の動き方」、「発明報奨金の決定プロセス」、「他社特許調査及び発明発掘のハイブリッド調査の進め方」などなど、ありとあらゆるプロセス業務を全てフロー図や概念図を作成し、誰か見てもわかる業務ということに留意しています。 現状はまだ引き継ぎや新たな知財部員の登用という話がないので、わかりやすい効果を発揮しているわけではないのですが、他部門からの問い合わせがあった際は資料だけ渡せば理解してもらえるので、コミュニケーションの効率化には貢献していると思います。 どのような特許を取得すべきなのか 企業としてどのような特許を取得していくべきか、ということは「知財を最大限に活用する」という知財の出口から考えていく上で、重要な事項になります。 そしてどのような特許を取得するかは、事業領域や事業ミッションに沿って設定されるべきです。 メドレーは、オープンプラットフォームによる医療のあり方の変革を目指している企業なので、開発チームから上がってきたアイデアについては、 プラットフォーム事業を適切に運営していく上で必要な技術かどうか 、という観点で特許化するかどうかを判断しています。 例えば、最近特許を取得した**医療データの管理方法（ 特許第 6921177 号 ）**というものがあります。これは、アプリ端末から入力された患者データと、医療機関の各業務システムから入力された患者データという 2 つの類似したデータをシームレスに管理するために、両方のデータを 2 つのデータベース上で統合管理することにより、データ管理の責任分担の明確化及び厳格な情報管理を可能にするというものです。 仕組みとしてはとてもシンプルなのですが、 患者の持つ端末と、医科・歯科・調剤等の各業務システムをシームレスに連携させる仕組みが、医療プラットフォームを適切に運営していく上で必要な技術だと判断 したため、特許化しました。 また、上記事例のように実際にプロダクトに実装されている技術を特許化したものだけでなく、実際にプロダクトに実装するかわからないけれども将来を見据えた先見的な特許として、**ブロックチェーンを用いた電子処方箋の管理方法（ 特許第 6936763 号 ）**という特許を取得しています。 これは、ブロックチェーンを用いたアクセス権の管理機能として全体的に秘密状態を保ちながら電子処方箋を管理するためのアクセス制御に関する仕組みで、ブロックチェーンデータベース上において処方箋データと患者データとを紐づけて、医師端末からの患者レコードへの一時的なアクセス権限を付与し、会計終了時に患者端末の操作に応じて医師端末へのアクセス権限を剥奪するというものです。 このような特許を取得した背景には、 マーケットを独占して権利主張をするためというよりも、メドレーが考える未来のプロダクトビジョンであったり、開発部門の先見的な創作活動を対外的に発信したい 、という思いがあります。 メドレーは、顧客利用率の高いプロダクト、機能拡張性の高いプロダクトの開発を推進しているため、**独創的で最新技術を取り入れた尖った機能を目指すというよりはユーザにとって使いやすいシンプルさが多く取り入れられています。**また、それだけではなく、前述したブロックチェーンと電子処方箋との組み合わせ技術の先見的な特許取得のように、10 年先を見据えた未来のプロダクトのあり方についても日々追求しています。 特許を身近に感じてもらうためのユニークな話も取り入れて社内に啓蒙する いい特許を生み出すためには地道な社内の啓蒙活動も重要です。 メドレーでは、開発チーム間の技術格差の是正や、技術情報の共有による活性化を目的として、エンジニアが日々の業務で扱っている技術や取り組みについて共有するテックランチという勉強会が定期的に開催されています。 先日そのテックランチで、社内のエンジニアの方達に少しでも特許を身近に感じてもらおうと、「特許の頭体操」というコーナーを設けて、実際に頭を使って体験してもらいました。 下の例では、おたまとスプーンとの違いを考えようというお題を通して、ある物の特徴を把握する際に、 「違い」から「もの」を観察すると、その物の特徴が浮き出てくる 、というメッセージが含まれています。 おたまもスプーンも対象物をすくい上げるという機能においては共通しているのですが、おたまの先端のお皿部分とスプーンの先端のお皿部分とは、その形状が異なります。スプーンのお皿部分は楕円形ですが、おたまのお皿部分は円形になっています。 つまり、おたまの特徴は、特許的にいうと「その先端にあるお皿部分が円形の開口を有した半球状で、対象物をすくうための所定の深さを有している」ということになります。 この辺はちょっと固苦しい表現が続いたせいもあり、「難しい…」というコメントをもらいました。馴染みのない人にとってはただただ面倒な作業だと思います。 しかし、ここで言いたかったのは、 これはあくまで構造物についての話であって、ソフトウェアの特徴を把握するということはそんなに難しいことではないのだよ 、ということでした。 ソフトウェアの場合は、ちょっとした機能を追加すれば、それが従来のソフトとは異なるものとなり、比較的簡単に特許になってしまうケースが少なくありません。 つまり、エンジニアの方は日々新しい機能を実装すべく開発業務を行っているわけなので、 知財の観点から言うと、極端なことを言えば日々発明をしている ということになります。当然特許になるかどうかは別の話になりますが、日々の開発業務で自分が発明をしていることに気づいていない、という状況が多分にあるということです。 さらに、 知財担当がこれに気づかなければ、日の目を見ることない埋蔵知財が量産される ということになってしまいます。 では、どのようにしてエンジニアの方が自ら発明をしていることに気づいていないものを発掘し、社内の知的財産として認定していくのか、というのが次の話になります。 面白いアイデアは雑談から生まれる 日々の開発業務の延長で生まれてくる機能や技術を特許化するという活動が基本であることは間違いないのですが、実際にプロダクトに実装するかどうか不確定要素を多く含むアイデアを特許化するという活動は、エンジニアの開発成果物を知的財産として見える化することで、エンジニアの成果が報われる土壌を作るという意味においては大切な活動になってきます。 ただ、どの企業知財部でも発明発掘業務はされていると思いますし、「アイデアは雑談から生まれる」ということは既に周知の事実かもしれません。また、知財活動として特段新しいことをしているわけではないのですが、実際にそれを実行する際の心構えであったり、具体的に気をつけていることについて、事例を通してご紹介したいと思います。 私は、 エンジニアの方というのは、アイデアの卵をもっている という前提に立ってエンジニアの方とコミュニケーションをとるようにしています。 そうすると、「実はアイデアありますよね、なんで言ってくれないんですか〜。」という具合にカジュアルな会話をスタートすることができ、スムーズにブレストを進めることができたりします。大したことではないのですが、 意外とこういう心がけが円滑なコミュニケーションを生み出すきっかけになっている かもしれません。 一方で、エンジニアの方は暇ではありません。 日々の開発では、既存機能の修正や新規機能の開発などの案件に追われるため、頭の中にあるアイデアの卵も埋もれてしまいがちです。 以上のことを踏まえ、エンジニアからアイデアを出してもらうためのブレスト MTG では主に以下の点に気をつけています。 エンジニアの方の負担にならないように短時間に設定すること（長くて 30 分） カジュアルに話しやすい雑談ベースの雰囲気にすること そのために少人数で行うこと 出てきたアイデアを楽しむこと 実際に下図に示すような雑談ベースの会話から、「診療方式を患者と医療機関との間の距離に応じて、対面診療かオンライン診療かを自動的に切り替える」というアイデアが生まれ、実際に特許出願につながりました。 この時にエンジニアの方々からは「とても面白い！」とか「またやりたい！」という前向きなコメントをもらえて、カジュアルベースの雑談効果を実感しました。 このようなブレストを通して一番大きな気づきというのは、エンジニアの皆さん、本当によくプロダクトについて考えているということ。 エンジニアの方々の創意工夫が全て知的財産「権」になるわけではないのですが、知的財産であることには違いありません。 これからは、そういった エンジニアの方の頭の中に埋もれがちな創意・工夫というものが報われるような土壌作りを、知的財産というツールを使って構築していきたい と考えています。 このブログも「特許を対外的にどう見せるか」という実験の１つ ここまでご紹介してきた内容は、知財計画を立てて、立てた計画に沿って知財業務を運用し、運用していく中でアイデア発掘して知財化する、という話にとどまってましたが、実際に取得した知財権をどのように活用して企業価値の向上につなげるのか、ということがこれからの知財部門にとっての重要なミッションになると考えています。 従来は、特許権の独占排他権という性質を使って参入障壁として活用したり、模倣の抑止に活用されるのが常識だったと思いますが、メドレーではこれまでにない新たな活用方法を模索しています。 実はこのブログもそうなのですが、特許を対外的にどうみせるか、ということの１つの実験です。 どういうことかというと、ここまでご紹介してきた 知財活動自体も人の知的活動によって生み出された知的財産であり、このようにブログで発信しなければ単なる埋蔵知財になってしまいます 。 例えば、特許取得についてもただ特許を取ったという事実を公表するのではなく、どうしてそのような特許を取得してどのように活用しているのか、またそこに関連したメンバーは誰でどのような検討があったのか、というストーリーメイキングをすると、特許というものを中心とした１つのドラマが浮き上がってきます。 今回は知財活動のご紹介という趣旨で、特許を中心とした内容になっているため、特許に関心がない人にはあまりささらないコンテンツになっているかもしれませんが、例えば特許と広報との掛け算でストーリーメイキングをすれば 特許に関心がある人だけでなく、広報に関心がある人にも情報がリーチすることになります 。 これは 特許というものが、人材・業務ノウハウ・広報・採用活動等と同列に知的財産である がゆえになせるものです。これからは、知的財産＝特許、商標という視点ではなく、知財＝目に見えない創造的な活動という捉え方をした上で、企業価値に貢献していく必要があります。 知財部門が、採用、IR、広報、開発、社内 IT といった企業内にある多数の部門とコラボレーションすることでこれまで見たことのない新しい知財活用の形を模索し、 知財を最大活用することによって企業価値を向上させていきたい と考えています。 さいごに ここまで、知財活動の一部をご紹介させていただきましたが、これが知財活動の進め方として正解というわけではなく、企業風土や事業領域によって、知財活動のあり方は異なります。そして、そこを考えながら知財活動を推進していくことが仕事の面白さであり醍醐味とも言えます。新しい知財部のあり方や、新しい知的財産の活用方法を検証しながらも、建設的かつ柔軟に日々の業務を進め、メドレーの事業をしっかりとバックアップしていきたいと考えています。少しでも当社の知財活動が参考になれば幸いです。最後までお付き合い頂きありがとうございました！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは、メドレーのコーポレート本部法務コンプライアンス部で、知的財産関連の業務を担当している鬼鞍です。 1 年ほど前に本ブログで「 特許とはなにか 」というテーマで当社における特許啓蒙活動を紹介させて頂いたのですが、思っていた以上に反響があり、「面白い」とか「わかりやすい」という嬉しいコメントも頂戴しました。 私がメドレーに入社して最初のミッションが知財部門の立ち上げだったので、次はぜひ**「ベンチャーでの知財部門の立ち上げ方」**的なテーマでブログ発信したいと思っていたのですが、当初はまだ具体的な社内事例が少なかったため、実績ができた段階で改めて本ブログで発表したいと思っていました。 それから１年以上が経過して実際に特許も取得するなど知財活動としての実績が蓄積されてきたため、これを機会に ベンチャーで知財部門を立ち上げる際にやるべきことについて、実例に触れながら具体的にまとめてみました。 かなり長いコンテンツになってしまいましたが、 フェーズごとの知財活動計画 であったり、 知財ロードマップの作り方 など、 なかなか表に出てこない知財部門立ち上げストーリーの具体的事例を惜しみなく書かせていただいております ので、ぜひご一読いただき、お役に立てれば幸いです。 知財は開発チームとの信頼関係の構築がまず第一 先ほどは知財部門を立ち上げストーリの中で、知財活動計画とか、知財ロードマップであるとか少し格好つけたような文字が羅列していましたが、実は私が知財専任として初めに配置されて最初にやったことはそんな大それたことではありませんでした。 最初になにをやったかというと、 エンジニアの方とランチに行く、あるいは飲みに行く 、ということでした。当時はまだ Covid-19 が蔓延する前だったので気軽にそういうことができました。入社して最初の 1 ヶ月くらいは週 2 回くらいのペースで誰かとランチか飲みにいくということをしていたと思います。 飲みに行く、というとふざけているとか思われるかもしれませんが、知財部門の立ち上げストーリーを語る上で、このプロセスは無視できないほど重要だと考えています。先に断っておくと私は酒好きでもなければ、家でも一切飲みません。 当たり前のことなのですが、知財というのはプロダクトを生み出す開発組織があって初めて価値を発揮するものです。知財はあくまで事業や開発をサポートするところであって、それ単体で存在意義を発揮することはほぼありません。特に特許活動については開発チームとの連携が非常に重要です。 一緒にご飯を食べることが信頼関係を構築する上で最良の方法、とまでは言いませんが、少なくともご飯を食べない人はいないわけで、時間を無駄にしている感もなければ、オフィスの外で会えば仕事以外のことを話題にし易いので互いの趣味嗜好を知ることができます。みなさんもそうだと思いますが、通常、仲の悪い人とは一緒に食事はしないと思います。 特に、この後にもご紹介する 社内のアイデアを発掘するという発明発掘活動は、話しやすいカジュアルな雰囲気で雑談のような感じでブレストするというのが非常に重要 で、このときに相手がどんな人間かを互いに知っているか、知らないかでは大きな差がでてきます。 また更に、この後にご紹介する知財計画立案や知財ロードマップを作成することも当然重要なのですが、結局仕事というのは人と人との間を思考がやりとりされて実現化されていくものなので、人間関係・信頼関係が全ての基礎であり、実は一番大切にするべきものだと思います。 これは何も知財に限ったことではなく、部門を跨いで仕事をする上で信頼関係は非常に重要ですし、知財の観点で見ても 円滑なコミュニケーションが結果的にいい発明やアイデアを生み出すための土壌づくりに貢献する ものだと考えています。 知財活動計画は、事業の成長フェーズに合わせて設定する 知財部門の設立にあたって、エンジニアとのコミュニケーションと並行して進めたのが、知財活動計画の立案でした。知財活動とは、知財サイクルをうまく事業サイクルにインストールしてサイクルを循環させることであり、更にはこのサイクルが循環するための運用基盤を構築することを指します。また、ここでいう知財サイクルとは、例えば、社内に埋もれたアイデアを発掘し（創発）→ それを知財権化し（保護）→ 権利化した知財を活用し（活用）→ 活用した知財で得られた利益や結果を創発支援に適用できる形に変換する、というものです。 このような知財サイクルを、何の計画や戦略もなしに事業サイクルへインストールしようとするとうまくいきません。なぜなら、事業というのは日々成長し変化していくもので、 事業の成長に応じて知財活動の目的や課題も変化するからです 。 例えば、子会社が増えて事業規模が拡大すると、その子会社の事業領域で既に多くの特許出願がされている場合には、発明発掘活動よりもまずは法的リスクを回避することを最優先にして、他社の特許調査をしっかりやってからプロダクトをリリースする仕組みを作ろう、ということになります。あるいは、事業の成長に伴いプロダクトが成熟してきた場面では、似たようなプロダクトが乱立する結果、尖った機能や最先端技術で差別化をするようになるため、こうした場合には先行した特許取得が重要な目的になってきます。 このように、事業の成長フェーズに応じた知財活動の計画を立案するべく、まずはメドレーのミッションおよびそのミッションを実現するためのプロダクトの性質を把握する必要がありました。 メドレーは「医療ヘルスケアの未来をつくる」というミッションを掲げ、インターネットテクノロジーによる医療のあり方の変革を目指す企業です。 このミッションと向き合いつつ、 事業プラットフォームの成長フェーズごとに知財活動の方向性・目的を３段階にわけて設定し、成長フェーズごとに知財活動計画を立案しました 。 例えば、プラットフォームの創設期においては新規ユーザ獲得が重要となり、使い勝手のいいシンプルな機能に開発の方向性が向いているため、独自性のある技術を特許化するというよりも、まずは守りを固めるべく知財権侵害のリスクを最小限にして法的安定性の確保に軸足を置いた知財活動を推進します。 このような計画は、知財の観点で一方的にできるものではありません。 知財活動の計画に際しては、開発チームを統括するマネージャにプロダクト開発の方向性をヒアリングして特許取得の判断基準を検討したり、経営層に将来の事業の方向性についてヒアリングをして長期志向で目標設定したりして、ブラッシュアップしていきました。 そういった検討や議論を重ねていくうちに自然と、その企業風土や事業ミッションにあった知財活動計画というものができあがってくるのだと思います。 知財活動ロードマップで現在位置を把握しつつ定期的に軌道修正する 長期的な方向性を可視化したら次はそれをどう実行するかという実行計画が必要になってきました。 そもそも自分たちは今何ができていて、何ができていないのか。またどのようなことを今後やっていかなければならないのかが不明確だよね、という話になり、それを具体的に俯瞰するための知財ロードマッピングというものを作成しました。 縦軸に知的財産の種類、横軸に時間軸であるフェーズを設定して、知財活動の内容に過不足ないかをチェックできるようにしました。 定期的に内容を見直してメドレーの事業規模にあった形に修正しながら自分達の現在位置を把握し、今後の方向性を見定めるためのツールとして有効でした。 このようなロードマップがあれば、知財担当者の立場からすると、実績が可視化されるため知財活動を推進していく上での達成感もありますし、逆に知財担当者を評価する立場からしても、明確な評価基準がない中で、知財担当者の評価をする際に役に立ちます。 以上のように、何もないところから他部門と関わりながら知財活動計画を立案し、ロードマップを達成していくのは、知財部門を立ち上げるという業務の面白さの１つでもあります。 初期段階から長期視点で知財素人でも回せる業務運用作りをする 1 人法務や 1 人知財担当という状況は、遅かれ早かれ属人化という問題が必ずやってきます。 属人化は組織運営上、健全ではありません。 そのため、 知財に関する知識がない人間でも、誰でもその業務を回すことができるような状態をつくる ために、知財部門立ち上げの初期段階から、自分が担当している業務でルーチン化できるものは全て仕組み化してドキュメントに落とし込むようにしていました。 例えば「怪しい特許を見つけた場合の動き方」、「発明報奨金の決定プロセス」、「他社特許調査及び発明発掘のハイブリッド調査の進め方」などなど、ありとあらゆるプロセス業務を全てフロー図や概念図を作成し、誰か見てもわかる業務ということに留意しています。 現状はまだ引き継ぎや新たな知財部員の登用という話がないので、わかりやすい効果を発揮しているわけではないのですが、他部門からの問い合わせがあった際は資料だけ渡せば理解してもらえるので、コミュニケーションの効率化には貢献していると思います。 どのような特許を取得すべきなのか 企業としてどのような特許を取得していくべきか、ということは「知財を最大限に活用する」という知財の出口から考えていく上で、重要な事項になります。 そしてどのような特許を取得するかは、事業領域や事業ミッションに沿って設定されるべきです。 メドレーは、オープンプラットフォームによる医療のあり方の変革を目指している企業なので、開発チームから上がってきたアイデアについては、 プラットフォーム事業を適切に運営していく上で必要な技術かどうか 、という観点で特許化するかどうかを判断しています。 例えば、最近特許を取得した**医療データの管理方法（ 特許第 6921177 号 ）**というものがあります。これは、アプリ端末から入力された患者データと、医療機関の各業務システムから入力された患者データという 2 つの類似したデータをシームレスに管理するために、両方のデータを 2 つのデータベース上で統合管理することにより、データ管理の責任分担の明確化及び厳格な情報管理を可能にするというものです。 仕組みとしてはとてもシンプルなのですが、 患者の持つ端末と、医科・歯科・調剤等の各業務システムをシームレスに連携させる仕組みが、医療プラットフォームを適切に運営していく上で必要な技術だと判断 したため、特許化しました。 また、上記事例のように実際にプロダクトに実装されている技術を特許化したものだけでなく、実際にプロダクトに実装するかわからないけれども将来を見据えた先見的な特許として、**ブロックチェーンを用いた電子処方箋の管理方法（ 特許第 6936763 号 ）**という特許を取得しています。 これは、ブロックチェーンを用いたアクセス権の管理機能として全体的に秘密状態を保ちながら電子処方箋を管理するためのアクセス制御に関する仕組みで、ブロックチェーンデータベース上において処方箋データと患者データとを紐づけて、医師端末からの患者レコードへの一時的なアクセス権限を付与し、会計終了時に患者端末の操作に応じて医師端末へのアクセス権限を剥奪するというものです。 このような特許を取得した背景には、 マーケットを独占して権利主張をするためというよりも、メドレーが考える未来のプロダクトビジョンであったり、開発部門の先見的な創作活動を対外的に発信したい 、という思いがあります。 メドレーは、顧客利用率の高いプロダクト、機能拡張性の高いプロダクトの開発を推進しているため、**独創的で最新技術を取り入れた尖った機能を目指すというよりはユーザにとって使いやすいシンプルさが多く取り入れられています。**また、それだけではなく、前述したブロックチェーンと電子処方箋との組み合わせ技術の先見的な特許取得のように、10 年先を見据えた未来のプロダクトのあり方についても日々追求しています。 特許を身近に感じてもらうためのユニークな話も取り入れて社内に啓蒙する いい特許を生み出すためには地道な社内の啓蒙活動も重要です。 メドレーでは、開発チーム間の技術格差の是正や、技術情報の共有による活性化を目的として、エンジニアが日々の業務で扱っている技術や取り組みについて共有するテックランチという勉強会が定期的に開催されています。 先日そのテックランチで、社内のエンジニアの方達に少しでも特許を身近に感じてもらおうと、「特許の頭体操」というコーナーを設けて、実際に頭を使って体験してもらいました。 下の例では、おたまとスプーンとの違いを考えようというお題を通して、ある物の特徴を把握する際に、 「違い」から「もの」を観察すると、その物の特徴が浮き出てくる 、というメッセージが含まれています。 おたまもスプーンも対象物をすくい上げるという機能においては共通しているのですが、おたまの先端のお皿部分とスプーンの先端のお皿部分とは、その形状が異なります。スプーンのお皿部分は楕円形ですが、おたまのお皿部分は円形になっています。 つまり、おたまの特徴は、特許的にいうと「その先端にあるお皿部分が円形の開口を有した半球状で、対象物をすくうための所定の深さを有している」ということになります。 この辺はちょっと固苦しい表現が続いたせいもあり、「難しい…」というコメントをもらいました。馴染みのない人にとってはただただ面倒な作業だと思います。 しかし、ここで言いたかったのは、 これはあくまで構造物についての話であって、ソフトウェアの特徴を把握するということはそんなに難しいことではないのだよ 、ということでした。 ソフトウェアの場合は、ちょっとした機能を追加すれば、それが従来のソフトとは異なるものとなり、比較的簡単に特許になってしまうケースが少なくありません。 つまり、エンジニアの方は日々新しい機能を実装すべく開発業務を行っているわけなので、 知財の観点から言うと、極端なことを言えば日々発明をしている ということになります。当然特許になるかどうかは別の話になりますが、日々の開発業務で自分が発明をしていることに気づいていない、という状況が多分にあるということです。 さらに、 知財担当がこれに気づかなければ、日の目を見ることない埋蔵知財が量産される ということになってしまいます。 では、どのようにしてエンジニアの方が自ら発明をしていることに気づいていないものを発掘し、社内の知的財産として認定していくのか、というのが次の話になります。 面白いアイデアは雑談から生まれる 日々の開発業務の延長で生まれてくる機能や技術を特許化するという活動が基本であることは間違いないのですが、実際にプロダクトに実装するかどうか不確定要素を多く含むアイデアを特許化するという活動は、エンジニアの開発成果物を知的財産として見える化することで、エンジニアの成果が報われる土壌を作るという意味においては大切な活動になってきます。 ただ、どの企業知財部でも発明発掘業務はされていると思いますし、「アイデアは雑談から生まれる」ということは既に周知の事実かもしれません。また、知財活動として特段新しいことをしているわけではないのですが、実際にそれを実行する際の心構えであったり、具体的に気をつけていることについて、事例を通してご紹介したいと思います。 私は、 エンジニアの方というのは、アイデアの卵をもっている という前提に立ってエンジニアの方とコミュニケーションをとるようにしています。 そうすると、「実はアイデアありますよね、なんで言ってくれないんですか〜。」という具合にカジュアルな会話をスタートすることができ、スムーズにブレストを進めることができたりします。大したことではないのですが、 意外とこういう心がけが円滑なコミュニケーションを生み出すきっかけになっている かもしれません。 一方で、エンジニアの方は暇ではありません。 日々の開発では、既存機能の修正や新規機能の開発などの案件に追われるため、頭の中にあるアイデアの卵も埋もれてしまいがちです。 以上のことを踏まえ、エンジニアからアイデアを出してもらうためのブレスト MTG では主に以下の点に気をつけています。 エンジニアの方の負担にならないように短時間に設定すること（長くて 30 分） カジュアルに話しやすい雑談ベースの雰囲気にすること そのために少人数で行うこと 出てきたアイデアを楽しむこと 実際に下図に示すような雑談ベースの会話から、「診療方式を患者と医療機関との間の距離に応じて、対面診療かオンライン診療かを自動的に切り替える」というアイデアが生まれ、実際に特許出願につながりました。 この時にエンジニアの方々からは「とても面白い！」とか「またやりたい！」という前向きなコメントをもらえて、カジュアルベースの雑談効果を実感しました。 このようなブレストを通して一番大きな気づきというのは、エンジニアの皆さん、本当によくプロダクトについて考えているということ。 エンジニアの方々の創意工夫が全て知的財産「権」になるわけではないのですが、知的財産であることには違いありません。 これからは、そういった エンジニアの方の頭の中に埋もれがちな創意・工夫というものが報われるような土壌作りを、知的財産というツールを使って構築していきたい と考えています。 このブログも「特許を対外的にどう見せるか」という実験の１つ ここまでご紹介してきた内容は、知財計画を立てて、立てた計画に沿って知財業務を運用し、運用していく中でアイデア発掘して知財化する、という話にとどまってましたが、実際に取得した知財権をどのように活用して企業価値の向上につなげるのか、ということがこれからの知財部門にとっての重要なミッションになると考えています。 従来は、特許権の独占排他権という性質を使って参入障壁として活用したり、模倣の抑止に活用されるのが常識だったと思いますが、メドレーではこれまでにない新たな活用方法を模索しています。 実はこのブログもそうなのですが、特許を対外的にどうみせるか、ということの１つの実験です。 どういうことかというと、ここまでご紹介してきた 知財活動自体も人の知的活動によって生み出された知的財産であり、このようにブログで発信しなければ単なる埋蔵知財になってしまいます 。 例えば、特許取得についてもただ特許を取ったという事実を公表するのではなく、どうしてそのような特許を取得してどのように活用しているのか、またそこに関連したメンバーは誰でどのような検討があったのか、というストーリーメイキングをすると、特許というものを中心とした１つのドラマが浮き上がってきます。 今回は知財活動のご紹介という趣旨で、特許を中心とした内容になっているため、特許に関心がない人にはあまりささらないコンテンツになっているかもしれませんが、例えば特許と広報との掛け算でストーリーメイキングをすれば 特許に関心がある人だけでなく、広報に関心がある人にも情報がリーチすることになります 。 これは 特許というものが、人材・業務ノウハウ・広報・採用活動等と同列に知的財産である がゆえになせるものです。これからは、知的財産＝特許、商標という視点ではなく、知財＝目に見えない創造的な活動という捉え方をした上で、企業価値に貢献していく必要があります。 知財部門が、採用、IR、広報、開発、社内 IT といった企業内にある多数の部門とコラボレーションすることでこれまで見たことのない新しい知財活用の形を模索し、 知財を最大活用することによって企業価値を向上させていきたい と考えています。 さいごに ここまで、知財活動の一部をご紹介させていただきましたが、これが知財活動の進め方として正解というわけではなく、企業風土や事業領域によって、知財活動のあり方は異なります。そして、そこを考えながら知財活動を推進していくことが仕事の面白さであり醍醐味とも言えます。新しい知財部のあり方や、新しい知的財産の活用方法を検証しながらも、建設的かつ柔軟に日々の業務を進め、メドレーの事業をしっかりとバックアップしていきたいと考えています。少しでも当社の知財活動が参考になれば幸いです。最後までお付き合い頂きありがとうございました！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは、メドレーのコーポレート本部法務コンプライアンス部で、知的財産関連の業務を担当している鬼鞍です。 1 年ほど前に本ブログで「 特許とはなにか 」というテーマで当社における特許啓蒙活動を紹介させて頂いたのですが、思っていた以上に反響があり、「面白い」とか「わかりやすい」という嬉しいコメントも頂戴しました。 私がメドレーに入社して最初のミッションが知財部門の立ち上げだったので、次はぜひ**「ベンチャーでの知財部門の立ち上げ方」**的なテーマでブログ発信したいと思っていたのですが、当初はまだ具体的な社内事例が少なかったため、実績ができた段階で改めて本ブログで発表したいと思っていました。 それから１年以上が経過して実際に特許も取得するなど知財活動としての実績が蓄積されてきたため、これを機会に ベンチャーで知財部門を立ち上げる際にやるべきことについて、実例に触れながら具体的にまとめてみました。 かなり長いコンテンツになってしまいましたが、 フェーズごとの知財活動計画 であったり、 知財ロードマップの作り方 など、 なかなか表に出てこない知財部門立ち上げストーリーの具体的事例を惜しみなく書かせていただいております ので、ぜひご一読いただき、お役に立てれば幸いです。 知財は開発チームとの信頼関係の構築がまず第一 先ほどは知財部門を立ち上げストーリの中で、知財活動計画とか、知財ロードマップであるとか少し格好つけたような文字が羅列していましたが、実は私が知財専任として初めに配置されて最初にやったことはそんな大それたことではありませんでした。 最初になにをやったかというと、 エンジニアの方とランチに行く、あるいは飲みに行く 、ということでした。当時はまだ Covid-19 が蔓延する前だったので気軽にそういうことができました。入社して最初の 1 ヶ月くらいは週 2 回くらいのペースで誰かとランチか飲みにいくということをしていたと思います。 飲みに行く、というとふざけているとか思われるかもしれませんが、知財部門の立ち上げストーリーを語る上で、このプロセスは無視できないほど重要だと考えています。先に断っておくと私は酒好きでもなければ、家でも一切飲みません。 当たり前のことなのですが、知財というのはプロダクトを生み出す開発組織があって初めて価値を発揮するものです。知財はあくまで事業や開発をサポートするところであって、それ単体で存在意義を発揮することはほぼありません。特に特許活動については開発チームとの連携が非常に重要です。 一緒にご飯を食べることが信頼関係を構築する上で最良の方法、とまでは言いませんが、少なくともご飯を食べない人はいないわけで、時間を無駄にしている感もなければ、オフィスの外で会えば仕事以外のことを話題にし易いので互いの趣味嗜好を知ることができます。みなさんもそうだと思いますが、通常、仲の悪い人とは一緒に食事はしないと思います。 特に、この後にもご紹介する 社内のアイデアを発掘するという発明発掘活動は、話しやすいカジュアルな雰囲気で雑談のような感じでブレストするというのが非常に重要 で、このときに相手がどんな人間かを互いに知っているか、知らないかでは大きな差がでてきます。 また更に、この後にご紹介する知財計画立案や知財ロードマップを作成することも当然重要なのですが、結局仕事というのは人と人との間を思考がやりとりされて実現化されていくものなので、人間関係・信頼関係が全ての基礎であり、実は一番大切にするべきものだと思います。 これは何も知財に限ったことではなく、部門を跨いで仕事をする上で信頼関係は非常に重要ですし、知財の観点で見ても 円滑なコミュニケーションが結果的にいい発明やアイデアを生み出すための土壌づくりに貢献する ものだと考えています。 知財活動計画は、事業の成長フェーズに合わせて設定する 知財部門の設立にあたって、エンジニアとのコミュニケーションと並行して進めたのが、知財活動計画の立案でした。知財活動とは、知財サイクルをうまく事業サイクルにインストールしてサイクルを循環させることであり、更にはこのサイクルが循環するための運用基盤を構築することを指します。また、ここでいう知財サイクルとは、例えば、社内に埋もれたアイデアを発掘し（創発）→ それを知財権化し（保護）→ 権利化した知財を活用し（活用）→ 活用した知財で得られた利益や結果を創発支援に適用できる形に変換する、というものです。 このような知財サイクルを、何の計画や戦略もなしに事業サイクルへインストールしようとするとうまくいきません。なぜなら、事業というのは日々成長し変化していくもので、 事業の成長に応じて知財活動の目的や課題も変化するからです 。 例えば、子会社が増えて事業規模が拡大すると、その子会社の事業領域で既に多くの特許出願がされている場合には、発明発掘活動よりもまずは法的リスクを回避することを最優先にして、他社の特許調査をしっかりやってからプロダクトをリリースする仕組みを作ろう、ということになります。あるいは、事業の成長に伴いプロダクトが成熟してきた場面では、似たようなプロダクトが乱立する結果、尖った機能や最先端技術で差別化をするようになるため、こうした場合には先行した特許取得が重要な目的になってきます。 このように、事業の成長フェーズに応じた知財活動の計画を立案するべく、まずはメドレーのミッションおよびそのミッションを実現するためのプロダクトの性質を把握する必要がありました。 メドレーは「医療ヘルスケアの未来をつくる」というミッションを掲げ、インターネットテクノロジーによる医療のあり方の変革を目指す企業です。 このミッションと向き合いつつ、 事業プラットフォームの成長フェーズごとに知財活動の方向性・目的を３段階にわけて設定し、成長フェーズごとに知財活動計画を立案しました 。 例えば、プラットフォームの創設期においては新規ユーザ獲得が重要となり、使い勝手のいいシンプルな機能に開発の方向性が向いているため、独自性のある技術を特許化するというよりも、まずは守りを固めるべく知財権侵害のリスクを最小限にして法的安定性の確保に軸足を置いた知財活動を推進します。 このような計画は、知財の観点で一方的にできるものではありません。 知財活動の計画に際しては、開発チームを統括するマネージャにプロダクト開発の方向性をヒアリングして特許取得の判断基準を検討したり、経営層に将来の事業の方向性についてヒアリングをして長期志向で目標設定したりして、ブラッシュアップしていきました。 そういった検討や議論を重ねていくうちに自然と、その企業風土や事業ミッションにあった知財活動計画というものができあがってくるのだと思います。 知財活動ロードマップで現在位置を把握しつつ定期的に軌道修正する 長期的な方向性を可視化したら次はそれをどう実行するかという実行計画が必要になってきました。 そもそも自分たちは今何ができていて、何ができていないのか。またどのようなことを今後やっていかなければならないのかが不明確だよね、という話になり、それを具体的に俯瞰するための知財ロードマッピングというものを作成しました。 縦軸に知的財産の種類、横軸に時間軸であるフェーズを設定して、知財活動の内容に過不足ないかをチェックできるようにしました。 定期的に内容を見直してメドレーの事業規模にあった形に修正しながら自分達の現在位置を把握し、今後の方向性を見定めるためのツールとして有効でした。 このようなロードマップがあれば、知財担当者の立場からすると、実績が可視化されるため知財活動を推進していく上での達成感もありますし、逆に知財担当者を評価する立場からしても、明確な評価基準がない中で、知財担当者の評価をする際に役に立ちます。 以上のように、何もないところから他部門と関わりながら知財活動計画を立案し、ロードマップを達成していくのは、知財部門を立ち上げるという業務の面白さの１つでもあります。 初期段階から長期視点で知財素人でも回せる業務運用作りをする 1 人法務や 1 人知財担当という状況は、遅かれ早かれ属人化という問題が必ずやってきます。 属人化は組織運営上、健全ではありません。 そのため、 知財に関する知識がない人間でも、誰でもその業務を回すことができるような状態をつくる ために、知財部門立ち上げの初期段階から、自分が担当している業務でルーチン化できるものは全て仕組み化してドキュメントに落とし込むようにしていました。 例えば「怪しい特許を見つけた場合の動き方」、「発明報奨金の決定プロセス」、「他社特許調査及び発明発掘のハイブリッド調査の進め方」などなど、ありとあらゆるプロセス業務を全てフロー図や概念図を作成し、誰か見てもわかる業務ということに留意しています。 現状はまだ引き継ぎや新たな知財部員の登用という話がないので、わかりやすい効果を発揮しているわけではないのですが、他部門からの問い合わせがあった際は資料だけ渡せば理解してもらえるので、コミュニケーションの効率化には貢献していると思います。 どのような特許を取得すべきなのか 企業としてどのような特許を取得していくべきか、ということは「知財を最大限に活用する」という知財の出口から考えていく上で、重要な事項になります。 そしてどのような特許を取得するかは、事業領域や事業ミッションに沿って設定されるべきです。 メドレーは、オープンプラットフォームによる医療のあり方の変革を目指している企業なので、開発チームから上がってきたアイデアについては、 プラットフォーム事業を適切に運営していく上で必要な技術かどうか 、という観点で特許化するかどうかを判断しています。 例えば、最近特許を取得した**医療データの管理方法（ 特許第 6921177 号 ）**というものがあります。これは、アプリ端末から入力された患者データと、医療機関の各業務システムから入力された患者データという 2 つの類似したデータをシームレスに管理するために、両方のデータを 2 つのデータベース上で統合管理することにより、データ管理の責任分担の明確化及び厳格な情報管理を可能にするというものです。 仕組みとしてはとてもシンプルなのですが、 患者の持つ端末と、医科・歯科・調剤等の各業務システムをシームレスに連携させる仕組みが、医療プラットフォームを適切に運営していく上で必要な技術だと判断 したため、特許化しました。 また、上記事例のように実際にプロダクトに実装されている技術を特許化したものだけでなく、実際にプロダクトに実装するかわからないけれども将来を見据えた先見的な特許として、**ブロックチェーンを用いた電子処方箋の管理方法（ 特許第 6936763 号 ）**という特許を取得しています。 これは、ブロックチェーンを用いたアクセス権の管理機能として全体的に秘密状態を保ちながら電子処方箋を管理するためのアクセス制御に関する仕組みで、ブロックチェーンデータベース上において処方箋データと患者データとを紐づけて、医師端末からの患者レコードへの一時的なアクセス権限を付与し、会計終了時に患者端末の操作に応じて医師端末へのアクセス権限を剥奪するというものです。 このような特許を取得した背景には、 マーケットを独占して権利主張をするためというよりも、メドレーが考える未来のプロダクトビジョンであったり、開発部門の先見的な創作活動を対外的に発信したい 、という思いがあります。 メドレーは、顧客利用率の高いプロダクト、機能拡張性の高いプロダクトの開発を推進しているため、**独創的で最新技術を取り入れた尖った機能を目指すというよりはユーザにとって使いやすいシンプルさが多く取り入れられています。**また、それだけではなく、前述したブロックチェーンと電子処方箋との組み合わせ技術の先見的な特許取得のように、10 年先を見据えた未来のプロダクトのあり方についても日々追求しています。 特許を身近に感じてもらうためのユニークな話も取り入れて社内に啓蒙する いい特許を生み出すためには地道な社内の啓蒙活動も重要です。 メドレーでは、開発チーム間の技術格差の是正や、技術情報の共有による活性化を目的として、エンジニアが日々の業務で扱っている技術や取り組みについて共有するテックランチという勉強会が定期的に開催されています。 先日そのテックランチで、社内のエンジニアの方達に少しでも特許を身近に感じてもらおうと、「特許の頭体操」というコーナーを設けて、実際に頭を使って体験してもらいました。 下の例では、おたまとスプーンとの違いを考えようというお題を通して、ある物の特徴を把握する際に、 「違い」から「もの」を観察すると、その物の特徴が浮き出てくる 、というメッセージが含まれています。 おたまもスプーンも対象物をすくい上げるという機能においては共通しているのですが、おたまの先端のお皿部分とスプーンの先端のお皿部分とは、その形状が異なります。スプーンのお皿部分は楕円形ですが、おたまのお皿部分は円形になっています。 つまり、おたまの特徴は、特許的にいうと「その先端にあるお皿部分が円形の開口を有した半球状で、対象物をすくうための所定の深さを有している」ということになります。 この辺はちょっと固苦しい表現が続いたせいもあり、「難しい…」というコメントをもらいました。馴染みのない人にとってはただただ面倒な作業だと思います。 しかし、ここで言いたかったのは、 これはあくまで構造物についての話であって、ソフトウェアの特徴を把握するということはそんなに難しいことではないのだよ 、ということでした。 ソフトウェアの場合は、ちょっとした機能を追加すれば、それが従来のソフトとは異なるものとなり、比較的簡単に特許になってしまうケースが少なくありません。 つまり、エンジニアの方は日々新しい機能を実装すべく開発業務を行っているわけなので、 知財の観点から言うと、極端なことを言えば日々発明をしている ということになります。当然特許になるかどうかは別の話になりますが、日々の開発業務で自分が発明をしていることに気づいていない、という状況が多分にあるということです。 さらに、 知財担当がこれに気づかなければ、日の目を見ることない埋蔵知財が量産される ということになってしまいます。 では、どのようにしてエンジニアの方が自ら発明をしていることに気づいていないものを発掘し、社内の知的財産として認定していくのか、というのが次の話になります。 面白いアイデアは雑談から生まれる 日々の開発業務の延長で生まれてくる機能や技術を特許化するという活動が基本であることは間違いないのですが、実際にプロダクトに実装するかどうか不確定要素を多く含むアイデアを特許化するという活動は、エンジニアの開発成果物を知的財産として見える化することで、エンジニアの成果が報われる土壌を作るという意味においては大切な活動になってきます。 ただ、どの企業知財部でも発明発掘業務はされていると思いますし、「アイデアは雑談から生まれる」ということは既に周知の事実かもしれません。また、知財活動として特段新しいことをしているわけではないのですが、実際にそれを実行する際の心構えであったり、具体的に気をつけていることについて、事例を通してご紹介したいと思います。 私は、 エンジニアの方というのは、アイデアの卵をもっている という前提に立ってエンジニアの方とコミュニケーションをとるようにしています。 そうすると、「実はアイデアありますよね、なんで言ってくれないんですか〜。」という具合にカジュアルな会話をスタートすることができ、スムーズにブレストを進めることができたりします。大したことではないのですが、 意外とこういう心がけが円滑なコミュニケーションを生み出すきっかけになっている かもしれません。 一方で、エンジニアの方は暇ではありません。 日々の開発では、既存機能の修正や新規機能の開発などの案件に追われるため、頭の中にあるアイデアの卵も埋もれてしまいがちです。 以上のことを踏まえ、エンジニアからアイデアを出してもらうためのブレスト MTG では主に以下の点に気をつけています。 エンジニアの方の負担にならないように短時間に設定すること（長くて 30 分） カジュアルに話しやすい雑談ベースの雰囲気にすること そのために少人数で行うこと 出てきたアイデアを楽しむこと 実際に下図に示すような雑談ベースの会話から、「診療方式を患者と医療機関との間の距離に応じて、対面診療かオンライン診療かを自動的に切り替える」というアイデアが生まれ、実際に特許出願につながりました。 この時にエンジニアの方々からは「とても面白い！」とか「またやりたい！」という前向きなコメントをもらえて、カジュアルベースの雑談効果を実感しました。 このようなブレストを通して一番大きな気づきというのは、エンジニアの皆さん、本当によくプロダクトについて考えているということ。 エンジニアの方々の創意工夫が全て知的財産「権」になるわけではないのですが、知的財産であることには違いありません。 これからは、そういった エンジニアの方の頭の中に埋もれがちな創意・工夫というものが報われるような土壌作りを、知的財産というツールを使って構築していきたい と考えています。 このブログも「特許を対外的にどう見せるか」という実験の１つ ここまでご紹介してきた内容は、知財計画を立てて、立てた計画に沿って知財業務を運用し、運用していく中でアイデア発掘して知財化する、という話にとどまってましたが、実際に取得した知財権をどのように活用して企業価値の向上につなげるのか、ということがこれからの知財部門にとっての重要なミッションになると考えています。 従来は、特許権の独占排他権という性質を使って参入障壁として活用したり、模倣の抑止に活用されるのが常識だったと思いますが、メドレーではこれまでにない新たな活用方法を模索しています。 実はこのブログもそうなのですが、特許を対外的にどうみせるか、ということの１つの実験です。 どういうことかというと、ここまでご紹介してきた 知財活動自体も人の知的活動によって生み出された知的財産であり、このようにブログで発信しなければ単なる埋蔵知財になってしまいます 。 例えば、特許取得についてもただ特許を取ったという事実を公表するのではなく、どうしてそのような特許を取得してどのように活用しているのか、またそこに関連したメンバーは誰でどのような検討があったのか、というストーリーメイキングをすると、特許というものを中心とした１つのドラマが浮き上がってきます。 今回は知財活動のご紹介という趣旨で、特許を中心とした内容になっているため、特許に関心がない人にはあまりささらないコンテンツになっているかもしれませんが、例えば特許と広報との掛け算でストーリーメイキングをすれば 特許に関心がある人だけでなく、広報に関心がある人にも情報がリーチすることになります 。 これは 特許というものが、人材・業務ノウハウ・広報・採用活動等と同列に知的財産である がゆえになせるものです。これからは、知的財産＝特許、商標という視点ではなく、知財＝目に見えない創造的な活動という捉え方をした上で、企業価値に貢献していく必要があります。 知財部門が、採用、IR、広報、開発、社内 IT といった企業内にある多数の部門とコラボレーションすることでこれまで見たことのない新しい知財活用の形を模索し、 知財を最大活用することによって企業価値を向上させていきたい と考えています。 さいごに ここまで、知財活動の一部をご紹介させていただきましたが、これが知財活動の進め方として正解というわけではなく、企業風土や事業領域によって、知財活動のあり方は異なります。そして、そこを考えながら知財活動を推進していくことが仕事の面白さであり醍醐味とも言えます。新しい知財部のあり方や、新しい知的財産の活用方法を検証しながらも、建設的かつ柔軟に日々の業務を進め、メドレーの事業をしっかりとバックアップしていきたいと考えています。少しでも当社の知財活動が参考になれば幸いです。最後までお付き合い頂きありがとうございました！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは、メドレーのコーポレート本部法務コンプライアンス部で、知的財産関連の業務を担当している鬼鞍です。 1 年ほど前に本ブログで「 特許とはなにか 」というテーマで当社における特許啓蒙活動を紹介させて頂いたのですが、思っていた以上に反響があり、「面白い」とか「わかりやすい」という嬉しいコメントも頂戴しました。 私がメドレーに入社して最初のミッションが知財部門の立ち上げだったので、次はぜひ**「ベンチャーでの知財部門の立ち上げ方」**的なテーマでブログ発信したいと思っていたのですが、当初はまだ具体的な社内事例が少なかったため、実績ができた段階で改めて本ブログで発表したいと思っていました。 それから１年以上が経過して実際に特許も取得するなど知財活動としての実績が蓄積されてきたため、これを機会に ベンチャーで知財部門を立ち上げる際にやるべきことについて、実例に触れながら具体的にまとめてみました。 かなり長いコンテンツになってしまいましたが、 フェーズごとの知財活動計画 であったり、 知財ロードマップの作り方 など、 なかなか表に出てこない知財部門立ち上げストーリーの具体的事例を惜しみなく書かせていただいております ので、ぜひご一読いただき、お役に立てれば幸いです。 知財は開発チームとの信頼関係の構築がまず第一 先ほどは知財部門を立ち上げストーリの中で、知財活動計画とか、知財ロードマップであるとか少し格好つけたような文字が羅列していましたが、実は私が知財専任として初めに配置されて最初にやったことはそんな大それたことではありませんでした。 最初になにをやったかというと、 エンジニアの方とランチに行く、あるいは飲みに行く 、ということでした。当時はまだ Covid-19 が蔓延する前だったので気軽にそういうことができました。入社して最初の 1 ヶ月くらいは週 2 回くらいのペースで誰かとランチか飲みにいくということをしていたと思います。 飲みに行く、というとふざけているとか思われるかもしれませんが、知財部門の立ち上げストーリーを語る上で、このプロセスは無視できないほど重要だと考えています。先に断っておくと私は酒好きでもなければ、家でも一切飲みません。 当たり前のことなのですが、知財というのはプロダクトを生み出す開発組織があって初めて価値を発揮するものです。知財はあくまで事業や開発をサポートするところであって、それ単体で存在意義を発揮することはほぼありません。特に特許活動については開発チームとの連携が非常に重要です。 一緒にご飯を食べることが信頼関係を構築する上で最良の方法、とまでは言いませんが、少なくともご飯を食べない人はいないわけで、時間を無駄にしている感もなければ、オフィスの外で会えば仕事以外のことを話題にし易いので互いの趣味嗜好を知ることができます。みなさんもそうだと思いますが、通常、仲の悪い人とは一緒に食事はしないと思います。 特に、この後にもご紹介する 社内のアイデアを発掘するという発明発掘活動は、話しやすいカジュアルな雰囲気で雑談のような感じでブレストするというのが非常に重要 で、このときに相手がどんな人間かを互いに知っているか、知らないかでは大きな差がでてきます。 また更に、この後にご紹介する知財計画立案や知財ロードマップを作成することも当然重要なのですが、結局仕事というのは人と人との間を思考がやりとりされて実現化されていくものなので、人間関係・信頼関係が全ての基礎であり、実は一番大切にするべきものだと思います。 これは何も知財に限ったことではなく、部門を跨いで仕事をする上で信頼関係は非常に重要ですし、知財の観点で見ても 円滑なコミュニケーションが結果的にいい発明やアイデアを生み出すための土壌づくりに貢献する ものだと考えています。 知財活動計画は、事業の成長フェーズに合わせて設定する 知財部門の設立にあたって、エンジニアとのコミュニケーションと並行して進めたのが、知財活動計画の立案でした。知財活動とは、知財サイクルをうまく事業サイクルにインストールしてサイクルを循環させることであり、更にはこのサイクルが循環するための運用基盤を構築することを指します。また、ここでいう知財サイクルとは、例えば、社内に埋もれたアイデアを発掘し（創発）→ それを知財権化し（保護）→ 権利化した知財を活用し（活用）→ 活用した知財で得られた利益や結果を創発支援に適用できる形に変換する、というものです。 このような知財サイクルを、何の計画や戦略もなしに事業サイクルへインストールしようとするとうまくいきません。なぜなら、事業というのは日々成長し変化していくもので、 事業の成長に応じて知財活動の目的や課題も変化するからです 。 例えば、子会社が増えて事業規模が拡大すると、その子会社の事業領域で既に多くの特許出願がされている場合には、発明発掘活動よりもまずは法的リスクを回避することを最優先にして、他社の特許調査をしっかりやってからプロダクトをリリースする仕組みを作ろう、ということになります。あるいは、事業の成長に伴いプロダクトが成熟してきた場面では、似たようなプロダクトが乱立する結果、尖った機能や最先端技術で差別化をするようになるため、こうした場合には先行した特許取得が重要な目的になってきます。 このように、事業の成長フェーズに応じた知財活動の計画を立案するべく、まずはメドレーのミッションおよびそのミッションを実現するためのプロダクトの性質を把握する必要がありました。 メドレーは「医療ヘルスケアの未来をつくる」というミッションを掲げ、インターネットテクノロジーによる医療のあり方の変革を目指す企業です。 このミッションと向き合いつつ、 事業プラットフォームの成長フェーズごとに知財活動の方向性・目的を３段階にわけて設定し、成長フェーズごとに知財活動計画を立案しました 。 例えば、プラットフォームの創設期においては新規ユーザ獲得が重要となり、使い勝手のいいシンプルな機能に開発の方向性が向いているため、独自性のある技術を特許化するというよりも、まずは守りを固めるべく知財権侵害のリスクを最小限にして法的安定性の確保に軸足を置いた知財活動を推進します。 このような計画は、知財の観点で一方的にできるものではありません。 知財活動の計画に際しては、開発チームを統括するマネージャにプロダクト開発の方向性をヒアリングして特許取得の判断基準を検討したり、経営層に将来の事業の方向性についてヒアリングをして長期志向で目標設定したりして、ブラッシュアップしていきました。 そういった検討や議論を重ねていくうちに自然と、その企業風土や事業ミッションにあった知財活動計画というものができあがってくるのだと思います。 知財活動ロードマップで現在位置を把握しつつ定期的に軌道修正する 長期的な方向性を可視化したら次はそれをどう実行するかという実行計画が必要になってきました。 そもそも自分たちは今何ができていて、何ができていないのか。またどのようなことを今後やっていかなければならないのかが不明確だよね、という話になり、それを具体的に俯瞰するための知財ロードマッピングというものを作成しました。 縦軸に知的財産の種類、横軸に時間軸であるフェーズを設定して、知財活動の内容に過不足ないかをチェックできるようにしました。 定期的に内容を見直してメドレーの事業規模にあった形に修正しながら自分達の現在位置を把握し、今後の方向性を見定めるためのツールとして有効でした。 このようなロードマップがあれば、知財担当者の立場からすると、実績が可視化されるため知財活動を推進していく上での達成感もありますし、逆に知財担当者を評価する立場からしても、明確な評価基準がない中で、知財担当者の評価をする際に役に立ちます。 以上のように、何もないところから他部門と関わりながら知財活動計画を立案し、ロードマップを達成していくのは、知財部門を立ち上げるという業務の面白さの１つでもあります。 初期段階から長期視点で知財素人でも回せる業務運用作りをする 1 人法務や 1 人知財担当という状況は、遅かれ早かれ属人化という問題が必ずやってきます。 属人化は組織運営上、健全ではありません。 そのため、 知財に関する知識がない人間でも、誰でもその業務を回すことができるような状態をつくる ために、知財部門立ち上げの初期段階から、自分が担当している業務でルーチン化できるものは全て仕組み化してドキュメントに落とし込むようにしていました。 例えば「怪しい特許を見つけた場合の動き方」、「発明報奨金の決定プロセス」、「他社特許調査及び発明発掘のハイブリッド調査の進め方」などなど、ありとあらゆるプロセス業務を全てフロー図や概念図を作成し、誰か見てもわかる業務ということに留意しています。 現状はまだ引き継ぎや新たな知財部員の登用という話がないので、わかりやすい効果を発揮しているわけではないのですが、他部門からの問い合わせがあった際は資料だけ渡せば理解してもらえるので、コミュニケーションの効率化には貢献していると思います。 どのような特許を取得すべきなのか 企業としてどのような特許を取得していくべきか、ということは「知財を最大限に活用する」という知財の出口から考えていく上で、重要な事項になります。 そしてどのような特許を取得するかは、事業領域や事業ミッションに沿って設定されるべきです。 メドレーは、オープンプラットフォームによる医療のあり方の変革を目指している企業なので、開発チームから上がってきたアイデアについては、 プラットフォーム事業を適切に運営していく上で必要な技術かどうか 、という観点で特許化するかどうかを判断しています。 例えば、最近特許を取得した**医療データの管理方法（ 特許第 6921177 号 ）**というものがあります。これは、アプリ端末から入力された患者データと、医療機関の各業務システムから入力された患者データという 2 つの類似したデータをシームレスに管理するために、両方のデータを 2 つのデータベース上で統合管理することにより、データ管理の責任分担の明確化及び厳格な情報管理を可能にするというものです。 仕組みとしてはとてもシンプルなのですが、 患者の持つ端末と、医科・歯科・調剤等の各業務システムをシームレスに連携させる仕組みが、医療プラットフォームを適切に運営していく上で必要な技術だと判断 したため、特許化しました。 また、上記事例のように実際にプロダクトに実装されている技術を特許化したものだけでなく、実際にプロダクトに実装するかわからないけれども将来を見据えた先見的な特許として、**ブロックチェーンを用いた電子処方箋の管理方法（ 特許第 6936763 号 ）**という特許を取得しています。 これは、ブロックチェーンを用いたアクセス権の管理機能として全体的に秘密状態を保ちながら電子処方箋を管理するためのアクセス制御に関する仕組みで、ブロックチェーンデータベース上において処方箋データと患者データとを紐づけて、医師端末からの患者レコードへの一時的なアクセス権限を付与し、会計終了時に患者端末の操作に応じて医師端末へのアクセス権限を剥奪するというものです。 このような特許を取得した背景には、 マーケットを独占して権利主張をするためというよりも、メドレーが考える未来のプロダクトビジョンであったり、開発部門の先見的な創作活動を対外的に発信したい 、という思いがあります。 メドレーは、顧客利用率の高いプロダクト、機能拡張性の高いプロダクトの開発を推進しているため、**独創的で最新技術を取り入れた尖った機能を目指すというよりはユーザにとって使いやすいシンプルさが多く取り入れられています。**また、それだけではなく、前述したブロックチェーンと電子処方箋との組み合わせ技術の先見的な特許取得のように、10 年先を見据えた未来のプロダクトのあり方についても日々追求しています。 特許を身近に感じてもらうためのユニークな話も取り入れて社内に啓蒙する いい特許を生み出すためには地道な社内の啓蒙活動も重要です。 メドレーでは、開発チーム間の技術格差の是正や、技術情報の共有による活性化を目的として、エンジニアが日々の業務で扱っている技術や取り組みについて共有するテックランチという勉強会が定期的に開催されています。 先日そのテックランチで、社内のエンジニアの方達に少しでも特許を身近に感じてもらおうと、「特許の頭体操」というコーナーを設けて、実際に頭を使って体験してもらいました。 下の例では、おたまとスプーンとの違いを考えようというお題を通して、ある物の特徴を把握する際に、 「違い」から「もの」を観察すると、その物の特徴が浮き出てくる 、というメッセージが含まれています。 おたまもスプーンも対象物をすくい上げるという機能においては共通しているのですが、おたまの先端のお皿部分とスプーンの先端のお皿部分とは、その形状が異なります。スプーンのお皿部分は楕円形ですが、おたまのお皿部分は円形になっています。 つまり、おたまの特徴は、特許的にいうと「その先端にあるお皿部分が円形の開口を有した半球状で、対象物をすくうための所定の深さを有している」ということになります。 この辺はちょっと固苦しい表現が続いたせいもあり、「難しい…」というコメントをもらいました。馴染みのない人にとってはただただ面倒な作業だと思います。 しかし、ここで言いたかったのは、 これはあくまで構造物についての話であって、ソフトウェアの特徴を把握するということはそんなに難しいことではないのだよ 、ということでした。 ソフトウェアの場合は、ちょっとした機能を追加すれば、それが従来のソフトとは異なるものとなり、比較的簡単に特許になってしまうケースが少なくありません。 つまり、エンジニアの方は日々新しい機能を実装すべく開発業務を行っているわけなので、 知財の観点から言うと、極端なことを言えば日々発明をしている ということになります。当然特許になるかどうかは別の話になりますが、日々の開発業務で自分が発明をしていることに気づいていない、という状況が多分にあるということです。 さらに、 知財担当がこれに気づかなければ、日の目を見ることない埋蔵知財が量産される ということになってしまいます。 では、どのようにしてエンジニアの方が自ら発明をしていることに気づいていないものを発掘し、社内の知的財産として認定していくのか、というのが次の話になります。 面白いアイデアは雑談から生まれる 日々の開発業務の延長で生まれてくる機能や技術を特許化するという活動が基本であることは間違いないのですが、実際にプロダクトに実装するかどうか不確定要素を多く含むアイデアを特許化するという活動は、エンジニアの開発成果物を知的財産として見える化することで、エンジニアの成果が報われる土壌を作るという意味においては大切な活動になってきます。 ただ、どの企業知財部でも発明発掘業務はされていると思いますし、「アイデアは雑談から生まれる」ということは既に周知の事実かもしれません。また、知財活動として特段新しいことをしているわけではないのですが、実際にそれを実行する際の心構えであったり、具体的に気をつけていることについて、事例を通してご紹介したいと思います。 私は、 エンジニアの方というのは、アイデアの卵をもっている という前提に立ってエンジニアの方とコミュニケーションをとるようにしています。 そうすると、「実はアイデアありますよね、なんで言ってくれないんですか〜。」という具合にカジュアルな会話をスタートすることができ、スムーズにブレストを進めることができたりします。大したことではないのですが、 意外とこういう心がけが円滑なコミュニケーションを生み出すきっかけになっている かもしれません。 一方で、エンジニアの方は暇ではありません。 日々の開発では、既存機能の修正や新規機能の開発などの案件に追われるため、頭の中にあるアイデアの卵も埋もれてしまいがちです。 以上のことを踏まえ、エンジニアからアイデアを出してもらうためのブレスト MTG では主に以下の点に気をつけています。 エンジニアの方の負担にならないように短時間に設定すること（長くて 30 分） カジュアルに話しやすい雑談ベースの雰囲気にすること そのために少人数で行うこと 出てきたアイデアを楽しむこと 実際に下図に示すような雑談ベースの会話から、「診療方式を患者と医療機関との間の距離に応じて、対面診療かオンライン診療かを自動的に切り替える」というアイデアが生まれ、実際に特許出願につながりました。 この時にエンジニアの方々からは「とても面白い！」とか「またやりたい！」という前向きなコメントをもらえて、カジュアルベースの雑談効果を実感しました。 このようなブレストを通して一番大きな気づきというのは、エンジニアの皆さん、本当によくプロダクトについて考えているということ。 エンジニアの方々の創意工夫が全て知的財産「権」になるわけではないのですが、知的財産であることには違いありません。 これからは、そういった エンジニアの方の頭の中に埋もれがちな創意・工夫というものが報われるような土壌作りを、知的財産というツールを使って構築していきたい と考えています。 このブログも「特許を対外的にどう見せるか」という実験の１つ ここまでご紹介してきた内容は、知財計画を立てて、立てた計画に沿って知財業務を運用し、運用していく中でアイデア発掘して知財化する、という話にとどまってましたが、実際に取得した知財権をどのように活用して企業価値の向上につなげるのか、ということがこれからの知財部門にとっての重要なミッションになると考えています。 従来は、特許権の独占排他権という性質を使って参入障壁として活用したり、模倣の抑止に活用されるのが常識だったと思いますが、メドレーではこれまでにない新たな活用方法を模索しています。 実はこのブログもそうなのですが、特許を対外的にどうみせるか、ということの１つの実験です。 どういうことかというと、ここまでご紹介してきた 知財活動自体も人の知的活動によって生み出された知的財産であり、このようにブログで発信しなければ単なる埋蔵知財になってしまいます 。 例えば、特許取得についてもただ特許を取ったという事実を公表するのではなく、どうしてそのような特許を取得してどのように活用しているのか、またそこに関連したメンバーは誰でどのような検討があったのか、というストーリーメイキングをすると、特許というものを中心とした１つのドラマが浮き上がってきます。 今回は知財活動のご紹介という趣旨で、特許を中心とした内容になっているため、特許に関心がない人にはあまりささらないコンテンツになっているかもしれませんが、例えば特許と広報との掛け算でストーリーメイキングをすれば 特許に関心がある人だけでなく、広報に関心がある人にも情報がリーチすることになります 。 これは 特許というものが、人材・業務ノウハウ・広報・採用活動等と同列に知的財産である がゆえになせるものです。これからは、知的財産＝特許、商標という視点ではなく、知財＝目に見えない創造的な活動という捉え方をした上で、企業価値に貢献していく必要があります。 知財部門が、採用、IR、広報、開発、社内 IT といった企業内にある多数の部門とコラボレーションすることでこれまで見たことのない新しい知財活用の形を模索し、 知財を最大活用することによって企業価値を向上させていきたい と考えています。 さいごに ここまで、知財活動の一部をご紹介させていただきましたが、これが知財活動の進め方として正解というわけではなく、企業風土や事業領域によって、知財活動のあり方は異なります。そして、そこを考えながら知財活動を推進していくことが仕事の面白さであり醍醐味とも言えます。新しい知財部のあり方や、新しい知的財産の活用方法を検証しながらも、建設的かつ柔軟に日々の業務を進め、メドレーの事業をしっかりとバックアップしていきたいと考えています。少しでも当社の知財活動が参考になれば幸いです。最後までお付き合い頂きありがとうございました！ https://www.medley.jp/jobs/

はじめに こんにちは、メドレーのコーポレート本部法務コンプライアンス部で、知的財産関連の業務を担当している鬼鞍です。 1 年ほど前に本ブログで「 特許とはなにか 」というテーマで当社における特許啓蒙活動を紹介させて頂いたのですが、思っていた以上に反響があり、「面白い」とか「わかりやすい」という嬉しいコメントも頂戴しました。 私がメドレーに入社して最初のミッションが知財部門の立ち上げだったので、次はぜひ**「ベンチャーでの知財部門の立ち上げ方」**的なテーマでブログ発信したいと思っていたのですが、当初はまだ具体的な社内事例が少なかったため、実績ができた段階で改めて本ブログで発表したいと思っていました。 それから１年以上が経過して実際に特許も取得するなど知財活動としての実績が蓄積されてきたため、これを機会に ベンチャーで知財部門を立ち上げる際にやるべきことについて、実例に触れながら具体的にまとめてみました。 かなり長いコンテンツになってしまいましたが、 フェーズごとの知財活動計画 であったり、 知財ロードマップの作り方 など、 なかなか表に出てこない知財部門立ち上げストーリーの具体的事例を惜しみなく書かせていただいております ので、ぜひご一読いただき、お役に立てれば幸いです。 知財は開発チームとの信頼関係の構築がまず第一 先ほどは知財部門を立ち上げストーリの中で、知財活動計画とか、知財ロードマップであるとか少し格好つけたような文字が羅列していましたが、実は私が知財専任として初めに配置されて最初にやったことはそんな大それたことではありませんでした。 最初になにをやったかというと、 エンジニアの方とランチに行く、あるいは飲みに行く 、ということでした。当時はまだ Covid-19 が蔓延する前だったので気軽にそういうことができました。入社して最初の 1 ヶ月くらいは週 2 回くらいのペースで誰かとランチか飲みにいくということをしていたと思います。 飲みに行く、というとふざけているとか思われるかもしれませんが、知財部門の立ち上げストーリーを語る上で、このプロセスは無視できないほど重要だと考えています。先に断っておくと私は酒好きでもなければ、家でも一切飲みません。 当たり前のことなのですが、知財というのはプロダクトを生み出す開発組織があって初めて価値を発揮するものです。知財はあくまで事業や開発をサポートするところであって、それ単体で存在意義を発揮することはほぼありません。特に特許活動については開発チームとの連携が非常に重要です。 一緒にご飯を食べることが信頼関係を構築する上で最良の方法、とまでは言いませんが、少なくともご飯を食べない人はいないわけで、時間を無駄にしている感もなければ、オフィスの外で会えば仕事以外のことを話題にし易いので互いの趣味嗜好を知ることができます。みなさんもそうだと思いますが、通常、仲の悪い人とは一緒に食事はしないと思います。 特に、この後にもご紹介する 社内のアイデアを発掘するという発明発掘活動は、話しやすいカジュアルな雰囲気で雑談のような感じでブレストするというのが非常に重要 で、このときに相手がどんな人間かを互いに知っているか、知らないかでは大きな差がでてきます。 また更に、この後にご紹介する知財計画立案や知財ロードマップを作成することも当然重要なのですが、結局仕事というのは人と人との間を思考がやりとりされて実現化されていくものなので、人間関係・信頼関係が全ての基礎であり、実は一番大切にするべきものだと思います。 これは何も知財に限ったことではなく、部門を跨いで仕事をする上で信頼関係は非常に重要ですし、知財の観点で見ても 円滑なコミュニケーションが結果的にいい発明やアイデアを生み出すための土壌づくりに貢献する ものだと考えています。 知財活動計画は、事業の成長フェーズに合わせて設定する 知財部門の設立にあたって、エンジニアとのコミュニケーションと並行して進めたのが、知財活動計画の立案でした。知財活動とは、知財サイクルをうまく事業サイクルにインストールしてサイクルを循環させることであり、更にはこのサイクルが循環するための運用基盤を構築することを指します。また、ここでいう知財サイクルとは、例えば、社内に埋もれたアイデアを発掘し（創発）→ それを知財権化し（保護）→ 権利化した知財を活用し（活用）→ 活用した知財で得られた利益や結果を創発支援に適用できる形に変換する、というものです。 このような知財サイクルを、何の計画や戦略もなしに事業サイクルへインストールしようとするとうまくいきません。なぜなら、事業というのは日々成長し変化していくもので、 事業の成長に応じて知財活動の目的や課題も変化するからです 。 例えば、子会社が増えて事業規模が拡大すると、その子会社の事業領域で既に多くの特許出願がされている場合には、発明発掘活動よりもまずは法的リスクを回避することを最優先にして、他社の特許調査をしっかりやってからプロダクトをリリースする仕組みを作ろう、ということになります。あるいは、事業の成長に伴いプロダクトが成熟してきた場面では、似たようなプロダクトが乱立する結果、尖った機能や最先端技術で差別化をするようになるため、こうした場合には先行した特許取得が重要な目的になってきます。 このように、事業の成長フェーズに応じた知財活動の計画を立案するべく、まずはメドレーのミッションおよびそのミッションを実現するためのプロダクトの性質を把握する必要がありました。 メドレーは「医療ヘルスケアの未来をつくる」というミッションを掲げ、インターネットテクノロジーによる医療のあり方の変革を目指す企業です。 このミッションと向き合いつつ、 事業プラットフォームの成長フェーズごとに知財活動の方向性・目的を３段階にわけて設定し、成長フェーズごとに知財活動計画を立案しました 。 例えば、プラットフォームの創設期においては新規ユーザ獲得が重要となり、使い勝手のいいシンプルな機能に開発の方向性が向いているため、独自性のある技術を特許化するというよりも、まずは守りを固めるべく知財権侵害のリスクを最小限にして法的安定性の確保に軸足を置いた知財活動を推進します。 このような計画は、知財の観点で一方的にできるものではありません。 知財活動の計画に際しては、開発チームを統括するマネージャにプロダクト開発の方向性をヒアリングして特許取得の判断基準を検討したり、経営層に将来の事業の方向性についてヒアリングをして長期志向で目標設定したりして、ブラッシュアップしていきました。 そういった検討や議論を重ねていくうちに自然と、その企業風土や事業ミッションにあった知財活動計画というものができあがってくるのだと思います。 知財活動ロードマップで現在位置を把握しつつ定期的に軌道修正する 長期的な方向性を可視化したら次はそれをどう実行するかという実行計画が必要になってきました。 そもそも自分たちは今何ができていて、何ができていないのか。またどのようなことを今後やっていかなければならないのかが不明確だよね、という話になり、それを具体的に俯瞰するための知財ロードマッピングというものを作成しました。 縦軸に知的財産の種類、横軸に時間軸であるフェーズを設定して、知財活動の内容に過不足ないかをチェックできるようにしました。 定期的に内容を見直してメドレーの事業規模にあった形に修正しながら自分達の現在位置を把握し、今後の方向性を見定めるためのツールとして有効でした。 このようなロードマップがあれば、知財担当者の立場からすると、実績が可視化されるため知財活動を推進していく上での達成感もありますし、逆に知財担当者を評価する立場からしても、明確な評価基準がない中で、知財担当者の評価をする際に役に立ちます。 以上のように、何もないところから他部門と関わりながら知財活動計画を立案し、ロードマップを達成していくのは、知財部門を立ち上げるという業務の面白さの１つでもあります。 初期段階から長期視点で知財素人でも回せる業務運用作りをする 1 人法務や 1 人知財担当という状況は、遅かれ早かれ属人化という問題が必ずやってきます。 属人化は組織運営上、健全ではありません。 そのため、 知財に関する知識がない人間でも、誰でもその業務を回すことができるような状態をつくる ために、知財部門立ち上げの初期段階から、自分が担当している業務でルーチン化できるものは全て仕組み化してドキュメントに落とし込むようにしていました。 例えば「怪しい特許を見つけた場合の動き方」、「発明報奨金の決定プロセス」、「他社特許調査及び発明発掘のハイブリッド調査の進め方」などなど、ありとあらゆるプロセス業務を全てフロー図や概念図を作成し、誰か見てもわかる業務ということに留意しています。 現状はまだ引き継ぎや新たな知財部員の登用という話がないので、わかりやすい効果を発揮しているわけではないのですが、他部門からの問い合わせがあった際は資料だけ渡せば理解してもらえるので、コミュニケーションの効率化には貢献していると思います。 どのような特許を取得すべきなのか 企業としてどのような特許を取得していくべきか、ということは「知財を最大限に活用する」という知財の出口から考えていく上で、重要な事項になります。 そしてどのような特許を取得するかは、事業領域や事業ミッションに沿って設定されるべきです。 メドレーは、オープンプラットフォームによる医療のあり方の変革を目指している企業なので、開発チームから上がってきたアイデアについては、 プラットフォーム事業を適切に運営していく上で必要な技術かどうか 、という観点で特許化するかどうかを判断しています。 例えば、最近特許を取得した**医療データの管理方法（ 特許第 6921177 号 ）**というものがあります。これは、アプリ端末から入力された患者データと、医療機関の各業務システムから入力された患者データという 2 つの類似したデータをシームレスに管理するために、両方のデータを 2 つのデータベース上で統合管理することにより、データ管理の責任分担の明確化及び厳格な情報管理を可能にするというものです。 仕組みとしてはとてもシンプルなのですが、 患者の持つ端末と、医科・歯科・調剤等の各業務システムをシームレスに連携させる仕組みが、医療プラットフォームを適切に運営していく上で必要な技術だと判断 したため、特許化しました。 また、上記事例のように実際にプロダクトに実装されている技術を特許化したものだけでなく、実際にプロダクトに実装するかわからないけれども将来を見据えた先見的な特許として、**ブロックチェーンを用いた電子処方箋の管理方法（ 特許第 6936763 号 ）**という特許を取得しています。 これは、ブロックチェーンを用いたアクセス権の管理機能として全体的に秘密状態を保ちながら電子処方箋を管理するためのアクセス制御に関する仕組みで、ブロックチェーンデータベース上において処方箋データと患者データとを紐づけて、医師端末からの患者レコードへの一時的なアクセス権限を付与し、会計終了時に患者端末の操作に応じて医師端末へのアクセス権限を剥奪するというものです。 このような特許を取得した背景には、 マーケットを独占して権利主張をするためというよりも、メドレーが考える未来のプロダクトビジョンであったり、開発部門の先見的な創作活動を対外的に発信したい 、という思いがあります。 メドレーは、顧客利用率の高いプロダクト、機能拡張性の高いプロダクトの開発を推進しているため、**独創的で最新技術を取り入れた尖った機能を目指すというよりはユーザにとって使いやすいシンプルさが多く取り入れられています。**また、それだけではなく、前述したブロックチェーンと電子処方箋との組み合わせ技術の先見的な特許取得のように、10 年先を見据えた未来のプロダクトのあり方についても日々追求しています。 特許を身近に感じてもらうためのユニークな話も取り入れて社内に啓蒙する いい特許を生み出すためには地道な社内の啓蒙活動も重要です。 メドレーでは、開発チーム間の技術格差の是正や、技術情報の共有による活性化を目的として、エンジニアが日々の業務で扱っている技術や取り組みについて共有するテックランチという勉強会が定期的に開催されています。 先日そのテックランチで、社内のエンジニアの方達に少しでも特許を身近に感じてもらおうと、「特許の頭体操」というコーナーを設けて、実際に頭を使って体験してもらいました。 下の例では、おたまとスプーンとの違いを考えようというお題を通して、ある物の特徴を把握する際に、 「違い」から「もの」を観察すると、その物の特徴が浮き出てくる 、というメッセージが含まれています。 おたまもスプーンも対象物をすくい上げるという機能においては共通しているのですが、おたまの先端のお皿部分とスプーンの先端のお皿部分とは、その形状が異なります。スプーンのお皿部分は楕円形ですが、おたまのお皿部分は円形になっています。 つまり、おたまの特徴は、特許的にいうと「その先端にあるお皿部分が円形の開口を有した半球状で、対象物をすくうための所定の深さを有している」ということになります。 この辺はちょっと固苦しい表現が続いたせいもあり、「難しい…」というコメントをもらいました。馴染みのない人にとってはただただ面倒な作業だと思います。 しかし、ここで言いたかったのは、 これはあくまで構造物についての話であって、ソフトウェアの特徴を把握するということはそんなに難しいことではないのだよ 、ということでした。 ソフトウェアの場合は、ちょっとした機能を追加すれば、それが従来のソフトとは異なるものとなり、比較的簡単に特許になってしまうケースが少なくありません。 つまり、エンジニアの方は日々新しい機能を実装すべく開発業務を行っているわけなので、 知財の観点から言うと、極端なことを言えば日々発明をしている ということになります。当然特許になるかどうかは別の話になりますが、日々の開発業務で自分が発明をしていることに気づいていない、という状況が多分にあるということです。 さらに、 知財担当がこれに気づかなければ、日の目を見ることない埋蔵知財が量産される ということになってしまいます。 では、どのようにしてエンジニアの方が自ら発明をしていることに気づいていないものを発掘し、社内の知的財産として認定していくのか、というのが次の話になります。 面白いアイデアは雑談から生まれる 日々の開発業務の延長で生まれてくる機能や技術を特許化するという活動が基本であることは間違いないのですが、実際にプロダクトに実装するかどうか不確定要素を多く含むアイデアを特許化するという活動は、エンジニアの開発成果物を知的財産として見える化することで、エンジニアの成果が報われる土壌を作るという意味においては大切な活動になってきます。 ただ、どの企業知財部でも発明発掘業務はされていると思いますし、「アイデアは雑談から生まれる」ということは既に周知の事実かもしれません。また、知財活動として特段新しいことをしているわけではないのですが、実際にそれを実行する際の心構えであったり、具体的に気をつけていることについて、事例を通してご紹介したいと思います。 私は、 エンジニアの方というのは、アイデアの卵をもっている という前提に立ってエンジニアの方とコミュニケーションをとるようにしています。 そうすると、「実はアイデアありますよね、なんで言ってくれないんですか〜。」という具合にカジュアルな会話をスタートすることができ、スムーズにブレストを進めることができたりします。大したことではないのですが、 意外とこういう心がけが円滑なコミュニケーションを生み出すきっかけになっている かもしれません。 一方で、エンジニアの方は暇ではありません。 日々の開発では、既存機能の修正や新規機能の開発などの案件に追われるため、頭の中にあるアイデアの卵も埋もれてしまいがちです。 以上のことを踏まえ、エンジニアからアイデアを出してもらうためのブレスト MTG では主に以下の点に気をつけています。 エンジニアの方の負担にならないように短時間に設定すること（長くて 30 分） カジュアルに話しやすい雑談ベースの雰囲気にすること そのために少人数で行うこと 出てきたアイデアを楽しむこと 実際に下図に示すような雑談ベースの会話から、「診療方式を患者と医療機関との間の距離に応じて、対面診療かオンライン診療かを自動的に切り替える」というアイデアが生まれ、実際に特許出願につながりました。 この時にエンジニアの方々からは「とても面白い！」とか「またやりたい！」という前向きなコメントをもらえて、カジュアルベースの雑談効果を実感しました。 このようなブレストを通して一番大きな気づきというのは、エンジニアの皆さん、本当によくプロダクトについて考えているということ。 エンジニアの方々の創意工夫が全て知的財産「権」になるわけではないのですが、知的財産であることには違いありません。 これからは、そういった エンジニアの方の頭の中に埋もれがちな創意・工夫というものが報われるような土壌作りを、知的財産というツールを使って構築していきたい と考えています。 このブログも「特許を対外的にどう見せるか」という実験の１つ ここまでご紹介してきた内容は、知財計画を立てて、立てた計画に沿って知財業務を運用し、運用していく中でアイデア発掘して知財化する、という話にとどまってましたが、実際に取得した知財権をどのように活用して企業価値の向上につなげるのか、ということがこれからの知財部門にとっての重要なミッションになると考えています。 従来は、特許権の独占排他権という性質を使って参入障壁として活用したり、模倣の抑止に活用されるのが常識だったと思いますが、メドレーではこれまでにない新たな活用方法を模索しています。 実はこのブログもそうなのですが、特許を対外的にどうみせるか、ということの１つの実験です。 どういうことかというと、ここまでご紹介してきた 知財活動自体も人の知的活動によって生み出された知的財産であり、このようにブログで発信しなければ単なる埋蔵知財になってしまいます 。 例えば、特許取得についてもただ特許を取ったという事実を公表するのではなく、どうしてそのような特許を取得してどのように活用しているのか、またそこに関連したメンバーは誰でどのような検討があったのか、というストーリーメイキングをすると、特許というものを中心とした１つのドラマが浮き上がってきます。 今回は知財活動のご紹介という趣旨で、特許を中心とした内容になっているため、特許に関心がない人にはあまりささらないコンテンツになっているかもしれませんが、例えば特許と広報との掛け算でストーリーメイキングをすれば 特許に関心がある人だけでなく、広報に関心がある人にも情報がリーチすることになります 。 これは 特許というものが、人材・業務ノウハウ・広報・採用活動等と同列に知的財産である がゆえになせるものです。これからは、知的財産＝特許、商標という視点ではなく、知財＝目に見えない創造的な活動という捉え方をした上で、企業価値に貢献していく必要があります。 知財部門が、採用、IR、広報、開発、社内 IT といった企業内にある多数の部門とコラボレーションすることでこれまで見たことのない新しい知財活用の形を模索し、 知財を最大活用することによって企業価値を向上させていきたい と考えています。 さいごに ここまで、知財活動の一部をご紹介させていただきましたが、これが知財活動の進め方として正解というわけではなく、企業風土や事業領域によって、知財活動のあり方は異なります。そして、そこを考えながら知財活動を推進していくことが仕事の面白さであり醍醐味とも言えます。新しい知財部のあり方や、新しい知的財産の活用方法を検証しながらも、建設的かつ柔軟に日々の業務を進め、メドレーの事業をしっかりとバックアップしていきたいと考えています。少しでも当社の知財活動が参考になれば幸いです。最後までお付き合い頂きありがとうございました！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは、メドレーのコーポレート本部法務コンプライアンス部で、知的財産関連の業務を担当している鬼鞍です。 1 年ほど前に本ブログで「 特許とはなにか 」というテーマで当社における特許啓蒙活動を紹介させて頂いたのですが、思っていた以上に反響があり、「面白い」とか「わかりやすい」という嬉しいコメントも頂戴しました。 私がメドレーに入社して最初のミッションが知財部門の立ち上げだったので、次はぜひ**「ベンチャーでの知財部門の立ち上げ方」**的なテーマでブログ発信したいと思っていたのですが、当初はまだ具体的な社内事例が少なかったため、実績ができた段階で改めて本ブログで発表したいと思っていました。 それから１年以上が経過して実際に特許も取得するなど知財活動としての実績が蓄積されてきたため、これを機会に ベンチャーで知財部門を立ち上げる際にやるべきことについて、実例に触れながら具体的にまとめてみました。 かなり長いコンテンツになってしまいましたが、 フェーズごとの知財活動計画 であったり、 知財ロードマップの作り方 など、 なかなか表に出てこない知財部門立ち上げストーリーの具体的事例を惜しみなく書かせていただいております ので、ぜひご一読いただき、お役に立てれば幸いです。 知財は開発チームとの信頼関係の構築がまず第一 先ほどは知財部門を立ち上げストーリの中で、知財活動計画とか、知財ロードマップであるとか少し格好つけたような文字が羅列していましたが、実は私が知財専任として初めに配置されて最初にやったことはそんな大それたことではありませんでした。 最初になにをやったかというと、 エンジニアの方とランチに行く、あるいは飲みに行く 、ということでした。当時はまだ Covid-19 が蔓延する前だったので気軽にそういうことができました。入社して最初の 1 ヶ月くらいは週 2 回くらいのペースで誰かとランチか飲みにいくということをしていたと思います。 飲みに行く、というとふざけているとか思われるかもしれませんが、知財部門の立ち上げストーリーを語る上で、このプロセスは無視できないほど重要だと考えています。先に断っておくと私は酒好きでもなければ、家でも一切飲みません。 当たり前のことなのですが、知財というのはプロダクトを生み出す開発組織があって初めて価値を発揮するものです。知財はあくまで事業や開発をサポートするところであって、それ単体で存在意義を発揮することはほぼありません。特に特許活動については開発チームとの連携が非常に重要です。 一緒にご飯を食べることが信頼関係を構築する上で最良の方法、とまでは言いませんが、少なくともご飯を食べない人はいないわけで、時間を無駄にしている感もなければ、オフィスの外で会えば仕事以外のことを話題にし易いので互いの趣味嗜好を知ることができます。みなさんもそうだと思いますが、通常、仲の悪い人とは一緒に食事はしないと思います。 特に、この後にもご紹介する 社内のアイデアを発掘するという発明発掘活動は、話しやすいカジュアルな雰囲気で雑談のような感じでブレストするというのが非常に重要 で、このときに相手がどんな人間かを互いに知っているか、知らないかでは大きな差がでてきます。 また更に、この後にご紹介する知財計画立案や知財ロードマップを作成することも当然重要なのですが、結局仕事というのは人と人との間を思考がやりとりされて実現化されていくものなので、人間関係・信頼関係が全ての基礎であり、実は一番大切にするべきものだと思います。 これは何も知財に限ったことではなく、部門を跨いで仕事をする上で信頼関係は非常に重要ですし、知財の観点で見ても 円滑なコミュニケーションが結果的にいい発明やアイデアを生み出すための土壌づくりに貢献する ものだと考えています。 知財活動計画は、事業の成長フェーズに合わせて設定する 知財部門の設立にあたって、エンジニアとのコミュニケーションと並行して進めたのが、知財活動計画の立案でした。知財活動とは、知財サイクルをうまく事業サイクルにインストールしてサイクルを循環させることであり、更にはこのサイクルが循環するための運用基盤を構築することを指します。また、ここでいう知財サイクルとは、例えば、社内に埋もれたアイデアを発掘し（創発）→ それを知財権化し（保護）→ 権利化した知財を活用し（活用）→ 活用した知財で得られた利益や結果を創発支援に適用できる形に変換する、というものです。 このような知財サイクルを、何の計画や戦略もなしに事業サイクルへインストールしようとするとうまくいきません。なぜなら、事業というのは日々成長し変化していくもので、 事業の成長に応じて知財活動の目的や課題も変化するからです 。 例えば、子会社が増えて事業規模が拡大すると、その子会社の事業領域で既に多くの特許出願がされている場合には、発明発掘活動よりもまずは法的リスクを回避することを最優先にして、他社の特許調査をしっかりやってからプロダクトをリリースする仕組みを作ろう、ということになります。あるいは、事業の成長に伴いプロダクトが成熟してきた場面では、似たようなプロダクトが乱立する結果、尖った機能や最先端技術で差別化をするようになるため、こうした場合には先行した特許取得が重要な目的になってきます。 このように、事業の成長フェーズに応じた知財活動の計画を立案するべく、まずはメドレーのミッションおよびそのミッションを実現するためのプロダクトの性質を把握する必要がありました。 メドレーは「医療ヘルスケアの未来をつくる」というミッションを掲げ、インターネットテクノロジーによる医療のあり方の変革を目指す企業です。 このミッションと向き合いつつ、 事業プラットフォームの成長フェーズごとに知財活動の方向性・目的を３段階にわけて設定し、成長フェーズごとに知財活動計画を立案しました 。 例えば、プラットフォームの創設期においては新規ユーザ獲得が重要となり、使い勝手のいいシンプルな機能に開発の方向性が向いているため、独自性のある技術を特許化するというよりも、まずは守りを固めるべく知財権侵害のリスクを最小限にして法的安定性の確保に軸足を置いた知財活動を推進します。 このような計画は、知財の観点で一方的にできるものではありません。 知財活動の計画に際しては、開発チームを統括するマネージャにプロダクト開発の方向性をヒアリングして特許取得の判断基準を検討したり、経営層に将来の事業の方向性についてヒアリングをして長期志向で目標設定したりして、ブラッシュアップしていきました。 そういった検討や議論を重ねていくうちに自然と、その企業風土や事業ミッションにあった知財活動計画というものができあがってくるのだと思います。 知財活動ロードマップで現在位置を把握しつつ定期的に軌道修正する 長期的な方向性を可視化したら次はそれをどう実行するかという実行計画が必要になってきました。 そもそも自分たちは今何ができていて、何ができていないのか。またどのようなことを今後やっていかなければならないのかが不明確だよね、という話になり、それを具体的に俯瞰するための知財ロードマッピングというものを作成しました。 縦軸に知的財産の種類、横軸に時間軸であるフェーズを設定して、知財活動の内容に過不足ないかをチェックできるようにしました。 定期的に内容を見直してメドレーの事業規模にあった形に修正しながら自分達の現在位置を把握し、今後の方向性を見定めるためのツールとして有効でした。 このようなロードマップがあれば、知財担当者の立場からすると、実績が可視化されるため知財活動を推進していく上での達成感もありますし、逆に知財担当者を評価する立場からしても、明確な評価基準がない中で、知財担当者の評価をする際に役に立ちます。 以上のように、何もないところから他部門と関わりながら知財活動計画を立案し、ロードマップを達成していくのは、知財部門を立ち上げるという業務の面白さの１つでもあります。 初期段階から長期視点で知財素人でも回せる業務運用作りをする 1 人法務や 1 人知財担当という状況は、遅かれ早かれ属人化という問題が必ずやってきます。 属人化は組織運営上、健全ではありません。 そのため、 知財に関する知識がない人間でも、誰でもその業務を回すことができるような状態をつくる ために、知財部門立ち上げの初期段階から、自分が担当している業務でルーチン化できるものは全て仕組み化してドキュメントに落とし込むようにしていました。 例えば「怪しい特許を見つけた場合の動き方」、「発明報奨金の決定プロセス」、「他社特許調査及び発明発掘のハイブリッド調査の進め方」などなど、ありとあらゆるプロセス業務を全てフロー図や概念図を作成し、誰か見てもわかる業務ということに留意しています。 現状はまだ引き継ぎや新たな知財部員の登用という話がないので、わかりやすい効果を発揮しているわけではないのですが、他部門からの問い合わせがあった際は資料だけ渡せば理解してもらえるので、コミュニケーションの効率化には貢献していると思います。 どのような特許を取得すべきなのか 企業としてどのような特許を取得していくべきか、ということは「知財を最大限に活用する」という知財の出口から考えていく上で、重要な事項になります。 そしてどのような特許を取得するかは、事業領域や事業ミッションに沿って設定されるべきです。 メドレーは、オープンプラットフォームによる医療のあり方の変革を目指している企業なので、開発チームから上がってきたアイデアについては、 プラットフォーム事業を適切に運営していく上で必要な技術かどうか 、という観点で特許化するかどうかを判断しています。 例えば、最近特許を取得した**医療データの管理方法（ 特許第 6921177 号 ）**というものがあります。これは、アプリ端末から入力された患者データと、医療機関の各業務システムから入力された患者データという 2 つの類似したデータをシームレスに管理するために、両方のデータを 2 つのデータベース上で統合管理することにより、データ管理の責任分担の明確化及び厳格な情報管理を可能にするというものです。 仕組みとしてはとてもシンプルなのですが、 患者の持つ端末と、医科・歯科・調剤等の各業務システムをシームレスに連携させる仕組みが、医療プラットフォームを適切に運営していく上で必要な技術だと判断 したため、特許化しました。 また、上記事例のように実際にプロダクトに実装されている技術を特許化したものだけでなく、実際にプロダクトに実装するかわからないけれども将来を見据えた先見的な特許として、**ブロックチェーンを用いた電子処方箋の管理方法（ 特許第 6936763 号 ）**という特許を取得しています。 これは、ブロックチェーンを用いたアクセス権の管理機能として全体的に秘密状態を保ちながら電子処方箋を管理するためのアクセス制御に関する仕組みで、ブロックチェーンデータベース上において処方箋データと患者データとを紐づけて、医師端末からの患者レコードへの一時的なアクセス権限を付与し、会計終了時に患者端末の操作に応じて医師端末へのアクセス権限を剥奪するというものです。 このような特許を取得した背景には、 マーケットを独占して権利主張をするためというよりも、メドレーが考える未来のプロダクトビジョンであったり、開発部門の先見的な創作活動を対外的に発信したい 、という思いがあります。 メドレーは、顧客利用率の高いプロダクト、機能拡張性の高いプロダクトの開発を推進しているため、**独創的で最新技術を取り入れた尖った機能を目指すというよりはユーザにとって使いやすいシンプルさが多く取り入れられています。**また、それだけではなく、前述したブロックチェーンと電子処方箋との組み合わせ技術の先見的な特許取得のように、10 年先を見据えた未来のプロダクトのあり方についても日々追求しています。 特許を身近に感じてもらうためのユニークな話も取り入れて社内に啓蒙する いい特許を生み出すためには地道な社内の啓蒙活動も重要です。 メドレーでは、開発チーム間の技術格差の是正や、技術情報の共有による活性化を目的として、エンジニアが日々の業務で扱っている技術や取り組みについて共有するテックランチという勉強会が定期的に開催されています。 先日そのテックランチで、社内のエンジニアの方達に少しでも特許を身近に感じてもらおうと、「特許の頭体操」というコーナーを設けて、実際に頭を使って体験してもらいました。 下の例では、おたまとスプーンとの違いを考えようというお題を通して、ある物の特徴を把握する際に、 「違い」から「もの」を観察すると、その物の特徴が浮き出てくる 、というメッセージが含まれています。 おたまもスプーンも対象物をすくい上げるという機能においては共通しているのですが、おたまの先端のお皿部分とスプーンの先端のお皿部分とは、その形状が異なります。スプーンのお皿部分は楕円形ですが、おたまのお皿部分は円形になっています。 つまり、おたまの特徴は、特許的にいうと「その先端にあるお皿部分が円形の開口を有した半球状で、対象物をすくうための所定の深さを有している」ということになります。 この辺はちょっと固苦しい表現が続いたせいもあり、「難しい…」というコメントをもらいました。馴染みのない人にとってはただただ面倒な作業だと思います。 しかし、ここで言いたかったのは、 これはあくまで構造物についての話であって、ソフトウェアの特徴を把握するということはそんなに難しいことではないのだよ 、ということでした。 ソフトウェアの場合は、ちょっとした機能を追加すれば、それが従来のソフトとは異なるものとなり、比較的簡単に特許になってしまうケースが少なくありません。 つまり、エンジニアの方は日々新しい機能を実装すべく開発業務を行っているわけなので、 知財の観点から言うと、極端なことを言えば日々発明をしている ということになります。当然特許になるかどうかは別の話になりますが、日々の開発業務で自分が発明をしていることに気づいていない、という状況が多分にあるということです。 さらに、 知財担当がこれに気づかなければ、日の目を見ることない埋蔵知財が量産される ということになってしまいます。 では、どのようにしてエンジニアの方が自ら発明をしていることに気づいていないものを発掘し、社内の知的財産として認定していくのか、というのが次の話になります。 面白いアイデアは雑談から生まれる 日々の開発業務の延長で生まれてくる機能や技術を特許化するという活動が基本であることは間違いないのですが、実際にプロダクトに実装するかどうか不確定要素を多く含むアイデアを特許化するという活動は、エンジニアの開発成果物を知的財産として見える化することで、エンジニアの成果が報われる土壌を作るという意味においては大切な活動になってきます。 ただ、どの企業知財部でも発明発掘業務はされていると思いますし、「アイデアは雑談から生まれる」ということは既に周知の事実かもしれません。また、知財活動として特段新しいことをしているわけではないのですが、実際にそれを実行する際の心構えであったり、具体的に気をつけていることについて、事例を通してご紹介したいと思います。 私は、 エンジニアの方というのは、アイデアの卵をもっている という前提に立ってエンジニアの方とコミュニケーションをとるようにしています。 そうすると、「実はアイデアありますよね、なんで言ってくれないんですか〜。」という具合にカジュアルな会話をスタートすることができ、スムーズにブレストを進めることができたりします。大したことではないのですが、 意外とこういう心がけが円滑なコミュニケーションを生み出すきっかけになっている かもしれません。 一方で、エンジニアの方は暇ではありません。 日々の開発では、既存機能の修正や新規機能の開発などの案件に追われるため、頭の中にあるアイデアの卵も埋もれてしまいがちです。 以上のことを踏まえ、エンジニアからアイデアを出してもらうためのブレスト MTG では主に以下の点に気をつけています。 エンジニアの方の負担にならないように短時間に設定すること（長くて 30 分） カジュアルに話しやすい雑談ベースの雰囲気にすること そのために少人数で行うこと 出てきたアイデアを楽しむこと 実際に下図に示すような雑談ベースの会話から、「診療方式を患者と医療機関との間の距離に応じて、対面診療かオンライン診療かを自動的に切り替える」というアイデアが生まれ、実際に特許出願につながりました。 この時にエンジニアの方々からは「とても面白い！」とか「またやりたい！」という前向きなコメントをもらえて、カジュアルベースの雑談効果を実感しました。 このようなブレストを通して一番大きな気づきというのは、エンジニアの皆さん、本当によくプロダクトについて考えているということ。 エンジニアの方々の創意工夫が全て知的財産「権」になるわけではないのですが、知的財産であることには違いありません。 これからは、そういった エンジニアの方の頭の中に埋もれがちな創意・工夫というものが報われるような土壌作りを、知的財産というツールを使って構築していきたい と考えています。 このブログも「特許を対外的にどう見せるか」という実験の１つ ここまでご紹介してきた内容は、知財計画を立てて、立てた計画に沿って知財業務を運用し、運用していく中でアイデア発掘して知財化する、という話にとどまってましたが、実際に取得した知財権をどのように活用して企業価値の向上につなげるのか、ということがこれからの知財部門にとっての重要なミッションになると考えています。 従来は、特許権の独占排他権という性質を使って参入障壁として活用したり、模倣の抑止に活用されるのが常識だったと思いますが、メドレーではこれまでにない新たな活用方法を模索しています。 実はこのブログもそうなのですが、特許を対外的にどうみせるか、ということの１つの実験です。 どういうことかというと、ここまでご紹介してきた 知財活動自体も人の知的活動によって生み出された知的財産であり、このようにブログで発信しなければ単なる埋蔵知財になってしまいます 。 例えば、特許取得についてもただ特許を取ったという事実を公表するのではなく、どうしてそのような特許を取得してどのように活用しているのか、またそこに関連したメンバーは誰でどのような検討があったのか、というストーリーメイキングをすると、特許というものを中心とした１つのドラマが浮き上がってきます。 今回は知財活動のご紹介という趣旨で、特許を中心とした内容になっているため、特許に関心がない人にはあまりささらないコンテンツになっているかもしれませんが、例えば特許と広報との掛け算でストーリーメイキングをすれば 特許に関心がある人だけでなく、広報に関心がある人にも情報がリーチすることになります 。 これは 特許というものが、人材・業務ノウハウ・広報・採用活動等と同列に知的財産である がゆえになせるものです。これからは、知的財産＝特許、商標という視点ではなく、知財＝目に見えない創造的な活動という捉え方をした上で、企業価値に貢献していく必要があります。 知財部門が、採用、IR、広報、開発、社内 IT といった企業内にある多数の部門とコラボレーションすることでこれまで見たことのない新しい知財活用の形を模索し、 知財を最大活用することによって企業価値を向上させていきたい と考えています。 さいごに ここまで、知財活動の一部をご紹介させていただきましたが、これが知財活動の進め方として正解というわけではなく、企業風土や事業領域によって、知財活動のあり方は異なります。そして、そこを考えながら知財活動を推進していくことが仕事の面白さであり醍醐味とも言えます。新しい知財部のあり方や、新しい知的財産の活用方法を検証しながらも、建設的かつ柔軟に日々の業務を進め、メドレーの事業をしっかりとバックアップしていきたいと考えています。少しでも当社の知財活動が参考になれば幸いです。最後までお付き合い頂きありがとうございました！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは、メドレーのコーポレート本部法務コンプライアンス部で、知的財産関連の業務を担当している鬼鞍です。 1 年ほど前に本ブログで「 特許とはなにか 」というテーマで当社における特許啓蒙活動を紹介させて頂いたのですが、思っていた以上に反響があり、「面白い」とか「わかりやすい」という嬉しいコメントも頂戴しました。 私がメドレーに入社して最初のミッションが知財部門の立ち上げだったので、次はぜひ**「ベンチャーでの知財部門の立ち上げ方」**的なテーマでブログ発信したいと思っていたのですが、当初はまだ具体的な社内事例が少なかったため、実績ができた段階で改めて本ブログで発表したいと思っていました。 それから１年以上が経過して実際に特許も取得するなど知財活動としての実績が蓄積されてきたため、これを機会に ベンチャーで知財部門を立ち上げる際にやるべきことについて、実例に触れながら具体的にまとめてみました。 かなり長いコンテンツになってしまいましたが、 フェーズごとの知財活動計画 であったり、 知財ロードマップの作り方 など、 なかなか表に出てこない知財部門立ち上げストーリーの具体的事例を惜しみなく書かせていただいております ので、ぜひご一読いただき、お役に立てれば幸いです。 知財は開発チームとの信頼関係の構築がまず第一 先ほどは知財部門を立ち上げストーリの中で、知財活動計画とか、知財ロードマップであるとか少し格好つけたような文字が羅列していましたが、実は私が知財専任として初めに配置されて最初にやったことはそんな大それたことではありませんでした。 最初になにをやったかというと、 エンジニアの方とランチに行く、あるいは飲みに行く 、ということでした。当時はまだ Covid-19 が蔓延する前だったので気軽にそういうことができました。入社して最初の 1 ヶ月くらいは週 2 回くらいのペースで誰かとランチか飲みにいくということをしていたと思います。 飲みに行く、というとふざけているとか思われるかもしれませんが、知財部門の立ち上げストーリーを語る上で、このプロセスは無視できないほど重要だと考えています。先に断っておくと私は酒好きでもなければ、家でも一切飲みません。 当たり前のことなのですが、知財というのはプロダクトを生み出す開発組織があって初めて価値を発揮するものです。知財はあくまで事業や開発をサポートするところであって、それ単体で存在意義を発揮することはほぼありません。特に特許活動については開発チームとの連携が非常に重要です。 一緒にご飯を食べることが信頼関係を構築する上で最良の方法、とまでは言いませんが、少なくともご飯を食べない人はいないわけで、時間を無駄にしている感もなければ、オフィスの外で会えば仕事以外のことを話題にし易いので互いの趣味嗜好を知ることができます。みなさんもそうだと思いますが、通常、仲の悪い人とは一緒に食事はしないと思います。 特に、この後にもご紹介する 社内のアイデアを発掘するという発明発掘活動は、話しやすいカジュアルな雰囲気で雑談のような感じでブレストするというのが非常に重要 で、このときに相手がどんな人間かを互いに知っているか、知らないかでは大きな差がでてきます。 また更に、この後にご紹介する知財計画立案や知財ロードマップを作成することも当然重要なのですが、結局仕事というのは人と人との間を思考がやりとりされて実現化されていくものなので、人間関係・信頼関係が全ての基礎であり、実は一番大切にするべきものだと思います。 これは何も知財に限ったことではなく、部門を跨いで仕事をする上で信頼関係は非常に重要ですし、知財の観点で見ても 円滑なコミュニケーションが結果的にいい発明やアイデアを生み出すための土壌づくりに貢献する ものだと考えています。 知財活動計画は、事業の成長フェーズに合わせて設定する 知財部門の設立にあたって、エンジニアとのコミュニケーションと並行して進めたのが、知財活動計画の立案でした。知財活動とは、知財サイクルをうまく事業サイクルにインストールしてサイクルを循環させることであり、更にはこのサイクルが循環するための運用基盤を構築することを指します。また、ここでいう知財サイクルとは、例えば、社内に埋もれたアイデアを発掘し（創発）→ それを知財権化し（保護）→ 権利化した知財を活用し（活用）→ 活用した知財で得られた利益や結果を創発支援に適用できる形に変換する、というものです。 このような知財サイクルを、何の計画や戦略もなしに事業サイクルへインストールしようとするとうまくいきません。なぜなら、事業というのは日々成長し変化していくもので、 事業の成長に応じて知財活動の目的や課題も変化するからです 。 例えば、子会社が増えて事業規模が拡大すると、その子会社の事業領域で既に多くの特許出願がされている場合には、発明発掘活動よりもまずは法的リスクを回避することを最優先にして、他社の特許調査をしっかりやってからプロダクトをリリースする仕組みを作ろう、ということになります。あるいは、事業の成長に伴いプロダクトが成熟してきた場面では、似たようなプロダクトが乱立する結果、尖った機能や最先端技術で差別化をするようになるため、こうした場合には先行した特許取得が重要な目的になってきます。 このように、事業の成長フェーズに応じた知財活動の計画を立案するべく、まずはメドレーのミッションおよびそのミッションを実現するためのプロダクトの性質を把握する必要がありました。 メドレーは「医療ヘルスケアの未来をつくる」というミッションを掲げ、インターネットテクノロジーによる医療のあり方の変革を目指す企業です。 このミッションと向き合いつつ、 事業プラットフォームの成長フェーズごとに知財活動の方向性・目的を３段階にわけて設定し、成長フェーズごとに知財活動計画を立案しました 。 例えば、プラットフォームの創設期においては新規ユーザ獲得が重要となり、使い勝手のいいシンプルな機能に開発の方向性が向いているため、独自性のある技術を特許化するというよりも、まずは守りを固めるべく知財権侵害のリスクを最小限にして法的安定性の確保に軸足を置いた知財活動を推進します。 このような計画は、知財の観点で一方的にできるものではありません。 知財活動の計画に際しては、開発チームを統括するマネージャにプロダクト開発の方向性をヒアリングして特許取得の判断基準を検討したり、経営層に将来の事業の方向性についてヒアリングをして長期志向で目標設定したりして、ブラッシュアップしていきました。 そういった検討や議論を重ねていくうちに自然と、その企業風土や事業ミッションにあった知財活動計画というものができあがってくるのだと思います。 知財活動ロードマップで現在位置を把握しつつ定期的に軌道修正する 長期的な方向性を可視化したら次はそれをどう実行するかという実行計画が必要になってきました。 そもそも自分たちは今何ができていて、何ができていないのか。またどのようなことを今後やっていかなければならないのかが不明確だよね、という話になり、それを具体的に俯瞰するための知財ロードマッピングというものを作成しました。 縦軸に知的財産の種類、横軸に時間軸であるフェーズを設定して、知財活動の内容に過不足ないかをチェックできるようにしました。 定期的に内容を見直してメドレーの事業規模にあった形に修正しながら自分達の現在位置を把握し、今後の方向性を見定めるためのツールとして有効でした。 このようなロードマップがあれば、知財担当者の立場からすると、実績が可視化されるため知財活動を推進していく上での達成感もありますし、逆に知財担当者を評価する立場からしても、明確な評価基準がない中で、知財担当者の評価をする際に役に立ちます。 以上のように、何もないところから他部門と関わりながら知財活動計画を立案し、ロードマップを達成していくのは、知財部門を立ち上げるという業務の面白さの１つでもあります。 初期段階から長期視点で知財素人でも回せる業務運用作りをする 1 人法務や 1 人知財担当という状況は、遅かれ早かれ属人化という問題が必ずやってきます。 属人化は組織運営上、健全ではありません。 そのため、 知財に関する知識がない人間でも、誰でもその業務を回すことができるような状態をつくる ために、知財部門立ち上げの初期段階から、自分が担当している業務でルーチン化できるものは全て仕組み化してドキュメントに落とし込むようにしていました。 例えば「怪しい特許を見つけた場合の動き方」、「発明報奨金の決定プロセス」、「他社特許調査及び発明発掘のハイブリッド調査の進め方」などなど、ありとあらゆるプロセス業務を全てフロー図や概念図を作成し、誰か見てもわかる業務ということに留意しています。 現状はまだ引き継ぎや新たな知財部員の登用という話がないので、わかりやすい効果を発揮しているわけではないのですが、他部門からの問い合わせがあった際は資料だけ渡せば理解してもらえるので、コミュニケーションの効率化には貢献していると思います。 どのような特許を取得すべきなのか 企業としてどのような特許を取得していくべきか、ということは「知財を最大限に活用する」という知財の出口から考えていく上で、重要な事項になります。 そしてどのような特許を取得するかは、事業領域や事業ミッションに沿って設定されるべきです。 メドレーは、オープンプラットフォームによる医療のあり方の変革を目指している企業なので、開発チームから上がってきたアイデアについては、 プラットフォーム事業を適切に運営していく上で必要な技術かどうか 、という観点で特許化するかどうかを判断しています。 例えば、最近特許を取得した**医療データの管理方法（ 特許第 6921177 号 ）**というものがあります。これは、アプリ端末から入力された患者データと、医療機関の各業務システムから入力された患者データという 2 つの類似したデータをシームレスに管理するために、両方のデータを 2 つのデータベース上で統合管理することにより、データ管理の責任分担の明確化及び厳格な情報管理を可能にするというものです。 仕組みとしてはとてもシンプルなのですが、 患者の持つ端末と、医科・歯科・調剤等の各業務システムをシームレスに連携させる仕組みが、医療プラットフォームを適切に運営していく上で必要な技術だと判断 したため、特許化しました。 また、上記事例のように実際にプロダクトに実装されている技術を特許化したものだけでなく、実際にプロダクトに実装するかわからないけれども将来を見据えた先見的な特許として、**ブロックチェーンを用いた電子処方箋の管理方法（ 特許第 6936763 号 ）**という特許を取得しています。 これは、ブロックチェーンを用いたアクセス権の管理機能として全体的に秘密状態を保ちながら電子処方箋を管理するためのアクセス制御に関する仕組みで、ブロックチェーンデータベース上において処方箋データと患者データとを紐づけて、医師端末からの患者レコードへの一時的なアクセス権限を付与し、会計終了時に患者端末の操作に応じて医師端末へのアクセス権限を剥奪するというものです。 このような特許を取得した背景には、 マーケットを独占して権利主張をするためというよりも、メドレーが考える未来のプロダクトビジョンであったり、開発部門の先見的な創作活動を対外的に発信したい 、という思いがあります。 メドレーは、顧客利用率の高いプロダクト、機能拡張性の高いプロダクトの開発を推進しているため、**独創的で最新技術を取り入れた尖った機能を目指すというよりはユーザにとって使いやすいシンプルさが多く取り入れられています。**また、それだけではなく、前述したブロックチェーンと電子処方箋との組み合わせ技術の先見的な特許取得のように、10 年先を見据えた未来のプロダクトのあり方についても日々追求しています。 特許を身近に感じてもらうためのユニークな話も取り入れて社内に啓蒙する いい特許を生み出すためには地道な社内の啓蒙活動も重要です。 メドレーでは、開発チーム間の技術格差の是正や、技術情報の共有による活性化を目的として、エンジニアが日々の業務で扱っている技術や取り組みについて共有するテックランチという勉強会が定期的に開催されています。 先日そのテックランチで、社内のエンジニアの方達に少しでも特許を身近に感じてもらおうと、「特許の頭体操」というコーナーを設けて、実際に頭を使って体験してもらいました。 下の例では、おたまとスプーンとの違いを考えようというお題を通して、ある物の特徴を把握する際に、 「違い」から「もの」を観察すると、その物の特徴が浮き出てくる 、というメッセージが含まれています。 おたまもスプーンも対象物をすくい上げるという機能においては共通しているのですが、おたまの先端のお皿部分とスプーンの先端のお皿部分とは、その形状が異なります。スプーンのお皿部分は楕円形ですが、おたまのお皿部分は円形になっています。 つまり、おたまの特徴は、特許的にいうと「その先端にあるお皿部分が円形の開口を有した半球状で、対象物をすくうための所定の深さを有している」ということになります。 この辺はちょっと固苦しい表現が続いたせいもあり、「難しい…」というコメントをもらいました。馴染みのない人にとってはただただ面倒な作業だと思います。 しかし、ここで言いたかったのは、 これはあくまで構造物についての話であって、ソフトウェアの特徴を把握するということはそんなに難しいことではないのだよ 、ということでした。 ソフトウェアの場合は、ちょっとした機能を追加すれば、それが従来のソフトとは異なるものとなり、比較的簡単に特許になってしまうケースが少なくありません。 つまり、エンジニアの方は日々新しい機能を実装すべく開発業務を行っているわけなので、 知財の観点から言うと、極端なことを言えば日々発明をしている ということになります。当然特許になるかどうかは別の話になりますが、日々の開発業務で自分が発明をしていることに気づいていない、という状況が多分にあるということです。 さらに、 知財担当がこれに気づかなければ、日の目を見ることない埋蔵知財が量産される ということになってしまいます。 では、どのようにしてエンジニアの方が自ら発明をしていることに気づいていないものを発掘し、社内の知的財産として認定していくのか、というのが次の話になります。 面白いアイデアは雑談から生まれる 日々の開発業務の延長で生まれてくる機能や技術を特許化するという活動が基本であることは間違いないのですが、実際にプロダクトに実装するかどうか不確定要素を多く含むアイデアを特許化するという活動は、エンジニアの開発成果物を知的財産として見える化することで、エンジニアの成果が報われる土壌を作るという意味においては大切な活動になってきます。 ただ、どの企業知財部でも発明発掘業務はされていると思いますし、「アイデアは雑談から生まれる」ということは既に周知の事実かもしれません。また、知財活動として特段新しいことをしているわけではないのですが、実際にそれを実行する際の心構えであったり、具体的に気をつけていることについて、事例を通してご紹介したいと思います。 私は、 エンジニアの方というのは、アイデアの卵をもっている という前提に立ってエンジニアの方とコミュニケーションをとるようにしています。 そうすると、「実はアイデアありますよね、なんで言ってくれないんですか〜。」という具合にカジュアルな会話をスタートすることができ、スムーズにブレストを進めることができたりします。大したことではないのですが、 意外とこういう心がけが円滑なコミュニケーションを生み出すきっかけになっている かもしれません。 一方で、エンジニアの方は暇ではありません。 日々の開発では、既存機能の修正や新規機能の開発などの案件に追われるため、頭の中にあるアイデアの卵も埋もれてしまいがちです。 以上のことを踏まえ、エンジニアからアイデアを出してもらうためのブレスト MTG では主に以下の点に気をつけています。 エンジニアの方の負担にならないように短時間に設定すること（長くて 30 分） カジュアルに話しやすい雑談ベースの雰囲気にすること そのために少人数で行うこと 出てきたアイデアを楽しむこと 実際に下図に示すような雑談ベースの会話から、「診療方式を患者と医療機関との間の距離に応じて、対面診療かオンライン診療かを自動的に切り替える」というアイデアが生まれ、実際に特許出願につながりました。 この時にエンジニアの方々からは「とても面白い！」とか「またやりたい！」という前向きなコメントをもらえて、カジュアルベースの雑談効果を実感しました。 このようなブレストを通して一番大きな気づきというのは、エンジニアの皆さん、本当によくプロダクトについて考えているということ。 エンジニアの方々の創意工夫が全て知的財産「権」になるわけではないのですが、知的財産であることには違いありません。 これからは、そういった エンジニアの方の頭の中に埋もれがちな創意・工夫というものが報われるような土壌作りを、知的財産というツールを使って構築していきたい と考えています。 このブログも「特許を対外的にどう見せるか」という実験の１つ ここまでご紹介してきた内容は、知財計画を立てて、立てた計画に沿って知財業務を運用し、運用していく中でアイデア発掘して知財化する、という話にとどまってましたが、実際に取得した知財権をどのように活用して企業価値の向上につなげるのか、ということがこれからの知財部門にとっての重要なミッションになると考えています。 従来は、特許権の独占排他権という性質を使って参入障壁として活用したり、模倣の抑止に活用されるのが常識だったと思いますが、メドレーではこれまでにない新たな活用方法を模索しています。 実はこのブログもそうなのですが、特許を対外的にどうみせるか、ということの１つの実験です。 どういうことかというと、ここまでご紹介してきた 知財活動自体も人の知的活動によって生み出された知的財産であり、このようにブログで発信しなければ単なる埋蔵知財になってしまいます 。 例えば、特許取得についてもただ特許を取ったという事実を公表するのではなく、どうしてそのような特許を取得してどのように活用しているのか、またそこに関連したメンバーは誰でどのような検討があったのか、というストーリーメイキングをすると、特許というものを中心とした１つのドラマが浮き上がってきます。 今回は知財活動のご紹介という趣旨で、特許を中心とした内容になっているため、特許に関心がない人にはあまりささらないコンテンツになっているかもしれませんが、例えば特許と広報との掛け算でストーリーメイキングをすれば 特許に関心がある人だけでなく、広報に関心がある人にも情報がリーチすることになります 。 これは 特許というものが、人材・業務ノウハウ・広報・採用活動等と同列に知的財産である がゆえになせるものです。これからは、知的財産＝特許、商標という視点ではなく、知財＝目に見えない創造的な活動という捉え方をした上で、企業価値に貢献していく必要があります。 知財部門が、採用、IR、広報、開発、社内 IT といった企業内にある多数の部門とコラボレーションすることでこれまで見たことのない新しい知財活用の形を模索し、 知財を最大活用することによって企業価値を向上させていきたい と考えています。 さいごに ここまで、知財活動の一部をご紹介させていただきましたが、これが知財活動の進め方として正解というわけではなく、企業風土や事業領域によって、知財活動のあり方は異なります。そして、そこを考えながら知財活動を推進していくことが仕事の面白さであり醍醐味とも言えます。新しい知財部のあり方や、新しい知的財産の活用方法を検証しながらも、建設的かつ柔軟に日々の業務を進め、メドレーの事業をしっかりとバックアップしていきたいと考えています。少しでも当社の知財活動が参考になれば幸いです。最後までお付き合い頂きありがとうございました！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは、メドレーのコーポレート本部法務コンプライアンス部で、知的財産関連の業務を担当している鬼鞍です。 1 年ほど前に本ブログで「 特許とはなにか 」というテーマで当社における特許啓蒙活動を紹介させて頂いたのですが、思っていた以上に反響があり、「面白い」とか「わかりやすい」という嬉しいコメントも頂戴しました。 私がメドレーに入社して最初のミッションが知財部門の立ち上げだったので、次はぜひ**「ベンチャーでの知財部門の立ち上げ方」**的なテーマでブログ発信したいと思っていたのですが、当初はまだ具体的な社内事例が少なかったため、実績ができた段階で改めて本ブログで発表したいと思っていました。 それから１年以上が経過して実際に特許も取得するなど知財活動としての実績が蓄積されてきたため、これを機会に ベンチャーで知財部門を立ち上げる際にやるべきことについて、実例に触れながら具体的にまとめてみました。 かなり長いコンテンツになってしまいましたが、 フェーズごとの知財活動計画 であったり、 知財ロードマップの作り方 など、 なかなか表に出てこない知財部門立ち上げストーリーの具体的事例を惜しみなく書かせていただいております ので、ぜひご一読いただき、お役に立てれば幸いです。 知財は開発チームとの信頼関係の構築がまず第一 先ほどは知財部門を立ち上げストーリの中で、知財活動計画とか、知財ロードマップであるとか少し格好つけたような文字が羅列していましたが、実は私が知財専任として初めに配置されて最初にやったことはそんな大それたことではありませんでした。 最初になにをやったかというと、 エンジニアの方とランチに行く、あるいは飲みに行く 、ということでした。当時はまだ Covid-19 が蔓延する前だったので気軽にそういうことができました。入社して最初の 1 ヶ月くらいは週 2 回くらいのペースで誰かとランチか飲みにいくということをしていたと思います。 飲みに行く、というとふざけているとか思われるかもしれませんが、知財部門の立ち上げストーリーを語る上で、このプロセスは無視できないほど重要だと考えています。先に断っておくと私は酒好きでもなければ、家でも一切飲みません。 当たり前のことなのですが、知財というのはプロダクトを生み出す開発組織があって初めて価値を発揮するものです。知財はあくまで事業や開発をサポートするところであって、それ単体で存在意義を発揮することはほぼありません。特に特許活動については開発チームとの連携が非常に重要です。 一緒にご飯を食べることが信頼関係を構築する上で最良の方法、とまでは言いませんが、少なくともご飯を食べない人はいないわけで、時間を無駄にしている感もなければ、オフィスの外で会えば仕事以外のことを話題にし易いので互いの趣味嗜好を知ることができます。みなさんもそうだと思いますが、通常、仲の悪い人とは一緒に食事はしないと思います。 特に、この後にもご紹介する 社内のアイデアを発掘するという発明発掘活動は、話しやすいカジュアルな雰囲気で雑談のような感じでブレストするというのが非常に重要 で、このときに相手がどんな人間かを互いに知っているか、知らないかでは大きな差がでてきます。 また更に、この後にご紹介する知財計画立案や知財ロードマップを作成することも当然重要なのですが、結局仕事というのは人と人との間を思考がやりとりされて実現化されていくものなので、人間関係・信頼関係が全ての基礎であり、実は一番大切にするべきものだと思います。 これは何も知財に限ったことではなく、部門を跨いで仕事をする上で信頼関係は非常に重要ですし、知財の観点で見ても 円滑なコミュニケーションが結果的にいい発明やアイデアを生み出すための土壌づくりに貢献する ものだと考えています。 知財活動計画は、事業の成長フェーズに合わせて設定する 知財部門の設立にあたって、エンジニアとのコミュニケーションと並行して進めたのが、知財活動計画の立案でした。知財活動とは、知財サイクルをうまく事業サイクルにインストールしてサイクルを循環させることであり、更にはこのサイクルが循環するための運用基盤を構築することを指します。また、ここでいう知財サイクルとは、例えば、社内に埋もれたアイデアを発掘し（創発）→ それを知財権化し（保護）→ 権利化した知財を活用し（活用）→ 活用した知財で得られた利益や結果を創発支援に適用できる形に変換する、というものです。 このような知財サイクルを、何の計画や戦略もなしに事業サイクルへインストールしようとするとうまくいきません。なぜなら、事業というのは日々成長し変化していくもので、 事業の成長に応じて知財活動の目的や課題も変化するからです 。 例えば、子会社が増えて事業規模が拡大すると、その子会社の事業領域で既に多くの特許出願がされている場合には、発明発掘活動よりもまずは法的リスクを回避することを最優先にして、他社の特許調査をしっかりやってからプロダクトをリリースする仕組みを作ろう、ということになります。あるいは、事業の成長に伴いプロダクトが成熟してきた場面では、似たようなプロダクトが乱立する結果、尖った機能や最先端技術で差別化をするようになるため、こうした場合には先行した特許取得が重要な目的になってきます。 このように、事業の成長フェーズに応じた知財活動の計画を立案するべく、まずはメドレーのミッションおよびそのミッションを実現するためのプロダクトの性質を把握する必要がありました。 メドレーは「医療ヘルスケアの未来をつくる」というミッションを掲げ、インターネットテクノロジーによる医療のあり方の変革を目指す企業です。 このミッションと向き合いつつ、 事業プラットフォームの成長フェーズごとに知財活動の方向性・目的を３段階にわけて設定し、成長フェーズごとに知財活動計画を立案しました 。 例えば、プラットフォームの創設期においては新規ユーザ獲得が重要となり、使い勝手のいいシンプルな機能に開発の方向性が向いているため、独自性のある技術を特許化するというよりも、まずは守りを固めるべく知財権侵害のリスクを最小限にして法的安定性の確保に軸足を置いた知財活動を推進します。 このような計画は、知財の観点で一方的にできるものではありません。 知財活動の計画に際しては、開発チームを統括するマネージャにプロダクト開発の方向性をヒアリングして特許取得の判断基準を検討したり、経営層に将来の事業の方向性についてヒアリングをして長期志向で目標設定したりして、ブラッシュアップしていきました。 そういった検討や議論を重ねていくうちに自然と、その企業風土や事業ミッションにあった知財活動計画というものができあがってくるのだと思います。 知財活動ロードマップで現在位置を把握しつつ定期的に軌道修正する 長期的な方向性を可視化したら次はそれをどう実行するかという実行計画が必要になってきました。 そもそも自分たちは今何ができていて、何ができていないのか。またどのようなことを今後やっていかなければならないのかが不明確だよね、という話になり、それを具体的に俯瞰するための知財ロードマッピングというものを作成しました。 縦軸に知的財産の種類、横軸に時間軸であるフェーズを設定して、知財活動の内容に過不足ないかをチェックできるようにしました。 定期的に内容を見直してメドレーの事業規模にあった形に修正しながら自分達の現在位置を把握し、今後の方向性を見定めるためのツールとして有効でした。 このようなロードマップがあれば、知財担当者の立場からすると、実績が可視化されるため知財活動を推進していく上での達成感もありますし、逆に知財担当者を評価する立場からしても、明確な評価基準がない中で、知財担当者の評価をする際に役に立ちます。 以上のように、何もないところから他部門と関わりながら知財活動計画を立案し、ロードマップを達成していくのは、知財部門を立ち上げるという業務の面白さの１つでもあります。 初期段階から長期視点で知財素人でも回せる業務運用作りをする 1 人法務や 1 人知財担当という状況は、遅かれ早かれ属人化という問題が必ずやってきます。 属人化は組織運営上、健全ではありません。 そのため、 知財に関する知識がない人間でも、誰でもその業務を回すことができるような状態をつくる ために、知財部門立ち上げの初期段階から、自分が担当している業務でルーチン化できるものは全て仕組み化してドキュメントに落とし込むようにしていました。 例えば「怪しい特許を見つけた場合の動き方」、「発明報奨金の決定プロセス」、「他社特許調査及び発明発掘のハイブリッド調査の進め方」などなど、ありとあらゆるプロセス業務を全てフロー図や概念図を作成し、誰か見てもわかる業務ということに留意しています。 現状はまだ引き継ぎや新たな知財部員の登用という話がないので、わかりやすい効果を発揮しているわけではないのですが、他部門からの問い合わせがあった際は資料だけ渡せば理解してもらえるので、コミュニケーションの効率化には貢献していると思います。 どのような特許を取得すべきなのか 企業としてどのような特許を取得していくべきか、ということは「知財を最大限に活用する」という知財の出口から考えていく上で、重要な事項になります。 そしてどのような特許を取得するかは、事業領域や事業ミッションに沿って設定されるべきです。 メドレーは、オープンプラットフォームによる医療のあり方の変革を目指している企業なので、開発チームから上がってきたアイデアについては、 プラットフォーム事業を適切に運営していく上で必要な技術かどうか 、という観点で特許化するかどうかを判断しています。 例えば、最近特許を取得した**医療データの管理方法（ 特許第 6921177 号 ）**というものがあります。これは、アプリ端末から入力された患者データと、医療機関の各業務システムから入力された患者データという 2 つの類似したデータをシームレスに管理するために、両方のデータを 2 つのデータベース上で統合管理することにより、データ管理の責任分担の明確化及び厳格な情報管理を可能にするというものです。 仕組みとしてはとてもシンプルなのですが、 患者の持つ端末と、医科・歯科・調剤等の各業務システムをシームレスに連携させる仕組みが、医療プラットフォームを適切に運営していく上で必要な技術だと判断 したため、特許化しました。 また、上記事例のように実際にプロダクトに実装されている技術を特許化したものだけでなく、実際にプロダクトに実装するかわからないけれども将来を見据えた先見的な特許として、**ブロックチェーンを用いた電子処方箋の管理方法（ 特許第 6936763 号 ）**という特許を取得しています。 これは、ブロックチェーンを用いたアクセス権の管理機能として全体的に秘密状態を保ちながら電子処方箋を管理するためのアクセス制御に関する仕組みで、ブロックチェーンデータベース上において処方箋データと患者データとを紐づけて、医師端末からの患者レコードへの一時的なアクセス権限を付与し、会計終了時に患者端末の操作に応じて医師端末へのアクセス権限を剥奪するというものです。 このような特許を取得した背景には、 マーケットを独占して権利主張をするためというよりも、メドレーが考える未来のプロダクトビジョンであったり、開発部門の先見的な創作活動を対外的に発信したい 、という思いがあります。 メドレーは、顧客利用率の高いプロダクト、機能拡張性の高いプロダクトの開発を推進しているため、**独創的で最新技術を取り入れた尖った機能を目指すというよりはユーザにとって使いやすいシンプルさが多く取り入れられています。**また、それだけではなく、前述したブロックチェーンと電子処方箋との組み合わせ技術の先見的な特許取得のように、10 年先を見据えた未来のプロダクトのあり方についても日々追求しています。 特許を身近に感じてもらうためのユニークな話も取り入れて社内に啓蒙する いい特許を生み出すためには地道な社内の啓蒙活動も重要です。 メドレーでは、開発チーム間の技術格差の是正や、技術情報の共有による活性化を目的として、エンジニアが日々の業務で扱っている技術や取り組みについて共有するテックランチという勉強会が定期的に開催されています。 先日そのテックランチで、社内のエンジニアの方達に少しでも特許を身近に感じてもらおうと、「特許の頭体操」というコーナーを設けて、実際に頭を使って体験してもらいました。 下の例では、おたまとスプーンとの違いを考えようというお題を通して、ある物の特徴を把握する際に、 「違い」から「もの」を観察すると、その物の特徴が浮き出てくる 、というメッセージが含まれています。 おたまもスプーンも対象物をすくい上げるという機能においては共通しているのですが、おたまの先端のお皿部分とスプーンの先端のお皿部分とは、その形状が異なります。スプーンのお皿部分は楕円形ですが、おたまのお皿部分は円形になっています。 つまり、おたまの特徴は、特許的にいうと「その先端にあるお皿部分が円形の開口を有した半球状で、対象物をすくうための所定の深さを有している」ということになります。 この辺はちょっと固苦しい表現が続いたせいもあり、「難しい…」というコメントをもらいました。馴染みのない人にとってはただただ面倒な作業だと思います。 しかし、ここで言いたかったのは、 これはあくまで構造物についての話であって、ソフトウェアの特徴を把握するということはそんなに難しいことではないのだよ 、ということでした。 ソフトウェアの場合は、ちょっとした機能を追加すれば、それが従来のソフトとは異なるものとなり、比較的簡単に特許になってしまうケースが少なくありません。 つまり、エンジニアの方は日々新しい機能を実装すべく開発業務を行っているわけなので、 知財の観点から言うと、極端なことを言えば日々発明をしている ということになります。当然特許になるかどうかは別の話になりますが、日々の開発業務で自分が発明をしていることに気づいていない、という状況が多分にあるということです。 さらに、 知財担当がこれに気づかなければ、日の目を見ることない埋蔵知財が量産される ということになってしまいます。 では、どのようにしてエンジニアの方が自ら発明をしていることに気づいていないものを発掘し、社内の知的財産として認定していくのか、というのが次の話になります。 面白いアイデアは雑談から生まれる 日々の開発業務の延長で生まれてくる機能や技術を特許化するという活動が基本であることは間違いないのですが、実際にプロダクトに実装するかどうか不確定要素を多く含むアイデアを特許化するという活動は、エンジニアの開発成果物を知的財産として見える化することで、エンジニアの成果が報われる土壌を作るという意味においては大切な活動になってきます。 ただ、どの企業知財部でも発明発掘業務はされていると思いますし、「アイデアは雑談から生まれる」ということは既に周知の事実かもしれません。また、知財活動として特段新しいことをしているわけではないのですが、実際にそれを実行する際の心構えであったり、具体的に気をつけていることについて、事例を通してご紹介したいと思います。 私は、 エンジニアの方というのは、アイデアの卵をもっている という前提に立ってエンジニアの方とコミュニケーションをとるようにしています。 そうすると、「実はアイデアありますよね、なんで言ってくれないんですか〜。」という具合にカジュアルな会話をスタートすることができ、スムーズにブレストを進めることができたりします。大したことではないのですが、 意外とこういう心がけが円滑なコミュニケーションを生み出すきっかけになっている かもしれません。 一方で、エンジニアの方は暇ではありません。 日々の開発では、既存機能の修正や新規機能の開発などの案件に追われるため、頭の中にあるアイデアの卵も埋もれてしまいがちです。 以上のことを踏まえ、エンジニアからアイデアを出してもらうためのブレスト MTG では主に以下の点に気をつけています。 エンジニアの方の負担にならないように短時間に設定すること（長くて 30 分） カジュアルに話しやすい雑談ベースの雰囲気にすること そのために少人数で行うこと 出てきたアイデアを楽しむこと 実際に下図に示すような雑談ベースの会話から、「診療方式を患者と医療機関との間の距離に応じて、対面診療かオンライン診療かを自動的に切り替える」というアイデアが生まれ、実際に特許出願につながりました。 この時にエンジニアの方々からは「とても面白い！」とか「またやりたい！」という前向きなコメントをもらえて、カジュアルベースの雑談効果を実感しました。 このようなブレストを通して一番大きな気づきというのは、エンジニアの皆さん、本当によくプロダクトについて考えているということ。 エンジニアの方々の創意工夫が全て知的財産「権」になるわけではないのですが、知的財産であることには違いありません。 これからは、そういった エンジニアの方の頭の中に埋もれがちな創意・工夫というものが報われるような土壌作りを、知的財産というツールを使って構築していきたい と考えています。 このブログも「特許を対外的にどう見せるか」という実験の１つ ここまでご紹介してきた内容は、知財計画を立てて、立てた計画に沿って知財業務を運用し、運用していく中でアイデア発掘して知財化する、という話にとどまってましたが、実際に取得した知財権をどのように活用して企業価値の向上につなげるのか、ということがこれからの知財部門にとっての重要なミッションになると考えています。 従来は、特許権の独占排他権という性質を使って参入障壁として活用したり、模倣の抑止に活用されるのが常識だったと思いますが、メドレーではこれまでにない新たな活用方法を模索しています。 実はこのブログもそうなのですが、特許を対外的にどうみせるか、ということの１つの実験です。 どういうことかというと、ここまでご紹介してきた 知財活動自体も人の知的活動によって生み出された知的財産であり、このようにブログで発信しなければ単なる埋蔵知財になってしまいます 。 例えば、特許取得についてもただ特許を取ったという事実を公表するのではなく、どうしてそのような特許を取得してどのように活用しているのか、またそこに関連したメンバーは誰でどのような検討があったのか、というストーリーメイキングをすると、特許というものを中心とした１つのドラマが浮き上がってきます。 今回は知財活動のご紹介という趣旨で、特許を中心とした内容になっているため、特許に関心がない人にはあまりささらないコンテンツになっているかもしれませんが、例えば特許と広報との掛け算でストーリーメイキングをすれば 特許に関心がある人だけでなく、広報に関心がある人にも情報がリーチすることになります 。 これは 特許というものが、人材・業務ノウハウ・広報・採用活動等と同列に知的財産である がゆえになせるものです。これからは、知的財産＝特許、商標という視点ではなく、知財＝目に見えない創造的な活動という捉え方をした上で、企業価値に貢献していく必要があります。 知財部門が、採用、IR、広報、開発、社内 IT といった企業内にある多数の部門とコラボレーションすることでこれまで見たことのない新しい知財活用の形を模索し、 知財を最大活用することによって企業価値を向上させていきたい と考えています。 さいごに ここまで、知財活動の一部をご紹介させていただきましたが、これが知財活動の進め方として正解というわけではなく、企業風土や事業領域によって、知財活動のあり方は異なります。そして、そこを考えながら知財活動を推進していくことが仕事の面白さであり醍醐味とも言えます。新しい知財部のあり方や、新しい知的財産の活用方法を検証しながらも、建設的かつ柔軟に日々の業務を進め、メドレーの事業をしっかりとバックアップしていきたいと考えています。少しでも当社の知財活動が参考になれば幸いです。最後までお付き合い頂きありがとうございました！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 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 への移行を完了させることができました。 スティーブ・ジョブズは数分のプレゼン発表のために数百時間の準備をしていたといいます。プレゼンで言うところのシナリオの作成とリハーサルの実行もそうですが、サービス特性の理解や検証を綿密に行うことも本番を成功させるためには欠かせません。準備を怠らないエンジニアでありたい、と執筆しながら改めて感じているところです。 さいごに メドレーでは「医療ヘルスケアの未来をつくる」というミッション実現のため、日々開発・運営を行っています。エンジニア・デザイナーをはじめ多くのポジションでメンバーを募集しております。もし少しでもご興味をお持ちいただけましたら、ぜひお気軽にお話しさせていただければと思います。 最後までお読みいただき、ありがとうございました。 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

こんにちは、人材プラットフォーム本部 プロダクト開発室 第一開発グループ所属の森川です。医療介護求人サイト「 ジョブメドレー 」の開発チームの一員として、現在はインフラタスクをメインに取り組んでいます。 今年（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 年度新卒エンジニア研修について 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