なぜAWSを活かしきれないのか？技術と組織への処方箋

なぜAWSを活かしきれないのか？技術と組織への処方箋 JAWS FESTA 2025 in Kanazawa 2025年10月11日 NRIネットコム株式会社執行役員
デジタルソリューション事業本部長クラウドテクニカルセンターセンター長佐々木拓郎

1 Copyright（C） NRI Netcom, Ltd. All rights reserved. このセッションの目的本日のゴール
• AWSを“技術導入”から“構造設計”として捉え直す • AWS活用を支える「組織デザイン」と「技術基盤」の関係を理解する • 自組織に適用するヒントを得る • 組織の中で、自分の役割を考えるキッカケを作る • AWS Cloud Adoption Frameworkの存在を知る

2 Copyright（C） NRI Netcom, Ltd. All rights reserved. 自己紹介 ◼
2000年 4月 NRIネットコム株式会社入社 ◼ 現在執行役員デジタルソリューション事業本部長クラウドテクニカルセンターセンター長佐々木拓郎 ◼ 執筆

3 Copyright（C） NRI Netcom, Ltd. All rights reserved. さまざまな立場でAWSと関わってきましたエンジニア
12年マネージャー 12年役員 2年 2000年 2025年 2006年 AWSとの出会い

4 Copyright（C） NRI Netcom, Ltd. All rights reserved. NRIネットコムのAWSへの取り組み APNアドバンスド
コンサルティングパートナー複数のAWS Award受賞者と多数のAWS認定者資格書籍&ブログ執筆

5 Copyright（C） NRI Netcom, Ltd. All rights reserved. なぜ、クラウドを使っても成果が出ないのか 01
変革を支える組織設計 02 クラウド時代の技術・組織構造の設計例 03 お知らせ 04

7 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWSがもたらした変化 AWSは、システム構築の「速度・スケール・自由度」を根本的に変えた
速度スケール柔軟性個人や小さな組織でも、大企業に匹敵するリソースが利用可能に

8 Copyright（C） NRI Netcom, Ltd. All rights reserved. でも、AWSを活かしきれていますか？技術の制約は解けた。それでも成果が出ない組織も多いのでは？
速度スケール柔軟性組織構造意思決定サイロ化構造の制約クラウドの利点制限構造の制約が、クラウドのポテンシャルを制限

9 Copyright（C） NRI Netcom, Ltd. All rights reserved. 開発者の認知負荷が高まっている問題開発者の責任範囲が広がり、処理できる情報量の限界を迎えつつある
『Platform Engineeringとは何か？なぜ注目されているのか』より引用 https://codezine.jp/article/detail/18752 ⚫ アプリケーションアーキテクチャの変遷 ⚫ インフラの定義の変化 ⚫ 開発者の責任範囲の拡大による認知負荷の増大ここを軽減する仕組みが必要

10 Copyright（C） NRI Netcom, Ltd. All rights reserved. なんだか最近、忙しいこんな状態になっていませんか？
⚫ 作業効率は格段にあがっている ⚫ Outputの量も増えている ⚫ いつも忙しい ⚫ 全体のスループットが向上にはつながらない技術と組織での両面で解決を図りましょう！！

12 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWS Cloud
Adoption Framework: People Perspectiveが示す7つの変革領域 AWSのクラウド導入フレームワークには、文化と変革に着目した導入手順が用意されている ⚫ Culture / Leadership / Fluency / Workforce / Change / Org Design / Alignment ⚫ 特に重要なのは「文化」と「リーダーシップ」と「構造」 AWS Cloud Adoption Framework: People Perspective 人員のパースペクティブ：文化と変革 https://docs.aws.amazon.com/ja_jp/whitepapers/latest/overview-aws-cloud-adoption-framework/people-perspective.html

13 Copyright（C） NRI Netcom, Ltd. All rights reserved. トップダウンからの変革 Transformational
Leadership：変革を牽引するリーダー ⚫ CxO層は「AWSのROI」ではなく「組織変革のROI」で語るべき ⚫ 変化に向き合える中間層（マネージャー）を支援する仕組みが鍵技術と組織での両面で解決を図りましょう！！項目内容コストの性質人的投資 CCoEや人材育成組織の設立固定費（人件費）教育・仕組み化トレーニング・ドキュメント整備・自動化パイプライン構築一時的投資権限・プロセス見直し責任範囲やガイドライン作成アラインメント投資プラットフォーム構築 CI/CD、IaC、共通アカウント管理技術/設備投資

14 Copyright（C） NRI Netcom, Ltd. All rights reserved. ボトムアップからの改善文化を行動で変える。行動で文化を作る
⚫ 「失敗を恐れず、素早く学ぶ」文化は自動的には生まれない ⚫ 報酬・承認・評価の仕組みに新しい行動を埋め込む ⚫ 行動を測定可能にすることで文化は変えられるありたい姿を定義して、仕組みに落とし込む観点新しい行動様式報酬・承認・評価測定方法・指標期待される効果失敗を恐れず挑戦する PoC・実験・検証の実施を評価 “挑戦件数”を定例で共有／成功率よりも学びの数を評価 PoC数、検証→本番化率、ふりかえり投稿数学習サイクルの高速化、心理的安全性の向上学びを共有する失敗事例やナレッジをCCoE・ Wikiに公開ナレッジ投稿・共有回数を評価指標に追加投稿数、閲覧数、再利用率組織知の蓄積・再利用による生産性向上標準化・自動化を推進する手作業を自動化、IaC化を推奨 “改善提案”や“自動化PR”を評価 IaC比率、手動作業削減率、CI/CD 導入率再現性・セキュリティ・スピードの向上クロスチームで助け合うチーム外レビュー・共同検証横断貢献（他チームサポート）を評価に反映他チーム支援件数、社内登壇回数サイロ解消・全体最適の意識強化改善を数値で語る「やってみた結果」を定量報告 OKR・KPIを週次で見える化改善サイクル数、KPI改善率行動の継続性・成果可視化による納得感

15 Copyright（C） NRI Netcom, Ltd. All rights reserved. トップダウンとボトムダウンの両面で構造を変える AWSを活かす組織は、リーダーの方向性
× 現場の行動で構造をつくる ⚫ トップダウンだけでは、変化は号令で終わる ⚫ ボトムアップだけでは、実行力が伴わず燃え尽きる観点実施内容目的・効果権限設計の再構築情シス・CCoE・事業部の責任分担を明確化（例：IdP／Identity Center ／アカウント管理）トップの戦略を現場の判断に落とし込む構造を作る意思決定の分散化「承認」から「信頼と原則ベースの判断」へ移行（例：SCPで枠を定義し中間層に裁量）中間層が変化に向き合える環境を作る標準と例外の明文化共通基盤・テンプレート・ベストプラクティスを共有（CCoE／Wiki化）現場の判断を統一しつつ、学習サイクルを加速学習と成果の可視化 KPI・行動メトリクスをダッシュボード化（例：リードタイム、変更頻度、再利用率）ボトムアップの行動が経営指標に反映される構造を作る組織横断チームの設置 Platform／Enablementチームを設置し、現場支援と標準化を両立トップダウンとボトムアップの橋渡し役を明確化文化は行動で変わる。行動は構造で支えられる

17 Copyright（C） NRI Netcom, Ltd. All rights reserved. IAM Identity
Centerでみる組織と技術のマッピング IAM Identity Centerの例

18 Copyright（C） NRI Netcom, Ltd. All rights reserved. IAMのベストプラクティスの変遷 2019年
2025年 1 AWS アカウントのルートユーザーのアクセスキーをロックする人間のユーザーが一時的な認証情報を使用して AWS にアクセスする場合に ID プロバイダーとのフェデレーションを使用することを必須とする 2 個々のIAM ユーザーの作成ワークロードが AWS にアクセスする場合に IAM ロールで一時的な資格情報を使用することを必須とする 3 IAM ユーザーへのアクセス許可を割り当てるためにグループを使用する多要素認証 (MFA) を必須とする 4 最小権限を付与する長期的な認証情報を必要とするユースケースのためにアクセスキーを必要な時に更新する 5 AWS 管理ポリシーを使用したアクセス許可の使用開始ルートユーザーの認証情報を保護するためのベストプラクティスに沿う 6 インラインポリシーではなくカスタマー管理ポリシーを使用する最小特権アクセス許可を適用する 7 アクセスレベルを使用して、IAM 権限を確認する AWS 管理ポリシーの使用を開始し、最小特権のアクセス許可に移行する 8 ユーザーの強力なパスワードポリシーを設定 IAM Access Analyzer を使用して、アクセスアクティビティに基づいて最小特権ポリシーを生成する 9 特権ユーザーに対してMFA を有効化する未使用のユーザー、ロール、アクセス許可、ポリシー、および認証情報を定期的に確認して削除する 10 Amazon EC2 インスタンスで実行するアプリケーションに対し、ロールを使用する IAM ポリシーで条件を指定して、アクセスをさらに制限する 11 ロールを使用したアクセス許可の委任 IAM Access Analyzer を使用して、リソースへのパブリックアクセスおよびクロスアカウントアクセスを確認する 12 アクセスキーを共有しない IAM Access Analyzer を使用して IAM ポリシーを検証し、安全で機能的なアクセス許可を確保する 13 認証情報を定期的にローテーションする複数のアカウントにまたがるアクセス許可のガードレールを確立する 14 不要な認証情報を削除するアクセス許可の境界を使用して、アカウント内のアクセス許可の管理を委任する 15 追加セキュリティに対するポリシー条件を使用する 16 AWS アカウントのアクティビティの監視 17 IAM ベストプラクティスについてビデオで説明する廃止新規に追加

Centerの概念図と用語 AWS IAM Identity Center インスタンスワークフォースユーザー許可セットアクセスターゲット AWSアカウント一部のAWSのアプリケーション WorkSpaces QuickSight Grafana カスタムアプリケーション（SAML/OIDC対応）利用者 IdP 内部ディレクトリ：IAM Identity Center 外部IdP：Okta,Entra ID, Etc 認証依頼 SAML token

Center + IdP+IAMロールをどう管理するか？認証認可をコントロールする３つのサービスの管理主体がバラバラのケースが多い • IdPの管理主体：情報システム部（全社のID管理） • IAM Identity Centerで管理する許可セット：CCoEなど横断組織 • 各アカウントで事業主体が管理するIAMロール：事業部 IAM Identity Center IdP 各AWSアカウント Okta,Entra ID, Etc 許可セットアカウント内生成の IAMロール IAMポリシー許可セットから生成される IAMロール管理主体の問題 CCoE 情シス各事業部の管理者この３つの要素は組織次第で管理方法が変わる

21 Copyright（C） NRI Netcom, Ltd. All rights reserved. ３者での責任範囲の分解例 1/3
IAM Identity Center IdP 各AWSアカウント Okta,Entra ID, Etc AWS 各アカウントで使える権限は同じ CCoE 情シス各事業部の管理者 Role 各事業部は、与えられたRoleを利用してリソース作成全アカウント共通の汎用的な許可セットを利用ユーザーの認証情報のみ管理中央管理の設計パターン AWSリソース汎用許可セット中央管理型で運用に支障無いような形になればベスト

22 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWSアカウントA AWSアカウントA
３者での責任範囲の分解例 2/3 アカウント単位の設計パターン IAM Identity Center IdP AWSアカウントA Okta,Entra ID, Etc AWS アカウントに最適化された IAM Role CCoE 情シス各事業部の管理者 Role 許可セット設計で Identity Center管理者と調整が必要アカウント毎に許可セットを作成 ※許可セット多すぎ問題ユーザーの認証情報のみ管理 AWSリソースアカウントX 許可セット Identity Center管理の負荷が高いが、事業部任せにならないアカウントA 許可セット

23 Copyright（C） NRI Netcom, Ltd. All rights reserved. ３者での責任範囲の分解例 3/3
IAM Identity Center IdP 各AWSアカウント Okta,Entra ID, Etc IdPでログインしたユーザがスイッチするロール CCoE 情シス各事業部の管理者 Role Role 各事業部でアカウント内の利用できるリソースを定義許可セットを元に利用するロールを管理ユーザーの認証情報のみ管理ハイブリッド型の設計パターンスイッチロールのみの許可セット各事業部側の管理者に高い能力を求められるが、自由度が高い AWSリソース IAMロールの利用状況を追跡可能にする必要あり

25 Copyright（C） NRI Netcom, Ltd. All rights reserved. TEAM等を使って、一時的な権限昇格の仕組みの構築本番環境
Jumpアカウント or IAM Identity Center 利用者（申請者） IAMロール AWSの場合（Microsoft Entra IDにもPrivileged Identity Managementという製品がある）承認者承認後に権限が発行され利用可能にアクセス申請の承認要求監査人管理者システムの利用状況をログから監査申請ルールの管理

27 Copyright（C） NRI Netcom, Ltd. All rights reserved. 担当制から横断制へ。MSP型運用の思想案件ごとの小チームでの運用から、横断的な運用チームに移行
⚫ システムごとの担当ではなく、複数システムを横断的に支援・自動化。 ⚫ 運用・監視・セキュリティ・コスト最適化を、プラットフォーム化して提供。 ⚫ 社内MSPのように“運用の共通サービス化”を目指す。事業A用 AWSアカウント事業B用 AWSアカウント事業C用 AWSアカウント運用チームA メンバー1～2人運用チームB メンバー3人運用チームC メンバー2人マネジメント AWSアカウント事業A用 AWSアカウント事業B用 AWSアカウント事業C用 AWSアカウント Before After CCoEチームがアカウントマネジメント MSPチームが運用を一元管理

29 Copyright（C） NRI Netcom, Ltd. All rights reserved. テックブログ ◼
2021年3月に開設。直近1年の月間PV数 6万～12万で推移 ◼ 累計記事数 1,027本 • 2021年 114本 • 2022年 192本 • 2023年 222本 • 2024年 266本 • 2025年 233本 ※2025年10月6日現在 ◼ 技術的な記事以外にもライフスタイルやカルチャーなど幅広く社員の知見や考え方を発信し、扱ってる技術や業務だけでなく当社のカラーもブログから感じてもらえるよう意識

30 Copyright（C） NRI Netcom, Ltd. All rights reserved. 文化の醸成ブログを書くことが当たり前という雰囲気を作る
例）・こんなことを書いてもいいのか？と思っている人 →あなたが普通だと思っていることは実は世の中では誰かの役に立つ可能性を大いに秘めている・雑談しているときに運営視点でいいネタがポロッと出てきた →それ書いてみない？と話してみる ◼ ブログの社内認知の促進 • 社内認知の促進 • 執筆してみようかな/してみたいなという雰囲気の醸成 • 執筆後のフィードバック ◼ 雰囲気の醸成 • チームの先輩や、同期が書いている。自分も書いてみようかという雰囲気 • ブログを書くことが当たり前にする

35 Copyright（C） NRI Netcom, Ltd. All rights reserved. NRIネットコムの勉強会、随時開催しています毎月、2～3回のペースで開催中。connpassで申し込めます
【開催テーマ】・AWSマンスリーアップデートピックアップ・AWS Ambassador 3人のよる毎月の登壇・個別技術テーマ・デジタルマーケティングやデザイン関係の勉強会もあります NRIネットコム connpass https://nrinetcom.connpass.com/

なぜAWSを活かしきれないのか？技術と組織への処方箋

なぜAWSを活かしきれないのか？技術と組織への処方箋

More Decks by NRI Netcom

Other Decks in Technology

Featured

Transcript