躾はマイクロマネジメント、裁量はリスクマネジメント


自分が所属する組織は、すぐ隣の組織でもマネージャが違うだけで全く違う家風を文化として持つものです。その組織の単位が課から部へ、部から事業部へと大きくなれば、その差異の濃さも広がるんだね。組織再編が好きな会社なら大規模な再編に揉まれると嫌でも経験させられるもので、ワタシなんて何度味わされたものか。


マネージャなら自分が担当する組織をどのようにオペレーションしたいかでチームデザインを考えるものだし、デザインを考えないマネージャはチームデザインのポリシーがない故、そのメンバはそのマネージャの元にいる間は右往左往させられるものです。実際、チームデザインをポリシーとして理解できるときのマネージャなら軸がぶれないので先が想定できて仕事がし易いし、ポリシーのないマネージャは毎回変わるので仕事がし辛いです。


ここずっと、他の組織までレビューアとして見る機会が多くなって、−隣の家に行くようなもんですが−、そのマネージャがどれだけチームデザインに気を配っているか、それともノーコントロールでやっているかよくわかるんです。ワタシと同じや近いような価値観でチームデザインをしているとワタシ自身と親和性が高いから馴染み易いし、そうでなくてもそのマネージャのチームデザインの考えがわかると理解が進むものです。でも、マネージャもそういったチームデザインをする人ばかりではないのはシステムエンジニア自身が学ぶことについてのマインドセットが十人十色であるのと同じように少なからずいるもので、そういったマネージャのお家のレビューは骨が折れるんです。


組織は成長もするし怠惰に流されもする
マネージャが組織のチームデザインをするのは、マネージャ自身の組織への想いに属する組織の目標を添加した結果です。想いにエッセンスを添加したから今のチームがデザインされているのです。


人は何もしなければ成長はしないものです。なんせ、怠け者ですものね。楽をしたがるのは安全な組織というエリアに属することが出来たら当然の帰結でしょう。それは本来組織である以上は許されないものなのですが。


システムエンジニアが意識して自分のマインドセットを駆動してまなび、フィードバックを経て自己伸長をするように、組織はリーダであるマネージャがチームの成長のためにチームがありたい姿をデザインしてそのデザインをメンバと共有と実行を経て成長をすることができるのです。ただ、チームは成長もできるけれど、成長をしないことも選べるんです。どちらかになるかはリーダであるマネージャに大きく依存するのです。


マネージャが成長を望み自らが先頭に立つなら成長するし、ただ、上からのオペレーションを落とすだけなら日々の業務を怠惰に流すだけでしかないでしょう。


躾はマイクロマネジメント
チームデザインは、2段階あると思っています。一つは、最低限のふるまいの標準化です。標準化と言っても、そのチームに属するメンバの誰がふるまっても、最低限の作業結果のアウトプットの品質が得られるというものです。ある程度の幅の作業なら、誰がやってもここまではできているという共通で持てる“期待へのマネジメント”といってもいいでしょう。


チームの誰がやっても、となるので箸の上げ下げができるまで五月蠅く介入します。それは先に述べたように誰がやっても最低限の品質レベルを得たいからです。“期待へのマネジメント”は、期待という最低限の品質レベルのアウトプット得るためのコントロールなのですから。


“期待へのマネジメント”を確保するための躾のマイクロマネジメントをチームの中には嫌がるメンバもいるものです。なぜ、やるかを理解しようともしないし、なかなか協力をしようとしない。でも、それを見過ごせば、“期待へのマネジメント”は実現されないし、自分のデザインしたチームは作れないのです。だから、絶対折れてはいけないし、厳しい口調でも改めさせなければならないときもあるのです。でも、それが実現したときに一番恩恵を受けるのがその嫌がるメンバだったりするのも面白いものなんですが。


“期待へのマネジメント”を実現するための小五月蠅いことは、子どもへの躾と同じで、躾のアプローチは様々なようにチームへのふるまいのコントロールの仕方はそのチームメンバにあったように箸の上げ下げについてみて上げなければなりません。


裁量はリスクマネジメント
“期待へのマネジメント”が結果として得られるようなチームデザインに近づいてくる頃、そのチームの中でも上位のメンバは、もともと自然と対応できるほどのスキルや経験を持っていて、躾のようなマイクロマネジメントはサッと通過するメンバもいます。そう言ったメンバは、放置しても“期待へのマネジメント”は得られるのですから、次のステップである裁量を渡してあげなければなりません。それはマネージャの負荷軽減もあるのですが、それより、次のリーダを育てるための自律してふるまうことの出来る人を育成すると伴に、他の“期待へのマネジメント”へ応えられていないメンバへがそこにたどり着きたいと思わせる動機になるからです。


裁量を与えるということは、与えた側に心構えが必要で、与えた責任を負うことが前提にあるということです。それは、裁量を与えたのだからどんなに苦しくても悲鳴をあげてもやり切れ、ではなくて、状況に応じて介入し、辻褄をマネージャが自分自身で合わせなければならないという覚悟をしておきなさい、というものです。


マネージャが自分でチームデザインをするなら、そんなこと当たり前だと思っているマネージャばかりですがチームデザインをしないマネージャは、メンバに丸投げして炎上して、そのまま泣きついてくることが多いのもまた現実です。


システムエンジニアがどんな小さなリーダでもリーダになるとき、マイショップのオーナになるのですから、チームデザインをしましょう。マイショップをどういう運営にするのか、何をコントロールして何を裁量として渡すのか。何を厳密にして、何を曖昧にしておくのか。その小さな試行錯誤の積み重ねが自分をもっと涵養させるのです。