品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)

location_city Osaka schedule Jun 26th 03:00 - 03:45 PM JST place 新潟 people 9 Interested

スクラムで品質に悩んでいるチームや組織へのアプローチを整理する話をします。


品質を向上するためにテスターやQAエンジニア、SETやSREを増やそうとする組織は多いですが、スキルセットやキャリアパスをどのように決めていけばよいのかについて困っているところも多いと思います。また、当面はテストを外部発注してしのぐとしても、どう内製化するか、どうスケールするか、どう組織全体に根付かせていくか、について悩んでいる組織も多いと思います。


そうした悩みを解決するために、本プレゼンテーションではQMファンネル(3D版)を使って整理するお話を紹介します。


頂点が下向きになっている三角錐を想像してください。まず三角錐の側面はエンジニアのスペシャリティ(得意技)です。スペシャリティをTE(Test Engineer、いわゆるテスター)、QA(Quality Assurance、いわゆる品質保証)、DA(Delivery Accelerator、いわゆるSETやSRE)の3つに分けて整理します。もちろん、それぞれのスペシャリティがサイロ化しないように、側面の境界をスムーズにするような境界的なスペシャリティも考えないといけません。


次に、三角錐の深さはレンジ(範囲)になります。レンジを、外部発注したり専門組織によるサービスという役割分担から、スクラムチームの内部だけで頑張るインプロセス、チームと一緒に開発しながら高度なスペシャリティを浸透させるコーチ、それぞれのチームの外部からスペシャリティを移転するコンサルタント、組織全体にスペシャリティを浸透させていくプロモーターといった5つのレンジに分けて整理します。


品質を向上するには、TE、QA、DAの3つのスペシャリティが全て必要です。これらをまとめてQM(品質マネジメント)として捉えることで、バランスのよい品質向上が実現できます。同時にオールレンジの活動を意識することで、組織全体でバランスよく品質向上を浸透させることができます。


またQMファンネルは、伝統的なプロジェクトのようにPMとエンジニアを区別する考え方ではないという点にも注意する必要があります。スクラムチームでは、テスト計画・テスト設計・テスト実行を分割してサイロ化させるのは得策ではありませんし、コンサルタントやプロモーターが偉いわけでもありませんので。


私たちのQMファンネル(3D版)について聞いて頂いて、皆さんの組織の品質がスムーズに加速できればとても嬉しく思います。たくさん議論させてくださいね!

 
 

Outline/Structure of the Talk

- QAやテスター職の採用やキャリアパスの悩み
- 品質向上の大規模化にまつわる罠
- QMファンネル(3D版)の全体像
- TE、QA、DAの各スペシャリティの概要
- 境界的なスペシャリティ
- サービス、インプロセス、コーチ、コンサルタント、プロモーターの各レンジの概要
- レンジはマネジメント階層か?
- QMファンネル(3D版)の使い方

Learning Outcome

- 組織的に品質向上を進めるためのヒント
- QAやテスター、SETやSRE職に対するキャリアパスのヒント
- QAやテスター職の採用活動を明確化するためのヒント

Target Audience

QAやテスター職の採用活動がピンボケだなと感じている組織の皆さん、QAやテスター職のキャリアパスがうまく提示できないと感じている組織の皆さん 、組織的に品質向上を進めたいと考えている組織の皆さん、などなど

Prerequisites for Attendees

- 自分たちの組織の品質確保は外部発注頼りになっていないか?
- 自分たちの組織の品質向上活動はスケールするのか?
- 自分たちの組織では品質関連職に品質関連職以外のキャリアパスを提示できているか?

schedule Submitted 1 year ago

  • Yoh Nakamura
    keyboard_arrow_down

    Yoh Nakamura - チームの状況にあったいろいろなタイプのスクラムマスターの見つけ方

    20 Mins
    Talk
    Beginner

    「どういう人がスクラムマスターをやればいいんだろうか?」

    この質問はチームがScrumに取り組もうとした時によく出てくることの1つです
    Scrumにあるプロダクトオーナー、スクラムマスター、開発者の3つの役割のうち、特にスクラムマスターはわかりにくいようで、この冒頭の質問が出てくるようです

    しかし、一方で、ScrumGuideには以下にあるようにスクラムが機能するにはとても重要な役割を果たします

    スクラムマスターは、スクラムガイドで定義されたスクラムを確立させることの結果に責任を 持つ。スクラムマスターは、スクラムチームと組織において、スクラムの理論とプラティクス を全員に理解してもらえるよう支援することで、その責任を果たす。

    では、どのような人がスクラムマスターに向いているのでしょうか?
    またプロダクト、チームや組織の状況によってどういうような人がスクラムマスターをするとより良いのでしょうか?

    このセッションでは、「どういう人がスクラムマスターをやればいいんだろうか?」という質問に、ギルドワークスの現場コーチとして70チーム以上(すべてにスクラムマスターがいたわけではありませんが)を支援してきた事例から自分なりの経験や考えをお話できればと思います

    よりよいスクラムマスターと出会える、見つける、なっていくヒントになれば幸いです

  • Kei Nakahara
    keyboard_arrow_down

    Kei Nakahara - 老舗メーカーにみんなでアジャイルを導入してみました ~「俺がやる!」から「みんなでやる!」に至るまで~

    45 Mins
    Talk
    Beginner

    既存の組織体系やマインドが色濃く残る老舗メーカーで、健全なソフトウェア開発を実現できるよう全社的にアジャイルや要求開発の導入を推進してきました。

    2016年に、ほぼ私一人で始めた活動ですが、今では20名を超えるコーチングチームを組織するに至りました。
    一部の活動は私の手を離れ、完全に社内コミュニティを主体に運営されています。
    さらに、毎年開催している社内のアジャイルカンファレンスは、17年時点は約450名ほどの参加者だったのが20年には倍の約900名にまで増えました。
    さらにさらに、私が支援した社内のサービス開発チームが、SFOにプロポーザルを出すに迄いたりました。

    ここに至るまで経緯や具体的な施策、現在直面している困難と課題についてお話しさせて頂きます。

    現在の途中経過ではありますが、少しでも皆さんの参考になれば幸いです。

  • Masanori Kawarada (Mark Ward)
    keyboard_arrow_down

    Masanori Kawarada (Mark Ward) - 独立QAチーム1年戦記:スクラムの外からチームと組織の品質を創る道 / An Independent QA Team's 1 Year's War: Way to Create Quality of the Teams and the Organization from the Outside of Scrum

    45 Mins
    Talk
    Intermediate

    English follows:

    [email protected][email protected])を取り入れた100名ほどの開発組織で、スクラムに入らない独立したQAチームが活躍している」と聞いたら、もしかしたら奇異な感じを受けるかもしれない。スクラムではチームであらゆることが完結することを理想とするため、当然テスター(QAエンジニア・テストエンジニア ・などなど)もスクラムチームに入るべき、と考える方がスクラム実践者にとっては自然だからである。あえて、その自然に逆らって、私たちQAチームは独自のビジョンを掲げた「ビジョナリー・QA(Visionary QA)」として、独立した立場から品質向上という成果を上げようと奮闘している。このトークではそんな私たちQAチームの1年戦記をありのままに扱いたい。

    開発プロセスの高速化が進み、多くの企業でアジャイル開発が取り入れられ、過去の当たり前が当たり前でなくなっている中で、QA界隈ではどうやって価値を提供するか頭を悩ませている。あくまでもテストにこだわる者もいれば、スクラムマスター・プロダクトオーナーの視野を得るべく資格を目指す者もいる。2009年に翻訳出版されたリサとジャネットによる『実践アジャイルテスト(Agile Testing)』(翔泳社)は国内のテスターに広く読まれているが、最近版元品切になっていることもあり、手に入りにくくなっている。

    さて、テスターは異質な存在のひとつとして見なされている。ご存知の通り、スクラムガイドにはテストやQA活動をどのように行うべきか、言及されていない。3つのロールに「テスター」の文字は無い。よって、テスターのあり方はそれぞれの組織で模索するしかなく、特にテスターをスクラムチームに含めるべきか否かという議論は継続的に行われている。先にもあげたように、スクラム実践者にとってはテスターがスクラムチームに入ることは自然であると感じられ、実際そのようにしている組織が多いが、それぞれにメリット・デメリットがあることから、あらゆる組織で通じる答えは今のところ無さそうだ(テスターとして仕事をしてきたメンバーがスクラムチームの開発者の一員としてどれだけクロスファンクショナルに動けるか、という点が特にネックなように思える)。

    このトークは、独立した立場で動くことを選んだQAチームの話だ。スクラムチームにテスターを迎え入れねばならないと思っている方にはそうでない可能性を示す一方で、やはりスクラムチームに開発者としてテスターを加えるべきだと結論づけるオーディエンスもいらっしゃるかもしれない。スクラムチームとテスターの一筋縄ではいかない関係を、1年間の実例をもとに、一緒に考えようではないか。

    "In a 100-strong software development organization which runs [email protected], an independent QA team works well." ––it may sound strange to you. Ideally, in Scrum, everything should be done in one scrum team, so it is natural for Scrum practitioners that testers (QA engineers, test engineers, etc.) should join a scrum team. Daring to go an unnatural way, our QA team struggles to achieve quality improvement results from an independent standpoint as "Visionary QA" with its vision. I want to treat our QA team's year-long battle story as it is in this talk.

    Development processes are getting faster and faster. Many companies are incorporating agile development. The commonplace of the past is no longer the norm. In this fast-changing age, the QA industry is struggling to figure out how to deliver value.  Some testers are more concerned with testing, while others aim for the certification to learn a Scrum Master/Product Owner's perspective. The excellent book, "Agile Testing" by Lisa Crispin and Janet Gregory (Addison-Wesley), which was translated in Japan in 2009 by the domestic publisher Shoeisha, has been widely read by testers in our country. Recently, however, it isn't easy to get due to out of print.

    Testers tend to be seen as one of the heterogeneous entities. As you know, there is no mention in the Scrum Guide on how testing and QA activities should be done. There is no "Tester" in the three roles of Scrum. Therefore, each organization has no choice but to explore the nature of testers. In particular, there is an ongoing debate on whether or not testers should be included in Scrum. As mentioned earlier, it seems natural for Scrum practitioners to have testers join Scrum, and indeed many organizations are doing so. Still, since each has its advantages and disadvantages, it seems that we don't have an answer that works for all organizations at the moment. One of the problematic points appears to be how well testers can work cross-functionally as a "Developer" in Scrum.

    With this session, which is about a QA team that chose to work independently, some attendees who feel testers should join a Scrum team may get a chance to notice the other possibility, and others may conclude that Scrum teams should still include testers. Let's take a look at the tricky relationship between Scrum and testers with the help of a year's worth of examples.

  • Yotaro Takahashi
    keyboard_arrow_down

    Yotaro Takahashi - もしもエンジニアリングマネージャーが妻のアメリカ出張を一年間経験することになったら

    45 Mins
    Talk
    Intermediate

    My Wife Went To U.S.

    それは突然のことでした。「ねぇ、4月からアメリカ行っていい?」

    そこから始まる父と小学生の息子2人、トイプードルの娘1人との1年間の情熱ワンオペ育児。たくさんの不安がよぎります。しかし、この困難に正面から立ち向かうことにしました。自分の道具箱にはエンジニアリングマネージャーとしての経験があります。これをどうにか活かすことはできないかと取り組みを始めます。

    エンジニアリングマネージャーが家事育児にトライしてみると?

    実際に取り組みを始めてみると、自分のこれまでのエンジニア、マネージャーとしての経験が多くの場面で活かせることに気がつきます。実際に経験したものの一例は下記のようなものです。

    • あ、冷蔵庫行ったり来たりすると面倒だな(TPSのムダの発見と解消)
    • 仕事をどう調整つけようか、不安がる実家の親をどう安心させようか(ステークホルダーへの透明性)
    • ホットクック(自動化)
    • 水回り、お金払ってピカピカになるととってもアガるし効率がいいな(アウトソース)
    • 料理代行、ただ作ってもらうだけだとそんなに楽にならないな(リーンソフトウェアの「全体を最適化する」)
    • 大根が嫌い? なら千切りにして味噌汁に入れたらどうなるかな?夕飯で試そう(高速に実験&学習する)

    これらの活動を通して、苦労していたワンオペ育児もだんだんと楽しく、より良くなるように感じています。また、今までの経験・知識をワンオペ育児へ再適用することで、これまでの経験にもより深い理解にたどり着きました。

    このセッションについて

    このセッションでは、私が実際に経験した家事・育児での困難さを、自分のエンジニアリングマネージャーとしての経験から見たときにどう見立てられるのかを学び、どう戦っていったのかを話します。その中でのフィードバックループを回す中で、自分が持っているアジャイルやソフトウェアの知識もより深い理解にたどり着いたように感じたので、その学びについてもシェアします。

    アジャイルな思想や方法論をどのように適用したら良いのかがわからず困っている人がもしいれば、このセッションを聞いてみませんか? ソフトウェア開発とは全く異なる対象領域ですが、アジャイルな家事育児を通して、理論と実践、思想と方法論がコネクトできるヒントになると思っています。もちろん日々の家事・育児に悩んでいる人も参考になるTIPsが多いと思いますので、参考にしていただければ幸いです。

  • Yuya Kazama
    keyboard_arrow_down

    Yuya Kazama - 開発が加速していくために、テストコードを書き始める前から考えるべきテストの話

    Yuya Kazama
    Yuya Kazama
    QA Engineer
    BizReach Inc.
    schedule 1 year ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    システム開発において、テストは切っても切り離せない存在です。
    しかし、「カバレッジを満たすために書いている」「テストコードは書いたが、本番でトラブルが多発している」となっていませんか?
    実は、テストコードを書き始める前に既に勝負は決まっています。

    本セッションでは、実際に例題を使って皆さんにも考えてもらいます。そして、作業ではないテストについて“体験”し“実感”してもらいます。

    本セッションの体験を通じて、「開発エンジニア」「テストエンジニア」がともに考えて作り出す、一歩先行くテストの世界をご紹介します。

  • aki matsuno
    keyboard_arrow_down

    aki matsuno - コミュニティ活動で得られた知識と希望~オンライン勉強会に半年で200回参加して感じたこと~

    aki matsuno
    aki matsuno
    engineer
    -
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    完全未経験&文系でソフトウェア開発の道に飛び込んで3年半、仕事で少しずつ成果が出せるようになったものの、度重なる挫折と大きな無力感を抱いていた自分は、藁にも縋る想いでオンライン勉強会への参加を始めました。

    そこで出会ったのは、アジャイル開発をはじめとしたソフトウェア開発を豊かにする多種多様な知見と、常に変化を楽しんでお互いに刺激を与え続けているコミュニティの方々でした。

    素敵な出会いに囲まれた自分は、焦燥感から参加していた勉強会が楽しくなるばかりか、これまで嫌いだった"学ぶ"という行為が楽しく感じられるようになりました。
    気が付くと、物事を継続することが苦手だった自分は毎週勉強会に参加して毎日読書するようになり、200回の勉強会参加&100冊弱の読書をしていました。

    そして、コミュニティの方々と一緒に学びを深めるにつれ、知識が身につくのみならず"自分自身と向き合うこと"の重要性を意識するようになりました。

    今回は、自分がアジャイル開発や様々な学問から学んだ知識やもらった希望、そして自分に多数の知識と驚くほど大きなエネルギーをくれたコミュニティの方々の話をしてみようと思います。

  • Yukio Okajima
    keyboard_arrow_down

    Yukio Okajima - 成功と失敗に学ぶアジャイル受託開発の極意

    45 Mins
    Talk
    Intermediate

    特にこの数年、日本の受託開発でもアジャイル手法が普及してきている実感はあります。しかし一方、アジャイル受託開発を、日々の当たり前として定着させる難しさも見えてきました。「顧客との関係」「メンバーの育成」「事業の成長」、これらはそれぞれ長い目で取り組む必要があり、かつ相互にトレードオフを含む適応的な課題でもあります。

    例えば、次のようなシチュエーションにどのように対応すると良いでしょうか。

    • 本来なら受けがたい一括請負によるアジャイル開発を将来有望な顧客から求められたら?
    • プロジェクトがピンチ!火消しをすべきなの?チームにまかせるべき?
    • ウォーターフォールとのハイブリッドの是非について顧客とメンバーの意見が合わないのをどうすれば?

    このセッションでは、受託アジャイル開発を生業とする私たちが、成功や失敗の体験を分析することでたどり着いた「アジャイル開発の組織定着に向けた一つの型」を提示させていただきます。私の立場上、どうしても受注側の視点がメインとなってしまいますが、発注側の方にとっても、ヒントになることは多いかと思います。

  • Yuichi Tokutomi
    keyboard_arrow_down

    Yuichi Tokutomi - ゲームのように学ぶアジャイル開発

    Yuichi Tokutomi
    Yuichi Tokutomi
    CEO
    Degino Inc.
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    アジャイル開発に興味のあるみなさん、どうやって学んでいますか?

    XP の白本から始まったアジャイル開発。その後、たくさんの本が出版されてます。本に書いてあることは良さそうなのですが、実際にやろうとすると分からないことだらけだったりしませんか? スクラム開発をやってるとつもりだった自分のプロジェクトが "ミルクボーイがアジャイルを説明したら" のネタになっててハッとしたりしませんでしたか?

    そんなアジャイル開発の入り口にいる人たちに向けて、私がどうやって学んできたのか? 学び続けているのか? XP 白本の発売から 20 年の道のりをお話したいと思います。入り口から一歩進むきっかけにしていただければ幸いです。

  • Junki Kosaka
    keyboard_arrow_down

    Junki Kosaka - スクラムから見る野中郁次郎先生と組織変革

    20 Mins
    Talk
    Intermediate

    RSGT2021をきっかけに2冊の本を読みました。

    『知識創造企業』と『ワイズカンパニー』。

    この中で語られている、
    組織がよりいきいきするを、みんなで実現することに
    とても魅せられてしまい、野中郁次郎先生のファンとなりました。

    20年前に語られていた野中先生のお話を、
    スクラムを学んだ目線で読み解いてみると、
    非常に面白い要素がたっぷり詰まっていました。

    野中先生は、1986年に『The New New Product Development Game』という、
    スクラムの原点となった論文を書かれたことでも有名です。

    そんな切っても切れないスクラムと野中郁次郎先生について、
    にわかファンのJ.Kが熱狂したポイントを語り尽くします。

  • Ryuku Hisasue
    keyboard_arrow_down

    Ryuku Hisasue - 良いチームを形成する方法 〜リーダーのいない組織を大学生が挑戦〜

    45 Mins
    Talk
    Beginner

    このセッションでは,大学のPBL(Project Based Learning)でリーダーのいない組織を形成し,その活動の中でどのようにチームが成長してきたかをお伝えします.

    いま,日本の大学ではPBLという学習方法が広く実施されています.PBLとは,実際にプロジェクトチームを形成してプロダクトを作る経験を得ることによって,チーム開発やチームマネジメントの手法について学ぶことができる学習手法です.私が所属する大学でもPBLのカリキュラムがあり,スクラムを用いてプロダクトを作るという経験を得ました.しかし,私たちのチームはほかのチームとことなりリーダーを決めずに活動してきました.そして,その結果として,とても良いチームを形成できたと感じています.

    リーダーもいなく,開発初心者が集まるプロジェクトで,どのようなことに苦労したか紹介・分析し,そのうえでチームをより良くするためにはどうすればいいかお話ししていきます.

  • Takao Oyobe
    keyboard_arrow_down

    Takao Oyobe / kyon _mm / Mori Yuya / Toshiharu Akimoto - Deep Dive Experts - 達人が見ている世界を覗いてみよう -

    90 Mins
    Talk
    Beginner

    達人たちが見ている世界を覗いてみませんか

    「あの人はこの問題に対してなんて答えるんだろう?」
    「あの人はこの答えに辿り着くまでにどういう思考プロセスを経たのだろう?」
    「あの人の頭の中身が見てみたい!!」
    と思ったことはありませんか?

    同じようなプラクティスや手法を用いていても、人/チームによってまったく違う結果になります。
    つまり現場での成功には、形式的な方法だけでなく、それを扱う人の呼吸、思考、メンタルモデルが大きく影響しているということに他なりません。

    このセッションでは達人たちが見ている世界を覗いてみる実験をします。
    ある分野で研鑽を重ねる達人同士が、お互いにインタビューをすることでお互いの思考を探ります。
    ただのインタビューでは見ることができないDeepな世界にDiveしてみましょう。

  • Akiko Iwakiri
    keyboard_arrow_down

    Akiko Iwakiri / Junki Kosaka / Koji Shimada / Noriyuki Nemoto / Ryutaro YOSHIBA (Ryuzee) / Tatsuya Sato / Yasuo Hosotani / YUKI TORII / Yuko Kondo - あなたの一歩を後押しした本やあなたの手掛けた本について話してほしい!「旅するAgile本箱」LT #2021

    90 Mins
    Talk
    Beginner

    昨年のスクラムフェス大阪で好評だった「旅するAgile本箱LT」再び!

    旅するAgile本箱は、これからアジャイル開発に取り組もうとしている人たちや既に実践している人たちのために、関連書籍を段ボール2箱、会社やイベントへ貸出す活動です。 これまでに24ヶ所へ旅してきました。 本のセレクトは、アジャイル開発実践者の投票により成り立っており、含まれている本の中には、一般に「アジャイル」「スクラム」や「ソフトウェア開発」に分類されない本も混じっています。 それら含めて、この本箱にある本たちは実践者を何らかの形で助け本たちです。

    今回の旅するAgile本箱LTも、実践者の皆さんを後押しした一冊、ないしは、心震えた一冊、ご自身で手がけられた一冊、かけた思いの丈を、語っていただきます!

    ★旅するAgile本箱LT2021:発表順(予定)

    1. 前説:旅するAgile本箱って?
    2. 細谷 泰夫さん『Ultimate Agile Stories - 10th Anniversary』
    3. 根本 紀之さん 『ソフトウェアテスト技法練習帳』
    4. 鳥井 雪さん  「ダイバシティな絵本」のご紹介(順不同)
      『王さまと王さま』 『いろいろいろんなかぞくのほん』 『ふたりのママの家で』 『ジュリアンはマーメイド』 『タンタンタンゴはパパふたり』『ねえさんの青いヒジャブ』『300年まえから伝わる とびきりおいしいデザート』
    5. 吉羽 龍太郎さん「エンジニア的翻訳術」
    6. 近藤 佑子さん 「大学生に『書くこと』の授業をしたときに引き合いに出した本」
    7. 佐藤 竜也さん『達人プログラマー 第2版』
    8. 島田 浩二さん『ユニコーン企業のひみつ』
    9. 結び

    ●ハッカーライフラボスタッフ
    ・司会:コサカ ジュンキ
    ・配信:アジャイル札幌のみなさん

  • Jumpei Ito
    keyboard_arrow_down

    Jumpei Ito - アジャイル環境における品質プロセス - Janet Gregory & Lisa Crispin(動画放映)

    90 Mins
    Track Keynote
    Beginner

    テスターを含むチーム全体(Whole-Team)で、プロセスやプロダクトに品質を作り込む(Build quality in)にはどうしたらよいでしょうか。
    Janet Gregory とLisa Crispinによるこの動画では、W.エドワード・デミング氏が提唱する「ビジネス効率を向上させるためのマネジメントの原則」と、それをアジャイルな職場で実践する方法について詳しく学べます。

     

    W.エドワード・デミング氏が提唱する「ビジネス効率を向上させるためのマネジメントの原則」で以下の2つの原則はJanetのお気に入りです。

    • quality is everyone's responsibility(品質はすべての人の責任)
    • improve quality you automatically improve productivity(品質を向上させれば、自動的に生産性も向上する)

    また、Janetがオリジナルで提唱する原則が以下の2つです。

    • if you focus on quality the speed will come(品質にフォーカスすればスピードが出る)
    • if you focus on speed the quality gets lost(スピードにフォーカスすれば品質が失われる)

    アジャイル環境において品質を考えると、「プロダクト品質」と「プロセス品質」の関係が重要となります。
    JanetとLisaは以下のような内容で特にプロセス品質についてトークします。


    1.Question Askerであるべき
    2.例やテストを使って開発をガイドする
     ・magic bubble(魔法の泡) コード・テスト・自動化
     ・Acceptance Testのループ(受け入れテスト作成→テストの拡大→自動化担当者とペア→テストメソッドの作成→何をテストするのかを明確化→TDDサイクル→ハッピーパスが通るまでリピート→探索的テスト)
    3.エクササイズ(ユーザーストーリーからテストを考える)
    4.アジャイルテスティングの4象限を使ってテストを把握する
    5.探索的テスト、品質属性のテスト、スライディング・スケール
    6.コアプラクティスを使う
     ・継続的インテグレーション
     ・テスト自動化
     ・機能やストーリーの優先順位付け
     ・ビジネス価値を頻繁にデリバリー(いつでも出荷可能なリリース候補を用意する)
     ・品質をデリバリー(コアプラクティスを用いて、会社やチームのあらゆる部分で品質を構築)

     

  • Tsutomu Yasui
    keyboard_arrow_down

    Tsutomu Yasui / Yoh Nakamura - 紙芝居で2人のアジャイルコーチがScrumのあるあるをちょっとだけ語ってみる

    20 Mins
    Talk
    Beginner

    スクラムやアジャイルに初めて取り組むときにありがちなことをネタにして、2人のアジャイルコーチが、紙芝居でRPG風の物語のワンシーンを演じつつ、スクラムやアジャイルでの落とし穴について解説をします。

     

     

  • Kotoe Ishige
    keyboard_arrow_down

    Kotoe Ishige / Kentaro Masuda - 大規模な縦割り組織にLeSSを導入するまでの1年間とその後

    45 Mins
    Talk
    Beginner

    アカツキのゲーム事業では、継続的に、世界中のユーザーに最高のワクワクを届けていきたいと考えています。
    そのため、ゲーム開発においては、高品質でインパクトの大きな機能をスピーディーにリリースすることが常に求められ、必然的に組織は大規模になり、ロードマップを引いたプロジェクトマネジメントが必要になります。

    そんな中、実際のゲーム開発現場では、以下のような問題が起きていました。

    • 納期直前にエンジニアからリリースに間に合わないことが告げられる
    • 要件の変更が、プロジェクトの終盤でも発生する
    • 上記のような問題の原因を誰も理解していない

    これらの問題に対処し、継続的にインパクトの大きなリリースをするために、LeSS(Large Scale Scrum)の導入を決意しました。しかし、スクラムの知識や経験のあるメンバーが少ないこと、すでに大規模な組織であったことから、以下のステップを踏んで、導入を進めました。

    1. 「なぜLeSSに取り組むのか」をメンバーに半年かけて勉強会を実施
    2. 既存の体制を崩さないようにスクラムを一部で先行実施
    3. 体制変更を含めた、組織全体へのLeSS導入

    本セッションでは、すでに複雑な状況になっている大規模組織において、LeSSを採用した大規模スクラム体制に移行するまでの1年間と、実際にやってみた半年間についてお話します。

  • Tsuyoshi Sega
    keyboard_arrow_down

    Tsuyoshi Sega - アジャイル推進組織奮闘記 ~NTTコムウェアの場合~

    20 Mins
    Talk
    Beginner

    社内に多数のScrumチームが立ち上がっているが、Scrum間の連携の必要性がなく、各Scrumが独自に活動。その結果、質の差が大きく出たり、会社としての統制が難しかったり・・・そんな悩みはございませんか?

    弊社も同様です。弊社は社員数6000人を超えるNTTグループ会社で、もともと(今でも)WF脳の会社です。そんな会社にもアジャイル開発の波が到来しました。現在、年間数十件のアジャイル開発が立ち上がります。各開発はサービス的にはほぼ横連携はなく個別に活動をしていることが多いのが実態です。

    この状況になることは、2016年当時から予想できたため、社内にアジャイル推進組織を作りました。推進組織では、アジャイル開発が増えても最低限の開発の質を担保することや、各チームの困り事の解決のサポートと解決策の横展開を目指した活動をしてきました。

    それなりの歴史があり社員数も多い会社であるため、一筋縄ではいかず、今でも悩み多き活動です。また、推進組織のメンバもアジャイル経験の希薄なメンバの集まりという状況で活動をしてきました。推進メンバをどう育てながらどう活動してきたいのかをご紹介いたします。

  • Kentaro Arakawa
    keyboard_arrow_down

    Kentaro Arakawa - プロセス改善活動における二刀流的アプローチ

    20 Mins
    Talk
    Beginner

    プロセス改善活動において、テストの自動化や継続的デリバリーの確立などの技術的なアプローチは代表的な打ち手の一つです。

    かたやアジャイル的アプローチでプロセス改善活動を推し進める際、スクラムなどに代表される「組織の構成やそれに付随する約束事的アプローチ」に注目されがちとの思いもあります。

    今回私がプロセス改善を目的とする「SPI(Software Process Improvemnet)グループ」と、テストの自動化を推進する「Automationチーム」を兼任した1年半のプロセス改善活動で経験したことを実例を交えて紹介し、組織全体の流れに手を入れながらピンポイントで自動化エンジニアリングが出来ることの有用性や課題、展望について展開することにより、プロセス改善エンジニアの動き方の一つとして皆さまに一考していただくことを目的としたセッションです。

  • Jean-Baptiste Vasseur
    keyboard_arrow_down

    Jean-Baptiste Vasseur - リーダーとは何か、その答えをずっと探していたがCAL2を受けてやっと理解し始めた話

    45 Mins
    Talk
    Intermediate

    昨年弊社のメンバーが徐々に増えてきて、自分としてよりリーダーらしい立場と振る舞いをとっていきたいと考え始めましたが、そもそもリーダーとは何か、そこからスタートする必要がありました。

    色んな書籍やネット記事を読めば大体のことが理解できますが、相反する考え方もあれば自分としてこういうリーダーになりたいというものがちゃんとフィットするものも見つかりませんでした。

    そこで2020年9月にScrum AllianceのCAL(Certified Agile Leadership)プログラムに出逢いました。

    よし!CAL1とCAL2を取得してヒント探しに行くぞ、と。

    そして2021年4月現在、無事終わりました。確かにヒントは得られました。

    しかし、経験したこと、学んだこと、得られたものは想像を遥かに超えていました。

    皆さんにもぜひアジャイルリーダーの旅に出て欲しいという気持ちを込めて私のアジャイル・リーダー・ジャーニーを語りたいと思います。

  • Mori Yuya
    keyboard_arrow_down

    Mori Yuya - プロダクトオーナーマニアックス! POとSMの原点の原点をさかのぼって学ぶ初代主査 中村健也の働き方

    45 Mins
    Talk
    Advanced

    ■チーフエンジニアというプロダクトオーナーとスクラムマスターの原点

    スクラムではプロダクトオーナーという役割が用意されています。この役割はどのように作られたのでしょう。ジェフ・サザーランドが書いた『スクラム 仕事が4倍速くなる“世界標準”のチーム戦術』では次のように解説しています。

     プロダクトオーナーという役割は、トヨタのチーフエンジニアから発想を得たものだ。

     

    続いて、スクラムマスターの着想もチーフエンジニアからだったことが解説されます。

     チーフエンジニアはただこうしろと指示を出せばいいのではない。メンバーを納得させ、うまくその気にさせて、自分が提案するやり方が正しくベストなやり方だということを示さなければならない。普通ならその道で三十年くらいの経験がなければ務まらない役割だ。そこでこの役割を二つに分け、仕事の進め方をスクラムマスターが、仕事の内容をプロダクトオーナーが管理する分担制にした。

    もちろんチーフエンジニア以外からも参考にされたものはたくさんあるでしょうが、POとSMというアイデアに大きな影響を与えたようです。

     

    ■機能しないチーフエンジニア

    しかし、チーフエンジニア制度と半世紀近く携わり、自らもセリカ、カリーナ、スープラのチーフエンジニアであった和田明広は次のように述べています。『和田明広オーラル・ヒストリー』 から引用してみましょう。

    トヨタのチーフエンジニア制度について様々な企業から相談が持ち込まれますが、うまく機能しないことを述べています。※文中の主査は、チーフエンジニアの前の名称。

     和田 チーフエンジニアという制度はあるのですが、トヨタみたいな機能はしないのです。マーケットを見ていますけれども、新しい車をクリエイトするというようなことがなかなかできないのです。
     尾高 日本の中ではどうですか。
     和田 同じです。


    また現在のトヨタにおいてもチーフエンジニア制度は、機能しているか疑わしいと述べています。

     和田 よそのチーフエンジニアですか。でも、いまはトヨタのチーフエンジニアもそうですからね。いまはそんなに能力のある人間はいません。そんな2年や3年ちょこちょこっとやったぐらいで十分な能力ができるわけないですよ。我々だってどのくらい失敗したかわからないわけです。10年から実質的には何十年やっていますけれども、どれくらい失敗したかわかりません。

     

    ■トヨタのチーフエンジニア制度が生まれる過程

    ジェフ・サザーランドがスクラムを構築する過程にチーフエンジニア制度があったように、トヨタのチーフエンジニア制度においても過程がありました。その中で和田明広は中村健也という人物に焦点を当てています。

     松島 トヨタの場合は、なぜ他社とは異なる主査制度が生まれてきたたのでしょうか。
     和田 それは前回申し上げたかもしれませんが、中村健也さんが素晴らしい実績を残されて、会社内全体が、主査のいうことは社長の言うことだ、そういうムードになったのだと思います。

     

     尾高 外国から主査の役割についていろいろ聞いてきたとおっしゃいましたね。その結果、外国で何か起きたのでしょうか。
     和田 起きないと思います。どうしてトヨタでは主査というのがうまく機能するのか、ということですから。それはどうしてかと私に聞かれれば、それは中村健也さんから始まって全社的な組織とは違ったパーセプションを得られて、それでうまく動いているのだと説明するしかないのですけれども(略)

    ※和田明広 日本初の乗用車である初代クラウンや、初代カローラのボディ設計を担当し、トヨタで大主査と呼ばれるようになった中村健也や長谷川龍雄と共に開発をした。その後、自身もセリカ、カリーナ、カリーナED、スープラの主査(チーフエンジニアの前の名称)、またプリウスのプロジェクト責任者を担当。トヨタ副社長、アイシン精機会長、日本機械学会会長を歴任。

     

    トヨタ自動車株式会社名誉会長である豊田章一郎は『未来を信じ一歩ずつ : 私の履歴書』の中で、節をまるまる用いて中村健也を取りあげています。

     その後、1962年(昭和37年)はにモデルチェンジした2代目クラウンには、より剛性の高い「Xフレーム」を採用した。
      このときも、私は、技術部で中村さんと一緒に仕事をした。フレームをできるだけ薄くし、車高を低くすることを目指したが、X型フレームに対しては社内の反対も多く、まさに冒険そのものたった。
      テストコースの悪路耐久試験ではフレームに亀裂が生じたが、中村さんは決して諦めなかった。私は、「これが失敗したら2人で一緒に会社を辞めましょう」と言って中村さんを励ました。いつも不退転の決意で臨む中村さんも同じ思いだった。

     

     中村さんの主査としてのやり方が骨格となり、今日のトヨタのCE制度がだんだんと築き上げられ、それがトヨタの特徴となり財産にもなった。
      初代クラウンとともに主査中村健也は、いつまでも私の心に残る技術者だ。いかに情熱を持って仕事に取り組むか。そのような精神の持ち方を訓練すれば、私のような若い技術者でも大いに活躍できると思った。

    ※CE制度とはチーフエンジニア制度のこと

    いったい中村健也とは何者なのでしょうか。どのような仕事や仕事の仕方をしてきたのでしょうか。

     

     

    ■このセッションでは何をするか、何が得られるか

    スクラムのPOとSMはジェフ・サザーランドによればトヨタのチーフエンジニア制度から着想を得ましたが、和田明広によればチーフエンジニア制度は他社では積極的に導入を試みるもうまく機能しておらず、まして現在のトヨタでも機能しているか疑わしいと厳しい評価をしています。

    このセッションでは、私たちがプロダクトオーナーという役割をより効果的に果たしていくために「そもそもチーフエンジニア(主査)とはなんだったのか」を「中村健也」という人物を中心に、POとSMの原点(チーフエンジニア制度)の原点(中村健也)を70年ほどさかのぼり、プロダクトオーナーが効果的に力を発揮するための知恵を探ります。

     

     

    参考文献

    『スクラム 仕事が4倍速くなる“世界標準”のチーム戦術』ジェフ・サザーランド, 早川書房, 2015
    『和田明広オーラル・ヒストリー』 松島茂, 尾高煌之助編 東京理科大学専門職大学院MOT研究センター, 2008.12(非売)
    『未来を信じ一歩ずつ : 私の履歴書』豊田章一郎, 日経BP, 2015
    『トヨタ自動車開発主査制度』塩沢茂, 講談社, 1987(絶版)
    『主査 中村健也』和田明広編, トヨタ自動車株式会社, 1999(非売)
    『トヨタの製品開発』安達瑛二, 白桃書房, 2014
    『初代クラウン開発物語』桂木洋二, グランプリ出版, 2015(底本1991)
    『トヨタ チーフエンジニアの仕事』 北川尚人, 講談社, 2020
    『プロジェクトX 挑戦者たち われら茨の道を行く ~国産乗用車 攻防戦~』NHK

  • Hiromi Morikawa
    keyboard_arrow_down

    Hiromi Morikawa - 創業145年の日系大企業でのアジャイルへの挑戦

    20 Mins
    Talk
    Beginner

    145年の歴史を持つ大日本印刷株式会社。
    時代の変化に適応し、印刷という名前からは想像できないほど、ものからシステム、SI案件から自社事業まで幅広いものづくりを行っています。

    そんななかで新規事業のシステム開発を担う、たった5人のスクラムチームからはじまり、
    現在では会社全体になかまができ、外部コーチの力を借りながらアジャイル推進を行うまでになりました。
    新規事業の開発チームしかいなかった状況から、プラットフォーム開発や受託開発での検討の話題にもなっています。
    当初は1チームしかなかった開発チーム。チームと人材は徐々に増え、会社としての取り組みが加速しています。

    開発チーム内での実践から「アジャイル推進」へ役割を変え、
    どのようになかまを作りムーブメントを広げていったのか、大企業内で推進に向き合ってきたなかでの工夫や苦労をお伝えできればと思います。

    大きな組織のなかで試行錯誤している事例のひとつが、みなさんの参考になれば幸いです。

help