location_city Niigata schedule May 20th 04:25 - 04:45 PM JST place NINNO3  RoomD people 5 Interested

いざ!新しいプロダクトオーナーまたは開発者、またはスクラムマスターを迎えてスクラム開発しよう!

と、した時に

皆さんは新しいメンバーに「うちのスクラム開発はこのようにやってるよ!」とどのように伝えていますか?

私たち東京海上日動システムズでもスクラム開発を実践しており、日々新しいメンバーが参画してきますが、

「うちのスクラム開発のやり方」についてはチームに合流して体感しながら習得していくスタイルが主でした。

これはこれで、対話重視のチームへの受け入れ方として大事にしているスタイルではあるものの、以下のような悩みもありました。

  • スクラムガイドに沿ってと言われたけどガイドにない部分はどうしているか分からない
  • メンバー変更で隣のチームに来たらやり方が違うから混乱する
  • スクラムマスターによって方向性、レベルがばらつく

もちろんそれぞれチームのビジョンやプロダクトの特性、歩んできた歴史があり、それを否定することはありません。

ただ、POがチームにビジョンを示すように、組織として目指しているスクラムの姿を伝えるものがあってもよいのではないか、と感じ、スクラムチームの指針となる「スクラムコンパス」を作成しました。

アジャイルコーチのRedHatさん、社外のスクラムマスターの方々、東京海上日動システムズ社員のスクラムマスター、総勢15名で集まり、一つ一つの項目について議論して作りあげました。

スクラムコンパスをつくるに至った背景、作る過程、作った成果物をお話しします。

 
 

Outline/Structure of the Talk(Online Only / オンラインで発表します)

  • スクラムコンパスを作成することになった背景
  • スクラムコンパスを作成で行ったこと
  • スクラムコンパスの全容
  1. スプリント開始
  2. 各役割
  3. 各イベント
  4. 各作成物

コンパスの一部をご紹介‥今回は「各作成物」をご紹介します。

 □プロダクトバックログ(プロダクトゴール)

 □スプリントバックログ(スプリントゴール)

 □インクリメント(完成の定義)

  • スクラムコンパスを使用してみた結果

 

Learning Outcome

私たちのスクラムコンパス

Target Audience

スクラム開発をしたい方  スクラム開発をしている方  スクラムチームが複数ある組織の方

Prerequisites for Attendees

特にありません!

schedule Submitted 6 months ago

  • Daniel Maslyn
    keyboard_arrow_down

    Daniel Maslyn - Reaching the “Big Picture” In Testing and Quality / テストと品質における「全体像(ビッグピクチャー)」への到達

    Daniel Maslyn
    Daniel Maslyn
    IT Consultant
    N/A
    schedule 7 months ago
    Sold Out!
    90 Mins
    Keynote
    Beginner

    “When one looks to closely one sees too much,  When one looks from far away one does not see enough, When one learns to look from the right distance, one sees the solutions”  Maslyn - 2023

    Our profession has no set rules. Shouldn’t it have something common to all practitioners though? There are methods and processes but there is no one method that can claim to be complete and take the place of common sense. One must learn to master their own ship of testing based on their natural talents for curiosity and experimentation tempered with smart choices in their years of experiences both positive and negative that shaped their learning process. I know of no one who said when they were little, they wanted to grow up to be a “tester” but I know many who found themselves in the situation to take on a massive responsibility to test systems which our fellow human beings rely upon and interacts with for mission critical processes day in and day out. Good testing is not easy. If it were, solely automated tools and machines would already be doing it. The real act of testing and quality management still requires the ability to focus sometimes quickly and efficiently one the smallest of details while still being able to in an instant zoom out and not lose the forest through the trees.  How can we develop this “Testing Zoom” ? How do we take what seems like a show stopping defect with no solution or a lack of test data methods that present a possible show stopping issue an project defect and turn it into an opportunity and victory and even learn to improve in our automation, tools and skills to tackle harder and more difficult problems? We need to learn to work as a team and have a vision that is calibrated to take in the entire picture and the various aspects which are not just technological but very human indeed. You cannot learn this “test zooming” in a book. It comes from experience and sharing with others lessons learned in a way that builds up both a personal and a common archive of experiences. If it were possible to condense all of these collective these years of learning across decades into one book or one method or one lecture, the craft would not be worthwhile. Instead, it must be introduced and the mind and body must be trained over the years not unlike learning a martial art or music instrument. Testing is a craft that requires skill and trial and error. This requires sometimes following a strict set of rules and methods and then requires the tester to be willing to engage their intuition and senses and logic in many ways they probably never thought they were capable of. Sometimes these talents only come out when one is facing what seems like a seemingly insurmountable testing task or challenge. Only then does the testers innate skills come to bear. Testing and a true Quality Mindset require a living and learning approach that is not only based on tools and methods and context but also on empathy and adjusting the “zoom” and focus of your efforts to the right distance to get the needed balance and understanding of “the big picture”. But what is the “big picture”? Is it just the territory of the projects we find ourselves tasks with carrying out or is it sometimes in the greater whole of our societies and world where we have chosen to fulfill the testing roles we have to carry out? Why do some thrive in these roles and others seems to only endure them? And how does knowing how to learn this talent of seeing the whole and the parts as one develops. This session will explore these questions and hopefully give you the answers for yourself. Let’s reach for the big Picture together.

    「近くから視ると多くを見すぎ、遠くから視ると十分に見えず、適切な距離で視ることを学ぶと、解決策が見つかる」ダニエル・マスリン - 2023

    私たちの職業には決まったルールがありません。しかし、すべての実践者に共通する何かがあってもいいのではないでしょうか?手法やプロセスはありますが、完全であると言い切れる、常識に代わる方法はありません。

    人は、好奇心と実験に対する生まれつきの才能を、長年の経験の中で鍛え、自分自身のテストという船を使いこなすことを学ばなければなりません。そして、その学習プロセスを形成した、肯定的、否定的な両方の経験の中で賢い選択をします。

    幼い頃から「テスターになりたい」と言う人はいないでしょう。しかし、私は、毎日毎日ミッションクリティカルなプロセスに依存し、相互作用するシステムをテストするという、大きな責任を引き受ける状況にある人にたくさん出会ってきました。

    G.O.O.Dテストは簡単ではありません。もしそうなら、自動化されたツールや機械がすでに行っているはずです。テストや品質管理には、時には素早く、時には効率よく、細かいところまで集中し、時には瞬時にズームアウトし、木を見ながらも森を見逃さない能力が必要なのです。

    この「Testing Zoom」をどのように開発すればよいのでしょうか?解決策もなく、テストデータの不足もあり、プロジェクトの欠陥となりうるような、目も当てられないような不具合を、どのようにしてチャンスと勝利に変え、さらに自動化やツール、スキルを向上させて、より困難で難しい問題に取り組めるようになるのでしょうか?

    私たちは、チームとして働くことを学び、全体像と、技術的な面だけでなく人間的な面も含めたさまざまな側面を取り込むための調整されたビジョンを持つ必要があるのです。この 「Testing Zoom」は本では学べません。 もし、こうした長年の学習を本やメソッド、講義に凝縮することが可能なら、この技術に価値はないでしょう。代わりに、武術や楽器の習得と同じように、導入して何年もかけて心と体を鍛えなければならない。そのためには、時には厳しいルールやメソッドに従った上で、直感や感覚、論理を駆使して、自分では思いもよらなかったような方法で挑戦することが求められます。

    このような才能は、一見すると乗り越えられないようなテスト作業や課題に直面したときに初めて発揮されることがあります。その時初めて、テスターの生来のスキルが発揮されるのです。

    テストと真の品質マインドセットは、イキイキと学ぶアプローチを必要とするのです。ツールやメソッドやコンテキストに基づくだけでなく、共感し、必要なバランスと「全体像(ビッグピクチャー)」の理解を得るために、自分の努力の「ズーム」と焦点を適切な距離に調整することでもあります。

    しかし、「全体像(ビッグピクチャー)」とは何でしょうか?それは、私たち自身が遂行しなければならないプロジェクトの領域だけなのでしょうか?それとも、私たちが遂行しなければならないテストの役割を果たすことを選択した社会や世界のより大きな全体像のことなのでしょうか?なぜ、このような役割の中で成功する人もいれば、耐えるだけの人もいるのでしょうか?そして、全体と部分を見渡す才能を身につけるにはどうしたらよいのでしょうか?このセッションでは、このような疑問について探求し、できれば皆さん自身がその答えを得られるようにしたいと思います。

    一緒に全体像(ビッグピクチャー)へ到達しましょう!

  • 45 Mins
    Talk(Online Only / オンラインで発表します)
    Advanced

    「_ _ 、_ _ 、_ _ 、_ _ 」_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ?

    参考 : 【0文字クイズ】クイズ王、文字がなくても正解できる説

    みなさんはどれくらいアジャイルテストを知っているのか?すっとその知識を出せるのか?不安になったり、どうやって成長すればいいのか悩んだりしたことがあるかと思います。

    資格取得、読書、ワークショップ、業務での取り組みさまざまなものがありますが、その中でもライトに取り組めるのがクイズです。今回はみなさんにアジャイルテストのクイズを出してその知識や引き出し方を確認してもらえればと思います。

    当日は10問前後からなる問題をだしてDiscordで最も早く回答してくださった方を勝者とします。また誤答によるペナルティはありません。

  • Yusuke Uchida
    keyboard_arrow_down

    Yusuke Uchida - 相互理解を目指す対話主体のコミュニケーションで心の負担を軽減し持続可能な組織変革を

    45 Mins
    Talk(Onsite / 現地で発表します)
    Beginner

    組織変革を試みると様々な壁にぶつかる

    より良いソフトウェア開発のため、より楽しく仕事をするためにと情熱を持って組織変革を試みると、様々な壁にぶつかることは少なくないと思います。

    人と人とが関わる中で異なる意見に出会うことは避けられません。なんでわかってくれないんだろうかとしんどくなります。同じように悩んでいる人にもよく出会います。

     

    アドバイスをもらうも理解しきれなかった

    一方で、まるでしんどくないかのように活動し続けているように見える人もいます。苦しい場面に出会わないのでしょうか、彼らは超人だから壁にぶつかっても、ものともしないのでしょうか。

    相談してみるとそんなことはないようで、コミュニティで色々なアドバイスをもらい、それらをまとめて発表させてもらう機会もありました。

    しかし彼らのアドバイスだけでは、まだ自分のしんどさは解消しきれませんでした。

    「他人を変えることはできない、変えられるのは自分だけ」

    と聞いても、それは自分の夢や理想を諦め、情熱を捨て我慢するということなのかと悩んでいました。当時の自分は、彼らの言葉を表面的に捉えることしか出来ていませんでした。

     

    アドバイスをどのように理解することができたか

    そんな中

    • 「誰もが正しい、ただし部分的には」(『SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意 メタスキル、学習、心理、リーダーシップ』)

    というアジャイルの基本姿勢、対話の考え方に出会い、さらにその具体的な方法として

    • 「表現の奥に隠れているニーズを理解する」(『NVC 人と人との関係にいのちを吹き込む法』)
    • 「想定や関係情報を揃える」(『ファシリテーター完全教本: 最強のプロが教える理論・技術・実践のすべて』)

    にも出会い、相互理解を目指す対話主体のコミュニケーションで心の負担を軽減できることに気づきました。

    以前コミュニティでもらっていたアドバイスを見返すと、その裏のロジックを理解することが出来ました。

     

    そしてここにマインドフルネスを組み合わせると効果が高まることにも気づきました。

    対話を心がけていても、意見の異なる相手の言動によってはついついファイティングポーズをとってしまう瞬間もあります。少しでもその拳を上げずにおくために、心の情動を抑え対話を続けるためにマインドフルネスが役立つのです。

     

     

    情熱を持って組織変革を試みる人はとても貴重です。

    そんな人が心の負担で押しつぶされないために、自分の情熱を諦めるのではなく、異なる意見と対面した時の捉え方、コミュニケーション方法を変えることで心の負担を軽減できた例をお話ししたいと思います。

  • amix edcolor
    keyboard_arrow_down

    amix edcolor - 夢に挑むことは難しい、でも、諦めたくない 〜あなたの背中を押すセッション〜

    amix edcolor
    amix edcolor
    Engineer
    Relic Inc.
    schedule 7 months ago
    Sold Out!
    20 Mins
    Talk(Onsite / 現地で発表します)
    Beginner

    このセッションは、夢に挑み続けるamixedcolorが、なぜ挑み続けられているのかについて熱弁して、あなたの背中を押すセッションです。あなたが夢について考えるきっかけを作ります。夢に挑むことは難しいです。でも、諦めたくない。あなたの夢はどんな夢ですか?あなたは夢を諦めたことがありますか?夢を諦めたとき、それは諦めたくて諦めたわけじゃないと思います。

    もう一度あなたが夢に向かって歩き出すために。しのび足でも、すくみ足でもいい、もういちど夢をみて、夢に挑むために。このセッションがあなたの背中を押します。

    なぜこんな話をするのか と思うでしょう。夢を諦めた人の背中を押せなかったことが悔しいからです。今、やりたいことがあるのにそれができなくて、諦めてしまう人がいる世界を変えたいからです。誰しもに機会があり、やりたいことをやれる世界を実現したいからです。僕の最も身近にいた母は、僕が最もよく知る夢を諦めた人です。母は言いました。「今はあなたもパパもいるし、そもそも私は平凡なんだから」と言いました。それに言い返せなかった自分が悔しいです。

    ではどうやって背中を押すのか については、僕が挑み続ける中で見つけたことを話します。かくいう僕も、夢に挑み、苦難しました。自分の夢はこれでいいのか、この夢を自分に叶えることはできるのか、今自分がやっていることは、本当に夢につながるのか。何度も不安に思いました。それでも挑み続けました。

    見つけたことは何か、何を話すのか。 僕は3つの要素を見つけました。1つ目は、自分の夢の根源にあるものを見つけること。2つ目は、夢の実現方法は1つではないと知り方向転換をすること。3つ目は、これまで歩いてきた道を夢に向かっている道にすることです。

    夢を諦めたとき、諦めたくて諦めたいわけじゃないでしょう。でも諦めなくていいんです。夢はそのまま追っていいんです。いつでもあなたは夢のために進んでいるんです。

    本当に?

    でも難しい?

    そんなあなたの背中を押します。

  • Takao Oyobe
    keyboard_arrow_down

    Takao Oyobe - いきいきした受託開発をするためにアジャイルチームができること

    45 Mins
    Talk(Online Only / オンラインで発表します)
    Intermediate

    受託開発と聞いてどのようなイメージを持っているでしょうか?

    %E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88-2023-01-19-18.03.38.png

    私はこれまで自社開発に携わってきたので、受託開発に興味を持っていませんでした。
    それでも耳に入ってくる「受託開発」の情報は、ネガティブでつらそうなものが多かったです。

    私たちSilver Bullet Clubは、2022年7月に株式会社ホロラボにチーム転職をしました。
    ホロラボはXRの技術を得意とする会社で、受託開発をメインとしています。
    私たちは転職をして、受託開発に取り組むことになりました。

    そこで、受託開発について学ぶために、「受託アジャイル勉強会」というコミュニティを立ち上げました。
    さまざまな受託開発経験者の方と議論を重ねて、受託開発とアジャイル開発について知見を交換したり、受託開発の未来について熱く語っています。

    それらのヒントを糧に、チームで受託開発に取り組みはじめ、いくつかのプロジェクトに携わりました。
    やってみてわかったことは、確かに受託開発ならではの制約はあるものの、これまでチームで取り組んできて大切だと思っていたことはそれほど変わりませんでした。よいビジネスをつくるために、会社を超えてワンチームをつくり、受託開発でも今まで通り楽しくアジャイル開発をしています。

    このセッションでは、自分たちの経験を元に、受託開発でも前向きに仕事をしていくために、アジャイルチームができることについてお話します。もちろんビジネスを成功させるためには、経営や組織の協力は不可欠ですが、チームでできることもたくさんあります。

    もちろん受託開発にもアジャイル開発にもこだわる必要はありません。
    しかし、このセッションでは受託開発×アジャイル開発に敢えてフォーカスをして、建設的に考えていきたいと思います。

  • Atusuke Muratra
    keyboard_arrow_down

    Atusuke Muratra - チームの成長を促すためにふりかえりの改善に本気で向き合った話

    Atusuke Muratra
    Atusuke Muratra
    Engineer and Scrum master
    Cybozu
    schedule 6 months ago
    Sold Out!
    20 Mins
    Talk(Onsite / 現地で発表します)
    Beginner

    皆さんのチームではどのようなふりかえりを行なっていますか?そのふりかえりはチームの成長につながる場として機能していますか?

    ふりかえりを導入して最初はうまくいっていたのに、気がついたら「ふりかえりやめません?」という雰囲気になっていたことはありませんか?

    チームが課題を解決して成長するにつれて、扱う問題や課題発見の難易度は上がります。課題やアイデアを発見できなかったり、問題解決に向かう施策が立てられない状況に陥ると、チームはふりかえりに対して疑いの目を向けるようになります。「効果の出ないふりかえりを続ける必要はありますか?」メンバーからふりかえりの意味を問われたとき、あなたならどのようなアプローチを試みますか?私はふりかえりの改善と向き合いました。

    このセッションではチームの成長に伴いふりかえりが形骸化するメカニズムと、形骸化したふりかえりを効果のあるふりかえりに改善するために取り組んだことを紹介します。皆さんのふりかえりの場がより良い形になるように、自分が知り得たこと、経験したこと、すべてお話しします。

  • Takefumi Iseki
    keyboard_arrow_down

    Takefumi Iseki - 保守 (Ops) の保守改修プロセス構築記

    45 Mins
    Talk(Onsite / 現地で発表します)
    Beginner

    昨今ではアジャイル・スクラム開発で新規開発、バグ・仕様変更などの開発を同チームで行うことも多いかと思います。

     

    B2B の、とあるパッケージ製品を開発していますが、新規開発と保守(バグ修正、仕様変更、そしてリリース作業)と完全にラインが分かれている分業スタイルの部署となっている 保守チームとしての保守改修プロセスの構築の取り組みをお話ししたいと思います。

     

    バグや仕様変更のプロセスとしてはなんとなく存在し、暗黙知として実施されておりました。品質の視点・視野に入れた改修はしておらず対処療法としてバグ修正を行っていた経緯があります。

     

    サポートの調査などにも追われていたため開発プロセスの定義などに手付かずのところがあったようですが、テスト設計も約 4 年前にサンプルとしてテンプレートを出したもののアップデートされておらず、おおよそ CPM 法 (仕様書の語尾を~できることと変えたテスト設計) になっており自分たちが望んでいるものを提供している状態とは言えませんでした。

     

    サポートチームも組織的に分離したため、これを機に新規開発 (Dev) で開発プロセスを定義をしてきた実績をもとに DevOps となるべく保守 (Ops) のプロセスの定義と構築を行っていこうと考えました。

     

    モダンな開発プロセスで保守 (Ops) だけ切り離されたチームというのは、サイロ化を無くそうという意味で昨今あまり聞かれませんが、バグ・仕様変更に対してどのように品質を考慮して修正・テストしてリリースをしていくかを話していこうと思います。

  • Masami Morita
    keyboard_arrow_down

    Masami Morita - QAはチームの外から支援するのか?中から支援するのか?

    45 Mins
    Talk(Onsite / 現地で発表します)
    Intermediate

    近年、1人目QAとして活躍される方が増えてきました。1人目として行ったことの事例もweb上で見かけることも増えました。次なる関心はその先の話です。

    今回は、2年目に行った取り組みのうち、開発支援にフォーカスします。(支援とは主に、テストスコープの決定、結合テストの設計・実行の支援を指します)

    「QAはチームの外から支援するのか?中から支援するのか?」私が感じたそれぞれの支援のメリット・デメリットを、体験談を交えながらお話します。

    • はじめに
      • QA組織立ち上げ2年目の概要
      • QA活動の4本柱
      • QA組織体制
    • スクラムチーム内/外からの支援のメリット・デメリットと事例紹介
      • 私が感じたそれぞれの支援のメリット・デメリット
      • 内からの支援 成功例
      • 外からの支援 成功例
      • 外からの支援 失敗例
    • まとめ
  • Junki Kosaka
    keyboard_arrow_down

    Junki Kosaka - 起きてからじゃ遅い。組織で一番悲痛な声が聞こえる場所

    20 Mins
    Talk(Onsite / 現地で発表します)
    Advanced

    昨日まで一緒に頑張っていた仲間がいて
    ある日突然、バランスを失ってしまったこと、ありませんか?

    組織で誰かを
    信用できなくなったり
    尊敬できなくなったり
    頼れなくなったり

    そんな時、あなたはどうしますか?

    誰かに相談、したいですか?

    本当の声は、第三者や相談窓口には聞こえてきません。
    組織内に受け取れる場所がなければ、悲劇は突然訪れるだけです。

    組織がこんなギリギリの状態にならない方が良いのは間違いありません。
    一方で、瀬谷さんのお話は身近なところでも起きてしまっていると感じてもいます。

    このセッションでは、
    自分の辛かった体験をベースに
    機械的ではない組織の作り方についてお話します。

  • Eisuke Tomita
    keyboard_arrow_down

    Eisuke Tomita / Narumi Yanagi - ふりかえり初心者が急に毎日ふりかえりをやってみて、気づいたら1年経って元気になっていた

    20 Mins
    Talk(Online Only / オンラインで発表します)
    Beginner

    みなさん、毎日ふりかえりやってますか?

    去年のふりかえりカンファレンス 2022 で、『実録!ふりかえりを60日間続けると人はどう変わるのか?ふりかえりをふりかえり!』という発表がありました。
    その発表を聞いて、自分たちもやってみると何かあるかも!?となったので、毎営業日に集まってふりかえりをすることになりました。

    参加メンバーはアジャイル推進室のえーちゃんとふりかえり初心者の人事のねこやなぎさん + Gather で集まったゲストさん。
    ふりかえりカタログから引用してやってみたり、自分たちで新しいふりかえりを考えてみたり。
    もし今日がうまくいかなかった時も、1日の終りに少しだけいいことが見つかるように、明日を楽しく過ごせるようにといったテーマを持ちつつ
    各々が今日1日のふりかえりをやっていました。

    最初は1~2ヶ月続けばいいかなと思っていたら、半年・1年といつのまにかふりかえりしないと落ち着かない習慣となってきました。
    そして仕事の中でもちょっとずつ変化が起こって、「ポジティブさ」や「前向きに」働くコツがつかめてきたのです。
    今回は、1年続いたコツというより、1年間やってみた自分たちの変化や気付きをメインに発表します!

    当日は見せられる範囲で実際に私達が使っている Miro なども公開していこうと思います!

  • Keita Watanabe
    keyboard_arrow_down

    Keita Watanabe - チーム作りにおいて、小さな声を聴くことの重要性に気づいた話

    45 Mins
    Talk(Onsite / 現地で発表します)
    Intermediate

    チーム作りにおいて、たとえば、小数の意見。ひとりの感想。感情。そういう小さな声には、注目していなかった。

    大事なものではある。けれど、プロダクト開発という大きな流れを見たときに、それらは大勢に影響を及ぼすものではないと思っていた。

    プロセスやフレームワークが適切であれば、チームはうまくまわる。そう考えていた ──

     

    システムコーチング®のトレーニングを受け、そうした小さな声を聴くことの重要性に気づいた。そんなお話しです。

    ソフトウェアに何かエラーが起きたとき、(ちゃんと作られていれば)エラーメッセージが出ます。それによって、どこに異常があるのか、どう対処すればいいのかが分かります。

    チームも同じです。小さな声、声にならない声は、チームから出ている何かしらのメッセージです。システムコーチング®とは、そのメッセージの意味を明らかにし、チームの変容、適応、問題解決をうながすアプローチです。

    システムコーチングの概要や肝になる考え方を紹介するとともに、今のぼくが見えている、小さな声を聴くことの重要性・可能性について、アジャイルの観点も混ぜながら語ろうと思います。

  • Emi Kobayashi
    keyboard_arrow_down

    Emi Kobayashi - 観察から対話へ 〜人類学の知恵を借り、よりチームに、自分に向き合おう〜

    Emi Kobayashi
    Emi Kobayashi
    Scrum master
    株式会社yamaneco
    schedule 6 months ago
    Sold Out!
    45 Mins
    Talk(Onsite / 現地で発表します)
    Beginner

    「観察さえ上手くなれば、もっとチームのことを理解できるはずだ!」

    6ヶ月前の私は、そう考えていました、、、

    このセッションでは、6ヶ月間人類学のゼミに参加した経験をもとに、人類学的視点がどのようにチーム支援に立つかをお話します。

    支援する立場として感じた効果は、下記のようなものです。

    • チームメンバーと向き合い、チームで起きていることに気がつくことがよりできるようになる
    • チームで起きていることに向き合い、受け入れることができるようになる
    • 自分の持っている思考の偏りやフィルターに自覚的になることができる

    また、チームの支援を行う立場にいなくても、自分のいるチームをより良くしたいと思う人が、実際に働きかけを行う時に人類学的視点がどのように効果を発揮するか、私の経験を交えてお話します。

    自分のいるチームをより良くしたいと思うする立場として感じた効果は、下記のようなものです。

    • 始めるべき難しい会話を始める勇気が出る
  • Kei Ogane
    keyboard_arrow_down

    Kei Ogane - 「アジャイルって品質悪いんでしょ?」って言われた時に送りつける用登壇資料(仮)

    Kei Ogane
    Kei Ogane
    Engineering Manager
    for Startups, inc.
    schedule 7 months ago
    Sold Out!
    20 Mins
    Talk(Onsite / 現地で発表します)
    Beginner

    過去、SIer時代に「アジャイルって品質悪いんでしょ?」って言われてカッとなって作った資料を元にブラッシュアップして発表したいです。
    基本的な内容はスライド欄にその当時発表した資料があるのでそちらをご参照下さい。

    Web系プロダクトの開発に従事して得た経験が反映されると思います。

  • aki matsuno
    keyboard_arrow_down

    aki matsuno - 競技人口100万人以上のゲームで世界一を取った人間がN=1で語るメンタルヘルス

    20 Mins
    Talk(Online Only / オンラインで発表します)
    Advanced


    学生時代にゲームに明け暮れていた自分は、競技人口100万人以上の2つのゲームで世界一を獲得することができました。
    ここで世界一を獲得した際に自分が大事にしてトレーニングを重ねていた要素は幾つかあったのですが、その中の一つにはメンタルヘルスがありました。

    本発表では、このメンタルヘルスについて以下の観点で話をしてみようと思います。

    • ストレスとの付き合い方
    • いわゆるフロー状態を呼び覚ますためにやっていたこと
    • 自分が独自に実施していたメンタルヘルストレーニング

    自分はメンタルヘルスの専門家でもないですし過去の話なので記憶が美化されている可能性も高いため、真似をしようとかこれが正解だとかは考えず、Advancedセッションとして楽しんで聞いてもらえると幸いです。

  • Masami Morita
    keyboard_arrow_down

    Masami Morita / chinatsu mikami - デザイナー × QA 対談 ! スクラムチームにどう入り込んでいる?

    45 Mins
    Talk(Onsite / 現地で発表します)
    Beginner

    複数案件に関わっているという共通点を持つ、デザイナーとQAエンジニア。

    現在、デザイナーは主に要件から仕様固め&UIUX設計を行っています。QAは主にテスト計画やテスト設計・実行のサポートを行っています。

    もっとコラボしたいと思いつつも、スクラムと関わるフェーズが異なるため、これまであまり絡んでこれなかった2人が、スクラムチームへの関わり方について語り合います。

    様々なロールの人がいるスクラムチームですが、デザイナーとQAがどのような悩みや課題を抱えているのかを聞いていただき、ご自身のスクラムチーム運営のヒントとなったら嬉しいです。

  • kobase 555
    keyboard_arrow_down

    kobase 555 - Agile Tasting ~わいわいテイスティング~

    kobase 555
    kobase 555
    Software Engineer
     
    schedule 7 months ago
    Sold Out!
    45 Mins
    Workshop(Onsite / 現地で発表します)
    Beginner

    お酒やソフトドリンクを飲みながら、みんなでわいわいしましょう!

help