新しいチームでは、改善より先に信頼と現場理解を得る
チームを改善したいリーダーやマネージャーにとって、まったく関係性のない新しいチームへ入った直後は、難易度がいちばん高い局面だと考えています。信頼もなく、そのチーム特有の事情もわかっていないからです。本稿では、リーダーやマネージャーが関係性の薄いチームに入った想定で、その進め方を紹介します。すでに関係があるチームなら、同じ順序はより行いやすいはずです。
他のチームで効果があった実績のあるプラクティスだとしても、入った直後から「やり方を変えましょう」と伝えるのはリスクがあります。そのチームの背景を知らないままでは、今の事情に合わず届きません。リーダーやマネージャーであっても、最初から改善する側に立つ必要はありません。
私は2025年6月に弥生株式会社へ入社し、スクラムチームへ加わりました。最初の約2カ月は、1人のエンジニアとしてチケットを担当することを優先しました。開発で使う技術を理解し、開発のつらさに共感し、分報で自分の仕事ぶりを公開しました。分報は、自分の状況を随時公開するプラクティスで、詳細は後述します。仕事を経験するなかで改善できそうな点も見えてきましたが、チームの事情を理解する前に提案することはしませんでした。この期間に信頼を得られたことが、その後の提案を受け入れてもらいやすい土壌になったと考えています。
エンジニアの仕事を続けるなかで、朝会では担当チケットを共有していても「今日どこまで進めるか」がわかりにくく、チケットを進める順序や相談のタイミングも個人に委ねられていることも見えてきました。その後、リリースが大幅に遅れる見込みをチーム全員が認識した段階で、ふりかえりの場で、仕事の途中経過を見えるようにする施策を私から提案しました。信頼と現場理解がある状態で、チームが解決したい問題と結びつけて提案できたことが、本稿で紹介する3つのプラクティスをチームで試すことにつながったと考えています。
この経験から、新しいチームへ知見を持ち込むときは、内容だけでなく、届ける順序も重要だと考えています。まず同じ仕事を経験し、技術とつらさを理解したうえで信頼を得ます。そのうえで、チームが今まさに解決したい問題とプラクティスを結びつけると、提案は届きやすくなります。
途中経過が見えないと、相談や助言は起きにくい
到達点と進め方が見えないことは、相談や助言が起きにくい理由でもあります。周囲が把握したい途中経過は、次のようなものです。
- 誰が、今日の作業でどこまでを目指しているのか
- どこで悩んでいて、どこまで進んでいるのか
- どういう判断で、その進め方を選んだのか
これらが見えないと、助言したくてもタイミングを逃しやすくなります。朝会で担当チケットはわかっても、今日どこまで進めるつもりかがわからなければ、想定より遅い進め方に気づいても、朝の時点で確認しにくくなります。進め方が頭の中だけだと、成果物を作ったあとのレビューで初めて問題がわかり、手戻りが増えます。「早く相談して」と求めるだけでは、どの時点で何を相談すべきかは伝わりません。日中の迷いが見えなければ、知見を持つメンバーも声をかけられません。
そこで、目標、進め方、途中の迷いを共有し、相談や助言が起きる材料を作ります。これが本稿でいう透明化です。
