チームビルディング
仕事をする上でチーム作りって大事だなと、あらためて今日思った。
人ってそもそもモチベーション次第で仕事のパフォーマンスはがらりと変わるけど、じゃあ、そのパフォーマンスを高く保つキーは何かというと、チームの関係性だとか、雰囲気なんだと思う。
互いに、いい仕事をし合って全体のクオリティを上げるには、互いが信頼し合って、言うべきことをちゃんと言えたり、それぞれが積極的に自分の仕事を作り、互いに刺激になるような提案をし合う環境をいかに作るかだと思う。
人間関係のストレスのない環境をつくる
いろんなチームの作り方があると思うけど、僕はとにかく楽しく、なんでも面白がって仕事をし合える関係性でいられるチームが好きだ。いい時はほめて、ダメだったら違うって、そんなに気を遣わず言える関係性。上下関係とかもほとんど気にならないようにしたいし、誰が言ったことなのかとではなく、本当に良いアイデアを採用していける状態を作りたい。
最終的にいい仕事をしたって言えることを一番に目指して、その妨げになりそうな各自のプライドとか競争とかは保留にできる人の集まり。もちろん、性別とか、年齢差とかも、違いは認めつつも、それを理由にしたへんな先入観はあってはダメだと思う。そんなことで各人のパフォーマンスを下げるのは馬鹿らしい。とにかく人間関係に気を使うコストは極力減らした環境にチームを置きたいなと思う。
同じ目線、同じ立場で
あとは一度集まったら、組織の壁とかを言うのはやめにしたい。同じ目標を目指そうというとき、誰が発注者で誰が受注側かなんて言い出したら、それぞれの持っているパフォーマンスの引きだせる割合は高くはならない。やれる人がやれることをやる。わかる人がわかることをやる。そういうことを優先せず、発注側だの受注側だのを優先しだしたら、それぞれの持つ力とは無関係にタスクを実行しなくてはならなくなり、それはチームでの仕事ではなくなる。組織の違いは棚に上げて、同じ目線、同じ立場で、目標に向かうことができないなら、チームを外から見守る選択をした方がよい。
そして、お金を出して、本当に自分が望む結果を、チームに出してもらいたいなら、いかに彼らのパフォーマンスが自分たちが望む方向に最大化するかを考え、振舞うべきだろう。
そのとき、一番欠かせないのは、自分が望むイメージを充分に彼らに伝えることだ。あとは彼らがパフォーマンスを最大化できるように、楽しい環境と自由な創造の余地をちゃんと用意してあげることだろう。
自分が何を欲しているかイメージできていなければ、チームからそれが出てくること期待しても、無駄だ。ちゃんとイメージを自分でもはっきりさせた上で、チームにその旨を伝えないと、何のために何を外にお願いしてるのかわからない。そんなやり方で自分の納得いくものが得られるとでも思っていたら大間違いだ。
もちろん、そんな状態でもちゃんと思いを拾ってくれる有能な人はいるが、そういう人はまあ、それなりの人だ。それなりの人に頼めないなら、自分の側で工夫する必要がある。
目的が明確にないのに、アウトプットだけ頼んでも
もし、自分がまだちゃんと欲しているものがイメージできていないなら、それこそ、そのイメージをするところからちゃんと外の人がたちを集めて、彼らといっしょに期待するイメージは何か？というところから、チームになっていっしょに考えた方がいいだろう。
自分が欲するもののイメージもわいてないのに、いきなり最終アウトプットのみ、外に出て頼もうとする人がいるが、そんな馬鹿な話はない。アウトプットに何が求められるのかという要件が決まってないところで、アウトプットを期待したところで、出てくるものはたかがしれている。
頼まれるほうはそれなりのプロなのだろうから、悪くはないものが提示されることは少なくないだろうが、それが本当に欲していたものであることはほぼないだろう。それに満足しているとしたら、そもそも何を何の目的で頼んだかがわかってなさすぎて、判断基準が単なるアウトプットに対する好みとかになってるからだろう。
そんな無意味なことを外部にお願いするくらいなら、目的とゴールの設定から含めて外部といっしょに考えるプロジェクトからはじめた方が良いと思う。
計画＋コミュニケーション
さて、話が逸れたので、チームビルディングの話に戻りたい。
誰をプロジェクトチームのメンバーにするかはもちろんプロジェクト設定をする上で大事なことだ。でも、ここまでも書いてきたように、集めたメンバーとどう取り組むかの設計はそれ以上に大事なことだ。にもかかわらず、多くのプロジェクトが後の部分の設計がない。いや、設計がないというより、昔ながらの組織設計、ウォーターフォール型でまわす仕組みのための人員計画をそのまま、いまのオープンコラボレーションやアジャイルなどが取り入れられたプロジェクトにも当てはめるから、うまくいくはずがない。オープンなプロジェクトでは、誰もが自分が何をすべきかを積極的に、役割を超えてでもやれるような環境が必要だ。だから、外のメンバーへの発注も当然、アウトプットだけの発注という形になるはずもない。プロセスへの積極的な参加も含めた依頼となるだろう。
そうしたことも含めてのプロジェクト設計がなければ、プロジェクトは人間関係の整備に追われて、成果を出すことに時間を割けないだろう。多くのプロジェクト失敗の大きな要因がそれだ。
チームで仕事をするなら、やはり上下や組織の違い、性別や年齢、役職などをある程度、括弧に入れたコミュニケーション、コラボレーションができる状態になって、共通の目標に向かって達成を目指すには、どうすればよいか、どう動いていくかをちゃんと共有しながら進めることが大事だ。
それには目的や目標と、それに伴うKPIの設定、さらにはそれを目指すためのスコープや品質基準、コミュニケーションの方法や予算などをしっかり計画立て、かつ、その計画をマネジメントしながら実行することが必要だと常に感じる。
そういうちゃんとした計画があっての、楽しく進めるためのコミュニケーションだったり、雰囲気作りが大事だよねという話。互いのコミュニケーションが大事だし、互いのリスペクトが欠かせないのだろう。
そんな計画や配慮があってこそのチームワークスである。
そこの気を遣えず、プロジェクトを進めてもうまくいくはずがないのは当然ではないだろうか。
基本的にnoteは無料で提供していきたいなと思っていますが、サポートいただけると励みになります。応援の気持ちを期待してます。