「自律的な開発組織」はいかにして作られたか？　LINEのフロントエンドチームの場合

LINEフロントエンドチームのチームビルディング

大槻友諒氏：フロントエンドエンジニアの大槻です。今日は「一人ひとりの『変えたい』を力に、11人で変化し続けるフロントエンド開発チームができるまで」というタイトルでお話しいたします。

突然ですが、チームの課題と聞いて、どのようなことを思い浮かべますか？日頃、チームで開発をしている方にとっては、日々向きあっているものかもしれません。一方、フロントエンドの現場では1人で実装を担当している方もいらっしゃると思いますので、その場合はデザイナーやQAなど他の職種の人と協業する場面を想像してもらうと、複数人で仕事をする上での課題が想像しやすいかもしれません。

私たちのチームでも、実装に関する意見が割れたり、在宅ワークになって会話が減ったりと、いろいろな課題と向き合ってきました。そんな私たちが、今では課題を乗り越えていけるチームへと変化してきたので、その歩みを紹介しようと思います。それではよろしくお願いします。

あらためて自己紹介いたします。「LINE NEWS」のフロントエンド開発を担当している大槻友諒です。プロダクト開発以外の業務ですと、エンジニアリングマネジメントやスクラムマスターなどをしています。

LINE NEWSには、LINEアプリの右から2番目にある「ニュースタブ」の画面であったり、そこから遷移する記事の画面などがあります。それらの画面を開発しているのが私たちのチームです。

私たちのフロントエンドチームは、サービスがローンチされた2013年の時点ではフロントエンドエンジニアは2人でしたが、サービスの成長に伴い、今では11人に増えました。

今日はこのチームについての話なので、前提をもう少し添えておくと、今年に入ってからは全員がリモートワークをしています。また、裁量労働制をとっているので働く時間もまちまちだったり、雇用形態も違います。派遣社員の方がいたりアルバイトの方がいたり、今年はインターン生も来てくれました。

レベル1〜3を定義し、自律的なチームを目指す

さて、ここからが本題です。みなさんは自律的なチームとはどんなチームだと思いますか？

トラブル時にリーダーが不在であっても最適な対処ができるチームかもしれませんし、自分たちのエンジニアリング力を自主的に向上できるチームかもしれません。

私たちが考える自律的なチームとは、タイトルにもありますように、チームメンバー一人ひとりが変えたい気持ちを持って行動を起こし、チームメンバーがともに変化していくチームです。

この変えたい気持ちから来る行動とは、具体的には2つの行動を指しています。1つ目は、最初に変えたいと思った人がチームメンバーにその思いを伝えて、最初の1歩目を踏み出す行動です。

もう1つは、チームメンバーの変えたい気持ちを歓迎してともに変化していこうとする行動です。これらをチームメンバーが互いに行動し合って、自分たちの課題を改善し続けられるチームを自律的なチームだと考えています。

私はこの自律的なチームについて考えるときに、「変えたい」という気持ちから来る行動がどのように現れているか、その現れ方をもとに簡易的に3段階に分けて考えることがあります。

まずレベル1の状態。これはチームメンバーの中には変えたい気持ちを持っている人がいるかもしれないけれども、行動としてはまだ見えていない状態を指します。この状態だと、なにか問題が起きたときに、それが放置されてしまったり、チームメンバー間での必要なコミュニケーション、仕事の依頼や状況の共有などが遅れてしまう。こういったことが起きる可能性があります。

周りからは、チームメンバー一人ひとりが自分の仕事や自分のタスクにのみ関心を持っているのではないかと思われる可能性もあるでしょう。もっと極端な例だと、自主性がないと思われる可能性もあると思います。ただ、実際にどうかはわからないですね。変えたい気持ちを持っているかもしれないが、行動としては見えていない状態、これがレベル1の状態です。

続いてレベル2の状態。これは特定の人は変えたい気持ちから来る行動を起こしている状態です。なにか問題に出くわしたときに、いつも特定の人が積極的にカバーをしていたり、なにか話し合いをしようとなったときに、いつも特定の人が意見を出して話をリードしていたりする状態です。

こうなってくると、周りからはチームとしては一見うまく機能しているように見えることがあります。逆にチームの内情をよく知っている人には、特定のチームメンバーに依存しているように思われるかもしれません。

そしてレベル3。これは先ほど紹介した理想的な状態ですが、チームメンバーの変えたいという気持ちが行動につながって、それが噛み合っている状態です。課題が見つかったときにすぐにチーム内で共有されて、改善に向かって行動が起きる状態と言えます。

こうなってくると、このチームに安心して仕事を任せられたり、なにかチームで問題が起きたとしてもきっと自分たちで解決してくれるだろうという安心感を、周りから持ってもらえる状態と言えます。

みなさんのチームはどのような状態でしょうか？　チームメンバー一人ひとりの変えたいという気持ちの種は行動となって開花しているでしょうか？

実際には、ある日を境にガツンとレベルが上がることはあまりなくて、少しずつレベル2やレベル3の行動が顕在化してきたり、ふと振り返ったときに「自分たちはレベル3になってきたかもな」と感じるような曖昧なものだと思います。

だからこそ、こういった物差しを定義しておくと変化を自覚しやすくなると思っているので、ここで紹介いたしました。私たちもレベル1やレベル2の状態を時間をかけて行き来しながら、最近ようやくレベル3の行動が増えてきたように感じています。

レベル1、2で起きた開発の諸問題

ここから、私たちがレベル1であることを実感した事例を紹介します。私たちがレベル1の頃は仕事が落ちることが多々ありました。「落ちる」とは、チームの仕事だと認識はしているものの、誰にも担当されずに放置されてしまっている状態を指しています。

具体例を出しますと、今映しているのはコードレビューの依頼をチームメンバーに何度も何度もチャットで投稿しているときのスクリーンショットですが、誰かがやらなければいけないコードレビューといった仕事が着手されず、忘れられてしまうことがありました。

もう1つ別の例ですと、重要だけれども緊急ではない、私たちにとってはTypeScript移行がそれに当たりますが、こういった仕事が後回しにされ続けてしまうことがありました。チームメンバー全員がやらないといけないとは思っていましたが、つまり変えたいという気持ちは全員にありましたが、行動としては現れなかったというものです。

続いてレベル2を実感した事例をお見せします。少しずつ自律的な行動が現れてきた時期ではあったんですが、その反面、合意や判断といったプロセスを忘れ独断で進めてしまった仕事がいくつかありました。その結果、手戻りが発生したり、実装がバッティングしたりということがありました。

こちらも具体例を1つ紹介します。私たちは日頃実装したコードを互いにレビューしあっていますが、TypeScript移行が済んだ直後のある開発案件では、開発の締め切り直前にコードレビューが依頼されました。そして実装者はコードの一部をJSで実装していました。

このとき実装担当者はどうにかして締め切りに間に合わせようと、書き慣れたJSで実装したのですが、レビューした側は原則TSで書くべきといった観点でレビューをしていたので、どうするべきかと衝突しました。締め切りが迫っている中でTS化すべきかどうかという合意のプロセスが抜けていたために衝突が起き、納期と品質がトレードオフになってしまったといった事例でした。

「相手にどう振る舞ってほしいか」が理解できていなかった

このような問題はなぜ起きたのでしょうか？　チームメンバーに問題があったのでしょうか？　私はそうではないと思っています。すべき行動を起こさない場合、そこにはやらない理由ややれない理由があったと思います。どんな理由があったのか、この3つの事例についてもあらためて見てみようと思います。

コードレビューが着手されなかった例です。このときレビューを依頼された側のチームメンバーは、自分の仕事が忙しくてレビューする時間がないと思っていた人もいましたし、今は忙しいからあとで見ようと思っていた人もいました。

また、レビューする気はあるものの、仕様について知識が足らないから、そこから全部習得してレビューするには時間がかかると思い、なかなか着手できずにいた方もいました。また、自分よりも適任がいる、有識者がいるから、そういった人に任せて自分は見なくてもいいなと考えていた人もいました。

コードレビューをしなかった理由はさまざまなんですが、いつまでもコードレビューがされなかった背景には、なぜコードレビューをしないかという考えを伝え合っていなかったこと、理解し合っていなかったことがあると思います。

2つ目、重要だが緊急ではないTypeScript移行が後回しにされ続けていた事例です。こちらもTS化すべきという考えを全員が持っていたんですが、人によりその解釈が少し違いました。

ある人は後回しにするほど修正するコード量も増えるから、できるだけ早く、いますぐにでもTS化すべきと考えていました。一方、別の人は、影響範囲やほかの案件との優先順位などを考慮して、今すぐにTS化するのは少し難しいのではないかと考えていました。

どちらも意見、主張としては正しいものだったんですが、チームにとって今はどういう判断をすべきか、つまりチームにとっての判断基準や価値基準などを理解し合っていなかったために議論は平行線のままで、いつまで経ってもTS化は実行されずにいました。

3つ目の例は、TS化後にJSで実装された案件のことでした。こちらは締め切りが迫っている中で、TS化というコードの品質を取るのか、それとも納期に間に合わせて代わりにJSで実装することを取るのかが議論になりました。

この背景には、レビュー依頼した側は、TS化するか否かの観点を除けば、そんなに複雑な実装ではないからサクッとレビューをお願いしてもらいたい。時間はないけれど、サッと見てapproveをもらいたいと思っていました。

一方、レビューする側は、レビューは余裕を持って出してほしいと思っていましたし、TS化するかしないかは実装に着手する前に相談してほしいと思っていましたし、「原則TS化」を守ってほしいと思っていました。

このとき、私たちは相手にどう振る舞ってほしいかを理解し合っていませんでした。

「相互理解」には強い覚悟が必要だった

3つの事例でなぜ取るべき行動が取られなかったのか、背景を振り返ってみました。あらためて、これらの問題がなぜ起きたのかを考えてみようと思います。

共通して言えることは、互いの考えを伝え合っていなかった、理解し合っていなかったことにあると思っています。

ここで「なぜ伝え合わないんだ？　理解し合わないんだ？」とチームメンバー一人ひとりの問題として注意することは簡単なんですが、それでは改善するかどうかはチームメンバー任せになってしまいます。コミュニケーションが得意な人や相性のいい人同士でしたら、それで十分かもしれませんが、マネジメントとしてこの問題に向き合うには不十分だと考えていました。

私はこれをチームメンバー個々の問題ではなくて、チームメンバーの関係性の問題として捉えました。つまり「なぜ伝え合わないのか？」と行動しなかったことを問題視するのではなくて、行動しやすい関係性が整っていなかったことを問題視したわけです。こう考えると「どうすれば、行動しやすい関係性を整えることができるのか？」と考える幅が広がっていきます。

そして、この行動しやすい関係性を端的に表す言葉が「相互理解」です。つまり、私たちが目指す自律的なチームに近づくためにはこの相互理解が必要だということです。

課題に対して、例えばコードレビューがいつまで経ってもされないという課題に対して、直接的なアプローチをとるのではなくて、問題が起きる前から常日頃から相互理解を積み上げておくことで、課題が見つかったときにチームメンバーが自律的に解決するように関係性をつくるというアプローチです。

これには強い覚悟が必要でした。私自身が「指示を出さないといけない」「自分がまとめ役をやらないといけない」といった思い込みを捨てて、関係性がきちんと整えば、チームメンバーは自律的に行動してくれるはずだと信じ続けることが必要だったからです。

ここまでが前半になります。私たちが自律的なチームに近づくために相互理解を大切にしていることを説明してきました。