こんにちは、インフラエンジニア の 森田です。 この記事は Enigmo Advent Calendar 2025 の4日目の記事です。 BUYMA は8月に本番環境を移行しており、その後コストのチューニングを行っています。 この記事では実際に進めた内容を元に自分の AWS におけるコスト削減の考え方と役立つ機能について紹介します。 サマリ まず最終的なゴール設定ですが、 リザーブ ド インスタンス やSavings Plans等利用量をコミットしてコスト削減を行えるモデルの購入とします。 また今回は分かりやすいよう主要なサービスであるEC2とRDSでのコスト削減をターゲットとします。 大枠では次のような流れで AWS のコスト削減を考えています。 サイジングを考える 利用状況の変化を考える コストコ ミットを考える 次項からそれぞれで検討すべき項目と、それに利用できる AWS の機能を紹介します。 1. サイジングを考える まずその インスタンス に適切なリソースが割り当てられているかを考えていきます。 AWS のような従量課金のサービスにおいて一定のタイミングで現在の状況にあったリソースが割り当てられているかを考える事は重要です。 利用状況を超えたリソースの割り当ては余計な支出を生みますし、リソースが不足していればサービスの安定稼働の妨げとなってしまいます。 そのため インスタンス タイプを適切に割り当てたいなと思うわけですが、種類が多すぎて何が適切なのかの検討が難しい場合もあります。 そこで参考にできるのが AWS Compute Optimizer です。 Compute Optimizerは 機械学習 を用いて AWS リソースの利用状況を分析し、コスト削減やパフォーマンス向上に繋がるレコメンドを提示してくれるサービスです。 画像のようなイメージで インスタンス ごとに適切か否か、否なら何が適切かを提示してくれるのでサイジングの参考にして下さい。 ただ注意しないといけないのはこれはあくまでオススメする インスタンス タイプであり、動作の保証はされないという事です。 肌感覚ですが、カスタマー利用があり負荷が一定でないWebやAppサーバ等でこのレコメンドの通りにサイジングを行うのはかなり危険だと思います。 実際にコスト削減のため アプリケーションサーバ の インスタンス タイプをレコメンドよりも一回りバッファを持たせたサイズへ下げたものの、高負荷となってしまうケースがありました。 この時は1台だけ下げた インスタンス を組み込むという計画だったため即切り戻しが可能でしたが、やはり負荷の一定でない インスタンス の変更は慎重に行うべきであるということです。 逆に社内サービス等負荷がおおよそ一定になる用途のものに関してはかなり参考にできるかなと思っています。 2. 利用状況の変化を考える 次にその インスタンス の利用状況の見通しを考えましょう。 AWS の コストコ ミット類の最小期間は1年であるため、1年程度見通せると良いかと思います。 大まかには以下の点を検討する形になるかと思います。 この用途の インスタンス は向こう1年以上利用するか 1年以内にOS、DBエンジンのEOS・EOLが発生するか OS、DBエンジンのEOS・EOLは Health Dashboard などが参考にできます。 OSやDBエンジンのバージョンは リザーブ ド インスタンス やSavings Plansで縛られないものの、 バージョンアップ後に負荷が上がる可能性はあるので、もし1年以内に発生する場合は インスタンス タイプの変更含めて検討が必要です。 3. コストコ ミットを考える リザーブドインスタンス EC2でも リザーブ ド インスタンス を購入することは可能ですが、 インスタンス ファミリーやOSの変更にも対応できる柔軟性を考慮すると、EC2には後述するSavings Plansを利用するのを推奨します。 そのため、ここでのターゲットは主に RDS とします。 ※ただし直近でRDSのSavingsPlansもGAとなっているため、今後はこちらも合わせて検討するのが良いと思います。 RDS RI購入の考え方 RDSの台数が少なければ、前述の検討内容を元に手動で個別に購入して問題ありません。 しかし、台数が多い場合は AWS コンソールの推奨機能を活用します。 Billing and Cost Management > 予約 > 推奨事項 ここでも「1. サイジング」と「2. 利用状況の変化」での検討が重要になってきます。 単に現状の通りにRIを購入するのではなく、無駄なリソースを排除し、EOS対応などの将来的な再構築リスクがないことを確認した上で推奨事項を見ることで、 「推奨＝購入すべき正解」 という状態を作り出せるからです。 インスタンス サイズの柔軟性について また、RDSのRI購入を後押しする要素として 「 インスタンスサイズの柔軟性 」 があります。 MySQL 、 MariaDB 、 PostgreSQL 、 Oracle 、Aurora を利用している場合、同じ インスタンス ファミリー（例: db.r6g ）内であれば、サイズ（ large や xlarge 等）が変更されてもRIの割引が適用されます。 ( ライセンスを含む場合は柔軟性の対象外となる点 に注意して下さい) これにより、「今は db.r6g.large が適切だが、半年後に負荷が増えて db.r6g.xlarge にスケールアップするかもしれない」といったケースでも、RIが無駄になりません。 この仕様があるため、ファミリー自体の変更（例: r6g → r7g ）さえ発生しない見通しが立っていれば、比較的安心して1年/3年のコミットを行うことができます。 不要なリソースは削除済み、かつ将来のファミリー変更リスクも検討済みであれば、推奨事項に表示されている台数・期間で購入を進め、割引効果を最大化させましょう。 Savings Plans EC2に関しては、 リザーブ ド インスタンス よりも柔軟性が高い Savings Plans 、その中でも Compute Savings Plans の利用を推奨します。 Compute Savings Plansであれば、 インスタンス ファミリー、サイズ、AZ、リージョン、OS、テナンシーが変わっても割引が適用されるため、構成変更に非常に強いのが特徴です。 こちらもRDS同様、 AWS コンソールで推奨事項を確認できます。 Billing and Cost Management > Savings Plans > 推奨事項 ここで前項までの「1. サイジング」と「2. 利用状況の変化」の検討が活きてきます。 通常、この推奨事項は過去の利用実績に基づいて算出されるため、無駄なリソースが放置されている状態で見ると、過剰なコミット額が提案されてしまいます。 しかし今回は、既にサイジングで見直しを行い、将来的な利用期間（1年以上など）も精査済みです。 つまり、 現在稼働しているリソースは「必要なリソース」のみに絞り込まれている状態 と言えます。 そのため、ここでの戦略はシンプルです。 Compute Savings Plans を選択する 期間は「利用状況の変化」で確認した期間（基本は1年）を選択する 表示された推奨事項の 時間単位のコミットメント を信頼して購入する 事前にしっかりとリソースの棚卸しができているからこそ、迷いや過度なマージン（ リスクヘッジ による減額）を入れることなく、提示された最適解で購入を進めることができます。 これが結果として、無駄なく最大のコスト削減効果を生むことに繋がります。 まとめ 今回は「サイジング」「利用状況の変化」「 コストコ ミット」の3ステップで進める AWS コスト削減について紹介しました。 コスト削減というと、どうしても「とりあえず リザーブ ドやSavings Plansを買う」という手段が先行しがちですが、その土台となるシステムの見直しや将来予測が不十分だと、効果が薄れたり逆に無駄が発生したりするリスクがあります。 今回紹介したように、しっかりと足元（現状の利用量）と未来（これからの構成）を整理した上で AWS のレコメンド機能を活用すれば、迷うことなく最大限のコミットメントが可能になります。 インフラコストの最適化は、一度行えば終わりではなく継続的な運用が重要です。 ぜひこの機会に、皆様の環境でもCompute Optimizerや推奨事項をチェックし、攻めのコスト管理にチャレンジしてみてください。 明日の記事の担当は データアナリストの 井原さんです。お楽しみに。

はじめに こんにちは、SE本部の加藤です。現在はインフラグループに所属し、 BUYMA の AWS 基盤を運用しています。 この記事は Enigmo Advent Calendar 2025 の 1日目の記事です。 背景課題 BUYMA の AWS 運用を続ける中で、RDSのバージョンアップ作業等で取得した手動スナップショットが、複数の AWS アカウントに作業後も削除されずに残留しており不要なストレー ジコス トを生んでいました。 スナップショットを自動削除するためのマネージドサービスの機能がないか調べてみたものの、今回の要件に当てはまる機能は存在しないようでした。 そのため、 複数アカウント のスナップショットを一括で監視し、通知する仕組みを作成することにしました。 システム構成 本監視システムは、 親アカウント に主要なリソースを集約し、 クロスアカウントアクセス によって子アカウントの情報を取得する構成です。 システム全体は CloudFormation で管理され、主に以下のリソースで構成されています。 概要 親アカウントのLambdaをスケジュール実行し、クロスアカウントで子アカウントのRDS手動スナップショットを取得する構成です。 作成から一定期間経過した古いスナップショットを検出してSlackに通知します。長期保存対象となる管理用タグも設定しています。 主な AWS リソース リソース種別          説明                                                            CloudFormation  ECR リポジトリ 、Lambda、EventBridge、Secrets Manager、IAMロールなど全リソースを管理。 Lambda関数        コンテナイメージとしてECRに格納。スナップショット検出とSlack通知を実行。                      ECR              Lambdaで使用するコンテナイメージの リポジトリ 。                                    EventBridge      定期スケジュールでLambdaを起動。                                            Secrets Manager Slack Bot の認証 トーク ンを管理。                                        IAMロール（子アカウント）  親アカウントのLambdaがAssumeRoleするためのロール。RDSスナップショット読み取り権限を付与。    処理の流れ 本仕組みは、以下の手順で動作します。 1. スケジュール実行とクロスアカウントアクセス EventBridgeによるスケジュール実行 （毎月1日午前9時）でLambdaが起動します。 起動した親アカウントのLambdaは、子アカウントに設定した IAMロールをAssumeRole し、 クロスアカウントでスナップショット情報を取得 します。このロールは rds:DescribeDBSnapshots などの必要な権限を持ち、 複数アカウント の監視を可能にします。 2. 不要スナップショットの検出とタグによる除外判定 取得したスナップショットに対し、以下のロジックで削除候補を抽出します。 経過日数による抽出 : 7日以上経過した手動スナップショット を抽出します。 タグによる長期保存管理 : 手動スナップショットに SnapshotRetain: true タグが付与されている場合、長期保存対象として Slack通知内で「保持対象」として表示 します。これにより、必要なスナップショットの誤削除を防ぎます。 3. コストの推定計算 検出されたスナップショットに対して、その推定ストレー ジコス トを計算します。 料金計算ロジック : スナップショットごとにストレージサイズとエンジン種別（Auroraかどうか）で単価を切り分けています。 Auroraは1GBあたり0.023 USD 、 その他RDSは0.095 USD を料金の目安にしました。（※Auroraはサイズが出し辛く、デフォルト10GBを設定） 全スナップショットの合計推定コストを計算し、Slack通知に含めることで 不要スナップショットのコスト影響を視覚化 します。 4. Slack通知 抽出したスナップショット一覧、推定コスト、およびエラー発生時はその詳細を Slackへ通知 します。Slack通知に利用する Bot トーク ンはSecrets Managerで安全に管理されています。 Slack通知例 スナップショット検出時 対象なし時 実行エラー時 まとめ これまで、不要なAuroraやRDSの手動スナップショットの削除忘れにより、全アカウントを合計すると、数万円単位のストレー ジコス トが毎月発生していました。 本仕組みの導入により、これらの古いスナップショットを定期的に自動検知し、Slackに通知することで削除忘れを回避することが可能になりました。 結果として、不要なストレー ジコス トの削減が実現し、無駄な支出を抑制できました。 明日の記事の担当は 人事総務グループ の 廣島 さんです。お楽しみに。 株式会社 エニグモ 正社員の求人一覧 hrmos.co

国内最大級の海外ファッション ECサイト 「 BUYMA （バイマ）」を運営する エニグモ 。 今回は、エンジニア組織を支えるエンジニア リングマ ネージャーとして、プロジェクト推進からメンバー育成まで幅広く携わる穴澤さんにインタビューしました。これまでのキャリアや エニグモ に入社した経緯、現在の役割、そして「 BUYMA 」の開発に携わる魅力について伺いました。 これまでのキャリアと エニグモ に入社した経緯を教えてください 前職では、オンライン英会話サービスを開発する会社で Webサービス 開発チームのリーダーを務めていました。 サーバーサイドエンジニアとして英会話レッスンの予約システムや決済機能のメンテナンスからスタートし、その後はシステムの刷新やサービスの拡大期にチームリーダーとしてチームをまとめる役割を担うようになりました。 スマホ 向けの新規事業の立ち上げや、海外子会社で講師向けシステムを開発するなど、本当に多様な経験を積むことができました。 7年間の経験を通じて「やり切った」という手応えを感じる一方で、次はより大きな組織の成長に貢献できる環境で自分のマネジメント経験を活かしたいと考えるようになりました。そんなときに出会ったのが エニグモ です。 面談や選考で話を伺ううちに、ここなら自分の強みを活かし、組織づくりにも携われると感じ、入社を決意しました。選考の中で多くのエンジニ アメンバー と直接話せたことも、とても印象に残っています。 実は エニグモ に入社する1年前に一度縁があり内定が出ていたのですが、当時は転職のタイミングを見直すことにし、辞退していました。改めて転職を考えているタイミングで エニグモ の人事部長から再度声をかけていただき、入社した経緯があります。 現在の 「 BUYMA 」のエンジニア リングマ ネージャーとしての役割を教えてください 現在はエンジニア リングマ ネージャーとして、大規模プロジェクトの推進やメンバーのフォローアップ、組織づくりと幅広く関わっています。 BUYMA の開発組織は「BUY（購入者向け機能）」「SELL（出品者向け機能）」「SERVICE INFRA（決済や配送などの基盤機能）」の3つの ドメイン に分かれています。 ドメイン はエンジニア・デザイナー・ディレクター・データアナリストなど職能横断チームで、私はその中で ドメイン ヘッド（Domain Head）として、ビジネス側との折衝や全体のマネジメントを担っています。各 ドメイン はミッションの近い複数のSquad（開発チーム）の集合体であり、チームごとにKPIを設定し、事業やユーザーの課題解決に向けたプロジェクトを進めています。 プロジェクトの推進については、大小様々な案件で、多くの関係者が関わる複雑なプロジェクトに関わることが多いです。 ※ エニグモ では、大型セールや複数の領域（ ドメイン ）にまたがる大規模開発のような施策は、部署を横断する全社的なプロジェクトとして推進しています。 実際の開発は、基本的に各担当のエンジニアに任せていますが、プロジェクトを迅速に進める中で意見が滞りがちな場面では、「いつ、誰が、何を、どこまでやるのか？」を明確に整理し、進行をサポートする役割を担うこともあります。 また、 プレイングマネージャー として、自らも手を動かす場面を持つようにしています。そうすることで組織全体の ボトルネック や開発メンバーの抱える課題を肌で感じることができます。自分も開発しながら組織全体のことを見るというバランス感が、 エニグモ のエンジニア リングマ ネージャーの面白さだと感じています。 それ以外にも、チームメンバーとの1on1や目標設定といったマネジメントも行っています。日々の業務やコミュニケーションを通じて、メンバーそれぞれの特性や志向性を把握し、その強みを活かせるよう意識しています。「こうすればもっと良いエンジニアになれるんじゃないか」「このスキルを活かして、次のプロジェクトでこんな仕事ができると良いね」といったことを一緒に考え、キャリア形成のサポートも大切な仕事だと捉えています。 マネージャーとして、コミュニケーションやチーム運営で心がけていることはありますか？ メンバー自身が、自律的に考えて行動できる組織にするためのコミュニケーションを心がけています。 プロジェクトの方向性を決める際や、メンバーからの相談を受ける際には、マネージャーの中で「こう進んだ方が良い」という結論を初めから伝えすぎないようにしています。もちろん、自分で考えて適切な結論にたどり着くための情報のインプット等のサポートはします。 入社した当時、 エニグモ は組織として大きく成長しようとしており、採用を本格化していく時期でした。当時は採用に関わるエンジニアが限られていたため、組織として人を採用し、育成していく仕組みが必要だと感じていたため、そこで、私自身も積極的に採用活動に関わらせてもらうようになりました。 組織づくりの一つとして、若手や新卒メンバーに対しては、入社初期からメンター制度を取り入れています。 メンターと新メンバーが毎朝ミーティングを行い、進捗の共有だけでなく、悩み相談や雑談を交えられる仕組みになっています。週次でのふりかえりを通して「できたこと」「学んだこと」「次に挑戦したいこと」を整理する機会も設けています。経験の浅いメンバーもメンター制度を通して入社後1年程で独り立ちして、プロジェクトを回し始めているような人材へと成長しています。メンバーの成長というのは個人の資質や頑張りによるもので、あくまでもメンター制度はそのお手伝いであると思っています。 新メンバー全員に共通しているオンボーディングの取り組みとしては、チームのマネージャーが 開発プロセス やリリース手順、組織構成の話などを入社日に直接会ってお話ししています。その後、最初は簡単なタスクを担当しながら、チームの朝会やSlackで質問などを気軽にできる体制をとっています。 ※メンタリングについてはこちらの記事で詳しく紹介しています。 開発部門のメンタリング体制 - エニグモ開発者ブログ これまでの経験が活きていると感じる場面はありますか？ 前職での多様な開発経験と、組織づくりへの興味が、今の仕事に直結していると感じます。 システム刷新や新規事業の立ち上げを通して、技術だけでなくプロジェクト全体を俯瞰する力を養えたことは、 BUYMA のような大規模サービスの開発プロジェクトの推進でも活きていると感じます。 また、入社時に「組織の成長に貢献したい」という思いがあったため、採用や育成といった組織づくりに積極的に関わることができました。 エニグモ はスタートアップのようなスピード感と、上場企業としての安定性が共存している珍しい環境だと思います。 「 BUYMA 」の開発に携わる魅力を教えてください エニグモ でエンジニアとして働く魅力は、ビジネスサイドとの距離の近さと、20年続く大規模サービスならではの技術的な挑戦の両方を追求できる点だと思います。 まず、ビジネスサイドとのコミュニケーションが活発です。 BUYMA の事業チームのメンバーは技術 リテラシー が高く、「これを作ってほしい」という依頼ではなく、「どうすればこの課題を解決できるだろうか？」という形で議論が始まることが多いです。 エンジニアもプロダクトの成長を一緒に考えるビジネスパートナーとして、開発の実現可能性だけでなく、「開発目線」で本質的な解決策を提案し、要件定義から深く関与することができます。 さらに、 BUYMA のエンジニアはユーザーとの距離が非常に近く、フィードバックをダイレクトに受け取れる点も魅力のひとつです。 ユーザーの声をもとに改善を重ねていくプロセスは、他の業種ではなかなか得られない貴重な経験です。 そして何より、 BUYMA の開発には20年続く大規模サービス特有の難しさと面白さがあります。 BUYMA はグローバル規模で運営されており、サービスを1秒たりとも止めることができないシビアな環境下で改善・開発を進めています。 この環境で得られる「大規模 トラフィック の中で本質的なスキルを磨く経験」は、スキルを磨きたいエンジニアにも最適だと思います。 また、ユーザー数が多いため、施策の効果が数値として明確に現れます。新機能をリリースした直後にABテストやデータ分析を通して成果を検証でき、短いサイクルで開発と改善を繰り返せる環境があります。 トラフィック 量も大きく、データ構造も複雑なため、スケーラビリティやパフォーマンスチューニングなど、高度な設計・運用力を磨き続けられる環境です。 開発の手応えをすぐに感じながら、自分たちの手でプロダクトを進化させていける実感が持てるのは、 BUYMA ならではだと思います。 エニグモ ではエンジニアとして、どのような経験やスキルを身につけたり、キャリアを積むことができますか？ エニグモ には、エンジニアの 「事業・プロダクト志向」「技術志向」「マネジメント志向」 といった個々の志向性に合わせた、多様なキャリアの道が明確に広がっています。 エニグモ のエンジニアは、 BUYMA の事業課題を深く理解した上で、開発目線でビジネス側と協議し、要件定義から開発に携われるポジションです。 プロダクトの成長にどう貢献するかを考える機会が豊富で、事業志向の方には特に大きなやりがいがあると思います。 一方で、技術を突き詰めたい方にとっても魅力的な環境です。先ほどお伝えした通り、 BUYMA はアクセス数・ トランザクション 量ともに非常に多く、機能同士が複雑に連携する大規模プロダクトです。 そのため、コードの変更一つにも他機能への影響を慎重に考慮する必要があり、自然と質の高い開発マインドが養われます。 スケーラビリティやパフォーマンス最適化といった、大規模サービスならではの設計・運用を経験できる点も大きな魅力であり、高度な技術力を鍛え続けられます。 また キャリアパス も柔軟です。現在のエンジニア組織は、マネージャー集権から ドメイン 特化の“スクワッドリード”へと裁量を移譲しています。 さらに、マネージャーにならなくても「技術に特化した スペシャ リスト職」として正当に評価・昇給される仕組みが整っており、カルチャーも「柔らかいやりとり」が多く相談しやすい環境です。 このように、 エニグモ のエンジニアは「事業志向」「技術志向」はもちろん、私のような組織を率いる「マネジメント志向」も含め、個々の強みを活かしながら成長していける環境にあります。 どんな志向を持つ方でも、可能性を広げながらキャリアアップできることが、 BUYMA 開発組織の最大の特徴です。 最後に エニグモ に興味を持ってくださっている方へメッセージをお願いします システム的には、長年の運用を経て、いわゆる技術的負債（矛盾や制約）も残っているのが現状です。マネージャーとして、そうした改善が難しい領域を少しずつ解きほぐし、開発者がよりスムーズに、気持ちよく開発に取り組めるような環境を整備していく必要があります。これは、エンジニア部署として継続的に推進していくべき、重要なプロジェクトだと考えています。 また、 BUYMA のシステムは機能範囲が非常に広いため、各 ドメイン や機能領域において、より専門性を持った、俊敏に動ける組織づくりが求められています。 人の面での育成はもちろん、技術的な基盤の底上げも含めて、 BUYMA のさらなる成長に貢献していきたいと思っています。 私は、「 エニグモ を卒業した後も『 BUYMA の開発に関わっていた人は優秀だね』と思われるようなエンジニア」を育てたいという気持ちで、日々メンバーと向き合っています。 私たちの組織で培った経験が、どこに行っても価値を発揮できる高い市場価値に繋がること——それが私たちが育成において最も大切にしていることです。 エニグモ にはエンジニアとしてのスキルをしっかり磨ける環境があり、力のあるエンジニアがたくさん在籍しています。そうした仲間と一緒に働く機会も多いので、自分で勉強してきた方や、スキルの高い人たちと切磋琢磨したいという方にとっても、最適な環境だと思います。 ぜひ一緒に、 BUYMA の成長を支える開発組織をつくっていきましょう。

はじめに こんにちは、AIテク ノロ ジー グループの辻埜です。普段はデータサイエンティストとして 機械学習 を用いたシステムの開発運用や、社内のAI活用推進を担当しています。 近年、テク ノロ ジー の発展に伴いAIの重要性が叫ばれる中で、 エニグモ が運営するソーシャルショッピングサイト『 BUYMA 』でも積極的にAIの活用が進められています。この記事では、 エニグモ においてAIやデータをメインで扱っている「AIテク ノロ ジー グループ」についてご紹介します。 まずはじめに「AIテク ノロ ジー グループ」の組織における位置付けとグループ内のチーム構成を簡単にご説明した上で、メインのトピックとして各チームの業務内容や技術スタック/ツールついてご紹介していきます。 AIテク ノロ ジー グループとは 組織図 AIテク ノロ ジー グループは、社内のエンジニア組織であるサービスエンジニアリング本部（以下、SE本部）に属するグループの1つです。AI・データの スペシャ リストが集まっており、それらの専門知識・技術をプラットフォーム・組織に提供し、事業価値・ 企業価値 向上へ貢献する役割を担っています。元々データテク ノロ ジー グループという名称でしたが、2025年4月1日より「AIテク ノロ ジー グループ」へと名称を変更しました。 組織図（2025年8月1日時点） AIテク ノロ ジー グループが所属するSE本部はAIテク ノロ ジー グループ、アプリケーション開発グループ、インフラグループの3つのグループに分かれており、各グループ内でも担当ごとに更に細かくチームを構成しています。 SE本部の開発体制の詳細について知りたい方は以下の記事も併せてご覧ください。 tech.enigmo.co.jp チーム構成について AIテク ノロ ジー グループにはデータエンジニア、データサイエンティスト、検索・MLOpsエンジニアなどデータに関わるメンバーが所属しており、以下のような単位でチームを構成しています。 データ基盤チーム 機械学習 チーム 検索チーム MDDBチーム システムの構成図と各チームの担当範囲は以下のようになっています。 システム構成と担当範囲 ここからは、それぞれのチームごとの役割と業務内容を順番にご紹介します。 各チームの紹介 データ基盤チーム 役割 データ基盤チームにはデータエンジニアが所属しています。社内の膨大なデータを整理して「データ基盤」を構築・運用し、データ分析がしやすい環境を提供する役割を担っています。 エニグモ では、データアナリストやデータサイエンティストといった分析を専門とする社員だけでなく、ほとんどの社員が自ら SQL を駆使してデータを確認したり分析を行うなど、データドリブンな文化が強く根づいています。データ基盤チームはこの強力なデータ活用文化を支えています。 業務内容 データ基盤チームの主要な業務の1つは、データのETL（Extrat: 抽出、Transform: 変換、Load: 書き出し）処理の管理です。 エニグモ では、それらのデータ処理の オーケストレーション にCloud Composerを活用しています。環境から収集 API を通じて送られてくる何万、何億というデータを分析しやすい形式に整形し、データベースに集約します。さらに、それらのデータがその先のデータベースやMAツール、社内分析ツールへと連携されるまでの一連の処理すべてを オーケストレーション しています。 効果的な施策を実施するためにはデータのリアルタイム性も欠かせません。データはわずか1時間で各DBからデータ基盤であるBigQueryへ同期され、リアルタイムに近い分析と意思決定を可能にしています。高速なデータ連携を維持するため、全体の健全性の監視も行っています。具体的には、Cloud Composerが適切に稼働しているか、同期に遅延は起きていないか、格納されたデータに問題はないかなどを常に確認しています。 また、データ処理の オーケストレーション だけでなく、ビジネスチームがデータを最大限に活用するための環境の整備も行っています。社内では分析ツールのひとつに「Looker」が使用されており、データ基盤チームは社内からの要望に応じてLookML（Lookerで使用される独自の モデリング 言語）でデータの定義を行っています。これにより、社内の誰もが効率的で一貫性のあるデータ分析ができる環境を提供しています。さらに、Lookerの利用コストが著しく増大するのを防ぐため、LookMLの記述においてクエリの効率化やデータ集計の最適化を行うことで、リソース消費の抑制を図っています。 加えて直近の業務としてはオンプレミス環境に存在する一部のデータ処理基盤の クラウド 移行プロジェクトも進められています。Terraformによるインフラ部分のコード化、既存のDAGのバージョンアップ修正、現状の構成の リファクタリング 、移行に伴う動作確認など、機能面・非機能面ともに移行後に求めらる水準を達成できるよう、入念にプロジェクトを進めています。 以上のように、 エニグモ のデータ活用を根底から支えているのがデータ基盤チームです。 機械学習 チーム 役割 機械学習 チームにはデータサイエンティストが所属しています。施策の企画や実施、効果検証、 機械学習 モデルの開発・運用、社内のAI活用推進などを担当しています。 データ基盤チームの取り組みにより、 エニグモ には総ユーザー1000万人以上の行動データ、計650万点以上の出品データなど、膨大なデータが蓄積されています。それらのデータから 機械学習 を活用して インサイト を抽出し、アプリの機能や施策など様々な形でユーザーへ価値を届けるのがデータサイエンティストの役割です。 業務内容 BUYMA では様々なシーンで 機械学習 が活用されています。たとえばログイン済みのユーザーが BUYMA を開くと、PERSONALIZED RANKINGという項目が表示されます。これは、各ユーザーの履歴をもとに、ユーザーの好みに沿った商品をレコメンドし、専用のランキングとして表示しています。 PERSONALIZED RANKING また、データサイエンティストが自発的に提案を行い施策を実施するケースもあります。クーポン施策の実施などがその一例です。施策の企画から分析、実施、効果検証まで一貫して担当します。過去の施策を分析したり 機械学習 モデルを活用しながら、施策内容や配布タイミング、対象者を定め、様々な関係者と連携をとりながらプロジェクトを進めます。施策実施後には効果検証も行い、後の施策に活かすための知見を探ります。 機械学習 の知見を活用し、社内で利用されているサービスの内製化に至ったケースもあります。以下のブログでは、 元々社 内で使用されていた他社製の類似画像検索システムにおいて、精度を維持しつつコスト削減が実現できた事例をご紹介しています。 tech.enigmo.co.jp 直近では社内のAI活用を推進するため、Difyという生成AIアプリ開発ツールを活用した取り組みも行っています。エンジニアが逐一アプリを構築するのではなく、非エンジニアでもツールを使ってどんどんAIを活用できるような環境を整えるための取り組みを行っています。 以上が 機械学習 チームの業務内容です。 ※混同されがちですが社内の別グループにはデータアナリストのチームも存在します。役割の違いとしては、データアナリストは各事業部が実施した施策を アドホック に分析し、ビジネス上の課題を特定したり、成功要因を把握することに焦点を当てます。一方でデータサイエンティストは 機械学習 の知識を駆使して、将来の予測やモデルの構築を行うことがメインの役割です。役割の違いはありつつも両者は業務範囲が重なる部分も多いため、毎週合同のデータ勉強会を実施したりミーティングを通じて情報交換などをするなど、密に連携をとりながら業務を進めています。 検索チーム 役割 チーム名から検索システムのみを担当としているチームと思われがちですが、業務内容としては社内のMLOps領域も担っており、検索兼MLOpsエンジニアが所属しています。 BUYMA の検索システムの運用改善、 機械学習 基盤の開発運用を担うチームです。 業務内容 検索チームの業務内容としては主に3つの柱があります。 1つ目が BUYMA の検索システムの運用改善です。 BUYMA では650万点以上もの商品が出品されています。その膨大な商品の中からユーザーが求めている商品を見つけやすくするためには、高精度な検索システムが欠かせません。検索チームでは検索システムが稼働する Kubernetes Engine（GKE）環境の更新や中間DBに用いられている MySQL の管理など、検索システムに関わる一連のシステムのすべての管理を担当しています。 また、直近では検索システムの運用だけではなく、よりよい検索結果を提供するための精度改善の取り組みも行われています。 BUYMA では複数の検索システムが稼働しています。2024年7月に全検索システムの Google Cloud Platformへの移設が完了しており、完全にマイクロサービス化された状態となっています。 BUYMA の検索システムの構成については以下の記事も併せてご覧ください。 tech.enigmo.co.jp 2つ目の柱がMLOpsです。検索チームは元々は検索エンジニアリングの専任チームとしてスタートしましたが、徐々に検索システムから推薦システム、 機械学習 へと領域が広がり、今ではAIサービスの安定稼働を支えるMLOps部分も担当しています。 具体的にはデータサイエンティストが開発したモデルをデプロイするための クラウド 環境の構築などを行います。構築にあたっては求められる水準のレスポンス速度や可用性を担保するための設計、システムが危険に晒されないためのセキュリティの設計など、考慮すべき事項が数多くあります。また、 機械学習 システムは一度リリースされたら終わりではなく、必要に応じて何度も修正、テスト、デプロイが繰り返されます。それらの開発と運用のサイクルを円滑にするためのCI/CDの構築も行っています。 3つ目の柱がAIシステムの開発やPoCです。以前までは上記の2つの業務が主でしたが、最近はAIを使ったシステムを比較的容易にデプロイできるような SaaS 系のサービスも増えてきたため、それらを活用してAIを使ったシステムの開発やPoCを担当するようにもなっています。 代表的にはAIを用いた社内ドキュメント検索システムの構築や BUYMA のAI検索機能の改善、テキストデータの分析システムの構築などを行っています。 以上のように、インフラからアプリケーションレイヤーにわたる幅広い知識をフルに生かし、 機械学習 システムの大黒柱のような役割を担っています。 MDDBチーム 役割 MDDBはMerchandise Databaseの略で、 BUYMA に掲載されている膨大な数の商品情報を集約・整理し、提供するための基盤を指します。MDDBチームは、このMDDBの開発と改善、そして社内でMDDBをより活用しやすくするための API 開発などを行っています。 業務内容 BUYMA ではCtoCプラットフォームの特性上、出品されている商品が同じ商品であっても、出品者が異なればそれぞれ異なる商品IDが付与されるため、システム上では別々の商品であると認識されてしまいます。 そこで、MDDBチームでは社内に蓄積された多種多様な情報を整備し、異なる商品IDを持つ同一商品を紐づけることで、より正確で包括的な商品データベースを構築しています。 一口に「情報の整備」と言っても、乗り越えるべき課題は多岐にわたります。例えば、 BUYMA の商品情報の入力方法や記載内容は出品者によってさまざまです。そのため、AIを活用して表記ゆれを吸収し、画像情報や製品情報なども活用しながら、真に同じ商品であるかを識別する仕組みを開発しています。 また、構築されたMDDBの情報をLookerと連携させることで、社内の誰もが簡単にデータにアクセスし、分析できる環境を提供しています。これにより、各部門は「 BUYMA 上ではどの商品が人気か？」「どんな商品が出品数が多いか？少ないか？」といった商品を軸にした分析や、その分析結果を根拠とした施策の意思決定が可能になります。 さらに、各部門にMDDBを活用した分析環境を提供するだけでなく、MDDBチーム側からもデータ分析における積極的な貢献を行っています。具体的には、MDDBのデータを使って BUYMA 上に出品されている商品の変化を分析し、出品や購入を促進するための示唆に富むデータを提供することで、各部門がより効果的な施策を検討できるよう支援しています。 このように、商品という切り口で施策の意思決定の根拠になるようなデータを収集、整備、分析して提供するのがMDDBチームのミッションです。 技術スタック・ツール 上記でご説明した業務を行うにあたって、AIテク ノロ ジー グループでは主に以下の技術スタック、ツールが使われています。 用途 技術/サービス/ツール名 開発言語 Python , Ruby （ Ruby on Rails ）, PHP コード管理 GitLab CI/CD GitLabCI/CD インフラ Google Cloud, Docker, Google Kubernetes Engine（GKE） IaC Terraform バッチ処理 Cloud Run, Vertex AI Pipelines 分散処理 Dataflow ログ管理 Datadog, Cloud Logging ワークフロー管理 Apache Airflow / Cloud Composer, Vertex AI Pipelines, Cloud Workflows データ変換 dbt データベース BigQuery, MySQL , Cloud Datastore データ分析 Looker, Redash 検索エンジン Apache Solr タスク管理 Jira, Redmine コミュニケーション Slack, Zoom 技術スタックについては上記のサービス群で固定されているわけではなく、新たに有用なサービスが見つかった場合には積極的に利用しています。使用ツールについてもセキュリティに問題のない範囲で各個人で好きなツールを使っていたり、最新のAIエディタ等も申請が通れば会社の予算で利用できるなど、エンジニアがなるべく開発しやすくなるような環境を整えています。 さいごに 先にご紹介した通り、AIテク ノロ ジー グループは昨年度までは「データテク ノロ ジー グループ」という名称でした。しかし、社内でのAI活用が進んでいく中で、グループの担当業務としてもAI検索システムの導入などAIの案件が増えていたことに加え、グループの方針として「 BUYMA および社内業務へのAI組み込みの提案」という方針を打ち立てており、実態にあった名称とするために2025年4月から「AIテク ノロ ジー グループ」という名称に変更されました。 AIテク ノロ ジー グループは、新たなグループ名となってまだスタートを切ったばかりです。 BUYMA がユーザーの皆様にとって魅力的で価値のあるプラットフォームであり続けるために、そして「世界を変える、新しい流れを。」というモットーのもと、日々奮闘しています。 まだまだ課題やチャレンジしたいことがたくさんあります。以下の通り採用も行っておりますので、ご興味のある方はぜひご覧ください。ご応募お待ちしております！ hrmos.co

こんにちは、UXデザイングループの宮川です。今回は、 エニグモ が運営するソーシャルショッピングサイト「 BUYMA 」で、購入者向け機能を開発するチームのエンジニア、東野さんにインタビューしました。 エニグモ に入社したきっかけや普段の業務内容、そして エニグモ で働く魅力について伺います。 これまでのキャリアと エニグモ に入社した経緯を教えてください 元々、エンジニアとしてキャリアをスタートさせたわけではなく、建築業界で施工管理の仕事をしていました。そこからエンジニアという職業に興味を持ち、独学で勉強してエンジニアとして転職しました。 前職ではエンジニアが5名ほどの小規模な組織に所属し、Web上の店舗情報を一括管理する SaaS の開発に携わっていました。ここでは、バックエンド、フロントエンド、インフラと、開発のほぼ全ての領域を担当し、ビジネスサイドやCTOと密に連携しながら、要件定義から開発までを一貫して行っていました。 とても貴重な経験をさせていただいていたのですが、その一方で、エンジニア組織が小規模で技術への関心が高いメンバーが少なかったことから、自身の技術的な貢献が評価されにくいという課題も感じていました。 そんな中、 エニグモ の記事で評価制度やバリューに関する考え方を拝見し、透明性が高く、自分がやりたいことで会社に貢献し、正当に評価してもらえる環境だと感じました。また、技術ブログからは、 スペシャ リストとして業務に貢献されている方々の姿や、各メンバーの取り組みを知ることができ、その技術レベルの高さに強く惹かれました。技術面においても、大規模な トラフィック を前提としたデータ処理や、本番環境で求められる高い品質を考慮した設計・実装など、私が挑戦したいことと エニグモ が求めるものが一致していると感じ、入社を決意しました。 ※スペシャリストとして貢献するメンバーの紹介記事 ※カンファレンスについての記事 ※エンジニア組織やバリューに関する記事     エニグモ ではどのようなお仕事をされていますか？ 入社当初は、開発組織を横断的に支援するチームの１つであるApplication Platformチーム（以下APチーム ) に所属していました。ここでは、技術スタックの最適化、インフラ基盤のモダン化、 アーキテクチャ 改善、サービスの信頼性向上といった、横断的に共通の技術課題を解決し、開発組織全体の生産性を向上させる活動を行っていました。 その後、社内異動を経て、現在は BUYMA の購入者向け機能を開発する「BUY Domain」の「CVR Squad」に所属しています。 エニグモ の開発体制は、 BUYMA のDomain（機能）ごとに、BUY（購入者向け機能）、SELL（出品者向け機能）・SERVICE INFRA（決済や配送などの BUYMA 根幹を支える機能）(※)といった3つの ドメイン に分かれています。そして、その ドメイン をさらに細分化し、事業的なミッション達成に向けて、システム全体のライフサイクル（設計、開発、テスト、本番化、運用、不具合対応など）にオーナーシップを持つ縦割りのチームのことを「Squad（スクワッド）」と呼んでいます。 私の所属するCVR Squadは「購入者のコンバージョン率（CVR）向上」のミッションを持っており、私は BUYMA の購入フローやクーポン施策に関する開発を担当し、今後開発をリードしていく役割を担っています。 また、DXチームという開発組織を横断的に支援するチームも兼任しており、 BUYMA のローカル開発環境やソフトウェア開発のプロセスを自動化するためCI/CDツールの整備を通して、エンジニアがより快適かつ効率的に開発できる環境づくりに取り組んでいます。例えば、AIツールを安全に活用できるよう、 BUYMA の ソースコード から個人情報などの機密情報を分離し、気兼ねなくAIを使用できる開発環境の整備などを行なっています。 ※エニグモのエンジニア組織について   印象に残っているプロジェクトについて教えてください 現在所属しているCVR Squadでの、トレンドワード機能を改善したプロジェクトが印象に残っています。 BUYMA には、ホーム画面のカテゴリータブの下にある、（ブランド名）人気バッグ、（ブランド名）アウトレット商品などの「トレンドワード」タグを押下して検索結果に遷移できる機能があります。 改善前のこの機能では、全年代に一律の「トレンドワード」を表示しており、特定の層にしか響かず、特に若年層への訴求が弱いという課題がありました。そこで、ログインユーザーの年代に合わせて、表示する「トレンドワード」を最適化し、若年層への訴求を強化するために、このプロジェクトが始まりました。 私は主にバックエンド開発の役割で関わりましたが、仕様のキャッチアップも兼ねてWebアプリケーションのフロントエンド（React）も一部担当しました。また、ディレクターやアプリエンジニア（ iOS / Android ）を交えてビジネス要件を調整しつつ、バックエンドの設計・実装を進め、施策全体の開発計画やリリース計画の調整も行いました。 開発そのものの複雑さは高くなかったのですが、大規模サービスならではの課題が2点ありました。1点目は、複数のレイヤーにキャッシュが組み込まれていることや、アプリ用 API でバージョニングを考慮した設計が必要であるなど、サービスが大規模なため、数々の既存システムの仕様を把握する必要があったことです。 2点目は、私の BUYMA でのはじめてのビジネス系の施策で、アプリ（ iOS / Android ）、管理画面、Webと開発範囲が広かったため、自身の担当範囲の見極めや、開発フローを把握しながら他チームと連携する必要があったことです。 これらの課題に対し、1点目の既存システムの仕様の把握については、社内の情報共有ツール（ esa ）やSlackのログを確認したり、 ソースコード を直接読み解いたりすることで理解を深めました。2点目の開発の連携については、プロジェクトの初期段階でタスクを洗い出して開発計画を立て、 クリティカルパス を把握した上で、開発の順序や他チームへの依頼フローを整理するようにしました。  結果、大きな手戻りなく各チームが効率的に開発を進めることができ、施策としてもトレンドワード機能を利用するユーザーの数を底上げすることに成功しました。このプロジェクトを通して、幅広い開発スコープを担当させてもらえたことで、ビジネス施策の進め方やシステム仕様への理解が深まり、大きな自信に繋がる印象的なプロジェクトになりました。   エニグモ グループで働く魅力を教えてください 長年続くサービスだからこそ得られる技術的な知見 BUYMA は20年以上稼働している エニグモ 創業時から続くサービスで、以前は開発言語に PHP が使われていましたが、現在は Ruby に技術刷新され、旧来のシステムと新しいシステムが共存する形で運用されています。 そのため、機能的には移行が完了していても、一部で PHP 時代の影響が残っている箇所があり、施策内容によっては旧来のシステムへの影響調査と設計が求められます。このような長年稼働している複雑なシステムに対し、実装当時の担当者がいない中で、自ら仮説を立てて状況を整理し、アウトプットを出す必要があります。 難しい挑戦ではありますが、それを乗り越えることで、リアルなビジネス課題を解決するための実践的な知見を得ることができます。 職種の枠を超えて幅広い工程に携われる システム開発 において、ビジネス要件の調整から、既存システムの調査、開発計画の立案、設計、実装、QAまで、全工程に携われることも大きな魅力です。  もちろん、全てを一人で対応しなければいけないわけではありません。状況に応じて他チームに依頼することや、エンジニアの アサイ ンが難しい場合は自ら開発することもあります。あるいは、開発に専念してレビューのみを他チームに依頼したりと、柔軟な動き方が可能です。  加えて、 エニグモ では安全なリリースに必要なリソースを確保しやすい文化があるため、時間をかけて調査や実装、リリース計画を綿密に立てることができるため、エンジニアとして納得感を持ちながら開発に取り組むことができます。 多職種なメンバーと協業しながら開発できる環境 入社時に配属になったAPチームでは、難易度の高い専門的な技術を扱っており、技術力が高いエンジニアが集まっていたため、当初エンジニア3年目の自分にとってはチャレンジングな環境でした。何でも自分で解決しようとして行き詰まることもありましたが、思い切って相談してみると、皆さん快く手を差し伸べてくださり、自己解決が難しい案件もスムーズに進められるようになりました。 複数のチームを経験したことで組織体制への理解が深まり、他チームのエンジニアやビジネスサイドのメンバーと関わる中で、効率的に業務を進められるようになったと感じています。また、ビジネスサイドやディレクターの方々もエンジニアへの理解が深く、建設的なコミュニケーションが取りやすい環境です。 多様なメンバーと協業する中で、視野が広がり、自身の成長やよりよい開発・提案にもつながっていると実感しています。   今後チャレンジしたいことを教えてください 既存システムの技術的課題や ソースコード の改善提案などを通して、サービスの安定性と開発者体験の向上にさらに貢献していきたいです。 BUYMA は既存システムの仕様を把握するのが難しく、改善提案を行う際にも、変更することによって起こる多くの影響を考慮する必要があります。しかし、今までの業務で既存システムに触れ、他のエンジニアのコードレビューと合わせて仕様の把握を進める中で、より大きな課題解決を行うための準備が整ってきたと感じており、今後は、より積極的に改善に取り組んでいこうと思っています。 例えば、 BUYMA のユーザー情報や取引情報を管理する社内ツールは、多くの部署で利用される必要不可欠なツールですが、技術スタックが古く、機能開発の ボトルネック になり、パフォーマンスが最適化されていません。このようなツールの新規開発を主導し、順次リプレースを進めることで、抜本的な改善に貢献していきたいと考えています。   エニグモ に興味を持ってくださっている方に、メッセージをお願いします 20年以上続く大規模サービスを舞台に、本番環境に根ざしたリアルな課題に向き合うことができます。開発者としての視野を広げ、技術的な意思決定を自らの手で行う経験を積みたい方にとっては、非常にやりがいのある環境だと思います。 担当業務は基本的に自身の役割が軸になりますが、施策の初期段階から関わることで設計や技術方針に意見を出し、必要に応じて他の領域に挑戦したりすることも可能です。 私も最初は不安がありましたが、困ったときにはすぐに助けてくれるチームメンバーや、エンジニアの挑戦を後押ししてくれる文化があるので、安心してチャレンジを続けられています。 エニグモ で、一緒にエンジニアとしての幅を広げていきましょう！   ---- 株式会社 エニグモ すべての求人一覧 hrmos.co

こんにちは、 エニグモ 嘉松です。 データ活用推進室という部署でデータ活用の推進や マーケティング ・オートメーションツール（MAツール）を活用した販促支援、 CRM などを担当しています。 この記事は エニグモ Advent Calendar 2024 の 25 日目の記事です。 はじめに この記事では、AppSheetを学び始めたばかりの私が実際に視聴して役立った YouTube 動画をご紹介します。 効率的に スキルアップ できるよう、おすすめの視聴順も一緒にご紹介します。 AppSheetとは AppSheetとは、プログラミングの知識がなくても簡単にアプリを作成できる Google 社が提供するノーコード開発プラットフォームです。 Google スプレッドシート などのデータと連携し、 GPS 機能やカメラ機能を活用したアプリも開発可能です。営業活動の効率化、在庫管理の最適化、顧客管理の強化など、様々な業務に活用することができ、業務効率化、コスト削減、意思決定のスピードアップを実現できます。現場の作業者など、IT知識がなくても アプリ開発 に挑戦したい方におすすめです。 おすすめ動画（再生リスト）２選 以下におすすめ動画の再生リストを２つ紹介します。 「AppSheetを作ろうの会」 「AppSheet入門シリーズ」 「AppSheetを作ろうの会」 チャンネル名 cooker8 by 明治クッカー https://www.youtube.com/@cooker8 再生リスト AppSheetを作ろうの会 https://youtube.com/playlist?list=PLI47ltjBt9zETX2YcHSGArWLe4UBKJazW&si=T8SOH8Xm_SjLkjJK 動画本数 22本（2024年12月時点） 内容 AppSheetの初心者向けに、アプリ作成の基本から応用までを解説しています。 各動画では、具体的なアプリの作成手順や機能の使い方が丁寧に説明されています。 メインで解説を担当する牛乳屋の社長と社員に加えて、 Google Cloud Japanの担当者も登場します。 動画の再生時間が30分を超えるものもあり、また動画本数も22本と多いです。 おすすめポイント AppSheet初心者の社長の視点で解説されているので、AppSheet初心者には同じ視点で動画を視聴することができます。 Google Cloud Japanの担当者の方も登場するので、AppSheetの中の人からの解説も聞ける点が他の動画と比較してユニークです。 現在も動画が追加されているので、定期的にウオッチしていくと最新の動向など把握できます。 AppSheet開発の考え方や作ったアプリをどのような業務に活かせるのか？といったAppSheetの開発の説明に留まらない重要な内容に触れているところに価値があると感じます。 おすすめ視聴方法 動画の本数も多く、30分を超えるような再生時間が長い動画もあるので、最初から一気に全て視聴するのはタイパという点でおすすめしません。 視聴者のこれまでの経験や担当する役割、確保できる時間との兼ね合いで、動画をピックアップして視聴するのがおすすめです。 視聴する優先度はこの後の「おすすめ視聴順」を参考にしてください。 「AppSheet入門シリーズ」 チャンネル名 AppSheetエンジニア岡田 https://www.youtube.com/@gasappsheet3423 再生リスト AppSheet入門シリーズ https://youtube.com/playlist?list=PLjtPSE_IHMnqyS35ChvLV_zGDcmXVRSA2&si=_fo_lXFwezpPj-PN 動画本数 10本（2024年12月時点） 内容 AppSheet専門 フリーランス エンジニアの方が解説している動画です。 初心者向けにプログラミングの知識がなくても理解しやすい構成になっています。 各動画がコンパクトにまとめられており、効率的に必要な知識を得ることができます。 おすすめポイント 開発の手順について実践的に解説されているので、いち早くAppSheetで アプリ開発 を進めるには最適な再生リストです。 実際の操作画面を見ながら学べるため、手順が分かりやすく、初心者でもスムーズに アプリ開発 に取り組めます。 動画のクオリ ティー も高いと感じました。 おすすめ視聴順 「おすすめ視聴順」の選定ポイント 最初はAppSheetの特性を理解できる動画をおすすめ！ 具体的には、AppSheetでどのようなことができるのか、また、AppSheetがどのような場合に適していて、どのような場合に不向きなのかを理解できる動画を最初に視聴することをおすすめします。なぜなら、どのようなケースでAppSheetを使うべきか、逆にどのようなケースではAppSheetを使わない方が良いのかを判断できることは、その後の アプリ開発 において非常に重要だからです。AppSheetに向いていないことをAppSheetで行おうとすると、開発者もAppSheetも不幸になってしまうため、何事も適材適所が大切です。 次に実際に手を動かしながら開発手順、開発方法を学べる動画をおすすめ！！ 次の段階としては、実際に動画を視聴しながら、開発を進めていく段階です。この段階では思ったとおりにいかないことも多々でてくると思います。なるべく迷わないように動画のクオリティが高く、丁寧に解説されている動画が良いと思いました。 AppSheetの開発の初期段階で知っておいたほうが良い小技的な知識も優先して視聴することをおすすめ！！！ 開発が進んだ段階だと後戻り、作り直しになってしまうような知識（たいていは小技的なことが多い）は早めに見る価値は高いので、優先して視聴することをおすすめします。 おすすめ視聴順 視聴順 動画タイトル チャンネル名 視聴時間 1 【AppSheet新シリーズ】新企画始動！第一弾：AppSheetでめっちゃ便利なアプリを大公開！ cooker8 by 明治クッカー 約33分 2 【AppSheet第三弾】5分で出退勤アプリをつくる。「ド素人」のにっしー社長の作成過程を全部見せます。 cooker8 by 明治クッカー 約26分 3 AppSheetの絶対ルールをまとめてみた。【AppSheet第5弾】 cooker8 by 明治クッカー 約21分 4 AppSheet入門シリーズ（Part1〜Part6） AppSheetエンジニア岡田 約60分 おすすめ視聴順の詳細 「AppSheetを作ろうの会」 【AppSheet新シリーズ】新企画始動！第一弾：AppSheetでめっちゃ便利なアプリを大公開！（視聴時間約33分） 33分と長いが、どんなアプリが作れるのか、アプリをどのように業務に活かせるのかをイメージできる。 アプリの作り方は説明していないが、どんなアプリを作れるか、どう業務に活かせるかをイメージできるのでオススメ。 個別のアプリの説明がやや長いので、その部分は飛ばして視聴してもオッケーです。 【AppSheet第三弾】5分で出退勤アプリをつくる。「ド素人」のにっしー社長の作成過程を全部見せます。（視聴時間約26分） アプリ開発 の初心者（未体験）の社長が、最初のアプリを作るまでを紹介している。 超シンプルなアプリの開発を通して、AppSheetの開発の流れを理解できる。 AppSheetの絶対ルールをまとめてみた。【AppSheet第5弾】（視聴時間約21分） スプレットシートからAppSheetを作成する前段階として押さえておいたほうが良いこと、特にAppSheeを作成した後だと容易に変更できないことなどがまとめられている。 AppSheetの開発の初期段階で知ってくと後戻りが少ないので、早めに見る価値は高い。 「AppSheet入門シリーズ」 「AppSheet入門シリーズ」のPart1からPart6まで通しで視聴する。（視聴時間約60分） 作りたいアプリによってはPart6の後にPart7とPart8を視聴する。（視聴時間約14分） 時間のある時にPart9、Part10を視聴する。（視聴時間約20分） おわりに この記事では、AppSheetの初学者の私が視聴してためになったYouTuebe動画をおすすめの視聴順と合わせて紹介させていただきました。 これからAppSheetを試してみたい、勉強したいという方の一助となれば幸いです。 他に参考になる動画があればコメントいただければ助かります。 本日の記事は以上になります。 なお エニグモ Advent Calendar 2024 もこの記事で最後になります。 最後までお読みいただきありがとうございました。 株式会社 エニグモ すべての求人一覧 hrmos.co

こんにちは！Webアプリケーションエンジニアの 川本 です！ この記事は Enigmo Advent Calendar 2024 の 23日目の記事です。 2024年12月18日に開催された Datadog Live Tokyo 2024 Reprise へ参加してきました。 www.datadoghq.com 10月に行われた Datadog Summit Tokyo 2024 にも参加したのですが、イベント内容の充実度とそこから得た学びが多かったことから今回のイベントにも参加を決めました。 Datadog Summit Tokyo 2024 へ参加した際のレポートを 2日目のAdventCalenderに投稿しているので、気になった方はこちらも合わせてご覧ください。 tech.enigmo.co.jp 印象に残ったトピック 今回のイベントを通して以下のトピックが印象に残りました。 ボトルネック 特定までの流れ サイバーエージェント 社の赤野さんの講演で紹介されていた、 API パフォーマンス改善を行なった際に APM Trace Queries を使って ボトルネック 特定の流れが非常に参考になりました。 APM Trace Queriesは Span の関係に基づいて Trace の検索、集計ができる機能です。 例えば ServiceA から直接呼び出されている ServiceB または ServiceC の Span を含むトレースを検索する場合、トレースクエリ 演算子 を用いて以下のように表現することができます。 ServiceA => ServiceB | ServiceC APM Trace Queries についての詳細 docs.datadoghq.com ボトルネック 特定までの流れは以下にように紹介されておりました。 APM Trace Queries を使って BFF のレイテンシに対して処理時間の割合が大きいマイクロサービス API を可視化 API ごとに APM Trace を確認して怪しい Span がないかを探す Continuous Profiler で ボトルネック になっている関数を特定 私もパフォーマンス改善の際に同じような手順で改善を試みたことがあるのですが、 APM Trace Queriesについてはここまで活用できていなあったので非常に参考になりました。 また Datadog を使った ボトルネック 特定の手順は属人化しないと思うので、手順としてチームに共有することもできるのでとてもいいなと思いました。 オブザーバビリティツールの統一 サービスによっては歴史的経緯やマイクロサービス化等によってオブザーバビリティツールが統一されていない状況があるかと思います。 しかし、このような状況ですとツールの管理者は事情を把握しているので 臨機応変 に使いわけられるかと思いますが、利用者は最初どれを使えばよいのか混乱を招く可能性があります。 他にも Wantedly 社の田中さんの講演ではツールを統一することには以下のようなメリットがあると紹介されており非常に参考になりました。 計装ライブラリへの依存が減りパフォーマンス向上 計装ライブラリ同士の競合による不具合の解消 サービス利用費用の圧縮 speakerdeck.com 弊社では Datadog が主に使われていますが、完全には統一されておらず他のツールと併用している状況です。私自身も入社当初どのツールを見れば良いのか迷って質問した経験があります。社内の誰でもオブザーバビリティを活用できるようにツールは統一していきたいです。 コスト管理 コスト管理に関する興味深い点として、オブザーバビリティツールが従量課金モデルかユーザー数課金モデルかで大きく違ってくるということです。 従量課金の場合はコスト管理は難しいが、 コストコ ン トロール はしやすい。 ユーザー数課金の場合はコスト管理はしやすいが、 コストコ ン トロール は難しい。 これらは組織によってツール選定の基準に大きく関わってきそうです。 従量課金のDatadog www.datadoghq.com ユーザー数課金のNew Relic newrelic.com エンドポイントごとの担当者（Owner）を可視化 大規模なモノリシックなサービスでエンドポイントが多数ある場合、どのエンドポイントが自分のチームが管理しているのものなのか把握するのが難しいことがあると思います。 リクルート 社の小檜山さんの講演で、エンドポイントのOwner一覧を ダッシュ ボードで見れるようにしたという事例が非常に参考になりました。 以下の資料で紹介されております↓ speakerdeck.com 弊社も大規模な Rails の モノリス が存在しており、お問い合わせ対応の際にすぐにエンドポイントのOwnerがどこかわからずに混乱するといったことがあります。この事例は弊社でも適用できそうだと感じました。 おわりに 様々な会社のオブザーバビリティ、Datadogの活用事例が聞けてとても勉強になりました。 また Datadog をエンジニア組織に普及することの難しさはどの会社でも語られていましたが、まずは興味を持ってもらう機会を作りだし、ちょっと便利だから使ってみようかなと思ってもらうことが大切なのかなと思いました。 イベント最後に、Datadogのキャップやステッカーをいただきました。 運営の皆様素晴らしいイベントをありがとうございました！ 明日の記事の担当は SC本部 の 平澤さんです。お楽しみに。 株式会社 エニグモ すべての求人一覧 hrmos.co

こんにちは、GASエンジニア の 佐伯 です。 この記事は Enigmo Advent Calendar 2024 の 21 日目の記事です。 この記事では Google 製の アプリ開発 ツールである、AppSheet について紹介します。 軽く自己紹介になりますが、普段はGAS（ Google Apps Script）やBigQueryなどを用いて業務用ツールの開発を行っています。最近はGASとの親和性も高いAppSheetに挑戦しているので、その中で気づいたことをまとめます！ 概要 AppSheetの利用を検討している方向けに、AppSheetの基本的な特徴やメリットをまとめる。また、より高度に使いこなしたい場合の拡張性や、筆者が感じる向いている用途、デメリット（弱点）、 Microsoft 製品との比較についても記載している。 特徴とメリット データに関する設定を重視した開発ツール 大前提とされるべきAppSheetの特徴として、データ重視の開発ツールである点がある。 これはどういう意味かというと、例えば、ある業務に関連した複数のリレーショナルなテーブルがあるとする。これらに対して、各テーブルの主キーやデータ型を定義し、またテーブル間の参照関係を設定すると、それらのテーブルの利用の仕方は、おおよそ決まってくる（予想がつく）。 「予想がつくなら、自動で作ればいいやん」というのが、 Google 社がAppSheetに込めた主要な思想かな、、と考えている。 それゆえ、それらのテーブルに対する CRUD （ = Create 生成、Read 読み取り、Update 更新、Delete 削除）操作を行うUIを、ほぼ自動で作成するのが AppSheetのメイン機能となっている。 それ以外にも多くの便利なサブ機能があるが、これらはメイン機能に付随し、補完する形で提供される。 UIの作成が非常に早い データソースの設定がなされた時点で、主要なUIは、ほぼ自動で作成される。 UIの表示形式も、テーブルやカード、タイル形式だけでなく、 ダッシュ ボード、カレンダー、マップ、フォームなどなど、ある程度のバリエーションが用意されている。 データ型に応じた入力補助のUIなども、自動で適用される。選択肢タイプであればドロップダウンが表示されるし、日付型であればカレンダーが表示される。当然、データ型に違反するような入力はできない。 あとは、表示順や、並び替えといった、実際に利用するユーザー目線での利便性を向上させれば完了である。 ここまで読んで、メイン機能それだけ？！と言われそうであるが、AppSheetを利用することで、UIとデータソースをほぼ完全に分離することができるため、これによるメリットはやはり大きい。 例えば、GASで スプレッドシート をベースにツールを組む場合、UI作成の手間を回避するために スプレッドシート をUIとして用いることが多いが、この場合、どうしてもユーザーがデータソースを直接編集する形になりがちであり、誤操作やツールの破壊が生じるリスクは大きい。 また、本来であれば正規化して複数のテーブルに分離されるべきデータ構造であっても、やはりユーザーの一覧性向上の観点から、一つのシートにまとめて表示させる場合も多く、冗長でもあるし、データの 保全 性という点でも、よろしくない。 AppSheetを利用することで、UIを独立させ、データソースを理想的なリレーショナルDBの構成で、堅牢に安全性高く維持することができる。しかもUIはほぼ自動でできるのだから、活用しない手はない。 ちなみに自動で作成されたUIを利用せずに、手動でイチから設定していくことも可能である。 データソースの選択肢が幅広い スプレッドシート をデータベースにするのが一番簡単な始め方だが、 AppSheetはそれ以外の方式にも幅広く対応している。 名称 説明 AppSheetデータベース 専用のリレーショナルデータベース。 Google フォーム Google フォーム入力値をテーブルに使える。 Google ドライブ フォルダーやファイルを指定し、そのコンテンツを解析して半自動でテーブルを作成する。 Microsoft OneDrive または SharePoint にあるエクセルを使える。 Airtable Cloud Database GCP , AWS ,Azureなど、 クラウド 上にあるデータベース。通常の SQL 形式はもちろん、BigQueryも含む。 On-premises Database オンプレデータベース。DreamFactory connection を使って接続する。 特に Google ドライブは、請求書などの書面からも自動的にデータを再現するとのことであり、使ったことはないが、おもしろそうである。 サブ機能によって処理内容の自由度を上げられる 基本的な CRUD 操作以上の処理フローを構築する手段として、AppSheetでは様々なサブ機能が提供されている。 サブ機能 内容 入出力補完 UI上でユーザーが様々な CRUD 操作を行う際に、いろいろなバリデーションや加工、警告といった機能を付与できる。 Action ユーザーが実際に CRUD 操作を行う際に、実行するであろう画面遷移や処理内容を、ボタン１クリックにまとめて、UI上に配置する機能である。 Automation テーブルに加えられた CRUD 操作や、スケジュール設定をトリガーにして、定められた処理を実行する機能である。処理内容の選択肢としては、大きく次の２種がある。 ①メール、通知、SMS、Chatなどの通知系 ②webhookやGASを実行する外部連携系 Chat app アプリと連動させて、 Google Chatにメッセージを送るような使い方ができる。普段から Google Chatを使っているならば、便利と思われる。 Action はアプリ内での画面遷移や、他のテーブルへ影響を伝播させるための機能で、処理内容は選択式となるため制約もあるが、比較的簡単な操作で処理フローを構築できる。 Automationは、ユーザー操作や時間タイマーをトリガーとする自動化処理を構築するための機能で、先ほどのActionによる内部的な処理はもちろん、web API などを通じた外部サービスとの連携や、GASとの連携を図ることができる。GASは GCP とも密接に連携可能であり、この点は、AppSheetの限界を大きく広げてくれる。 ただしweb API については、AppSheetから直接認証通過できるのは、 API キー方式などの単純なものに限られ、OAuth2といった主流の方式は（今のところ）直接接続はできない。ただしこの点も、GASに処理を任せてしまえば、そちらでOAuth2通過はできるので、あまり問題にはならない。 GASをどれだけ使いこなすかが、AppSheetの限界を決めそうであるが、GASとAppSheetを連携させる場合においても細かい注意点はあるので、こちらは別途まとめる予定。 SQL ライクの専用関数を利用して、複雑な処理フローも構築できる。 少し複雑な処理フローを構築する場合でも、 AppSheetには専用の関数が利用されており 、これらを用いることで、かなり複雑なデータ操作も作成できる。 これらの関数の使い心地としては、基本的には スプレッドシート 関数に似ていて、テー ブルデー タを操作する部分については SQL の記法も混じっている感覚となる。関数の数は少ないが、よく考えられており、組み合わせ次第で多彩な使い方が可能。 モバイルからの利用をメインで想定しているようだが、パソコンでも問題なく使えるし、便利。 AppSheetのエディター画面では、モバイル形式のプレビュー画面がデフォルトで表示されるが、パソコンのブラウザでのプレビューも表示できるし、実際、問題なく利用できる。 ただ、基本的にモバイルを想定しているため、パソコン（ブラウザ）で利用すると、画面がちょっとシンプルすぎる印象ではある。ただこの点も、デスクトップモードの改善が進んでおり、かなり利便性を向上させやすい状態になっている。 実質無料 驚くべきことに、無料の Gmail ユーザーであっても、AppSheetは利用できる。いくつか機能に制限があり、アプリを共有できるのも最大10名までではあるが、それで事足りる場合も多い。 ましてや workspaceを利用している組織であれば、使わない手はない。プラン関係なく、Business系プランには AppSheetの Coreプランが付属している。 AppSheet有料プランの料金体系は極めて複雑であり、合理的なのだろうとは思うが、ユーザーの理解を拒絶しているといっても差し支えないレベルである。 詳細を無視してざっくり言ってしまうと、「（有料レベルの機能を利用している、または10個以上の Google アカウントで利用しているアプリの場合、）そのユーザー数分の AppSheet有料プラン契約が必要」というイメージである。 workspaceを利用している組織であれば、そのユーザー数分の AppSheet有料プランは含まれているわけだから、例えば30人の組織であれば、あるアプリを最大30ユーザーで利用できる。しかも、これは組織内のアカウントに限られず、組織外の無料 Gmail ユーザーを含んでいてもよい。そのアプリの合計ユーザー数が30を超えなければよい、のである。 さらに無料、有料を問わずアプリ数の制限はなく、また全アプリの合計ユーザー数分の有料プランが必要なわけでもない。あくまで個々のアプリでユーザー数が判定されるのみで、先ほどの例で行くと、組織内でアプリA、アプリB、アプリC の 3つのアプリを運営しているとしても、それぞれのアプリで30ユーザーまで設定できる。 抜群の拡張性 ここまで AppSheetの主要な特徴に絞って記載してきたが、それ以外にも注目に値する特徴は多い。 バーコード、 QRコード の読み取りが可能 商品や資材といった物理的なアイテムを取り扱う業態の場合、これは非常に強力なメリットとなる。コードを読み取ってアプリに値を直接入力したり、コードを読み取ってそのアイテムに該当するデータを瞬時に検索したりすることができる。 データだけでなく、画像を始めとした各種ファイルの取り扱いが可能 画像やファイルを、データに紐付けて保管できる。アプリ内で端末からアップロードすると、 Google ドライブ内に作られた専用フォルダに自動で保管される。 CSV を介したデータ操作が可能 他ツールとの連携や一括更新の際に便利。現状のテーブルをそのまま CSV で出力し、修正の上で、アップロードして反映させることも可能 アプリごとに API を利用できる これもエンジニアにとっては嬉しいところ。他のシステムやツールから、 API を介して直接データ操作することができる。 GAS（ GCP ）連携 先にも述べた通りで、 スタンドアロン 型のGASと連携できる。GASは GCP や外部システムとの連携が可能であり、これはつまり、ほぼ何でもありであることを意味する。 デメリット AppSheetにはデメリット、または使いにくそうな面ももちろんある。以下は、これまでの使用経験の中で感じた主要なデメリットであり、今後の改善に期待している。 UI作成の自由度は低い。特に要素配置やメッセージ表示の観点で不自由を感じることが多い。 環境移行の手間が比較的多い。アプリAからBへ丸っと移行はできるが、その際にGitのような移行前後の差分確認ができない。来歴管理については、開発画面で編集保存するたびにバージョンが自動更新されるようになっており、過去のバージョンに ロールバック させる機能が備わっている。 スプレッドシート のように他ユーザーの利用状況を確認できない。 スプレッドシート のようにアプリ画面で関数や条件付き書式の設定ができない。（開発エディターからは可能） 他ユーザーによる操作の反映がリアルタイムに行われない場合がある。その際は画面再読み込みが必要。 向いている用途 SQL 形式のデータ構造に基づく、業務用アプリケーションの作成に向いている。 NoSQLや複雑なデータ構造が必要なアプリケーションや、顧客向けアプリのようなオシャレで複雑なUIデザインが必要な用途には、向いていない。 また業務アプリケーションであっても、複数人で同時にテーブルの同一行を編集するような用途では、衝突により更新が拒否される場面が多くなる可能性があり、工夫が必要である。 今後期待している点 一番は、UIの柔軟性の向上である。表示のデザインや操作性には特に文句はないのだが、項目やボタンの配置の自由度がもっと上がれば、非常に使いやすい画面になると思っている。 またユーザーからの指摘で「なるほど」と思ったのは、 スプレッドシート のように「誰がどこで作業しているかを表示してほしい」という意見であった。業務に関する操作を行うのが目的である以上、他メンバーの状況が一目瞭然にわかるということは、進捗の把握や連携の向上といった点で、得られるものは大きいと思う。 Microsoft 製サービスとの比較 仕事と言えばエクセル（？）、エクセルといえば Microsoft ということで、長く独壇場を維持していた Microsoft も負けてはいない。 グループウェア のビッグ２といえば、 Google Workspace と Microsoft 365 であり、 Microsoft 365 には AppSheet と類似する Power Apps が含まれている。 Power Apps もノーコード・ローコードツールであり、 SharePoint に作成したテーブルなどをベースに、 Poser Automate の処理フローと連携して作成する業務アプリケーション作成ツールである。 Google AppSheet と比較した際の一番の特徴は、UI制作の自由度の高さである。項目の配置はもちろん、その大きさや配置など、極めて柔軟であり、自由である。 VBA のユーザーフォーム（UI)作成の操作感とよく似ていると思う。 ただ自由度が高いということは、それだけ手間がかかるということであり、実際、同じような画面を作る 工数 は、AppSheet と比べると Power Apps のほうが大きくなると感じている。 Google AppSheetのようにスッパリ割り切るのがよいか、それとも、 Microsoft Power Appsで納得いくまでこだわれる方がよいか、、このあたりはまさに悩みどころかもしれない。 終わりに 近年のノーコード・ローコードツールの発達は目覚ましく、AppSheetがその代表例の一つであることは間違いない。いろいろとツールを調べたり使ってみたりする中で思うようになったのは「拡張性の高いノーコード・ローコードツールを、エンジニアが使うことが重要」という点だ。 プログラミングスキルに乏しい状態でノーコード・ローコードツールを使っても、さほど便利なアプリは作れない。あくまで標準的に準備されている環境の中だけで構築することになるからである。 しかし、エンジニアが拡張性に優れたノーコード・ローコードツールを使うことで、 （生産性の低くなりがちな）UIや簡単な処理フローの構築をツールに頼って高速化しつつ、 ツール内では対応しきれないような複雑な処理フローについては、連動可能なプログラミング環境内で実装することで、その業務特有の複雑なプロセスにも対応できる。 という、両者のいいとこどりが可能となる。 また、操作性がよいゆえに、ノーコード・ローコードツールの開発者は、かつての VBA のように今後ジリジリと増えていくと思われる。こういったツールでは開発手法がより規格化されやすいので、同じ機能を実装した場合の開発者による差も生じにくい。 それゆえ、できるだけこういったツールを用いることで、開発／保守業務の属人化を極小化し、ひいては業務の継続性・安定性を高めることになると考えている。 明日の記事の担当は RDチーム の 廣島 さんです。お楽しみに。 株式会社 エニグモ すべての求人一覧 hrmos.co

こんにちは、データエンジニアの中村です。 新卒で入社してから、気づけば2年が経とうとしています。時間の流れは本当に早いものですね。 今回は、私がこれまで取り組んできたデータ基盤におけるアクセス制御に関する技術と取り組みについてお話ししようと思います。 昨日に引き続きデータ基盤関連の記事になりますが、ぜひ最後までご覧ください！ この記事は Enigmo Advent Calendar 2024 の 20日 目の記事です。 目次 背景 ポリシータグとは ポリシータグの利用イメージ ポリシータグによるアクセス制御の仕組み 使ってみた感想 まとめ 最後に 背景 弊社のデータ基盤はBigQueryを利用しており、社内の個人ユーザーやサービスアカウント経由での各種サービスからアクセスがあります。 データの種類によってはユーザー・グループ毎にカラムレベルでアクセスを制御したいケースが発生することがありました。 以前は、通常のviewと特定のグループに見せたくないカラムをexceptしたviewの二つを作成し管理していました。 図1: アクセス制御方法(旧) シンプルな構成で直感的に理解しやすいのでこのままでも良さそうでしたが、特定のカラムが閲覧不可のグループから要望があるたびにViewを用意する必要があるので、要望が多いと対応が大変になってしまいます。 その課題を解決するために、BigQueryの ポリシータグ という機能を利用してアクセス制御を行おうと考えました。 ポリシータグとは ポリシータグは、BigQuery上のテーブルで、列レベルでのアクセス制御を可能にする タグ機能 のことです。 以下はBigQuery上で実際にポリシータグを設定した時の画像です。アクセス制御したいカラムに対して、作成したポリシータグを紐づけることでカラム単位でのアクセス制御が可能となります。 図2: ポリシータグ ポリシータグの利用イメージ イメージを以下に示しました。 図3: ポリシータグによるアクセス制御方法 ざっくり言うと ポリシータグを作成 → ポリシータグに対して権限周りの設定をゴニョゴニョ → アクセス制御したい列に対してポリシータグを設定 → アクセス制御したい列の見え方がユーザーによって変わる といった具合です。 ここで重要なのが、 「同じテーブルを見ているのにユーザーによって見え方が変わる」 ということです。 これまでは閲覧権限のないカラムをexceptしたviewを作って権限管理していましたが、ポリシータグによって１つのテーブルでそれぞれの閲覧権限に応じて閲覧可能なカラムのみ見せられるようになりました。 図4: アクセス制御方法(新) 現時点ではまだ移行途中ですが、最終的には図1から図4へ完全移行を考えております。 それでは、どのようにして見え方を変えているのかを説明していこうと思います。 ポリシータグによるアクセス制御の仕組み ポリシータグの挙動を理解する上で重要なのが以下のロールです。 1. roles/datacatalog.categoryFineGrainedReader (きめ細かい読み取り) 2. roles/bigquerydatapolicy.maskedReader (マスクされたデータの読み取り) 名前からある程度想像がつきますね。 1は 「ポリシータグが付与されていても、データをそのまま見れる」 ロールで、2は 「ポリシータグが付与されている場合、データをマスクされた状態で閲覧できる」 ロールです。 この二つのロールを利用してアクセス制御を行います。 ポリシータグを作成 図3① して、ポリシータグをテーブルへ設定 図3⑤ するだけだと、どちらのグループも権限エラーでクエリすらできません。 まずは閲覧可能グループの場合ですが、1のロールを付与したIAMポリシーをポリシータグへbinding 図3② します。そうすると、閲覧可能グループがクエリしてもポリシータグが付与されているカラムはそのままの状態で閲覧できる状態になります。 次に、閲覧不可グループの場合ですが、2のロールを付与したIAMポリシーをポリシータグへではなくデータポリシーにbinding 図3④ します。 データポリシーというのはポリシータグに紐づいているデータの マスキングルール を決定するリソースであり、それに対してポリシーbindingを行います。マスキングルールは複数あるので、ケースに応じて適切なルールを選ぶと良いでしょう。 ここまで行うと、閲覧不可グループがポリシータグを設定した列を含むクエリを実行した場合、ポリシータグを設定した列がマスキングルールに従った状態で返ってくる状態になります。 まとめると以下のような挙動になります。 図5: ポリシータグの挙動 ③の状態になってしまうと、そもそもクエリが実行できなくなってしまうので、そうならないように全てのグループ・ユーザーが①or②の状態になることが理想です。 使ってみた感想 約1年半利用しましたが、正直なところ当初の課題であった「特定のカラムが閲覧不可のグループから要望があるたびにViewを用意する必要がある」というケースがあまり発生しなくなったので、利用前後でそこまで恩恵を感じておりません。 ですが、アクセス制御方法を移行することによって将来的に以下のメリットがあると思いました。 組織が拡大してさらに細かいアクセス制御が必要になった場合、ポリシータグの方が対応が容易 セキュリティポリシー の一元管理が可能になり、管理コストが削減される デメリットももちろんあり、以下のような状況に陥りました。 テーブルへのポリシータグ付与をAirflowで行なっており、そこで利用している API が タイムアウト になり連携処理が失敗・遅延してしまい後続処理へ影響が出てしまった。 新規で作成したSAが図5③の状況になり、各所からこれまで以上に権限付与依頼が届くようになった。 API の タイムアウト の件は、暫定でリトライ回数を増やして対応しました。 権限付与依頼の増加は、デメリットというよりメリット寄りかもしれません。というのも新規ユーザーがデータ基盤にアクセスする場合はどのような権限を持つべきかを考えるべきだと考えているので、その状態が作れていることはプラスであると思います。 (あまりに多くなってきたらもっと良いやり方がないか考えます。。) まとめ 現段階では総じてポリシータグによるアクセス制御への移行は個人的に微差でプラス寄りな気がします。 最終的に移行してよかったと思えるように日々運用方法は改善していこうと思います。 最後に 最後までご覧いただきありがとうございました！ 明日は佐伯さんよりAppSheetに関する記事をお届けします。お楽しみに！ 株式会社 エニグモ すべての求人一覧 hrmos.co

こんにちは、データエンジニアの中村です。 弊社ではBIツールとして Google Cloudから提供されている Looker を利用しています。 Lookerの利用者も徐々に増えており、日々データ活用が進んでいることは嬉しいですが、それと比例して気になるのは ダッシュ ボードの表示速度やクエリコスト等のパフォーマンスです。 最近 AggregateAwareness という機能を利用してパフォーマンスを改善することができたので、その機能を利用するに至った背景と、その改善効果を紹介したいと思います。 AggregateAwarenessの詳細な使い方は説明しないので、その点はご了承ください。 この記事は Enigmo Advent Calendar 2024 の19日目の記事です。 目次 背景 AggregateAwarenessとは 利用した結果 メリデメ まとめ 最後に 背景 弊社のデータ基盤はBigQueryを採用しており、LookerからBigQueryへのクエリでどのくらいのコストが発生しているかをモニタリングしています。 今年の8月ごろからクエリコストが増加していることが判明し、原因調査から始めました。 Lookerのコスト推移 原因はアクセス量の多い ダッシュ ボードにスキャン量の大きい Look を追加したことによるものでした。 対策としては、Lookに対応した軽量のデータマートを用意してあげることでコストを抑えるといった方法があると思いますが、パネル毎にデータマートを用意するのは大変ですし、メンテナンスコストも高くなります。 かといって、DWH層を一から整備していくのは時間がかかりそうです。 そこで、両者のメリットを兼ね備えた方法としてAggregateAwarenessという機能に辿り着きました。 AggregateAwarenessとは AggregateAwareness とは、 データマートに相当する、事前に集計されたテーブルを自動で作成し、クエリの際にそのテーブルを自動で認識してくれる機能 です。 ざっくりとした手順を以下に記載しますが、本題ではないので詳細は割愛します。利用方法はクラスメソッドさんの こちら の記事が参考になりました。 ①AggregateAwarenessを適用したいLookが参照しているExplore画面を表示 ↓ ②Explore画面より、AggregateAwareness用に自動生成されたLookMLをコピー ↓ ③コピーしたLookMLを、対象のexploreが定義されているmodelファイルのexploreブロックへコピペ ↓ ④Exploreからクエリを実行すると、BigQueryにLookMLで指定した条件で集計されたテーブルが作成される ↓ ⑤次回以降は④で作成された集計テーブルへクエリしに行ってくれるので、クエリパフォーマンスが向上する この方法だと、テーブルの作成をLooker側で行なってくれるので、 工数 をかけずにマートの作成が行えてよかったです。 また、パネルが不要になったら、コピペしたLookMLと自動で作成されたテーブルを削除すればクリーニングが済むので、後片付けが楽そうだと感じました。 紹介はここまでにして、AggregateAwarenessを利用した結果の方を説明していこうと思います。 利用した結果 AggregateAwareness適用後のコスト推移 グラフを見ると一目瞭然ですが、適用前後で大幅にコストを削減することができています。 修正した日付が11月14日なので、11/10の週から減少傾向になり、11/17の週から一気に削減効果が現れていますね。 クエリ一回あたりのコストも連動して減少しているので、クエリ回数が減ったことによる効果ではなさそうです。 コスト 期間① ※1 期間② ※2 減少率 クエリ全体のコスト(円) (省略) (省略) 71.8% クエリ1回あたりのコスト(円/クエリ) 13.75 3.53 74.3% ※1期間①: 10/14~11/13(修正日前日から直近1ヶ月) ※2期間②: 11/14~12/15(修正日当日から1ヶ月後まで) 具体的な数値だと、適用前後1ヶ月で全体のクエリコストを約71%、クエリ一回あたりのコストを約74%削減できました！ また、今回の対応を行うきっかけとなったパネル以外にもAggregateAwarenessを適用したことで、コスト増加前の期間よりも改善されていました。 コスト 期間③ ※3 期間② ※2 減少率 クエリ全体のコスト(円) (省略) (省略) 34.0% クエリ1回あたりのコスト(円/クエリ) 7.17 3.53 50.8% ※3期間③: 7/1~7/31(コスト増加前) 平常時と比較しても約50%のコスト削減効果を得られたので、年間を通してかなり効きそうですね。 なお、クエリパフォーマンスも改善されており、平常時の平均実行時間はは4秒程度だったものが、適用後は3秒程度まで減少していました。 クエリの平均実行時間の推移 コスト削減と同時に ユーザビリティ を向上させることもできました！ メリデメ AggregateAwarenessを使用してみて、以下のメリットがあると感じました。 メリット 簡単にデータマートを作成でき、削除する際もクリーニングが簡単 クエリのパフォーマンスが課題になっている場合、改善効果が大きい ただし、上記のメリットはあくまで短期的な視点で見た時のものであり、中・長期的な視点で考えると以下のようなデメリットもあると感じました。 デメリット パフォーマンスが低下するたびに対応が必要で、イタチごっごになってしまう。（スケーラビリティの低下） AggregateAwarenessの利用が膨大になると、メンテナンスコストが増加しそう。(このLookMLってどのLookに対応してるんだっけ？とかが起こる) これらのメリデメを加味してバランスよく利用していけばかなり有用な機能だと思いました。 メリットが大きすぎるので、個人的にはどんどん利用していきたいです。 まとめ AggregateAwareness を利用することで、Lookerのコストを約70%削減することができました。 平均クエリ実行時間も減少し、 ユーザビリティ の向上も同時に行えました。 「まだ利用していない&パフォーマンスを改善したい」場合は利用をお勧め！ 最後に 最後までご覧いただきありがとうございました！ 明日の記事の担当は、本日と同じくデータエンジニアの中村です。お楽しみに！ 株式会社 エニグモ すべての求人一覧 hrmos.co

こんにちは。エンジニアの竹田です。 BUYMA の検索システムやMLOps基盤の開発・運用を担当しております。 こちらは Enigmo Advent Calendar 2024 の18日目の記事です 🎄 はじめに 2024年もいよいよ年の瀬ですね！寒さが増すこの季節、みなさまいかがお過ごしでしょうか？ 早速ですが本記事の主題のシステムリプレイスについてです。 ここ言うシステムリプレイスとは、老朽化したシステムの刷新、管理目的での移設など、既存システムがあり、それを何かしらの方法で置き換えることを指しています。 例えば、古くなったオンプレミス環境を クラウド に移行したり、データベースをより新しいものに入れ替えるといった作業も含まれます。 サーバサイドから下位のレイヤを担当している方々は、システムリプレイスを行う機会が割と多いのではないでしょうか。 実際に自分も エニグモ に入社してからもそうですが、それ以前からも新規システムを構築するよりはシステムリプレイスを行うことが多いと感じています。 今までの実績 各種検索システムのリプレイス MLOpsシステムのkubeflow pipelines→vertex ai pipelinesへのリプレイス アカウント検知システムのリプレイス どんなシステムでも老朽化が進むため、定期的なリプレイスが必要です。 気が付くとサポート期限間近であったりということは少なくないのではないでしょうか。 ただ、新しいもの作りという訳ではないので、なかなかモチベーションを上げ辛い作業ではないかなと思います。 また、旧システムとインプットやアウトプットは変えない、というのが命題となるので、結果比較に時間を要したりとナーバスになる作業も多いです。 そんな中でも、モチベーションを高く保つために自分が意識していることを紹介したいと思います。 システムリプレイスのモチベーションを高めるために 改善のチャンスと捉える：システムの価値を高める！ 何か付加価値を提供できないかを考えます。 システムコストや学習コストの兼ね合いもありますが、思い切って足回りや ミドルウェア の置き換えなど検討しても良いと思います。 コスト削減 新たなマネージドサービスの利用 多めに見積もって構築されていたリソースの削ぎ落とし システム強化 少し気になっていたコードの修正 構成周りの定義での一工夫 マイクロサービス化 機能の一部を切り出して影響を局所化 監視強化 迅速な障害対応、柔軟な運用 学びのチャンスと捉える：自身のスキル底上げ！ 少なくとも現状を一切変更しないリプレイスはあまり存在しないと思います。 例えば、旧システムのデータベースを調査中に、想定外のデータ構造や運用上の工夫を発見することもあります。それが新システム設計のヒントになることもしばしばです。 そう考えると、以下の点で新しく学びを得られる機会があります。 各種ライブラリのバージョン最新化 動作差異の確認、理解 あまり深く知らない言語の理解 どの言語でも固有の特徴がある 旧システムの構成や思想の理解 wiki 等が残っていれば確認、当時の思想が全く分からないこともある... とにかく旧システムを把握しないことには作業を進めづらい アウトプットのチャンスと捉える：学びを共有して価値を広げる！ どういった方法でシステムを刷新したか、その意図など、技術ブログなどで外部発信する機会を得られます。 技術ブログの他にも、社内勉強会やカンファレンスでのLT（ライトニング トーク ）なども該当するかと思います。 自分もこの点はあまり実践できていないので、自戒の意味も込めて記載しています。 自身の技術棚卸し こういった機会を作ることで、振り返りの機会を設ける 外部向け文章作成の機会 企業 ブランディング への貢献 より気持ちを高めるために 関わったことのなかった方と関わりを持てる可能性がある 過去担当していた方と関わりを持ち、人間関係を広げる機会になる可能性があります。 怯むことなく関わりを持てるようにしましょう。 今どきな言い方をしてみる slack等でやりとりする際、リプレイスではなく モダナイズ という言葉を使ってみたりしています。 ただし、 クラウド の新機能を利用したり、インフラやアプリの構成を大幅に見直すような場合でないと名前負けした感じになるので注意が必要です。 最後に 以上のようなことを意識して取り組んでいるため、比較的楽しくシステムリプレイスを行っていると思っています。 システム規模が大きくなればなるほどリプレイスは大変になるので、立ち止まって特定の機能を切り出せないかを考えたりするのも良いと思います。 みなさんもシステムリプレイスを楽しむ方法を見つけて、エンジニアとしての成長を一緒に楽しんでいきましょう！ 明日の記事の担当は同グループの中村さんです。お楽しみに！！ 株式会社 エニグモ すべての求人一覧 hrmos.co

こんにちは！ WEBアプリケーションエンジニア の小松です！ この記事は[ Enigmo Advent Calendar 2024 ]の17日目の記事です。   Railsの場合: 自動的に日付オブジェクトとして認識 サンプルコード（Rails） Laravelの場合: 明示的な型変換が必要 サンプルコード（Laravel） RailsとLaravelの比較表 開発者の観点からの結論 Railsのメリット Laravelのメリット Rails の場合: 自動的に日付オブジェクトとして認識 Rails は ActiveRecord のORMを利用する場合だけでなく、 rawクエリを用いた場合でも date 型は Ruby の Date オブジェクトに変換されます 。そのため、日付フォーマットの変換を簡単に記述できます。 サンプルコード（ Rails ） テーブル定義 # migration create_table :events do |t| t.date :event_date t.timestamps end rawクエリの利用 result = ActiveRecord::Base.connection.execute("SELECT event_date FROM events LIMIT 1") raw_date = result.first["event_date"] # => #<Date: 2023-12-13> puts raw_date.strftime('%Y%m%d') # => "20231213" ポイント event_date は Ruby の Date オブジェクトとして取得される。 .strftime メソッドを直接利用してフォーマットを変更可能。 Laravelの場合: 明示的な型変換が必要 Laravelでrawクエリを使用した場合、 デフォルトでは date 型は文字列として取得されます 。そのため、フォーマットを変更する際は、明示的に Carbon オブジェクトなどに変換する必要があります。 サンプルコード（Laravel） テーブル定義 // migration Schema::create('events', function (Blueprint $table) { $table->date('event_date'); $table->timestamps(); }); rawクエリの利用 use Illuminate\Support\Facades\DB; use Carbon\Carbon; $result = DB::select("SELECT event_date FROM events LIMIT 1"); $rawDate = $result[0]->event_date; // => "2023-12-13" (文字列) $carbonDate = Carbon::parse($rawDate); echo $carbonDate->format('Ymd'); // => "20231213" ポイント event_date は文字列として取得される。 PHP の Carbon ライブラリを利用して明示的に日付オブジェクトに変換する必要がある。 Rails とLaravelの比較表 特徴 Rails Laravel rawクエリでの date 型の扱い 自動的に Date オブジェクトとして認識される 文字列として取得される 日付フォーマットの変更 .strftime('%Y%m%d') が直接利用可能 Carbon::parse($date)->format('Ymd') が必要 追加の変換処理の必要性 不要 必要 デフォルトの開発者体験 日付操作が非常に簡潔で直感的 明示的な型変換が必要で、柔軟性が高い 適用範囲 ActiveRecord でもrawクエリでも同じ Eloquentとrawクエリで挙動が異なる 開発者の観点からの結論 Rails のメリット 開発効率が高い : 日付型は自動的に Date オブジェクトとして認識され、変換処理を意識する必要がありません。 統一性がある : ActiveRecord でもrawクエリでも同じように扱えます。 時間をかけてハマる前に、まず .to_sql でクエリを確認 する習慣をつけると、 デバッグ がスムーズになります！ Laravelのメリット 柔軟性が高い : Carbon を使えば、細かい日付操作や タイムゾーン 操作が可能です。 設計の自由度 : 明示的な変換により、モデルや ユースケース に応じた日付処理を柔軟に適用できます。 Rails は「標準的な処理が簡潔」、Laravelは「柔軟性を重視」といった フレームワーク の哲学の違いが、日付型の扱い方にも表れています。どちらを選ぶかはプロジェクトの要件やチームの好みに依存しますが、簡潔さを求める場合は Rails が有利です。

こんにちは！ WEBアプリケーションエンジニア の小松です！ この記事は[ Enigmo Advent Calendar 2024 ]の16日目の記事です。     コンソールを使った デバッグ は開発において非常に重要です。 フレームワーク や言語ごとに特性が異なるため、それぞれの仕組みに慣れる必要があります。以下に PHP や Rails を例に、 デバッグ 手法や注意点を詳しく解説します。 1. PHPのデバッグ方法 2. Railsのコンソール機能 3. RSpecでのデバッグ 結論 1. PHP の デバッグ 方法 PHP には Ruby on Rails のような標準的なコンソール機能（例： rails console ）が存在しません。そのため、 デバッグ の際には以下の手法を使うことが一般的です。 var_dump() の利用 PHP では主に var_dump() が使われます。これは CLI からの実行でも WEBブラウザ 経由のアクセスでも有効です。 例 : $data = ['name' => 'John', 'age' => 30]; var_dump($data); CLI での PHP スクリプト 実行 テスト スクリプト を作成して CLI から直接実行する方法もあります。これにより、サーバーを介さずに デバッグ が可能です。 2. Rails のコンソール機能 Rails には標準で rails console が用意されており、 デバッグ やテストに非常に便利です。ただし、注意すべき点もいくつかあります。 関数のテストが容易 Rails のコンソールでは、関数やクラスを直接呼び出してテストできます。 例 : def greet(name) "Hello, #{name}!" end puts greet("Alice") #=> Hello, Alice! デバッグ における注意点 Rails コンソールでの デバッグ には p を使用しますが、 PHP の var_dump() と異なるため、切り替えを忘れることがあります。 例 : data = { name: "John", age: 30 } p data #=> {:name=>"John", :age=>30} コード変更時の再起動 コードを変更した場合、 Rails コンソールに入り直す必要があります。これを忘れると、古いコードのまま デバッグ を続けることになり、時間を無駄にする原因になります。 3. RSpec での デバッグ RSpec の デバッグ でもコンソールと似ています。以下に注意点と手法を挙げます。 p を利用した デバッグ RSpec では、ログを確認するよりも p を使う方が効率的な場合があります。しかし、つい忘れてしまうことも多いです。 例 : it "tests addition" do result = 2 + 2 p result #=> 4 expect(result).to eq(4) end コード変更時の挙動 RSpec コードそのものを変更する場合、通常は何もせずにテストを実行できます。しかし、テスト対象のロジックを変更した場合、特定の環境では注意が必要です。 コード変更と反映 テスト用のコード変更は即時反映されますが、今の開発環境では実際のアプリケーションコードを変更した場合はDockerコンテナを再起動する必要がある場合があります。この手順を忘れると、古いコードで デバッグ を進めてしまう可能性があります。 手順 : コードを変更する。 以下のコマンドでコンテナを再起動する。 結論 PHP や Rails 、 RSpec 環境それぞれに特有の デバッグ 手法と注意点があります。特に Rails やDocker環境ではコード変更時の再起動を忘れがちになります。また、各環境での デバッグ 手法に慣れることで、無駄な時間を減らし、生産性を向上させることができます。

こんにちは！ WEBアプリケーションエンジニア の小松です！ この記事は[ Enigmo Advent Calendar 2024 ]の15日目の記事です。   PHPの場合 呼び方の具体例 文字列キーを使ったハッシュアクセス 文字列キーアクセスを使う場面 シンボルキーを使ったハッシュアクセス オブジェクト形式（OpenStruct）のアクセス 確認方法 クラス内のインスタンス変数の確認方法 シンボルはRubyのみ存在? PHP の場合 model['full_name'] こういう変数の持ち方を 連想配列 と呼んでいただけなので、シンボルキーという言葉と発想がなかったです。 呼び出し方でも model['full_name'], model[:full_name], model.full_name などがあり、 <%= debug model %> やログでオブジェクト全体の値が取れてもキーの持ち方が違って取得するのに時間がかかることがありました。 なので、呼び方の具体例や呼び出し方を記載しました。 model['full_name'] のような形式は、文字列キーを持つハッシュから値を取得する方法です。このような形式でのアクセスは、 Ruby の基本的なハッシュオブジェクトの操作です。 呼び方の具体例 文字列キーを使ったハッシュアクセス Ruby では、ハッシュのキーとして文字列（String）を使う場合に、この形式でアクセスします。 model = { 'full_name' => ' AIR JORDAN 13(エアジョーダン13)' } puts model['full_name']  # => " AIR JORDAN 13(エアジョーダン13)" 文字列キーアクセスを使う場面 JSON パーサーからのデータ: JSON を Ruby でパースした場合、デフォルトではハッシュのキーが文字列になります。 シンボルキーを使ったハッシュアクセス Ruby では、ハッシュのキーとしてシンボル（Symbol）を使うことも一般的です。この場合は、:full_name のようにしてアクセスします。 model = { full_name: ' AIR JORDAN 13(エアジョーダン13)' } puts model[:full_name]  # => " AIR JORDAN 13(エアジョーダン13)" オブジェクト形式（OpenStruct）のアクセス OpenStruct を使うと、ドット 演算子 （.）でプロパティにアクセスできます。 require 'ostruct' model = OpenStruct.new(full_name: ' AIR JORDAN 13(エアジョーダン13)') puts model.full_name  # => " AIR JORDAN 13(エアジョーダン13)"   確認方法 model.class を実行することで、オブジェクトがハッシュなのか、OpenStruct なのか、あるいは別の型なのかを確認できます。その型に応じたアクセス方法を選びましょう。   クラス内の インスタンス 変数の確認方法 インスタンス 変数の取得方法も初めは時間がかかりました。 docs.ruby-lang.org p obj.instance_variable_get(:@foo)  このように取得するみたいです。   シンボルは Ruby のみ存在? Python 、 PHP 、C、Go、 JAVA などには存在せず、 Javascript には存在するけど、挙動が少し違うようです。 qiita.com 慣れればメリットもあるとの事ですが、他の言語にない概念なので、 Ruby 使い始めは正直紛らわしかったです。  

こんにちは、インフラグループの片桐です。 この記事は Enigmo Advent Calendar 2024 の 14 日目の記事として、サーバ機器管理台帳を 表計算 ツールから OSS の「NetBox」に移行した取り組みについて紹介します。 はじめに サーバ機器やネットワーク機器、各機器に付随する IPアドレス の情報など、サーバ機器や関連情報をまとめる為に「機器管理台帳」は欠かせないものになっています。その中で、機器管理台帳は Excel や Google スプレッドシート 等の 表計算 ツールで管理されているケースもよく見られます。 表計算 ツールを台帳として機器管理している場合、台帳の規模が拡大するにつれて、管理すべき各種情報が複数のシートやファイルに分散しがちです。これにより管理コストが増大し、整合性の維持も難しくなります。こうした状況に心当たりのある方も多いのではないでしょうか。 弊部署も同様に、 表計算 ツールを用いた煩雑な機器管理に悩まされていました。そこで、データセンターのインフラ管理（DCIM)と IPアドレス 管理(IPAM)を兼ねるツールであるNetBoxを導入し、機器情報管理の一元化・整合性維持を試みました。本記事では、機器管理台帳の 表計算 ツール管理からNetBox移行について、取り組み内容、移行に際する知見等を紹介します。  用語の整理 DCIM DCIM(Data Center Infrastructure Management)は、データセンターに関連するサーバ機器やネットワーク機器、ラック、配電や配線、設備など、さまざまなリソースを管理・可視化するためのツールや手法のことです。DCIMおよびDCIMツールを導入することで、ハードウェア配置や容量、ネットワーク接続状況などを一元管理することが可能となります。 IPAM IPAM(IP Address Management)は、ネットワーク内で使用される IPアドレス を一元的に管理し、その割り当てや利用状況、変更履歴などを可視化・追跡するためのツールや手法のことです。IPAM及びIPAMツールを導入することで、利用可能な アドレス空間 のシステム的な管理と、管理に伴ったIP重複割り当ての予防等が可能となります。 NetBox NetBoxは、DCIMとIPAMの機能を併せ持つ OSS です。サーバ機器やラック構成、 IPアドレス 、ケーブル接続など、データセンターまわりの情報を一元的に、かつわかりやすく管理することに特化しています。 Webインターフェースや REST API を通して各機器やネットワーク関連のデータを登録・編集・参照できるため、機器情報の管理をするだけでなく、管理の簡略化・自動化も可能です。 お試しで触りたい方向けの公式デモ版サイトも公開されています。 github.com 移行の背景と課題 これまで、弊部署の機器管理台帳には複数ファイル/複数シートを跨ぐ Google スプレッドシート を使用しており、以下をはじめとする各種情報を管理していました。 ハードウェア関連：機材情報、シリアル番号、ラック配置、納品日/保守期限、各機材のLAN接続状況 ホスト関連：ホスト名、各 NIC ごとの IPアドレス 割り当て状況 etc... 台帳上の各機器について、あるシートではホスト名と IPアドレス の紐づけ、あるシートではホスト名とラック上の設置位置の紐づけ...等、1箇所のデータを更新した際に関連するデータを複数シート上で合わせて更新する運用でした。 一方、この管理方式には以下の様な課題もあります。 台帳更新の煩雑さ: 1つの機器について複数ファイル/複数シートを跨いで情報が登録されている場合。 シート上のある箇所を変更した際、別シートや別セルの依存箇所も特定して修正する必要がある。 依存箇所を漏れなく特定できる運用フローや仕組み構築が必要になる。 整合性管理の困難さ: 台帳更新の煩雑さ にも関連。 依存箇所の修正漏れが起きやすい状況下にて、依存データ間で整合性の取れていないデータが発生した場合に事実確認の手間が発生する。 外部連携の困難さ: 機器管理台帳に限らず、 表計算 ツールで作成された各種データファイルが完全な CSV 形式で構築されていない場合。 台帳上に存在する情報を読み込んで プログラマブル に利用したい場合や、外部のシステムにデータを取り込む際、各環境が扱える状態に一度変換する手間がある。 これらの課題に対してNetBoxを導入し、対応を試みました。 NetBoxのデプロイ NetBoxのデプロイ先として、社内向けツール用に構築しているEKS( Amazon Elastic Kubernetes Service) クラスタ 上に構築しました。 インストールには、Netbox Communityの GitHub 上で公開されている Helmチャート(netbox-chart) を使用しました。 github.com helmを利用する場合は 利用ガイド を読みながら、ご自分の環境に合わせて values.yaml の各値を変更してセットアップする流れとなります。 特に 管理者ユーザ周りの設定値 はログイン時に使用するため、ご利用の環境に合わせて事前設定することをおすすめします。 NetBoxへのデータ登録 NetBoxに登録できる項目について データの登録を始める前に、既存の機器管理台帳では何の情報を管理しているのか、NetBoxには何の情報を登録できるのかを一通り把握しておくことを推奨します。 ドキュメントをご参照いただくと分かる通り、NetBoxに登録できる項目は多岐にわたり、かつきめ細かい情報を登録であるため、最初から全ての情報を入れ込むことが難しい場合も想定されます。 (以下NetBox ドキュメントの models 配下の大項目、並びに大項目配下の詳細情報を各機器/各グループ毎に入力可能となっています。) github.com もしスモールスタートで「データセンタ内の機器情報、ラックへの機器マウント情報、各機器へのLAN配線、 VM ホストとゲスト VM の紐づけ、各 NIC への IPアドレス アサイ ン」程度で運用を開始したい場合は、以下図のmodel項目を参考に入力していくことで簡素版な環境を構築可能です。 データの登録 NetBoxの導入を検討した当初は スプレッドシート 上に散在していた情報を1件ずつ確認しながら手動で登録することも考えていましたが、登録すべき情報を整理していく中で、数百台以上の機器や IPアドレス 、接続情報等をすべて手動で移行するのはあまりにも現実的ではない事に気付きました。 一方、NetBoxには機器追加/変更/削除等のデータ操作を楽にする為の仕組みが複数整備されており、一括でのデータ操作が可能となっています。 CSV / YAML 形式での一括インポート: NetBoxのWEBインターフェースの機能として、 CSV / YAML 形式でのデータの一括インポートに対応しています。 登録するデータを各形式に整形して事前に整備出来ている場合、各model毎のWEB UI上から楽にデータをインポート可能です。 1行目に各modelに対応するヘッダを、2行目以降に登録するデータを入力する形で定義します。 CSV 形式インポートの入力例 REST API でのデータ操作: NetBoxに実装されている REST API を活用することで、各種データ操作を プログラマブル に行う事も可能です。 CSV でのインポートはデータの登録のみ可能ですが、 API を利用することで CRUD 各処理を複雑な条件式を絡めて実行することも可能となります。 Netbox API Document 上記2種類の一括操作方法を実施して、既存の機器管理台帳上のデータを移行していきました。 スプレッドシート から移行する際の知見 移行前の情報を整理した上で、完全に正規化された CSV を作成するべき 移行前の スプレッドシート には現状との乖離として、例えば以下の様な不整合が発生していました。 新しいホストに付け替えた IPアドレス が古い機器に付随されたままになっている。 ホスト名を変更したが、旧ホスト名のまま台帳に登録されている。 不整合を一つ一つ修正するのは非常に手間の掛かる作業となる上、独自管理の形式から完全な状態の CSV 形式に落とし込むことは、手間と時間の掛かる作業となります。 一方、NetBoxには強力な CSV インポート機能が備わっているため、一度完全な状態の CSV を作成してしまえば、NetBoxの運用は直ぐにでも開始可能です。 私は不整合の解消作業は実施したものの、完全な状態の CSV を作成する前に移行を始めてしまった為、変更が必要な所は REST API を使用して適宜修正する形での対応となりました。 再度移行作業を実施する機会のある際には、完全に正規化された CSV を作成してから実施すべきと実感しました。 NetBoxに登録する情報の精査と入力先カラムの確認 前述の完全に正規化された CSV を作成した後は、 CSV 上のカラムをNetBox上のどのモデルに入れるかを予め検討しておくべきでした。 ラックの情報は dcim > racks に、機器のモデル名やシリアルは dcim > devices に、IPは ipam > ip-addresses に登録出来る、あるいはこの項目について入力できそうな項目が存在しない、等を先行して把握しておくべきでした。 例えば、NetBoxには機器の納品日や保守期限といった項目を入力出来る箇所が標準項目としては存在しません。 そのため、機器情報の自由記述欄となる Comment カラムに入力するか、 カスタムフィールド を追加することで、標準機能外の情報管理もNetBox上で可能になります。 一括登録を実施する前に、整理された CSV の項目とNetBoxの入力項目を比較して、このデータは何処に入るのか？を明確にしておくとスムーズなデータの投入が可能でした。 カスタムフィールドで機材納品日の入力欄を追加する例 NetBox導入によって感じたメリット 情報の一元管理と可視化: NetBox移行後は IPアドレス 、機器モデル、シリアルナンバー、物理配置、接続関係など、あらゆる情報をNetBoxで一元的な管理が可能となりました。 スプレッドシート を利用していた頃は、ある箇所を修正した際依存する情報の修正を、複数シート/複数ファイルに跨って手動で行う必要がありました。 NetBox移行後には依存情報の修正も行われるため、整合性保持にも寄与します。 エクスポート/インポートの柔軟性: 前述の通り、NetBoxにデータを登録する際は CSV / YAML 形式でのインポートが可能です。 また、NetBoxに登録されている情報は、 CSV / YAML 形式でのエクスポートも可能であるため、将来的に別の管理基盤へ移行する際にもデータ移行が容易になることが見込まれます。 拡張性と自動化: NetBoxには REST API や各種WebHookが実装されています。 API による台帳上のデータの一括操作が可能になった他、WebHookによって台帳に新規機材が追加された際にSlackなどチャットツールに通知する等の対応が可能となりました。別途仕組み作りを実施することで柔軟な対応が可能となるため、今後の拡張性として期待が高まりました。 サー バラック の情報可視化例。ラックの色のついている部分には登録した機器が紐づいている まとめ スプレッドシート からNetBoxへと台帳管理を移行した結果、情報一元化や更新作業の効率化が期待できる基盤が整いました。初期構築やデータ整備に手間はかかりましたが、その分、長期的な整合性維持と運用自動化の可能性が大きく広がりました。 一方、現時点では、NetBoxの基本的な機能を用いて、ハードウェアと IPアドレス 、簡易な接続情報を一元管理する段階にとどまっています。今後は運用を通じて API やWebHookの活用や NetBoxのプラグイン導入 など、さらなる効率化と可視化を進めていきたいと考えています。 明日の記事の担当はWEBアプリケーションエンジニアの小松さんです。お楽しみに。 株式会社 エニグモ すべての求人一覧 hrmos.co

こんにちは！インフラエンジニアの森田です！ この記事は Enigmo Advent Calendar 2024 の12日目の記事です。 また、11日目の Googleスプレッドシート編 の続きであるため未読であればそちらからご一読いただければと思います。 前回の記事ではZapierで扱うデータのインプットとなる スプレッドシート の解説を行いましたので、今回は処理とアウトプットを行うZapの解説を行います。 現在以下のZapが稼働していますが、 毎月22日に翌月の発表者へまとめてリマインド 毎週月曜日に発表者へリマインドし、発表予定がなければ募集する 発表があれば開始のアナウンスをし、発表予定がなければスキップのアナウンスをする 今回は翌月の発表者へまとめてリマインドするZapの解説を行いたいと思います。 毎月22日に翌月の発表者へまとめてリマインド 1.毎月22日にトリガー まず、翌月頭の発表者の準備期間が取れるように毎月22日にトリガーするようにしています。 キャプチャと同じように設定すれば毎月のトリガーとなります。 2.翌月が何月か計算 次の工程で使用するために翌月が何月なのかを取得しています。 具体的には1のトリガーが次に動く日付(翌月の22日)から 正規表現 で何月かを抽出しています。 import re print (input_data[ 'next' ]) result = re.findall( r'-\d{2}-' , input_data[ 'next' ]) return { 'result' : result[ 0 ].replace( '-' , '' )} 3.翌月の行を取得 翌月発表の行をまとめて取得してきています。 具体的には「リマインド管理シート」に開催月という列があったと思いますが、開催月が2で取得したものと同値かつ開催フラグがTRUEの行を取得しています。 注意が必要なのがEventの設定で、「Lookup Spreadsheet Rows」と「Lookup Spreadsheet Rows (Advanced)」という似たイベントが存在しますが、「Lookup Spreadsheet Rows」では取得できる行が1行のため、翌月の発表全てというような複数行取得したい場合は「Lookup Spreadsheet Rows (Advanced)」を選択する必要があります。 4.Slack送信メッセージ作成 3で取得した要素をSlackのメッセージへ整形するため python で実装しています。 date_list=input_data[ 'date' ].split( ',' ) title_list=input_data[ 'title' ].split( ',' ) SlackID1_list=input_data[ 'SlackID1' ].split( ',' ) result = f ''' 【{input_data['month']}月 Hacker’s Delightスケジュールのお知らせ】 {input_data['month']}月のスケジュールの予定はこちらです。発表者の方は準備をよろしくお願いします。 何かあれば @devrel へご連絡ください ''' for i in range ( len (date_list)): string = f " \n {date_list[i]}：{title_list[i]} <@{SlackID1_list[i]}>" result = result + string print (result) return { 'result' : result} それぞれの発表の部分はリストの要素分ループで回して戻り値へ加算(追記)していく形になっています。 5.Slackへ送信 4で整形したメッセージ(戻り値)をシンプルにSlackのチャンネルに送信しています。 実際に以下のようなメッセージが送信されます。 Zapの解説は以上になります。 おわりに 今回は1つのZapを用いて解説を行いましたが、11日目の記事で解説したインプットがあれば 毎週月曜日に発表者へリマインドし、発表予定がなければ募集する 発表があれば開始のアナウンスをし、発表予定がなければスキップのアナウンスをする 上記のようなリマインドも実装することができます。 また、今回 エニグモ で行っている アドベントカレンダー のリマインドも同じ要領で自動化しています。 スケジュールを把握して色々なメンバーにリマインドをするというのは思いの外意識を割かれてしまうため、 Google スプレッドシート とZapierが利用できる環境にあれば是非自動化にチャレンジしていただければと思います。 2記事に分かれて長かったですが、お読みいただきありがとうございました。 明日の担当はRDチームの 廣島 さんです。お楽しみに。 株式会社 エニグモ すべての求人一覧 hrmos.co

こんにちは！インフラエンジニアの森田です！ この記事は Enigmo Advent Calendar 2024 の11日目の記事です。 私は社内の勉強会チーム(DeveloperRelationsチーム)としても活動しており、 人力で行なっていたリマインドをZapierで自動化したのでそのご紹介をしたいと思います。 今回は毎週金曜日に実施している軽い勉強会( Hacker'sDelight )のリマインドの自動化を例に記載します。 元々は以下のようなスケジュール管理シートがあり、こちらを人の目で見て翌月の発表者やその週の発表者にSlackでリマインドを送るという運用をしていました。 ただずっと人力でリマインドを送るというのはツラいため、社内で自動化ツールのZapierを契約しているため折角なら自動化してしまおうということで自動化に着手しました。 調べながらZapを作成する中で意外にZapierの日本語のドキュメントが少なかったため、この記事が備忘録かつ同じような自動化をやりたい方の参考になればと思います。 今回の自動化を構成しているのは大きく分けて以下の3要素になります。 スケジュール管理シート(パブリック) リマインド管理シート(クローズド) Zap 全ての要素の解説を１記事で行うと長くなってしまうため今回は「スケジュール管理シート」と「リマインド管理シート」の解説を行います。 Zapの解説は12日目の記事で解説したいと思います。 スケジュール管理シート(パブリック) 以下が「スケジュール管理シート」です。 基本的に上で貼ったスケジュール管理シートと同様ですが、「リマインド管理シート」でSlackIDをメールアドレスから自動検索するために列が追加されています。 こちらのシートは基本的にパブリックになっており、一般メンバーもHacker'sDelightのカレンダーとして見ることができます。 全て手動で管理しているので特に言及するところはありませんが、この後の解説で関連してくる列は以下となります。 内容 発表者1,2（敬称略） 発表者1,2メアド 日程 リマインド管理シート(クローズド) 「リマインド管理シート」は「Zapier通知用」と「Slackメンション用IDリスト」の2つのシートからなります。 Zapier通知用 このシートは「スケジュール管理シート」から参照した値から計算して自動的に埋められるため、手動での管理は不要になっています。 それぞれの列の解説をします。 日程 発表内容 発表者1,2 発表者1,2メアド これらの列は全て「スケジュール管理シート」からそのまま参照しています。 別の スプレッドシート から値を参照してくるには IMPORTRANGE関数 を使用します。 例) =IMPORTRANGE("https://docs.google.com/spreadsheets/d/xxxx","2025!G4") また、発表者の部分は敬称を スプレッドシート 側で入れておきたいので カスタム数値形式 で「@さん」と入れることで自動で敬称を付与するようになっています。 開催月 MONTH関数 を用いて何月に開催されるのかを抽出しています。 これは翌月の発表をまとめてリマインドするのに使用します。 例) =MONTH(A2) 当日までの日数 日程のセルから TODAY関数 で今日の日付をマイナスすることで発表当日まで何日なのかを算出することができます。 例) =A2-TODAY() メンション用ID VLOOKUP関数 で「Slackメンション用IDリスト」から発表者メアドに対応した IDを取得してきています。 元々人力でメンション用IDを探してコピペしていましたが辛すぎるうえミスが分かりずらいため、IDは自動で取得されるようにした方が良いと思います。 例) =VLOOKUP(F2,'Slackメンション用IDリスト'!$A$3:$B$1435,2,FALSE) 開催フラグ 発表があるのかないのかを判別するために ISBLANK関数 で発表内容のセルを空白判定しています。 また、そのままだと発表がある(セルが埋まっている)とFALSEと判定され違和感があるため、 NOT関数 で逆の論理値が返されるようにしています。 例) =NOT(ISBLANK(D2)) Slackメンション用IDリスト 以下のドキュメントを参考にメンバーリストを取得すると、ユーザーのメールアドレスとUserIDが記載された csv ファイルが取得できます。 ワークスペースのメンバーリストをダウンロードする こちらのシートは csv の内容をそのままコピペしたものです。 Zapierを使ってユーザーにメンションをする際にはこのUserIDが必要になります。 注意が必要なのはこのメンバーリストがSlackのオーナーまたは管理者権限を持っていないと取得できない点です。 不特定多数が見られる場所に書かれるのは好ましくないため、「リマインド管理シート」の参照権限はクローズドで必要のあるメンバーのみが見られるようにするべきです。 Zapierでリマインドを行うためのインプットとなる スプレッドシート の解説は以上となります。 明日の記事では実際にリマインドを行う部分であるZapの解説を行います。 株式会社 エニグモ すべての求人一覧 hrmos.co

この記事は 私は、株式会社 エニグモ でチームのマネージャをしている後藤です。 マネージャ業務の傍ら開発作業を行うこともあります。 この記事は Enigmo Advent Calendar 2024 の10日目の記事です。 この記事では多くの Ruby を使っている人が、使っているであろう ruby-lsp を少し便利にする ruby-lsp-addons について紹介しながら、 VSCode でどのように活用できるのかについて紹介したいと思います。 ruby -lspとは ruby-lsp とは、 Ruby 言語向けに Microsoft が定義している、 Language Server Protocol を実装したサーバになります。 Language Server Protocol (以下 LSP ) は、プログラム中に定義されたクラス名、関数名、変数名などを取得できる API とデータ型を定義したものになります。プログラム中のデータを取得する API を定義しておくことで、エディタから対象言語に対応した LSP サーバーを通して 関数定義情報を表示、関数/変数の定義箇所へのジャンプ、関数名/変数名を使った入力補間ができるようになります。 LSP の登場以前は universal-ctags + GNU Global などを用いて同様の機能を実現することが多かったように思いますが、 VSCode の登場と合わせて LSP の提案と普及が進みました。その結果、多くのエディタで LSP がサポートされるようになり、最近は補間や関数ジャンプのための機能が LSP に集約されつつあるように思います。 Visual Studio Code ( VSCode ) の場合は、 ruby-lsp プラグイン を VSCode に追加することで ruby ソース編集次に ruby -lsp を使った関数ジャンプや入力補間が使えるようになります。 ruby -lsp-addons ruby -lsp ですが、当然ながら ruby の文法しかサポートしていません。ただ、 Ruby on Rails の場合はモデルの has_many、blongs_to、validates などなど多数の DSL がありこれらもOUTLINEなどに表示して欲しいところですが、その機能を ruby -lsp に実装するのも違っている気がします。 そんな問題を解決しようとしているのが、 ruby-lsp-addons 機構になります。 公式のドキュメントは Add-ons | Ruby LSP にあります。ただ、公式ドキュメントにもあるように実験的な取り組みのようで、 ruby-lsp のメジャーバージョンが変わると、 インターフェイス が変わって addons が動かなくなることもありますし、将来a addons のサポートが終わってしまう可能性があることを心にとめて置いてください。 それでは、 ruby-lsp-rails ruby-lsp-rspec について紹介していきたいと思います。 ruby-lsp-rails こちらの add-on を使えるようにするには、 ruby-lsp-rails gem を追加します。 名前からわかる通り、 rails 固有の機能サポートを追加するadd-onになります。 今回は、 gitlabhq/gitlabhq のソースの一部を表示しながら、 公式ドキュメントからいくつかの機能を抜粋して紹介したいと思います。 modelの DSL サポート # frozen_string_literal: true module Achievements class Achievement < ApplicationRecord include Avatarable include StripAttribute belongs_to :namespace , inverse_of : :achievements , optional : false has_many :user_achievements , inverse_of : :achievement has_many :users , through : :user_achievements , inverse_of : :achievements strip_attributes! :name , :description validates :name , presence : true , length : { maximum : 255 }, uniqueness : { case_sensitive : false , scope : [ :namespace_id ] } validates :description , length : { maximum : 1024 } def uploads_sharding_key { namespace_id : namespace_id } end end end のようなコードがあると、 VSCode の OUTLINE には以下のように Rails 固有の DSL で定義された項目も表示されます。 コントローラーメソッドからviewへのジャンプ コントローラのメソッド画面にviewを開くリンクが追加されます。 上の絵の赤枠で囲ったリンクが表示されるようになります。 この、 Jump to view をクリックすることで view が表示されます。 地味に、便利です。 その他の機能 公式ドキュメントを読むと、モデルの belongs_to のアソシエーション先にジャンプできる機能、コントローラーのメソッド定義箇所から ルーター の定義にジャンプできる機能などがあることになっていますが、上手く機能していないようです。この辺は実験的な取り組みということを温かく見守ることしましょう。 ruby-lsp-rspec 次は、 ruby -lsp- rspec です。 こちらも add-on を使えるようにするには、 ruby-lsp-rspec gem を追加します。 こちらも名前から想像できる通り、 rspec 向けの機能拡張を行う add-on になります。 以下のような specファイルを開くと、 # frozen_string_literal: true require " spec_helper " RSpec .describe Diffs :: StatsComponent , type : :component do include RepoHelpers subject( :component ) do described_class.new( diff_files : diff_files) end let_it_be( :project ) { create( :project , :repository ) } let_it_be( :repository ) { project.repository } let_it_be( :commit ) { project.commit(sample_commit.id) } let_it_be( :diffs ) { commit.raw_diffs } let_it_be( :diff ) { diffs.first } let_it_be( :diff_refs ) { commit.diff_refs } let_it_be( :diff_file ) { Gitlab :: Diff :: File .new(diff, diff_refs : diff_refs, repository : repository) } let_it_be( :diff_files ) { [diff_file] } describe " rendered component " do subject { page } let( :element ) { page.find( " .js-diff-stats-dropdown " ) } before do render_inline component end ... VSCode の OUTLINE に以下のように、 examples のテキストが表示されるため、 spec ファイルの流れを追うのも、修正をするのも楽になります。 また、以下のようにspecファイル上に Run | Run In Terminal | Debug リンクが追加されます。 このRunなどをクリックすることで、 rspec のテストを実行できます。また、これらのテスト機構が、 VSCode の テスト機能に統合されているため、 以下のような VSCode 標準の、 Test: Run Test at Curosr などの機能が利用できるようになります。 また、テスト結果についても GUI で表示られるようになります。 テスト結果がエラーになっているのは、DBなどを構築せずテストだけ実行したためで、gitlab のバグではありません。 使いたいんだけど、プロジェクトの Gemfiles に組み込めないんだけど VSCode の ruby -lsp ですが、インストール時の設定では、プロジェクトに bundle install されているものを使う設定になっていると思います。そのため、プロジェクトの他のgemとの依存関係の問題で使いたくても最新の ruby-lsp が使えない、なんて問題に出会う事があると思います。 そのような場合は、 ruby-lsp などの ruby 開発サポート系ツールだけをインストールした リポジトリ を準備し、bundler でインストールした bin ディレクト リへ PATH を通しておいて、 VSCode 上の設定を変更することで、プロジェクトは独立した形で、 ruby-lsp を使うことができます。 手順は以下のようなGemfileを準備し # frozen_string_literal: true source ' http://rubygems.org ' gem ' ruby-lsp ' gem ' ruby-lsp-rails ' gem ' ruby-lsp-rspec ' 対象 ディレクト リで、 bundle config path vendor bundle install しておき、 VSCode の settings.json にいかの項目を追加します。 " rubyLsp.bundleGemfile ": "$ { インストールディレクトリ } / Gemfile " 私の場合は、 asdf を使って ruby をいれているのもあってrubocop、erblint などをひとまとめにしたチェック系ツールをまとめた リポジトリ を作り、homebrewと asdf 用の環境セットアップをするラッパー スクリプト を通して、bundle exec する シェルスクリプト から各種ツールを起動する リポジトリ を作って使っています。 また、PCが変わっても VSCode の設定が変わらないよう上記 リポジトリ を /opt/ruby_tool へcloneしています。 参考のために、 ruby_tool へのリンクも貼っておきます。頻繁にバージョンを上げたり、ツールを入れ替えたりしているので、ご利用される際は、forkしてお使いください。 最後に 最後までお読みくださりありがとうございました。 明日の記事の担当は 森田 さんです。お楽しみに。 また、株式会社 エニグモ では、ツールやエディタのカスタマイズを 愛する人 エンジニアもそうでないエンジニアも広く募集しております。興味のある方は、以下の求人一覧をご覧ください。 株式会社 エニグモ すべての求人一覧 hrmos.co

こんにちは、データアナリストの井原です。 この記事は Enigmo Advent Calendar 2024 の9日目の記事です。 私は、普段データアナリストとして エニグモ で働いています。データからビジネスの意思決定を行うための示唆を出し、関係者に正しく伝えることが主要な業務です。 最近、チームの勉強会でも話題になったのですが、データアナリストは伝え方って大事だよねという話がありました。その場ではさらっと話が進んだのですが、確かに、データアナリストはいつもポジティブな結果ばかりを伝えるわけではありません。企画者が苦労をしてリリースにこぎつけた施策で、結果も期待されていてという状況で、数字がよくなかった、または、懸念点が上がってきたということも多いです。 この記事では個人のこれまでの経験を振り返って、ネガティブなことを伝えなければいけない時に、どのようなことに気をつけたらよいかを考えてみたいと思います。 この1年を振り返ってみても、結果を伝えにくいと思う案件はいくつかありました。「事前検証ではそれなりに効果が出そうであると（自分が）押した案件が、蓋を開けてみると効果はかなり微量だった。」「これまで重点的に企画が行われてきた施策について、利益性が低そうだと伝えなければいけなかった。」などなど。 そんな自分の経験を通して、どんなことに気を付けるとよさそうか、5つ洗い出してみました。挙げてみた要素はあくまでも個人の意見ではありますし、自分も常にうまくやれているわけではないのですが、自戒もこめて書いていきたいと思います。 1.言いやすい関係性を作っておく いきなり、そもそもといった内容にはなりますが、元々の関係性はかなり重要な要素だと思います。 これは、言う側だけでなく言われる側の身を想像しても、それまで関係性の薄い第 三者 から言われるよりは、自身の取り組みを知ってくれている人の方が受け入れやすくなると考えられます。 そのためには、可能な限り、企画の段階でデータアナリストも企画に入っていけるようにするとよいと思います。また、分析の時点から入らざるを得ないとしても、こまめに質問や進捗を伝えるなどして、コミュニケーションを増やしておくといざという時には伝えやすくなります。 巨大な組織だと難しいところもあるかもしれませんが、 エニグモ は比較的少人数の組織なので、その辺りはやりやすい気はしています。 2.言葉遣いに気を付ける 当たり前ではあるのですが、伝える時の言葉遣いは気を付ける必要があります。特に意識をしていないと、さらっと否定的な言葉が（そこまで否定的だと意識せず）つい出てしまう場合があります。 例えば、「意味がない」とか「ダメですね」のような全否定の言葉は使わないように自分は気をつけます。「この数字だとちょっと厳しいかもしれません」や「想定と違うかもしれませんが、どうですか？」のような、相手と会話していく姿勢を出すだけでも建設的に話せるのではないかと思います。 前項とは反対になりますが、言いやすい関係を作りすぎてしまうと、ぽろっと否定的な言葉も出やすくなってしまう（気軽に話せるので言葉を意識しなくなりやすい）側面もあるので、この辺りはバランスを考えてうまく調整出来るとよいのではないかと思います。 3.最初に「言いづらい結果なのですが」と言ってしまう これはテクニック的な話ではありますが、会議の最初に言ってしまうと、言う方も聞く方も受け入れる準備が出来るので楽になるのではないかと思います。あるいはタイミングがあれば、「今分析しているのですが、厳しい結果が出るかもしれません」と雑談的に話しておくのもよいでしょう。 根本的にはもう少し他の項目の方が大事ではないかとも思いますが、相手に結果を受け入れてもらうということも、アナリストの重要な仕事の一つです。こういった地味なテクニックを意識しておいて損はないと思います。 4.相手に労いと尊敬の気持ちを持つ 言葉遣いなどに繋がる話ですが、施策を進めているメンバーはその企画に対してかけた労力や思いがあります。その労力や思いに対しては、労いと尊敬の気持ちを持つことが大事です。 相手の企画に対しての思いを知る過程で関係性も作れると思いますし、言葉遣いも下手な言葉遣いはしにくくなると思います。例えば、相手が大切に思っていることに対して、「意味ないよ」などとは、ある程度の良識があれば言いにくいですよね。 5.それでも遠慮はしない、自分の分析結果には自信を持つ 相手を思いやることは大事だと思いますが、一方で、データアナリストとして伝えるべきことは伝えなければなりません。 そのため、最終的には自分の分析結果に対して自信を持つことも大事です。 伝えづらい分析結果が出てきた時、多くの分析者は分析内容を振り返ったり、よさそうな点を見つけようとデータをさらに詳細に区切って細かい分析を行ったりなど、よくあるのではないかなと思っています。しかし、持てる知識をフル活用して分析を行った結果なのであれば、下した結論がネガティブな内容であっても、それはしっかりと伝える必要があります。 伝え方自体は上で書いたように気を付ける必要がありますが、結論はしっかりと相手に伝わるように、準備できればよいと思っています。 おわりに 自分の一年間を振り返りつつ、ネガティブなことを伝えなければならない時に気を付けていること（きたこと）を洗い出してみました。 世の中には、データから新しい知見を発見して、それを活用して成功しました！というポジティブな話が多いと思いますが、現実のデータ分析では、新しい発見やポジティブな結果が確認できることばかりではありません。むしろ、特に目新しくない結果、ネガティブな結果が出てくる方が多いと思われます。 データアナリストという立ち位置は、時に第 三者 的な視点での意見が求められる職種ですので、データの解釈は冷静に客観的に行わなければなりません。しかし、それを伝えるところまで責任を持つという点では、合理性や客観性以外の人情的なコミュニケーションも必要になってくると思います。 少しでも、今回の話がデータを取り扱う方々の参考になったら幸いです。お読みいただきありがとうございました。 明日の記事の担当はエンジニアの後藤さんです。お楽しみに。 株式会社 エニグモ すべての求人一覧 hrmos.co

こんにちは！Webアプリケーションエンジニアの レミー です！ この記事は Enigmo Advent Calendar 2024 の 8日目の記事です。 Ruby on Rails 8が新しくリリースされ、Kamalという迅速かつ便利なデプロイツールが統合されました。私はこれまで Ruby on Rails アプリケーションのデプロイに Capistrano を使用していましたが、Kamalを試してみると、その便利さと簡単さに魅了されました。 この記事では、Kamalを使用して Ruby on Rails 8アプリケーションを AWS EC2サーバーにデプロイする手順を詳しく説明します。 Kamalとは？ Kamalは 37Signals のチームによって開発された新しいデプロイメントツールです。このツールを使用すると、デプロイメントプロセスを1つのファイルで定義でき、複雑な手順を簡素化できます。ほとんどのアプリケーションで考慮する必要がない複雑な部分を省略することが可能です。Kamalは、DockerコンテナやTraefikなどのソフトウェアを組み合わせて動作します。セットアップ段階から包括的なソリューションを提供し、 Rails アプリケーションを最短時間で本番環境にリリースできます。 Kamalはどのように動作するのか？ Kamalは、サーバー上でDockerコンテナ内にWebアプリケーションを実行し、Traefikを組み合わせてネットワーク トラフィック を処理します。新しいバージョンをデプロイする際、Kamalは以下の手順を実行します： 新しいDockerイメージをビルドする。 新しいイメージからコンテナを起動する。 新しいコンテナが正常に動作しているかを検証する。 Traefikを更新して、 トラフィック を新しいコンテナにルーティングする。 古いコンテナを停止する。 特に注目すべき点は、ダウンタイムなしのデプロイメントを実現し、blue/greenデプロイメントをサポートしていることです。 Ruby on Rails アプリケーションのサーバーの準備 ここでは、 AWS EC2でサーバーを準備します。 EC2 インスタンス の作成 Ubuntu Server 24.04 を選択します。 Keyペアは SSH とサーバーへのアクセスに使用します。 セキュリティグループでは、以下のポートを開放してください： 22 : SSH 用 80 : HTTP用 443 : HTTPS 用 SSH 権限の設定 まず、ローカルの公開鍵をコピーします。 cat ~/.ssh/id_rsa.pub インスタンス を起動したら、先ほど作成したKeyペアを使って、 ubuntu ユーザーでサーバーに SSH 接続します。 IPアドレス は新しく作成した インスタンス のものを使用します。 ssh ubuntu@ 18.182 . 197.19 -i /path/to/key.pem 次に、ローカルでコピーした公開鍵をサーバーの ~/. ssh /authorized_keys ファイルに貼り付けます。 ssh-rsa AAAABEAAAADAQABAAABgQ...AAAAB3Nzac2EAAAADAQABA Yuto MacBook Pro これでサーバーの準備は完了です。以降は以下のコマンドでサーバーに SSH 接続できます。 ssh ubuntu@ 18.182 . 197.19 Ruby on Rails 8アプリケーションの作成 まず、kamaltest という名前で Ruby on Rails 8アプリケーションを作成します。 rails new kamaltest プロジェクト ディレクト リに移動します。 cd kamaltest このアプリケーションは、タイトルと内容を持つ簡単なブログになります。そのため、scaffoldを使用して構築します。 rails g scaffold article title content:text データベースを作成します。 rake db:migrate routes.rb ファイルでホームページを設定します。 root "articles#index" アプリケーションを起動します。 bin/dev その後、 http://localhost:3000 にアクセスすると、アプリケーションが起動していることが確認できます。 deploy.ymlファイルでKamalを設定する Ruby on Rails 8ではKamalが既に統合されています。それ以前のプロジェクトにKamalを追加する場合は、Gemfileに kamal を追加し、以下のコマンドを実行します。 kamal init このコマンドを実行すると、Kamalがアプリケーションをデプロイするための設定を含む config/deploy.yml ファイルが生成されます。 Kamalの基本設定 デプロイのための設定は以下のようになります。 image: yutoyasunaga/kamaltest servers: web: - 18.182.197.19 # server IP proxy: ssl: true host: kamaltest.sampleapp.net registry: username: yutoyasunaga password: - KAMAL_REGISTRY_PASSWORD ssh: user: ubuntu image : Docker Hub上に保存されるDockerイメージの場所 servers web : サーバーの IPv4 アドレス proxy ssl : true に設定すると SSL が自動的に設定されます host : 使用する ドメイン registry username : Dockerアカウントのユーザー名 password : Dockerアカウントのログ インパス ワード。セキュリティのため、 KAMAL_REGISTRY_PASSWORD シークレットを通じて取得します。 ssh user : サーバーに SSH 接続する際のユーザー Kamalのシークレット 機密情報は .kamal/secrets ファイルに配置します。以下はその例です。 # 環境変数からレジストリパスワードを取得 KAMAL_REGISTRY_PASSWORD=$KAMAL_REGISTRY_PASSWORD シークレットは 環境変数 から取得します。例えば、Dockerのパスワードが hogehoge の場合、以下のように設定します。 export KAMAL_REGISTRY_PASSWORD= 'hogehoge' 以下のコマンドで値を確認できます。 echo $KAMAL_REGISTRY_PASSWORD Kamalでデプロイを開始 config/deploy.yml の設定が完了したら、以下のコマンドを使用して初回のデプロイを開始します。 kamal setup このコマンドは以下の処理を行います： SSH キーを使ってサーバーに接続。 サーバーにDockerがインストールされていない場合は、get.docker.com を使ってDockerをインストール（ SSH 経由でrootアクセスが必要）。 レジストリ にローカルおよびリモートでログイン。 アプリケーションのルートにある標準的なDockerfileを使用してDockerイメージをビルド。 イメージを レジストリ にプッシュ。 レジストリ からイメージをサーバーにプル。 kamal-proxy がポート80および443で トラフィック を受け入れることを確認。 現在のGitバージョンのハッシュに一致するアプリケーションバージョンで新しいコンテナを起動。 新しいコンテナが GET /up リク エス トに対して200 OKを返す場合、kamal-proxy に トラフィック を新しいコンテナにルーティングさせる。 前バージョンのアプリケーションを実行している古いコンテナを停止。 使用されていないイメージや停止したコンテナを削除して、サーバーの容量を確保。 デプロイが成功すると、次のような結果が表示されます。 Finished all in 70.0 seconds 初回のデプロイは kamal setup を使用しますが、2回目以降のデプロイでは kamal deploy のコマンドを使用します。 permission denied エラーの解決方法 初回のデプロイで以下のようなDockerに関連するエラーが発生した場合： Releasing the deploy lock... Finished all in 47.9 seconds ERROR (SSHKit::Command::Failed): Exception while executing on host 54.250 . 243.158 : docker exit status: 1 docker stdout: Nothing written docker stderr: permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post "http://%2Fvar%2Frun%2Fdocker.sock/v1.47/images/create?fromImage=yutoyasunaga%2Fkamaltest&tag=4985d03bae739286203ce1185efdd4b2c71f90a9" : dial unix /var/run/docker.sock: connect: permission denied 次の手順で解決できます。 サーバーに SSH 接続します。 ssh ubuntu@ 18.182 . 197.19 以下のコマンドを実行して、現在のユーザーをDockerグループに追加します。 sudo usermod -aG docker $USER && newgrp docker Dockerが正常に動作するか確認します。 docker ps 以下のような出力が表示されれば成功です。 CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES デプロイ後の結果を確認 まず、 https://hub.docker.com にアクセスして、イメージがプッシュされていることを確認します。 Route53を使用して ドメイン を管理している場合、以下のようにホストゾーン内でレコードを作成し、 ドメイン をサーバーのIPに向けます。 設定が正しい場合、 https://kamaltest.sampleapp.net にアクセスすると、アプリケーションの画面が表示されます。 このように、1分ほどで Ruby on Rails アプリケーションをサーバーにデプロイし、 ドメイン と SSL の設定まで完了しました。便利ですね！ 🎉 よく使われるKamalコマンド aliases: console: app exec --interactive --reuse "bin/rails console" shell: app exec --interactive --reuse "bash" logs: app logs -f dbc: app exec --interactive --reuse "bin/rails dbconsole" デフォルトの deploy.yml ファイルでは、以下の4つの便利なコマンドが定義されています。 kamal console : Rails コンソールにアクセス kamal shell : サーバー上のコンテナにアクセス kamal logs : サーバーログを確認 kamal dbc : データベースコンソールにアクセス Kamalでのアセットのデプロイ RUN SECRET_KEY_BASE_DUMMY=1 ./bin/rails assets:precompile Dockerfile にはすでにアセットをプリ コンパイル するコマンドが定義されています。そのため、デプロイ時にアセットも自動的に処理されます。 Kamalでの 環境変数 （Environment Variable） 開発環境の 環境変数 の設定 開発環境では、 dotenv gem を使用します。 公式 リポジトリ : https://github.com/bkeepers/dotenv Gemfileに dotenv を追加 以下のコードを Gemfile に記載します。 group :development, :test do gem 'dotenv' end 環境変数 を管理する .env ファイルを作成し、例は以下のように記載します。 TEST_ENV_CLEAR=env_clear_local TEST_ENV_SECRET=env_secret_local 環境変数 が正しくロードされているかを Rails コンソールで確認します。 ENV .select { |key, _| key.start_with?( " TEST_ENV " ) } => { " TEST_ENV_CLEAR " => " env_clear_local " , " TEST_ENV_SECRET " => " env_secret_local " } 本番環境の 環境変数 の設定 現時点では以下の方法を使用していますが、より良い方法が見つかれば変更する予定です。 本番環境用の 環境変数 を管理する .env.production ファイルを作成します。 TEST_ENV_SECRET=env_secret_prod deploy.yml ファイルに 環境変数 を設定します。 env: secret: - TEST_ENV_SECRET clear: TEST_ENV_CLEAR: env_clear_prod clear : deploy.yml ファイルに直接記載される 環境変数 。 secret : 機密情報を含む 環境変数 で、 .kamal/secrets ファイルから読み込まれます。 .kamal/secrets ファイルで 環境変数 を以下のように設定します。 TEST_ENV_SECRET=$(cat .env.production | grep TEST_ENV_SECRET | cut -d '=' -f 2) 上記の設定は、 .env.production ファイルから情報を抽出します。 例えば、 .env.production に以下の行が含まれている場合： TEST_ENV_SECRET=env_secret_prod コマンド cut -d '=' -f 2 によって env_secret_prod が抽出されます。 デプロイ後、 Rails コンソールにアクセスして 環境変数 を確認できます。 kamal console ENV .select { |key, _| key.start_with?( " TEST_ENV " ) } => { " TEST_ENV_SECRET " => " env_secret_prod " , " TEST_ENV_CLEAR " => " env_clear_prod " } Kamalは、 Ruby on Rails アプリケーションのデプロイを大幅に簡素化し、効率化する強力なツールです。ぜひKamalを使ったデプロイに挑戦してみてください！ 株式会社 エニグモ すべての求人一覧 hrmos.co