チームが期待されている貢献を何かしらの形にするために何をするか

チームには様々なミッションが設定されている。プロジェクト（業務）の目的を達成することは勿論、それ以外にも技術力向上や後進育成、ビジネスの創出などそのチームごとでのミッションこそ、チームが組織の中で存在する理由でもある。

この、チームが組織の中で存在する理由の大切さ、意味を理解していないエンジニアが多い。アサインメントされたからそのチームのメンバになったくらいにしか思っているのが普通なのかもしれないが。

そういった背景もあって、年度始めの目標設定の際には、

「なぜ、私たちのチームはここに存在するのか」

を改めてチーム全員で再認識することにしている。そのうち忘れてしまうかもしれないけれど、マネージャとしては繰り返し存在意義は刷り込むことは必要だし、これはある意味、プロジェクト憲章の読み合わせのようなものだ。

全ての活動はチームの存在理由に帰結する。繰り返すがチームの存在理由は、そのチームに属するコストを掛けてもビジネスとしての貢献を期待されているからだ。

チームの活動はチームメンバに考えさせる

考えさせる、と書いている時点でまだ道半ばだと思う。メンバに投げかければ、口ではわかった風な答えが返ってくるが、マネージャが考え期待していることとは程遠いのは、伝える側の期待するイメージとメンバの確固たるアウトプットを完成させることに訓練されているエンジニアの性かもしれない。

プロジェクトや事務処理的なことであればそれでいい。しかし、それでも困ることもある。例えば、ビジネス創出など、ゴールを設定できない目標に対しては。

それであっても、最初はチームのメンバに１年間の活動の中で何をしていくかを考えてもらう。

チームが期待されている貢献を何かしらの形にするために、何をするか。

チームに期待する活動を一旦は制約をかけないで何をするかを話し合ってもらうと始めるのが決まり切ったようにブレストを始める。

ブレスト、まーブレストの形態を取るよねと思うが、始めたかが悪い。思いつくことをあげるのはいいが、スライドやホワイトボードのペンを持っている人が思いつくことを書き始めてしまうから始末が悪い。

チームに期待されていることを何かしらの形にするのであれば、ブレストをスタートする前に、チームに期待されていることは何かを確認した上で始めなければ単なる思いつきレベルでしかないし、仕切っているメンバが自分で書き始めては、周りのメンバは仕切っている人が書き出すことだけを見ているだけ、になってしまう。

そういったところは、指摘しながら、全員が実質的な意味合いで参加して、チームの存在理由の軸から外れないように軌道修正させつつ、貢献の仮説のアイデアを1つでも見つけて欲しいと思っているが、なかなかスピード感が合わないことろは、日頃、どれだけチームを考えているか、そのリソースの分だけ違うのだろう。