みなさんは、チーム作りについてどのように考えていますか？
ひとそれぞれ持っている価値観は違っていて、それをまとめていくって相当難しいですよね。
チーム作りについて書かれた「The Team 5つの法則」を読んでみたのでその感想を書いていきます。
ポチップ
この本で自分が１番印象に残っているのはこの言葉です。
メンバーの「当事者意識」を高めるために最も無駄なのは、「当事者意識を持て！」ということです。
これはめちゃくちゃ分かります。「当事者意識」を持てと言って、持ってくれたら誰も苦労しないですよね。
その仕組みづくりについて、書かれているのでとても参考になりました。
スクラム（アジャイル開発）をしてきて思ったことと重なることが多いので、実際に経験したことも含めてこの記事を書いています。
The Team 5つの法則 要約＆感想
この本を読んで分かること
タイトルにもある通り、Teamに必要な５つのことを紹介してくれます。
- 目標設定の法則
- 人員選定の法則
- 意思疎通の法則
- 意思決定の法則
- 共感創造の法則
チームで仕事をしていく中で、あるあるとうなずきながら読み終えた本でした。
それぞれの章で感じたことを書いていこうとも思いますので、興味のある方はぜひ御覧ください。
#1 目標設定の法則
目標を設定するにあたって、重要な定義はグループとチームの違いです。
グループは集団。チームは目標に向かって各人がそれに向かい役割を果たしていくことです。
目標を確実に達成するチームが良いチームではなく、目標を適切に設定できるチームが良いチームだ
実現可能性が高い目標を掲げ、それを達成したとして、あなたはどう思いますか？
目標を適切に設定する。言葉にすると簡単ですが、実際に考えると非常に難しいことです。
この適切な設定は、どこにいっても考えさせられるテーマだと思います。
目標設定は、現在の人事制度でよくあると思いますが、設定する目標は人によってまちまち。口が上手い人が良い評価を受けるということはどの職場でもあるあるではないでしょうか。
ここの違和感に気付かないと、社員の不平・不満は無くならないだろうなーと思ったりします。
目標設定は、行動レベル・成果レベル・意義レベルの３つ
目標設定は難しいですが、設定しない限りチームとして良い成果は挙げられません。
この３つを考えることで、良いチームに近づくことができます。
- 意義レベル→どういう世界になるのか
- 成果モデル→何ができあがるのか
- 行動レベル→どんな行動をするのか
どれか１つを設定するのではなく、バランス良く設定することが重要です。
例えば意義レベルだけ捉えると、「○○な世界を作る」と目標を設定した場合、チームのメンバーは各々がその目標に沿って好きなことをしだす。または、何をすればよいか分からず何も生み出さないか
行動レベルだけ捉えると、「□□を作る」と目標設定をした場合、何のためにやっているか分からず、新しい発想が生まれにくいといった欠点が出てきます。
目標設定は、チームで活動する上で重要であるが、重要と捉えてチームで考え抜くことはもっと重要だと感じました。
#2 人員設定の法則
目的が決まれば、次に必要なのが人員選定。
チームは4つのタイプに分かれるため、どんな人員を集めればよいかが分かってくる。
これらは環境の変化度合い × 人材の連携度合いにより変わる。
1. 野球チーム型 環境：小 × 人材：大 （ex.飲食店の店舗スタッフ）
2. サッカーチーム型 環境：大 × 人材：大 （ex.スマートフォン開発）
3. 柔道チーム型 環境：大 × 人材：小 （ex.生命保険の営業チーム）
4. 駅伝チーム型 環境：小 × 人材：大 （ex.メーカー工場の生産）
エンジニアに関連のあるのは、サッカーチームが多いと思います。
サッカーでいうところの、各ポジンションの役割の違いと一緒ですね。
ソフトウェア開発において、目まぐるしく変わる、環境の変化（仕様変更、スコープの変化等）と人材の連携（インフラチームとアプリケーションチームのやりとりやユーザとのやりとり等）は、切っても切れない関係です。
ただ、最近ではアジャイル開発の手法が取り上げられている中で、アジャイル開発は、サッカー型というよりフットサル型といったほうが近いのかなと思っています。
ウォータフォール開発では、要件定義・設計・実装・テスト・運用フェーズと段階的にアプリケーションが進みます。
そのため、実装が得意な人・設計が得意な人・スケジュール管理が得意な人など、さまざまなタイプの人がチームには必要で、その人達は、決められたスケジュールが動いているときに、存在していれば問題ありません。
要件定義・設計のときには、これが得意な人だけいればよくて、
設計が決まれば、実装者がいればよくて
実装が終われば、テストできる人がいればよくて
といった感じです。
ですが、アジャイル開発では、この5つのフェーズを高速に回す必要があります。
攻守が激しく入れ替わるフットサルと似ていますね。攻撃もできて守備もできる人が必要になってきます。
プロダクトマネージャー、スクラムマスター、開発チームが全てのフェーズにおいて、意見交換・認識合わせをすることで、ウォーターフォール開発で必要であった、次の作業者への引継ぎを無くしています。この引き渡し作業を無くすことで、よりスピーディに開発を進めるようになります。
なので、1つの役割に特化したスペシャリストではなく、全フェーズをこなせるジェネラリスト（フルスタックエンジニア）が必要になってきているようです。
ただ、個人的にはスペシャリストはチームに居ると安心感・信頼感が違うので開発する上で必須です。ですが、チームにいてもよいし、チームの相談役として別で用意するのもありかなと思います。
仕事の進め方、アプリケーションの要件によって、必要な人材は違ってくるため適材適所で活躍できるようなチームを作ることが大切になってきます。
#3 意思疎通の法則
チームにはコミュニケーションが多いほうが良いという誤解
コミュニケーションを多くとっているほうが良いと言われることが多いが、この著書にもあるようにこれは誤解で、実は少ないほうが良いというのは、非常に賛成です。
コミュニケーション回数が多い＝伝言ゲーム と僕自身捉えています。
会議にでて、その話の流れが分かっていないと文脈を読み取ることができず、違った解釈をしたまま進んでしまうということはよくあります。
人員選定の法則で書いたアジャイル開発を例にしますが、僕がスクラムチームにいたときは、プロダクトオーナーと作るアプリケーションについて話すときは、開発チーム全員を含めて話し合っていました。
これをすることで、作る人も含めてイメージを共有でき、不要なコミュニケーション（こんなもの作れと言ってない、いや言った）を削除することが可能です。
ただ、会議に全員で参加する＝全員分の時間コストは消費していますので、必要な会議を必要な時間で回すファシリテーション能力は重要です。スクラムマスターの必須スキルでした。
コミュニケーションの回数が多ければ、その精度は落ちていくということを常に意識する必要があり、
コミュニケーションの質も高めなければ、時間ばかり取られていくということも、意識する必要があります。
この本では、他にもルールを設定することで意思疎通の精度を上げるやり方が説明されています。
- What：ルールは多いほうがいいのか、少ないほうがいいのか
- Who：メンバーが決めるのか、リーダーが決めるのか
- Where：個人成果か、チーム成果か
- How：成果を評価するか、プロセスを評価するか
- When：確認が多いか、確認が少ないか
4つのタイプのチームによって、ルールの決め方も変わってきます。どのようにルールを設定すればチームの最適解になるか、チームで話し合ってみるのも面白いと思います。
#4 意思決定の法則
チームで進んでいく中で、分岐点は必ず訪れる。そのときに最適な選択をすることができるのかを説いた章になっています。
意思決定をするのって勇気がいりますよね。
意思決定をする際に、話し合って決める・多数決をして決める・チームの誰かが決める。この3つの方法があります。
それぞれで、長所短所があります。その評価軸は、時間と納得感。
チームの誰かが決めれば、時間はかからないが、チームの納得感は低くなる（可能性がある）
話し合いをして決めれば、チームの納得感はできるが、時間はかかる。
多数決をして決めれば、時間はあまりかからないが、チームの納得感は半々といったところ
チームの現在置かれている状況によってどれをすべきか、考えていかなければいけないですね。
この本の中では、こんな言葉が書かれています。
意思決定者は反対や孤立を恐れずに、1人で決めよ。
しかし、メンバーは意思決定者を孤独にするな。
とても良い言葉だと思うと同時に、これこそ良いチームだなと思いました。
リーダーシップのあるリーダーとフォロワーシップのあるメンバーに囲まれたチームに所属したいと常々思っています。（切実）
意思決定したことにおいて、誰かのせいではなく、チームのせいにすることができるのは、非常に重要だと思います。
少し話はそれますが、昔いたスクラムチームでは、インシデントが発生した際に、誰をせめるでもなく、チームの問題として解決策を見出すためのミーティングを開くようにしていました。
インシデントが発生したのは、チームのせい。誰かを責めるのではなく、チームを責める。
今後起きないために対応策を話し合い、実践する。
具体的には、以下のことを話します。
- 発生した背景の整理
- なぜ発生したか原因の整理
- 解決策の提起
- 解決策の実行（暫定・恒久対応）
これをすることで、失敗してしまった人のメンタルケアにも繋がりますし、失敗を恐れないチームとして、士気もあがることを実践できました。
孤独にさせない。チームとして戦い抜くことを重要視した活動の1つだと思うので、みなさんも是非試してみて下さい。
#5 共感創造の法則
チームメンバーのモチベーション管理の重要性を説いた章になります。
みなさんはチームメンバーのモチベーションがどこに向いているか管理できていますか？
- 能力は基準以上ある（優等生）が、今の仕事に興味がない
- 能力は基準程度であるが、今の仕事が楽しい・やりがいがあると感じている
この2人を比べたときに、あなたはどちらの人と仕事がしたいですか？どちらの人に教えたいですか？
僕は圧倒的に後者です。能力で劣っていても、意欲でそれを上回る日がかならず来るからです。責任感の感じ方もきっとちがってきますよね。
人それぞれモチベーションがどこに向いているか違っているものです。チームをより良くするために、ぜひチームメンバーと話し合ってみてください。
人員選定の法則でもあったように、チームは入れ替えが必要なときも出てくるでしょう。どんな人とやればチームとして良くなるかを考える必要があります。
仲良しこよしでやるようならそれはチームではなくグループです。
チームのパフォーマンスを上げて、良いプロダクトを生んでいきたいですね。
チームの落とし穴
自分ひとりくらいという落とし穴（社会的手抜き）
チームのメンバーが増えれば増えるほど、落とし穴は多くなっていきます。人が多いチームはここ注意する必要があります。
誰かがやってくれるから大丈夫だろう。とみなさん一度は思ったことがあると思います。
そして、実際誰もやっていなかったみたいになったらもっと最悪です。
こうならないために必要なことが「当事者意識」です。
誰かがやってくれるから、自分はやらなくても良いだろう。ではなく、
自分もやる必要が出てくるかもしれないから、自分から動こう。
こうなるのが理想だと思います。
メンバーの「当事者意識」を高めるために、最も無駄なことは、
当事者意識を持て！と言うことです。
本書の中で、僕が1番ぐさっときた言葉です。
チームのメンバーが増えていく中で、一番心を悩ました事柄の一つでもあったからです。
チームのメンバーが増えていくと、新規参入者は、自分から動ける人ではない可能性もあります。
チームとして既に自立していると、そのメンバーだけで動けているので、自分いなくても大丈夫と思って積極的に動けなかったのだろうと思っています。
ここで、チームとして動くために必要だったことは、３つと紹介されています。
- 人数を少なくする
- 責任を持たせること
- 参画感を持たせること
１つ目の人数は、人数が多いと作業がかぶったり、タスクが少なくなったり、生産効率が非常に悪く、更に人の成長も止めてしまいます。
すぐに人員を減らしましょう。もし難しければ、機能ごとに少人数チームを仮に作ることをおすすめします。
２つめの責任は、タスクのメイン担当者として責任を負わせましょう。そのタスクを主導してもらうことで、声を上げるきっかけになるためです。
３つ目の参画感は、積極的に意見を聞くことで感じさせてあげましょう。
旧チームだけだと意見が偏ってしまう可能性があるため、ぜひ外側からの意見も欲しい。といったスタンスで、積極的に声を上げてもらうことが重要です。
チームに参画している・自分の意見を言っても良いんだということを示してあげましょう。
会社で働くということは、色々な人と仕事をすることです。色々な価値観を持った人たちと、良いチームで働いていくために、ここで紹介したことを実践してみてはいかがでしょうか。
また、今回紹介したこちらの本では、それ以上に詳細に書かれていますので、チーム運営のメソッドがたくさん掲載されています。興味を持った方はぜひご覧ください。
ポチップ
チームマネジメントに関するその他のおすすめ本はこちらでも紹介しています。
また、エンジニアの仕事を楽しくするためのコツがわかるおすすめ本を以下の記事で紹介しています。
興味のある方はぜひご覧ください。
現役エンジニアがおすすめする本7選｜初心者エンジニアが楽しく仕事をするためのコツ
