概要

心理的安全性という言葉、皆様は聞いたことありますか？

心理的安全性が重要だ・心理的安全性がチームには必要だ・心理的安全性を実現しなければいけない、という意見は最近良く見聞きするようになりました。

あなたが所属するチームで、メンバーに「心理的安全性は重要だと思う？」と聞けば、恐らく殆どの場合「当然。心理的安全性は重要だし、私たちのチームでも心理的安全性を実現していく必要があるよ！」という声が帰ってくると思います。

しかし、そのように答えてくれる人の頭の中にある「心理的安全性」は、果たしてあなたの考える心理的安全性と同義でしょうか？心理的安全性という言葉がキャッチー（かつ、流行っている）こともあり、言葉が先行して肝心の目的を見失ってしまっているケースも散見します。

心理的安全性は、チームに属するすべての人にとって率直で安全だと思える心理状況を作り出せれば強力なツールとなり得ますが、いびつな形で運用されると逆効果にもなり得るのです。

このセッションでは心理的安全性の基礎についておさらいをし、その上で陥りやすい間違った心理的安全性の認識や運用についてご紹介します。

そして、そのような間違った心理的安全性に対してどのようなリカバリーの手を打つことができるかも一緒に考えてみましょう。

開催年月 開催地 チャンピオン
2022年6月 大阪 yattom
2022年5月 新潟 yattom
2022年1月 お茶の水 yattom

F1のFはFeedbackのFです。
アジャイルに関わる皆さんならきっと大好きなフィードバック、これを上手にできる腕を競う選手権です。

この45分間のパネルセッションは、大喜利形式で行われる楽しいセッションです。

アジャイル開発で悩んだり困ったりしたシチュエーションをお題として募集します。お題に対して回答者はフィードバックコメントをし、もっともナイスフィードバックと思われる回答がポイントを獲得します。
ポイントの投票は回答者自身と、聴講者によっておこなわれます。
高評価の観点が参加者によって醸成されていく、ダイナミックでインタラクティブなセッションです。
最多ポイントを獲得した人はF1仙台グランプリの勝者となり、1年間、その栄誉が讃えられます。

お題と回答の例その1
お題「僕はスクラムマスターです。上司がチームのパフォーマンスを気にしているので、ベロシティのグラフを見える化してみたんですが、どうでしょうか？」
回答1「上司にベロシティについての理解を問うてみてはどうでしょうか？」
回答2「ベロシティは顧客価値につながる指標なんでしょうか？」
回答3「デプロイメント頻度は計測できていますか？」

お題と回答の例その2
お題「私はデベロッパーです。いつもテストをきちんとしようと思うのですが、プロダクトオーナーの期待するスピードで作ることができません。正直毎スプリントこんなにきっちりテストをするなんて足枷に感じてしまうのですが、どうしたらいいでしょうか」
回答1「テストをサボるとその足枷がどんどん重くなるのでは？」
回答2「一度テストをまったくしないで進めてみてはどうでしょうか？」
回答3「プロダクトオーナーを説得する役割の人はいないのですか？」

出演者の情報です。
実況：ながせ（miholovesq）
解説：もりや（yudmo）
ドライバー（回答者）：よた（yota）、てやまぐ（teyamagu）、やっとむ（yattom）、かっちゃん（katzchang）
その他のドライバーにはこれから声をかけます。
出走希望のドライバーも募集しています。ローカルレーサーは特に歓迎します！

今回ついにローカルドライバーとして半谷さん(bangucs)がひとっ走りしてくれることになりました！！！

お題は下記のフォームで募集し、当日はこの中から厳正なる抽選で採用されます。
https://forms.gle/oFih3o1mk6P8gTGK8

エンジニアとしてアジャイルなものづくりをし続けるためには、それを実現するだけのスキルが必要です。

そのスキルのひとつは"技術スキル"であり、私自身の弱さとなっている部分であり、向き合わなければいけないものでした。

あなたはどんな理由で、アジャイルを探求したり、スクラムを実践したり、コミュニティで学びを深めたりしていますか？

アジャイルの考え方が好きだったり、自分たちの開発に悩みを抱えていたり、より良い価値をユーザに届けたかったり、その理由は人それぞれだと思います。

私がアジャイルに興味を持ったのは、本質を突き詰めていくような考え方に深く共感し、自分たちもそんな風にものづくりをしたい、と思ったのがきっかけです。

思想を持ちながら、書籍、コミュニティ、カンファレンスでその理解を深めていくことで、本質的に価値を届けていくことはできる、と思いながら新天地へ足を踏み入れた私は、しかし思うように動けませんでした。

一方そこには、アジャイルのことはよく知らない、と言いながら自分なんかよりもよっぽどアジャイルな人たちがいました。

実践する前にアジャイルの思想を知り、頭の中で理想の世界が膨らみ続けていた私が、いざ実践となった時に突きつけられた「自分の弱み」の話をします。

いろんな痛みを伴ったので正直言語化するのもちょっと辛いですが、アジャイルであり続けるために頑張ります！！

「アジャイルチームで品質を作りこむ」
色々やり方があると思いますが、今回は私たちのチームで実施している方法を紹介します。

ポイントはソフトウェアを"作る前”と”作った後”にあります。私たちのチームでは作る前に「リファインメント」、作った後に「受け入れ」（独自イベント）を実施し、認識を合わせることで、1つひとつのPBIの抜け漏れを少なくしています。

### リファインメント

言わずとしれたリファインメント。このイベントにはDEV、PO、QAが参加し、以下のような項目についてスプリント開始前に話します。

• PBIのゴール
• 設計方針
• テストの方針＋影響範囲

POはPBIの意義、開発からは設計方針、QAは必要最小限なテスト、ソフトウェアアーキテクチャー上の影響範囲などについて話しながらPBIの輪郭をハッキリさせていきます。

### 受け入れ

私たちのチームでは独自のイベントとして開発のテスト終了後、受け入れというイベントを実施しています。こちらもリファインメントと同様にDEV、PO、QAが参加しています。
POは出来上がったものに関して問題ないか、開発は実装時に変更したところ、困ったところ、テスト結果について、QAは実装時の変更による影響、追加で必要なテストはないか、を認識合わせしていきます。

お気づきでしょうか？
DEV、PO、QAはアジャイルテスティングの文脈ではスリーアミーゴスと呼ばれています。
良く見ると「実装」がスリーアミーゴスでサンドされています。
自分は心の中でスリーアミーゴスサンドと呼んでいますが、今までチームメンバーに話したことはありません。墓場まで持っていくつもりでしたが、第2の故郷の仙台でお話したいと思います。

• スリーアミーゴス
• 実装
• スリーアミーゴス

このスリーアミーゴスサンドにより、以下のことを防ぐことができます。

• 作ってみたら変なモノができていた（修正）
• テストが足りていない（追加）
• お互いに期待値に達していなくてイライラする

スリーアミーゴスサンドぜひお試しを！

• 今日は本を読むぞと決めたけど、結局ゲームをやってしまった

• 体重を減らさないといけないのだが、ついつい夜中にカップ焼きそばを食べてしまった

• 貯金をしたいのに、欲しいものがあると思わず買ってしまう

このような冷静に考えるとやらないほうが良いことを、思わずやってしまった経験はないでしょうか？私はあります。こうした経験をすると、自分の意志の弱さを感じて、嫌になったりもします。

行動経済学などの文脈で、「意思決定理論」という考えがあります。私が知っている範囲では、「意思決定理論」において重要なのは、いかに目的に対して合理的な決定ができるか、であって、たとえば、確率的により高いものを選んだり、認知バイアスの影響を減らした決定をできるか、といったことかなと思っています。

例として、サイコロで1の目が連続で出続けた後に再び1が出る可能性を低く見積もる「ギャンブラーの誤謬」であったり、得することよりも損をすることを回避した意思決定をしてしまう「プロスペクト理論」などが挙げられます。こうしたバイアスの影響を認識した上で、何回1が出た後でもサイコロの1は次も1/6の確率で出るのだと捉えて合理的な選択が出来ることが重要なわけです。

このような合理性を求める意思決定理論から考えれば、冒頭に挙げたような非合理的な行動は愚の骨頂とも言えるような振る舞いだと感じてしまうのですが、一方で、「なぜ人間はそんな行動をやりたくなってしまうのだろうか」という疑問も湧くのです。本当に必要がないのなら、進化の過程でそういう感情が滅びても良いのではないでしょうか。

こうした非合理的な行動を説明する理論として「双曲割引」という考えがあります。

私は、この考えを学んで、非合理的な行動にも実は意味があるのだなと感じました。もちろん非合理的な行動を合理的な行動に変えていくことも必要ではありますが、ある程度非合理的な行動をすることも必要なのだと分かりました。にんげんだもの、です。

このセッションでは、前半でこのような意思決定理論を学んで私が考えたことをお話させてもらった後に、後半では私の話を聞いてどう感じたかを参加者の方同士で話し合ってもらうことを考えています。

私が何か正解や答えのようなものをお伝えできるわけではないので、あなたの普段の意思決定をふりかえってみたり、参加者同士で非合理な意思決定の必要性について話合ってみたりすることで、何かの気付きや学びに繋がっていくことを期待しています。

当初講演予定のRyuzee不在につきプレゼンター変更でお届けします

講演者の代打として、miholovesqによるryuzeeのモノマネパワポカラオケ（コーラス：haradakiro）でお送りします。
いつの日か本物の「スプリントプランニング Deep Dive」が聴けることを期待しつつ……、それでは聴いてください。
Attractor Inc.で、新曲「スプリントプランニング Deep Dive」

★★★Deep Diveシリーズ第2弾!!★★★ (シリーズなのか)

前回のプロダクトバックログ（https://slide.meguro.ryuzee.com/slides/107）に引き続き、今回はスプリントプランニングのすべてを完全解説!!

スクラムにおいて、スプリントの開始時にまず行うのがスプリントプランニングです。従来型のプロジェクトにおける失敗理由の多くが出だしで躓いたせいだと考えると、スプリントの最初のイベントであるスプリントプランニングも重要であることがわかります。

ここで計画づくりに失敗してしまうと、インクリメントを届けられず、スプリントレビューは針の上のむしろになり、スプリントゴールも達成できなくなってしまいます。

一方でスクラムガイドを見ると、扱うべき3つのトピックは明記されているものの、具体的なやり方や手順は書かれていません。結果的にスクラムの価値基準や原則にそぐわないことをしてしまっている例も散見します。

以下の項目のいくつかは、一般的に望ましくないとされています。どれが望ましくないものか考えてみてください。

• (a) 選択したプロダクトバックログアイテムのうち、必達のものを完成させることをスプリントゴールにする
• (b) 選択したプロダクトバックログアイテムの担当者を決めて、その人がそのアイテムの作業計画をたてる
• (c) できるかぎりReadyなプロダクトバックログを用意するのが望ましいが、必要ならスプリントプランニングで、選択予定のプロダクトバックログアイテムの中身を見直したり再見積もりする
• (d) ステークホルダーと約束した期日があるので、完成できる気がしないプロダクトバックログアイテムもとりあえずスプリントに入れる
• (e) スプリントプランニングの前に、先にタスクに分解しておく

もちろんスクラムガイドを解釈して、どのように進めるかは、スクラムチームごとに試行錯誤していけばよいのですが、とはいえ体系的に知識を押さえておけば（SCRUM BOOT CAMP THE BOOKも是非読んでみてください）、陥りがちな罠は避けられます。

本セッションでは、スプリントプランニングをうまく行うための基本から応用まで、Scrum Alliance認定スクラムトレーナー(CST-R)、認定チームコーチ(CTC)の吉羽が体系的に解説します。

なお、望ましくないものは、(c)以外のすべてです。

自分が所属するUnipos株式会社では、「感情報酬を社会基盤に」というミッションを掲げてUniposというソフトウェアを開発しています。

1年半前、自分はみんながもっと楽しく開発できるように、従来型の開発プロセスを変えようとトップの人に直談判を試みます。

自分が変革をはじめる最初の一人でした。
初学者でしたが書籍から学び、知識は万全。きっとなんとかすると前のめりでした。

ところが、憧れた会社や書籍のようにうまくいきませんでした。
そこにはシンデレラストーリーがあるのではなく、ただただ現実的な問題ばかりがありました。
その問題の乗り越え方は書籍には載っていません。
自分で悩み考え、取り組んでみて学習する必要があります。
形式知ばかりを学び、「最初の一歩」を実践したことのなかった自分は見事に頭でっかちになっていました。
頭ごなしに知識を押し付けたところで、とうとう組織の支援を受けることはできませんでした。

初学者が組織の変革をはじめる最初の一人になる場合、経験したことがないため乗り越えられないような問題が出てくることがあります。
そう考えると、むしろ最初は組織から協力を引き出せないほうが、自然なのではないでしょうか。
では、初学者が組織の変革をはじめるべきではないのでしょうか？自分はそんなことはないと思います。

最初の一人が躓いたとき、その後の歩みを止めないためにできることは何でしょうか。

このセッションでは、組織を変革する最初の一歩の道のりをふりかえり、自分が学んできたことをご紹介します。
なにぶん昔のことなので、思い出せないところもありますが、書籍には載っていないような自分の実践から学んだお話をご提供できれば幸いです。

すべてがフィードバック、なんでもフィードバック - Feedback is Life

フィードバックは、会社の中のコミュニケーションだけでなく、家族間、学校内、などなど、コミュニケーションがあるところには、かならずあることです。リーダーからメンバーへフィードバックする機会もあります。トレーナーとして、受講者にアドバイスするのもフィードバックなら、受講者からトレーナーが学ぶのもフィードバックです。立場と関係なく、自分が感じたり考えたりしたことを共有し、相手からも教えてほしいというのも、またフィードバックの話です。

しかしいざ学ぼうと思って探してみても「上司が部下に言うことを聞かせるため」系の本しかありませんでした。そのときに、ワインバーグ先生の『What Did You Say? The Art of Giving and Receiving Feedback』に出会いました。ワインバーグ先生ならきっといいことが書いてあるに違いない！と考えて、英語の本に取り組むため仲間を集め、定期的な読書会形式で進めることにしました。

そして1年4ヶ月の読書会を経て、私たちはこんなふうに理解できました。

• すべてがフィードバック、なんでもフィードバック。
• テクニックとしてではなく、人の心の働きに立ち戻り何が起きているのか分析する話です。
• フィードバックとは、しようと思ってするわけではなく、すべてがフィードバックです。またフィードバックは受け手の話ではなく、与え手を表現することです。そしてフィードバックは一方通行のコミュニケーションではなく、複雑な相互の継続的プロセスです。
• フィードバックでは自分自身を大事にすることが大切です。
• フィードバックは適切に、客観的に、わかりやすくすれば伝わると思ったら、大間違いです。
• 「フィードバックください！」とよく言ったり言われたりしますが、実は……

みんなでこうした理解に到達できたのは、単に英文を読み解いてというだけではなく、文意について意見交換をしたり、自分の体験にもとづいた捉え方を話し合ったり、ふりかえりをしたりしたおかげです。そこでこの読書会の体験と書籍の内容をセッションで共有したいと思います。

本の内容と読書会の体験について、読書会メンバーが対談・パネルセッションでわいわいします。実際の読書会の場面を切り取るような内容も、話せるかもしれません。

ぜひ、楽しい時間を皆さんと分かち合いましょう！

私は、悩んでいました。

アジャイルコーチを名乗っているのですが、コーチングができているかわからないんです。
もちろん学んでいますし、超優秀なコーチから継続的にコーチングも受けています。
でも、現場で行っているコーチングが、コーチングになっているかどうかの判断がつかないのです。

まわりを見ると、第一線でキラキラと輝くアジャイルコーチたちが活躍をしています。
そして、自分はいつも、悩んでいました。

そんなある日、コーチングセッションでコーチから提案を受けました。
「小さなことでもいいので、現場で日々やっていることを書いて共有して！！」

当初は、1ヶ月で20個、現場でやってみたことを書いてみる予定でした。
やってみると、1週間で50個を超えました。
今は、3週間で100個を超えました。

「デイリーミーティングでは大きな声で挨拶する」のような、簡単なものもあります
気づかず繰り返しでやっているものもあります。
中には、やってみて、傷つくような失敗になったものもあります。
思いがけずに、素敵な結果に結びついたものもあります。

もしかすると、僕がやりたいことは
こういったことが積み重なった先にある、小さく始めるアジャイルコーチの提案なのではないか、と思い始めています。

発表では、私が日々現場でやってきたことを抜粋して紹介します。
また、繰り返し現れたものや関係性があるものなど、パターンの抽出にも手をつけてみようと思います。

それら、発表の中で紹介した中から、気に入ったものや使えそうなものを持ち帰っていただいて、
明日から、皆さんの現場で、小さくな所からでもアジャイルコーチを始めてもらえれば嬉しいです！！
そして、また、コミュニティの中で結果を共有できる日を楽しみにしています！！

あなたのチームのインセプションデッキは役に立ってますか？

インセプションデッキは、書籍「アジャイルサムライ」の中で紹介されたツールです。

"プロジェクトに対する期待をマネジメントするためのすぐれたツールであるインセプションデッキ"

インセプションデッキは10個の質問で構成されていて、質問に答えていくことでプロジェクト開始前に確認しておくべきことが明らかになるツールです。これだけ聞くと簡単そうに聞こえますが、実際に現場でインセプションデッキを作成して活用するまでにはさまざまなお悩みポイントにぶつかります。

「デッキ作成にどれくらい時間を確保すればよいの？」  
「デッキ作成するときは具体的にどう進めたらよいの？」  
「デッキを作ったのはいいけれどそのあとどうしたらいいの？」

本セッションでは、インセプションデッキの紹介からこれらの現場で実践する際のお悩みポイントを解決する方法までお話します。

また、インセプションデッキは作成したデッキ以上にチームの関係性をつくることに価値があります。ただデッキを作成するだけでなく、チームの関係性をつくるためのインセプションデッキについてお話してみます。

スウォーミングとは、ソフトウェア開発の文脈では 1 つの問題やタスクを皆で群がって解決するという意味合いになります。私が所属しているスクラムチームでは、最も優先順位が高いタスクを最速で完了させることを目的にスウォーミングを実施しています。

スウォーミングの手段の1つにモブプログラミングがあります。私たちのチームも結成当初は、フロー効率最大化のためモブプログラミングで1つのタスクに群がっていました。しかし、開発が進みタスクの不確実性が下がってくると、開発メンバーは「フロー効率重視の開発スタイルを維持したままリソース効率を高めていきたい」と考えるようになりました。

そこで、Swarming: One-Piece Continuous Flow** のキャプテンの仕組みを参考に、ソロプログラミングを主とした開発でもフロー効率が下がらない方法を編み出し、チームに適用しました。私たちはこの仕組みをキャプテン制度と名付けて運用しています。

本セッションでは、スクラムチームで実践しているスウォーミングの紹介、キャプテン制度の策定の背景、得られた効果についてお話ししたいと思います。また、私自身スクラムマスターとエンジニアを兼務している立場であるため、スクラムマスター、エンジニアそれぞれの立場で、キャプテン制度を運用してみた所感についても共有させていただきたいと思います。

設立74年目のアルプスアルパイン株式会社では、数々のカーナビゲーション、音響機器、電子部品を開発、製造、販売しています。

約3年前、自発的に「スクラムやってみない？」と始めた私の所属チームは、現在もスクラムで業務を進めています。

このセッションでは、これまで沢山の難所・失敗を経験しながら一歩ずつ成長してきた、私の所属チームの奮闘記をご紹介します。

どのような難所・失敗が発生したか、それらにどう立ち向かったか、結果どうなったのか、をできるだけ具体的にお話する予定です。

多くの書籍やサイトで、アジャイル開発やスクラムは不確実性が高い領域へのアプローチとして有効だとされています。
例えば、More Effective Agileでは以下のように言及されています。

> プロジェクトに関して不確実性が高ければ高いほど、煩雑系（シーケンシャル）のアプローチよりも複雑系（アジャイル）のアプローチのほうが有利になる。
「More Effective Agile “ソフトウェアリーダー”になるための28の道標」 Steve McConnell

しかし、不確実性という単語にはマイナスイメージが強いためか、不確実性との付き合い方に失敗してしまう場面も見受けられます。自分が見たり経験してきた具体的なものだと、以下のような場面が挙げられます。

• 不確実性は減らせば減らすほど良いものだと解釈してしまい、なかなかはじめの一歩が踏み出せなくなってしまう
• 制御可能な事象や一方的な要求が不確実性という言葉で包まれてしまう
• 「不確実性が高い領域だったので失敗したのは仕方がない」と、うまくいかなかった理由として短絡的に結びつけられてしまう

本セッションでは、金融領域や数学の領域を中心に据えながら、様々な視点から不確実性とは何かを探っていくことで、不確実性という言葉に対する理解を深めると共に、不確実性とはどのように付き合っていくことができるのかや、不確実性をどのように活用していくと良いのか...を考えていきます。
具体的には、以下のような視点が登場する予定です。

• モンテカルロシュミレーション(金融領域で意図的に入れ込む不確実性)
• マクロ経済学
• カオス理論

スクラムを実践していくにあたって、不確実性をどのように捉え、どのように不確実性に向かい合っていくのかを考える一助になれば幸いです。

どうもこんにちは! タフクエスチョンオタクの森です!

手強い問いかけを「タフクエスチョン」と呼んだりします。答えることがなかなか難しいですが、今まで考えたこともない観点になることもあり、停滞していた状況を打開できることもあります。盲点を突くような問いかけです。

では、簡単な問いかけと手強い問いかけにはどのような違いがあるのでしょう。

人は様々な知識を持っていて、問いかけをされると刺激されて考えが引き出されます。しかし、どのような問いかけがどのような刺激を与え、どのような結果になるのか、その関係は明らかではないように思います。たとえば、自社のプロダクトに質問をしたとしましょう。

「このプロダクトの特徴はなに?」
「このプロダクトを買うと、どんないいことがあるの?」
「さまざまなプロダクトの中から、なぜこのプロダクトを選ばなければならないの?」

下に行くほど答えるのが難しい感覚があるのではないでしょうか。

このセッションでは問いかけと答えの仕組みと働きを紹介し、参加者が効果的な仮説立案と検証について知ってもらうセッションです。

■セッション内容(予定)
・質の高い問いかけが、私たちの仕事にどのような働きをもたらすのか
・過剰にもてはやされるWHYカーゴカルト
・シンプルな質問とシンプルな答え
・複雑な質問と複雑な答え
・シンプルと複雑の違い
・問いかけの構造と機能
・質の高い問いかけを作ろう

こんにちは！仙台。

私はQA組織のラインマネージャーをしていますが、なかなかエンジニアが集まらないことに悩みを持っています（どこもそうかもしれませんが）

そこで、QAエンジニアやテストエンジニアについて少し語らせてください。

QA（品質保証）という職種はピンとこないものですよね。

特にこれからエンジニアとして新しく社会人になる方は未知の世界だと思います。

実際に弊社の新人研修に参加して、新人エンジニアに聞いてみると、QAエンジニアやテストエンジニアの印象は以下のようなものでした。

「よくわからないけどテストする人」

「製品の品質を保証する人」

「プロジェクトを改善する人」

実際に採用情報を調べてみても、よくわからないのが現状のようでした。

では、ウイングアーク１ｓｔ（弊社）ではどのような定義をしているか？

実はQMファンネルというツールを使ってわかりやすく説明できる状態にしています。

このセッションではQMファンネルを使ってエンジニアを再定義し、実際にどのような活動を行っているのかを紹介しつつ、これから新社会人になるエンジニアにQAについての理解度を深めてほしいと思います。

そして「QAの魅力や、やりがいを感じ取ってほしい！」そんな想いをのせたいと思います。

QMファンネルとは？

新しい品質保証のかたちを目指して、SigSQAというコミュニティで作ったツールで、スペシャリティやロールを可視化することによって、組織デザインやキャリア開発の手助けをします。

詳しくはこちらのブログを参考にしてください。

3つのスペシャリティと5つのロールを軸に説明します。

QMファンネルはエンジニアを３つの得意技に分けています。これをスペシャリティと表現しています。

• テスト・エンジニア（TE）
• パイプライン・エンジニア（PE）
• QA・エンジニア（QA）

また、３つのスペシャリティに対して深さ（実業務への近さ）を表します。これをロールと表現しています。

• スプリット
• インプロセス
• コーチ
• コンサルタント/サービス
• プロモーター

タイトルで三◯寿の名言をオマージュすることを思いついてしまったので、J・リチャード・ハックマンの「Leading Teams」に絡ませて「チームの学びと成長について」の内容で話していこうと思います(がんばります)

銀行の内製アジャイルチームが、バシャっと集められてから約1年経とうとしています。
やってみよう、認め合おう、許しあおう、意見を出し合おう
ができている良いチームだと感じています。
それはチームを主観的に見ているからなのかもしれないと疑問に感じました。
そして、それは客観的な何かでチームの状態を説明可能なのかと考えるきっかけになりました。
チームに対する
・チームの機能期へと向かっていく変遷
・その道のりでの出来事、挑戦したこと(心理的安全性の作り込み、1年デイリーレトロ)
・今の状態がハックマンモデルではどう説明できるのか
の発表を通して、チームの状況を評価・説明していきます。

スクラムチームの構成

• PO：他部署(開発経験なし)
• SM：私です！
• Dev：4名
  
  • メンバー１：15年目くらい
  • メンバー２：元銀行員(エンジニア4年目)
  • メンバー３：元銀行員(エンジニア1年目)
  • メンバー４：新卒エンジニア

みなさんは、こばせさんのツイートを覗いたことがありますか？

ナゾの要素が多いつぶやきだったり、思わず共感してしまう内容だったり、意外な気づきを得るきっかけになったりと、いろんな味わい深さがあります。

そんなこばせさんのツイートを見ながら、こばせ（本人）・おがさわら・いづのタイプの違う３人で、ラフな感想戦をしながらゆったりと探訪する『ツイートお散歩』的な企画です。

同じ景色を見ていても人によって感じ方が異なるように、同じモノを見ていても思考や解釈の仕方は、人によってそれぞれ異なります。

他の人の思考や解釈を知ることで、思わぬ発見や気づき、新たな行動のきっかけに出会うことがあります。

あなたも気軽な気持ちで『こばせ語録』を一緒に探訪しませんか？

-------------------------------------------------------

【登場人物】

こばせ：ひとりで想いを巡らせる内省タイプ

おがさわら：ロジカル思考で時々詰め気味になってしまうタイプ

いづ：共感しすぎて感情に憑依されムダに悩みを増やすタイプ

-------------------------------------------------------

【散歩イメージ】

こばせ (@kobase555)
「フィードバック」に変わる言葉がほしいいいい

いづ：
「これ、なにがあったのw」

こばせ：
「"フィードバック"と一言で言っても、どういうものを表すのか、いろんなものがあると思います」
「例えば、レビューの指摘、査定とか評価、感想、マサカリ、感謝とかいろいろあると思うんですよね」
「フィードバックに関するプロポーザルを書こうとして、私が対象にしているものは何といえばいいんだろう？と思ったのがきっかけです」

いづ：
「それでいうと、私は"心理的安全性"って言葉も似てると思うんだよね」
「"心理的安全性"もひとつのワードではあるけど、個人の中の定義や理解度はバラバラ」
「本来なら意味のある適切な言葉があるはずなのに、抽象度の高い言葉でラップすることによって、伝わることも伝わらなくしてしまってる感じあるなぁって」
「そのままの言葉でそのまま伝え合うほうが好きだな」

おがさわら：
「ちょっと話は変わってしまうんですが、前に認知科学の本を読んだときに印象的だった好きな話があって」
「日本語だと、辛い（からい）はひとつだけなんですが、中国語だと麻とか辣みたいに辛いにたくさんの種類があるらしくて」

「なぜたくさんあるかというと、細かい辛さの違いを区別したくなるような文化というか、人々の辛さに対する興味の高さがあるって話で」
「それを考えると、フィードバックって言葉の粒度だと少し粗く感じるというのは、フィードバックについて、こばせさんが注目し始めたってことなのかなと」

「なので評価とか感謝みたいな別の言葉に置き換えたくなるのも、ある種自然なことだったりするのかなとか思いました」

こばせ (@kobase555)
ふくざつにゃーん

こばせ：
「きっとなんかふくざつだったんですね」

こうして３人の探訪は続く・・・

私はアジャイルコーチとしてスクラムチームの支援をしています。

支援先の多くは「今からアジャイル開発を始める」または「1,2ヶ月前に始めた」というチームです。

始めたばかりのチームだと色々な悩みがありますが、その中でも今回はスクラムマスターに関する悩みにフォーカスしてみようと思います。

（スクフェスの参加者的にスクラムマスターの方が多そうなので）

立ち上がったばかりのスクラムチームにおけるスクラムマスターの悩みも多様ですが、よくあるのはこんなところでしょうか？

1. そもそも何をやったら良いか分からない
2. 開発者と兼業でも大丈夫だろうか
3. 他のメンバーがちゃんとスクラムをやってくれない
4. ちゃんとできていないことをどう伝えればいいだろうか
5. スクラムマスターってどんな立ち位置でいればいいの

今回はガイドや書籍を読んでもなかなか解決が難しそうな 3. 以降の悩みに更にフォーカスしてみようと思います。

初めてスクラムマスターをした方が「どんな観点でチームの問題に気付くのか」「それに対してどんな反応をするのか」「その結果どんなことが起きるのか」あたりを紐解いていってみようと思います。

また、そういったスクラムマスターに対してどんな関わりをすると良さげだったのかも共有させてもらおうと思います。

今回の話はN=1の事例の話ではなく、複数のケースから抽出したものになります。

具体的で生っぽい面白さはないかもしれませんが、使える範囲は少し広めかなとおもいます。

「なんでみんなスクラムをやってくれないんだ！だからうまくいかないんだよ！」と思っていたり、そういった積み重ねから「なんか開発者やPOとうまくいってないんだよなぁ…」という方がチームと馴染んでいくためのヒントになれば幸いです！

何はともあれスクフェス仙台も盛り上がっていきましょー！わっしょい！！

スクラムを始めていくと

• こんなに多くの会議は必要ですかね？
• 手を動かしたほうが早くないでしょうか？
• スクラムイベントの時間が長くて疲労感がすごいです。

という感想やフィードバックがレトロスペクティブの際に挙がることはないでしょうか？

チームが上記のように感じることで、時にはチームのモチベーションが下がったり、スクラム開発をやめてしまう原因の一つになってしまうこともあると思います。

スクラムに対して「会議が多い」「会議の時間が長い」というのはよく聞く批判なので（あるあるなので）

• よく出てくる感想なので、あまり心配しないでくださいね
• 効果を感じるまで時間がかかるのは事実なので、もう少しやってみませんか？
• 慣れるまでは確かに大変だと思います。

という言葉でチームに対してコメントや問いかけをすることもあると思いますが（自分はそうしてしまうことも多かったです）、「会議が長い・多い」という感想やフィードバックがでてしまう背景には当然原因となる事象が潜んでいるはずです。

それらのフィードバックや感想の原因となる事象についての考察と、それに対してチームでどう向き合っていくのかについて、BASE株式会社のあるチームの実例を紹介しつつ発表します。

「スクラムチームにスクラムマスターは本当に必須ですか？」

スクラムマスターがいるのに、成果が出ていないチームもあります。

スクラムマスターがいなくても、成果が出ているチームもあります。

「その真髄はどこにあるのか？」

異なる立場で向き合う3人のスクラム実践者と紐解くセッションです。

我々3人が見てきた様々なスクラムマスターを紹介します。

• 専任
• PO兼任
• 開発者兼任
• マネージャー兼任
• SM無し
• ペア
• 複数チームのSM
• プロパー
• 社外のメンバー
• 新社会人
• 開発未経験者
• 開発経験者
• サイレントSM

様々なスクラムマスター・チームを見てきた3人が今考えていることはこのような感じです。

• SMの人数とチームの成長は必ずしも相関していない
• SMの役割を他のメンバーに分散しても良いのでは？
• 明示的にSMのラベルを貼らなくても良いのでは？
• SMの役割が多すぎるので1人でやるの難しすぎるのでは？
• SMのスキルが必要なのはスクラムだけじゃないのでは？
• SMの練習はスクラム以外でも出来るのでは？
• SMの勉強だけしていても良いSMになれないのでは？
• SMのゴールや幸せとは？
• SMのキャリアはアジャイルコーチが多いけど他に何があるんだろう？
• SMを長期間継続している人がいないのはなぜだろう？
• あらためて、SMとは？

このセッションでは、上記のようなテーマを3人と一緒に考えてみる時間です。

皆さんも一緒にスクラムマスターの価値を大解剖しましょう！