心理的安全性を確保した組織とプロジェクトチーム作りの経験から考えること

心理的安全性についてのスライドとして、よくまとまっていると思う。

 

speakerdeck.com

 

ブコメにもあったが、同じように1つだけ気になるところがある。

 

※ただ、これらの行動を起こすメンバーは注意しても改善しない 事は多々あるので、むしろ採用しないように気をつける事の方が重要

 

これから迎え入れる人についての対応としてはそれで実現できるかもしれないが、チームに自分自身が入っていく場合はどうだろうか。これは、チーム内に既に境界を超えてくるメンバがいる場合である。位置付けとしては、引用しているケース以外の場合にあてはまるだろう。

もしくは、チームのリーダになったとき、そのチームの中に境界を超えてくるメンバがいたらどうすればいいのだろうか。これは、境界を超えてくるメンバとチームではなく、チームとリーダ、またはマネージャとロールを変えた場合のケースである。

 

ある部門に異動したとき、配属になったチームはいわゆるコンサルおじさん達がはびこるチームだった。そこに、異質のプロマネ志向のエンジニアが参画した。配属後にどんな仕事をしているか風景を観察していると、コンサルおじさんやリーダのエンジニアが中堅や若手にいわゆるマウントをとる光景が目についた。

今で言えば、心理的安全性なんて微塵もないのである。第一、当時は心理的安全性などという言葉もない。

想像して欲しい。オフィスで、近くの席で、コンサルおじさんやそのおじさん達に訓練されたリーダが中堅エンジニアを捕まえてできていないことを延々と指摘する風景を。

誰でも思うだろう。出来ていないことを何度もいっても出来るわけがない。だったら、そのマウントを取っている時間を一緒に片付けたほうがお互いに幸せになれる。

対策

このケースでは、次の対処を行った。コンサルおじさんやリーダのエンジニアに雑談を持ちかける体で話す機会を作る。

困っていることがないかを尋ねると、

『進捗がいまいちだ。中堅エンジニアの出来が良くない』

などと自分が困っていることをいう。それはそうだ、プロジェクト上の障害を取り除き、楽をして進めたいと思うのは誰でもだろう。

ひと通り話を聞いて、でも一つひとつにいちいち策は述べない。ただ、こんな話をした。

あなたが中堅エンジニアと同じ年齢だった頃、今、中堅エンジニアに求めている仕事を求めているクオリティで出来ていたか。

大抵の人はここで黙り込む。なぜなら、今の自分のレベルで物事を要求しているからだ。

あともうひとつ。

今ここで中堅エンジニアを育てないとずっと苦労するのはあなたではないか。期待する行動を取れるエンジニアに育てれば、次は少し楽に仕事をできるのではないか。

1つ目の問いかけはかなり有効である。それに自分はできたというケースも2つ目の問いで救うのである。嫌だといったら、それは組織の中でのミッションである後進育成をないがしろにしていることになるのだから。

 

次は、ロールを変えた場合である。これも以前のエントリにエッセンスを書いた。境界を超えてくるメンバがプロジェクトチームにいた時にどう対処するか。

対策

プロジェクトルールを作る。これはチームの前で、定着するまで繰り返す。そしてルールをチームメンバで変えていく。

  • チームのルールを守っている限り、あなた達を守る。ただし、ルールを破ったら一切、守らない。
  • 本番環境での作業前での失敗は不問である。その前にわかったのだから褒められることだ。設計書、手順書、を直そう。
  • 作業での失敗は、作ったプロセスにある。人にではない。プロセスを直さなければ再発するのでおかしいと思ったら些細なことでも指摘すること

この考え方が定着すると勝手にチームが動き出す。なぜなら、失敗してもプロセスを直せばいいし、おかしいところを言わないと失敗するかもしれないからである。

それで、これがどうしてマウントを取る、境界を超えてくるメンバをなんとかしてくれるのかということであるが、マウントを取りようがないのである。

なぜなら、人対人の関係が存在しないからである。必ず、人対コト、になっていることに注目してほしい。この環境を作りたくて、チームのグランドルールとも言えるルールをメンバが変えていくことをよしとしているのである。

 

どちらも共通しているのは、仲間を大事に扱え、ということだ。その仲間がいなければ、仕事にならないのだから。 

 

 

プラレール S-11 サウンドN700系新幹線

プラレール S-11 サウンドN700系新幹線