SlideShare a Scribd company logo
1 of 16
Download to read offline
ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料

はじめてのスクラム体験ワークショップ ∼ アジャイル時代のテスターを目指して
                               楽天株式会社 川口恭伸


1.本研修の目的
日本においても、アジャイル開発プロジェクトは、もはや珍しいものではなくなりまし
た。テストエンジニアのスキルとアジャイル開発はどのように交わっていくのでしょう
か。アジャイル開発において、品質保証はどのように行われていくのでしょうか。
本セッションでは、アジャイル開発におけるテストについて議論した後、アジャイルの基
本といえるスクラムのチーム運営について学んでいきます。


2.アジャイルとは
2001年 ボブ・マーティン1 の呼びかけで、軽量で実践的なソフトウェア開発プロセスを
実践している人々が、米国ユタ州ソルトレイクシティ近郊のSnowBirdという山荘に集ま
りました。ここで有名な「Manifesto for Agile Software Development
(通称: アジャイルマニフェスト)」がまとめられ、以後、様々なソフトウェア開発手法や、
その文化に「アジャイル」という呼称が用いられるようになりました。2


         アジャイルソフトウェア開発宣言3
         私たちは、ソフトウェア開発の実践
         あるいは実践を手助けをする活動を通じて、
         よりよい開発方法を見つけだそうとしている。
         この活動を通して、私たちは以下の価値に至った。
            プロセスやツールよりも個人と対話を、
            包括的なドキュメントよりも動くソフトウェアを、
            契約交渉よりも顧客との協調を、
            計画に従うことよりも変化への対応を、
         価値とする。すなわち、左記のことがらに価値があることを
         認めながらも、私たちは右記のことがらにより価値をおく。

         Kent Beck, Mike Beedle, Arie van Bennekum. Alistair Cockburn
         Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith
         Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin
         Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas


         © 2001, 上記の著者たち
         この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。




1   Robert C. Martin 『Clean Code』『Clean Coder』等の著者、通称 Uncle Bob (ボブおじさん)
2   http://d.hatena.ne.jp/wayaguchi/20110213/1297531229
3   http://agilemanifesto.org/iso/ja/
ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料



    12の原則
    1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
    2. 要求の変更はたとえ開発の後期であっても歓迎します。
      変化を味方につけることによって、お客様の競争力を引き上げます。
    3. 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
    4. ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
    5. 意欲に満ちた人々を集めてプロジェクトを構成します。
      環境と支援を与え仕事が無事終わるまで彼らを信頼します。
    6. 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
    7. 動くソフトウェアこそが進捗の最も重要な尺度です。
    8.アジャイル・プロセスは持続可能な開発を促進します。
      一定のペースを継続的に維持できるようにしなければなりません。
    9. 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
    10. シンプルさ(ムダなく作れる量を最大限にすること)が本質です。
    11. 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
    12. チームがもっと効率を高めることができるかを定期的に振り返り、
      それに基づいて自分たちのやり方を最適に調整します。




アジャイルは様々な方法論を含む総称としてつけられたラベルのため、「アジャイル開発
をしている」という場合にも、その実体としてどのようなプラクティスを採用しているの
か、どの程度行っているかによって、大きな多様性があります。




 
ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料




3. アジャイル・テスティング
ソフトウェア開発プロジェクトをアジャイルで行う際の、テスターや品質保証(QA)のスキ
ルを持つ人の役割を定義したのが、リザ・クリスピンとジャネット・グレゴリーによるア
ジャイル・テスティング Agile Testing です。


従来の品質保証担当は、製品開発の最終段階におけるチェックを主に行ってきました。仕
様書を(開発者とは別に)読み解き、テストケースを作成し、主に手作業で実施する...。し
かし、テストの自動化が進展した現在では、そのあり方も変化しています。


TDD (テスト駆動開発) は、ケント・ベックらXPコミュニティで発展してきた技法です。
開発者自身がユニットテストとソースコードをセットで書くことで、仕様の理解を明確に
し、リファクタリングを用いてコードの品質を洗練していきます。テストコードのカバ
レッジを計測し、ユニットテストが用意されていないコードをなるべく無くすことを目指
します。ペアプログラミング(2人一組でのプログラミング)によって、仕様の明確化と
コードレビューを同時に行うこともあります。


CI (継続的インテグレーション) 用のサーバを用意し、ソースコードとテストがソース
コード管理システムにコミットされたらすぐに、ビルドとテストを自動実行して後退(リグ
レッション)がないことを確認します。


このように、開発者自身が自動テストを書くようになれば、時間のかかる品質保証(QA)
は不要になるのではないか?という意見もアジャイルコミュニティにはあったようです。
しかし、TDDで記述するテストはあくまで「開発の足がかりになるもの」にとどめるのが
一般的です。その一方で、求められる品質を確かめようとすれば、必要なテストは多岐に
わたります。ですから、包括的なテスト設計のために、テスターの 役割とスキル が重
要になります。




    
     テスト自動化ピラミッド ( Mike Cohn )      (c)2012 Lisa Crispin, Janet Gregory
ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料

アジャイルテスター
アジャイルチームの中に、テストについての十分なスキルを持った人が必要です。リザと
ジャネットはそういった人を「アジャイルテスター」と定義しました。アジャイルテス
ターになるためには、アジャイルチームの文化や振る舞いを知り、参加していく必要があ
ります。


       アジャイルチームは業務に近いところで作業を行い、要求の詳細を理解していま
      す。チームが何を提供できるかに焦点を当て、昨日の優先順付けの決める多くの要
      素を把握しているのです。テスターは座って待っているのではなく、開発サイクルを
      通してチームに役立つことを探しています。 4


       アジャイルでは、テスターや品質保証の人たちだけが、品質に責任を持っているわ
      けではありません。「組織の壁」は気にせず、最高の製品を作り出せるスキルと要員
      だけを考えています。アジャイル開発の肝は高品質のソフトウェアを作り出すことで
      す。しかも、ビジネス価値を最大化するようなスピード感覚でソフトウェアを作り出
      します。これがチーム全体で進める仕事であり、テスターや任命された品質保証の
      専門家だけでやるものではありません。アジャイルチームにいる人はみな、「テス
      ト好き」になります。単体テスト以降のテストはコーディングを促進し、アプリケー
      ションがいかに稼働すべきかを理解し、タスクまたはストーリーが完了したことが
      分かります。 5


アジャイルチームが生み出すソフトウェアの品質は、チーム全体で責任を持ちます。 です
から、アジャイルテスターはチームの一員として、製品の品質を高めることに寄与しま
す。




    
    ドキュメントで受け渡すプロセス(左上)と、
    アジャイルのクロスファンクショナルチーム(右下)

4   『実践アジャイルテスト テスターとアジャイルチームのための実践ガイド』 (2009)  P.12
5   『実践アジャイルテスト テスターとアジャイルチームのための実践ガイド』 (2009)  P.15
ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料




4.スクラム : 最も普及したアジャイル・チーム・マネジメントの枠組み
スクラムはアジャイルのチームマネジメントのフレームワークとして、現在、最も普及し
ている手法です。90年代前半に、ジェフ・サザーランドとケン・シュウェイバーによって
作られ、96年に発表されました。この両名もアジャイルマニフェストの策定に参加してい
ます。スクラムは技術的なプラクティスを一切削ぎ落とし、チーム・マネジメントに
フォーカスしたプラクティスのみを残した フレームワーク としました。その結果、様々
な分野/プロダクトで利用可能な汎用性を持っています。


また、スクラムが参考にした論文の一つに、 日本人の竹内弘高・野中郁次郎の The
New New Product Development Game (1986) があります。これはホンダやキャノ
ン、富士ゼロックスの新製品開発の事例を研究したものです。従来の開発工程をフェーズ
毎に明確に区切るプロセスに対し、開発工程をオーバーラップさせ、全体を1チームとし
て作業を進める過程を採用していました。竹内と野中は論文中でその過程をラグビーの
「スクラム」と表現しました。




                                                                 
     The New New Product Development Game   Hirotaka Takeuchi, Ikujiro Nonaka (1986)
ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料

(1)3つの原則
スクラムはエンピリカル(経験主義)に基づくマネジメント手法です。机上の予測だけに頼
らず、できる限り実際の作業や成果物を用いて、意見を聞き、仮説を修正します。できる
限り頻繁にリリースとデモを行います。徐々にチームとして知識を獲得し、予測可能性を
上げ、現実的なリスクマネジメントのノウハウを獲得していきます。


 3つの原則
 ・透明性 transparency : チーム及び関係者全員が共通理解(common sense)を持つ
 ・検査 inspect : (作業の妨げにならない程度に)頻繁に成果物やプロセスを検査する
 ・適応 adapt : プロセスおよび成果物に問題があると判断された場合は対策を行う


一般的には以下のような制約を利用します。
 ・チームメンバーの頻繁な入れ替えを避け、なるべく固定のメンバーとする
 ・固定のスプリント期間(2-4週)を設け、ミーティングや計測、成果物の引渡しを行う
 ・チームの状態は特定の個人ではなく、チーム自身が管理を行う
 ・チームが持つ情報は、できる限りチーム内で共有する
 ・外部からの直接の指示を出さない (話は聞くが、メンバーが判断を行う)


(2)4つのミーティング
スクラムでは、スプリント内で行う4つのミーティングを定義しています。


 4つのミーティング(儀式)
 ・スプリント計画 : スプリント冒頭で行う
  ・第一部 : 実績に基づき、当スプリントの到達点をプロダクトオーナーと合意する
  ・第二部 : 当スプリント内で行うタスクをチーム内で詳細に検討する
 ・デイリースクラム(朝会) : 現在の状況をチームに共有する
 ・スプリントデモ(レビュー) : 成果物をステークホルダに共有、フィードバックを得る
 ・レトロスペクティブ(ふりかえり) : 自分たちのプロセスを見直し、改善案を出す


  例えば、2週間のスプリントの場合、以下のような時間を割り当てます。




                                                 6




6   http://www.publickey1.jp/blog/11/10_5.html
ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料

(3)3つのロール
スクラムではチームが主体ですが、チームを支援する2つのロールを定義しています。


 3つのロール(役割)
 ・チーム Team :
   スクラムの主体となる自己管理されたチーム。
   理想的にはプロダクトを作るのに必要な全ての能力を備えている。
 ・プロダクトオーナー Product Owner(PO) :
   チームが生み出すプロダクトの方向性を決定する役割。舵取り役。
   プロダクトバックログを適切にメンテナンスする責任を持つ。
   不確実な将来に対し、投資判断を行う。
 ・スクラムマスター Scrum Master(SM) :
   チームとプロセスの健康状態をチェックし、チームの前進と成長を促す。
   チームドクター。ミーティングのファシリテーションも行う(適宜)。
   前進への障害物を確認して、チームや外部          に除去を働きかける。
   次のスクラムマスターを育てる。




     
         @IT 開発チームを改善するためのスクラムTips
           最終回 5分で分かる、「スクラム」の基本まとめ




(4)3つのアーティファクト
チーム内の共通理解(common sense)を手助けするのがアーティファクトです。


 3つのアーティファクト(道具)
 ・プロダクトバックログ Product Backlog :
   プロダクトの要件を優先順位漬けされたリストにしたもの。
   一つ一つの項目をプロダクトバックログ項目(PBI)という。
   各PBIは、実現したときの価値をプロダクトオーナーが見積もり、
   実現のための作業規模をチームが見積もる。
   優先順位付け(並べ替え)はプロダクトオーナーが行う。
ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料

 ・スプリントバックログ Sprint Backlog :
   当該スプリントで完成する見込みのプロダクトバックログの一部。
   規模見積もりとベロシティ(推定される作業量)によって予測到達点を推測する。
   スプリント計画第一部で合意し、第二部で詳細に作業計画を行う。


 ・バーンダウン・チャート Burndown Chart:
   スプリント内の残作業量をプロットする右下がりのグラフ。
   スプリントバックログ内のPBIをスプリント期間内にすべて完了することが
   できるか、視覚的に把握する。




     Henrik Kniberg “塹壕よりScrumとXP(Scrum and XP from the Trenches)”7




7   http://www.infoq.com/jp/minibooks/scrum-xp-from-the-trenches
ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料

5.アジャイル開発のライフサイクルとテスターの役割
次にアジャイル開発のタイムボックスと、各タイミングでのテスターの役割についてみて
いきましょう。


(1)リリース計画




  
顧客と利用者が期待しているものを分析し、今回のリリースで優先する機能(フィー
チャー)を決定します。ユーザーストーリーを洗い出し、作業規模を見積もり、優先順位を
調整して、プロダクトバックログを完成させます。


 リリース計画で行うこと(チーム全体として)
 ・利用者が誰であるかを共有する
 ・利用者のワークフローを明らかにする、もしくは仮説を共有する
 ・利用者に提供する機能を、利用者視点で記述する (ユーザーストーリー)
 ・各ユーザーストーリーについて必要な受入テスト項目を洗い出す
 ・各ユーザーストーリーの規模を見積もる
 ・改善後のワークフローを確認し、ユーザーストーリー間の依存関係を考慮しながら、
  最小限必要なものを確認する
 ・リリースに必要な設備や、利用者に届けるための戦略と予定表/締切を確認する
 ・関連システムと移行計画、全体への影響やリスクを確認する
 ・テスト戦略について決定する。必要な環境、データ、リソース、時間はどれだけか
 ・完了の定義(各ユーザーストーリーの実装完了の基準、必要なテスト等)を決定する
 ・状況の見える化の仕組みを検討する


テスターは 成果物の価値を期待通りに届けられるよう、アイデアや計画の実現可能性に
ついて情報を提供し、テスト計画を立案することに主体的な貢献を行っていきます。



ストーリーカードと受け入れテスト項目
アジャイル開発で最も有名な手法の一つが「ストーリーカード」です。要件定義は、多様
な情報の収集と整理のプロセスですので、優れた 誰か に情報を集めることで、効率的な
意思決定を行う、というのが従来の方法でした。しかし現在では、解くべき問題が複雑に
なり、求められる時間的制約も厳しくなり、 誰か 一人だけでは実現可能な計画を作り上
ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料

げることは不可能になってきています。そこで、アジャイルでは、カードを媒介すること
で、チームの中央に知識を置き、多様なスキルを持つメンバーが集まり、効率的な要件定
義を行うのです。紙のカードは同時に複数のメンバーが書いたり、操作したりすることが
できます。




                                                                                            8



あわせて、完了までに確認が必要な項目(受け入れテスト項目)について検討します。具体
例で考えることで、利用者にとっての価値を共有し、完了までに必要な作業の規模をより
正確にし、スプリント開始後に確実に着手できるようにします。



テスト自動化による品質の作り込み
テスト自動化には2種類の取り組みがあります。TDD(テスト駆動開発)はデベロッパーテ
ストとも呼ばれ、開発者自身の作業の足がかりとしてテストを書いていくものです。各メ
ソッドの振る舞いをテストするコードを先に書き、テストに合格するようにメソッドの実
装を書いていきます。結果的にはコードとともに、十分な量のユニットテストが生み出さ
れ、いつでも確認できるようになります。また、テストを壊さないようにコードを洗練さ
せるリファクタリングも行っていきます。


一方で、受け入れテストレベルでの自動化を行うのがATDD(受入テスト駆動開発)や
BDD(ビヘイビア駆動開発)です。 受け入れテストを定義したり実施するのはプロダクト
オーナーや顧客の役目です。このため、FitNesse や Selenium、Cucumber などのツー
ルでは、非プログラマでも理解/記述できるよう、自然言語に近いドメイン特化言語や
HTML表などでテストケースを記述できるようになっています。スプリントの開始前にど
のような受け入れテストを実施するのかを決め、その実行のための環境を整備しておくこ
とが重要です。


アジャイルテスターにとって、受け入れテスト項目を洗い出し、自動テストに落とし込む
こと、また自動テストを適切に管理することは必須スキルといってよいでしょう。




8 http://www.mountaingoatsoftware.com/blog/advantages-of-the-as-a-user-i-want-user-story-
template
ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料



テストの全体像を俯瞰する
製品の品質を確保するには、自動化できるテスト以外にも、多様なテストがあります。




    アジャイルテストの四象限 ( Brian Marick )   (c)2012 Lisa Crispin, Janet Gregory



第1象限(左下)   :   テスト駆動開発(TDD)です。
第2象限(左上)   :   機能レベルで受入条件をテストします。ATDDやBDDが支援します。
第3象限(右上)   :   期待に合っているか、競合に対して価値があるかなどを確認します。
第4象限(右下)   :   非機能要件やセキュリティをテストします。




テスト環境、テストデータの整備
スプリントを始める前に、テストやリリースのための環境を確認し、できる限り整備して
おくべきです。また、各ユーザーストーリーの完了基準を考えておく必要もあります。



見える化の仕組みを検討する
テストの進捗や自動テストのカバレッジなどを、チームから見える場所に表示しておく方
法を整備しておきます。
ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料



(2)スプリント計画
スプリント計画フェーズでは、チームが当該スプリントで完成させるストーリーが選択さ
れ、詳細なタスク(作業計画)を検討します。




   


ストーリーがテスト可能であることを確認する
ストーリーがテスト可能であるかどうかは、カードを見るたびに気にする必要があります
が、スプリント計画はそれを確認する最後のチャンスです。


ストーリーをどのようにデモンストレーションするか検討する
スプリントの終了時にはステークホルダー向けにデモを行います。そのストーリーの成果
物や価値をわかってもらうためには、効果的なデモンストレーションが必要です。そのス
トーリーははっきりと見せられるでしょうか。完成したストーリーを、プログラマやテス
ター以外の人にも簡潔に説明する方法について検討します。


ストーリーの規模を明らかにする
チームはストーリーの規模を、プランニングポーカーなどを用いて見積もっていきます。
テスターもチームの一員として参加し、必要に応じて明確化(clarify)のための質問をしま
しょう。


大きすぎるストーリーは分割します。その際にも、最低限の機能はどこか? テスト工数
を最小限にしつつ、そのストーリーの有効性を確認できる実装方法はないか、検討を行い
ます。


まだ経験のない技術を採用するときなどは、「スパイク」という技術確認のためのストー
リーを行います。有限の調査検討時間を決めて、その技術を採用する意味があるかどうか
を検討します。その結果、次回以降のスプリントではより正確に見積もれるようになりま
す。
ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料



(3)スプリントの進行とテスト、完了の確認
チームは、ストーリーを優先順位に従って実装していきます。受け入れテストの自動化を
行う場合は、開発と平行して受け入れテストの自動化を進めます。




   
デイリースクラム(朝会)
スクラムでは、一日一回のミーティングを行って、日々の進捗やメンバーの状況を確認し
ます。以下の3点を手短かに共有します。
 ・昨日やったこと
 ・今日やること
 ・問題になっている事 (前進を妨げているもの)


開発者との協同作業
開発者の隣に座ってテストを実装する(ペアテスト)、気になる部分の進捗を適宜見せても
らう、ストーリーが持つ価値の理解を深めるためにチーム外の人々と話すなど、チームが
前進するために、できることを行っていきましょう。


不具合との対峙
スプリント進行中に、以前リリースしたシステムの不具合(バグ)が報告される事があるで
しょう。この場合は、スプリントで計画されたストーリーよりも優先して対処しなければ
ならない事がほとんどでしょう。すぐに直せる場合は、修正し、リグレッションテストを
行い、修正リリースします。 テストが自動化されていれば、リグレッションテストは短時
間ですみます。不具合への対処時間が短くなり、スプリントの見積もり工数からのズレも
軽微ですみます。


大きな対策が必要な場合は、プロダクトオーナーに説明し、プロダクトバックログに記載
します。


スクラムでは、プロダクトバックログを優先度順に記述しているため、予定外の作業を行
う場合にどのストーリーが実装できなくなるかが明らかです。プロダクトオーナーに報告
し、必要な対策(ステークホルダーへの説明など)をとってもらいます。
ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料



(4)スプリントデモ、レトロスペクティブ(ふりかえり)
スプリントの終盤では、完成したストーリーをステークホルダに見せ、フィードバックを
もらいます。その後、チームでスプリントをふりかえって、今後改善できるところがない
か検討します。




   
いつでも出荷可能なプロダクトの増分
スクラムでは、各スプリント中に各ストーリーを「いつでも出荷可能なプロダクトの増分
(Potentially shippable increment)」に仕上げます。プロダクトオーナーの出荷判断が下
ればいつでも出荷に応じられる状態、ということです。受け入れテストはすべて終了して
おり、事前に定義した「完了の定義(DoD)」にしたがって、その他の確認がすべて終了し
た状態です。


デモンストレーションのための過剰な準備をしてはならない
スプリントデモでは「いつでも出荷可能なプロダクトの増分」のあるがままをステークホ
ルダーに見せます。デモンストレーションのために過剰な資料や、ハリボテを準備しては
いけません。うまく伝えられなかった場合は、次に向けて改善策を検討しましょう。


チームとして改善する
スプリントデモは、チームの間違いや、ステークホルダー間の意見の食い違いなどを発見
する、よいチャンスです。多くの人は、動くソフトウェアや明日から使うような状態の
ツールがあってはじめて、具体的な想像力が働きます。チームは、成果物を提示し、ス
テークホルダーの意見に耳を傾けます。どんな情報も「見つかってよかった!」と考えま
しょう。


レトロスペクティブ(ふりかえり)を行って、チームとして改善のヒントを探っていきま
す。すぐにできない対策も、メモをとっておき、順に解決していきます。すぐに解決でき
る問題だけを問題と考えるのは危険です。


チームは前進しました。ささやかな成功を祝い、次のスプリントに備えましょう。
ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料



(5)リリースとデリバリー




    


製品を磨き上げる
複数のスプリントで作られた「いつでも出荷可能なプロダクトの増分」を組み合わせてリ
リースする場合には、結合した状態で、利用者にとって不都合がないかをチェックする必
要があります。まず、利用者になりかわって、チームとして探索的テストを行います。あ
らかじめ時間を決め、全員で使ってみるのです。可能であれば、実際のユーザー像に近い
第三者に協力をあおぎ、試しに使ってもらうところを、後ろから観察させてもらうと効果
的です。見つかった問題はすぐさま修正を検討します。


問題が発見されない/修正済みになったら、利用者の一部に使ってもらうことも検討しま
しょう。UAT(ユーザによる受け入れテスト)や、A/Bテスト(一部の顧客に先行リリース)を
通して、リリースされるストーリーの価値を確認していきます。


本番にリリースできてはじめて価値がある
本番環境へのリリースを行い、顧客に成果物を届けることで、初めて価値が発生します。
リリースできないストーリーはすべて在庫です。デリバリーをスムーズに行えるように環
境を整備することは、非常に重要です。
 ・ 開発環境、ステージング環境、本番環境は同じソースコードで展開可能ですか?
 ・ 本番環境の構成はバージョン管理システムで管理されていますか?
 ・ デプロイは自動化されていますか?
 ・ リリースをスムーズに行える手順が確立できていますか?
 ・ 問題があった場合の切り戻しの手順や影響は明らかですか?
 ・ 稼働監視は考慮できていますか?
 ・ 本番環境での障害時に情報を適切に収集する仕組みはできていますか?
ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料



成功への鍵
最後に、『実践アジャイルテスト』より、リザ・クリスピンとジャネット・グレゴリーの
挙げる成功への鍵を紹介します。


 ・1   :   チーム全体のアプローチ (whole team approach)
 ・2   :   アジャイルテストの考え方を採用する
 ・3   :   自動リグレッションテスト
 ・4   :   フェードバックを与え、受ける
 ・5   :   コアプラクティスの基礎を築く (CI, テスト環境、技術的負債の管理)
 ・6   :   顧客と共同作業する
 ・7   :   広い視野を持つ


もしかすると、企業の中にはさまざまな組織の壁があり、簡単にはチーム全体のアプロー
チができないと感じることもあるかもしれませんが、一つ一つ分析し、実験を積み重ね、
できることを増やしていっていただくことを祈っております。




謝辞
本原稿は、執筆の過程で山口鉄平氏、木村卓央氏、細谷泰夫氏の助言をいただきました。
また、本研修は森崎修司氏よりきっかけをいただきました。ジャネット・グレゴリーさん
には東京での研修の開催を通じて多くのことを教えていただきました。
ここに感謝を申し上げます。

More Related Content

What's hot

アジャイル開発の中の設計
アジャイル開発の中の設計アジャイル開発の中の設計
アジャイル開発の中の設計
Takuya Okamoto
 

What's hot (20)

アジャイル開発の中の設計
アジャイル開発の中の設計アジャイル開発の中の設計
アジャイル開発の中の設計
 
大企業アジャイルの勘所 #devlovex #devlovexd
大企業アジャイルの勘所 #devlovex #devlovexd大企業アジャイルの勘所 #devlovex #devlovexd
大企業アジャイルの勘所 #devlovex #devlovexd
 
Shinise maker minade_agile_2021_scrum_festo_saka
Shinise maker minade_agile_2021_scrum_festo_sakaShinise maker minade_agile_2021_scrum_festo_saka
Shinise maker minade_agile_2021_scrum_festo_saka
 
【初心者向】ロジカルシンキングをゼロからはじめる
【初心者向】ロジカルシンキングをゼロからはじめる【初心者向】ロジカルシンキングをゼロからはじめる
【初心者向】ロジカルシンキングをゼロからはじめる
 
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
 
人にうれしいAIのUXデザイン - Googleの「People + AI Guidebook」をひもとく:DevLOVE X
人にうれしいAIのUXデザイン - Googleの「People + AI Guidebook」をひもとく:DevLOVE X人にうれしいAIのUXデザイン - Googleの「People + AI Guidebook」をひもとく:DevLOVE X
人にうれしいAIのUXデザイン - Googleの「People + AI Guidebook」をひもとく:DevLOVE X
 
絶望と最後の希望
絶望と最後の希望絶望と最後の希望
絶望と最後の希望
 
リーンスタートアップを理解する
リーンスタートアップを理解するリーンスタートアップを理解する
リーンスタートアップを理解する
 
スタートアップの 3 分ピッチテンプレート
スタートアップの 3 分ピッチテンプレートスタートアップの 3 分ピッチテンプレート
スタートアップの 3 分ピッチテンプレート
 
Design Sprint 概要 / デザインスプリント概要
Design Sprint 概要 / デザインスプリント概要Design Sprint 概要 / デザインスプリント概要
Design Sprint 概要 / デザインスプリント概要
 
【SQiP2016】楽天のアジャイル開発とメトリクス事例
【SQiP2016】楽天のアジャイル開発とメトリクス事例【SQiP2016】楽天のアジャイル開発とメトリクス事例
【SQiP2016】楽天のアジャイル開発とメトリクス事例
 
TDD のこころ
TDD のこころTDD のこころ
TDD のこころ
 
Head First Inception Deck
Head First Inception DeckHead First Inception Deck
Head First Inception Deck
 
STAC2023 テストケースの自動生成に生成AI導入を検討してみた STAC2023
STAC2023 テストケースの自動生成に生成AI導入を検討してみた STAC2023STAC2023 テストケースの自動生成に生成AI導入を検討してみた STAC2023
STAC2023 テストケースの自動生成に生成AI導入を検討してみた STAC2023
 
ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。
 
事業成長にコミットするエンジニア組織への道のり
事業成長にコミットするエンジニア組織への道のり事業成長にコミットするエンジニア組織への道のり
事業成長にコミットするエンジニア組織への道のり
 
ストーリーでわかる「起業の科学」ハマりやすい57のワナスライド sd用
ストーリーでわかる「起業の科学」ハマりやすい57のワナスライド sd用ストーリーでわかる「起業の科学」ハマりやすい57のワナスライド sd用
ストーリーでわかる「起業の科学」ハマりやすい57のワナスライド sd用
 
アジャイル開発はWhyから始まる
アジャイル開発はWhyから始まるアジャイル開発はWhyから始まる
アジャイル開発はWhyから始まる
 
アジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイドアジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイド
 
2023-03-23_Spiral.AI
2023-03-23_Spiral.AI2023-03-23_Spiral.AI
2023-03-23_Spiral.AI
 

Viewers also liked

TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ
TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめTDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ
TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ
Kei Sawada
 
Salesforce1 platform最新動向とパートナーエコシステム
Salesforce1 platform最新動向とパートナーエコシステムSalesforce1 platform最新動向とパートナーエコシステム
Salesforce1 platform最新動向とパートナーエコシステム
Salesforce Developers Japan
 
ソフトウェア開発の3本柱
ソフトウェア開発の3本柱ソフトウェア開発の3本柱
ソフトウェア開発の3本柱
Shuji Watanabe
 
テスト駆動ゲーム開発をJava scriptで実践
テスト駆動ゲーム開発をJava scriptで実践テスト駆動ゲーム開発をJava scriptで実践
テスト駆動ゲーム開発をJava scriptで実践
Yuusuke Takeuchi
 
CIサーバーとSchemaSpyでデータベースのドキュメント作成を自動化
CIサーバーとSchemaSpyでデータベースのドキュメント作成を自動化CIサーバーとSchemaSpyでデータベースのドキュメント作成を自動化
CIサーバーとSchemaSpyでデータベースのドキュメント作成を自動化
Hiroyuki Ohnaka
 

Viewers also liked (20)

iOSビヘイビア駆動開発
iOSビヘイビア駆動開発iOSビヘイビア駆動開発
iOSビヘイビア駆動開発
 
テスト駆動開発のはじめ方
テスト駆動開発のはじめ方テスト駆動開発のはじめ方
テスト駆動開発のはじめ方
 
テスト駆動開発入門
テスト駆動開発入門テスト駆動開発入門
テスト駆動開発入門
 
TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ
TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめTDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ
TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ
 
Salesforce1 platform最新動向とパートナーエコシステム
Salesforce1 platform最新動向とパートナーエコシステムSalesforce1 platform最新動向とパートナーエコシステム
Salesforce1 platform最新動向とパートナーエコシステム
 
楽天テクノロジーカンファレンス2015 の見どころ、日本語版
楽天テクノロジーカンファレンス2015 の見どころ、日本語版楽天テクノロジーカンファレンス2015 の見どころ、日本語版
楽天テクノロジーカンファレンス2015 の見どころ、日本語版
 
Shizudev git hub宿題
Shizudev git hub宿題Shizudev git hub宿題
Shizudev git hub宿題
 
ソフトウェア開発の3本柱
ソフトウェア開発の3本柱ソフトウェア開発の3本柱
ソフトウェア開発の3本柱
 
楽天テクノロジーカンファレンス2016 の見どころ 日本語版
楽天テクノロジーカンファレンス2016 の見どころ 日本語版楽天テクノロジーカンファレンス2016 の見どころ 日本語版
楽天テクノロジーカンファレンス2016 の見どころ 日本語版
 
テスト駆動ゲーム開発をJava scriptで実践
テスト駆動ゲーム開発をJava scriptで実践テスト駆動ゲーム開発をJava scriptで実践
テスト駆動ゲーム開発をJava scriptで実践
 
Visual studio 2015 update1 ctpとcsi
Visual studio 2015 update1 ctpとcsiVisual studio 2015 update1 ctpとcsi
Visual studio 2015 update1 ctpとcsi
 
ライトニングトーク Windows10体験記 201510_山p(アップロード用)
ライトニングトーク Windows10体験記 201510_山p(アップロード用)ライトニングトーク Windows10体験記 201510_山p(アップロード用)
ライトニングトーク Windows10体験記 201510_山p(アップロード用)
 
Grani's way of thinking infrastructure
Grani's way of thinking infrastructureGrani's way of thinking infrastructure
Grani's way of thinking infrastructure
 
TDDBC お題
TDDBC お題TDDBC お題
TDDBC お題
 
CIサーバーとSchemaSpyでデータベースのドキュメント作成を自動化
CIサーバーとSchemaSpyでデータベースのドキュメント作成を自動化CIサーバーとSchemaSpyでデータベースのドキュメント作成を自動化
CIサーバーとSchemaSpyでデータベースのドキュメント作成を自動化
 
どうやらテスト駆動型開発は死んだようです。これからのCI
どうやらテスト駆動型開発は死んだようです。これからのCIどうやらテスト駆動型開発は死んだようです。これからのCI
どうやらテスト駆動型開発は死んだようです。これからのCI
 
【JaSST'14 Tokyo】システムテストの自動化による 大規模分散検索プラットフォームの 開発工程改善 #JaSST
【JaSST'14 Tokyo】システムテストの自動化による 大規模分散検索プラットフォームの 開発工程改善 #JaSST【JaSST'14 Tokyo】システムテストの自動化による 大規模分散検索プラットフォームの 開発工程改善 #JaSST
【JaSST'14 Tokyo】システムテストの自動化による 大規模分散検索プラットフォームの 開発工程改善 #JaSST
 
Agile Testing Learning journeys for the whole team at AgileJapan 2015
Agile Testing Learning journeys for the whole team at AgileJapan 2015Agile Testing Learning journeys for the whole team at AgileJapan 2015
Agile Testing Learning journeys for the whole team at AgileJapan 2015
 
Azure Service Fabric 概要
Azure Service Fabric 概要Azure Service Fabric 概要
Azure Service Fabric 概要
 
アジャイルテスト勉強会
アジャイルテスト勉強会アジャイルテスト勉強会
アジャイルテスト勉強会
 

Similar to はじめてのスクラム体験ワークショップ 〜 アジャイル時代のテスターを目指して

はじめてのアジャイル
はじめてのアジャイルはじめてのアジャイル
はじめてのアジャイル
Takao Kimura
 
Coding Guide
Coding GuideCoding Guide
Coding Guide
ohdreamer
 
TFSUG : TFS2010ハンズオンラボ資料
TFSUG : TFS2010ハンズオンラボ資料TFSUG : TFS2010ハンズオンラボ資料
TFSUG : TFS2010ハンズオンラボ資料
Hiroyuki Wada
 

Similar to はじめてのスクラム体験ワークショップ 〜 アジャイル時代のテスターを目指して (20)

とりあえず30分でひととおり分かった気にはなれるアジャイル入門
とりあえず30分でひととおり分かった気にはなれるアジャイル入門とりあえず30分でひととおり分かった気にはなれるアジャイル入門
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
 
アジャイル開発&TFS導入
アジャイル開発&TFS導入アジャイル開発&TFS導入
アジャイル開発&TFS導入
 
To be sn agile enterprise
To be sn agile enterpriseTo be sn agile enterprise
To be sn agile enterprise
 
JAWS FESTA Kansai 2013 | ビジネスに貢献する戦略的なITのためのDevOps
JAWS FESTA Kansai 2013 | ビジネスに貢献する戦略的なITのためのDevOpsJAWS FESTA Kansai 2013 | ビジネスに貢献する戦略的なITのためのDevOps
JAWS FESTA Kansai 2013 | ビジネスに貢献する戦略的なITのためのDevOps
 
Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】
Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】 Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】
Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】
 
Scrum"再"入門
Scrum"再"入門Scrum"再"入門
Scrum"再"入門
 
はじめてのアジャイル
はじめてのアジャイルはじめてのアジャイル
はじめてのアジャイル
 
GCSアジャイル開発を使ったゲームの作り方
 GCSアジャイル開発を使ったゲームの作り方 GCSアジャイル開発を使ったゲームの作り方
GCSアジャイル開発を使ったゲームの作り方
 
アジャイルマネジメントとは?
アジャイルマネジメントとは?アジャイルマネジメントとは?
アジャイルマネジメントとは?
 
組み込み開発のテストとゲーム開発のテストの違い
組み込み開発のテストとゲーム開発のテストの違い組み込み開発のテストとゲーム開発のテストの違い
組み込み開発のテストとゲーム開発のテストの違い
 
Pivotal Trackerでアジャイルなプロジェクト管理
Pivotal Trackerでアジャイルなプロジェクト管理Pivotal Trackerでアジャイルなプロジェクト管理
Pivotal Trackerでアジャイルなプロジェクト管理
 
Coding Guide
Coding GuideCoding Guide
Coding Guide
 
Bringing Continuous Agile to Japan
Bringing Continuous Agile to JapanBringing Continuous Agile to Japan
Bringing Continuous Agile to Japan
 
アジャイル風の開発で集中を実現する
アジャイル風の開発で集中を実現するアジャイル風の開発で集中を実現する
アジャイル風の開発で集中を実現する
 
Ti dd force09
Ti dd force09Ti dd force09
Ti dd force09
 
【XDev】A-2 アジリティ向上のためのツール活用
【XDev】A-2 アジリティ向上のためのツール活用【XDev】A-2 アジリティ向上のためのツール活用
【XDev】A-2 アジリティ向上のためのツール活用
 
でぶさみ夏2013 キーノート オレンジレンジャーの資料
でぶさみ夏2013 キーノート オレンジレンジャーの資料でぶさみ夏2013 キーノート オレンジレンジャーの資料
でぶさみ夏2013 キーノート オレンジレンジャーの資料
 
[TL09] 突撃! 隣の Visual Studio Team Services / Team Foundation Server ~利用者からのベスト...
[TL09] 突撃! 隣の Visual Studio Team Services / Team Foundation Server ~利用者からのベスト...[TL09] 突撃! 隣の Visual Studio Team Services / Team Foundation Server ~利用者からのベスト...
[TL09] 突撃! 隣の Visual Studio Team Services / Team Foundation Server ~利用者からのベスト...
 
TFSUG : TFS2010ハンズオンラボ資料
TFSUG : TFS2010ハンズオンラボ資料TFSUG : TFS2010ハンズオンラボ資料
TFSUG : TFS2010ハンズオンラボ資料
 
Quality characteristics
Quality characteristicsQuality characteristics
Quality characteristics
 

More from Rakuten Group, Inc.

More from Rakuten Group, Inc. (20)

コードレビュー改善のためにJenkinsとIntelliJ IDEAのプラグインを自作してみた話
コードレビュー改善のためにJenkinsとIntelliJ IDEAのプラグインを自作してみた話コードレビュー改善のためにJenkinsとIntelliJ IDEAのプラグインを自作してみた話
コードレビュー改善のためにJenkinsとIntelliJ IDEAのプラグインを自作してみた話
 
楽天における安全な秘匿情報管理への道のり
楽天における安全な秘匿情報管理への道のり楽天における安全な秘匿情報管理への道のり
楽天における安全な秘匿情報管理への道のり
 
What Makes Software Green?
What Makes Software Green?What Makes Software Green?
What Makes Software Green?
 
Simple and Effective Knowledge-Driven Query Expansion for QA-Based Product At...
Simple and Effective Knowledge-Driven Query Expansion for QA-Based Product At...Simple and Effective Knowledge-Driven Query Expansion for QA-Based Product At...
Simple and Effective Knowledge-Driven Query Expansion for QA-Based Product At...
 
DataSkillCultureを浸透させる楽天の取り組み
DataSkillCultureを浸透させる楽天の取り組みDataSkillCultureを浸透させる楽天の取り組み
DataSkillCultureを浸透させる楽天の取り組み
 
大規模なリアルタイム監視の導入と展開
大規模なリアルタイム監視の導入と展開大規模なリアルタイム監視の導入と展開
大規模なリアルタイム監視の導入と展開
 
楽天における大規模データベースの運用
楽天における大規模データベースの運用楽天における大規模データベースの運用
楽天における大規模データベースの運用
 
楽天サービスを支えるネットワークインフラストラクチャー
楽天サービスを支えるネットワークインフラストラクチャー楽天サービスを支えるネットワークインフラストラクチャー
楽天サービスを支えるネットワークインフラストラクチャー
 
楽天の規模とクラウドプラットフォーム統括部の役割
楽天の規模とクラウドプラットフォーム統括部の役割楽天の規模とクラウドプラットフォーム統括部の役割
楽天の規模とクラウドプラットフォーム統括部の役割
 
Rakuten Services and Infrastructure Team.pdf
Rakuten Services and Infrastructure Team.pdfRakuten Services and Infrastructure Team.pdf
Rakuten Services and Infrastructure Team.pdf
 
The Data Platform Administration Handling the 100 PB.pdf
The Data Platform Administration Handling the 100 PB.pdfThe Data Platform Administration Handling the 100 PB.pdf
The Data Platform Administration Handling the 100 PB.pdf
 
Supporting Internal Customers as Technical Account Managers.pdf
Supporting Internal Customers as Technical Account Managers.pdfSupporting Internal Customers as Technical Account Managers.pdf
Supporting Internal Customers as Technical Account Managers.pdf
 
Making Cloud Native CI_CD Services.pdf
Making Cloud Native CI_CD Services.pdfMaking Cloud Native CI_CD Services.pdf
Making Cloud Native CI_CD Services.pdf
 
How We Defined Our Own Cloud.pdf
How We Defined Our Own Cloud.pdfHow We Defined Our Own Cloud.pdf
How We Defined Our Own Cloud.pdf
 
Travel & Leisure Platform Department's tech info
Travel & Leisure Platform Department's tech infoTravel & Leisure Platform Department's tech info
Travel & Leisure Platform Department's tech info
 
Travel & Leisure Platform Department's tech info
Travel & Leisure Platform Department's tech infoTravel & Leisure Platform Department's tech info
Travel & Leisure Platform Department's tech info
 
OWASPTop10_Introduction
OWASPTop10_IntroductionOWASPTop10_Introduction
OWASPTop10_Introduction
 
Introduction of GORA API Group technology
Introduction of GORA API Group technologyIntroduction of GORA API Group technology
Introduction of GORA API Group technology
 
100PBを越えるデータプラットフォームの実情
100PBを越えるデータプラットフォームの実情100PBを越えるデータプラットフォームの実情
100PBを越えるデータプラットフォームの実情
 
社内エンジニアを支えるテクニカルアカウントマネージャー
社内エンジニアを支えるテクニカルアカウントマネージャー社内エンジニアを支えるテクニカルアカウントマネージャー
社内エンジニアを支えるテクニカルアカウントマネージャー
 

Recently uploaded

2024年5月25日Serverless Meetup大阪 アプリケーションをどこで動かすべきなのか.pptx
2024年5月25日Serverless Meetup大阪 アプリケーションをどこで動かすべきなのか.pptx2024年5月25日Serverless Meetup大阪 アプリケーションをどこで動かすべきなのか.pptx
2024年5月25日Serverless Meetup大阪 アプリケーションをどこで動かすべきなのか.pptx
ssuserbefd24
 
研究紹介スライド: オフライン強化学習に基づくロボティックスワームの制御器の設計
研究紹介スライド: オフライン強化学習に基づくロボティックスワームの制御器の設計研究紹介スライド: オフライン強化学習に基づくロボティックスワームの制御器の設計
研究紹介スライド: オフライン強化学習に基づくロボティックスワームの制御器の設計
atsushi061452
 

Recently uploaded (12)

部内勉強会(IT用語ざっくり学習) 実施日:2024年5月17日(金) 対象者:営業部社員
部内勉強会(IT用語ざっくり学習) 実施日:2024年5月17日(金) 対象者:営業部社員部内勉強会(IT用語ざっくり学習) 実施日:2024年5月17日(金) 対象者:営業部社員
部内勉強会(IT用語ざっくり学習) 実施日:2024年5月17日(金) 対象者:営業部社員
 
情報を表現するときのポイント
情報を表現するときのポイント情報を表現するときのポイント
情報を表現するときのポイント
 
Intranet Development v1.0 (TSG LIVE! 12 LT )
Intranet Development v1.0 (TSG LIVE! 12 LT )Intranet Development v1.0 (TSG LIVE! 12 LT )
Intranet Development v1.0 (TSG LIVE! 12 LT )
 
5/22 第23回 Customer系エンジニア座談会のスライド 公開用 西口瑛一
5/22 第23回 Customer系エンジニア座談会のスライド 公開用 西口瑛一5/22 第23回 Customer系エンジニア座談会のスライド 公開用 西口瑛一
5/22 第23回 Customer系エンジニア座談会のスライド 公開用 西口瑛一
 
論文紹介:Deep Occlusion-Aware Instance Segmentation With Overlapping BiLayers
論文紹介:Deep Occlusion-Aware Instance Segmentation With Overlapping BiLayers論文紹介:Deep Occlusion-Aware Instance Segmentation With Overlapping BiLayers
論文紹介:Deep Occlusion-Aware Instance Segmentation With Overlapping BiLayers
 
クラウド時代におけるSREとUPWARDの取組ーUPWARD株式会社 CTO門畑
クラウド時代におけるSREとUPWARDの取組ーUPWARD株式会社 CTO門畑クラウド時代におけるSREとUPWARDの取組ーUPWARD株式会社 CTO門畑
クラウド時代におけるSREとUPWARDの取組ーUPWARD株式会社 CTO門畑
 
Amazon Cognitoで実装するパスキー (Security-JAWS【第33回】 勉強会)
Amazon Cognitoで実装するパスキー (Security-JAWS【第33回】 勉強会)Amazon Cognitoで実装するパスキー (Security-JAWS【第33回】 勉強会)
Amazon Cognitoで実装するパスキー (Security-JAWS【第33回】 勉強会)
 
2024年5月25日Serverless Meetup大阪 アプリケーションをどこで動かすべきなのか.pptx
2024年5月25日Serverless Meetup大阪 アプリケーションをどこで動かすべきなのか.pptx2024年5月25日Serverless Meetup大阪 アプリケーションをどこで動かすべきなのか.pptx
2024年5月25日Serverless Meetup大阪 アプリケーションをどこで動かすべきなのか.pptx
 
20240523_IoTLT_vol111_kitazaki_v1___.pdf
20240523_IoTLT_vol111_kitazaki_v1___.pdf20240523_IoTLT_vol111_kitazaki_v1___.pdf
20240523_IoTLT_vol111_kitazaki_v1___.pdf
 
論文紹介:ViTPose: Simple Vision Transformer Baselines for Human Pose Estimation
論文紹介:ViTPose: Simple Vision Transformer Baselines for Human Pose Estimation論文紹介:ViTPose: Simple Vision Transformer Baselines for Human Pose Estimation
論文紹介:ViTPose: Simple Vision Transformer Baselines for Human Pose Estimation
 
研究紹介スライド: オフライン強化学習に基づくロボティックスワームの制御器の設計
研究紹介スライド: オフライン強化学習に基づくロボティックスワームの制御器の設計研究紹介スライド: オフライン強化学習に基づくロボティックスワームの制御器の設計
研究紹介スライド: オフライン強化学習に基づくロボティックスワームの制御器の設計
 
ロボットマニピュレーションの作業・動作計画 / rosjp_planning_for_robotic_manipulation_20240521
ロボットマニピュレーションの作業・動作計画 / rosjp_planning_for_robotic_manipulation_20240521ロボットマニピュレーションの作業・動作計画 / rosjp_planning_for_robotic_manipulation_20240521
ロボットマニピュレーションの作業・動作計画 / rosjp_planning_for_robotic_manipulation_20240521
 

はじめてのスクラム体験ワークショップ 〜 アジャイル時代のテスターを目指して