皆様こんにちは。インキュベーション本部エンジニアの濱中です。 9/19〜21 に iOSDC Japan 2020 （以下 iOSDC）が開催されました。 先日の記事 の通り、メドレーは 2017 年より iOSDC に 協賛 しております。 メドレーでは、Swift を利用してオンライン診療／服薬指導アプリ「CLINICS」iOS 版の開発をしています。 CLINICS(クリニクス)　オンライン診療・服薬指導アプリ 5 回目となる今回は、初のオンライン開催となり、主にニコニコ生放送、Discord 上で発表・コミュニケーションが行われました。私が iOS 版 CLINICS の開発に携わっている縁で、今回スポンサー枠として iOSDC に参加させていただきましたので紹介させていただきます。 イベント全体について オンライン開催となったため、会場の様子や企業ブースなど、雰囲気の伝わる写真をお届けできないのが残念ですが、発表の主会場となったニコニコ生放送では、終始穏やかな雰囲気でありつつも活発にコメントがなされ、大いに盛り上がっていました。 前回同様、初日は day 0 として夕方から、2 日目以降は朝〜夕方まで、最大 5 つのチャンネルで並行して発表が行われました。セッションについては事前に録画したものを放送し、LT のみリモートにてリアルタイム発表という形式となっていました。 質疑応答については、各発表の終了直後に Discord チャンネルに発表者が待機して対応していました。初のオンライン開催ということで、イントロダクション動画をはじめとし、各所で積極的なフィードバック・コミュニケーションが奨励されていたように思います（なお、イントロダクション・スポンサー紹介の各動画はナレーションが声優の緒方恵美さん・三石琴乃さんと、とても豪華でした。生放送中のコメントや、 18 年の弊社ブログ を見る限りは毎年恒例のようですね。すごいです！）。 セッションについて 昨年 iOS13 とともに発表された SwiftUI への移行や、コード移行・モジュール分割等、プロジェクトの最適化についてのトピックが多かったように思います。 SwiftUI は、従来 Storyboard で設計していた UI をコードベースで記述できる画期的なフレームワークですが、SwiftUI を使ったアプリは iOS13 未満の端末では利用できなくなってしまうこともあり、アプリの公開対象を広めにもっておきたい場合はなかなか乗り換えづらい印象でした。2020 年 6 月現在で iOS13 のシェアが 9 割以上となったことで、ちょうど iOSDC での発表トピックを決めるころに導入作業を行った（かつ苦労した）というケースが多かったのかな、と思います。 以下、視聴したセッションのうち気になったものをいくつかご紹介いたします。 オープンソースの AltSwiftUI の発表 fortee.jp 楽天のエンジニアの方による、SwiftUI の提供するネイティブコンポーネントに対応しつつ、iOS11 以上で利用可能なオープンソースのフレームワーク AltSwiftUI （ 公式 Doc ）の開発についてのセッションでした。 iOS12 以下の対応を切らずに SwiftUI への乗り換えを進められる（かつ本家と違ってオープンソースである）便利さもそうですが、別途フレームワークが出来上がってしまうあたりに、SwiftUI への移行対応への苦労がしのばれる内容でもありました（ストアにある楽天提供の iOS アプリの数を考えると乗り換えコストが大変そう…）。 「それ、自動化できますよ」: note を支えるワークフロー大全 speakerdeck.com 改修要望が上がってから、実際に改修を行ってアプリをリリースするまでの作業をできる限り自動化した、というセッションです。CLINICS でも、「証明書の有効期限確認、プッシュからのテスト、マージからのリリース準備」は Bitrise のトリガを利用して自動化しています。 上記のような、GitHub 上でのアクション（プッシュ、マージなど）をトリガとする自動化はよく聞く話ではあるのですが、Slack のポストに特定のスタンプつけると Issue 化、はちょっと目新しくて面白いなと思いました（気をつけないと表記揺れで同じような Issue が乱立しそうですが）。 Issue もきちんと管理しておかないとトラブルの起きやすい部分ですよね。起票者と実装者の間でボールが浮いてしまったり、プロジェクトに紐づいていなかったために対応から洩れてしまったり…。 また、このスライドですが終始手書きの挿絵がかわいくて、そういった意味でもコメント欄が盛り上がっていたのが印象的でした。 100 人でアプリをリファクタリングして見えてきた、最強の iOS アプリ設計に求められること fortee.jp アプリを長期に運用していくとほぼ必須となる課題でありながら、人ごとに基準が曖昧だったり、機能開発におされて対応が後手後手になったり…と、何かとつらい話をよく聞くソースコードのリファクタリングに関するセッションでした。 同じ状態のソースコードを多数のエンジニアがリファクタした結果を比較することで、「良いリファクタリングのための考え方」とは何か？を模索した内容です。 ビューとロジックの分割をしっかり行う、というのは PR レビューでエンジニアが口を酸っぱくしてよく言われることではありますが、「ロジックの中でも、アプリの仕様に依存するものとそうでない普遍的なものは分離すべき」というアイデアは個人的には眼から鱗が落ちるものでした。 また、これを説明するリバーシの具体例（「対戦相手が人間か AI か」はアプリ仕様に依存するロジック、「そこに石を置けるか」は普遍的なロジック＝リバーシのルールそのもの）も非常にわかりやすかったです。 そのほか、React / Redux でフロントエンド開発を行っている人にはお馴染みの Action / Reducer を使った単一方向のデータフローの導入なども紹介されています。 新規機能開発からモジュール分割を始めてみる speakerdeck.com 一つのアプリが長期間運用されていくなかで、複数の機能が統合されたスーパーアプリになることがあります。そうなった場合、ソースコードが肥大化 → ビルド・テストも長大化、となってメンテナンス性が低下するため、対策としてコードを分割してテストやビルドの単位を小さくする必要があります。 いきなりアプリ全体をモジュールに分割するのは時間がかかるため、本セッションではまず第一段階として新規に開発する機能を別モジュールとして実装し、その時得た知見について触れられていました。 「分割したモジュール側でのサードパーティ製フレームワークのリンク方法（※リンクを正しく行わないと、ビルドして動作はするのにアーカイブに失敗してリリースできなくなる）」などは、今後の開発にモジュール分割を取り入れていく際に参考になりそうです。 Swift で始める静的解析 speakerdeck.com Swift ソースコードからの構文木の生成、解析を行うライブラリ SwiftSyntax の紹介と、それを用いたソースコード重複検出機能の実装についてのセッションでした。 普段 Xcode を始めとした IDE で開発していると、コード重複、不要なローカル変数、型や Nullable の不一致に変数リファクタリング…等々の便利な機能を気軽に使えてしまいますが、その裏の動作を改めて一つずつ具体的に追っていくと、そのありがたみが身に染みます…。 静的解析そのものは Swift に限らず様々な言語のソースコードに対して適用できるトピックではあるのですが、普段何気なく使ってしまう IDE の機能について考えるよい機会になったため、紹介させていただきました。 まとめ ちょうど業務でも iOS アプリ開発を担当していることもあり、興味深い知見が得られ、よい経験となりました。また、事前録画形式になったことで発表の構成がよく練られ、結果として聞きやすく（皆様かなり気をつけてゆっくり発声されていました）、個性のある発表が多かったように思います。 今回、初のオンラインでの開催ということで、運営委員会の皆様もいろいろと苦労されていらっしゃるようでした。ただ、その甲斐あってか当日の進行はスムーズで、会場はとても盛り上がっていました。関係者の皆様、本当にお疲れ様でした。 情勢を踏まえ、来年度の開催可否・形式は未定とのことでしたが、オンライン・対面のそれぞれの良さを取り入れつつ、より多くの人が参加できる形態になっているとよいなと思います。 公式 YouTube チャンネル で過去の発表を視聴できますので、ご興味のある方はぜひどうぞ（今年の発表分も一ヶ月ほどしたら公開されるとのことでした）。 またメドレーでは iOS / Android ネイティブアプリ開発エンジニアを募集しています。興味がある方、ぜひお気軽にお話しましょう! www.medley.jp

こんにちは。 ジョブメドレー の開発チームでエンジニアをしている新居です。 はじめに 2020 年 4 月に、新卒エンジニア 3 名が入社しました。 入社後は新卒エンジニア研修を実施し、先日 8 月 25 日の最終報告会をもって終了しました。 コロナウイルスの影響で入社間もなくフルリモート勤務となり、不慣れなところもありましたが、本年度の研修の取り組みを紹介します。 2020 年度新卒エンジニア 研修の概要 メドレーでは昨年度から新卒エンジニアを迎えており、合わせて研修も開始しました。 初めての研修をどのような視点で計画・実施したかについては、昨年平木がこちらにまとめています。 2019 年度エンジニア新卒の研修について - Medley Developer Blog 今年は人事部のご協力もいただきながら、昨年の内容を少しアップデートして行いました。 研修の目的は、 新卒メンバーが同じ空間で互いに刺激し合いながら、社会人への思考転換をはかり、業務遂行に必要となる基礎知識とスキルを習得すること です。 研修は以下の 4 つのフェーズに区切って行いました。 研修のフェーズ 研修の内容 ここから 4 つのフェーズ毎に内容を紹介します。 フェーズ 1：社会人&メドレー基礎研修 1. オリエンテーション メドレーの事業や組織、大切にしている行動規範などの概要説明 セキュリティ研修とコンプライアンス研修 2. ビジネス研修 ビジネスマナー研修 ビジネススキル研修 ビジネススタンス研修（外部研修） フェーズ 1 では「医療ヘルスケアの未来をつくる」メンバーの一員として大切にして欲しいことを学ぶフェーズでした。 社会人としての最低限のマナーやスタンスは勿論ですが、メドレーで働く上で土台となるマインドをここで学び、 医療ヘルスケア分野の課題を解決する一員 として共にプロダクトを作るためのベースを築けたと思います。 フェーズ 2：エンジニア基礎研修 1. 開発基礎 1 講義「メドレーが求めるエンジニアとは」 ジョブメドレー と CLINICS の事業・プロダクトについての概要説明 Ruby on Rails（以下 Rails）の基礎トレーニング 2. 開発実践 チーム開発体験 3. 開発基礎 2 書籍 『Web を支える技術 -HTTP、URI、HTML、そして REST』 の輪読会 ドキュメンテーション研修とプレゼンテーション研修 中間報告会の準備と実施 フェーズ 2 から開発の研修がスタートしました。 開発基礎 1 開発の研修に入る前に、エンジニアの執行役員 田中から「メドレーが求めるエンジニアとは」というテーマで講義を行いました。メドレーがどういうエンジニアを求めているのか、目指すところの視点合わせを行い、これから行う研修に対する意識や取り組みの質を上げることを目指しました。 メドレーが求めるエンジニア像については CTO 平山の記事にも詳しく書いています。 メドレー平山の中央突破: THE エンジニア その後ジョブメドレーと CLINICS の事業・プロダクトについての概要説明、Rails の基礎トレーニングを行いました。メドレーのプロダクトは Rails 製です。Rails やウェブアプリケーション開発に慣れていない新卒メンバーは、Rails の基礎トレーニングで Ruby on Rails チュートリアル を使って基礎からみっちり学びます。 Ruby on Rails チュートリアルの進め方 ここで大切なことは、漠然とひたすら写経してチュートリアルを進めるのではなく、毎日のフィードバック会でしっかりその日の進捗や学びを共有し、不明点はメンターに質問してもらうようにすることです。 メンターは、新卒メンバーが理解が浅いまま進めてたり、理解していて欲しいところがいい加減になってたり、進め方や学びの方向性がズレてる場合などはアドバイスを入れて軌道修正することを心掛けました。 また「実際の開発ではこうだよ」といった実務を踏まえたアドバイスや、意識していることも伝えていきました。 20 新卒 S さんの感想 「毎日のフィードバック会の中で、その日学んだ技術がジョブメドレーではどのように利用されているのか、どういったことに留意して利用しているのかなどを確認できたので、現場の人の感覚を少しずつ知ることができた。」 新卒メンバーは毎日リズム良く進捗を出し、メンターは新卒メンバーのフォローと引き上げを意識し、成果を最大化できるよう努めました。 開発実践 続いて開発実践ではチーム開発を行いました。前回までは各自個別に進めていましたが、ここではジョブメドレーに関する課題解決を目的としたプロジェクトに対して、チームで向き合う研修でした。 開発実践の目的と達成すべきこと 実務ではチーム開発が基本となり、チームメンバーとの協働は必須です。学生時代に業務レベルのチーム開発を経験しているのは稀ですし、実務に入る前にチームでプロジェクト推進するとはどういうことかを知るのは、とても価値があると思います。 加えて、チームで課題をどう解決していくのかも、新卒メンバー同士で話し合って決める必要があるので、課題解決力も養われたと思います。 今回はプロトタイプを作って成果発表するところまででしたが、プロジェクト推進においてはスケジューリング、要件定義、各種設計、開発フローやコミュニケーションフローの整備、実装、テスト、などなど、やることは尽きません。 また、このプロセスの中で密なコミュニケーションが必要不可欠となるので、新卒メンバー間のチームワークも向上し、お互いのことを更に知ることができたと思います。 この段階で、チームでプロジェクトを推進することの全体感を知り、プロジェクト推進の苦悩苦闘を実体験できたのは大きな経験値になったと思います。 20 新卒 O さんの感想 「各機能の影響を互いに受けないためにブランチを細分化するブランチ戦略や GitHub を用いたコード管理について理解できた。一方で、UI を考える際にチームの各メンバーの認識のズレが生じたことや、序盤は各メンバーの進捗の詳細を把握できていなかったことから報・連・相の重要性を再認識した。」 20 新卒 T さんの感想 「初めてのチーム開発であったことから、実装の序盤は、どのファイルなら編集しても他のメンバーの作業に影響がないのか、動作確認のための画面を作るファイルは自由に作成して良いのか、どのテーブルから関係する他のテーブルの情報を含めた情報を取得をするかなどに悩んでいた。今になって振り返るとチーム内で話せば解決することに対して、技術的にも心理的にも難しさを感じた。」 ###開発基礎 2 フェーズ 2 最後の開発基礎 2 では、書籍 『Web を支える技術 -HTTP、URI、HTML、そして REST』 の輪読会を行いました。もっと前のフェーズでの実施も検討しましたが、開発基礎 1 と開発実践を経た後の方が書籍の内容の納得感が高くなるだろうという判断で、この段階での実施となりました。 その後、中間報告会に向けたドキュメンテーション研修とプレゼンテーション研修を行いました。仕事を進めていく上では、背景や目的を正しくステークホルダーへ共有しながら進めていくことが必要で、伝えたいことを適切に文章として整理し、他者へ分かりやすく伝えていくことが求められます。中間報告会では、そういったことを意識しながらこれまでの研修でやってきたことや成果、学びをレポートにまとめ、プロダクト開発室の室長と副室長、メンター陣の前でプレゼンテーションして報告しました。 フェーズ 3：事業部 OJT 1.代表取締役医師 豊田の講義 日本における医療制度の課題とそれに対するメドレーの位置付けについての講義 2.ジョブメドレー開発 OJT ジョブメドレーの実際の開発 Issue に対応し、ジョブメドレーの開発プロセスを体験 フェーズ 3 の最初は豊田代表の講義を受けました。基礎的な研修を終え、ジョブメドレー開発 OJT に入る前にメドレー社の社会的意義などを改めて代表から伝えていただきました。 続いて、ジョブメドレー開発 OJT は以下の狙いを持って進めました。 ジョブメドレー開発 OJT の狙い 実際に行ったことは、手始めに小さい不具合系 Issue の対応に取り組んだ後、サーバーレスポンス改善の Issue に取り組むというものでした。 サーバーレスポンスの改善は、1 人 1 画面を担当し、「プロファイルツールで分析 → 改善できそうな箇所を調査 → 改善方針の検討 → 提案 → 実装 → レビュー → リリース」というサイクルを回しました。 1 つ目の Issue 対応でも心掛けたことですが、言われたものを実装するのではなく、 ある課題を解決するためにどうしたら良いかを自分で主体的に考えることを重視しました。実装力と同じくらい課題解決力も大切にしているためです。 とはいえ成果が何も出せないというのは、精神衛生上良くないので、日々の朝会と夕会にて進捗や状況をしっかり確認しながら適宜フォローやインプットを行い、ヒントになりそうな過去 Issue のリンクを渡して参考にしてもらったり、メンターの適切なバックアップも必要です。 今回の OJT を通じて実務を知ることで、実際にエンジニアとして仕事をするイメージが沸き、同時に仕事をする上で足りないことも明確になります。自分の課題と向き合うことで、直近の自身の学習プランの軌道修正もできます。 課題は簡単なものではありませんでしたが、最終的に 1 人 1 つ以上のサーバーレスポンス改善 PR をリリースすることができました。 S さんの感想 「速度パフォーマンスの悪いコードに対する嗅覚、オブジェクトを生成しすぎていないか、無駄に通信を走らせていないかなどを学べた。」 O さんの感想 「Issue を本質的に解決するメドレーの開発姿勢について学んだ。Issue を表面的に解決するのではなく、背景や目的、関連するコードなどの不明点を調査し、十分に理解・納得した上で修正することの意識付けができた。また、Issue に関連する一部分のコードを修正すれば良いという狭い視野を持たず、修正による影響範囲を考慮した上で全体の最適化を考えることが重要であると学んだ。」 フェーズ 4：最終報告 1. 最終報告会 最終報告会の準備と実施 最後のフェーズ 4 では、これまでの研修でやってきたことや成果、学びをレポートにまとめ、役員陣の前でプレゼンテーションして報告しました。 役員陣の前なので緊張は最高潮になりますが、自分達が研修を通じて何を得てどう成長したか、今後どういうエンジニアを目指していくのか、などを役員陣の前でアピールする貴重な機会となりました。 1 人 10 分の枠内で役員陣にどういう情報をどういう表現でプレゼンテーションするかを考える機会にもなったので、情報整理力や表現力が培われる場にもなりました。 さいごに 2020 年度の新卒エンジニア研修も無事終了することができました。改めて、新卒メンバーのみなさん、関係者のみなさん本当にお疲れ様でした。 振り返ると、メドレー社員としてのマインドや開発の基本的なことをしっかりインプットしつつ、新卒メンバーが主体的に課題解決に取り組む研修ができたように思います。 必要な技術スタックを 1 から 10 まで懇切丁寧に資料に落とし込み、講義形式で行う研修も身になることは多いですが、 メドレーの研修のような課題解決を実体験する研修はより実務に繋がる実践的な研修だと思います。 少しハードな面もあるかもしれませんが、このような研修を乗り越え、医療ヘルスケア分野の課題解決に取り組みたい学生エンジニアのみなさん、少しでも興味を持っていただけると幸いです。 もちろん中途エンジニアの方もぜひお気軽にお話をしましょう。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。 ジョブメドレー の開発チームでエンジニアをしている新居です。 はじめに 2020 年 4 月に、新卒エンジニア 3 名が入社しました。 入社後は新卒エンジニア研修を実施し、先日 8 月 25 日の最終報告会をもって終了しました。 コロナウイルスの影響で入社間もなくフルリモート勤務となり、不慣れなところもありましたが、本年度の研修の取り組みを紹介します。 2020 年度新卒エンジニア 研修の概要 メドレーでは昨年度から新卒エンジニアを迎えており、合わせて研修も開始しました。 初めての研修をどのような視点で計画・実施したかについては、昨年平木がこちらにまとめています。 2019 年度エンジニア新卒の研修について - Medley Developer Blog 今年は人事部のご協力もいただきながら、昨年の内容を少しアップデートして行いました。 研修の目的は、 新卒メンバーが同じ空間で互いに刺激し合いながら、社会人への思考転換をはかり、業務遂行に必要となる基礎知識とスキルを習得すること です。 研修は以下の 4 つのフェーズに区切って行いました。 研修のフェーズ 研修の内容 ここから 4 つのフェーズ毎に内容を紹介します。 フェーズ 1：社会人&メドレー基礎研修 1. オリエンテーション メドレーの事業や組織、大切にしている行動規範などの概要説明 セキュリティ研修とコンプライアンス研修 2. ビジネス研修 ビジネスマナー研修 ビジネススキル研修 ビジネススタンス研修（外部研修） フェーズ 1 では「医療ヘルスケアの未来をつくる」メンバーの一員として大切にして欲しいことを学ぶフェーズでした。 社会人としての最低限のマナーやスタンスは勿論ですが、メドレーで働く上で土台となるマインドをここで学び、 医療ヘルスケア分野の課題を解決する一員 として共にプロダクトを作るためのベースを築けたと思います。 フェーズ 2：エンジニア基礎研修 1. 開発基礎 1 講義「メドレーが求めるエンジニアとは」 ジョブメドレー と CLINICS の事業・プロダクトについての概要説明 Ruby on Rails（以下 Rails）の基礎トレーニング 2. 開発実践 チーム開発体験 3. 開発基礎 2 書籍 『Web を支える技術 -HTTP、URI、HTML、そして REST』 の輪読会 ドキュメンテーション研修とプレゼンテーション研修 中間報告会の準備と実施 フェーズ 2 から開発の研修がスタートしました。 開発基礎 1 開発の研修に入る前に、エンジニアの執行役員 田中から「メドレーが求めるエンジニアとは」というテーマで講義を行いました。メドレーがどういうエンジニアを求めているのか、目指すところの視点合わせを行い、これから行う研修に対する意識や取り組みの質を上げることを目指しました。 メドレーが求めるエンジニア像については CTO 平山の記事にも詳しく書いています。 メドレー平山の中央突破: THE エンジニア その後ジョブメドレーと CLINICS の事業・プロダクトについての概要説明、Rails の基礎トレーニングを行いました。メドレーのプロダクトは Rails 製です。Rails やウェブアプリケーション開発に慣れていない新卒メンバーは、Rails の基礎トレーニングで Ruby on Rails チュートリアル を使って基礎からみっちり学びます。 Ruby on Rails チュートリアルの進め方 ここで大切なことは、漠然とひたすら写経してチュートリアルを進めるのではなく、毎日のフィードバック会でしっかりその日の進捗や学びを共有し、不明点はメンターに質問してもらうようにすることです。 メンターは、新卒メンバーが理解が浅いまま進めてたり、理解していて欲しいところがいい加減になってたり、進め方や学びの方向性がズレてる場合などはアドバイスを入れて軌道修正することを心掛けました。 また「実際の開発ではこうだよ」といった実務を踏まえたアドバイスや、意識していることも伝えていきました。 20 新卒 S さんの感想 「毎日のフィードバック会の中で、その日学んだ技術がジョブメドレーではどのように利用されているのか、どういったことに留意して利用しているのかなどを確認できたので、現場の人の感覚を少しずつ知ることができた。」 新卒メンバーは毎日リズム良く進捗を出し、メンターは新卒メンバーのフォローと引き上げを意識し、成果を最大化できるよう努めました。 開発実践 続いて開発実践ではチーム開発を行いました。前回までは各自個別に進めていましたが、ここではジョブメドレーに関する課題解決を目的としたプロジェクトに対して、チームで向き合う研修でした。 開発実践の目的と達成すべきこと 実務ではチーム開発が基本となり、チームメンバーとの協働は必須です。学生時代に業務レベルのチーム開発を経験しているのは稀ですし、実務に入る前にチームでプロジェクト推進するとはどういうことかを知るのは、とても価値があると思います。 加えて、チームで課題をどう解決していくのかも、新卒メンバー同士で話し合って決める必要があるので、課題解決力も養われたと思います。 今回はプロトタイプを作って成果発表するところまででしたが、プロジェクト推進においてはスケジューリング、要件定義、各種設計、開発フローやコミュニケーションフローの整備、実装、テスト、などなど、やることは尽きません。 また、このプロセスの中で密なコミュニケーションが必要不可欠となるので、新卒メンバー間のチームワークも向上し、お互いのことを更に知ることができたと思います。 この段階で、チームでプロジェクトを推進することの全体感を知り、プロジェクト推進の苦悩苦闘を実体験できたのは大きな経験値になったと思います。 20 新卒 O さんの感想 「各機能の影響を互いに受けないためにブランチを細分化するブランチ戦略や GitHub を用いたコード管理について理解できた。一方で、UI を考える際にチームの各メンバーの認識のズレが生じたことや、序盤は各メンバーの進捗の詳細を把握できていなかったことから報・連・相の重要性を再認識した。」 20 新卒 T さんの感想 「初めてのチーム開発であったことから、実装の序盤は、どのファイルなら編集しても他のメンバーの作業に影響がないのか、動作確認のための画面を作るファイルは自由に作成して良いのか、どのテーブルから関係する他のテーブルの情報を含めた情報を取得をするかなどに悩んでいた。今になって振り返るとチーム内で話せば解決することに対して、技術的にも心理的にも難しさを感じた。」 ###開発基礎 2 フェーズ 2 最後の開発基礎 2 では、書籍 『Web を支える技術 -HTTP、URI、HTML、そして REST』 の輪読会を行いました。もっと前のフェーズでの実施も検討しましたが、開発基礎 1 と開発実践を経た後の方が書籍の内容の納得感が高くなるだろうという判断で、この段階での実施となりました。 その後、中間報告会に向けたドキュメンテーション研修とプレゼンテーション研修を行いました。仕事を進めていく上では、背景や目的を正しくステークホルダーへ共有しながら進めていくことが必要で、伝えたいことを適切に文章として整理し、他者へ分かりやすく伝えていくことが求められます。中間報告会では、そういったことを意識しながらこれまでの研修でやってきたことや成果、学びをレポートにまとめ、プロダクト開発室の室長と副室長、メンター陣の前でプレゼンテーションして報告しました。 フェーズ 3：事業部 OJT 1.代表取締役医師 豊田の講義 日本における医療制度の課題とそれに対するメドレーの位置付けについての講義 2.ジョブメドレー開発 OJT ジョブメドレーの実際の開発 Issue に対応し、ジョブメドレーの開発プロセスを体験 フェーズ 3 の最初は豊田代表の講義を受けました。基礎的な研修を終え、ジョブメドレー開発 OJT に入る前にメドレー社の社会的意義などを改めて代表から伝えていただきました。 続いて、ジョブメドレー開発 OJT は以下の狙いを持って進めました。 ジョブメドレー開発 OJT の狙い 実際に行ったことは、手始めに小さい不具合系 Issue の対応に取り組んだ後、サーバーレスポンス改善の Issue に取り組むというものでした。 サーバーレスポンスの改善は、1 人 1 画面を担当し、「プロファイルツールで分析 → 改善できそうな箇所を調査 → 改善方針の検討 → 提案 → 実装 → レビュー → リリース」というサイクルを回しました。 1 つ目の Issue 対応でも心掛けたことですが、言われたものを実装するのではなく、 ある課題を解決するためにどうしたら良いかを自分で主体的に考えることを重視しました。実装力と同じくらい課題解決力も大切にしているためです。 とはいえ成果が何も出せないというのは、精神衛生上良くないので、日々の朝会と夕会にて進捗や状況をしっかり確認しながら適宜フォローやインプットを行い、ヒントになりそうな過去 Issue のリンクを渡して参考にしてもらったり、メンターの適切なバックアップも必要です。 今回の OJT を通じて実務を知ることで、実際にエンジニアとして仕事をするイメージが沸き、同時に仕事をする上で足りないことも明確になります。自分の課題と向き合うことで、直近の自身の学習プランの軌道修正もできます。 課題は簡単なものではありませんでしたが、最終的に 1 人 1 つ以上のサーバーレスポンス改善 PR をリリースすることができました。 S さんの感想 「速度パフォーマンスの悪いコードに対する嗅覚、オブジェクトを生成しすぎていないか、無駄に通信を走らせていないかなどを学べた。」 O さんの感想 「Issue を本質的に解決するメドレーの開発姿勢について学んだ。Issue を表面的に解決するのではなく、背景や目的、関連するコードなどの不明点を調査し、十分に理解・納得した上で修正することの意識付けができた。また、Issue に関連する一部分のコードを修正すれば良いという狭い視野を持たず、修正による影響範囲を考慮した上で全体の最適化を考えることが重要であると学んだ。」 フェーズ 4：最終報告 1. 最終報告会 最終報告会の準備と実施 最後のフェーズ 4 では、これまでの研修でやってきたことや成果、学びをレポートにまとめ、役員陣の前でプレゼンテーションして報告しました。 役員陣の前なので緊張は最高潮になりますが、自分達が研修を通じて何を得てどう成長したか、今後どういうエンジニアを目指していくのか、などを役員陣の前でアピールする貴重な機会となりました。 1 人 10 分の枠内で役員陣にどういう情報をどういう表現でプレゼンテーションするかを考える機会にもなったので、情報整理力や表現力が培われる場にもなりました。 さいごに 2020 年度の新卒エンジニア研修も無事終了することができました。改めて、新卒メンバーのみなさん、関係者のみなさん本当にお疲れ様でした。 振り返ると、メドレー社員としてのマインドや開発の基本的なことをしっかりインプットしつつ、新卒メンバーが主体的に課題解決に取り組む研修ができたように思います。 必要な技術スタックを 1 から 10 まで懇切丁寧に資料に落とし込み、講義形式で行う研修も身になることは多いですが、 メドレーの研修のような課題解決を実体験する研修はより実務に繋がる実践的な研修だと思います。 少しハードな面もあるかもしれませんが、このような研修を乗り越え、医療ヘルスケア分野の課題解決に取り組みたい学生エンジニアのみなさん、少しでも興味を持っていただけると幸いです。 もちろん中途エンジニアの方もぜひお気軽にお話をしましょう。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。 ジョブメドレー の開発チームでエンジニアをしている新居です。 はじめに 2020 年 4 月に、新卒エンジニア 3 名が入社しました。 入社後は新卒エンジニア研修を実施し、先日 8 月 25 日の最終報告会をもって終了しました。 コロナウイルスの影響で入社間もなくフルリモート勤務となり、不慣れなところもありましたが、本年度の研修の取り組みを紹介します。 2020 年度新卒エンジニア 研修の概要 メドレーでは昨年度から新卒エンジニアを迎えており、合わせて研修も開始しました。 初めての研修をどのような視点で計画・実施したかについては、昨年平木がこちらにまとめています。 2019 年度エンジニア新卒の研修について - Medley Developer Blog 今年は人事部のご協力もいただきながら、昨年の内容を少しアップデートして行いました。 研修の目的は、 新卒メンバーが同じ空間で互いに刺激し合いながら、社会人への思考転換をはかり、業務遂行に必要となる基礎知識とスキルを習得すること です。 研修は以下の 4 つのフェーズに区切って行いました。 研修のフェーズ 研修の内容 ここから 4 つのフェーズ毎に内容を紹介します。 フェーズ 1：社会人&メドレー基礎研修 1. オリエンテーション メドレーの事業や組織、大切にしている行動規範などの概要説明 セキュリティ研修とコンプライアンス研修 2. ビジネス研修 ビジネスマナー研修 ビジネススキル研修 ビジネススタンス研修（外部研修） フェーズ 1 では「医療ヘルスケアの未来をつくる」メンバーの一員として大切にして欲しいことを学ぶフェーズでした。 社会人としての最低限のマナーやスタンスは勿論ですが、メドレーで働く上で土台となるマインドをここで学び、 医療ヘルスケア分野の課題を解決する一員 として共にプロダクトを作るためのベースを築けたと思います。 フェーズ 2：エンジニア基礎研修 1. 開発基礎 1 講義「メドレーが求めるエンジニアとは」 ジョブメドレー と CLINICS の事業・プロダクトについての概要説明 Ruby on Rails（以下 Rails）の基礎トレーニング 2. 開発実践 チーム開発体験 3. 開発基礎 2 書籍 『Web を支える技術 -HTTP、URI、HTML、そして REST』 の輪読会 ドキュメンテーション研修とプレゼンテーション研修 中間報告会の準備と実施 フェーズ 2 から開発の研修がスタートしました。 開発基礎 1 開発の研修に入る前に、エンジニアの執行役員 田中から「メドレーが求めるエンジニアとは」というテーマで講義を行いました。メドレーがどういうエンジニアを求めているのか、目指すところの視点合わせを行い、これから行う研修に対する意識や取り組みの質を上げることを目指しました。 メドレーが求めるエンジニア像については CTO 平山の記事にも詳しく書いています。 メドレー平山の中央突破: THE エンジニア その後ジョブメドレーと CLINICS の事業・プロダクトについての概要説明、Rails の基礎トレーニングを行いました。メドレーのプロダクトは Rails 製です。Rails やウェブアプリケーション開発に慣れていない新卒メンバーは、Rails の基礎トレーニングで Ruby on Rails チュートリアル を使って基礎からみっちり学びます。 Ruby on Rails チュートリアルの進め方 ここで大切なことは、漠然とひたすら写経してチュートリアルを進めるのではなく、毎日のフィードバック会でしっかりその日の進捗や学びを共有し、不明点はメンターに質問してもらうようにすることです。 メンターは、新卒メンバーが理解が浅いまま進めてたり、理解していて欲しいところがいい加減になってたり、進め方や学びの方向性がズレてる場合などはアドバイスを入れて軌道修正することを心掛けました。 また「実際の開発ではこうだよ」といった実務を踏まえたアドバイスや、意識していることも伝えていきました。 20 新卒 S さんの感想 「毎日のフィードバック会の中で、その日学んだ技術がジョブメドレーではどのように利用されているのか、どういったことに留意して利用しているのかなどを確認できたので、現場の人の感覚を少しずつ知ることができた。」 新卒メンバーは毎日リズム良く進捗を出し、メンターは新卒メンバーのフォローと引き上げを意識し、成果を最大化できるよう努めました。 開発実践 続いて開発実践ではチーム開発を行いました。前回までは各自個別に進めていましたが、ここではジョブメドレーに関する課題解決を目的としたプロジェクトに対して、チームで向き合う研修でした。 開発実践の目的と達成すべきこと 実務ではチーム開発が基本となり、チームメンバーとの協働は必須です。学生時代に業務レベルのチーム開発を経験しているのは稀ですし、実務に入る前にチームでプロジェクト推進するとはどういうことかを知るのは、とても価値があると思います。 加えて、チームで課題をどう解決していくのかも、新卒メンバー同士で話し合って決める必要があるので、課題解決力も養われたと思います。 今回はプロトタイプを作って成果発表するところまででしたが、プロジェクト推進においてはスケジューリング、要件定義、各種設計、開発フローやコミュニケーションフローの整備、実装、テスト、などなど、やることは尽きません。 また、このプロセスの中で密なコミュニケーションが必要不可欠となるので、新卒メンバー間のチームワークも向上し、お互いのことを更に知ることができたと思います。 この段階で、チームでプロジェクトを推進することの全体感を知り、プロジェクト推進の苦悩苦闘を実体験できたのは大きな経験値になったと思います。 20 新卒 O さんの感想 「各機能の影響を互いに受けないためにブランチを細分化するブランチ戦略や GitHub を用いたコード管理について理解できた。一方で、UI を考える際にチームの各メンバーの認識のズレが生じたことや、序盤は各メンバーの進捗の詳細を把握できていなかったことから報・連・相の重要性を再認識した。」 20 新卒 T さんの感想 「初めてのチーム開発であったことから、実装の序盤は、どのファイルなら編集しても他のメンバーの作業に影響がないのか、動作確認のための画面を作るファイルは自由に作成して良いのか、どのテーブルから関係する他のテーブルの情報を含めた情報を取得をするかなどに悩んでいた。今になって振り返るとチーム内で話せば解決することに対して、技術的にも心理的にも難しさを感じた。」 ###開発基礎 2 フェーズ 2 最後の開発基礎 2 では、書籍 『Web を支える技術 -HTTP、URI、HTML、そして REST』 の輪読会を行いました。もっと前のフェーズでの実施も検討しましたが、開発基礎 1 と開発実践を経た後の方が書籍の内容の納得感が高くなるだろうという判断で、この段階での実施となりました。 その後、中間報告会に向けたドキュメンテーション研修とプレゼンテーション研修を行いました。仕事を進めていく上では、背景や目的を正しくステークホルダーへ共有しながら進めていくことが必要で、伝えたいことを適切に文章として整理し、他者へ分かりやすく伝えていくことが求められます。中間報告会では、そういったことを意識しながらこれまでの研修でやってきたことや成果、学びをレポートにまとめ、プロダクト開発室の室長と副室長、メンター陣の前でプレゼンテーションして報告しました。 フェーズ 3：事業部 OJT 1.代表取締役医師 豊田の講義 日本における医療制度の課題とそれに対するメドレーの位置付けについての講義 2.ジョブメドレー開発 OJT ジョブメドレーの実際の開発 Issue に対応し、ジョブメドレーの開発プロセスを体験 フェーズ 3 の最初は豊田代表の講義を受けました。基礎的な研修を終え、ジョブメドレー開発 OJT に入る前にメドレー社の社会的意義などを改めて代表から伝えていただきました。 続いて、ジョブメドレー開発 OJT は以下の狙いを持って進めました。 ジョブメドレー開発 OJT の狙い 実際に行ったことは、手始めに小さい不具合系 Issue の対応に取り組んだ後、サーバーレスポンス改善の Issue に取り組むというものでした。 サーバーレスポンスの改善は、1 人 1 画面を担当し、「プロファイルツールで分析 → 改善できそうな箇所を調査 → 改善方針の検討 → 提案 → 実装 → レビュー → リリース」というサイクルを回しました。 1 つ目の Issue 対応でも心掛けたことですが、言われたものを実装するのではなく、 ある課題を解決するためにどうしたら良いかを自分で主体的に考えることを重視しました。実装力と同じくらい課題解決力も大切にしているためです。 とはいえ成果が何も出せないというのは、精神衛生上良くないので、日々の朝会と夕会にて進捗や状況をしっかり確認しながら適宜フォローやインプットを行い、ヒントになりそうな過去 Issue のリンクを渡して参考にしてもらったり、メンターの適切なバックアップも必要です。 今回の OJT を通じて実務を知ることで、実際にエンジニアとして仕事をするイメージが沸き、同時に仕事をする上で足りないことも明確になります。自分の課題と向き合うことで、直近の自身の学習プランの軌道修正もできます。 課題は簡単なものではありませんでしたが、最終的に 1 人 1 つ以上のサーバーレスポンス改善 PR をリリースすることができました。 S さんの感想 「速度パフォーマンスの悪いコードに対する嗅覚、オブジェクトを生成しすぎていないか、無駄に通信を走らせていないかなどを学べた。」 O さんの感想 「Issue を本質的に解決するメドレーの開発姿勢について学んだ。Issue を表面的に解決するのではなく、背景や目的、関連するコードなどの不明点を調査し、十分に理解・納得した上で修正することの意識付けができた。また、Issue に関連する一部分のコードを修正すれば良いという狭い視野を持たず、修正による影響範囲を考慮した上で全体の最適化を考えることが重要であると学んだ。」 フェーズ 4：最終報告 1. 最終報告会 最終報告会の準備と実施 最後のフェーズ 4 では、これまでの研修でやってきたことや成果、学びをレポートにまとめ、役員陣の前でプレゼンテーションして報告しました。 役員陣の前なので緊張は最高潮になりますが、自分達が研修を通じて何を得てどう成長したか、今後どういうエンジニアを目指していくのか、などを役員陣の前でアピールする貴重な機会となりました。 1 人 10 分の枠内で役員陣にどういう情報をどういう表現でプレゼンテーションするかを考える機会にもなったので、情報整理力や表現力が培われる場にもなりました。 さいごに 2020 年度の新卒エンジニア研修も無事終了することができました。改めて、新卒メンバーのみなさん、関係者のみなさん本当にお疲れ様でした。 振り返ると、メドレー社員としてのマインドや開発の基本的なことをしっかりインプットしつつ、新卒メンバーが主体的に課題解決に取り組む研修ができたように思います。 必要な技術スタックを 1 から 10 まで懇切丁寧に資料に落とし込み、講義形式で行う研修も身になることは多いですが、 メドレーの研修のような課題解決を実体験する研修はより実務に繋がる実践的な研修だと思います。 少しハードな面もあるかもしれませんが、このような研修を乗り越え、医療ヘルスケア分野の課題解決に取り組みたい学生エンジニアのみなさん、少しでも興味を持っていただけると幸いです。 もちろん中途エンジニアの方もぜひお気軽にお話をしましょう。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。 ジョブメドレー の開発チームでエンジニアをしている新居です。 はじめに 2020 年 4 月に、新卒エンジニア 3 名が入社しました。 入社後は新卒エンジニア研修を実施し、先日 8 月 25 日の最終報告会をもって終了しました。 コロナウイルスの影響で入社間もなくフルリモート勤務となり、不慣れなところもありましたが、本年度の研修の取り組みを紹介します。 2020 年度新卒エンジニア 研修の概要 メドレーでは昨年度から新卒エンジニアを迎えており、合わせて研修も開始しました。 初めての研修をどのような視点で計画・実施したかについては、昨年平木がこちらにまとめています。 2019 年度エンジニア新卒の研修について - Medley Developer Blog 今年は人事部のご協力もいただきながら、昨年の内容を少しアップデートして行いました。 研修の目的は、 新卒メンバーが同じ空間で互いに刺激し合いながら、社会人への思考転換をはかり、業務遂行に必要となる基礎知識とスキルを習得すること です。 研修は以下の 4 つのフェーズに区切って行いました。 研修のフェーズ 研修の内容 ここから 4 つのフェーズ毎に内容を紹介します。 フェーズ 1：社会人&メドレー基礎研修 1. オリエンテーション メドレーの事業や組織、大切にしている行動規範などの概要説明 セキュリティ研修とコンプライアンス研修 2. ビジネス研修 ビジネスマナー研修 ビジネススキル研修 ビジネススタンス研修（外部研修） フェーズ 1 では「医療ヘルスケアの未来をつくる」メンバーの一員として大切にして欲しいことを学ぶフェーズでした。 社会人としての最低限のマナーやスタンスは勿論ですが、メドレーで働く上で土台となるマインドをここで学び、 医療ヘルスケア分野の課題を解決する一員 として共にプロダクトを作るためのベースを築けたと思います。 フェーズ 2：エンジニア基礎研修 1. 開発基礎 1 講義「メドレーが求めるエンジニアとは」 ジョブメドレー と CLINICS の事業・プロダクトについての概要説明 Ruby on Rails（以下 Rails）の基礎トレーニング 2. 開発実践 チーム開発体験 3. 開発基礎 2 書籍 『Web を支える技術 -HTTP、URI、HTML、そして REST』 の輪読会 ドキュメンテーション研修とプレゼンテーション研修 中間報告会の準備と実施 フェーズ 2 から開発の研修がスタートしました。 開発基礎 1 開発の研修に入る前に、エンジニアの執行役員 田中から「メドレーが求めるエンジニアとは」というテーマで講義を行いました。メドレーがどういうエンジニアを求めているのか、目指すところの視点合わせを行い、これから行う研修に対する意識や取り組みの質を上げることを目指しました。 メドレーが求めるエンジニア像については CTO 平山の記事にも詳しく書いています。 メドレー平山の中央突破: THE エンジニア その後ジョブメドレーと CLINICS の事業・プロダクトについての概要説明、Rails の基礎トレーニングを行いました。メドレーのプロダクトは Rails 製です。Rails やウェブアプリケーション開発に慣れていない新卒メンバーは、Rails の基礎トレーニングで Ruby on Rails チュートリアル を使って基礎からみっちり学びます。 Ruby on Rails チュートリアルの進め方 ここで大切なことは、漠然とひたすら写経してチュートリアルを進めるのではなく、毎日のフィードバック会でしっかりその日の進捗や学びを共有し、不明点はメンターに質問してもらうようにすることです。 メンターは、新卒メンバーが理解が浅いまま進めてたり、理解していて欲しいところがいい加減になってたり、進め方や学びの方向性がズレてる場合などはアドバイスを入れて軌道修正することを心掛けました。 また「実際の開発ではこうだよ」といった実務を踏まえたアドバイスや、意識していることも伝えていきました。 20 新卒 S さんの感想 「毎日のフィードバック会の中で、その日学んだ技術がジョブメドレーではどのように利用されているのか、どういったことに留意して利用しているのかなどを確認できたので、現場の人の感覚を少しずつ知ることができた。」 新卒メンバーは毎日リズム良く進捗を出し、メンターは新卒メンバーのフォローと引き上げを意識し、成果を最大化できるよう努めました。 開発実践 続いて開発実践ではチーム開発を行いました。前回までは各自個別に進めていましたが、ここではジョブメドレーに関する課題解決を目的としたプロジェクトに対して、チームで向き合う研修でした。 開発実践の目的と達成すべきこと 実務ではチーム開発が基本となり、チームメンバーとの協働は必須です。学生時代に業務レベルのチーム開発を経験しているのは稀ですし、実務に入る前にチームでプロジェクト推進するとはどういうことかを知るのは、とても価値があると思います。 加えて、チームで課題をどう解決していくのかも、新卒メンバー同士で話し合って決める必要があるので、課題解決力も養われたと思います。 今回はプロトタイプを作って成果発表するところまででしたが、プロジェクト推進においてはスケジューリング、要件定義、各種設計、開発フローやコミュニケーションフローの整備、実装、テスト、などなど、やることは尽きません。 また、このプロセスの中で密なコミュニケーションが必要不可欠となるので、新卒メンバー間のチームワークも向上し、お互いのことを更に知ることができたと思います。 この段階で、チームでプロジェクトを推進することの全体感を知り、プロジェクト推進の苦悩苦闘を実体験できたのは大きな経験値になったと思います。 20 新卒 O さんの感想 「各機能の影響を互いに受けないためにブランチを細分化するブランチ戦略や GitHub を用いたコード管理について理解できた。一方で、UI を考える際にチームの各メンバーの認識のズレが生じたことや、序盤は各メンバーの進捗の詳細を把握できていなかったことから報・連・相の重要性を再認識した。」 20 新卒 T さんの感想 「初めてのチーム開発であったことから、実装の序盤は、どのファイルなら編集しても他のメンバーの作業に影響がないのか、動作確認のための画面を作るファイルは自由に作成して良いのか、どのテーブルから関係する他のテーブルの情報を含めた情報を取得をするかなどに悩んでいた。今になって振り返るとチーム内で話せば解決することに対して、技術的にも心理的にも難しさを感じた。」 ###開発基礎 2 フェーズ 2 最後の開発基礎 2 では、書籍 『Web を支える技術 -HTTP、URI、HTML、そして REST』 の輪読会を行いました。もっと前のフェーズでの実施も検討しましたが、開発基礎 1 と開発実践を経た後の方が書籍の内容の納得感が高くなるだろうという判断で、この段階での実施となりました。 その後、中間報告会に向けたドキュメンテーション研修とプレゼンテーション研修を行いました。仕事を進めていく上では、背景や目的を正しくステークホルダーへ共有しながら進めていくことが必要で、伝えたいことを適切に文章として整理し、他者へ分かりやすく伝えていくことが求められます。中間報告会では、そういったことを意識しながらこれまでの研修でやってきたことや成果、学びをレポートにまとめ、プロダクト開発室の室長と副室長、メンター陣の前でプレゼンテーションして報告しました。 フェーズ 3：事業部 OJT 1.代表取締役医師 豊田の講義 日本における医療制度の課題とそれに対するメドレーの位置付けについての講義 2.ジョブメドレー開発 OJT ジョブメドレーの実際の開発 Issue に対応し、ジョブメドレーの開発プロセスを体験 フェーズ 3 の最初は豊田代表の講義を受けました。基礎的な研修を終え、ジョブメドレー開発 OJT に入る前にメドレー社の社会的意義などを改めて代表から伝えていただきました。 続いて、ジョブメドレー開発 OJT は以下の狙いを持って進めました。 ジョブメドレー開発 OJT の狙い 実際に行ったことは、手始めに小さい不具合系 Issue の対応に取り組んだ後、サーバーレスポンス改善の Issue に取り組むというものでした。 サーバーレスポンスの改善は、1 人 1 画面を担当し、「プロファイルツールで分析 → 改善できそうな箇所を調査 → 改善方針の検討 → 提案 → 実装 → レビュー → リリース」というサイクルを回しました。 1 つ目の Issue 対応でも心掛けたことですが、言われたものを実装するのではなく、 ある課題を解決するためにどうしたら良いかを自分で主体的に考えることを重視しました。実装力と同じくらい課題解決力も大切にしているためです。 とはいえ成果が何も出せないというのは、精神衛生上良くないので、日々の朝会と夕会にて進捗や状況をしっかり確認しながら適宜フォローやインプットを行い、ヒントになりそうな過去 Issue のリンクを渡して参考にしてもらったり、メンターの適切なバックアップも必要です。 今回の OJT を通じて実務を知ることで、実際にエンジニアとして仕事をするイメージが沸き、同時に仕事をする上で足りないことも明確になります。自分の課題と向き合うことで、直近の自身の学習プランの軌道修正もできます。 課題は簡単なものではありませんでしたが、最終的に 1 人 1 つ以上のサーバーレスポンス改善 PR をリリースすることができました。 S さんの感想 「速度パフォーマンスの悪いコードに対する嗅覚、オブジェクトを生成しすぎていないか、無駄に通信を走らせていないかなどを学べた。」 O さんの感想 「Issue を本質的に解決するメドレーの開発姿勢について学んだ。Issue を表面的に解決するのではなく、背景や目的、関連するコードなどの不明点を調査し、十分に理解・納得した上で修正することの意識付けができた。また、Issue に関連する一部分のコードを修正すれば良いという狭い視野を持たず、修正による影響範囲を考慮した上で全体の最適化を考えることが重要であると学んだ。」 フェーズ 4：最終報告 1. 最終報告会 最終報告会の準備と実施 最後のフェーズ 4 では、これまでの研修でやってきたことや成果、学びをレポートにまとめ、役員陣の前でプレゼンテーションして報告しました。 役員陣の前なので緊張は最高潮になりますが、自分達が研修を通じて何を得てどう成長したか、今後どういうエンジニアを目指していくのか、などを役員陣の前でアピールする貴重な機会となりました。 1 人 10 分の枠内で役員陣にどういう情報をどういう表現でプレゼンテーションするかを考える機会にもなったので、情報整理力や表現力が培われる場にもなりました。 さいごに 2020 年度の新卒エンジニア研修も無事終了することができました。改めて、新卒メンバーのみなさん、関係者のみなさん本当にお疲れ様でした。 振り返ると、メドレー社員としてのマインドや開発の基本的なことをしっかりインプットしつつ、新卒メンバーが主体的に課題解決に取り組む研修ができたように思います。 必要な技術スタックを 1 から 10 まで懇切丁寧に資料に落とし込み、講義形式で行う研修も身になることは多いですが、 メドレーの研修のような課題解決を実体験する研修はより実務に繋がる実践的な研修だと思います。 少しハードな面もあるかもしれませんが、このような研修を乗り越え、医療ヘルスケア分野の課題解決に取り組みたい学生エンジニアのみなさん、少しでも興味を持っていただけると幸いです。 もちろん中途エンジニアの方もぜひお気軽にお話をしましょう。 https://www.medley.jp/jobs/

こんにちは。 ジョブメドレー の開発チームでエンジニアをしている新居です。 はじめに 2020 年 4 月に、新卒エンジニア 3 名が入社しました。 入社後は新卒エンジニア研修を実施し、先日 8 月 25 日の最終報告会をもって終了しました。 コロナウイルスの影響で入社間もなくフルリモート勤務となり、不慣れなところもありましたが、本年度の研修の取り組みを紹介します。 2020 年度新卒エンジニア 研修の概要 メドレーでは昨年度から新卒エンジニアを迎えており、合わせて研修も開始しました。 初めての研修をどのような視点で計画・実施したかについては、昨年平木がこちらにまとめています。 2019 年度エンジニア新卒の研修について - Medley Developer Blog 今年は人事部のご協力もいただきながら、昨年の内容を少しアップデートして行いました。 研修の目的は、 新卒メンバーが同じ空間で互いに刺激し合いながら、社会人への思考転換をはかり、業務遂行に必要となる基礎知識とスキルを習得すること です。 研修は以下の 4 つのフェーズに区切って行いました。 研修のフェーズ 研修の内容 ここから 4 つのフェーズ毎に内容を紹介します。 フェーズ 1：社会人&メドレー基礎研修 1. オリエンテーション メドレーの事業や組織、大切にしている行動規範などの概要説明 セキュリティ研修とコンプライアンス研修 2. ビジネス研修 ビジネスマナー研修 ビジネススキル研修 ビジネススタンス研修（外部研修） フェーズ 1 では「医療ヘルスケアの未来をつくる」メンバーの一員として大切にして欲しいことを学ぶフェーズでした。 社会人としての最低限のマナーやスタンスは勿論ですが、メドレーで働く上で土台となるマインドをここで学び、 医療ヘルスケア分野の課題を解決する一員 として共にプロダクトを作るためのベースを築けたと思います。 フェーズ 2：エンジニア基礎研修 1. 開発基礎 1 講義「メドレーが求めるエンジニアとは」 ジョブメドレー と CLINICS の事業・プロダクトについての概要説明 Ruby on Rails（以下 Rails）の基礎トレーニング 2. 開発実践 チーム開発体験 3. 開発基礎 2 書籍 『Web を支える技術 -HTTP、URI、HTML、そして REST』 の輪読会 ドキュメンテーション研修とプレゼンテーション研修 中間報告会の準備と実施 フェーズ 2 から開発の研修がスタートしました。 開発基礎 1 開発の研修に入る前に、エンジニアの執行役員 田中から「メドレーが求めるエンジニアとは」というテーマで講義を行いました。メドレーがどういうエンジニアを求めているのか、目指すところの視点合わせを行い、これから行う研修に対する意識や取り組みの質を上げることを目指しました。 メドレーが求めるエンジニア像については CTO 平山の記事にも詳しく書いています。 メドレー平山の中央突破: THE エンジニア その後ジョブメドレーと CLINICS の事業・プロダクトについての概要説明、Rails の基礎トレーニングを行いました。メドレーのプロダクトは Rails 製です。Rails やウェブアプリケーション開発に慣れていない新卒メンバーは、Rails の基礎トレーニングで Ruby on Rails チュートリアル を使って基礎からみっちり学びます。 Ruby on Rails チュートリアルの進め方 ここで大切なことは、漠然とひたすら写経してチュートリアルを進めるのではなく、毎日のフィードバック会でしっかりその日の進捗や学びを共有し、不明点はメンターに質問してもらうようにすることです。 メンターは、新卒メンバーが理解が浅いまま進めてたり、理解していて欲しいところがいい加減になってたり、進め方や学びの方向性がズレてる場合などはアドバイスを入れて軌道修正することを心掛けました。 また「実際の開発ではこうだよ」といった実務を踏まえたアドバイスや、意識していることも伝えていきました。 20 新卒 S さんの感想 「毎日のフィードバック会の中で、その日学んだ技術がジョブメドレーではどのように利用されているのか、どういったことに留意して利用しているのかなどを確認できたので、現場の人の感覚を少しずつ知ることができた。」 新卒メンバーは毎日リズム良く進捗を出し、メンターは新卒メンバーのフォローと引き上げを意識し、成果を最大化できるよう努めました。 開発実践 続いて開発実践ではチーム開発を行いました。前回までは各自個別に進めていましたが、ここではジョブメドレーに関する課題解決を目的としたプロジェクトに対して、チームで向き合う研修でした。 開発実践の目的と達成すべきこと 実務ではチーム開発が基本となり、チームメンバーとの協働は必須です。学生時代に業務レベルのチーム開発を経験しているのは稀ですし、実務に入る前にチームでプロジェクト推進するとはどういうことかを知るのは、とても価値があると思います。 加えて、チームで課題をどう解決していくのかも、新卒メンバー同士で話し合って決める必要があるので、課題解決力も養われたと思います。 今回はプロトタイプを作って成果発表するところまででしたが、プロジェクト推進においてはスケジューリング、要件定義、各種設計、開発フローやコミュニケーションフローの整備、実装、テスト、などなど、やることは尽きません。 また、このプロセスの中で密なコミュニケーションが必要不可欠となるので、新卒メンバー間のチームワークも向上し、お互いのことを更に知ることができたと思います。 この段階で、チームでプロジェクトを推進することの全体感を知り、プロジェクト推進の苦悩苦闘を実体験できたのは大きな経験値になったと思います。 20 新卒 O さんの感想 「各機能の影響を互いに受けないためにブランチを細分化するブランチ戦略や GitHub を用いたコード管理について理解できた。一方で、UI を考える際にチームの各メンバーの認識のズレが生じたことや、序盤は各メンバーの進捗の詳細を把握できていなかったことから報・連・相の重要性を再認識した。」 20 新卒 T さんの感想 「初めてのチーム開発であったことから、実装の序盤は、どのファイルなら編集しても他のメンバーの作業に影響がないのか、動作確認のための画面を作るファイルは自由に作成して良いのか、どのテーブルから関係する他のテーブルの情報を含めた情報を取得をするかなどに悩んでいた。今になって振り返るとチーム内で話せば解決することに対して、技術的にも心理的にも難しさを感じた。」 ###開発基礎 2 フェーズ 2 最後の開発基礎 2 では、書籍 『Web を支える技術 -HTTP、URI、HTML、そして REST』 の輪読会を行いました。もっと前のフェーズでの実施も検討しましたが、開発基礎 1 と開発実践を経た後の方が書籍の内容の納得感が高くなるだろうという判断で、この段階での実施となりました。 その後、中間報告会に向けたドキュメンテーション研修とプレゼンテーション研修を行いました。仕事を進めていく上では、背景や目的を正しくステークホルダーへ共有しながら進めていくことが必要で、伝えたいことを適切に文章として整理し、他者へ分かりやすく伝えていくことが求められます。中間報告会では、そういったことを意識しながらこれまでの研修でやってきたことや成果、学びをレポートにまとめ、プロダクト開発室の室長と副室長、メンター陣の前でプレゼンテーションして報告しました。 フェーズ 3：事業部 OJT 1.代表取締役医師 豊田の講義 日本における医療制度の課題とそれに対するメドレーの位置付けについての講義 2.ジョブメドレー開発 OJT ジョブメドレーの実際の開発 Issue に対応し、ジョブメドレーの開発プロセスを体験 フェーズ 3 の最初は豊田代表の講義を受けました。基礎的な研修を終え、ジョブメドレー開発 OJT に入る前にメドレー社の社会的意義などを改めて代表から伝えていただきました。 続いて、ジョブメドレー開発 OJT は以下の狙いを持って進めました。 ジョブメドレー開発 OJT の狙い 実際に行ったことは、手始めに小さい不具合系 Issue の対応に取り組んだ後、サーバーレスポンス改善の Issue に取り組むというものでした。 サーバーレスポンスの改善は、1 人 1 画面を担当し、「プロファイルツールで分析 → 改善できそうな箇所を調査 → 改善方針の検討 → 提案 → 実装 → レビュー → リリース」というサイクルを回しました。 1 つ目の Issue 対応でも心掛けたことですが、言われたものを実装するのではなく、 ある課題を解決するためにどうしたら良いかを自分で主体的に考えることを重視しました。実装力と同じくらい課題解決力も大切にしているためです。 とはいえ成果が何も出せないというのは、精神衛生上良くないので、日々の朝会と夕会にて進捗や状況をしっかり確認しながら適宜フォローやインプットを行い、ヒントになりそうな過去 Issue のリンクを渡して参考にしてもらったり、メンターの適切なバックアップも必要です。 今回の OJT を通じて実務を知ることで、実際にエンジニアとして仕事をするイメージが沸き、同時に仕事をする上で足りないことも明確になります。自分の課題と向き合うことで、直近の自身の学習プランの軌道修正もできます。 課題は簡単なものではありませんでしたが、最終的に 1 人 1 つ以上のサーバーレスポンス改善 PR をリリースすることができました。 S さんの感想 「速度パフォーマンスの悪いコードに対する嗅覚、オブジェクトを生成しすぎていないか、無駄に通信を走らせていないかなどを学べた。」 O さんの感想 「Issue を本質的に解決するメドレーの開発姿勢について学んだ。Issue を表面的に解決するのではなく、背景や目的、関連するコードなどの不明点を調査し、十分に理解・納得した上で修正することの意識付けができた。また、Issue に関連する一部分のコードを修正すれば良いという狭い視野を持たず、修正による影響範囲を考慮した上で全体の最適化を考えることが重要であると学んだ。」 フェーズ 4：最終報告 1. 最終報告会 最終報告会の準備と実施 最後のフェーズ 4 では、これまでの研修でやってきたことや成果、学びをレポートにまとめ、役員陣の前でプレゼンテーションして報告しました。 役員陣の前なので緊張は最高潮になりますが、自分達が研修を通じて何を得てどう成長したか、今後どういうエンジニアを目指していくのか、などを役員陣の前でアピールする貴重な機会となりました。 1 人 10 分の枠内で役員陣にどういう情報をどういう表現でプレゼンテーションするかを考える機会にもなったので、情報整理力や表現力が培われる場にもなりました。 さいごに 2020 年度の新卒エンジニア研修も無事終了することができました。改めて、新卒メンバーのみなさん、関係者のみなさん本当にお疲れ様でした。 振り返ると、メドレー社員としてのマインドや開発の基本的なことをしっかりインプットしつつ、新卒メンバーが主体的に課題解決に取り組む研修ができたように思います。 必要な技術スタックを 1 から 10 まで懇切丁寧に資料に落とし込み、講義形式で行う研修も身になることは多いですが、 メドレーの研修のような課題解決を実体験する研修はより実務に繋がる実践的な研修だと思います。 少しハードな面もあるかもしれませんが、このような研修を乗り越え、医療ヘルスケア分野の課題解決に取り組みたい学生エンジニアのみなさん、少しでも興味を持っていただけると幸いです。 もちろん中途エンジニアの方もぜひお気軽にお話をしましょう。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。 ジョブメドレー の開発チームでエンジニアをしている新居です。 はじめに 2020 年 4 月に、新卒エンジニア 3 名が入社しました。 入社後は新卒エンジニア研修を実施し、先日 8 月 25 日の最終報告会をもって終了しました。 コロナウイルスの影響で入社間もなくフルリモート勤務となり、不慣れなところもありましたが、本年度の研修の取り組みを紹介します。 2020 年度新卒エンジニア 研修の概要 メドレーでは昨年度から新卒エンジニアを迎えており、合わせて研修も開始しました。 初めての研修をどのような視点で計画・実施したかについては、昨年平木がこちらにまとめています。 2019 年度エンジニア新卒の研修について - Medley Developer Blog 今年は人事部のご協力もいただきながら、昨年の内容を少しアップデートして行いました。 研修の目的は、 新卒メンバーが同じ空間で互いに刺激し合いながら、社会人への思考転換をはかり、業務遂行に必要となる基礎知識とスキルを習得すること です。 研修は以下の 4 つのフェーズに区切って行いました。 研修のフェーズ 研修の内容 ここから 4 つのフェーズ毎に内容を紹介します。 フェーズ 1：社会人&メドレー基礎研修 1. オリエンテーション メドレーの事業や組織、大切にしている行動規範などの概要説明 セキュリティ研修とコンプライアンス研修 2. ビジネス研修 ビジネスマナー研修 ビジネススキル研修 ビジネススタンス研修（外部研修） フェーズ 1 では「医療ヘルスケアの未来をつくる」メンバーの一員として大切にして欲しいことを学ぶフェーズでした。 社会人としての最低限のマナーやスタンスは勿論ですが、メドレーで働く上で土台となるマインドをここで学び、 医療ヘルスケア分野の課題を解決する一員 として共にプロダクトを作るためのベースを築けたと思います。 フェーズ 2：エンジニア基礎研修 1. 開発基礎 1 講義「メドレーが求めるエンジニアとは」 ジョブメドレー と CLINICS の事業・プロダクトについての概要説明 Ruby on Rails（以下 Rails）の基礎トレーニング 2. 開発実践 チーム開発体験 3. 開発基礎 2 書籍 『Web を支える技術 -HTTP、URI、HTML、そして REST』 の輪読会 ドキュメンテーション研修とプレゼンテーション研修 中間報告会の準備と実施 フェーズ 2 から開発の研修がスタートしました。 開発基礎 1 開発の研修に入る前に、エンジニアの執行役員 田中から「メドレーが求めるエンジニアとは」というテーマで講義を行いました。メドレーがどういうエンジニアを求めているのか、目指すところの視点合わせを行い、これから行う研修に対する意識や取り組みの質を上げることを目指しました。 メドレーが求めるエンジニア像については CTO 平山の記事にも詳しく書いています。 メドレー平山の中央突破: THE エンジニア その後ジョブメドレーと CLINICS の事業・プロダクトについての概要説明、Rails の基礎トレーニングを行いました。メドレーのプロダクトは Rails 製です。Rails やウェブアプリケーション開発に慣れていない新卒メンバーは、Rails の基礎トレーニングで Ruby on Rails チュートリアル を使って基礎からみっちり学びます。 Ruby on Rails チュートリアルの進め方 ここで大切なことは、漠然とひたすら写経してチュートリアルを進めるのではなく、毎日のフィードバック会でしっかりその日の進捗や学びを共有し、不明点はメンターに質問してもらうようにすることです。 メンターは、新卒メンバーが理解が浅いまま進めてたり、理解していて欲しいところがいい加減になってたり、進め方や学びの方向性がズレてる場合などはアドバイスを入れて軌道修正することを心掛けました。 また「実際の開発ではこうだよ」といった実務を踏まえたアドバイスや、意識していることも伝えていきました。 20 新卒 S さんの感想 「毎日のフィードバック会の中で、その日学んだ技術がジョブメドレーではどのように利用されているのか、どういったことに留意して利用しているのかなどを確認できたので、現場の人の感覚を少しずつ知ることができた。」 新卒メンバーは毎日リズム良く進捗を出し、メンターは新卒メンバーのフォローと引き上げを意識し、成果を最大化できるよう努めました。 開発実践 続いて開発実践ではチーム開発を行いました。前回までは各自個別に進めていましたが、ここではジョブメドレーに関する課題解決を目的としたプロジェクトに対して、チームで向き合う研修でした。 開発実践の目的と達成すべきこと 実務ではチーム開発が基本となり、チームメンバーとの協働は必須です。学生時代に業務レベルのチーム開発を経験しているのは稀ですし、実務に入る前にチームでプロジェクト推進するとはどういうことかを知るのは、とても価値があると思います。 加えて、チームで課題をどう解決していくのかも、新卒メンバー同士で話し合って決める必要があるので、課題解決力も養われたと思います。 今回はプロトタイプを作って成果発表するところまででしたが、プロジェクト推進においてはスケジューリング、要件定義、各種設計、開発フローやコミュニケーションフローの整備、実装、テスト、などなど、やることは尽きません。 また、このプロセスの中で密なコミュニケーションが必要不可欠となるので、新卒メンバー間のチームワークも向上し、お互いのことを更に知ることができたと思います。 この段階で、チームでプロジェクトを推進することの全体感を知り、プロジェクト推進の苦悩苦闘を実体験できたのは大きな経験値になったと思います。 20 新卒 O さんの感想 「各機能の影響を互いに受けないためにブランチを細分化するブランチ戦略や GitHub を用いたコード管理について理解できた。一方で、UI を考える際にチームの各メンバーの認識のズレが生じたことや、序盤は各メンバーの進捗の詳細を把握できていなかったことから報・連・相の重要性を再認識した。」 20 新卒 T さんの感想 「初めてのチーム開発であったことから、実装の序盤は、どのファイルなら編集しても他のメンバーの作業に影響がないのか、動作確認のための画面を作るファイルは自由に作成して良いのか、どのテーブルから関係する他のテーブルの情報を含めた情報を取得をするかなどに悩んでいた。今になって振り返るとチーム内で話せば解決することに対して、技術的にも心理的にも難しさを感じた。」 ###開発基礎 2 フェーズ 2 最後の開発基礎 2 では、書籍 『Web を支える技術 -HTTP、URI、HTML、そして REST』 の輪読会を行いました。もっと前のフェーズでの実施も検討しましたが、開発基礎 1 と開発実践を経た後の方が書籍の内容の納得感が高くなるだろうという判断で、この段階での実施となりました。 その後、中間報告会に向けたドキュメンテーション研修とプレゼンテーション研修を行いました。仕事を進めていく上では、背景や目的を正しくステークホルダーへ共有しながら進めていくことが必要で、伝えたいことを適切に文章として整理し、他者へ分かりやすく伝えていくことが求められます。中間報告会では、そういったことを意識しながらこれまでの研修でやってきたことや成果、学びをレポートにまとめ、プロダクト開発室の室長と副室長、メンター陣の前でプレゼンテーションして報告しました。 フェーズ 3：事業部 OJT 1.代表取締役医師 豊田の講義 日本における医療制度の課題とそれに対するメドレーの位置付けについての講義 2.ジョブメドレー開発 OJT ジョブメドレーの実際の開発 Issue に対応し、ジョブメドレーの開発プロセスを体験 フェーズ 3 の最初は豊田代表の講義を受けました。基礎的な研修を終え、ジョブメドレー開発 OJT に入る前にメドレー社の社会的意義などを改めて代表から伝えていただきました。 続いて、ジョブメドレー開発 OJT は以下の狙いを持って進めました。 ジョブメドレー開発 OJT の狙い 実際に行ったことは、手始めに小さい不具合系 Issue の対応に取り組んだ後、サーバーレスポンス改善の Issue に取り組むというものでした。 サーバーレスポンスの改善は、1 人 1 画面を担当し、「プロファイルツールで分析 → 改善できそうな箇所を調査 → 改善方針の検討 → 提案 → 実装 → レビュー → リリース」というサイクルを回しました。 1 つ目の Issue 対応でも心掛けたことですが、言われたものを実装するのではなく、 ある課題を解決するためにどうしたら良いかを自分で主体的に考えることを重視しました。実装力と同じくらい課題解決力も大切にしているためです。 とはいえ成果が何も出せないというのは、精神衛生上良くないので、日々の朝会と夕会にて進捗や状況をしっかり確認しながら適宜フォローやインプットを行い、ヒントになりそうな過去 Issue のリンクを渡して参考にしてもらったり、メンターの適切なバックアップも必要です。 今回の OJT を通じて実務を知ることで、実際にエンジニアとして仕事をするイメージが沸き、同時に仕事をする上で足りないことも明確になります。自分の課題と向き合うことで、直近の自身の学習プランの軌道修正もできます。 課題は簡単なものではありませんでしたが、最終的に 1 人 1 つ以上のサーバーレスポンス改善 PR をリリースすることができました。 S さんの感想 「速度パフォーマンスの悪いコードに対する嗅覚、オブジェクトを生成しすぎていないか、無駄に通信を走らせていないかなどを学べた。」 O さんの感想 「Issue を本質的に解決するメドレーの開発姿勢について学んだ。Issue を表面的に解決するのではなく、背景や目的、関連するコードなどの不明点を調査し、十分に理解・納得した上で修正することの意識付けができた。また、Issue に関連する一部分のコードを修正すれば良いという狭い視野を持たず、修正による影響範囲を考慮した上で全体の最適化を考えることが重要であると学んだ。」 フェーズ 4：最終報告 1. 最終報告会 最終報告会の準備と実施 最後のフェーズ 4 では、これまでの研修でやってきたことや成果、学びをレポートにまとめ、役員陣の前でプレゼンテーションして報告しました。 役員陣の前なので緊張は最高潮になりますが、自分達が研修を通じて何を得てどう成長したか、今後どういうエンジニアを目指していくのか、などを役員陣の前でアピールする貴重な機会となりました。 1 人 10 分の枠内で役員陣にどういう情報をどういう表現でプレゼンテーションするかを考える機会にもなったので、情報整理力や表現力が培われる場にもなりました。 さいごに 2020 年度の新卒エンジニア研修も無事終了することができました。改めて、新卒メンバーのみなさん、関係者のみなさん本当にお疲れ様でした。 振り返ると、メドレー社員としてのマインドや開発の基本的なことをしっかりインプットしつつ、新卒メンバーが主体的に課題解決に取り組む研修ができたように思います。 必要な技術スタックを 1 から 10 まで懇切丁寧に資料に落とし込み、講義形式で行う研修も身になることは多いですが、 メドレーの研修のような課題解決を実体験する研修はより実務に繋がる実践的な研修だと思います。 少しハードな面もあるかもしれませんが、このような研修を乗り越え、医療ヘルスケア分野の課題解決に取り組みたい学生エンジニアのみなさん、少しでも興味を持っていただけると幸いです。 もちろん中途エンジニアの方もぜひお気軽にお話をしましょう。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。 ジョブメドレー の開発チームでエンジニアをしている新居です。 はじめに 2020 年 4 月に、新卒エンジニア 3 名が入社しました。 入社後は新卒エンジニア研修を実施し、先日 8 月 25 日の最終報告会をもって終了しました。 コロナウイルスの影響で入社間もなくフルリモート勤務となり、不慣れなところもありましたが、本年度の研修の取り組みを紹介します。 2020 年度新卒エンジニア 研修の概要 メドレーでは昨年度から新卒エンジニアを迎えており、合わせて研修も開始しました。 初めての研修をどのような視点で計画・実施したかについては、昨年平木がこちらにまとめています。 2019 年度エンジニア新卒の研修について - Medley Developer Blog 今年は人事部のご協力もいただきながら、昨年の内容を少しアップデートして行いました。 研修の目的は、 新卒メンバーが同じ空間で互いに刺激し合いながら、社会人への思考転換をはかり、業務遂行に必要となる基礎知識とスキルを習得すること です。 研修は以下の 4 つのフェーズに区切って行いました。 研修のフェーズ 研修の内容 ここから 4 つのフェーズ毎に内容を紹介します。 フェーズ 1：社会人&メドレー基礎研修 1. オリエンテーション メドレーの事業や組織、大切にしている行動規範などの概要説明 セキュリティ研修とコンプライアンス研修 2. ビジネス研修 ビジネスマナー研修 ビジネススキル研修 ビジネススタンス研修（外部研修） フェーズ 1 では「医療ヘルスケアの未来をつくる」メンバーの一員として大切にして欲しいことを学ぶフェーズでした。 社会人としての最低限のマナーやスタンスは勿論ですが、メドレーで働く上で土台となるマインドをここで学び、 医療ヘルスケア分野の課題を解決する一員 として共にプロダクトを作るためのベースを築けたと思います。 フェーズ 2：エンジニア基礎研修 1. 開発基礎 1 講義「メドレーが求めるエンジニアとは」 ジョブメドレー と CLINICS の事業・プロダクトについての概要説明 Ruby on Rails（以下 Rails）の基礎トレーニング 2. 開発実践 チーム開発体験 3. 開発基礎 2 書籍 『Web を支える技術 -HTTP、URI、HTML、そして REST』 の輪読会 ドキュメンテーション研修とプレゼンテーション研修 中間報告会の準備と実施 フェーズ 2 から開発の研修がスタートしました。 開発基礎 1 開発の研修に入る前に、エンジニアの執行役員 田中から「メドレーが求めるエンジニアとは」というテーマで講義を行いました。メドレーがどういうエンジニアを求めているのか、目指すところの視点合わせを行い、これから行う研修に対する意識や取り組みの質を上げることを目指しました。 メドレーが求めるエンジニア像については CTO 平山の記事にも詳しく書いています。 メドレー平山の中央突破: THE エンジニア その後ジョブメドレーと CLINICS の事業・プロダクトについての概要説明、Rails の基礎トレーニングを行いました。メドレーのプロダクトは Rails 製です。Rails やウェブアプリケーション開発に慣れていない新卒メンバーは、Rails の基礎トレーニングで Ruby on Rails チュートリアル を使って基礎からみっちり学びます。 Ruby on Rails チュートリアルの進め方 ここで大切なことは、漠然とひたすら写経してチュートリアルを進めるのではなく、毎日のフィードバック会でしっかりその日の進捗や学びを共有し、不明点はメンターに質問してもらうようにすることです。 メンターは、新卒メンバーが理解が浅いまま進めてたり、理解していて欲しいところがいい加減になってたり、進め方や学びの方向性がズレてる場合などはアドバイスを入れて軌道修正することを心掛けました。 また「実際の開発ではこうだよ」といった実務を踏まえたアドバイスや、意識していることも伝えていきました。 20 新卒 S さんの感想 「毎日のフィードバック会の中で、その日学んだ技術がジョブメドレーではどのように利用されているのか、どういったことに留意して利用しているのかなどを確認できたので、現場の人の感覚を少しずつ知ることができた。」 新卒メンバーは毎日リズム良く進捗を出し、メンターは新卒メンバーのフォローと引き上げを意識し、成果を最大化できるよう努めました。 開発実践 続いて開発実践ではチーム開発を行いました。前回までは各自個別に進めていましたが、ここではジョブメドレーに関する課題解決を目的としたプロジェクトに対して、チームで向き合う研修でした。 開発実践の目的と達成すべきこと 実務ではチーム開発が基本となり、チームメンバーとの協働は必須です。学生時代に業務レベルのチーム開発を経験しているのは稀ですし、実務に入る前にチームでプロジェクト推進するとはどういうことかを知るのは、とても価値があると思います。 加えて、チームで課題をどう解決していくのかも、新卒メンバー同士で話し合って決める必要があるので、課題解決力も養われたと思います。 今回はプロトタイプを作って成果発表するところまででしたが、プロジェクト推進においてはスケジューリング、要件定義、各種設計、開発フローやコミュニケーションフローの整備、実装、テスト、などなど、やることは尽きません。 また、このプロセスの中で密なコミュニケーションが必要不可欠となるので、新卒メンバー間のチームワークも向上し、お互いのことを更に知ることができたと思います。 この段階で、チームでプロジェクトを推進することの全体感を知り、プロジェクト推進の苦悩苦闘を実体験できたのは大きな経験値になったと思います。 20 新卒 O さんの感想 「各機能の影響を互いに受けないためにブランチを細分化するブランチ戦略や GitHub を用いたコード管理について理解できた。一方で、UI を考える際にチームの各メンバーの認識のズレが生じたことや、序盤は各メンバーの進捗の詳細を把握できていなかったことから報・連・相の重要性を再認識した。」 20 新卒 T さんの感想 「初めてのチーム開発であったことから、実装の序盤は、どのファイルなら編集しても他のメンバーの作業に影響がないのか、動作確認のための画面を作るファイルは自由に作成して良いのか、どのテーブルから関係する他のテーブルの情報を含めた情報を取得をするかなどに悩んでいた。今になって振り返るとチーム内で話せば解決することに対して、技術的にも心理的にも難しさを感じた。」 ###開発基礎 2 フェーズ 2 最後の開発基礎 2 では、書籍 『Web を支える技術 -HTTP、URI、HTML、そして REST』 の輪読会を行いました。もっと前のフェーズでの実施も検討しましたが、開発基礎 1 と開発実践を経た後の方が書籍の内容の納得感が高くなるだろうという判断で、この段階での実施となりました。 その後、中間報告会に向けたドキュメンテーション研修とプレゼンテーション研修を行いました。仕事を進めていく上では、背景や目的を正しくステークホルダーへ共有しながら進めていくことが必要で、伝えたいことを適切に文章として整理し、他者へ分かりやすく伝えていくことが求められます。中間報告会では、そういったことを意識しながらこれまでの研修でやってきたことや成果、学びをレポートにまとめ、プロダクト開発室の室長と副室長、メンター陣の前でプレゼンテーションして報告しました。 フェーズ 3：事業部 OJT 1.代表取締役医師 豊田の講義 日本における医療制度の課題とそれに対するメドレーの位置付けについての講義 2.ジョブメドレー開発 OJT ジョブメドレーの実際の開発 Issue に対応し、ジョブメドレーの開発プロセスを体験 フェーズ 3 の最初は豊田代表の講義を受けました。基礎的な研修を終え、ジョブメドレー開発 OJT に入る前にメドレー社の社会的意義などを改めて代表から伝えていただきました。 続いて、ジョブメドレー開発 OJT は以下の狙いを持って進めました。 ジョブメドレー開発 OJT の狙い 実際に行ったことは、手始めに小さい不具合系 Issue の対応に取り組んだ後、サーバーレスポンス改善の Issue に取り組むというものでした。 サーバーレスポンスの改善は、1 人 1 画面を担当し、「プロファイルツールで分析 → 改善できそうな箇所を調査 → 改善方針の検討 → 提案 → 実装 → レビュー → リリース」というサイクルを回しました。 1 つ目の Issue 対応でも心掛けたことですが、言われたものを実装するのではなく、 ある課題を解決するためにどうしたら良いかを自分で主体的に考えることを重視しました。実装力と同じくらい課題解決力も大切にしているためです。 とはいえ成果が何も出せないというのは、精神衛生上良くないので、日々の朝会と夕会にて進捗や状況をしっかり確認しながら適宜フォローやインプットを行い、ヒントになりそうな過去 Issue のリンクを渡して参考にしてもらったり、メンターの適切なバックアップも必要です。 今回の OJT を通じて実務を知ることで、実際にエンジニアとして仕事をするイメージが沸き、同時に仕事をする上で足りないことも明確になります。自分の課題と向き合うことで、直近の自身の学習プランの軌道修正もできます。 課題は簡単なものではありませんでしたが、最終的に 1 人 1 つ以上のサーバーレスポンス改善 PR をリリースすることができました。 S さんの感想 「速度パフォーマンスの悪いコードに対する嗅覚、オブジェクトを生成しすぎていないか、無駄に通信を走らせていないかなどを学べた。」 O さんの感想 「Issue を本質的に解決するメドレーの開発姿勢について学んだ。Issue を表面的に解決するのではなく、背景や目的、関連するコードなどの不明点を調査し、十分に理解・納得した上で修正することの意識付けができた。また、Issue に関連する一部分のコードを修正すれば良いという狭い視野を持たず、修正による影響範囲を考慮した上で全体の最適化を考えることが重要であると学んだ。」 フェーズ 4：最終報告 1. 最終報告会 最終報告会の準備と実施 最後のフェーズ 4 では、これまでの研修でやってきたことや成果、学びをレポートにまとめ、役員陣の前でプレゼンテーションして報告しました。 役員陣の前なので緊張は最高潮になりますが、自分達が研修を通じて何を得てどう成長したか、今後どういうエンジニアを目指していくのか、などを役員陣の前でアピールする貴重な機会となりました。 1 人 10 分の枠内で役員陣にどういう情報をどういう表現でプレゼンテーションするかを考える機会にもなったので、情報整理力や表現力が培われる場にもなりました。 さいごに 2020 年度の新卒エンジニア研修も無事終了することができました。改めて、新卒メンバーのみなさん、関係者のみなさん本当にお疲れ様でした。 振り返ると、メドレー社員としてのマインドや開発の基本的なことをしっかりインプットしつつ、新卒メンバーが主体的に課題解決に取り組む研修ができたように思います。 必要な技術スタックを 1 から 10 まで懇切丁寧に資料に落とし込み、講義形式で行う研修も身になることは多いですが、 メドレーの研修のような課題解決を実体験する研修はより実務に繋がる実践的な研修だと思います。 少しハードな面もあるかもしれませんが、このような研修を乗り越え、医療ヘルスケア分野の課題解決に取り組みたい学生エンジニアのみなさん、少しでも興味を持っていただけると幸いです。 もちろん中途エンジニアの方もぜひお気軽にお話をしましょう。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。 ジョブメドレー の開発チームでエンジニアをしている新居です。 はじめに 2020 年 4 月に、新卒エンジニア 3 名が入社しました。 入社後は新卒エンジニア研修を実施し、先日 8 月 25 日の最終報告会をもって終了しました。 コロナウイルスの影響で入社間もなくフルリモート勤務となり、不慣れなところもありましたが、本年度の研修の取り組みを紹介します。 2020 年度新卒エンジニア 研修の概要 メドレーでは昨年度から新卒エンジニアを迎えており、合わせて研修も開始しました。 初めての研修をどのような視点で計画・実施したかについては、昨年平木がこちらにまとめています。 2019 年度エンジニア新卒の研修について - Medley Developer Blog 今年は人事部のご協力もいただきながら、昨年の内容を少しアップデートして行いました。 研修の目的は、 新卒メンバーが同じ空間で互いに刺激し合いながら、社会人への思考転換をはかり、業務遂行に必要となる基礎知識とスキルを習得すること です。 研修は以下の 4 つのフェーズに区切って行いました。 研修のフェーズ 研修の内容 ここから 4 つのフェーズ毎に内容を紹介します。 フェーズ 1：社会人&メドレー基礎研修 1. オリエンテーション メドレーの事業や組織、大切にしている行動規範などの概要説明 セキュリティ研修とコンプライアンス研修 2. ビジネス研修 ビジネスマナー研修 ビジネススキル研修 ビジネススタンス研修（外部研修） フェーズ 1 では「医療ヘルスケアの未来をつくる」メンバーの一員として大切にして欲しいことを学ぶフェーズでした。 社会人としての最低限のマナーやスタンスは勿論ですが、メドレーで働く上で土台となるマインドをここで学び、 医療ヘルスケア分野の課題を解決する一員 として共にプロダクトを作るためのベースを築けたと思います。 フェーズ 2：エンジニア基礎研修 1. 開発基礎 1 講義「メドレーが求めるエンジニアとは」 ジョブメドレー と CLINICS の事業・プロダクトについての概要説明 Ruby on Rails（以下 Rails）の基礎トレーニング 2. 開発実践 チーム開発体験 3. 開発基礎 2 書籍 『Web を支える技術 -HTTP、URI、HTML、そして REST』 の輪読会 ドキュメンテーション研修とプレゼンテーション研修 中間報告会の準備と実施 フェーズ 2 から開発の研修がスタートしました。 開発基礎 1 開発の研修に入る前に、エンジニアの執行役員 田中から「メドレーが求めるエンジニアとは」というテーマで講義を行いました。メドレーがどういうエンジニアを求めているのか、目指すところの視点合わせを行い、これから行う研修に対する意識や取り組みの質を上げることを目指しました。 メドレーが求めるエンジニア像については CTO 平山の記事にも詳しく書いています。 メドレー平山の中央突破: THE エンジニア その後ジョブメドレーと CLINICS の事業・プロダクトについての概要説明、Rails の基礎トレーニングを行いました。メドレーのプロダクトは Rails 製です。Rails やウェブアプリケーション開発に慣れていない新卒メンバーは、Rails の基礎トレーニングで Ruby on Rails チュートリアル を使って基礎からみっちり学びます。 Ruby on Rails チュートリアルの進め方 ここで大切なことは、漠然とひたすら写経してチュートリアルを進めるのではなく、毎日のフィードバック会でしっかりその日の進捗や学びを共有し、不明点はメンターに質問してもらうようにすることです。 メンターは、新卒メンバーが理解が浅いまま進めてたり、理解していて欲しいところがいい加減になってたり、進め方や学びの方向性がズレてる場合などはアドバイスを入れて軌道修正することを心掛けました。 また「実際の開発ではこうだよ」といった実務を踏まえたアドバイスや、意識していることも伝えていきました。 20 新卒 S さんの感想 「毎日のフィードバック会の中で、その日学んだ技術がジョブメドレーではどのように利用されているのか、どういったことに留意して利用しているのかなどを確認できたので、現場の人の感覚を少しずつ知ることができた。」 新卒メンバーは毎日リズム良く進捗を出し、メンターは新卒メンバーのフォローと引き上げを意識し、成果を最大化できるよう努めました。 開発実践 続いて開発実践ではチーム開発を行いました。前回までは各自個別に進めていましたが、ここではジョブメドレーに関する課題解決を目的としたプロジェクトに対して、チームで向き合う研修でした。 開発実践の目的と達成すべきこと 実務ではチーム開発が基本となり、チームメンバーとの協働は必須です。学生時代に業務レベルのチーム開発を経験しているのは稀ですし、実務に入る前にチームでプロジェクト推進するとはどういうことかを知るのは、とても価値があると思います。 加えて、チームで課題をどう解決していくのかも、新卒メンバー同士で話し合って決める必要があるので、課題解決力も養われたと思います。 今回はプロトタイプを作って成果発表するところまででしたが、プロジェクト推進においてはスケジューリング、要件定義、各種設計、開発フローやコミュニケーションフローの整備、実装、テスト、などなど、やることは尽きません。 また、このプロセスの中で密なコミュニケーションが必要不可欠となるので、新卒メンバー間のチームワークも向上し、お互いのことを更に知ることができたと思います。 この段階で、チームでプロジェクトを推進することの全体感を知り、プロジェクト推進の苦悩苦闘を実体験できたのは大きな経験値になったと思います。 20 新卒 O さんの感想 「各機能の影響を互いに受けないためにブランチを細分化するブランチ戦略や GitHub を用いたコード管理について理解できた。一方で、UI を考える際にチームの各メンバーの認識のズレが生じたことや、序盤は各メンバーの進捗の詳細を把握できていなかったことから報・連・相の重要性を再認識した。」 20 新卒 T さんの感想 「初めてのチーム開発であったことから、実装の序盤は、どのファイルなら編集しても他のメンバーの作業に影響がないのか、動作確認のための画面を作るファイルは自由に作成して良いのか、どのテーブルから関係する他のテーブルの情報を含めた情報を取得をするかなどに悩んでいた。今になって振り返るとチーム内で話せば解決することに対して、技術的にも心理的にも難しさを感じた。」 ###開発基礎 2 フェーズ 2 最後の開発基礎 2 では、書籍 『Web を支える技術 -HTTP、URI、HTML、そして REST』 の輪読会を行いました。もっと前のフェーズでの実施も検討しましたが、開発基礎 1 と開発実践を経た後の方が書籍の内容の納得感が高くなるだろうという判断で、この段階での実施となりました。 その後、中間報告会に向けたドキュメンテーション研修とプレゼンテーション研修を行いました。仕事を進めていく上では、背景や目的を正しくステークホルダーへ共有しながら進めていくことが必要で、伝えたいことを適切に文章として整理し、他者へ分かりやすく伝えていくことが求められます。中間報告会では、そういったことを意識しながらこれまでの研修でやってきたことや成果、学びをレポートにまとめ、プロダクト開発室の室長と副室長、メンター陣の前でプレゼンテーションして報告しました。 フェーズ 3：事業部 OJT 1.代表取締役医師 豊田の講義 日本における医療制度の課題とそれに対するメドレーの位置付けについての講義 2.ジョブメドレー開発 OJT ジョブメドレーの実際の開発 Issue に対応し、ジョブメドレーの開発プロセスを体験 フェーズ 3 の最初は豊田代表の講義を受けました。基礎的な研修を終え、ジョブメドレー開発 OJT に入る前にメドレー社の社会的意義などを改めて代表から伝えていただきました。 続いて、ジョブメドレー開発 OJT は以下の狙いを持って進めました。 ジョブメドレー開発 OJT の狙い 実際に行ったことは、手始めに小さい不具合系 Issue の対応に取り組んだ後、サーバーレスポンス改善の Issue に取り組むというものでした。 サーバーレスポンスの改善は、1 人 1 画面を担当し、「プロファイルツールで分析 → 改善できそうな箇所を調査 → 改善方針の検討 → 提案 → 実装 → レビュー → リリース」というサイクルを回しました。 1 つ目の Issue 対応でも心掛けたことですが、言われたものを実装するのではなく、 ある課題を解決するためにどうしたら良いかを自分で主体的に考えることを重視しました。実装力と同じくらい課題解決力も大切にしているためです。 とはいえ成果が何も出せないというのは、精神衛生上良くないので、日々の朝会と夕会にて進捗や状況をしっかり確認しながら適宜フォローやインプットを行い、ヒントになりそうな過去 Issue のリンクを渡して参考にしてもらったり、メンターの適切なバックアップも必要です。 今回の OJT を通じて実務を知ることで、実際にエンジニアとして仕事をするイメージが沸き、同時に仕事をする上で足りないことも明確になります。自分の課題と向き合うことで、直近の自身の学習プランの軌道修正もできます。 課題は簡単なものではありませんでしたが、最終的に 1 人 1 つ以上のサーバーレスポンス改善 PR をリリースすることができました。 S さんの感想 「速度パフォーマンスの悪いコードに対する嗅覚、オブジェクトを生成しすぎていないか、無駄に通信を走らせていないかなどを学べた。」 O さんの感想 「Issue を本質的に解決するメドレーの開発姿勢について学んだ。Issue を表面的に解決するのではなく、背景や目的、関連するコードなどの不明点を調査し、十分に理解・納得した上で修正することの意識付けができた。また、Issue に関連する一部分のコードを修正すれば良いという狭い視野を持たず、修正による影響範囲を考慮した上で全体の最適化を考えることが重要であると学んだ。」 フェーズ 4：最終報告 1. 最終報告会 最終報告会の準備と実施 最後のフェーズ 4 では、これまでの研修でやってきたことや成果、学びをレポートにまとめ、役員陣の前でプレゼンテーションして報告しました。 役員陣の前なので緊張は最高潮になりますが、自分達が研修を通じて何を得てどう成長したか、今後どういうエンジニアを目指していくのか、などを役員陣の前でアピールする貴重な機会となりました。 1 人 10 分の枠内で役員陣にどういう情報をどういう表現でプレゼンテーションするかを考える機会にもなったので、情報整理力や表現力が培われる場にもなりました。 さいごに 2020 年度の新卒エンジニア研修も無事終了することができました。改めて、新卒メンバーのみなさん、関係者のみなさん本当にお疲れ様でした。 振り返ると、メドレー社員としてのマインドや開発の基本的なことをしっかりインプットしつつ、新卒メンバーが主体的に課題解決に取り組む研修ができたように思います。 必要な技術スタックを 1 から 10 まで懇切丁寧に資料に落とし込み、講義形式で行う研修も身になることは多いですが、 メドレーの研修のような課題解決を実体験する研修はより実務に繋がる実践的な研修だと思います。 少しハードな面もあるかもしれませんが、このような研修を乗り越え、医療ヘルスケア分野の課題解決に取り組みたい学生エンジニアのみなさん、少しでも興味を持っていただけると幸いです。 もちろん中途エンジニアの方もぜひお気軽にお話をしましょう。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

自己紹介 株式会社メドレーのエンジニア阪本です。 9 月に入っても暑い日が続く中、皆さんはいかがお過ごしでしょうか。 前回のブログでも書きましたが私は野球観戦（虎党）が趣味で、毎日の試合結果に一喜一憂しています。 このブログの執筆時点ではセ・リーグは首位巨人にマジックが点灯し、残試合 50 を切った状況でのゲーム差 10。優勝を目指す阪神にとっては厳しい状況となりましたが、残り直接対決をすべて勝てば可能性は見えてくるはず。ここは諦めずに応援しようと思います。 次の記事を書く頃には何らかの決着が着いていると思いますので、その時には喜びのメッセージが書ける事を願っています。 はじめに 突然ですが、皆さんは Fargate を使いこなしていますか？ 今まで ECS(EC2)での運用がメインでしたが、ジョブメドレーのシステムでも Fargate に触れる機会が増えてきました。 筆者自身は初めての Fargate でしたが、EC2 の存在が無くなることに不思議な感覚を覚えつつも、管理するものが減って運用が楽になったと実感しています。 しかし、EC2 が無くなった事によりサーバ内にターミナルで入る手段を失いました。 公式の ガイド では 質問２：コンテナの中に ssh や docker exec で入ることは出来ますか？ こちら現状サポートしておりませんが、コンテナワークロードでは「 同一の環境でしっかりテストを行う 」ことや「 ログを外部に全て出す 」ことがベストプラクティスとされていて、コンテナに入る必要性を出来る限り減らす方が将来的にも好ましいです。 と「事前にテストを十分に実施する」「ログは(S3 や CloudWatchLogs など)外部に出力する」 さえ出来ていれば入る必要が無いはずと記載されているものの・・・心配性な自分は不測の事態が発生した時の事を考えてサーバに入る手段を求めてしまいます。 そこで代替手段を模索していた所、 SessionManager を使えば可能との文献を見つけました。 すでに SessionManager 自体は EC2 に対して運用を行っていたため導入の敷居は低いと考え、この手段を採用することにしました。 Session Manager とは？ Session Manager とは AWS の Systems Manager サービスの 1 機能で、AWS 上で管理しているサーバ（マネージドインスタンス）に対してターミナルのアクセスを可能にするものです。 ターミナルへのアクセス手段は、よくある手段だと SSH がありますが この方法は SSH ポートを外部に開放する必要があるため攻撃の対象になりやすく、あまり好ましくありません。 それに比べて Session Manager は SSH ポートの開放は不要でサーバから見てアウトバウンド方向の HTTPS 通信の確保で済む為、外部からの攻撃も受けず安全にアクセス経路の確保が実現できます。 ※通信経路の確保以外にも IAM ロールの設定などが必要となります。詳しくは こちら を参考 「AWS 上で管理しているサーバ」と先に記載しましたが、このサーバは EC2 インスタンスに限らないのが本記事の重要なポイントになります。 オンプレミスなサーバも AWS 上で管理されているのであれば、SessionManager エージェントをインストールする事により管理対象に含めることが可能になるのです。 今回は EC2 で動いていた SessionManager エージェントを Fargate で動くコンテナにインストールする事によりコンテナ自体をサーバと見立ててマネージドインスタンスとし、SessionManager でアクセスする事を目指します。 対応 Systems Manager インスタンス枠をスタンダードからアドバンスドに変更する ／ AWS コンソールでの設定 オンプレミスなサーバに SessionManager にてアクセスする場合、Systems Manager のオンプレミスインスタンスティアを スタンダードからアドバンスドへと変更する必要 があります。 この変更作業は AWS コンソールから行う事になりますが、アドバンスドへの変更に当たって既存のマネージドインスタンスに影響することはありません。 ただし、この逆の場合、スタンダードに戻す際には考慮が必要となるので こちら を参照ください。 SSM Agent のインストール ／ コンテナに対する設定 ここからは実際に動くコンテナに対する設定になります。 AWS のドキュメント 手動でインストール SSM エージェント EC2 で Linux のインスタンス を参考に、OS に合った方法で SessionManager エージェントのインストールを行います。 インストール作業には通信などの時間が必要となるので、事前にコンテナイメージにインストールする形としました。 コンテナをマネージドインスタンスとして登録する ／ コンテナに対する設定 コンテナをマネージドインスタンスとして登録するため、コンテナのスタートアップ(Entrypoint)にて下記スクリプトを実行します。 # 1. ハイブリッドアクティベーションの作成 SSM_ACTIVATE_INFO = ` aws ssm create-activation --iam-role service-role/AmazonEC2RunCommandRoleForManagedInstances --registration-limit 1 --region ap-northeast-1 --default-instance-name medley-blog-fargate-container` # 2. アウトプットからアクティベーションコード/ID の抽出 SSM_ACTIVATE_CODE = ` echo $SSM_ACTIVATE_INFO | jq -r '.ActivationCode'` SSM_ACTIVATE_ID = ` echo $SSM_ACTIVATE_INFO | jq -r '.ActivationId'` # 3. コンテナ自身をマネージドインスタンスへの登録 amazon-ssm-agent -register -code $SSM_ACTIVATE_CODE -id $SSM_ACTIVATE_ID -region "ap-northeast-1" # 4. SessionManager エージェントの起動 amazon-ssm-agent & これらのコマンドについては各行ごとに説明します 1.ハイブリッドアクティベーションの作成 マネージドインスタンス登録に必要なアクティベーションコード/ID 取得のため、ハイブリッドアクティベーションの登録を行います。 後々 AWS コンソールにてインスタンスの識別ができるように、 --default-instance-name オプションにて medley-blog-fargate-container という名前を付与しています。 このコマンドのアウトプットにて下記のような JSON が返される為、一旦変数に格納しています。 { "ActivationId" : "<<アクティベーション ID>>", "ActivationCode": "<<アクティベーションコード>>" } また --iam-role オプションでサービスロール AmazonEC2RunCommandRoleForManagedInstances を使っています。 このロールがまだ存在しない場合、AWS コンソールからハイブリッドアクティベーションから IAM ロール →「必要な権限を備えたシステムのデフォルトコマンド実行ロールを作成」により作成してください。 2. アウトプットからアクティベーションコード/ID の抽出 前項のアウトプットからアクティベーションコード/ID を個々の変数に分離しています。 3. コンテナ自身をマネージドインスタンスへの登録 取得したアクティベーションコード/ID を利用し、コンテナ自身をマネージドインスタンスとして登録します。 環境変数 AWS_DEFAULT_REGION のように AWS の Credential にてデフォルトの Region 設定があった場合でも、このコマンドではオプションで Region 指定が必須となるのでご注意ください。 4. SessionManager エージェントの起動 最後に SessionManager エージェントを起動します。 これにより AWS との通信が確立され、SessionManager が利用できるようになります。 この状態でマネージドインスタンス画面にて目的のインスタンスが「オンライン」であれば設定が完了です。 接続確認 設定が完了したので、実際に SessionManager にて接続してみます。 AWS コンソールのセッションマネージャからセッションの開始を選択し、名前が事前に登録した medley-blog-fargate-container であるものを選択します。 外見は他の EC2 と変わらない表示ですが、この手段で登録したものはインスタンス ID が mi から始まる ID になります(通常の EC2 は i から始まる ID)。 後は普段通りにセッションを開始するとコンテナ内へのアクセスが開始されます。 これで EC2 の無い Fargate 上のコンテナに対してもターミナルに入ることができました。 運用してみての感想 Fargate 上のコンテナに直接入ることにより、今まで出来なかった top コマンドによるプロセス状態の確認 df コマンドによる Disk 容量の確認 などの環境調査が出来るようになりました。 利用頻度が多い訳ではありませんが、調査の選択肢を増やす事により有事の際の早期対応に繋げれられていると感じています。 注意点 ここからは運用に当たっての注意点について数点紹介します。 料金 EC2 での SessionManager と違い、 この方法で登録したサーバへの SessionManager 通信は料金が発生します 。 正確には 「SessionManager エージェントが起動し AWS と通信が確立している状態」 での時間課金で SessionManager での接続有無は問いません。 よって、常時必要ではない場合は SessionManager エージェントを止めて節約する方法を検討してください。 アクティベーションやマネージドインスタンスがリストに残る コンテナ終了時でも AWS コンソールのハイブリッドアクティベーション一覧やマネージドインスタンス一覧に表示が残ってしまうようです。 一覧の上限の記載は見つからなかったものの、無限に増えるとも思えないので適時 Lambda を使って削除しています。 SessionManager での操作について EC2 インスタンスに対しての SessionManager と同様ですが、セッション開始直後のユーザは ssm-user 固定になるようです。 特定ユーザでの操作が必要となる場合、 su コマンドでのユーザ切り替えが必要になります。 さいごに 今回のようにメドレーでは新たな技術を取り入れつつ、サービスの安定を目的とした様々な施策を導入しています。 こういった働き方に興味を持たれた方、まずは下記リンクからお気軽にお話しませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

自己紹介 株式会社メドレーのエンジニア阪本です。 9 月に入っても暑い日が続く中、皆さんはいかがお過ごしでしょうか。 前回のブログでも書きましたが私は野球観戦（虎党）が趣味で、毎日の試合結果に一喜一憂しています。 このブログの執筆時点ではセ・リーグは首位巨人にマジックが点灯し、残試合 50 を切った状況でのゲーム差 10。優勝を目指す阪神にとっては厳しい状況となりましたが、残り直接対決をすべて勝てば可能性は見えてくるはず。ここは諦めずに応援しようと思います。 次の記事を書く頃には何らかの決着が着いていると思いますので、その時には喜びのメッセージが書ける事を願っています。 はじめに 突然ですが、皆さんは Fargate を使いこなしていますか？ 今まで ECS(EC2)での運用がメインでしたが、ジョブメドレーのシステムでも Fargate に触れる機会が増えてきました。 筆者自身は初めての Fargate でしたが、EC2 の存在が無くなることに不思議な感覚を覚えつつも、管理するものが減って運用が楽になったと実感しています。 しかし、EC2 が無くなった事によりサーバ内にターミナルで入る手段を失いました。 公式の ガイド では 質問２：コンテナの中に ssh や docker exec で入ることは出来ますか？ こちら現状サポートしておりませんが、コンテナワークロードでは「 同一の環境でしっかりテストを行う 」ことや「 ログを外部に全て出す 」ことがベストプラクティスとされていて、コンテナに入る必要性を出来る限り減らす方が将来的にも好ましいです。 と「事前にテストを十分に実施する」「ログは(S3 や CloudWatchLogs など)外部に出力する」 さえ出来ていれば入る必要が無いはずと記載されているものの・・・心配性な自分は不測の事態が発生した時の事を考えてサーバに入る手段を求めてしまいます。 そこで代替手段を模索していた所、 SessionManager を使えば可能との文献を見つけました。 すでに SessionManager 自体は EC2 に対して運用を行っていたため導入の敷居は低いと考え、この手段を採用することにしました。 Session Manager とは？ Session Manager とは AWS の Systems Manager サービスの 1 機能で、AWS 上で管理しているサーバ（マネージドインスタンス）に対してターミナルのアクセスを可能にするものです。 ターミナルへのアクセス手段は、よくある手段だと SSH がありますが この方法は SSH ポートを外部に開放する必要があるため攻撃の対象になりやすく、あまり好ましくありません。 それに比べて Session Manager は SSH ポートの開放は不要でサーバから見てアウトバウンド方向の HTTPS 通信の確保で済む為、外部からの攻撃も受けず安全にアクセス経路の確保が実現できます。 ※通信経路の確保以外にも IAM ロールの設定などが必要となります。詳しくは こちら を参考 「AWS 上で管理しているサーバ」と先に記載しましたが、このサーバは EC2 インスタンスに限らないのが本記事の重要なポイントになります。 オンプレミスなサーバも AWS 上で管理されているのであれば、SessionManager エージェントをインストールする事により管理対象に含めることが可能になるのです。 今回は EC2 で動いていた SessionManager エージェントを Fargate で動くコンテナにインストールする事によりコンテナ自体をサーバと見立ててマネージドインスタンスとし、SessionManager でアクセスする事を目指します。 対応 Systems Manager インスタンス枠をスタンダードからアドバンスドに変更する ／ AWS コンソールでの設定 オンプレミスなサーバに SessionManager にてアクセスする場合、Systems Manager のオンプレミスインスタンスティアを スタンダードからアドバンスドへと変更する必要 があります。 この変更作業は AWS コンソールから行う事になりますが、アドバンスドへの変更に当たって既存のマネージドインスタンスに影響することはありません。 ただし、この逆の場合、スタンダードに戻す際には考慮が必要となるので こちら を参照ください。 SSM Agent のインストール ／ コンテナに対する設定 ここからは実際に動くコンテナに対する設定になります。 AWS のドキュメント 手動でインストール SSM エージェント EC2 で Linux のインスタンス を参考に、OS に合った方法で SessionManager エージェントのインストールを行います。 インストール作業には通信などの時間が必要となるので、事前にコンテナイメージにインストールする形としました。 コンテナをマネージドインスタンスとして登録する ／ コンテナに対する設定 コンテナをマネージドインスタンスとして登録するため、コンテナのスタートアップ(Entrypoint)にて下記スクリプトを実行します。 # 1. ハイブリッドアクティベーションの作成 SSM_ACTIVATE_INFO = ` aws ssm create-activation --iam-role service-role/AmazonEC2RunCommandRoleForManagedInstances --registration-limit 1 --region ap-northeast-1 --default-instance-name medley-blog-fargate-container` # 2. アウトプットからアクティベーションコード/ID の抽出 SSM_ACTIVATE_CODE = ` echo $SSM_ACTIVATE_INFO | jq -r '.ActivationCode'` SSM_ACTIVATE_ID = ` echo $SSM_ACTIVATE_INFO | jq -r '.ActivationId'` # 3. コンテナ自身をマネージドインスタンスへの登録 amazon-ssm-agent -register -code $SSM_ACTIVATE_CODE -id $SSM_ACTIVATE_ID -region "ap-northeast-1" # 4. SessionManager エージェントの起動 amazon-ssm-agent & これらのコマンドについては各行ごとに説明します 1.ハイブリッドアクティベーションの作成 マネージドインスタンス登録に必要なアクティベーションコード/ID 取得のため、ハイブリッドアクティベーションの登録を行います。 後々 AWS コンソールにてインスタンスの識別ができるように、 --default-instance-name オプションにて medley-blog-fargate-container という名前を付与しています。 このコマンドのアウトプットにて下記のような JSON が返される為、一旦変数に格納しています。 { "ActivationId" : "<<アクティベーション ID>>", "ActivationCode": "<<アクティベーションコード>>" } また --iam-role オプションでサービスロール AmazonEC2RunCommandRoleForManagedInstances を使っています。 このロールがまだ存在しない場合、AWS コンソールからハイブリッドアクティベーションから IAM ロール →「必要な権限を備えたシステムのデフォルトコマンド実行ロールを作成」により作成してください。 2. アウトプットからアクティベーションコード/ID の抽出 前項のアウトプットからアクティベーションコード/ID を個々の変数に分離しています。 3. コンテナ自身をマネージドインスタンスへの登録 取得したアクティベーションコード/ID を利用し、コンテナ自身をマネージドインスタンスとして登録します。 環境変数 AWS_DEFAULT_REGION のように AWS の Credential にてデフォルトの Region 設定があった場合でも、このコマンドではオプションで Region 指定が必須となるのでご注意ください。 4. SessionManager エージェントの起動 最後に SessionManager エージェントを起動します。 これにより AWS との通信が確立され、SessionManager が利用できるようになります。 この状態でマネージドインスタンス画面にて目的のインスタンスが「オンライン」であれば設定が完了です。 接続確認 設定が完了したので、実際に SessionManager にて接続してみます。 AWS コンソールのセッションマネージャからセッションの開始を選択し、名前が事前に登録した medley-blog-fargate-container であるものを選択します。 外見は他の EC2 と変わらない表示ですが、この手段で登録したものはインスタンス ID が mi から始まる ID になります(通常の EC2 は i から始まる ID)。 後は普段通りにセッションを開始するとコンテナ内へのアクセスが開始されます。 これで EC2 の無い Fargate 上のコンテナに対してもターミナルに入ることができました。 運用してみての感想 Fargate 上のコンテナに直接入ることにより、今まで出来なかった top コマンドによるプロセス状態の確認 df コマンドによる Disk 容量の確認 などの環境調査が出来るようになりました。 利用頻度が多い訳ではありませんが、調査の選択肢を増やす事により有事の際の早期対応に繋げれられていると感じています。 注意点 ここからは運用に当たっての注意点について数点紹介します。 料金 EC2 での SessionManager と違い、 この方法で登録したサーバへの SessionManager 通信は料金が発生します 。 正確には 「SessionManager エージェントが起動し AWS と通信が確立している状態」 での時間課金で SessionManager での接続有無は問いません。 よって、常時必要ではない場合は SessionManager エージェントを止めて節約する方法を検討してください。 アクティベーションやマネージドインスタンスがリストに残る コンテナ終了時でも AWS コンソールのハイブリッドアクティベーション一覧やマネージドインスタンス一覧に表示が残ってしまうようです。 一覧の上限の記載は見つからなかったものの、無限に増えるとも思えないので適時 Lambda を使って削除しています。 SessionManager での操作について EC2 インスタンスに対しての SessionManager と同様ですが、セッション開始直後のユーザは ssm-user 固定になるようです。 特定ユーザでの操作が必要となる場合、 su コマンドでのユーザ切り替えが必要になります。 さいごに 今回のようにメドレーでは新たな技術を取り入れつつ、サービスの安定を目的とした様々な施策を導入しています。 こういった働き方に興味を持たれた方、まずは下記リンクからお気軽にお話しませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

自己紹介 株式会社メドレーのエンジニア阪本です。 9 月に入っても暑い日が続く中、皆さんはいかがお過ごしでしょうか。 前回のブログでも書きましたが私は野球観戦（虎党）が趣味で、毎日の試合結果に一喜一憂しています。 このブログの執筆時点ではセ・リーグは首位巨人にマジックが点灯し、残試合 50 を切った状況でのゲーム差 10。優勝を目指す阪神にとっては厳しい状況となりましたが、残り直接対決をすべて勝てば可能性は見えてくるはず。ここは諦めずに応援しようと思います。 次の記事を書く頃には何らかの決着が着いていると思いますので、その時には喜びのメッセージが書ける事を願っています。 はじめに 突然ですが、皆さんは Fargate を使いこなしていますか？ 今まで ECS(EC2)での運用がメインでしたが、ジョブメドレーのシステムでも Fargate に触れる機会が増えてきました。 筆者自身は初めての Fargate でしたが、EC2 の存在が無くなることに不思議な感覚を覚えつつも、管理するものが減って運用が楽になったと実感しています。 しかし、EC2 が無くなった事によりサーバ内にターミナルで入る手段を失いました。 公式の ガイド では 質問２：コンテナの中に ssh や docker exec で入ることは出来ますか？ こちら現状サポートしておりませんが、コンテナワークロードでは「 同一の環境でしっかりテストを行う 」ことや「 ログを外部に全て出す 」ことがベストプラクティスとされていて、コンテナに入る必要性を出来る限り減らす方が将来的にも好ましいです。 と「事前にテストを十分に実施する」「ログは(S3 や CloudWatchLogs など)外部に出力する」 さえ出来ていれば入る必要が無いはずと記載されているものの・・・心配性な自分は不測の事態が発生した時の事を考えてサーバに入る手段を求めてしまいます。 そこで代替手段を模索していた所、 SessionManager を使えば可能との文献を見つけました。 すでに SessionManager 自体は EC2 に対して運用を行っていたため導入の敷居は低いと考え、この手段を採用することにしました。 Session Manager とは？ Session Manager とは AWS の Systems Manager サービスの 1 機能で、AWS 上で管理しているサーバ（マネージドインスタンス）に対してターミナルのアクセスを可能にするものです。 ターミナルへのアクセス手段は、よくある手段だと SSH がありますが この方法は SSH ポートを外部に開放する必要があるため攻撃の対象になりやすく、あまり好ましくありません。 それに比べて Session Manager は SSH ポートの開放は不要でサーバから見てアウトバウンド方向の HTTPS 通信の確保で済む為、外部からの攻撃も受けず安全にアクセス経路の確保が実現できます。 ※通信経路の確保以外にも IAM ロールの設定などが必要となります。詳しくは こちら を参考 「AWS 上で管理しているサーバ」と先に記載しましたが、このサーバは EC2 インスタンスに限らないのが本記事の重要なポイントになります。 オンプレミスなサーバも AWS 上で管理されているのであれば、SessionManager エージェントをインストールする事により管理対象に含めることが可能になるのです。 今回は EC2 で動いていた SessionManager エージェントを Fargate で動くコンテナにインストールする事によりコンテナ自体をサーバと見立ててマネージドインスタンスとし、SessionManager でアクセスする事を目指します。 対応 Systems Manager インスタンス枠をスタンダードからアドバンスドに変更する ／ AWS コンソールでの設定 オンプレミスなサーバに SessionManager にてアクセスする場合、Systems Manager のオンプレミスインスタンスティアを スタンダードからアドバンスドへと変更する必要 があります。 この変更作業は AWS コンソールから行う事になりますが、アドバンスドへの変更に当たって既存のマネージドインスタンスに影響することはありません。 ただし、この逆の場合、スタンダードに戻す際には考慮が必要となるので こちら を参照ください。 SSM Agent のインストール ／ コンテナに対する設定 ここからは実際に動くコンテナに対する設定になります。 AWS のドキュメント 手動でインストール SSM エージェント EC2 で Linux のインスタンス を参考に、OS に合った方法で SessionManager エージェントのインストールを行います。 インストール作業には通信などの時間が必要となるので、事前にコンテナイメージにインストールする形としました。 コンテナをマネージドインスタンスとして登録する ／ コンテナに対する設定 コンテナをマネージドインスタンスとして登録するため、コンテナのスタートアップ(Entrypoint)にて下記スクリプトを実行します。 # 1. ハイブリッドアクティベーションの作成 SSM_ACTIVATE_INFO = ` aws ssm create-activation --iam-role service-role/AmazonEC2RunCommandRoleForManagedInstances --registration-limit 1 --region ap-northeast-1 --default-instance-name medley-blog-fargate-container` # 2. アウトプットからアクティベーションコード/ID の抽出 SSM_ACTIVATE_CODE = ` echo $SSM_ACTIVATE_INFO | jq -r '.ActivationCode'` SSM_ACTIVATE_ID = ` echo $SSM_ACTIVATE_INFO | jq -r '.ActivationId'` # 3. コンテナ自身をマネージドインスタンスへの登録 amazon-ssm-agent -register -code $SSM_ACTIVATE_CODE -id $SSM_ACTIVATE_ID -region "ap-northeast-1" # 4. SessionManager エージェントの起動 amazon-ssm-agent & これらのコマンドについては各行ごとに説明します 1.ハイブリッドアクティベーションの作成 マネージドインスタンス登録に必要なアクティベーションコード/ID 取得のため、ハイブリッドアクティベーションの登録を行います。 後々 AWS コンソールにてインスタンスの識別ができるように、 --default-instance-name オプションにて medley-blog-fargate-container という名前を付与しています。 このコマンドのアウトプットにて下記のような JSON が返される為、一旦変数に格納しています。 { "ActivationId" : "<<アクティベーション ID>>", "ActivationCode": "<<アクティベーションコード>>" } また --iam-role オプションでサービスロール AmazonEC2RunCommandRoleForManagedInstances を使っています。 このロールがまだ存在しない場合、AWS コンソールからハイブリッドアクティベーションから IAM ロール →「必要な権限を備えたシステムのデフォルトコマンド実行ロールを作成」により作成してください。 2. アウトプットからアクティベーションコード/ID の抽出 前項のアウトプットからアクティベーションコード/ID を個々の変数に分離しています。 3. コンテナ自身をマネージドインスタンスへの登録 取得したアクティベーションコード/ID を利用し、コンテナ自身をマネージドインスタンスとして登録します。 環境変数 AWS_DEFAULT_REGION のように AWS の Credential にてデフォルトの Region 設定があった場合でも、このコマンドではオプションで Region 指定が必須となるのでご注意ください。 4. SessionManager エージェントの起動 最後に SessionManager エージェントを起動します。 これにより AWS との通信が確立され、SessionManager が利用できるようになります。 この状態でマネージドインスタンス画面にて目的のインスタンスが「オンライン」であれば設定が完了です。 接続確認 設定が完了したので、実際に SessionManager にて接続してみます。 AWS コンソールのセッションマネージャからセッションの開始を選択し、名前が事前に登録した medley-blog-fargate-container であるものを選択します。 外見は他の EC2 と変わらない表示ですが、この手段で登録したものはインスタンス ID が mi から始まる ID になります(通常の EC2 は i から始まる ID)。 後は普段通りにセッションを開始するとコンテナ内へのアクセスが開始されます。 これで EC2 の無い Fargate 上のコンテナに対してもターミナルに入ることができました。 運用してみての感想 Fargate 上のコンテナに直接入ることにより、今まで出来なかった top コマンドによるプロセス状態の確認 df コマンドによる Disk 容量の確認 などの環境調査が出来るようになりました。 利用頻度が多い訳ではありませんが、調査の選択肢を増やす事により有事の際の早期対応に繋げれられていると感じています。 注意点 ここからは運用に当たっての注意点について数点紹介します。 料金 EC2 での SessionManager と違い、 この方法で登録したサーバへの SessionManager 通信は料金が発生します 。 正確には 「SessionManager エージェントが起動し AWS と通信が確立している状態」 での時間課金で SessionManager での接続有無は問いません。 よって、常時必要ではない場合は SessionManager エージェントを止めて節約する方法を検討してください。 アクティベーションやマネージドインスタンスがリストに残る コンテナ終了時でも AWS コンソールのハイブリッドアクティベーション一覧やマネージドインスタンス一覧に表示が残ってしまうようです。 一覧の上限の記載は見つからなかったものの、無限に増えるとも思えないので適時 Lambda を使って削除しています。 SessionManager での操作について EC2 インスタンスに対しての SessionManager と同様ですが、セッション開始直後のユーザは ssm-user 固定になるようです。 特定ユーザでの操作が必要となる場合、 su コマンドでのユーザ切り替えが必要になります。 さいごに 今回のようにメドレーでは新たな技術を取り入れつつ、サービスの安定を目的とした様々な施策を導入しています。 こういった働き方に興味を持たれた方、まずは下記リンクからお気軽にお話しませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

自己紹介 株式会社メドレーのエンジニア阪本です。 9 月に入っても暑い日が続く中、皆さんはいかがお過ごしでしょうか。 前回のブログでも書きましたが私は野球観戦（虎党）が趣味で、毎日の試合結果に一喜一憂しています。 このブログの執筆時点ではセ・リーグは首位巨人にマジックが点灯し、残試合 50 を切った状況でのゲーム差 10。優勝を目指す阪神にとっては厳しい状況となりましたが、残り直接対決をすべて勝てば可能性は見えてくるはず。ここは諦めずに応援しようと思います。 次の記事を書く頃には何らかの決着が着いていると思いますので、その時には喜びのメッセージが書ける事を願っています。 はじめに 突然ですが、皆さんは Fargate を使いこなしていますか？ 今まで ECS(EC2)での運用がメインでしたが、ジョブメドレーのシステムでも Fargate に触れる機会が増えてきました。 筆者自身は初めての Fargate でしたが、EC2 の存在が無くなることに不思議な感覚を覚えつつも、管理するものが減って運用が楽になったと実感しています。 しかし、EC2 が無くなった事によりサーバ内にターミナルで入る手段を失いました。 公式の ガイド では 質問２：コンテナの中に ssh や docker exec で入ることは出来ますか？ こちら現状サポートしておりませんが、コンテナワークロードでは「 同一の環境でしっかりテストを行う 」ことや「 ログを外部に全て出す 」ことがベストプラクティスとされていて、コンテナに入る必要性を出来る限り減らす方が将来的にも好ましいです。 と「事前にテストを十分に実施する」「ログは(S3 や CloudWatchLogs など)外部に出力する」 さえ出来ていれば入る必要が無いはずと記載されているものの・・・心配性な自分は不測の事態が発生した時の事を考えてサーバに入る手段を求めてしまいます。 そこで代替手段を模索していた所、 SessionManager を使えば可能との文献を見つけました。 すでに SessionManager 自体は EC2 に対して運用を行っていたため導入の敷居は低いと考え、この手段を採用することにしました。 Session Manager とは？ Session Manager とは AWS の Systems Manager サービスの 1 機能で、AWS 上で管理しているサーバ（マネージドインスタンス）に対してターミナルのアクセスを可能にするものです。 ターミナルへのアクセス手段は、よくある手段だと SSH がありますが この方法は SSH ポートを外部に開放する必要があるため攻撃の対象になりやすく、あまり好ましくありません。 それに比べて Session Manager は SSH ポートの開放は不要でサーバから見てアウトバウンド方向の HTTPS 通信の確保で済む為、外部からの攻撃も受けず安全にアクセス経路の確保が実現できます。 ※通信経路の確保以外にも IAM ロールの設定などが必要となります。詳しくは こちら を参考 「AWS 上で管理しているサーバ」と先に記載しましたが、このサーバは EC2 インスタンスに限らないのが本記事の重要なポイントになります。 オンプレミスなサーバも AWS 上で管理されているのであれば、SessionManager エージェントをインストールする事により管理対象に含めることが可能になるのです。 今回は EC2 で動いていた SessionManager エージェントを Fargate で動くコンテナにインストールする事によりコンテナ自体をサーバと見立ててマネージドインスタンスとし、SessionManager でアクセスする事を目指します。 対応 Systems Manager インスタンス枠をスタンダードからアドバンスドに変更する ／ AWS コンソールでの設定 オンプレミスなサーバに SessionManager にてアクセスする場合、Systems Manager のオンプレミスインスタンスティアを スタンダードからアドバンスドへと変更する必要 があります。 この変更作業は AWS コンソールから行う事になりますが、アドバンスドへの変更に当たって既存のマネージドインスタンスに影響することはありません。 ただし、この逆の場合、スタンダードに戻す際には考慮が必要となるので こちら を参照ください。 SSM Agent のインストール ／ コンテナに対する設定 ここからは実際に動くコンテナに対する設定になります。 AWS のドキュメント 手動でインストール SSM エージェント EC2 で Linux のインスタンス を参考に、OS に合った方法で SessionManager エージェントのインストールを行います。 インストール作業には通信などの時間が必要となるので、事前にコンテナイメージにインストールする形としました。 コンテナをマネージドインスタンスとして登録する ／ コンテナに対する設定 コンテナをマネージドインスタンスとして登録するため、コンテナのスタートアップ(Entrypoint)にて下記スクリプトを実行します。 # 1. ハイブリッドアクティベーションの作成 SSM_ACTIVATE_INFO = ` aws ssm create-activation --iam-role service-role/AmazonEC2RunCommandRoleForManagedInstances --registration-limit 1 --region ap-northeast-1 --default-instance-name medley-blog-fargate-container` # 2. アウトプットからアクティベーションコード/ID の抽出 SSM_ACTIVATE_CODE = ` echo $SSM_ACTIVATE_INFO | jq -r '.ActivationCode'` SSM_ACTIVATE_ID = ` echo $SSM_ACTIVATE_INFO | jq -r '.ActivationId'` # 3. コンテナ自身をマネージドインスタンスへの登録 amazon-ssm-agent -register -code $SSM_ACTIVATE_CODE -id $SSM_ACTIVATE_ID -region "ap-northeast-1" # 4. SessionManager エージェントの起動 amazon-ssm-agent & これらのコマンドについては各行ごとに説明します 1.ハイブリッドアクティベーションの作成 マネージドインスタンス登録に必要なアクティベーションコード/ID 取得のため、ハイブリッドアクティベーションの登録を行います。 後々 AWS コンソールにてインスタンスの識別ができるように、 --default-instance-name オプションにて medley-blog-fargate-container という名前を付与しています。 このコマンドのアウトプットにて下記のような JSON が返される為、一旦変数に格納しています。 { "ActivationId" : "<<アクティベーション ID>>", "ActivationCode": "<<アクティベーションコード>>" } また --iam-role オプションでサービスロール AmazonEC2RunCommandRoleForManagedInstances を使っています。 このロールがまだ存在しない場合、AWS コンソールからハイブリッドアクティベーションから IAM ロール →「必要な権限を備えたシステムのデフォルトコマンド実行ロールを作成」により作成してください。 2. アウトプットからアクティベーションコード/ID の抽出 前項のアウトプットからアクティベーションコード/ID を個々の変数に分離しています。 3. コンテナ自身をマネージドインスタンスへの登録 取得したアクティベーションコード/ID を利用し、コンテナ自身をマネージドインスタンスとして登録します。 環境変数 AWS_DEFAULT_REGION のように AWS の Credential にてデフォルトの Region 設定があった場合でも、このコマンドではオプションで Region 指定が必須となるのでご注意ください。 4. SessionManager エージェントの起動 最後に SessionManager エージェントを起動します。 これにより AWS との通信が確立され、SessionManager が利用できるようになります。 この状態でマネージドインスタンス画面にて目的のインスタンスが「オンライン」であれば設定が完了です。 接続確認 設定が完了したので、実際に SessionManager にて接続してみます。 AWS コンソールのセッションマネージャからセッションの開始を選択し、名前が事前に登録した medley-blog-fargate-container であるものを選択します。 外見は他の EC2 と変わらない表示ですが、この手段で登録したものはインスタンス ID が mi から始まる ID になります(通常の EC2 は i から始まる ID)。 後は普段通りにセッションを開始するとコンテナ内へのアクセスが開始されます。 これで EC2 の無い Fargate 上のコンテナに対してもターミナルに入ることができました。 運用してみての感想 Fargate 上のコンテナに直接入ることにより、今まで出来なかった top コマンドによるプロセス状態の確認 df コマンドによる Disk 容量の確認 などの環境調査が出来るようになりました。 利用頻度が多い訳ではありませんが、調査の選択肢を増やす事により有事の際の早期対応に繋げれられていると感じています。 注意点 ここからは運用に当たっての注意点について数点紹介します。 料金 EC2 での SessionManager と違い、 この方法で登録したサーバへの SessionManager 通信は料金が発生します 。 正確には 「SessionManager エージェントが起動し AWS と通信が確立している状態」 での時間課金で SessionManager での接続有無は問いません。 よって、常時必要ではない場合は SessionManager エージェントを止めて節約する方法を検討してください。 アクティベーションやマネージドインスタンスがリストに残る コンテナ終了時でも AWS コンソールのハイブリッドアクティベーション一覧やマネージドインスタンス一覧に表示が残ってしまうようです。 一覧の上限の記載は見つからなかったものの、無限に増えるとも思えないので適時 Lambda を使って削除しています。 SessionManager での操作について EC2 インスタンスに対しての SessionManager と同様ですが、セッション開始直後のユーザは ssm-user 固定になるようです。 特定ユーザでの操作が必要となる場合、 su コマンドでのユーザ切り替えが必要になります。 さいごに 今回のようにメドレーでは新たな技術を取り入れつつ、サービスの安定を目的とした様々な施策を導入しています。 こういった働き方に興味を持たれた方、まずは下記リンクからお気軽にお話しませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

自己紹介 株式会社メドレーのエンジニア阪本です。 9 月に入っても暑い日が続く中、皆さんはいかがお過ごしでしょうか。 前回のブログでも書きましたが私は野球観戦（虎党）が趣味で、毎日の試合結果に一喜一憂しています。 このブログの執筆時点ではセ・リーグは首位巨人にマジックが点灯し、残試合 50 を切った状況でのゲーム差 10。優勝を目指す阪神にとっては厳しい状況となりましたが、残り直接対決をすべて勝てば可能性は見えてくるはず。ここは諦めずに応援しようと思います。 次の記事を書く頃には何らかの決着が着いていると思いますので、その時には喜びのメッセージが書ける事を願っています。 はじめに 突然ですが、皆さんは Fargate を使いこなしていますか？ 今まで ECS(EC2)での運用がメインでしたが、ジョブメドレーのシステムでも Fargate に触れる機会が増えてきました。 筆者自身は初めての Fargate でしたが、EC2 の存在が無くなることに不思議な感覚を覚えつつも、管理するものが減って運用が楽になったと実感しています。 しかし、EC2 が無くなった事によりサーバ内にターミナルで入る手段を失いました。 公式の ガイド では 質問２：コンテナの中に ssh や docker exec で入ることは出来ますか？ こちら現状サポートしておりませんが、コンテナワークロードでは「 同一の環境でしっかりテストを行う 」ことや「 ログを外部に全て出す 」ことがベストプラクティスとされていて、コンテナに入る必要性を出来る限り減らす方が将来的にも好ましいです。 と「事前にテストを十分に実施する」「ログは(S3 や CloudWatchLogs など)外部に出力する」 さえ出来ていれば入る必要が無いはずと記載されているものの・・・心配性な自分は不測の事態が発生した時の事を考えてサーバに入る手段を求めてしまいます。 そこで代替手段を模索していた所、 SessionManager を使えば可能との文献を見つけました。 すでに SessionManager 自体は EC2 に対して運用を行っていたため導入の敷居は低いと考え、この手段を採用することにしました。 Session Manager とは？ Session Manager とは AWS の Systems Manager サービスの 1 機能で、AWS 上で管理しているサーバ（マネージドインスタンス）に対してターミナルのアクセスを可能にするものです。 ターミナルへのアクセス手段は、よくある手段だと SSH がありますが この方法は SSH ポートを外部に開放する必要があるため攻撃の対象になりやすく、あまり好ましくありません。 それに比べて Session Manager は SSH ポートの開放は不要でサーバから見てアウトバウンド方向の HTTPS 通信の確保で済む為、外部からの攻撃も受けず安全にアクセス経路の確保が実現できます。 ※通信経路の確保以外にも IAM ロールの設定などが必要となります。詳しくは こちら を参考 「AWS 上で管理しているサーバ」と先に記載しましたが、このサーバは EC2 インスタンスに限らないのが本記事の重要なポイントになります。 オンプレミスなサーバも AWS 上で管理されているのであれば、SessionManager エージェントをインストールする事により管理対象に含めることが可能になるのです。 今回は EC2 で動いていた SessionManager エージェントを Fargate で動くコンテナにインストールする事によりコンテナ自体をサーバと見立ててマネージドインスタンスとし、SessionManager でアクセスする事を目指します。 対応 Systems Manager インスタンス枠をスタンダードからアドバンスドに変更する ／ AWS コンソールでの設定 オンプレミスなサーバに SessionManager にてアクセスする場合、Systems Manager のオンプレミスインスタンスティアを スタンダードからアドバンスドへと変更する必要 があります。 この変更作業は AWS コンソールから行う事になりますが、アドバンスドへの変更に当たって既存のマネージドインスタンスに影響することはありません。 ただし、この逆の場合、スタンダードに戻す際には考慮が必要となるので こちら を参照ください。 SSM Agent のインストール ／ コンテナに対する設定 ここからは実際に動くコンテナに対する設定になります。 AWS のドキュメント 手動でインストール SSM エージェント EC2 で Linux のインスタンス を参考に、OS に合った方法で SessionManager エージェントのインストールを行います。 インストール作業には通信などの時間が必要となるので、事前にコンテナイメージにインストールする形としました。 コンテナをマネージドインスタンスとして登録する ／ コンテナに対する設定 コンテナをマネージドインスタンスとして登録するため、コンテナのスタートアップ(Entrypoint)にて下記スクリプトを実行します。 # 1. ハイブリッドアクティベーションの作成 SSM_ACTIVATE_INFO = ` aws ssm create-activation --iam-role service-role/AmazonEC2RunCommandRoleForManagedInstances --registration-limit 1 --region ap-northeast-1 --default-instance-name medley-blog-fargate-container` # 2. アウトプットからアクティベーションコード/ID の抽出 SSM_ACTIVATE_CODE = ` echo $SSM_ACTIVATE_INFO | jq -r '.ActivationCode'` SSM_ACTIVATE_ID = ` echo $SSM_ACTIVATE_INFO | jq -r '.ActivationId'` # 3. コンテナ自身をマネージドインスタンスへの登録 amazon-ssm-agent -register -code $SSM_ACTIVATE_CODE -id $SSM_ACTIVATE_ID -region "ap-northeast-1" # 4. SessionManager エージェントの起動 amazon-ssm-agent & これらのコマンドについては各行ごとに説明します 1.ハイブリッドアクティベーションの作成 マネージドインスタンス登録に必要なアクティベーションコード/ID 取得のため、ハイブリッドアクティベーションの登録を行います。 後々 AWS コンソールにてインスタンスの識別ができるように、 --default-instance-name オプションにて medley-blog-fargate-container という名前を付与しています。 このコマンドのアウトプットにて下記のような JSON が返される為、一旦変数に格納しています。 { "ActivationId" : "<<アクティベーション ID>>", "ActivationCode": "<<アクティベーションコード>>" } また --iam-role オプションでサービスロール AmazonEC2RunCommandRoleForManagedInstances を使っています。 このロールがまだ存在しない場合、AWS コンソールからハイブリッドアクティベーションから IAM ロール →「必要な権限を備えたシステムのデフォルトコマンド実行ロールを作成」により作成してください。 2. アウトプットからアクティベーションコード/ID の抽出 前項のアウトプットからアクティベーションコード/ID を個々の変数に分離しています。 3. コンテナ自身をマネージドインスタンスへの登録 取得したアクティベーションコード/ID を利用し、コンテナ自身をマネージドインスタンスとして登録します。 環境変数 AWS_DEFAULT_REGION のように AWS の Credential にてデフォルトの Region 設定があった場合でも、このコマンドではオプションで Region 指定が必須となるのでご注意ください。 4. SessionManager エージェントの起動 最後に SessionManager エージェントを起動します。 これにより AWS との通信が確立され、SessionManager が利用できるようになります。 この状態でマネージドインスタンス画面にて目的のインスタンスが「オンライン」であれば設定が完了です。 接続確認 設定が完了したので、実際に SessionManager にて接続してみます。 AWS コンソールのセッションマネージャからセッションの開始を選択し、名前が事前に登録した medley-blog-fargate-container であるものを選択します。 外見は他の EC2 と変わらない表示ですが、この手段で登録したものはインスタンス ID が mi から始まる ID になります(通常の EC2 は i から始まる ID)。 後は普段通りにセッションを開始するとコンテナ内へのアクセスが開始されます。 これで EC2 の無い Fargate 上のコンテナに対してもターミナルに入ることができました。 運用してみての感想 Fargate 上のコンテナに直接入ることにより、今まで出来なかった top コマンドによるプロセス状態の確認 df コマンドによる Disk 容量の確認 などの環境調査が出来るようになりました。 利用頻度が多い訳ではありませんが、調査の選択肢を増やす事により有事の際の早期対応に繋げれられていると感じています。 注意点 ここからは運用に当たっての注意点について数点紹介します。 料金 EC2 での SessionManager と違い、 この方法で登録したサーバへの SessionManager 通信は料金が発生します 。 正確には 「SessionManager エージェントが起動し AWS と通信が確立している状態」 での時間課金で SessionManager での接続有無は問いません。 よって、常時必要ではない場合は SessionManager エージェントを止めて節約する方法を検討してください。 アクティベーションやマネージドインスタンスがリストに残る コンテナ終了時でも AWS コンソールのハイブリッドアクティベーション一覧やマネージドインスタンス一覧に表示が残ってしまうようです。 一覧の上限の記載は見つからなかったものの、無限に増えるとも思えないので適時 Lambda を使って削除しています。 SessionManager での操作について EC2 インスタンスに対しての SessionManager と同様ですが、セッション開始直後のユーザは ssm-user 固定になるようです。 特定ユーザでの操作が必要となる場合、 su コマンドでのユーザ切り替えが必要になります。 さいごに 今回のようにメドレーでは新たな技術を取り入れつつ、サービスの安定を目的とした様々な施策を導入しています。 こういった働き方に興味を持たれた方、まずは下記リンクからお気軽にお話しませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

自己紹介 株式会社メドレーのエンジニア阪本です。 9 月に入っても暑い日が続く中、皆さんはいかがお過ごしでしょうか。 前回のブログでも書きましたが私は野球観戦（虎党）が趣味で、毎日の試合結果に一喜一憂しています。 このブログの執筆時点ではセ・リーグは首位巨人にマジックが点灯し、残試合 50 を切った状況でのゲーム差 10。優勝を目指す阪神にとっては厳しい状況となりましたが、残り直接対決をすべて勝てば可能性は見えてくるはず。ここは諦めずに応援しようと思います。 次の記事を書く頃には何らかの決着が着いていると思いますので、その時には喜びのメッセージが書ける事を願っています。 はじめに 突然ですが、皆さんは Fargate を使いこなしていますか？ 今まで ECS(EC2)での運用がメインでしたが、ジョブメドレーのシステムでも Fargate に触れる機会が増えてきました。 筆者自身は初めての Fargate でしたが、EC2 の存在が無くなることに不思議な感覚を覚えつつも、管理するものが減って運用が楽になったと実感しています。 しかし、EC2 が無くなった事によりサーバ内にターミナルで入る手段を失いました。 公式の ガイド では 質問２：コンテナの中に ssh や docker exec で入ることは出来ますか？ こちら現状サポートしておりませんが、コンテナワークロードでは「 同一の環境でしっかりテストを行う 」ことや「 ログを外部に全て出す 」ことがベストプラクティスとされていて、コンテナに入る必要性を出来る限り減らす方が将来的にも好ましいです。 と「事前にテストを十分に実施する」「ログは(S3 や CloudWatchLogs など)外部に出力する」 さえ出来ていれば入る必要が無いはずと記載されているものの・・・心配性な自分は不測の事態が発生した時の事を考えてサーバに入る手段を求めてしまいます。 そこで代替手段を模索していた所、 SessionManager を使えば可能との文献を見つけました。 すでに SessionManager 自体は EC2 に対して運用を行っていたため導入の敷居は低いと考え、この手段を採用することにしました。 Session Manager とは？ Session Manager とは AWS の Systems Manager サービスの 1 機能で、AWS 上で管理しているサーバ（マネージドインスタンス）に対してターミナルのアクセスを可能にするものです。 ターミナルへのアクセス手段は、よくある手段だと SSH がありますが この方法は SSH ポートを外部に開放する必要があるため攻撃の対象になりやすく、あまり好ましくありません。 それに比べて Session Manager は SSH ポートの開放は不要でサーバから見てアウトバウンド方向の HTTPS 通信の確保で済む為、外部からの攻撃も受けず安全にアクセス経路の確保が実現できます。 ※通信経路の確保以外にも IAM ロールの設定などが必要となります。詳しくは こちら を参考 「AWS 上で管理しているサーバ」と先に記載しましたが、このサーバは EC2 インスタンスに限らないのが本記事の重要なポイントになります。 オンプレミスなサーバも AWS 上で管理されているのであれば、SessionManager エージェントをインストールする事により管理対象に含めることが可能になるのです。 今回は EC2 で動いていた SessionManager エージェントを Fargate で動くコンテナにインストールする事によりコンテナ自体をサーバと見立ててマネージドインスタンスとし、SessionManager でアクセスする事を目指します。 対応 Systems Manager インスタンス枠をスタンダードからアドバンスドに変更する ／ AWS コンソールでの設定 オンプレミスなサーバに SessionManager にてアクセスする場合、Systems Manager のオンプレミスインスタンスティアを スタンダードからアドバンスドへと変更する必要 があります。 この変更作業は AWS コンソールから行う事になりますが、アドバンスドへの変更に当たって既存のマネージドインスタンスに影響することはありません。 ただし、この逆の場合、スタンダードに戻す際には考慮が必要となるので こちら を参照ください。 SSM Agent のインストール ／ コンテナに対する設定 ここからは実際に動くコンテナに対する設定になります。 AWS のドキュメント 手動でインストール SSM エージェント EC2 で Linux のインスタンス を参考に、OS に合った方法で SessionManager エージェントのインストールを行います。 インストール作業には通信などの時間が必要となるので、事前にコンテナイメージにインストールする形としました。 コンテナをマネージドインスタンスとして登録する ／ コンテナに対する設定 コンテナをマネージドインスタンスとして登録するため、コンテナのスタートアップ(Entrypoint)にて下記スクリプトを実行します。 # 1. ハイブリッドアクティベーションの作成 SSM_ACTIVATE_INFO = ` aws ssm create-activation --iam-role service-role/AmazonEC2RunCommandRoleForManagedInstances --registration-limit 1 --region ap-northeast-1 --default-instance-name medley-blog-fargate-container` # 2. アウトプットからアクティベーションコード/ID の抽出 SSM_ACTIVATE_CODE = ` echo $SSM_ACTIVATE_INFO | jq -r '.ActivationCode'` SSM_ACTIVATE_ID = ` echo $SSM_ACTIVATE_INFO | jq -r '.ActivationId'` # 3. コンテナ自身をマネージドインスタンスへの登録 amazon-ssm-agent -register -code $SSM_ACTIVATE_CODE -id $SSM_ACTIVATE_ID -region "ap-northeast-1" # 4. SessionManager エージェントの起動 amazon-ssm-agent & これらのコマンドについては各行ごとに説明します 1.ハイブリッドアクティベーションの作成 マネージドインスタンス登録に必要なアクティベーションコード/ID 取得のため、ハイブリッドアクティベーションの登録を行います。 後々 AWS コンソールにてインスタンスの識別ができるように、 --default-instance-name オプションにて medley-blog-fargate-container という名前を付与しています。 このコマンドのアウトプットにて下記のような JSON が返される為、一旦変数に格納しています。 { "ActivationId" : "<<アクティベーション ID>>", "ActivationCode": "<<アクティベーションコード>>" } また --iam-role オプションでサービスロール AmazonEC2RunCommandRoleForManagedInstances を使っています。 このロールがまだ存在しない場合、AWS コンソールからハイブリッドアクティベーションから IAM ロール →「必要な権限を備えたシステムのデフォルトコマンド実行ロールを作成」により作成してください。 2. アウトプットからアクティベーションコード/ID の抽出 前項のアウトプットからアクティベーションコード/ID を個々の変数に分離しています。 3. コンテナ自身をマネージドインスタンスへの登録 取得したアクティベーションコード/ID を利用し、コンテナ自身をマネージドインスタンスとして登録します。 環境変数 AWS_DEFAULT_REGION のように AWS の Credential にてデフォルトの Region 設定があった場合でも、このコマンドではオプションで Region 指定が必須となるのでご注意ください。 4. SessionManager エージェントの起動 最後に SessionManager エージェントを起動します。 これにより AWS との通信が確立され、SessionManager が利用できるようになります。 この状態でマネージドインスタンス画面にて目的のインスタンスが「オンライン」であれば設定が完了です。 接続確認 設定が完了したので、実際に SessionManager にて接続してみます。 AWS コンソールのセッションマネージャからセッションの開始を選択し、名前が事前に登録した medley-blog-fargate-container であるものを選択します。 外見は他の EC2 と変わらない表示ですが、この手段で登録したものはインスタンス ID が mi から始まる ID になります(通常の EC2 は i から始まる ID)。 後は普段通りにセッションを開始するとコンテナ内へのアクセスが開始されます。 これで EC2 の無い Fargate 上のコンテナに対してもターミナルに入ることができました。 運用してみての感想 Fargate 上のコンテナに直接入ることにより、今まで出来なかった top コマンドによるプロセス状態の確認 df コマンドによる Disk 容量の確認 などの環境調査が出来るようになりました。 利用頻度が多い訳ではありませんが、調査の選択肢を増やす事により有事の際の早期対応に繋げれられていると感じています。 注意点 ここからは運用に当たっての注意点について数点紹介します。 料金 EC2 での SessionManager と違い、 この方法で登録したサーバへの SessionManager 通信は料金が発生します 。 正確には 「SessionManager エージェントが起動し AWS と通信が確立している状態」 での時間課金で SessionManager での接続有無は問いません。 よって、常時必要ではない場合は SessionManager エージェントを止めて節約する方法を検討してください。 アクティベーションやマネージドインスタンスがリストに残る コンテナ終了時でも AWS コンソールのハイブリッドアクティベーション一覧やマネージドインスタンス一覧に表示が残ってしまうようです。 一覧の上限の記載は見つからなかったものの、無限に増えるとも思えないので適時 Lambda を使って削除しています。 SessionManager での操作について EC2 インスタンスに対しての SessionManager と同様ですが、セッション開始直後のユーザは ssm-user 固定になるようです。 特定ユーザでの操作が必要となる場合、 su コマンドでのユーザ切り替えが必要になります。 さいごに 今回のようにメドレーでは新たな技術を取り入れつつ、サービスの安定を目的とした様々な施策を導入しています。 こういった働き方に興味を持たれた方、まずは下記リンクからお気軽にお話しませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

自己紹介 株式会社メドレーのエンジニア阪本です。 9 月に入っても暑い日が続く中、皆さんはいかがお過ごしでしょうか。 前回のブログでも書きましたが私は野球観戦（虎党）が趣味で、毎日の試合結果に一喜一憂しています。 このブログの執筆時点ではセ・リーグは首位巨人にマジックが点灯し、残試合 50 を切った状況でのゲーム差 10。優勝を目指す阪神にとっては厳しい状況となりましたが、残り直接対決をすべて勝てば可能性は見えてくるはず。ここは諦めずに応援しようと思います。 次の記事を書く頃には何らかの決着が着いていると思いますので、その時には喜びのメッセージが書ける事を願っています。 はじめに 突然ですが、皆さんは Fargate を使いこなしていますか？ 今まで ECS(EC2)での運用がメインでしたが、ジョブメドレーのシステムでも Fargate に触れる機会が増えてきました。 筆者自身は初めての Fargate でしたが、EC2 の存在が無くなることに不思議な感覚を覚えつつも、管理するものが減って運用が楽になったと実感しています。 しかし、EC2 が無くなった事によりサーバ内にターミナルで入る手段を失いました。 公式の ガイド では 質問２：コンテナの中に ssh や docker exec で入ることは出来ますか？ こちら現状サポートしておりませんが、コンテナワークロードでは「 同一の環境でしっかりテストを行う 」ことや「 ログを外部に全て出す 」ことがベストプラクティスとされていて、コンテナに入る必要性を出来る限り減らす方が将来的にも好ましいです。 と「事前にテストを十分に実施する」「ログは(S3 や CloudWatchLogs など)外部に出力する」 さえ出来ていれば入る必要が無いはずと記載されているものの・・・心配性な自分は不測の事態が発生した時の事を考えてサーバに入る手段を求めてしまいます。 そこで代替手段を模索していた所、 SessionManager を使えば可能との文献を見つけました。 すでに SessionManager 自体は EC2 に対して運用を行っていたため導入の敷居は低いと考え、この手段を採用することにしました。 Session Manager とは？ Session Manager とは AWS の Systems Manager サービスの 1 機能で、AWS 上で管理しているサーバ（マネージドインスタンス）に対してターミナルのアクセスを可能にするものです。 ターミナルへのアクセス手段は、よくある手段だと SSH がありますが この方法は SSH ポートを外部に開放する必要があるため攻撃の対象になりやすく、あまり好ましくありません。 それに比べて Session Manager は SSH ポートの開放は不要でサーバから見てアウトバウンド方向の HTTPS 通信の確保で済む為、外部からの攻撃も受けず安全にアクセス経路の確保が実現できます。 ※通信経路の確保以外にも IAM ロールの設定などが必要となります。詳しくは こちら を参考 「AWS 上で管理しているサーバ」と先に記載しましたが、このサーバは EC2 インスタンスに限らないのが本記事の重要なポイントになります。 オンプレミスなサーバも AWS 上で管理されているのであれば、SessionManager エージェントをインストールする事により管理対象に含めることが可能になるのです。 今回は EC2 で動いていた SessionManager エージェントを Fargate で動くコンテナにインストールする事によりコンテナ自体をサーバと見立ててマネージドインスタンスとし、SessionManager でアクセスする事を目指します。 対応 Systems Manager インスタンス枠をスタンダードからアドバンスドに変更する ／ AWS コンソールでの設定 オンプレミスなサーバに SessionManager にてアクセスする場合、Systems Manager のオンプレミスインスタンスティアを スタンダードからアドバンスドへと変更する必要 があります。 この変更作業は AWS コンソールから行う事になりますが、アドバンスドへの変更に当たって既存のマネージドインスタンスに影響することはありません。 ただし、この逆の場合、スタンダードに戻す際には考慮が必要となるので こちら を参照ください。 SSM Agent のインストール ／ コンテナに対する設定 ここからは実際に動くコンテナに対する設定になります。 AWS のドキュメント 手動でインストール SSM エージェント EC2 で Linux のインスタンス を参考に、OS に合った方法で SessionManager エージェントのインストールを行います。 インストール作業には通信などの時間が必要となるので、事前にコンテナイメージにインストールする形としました。 コンテナをマネージドインスタンスとして登録する ／ コンテナに対する設定 コンテナをマネージドインスタンスとして登録するため、コンテナのスタートアップ(Entrypoint)にて下記スクリプトを実行します。 # 1. ハイブリッドアクティベーションの作成 SSM_ACTIVATE_INFO = ` aws ssm create-activation --iam-role service-role/AmazonEC2RunCommandRoleForManagedInstances --registration-limit 1 --region ap-northeast-1 --default-instance-name medley-blog-fargate-container` # 2. アウトプットからアクティベーションコード/ID の抽出 SSM_ACTIVATE_CODE = ` echo $SSM_ACTIVATE_INFO | jq -r '.ActivationCode'` SSM_ACTIVATE_ID = ` echo $SSM_ACTIVATE_INFO | jq -r '.ActivationId'` # 3. コンテナ自身をマネージドインスタンスへの登録 amazon-ssm-agent -register -code $SSM_ACTIVATE_CODE -id $SSM_ACTIVATE_ID -region "ap-northeast-1" # 4. SessionManager エージェントの起動 amazon-ssm-agent & これらのコマンドについては各行ごとに説明します 1.ハイブリッドアクティベーションの作成 マネージドインスタンス登録に必要なアクティベーションコード/ID 取得のため、ハイブリッドアクティベーションの登録を行います。 後々 AWS コンソールにてインスタンスの識別ができるように、 --default-instance-name オプションにて medley-blog-fargate-container という名前を付与しています。 このコマンドのアウトプットにて下記のような JSON が返される為、一旦変数に格納しています。 { "ActivationId" : "<<アクティベーション ID>>", "ActivationCode": "<<アクティベーションコード>>" } また --iam-role オプションでサービスロール AmazonEC2RunCommandRoleForManagedInstances を使っています。 このロールがまだ存在しない場合、AWS コンソールからハイブリッドアクティベーションから IAM ロール →「必要な権限を備えたシステムのデフォルトコマンド実行ロールを作成」により作成してください。 2. アウトプットからアクティベーションコード/ID の抽出 前項のアウトプットからアクティベーションコード/ID を個々の変数に分離しています。 3. コンテナ自身をマネージドインスタンスへの登録 取得したアクティベーションコード/ID を利用し、コンテナ自身をマネージドインスタンスとして登録します。 環境変数 AWS_DEFAULT_REGION のように AWS の Credential にてデフォルトの Region 設定があった場合でも、このコマンドではオプションで Region 指定が必須となるのでご注意ください。 4. SessionManager エージェントの起動 最後に SessionManager エージェントを起動します。 これにより AWS との通信が確立され、SessionManager が利用できるようになります。 この状態でマネージドインスタンス画面にて目的のインスタンスが「オンライン」であれば設定が完了です。 接続確認 設定が完了したので、実際に SessionManager にて接続してみます。 AWS コンソールのセッションマネージャからセッションの開始を選択し、名前が事前に登録した medley-blog-fargate-container であるものを選択します。 外見は他の EC2 と変わらない表示ですが、この手段で登録したものはインスタンス ID が mi から始まる ID になります(通常の EC2 は i から始まる ID)。 後は普段通りにセッションを開始するとコンテナ内へのアクセスが開始されます。 これで EC2 の無い Fargate 上のコンテナに対してもターミナルに入ることができました。 運用してみての感想 Fargate 上のコンテナに直接入ることにより、今まで出来なかった top コマンドによるプロセス状態の確認 df コマンドによる Disk 容量の確認 などの環境調査が出来るようになりました。 利用頻度が多い訳ではありませんが、調査の選択肢を増やす事により有事の際の早期対応に繋げれられていると感じています。 注意点 ここからは運用に当たっての注意点について数点紹介します。 料金 EC2 での SessionManager と違い、 この方法で登録したサーバへの SessionManager 通信は料金が発生します 。 正確には 「SessionManager エージェントが起動し AWS と通信が確立している状態」 での時間課金で SessionManager での接続有無は問いません。 よって、常時必要ではない場合は SessionManager エージェントを止めて節約する方法を検討してください。 アクティベーションやマネージドインスタンスがリストに残る コンテナ終了時でも AWS コンソールのハイブリッドアクティベーション一覧やマネージドインスタンス一覧に表示が残ってしまうようです。 一覧の上限の記載は見つからなかったものの、無限に増えるとも思えないので適時 Lambda を使って削除しています。 SessionManager での操作について EC2 インスタンスに対しての SessionManager と同様ですが、セッション開始直後のユーザは ssm-user 固定になるようです。 特定ユーザでの操作が必要となる場合、 su コマンドでのユーザ切り替えが必要になります。 さいごに 今回のようにメドレーでは新たな技術を取り入れつつ、サービスの安定を目的とした様々な施策を導入しています。 こういった働き方に興味を持たれた方、まずは下記リンクからお気軽にお話しませんか？ https://www.medley.jp/jobs/

自己紹介 株式会社メドレーのエンジニア阪本です。 9 月に入っても暑い日が続く中、皆さんはいかがお過ごしでしょうか。 前回のブログでも書きましたが私は野球観戦（虎党）が趣味で、毎日の試合結果に一喜一憂しています。 このブログの執筆時点ではセ・リーグは首位巨人にマジックが点灯し、残試合 50 を切った状況でのゲーム差 10。優勝を目指す阪神にとっては厳しい状況となりましたが、残り直接対決をすべて勝てば可能性は見えてくるはず。ここは諦めずに応援しようと思います。 次の記事を書く頃には何らかの決着が着いていると思いますので、その時には喜びのメッセージが書ける事を願っています。 はじめに 突然ですが、皆さんは Fargate を使いこなしていますか？ 今まで ECS(EC2)での運用がメインでしたが、ジョブメドレーのシステムでも Fargate に触れる機会が増えてきました。 筆者自身は初めての Fargate でしたが、EC2 の存在が無くなることに不思議な感覚を覚えつつも、管理するものが減って運用が楽になったと実感しています。 しかし、EC2 が無くなった事によりサーバ内にターミナルで入る手段を失いました。 公式の ガイド では 質問２：コンテナの中に ssh や docker exec で入ることは出来ますか？ こちら現状サポートしておりませんが、コンテナワークロードでは「 同一の環境でしっかりテストを行う 」ことや「 ログを外部に全て出す 」ことがベストプラクティスとされていて、コンテナに入る必要性を出来る限り減らす方が将来的にも好ましいです。 と「事前にテストを十分に実施する」「ログは(S3 や CloudWatchLogs など)外部に出力する」 さえ出来ていれば入る必要が無いはずと記載されているものの・・・心配性な自分は不測の事態が発生した時の事を考えてサーバに入る手段を求めてしまいます。 そこで代替手段を模索していた所、 SessionManager を使えば可能との文献を見つけました。 すでに SessionManager 自体は EC2 に対して運用を行っていたため導入の敷居は低いと考え、この手段を採用することにしました。 Session Manager とは？ Session Manager とは AWS の Systems Manager サービスの 1 機能で、AWS 上で管理しているサーバ（マネージドインスタンス）に対してターミナルのアクセスを可能にするものです。 ターミナルへのアクセス手段は、よくある手段だと SSH がありますが この方法は SSH ポートを外部に開放する必要があるため攻撃の対象になりやすく、あまり好ましくありません。 それに比べて Session Manager は SSH ポートの開放は不要でサーバから見てアウトバウンド方向の HTTPS 通信の確保で済む為、外部からの攻撃も受けず安全にアクセス経路の確保が実現できます。 ※通信経路の確保以外にも IAM ロールの設定などが必要となります。詳しくは こちら を参考 「AWS 上で管理しているサーバ」と先に記載しましたが、このサーバは EC2 インスタンスに限らないのが本記事の重要なポイントになります。 オンプレミスなサーバも AWS 上で管理されているのであれば、SessionManager エージェントをインストールする事により管理対象に含めることが可能になるのです。 今回は EC2 で動いていた SessionManager エージェントを Fargate で動くコンテナにインストールする事によりコンテナ自体をサーバと見立ててマネージドインスタンスとし、SessionManager でアクセスする事を目指します。 対応 Systems Manager インスタンス枠をスタンダードからアドバンスドに変更する ／ AWS コンソールでの設定 オンプレミスなサーバに SessionManager にてアクセスする場合、Systems Manager のオンプレミスインスタンスティアを スタンダードからアドバンスドへと変更する必要 があります。 この変更作業は AWS コンソールから行う事になりますが、アドバンスドへの変更に当たって既存のマネージドインスタンスに影響することはありません。 ただし、この逆の場合、スタンダードに戻す際には考慮が必要となるので こちら を参照ください。 SSM Agent のインストール ／ コンテナに対する設定 ここからは実際に動くコンテナに対する設定になります。 AWS のドキュメント 手動でインストール SSM エージェント EC2 で Linux のインスタンス を参考に、OS に合った方法で SessionManager エージェントのインストールを行います。 インストール作業には通信などの時間が必要となるので、事前にコンテナイメージにインストールする形としました。 コンテナをマネージドインスタンスとして登録する ／ コンテナに対する設定 コンテナをマネージドインスタンスとして登録するため、コンテナのスタートアップ(Entrypoint)にて下記スクリプトを実行します。 # 1. ハイブリッドアクティベーションの作成 SSM_ACTIVATE_INFO = ` aws ssm create-activation --iam-role service-role/AmazonEC2RunCommandRoleForManagedInstances --registration-limit 1 --region ap-northeast-1 --default-instance-name medley-blog-fargate-container` # 2. アウトプットからアクティベーションコード/ID の抽出 SSM_ACTIVATE_CODE = ` echo $SSM_ACTIVATE_INFO | jq -r '.ActivationCode'` SSM_ACTIVATE_ID = ` echo $SSM_ACTIVATE_INFO | jq -r '.ActivationId'` # 3. コンテナ自身をマネージドインスタンスへの登録 amazon-ssm-agent -register -code $SSM_ACTIVATE_CODE -id $SSM_ACTIVATE_ID -region "ap-northeast-1" # 4. SessionManager エージェントの起動 amazon-ssm-agent & これらのコマンドについては各行ごとに説明します 1.ハイブリッドアクティベーションの作成 マネージドインスタンス登録に必要なアクティベーションコード/ID 取得のため、ハイブリッドアクティベーションの登録を行います。 後々 AWS コンソールにてインスタンスの識別ができるように、 --default-instance-name オプションにて medley-blog-fargate-container という名前を付与しています。 このコマンドのアウトプットにて下記のような JSON が返される為、一旦変数に格納しています。 { "ActivationId" : "<<アクティベーション ID>>", "ActivationCode": "<<アクティベーションコード>>" } また --iam-role オプションでサービスロール AmazonEC2RunCommandRoleForManagedInstances を使っています。 このロールがまだ存在しない場合、AWS コンソールからハイブリッドアクティベーションから IAM ロール →「必要な権限を備えたシステムのデフォルトコマンド実行ロールを作成」により作成してください。 2. アウトプットからアクティベーションコード/ID の抽出 前項のアウトプットからアクティベーションコード/ID を個々の変数に分離しています。 3. コンテナ自身をマネージドインスタンスへの登録 取得したアクティベーションコード/ID を利用し、コンテナ自身をマネージドインスタンスとして登録します。 環境変数 AWS_DEFAULT_REGION のように AWS の Credential にてデフォルトの Region 設定があった場合でも、このコマンドではオプションで Region 指定が必須となるのでご注意ください。 4. SessionManager エージェントの起動 最後に SessionManager エージェントを起動します。 これにより AWS との通信が確立され、SessionManager が利用できるようになります。 この状態でマネージドインスタンス画面にて目的のインスタンスが「オンライン」であれば設定が完了です。 接続確認 設定が完了したので、実際に SessionManager にて接続してみます。 AWS コンソールのセッションマネージャからセッションの開始を選択し、名前が事前に登録した medley-blog-fargate-container であるものを選択します。 外見は他の EC2 と変わらない表示ですが、この手段で登録したものはインスタンス ID が mi から始まる ID になります(通常の EC2 は i から始まる ID)。 後は普段通りにセッションを開始するとコンテナ内へのアクセスが開始されます。 これで EC2 の無い Fargate 上のコンテナに対してもターミナルに入ることができました。 運用してみての感想 Fargate 上のコンテナに直接入ることにより、今まで出来なかった top コマンドによるプロセス状態の確認 df コマンドによる Disk 容量の確認 などの環境調査が出来るようになりました。 利用頻度が多い訳ではありませんが、調査の選択肢を増やす事により有事の際の早期対応に繋げれられていると感じています。 注意点 ここからは運用に当たっての注意点について数点紹介します。 料金 EC2 での SessionManager と違い、 この方法で登録したサーバへの SessionManager 通信は料金が発生します 。 正確には 「SessionManager エージェントが起動し AWS と通信が確立している状態」 での時間課金で SessionManager での接続有無は問いません。 よって、常時必要ではない場合は SessionManager エージェントを止めて節約する方法を検討してください。 アクティベーションやマネージドインスタンスがリストに残る コンテナ終了時でも AWS コンソールのハイブリッドアクティベーション一覧やマネージドインスタンス一覧に表示が残ってしまうようです。 一覧の上限の記載は見つからなかったものの、無限に増えるとも思えないので適時 Lambda を使って削除しています。 SessionManager での操作について EC2 インスタンスに対しての SessionManager と同様ですが、セッション開始直後のユーザは ssm-user 固定になるようです。 特定ユーザでの操作が必要となる場合、 su コマンドでのユーザ切り替えが必要になります。 さいごに 今回のようにメドレーでは新たな技術を取り入れつつ、サービスの安定を目的とした様々な施策を導入しています。 こういった働き方に興味を持たれた方、まずは下記リンクからお気軽にお話しませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

みなさん、こんにちは。エンジニア・デザイナー採用担当の平木です。 メドレーでは iOS 開発コミュニティに微力ながら還元したいと、2017 年より iOSDC に協賛をさせていただいておりますが、今年も シルバースポンサー として協賛させていただくことになりました。 過去の参加レポート entry/2018/09/13/175702 entry/2017/09/27/120000 iOSDC 初のオンライン開催 今年の iOSDC は初のオンライン開催ということで、例年とはまた違った楽しみ方ができそうです。 公式スタッフブログに記載されていますが、今年はノベルティグッズが 配送 されるとのことで、既に届いている方もいらっしゃるようです。弊社のパンフレットも同封させていただいてます。 今年の タイムテーブル も大変興味深い内容が多く、今から視聴が楽しみですが(スポンサーチケットを頂いてはいますが、筆者も自腹でチケット購入しています) ニコニコ生放送での視聴 ということで、例年とは違い、コメントなどで盛り上がりがあるのではないかと、大変期待しています。 Ask the Speaker では Discord を使用するということで、対面とはまた違ったコミュニケーションが取れそうです。参考 URL や図などがすぐに出してもらえたりなど、さらに学びが深くなるのではないかと思っています。 最後に 今回は直接会場でみなさんとの交流はできませんが、弊社のエンジニアも参加予定ですので、一緒に楽しんでいきたいと思います。後日イベントレポートもこちらで公開したいと考えています。 また、メドレーではこうしたイベントにも興味をお持ちの iOS エンジニアを絶賛募集中です。お気軽に下記よりご連絡いただければ、カジュアルにお話をしたいです! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

みなさん、こんにちは。エンジニア・デザイナー採用担当の平木です。 メドレーでは iOS 開発コミュニティに微力ながら還元したいと、2017 年より iOSDC に協賛をさせていただいておりますが、今年も シルバースポンサー として協賛させていただくことになりました。 過去の参加レポート entry/2018/09/13/175702 entry/2017/09/27/120000 iOSDC 初のオンライン開催 今年の iOSDC は初のオンライン開催ということで、例年とはまた違った楽しみ方ができそうです。 公式スタッフブログに記載されていますが、今年はノベルティグッズが 配送 されるとのことで、既に届いている方もいらっしゃるようです。弊社のパンフレットも同封させていただいてます。 今年の タイムテーブル も大変興味深い内容が多く、今から視聴が楽しみですが(スポンサーチケットを頂いてはいますが、筆者も自腹でチケット購入しています) ニコニコ生放送での視聴 ということで、例年とは違い、コメントなどで盛り上がりがあるのではないかと、大変期待しています。 Ask the Speaker では Discord を使用するということで、対面とはまた違ったコミュニケーションが取れそうです。参考 URL や図などがすぐに出してもらえたりなど、さらに学びが深くなるのではないかと思っています。 最後に 今回は直接会場でみなさんとの交流はできませんが、弊社のエンジニアも参加予定ですので、一緒に楽しんでいきたいと思います。後日イベントレポートもこちらで公開したいと考えています。 また、メドレーではこうしたイベントにも興味をお持ちの iOS エンジニアを絶賛募集中です。お気軽に下記よりご連絡いただければ、カジュアルにお話をしたいです! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

みなさん、こんにちは。エンジニア・デザイナー採用担当の平木です。 メドレーでは iOS 開発コミュニティに微力ながら還元したいと、2017 年より iOSDC に協賛をさせていただいておりますが、今年も シルバースポンサー として協賛させていただくことになりました。 過去の参加レポート entry/2018/09/13/175702 entry/2017/09/27/120000 iOSDC 初のオンライン開催 今年の iOSDC は初のオンライン開催ということで、例年とはまた違った楽しみ方ができそうです。 公式スタッフブログに記載されていますが、今年はノベルティグッズが 配送 されるとのことで、既に届いている方もいらっしゃるようです。弊社のパンフレットも同封させていただいてます。 今年の タイムテーブル も大変興味深い内容が多く、今から視聴が楽しみですが(スポンサーチケットを頂いてはいますが、筆者も自腹でチケット購入しています) ニコニコ生放送での視聴 ということで、例年とは違い、コメントなどで盛り上がりがあるのではないかと、大変期待しています。 Ask the Speaker では Discord を使用するということで、対面とはまた違ったコミュニケーションが取れそうです。参考 URL や図などがすぐに出してもらえたりなど、さらに学びが深くなるのではないかと思っています。 最後に 今回は直接会場でみなさんとの交流はできませんが、弊社のエンジニアも参加予定ですので、一緒に楽しんでいきたいと思います。後日イベントレポートもこちらで公開したいと考えています。 また、メドレーではこうしたイベントにも興味をお持ちの iOS エンジニアを絶賛募集中です。お気軽に下記よりご連絡いただければ、カジュアルにお話をしたいです! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp