いいチームとミッション・インポッシブルと初めの段取り
いいチームとはどんなチームか？
改めて自分なりに考えてみた。
チーム構成というよりはどんなチームで仕事できると個人としても嬉しいか、
お客さんとしても嬉しいかという観点で考えた。
個人的には
「このチームにいたら成長できる」
「チームワークがよくて楽しいと感じる」
というのは二義的で、
まず満たすべきは
「それぞれが自分なりのバリューをだせて、それがカチッとうまく噛み合い、
チームとしてのゴールを達成できる」
ことだと考えている。
その中でゴールの達成感、
それに対する「自分もココで貢献したぜ」という寄与感を感じたときに
いいチームで仕事したと感じる。
それを達成するためには当然ながら
・ゴールはどんなものなのか
・それぞれのタスクがどう構成されて、ゴールが達成されるのか
・各々はどのタスクを担い、どんなバリューにつながっていくか
を知っていないとできないし、
それを知っていると
・誰かがコケればそれを別の誰かがフォローできる
・自分のタスクと他の人のタスクのつながりがわかるので、情報・タスク連携できる
・自分のタスクと他の人のタスクのつながりがわかるので、
全体で滞りなくタスク進めるにはどこを優先すべきかがわかる
ことになりチームがうまく進む。
これまでの自分の経験を振りかえって「いいチームとは」を考えてみたが
自分が参画したプロジェクトでいいチームが思い浮かばなかった。
（思い出せなかっただけかもしれないが）
これを考えるに至っては最近見た
「ミッション:インポッシブル/ゴースト・プロトコル」の
イーサンの率いたチームを思い出して考えていた。
唯一それに近かった自分の経験として思い至ったのは
過去に人事システム再構築の要件定義フェーズで
自分がTLとしてアプリチームをリードした時。
その時は、ゴリゴリのロジック派、コミュニケーション強者、
ある程度システム素養がある弟肌がメンバーとしていたのだが、
・誰かがコケればそれを別の誰かがフォローできる
・自分のタスクと他の人のタスクのつながりがわかるので、情報・タスク連携できる
というのができていたし、それぞれが得意な分野を担当できていた。
まず尖兵としてロジック派が重要な議論を実施できるようフォローし、
その内容を汎化してチーム内に展開してもらう。
それからお客さんとの折衝が必要な領域をコミュニケ派が、
システム化が難しそうな領域を弟肌がリードしていった。
タスク溢れそうなときには手が空き気味の人がフォローに入る。
それだけの状況共有と信頼感があった。
コレに対してその後続の開発フェーズ以降のチームはいまいちだった。
なんとなく各自作業者ベースでタスクをこなし、お互いには無関心、
ひたすら手を動かす、自律もモチベもない「軍隊」の印象が強い。
何が違うかと考えたが、メンバーが増えていく中で初めの段取りでイマイチだったことが思い当たる。
・プロジェクトの顧客内でのビジネスインパクトはどんなものか、
プロジェクトがどういう使い道をされどう価値を生むか
・プロジェクトのゴールは何か、今のフェーズはどんな段階にあたりどんな重要性があるのか
・ゴール達成のために各タスクがどう構成され、
他チーム含めどう全体としてつながり、どんな意味を持つのか
・各自にどんなことをお願いしたくて、どうあってほしいのか
をちゃんと説明できなかったし、たぶんその段階で自分も腹落ちし言語化できる状態でなかった。
そしてメンバーが徐々にパラパラアサインされて入れ替わっていくため説明をどこか怠っていた面がある。
「WBSがここにあり、こういうタスクをやってほしいから。期日はこれで」
「Outputイメージはこんなかんじ想定。あとはよろしくやって」
という仕事の依頼方法になってしまっていた。
あとは自分はそのままずっといたので説明が必要、という感度が落ちていたのだと思う。
ゴールに対する重要性とか、
その後にどんなタスクがつながるのか共有されてないから何に注力すべきか、
自分のタスクをさておきフォローすべきなのか、
そもそも自分がプロジェクト全体に対してどんなバリューを出せているのかを
感じ取ることができなかったのではないか。
アサイン時に本来上記のような話をすべきなのだが、そこまでの意識がなく
過剰な期待値やただの理想をうわっつらだけで話していた気がする。
こういった初めの段取りがいいチームをつくるための1つの条件となるののでは？
