チーム・ジャーニーを読んでみた (前半)(Advent Calendar Day 15)

はじめに

こんにちは、D2Cデータサイエンティストの小林です。
本日は、D2Cのデータサイエンティスト（MLエンジニア）をやっている須田さんとチーム・ジャーニーを読んでみた感想を記事にいたしました。

問題と解決編の要約

• 第1話　グループでしかないチーム

  • 課題: システム立ち上げメンバーの1人が権力を持ってタスクをメンバーに振る、メンバーは事を荒立てないように発言を控えて言われた事をただやる、いわゆるチームになっていない状態になっている。
  • 解決: チームになるための4条件で違いを知り、目線を合わせる必要がある。

• 第2話　一人ひとりに向き合う

  • 課題: ただレールを走り続ける機関車のようなチームになっている。つまり、目的がなくただ目の前のタスクをこなすだけの状態になっている。
  • 解決: 一度立ち止まり、チームで自分達のWhy/What/Howを問い直す必要がある。チームの状況が変わったら振り返りと向き直りで定期的に問い直すことが大事になる。

• 第3話　少しずつチームになる

  • 課題: チームメンバーや上長の方針でいきなりスクラムをやることになる。つまり、いきなり理想のチームを作ろうとしている状態になっている。
  • 解決: チームの成長のための段階を設計する必要がある。どういう段階を踏めば理想の状態になれるのかチームジャーニー(成長戦略)を考え、そのために何をするべきか見立てる。定期的な振り返り・向き直りで段階の見直し、再設計を行うこともある。
    ★タックマンモデルと成功循環モデルを組み合わせて進めると良い。

• 第4話　チームのファーストを変える

  • 課題: チームで一体感が生まれてくるとチーム全体に情報を行き渡らせ、全員で意思決定をすることが増える(チームファーストの状態)。しかし、これはただのチームごっこに陥っていることが多く、仲が良いが外から見たらパフォーマンスが出ていない状態になっている。
  • 解決: チームのファーストをプロダクトファーストに切り替えることでプロダクト(成果)にフォーカスした意思決定ができるようになってくる。
    ★チームファースト時だけでなく状況によって第一主義を切り替えられると機能性が高いチームと言える。

• 第5話　チームをアップデートする

  • 課題: 振り返りの時間に問題が何も出てこず、チームがマンネリ化してしまい状況としてはチーム立ち上げ時に逆戻りしている。
  • 解決: 現状のチームとDIFF(差分)を把握しチームのジャーニー(段階)を切り替える。ここで再度、一人一人が次にどこへ向かうのかを理解している状態を作ることが大事になってくる。

• 第6話　分散チームへの適応

  • 課題: 新しくチームにメンバーが加わり、多種多様な働き方でチーム開発を行うことになり、働く時間や場所が違うことでスクラムイベントが成り立たなくなってしまった。また、新しいアーキテクチャを開発する際に新規メンバーの既存機能のキャッチアップが問題となっている。
  • 解決: 時間、経験、場所の分断で発生する6つの問題があることをまず理解した上で、チームにある分断を把握することが大事になる。また、それぞれの分断に適したフォーメーションを組むことでチーム内に発生している分断に対処する。プロダクト開発は様々な不確定要素を呼び込むものなので、チームでその状況に合わせてフォーメーションを変更できる体制になっていると良い。

• 第7話　チームの共通理解を深める

  • 課題: チーム内で共通の認識や共通の方向性を共有していないことで開発が思うように進まなくなってしまっている。
  • 解決: チームでプロダクトの理解を合わせる必要がある。共通の理解を得る手段として仮説キャンバスを用いる。また、プロダクトチームには無数の分断が発生する。この分断の発生を抑えるためにチームの透明性を高めることが大事。透明性を高めるためには「見える化」「場づくり」「一緒にやる」この3つの原則を用いる。

• 第8話　一人の人間のようなチーム

  • 課題: チームメンバーが何のために何を作っているのかを把握できていない。その影響でたくさん機能開発を行っても機能が足りないと言われるが、何を作ればいいのかチームでわかっていない。
  • 解決: 出発のための3つの問いに再度向き合う。この時、チームビルドが進んだ段階では、「チームとしてのWhy」「チームとしてのHow」「個人としてのWhy」の順番で考える。仮説検証とアジャイル開発を組み合わせ一人の人間のようなチームに近づけていくことが大になる。仮説立案から開発までの速度を上げていくことが重要になる。

読んでみた感想

分析基盤構築チームリーダー(須田)

• 分析基盤構築チームの過去の状況や今ある課題とリンクする場面が多くありました。特に、ただレールを走り続ける機関車のようなチームだったり、間違った民主主義の問題の場面で分析基盤構築チームと全く同じ現象だと感じました。
  解決するべく、書籍の現場と同じようにゴールデンサークルを実施したのですが、書籍のようにうまくはいきませんでした。この時に学んだことは、チーム内だけで決めてはいけないということです。POやステークホルダーなどと一緒に周りの期待とチームの意義が合致するように決めていかなければいけなかったのですが、当時はチーム内で完結して決めてしまい、その後の周りの期待とのすり合わせがうまくいきませんでした。後日上長含めて再定義&再出発しています。
  このように、書籍のストーリーと実際のチームの状況を客観的に行き来し、良いと思ったことは現実世界で試しながら読み進めました。
  そして、読み進めていくうちに「ふりかえりや向き直り」を大事にしていきたいと思いました。
  常に振り返りと向き直りを繰り返し、チームを理想の状態に持っていけるようにしていきたい、そういう環境を作ることが今チームには必要で、私のやるべきことだと気付かされました。私は、マネジメントの経験が浅いため機能するチームになるための1つの例をこの本から学ぶことができてよかったです。

機械学習チームリーダー(小林)

• 機械学習チームでは、スクラム開発導入後、開発がスムーズに進んでおり、問題もなく開発が進んでいるように思えていた時期がありました。しかし、ある時にメンバーからスクラムにのせるほどではないがいづれやっておいた方が良いタスクがたくさんあることを指摘されました。スクラムでは開発期限の関係やビジネス的に優先度の高いものが優先されており、やったほうがいいけど今すぐというわけではないタスクを後回しにしていました。その結果、そのようなタスクが山積みとなり運用や開発環境に影響を及ぼすことになってしまいました。そこで、機械学習チームでは、現状どのようなタスクがあるのか整理を行い、チームの現状を振り返り、スクラムはそのまま継続し、新たにカンバン開発を導入しました。その結果、山積みされていたタスクをスクラムの隙間時間や気晴らしの作業として消化でき、よりスムーズに開発が行えるようになっていきました。
  書籍にもあるとおり、チームの現状を把握しその状態にあった体制や開発手法を選択することが大事なんだと改めて感じさせられました。また、こちらの書籍はリーダーだけでなく、チームメンバー全員が1度は読むべきだと感じました。

最後に

今回はチーム・ジャーニーの前半を読んでみた感想をまとめました。
チームの立ち上げや現状のチームが何かしらの問題に直面していると感じている方はぜひ一度読んでいただけるとと思います。
後半についても、まとめる予定ですのでご興味があればご覧ください。

最後までお読みいただきありがとうございました。

採用情報

• D2Cグループ採用サイト

https://recruit.d2c.co.jp/

• D2C問い合わせフォーム

https://www.d2c.co.jp/inquiryform/