マネジメントって何だろう その②「チームビルディング」
前回のマネジメントの記事の続きを書きたいと思います。
ヌーラボのTATSURUです。
前回の記事はマネジメントとリーダーシップについて書きました。
ご興味がある方はこちらも宜しくお願いします。
マネジメントの要素をテーマ別に深堀していければと考えています。
今回は、チームビルディングについて書きたいと思います。
卵が先か鶏が先か
マネジメントの話をする上で、チームビルディングをテーマに選んだのは「たまたま」ですが、何かプロジェクトを開始するときに、人選が先なのか計画が先なのかという議論が起きる事があります。
会社の状況にもよりますので、どちらでも構わないのですが、計画はいくらでも変更が効きますが、人は簡単に変更ができません。
本来は、超上流工程として事業戦略や事業計画があるのですが、今回はそれらがすでにある前提でプロジェクトをマネジメントする事になった場合を想定します。事業戦略や事業計画については別の機会に記事にできればと思います。
そうすると、詳細な計画を今後立てていく事も含め、人選は非常に重要ですし難しい部分があるので、まずはチームビルディングについて個人的な考えを紹介します。
プロジェクトは計画の時点で成否が決まっている
チームビルディングの話なのに、元も子もない話をするとプロジェクトの多くは計画の時点である程度成功するかどうかが決まってしまいます。
何をするのか、どうやるのか、誰がやるのか、前例のあるプロジェクトか、何をもって成功とするのか、どうなったら撤退するのか、そういった計画やその計画の根拠となる戦略の時点である程度成功確率が決まってしまいます。
世界の誰もがやっていない事をするのであれば成功は難しいでしょうし、具体的な事例があれば、参考にすることも可能なので成功率は高くなります。もし異常に難易度の高いプロジェクトを担当する事になった場合、そのあたりを踏まえて、難易度を上司や会社としっかり共有してうまく立ち回ってください。
しかし、成功確率を戦略や計画で高めていても、それを遂行するチームの実力や状況次第で失敗してしまう事もありますし、逆に強力なチームであれば成功確率の低いプロジェクトでもなんとかしてくれる事もあります。
成功確率の高いチーム・低いチーム
当たり前の事ですが、プロジェクトに見合ったタレント・スキルが不足していればそのプロジェクトは失敗する可能性が高くなります。
しかし、日本の会社において完璧なチームでプロジェクトを開始できる事がどれだけあるでしょうか？
そもそも社員のタレントやスキルをしっかり把握できている事も少ないかもしれませんし、そのプロジェクトの難易度を正しく評価できているかも解りません。
例えば、アジャイル開発のプロジェクトを「やりながら考えるプロジェクト」と考えているようだと成功確率は低くなってしまいます。アジャイル開発だからといって重要な部分はしっかり決めておかないといけませんし、大事なのは「やってみて計画を見直すプロジェクト」である事です。
他にも、評価基準も定めていないのに、最初は失敗してもいいよ、なんていう上司を信じない方がいいかなと思います。きっと手のひらをくるりと回されることでしょうから、回させないためにも評価基準を決めておきましょう。
すみません脱線しました。
成功率を高めるのであれば、プロジェクトにマッチしたチームで行う必要がありますが、スタート時にはそうなっていない可能性があり、そうなると人を集める事もマネジメント及びチームビルディングの一環になります。
会社が適切なメンバーを与えてくれるとは限らないという事から始めたいと思います。チームは与えられるものではなく作るものだと個人的には考えておりますが、自分でメンバーを選定した方が成功確率を高められる可能性があります。
人材の集め方
やりたい事をやるために、チームに人が足りない、必要なタレントやスキルが足りないといった事は多々あるかと思います。
このとき、「人が足りないからできない」ではなく、どうやったらできるのかを考える事がマネジメントの仕事だと考えています。
人が足りないなら、雇えばいいのです。プロジェクトの予算がどの程度なのか見積もっていると思いますが、見積もる際には、労務費をどの程度積んでおくべきか考えるかと思います。
このとき、与えられたメンバーが不足している場合、根性や気合でどうにかしようと思わずに、様々な方法で人材を集めましょう。
社内調整
必要なタレントやスキルを持つ人をアサインしてもらえるように調整してみましょう。（できる・できないではなく、調整したという事実が重要です。後述します。）
外部委託
外部に信頼できる受託開発の会社や、オンサイトで支援してくれる会社、派遣、アルバイト、クラウドワークスなど、さまざまな方式で人を集められるか検討します。（できる・できないではなく、どういった方法がとれるのかを知る事が大事です。）
中途採用
人事に必要なタレント・スキルを持つ人を中途採用してもらえるか交渉します。上司を通じてでも直接でもかまいません。（できる・できないではなく、採用にどこまで関わる事ができるのか知る事が大事です。）
上記のすべてが全滅（会社が認めない、権限がないなど）だったとして、なぜできないのかの情報が集まるはずです。どの手法が使える・使えない、何かハードルをクリアすればできる事もあるはずです。
ほとんどの場合、できない事はありません。世の中でそれをやっている会社や人が居るのですから、関係各所のやりたくない理由を取り除く事をすれば良いのです。こういった事は人事の仕事だとか言わずに、積極的に人事と話してみるだけでも情報が得られるのでプロジェクト成功のためだと考えるのも一興です。
わざわざそんな苦労をしてまで仕事をする人はそう多くはないかもしれませんね。しかし将来のための苦労はした方が、多くを学ぶ事ができるので、結果として明るい未来が待っているので、私は率先して誰もやっていない事をやる事をお勧めします。
そして、誰もが思いつくけど面倒な調整事はやったという事実があれば、できなくても次のステップに進む事ができます。調整ができなかった原因を取り除く大義名分になる場合や、予算の増加の理由や、スケジュール延長の理由です。
世の中、あまり杓子定規にやるのは良くないのですが、大義名分があるのとないのとでは物事の進み方が違うので、何か調整を行うときはそれは後々のアリバイ作り・証拠固め・伏線だと思って面倒でもやっておきましょう。
諦めなければなんらかの方法で人は集められます。もしどうやっても集まらなかったら早めにギブアップしましょう。ギブアップの仕方にもよりますが、何を諦めたのか明確にすることもマネジメントの仕事です。
情報を共有しマインドを共有する
今回はチームビルディングの最初からになりますので、様々な方法でなんとか人は集めたとします。集めたとしてもそれだけでは十分ではありません。チームとして動ける状態にしなければなりません。
チームが成果を出すために必要な事は以下の通りです。
目的・ゴールを共有する
チームのメンバー全員に何が目的でゴールなのか、それまでのマイルストーンを含めしっかりと共有します。これは１度や2度説明するくらいで共有できたと思ってはいけません。折に触れて、何が目的でゴールだったか確認し、必要に応じて変更が発生すればその理由も含め都度、しっかり定期的に共有しましょう。
役割分担・責任範囲を明確にする
メンバーそれぞれに期待する役割や責任範囲を明確にしましょう。フォローを期待する場合は、誰が誰をフォローするのかも含めて決めておいた方が最初はスムーズだと思います。ただし、範囲は狭くなりすぎないようにメンバー同士がフォローしあえる状態を意識します。
ものごとの決め方・修正の仕方を共有する
あらかじめ決まっていない事を決めるプロセスを明確にします。例えば技術選定が終わっていない、仕様が固まっていない、実施するプロセスが明確になっていないなどなど「決めなければいけない事」が決まっていない場合、どのようにして決めるかを話し合っておきましょう。
誰が決めるか、どうやって決めるか、多くの課題は決まっていない事がまず課題で、次に決めた事が間違っていることが課題になります。間違っていたら修正すればいいのですが、修正もどういうプロセスで修正するかを話し合っておくと後々スムーズです。
なんだか、チームビルディングの話に聞こえないかもしれませんが、ここからチームビルディングは始まっています。これらをすべてマネジメントを行う人だけで考えていても意味がありません。共有して初めてスタートラインに立てます。
チームに共有し、チームが自発的にこれらを意識しながらプロジェクトを進めてくれないと、何もフィードバックを得られないのでプロジェクトは失敗へと進んでしまいます。
私はチームビルディングはチームを作る事・育てる事にフォーカスしすぎてはいけないと考えており、そのチームが成果を出し続けるためのしくみを作り、メンバーのマインドの共有が最も重要だと思います。
人には個性があり、それぞれの考え方や意見があるかもしれませんが、プロジェクトを成功させるためには、自分の意見を押し付けるような人はプロジェクトを崩壊させかねません。前回の記事でメンバーにもリーダーシップが必要というのはこういう面でも関わってきます。
リーダーシップとは、意見を押し付ける事ではなく、意見を聞くことと、説得力のある意見を伝える事だと思います。なので、メンバーにリーダーシップがあれば、リーダーの意見を聞く事ができますし、説得力のある反論もしつつ、最終的にはチームのためにモアベターな行動をしてくれることでしょう。
あくまでプロジェクト成功のためにベストとはいえなくてもモアベターな方法で進めるべきなので、仮に意見衝突が起きてもどういうプロセスでそれを解決させるべきかのマインドを共有化しておくのが最初にチームビルディングで行うべきことです。
マインドの共有化できないメンバーの取り扱い
チームにおいてマインドが共有できないメンバーというのも存在しうると思います。人は発言や行動をある程度コントロールできますので、本当は思っている事と違っていても周りに合わせる事ができますので、一見マインドが共有されているように見えても、本心から思っていない場合があります。
本心から思っていなくても、ずっと発言や行動をコントロールしてプロジェクトに貢献してくれればありがたいのですが、やはり無理は長続きしませんので、何かの拍子に本音が出てきます。
失敗しそうになると、「実はこうなると思っていた」とか「自分の責任ではない」といった発言や行動です。
これは仕方の無い事で、本人にも自覚がない事も多いため、人の本質を見抜くのは本当に難しいのですが、プロジェクトがうまく行っていれば恐らく問題にはならないと思いますので気づくのも遅れます。
こういうメンバーは責任のある立場になってはじめて、「あれ、こんな人だったのか」と思わされる事がありますので、一度責任ある立場をやらせてみるのはリトマス試験紙になります。
ただし、こういった人の取り扱いは、責任ある立場に置き続けない事だと思います。メンバーとして成果を出してくれるのなら問題ありませんが、そういう他責にしがちな事を無自覚な人に限って高い地位を求める傾向もありますので、マインドが共有できないタイプの人はあまり責任や権限のあるところに置くことは避けた方がいいと思います。
責任ある立場に置く前に、そういった人は何かと周りを下げて、自分を上げる傾向があるので注意してみておいてください。
本人の理屈やある角度においては正しそうな事、人の責任は追及するが自分の責任は言葉上でだけ反省しているような発言をする人には注意が必要です。このタイプは世の中に一定数居て、実務面は優秀な事が多い反面人間関係でトラブルを起こしやすいと感じています。
メンバーの選定基準
メンバーの集め方については列挙しましたが、どのように選定すればいいかについて最後に補足しておきます。
ここまでの流れで解りかもしれませんが、「マインドを共有できるか」は非常に重要なファクターだと思っています。
会社や組織やチームは例えるなら大きさにもよりますが、船団だとイメージしてみてください。マインドが共有できていないと、海を渡って日本からアメリカを目指していたのに、一部のチームだけインドに行ってしまったりアフリカに行ってしまう可能性があります。
行先が違う以外にも船の上で争いを起こして沈没するかもしれません。船頭が何人も居ると、気づいたら富士山のてっぺんに船を運んでしまっているかもしれません。船長も船員もそんな事を望んでいないのにも関わらずに、一部のマインドが共有できない人が居る事でこういった事が起きやすくなります。
既にそういう人がチームに居る場合は、一緒にオールを漕ぐ分には問題ないのですが、それすらできない場合は船を降りてもらうしかありません。
マネジメントの役割としては、もしかするとオールを漕ぐか船をおりるかの選択をさせる事は大事な仕事の一つなのかもしれませんが、これも非常に日本では難しい事ではあるので、選定時にマインドが共有できそうな人を選定しましょう。
よくこういう事を言ってしまうと、多様性を排除しているのではないかと気にする人も居ますが、そもそもマインドが共有できない人自身が、多様性を認めていない発言や行動をする可能性が高いのでそれを未然に防ぐためだと考えればよろしいかと思います。
一緒に働く人は選んで良いですし、自分も選ばれる側でもあるので、お互い選ばれるマインドを持ちましょうね。
まとめ
マネジメントにおいてリソース管理は非常に重要ですが、特に人に関しては他とは比べられないほど重要です。
ビジネスによっては、AIやロボットによる自動化や、マニュアル化や機械化による半自動化によって、誰でもできる仕事というものも存在しますが、それであっても一緒に働く人とはマインドを共有できないと働き続けるのは難しくなってしまいます。
タレントやスキルは現代においては、ある一定レベルまではアウトソーシングも可能ですし、AIの補助により下限を押し上げるのは簡単になってきました。
問題は、タレントやスキルの上限をいかに上げるかが、プロジェクトの成功のみならず成果の最大化には重要になってきています。
今回は触れませんでしたが、そこで重要になるのは育成です。今の時代においては自己学習が重要になってきていますので、マネジメントでできる事は学習機会の創出なのかもしれませんが、次回はそのあたりを中心に記事にできればと思います。
では、また。