歴史に学ぶ、ダメダメ開発兵器 (もしスクラムみたいな開発をしたら。。。)

皆さんは、歴史上にダメダメな開発経路をとった兵器があるのをご存じですか?

中には傑作機、名機と言われた兵器もありますが、私から言うと、こんなダメ兵器よく開発したな (使っていたな) っと思うことあります。


当時の開発状況を詳細に知ることは難しいですが、当時の状況から、おそらくこんな開発していたんじゃないか?
という推測をもとにしてダメダメ開発で生まれた兵器について語ってみたいと思います。

そして、歴史に「もし」はないのですが、自分だったら、こんなことやっていたんじゃないかなということも話してみたいと思います。


歴史は温故知新となる宝石箱です。
歴史を知り、失敗を考え、現在の自分の状況に照らし合わせて将来につなげていければいいかなと考えています。


皆さんでタイムスリップして歴史のジャーニーをしてみませんか?

 
 

Outline/Structure of the Talk

  • はじめに
  • 現場 (戦場) にそぐわなかった残念な銃
  • 失敗できないから欠陥をひた隠ししていたあの有名な戦闘機
  • いろいろ悩んで設計やり直していたら既に時代遅れでフルボッコなヤワラカ戦車
  • リリース急ぎすぎて、リスク考えなかった空母の末路
  • 自由 (すぎる) な発想、そして実験って大事だよね
  • おわりに

Learning Outcome

ダメダメプロジェクトのあるあるで、そんななか生まれた残念な兵器たちを知れます。

Target Audience

ダメダメ開発での出来事、そして自分たちの状況と合わせて何をしたらいいかを考えてみたい人

schedule Submitted 9 months ago

  • Ikuo Odanaka
    keyboard_arrow_down

    Ikuo Odanaka - R&Dチームが歩むスクラム守破離ジャーニー

    20 Mins
    Talk
    Beginner

    R&D(研究開発)チームは常に不確実性と向き合っているため、アジャイル/スクラムを取り入れることは必然のように思えます。
    私が所属するR&Dチームや隣のR&Dチームもスクラムに取り組み、自分たちで働き方を問い直しながら変化し続けるようになっています。
    今ではスクラム導入前にどう働いていたのか思い出せないほどにチームに浸透しています。
    新しく配属された新人は、このやり方こそがスタンダードだと感じています。

    しかし、最初から難なくスクラム開発に取り組むことができたかというと、そうではありませんでした。
    スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブ…
    スクラムイベントの名を冠する予定は定期的に開催されていたものの、そこに透明性はなく、よって検査と適応もない状態でした。

    形だけのスクラムがもたらした閉塞感から脱却し、透明性・検査・適応によって変化していくために実施したこと。
    取り組む中でどのような壁にぶつかり、どう適応し変化していったのか。いつ自分たちの開発スタイルに自信を持つことができたのか。
    そして、今はどこに向かっているのか。

    現在進行形の現場から、チームの学びと成長をお届けします。

  • Makoto Iguchi
    keyboard_arrow_down

    Makoto Iguchi - セキュリティとアジャイル開発のいい関係について考える / Security and Agile Development

    20 Mins
    Talk
    Intermediate

    The presentation will be given in Japanese. I've uploaded the (partially) translated version of my slides at https://www2.slideshare.net/makotoiguchi/how-to-balance-between-security-and-agile-development for your reference.


    2018年12月頃に掲載された「アジャイル手法でのセキュリティは困難」というタイトルの記事において、某セキュリティ会社のCTOは「高速のCI/CD(継続的なインテグレーション/デリバリー)においてセキュリティ上の問題が浮上しても、その解決に当たる余裕や時間がないままに事態が進行してしまうようなことが往々にしてあり、現場が混乱する」とした上で、結果として「DevSecOps、NetSecOpsが、現実にはうまく機能しない」という見解を示しました。

    これは本当なのでしょうか?
    もし本当だとしたら、それは悲しいことなのではないでしょうか?

    一方、2019年8月に掲載された "Your security team is probably an infuriating obstacle - but it doesn't have to be this way" という記事においても触れられているように、開発者側より「セキュリティは、DevOpsやアジャイルな開発スタイルにブレーキをかける存在である」といった声を聞くことがよくあります。

    これは正しい姿なのでしょか?
    セキュリティとアジャイル開発は、水と油の関係なのでしょうか?

    このセッションでは、ISMS内部監査責任者とスクラムマスターを兼任している立場の人間から見た、セキュリティとアジャイル開発の「あるべき姿」についてお話します。また、現在行っているセキュアなアジャイル開発の実現へ向けた実験(The Elevation of Privilege: Threat Modeling Card Deck を活用したセキュリティ問題の洗い出しとプラニング)をご紹介します。

    参考)The Elevation of Privilege: Threat Modeling Card Deck を日本語化&いらすとや化したもの。こちらの Github レポジトリで公開中です。

    EfOaaY7VAAE6AW7?format=jpg&name=medium

  • Masanori Kawarada (Mark Ward)
    keyboard_arrow_down

    Masanori Kawarada (Mark Ward) - [Online Interpretation] 独立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:

    「Scrum@Scale(S@S)を取り入れた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 Scrum@Scale, 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.

  • Rochelle Kopp
    keyboard_arrow_down

    Rochelle Kopp / Tatsuya Kinugawa - Bilingual cross-cultural discussion 日本人と外国人のディスカッション: How to accelerate the adoption of agile and scrum in Japan? 日本でのアジャイルとスクラムの導入をどう加速すれば良いか?

    100 Mins
    Workshop
    Beginner

    This session is an opportunity for Japanese and non-Japanese to exchange ideas about the challenges of implementing agile and scrum in Japan, and brainstorm about how to work together to overcome them.

    RSGらしい国際交流の場をTokyoでも。こちらのセッションでは、日本におけるアジャイルとスクラムの導入をどうすれば加速できるかについて日本の方々と外国の方々にご参加いただき議論できればと思っています。RSGTにご参加の皆様は耳を疑うかもしれませんが、我々2人は今もなお外国の方々から「日本ではなぜアジャイル開発がスタンダートではないのか」「アジャイル開発を導入したいが様々な課題に直面している」という相談を受けることがあります。この課題には実は二つの異なる要素が包含されているように感じています。一つは、日本、ひいてはアジア諸国における文化的なハードルによる難しさ(いわゆる異文化交流の難しさ)、もう一つは、日本の企業体制におけるアジャイル導入のハードルによる難しさだと思います。

     

  • Ryo Tanaka
    keyboard_arrow_down

    Ryo Tanaka - フィールドワーカーから学ぶアジャイルコーチとしての生き方のすゝめ

    20 Mins
    Talk
    Advanced

    民族誌学/エスノグラフィーのフィールドーワーカーから学ぶアジャイルコーチとしての生き方。

    フィールドワーカーとは他の文化圏、他の民族の中に入り、中からそのシステムを観察し、何らかの研究結果を出していく仕事です。
    外部アジャイルコーチは、NOT SCRUM 文化圏や伝統的IT文化圏の中に入り、中からそのシステムを観察し、何らかの変化をシステムに与えていく仕事です。

    観察し、解析し、なんらかの仕事をする。このサイクルはかなり共通点が多いと考えています。
    アジャイルコーチもフィールドワーカーも「カルチャーショック」を潜り込んだ先で受けますし、相手側は「フィールドワーカーショック」をフィールドワーカーから受けます。コーチの場合は「アジャイルコーチショック」とでもいうのか。その場合の影響の最小化の仕方、最大化の仕方。記録のとどめ方。

    また、アジャイルコーチもフィールドワーカーも人間ですから、段々と精神が不安定になってくることもあります。その場合の乗り切り方(例えば「正直な日記」の書き方)。うまくいってる時はいってる時で、どのような観察をフィールドワーカーとしてすべきなのか?(厚い記述と薄い記述の話)。

    等々、フィールドーワーカーから学べる事は非常に多いと考えています。 

  • manami Ozawa
    keyboard_arrow_down

    manami Ozawa - 自分のチームについて改めて考える時間を作ろう

    manami Ozawa
    manami Ozawa
    Freelance
    Freelance
    schedule 9 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    「なぜあなたはスクラムをやりたいのですか?なぜやった方がいいと思っているのですか?」

    ふと組織支援の場面でこの問いを投げかけたことがあります。
    スクラム・アジャイルで開発していくことがいいと思う理由をチームに伝えることはできているでしょうか。
    そして、導入していくにはチームにあったやり方、ステップを考えることができているでしょうか。

    私は1on1ミーティングを外部の立場から行うなど、職場のコミュニケーションに特化して組織を支援しています。
    一見、1対1のコミュニケーションだから、チームと離れる印象をもつかもしれません。
    でも仕事を行う以上、人と関わるのは必然。複数人行ううちに共通の課題も見えてきます。

    今回お話するのは、職場のコミュニケーションに特化した組織支援の中で
    いくつかの現場で共通して見えたチームに対するすれ違い、考えの違いを紹介して行きます。

    あなたのやりたいこと、得意なことはチームに伝わっていますか?
    あなたはチームメンバーのやりたいこと、得意なことを知っていますか?
    チームとして目指す方向性ややっていきたいことの認識はあっていますか?

    チームをどう見ているかはあなたしか知らない。
    だからこそ、あなたにあったやり方でチームをいい方向に持っていくお手伝いができたらと思っています。

    XP祭りで登壇した内容をもう一歩進めてお話できたらと思います。
    参考までにXP祭りでお話した資料を添付します。

    slide.png

  • Jumpei Ito
    keyboard_arrow_down

    Jumpei Ito - テスト設計コンテストでAgile Testingしてみた結果

    Jumpei Ito
    Jumpei Ito
    QA Engineer
    WingArc1st Inc.
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    テスト設計コンテストに初参加し、アジャイルにテスト設計をしてみた結果を共有します。

    http://aster.or.jp/business/contest.html

    アジャイルは何も開発プロセスだけでなく、色々なプロジェクトで適応でもるものです。今回、テスト設計コンテストに初参加し、スクラムでテスト設計を実施した時の気付きと学びを共有します。

     

  • Kei Nakahara
    keyboard_arrow_down

    Kei Nakahara / Stefan Nüsperling - 変化に適応する組織のつくり方!Management3.0 実践ワークショップ

    45 Mins
    Workshop
    Beginner

    ビジネスの急速な変化に適応すべく、多くの企業でデザイン思考やスクラムの導入が進んでいます。しかし、新たな体制や進め方を導入してもなかなか効果が出ないのが実際ではないでしょうか?例えば、能力も経験も何の支援も無く「明日から君がスクラムマスターだ」というような無茶ぶり。チームに権限委譲されているはずなのに、いつも細かく口出しする上司。このような経験をお持ちの方は少なくないのでは?この原因の1つとして、組織マネージメントの方法やマインドセットが従来から変わっていない事があげられます。デザイン思考やアジャイルを導入しても従来通りの組織マネージメントとマインドセットでは、効果は薄れてしまいます。このような問題の1つの解としてManagement3.0というマインドセットがあります。本ワークショップではManagement3.0の基本的な考え方と、具体的なプラクティスを用いたワークショップを実践形式でお伝えします。参加されるみなさんに「今日から」使える考え方とプラクティスを持ち帰って頂こうと思います。

    追記:2020/09/22 エンタープライズアジャイル勉強会で中原が開催したワークショップに加えてTeamへの権限委譲と育成の観点を加えて100分で実施する予定です(10/12 追記)     参照:https://easg.smartcore.jp/C22/notice_details/V2p0V1lRTTQ=

  • Ryo Tanaka
    keyboard_arrow_down

    Ryo Tanaka - Tour de Scrum 2021 -スクラムを会社でやっていくのは耐久レースだ !-

    20 Mins
    Talk
    Intermediate

    Scrum を会社の中の1チームが始める時、その瞬間から組織全体変革の問題が始まっています。Scrumがあなたの会社にとって革新的なものであるとき、Scrumをチームに適用して改善していくことには、暗黙的に会社組織全体の改善も含まれています。それを理解しないままスタートした、もしくはしようとした、企業のサポートに何度かアジャイルコーチとして立ち会いそこから得た学びを共有します。Scrum するなら会社ごとやる覚悟を持って、覚悟持てないなら、社員の献身を犠牲になんとか半年以内に決断して、Scrumは目的じゃないし手段だけど、それを言えるのはきっちり向き合っている人だけです。

    • 事例1:某大規模NOT IT企業、チームレベルでの大成功と会社のビジネスに届かない話
    • 事例2:某大規模伝統的IT企業、異文化との交流を覚悟を持って挑んだ話と、その覚悟が部署内で閉じてた話
    • 事例3:某大規模IT企業、現場にScrumを適用する話と、現場にしかScrum適用していない話

     

     

  • Koki Kawagoi
    keyboard_arrow_down

    Koki Kawagoi - スクラムマスターの任命&育成法の紹介 〜学習科学に基づいた解説を添えて〜

    20 Mins
    Talk
    Advanced

    皆様は、組織でスクラムマスターをお願いするときに困ったりしていませんか?
    また、スクラムマスターが、成長していると感じますか?

    多くのチームの見てきましたが、スクラムマスターの任命時から育成において
    うまく仕組みが作れている組織はあまりありません。

    スクラムマスターの任命にうまくいかなかったり、育てられないと、
    スクラムチームのアウトプット・アウトカムの向上がすごく遠回りになってしまいます。

    そこで、これまで私が実施してきた方法を学習科学の観点から解説しながら、
    スクラムマスターとしての任命から育成の方法について紹介します。

    %E5%86%99%E7%9C%9F%202020-09-29%2017%2047%2004.png

    育成したスクラムマスターの事例はこちら。

    スクラムマスター上田さんによる「スクラムマスターとして気づいたこと」の講演資料

    同じシリーズのチーム育成編はこちら

    XP祭りでの発表:コードレビュー地獄から抜け出すためのペアプロ育成法〜学習科学の視点から〜

  • Takefumi Iseki
    keyboard_arrow_down

    Takefumi Iseki - QA がスクラムマスターっぽい役割をしてみた話

    45 Mins
    Talk
    Beginner

    開発モデルが、いまどきV字型をとっているというと驚かれるかもしれませんがスクラムどころかアジャイル開発型にもなっていない開発現場です。

    このような組織では、上流から要求が出てきたものを実装しテストをしてリリースをするだけとなり、「どうしてこのような機能にしたの?」と聞かれても
    「仕様書に○○と書いてあったから」というだけの説明がほとんどででした。


    また、言われたこと以外は実装せず (実装してミスをするとさらに問題になるので冒険はしない) 「仕様書に書かれていないから」という保身的な状態も多くありました。

    さらに、ふりかえりも (ほぼ) なく (あっても名ばかり) で案も出ずに、結局根性論に落ち着いて、全く改善につながらない状態でした。

    よって、仕様の限定範囲での意見や改善はありましたが、おおよそは、指示待ち設計、指示待ち開発、指示待ちテストという状態でした。


    これでは、価値を創造し顧客へ提供するという概念がなく、結局、価値が低い (品質が低い) 製品となり、技術者も新しい知識や情報を取得せず、製品も技術者も「緩やかに死ぬ」危機感を覚えていました。

    そこで、価値を創造できるような開発チームになるように、この V 字型の開発手法において、QA がスクラムマスターっぽい役割となり開発チームのマインドセットを変え、要求分析/要件定義をはじめ、設計、コーディング、テストのプロセスの変更、そしてふりかえりからの継続的なプロセス改善に取り組んでみました。

    要件定義においては、ステークホルダー分析から始まり、品質特性などから、それぞれの人が本当に欲しい機能はなんだろうということを考えることから始めました。
    さらにユーザーストリーマッピングの考え方も取り入れて、どういう使われ方をするのかを考えるプロセスも取り入れました。

    設計やコーディングにおいては、開発者、テスターの全員でモブ設計を行い、多様な意見を交流できるようにして、様々な機能の必要性を検討するようにしました。

    テストにおいては、開発者がテストをする大切さを説き、テストファーストの概念でテストコードを書く習慣に変えようとしています。

    また、プロセス全体としてふりかえりを行い、新しい手法や考えを取り入れていき改善していくことを考えていけるようにしていきました。


    そんな QA が思考錯誤しながらスクラムマスターっぽいことをやってみた奮闘記をお話しをしたいと思います。

     
     
  • ゆうすけ おおひら
    keyboard_arrow_down

    ゆうすけ おおひら - 混沌し続けるコミュニティの話

    45 Mins
    Talk
    Beginner

    こんにちは、世界。

    はじめまして。テストの街「葛飾」というコミュニティを運営している おおひらです。

    テストの街「葛飾」は、
    2019年の終わりにいつもの寿司屋で、悩み多きQAとテスターのこんな会話から始まりました。

    「勉強会とかイベントって渋谷とか新宿で東京の東側は少ないよね」
    「無いなら自分たちで作りましょうか」
    「せっかくだから、ソフトウェアテストで葛飾区を盛り上げるようなことがしたいっすね」

    そんな中、
    世間は、 COVID-19 が感染拡大し、オフラインでイベントをすることが難しくなり、他と同じく私たちはオンラインでイベント「大人のソフトウェアテスト雑談会」を開催することにしました。

    ただ、私たちがイベントのコンテンツとして選んだのは、「雑談」。

    よくあるLTやワークショップをせず、ただ参加者同士が会話するのみのイベントです。

    これは、絶対的な正しさがない世界で、参加者同士が対話することで、何らかの気づきを得てもらい、少しでも楽しく生きてもらいたいという願いから決めました。

    (本当は発表するコンテンツもコネもない苦肉の策でもありますが)

    雑談の内容は、開発、テスト、プロセスなどのソフトウェア開発についてであったり、葛飾の美味しいお店、はまっているゲームの話、人生とは?というようにお互いに相談しあったり、見地を披露したりとさまざまです。

    このイベントは、4月中旬から毎週開催しており、現在20回を超えました。
    (9月末現在)

    誰も来ない時もあるけど、誰も拒まず、参加した人が少し楽しくなるイベントを開催し続けています。

    そんな、あえて説明しずらいカオスなイベントを私たちがどのように考えて続けていているかの話をします。

help