tuneの日記

アジャイル開発、組織変革、ファシリテーションについて学んだことの記録

LeSS Study LeSS本読書会 第1回 & 第2回に行ってきました

f:id:tune:20190321134657j:plain
サインをもらいました

大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法が1月末に発売され、LeSSの勉強会「LeSS Study」が読書会として再スタートすることになったので行ってきました。アジャイルスクラム・LeSSに関して突っ込んだ議論ができるとても楽しい会なのですが、ピザ&ビールを食べながらで翌日には記憶が曖昧になってしまうのが難点です。

LeSS Study LeSS本読書会 第1回

秋葉原のクラスメソッドさんでの開催でした。 内容は「読書会の説明」、「LeSS本の説明」、「LeSS でもっと多く: 2ページ」まで予定通り進みました。

以下質疑応答でかろうじて覚えているメモです。

Q: LeSSはスクラムなのか

A: スクラムである。原則にも「Large-Scale Scrumはスクラムである」と明確にかかれている。

LeSSはスクラムをベースに新しい役割やイベント、ルールを当てはめたものではなく、1つのスクラムを複数チームでやろうとした際に考慮した方がよいアドバイス集のようなイメージです。

Q : LeSSを構成する原理・原則が多いのではないか?

A: 確かにそうかも。

「透明性」や「顧客中心」などスクラムと重複しているものもある。 「LeSSはスクラムである」ならば、スクラムの原理原則をベースとして、LeSS固有の追加事項だけに記述を留めたほうが良いのかもしれない。

Q: システム思考ってどんなもの? 勉強にいい本ある?

A: 相互に作用する要素・関係性を整理し、どこを起点に改善を図っているかを考えるやり方。

例えばプロジェクトが遅延すると追加要員が送られる。開発メンバが増えるとコミュニケーションコストが増えさらにプロジェクトは遅延する。プロジェクトが遅延すると追加要員が送られ…といったよくある事象を関係で整理し、改善点を検討する。

LeSS Study LeSS本読書会 第2回

恵比寿 Redhatさんでの開催でした。 第2章が対象でしたが、途中の議論が盛り上がりスプリントプランニングぐらいしか話していません。

Q: スプリントプランニング1に代表者しか来ないとあるけど、残りの人は何しているの?

A: 対して長くないから気にしなくても大丈夫。

1チームスクラムのプランニングと異なり、LeSSのスプリントプランニング1はどのチームが何のストーリを担当するかを「ざっくりと」決めるものなので短いです。プロダクトオーナーがバックログを付箋に書いて持ってきて、チーム代表者の前にがさっと置き、代表者が好き好きに好きなものを持っていくぐらいのイメージです。事前にプロダクトバックログリファインメントでどんなストーリーが来るのか確認しているのでここで長い議論になることはないのだと思います。

Q: スプリントプランニング1でバックログの優先順位を考慮しなくて良いのか?

A: チームにストーリーの分配が終わった後で優先順位が高いものが残った場合、プロダクトオーナーがチームと交渉すれば良い。「このストーリーと交換できないか」とか。

Q: 書籍では「預託チーム」「取引チーム」「非デリバティブチーム」となっているが、チーム分けはどうするのか?

A: 顧客視点の機能で分けるフィーチャーチームが基本。コンポーネントチームではない。

とはいえ書籍のチーム名はコンポーネントチームに見えなくもない。「預託コンポーネント」とかありそう。 実際の現場では機能と関係がないチーム名をつけ、「預託に強いチーム」「取引に強いチーム」といった認識を裏で持っておくぐらいで良いが、書籍での説明のしやすさのため今の形に落ち着いているのかもしれない。

スクラムマスターは保育園の先生に似ているという話もあるので、「うさぎさんチーム」「くまさんチーム」といった名前でも良いかもしれない。

Q: 単一チームでプロダクトバックログリファインメント(PBR)したストーリーを別チームに割り振ってもいいの?

A: ダメじゃないけど、どのチームが担当しても良いストーリーは複数チームでPBRした方が良い。

「複数チームPBR」は、A・B・Cの3チームがあった時、3チームで順繰りに見積もりを行なって結果をまとめるということではない。A・B・Cのメンバをごちゃ混ぜにし、3グループに分け、3グループに見積もり対象のストーリーを1/3ずつ分け、それで見積もりを行う方式である。したがって見積もりに要する時間は単一チームに見積もらせる時と変わらない。

複数チームPBRを行う利点として、チーム横断で議論できることで観点の見落としが減り、ストーリーポイントなどの見積もりも自然と揃ってくることがある。また実際にチームがストーリーに着手した際も誰かしらストーリーの詳細を把握している人がチームにいることが期待できる。

Q: スプリントプランニング1でチームに自由に取らせると偏りが出て、得意なものばかりやるのでは?

A: あるチームが優先順位の高いストーリーばかりを担当するなど、スプリントを始めるにあたって課題がある場合、プロダクトオーナー・他チームとストーリーの交換など調整をすることになる。この時に「得意じゃないけど、担当できる」ストーリーが割り当てられることになるので、スプリントを長く続けていると偏りは出にくくなる。

Q: スプリントプランニング2は共有スペースで行うの?

A: その通り。複数チームで行う時は広い場所で行う。大きい会議室、食堂など。

計画時に他チームと調整が必要になった時にすぐに話せるようにするため。 リモートサイトのチームがあるときはスプリントプランニング2の時はテレビ会議を繋ぎっぱなしにし、部屋のある一角に移動したらすぐに話し始められるようにする。


大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法

大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法

awesome-agile-workshopを作っています

github.com

はじめに

少し前に流行った便利なライブラリなどをまとめる "awesome-XXX"のノリで、アジャイル開発、スクラム開発、チーム開発で使えそうなアクティビティ・ワークショップの情報をまとめてみました。日々いろんな取り組みの情報が流れてきますが、忘れてしまいがちなので。

漏れてるもの、もっと良い情報源などありましたらPull Requestお待ちしています。

変革の軌跡【世界で戦える会社に変わる"アジャイル・DevOps"導入の原則】

変革の軌跡【世界で戦える会社に変わる

変革の軌跡【世界で戦える会社に変わる"アジャイル・DevOps"導入の原則】

だいぶ前に読んでいた本ですが、まとめてみました。

この本はどんな本か?

HPのプリンタでのファームウェア開発における事例をもとに、巨大な組織でハードウェアが絡む製品開発をアジャイルに進めるやり方を紹介した本です。

他のアジャイル本と比較して上位の経営幹部向けだと感じました。DeoOpsなど実践に関する説明は少ないです。

大組織におけるソフトウェア開発の変革

既存の大組織の多くがソフトウェア開発・デリバリーに苦しんでいる。 その結果、市場で競争したり、ソフトウェアでイノベーションを起こすことが困難になってきている。

大企業でソフトウェア開発を変革するには、チーム同士が協力し価値を生み出す仕組みづくりをまず考える。 それぞれのチームの働き方はその次である。

経営幹部が主導する

単にアジャイルに取り組むことを目的にしない。

エンタープライズレベルの継続的改善プロセスは経営幹部が作る必要がる。 なぜならば組織内のリソースを割り当てられる唯一の存在であり、バリューチェーンの端から橋までを見ることができるからである。

経営幹部はエンタープライズレベルで計画を推進し、進捗を把握できる戦略的な目標を設定する。

  • 通常4〜7個の上位目標
  • 測定可能な小項目

経営幹部は組織全体と共同して目標を設定し、この目標が重要であり達成可能だと全員が感じられるようにする。

アジャイルに取り組むための「正しい方法」を決めてしまうと、次にその正しい方法を全員に教えなければと思い始めてしまう。 リーダーとして、可能な限り目標ととともにフレームワークを提供し、仕事の進め方に関しては最大限の裁量をチームに与えることが重要である。 これによってチームは仕事により興味を覚え、結果に対するオーナーシップを高めることになる。

ビジネス目標を設定し、継続的改善プロセスを実施し続けることで、経営幹部やマネージャーを巻き込み、彼らに変革をリードさせる。 組織全体にわたる計画プロセスやデリバリープロセスの改善に注力する。

頻繁に結合する文化を作る

ブランチを切らず、全員がメインブランチで開発を進める。これにより頻繁な統合を促すことができる。 メインブランチで開発するにはテクニックが必要である。

  • 既存のコードを壊す変更を実装しない。
  • 既存の機能を壊すことなく、コードの大規模なリファクタリングを可能にする。
  • フィーチャーフラグなどを導入し、新しいコードをコミットしつつ、システムの他の部分からは使わせない。
  • 既存の機能を壊さずにデータベースのスキーマを変更する。

自動テストなどを拡充し、メインブランチは常に安定する状態を保たなければならない。

  • コードをコミットする際、自動化された受入テストに合格するまでその場を離れてはいけない
  • 壊れたビルドに続けてコードをコミットしてはならない。

アジャイルに開発された戦闘機 SAAB社グリペンについて

f:id:tune:20130924141653j:plain

はじめに

アジャイル開発、スクラム開発の研修資料で「戦闘機だってアジャイルに作れる」という事例紹介で、よく引用されている気がするのですが、なかなかまとまった情報が見つからないのでここにまとめておきます。

SAAB社・グリペンについて

グリペンの特徴

  • 戦闘機が帰還したのち、システムをシャットダウンしてから再始動、再び滑走路へ出ていくまでの時間「ターンアラウンドタイム」が10分。
    • F-15F-16では、おおむね2時間から3時間
  • 機体は可能な限りシンプルに、かつ必要な機器が最低限となるよう、設計時から配慮されている。
    • 1名の監督者と5名の整備員でターンアラウンド中の整備ができる。
    • 設備の整った航空基地だけでなく、高速道路を流用した臨時飛行場でも上記対応が可能。
  • 製造単価から燃料、廃棄に至るまでに必要な経費「ライフサイクルコスト」が1機あたり約100億円と安い。
    • 航空自衛隊が擁する三菱F-2戦闘機のライフサイクルコストは1機あたり370億円

SAAB社におけるアジャイル開発

モジュールごとにチーム開発

ソフトウェア開発におけるオブジェクト思考的な考えを取り入れ、コクピット・機体・エンジンなどの単位でチームを組織している。

スクラムの適用

スプリントは3週間区切り、全チームがタイミングを揃えている。

デイリースクラムは4096人が開発に従事し、毎日Scrum of Scrumsで1時間内に情報共有を終える。

  • 7:30 Daily Scrum
  • 7:45 Scrum of Scrums
  • 8:00 Scrum of Scrum of Scrums
  • 8:15 Scrum of Scrum of Scrum of Scrums
  • 8:30 Executive Action Team

その他

会社の誰もがいつでも現在の3Dモデル、ソフトウェアにアクセスすることができる。またこれらを元にしたフライトシミュレータを使うことができる。

情報源

Agile In Military Hardware - How the SAAB Gripen became the world’s most cost effective military aircraft

Owning the Sky with Agile

trafficnews.jp

Engineering Manager Meetup #4で「1つの大きなプロダクトをみんなで作る」を話してきました #em_meetup

speakerdeck.com

はじめに

昨年からSlackに参加していたEngineering ManagerコミュニティでMeetupがあるというので参加 & 発表してきました。 開催してくださった ohbaryeさん、素敵な会場を提供いただいたRettyさん、発表にコメントいただいたみなさま、どうもありがとうございました。

engineering-manager-meetup.connpass.com

Twitterでいただいたコメント

機能別チーム、技術負債返却チーム

みる範囲が明確になるのはメリットだけど、コードが別れて独自進化を遂げていくのが問題なんですよね。

みんなで立ち止まって一斉に負債返却するとまだいいんですけどね。短期で終えないと難しいと思っています。

あるあるなんですね!

コンポーネントチームの問題点

あるあるです、でもコンポーネントチームやめられないプロジェクトが多いなーと感じています。

フィーチャーチームについて

勉強会で紹介したサイトは下記です。「Googleで"フィーチャーチーム"と検索し、1番目に出てくるサイトに全て書いてあります。」

featureteamprimer.org

そうなんです!私も研修受けた後に知ってびっくりしました。

チーム名の決め方

ぜひ試してみてください!

テーマを持たせて決めるのも面白いですね!

自分たちで決めると愛着湧くみたいですよ。

コンポーネントに監督者を置く

監督者を置いて、監督者を中心にチームを作っちゃうからコンポーネントチームができるのかなと思っています。

技術を見れる人がたくさんいるならコミュニティー感を出すために「メンター」がいいと思います。 「コードオーナー」は意味があまりブレないので、コンポーネントみれる人が少ない時はおすすめです。

LeSS/LeSS本について

ググりにくい単語です。"less agile"とか"less scrum"とするといい感じです。

売れてる気がする!

その他

学びは多かったです。ただ実は「組織変更」はしていません。組織は既存のまま、プロジェクト体制だけLeSSでいろいろいじってます。組織を作ってプロジェクト体制を整える会社が多いですが、うまくいくプロジェクト体制を作ってから組織を後から直す方が楽じゃないかと思っています。

実は私も行ったことがありません。本が出て読書会がリブートするという話もあるので期待しています。

SAFeもアジャイル開発をスケーリングさせる手法ですがアプローチが異なります。LeSSは調整役をできる限り置かないアプローチですが、SAFeは調整役を積極的に置く仕組みです。

バックログアイテムに重い責任を伴うものが紛れていると、ババを引いたチームが出てきてしまうことはありえますね。 いいお題として対策を考えてみることにします。

こちらこそありがとうございました!

バックログに積むユーザーストーリーを考える参考にアプリのリリース文を見る

f:id:tune:20190127000743p:plain

はじめに

RGSTのOSTトピックの一つに「ユーザーストーリーを取扱説明書に例えるのはどう思う?」*1があり、参加しました。

議論の中で「プロダクトオーナーは"プレスリリースから考える"といいという話が昔あったけど、最近はスマホアプリのリリース文が参考になる」というコメントがありました。

「プレスリリースから考える」はAmazon発だった気がしますが、下記記事でも言及されています。

type.jp

アプリによって個性があるようなので、普段使っているアプリのリリース文を集めてみました。

アプリのリリース文

以下、順不同です。

Slack

Slack

Slack

  • Slack Technologies, Inc.
  • ビジネス
  • 無料

3.59 2019年1月8日
新着情報 
• あけましておめでとうございます!2019 年最初の新着情報は… 画像アップロード機能の改善から!jpeg 画像を圧縮してアップロードするようにしたことで、スピードと信頼性が向上しました。今までどおり圧縮しないでアップロードしたい場合は、「設定」 > 「詳細設定」から設定を切り替えることもできますのでご安心を。 

バグ修正 
• 修正 : iPad で外付けキーボードを使用する際に、キーボードショートカットの一部が機能しないという不具合がありましたが、これを修正しました。キーボードでも道でも、使えるはずの「ショートカット」が使えないとイラっとしますよね。大変失礼しました! 
• 修正 : アカウントが解除されたユーザーとの DM セッションへの切り替えにクイックスイッチャーを使えるようになりました。人がチームを離れても知識は残りますので、これで今後もその知識を活用できて便利ですね。

まずはOSTでも褒められていたSlack、かなりフランクな文体です。年始の挨拶も目を引きますが、バグ修正に対し、ユーザがどう困っていたかが記載されているのが面白いなと思いました。

SmartNews

スマートニュース

スマートニュース

6.0.5 2019年1月23日
- より快適にご利用いただけるよう細かな改善を行いました。
- 新チャンネルが登場しました。「超!アニメディア」「with online」「くるまのニュース」「清水エスパルス」「川崎フロンターレ」「Ray」「STVニュース北海道」

毎日ニュースを読むのに使っています。書く人が変わっているのか2018年の頭は「不具合の修正や改善を行いました。」とそっけなかったものが、2018年の中頃は「画面下部をリニューアルし、チャンネルを一覧できるボタンを右下に設置しました。」と具体的な修正に言及するようになりましたが、現在は「細かな改善」にまとめてしまっているようです。何を改善しているんでしょう???

LINE

9.0.0 2019年1月21日
■トークルームでLINE絵文字をタップ、もしくは長押しして表示されるメニューの[ショップ]をタップすることでLINE絵文字の購入ページを表示できる機能を追加
■トークルームで画像を長押しして表示されるメニューに[アルバム]を追加し、直接アルバムへ保存できるように改善
■写真を選択する画面を改善
・選択した写真を一目で確認できるように画面の下段に選択された写真の一覧を表示
・選択する写真のフォルダーにアクセスしやすく改善
■近日中にLINE QUICK GAME新作タイトルの追加と一部タイトルのアップデートを予定

ユーザーストーリーっぽく書かれているなと感じました。私のイメージはもっと親しみやすくフレンドリーなアプリですが、技術力が確かな会社だからか、しっかりエンジニアリングをわかっている方が書いているのかもしれません。

Eight

Eight - 100万人が使う名刺アプリ

Eight - 100万人が使う名刺アプリ

  • Sansan, Inc.
  • ビジネス
  • 無料

9.0.2 2018年12月18日
アプリをリニューアルしました。
主なアップデートは以下の通りです。
● 名刺登録がもっとスマートに
- 2ステップで名刺登録が可能になりました
- 名刺撮影時にラベル付けやお礼メールの送信ができるようになりました
● 人脈情報や企業情報の活用が容易に
- 名刺の情報に素早くアクセスできるようになりました
- 接点がある企業の概要情報やつながりが確認できるようになりました

● 効率的な近況チェック
- 近況フィードをカスタマイズできるようになりました

● データ化がパワーアップ
- 名刺の裏面も入力対象になりました(プレミアム機能)

これからも皆さまのビジネスをサポートできるよう機能改善に努めてまいります。
お気付きの点がありましたら、アプリ内「自分」タブの「ご意見・不具合のご報告」からご連絡ください。

最近使い始めました。改善内容をカテゴリ分けしているのが特徴でしょうか。

JapanTaxi

JapanTaxi(旧:全国タクシー)

JapanTaxi(旧:全国タクシー)

  • JapanTaxi Co.,Ltd.
  • 旅行
  • 無料

4.3.1 2019年1月16日
[機能改善]
- 乗車体験を改善する為、乗車後に注文結果画面で乗務員に対する評価を訴求するダイヤログを表示するように修正しました。
- 付近のタクシーを検索中画面を表示中にネットワークが切れた時、注文条件を変更のダイヤログが表示されてしまうバグを修正しました。
- 注文結果画面から行き先画面に遷移した際に、行き先だけでなく現在地も地図上に表示されるように修正しました。
- 中国語表示の際、乗車カード画面で文字が切れてしまうバグを修正しました。
- Amazon Alexa画面から遷移するお気に入り画面のレイアウトを修正しました。
- 注文時のタクシー会社画面のレイアウトを修正しました。
- お気に入りの地図で場所を登録する画面の文言を修正しました。

[開発後記]
明けましておめでとうございます。
本年もよろしくお願い申し上げます。

年末年始、多くの方にご利用いただきありがとうございました。
私も地元の愛媛に帰省する際に利用しておりました。
東京都内だと公共交通機関が発達しているので、タクシーの他に電車やバスといった選択肢があるのですが、愛媛は車がないと移動が不便なことが多いです。
帰省した際に旧友とお酒を飲むことが多いのですが、車は運転できないので、タクシーを簡単に呼べるアプリはやはり重要だなと再確認しました。

多くのタクシー会社さんに協力をいただいて、地方のタクシー乗車体験も良くしたいと考えていますので、「メニュー」>「アプリについて」>「お問い合わせ」よりご要望をいただけると幸いです。
今後とも応援をよろしくお願いします!

JapanTaxi開発チーム

細かな修正が記載してあるのに加え、開発後記があるのが目を引きます。開発者がどんなことを考えているのかはなかなか聞く機会がないですからね。

Facebook

205.0 2019年1月25日
このアプリは、快適にご利用いただけるよう、定期的にアップデートされます。すべての機能をご利用いただくには、最新バージョンをダウンロードしてください 各種不具合の修正とパフォーマンスの向上。 Facebookをご利用いただきありがとうございます。

壊れたロボットのように基本これしかありません。

Amazon

Amazon ショッピングアプリ

Amazon ショッピングアプリ

  • AMZN Mobile LLC
  • ショッピング
  • 無料

13.1.0 2019年1月9日
今回のリリースではバグ修正及び動作パフォーマンスを改善しました。

お前もか… 基本これしか無いようです。

Pokémon GO

Pokémon GO

Pokémon GO

1.99.2 2018年12月15日
- 新しい対戦機能「トレーナーバトル」をお楽しみいただけるようになりました。
- 近くのトレーナーの「対戦コード」を読み取ることで「トレーナーバトル」ができます。
- 「親友」または「大親友」のフレンドなら、離れた場所からでも「トレーナーバトル」ができます。
- チームリーダー(スパーク、キャンデラ、ブランシェ)とも「トレーナーバトル」ができます。
- 「トレーナーバトル」は3つの「バトルリーグ」に分かれています。それぞれの「バトルリーグ」ごとに、参加できるポケモンの最大CP上限値が異なります。
- 「トレーナーバトル」をプレイすると、トレーナーはリワードを獲得できます。
- トレーナーのスタイルに新しい髪の色と肌の種類が追加されました。

ゲームをする人目線の書き方ですね。ゲームは書きやすいのかな?

終わりに

やはりSlackが群を抜いて面白いですね。面白いリリース文を出しているアプリがあればおしらせください。

*1:すみません、テーマ名うろ覚えです

NETFLIXの最強人事戦略 私的まとめ

NETFLIXの最強人事戦略 自由と責任の文化を築く

NETFLIXの最強人事戦略 自由と責任の文化を築く

2018年に読んだ本でダントツ一番おもしろい本でした。

この本はどんな本か?

Netflixが自社の文化をまとめた「カルチャーデック」という資料をベースとし、Netflixの人事哲学が語られています。

jobs.netflix.com

tkybpp.hatenablog.com

Netflixの人事哲学

コミュニケーション

  1. 徹底的に正直であること。
  2. 徹底的に議論を戦わせること。
  3. コミュニケーションは双方向であること

いつでも間違いを認め、正しい選択ができなければならない。 そのために徹底的に議論を戦わせる必要がある。 Netflixでは「問題がおこったら当事者同士でオープンに話し合う」ことが重要な約束事となっている。 またコミュニケーションは双方向でなければならない。経営陣は会社の戦略や事業運営、業績に関する情報を正しく従業員に伝えなければならない。 また従業員は知りたいことを自ら問わなければ答えを得ることはできない。

誰かがバカなことをしているというのなら、それは情報を与えられていないか、誤った情報を与えられたせいである。 能力が不足しているためではない。 上層部から正しい情報を下ろさなければ、従業員は他の誰かから誤った情報を与えられる可能性が高い。

チーム・組織づくり

優れたチーム作りに本気で取り組むことが、経営陣にとって一番重要な仕事である。 「今のチームが理想でないことが、会社の成長の足かせになっていないか」を常に問い続けなければならない。

ただし、これは「これは従業員を育て、鍛える必要がある」という意味ではない。

  • 従業員に能力を超えた仕事、才能と合わない仕事を与える義務はない。
  • 長年の貢献に報いるためにポストを用意する義務もない。
  • 誰かに遠慮して重要な人事変更を控える義務もない。

会社は家族ではなくスポーツチームである。 だから優れた成績を挙げていないプレイヤーは交代させなければ、チームやファンをがっかりさせてしまう。 会社の将来に必要な人材は社外からも広く探して最善の人材をポストに当てる。

解雇された従業員が会社を相手に訴訟を起こす可能性は、とくに業務上の課題について定期的に話し合いを持っていた場合はゼロに近い。 キャリアマネジメントはあくまで従業員自身の責任である。マネージャーの責務ではない。

従業員にとって最高の特典や催しは立派な福利厚生や働きやすい職場環境ではなく、事業や顧客について理解を深められる機会である。 最高の人材や優秀な専門家が、会社の最も差し迫った問題を議論する様子を間近で見させ、その議論に参加させる。 これ以上の学習機会・成長機会は無い。

採用

  1. 優れた人材の採用と従業員の解雇は主にマネージャーの責任である。
  2. すべての職務にまずまずの人材ではなく、最適な人材を採用するように務める。
  3. どんなに優れた人材でも会社が必要とする職務にスキルがあってないと判断すれば進んで解雇する。

いつでも最高の人材を補充できるとわかっていなければ、安心して解雇することができない。 だからヘッドハンティング会社から人材を引き抜いて、社内に採用機能を構築した。

本当に欲しい人材を獲得するためには、社内の給与水準やルールなどに縛られることなく、現実の市場の需要に対応するしかない。

人事評価

ほとんどの企業の人事施策や制度はどれもお金がムダにかかる上、「インセンティブをもらい、支持されなければ動けない」という人間に関する誤った考えを前提としている。 Netflixでは従業員にトップレベルの給与を支払い、高い業績をあげるようにハッパをかけている。

人事考課は評価を給与・報酬と連動させているから大変な手間をかけて行なっているだけで、なんの成果も生み出していない。 人事考課と給与・報酬を分離し、給与は会社業績だけに連動させれば人事考課を行わず、従業員成長のためのフィードバックのみに注力できる。。

まとめ

効率の良い働き方を目指し、従来の慣習を見つめ直し、不要なルール・取り組みを無くしていった結果の働き方だと感じました。 全てが「その通り」と同意できるものではありませんが、Netflixの事例をきっかけに自社・自分たちのやり方を見直すのは価値があることだと考えます。

上にあげた事項だけでも十分刺激的ですが、下記の内部暴露はさらに刺激的です。

www.gizmodo.jp