はじめに この記事は mediba Advent Calendar 11日目の記事です。 バックエンドエンジニアをしている山口です。medibaに入社して約7年になります。 7年もこの業界でエンジニアをしているにも関わらず、 私はこれまでマークアップという業務に一切関わってきませんでした。 そんな私が、今回はじめて業務で .html をデプロイした話をします。 動機 デプロイに至ったきっかけはいくつかありますが、 現在のプロジェクトから離れることが決まった。 生成AIの成長が加速度的に進化している。 が大きな理由でした。 現在のプロジェクトから離れることが決まった 皆さん

Introduction ! この記事は、 mediba アドベントカレンダー2025 の10日目です。 株式会社medibaでエンジニア組織マネージャーと複数プロダクトの開発責任者を担当している船田です。 新規プロジェクトや新機能の検討時、ビジネス担当やクライアントからこう聞かれた経験はありませんか？ 「ねぇ、これ、ざっくり1,000万円くらいでできる？」 「これってざっくりどのくらいでできるかな？」 この「ざっくり」という問いかけの裏にある、ビジネス側の真の意図は、意思決定のための目安を求めているのです。 投資対効果に見合うか。 他の並行案件と比較したプロジェクトの優先度決め

はじめに この記事は mediba Advent Calendar 8日目の記事です。 エンジニア組織でマネージャーを務めているチェです。 medibaに入社して約6年、マネージャーになってから約3年が経ちました。 マネージャーになってから ちょっと技術的な話よりは、私自身のキャリアの「リファクタリング」についてお話しします。 エンジニアとして約10年間、ライフサイクルの管理やメモリリークなどと戦い続けてきたのですが、この3年間マネージャーとして何を感じて、何が変わったのか。 「現場を離れるのが怖い」、「マネージャーになると技術力が落ちるのではないか」 そんな不安を感じているエン

株式会社medibaの田中です。 新卒で入社して今年で3年目になります。バックエンドエンジニアしてます。 もうすぐ大晦日＆お正月。帰省したり、親戚の家に行ったりする時期が近づいてまいりました。 私も就職を機に親元を離れた身。実家の犬にジャーキーを献上するミッションがあります。 ミッションはジャーキー献上だけではありません。帰省したら必ず訪れる、もう一つの大ミッション。それが、親戚一同が集まる食卓での あんた仕事何してんの？ 難問です。 お茶の間の難問と「裏方」の宿命 一言に「エンジニア」と答えても伝わりません。年代や職業によって「エンジニア」から想像するお仕事は変わることがあります。

株式会社medibaの田中です。 新卒で入社して今年で3年目になります。バックエンドエンジニアしてます。 本記事では、私が昨年の12月から支援している学生インターン育成の取り組みについてご紹介します。 指導の核となっているのは、「教えない勇気」 というアプローチです。 11/10に行われたKGDC内での発表内容と同じです。使用したスライドは↓ 育成の目的と体制 このインターンシップの期間は2024年12月〜2027年3月。学生(1名)が卒業するまで継続中です。 期間から察する通り、対象学生は内定者ではありません。 そのため、育成のゴールは 学生が 「自信」と「報連相」 を身につけ、

はじめまして、または、お久しぶりです。medibaテックブログ運用担当です。 これまで mediba Creative x Engineer Blog で発信を行ってきましたが、この度ブログをZennに移設することにしました。 移設に至った経緯についてをご紹介いたします。 技術ブログ移設の理由 旧技術ブログでは過去様々な投稿がありましたが、正直なところ今では下火になってしまいました。振り返ってみて投稿が減ってしまった主な要因を考えてみました。 管理画面での記事投稿が非常にしづらい 旧技術ブログの裏側で利用していたTumblrはマイクロブログ用のSNSであるため長文を記述するのに向

この記事は medibaアドベントカレンダー 2025 3日目の記事です。 はじめに mediba でフロントエンドエンジニアをしている y_nakahata です。 私の所属している開発チームでは、2025年度から業務で GitHub Copilot を使用しています。この記事では、mediba の開発プロジェクトでの活用事例をご紹介します。 概要 初めに、プロジェクトの概要についてご説明します。詳細は公開できないのですが、あるプロダクトの技術スタックを PHP から Next.js に置き換える技術刷新プロジェクトでした。 PHP でフロントエンドとバックエンドの両方が実装さ

はじめに こんにちは、データアナリストの左海です。 担当中の案件にて、対象ページを別ドメイン上（クロスサイト）でiframe呼び出しすると GA4イベントが送信されないという事象に遭遇しました。 今回は、本事象の原因と解決策について書いていきます。 事象 以下の前提を踏まえて、事象について説明していきます。 iframe呼び出し元、呼び出し先ドメインの関係は「クロスサイト」に該当する 両ドメインは、page_viewイベントなど基本的なGA4イベントの計測設定済 GA4ログの疎通確認は、Google Chromeの開発者ツールのNetworkパネルで行った 添付画像の通り、a.com上で、b.comをiframe呼び出ししていたのですが なぜかb.comのGA4イベントの送信のみ確認できませんでした。 原因 調査したところ、Google Chromeの仕様変更が原因であることが判明しました。 On top of these, in the latest version of the Google Chrome browser, the cookie will also be treated as having the SameSite=Lax flag. This means the cookie will not work when accessed in a third-party context. 引用： THE NEW COOKIEFLAGS SETTING IN GOOGLE ANALYTICS Google Chrome 80の仕様変更により、CookieのSameSite属性のデフォルト値が「None」から「Lax」に変更となり、サードパーティコンテキスト（クロスサイト）のCookieの書き込みが拒否されるようになったようです。 その結果、b.comからGA Cookieへの書き込みが拒否され、GA4イベントが送信できなかったということです。 解決策の前に、クロスサイトやCookieのSameSite属性についても触れておきます。 クロスサイトとは クロスオリジンのような似た語句が多く、混乱する可能性が高いため「クロスサイト」について整理しておきます。 クロスサイトは、スキームやeTLD+1が異なるウェブサイトを指します。 例として、以下のパターンが該当します。 また、Google Chromeの開発者ツールのNetworkパネルでもクロスサイトかどうかの確認が可能です。 任意のファイルの「Request Headers」の「Sec-Fetch-Site」ヘッダーの値を確認し 添付画像のように、値に「cross-site」と表示されていれば「クロスサイト」となります。 参考： 「Same-site」と「same-origin」 CookieのSameSite属性とは CookieのSameSite属性とは、Cookieの取り扱いに関するセキュリティレベルを指定するための属性です。 Google Chrome 80の仕様変更の背景として、GoogleがCSRF（Cross-site Request Forgeries）対策としてブラウザレベルでセキュリティ対策を施したようです。 繰り返しになりますが、クロスサイトにおけるGA Cookieの書き込みもセキュリティ対策の対象となり、GA4ログの送信ができませんでした。 なお、SameSite 属性に設定可能な値は、None、Lax、Strictの3種類で それぞれの設定値の詳細については、以下のサイトをご確認ください。 参考： Using HTTP cookies - HTTP ※ SameSite=None が設定されている場合、必ずSecure属性も付与しCookieの書き込みをHTTPS通信に限定する必要があります 解決策 解決策は、GA CookieのSameSite属性の値を「None」に設定するのみです。 今回、GA4イベントの計測はGTM経由で行っていたため、対象のGoogleタグの構成パラメータ「cookie_flags」の値に 「SameSite=None;Secure」と設定すれば、完了です。 おわりに 本事象に遭遇して、改めてアクセス解析におけるCookieの重要性を再認識することができました。 同時に、データアナリストはインターネットに関係するドメイン知識を可能な限りインプットしておく必要があると感じました。 引き続きあらゆることに興味をもって業務に取り組んでいきます。

ALT View on Twitter 長男が藤本タツキの短編にハマっていて喜んでいいのかわかりません。 本稿は、藤本タツキ論ではなく、図解ツール mermaid をauウェルネス開発チームで利用した際のtipsです。 mermaidとは JavaScriptベースの図解ツールです。 ライブエディタ も提供されています。 プラットフォームは、開発に欠かせない各種SaaSでのサポートも進んでおり、notionを導入している弊チームもそのメリットを享受することが出来ております。 その話は、また後日に。 入門 弊チームでは、事ある毎に図表を残すようにしています。 現状もmermaidを利用を強制することはしておりませんが、PlantUMLで各種図表を作成してきました。 mermaidの文法は、PlantUMLを利用されたことがあれば、直感的にわかるでしょう。 サンプルのリンクを貼っておきますので、気になる方はどうぞ。 シーケンス図 フローチャート ER図 tips オンラインのコミュニケーションが定着している弊チームですが、ご多分に漏れず情報共有のあり方には課題がありました。 特に設計フェーズにおいては、図解して概要や意図を伝える(書き残す)ことが習慣化出来ていたものの、PlantUMLではその成果物の管理に一手間あり、チームの負担にもなっていました。 notionを導入している弊チームからするとmermaidは、PlantUMLに比べて成果物をリアルタイムで共有、手軽に管理出来ることにメリットがあります。 今後は、変更管理の課題に取り組んでいきたいと思います。 おわりに mermaidは、それ単体でも十二分に有用なツールですが、JavaScriptベースであることを活かして各種SaaSやプラットフォームと組み合わせ利用できることに強みがあります。 皆さんの図解ライフに本稿が少しでも貢献出来れば幸いです。 ではまた。

こんにちは、テクノロジーセンターオンボーディングチームメンバーです。 皆さんの会社では、オンボーディングプログラムをどのように運営していますか？ medibaでは、テクノロジーセンターに入った従業員向けの教育プログラム『中途社員向けオンボーディング』を実施しています。 今回は、テクノロジーセンターの有志のメンバーが教育プログラムを構築し、実施し改善した活動についてお話しようと思います。社歴が長い人も入社したての人も、異なる職種のメンバーが集まり、限られた短い時間の中で取り組みました。 エンジニア向けにオンボーディングを構築する上で少しでもご参考になれば幸いです。 なぜオンボーディングプログラムを作ったのか 数年前から、全社の組織構造が事業型からマトリクス型へ変わりました。現在は、エンジニアが所属するテクノロジーセンターと、プロダクトごとのプロダクトチームが交差する組織構造となっています。 これまではテクノロジーセンターでのオンボーディングがなく、以下のような課題がありました。 情報が足りていない、まとまっていない、検索しにくい 入社者は、何からはじめたらよいかわからない プロジェクトに入ればプロダクトのオンボーディングがあるが、人となりや保有技術がわからず誰に聞いたらいいかわからない 担当によって教えることにばらつきがあり、OJT担当者に負荷がかかっている オンボーディングプログラムの目指すべき姿 そこで、オンボーディングプログラムがどうあるべきなのか、ヒアリングを実施し、下記を目指すことにしました。 中途入社の方が即戦力として活躍できる環境を作る 活躍できない、既存メンバーに負荷がかかるなどの理由での退職を防ぐ プロジェクトや人に依存しない仕組みを作る 課題解決のために何をやったか 上記の課題を解決するために、オンボーディングプログラムとして、入社時に知っておくと良いリンク集「まとめページ」を作成しました。入社者には「まとめページ」にそって自習していただき「チェックシート」で各項目が把握できたかを記載し共有します。分からないことは「よろず相談」へ問い合わせてもらいます。そして、下記のようなタスクを作り、半年間運営してみました。 入社時に知っておくと良いリンク集「まとめページ」と入社者用「チェックシート」の作成 入社翌日に３０分ほど説明会と、オンボーディングメンバーの紹介 問い合わせ場所「よろず相談」で分からないこと・ご意見お伺い 入社者向けアンケート自動化 入社者の質問に伴い「まとめページ」を随時更新し継続的改善 上長、OJT担当向けにヒアリング テクノロジーセンター向けアンケートでオンボーディング活動の価値をお伺い 来期活動の課題を抽出 人事と連携して入社情報をキャッチアップ 実は、進める上で苦労したこと 知ってもらいたい情報量が多すぎて、スコープが決まらず、情報の重要度と粒度を決めるのが大変でした。そこで、半年でプログラムの実施及び検証を前提に開始予定日を決め、「中途エンジニアが組織で活躍するために必要な情報」として、エンジニアがオンボーディングで触れておきたい項目を下記の３つに絞って整理することにしました。 知っていないと業務開始できない・・・ 開発に関する知識 業務が深くなったり領域が広がった時知らないと困る・・・ センターに関する情報 長く会社にいると必要になってくる・・・ 会社全体の情報 結果はどうだったか 半年で「まとめページ」の作成、半年でオンボーディングプログラムの運営を行ってみての結果は、アンケートやヒアリング結果を分析したところ、当初課題の６割がたは解決できました。また、今回の活動の内容をより多くの人に知ってもらうために、社内報告会を行いました。 それぞれいただいた意見は下記のような内容でした。 ＜ポジティブな意見＞ 入社者が感じる「情報が足りていない」「何からはじめたらよいかわからない」は解決できた オンボーディングプログラムによる受入部門の負担は減った 入社者からの質問は、まとめページの改善につながる ＜まだまだ改善が必要な点＞ 人 先輩との交流の機会をもっとつくってもらえないか もっと「人」がわかる仕組みが欲しい 情報 まとめページのブラッシュアップ 情報メンテナンスの文化をつくってもらいたい フォロー体制 目標や評価は自分で読んで理解するには限界あり 「開発に関する知識」の情報は見ていただいているが、「会社全体の情報」は見られていない傾向にある 最後に まだ課題は残っているのですが、今回のオンボーディングプログラムを実施した方からは好意的なご意見をもらえました。 受け入れるプロダクトの方の負担も減り、オンボーディングの活動自体に価値を感じました。 これからも活動を継続して残っている課題を解決していき、今後入社される方の助けになることができればと思います。 テクノロジーセンターでは、いろんな視点のいろんな職種のメンバがアイディアを出し合って、「いいものを作り続ける」マインドでオンボーディングプログラムを運営しています。 現在medibaではメンバーを大募集しています。 募集・応募ページ medibaってどんな会社だろうと、興味を持っていただいた方は、カジュアル面談もやっておりますので、お気軽にお申込み頂ければと思います。 カジュアル面談

こんにちは。mediba でテクノロジー2G にてFEをしております、楊です。 最近のPJ開発中にあったことで、Reactコンポネートの制御か非制御か当時綺麗に解決できなかったので、 振り返って、色々調べた上にまとめたメモです。 コンポネートの制御と非制御 React公式の説明 下手な絵で簡単に説明すると↓ ではどうすれば、非制御であり制御コンポネートでもあるコンポネートを作れるでしょう 最も簡単なやり方ーー内外のStateを持ちながら同期させる まずは子コンポネート内でStateを持たせて、どんな状態（制御モード・非制御モード）でも自分のStateを使うようにする。 次は制御モードにおいて、内部StateをPropsと同期させれば、問題なさそう！ const Input: FC<{ value?: string; onChange?: (value: string) => void; }> = (props) => { const isControlled = props.value !== undefined; const [value, setValue] = useState(props.value); const handleOnChange = (e) => { if (isControlled) { setValue(e.target.value); props.onChange(e.target.value); } } useEffect(() => { if (isControlled) { setValue(props.value); } },[props.value]); return ( <input value={value} onChange={handleOnChange}/> ); }; よくみてみると、制御モードでは気になるところも出てきたね 子コンポネート内のState更新はParentより遅い パフォマンス的によくない、useEffect内でのsetStateの使いなので、余計な再描画が発生してしまう 解決できそうかな、試してみよう 子コンポネート内のState更新はParentより遅い これだと簡単に解決できそう、制御モードにおいてPropsから渡してきた値そのまま使えばいい。 const finalVal = isControlled ? props.value : value const handleOnChange = (e) => { if (isControlled) { setValue(e.target.value); props.onChange(e.target.value); } } return ( <input value={finalVal} onChange={handleOnChange}/> ); こうすれば、同期は一歩遅くても、子コンポネートに使ってもらうStateは必ず最新であることを担保できる。 パフォマンス的によくない、useEffect内でのsetStateの使いなので、余計なレンダリングが発生してしまう useEffect内でのState同期なので、再描画を防げなくて、簡単なコンポネートであれば、パフォマンスの影響は少ないが、コンプレックスなコンポネートには、問題である ポイントは 同期させるタイミング だね、ならどうしよう、、、、 Stateでvalue保存には、setterで同期させた直後に再描画が始まる、もし再描画が制御可能になったら問題ないでしょう。 保存にはRefを使って、強制再描画には 仮のstateを作って const [_, setObj] = useState({}) function triggerRendering(){ setObj({}) } を使う。そうしたら全体は↓ const Input: FC<{ value?: string; onChange?: (value: string) => void; }> = (props) => { const isControlled = props.value !== undefined; const stateRef = useRef(props.value); if (isControlled) { stateRef.current = props.value; } const [_, setObj] = useState({}); function triggerRendering() { setObj({}); } const handleOnChange = (e: React.ChangeEvent) => { stateRef.current = e.target.value; triggerRendering(); props.onChange(e.target.value); }; return <input value={stateRef.current} onChange={handleOnChange}/>; }; こうしたことで値の同期による再描画がなくなり、制御同時に非制御のコンポネートが出来上がった。 refとhandleOnChangeの部分を取り出し、hooksにすることで、他のコンポネートに適用することもできるでしょう。 現在medibaではメンバーを大募集しています。 募集・応募ページ medibaってどんな会社だろうと、興味を持っていただいた方は、カジュアル面談もやっておりますので、お気軽にお申込み頂ければと思います。 カジュアル面談

こんにちは。mediba でテクノロジー統合Unit にてマネージャをしております、長根と申します。 エンジニア業界の市況は、各社熾烈なエンジニアの取り合いといった状況となって久しい今日この頃いかがお過ごしでしょうか。 さて、こと弊社においてもエンジニア採用は、重要テーマかつ永遠のテーマでもあります。 これまでもエンジニア組織と、人事部門が連携して課題に取り組んでおりましたが、一昨年から、「（組織課題解決の）民主化」と称して、現場を主体で課題を解決していく取り組みを行っております。 今回はその活動における取り組みの紹介を通したいと思います。medibaのことに少しでも興味を持って頂けたり、同じような課題を持つ方への参考の一助となれば幸いです。 組織課題の民主化とは？ これまで組織課題の解決において、マネージャを中心として進めていくことが多くありましたが、以下のような課題がありました。 プロセスが不透明とみられることが多い。健全性の担保に難がある。 マネージャ主体では、現場での課題から遠いケースがある。 これらの課題から、「役職関係なくエンジニアの誰もが参加可能で、現場のエンジニアがより良い課題解決を行う」ことができるよう民主化の取り組みが開始されました。 好きなフルーツを決めよう！ 課題の民主化の取り組みにおいて、上司から指示を参加を強制されることはありません。 参加するもしないも自分次第です。 課題弊社VPoEの下地から、メンバーに向けて取り組みたい課題をフルーツに例え参加表明をしていくカジュアルな感じでメンバーが募られていきます。 見て頂くとわかるように、民主化の取り組みにおいては、採用活動以外にも、色々なチームがあります。 何をどのように取り組んでいったのか。 採用チームとして、適切な組織維持のために継続的な採用を行う必要がありますが、そもそもの面談/面接の母数を増やさない事には、採りたいエンジニアの方を獲得することは難しいです。 そのため、まずは面談/面接回数を向上するといったKPIを掲げ、その中で適切なスキルセットやマインドを持つ方にアプローチや、情報が届けられるよう、様々な観点から施策を行っていきました。 個々詳細の施策内容は割愛しますが、以下のような取り組みを行っていきました。 採用チャネル別の見直し 採用エージェント 市場感の把握、求職者視点で知りたい情報が伝えられているか エージェントさん向けの個別資料（組織、カルチャー等）の作成・提供 リファラル採用 リファラル採用施策の改善（運用、インセンティブ見直し） カジュアル面談 カジュアル面談の応募ページの作成、導線作成 ダイレクトリクルーティング 新規ダイレクトリクルーティングツールの利用開始 新卒採用 新卒カジュアル面談の運用・改善（多人数での面談が可能な体制へ変更） 採用ページ改善 求職者が求める情報（現場課題、制度、カルチャー、記載できていない福利厚生等）を拡充 視認性向上 これらの施策をエンジニアだけで行うことは限界があるので、人事部門との週次の定期ミーティングを通して課題解決に向けて、それぞれの部門でのタスクを分担して進めていきました。 結果と感想 上期のKPIは無事達成することができました。 取り組み前に比べ、格段に面談数が多い状況となりました。 下期状況はまだ未確定ですが、良い数字が出ている状況です。 面談/面接数のKPIは、目標指数として分かりやすい反面、転職市況やその他外的要因から大きく影響を受けるため、施策がダイレクトに繋がったかどうかの評価が難しい点もありますが、なるべく定量的に評価できるように計測や振り返りが必要と感じています。 今回の民主化活動を通じ、未来の仲間を増やしていくため、様々な観点から採用課題に取り組むことで、見えてくることも多く、これは大きな発見であったと感じます。 今後も未来のmedibaを担うメンバーと巡り合えるように積極的に活動をしていきたいと思います。 現在medibaではメンバーを大募集しています。 募集・応募ページ medibaってどんな会社だろうと、興味を持っていただいた方は、カジュアル面談もやっておりますので、お気軽にお申込み頂ければと思います。 カジュアル面談

初めに こんにちは、バックエンドエンジニアの山口です。 W 杯での三苫選手を筆頭とした日本代表チームの躍進、アルゼンチン vs フランスの決勝を見て、これまでサッカーを見てなかったけど abemaTV などで海外サッカーを見るようになった！という方も多いのではないでしょうか。 今回の記事では主観満載でサッカークラブを考察して、エンジニア組織、開発チームの運営について自分なりに考えてみたいと思います。 それぞれに関わっているメンバーをざっくりと エンジニア組織 VPoE マネージャー エンジニア サッカーチーム 監督 コーチ(フィジカル,戦術,セットプレーなどなど) 選手 チームについて サッカークラブを語るにあたって切り離せないのが監督と選手です。 今、欧州で最も成績を残しているチームはマンチェスター・シティ, レアル・マドリードだと思います。(僕はクレですが。) この 2 チームを戦術•監督•選手•試合内容の観点で単純比較すると以下のようになります。 どちらのチームも欧州で最高レベルの成績を近年残し続けているクラブなので、どちらが良い悪いの話ではありませんが、チーム作りに違いがあります。 レアル・マドリードのようなチームはエンジニア組織に例えると、尖ったエンジニア達(I 型人材)を政治力•マネジメント力の強いマネージャーがまとめ上げているイメージでしょうか。逆にマンチェスターシティは T 型人材を上手く配置し、組織内で適切にアロケーションし組織運営しているイメージです。 では、エンジニア組織•開発チームを運営するにあたってどちらのクラブチームを参考にするのが良いか考えていきたいと思います。 レアル・マドリード レアル・マドリードはチャンピオンズリーグ優勝回数が欧州で最多のチームです。 なので、1 発勝負の重要な大会やここ一番という試合展開では絶対的な強さを発揮します。この点においてはヨーロッパ１と言って良いでしょう。レアル・マドリードの強さの第 1 は選手のタレント力ですが、臨機応変さも大きな強みです。試合中に核となる選手達が試合状況・展開を俯瞰し、どこで点を取りに行くか、ボールキープをするか、誰にボールを渡せば一番効果的かということを現場レベルで臨機応変に対応できています。現在であればモドリッチ、クロース、ダビドアラバ、ベンゼマなどの選手達です。このような核となる選手を揃えることで、監督のマネジメントが届きにくい試合中であっても現場レベルで問題を解決し、圧倒的な強さを発揮できるのかなと考えます。 このようなチームが向いているフェーズとしては以下のようなフェーズでしょうか。スピーディーかつ高可用性が求められる開発フェーズですかね。まだまだプロダクト運営のルールが決まりきっていない 0->1 のフェーズの開発力でも強さを発揮しそうです。また、中小企業で 1 つのサービスに注力しているな企業の開発にも向いているように感じます。 ベンチャー初期フェーズ プロジェクト立ち上げ時の開発チーム 中小企業での注力サービスの開発•運用 マンチェスター・シティ マンチェスター・シティは世界最高峰のプレミアリーグでここ 5 年間で 4 度の優勝をしています。チャンピオンズリーグと違い、試合回数•対戦相手も多く安定した戦いをすることが求められます。デブライネのような核となる選手は存在しますがレアル・マドリードほど個人に依存することはなく、ローテーションしつつどんなメンバーで試合に出ても一定以上の成績を収めており、ゲームプラン通りに試合展開を進めることを得意とし磐石に勝利するイメージです。一方で、ここ一番での破壊力や試合展開に逆らわず強弱をつけるような試合展開は得意な方ではないです。臨機応変さが少し足りないですね。 このようなチームが向いているフェーズとしては以下のようなフェーズでしょうか。 ルールが整備されてきているプロダクトでのグロースや機能追加、事前のプラン通りにアクションプランを立てていくことが望ましいサービス成長期などで力を発揮しそうです。 サービスグロース期 サービス成長期及び組織拡大時期 上記以外にもそれぞれ向いているフェーズや役割がしっかりありそうだと僕は思います。 個人について ここからは選手個人にフォーカスを当てたいと思います。 今季からマンチェスター・シティに点を取ることに特化した 22 歳のハーランドというバケモノ選手が移籍してきました。この選手はタイプで言えばレアル・マドリードタイプの選手といえると思います。確かに個人成績は素晴らしい反面、リーグ戦でのチーム成績は思ったよりも伸びておらず現在 2 位です。圧倒的な個性を持った選手(I 型の選手)がチームバランスを壊すというのはサッカー界ではあるあるです。(それでも強いですが。)最近移籍したクリスティアーノロナウドも晩年のマンチェスターユナイテッドではこのような立ち位置でした。この事象はイケイケの強強エンジニアをアサインした際にそのエンジニアのパフォーマンスは期待通りだが、他メンバーのパフォーマンスが落ちてしまう現象に近いです。 それでは I 型の選手はなかなかビッグクラブで活躍するのは難しいのかということを考えていきたいと思います。サッカー界で神と呼ばれるイブラヒモビッチはグアルディオラ(マンチェスター・シティの監督)に対して次のようにコメントを残しており、尖りまくっていて、扱いづらいように感じます。 自伝『ADRENALINA』より 「現在のマンチェスター・シティのボスは、マンツーマンのスキルが欠けていると今でも思っている。"哲学者"は、言い返さずに従う選手を好むんだ」 「俺を買うということは、フェラーリを買うということだ」 ただ、このイブラヒモビッチは昨シーズンに長年リーグ優勝から遠ざかっていた AC ミランをベテランかつ精神的支柱としてリーグ優勝に導いています。 サッカーでは若い頃に尖っていた選手が円熟味を増す晩年期にチームの支柱として成績を残すというのはよくあります。今回の W 杯のアルゼンチン優勝のメッシにも似たような臭いを感じます(メッシはそれほど尖ってはいませんが)。ちなみにメッシ、イブラヒモビッチ共にチーム最高齢でした。強烈な個性を持った選手はそれだけカリスマ性も高く、若い選手からもリスペクトされる傾向が強いのでキャリア晩年には若手の牽引や経験からくる試合中の読みでチームを勝たせているイメージがあります。 強強エンジニアは若手時代に同じような強強エンジニアを手本に、ベテラン・シニア時には若い強強エンジニアの個性を殺さずに見守るのが良いのでしょうか。(メッシがロナウジーニョの背中を見ていたように。) ハーランドにはイブラヒモビッチの弟子になってほしいと思いますね。 まとめ エンジニアはスキルがあればという意見が強いですが、自分のパーソナリティに合う環境、一緒に働くメンバーも同じくらい重要な要素です。 レアル・マドリードのような会社であれば技術的なパーソナリティを強くしスペシャリストのような役割を。 マンチェスター・シティのような会社だと技術的強みを生かしつつ多少オールラウンダーな振る舞いが必要そうです。 弊社はどちらかというとマンチェスター・シティ寄りでしょうか。レアル・マドリード的な風土も取り入れて強固な組織にしていきたいですね。 個人的には今回のブログはキャリアを考える良い材料になりました。 最後に 面談でサッカー談義がしたいと思われた方がいらっしゃいましたら、ご応募お待ちしておりますのでよろしくお願いします。 PS: 次は技術ブログを書きます。 ありがとうございました。

はじめに 皆様、こんにちはこんばんは、SREの北浦( @kitta0108 )です。 今回はmedibaの取り組みでLTワークショップを開いたら、 思いのほか大盛況だったため、その取り組みを紹介します。 読者想定 こんな方におすすめの記事にしていくモチベーションで書いています。 medibaの風土が知りたい。 mediba社内LTの発表資料が見たい。 エンジニアの発信力強化を目的とした他社の取り組みを知りたい。 なぜLTワークショップを開こうと思ったのか エンジニア採用事情の課題解決、技術力向上、エンゲージメント向上…などなど、 さまざまな課題からエンジニア自身の発信力につながるような文化を醸成していきたいという気持ちがありました。 出発地点が文化醸成という事から、 大枠として以下の要素を満たすような企画をしたいと考えました。 参入障壁が低いこと 興味関心を引くようなコンテンツであること 実際に体験できるコンテンツであること まず、体験するものに関しては、 エンジニアのアウトプットとしても比較的、参入障壁が低いLTにしました。 また、全員が初めてのLTという前提で、 発表の企画から資料作りまでを1から一緒に作っていくようなワークショップ形式にすることにより、 発表内容のイメージが湧かないような人でも参加しやすいものにしました。 いざ参加者を募集 というように企画案が固まったところで、参加者の募集文を考えるに至ります。 たかが募集文、されど募集文。 ここで人が集まらないとなってしまうと、文化醸成も甚だしく、企画倒れになってしまいます。 なので、ここはおふざけ一切なし、僕らの真剣な想いが伝わる文を投下しました。 僕のアウトプットパワーが最強かどうかはさておき、 想いのある漢達が真面目に考えた甲斐もあって、 17名の参加応募をいただきました。 それにしても、思い返してみれば、仮に参加応募0人だったら僕はどんな心境になったんでしょうね。 きっと3ヶ月くらいの休職期間を必要としたに違いありません。 そう考えたなら、救ってくれた参加者の皆様には感謝しかありません。 ワークショップ1日目 1日目は主にアウトプットを行うことによるリターンはどのようなものがあるのかということと、 プロット作成について話してみました。 これは持論なのですが、LTのようなラフなアウトプットでも、資料作りに打ち込んだり、 当日は緊張しながら発表したりと、それなりに負荷があるものだと思っています。 やりとげた達成感や、その他のメリットをしっかり享受できたら良いのですが、 そのメリットは例えばどんなものがあるのか、それはどうやったら享受できる可能性が上がるのかという話をしました。 あとは発表内容の企画においては、プロットを作成しておくと、 後の工程がグッと楽になるTipsを紹介しました。 資料は こちら です。 ワークショップ2日目 2日目はアジェンダ（というよりストーリー構成）と資料作りの細かいTipsをメインに話しました。 ここのレイヤーは僕自身があまり熱を入れないところなので、 あくまで最低限、発表できるレベルになるまでに知っておくとためになることの詰め合わせのような発表になりました。 （むしろ教わりたいくらいなので、社内で得意な人が突如現れて次回のワークショップ開催されるイベントが期待されますw） 資料は こちら です。 ワークショップ3日目 3日目は、みんなでLT大会するという内容にしまして、 以下のルールを設けました。 1人5分を意識すること（止めないけど） 発表資料はWebにアップロードすること 必ず1つの発表に対して、1人1コメント、ポジティブな内容でチャットに投稿すること 特に3番目のルールは、アンケート結果や参加者のフィードバックとして、 「聴講する側としてもコメントしようと意識して聞くことによって学びが得られた」 「発表したときに周りがコメントしてくれるのが嬉しかった」 という声をいただけたので、設けて正解だったのかなという所感でした。 記述量少ないですが資料は こちら です。 みんなの発表資料 ブログ記事で公開OKいただいた方の資料を掲載します。 発表者 タイトル 資料URL 板谷 誰でも簡単 実質30分でできるYoutubeLive配信のすすめ 資料 retch 闇の魔術に対する防衛術 競技プログラミング編 資料 永原 英語を勉強してみて 資料 井上 不要になったAWSリソースを削除してサービス障害起こした話 資料 下地 良いフィードバックとは 資料 山本（翔） フロントエンドの フレームワーク事情2022 資料 吉澤 VSCode+Vim 資料 kamaboko フロントエンド採用における面接の課題について 資料 堀 バックエンドからフロントエンドにジョブチェンジした話 資料 菅原 新しいNISAざっくり解説 資料 馬淵 Slackでスタンプを押すとBackLogに起票する仕組みを作る 資料 アンケート結果 後の活動に生かすため、アンケートをとっていました。 あくまでmediba内の活動としての回答結果ではありますが、 参考になるようなことがあればと思い、質問事項や実際の回答からの所感も合わせて知見として共有してみます。 主に僕の振り返りをするために設けた項目ですが、 ポジティブ寄りの結果になり、嬉しいですね。 企画自体がよかったのと、発表時に設けたルールによって、 場の雰囲気を和気藹々とできたことが主な勝因だったかなという所感です。 これは新しい発見でした。 次回の機会があるならば、なぜ発信力をあげたいのかという一つ深ぼった話も聞いてみたいものです。 数ある項目の中で、ソフトスキル面の向上というベクトルの意識が高いのは、 同じエンジニアとしても誇らしい限りです。 この取り組みにおける僕と参加者のゴールは、LTに参加する敷居を下げるという点においていたので、 目的は達成できたように感じます。 社内のイベントには登壇していこうかなって意識が芽生えたという意見も嬉しいですね。 難しいヨネー、未だにここの難易度がイージーになるという未来は僕も見えませんw それ相応の負荷を乗り越えて発表してくれているんだというコンテキストを尊重しあっていきたいものです。 勉強になること、フィードバックをもらえること、この2点が良い体験になったようです。 この結果を次回の企画に反映していきたいところです。 意識が高い…！ この経験から活動領域が増えるキッカケになったのであれば嬉しいですね。 この4択であれば、資料や内容の支援が必要とされているようです。 発表する内容の正当さが不安要素が障壁として大きく感じているという結果な気がします。 ここは上司ぴにも相談して、会社としての取り組みとして検討してもらうことにしましょう。 さいごに LTワークショップの取り組みについて紹介しましたが、いかがでしたでしょうか。 medibaの和気藹々とした雰囲気が伝わったり、発表資料の内容や取り組みについて何か持ち帰るものがあったなら幸いです。

こんにちは、データアナリストの左海です。 昨日16日 に引き続き、 mediba Advent カレンダー 17日目は私からサーバーサイドGTM(以下sGTM)を試してみたお話の続きとなります。 前編でsGTMの導入が完了したので、後編ではSafariのITP制限がGoogle Analytics4(以下GA4)のログにどう影響しているのか観察していきます。 SafariのITP制限によるGA4ログへの影響とsGTM まずは、前編の重要な部分を簡単に振り返ります。 SafariのITP制限は主にCookieに対して制限をかけており、JavaScriptで設定された1st Party Cookieの有効期限は7日間となります。 そのため、アクセス解析においては8日以上の間隔を空けて再訪問したユーザーは新規ユーザー扱いとなり、同一ユーザーとしてカウントされません。 上記問題を緩和するのがsGTMで、サーバーサイドでCookieを発行するため、GA4のCookieの有効期限はデフォルトの有効期限に緩和することが可能でした。 観察したいこと 前述の通り、ITP制限のアクセス解析への影響は、8日以上の間隔を空けて再訪問したユーザーは新規ユーザー扱いとなることです。 ゆえに、sGTMを利用した場合、GA4では8日以上の間隔を空けて再訪問したユーザーは同一ユーザーとして計測されるのか観察していきます。 おそらく、同一ユーザーと判定されるため、GA4のデータ探索でユーザー数 1 と表示されるはずです。 観察方法 それでは、観察していきます。観察は以下の手順で行いました。 2022/12/7 13:00ごろSafariで初回訪問し、 page_view イベントを発生させる 2022/12/14 14:00以降にSafariで再訪問し、 page_view イベントを発生させる(8日以上の間隔を空けて再訪問) GA4のデータ探索でユーザー数を確認する 観察結果 GA4のデータ探索で確認したところ、想定していた結果とは異なり、総ユーザー数/アクティブユーザー数には 2 と表示されていました。新規ユーザーとして扱われていることになります。 ユーザー数(想定) ユーザー数(結果) sGTMを利用 1 2 データ探索の設定は、ユーザーセグメントでブラウザをSafariに絞って総ユーザー数/アクティブユーザー数を取得しています。 BigQueryで以下クエリを実行して日付ごとに訪問ユーザーのuidを確認してみました。 SELECT DISTINCT(event_date) ,user_pseudo_id FROM `projectName.datasetName.events_*` WHERE _TABLE_SUFFIX BETWEEN '20221207' AND '20221214' AND device.mobile_model_name = 'Safari' ; 7日と14日で全く別の値が入っているので別ユーザーとしてカウントされています。 考察 観察した結果、当初想定していた同一ユーザーとしてはカウントされず、新規ユーザーとしてカウントされてしまいました。 今回調査に十分な時間を確保できなかったのですが、Webkitの「IPアドレス判定でのCookie制限」が既に適用されているかもしれません。 WebKit will start limiting the lifetime of cookies to 7 days when set via “third-party” IP addresses. Third-partiness determined by whether the first half of the request’s IP address matches the first half of the first-party IP address. 参考 - Steven Englehardt氏 おわりに 今回、sGTMを試してみてCookieへの理解、sGTMやDNSの設定方法など新たに多くのことを知ることができました。 中でもCookieはデータアナリストとして業務を行う上でプライバシー保護の取り組みと併せて最新の情報を理解しておく必要があると感じました。 最後に、今回の観察結果の考察が正しければ、やはりITPがプライバシーを守る取り組みである以上、sGTMでCookie制限を恒久的に回避するのは難しいかもしれません。 どなたかの参考になれば、幸いです。

こんにちは、データアナリストの左海です。 mediba Adventカレンダー 16日目ということで、私からはサーバーサイドGTM(以下sGTM)を試してみたお話についてです。 はじめに 私自身、過去にsGTMを利用したことがなく、理解を深めるためにプライベート環境へ導入してみることにしました。 sGTMに触れる上で切り離せない話題としてApple社のSafariのITP制限が挙げられます。 そのため、今回はsGTMの導入だけでなく、ITP制限がGoogle Analytics4(以下GA4)のログにどう影響しているのかまで観察していきます。 ※本投稿は「sGTMを導入したお話」と「ITP制限のGA4ログへの影響を観察したお話」(明日17日投稿予定)の2部構成となっています。 sGTMとは 初めに、sGTMとはGoogle Tag Manager(以下GTM)のコンテナ種別の「Server」のことを指します。 従来のGTMはタグの処理をクライアント(ブラウザ)側で処理していたのに対し、sGTMを利用することでWebサイト管理者が管理するサーバー上で処理することが可能になります。 今回、タグを処理するためのサーバーはGoogle Cloud Platform(以下GCP)のApp Engineで設置します。 sGTMとApple社のSafariのITP制限の関係 ITPとは、Apple社がSafariに搭載したユーザーの行動データの収集を規制するための機能です。2022/12/11時点でSafariでは主にCookieに対して以下の制限が設けられています。 Cookie 制限内容 1st Party Cookie document.cookie で設定されたCookieの場合 ・Webサイト上でユーザーの操作がない状態でブラウザが7日間使用されると削除される 参照元ドメインが既知のトラッカーである場合 ・URL装飾（クエリパラメータやフラグメント）があるページでは有効期限が24時間に設定される 3rd Party Cookie Storage Access APIを除いてすべてのアクセスを制限 参考 - Cookie Status GA4のCookie( _ga )はJavaScriptで設定された1st Party Cookieとなるため、Cookieの有効期限は7日となります。 (ここでは、参照元URLに、Appleが定義したトラッカーのURLパラメータが含まれる場合は触れません。) そのため、アクセス解析においては8日以上の間隔を空けて再訪問したユーザーは新規ユーザー扱いとなり、同一ユーザーとしてカウントされません。 上記問題を緩和するのがsGTMで、サーバーサイドでCookieを発行するため、GA4のCookieの有効期限はデフォルトの有効期限に緩和することが可能です。 ただ、ITPがプライバシー守るという取り組みであるのでこの方法を継続的に利用するのは難しいかもしれません。現にWebKitは、 「サードパーティ」と判定したIPアドレス経由で設定されたクッキーの有効期間を7日間に制限するようです。 参考 - Steven Englehardt氏 sGTM導入手順 それでは早速、私の個人ブログにsGTMを導入していきます。導入手順は以下の通りです。 サーバーコンテナの作成 GCP(App Engine)とのプロビショニングとカスタムドメイン設定(GTM/GCP/DNS) ウェブ用コンテナ側でのトランスポートURL設定(GTM) サーバー用コンテナ側での初期タグ設定(GTM) 参考 - サーバー用GTMコンテナの初期導入方法まとめ | アユダンテ株式会社 サーバーコンテナの作成(GTM) GTMのコンテナ一覧画面 > コンテナを作成する > Serverでサーバー用コンテナの作成を行います。 なお、通常のウェブ用コンテナも必要ですので準備しておきます。 GCP(App Engine)とのプロビショニングとカスタムドメイン設定(GTM/GCP/DNS) 次にサーバー用コンテナを動かすためのサーバーを準備し、サーバー側のエンドポイントのURLに対してカスタムドメイン設定を行います。 本工程は アユダンテさんのコラム に分かりやすく記載されているので参考にしてみてください。 なお、プロビショニングは設定内容を確認したく「手動設定」で行いました。 添付画像の通り、無事にサーバのデプロイが完了しました。 カスタムドメインの設定も完了しました。 補足ですが、カスタムドメインの設定では、私のサイトドメインを管理しているレジストラの管理画面で「ドメインの所有権の証明」と「サブドメインのDNS設定」の際にDNSのレコード登録が必要になりました。 私はムームーDNSを利用していたのでコントロールパネル > ドメイン管理 > ドメイン操作 > ムームーDNSから設定しました。 ウェブ用コンテナ側でのトランスポートURL設定(GTM) 事前に準備したウェブ用コンテナで計測に必要なタグの作成を行います。今回はGA4の page_view イベントを計測することにします。 添付画像の通りにGA4設定タグを作成し、 All Pages トリガーを紐付けます。 sGTMを利用する場合、赤枠箇所の「サーバーコンテナに送信」にチェックを入れ、サーバー側のエンドポイントのURLを入力します。 すると、GA4ログの送り先はデフォルトのGAサーバではなく、指定のサーバーに変更されます。 サーバー用コンテナ側での初期タグ設定(GTM) サーバー用コンテナでは、ウェブ用コンテナから受信したデータを本来送信すべきツールサーバー(GA)へ飛ばすための設定を行います。 具体的にはウェブ用コンテナに「対応するクライアントが登録されているかの確認」/「対応するGA計測タグの登録」の2つです。 私の場合、対応するクライアントが登録されていなかったので新規作成しました。 詳細設定の「Cookieとクライアントの識別」ではサーバー用コンテナでのGA4計測タグのクライアントIDの保存場所を指定します。サーバー用コンテナが発行するCookieを使用したいため、サーバー管理を選択します。 「JavaScript 管理クライアント IDから移行」にもチェックを入れます。チェックを入れないと、ページ側でJavaScript管理のCookie( _ga )を保持していたとしても、特に気にせず、サーバー管理CookieではクライアントIDが生成されるようです。 次に、サーバー用コンテナでもウェブ用コンテナ同様にGA4の page_view イベントタグを作成します。 トリガーはウェブ用コンテナとは異なり、カスタムトリガーでトリガーの発生場所を先ほど作成したクライアントを設定するため、 Clinent Name が Google Analytics 4 に等しいを選択します。 以上の設定が完了すれば、ウェブ用コンテナからのデータ受信後、サーバー用コンテナで登録されたクライアントが反応してGA4イベントタグが発火され、GA4のログが送信できるようになります。 GA4ログの確認 ウェブ/サーバー用の両コンテナを公開後、想定通りにGA4の page_view イベントが飛んでいるのが確認できました。 これでsGTMの導入は完了です。明日17日も引き続き私からITP制限のGA4ログへの影響を観察したお話についてです。 ぜひご覧ください。

こんにちは。本格的に今年の終わりが見えてきましたが、みなさまいかがお過ごしでしょうか。私は最近毎日ふるさと納税で頂いたツナ缶を食べて過ごしています。マグロの油は頭が良くなるそうなのでしっかり油まで食べてます。 medibaフロントエンドエンジニアでBFFチーム所属兼auスマートパスTCLの 山本（ @yamam00s ）です。 この投稿は mediba Advent Calendar 2022 の20日目の記事です。 この記事では今期取り組んでいる、auスマートパスでのBFFチームのモブワークについてお話させていただきます。 BFFとは？という方については、 去年の私のアドベントカレンダーの記事 をご参考いただければと思います。 BFFチームの選定技術 auスマートパスのBFFではTypeScriptを採用しています。 現在はフロントエンドとチームを分けていますが、将来的にフロントエンドとBFFの垣根を無くすことで、疎結合なアプリケーションの機能実装の一連の流れを1つのチームで完結できようになることを見越しての選定となっております。 フロントエンドはAPIも、BFFチームはViewの構築もできるようになる為の、最初の1歩として言語を揃えて開発していこうという試みです。 BFFチームメンバーと課題について 今までのauスマートパスはバックエンドとフロントエンドでしっかりきっちりチームを分けていたため、 BFFチームを結成した際は下記のような課題を持ったメンバー構成となりました。 私のようなバックエンド開発経験のないフロントエンドエンジニア TypeScript経験があまりないバックエンドエンジニア auスマートパスのドメイン知識が薄いエンジニア ※ あえて課題をメインに書かせていただいています。 BFFという特性上、他チームと比較して特に個人の持つ技術スタックがバラつきやすいのかなと感じました。 モブワークについて BFFチームでは上記で説明した課題を解消するため、1日の半分をモブワークで過ごしています。 基本的にリモートで作業しており、 Gather.Town を使用しています。 全員がオンラインで通話をつなぎコミュニケーションを取り、時には今日の晩ごはんの話をしながら、みんなで1つの機能を実装しています。 とても楽しそうですね モブワークで進める1日の流れ 基本的な1日の流れは下記になります。 10:00~10:30 プロダクト全体の朝会 11:00~12:00 別チームとの共有（トピックのある日のみ） 13:30~16:30 BFFモブワーク 水曜日は燃えるゴミの日だそうです medibaでのモブプロラグラミングへの取り組みについては モブプログラミングはじめました を一読いただければよりイメージがつかみやすいかと思います。 モブワークでのルール モブワークで進めるにあたって、下記のようなルールで進行しています。 意思決定は基本的に全員同意 モブプロのドライバーはメンバーが均等に担当する 実装の方針や機能作成時の一連の流れはモブワークで進める ソロタスク含めPRのMergeもモブワークで進める わからないことは何でも正直に聞く 逆にソロタスクを割り振るようなものは、実装方針をモブで決めたものに絞っています。 モブワークで嬉しかったこと 嬉しいことがたくさんありました。 mainブランチの内容をメンバーが把握している状態を維持できる メンバーごとのコードの品質の差を抑えることができる メンバー全員がプロダクトに詳しくなる 1人では得られない量のナレッジを得ることができる 1人での作業に詰まる孤独から開放される モブワークで作業を進めることで上記のメリットがある他、長い時間をメンバーと過ごすため関係性も深まり、互いにリスペクトも生まれ良い体制だなと個人的に思っています。 今回のチームではリーダーを務めさせていただていますが、他プロダクトを任せていただくときにも同じようなチーム作りができればと考えています。 （もちろんプロダクトの特性によって向き不向きがあるので一概には言えませんが…） 最後に auスマートパスをはじめとするmedibaの様々なプロダクトでは、共に働くエンジニアを募集しています！ 現在、medibaの募集求人ページから応募され入社が決定すると、お祝い金として30万円をプレゼントするキャンペーンを実施中です！！ リモート環境を充実するためディスプレイやマイクを買いそろえるも良し。スキル習熟のために自己研鑽に使うも良し。使途は完全自由です。 【東京本社】エンジニア 募集求人一覧 | 株式会社mediba いきなり応募だとちょっとハードルが高い・・でも興味がある方は、カジュアル面談も行っていますので、まずはお話してみませんか？ 【東京本社】カジュアル面談 | 株式会社mediba ※お祝い金は、試用期間（3か月）を経て、雇用が継続した場合に支給させて頂きます。また、お祝い金は予告なく終了する場合があります。 ご応募お待ちしております！！！

mediba Advent Calendar 2022 と SRE Advent Calendar 2022 の15日目の記事です。 はじめに medibaでSREをしている北浦( @kitta0108 )です。 今回は、JAWS-UG SRE支部やNRUG SRE支部の設立に至るまでの裏側の話を雑に語っていこうと思います。  先にお断りしておくと、何かしらの知見を得られるようなものにはなっていない気がしていましてw ユーザーコミュニティの立ち上がりってどんな感じなのかというベクトルから、 読み物としてお楽しみいただくようなコンテンツになるよう意識しています。 なんなら、これをきっかけにエンジニア界隈のユーザーコミュニティ活動に 興味をもってくれるような人が出てきたら、この上なく嬉しい気持ちになる気がします。 そんなモチベーションで頑張って書いていきます。 JAWS-UG SRE支部設立のきっかけ ことの発端は、弊社にはslackにtimesチャンネルを作る文化があるのですが、 その場でJAWS-UGにSRE支部あったらいいのになーとぼやき始めたところになります。 この時点では95％くらいの冗談寄りで設立しちゃおっかなみたいなことを言っていますね。 元々、弊社の課題感として、 AWSの各リソースを使ってSREのプラクティスを実践していくという事の関心や、 社外の方との意見交換を欲していたこともあり、そのせいもあってか、 社内からは設立に関しては後押しされる声をいただきました。 追い風のように、社外の親しくさせていただいているエンジニアや、 1on1にお付き合いいただいているメンターからも、ポジティブな声をいただくなどして、 いよいよもってして、本当に設立しちゃおっかなという気持ちの昂りがあったことを今でも覚えています。 設立の決断 この時点で、設立に関して、かなり前向きになっている状態なので、 日頃の発言も設立に関することが多くなっていたような気がします。 そんなこともあってか、弊社の板谷さん( @mary_tuba )が ホントにやるなら手伝うよと声をあげてくれたり、 当時、New Relicの技術コンサルとして支援いただいていた瀬戸島さん( @tossi_104 )との雑談から あんどぅさん( @integrated1453 )を紹介いただいたり、 元、弊社でSREチームのマネージャーをしていた沼沢さん(Twitterやってないヨ)にも手伝ってもらうことになったり、 あれよあれよと運営メンバーが集まることになりました。 幸いにも、日頃からJAWS-UGの出入りが多かったメンツだったこともあり、 設立の手筈なども、もたつくことなくコミュニケーションがとれ、そして設立宣言に至ります。 緊張の第一回目開催 非常に嬉しい誤算なのですが、 当時、参加者数50人集まったらいいよねみたいな話をしていた矢先、 まさかの430人集まるという事態になりました。 やっぱりみんな、SRE支部欲しかったんだなと改めて感じたのと本当に設立してよかったと思う瞬間でした。 話はじめてしまえばどうということはないのですが、 開始10分前とかは、緊張しすぎて小鹿のように足を震わせてた思い出ですw そんな第一回目は以下からアーカイブ視聴が可能なので、よかったらみてやってください。 SRE支部第一回目アーカイブ 反響もよく、アンケート結果はもちろん、 個人としても、他のSRE界隈のコミュニティでもSRE支部で取り上げた内容の参照がされていたり、 有意義なコンテンツを提供できた手応えを感じました。 余談ですけど、いただいたアンケートは穴が開くほどよくみているので、 勉強会に参加された方でアンケート求められたら、運営している方のためと思って協力してあげてください。 泣いて喜ぶことになるでしょうw そして、運営メンバーもこのタイミングで4名追加になって一気に華やかになりました。 ユーザーコミュニティというと、勉強会の開催をメインにやっていく集まりのように見えるかもしれませんが、 割と普段から技術面の意見交換だったり、時には恋バナ?wなどでも盛り上がれる最高のメンバーで構成されてます。 ちょうど昨日、SRE支部運営メンバーで今年の成果報告会やろうぜなどといって、 お互い発表しあって楽しい時を過ごすなどをしましたw 今のメンバーと取り組みはこんな感じです。 NRUG SRE支部設立のきっかけ JAWS-UG SRE支部設立から時は経ち、 一方で、SRE業務の関心軸として、開発者体験の向上やサイト信頼性向上といった文脈から、 o11y導入のモチベーションが高まっていました。 そんな中、NRUG Vol.0の懇親会にお邪魔した際に、 清水さん( @photographed )からNRUGでもSRE支部設立どおっすか？と お声かけいただく機会がありました。 その後、NRUG Vol.1に登壇させていただき、その際の資料にNRUG SRE支部一緒に設立したい人募集！と軽い気持ちで一文書いておいたところ、 Tocyukiさん( @Tocyuki )とkazumaxさん( @kazumax55 )が 手をあげてくださり、その場でのいきおいwで設立することになりました。 ドキドキの第一回目 JAWS-UGのときもそうだったのですが、第一回目の開催前は、 コミュニティの意義、参加想定者、僕らは何に貢献していくのか、などを整理していく過程を踏んでいくことになります。 その整理にいたっては、 運営3名 + New Relicさん側から、大平さん( @joe_yuzupi )と清水さんのサポートがあり、 手前味噌ながら、高い完成度の指針を作り込めた気がします。 そんな中で迎えた第一回目のテーマは「俺たちのNew RelicとSRE」です。 参加者数も192名と、当初想定のおおよそ4倍近い方々からの参加をいただきました。 SNS上の拡散などで応援してくれた方々も多かったので、その点は大変に感謝です。 そんな皆様のご支援もあってか、JAWS-UGと同様、参加者は思ってた以上に集まり、ォィォィZoomの参加可能枠超えちまうよみたいな謎テンションの心配事をした記憶がありますw 運営3名がちょうどSREのフェーズ感が違っていたというのと、 それぞれが発表できそうなネタがあるということで運営3名が登壇したのですが、 こちらもアンケート結果や当日のTwitterの賑わいなどからも、手応えとしてグッとくるものがありました。 NRUG SRE支部 Vol.1アーカイブ o11yとSREは親和性の高さを感じるものがあり、 今後も継続して良質なコンテンツを提供できるように頑張っていきたいものです。 まとめと所感 思ってた以上に、自分ごとを書き連ねてしまった反省はあるのですが、 いかがでしたでしょうか。 思い返してみれば、コロナ禍という向かい風があった中でしたが、 たくさんの人に支えあって、やりとげられたことのような気しかしません。 運に極振りしたような人生ですねw 色々と書きましたが、「ユーザーコミュニティは参加するのも運営するのもいいゾォォ。」 こんな雰囲気が伝わったならいいかなと思います。 ちょっとだけ宣伝 各ユーザーコミュニティのリンクです。 興味ある方は是非Watchいただけると嬉しく思います。 JAWS-UG SRE支部は次回1月開催 NRUG SRE支部は次回2月開催・・・ができたらいいなという温度感で取り組んでいます。 JAWS-UG SRE支部 NRUG SRE支部 本件とは別のコミュニティですが、北浦個人として以下のコミュニティ運営も携わらせていただいてます。 JAWS-UG コンテナ支部 Tech-on 2022/12/20はコンテナ支部#22 re:Cap会やります！ リモート参加もOKですし、現地ではBeer Bashをやります。飲もうぜ！！ JAWS-UGコンテナ支部 #22 re:Cap

New Relic Advent Calendar 2022 の12日目の記事となります。 はじめに どうも、こんにちはこんばんは、SREの北浦( @kitta0108 )です。 今回はNew RelicのSynthetics機能を使ってE2Eテストを実装したら思いの他、 簡単且つ、痒いところによく手が届く印象でしたので、 その知見を共有します。 この記事を読んだら、E2Eテストを実装したくなっちゃうに違いない!? そんな熱量でお届けしていきます。 読者想定 こんな方におすすめの記事にしていくモチベーションでおります。 外形監視の実装方法の選択肢を広げたい ブラウザベースのE2Eテストの実装方法を知りたい。 より一層New Relicに魂を売りたい。 対象の機能 New Relicのマネジメントコンソール上では、以下からアクセスできる機能です。 お題 解説の便宜上、以下のようなログイン画面の例を使っていきます。 ■実装したいシナリオ ログイン画面にアクセスする。 ユーザーIDを入力する。 「次へ」ボタンをクリックする。 パスワードを入力する。 「Log In」ボタンをクリックする。 ログインユーザー名の表示が指定の文字列であることを確認する。 実装方法 まずはSynthetics画面からCreate monitorをクリックします。 monitor typeの選択画面に遷移するので、今回は「User step execution」を選択します。 Zero code monitor buildingって書いてありますね。フレーズが素敵ですw Creater monitor画面に遷移します。 なんのテストなのか、名付けしたり、実行間隔の設定をします。 後述しますが、「Enable screenshot on failure and in script」にはチェックを入れておくと、後々捗ります。 お次はSelect locationsの設定です。 外形監視として、どこのLocationからの疎通をTryするのかという設定ですね。 今回は日本国内からの疎通が取れればOKというアプリケーション要件なので、Tokyo、JPだけにチェックを入れます。 ここからが主題の設定です。 以下がお題の完成形でして、画面右部の1 ~ 6のStepで処理が実行されます。 詳細は別セクションで解説します。 Define stepsの各種設定項目 Navigate どこのURLへアクセスしにいくのか設定します。 Advanced OptionsによってUser-Agentの指定も可能です。 Type Text 要素をXPathで指定し、入力する文字列を設定します。 Click Element 要素をXPathで指定し、画面上でクリックさせる設定をします。 Secure Credential 要素をXPathで指定し、機密情報を入力する設定をします。 New Relic上で機密情報を扱う際には、Secure Credentialという機能を使って、情報を保存します。 基本的なところではありますが、機密情報の扱いはベタのTextベースで扱わないように日々気をつけていきましょう！ Assert Text 要素をXPathで指定し、表示されているTextが指定の文字列と一致しているか確認します。 Equals以外にも以下の選択肢があります。これだけ揃っていれば不便な思いはしないで済みそうですね。 各種Tips XPathの取得方法 Google ChromeのDeveloper Toolを使ってCopyが可能です。 Fail時のScreenShot機能 Results画面に遷移すると以下のように疎通結果ログの回覧が可能です。 その中で結果がFailであったものの詳細をドリルダウンしていくと、疎通時の描画状態をScreenShotとして回覧が可能です。 これは超絶便利ですよね。 以下はAssert Checkでわざと違う値を設定した例です。Assert結果が違うって指摘もちゃんと出てますね。(ぼかしが多くてスミマセン！) おわりに New RelicというとAPMのイメージが強いかと思いますが、今回は毛色を変えてSynthetics機能を紹介してみました。 E2Eテストしてみたい！もっと品質良く、且つ高速なフィードバックによる開発体験の向上したい！などの文脈で取り組んでみてはいかがでしょうか。

この記事は mediba Advent Calendar 2022 の12日目にエントリーされた記事です。 はじめに 株式会社medibaの @zuuundayo と申します。テクノロジー統合UNIT内のSREチームのメンバーです。 Advent Calendar向けの良いネタがあまり思いつかなかったので 個人で時系列データベースを触ったことを共有します（ちょっと今更感ありますが）。 時系列データベースとは 雑に説明すると時間と値の組み合わせデータ（時系列データ）を対象としたデータベースです。 リレーショナルデータベースなどもこのようなデータの取り扱いが可能ですが、 特化したデータベースが作られているのには理由があります。 IoT製品のセンサーから観測されたデータなどはリアルタイムに利用されたりするので絶え間なくデータが送り続けられて来たりします。 このような状態で取りこぼさずにデータを格納したり、時間や値を元にデータを素早く引っ張り出す機能にニーズがあるためです。 IoTが幅広く普及してきた近年では、Amazon Timestreamなどのマネージドな時系列データベースも登場したりしています。 なんで触ろうと考えたのか 個人でリアルタイムに投票するシステムを作ろうと考えました。 RDBを採用すると汎用的な用途ゆえ機能が多すぎてオーバースペックな気がするし、 シンプルな形でデータを簡単かつ高速に集計する仕組みが良かったので時系列データベースを採用してみることにしました。 InfluxDBとは InfluxDB https://www.influxdata.com はオープンソースな時系列データベースです。 いろいろな方が性能や使い勝手を比較されていますが それらを参考にお手軽に利用できそうだなと判断して採用しました。 他の時系列データベースはRDBの拡張モジュールだったり、有料だったりしたので お手軽感のあるこちらを選んでます。 InfluxDBにはマネージド版のInfluxDB Cloudが存在しており、なおかつFreeプランが存在しているため 個人での利用に嬉しいメリットがあります。今回はマネージド版のFreeプランを使ってます。 セットアップ InfluxDBのサイトからInfluxDB Cloudの会員登録を行います。登録すると管理コンソールにアクセスできます。 まず最初にBucketsメニューでBucketを作成します。BucketとはRDBのテーブルみたいなものでデータを放り込む場所になります。 Create Bucketボタンを押すとメニューが出てくるので名前とデータの有効期限を設定します。 Advanced ConfigurationではBucket Schema Typeを選べます。今回はImplicitを選びます。 Implicitを選ぶとSchemaが暗黙的となりSchemaが強制されません。 Explicitを選ぶとSchemaが強制されるので形式があっていないデータは格納できなくなります。 ただし、一度スキーマを設定するとあとからカラムを変更できず新規追加しかできないそうなのでご注意を。 利用方法（簡易的に試す方法） 結構親切に体験する方法を教えてくれるのであまり書くことないですが、注意事項等書いておきます。 バケットが作成できるとバケットの一覧から作成したバケットの欄のADD DATAボタンをクリックします。 クリックするとメニューパネルが出てくるのでClient Libraryをクリックします。CSV Uploadなどのボタンもあるのでからもデータをインポートできるようです。 Client Libraryをクリックすると様々な言語が出てくるのでお好きな言語をクリック。ここではPythonを選びます。 ページを移動すると親切にウィザード形式でセットアップ方法を指示してくれます。 まずはローカルにクライアントモジュールをインストールします。 pip3 install influxdb-client 次にトークンを発行し環境変数に追加するよう指示されます。 ウィザードで自動的に発行されたトークンはすべての権限が付与されたものになるので非推奨であるそうです。実際に利用する際はAPI Tokensのメニューから特定のバケット等に権限を絞ったトークンを発行して利用しましょう。 クライアントの初期コードが出てくるので指示通り、Pythonのインタプリタにコードを入力する。 続いて今回作成したバケットにデータを送信するコードが出てきます。今回作成したバケットを選択するとコードも自動的に修正してくれます。 ここでのコードは0から4までの値を1秒おきに送信するコードです。 下の欄にデータが取得されたかを確認するボタンがあるので、確認してみてください。うまく行ってると"Connection Found!“と表示されます。 次の画面では送信したデータをFlux Queryで確認する方法が表示されます。管理画面のData Explorer上でもクエリ叩けますがPython上で叩くコードも表示されます。 うまく行ってると下記のように時系列データが表示されます。Data Explorerで表示させると画像みたいな感じです。 利用してみての感想 Cloud版はマネージドなだけあってセットアップを簡単に行うこともできましたし、 APIのリファレンスなどのドキュメントも分かりやすい方なので使い勝手は良いです。 何よりシンプルな設定でサクッと時系列データをとりあえず保管して可視化するには便利なので皆さんも利用してみてはいかがでしょうか。 現在はそこまで大きなワークロードで活用しているわけではないのでデメリットは使っているうちに見えてくると思います。 ここには書いていませんがFlux Queryは監視ツールなどによくある時系列データに対する様々な集計関数があったりするので使ってみると面白いですよ。 終わりに 個人的な試行をAdvent Calenderにしてしまいましたが、決して会社の中で何もやっていないわけではないですという言い訳をしておきます（汗）。 微妙にネタかぶりしてしまったんです。はい。 今弊社のSREチームでは、絶賛メンバーを募集しております。 チームメンバーには業務だけでなくプライベートでも様々な活動されている方々もいらっしゃるので雰囲気を知りたい方はお気軽にお問い合わせください ( https://hrmos.co/pages/mediba/jobs/1100000001 )。 最近はフルリモート勤務での採用も開始してます！