スクラムイベントに出席しない優秀で不可欠な（？）エンジニアをどう扱うか

みなさんこんにちは。@ryuzeeです。

スクラムマスター用のロールプレイのお題をTwitterに書いたら、多くの方から「自分ならこうする」という案を頂いたので共有します。

今回のお題は、以下のものです。

あなたならどうするシリーズw 『あるメンバーはデイリースクラムの時間に出社せず、ほかのイベントでも内職したり別のミーティングでどこかに行ってしまうことがしばしばです。一方で技術的には非常に優秀で、現在の速度で開発する上では不可欠な存在です。スクラムマスターとしてどうしますか？』
— Ryutaro YOSHIBA (@ryuzee) January 1, 2019

その他のお題はこちらにあるので、チームで自由に遊んでみてください。

あらかじめ言っておきますが、どの対応が正解というのはありません。

これは、あくまでロールプレイなので、色々なオプションを考えておいて、実際にそのような状況に遭遇したら、その状況に合わせて対応方法を選択すれば良いでしょう。ただ、1つだけ言えるのは、チームの意向なしにスクラムマスターが単独で色々なアクションを取るのは（チームのステージによりますが）やりすぎの可能性はあります。

事実を探る

現在のミッションを達成することを前提に、彼の理由を聞き、ミーティングとして改善する点を具体的に提案させる。
— fuguman777 (@fugumen) January 1, 2019

たぶんそのメンバーはスクラムイベントに意義を見出だしてないので、1on1でスクラムイベントの意義について会話します。
別チームの作業とか、評価についてとか、障害になる事項を一緒になって解決するようにします。 https://t.co/UjyVwE4FDb
— ヤギのメイ、くまのプー (@bluechip05102) January 2, 2019

あるメンバーが本当にデイリースクラムや各種イベントに来ないのか、それはどれくらいの頻度なのか、どんな理由があるのかというような事実はアクションする前に知っておくと、打ち手の選択肢が広がりそうです。また内職している理由も、例えば他のチームと兼任してて仕事が溢れかえっているといった理由も考えられるので明らかにすると良いかもしれません。一方で、いきなり本人に直接聞くと、先入観を持つ可能性もあるので、純粋なファクトデータとして、チームメンバーから「実際に発生した事実」を具体的に収集する手もあります。

現実を受け止める

それでもチームが楽しいと思える場にする。全員同席はこのチームにおいては幻想だということに正面から向き合う。
— きょん＠アジャイルコーチ、システムアーキテクト (@kyon_mm) January 1, 2019

この状態でも成果が出ていて、本人も周りもそもそもこの事象を課題だとも思っていないのであれば、敢えて今そこに触れる必要すらないかもしれません。パンドラの箱をあけるにはそれなりの覚悟も必要になります。今解決すべきいちばん大事な問題なのか、そうじゃないのかによって、行動の優先順位は当然変わります。

チームで話し合う

振り返りで話題に上げて話し合えばいいかなーとおもいました。
そこで本人もチームも(ポジティブな意味で)納得できればそれでいいように思います( ´∀｀)
— ふっしー (@fushimi_kohei) January 2, 2019

非建設的な振り返りにならないように事前に根回し的なことも必要かとおもいます。
— ふっしー (@fushimi_kohei) January 2, 2019

チーム自体で、この人のことを問題だと思っているのであれば、レトロスペクティブでテーマにする手もあります。ただし、チームとして問題だと思っていないのに、スクラムマスターがテーマとして取り上げてしまうと、吊し上げのようになる可能性もあり、ますます本人が辛くなる（もしくはこじらせる）可能性もあるので、事前に仕込みをしておくのは賛成です。また、チームのメンバーが事実や理由を理解せず、印象だけで色々なことを言う可能性もあるので、先にファクトデータなどを収集しておくと良いかもしれません。

そもそもその人は本当に不可欠？

不可欠な人でそういう人に出会ったことないけど、参加しないとだいたいあてにされなくなるからなー。「これないなら時間変えようか？」って話したことはあったなー。製品の役に立ててない（自他共に認識されている）から朝会に参加した方がいい、って話はしたことあるな。こないけど。
— seki at druby.org (@m_seki) January 2, 2019

これは鋭い視点で、チームの中で必要不可欠で、周りから優秀だと思われている人は、規律に関してもしっかりとふるまうことが多いです。 Effective DevOpsの8章（8.2.6）で、このような例についての解説があります。

『多くの場合、このような人物が組織のためにすることは、技術的にも文化的にも、とうてい「価値がある」レベルとは言えない。特に、業界内でその企業がこういった問題行動に耐性がある（あるいは奨励している）という評判が立ってしまったら損害は大きい。』

したがって本当にこの人が必要不可欠なのか、この人がどれくらい貢献しているのか、一方でこの人のせいでどんな問題が起こったのかを明らかにすると良いでしょう。その上で、チーム自身が、その人を必要ないと判断できるのであれば、プロダクトオーナーや組織のマネージャーにそれを伝えても良いでしょう（一般的にスクラムマスターはチームメンバーを外す権限はないと言われています）。

もちろん、本人のふるまいが、他の理由（複数案件を掛け持ちしている、仕事があふれている、プライベートで問題を抱えている）の可能性はもちろんあるので、そこは把握が必要です。

期待値を明確にする

チームメンバーの納得感を高めるように努めます。

POからPOのしていることの背景や意図を説明してもらったり、それによる影響を開発メンバーから説明してもらうとか。

双方ともに納得したうえで仕事に取り組めるようにしたいです( ´∀｀)
— ふっしー (@fushimi_kohei) January 2, 2019

こういうスーパーエンジニアはスクラムのフレームワークにも詳しかったりして、ふつうにチームワークを説いても響きませんよね。
案件がつまらない、エキサイトできず、エキスプロイトされてるのが１つの理由じゃないっしょうか…回答になってないなーー https://t.co/Tk26qLyQ3W
— Takao Hori (@hori_takao) January 2, 2019

本当に優秀な人は先を見通すスキルを持っていることが多いです。分かりやすく言えば、このプロダクトやプロジェクトはうまく行きそうか、行かなそうかを早い段階で察知します。そこで問題点や改善点を打ち上げて、良い方向に持っていこうとふるまいます。一方で、ステークホルダーやプロダクトオーナーがこれに対してずっと耳を貸さないような状況が続くと、モチベーションが低下していきます。もちろんプロなので、規律に従って全力は尽くさないといけないのですが、人間ですので。こういうときは、一度立ち止まって、プロダクトのビジョンやゴールを確認したり、各メンバーに対する期待値を明らかにしたり、といった足元の活動をやり直してみるといいかもしれません。

プロセスやイベントの有効性を常に気にかける習慣をつける

いろんなイベントがあるとして、それぞれ続けるべきかどうか、意味があるかどうか、いつも話し合ってた方がいいかも。「当初はこういう理由で始めたけど、今はこうだ、まだ続けるべきか？」とか。
— seki at druby.org (@m_seki) January 2, 2019

イベントが形骸化していて、役目を果たしていないが故の可能性もあります。さんざん指摘してもデイリースクラムが単なる報告会になっていた、スプリントレビューにステークホルダーが来ない、みたいな状況であれば、時間のムダなので作業を進めたい、と思うのも不自然ではありません。このケースでも、こうなる前に本人がプロセスに対してフィードバックや懸念を表明していたかもしれません。継続的に、それぞれのイベントやプロセスがどんな意味や効果を持つのか、チーム内やステークホルダーを交えて確認し続けておくと良いでしょう。

内職をさせない仕掛け作り

内職に関しては、全員でだまってその人を見る、内職が終わるまで待つ、がいいと思う。うちは会議にPCやスマホ持ち込めないようにしました。
— seki at druby.org (@m_seki) January 2, 2019

これは普段のミーティングやイベントをどのように進めているのかによりますが、全員がPCを開いているような会議だと内職しやすくなります。チームのワーキングアグリーメントを決めて、会議の進め方を決めておくのが、よく使う方法です。僕が昔働いていた会社では、集中して参加が求められる会議だと、冒頭に「クローズドラップトップ」宣言がなされて、全員がPCを閉じてから開始することもありました。ルールを決めても守らない人がいる場合は、みんなでその人を眺めて待っているというのは分かりやすい対応だと思います。

それでは。