本記事は、2025年8⽉6⽇に公開された Amazon QuickSight BIOps – Part 1: A no-code guide to version control and collaboration を翻訳したもの です。翻訳は Public Sector PSA の西川継延が担当しました。 ビジネスインテリジェンス（BI）チームが成長するにつれて、ダッシュボード、データセット、分析の管理はますます複雑になります。明確なバージョン管理なしでのコラボレーションは、作業の上書き、レポートの不整合、本番環境でのエラーにつながる可能性があります。ビジネスのステイクホルダーは迅速なインサイトを要求しますが、BI 作成者は変更を間違いなく繰り返し、自信を持ってデプロイするためのツールを欠いていることがよくあります。 DevOps の原則に着想を得たビジネスインテリジェンスオペレーション（BIOps）は、BI プロセスにバージョン管理と共同開発を導入します。この記事では、 Amazon QuickSight のノーコードのコンソール機能を使用して BIOps を実装する方法を説明します。ダッシュボードのバージョン管理、ビジュアルの再利用、並行でのコラボレーション、そして更新の安全なデプロイを、すべて QuickSight UI を通じて行う方法を紹介します。私たちのフレームワークは、QuickSight に組み込まれたバージョン管理ツールを使用して、チームが管理を合理化し、手作業を削減するのに役立ちます。このコード不要のアプローチは、BI アナリストとダッシュボード作成者の両方がこれらのプラクティスをすぐに採用するのに役立ちます。 QuickSight の基本 このセクションでは、Amazon QuickSight におけるビジネスインテリジェンスオペレーション（BIOps）の基本を紹介します。QuickSight のアセットがどのように分類されるか、基礎となる権限モデル、そして私たちのオペレーションを導く不可欠な BIOps の原則という3つの主要な領域を検証します。 アセットの分類 QuickSight はアセットを4つのカテゴリに整理し、それぞれが BI ワークフローで特定の目的を果たします。 メインアセット – これらは中核となる構成要素であり、QuickSight コンソール上でスタンドアロンのオブジェクトとして表示されます。これらのアセットは相互に依存しています。例えば、分析はデータセットに依存し、データセットはデータソースに依存します。 データソースは、 Amazon Redshift 、 Amazon Athena 、 Amazon Simple Storage Service (Amazon S3) などのシステムに接続します。 データセットはデータソースから構築され、結合、カスタム SQL、計算フィールドを含むことができます。 分析は、ビジュアルを構築するためのインタラクティブな環境です。 ダッシュボードは、分析が公開されたもので、読み取り専用のバージョンです。 Amazon Q のトピックは、自然言語クエリのためのセマンティックレイヤーを定義します。 補助アセット -これらはユーザーエクスペリエンスを向上させますが、QuickSight UI では主要なオブジェクトではありません。例えば、テーマはダッシュボードや分析のスタイルを定義しますが、QuickSight コンソール上ではスタンドアロンのアセットとしてリストされません。しかし、テーマは API を介してプログラム的にスタンドアロンのオブジェクトとして管理でき、 list 、 describe 、 update 、 delete などの操作をサポートします。 セカンドクラスアセット – これらはメインアセット内の内部コンポーネントであり、カスタム SQL、テーブル、フィルター、計算フィールド、パラメータなどが含まれます。これらの要素は QuickSight コンソール UI 上ではスタンドアロンのオブジェクトではなく、直接的なリスト ( list ) や詳細表示 ( describe ) の API コールを通じてもアクセスできません。代わりに、データセット、分析、またはダッシュボードの定義内で定義されます。これらは QuickSight コンテンツのロジック、構造、およびインタラクティビティを定義する上で重要な役割を果たします。 フォルダ – これらはメインアセットを階層構造に整理するために使用される管理アセットです。個人用または共有フォルダを作成してアセットを分類できます。フォルダはアクセス権限をサポートし、1つのアセットは複数のフォルダに存在できます。 権限モデル QuickSight のメインアセット、補助アセット、および管理アセットは、安全なコラボレーションのためにユーザーおよびグループレベルの権限をサポートしています。 BIOps の基本ワークフロー BIOps には３つのコア機能が含まれます。 アセットのバックアップと復元 – これは通常、AWS アカウントごと、または AWS リージョンごとにスコープが設定されます。このプロセスにより、誤った削除、サービスの中断、またはデータの破損が発生した場合に QuickSight アセットを復元できることが保証されます。 バージョン管理 – これは同じ AWS アカウント内で適用でき、BI チームはアセット定義（例えば、データセットやダッシュボード）への変更を追跡したり、以前のバージョンにロールバックしたり、時間の経過とともに異なる開発ブランチを維持したりできます。 デプロイメント – これは環境間（例えば、開発アカウントからテスト、QA、本番アカウントへ）およびリージョン間（例えば、 us-east-1 から us-west-2 へアセットをデプロイ）でのアセットの昇格をサポートします。 BIOps ワークフローを使用すると、チームはアセットレベルとフォルダレベルの両方でデプロイとバックアップを管理できます。ダッシュボードをデプロイする際、チームは機能をサポートするために依存アセット（データセット、データソース、テーマ）を含めることができます。フォルダレベルの操作により、関連するアセットを単一のパッケージとして昇格させることが可能になります。AWS アカウント間でのデプロイには、慎重な権限管理が必要です。アセットタイプにはユーザーまたはグループの権限があり、セキュリティを維持し、依存関係の破損を防ぐために、ターゲット環境で適切に再作成する必要があります。 次の図は、BIOps ワークフローの概要を説明したものです。バージョン管理は、QuickSight コンソール UI を通じても実現できます。 QuickSight ダッシュボードの構築と公開 次のグラフに示すように、QuickSight のダッシュボード開発プロセスは、BI 作成者から始まります。BI 作成者は、アクセス管理を簡素化するためにグループにまとめることができます。 作成者はまず、QuickSight を Amazon Redshift などのストレージシステムに接続してデータソースを作成します。次に、変換、結合、カスタムフィールドを追加してデータセットを構築します。データセットの鮮度は、手動またはスケジュールされた更新によって維持され、モニタリング機能も備わっています。 これらのデータセットを使用して、作成者はビジュアルとインタラクティブなコンポーネントを備えた分析を作成します。一貫した組織のブランディングのためにテーマを適用することができます。最終ステップは、分析をダッシュボードとして公開し、特定のユーザーやグループと共有することです。このプロセスにより、ガバナンスを維持しながら、スケーラブルなセルフサービス BI が可能になります。 ソリューションの概要 この記事では、３つの主要な QuickSight 機能について説明します。 コンソール UI を通じた ダッシュボードのバージョン管理 異なる分析からダッシュボードを公開することによる並行でのチームコラボレーション 他の分析やダッシュボードから ビジュアルをインポート することによるコンテンツの再利用 QuickSight コンソールのこれらの新機能により、ノーコードのインターフェースを通じて効率的な BI コラボレーションとダッシュボードのライフサイクル管理が可能になります。作成者は以下のことができます。 ダッシュボードとデータセットのバージョン履歴を追跡する ダッシュボードを以前のバージョンにロールバックする アセットを手動で複製する 分析とダッシュボード間でビジュアルをインポートおよびエクスポートする アセットの説明を通じて変更を文書化する ブックマークを使用してパーソナライズされたビューを作成する 元に戻す（undo）とやり直し（redo）機能で分析の編集を管理する これらの機能は、コーディングの経験を必要とせずに、合理化されたガバナンスとチームコラボレーションをサポートします。 この記事では、ノーコードでUIベースのワークフローに焦点を当てます。このシリーズの パート 2 と パート 3 では、QuickSight API とプログラム可能なアプローチを使用した自動化されたガバナンスとデプロイについて説明します。 UI ベースのデータセットとダッシュボードのバージョン管理 QuickSight は 2021 年後半にネイティブな データセットのバージョン管理 を導入しました。ユーザーは、QuickSight コンソール UI 内で直接、最大 1,000 の公開済みバージョンを追跡および管理できます。データセットの所有者は、過去の状態をプレビューしたり、以前のバージョンに戻したり、安全に編集したりできます。これには、互換性のない変更（削除されたソースや無効な計算など）に対する保護機能が含まれています。 2025 年 4 月、QuickSight は  ダッシュボードのバージョン管理 を導入し、バージョン管理機能をデータセットから完全なダッシュボードへと拡張しました。ダッシュボードの所有者は、UI を通じてバージョンの管理、変更の追跡、以前の状態への復元を、コードを書くことなく行えるようになりました。技術チームは引き続き API ベースの自動化を選択するかもしれませんが、アナリストやビジネスユーザーはこれらの機能を利用して、エンドツーエンドのダッシュボードライフサイクル管理を容易に行うことができます。 次の図は、QuickSight のダッシュボード開発における、バージョン管理された継続的インテグレーションと継続的デリバリー（CI/CD）のワークフローを示しています。 ワークフローは、分析の作成と編集（バージョン 1）から始まり、次にそれをダッシュボードバージョン 1 として公開します。QA テストの後、ダッシュボードが合格すれば、分析はバージョン 2 に更新され、再公開されます。QA テストがどの時点でも失敗した場合、チームは現在のバージョンの編集を続けるか、以前のバージョンにロールバックすることができます。このサイクルは、公開、テスト、更新という反復的な開発を続け、変更が本番環境に到達する前に検証されることを保証します。「元に戻す」「やり直し」アクションは分析内の変更をサポートし、バージョンのロールバックは BI チームの安全性と俊敏性を高めます。 分析における軽微な編集のための「元に戻す」「やり直し」 QuickSight で分析を編集する際、作成者は 「元に戻す」および「やり直し」 オプションを使用して、変更が永続的になることを心配せずに実験できます。分析内で最大 200 のアクションを元に戻したり、やり直したりすることができ、ツールバーのアイコン（次のスクリーンショットを参照）を使用してアクセスできます。 ダッシュボードの公開とバージョン履歴 分析がダッシュボードとして公開されると、QuickSight は自動的に新しいバージョンを作成します。ダッシュボードの所有者は、 バージョン履歴 を表示することでこれらのバージョンを管理できます。そのためには、ダッシュボードを開き、上部ツールバーのバージョン履歴アイコンを選択します（次のスクリーンショットを参照）。 これにより、現在公開されているバージョンと、タイムスタンプや各バージョンを公開したユーザーを含むすべての以前のバージョンのリストが表示されるペインが開きます。そこから、必要に応じて以前に公開されたバージョンを確認、比較、復元できます。この機能は、ダッシュボードの変更履歴を明確に追跡でき、所有者はコンテンツがどのように変化してきたかを把握することができます。 間違いが発見されたり、以前のバージョンが好まれたりした場合、所有者はワンクリックでダッシュボードを以前のバージョンにロールバックできます。 このバージョン管理機能は、公開された各ダッシュボードの完全なスナップショットを保持することで、手動での再作業を削減します。他のバージョンへのアクセスを失うことなく以前のバージョンを復元でき、安定性を維持しながら迅速なイテレーション（反復）を可能にします。 UI ベースの並行作成とコラボレーション 次の図は、単一の QuickSight 開発アカウント内で複数の作成者が並行してコラボレーションする方法を示しています。共有フォルダ「QA Assets」は、再利用可能なコンテンツを一元管理する場所として機能し、作成者はダッシュボードを拡張したり、ビジュアルを再利用したり、バージョンを独立して管理したりできます。 この例では、３人の作成者が共有の開発ワークフローに貢献しています。 Ying は分析 1 を作成し、それをダッシュボード 1 として公開し、チームのための再利用可能なアセットを確立します。 Julia は分析 2 を作成し、ダッシュボード 1 から選択したビジュアルをインポートします。これにより、既存の作業を基に構築しながら、独自のバージョンを維持できます。その後、ダッシュボード 2 を公開します。 Rushabh はダッシュボード 2 の「 名前を付けて保存 」オプションを使用して分析 3 を作成し、さらにカスタマイズしてダッシュボード 3 を公開します。Rushabh は、分析 3 を公開してダッシュボード 1 を置き換えることで、ダッシュボード 1 を更新することもできます。 このアプローチは 2 つの主要な利点をサポートします。 並行開発 – 各作成者は、共有アセットを参照しながら独立して作業します。これにより、上書きや競合の変更のリスクなしに、複数のダッシュボードや機能を同時に開発できます。 副次的な変更を伴わない安全な修正 – 本番のダッシュボードに迅速な修正が必要な場合、作成者は公開されたバージョンから開始し、ターゲットを絞った編集を行い、再公開することができます。これにより、開発中の元の分析にある未完成のビジュアルや実験的な変更を導入することがありません。 これらの機能を組み合わせることで、バージョンの追跡可能性が促進され、リスクが最小化され、大規模なコラボレーションが合理化されます。共有フォルダとモジュール式のワークフローにより、QuickSight はエンタープライズ BI チームにとって強力なプラットフォームとなります。 ダッシュボードを分析として保存 公開後、ダッシュボードはさらなる変更のために分析として 保存 できます。作成者は、次のスクリーンショットに示すように、「 名前を付けて保存 」オプション（フロッピーディスクアイコン）を使用して、利用中のダッシュボードから新しい分析を作成できます。 新しい分析は個人のリストに表示され、自由に編集できます。元のダッシュボードに影響を与えることなく、ビューをカスタマイズしたり、ビジュアルを試したりできます。 他の分析やダッシュボードからビジュアルをインポート QuickSight の ビジュアルのインポート機能 を使用すると、分析間でダッシュボードコンポーネントを効率的に再利用し、標準化できます。分析ツールバーから「ビジュアルのインポート」を選択し、共有または個人のアセットを参照して 1 つ以上のビジュアルをインポートします。クエリ、フォーマット、インタラクションを含むインポートされたビジュアルは、現在の分析にコピーされ、元のソースに影響を与えることなく独立してカスタマイズできます。この機能により、ダッシュボードの開発が合理化され、ビジュアルの一貫性が促進され、チーム間の重複が削減されます。 分析からダッシュボ​​ードを公開 QuickSight で 既存のダッシュボードを置き換える には、公開時に「既存のダッシュボードを置き換える」を選択します。これにより、セキュリティ設定や E メールレポートの設定に影響を与えることなく、ダッシュボードが新しい変更で更新されます。 ダッシュボードを分析として保存する、任意の分析からダッシュボードを公開する、他の分析やダッシュボードからビジュアルをインポートするなどの機能を組み合わせることで、BI チームは開発ワークフローにおいて強力な柔軟性を得ることができます。チームはダッシュボードを並行して開発でき、複数の作成者が異なる機能やビジュアルに独立して取り組むことができます。また、元の分析にある進行中または実験的なビジュアルを誤って本番バージョンに導入することなく、本番ダッシュボードの問題を安全に修正することもできます。このモジュール式で管理されたアプローチは、本番環境での安定性を維持しながら、アジャイルなイテレーション（反復）をサポートします。 ダッシュボードを壊さずにデータセットを置き換える QuickSight のフィールドタイプは、ビジュアル、フィルター、計算がどのように機能するかを決定します。データセットのスキーマ変更が分析の要件と競合すると、ダッシュボードの障害が発生する可能性があります。次のスクリーンショットは、フィルターとビジュアライゼーションのキーフィールドとして SaleDate を使用して構築された、映画チケット販売ダッシュボードの例です。 データセットが更新されました。この更新中に、 SaleDate は Date（日付）フィールドから Integer（整数）に変更されました。 再公開後、ダッシュボードは SaleDate に関連付けられたビジュアルを読み込むことに失敗しました。影響を受けた各ビジュアルには、「データセットが変更されすぎたため、QuickSight が分析を自動的に更新できませんでした」というメッセージが表示されました。 円グラフのレンダリングが停止し、時間比較のビジュアルが失敗し、 SalesDate のフィルターコントロールが機能しなくなりました。 すでにダッシュボードを動かしているデータセットのスキーマを更新する際、データ型の不一致（フィールドを Date から Integer や String に変更するなど）は、ビジュアルが破損する一般的な原因です。 スキーマの変更が意図的な場合は、次のことを行う必要があります。 影響を受けるフィルターを再作成する 新しいデータ型を認識するようにビジュアルを更新する スキーマの変更が意図的でない場合は、次のことができます。 不要な変更が含まれていない以前のデータセットバージョンに戻す QuickSight でデータセットを置き換える際、フィールドマッピングの不一致によるビジュアルの破損も一般的なリスクです。これを軽減するために、QuickSight は現在、次のアクションを実行します。 不一致が検出された場合にフィールドマッピングを更新するようユーザーに自動的に促す スキーマの類似性に基づいてフィールドを自動的にマッピングしようと試みる スキーマが完全に一致しない場合にレビューのための不一致ダイアログを表示する 一致しない、または不整合なフィールドは手動で調整する必要があります。QuickSight は検出された不一致に対してマッピングを強制しますが、ユーザーが提供したマッピングの正確性を検証しません。スキップされたり不適切なマッピングは、依然としてビジュアルの破損を引き起こします。正しいフィールドマッピングにより、ビジュアルが新しいデータセットで期待通りにレンダリングされることが保証されます。 まとめ 新しい QuickSight コンソール機能により、ダッシュボードとデータセットのライフサイクルをコードフリーで管理できます。チームは、バージョン管理、ロールバック機能、並行開発、ビジュアルの再利用を活用して、より安全で効率的なワークフローを作成できます。 自動化、CI/CD 統合、またはプログラムによるガバナンスを必要とするチームのために、このシリーズの パート 2 と パート 3 では、API ベースの BIOps ワークフローについて説明します。 著者について Ying Wang は、AWS のジェネレーティブ AI 組織に所属するシニアスペシャリストソリューションアーキテクトで、Amazon QuickSight と Amazon Q を専門とし、大企業や ISV のお客様をサポートしています。彼女はデータアナリティクスとデータサイエンスで 16 年の経験を持ち、データアーキテクトおよびソフトウェア開発エンジニアリングマネージャーとしての強力なバックグラウンドを持っています。データアーキテクトとして、Ying は顧客がクラウドでエンタープライズデータアーキテクチャソリューションを設計し、スケールするのを支援しました。エンジニアリングマネージャーとしての役割では、新機能を提供し、エンジニアリングと製品の両方の観点から製品イノベーションを推進することで、顧客が QuickSight を通じてデータの力を解き放つことを可能にしました。 Julia Flash は、AWS のジェネレーティブ AI 組織に所属するシニアビジネスディベロップメントスペシャリストで、北米のエンタープライズセグメント向けのQuickSightエンゲージメントをリードしています。AI、コーディング、製品戦略で 12 年の経験を持ち、エンジニア、テクニカルプロダクトマネージャー、特許を持つイノベーターとしての深いバックグラウンドを持っています。Julia は AI ソリューションの設計と開発、オープンソースのデータサイエンスへの貢献、そして影響力の大きい顧客対応のエンゲージメントを提供してきました。今日、彼女は引き続き顧客と協力し、QuickSight の大規模な採用を推進しています。

はじめに Snowflake Summit 2025の2日目に開催された「Platform Keynote」の模様を、会場の熱気とともにレポートします！ Platform Keynote では、Snowflake の共同創業者であり President of Product（製品担当社長）でもある Benoit Dageville（ベノア）、そして Executive Vice President of Product（製品担当副社長）である Christian Kleinerman（クリスチャン）をはじめとする幹部陣、そして Snowflake の製品を実際に開発しているマネージャ

こんにちは！バックエンドチームマネージャーの @tsuwatch です！ 2022/9/8〜10に三重県にて開催されたRubyKaigi 2022でプラチナスポンサーとして協賛し、スポンサーブースを出展しました。 technote.zozo.com technote.zozo.com 弊社からは WEAR を開発するバックエンドエンジニア、SRE、PdMなど合計10名ほどが現地で参加しました。 我々が運営しているファッションコーディネートアプリ「WEAR」のバックエンドはRuby on Railsで開発しています。2013年にVBScriptで作られたシステムですが、2020年くらいからVBScriptのシステムをコードフリーズし、リプレイスをはじめました。現在もリプレイスを進めながら、新規の機能もRubyでどんどん開発しています。 また弊社ではRubyコミッタのsonotsさんがいたり、顧問としてMatzさんにもご協力いただいており月に一度、Matzさんに何でも聞く会をやっていたり、積極的にRubyを活用しています。 今回もエンジニアによるセッションの紹介とブースでの取り組みについて紹介します。 エンジニアによるセッション紹介 弊社エンジニアによるセッションの紹介をします。 How fast really is Ruby 3.x？ github.com 高久です。Fujimoto Seijiさんのセッション「How fast really is Ruby 3.x？」についてご紹介します。 このセッションでは、Rubyの過去バージョンと比較しRuby 3.xではどれくらい早くなったかを、実際のアプリケーションを用いて検証した結果を報告しています。検証対象のアプリケーションはFujimoto Seijiさんがコミッターを務めるFluentdです。 検証の背景について。まず前提としてRuby 3は「Ruby 3×3」という「Ruby 2.0の3倍早くする」ことを目指して開発が進められました。そして過去のRubyKaigiでも同様に実際のアプリケーションを使った検証の話がいくつかありました。しかし、どれもRailsアプリで作られたものでは3倍にならないという話でした。なぜならRailsアプリは基本的に、アプリケーションの多くの時間を占めているのがRubyの処理ではなく、DBなどの外部処理によるものだからです。Rubyを早くしたとしても、その他にかかる時間が大きいため、全体の処理時間の短縮化に大きく寄与するものではありませんでした。 そこで今回、多くの処理をRubyで行なっているFluentdを対象に測定してみたらどうなるか？　というのがテーマとなっています。 検証は読み込ませるファイルごとに2パターン行なっています。 LTSVファイル nginxログファイル 検証した結果Ruby 1.9と比較しRuby 3.2（YJIT有効）は、LTSVファイルで約3.15倍、nginxログファイルで約2.5倍のスループットが出ることを確認できました。Ruby 1.9と3.2の比較にはなりますが、概ね「Ruby 3×3」は実現しているのではということが、Fujimoto Seijiさんが伝えたかった内容になります。 セッションでは、更に他の言語と比較してどうかを述べていました。気になる方は是非スライドをご確認ください。 コミッターさんたちがRubyをより良くするために開発をし、Rubyが日々進化していることを実感した発表でした！ Make RuboCop super fast speakerdeck.com 小山です。RuboCopメンテナの@koicさんによる「Make RuboCop Super fast」の発表を紹介します。 RuboCopは2012年4月21日がファーストコミットで今年10周年を迎えました。RuboCopは現在1.36.0が最新バージョンでありますが、2.0系リリースに向けてマイルストーンを掲げており、この発表はそのマイルストーンのうちの1つであるRuboCop2×2に関する発表でした。RuboCop2×2はRuby 3×3で目指しているように、RuboCopの速度を1.0系と比較し、2倍を目指すというものです。 RuboCopはCaching、Multi-cores、Reduce unused requires、Daemonizeの4つのアプローチで高速化を図っています。 Cachingはかねてから提供されていて、1回検査したコードはデフォルトで ~/.cache/rubocop_cacheに保存しています。 Multi-coresは1.19からデフォルトで並列検査するようになり、1.32から並列でオートコレクションするようになりました。8 core CPUかつHyper-Threadingを使用して約1,300ファイルに対して直列実行と並列実行を比較した場合、直列実行は61秒で完了したのに対し、並列実行は10秒で完了したそうです。 Reduce unused requiresは --onlyオプションを付与したとしてもすべてのCopが読み込まれてしまう問題がありました。require 'rubocop' の改善により高速化を実現しており、セッションの本論で話されていたserverモードと一部関連があります。 Daemonize（serverモード）がセッションで一番厚くお話されていた内容になります。serverモードは #10706 で対応されて1.31から導入されています。使用することでrubocopコマンドを実行する度にプロセスを起動するのではなく、プロセスを常駐することでモジュールの読み込みが初回のみになります。Client/Serverモデルを採用して高速化を実現していたサードパーティ製のgem、rubocop-deamonを統合することで、RuboCopのserverモードは高速化されています。Client/Serverモデルとは、Server側の初回プロセスであらかじめモジュールを読み込んでおいて、Client側がすでにモジュールを読み込んでいるサーバーに接続するアプローチです。またrubocop-daemonをどのように統合したか、serverモードの設計、具体的な使用方法についてはセッション内で詳しく解説されていますので気になる方は是非スライドをご覧ください。 成果としては、moduleの読み込みを必要なもののみにし、serverモードを実装したことで850倍高速化されています。驚くべき成果です。 RubyのDX向上に、すぐに繋がると実感した素敵な発表でした。まだ不安定な挙動が残っているとの補足はありましたが、RuboCopのバージョンを上げて積極的に使っていきたいです！ The Better RuboCop World to enjoy Ruby speakerdeck.com 三浦です。私からはOhba Yasukoさん（@nay3）によるセッション "The Better RuboCop World to enjoy Ruby" について紹介したいと思います。技術的なセッションからは少し視点を変えた、RuboCopとうまく付き合っていくにはどうしたら良いかを考える内容になります。 RuboCopはRubyの静的コード解析ツールの1つで、コーディング規約を守れていないコードを簡単に確認でき、自動で修正できる便利なツールです。CIで回して事前に修正しておくことでレビューの負担軽減にも繋がります。 ただこのRuboCopのルールは "状況に合わないこと" もあります。例えば "Naming/PredicateName" というルールは、has , is , have_ といった特定の接頭辞のメソッド名をチェックし、接頭辞を排除したメソッドを使うよう警告します。 # bad def is_child? end def has_child? end # good def child? end ただ child? にしてしまうと、どちらとも捉えられるような曖昧なメソッド名になってしまいます。 "is child" なことをチェックするメソッド "has child" なことをチェックするメソッド このようにRuboCopの中にはルールとして間違ってはいないけど状況によっては合わないルールがいくつか存在しています。 初心者〜初級者のエンジニアの場合、状況に合っていないルールなのかを判断するのは難しいです。そのためRuboCopの警告に忠実に従ってコーディングをしてしまい、その結果かえって読みにくいコードになってしまう場合があります。 レビューで指摘された軽微な修正でも直そうとするとRuboCopのルールに引っかかってしまい、複雑な実装になってしまったなんてこともよくあります。(私もありました、、、) このような状況に合わないルールで振り回されてしまうのは、開発速度を低下させる一因にもなります。 RuboCopの全てのルールは、無効にしたりデフォルトとは異なる方針に変更できます。また、特定のコードで特定のルールを無視できます。しかしこのルールの設定の判断はルールの妥当性を判断できる技術力と経験が必要です。初心者〜初級者のエンジニアにとってはこの判断はなかなか難しいものです。かといって経験者が1つ1つのルールを必要か毎回確認するのも大変です。 そこで提案されたのがルールを大きく2つのレベルに分けて考えることでした。 強制レベル：ほぼ100％の状況で適用しても問題がないようなルール 参考レベル：なるべく多くの改善ポイントに気付けるような理想的なルール この2つのレベルに合わせてrubocop.ymlの設定ファイル自体を分けておきます。強制レベルのルールは現状通りCIなどで警告を出し、修正を強制します。参考レベルのルールはCIを回しますが、参考情報として表示するだけに留めておきcommitの禁止やマージの禁止といった強制力は持たせないようにします。 このように参考レベルのルールを作っておくと全てのルールに従おうとして不自然なコードを作ることを防ぐことができるので良いのではということでした。Ruby初心者にとってのつまづきポイントなどもたくさん紹介しており、うなずきたくなるような共感できる内容でした。スライドのイメージ図は全て画像生成AIのMidjourneyを使って生成したものだそうで笑いも起こる楽しいセッションでした。 Implementing Object Shapes in CRuby @tsuwatch です。個人的におもしろそうだなと思っていたObject Shapesというオブジェクトのプロパティを表現する手法について書こうと思います。Object Shapesを導入することでインスタンス変数のを見つけるときのキャッシュヒット率の増加とランタイム時のチェックを減らすことができ、JITのパフォーマンスを向上させるというものです。また、この手法はTruffleRubyやV8で採用されているそうです。 詳細はチケットにあるのでご覧ください。 bugs.ruby-lang.org Object Shapesとは class Foo def initialize # Currently this instance is the root shape (ID 0) @a = 1 # Transitions to a new shape via edge @a (ID 1) @b = 2 # Transitions to a new shape via edge @b (ID 2) end end class Bar def initialize # Currently this instance is the root shape (ID 0) @a = 1 # Transitions to shape defined earlier via edge @a (ID 1) @c = 1 # Transitions to a new shape via edge @c (ID 3) end end foo = Foo .new # blue in the diagram bar = Bar .new # red in the diagram 例えばこういうコードが存在したときにObject Shapesは以下のようなツリー構造を構築します。 インスタンス変数の遷移をツリー状に構築することで、同じ遷移をするクラスはキャッシュを利用できます。別のクラスをnewしたときにも元のShapesの差分のみ作れば良いというわけです。 class Hoge def initialize # Currently this instance is the root shape (ID 0) @a = 1 # Transitions to the next shape via edge named @a @b = 2 # Transitions to next shape via edge named @b end end class Fuga < Hoge ; end hoge = Hoge .new fuga = Fuga .new 現在はクラスをキャッシュキーとして使用しており、その場合はこのコードではキャッシュヒットさせることはできません。Object Shapesを導入することでクラス依存しないキャッシュを実現し、キャッシュヒット率を上げることができます。 複雑そうですが、効果がありそうなパフォーマンスチューニングです。キャッシュの構造や実際にどれくらいパフォーマンスが改善するのか今後もウォッチしていこうと思います。 Method-based JIT compilation by transpiling to Julia speakerdeck.com 近 です。@KentaMurata氏のメソッドベースのJust-In-Timeコンパイルへの新しいアプローチとして、インフラストラクチャにJulia言語を使用した背景と仕組み、特徴についてのお話を紹介します。Numo::NArrayやRed Arrowを使えば大きな数値計算が出来つつありますが、MJITやYJITが利用できてもあまり高速ではないという問題があるとのことでした。 理由として、これらのJITコンパイラがRubyの全てのセマンティクスを保持するためです。Rubyでは全てのメソッドが再定義可能で、再定義されたメソッドは直ちにコード実行に影響を与えます。例えば、以下のようなループの途中でも、injectメソッドや+演算子（メソッド）が再定義されていないかの確認が毎回行われます。 s = ( 1 .. 10 ).inject { |a, x| a + x } 以上の特徴によって高速性が失われていましたが、数値計算の場合このRubyの動的性は数値計算アルゴリズムでは殆ど無意味なので、これを無視して計算を最適化できるほうが良いのでは？　というのがこのセッションの議題になります。 しかし、現在ではこのような最適化を行うためには、アルゴリズムをCの拡張ライブラリに書き換える必要があります。これをせずに、高速化を行う手段として挙げられたのがJuliaでした。Juliaはデータ処理や数値計算に向いていて高速な言語という特徴があります。 ここで、比較としてPythonの世界での解決策であるNumbaというライブラリの紹介がありました。NumbaはCPython用のJITコンパイラであり、PythonとNumPyのコードの一部を高速な機械語に変換します。もう少し具体的にコンパイルの流れを書きます。 CPythonのバイトコードを解析 NumbaIRを生成して書き換え 型を推論 型付IRに書き換え 自動並列化の実行 LLVM IRの生成 ネイティブコードにコンパイル という流れで、CPythonを型付の中間表現に変換してネイティブコードを生成しています。 またNumbaには2つのモードがあります。オブジェクトモードというCPythonインタプリタのC APIを使用しCPythonの完全なセマンティクスを保持するモード。もう1つはnopythonモードというfloat64やnumpy配列などの特定のネイティブデータ型に特化した小さくて効率の良いネイティブコードを生成するモードです。ざっくり言うと処理をPython経由で行うか、CPUに直接命令するかの違いになります。 このNumbaのnopythonモードのようなものをRubyのJITコンパイラでも実現する手段として登場するのが、今回のセッションの本題であるJuliaでした。まず、RubyでNumbaライクなJITコンパイラを表現すると以下のようになります。 Rubyメソッド ASTの生成 最適化 バイトコードの生成 CRubyのバイトコード IRの生成 タイプ推論 最適化 型付けされたIR LLVM IRの生成 ネイティブコードにコンパイル これと同じようなことをやっているのが、Juliaになります（JuliaはNumbaともだいたい同じ機構が動いています） Juliaコード ASTの生成 Julia AST タイプ推論 IRの生成 Julia typed IR LLVM IRの生成 ネイティブコードにコンパイル そこで、RubyをJuliaへトランスパイルし、それ以降をJuliaのJITコンパイラに実行してもらって高速化します。 Rubyメソッド Juliaコード Julia AST Julia typed IR LLVM IRの生成 ネイティブコードにコンパイル Juliaは最適化されたネイティブコードを生成してくれるため、高速です。この辺りの解説はセッションのスライド図と発表が大変分かりやすく、面白かったので是非資料や動画をご覧ください。 次に、RubyからJuliaへのトランスパイル方法についての紹介がありました。トランスパイルには、yadriggyというRubyメソッドのASTを構築し、構文と型をチェックするgemを使用しているとのことでした。セッションでは具体的なコードを紹介していましたが、大雑把にいうとRubyコードからASTを構築し、それを使ってJuliaコードを生成しているようでした。 Rubyコード → Ruby AST → 型チェッカーでノードに対して型付け → Juliaコード これによって、Rubyの機械への命令を最適化させています。 またRubyとJuliaで実装の違うものがいくつかあり（例ではRangeを挙げていました）これらの対応をするには自分で変換コードを書く必要があるとのことでした。 これらの高速化の実験比較として、以下の計算をしていました。 マンデルブロ集合 モンテカルロ法によるπの近似 クイックソート 畳み込み ドット積 それぞれの結果は以下のようになっていました。RubyはおそらくYJITが有効。 マンデルブロ集合 Ruby：平均3.326ms Ruby to julia：平均171.667μs モンテカルロ法によるπの近似 Ruby：平均106.368ms Ruby to julia：平均8.851ms クイックソート Ruby：平均7.551ms Ruby to julia：平均1.937ms 畳み込み（結果が複雑なので省略） ドット積 Ruby (N=10000) 平均468.608μs Ruby to julia (N=10000) 平均3.759ms Ruby to julia (N=10000, T=Float64) 平均10.651μs これらのように、一部の結果を除いて超高速に計算することが可能になるようでした。 紹介は以上になります。発表が分かりやすく、深掘りしたくなるような興味深い内容でした！Rubyの高速化についてこういう方法もあるんだなと、とても学びが多かったです。RubyKaigiではこのような発表がいくつもあり、すごくワクワクしました。 スポンサー 今年も2019年に続いてスポンサーブースを出展しました。 こちらは今回のために作成したノベルティたち。すごくかわいいですね！来てくださった方にもとてもご好評いただきました。とてもこだわって作成したので嬉しかったです。 Tシャツもデザイナーさんにデザインしていただいた魂のこもったTシャツです！普段でも全然着られるのではないでしょうか？「WEAR」アプリをインストールしていただいてる方にお配りしていたのですが、1日目でほとんどなくなってしまいました。ありがとうございます！着てください！ またブースでは、会期中の3日間『エンジニアのファッション事情を大調査！』と銘打ち、毎日異なるアンケートを取っていました。 服を買うなら？ 実店舗 28票 ECサイト（ZOZOTOWN） 15票 ECサイト（ZOZOTOWN以外） 9票 その他 3票 まだまだ実店舗が多いですね！次はありがたいことにZOZOTOWNでした！ありがとうございます！その他の方はご家族やパートナーの方が買っているとの声もありました。 コーディネートはどうやって決める？ 己のセンスを信じる 86票 雑誌やネット 56票 その他 45票 周りの人を見る 19票 己のセンスを信じる人が多かったです。エンジニアはやはり我が道を行くのでしょうか。 コーディネートのパターン数は？ 1 ~ 5 43票 着るときに考える 41票 6 ~ 10 37票 10より多い 9票 票がわかれました。ちなみに僕は着るときに考える派です。でもそんなに服がないのでいつもだいたい同じ格好になってますね。 みなさんアンケートに回答していただきありがとうございました！ 我々はファッションの悩みを解決することをミッションとして掲げています。みなさんが日々どのようにファッションと向き合っているのか、いろいろお話を聞くことができました。「WEAR」に要望をくださったり、使ったことがない人にご紹介できたりしました。ファッションへのモチベーションが高い人も、そこまで高くない人もそれぞれ悩みはあると思います。「WEAR」をこれからも良いサービスにしていきます！ 最後に ZOZOではセミナー・カンファレンスへの参加を支援する福利厚生があり、カンファレンス参加に関わる渡航費・宿泊費などは全て会社に負担してもらっています。ZOZOでは引き続きRubyエンジニアを募集しています。以下のリンクからぜひご応募ください。 hrmos.co また、メドピアさん、ファインディさんと合同で9/27に「After RubyKaigi 2022」を開催します。ぜひご参加いただければと思います。 findy.connpass.com おまけ 楽しんでいる様子です。Wポーズ！ PdMのお二人！　昔の仕事仲間や他社の方々、ユーザーさんと交流できて楽しそうでした。 Matzさんと！　全員集合したかったですね。 RubyKaigiではおいしいご飯が食べられます！ アンドパッドさんの二進数足し算RTAで弊社のjeuxd1eauが5位！なんとPdMの方です！エンジニア、本部長も敗北しました。 待ちに待ったオフラインでのカンファレンスで久しぶりに良い刺激をもらいましたし、とても楽しかったです。来年は松本市でお会いしましょう！それではまた次回。