アジャイルコーチの備忘録

3歩歩いたら忘れるニワトリアジャイルコーチの備忘録。書評、活動記録など...

atama plusの大規模スクラム(LeSS)リモートイベント見学レポート【前編】

以前から大規模スクラム(LeSS)の書籍を繰り返し読み、コミュニティに参加し...と大規模スクラムの理論を学んできましたが、「理論は素晴らしいけど、現実で上手くいくのだろうか?」とどこかで感じてもいました。

そんな折、認定LeSS実践者研修で知り合い、大規模スクラムを実際に導入したatama plusのスクラムマスター河口さんから、「良ければウチの現場を見学しない?」と言葉を掛けていただき、ようやくこの目で大規模スクラムを見学することができました!

今回は、前編と後編に分けて、見学レポートをお届けします。
前編ではスクラムイベントの流れや、atama plusが独自にplusしている工夫を書いていきます。*1

こんな方にオススメ

  • 大規模スクラム導入を検討されている方
  • リモートでのスクラムイベント運営について知りたい方
  • atama plusのスクラムイベントについて詳しく知りたい方

atama plusと組織構成

atama plusとは中高生向け一人一人に最適な学習カリキュラムをAIが生成する「atama +」というサービスを開発運営する会社です。
「atama+」は開発者、UI/UXデザイナー、QAで構成された5〜6人からなる4チームが大規模スクラムでプロダクトを開発しています。
専任スクラムマスターは2名で、それぞれ2チームずつ担当しています。
詳しくは以下をご参照ください。

speakerdeck.com

大規模スクラムとは?

大規模スクラムとは2〜8チーム向けの大規模アジャイルフレームワークです。
1つのプロダクトバックログを1人のプロダクトオーナーが管理するというスクラムのコンセプトを踏襲しながら、複数チームが連携しながらプロダクトバックログアイテム(以下、PBI)を優先順に実現します。
詳しくは以下をご参照ください。

less.works

見学したスクラムイベント

  • スプリントプランニング
  • 複数チームプロダクトバックログリファイメント(以下、複数チームPBR)
  • オーバーオールレトロスペクティブ
  • レトロスペクティブ
  • デイリースクラム
  • 教室長ワークショップ(「atama +」のユーザーインタビュー結果をチームメンバーに共有するためのワークショップ)

atama plusのスクラムイベントはリモートに移行しており、Zoom、Googleスプレッドシート、Jira、Miro等が利用されていました。

今回は、大規模スクラムでとりわけ特徴的なイベントである、スプリントプランニング、複数チームPBR、オーバーオールレトロスペクティブについて書いてきます。

スプリントプランニング

最初にご紹介するのはスプリントプランニングです。
大規模スクラムでのスプリントプランニングの特徴は、1チームスクラムの流れに加えて、チーム間で調整しながらチームが担当するPBIを決定することです。

f:id:norihiko-saito-1219:20201018001940p:plain
参照:https://less.works/img/framework/sprint-planning.jp.png

スプリントプランニングイベントはZoomで実施され、POおよび全チームメンバーが参加します。
テーマ(プロダクトバックログをまとめるビジネステーマ)はMiro上の付箋で、プロダクトバックログはJiraで管理されていました。

スプリントプランニング第1部の流れ(1h)
  1. テーマと優先順位についてPOが説明
  2. 新しく作成されたPBIの概要/ビジネス背景をPOが説明
  3. 次スプリントで実現したいPBIをPOが説明
  4. 各チームメンバー同士で話し合いながら、チームが担当するPBIを決定
スプリントプランニング第2部の流れ(1h)
  1. チームごとにブレイクアウトルームに分かれ、プランニング第2部を実施(スプリントバックログはMiro上の付箋やJiraのサブタスク等で管理)

複数チームPBR(複数チームプロダクトバックログリファインメント)

大規模スクラムで最も運営が難しいイベントが複数チームPBRかもしれません。
大規模スクラムでは全チームが全てのPBIを担当する可能性があるので、スプリント開始前に全チームが全てのPBIを把握している必要があります。
しかし、全チームの全メンバーが全てのPBIについてリファインメントに参加するのは効率的ではありません。そこで、複数チームPBRではPBIごとにチームから代表者を割り当て、複数のPBIを並行してリファインメントを実施します。

f:id:norihiko-saito-1219:20201018002105p:plain
参照:https://less.works/img/framework/product-backlog-refinement.jp.png

リファインメント前日までに、各チームの代表者からなるリーディングチームが仕様の叩き台をGoogleスプレッドシートにまとめます。当日はシートを共同編集しながらZoom上でリファインメントを実施していました。*2

イベントの流れ(PBIごとにリファイメント30分+チームへの共有10分)
  1. リファインメント対象のプロダクトバックログの全体感をPOが説明
  2. リファインメント対象のPBIのビジネス背景と満足条件(≒受入条件)をPOが説明
  3. PBIごとに、チームから代表者を割り当て(チームのSlackチャネルで議論)
  4. 各チーム代表者がブレイクアウトルームに移りリファインメントを実施
  5. 各チーム代表者がブレイクアウトルームに移りリファインメント結果をチームメンバーに共有
  6. リファイメント対象のPBIが無くなるまで、4と5を繰り返す

(4、5は複数のPBIを並行して実施)

オーバーオールレトロスペクティブ

チームでは解決が難しい、組織的な課題を解決するためのイベントがオーバーオールレトロスペクティブです。

f:id:norihiko-saito-1219:20201018002158p:plain
参照:https://less.works/img/framework/xsprint-review-retrospective.png.pagespeed.ic.4qxk6ndBIS.webp

atama plusではチームのレトロスペクティブで、チームで解決できる課題と組織的な課題を切り分け、組織的課題をオーバーオールレトロスペクティブの議題に追加していました。
また、課題だけではなく、組織に「ただ共有したいこと」をオーバーオールレトロスペクティブの議題に追加するケースもありました。
atama plusではオーバーオールレトロスペクティブは全員が参加するのではなく、参加したい人が参加する形式。オブザーバー参加もOKです。私が見た際には、組織的課題を提起した方が積極的に参加する傾向にありました。
ちなみにatama plus代表の稲田さんもこのイベントは毎回参加されています。

Miroで付箋を利用しながら、Zoom上で議論していました。

イベントの流れ(1h)
  1. 参加者が持ち寄った組織課題を共有する
  2. 参加者の投票により組織課題の優先順位を決定する
  3. 解決策についてタイムボックスに区切り討論する(いわゆる「リーンコーヒー」に近い)

atama plusがplusしている工夫

今回のブログの終わりに、atama plusがスクラム運営に独自にplusしている工夫を一部挙げます。

  • PBI担当決めの効率化のため、各チームが担当したいPBIをスプリント前に事前に表明している(「お気持ち表明」と呼ばれています)
  • スクラムイベント運営コミュニティがあり、スクラムマスター以外のコミュニティメンバーがZoomのブレイクアウトルームの管理などのイベント運営をサポートしている
  • レトロスペクティブやデイリースクラム等のチームのイベントはスクラムマスター以外のメンバーがファシリテートしている
  • レトロスペクティブの最後にメンバー全員でレトロスペクティブ自体のふりかえりを実施し、レトロスペクティブのやり方を毎回改善している
  • チームメンバーが、ビジネス的な事情を鑑みつつも「このPBIは取れない」と調整する機会がある
  • 大規模スクラムの原則を組織に浸透させるために、スクラムマスターがイベントの冒頭で「調整と統合」などのキーワードを繰り返し伝えている

またスクラムマスターの河口さんによるとatama plusでは、創業当時より、プロダクトディスカバリーとプロダクトデリバリーを組み合わせた「デュアルトラックアジャイル」へ取り組んでおり、今回導入した「LeSS」との組み合わせた新しい開発手法を模索しているとのことでした。

note.com

また、atama plusでは見学も調整できるという事なので、大規模スクラムや「デュアルトラックアジャイル」に興味がある方は、是非河口さんにご相談してみてください!

後編では、僭越ながら、atama plusのスクラム運営の強みと弱みについて書く予定です。
最後までお読みいただき、ありがとうございました!

*1:今回のブログは見学時点(2020年8月)のスナップショットです。

*2:スプレッドシートの準備が大変で、リーディングチームの負荷が高いことがオーバーオールレトロスペクティブで課題視されていました。

そして父になる......!?

6月5日、第一子が生まれた。

妻は42歳で、僕は36歳だった。

結婚した時点で妻が38歳。
僕を含め、家族の誰もが、子供を授かれることを期待していなかった。

「子供が欲しいか?」と聞かれると、正直あまり深く考えていなかった。
ただ、妻が子供を望んでいたので、僕も欲しいと答えていた。
どのみち、何もイメージができていなかったのです。生まれたその瞬間、ではなく、里帰り出産から妻が帰ってきた7月までは。

ただ、漠然した予感がずっと心の中に鳴り響いていた。

「僕が未成熟なのに、夫婦だけでも手一杯なのに、子育てできるのか?」
「このご時世に子供を産んで、子供を幸せにできるのか?」

この予感は、思いの外、すぐ的中することになる。

今回はこの予感がどう的中し、現在、どう立ち直りつつあるかという事を男性側の視点から書いてゆきたい。

f:id:norihiko-saito-1219:20201015190423p:plain

崩壊の4ステップ

  1. 削られる体力
  2. 削られるメンタル
  3. 低下する仕事のクオリティ
  4. 育児の悩みを相談しづらい男性
1. 削られる体力

まず、正直とても恥ずかしいのですが、共働きにも関わらず、禄に家事をしてこなかったのです。
代わりに毎晩のようにオンライン・アジャイル・コミュニティに参加していた。めっちゃ楽しかった。
ただ、やってきたのは過酷な現実だ。
娘は四六時中、泣き喚いている。
泣き止むには授乳しかない。

流石の僕でもこれは家事をしなければマズい、と気づいた。
そこで慣れないながら、掃除、食事の準備、買物、子供の入浴、ミルクあげ、おむつ替え等をするようになった。
慣れない家事と、育児、そして夜泣きによる睡眠不足で、どんどん体力が削られていった。

2. 削られるメンタル

こちらも情けないのですが、僕は精神的にも妻に完全に依存していた。
具体的にはうまくいかないことや愚痴を逐一妻に吐き出していた。
辛いのは泣いている娘だけじゃない、僕も辛い。
そこで、必死に娘をあやす妻に話しかけてみた。

「ねえねえ、今ちょっと話聞ける?」
「そんな余裕ない! 見てわからない!?」

......当然だ。

そして僕はこう見えてプライドが高く、妻以外にあまり相談できなかった。

3. 低下する仕事のクオリティ

周りの父親はみな子育てをこなしながら、仕事でも易々と成果を挙げているように見える。
また、育児で仕事量が減ったと思われたくなかった。
何しろ少人数のチームだ、周りに迷惑を掛けるのも辛かった。
そこで、バカだったとしか言いようがないけど、普段よりたくさんの仕事を任せて欲しいとチームに掛け合った。
結果、どの仕事も中途半端になり、日に日にクオリティは低下していった。
今までは残業や土日出勤で密かにカバーして何とか取り繕ってきたけど、業務時間外は育児で手一杯だ。今回はその手は使えない。
結果、一人で担当すると宣言したのに、最後にはチームメンバーに様々なサポートをお願いする結果になってしまった。

4. 育児の悩みを相談しづらい男性

「なんでこんなに胸が重苦しいのだろう......」
7月から9月に掛けて、ずっとこんな気分が続いた。
この原因が育児による環境変化と気づいたのは、9月に入ってからだった。
育児に悩む女性の記事やツイートは良く見かけるが、男性の記事はほとんど無い。
そして、隣には、僕より何百倍も苦しむ妻がいる。
「男が弱音を吐いちゃいけない」という風潮に知らず知らずに僕もハマり、相談することすら出来ずにいた。

3ヶ月での気づき

色々と書いてきたが、この3ヶ月で気づいたことを一言でいえば、
「余裕がなければ、育児はできない」
さらにいえば、
「自分が幸せでなければ、人を幸せにできない」
という平凡なことだ。

けれど、皮肉なことに、育児とは参加者の余裕がなくなっていくゲームなのだ。
そんな中で、余裕を確保するために、今取り組んでいることは以下の2点だ。

  1. 周りの人に状況を打ち明け、協力をお願いする
  2. 仕事を効率化する
1. 周りの人に状況を打ち明け、協力をお願いする

どうしようもなくなってから、僕は上司に、同僚に、アジャイル・コミュニティの仲間に、悩みを打ち明けた。
みなさん暖かく、手を差し伸べてくれた。
もちろん、ただ単に仕事を丸投げすることではなく、自分が出来る事を見極め、キッチリやりきることは必要だ。
ただ、今回は上司も同僚も協力をしていただいて、本当にありがたく思っている。
そして、仲間にも本当に助けられた。

2. 仕事を効率化する

そして、余裕を作るために、仕事の効率化を進めたいと思っています。
ここはまだ取り組んでいる最中なので、何か良いアイディアあれば是非教えてください!
僕が10分でも余裕ができれば、その間、娘が抱っこでき、娘にべったりな妻にもわずかに余裕ができる。
結果、こうした方が周りが幸せになる、という事を今は確信している。

最後に「自分が幸せになる」ということについて

様々悩んだ僕がこの3ヶ月で結論したことは、自分が幸せになる、ということは「自分の持っている事を認める」ということに尽きると思った。
よく、水が半分入っているコップを見て「半分も入っている」「半分しか入っていない」というが、そこであくまでも「半分も入ってる、ラッキー!」と言い張るのだ。

  • 水が半分以下になっても、「水が入ってる、ラッキー!」
  • 水が無くなっても、「コップがある、ラッキー!」
  • コップが砕け散っても、「破片が綺麗、ラッキー!」
  • 失敗に成功した!

なので、この先何があっても、心の中で号泣していても「ラッキー!」と言い続けたいと思っています。
娘のために、周りのために、僕自身のために。

今日はバラバラと書いてきました。
拙い経験ですが、父親の方、これからお子さんを出産する方、誰かのお役に立てれば幸いです。
最後までお読み下さり、ありがとうございます!

【イベントレポート】「離れて、共に 市場経済を超えたニーズへの対応」

はじめに

2020年7月25日に開催された、ミキ・カシュタンによる、特別オンラインWS「離れて、共に 市場経済を超えたニーズへの対応」のイベントレポートです。

スピーカーはミキ・カシュタン。
名前だけは知っていたけど、オーガナイザーの安納献さんによれば、日本にNVCを広めることになった源流の一人、そして世界で最も影響力のあるNVCトレーナーの一人とのこと。

今回はミキがコロナ禍で感じた市場経済主義の限界と、それを乗り越える方法を一緒に考えるという趣旨のワークショップでした。

www.facebook.com

スピーチ

f:id:norihiko-saito-1219:20200726113928p:plain

質疑応答

Q. (地域コミュニティで交換する経済は)みんなが交換できるリソース(資源)を持っていることが前提となっているが、個人が細分化され、そのようなリソースを持っていないことが問題では?

全くもって同意します。
最初に政府を頼らなければならないのは、みんなが遠いところにある、大きな組織に頼っているから。
ただ、みんながどこにいようと、それを始めて欲しい。
たとえば、車から始められるかもしれない(→カーシェアリング)。
一つのストーリーをシェアさせて欲しい。
ソ連崩壊時、キューバへの贅沢品ではなく、日用必需品の輸入も途絶えた。
当時、急に自給自足にならないといけなかった。
今でもキューバの食料品の半分は、首都ハバナで生産されている。
環境が制限されると、私たちはよりクリエイティブになる。
今のこの時期は、創造性を引き出すのに良い時期。

Q. ミキさんの話の背景には、社会契約があるのでは? 日本は天皇制で2000年いったので、オルタナティブを探しづらい。ミキさんの社会契約という考え方が、簡単にしてるのでは?

私は日本の歴史にほとんど詳しくないので、想像で答えます。
天皇制の遥か前に、何かがあって、いのちから離れていった。
全ての文化の太古の知恵は、日本でも同じだと思う。
どこかの時点で、いのちを信頼するところから離れていった。
いのちから離れていたら、恐れに入った。
恐れに入ったら、どれだけ必要かどうかがわからなくなる。
恐れの中では、実際に必要な分量が分からなくなる。

自然の豊かさの代わりに、そこに生まれるのは2つの悪。
1. 製造された欠乏
2. 恐れ

恐れが起ると、争いが起こる
そこでは国家を作るのがとても魅力的になる

国家の機能は、暴力をコントロールすること。
1. これは正当化された暴力、正当化されてない暴力と区分ける
2. 国家は市場を生み出す。税金を生み出すためのお金を産むのに役に立つから

みなさんが乗り越えなきゃいけない権力への恐れは2層ある。
1. 天皇、もしくはてっぺんにいる強い男性への恐れ
2. グループ全体が持つ、同調圧力、グループが持っている権威

日本文化の強みは、全体を考えること、それは有利にも使える。

Q. 私たちは結局、プラスチック産業などは必要なのではないか?

エネルギー、石油、はそう長く持たない。
私たちはあまりにも利便性に慣れ親しんでいて、それ抜きでどう生活したら良いかのイマジネーションを失っている。
私たちは死と向き合う必要がある。
私たちを殺そうとするものをコントロールしようとするとそこには、より多くの死が集まります。
近代の文化は死を失敗と捉えている。
私は自然の命の一環として見ている。
この惑星の資源の範囲内で暮らし、消費を減らし、もう二度と合わない人の面倒を見る。

Q. ミキがこのワークショップで一番伝えたかったことは何か?

交換(exchange)は、利己主義に基づいている。
流れ(flow)は、寛大さに基づいている

私は、人間のみならず、全ての命を大切にするあり方がみたい。

人間のみならず。

(もう一問とても興味深い問いがあったのですが、ちょうど飲み物を取りにいってて聞けなかったので割愛)

感想

オーガナイザーの安納献さんがこのワークショップを開催した理由の一つとして、「ミキみたいな人がこの星にいて、こんなすごいことを言っている人がいるよと伝えたい」と言っていましたが、まず私が強く感じたのもミキの圧倒的な存在感でした。
ミキは、自分の人生すべてを目的のために捧げよう。と思い、目的に添わないことはやらない人で、このワークショップもミキに断られ続け、数年掛かりでようやく実現したとのこと。
まずはそんなミキ・カシュタンの存在と生き方に衝撃を受けました。
そして、衝撃を受けたのはミキ自身だけではなく話の内容にもです。
話は国家誕生前の数万年の規模に及び、資本主義など既存のイデオロギーに染まっている自分にはまだ消化に時間がかかると感じました。正直最初は「お花畑」ではないかと感じていましたが、質疑応答やミキのブログを読むと、これはお花畑ではなく、地に足がついた思想に支えられた社会変革運動だと思い直していきました。

thefearlessheart.org

それに......市場に委ねるのではなく、政府に頼るのでもなく、地域コミュニティで必要な分だけを与え合う社会。それは決して夢物語ではなく、すでに、社会のあちこちで芽吹き、このコロナ禍で加速しているようにも感じています。

今回、ミキは理想という種をみんなに植えたかったのだと思います。

もちろん理想を実現するのには多くの障害がありますが、種を植えられた私たちは、明日から少しだけ行動が変わるような気がしています。そしてその小さな行動の積み重ねが、大きく社会を変えていくのではないでしょうか。
私も今日からできることを探そうと思ったワークショップでした。

さいごに

今回はミキ・カシュタンの特別WS「離れて、共に 市場経済を超えたニーズへの対応」のイベントレポートを書きました。
イベントに参加できなかった方が少しでもイベントの雰囲気が感じる助けになれば嬉しく思います!
そして、想像より遥かに大変なイベントを企画、実現してくださった運営チームの安納 献、鈴木 重子、石川 咲子、石川 世太の皆様、ありがとうございました!

新人スクラムマスターやアジャイルコーチ必読!?『アジャイルコーチヒッチハイク・ガイド』【現在無料】

はじめに

今回は、アジャイルコーチに限らず、スクラムマスターやエンジニアリングマネージャーにも是非オススメしたい『The Hitchhiker's Guide to Agile Coaching(アジャイルコーチヒッチハイク・ガイド)』という本をご紹介します。*1
現在(2020年07月23日)、今なら無料で以下よりダウンロードできます。

www.agile42.com

f:id:norihiko-saito-1219:20200723004646p:plain

私は様々なエンタープライズ企業でアジャイル導入支援をしています。
この一年、様々なアジャイル関連書籍を読んだ中で、どの本も素晴らしいと感じる一方、仕事で感じているモヤモヤや困り事に対応していない、というもどかしさを感じていました。

今、ようやく探していた一冊に辿り着けたような気がしています。

てわけで前置きが長くなりましたが、なぜ本書をオススメしたいのかと、本書で紹介されているテクニックの一部をご紹介していきます。

本書をオススメする理由

本書をオススメするのは、あまり語られることがない、アジャイルを定着させるためのコーチングスキルについて実践的なテクニックやフレームワークが豊富に紹介されているためです。

Agile thinking and agile practices are easier to learn than coaching skills. There are agile books, Scrum training, workshops, conferences, communities and a lot more available, however for many people the main problem is, in fact, the unlearning of old thinking patterns.

アジャイル思考やプラクティスはコーチングスキルよりも簡単に学べます。アジャイル関連書籍、スクラムレーニング、ワークショップ、カンファレンス、コミュニティ、その他多くのものがあります。

前書きに、アジャイル関連書籍は「仕事で感じているモヤモヤや困り事に答えていない」と書きましたが、それもそのはず。

  1. アジャイルマインドやプラクティスのスキル
  2. アジャイルを定着させるためのコーチングスキル

1と2は異なるスキルなのにも関わらず、私が1の本に2の情報に求めていたからなのです。
そして、1に関する情報はあふれていますが、2に関する情報はまだまだ多くありません。*2

They have started out as new agile coaches with reasonably good agile knowledge, but do not know enough about coaching. If you belong to this group, this book is for you.

彼らは、合理的で優れたアジャイルナレッジを持ちながらも、コーチングについて十分な知識を持っていない新人アジャイルコーチとしてスタートしました。
もしあなたがこのグループに属しているなら、この本はあなたのためのものです。

まさに私がそうでした。

全くコーチングスキルがないままこの世界に飛び込んだ私が取れた唯一の選択肢は、「狂信者」になることでした。つまり、現場で、アジャイルマニフェストスクラムガイドを掲げて「スクラムではこうしてください!」「それはアジャイルマニフェストと違います!」と叫んでいたのです。

結果、変わらないどころか、悪化する現実......

なぜなら、

however for many people the main problem is, in fact, the unlearning of old thinking patterns.

しかし多くの人にとっての主な問題は、結局のところ、古い思考のアンラーニングです。

多くの企業にとってアジャイル導入時の主要な問題は「古い思考のアンラーニング」だからです。
経験的にも、古い思考をアンラーニングしながら新しい思考をインストールするためには、アジャイルに関するスキルと同じ位、優れたコーチングスキルが必要になります。本書は、そのための本なのです。

個人やチームにどう問いかけるべきか?

ここからは本書で紹介されているテクニックのごく一部をご紹介します。

ナラティブ・クエッショニング

どのように個人やチームに質問を投げかけるか? は、私のようなコーチング初心者にとってとりわけ難しいテーマの一つです。
そんな中、本書で紹介されている北欧の家族療法の理論家カール・トム(Tomm, K.)のナラティヴ・クエッショニングが参考になりました。トムは4つの質問を意識して質問することが重要だと言います。

1. リニア・クエッション(刑事の質問)
 直線的因果律の構え・探索的意図
 (いつ、何処で、誰が、何を)
2. サーキュラー・クエッション(探検隊の質問)
 円環的因果律の構え・探索的意図
 (一体全体どうなってるんだろう)
3. ストラテジック・クエッション(教師の質問)
 直線的因果律の構え・戦略的意図
 (正しく導くための質問)
4. リフレクシブ・クエッション(ファシリテーターの質問)
 円環的因果律の構え・戦略的意図
 (新しい物語へのきっかけを作る質問)

http://www.jahbs.info/TB2017/TB2017%202-6.pdf より引用

たとえば、プロダクトオーナーが複数いる現場を、一人のプロダクトオーナーに導きたいとします。

以前の自分は以下のようなストラテジック・クエッションをふりかざし、教師のように振舞うのが精一杯でした。

  • スクラムガイド にはプロダクトオーナーが何人と書かれていますか?
  • 本来は何人が望ましいですか?

しかし、ストラテジック・クエッションだけでは現実は動きません。
現実を動かすためには、以下のようなリニア・クエッションで刑事のように、事実を確認する必要があり、

  • いつからプロダクトオーナーが複数人になりましたか?
  • 複数人のプロダクトオーナーは具体的に何をしてますか?

以下のようなサーキュラー・クエスチョン文化人類学者のように、組織や人がどのような世界観と構造を持っているかを確認する必要があり、

  • なぜプロダクトオーナーが複数人になったのでしょうか?
  • プロダクトオーナーが複数人いることで何か課題はありますか?

そして、以下のようなリフレクシブ・クエッションファシリテーターとして、相手の世界観を尊重しながら、アジャイルとしても適切な地点に着地させる必要があります。

  • プロダクトに一番詳しいあなたが、開発チームとモブでプロダクトバックログアイテムを作ることで知識をシェアしていくのはどうでしょうか?

経験豊富なコーチやコンサルタントを観察すると、この質問の使い分けを上手にしていることに驚かされます。

ブリッジクエスチョン

アジャイルコーチは個人だけではなく、チームに対しても質問しなければなりません。
本書が素晴らしいのは個人に対してだけではなく、チームに対する問いかけのテクニックやフレームワークも豊富に紹介されていることです。
たとえば、メンバーの態度、経験、意見、提案の間の架け橋となり、チームの共通理解を築くためのブリッジクエスチョン(bridging questions)は、発言するメンバーの意見が偏っている場合や、形成期のチームに有効だと感じています。

  • ブリッジクエスチョンの例

“What similarities do you see in what different people are saying here?”
“In what way do the things Paul is speaking about link to your interest in the subject? What can you add to this?”
“In what way are you inspired when you hear the others discuss the subject?”
“Is there something you feel that the others have forgotten in their discussion?”
“In which way can you see that your thoughts are aligned with other people’s opinions? In which way do your thoughts differ from the others’ opinions?”


"異なる人々がここで述べていることにどのような類似点がありますか?"
"パウロが話していることは、どのようにしてあなたの興味と結びついているのでしょうか? あなたはこれに何を加えることができますか?
"他の人たちがこのテーマについて話しているのを聞いて、あなたはどのような点で感銘を受けましたか?"
"他の人たちが議論する中で、何か忘れていると感じることはありますか?"
"自分の考えが他の人の意見とどのように一致していると思いますか?自分の考えと相手の意見はどのように違いますか?"

おわりに

今回は、『The Hitchhiker's Guide to Agile Coaching』をご紹介しました。

もちろん本書では「ナラティブ・クエッショニング」や「ブリッジクエスチョン」などの質問についてだけではなく、傾聴やシステムコーチやスポーツコーチとアジャイルコーチの違い、各スクラムイベントでのチェックポイント、5Dモデル、チームの成長モデル等、明日から役に立ちそうな様々なテクニックやモデルが取り上げられています。

Agile coaching is not magical handwaving. It is a soft but very very structured skill.

アジャイルコーチングは、魔法の手振りではありません。
ソフトではありますが、非常に、非常に構造化されたスキルです。

本書は、アジャイル推進者のための本に見えて、実はアジャイルではなくても有用な本です。
私のようにアジャイル推進で苦戦している方だけではなく、組織に新しいことをもたらそうと苦戦している方が一人でも多く本書を知るきっかけになればと思います。

最後までお読みいただき、ありがとうございました!

*1:引用は全て『The Hitchhiker's Guide to Agile Coaching』からの筆者の仮訳です。

*2:もちろん『アジャイルコーチング』や『Coaching Agile Teams』など素晴らしい書籍がありますが、本書はコンパクトながらとても充実した内容でした。また、以下の本を読むのが楽しみです! www.amazon.co.jp

アジャイルコーチが見た、上司を説得するための5つのポイント

昨日、「ほめる」ことについてウダウダ書いてた挙句次第に気に入らなくなりボツにしてしまったので、今回は連続Tweetみたいなノリで、これまでのスクラムマスターやアジャイルコーチの経験を通じて、組織を変えるためのポイントを書いてみたい。

今回は、組織を変えるために避けて通れない「上司(や他部門やステークホルダー)」を説得する際に普段心掛けている極私的ポイントをまとめました。

f:id:norihiko-saito-1219:20200719162925p:plain

1. 相手の言葉を使う

あるUXデザイナーが、エンジニアとの合同ミーティングを開催した際の経験をシェアします。
私を含むエンジニアはUXデザイナーの提案に懐疑的で、会議も重苦しい雰囲気に包まれていましたが、そのUXデザイナーが、
「それってドメイン駆動設計におけるユビキタス言語みたいなものですよね」
と普段エンジニアが会話している用語を使ったことから、「お、この人分かってんじゃん」という空気が流れ、一気に場の雰囲気が打ち解けてエンジニア全員が彼に耳を傾けていきました。

その時分かったことは、相手に提案を聞いてもらうためには、「この人は自分のことをわかっている」と思わせる必要があり、「相手の言葉を使う」ことはそのための有効な手段だということ。

アジャイルスクラムを推進する際、私たちはついスクラム用語で話しがちになりますが、それは「私たちが所属する言語圏の言語」です。まずは「相手が所属する言語圏」を見極めましょう。事業責任者をプロダクトオーナーなどと勝手に翻訳することには注意です。

  • 相手の言語を観察/傾聴する
  • その言語をそのままコピーする
  • 書籍などを読み、相手の言語をより理解する(対セールス部門だったらセールスの、対マネージメント部門だったらマネージメントの)

2. 行動の背後にある"意図"に注目する

私たちは、上司やマネージャーの提案を見て、しばしば「間違っている、ついていけない」と思う。

ただ現在、様々な組織を経験して思うのは、上司やマネージャーが間違うのは、意図ではなく、意図を実現するための戦略(手段)であることがほとんどだということ。そして従来型組織の上司やマネージャーは意図を伝えることが苦手な方が多いことがこの悲劇に拍車を掛けます。

多くの組織で悲劇は、以下のように起こります。

  • メンバーに自律的に働いて欲しい → 「よし、そうできるように精一杯アドバイスをしよう」
  • もっと効率を上げたい → 「よし、全員に仕事を詰め込もう」
  • もっと規律を高めたい → 「よし、チャラチャラしている付箋は禁止しよう」

なので私たちは、上記のような提案を聞いても、即座に否定するのではなく、その背後にある意図を汲むことが重要となります。大変なのは、表面に現れるものから暗号のように意図を読み解く必要があることです(上司に限らず私たちだって「愛している」と伝えたくて、相手を「なんて自分勝手な人なんだ!」と怒鳴ったりする)。

経験上、抵抗派の上司もアジャイル開発の推進メンバーも、「メンバーに自律的に働いて欲しい」「もっと効率を上げたい」「もっと規律を高めたい」というような共通の意図を持っている事が多いのです。もちろん従来型開発とアジャイル開発では、たとえば効率という観点でも、リソース効率やフロー効率というように採用する戦略は正反対になりますが。

即座に相手を否定せず、相手の意図を理解し、それを満たすような手段という形で提案すれば、上司やマネージャーに受け入れられる可能性が高まります。もしかした苦手な相手とも、意外と自分と重なる意図を持っているかもしれません。

3. 小さくはじめて信頼貯金を貯める

これも多くの方が言っている事ですが、結局の所、上司や他部門に、自分の提案を通すためには「実績を上げて信頼を勝ち取る」しかありません。これは社内のスクラムマスターでも社外のアジャイルコーチでも同じです。そして初めから大きな実績を上げることは困難なので、なるべく小さな成功体験を積み重ねて信頼貯金を貯めることが重要になります。

ただし、小さな成功体験にもリスクがあります。それは周囲が「もう十分達成した」と思い込んでカイゼンをやめてしまうこと。なので、小さな成功体験をある程度重ねたら、どこかでギアチェンジをして変化を加速させると良いと思います。

焦ることはありません。
私が見る所、信頼貯金には複利がつきます。
ただし、失うのも一瞬ですが......

4. あなたの力を意識する

さて、これまで上司や他部門に説得することをテーマに話していましたが、そもそも自分は提案できる立場ではない、役職上の権力がないから組織なんか変えられっこない、という人もいるかと思います。

というか、ぶっちゃけ、それは私です。

私は10年間以上、ある孫請けSIerで平社員としてWebエンジニアをしていました。会社は上意下達のカルチャーであり、そこでは上司が絶対でした。
意思決定とは絶対的な権力を持った上司するもので、部下はそれに従うものだとずっと思ってきました。

私は、役職的な権力だけを力と勘違いし、「孫会社だから、平社員だから、派遣だから何もできない」と無力感をずっと抱えて生きてきました。しかし、心理学者のJ.R.P.FrenchとB.Ravenは「人々がリーダーの要求に応え、命令や指示に従う根拠は、①強制的パワー、②報酬的パワー、③合法的(地位・役職)パワー、④人間的(好感)パワー、⑤情報的パワー、⑥専門的パワー」と言っているそうです。

will-systems.net

つまり、人を説得し、組織を変えるのに必ずしも地位や役職は必須ではないのです。
さらに言えば、あなたはあなたの影響力で、既に組織を変化させ続けています。

組織においては全ての関係性は連続的につながっています、
先程のバタフライエフェクトの例のように、あなたが隣人に小さくとも影響を与えることで組織は少しづつ変化しています。
普段は意識出来ていないかもしれませんが、貴方は毎日組織で何かアクションをするたびに関係性に影響を与え変化させているのです。

note.com

先輩アジャイルコーチは「上司を変えることはできないが、上司に働きかけることはいつでもできる」とよく現場で伝えています。

あなたの力を意識し、信じて、遠慮なく上司に働きかけていきましょう。

5. 説得しない(人は変えられないことを知る)

大学時代、授業中に「告白は必ず失敗する」と言った教授がいました。

理由を訊ねると、「本当にお互いが好きだったらわざわざ告白という不自然な儀式をしなくても自然に付き合っているはずだ、相手が好きではないから告白をするのだ」との答えが返ってきて、なぜだか不思議と記憶に残っています。

人を説得することは告白と似ています。

これまで人を説得することについて語ってきましたが、不思議なもので、頑張って人を説得しようとすればするほど、相手はそこにコントロールの意図を感じ取り、拒絶を強めます。逆説的ですが、他人は変えられないことを認識してはじめて、他人が変わる可能性が開けるのです。

人に説得する前に、まずはあなた自身が変わりましょう。
そのためには「XPを広めるためにはどうしていけばいいか」という質問に対するケント・ベックの回答が参考になります。

「XPを広めるにはどうしていけばいいか」という質問に対しては,Beck氏は「まずは努力して自分を変える」ことだと答えた。「自分が変わることによって,立ち居振る舞いや行動がどう変わったかを人に見せる。その変化がどれだけプラスの方向に働いているかを証明する。自分がよい方向に変われば,対人関係もよくなる。そこから信頼が生まれる。そこまでいけば,まわりは『自分も変わってみようか』と思う」(同氏)。「相手を説得しよう,相手が言うことを覆して自分が言うことを納得させよう」という態度では決して伝わらないのである。「まわりの人間のどこが悪い,ここが悪いという点に注目するのではなく,ポジティブな方向性でよりよくものごとを変えていく」という心構えが必要だという。

xtech.nikkei.com

おわりに

今回は、組織を変えるために避けて通れない「上司(や他部門やステークホルダー)」を説得する際の普段心掛けている極私的ポイントをまとめてみました。
はじめは連続Tweetのノリで書こうと思いましたが、意外と分量が多くなって反省しています。
上司や組織との関係は以下のようにまだまだ語りたいトピックが多いため、また機会を見つけて話したいと思います。

  • "事実"と"意見"を分けて話す
  • それでもダメだったらとっとと逃げ出す

もちろん、これは私の経験によるもので、あなたの組織に適用できるかどうかはわかりません。
ですが、一つでも使えそうなアイディアがあればとても嬉しく思います!

最後までお読みいただきありがとうございました!

軽い気持ちや冗談で相手を批判する時、自分の中で起こっていること

つい先日、本人としては軽い冗談のつもりで他人のブログを批判してしまい、大切な人を傷つけてしまったことがある。

もう二度とこんなことを起こしたくない、という欲求がある。
人とのつながりをもう一度取り戻したい、という欲求がある。

そのため、軽い気持ちで相手を批判する時、自分の中で起こっていたことを最近探究しているNVC(非暴力コミュニケーション)の助けを借りて考えてみたい。

f:id:norihiko-saito-1219:20200708221655p:plain

f:id:norihiko-saito-1219:20200708221727p:plain

批判する時に湧き上がっている感情

判断する、批判する、評価する、解釈を加えるということはどれも、自分が必要としていることが満たされていないという遠回しの訴えだ。

www.amazon.co.jp

僕が人に批判的になってしまうのは、うらやましさや妬ましさがある場合だ。

  1. その人は、いつか辿り着きたい場所にいる。それは、自分が辿り着きたい場所からいかに遠いかを痛感させる。その痛みをぶつけたくなってしまう
  2. その人は、注目を浴びている。それは、自分が注目を浴びていないことを痛感させる。その痛みをぶつけたくなってしまう
  3. その人は、輝かしく見えるキャリアを歩んでいる。それは、自分のキャリアがいかに不安定かということを痛感させる。その痛みをぶつけたくなってしまう
  4. その人は、楽しそうに仕事をしている。それは、自分の仕事の苦しさを痛感させる。その痛みをぶつけたくなってしまう

自分はその湧き上がった痛みや感情をどこかで恥ずかしいと感じている。だからなるべく他人に悟られないよう、冗談や軽口の形でなるべくわからせないようにするのだ。

感情の大元にあるニーズ

けれどNVCが自分にとって大きな助けになったのは、それら一見醜くて目を背けたくなるような感情の大元にも、人間としての普遍的なニーズがあり、そしてニーズは全て美しいと主張しているところだ。
もともと感情に美しさや醜さはない、醜くみえる感情は、美しいニーズが満たされていないという現れなのだ。

わたしたちの言葉(言動)はすべて、そのひとのニーズを表しています。
ニーズとは、(ひとのもっとも深いところにある)行動の源となる動機です。言葉を口にしたときに、そのひとのなかで本当に大切にしているものです。

わたしたちには、いつでも「『人生の普遍的で美しい質』を満たしたい」という思いがあります。

note.com


最初に湧き上がった感情の背後にあるニーズをNVCの感情とニーズリストにあるニーズの言葉で現してみたい。

nvc-japan.net


1. のニーズは、"成長"や"所属、帰属意識"
2. のニーズは、"理解してもらうこと"や、"共鳴・共振"
3. のニーズは、"安心"
4. のニーズは、"気楽さ"や、"楽しみ"

おわりに

今まで言ってきたことは、決して自己正当化ではない。全ての言動や行動が普遍的な美しいニーズに基づくからといって、もちろん何を言っていいわけではない。自分の言動や行動の背後には美しいニーズがあるのと同様に、相手の言語や行動の背後にも美しいニーズがある。今回、自分の痛みと向き合うことを恐れて、軽口の形で相手を非難することは、相手の大切なニーズを損うことを学んだ。

これからは相手に批判的なフィードバックをしたくなったら、自分の中に湧き上がるネガティブな感情に向き合い、その大元にあるニーズに目を向けたい。そして、相手の中にあるニーズをできるだけ推測したい。その上で、言葉を紡いでいきたいと強く考えている。

新しいふりかえりのアクティビティ: Requestについて

最近クライアント先で実験しているふりかえりのアクティビティが、チームや全体に良い効果をもたらしつつあると感じるため、アクティビティを「Request」と「KPTR(=Request)」とそれぞれ名づけてシェアしたいと思います。

「Request」のコンセプトです。

チームのカイゼンと同じくらいのエネルギーを、他者へのリクエストに向けることで、チームのみならず「チームを含むシステム全体」のカイゼンと調和をはかるためのアクティビティ

また、Requestが効果的なチームは以下を想定しています。

  • 関係者が多いプロジェクトの大企業等のスクラムチーム
  • 開発チームだけでふりかえりを実施しているチーム

f:id:norihiko-saito-1219:20200703193945p:plain

作成した背景

これまで、様々な企業でのスクラムマスターやアジャイルコーチの経験を通して、チームでカイゼンをするというアジャイルにおけるふりかえりのコンセプトは素晴らしいですが、実際の運用では以下のような問題があると感じてきました。*1

  1. チームだけで解決できるProblemを選ぶ中で、チームがチーム以外のことを考えなくなる
  2. チームだけで解決できるProblemを選ぶ中で、部分最適に陥り改善インパクトが低下していく

そして、上記の結果、以下状態になったチームも少なからず経験してきました。

  • チーム自身に対して無力感を抱くようになる
  • チーム以外に対して批判的感情を抱くようになる

無力感や批判的感情を抱いたチームは、チーム内では楽しく活動できるもの、マネージャーやステークホルダーなど他者との健全な関係性を抱けないまま、その偉大なパワーを次第に弱めていきます。

上記を解決するため、チームのProblemに対してチーム自身で解決策を図ると同時に、チーム以外の他者に対して積極的にリクエスト(=お願い)することを要素として追加したのが「Request」です。

Requestのやり方

  1. チームメンバーで課題の原因分析する
  2. チームのTryと他者へのリクエストを決める

1. チームメンバーで課題の原因分析する

まずは、チームメンバーで話し合いたい課題の原因分析をします。なるべくチーム内で閉じない、組織全体に関連しそうな課題を選択すると効果的です。*2

まずホワイトボード中央に課題のふせんを配置し、あとは「なぜなぜ分析」や「マインドマップ」やシステム思考の「因果ループ図」などで原因分析していきます。

この時、チームだけで解決可能な原因と、他者の力を借りる必要がある原因のふせんを色分けするのがポイントです。

f:id:norihiko-saito-1219:20200703193748p:plain

2. チームのTryと他者へのリクエストを決める

上記分析の結果から、チームのTryと他者へのリクエストを決めます。

上記での「チームだけで解決可能な原因と、他者の力を借りる必要がある原因」の境界線がチームの限界点です。
なので境界線付近の原因について、チームのTryと他者へのリクエストを決めます。

ここでは、自身へのTryのみならず他者へのリクエストを「SMART Goals」の考え方を活かしてなるべく具体的にすることがポイントです。*3具体的なリクエストであればあるほど、リクエストが受け入れられる可能性が高まるからです。*4

(リクエストの例)

  • 悪い例: 開発チームのことを考えてもっと早めに動いて欲しい
  • 良い例: スプリント開始前までに、スプリントで必要なPBIのリソースを用意して欲しい

KPTRのやり方

「KPTR」は「Request」の簡易版です。

KPTや類似するYWTなどのアクティビティでの「何をすべきか決定する」フェーズで、上記を参考に、チーム自身のTryに加えて、具体的に他者にリクエストしたいことを決定します。

想定される疑問

「Request」や「KPTR」はこのブログで公開するのでもちろんまだ具体的なリアクションはありませんが、これらのアクティビティに対する想定される疑問についてお応えします。

どうせリクエストが通らないのでは?

このアクティビティを聞いて「リクエストしても、どうせ上司や顧客は聞いてくれないよ......」という疑問が浮かぶかもしれません。

しかし経験的には、他者が拒絶するのは思いつきのような雑な提案や批判です。
このアクティビティでは以下のような工夫を重ねることで、リクエストが実行される可能性をできる限り高めています。

  1. 課題分析内容や、他者へのリクエスト内容がチームで合意できている
  2. 他者への丸投げではなく「ここまではチームは実施したので、ここから先は手伝ってください」という形のリクエストになっている
  3. リクエストが具体的である

チームの甘えにつながるのでは?

また、このアクティビティを聞いて「チームの甘えにつながるのでは?」という疑問が浮かぶかもしれません。

ですが、このアクティビティはチーム自身をカイゼンさせるよりも、勇気が必要になる場合があると感じます。

個人的な経験からも、それくらい他者へのお願いというのは難しいものです。

お願いは常に、断られたらどうしようという恐怖がつきまといます。なので現実はお願いする代わりに、遠慮や、我慢や、命令や、批判であふれています。「Request」 はチームを甘えさせるものではなく、チームに勇気を持って正々堂々と他者にお願いをすることで、チームの成長と周囲との健全な関係づくりを促すためのアクティビティなのです。

さいごに

今回は顧客先で実験中のふりかえりのアクティビティである「Request」をご紹介しました。
これからはもっともっとふりかえりのアクティビティを作っていきたいと思います!

もしご興味があれば、フィードバックや、自分のチームでも実験していただければ泣いて喜びます!😭

最後までお読みいただき、ありがとうございました!

*1:他のエントリでより詳しく考察しているため、もし良ければお読みください。 norihiko-saito-1219.hatenablog.com

*2:「Request」はLeSS(大規模スクラム)のオーバーオールレトロスペクティブに影響されていますが、1. オーバーオールレトロスペクティブよりも手軽にできること、2. 他者へのリクエストの有無が異なります。 less.works

*3:「SMART Goals」については以下の記事が参考になります。 qiita.com

*4:具体的なリクエスト程実行可能性が高いことについては、NVC(非暴力コミュニケーション)が参考になります。「相手から受け取りたいものがはっきりすればするほど、必要としていることが叶う可能性は高くなる」 www.amazon.co.jp