受け身なエンジニアからリーダシップを引き出すチーム運営

マネジメントは言うのですよ、全員がリーダシップを発揮しよう、と。まあ、そうですねとしか思わないので否定するわけでもなく、ただ、当たり前すぎてスルーする方向で。

前にも書いたし、よく言われていることはリーダシップという人の数だけリーダシップの概念があるよ、というものです。300人の人がリーダシップは必要だ、というならリーダシップの概念も300通りあるよ、ということです。

ステレオタイプ的な体育会系のリーダシップや映画で観る軍隊のリーダシップを思い浮かべながら、システム開発のチームの中でリーダシップを当てはめるとどんな光景が目の前に展開されるでしょうか。主将や隊長が大声で次から次へと指示を出すシーンだったりするのでしょうか。

さて、その場面に全員がリーダシップを発揮するシチュエーションはやってくるのでしょうか。いや、ないですよね、一方的なワンウェイのコミュニケーションだもの。

前提としてのリーダのポジション

全員でリーダシップを発揮することを目標とすると、チームの最終的な意思決定は誰がするのかは決めておく必要があります。

これは、チームのメンバが同じ方向に顔を向かせたり、メンバの分を超えた意思決定をする必要がある場合に必要となることです。

チームの中で役割としてのロールは作るけれど、権限の階層的な上下関係はチーム内としても作らないということです。

ここが一つのツボです。これを従来の階層型にしてしまうと全員がリーダになるチーム運営のアンチパターンになります。

メンバは何かしら技術的な専門性を持っているのでチームに召集されています。え、何が得意か知らないけれど上から指示されてメンバを集めた、ですって。それでチームとして必要なスキルセットを充足できているんでしょうかねぇ。

あ、そうか。プロジェクトで適用技術が必要となるタイミングに合わせてメンバの技術習得の教育をして育てながらチームを運営するんですね、なるほど。

まあ、そんなケースは稀ですよねえ。

チームのメンバに漠とリーダシップを発揮してと言っても何でどんな行動を取ればいいかメンバの人数分だけメンバはそれぞれ勝手に想像しようとします。想像しようとしますが、大体はリーダシップを発揮した自分のイメージを持っていないのでイメージする前に考えることをやめてしまいます。

知らないことは誰も想像できませんから。

やったことがなければ、自分がどう振る舞えばいいのかさっぱりわかりません。これは人は経験したことをベースにしかイメージづくりできないからです。

であれば、普段行なっていることの意思決定が実はリーダシップだと気づかせてあげればいいのです。

リーダとは意思決定する役割です。これは300人がリーダシップを語っても300人同じ共通でしょう。

チームの中でのアクティビティで全員がリーダシップを発揮すると考えるとき、主将や隊長の振る舞いをイメージさせるのではなく、専門家としての知見を元に意思決定することをチームのリーダシップとして定義すればいいのです。

5人のチームで5人がそれぞれ専門性を持っていたら役割としてのリーダも技術的に詳しくない範囲もあるものです。そういう前提を置いたとき、技術的に専門が強いメンバが意思決定を導けばいいのです。

これなら、誰だってできるでしょう。何かしら得意な分野は持っているのですから。

このチーム運営は、調整型でもサーバント型でもないチーム運営のリーダシップです。みんなが実現したい、自立、自律したエンジニアとチームはこうした運営でないとなかなか実現できません。