スクラムマスターとして、はじめましてのチームに入ったときの過ごし方

前回のブログの通り、GW明けの5/6から社会復帰しています。そこで、1週間ちょっと経ったわけですが、こんな感じで最初の1週間を過ごしていったよというのを軽くまとめ・紹介します。

なお、前提は以下の通り。

  • 週1,2でスクラムイベントだけとかではなく、スクラムマスターとしてチームにフルタイムで入る
  • アジャイルコーチの知り合いが一人いた程度で、他の人ははじめましてな状態

既存のMTGには、まずは色々参加

  • どういう内容を話してるかや進め方を感じ取る
  • その際にも、いきなり「これがいいよ」「ここはちょっと変えたほうがよさそう」とかは押し付けないように
    • そういうやり方をしている背景・経緯があるはずなので
    • やるにしても、「こういうやり方やってるチームもありましたよ」という情報提供な感じ

開発者がコミュニケーションしてる場にも積極的に参加する

  • 開発的な成果を出すというより、関係の質を作るところや実際の進め方を肌体感するのを重視
    • モブしてたので、乗り込む場があったのはありがたかった
  • 具体的な行動は
    • 分からなくても発言する(「分からないので、教えて下さい」メソッド)
    • ローカルに開発環境を1mmも整えてなくてもコード修正できる(そう、Visual Studio Live Shareならね)
    • 実装のことはついていけなくても、少し引いて貢献できることも多い(テスター的な視点で受け入れテストを整理するとか、不具合なら再現方法・期待する振る舞い・実際の結果を整理するとか)
    • コマンドの使い方などの基礎的なところは、自分の経験から話せることも多いよね

プロダクトオーナーやアジャイルコーチ、リーダー的な人たちとも会話していく

  • この場では、(開発者の場よりも)自分が感じたことや考えも出していく
  • とはいえ、背景分かってないこともあるので、「新鮮な目で見たときに、〇〇のように見えました」という `I message` なスタンスで

言葉だけでなく、目に見えるものを見せる

  • 最初だから観察が多めな時期ではあったけれども、さくっとやれそうなのは提案もしていった
    • お作法が分からないところもあったけど、基本は「許可を求めるな、謝罪せよ(超意訳)」の精神
    • 特に新しい取り組みの場合、言葉だけで説明してもピンとこないので、見える形にするのは大事
  • たとえば、こんな取り組み
    • 「朝会で話にあがってたタスクを、カンバンに優先順に登録してみたので、これ見ながら話しませんか?」
    • 「PBIのステータスを更新しやすいように、各ステータスの定義や更新タイミングを検討して明記してみたけど、これで現状と合ってます?」とかとか


こういうのを、入社2日目からやっていってました。メンバーと同じリズムでMTG参加含めて仕事してた&既存のメンバーと違って新しいインプットも多かったので、だいぶ疲れました。

ただ、時間効率という意味では、ちょっぱやだったんじゃないかなと思ってます。1週間ちょっとで進め方をある程度実体験できたし、一緒にモブしてるチームをはじめとした、みんなとの関係性もできてきたと思う。

まあ、スタートダッシュを切れたのはよかったのですが、疲れたのは疲れたし、ちょっと持続可能ではなさげ。ここからは、少しペースを緩めつつ、スクラムマスター的な視点やアプローチを考える時間を取っていこうかなと思ってます。

というのを、このポスト見てちょうど色々考えたので、今の自分の状況をふりかえってまとめてみました。

転職しました(11年ぶり2回目)

前職では

2021年4月まで、約10年以上もの間、ヌーラボにお世話になりました。

新卒で入ったSIerではSAPやってて、ヌーラボに入った当初はWeb業界のスキルなどがほぼほぼない状態でした。ほんとに「駄目だこいつ、早く何とかしないと…」レベルでしたが、受託開発やら自社サービスのBacklogの開発・運用をやっていく中で、エンジニアとして少しずつ成長していけました。

そんな中、幸運にも自分の興味志向と本業をうまくマッチさせることができました。当初から「一緒に働いているチームの役に立ちたい!」という思いのもと、Backlogをはじめとした開発をサポートするツール群に興味があったのですが、それの延長線上でJenkinsをはじめとしたCI/CD周り、さらにはツールだけにとどまらないチーム・プロセス周りの改善としてアジャイルスクラムなどにのめり込んでいきました。プライベート活動でも動くことができましたし、その成果を社内にも還元できたかなと思います。

(もちろん、うまくできたなと思うこともあった反面、力及ばずだったこともいっぱいあったなという思い出です)

次の会社では

5月から、クリエーションラインで働きます。クリエーションラインでは、エンジニアの知識・スキルを基盤としながらも、スクラムマスター・アジャイルコーチとして、アジャイルのレフトウィング:協調でゴールに向かう「チーム環境」の整備に携わっていければと思っています。

Joyを突き詰める旅へ

クリエーションラインを選んだ理由はいくつかありますが、理由の一つは企業理念にJoyが掲げられていること。以前の感想ブログの通り、Joy, Incがすごい好きなのですが、改めて見直してみて一番感銘を受けたところを抜粋。

メンローでの喜びの根幹にあるものは、僕たちが作ったソフトウェアを人が使ってくれ、うれしい体験だと感じてくれることだ。目標はいつも変わらない。マニュアルも講習会も使い方メモもいらない、使いやすいソフトウェアをデザインして作ることだ。まったく経験をしたことがないような難しい業務領域においても、僕たちはそれを成し遂げてきた。


人に奉仕しない会社は、この世に存在できない。会社とは、生み出すプロダクトやサービスを使ってくれる人たちの要求に応えるために存在するものだ。喜びについてこんなふうに考えれば、全員が価値ある目標に集中して取り組める。ソフトウェアを届けるのは、難しいことだ。コーディングは緻密な作業だし、正しいデザインに至るまでには忍耐と粘り強い努力が必要になる。それは本当に大変な作業で、いつもうまいこと完成できるとは限らない。僕たちもイライラするし、我慢強いわけでもないし、予想外の問題だって起こる。しかし、僕たちの喜びもまた、そうした大変な作業の成果として得られるものなんだ。だから、僕たちがデザインし作り上げるソフトウェアによって、人の生活に喜びを与えたい。

そうそう、そうなんだよねー。大変なことも多いけど、それがユーザーの生活をよくしたときに喜びを感じる。合わせて、自分たちだけ喜びに満ち溢れてるのではなく、使ってくれるユーザーとそのユーザーの生活に喜びを与えるのがいい。

前職とは違った形で、自分なりの、そして企業としてユーザーへのJoyを突き詰めていく旅に出ます。今後をご期待ください!

組織パターンを読みました

有給消化期間中で、この機会に鬼のように積ん読消化していきたい。その一環として、前から気になってたけど読めてなかった、組織パターンをざっと目を通しました。

ついでに、読書のやり方も色々試行錯誤してる途中。今回は、読むスピードを優先して、メモは自分だけで分かるレベルでさくっと取っていく方針で。その中でも、いくつか全体感想的なところだけを出しておいて、なにかの話のネタやこの後読む人の参考になれば程度。

www.amazon.co.jp



この本から得たいこと

パターンをさっと取り出して、自分の意見を補強するため。やっぱり、本とかでまとまったものを引用すると、説得力が違うので。

拠点をまたいだ組織系のパターンが、今はやっぱり大きな関心事の一つかな。その辺を補強できるものがあれば。

感想・得たもの

1回じゃさっと取り出して活用するまではならなさそうなので、2回目以降の読み直しにかけたい。

巻末のパトレットの方がわかりやすいし、まとまってるので、こっちを覚えるようにしよう。

ところどころ、スクラムでイメージできるものがあった。「ワークキュー(≒プロダクトバックログ)」だったり「非公式の労働計画(≒スプリントバックログ)」だったり。

わかりやすく、明日からでも使えそうなやつ。

  • 4.1.26 手を止めて始めた作業を中断するな
  • 4.2.5 ソロ・バイオリニスト
  • 拠点をまたいだ組織系のパターン
    • 5.1.8 組織は拠点配置に従う
    • 5.1.10 離れて作業する前の顔合わせ
    • 「拠点離れているときでも、なんとかなる条件」は、現実解として分かりやすい

1. すべての拠点を合計しても、プロジェクトの開発者の数が少ない
2. ほとんどのコミュニケーションが、Eメール(広く分散され、非同期のコミュニケーション)のようなもので行われている。その場合、コミュニケーションの主な手段が立ち話である場合に比べて、より多くの人が会話の輪に加われる
3. 関わる人が一定期間一緒にいて、お互いを知っていると感じている(キックオフミーティングのように短い期間でもよい。[ 離れて作業する前の顔合わせ( 5.1.10)]も参照)
4. 「不必要」な移動のせいでメンバーが疲れてしまうことのない程度に、必要に応じて喜んで移動する人たちである。状況によっては[拠点間に分かれた作業を完了させることが]プロジェクトの性質上、不可能である。そのため、拠点が離れているという問題に対処する方法が必要だ

RACIチャートで役割 / 責任をまとめるのを推し進めていたことがあったんだけど、そのときに「5.1 組織のスタイルのためのパターン言語」を知っておくと、もう少し自信を持って進められたかもしんない。

「5.1.7 コンウェイの法則」を、この機会にちゃんと学べた。

上の方に位置されてるパターンが、より最初に考えるところかな。特に、どのパターン言語でも「信頼で結ばれた共同体」から始まってるのが、興味深い。

Agile Tour Osaka × miniPLoP 2020で、SCRUMMASTER THE BOOKの紹介とディスカッションしてきたよ

www.kokuchpro.com

主催者の方からお誘いがあって、SCRUMMASTER THE BOOKの紹介と、それにまつわるディスカッションをしてきました。ディスカッションがよかったので、ふりかえりを兼ねてメモ。

発表資料はこちらです。

www2.slideshare.net



タックマンモデルで、スクラムマスターが取るべきアプローチ

タックマンモデルでは、最初の2つのフェーズである形成期・混乱期の過ごし方が大事だと言われています。

統一期・機能期にうまく入りさえすれば、チームの生産性は最大限に発揮されます。一方で、形成期・混乱期をうまく超えられないと、チームとしての成果が出せない状況に陥ってしまう可能性もあります。


チームの期待値を合わせる!ドラッカー風エクササイズとタックマンモデルを組み合わせた結果 | Backlogブログ

上記のブログで書いた通り、スタートダッシュを切るために形成期・混乱期が大事だとは今でも思ってます。だけど、統一期も大事だよねというのを、ディスカッションしてて感じました。

形成期や混乱期(特に混乱期)は、意見の対立が起きたりで、うまくいってないことが分かりやすいんですよね。ここでは、マイナスをゼロに持っていくイメージ。ゼロに持っていく際の打ち手、対立の建設的な解消がうまくいくかは、スクラムマスターの腕次第ではあるけど。

一方、統一期はゼロかちょっとプラスを、より大きなプラスに持っていくイメージ。このフェーズでは、混乱期ほど対応しなきゃいけない課題が分かりやすいものではないので、ここから抜け出すのはチームだけでは気づきにくいのかもしれない。なので、見えないものを見ようとするスクラムマスターが、一歩引いた目で支えるのが必要なんだろうなと感じました。

スクラムマスターは、個人に着目すべきか・チーム全体に対してアプローチすべきか

参加者からの質問。自分の発表部分、スクラムマスターの心理状態モデルと関連してたので、自分も回答しました。

その場での自分の回答内容は、こんな感じ。

  • スクラムは、(個人ではなく)チームの成果を重視するので
  • チームの成果に近づくならば、個人に対するかチーム全体に対するかは、ケースバイケースでより適切な方を

改めて、自分がどっちのアプローチを選ぶかをもうちょっと考えたら、こんな風に動いているかな。

  • ティーチング的な内容で、全体の底上げをしたい場合は、チーム全体にアプローチ
  • コーチング含めて、より深く話しつつ相手に気づいてもらって自分から行動を促す場合は、個人にアプローチ

#スクラムマスター道において、レベル2からレベル3へ

レベル1(開発チーム)からレベル2(関係性・スクラムチーム内外)と比べて、レベル2からレベル3(システム全体・組織全体)って、ちょっと飛躍してる気はしていたんですよね。ただ、ディスカッションの中で、その辺も少し話題が出たので、ちょっとイメージがつくようになりました。

  • ボトムアップ的なアプローチ
    • レベル2視点でいいスクラムチームは、周りへいい影響を与えられる
    • ボトムアップ的にいいチームが増えていけば、そのチームを支援していたスクラムマスターも影響力・発言力を持っていけそう
    • それが、レベル3の組織全体につながる
  • トップダウン的なアプローチ
    • ボトムアップと合わせて、トップの方針を現場・ボトムとすり合わせる(支援をする)のも、組織のスクラムマスターの仕事


他の参加者(akipiiさん)の参加メモもありますので、興味がある方は合わせて参照ください。
forza.cocolog-nifty.com