AWS PrivateLinkの使い方と注意点 ~VPCピアリングとの使い分け~

AWS PrivateLinkの使い方と注意点 ~VPCピアリングとの使い分け~

プラットフォーム技術部の小林です。 本記事ではVPCサービスとして提供されているPrivateLinkについて、2017年11月のリリース以降エンハンスされた機能も含めた現行機能の整理と、PrivateLinkの使いどころや注意点などをまとめます。 最後に、実際にPrivateLinkを使ってプライベートサブネットからインターネットを経由せずにKinesisに対してAPIコールを実行する手順を掲載します。 PrivateLinkって何? PrivateLinkとは「AWSへのAPIアクセスをインターネットを経由せずに行えるインターフェースタイプのVPCエンドポイント」です。 PrivateLinkを使うことでインターネットに出る必要がなくなるため「IGW、NATデバイス、VPNコネクション、パブリックIP」の導入・設定が不要になり、環境設計が必要なコンポーネントを減らすことができます。また、セキュリティ要件の厳しいシステムやクローズドな環境での稼動が必須となるシステムをAWS上に構築する際に役立ちます。 そもそもVPCエンドポイントって何? さきほどのPrivateLinkの説明の中でPrivateLinkはインターフェースタイプのVPCエンドポイントと書きましたが、そもそもVPCエンドポイントとは何でしょうか。 VPCエンドポイントとは、VPCと他のサービス間の通信を可能にするVPCコンポーネントで、その実態は仮想デバイスです。VPCエンドポイントをVPCに作成することで、VPC内のインスタンスとVPC外のサービスとで通信ができるようになります。(詳細はVPCエンドポイントのガイドを参照してください。) VPCエンドポイントは下記の2つのタイプが提供されています。インターフェースタイプPrivateLinkと呼んでいる 実態はプライベートアドレスをもつENIゲートウェイタイプルートテーブルで送信先に対するターゲットとして指定する二つのタイプのVPCエンドポイントを使用した構成例を下図に示します。タイプによって、インスタンスとサービス間での通信経路が異なります。 ゲートウェイタイプを使用する場合はルーティング設定が必要です。図に示したルートテーブルにあるように、Destinationとして「使用するサービスのエンドポイント(この場合は東京リージョンのS3のpl-id(プレフィックスリストID))」、Targetとして「作成したVPCエンドポイントのID(vpce-id)」を指定します。このルートを設定することでVPC内部からVPC外のサービスへの通信ができるようになります。  タイプによる違いを整理:ゲートウェイとインターフェース ゲートウェイタイプとインターフェースタイプで異なる制限を下表に整理します。 [table id=12 responsive="desktop"/] カテゴリとサービス一覧 タイプによって利用できるカテゴリとサービスが異なりますので、それぞれ利用できるものを整理します。 カテゴリ一覧 まずはカテゴリの一覧です。2018年5月時点で利用できるカテゴリは下表のとおりです。 [table id=13 responsive="desktop"/] サービス一覧 つぎは各カテゴリで利用可能なサービスについて整理します。 AWSサービス まず1つめの「AWSサービス」カテゴリでは、AWSプリンシパルなサービスが提供するエンドポイントを選択できます。 下表に、現時点で提供されているサービスと対応するエンドポイントタイプ、エンドポイントをまとめています。 [table id=14 responsive="desktop"/] ※"amazon"、"aws"という語は省略してサービス名順に並べています 昨年11月のre:invent 2017で紹介されたサービスや、2018年になって新たに追加されたサービスも記載しています。いずれも東京リージョンで利用可能なサービスです。VPCエンドポイントに対応するサービスはどんどん追加されていきますので、VPCエンドポイントを使用する際にはその時点でどのサービスが利用可能なのかを確認するようにしましょう。 なお、公式のVPCエンドポイントのガイドに掲載されているサービス一覧表は最新の状態にアップデートされていないため、2018年5月時点ではこちらの表に記載の内容が正しいです。ご注意ください。 独自サービス 2つめは「独自サービス(VPCエンドポイントサービス)」です。 マネジメントコンソールでは「サービスを名前で検索」というカテゴリで表示されています。インターフェイスタイプのエンドポイントが利用可能なカテゴリです。 独自に作成したサービスをVPCエンドポイントサービスとして公開し、AWSネットワークに閉じて利用することができます。利用するにはNLBの作成が必須です。 独自サービスを利用するために図に示したように3つのステップで設定していきます。①独自アプリケーションの前段にNLBを配置して、②NLBを指定してVPCエンドポイントサービスを作成します(例:com.amazonaws.vpce.ap-northeast-1.vpce-svc-xxxxxxxxx)。③そのVPCエンドポイントサービスに接続するインターフェースVPCエンドポイントを作成します。エンドポイントサービスの作成にはNLBの関連付けが必須となりますのでご注意ください。  図に示したように、PrivateLinkとNLBのVPCエンドポイントサービスを使用することで異なるVPC間の通信が可能になります。となると、VPCピアリングとの使い分けについても気になると思いますがそちらについては「VPCピアリングとの違い」の節でまとめていますので参考にしてください。 マーケットプレイスサービス 3つめはマーケットプレイスサービスです。 マネジメントコンソールでは「ご使用のAWSマーケットプレイスサービス」として表示されています。このカテゴリは2017年11月に追加されたカテゴリです。AWSマーケットプレイスが提供するサービスを利用できます。対応するタイプはインターフェイスタイプのみです。マーケットプレイスでSaaSとして提供されているサービスに対してVPCエンドポイントを作成することで、インターネットを介さずにSaaSを利用することができます。 [blogcard url="https://aws.amazon.com/jp/about-aws/whats-new/2017/11/aws-privatelink-on-aws-marketplace-now-available/"] 2018年5月時点で利用可能なVPCエンドポイント対応のマーケットプレイスサービスは下表のとおりです。 [table id=15 responsive="desktop"/] セキュリティ関連のSaaSが利用可能になっているようです。こちらも随時対応サービスが拡張されていくと思いますので、VPCエンドポイントを使用したSaaS利用を検討している方はチェックしておきましょう! VPCピアリングとの違い 独自アプリケーションのVPCエンドポイントサービスを作成することができるようになり、異なるVPC間での通信が可能になりました。「異なるVPC間での通信」という観点で、PrivateLink機能を利用するべきか、VPCピアリングを利用するべきかを検討する際の参考情報として下表に機能の違いを整理しました。 [table id=16 responsive="desktop"/] ユースケース 上記の比較を受けて、PrivateLinkはどのような状況で使用するべきでしょうか。 独自のサービスにクローズドな環境で通信をしたい場合はPrivateLinkが適しているかもしれません。また、そのサービスがマーケットプレイスでエンドポイントサービスとして提供されているものである場合はPrivateLinkを選択しましょう。 Direct Connect接続経由のエッジツーエッジルーティングを実現したい場合は、VPCピアリング接続では実現できないのでPrivarteLinkを選択する必要があります。 VPCのCIDRブロックが重複している場合も、VPCピアリング接続での実現ができないのでPrivateLinkを使用します。すでに存在するVPC同士を接続する場合は、CIDRブロックを確認してVPCピアリング接続が可能かどうかを確認しましょう。 現在のネットワーク構成やセキュリティ要件、通信要件からはVPCピアリングとPrivateLinkのどちらを使用しても大差ないという状況であれば、設計・構築・運用の作業の大変さ、という観点でどちらがいいかを検討するのもよいでしょう。 VPCピアリングを使用する場合は、ルートテーブル/NACL/SGでアクセスを限定していくので詳細な制御ができる反面、設計や構築作業、構築後のメンテナンスが複雑になってしまうかもしれません。PrivateLinkを使用することで通信経路が可視化され構成図がシンプルになる可能性もあります。現行の運用方法に即して選択することをおすすめします。 PrivateLinkを使ってみる 実際にPrivateLinkを使ってみます。今回は下図のような簡易な構成を作成していきます。 プライベートサブネット内のインスタンスからインターネットを経由しないでKinesisのエンドポイントにAPIアクセスをしてみます。PrivateLinkの作成 VPCサービスから「エンドポイント > エンドポイントの作成」と選択します。サービスカテゴリは「AWSサービス」を選択します。 表示されたサービス名の一覧から「Kinesis-streams」サービスを選択します。(東京リージョンで作業をしているので、com.amazonaws.ap-northeast-1.kinesis-streamsと表示されています)つづいて、VPC、AZ、プライベートDNS設定、セキュリティグループを選択していきます。 VPCをプルダウンから選択すると利用可能なAZとサブネットが表示されるので、VPCエンドポイントを作成するサブネットを選択します。プライベートサブネット内のインスタンスから、AWS CLI によってVPCエンドポイントに対してHTTPS で
【わたしに♥おまかせ Zabbix⑥】Zabbixのデータベースについて – トリガー編

【わたしに♥おまかせ Zabbix⑥】Zabbixのデータベースについて – トリガー編

本連載では「まるごとおまかせZabbix」をより便利で有用なサービスとするために日々奮闘中の齊藤(沙)がアークシステム ザビ家の一員として、Zabbix に関する日々の取り組みやナレッジをご紹介していきます!【わたしに♥おまかせ Zabbix①】Zabbixの構成要素とパラメーターについて 【わたしに♥おまかせ Zabbix②】Zabbixサーバーと内部プロセスについて 【わたしに♥おまかせ Zabbix 号外】Interop Tokyo 2017 Zabbixブースに出展! 【わたしに♥おまかせ Zabbix③】Zabbixの内部プロセスについて-続き 【わたしに♥おまかせ Zabbix④】Zabbixのデータベースについて 【わたしに♥おまかせ Zabbix⑤】Zabbixのデータベースについて – アイテム編 【わたしに♥おまかせ Zabbix⑥】Zabbixのデータベースについて – トリガー編(本記事)本サービスの詳細や、Zabbixを活用したソリューションにご興味をお持ちの方がいらっしゃいましたら サービス紹介ページ からお気軽にお問合わせ下さい。こんにちは!プラットフォーム技術部の齊藤(沙)です。 前回はZabbixが監視設定や履歴データを保管するデータベースの中でも監視項目であるアイテムに関連するテーブルについて確認しました。今回は監視閾値であるトリガーに関連するテーブルについて確認していきます。 Zabbixを知ろう -Zabbixのデータベースについて –
MR花見~HoloLensで花見をしよう~

MR花見~HoloLensで花見をしよう~

こんにちは。ソリューション開発部 HoloLens分科会の中川です。 先生、花見が、、、したいです。 季節が巡るのはホントに早いですね。 ふと思い立って花見をしようとしたら、なんととっくに桜は散っていたんですよ。 満開の時は何となく、いつでもできるから、という気になって結局やらず。 桜が散ってから花見がしたくなる気持ち、わかりますよね? しかし2018年になった今、我々にはMR(Mixed Reality)という技術があるではないですか。 肌寒い中で無理して冷たいビールを飲むなんて時代遅れですよ。 外が寒ければ屋内で花見すればいいじゃない。 桜が散ってしまったなら、また咲かせればいいじゃない。   そう、時代はMR花見だ! HoloLensで花見をしよう!!   MR花見を作るのだ。 というわけで、MR花見アプリを作りましょう。 終業時刻までに完成させて、定時になると同時に花見をしたいので急いで作らなければなりません。 基本は過去の記事「MixedRealityToolkit-Unityを使ったHoloLens開発クイックスタート」の手順そのままです。 円柱の代わりに桜の木のCGを用意すればいいだけです。 慣れれば5分もかからない作業です。 桜の木のCGが手元になかったので、Freeの木のAssetをダウンロードし、緑の葉の部分を桜色に塗りつぶして代用することにしました。  普通の緑の木  葉をピンクにするだけで、桜っぽく見えてくる不思議。  MRならサイズは自由なので、机の上に桜を咲かせることもできます。  無事に花見ができました。 キャプチャした画像だと桜の存在感が薄いですが、HoloLensを通してみるともっときれいに見えます。 しかしHoloLensをかけているのは私だけなので、他のメンバーはただ単にオフィスで一杯やっているだけですが。   MRと季節行事は相性がいい。 VR花見だと手元のビールが見えないので困りますが、MRなら普段通りに花見をすることができます。 現実とヴァーチャルを融合するMRのお手本のような活用方法ではないでしょうか。 夏以降も、MR花火大会、MR月見、MRハロウィンやMRホワイトクリスマスなどなど、いろいろな応用ができそうです。
AWS LambdaをVPC内に配置する際の注意点

AWS LambdaをVPC内に配置する際の注意点

はじめまして。プラットフォーム技術部の山崎です。 オンプレ環境のEOSL対応から始まったAWSリプレースプロジェクトで、インフラ周りの設計構築を担当しています。そこで得たナレッジをご紹介していきます。 今回はAWS LambdaのVPC内ヘの配置についてです。手軽にできるものと思っていたら、環境設定でいくつか考慮すべきことがありましたので、配置する際の注意点をまとめます。VPC内にLambdaを置くケース まずはじめに、Amazon Web Serviceの公式見解では、LambdaをVPC内に置くメリットは基本的にないというスタンスです。しかし、Amazon EC2やAmazon RDSなど、VPC内にあるリソースとLambdaで内部通信する場合はVPC内への配置が必要となります。例えば外部公開しないADサーバーとLambdaで認証情報をやりとりする、など。 [blogcard url="https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/best-practices.html#lambda-vpc"]VPC内に配置する際の注意点 主に5つです。 LambdaをVPC内に配置すると、Lambda実行時にENI(仮想ネットワークインターフェース)が付与されるようになります。それに伴い考慮すべきことがあります。 セキュリティグループの設定 Lambdaに対してセキュリティグループが設定できるようになります。 EC2/RDS等のVPC内リソースのセキュリティグループにて、Lambdaからのアクセスを許可しましょう。設定内容はLambdaのセキュリティグループや、Lambda専用サブネットを作成していたらそのサブネットなど、環境により適切な方法で設定します。 Lambdaのセキュリティグループは必要に応じて設定しますが、API Gatewayなど呼び出し元が特定できない場合はデフォルトのままとすることもあります。 IAMロールの設定 Lambda自身がENIを作成/削除できるようにするため、Lambdaに対してIAM(Identity and Access Management)権限を付与します。既にIAMポリシーとして「AWSLambdaVPCAccessExecutionRole」が用意されているので、Lambda用のIAMロールを作成する際にこのポリシーをあてて設定することも可能です。 所属サブネットの残りのIP 当然ながらVPCサブネットのプライベートIPアドレスを浪費するので、サブネット内の残りのIP数が枯渇しないよう注意してください。AWSのベストプラクティスでは、他のAWSリソースに影響が出ないようLambda専用のサブネットを用意することを推奨しています。冗長化のため、Lambdaも他のAWSリソースと同様マルチAZ(アベイラビリティゾーン)で構成します。 起動スピードが若干遅くなる Lambda実行時、ENIを作成しLambdaに付与する時間(数秒~数十秒程度)がかかります。 ただし、時間がかかるのは初回のLambda実行時のみで、それ以降は基本的には付与されているENIを使いまわします。Lambda実行リクエストが一定時間なければENIは自動削除されます。 なお、遅延時間分はLambda実行時間にはカウントされないため、その分の料金は計上されません。どうしても初回遅延が許容できないというのであれば、定期的にダミーのLambda実行をしてENIを自動削除させない、といった方法も考えられますが、仕組みは自身で構築する必要があります。 VPC外でも、厳密に言うとENI作成ほどではありませんがLambda初回実行時は若干時間がかかります。「コンテナ」と呼ばれるLambda実行環境を作成するためです。外部ネットワークと通信する際は、、、 ここが一番のポイントです。外部ネットワークと通信する際は、NATゲートウェイ等の設定が必要です。VPC内にあるLambda(ENI)にはパブリックIPが付与されないので、外部ネットワークと通信することができません。そのため、VPC内のパブリックサブネットにNATゲートウェイもしくはNATインスタンスを設定します。 結果、Lambdaの送信元IP(グローバルIPアドレス)は固定されることになります。 NATゲートウェイの場合は、冗長化を考慮するとAZ毎に設定が必要になるため、NATゲートウェイのコストが2,3倍となることも考えられます。まとめ VPC内にLambdaを置く場合は通信関連の考慮が必要になり、場合によってはランニングコストが増えるかもしれません。「お金がかかるのでNATゲートウェイを使用しない」という方針で設計すると、このようなケースでどうしても必要になることもありますので、アプリケーションや認証関連でLambdaを内部通信させる必要があるのか、事前に把握しておくとよいと思います。
突撃! 隣のスクラムチーム(スクラム交流会:2回目)

突撃! 隣のスクラムチーム(スクラム交流会:2回目)

こんにちは、ソリューション開発部 認定スクラムマスターの本間(manhole)です。 この一週間で大小合わせて15回くらいのふりかえりをしています。 (スクラムにはスプリント毎のふりかえりが組み込まれていますが、改善活動の一環としてふりかえりの頻度や対象を試行錯誤しています。← またの機会に書いてみたいと思います。) さて数ヶ月前になりますが、ARKメンバが参加している株式会社D2C様のスクラムチームが、本間が参加している株式会社アプレッソ様のスクラムチームを見学しました。(こちらの記事です。← 本間はアプレッソチーム側にいました。) そして今回はターンを交代し、アプレッソ様のチームがD2C様のスクラムを見学することになりましたので、交流会とその後のことについてご紹介します。 (以下、敬称略とさせていただきます。) 交流会に望む 交流会に向けて、両チームに良い影響をもたらせるよう、個人的に次のようなことをアプレッソチームの目的にしていました。相手チームの良い点と、改良できそうな点を見つける。 見つけた良い点と改良できそうな点を、フィードバックする。 見学したことを自分たちの活動に活かせるよう、ふりかえる。そして当日です。朝から夕方まで、スクラムイベントの幾つかを見学させていただきました。ふりかえり (スプリントレトロスペクティブ) 次スプリントのプランニング (そして懇親会へ...)これらのイベントは普段は日を分けて開催しているとのことですが、今回は多くのイベントを見学できるよう1日に調整していただきました。 また、交流会のために大人数が入れる会議室を用意していただきました。 「感謝っ・・・・!」「圧倒的感謝っ・・・・!」(元ネタ) 持ち運び可能なタスクボード 最初に目についたのが、タスクボードでした。 壁不足問題を改善するために「Smart Task Board」を購入したと聞いていたので、目にするのを楽しみにしていたのです。 屏風ふうに畳めて持ち運びしやすいという触れ込みの製品でして、実際に見学会の準備中に会議室へ担がれてきました。(見学者の視線が集まります) 軽く、立てかけなくても自立するなど、使い勝手が良さそうでした。(アプレッソチームの物欲が高まった瞬間です) アプレッソでの工夫が取り込まれてる! そのタスクボードを見ると、レイアウトや付箋の使われ方に既視感があります。尋ねると、アプレッソでの取り組みを輸入したとのことです。(前回の記事からも、取り入れようという意気込みが伝わってきます。)DONEのエリアが、日毎に分かれている。 → アプレッソチームでは日々の進捗をトラッキングしやすくするために始めたのですが、ふりかえりの際にタイムラインとして活用されるという、予想外の発展を遂げています。 計画したタスクと、予定外の追加タスク付箋を別の色にしている。 → 追加タスク付箋があることは、計画漏れがあるということです。ふりかえりで役立っています。 タスクボードに、その日のできごとや感じたことなどの付箋が貼られている。 → その付箋はKeepやProblemなどを示していて、ふりかえりのインプットとして使います。 ふりかえりになってから思い出すのでは、時間が掛かるのと、漏れが生じてしまうためです。交流会を実施して良かったと感じました。ありがたいです。 チーム活動っていいですね そして、終日に渡ってスクラムイベントを見学させて頂き、スクラムの中身は現場ごとに異なるのだな... と改めて実感しました。
【わたしに♥おまかせ Zabbix⑤】Zabbixのデータベースについて – アイテム編

【わたしに♥おまかせ Zabbix⑤】Zabbixのデータベースについて – アイテム編

本連載では「まるごとおまかせZabbix」をより便利で有用なサービスとするために日々奮闘中の齊藤(沙)がアークシステム ザビ家の一員として、Zabbix に関する日々の取り組みやナレッジをご紹介していきます!【わたしに♥おまかせ Zabbix①】Zabbixの構成要素とパラメーターについて 【わたしに♥おまかせ Zabbix②】Zabbixサーバーと内部プロセスについて 【わたしに♥おまかせ Zabbix 号外】Interop Tokyo 2017 Zabbixブースに出展! 【わたしに♥おまかせ Zabbix③】Zabbixの内部プロセスについて-続き 【わたしに♥おまかせ Zabbix④】Zabbixのデータベースについて 【わたしに♥おまかせ Zabbix⑤】Zabbixのデータベースについて - アイテム編(本記事) 【わたしに♥おまかせ Zabbix⑥】Zabbixのデータベースについて – トリガー編本サービスの詳細や、Zabbixを活用したソリューションにご興味をお持ちの方がいらっしゃいましたら サービス紹介ページ からお気軽にお問合わせ下さい。こんにちは!プラットフォーム技術部の齊藤(沙)です。 前回はZabbixが監視設定や履歴データを保管するデータベースの中でもホストに関連するテーブルについて確認しました。今回はアイテムに関連するテーブルについて確認していきます。 Zabbixを知ろう -Zabbixのデータベースについて -
【わたしに♥おまかせ Zabbix④】Zabbixのデータベースについて

【わたしに♥おまかせ Zabbix④】Zabbixのデータベースについて

本連載では「まるごとおまかせZabbix」をより便利で有用なサービスとするために日々奮闘中の齊藤(沙)がアークシステム ザビ家の一員として、Zabbix に関する日々の取り組みやナレッジをご紹介していきます!【わたしに♥おまかせ Zabbix①】Zabbixの構成要素とパラメーターについて 【わたしに♥おまかせ Zabbix②】Zabbixサーバーと内部プロセスについて 【わたしに♥おまかせ Zabbix 号外】Interop Tokyo 2017 Zabbixブースに出展! 【わたしに♥おまかせ Zabbix③】Zabbixの内部プロセスについて-続き 【わたしに♥おまかせ Zabbix④】Zabbixのデータベースについて(本記事) 【わたしに♥おまかせ Zabbix⑤】Zabbixのデータベースについて – アイテム編 【わたしに♥おまかせ Zabbix⑥】Zabbixのデータベースについて – トリガー編本サービスの詳細や、Zabbixを活用したソリューションにご興味をお持ちの方がいらっしゃいましたら サービス紹介ページ からお気軽にお問合わせ下さい。こんにちは!プラットフォーム技術部の齊藤(沙)です。 前回はZabbixサーバーの内部プロセスについて確認しましたね。 今回はZabbixが監視設定や履歴データを保管するデータベースについて確認していきます。 Zabbixを知ろう -Zabbixのデータベースについて 私たちアークシステムでは、パフォーマンスの観点からZabbixにおけるデータベースはMariaDB(Mysql)の使用を推奨しています。本記事では、Zabbix3.0、mariadb5.5の環境を用いて確認していきます。 ホストに関する情報について 主要テーブル一覧 監視対象であるホストに関する情報は、主に以下のテーブルに格納されています。 [crayon-5b0145b2153a9432285479/] hostsテーブル詳細 まずはホストに関する主要な情報が格納されている「hosts」テーブルについて詳しく確認していきます。
スクラム開発における不具合(バグ)発生時の対処方法

スクラム開発における不具合(バグ)発生時の対処方法

こんにちは。ソリューション開発部 認定スクラムマスターの飯出(いいで)です。 システム開発をしていると頻度はチームによってまちまちですが、不具合に遭遇することが良くあると思います。 えっ、不具合なんて全く発生しない!?すばらしいチームに所属されているようですね。残念ながら、私たちのチームはそのようなチームではありません。多少の不具合に遭遇することはあります。 今回はスクラム開発における不具合発生時の対処法について書いてみようと思います。あくまでも経験を踏まえた個人的な考え方ですが、参考になれば幸いです。 この記事を書こうと思った経緯 最近、以前に比べて不具合に遭遇するケースが多いと感じています。 私がスクラムマスターとして従事していたチームですが、現在はスクラムマスターのポジションを後輩に任せ、私はプロダクトオーナー(PO)のひとりとして従事しています。もしかしたら、不具合に遭遇するケースが多いと感じているのは、その立場が変わったからかも知れません。あくまでも、主観です。 不具合とは 不具合とは、「システムが想定通りに動作しない状況。および、その状況の原因となっている問題」を指す言い方ですね。「障害や欠陥、不良品、バグという言葉を使うことを回避するための、日本語特有の言い回し」とも言われます。 ここでの不具合は、スクラム開発において「プロダクトバックログ・アイテム(PBI)が完了(done)した後に見つかった不具合」、端的に言えば「スプリントを逃れた不具合」とします。すなわち、スプリントで実装中の PBI における不具合ではないということです。 実際の判断基準はチームによって異なると思いますが、実装上の不具合や要求を満たしていなかったもの。ですね。 不具合の対処方法 スクラム開発における不具合対処法を、(良きも悪きも)いくつか並べてみます。 半日程度で直るならPOと相談してすぐ修正する 私が認定スクラムマスター研修を受けた際に James O. Coplien氏 がそう話していました。後述しますが、付け焼き刃で対処しないことが重要だと思います。そう考えると、本当に軽微な不具合が対象となるでしょう。 優先順位の低いPBIとの入れ替えをPOと合意する 開発チームが対応可能と判断している場合において、優先順位の低い PBI との入れ替えを PO と合意し、不具合修正に着手するやり方です。これも、軽微な不具合が対象になるのではないかと思います。 POがPBIのひとつとして優先順位付けをする スクラム開発において、一番ポピュラーなやり方ではないでしょうか。即座に不具合修正に着手せずに、最速で次スプリントでの対処となるパターンです。言わずもがな、次スプリントでの着手となる場合は、PO が優先順位を高く設定した場合です。この場合において、開発チームは不具合修正のストーリーポイントを算出します。 POが「不具合の緊急度が高い」と判断した場合 PO の判断により不具合における業務影響が大きい等と判断した場合、スプリントの中止(スプリント緊急停止)を行います。重要なのは「PO による判断であること」です。私たちのチームでは、PO がスクラムマスターに必ず助言を求めるようにしています。これは、「スプリント緊急停止の乱発を抑えること」と「スクラムマスターがより良い対処(処方箋)ができるように」という効果を期待しています。 不具合の発生に備えた余力を残しておく 予め開発チームのキャパシティから不具合への対応時間を差し引いておくやり方です。「どのくらいの余力を残しておけば良いか」という課題がありますが、各スプリントで割り当てられた不具合修正の履歴から算出できるのではないかと思われます。 ただし、不具合修正スプリントを作ることは推奨しません。なぜなら、不具合をためこんで、あるタイミングで一気に消化する悪い癖が付く。 PO は PBI に対して、常に優先順位付けをすること。それを怠ってしまう。という理由です。 付け焼き刃で対処しない 「本番環境で動くからいいや。」ではいけません。自動化されたテストケースが存在するのであればそれも修正対象ですし、必要に応じてドキュメント修正も発生するかも知れません。何も言わないと、BTS