「エンパワーメント」について調べてみました。

ども、ひぐちぇです(゜д゜)ﾉ

たまーに気になったとき、部分的だったりではありますが、「スクラムガイド」を読み返してます。

スクラムガイド 2017 日本語版
https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf

ちょいと今回はそのスクラムガイドのP6の「開発チーム」の項目に、

開発チームは、自分たちの作業を構成・管理するために、組織から体制と権限を与えられている。
その相乗効果によって、開発チーム全体の効率と効果が最適化される。

と書かれており、ここで書かれている「権限を与えられている」という箇所について、

「いったい、どんな権限が与えられているのか？」が気になったので、調べてみました。

まずは、英語版のスクラムガイドで、ここの箇所ついて確認しました。
その結果、「empowered」という単語が使われていることがわかりました。

そして、「empower」という言葉を調べてみると、
どうやら、「権限委譲（Authority）」と「自立行動支援(Ability)」の２要素に分かれるらしく、『責任(Accountability)と自立(Responsibility)という相反するこの２つをバランス良くマネジメントすることがポイントである。』と書かれておりました。

参照：masaki-ravens.com

他のページでも同様の事が書かれております。
『「自律性促進」「権限移譲」「能力開花」などといった意味が多くなっています。』とのこと、、

参照：www.kaonavi.jp

さらに調べてみると、
権限委譲（empowerment）と権限移譲（delegation）は異なるものであるとの事です。

権限委譲（empowerment）：事前に決められた業務について、上司の決裁なく部下の判断で進行してOK。ただし、その結果責任はすべて上司が負うというもの
権限移譲（delegation）：こちらは、権限だけでなく、責任も含めてそのままスライドするというもの

参照：bizhint.jp

なかなか奥が深いです。
つまりは、スクラムでは、開発チームに「empowerment（権限委譲と自立行動支援）」を行うことによって、

・スピーディーな意思決定による市場競争力アップ
・開発チームのモチベーション向上
・自己裁量で仕事できることによる目的意識と責任感の強化
（※他にもあるかも、、）

などを目指しているのでしょうね！！

スクラム開発をやっていく上で、励みになりそうな名言集①

ちょいと今回は、スクラム開発をやっていく上で、励みになりそうな名言を集めてみました(゜д゜)ﾉ
また２回目もやりそうな気がするんで、①と付けとりますｗ

「失敗ではない。うまくいかない1万通りの方法を発見したのだ」

エジソンの言葉です。
まさにトライ&エラーな考え方！この精神で取り組みたいです！

【参考】
tabi-labo.com

「許可を求めるな謝罪せよ」

いいアイデアを思いついて、いちいち事前に許可を求める暇があったら、すぐにでもやってみて駄目だったら謝ればいいじゃんって話です！

【参考】
scrapbox.io
www.jmac.co.jp

「人にものを教えることはできない。みずから気づく手助けができるだけだ。」

ガリレオ・ガリレイの名言です。
ほんとそう。。同じ部内の社員でも学ぼうとする姿勢のない人間にものを教えることになんてできないですよ。勘弁して欲しいわー

【参考】
www.a-inquiry.com

「成功者になろうとするな。価値のある人間になれ」

アインシュタインの名言です。
成功者になろうとすると、本当に大事な事を見失ってしまうということですね。。
常に価値を生み出せる人間になりたいものです。

【参考】
www.a-inquiry.com

とりあえず、こんなもんですかね。
また、良さそうな名言あったら書き出してみようと思います。

「Scrum Masters Night! in Fukuoka ～第4夜～」の参加レポート

おそくなりましたが、
9/12に「Scrum Masters Night! in Fukuoka ～第4夜～」に参加してきました。

smn.connpass.com

いつも通り、ディスカッションしたいお題を出し合って、2題について同時進行でスタート

（１）「『目的』さえ共有できていればチームとして成り立つのか？」を実験するゲームをやりました。
（２）スクラムをやっていく上で利用できるツールとして使っているものはあるか？

私は、主に（１）に参加しました。

（１）「『目的』さえ共有できていればチームとして成り立つのか？」を実験するゲーム

どんなゲームかというと、８人居たので、４人で１チームの２チームを作り、付箋紙を各人１枚ずつ持ち、そこに「各チームで合計が、ファシリテーターがゲーム開始時に言った個数になるように各人が自由に★マークを書く」というもの。
ただし、条件として、
・相手に★マークを書いた付箋紙は見せない事
・ゲーム中の会話禁止
・ゲーム中のジェスチャーも禁止
・他メンバーは見ない
・時間は３分
至って簡単なゲームですね。

そして、１回目から、順次、回を重ねる毎に条件を少しだけ条件を解禁したり替えたりしていきます。

１回目：上記条件のみで、予めの打ち合わせなど無し
ファシリテーターが「１７個の星を書いてください」でゲーム開始
・・・４人なので、おそらく割る４した値ぐらいを皆書いてくるのだろうと思い、とりあえず、私は４つの星を書いてみました。
３分経ってから、一斉に見せ合い、答えわせ、、、全く０の人も居るし、てんでバラバラｗｗｗ
これは予想外でしたｗｗｗ結局全く合わず

２回目：上記の条件の「他メンバーは見ない」は無しで「他メンバーが書いている所は観察して良い」という条件に変更
１回目と同様に、「◯◯個の星を書いてください」でゲーム開始
流石に、その変更だけではあまり分からず、、しかし、１回目の感じからあまり皆が書いて来ないのだと思い、ちょっと多めに星を書いてみましたｗ
３分経ってから、一斉に見せ合い、答えわせ、今回は偶然でしょうが、だいぶ近い値になりました。

３回目：ゲーム開始後のジェスチャーはアリにする。ただし数を示すジェスチャーは無し
このルール適用で、合図を出してくれるメンバーが１人。別の１人には伝わっていたようですが、
私ともう１人には正確に伝わっておらず、、でも、なんだかんだで、初めての数一致！！やったねｗ

４回目：ゲーム開始前に作戦会議を実施
これが解禁になってから、「各メンバーに１～４の番号を振り、それぞれが、割る４した値を各人が書いていって、あまりをその順次特定の人が書く」という作戦を提案し、ゲーム開始
計算が早くわかったメンバーは、ジェスチャーでも伝えてくれ、
見事に、作戦が上手くいき、この回でも数一致！やったねｗ

このルールで安定っしょｗｗ

５回目：各チーム２名を入れ替え、作戦時間無しで実施
ゲーム開始後、先程のルールがジェスチャーで伝えれないか、がんばってみる。。
上手く伝わったようで、見事に数一致！！

これ、もう攻略したっしょｗｗ

最後に皆で、ネタ合わせしたのですが、もう１方のチームは、ある「１人が星全てを書く」という作戦だったようで、その発想はなかったｗｗｗｗ なので、５回目のメンバー入れ替え後では、作戦立てる時間がなかったので、適用できなかったとのことでした。なるほどねー
変わったゲームでなかなか楽しかったです^^

（２）スクラムをやっていく上で利用できるツールとして使っているものはあるか？

もう１方のグループがこの話題でお話してたようで、途中から混ざってきました。
調べ物してたときに私が見つけた、ABD（アクティブ・ブック・ダイアログ）という手法の話になって、えらく感動していたご様子でしたｗ

私もまだやったことないのですが、自社内で近いうちやる予定なのです！
ちなみに、↓こちらが、ABD（アクティブ・ブック・ダイアログ）です。
heart-quake.com

懇親会

今回は、いつもよりも名刺交換がんばりましたー
主に私のスクラムマスターの役割上の愚痴聞いてもらえてスッキリｗｗ

あと、知らなかった話、、「クルー・リソース・マネージメント」というお話が聞けました。
航空会社のコックピット内での事故防止を目的とした、コミュニケーション、リーダーシップ、意思決定などの教育活動だそうで、だいぶ早い時期から「心理的安全性」の重要さが示されているそうです。
ja.wikipedia.org

いやぁ、、知らなかったー(´・ω・`)

まとめ

ビール３本も飲めましたし、今回も楽しく過ごせました
次回はまた２ヶ月後かなぁー。また参加するつもりです。

「フロー理論」について調べてみた

先週、会社内部の勉強会で、たまたま「フロー理論」という単語ができて来たので、ちょっと気になって調べて見ましたー(゜д゜)ﾉ

まず、フローとは、Wikipediaによると、

フロー（英: Flow）とは、人間がそのときしていることに、完全に浸り、精力的に集中している感覚に特徴づけられ、完全にのめり込んでいて、その過程が活発さにおいて成功しているような活動における、精神的な状態をいう。ゾーン、ピークエクスペリエンス、無我の境地、忘我状態とも呼ばれる。心理学者のミハイ・チクセントミハイによって提唱され、その概念は、あらゆる分野に渡って広く論及されている。

出典：フロー (心理学) - Wikipedia

つまりは、無我夢中で取り組んでいる状態のことなのでしょうね。

この図によると、高い「スキルレベル」かつ、高い「挑戦レベル」のときにこういう状態になるようです。
そして、この状態を、「フロー体験」とか、「フロー状態」などと言うそうです。
この状態になったとき、非常に高い生産性を出すようなのです。スー◯ーサ◯ヤ人みたいですね！←

フロー体験（状態）を構成する8要素

↓の記事を参考にしました。
learn-tern.com

① 達成できる期待のある課題
② 行動への集中
③ 明確な目標
④ 直接的で即時的なフィードバック
⑤ 不快なこと、気になることを忘れる
⑥ 恐れを払い、成功を観る、高い統制の感覚
⑦ 自意識の消失による自己超越
⑧ 時間間隔の変容

少し補足：
①は、簡単では無いけども不可能では無いくらいの課題であることだそうです。つまりは、課題が「簡単である」かのような言い方は避けた方がいいのでしょうね。やってる方も意欲を失ってしまうでしょう。
⑥は、ちょっと分かり難いですが、他の記事みると、「状況や活動を自分で制御している感覚」と書かれておりました。つまりは、自分の状況（課題に取り組む環境）や活動（課題に対するやり方）は自分でコントロールできていると感じている状態という事でしょう。

「フロー体験」が生み出される主要な条件

↓の記事を参考にしました。
blogs.itmedia.co.jp

１．自分の能力に対して適切な難易度のものに取り組んでいる
２．対象への自己統制感がある
３．直接的なフィードバックがある
４．集中を妨げる外乱がシャットアウトされている

働いてもらう人達が高い生産性を出してもらうためには、こういった条件を満たす環境を作り出してあげることが大事という事でしょう！

「フロー理論」から分かる成長のループ

この資料の図がわかりやすかったです。
positiveinnovation.org

ある人（またはチーム）を対象にして、その対象のスキルレベルに応じた難易度の挑戦をさせ、その挑戦が成功する（良く評価をされる）と次第に慣れてきて、退屈に傾く、、そこで次は更に高い難易度の挑戦をさせて、、、とこのサイクルを繰り返すことで、人やチームを成長させると言っているのです。
そのためには、「１つの挑戦が終わる事＝結果に対して『評価』する事」が必要なわけで、つまり、短期間で適切な難易度の挑戦を繰り返し、その都度、達成度合いを評価する必要があるという事です。

ゲームやスポーツに置き換えるととてもわかり易いです。
↓で示されているようにフローサイクルに入り込むことで没頭し、その間、大きな生産スピードと成長を得るできるのでしょう。
scrapbox.io

私も昔、ゲームに没頭していた時期がありましたが、そういう事だったのですね！

あ、、あと、↓重要だと思ったので貼っておきます。

一つだけ、誤解のないように・・。人は仕事の中でさまざまな業務をこなしています。すべての業務にフローを求める必要はありません。また、会社全体の目標達成上からもそのような仕事ばかりを選ぶことが出来ません。熟達した仕事をすることもあります。また、その機会も多いものです。ここで言いたいのは、全てを「退屈」分野で仕事をするのではなく、いくつかは「フロー」が経験できるチャレンジレベルのものをもって仕事をしましょう、と言うことです。それで、自分を成長させることができるのです。

「スクラム」と「フロー理論」の関係性

ここまで書くと、なんか、フロー理論とスクラムって似ているように感じてしまいまして、もしかして、スクラムってのは、フロー理論が裏付けとなる仕組みなのではないかと思って調べてみました。

↓の資料を見つけました。
https://www.pmaj.or.jp/library/open/regular/kns20140613.pdf

９ページ目の最後のスライドに「アジャイルはチームとしてのフロー状態」と書かれていました。
（これ以外に関連を示す記事は見当たりませんでしたが、、）まぁ納得！！

「スクラム」では、『「フロー体験」が生み出される主要な条件』を満たしてあげることで、チームとしてのフロー状態を作り出そうとしているのでしょう。

１．自分の能力に対して適切な難易度のものに取り組んでいる
　→これはスクラムでは特に語られてないですが、チームがやっている仕事は簡単では無いことを認識してもらいましょう。

２．対象への自己統制感がある
　→スクラムでは、チームに「やり方（How）」に対する権限を与えています。

３．直接的なフィードバックがある
　→スクラムでは、毎スプリント後にスプリントレビューという形でのフィードバックや、ステークホルダーレビューという形でのフィードバックを得ることができ、これらにチームメンバーも参加すべきでしょう。

４．集中を妨げる外乱がシャットアウトされている
　→スクラムでは、これを行うのが、スクラムマスターの役目ですよね。

『「フロー理論」から分かる成長のループ』のところで、「短期間で適切な難易度の挑戦を繰り返し、その都度、達成度合いを評価する」ことが必要であると書きましたが、まさにスクラムではそれが可能なわけですよ！逆にウォーターフォールでは、その評価が最後にしかされないわけで、作業員の成長性や生産性も遅いということを意味しているのですね。

まとめ

『「フロー体験」が生み出される主要な条件』の４つがとても大事ですね。
今後、「なぜスクラム開発のそのやり方で、生産性があがるのか？」という話が出た際に、フロー理論を裏付けとして説明することができそうだということが分かりました。

↓の本が評価高いようで、ここで書いた事をきっちり勉強しときたいものです。

フロー体験 喜びの現象学 (SEKAISHISO SEMINAR)

フロー体験入門―楽しみと創造の心理学

書籍「『キングダム』で学ぶ 乱世のリーダーシップ」を読みました。

↓の本を読みましたー

『キングダム』で学ぶ 乱世のリーダーシップ

前に読んだ、↓と似たような本ですね。
junhiguchi.hatenablog.jp
キングダムの世界で起きた出来事（特にキャラクターの行動）についてピックアップし、リーダーとは何か？について説明してくれておりました。
１０個のリーダーの条件をあげており、とても読み易い本でした。

私が、特に心に留めて置きたいと思ったことを上げておきます。

先を見通してこそ細部を詰められる

ただ細かい指示を出せばいいわけでも、ただ放任でいいというわけでもなく、リーダーは先のこと（全体像）を分かっていなければ、細かい箇所なのか大きな箇所なのかの判断ができないわけで、そこまで分かった上で、細かい箇所については、部下に任せるという判断を下すべきという事を書いておりました。

全ての責任を背負ってこそ、全ての権限が与えられる

リーダー自身が全責任を追うという覚悟を見せてこそ、部下はその指示に従うのである。もし、部下が命令や指示に従わないとしたら、それは深から「このリーダーは責任を自分で負う覚悟がないな」と思われているのかもしれません。という事が書かれておりました。

誰も間違っていない。どれも人の持つ正しい感情からの行動だ

戦う理由は人それぞれ、「大義のため」「仲間のため」「愛する者のため」「私利私欲のため」「復讐を果たすため」など、さまざまあるが、いずれも人間の持っている正しい感情からの行動であるわけで、誰かが間違っているというわけではないと言うのです。仕事も同じですよね。色んな価値観の人が様々な理由でその仕事をやっているわけで、いずれも間違っているというわけではない。人間とはそういうものであるという事をリーダーは肝に銘じておかなければならない。ということを書かれておりました。

部下を信じなければならない

兵を道具として扱うのではなく、信頼すべき仲間として、家族として扱う姿勢で、兵達はやる気になり、力を発揮するのです。人間は１人では弱くても、２人、３人と仲間がいて、組織となると力を発揮することもあり、その組織としての強さや勢いを生み出していくのがリーダーの役割である。と書かれておりました。

将とは「智信仁勇厳」なり

最後の章で、リーダーには以下が必要であることが書かれてました。
『将とは「智信仁勇厳」なり』とは、孫子の言葉だそうです。
「智」・・・物事の本質を見抜く力
「信」・・・部下や取引先から信頼されること
「仁」・・・部下を慈しみ育てる心
「勇」・・・困難に立ち向かい信念を貫くこと
「厳」・・・組織を動かすルールを徹底し処断する厳しさ

孫子の兵法の中で、逆に駄目なリーダーのタイプ（五危）も紹介されてました。
「必死」・・・思慮が浅く、必死の覚悟だけであれば殺される
「必生」・・・生き延びることばかり考えていては捕虜にされる
「忿速」・・・短気で辛抱ができないようでは相手の挑発に引っ掛かってしまう
「廉潔」・・・体面を気にして清廉潔白なのは侮辱されて罠にかかる
「愛民」・・・兵や民衆に情けをかけて思いやりが強すぎるとその世話に苦労させられる

いずれも現代の仕事に置き換えることが可能ですね。。
こういったことに気をつけながら、リーダーを目指したいものです。

プロジェクト・アリストテレス「効果的なチームとはどんなチームなのか！？」

どもです。

最近、いろいろ調べてるときに、「プロジェクト・アリストテレス」というキーワードを聞いたので、調べてみました。

「プロジェクト・アリストテレス」というのは、Googleの取り組みで、パフォーマンスが高いチームとはどういう要素を持ったチームなのか？を調べた研究だそうです。

その結果の日本語訳がこちら、、
rework.withgoogle.com

結果だけを書くと↓こんな感じ

• 心理的安全性　…何を質問しても怒られない。ミスを報告して責められない事
• 相互信頼　…他のメンバーに対していい仕事をしてくれると感じている事
• 構造と明快さ　…チームの役割、計画、目標が明確である事
• 仕事の意味　…チームの仕事が、自分にとって意味があると感じている事
• インパクト　…チームの仕事が、外部に対して意義があり、良い変化を生むものだと思っている事

特に「心理的安全性」が重要だそうです。
最近、「心理的安全性」という言葉をよく耳にするようになったのですが、この研究結果が元になっているのかもですねぇ。。

↓「心理的安全性」を高める
https://rework.withgoogle.com/jp/guides/understanding-team-effectiveness/steps/foster-psychological-safety/

↓「チームの効果性に関するディスカッション ガイド」
https://docs.google.com/document/d/1obuZy1ioLNme3geU69cdCQM2cs8cu6QafG99NjrdY3o/export?format=pdf

生産性の高いチームを作るための要素として、↑の５つの要素が不可欠ということでしょうね。
これを踏まえてチームビルディングしていきたいです。

「スクラム現場ガイド」を残り全部読みました。

↓の続きです。
junhiguchi.hatenablog.jp

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

やっと読み切りましたー。（実際にはもっと前に読んでたんですが、あまり書く時間がなかった。。

Chapter 21 文化の衝突

途中から新たに参入したメンバーとやり方について、衝突してしまい開発チームにどうしても馴染めそうにない。そんな場合の話です。
スクラムマスターはそのメンバーに対して落とし所を探ったが、難しそう。。なので、上司にその新規メンバーを外してくれと頼んだもののやってはくれなかった。こんなとき、スクラムマスターは、その新規参入メンバーには「プロジェクトとは別の場所で別の事をやってもらう（事実上プロジェクトから外す）」という選択をするという話でした。
いやぁ、こういう場合もあるでしょうから、参考になりました^^;

Chapter 22章 スプリント緊急手順

突然、メンバーの1人（チームの中心人物）が部異動になり、チームから抜ける事になった話です。
しかも、「今すぐ」「スプリントのど真ん中」という状態。そんなとき、同判断するのがベストか？
選択肢としては、①障害を取り除く、②助けを得る、③スコープを減らす、④スプリントをキャンセルする。
ステークホルダーの状況も踏まえ、この中のどれか判断すべき、しかし、④の選択肢は最終手段とすべきという話でした。

Chapter 23 持続可能なペース

基本、開発チームは持続可能なペース（生産性）で結果を出し続けるのが理想であり、これを過度に上げようとすると、結果として疲れ始め判断ミスが増えはじめてしまう。という話でした。
生産性というのは意図して上げようと考えない方がいいのでしょう。別の要因を改善して、その結果として生産性が上がるというのが理想なのかなって思います。

Chapter 24 動作するソフトウェアを届ける

必要だと思われるもの全てを一度に完成させることは難しいことで、必要最小限の機能から順番を付けて届けていこうという話です。

Chapter 25 価値の測定と最適化

開発チームは実際に動くものをデリバリーする以外に他にも仕事をしているわけで、その内容と割合を明確化すべきであるという話でした。例えば、スパイク、税（スクラムのイベントやレビューなど）、環境準備（ビルドや結合環境へのリリースなど）、バグ対応、リファクタなどです。

Chapter 26 プロジェクトのコストを事前に考える

やるべき事をユーザーストリーとして書き出し、ポイント見積もりと優先順位決めを行う話でした。ポイント見積もりというのは、相対的な見積もりで、フィボナッチ数列の数値を使って見積もるというもの。優先順位も当然相対的なものになります。このポイント付を行った上で、チームの生産性（１スプリント辺りに消化できているポイント数）から計算し、先々予定を立て、そこからコストを見積もるというものでした。

Chapter 27 スクラムにおけるドキュメント

アジャイル開発ではドキュメントが全くなくていいと思われがちだが、そうではないよという話です。
中間ドキュメントのような無駄なドキュメントは書かないのでしょうが、ユーザー向けの手順書などについては、コード作成より後回しにはなりますが必ず書き上げます。その方が、無駄がないためです。

Chapter 28 アウトソースとオフショア

オフショアにアウトソーシングする際の注意点についてでした。基本はおすすめしないという事ですが、もしやるとしたら、こんな感じでやるべきという事をまとめてくれてました。
実際にそういう場面になったとき、この章を読み返してみたいですね。

Chapter 29 巨大なバックログの見積もりと優先順位付け

大量のバックログを短時間で見積もる話です。ストーリーをカード化したうえで、広い壁に貼り付け、縦軸が優先順位、横軸がポイントの大きさとして、ストーリーを比較的しながら貼り付けていくことで、短時間にスムーズに終わらせることができるという話でした。

Chapter 30 契約の記述

スクラム開発で行っていくのであれば、契約の仕方として、コスト、期間、スコープの３つが固定化されていてはならない。そんな契約の１案です。
まずは、発見フェーズで２周間の調査を行い、そこで、ユーザーペルソナの定義、ユーザーストーリー、プロダクトバックログ、リリース計画を作成し、そこから見積もりを実施する。
第２フェーズでも自分たちの会社を使わないといけないという制約はなしにする。
第２フェーズ中では、１スプリントの猶予付きで、いつでも解約可能とし、スプリントの成果が得られない場合には費用は頂かない。という契約にする。
という話でした。すごいですね。成功報酬ですよ。
こんなの現実的にできるのでそうかねぇ。。契約についてはもう少し勉強してみたいです。

といった感じで、この書籍、いろんな事例やそのアプローチが満載でとても参考になりました。
ものによっては必要に迫られた際に読み返したいものです。