More than 1 year has passed since last update.

HajimariAdvent Calendar 2023

@YUM_3in

株式会社Hajimari

スクラムマスターを1年間経験して変わったこと

Posted at 2023-12-03

はじめに

なぜ書こうと思ったのか

22年10月頃から一年間スクラムマスターとしてチームの役割を担ってきました。

実のところマインドセット（思考法）自体は半年くらいで大きく変わった実感はあったのですが、1年をかけてゆっくりと育った感覚もあります。

今回は、自分が「スクラムマスター」としての役割を通してどのように価値観・マインドセット（思考法）が変わったのかをこの記事を通して伝え、同じ悩みや疑念を持っている人の勇気に繋がればいいなと執筆しました。

スクラムマスターとは

スクラムマスターは、スクラムガイドで定義されたスクラムを確⽴させることの結果に責任を持つ。(2020-Scrum-Guide-Japanese.pdfより引用)

スクラムマスターはスクラムに責任を持つ役割です。スクラムに責任を持つということは、「スクラムのプロセスを機能させること」や「チームビルディング」、そして「スクラムの原則と価値」や「アジャイルの価値観をコーチングする」ことも含まれていると考えています。つまり、スクラムマスターはチームの中でもアジャイル価値観への理解度が高く、尚且つ実現している役割になることが重要だと感じています。

そして、その学びや価値観を伝える方法は座学を行ったり、説得することではないと感じています。チームと一緒に体験し、考え、共に歩んでいくことで自ずとチーム内へ共有されていきます。

スクラムマスターについての定義を詳しくここでは解説しませんが、いくつかの参考資料を掲載しますので、興味があれば適宜参考にしていただけると幸いです。

スクラムマスターは保育園の先生に似ている - kawaguti’s diary
スクラムマスターの仕事にはどんなものがあるか | Ryuzee.com
スクラムマスター | Agile Studio

変わったこと

主に「変わったな」と実感している点について、節ごとにまとめました。

「よいチーム」を作れるようになった

「よいチーム」とは

「よいチーム」を作れていますか？仲が良いだけのチームになっていませんか？

私はチームビルディング経験がなかった時に「仲がいいだけ」のチームを作ってしまった経験があります。これは明確な失敗経験だと感じています。

ここで言う「よいチーム」は「仲がいい」だけではなく、お互いの意見を忌憚なく伝え、健全な衝突をし、より自分たちが成長していく話し合いができたり、そのアクションができるチームになっていることを指します。

そして、以前私が作ってしまった「仲がいいだけ」のチームでは、成果はなく、必要のない仕事まで作ってしまった自負があります。そして、健全な衝突ができる状態ではない、いわゆる「心理的安全性の低い」チームになってしまっていたが故に、誰も方向が間違っていることが示せずにこのような結果になってしまったのだと感じています。

ですが、今回スクラムマスターという役割を通じてより「よいチーム」を作ることへの理解度が高まりました。

失敗から、「よいチーム」を作るために

失敗から、もし自分がチームビルディングを主導していく場合、以下の点に気をつけています。

チームの関係性（硬直しているか、相互理解が高い状態か）
チームのWhyは共通認識を取れていて、外部に向いているか
メンバーがふりかえりの時に遠慮していないか

少しだけ簡単にここを説明します。

チームの関係性（硬直しているか、相互理解が高い状態か）

チームメンバー同士の関係性を重視しています。ここの関係性が硬直した状態で色々なHowをおこなっても空回りしてしまう危険性があるからです。

なので、チームの状態については細心の注意を払います。ここを読み違えてしまうと少し時間を無駄にしてしまったり、自分がチームビルディングを行う意味がないとチームに受け取られてしまう可能性があるため、各々が感じているフラストレーションを1on1を通して聞き込みを行ったり、MTG中の動作や視線を注意深く観察しています。

現状この「関係性」を測る指標については言語化が出来ていないため、今後言語化する必要があるなと記事を書きながら内省しています。

チームのWhyは共通認識を取れていて、外部に向いているか

端的にいうとしたらインセプションデッキ | Agile Studioの「我々はなぜここにいるのか」をチーム自身で出来ていて、共通認識を持てている状態なのかどうかを検査します。

そして、その共通認識は外部（顧客）を向いているかどうかも注意深く見ています。

まず、チームでの共通認識を持てていない状態だとチームビルディングをしていても「これって何のためにやっているんだっけ？」となりがちです。それは当然で、チームに共通した目的がないので、意義を簡単に見失ってしまいます。意義を見失ってしまったチームはコミュニケーションやチームビルディングの必要性を感じず、関係性が硬直化して行ってしまいます。

また、外部（顧客）を向いているかという点も重視しています。ここで外部に向かず、内部だけの共通認識になってしまうとチーム自身が部分最適化してしまう可能性があるからです。

ここで言う「内部に向いているチームの共通認識」は「最強のチームになる」とか「社内で一番のチームになる」といったものです。ここに顧客は入ってません。

わたし達は何のためにプロダクトを開発しているのか？何のために事業をしているのか？それは顧客のためです。

顧客の価値を高めるためのWhyになっていない限り、チームは誤った方向に最適化されがちです。自己管理できているチームになったとしても、それは行き過ぎた自己組織化か、閉じてしまっている自己組織化です。

どんな形であれ、外部（顧客）を含む共通認識を持ってもらうように「気づき」を提供しています。

詳しく知りたい場合はこちらの書籍がおすすめです。
アジャイルエンタープライズ（川口恭伸角征典 Mario E. Moreira）｜翔泳社の本

メンバーがふりかえりの時に遠慮していないか

かなり直接的な部分です。チームメンバーが遠慮していないかどうかの様子を見ます。

たとえば、口ごもっていたり、何か言うのを堪えていたり、少しつまらなそうにしていたり、画面外を見ていたりなどの小さな挙動を徹底的に観察します。人間は意外と身体にサインを出します。そのサインを見逃さずに「怪しい」と感じたら少ししつこいくらいの温度感で問います。そうすることで、意外と話してくれることがあります。

全員がいる場で話してくれないメンバーがいる時もあります。そういう時は1on1などClosedな場で聞くように心がけています。また、自分からもぶっちゃけた事を言うようにしています。自己開示により「私は安全だよ」「私は仲間だよ」というスタンスを伝えることにより、相手がどう感じているのか・どう考えているのかを引き出し、それを基にもっとチームの関係が向上するようにふりかえりの設計などを行っています。

スクラムはこのチームビルディングの場が「ふりかえり/レトロスペクティブ」という名前で存在し、組み込まれています。私はここから学ぶことが出来たのだと思っています。

多様性を大切にするように

最近同僚から多様性の科学を猛推しされています。Amazon Kindleで少しずつ読んでいます。

ここでいう多様性は社会的な文脈ではなく、「人と人の違い」という意味で使用しています。

やはり働いていると色々な人と働くことになります。その時、自分と考え方が合わない人や自分が気に食わない人と出会うこともあります。でも、色々な人と一緒に働くことも「良いプロダクトを作る」上では重要だということを学びました。

スクラムはとにかく「全員でやる」MTGが多くあります。
効率を考えてしまうと全員の時間を同期的に拘束することになるため、フラストレーションを溜めてしまう人もいるかと思います。ただ、この各種MTGは「全員でやる」からこそ効果があるのだと実感しました。

「全員でやる」ということは、１つの物事を考える時に「多数の背景を持つ人達」で「多角的」に物事を見ることができます。
誰か１人のエキスパートの声がそのまま反映されてプロダクトを作っていく訳ではなく「多角的な観点」からプロダクトを作っていくことになります。そして、そのようなプロダクトは不思議なことにより洗練されたものになります。（この部分は多様性の科学などを読んでみると理解が深まるかもしれません）

つまり、スクラムマスターとしてチームの「多様性」を殺さないように気を配り、よりチームが創造的で革新的な状態になるために、自分自身もチームと同じく同質化の罠にハマらないように内省し、メタ認知をすることでチームを健全な状態に引き戻す役割を担うことで支援するのです。

アジャイルリーダーシップ - 共立出版によると「私たち」の領域を創るためには「コラボレーション」「信頼」「オープンさ」「多様性」のメタスキルが必要だと述べられています。

オープンさと多様性は環境にさまざまな視点やエネルギー、そして深みを加え、創造的で革新的なチームに仕立てます。多様性があることで様々な視点を探すことに集中することとなり、より深い洞察を得ることに役立ちます。

効率より効果を

効率主義とスクラム

私はこの言葉が大好きです。アジャイルの価値観をより示しているなぁと感じるからです。

この言葉に出会った書籍はゾンビスクラムサバイバルガイドです。

組織やプロダクト開発を管理するこれまでの方法は、アジリティとは正反対のことを達成するために設計されている。このメンタルモデルは、効率主義と呼ばれている。（中略）
しかし、本質的に予測不可能で不確実である複雑で適応的な問題を扱う場合には上手くいかない。
それにもかからわず、このメンタルモデルはあまりにも深く染み付いており、意識できない。それが組織やコミュニケーションを設計する方法や、文化を創る方法を完全に決めてしまうのだ。（中略）
広い意味で、スクラムフレームワークは効率的であることよりも効果的であることに重きを置いている。 効率は、たくさんの作業（アウトプット）に関することである一方、効果は作業と価値と有用性（アウトカム）に関することである。

この節から自分が効率主義の世界に囚われていたことに気づくことができました。そして「より」なだけであり、全く重視しないという意味ではなく、優先順位的に「1.効果 2.効率」なんだよ、ということを理解しました。

そして今「効率より効果」を心に持っている私は「効率化が目的になっていること」に対しては警鐘を鳴らし、元々求めていた価値について問うようになりました。

出力だけを見ることはとても簡単で、出力を測ることはもっと簡単です。ただ、出力を重視するあまりに失ってしまった副次的なことも多くあることを忘れないでください。この副次的なものが積重なった時に歯車は噛み合わなくなり、取り戻すことができない状況にまで進んでしまう可能性があります。

そして、効率を重視する社会では能力をより重視します。能力を重視するあまり、人間を機械として見てしまい、人に対しての扱いが雑になってしまったり、息苦しい世の中になっていき、創造性が失われていきます。（ここで割愛しますが、より詳しく知りたい人はこちらを冒険の書　AI時代のアンラーニング | 日経BOOKプラス）

リソース効率とフロー効率

アジャイルになる上で重要な考え方があります。それがリソース効率とフロー効率です。

リソース効率は、「資源をどのように使うか」を重視します。例えば2人稼働する人がいる時、その2人の稼働を余らせないためにAというタスクとBというタスクを同時並列させて進める考え方です。

フロー効率は、「リードタイムをどれだけ早くするか」を重視します。例えば2人稼働する人がいる時、その2人でまずAというタスクを行い、その後にBというタスクを行います。この時Aというタスクをいち早く顧客に届ける（リードタイムを短くする）ことによって、学びを得て、さらにプロダクトに価値を付与していこうという考え方です。

詳しくはこちらアジャイルプラクティスガイドブックチームで成果を出すための開発技術の実践知電子書籍｜翔泳社の本。

これらは、アウトプットに注目するとリソース効率の方が優れているように感じ、アウトカムに注目するとフロー効率の方が優れているように感じる良い例になります。

どちらがチームに対して最適かは文脈によるため一概には言えませんが、リソース効率を重視すればするほどチームの関係性は良好なものとは言えず、少しずつ「グループ」へと近づいていきます。そして少しずつ今やっていることの「意義」が分からなくなり、最終的な効率は大きく落ちます。退職などによってリソースがなくなるからです。

逆にフロー効率を重視しすぎると本当に必要な期間までに本当に必要なものが出揃わない可能性があります。それにチームでの協働経験がない場合は「かなり難しい」ものに最初は感じるため効率はより大きく下がります。

ただそれでもフロー効率がよりプロダクトの価値や私たちを人間として良いものにしてくれることは変わらないと思っています。

具体的にフロー効率を高める取り組みについてはこちらを参照してみてください。

顧客をファーストに考えるように

「効率より効果」という節と似ている部分がありますが、何をするにあたっても「顧客」をファーストに考えるようになりました。

例えば、社内で行う施策１つに取っても「これを実際に行う人はどういう気持ちになるだろうか」「これをやって本当に与えたい価値が生まれるのか」「価値とコストが見合っているのか」を考えるようになり、その先の「ペルソナ」まで頭の中に思い浮かべながら取り組むことが増えました。単純に「効率化すればいい」という考え方ではなくなったのです。

自分が今まで書いた記事を例にしてみると

がんばらないObsidianノート術 #新人プログラマ応援 - Qiita

この記事を書いた時「Obsidianを使いたいと考えているが、ツールへのキャッチアップが苦手でいまいち導入できていない人」を想像して、その人に届くように書きました。（裏話として「自分がツールへのキャッチアップが苦手ではない」ことから本当に苦手な人には耐え難いハードルを提示してしまったため、あまり刺さりませんでした）

アウトプット記事を書くために結局何をすればいいのか？ #アジャイル - Qiita

この記事を書いた時は「読みての価値を考えて書くことで、伝えたいメッセージが明確になるよ」という価値を考え、「記事の書き方が分からない/記事を書く意味が分からない」人に対して書きました。

このように「相手が求めていること」が含んでいる「本質的な課題」に対してアプローチすることで、より効果を生み出すことを理解したため、「顧客ファースト」で考えるようになりました。

ここで勘違いしないで欲しいのが「顧客ファースト」と「お客様第一」は違うということです。
日本の伝統的な部分として「お客様第一」という考え方があるように感じられます。

ただこれは「お客の求めていることをすべて提供する/お客に言われたことは何でもやる」という精神が含まれていて、顧客価値については深く言及されていないように感じます。（もしかしたら元々は顧客価値の言葉だったのかもしれませんが、時間や複数情報源を経由するうちに変わってしまったのかもしれません）

顧客をファーストに考えるということは、顧客の得る価値や体験について考えることです。この価値を最大化させるためにわたし達は尽力するだけであり、「顧客が言っていること」をすべて満たすために存在するわけではありません。この違いを念頭に置きつつ、プロダクト開発やクリエイティブ活動を行うようになりました。

完璧主義から脱却した

元々超がつくほどの完璧主義でした。自分が少しでも気になった部分は修正しないと気がすまないタイプでした。

ただ、このマインドセット（思考法）は窮屈であり、能力を過信しすぎていて、尚且つ他人を機械としてみなしてしまう可能性があるため危険です。

「自分には厳しく、他人には優しく」で動いているつもりでしたが、いつしか自分は他人にも無意識のうちに「完璧であること」を求めるようになりました。

この考え方をスプリントレビューやふりかえり会を通して「どんなに予想や考え尽くしても、漏れは出るし、予想と外れることはある。そして前提が間違っている可能性もある」ことを理解しました。

また、そもそも計画自体が誤っている可能性があることもスプリントレトロスペクティブを通して問えるようになりました。「そもそも予算や計画、KPIが間違っている」と考え、チームで話し合うことによってより目的を達成するために軌道修正を行いながら進めることが出来たからだと思います。

完璧主義が無意識になればなるほど、他人に対して完璧であることを求めます。それが「社会人としてあたりまえ」や「できてあたりまえ」という考え方に繋がり、創造性を潰してしまったり、一人ひとりの個性を潰すことになります。そのように捉えてからは、自分は誰かを見て「◯◯が足りていない」などは考えることがなくなりました。「◯◯が足りていない」というのは自分の中にある基準に対しての意見であり、その人自身が本当に足りていないかどうかではないからです。

この考え方を突き詰めていくとアジャイルリーダーシップ - 共立出版における「エキスパート」になってしまうと今では分かります。エキスパートだけが生み出す世界に私達はうんざりしてきたのではないでしょうか。

本質的な課題を考えるように

顧客ファーストの部分とかぶる点もありますが、「Howでおりてきた依頼」をそのまま鵜呑みしないようになりました。

「〜してください」と頼まれることはありますが、その「〜してください」という結論に至ったまでの背景やプロセスを聞き、そこから本質的な課題を見極め、より効果的なHowを探すようになりました。結果的に最初に降りてきた「〜してください」という結論になることもありますが、そうならないケースも多々あります。

これはユーザーストーリーの考え方に強く影響されました。O'Reilly Japan - ユーザーストーリーマッピングという書籍に以下のような節があります。

要件という言葉が、実際いは黙れという意味だと学んだのは、そのときのことである。多くの人々にとって、要件とはまさにそういうものだ。要件は、それを使う人と解決すべき問題についての会話を停止させてしまう。しかし、必要なものの一部を作るだけでも、人々に大きな満足を贈ることができるのだ。覚えておこう。結局のところ、あなたがやらなければならないことは要件を満たすことではない。世界を変えることだ。

「〜してください」というのは、つまり要件です。これをベースに要件を鵜呑みにして満たしたとして、本当に顧客は価値を得られているのでしょうか？一時は満足したとして、数ヵ月後に手痛い状態にはなっていないでしょうか？
要件で降りてきたものは「一時的に解決する」可能性があるHowかもしれません。その要件が生まれるまでのストーリーを知ることでより私達は共感し、本質的な課題へ向き合うことができるのだと学びました。

自分の人生の目的が明確に

アジャイル/スクラムを通して、自分が社会に対して考えてきた/感じていたことが言語化された感覚になりました。
日本の仕事社会は「最適化」されすぎているように感じます。最適化自体は悪いことではありませんが、行き過ぎた最適化は私達自身を窮屈なものにし、どんどん生きづらい世の中にしていきます。この生きづらい世の中に辟易しているというのに、この世の中を作っているのは自分達だという皮肉です。

これまでの仕事これからの仕事～たった1人から現実を変えていくアジャイルという方法という書籍はそんな日本の仕事社会について切り込んでいます。

この仕事に対する価値観をアップデートし、より一人ひとりが自己実現できている世界を実現することによって、不幸せに苦しむ人を減らせるようになると私は信じています。そして、そこが自分自身が取り組む課題であると。

アジャイルの価値観を経営に広げていく書籍は多くあります。

「人を変える」時代から「人は変えられない、自分を変える」時代になってきています。この考え方が広がれば、よりみんなイキイキと働けるようになると思っています。

終わりに

途中から書きたいことを書く形になってしまいましたが、この記事で本質的に伝えたいことは「今の仕事観をアンラーニングする必要がある」ことです。

私達は小学校から能力主義の世界で生きてきています。その連続性の中で社会に出て、「能力ではない部分」と向き合うことになります。この「能力ではない部分」に対してのアプローチ方法をより見つめ直すことによってもっと世界は良くなっていきます。

そして、その第一人者的な役割を担うのはアジャイルの考え方が生まれた「ソフトウェア開発」に携わる人が一番近いと考えています。私達はただプログラムをコーディングしているのではなく、世界をコーディングしているのです。

参考資料/リンク

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up