エウレカで開発チームをイチからチーム・ビルディングしてみた話 その1

皆さん、こんにちは！ CTO室でリーダをしています。梶原です！ 私は主に開発チームのプロセス改善や開発チームのチーム・ビルディングに取り組んでいます。
このエントリーでは、エウレカでの開発チームをチーム・ビルディングした経験について書きたいと思います。エモさ満点の話ですが、何か既存のやり方を変えて、新しい事を始めたい時に参考にして下さい。

TL;DR

• 何か既存のやり方を変えて、新しいことを始める時に参考にして下さい。
• 問題点を見える化してから、課題を解決するアプローチだとすんなり受け入れてくれる。
• 「HOW」にこだわりすぎない、本質はチームの中の対話を増やすこと

きっかけ

もっと良いユーザ体験を届けたい。 より早くユーザに価値を届けたい想い

新しく任命されたチーム・リーダーから相談を受けました。
それは、「経験が無いのでどのように開発チームをチーム・ビルディングすれば良いかが分からない。」という話だったので、支援（半ば強引に？ｗ）を申し出させてもらい活動を開始しました。

まずは開発チームの状況をヒアリングする事から始めました。

問題点の見える化を行う

チームの状況をヒアリングしたところ、「決定的にここが悪い。」といった状態ではなかったものの。「もっと上手くやれるハズだけど、どうやったら良いか分からない。」という状態でしたので、チームリーダと二人で開発チームの振返りを「Good」「More」を書き出してみました。

MOREをグルーピングし、それぞれの課題が解消すると、改善されるビジネス課題を定義していく。

グルーピングをしてみる。以下の３つにフォーカスされました。

• Devチームがマルチファンクション化できていない
• 振返りの習慣がない
• プロダクトオーナーが不在

特にプロダクトオーナーが不在の問題が大きい事が分かります。

「プロダクトオーナーが不在」について課題と課題がループしている所を探します。その中からひとつでも改善する事ができたら、状況がよくなる事があります。

ビジネスオーナーに対しては、改善されるビジネス課題とセットでトレード・オフになるものを提示すると判断を行う上での支援になります。

例えば、このような感じです。

改善されるビジネス課題とは

• 常にプライオリティがメンテナンスされて、ビジネス価値を届けるために何をしないと行けないかチームをリードできるようになる。
• ユーザエクスペリエンスについて、責任を持つ人をアサインすることで、プロダクトの価値を高める。
• チームから、案件、プロジェクトについての質問を受けて、ユーザストーリーの背後まで説明することで、必要な機能を開発できるようになる。

この課題を解消させる提案

• 明確にこのロールをアサインする。 必要に応じて人員の手配を行う。

トレードオフ

• 新しくプロダクトオーナーにアサインするエンジニアの代わりが必要

→ 当初は兼任しつつ、徐々にペアワークや、ペアプロ等でスキル移転を行う。

スクラム開発のはじまり

まず始めたことは、開発チームのプロセスに振返り会を初めて定着させる事でした。
振返り会とは、チームのプロセスについてフォーカスして振り返ることで、チームの課題を現状分析して、トライを設定して課題の改善を行います。
出てきたトライに対して、スクラムやアジャイルのプラクティスを使って、チーム・ビルディングをしていきました。

チームの中で人のSPOF（単一障害点）を避けたい。

背景として、サーバサイドエンジニアは１人しかおらず障害などが発生した場合に、その調査対応などできる人が１人しかいない状態でした。
まずは、スキルマップを作成してチームとして必要なスキルを定義し、それぞれチームメンバーをプロットして可視化を行いました。
ある特定領域のスキルに対して１人しかできない状態を避けるべく、ペアワークなどを取り入れて徐々にスキル移転とノウハウ共有を行いました。

リリース日がズレたり、プランニングができない問題

ストーリー・ポイントでタスクを見積もる事。 チームのベロシティを取得して、実績を元にこれからリリースするフィーチャーのプランニングを行えるようにしました。
詳細は今年のデベロッパー・サミット2017で登壇しました時にまとめています。

正しくプロダクトを作り、リリースプランニングするためのプロダクトオーナーの役割とは from Narichika Kajihara

などなど。 徐々にチームにスクラム開発のメトリクスをインストールしていきました。
「HOW」に拘らず、本質的なチーム内の対話にフォーカスして行くことで、開発チーム内のコンディションは大きく改善していくことができました。

チームがどう変わったのか

振返りの会話の中や朝会での会話の中でも「本質的にユーザが求めているのは、こういう事だよね？」とか、「もっとプロダクトを良くするためにどうすれば良いのか？」などの会話が目に見えて増えてきました。
APIの実装はこーだけど、iOS側はこういうデータが欲しいと思っているよね？と、担当を超えてお互いの実装について踏み込んだ会話ができるようになり、それぞれがそれぞれの立場を超えて、よりよい成果を出すために自ら改善していく姿を見る事ができるようになっています。


自己組織化の第一歩を踏み出した感じです。


また、エウレカ全体的にスクラムがどのように定着していった事に関しては、次回のエントリーで書きたいと思います。