20170609_WG議論

WG7 エンジニアのトリセツ †

今日のお品書き †

• 9:30-9:50 昨日の議論の振り返り (松尾谷さん)
• 9:50-10:30 ちょっと遠い（？）事例 (森本先生)
• 10:30- 議論
• 11:30- 振り返り

議論などのコメント †

• 『クラッシャー上司』という本にも同じようなことが書かれている．

理想の姿から考えてみる †

• エンジニアは知識欲が強い人が多い．たとえば，給料を50万上げるなら，50万の予算でセミナー，新規のチャレンジができるようにしてもらえた方が嬉しい．
  • 自由にすると変なことするというのはホント？
    • いい人，いいチームを作りたいのであれば採用からきちんとしないといけない？
    • 処遇が人を変えるのでは？
  • 日本とアメリカでのエンジニアの取扱が違う．日本はサラリーマンとして取り扱われる．

    
    

• マイクロマネジメントになるのは教育側面があるのでは？
  • 新入社員教育が始まってからおかしくなった．企業が序列で動くようになった．
  • 子供に危ないからとハサミを持たせないことと同じ．
    • 先回りして危ないよとやらせない，失敗しないように先回りしてしまう．
    • とはいえ，何も知らないので教えないと仕事が進められない．

      
      

• なぜマイクロマネジメントに走るのか？
  • 管理職になりたての頃は気負ってる．期待に応えないとと考えて過干渉になる．
    • 同世代の部下が出来た時に，長文のメールでやり方について連絡もらった．その時は文句言われたと思って気づかなかったが，後から気づいた．
  • 何がマネジャーとして期待されているのか分からない．
  • 日本ではプロジェクトマネジメントの教育はするが，組織マネジメントの教育はしていない．

    
    

• マネジャーの「役割期待」はなに？
  • マイクロマネジメントが始まったのは，パートナーを使い出し，その比率が上がり，外注管理をし出した頃から．

    
    

• 安心を与えるための技術が発展していない
  • だからチェックリストでの確認などになる．複雑になるチェックリストを人間の目でチェックするにも限界がある．
    • NASAはツールでチェックしようとしている．そのためにFormatを揃えることに注力している．
    • 日本のマネジャーはExcelしか使ってない→マネジメント技術が低い．
  • 技術力で安心感を与える方法の方が良いのでは．マネジメントの合理化．

    
    

• 相手の状況に対する関わり合い方の違い．これらを使い分ける必要がある．今は全てごっちゃになっているのでは．
  • カウンセリング：答えのないものに対する支援，相手をマイナスからゼロに．
  • コーチング：答えのないものに対する支援，相手をゼロからプラスに．
  • ティーチング：答えのあるものに対する指導，相手をマイナスからゼロに．
  • コンサルティング：答えのあるものに対する指導，相手をゼロからプラスに．
  • 組織に対してではなく，相手に対して使い分けている事例．彼らの認識は，管理ではなく，支援であり，課題解決．楽しんでやっている．
  • PMBOKを勉強した人は情報対応解決力として知っているが，人系の勉強をしていない人は知らない．知らなくて当たり前だと思う．日本の大学で人系のことも教えていない．
    • 教えて出来ない人はいない．苦しんでも出来る．出来ない人は人格的に問題がある．
  • 使い分けは教えてもらえわないと分からない．自分にとってやりやすいやり方で行ってしまう．
  • 経験を重ねていくことで多様性に気づき，変わっていくことができる．エンジニアは社会人になってから気づくので遅い．
    • マイクロマネジメントの上司が出張で不在の時に仕事がもの凄い進んだ．
    • いやなお客さんと長くつきあいたくないか仕事を早く終わらせた
    • モチベーションをどう持っていくかも大切．
  • 自分とちょっと離れた人には気づいていても教えない，注意しない．理由は「相手のためにならない」から．教えた方が会社のためにはなるのに．→まちがった放任主義．

    
    

• ソフトウェアの特徴
  • ソフトウェアは自分一人で完結できる．人とコミュニケーションを取らなくてもできる世界．この考えとマネジメントは関係しているのではないか．
    • Inputコマンドを打ったら，なんかしらのOutputが来るものと考えてしまう？

• 12のロードブロック
  • これをやると相手は考えられなくなる．相手が考えられなくなるので自分が考えなければならない，そして，相手の様子が分からないのでマイクロマネジメントが始まる．まずはこれらを使ってはいけない場面を理解する．
    • 1.命令する
    • 2.警告する
    • 3.道を説く
    • 4.アドバイスする
    • 5.論理を使う
    • 6.批判する
    • 7.称賛する
    • 8.レッテルを貼る
    • 9.分析する
    • 10.安心させる
    • 11.質問する
    • 12.回避する
  • これ全部がダメというよりは，「相手に考えさせなくする」ことがダメ．
  • とすると，まずは相手の理解の前に自分を理解しないといけなそう．
  • リーダシップの最初のステップは，自己理解．
    • 何を使って理解したら良いのか？
    • まずは自分の欲求を知る．
    • エンジニアは100%自己理解できないと次に進めないことがある．自己理解は一生続くことなので，ここは注意が必要．
      
      
• ゲームから褒め方を考える (JaSST東京での発表)
  • バートルテスト (Bartle Test)：ゲーマーのタイプ分類
    • 達成者/アチーバー(Achiever)：数値・・・
    • 探検家/エクスプローラ：新しいことに挑戦したい
    • 社交家/ソーシャライザー：人とのコミュニケーションに重きを置く
    • 殺人者/キラー：勝ち負けなど競争に重きを置くタイプ

これまでの議論を振り返って †

• 4つのパターン，ゲーミフィケーションについては教育の現場でも同様．アシスタントなどもあるので今後も参考にしていきたい．
• 4つの教え方のパターン，自分の得意なのは教えてあげること．出来る人，出来ない人に対して教えたくなる気持ちが先に出てしまう．個人の個性や力量を見てあげる必要がある．その人が今どういう所に立っているのかを見てあげないといけない．自分自身を強めていってそういうことが出来る人になりたい
• 人に対してマネジメントをする時，良いところを言って伸ばしていくのか，悪いところを言って伸ばしていくのか，人によって色々ある．良いところを伸ばしていくようにするのがマイクロマネジメントを防ぐことができるのでは．
• クラッシャー上司を読んだ時にまさに自分の上司そのままだった．それに対抗する何かがあるのかなと思えた．入社時に聞いたリーダシップの話を振り返ったり考える余裕がなかったので，もう一度考え直したい．
• いろいろな気づきや発見があった．ソフトウェアは人が作っているものなので，もう少し人系の知識や経験があると思っていたが，なかなかそうではないことが分かった．
• ソフトウェアの仕事でInputがあってOutputが戻ってくるのであまり人とのつきあいがないという話があったが，既存ソフトウェアの性能改善や機能追加見積などもソフトウェアのエンジニアとしてあると思う．その場合においてはエンドユーザとのコミュニケーションはある．人をベースにしたスキルを身につける教育をおこなった行ったら良いのでは．マイクロマネジメントに関してはメンバに提案させてチームで評価する形にすればメンバの印象は変わるのではないか．
• 異動により職場・上司が変わったことにより，自分自身の仕事がつまらなくなり，仕事が作業になっている話を聞くともったいないと思っている．自分自身も経験して体験をもって理解できた．知識を得たのでじっくり考えていきたい．
• マイクロマネジメントは善悪で言えるのか．経営方針や事業戦略に沿っているのであれば良いのではないか．会社視点に立てばやりやすいマネジメントのやり方だと思うが，各会社が置かれている外部環境が変わってきていることから，先の見えない所に対するマネジメントに変わってきてるのかなと思う．人材をどう活かしていくかは自分自身が考えていかないといけない．メンバとのつきあい方，褒める一つにとっても色々考えていくとリーダシップやマネジメントのやり方が変わってくると思った．
• マイクロマネジメントの課題はチームを持った時から考えなければならない問題と思った．そこで，うまくいったチームの事例を調べた．マイクロマネジメントの土台は体育会系の部活．それをうまく買えたのが青山学院大学．この違いを見ていきたい．社内のリーダシップ研修で使っているビデオで，Googleの及川さんによると，最初はマイクロマネジメントで成功をしてきたが，方針転換をして良い成果を出してきているとのこと．変われる人は変われる．
• https://www.nhk-ondemand.jp/goods/G2012037030SA000/
• 自分がマネジメントという立場になってこういった視点で考えるようになった．バリバリのエンジニアだった時代にこのWGに出ても心に落ちてこなかったかもしれない．もうちょっと若い時からこういった所に興味を持てば良かったとは思うが，課題としては自分を変革する材料とすると共に，自分の部下や後継者に早い段階で興味を持ってこういう所を勉強してもらうようにしたら良いかというところ．
• マイクロマネジメントの何がいけないの？から考えてみた．必要でやっている部分もある．なんでいけないのか，というと本質ではない所で雑用が増えて本業に集中できない．これについては無駄な技術はやめる，IT技術で解決できる．マイクロマネジメントされる側としては，信頼関係の問題だと思う．上司側にもきちんとコミュニケーションが取れる，リーダシップが取れるような教育が必要．される側にも同様の教育が必要．若い頃から教育をしていくことが必要．相互関係を考えてみたい．
• マイクロマネジメントをしなければならない局面はある．見ることが大事．相手がどのような状態なのか，どういう人なのか，なぜか，それは見ないと分からない．それを端折って自分の体験からの思い込みで走るとギャップが生じる．