2回目の投稿。

できれば週2回は何かしら考えていることを書き出していきたい。続くかな。

昨日こんな記事を読みました。

この記事は、リーダーの下につく社員がリーダーを評価するための13の質問の内容について書かれています。詳しくは記事を読んでみてください。

そこの2番目の質問について。

2.　上司は「マイクロマネージ」するタイプだ（他の誰かが対応すべきことにまで口を出す）

マイクロマネジメントは、チームに対する信頼感の欠如を示している。マイクロマネージする代わりに、上司は基準を設定し、目標と目的を明示し、チームが成功するための環境を作り出す必要がある。チームは任せられることで力を得て、成長することができる。

これを読んで自分の経験をもとに感じたことについてさらっと書きます。

マイクロマネジメントは、自分で出来る人のやる気を削ぐ

この質問の通り、マイクロマネジメントは任せないマネジメントなので、リーダー側はやると細かく状況を管理出来るのでよいのですが、やられる側は自分の裁量を持てないので辛い状況に陥るケースがあります。

実際に私も前職でソフトウェア開発の5名程度のチームのリーダー業務をやったことがありますが、そのときはマイクロマネジメントをやっていました。

そのときは私が未熟だったのもありますが、かなり過密なスケジュールだったので（というか常に無茶なスケジュールしかなかった）、毎日状況を把握したり、やることに細かく指示を出したりしていました。

それはそれでちゃんとスケジュールどおりに業務が達成出来たので会社的には良かったかもしれませんが、実際に作業している人は面白くなかったかもしれないです。

最近は、自分を自分でマネジメント出来る人（セルフマネジメント）、もしくはそういった成長して欲しい人には、細かく指示を出したりはしないように注意しています。（というか今はマネジメント業務はやっていないです。(笑)　まあそれでも気をつけているという話。）

任せることでその人が自分で考えて行動するので成長につながるし、結果としてチームとしては大きな成果を生むと考えるようになってきました。

なので基本的にGoogleの記事には賛同しています。

例外的に全く業務がわからない人と働くときはマイクロマネジメントが機能する

ただ、全てが全てマイクロマネジメントが駄目という訳ではなくて、例外もあると思います。

さっき書いた前職のリーダー時に、常駐さんととして新しく入ってきたが仕事の仕方がいまいちわからない方がいました。

その方（Aさんとします）には、最初私以外の方がリーダーに付いていましたが、そこでは正直「Aさんはあまり仕事が出来ない」と言われて、私のチームに移ってこられました。

確かに最初はあまりほっといても進捗出ないなと思い、対策として何かを頼む時に一緒に考えるところまでやるようにしました。

ソフトウェア開発では、設計や実装（コーディング）という作業があるのですが、設計するときもどういった構成にすればよいかを一緒にミーティング形式にして考えて、設計書をその場で書き起こしたり、コーディングも書き出す前に参考となるコードを教えてまずは一番カンタンなところから着手してもらうようにしました。（マイクロマネジメントというか、寄り添うマネジメントって感じですかね。）

それを2ヶ月ぐらい続けていくと、だんだんAさんも自分でこなせるようになってきて、数カ月後に「Aさんは仕事が出来ない」といっていた方が「以前とぜんぜん違う」と聞けるレベルになっていました。（正直このときは「やったぜ！」と心の中で思っていました。）

この経験をもとに、新人の方や、外からきて業務に不慣れな方の最初の段階ではマイクロマネジメントをした方が有効なケースもあると考えています。

自分の中では、マネージャーがロケットの一段目のブースタになってあげるイメージですね。停滞しているその人を押し上げる感じです。

Googleに入社してくるぐらい優秀な方や自主的に自分のやり方を展開出来る人は不要だと思います（自分のロケットで勝手に飛び立てる人はほっといても飛び立てます）が、中にはそうじゃない状況の人もいます。

人と状況をちゃんとみてどういったマネジメントをするか考えたほうが全体的にスムーズに進むと考えています。