この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは。CX事業本部でデザインチームの小峰です。
前回の記事ではアジャイルとスクラムの違いについて簡単にまとめてみました。こういった動きはスクラムで言うところのスクラムマスターにあたります。
本来であればマネージャーがスクラムマスターを兼任するのはあまり好ましくありません。
参考URL：Q. スクラムマスターに向いているのはどんな人ですか？
いずれはチーム内の誰かにスクラムマスターをお願いしたい気持ちです。ですがこれも状況によりけりです。私としてはチームの皆さんとフラットかつ健全な協議・議論をしたいですが、何かしらの肩書や役職というラベルがついていると、どうしてもそれに引っ張られてしまうことはよくあります。意識的、無意識的に関わらず。
ですので、チームの皆さんとお話する際に「今はマネージャーとスクラムマスターのどちらの帽子を被って話しているのか？」を気をつけています。たまにプロダクトオーナーやステークホルダーにもなります（笑）
さて、今回は「マネージャー」「スクラムマスター」としてチームの皆さんに意識してほしいことを書いてみました。「チームの有効性に責任を持つ」という意味ではどちらにも責任があるロールですね。
この記事の内容は私たちのチームのインセプションデッキにも記載しています。
これからマネージャーやスクラムマスターをやることになった方、メンバーに伝えたいことの言語化を模索しているような方にとって、何らかの参考になると嬉しいです。
1.CLPの理解と実践に努めること
いきなりですが会社独自のものです（笑）
クラスメソッドのカルチャー Classmethod Leadership Principle
これが会社のカルチャーであり、日々の活動の中で最も重要と言っても過言ではありません。迷ったときの行動指針ですので、日常的に意識する必要があります。
後述するアジャイルソフトウェア開発宣言やスクラムガイドと被ったり、似ていたりする部分も多いのではないと思っています。
例えば、以下はほぼスクラムチームにとって必要な考え方と言っても差し支えないでしょう。
リーダーシップ
– Leadership –
全ての社員がリーダーであるという考えのもとで、指示待ちや他責にならず自ら進んで前向きに行動し、周囲を巻き込み協力しあいながら、妥協せずに最高の結果が出るように尽力します。
2.アジャイルソフトウェア開発宣言とアジャイルソフトウェアの12の原則をよく読み理解と実践に努めること
私達のチームはスクラムを活用してアジャイルな状態のチームを目指そうとしています。本質的にはアジャイルの原理原則・思想・マインドセットとなるような考え方を知り、理解することが重要です。
最初はよくわからないものですが、実践を通して理解が深まっていきます。実践のためにスクラムなどの手法を使います。
「経営者意識を持て」「当事者意識を持て」といった話をよく聞きます。が、このような意識を起点に変えていくことは極めて難しいかなと思います。
行動が変化して初めて意識は変化するものです。
「スクラムなどの方法論を通してチーム全体がアジャイル意識を持つことができる」と私は捉えています。
3.スクラムガイドをよく読み理解と実践に努めること
当然ながらこれも重要です。
私がアジャイルに取り組み始めて間もない頃に感じたことですが、案外みんな読んでいません（笑）
「なんちゃってスクラム」という状態を耳にしますが、こういった状況に陥る背景には、
- 「確約」「集中」「公開」「尊敬」「勇気」
- 「透明性」「検査」「適応」
- 「経験主義」「リーン思考」
これら重要なポイントを抑えずに4つのスクラムイベントを回すだけ（リファインメントも含めれば5つ）、ということになってしまってることが多いからではないかと私は考えています。
適切にスクラムイベントを実行することは重要ですが、その背景となる考え方や理由はもっと重要です。そのため私はこれらが大事なポイントであることと、多くの行動を実行する中で、その行動に潜む重要なポイントは何か？ ということを伝えたり気付いてもらったりするようなサポートを意識して活動しています。チームが日々スクラムイベントをこなす中で、様々なプラクティスを試行錯誤し、個々人の頭に馴染んでいくことで、チーム全体の活動も滑らかになり、アジャイルな状態のチームに近づくことができます。。
また、2017年版から2020年版に変わって色々と変化しています。しかし相変わらずデイリースクラムでは3つの問いに縛られていたり、「自己組織化」というワードを使い続けている人が見受けられます。
参考URL：スクラムガイド2020のアップデートについて
浸透するまである程度の時間がかかるのは避けられませんが、「なぜ変化したのか？」の理解は重要です。
スクラムガイドの次のアップデートがいつになるかはわかりませんが、その際には、その時点でチームが置かれている状況を踏まえつつ、変化点の確認と解釈をチームで取り組みます。
4.「ただ話す」を実践すること
これはLarge-Scale Scrum(LeSS)で紹介されていた調整の方法のひとつです。
参考URL：調整と統合 - Large Scale Scrum (LeSS)
チーム間での調整について書かれていますが、私はこれはチーム間に限らず、その内外や個人間でも有効なものと考えています。
具体的な方法は、
- あなたは何か調整が必要なことに気づく
- 立ち上がって
- 調整が必要な人のところへ行き
- 「やぁ話そう！」と言う
です（笑）
LeSSについて解説されている書籍には「バカげた冗談のように聞こえるかもしれないが、本気で言っている」と記載があります。著者たちは「より正式な調整方法の環境が整っていると、調整が少なくなる」というパターンによく遭遇していたそうです。人は「正しい」環境で調整することが重要だと感じるからです。
これを読んでいる皆さんも下記のような似た体験があるのでないでしょうか。
- 何か調整が必要だと気づく
- 何日か後に定例があるからそこで話そうと考える
- しかし忙しい！
- 「あれ何相談しようとしていたんだっけ？」ないし「なんか他の話題で盛り上がってるから話さないでおこう」などあれやこれや
ほとんどの調整ごとは思い立ったらすぐ動けば解決できることが多いと思っています。問題は「どのような調整方法を使うべきか？」ではなく「調整して会話する必要があることについてチームがどう気づけるか？」です。
以前に「会議はバグである」という記事がちょっと話題になっていました。
「無駄な会議」を斬新な方法で一掃。経営陣「会議はバグです。本日このバグを修正しました」 | ハフポスト これからの経済
これはかなり過激かつドラスティックな手法で真似することは難しいでしょう。現実問題、事前にアジェンダや資料をきっちり用意し、かつ、関係者を集めた協議や議論が必要な場面をゼロにすることは難しいです。ですが「とりあえず会議設定しよう」から「とりあえず誰かと話そう」に切り替わるだけでも、物事はかなりスピードアップするはずです。
5.How（どうすればできるか？）」の前に「Why（なぜやるのか）」の理解に努めること
我々は特にお客様のご要望に応えるために活動しています。そこへ意識が向きすぎた結果、ご要望をそのまま受け取り、「How（どうすればできるか？）」の議論に集中しがちです。
しかしご要望の裏にはその本質となるような目的であったり、その要望に到達した背景があるはずです。そういったものの理解が無いまま作り始めた結果「なんか違う」となってしまうことは避けなければなりません。
そういったことを避けるためにもチームの中では「Why（なぜやるのか）？」という疑問を持つことの重要さを伝えています。
Whyが明確になると「What（何を作るのか？）」も明確化しやすくなりますし、不必要なものは避け、目的を達するために必要最低限のものをつくることができるようになります。これはリーン思考にも通づる考え方ですね。
6.よく整理すること
誰が意思決定者なのか？ 誰と議論や相談をする必要があるのか？ 事象の背景は何か？ 今の数字状況はどうなっているのか？ KGIやKPI等でどんな数字を伸ばさなければならないのか？ 何を決めなければならないのか？ カスタマージャーニーマップ、ユーザーストーリーマッピング、ABテスト、ユーザーインタビュー、ワイヤーフレーム、プロトタイピング、デザインシステム、ビジュルアルアイデンティティ等、用いる手段は何なのか？……等々様々な状況や疑問、パラメータを徹底的に整理する必要があります。
複雑な状況下でプロジェクトは目まぐるしく変化していきます。情報を素早く収集し整理することで、共通項が見えてきたり、課題が見えてきたりします。これにより目的の達成のための今やるべき最低限のことがわかります。
7.物事の進め方について「観察」「状況判断・方針決め」「意思決定」「行動」のプロセスを行い続けること
いわゆるOODAループと呼ばれる考え方です。似たもので有名な「PDCA」もありますね。一般的にはこちらの方がよく使われるかもしれません。
個人的にはPDCAよりもOODAが好みです。いきなり計画から入っても頓挫する可能性が高いと考えるからです。まずは観察から入り、よく整理することで見えてきたものから計画することで、成功確率が上がるだろう、というのが私の考えです。
8.グループではないチームであること
ただ人が集まっているだけでは、なかなかチームにはなれません。そこでグループとチームの比較表を用いて「チームを目指そう！」というメッセージを込めています。
比較することで違いがわかり、自分たちの現在の状況と理想像とのギャップが見えてきます。ギャップが見えれば、それを埋めるための活動を進めます。
9.心理的安全性と基準が高いチームであること
心理的安全性。だいぶ前にGoogleが提唱し、最近はかなり浸透しました。ただ、これも最近良く言われるようになった気がしますが、心理的安全性がただ高いだけでも良くないはずです。
心理的安全性のある環境だからこそ高い基準で活動することができると考え、目標も高く設定します。これがセットでなければ、画像のようにただ「ヌルい組織」になってしまいます。
クラスメソッドではOKRを用いて会社も組織も事業も個人もストレッチなゴール設定をしています。心理的安全性が高い環境で、メンバーが協力して学習し成長することでその達成に近づくことができるという考えです。
終わりに
以上、9個でした。我ながら10個じゃないあたり中途半端だなと思いますが（笑）、とはいえこういうものは数ではありませんからね。
そして内容も不定期に変わっていくものです。減ることはあんまりなさそうですが、増えることはありそうです。現時点で書き加えてもいいかも、と思うのは
- Unlearnやダブルループ学習
- 型やパターン
- 荒ぶる四天王（時間、予算、品質、スコープ）
- 守破離
他にも多くありますが、パッと思いつくのはこの辺りでしょうか。
いつになるかはわかりませんが、追加修正が行われた際にはご紹介できればと思います。
それではー。
参考文献・URL
- 「ワイズカンパニー: 知識創造から知識実践への新しいモデル」 野中 郁次郎 (著), 竹内 弘高 (著), 黒輪 篤嗣 (翻訳)
- 「大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法」 榎本 明仁 (監修, 翻訳), 木村 卓央 (翻訳), 高江洲 睦 (翻訳), 荒瀬 中人 (翻訳), 水野 正隆 (翻訳), 守田 憲司 (翻訳)
- 「心理的安全性のつくりかた」 石井 遼介 (著)
- アジャイルソフトウェア開発宣言
- スクラムガイド
- Google re:Work - ガイド: 「効果的なチームとは何か」を知る
75
