チームでプロダクト開発をしているものの、ジュニアエンジニアが十分に成長していない…。1人でやれるタスクは増えているものの、それなりの規模の開発案件を責任を持ってやり遂げるだけのオーナーシップやリーダーシップがなかなか養われない…。

一方で、難易度の高い案件やスケジュールの厳しい案件などは特定のシニアエンジニアの馬力によって乗り越えているため、特定の人に負荷が集中してばかり…。

こんなチーム状況が1〜2年近く続いているとしたら、そのチームには改善の余地があります。

短期的にはシニアエンジニアの馬力頼りで走り切るサバイバルモードが必要な場面もあります。しかしそれが1年以上も続けばシニアエンジニアだって疲弊しますし、「なぜ自分はロクに変化の起きないこのチームの面倒を見続けているのか」と不満を抱きチームを離れる可能性すらあるでしょう。

つまりいつかは区切りをつけ学習モードへ切り替える必要があり、切り替えが起きない状況は、強い意思を持って手を加える必要があるということです。

チームによって向き合うべき課題は違うので普遍的に使えるTipsはあまりないですが、上述のようなサバイバル沼に陥りやすい要因が経験から見えてきたので、チェックリスト的に共有します。

……それにしても妙に具体的な”入り”だなと感じた人は勘が鋭いです。つまり私が失敗してきた事例とそこから得た学びを共有するということです。恥ずかしいですが山程失敗してきたので、学びのお裾分けをしてみようと思います。

要因1: トップダウン的なタスクアサインをしている

シニアエンジニアやテックリードなどの特定の1人からチームメンバーにタスクを分配しているチームは注意が必要です。タスクを受け取るメンバーからすれば「与えられたタスクをやれば自分の役割を満たせる」と感じます。自分のタスク以外への興味が薄れ、チームとしてのアウトプットを意識しなくなります。

その結果、チームメンバーはチーム全体やプロジェクト全体を俯瞰する視点を持つ機会や必要性がなく、リード的な視野・視座をいつまでも持てず、反面タスクを分配する特定の1人にのみ負担が集中します。

おすすめの解決策はセルフアサインです。

まずバックログアイテムや案件仕様書を『チーム全員のもの』と捉え、チームでタスク分解します。そして今回のイテレーションで着手する分だけ、各自が手を挙げる形式でセルフアサインします。予定より早く終わったときは分解したタスクの残りから追加でセルフアサインしても良いですし、チームメンバーを手助けしても良いでしょう。

ポイントはバックログや案件を『チーム(メンバー全員)のもの』と捉えることと、自らの意思でタスクを選択することです。これにより全体感を捉える視野や、チームのアウトプットを自分ごとと捉える機会が生まれます。

要因2: 状況の共有頻度が低い、また共有内容に関心がない

日々の仕事内容についてチームメンバー間での共有頻度が低い場合や、共有内容への関心が薄い場合、要因①と同様にチームメンバーのリーダーシップやオーナーシップが育つチャンスを失います。

チームやプロダクトの状況を把握しそれに応じて自身の行動を調整する、という一連の活動の延長線上に『リーダーシップ』が存在します。この行動を促すには、状況を把握する機会、そして自分の行動を調整する機会を増やすことが重要です。

つまり、状況を知る機会が頻繁にあり、その場の内容に関心をもって臨めると良いというわけです。

「そんなことは分かっていて、デイリースタンドアップをしているものの惰性的で形骸化している」といった場合は、場をチューニングしてみます。

個人の進捗共有が目的ではなく、チームの計画やゴールのための再調整の場であると目的を再確認し、それに向かうようファシリテーションすることでチューニングできます。それでも良くならない場合は、そのミーティングを一度消滅させ、新しい名前、新しい時間帯、新しいフォーマットで場作りをし、気分を一新することが効果的かもしれません。

要因3: 現状に問題がないので働き方のアップデートをしていない

ふりかえりで意見が出なかったり、現状の仕事のプロセスに変化が起きなかったりといった状況が長く続くものの、『特段問題がないから現状維持で良い』という考えがチームに蔓延している場合、実はゆるやかにチームが衰退しているケースが多いです。

逆に考えてみると「現状に問題がある」というのは、問題が顕在化しているということです。
「問題がないから改善しない」は「問題が顕在化するまで何もしない」と言い換えられます。

そして変化が起きない状況が続くにつれて、ますます変化は生まれにくくなります。日常的に新しい試みを積み重ねているチームと比べると、変化してこなかったチームにとって「変化は特別なこと」であり、変化への耐性が身についていません。つまり変わることへの抵抗感が強いです。

言い換えると、変化を日常的にし、「働き方は自ら考えアップデートするものだ」と捉えることで、チームのプロセスに対するオーナーシップが育ちます。

オーナーシップが発揮され始めてくると「Aさんはミーティングの効率化に積極的」「Bさんはレビュープロセスへの関心が高い」といった具合に、各々の長所が見えてきます。そうなれば改善は加速し、チームメンバー一人ひとりの積極性ある行動が増え、行動が増えれば学びが増え、チームメンバーもチームも育っていくでしょう。

要因4: ふりかえりをしているつもりだが、働き方のアップデートをしていない

「自分たちは改善活動をしている」と思っているが、その実態が「KPTを実施しているしコードのリファクタリングもしているが、メンバーの役割や仕事のプロセスについては何もアップデートしていない」という状況であれば要注意です。

「自分たちは継続的な改善活動をしている」と錯覚しやすい例が「(KPTなどの)ふりかえりフレームワークを使っている」「リファクタリングなどの技術的な改善をしている」の2つです。

たしかにこれらは改善活動ではあります。

しかし、やみくもに(本来のKPTの狙いを理解せずに)KPTをするだけでは十分な効果は得られません。コンセプトや効果を理解せずにフレームワークを利用するということは、「Reactよく分からないけど流行ってるから導入してみよう」と同じです。想像するまでもなく、その危うさは分かると思います。

またリファクタリングは改善活動ではありますが、リファクタリングやライブラリのアップデートしか改善活動と呼べる活動がない場合、つまりコードベースに対する改善活動しかない場合、注意が必要です。

この状況は、イテレーションの長さ・コミュニケーションパス・チーム構成・メンバー一人ひとりの役割等の『自分たちが従っているルールや条件』を完全に外部から与えられるものと認識していて、「ルールや条件も自分たちで変えていける余地がある」と捉えていない可能性があります。

特に開発プロセスは、過去に一度組み立てたまま現在も変わらず運用していてチームのスケールに適応できていなかったり、プロダクト立ち上げ直後に突貫工事でつくったルールであり本当はメンテナンスが必要な状態であったりと、アップデートする余地が残っているケースが珍しくありません。

ですがその問題をに目を向けず、ルールは偉い誰かが決めるものであり自分たちが考える必要はなく、ルールの中でコードを書くことだけが開発チームの仕事だと捉えていては、チームの最大パフォーマンスは発揮されませんしオーナーシップも生まれません。

自分たちのルールや働き方さえも自分たちで変え得るものだと捉えて改善していくことでオーナーシップが育ち、オーナーシップがあることで自然と自らの働き方をふりかえる習慣が生まれることは、なんとなく想像できるのではないでしょうか。

相互に作用するものなので、まずは「自分たちの今の開発プロセスに改善の余地はないか」をチーム全員で見直すことで、良い循環の1歩目を踏み出せます。

冒頭に挙げた例のように「リーダーシップやオーナーシップの有無」がシニアエンジニアとそうでないエンジニアの差(のひとつ)であるならば、この1歩目が、差を埋めるきっかけになるはずです。

おわりに

チームを眺めたときに感じ取れる危機感は他にも様々あります。このセンサーは経験で養えるものだと思うので、私よりも高感度な人もいればそうでない人もいるでしょうし、私自身も1年前より感度が良くなっていますし、来年は更に鋭くなることでしょう。

ですので焦らず、今の自分たちに感じ取れるものから向き合っていけば良いと思っています。

その中でも簡単に察知できる部分を、今回は書き出してみました。チームの危機を1つでも見つけるきっかけになれば幸いです。

上述のように「問題が起きていないから自分たちは大丈夫」「改善活動してるから自分たちは大丈夫」と判断してしまうことがかつて自分にもありましたが、短期的な問題の有無に気を取られ過ぎると、記事タイトルにしたような「いつまでもメンバーのキャリアが前進していない」といった中長期の課題となってはね返ってきます。

特に「キャリアが前進しているか」や「期待役割が変化しているか」は中〜長期の視点でメンバーと向き合わないと気付けない課題なので、目先のタスクに集中したいサバイバルフェーズでは気付きにくいです。

理想的なことを言えば、中長期の課題が見つかる前に日々の改善を重ね、変化に慣れ、ひいては変化を歓迎し変化し続ける自律的なチームになることが、タイトルへの回答になります。

といっても簡単ではないので(本当に簡単ではないので)、お互い地道に一歩ずつやっていきましょう。