スクラムマスターをして半年がたった

近況

こんにちは．
表題通りでレコメンデーションチームのスクラムマスターを昨年の6月からやっている．
以前はチームから出向という形で新規チームのTLをやっていたのだが，チームでのMVPが完成してML的な複雑性をほぼ持たないシステムになったのでTLを委譲し，shopetan自身はレコメンデーションチームにカムバックしていた．
shopetan.hatenablog.com

レコメンデーションチームはというと，ここ半年でチームメンバーが精力的に外部登壇や記事を公開している．
昨年の下半期ではチーム史上最高のKPI向上を果たしていて，チームメンバー全員がBe a Proであるが故の成果だが，チームとしてもワークするようになっているのを肌感でも感じている．

codezine.jp
engineering.mercari.com
engineering.mercari.com
ai.mercari.com

近況の共有がてら，SMとしてやってきた事を3つ振り返っておこうと思う．

絶えず「課題に感じたこと」と「どのようなActionを実施するか」のログを残す

チームの状態はシステムとは比べられないほどに有機的なので，ある時点では課題と感じていても，また数日経過したある時点では課題ではなくなる可能性も高い．
これを踏まえて定常的にチームの観察とその時の思考をロギングし課題のリファインメントがいつでも出来るようにしている．
これはSMになった当初から行っている事で，今振り返ると運用やリスクを考慮するSWE的なマインドセットに基づくものなのかもしれない．
SWEとして振る舞っているとSystem Design Docなどを作成する過程で背景や目的，設計方法や代案などをdocumentベースで議論し意思決定をログとして残す事が当たり前になる．
Design Docのメリットは「Docsが必要な時に必要な議論が出来る最小単位」となっていて「Acition実施前に全体考察可能」で「Acitionの精度が高まり手戻りが減る」ことだと思う．
SMとしても「議論をし意思決定のログを残す」というところまでがセットであるべきで，アジャイルコーチやPO,TLなどが含まれる場で情報の共有と議論をするところまでは実施出来ると良いと思う．
これはチームの歴任のSMが共通のdocumentで継続的に議論しており，自分は良い習慣にタダ乗り出来た状態だった．

現在はアジャイルコーチが居なくなってしまったので客観的なFBを得れる機会がなくなってしまった．
議論をする事が減ったのでこれを踏まえてdocumentという体はやめた．
代わりにSMとしてのログは自前のカンバンに残し，気になったタイミングで課題追加 + 適宜優先度順位の見直しを実施してActionの優先順位付けなどを行っている．
documentと比較して検索性が下がって議論のフォーマットとしては不適切だが，今は各メンバーとの1on1内で議論をロギングし，課題は必要なタイミングでカンバンから共有するというスタイルで運用している．

課題を共通のものにする

SMとして課題を考えるとどうしてもSM目線では課題と感じていてもチームメンバーには腑に落ちないことも多々ある．
また，チームメンバー目線でもあるメンバーは課題認知していても別のメンバーは課題と認知しないケースがある．
「課題を課題と認知させぬ間に問題を解決し，気づいたらチームが生産的になっていた/働きやすくなっていた．」を実現できるのが守破離を体得しきったSMだと思うが残念ながら自分はまだそのようなフェーズに居ない．

まずはレトロスペクティブが機能的になるようにコミットメントしようとしていた．
当時のチームに対するSMとしての認知は，

• チームメンバーは起きた課題が対処できる
• 課題として共有され，共通化されれば対処のActuionが取れる
• 日々の問題を認知し修正する力はあるが，長い間，チームのプロセスや価値観などを議論してきていない
• プロセスの改善にフォーカスされない(課題の認知化が進んでいないor課題に気づけない)

1actionで解決出来る問題ではない事が明らかなので，昨年度は個別対処をメイン戦略として取った．
下記のものを実施した．
結論から言うと上記の状態から解決はしていない．経験を積んだだけの状態で，実力不足でプロセス改善の習慣化まで至っていない．
実施したフレーム自体は価値の高いものであるが何れもボトルネックがあり持続可能性に乏しいので，メリットとデメリットを理解して実施するべし．
現在はチームの現状に向き合った習慣変容と，Visionに基づく習慣変容の2軸で施策を実施している．これらもいずれ紹介したい．

1on1に基づきメンバーのpainをまとめたpain sheetの共有

needs, pain, solutionからなるシートで，1on1でチームメンバーの現状のpainを収集し，needsとして共通化，対処案などをまとめたもの．
特にSM就任初期に1on1で課題収集と言語化を進めて匿名化したものをメンバーに共有した．

Good

• チームメンバーが感じていた問題が一覧化出来る
• 他メンバーが課題に感じていなかったとしても共有が進む

Bad

• 1on1から共有まで莫大な時間がかかる
• 無数の課題が共有されるので関心が持たれない
• 優先度が分からない(個別に収集した故にフラットになってしまいActionを取りにくい)

Agile wheelのワークショップによるチームメンバー間の価値観の共有

Agile wheelについては下記の記事が詳しい．
一言で言うならチームメンバーがそれぞれ12項目について現状となりたい姿の評価を主観で行い，GAPなどを可視化する方法である．
dev.classmethod.jp

Good

• チームメンバーがそれぞれの項目に関する価値観を共有する機会になる
• チームで大まかな課題解決の優先順位付けが可能になる
• 複数のGAPを知ることが出来る

具体的には下記

• チームメンバー間のGAP
• 現状となりたい姿へのGAP
• (継続的に実施出来る場合)過去の評価と現状のGAP

Bad

• 準備に多少の時間がかかる
• 解釈が一意に決まらない，基準が主観によるものなので評価自体の正確性は少ない

happiness radarのワークショップによる開発プロセスに対する課題感の共有

表のフォーマットに対して一方の軸を感情(晴れ/曇り/雨)，もう一方の軸を開発プロセス(Planning/Implementation/Release/Operation)としてチームの現状を評価してもらう．
下記のリンクではVote式になっているが，実施時は具体的な出来事やプロセスを各セルごとに記入してもらうようにした．
www.funretrospectives.com

Good

• 振り返るコンテキストをプロセスに集中できる
• 感情が軸に含まれる

感情を共有するのは通常の振り返りだと難しく，事象と結びつけて共有するのも同様に難しく，ツールで共有しやすい体が作れるのがメリットだと思う．

Bad

• 項目が大きく話が分散する
• コンテキストが絞られているがゆえに実施が適切なタイミングでないと関心にムラが生まれる

ワークショップに対する振り返りの実施

Agile wheel時やその他のレクチャー時に実施した．振り返りはチームが通常行っているフォーマット(START/STOP/CONTINUE/FEEL)で行った．
ワークショップ自体の価値があったか，プロセスが改善できるか，何に注力したいかなどを最終的に共通化出来る．

Good

• チームとしてフォーカスしたいところが言語化される
• 慣れたフォーマットなので実施コストが低い
• SMとしてのFBとして利用できる

Bad

• 全体を通して実施時間が長くなりがち
• 振り返りの振り返りになるので疲労する

日々の習慣を愛する(経験の可視化)

1年の最後に上記のログに基づいた，チームが積んだ経験の可視化を行い共有した．
フォーマットとしては，下記のようなものを盛り込んだ．

• 四半期ごとに各Scrum eventとそのGood/Badをまとめて共有
• Scrum event外の当時の課題と現在の状況の共有
• チーム自体の変遷(e.g. メンバー異動や体制変更)
• Q単位のチームの成果を祝う

昨年読んだ本で好きなエッセイがあり「チームに成長してもらうためのリーダーシップ」という章の中で「成長の可視化を手助けする」というものがある．
www.oreilly.co.jp
SWEとして働いていると，日々の活動がイテレーティブ型の開発スタイルになり，目の前の解くべき課題と成果として還元するための方法にコミットし続けることになる．
このような状況下では短期的な視点に集中しがちで，日々のイベントの中で行う「検査」と「適応」がその後のチームの習慣にどのような影響を与えているか実感できない．
上記の問題点から習慣は雪だるま式に積み重なってチームに良い影響を与えているということと，その裏では開発チームのメンバーを含む色々な人がチームの成長に貢献しているということを可視化することで，チームとしての成長を実感出来るようにした．

これが実際に期待する効果を生んでるか測定するのは難しい．
個人的には，効果以前の話で，product開発の現場では当たり前のようにQや半期単位で目標設定とその振り返りが成されているはず．チームに対しても当たり前に還元されるべき情報だと思う．
自分たちがどこに向かっているのか，向き先は正しそうか，大きなゴールに向けてチームが検査と適応の経過を振り返るためにも今後も提供し続けたいと思う．

「お前は何も覚えていないのよ――阿良々木。自分が何でできているかを知らないの」

終物語より

まとめ

実施してきたトピックはスクラムの三本柱である「透明性」「検査」「適応」の何れかの思想に基づいている．
自分の振る舞いに落とし込むと以下のようになる．

• 透明性: 正しい情報をロギングしてSMとして次の行動が起こせる状態
• 検査: 現在の目的と，現状が明確化されていて，GAPを把握可能な状態
• 適応: GAPを把握した上で目標に近づくアクションを起こしている状態

そもそも自分はSMをやる気は全くなくて，どちらかといえば強烈に反発していた側の人間だった．*1
だが「人間の集合(チームや組織)をシステムやプロダクトとみなしてビジョンの実現確率を高めるロールである」と解釈できるようになってから随分マインドセットがましになった．
今の組織は兼業しか認めておらず，自分は50%の割合でSWEもやらざるを得ないのだが，兼業メリットは皆無であることも実感値としてよく理解した．*2
次は価値を認めてもらって，組織を変えなければならないフェーズなので今年も気を引き締めてやっていこうと思う．

*1:「チームが熟達したメンバーで構成されていて，マインドセットもまともならこんな事をする必要がないのでは」といった感じ．実際，強制的にスクラムが導入されたのでその事は根に持っている．

*2:そもそもSMとしてワークするにはかなりの時間を要するし，自分がSMとして振る舞っているのかSWEとして振る舞っているのかの区別もつかない状態からスタートする．ロールに対する解像度の低い状態からスタートする事を踏まえると兼業させるのは妥当のようにも感じる．