「メンバーを信用していないのでは？」　“ある指摘”から始まったLINEアプリ開発チームの生産性改善施策

LINEのクライアントアプリ開発チームの効率化事例

竹下秀則氏：みなさん、こんにちは。今日は「大規模クライアントアプリ開発チームの生産性を改善した仕組み化の数々」というタイトルでお話しします。LINE福岡開発1室所属のエンジニアリングマネージャー、竹下と申します。よろしくお願いいたします。

さっそくですが、本日のアジェンダはこちらになります。まずは私がマネージャーとして所属している、今日お話しする改善の舞台となったチームについて紹介します。

次にそこで直面した課題の数々について赤裸々にお話しいたします。それから、その課題に対してどのような改善策を、どうやってチームに適用したかについて、そして最後にまとめと今後の課題についてお話しいたします。

ではチームについてご紹介します。私たちチームが開発に携わっているLINEクライアントアプリはグローバル5拠点で開発しており、iOS、Android合わせて約200人ほどのクライアントエンジニアが開発に関わっています。最初に紹介したように、私はLINE Fukuokaに所属しています。

LINE FukuokaはLINEの国内第2の拠点です。2021年1月時点でエンジニアは全体で87人、海外籍メンバーの比率が57パーセントほどとなっています。私が在籍しているチームにはさまざまな国籍のiOS、Androidのクライアントエンジニア13名ほどが所属しています。

そのチームで、LINEアプリの数ある機能の中でもShopと呼ばれるパートを担当しています。このパートでは、主にユーザーがコミュニケーションを円滑に行うために購入できるプロダクト群であるLINEスタンプや絵文字、それに加えて着せかえなどの機能を取り扱っています。

2017年にShop開発を東京から引き継ぎました。当時は私を含めて5名というチームサイズでしたが、その後4年ほどで13名まで大きくなりました。ちなみにチーム発足当時、私はiOSエンジニアとして開発も行うプレイングマネジメントのスタイルでしたが、その後チームサイズの拡大とともにマネージャー業の比率が上がり、現在はほぼマネジメントに専念しています。

少しだけ開発フローに触れますと、LINEアプリは2週間のリリーストレインを採用しており、各パートごとに企画者、QAメンバーといった関係者と協力しながら、最終的に1つのアプリとして安定的・継続的なリリースを実現しています。我々Shopクライアントチームも同様に、世界各地の開発チーム、関係者と連携を取りつつ、2週間ごとのリリースに合わせて開発を行っています。

チームの成長を妨げる課題の数々

では、このように成長していったチームでどのような課題が出てきたのかについて、お話しいたします。

いきなりですが、主だった課題を箇条書きにしてみました。上から順に「コードレビューを誰に依頼したらよいか」「iOS、Androidで実装の差異が負債化した」「障害が増えた」「新メンバーのオンボーディングに苦労した」「知識が属人化している」「ドキュメントがない、またはあっても古い」などなどです。

恐らく同じような課題に、まさに頭を悩ましていらっしゃる方もいるのではないでしょうか。また、これらの課題のいくつかは、そもそも即大きな問題として現れるものではないけれどもジワジワと効いてくるといった類の、チームを拡大していく際に避けることができない課題です。

例えば業務知識に偏りがあるとか、ドキュメントが足りていないといったことは頭にずっとありましたが、忙しさにかまけて優先度を下げ、特にチームとしての改善方針などを検討することもなく後回しになっていました。

そうこうしていると、最終的に避けるべき大きな問題、つまり、障害として自分たちに降りかかってきます。そして、障害対応に手を取られている間にも案件は進行しますので、改善に対峙することがいつまでもできない、というループに陥ってしまっていたのです。

日々の忙しさを理由に、中長期的な目線でチームのためにやるべきことをやれていない。その結果、先ほど挙げたようなさまざまな問題を抱え込んでしまっていました。これはつまり、チームとして解決すべき課題の優先順位を見誤ったマネジメントの失敗であり、マネージャーがチーム成長のボトルネックになっている状態だと思いました。

マネージャー業を行ううえで私がとても参考にしている、キム・スコットさんの『Radical Candor』という本に「毎日2時間は必ず考える時間を確保し、それを神聖なものとして扱いなさい」というような言葉がありました。これには完全に同意していたのですが、そんな余裕はありませんでした。

では、そもそも何がそんなに忙しかったのでしょうか。その忙しさの正体は何だったんでしょうか。

もともと、マネージャーである私が他部署とのコンタクトポイントとなり、ほとんどの案件の1次コミュニケーションを担っていました。他部署の関係者も少ない時はよかったのですが、プランナーやQAの方を始め、他にも関係する部署が増えたにも関わらず、同じ体制を続けていると、コミュニケーションや会議がマネージャーに集中することが忙しさの一因としてありました。

これをみんなに分担してもらうしかありません。でも腰が重かったので後回しになってしまっていたのです。それはなぜだったのでしょうか。

360度評価制度でズバリ指摘された

考えを整理すると、まず「メンバーがうまくやれるか心配」ということがありました。そして、その心配も2つに分けることができました。まずは「スキル的に任せることができるのか」という心配。これはテクニカルなスキルだけではなく、コミュニケーションなども含めた仕事を進めるうえでの総合的なスキルのことです。

もう1つは言語の課題です。弊社ではSlackなどのチャットは基本的に通訳botを入れていたり、会議では専属の通訳さんにヘルプしてもらったりとサポートは十分に用意されています。それでもやはり得意な言語でコミュニケーションできないのはつらい部分もあるでしょう。自分に置き換えてもわかります。

もう1つの心配が、そもそもこういったコミュニケーションは手間と時間が掛かることが多く、実際のところあまりやりたくないんじゃないか、というものです。

これらの心配については、いわゆるマネージャーが陥りがちな「自分がやったほうが早い」という考え方で解決しがちな部分かと思いました。そして、自分はまんまとそうなっていました。「自分が一手に引き受けてしまえばよい」という短絡的な考えで、これらをやり過ごしていたのです。

ですが、こうやって自分がコミュニケーションの場を独占することにより自身の時間的余裕がなくなること以外にも、各ステークホルダーとチームメンバーが協業する機会を奪い、結果メンバーの仕事の幅を狭めてしまう、ということに懸念を感じるようになりました。

実はそれを気づかせてくれたきっかけの1つは、弊社の360度評価制度でもあります。これは、半期ごとに協業相手を匿名で評価し合うシステムなのですが、ここでさまざまなフィードバックを同僚から受け取ることができます。

ある時、この評価で「あなたばかり前に出てきてメンバーに仕事を任せようとしないように見える。実はメンバーを信用していないのではないか」といったフィードバックを受けたのです。薄々と感じていたことをズバリ指摘され「これはなんとかするしかない」と考えを新たにしました。

ですが、そもそも誰に・どう引き継ぐか整理できていないので、体制を変えることができない。チームサイズも大きくなってきたので、アドホックに対応するのではなく、今後を見据えて仕組み化する必要があると考えました。

まずは、マネージャーの権限移譲から

ということで、ここからが実際に取り組んだ内容になります。まず、先ほどお話ししたように、こういった課題がチームに起きていたのでした。そしてこれらの解決にコミットしていくために、まずはマネージャーがボトルネックになっている状況を解決したく、仕組み化が必要と考えたのでした。

この問題を改善するために、私が抱えてる役割のうち引き継げるものをメンバーに渡していく方法として、Component Leadシステムという仕組みを考え、チームに提案することにしました。具体的な内容についてお話ししていきます。

最初にお話ししたように、ShopというパートにはLINEスタンプ・絵文字・着せかえといった商品があり、トークルームのキーボード部分の機能なども担当範囲になっているのですが、取り立てて専任の担当は決めておらず、対応案件がある場合に手が空いている人が対応する、という方針でした。

まずは、マネージャーである私が抱えている仕事を機能ごとに分割して委譲していけばよいのではないかと考え、機能ごとに担当者を配置して責任範囲を明確にしようと思いました。

機能ごとにどう分けるのかについてご説明します。弊社ではBTSにJIRAを利用しています。JIRAのチケットにはさまざまなフィールドがあるのですが、その中にComponentというフィールドがあります。モジュールや機能ごとに任意の名前を定義して利用するフィールドとなっており、LINEアプリでも機能ごとに分類する用途として使っています。

ここにはLeadを設定する項目があり、ここに設定された人をそのComponentが付与されたチケットのデフォルトアサイニーとして設定させることができます。そこで、Shop関連のComponentを見直し整理して、それぞれにLeadを任命することにしました。

そして各機能ごとの相談窓口もこのComponent Leadに委譲していくようにしました。これでマネージャーがやっていた役割のうち、関係者との窓口の役割を機能ごとにComponent Leaderに委譲できる状態になりました。同時に、リソースの状況を見てアサイン先を決めるステップも解消されました。

また、Slackで各担当に連絡する際に便利なように、Slackで各Componentに対してユーザーグループを設定しました。こうすることで、外部からは「誰が担当者なのか」ということを知らない状態でも連絡が容易になります。もちろん担当者の名前は覚えてほしいのですが、利便性は高いと考えました。

Component Leadが業務アサイン

さらに「Component Leadはその担当領域の実装に詳しくあるべき」と仮定して「コードレビューの担当者という役割を持ってもよさそう」と考えました。そしてLead自身が必ずしも担当Componentの開発を行う必要はなく、他メンバーをアサインできる仕組みにすれば負荷を分散することもできますし、アサインされたメンバーはその領域の実装に詳しいComponent Leadがコードレビューをしてくれるということで、安心して開発に臨めそうです。

しかし「Component Lead自身が開発した場合に誰がレビューするか」という問題があります。さらに各Componentは規模がそれぞれ違うため、あるComponentは巨大、かつ発生する案件の量も多いが、あるComponentはそうでもない、といったように、コードレビューの負担量がまったく違います。

そこでComponentの中の機能を細分化し、Sub Componentという分類を行い、それぞれにSub Component Leadと呼ぶ担当を付けるようにしました。これは特にJIRAの機能と結びつくものはなく、独自に作った概念になります。

そして、このSub Component Leadは、その細分化された領域のコードレビューを担当するのです。こうすることで、Component Leadが開発を行った場合のレビュアーとしても機能できます。

さらにSub Component Leadは複数人任命することができるようにすることで、コードレビュー対象が多い場合の負荷軽減もできます。

例えば、スタンプというComponentには6つのSub Componentを作りました。ログインやデータのシンク周りの担当。送受信ロジックの担当。アニメーションやサウンドなど、動きがあるスタンプ周りの担当。カスタムスタンプやメッセージスタンプなどの、ユーザーが文字を入力できるスタンプ周りの担当。そして設定ページの機能担当です。

そして、これらのSub Componentで特に重要な部分や頻繁にレビューが発生する場所には、複数人のSub Component Leadを割り当てました。もちろんメンバーの数には限りがありますので、1人につき重複していくつかのSub Componentを担当する方もいます。そしてComponent Leadは、これらすべての領域について担当する、というイメージです。

GitHubのCode Owners機能も駆使

では次にGitHub上でComponent Lead、Sub Component Leadをプルリクエストのレビュアーとして自動的にアサインするための設定についてお話しします。これにはCode Ownersの仕組みを利用します。

ご存じの方も多いと思いますが、Code OwnersはGitHubの機能で、リポジトリの.githubディレクトリの下にCODEOWNERSファイルを置いて適宜宣言することで、修正されたファイルに対して定義されたオーナーが、適宜レビュアーとしてプルリクエスト作成時に自動でサジェストされる仕組みです。

具体的にはComponent Lead、Sub Component Leadは、それぞれ自分が担当するファイル名の横に＠付きで自分のユーザーネームを書いておくことで、該当ファイルに修正があるプルリクエストが作成されると、オーサーが任意のレビュアーを指定しなくても自動でレビュアーが設定されますので、スムーズにレビュー依頼ができます。

タスク依頼が来てからレビューされるまでの一連の流れのフローがこちらです。先ほどお話ししたように、Component Leadがまずタスクをいったん受け取り、その後実際に開発するメンバーのアサインを行います。

開発が終わると、レビュアーはGitHubのCode Owner機能により自動的にComponent LeadおよびSub Component Leadにアサインされます。また、同時にチームアカウントも全ファイルに設定していますので、2人以上にレビューしてもらえる仕組みになっています。

このような仕組みにすることで、メンバー全員のサービスに対する経験向上・理解促進のために、実装作業は自身の担当Componentに限らず行えるという状況を作り、その部分の仕様や実装に対する十分な知識があるはずのComponent Lead、またはSub Component Leadがレビューすることで、実装担当の心理的負荷や不安を低減し、品質を担保しようという考えです。

Component Lead、Sub Component Leadそれぞれの役割と、1人のメンバーが担当する量を整理します。

Component Leadの責務は各ステークホルダーとのコミュニケーションからタスクアサイン、Componentが含むSub Component全体のコードレビュー。そしてドキュメントの管理に関しても、詳細はまた後ほどお話ししますが、各Component Lead、Sub Component Leadで分担して管理するとよいのではないかと考え、これも各Leadの責務としました。

Sub Component Leadの責務はコードレビューとドキュメントの管理です。また、立候補を募るにあたり、Component Leadは単純に開発タスク以外の責任も増えますので、希望者にお任せするかたちにしたい、と考え、メンバー1人につき0個以上という割り当てにしました。Componentの大きさとメンバーの力量・意欲によっては複数担当も可能という仕組みです。

一方、Sub Component Leadは、担当箇所のコードレビューとドキュメント管理という、一般的に開発者が行う責務しか持たせていないので、1人最低1個は担当してもらうようにしました。

Component Leadシステムで利用したツールの設定をまとめるとこのような感じです。JIRAにおいてはComponent Leadを設定することでJIRAチケットのアサイン先を自動化および明確化。GitHubにおいてはCode Ownerの仕組みを使うことで、レビュアー設定の自動化および明確化。SlackではユーザーグループをComponentごとに作ることで、問い合わせ先を明確化しました。

メンバーの成長機会の損失も減ってきた

さて、このような仕組み化を行ってきたことでマネージャーからメンバーへの仕事の委譲ができるようになり、メンバー成長機会の損失も改善できる基盤が整ってきました。ですが、仕事を委譲していくにあたっていくつかの不安を持っていたのでした。そもそもうまくできるのか。また、このような仕事はやりたくないのではないか、という部分です。

そこで、まずは仕組みの草案ができた時点で何人かのメンバーに先立ってヒアリングを行い、方向性に問題や抵抗感がないかということを確認しました。そして、メンバーのみなさんに齟齬なくしっかりと「なぜこれが必要で、何を解決するのか」という部分を理解してもらうために、プレゼン資料を作りました。

また、英語話者にも齟齬なく伝わるように、事前に開発組織専属の通訳さんにも査読をしてもらい、準備を万全に行いました。

これらを行った結果、メンバーからは特に反発もなく、むしろ協力的にこの新しい仕組みに取り組んでいく姿勢を見せてもらえて、とてもうれしく感じました。そしてあくまでも強制ではなく立候補というかたちでComponent Leadの希望者を募りました。

私のチームではComponentの数よりもメンバーの数が少なかったので、どうしても1人で複数のComponentを担当する方が必要になったのですが、比較的仕事量が少なそうなComponentを1人で複数担当してもらったり、とわりとスムーズに担当を決定することができました。

デリゲーションポーカーで期待値調整

とはいえ、個々人の経験や実力を踏まえると、同じ仕組みを全員がうまく同程度にこなせるかどうかについては当然差が出るでしょうし、マネージャー・メンバーお互いにできるだけストレスなく運用できるように、期待値を調整しておきたいと考えました。

そこで利用したのがデリゲーションポーカーです。デリゲーションポーカーというのは、アジャイル開発の流れを汲むマネジメント手法である『Management 3.0』で提唱されているプラクティスの1つです。

これはマネージャーとメンバー間でどの程度仕事を委譲するのかを明確にするアクティビティでして、レベルが1から7まであり、大きくなるほど委譲度が高いということになります。例えば、シニアエンジニアにはレベル5以上を期待する、といった具合です。

ここでしっかりとお互いがどこまで仕事を任せる・引き受けるのかを明確にしておくことで、期待値をはっきりさせておくことができ、最終的に正しい評価を相手に対して行えるようになると思います。

ちなみに余談ですが、弊社にはEffective Team and Delivery室という全社的にプロジェクトマネジメントやアジャイルコーチングを提供する専門組織があり、相談すると先ほどお話ししたような問題解決のためのヒントやアイデアを貰うことができ、非常に心強いです。ご興味ある方はぜひ、こちらの資料もご参照されてください。

さて、このような施策を行いながらメンバーと向き合うことで、私が持っていた不安も解消され、マネージャーがチームのボトルネックとなっている状況を打破する準備ができました。

（後半へつづく）