The Dragon Scroll

Be just and fear not.

チームの脳を1つにしない。

発端

プロジェクトマネジメントの勉強会というか事例発表の場を、開きたいと思ったのは、2009年のことで、
とあるコミュニティの飲み会で、幹事のkentさんと話をしていたときだった。
kentさんとの関係は4年以上までに遡る。多様な武器を御持ちのkentさんだが、彼の御仁の本業であるプロマネ
についての持論は、じっくりと聞いたことが無かった。その場を、DevLOVEコミュニティで用意することが出来た。
7月27日 【DevLOVE】PM/PLイベント 「プロジェクトマネジメントは愉しい!」(東京都)

苦境に陥ったときに始めるプラクティスは、チームの外には無い、中にある。

そもそも、ビジネスの制約や前提によりプロジェクトが苦境からスタートすることは、少なくない。
何らかの事情で、納期が短い。要員が足りていない。それらを、織り込み済みでプロジェクトを始めることがある。


苦境に陥ったときこそ、チーム固有の奇妙なプラクティスがいきてくる。
そのチーム、その状況に適したプラクティスは、自分たちで発見するしかない。
外から持ってきたプラクティスをそのまま自分たちにあてはめようとして、上手く行かなかった経験は誰でも
やっていることではないだろうか。では、外に転がっているプラクティスを学ぶことは全く無駄なのか、
というとそういうことでもない。
チーム固有のプラクティスを生み出すためのヒントや原型こそ、コミュニティや勉強会で掴むことが出来るはずだ。


ここで、私がかつて経験した、とあるプロジェクトを例に考える。
ある事情から、リーダ不在が続いたチームをプロジェクトの途中から引き継いだ。チームは前進感の無い仕事の状況
に疲弊していた。何を始めるべきか。


例えば、コミュニケーションを増やすことを狙いとした朝会が、有効なチームもある。
一方、朝会を意味をなさないチームもある。指示伝達をするだけの場になり、静まりかえる朝会。
最初にやることはプラクティスを輸入することではなく、そこにどういう課題が起きているのかを見ようとすること、
すなわち、観察と対話のはずだ。メンバー、顧客、そして、その関係性。それから当然、仕事の状況。
例えば、チームの中で誰の声が大きいかを眺めてみる。彼女はどういう動機でこのチームを引っ張ろうとしているのか。
彼女に何が起きているのか。何を心配に思っているか。
あるいは、メンバーとメンバーの間にどのようなコミュニケーションが発生しているか。関係性が悪い箇所で
着目するべきは、そこに仕事上の課題が起きているのではないかということ。
あるいは、顧客は我々をどう思っているか。多くの言葉を引き出してみて、口調の変化を見る。何か腹に
据えかねていることは無いか。
あるいは、どの期間にどの仕事をしなければならないかことになっているか。それに対する現状はどうか。
そもそも、その仕事の定義は誰が行ったのか。その前提は、変えられるのか。
チーム、プロジェクトの状況によって細かいポイントは異なるだろうが、始めることは観察と対話。

チームの脳をひとつにしない。

kentさんの話にあった、次に起こりそうな問題とは何か、というシンプルな問い。
この問いが、苦しい状況でいきてくる。この問いが出てくるかどうかで、チームの脳がどこにあるかがわかる。
チームの脳をPMやPLだけにしてはいけない。1個人の経験や知見がチームの限界になってしまう。


なぜ、我々はチームで仕事をしているのだろうか。
ちょうど、デザイン思考のワークショップの例がある。なぜ、チームでワークをするのか。
デザイン思考、人間がその最高の材料。 - papandaDiary - Be just and fear not.
稲作たかだか60回の話がある。1個人が1生かけても経験できることは限られてくる。
「まだ60回しか稲作したことがない」という含蓄ある言葉 - サンフランシスコ出羽守手記(masayangの日記
確かに、個人の経験量には頭打ちがあるかもしれない。
しかし、複数人の経験を集めることができれば、チームの総体としての経験を拡張することできる。
コミュニティや職場で、ハンガーフライトしよう。 - papandaDiary - Be just and fear not.
チームの苦境を救うのは、プロジェクト管理者によるルールブックに従った管理ではない。
チーム自身が持っているもの、すなわちチームの多様性を活かせるかどうかだと思う。
チームが多様である以上、そこに生まれてくるプラクティスもまた、そのチーム自身のものだ。


kentさんの話には共感できるところがたくさんありました。
ご多忙にも関わらず、素晴らしい準備とプレゼンをありがとうございました。