マネージメントに悩む人は「思考と視点」を変えよ!(本)35歳からの「脱・頑張り」仕事術 仕組みを作れば、チームは自動で回り出す

投稿日:2013-01-26


 
こんばんは(^-^)/

ナカジ(@cp_nakajun)です。

 
35歳からの「脱・頑張り」仕事術 仕組みを作れば、チームは自動で回り出す (PHPビジネス新書)
 

マネージメントに悩む人は「テクニック」に走りがちに思います。

悩むからテクニックに頼りたいのです。

 

人を変えようとしてもかわりません

自分を変えるしか...

 

わかってるよ!!

 

そう言われそうですが、要は「思考と視点」を変えればいいのです。

立ち位置・スタンスを変えるのです

 

紹介する本は「テクニック」的ですが

相手をどうこうするテクニックではなく、自分を変えるテクニックです

 

判りやすく、簡単で、とてもオススメです!!

 

では、僕なりのポイントと読書メモを共有します。

 

■マネージャーの仕事

  • アウトプットに対する責任と管理
  • メンバーのモチベーション(仕組み)の管理
  • 自身の成長管理

 

■マネージャーの心得

  • 手柄はメンバー、失敗は自分
  • 主役はメンバー、自分は脚本を書く黒子

 

◆僕なりにポイントをまとめました

  1. 最初の部分は一番下っ端のやることを自分でやる
  2. 仮説(あるべきすがた)を最速で「想像」する
  3. チームメンバーから思考を引き出しつつ仮説の精度を上げる
  4. 仮説はあくまでも「チームメンバー自身」が作り上げるように誘導する
  5. チームが動き始めたら「リスク回避」を陰でする
  6. メンバーの「精神衛生」をケアする
  7. 「メンバーに仕事を取られる」不安でなく「自分にしかできない領域」を追求する

 

■以下、読書メモ

  • 最初の仮説をマネージャーが作り、その確認、検証作業をチームメンバーに分担して任せ、一緒に、仮説が 違った時(反証という)に次の仮説を考えたり、さらに一緒に仮説を進化させたりする。あなた一人が作業する時よりも、質の高い成果物が、効率的に作り出せ る可能性がある方法論だ
  • まず猛スピードで品質の高い情報を集める。そして、さっと仮説にまとめるのがマネージャーの最初の仕事
  • 私流「仕組み」仕事術の第二の要素は、「絵を描く」という言葉に集約される。要するに、いま与えられた課題について、結論としてどういう状態に持っていったら良いかのイメージを想像することである。「あるべき姿、ありたい姿」の絵を描くこと
  • 自分で考えた仮説でも、実際の部下とのやりとりの過程では、あくまで部下との対話の中で、彼らをやんわりと誘導しながらも、彼らと一緒、というか、彼らが仮説を作ったかのように見せる演出をする
  • 絶対にマネージャーが精密にやってはならない。  マネージャーが自分で細部まで精密に作った仮説を見せられた部下がどう思うか、考えてみてほしい。できない部下は、あなたの指示を待っていれば何でも やってくれると思うだろう。まあまあのできの部下も、楽ができると喜んで、オーナーシップを持って仕事に取り組まなくなる。  こうなると、仮に仮説が反証されたとしても、「シマッタ、今すぐ方向転換だ」という切羽詰まった気持ちにもならない。要するに、彼らにとってこの仕事の オーナーはあなたになってしまうのである。「人ごと」になってしまうのである。  できる部下は、もっとマズイ。いきなり萎えてやる気がなくなる。「任せてくれない」と言って……。  だから、マネージャーは半分、とぼけるべきなのである。「さぁ、この皆で作った君らの仮説の詳細チェックは君らがしなきゃね。よろしく! できるだけ詳 細にやってね」と言って渡すのである。これで仕事のオーナーシップというボールは部下の手元に移った
  • 「これだ!」という仮説が見えるまでは、部下の先を走りまくり、現場作業に没頭しなければならない
  • マネージャーの経験で、自分の今まで感じた雰囲気と比較衡量して、その空気の意味をつかんでほしいのだ。それが差別化につながる。そして、部下に、どうしてそう思ったのかを説明してあげてほしい。ここは、経験がモノをいう
  • その部下の考え方を素直に聞く、「間違っていても良いから、あなたはどう思うか」と言って、ジックリ聞く。「どうしてそう思ったのか」も聞いてみる。自分の頭の中で、その部下の観察事実と思考回路を理解するため
  • 相手の頭を乗っ取ってしまうのだから、相手の拾ってきた観察事実と、相手の思考回路に、自分の観察事実 と思考回路を混ぜてしまう。事実については、「ここまでは、私も知っている」「ここからは、新事実だ」として、両方を自分の頭に入れる。思考回路も、相手 の思考回路で面白いと思ったものは自分の中に取り込んでしまう
  • 生まれ育った環境も、物事の考え方、経験も自分と違う、一番身近な異質が部下のはずである。その部下が、あなたに教えてくれる「輝く異質性」を一個も持っていないなんてことはありえない
  • 異質の人とうまくふれあうための肝は、自分と部下との間の共通部分集合を探すことにある。どんな人とで も、共通部分集合は絶対にあるはずだ。それを見つけるために、部下の観察事実に耳をそばだて、部下の思考回路を理解して、かつ、どうしてそういう思考回路 をもつに至ったのかの理解に努める
  • 不祥事の報告が遅れる理由に、上司が聞きたくない話を伝えにくいという部下の気持ちが挙げられることが多い。根っ子の問題は、この円と円との完全一致を求めるという稚拙な部下マネジメント方式にある
  • 部下との共通集合を見つける場合、部下にどうしてそういう結論を導いたのかという過程を尋ねることが極めて有効になる。 「君の結論(点)は、XXだね。どうして、そういう結論になったか話してくれないかな?(円を尋ねている)」と聞くだけである
  • その結果、部下に向かって、「君は面白いものを見つけてきたね。それは、面白い観察事実だよ。でも、その観察事実は、こういうふうに考えたほうが面白いと思うんだ。いずれにしても、君の観察力の鋭さのおかげで、仮説が一歩進化したね」と言うことになる
  • 顔色がすぐれない原因が、個人的な事情の影響であったりキャリア上の悩みであったりするときも多い。そうしたことも面倒を見てあげないと、良いパフォーマンスで仕事をしてもらえない。とにかく、部下の顔を見ること。それが、最大のリスク・マネジメントになる
  • 私の成果物要請の大原則は「顧客向けの資料は、絶対に手を抜かない」「社内向けの資料は、徹底的に形式にこだわらない。場合によっては、紙や資料をまとめ直す必要はない。生の資料でも、汚い手書きでもコピーボードでも構わない」ということ
  • 一つの欠点は、マネージャー自らが自分の非を認めるということで権威とプライドを犠牲にするリスクがあるということ。私は、そんな空虚な権威とプライドにしがみついて仕事するべきではないと思う
  • 仕事オーナーシップの精神を持ってもらい、かつ、彼らが倒れないようにきめ細かくフォローするというスキル
  • 部下に自分の仕事のオーナーシップを持ってもらい、本気で仕事に取り組む姿勢を作ってもらい、仕事オー ナーシップの高まった部下の精神上のストレス、仕事失敗のリスクを最小限にマネジメントし、いざという時、すぐに救出できる仕組みを作っておくという、部 下にとっての「働くための衛生要因」を満たすこと、そして、私との仕事を通じて部下に成長してもらう、という三つの目標を達成する「仕組み」を作ることだ
  • わが社が、『無理です』『できない』と言っているような課題は、当然、ライバル企業も同じように思っているはず。競争に勝つには差別化しかない。他社も同じように言ってるんだとしたら、わが社は、『どうしたらできるんだろう』を考えれば、それが、ズバリ差別化の武器になる
  • 明らかな悪意や手抜き、サボタージュでない限りは、決して、責任追及はしない
  • 私生活が安定して初めて、明るく、前向きに、オーナーシップレベルの高い状態で働いてくれる。詳細に私生活に立ち入るべきではないが、私生活への配慮は大事である
  • 部下を育成するときの私の大原則は、その部下の「相対的強みを発見し、まずその強みを伸ばす手伝いをする」ということである
  • できる部下が、マネージャー仕事の領土に侵略してきたら、それは渡してしまう。自分は上司の視点で考え、場合によっては上司の仕事の一部を領土侵略してしまえば良い
  • 人前でまれに褒めることはあっても、絶対に人前で悪い評価を口にしない。その代わりに、気がついたところがあると、「山本、ちょっと来い」と個室に呼ばれる。そこで、弱いところ、悪いところを直球で指導してくれた
  • 「弱み」という言葉は、絶対に使わない。代わりに「改善点」という言葉を使う
  • ここの部分を良くすると、もっと良くなる
  • 部下が自ら成長したいと思っていることを、仕事や、私というマネージャーとの関係性を通じて達成できる術がないかを考えるわけだ。部下のやりたいことと仕事を擦り合わせるといっても良い
  • 部下を絶対に批判や失敗の矢面に立たせ続けない、ということである
  • 部下に責任を取らせるのなら、マネージャーである自分は無用の長物となる。そもそもの責任は、そういう部下の能力を見抜けず、間違った仕事の与え方をして、おまけにリスク・マネジメントを怠り、部下を失敗させ、指導もせずにいたマネージャーにあるのだから
  • 自分が優秀なマネージャーだから上手くいったというような態度は絶対にしてはいけない
  • 「褒められたときは、部下のおかげ」「叱られたら、自分の責任」

 

これは本当にいい本だとおもう

僕もこの読書メモは定期的に読み直したい

 

オススメです。

 

 

サポート募集中

この記事はお役に立てましたか。
よかったら、コーヒー ☕ をご馳走いただけたら励みになります。



おすすめのクリエイティブ・コーディング関連カテゴリー

クリエイティブコーディング系 講座


ウェブツール

機能はシンプルなものですが、p5.jsやTone.jsで描画したり音が出たりするので遊んでみてください。
・【Midi Number Tools】:MIDIナンバーから音名と周波数を判定します
・【Delay Time Calculator】:テンポに応じた音符の長さを判定します