ブログ

ryuzeeによるブログ記事。不定期更新

直近開催のScrum Alliance認定スクラムマスター研修のご案内

チームパフォーマンスモデルとは?

みなさんこんにちは。@ryuzeeです。

人が集まっただけでは機能するチームにならない、というのはみなさんご存知のとおりです。 そしてチームの形成過程をあわらすモデルの1つとして有名なものに「タックマンモデル」があります(こちらを参照)。

今日はもう1つ別のモデルとしてDrexlerとSibbetが提唱している「チームパフォーマンスモデル」を紹介します。

タックマンモデルでは、チームの形成過程は形成期・混乱期・統一期・機能期・解散期の5段階(初期は4段階)で構成されていましたが、このチームパフォーマンスモデルでは、以下の7段階で構成されます。

  • オリエンテーション
  • 信頼の醸成
  • ゴールの明確化
  • コミットメント
  • 実行
  • ハイパフォーマンス
  • リニューアル

これらのステージは前半上から下に向います(形成段階)が、この段階では、徐々に制約を感じるようになっていきます。一方で後半に下から上にあがっていく(持続段階)につれて自由を感じるようになります。 それぞれのステージについて見ていきましょう。

オリエンテーション

この段階では、チームがなぜそこに集められたのか、どんなことが期待されているのかを明らかにします。 なぜ集められたのかが分からなければ、チームは不安になってしまい参加意識を欠くことになります。 アジャイル開発でよく使われるインセプションデッキでも「われわれはなぜここにいるのか?」という項目を最初に明らかにしています。 この段階でメンバーが恐怖感をもっている場合は、先に進む前に十分な説明が必要になります。

信頼の醸成

メンバーはお互いの仕事に依存関係を持つことになるため、お互いの理解が必要です。 そこで「あなたは誰?」という質問にもあるように、それぞれの強み(や弱み)、それぞれの考え方、お互いに対する期待値などを明らかにします。 ここでメンバーが警戒心を持っていたり、見せかけの振る舞いをしているような場合は、改善が必要になります。

ゴールの明確化

一番最初のステージでなぜ集められたのかは分かりましたが、ここではもう一段踏み込んで、ゴールや成果物を合意するとともに、実際に自分たちが何をやるのか明確化します。 ゴールを達成するための選択肢が複数あるのであれば、それぞれについて議論を行います。 議論において人の意見に文句ばかり言う人が出る場合もありますし、そもそもゴールに関心を持たない人がいる場合もあります。 その場合は前のフェーズでの信頼の醸成が不足していることを指します。

コミットメント

次に、どうやってやるかを決定します。ここでは選択肢の決定、個人の役割や責務の決定、必要なサポートの手配やリソースの割り当てなどを行います。 ここでも個人の役割や責務を持ちたがらないような人が出てくる可能性もあります。 また意思決定の責任を取りたがらず単に人の意見に従う人がでてくることもあります。 その場合は手前のステージに戻ります。

実行

コミットメントが終われば実行フェーズに入ります。具体的に誰が何をいつどこで行うのか、スケジュールや戦略やプロセスを決定して進めていきます。 実行段階で混乱が起こったり衝突が起こる場合は、戦略やプロセスの合意が不足していることを指します。 またプロセスが不明瞭だと規律に従わない行動が増える可能性もあります。

ハイパフォーマンス

うまく機能するチームになっている段階。チームに与えられた時間の中でどれだけ多くをこのステージで過ごすかが成果の最大化への鍵になります。 信頼関係と明確なゴールやプロセスをもとにチームが自律的に物事を進められる段階になっているので、必ずしも多くの管理は必要ありません。 一方でチームがフロー状態に入るので、たくさんの成果を出したくて負荷があがることは考えられます。

リニューアル

時間がたったり状況が変化したりすることでチームが置かれた状況は変化します。 このとき、このまま続けるかどうかを判断し、状況によっては、また最初のステージに立ち戻って自分たちがなぜそこにいるのかを確認しないといけないこともあります。 もしくは、ハイパフォーマンスなチームを維持することは大事なことではあるものの、チームを解散しないといけなくなることもあります。 このタイミングで、自分たちが達成できたことやできなかったこと、もっとうまくできそうなこと等を洗い出して次回に反映するようにします。

雑多な所感

このモデルや、以前紹介したタックマンモデルを踏まえて考えておくと良いと思う点を列挙しておきます。

  • なぜ自分がそこにいるのかを明らかにすることは極めて重要
  • いきなり集められてお互いのことを信頼しろ、とか明日から高いパフォーマンスを出せと言われても無理
  • 当たり前の話ですが、プロジェクトをどう立ち上げるのか、チームをどう立ち上げるのかという初期の活動を軽視してしまうと後工程で大きなツケを払うことになる
  • 警戒・懐疑主義・無関心・依存といったあたりは個人の資質によるところも大きい。一方で「恐怖」によってそうせざるを得なくなっている場合もあるので、チームの外からどんな力が働いているかを明らかにする必要がある
  • インセプションデッキのようなテンプレートを用意しておくと、こういうプロセスの流れに乗りやすい。自分たち用のフレームワークを作っておいてもよいかもしれない
アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください(初回相談無料)
前の記事 デブサミ2016夏でDevOpsお悩み相談室というセッションをやりました
次の記事 【資料公開】カイゼンの基本

プロダクト開発で、こんな課題を感じていませんか?

  • 何を作るべきか、順位の決め方が定まらない
  • プロダクトの方向性をチームで共有できていない
  • 開発組織の体制や役割がうまく機能していない
  • 開発プロセスが形骸化し、目的を見失っている
  • アジャイルを導入したが、組織に定着しない

プロダクトマネジメント、組織構造、開発プロセスの課題について、組織全体の視点から支援します。

お問い合わせ(初回相談無料)

契約を前提にした相談でなくて構いません。相談に際して事前の整理や準備は不要です。

Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方
ダイナミックリチーミング 第2版
Tidy First?
脳に収まるコードの書き方
プロダクトマネージャーのしごと 第2版
エンジニアリングマネージャーのしごと
チームトポロジー
スクラム実践者が知るべき97のこと
プロダクトマネジメント
SCRUM BOOT CAMP THE BOOK
みんなでアジャイル
レガシーコードからの脱却
Effective DevOps
変革の軌跡
ジョイ・インク
アジャイルコーチの道具箱
カンバン仕事術
Software in 30 Days
How to Change the World