良いチームと悪いチーム
目次
仕事を始めてから、割りとあっというまに、いつのまにか15年以上がたちました。
うまくいっているチームや、うまくいってないチームなどさまざまなチームで開発をしてきました。
いままで働いてきたことを振り返って、いいチームはどういうチームなのか
うまく行ってないケースはどういうパターンがあるのかを、
過去の経験を元に原因と対策について今考えてることをメモしておこうかと思います。
うまく行っているチームとは
- 何を作るかの、開発の方針が明確になっている
- それが全員に共有されていている
- 要件定義、相談、実装のフローが構築されている
- 要件定義から実装までのフローが素早く行えるような構造になっている
- PDCAが素早く行えるような構造になっていたり、それに変わる仕組みができている
- 要件定義から実装までのフローが素早く行えるような構造になっている
- それぞれの分野のプロが揃っていて、適切な配置と役割が明確になっている
- その役割を個々が認識している
- チームの状態が良好
- 仲がよい
- お互い意見し合える関係性ができている
- お互いの意見を尊重しつつメリット・デメリットを考慮した判断ができている
- それぞれが何をしているのかを個々が把握している
- すばやい開発が行えるような開発環境が整っている
- 上記のどこかに問題が起きたときに、改善できるようなフローが構築されている
- KPTなど 振り返りのフレームワーク「KPT法」とは｜そのメリットや進め方、実施のポイントについて
- 方向がずれているときに改善できるような体制を整える 1on1などの面談を設定するなど
うまくいっていないチームとは
「上（うまく行っているチームとは箇条書き）のどこかに問題がある」ということかなとは思います。
これで終わっても味気ないので、一つづつもう少し過去の経験も踏まえて掘り下げて行こうかなと思います。
何を作るかの、開発の方針が明確になっていない、もしくは共有されていない
- そもそも方針がない
- 誰が方針を決めるのかがわからない体制になっている
- 方針はあるが、チームに共有されていない
- 方針は共有されているが、全員が納得できていない
- チームで作りたいものがバラバラ
- 営業、プロジェクトマネージャー、開発の目線がそれぞれで違うなど..
全体的にチームがコミュニケーションがうまく行っていないために、起こっている問題が多いかなと思います。
方針が決まっていない、共有されていない場合に見直したい部分
- リーダーなどの上位の人が方針を決めきる
- リーダーがいない場合は全体で話して決めれる体制を作る
- 決めた方針を全員が納得行くかたちで共有する
- 納得が難しい場合は、チームでの対話や一人一人と対話するような体制を作る
- 作りたいものがバラバラにならないように、方向がぶれないような話し合いや軌道修正が定期的に行えるような体制を整える
方針決めについてのまとめ
問題点 | 付随する問題 | 解決策 |
|---|---|---|
そもそも方針がない | リーダーなどの上位の人が方針を決めきる | |
誰が方針を決めるのかがわからない体制になっている | リーダーがいない場合は全体で話して決めれる体制を作る | |
方針はあるが、チームに共有されていない | 決めた方針を全員が納得行くかたちで共有する | |
方針は共有されているが、全員が納得できていない | 納得が難しい場合は、チームでの対話や一人一人と対話するような体制を作る | |
チームで作りたいものがバラバラ | 営業、プロジェクトマネージャー、開発の目線がそれぞれで違うなど.. | 方向がぶれないような話し合いや軌道修正が定期的に行えるような体制を整える |
要件定義、相談、実装のフローが構築されていない
- そもそも要件になっておらず、直接な仕様ベースの要望で落ちてくる構造になっている
- 例）要望「ヘッダーの色を変えてほしい」 → 実際の要件「ヘッダーの文字が見づらい」
- 例）要望「ローディングが邪魔なのでなくしたい」 → 実際の要件「読み込みが遅いため、早くしたい。ローディンがじゃまにならないような工夫がしたい」
- 何をいつ実装するかの区分けが明確になっていない
- 要件定義から、実作業への落とし込みが適切に行われていない
- 作業する人を交えての作業への落とし込みの、コミュニケーションが取られていない
- 実作業する人が納得する落とし込みが行われていない
- 要件の入り口と、実装のリリースまでの出口の責任者が一人で、そこを通過しないと物事が進まない構造になっている
- 一つ遅れると全員に影響するような構造になっている
- 実装・レビュー・修正・リリースフローが明確になっていない
- 定期的な遅れを見直す構造になっていない
要件定義、相談、実装のフローが構築されていない場合に見直したい部分
- 要件と実装にわけて適切に議論して決定する
- すぐにリリースが必要なもの、そうでないものの把握と判断をする
- 要件定義から、実作業への落とし込みをチームの担当者が納得している状況を作る
- みんなで話し合って決める場を用意する
- 一人に仕事が集中しないように適切な役割分担が行われるような仕組みを作る
- 遅れている場合に、「リリース伸ばす」、「対応をずらす」などを考えられるような状態を作る
フローが構築のまとめ
問題点 | 付随する問題 | 解決策 |
|---|---|---|
そもそも要件になっておらず、直接な仕様ベースの要望で落ちてくる構造になっている | 例）要望「ヘッダーの色を変えてほしい」 → 実際の要件「ヘッダーの文字が見づらい」 例）要望「ローディングが邪魔なのでなくしたい」 → 実際の要件「読み込みが遅いため、早くしたい。ローディンがじゃまにならないような工夫がしたい」 | 要件と実装にわけて適切に議論して決定する |
何をいつ実装するかの区分けが明確になっていない | すぐにリリースが必要なもの、そうでないものの把握と判断をする | |
要件定義から、実作業への落とし込みが適切に行われていない | 作業する人を交えての作業への落とし込みの、コミュニケーションが取られていない 実作業する人が納得する落とし込みが行われていない | 要件定義から、実作業への落とし込みをチームの担当者が納得している状況を作る みんなで話し合って決める場を用意する |
要件の入り口と、実装のリリースまでの出口の責任者が一人で、そこを通過しないと物事が進まない構造になっている | 一人に仕事が集中しないように適切な役割分担が行われるような仕組みを作る | |
一つ遅れると全員に影響するような構造になっている | 実装・レビュー・修正・リリースフローが明確になっていない | 一人に仕事が集中しないように適切な役割分担が行われるような仕組みを作る |
定期的な遅れを見直す構造になっていない | 遅れている場合に、「リリース伸ばす」、「対応をずらす」などを考えられるような状態を作る |
メンバー不足、適切な配置が行われていない
- どんな技術を持ったメンバーが足りていないのかが、明確になっていない
- 個々がやりたいこと、得意なことを認識せずに配置が行われている
- 個々がそれぞれの担当範囲、責任範囲を認識していない
適切なメンバー配置が行われていない場合に見直したい部分
- 足りないメンバーはどういうメンバーなのかを明確にする
- いくらメンバーを集めても、足りないメンバーを把握していないと、チームに必要ないメンバーが集まることになってしまう
- それぞれメンバーと話し合い得意なこと、やりたいことを明確にする
- それぞれ納得した状態で、適切な配置を決める
- 決められた責任と担当範囲を全員が納得している状態を作る
メンバー集め・配置のまとめ
問題点 | 付随する問題 | 解決策 |
|---|---|---|
どんな技術を持ったメンバーが足りていないのかが、明確になっていない | 足りないメンバーはどういうメンバーなのかを明確にする いくらメンバーを集めても、足りないメンバーを把握していないと、チームに必要ないメンバーが集まることになってしまうため | |
個々がやりたいこと、得意なことを認識せずに配置が行われている | それぞれメンバーと話し合い得意なこと、やりたいことを明確にする | |
個々がそれぞれの担当範囲、責任範囲を認識していない | それぞれ納得した状態で、適切な配置を決める 決められた責任と担当範囲を全員が納得している状態を作る |
チームの状態が悪い
- 営業、プロジェクトマネージャー、開発の分野ごとの関係性が良くない
- 仲が悪い人同士がチーム内にいる（空気が悪い）
- 誰に何を任せる、相談すればいいのかがわからず、個々の信頼関係が構築されていない
- 開発方針が個々でバラバラで話し合う場がない
チームの状態が悪い場合に見直したい部分
- なぜ担当範囲ごとの関係性が良くないのかを全体で話し合い明確化する
- 個人攻撃ではなく、なるべくは仕組みで解決するような話し合いを行う
- それぞれ、任せればうまくいくという信頼関係を構築する
- 問題点を前向きに、対等に言い合い解決できる人間関係を構築する
- 人間性の否定やマウントの取り合いなどではなく、仕組みで解決するような方向性を話し合えるようにする
- どんなことに興味があるのかを、チームとしてぼんやりと共通認識が状態にする
- どうしても合わない人や・もやもやする課題は早めに解決する
- どうしても解決が難しい場合は、プロジェクトの配置換えなど、やり取りしないでいいような人事配置を検討する
- 問題点を前向きに、対等に言い合い解決できる人間関係を構築する
- 上記ができるような、日々のコミュニケーションが行える環境を構築する
- 問題点が入り組みすぎていて最悪の場合は、問題点を把握した上で、0からチーム編成しなおすことを検討する
- 問題点を把握してから出ないと、また同じ結果になってしまうので注意
チームの人間関係の問題
問題点 | 付随する問題 | 解決策 |
|---|---|---|
営業、プロジェクトマネージャー、開発の分野ごとの関係性が良くない | なぜ担当範囲ごとの関係性が良くないのかを全体で話し合い明確化する 個人攻撃ではなく、なるべくは仕組みで解決するような話し合いを行う | |
仲が悪い人同士がチーム内にいる（空気が悪い） | どうしても合わない人や・もやもやする課題は早めに解決する どうしても解決が難しい場合は、プロジェクトの配置換えなど、やり取りしないでいいような人事配置を検討する | |
誰に何を任せる、相談すればいいのかがわからず、個々の信頼関係が構築されていない | それぞれ、任せればうまくいくという信頼関係を構築する 問題点を前向きに、対等に言い合い解決できる人間関係を構築する 人間性の否定やマウントの取り合いなどではなく、仕組みで解決するような方向性を話し合えるようにする どんなことに興味があるのかを、チームとしてぼんやりと共通認識が状態にする | |
開発方針が個々でバラバラで話し合う場がない | 上記ができるような、日々のコミュニケーションが行える環境を構築する |
問題点が入り組みすぎていて最悪の場合は、問題点を把握した上で、0からチーム編成しなおすことを検討する
問題点を把握してから出ないと、また同じ結果になってしまうので注意
開発スピードが遅くなる開発環境になっている
- ビルドが遅く、一つ作業するごとに、集中が切れてしまうほどにビルド時間がかかる
- トライ&エラーでコードを確認しようとしてもビルド時間がかかるため、中身が調べずらい
- コードの影響範囲がわかりずらい構造になっている
- 実装からレビューのフローが構築できていない
開発スピードが落ちている場合に見直したい部分
- 他のタスクを一時中断してでも早めにビルドを改善するタスクを先に進めるようにする（どんどん他作業が遅くなる原因になってしまうため）
- 影響範囲がわかりやすいような閉じた作りにする（フロントの場合コンポーネント内で完結するなど）
- E2Eテストや、単体テストを入れる
- 実装が完了後、誰が、いつまでにレビューするかを決める
開発環境についてのまとめ
問題点 | 付随する問題 | 解決策 |
|---|---|---|
ビルドが遅く、一つ作業するごとに、集中が切れてしまうほどにビルド時間がかかる | トライ&エラーでコードを確認しようとしてもビルド時間がかかるため、中身が調べるのに時間がかかる | 他のタスクを一時中断してでも早めにビルドを改善するタスクを先に進めるようにする （どんどん他作業が遅くなる原因になってしまうため） |
コードの影響範囲がわかりずらい構造になっている | 影響範囲がわかりやすいような閉じた作りにする（フロントの場合コンポーネント内で完結するなど） E2Eテストや、単体テストを入れる | |
実装からレビューのフローが構築できていない | 実装が完了後、誰が、いつまでにレビューするかを決める |
まとめ
うまくいっているチーム、いっていないチームについて考えてみました。
さまざまなチームで開発をしてみて、長くいたチームは
「一緒に働いている仲間とずっと一緒に開発をしたいなぁ」と思ったことが一番大きいかなと思いました。
人間関係の居心地が悪かったり、尊敬する人が周りにいなかったり、開発スピードがあわなかったり、
この辺りがつづくとどうしても長く続けることは難しくなってしまうのかなと思います。
たくさんのメンバーとチームで開発していると、
日々問題が起こるのは当たり前だと思うので
それを改善できるようにコミュニケーションや、見直せるフローを作っておくことが大事かなぁと思います。
これからもいろんな人と出会って、いい感じに開発し続けていきたいですねっ。
最近ものすごくいろんな開発をしたい欲が出てきていて、
色々なプロジェクトに積極的に参加していきたいと思っています！
