LINEのフロントエンドチームが教える、自律的な開発組織になるまでの3つのステップ

3つの「相互理解」を深めるために

大槻友諒氏：ここからは、実際に相互理解をどう深めているかといった実践編をお伝えしていこうと思います。

相互理解と聞くと、家族や親友のような環境をイメージするかもしれませんし、もしかしたら阿吽の呼吸で仕事が進むような様子をイメージするかもしれませんが、そんなに難しいことだとは考えていません。

仕事を円滑に進めるために必要な、最低限の相互理解があればいいと考えています。ですので、何を相互理解したらいいかをまずはお伝えしようと思います。

相互理解すべきことは、大きく分けると3つだと思っています。

順番に説明していきます。1つ目は「一人ひとりの違いについての相互理解」です。価値観やコミュニケーションのスタイルは人によって当然違います。とくに在宅ワークが増えた最近では、自宅環境の違いや、生活サイクルの違いなども今まで以上に実感できるようになってきました。

ですので、私たち一人ひとりがそれらは違って当然だという前提に立って、その違いに興味を持って優劣をつけることなく公平に接し合うことが、一人ひとりの違いを相互理解することです。

もちろん、具体的にどう違うのかまで踏み込んで理解し合えば、よりよくなるとは思うんですが、そこまでいかなくとも、私たちは当然違うんだという前提に立つだけでも、安心して自分のことを相手に伝えたり、意見を出したりできるようになると思います。

2つ目は「チームの方向性の相互理解」です。今お伝えしたように、私たち一人ひとりの考え方は違って当然なので、時には意見が衝突することもあるでしょう。先ほどの「今TS化すべきか、あとですべきか」の例でもありましたね。

こういった場面でこのチームは何を優先するのか、何ファーストなのかについて共通の理解を持っていれば、適切な判断がしやすくなると思います。そのためにこのチームの方向性の共通理解、相互理解というのが必要になってくると思っています。

そして、3つ目は「互いへの期待の相互理解」です。これは私にできることが何で、あなたにしてほしいことが何かを互いに理解し合うことです。これも先ほどの例で出てきました。TS化するどうかの判断は実装より前に依頼してほしいというものですね。

そのほかにも、マネージャーとチームメンバーの間で期待値を揃えておかないと「頼んだのにやってくれない」「言われたとおりにやったのに評価されない」といった認識のズレが起きたりすることがあります。こういったことを防ぐのがこの「互いへの期待の相互理解」だと考えています。

これらの3つの相互理解を深めることがチームの自律につながると考えて取り組んできました。

相互理解の1歩目は自分から踏み出す

何を相互理解すればいいかをお伝えしてきたので、今度はどのように相互理解を深めればいいかをお伝えします。ここからは実際に、私たちが相互理解を深めようとして実践してきたことをお伝えするのですが、その実践する内容よりも実践のときに何を意識していたかを重点的にお伝えしていこうと思いますので、そこを聞いていただけたらと思います。

1つ目は、今年の9月にインターン生がチームメンバーとしてジョインしてくれたときの事例です。この当時私たちのチームは、会話の量が多かったり、ちょっとしたことでも気軽に盛り上がれる関係性はできていたんですが、それがかえってインターン生からすると、輪に入りにくい感じがあるのではないかと気にしていました。

そこで私は、「偏愛マップ」という自分の好きなものについてひたすら書くマップを見せ合って、コミュニケーション、相互理解のきっかけを見つけてもらいたいと考えていました。それを実際に作って、チャットに投稿して「みんなで見てみませんか？」と提案したときのスクリーンショットが今画面に映っています。

この事例では、自分の価値観や興味について知ってもらうきっかけづくりとしての取り組みでしたので、これは「一人ひとりの違いの相互理解」と言えると思います。

そして、これを実践するときに気をつけていたこと、ここからが大事な部分ですが、気をつけていたことは自分から始めることです。相互理解を深めようと思ったら、最初に私が意識することは必ずこれです。

相互理解するためには当然、自分のことを相手に伝える必要があります。つまり、自己開示をする必要があります。ただ、自己開示って一般的には心理的なハードルがあるものだと思います。

不慣れな相手に、自分のことを知られるのは抵抗があるはずなので、いきなり相手に自己開示を強要するのではなくて、まずは自分からやってみせることがとても大事なことだと考えています。

そして、この事例にあたって大事にしていたことがもう1つあります。それは参加しやすい空気づくりから始めることです。いきなり全員に「偏愛マップを作ってください」というのは、手間もかかることですし、先ほどお伝えした自己開示の心理的なハードルもあると思いますので、最初は「気になるものがあったらリアクションしてください」くらいの簡単に関わるきっかけを意識していました。

これを見ておもしろそうと思って、偏愛マップを作ってくれるチームメンバーがいればうれしいですし、いなくてもここをきっかけに会話が広がるだけでも相互理解には十分なるなと思っていました。

結果的に、リアクションをいっぱいもらえたり、ここから会話が生まれたりしました。

この事例をまとめると、今回の事例は一人ひとりの違いについての相互理解の事例でした。このとき意識していたことは、自分から始めることと参加しやすい空気づくりから始めることです。

相互理解を深める環境づくりに着手

もう1つ別の例を見てみます。こちらはチームメンバーとスキルマップを作ったときの例になります。スキルマップは、業務で必要なスキルを洗い出して、チームメンバー一人ひとりの持っているスキルを一覧化したものなんですが、私たちは「経験が多いか・少ないか」、あとは「好きか・嫌いか」の2軸でマッピングする方法をとっています。

今、画面に映しているものも、このスキルマップを作ってみませんかと提案したときのチャットのスクリーンショットです。

これも一人ひとりの違いについての相互理解と言えると思います。互いの興味関心や得意分野を知ることで、なにか困ったときに相談する先が予測しやすかったり、なにかをチャレンジしたいと思ったときに、一緒に巻き込む相手、協力してやる相手を見つけやすくなったりすることを意識して、取り組んでいました。

この事例を実践するにあたって意識していたことは、チームの状況を見極めることから始めることです。スキルマップを作って紹介し合って、そこから会話をさらにするのはけっこう時間のかかることだと思います。11人全員でこれをすると、短くても2時間ぐらいはかかると思います。そして自己開示の心理的ハードルも高いものだと思っています。

ですので、簡単に実践できる取り組みではないとは思っていたんですが、私たちは毎週モブワークの時間を確保しています。あとはその緑枠で囲っているところに「1年ぶりに」という言葉がありますが、ちょうど1年前にもスキルマップづくりをやっていてそろそろ変化が互いに気になるころだろうということも加味していたり、現状の仕事の量を考慮したりと、いろいろな観点でチームの状況を見極めた上で、この方法を実践するに至りました。

あわせて、先ほど紹介した参加しやすい空気づくりから始めることも意識しています。全員必須参加とするわけではなくて、なにかしらの緊急の業務をしている人もいるかもしれないですし、今はあまり興味を持てない人もいるかもしれないので、都合のつく方や関心のつく方から参加するかたちで、なるべく参加のハードルを下げることを意識していました。

そして、実際にメンバーに集まってもらうことができて、無事完成させることができました。中身について詳しくは紹介できないので、気になる方はあとでスライドを見ていただきたいです。

この例をまとめますと、今回も一人ひとりの違いについて相互理解する例でした。意識していたことは、チームの状態を見極めることから始めることと、参加しやすい空気づくりから始めることです。

デリゲーションレベルを設定し、権限移譲

3つ目の例。これが最後の例になります。これまでとはちょっと違う例を持ってきました。先ほど紹介した、TS化と納期、どちらを優先するかと議論になった案件がリリースされたあとに行った振り返りのディスカッションのログを今画面に映しています。

私たちの振り返りは、ウェブ会議をつないで、共同編集できるエディタを開いて、みんなで書き込みながら対話する方法をとっているので、そのときの一部を今ここでご紹介しています。こちらも中について詳しく説明はしませんので、気になる方はあとでスライドを見てみてください。

上のほうに「ふりかえりたい観点」と書いてありまして、この中に「経験の少ない案件をやる場合の見積もり、時間配分、合意形成、体制などで考慮したいこと」について話そうとしています。つまり、共通認識を作ろうとしています。これはチームとしての決めごとや方針を言語化して認識を揃えようとしている事例なので、チームの方向性の相互理解と言えると思います。

そして、その振り返りたい観点の4番目に「コードレビューの依頼の出し方」があります。これも先ほど紹介した「TS化するかどうかは早いタイミングで相談してほしい」「締め切り直前でのレビューはやめてほしい」など、そういったことですね。こういったものの認識を揃えようとしているわけです。これはチームの方向性の相互理解であり、互いへの期待の相互理解であると言えると思います。

続いて別のログです。こちらは先ほどの観点を決めたあとに実際にディスカッションしたときのログの一部です。「TS化と納期のどちらを優先するかを最終的に誰が判断するのか。マネージャーが判断するのか、チームメンバーがするのか」といった権限移譲の度合いについて、認識を揃えようとしていたときの議論です。

ここでは、権限移譲の度合いをデリゲーションレベルと言っています。このデリゲーションレベルを7段階に分ける考え方を使って、「このとき私たちはレベルいくつだと考えていたか」のすり合わせをしました。例えば「3. 相談する」のあとに星が5つついているんですが、これはチームメンバーのうち5人がこのレベルだと考えていたということです。

これはまさしく「私はどこまですべきか」「あなたにどこまでしてほしいか」といった互いの期待の相互理解を深めていった例と言えると思います。

デリゲーションレベルの議論をするにあたっては、この議論を十分に行えるぐらいの経験が貯まっているかを意識していました。つまり「チームの状態を見極めることから始める」を実践していました。

日々の仕事の内容や進め方を十分に理解する前に権限移譲の度合いの話をすることは難しいですし、互いの考えをきちんと言い合える関係性ができあがってからでないと、ここまでやってほしいと正直に伝えるのは難しいんじゃないかと思っています。

なので、マネジメントにおいて権限移譲とは大事な要素の1つではありますが、チームとしての成熟度が高まってから、この話題に触れようと考えていました。もちろんこのタイミングはチームによって違うとは思います。

まとめますと、この例ではチームの方向性についての相互理解と互いへの期待の相互理解を深める事例でした。このとき気をつけていたことはチームの状態を見極めることから始めることでした。

変化を体感できるまでは半年以上かかった

ここまでで3つの実践例を紹介してきました。その中で触れた相互理解を深めるときに意識してきたことがいくつかあったんですけれども、あらためて紹介します。1つ目は「自分から始める」。2つ目は「参加しやすい空気づくりから始める」。そして3つ目が「チームの状態の見極めから始める」でした。

このチームの状態の見極めはちょっと複雑でした。チームの状態を見極める軸は、さまざまなものがあると思います。忙しいかどうかであったり、協業に慣れているかどうかであったり、チームとして成熟しているかどうかであったり、ほかにもさまざまな観点があるはずです。

相互理解については、その方法について調べると情報はけっこう多く出てきます。どれも実践したら、効果がありそうだなと思えるものが多いんですが、その方法が今の自分たちに適しているかどうか、今すべきかどうかをしっかりと見極めてから始めることを、私たちは意識して取り組んできました。

そして、やはり大切なことは、相互理解を深めるという目的です。今回紹介した3つの事例は、決してお手本ではなくて、あくまで一例に過ぎません。とくにこのセッションに向けて印象的だった事例をピックアップして紹介しましたので、実際にはスキルマップを書くようなイベントごとを開催して相互理解を深めようとするケースは稀です。それよりも日々のコミュニケーションの中で、互いを理解しようとすることを常々意識してきています。

日々のコミュニケーションの中で小さな相互理解を時間をかけて積み重ねて、少しずつ変化を起こしてきました。私たちが変化を体感できるようになるまでは、半年以上はかかったように感じています。

メンバーの「変えたい」という思いが実現できるチームに

ここまでで私たちの相互理解の深め方について説明をしてきました。これらの相互理解の実践によって私たちのチームがどのような状態になったのかをこのあとお見せして、まとめに入っていこうと思っています。

前半部分で、重要だけれども急ぎではない仕事が後回しにされる例で紹介したTypeScript移行ですが、これは自律的な行動が増えてきたタイミングで、あるチームメンバーから、今まで着手できなかった理由を明らかにして、段階的に移行していく土台をつくりましょうと提案が上がりました。

これはまさしく変えたいと思った最初の1人目が最初の行動を踏み出した事例でしょう。そして、これに対してチームメンバーも協力する姿勢を見せて、今まで話したけどできなかったから諦めようとするのではなくて、どうやったら行動に移せるかを一緒に議論した結果、長らく放置されていたこのTS化は成就しました。

このときの詳細は別のミートアップでチームメンバーが発表しているので、よければ過去の資料を見てみてください。

そしてもう1つ、忘れられがちなコードレビューについても、チームメンバーから自然と自律的な改善が生まれてきました。

レビューを依頼する側は、依頼時に難易度を添えたり……今の画面ですと上のほうに緑の枠で囲ってある部分ですね。星が3つついていますが、難易度を添えるようにしたり、背景が複雑な案件については、レビューの前に口頭で説明するといった提案をすることが自然と生まれてきました。

また、レビューする側は「見ます」「あとで見ます」といった一次返答をなるべく早くするように変化が生まれました。これらも変えたいという気持ちから生まれた行動になります。

ほかにも細かい変化はいっぱいあって、すべてを紹介することはできないんですが、自律的に課題に向き合っていく仕組みとして、自分が気づいた課題を自由に投稿する「battleground」というSlackチャンネルを私たちのチームでは運用しています。今、画面に映しているのはその一部のスクリーンショットですが、コードベースの振り返りがしたいと書かれています。

この課題を自由に投稿するSlackチャンネルと対になっている仕組みがあります。毎週1時間、この内容をもとに議論する時間です。これは実際にコードべースによる振り返りをしたときのログですが、このように気づいたことを投稿する先と、それをもとに話し合う時間をセットで運用していて、これもチームメンバーの自律的な行動で始まった取り組みです。

これはチームメンバーの変えたいという気持ちにチームメンバー全員で向き合おうという意思が具現化されたアイデアだと感じていて、チームの自慢できるところの1つです。

変化を恐れず、変化を歓迎するチームビルディング

さて、まとめに入ります。長かった内容を、一気におさらいしていきましょう。私たちの考える自律的なチームとは、チームメンバー一人ひとりが変えたい気持ちを持って行動を起こし、チームメンバーがともに変化していくチームでした。

自律的なチームに必要な行動を引き出す大事な要素が相互理解でした。これは課題に対して直接アプローチするのではなくて、常日頃から相互理解を深めて土台づくりをしておくことで、課題に自律的に対処できるようになることを意図しています。

相互理解するポイントは3つありました。一人ひとりの違いについて。チームの方向性について。そして互いへの期待についてです。

これを実践するときに意識してきた3つの始め方がありました。自分から始めること。参加しやすい空気づくりから始めること。チームの状態の見極めから始めること。以上が今日お話しした内容になります。

最後にマネージャーやリーダーのみなさん。みなさんはチームメンバーの変えたい気持ちの種が開花するように日々試行錯誤していることと思います。今回、お話しした相互理解という切り口が、なにかしらのお役に立てればうれしいです。

逆に、もっと違った切り口でチームづくりをしているというアイデアがあれば、ぜひ教えていただきたいです。ともにチームメンバーが力を存分に発揮できるチームづくりをしていきましょう。

そして、チームメンバーのみなさん。これを聞いてくださっているということは、チームについてなにかしらの関心を持っていることだと思います。チームが変化していくためには、みなさんの変えたい気持ちが欠かせません。本セッションで紹介した、最初の一歩目を踏み出す行動や、チームメンバーの変えたいという気持ちを歓迎して、ともに変化しようとする行動をしてくれる人が必要なのです。

とはいえ、どのように行動すればいいかわからなかったり、チームの中でいきなり自分が行動を起こすことが躊躇われることもあると思います。

なかなか糸口も見つからず、苦しんでしまうこともあるかと思いますが、そういったときは私たちのチームに遊びに来てください。一緒に意見交換をしながら、お互いの行動のヒントを見つけ合えればと思います。

以上で私の発表を終わりにします。ご清聴いただき、ありがとうございました。