Tweet
Tweet

Slide 1

Slide 1 text

AWSコンテナ本出版から3 年経った今、もし改めて執 筆し直すなら… 新井 雅也 (@msy78)

Slide 2

Slide 2 text

全体方針・設計 パート 構築・ハンズオン パート

Slide 3

Slide 3 text

全体方針・設計 パート 構築・ハンズオン パート こちらのパートから 20分間お話します！ 馬勝さんパートと内容が重複する点があるかもしれませんが、ご容赦ください

Slide 4

Slide 4 text

新井 雅也 現在は衛星の開発・運用を手掛けるSynspectiveにて、クラウドを 中心とした技術力を活かしつつ、宇宙業界の発展に尽力している。 好きなAWSサービスは、Amazon ECS、AWS Fargate。 好きなエナジードリンクはRed Bull。 AWS Container Hero AWS Ambassador 2022-2023 Google Cloud Champion Innovator Google Cloud Partner Top Engineer 2023 @msy78 Principal Cloud Architect

Slide 5

Slide 5 text

本発表の目的 • 書籍出版から3年間の内容を踏まえ、ECS/Fargateを前提としたアーキテク チャ設計の最適解を探る • 本書を読んだことがある方に対して、更に最適な設計・構築ができるような ヒントを提供する

Slide 6

Slide 6 text

おはなしの前提 AWS上におけるECS/Fargateに関連した 技術・サービスの話にとどめます Kubernetesやその他コンテナ系サービス(App Runner等)に関する トピックは今回の発表では対象外

Slide 7

Slide 7 text

時間軸 2021年 10月

Slide 8

Slide 8 text

時間軸 2021年 10月 2021年出版当時のコンテナ本内ECS/Fargateアーキテクチャ

Slide 9

Slide 9 text

時間軸 2024年 10月 2021年 10月 ちょうど 3年が経過

Slide 10

Slide 10 text

時間軸 2024年 10月 ??? 2021年 10月

Slide 11

Slide 11 text

時間軸 本日お話すること 2024年 10月 どのような AWSアーキテクチャを主軸にしながら 改めて読者のみなさまに価値を届けるか？ 2021年 10月

Slide 12

Slide 12 text

時間軸 本日お話すること（３つの観点から考察） 2024年 10月 2021年 10月 ECS/Fargateをとりまく アーキテクチャデザイン Well-Architected Framework再考 サービス新規利用停止と 終了を踏まえて

Slide 13

Slide 13 text

ECS/Fargateを取り巻くアーキテクチャデザイン

Slide 14

Slide 14 text

初版では、あえてECS/Fargateと他のAWSサービスのつなぎ方を 個別に切り出して執筆しなかった

Slide 15

Slide 15 text

• 刊行当初でさえAWSサービス数は200を超え、サービス連携の仕方は無数に存在 初版では、あえてECS/Fargateと他のAWSサービスのつなぎ方を 個別に切り出して執筆しなかった

Slide 16

Slide 16 text

• 刊行当初でさえAWSサービス数は200を超え、サービス連携の仕方は無数に存在 • サービス連携の判断は自分たちのビジネス要件次第 • ニーズに合わせて最終的には意思決定される • ECS/Fargateのサービス興隆期でもあり、見極めが難しい • 自分たちが紹介するアーキテクチャを”ベストプラクティス”と謳うには時期尚早 初版では、あえてECS/Fargateと他のAWSサービスのつなぎ方を 個別に切り出して執筆しなかった

Slide 17

Slide 17 text

• 刊行当初でさえAWSサービス数は200を超え、サービス連携の仕方は無数に存在 • サービス連携の判断は自分たちのビジネス要件次第 • ニーズに合わせて最終的には意思決定される • ECS/Fargateのサービス興隆期でもあり、見極めが難しい • 自分たちが紹介するアーキテクチャを”ベストプラクティス”と謳うには時期尚早 • ECS/Fargateベースのシステムを本番運用することを想定し、価値提供の先として 読者のみなさまが自力で設計・構築できる状態を目指した 初版では、あえてECS/Fargateと他のAWSサービスのつなぎ方を 個別に切り出して執筆しなかった

Slide 18

Slide 18 text

あれから3年、AWS上におけるコンテナ活用が広がり、 要件に合わせた最適な組み合わせ方が確立されてきている

Slide 19

Slide 19 text

• 1日における世界中のECSタスクの起動数は3億個/日 あれから3年、AWS上におけるコンテナ活用が広がり、 要件に合わせた最適な組み合わせ方が確立されてきている

Slide 20

Slide 20 text

• 1日における世界中のECSタスクの起動数は3億個/日 • AWS上でコンテナを利用しようとしている新規ユーザーの65%がECSを選択 あれから3年、AWS上におけるコンテナ活用が広がり、 要件に合わせた最適な組み合わせ方が確立されてきている

Slide 21

Slide 21 text

• 1日における世界中のECSタスクの起動数は3億個/日 • AWS上でコンテナを利用しようとしている新規ユーザーの65%がECSを選択 • ECS/Fargateを活用したアーキテクチャ事例も多数公開されている • 事例は生きた（ビジネスとして価値を生み出す or 生み出さない）アーキテクチャの証拠 • 「外さない(無難な)」アーキテクチャデザインが見えるようになってきた • よく採用されるアーキテクチャパターンはそれなりの理由がある あれから3年、AWS上におけるコンテナ活用が広がり、 要件に合わせた最適な組み合わせ方が確立されてきている

Slide 22

Slide 22 text

つまりお伝えしたいことは... 「ECS/Fargateに関する要件に合わせた最適な アーキテクチャパターンを紹介できるフェーズになった」 ということ

Slide 23

Slide 23 text

ここで、いくつかのアーキテクチャパターンを 一緒に考えてみましょう

Slide 24

Slide 24 text

例１）インターネット上にWebアプリケーションを公開する場合

Slide 25

Slide 25 text

例１）インターネット上にWebアプリケーションを公開する場合

Slide 26

Slide 26 text

要件のユースケース 1 • なるべくシンプルかつスモール 構成でアプリケーションを公開 したい • 一般的なWebアプリケーション セキュリティ対策を施したい • アクセス増に対するアプリケー ションの可用性を高めたい 例１）インターネット上にWebアプリケーションを公開する場合

Slide 27

Slide 27 text

要件のユースケース 1 • なるべくシンプルかつスモール 構成でアプリケーションを公開 したい • 一般的なWebアプリケーション セキュリティ対策を施したい • アクセス増に対するアプリケー ションの可用性を高めたい 例１）インターネット上にWebアプリケーションを公開する場合

Slide 28

Slide 28 text

要件のユースケース 2 • 一般的なWebアプリケーション セキュリティ対策を施したい • アクセス増に対するアプリケー ションの可用性を高めたい • グローバルからのアクセスのレ スポンスを最適化したい 例１）インターネット上にWebアプリケーションを公開する場合

Slide 29

Slide 29 text

要件のユースケース 2 • 一般的なWebアプリケーション セキュリティ対策を施したい • アクセス増に対するアプリケー ションの可用性を高めたい • グローバルからのアクセスのレ スポンスを最適化したい 例１）インターネット上にWebアプリケーションを公開する場合

Slide 30

Slide 30 text

要件のユースケース 3 • 一般的なWebアプリケーション セキュリティ対策を施したい • アクセス増に対するアプリケー ションの可用性を高めたい。ま た、一定数のアクセスに流量制 御を設けたい • グローバルからのアクセスのレ スポンスを最適化したい • 個別の認証・認可を実装したい 例１）インターネット上にWebアプリケーションを公開する場合

Slide 31

Slide 31 text

要件のユースケース 3 • 一般的なWebアプリケーション セキュリティ対策を施したい • アクセス増に対するアプリケー ションの可用性を高めたい。ま た、一定数のアクセスに流量制 御を設けたい • グローバルからのアクセスのレ スポンスを最適化したい • 個別の認証・認可を実装したい 例１）インターネット上にWebアプリケーションを公開する場合

Slide 32

Slide 32 text

例２）定期実行ジョブを構成したい場合

Slide 33

Slide 33 text

例２）定期実行ジョブを構成したい場合

Slide 34

Slide 34 text

例２）定期実行ジョブを構成したい場合 要件のユースケース 1 • 単発の処理を実行したい • 開発コストをかけず、 シンプルに運用したい

Slide 35

Slide 35 text

例２）定期実行ジョブを構成したい場合 要件のユースケース 1 • 単発の処理を実行したい • 開発コストをかけず、 シンプルに運用したい

Slide 36

Slide 36 text

例２）定期実行ジョブを構成したい場合 要件のユースケース 2 • 複数の処理を実行したい • 処理結果によって、分岐処理を 設けたい • 他のAWSサービスと連動した ジョブ処理を構成したい • リトライ処理を容易に実装した い

Slide 37

Slide 37 text

例２）定期実行ジョブを構成したい場合 要件のユースケース 2 • 複数の処理を実行したい • 処理結果によって、分岐処理を 設けたい • 他のAWSサービスと連動した ジョブ処理を構成したい • リトライ処理を容易に実装した い

Slide 38

Slide 38 text

例２）定期実行ジョブを構成したい場合 要件のユースケース 3 • 複数の処理を実行したい • マイクロサービスで構成された API処理を組み合わせて処理を 実行したい • リトライ処理を容易に実装した い

Slide 39

Slide 39 text

例２）定期実行ジョブを構成したい場合 要件のユースケース 3 • 複数の処理を実行したい • マイクロサービスで構成された API処理を組み合わせて処理を 実行したい • リトライ処理を容易に実装した い

Slide 40

Slide 40 text

より良い設計を模索するために、 確立された設計パターンとその採用理由を学ぶことは価値がある

Slide 41

Slide 41 text

• 愚者は経験から学び、賢者は歴史（他者の成功と失敗）から学ぶ より良い設計を模索するために、 確立された設計パターンとその採用理由を学ぶことは価値がある

Slide 42

Slide 42 text

• 愚者は経験から学び、賢者は歴史（他者の成功と失敗）から学ぶ • アーキテクチャの設計理由をビジネス観点から言語化するのは 設計者自身の責務 より良い設計を模索するために、 確立された設計パターンとその採用理由を学ぶことは価値がある

Slide 43

Slide 43 text

Well Architected Framework再考

Slide 44

Slide 44 text

Well Architected Framework おさらい

Slide 45

Slide 45 text

クラウド上のシステム設計時における、 AWSが提供する非機能観点のアーキテクチャベストプラクティス Well Architected Framework おさらい

Slide 46

Slide 46 text

Well Architected Framework おさらい クラウド上のシステム設計時における、 AWSが提供する非機能観点のアーキテクチャベストプラクティス

Slide 47

Slide 47 text

刊行当初における Well Architected Framework に沿った設計観点

Slide 48

Slide 48 text

 ログ・メトリクス設計  トレース設計  CI/CD設計  イメージメンテナンス運用  Bastion設計  イメージセキュリティ  レジストリセキュリティ  オーケストレータセキュリティ  コンテナセキュリティ  スケールアップ戦略  スケールアウト戦略  マルチAZ構成の考慮  障害時切り離しと復旧  システムメンテナンスの考慮  サービスクォータ  ECSタスク数とリソースサイジング  Compute Savings Plans  ECSコンテナイメージのメンテナンス  タスク稼働時間帯の調整  Fargateスポットの調整  コンテナイメージサイズの削減 刊行当初における Well Architected Framework に沿った設計観点

Slide 49

Slide 49 text

刊行当初におけるWell Architect Frameworkに沿った設計観点  ログ・メトリクス設計  トレース設計  CI/CD設計  イメージメンテナンス運用  Bastion設計  イメージセキュリティ  レジストリセキュリティ  オーケストレータセキュリティ  コンテナセキュリティ  スケールアップ戦略  スケールアウト戦略  マルチAZ構成の考慮  障害時切り離しと復旧  システムメンテナンスの考慮  サービスクォータ  ECSタスク数とリソースサイジング  Compute Savings Plans  ECSコンテナイメージのメンテナンス  タスク稼働時間帯の調整  Fargateスポットの調整  コンテナイメージサイズの削減 刊行から3年、ECS/Fargateや関連サービスは どのように進化したのか？

Slide 50

Slide 50 text

50 書籍刊行〜現在までのECS/Fargate主要アップデートを追ってみる

Slide 51

Slide 51 text

時間軸 書籍刊行〜現在までのECS/Fargate主要アップデートを追ってみる

Slide 52

Slide 52 text

時間軸 書籍刊行〜現在までのECS/Fargate主要アップデートを追ってみる 2022-11-23 : Graviton2サポート アプリケーションをarm64向けにビルドできれば、 vCPUとメモリのコストを25%程度安く利用できる

Slide 53

Slide 53 text

時間軸 書籍刊行〜現在までのECS/Fargate主要アップデートを追ってみる 2022-11-23 : Graviton2サポート 2022-03-01 : FISがECSタスクをサポー ト FISにより、ECSクラスター、ECSタスク、 Auroraクラスターレベルでの障害注入が可能となり、 信頼性の検証がしやすくなった。

Slide 54

Slide 54 text

時間軸 書籍刊行〜現在までのECS/Fargate主要アップデートを追ってみる 2022-11-23 : Graviton2サポート 2022-04-13 : タスクスケーリング改善 2022-11-10 : タスクのスケールイン保護 2022-03-01 : FISがECSタスクをサポー ト ECSタスクの起動が16倍高速になった。 また、ミッションクリティカルなタスクが意図せず終 了しないように制御できるようになった。

Slide 55

Slide 55 text

時間軸 書籍刊行〜現在までのECS/Fargate主要アップデートを追ってみる 2022-11-23 : Graviton2サポート 2022-04-13 : タスクスケーリング改善 2022-11-10 : タスクのスケールイン保護 2022-11-27 : ECS Service Connectの発表 2022-03-01 : FISがECSタスクをサポー ト サービスの検出やトラフィック観測に対応した ECS間の接続構成が可能なった。

Slide 56

Slide 56 text

時間軸 書籍刊行〜現在までのECS/Fargate主要アップデートを追ってみる 2022-11-23 : Graviton2サポート 2022-04-13 : タスクスケーリング改善 2022-11-10 : タスクのスケールイン保護 2022-11-27 : ECS Service Connectの発表 2023-11-26 : Fargateにおける 2022-03-01 : FISがECSタスクをサポー ト GuardDuty ECS runtime monitoring GuardDutyによる脅威検知がECSにも対応。 サイドカーによるセキュリティエージェント により、潜在的な問題を検出可能 （コストバランスは要検討）

Slide 57

Slide 57 text

時間軸 書籍刊行〜現在までのECS/Fargate主要アップデートを追ってみる 2022-11-23 : Graviton2サポート 2022-04-13 : タスクスケーリング改善 2022-11-10 : タスクのスケールイン保護 2022-11-27 : ECS Service Connectの発 表 2024-07-12 : 停止タスクの 2023-11-26 : Fargateにおける 2022-03-01 : FISがECSタスクをサポー ト GuardDuty ECS runtime monitoring エラーメッセージ内容強化 タスク停止時のエラーメッセージがより具体的に なった。さらにSlack等と連携することで、トラブ ルシューティングがしやすくなる。

Slide 58

Slide 58 text

時間軸 書籍刊行〜現在までのECS/Fargate主要アップデートを追ってみる 2022-11-23 : Graviton2サポート 2022-04-13 : タスクスケーリング改善 2022-11-10 : タスクのスケールイン保護 2022-11-27 : ECS Service Connectの発表 2024-07-12 : 停止タスクの 2024-09-07 : GravitonベースのSpot利用 2023-11-26 : Fargateにおける 2022-03-01 : FISがECSタスクをサポー ト GuardDuty ECS runtime monitoring エラーメッセージ内容強化 可用性とのバランスで折り合いがつけば、 Fargate料金を最大70%割引可能

Slide 59

Slide 59 text

 ログ・メトリクス設計  トレース設計  CI/CD設計  イメージメンテナンス運用  Bastion設計  イメージセキュリティ  レジストリセキュリティ  オーケストレータセキュリティ  コンテナセキュリティ  スケールアップ戦略  スケールアウト戦略  マルチAZ構成の考慮  障害時切り離しと復旧  システムメンテナンスの考慮  サービスクォータ  ECSタスク数とリソースサイジング  Compute Savings Plans  ECSコンテナイメージのメンテナンス  タスク稼働時間帯の調整  Fargateスポットの調整  コンテナイメージサイズの削減  Gravitonの考慮  Gravitonの考慮 刊行当初における Well Architected Framework に沿った設計観点

Slide 60

Slide 60 text

現在におけるWell Architected Frameworkに沿った設計観点  ログ・メトリクス設計  トレース設計  CI/CD設計  イメージメンテナンス運用  Bastion設計  (追加)トラブルシューティング  イメージセキュリティ  レジストリセキュリティ  オーケストレータセキュリティ  コンテナセキュリティ  (追加) ランタイムセキュリティ  スケールアップ戦略  スケールアウト戦略  マルチAZ構成の考慮  障害時切り離しと復旧  システムメンテナンスの考慮  サービスクォータ  (追加) FISによる耐障害性の検証  ECSタスク数とリソースサイジング  Compute Savings Plans  ECSコンテナイメージのメンテナンス  タスク稼働時間帯の調整  Fargateスポットの調整  コンテナイメージサイズの削減  Gravitonの考慮  (追加)Gravitonの利用検討 ECS Execの活用 タスクのエラーメッセージ

Slide 61

Slide 61 text

昨今のサービス新規利用停止・終了を踏まえて

Slide 62

Slide 62 text

AWSはユーザニーズに基づく価値発散から収束のフェーズに

Slide 63

Slide 63 text

昨今では一部AWSサービスの新規利用停止と終了がアナウンス(2025/10/31時点)

Slide 64

Slide 64 text

AWS App Mesh 2026/09/30終了予定 AWS App Cost Profiler 2024/09/30終了 AWS Cloud9 2024/07/25新規受付停止 Amazon Cloud Search 2024/07/25新規受付停止 AWS CodeCommit 2024/07/25新規受付停止 AWS CodeStar 2024/07/31終了 AWS Data Pipeline 2024/07/25新規受付停止 AWS DeepComposer 2025/09/17終了予定 AWS DeepLens 2024/01/31終了 AWS DeepRacer 2025/12終了予定 Amazon Forecast 2024/07/29新規受付停止 Amazon FSx File Gateway 2024/10/28新規受付停止 Amazon Honeycode 2024/02/29終了 AWS IoT 1-Click 2024/12/16終了予定 AWS Lex V1 2025/09/30終了予定 ※V2に以降 Lookout for Equipment 2024/10/17新規受付停止 AWS OpsWorks 2024/05/26終了 Amazon QLDB 2025/07/31終了予定 AWS RoboMaker 2025/09/10終了予定 Amazon S3 Select 2024/07/25新規受付停止 Amazon SimpleDB 2024/07/25新規受付停止 AWS WAF Classic 2025/09/30終了 ※V2に以降 NICE EnginFrame 2025/09/25終了予定 AWS Snowmobile 2024/03終了 Amazon IoT Analytics 2024/07/25新規受付停止 AWS IoT Device Management Fleet Hub 2025/10/18終了予定 AWS Kinesis Data Analytics for SQL 2028/01/27終了予定 Amazon CloudWatch Evidently 2025/10/17終了予定 昨今では一部AWSサービスの新規利用停止と終了がアナウンス(2025/10/31時点)

Slide 65

Slide 65 text

AWS App Cost Profiler 2024/09/30終了 Amazon Cloud Search 2024/07/25新規受付停止 AWS CodeStar 2024/07/31終了 AWS Data Pipeline 2024/07/25新規受付停止 AWS DeepComposer 2025/09/17終了予定 AWS DeepLens 2024/01/31終了 AWS DeepRacer 2025/12終了予定 Amazon Forecast 2024/07/29新規受付停止 Amazon FSx File Gateway 2024/10/28新規受付停止 Amazon Honeycode 2024/02/29終了 AWS IoT 1-Click 2024/12/16終了予定 AWS Lex V1 2025/09/30終了予定 ※V2に以降 Lookout for Equipment 2024/10/17新規受付停止 AWS OpsWorks 2024/05/26終了 Amazon QLDB 2025/07/31終了予定 AWS RoboMaker 2025/09/10終了予定 Amazon S3 Select 2024/07/25新規受付停止 Amazon SimpleDB 2024/07/25新規受付停止 AWS WAF Classic 2025/09/30終了 ※V2に以降 NICE EnginFrame 2025/09/25終了予定 AWS Snowmobile 2024/03終了 Amazon IoT Analytics 2024/07/25新規受付停止 AWS IoT Device Management Fleet Hub 2025/10/18終了予定 AWS Kinesis Data Analytics for SQL 2028/01/27終了予定 Amazon CloudWatch Evidently 2025/10/17終了予定 AWSコンテナ本含め、ECS/Fargate関連システムで影響があるサービス AWS App Mesh 2026/09/30終了予定 AWS Cloud9 2024/07/25新規受付停止 AWS CodeCommit 2024/07/25新規受付停止

Slide 66

Slide 66 text

もともと、ECS間のサービス接続方式は4種類存在

Slide 67

Slide 67 text

ALBによる接続 ECS Service Discoveryによる接続 AWS App Meshによる接続 ECS Service Connectによる接続 もともと、ECS間のサービス接続方式は4種類存在 ・B/Gデプロイや追加メトリクスの取得 ・追加のALBコストとリソース管理 ・シンプルな構成 ・トラフィックのメトリクスなし ・トラフィック制御、mTLS通信 ・構成管理が複雑になりがち ・シンプルかつ追加メトリクスの取得 ・サイドカー注入による追加コスト

Slide 68

Slide 68 text

ALBによる接続 ECS Service Discoveryによる接続 AWS App Meshによる接続 ECS Service Connectによる接続 ・B/Gデプロイや追加メトリクスの取得 ・追加のALBコストとリソース管理 ・シンプルな構成 ・トラフィックのメトリクスなし ・トラフィック制御、mTLS通信 ・構成管理が複雑になりがち ・シンプルかつ追加メトリクスの取得 ・サイドカー注入による追加コスト 2026年9月30日にサービス終了予定 AWS App Mesh終了により、ECSタスク間の接続方法は今後3種類となる

Slide 69

Slide 69 text

AWS Cloud9の新規受付停止により、諸々の開発作業環境の移行が必要に

Slide 70

Slide 70 text

AWS Cloud9の新規受付停止により、諸々の開発作業環境の移行が必要に ここ

Slide 71

Slide 71 text

一部のユーザーにおいては、書籍内のハンズオンが手順どおり実行できなくなってしまう AWS Cloud9の新規受付停止により、諸々の開発作業環境の移行が必要に

Slide 72

Slide 72 text

代替としてのCloudShellは有力候補だが、各種制約に気をつける必要あり

Slide 73

Slide 73 text

• 永続ストレージの容量が1GBしかない • 120日利用がないと削除される • サイズの引き上げが不可 • VPC環境で起動すると、そもそも永続ストレージがない • 毎月の使用量クォーター(200時間/月)が存在する • 場合によってはクォーター引き上げが必要 • 20-30分操作しないとシェルセッションが終了する 代替としてのCloudShellは有力候補だが、各種制約に気をつける必要あり

Slide 74

Slide 74 text

新規ユーザーはCodeCommitが利用できない

Slide 75

Slide 75 text

新規ユーザーはCodeCommitが利用できない

Slide 76

Slide 76 text

2024年７月25日 新規利用の受付停止 新規ユーザーはCodeCommitが利用できない

Slide 77

Slide 77 text

代替として、まずはGitHubをリポジトリとしてCI/CDパイプラインを検討

Slide 78

Slide 78 text

代替として、まずはGitHubをリポジトリとしてCI/CDパイプラインを検討

Slide 79

Slide 79 text

まとめ

Slide 80

Slide 80 text

時間軸 まとめ 2024年 10月 どのような AWSアーキテクチャを主軸にしながら 改めて読者のみなさまに価値を届けるか？ 2021年 10月

Slide 81

Slide 81 text

時間軸 まとめ（３つの観点から考察） 2024年 10月 ECS/Fargateをとりまく アーキテクチャデザイン Well-Architected Framework再考 サービス新規利用停止と 終了を踏まえて 2021年 10月 先人が築いた良質な設計を理解す ることで、設計の最適解を模索 日々のアップデートとW-A軸を 照らし合わせることで、 より網羅的な設計を探索 潮流にあわせて、自分たちの アーキテクチャを持続可能なもの にしていく必要

Slide 82

Slide 82 text

時間軸 まとめ（出版当初のアーキテクチャ） 2024年 10月 2021年 10月

Slide 83

Slide 83 text

時間軸 まとめ（現在のアーキテクチャ） 2024年 10月 2021年 10月

Slide 84

Slide 84 text

さいごに

Slide 85

Slide 85 text

AWSコンテナ本出版から3 年経った今、もし改めて執 筆し直すなら…

Slide 86

Slide 86 text

AWSコンテナ本出版から3 年経った今、もし改めて執 筆し直すなら…します！ 出版社さま(SB Creativeさま)側の企画は承認済み。 2025年度の出版を目標に、皆さまに新たな価値を 届けるべく、鋭意改訂版を執筆中です！ Stay tuned! ほぼ全刷新

Slide 87

Slide 87 text

ご清聴ありがとうございました。