ケースから考えるチームビルディング

こんにちは、@kuuhakuです。
東京のベンチャー企業に勤めているエンジニアです。

去年と今年の2年間、IPAのプロジェクトマネージャー試験の勉強をしていました。
資格勉強を通じて現場でも活かせそうな内容だと思い、
「チームビルディング」のテーマを記事にしました。

# どういう人向けの記事なのか
- プロジェクトマネージャーやチームリーダになりたてでチームを任されたけど、
どう運用したりメンバーと接したらいいかわからない人
- サブリーダになって、サブチームを運用するよう任されたけど、どうすればいいか分からない人
- チームをまとめたり、マネジメントをやってみたい人

:::note warn 
既にプロジェクトマネージャーを務めていて、何年も仕事をしている人にとっては、
役に立たない内容であったり、もっと素晴らしいやり方があると思います。

ですが、何事にも基礎は大事だとは思っているので、
その基礎的なやり方をまとめたものだと思っていただけると幸いです。
:::

# この記事の使い方
プロジェクトを進めるに連れて発生するチームに関する問題をケース毎に出して行きます。
問題を読んで、「もし私がプロジェクトマネージャーでこの状況だったらこういう対応をするなぁ」
と想像しながら読んでいくと学びが大きいかと思います。

# 用語の紹介

```
DXについて：
「DX（デジタルトランスフォーメーション）」とは、企業がAI、IoT、ビッグデータなどのデジタル技術を用いて、
業務フローの改善や新たなビジネスモデルの創出だけでなく、
レガシーシステムからの脱却や企業風土の変革を実現させることを意味します。
```
(引用：https://monstar-lab.com/dx/about/digital_transformation/)

# 背景

```
あなたは玩具製造業のA社で働くプロジェクトマネージャーである。
A社は主要事業としてトレーディングカードなどの玩具を製造して、
店舗またはインターネットで顧客に販売している。
今回、新しい顧客の獲得と売上の向上を目指すために「玩具を製造・販売する事業」から
「遊び体験を提供する事業」へのDXの推進に取り組むことにした。
その具体的に活動として、まずはトレーディングカードの電子化から進める。

これまでA社では、PMによる統制のマネジメントの影響が大きいため、
システム部のメンバー(以下、メンバー)が事業部門に対して意見を伝えづらかったり、
事業部門の指示に応じた作業が中心であるので、メンバーのモチベーションが低下するといった状況である。
これはあなたがA社で5年働いていて気づいたA社のチーム作業の課題である。

これまでの体制ではDXの推進に取り組むことが出来ないと感じたあなたは、
全社横断でチームを編成し、能動的に目標を定めることの出来るチームを目指して
チームビルディングを行うことにした。
```

# ケース.1

```
(質問)
まずは、あなたが感じたA社のが抱えているチーム作業の課題と
メンバーが感じているチーム作業の課題が同じであるか確認する必要がある。
あなたはどんな行動をしましたか？ 選択肢A~Cの中から正しいものを選んでください。

(選択肢)
A：これまでのチーム作業の中で困った点や反省点について、メンバーに無記名のアンケートを実施する
B：メンバーと個別に面談し、あなたが感じたA社の状況を説明してからメンバーが感じている状況について聞き出す
C：メンバーを全員集めて会議を開き、これまでのチーム作業の中で困った点や反省点について聞き出す
```

<details><summary>ケース.1の解答と解説</summary>

正解は「<strong>A：これまでのチーム作業の中で困った点や反省点について、メンバーに無記名のアンケートを実施する</strong>」です。

◯ A：これまでのチーム作業の中で困った点や反省点について、メンバーに無記名のアンケートを実施する
→ 無記名のアンケートという形で匿名性を持たせることで、メンバーが気軽に困った点や反省点を引き出しやすくします。

× B：メンバーと個別に面談し、あなたが感じたA社の状況を説明してからメンバーが感じている状況について聞き出す
→ PMであるあなたが感じたA社の状況を説明してからだと、メンバーがその考えに引っ張られる状況になってしまいます。

× C：メンバーを全員集めて会議を開き、これまでのチーム作業の中で困った点や反省点について聞き出す
→ 全員を集めて会議を開いてしまうと、
会議の中に対象のメンバーがいた場合、遠慮してしまってチーム作業の中での困った点や反省点についての
本音について聞き出せなくなってしまいます。

</details>

# メンバーから聞き出した課題
(※ケース1の続きです)

```
ケース1の行動をした結果、あなたは、メンバーから次のような状況を聞き出すことが出来ました。

課題1：
対立につながる可能性のある意見を他のメンバーに伝えることを恐れている。
その理由としては、自分は他のメンバーを信頼しているが、
他のメンバーは自分を信頼していないかもしれないといった懸念を感じているからである。

課題2：
チームの一員としてチームのマネジメントへの参画に関心が高いメンバーがいるが、
これまでのチーム作業では、自分の考えをチームの意思決定のために提示出来ていない。
後になって自分の考えが採用されていれば、チームにとってより良い意思決定になったのではないか
と後悔することが多い。

課題3：
チーム作業の遂行において、自分の能力不足によって困難な状況になった時に、
他のメンバーの支援を受ければ早期に解決出来たかもしれないのに、
支援を求めることが出来ずに苦戦することがあった。
```

# ケース.2

```
(質問)
メンバーから聞き出した課題1(対立につながる可能性のある意見を他のメンバーに伝えることを恐れている)に関して、
メンバーとの対話を重ね、1つのチームの運営方法を定めることをメンバーと合意しました。
どのような内容で合意したのでしょうか？A~Cの中から正しいものを選んでください。

(選択肢)
A:対立につながる可能性のある意見を言わず、自分の中で無理やり納得させる
B:対立につながる可能性はあるが、自分の意見を述べて相手を論破する
C:メンバーは対立する意見にも耳を傾け、自分の意見も率直に述べる
```

<details><summary>ケース.2の解答と解説</summary>

正解は、「<strong>C：メンバーは対立する意見にも耳を傾け、自分の意見も率直に述べる</strong>」です。」


△ A:対立につながる可能性のある意見を言わず、自分の中で無理やり納得させる
→ 対立には発展しないので、一見良い回答に思えますが、その代償として自分の意見を押し殺してしまっています。
対立側の意見が間違った方向性であったら、自分の意見の方がよりよい意見であったら、と考えると
チームの為に自分の意見も率直に述べた方がチームの成長につながります。

× B:対立につながる可能性はあるが、自分の意見を述べて相手を論破する
→ 一方的に意見を述べて相手を論破してしまうと、相手側に何らかの不満感が残ってしまい、
チームの関係性が悪くなるリスクがあります。

◯ C：メンバーは対立する意見にも耳を傾け、自分の意見も率直に述べる
→ PMのしての立場としては、多少のメンバー同士の対立に関しては、目を瞑ることも大事です。
なぜなら多少の対立から、妥協案やよりより意見が出てきたりする可能性があるからです。
ただ大規模な対立になってきて、意見の違いから派閥が出来たり、感情論になってきてしまった場合は
PMが止めに入って、PMや経営陣側にエスカレーションし決定事項を周知する対応になります。

</details>

# ケース.3

```
(質問)
メンバーから聞き出した課題2(自分の考えをチームの意思決定の為に提示出来ていない)に関して、
メンバーとの対話を重ね、1つのチームの運営方法を定めることをメンバーと合意しました。
どのような内容で合意しましたか？ A~Cの中から正しいものを選んでください。

(選択肢)
A：チームのマネジメントへの参画に関心が高いメンバーが自分の考えの赴くままに行動する
B：メンバー間での対話を通じて、チームとして意思決定をする
C：チームのマネジメントへの参画に関心が高いメンバーの意見だけをチームの意思決定とする
```

<details><summary>ケース.3の解答と解説</summary>

正解は「<strong>B：メンバー間での対話を通じて、チームとして意思決定をする</strong>」です。

△ A：チームのマネジメントへの参画に関心が高いメンバーが自分の考えの赴くままに行動する
→ 一見関心が高いメンバーが自分の考えの赴くままに行動することは悪くはないように思ってしまうが、
チームとしてではなく、個人での行動になってしまいチームの運営方法としてはふさわしくないです。

◯ B：メンバー間での対話を通じて、チームとして意思決定をする
→ チームのマネジメントへの参画に関心が高いメンバーの意見が必ず正しいとは限りません。
そこに関しては、メンバー間での対話を通じて、考えを納得させた上でチームとしての意思決定にする方がいいでしょう。

× C：チームのマネジメントへの参画に関心が高いメンバーの意見だけをチームの意思決定とする
→ チームのマネジメントへの参画に関心が高いメンバーの意見だけをチームの意思決定としてしまうと、
間違った判断や方向性の場合チーム全員が引きずられる結果となってしまいます。

</details>

# ケース.4

```
(質問)
メンバーから聞き出した課題3(支援を求めることが出来ずに苦戦することがある)に関して、
メンバーとの対話を重ね、1つのチームの運営方法を定めることをメンバーと合意しました。
どのような内容で合意しましたか？ A~Cの中から正しいものを選んでください。

(選択肢)
A:メンバー自身の能力不足によって困難な状況になったときは、何もせずに放置する
B:メンバー自身の能力不足によって困難な状況になっても、上司に無断で残業してでも頑張ろうとする
C:メンバー自身の能力不足によって困難な状況になったときは、それを他のメンバーにためらわずに伝える
```
　　
<details><summary>ケース.4の解答と解説</summary>

正解は「<strong>C:自分の能力不足によって困難な状況になったときは、それを他のメンバーにためらわずに伝える</strong>」です。

× A:メンバー自身の能力不足によって困難な状況になったときは、何もせずに放置する
→ 何もせずに放置するのは、良い解決に向かいません。

△ B:メンバー自身の能力不足によって困難な状況になっても、PMに無断で残業してでも頑張ろうとする
→ 頑張ろうとすることに対しては悪いことではありませんが、PMに無断で残業するのはNGです。
会社によってはPMが工数を管理していたりもするので、残業が発生したとしても報告する必要があります。

◯ C:メンバー自身の能力不足によって困難な状況になったときは、それを他のメンバーにためらわずに伝える
→ タスクに関しては、期限や納期に迫られることがほとんどだと思います。
自身の能力不足によって困難な状況と気付いたときは早期に他メンバーの支援を求めましょう。

</details>

# まとめ

このケースからわかるように、
主に以下の4つの手順で進められると、
「<strong>能動的に目標を定めることの出来るチーム</strong>」を作れると思います。

1.PMがどういったチームにしていきたいかを決定する
2.PM自身がチームの課題を認識する
3.目的を伝え、メンバーからの率直な意見をヒアリングする
4.聞き出した課題に対して、メンバーとの対話を通じてチームの運営方法を決める
5.上記1~4を継続的に続ける

図にするとこのような流れになります。

```plantuml
@startuml
[*] -down-> 1.チーム像の決定
1.チーム像の決定 -down-> 2.課題の認識
1.チーム像の決定 : PMが目指すチーム像を決める
2.課題の認識 -right-> 3.ヒアリング
2.課題の認識 : PMが感じたチームの課題を見つける
3.ヒアリング -up-> 4.チームの運営方法の決定
3.ヒアリング : メンバーに対してチームの課題をヒアリングする
4.チームの運営方法の決定 -left-> 1.チーム像の決定
4.チームの運営方法の決定 : メンバーと対話し、課題に対してチームの運営方法を決める
@enduml
```

# 最後に

今回のケースのように進められればいいのですが、現実はなかなか上手く行かないものですよね。。

チームビルディングに力を入れすぎると、
かえってメンバーに対して大きな負担を掛けてしまったりするので、
長期的に計画して進めていくといった方がいいように思います。

ここまで読んでいただきありがとうございます。
もしこの記事で楽しめた方は「LGTM』をいただけると幸いです。