会社のメンバーが読んだ、という話を聞いて私も読んでみました。
共通認識を持つことができれば改善はよりうまく進みます。
まずは章ごとに感想を。
■第1章 褒めてやらねば、人は動かず
望む行動の時にはイエスの態度、そうでないときにはノーの態度をとる。
確かに基本で、それをしない人は何を望んでいるのかわからない。
でもそもそも人を動かしたい、成功したい、と考えていれば良いのですがそもそもそれがないから困っていることのほうが多いですよね。
■第2章 鬼の上司が会社を伸ばす
ちゃんとほめなさい、というところはその通りかと
この章で一番大事なのは「その場面に適切な行動を何も教えていない」という部分ですね。
大概はこれが問題の原因になっていることが多いと思います。
あとは「言っているんだけど伝わっていない」ですね。
相手が理解するところまで噛み砕く、100回言って理解してもらえないなら1000回言う、ということが大事。大体は1回言ってわかってもらえることなんてまれなので大事なことなら10回は言うようにしています。
■第3章 ネガティブ社員はこう扱え
いや例示が絵空事にもほどがあるやろ。
確かに問題があって相手側も聞く側も言語化できていればこの状態に近づけていけるけれども、問題がそんな単純なものであれば解決できているのでは？何となくまずそう、でもよくわからないけどこのままじゃまずい、という状況の方が圧倒的に多いと思うので、こんな風に解決できる方がまれだと思う。
ネガティブな人はいたほうがいい。パレートの法則ではないですが2割は普通にネガティブになるもの。他のチームでポジティブでも、ポジティブな人の集団に入れるとネガティブになる人もいる。
基本ネガティブな人がいると仕事が確実になる。でも進みが遅くなる。
ネガティブな人の割合が多いと進みにくくなるので、割合は確かに2割ぐらいにしておいたほうがいいかと。
会社ぐるみでネガティブな人を排除しようとした会社にいたことがあるので、その話をしますね。
その会社では年に一度会社の会合があって絶対参加でした。
新人の子たちが余興をするのが恒例だったのですが、男女問わずアイドルの格好をして踊っていました。
毎日就業後に集まってやっていて、ほほえましいともいえますが反対意見を言う人がまるでいなくてちょっと怖くなった覚えがあります。
その会社ではその会合に限らず通常の会社の飲み会であっても、サービスが問題を起こしている最中ても参加が絶対でした。
そういう会社がどうなるかというと、仕事の進みは早いけれども不具合でまくりになるんですよ。
である程度勤続年数が増えると疲れて辞めてしまう人が多い。
お金を稼ぐということで考えるとポジティブな方が有利です。不具合が多くてもどんどんサービスをリリースさせていく方が結果儲かることが多いから。
ただエンジニアとしてはそれだとあんまり力がつかないんじゃないかな。
不安な人の話にはしっかりと付き合うしかないんじゃないかな。自分が100%解決方法がわかっている状態なんてないんだろうし、自分が気が付いていない問題を教えてくれるわけなんだから無駄じゃないでしょ。それを放置していると不満が起きるわけで。
自分が100%解決方法がわかっている状態だったとしたらまずいですよ。そんな簡単に問題がわかっている状況はプロジェクトの難易度自体が低すぎるでしょ。
■第4章 活発な職場を取り戻す
笑顔と感謝必要。でも感謝して意味があるのは作業に関してちゃんと理解があるときだけで、本書の例のように能力が備わっていなければできないか意味がないものになる。
本書は所属部署を差し替えましょうということで解決したけど、実際は上層部がそれを認めなかったり、認めても移動先がなかったりすることの方がほとんどかと思う。
あんまりためになる解決方法ではないなあ。
改善はかなり難しい。実際は上司の方がちゃんと理解でてないとだめで、それが実現できないのであれば改善でき無くて適当かと。
それでも改善したいと思って頑張ると、その頑張った人が損して、それを見ていた人が辞めるっている最悪な循環パターン。
あと相談に来たら「ありがとうございます」とかえしているけど、理想的ではあるけどこの受け答えしている人はつぶされちゃうことも多いから注意。実際はできる量が限られているのだから、自分のキャパを超えたら受け取れない態度をとることも大事。
ネガティブな発言を抑制すると、その人が折れやすくもなるからそれも注意。能力が低くてネガティブなら押さえつけてもいいけど、作業を進めている人が出しているのであればそれを抑制すると潰れてしまうことがある。
実際問題ちゃんとやっている人は他人に対して腹が立つものだし、そうであればネガティブな発言をするのが適当。それでもポジティブな発言している人はやめちゃうか潰れちゃうかと思うんですが。
トリアージを気にすることは重要、効果的。
この章の本来の言いたいことは、良いことをほめて、悪いところは具体的に改善を提案しましょう、というところで正しいんだけど第2章といっていることが一緒。
「悪いところは具体的に改善を提案」というのは能力的に高くないといけない。
管理者であっても必ずしもすべての管理下の作業について詳しいわけではない。現状はそんなに単純な状況ではない。
■第5章 上手な褒め方、無意味な褒め方
適切な内容でできるだけ早く褒めるというのは確かに重要。
自分自身の能力の高さも必要。できない人に褒められても響かない。
一人でやる作業というのをできるだけ減らそうとしています。
一人でやっているとうまくできているのかそうでないのか客観的に理解できる人がいなくなる。
そうなるとやる気がなくなるのが普通で、褒めていないのと同じ状態になるのでです。
■第6章 「頑張れ」というだけでは業績は上がらない
作業に順位付けを行うのは重要ではある。作業を詳細に分析してボトルネックを探す。
どちらも有効。
ただ作業に優先順位を付けないといけないということは作業指示を出している量と、実際にできる量がかい離しているということ。
これ自体は改善しないといけない。
ボトルネックを探す作業は都度行うべき。
ワークフロー的に対応し始めると本来「A案」でやるか「B案」でやるか検討して適当な方でやらないといけないときに「A案」がワークフローになっているから「A案」でやろうみたいな動きになる。ゲーム開発は割と都度最適解が変わるし、「C案」、「D案」みたいなのが出てきて比較検討する必要が出てくることが多い。
新規開発だと上記のように気を付けないといけないが、ソーシャルゲームの運営のように割と決まった作業はワークフローに当てはめた方が良い。
パフォーマンスは最低でも週に1回はチェックせよ、というのはその通り。できれば毎日チェックしたい。
ためるから大変なだけで、毎日のチェックであればチェック自身楽になるし、手戻りも少なくすることができる。
■第7章 ハイパフォーマンス集団のつくり方
確かにシェイピングはいい手法。やることを分析してリスト化して、得意不得意を判断。できる人の知識をできない人に共有する。
一般にできない人とされている人もストロングポイントがあることが多いが、そういう人に学ぶということに抵抗感がある人が多いのが課題。
あとできてない人をできると判断してしまうことも危険。一気にわかっている人のやる気がなくなり、間違った知識が共有されると目も当てられない。
やる作業が多岐にわたっていると効果は薄いかも
あとは解決できない問題もある。
例えば進捗管理ツールの導入に関して。
ある人は「複数のツールを使い分けるのは非効率」だという。
ある人は「各作業の性質によって複数のツールを使い分けるべき」だという
どちらが正解かはわからないが、言っている本人にとってはそれぞれ正解。
こういう場合にどうするか？やる気があるから難しい判断というものもあります。
■第8章 「勝ち味」を覚えさせよ
「自信がないからどうにかしたい」、という人の対応だと思うがたいがいは「自信がないからどうでもいい」になるのでは？
バックワードチェイニングは効果的だと思う。
ただ反対する人も多く、なかなか実現は難しいかも。
成果主義が周囲への協力や教育を阻害するようになったというのは確かにそう。
チーム員へ成功体験を分けた人は、個人で行ったよりも高い評価をする、というところを経営陣に納得させルール化できるといいと思う。
■第9章 裏表のない組織を作る
会社を良くするためにもっと話し合いましょう、というのはその通りだと思います。
ただ今の世の中の価値観として、会社を良くしよう、と思ってもらうこと自体に無理があるかもしれません。
良くなればいいくらいには思っていると思いますが、よくするための行動自体否定的な人がいるということを考慮するべきです。
そう思う人がそれを表明できて初めて裏表がない組織になるかと思います。
そこで「やろうと思う人」と「やりたくない人」を明確に分けて、評価も変えていけばいいのだと思います。
ちゃんと表明させる、表明したからにはやってもらうorやらせないようにする、で評価は明確に分ける、です。
やりたくないけど何となく無理してやってるんだから評価してよ、という人がいるからややこしい。やりたくないならやらなくていいしやらせない。
で、やる人をちゃんと評価する。
この章の例だと信用できる、信用できない、で分けているが実際はそんなにシンプルではない。
この部分は信用できるが、この分野では信用できないと分けられることがおいし
■第10章 お互いの悪い癖を直す
自分の悪いところを直したい、と思ってくれているのであれば直せますね。
そもそもそれを思ってくれないから苦労しているわけで。
プロンプトは効果的だと思うが、実際それでも直らないとイライラするし、きつく言い続けるとパワハラ扱いを受けてしまう危険性もある。
やり方を考えるより、関係性を良化するほうがいいとは思う。
■第11章 表彰制度はこう変えよ
表彰制度を実施するかという質問に対して「社長が本当にやりたいことは、表彰するということより、チームワークの重要性を会社員が意識し、毎日の仕事で実際に行動することじゃないですか」という返し、発想はとても良い。
しかしながら実際こういう開始をすると理解するのではなくぽかんとする人の方が多い。
表彰をやれと言われているのだから表彰をしないと、と思ってしまう人が多いところが問題。
1回の表彰で基準が明確でないと効果が薄いというのはその通りだと思う。
ただみんなで評価しあうというのは多少問題。
経営陣が思ったような人が表彰されないと、間違った結果が出ていると思う人は多いし、どうしてもコミュニケーションが活発な人の方が選ばれやすい。
実際似たようなものをやっていたことがあるけれども、デザイナー同士は仕事でもコミュニケーションも多く、よく票を確保していた。
プログラマーでもデザイナーと交流がある人は票をもらっていた。ただコツコツやる人はもらえないことが多い。
SNSでいい値をもらう回数が多い人が優秀な人ではないでしょう。
ノミネートや受賞は抽選、といってもどうしても不平等感が出るかと。
ノミネート形式もやっていた会社にいたことがあるのですが、外から見える人に得票が集まって、実際に良い結果を出していた人とかい離することが多く危険。何年か経つとノミネートされてたけど全然この人だめじゃん、ということが何度かあってこれ難しいなと思いました。
個人的にはお楽しみ程度でやる以上のことは不要なんじゃないかなあと思います。正しく評価するのが難しいし、それに労力を割くのも割に合わないかと。
■第12章 フィードバックで新人を育てる
新人に何を教えるのか、ということも大事だがそもそも教える方の教え方が大丈夫か気にしなさいというところはその通り。
新人研修の目的をちゃんと決めましょうというのも意外にできていないけど大事なことだと思います。
ただ人を付けて新人研修をやることに関しては、個人的に懐疑的。
10年後を背負ってもらう、という意気込みはいいが現実離れしすぎている。
会社がそもそもあるかどうかわからないし、同じような仕事をしているかはもっとわからないし、どんなに良い会社でも辞める人はやめる。5年したら独立する！という気概がある人だっているだろう。
初年度は社会人としての生活ができるようになる、2、3年後ある程度の仕事ができるようになる、というところで切っておくのが現実的かと。
それこそタスクにして自動化できないか。でできていない人に対して繰り返しやってもらえるとよい。
人がやると角が立ったり、教育係の手間にもなるので自動化できた方が良い。やるならできるまでやらないと意味がない。
私が新人の教育係になるときは低レベルのことから何度でもいうようにしている。本人のレベルが高かったとしても、どこに落とし穴があるかわからないからだ。
で、自分の教え方の勉強にもなっているのだからどんな人にも同じように伝える。
臨機応変にやらない。それをやるから抜けが出て失敗すると思っています。
繰り返し教えることでやっと徐々にできるようになる。新人研修は1回言ってやれるようになることを求められる傾向があるので、なしでもいいのではと思ったりしている。
■第13章 マンネリが組織を不活性化する
確立操作自体は効果的かと。
ただマンネリであってもリターンと告知がしっかりとされていれば続くことが多いかと思います。
特許の報奨制度があったのですが、結構リターンが大きかったです。具体的に１請求項5000円。採用されると5万円。
一見少ないように思えますが、1個特許を考えると同じようなものをまとめてとるので請求項の時点で5~10万。その中で採用されるのが半分以下で20～35万くらいだったので大体まとめて30万くらいもらえることが多かったです。
特許申請自体は大変なのですが、この報奨制度のおかげで業界トップの申請率でした。
またチームに一人は特許報酬目当てでよく出している人がいたので、特許侵害にも目端が利くようになったり、これは特許にした方がいいという提案もよく生まれたので相乗効果が高かったです。
私自身2回特許をとっていて、合計60万くらいもらっています。自信にもなるし特許関連に詳しいのは武器になっています。
つまりリターンのバランスが大事だということです。
■第14章 過去の自分と決別する
自己強化。
自分で自分をほめることは効果的。仕事を進められる人はもれなくこれができるように思う。
根拠がない自信がないとゲームなんて作ってられない。
自分にご褒美は何気に効果的。自己研鑽はなにげに快感が高い。
短期的に効果が見えることを繰り返すことが良い。
最近は空き時間は応用情報の勉強をするようにしているが、だらだらしているよりも良い効果が出ているように思う
■第15章 「苦手な顧客」の克服法
レスポンデント消去の方法は勉強になった。
試したことはないが、どうしても避けられない人もいるので必要に応じて試してみたいと思う。
個人的に全く妥協したいない人というのは私自身苦手意識がある。
ただ自分の部下となれば克服させるということはさせず、普通に担当を別の人にする。
相性があるので常にだれを当ててもダメということの方が珍しい。
克服する、させるということは失敗した時のことを考えるとリスクがでかすぎるのでやらないほうがいい。
■第16章 コンプライアンスを高める
ラインを止めてもペナルティがない、ということを本当に実現できるのであればよい話。
実際にはペナルティがなくても目標が達成できない状態はペナルティと同じになるのでは？
撃墜王も発見確率が高い人がなっていればいいが、そうでないなら発見数が多くても足を引っ張っている状態になることがある。
役割を別途設けるか、わかりやすい基準を設けて対処するしかないのでは。
基本は適切な量を適切な期間で行うことが重要で、それがなされていないのであれば改善されるわけがない。
+------
と、最後まで読んでみたのですが相変わらずネガティブな意見になってしまいますね。
コンサルティングがはいってろくなことになったことがないので、どうしてもポジティブになれませんね。
この本に関してですが、まず第一にちょっと古いです。2008年の本なので現状と即していないところが多すぎる。
この記事はそのあたりを差し引いてみてもらえるとよいかなと思います。
あと13章にてサカモトが（ありがたいけれど、私もいつまでここにいられるかわからない）というシーンがあるのですが、これが一番の問題なんですよね。
改善しようという社員はできるだけその会社にいようとしている人たちです。そういう社員はいついなくなるかわからない人に頼らないだろうと思うのですが。
改善する社員って矛盾なんですよ。改善が終わった後いなくなるの？やはりずっと会社にいる人、その会社の中心業務をやり続ける人がやり続けながら改善するしかないと思います。
実際は別の実務を抱えながら進めないといけない作業だと思うので、そういったことを踏まえているとよかったかなあ。
まあしょうがないのですが、少しご都合主義的に問題が解決しすぎかなと思います。
実際には「基本的なやり方では改善しない、そこでどうするか」というところで困るので、そういった例がないのであんまり役に立たないですねえ。
そういった込み入ったものを解決するためには、確かにこのような本を複数読んで手法を増やして組み合わせて対応するしかないです。
そういう手法の一つとしては有効だと思います。
+--------------------------------------------
↓ブログランキング参加しています！
ゲーム制作ランキング