Interested心理的安全性という言葉、皆様は聞いたことありますか?心理的安全性が重要だ・心理的安全性がチームには必要だ・心理的安全性を実現しなければいけない、という意見は最近良く見聞きするようになりました。重要だし、私たちのチームでも心理的安全性を実現していく必要があるよ!」という声が帰ってくると思います。そのように答えてくれる人の頭の中にある「心理的安全性」は、果たしてあなたの考える心理的安全性と同義でしょうか?心理的安全性という言葉がキャッチー(かつ、流行っている)こともあり、言葉が先行して肝心の目的を見失ってしまっているケースも散見します。心理的安全性は、チームに属するすべての人にとって率直で安全だと思える心理状況を作り出せれば強力なツールとなり得ますが、いびつな形で運用されると逆効果にもなり得るのです。このセッションでは心理的安全性の基礎についておさらいをし、その上で陥りやすい間違った心理的安全性の認識や運用についてご紹介します。そのような間違った心理的安全性に対してどのようなリカバリーの手を打つことができるかも一緒に考えてみましょう。Audienceチームに参加するすべての人が真に安全な状態だと思えるスクラムチームを実現し、率直な対話や自発的なチャレンジから成果を出していけるようにしたいと考えているマネージャー・リーダー・メンバーが対象となります。different.あなたのScrumといえば、ソフトウェア開発での活用をイメージするでしょう。多くの日本のコミュニティで、こうした声をよく聞きます。私のイメージは、少し異なります。話して欲しい」との要望を受けました。イメージが変わるかもしれません。MinsTalkBeginnerアジャイル開発の解説はたくさんあるので、逆に、アジャイル開発になれない方法をざっくり紹介します。成功する方法を見つけるのは難しいけど、失敗する方法を知るのは簡単だったり。MinsTalkBeginnerソフトウェア開発者としてのキャリアやスキルをどのように広げていくかについて悩むことは多いと思います。日々技術は変化していっているのに自分の勉強がおいつかなくて、まわりのすごい人たちに焦り、何もできていない自分にがっかりする。自分はそんな日々を過ごしてきました。そこからほんの少しずつでも視点をずらしてジェネラリストという道を選び、ソフトウェア開発に徐々に貢献できるようになり、自信をもてるようになったことも事実です。ソフトウェア開発者として、アジャイルコーチとしてジェネラリストを選択した理由、ジェネラリストとしてやっていることなど、具体的な経験を交えながらジェネラリストとしてソフトウェア開発に貢献する方法をお話します。yattomF1のFはFeedbackのFです。アジャイルに関わる皆さんならきっと大好きなフィードバック、これを上手にできる腕を競う選手権です。この45分間のパネルセッションは、大喜利形式で行われる楽しいセッションです。アジャイル開発で悩んだり困ったりしたシチュエーションをお題として募集します。お題に対して回答者はフィードバックコメントをし、もっともナイスフィードバックと思われる回答がポイントを獲得します。ポイントの投票は回答者自身と、聴講者によっておこなわれます。高評価の観点が参加者によって醸成されていく、ダイナミックでインタラクティブなセッションです。最多ポイントを獲得した人はF1仙台グランプリの勝者となり、1年間、その栄誉が讃えられます。お題と回答の例その1お題「僕はスクラムマスターです。回答3「デプロイメント頻度は計測できていますか?」お題と回答の例その2お題「私はデベロッパーです。いつもテストをきちんとしようと思うのですが、プロダクトオーナーの期待するスピードで作ることができません。実況:ながせ(miholovesq)解説:もりや(yudmo)ドライバー(回答者):よた(yota)、てやまぐ(teyamagu)、やっとむ(yattom)、かっちゃん(katzchang)その他のドライバーにはこれから声をかけます。出走希望のドライバーも募集しています。ローカルレーサーは特に歓迎します!今回ついにローカルドライバーとして半谷さん(bangucs)がひとっ走りしてくれることになりました!!!お題は下記のフォームで募集し、当日はこの中から厳正なる抽選で採用されます。MinsTalkAdvanced毎日ふりかえりをして、毎週ふりかえりをして、自分たちのこと、チームのこと、プロダクトのことに向き合い続ける。毎回1つとて同じふりかえりはなく、その場に合わせて新しいふりかえりが自然発生し、チームによって生み出されていく。いったふりかえりを全力で行い、プロダクトを全身全霊で作るうちに、ふりかえりが日常に溶けていく。そんなチームが出来上がるまでの2年間をふりかえると、ふりかえりだけでない、いろんな要素が絡み合っていました。ふりかえりを楽しむということ。チームの文化を作り続けるということ。ひとりひとりのオーナーシップ。メンバーそれぞれの価値観の共有。みんなが大切にしている想い。ゴールをともに作り上げ共有すること。このセッションでは、ふりかえりを日常とするチームができるまでを「プロダクトオーナー」という観点でふりかえり、それを再現するために必要だった要素をお伝えします。マネする必要は全くありませんが、少しでもふりかえりを身近に感じられたり、ふりかえりの周辺にある何かを感じ取っていただけたら嬉しいです。MinsTalkIntermediateエンジニアとしてアジャイルなものづくりをし続けるためには、それを実現するだけのスキルが必要です。そのスキルのひとつは"技術スキル"であり、私自身の弱さとなっている部分であり、向き合わなければいけないものでした。あなたはどんな理由で、アジャイルを探求したり、スクラムを実践したり、コミュニティで学びを深めたりしていますか?アジャイルの考え方が好きだったり、自分たちの開発に悩みを抱えていたり、より良い価値をユーザに届けたかったり、その理由は人それぞれだと思います。私がアジャイルに興味を持ったのは、本質を突き詰めていくような考え方に深く共感し、自分たちもそんな風にものづくりをしたい、と思ったのがきっかけです。思想を持ちながら、書籍、コミュニティ、カンファレンスでその理解を深めていくことで、本質的に価値を届けていくことはできる、と思いながら新天地へ足を踏み入れた私は、しかし思うように動けませんでした。そこには、アジャイルのことはよく知らない、と言いながら自分なんかよりもよっぽどアジャイルな人たちがいました。実践する前にアジャイルの思想を知り、頭の中で理想の世界が膨らみ続けていた私が、いざ実践となった時に突きつけられた「自分の弱み」の話をします。MinsWorkshopIntermediateチームが一致団結して開発する日々の様子を、メンバーの立場から体験できるボードゲームを作りました(作っています)。以下のような和やかなやり取りをしながら進めるゲームです(予定です)。「依頼してよかったですよ、ありがとうございます。「楽しく仕事しましょうね、楽しくね」4人1グループで、90分~2時間くらいかけて遊ぶゲームになりそうです。仙台では、オンサイトで会場に集まってボードゲームを遊ぶ予定です。各プレイヤーは、開発チームのメンバーとして、自分のスキルを表す手札を持っています。ボード上にはタスクカードが並んでおり、自分のスキルでこなせるタスクを選び案件として実施すると、開発が進みます。開発を進めるとチームは3種類の報酬を得ます。プロセス改善やリファクタリングによる作業効率化メンバーは一人ひとり異なった「勝利条件」を持っています。あるメンバーはひたすら成長にコミットしており、別のメンバーは自分のスキルにしか興味がなく、また別のメンバーはプロダクトがバランスよく成長しながら社会に貢献することをモチベーションにしている。自分の勝利条件に近づくようにタスクを選んで案件を実施ししましょう。1人でできる仕事は僅かです。スポンサーの要求はどんどん高まっていき、チームが協力して開発しなくてはクビになってしまいます。チームとして案件を成功させながら、いかにして個々人の勝利条件を追求するのか。チームとしてのコミュニケーション、作戦、そして駆け引きがこのゲームの醍醐味です(予定)。ゲームの準備の都合で、参加者は最大12名の予定です。見学だけの参加も可能です。やり方があると思いますが、今回は私たちのチームで実施している方法を紹介します。ポイントはソフトウェアを"作る前”と”作った後”にあります。私たちのチームでは作る前に「リファインメント」、作った後に「受け入れ」(独自イベント)を実施し、認識を合わせることで、1つひとつのPBIの抜け漏れを少なくしています。リファインメント言わずとしれたリファインメント。このイベントにはDEV、PO、QAが参加し、以下のような項目についてスプリント開始前に話します。PBIのゴール設計方針テストの方針+影響範囲POはPBIの意義、開発からは設計方針、QAは必要最小限なテスト、ソフトウェアアーキテクチャー上の影響範囲などについて話しながらPBIの輪郭をハッキリさせていきます。受け入れ私たちのチームでは独自のイベントとして開発のテスト終了後、受け入れというイベントを実施しています。こちらもリファインメントと同様にDEV、PO、QAが参加しています。POは出来上がったものに関して問題ないか、開発は実装時に変更したところ、困ったところ、テスト結果について、QAは実装時の変更による影響、追加で必要なテストはないか、を認識合わせしていきます。お気づきでしょうか?DEV、PO、QAはアジャイルテスティングの文脈ではスリーアミーゴスと呼ばれています。見ると「実装」がスリーアミーゴスでサンドされています。自分は心の中でスリーアミーゴスサンドと呼んでいますが、今までチームメンバーに話したことはありません。墓場まで持っていくつもりでしたが、第2の故郷の仙台でお話したいと思います。スリーアミーゴス実装スリーアミーゴスこのスリーアミーゴスサンドにより、以下のことを防ぐことができます。MinsTalkBeginner東京理科大発(理科大VC出資)ベンチャーShinonome(https://shinonome.io/)を学生創業してから、はや6年。現在では、全国の大学と提携をして大学生にIT実践教育の仕組みを提供できるようになり、500名以上のエンジニア・デザイナーを教育・輩出しています。創業期は...「金がないので、寸胴で炊き出し?!」「20時間/312日、開発体制!?」ソフトウェアとの出会いから、学生起業、今に至るまで赤裸々なストーリーをお話しします。Teamsによると「安定したチームほど良いパフォーマンスを発揮する」とあります。嬉しくもあり、残念でもあるのですが、チームでの活動がうまくいった結果、プロダクトが成長し、ビジネスが成長すると、どれだけ今のチームが素晴らしくても、チームを大きくする力がどうしても働き始めます。すると、いつまでも安定したチームで居続けられなくなるのもまた事実です。安定したチームがよいパフォーマンスを発揮するとはわかっていても、なかなか許してもらえない。Reteamingより、チームをダイナミックにリチーミングするための5つの方法を、実際に現場でチームと関わるなかででてきた事例とともにご紹介します。MinsTalkBeginner今日は本を読むぞと決めたけど、結局ゲームをやってしまった体重を減らさないといけないのだが、ついつい夜中にカップ焼きそばを食べてしまった貯金をしたいのに、欲しいものがあると思わず買ってしまうこのような冷静に考えるとやらないほうが良いことを、思わずやってしまった経験はないでしょうか?私はあります。した経験をすると、自分の意志の弱さを感じて、嫌になったりもします。おいて重要なのは、いかに目的に対して合理的な決定ができるか、であって、たとえば、確率的により高いものを選んだり、認知バイアスの影響を減らした決定をできるか、といったことかなと思っています。例として、サイコロで1の目が連続で出続けた後に再び1が出る可能性を低く見積もる「ギャンブラーの誤謬」であったり、得することよりも損をすることを回避した意思決定をしてしまう「プロスペクト理論」などが挙げられます。したバイアスの影響を認識した上で、何回1が出た後でもサイコロの1は次も1/6の確率で出るのだと捉えて合理的な選択が出来ることが重要なわけです。このような合理性を求める意思決定理論から考えれば、冒頭に挙げたような非合理的な行動は愚の骨頂とも言えるような振る舞いだと感じてしまうのですが、一方で、「なぜ人間はそんな行動をやりたくなってしまうのだろうか」という疑問も湧くのです。本当に必要がないのなら、進化の過程でそういう感情が滅びても良いのではないでしょうか。した非合理的な行動を説明する理論として「双曲割引」という考えがあります。私は、この考えを学んで、非合理的な行動にも実は意味があるのだなと感じました。非合理的な行動を合理的な行動に変えていくことも必要ではありますが、ある程度非合理的な行動をすることも必要なのだと分かりました。にんげんだもの、です。このセッションでは、前半でこのような意思決定理論を学んで私が考えたことをお話させてもらった後に、後半では私の話を聞いてどう感じたかを参加者の方同士で話し合ってもらうことを考えています。私が何か正解や答えのようなものをお伝えできるわけではないので、あなたの普段の意思決定をふりかえってみたり、参加者同士で非合理な意思決定の必要性について話合ってみたりすることで、何かの気付きや学びに繋がっていくことを期待しています。MinsTalkAdvancedみなさん、こんにちは!アジャイルコーチの清水弘毅です!日本在住だとおそらく3人ほどしかいない、CTC認定をスクラムアライアンスから受けています!本セッションでは、スクラムマスターやアジャイルコーチの方の、必要なスキルの探求をしていきます。私自身がどんな場面に遭遇し、どのように考え、どのような道を辿ってきたかお伝えしますので、スクラムマスターを極めたいと考えている方たちの一助になれば幸いです。CECで求められるコンピテンシーに照らし合わせながらお話する予定です。MinsTalkBeginner私は筑波大学の情報系の学生です。3年生の春から、enPiTを通してアジャイル、スクラムを学んでいます。3年生の秋に、新しくチームを組み開発を始めることになりました。ここで珍しかったのが、そのチームのチームメイトは全員スクラムを知らなかったということです。そんなチームで、私がスクラムマスターとなり、スクラムをはじめました。その過程から「スクラムのはじめかた」を紐解いていきたいと思います。MinsTalkBeginner当初講演予定のRyuzee不在につきプレゼンター変更でお届けします講演者の代打として、miholovesqによるryuzeeのモノマネパワポカラオケ(コーラス:haradakiro)でお送りします。Dive」が聴けることを期待しつつ......、それでは聴いてください。(シリーズなのか)前回のプロダクトバックログ(https://slide.meguro.ryuzee.com/slides/107)に引き続き、今回はスプリントプランニングのすべてを完全解説!!スクラムにおいて、スプリントの開始時にまず行うのがスプリントプランニングです。従来型のプロジェクトにおける失敗理由の多くが出だしで躓いたせいだと考えると、スプリントの最初のイベントであるスプリントプランニングも重要であることがわかります。ここで計画づくりに失敗してしまうと、インクリメントを届けられず、スプリントレビューは針の上のむしろになり、スプリントゴールも達成できなくなってしまいます。一方でスクラムガイドを見ると、扱うべき3つのトピックは明記されているものの、具体的なやり方や手順は書かれていません。結果的にスクラムの価値基準や原則にそぐわないことをしてしまっている例も散見します。以下の項目のいくつかは、一般的に望ましくないとされています。どれが望ましくないものか考えてみてください。BOOKも是非読んでみてください)、陥りがちな罠は避けられます。Alliance認定スクラムトレーナー(CST-R)、認定チームコーチ(CTC)の吉羽が体系的に解説します。望ましくないものは、(c)以外のすべてです。MinsWorkshopBeginnerスクラムガイド2020年版において「完成の定義」のアイデンティティが明確になりましたが、活用イメージがついていない方もいらっしゃるのではないでしょうか。Done)の理解を助けるワークショップを作りました。スクラムチームにおける役割や職種、スクラムの経験年数に関係なく、どんな方でも参加いただけると思います。みんなでワイワイ楽しみましょう!※基本的にオンラインで進行しますが、希望が多ければ、オンサイトでの同時進行も行うかもしれません。直前のご案内で申し訳ありません。こちらのセッションは「オンサイト開催」となりました。私たちは、これまで外側の世界に対してなにか働きかけをしなければいけない、と考えて改善を行ってきました。本当に私たちが向かうべきは外側ではなく内側だったのです!!本講演は、NVC(非暴力コミュニケーション)、ザ・メンタルモデルの知見から、主にスクラムマスターの内側の世界(感情、ニーズ、痛み)に目を向けます。生命的な進化を遂げる組織の人間関係において必要とされるのは、表面的なコミュニケーションテクニックではなく、他者に対する理解や共感です。これまでアジャイルに20年間向き合ってきて到達したいきいきとしたチームの結論が、自己理解に基づく個人の変容です。ついての概要、なぜチームの生命構造を生み出すのに自己理解が必要なのかの説明した後、実際に自己理解を体験するためのワークを行います。行っていく上でのポイントをお伝えします。MinsTalkBeginner自分が所属するUnipos株式会社では、「感情報酬を社会基盤に」というミッションを掲げてUniposというソフトウェアを開発しています。1年半前、自分はみんながもっと楽しく開発できるように、従来型の開発プロセスを変えようとトップの人に直談判を試みます。自分が変革をはじめる最初の一人でした。初学者でしたが書籍から学び、知識は万全。なんとかすると前のめりでした。ところが、憧れた会社や書籍のようにうまくいきませんでした。そこにはシンデレラストーリーがあるのではなく、ただただ現実的な問題ばかりがありました。その問題の乗り越え方は書籍には載っていません。自分で悩み考え、取り組んでみて学習する必要があります。形式知ばかりを学び、「最初の一歩」を実践したことのなかった自分は見事に頭でっかちになっていました。頭ごなしに知識を押し付けたところで、とうとう組織の支援を受けることはできませんでした。初学者が組織の変革をはじめる最初の一人になる場合、経験したことがないため乗り越えられないような問題が出てくることがあります。考えると、むしろ最初は組織から協力を引き出せないほうが、自然なのではないでしょうか。初学者が組織の変革をはじめるべきではないのでしょうか?自分はそんなことはないと思います。最初の一人が躓いたとき、その後の歩みを止めないためにできることは何でしょうか。このセッションでは、組織を変革する最初の一歩の道のりをふりかえり、自分が学んできたことをご紹介します。なにぶん昔のことなので、思い出せないところもありますが、書籍には載っていないような自分の実践から学んだお話をご提供できれば幸いです。コミュニケーションがあるところには、かならずあることです。リーダーからメンバーへフィードバックする機会もあります。トレーナーとして、受講者にアドバイスするのもフィードバックなら、受講者からトレーナーが学ぶのもフィードバックです。立場と関係なく、自分が感じたり考えたりしたことを共有し、相手からも教えてほしいというのも、またフィードバックの話です。いざ学ぼうと思って探してみても「上司が部下に言うことを聞かせるため」系の本しかありませんでした。Feedback』に出会いました。ワインバーグ先生ならきっといいことが書いてあるに違いない!と考えて、英語の本に取り組むため仲間を集め、定期的な読書会形式で進めることにしました。1年4ヶ月の読書会を経て、私たちはこんなふうに理解できました。すべてがフィードバック、なんでもフィードバック。テクニックとしてではなく、人の心の働きに立ち戻り何が起きているのか分析する話です。フィードバックとは、しようと思ってするわけではなく、すべてがフィードバックです。フィードバックは受け手の話ではなく、与え手を表現することです。フィードバックは一方通行のコミュニケーションではなく、複雑な相互の継続的プロセスです。フィードバックでは自分自身を大事にすることが大切です。フィードバックは適切に、客観的に、わかりやすくすれば伝わると思ったら、大間違いです。「フィードバックください!」とよく言ったり言われたりしますが、実は......みんなでこうした理解に到達できたのは、単に英文を読み解いてというだけではなく、文意について意見交換をしたり、自分の体験にもとづいた捉え方を話し合ったり、ふりかえりをしたりしたおかげです。そこでこの読書会の体験と書籍の内容をセッションで共有したいと思います。本の内容と読書会の体験について、読書会メンバーが対談・パネルセッションでわいわいします。実際の読書会の場面を切り取るような内容も、話せるかもしれません。MinsTalkBeginner私は、悩んでいました。アジャイルコーチを名乗っているのですが、コーチングができているかわからないんです。学んでいますし、超優秀なコーチから継続的にコーチングも受けています。現場で行っているコーチングが、コーチングになっているかどうかの判断がつかないのです。まわりを見ると、第一線でキラキラと輝くアジャイルコーチたちが活躍をしています。自分はいつも、悩んでいました。そんなある日、コーチングセッションでコーチから提案を受けました。当初は、1ヶ月で20個、現場でやってみたことを書いてみる予定でした。やってみると、1週間で50個を超えました。今は、3週間で100個を超えました。「デイリーミーティングでは大きな声で挨拶する」のような、簡単なものもあります気づかず繰り返しでやっているものもあります。中には、やってみて、傷つくような失敗になったものもあります。思いがけずに、素敵な結果に結びついたものもあります。すると、僕がやりたいことはこういったことが積み重なった先にある、小さく始めるアジャイルコーチの提案なのではないか、と思い始めています。発表では、私が日々現場でやってきたことを抜粋して紹介します。繰り返し現れたものや関係性があるものなど、パターンの抽出にも手をつけてみようと思います。