ロッシェル・カップ "日本企業の社員は、なぜこんなにもモチベーションが低いのか?"

日本企業の社員は、なぜこんなにもモチベーションが低いのか?

日本企業の社員は、なぜこんなにもモチベーションが低いのか?

日本で仕事されている経営コンサルタントの人の本。日本の人事部門や採用/人事/教育戦略で割と上手くいってないところをくくり出し、また米国を中心として取り組みの事例やメソッドなどを挙げている。

エンゲージメントの低さ

日本企業ではエンゲージメントが低い、という点が第1章、この本最初の指摘だ。

社員のエンゲージメントとは、社員の企業に対する関与の度合いと、仕事に対する感情的なつながりを表現するものである。 (P.35)

これは、20世紀の日本企業では当たり前だった会社への忠誠心とかプライドといったものが、多くの会社でなくなってしまっている、ということだと思われる。調査機関などの10のレポートをあげて、欧米やアジアに対して日本企業のエンゲージメントレベル、ないしエンゲージメントの高い社員の比率の低さが報告されている、とする。

それはなぜだろうか、という疑問を中心に本書は進む。
さっと付箋をつけたところを抜き書きしておく。

日本企業では典型的に社員は自分で仕事の内容を選ぶことができない (P.52)

1980年代の過剰が招いた従業員数の肥大化の後始末として、日本企業の人事部はその後20年もの間、コスト管理に焦点をあて、社員のやる気を増大させるポジティブなアプローチには無関心でいる。 (P.54)

日本人マネジャーの多くがマネジメントにあたって「新人のミス」を繰り返し、社員を怒鳴りつけたり間違いを大勢の前で指摘したりといった、他国では疑問視されているアプローチを取っている。 (P.55)

Netflixの人事管理制度

続く第2章では社員のモチベーションをどうやって高めるか、という話に移る。
Netflixのアプローチが紹介されている。

とても有名なスライドセットが公開されているそうだ。これかなぁ。
http://www.slideshare.net/reed2001/culture-1798664

スライドにある「重視している価値」は以下のとおり。本書にも抄訳が掲載されている。

  • Judgement : 賢い判断をする。根本問題分析、ただ症状を治すだけでない判断。現在あなたはなにで、なにでないか、どうしようとしているかを戦略的に考える。今できていることと今後改善できそうなことを分けて考える
  • Communication: すぐ対処するのではなく、よく聞いてより良い理解に。簡潔に端的に書く・話す。他の人の状況の独自性や、あなたと意見の合わない点を尊重する。ストレスのある状況下では、落ち着いて冷静に。
  • Impact: 驚くほど多くの重要な仕事をこなす。一貫して成果をデモすることで同僚はあなたを信頼できる。プロセスではなく結果に集中する。行動重視、分析麻痺を避ける。
  • Curiosity: 素早く積極的に学ぶ。戦略/マーケット/顧客/サプライヤを理解する。ビジネス/技術/エンターテインメントに関する幅広い知識を持つ。専門外のことにも効果的に貢献する
  • Innovation: 課題を捉え直し、難しい問題を実践的に解決する。当たり前だと思われていることがあれば、その仮定を明らかにし、よりよい方法を提案する。使いやすさを実現するアイデアを出す。複雑さを最小限にし、単純化するための時間をとって、スピードを維持する。
  • Courage: ザワッとしそうなことでも、自分の意見を述べる。苦渋することなしに、難しい決断をする。賢くリスクをとる。我々の価値観と矛盾した行動に疑問を持つ。
  • Passion: 卓越したいと強く望み、他の人に刺激を与える。Netflixの成功を真剣に考える。成功を祝う。粘り強く。
  • Honesty: 率直に。他の人と意見が合わない時にも政治的にならない。同僚について話すときは、本人に直接言えることだけを口にする。失敗はすぐに認める。
  • Selflessness: あなたやあなたのグループより、Netflix全体にとってベストなことを探す。エゴなく最良のアイデアを探す。同僚を助けるための時間を作る。オープンに積極的に情報を公開する。


本書に戻ると、このあとNetflixの文化や施策を紹介している。スライドの引き続きの部分が中心なので、日本語訳するかわりに参照するといいかもしれない。

面白い(アメリカ的だなぁ)と思ったのは以下の解雇のくだり。

Netflixはすべての職務で最も優れた人材を望んでおり、そのための採用・能力開発・解雇を「賢明に」実行している。ネットフリックスでマネジャーが使用する「キーパーテスト」とは、「自分の部下が競合会社の類似の職に就くために辞職するといってきたと仮定して、ネットフィリックスに留まるようにその部下を強く説得するかどうか」というテストである。マネジャーが自分自身にこの質問をし、回答が「ノー」、すなわち部下を説得しないと考える場合、その社員は「寛大な解雇手当を渡して即刻解雇すべきである。そうすればその職務をより優れた人材で埋めることができるから」というのがその論理である。(P.77)

社員を信頼してイノベーティブなことをやろうという企業なので、常にできる人を維持して任せないといけないという切迫感を感じる。

責任能力のある人材は自由を与えられることでさらに才能を伸ばし、またその自由に価する」というのがネットフリックスの考え方である。「成功を持続させる革新的な人材を惹きつけ育てる」ためには、会社の成長に合わせて社員の自由を制限するのではなく増加すべきだというのがその方策である。(P.80)

プロセスを増やして安定させようという圧力に徹底的に争う姿勢を持つ。そうしないと、成功は安定するかもしれないが、どんどん時代遅れになっていく。

日本の人事制度や雇用関係の問題

筆者の鋭い指摘を、いくつか抜き書きしておく。

人事異動は当然という固定観念によって、日本企業が多くの問題点を見落としているというのが私の見解だ。 (P.106)

定期的に顧客や同僚との関係がリセットされたり、遠方に異動したり、というのは非効率だという指摘である。

マイクロマネジメントは、アメリカで非常に効果があるとされているアプローチである「エンパワーメント」の対極にあるマネジメントスタイルである。(P.172)

この前後でマイクロマネジメント、ホウレンソウ、プレイングマネージャーの問題について述べている。

日本人がポジティブフィードバックが苦手な理由は様々である。(P.192)

暗黙の了解の文化や、頑張ってあたりまえ、取って付けたような褒め言葉になるんじゃないか、というところから、日本人マネージャーは褒めるのが得意でない、とのことだ。

大切なのは、自分を「X企業で働く社員」として考えることをやめ、自分のスキル、能力、将来性をその企業の中だけで考えないことである。自立した個人として、自分の人的資本を活用するため、自分で選んだ進路を進むことを考える必要がある。
これは、企業に忠実であるのをやめるということではない。また、仕事に力をいれないということでもない。それは、自分と自分の興味・関心を企業と企業の興味・関心から分離して考えることを指している。 (P.283)

このあたりは、じっくりと考えていく必要があるのだろう。

さらっと読んだだけだが、発見の多い本だった。


Post It Plus でふりかえりの内容をキャプチャして共有

昨夜のXP祭りの実行委員ふりかえりを Post It Plus でキャプチャして共有してみました。


写真は内容を読めないように加工(blurフィルタ)しておりますが、オリジナルは付箋の内容までだいたい読めます。

今回のやり方

Post It plus を使ってキャプチャしたものを PowerPoint で出力して Google Drive 上で回転とか余分なもの削る、というフローで、とりあえず仲間に共有まではいけた。

写真共有と違って、付箋一枚一枚がオブジェクトなので多少いじることができたり、PowerPointでコメント入れたリが楽しそう。このあたりは既存のやり方(写真を取って加工)にないところなので、面白い使い道がありそう。

PostIT Plus で取り込むときに付箋が重なっていると認識が弱いので、離して貼るのがよさそう。

Rakuten Technology Conference 2014 および 前夜祭 前々夜祭

今年も楽天テクノロジーカンファレンスを10月25日に行う予定です!

これに先立って、前夜祭と前々夜祭も行われます!

ちなみに社内では、前野菜・全然野菜とも呼ばれ、たいへんヘルシーなことになっております。

Copeからの組織パターン研修へのお誘いメッセージ(ざっくり翻訳)

Copeからの組織パターン研修へのお誘いメッセージをざっくり翻訳してみました。
(I did quick translation of Cope's message to Japanese friends.)

This is to all my Scrum friends in Japan:
I'll be visiting you guys in a few weeks to enjoy the country and to continue work with some old partners.
While I'm there I once again will be running the seminar on "Improving your Scrum with Patterns" on 7 November.


日本にいる私のスクラムフレンドすべてに向けてのメッセージです。
私は数週間後に日本を訪問して、以前からのパートナーと一緒に仕事をします。
その間に、もう一度「パターンを使ってスクラムを改善する」研修を11月7日に行います。

This is a rare opportunity for ScrumMasters to learn concrete approaches to improve their teams' performance,
or for entire Scrum teams to come together to accelerate their practices.
This is what Kaizen mind is all about.
So if you've gotten started with Scrum and have been working hard to make your practices better over the past months or years,
and wonder how you can achieve the levels of performance that people like Jeff Sutherland talk about,
consider making an investment in this workshop.


これはスクラムマスターにとって、チームのパフォーマンスを改善する手法を学ぶ、とても貴重な機会です。
スクラムチーム全体にとっては、プラクティスをみんなでよりうまく使う方法を学ぶいい機会になります。
その正体は、改善マインドです。
ですから、もしあなたがスクラムを始めてから、何ヶ月も何年もプラクティスをよりよくするために頑張ってきたなら、
そしてジェフ・サザーランドさんが言うような素晴しいパフォーマンスをチームで達成するやり方を知りたいなら、
このワークショップに投資することを考えてみてください。

We will be describing how to use the Organizational Patterns that we have been writing over the years
— including patterns contributed by Mike Beedle, Gabrielle Benefield, Jeff Sutherland, Neil Harrison, myself,
and many more — to improve your Scrum. We'll be focusing on the patterns in the Organisational Patterns book.


私たちは組織パターンを使いこなす方法を説明します。組織パターンはスクラムを改善するために、何年もかけて、
マイク・ビードル、ガブリエル・ベネフィールド、ジェフ・サザーランド、ニール・ハリソン、私自身、
そしてもっと多くの人々の貢献を受けました。私たちは組織パターンの書籍を詳細にみていきます。

You can learn more at http://members.scrumalliance.org/courses/20144219-extended-education
or can sign up at http://agilergo.wufoo.com/forms/registration-agilergo-japan-2014/.
There's a substantial discount if you attend as a Scrum Team!
We hope to see you there!!


内容について詳しくはこちらに: http://members.scrumalliance.org/courses/20144219-extended-education
登録についてはこちら: http://agilergo.wufoo.com/forms/registration-agilergo-japan-2014/.
スクラムチームとして参加する場合には割引もします!
研修でお会いしましょう!



Kindle

組織パターン

組織パターン

Amazon
組織パターン (Object Oriented SELECTION)

組織パターン (Object Oriented SELECTION)

Kobo楽天ブックス

継続的乾杯

XP祭りの懇親会では(最近は大体そうなのだけど)、日本的な乾杯の概念をちょっと緩めて、乾杯をした。継続的乾杯と名付けた人がいて、なかなか素晴しいネーミングだと思った。

日本的な乾杯から、以下の制約をはずすだけでだいぶ快適になると思う。

  • 1. 乾杯の前には飲み物に口を付けるべきではない
  • 2. 乾杯は一度だけ
  • 3. 乾杯はスピーチ付き

1は特に海外の人に理解されづらい日本の慣習だと思う。「ウェルカムドリンク」と名を付けることで、日本の人にも比較的抵抗なく、この制約を外すことが受け入れられると思った。

2の制約を外すには、「乾杯の練習」と名付けるのがうまい作戦だと思った。コミュニティでよくやられている。

3は1-2と結びついた上に長くなると問題になるが、逆にそうでなければよいので、お願いの仕方を工夫すれば大丈夫だろう。いきなり振られても困るケースが多いので事前にお願いしておくのがよいと思う。とくに海外の人。


以上、私が発見したわけではないが、制約を緩めることに関して社会的認知が高まるとうれしい(やりやすい)ので、ここに記録に残してみた。

XP祭り2014 を開催した。

XP祭り2014を開催した。大きな事故もなく終えることができたのはみなさまのご協力のたまものだ。規模が大きくなっているのに、手作り感が残っているのがよいというご意見もいただいた。スタッフは少人数でそれなりに大変なので、実行委員をやっていただける方が、ボチボチと手を上げていただけると助かる。すでに手を挙げていただいた方もいる。毎年、「初めて来ました」という方が多いのが特徴だ。数年ぶりという方もいる。気軽に来て、なにか発表してみたり、他の方からエネルギーをもらったり、相談できる仲間を見つけてかえっていただけると、うれしい。

前説の資料はこちら。なるべくコンパクトにXPの説明と、XP祭りの説明を入れることを試みてみた。
https://speakerdeck.com/kawaguti/xp-matsuri-2014

今回は、Joseph Yoder もカンファレンスに寄ってくれた上に、トークもやってくれた。今後もタイミングが合えばぜひ英語でのセッションも用意できればと思う。5分でキッチリ銅鑼を鳴らすLTの形式に興味を持ってくれて、懇親会で5分スピーチにチャレンジしてくれたのが、とてもよかった。

ありがとうございました。

ゼネコンとITゼネコンとデスマーチと工程修正

よしおかさんがざっくりいいきるときは、だいたい適当なので、突っ込んだ方が損した気になったりするものなので、適当には適当で返しておこうと思います。なのでこちらの話はとても適当ですので、突っ込まれると知識不足が露呈しますが、予めご容赦ください。

システム管理者、感謝の日イベントに参加した。 - 未来のいつか/hyoshiokの日記

どんなプロジェクトも工期通りに終了する。工期が遅延して品質もぼろぼろといういわゆる「デスマーチ」のようなものは建設業ではほとんど起きないそうである。それはやっぱり工事現場だとものが出来ていくのが見えているので、ヤバい問題はわりと早く発見できるかららしい。結局、問題を可視化して、早期に問題を発見し、早め早めに手を打つということらしい。

建築プロジェクトではデスマーチの代わりに工期遅延が起こる

ワールドカップやオリンピックごとに、建築間に合うのか問題が起きているのは、日本じゃないから、という事なんでしょうか。うまくいってない工事というのもあり(東京青山の億ション工事で最強トリオが引き起こした前代未聞の大失敗)、そこまでいかなくても、ディテールを修正して間に合わせるという判断も起きているはず。そういう意味では、細かな要件の見送りや削減は日常茶飯事でしょう。土地図面の信頼性はあまり高くないらしいので、掘ってみないと分からないことは多いっぽいです。掘ってみたら遺跡が出てきて大幅な工期遅延ってよく聞きます。都市伝説かもしれませんが。

IT業界のゼネコンさんも同じこと言いますよね

たぶん、SIer(IT業界のゼネコンさん)も同じこと言うと思います。「うちは要件定義と調査能力に強みがあるので、発注いただいた後の工程の大きな変更は起きないですし、問題が起きてもすぐに対応していますので、デスマーチのようなことはなかなか起きないと思います。ただ、もちろん、お客様のご都合になるべくあわせ、最終的にはなんとかします。」とかとか。
実際は営業さんと付き合いがあまりないのでよく知りません。適当です。

分かってない人が出ていって約束しちゃう問題

ソフトウェア業界の問題は、従来は請け負ってこなかった分野をパワポ一つで取りにいってしまう、エンジニア経験のない営業さんが起こしている部分もあるのかもしれません。業務要件をきちんと理解し、PMBOKITILをきちんと勉強していれば防げるたぐいの凡ミスも多いんじゃないかと推察します。エンジニアサイドで昔からよく聞く話は「営業がこんなの約束してきやがった。」です。

あ、関係ないですけど、だいぶ前に、引っ越し屋さんも同じこといってました。

そもそもエンジニア知識を持っている人が足りない問題

たぶん、日本のソフトウェア業界ではエンジニアリング知識(コンピュータサイエンスとまで言わないまでも)を持った人がすくないので、そういう人が営業することもないし、顧客やユーザーとの折衝に入っていくことも最後の手段と見られています。そんなことよりコードを生み出せ、と言われていると思います。でも実際は、エンジニア知識がない人がたくさんのムダな仕事を生んでいたりして、結局すり切れるまでエンジニアが火消ししている、なんて状況がたまにあります。ちょっとできる若いエンジニアの人からすれば、そういう時に頼られることがカタルシスだったりしますし。

あ、これ20代くらいの自分を見返して書きました。すみません。

得意分野でないとこをカジュアルに攻めちゃう問題

建設業界のゼネコンさんって得意分野が明らかで、作ったことがあるものを量産するタイプのマンション建築ではそういうのが得意なメーカーさんが優位性を持っているようです。ちょっと難しいのを中心に請け負う最先端のメーカーさんもあるみたいです(ブランドがある)。構造設計が難しい橋梁建築も、特定の会社しか受けないと聞きます。

ITゼネコンさんも以前は分野が明らかで、ノウハウの蓄積先も明瞭だったのでしょうが、そのあたりが徐々に崩れてきて、技術者もキープできなくなって...というのがここ10-20年くらいの流れではないかと思います。これはたぶん順番としてはITが早くきていて(クラウド)、徐々にモノ作りメーカーの技術者に進んできている、という感じもします(もちろんモノ作りベンチャーさんは以前からたくさんいますけれど)。

追記: 建設業における労働災害発生状況

Facebook の方で、Yoshiya Tachikawa さんに、「事柄、建設業の方と接する機会が多いのですが、結構デスマーチありますよ。分かり易い例だと工事中の事故が起きた時とか。事故だけでも年間2万件以上ありますので。」というご指摘をいただきました。ITだと精神疾患が多く判定が難しいため、労災の適用になる比率は多くないかもしれません(そういう意味では、建設業界の方が労働災害が明確に見える化されている、と言えるかもしれないですが、そんなこと分かっても誰も得しないですね)。

建設業における労働災害発生状況
http://www.kensaibou.or.jp/data/statistics_graph.html

えーっと、こういったデータを元に、建設業界とIT業界の優劣を論じる気はありません。
ITゼネコン」という単語が正しいかどうかにも、興味はありません。