コミュニケーションがおかしいと思ったら仲が良い悪いを疑う前にすること

on


プロジェクトってプロジェクトマネージャのプロジェクトのスタイルで様々な運営がされていますよね。古いマネジメントスタイルなトップダウン、統制型でプロジェクトを運営するプロジェクトマネージャもいれば、チームメンバと協調を重視する調整型の運営をするプロジェクトマネージャもいるし、ここ数年はサーバントタイプのメンバのパフォーマンスを最大化できるように動くプロジェクトマネージャのスタイルを取るプロジェクトマネージャもいます。


不思議なことに、どのプロジェクトマネジメントのスタイルもプロジェクトとして成功しているケースもあるし、失敗しているケースもあります。なんででしょうね。新しいプロジェクトの運営のやり方なら旧来の統制型のプロジェクトの改善点が考慮されているでしょうから、よりうまくプロジェクトが運営出来てもいいのに。


こんなケースを考えてみます。統制型のプロジェクトの経験ばかりで育ってきたメンバは、期待されるスキルを持っていて指示されることはきちんと納期までに仕上げることができます。こういった経験を持っているメンバが新規のプロジェクトにアサインされたらサーバントタイプのプロジェクト運営をするチームだった。さてどんな問題が起きるでしょうか。


統制型のトップダウンのプロジェクトは公式には情報は組織の階層を通って伝達されます。言い換えると上から降ってくるわけです。自分から発信するときには上に投げるわけです。実務では同じレベルでの会合で横のつながりで共有されるでしょうが、それもドメイン単位の中でに限られます。ドメインが違うと公式な階層を通ってでしかやり取りされなくなります。


一方のサーバントスタイルのプロジェクトチームの運営では、メンバが自主的に協調しながら動くことを期待するのでプロジェクトマネージャはメンバが動きやすいような環境作りに注力するようになります。メンバは自分から必要とする情報を取りに行き、自分の仕様としていることを発信しる自律した行動を求められます。その上で情報は交換されることになります。


２つの違いは情報に対する接し方です。情報をリクエストして返ってくるのを待つ受け身なのか、自分から発信して取りに行くのか。さらに言えば、その取ろうとする情報を持っている相手であるフォーカルポイントの数も違います。


自分から動かなければ情報は手に入れられないし、自分から情報を発しなければ何を考えているかもわからないのは同じなのに。


これはシステムエンジニアとして慣れ育った環境に影響を受けて情報に接する姿勢が影響を受けてしまっているんです。だから、プロジェクトマネジメントのスタイルが変わると変わった先で受け身に見えたり、逆の場合はスタンドプレーに見えたりするんですね。


こうしたメンバの情報に対する接し方は経験というシステムエンジニアの背景を聞かなければわからないものです。プロジェクトチームを立ち上げて、コミュニケーションが悪く感じたらメンバ一人ひとりの情報に対する接し方の違いのギャップが原因で生まれているのかもしれません。


そういったときは、お互いの経験したプロジェクトのスタイルと好ましい情報の授受のスタイルをメンバに語らせてチームの他のメンバは情報に対してどのように接したいかを知る時間を取ることをお勧めします。全員の経験と情報接し方をチームで話し、今後はどのように交換するかを決めてください。