[note下書き供養]ジュニアチームが独り立ちした話

はじめに

この前久しぶりにnoteを開いてみたら、たくさんの下書きが残っていることに気づいた。下書きをあさっていると、こんなタイトルの記事を見つけた

『チームから上司を追い出してみた結果』

かなりやべえ記事書いてるな、昔の自分...って思ったんですが、中身見てみたら内容はそれなりに普通でした

この記事は1年前に書き残してたやつで、エンジニアになって1年半が経とうとしていた頃に書きかけてた記事です。多分年数を重ねれば重ねるほど、こういう視点のアウトプットは出せなくなる気がするので、供養も兼ねてここで吐き出させてもらいます

下書きはかなり殴り書きだったのでちょいちょい書き足してます

こんなチームだった

チームはこんなメンバー構成だった

• PO兼技術サポート：上司

• 開発メンバー：4名。全員未経験〜3年目くらい

開発メンバーたちはこういう良さ・強みを持っていた

• メンバー同士、わからないことをわからないと言える

• チームにとって難しい問題でも、明るい雰囲気で協力しながら立ち向かえる

• 成長につながる、前向きなふりかえりができる

• 課題を解決するために、皆が自発的に考えて行動できる

でも、こういったチーム構成だったことで、下記のような課題も抱えていた

• ふりかえりが反省会のようになりがちだった

• メンバーが「自分はスキルが無いし努力も足りない」と強く思ってしまうことで、皆の主体性が損なわれているように感じた

• 開発メンバーでの話し合い時点では「チームとしての答えを出す話し合い」ができていたのに、チーム全体での相談会になると途端に「答え合わせ」になっていた

• 開発メンバーが主体的に要件定義に携わったり・ステークホルダーとのコミュニケーションを取りに行くようになった結果、開発メンバーとPOの連携がうまくいかなくなった

「開発メンバーだけで仕事をしてみたい」という気持ちが日に日に強くなっていた

思い切って、自分たち(開発メンバー)だけでやってみることにした

しかし、自分たちの力だけでPJを回すには力不足だった。実際こんな感じだった

• 今までは、進捗管理を自分たちでうまく出来ていなかった(不定期に上司のサポートを受けていた)

• Findy Team+を利用していてチームの開発生産性を可視化できる環境だったのに、データチェックや分析は上司任せになっていた

• 要件定義(ユーザーストーリー作成)を自分たちだけでやったことがなかった

その一方で、チームは1ヶ月半後の新機能リリースが迫っている状況だった

それでも私たちは自分たちの力でリリースまで頑張ってみたかった。幸い上司の理解も得ることができたので、スケジュール通りにリリースするためにこういう打ち手(というほどでも無いかもだけど)を立てて臨んだ

• 進捗管理を自分たちでやる(朝会でタスクの進行状況・バーンダウンチャートを確認するステップを設けて、更新漏れを予防)

• スプリントごとに上司に進捗状況・抱えている課題を共有。スケジュールに支障が出そうな懸念点の洗い出し、サポートが欲しい事項についての頭出しなどをここで行う

• チームで解決できる課題とサポートが必要な課題を切り分け、必要なサポートを求める

結果、部分的にサポートをもらいつつスケジュール通りにリリースすることができた

実際やってみて

1ヶ月半で、チームにこのような変化があった

• メンバーの主体性が増し 「このプロダクトを届けたい。良いものを作りたい」という気持ちが非常に強くなった

• バーンダウンでチャートの進捗把握を毎日行うことが習慣化された

• スケジュール通りに開発できそうかの判断をチーム自身が行えるようになった(今までは上司に頼っていた)

• ふりかえりでは、次の打ち手がどんどん出るようになった 。「なぜうまくできなかったのか」「こうするともっとよくなりそう」という議論がものすごく活発になった

• FindyTeams+のメトリクスを毎日の朝会で確認し、チームのヘルスチェックを行えるようになった

感じたこと

自分たちのチームは、全体的に当事者意識が高く、意欲も備わっているチームだと思っていたが、実際こういった課題を抱えていたように思う

• 開発工程全てを主導していたわけではなかったので、開発工程で見渡せる範囲が狭かった(特に、要件定義の領域は上司が主導でやっていた)

• 詳細設計〜実装あたりが一番解像度が高く、そこから上流に行けば行くほど解像度が低かったので、場当たり的な、若しくは的外れな解決策を導き出してしまうことがあった

• 開発スケジュールはPOである上司がかなり丁寧に管理してくれており、ベロシティの計測などは自分たちでやりつつも「スケジュール通りか検証する。スケジュールに間に合わせる」という意識が希薄だった

• できない(若しくは、出来ていないと指摘された)領域では受け身になってしまうことが多かった(上司や先輩はサポートを求めたら1~10まで教えてくれたり、実装してくれたりすることがあり、それに流されていた)

自分たちで全ての課題に取り組みリリースまで持っていくという経験ができた結果、開発や進捗管理に関してかなり視野が広がったと思う

また、ステークホルダーと直接やりとりをして、プロダクトのあり方を一緒に考えながらユーザーストーリーを作成するという経験ができたことで、「(与えられた要件に対し)どう作るのか」しか考えられていなかった状態から、「どんなものを作ると良いのか」という段階から考えて動けるようになった

そういった視野の広がり・気づきと本来持っていた当事者意識の高さが組み合わさって、チームがものすごい成長したなあと感じている。

(しかし、チームはこの2ヶ月後に解散することとなる。1年経った今思い返すと本当に無念...)

最後に：気をつけないといけないこと

チームとしては様々な学び・気づきを得られた1ヶ月半だったが、私たちのような技術的に未熟なチームが自走を試みるのは、上司から見るとものすごい胃が痛いことだったと思う

「皆が望み・合意した時期に望まれた価値をデリバリーする」という本来の目的を損なわないためには、仕事を任せてもらえる側として絶対にやらなきゃいけないことがあるなあと感じた

例えばこんなこと

• 進捗管理の手法・アラートのあげ方・サポートの求め方等について、予め上長と目線合わせしておく

• 定量的に計測可能な方法で進捗管理する

• 必要な時に迅速にサポートを受けられるよう、上長やサポートを求めたい人に対して日頃からPJTの進行状況や技術的課題などについて情報共有を行う