本ブログは 2026 年 8 月 18 日に公開された AWS Blog “ Security Hub Extended adds Supply Chain Security as its tenth category ” を翻訳したものです。 今年 2 月以降、AWS は AWS Security Hub Extended を、9 カテゴリにわたる厳選された 14 パートナーから、10 カテゴリ 23 パートナーへと拡大してきました。今月の Black Hat では、そのうち 14 パートナーが Amazon Web Services (AWS) ブースでライブデモを実施しました。4 パートナーがシアタートークを行い、10 パートナーが SecurityLive のストリーミング配信で紹介されました。また、AWS のリーダーシップとパートナー企業の経営陣が一堂に会し、今後の計画を話し合うパートナーレセプションも開催しました。これらの企業は、AWS とともに、そして次第にパートナー同士でも、エンジニアリングと市場開拓 (GTM) に本格的に投資しています。このモデルが、パートナーが日々接しているお客様から支持されているからです。ブースで最も多く寄せられた質問は、サプライチェーンセキュリティはいつ提供されるのか、というものでした。 その提供が始まりました。サプライチェーンセキュリティはカテゴリとして最も多くのお問い合わせをいただいているため、今回はこの話題を中心にお伝えします。 サプライチェーンセキュリティ: お客様が求め続けてきたカテゴリ ソフトウェアサプライチェーンのリスクは、セキュリティチームの懸念事項から、取締役会レベルの議題へと変わりました。SolarWinds の事例は、ビルドシステムが侵害されると何が起きるかを明らかにしました。Log4j の事例は、たった 1 つの推移的依存関係の脆弱性が世界規模で何を引き起こすかを示しました。xz utils のバックドアの事例は、メンテナーを侵害する攻撃が何年もかけて実行される執拗さを浮き彫りにしました。それぞれが同じ問題の異なる側面を示しており、そのペースは加速しています。攻撃者は、企業が知らず知らずのうちに信頼しているオープンソースパッケージこそが、企業への近道であることを知っています。 Black Hat で話をしたすべてのお客様が、この問題をリスク登録簿に載せていました。しかし、その多くはまだ解決策を運用に落とし込めていませんでした。運用化には、個別のデプロイ、新しい契約、新しいコンソール、そしてセキュリティチームが優先順位を上げられない統合作業が必要だったからです。AWS が取り除こうとしているのは、まさにこうした導入の手間です。 Security Hub Extended では、厳選されたパートナーとして Chainguard と Socket によるサプライチェーンセキュリティの提供を開始しました。サプライチェーンセキュリティは、Extended の他のすべてと同じモデルを採用しています。すべてのオファリングが従量制料金で、請求は 1 つにまとまり、長期契約は必須ではありません。これまでどおりの調達プロセスを継続したい企業向けには、Security Hub Extended のプライベートオファーも利用できます。プライベートオファーは、一定期間の利用をコミットする契約で、より大きな割引が適用され、複数パートナーへの支出を単一の AWS 請求に集約でき、契約期間を通じて月払いと年払いのどちらの支払いオプションも選択できます。お客様の購買プロセスに合った方法を選択できます。 Chainguard の役割 Chainguard は、強化・検証されたビルドプロセスでソースから再ビルドしたオープンソースの依存関係を提供します。これにより、お客様の環境に入ってくるものは、マルウェアに強く、来歴 (プロベナンス) に裏付けられたものになります。 同社の調査 によると、ソースからの再ビルドを行っていれば、既知の悪意あるパッケージの 98% が本番環境に到達するのを防げたとされています。ソースを検証できないものは、Chainguard のリポジトリに一切登録されません。これが、パブリックレジストリと開発者の間のフィルターとなります。 Socket の役割 Socket は、オープンソースパッケージの実際の挙動を分析し、インストール時点で悪意ある依存関係をブロックします。数日から数週間後に CVE (Common Vulnerabilities and Exposures) が公開されるのを待つのではありません。パッケージがお客様の環境に入り込もうとしたその瞬間に、Socket はデータベースの情報ではなくパッケージの挙動そのものに基づいて検知します。さらに、到達可能性分析によって、どの脆弱性がお客様のコードから悪用可能かがわかるため、チームがノイズに埋もれることがありません。料金は、チェックする個別のパッケージ数に基づき、ビルドの実行回数には依存しません。 2 社が連携して機能する理由 Chainguard と Socket を組み合わせることで、重要な 2 つの問いに対応できます。 取り込むものを信頼できるか 悪意あるコンポーネントがアプリケーションに組み込まれる前に阻止できるか Chainguard はコードが構築される基盤の保護を支援し、Socket はそこに取り込むパッケージを保護します。両者は、クラウドでもオンプレミスでも、デプロイ先を問わずソフトウェアサプライチェーンの保護に役立ちます。Security Hub Extended を通じて両方を有効化すると、その検出結果は OCSF (Open Cybersecurity Schema Framework) 形式で他のすべての情報とともに Security Hub に流れ込みます。これにより、サプライチェーンのリスクは、エンドポイント、アイデンティティ、クラウドの各シグナルと並べて相関付けられ、優先順位付けされます。そこから、すでに統合済みの下流ツールへとルーティングされるため、開発者が現在使っているパイプラインにそのまま適合します。 23 パートナー、10 カテゴリ。お客様の要望に基づいて構築 Security Hub Extended のすべてのパートナーは、お客様がその機能を必要としていると伝えてくれたこと、そしてその特定のソリューションがすでにお客様のもとで機能していたことを理由に参加しています。脅威の状況が進化するためカテゴリを追加し、それらの問題をうまく解決している企業をお客様が教えてくれるためパートナーを追加しています。目標はシンプルです。すでにお持ちの AWS との取引関係を通じて、同業他社がすでに成果を上げているセキュリティソリューションの導入を簡素化することです。 現在の対象領域は、エンドポイント、アイデンティティ、E メール、ネットワーク、データ、ブラウザ、クラウド、AI、セキュリティオペレーション、そして新たにサプライチェーンに及びます。23 の厳選されたパートナーは、7AI、Britive、Chainguard、CrowdStrike、Cyera、Island、LayerX、Native Security、Noma、Okta、Oligo、Opti、Palo Alto Networks、Proofpoint、SailPoint、SentinelOne、Socket、Splunk、Sublime、Upwind、Varonis、Zenity、Zscaler です。 AWS が現在注力しているのは、統合を深化させ、有効化にかかる手間を減らすことで、これらのソリューションが個別にではなく連携して機能するようにすることです。そこにこそ、価値が相乗的に高まっていきます。 今後の取り組み ここまで説明してきたことはすべて、販売モデルが機能していることの表れです。つまり、お客様が期待どおりの柔軟性のもとで、AWS との単一の取引関係を通じてベストオブブリードのセキュリティを購入しているということです。しかし、より大きなビジョンは、これらのツールを単に購入しやすくするだけでなく、組み合わせて使うことで実際に効果が高まる統合レイヤーです。 最も注力している統合は、クロスパートナーの相関付けです。エンドポイントソリューション、アイデンティティソリューション、クラウドソリューションからのシグナルを、相互に関連付けられていない 3 つのアラートではなく、1 つのエクスポージャーと 1 つの攻撃パスにまとめます。これと並行して、有効化、デプロイ、統合にかかる手間を大幅に減らし、お客様がサブスクライブしてから価値を実感するまでの時間を数週間ではなく数時間にすることに取り組んでいます。この 2 つの取り組みにより、お客様がすでに信頼している厳選されたソリューションは、個別に使うよりも連携させることで、より大きな成果をもたらします。 これが、AWS がパートナーとともに今まさに加速している取り組みです。re:Invent に向けて、さらに詳しい情報をお届けする予定です。 利用できるオファリングを確認する 本番環境でオープンソースソフトウェアを運用していて、まだサプライチェーンの可視性を確保できていない場合は、そこから始めてください。今すぐ Security Hub コンソールから Chainguard と Socket を有効化できます。複数のセキュリティベンダーとの関係を管理していて、Security Hub Extended による統合がどのようなものかを知りたい場合は、AWS アカウントチームにご相談ください。すべてのパートナーの料金は 料金ページ に公開されており、営業担当への問い合わせは不要です。また、すでにセキュリティ態勢管理と脅威検出に Security Hub を使用している場合、Extended プランは現在お使いのコンソールでそのまま利用できます。 これはまだ始まりにすぎません。 Michael Fuller Michael は AWS に 16 年間在籍し、11 年にわたって AWS セキュリティサービスのプロダクトを率いてきました。業界歴は 29 年で、IBM、Cisco、Amazon においてプロダクトマネジメント、事業開発、ソフトウェア開発のさまざまな役職を歴任してきました。アリゾナ大学でコンピュータ工学の理学士号を、ワシントン大学で MBA を取得しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本記事は 2026 年 8 月 12 日 に公開された「 Introducing Oracle Exadata on Exascale for Oracle AI Database@AWS 」を翻訳したものです。 Oracle AI Database@AWS 向けに Oracle Exadata Database Service on Exascale Infrastructure (ExaDB-XS) が一般提供開始となりました。ExaDB-XS は、従量課金モデルで Exadata クラスのパフォーマンスと可用性を提供します。コンピューティングとストレージを小さな単位で個別にスケールでき、使用した分だけを支払います。専用インフラストラクチャを事前にプロビジョニングする必要はありません。AWS Marketplace のパブリックオファーまたはプライベートオファーで、最小 8 Elastic CPU (ECPU)、ストレージ 300 GB から始められます。 Oracle AI Database@AWS では、AWS アベイラビリティゾーン内で Oracle Exadata インフラストラクチャをネイティブに実行できます。AWS Marketplace から購入し、他のワークロードと並べて管理できます。Oracle Exadata や RAC のワークロードを再アーキテクチャなしで移行し、Oracle データベース資産を統合して、AWS の分析、AI、運用サービスに直接接続できます。データベースが AWS リージョン内で動作するため、AWS の幅広いサービスに低レイテンシーでアクセスできます。生成 AI と検索拡張生成 (RAG) には Amazon Bedrock、モニタリングとガバナンスには Amazon CloudWatch、AWS KMS、AWS IAM、AWS CloudTrail を利用できます。 お客様からは、専用インフラストラクチャのコストとコミットメントという壁なしに Exadata の機能を使いたいという声が寄せられていました。専用インフラストラクチャでは、開始時にデータベースサーバー 2 台とストレージサーバー 3 台が最低構成として必要で、初期投資は決して小さくなく、すべてのワークロードに見合うわけではありません。ExaDB-XS はこのコストとコミットメントの壁に直接応えます。RAC、Smart Scan、Hybrid Columnar Compression (HCC) を含む Exadata と同じパフォーマンス、可用性、セキュリティを、プールされた共有モデルで提供します。ECPU 単位、ギガバイト単位という小さな増分でスケールし、コンピューティングとストレージを個別に追加できます。大規模な初期インフラストラクチャのコミットメントなしに始めたい場合、新しい AWS リージョンへコスト効率よく拡張したい場合、容量効率の高い 高速なデータベースクローニング を活用したい場合、Exadata Database Service on Dedicated (ExaDB-D) のクロスリージョン災害対策スタンバイをコスト効率よく運用したい場合に適しています。 Oracle AI Database@AWS ポートフォリオにおける ExaDB-XS の位置づけ ExaDB-XS は Oracle AI Database@AWS ポートフォリオをあらゆる規模のワークロードに広げ、専用インフラストラクチャの下に空いていた領域を埋めます。同一の Exadata ハードウェア上で、Oracle のデプロイメント選択肢が一通り揃いました。 サービス モデル お客様にとってのメリット ExaDB-XS (新規) — Exadata on Exascale Infrastructure 共有・プール型の Exadata コンピューティングとストレージ上で、お客様が管理する VM クラスター コミットメントが必要な最低構成インフラストラクチャなしに、Exadata のパフォーマンスと機能をフルに利用できる OS とデータベースの制御は ExaDB-D と同じなので、移行時も勝手が変わらない 従量課金 — 小さく始めて、コンピューティングとストレージを個別にスケールし、使用した分だけ支払う Oracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D) 専用 Exadata インフラストラクチャ上で、お客様が管理する VM クラスター 最大規模かつ最も要求の厳しいワークロードに向けた Exadata のパフォーマンスとシングルテナント分離 OS とデータベースをフルに制御し、必要なとおりに Oracle を運用できる パッチ適用とバージョン更新のタイミングを自社で管理し、変更管理を完全にコントロールできる Oracle Autonomous AI Database on Dedicated Exadata (ADB-D) 専用 Exadata インフラストラクチャ上のフルオートノマスデータベース 専用環境による分離と最小の運用工数 — パッチ適用、チューニング、スケーリングは Oracle がオートノマス機能で処理 日々の DBA 作業から解放され、アプリケーションに集中できる メンテナンスウィンドウは自社のビジネスカレンダーに合わせて制御できる Oracle Autonomous AI Database Serverless (ADB-S) フルオートノマス、サーバーレス、マルチテナント フルマネージドかつサーバーレスで、運用負荷は最小限。オートノマス機能を備える エラスティックなサーバーレススケーリングで、使用した分だけ支払う 管理するインフラストラクチャをゼロにしたい場合に最適 ExaDB-XS では、共有・プール型インフラストラクチャ上で ExaDB-D と同等の制御性とデータベース管理の使い勝手が得られます。Exadata の価値を支える機能を諦めることなく、小規模ワークロードまでスケールダウンできる Exadata の経済性を利用できます。 ExaDB-XS の新機能 ExaDB-XS は、Oracle Cloud Infrastructure (OCI) で利用できる Oracle Exascale の全機能と、Oracle AI Database@AWS がサポートする AWS 統合をリリース時点から備えています。つまり初日から本番ワークロードを ExaDB-XS に移行でき、最も重要な Oracle データベースに求められるセキュリティ、運用、コンプライアンスの機能もそのまま利用できます。以下の 3 つのセクションでは、ExaDB-XS が Oracle AI Database@AWS に追加する主な新機能を説明します。 コンピューティングとストレージのエラスティックなスケーリング ExaDB-XS はインフラストラクチャレベルでコンピューティングとストレージを分離します。まず、Exadata インテリジェントストレージを共有する単一の論理プール、Exascale Storage Vault をプロビジョニングします。次に 1 つ以上の VM クラスターをプロビジョニングし、Exadata のデータベース最適化コンピューティングの共有プールからコンピューティングを、Storage Vault からストレージを割り当てます。専用デプロイメントで使う Automatic Storage Management (ASM) ディスクグループとは異なり、Storage Vault は自動的にスケールし、オブジェクト単位で高冗長性を自動適用するため、ディスクグループの設計や容量分割は不要です。1 つの Storage Vault が複数の VM クラスターに対応できるので、ストレージはコンピューティング間で共有しつつ、ワークロード間の分離は保たれます。 コンピューティングは ECPU、ストレージは GB を単位とします。VM クラスターは 8 ECPU、ストレージ 300 GB から開始でき、その後はワークロードの変化に応じて各項目を個別に調整できます。スケーリングは AWS マネジメントコンソール、AWS Command Line Interface (AWS CLI)、AWS API から実行できます。 即時シンクローニング ExaDB-XS では、Oracle AI Database@AWS でシンクローニングが使えるようになります。redirect-on-write 技術により、ストレージを複製せずにデータベースの即時コピーを作成できます。クローンを作成すると、Storage Vault 内の元のデータブロックへのポインタが作られます。クローンは完全に独立したデータベースとして見え、そのように動作しますが、作成直後は追加のストレージを消費しません。ストレージを消費するのは、クローン内のデータがソースから変化した分だけです。シンクローニングは、読み取り/書き込みデータベース、読み取り専用データベース、プライマリおよびスタンバイデータベース、プラガブルデータベース、さらには既存クローンのクローンでも機能します。 本番データに対して 10 本の開発ブランチを並行して動かすチームは、フルコピー 10 個分ではなく、データベース 10 個分の変更量に対して支払います。自動化された継続的インテグレーション/継続的デリバリー (CI/CD) パイプラインの一部として新しいデータベースクローンをプロビジョニングし、テスト完了後に破棄することもできます。 初日から使える AWS サービス統合と AI 対応 ExaDB-XS は、Oracle AI Database@AWS で利用できる AWS サービス統合をリリース時点からすべて備えています。データベースの自動バックアップは Amazon Simple Storage Service (Amazon S3) に保存されます。AWS KMS がカスタマー管理キーによる暗号化を担います。Amazon CloudWatch と Amazon EventBridge がメトリクスとイベントのモニタリングを提供します。AWS IAM がアクセスを制御し、AWS CloudTrail が API 監査ログを記録します。ネットワーク接続の選択肢には AWS Transit Gateway、Amazon VPC Lattice、AWS Cloud WAN があります。ExaDB-XS は AWS Secrets Manager とも統合されており、作成/更新操作時にデータベースと Oracle Database Vault のパスワードをマネージドシークレットから安全に渡せます。機密性の高い認証情報をスクリプトや設定ファイルに置く必要がなくなります。 ExaDB-XS では、次世代の AI アプリケーションやエージェント型アプリケーションの中心に Oracle データベースを据えられます。Oracle AI Database 26ai では、AI Smart Scan が AI Vector Search を Exadata インテリジェントストレージにオフロードします。ベクトル検索と検索拡張生成 (RAG) は、分析やオンライントランザクション処理 (OLTP) を高速化するのと同じストレージ側のインテリジェンスを使い、運用データ上で動作します。データベースが AWS リージョン内で動作するため、生成 AI やエージェント向けの Amazon Bedrock、Amazon Bedrock AgentCore といったサービスをすぐ隣で利用できます。AI エージェントやアプリケーションは、最も価値あるビジネスデータを移動も複製もせずに低レイテンシーで利用できます。 ExaDB-XS を使い始める ExaDB-XS は AWS Marketplace から、セルフサービス調達のパブリックオファーまたは個別交渉のプライベートオファーで利用できます。License Included (全オプション付きの Oracle Enterprise Edition) と Bring Your Own License (BYOL) の両方に対応しています。以下では AWS マネジメントコンソールで最初の ExaDB-XS 環境を作成する手順を説明します。AWS CLI と CloudFormation の手順は Oracle AI Database@AWS のドキュメントを参照してください。 ステップ 1: ODB ネットワークを作成する Oracle AI Database@AWS を初めて使う場合は、まず ODB ネットワークを作成します。ODB ネットワークは、AWS アベイラビリティゾーン内で Oracle インフラストラクチャをホストするプライベートで分離されたネットワークです。AWS マネジメントコンソールで Oracle AI Database@AWS に移動し、[ODB Networks]、[Create ODB network] の順に選択します。アベイラビリティゾーン、クライアント接続とバックアップ接続用の Classless Inter-Domain Routing (CIDR) 範囲を指定し、必要に応じて Amazon S3 バックアップと Amazon Redshift ゼロ ETL 接続をネットワーク上で設定します。既存の Exadata Dedicated デプロイメントの ODB ネットワークがある場合は、その同じネットワークに ExaDB-XS リソースをプロビジョニングできます。 図 1: クライアントサブネットとバックアップサブネットの範囲を指定して ODB ネットワークを作成する 図 2: ODB ネットワークのサービス統合を設定する ステップ 2: Exascale Storage Vault を作成する Storage Vault は、VM クラスターが容量を割り当てて使うプール型ストレージリソースです。コンソールで [Exascale Storage Vaults] に移動し、[Create Storage Vault] を選択します。初期ストレージ容量を GB で指定し、Storage Vault を ODB ネットワークに関連付けます。作成後はいつでも容量を拡張できます。 図 3: Exascale Storage Vault を作成しストレージ容量を設定する ステップ 3: Exascale VM クラスターを作成する Storage Vault を用意したら、[VM Clusters] に移動して [Create VM Cluster]、[Exascale] の順に選択し、VM クラスターを作成します。ECPU 数 (VM あたり最小 8)、GB 単位のストレージ割り当て (合計最小 300 GB)、Oracle Database のバージョン (19c または 26ai)、ライセンスタイプを指定します。あわせて ODB ネットワークを選択し、VM へのアクセスに使う Secure Shell (SSH) キーペアを指定します。 図 4: Exascale VM クラスターの一般設定と構成を確認する 図 5: 作成前に VM クラスターの接続設定と診断設定を確認する ステップ 4: Oracle データベースを作成する VM クラスターの準備ができたら、AWS マネジメントコンソールで VM クラスターの詳細ページに移動し、[Manage in OCI] を選択します。OCI コンソールが開き、そこで Oracle データベースを作成、管理します。Oracle Database のバージョンを選択し、Amazon S3 バケットへの自動バックアップを設定して、データベースを作成します。インフラストラクチャリソース (Storage Vault、VM クラスター、ODB ネットワーク) は AWS マネジメントコンソールと AWS API の両方から引き続き参照、管理できます。 図 6: OCI コンソールで VM クラスターから Oracle データベースを作成する 料金 ExaDB-XS の料金は従量課金です。VM クラスターが消費した ECPU とストレージに対して支払い、最低インフラストラクチャコミットメントはなく、1 秒あたりの I/O 操作数 (IOPS) への個別課金もありません。License Included と Bring Your Own License の両方が利用できます。料金は OCI 上の Oracle Exadata Database Service on Exascale Infrastructure と同じです。最新の単価は Oracle AI Database@AWS の料金ページ を参照してください。 知っておきたいこと 提供リージョン。 ExaDB-XS は、Oracle AI Database@AWS が利用可能な 22 の AWS リージョンすべてで利用できます。米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、米国西部 (北カリフォルニア)、カナダ (中部)、南米 (サンパウロ)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (ミラノ)、欧州 (パリ)、欧州 (スペイン)、欧州 (ストックホルム)、欧州 (チューリッヒ)、アジアパシフィック (ハイデラバード)、アジアパシフィック (ムンバイ)、アジアパシフィック (大阪)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (東京)、オーストラリア (メルボルン)、オーストラリア (シドニー) です。 Storage Vault の容量。 Exascale Storage Vault は 1 つあたり最大 100 TB のインテリジェントストレージに対応します。それ以上の専用容量が必要な場合は、同じ ODB ネットワーク内で Oracle Exadata Database Service on Dedicated Infrastructure も併用できます。 データベースバージョン。 リリース時点では Oracle Database 19c と 26ai をサポートしています。対応バージョンは今後追加していく予定です。 モニタリング。 ExaDB-XS のリソースは AWS/ODB 名前空間で Amazon CloudWatch にメトリクスを発行します。AWS CloudTrail は API 呼び出しを記録します。Amazon EventBridge のルールを設定して、プロビジョニング完了、パッチ適用、スケーリング操作といったデータベースのライフサイクルイベントに対する自動応答をトリガーできます。 今日から始める ExaDB-XS は、世界中の Oracle AI Database@AWS 対応 22 リージョンすべてで本日から利用できます。 Oracle AI Database@AWS のサービスページ を確認するか、AWS マネジメントコンソールで Oracle AI Database@AWS に移動し、 [Create Storage Vault] を選択して始めてください。 詳細は Oracle AI Database@AWS ドキュメントの Exascale セクション、または以下のリソースを参照してください。 Oracle AI Database@AWS ドキュメント Oracle Exadata on Exascale ドキュメント (OCI) Oracle AI Database@AWS の料金 著者について Karthik Gopalakrishnan Amazon Web Services のシニアプロダクトマネージャーです。Oracle AI Database@AWS のプロダクトマネジメントを担当しています。 Jobin Joseph Jobin はトロントを拠点とするシニアデータベーススペシャリストソリューションアーキテクトです。リレーショナルデータベースエンジンを専門とし、お客様のデータベースワークロードの AWS への移行とモダナイゼーションを支援しています。Oracle Certified Master であり、Oracle データベースの経験は 25 年以上に及びます。 この記事は Solutions Architect の 矢木 覚が翻訳しました。

ニフティの開発手法はチームやプロダクトの特性によって異なりますが、現在、多くのチームで導入されているのがスクラムです。 スクラムとは、決まった期間（スプリント）ごとに価値を少しずつ届け、検査と適応を繰り返しながら進めていくフレームワークのこと。 「プロダクトオーナー（プロダクトの価値の最大化に責任を持つ）」、「スクラムマスター（スクラムの確立とチームの効果性に責任を持つ）」、「開発者」という3つの役割があり、それぞれに認定資格が存在します。今回はそのうち、プロダクトオーナーとスクラムマスターの資格を持つ、エキスパートたちにインタビュー。ニフティにおけるスクラム開発の導入事例や効果を語ってもらった前編に続き、後編では組織全体としてのスクラムの浸透度合いや、今後の課題について聞きました。 数年前の「内製化」を機に、スクラム開発へとシフト ――ニフティにおけるスクラム開発の浸透度や、導入による変化について教えてください。 西野さん プロダクトとの相性を鑑みて、あえてスクラム開発をやっていないチームもありますが、開発組織全体で見ると浸透度は高いです。スクラムマスターの資格保持者も年々増えていて、現時点で十数人。それまでにもチーム内でスクラム開発は取り入れていたけれど、より本格的にやっていきたいということで資格を取るケースもあります。 現状やっていないチームも、いったんは導入してみたけどあまりフィットせずに中止したケースや、一時は断念したけど、またトライしてみたいと私のところへ相談に来られるケースもあり、少なくとも前向きではあると思いますね。 ――以前に比べて開発組織全体でスクラム開発の導入が進んだことで、プロダクトの開発期間の短縮や、ニフティのサービスの質向上などにつながっている実感はありますか？ 清水さん そもそもの背景として、スクラム開発を導入する以前に、2018年あたりから開発を内製に切り替えていったというのが大きくて。それまでのニフティって、どちらかというとサービスのシステムは外部の開発会社の方に作っていただき、社内のエンジニアは仕様を決めたり、できあがったシステムのテストや調整だったりが主な役割でした。 私が入社したあたりから、少しずつ内製にシフトしていく動きが出てきた時に、開発方法そのものの見直しを迫られたんです。それまでのやり方は、最初に仕様をがっちり固めて外部パートナーに発注。ある程度の工期をかけてしっかり作り込んだものを最終的にこちらでテストするという、いわゆるウォーターフォール型の開発手法でした。ただ、内製でやるならスクラム開発のほうが、社内のエンジニア同士のコミュニケーションが増える利点をより活かせるのではないかと。 ――エンジニアとしてのスタンスも、大きく変わりそうですね。 清水さん そうですね。それまでは「エンジニアは企画の人に言われたことをやればいい」というスタンスでしたが、途中で違うことを言われた時に困ることもありました。最初に仕様をガチガチに固めず、小分けで実装・開発・テストを回していくスクラム開発にシフトすることでそうしたストレスも減りましたし、エンジニアのマインドセットにも影響を与えたのではないかと思います。 西野さん 私が入社した15〜16年前のニフティって、「振り返り」の文化がほぼなかったんです。せいぜい半年に一度の評価のタイミングで、それまでにやってきたことや成果を振り返るくらいで。 それがスクラムを導入して以降、早ければ1週間でプロジェクトを振り返る文化が色んなチームに根付いてきたと感じます。チーム単体のみならず開発組織全体としてもそうした動きがあり、それはスクラム文化が浸透してきたことも一因ではないかと。 吉田さん 現代のような変化が激しく複雑性の高い状況では、アジャイルな考え方が有効な場面が多いと感じています。その意味で、開発組織にスクラムが浸透してきたのは良い傾向ですが、それを真に効果的にするためには、プロダクトオーナーを輩出する企画側の深い理解が欠かせません。 単に開発側の働き方に企画側を従わせるのではなく、どうしたらスクラムのプロセスが有効なのかを一緒に考え、自分たちのプロダクトに対してアジャイルの原則と価値が機能するように落とし込んでいく必要があります。 そのあたりのはしご役は、企画側のプロダクトオーナーである私の役割だと思っています。 スクラムを開発チームだけでなく、会社全体に浸透させていく ――いま吉田さんから課題について少しお話しいただきましたが、西野さん、清水さんはいかがでしょう？　今後、ニフティのスクラム開発をより深化、あるいは企画側も含めてさらに浸透させていくためには、何が必要でしょうか？ 西野さん 吉田が言うように、スクラム導入が開発側だけで先行している点は、課題だと感じています。前回も少し話しましたが、企画と開発のフロアが別々になっていて、物理的な距離があるのも一つの原因ではあると思うので、もっと対話の機会を増やしていきたいですね。（※） 私たちポイントチームの場合は、企画側に吉田がプロダクトオーナーとして立ってくれていることもありコミュニケーションは活発ですが、他チームでも企画と開発の垣根をなくしていくことが大事です。今は「同じプロダクトに関わる組織」というだけの関係であって、企画側と開発側が一枚岩で動けているケースはそう多くないと思いますので。それができるようになると、企画と開発がそれぞれ感じているプロダクトの課題を共有できて、「その課題に対処するためにはスクラムがいいよね」といった具合に、自然とスクラム開発を導入する方向に進んでいくのではないでしょうか。 （※）インタビュー時点。2026年5月にオフィス移転し、現在は同フロアになっています。 清水さん 私も開発側の人間なのでスクラム開発を当たり前のようにやっていますが、開発組織以外の、ニフティ全体で見るとまだまだ十分に浸透しているとは言えません。特にビジネスサイドでスクラムの知見を持った人って、現状は吉田さんくらいなのかなと思っています。とはいえ、こちらがいくら「企画側もスクラムをやりましょう」とか「プロダクトオーナーの資格を取ってください」と言ったところで、課題の本質が分からないまま導入してもあまり意味がない。 吉田さんがおっしゃったように、スクラムの意味やメリットを企画側にも納得してもらうことが重要です。そのためには、スクラム開発の本質や、開発側が感じている利点、ビジネス側がそれをやることでプロダクトやサービスにどんな影響があるかといったことを言語化して、丁寧に伝えていく必要がある。それはスクラムマスターである私の役割の一つだと思いますので、ボトムアップでじわじわと組織全体に浸透させていきたいですね。 自分自身の現状を知って初めて、チームの課題が見えてくる ――最後に、みなさんが今後、ニフティのなかでチャレンジしたいことを教えてください。 吉田さん まずは自分自身が、プロダクトマネジメントというものをより理解し、実践できるようにならなくてはいけないと考えています。また、自分一人だけではなく企画側も含めた組織全体として、ニフティにあるべきプロダクトマネジメントとは何なのか、どう進めていくべきかを考え、構築していく必要がある。 そのために、たとえば開発側、企画側の上長や同僚が参加するプロダクトマネジメントの勉強会などに自分も参加しているのですが、そういった場で何かしらの発信をして、プロダクトマネジメントやスクラムに関する知見を開発以外の部署にも広げていくような活動ができればと考えています。 清水さん 先ほど話したことにも通じますが、開発内だけでなく会社の誰もが部署の垣根を超えて、自分の考えをシェアできるような場や文化を作りたいと思っています。たとえばニフティでは年2回、全社会議の場で経営陣から活動方針を伝えられるのですが、現状は一方通行というか「聞いて終わり」になってしまっているのが、もったいなく感じていて。 もっと現場の社員同士でディスカションして、「自分はこう受け取ったけど、あなたはどう思う？」といった話ができるといいのかなと。そうやって経営陣のメッセージに対する理解を深めた上で、「じゃあ自分は今期、こういう活動をしていきます」みたいなことまでシェアできると、組織全体が一枚岩になれるのではないかと思います。今はAIの活用が進み、業務時間が短縮できているので、そこで空いた時間は組織全体でもっと本質的な問いについて考えることに使いたいですよね。 西野さん チームや組織を変えるためには、まず個々のメンバーが自分自身の現状や課題に気づく必要があると考えています。自分がいま何に悩んでいるのか、何にチャレンジしたいのか、何が成長を阻んでいるのか。それが理解できて初めて、チームにも目を向けられるようになる。組織をより良い方向に変えていこうという思考が生まれる。メンバーそれぞれがチームの課題を言語化できるようになり、チーム全体にシェアされる。その結果、場合によっては課題解消のアプローチの一つとしてスクラムの導入へと至るかもしれません。 スクラムを単に形骸化したフレームワークに終わらせないためには、そうしたプロセスを踏んでいく必要があると考え、そのファーストステップとして2年前から社内コーチングを始めました。今は私だけでなく吉田と清水にもコーチングの研修を受けてもらっていて、チーム外活動としてコーチングを提供していこうと考えています。最終的にスクラムの導入というゴールに至らなかったとしても、一人ひとりが気づきを得ることで仕事へのモチベーションがアップし、組織全体の活性化にもつながっていくはずですから。 前編もご覧ください！ 今回はニフティのスクラム開発を牽引するエキスパートたちのインタビューの様子をお届けしました。あわせて前編もご覧ください。 【インタビュー】サービスを発展させるために「あらゆること」をやる。ニフティのスクラム開発を牽引するエキスパートたち【スクラムマスター 前編】 ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ このインタビューに関する求人情報/ブログ記事 ニフティ株式会社 求人情報