はじめに
こんにちは、KAGのnakazawawaです。エンジニアからスクラムマスター（SM）になって、1年が経ちました。
エンジニアとして働いていた頃は、技術選定や設計方針など自分で「やり方」を決めながら開発を進めていました。
チームの中で意見を出し、議論し、方向性を決める。それが当たり前でした。
でもSMになった途端、その当たり前が使えなくなりました。
何気なく言った一言がそのままチームの方針になってしまう。「あれ、みんな自分の意見を言わなくなった…？」と気づいたとき、自分の影響力がチームの自律性を奪っているのではないか、と不安になったのを覚えています。
この記事では、エンジニア出身SMとして1年間試行錯誤したことを振り返ります。
同じような悩みを持つ方の参考になれば嬉しいです。
やったこと① コードレビューを「見ない」と決めた
エンジニア出身SMとして悩んだのがコードレビューでした。
技術的なバックグラウンドがあるのでレビューしようと思えばできます。でも、自分がレビューに入ると気になることがあれば「ここ、こう書いた方がいいんじゃない？」と絶対口を出してしまう。
なのでコードレビューはほぼ見ないことに決めました。チームを信頼する、という意味も込めてです。
正直、最初は不安でした。「品質は大丈夫だろうか」「見落としがあったらどうしよう」と。でも、SMがいない方がメンバー同士でレビューし合う文化が育つかもしれない、と信じて意図的に距離を置くことにしました。これは自分が手を離す練習でもあったと思います。
やったこと②「〜しなくても大丈夫？」という問いかけ
もう一つ意識したのが、意見を「問いかけ」に変換することでした。
「ここまでやっておかないとマズイ」と思ったときに、直接言うのではなく問いかけに変えるようにしました。
- ❌「これは先にやっておいた方がいい」
- ⭕「〇〇は、しなくても大丈夫？」
直接指示するのではなく、チームに考えるきっかけを与える。もしチームが「大丈夫です」と判断したらそれを尊重する。「確かにやっておいた方がいいですね」となればチーム自身の判断として進められる。
小さな言い換えですが、これだけで「誰が決めたか」が変わります。地味ですが意識的にやっていました。
もう一つ意識していたのは、自分の考えとは違っても、チームが決めたことなら尊重するということ。
「自分ならこうするのに」と思っても、チームが議論して出した結論であればそれがチームの答え。
その結果うまくいかなかったとしても、それはチームの学びになる。そう割り切るようにしていました。
最初は正直もどかしかったです。自分が答えを言えば5分で決まることを、問いかけに変えるとけっこう時間がかかる。でも、チームが自分たちで考えて決める経験を積むことが大事だと信じて続けました。
失敗したこと：任せたつもりが「放置」だった
うまくいったことばかりではありません。任せたつもりが「放置」になってしまった失敗もあります。
私のチームはLeSS（Large-Scale Scrum）で複数チームと協働しています。あるスプリントで他チームとの打ち合わせが予定されていて、その前に決めておくべきことがありました。
私には「ここまでは決めておいた上で打ち合わせする」という認識があり、それが他チームのメンバーとは合っていたのですが、自分のチームメンバーとは認識がズレていました。
「そこまではチームで判断されるだろう」と思って、口を出さずにいたのです。
結果、打ち合わせ当日に認識のズレが発覚。他チームメンバーの困惑した顔を見て「自分が一言言っていれば防げたのでは」と反省しました。
「任せる」と「放置」は違う。必要な情報を渡さずに任せるのは、信頼ではなく責任の放棄だったな、と思います。情報を渡した上でチームの判断を尊重することが「信頼」なんだと、この経験から学びました。
1年経って気づいたこと
影響力は「消す」のではなく「向きを変える」
SMになった当初は自分の影響力を消そうとしていました。口を出さない、レビューを見ない、意見を言わない。
でも影響力は消せません。むしろ、黙っていることも一つの影響力です。「SMが何も言わない」ということ自体が、チームにメッセージを送っている。
大事なのは影響力を消すことではなく、影響力の「向き」を変えることでした。
- 「答えを与える」→「問いを投げる」
- 「方向を決める」→「情報を渡す」
- 「正解を示す」→「考える余白を作る」
同じ影響力でも、チームの自律性を奪う使い方と、自律性を育てる使い方がある。そこに気づけたのは大きかったです。
観察だけでなく「期待を伝える」ことも必要
最近感じているのは、観察しているだけでは足りないということです。
SMになった当初は「チームを観察して、必要なときにサポートする」というスタンスでいました。でも、それだけではチームは動きづらいこともある。
「こういう状態になってほしい」「ここまではできるようになってほしい」という期待を、ちゃんと言葉にして伝える必要があるのかもしれない。観察して見守るだけでなく、期待を共有した上で任せる。
正直、これはまだできていません。でも、これからやっていきたいことの一つです。
エンジニア出身SMの武器
技術が分かることは口を出したくなる「呪い」でもありますが、「武器」でもあると感じています。
POとエンジニアの会話を見ていると「あ、これ伝わってないな」と感じる場面が何度かありました。エンジニアは技術的な制約を説明しているけど、POには響いていない。POはビジネス的な優先度を伝えているけど、エンジニアはピンときていない。
そんなとき、別の言葉で言い換えてみました。「つまり、これをやると〇〇の機能に影響が出るかもしれない、ということですよね？」「POが気にしているのは、△△のリリースに間に合うかどうか、ということですか？」
技術も分かる。ビジネス側の話も、SMという立場上、エンジニアだった頃よりは理解できるようになった。両方の言葉が分かるからこそ橋渡しができる。これはエンジニア出身SMならではの強みかもしれません。
おわりに
「元エンジニア」は消えないし、消す必要もないと思っています。
技術が分かるからこそ「問い」に変換できる。そして「自分ならこうする」が見えてしまうからこそ、チームの判断を待つ難しさがある。
この葛藤こそがエンジニア出身SMの面白さなんだと、1年やってみて感じました。
同じように「エンジニアからSMになって戸惑っている」という方がいたら、この記事が少しでも一助になれば幸いです。