本記事は 2025 年 12 月 10 日 に公開された「 How to use Sustainability Insights Framework on AWS 」を翻訳したものです。 従来、組織は炭素排出量を追跡し、気候関連レポートを作成する際に、複雑で労働集約的、かつエラーが発生しやすい手動プロセスに直面してきました。このプロセスでは通常、従業員が公共料金の請求書、燃料消費記録、調達文書、出張領収書、施設運営ログなど、異なるソースから無数の時間をかけてデータを収集する必要がありました。大規模なチームは、このデータをスプレッドシートに手動で入力する必要があり、多くの場合、一貫性のない形式や単位を扱い、慎重な変換と検証が必要でした。このプロセスは、異なる地域基準、報告要件、排出係数を扱う多国籍組織にとって特に困難でした。スタッフは、スコープ 1 排出量（所有するソースからの直接排出）、スコープ 2 排出量（購入した電力からの間接排出）、さらに複雑なスコープ 3 排出量（バリューチェーン内のその他すべての間接排出）を手動で計算する必要がありました。各計算には適切な排出係数の慎重な適用が必要であり、これらの係数自体も基準の進化に伴って定期的に更新する必要がありました。 これらの懸念に対処するため、AWS は AWS Solutions Library に Sustainability Insights Framework (SIF) を導入しました。 これは、あらゆる規模の組織が AWS 上で炭素排出量を自動的に追跡し、気候関連レポートを作成するアプリケーションを構築するのに役立つ、柔軟でスケーラブルなソフトウェアプラットフォームです。計算、パイプライン処理、参照データセット用の特殊なコンポーネントを含むモジュラーアーキテクチャを通じて、SIF は組織が膨大な量のサステナビリティデータを処理しながら、すべての計算とレポート全体で精度と一貫性を維持できる高度なアプリケーションを作成することを可能にします。 フレームワークの有効性は最終的に入力データと推定方法の品質に依存し、すべての出力は規制遵守と公式開示のために独立した検証が必要ですが、SIF の自動化されたアプローチは 3 つの重要な利点を提供します：自動化されたデータ処理と計算を通じて人的エラーのリスクを劇的に削減し、増大する報告要件を処理するために動的にスケールし、進化するサステナビリティ基準と規制に容易に適応します。SIF には、それぞれ特定の目的を果たす複数のモジュールが含まれています。これらのモジュールは、アクセス管理、インパクト管理（排出係数管理）、参照データセット管理、計算、データパイプラインを処理します。 ​ SIF の主要機能 アカウント管理 – 組織の報告境界を設定します。フレームワーク内でユーザーアクセス、ロール、権限を制御します。 インパクト – GHG 排出係数などの活動インパクトのカタログを作成します。公開されたソースから排出係数を追加するか、独自のカスタム係数を作成します。 参照データセット – データパイプラインにカスタムデータセットを追加して、データ品質を向上させます。 計算 – ローコードアプローチを使用してカスタム計算を作成します。 メトリクス（KPI） – 処理された活動を自動的に集計するメトリクスを設定します。これらを組織の報告境界と期間に合わせます。 データ取り込みパイプライン – CSV ファイル、AWS Clean Rooms、または入力データコネクタフレームワークを使用した他のソースからデータをインポートします。計算を適用してデータを必要な出力に変換します。 監査可能性 – すべての計算と結果を完全な透明性で追跡および再現します。 マルチテナンシー – シングルテナントまたはマルチテナントモードで動作します。自社の排出量を計算したい組織と、SaaS オファリングを構築する組織をサポートします。必要に応じて、分離されたテナント間でデータを安全に共有します。たとえば、SaaS オファリングを構築する場合、トップティアのお客様は業界固有の数式などの事前定義された計算にアクセスできます。中央テナントは、集中管理のためにこれらの計算を保存します。トップティアテナントは、これらの計算にリモートでアクセスして使用する権限を取得します。 ソリューションアーキテクチャ SIF は、それぞれ特定の機能に焦点を当てた複数のモジュールで構成されています。以下のアーキテクチャ図は、これらのモジュールがどのように連携するかを示しています。 ​ SIFソリューションアーキテクチャモジュール ​ ユーザーは REST API を通じて SIF を操作します。 アクセス管理モジュール は、ユーザーと権限を管理し、グループごとにリソースを分離します。 インパクトモジュール は、データ処理計算中にインパクト係数などのリソースを管理するのに役立ちます。これらは計算モジュールとパイプラインモジュールから参照できます。 参照データセットモジュール は、ルックアップテーブルなどのデータセットを管理するのに役立ちます。これらのデータセットは、計算モジュールとパイプラインモジュールから参照できます。 計算モジュール は、方程式または関数を作成および管理するのに役立ちます。これらの計算は、データ処理計算のために他のモジュールで参照できます。 パイプラインモジュール は、計算用のデータ処理パイプラインを設定するのに役立ちます。 パイプラインプロセッサモジュール は、パイプラインを管理し、パイプライン集計を実行します。 計算機モジュール は、バックエンドコンポーネントとしてパイプライン内の操作を実行します。これには、算術演算とリソースルックアップが含まれます。 SIF は、AWS サービス上に構築されたモジュールのレイヤーとして機能します。各モジュールは特定の機能を処理します。各コンポーネントを見てみましょう： ​ アクセス管理モジュール アクセス管理モジュールは、ユーザーとグループを使用して SIF 内の権限を管理し、リソースを分離します。外部 REST API を通じてユーザーとグループを作成できます。他の SIF モジュールは、アクセス管理モジュールを呼び出して権限を確認します。各テナントは、独自のアクセス管理インフラストラクチャのコピーを取得します。 ​ SIF アクセス管理モジュール図 ​ インパクトモジュール インパクトモジュールは、インパクト関連のリソースを管理するのに役立ちます。排出量追跡などのデータ処理計算中に、計算モジュールとパイプラインモジュールからこれらのリソースを参照できます。インパクトの例としては、モバイルディーゼル燃料消費の二酸化炭素換算量（CO2e）があります。インパクトモジュールは、インパクトタスク API を通じて一度に多くのインパクトリソースを作成できます。すべてのインパクトには、透明性のためのバージョン追跡が含まれています。 ​ SIF インパクトモジュール図 ​ 参照データセットモジュール 参照データセットモジュールは、ルックアップテーブルなどのデータセットを管理するのに役立ちます。排出量追跡などのデータ処理計算中に、計算モジュールとパイプラインモジュールからこれらのデータセットを参照できます。参照データセットの例は、特定の場所の発電ミックス（石炭、原子力、風力）を示すテーブルです。すべての参照データセットには、透明性のためのバージョン追跡が含まれています。 ​ SIF 参照データセットモジュール ​ 計算モジュール 計算モジュールは、方程式または関数を作成および管理するのに役立ちます。排出量追跡などのデータ処理計算中に、他の計算モジュールまたはパイプラインモジュールでこれらの計算を参照できます。計算は、単純（単位変換など）または複雑（ビジネス固有の排出量計算など）にすることができます。すべての計算には、透明性のためのバージョン追跡が含まれています。 ​ SIF 計算モジュール ​ パイプラインモジュール パイプラインモジュールは、パイプライン構成を管理するのに役立ちます。これらの構成は、排出量追跡などの計算用のデータ処理パイプラインを設定します。パイプラインを構成して、実行全体で出力を結合し、メトリクスにグループ化できます。メトリクスは、時間の経過に伴う総排出量などの主要業績評価指標（KPI）を捕捉します。パイプライン構成のドライランをリクエストして、計算機を通じて処理し、作成前にエラーをチェックできます。すべてのパイプライン構成には、透明性のためのバージョン追跡が含まれています。 ​ SIF パイプラインモジュール ​ パイプラインプロセッサモジュール パイプラインプロセッサモジュールは、パイプライン操作を管理します。これには、入力ファイルを提供したときのパイプライン実行の開始と、パイプライン構成で定義された集計の実行が含まれます。パイプラインプロセッサモジュールは、パイプライン実行のステータスも表示します。 ​ パイプラインプロセッサモジュール ​ 計算機モジュール 計算機モジュールは、パイプラインで定義された操作を読み取って実行するバックエンドコンポーネントとして機能します。これには、算術演算と、参照データセットやインパクトなどのリソースのルックアップが含まれます。計算機は、入力値と実行で使用された各リソース（参照データセット、インパクト、計算）のバージョンを含む、すべてのパイプライン操作の監査ログも作成します。 ​ さまざまなモジュールの詳細については、こちらをご覧ください： Architecture diagrams for SIF on AWS ​ 米国環境保護庁（EPA）は、AWS と Sustainability Insights Framework（SIF）を使用して、サブパートW規制に基づく温室効果ガス排出量を管理および報告しています。SIFは、データ収集、分析、報告を容易にする包括的でスケーラブルかつ安全なプラットフォームを提供します。これにより、コンプライアンスが向上し、環境の持続可能性がサポートされます。このユースケースの詳細については、こちらをご覧ください： U.S. EPA Subpart W Greenhouse Gas Reporting with AWS and Sustainability Insights Framework ​ SIF 計算機モジュール ​ SIF の利点 SIF は以下の利点を提供します： 運用効率と自動化 ：データ収集から自動化された排出量計算と報告までの手動作業を削減します。 透明性と監査可能性 ：すべてのデータソース、計算式、結果がバージョン管理され、ログに記録されます。これにより、監査をサポートするトレーサビリティが作成されます。 標準化されたデータモデル ：データ統合と品質保証、さらにレポートの再利用性と高度なデータ分析を可能にします。 高い柔軟性とスケーラビリティ ：排出係数、ワークフロー、計算式を簡単に追加または変更できます。これにより、将来のニーズに柔軟に対応できます。 セキュリティと一貫性 ：データ暗号化や最小権限の原則を含む、AWS セキュリティのベストプラクティスに従います。 ガイダンスをデプロイする手順 SIF のソースコードは GitHub で見つけることができます： Guidance for AWS sustainability insights framework 。2 つのデプロイオプションがあります： CDK を使用して手動でデプロイする。 sif-cli を使用してデプロイする 。SIF コマンドラインインターフェース（sif-cli）は、コマンドラインコマンドを通じて SIF コンポーネントと対話するのに役立つオープンソースツールです。最小限のセットアップで、sif-cli は SIF の管理の多くの複雑さを簡素化します。また、デプロイされたバージョンと最新の SIF リリース間の互換性を確保する機能も含まれています。 デプロイを完了し、SIF を本番環境に移行したい場合は、 Considerations of running SIF in production を確認してください。 ​ カスタマイズガイダンス（さまざまなお客様向け） SIFは、多様なお客様要件を満たすために柔軟に適応します。 業界および地域別の排出係数のカスタマイズ ：製造や輸送などの業界、または米国や日本などの地域に応じて排出係数を管理します。 お客様固有の KPI とレポート形式の追加 ：SIF のカスタマイズ可能な計算式とレポートテンプレート機能を使用して、独自のメトリクスとカスタマイズされたレポート出力をサポートします。 既存のデータレイクとシステムとの統合 ：API と AWS サービス統合を通じて、SIFを既存のデータインフラストラクチャとシームレスに接続します。 組織構造とセキュリティ要件の最適化 ：SIF のマルチテナントアーキテクチャを使用して、複数の部門またはグループ会社間で操作を分離します。必要に応じて詳細なアクセス制御を設定します。 次のステップ SIF を始める準備はできましたか？以下をお勧めします： 初めてのユーザー向け： GitHub リポジトリを探索する – コードベースと要件を理解するために、AWS sustainability insights framework のガイダンスを確認してください。 開発環境をセットアップする – 必要な AWS CLI、CDK、および権限が構成されていることを確認してください。 パイロットデプロイから始める – 最もシンプルなセットアップエクスペリエンスのために、sif-cli ツールを使用して開発環境に SIF をデプロイします。 EPA ユースケースを確認する – 米国環境保護庁がサブパート W 報告のためにSIFをどのように実装したかを研究して、実際のアプリケーションを理解してください。 実装の準備ができている組織向け： データソースを評価する – SIF と統合する必要があるシステムとデータ形式を特定します。 排出係数を定義する – 構成する必要がある業界固有または地域固有の排出係数を決定します。 組織構造を計画する – 報告境界に基づいて、シングルテナントまたはマルチテナントアーキテクチャが必要かどうかを決定します。 本番環境の考慮事項を確認する – 本番環境にデプロイする前に、「 Considerations of running SIF in production 」のドキュメントを読んでください。 サポートを受ける： ベストプラクティスとピアサポートのために、AWS サステナビリティコミュニティに参加してください。 実装ガイダンスとカスタマイズサポートについては、AWS プロフェッショナルサービスをご検討ください。 SIF が使用する基盤となるサービスについては、AWS ドキュメントを確認してください。 パイロットプロジェクトから小規模に始めてアプローチを検証し、プラットフォームの経験を積むにつれてスケールアップしてください。 ​ 結論 AWS Sustainability Insights Framework（SIF）は、AWS上に構築された貴重なツールです。自動化された炭素排出量追跡のためのアプリケーションの設計と実装を加速する基盤となるソフトウェアコンポーネントを提供します。SIF は、自動化、カスタマイズの柔軟性、スケーラビリティ、コスト効率、セキュリティなどの利点を提供するために連携する、さまざまな独立したモジュールで構成されています。 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。 Smita Srivastava Smita Srivastava は、Amazon Web Services のシニアソリューションアーキテクトで、デジタルネイティブ企業のイノベーション促進を支援しています。その経験を活かし、企業の成長を導き、AWS サービスを活用した AI/ML に重点を置きながら、アイデアを現実に変えるサポートをしています。AWS のお客様にサステナビリティソリューションを提案することに深い関心を持っています。仕事以外では、旅行好きで、読書家であり、食の探求者でもあります。

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp 今回は、私が作った「PdMタイプ診断」という取り組みについてご紹介します。 この診断は、既存の性格診断をそのまま用いたものではなく、 PdMとしての思考や行動の傾向を整理するために、認知スタイルに関する考え方をヒントに独自に設計したもの です。 診断の仕組みと、ラクスの開発組織で実施して見えてきたことをレポートします。 なぜ作ったのか 診断の仕組み：3つの軸、8つのタイプ 軸① コミュニケーション 軸② 価値の方向性 軸③ 志向性 ラクス社内で試してみた 開発組織全体の傾向：「Logic × UX × Discovery」が最多 プロダクト部の特徴：「Discovery」が際立って高く、2つのタイプが拮抗 この結果をどう受け取るか まとめ おわりに なぜ作ったのか きっかけは、小さな課題感からでした。 PdMのイベントや社外の方と話すとき、「どんなPdMですか？」という問いにうまく答えるのが難しいと感じることがありました。 職種名だけでは伝わらないですし、スキルセットを並べても、その人らしさまではなかなか見えてきません。 もう一つ感じていたのが、チームづくりの場面で、 このメンバーはどんな場面で力を発揮しやすいのか を共通言語で話しにくいことでした。 もちろん、人の適性や可能性は診断だけで決まるものではありません。 ただ、対話のきっかけになる整理軸があるだけでも、お互いの理解は進めやすくなります。 そこで、PdMとしての思考・行動スタイルを3つの軸で整理し、8つのタイプに分類する診断を作ってみました。 初対面のPdM同士で話すきっかけにしたり、チーム内で自分や他者の強みを言語化したりするための、 参考情報の一つ として使えることを期待しています。また今回の整理にあたっては、設問やタイプ説明のたたき台を考える過程で、生成AIも補助的に活用しました。 人が考えるべき軸や解釈を前提にしつつ、表現の幅を広げたり、説明文を磨いたりするうえで、AIは良い壁打ち相手になると感じています。 診断の仕組み：3つの軸、8つのタイプ 診断は、3つの軸の組み合わせでPdMのタイプを分類します。 軸① コミュニケーション Logic（理詰め型）／ Emotion（共感型） チームや関係者をどう巻き込むかを見る軸です。 データや論理で動かす傾向が強いのか、共感や関係性を起点に動かす傾向が強いのかを見ます。 軸② 価値の方向性 UX（ユーザー価値重視）／ BV（ビジネス価値重視） どの成果をより重視しやすいかを見る軸です。 顧客体験を起点に考えるのか、事業成長や収益性を起点に考えるのか、その傾向を整理します。 軸③ 志向性 Discovery（探索志向）／ Delivery（実行志向） どのフェーズでモチベーションを感じやすいかを見る軸です。 まだ見ぬ課題を発見することに惹かれるのか、価値を着実に届けることに手応えを感じるのかを見ます。 この3軸の組み合わせで、8つのタイプになります。 ※本記事では、診断の詳細な設問内容や公開方法そのものの案内は割愛します。 ラクス社内で試してみた せっかく作ったので、ラクスの開発組織でも試してみました。 プロダクト部のメンバーだけでなく、楽楽シリーズの開発に携わるエンジニア、QA、インフラ、管理職まで、幅広く参加してもらいました。 ここで紹介するのは、個人を評価したり決めつけたりするためのものではなく、 組織の傾向を俯瞰して見るための集計結果 です。 「どのタイプが優れているか」を見るものではなく、「どんな視点が集まっているか」を知るための材料として扱っています。 そのうえで、いくつか興味深い傾向が見えてきました。 開発組織全体の傾向：「Logic × UX × Discovery」が最多 開発組織全体を見ると、もっとも多かったのは サイエンティスト（Logic × UX × Discovery）タイプ でした。 各軸の全体比率は次のとおりです。 論理的に考え、ユーザー価値を重視し、探索や発見にモチベーションを感じる人が多い。 これが、開発組織全体の大まかな傾向でした。 実際、日々のプロダクト開発でも、 「顧客課題をより深く理解したい」 「仮説を立てて検証したい」 という姿勢を持つメンバーが多いと感じています。この傾向は、顧客にとって本当に価値のある機能や体験を考えるうえで、ラクスの開発組織らしさの一つかもしれません。 プロダクト部の特徴：「Discovery」が際立って高く、2つのタイプが拮抗 プロダクト部に絞ると、また少し違った顔が見えてきました。 プロダクト部の各軸比率は次のとおりです。 特に目を引いたのは、志向性です。 全体でも67%がDiscovery型でしたが、プロダクト部では 79% とさらに高くなっていました。まだ答えのない問いを探索することが好きな人、発見のフェーズにエネルギーが湧く人が多い組織だと言えそうです。 さらに興味深かったのが、タイプの分布です。 プロダクト部で最多だったのは、 ビジョナリー（Emotion × UX × Discovery） と ストラテジスト（Logic × BV × Discovery） の同率首位でした。 一方は、共感から未来の体験を描くタイプ。 もう一方は、構造から勝ち筋を見出すタイプです。 アプローチは対照的ですが、どちらも「Discovery（探索）」に強く向いているという共通点があります。 感性寄りの人と論理寄りの人、ユーザー価値を強く見る人とビジネス価値を強く見る人が混在している。 その多様さが、ラクスのプロダクト部の特徴の一つなのかもしれません。 この結果をどう受け取るか 「タイプが違うと、摩擦が生まれるのでは」と感じる方もいるかもしれません。 私は、むしろ逆だと思っています。 たとえばビジョナリーとストラテジストは、それぞれ異なる強みを持っています。 共感から体験を描く力と、構造から事業の勝ち筋を考える力は、どちらもプロダクトづくりに欠かせません。 大切なのは、「あなたはこのタイプだからこうあるべき」と決めることではなく、 このチームにはどんな視点が集まっているのか を知ることだと思っています。 その視点の違いを理解できると、 顧客課題の見立てに偏りがないか 意思決定の観点が足りているか 誰がどの場面で力を発揮しやすいか といったことを、より建設的に話しやすくなります。 実際、この診断をきっかけに、ラクスのプロダクト部でも 「自分はどういう場面で力を出しやすいか」 「チームとして見ると、どの視点が強くて、どの視点が薄いか」 を話題にしやすくなった感覚があります。 その結果として、顧客にとっての価値の捉え方や、プロダクトづくりにおける役割分担の解像度が少し上がったように感じています。 まとめ 「PdMタイプ診断」は、まだ発展途上のツールです。 型にはめることが目的ではなく、 共通言語を通じて、自分やチームの傾向を理解するための出発点 として使ってもらえたらと思っています。 PdMとして、あるいはプロダクトづくりに関わる一人として、 「自分はどんな場面で力を発揮しやすいのか」 「チームの中でどんな視点を持ち込みやすいのか」 を考えるきっかけになれば、作った甲斐があります。 そして、こうした相互理解は、よりよいチームづくりだけでなく、 顧客課題を多面的に捉え、より価値あるクラウドサービスを届けることにもつながるはずです。 興味を持っていただけたら、ぜひ一度試してみてください。 おわりに ラクスのプロダクト部では、さまざまなタイプのPdMやデザイナーが一緒に働いています。 違いを面白がりながら、顧客にとってよりよい価値を考え続けたい方と、ご一緒できたらうれしいです。 採用情報は、ぜひこちらからご覧ください。 career-recruit.rakus.co.jp speakerdeck.com

リクルートのデータ推進室長 野村が自ら聞き手となり、現場の最前線で試行錯誤を続けるスペシャリストたちの「手の内」を紐解く連