この記事はNTTコムウェア Advent Calendar 2021 17日目の記事です。

はじめに

おはようございます。こんにちは。こんばんは。
本記事の投稿者は、NTTコムウェアでアジャイル開発の支援等を行っている社員です。

この記事について

数年前にCSM®¹となった私は、あるサービスをプロダクトとして提供するべくSM²としてPO³や開発者⁴とScrumTeamを立ち上げることになりました。

はじめてのScrumで得られた気づき
現在大事にしていること

このScrumTeamで得られた気づきを自身の振り返りを兼ねてまとめています。

ターゲット

ScrumTeamの一員として実践している人たち全体になります。特に当てはまる人たちは以下です。

ScrumMasterとしてのキャリアを歩みだした人たち
CSM資格を保有し、ScrumMasterとして駆け出している人たち
ScrumMasterって何考えているの？と疑問を持っている人たち
~~ScrumMasterって暇なのでは？と懐疑的な人たち~~

※既にScrumMasterとして経験を有する方にとっては、おおよそ既知の事柄と想定
※Scrumに関連する用語は既知の前提（初学者は、「ScrumGuide」で検索！）

得られた気づき

ここでは、

「得られた気づき」→「どうすればよかった？／今後はどうする？」

を4つ挙げています。

気づきその1：焦ったり、慌てたりしても良いことは全く無い

実際にScrumMasterとしての経験全般を通じて得た気づきです。
（ちなみに、CSM研修でもトレーナーからいただいたコメントでした。おそらくは自身の癖なのだと思います）

ScrumTeamを運営する上で、ユーザへのお披露目やリリースラインの達成が困難と判断せざるを得ない局面に何度も遭遇しました。
当時の（ScrumMasterとしてようやく入り口に立った程度に未熟な）私は、焦りによっていつしか「SMとして対応すべき優先順位」を忘れて眼前の事象を追うことになります。
その結果、見事に**（実は）重要で早期に対応しなければならなかった問題をスルー**することに…
また、SMの焦りはScrumTeamに「何か問題があるのか？」という形で伝搬しました。結果、POや開発者にいらぬ不安も与えてScrumTeamに何一つ良いことがない状況を導いてしまいました。

どうすればよかったのか？

SMとして対応すべき事項を常に整理して優先順位が高いと判断したものに集中して取り組むべきでした。
- インペディメントリストを作成したが、作成したからこそ透明化を徹底して真正面から向き合うべきでした。
- 真正面から向き合うことに逃げて、焦りと共に問題に取り組んだ「つもり」になっていました。
ScrumTeamへの影響を考えた際、「動じない自分」になるだけの冷静さを持つことができていたならば結果は違ったと思います（当時の自分にその余裕は残されていませんでした）
自分が焦らない、と同時に、ScrumTeamとしても焦らないことが大事
- 少なくてもSprint単位でスコープの（再）調整はできる仕組みなのだから。

気づきその2：特効薬は存在しない

問題が出た時に「何とかならないかなぁ」と他責思考になってしまった時の気づきです。

みなさんは開発で問題が出たときに**「一気に解決できる手段」を探ろうとしたことがありませんか？（実際には見つからず、結局は「そのうちなんとか見つかるだろう」と、問題をなぜか先送りにしてしまう**アレです）
実際には問題を先送りにすることで、より大きな問題となって襲い掛かるだけなのに…

今回、上記の問題はプロダクトバックログで管理していました。
かつ、「早く解決したい問題なので」優先順位が高いアイテムとして管理されます。

優先順位が高いにもかかわらず、Sprint内で解決する手段が整理できないため、Sprintでの消化項目に落とし込めない
→ScrumTeamの全メンバがなんとなく目を背ける(注：SMとしてこの段階で対処すべきだった。が前段の焦りも相まって…でした)
→いつしか、振り返りでも「解決しないとね。なんとかしないとね」という謎の落としどころが認められてしまった（なんとかなるわけがないのに)
→そして、リリースが近づいて（以下省略）

どうすればよかったのか？

問題を何とかしてくれる薬など無い、という当たり前のことに気づけている今なら以下の対処ができたと考えます。

まず、問題はなんとなく解決できるわけがない、という事実を認める
ましてや、万能薬が現れるわけがない、という事実を認める
問題は見つかった事実はポジティブにとらえて、小さなうちに対処する
- 先につぶせば大きな問題にならない
問題が複雑そうであれば、分解する（最近、分解の手段は様々あることを確認できたのだから）。

気づきその3：日々の成長が必須である

実際にSMとして動き始めた瞬間の気づきです。

CSM研修では「手段は皆さん自身で学んでください」という主旨のコメントがありました。
様々なTopicがあった研修だったこともあり、わかったようで少しモヤモヤしたコメントでもあったのですが…
モヤモヤした理由は、「手段」のスコープを誤認識していたから、と動き始めた瞬間気づくことになります。

誤り：「Scrum」を行うイベントやアーチファクト作成等手段
現認識：「ScrumTeamである自分たち」が成功するためのあらゆる手段

具体的には、チームビルド、コミュニケーション、ネゴシエーション、…と、Scrumに限らず業務遂行上求められるあらゆるスキルです。
かつ、（当時は気づけなかったのですが）ScrumTeamのメンバ構成が変わると、求められるスキルも変わるという、「1回経験すれば次も通用する」が通用しない世界でもあります。（プロジェクトマネジメント同様に、特性把握が大事、ということ）

どうすればよかったのか？

当時は当時なりに必要な学習をしていたことから、あえて言うなら「もっと時間を割く」です。（ワークライフマネジメント上、実現性に関して様々事情があるという前提で）

だとすれば、これからどうするのか？

現認識に基づき学習のスコープを拡げることでSMとしての視野拡大を目指す。
（ただし、一気に行うと中途半端になることから、優先順位をつけて焦らずに取り組む）。

気づきその4：「劇的な改善」を目撃できる時がある（ただし、継続できるかは別である）

最後は、劇的な改善が目撃できたにもかかわらず、一過性に終わったことによりはじめて得られた気づきです。

あるSprintのPlanningで、「POと開発者が向かい合って会話している（≒対立構造）」から「PBLと向かい合っている」になっていた瞬間を目撃しました。
それまで、「ここまでできる」「いや、難しい」という応酬も散見されたのに、です。

正直、SMとしてはうれしい瞬間でした。ScrumTeamに改善の兆しが見られたので、それまでの取り組みが報われたと感じれたのです。

しかし、その時の対応で未熟さが露呈したこともあってこの改善は1回目は一過性に終わりました。
（再度改善の兆しが見られたのですが、数Sprintを要する結果に）

基本動作なのですが、「改善した事実」をなんとなく伝えてしまったのだと思います。
また、改善の兆候を予測できなかったとも言えます。優れたScrumMasterであれば、これらの変化を計測して「期待通りに」目撃できるのかもしれません。予測ができなかったという観点では、自身がScrumMasterとして未熟であることの証拠なのかも。とも思います。

どうすればよかったのか？

今思えば、より大々的にScrumTeamをほめるチャンスだったな、と思います。当時考えうる範囲でポジティブな共有はしたのですが…まだ余地はあったというのが振り返りになります。
ポジティブな現象に、一喜一憂して冷静さにかけていたのかもしれません。冷静さ、大事。

現在大事にしていること

上記の気づきを経て、現在（個人的に）大事にしていることは以下になります。
ScrumMasterで無いと気づけない、ではないのがポイントです。
（ScrumMasterの立場からだと気づきやすい、かもしれないながら）

何が重要かを考えて優先順位を定義し、「ひとつずつ」問題に向き合う

毎日、わずかでも良いから「成長するための取り組み」を続ける
（書籍1ページ読む、でもよいので継続する）

重要と思える事項が無い場合は見落としの可能性を疑う。

自身が焦る、慌てる
自身以外のScrumTeamメンバを焦らせてしまう。慌てさせてしまう。

そして、一番はこれ！

現状打破（改善）に向けて、「何とかしよう」という焦り等からと一気に変化させようとしてしまう

その上で、ワークライフマネジメントにおけるあらゆる場面で、焦らない、慌てない自分を目指すべく、毎日を過ごしています（できた！という報告がいつかできますよう）

参考：どんな12か月間だったの？

0か月目

CSM研修受講(講師：ebacky)　←ScrumAlliance認定研修は、トレーナーにより「特色」が異なります。
- CSM研修と引き合わせてくれた当時の上司に感謝。

1-3か月目

とある新規ビジネスの検討にてPoCの実施に向けて準備
- 自身が現在所属している組織からの支援も受けはじめる。
- 想定したMVPは、まったくMVPと言えない代物（欲張りすぎ）ということにも気づけた。

4-6か月目

Sprint1開始。PO、Developerも含めて全員がScrum未経験だった。
- 最初の2Sprintは「アウトカム：0」（Scrumの伝達で必死な時期）。
- Sprint4で（欲張り過ぎから減らした）MVPをかろうじて実装。ユーザへのお披露目（実証実験）へ。

7-9か月目

商品化に向けた開発着手が決定。引き続きSMとしてScrumTeamに参加
- 実証実験時に割り切りで未対応としていた価値を新たに実装（追加、変更、時にはコードを捨てる決断も）
- Undone対応（プロダクトまわりは開発者にまかせつつ、リリースプロセスまわりはSMにて対応する決断をしました）

10-12か月目

一定の軌道にのって初回リリースへ
- 同時に、コロナの兆しが…（Scrum運営の大幅な見直しを考える時期へ）

追伸

「今回取り上げたScrumTeam」に所属していたみなさまに改めて感謝！
また、周囲でご支援いただいたみなさまには感謝してもしきれない、という点も改めてお伝えします。

Certified ScrumMaster®。認定スクラムマスター。ScrumAlliance®。スクラムマスターの資格は他の運営母体によるものを存在する。ScrumMasterに関連する資格はこのページが参考になります。 ↩
ScrumMaster。Scrumで定義されるロールのひとつ。 ↩
ProductOwner。Scrumで定義されるロールのひとつ。 ↩
ここでは、Scrumで定義されるロール（Developer）を指す。 ↩