「目標を共有するチーム」より強いのは「悩みを共有するチーム」　スクラムマスターが実践して気づいた、1on1“7つのコツ”

セブン銀行・スクラムマスターの小林公洋氏

小林公洋氏：それでは「LeSSではじめる1on1」を始めたいと思います。

まず簡単に、自己紹介をさせてもらえればと思います。セブン銀行の小林と申します。主な経歴としてはシステム開発をずっとやってきています。約3年ほど前にセブン銀行に転職をしています。セブン銀行は4、5年ぐらい前から内製開発に取り組んでいるのですが、内製開発を行っているグループが「プロダクト開発グループ」というところになっており、そちらに所属しています。

主な業務内容として「Myセブン銀行アプリ」の開発を行っており、始めはエンジニアで入り、現在はスクラムマスターという立ち位置でやらせてもらっています。趣味はけっこうアウトドアが好きなんですが、今は子どもが小さいのでだいたい週末は子どもと遊んでいます。

「Myセブン銀行アプリ」では大規模スクラムの手法を取り入れている

この「Myセブン銀行アプリ」って何？　というのがほとんどだと思うので、簡単にこちらの紹介をさせてもらえればと思います。こちらはセブン銀行初の内製開発プロダクトです。2020年4月にリリースをしました。このアプリの特徴は主に2つあり、1つが「最短10分で口座開設ができる」というところ。もう1つが「カードなしでスマホだけでATMから入出金ができる」というところです。

2022年11月8日、お買い物投資の「コレカブ」をリリースしました。こちらは商品のバーコードを読み取ると、そのバーコードを提供している企業を検索でき、その企業に1株から投資ができるといったサービスです。

お客さまの声を素早く取り入れるために、Myセブン銀行アプリの開発においてもアジャイル開発を取り入れていて、リリース回数もアプリとサーバーとで毎月2回前後というところで継続しています。

そろそろ200万ダウンロードに届きそうになっていたり、賞をいただいたり、銀行アプリとしてお客さまからのレビューでは、そこそこの評価をいただいているのかなと思っています。

アプリの紹介はこんなところで、タイトルにもあったLeSSですね。もしかしたら初めて聞く方もいるかもしれないので、簡単に紹介させてもらいます。こちらはLarge-Scale Scrumの略で、1つのプロダクトを複数チームで開発するアジャイル、大規模スクラムの開発手法の1つのやり方になっています。

今はセブン銀行アプリの開発で取り入れているので、こちらにおいてLeSSで1on1をやってみたというお話を今日はさせてもらえればと思います。

「アジェンダ」と「伝わるとうれしいこと3つ」

というところで、さっそくアジェンダです。まず、そもそもなんで1on1を始めたかというきっかけをお話しして、次にどうやって1on1をやっているのかというやり方ですね。最後に1on1を実際にやってみてどうだったか。メンバーの反応などをお伝えできればなと思っています。

今回のセッションで伝わるとうれしいことが3つあります。1つ目がスクラム、複数チームのスクラム、LeSSでも1on1はできますよということ。2つ目は1on1を始める時のポイントやコツ。3つ目は悩みを欲しがることの大切さというところが伝わるとうれしいかなと思っています。

黎明期・導入期・成長期・成熟期で変化してきた開発体制

ということで、さっそくアジェンダに入っていきたいと思います。なんで1on1を始めたかというところですね。こちらを紹介する前に、Myセブン銀行アプリはどういったかたち・体制で開発をしているかをまず簡単に紹介できればと思います。ちょっと図が小さくて申し訳ないのですが、2019年から案件の開発が行われて2020年にリリースをしました。

その後はけっこう複数のプロジェクトが立ち上がってきたというところで、それに合わせていろいろ体制を変えています。この丸の一つひとつが人のイメージで、それぞれ色分けが担当と思ってもらえればと思います。これだとさすがにちょっと小さいので、黎明期から導入期、成長期から成熟期みたいなところで簡単に紹介させてもらえればと思います。

まずは黎明期から導入期ですね。リリース前後になるのですが、この時は1チーム制のスクラムでした。全体はウォーターフォールだったので、ハイブリッドアジャイルみたいな形式で、開発チームとQAチームという体制で開発を行っていました。その後、けっこういろいろな大規模な案件が立ち上がってきました。プロジェクトチームがまた立ち上がったり、複数のチームが立ち上がったりしました。

ただ、そうするとこのプロジェクト間でのやり取りとか、既存の保守メンバーとか、そういうところとの連携がうまくいかないところがあって、プロジェクト型の開発ではなくプロダクトの開発に移行するためにLeSSの導入を決め、2021年頃からLeSSで開発を行っています。

LeSSになるので1チームですべて完結するチーム体制としていて、ビジネスアナリスト、アプリエンジニア、サーバーエンジニア、QAの担当が1チームに収まる体制で今は3チーム制になっています。チーム名はそれぞれチームメンバーに付けてもらっていて、動物の名前ですね。フクロウ、ゾウ、ブルズなどの名前で開発を行っています。

LeSS×ハイブリッドアジャイルに移行したことで生まれた課題

これですべてうまくいっているかというと、「実際には大変です」というところがあります。純粋なLeSSではなく、先ほども言ったようなかたちで、大規模案件だとウォーターフォールで進んでいます。LeSSとハイブリッドアジャイルの組み合わせの中、「LeSSブリッドアジャイル」みたいな感じになっています。

また、メンバーも全員正社員というわけではなく、複数社の常駐のエンジニアだったり、派遣の方だったりがいる体制になっています。それと今はみなさんもそうだと思いますが、在宅メインなのでリアルで顔を合わせたことがないメンバーも多数いる状態になっています。

2022年6月ぐらいにLeSSを導入して、半年ぐらい経った時に中長期的なふりかえりをやってみました。タイムラインやKPTを使ってやったのですが、そんな時にこんな声がメンバーから出てきていました。

「ふりかえりだと個人の意見が言いにくい」とか「わからないことを誰に聞けばよいのかがわからないよね」とか。あとはけっこう「人数が増えてきていて潜在化している問題があるんじゃないの？」みたいな声がありました。

体制の問題というより、どちらかというと個人で抱えている問題がもしかしたらいろいろと出ているんじゃないかというのが、その時に思ったことです。そんな時にこんな本に出合いました。ちょっとセッションのタイトルにも使わせてもらったんですが『悩みは欲しがれ』というものになります。

こちらはトーチングという手法で悩みを解決していくやり方になるんですが、その中でやっているのは「1on1」ですね。それが問題の解決に役立ちそうだと思い、まずは1on1をやってみようかなというところで開始をしました。

1on1に対して生じた疑問とスクラムコミュニティからのアドバイス

じゃあ実際に1on1をどうやって始めたのかというところについて、これから紹介していきたいと思います。私自身がそれまで1on1をまったくやったことがなく、まったく知見がない状態でした。なので、産業能率大学の通信講座を受けたり、本を読んだりネットを検索したり、いろいろ情報収集をしていました。だいたい1ヶ月ぐらいでやってみました。

ちょっと勉強して思ったこととして、世の中の1on1は上司と部下を対象としてやることを前提としたものがけっこう多く、スクラム、まして複数チームのLeSSだとどう始めればいいのかが正直よくわからないところがありました。あとは、常駐エンジニアとはどういうかたちでやればいいのかなというところがちょっと疑問にありました。

そこで知っている人に聞いてみようと思い、私はこのスクラム実験室というところに参画させてもらっているんですが、そちらのコミュニティでいろいろと質問をしてアドバイスをもらいました。その時にもらったのが主に5個ぐらいあります。

まず1個目としては、上司と部下でやるわけではないので構えすぎないのがいいということ。「ちょっと話を聞かせてよ」みたいな、そういったノリ、雑談ベースでやるのがいいんじゃないかというところだったり。あとは1on1といってもやり方がいっぱいでコーチング、ティーチングなどいろいろあるので、その進め方をはじめに合意したほうがいいですね。

3つ目。1on1を強制的にやってメンバーに面倒くさいと思われたら本末転倒なので、そういったところを気をつけたほうがいいというところ。なんだかんだ大事なのは関係性なんだよねというところですね。あとは、終わりのタイミングがないとダラダラしてしまうので、そこのタイミングを決めておくのが大事というアドバイスをもらいました。

実際の開催方法・形式

実際に、これらのアドバイスを基にメンバーに資料を作って説明をしました。上司と部下で行うのではなく、スクラムマスターとメンバーで行う対話形式にてやってみるというところですね。

やり方の合意というところでは、こういったかたちでコーチング、メンタリング、ティーチングなどいくつかの例を出して、アドバイスは「あり」がいいのか、「なし」がいいのか、認識を合わせながら選んでもらう形式にしました。

開催方法ですが、強制ではなくあくまでも任意ですよというところだったり、今回はLeSSで始めたので、2週間スプリントでやっているのですが、基本的にスプリントに1チームずつ進めるというかたちにしました。終了基準は3回を1セットというところで、3回ごとに継続確認をしますと伝えています。

最後に、あくまでこれは1on1をやる理由として、ストレスなく楽しく成長できるような構築につながるために1on1を始めたいと思っていますということをメンバーに伝えました。

実際にどんなかたちでやっているかというところですが、非公開のMiroのボードを使ってやっています。オンラインだったり、出社していれば対面でやることもあります。アジェンダは主にこの3つで、始めの5分に話すテーマをお互いに話して、そのテーマに基づいて20分間ぐらい会話します。最後の5分間ぐらいでふりかえりの時間を取っています。

2回目以降は、前回話したことのふりかえりをするかたちになっています。（スライドを示して）実際にこんなかたちでテーマに基づいていろいろ会話して、最後にこれをチャットで送るかたちで進めています。

1on1を開催した結果、9割のメンバーが参加してくれた

この形式で1on1を始めて実際にどうだったかを、これから紹介したいと思います。1on1を8月中旬ぐらいから始めたのですが、約3ヶ月で50回ぐらいやっています。結局9割ぐらいのメンバーが参加してくれているので、だいたい30人ぐらいが参加しています。

そこで気づいたことですが、当たり前ですが、やはり話すテーマはみんな違いましたというところですね。また、チームでふりかえりもレトロ（レトロスペクティブ）もやっているのですが、そこで出てくる課題と個人の課題はぜんぜん別物でした。

例えば「ミーティングが多くて困っています」みたいな話はけっこう個人によることが多いので、チームのレトロには出ていなかったのですが、個人でやるといろいろあるんだなということに気づきました。

3つ目ですね。やり方をはじめにいろいろ提示したのですが、ティーチングを選ぶ人が8割、9割を占めていました。この「アドバイスあり」を求めている人が多かったです。

最後に、実施する側をやってみて、1on1をやるにあたり、実施する側のスキルやコツというのがかなり大事であることに気づきました。

「1on1やってみてわかった7ルール」

スキルやコツについては、ちょっとこんな感じでまとめてみました。7つながりというところで、「1on1やってみてわかった7ルール」を作ってみました。7つ作ってみたので上から紹介させてもらえればと思います。

まずはルール1ですね。「まずは天気の話でも」というところになります。これは何かというと、アイスブレイクですね。1on1を始めていきなり「悩みはなんですか？」と聞くのではなく、雑談をしてから入ることによって、話してくれる内容もいろいろ変わるというところで、必ずこれはやるように心がけています。

ルール2ですね。「主役は相手の悩み」です。1on1は自分の聞きたいことを聞く場ではなく、相手に話したいことを話してもらう場であるということがわかりました。なので自分の聞きたいことだったり、相手の話したことに対して「自分だったらこうする」みたいな話は極力しないように気をつけることが大事というところで気をつけています。

ルール3ですね。「同じ釜の飯を食う」というところですね。1on1の本を読んでいるとけっこう「共感インタビュー」とか「積極的傾聴」というワードが出てくるのですが、これはちょっと聞き慣れない言葉だったので、（読んだ当時は）正直パッと来なかったんですが、やってみてこういうことかなと思いました。

要は、相手の悩みをまじめに聞いて、相手以上にその悩みに向き合うということですね。同じ悩みを共有しましょうというところが、かなり大事なニュアンスなのかなと思い、ルール3として挙げました。

ルール4ですね。「15分はひたすら深掘る」です。もちろん1on1で問題の解決ができればそれに越したことはありませんが、それより大事なものとして、問題が何かという定義のところはかなり重要だと思っています。なので、答えは急がずにまずは聞くことに専念するようにしています。

アインシュタインの名言の1つに「もし世界を救うのに1時間しかなかったら、問題定義をするのに55分、解決策を見つけるのに5分を費やすだろう」みたいなものがあると思います。これは1on1にもまさに当てはまると思っていて、悩みというのは初めに聞いたものと実際に深掘りしたもので真意的なところがかなり違うことがよくあります。

例えば、ビジネスアナリストみたいな役割を新たに作ったのですが、「ビジネスアナリストの役割がちょっとわかりません」という悩みがありました。それを深掘りしていくと、「自分の担当している案件における仕様をエンジニアに伝えるのは役割としてはわかるけれども、プロダクト開発をしている中で、障害の対応や改善系の対応を担う別の担当との連携がうまくいっていません」という話がありました。

そういった真因ですね。何に困っているのかを突き詰めることが大事なのかなと思いました。悩みの種が見つかる時もあるし、見つからない時もありますが、そういった時も次回までに一緒に悩むということが大事なのかなと思っています。

ルール5ですね。「ただ話す」。LeSSのプラクティスの1つに「Just Talk」という手法があります。これを初めて見た時に、けっこう当たり前じゃんと思っていたのですが、実際に1on1を始めてみて、当たり前が実はできていなかったんだなと、あらためて気づかされました。

在宅メインだと、新規のメンバーと関わる機会が始めの時しかなかったり、話す時があっても仕事の話しかしなかったり、というところで、関係性がまだまだできていないメンバーがかなり多くいる、ということに気づかされました。関係性を作るには直接話すのが一番大事だと思うので、この1on1がきっかけとしてかなり重要であるというところで、ルール5として挙げました。

ルール6ですね。「悩みを欲しがれ」です。こちらは先ほどもちょっと出したのですが、『悩みは欲しがれ』の著者が土曜日の深夜に放送されている『FOOT×BRAIN』というサッカー番組に出演した時に出た話で、チームビルディングにおいては目標を共有することも大事だけど、「悩み」を共有できているチームのほうがより強いという話がありました。

これはスクラムにおいても置き換えられるんじゃないかなと思います。どういうことかというと、目標を共有するのはプロダクトオーナーのポジションで、「悩みを欲しがる」のはスクラムマスターの役割かなというところで、この「悩みを欲しがる」ということは大事かなというところで挙げました。

ルール7ですね。「自分からはじめる」です。これはアジャイルでよく出てくるもので、まずは自分でやってみましょうということですね。自律的に始めることが何よりも大事かなと思います。今回の開発は何も知見がないところから始めたので、始めるまで2ヶ月半ぐらい時間がかかってしまったのですが、こういったナレッジがあればおそらく1ヶ月ぐらいでできるんじゃないかなと思います。

このコツはけっこう必要だと思いますが、始めることのハードルをかなり低くできるかなと思ったので、自分から始めるということを挙げました。1on1をやってみてわかった7ルールですね。1から7を紹介しました。

メンバーからはもらった意見と感想

実際に1on1をやってみてどうだったか、メンバーからの声ですね。若手メンバーからは「ふだん聞いてもいいのかがわからなくて迷っていたことが聞けてよかった」とか、常駐エンジニアからは「社員の方に直接悩みを相談できる場があって助かりました」という、わりとポジティブな意見をいただけました。

「今後やっていきたいこと3つ」ですね。まだ始めて3ヶ月なので、1on1を継続していきたいです。あとは、これからもずっとスクラムマスターとチームメンバーでやっていくのは体制を拡大した時に無理が生じてくると思うので、そういったところでも、もっとチーム内で気軽に1on1できるような仕組みを作りたいと思っています。あとは、チーム外メンバーとのシャッフル1on1もあったら楽しそうかなというところで、やっていきたいと思っています。

再掲ですね。（今回の発表で）伝わるとうれしいことです。スクラムや複数のスクラムのLeSSでも1on1はできるんだというところだったり、1on1を実際に始める時にどうやったらいいの？　というところの始め方やポイントやコツ。あとはスクラムにおいての悩みを欲しがることで新たな気づきがあるということが少しでも伝わって、「1on1をやってみました」という人が、1人でも出てきたら非常にうれしいです。

というところで、こちらのセッションを終わりにさせていただければと思います。ご清聴ありがとうございました。