More than 5 years have passed since last update.

強いチームの作り方

Posted at 2016-06-19

結構前のVolだが、WEB+DB PRESS Vol83を再度読み直したのでまとめてみた。

※画像は技評の公式より
http://gihyo.jp/magazine/wdpress/archive/2014/vol83

なぜ強いチームが必要なのか

なぜチームで働くことが必要なのか？

チームで働く一番の理由は、一人では完成できない仕事をするため。
能力は人それぞれ違うので、自分の能力の範囲をカバーするためにチームで開発を行う。

強いチームの評価基準

近年のビジネススピードの変化の中では、状況に対応し、新たに必要とされる能力をいかに短時間で身に付けることができるかが、競争力の源泉となりつつある。そのため、チームに求められる能力も、ある固定化されたルールにおける最適化よりも、状況を判断し、必要な能力を獲得できることに変わりつつある。
ある特定の状況下で勝てるチームが強いという時期は終わり、変化に対応しつつ、生き残れるための能力を身に付けることを自己組織的に行えることが強さの意味となってきた。

強いチームの特徴

結果を出し続けられる
変化に対応できる
タックマンモデルでは、チームの状況に変化が生じた際は、形成の段階を繰り返すことが説かれている。必要に応じてチーム自身の再形成を行えるというのが、最近のチームの強さ。
成長を維持できる
メンバーが完全に固定したままだと、メンバーは全員歳をとってしまう。メンバーは安定させつつ、新たなメンバーを育成する能力が、強いチームには必要。

強いチームと弱いチームで何が違うのか？

状況を把握する能力
今やっている方策、プロセスが役に立っているか、ベストなのかを都度判断しなければならない。あるやり方に慣れれば慣れるほど、そのやり方が想定していない状況を把握するのが難しくなる。そのため、チームの中で色々な見方を持てるメンバーが揃っているというのが非常に重要になってくる。
対応策を検討する能力
状況を把握して、問題があれば対応策が必要になってくる。対応策を見つけられる範囲、対応策を検討できる広い視野が必要になってくる。
必要な能力を身に付ける能力
対応策が現在のメンバーのスキルだけで実行できるとは限らない。必要に応じてスキルを身に付ける能力が必要。技術やプロセスの変化に追いつきながら保てる仕組みを用意しなければならない。個人として学ぶ能力はもちろんのこと、チーム・組織として学ぶ能力を身に付けることが必要。
繰り返す能力
1~3の能力の強化を繰り返していかなければならない。

強いチームの構造

多様性がもたらす強さ

強いチームを育てるには、多様性が大きな役割を果たす。チームのメンバーがさまざまな能力、視点、考え方を持ち、共通の目標に向かって努力できることが強いチームにつながる。
チームにおける多様性とは、メンバーが多様(年齢、性別、経験、国籍、嗜好・・)ということではなく、さまざまな意見を柔軟に受け入れられる度合いのこと。
多様性を受け入れず、均一なプロセスを推し進めようとすると、プロセスに対してフィードバックを行うのが難しくなる。プロジェクトで直面した問題に対して、プロセス改善のフィードバックを行おうとしても、ネガティブな意見や競合他社、顧客、サプライヤーの悪口ばかり言うようになる。プロセスがうまくいっていないことがわかりはじめると、プロセスのせいではなく使ったツールや方法を責めるようになる。強いチームどころか、どんどん弱くなってしまう。

多様性を育むには

多様性を育むには、多様な意見を受け入れられる度合を増やさなければならない。多様な意見を受け入れられるようになるには、チームの目標、ビジョン、価値観の合意が必要。

チームの責任

チームが負っている責任は、説明責任(発生した事実を説明する)、改善責任(同じような状況を再び起こさないように行動を変える)の2つがある。この2つを果たさず賠償責任(発生させた障害に対する賠償)、引責辞任など懲罰に言及すると、さらにプロジェクトを炎上させることになる。

信頼で結ばれた共同体は衝突を恐れない

多様性を受け入れつつ仕事をこなすチームにとってまず重要なのはメンバー間の信頼関係。信頼で大事なのは「相手にとって不快かもしれないフィードバックをしても、相手は個人攻撃と受け取らないと確信がある」「自分にとって不快なフィードバックも、それは改善のためであって悪意はないと確信できる」こと。チームで仕事していると意見の衝突はたびたび起こるが、そういった中でより良い案を選択していけるのは強いチームの特徴の一つである。

自分たちが従うルールは自分たちで決める

チームが成熟してくると、チームのパフォーマンスを上げるのに、外部のルールが障害になることがある。また、プロジェクトで問題が起こった場合などは、そういったルールが問題を悪化させることもある。そのため、ルールが有害であるならばルールを廃止する必要がある。ルールを決めるのは外部であることが多いが、自らルールを決めて、守り、状況を改善してみせることで、だんだんルールを決めて実施できるようになる。

チームの育成

強いチームであるためには、各チームメンバーそれぞれが能力を身に付けることが必要。全員が全ての能力を身に付ける必要はないが、一人しか持っていない能力にチームの成果が依存するのもよくない。チームメンバーの育成もチームの力を借りて行う。

チームのマネジメント

チームが多様性を活かして自律的に動けるようになってくると、マネージャの役割も変わってくる。マネージャが判断を行ってしまうと、チームの多様性が持つ強さを失わせる可能性があるので、極力判断はチームに任せる。ただ、いきなり全ての判断をチームに任せるわけにはいかないので、最初のうちはチームに権限委譲すること、マネージャが権限を持つことを予め決めておき、少しずつチームに権限委譲していくのが望ましい。

チームメンバーの入れ替え

チームメンバーは安定している方がチームのパフォーマンスは向上する。ただ、チームメンバーを固定したままだと、チーム内のことばかり気にして外部を気にしなくなるサイロ化が起き、チーム内とチーム外での環境のギャップが大きくなり、埋めにくくなる。このような状況を避けるため、チームメンバーは時々少人数入れ替わるのが良い。10人くらいのチームであれば、半年から一年に2名ずつくらいが良さそう。

強いチームのコミュニケーションスタイル

チームのコミュニケーションはなぜ必要か

どんなに優秀なメンバーで形成されたチームでも、コミュニケーションは必須である。チーム全員が仕事のゴールを共有し、ゴールに向けた進捗、課題を把握し、コミュニケーションを取りながら早めのアクションを取っていくことが成果の達成のために必要となってくる。

コミュニケーションの基本モデル

アート・オブ・プロジェクトマネジメントでは、コミュニケーションの基本モデルとして以下の5段階を定義している。

送信済み

　↓
受信済み

　↓
理解

　↓
合意

　↓
有益な行動への変換

コミュニケーションは理解の段階に至った時点で初めて成立すると言われている。コミュニケーション元の人は、情報を発信したからといって相手に伝わっているとは限らない、ということを理解しておくと後々の問題を避けられる。

チームのコミュニケーションの方法

同期型コミュニケーション

同じ時間を共有しながら行うコミュニケーション。よくあるのは会議等。メリットとしては、決められた時間の中で集中して情報共有をしたり、問題を解決したり、意思決定を行えることが挙げられる。また、緊急度が高いものを決定したりする場合もこのスタイルが適している。デメリットとしては、参加者の時間を消費すること、現在行っている作業を中断して参加することにより、参加者の作業効率が低下することが挙げられる。

非同期型コミュニケーション

それぞれが異なる時間軸の中で行うコミュニケーション。よくあるのはメール、チャット等。メリットとしては、自分でいつコミュニケーションを行うかを制御できることが挙げられる(もちろん期限を定めないといけないので、一定のタイムボックスの中でコミュニケーションを行うことになる)。デメリットとしては、コミュニケーション相手が増えれば増えるほどコミュニケーション完了までに時間を要すること、意図したことが伝わったかどうかを確認することが難しいことが挙げられる。

両者の使い分け

どちらかを使うのではなく、目的に応じて最大の効果が得られるように適切にコミュニケーション方法を選択すること、それらのバランスが必要になる。物理的にタイムゾーンが異なるメンバー(海外にいるメンバー等)と仕事をしていると、そもそも同期型のコミュニケーションを行える時間が限定的になるため、コミュニケーション方法の選択肢が制限されることになる。
なお、以下はそれぞれの使い分け例。

同期型コミュニケーションが望ましい例

・毎日の短い朝会
・トラブル発生時の対策会議など緊急時
・アプリケーションの仕様決めや優先順位づけ
・アイデア出し・ブレーンストーミング
・個人の行動に対するフィードバック
・チームの立ち上げ時
・複数の設計案の検討
・ペア作業

非同期型コミュニケーションが望ましい例

・単なる通知や報告
・会議の日程の調整
・ドキュメントやコードの細部の確認
・詳細で具体的な内容に関する質問とその回答
・小さな課題の対応方針の検討
・マイナーなバグの報告
・飲み会の連絡
・製品へのフィードバックの取得

さまざまなコミュニケーション方法の使用上の注意

会議

会議の目的、ゴール、出席希望者を明らかにする
会議の冒頭でその会議におけるゴールを確認する
会議の終わりには、決定事項と宿題を再確認する
会議は定期的に必要かどうかの判断をする
時間通りに開始する
長時間の会議を設定しない
会議の時間は延長しない
定時のあとに会議を設定しない
会議に関係ありそうなだからという理由で大量の人を呼ばない
職場の職位を会議に持ち込まない

メール

宛先を考える
適切なタイトルをつける、メールの冒頭に結論を書く
使いどころを考える

チャット

情報量をコントロールする
チーム全員で使う

ドキュメント共有

ドキュメントの鮮度を明確化する
ドキュメントへのアクセシビリティを高める
どこで何を共有するか合意する

チームの外とのコミュニケーション

コンテキストが共有されていないことを意識する
チーム編成が正しいかを考える
チームのルールを可視化する

強いチームの評価とフィードバック

何のために評価が必要なのか？

チームがより高いパフォーマンスを発揮し、仕事を完遂するために、今の自分たちのチームがどのような状態なのかを定期的に検査、評価し、もっとよくできるようにするためにはどうしたらよいかを考えて、改善していくことが必要。定期的にチームや個人のパフォーマンスを評価し、フィードバックしていく。

効果的な評価の方法

評価の基本原則
公平、公正であること。例えば、あらかじめ評価の観点や基準が決まっていること。
公平性に欠けると、不満が蓄積しチームのパフォーマンス向上の妨げになる。
評価の際に客観性を持たせるためには、定性的な評価だけでなく、定量的な評価も必要。ただし、書いたコードの行数、作った機能の数、こなしたタスクの数、バグや障害の件数、といったことは評価に直結させないほうが無難(これらは、評価を得たいがために各人でいかようにもできるため)。
評価の頻度
短い間隔で繰り返し行うのが理想。一般的な会社では年に1、2回程度の個人評価があるがこれは十分ではない。評価を個人のパフォーマンスを高めるための改善活動と考えると、1年周期は長すぎて改善の効果をすぐに成果に結びつけることができない。
評価のフィードバック
評価をしたら、被評価者にフィードバックが必要。フィードバックして次のアクションへ結びつけるため、出来るだけ具体的にフィードバックを行う。