みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 11 月 18 日 (水) に、Amazon Quick をデータ活用の観点から紹介するイベント「 Amazon Quick で進めるデータ活用の次の一手 — 活用企業・パートナー・AWS社員による事例紹介 」を開催します。最新アップデートの紹介に加えて、国分グループ本社様、LINEヤフー様、タキヒヨー様に活用事例を、シーイーシー様、電通デジタル様、ジェーエムエーシステムズ様に導入支援の事例をご紹介いただきます。AWS ジャパン社内の財務部門と法務部門での活用例もお話しします。会場は東京・麻布台ヒルズで、オンラインでも参加できます (配信はスライドと音声のみ)。11 月 20 日 (金) には 大阪会場 でも同じ内容で開催します。定員がありますので、気になる方はお早めにお申し込みください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年10月26日週の主要なアップデート 10/26(月) AWS Glue Data Catalog が Apache Iceberg REST Catalog API で OAuth をサポート AWS Glue Data Catalog の Apache Iceberg REST Catalog (IRC) エンドポイントが、従来の AWS Signature Version 4 (SigV4) に加えて、AWS Sign-In を利用した OAuth 2.0 ベアラートークン認証に対応しました。OAuth 2.0 Token Exchange (RFC 8693) により、パートナーのエンドユーザーの OIDC トークンを有効期限 1 時間以内の Glue スコープのアクセストークンに交換し、IRC リクエストに使用できます。AWS 認証情報を外部に配布することなく、サードパーティの分析プラットフォームや外部クエリエンジンに Iceberg テーブルへのフェデレーテッドアクセスを許可できます。アクセス制御は引き続き AWS IAM と AWS Lake Formation の権限で統制されます。AWS Glue と Lake Formation が利用可能なすべてのリージョンで利用できます。 AWS Key Management Service がポスト量子鍵カプセル化の ML-KEM をサポート AWS KMS が、NIST FIPS 203 で標準化されたポスト量子暗号の鍵カプセル化メカニズム ML-KEM に対応しました。ML_KEM_512、ML_KEM_768、ML_KEM_1024 の 3 つのキースペックで KMS キーを作成し、新 API の Encapsulate / Decapsulate で 32 バイトの共有シークレットを確立できます。秘密鍵は FIPS 140-3 Level 3 認定の HSM 内で保護されます。従来の RSA 鍵配送や DH / ECDH 鍵合意が量子計算機で破られる「harvest now, decrypt later」脅威への対策として、アプリケーション層の鍵確立を耐量子化できます。UAE リージョン、バーレーンリージョン、中国リージョンを除く KMS 提供の全リージョンで利用できます。 AWS IAM Identity Center がクロスリージョンの trusted identity propagation をサポート AWS IAM Identity Center の trusted identity propagation (信頼されたアイデンティティ伝播) が、複数の AWS リージョンをまたいだ ID コンテキストの伝播に対応しました。従来は、ユーザーの ID 情報を利用するすべての AWS サービスが同一リージョンに存在する必要がありましたが、今回の対応により、別リージョンのサービスに対してもユーザー個人とグループ所属に基づくアクセス制御と監査ができるようになりました。利用にはマルチリージョン構成の IAM Identity Center インスタンスとマルチリージョンのカスタマーマネージド KMS キーが必要です。追加料金はなく、IAM Identity Center が利用可能なすべてのリージョンで利用できます。 OpenAI GPT-6.1 Terra が Amazon Bedrock で一般提供開始 OpenAI の GPT-6.1 Terra が Amazon Bedrock で一般提供を開始しました。GPT-6.1 Terra は GPT-6 ファミリーの Terra ライン (バランス型) の最新モデルで、視覚推論、コンピュータ操作、事実性と文章品質の改善が特徴です。OpenAI の Agents’ Last Exam 評価では GPT-5.6 Terra を 15 ポイント上回って GPT-6 Astra と同等のスコアを記録し、タスクの完了は GPT-6 Astra や GPT-6.1 Sol の 3 倍以上速くなっています。トークン価格は GPT-6.1 Sol および GPT-5.6 Terra と比べて入出力ともに 50% 以上低く設定されており、日常的なワークロードに向けて性能・速度・コストのバランスを取ったモデルです。コンテキストウィンドウは最大 100 万入力トークンで、テキストと画像の入力に対応します。Amazon Bedrock API からの直接呼び出しに加え、ChatGPT Work や Codex のバックエンドとして Bedrock 上の本モデルを指定できます。 10/27(火) Amazon ECS が NVIDIA Multi-Process Service (MPS) による GPU 共有をサポート Amazon ECS が NVIDIA Multi-Process Service (MPS) による GPU 共有に対応し、1 つの NVIDIA GPU 上で複数の ECS タスクを同時に実行できるようになりました。タスク定義のコンテナ定義でコンテナごとの GPU メモリ量 (必須) と GPU コンピュート使用率の上限 (任意) を指定するだけで、ECS が空きメモリのある GPU にタスクを配置し、MPS デーモンの起動・管理も ECS が行います。アプリケーションコードの変更は不要です。ECS Managed Instances と ECS on EC2 の両方で利用でき、Managed Instances では MPS デーモンの障害を検知すると自動でインスタンスを置き換えます。小規模モデル推論やマルチモデルサービングなど GPU を使い切らないワークロードで、GPU 利用率の向上とインフラコストの削減につながります。すべての AWS 商用リージョンと AWS GovCloud (US) リージョンで利用できます。 10/28(水) AWS Backup の restore testing が Amazon Redshift をサポート AWS Backup の restore testing (復元テスト) 機能が Amazon Redshift に対応しました。restore testing は、バックアップからの復元テストをスケジュールに沿って自動実行し、復元が成功するかの確認と復元所要時間の計測を行う機能です。これまで EC2、EBS、RDS、Aurora、S3 などが対象でしたが、今回 Amazon Redshift のプロビジョンドクラスターを復元テスト計画に含められるようになりました。復元ジョブの完了時間を RTO (目標復旧時間) と突き合わせて評価できるため、データウェアハウスの災害対策や事業継続に関する規制・コンプライアンス要件への対応に使えます。 Amazon EKS Auto Mode が Kubernetes Gateway API をサポート Amazon EKS Auto Mode が Kubernetes Gateway API に対応しました。Gateway と HTTPRoute などの標準リソースを定義するだけで、EKS Auto Mode が ALB (L7) または NLB (L4) を自動的にプロビジョニング・管理します。これまで必要だった AWS Load Balancer Controller のインストールや運用は不要です。HTTP/gRPC ルーティング、名前空間をまたぐルーティング、重み付けトラフィック分割、ヘッダーベースルーティング、ACM による TLS 証明書の自動検出に対応します。既存の Ingress や Service type LoadBalancer はそのまま併用でき、追加料金なしで EKS Auto Mode に含まれます (ALB/NLB 自体の標準料金は別途発生します)。 Amazon ECS Managed Instances がインスタンス間統合と Spot 統合を追加 Amazon ECS Managed Instances のインフラ最適化に、cross-instance consolidation (インスタンス間統合) と Spot consolidation (Spot 統合) の 2 つの機能が追加されました。従来は各インスタンスを単独で評価して置き換えていましたが、今回から複数の低使用率インスタンスにまたがるタスクを同時に評価し、より少ない台数に再配置できます。AWS のテストでは 19 台のフリートが 13 台に減り、CPU 使用率は 42% から 91% に、メモリ使用率は 41% から 88% に上がりました。追加料金はなく、全リージョンの既存および新規の capacity provider に自動で適用されます。 Quick がエージェントアクションのスマート承認に対応 Amazon Quick に、エージェントが提案するアクションを審査するレイヤーであるスマート承認 (smart approvals) が追加されました。classifier と呼ばれる独立した審査モデルが、各アクションをユーザーの依頼内容と照合し、定型的なアクションは自動承認し、影響の大きいアクションはユーザーの確認に回します。既存の権限設定が常に優先され、スマート承認が新しいアクセス権を付与することはありません。全ユーザーでデフォルト有効となっており、管理者はカスタム権限プロファイルで利用可否を制御できます。自動承認と設定変更はすべて AWS CloudTrail に記録されます。 次世代 Amazon OpenSearch Serverless の時系列コレクションを発表 次世代 (NextGen) Amazon OpenSearch Serverless で time series collections (時系列コレクション) が利用可能になりました。クラスターの管理なしでログ、メトリクス、トレース、イベントデータを取り込み・保存・分析できます。従来の hot ストレージに加えて低コストの warm ストレージ階層が追加され、hot に置く期間 (1 日〜10 年) を指定するだけで古いデータが自動的に warm へ移行します。1 コレクションあたり最大 100 TB の hot ストレージに対応し、Classic コレクションでは未対応だったアラートと異常検知も使えるようになりました。OpenSearch Serverless が利用可能なすべてのリージョンで提供されています。 AWS Lambda が Lambda Managed Instances で Seekable OCI (SOCI) による遅延読み込みをサポート AWS Lambda は、Lambda Managed Instances 上で動作する OCI コンテナイメージ形式の Event Functions に対して、Seekable OCI (SOCI) による遅延読み込みをサポートしました。イメージ全体を事前ダウンロードする代わりに、実行環境の起動段階ごとに必要なファイルだけをオンデマンドで取得するため、コンテナ起動時間を最大 70% 短縮できます。数 GB 規模のイメージを使うデータ処理パイプラインや ML フレームワーク同梱アプリケーションで、スケールアウト時やバージョン公開時の起動遅延を抑えられます。利用方法は、イメージの SOCI インデックスを作成して Amazon ECR にプッシュし、関数のイメージ URI を SOCI インデックス付きタグに向けるだけで、追加の設定は不要です。Lambda Managed Instances が利用可能なすべての AWS 商用リージョンで利用できます。 10/29(木) Amazon Redshift が手動操作不要の自動クロスリージョンバックアップを発表 Amazon Redshift に自動クロスリージョンスナップショットコピー機能が追加されました。プロビジョンドクラスターおよび Serverless ワークグループの最新スナップショットを、指定した宛先リージョンへ継続的かつ増分的に自動コピーします。従来のクロスリージョンスナップショットコピーと異なり、ソース側のスナップショットスケジュールに依存せず、常にシステム上の最新スナップショットがコピー対象になります。これにより、リージョン障害などの予期しない停止が発生した際に、手動でコピーを開始する必要がなくなります。AWS 商用リージョンおよび GovCloud (US) の全リージョンで利用できます。 Amazon Aurora がポスト量子 TLS 鍵交換をサポート Amazon Aurora PostgreSQL 互換エディションが、ポスト量子 TLS (PQ-TLS) 鍵交換に対応しました。Aurora PostgreSQL 18 以降で ssl_groups クラスターパラメータを変更できるようになり、NIST FIPS 203 で標準化された ML-KEM-768 と古典暗号を組み合わせたハイブリッド鍵交換グループ (X25519MLKEM768、SecP256r1MLKEM768) を選択できます。これにより、暗号化通信を今記録しておき将来の量子コンピュータで復号する Harvest Now, Decrypt Later 攻撃から、転送中のデータを保護できます。パラメータは動的に適用され、再起動は不要です。 Amazon RDS for Oracle および SQL Server が追加ストレージボリュームでのストレージオートスケーリングをサポート Amazon RDS for Oracle と Amazon RDS for SQL Server の追加ストレージボリューム (additional storage volumes) で、RDS ストレージオートスケーリングが利用できるようになりました。追加ストレージボリュームは最大 3 つまで追加でき、プライマリボリュームと合わせて 1 インスタンスあたり 256 TiB まで拡張できる機能です。これまではプライマリボリュームのみオートスケーリングに対応しており、追加ボリュームは需要を見込んで手動でプロビジョニングする必要がありました。今回のアップデートにより、ボリュームごとに最大ストレージしきい値を設定するだけで、RDS が使用量を監視して自動で容量を拡張します。追加料金はなく、ダウンタイムも発生しません。全ての商用リージョンと AWS GovCloud (US) リージョンで利用できます。 10/30(金) Amazon SageMaker AI 推論がリアルタイムエンドポイントで GPU パーティショニングをサポート Amazon SageMaker AI のリアルタイム推論が、NVIDIA Multi-Instance GPU (MIG) 技術による GPU パーティショニングに対応しました。1 つの GPU を最大 7 個の独立したパーティションに分割し、それぞれに別のモデルを配置できます。各パーティションは専用のコンピュートスライスと GPU メモリを持つため、同居するモデル同士が性能に干渉しません。これまで GPU 全体を占有していた埋め込みモデルや分類器などの小〜中規模モデルを 1 つの GPU に集約でき、インスタンスコストを削減できます。P4d、P5、G7、G7e インスタンスで利用でき、東京リージョンを含む 7 リージョンで提供されます。 AWS WAF が Amazon CloudFront ディストリビューション向けの自動 SDK 統合を発表 AWS WAF は、CloudFront ディストリビューション向けに AWS WAF JavaScript SDK の自動統合 (automatic SDK integration) を発表しました。この機能を有効にすると、CloudFront がエッジで配信する HTML に SDK のスクリプトタグを自動挿入するため、アプリケーションコード、ビルドプロセス、デプロイの変更が不要になります。対象は Bot Control (targeted 検査レベル)、Fraud Control ATP、Fraud Control ACFP の 3 つのマネージドルールグループで、これらが必要とするクライアントサイドシグナルの収集を自動化します。追加料金はありません。従来は全ページへのスクリプトタグの手動追加と維持が必要で、タグの入れ忘れによる誤検知が起きやすい構成でしたが、この作業が不要になります。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です。

こんにちは。QAコンサルタントのテストのひろさんです。 本記事では、テスト進捗自体は順調なものの、現場の役割にミスマッチが生じていたプロジェクトの改善事例を紹介します。当時テストPMだった私が、JSTQB AL-TM v3.0Jシラバスなどの知見を活用し、どのように体制再構築と再発防止に取り組んだのかをお伝えします。 現場の運用に課題を感じている方の気づきや、参考になれば幸いです。 対象プロジェクトの概要 当時のテストプロジェクトの基本情報は以下の通りです。 テストレベル: システムテスト 期間: 2か月 テスト環境: オンサイト プロジェクト計画: システムテストの後に、機能追加に対するシステムテストを計画 チーム構成: PM（私）1名、テストリーダー（TL）1名、ビジネスパートナー（BP）リーダー1名、BPテスター3名 役割分担: BPリーダー: 日々の進捗報告（TL宛）、QA・タスクリストの更新、ハンズオンでのテスト実施。進捗フォーマットやステータス管理手法はトレーニング済み。 BPテスター: テスト実行全般。 TL: 進捗管理、探索的テスト実施、機能追加のテスト設計、QA・タスクリストのチェックや回答。 PM: 複数テストプロジェクトの統括。 立ち上げ時、TLの業務負荷が潜在的なリスクとして見受けられました。しかし、以下の理由からそのような計画で進行することを決定しました。 システムテストの一次報告はBPリーダーが実施すること 機能追加に伴うテスト設計の規模が限定的であること 探索的テストの工数や時期を調整可能であること 具体的には、最初の2週間は進捗管理とQA対応に注力し、3週間目から機能追加のテスト設計および探索的テストを開始するスケジュールを設定しました。 進捗の裏側に生じていた問題 システムテスト開始後、BPリーダーからは予定を前倒しで進めていると報告を受けていました。しかし、詳細を確認していくと以下の状況でした。 テスト進捗は専用のツールで算出するのですが、私が改めて算出し直した進捗数と、実際に報告されている進捗数が異なっていました。また、課題管理表の内容とTLから報告されている内容が一致していなかったり、課題管理表そのものに記載が漏れている等の状況に気づきました。 起きていたことをまとめると以下の状況です。 実際の進捗数と報告された進捗数の不一致 タスク管理表と実際の作業状況のズレ、および記載漏れ TLはBPリーダーへ是正を何度か依頼しましたが改善されず、事実確認などの対応に追われることになります。結果としてTLの工数が圧迫され、予定していた機能追加のテスト設計や探索的テストに入れない状況が発生しました。 この時、現場では以下のような心理的・運用的課題が生じていたのです。 TLの心理: テスト設計も探索テストも進まず、進捗もまとまらないという状況から、自身の評価への懸念が生まれ、PMに相談できず一人で抱え込んでいた。 BPリーダーの心理: 上手く進捗報告ができていないという認識はあるものの、具体的な改善方法が見出せず困惑していた。 双方ともに悩んでいる状態でした。ここで少し私の考えを挟むと、悩むとは問題を認識して試行錯誤しているが出口が見えない状態であり、考えるとはゴールが見えていて、そこに向かっていく状態だと捉えています。当時の現場は、まさに前者の出口が見えない状態に陥っていました。 さらに、この是正がうまくいかない日々が続いたことで、テストリーダーとBPチームの間にも徐々に不穏な空気が流れ始め、コミュニケーションが膠着する二次災害も起き始めていました。 1. 捉え方の転換：個人の問題ではなく構造の問題 この状況に直面した際、私は起きている問題を個人の資質や特性に起因させないことが重要であると考えました。 一見すると報告が不正確なリーダー、抱え込んでしまうTLのスキル問題に見えますが、本質は違います。これは、現場の状況変化に対してプロジェクトの初期枠組みが適合しなくなったことによる構造的な問題であると捉えました。 ここでベースにしたのは、人を責めず、仕組みを改善するという方針です。書籍「スクラム」などにある「プレイヤーを憎むな、ゲームを憎め」という言葉の通り、個人を責めても本質的な解決にはならないと私は考えています。 JSTQB AL-TM v3.0J には、以下のような記述があります。 「テストチームは、プロジェクト開始時に、必要なスキルをすべて持っているとは限らない。完璧な人材がそろうとは限らないが、強力なチームであれば、個人の長所と短所のバランスを取ることができる。」 最初から完璧な人材がそろうチームは難しいことがあるため、個人のせいにせず、仕組みや役割によってバランスを取るという考え方から、システムテストの進行途中で以下のように役割と環境の再配置を行いました。 役割の再定義 BPリーダー: 進捗報告・管理業務から一旦離し、ハンズオンテストの割り当てを80%に増加。タスク管理の不備がスキルの問題なのか業務過多によるものなのかを切り分けるとともに、テスト実行の推進に集中するようにしました。残りの20%はPMやメンバーとのコミュニケーションに充てる割合に変更しました。 テストリーダー（TL）: テスト管理やBPチームとのコミュニケーションをタスクから切り離し、本来のミッションである探索的テストの実施と機能追加のテスト設計」に専念できる工数を確保しました。 PM（私）: このシステムテストの進捗管理を巻き取りました。BPリーダーとのコミュニケーションは、時間を固定して1日2回（各10分）の状況確認を実施する運用へ変更しました。 物理環境の変更（座席位置の調整） また、TLとBPチームの間で関係性の悪化（コミュニケーションの膠着）が見られたため、オフィスの座席配置を変更して物理的な距離を置きました。これにより、TLによるBPチームへの細かな確認や介入を構造的に抑制し、TLもBPチームも自分たちのタスクに集中できる環境を整備しました。 ガバナンスの再構築 正確な情報を把握するため、これまでチャットベースで済ませていた報告を「対面での同期」に切り替えました。これは指示命令を強化するためではなく、事実（ファクト）と報告の同期を目的としたものです。情報の透明性を確保することで、プロジェクトの正確な現状がステークホルダーやチーム全体に共有される仕組みへと変更しました。 2. 心理的安全性と規律の両立：1on1における対話 役割変更と並行して、TLとの1on1を実施しました。目的は、心理的安全性を確保した上で役割変更の背景を納得してもらい、機能追加テスト設計、探索的テストに集中してもらうことです。1on1では、特に以下の3つの軸を意識して対話を行いました。 評価の切り分け（安心感の醸成）: 今回の介入はあくまで、体制上の判断による役割の変更であり、TL個人の評価を下げるものではないことを明言しました。テスト期間中であり、最終的な品質やゴールに対する結果はまだ出ていないためです。 ティーチングの選択: 通常であれば自律的な成長を促すコーチングを採用しますが、今回は納期が迫る緊急時であったため、私のやり方を直接伝えるティーチングへと戦略的にシフトしました。山本五十六の「やってみせ、言って聞かせ、させてみせ、ほめてやらねば、人は育たず」の方針のもと、並走しながらサポートしました。 コミュニケーションの原則（アサーション）: 強い言葉で行動を縛るのではなく、仕組みで解決を図る姿勢（アサーションの原則）を大切にしたい旨をTLに伝え、目線を合わせました。 3. 再発防止：根本原因の特定と仕組みのアップデート プロジェクト完了後、次フェーズである機能追加テストに向けて、今回の問題の根本原因の特定と仕組みのアップデートを行いました。 根本原因：正しいデータが報告に繋がらない集計・出力構造 そもそも、なぜ進捗報告と実態の乖離が起きていたのか。仕組みとしてExcel上で予定と実績が10%以上乖離するとセルが赤字になるというアラートのルール自体は存在しており、Excel内の関数やシステム側の元データも正常でした。 しかし、最終的に算出されたデータを、報告用にアウトプットする（テキスト化する）段階で人為的なミスが発生していたことが根本原因でした。 当時の集計・報告フローは以下の通りです。 テスト管理システムから正しい実績データをCSVでダウンロードする 集計用のExcelへコピー＆ペーストする（Excel上の関数・アラート自体は正常に機能） Excelで算出された数値を、手作業で報告用のテキストに書き起こす（ここで転記ミスが発生） 最終的な報告テキストを作成するまでに手作業のプロセスが多く、結果としてExcel上ではアラート（赤字）が出ていても、報告段階でそれが消えてしまうという、人為的ミスを誘発しやすい構造になっていました。BPリーダー個人を責めるのではなく、ミスが起きる構造を変える必要がありました。 対策：集計・出力の自動化 手作業によるリスクを排除するため、CSVダウンロード後のデータ集約から、Excelでの集計、そして最終的な「報告用テキストの出力」までをワンクリックで行うVBAマクロを導入しました。 これにより、データの信頼性を担保した上で、PMやステークホルダーが日々のモニタリングで客観的な事実（定量データ）をそのまま受け取り、早期に異常（アラート）を検知できる仕組みへとアップデートしました。 4. 再発防止の効果：定量的・定性的アプローチ アップデートした仕組みの効果を現場の感覚で終わらせないために、JSTQB AL-TM v3.0Jのシラバスに記されている以下の格言を指針としました。 「マネジメントには『測定できるものは達成できる』という格言がある。同様に、測定されないものは、無視されやすいので、達成されることはないだろう。したがって、テストを含め、どのような取り組みに対しても、適切なメトリクスを確立することが重要である。」 この考えに基づき、定量的なメトリクス評価と定性的なアプローチ（心理的安全性の確保）の両面から効果を測定しました。 ① 定量的なアプローチ プロジェクトメトリクス: テスト実行数、実行率、ステータス（OK/NG/Block）の推移。自動集計化により、10%の乖離アラートが正しく機能するようになり、進捗の透明性が確保された。 プロダクトメトリクス: BPリーダーのテスト比率を上げたことによる進捗の加速、TLの探索的テストによる、欠陥検出数と修正数の推移。想定していた計画値と実績を比較することで、品質リスクの低減に繋がった。 プロセスメトリクス: 集計作業工数そのものが削減されたことによる相乗効果で、チーム全体の生産性が向上した。 ② 定性的なアプローチ（1on1による内面サポート） 一方で、数字には表すことが出来ないメンバーの悩みや心理的状況は、定性的にしか捉えることができません。ここでは1on1などの直接的な対話によるサポートが不可欠です。 ちなみに、JSTQB AL-TM v3.0Jのシラバスには「方法論的、社会的、個人の能力はテストに特化したものではないため、専門的能力の開発に重点を置く」といった旨も述べられています。つまり、1on1やアサーティブなコミュニケーションといったスキルもまた、マネジメント知識として意識的な習得やトレーニングが必要な領域です。トレーニングや考え方などについては「ヤフーの1on1」「成長マインドセット」などの書籍を参考にしています。 1on1を継続した結果、TLが問題を一人で抱え込まずに早めのアラートを出せる関係性が構築され、BPリーダーも何に困っているかを素直に共有してくれる環境へと変化しました。 おわりに 今回の取り組みを通じて、データの信頼性とアラートの定量化、心理的安全性の確保によって、仕事の側面と人の側面をマネジメントすることの重要さを実感しました。 人が間違えるのは、仕組みに問題があると捉えて、変化の激しいテストプロジェクトを計画したゴールへ導くことが、マネジメントの本質ではないでしょうか。 この記事が、現場の体制構築や運用に悩むエンジニア・マネージャーの皆さまにとって、少しでも新しい視点や気づきのきっかけになれば幸いです。 最後までお読みいただき、ありがとうございました。 （参考文献） JSTQB JSTQB-Syllabus.Advanced_TM_VersionV3.0.J02 スクラム 仕事が4倍速くなる世界標準のチーム戦術（ジェフサザーランド 著、石垣 賀子 訳） ヤフーの1on1 部下を成長させるコミュニケーションの技法（本間 浩輔 著） 成長マインドセット 心のブレーキの外し方（吉田 行宏 著） The post 心理的安全性とガバナンスを両立させるテストチームの改善事例 first appeared on Sqripts .

はじめに：AIが賢くなるほど、現場は楽になる？ ! この記事の要点 AIレビューを用いることで設計書におけるレビュワーの作業が体感1時間程度から数分〜数十分に でも、レビュワーがしていた「判断」は、設計書を書いたエンジニアに移っただけだった 「判断」にはエネルギーが必要、それは誰がコストを支払うべき？ 役割整理から今後のSIerのあるべき姿を想像する ! この記事は商用システム開発での取り組みをもとにしています。構成や具体例は一般化しており、特定の顧客、クラウドサービス、システムの仕様を示すものではありません。 また、効果の数値もぼかして書いているため、定性的な点はご容赦くださ