暗黒の魔境アマゾン奥地3000キロに幻のアジャイル民族は実在した!!
大阪なのにベトナムとか言い出す謎のスクラム奇祭を追え!!

はじめに

というわけで2020年6月26日(金）・27日(土)の2日間にかけてオンラインで開催された
Scrum Fest Osaka 2020に参加してきたレポ記事になります。

Day1ではイベント運営全体について感じたことや基調講演の内容をレポしましたが、
Day2では僕個人が参加した以下4つのセッションの体験記をお届けしていこうと思います。
超絶長いのでもくじ機能を活用してください!

Rochelle Koppさん「サーバントリーダーシップを身に付けましょう！」
風間裕也さん「日本の開発者・経営者に特に伝えるべきAgile Testingのエッセンス」
鷲崎弘宜さん「アジャイル品質パターンによる伝統的な品質保証（Quality Assurance）からアジャイル品質（Agile Quality）への変革」
上野彩子さん/中村薫さん/小林幹門さん/安藤寿之さん「【座談会】役割も業界も乗り越えろ！」

この４つ含め、全セッションのスライドはスクラムマスダーさんがまとめてくれています！

Rochelle Koppさん「サーバントリーダーシップを身に付けましょう！」 @ 福岡

スライドはこちらから

スピーカーはRochelle Kopp(ロッシェル・カップ)さん(@JICRochelle)
- アメリカ人経営コンサルタント
- 異文化コミュニケーションを専門
  - もともとは日本に進出している海外企業のお手伝い、そこから日本と海外の違いに興味
  - 働き方で海外とのキャップを埋めていきたい

ラーニングアウトカム

サーバント・リーダーシップとは何なのかを理解する
サーバント・リーダーシップとは何故効果的なのかを理解する
サーバント・リーダーが実施している具体的なスキルを学んで習得する

イントロ

質問：参加者のロール比率調査
- マネージャー・上司が多め、次にスクラムマスター。その他もポツポツ（僕はその他）
質問：チームを管理する・一緒に取り組む上で大変なのは？
- モチベーション管理
- コミュニケーションの具体的手法
- 会社との間や個人間でのズレの調整　などなど。
新技術の導入を成功させるための8つの文化的習慣
- 今日はその中からサーバント・リーダーシップについて

サーバント・リーダーシップとは

従来の上司像とサーバント・リーダーとの違い
- 上からの指示型 ⇢ 一緒に行動型へ
サーバント・リーダーシップとは
- チームのサポートに集中
- マイクロマネジメントは推奨されず、権限移譲をよしとする
- マネージャーはチームの障害物を取り除くのを助ける
- マネージャーは優れた「聞く」スキルと「フィードバック」スキルを持っている
- マネージャーは従業員が過度な批判や過大な要求をしない
- プレイングマネージャーは、いらない

サーバント・リーダーシップは何故効果的か

サーバント・リーダーは何故今日本で必要なのか
- スクラム・アジャイル実施に不可欠
- 悪い日本企業風土の解毒剤に
- 研究で既に効果が証明されている
サーバント・リーダーシップのインパクト
- 40年前にアメリカで開発された、意外と古くからある手法
- 様々な効果が期待できる
  - 会社のパフォーマンス（収益）改善
  - メンバーのパフォーマンスやエンゲージメントの向上
  - 個人だけでなく、チーム、カスタマーにも効果が波及
「それはすごい！うちのマネージャーや会社の幹部にもやってほしい」と思ってません？（笑）
- まず自分から変わりましょう feat. ガンジー（笑）
何故スクラムマスターにサーヴァントリーダーシップが必要なのか? from Scrum Mastery
- スクラムマスターという役割には権力・肩書が付随しない
- チームのパフォーマンスを上げて、素晴らしい商品をいち早く届けるためになんでもする
もちろんチームメンバーにとっても役立つ
- リーダーシップはどんなポジションからでも発揮できる
- ある意味で究極のソフトスキル
  - 人に命令するのはなんのスキルも要しないが、人を説得するにはスキルが必要

リーダーシップとは

リーダーシップとは実際に何を意味するのか？
- 「ハンサムな人がなる？」（笑）
- Vance Packard「Pyramid Climbers」による定義
  - リーダーシップとは、やるべきとあなたが確信していることを、他の誰かがやりたくなるように仕向けるわざである
質問：尊敬する人から誰かから指示を与えられて、喜んで従った経験はありますか？
- この人物は、どんな行動をとっていましたか？
- どんな点を尊敬しましたか？
- この人物に感じた気持ちを言い表すとしたら？
オーディエンスの回答：尊敬する人に感じた気持ちを言い表すとしたら？
- 誠実, 安心, 信頼されている/信頼できる
- わくわく, 楽しい
- この人のようになりたい, ...
ある研究者たちが自身の研究で同じ質問をした
- ポジティブなワードばかりが挙げられた
- 調査対象者たちは誰も以下のワードを使わなかった
  - fearful（怖い）
  - intimidated（脅されたように感じた）
  - stupid（自分が無能のように感じた）
  - sad（悲しくなった）
- 「人は自分をいい気分にさせてくれるリーダーに従う」
  - 尊敬されるリーダーは自分の地位を強調したり、部下をないがしろにする行動をとったりしない
  - 優れたリーダーは部下を尊重し、部下の心をポジティブな感情で満たす
具体的に必要な資質
- たくさん（笑）
- 今日は以下の3つに絞る
  - Listening
  - Awareness
  - Commitment

Listening

サーバント・リーダーは徹底して顧客・従業員・マーケットの話を聞く
- なぜ？を明確にする
- 非明示的な態度にも注目する
- 聞いたことを実際に反映する・実現する
耳を傾けることの大切さ
- 人は誰かに気持ちをわかってもらい、受け止めてほしいと思っている
個人への気配りと具体的な手法としての1on1
- 一人ひとりに注意を払い、彼らの意見や懸念を引き出すのが大切
- 人の話を聞くにはしっかりとした時間が必要、例えば1on1など
  - リモートでは週2回、1on1を実施してもいいくらい
- 1on1ではメンバーは４つの質問を答える
  - 「ワクワクしていること」
  - 「心配していること」
  - 「チームマネージャーがなにかできることは？」
  - 「メンバー自身がなにかできることは？」
- 1on1以外のコミュニケーションも必要
  - リモートでは仕事以外の悩みを聞けるような会話を行うのがよい
  - ロッシェルさんの部下が離婚した際の体験談（笑）
上手に質問しよう
- 定義を質問する
- 理由や背景の情報を尋ねる
- 自分が正しく理解したか相手に確認する
- 次に何をすればいいかアドバイスや提案を依頼する
- 回答のための選択肢を多く与える
- 相手が対応するための計画や概要を見せる
このような資質は技術や訓練で補える
普通の業務にプラスしてこういった仕事をしていくのは基本的に無理
- こ結果が見えにくい仕事なので、時間がかからないと思われがちだがそうではない
- アメリカではプレイングマネージャーという概念すら存在しない
- 兼務している場合には、タイムボックスを完全に区切るのがよい（午前/午後でとか）

Awareness

オフィスを歩き回ってみよう
- リモートだったらWeb上の会議を増やす
  - メンバーの見えない仕事を「見える化」してあげる

Commitment (to the growth of people)

メンバーひとりひとりが成長に取り組むことを把握し、
自分がリーダーとしてメンバーに責任と影響力を持っていることを把握する
2つの具体的手法
- フィードバック
- 権限移譲

フィードバック

フィードバックとは
- 相手の仕事について自分の意見を伝える方法
  - 相手がどの点を成功しているか、どこを改善したらいいかをわかってもらう
- 日本にはもともとない概念
  - 「何も言わず無視していれば、問題はなくなる」という思い込みは間違い
  - 望まない行動は言葉に出して指摘しないと、許されていると思われる危険性がある
ネガティブ・フィードバック
- 実際の問題に絞ってはっきりと指摘しながら、相手への配慮を込めた丁寧な表現を用いる
  - 「叱る」のはやめよう、相手は子供ではない
- フィードバックはすぐに。ただ他の人の前では絶対にせず、必ず口頭で
- 具体的実践例
  - 1. 問題行動を指摘する
  - 1. 問題行動のよくない結果を指摘する
    - この「何故」が抜けがち
  - 1. 今後どんな行動をとって欲しいのかを示す
ポジティブ・フィードバック
- いい仕事をしていると思えば、それを伝える
  - すぐその場で、頻繁に
  - グループに対しても個人に対しても
- 具体的実践例
  - 1. 良い行動を指摘する（具体的に）
  - 1. 望ましい行動のいい結果を指摘する
  - 1. 今後どんな行動をとって欲しいのかを示す

権限移譲

しづらいと感じる人も多い、意識的に乗り越えよう
セルフマネジメントチームを作ろう
- チームのそれぞれがオーナーシップとコミットメントを発揮
- 必要なのはメンタリングとコーチング。命令とコントロールは不要

感想

コメントが大盛りあがりで、講演のタイムボックス終了後３０分以上質疑が続くという異常事態に（笑）
業務で研修講師を担当することが多いので、すぐに活かせる実践ステップの明示もあったのがとても助かりました。
また、僕は現時点でサーヴァント力が/Zeroなのですが「スキルだからトレーニングで身につく」とおっしゃってくれていたのがすごく心強かったですね。

風間裕也さん「日本の開発者・経営者に特に伝えるべきAgile Testingのエッセンス」 @ 新潟エリア

スライドはこちら

スピーカーは風間裕也（ブロッコリー）さん(@nihonbuson)
- 本名のほうが反応できないらしい
- 株式会社ビズリーチ所属
- JASST Review実行委員長
- WACATE実行委員
- 書籍「Agile Testing Condensed」翻訳

「Agile Testing Condensed」とその著者JanetとLisaさんについて

2008年「Agile Testing」（日訳「実践アジャイルテスト」）刊行
2011年「Agile Testing Days」にて講演
2014年「More Agile Testing」
2019年「Agile Testing Condensed」刊行
- 日本語翻訳版は電子版のみ刊行
- 前2作に比べ、ページ数が超少ない
  - もっと手軽に読んでほしい
  - 経営者にも読んでほしい
- 今回はアジャイルテストの考え方と事例などを紹介する

改めて「アジャイルテスト」を考える

定義
- 継続的に実施される協調的なテスト
- 理解を検証しながらプロダクトの品質を気付く
- 品質に対するチーム全体の責任という考え方をサポート
継続的テストモデル
- どこのフェーズでもテストする
アジャイルテストの10の原則
Testing Manifest
- アジャイルソフトウェア開発宣言も合わせて
4つのテストのアプローチ
- 例を用いる
- 探索的テスト
- 品質特性のテスト
- DevOpsでのテスト
  - 今日は「例を用いる」と「探索的テスト」を紹介

例を用いる

効能
- 各ストーリーの共有理解
- 矛盾点に気づきやすくなる
- ストーリーの拒否が少なくなる
- デプロイまでの時間短縮
プラクティス
- 振る舞い駆動開発(BDD)
- 受け入れ駆動開発(ATDD)
- インパクトマッピング
- 実例マッピング
  - ルールの理解を明確にするフレームワーク

実例マッピングの実例紹介

ストーリーとルールと例と疑問点を分けて会話し、分かれた状態で記録するという思考が大切
例：開発者が「いい感じに実装したい」と言っている。「いい感じ」とは実際どんなものだろう？
- QAが実例（入力値と出力値のQ&A）を用いながら対話によって解明していく
実例マッピングの成果物をインプットとしてSpikeの洗い出し、受け入れ条件、テストケースが導出できる
- 大抵1時間くらいのセッション
開発者とQAが協力して、実装前からテストを考え、認識を合わせられる
必要なスキル
- 実際に起こりうる具体例で考える
- 抽象化と具体化の行き来が必要
  - テストのスキルも必要

探索的テスト

「テスト設計と実行を同時に行い、実験から得た洞察を次に伝える」
- 学習と設計と実行を同時・反復的に行う
- アドホックテストやモンキーテストとは違う

アジャイルテストでよく使われる図を再考する

アジャイルテストの四象限
- どの象限が何を示すかを理解することが重要
- 状況に合わせてモデルを当てはめる
テスト自動化戦略の視覚化
- テスト自動化ピラミッド
- テスト自動化の氷山

今日のアジャイルテスト

テスターの新たな役割
- 世界でテスターの新たな役割が提唱されてきている
  - ちなみに世界ではQAエンジニアやテストエンジニアといわず「テスター」と呼ぶことが多い
    - 国内でも世界でも結構現場によって「テスター」の定義が違う
- チームにとっての 「品質の接着剤」
  - 思慮深いテストの設計に移行する
- テスターの新たな旅
  - 新しい実験を学び、試す
  - 優れた質問者になる
  - モデリングスキルを持つ
  - テスタビリティなどを定義するための知識を持つ
  - 共有と共同の姿勢を持つ
  - できるかぎりのことをする
  - 会話から始める
  - チェッカーはもう必要ない
- JanetとLisa曰く、テスターは「チームのテストコンサルとして行動する必要」
テストも含めてアジャイルを成功させるためには
- チーム全体のアプローチを意識する
- アジャイルテストの考え方を持つ
- 回帰テストを自動化
- フィードバックを提供
- コアプラクティスの基盤提供
- 顧客との強調
- 全体像を見る
- 信頼関係の構築
  - 実例
  - 探索的テスト
  - 継続的学習
  - 常に現実的でいる
- テストの問題をチーム全体が対処する問題に変える
  - 忍耐とふりかえり

感想

実例マッピングいいですね！対話を進めていった結果がスパイク・受け入れ条件・テストケースに自然に落とし込まれるのがいい感じ。~~（いい感じ、とは）~~
僕の現職ではもう出来上がってるシステムに対してテストすることがほとんどなんですけど、開発途中に参画できたらいいよなーとか思いました。
あと質疑応答タイムでおっしゃってた「Quality AssuranceからQuestion Askerに」の話がよかったです。
ロッシェルさんの「サーヴァント・リーダーシップ」の"Listening"にも通じますね。

「Agile Testing Condensed」の日本語版はLeanPubというサイト上で頒布されており、
$15から自分の望む金額をつけられるようになっているんだとか（ちょっとソーシャルファンディングみたいですね）。マストバイ。

鷲崎弘宜さん「アジャイル品質パターンによる伝統的な品質保証（Quality Assurance）からアジャイル品質（Agile Quality）への変革」 @ XP祭りエリア

スライドはこちら。

アジャイル品質とパターン

スピーカーは鷲崎弘宜さん(@Hiro_Washi)
- 早稲田大学グローバルソフトウェアエンジニアリング研究所所長
アジャイル品質をパターンという視点から見ていく
- なぜパターンなのか？
  - アリストテレス "Quality is not an act, it is a habit."
    - 日常の反復的行動や考え方から品質は成り立つ
  - アジャイルの源流自体がパターン＋品質
    - クリストファー・アレグザンダーのパターン・ランゲージ
      - ウォード・カニンガムのエピソード
      - James O.Coplienの開発工程の生成的パターン・ランゲージ
    - W・エドワーズ・デミングの品質管理
      - Tom GlibのEvo
      - トヨタ生産方式・リーン思考・バリューストリーム
  - 品質もパターンでまとめるのが自然

QA2AQ : Quality Assurance to Agile Quality

QA2AQ ⇢ codezineでの連載はこちら
- 4つのカテゴリから構成されたパターン集
  - 中核パターン
  - 品質のアジャイルなあり方（体制）
  - 品質の特定
  - 品質の可視化
  - このそれぞれを概観していく

中核パターン

codezineのこちらの記事が詳しいです。
他のパターンを用いる上での基礎となるパターン
- 以下の2つのパターンから構成
  - アジャイル品質プロセス
  - 障壁の解体(Breaking Barrier)
アジャイル品質プロセス
- アジャイルプロセスの一環として、システムの品質を理解・記述・開発・テスト
  - サイクル全体で、チーム全体で
- 障壁の解体(Breaking Barrier)
  - 早い段階からQAをチームに含める

品質のアジャイルなあり方

以下の9パターンから構成
- QAを含むOneチーム
- 品質スプリント
- プロダクト品質チャンピオン
- アジャイル品質スペシャリスト
- 品質チェックリスト
- 品質作業の分散
- 品質エキスパートをシャドーイング
- QAリーダーとペアリング
- できるだけ自動化
「QAを含むOneチーム」「品質スプリント」「プロダクト品質チャンピオン」に関してはこちらの記事が詳しいです。
「アジャイル品質スペシャリスト」「品質チェックリスト」「品質作業の分散」に関してはこちらの記事が詳しいです。
「品質エキスパートをシャドーイング」「QAリーダーとペアリング」「できるだけ自動化」に関しては絶賛執筆中とのこと。

品質の特定

以下の8パターンから構成
- 重要な品質の発見
- 品質シナリオ
- 品質ストーリー
- 測定可能なシステム品質
- 品質の折込
- 着陸ゾーン
- 着陸ゾーンの再調整
- 着陸ゾーンの合意

品質の可視化

以下の4パターンから構成
- 品質のロードマップ
- 品質バックログ
- システム品質ダッシュボード
- システム品質アンドン

感想

内容があまりにも濃密すぎて、途中ディスカッションしていたら45分では全く時間が足りなかったｗ
QA2AQに関しては共同研究者であるRebecca Wirfs-Brockさんのサイトで英語版全文が読めたり、
平鍋さんの記事でもとても詳細に解説されています。
また鷲崎さんはSmartSEという社会人向けのリカレント教育の一環でオンラインで講義を無料公開するという取り組みをされており、
8月20日にアジャイル開発と品質の講義があるそうです。マスト参加。

上野彩子さん/中村薫さん/小林幹門さん/安藤寿之さん「【座談会】役割も業界も乗り越えろ！」 @ Agile Japanエリア

スピーカー紹介
- ゲストは中村薫さん(@kaorun55)
  - 株式会社ホロラボ創業者・CEO
  - もともとWindowsアプリ開発者
  - 2009年にアジャイル/Scrumを知るが、しばらくは合わなかった
  - 2012年に独立
  - 2017年に会社設立
  - 最近ではアジャイル開発の良さに気づいて実際に取り組んでいる
- 上野彩子さん
  - 株式会社SHIFT所属
  - 立場上はQAチームを引っ張るマネージャー
  - QAはまわりと孤立しやすいことにお悩み
- 小林幹門さん
- 安藤寿之さん
- 座談会はDiscordのボイスチャットにて実施。
  - オーディオログが手元にないので話者等うろ覚えで恐縮です。
座談会
- [小林] アジャイルに目覚めたきっかけは?
  - [中村] 当初していた受託開発ではなかなか難しかった
  - [中村] 自社サービスだとスクラムのフレームワークがハマる
  - [中村] 受託でも請負or準委任でまた違ってくる
    - 請負だと最初に納品物を決めないとダメ
- [上野] QAの孤立問題に関して
  - [中村] テスト会社からのQA参入は第三者的なので余計難しい
  - [中村] 開発側、QA側とあると壁を作りがち
    - 契約やコンプラの関係
    - 中村さん自身、どうするのがよいのかわからない（笑）
  - [上野] QAも最初の段階から顧客と議論をしていきたい
    - 議論の場に呼んでいただけないと、リスクマネジメントの観点からもよくない
  - [中村] ちょうど中村さんの会社のサービスでもテストエンジニアに入ってもらっている
    - プロジェクトの最初からいたほうがやりやすい
- [リスナー] QA側は最初にこういう情報ほしいとかありますか?
  - [上野] 企画段階から参画できるとよい
  - [上野] 具体的には一緒にユーザーストーリーをつくる、受け入れ条件をつくっていく
    - 発注側もQA側も、お互いにどの情報が必要かが共有できてない
- [小林] 上野さんは今企画段階からプロジェクトに呼んでもらっているとのことだけど、どうやってそこに入ったの?
  - [上野] QAが入るとこんなメリットがありますよ、というお話を伝えた
    - 不具合、懸念点を最初につぶす、その方が先々困らない
    - お客様ははじめQAが入ることで会議でみんなの手が止まるのを恐れていた
  - [小林] 最初から入れる方がいいという気がある、開発側もそういう流れになってきた
    - 多少会議が長引くよりも、後々のリスクを潰すことが大事
- [上野] QAを企画時点に呼ばない理由って逆になに?
  - [中村] 受託開発をやっていても、お客さんとの間に壁を感じることはある
  - [小林] 「お客様にいいものを提供する」という思いは同じ
    - でもそこに向かうプロセスが違っている
    - お互いの邪魔をしないように、協力して進めたい
- [中村] 心理的な距離感ははじめどうしてもある。慣れてくると踏み込める
  - [中村] チームビルディングの段階で心理的距離感が最初できてしまっている
  - [中村] 実体験として、今の開発チームも半年くらいで打ち解けてきた
    - 心理的安全を確保するというのは、キツいことも言いあわなければならないこともある
  - [上野] マルチベンダだとお互いやってることがわからない
    - 少しずつ話して打ち解けてきた
- [リスナー] 開発・PO以外のQAやCSの人ってチームビルディング時に入れる？
  - [中村] 中村さんのところでは、マーケとか営業もワンチームで入れている
    - ここ1、2ヶ月でやりはじめた
    - 販売の人とのコミュニケーションが取れていないというのが発端
      - その方自身が声を上げてくれた
  - [中村] チームだけじゃなく、会社組織がフィードバックを受け付けるべきと思っている
    - ソフトウェアに対してフィードバックというなら、組織に対してもフィードバックをしてほしい
  - [小林] 無理にステークホルダーを洗い出して呼び出すよりも理想的な状態に聞こえる
    - 関わる人が多くないというのがいいのかも
  - [上野] 他社QAが一番仕様を知っている、というのはよくあったりする
  - [中村] 中村さんは属人化を良いと思っている
    - 新しいこと、好きなことをやるのは結局そのひとの属人になる
    - 必要なのは属人化したスキルをシェアする形の構築

感想

僕自身テスト会社にいるのでわかりみが深かったです。一人常駐とかになったときの孤立無援感凄まじいですよね…。。
最終的には開発とQAと（あるいは更に別のロールとで）対話を重ねるしかないんだろうなあという気がしました。
あとは中村さんの最後の「属人化はいいと思っている」の話の必要なのは属人化したスキルをシェアする形の構築というところにとても共感。
「別拠点にいる人が何やってるのか全く知らん」ってなりがちなので、こういうシステムを全社的にスッとできたらいいんでしょうね。

全体感想

ということで、冒頭にあった通り超絶長くなってしまいましたが、これで2日間のレポートが終わりです。

僕自身は社会人になって初のカンファレンス参加がこのスクラムフェス大阪2020だったのですが、**「オンラインでここまでの"フェス感"出せるのか…！」**とかなり衝撃的な2日間でした。
運営面でもセッションの内容面でも本当参考になる情報ばかりでした、かつ、全セッションの録画がされているので後日追って見れるのがすごく良いですね。
噂ではスクラムフェス大阪は来年もオンライン開催になるんだとか。ぜひまた参加できれば！と思っています。
運営の皆さん、スピーカーの皆さん、参加された皆さん、ありがとうございました！