こちらの記事は Medley（メドレー） Advent Calendar 2024 の12日目の記事です。 はじめに はじめまして。医療プラットフォーム事業部　プロダクト開発室　Dentis開発グループでグループマネジャーをしている牧（X: @Kirika_K2 ）と申します。 メドレーには2019年に入社し、以来、歯科医院向けのクラウドサービス Dentis の立ち上げ、プロダクト開発に携わっています。 Dentisは医療機関の予約・受付・問診・カルテの記録・会計業務・保険請求業務までをトータルでサポートするクラウドシステムで、主にRuby on RailsとReactで作られています。 日々歯科医療ドメインでお客様の声に向き合いながら、医療DXを推進しています。 着実に成長しているプロダクトですので、もしご興味ありましたら、カジュアル面談等受け付けておりますので、お声がけください。（宣伝終） 普段はプロダクト開発に従事していますが、プライベートでは地域Rubyコミュニティの表参道.rbを主催しておりまして、メドレーでも地域Rubyコミュニティ支援という形で、表参道.rbのスポンサー企業として、協力してもらっています。 今回のAdvent Calendarでは、一地域Rubyコミュニティオーガナイザーの立場から見たメドレーの地域Rubyコミュニティとの関わりについて書こうと思います。 表参道.rbと私の関わり 表参道.rbは2015年頃から始まった、表参道周辺のエンジニアが集まってRubyの周辺技術に関する情報交換をする地域Rubyコミュニティです。 毎月第１木曜日に開催しており、毎月1人10分程度のトークセッションを6〜７本と交流会を行っています。 一部例外があり、開催日が祝日等と重なる場合は、1週間ずらして第2木曜日に開催しています。 ちょうど今月の第1木曜日は島根県松江市で、RubyWorld Conference 2025が開催されており、表参道.rbに普段来てもらっている多くの方も松江に集合しているので、第2木曜日の開催になります。（つまり今日です！） 毎月第2週は、後ほどお話する六本木.rbが定期開催されており、合同開催という形での開催しています。 どちらも楽しいコミュニティですので、是非遊びに来てください。 表参道.rb https://omotesandorb.connpass.com/ 六本木.rb https://roppongirb.connpass.com/ 私は、2018年頃から運営に関わり始め、その後メドレーに入社し、職場が六本木に変わった後も続けていました。 コロナ禍によるオンライン開催移行、そしてオフライン開催の復活 2020年にコロナ禍になり、オフラインでの開催ができなくなり半年ほど開催を見送っていたこともありましたが、オンライン開催に移行して開催してきました。 ちょうどコロナ禍で混乱していた頃、コミュニティを活動休止にするか、オンライン開催に移行するか悩みましたが、一度中止にしてしまうと再開するきっかけを失ってしまう可能性もあったため、これまで通りの頻度で開催することに決めました。 またオンラインに移行するにあたって、もくもく会など、これまでと異なる形式での開催も考えましたが、いくつかのコミュニティがオンラインに移行している中、トークセッションがあるコミュニティは貴重、という意見をいただき、これまで通りの形式で進めていくことにしました。 オンライン開催の時は人の集まりが良くない時もあり、5名ぐらいで開催することもありましたが、毎回誰かが発表ネタを持ち込んでくれ、また発表が少なかった日は、少人数で余った時間をディスカッションに充てることができたので、これはこれで面白みがありました。 また普段遠方で表参道.rbに参加できないような方にも参加していただいていたので、今も表参道.rbが続いているのは、当時少人数でも途切れないようにコミュニティを支えてくださった方々のお陰です。とてもありがたいことですね。 御存知のとおり、コロナ禍は長く続くことになり、オンラインでの開催は2020年11月から2023年6月まで行われました。 RubyKaigiがオフライン開催に戻り、2023年の松本での開催から東京に戻った後、表参道.rbもオフラインに戻すことを考え始めました。 その際に必要になるのが開催する会場です。当時はまだオフラインで会場を提供していただける場所は多くなく、まず最初に相談したのは自分の勤務先であるメドレーでした。 メドレーでは過去にRubyコミュニティのために会場提供をしたことはありませんでしたが、私が地域Rubyコミュニティの主催を継続していたこともあり、活動を後押ししていただけ、快く会場提供と懇親会の予算をつけてもらえました。 表参道.rb #87 では弊社が会場提供させていただいております! #omotesandorb #ruby https://t.co/PDmvLeqLPN #omotesandorb — メドレー ディベロッパー公式 (@medley_dev) June 16, 2023 ありがたいことに、この回の表参道.rbに参加してくださった方の中から、「自分の会社でも会場提供したい」という申し出を受け、現在の表参道.rbは10社ぐらいの企業から会場スポンサードをしていただき、毎回開催会場を変えながら、継続しています。 そして、今年2024年8月に表参道.rbはめでたく100回目の開催を迎えました。 本当に様々な人に支えられて開催できた100回開催だな、と思います。 表参道rb 100回〜〜！！👏👏👏👏👏 #omotesandorb #roppongirb pic.twitter.com/1qe2aJWMcZ — あっきー🍺ツクリンクEM (@kuronekopunk) August 1, 2024 六本木.rbの復活とメドレーとの関わり ちょうど今年のはじめぐらいの頃に、表参道.rbに参加されていたryoskさん(X: @ryosk7 )から六本木.rbを再始動させたいという話があり、会場を探しているという話がありました。 六本木.rbは六本木周辺の企業で働くエンジニアが集まるRubyコミュニティで、コロナ前までは時々開催されていたようですが、こちらもコロナで休止していたコミュニティでした。 メドレーは六本木の企業ということもあり、表参道.rb同様に六本木.rbも支援してもらいたいということで会社に相談したところ、こちらも会場提供と懇親会予算をつけてもらえることになりました。 この時メドレーはRubyKaigi 2024のRubyスポンサーとして協賛しており、最終日の基調講演前のスポンサーセッション枠をもらったタイミングだったため、どうせなら、盛大に宣伝してもらおうということで、弊社VPoEの山崎にも地域.rb支援の件について紹介してもらいました。 ただいま発表がありましたが、 Roppongi.rb が復活します！！！🎉 六本木周辺の企業さんのお力を借りてオフライン開催をします。 6月13日はメドレーさんのオフィスをお借りします。 これからconnpassの方も展開します！ よろしくお願いします🙌 #rubykaigi https://t.co/zo2t6KGPrj — ryosk7🦎 (@ryosk7) May 17, 2024 RubyKaigi 2024 に Ruby Sponsor として協賛しました！ - MEDLEY Developers Portal それ以来、六本木.rbはメドレーを含む4社で月1回の定期開催しています。 メドレーさんのオフィスに着きました！ 今日はこちらでRoppongi.rbを行います。 #roppongirb pic.twitter.com/UioFP3FEyY — ryosk7🦎 (@ryosk7) June 13, 2024 地域Rubyコミュニティ支援に伴う、ポジティブな効果 このような活動を続けてきて、会社にどのような変化があったかについて触れたいと思います。 まず1つ目は「普段の仕事で会わない社内の人たちと社外のイベントで顔を合わせるようになった」ことです。 2022年RubyKaigiの様子、この年はコロナ休止からのリブートということもあり、ブース出展もなかったので、自分しか参加してなかった 2023年RubyKaigiの様子、会場の様子を見てきて欲しいと言われた若手エンジニアと。実はこの時写真を撮ってもらった人が、その後新卒としてメドレーに入るというミラクルが起きました 2024年RubyKaigiの様子、スポンサーブースにて 社内でRubyのイベントを告知するようになってから、参加してくれる人も増えました。 先日のKaigi on Railsでも、業務とは関係なく来たと言う人達で集まる一幕もあり、変化を感じた部分でもありました。 もう一つは、やはり社外への認知で、今年のRubyKaigi 2024ではRubyスポンサーでブースを出していたのですが、「表参道.rbで会社に行ったことがあります」と教えてくださる人が数名いらっしゃったり、今年入社された方が「表参道.rbに参加したことがあります」と教えてくださったり、少なからずポジティブな側面があるなぁ、と感じることがありました。こういった声が定期的に聞けるのはスポンサードしている側としてはとても嬉しいです。 地域Rubyコミュニティのオーガナイザーから見た、メドレーと地域Rubyコミュニティとの関わり さて、ここまではメドレーと地域Rubyコミュニティとの関わりについてお話してきました。 ここからは私の所感について書きます。ここから先は私がオーガナイザーとして普段コミュニティ活動について考えていることですので、特段会社から何か言われているということではありません。誤解なきようお願いします（笑 会社から見ると「地域.rbのスポンサードをしました！」、地域Rubyコミュニティのオーガナイザーから見ると「地域.rbを開催しました！」という話で終わるのですが、地域Rubyコミュニティのオーガナイザーをしつつ、会社として地域.rbの支援をする、という立場でみると、少し違った見え方になります。 企業がこういったスポンサードを行う際には、一定の費用対効果を考える必要があるからです。 私もスポンサードする側の立場から、そういった事情を抜きにすれば、「知名度向上のために積極的に行うべき」「採用面にも少なからずポジティブに働いている」と主張することはできますし、実際そういった側面はあると思います。しかし、それがどの程度プラスに働いているのかを正しく計測する方法がないため、基本的にはコミュニティはボランティアに近い形で支援してもらうことになります。 そういったものは、長く続くとは限りませんし、普段ご支援いただいている会社の窓口担当の方や、決済責任者が変わるだけで状況は変わります。 これについては、オーガナイザーとしては仕方ないものと考えており、コミュニティを持続可能なものにするために、最大限努力をする必要があると考えています。 以前表参道.rb 100回のときに、「表参道.rb 100回に寄せて」というタイトルで、「コミュニティが継続していくためにはどうすればよいか」というお話をさせていただきました。 その中で、コミュニティが継続するための3要素「主催者のやる気・スポンサード企業・参加者」の3つを挙げ、コミュニティが長く続くためにどうするべきか、というお話をさせていただきました。 「表参道.rb 100回に寄せて」 メドレーも現在は地域Rubyコミュニティを無償で応援している立場ではありますが、これが未来永劫続くかは分かりません。が、可能な限り長期間支援できるように、一地域Rubyコミュニティのオーガナイザーとして、そして会社の中の人として、努力したいと思っています。 まとめ 地域Rubyコミュニティのオーガナイザーから見た、メドレーと地域Rubyコミュニティとの関わりについて書かせていただきました。 メドレーでは、表参道.rbと六本木.rbの地域Rubyコミュニティの支援をしており、定期的にメドレーでも開催しております。 もし、ご興味ありましたら是非遊びに来てください。 表参道.rb https://omotesandorb.connpass.com/ 六本木.rb https://roppongirb.connpass.com/

こんにちは！人材プラットフォーム本部で技術広報兼エンジニア採用をしている重田( @Shige0096 )です。2024 年 11 月にメドレーにジョインし、初の社外イベントに参加してきました。 今回、メドレーは 2024/11/23 に九段坂上 KS ビルにて開催された「 JSConf JP 2024 」にプレミアムスポンサーとして協賛させていただきました。 JSConf JP は一般社団法人 Japan Node.js Association によって企画・運営されている JavaScript に関する“⁠ お祭り ⁠”です。日本と海外の Web 開発者を繋げる目的で企画されています。2020 年から開催され、今年で 5 回目。今年もフロントエンドエンジニア・採用人事・技術広報担当を中心に多くの参加者が訪れました。 会場の様子 会場は九段坂上 KS ビル。今年はオンライン・オフラインのハイブリッド開催でした。現地チケットは売り切れてしまったので、オンライン配信があるのは嬉しいですね。 当日は 4 つのトラックに分かれ、時間帯によっては 4 セッションが同時並行していました。 セッション数が多くとても充実したイベントになりました。 会場入り口 メドレーブースの様子 メドレーブースでは「医療体験あるある」をパネルを用いてアンケート調査しました。 エンジニアをはじめ多くの方にお越しいただきました！お越しいただいた皆様ありがとうございました ✨ 特に多かった「医療体験あるある」は以下 2 つ。 ① キャッシュレス決済がしたい ⇨ キャッシュレス対応が進んできたがまだまだ現金対応の病院が多い ⇨ 現金を引き落としに一度コンビニに行くことがあった ② 待ち時間が長い（ほぼ同率 １ 位） ⇨ 予約したはずなのに待ち時間が発生している ⇨ いつも混んでいるので病院に行くのが疲れる 実際に CLINICS アプリ の画面をご覧いただきながら以下のようなお話をしました。オンライン診療を受けたのち、ご要望に合わせて薬を Uber で配達することも可能であることや、何よりキャッシュレス決済もスムーズにできてとても良い！などのお声をいただきました。 多くの方にお越しいただきました 🙌 自身が開発しているプロダクトに込める思いは人一倍 👀✨ メドレー登壇 当社の髙橋(医療プラットフォーム本部)と德永(人材プラットフォーム)が登壇しました。 高橋のセッションの様子 次々に参加者が増えていき、最終的には 50 名近くの方にご覧いただきました 🙌 オンライン配信を含め、ご視聴いただいた皆様、ありがとうございました！ 登壇した髙橋より一言 セッションや登壇資料をご覧頂いた皆様、ありがとうございました！当日のブースや懇親会、また X やブログを通じて、皆様から多くのご感想を頂き感謝の気持ちでいっぱいです。発表で詳しく取り上げられなかった内容に関する Q&A を以下に公開します。 コンポーネントの分割粒度をチーム全体でどのように統一していますか？ 発表内で紹介した{関心事}{状況}{ベースコンポーネント名}の命名規則を守ることで Button や Dialog の単位で自然とコンポーネントが分割されるようなメンタルモデルを築いています。加えて Plop を使ってテンプレートコードを生成することで実装がブレないようにしています。 状態管理ライブラリはどのように使い分けていますか？ 非同期状態管理は Tanstack Query 、フォーム状態管理は React Hook Form 、その他の UI に関する状態は React.useState のように使い分けています。複合コンポーネント間で親子関係がある場合は React.createContext を使って依存関係を表現することがあります。このとき、子コンポーネントの Storybook の decorator に Context Provider を設定することで、複合コンポーネント間の連携を含めた Story とそのテストを実装しています。 Redux はサーバキャッシュとして運用していましたが、現在は Tanstack Query への移行を進めているため積極的な利用は避けています。 👇 登壇資料はこちら 德永のセッションの様子 登壇した徳永より一言 Remix のファイルベースルーティングについて LT させていただきました。当日に React Router v7 が正式リリースされるなど想定外のことが起こりつつも、皆さんにホットな話題として取り上げていただき有り難かったです。 👇 登壇資料はこちら 終わりに メドレーはこれからも医療ヘルスケア領域において、医療体験にインパクトを与えるプロダクトやサービスの開発に取り組んでいきます。引き続き技術的なチャレンジも行っていきますのでご注目ください！ 最後に、改めて JSConf JP 2024 の運営の皆様、登壇されたスピーカーの皆様、参加者の皆様、ありがとうございました。来年の開催も楽しみにしています！ ミイダス社とメルカリ社の素敵なノベルティをいただきました ✨ メドレーでは一緒に働く仲間を募集しています。 ぜひこの記事やブースや登壇などで興味を持っていただいた方はご連絡をお待ちしております！カジュアル面談も大歓迎ですので、お気軽にお問い合わせください！ 当日会場でお時間いただいた皆様、ありがとうございました！ メドレーは今後も技術イベントへ出展/登壇する予定です。今後も皆さんにお会いすることを楽しみにしています！

こんにちは！人材プラットフォーム本部で技術広報兼エンジニア採用をしている重田( @Shige0096 )です。2024 年 11 月にメドレーにジョインし、初の社外イベントに参加してきました。 今回、メドレーは 2024/11/23 に九段坂上 KS ビルにて開催された「 JSConf JP 2024 」にプレミアムスポンサーとして協賛させていただきました。 JSConf JP は一般社団法人 Japan Node.js Association によって企画・運営されている JavaScript に関する“⁠ お祭り ⁠”です。日本と海外の Web 開発者を繋げる目的で企画されています。2020 年から開催され、今年で 5 回目。今年もフロントエンドエンジニア・採用人事・技術広報担当を中心に多くの参加者が訪れました。 会場の様子 会場は九段坂上 KS ビル。今年はオンライン・オフラインのハイブリッド開催でした。現地チケットは売り切れてしまったので、オンライン配信があるのは嬉しいですね。 当日は 4 つのトラックに分かれ、時間帯によっては 4 セッションが同時並行していました。 セッション数が多くとても充実したイベントになりました。 会場入り口 メドレーブースの様子 メドレーブースでは「医療体験あるある」をパネルを用いてアンケート調査しました。 エンジニアをはじめ多くの方にお越しいただきました！お越しいただいた皆様ありがとうございました ✨ 特に多かった「医療体験あるある」は以下 2 つ。 ① キャッシュレス決済がしたい ⇨ キャッシュレス対応が進んできたがまだまだ現金対応の病院が多い ⇨ 現金を引き落としに一度コンビニに行くことがあった ② 待ち時間が長い（ほぼ同率 １ 位） ⇨ 予約したはずなのに待ち時間が発生している ⇨ いつも混んでいるので病院に行くのが疲れる 実際に CLINICS アプリ の画面をご覧いただきながら以下のようなお話をしました。オンライン診療を受けたのち、ご要望に合わせて薬を Uber で配達することも可能であることや、何よりキャッシュレス決済もスムーズにできてとても良い！などのお声をいただきました。 多くの方にお越しいただきました 🙌 自身が開発しているプロダクトに込める思いは人一倍 👀✨ メドレー登壇 当社の髙橋(医療プラットフォーム本部)と德永(人材プラットフォーム)が登壇しました。 高橋のセッションの様子 次々に参加者が増えていき、最終的には 50 名近くの方にご覧いただきました 🙌 オンライン配信を含め、ご視聴いただいた皆様、ありがとうございました！ 登壇した髙橋より一言 セッションや登壇資料をご覧頂いた皆様、ありがとうございました！当日のブースや懇親会、また X やブログを通じて、皆様から多くのご感想を頂き感謝の気持ちでいっぱいです。発表で詳しく取り上げられなかった内容に関する Q&A を以下に公開します。 コンポーネントの分割粒度をチーム全体でどのように統一していますか？ 発表内で紹介した{関心事}{状況}{ベースコンポーネント名}の命名規則を守ることで Button や Dialog の単位で自然とコンポーネントが分割されるようなメンタルモデルを築いています。加えて Plop を使ってテンプレートコードを生成することで実装がブレないようにしています。 状態管理ライブラリはどのように使い分けていますか？ 非同期状態管理は Tanstack Query 、フォーム状態管理は React Hook Form 、その他の UI に関する状態は React.useState のように使い分けています。複合コンポーネント間で親子関係がある場合は React.createContext を使って依存関係を表現することがあります。このとき、子コンポーネントの Storybook の decorator に Context Provider を設定することで、複合コンポーネント間の連携を含めた Story とそのテストを実装しています。 Redux はサーバキャッシュとして運用していましたが、現在は Tanstack Query への移行を進めているため積極的な利用は避けています。 👇 登壇資料はこちら 德永のセッションの様子 登壇した徳永より一言 Remix のファイルベースルーティングについて LT させていただきました。当日に React Router v7 が正式リリースされるなど想定外のことが起こりつつも、皆さんにホットな話題として取り上げていただき有り難かったです。 👇 登壇資料はこちら 終わりに メドレーはこれからも医療ヘルスケア領域において、医療体験にインパクトを与えるプロダクトやサービスの開発に取り組んでいきます。引き続き技術的なチャレンジも行っていきますのでご注目ください！ 最後に、改めて JSConf JP 2024 の運営の皆様、登壇されたスピーカーの皆様、参加者の皆様、ありがとうございました。来年の開催も楽しみにしています！ ミイダス社とメルカリ社の素敵なノベルティをいただきました ✨ メドレーでは一緒に働く仲間を募集しています。 ぜひこの記事やブースや登壇などで興味を持っていただいた方はご連絡をお待ちしております！カジュアル面談も大歓迎ですので、お気軽にお問い合わせください！ 当日会場でお時間いただいた皆様、ありがとうございました！ メドレーは今後も技術イベントへ出展/登壇する予定です。今後も皆さんにお会いすることを楽しみにしています！

こんにちは！人材プラットフォーム本部で技術広報兼エンジニア採用をしている重田( @Shige0096 )です。2024 年 11 月にメドレーにジョインし、初の社外イベントに参加してきました。 今回、メドレーは 2024/11/23 に九段坂上 KS ビルにて開催された「 JSConf JP 2024 」にプレミアムスポンサーとして協賛させていただきました。 JSConf JP は一般社団法人 Japan Node.js Association によって企画・運営されている JavaScript に関する“⁠ お祭り ⁠”です。日本と海外の Web 開発者を繋げる目的で企画されています。2020 年から開催され、今年で 5 回目。今年もフロントエンドエンジニア・採用人事・技術広報担当を中心に多くの参加者が訪れました。 会場の様子 会場は九段坂上 KS ビル。今年はオンライン・オフラインのハイブリッド開催でした。現地チケットは売り切れてしまったので、オンライン配信があるのは嬉しいですね。 当日は 4 つのトラックに分かれ、時間帯によっては 4 セッションが同時並行していました。 セッション数が多くとても充実したイベントになりました。 会場入り口 メドレーブースの様子 メドレーブースでは「医療体験あるある」をパネルを用いてアンケート調査しました。 エンジニアをはじめ多くの方にお越しいただきました！お越しいただいた皆様ありがとうございました ✨ 特に多かった「医療体験あるある」は以下 2 つ。 ① キャッシュレス決済がしたい ⇨ キャッシュレス対応が進んできたがまだまだ現金対応の病院が多い ⇨ 現金を引き落としに一度コンビニに行くことがあった ② 待ち時間が長い（ほぼ同率 １ 位） ⇨ 予約したはずなのに待ち時間が発生している ⇨ いつも混んでいるので病院に行くのが疲れる 実際に CLINICS アプリ の画面をご覧いただきながら以下のようなお話をしました。オンライン診療を受けたのち、ご要望に合わせて薬を Uber で配達することも可能であることや、何よりキャッシュレス決済もスムーズにできてとても良い！などのお声をいただきました。 多くの方にお越しいただきました 🙌 自身が開発しているプロダクトに込める思いは人一倍 👀✨ メドレー登壇 当社の髙橋(医療プラットフォーム本部)と德永(人材プラットフォーム)が登壇しました。 高橋のセッションの様子 次々に参加者が増えていき、最終的には 50 名近くの方にご覧いただきました 🙌 オンライン配信を含め、ご視聴いただいた皆様、ありがとうございました！ 登壇した髙橋より一言 セッションや登壇資料をご覧頂いた皆様、ありがとうございました！当日のブースや懇親会、また X やブログを通じて、皆様から多くのご感想を頂き感謝の気持ちでいっぱいです。発表で詳しく取り上げられなかった内容に関する Q&A を以下に公開します。 コンポーネントの分割粒度をチーム全体でどのように統一していますか？ 発表内で紹介した{関心事}{状況}{ベースコンポーネント名}の命名規則を守ることで Button や Dialog の単位で自然とコンポーネントが分割されるようなメンタルモデルを築いています。加えて Plop を使ってテンプレートコードを生成することで実装がブレないようにしています。 状態管理ライブラリはどのように使い分けていますか？ 非同期状態管理は Tanstack Query 、フォーム状態管理は React Hook Form 、その他の UI に関する状態は React.useState のように使い分けています。複合コンポーネント間で親子関係がある場合は React.createContext を使って依存関係を表現することがあります。このとき、子コンポーネントの Storybook の decorator に Context Provider を設定することで、複合コンポーネント間の連携を含めた Story とそのテストを実装しています。 Redux はサーバキャッシュとして運用していましたが、現在は Tanstack Query への移行を進めているため積極的な利用は避けています。 👇 登壇資料はこちら 德永のセッションの様子 登壇した徳永より一言 Remix のファイルベースルーティングについて LT させていただきました。当日に React Router v7 が正式リリースされるなど想定外のことが起こりつつも、皆さんにホットな話題として取り上げていただき有り難かったです。 👇 登壇資料はこちら 終わりに メドレーはこれからも医療ヘルスケア領域において、医療体験にインパクトを与えるプロダクトやサービスの開発に取り組んでいきます。引き続き技術的なチャレンジも行っていきますのでご注目ください！ 最後に、改めて JSConf JP 2024 の運営の皆様、登壇されたスピーカーの皆様、参加者の皆様、ありがとうございました。来年の開催も楽しみにしています！ ミイダス社とメルカリ社の素敵なノベルティをいただきました ✨ メドレーでは一緒に働く仲間を募集しています。 ぜひこの記事やブースや登壇などで興味を持っていただいた方はご連絡をお待ちしております！カジュアル面談も大歓迎ですので、お気軽にお問い合わせください！ 当日会場でお時間いただいた皆様、ありがとうございました！ メドレーは今後も技術イベントへ出展/登壇する予定です。今後も皆さんにお会いすることを楽しみにしています！

こんにちは！人材プラットフォーム本部で技術広報兼エンジニア採用をしている重田( @Shige0096 )です。2024 年 11 月にメドレーにジョインし、初の社外イベントに参加してきました。 今回、メドレーは 2024/11/23 に九段坂上 KS ビルにて開催された「 JSConf JP 2024 」にプレミアムスポンサーとして協賛させていただきました。 JSConf JP は一般社団法人 Japan Node.js Association によって企画・運営されている JavaScript に関する“⁠ お祭り ⁠”です。日本と海外の Web 開発者を繋げる目的で企画されています。2020 年から開催され、今年で 5 回目。今年もフロントエンドエンジニア・採用人事・技術広報担当を中心に多くの参加者が訪れました。 会場の様子 会場は九段坂上 KS ビル。今年はオンライン・オフラインのハイブリッド開催でした。現地チケットは売り切れてしまったので、オンライン配信があるのは嬉しいですね。 当日は 4 つのトラックに分かれ、時間帯によっては 4 セッションが同時並行していました。 セッション数が多くとても充実したイベントになりました。 会場入り口 メドレーブースの様子 メドレーブースでは「医療体験あるある」をパネルを用いてアンケート調査しました。 エンジニアをはじめ多くの方にお越しいただきました！お越しいただいた皆様ありがとうございました ✨ 特に多かった「医療体験あるある」は以下 2 つ。 ① キャッシュレス決済がしたい ⇨ キャッシュレス対応が進んできたがまだまだ現金対応の病院が多い ⇨ 現金を引き落としに一度コンビニに行くことがあった ② 待ち時間が長い（ほぼ同率 １ 位） ⇨ 予約したはずなのに待ち時間が発生している ⇨ いつも混んでいるので病院に行くのが疲れる 実際に CLINICS アプリ の画面をご覧いただきながら以下のようなお話をしました。オンライン診療を受けたのち、ご要望に合わせて薬を Uber で配達することも可能であることや、何よりキャッシュレス決済もスムーズにできてとても良い！などのお声をいただきました。 多くの方にお越しいただきました 🙌 自身が開発しているプロダクトに込める思いは人一倍 👀✨ メドレー登壇 当社の髙橋(医療プラットフォーム本部)と德永(人材プラットフォーム)が登壇しました。 高橋のセッションの様子 次々に参加者が増えていき、最終的には 50 名近くの方にご覧いただきました 🙌 オンライン配信を含め、ご視聴いただいた皆様、ありがとうございました！ 登壇した髙橋より一言 セッションや登壇資料をご覧頂いた皆様、ありがとうございました！当日のブースや懇親会、また X やブログを通じて、皆様から多くのご感想を頂き感謝の気持ちでいっぱいです。発表で詳しく取り上げられなかった内容に関する Q&A を以下に公開します。 コンポーネントの分割粒度をチーム全体でどのように統一していますか？ 発表内で紹介した{関心事}{状況}{ベースコンポーネント名}の命名規則を守ることで Button や Dialog の単位で自然とコンポーネントが分割されるようなメンタルモデルを築いています。加えて Plop を使ってテンプレートコードを生成することで実装がブレないようにしています。 状態管理ライブラリはどのように使い分けていますか？ 非同期状態管理は Tanstack Query 、フォーム状態管理は React Hook Form 、その他の UI に関する状態は React.useState のように使い分けています。複合コンポーネント間で親子関係がある場合は React.createContext を使って依存関係を表現することがあります。このとき、子コンポーネントの Storybook の decorator に Context Provider を設定することで、複合コンポーネント間の連携を含めた Story とそのテストを実装しています。 Redux はサーバキャッシュとして運用していましたが、現在は Tanstack Query への移行を進めているため積極的な利用は避けています。 👇 登壇資料はこちら 德永のセッションの様子 登壇した徳永より一言 Remix のファイルベースルーティングについて LT させていただきました。当日に React Router v7 が正式リリースされるなど想定外のことが起こりつつも、皆さんにホットな話題として取り上げていただき有り難かったです。 👇 登壇資料はこちら 終わりに メドレーはこれからも医療ヘルスケア領域において、医療体験にインパクトを与えるプロダクトやサービスの開発に取り組んでいきます。引き続き技術的なチャレンジも行っていきますのでご注目ください！ 最後に、改めて JSConf JP 2024 の運営の皆様、登壇されたスピーカーの皆様、参加者の皆様、ありがとうございました。来年の開催も楽しみにしています！ ミイダス社とメルカリ社の素敵なノベルティをいただきました ✨ メドレーでは一緒に働く仲間を募集しています。 ぜひこの記事やブースや登壇などで興味を持っていただいた方はご連絡をお待ちしております！カジュアル面談も大歓迎ですので、お気軽にお問い合わせください！ 当日会場でお時間いただいた皆様、ありがとうございました！ メドレーは今後も技術イベントへ出展/登壇する予定です。今後も皆さんにお会いすることを楽しみにしています！

こんにちは！人材プラットフォーム本部で技術広報兼エンジニア採用をしている重田( @Shige0096 )です。2024 年 11 月にメドレーにジョインし、初の社外イベントに参加してきました。 今回、メドレーは 2024/11/23 に九段坂上 KS ビルにて開催された「 JSConf JP 2024 」にプレミアムスポンサーとして協賛させていただきました。 JSConf JP は一般社団法人 Japan Node.js Association によって企画・運営されている JavaScript に関する“⁠ お祭り ⁠”です。日本と海外の Web 開発者を繋げる目的で企画されています。2020 年から開催され、今年で 5 回目。今年もフロントエンドエンジニア・採用人事・技術広報担当を中心に多くの参加者が訪れました。 会場の様子 会場は九段坂上 KS ビル。今年はオンライン・オフラインのハイブリッド開催でした。現地チケットは売り切れてしまったので、オンライン配信があるのは嬉しいですね。 当日は 4 つのトラックに分かれ、時間帯によっては 4 セッションが同時並行していました。 セッション数が多くとても充実したイベントになりました。 会場入り口 メドレーブースの様子 メドレーブースでは「医療体験あるある」をパネルを用いてアンケート調査しました。 エンジニアをはじめ多くの方にお越しいただきました！お越しいただいた皆様ありがとうございました ✨ 特に多かった「医療体験あるある」は以下 2 つ。 ① キャッシュレス決済がしたい ⇨ キャッシュレス対応が進んできたがまだまだ現金対応の病院が多い ⇨ 現金を引き落としに一度コンビニに行くことがあった ② 待ち時間が長い（ほぼ同率 １ 位） ⇨ 予約したはずなのに待ち時間が発生している ⇨ いつも混んでいるので病院に行くのが疲れる 実際に CLINICS アプリ の画面をご覧いただきながら以下のようなお話をしました。オンライン診療を受けたのち、ご要望に合わせて薬を Uber で配達することも可能であることや、何よりキャッシュレス決済もスムーズにできてとても良い！などのお声をいただきました。 多くの方にお越しいただきました 🙌 自身が開発しているプロダクトに込める思いは人一倍 👀✨ メドレー登壇 当社の髙橋(医療プラットフォーム本部)と德永(人材プラットフォーム)が登壇しました。 高橋のセッションの様子 次々に参加者が増えていき、最終的には 50 名近くの方にご覧いただきました 🙌 オンライン配信を含め、ご視聴いただいた皆様、ありがとうございました！ 登壇した髙橋より一言 セッションや登壇資料をご覧頂いた皆様、ありがとうございました！当日のブースや懇親会、また X やブログを通じて、皆様から多くのご感想を頂き感謝の気持ちでいっぱいです。発表で詳しく取り上げられなかった内容に関する Q&A を以下に公開します。 コンポーネントの分割粒度をチーム全体でどのように統一していますか？ 発表内で紹介した{関心事}{状況}{ベースコンポーネント名}の命名規則を守ることで Button や Dialog の単位で自然とコンポーネントが分割されるようなメンタルモデルを築いています。加えて Plop を使ってテンプレートコードを生成することで実装がブレないようにしています。 状態管理ライブラリはどのように使い分けていますか？ 非同期状態管理は Tanstack Query 、フォーム状態管理は React Hook Form 、その他の UI に関する状態は React.useState のように使い分けています。複合コンポーネント間で親子関係がある場合は React.createContext を使って依存関係を表現することがあります。このとき、子コンポーネントの Storybook の decorator に Context Provider を設定することで、複合コンポーネント間の連携を含めた Story とそのテストを実装しています。 Redux はサーバキャッシュとして運用していましたが、現在は Tanstack Query への移行を進めているため積極的な利用は避けています。 👇 登壇資料はこちら 德永のセッションの様子 登壇した徳永より一言 Remix のファイルベースルーティングについて LT させていただきました。当日に React Router v7 が正式リリースされるなど想定外のことが起こりつつも、皆さんにホットな話題として取り上げていただき有り難かったです。 👇 登壇資料はこちら 終わりに メドレーはこれからも医療ヘルスケア領域において、医療体験にインパクトを与えるプロダクトやサービスの開発に取り組んでいきます。引き続き技術的なチャレンジも行っていきますのでご注目ください！ 最後に、改めて JSConf JP 2024 の運営の皆様、登壇されたスピーカーの皆様、参加者の皆様、ありがとうございました。来年の開催も楽しみにしています！ ミイダス社とメルカリ社の素敵なノベルティをいただきました ✨ メドレーでは一緒に働く仲間を募集しています。 ぜひこの記事やブースや登壇などで興味を持っていただいた方はご連絡をお待ちしております！カジュアル面談も大歓迎ですので、お気軽にお問い合わせください！ 当日会場でお時間いただいた皆様、ありがとうございました！ メドレーは今後も技術イベントへ出展/登壇する予定です。今後も皆さんにお会いすることを楽しみにしています！

こんにちは！人材プラットフォーム本部で技術広報兼エンジニア採用をしている重田( @Shige0096 )です。2024 年 11 月にメドレーにジョインし、初の社外イベントに参加してきました。 今回、メドレーは 2024/11/23 に九段坂上 KS ビルにて開催された「 JSConf JP 2024 」にプレミアムスポンサーとして協賛させていただきました。 JSConf JP は一般社団法人 Japan Node.js Association によって企画・運営されている JavaScript に関する“⁠ お祭り ⁠”です。日本と海外の Web 開発者を繋げる目的で企画されています。2020 年から開催され、今年で 5 回目。今年もフロントエンドエンジニア・採用人事・技術広報担当を中心に多くの参加者が訪れました。 会場の様子 会場は九段坂上 KS ビル。今年はオンライン・オフラインのハイブリッド開催でした。現地チケットは売り切れてしまったので、オンライン配信があるのは嬉しいですね。 当日は 4 つのトラックに分かれ、時間帯によっては 4 セッションが同時並行していました。 セッション数が多くとても充実したイベントになりました。 会場入り口 メドレーブースの様子 メドレーブースでは「医療体験あるある」をパネルを用いてアンケート調査しました。 エンジニアをはじめ多くの方にお越しいただきました！お越しいただいた皆様ありがとうございました ✨ 特に多かった「医療体験あるある」は以下 2 つ。 ① キャッシュレス決済がしたい ⇨ キャッシュレス対応が進んできたがまだまだ現金対応の病院が多い ⇨ 現金を引き落としに一度コンビニに行くことがあった ② 待ち時間が長い（ほぼ同率 １ 位） ⇨ 予約したはずなのに待ち時間が発生している ⇨ いつも混んでいるので病院に行くのが疲れる 実際に CLINICS アプリ の画面をご覧いただきながら以下のようなお話をしました。オンライン診療を受けたのち、ご要望に合わせて薬を Uber で配達することも可能であることや、何よりキャッシュレス決済もスムーズにできてとても良い！などのお声をいただきました。 多くの方にお越しいただきました 🙌 自身が開発しているプロダクトに込める思いは人一倍 👀✨ メドレー登壇 当社の髙橋(医療プラットフォーム本部)と德永(人材プラットフォーム)が登壇しました。 高橋のセッションの様子 次々に参加者が増えていき、最終的には 50 名近くの方にご覧いただきました 🙌 オンライン配信を含め、ご視聴いただいた皆様、ありがとうございました！ 登壇した髙橋より一言 セッションや登壇資料をご覧頂いた皆様、ありがとうございました！当日のブースや懇親会、また X やブログを通じて、皆様から多くのご感想を頂き感謝の気持ちでいっぱいです。発表で詳しく取り上げられなかった内容に関する Q&A を以下に公開します。 コンポーネントの分割粒度をチーム全体でどのように統一していますか？ 発表内で紹介した{関心事}{状況}{ベースコンポーネント名}の命名規則を守ることで Button や Dialog の単位で自然とコンポーネントが分割されるようなメンタルモデルを築いています。加えて Plop を使ってテンプレートコードを生成することで実装がブレないようにしています。 状態管理ライブラリはどのように使い分けていますか？ 非同期状態管理は Tanstack Query 、フォーム状態管理は React Hook Form 、その他の UI に関する状態は React.useState のように使い分けています。複合コンポーネント間で親子関係がある場合は React.createContext を使って依存関係を表現することがあります。このとき、子コンポーネントの Storybook の decorator に Context Provider を設定することで、複合コンポーネント間の連携を含めた Story とそのテストを実装しています。 Redux はサーバキャッシュとして運用していましたが、現在は Tanstack Query への移行を進めているため積極的な利用は避けています。 👇 登壇資料はこちら 德永のセッションの様子 登壇した徳永より一言 Remix のファイルベースルーティングについて LT させていただきました。当日に React Router v7 が正式リリースされるなど想定外のことが起こりつつも、皆さんにホットな話題として取り上げていただき有り難かったです。 👇 登壇資料はこちら 終わりに メドレーはこれからも医療ヘルスケア領域において、医療体験にインパクトを与えるプロダクトやサービスの開発に取り組んでいきます。引き続き技術的なチャレンジも行っていきますのでご注目ください！ 最後に、改めて JSConf JP 2024 の運営の皆様、登壇されたスピーカーの皆様、参加者の皆様、ありがとうございました。来年の開催も楽しみにしています！ ミイダス社とメルカリ社の素敵なノベルティをいただきました ✨ メドレーでは一緒に働く仲間を募集しています。 ぜひこの記事やブースや登壇などで興味を持っていただいた方はご連絡をお待ちしております！カジュアル面談も大歓迎ですので、お気軽にお問い合わせください！ 当日会場でお時間いただいた皆様、ありがとうございました！ メドレーは今後も技術イベントへ出展/登壇する予定です。今後も皆さんにお会いすることを楽しみにしています！

こんにちは！人材プラットフォーム本部で技術広報兼エンジニア採用をしている重田( @Shige0096 )です。2024 年 11 月にメドレーにジョインし、初の社外イベントに参加してきました。 今回、メドレーは 2024/11/23 に九段坂上 KS ビルにて開催された「 JSConf JP 2024 」にプレミアムスポンサーとして協賛させていただきました。 JSConf JP は一般社団法人 Japan Node.js Association によって企画・運営されている JavaScript に関する“⁠ お祭り ⁠”です。日本と海外の Web 開発者を繋げる目的で企画されています。2020 年から開催され、今年で 5 回目。今年もフロントエンドエンジニア・採用人事・技術広報担当を中心に多くの参加者が訪れました。 会場の様子 会場は九段坂上 KS ビル。今年はオンライン・オフラインのハイブリッド開催でした。現地チケットは売り切れてしまったので、オンライン配信があるのは嬉しいですね。 当日は 4 つのトラックに分かれ、時間帯によっては 4 セッションが同時並行していました。 セッション数が多くとても充実したイベントになりました。 会場入り口 メドレーブースの様子 メドレーブースでは「医療体験あるある」をパネルを用いてアンケート調査しました。 エンジニアをはじめ多くの方にお越しいただきました！お越しいただいた皆様ありがとうございました ✨ 特に多かった「医療体験あるある」は以下 2 つ。 ① キャッシュレス決済がしたい ⇨ キャッシュレス対応が進んできたがまだまだ現金対応の病院が多い ⇨ 現金を引き落としに一度コンビニに行くことがあった ② 待ち時間が長い（ほぼ同率 １ 位） ⇨ 予約したはずなのに待ち時間が発生している ⇨ いつも混んでいるので病院に行くのが疲れる 実際に CLINICS アプリ の画面をご覧いただきながら以下のようなお話をしました。オンライン診療を受けたのち、ご要望に合わせて薬を Uber で配達することも可能であることや、何よりキャッシュレス決済もスムーズにできてとても良い！などのお声をいただきました。 多くの方にお越しいただきました 🙌 自身が開発しているプロダクトに込める思いは人一倍 👀✨ メドレー登壇 当社の髙橋(医療プラットフォーム本部)と德永(人材プラットフォーム)が登壇しました。 高橋のセッションの様子 次々に参加者が増えていき、最終的には 50 名近くの方にご覧いただきました 🙌 オンライン配信を含め、ご視聴いただいた皆様、ありがとうございました！ 登壇した髙橋より一言 セッションや登壇資料をご覧頂いた皆様、ありがとうございました！当日のブースや懇親会、また X やブログを通じて、皆様から多くのご感想を頂き感謝の気持ちでいっぱいです。発表で詳しく取り上げられなかった内容に関する Q&A を以下に公開します。 コンポーネントの分割粒度をチーム全体でどのように統一していますか？ 発表内で紹介した{関心事}{状況}{ベースコンポーネント名}の命名規則を守ることで Button や Dialog の単位で自然とコンポーネントが分割されるようなメンタルモデルを築いています。加えて Plop を使ってテンプレートコードを生成することで実装がブレないようにしています。 状態管理ライブラリはどのように使い分けていますか？ 非同期状態管理は Tanstack Query 、フォーム状態管理は React Hook Form 、その他の UI に関する状態は React.useState のように使い分けています。複合コンポーネント間で親子関係がある場合は React.createContext を使って依存関係を表現することがあります。このとき、子コンポーネントの Storybook の decorator に Context Provider を設定することで、複合コンポーネント間の連携を含めた Story とそのテストを実装しています。 Redux はサーバキャッシュとして運用していましたが、現在は Tanstack Query への移行を進めているため積極的な利用は避けています。 👇 登壇資料はこちら 德永のセッションの様子 登壇した徳永より一言 Remix のファイルベースルーティングについて LT させていただきました。当日に React Router v7 が正式リリースされるなど想定外のことが起こりつつも、皆さんにホットな話題として取り上げていただき有り難かったです。 👇 登壇資料はこちら 終わりに メドレーはこれからも医療ヘルスケア領域において、医療体験にインパクトを与えるプロダクトやサービスの開発に取り組んでいきます。引き続き技術的なチャレンジも行っていきますのでご注目ください！ 最後に、改めて JSConf JP 2024 の運営の皆様、登壇されたスピーカーの皆様、参加者の皆様、ありがとうございました。来年の開催も楽しみにしています！ ミイダス社とメルカリ社の素敵なノベルティをいただきました ✨ メドレーでは一緒に働く仲間を募集しています。 ぜひこの記事やブースや登壇などで興味を持っていただいた方はご連絡をお待ちしております！カジュアル面談も大歓迎ですので、お気軽にお問い合わせください！ 当日会場でお時間いただいた皆様、ありがとうございました！ メドレーは今後も技術イベントへ出展/登壇する予定です。今後も皆さんにお会いすることを楽しみにしています！

こんにちは！人材プラットフォーム本部で技術広報兼エンジニア採用をしている重田( @Shige0096 )です。2024 年 11 月にメドレーにジョインし、初の社外イベントに参加してきました。 今回、メドレーは 2024/11/23 に九段坂上 KS ビルにて開催された「 JSConf JP 2024 」にプレミアムスポンサーとして協賛させていただきました。 JSConf JP は一般社団法人 Japan Node.js Association によって企画・運営されている JavaScript に関する“⁠ お祭り ⁠”です。日本と海外の Web 開発者を繋げる目的で企画されています。2020 年から開催され、今年で 5 回目。今年もフロントエンドエンジニア・採用人事・技術広報担当を中心に多くの参加者が訪れました。 会場の様子 会場は九段坂上 KS ビル。今年はオンライン・オフラインのハイブリッド開催でした。現地チケットは売り切れてしまったので、オンライン配信があるのは嬉しいですね。 当日は 4 つのトラックに分かれ、時間帯によっては 4 セッションが同時並行していました。 セッション数が多くとても充実したイベントになりました。 会場入り口 メドレーブースの様子 メドレーブースでは「医療体験あるある」をパネルを用いてアンケート調査しました。 エンジニアをはじめ多くの方にお越しいただきました！お越しいただいた皆様ありがとうございました ✨ 特に多かった「医療体験あるある」は以下 2 つ。 ① キャッシュレス決済がしたい ⇨ キャッシュレス対応が進んできたがまだまだ現金対応の病院が多い ⇨ 現金を引き落としに一度コンビニに行くことがあった ② 待ち時間が長い（ほぼ同率 １ 位） ⇨ 予約したはずなのに待ち時間が発生している ⇨ いつも混んでいるので病院に行くのが疲れる 実際に CLINICS アプリ の画面をご覧いただきながら以下のようなお話をしました。オンライン診療を受けたのち、ご要望に合わせて薬を Uber で配達することも可能であることや、何よりキャッシュレス決済もスムーズにできてとても良い！などのお声をいただきました。 多くの方にお越しいただきました 🙌 自身が開発しているプロダクトに込める思いは人一倍 👀✨ メドレー登壇 当社の髙橋(医療プラットフォーム本部)と德永(人材プラットフォーム)が登壇しました。 高橋のセッションの様子 次々に参加者が増えていき、最終的には 50 名近くの方にご覧いただきました 🙌 オンライン配信を含め、ご視聴いただいた皆様、ありがとうございました！ 登壇した髙橋より一言 セッションや登壇資料をご覧頂いた皆様、ありがとうございました！当日のブースや懇親会、また X やブログを通じて、皆様から多くのご感想を頂き感謝の気持ちでいっぱいです。発表で詳しく取り上げられなかった内容に関する Q&A を以下に公開します。 コンポーネントの分割粒度をチーム全体でどのように統一していますか？ 発表内で紹介した{関心事}{状況}{ベースコンポーネント名}の命名規則を守ることで Button や Dialog の単位で自然とコンポーネントが分割されるようなメンタルモデルを築いています。加えて Plop を使ってテンプレートコードを生成することで実装がブレないようにしています。 状態管理ライブラリはどのように使い分けていますか？ 非同期状態管理は Tanstack Query 、フォーム状態管理は React Hook Form 、その他の UI に関する状態は React.useState のように使い分けています。複合コンポーネント間で親子関係がある場合は React.createContext を使って依存関係を表現することがあります。このとき、子コンポーネントの Storybook の decorator に Context Provider を設定することで、複合コンポーネント間の連携を含めた Story とそのテストを実装しています。 Redux はサーバキャッシュとして運用していましたが、現在は Tanstack Query への移行を進めているため積極的な利用は避けています。 👇 登壇資料はこちら 德永のセッションの様子 登壇した徳永より一言 Remix のファイルベースルーティングについて LT させていただきました。当日に React Router v7 が正式リリースされるなど想定外のことが起こりつつも、皆さんにホットな話題として取り上げていただき有り難かったです。 👇 登壇資料はこちら 終わりに メドレーはこれからも医療ヘルスケア領域において、医療体験にインパクトを与えるプロダクトやサービスの開発に取り組んでいきます。引き続き技術的なチャレンジも行っていきますのでご注目ください！ 最後に、改めて JSConf JP 2024 の運営の皆様、登壇されたスピーカーの皆様、参加者の皆様、ありがとうございました。来年の開催も楽しみにしています！ ミイダス社とメルカリ社の素敵なノベルティをいただきました ✨ メドレーでは一緒に働く仲間を募集しています。 ぜひこの記事やブースや登壇などで興味を持っていただいた方はご連絡をお待ちしております！カジュアル面談も大歓迎ですので、お気軽にお問い合わせください！ 当日会場でお時間いただいた皆様、ありがとうございました！ メドレーは今後も技術イベントへ出展/登壇する予定です。今後も皆さんにお会いすることを楽しみにしています！

こちらの記事は Medley（メドレー） Advent Calendar 2024 の3日目の記事です。 Who are you? メドレーで主にSRE活動を行っている人材プラットフォーム本部 第四開発グループの玉井です。 最初に簡単にFAQ形式で自己紹介させていただこうと思います。 （昨日は何を食べましたか） ： 麺系ファストフードでは一番好きな小諸そば。 （好きな本は何ですか） ： 柳井正さんの自伝書『一勝九敗』は心に残っています。 （遊びに行くならどこに行きますか） ： アウトドアが好きなのでキャンプなど。 今回は利用しているAWS環境に IAM Identity Center を導入した話をさせていただこうと思います。 セキュリティと管理コストの天秤 メドレーではクレデンシャルな情報は厳重に管理され、平文で外部ツールに保存されることはありません。AWSのIAMユーザのアクセスキーに関しても同じです。 ただ、それでも心配になるのは PCの中に平文で残る情報 。PCも厳重に管理されているのでそうそう漏洩するものではありませんが、それでも可能性はゼロではありません。 一時はAssumeRoleを使うことで漏洩時のリスクを減らしました。 最初の認証では何もできない弱い権限で、AssumeRoleで権限の強いロールに変身する方式を導入しました。 この話を聞いて、腕に包帯を巻いた学生服の少年が天狗のお面を被るいらすとが浮かんだあなたはAWSデベロッパーお馴染みのあのブログの敬虔な読者です。 AssumeRole概要図 それでもまだ課題はありました。 IAMユーザとAssumeRoleの管理コスト です。 AWSアカウントはサービスごとに複数存在し、さらに本番環境、ステージング環境でも分けてあります。それぞれのAWSアカウントにアクセスできる環境を開発メンバーに提供する必要があります。 AssumeRoleは変身する元と変身した先の設定をする必要があり、AWSアカウントを跨ぐ場合はそれぞれのAWSアカウントに設定が必要になります。開発メンバーの異動がある度にあちらこちらのAWSアカウントにその設定をすることが、面倒なトイルになっていました。 セキュアな環境を維持したまま、管理コストもなるべく下げたい。 そこで導入を決めたのが IAM Identity Center でした。 IAM Identity Centerの導入検討 結論を先に申し上げますと、IAM Identity Centerを導入することで セキュアな環境を維持しながらトイルの削減も実現することができました 。 完璧で究極というほどではありませんが、誰もが目を奪われていく理想の環境に一歩近づくことがました。 IAM Identity Centerをさらに管理するAWS Control Towerの導入も検討しましたが、既にある環境に導入することの予期せぬ制限がかかることのリスクや、AWS Configが多用されることで思わぬコスト増が発生するとの情報もあり、今回は見送ることにしました。 IAM Identity Centerとは 元は AWS Single Sign-On （AWS SSO） というサービス名でした。 これはIAMユーザとは全く別物のユーザ（これをSSOユーザとします）を作成し、SSOユーザが各AWSアカウントの各IAMロールを持ったユーザに変身することができる機能です。 IAM Identity Center概要図 IAM Identity Centerを導入した決め手 SSOユーザと権限の管理は一つのAWSアカウントのIAM Identity Centerで管理することができます。 これはAWS Organizationsの機能の上に乗る機能ですが、幸い元々それを導入していたことで、すぐに組み込むことができました（ちなみに現在はIdPを設定することでAWS Organizationsがなくてもこの機能を使うことができます）。 つまり、 複数のAWSアカウントの複数のユーザの複数のロールを一つのIAM Identity Centerで全て管理することができるのです 。 では、各AWSアカウントで既に作成してしまったIAMポリシーを、IAM Identity Centerで同じ内容で作り直さないといけないかというとそんなこともなく、カスタムロールという設定で、IAMポリシー名だけ定義することで既存のIAMポリシーをそのまま活かすことができます。 そして、SSOユーザは恒久的なアクセスキーを持つことができず、最大で12時間の期限付きアクセスキーしか持つことができません。従って、 仮に万が一アクセスキーが漏洩しても12時間後には使えなくなります 。 まさに最強で無敵のIAM Identity Centerです。 IAM Identity Centerの導入 ここではIAM Identity Centerの導入の流れを簡単に説明いたします。 一番最初はIAM Identity Centerを有効にすることですが、それは割愛して有効化した後の手順を記載していきます。 IAM Identity Center全体図 SSOユーザの作成 SSOユーザは前述した通りIAMユーザとは全く別物なので、新たに全員分作成する必要があります。 最低限必要なのは名前とメールアドレスのみです。 作成画面に任意項目で住所や電話番号などあったりするのですが、システム的には全く関係ないようです。IAM Identity CenterをIdPとして使うときのための設定でしょうか。 SSOユーザ作成画面 SSOグループの作成 SSOグループとは、SSOユーザと後述する許可セットをまとめるためのものです。 新しいSSOユーザが増えた場合は、該当のグループに追加してあげるだけでOKです。 SSOグループ作成画面 許可セットの作成 許可セットは、IAMロールの素になるものです。 ここで設定したポリシーが各AWSアカウントにIAMロール、IAMポリシーとしてプロビジョニングされます。 プロビジョニング先のAWSアカウントに既にあるIAMポリシーを使いたい場合は、カスタマーマネージドポリシーでその名前を設定すれば割り当てることができます。 名前が間違っていて存在しないIAMポリシーを設定してしまった場合は、プロビジョニング時にエラーになります。 許可セット作成画面 プロビジョニング “SSOユーザまたはグループ” と “許可セット” を適用したいAWSアカウントにプロビジョニングすることで、対象SSOユーザで該当AWSアカウントにログイン可能になります。 プロビジョニング概要図 SSOアクセスポータル画面 SSOユーザでログインするAWSアクセスポータル画面に、AWSアカウントへのリンクの一覧が表示されます。 このリンクから各AWSアカウントに、任意のロールでログインすることができます。便利ですね！ AWSアクセスポータル画面 一時的なアクセスキーはCLIでも取得できますが、この画面からも アクセスキー のリンクをクリックすると一覧画面が表示されます。 AWSアクセスポータル アクセスキー確認画面 導入後に対応したこと これまでの手順でマネジメントコンソールのでログインはできるようになっていますが、それ以外のツール等で利用するためにしたことをここでは説明します。 ~/.aws/configの修正 ターミナルでAWS CLIを利用するために、これまでアクセスキーを直接指定していたのを、SSOユーザ対応の記述に変更する必要があります。 アクセスキーなどのクレデンシャルな情報の記載が不要になり、この内容が漏洩してもダメージが少ないです。 [default] sso_session = m y-sso sso_account_id = 999999999999 sso_role_name = x xxxxxxxxxxx [sso-session my-sso] sso_start_url = h ttps://xxxxxxxxxxxx.awsapps.com/start sso_registration_scopes = s so:account:access sso_sessionの設定が古いaws_sdkだと対応していなかったりしたので、最新のaws_sdkを使うように mise (開発ツール管理用ツール)に設定しました。 [tools] awscli = "latest" この設定をした状態で aws sso login を実行すると認証画面のブラウザが自動で立ち上がり、ブラウザでの認証完了後にターミナルでCLIが使えるようになります。 ターミナルでsso login ブラウザで認証 開発環境へのアクセスキーの渡し方 開発環境においてアクセスキーの設定が必要な箇所があり、それを毎日ポータル画面からコピペで更新してくださいというのは面倒すぎるので、毎日1回最初にシェルを実行してもらうようにしました（これも面倒なのでこれなしでどうにかできれば良かったのですが・・・無念）。 この実行にはSSOの認証情報をシェル内の処理で利用するため aws2-wrap を利用し、.envファイルの更新には python-dotenv を利用しました。 これもmiseで定義することで、全開発メンバーにもれなく対応できました。 # 一部抜粋 if ! $(aws2-wrap --profile " $profile " --export ); then aws sso login --profile= " $profile " eval "$( aws2-wrap --profile " $profile " --export )" fi # 一部抜粋 from dotenv import set_key def update_env_file ( env_file , key_value_pairs ): try : for key in key_value_pairs: value = key_value_pairs[key] set_key(env_file, key, value, quote_mode = 'never' ) except Exception as e: print (e) Terraform, Packerの対応 最新のTerraform、Packerではaws ssoに対応しているので、ssoのprofileをそのまま使うことができます（AssumeRoleには対応していなかったので、それを対応させた時は大変でした・・・）。 Terraformは環境依存をなくすため実行環境をコンテナ化しコンテナ内で実行しているのですが、“ログイン時にSSOセッションの存在有無の確認” → “なければSSOログイン” をさせることで、 aws sso login の事前実行を意識しなくても良いようにしました。 # 一部抜粋 function get_caller_identity () { set +eu for i in { 1..3} ; do command "aws sts get-caller-identity --profile $1 " if [[ $? = 0 ]]; then break else echo "Not logged in" command "aws sso login --profile $1 " fi done set -eu } 最新のPackerはaws ssoに対応していると前述しましたが、なぜだか環境により sso-session が効かずにエラーになる場合がありました。その場合はレガシーな記述方法で回避できます。 [profile packer] credential_process = a ws --profile default configure export-credentials --format process region = a p-northeast-1 output = j son 対応して良かったこと 管理者目線で良かったこと 管理者目線では、AWSのユーザ管理が大分楽になりました。 これまで開発メンバーが増えた際には、複数のAWSアカウントに対しそれぞれに、IAMユーザの作成、アクセスキーの生成をし、その後初期ログインパスワードとアクセスキーをメンバーに配布しなければならなかったため、作業が大分煩雑でした。 IAM Identity Center導入後は、 1つのAWSアカウントでSSOユーザを作成するだけです 。招待メールも勝手に送られます。 また、与えている権限の管理も楽になりました。 IAM Identity Centerの画面を見れば、誰がどのAWSアカウントにどんな権限を持っているか全てわかりますし、設定するのもそこだけなので 、いろんなAWSアカウントを出入りして確認・設定する必要がなくなりました。 利用者目線で良かったこと 利用者目線では、各AWSアカウントへのログインがポータル画面のリンクから行くことができるので、 AWSアカウントごとにログインの作業が必要なくなったのも楽ですし、各AWSアカウント毎にログイン情報、MFA情報を保持しなくても良くなったのも管理が気楽になりました 。 対応して困ったこと 12時間の壁 SSOユーザのセッション時間の上限が12時間のため、朝9時にログインすると夜9時にセッションが切れてしまいます。そのことを忘れて12時間後に急に開発環境でエラーが出始めて「なんじゃこりゃあああ！」とたまに驚かされます（12時間以上働くことがほとんどないのでめったに遭遇しませんが、だからこそ忘れます）。 深夜メンテの際にそれが起きるとトラブルになりますので、その際は作業前に必ずログインし直すようにしています。 個人的にはセッション時間の上限の時間もう少し上げて欲しいです。 利用できないサードパーティーツールの存在 AWSにアクセスするためのサードパーティーツールは様々ありますが、 AWS_ACCESS_KEY_ID 、 AWS_SECRET_ACCESS_KEY の2項目しか設定できないものがあります。 SSOユーザでログインするには、それらに加え AWS_SESSION_TOKEN の値が必要であるため、設定できないツールはSSOユーザでは利用できないことになります。 最近ではSSOユーザでも利用できるようにアップグレードされているツールも増えてきていますので、今まで使っていたツールが使えなくなった場合は代替のツールを使いましょう。 まとめ これは絶対嘘ではなくて、IAM Identity Centerを導入することで、トイルの削減も、情報漏洩リスクの削減も、両方実現することができました。 もちろん私たちの挑戦はこれで終わりではなく、サービスの品質を上げるため、開発メンバーが開発に集中できる環境を作るため、 俺たちの戦いはまだ始まったばかり 、です。 そして、明日12月4日は @shigerisa さんが何やらもっと面白い記事を書いてくれているようです！お楽しみに！ We’re hiring! メドレーでは各種エンジニアを絶賛募集中です！ カジュアル面談いつでもWelcomeですので、お話しだけでも聞いてみたい、むしろ私の推しの話を聞いて欲しい、などなんでもかまいませんので、お気軽にお問い合わせください！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こちらの記事は Medley（メドレー） Advent Calendar 2024 の3日目の記事です。 Who are you? メドレーで主にSRE活動を行っている人材プラットフォーム本部 第四開発グループの玉井です。 最初に簡単にFAQ形式で自己紹介させていただこうと思います。 （昨日は何を食べましたか） ： 麺系ファストフードでは一番好きな小諸そば。 （好きな本は何ですか） ： 柳井正さんの自伝書『一勝九敗』は心に残っています。 （遊びに行くならどこに行きますか） ： アウトドアが好きなのでキャンプなど。 今回は利用しているAWS環境に IAM Identity Center を導入した話をさせていただこうと思います。 セキュリティと管理コストの天秤 メドレーではクレデンシャルな情報は厳重に管理され、平文で外部ツールに保存されることはありません。AWSのIAMユーザのアクセスキーに関しても同じです。 ただ、それでも心配になるのは PCの中に平文で残る情報 。PCも厳重に管理されているのでそうそう漏洩するものではありませんが、それでも可能性はゼロではありません。 一時はAssumeRoleを使うことで漏洩時のリスクを減らしました。 最初の認証では何もできない弱い権限で、AssumeRoleで権限の強いロールに変身する方式を導入しました。 この話を聞いて、腕に包帯を巻いた学生服の少年が天狗のお面を被るいらすとが浮かんだあなたはAWSデベロッパーお馴染みのあのブログの敬虔な読者です。 AssumeRole概要図 それでもまだ課題はありました。 IAMユーザとAssumeRoleの管理コスト です。 AWSアカウントはサービスごとに複数存在し、さらに本番環境、ステージング環境でも分けてあります。それぞれのAWSアカウントにアクセスできる環境を開発メンバーに提供する必要があります。 AssumeRoleは変身する元と変身した先の設定をする必要があり、AWSアカウントを跨ぐ場合はそれぞれのAWSアカウントに設定が必要になります。開発メンバーの異動がある度にあちらこちらのAWSアカウントにその設定をすることが、面倒なトイルになっていました。 セキュアな環境を維持したまま、管理コストもなるべく下げたい。 そこで導入を決めたのが IAM Identity Center でした。 IAM Identity Centerの導入検討 結論を先に申し上げますと、IAM Identity Centerを導入することで セキュアな環境を維持しながらトイルの削減も実現することができました 。 完璧で究極というほどではありませんが、誰もが目を奪われていく理想の環境に一歩近づくことがました。 IAM Identity Centerをさらに管理するAWS Control Towerの導入も検討しましたが、既にある環境に導入することの予期せぬ制限がかかることのリスクや、AWS Configが多用されることで思わぬコスト増が発生するとの情報もあり、今回は見送ることにしました。 IAM Identity Centerとは 元は AWS Single Sign-On （AWS SSO） というサービス名でした。 これはIAMユーザとは全く別物のユーザ（これをSSOユーザとします）を作成し、SSOユーザが各AWSアカウントの各IAMロールを持ったユーザに変身することができる機能です。 IAM Identity Center概要図 IAM Identity Centerを導入した決め手 SSOユーザと権限の管理は一つのAWSアカウントのIAM Identity Centerで管理することができます。 これはAWS Organizationsの機能の上に乗る機能ですが、幸い元々それを導入していたことで、すぐに組み込むことができました（ちなみに現在はIdPを設定することでAWS Organizationsがなくてもこの機能を使うことができます）。 つまり、 複数のAWSアカウントの複数のユーザの複数のロールを一つのIAM Identity Centerで全て管理することができるのです 。 では、各AWSアカウントで既に作成してしまったIAMポリシーを、IAM Identity Centerで同じ内容で作り直さないといけないかというとそんなこともなく、カスタムロールという設定で、IAMポリシー名だけ定義することで既存のIAMポリシーをそのまま活かすことができます。 そして、SSOユーザは恒久的なアクセスキーを持つことができず、最大で12時間の期限付きアクセスキーしか持つことができません。従って、 仮に万が一アクセスキーが漏洩しても12時間後には使えなくなります 。 まさに最強で無敵のIAM Identity Centerです。 IAM Identity Centerの導入 ここではIAM Identity Centerの導入の流れを簡単に説明いたします。 一番最初はIAM Identity Centerを有効にすることですが、それは割愛して有効化した後の手順を記載していきます。 IAM Identity Center全体図 SSOユーザの作成 SSOユーザは前述した通りIAMユーザとは全く別物なので、新たに全員分作成する必要があります。 最低限必要なのは名前とメールアドレスのみです。 作成画面に任意項目で住所や電話番号などあったりするのですが、システム的には全く関係ないようです。IAM Identity CenterをIdPとして使うときのための設定でしょうか。 SSOユーザ作成画面 SSOグループの作成 SSOグループとは、SSOユーザと後述する許可セットをまとめるためのものです。 新しいSSOユーザが増えた場合は、該当のグループに追加してあげるだけでOKです。 SSOグループ作成画面 許可セットの作成 許可セットは、IAMロールの素になるものです。 ここで設定したポリシーが各AWSアカウントにIAMロール、IAMポリシーとしてプロビジョニングされます。 プロビジョニング先のAWSアカウントに既にあるIAMポリシーを使いたい場合は、カスタマーマネージドポリシーでその名前を設定すれば割り当てることができます。 名前が間違っていて存在しないIAMポリシーを設定してしまった場合は、プロビジョニング時にエラーになります。 許可セット作成画面 プロビジョニング “SSOユーザまたはグループ” と “許可セット” を適用したいAWSアカウントにプロビジョニングすることで、対象SSOユーザで該当AWSアカウントにログイン可能になります。 プロビジョニング概要図 SSOアクセスポータル画面 SSOユーザでログインするAWSアクセスポータル画面に、AWSアカウントへのリンクの一覧が表示されます。 このリンクから各AWSアカウントに、任意のロールでログインすることができます。便利ですね！ AWSアクセスポータル画面 一時的なアクセスキーはCLIでも取得できますが、この画面からも アクセスキー のリンクをクリックすると一覧画面が表示されます。 AWSアクセスポータル アクセスキー確認画面 導入後に対応したこと これまでの手順でマネジメントコンソールのでログインはできるようになっていますが、それ以外のツール等で利用するためにしたことをここでは説明します。 ~/.aws/configの修正 ターミナルでAWS CLIを利用するために、これまでアクセスキーを直接指定していたのを、SSOユーザ対応の記述に変更する必要があります。 アクセスキーなどのクレデンシャルな情報の記載が不要になり、この内容が漏洩してもダメージが少ないです。 [default] sso_session = m y-sso sso_account_id = 999999999999 sso_role_name = x xxxxxxxxxxx [sso-session my-sso] sso_start_url = h ttps://xxxxxxxxxxxx.awsapps.com/start sso_registration_scopes = s so:account:access sso_sessionの設定が古いaws_sdkだと対応していなかったりしたので、最新のaws_sdkを使うように mise (開発ツール管理用ツール)に設定しました。 [tools] awscli = "latest" この設定をした状態で aws sso login を実行すると認証画面のブラウザが自動で立ち上がり、ブラウザでの認証完了後にターミナルでCLIが使えるようになります。 ターミナルでsso login ブラウザで認証 開発環境へのアクセスキーの渡し方 開発環境においてアクセスキーの設定が必要な箇所があり、それを毎日ポータル画面からコピペで更新してくださいというのは面倒すぎるので、毎日1回最初にシェルを実行してもらうようにしました（これも面倒なのでこれなしでどうにかできれば良かったのですが・・・無念）。 この実行にはSSOの認証情報をシェル内の処理で利用するため aws2-wrap を利用し、.envファイルの更新には python-dotenv を利用しました。 これもmiseで定義することで、全開発メンバーにもれなく対応できました。 # 一部抜粋 if ! $(aws2-wrap --profile " $profile " --export ); then aws sso login --profile= " $profile " eval "$( aws2-wrap --profile " $profile " --export )" fi # 一部抜粋 from dotenv import set_key def update_env_file ( env_file , key_value_pairs ): try : for key in key_value_pairs: value = key_value_pairs[key] set_key(env_file, key, value, quote_mode = 'never' ) except Exception as e: print (e) Terraform, Packerの対応 最新のTerraform、Packerではaws ssoに対応しているので、ssoのprofileをそのまま使うことができます（AssumeRoleには対応していなかったので、それを対応させた時は大変でした・・・）。 Terraformは環境依存をなくすため実行環境をコンテナ化しコンテナ内で実行しているのですが、“ログイン時にSSOセッションの存在有無の確認” → “なければSSOログイン” をさせることで、 aws sso login の事前実行を意識しなくても良いようにしました。 # 一部抜粋 function get_caller_identity () { set +eu for i in { 1..3} ; do command "aws sts get-caller-identity --profile $1 " if [[ $? = 0 ]]; then break else echo "Not logged in" command "aws sso login --profile $1 " fi done set -eu } 最新のPackerはaws ssoに対応していると前述しましたが、なぜだか環境により sso-session が効かずにエラーになる場合がありました。その場合はレガシーな記述方法で回避できます。 [profile packer] credential_process = a ws --profile default configure export-credentials --format process region = a p-northeast-1 output = j son 対応して良かったこと 管理者目線で良かったこと 管理者目線では、AWSのユーザ管理が大分楽になりました。 これまで開発メンバーが増えた際には、複数のAWSアカウントに対しそれぞれに、IAMユーザの作成、アクセスキーの生成をし、その後初期ログインパスワードとアクセスキーをメンバーに配布しなければならなかったため、作業が大分煩雑でした。 IAM Identity Center導入後は、 1つのAWSアカウントでSSOユーザを作成するだけです 。招待メールも勝手に送られます。 また、与えている権限の管理も楽になりました。 IAM Identity Centerの画面を見れば、誰がどのAWSアカウントにどんな権限を持っているか全てわかりますし、設定するのもそこだけなので 、いろんなAWSアカウントを出入りして確認・設定する必要がなくなりました。 利用者目線で良かったこと 利用者目線では、各AWSアカウントへのログインがポータル画面のリンクから行くことができるので、 AWSアカウントごとにログインの作業が必要なくなったのも楽ですし、各AWSアカウント毎にログイン情報、MFA情報を保持しなくても良くなったのも管理が気楽になりました 。 対応して困ったこと 12時間の壁 SSOユーザのセッション時間の上限が12時間のため、朝9時にログインすると夜9時にセッションが切れてしまいます。そのことを忘れて12時間後に急に開発環境でエラーが出始めて「なんじゃこりゃあああ！」とたまに驚かされます（12時間以上働くことがほとんどないのでめったに遭遇しませんが、だからこそ忘れます）。 深夜メンテの際にそれが起きるとトラブルになりますので、その際は作業前に必ずログインし直すようにしています。 個人的にはセッション時間の上限の時間もう少し上げて欲しいです。 利用できないサードパーティーツールの存在 AWSにアクセスするためのサードパーティーツールは様々ありますが、 AWS_ACCESS_KEY_ID 、 AWS_SECRET_ACCESS_KEY の2項目しか設定できないものがあります。 SSOユーザでログインするには、それらに加え AWS_SESSION_TOKEN の値が必要であるため、設定できないツールはSSOユーザでは利用できないことになります。 最近ではSSOユーザでも利用できるようにアップグレードされているツールも増えてきていますので、今まで使っていたツールが使えなくなった場合は代替のツールを使いましょう。 まとめ これは絶対嘘ではなくて、IAM Identity Centerを導入することで、トイルの削減も、情報漏洩リスクの削減も、両方実現することができました。 もちろん私たちの挑戦はこれで終わりではなく、サービスの品質を上げるため、開発メンバーが開発に集中できる環境を作るため、 俺たちの戦いはまだ始まったばかり 、です。 そして、明日12月4日は @shigerisa さんが何やらもっと面白い記事を書いてくれているようです！お楽しみに！ We’re hiring! メドレーでは各種エンジニアを絶賛募集中です！ カジュアル面談いつでもWelcomeですので、お話しだけでも聞いてみたい、むしろ私の推しの話を聞いて欲しい、などなんでもかまいませんので、お気軽にお問い合わせください！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こちらの記事は Medley（メドレー） Advent Calendar 2024 の3日目の記事です。 Who are you? メドレーで主にSRE活動を行っている人材プラットフォーム本部 第四開発グループの玉井です。 最初に簡単にFAQ形式で自己紹介させていただこうと思います。 （昨日は何を食べましたか） ： 麺系ファストフードでは一番好きな小諸そば。 （好きな本は何ですか） ： 柳井正さんの自伝書『一勝九敗』は心に残っています。 （遊びに行くならどこに行きますか） ： アウトドアが好きなのでキャンプなど。 今回は利用しているAWS環境に IAM Identity Center を導入した話をさせていただこうと思います。 セキュリティと管理コストの天秤 メドレーではクレデンシャルな情報は厳重に管理され、平文で外部ツールに保存されることはありません。AWSのIAMユーザのアクセスキーに関しても同じです。 ただ、それでも心配になるのは PCの中に平文で残る情報 。PCも厳重に管理されているのでそうそう漏洩するものではありませんが、それでも可能性はゼロではありません。 一時はAssumeRoleを使うことで漏洩時のリスクを減らしました。 最初の認証では何もできない弱い権限で、AssumeRoleで権限の強いロールに変身する方式を導入しました。 この話を聞いて、腕に包帯を巻いた学生服の少年が天狗のお面を被るいらすとが浮かんだあなたはAWSデベロッパーお馴染みのあのブログの敬虔な読者です。 AssumeRole概要図 それでもまだ課題はありました。 IAMユーザとAssumeRoleの管理コスト です。 AWSアカウントはサービスごとに複数存在し、さらに本番環境、ステージング環境でも分けてあります。それぞれのAWSアカウントにアクセスできる環境を開発メンバーに提供する必要があります。 AssumeRoleは変身する元と変身した先の設定をする必要があり、AWSアカウントを跨ぐ場合はそれぞれのAWSアカウントに設定が必要になります。開発メンバーの異動がある度にあちらこちらのAWSアカウントにその設定をすることが、面倒なトイルになっていました。 セキュアな環境を維持したまま、管理コストもなるべく下げたい。 そこで導入を決めたのが IAM Identity Center でした。 IAM Identity Centerの導入検討 結論を先に申し上げますと、IAM Identity Centerを導入することで セキュアな環境を維持しながらトイルの削減も実現することができました 。 完璧で究極というほどではありませんが、誰もが目を奪われていく理想の環境に一歩近づくことがました。 IAM Identity Centerをさらに管理するAWS Control Towerの導入も検討しましたが、既にある環境に導入することの予期せぬ制限がかかることのリスクや、AWS Configが多用されることで思わぬコスト増が発生するとの情報もあり、今回は見送ることにしました。 IAM Identity Centerとは 元は AWS Single Sign-On （AWS SSO） というサービス名でした。 これはIAMユーザとは全く別物のユーザ（これをSSOユーザとします）を作成し、SSOユーザが各AWSアカウントの各IAMロールを持ったユーザに変身することができる機能です。 IAM Identity Center概要図 IAM Identity Centerを導入した決め手 SSOユーザと権限の管理は一つのAWSアカウントのIAM Identity Centerで管理することができます。 これはAWS Organizationsの機能の上に乗る機能ですが、幸い元々それを導入していたことで、すぐに組み込むことができました（ちなみに現在はIdPを設定することでAWS Organizationsがなくてもこの機能を使うことができます）。 つまり、 複数のAWSアカウントの複数のユーザの複数のロールを一つのIAM Identity Centerで全て管理することができるのです 。 では、各AWSアカウントで既に作成してしまったIAMポリシーを、IAM Identity Centerで同じ内容で作り直さないといけないかというとそんなこともなく、カスタムロールという設定で、IAMポリシー名だけ定義することで既存のIAMポリシーをそのまま活かすことができます。 そして、SSOユーザは恒久的なアクセスキーを持つことができず、最大で12時間の期限付きアクセスキーしか持つことができません。従って、 仮に万が一アクセスキーが漏洩しても12時間後には使えなくなります 。 まさに最強で無敵のIAM Identity Centerです。 IAM Identity Centerの導入 ここではIAM Identity Centerの導入の流れを簡単に説明いたします。 一番最初はIAM Identity Centerを有効にすることですが、それは割愛して有効化した後の手順を記載していきます。 IAM Identity Center全体図 SSOユーザの作成 SSOユーザは前述した通りIAMユーザとは全く別物なので、新たに全員分作成する必要があります。 最低限必要なのは名前とメールアドレスのみです。 作成画面に任意項目で住所や電話番号などあったりするのですが、システム的には全く関係ないようです。IAM Identity CenterをIdPとして使うときのための設定でしょうか。 SSOユーザ作成画面 SSOグループの作成 SSOグループとは、SSOユーザと後述する許可セットをまとめるためのものです。 新しいSSOユーザが増えた場合は、該当のグループに追加してあげるだけでOKです。 SSOグループ作成画面 許可セットの作成 許可セットは、IAMロールの素になるものです。 ここで設定したポリシーが各AWSアカウントにIAMロール、IAMポリシーとしてプロビジョニングされます。 プロビジョニング先のAWSアカウントに既にあるIAMポリシーを使いたい場合は、カスタマーマネージドポリシーでその名前を設定すれば割り当てることができます。 名前が間違っていて存在しないIAMポリシーを設定してしまった場合は、プロビジョニング時にエラーになります。 許可セット作成画面 プロビジョニング “SSOユーザまたはグループ” と “許可セット” を適用したいAWSアカウントにプロビジョニングすることで、対象SSOユーザで該当AWSアカウントにログイン可能になります。 プロビジョニング概要図 SSOアクセスポータル画面 SSOユーザでログインするAWSアクセスポータル画面に、AWSアカウントへのリンクの一覧が表示されます。 このリンクから各AWSアカウントに、任意のロールでログインすることができます。便利ですね！ AWSアクセスポータル画面 一時的なアクセスキーはCLIでも取得できますが、この画面からも アクセスキー のリンクをクリックすると一覧画面が表示されます。 AWSアクセスポータル アクセスキー確認画面 導入後に対応したこと これまでの手順でマネジメントコンソールのでログインはできるようになっていますが、それ以外のツール等で利用するためにしたことをここでは説明します。 ~/.aws/configの修正 ターミナルでAWS CLIを利用するために、これまでアクセスキーを直接指定していたのを、SSOユーザ対応の記述に変更する必要があります。 アクセスキーなどのクレデンシャルな情報の記載が不要になり、この内容が漏洩してもダメージが少ないです。 [default] sso_session = m y-sso sso_account_id = 999999999999 sso_role_name = x xxxxxxxxxxx [sso-session my-sso] sso_start_url = h ttps://xxxxxxxxxxxx.awsapps.com/start sso_registration_scopes = s so:account:access sso_sessionの設定が古いaws_sdkだと対応していなかったりしたので、最新のaws_sdkを使うように mise (開発ツール管理用ツール)に設定しました。 [tools] awscli = "latest" この設定をした状態で aws sso login を実行すると認証画面のブラウザが自動で立ち上がり、ブラウザでの認証完了後にターミナルでCLIが使えるようになります。 ターミナルでsso login ブラウザで認証 開発環境へのアクセスキーの渡し方 開発環境においてアクセスキーの設定が必要な箇所があり、それを毎日ポータル画面からコピペで更新してくださいというのは面倒すぎるので、毎日1回最初にシェルを実行してもらうようにしました（これも面倒なのでこれなしでどうにかできれば良かったのですが・・・無念）。 この実行にはSSOの認証情報をシェル内の処理で利用するため aws2-wrap を利用し、.envファイルの更新には python-dotenv を利用しました。 これもmiseで定義することで、全開発メンバーにもれなく対応できました。 # 一部抜粋 if ! $(aws2-wrap --profile " $profile " --export ); then aws sso login --profile= " $profile " eval "$( aws2-wrap --profile " $profile " --export )" fi # 一部抜粋 from dotenv import set_key def update_env_file ( env_file , key_value_pairs ): try : for key in key_value_pairs: value = key_value_pairs[key] set_key(env_file, key, value, quote_mode = 'never' ) except Exception as e: print (e) Terraform, Packerの対応 最新のTerraform、Packerではaws ssoに対応しているので、ssoのprofileをそのまま使うことができます（AssumeRoleには対応していなかったので、それを対応させた時は大変でした・・・）。 Terraformは環境依存をなくすため実行環境をコンテナ化しコンテナ内で実行しているのですが、“ログイン時にSSOセッションの存在有無の確認” → “なければSSOログイン” をさせることで、 aws sso login の事前実行を意識しなくても良いようにしました。 # 一部抜粋 function get_caller_identity () { set +eu for i in { 1..3} ; do command "aws sts get-caller-identity --profile $1 " if [[ $? = 0 ]]; then break else echo "Not logged in" command "aws sso login --profile $1 " fi done set -eu } 最新のPackerはaws ssoに対応していると前述しましたが、なぜだか環境により sso-session が効かずにエラーになる場合がありました。その場合はレガシーな記述方法で回避できます。 [profile packer] credential_process = a ws --profile default configure export-credentials --format process region = a p-northeast-1 output = j son 対応して良かったこと 管理者目線で良かったこと 管理者目線では、AWSのユーザ管理が大分楽になりました。 これまで開発メンバーが増えた際には、複数のAWSアカウントに対しそれぞれに、IAMユーザの作成、アクセスキーの生成をし、その後初期ログインパスワードとアクセスキーをメンバーに配布しなければならなかったため、作業が大分煩雑でした。 IAM Identity Center導入後は、 1つのAWSアカウントでSSOユーザを作成するだけです 。招待メールも勝手に送られます。 また、与えている権限の管理も楽になりました。 IAM Identity Centerの画面を見れば、誰がどのAWSアカウントにどんな権限を持っているか全てわかりますし、設定するのもそこだけなので 、いろんなAWSアカウントを出入りして確認・設定する必要がなくなりました。 利用者目線で良かったこと 利用者目線では、各AWSアカウントへのログインがポータル画面のリンクから行くことができるので、 AWSアカウントごとにログインの作業が必要なくなったのも楽ですし、各AWSアカウント毎にログイン情報、MFA情報を保持しなくても良くなったのも管理が気楽になりました 。 対応して困ったこと 12時間の壁 SSOユーザのセッション時間の上限が12時間のため、朝9時にログインすると夜9時にセッションが切れてしまいます。そのことを忘れて12時間後に急に開発環境でエラーが出始めて「なんじゃこりゃあああ！」とたまに驚かされます（12時間以上働くことがほとんどないのでめったに遭遇しませんが、だからこそ忘れます）。 深夜メンテの際にそれが起きるとトラブルになりますので、その際は作業前に必ずログインし直すようにしています。 個人的にはセッション時間の上限の時間もう少し上げて欲しいです。 利用できないサードパーティーツールの存在 AWSにアクセスするためのサードパーティーツールは様々ありますが、 AWS_ACCESS_KEY_ID 、 AWS_SECRET_ACCESS_KEY の2項目しか設定できないものがあります。 SSOユーザでログインするには、それらに加え AWS_SESSION_TOKEN の値が必要であるため、設定できないツールはSSOユーザでは利用できないことになります。 最近ではSSOユーザでも利用できるようにアップグレードされているツールも増えてきていますので、今まで使っていたツールが使えなくなった場合は代替のツールを使いましょう。 まとめ これは絶対嘘ではなくて、IAM Identity Centerを導入することで、トイルの削減も、情報漏洩リスクの削減も、両方実現することができました。 もちろん私たちの挑戦はこれで終わりではなく、サービスの品質を上げるため、開発メンバーが開発に集中できる環境を作るため、 俺たちの戦いはまだ始まったばかり 、です。 そして、明日12月4日は @shigerisa さんが何やらもっと面白い記事を書いてくれているようです！お楽しみに！ We’re hiring! メドレーでは各種エンジニアを絶賛募集中です！ カジュアル面談いつでもWelcomeですので、お話しだけでも聞いてみたい、むしろ私の推しの話を聞いて欲しい、などなんでもかまいませんので、お気軽にお問い合わせください！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こちらの記事は Medley（メドレー） Advent Calendar 2024 の3日目の記事です。 Who are you? メドレーで主にSRE活動を行っている人材プラットフォーム本部 第四開発グループの玉井です。 最初に簡単にFAQ形式で自己紹介させていただこうと思います。 （昨日は何を食べましたか） ： 麺系ファストフードでは一番好きな小諸そば。 （好きな本は何ですか） ： 柳井正さんの自伝書『一勝九敗』は心に残っています。 （遊びに行くならどこに行きますか） ： アウトドアが好きなのでキャンプなど。 今回は利用しているAWS環境に IAM Identity Center を導入した話をさせていただこうと思います。 セキュリティと管理コストの天秤 メドレーではクレデンシャルな情報は厳重に管理され、平文で外部ツールに保存されることはありません。AWSのIAMユーザのアクセスキーに関しても同じです。 ただ、それでも心配になるのは PCの中に平文で残る情報 。PCも厳重に管理されているのでそうそう漏洩するものではありませんが、それでも可能性はゼロではありません。 一時はAssumeRoleを使うことで漏洩時のリスクを減らしました。 最初の認証では何もできない弱い権限で、AssumeRoleで権限の強いロールに変身する方式を導入しました。 この話を聞いて、腕に包帯を巻いた学生服の少年が天狗のお面を被るいらすとが浮かんだあなたはAWSデベロッパーお馴染みのあのブログの敬虔な読者です。 AssumeRole概要図 それでもまだ課題はありました。 IAMユーザとAssumeRoleの管理コスト です。 AWSアカウントはサービスごとに複数存在し、さらに本番環境、ステージング環境でも分けてあります。それぞれのAWSアカウントにアクセスできる環境を開発メンバーに提供する必要があります。 AssumeRoleは変身する元と変身した先の設定をする必要があり、AWSアカウントを跨ぐ場合はそれぞれのAWSアカウントに設定が必要になります。開発メンバーの異動がある度にあちらこちらのAWSアカウントにその設定をすることが、面倒なトイルになっていました。 セキュアな環境を維持したまま、管理コストもなるべく下げたい。 そこで導入を決めたのが IAM Identity Center でした。 IAM Identity Centerの導入検討 結論を先に申し上げますと、IAM Identity Centerを導入することで セキュアな環境を維持しながらトイルの削減も実現することができました 。 完璧で究極というほどではありませんが、誰もが目を奪われていく理想の環境に一歩近づくことがました。 IAM Identity Centerをさらに管理するAWS Control Towerの導入も検討しましたが、既にある環境に導入することの予期せぬ制限がかかることのリスクや、AWS Configが多用されることで思わぬコスト増が発生するとの情報もあり、今回は見送ることにしました。 IAM Identity Centerとは 元は AWS Single Sign-On （AWS SSO） というサービス名でした。 これはIAMユーザとは全く別物のユーザ（これをSSOユーザとします）を作成し、SSOユーザが各AWSアカウントの各IAMロールを持ったユーザに変身することができる機能です。 IAM Identity Center概要図 IAM Identity Centerを導入した決め手 SSOユーザと権限の管理は一つのAWSアカウントのIAM Identity Centerで管理することができます。 これはAWS Organizationsの機能の上に乗る機能ですが、幸い元々それを導入していたことで、すぐに組み込むことができました（ちなみに現在はIdPを設定することでAWS Organizationsがなくてもこの機能を使うことができます）。 つまり、 複数のAWSアカウントの複数のユーザの複数のロールを一つのIAM Identity Centerで全て管理することができるのです 。 では、各AWSアカウントで既に作成してしまったIAMポリシーを、IAM Identity Centerで同じ内容で作り直さないといけないかというとそんなこともなく、カスタムロールという設定で、IAMポリシー名だけ定義することで既存のIAMポリシーをそのまま活かすことができます。 そして、SSOユーザは恒久的なアクセスキーを持つことができず、最大で12時間の期限付きアクセスキーしか持つことができません。従って、 仮に万が一アクセスキーが漏洩しても12時間後には使えなくなります 。 まさに最強で無敵のIAM Identity Centerです。 IAM Identity Centerの導入 ここではIAM Identity Centerの導入の流れを簡単に説明いたします。 一番最初はIAM Identity Centerを有効にすることですが、それは割愛して有効化した後の手順を記載していきます。 IAM Identity Center全体図 SSOユーザの作成 SSOユーザは前述した通りIAMユーザとは全く別物なので、新たに全員分作成する必要があります。 最低限必要なのは名前とメールアドレスのみです。 作成画面に任意項目で住所や電話番号などあったりするのですが、システム的には全く関係ないようです。IAM Identity CenterをIdPとして使うときのための設定でしょうか。 SSOユーザ作成画面 SSOグループの作成 SSOグループとは、SSOユーザと後述する許可セットをまとめるためのものです。 新しいSSOユーザが増えた場合は、該当のグループに追加してあげるだけでOKです。 SSOグループ作成画面 許可セットの作成 許可セットは、IAMロールの素になるものです。 ここで設定したポリシーが各AWSアカウントにIAMロール、IAMポリシーとしてプロビジョニングされます。 プロビジョニング先のAWSアカウントに既にあるIAMポリシーを使いたい場合は、カスタマーマネージドポリシーでその名前を設定すれば割り当てることができます。 名前が間違っていて存在しないIAMポリシーを設定してしまった場合は、プロビジョニング時にエラーになります。 許可セット作成画面 プロビジョニング “SSOユーザまたはグループ” と “許可セット” を適用したいAWSアカウントにプロビジョニングすることで、対象SSOユーザで該当AWSアカウントにログイン可能になります。 プロビジョニング概要図 SSOアクセスポータル画面 SSOユーザでログインするAWSアクセスポータル画面に、AWSアカウントへのリンクの一覧が表示されます。 このリンクから各AWSアカウントに、任意のロールでログインすることができます。便利ですね！ AWSアクセスポータル画面 一時的なアクセスキーはCLIでも取得できますが、この画面からも アクセスキー のリンクをクリックすると一覧画面が表示されます。 AWSアクセスポータル アクセスキー確認画面 導入後に対応したこと これまでの手順でマネジメントコンソールのでログインはできるようになっていますが、それ以外のツール等で利用するためにしたことをここでは説明します。 ~/.aws/configの修正 ターミナルでAWS CLIを利用するために、これまでアクセスキーを直接指定していたのを、SSOユーザ対応の記述に変更する必要があります。 アクセスキーなどのクレデンシャルな情報の記載が不要になり、この内容が漏洩してもダメージが少ないです。 [default] sso_session = m y-sso sso_account_id = 999999999999 sso_role_name = x xxxxxxxxxxx [sso-session my-sso] sso_start_url = h ttps://xxxxxxxxxxxx.awsapps.com/start sso_registration_scopes = s so:account:access sso_sessionの設定が古いaws_sdkだと対応していなかったりしたので、最新のaws_sdkを使うように mise (開発ツール管理用ツール)に設定しました。 [tools] awscli = "latest" この設定をした状態で aws sso login を実行すると認証画面のブラウザが自動で立ち上がり、ブラウザでの認証完了後にターミナルでCLIが使えるようになります。 ターミナルでsso login ブラウザで認証 開発環境へのアクセスキーの渡し方 開発環境においてアクセスキーの設定が必要な箇所があり、それを毎日ポータル画面からコピペで更新してくださいというのは面倒すぎるので、毎日1回最初にシェルを実行してもらうようにしました（これも面倒なのでこれなしでどうにかできれば良かったのですが・・・無念）。 この実行にはSSOの認証情報をシェル内の処理で利用するため aws2-wrap を利用し、.envファイルの更新には python-dotenv を利用しました。 これもmiseで定義することで、全開発メンバーにもれなく対応できました。 # 一部抜粋 if ! $(aws2-wrap --profile " $profile " --export ); then aws sso login --profile= " $profile " eval "$( aws2-wrap --profile " $profile " --export )" fi # 一部抜粋 from dotenv import set_key def update_env_file ( env_file , key_value_pairs ): try : for key in key_value_pairs: value = key_value_pairs[key] set_key(env_file, key, value, quote_mode = 'never' ) except Exception as e: print (e) Terraform, Packerの対応 最新のTerraform、Packerではaws ssoに対応しているので、ssoのprofileをそのまま使うことができます（AssumeRoleには対応していなかったので、それを対応させた時は大変でした・・・）。 Terraformは環境依存をなくすため実行環境をコンテナ化しコンテナ内で実行しているのですが、“ログイン時にSSOセッションの存在有無の確認” → “なければSSOログイン” をさせることで、 aws sso login の事前実行を意識しなくても良いようにしました。 # 一部抜粋 function get_caller_identity () { set +eu for i in { 1..3} ; do command "aws sts get-caller-identity --profile $1 " if [[ $? = 0 ]]; then break else echo "Not logged in" command "aws sso login --profile $1 " fi done set -eu } 最新のPackerはaws ssoに対応していると前述しましたが、なぜだか環境により sso-session が効かずにエラーになる場合がありました。その場合はレガシーな記述方法で回避できます。 [profile packer] credential_process = a ws --profile default configure export-credentials --format process region = a p-northeast-1 output = j son 対応して良かったこと 管理者目線で良かったこと 管理者目線では、AWSのユーザ管理が大分楽になりました。 これまで開発メンバーが増えた際には、複数のAWSアカウントに対しそれぞれに、IAMユーザの作成、アクセスキーの生成をし、その後初期ログインパスワードとアクセスキーをメンバーに配布しなければならなかったため、作業が大分煩雑でした。 IAM Identity Center導入後は、 1つのAWSアカウントでSSOユーザを作成するだけです 。招待メールも勝手に送られます。 また、与えている権限の管理も楽になりました。 IAM Identity Centerの画面を見れば、誰がどのAWSアカウントにどんな権限を持っているか全てわかりますし、設定するのもそこだけなので 、いろんなAWSアカウントを出入りして確認・設定する必要がなくなりました。 利用者目線で良かったこと 利用者目線では、各AWSアカウントへのログインがポータル画面のリンクから行くことができるので、 AWSアカウントごとにログインの作業が必要なくなったのも楽ですし、各AWSアカウント毎にログイン情報、MFA情報を保持しなくても良くなったのも管理が気楽になりました 。 対応して困ったこと 12時間の壁 SSOユーザのセッション時間の上限が12時間のため、朝9時にログインすると夜9時にセッションが切れてしまいます。そのことを忘れて12時間後に急に開発環境でエラーが出始めて「なんじゃこりゃあああ！」とたまに驚かされます（12時間以上働くことがほとんどないのでめったに遭遇しませんが、だからこそ忘れます）。 深夜メンテの際にそれが起きるとトラブルになりますので、その際は作業前に必ずログインし直すようにしています。 個人的にはセッション時間の上限の時間もう少し上げて欲しいです。 利用できないサードパーティーツールの存在 AWSにアクセスするためのサードパーティーツールは様々ありますが、 AWS_ACCESS_KEY_ID 、 AWS_SECRET_ACCESS_KEY の2項目しか設定できないものがあります。 SSOユーザでログインするには、それらに加え AWS_SESSION_TOKEN の値が必要であるため、設定できないツールはSSOユーザでは利用できないことになります。 最近ではSSOユーザでも利用できるようにアップグレードされているツールも増えてきていますので、今まで使っていたツールが使えなくなった場合は代替のツールを使いましょう。 まとめ これは絶対嘘ではなくて、IAM Identity Centerを導入することで、トイルの削減も、情報漏洩リスクの削減も、両方実現することができました。 もちろん私たちの挑戦はこれで終わりではなく、サービスの品質を上げるため、開発メンバーが開発に集中できる環境を作るため、 俺たちの戦いはまだ始まったばかり 、です。 そして、明日12月4日は @shigerisa さんが何やらもっと面白い記事を書いてくれているようです！お楽しみに！ We’re hiring! メドレーでは各種エンジニアを絶賛募集中です！ カジュアル面談いつでもWelcomeですので、お話しだけでも聞いてみたい、むしろ私の推しの話を聞いて欲しい、などなんでもかまいませんので、お気軽にお問い合わせください！ https://www.medley.jp/jobs/

こちらの記事は Medley（メドレー） Advent Calendar 2024 の3日目の記事です。 Who are you? メドレーで主にSRE活動を行っている人材プラットフォーム本部 第四開発グループの玉井です。 最初に簡単にFAQ形式で自己紹介させていただこうと思います。 （昨日は何を食べましたか） ： 麺系ファストフードでは一番好きな小諸そば。 （好きな本は何ですか） ： 柳井正さんの自伝書『一勝九敗』は心に残っています。 （遊びに行くならどこに行きますか） ： アウトドアが好きなのでキャンプなど。 今回は利用しているAWS環境に IAM Identity Center を導入した話をさせていただこうと思います。 セキュリティと管理コストの天秤 メドレーではクレデンシャルな情報は厳重に管理され、平文で外部ツールに保存されることはありません。AWSのIAMユーザのアクセスキーに関しても同じです。 ただ、それでも心配になるのは PCの中に平文で残る情報 。PCも厳重に管理されているのでそうそう漏洩するものではありませんが、それでも可能性はゼロではありません。 一時はAssumeRoleを使うことで漏洩時のリスクを減らしました。 最初の認証では何もできない弱い権限で、AssumeRoleで権限の強いロールに変身する方式を導入しました。 この話を聞いて、腕に包帯を巻いた学生服の少年が天狗のお面を被るいらすとが浮かんだあなたはAWSデベロッパーお馴染みのあのブログの敬虔な読者です。 AssumeRole概要図 それでもまだ課題はありました。 IAMユーザとAssumeRoleの管理コスト です。 AWSアカウントはサービスごとに複数存在し、さらに本番環境、ステージング環境でも分けてあります。それぞれのAWSアカウントにアクセスできる環境を開発メンバーに提供する必要があります。 AssumeRoleは変身する元と変身した先の設定をする必要があり、AWSアカウントを跨ぐ場合はそれぞれのAWSアカウントに設定が必要になります。開発メンバーの異動がある度にあちらこちらのAWSアカウントにその設定をすることが、面倒なトイルになっていました。 セキュアな環境を維持したまま、管理コストもなるべく下げたい。 そこで導入を決めたのが IAM Identity Center でした。 IAM Identity Centerの導入検討 結論を先に申し上げますと、IAM Identity Centerを導入することで セキュアな環境を維持しながらトイルの削減も実現することができました 。 完璧で究極というほどではありませんが、誰もが目を奪われていく理想の環境に一歩近づくことがました。 IAM Identity Centerをさらに管理するAWS Control Towerの導入も検討しましたが、既にある環境に導入することの予期せぬ制限がかかることのリスクや、AWS Configが多用されることで思わぬコスト増が発生するとの情報もあり、今回は見送ることにしました。 IAM Identity Centerとは 元は AWS Single Sign-On （AWS SSO） というサービス名でした。 これはIAMユーザとは全く別物のユーザ（これをSSOユーザとします）を作成し、SSOユーザが各AWSアカウントの各IAMロールを持ったユーザに変身することができる機能です。 IAM Identity Center概要図 IAM Identity Centerを導入した決め手 SSOユーザと権限の管理は一つのAWSアカウントのIAM Identity Centerで管理することができます。 これはAWS Organizationsの機能の上に乗る機能ですが、幸い元々それを導入していたことで、すぐに組み込むことができました（ちなみに現在はIdPを設定することでAWS Organizationsがなくてもこの機能を使うことができます）。 つまり、 複数のAWSアカウントの複数のユーザの複数のロールを一つのIAM Identity Centerで全て管理することができるのです 。 では、各AWSアカウントで既に作成してしまったIAMポリシーを、IAM Identity Centerで同じ内容で作り直さないといけないかというとそんなこともなく、カスタムロールという設定で、IAMポリシー名だけ定義することで既存のIAMポリシーをそのまま活かすことができます。 そして、SSOユーザは恒久的なアクセスキーを持つことができず、最大で12時間の期限付きアクセスキーしか持つことができません。従って、 仮に万が一アクセスキーが漏洩しても12時間後には使えなくなります 。 まさに最強で無敵のIAM Identity Centerです。 IAM Identity Centerの導入 ここではIAM Identity Centerの導入の流れを簡単に説明いたします。 一番最初はIAM Identity Centerを有効にすることですが、それは割愛して有効化した後の手順を記載していきます。 IAM Identity Center全体図 SSOユーザの作成 SSOユーザは前述した通りIAMユーザとは全く別物なので、新たに全員分作成する必要があります。 最低限必要なのは名前とメールアドレスのみです。 作成画面に任意項目で住所や電話番号などあったりするのですが、システム的には全く関係ないようです。IAM Identity CenterをIdPとして使うときのための設定でしょうか。 SSOユーザ作成画面 SSOグループの作成 SSOグループとは、SSOユーザと後述する許可セットをまとめるためのものです。 新しいSSOユーザが増えた場合は、該当のグループに追加してあげるだけでOKです。 SSOグループ作成画面 許可セットの作成 許可セットは、IAMロールの素になるものです。 ここで設定したポリシーが各AWSアカウントにIAMロール、IAMポリシーとしてプロビジョニングされます。 プロビジョニング先のAWSアカウントに既にあるIAMポリシーを使いたい場合は、カスタマーマネージドポリシーでその名前を設定すれば割り当てることができます。 名前が間違っていて存在しないIAMポリシーを設定してしまった場合は、プロビジョニング時にエラーになります。 許可セット作成画面 プロビジョニング “SSOユーザまたはグループ” と “許可セット” を適用したいAWSアカウントにプロビジョニングすることで、対象SSOユーザで該当AWSアカウントにログイン可能になります。 プロビジョニング概要図 SSOアクセスポータル画面 SSOユーザでログインするAWSアクセスポータル画面に、AWSアカウントへのリンクの一覧が表示されます。 このリンクから各AWSアカウントに、任意のロールでログインすることができます。便利ですね！ AWSアクセスポータル画面 一時的なアクセスキーはCLIでも取得できますが、この画面からも アクセスキー のリンクをクリックすると一覧画面が表示されます。 AWSアクセスポータル アクセスキー確認画面 導入後に対応したこと これまでの手順でマネジメントコンソールのでログインはできるようになっていますが、それ以外のツール等で利用するためにしたことをここでは説明します。 ~/.aws/configの修正 ターミナルでAWS CLIを利用するために、これまでアクセスキーを直接指定していたのを、SSOユーザ対応の記述に変更する必要があります。 アクセスキーなどのクレデンシャルな情報の記載が不要になり、この内容が漏洩してもダメージが少ないです。 [default] sso_session = m y-sso sso_account_id = 999999999999 sso_role_name = x xxxxxxxxxxx [sso-session my-sso] sso_start_url = h ttps://xxxxxxxxxxxx.awsapps.com/start sso_registration_scopes = s so:account:access sso_sessionの設定が古いaws_sdkだと対応していなかったりしたので、最新のaws_sdkを使うように mise (開発ツール管理用ツール)に設定しました。 [tools] awscli = "latest" この設定をした状態で aws sso login を実行すると認証画面のブラウザが自動で立ち上がり、ブラウザでの認証完了後にターミナルでCLIが使えるようになります。 ターミナルでsso login ブラウザで認証 開発環境へのアクセスキーの渡し方 開発環境においてアクセスキーの設定が必要な箇所があり、それを毎日ポータル画面からコピペで更新してくださいというのは面倒すぎるので、毎日1回最初にシェルを実行してもらうようにしました（これも面倒なのでこれなしでどうにかできれば良かったのですが・・・無念）。 この実行にはSSOの認証情報をシェル内の処理で利用するため aws2-wrap を利用し、.envファイルの更新には python-dotenv を利用しました。 これもmiseで定義することで、全開発メンバーにもれなく対応できました。 # 一部抜粋 if ! $(aws2-wrap --profile " $profile " --export ); then aws sso login --profile= " $profile " eval "$( aws2-wrap --profile " $profile " --export )" fi # 一部抜粋 from dotenv import set_key def update_env_file ( env_file , key_value_pairs ): try : for key in key_value_pairs: value = key_value_pairs[key] set_key(env_file, key, value, quote_mode = 'never' ) except Exception as e: print (e) Terraform, Packerの対応 最新のTerraform、Packerではaws ssoに対応しているので、ssoのprofileをそのまま使うことができます（AssumeRoleには対応していなかったので、それを対応させた時は大変でした・・・）。 Terraformは環境依存をなくすため実行環境をコンテナ化しコンテナ内で実行しているのですが、“ログイン時にSSOセッションの存在有無の確認” → “なければSSOログイン” をさせることで、 aws sso login の事前実行を意識しなくても良いようにしました。 # 一部抜粋 function get_caller_identity () { set +eu for i in { 1..3} ; do command "aws sts get-caller-identity --profile $1 " if [[ $? = 0 ]]; then break else echo "Not logged in" command "aws sso login --profile $1 " fi done set -eu } 最新のPackerはaws ssoに対応していると前述しましたが、なぜだか環境により sso-session が効かずにエラーになる場合がありました。その場合はレガシーな記述方法で回避できます。 [profile packer] credential_process = a ws --profile default configure export-credentials --format process region = a p-northeast-1 output = j son 対応して良かったこと 管理者目線で良かったこと 管理者目線では、AWSのユーザ管理が大分楽になりました。 これまで開発メンバーが増えた際には、複数のAWSアカウントに対しそれぞれに、IAMユーザの作成、アクセスキーの生成をし、その後初期ログインパスワードとアクセスキーをメンバーに配布しなければならなかったため、作業が大分煩雑でした。 IAM Identity Center導入後は、 1つのAWSアカウントでSSOユーザを作成するだけです 。招待メールも勝手に送られます。 また、与えている権限の管理も楽になりました。 IAM Identity Centerの画面を見れば、誰がどのAWSアカウントにどんな権限を持っているか全てわかりますし、設定するのもそこだけなので 、いろんなAWSアカウントを出入りして確認・設定する必要がなくなりました。 利用者目線で良かったこと 利用者目線では、各AWSアカウントへのログインがポータル画面のリンクから行くことができるので、 AWSアカウントごとにログインの作業が必要なくなったのも楽ですし、各AWSアカウント毎にログイン情報、MFA情報を保持しなくても良くなったのも管理が気楽になりました 。 対応して困ったこと 12時間の壁 SSOユーザのセッション時間の上限が12時間のため、朝9時にログインすると夜9時にセッションが切れてしまいます。そのことを忘れて12時間後に急に開発環境でエラーが出始めて「なんじゃこりゃあああ！」とたまに驚かされます（12時間以上働くことがほとんどないのでめったに遭遇しませんが、だからこそ忘れます）。 深夜メンテの際にそれが起きるとトラブルになりますので、その際は作業前に必ずログインし直すようにしています。 個人的にはセッション時間の上限の時間もう少し上げて欲しいです。 利用できないサードパーティーツールの存在 AWSにアクセスするためのサードパーティーツールは様々ありますが、 AWS_ACCESS_KEY_ID 、 AWS_SECRET_ACCESS_KEY の2項目しか設定できないものがあります。 SSOユーザでログインするには、それらに加え AWS_SESSION_TOKEN の値が必要であるため、設定できないツールはSSOユーザでは利用できないことになります。 最近ではSSOユーザでも利用できるようにアップグレードされているツールも増えてきていますので、今まで使っていたツールが使えなくなった場合は代替のツールを使いましょう。 まとめ これは絶対嘘ではなくて、IAM Identity Centerを導入することで、トイルの削減も、情報漏洩リスクの削減も、両方実現することができました。 もちろん私たちの挑戦はこれで終わりではなく、サービスの品質を上げるため、開発メンバーが開発に集中できる環境を作るため、 俺たちの戦いはまだ始まったばかり 、です。 そして、明日12月4日は @shigerisa さんが何やらもっと面白い記事を書いてくれているようです！お楽しみに！ We’re hiring! メドレーでは各種エンジニアを絶賛募集中です！ カジュアル面談いつでもWelcomeですので、お話しだけでも聞いてみたい、むしろ私の推しの話を聞いて欲しい、などなんでもかまいませんので、お気軽にお問い合わせください！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こちらの記事は Medley（メドレー） Advent Calendar 2024 の3日目の記事です。 Who are you? メドレーで主にSRE活動を行っている人材プラットフォーム本部 第四開発グループの玉井です。 最初に簡単にFAQ形式で自己紹介させていただこうと思います。 （昨日は何を食べましたか） ： 麺系ファストフードでは一番好きな小諸そば。 （好きな本は何ですか） ： 柳井正さんの自伝書『一勝九敗』は心に残っています。 （遊びに行くならどこに行きますか） ： アウトドアが好きなのでキャンプなど。 今回は利用しているAWS環境に IAM Identity Center を導入した話をさせていただこうと思います。 セキュリティと管理コストの天秤 メドレーではクレデンシャルな情報は厳重に管理され、平文で外部ツールに保存されることはありません。AWSのIAMユーザのアクセスキーに関しても同じです。 ただ、それでも心配になるのは PCの中に平文で残る情報 。PCも厳重に管理されているのでそうそう漏洩するものではありませんが、それでも可能性はゼロではありません。 一時はAssumeRoleを使うことで漏洩時のリスクを減らしました。 最初の認証では何もできない弱い権限で、AssumeRoleで権限の強いロールに変身する方式を導入しました。 この話を聞いて、腕に包帯を巻いた学生服の少年が天狗のお面を被るいらすとが浮かんだあなたはAWSデベロッパーお馴染みのあのブログの敬虔な読者です。 AssumeRole概要図 それでもまだ課題はありました。 IAMユーザとAssumeRoleの管理コスト です。 AWSアカウントはサービスごとに複数存在し、さらに本番環境、ステージング環境でも分けてあります。それぞれのAWSアカウントにアクセスできる環境を開発メンバーに提供する必要があります。 AssumeRoleは変身する元と変身した先の設定をする必要があり、AWSアカウントを跨ぐ場合はそれぞれのAWSアカウントに設定が必要になります。開発メンバーの異動がある度にあちらこちらのAWSアカウントにその設定をすることが、面倒なトイルになっていました。 セキュアな環境を維持したまま、管理コストもなるべく下げたい。 そこで導入を決めたのが IAM Identity Center でした。 IAM Identity Centerの導入検討 結論を先に申し上げますと、IAM Identity Centerを導入することで セキュアな環境を維持しながらトイルの削減も実現することができました 。 完璧で究極というほどではありませんが、誰もが目を奪われていく理想の環境に一歩近づくことがました。 IAM Identity Centerをさらに管理するAWS Control Towerの導入も検討しましたが、既にある環境に導入することの予期せぬ制限がかかることのリスクや、AWS Configが多用されることで思わぬコスト増が発生するとの情報もあり、今回は見送ることにしました。 IAM Identity Centerとは 元は AWS Single Sign-On （AWS SSO） というサービス名でした。 これはIAMユーザとは全く別物のユーザ（これをSSOユーザとします）を作成し、SSOユーザが各AWSアカウントの各IAMロールを持ったユーザに変身することができる機能です。 IAM Identity Center概要図 IAM Identity Centerを導入した決め手 SSOユーザと権限の管理は一つのAWSアカウントのIAM Identity Centerで管理することができます。 これはAWS Organizationsの機能の上に乗る機能ですが、幸い元々それを導入していたことで、すぐに組み込むことができました（ちなみに現在はIdPを設定することでAWS Organizationsがなくてもこの機能を使うことができます）。 つまり、 複数のAWSアカウントの複数のユーザの複数のロールを一つのIAM Identity Centerで全て管理することができるのです 。 では、各AWSアカウントで既に作成してしまったIAMポリシーを、IAM Identity Centerで同じ内容で作り直さないといけないかというとそんなこともなく、カスタムロールという設定で、IAMポリシー名だけ定義することで既存のIAMポリシーをそのまま活かすことができます。 そして、SSOユーザは恒久的なアクセスキーを持つことができず、最大で12時間の期限付きアクセスキーしか持つことができません。従って、 仮に万が一アクセスキーが漏洩しても12時間後には使えなくなります 。 まさに最強で無敵のIAM Identity Centerです。 IAM Identity Centerの導入 ここではIAM Identity Centerの導入の流れを簡単に説明いたします。 一番最初はIAM Identity Centerを有効にすることですが、それは割愛して有効化した後の手順を記載していきます。 IAM Identity Center全体図 SSOユーザの作成 SSOユーザは前述した通りIAMユーザとは全く別物なので、新たに全員分作成する必要があります。 最低限必要なのは名前とメールアドレスのみです。 作成画面に任意項目で住所や電話番号などあったりするのですが、システム的には全く関係ないようです。IAM Identity CenterをIdPとして使うときのための設定でしょうか。 SSOユーザ作成画面 SSOグループの作成 SSOグループとは、SSOユーザと後述する許可セットをまとめるためのものです。 新しいSSOユーザが増えた場合は、該当のグループに追加してあげるだけでOKです。 SSOグループ作成画面 許可セットの作成 許可セットは、IAMロールの素になるものです。 ここで設定したポリシーが各AWSアカウントにIAMロール、IAMポリシーとしてプロビジョニングされます。 プロビジョニング先のAWSアカウントに既にあるIAMポリシーを使いたい場合は、カスタマーマネージドポリシーでその名前を設定すれば割り当てることができます。 名前が間違っていて存在しないIAMポリシーを設定してしまった場合は、プロビジョニング時にエラーになります。 許可セット作成画面 プロビジョニング “SSOユーザまたはグループ” と “許可セット” を適用したいAWSアカウントにプロビジョニングすることで、対象SSOユーザで該当AWSアカウントにログイン可能になります。 プロビジョニング概要図 SSOアクセスポータル画面 SSOユーザでログインするAWSアクセスポータル画面に、AWSアカウントへのリンクの一覧が表示されます。 このリンクから各AWSアカウントに、任意のロールでログインすることができます。便利ですね！ AWSアクセスポータル画面 一時的なアクセスキーはCLIでも取得できますが、この画面からも アクセスキー のリンクをクリックすると一覧画面が表示されます。 AWSアクセスポータル アクセスキー確認画面 導入後に対応したこと これまでの手順でマネジメントコンソールのでログインはできるようになっていますが、それ以外のツール等で利用するためにしたことをここでは説明します。 ~/.aws/configの修正 ターミナルでAWS CLIを利用するために、これまでアクセスキーを直接指定していたのを、SSOユーザ対応の記述に変更する必要があります。 アクセスキーなどのクレデンシャルな情報の記載が不要になり、この内容が漏洩してもダメージが少ないです。 [default] sso_session = m y-sso sso_account_id = 999999999999 sso_role_name = x xxxxxxxxxxx [sso-session my-sso] sso_start_url = h ttps://xxxxxxxxxxxx.awsapps.com/start sso_registration_scopes = s so:account:access sso_sessionの設定が古いaws_sdkだと対応していなかったりしたので、最新のaws_sdkを使うように mise (開発ツール管理用ツール)に設定しました。 [tools] awscli = "latest" この設定をした状態で aws sso login を実行すると認証画面のブラウザが自動で立ち上がり、ブラウザでの認証完了後にターミナルでCLIが使えるようになります。 ターミナルでsso login ブラウザで認証 開発環境へのアクセスキーの渡し方 開発環境においてアクセスキーの設定が必要な箇所があり、それを毎日ポータル画面からコピペで更新してくださいというのは面倒すぎるので、毎日1回最初にシェルを実行してもらうようにしました（これも面倒なのでこれなしでどうにかできれば良かったのですが・・・無念）。 この実行にはSSOの認証情報をシェル内の処理で利用するため aws2-wrap を利用し、.envファイルの更新には python-dotenv を利用しました。 これもmiseで定義することで、全開発メンバーにもれなく対応できました。 # 一部抜粋 if ! $(aws2-wrap --profile " $profile " --export ); then aws sso login --profile= " $profile " eval "$( aws2-wrap --profile " $profile " --export )" fi # 一部抜粋 from dotenv import set_key def update_env_file ( env_file , key_value_pairs ): try : for key in key_value_pairs: value = key_value_pairs[key] set_key(env_file, key, value, quote_mode = 'never' ) except Exception as e: print (e) Terraform, Packerの対応 最新のTerraform、Packerではaws ssoに対応しているので、ssoのprofileをそのまま使うことができます（AssumeRoleには対応していなかったので、それを対応させた時は大変でした・・・）。 Terraformは環境依存をなくすため実行環境をコンテナ化しコンテナ内で実行しているのですが、“ログイン時にSSOセッションの存在有無の確認” → “なければSSOログイン” をさせることで、 aws sso login の事前実行を意識しなくても良いようにしました。 # 一部抜粋 function get_caller_identity () { set +eu for i in { 1..3} ; do command "aws sts get-caller-identity --profile $1 " if [[ $? = 0 ]]; then break else echo "Not logged in" command "aws sso login --profile $1 " fi done set -eu } 最新のPackerはaws ssoに対応していると前述しましたが、なぜだか環境により sso-session が効かずにエラーになる場合がありました。その場合はレガシーな記述方法で回避できます。 [profile packer] credential_process = a ws --profile default configure export-credentials --format process region = a p-northeast-1 output = j son 対応して良かったこと 管理者目線で良かったこと 管理者目線では、AWSのユーザ管理が大分楽になりました。 これまで開発メンバーが増えた際には、複数のAWSアカウントに対しそれぞれに、IAMユーザの作成、アクセスキーの生成をし、その後初期ログインパスワードとアクセスキーをメンバーに配布しなければならなかったため、作業が大分煩雑でした。 IAM Identity Center導入後は、 1つのAWSアカウントでSSOユーザを作成するだけです 。招待メールも勝手に送られます。 また、与えている権限の管理も楽になりました。 IAM Identity Centerの画面を見れば、誰がどのAWSアカウントにどんな権限を持っているか全てわかりますし、設定するのもそこだけなので 、いろんなAWSアカウントを出入りして確認・設定する必要がなくなりました。 利用者目線で良かったこと 利用者目線では、各AWSアカウントへのログインがポータル画面のリンクから行くことができるので、 AWSアカウントごとにログインの作業が必要なくなったのも楽ですし、各AWSアカウント毎にログイン情報、MFA情報を保持しなくても良くなったのも管理が気楽になりました 。 対応して困ったこと 12時間の壁 SSOユーザのセッション時間の上限が12時間のため、朝9時にログインすると夜9時にセッションが切れてしまいます。そのことを忘れて12時間後に急に開発環境でエラーが出始めて「なんじゃこりゃあああ！」とたまに驚かされます（12時間以上働くことがほとんどないのでめったに遭遇しませんが、だからこそ忘れます）。 深夜メンテの際にそれが起きるとトラブルになりますので、その際は作業前に必ずログインし直すようにしています。 個人的にはセッション時間の上限の時間もう少し上げて欲しいです。 利用できないサードパーティーツールの存在 AWSにアクセスするためのサードパーティーツールは様々ありますが、 AWS_ACCESS_KEY_ID 、 AWS_SECRET_ACCESS_KEY の2項目しか設定できないものがあります。 SSOユーザでログインするには、それらに加え AWS_SESSION_TOKEN の値が必要であるため、設定できないツールはSSOユーザでは利用できないことになります。 最近ではSSOユーザでも利用できるようにアップグレードされているツールも増えてきていますので、今まで使っていたツールが使えなくなった場合は代替のツールを使いましょう。 まとめ これは絶対嘘ではなくて、IAM Identity Centerを導入することで、トイルの削減も、情報漏洩リスクの削減も、両方実現することができました。 もちろん私たちの挑戦はこれで終わりではなく、サービスの品質を上げるため、開発メンバーが開発に集中できる環境を作るため、 俺たちの戦いはまだ始まったばかり 、です。 そして、明日12月4日は @shigerisa さんが何やらもっと面白い記事を書いてくれているようです！お楽しみに！ We’re hiring! メドレーでは各種エンジニアを絶賛募集中です！ カジュアル面談いつでもWelcomeですので、お話しだけでも聞いてみたい、むしろ私の推しの話を聞いて欲しい、などなんでもかまいませんので、お気軽にお問い合わせください！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こちらの記事は Medley（メドレー） Advent Calendar 2024 の3日目の記事です。 Who are you? メドレーで主にSRE活動を行っている人材プラットフォーム本部 第四開発グループの玉井です。 最初に簡単にFAQ形式で自己紹介させていただこうと思います。 （昨日は何を食べましたか） ： 麺系ファストフードでは一番好きな小諸そば。 （好きな本は何ですか） ： 柳井正さんの自伝書『一勝九敗』は心に残っています。 （遊びに行くならどこに行きますか） ： アウトドアが好きなのでキャンプなど。 今回は利用しているAWS環境に IAM Identity Center を導入した話をさせていただこうと思います。 セキュリティと管理コストの天秤 メドレーではクレデンシャルな情報は厳重に管理され、平文で外部ツールに保存されることはありません。AWSのIAMユーザのアクセスキーに関しても同じです。 ただ、それでも心配になるのは PCの中に平文で残る情報 。PCも厳重に管理されているのでそうそう漏洩するものではありませんが、それでも可能性はゼロではありません。 一時はAssumeRoleを使うことで漏洩時のリスクを減らしました。 最初の認証では何もできない弱い権限で、AssumeRoleで権限の強いロールに変身する方式を導入しました。 この話を聞いて、腕に包帯を巻いた学生服の少年が天狗のお面を被るいらすとが浮かんだあなたはAWSデベロッパーお馴染みのあのブログの敬虔な読者です。 AssumeRole概要図 それでもまだ課題はありました。 IAMユーザとAssumeRoleの管理コスト です。 AWSアカウントはサービスごとに複数存在し、さらに本番環境、ステージング環境でも分けてあります。それぞれのAWSアカウントにアクセスできる環境を開発メンバーに提供する必要があります。 AssumeRoleは変身する元と変身した先の設定をする必要があり、AWSアカウントを跨ぐ場合はそれぞれのAWSアカウントに設定が必要になります。開発メンバーの異動がある度にあちらこちらのAWSアカウントにその設定をすることが、面倒なトイルになっていました。 セキュアな環境を維持したまま、管理コストもなるべく下げたい。 そこで導入を決めたのが IAM Identity Center でした。 IAM Identity Centerの導入検討 結論を先に申し上げますと、IAM Identity Centerを導入することで セキュアな環境を維持しながらトイルの削減も実現することができました 。 完璧で究極というほどではありませんが、誰もが目を奪われていく理想の環境に一歩近づくことがました。 IAM Identity Centerをさらに管理するAWS Control Towerの導入も検討しましたが、既にある環境に導入することの予期せぬ制限がかかることのリスクや、AWS Configが多用されることで思わぬコスト増が発生するとの情報もあり、今回は見送ることにしました。 IAM Identity Centerとは 元は AWS Single Sign-On （AWS SSO） というサービス名でした。 これはIAMユーザとは全く別物のユーザ（これをSSOユーザとします）を作成し、SSOユーザが各AWSアカウントの各IAMロールを持ったユーザに変身することができる機能です。 IAM Identity Center概要図 IAM Identity Centerを導入した決め手 SSOユーザと権限の管理は一つのAWSアカウントのIAM Identity Centerで管理することができます。 これはAWS Organizationsの機能の上に乗る機能ですが、幸い元々それを導入していたことで、すぐに組み込むことができました（ちなみに現在はIdPを設定することでAWS Organizationsがなくてもこの機能を使うことができます）。 つまり、 複数のAWSアカウントの複数のユーザの複数のロールを一つのIAM Identity Centerで全て管理することができるのです 。 では、各AWSアカウントで既に作成してしまったIAMポリシーを、IAM Identity Centerで同じ内容で作り直さないといけないかというとそんなこともなく、カスタムロールという設定で、IAMポリシー名だけ定義することで既存のIAMポリシーをそのまま活かすことができます。 そして、SSOユーザは恒久的なアクセスキーを持つことができず、最大で12時間の期限付きアクセスキーしか持つことができません。従って、 仮に万が一アクセスキーが漏洩しても12時間後には使えなくなります 。 まさに最強で無敵のIAM Identity Centerです。 IAM Identity Centerの導入 ここではIAM Identity Centerの導入の流れを簡単に説明いたします。 一番最初はIAM Identity Centerを有効にすることですが、それは割愛して有効化した後の手順を記載していきます。 IAM Identity Center全体図 SSOユーザの作成 SSOユーザは前述した通りIAMユーザとは全く別物なので、新たに全員分作成する必要があります。 最低限必要なのは名前とメールアドレスのみです。 作成画面に任意項目で住所や電話番号などあったりするのですが、システム的には全く関係ないようです。IAM Identity CenterをIdPとして使うときのための設定でしょうか。 SSOユーザ作成画面 SSOグループの作成 SSOグループとは、SSOユーザと後述する許可セットをまとめるためのものです。 新しいSSOユーザが増えた場合は、該当のグループに追加してあげるだけでOKです。 SSOグループ作成画面 許可セットの作成 許可セットは、IAMロールの素になるものです。 ここで設定したポリシーが各AWSアカウントにIAMロール、IAMポリシーとしてプロビジョニングされます。 プロビジョニング先のAWSアカウントに既にあるIAMポリシーを使いたい場合は、カスタマーマネージドポリシーでその名前を設定すれば割り当てることができます。 名前が間違っていて存在しないIAMポリシーを設定してしまった場合は、プロビジョニング時にエラーになります。 許可セット作成画面 プロビジョニング “SSOユーザまたはグループ” と “許可セット” を適用したいAWSアカウントにプロビジョニングすることで、対象SSOユーザで該当AWSアカウントにログイン可能になります。 プロビジョニング概要図 SSOアクセスポータル画面 SSOユーザでログインするAWSアクセスポータル画面に、AWSアカウントへのリンクの一覧が表示されます。 このリンクから各AWSアカウントに、任意のロールでログインすることができます。便利ですね！ AWSアクセスポータル画面 一時的なアクセスキーはCLIでも取得できますが、この画面からも アクセスキー のリンクをクリックすると一覧画面が表示されます。 AWSアクセスポータル アクセスキー確認画面 導入後に対応したこと これまでの手順でマネジメントコンソールのでログインはできるようになっていますが、それ以外のツール等で利用するためにしたことをここでは説明します。 ~/.aws/configの修正 ターミナルでAWS CLIを利用するために、これまでアクセスキーを直接指定していたのを、SSOユーザ対応の記述に変更する必要があります。 アクセスキーなどのクレデンシャルな情報の記載が不要になり、この内容が漏洩してもダメージが少ないです。 [default] sso_session = m y-sso sso_account_id = 999999999999 sso_role_name = x xxxxxxxxxxx [sso-session my-sso] sso_start_url = h ttps://xxxxxxxxxxxx.awsapps.com/start sso_registration_scopes = s so:account:access sso_sessionの設定が古いaws_sdkだと対応していなかったりしたので、最新のaws_sdkを使うように mise (開発ツール管理用ツール)に設定しました。 [tools] awscli = "latest" この設定をした状態で aws sso login を実行すると認証画面のブラウザが自動で立ち上がり、ブラウザでの認証完了後にターミナルでCLIが使えるようになります。 ターミナルでsso login ブラウザで認証 開発環境へのアクセスキーの渡し方 開発環境においてアクセスキーの設定が必要な箇所があり、それを毎日ポータル画面からコピペで更新してくださいというのは面倒すぎるので、毎日1回最初にシェルを実行してもらうようにしました（これも面倒なのでこれなしでどうにかできれば良かったのですが・・・無念）。 この実行にはSSOの認証情報をシェル内の処理で利用するため aws2-wrap を利用し、.envファイルの更新には python-dotenv を利用しました。 これもmiseで定義することで、全開発メンバーにもれなく対応できました。 # 一部抜粋 if ! $(aws2-wrap --profile " $profile " --export ); then aws sso login --profile= " $profile " eval "$( aws2-wrap --profile " $profile " --export )" fi # 一部抜粋 from dotenv import set_key def update_env_file ( env_file , key_value_pairs ): try : for key in key_value_pairs: value = key_value_pairs[key] set_key(env_file, key, value, quote_mode = 'never' ) except Exception as e: print (e) Terraform, Packerの対応 最新のTerraform、Packerではaws ssoに対応しているので、ssoのprofileをそのまま使うことができます（AssumeRoleには対応していなかったので、それを対応させた時は大変でした・・・）。 Terraformは環境依存をなくすため実行環境をコンテナ化しコンテナ内で実行しているのですが、“ログイン時にSSOセッションの存在有無の確認” → “なければSSOログイン” をさせることで、 aws sso login の事前実行を意識しなくても良いようにしました。 # 一部抜粋 function get_caller_identity () { set +eu for i in { 1..3} ; do command "aws sts get-caller-identity --profile $1 " if [[ $? = 0 ]]; then break else echo "Not logged in" command "aws sso login --profile $1 " fi done set -eu } 最新のPackerはaws ssoに対応していると前述しましたが、なぜだか環境により sso-session が効かずにエラーになる場合がありました。その場合はレガシーな記述方法で回避できます。 [profile packer] credential_process = a ws --profile default configure export-credentials --format process region = a p-northeast-1 output = j son 対応して良かったこと 管理者目線で良かったこと 管理者目線では、AWSのユーザ管理が大分楽になりました。 これまで開発メンバーが増えた際には、複数のAWSアカウントに対しそれぞれに、IAMユーザの作成、アクセスキーの生成をし、その後初期ログインパスワードとアクセスキーをメンバーに配布しなければならなかったため、作業が大分煩雑でした。 IAM Identity Center導入後は、 1つのAWSアカウントでSSOユーザを作成するだけです 。招待メールも勝手に送られます。 また、与えている権限の管理も楽になりました。 IAM Identity Centerの画面を見れば、誰がどのAWSアカウントにどんな権限を持っているか全てわかりますし、設定するのもそこだけなので 、いろんなAWSアカウントを出入りして確認・設定する必要がなくなりました。 利用者目線で良かったこと 利用者目線では、各AWSアカウントへのログインがポータル画面のリンクから行くことができるので、 AWSアカウントごとにログインの作業が必要なくなったのも楽ですし、各AWSアカウント毎にログイン情報、MFA情報を保持しなくても良くなったのも管理が気楽になりました 。 対応して困ったこと 12時間の壁 SSOユーザのセッション時間の上限が12時間のため、朝9時にログインすると夜9時にセッションが切れてしまいます。そのことを忘れて12時間後に急に開発環境でエラーが出始めて「なんじゃこりゃあああ！」とたまに驚かされます（12時間以上働くことがほとんどないのでめったに遭遇しませんが、だからこそ忘れます）。 深夜メンテの際にそれが起きるとトラブルになりますので、その際は作業前に必ずログインし直すようにしています。 個人的にはセッション時間の上限の時間もう少し上げて欲しいです。 利用できないサードパーティーツールの存在 AWSにアクセスするためのサードパーティーツールは様々ありますが、 AWS_ACCESS_KEY_ID 、 AWS_SECRET_ACCESS_KEY の2項目しか設定できないものがあります。 SSOユーザでログインするには、それらに加え AWS_SESSION_TOKEN の値が必要であるため、設定できないツールはSSOユーザでは利用できないことになります。 最近ではSSOユーザでも利用できるようにアップグレードされているツールも増えてきていますので、今まで使っていたツールが使えなくなった場合は代替のツールを使いましょう。 まとめ これは絶対嘘ではなくて、IAM Identity Centerを導入することで、トイルの削減も、情報漏洩リスクの削減も、両方実現することができました。 もちろん私たちの挑戦はこれで終わりではなく、サービスの品質を上げるため、開発メンバーが開発に集中できる環境を作るため、 俺たちの戦いはまだ始まったばかり 、です。 そして、明日12月4日は @shigerisa さんが何やらもっと面白い記事を書いてくれているようです！お楽しみに！ We’re hiring! メドレーでは各種エンジニアを絶賛募集中です！ カジュアル面談いつでもWelcomeですので、お話しだけでも聞いてみたい、むしろ私の推しの話を聞いて欲しい、などなんでもかまいませんので、お気軽にお問い合わせください！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こちらの記事は Medley（メドレー） Advent Calendar 2024 の3日目の記事です。 Who are you? メドレーで主にSRE活動を行っている人材プラットフォーム本部 第四開発グループの玉井です。 最初に簡単にFAQ形式で自己紹介させていただこうと思います。 （昨日は何を食べましたか） ： 麺系ファストフードでは一番好きな小諸そば。 （好きな本は何ですか） ： 柳井正さんの自伝書『一勝九敗』は心に残っています。 （遊びに行くならどこに行きますか） ： アウトドアが好きなのでキャンプなど。 今回は利用しているAWS環境に IAM Identity Center を導入した話をさせていただこうと思います。 セキュリティと管理コストの天秤 メドレーではクレデンシャルな情報は厳重に管理され、平文で外部ツールに保存されることはありません。AWSのIAMユーザのアクセスキーに関しても同じです。 ただ、それでも心配になるのは PCの中に平文で残る情報 。PCも厳重に管理されているのでそうそう漏洩するものではありませんが、それでも可能性はゼロではありません。 一時はAssumeRoleを使うことで漏洩時のリスクを減らしました。 最初の認証では何もできない弱い権限で、AssumeRoleで権限の強いロールに変身する方式を導入しました。 この話を聞いて、腕に包帯を巻いた学生服の少年が天狗のお面を被るいらすとが浮かんだあなたはAWSデベロッパーお馴染みのあのブログの敬虔な読者です。 AssumeRole概要図 それでもまだ課題はありました。 IAMユーザとAssumeRoleの管理コスト です。 AWSアカウントはサービスごとに複数存在し、さらに本番環境、ステージング環境でも分けてあります。それぞれのAWSアカウントにアクセスできる環境を開発メンバーに提供する必要があります。 AssumeRoleは変身する元と変身した先の設定をする必要があり、AWSアカウントを跨ぐ場合はそれぞれのAWSアカウントに設定が必要になります。開発メンバーの異動がある度にあちらこちらのAWSアカウントにその設定をすることが、面倒なトイルになっていました。 セキュアな環境を維持したまま、管理コストもなるべく下げたい。 そこで導入を決めたのが IAM Identity Center でした。 IAM Identity Centerの導入検討 結論を先に申し上げますと、IAM Identity Centerを導入することで セキュアな環境を維持しながらトイルの削減も実現することができました 。 完璧で究極というほどではありませんが、誰もが目を奪われていく理想の環境に一歩近づくことがました。 IAM Identity Centerをさらに管理するAWS Control Towerの導入も検討しましたが、既にある環境に導入することの予期せぬ制限がかかることのリスクや、AWS Configが多用されることで思わぬコスト増が発生するとの情報もあり、今回は見送ることにしました。 IAM Identity Centerとは 元は AWS Single Sign-On （AWS SSO） というサービス名でした。 これはIAMユーザとは全く別物のユーザ（これをSSOユーザとします）を作成し、SSOユーザが各AWSアカウントの各IAMロールを持ったユーザに変身することができる機能です。 IAM Identity Center概要図 IAM Identity Centerを導入した決め手 SSOユーザと権限の管理は一つのAWSアカウントのIAM Identity Centerで管理することができます。 これはAWS Organizationsの機能の上に乗る機能ですが、幸い元々それを導入していたことで、すぐに組み込むことができました（ちなみに現在はIdPを設定することでAWS Organizationsがなくてもこの機能を使うことができます）。 つまり、 複数のAWSアカウントの複数のユーザの複数のロールを一つのIAM Identity Centerで全て管理することができるのです 。 では、各AWSアカウントで既に作成してしまったIAMポリシーを、IAM Identity Centerで同じ内容で作り直さないといけないかというとそんなこともなく、カスタムロールという設定で、IAMポリシー名だけ定義することで既存のIAMポリシーをそのまま活かすことができます。 そして、SSOユーザは恒久的なアクセスキーを持つことができず、最大で12時間の期限付きアクセスキーしか持つことができません。従って、 仮に万が一アクセスキーが漏洩しても12時間後には使えなくなります 。 まさに最強で無敵のIAM Identity Centerです。 IAM Identity Centerの導入 ここではIAM Identity Centerの導入の流れを簡単に説明いたします。 一番最初はIAM Identity Centerを有効にすることですが、それは割愛して有効化した後の手順を記載していきます。 IAM Identity Center全体図 SSOユーザの作成 SSOユーザは前述した通りIAMユーザとは全く別物なので、新たに全員分作成する必要があります。 最低限必要なのは名前とメールアドレスのみです。 作成画面に任意項目で住所や電話番号などあったりするのですが、システム的には全く関係ないようです。IAM Identity CenterをIdPとして使うときのための設定でしょうか。 SSOユーザ作成画面 SSOグループの作成 SSOグループとは、SSOユーザと後述する許可セットをまとめるためのものです。 新しいSSOユーザが増えた場合は、該当のグループに追加してあげるだけでOKです。 SSOグループ作成画面 許可セットの作成 許可セットは、IAMロールの素になるものです。 ここで設定したポリシーが各AWSアカウントにIAMロール、IAMポリシーとしてプロビジョニングされます。 プロビジョニング先のAWSアカウントに既にあるIAMポリシーを使いたい場合は、カスタマーマネージドポリシーでその名前を設定すれば割り当てることができます。 名前が間違っていて存在しないIAMポリシーを設定してしまった場合は、プロビジョニング時にエラーになります。 許可セット作成画面 プロビジョニング “SSOユーザまたはグループ” と “許可セット” を適用したいAWSアカウントにプロビジョニングすることで、対象SSOユーザで該当AWSアカウントにログイン可能になります。 プロビジョニング概要図 SSOアクセスポータル画面 SSOユーザでログインするAWSアクセスポータル画面に、AWSアカウントへのリンクの一覧が表示されます。 このリンクから各AWSアカウントに、任意のロールでログインすることができます。便利ですね！ AWSアクセスポータル画面 一時的なアクセスキーはCLIでも取得できますが、この画面からも アクセスキー のリンクをクリックすると一覧画面が表示されます。 AWSアクセスポータル アクセスキー確認画面 導入後に対応したこと これまでの手順でマネジメントコンソールのでログインはできるようになっていますが、それ以外のツール等で利用するためにしたことをここでは説明します。 ~/.aws/configの修正 ターミナルでAWS CLIを利用するために、これまでアクセスキーを直接指定していたのを、SSOユーザ対応の記述に変更する必要があります。 アクセスキーなどのクレデンシャルな情報の記載が不要になり、この内容が漏洩してもダメージが少ないです。 [default] sso_session = m y-sso sso_account_id = 999999999999 sso_role_name = x xxxxxxxxxxx [sso-session my-sso] sso_start_url = h ttps://xxxxxxxxxxxx.awsapps.com/start sso_registration_scopes = s so:account:access sso_sessionの設定が古いaws_sdkだと対応していなかったりしたので、最新のaws_sdkを使うように mise (開発ツール管理用ツール)に設定しました。 [tools] awscli = "latest" この設定をした状態で aws sso login を実行すると認証画面のブラウザが自動で立ち上がり、ブラウザでの認証完了後にターミナルでCLIが使えるようになります。 ターミナルでsso login ブラウザで認証 開発環境へのアクセスキーの渡し方 開発環境においてアクセスキーの設定が必要な箇所があり、それを毎日ポータル画面からコピペで更新してくださいというのは面倒すぎるので、毎日1回最初にシェルを実行してもらうようにしました（これも面倒なのでこれなしでどうにかできれば良かったのですが・・・無念）。 この実行にはSSOの認証情報をシェル内の処理で利用するため aws2-wrap を利用し、.envファイルの更新には python-dotenv を利用しました。 これもmiseで定義することで、全開発メンバーにもれなく対応できました。 # 一部抜粋 if ! $(aws2-wrap --profile " $profile " --export ); then aws sso login --profile= " $profile " eval "$( aws2-wrap --profile " $profile " --export )" fi # 一部抜粋 from dotenv import set_key def update_env_file ( env_file , key_value_pairs ): try : for key in key_value_pairs: value = key_value_pairs[key] set_key(env_file, key, value, quote_mode = 'never' ) except Exception as e: print (e) Terraform, Packerの対応 最新のTerraform、Packerではaws ssoに対応しているので、ssoのprofileをそのまま使うことができます（AssumeRoleには対応していなかったので、それを対応させた時は大変でした・・・）。 Terraformは環境依存をなくすため実行環境をコンテナ化しコンテナ内で実行しているのですが、“ログイン時にSSOセッションの存在有無の確認” → “なければSSOログイン” をさせることで、 aws sso login の事前実行を意識しなくても良いようにしました。 # 一部抜粋 function get_caller_identity () { set +eu for i in { 1..3} ; do command "aws sts get-caller-identity --profile $1 " if [[ $? = 0 ]]; then break else echo "Not logged in" command "aws sso login --profile $1 " fi done set -eu } 最新のPackerはaws ssoに対応していると前述しましたが、なぜだか環境により sso-session が効かずにエラーになる場合がありました。その場合はレガシーな記述方法で回避できます。 [profile packer] credential_process = a ws --profile default configure export-credentials --format process region = a p-northeast-1 output = j son 対応して良かったこと 管理者目線で良かったこと 管理者目線では、AWSのユーザ管理が大分楽になりました。 これまで開発メンバーが増えた際には、複数のAWSアカウントに対しそれぞれに、IAMユーザの作成、アクセスキーの生成をし、その後初期ログインパスワードとアクセスキーをメンバーに配布しなければならなかったため、作業が大分煩雑でした。 IAM Identity Center導入後は、 1つのAWSアカウントでSSOユーザを作成するだけです 。招待メールも勝手に送られます。 また、与えている権限の管理も楽になりました。 IAM Identity Centerの画面を見れば、誰がどのAWSアカウントにどんな権限を持っているか全てわかりますし、設定するのもそこだけなので 、いろんなAWSアカウントを出入りして確認・設定する必要がなくなりました。 利用者目線で良かったこと 利用者目線では、各AWSアカウントへのログインがポータル画面のリンクから行くことができるので、 AWSアカウントごとにログインの作業が必要なくなったのも楽ですし、各AWSアカウント毎にログイン情報、MFA情報を保持しなくても良くなったのも管理が気楽になりました 。 対応して困ったこと 12時間の壁 SSOユーザのセッション時間の上限が12時間のため、朝9時にログインすると夜9時にセッションが切れてしまいます。そのことを忘れて12時間後に急に開発環境でエラーが出始めて「なんじゃこりゃあああ！」とたまに驚かされます（12時間以上働くことがほとんどないのでめったに遭遇しませんが、だからこそ忘れます）。 深夜メンテの際にそれが起きるとトラブルになりますので、その際は作業前に必ずログインし直すようにしています。 個人的にはセッション時間の上限の時間もう少し上げて欲しいです。 利用できないサードパーティーツールの存在 AWSにアクセスするためのサードパーティーツールは様々ありますが、 AWS_ACCESS_KEY_ID 、 AWS_SECRET_ACCESS_KEY の2項目しか設定できないものがあります。 SSOユーザでログインするには、それらに加え AWS_SESSION_TOKEN の値が必要であるため、設定できないツールはSSOユーザでは利用できないことになります。 最近ではSSOユーザでも利用できるようにアップグレードされているツールも増えてきていますので、今まで使っていたツールが使えなくなった場合は代替のツールを使いましょう。 まとめ これは絶対嘘ではなくて、IAM Identity Centerを導入することで、トイルの削減も、情報漏洩リスクの削減も、両方実現することができました。 もちろん私たちの挑戦はこれで終わりではなく、サービスの品質を上げるため、開発メンバーが開発に集中できる環境を作るため、 俺たちの戦いはまだ始まったばかり 、です。 そして、明日12月4日は @shigerisa さんが何やらもっと面白い記事を書いてくれているようです！お楽しみに！ We’re hiring! メドレーでは各種エンジニアを絶賛募集中です！ カジュアル面談いつでもWelcomeですので、お話しだけでも聞いてみたい、むしろ私の推しの話を聞いて欲しい、などなんでもかまいませんので、お気軽にお問い合わせください！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに 皆さん、こんにちは! エンジニア / エンジニア・デザイナー採用担当の平木です。 弊社では社内のエンジニアが定期・不定期で勉強会を開催しています。この勉強会は、プロダクト開発の話はもちろんですが、各技術の最新情報の共有などを、事業部に留まらず全社的に行う会となっています。 11/15(金)にも社内勉強会を開催したのですが、題材を Web フロントエンド版 DX Criteria についてとしました。そこで作成者の 1 人である日本 CTO 協会 DX Criteria WG の佐藤 歩( @ahomu )さん(以下 ahomu さん)を講師としてお招きして講演をしていただきましたので、そのレポートとなります。 今回の勉強会開催の背景 今年 4 月に Web フロントエンド版 DX Criteria が 発表 されたのを見て、内容的にメドレーでも参考にできる部分が非常に多いと思いました。 作成者の 1 人である ahomu さんは筆者の前職同僚だったということもあり、勉強会講師を打診して快諾いただいたため、開催の運びとなりました。 勉強会について 講演の様子 今回は社外から講師をお招きするということもあり、勉強会へは 25 名ほどの参加となりました。 真剣に講演を聞くメンバー 社内限定での勉強会ということもあり、ahomu さんからも、メドレーに合わせて濃いお話をしていただきました。 歴史を踏まえた昨今のフロントエンドの技術的な変遷 現代のフロントエンドの設計で重視しなければならないポイントと提供するプロダクトの特性の関係 開発持続性を実現するための、開発環境について Web フロントエンド版 DX Criteria の成り立ちや目的を、弊社の状況も交じえながら解説 Web フロントエンド版 DX Criteria のそれぞれの項目について、弊社の状況を踏まえて解説 アセスメント後に、どのような整理をして改善していけばよいかの指針について 佳境に入った講演の様子 上述したものは内容の一例で、全てをお伝えできませんが参加者がより Web フロントエンド版 DX Criteria を「メドレーのプロダクト」ベースで考えられるような講義を行なっていただきました。 参加者からも Web フロントエンド版 DX Criteria の内容を越えたフロントエンド技術についての質問なども飛び出して、大変盛況のうちに終了しました。 改めてプロダクトのフロントエンド開発を事業発展にどのように繋げるかという視点で考えることができた、非常に有意義な時間となりました。 多忙の中、今回の勉強会講師を快諾してくださった ahomu さんに大変感謝しております。ありがとうございました! ahomu さんと記念撮影 さいごに メドレーではこれからも機会があれば、社内の開発者向けに外部講師を招聘して勉強会などを開いていく予定です。 自分の技術を色々な角度から高めていきたい!と考えているエンジニア・デザイナーの方はぜひご連絡ください。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに 皆さん、こんにちは! エンジニア / エンジニア・デザイナー採用担当の平木です。 弊社では社内のエンジニアが定期・不定期で勉強会を開催しています。この勉強会は、プロダクト開発の話はもちろんですが、各技術の最新情報の共有などを、事業部に留まらず全社的に行う会となっています。 11/15(金)にも社内勉強会を開催したのですが、題材を Web フロントエンド版 DX Criteria についてとしました。そこで作成者の 1 人である日本 CTO 協会 DX Criteria WG の佐藤 歩( @ahomu )さん(以下 ahomu さん)を講師としてお招きして講演をしていただきましたので、そのレポートとなります。 今回の勉強会開催の背景 今年 4 月に Web フロントエンド版 DX Criteria が 発表 されたのを見て、内容的にメドレーでも参考にできる部分が非常に多いと思いました。 作成者の 1 人である ahomu さんは筆者の前職同僚だったということもあり、勉強会講師を打診して快諾いただいたため、開催の運びとなりました。 勉強会について 講演の様子 今回は社外から講師をお招きするということもあり、勉強会へは 25 名ほどの参加となりました。 真剣に講演を聞くメンバー 社内限定での勉強会ということもあり、ahomu さんからも、メドレーに合わせて濃いお話をしていただきました。 歴史を踏まえた昨今のフロントエンドの技術的な変遷 現代のフロントエンドの設計で重視しなければならないポイントと提供するプロダクトの特性の関係 開発持続性を実現するための、開発環境について Web フロントエンド版 DX Criteria の成り立ちや目的を、弊社の状況も交じえながら解説 Web フロントエンド版 DX Criteria のそれぞれの項目について、弊社の状況を踏まえて解説 アセスメント後に、どのような整理をして改善していけばよいかの指針について 佳境に入った講演の様子 上述したものは内容の一例で、全てをお伝えできませんが参加者がより Web フロントエンド版 DX Criteria を「メドレーのプロダクト」ベースで考えられるような講義を行なっていただきました。 参加者からも Web フロントエンド版 DX Criteria の内容を越えたフロントエンド技術についての質問なども飛び出して、大変盛況のうちに終了しました。 改めてプロダクトのフロントエンド開発を事業発展にどのように繋げるかという視点で考えることができた、非常に有意義な時間となりました。 多忙の中、今回の勉強会講師を快諾してくださった ahomu さんに大変感謝しております。ありがとうございました! ahomu さんと記念撮影 さいごに メドレーではこれからも機会があれば、社内の開発者向けに外部講師を招聘して勉強会などを開いていく予定です。 自分の技術を色々な角度から高めていきたい!と考えているエンジニア・デザイナーの方はぜひご連絡ください。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに 皆さん、こんにちは! エンジニア / エンジニア・デザイナー採用担当の平木です。 弊社では社内のエンジニアが定期・不定期で勉強会を開催しています。この勉強会は、プロダクト開発の話はもちろんですが、各技術の最新情報の共有などを、事業部に留まらず全社的に行う会となっています。 11/15(金)にも社内勉強会を開催したのですが、題材を Web フロントエンド版 DX Criteria についてとしました。そこで作成者の 1 人である日本 CTO 協会 DX Criteria WG の佐藤 歩( @ahomu )さん(以下 ahomu さん)を講師としてお招きして講演をしていただきましたので、そのレポートとなります。 今回の勉強会開催の背景 今年 4 月に Web フロントエンド版 DX Criteria が 発表 されたのを見て、内容的にメドレーでも参考にできる部分が非常に多いと思いました。 作成者の 1 人である ahomu さんは筆者の前職同僚だったということもあり、勉強会講師を打診して快諾いただいたため、開催の運びとなりました。 勉強会について 講演の様子 今回は社外から講師をお招きするということもあり、勉強会へは 25 名ほどの参加となりました。 真剣に講演を聞くメンバー 社内限定での勉強会ということもあり、ahomu さんからも、メドレーに合わせて濃いお話をしていただきました。 歴史を踏まえた昨今のフロントエンドの技術的な変遷 現代のフロントエンドの設計で重視しなければならないポイントと提供するプロダクトの特性の関係 開発持続性を実現するための、開発環境について Web フロントエンド版 DX Criteria の成り立ちや目的を、弊社の状況も交じえながら解説 Web フロントエンド版 DX Criteria のそれぞれの項目について、弊社の状況を踏まえて解説 アセスメント後に、どのような整理をして改善していけばよいかの指針について 佳境に入った講演の様子 上述したものは内容の一例で、全てをお伝えできませんが参加者がより Web フロントエンド版 DX Criteria を「メドレーのプロダクト」ベースで考えられるような講義を行なっていただきました。 参加者からも Web フロントエンド版 DX Criteria の内容を越えたフロントエンド技術についての質問なども飛び出して、大変盛況のうちに終了しました。 改めてプロダクトのフロントエンド開発を事業発展にどのように繋げるかという視点で考えることができた、非常に有意義な時間となりました。 多忙の中、今回の勉強会講師を快諾してくださった ahomu さんに大変感謝しております。ありがとうございました! ahomu さんと記念撮影 さいごに メドレーではこれからも機会があれば、社内の開発者向けに外部講師を招聘して勉強会などを開いていく予定です。 自分の技術を色々な角度から高めていきたい!と考えているエンジニア・デザイナーの方はぜひご連絡ください。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp