経験からのマネジメント論「認め合う関係の構築」
はじめに
「プロジェクトは生き物」とよく言われます。PMBOKでも「同じプロジェクトは二つと無く『必ず異なるものだ！』と思いなさい。」（要約）と書かれています。その一因となっているのが「人的資源」です。十人十色という言葉の通り人はそれぞれ異なる性質を持っており、同じ人でも時と場合で性質が変わるため、非常に不安定なものです。
この不安定な要素について、私がどのように考えて行動してきたのか？を書いていきたいと思います。
チームビルディングの大切さ
マネジメントというとタスクやスケジュールの業務管理をイメージをする人も少なくないのではないでしょうか？「そんなことないよ」という声が聞こえてきそうですが、その中にもチームビルディングが出来ていない人もいるのではないでしょうか？私はこれを怠っている人を数多く見てきました。
また、チームビルディングと一言で言ってもいくつかの要素がありますが、その中でも基礎となる「信頼関係」つまり「認め合う関係」を構築するために実践してきたことをまとめていきます。
注意！
既に記載している通り、人とは不安定なもので、一定のやり方で必ず効果が出るものではありません。その時の状況に応じて変化するので、日ごろからよく観察しておけると良いですね。
◆ポイント１：お互いの役割を定義する
チームとして活動する際、まず初めに「役目」や「役割」を明確にしておきます。そして全員で一緒に役割を定義しておきます。もしチームに新人が居ても一緒に行うことをオススメします。
役割の定義は、誰が何を担うか？を整理していく事を指していますが、その要素や粒度はプロジェクトによって異なります。
なお、最初に全てを定義することは難しいので、定例などのタイミングで認識合わせをした際に都度設定していくと良いです。
定義するべきことの例
〇 チーム内のポジション（役割名）
〇 役割ごとの日々のアクション
例：毎朝10時に朝会のために召集します
例：会議のファシリテートは〇〇がしてください
例：〇〇を行う場合は必ず私に確認を行ってください
例：〇〇は個人の判断で行ってください
開発チームにおいては、開発プロセスでの役割も定義しておくと良いです。
これはバリューストリームマッピングっぽく開発プロセスを可視化し、工程ごとにメンバを配置したものですが、これを行うと作業間での連携が把握できるのと、メンバ自身が業務プロセスを理解し能動的に行動しやすくなります。つまりメンバ同士が助け合いやすい環境を作れます。
◆ポイント２：上下関係を主張しない
ポイント１で役割の定義について触れましたが、役職あるいは役割というのは、責任と権限を設定するためのものであり、上下関係を示すものではありません。マネージャ、リーダー＝偉い人というわけではないということを肝に銘じています。「お互いを認め合う」ためには、長所を伸ばし合うことと、短所を補い合うことが大事なので、上下関係や優劣を主張するのではなく、お互いの役割を理解したうえで、もし手が足りていない場合に助け合えるようにしておきます。
具体的に意識しておくこと
〇 偉いかどうかじゃなく、定義した役割かどうかで考える
〇 誰を相手にする場合も敬語を使う（丁寧な言葉を使う）
〇 メンバそれぞれの得意としていることを把握する
〇 自分の弱さを隠さない
〇 相手の弱さを否定しない（不必要に「ここがダメ！」と言わない）
〇 メンバからの意見は肯定してから考える
なお、これは子育てにも似ていると思っていて、子供を相手にするときに「自分は親だから」という感覚で話すと伝わらない事が多いです。まあ子育ての話はさておき、「一緒に成長する」気持ちで接しているとフラットな関係を保てます。
◆ポイント３：雑談する
これは最近よく言われることですが、仕事の話しかしない関係だと信頼関係は築きにくいです。（出来ないとは言っていない）
信頼関係を築くためには、相手を知り、自分を知ってもらう必要があるのにビジネスの話だけで行うのは効率が良いとは思いません。商流においての信頼関係で言えばビジネス上の会話だけでも良いですが、チームビルディングにおいては少しでも早く関係を構築する必要があります。
たとえば、打ち合わせを行う場合に5分～10分ほど雑談しても良いと思います。あまりダラダラと話してはいけないので、自分の中で目途を定めておく必要があります。また、話す内容については個人的なことよりも、時事ネタを交えた社会性のある内容が良いです。エンジニアなら技術のトレンドについて語るのも面白いです。
◆ポイント４：チームの時期を理解する
チームビルディングを担う人は必ずタックマンモデルを理解しておくべきです。いや、人類、全員必修です。
チームはどの時期かでアプローチが変わります。ざっくり言うと以下のような感じです。
〇 形成期
・役割と権限を明確にしておく
・チーム内のルールを認識してもらう（リーダーの重要な役目）
・お互いを知るために積極的なコミュニケーションをとる機会を作る
・新しく編成されたチームだけでなく、要員が追加された場合もこれに該当
〇 混乱期
・とにかくヤバい、間違いなくモメる
・対立とは「正義 vs 正義」なので、リーダーはどちらも否定しない
・課題を言語化して、チームで解決方法を設定する（振り返りとか）
〇 統一期
・チーム運営の課題を出してみんなで解決方法を考える
・朝会や日報などで情報の通気性を高める
・ナレッジ共有の文化を作っておく
〇 機能期
・見守る（多少の問題も許容する）
・意見や行動を否定しない
・メンバが更に成長できる方法を考える
タックマンモデルを用いたチームビルディングにおいて、最も重要なことは「本人たちに状況を理解してもらうこと」だと思っています。常日頃から伝える必要はなく、特に混乱期で対立することがあれば、1 on 1で伝えてあげるようにしています。
◆ポイント５：「信頼できる」を作る
信頼するということを根拠も無くするべきではないです。信頼するためには、それに足る根拠が必要となります。もし、根拠も無く「信用している」と言うマネージャが居たら、恐らくその人はただの無責任な人です。
信頼とは作るものです。信頼の作り方は簡単で、人はそれを計画と呼びます。PMBOKでも計画が最重要だと言っています。マネジメントの勉強をしていないと計画＝スケジュールと勘違いする人も多い印象ですが、重要なのはスケジュールではないです。
私が計画を作る際に必ず整理しているのは以下になります。
〇 タイトル・概要
・プロジェクトを簡潔に言語化する
〇 背景
・なぜ必要だと思われるのか？を言語化する
〇 目的・ゴール
・何を達成したいのか？（目的）を言語化する
・どうすれば成功なのか？（ゴール）を言語化する
※目的とゴールは混同されやすいですが異なるものです
〇 制約・前提
・行動するための前提条件を言語化する
・行動する際の制約を言語化する
※混同しがちですが、混同しても問題無いです
検討や行動の判断材料となるものが言語化されれば良いです
〇 マイルストーン
・いつまでに何が出来ていると良いのか？を言語化する
※スケジュールではなく、行動の基準になるもの
〇 コミュニケーション方法
・どのツールを使ってコミュニケーションをとるかを言語化する
・どのタイミングでコミュニケーションをとるかを言語化する
PMBOKでは「プロジェクト憲章」と呼ばれるものに近いですが、あまりガチガチに作っても時間がもったいないので、その都度で必要と判断したものに限定して書くようにしています。
大事なのは濃さではなく、メンバの意見や行動を適切に出来るかどうかです。信頼するため、失敗しないための土台を構築しておきます。もし任せた人が間違いをおかしたり、「そうじゃない」と横やりを入れたくなった場合は、この土台が不足しているのでもう一度話し合います。
◆ポイント６：アウトプットを制限しない
もし成果物が決まっているならば明確にしておきます。例えばドキュメントを作らなければいけない場合、そのワイヤーフレームやフォーマットについて先に認識を揃えておきます。これを行っておかないと無駄な修正が増えると同時に信頼関係は失われていきます。
成果物において大事なのは、その成果物が目的を果たしているのか？にあるので、前項で書いたような「何のために何をするのか？」を明確にし、それが達成できているかどうかで判断します。もし目的を達成できているならフォーマットなどにこだわる必要も無いですし、ましてや誤字脱字があっても気にしないことです。ちょっとしたミスは確認ついでに代わりに修正してあげましょう。
やっちゃいけないこと、ダメ絶対！
〇 アウトプットイメージを持っているのに認識統一しておかない
〇 目的とは異なるミスばかり指摘する
〇 必ず自分が正しいと思いこむ
これらはチームのパフォーマンス低下、学習の疎外に繋がるため本当に注意が必要です。
◆ポイント７：お酒に頼らない
あくまで私の経験によるものですが、そもそも「お酒の席じゃないと腹を割って話せない」なんてことはありません。サッカーや野球などのスポーツでも良いし、ゲームや映画鑑賞でも良いです。お酒を抜きにした食事でも良いし、デザートや紅茶でも良いです。もちろん皆がお酒が好きならお酒でも良いと思います。
余談ですが、私はゾンビ映画とスプラトゥーン２が好きです。
その他のポイント
他にも意識している事は沢山ありますが、今回はここまでにしたいと思います。このままだと書き終わる気がしないので。
まとめ
認め合う関係を構築するために意識することは以下になります。
〇 役割を定義する
〇 上下関係を捨ててフラットに接する
〇 雑談を利用してコミュニケーションを活性化する
〇 チームの時期を理解する
〇 信頼するための土台をつくる
〇 成果物の評価を正しく行う
〇 自分本位なコミュニケーションを取らない
私は、時に真剣に時に笑顔で働ける環境を作れるように心がけています。せっかく一緒に働くのですから、「一緒に仕事できて良かった」と言ってもらえることが私の生きがいとも言えます。マネジメントの価値とは、認め合う関係を構築して、やりがいのある素晴らしいチームにするものではないでしょうか。
◆番外：どうにも出来なかったこと
ここまでチームビルディングについて私の考えを書きましたが、プロジェクトは魔物です。これまで、どうにも出来なかったこともありました。番外編として書いておきたいと思います。
ケース（１）：何故かめっちゃ嫌われてる
チームの編成当初から、なぜだか解りませんが一名のメンバに嫌われていました。泣きながら配置換えをお願いされるくらいに。プロジェクト自体は問題無く完了しましたが、最後まで嫌われたままで真意は解らず。。。
「生理的に合わない」という言葉がありますが、まさにそれなんでしょうか。同じような状況にある人に言ってあげられる言葉は「諦めましょう」です。
ケース（２）：成果物のイメージが抽象的で作業が進まない
業務要件は明確でしたが成果物のイメージが全く解らず、作っては切られるを何度も繰り返しました。次第にメンバも疲弊していき何が正解かも解らないまま残業時間だけが増えていました。
一番厄介だったのは、目的を達成するために他チームとの意思疎通を図ろうとした際、そんなことするなと言われたことです。
目的の達成ではなく、特定のアウトプットを求められており、そのイメージは共有されていない。効率化が求められていない現場では違うアプローチが必要なんだと思います。