初めにやるべきこと?
とりあえず、思いつく王道の答えを上げてみます。
目標を立て、役割を決める
リーダは、チームや組織をまとめるのが役割です。
また、組織で仕事をする利点は、個人では出せない成果を出せるところにあります。
全員が同じ目標を共有し、メンバーが自分の役割を認識することは
組織として動くうえで大事なことです。
メンバーの顔と名前を覚える
リーダでなくとも、これは社会人としてやっておいた方がよいですね。
自分に興味を持ってくれない人に対して、人は興味を持ちません。
ただリーダならば、顔と名前だけでなく、各メンバーの性格や職歴なども抑えておきましょう。
組織の問題点を分析する
リーダは、そのチームや組織の問題点を改善し、生産性を高める役割があります。
問題点を事前に洗い出しておくことは大事なことです。
これらは、すべてリーダとして大事な仕事です。是非やってください。
・・・しかし、これらの実務をこなしていても、
うまく組織をまとめられる人と、まとめられない人がいます。
やるべきこと、やってはいけないこと
ある組織で働いていたときの話です。
組織変更があり、新しくマネージャが赴任してきました。
それに対して現場の開発者は、多少の入れ替わりがあったものの、
人員の変更は、ほとんどありませんでした。
しかし、これは組織変更としてはよくある形です。
やってはいけないことをしたマネージャ
問題は、そのマネージャが初めにやったことでした。
それは、
開発者が部署内で公開していたレポートを非公開にすること
でした。
そして、そのマネージャは開発者たちにメールを送りました。
このレポートの公開は不適切だと判断しました。
これが私の考えです。
「でも、些細なことじゃないか?」と思うかもしれませんが、
私は、この出来事で「この人は、開発者たちの上に立つには不適切な人だ」と確信しました。
リーダになって初めにやるたったひとつのこと
私にとっての「リーダになって初めにやるたったひとつのこと」は、これです。
成果を示して、メンバーの信頼を得ること
リーダは、就任直後から様々な実務をこなさないといけません。
しかし、その目的は「メンバーの信頼を得るため」です。
ソフトウェアというロジックの塊のような生産物の開発であっても、
結局、仕事は
信頼関係で成り立っています。
そして、リーダの成果は、開発者の成果物のように明確ではありません。
リーダの方こそ、
信頼を得るための努力が必要なのです。
組織やメンバーは、リーダの所有物ではない
先のマネージャは、まだ新しい職場で成果も上げていませんし、
その職場で必要な知識に関しても、開発者たちに遠く及びません。
しかし、
自分の権限をアピールして、上下関係を示そうとしてしまったわけです。
部下やメンバーは、無条件で指示に従う存在ではありません。
また、逆にリーダを評価する存在でもあります。
リーダは組織の責任者であって、所有者ではないのです。
以前の記事「
主体性に保存則って働くのか?」でも書きましたが、
私の経験上、リーダの仕事への姿勢次第で、
メンバーのモチベーション、協調性、そして成果は大きく変わってきます。
いきなり指示を出すリーダや、一方的に部下に成果を求めるリーダがいますが、
まず、リーダが成果を示し、信頼を得てからでないと、
組織は力を発揮できないのです。
蛇足
蛇足ですが、本記事のタイトルは、以下の本から拝借しました。
この本は、ある職場の先輩が
「リーダとマネージャの違いって分かるか?」
と質問してきて、答えられなかった私に勧めてくれた本です。
この本の特徴は、本記事のような経験則が書かれているわけではなく、
膨大な調査やインタビューから、著者が客観的に導き出した答えが書いてあるところです。
なので新しい発見がありつつも、個人の経験則や、特定の職場に偏った話ではないので、
多くの答えが私にとっては腑に落ちるものでした。
「誰も思いつかなかった奇抜な考え」を提示するのではなく、
誰もがもやもやと答えを出せずにいた問題に明確に答えてくれる本
を名著とするなら、私の中では名著の一冊になっています。
記事を気に入っていただけた方は、クリックしていただけると励みになります。
↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓
