変革の軌跡【世界で戦える会社に変わる"アジャイル・DevOps"導入の原則】
変革の軌跡【世界で戦える会社に変わる"アジャイル・DevOps"導入の原則】
- 作者: Gary Gruver,Tommy Mouser,吉羽龍太郎,原田騎郎
- 出版社/メーカー: 技術評論社
- 発売日: 2017/01/25
- メディア: 単行本
- この商品を含むブログ (1件) を見る
だいぶ前に読んでいた本ですが、まとめてみました。
この本はどんな本か？
HPのプリンタでのファームウェア開発における事例をもとに、巨大な組織でハードウェアが絡む製品開発をアジャイルに進めるやり方を紹介した本です。
他のアジャイル本と比較して上位の経営幹部向けだと感じました。DeoOpsなど実践に関する説明は少ないです。
大組織におけるソフトウェア開発の変革
既存の大組織の多くがソフトウェア開発・デリバリーに苦しんでいる。 その結果、市場で競争したり、ソフトウェアでイノベーションを起こすことが困難になってきている。
大企業でソフトウェア開発を変革するには、チーム同士が協力し価値を生み出す仕組みづくりをまず考える。 それぞれのチームの働き方はその次である。
経営幹部が主導する
単にアジャイルに取り組むことを目的にしない。
エンタープライズレベルの継続的改善プロセスは経営幹部が作る必要がる。 なぜならば組織内のリソースを割り当てられる唯一の存在であり、バリューチェーンの端から橋までを見ることができるからである。
経営幹部はエンタープライズレベルで計画を推進し、進捗を把握できる戦略的な目標を設定する。
- 通常4〜7個の上位目標
- 測定可能な小項目
経営幹部は組織全体と共同して目標を設定し、この目標が重要であり達成可能だと全員が感じられるようにする。
アジャイルに取り組むための「正しい方法」を決めてしまうと、次にその正しい方法を全員に教えなければと思い始めてしまう。 リーダーとして、可能な限り目標ととともにフレームワークを提供し、仕事の進め方に関しては最大限の裁量をチームに与えることが重要である。 これによってチームは仕事により興味を覚え、結果に対するオーナーシップを高めることになる。
ビジネス目標を設定し、継続的改善プロセスを実施し続けることで、経営幹部やマネージャーを巻き込み、彼らに変革をリードさせる。 組織全体にわたる計画プロセスやデリバリープロセスの改善に注力する。
頻繁に結合する文化を作る
ブランチを切らず、全員がメインブランチで開発を進める。これにより頻繁な統合を促すことができる。 メインブランチで開発するにはテクニックが必要である。
- 既存のコードを壊す変更を実装しない。
- 既存の機能を壊すことなく、コードの大規模なリファクタリングを可能にする。
- フィーチャーフラグなどを導入し、新しいコードをコミットしつつ、システムの他の部分からは使わせない。
- 既存の機能を壊さずにデータベースのスキーマを変更する。
自動テストなどを拡充し、メインブランチは常に安定する状態を保たなければならない。
- コードをコミットする際、自動化された受入テストに合格するまでその場を離れてはいけない
- 壊れたビルドに続けてコードをコミットしてはならない。
アジャイルに開発された戦闘機 SAAB社グリペンについて
はじめに
アジャイル開発、スクラム開発の研修資料で「戦闘機だってアジャイルに作れる」という事例紹介で、よく引用されている気がするのですが、なかなかまとまった情報が見つからないのでここにまとめておきます。
SAAB社・グリペンについて
グリペンの特徴
- 戦闘機が帰還したのち、システムをシャットダウンしてから再始動、再び滑走路へ出ていくまでの時間「ターンアラウンドタイム」が10分。
- 機体は可能な限りシンプルに、かつ必要な機器が最低限となるよう、設計時から配慮されている。
- 1名の監督者と5名の整備員でターンアラウンド中の整備ができる。
- 設備の整った航空基地だけでなく、高速道路を流用した臨時飛行場でも上記対応が可能。
- 製造単価から燃料、廃棄に至るまでに必要な経費「ライフサイクルコスト」が1機あたり約100億円と安い。
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モデル、ソフトウェアにアクセスすることができる。またこれらを元にしたフライトシミュレータを使うことができる。
情報源
Engineering Manager Meetup #4で「1つの大きなプロダクトをみんなで作る」を話してきました #em_meetup
はじめに
昨年からSlackに参加していたEngineering ManagerコミュニティでMeetupがあるというので参加 & 発表してきました。 開催してくださった ohbaryeさん、素敵な会場を提供いただいたRettyさん、発表にコメントいただいたみなさま、どうもありがとうございました。
engineering-manager-meetup.connpass.com
Twitterでいただいたコメント
機能別チーム、技術負債返却チーム
機能でわける。その時縦割りになっていってしまう可能性がありそうって懸念でるよなぁ。
— つよぽそ (@cobasparxxx) February 1, 2019
#em_meetup
みる範囲が明確になるのはメリットだけど、コードが別れて独自進化を遂げていくのが問題なんですよね。
技術的負債を返済するチーム、でかいテーマがあったときに一時的にプロジェクトにしてそれだけやったことあったけど、PMが優秀でうまくいったことがある#em_meetup
— ナカハシ (@k_nakahashi) February 1, 2019
みんなで立ち止まって一斉に負債返却するとまだいいんですけどね。短期で終えないと難しいと思っています。
機能追加チームと負債返却チームに分割したら空気が悪くなった話、あるある過ぎる #em_meetup
— Teppei Sato (@teppeis) February 1, 2019
あるあるなんですね！
コンポーネントチームの問題点
要件が固まっていなくて開発ができない→リリースが遅れる→会議が増える→よくないスパイラル。あるあるだなー#em_meetup
— 水殿 #技書博2スタッフ (@midono_ap1) February 1, 2019
あるあるです、でもコンポーネントチームやめられないプロジェクトが多いなーと感じています。
フィーチャーチームについて
勉強会で紹介したサイトは下記です。「Googleで"フィーチャーチーム"と検索し、1番目に出てくるサイトに全て書いてあります。」
LeSSを作った2人の文章か！https://t.co/2BCaM2wbFP
— ゆのんEMFM/EOF2019 (@yunon_phys) February 1, 2019
#em_meetup
そうなんです！私も研修受けた後に知ってびっくりしました。
チーム名の決め方
フィーチャーチームのチーム名を全く関係ない名前にすると名前がチームの役割に紐付かなくなってチームの結束力が高められる、よさそう#em_meetup
— 水殿 #技書博2スタッフ (@midono_ap1) February 1, 2019
ぜひ試してみてください！
うちのチーム名は伊賀、甲賀、風魔、戸隠です。テスト用のドメインは.ninjaです。 #em_meetup
— Teppei Sato (@teppeis) February 1, 2019
テーマを持たせて決めるのも面白いですね！
機能名をそのままチーム名は、分からなくはないけど、毎日呼んで呼ばれるんだから、面白くてテンション上がるような名前つけたいなぁ🐷 #em_meetup
— yum-t (@_yum_t) February 1, 2019
自分たちで決めると愛着湧くみたいですよ。
コンポーネントに監督者を置く
実装上の設計はチームに委ねて、コンポーネントに監督者を置く（機能的な部分をチェックしてコードをマージする人）。今やってるやり方に近い気がする。 #em_meetup
— Kou.N (@KouN1847) February 1, 2019
監督者を置いて、監督者を中心にチームを作っちゃうからコンポーネントチームができるのかなと思っています。
うちはコンポーネントメンターって名前でやってたな。ここでも名前がことなるが同じことやる問題がｗ #em_meetup
— daisuke sato (@dskst9) February 1, 2019
技術を見れる人がたくさんいるならコミュニティー感を出すために「メンター」がいいと思います。 「コードオーナー」は意味があまりブレないので、コンポーネントみれる人が少ない時はおすすめです。
LeSS/LeSS本について
LeSSって初めて聞いた。
— Ippo Matsui / Ginco EM (@ippo_012) February 1, 2019
Large Scale Scrumの略なのね。#em_meetuphttps://t.co/REJfRtUbpj
ググりにくい単語です。"less agile"とか"less scrum"とするといい感じです。
そいえば、ちょうど LeSS の本が発売されましたね！ #em_meetuphttps://t.co/evfEw32gnN
— daisuke sato (@dskst9) February 1, 2019
ちょうどLeSSの本が昨日発売されてた #em_meetup https://t.co/Mlyl0Tp3x7
— こまど (@ky_yk_d) February 1, 2019
丁度明日届く！🐷#em_meetup
— yum-t (@_yum_t) February 1, 2019
大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法 https://t.co/Ti2vuf7Y6n
売れてる気がする！
その他
こんだけ組織変更の実験ができるって羨ましい。 大きな学びを得られるはず。#em_meetup
— 久津佑介(HisatsuYusuke)🔥プロダクトマネージャー (@Nunerm) February 1, 2019
学びは多かったです。ただ実は「組織変更」はしていません。組織は既存のまま、プロジェクト体制だけLeSSでいろいろいじってます。組織を作ってプロジェクト体制を整える会社が多いですが、うまくいくプロジェクト体制を作ってから組織を後から直す方が楽じゃないかと思っています。
たぶんここで読書会してる。 https://t.co/phNipmqZd3 #em_meetup
— ろずにゃっく (@i47_rozary) February 1, 2019
実は私も行ったことがありません。本が出て読書会がリブートするという話もあるので期待しています。
SAFe(Scaled Agile Framework)もあるというのを教えていただいた☺️#em_meetup https://t.co/TYTc4hc36u
— Ippo Matsui / Ginco EM (@ippo_012) February 1, 2019
SAFeもアジャイル開発をスケーリングさせる手法ですがアプローチが異なります。LeSSは調整役をできる限り置かないアプローチですが、SAFeは調整役を積極的に置く仕組みです。
LeSS すごい楽しいよねー！うちの会社では責任が分散して失敗したことがあるので、プロダクトに同責任を持つかが大事です。サーバアラートはどのチームがやるの？とか。コンポーネントメンターとか機能すればうまくまわったのかなー #em_meetup
— daisuke sato (@dskst9) February 1, 2019
バックログアイテムに重い責任を伴うものが紛れていると、ババを引いたチームが出てきてしまうことはありえますね。 いいお題として対策を考えてみることにします。
OST風懇親会でLeSSとスクラムのお話してくださった皆さんありがとうございました！またお会いしたい！#em_meetup
— たにさん (@tany3_) February 1, 2019
こちらこそありがとうございました！
バックログに積むユーザーストーリーを考える参考にアプリのリリース文を見る
はじめに
RGSTのOSTトピックの一つに「ユーザーストーリーを取扱説明書に例えるのはどう思う?」*1があり、参加しました。
議論の中で「プロダクトオーナーは"プレスリリースから考える"といいという話が昔あったけど、最近はスマホアプリのリリース文が参考になる」というコメントがありました。
「プレスリリースから考える」はAmazon発だった気がしますが、下記記事でも言及されています。
アプリによって個性があるようなので、普段使っているアプリのリリース文を集めてみました。
アプリのリリース文
以下、順不同です。
Slack
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
9.0.2 2018年12月18日 アプリをリニューアルしました。 主なアップデートは以下の通りです。 ● 名刺登録がもっとスマートに - 2ステップで名刺登録が可能になりました - 名刺撮影時にラベル付けやお礼メールの送信ができるようになりました ● 人脈情報や企業情報の活用が容易に - 名刺の情報に素早くアクセスできるようになりました - 接点がある企業の概要情報やつながりが確認できるようになりました ● 効率的な近況チェック - 近況フィードをカスタマイズできるようになりました ● データ化がパワーアップ - 名刺の裏面も入力対象になりました（プレミアム機能） これからも皆さまのビジネスをサポートできるよう機能改善に努めてまいります。 お気付きの点がありましたら、アプリ内「自分」タブの「ご意見・不具合のご報告」からご連絡ください。
最近使い始めました。改善内容をカテゴリ分けしているのが特徴でしょうか。
JapanTaxi
4.3.1 2019年1月16日 [機能改善] - 乗車体験を改善する為、乗車後に注文結果画面で乗務員に対する評価を訴求するダイヤログを表示するように修正しました。 - 付近のタクシーを検索中画面を表示中にネットワークが切れた時、注文条件を変更のダイヤログが表示されてしまうバグを修正しました。 - 注文結果画面から行き先画面に遷移した際に、行き先だけでなく現在地も地図上に表示されるように修正しました。 - 中国語表示の際、乗車カード画面で文字が切れてしまうバグを修正しました。 - Amazon Alexa画面から遷移するお気に入り画面のレイアウトを修正しました。 - 注文時のタクシー会社画面のレイアウトを修正しました。 - お気に入りの地図で場所を登録する画面の文言を修正しました。 [開発後記] 明けましておめでとうございます。 本年もよろしくお願い申し上げます。 年末年始、多くの方にご利用いただきありがとうございました。 私も地元の愛媛に帰省する際に利用しておりました。 東京都内だと公共交通機関が発達しているので、タクシーの他に電車やバスといった選択肢があるのですが、愛媛は車がないと移動が不便なことが多いです。 帰省した際に旧友とお酒を飲むことが多いのですが、車は運転できないので、タクシーを簡単に呼べるアプリはやはり重要だなと再確認しました。 多くのタクシー会社さんに協力をいただいて、地方のタクシー乗車体験も良くしたいと考えていますので、「メニュー」＞「アプリについて」＞「お問い合わせ」よりご要望をいただけると幸いです。 今後とも応援をよろしくお願いします！ JapanTaxi開発チーム
細かな修正が記載してあるのに加え、開発後記があるのが目を引きます。開発者がどんなことを考えているのかはなかなか聞く機会がないですからね。
205.0 2019年1月25日 このアプリは、快適にご利用いただけるよう、定期的にアップデートされます。すべての機能をご利用いただくには、最新バージョンをダウンロードしてください 各種不具合の修正とパフォーマンスの向上。 Facebookをご利用いただきありがとうございます。
壊れたロボットのように基本これしかありません。
Amazon
13.1.0 2019年1月9日 今回のリリースではバグ修正及び動作パフォーマンスを改善しました。
お前もか… 基本これしか無いようです。
Pokémon GO
1.99.2 2018年12月15日 - 新しい対戦機能「トレーナーバトル」をお楽しみいただけるようになりました。 - 近くのトレーナーの「対戦コード」を読み取ることで「トレーナーバトル」ができます。 - 「親友」または「大親友」のフレンドなら、離れた場所からでも「トレーナーバトル」ができます。 - チームリーダー（スパーク、キャンデラ、ブランシェ）とも「トレーナーバトル」ができます。 - 「トレーナーバトル」は3つの「バトルリーグ」に分かれています。それぞれの「バトルリーグ」ごとに、参加できるポケモンの最大CP上限値が異なります。 - 「トレーナーバトル」をプレイすると、トレーナーはリワードを獲得できます。 - トレーナーのスタイルに新しい髪の色と肌の種類が追加されました。
ゲームをする人目線の書き方ですね。ゲームは書きやすいのかな?
終わりに
やはりSlackが群を抜いて面白いですね。面白いリリース文を出しているアプリがあればおしらせください。
*1:すみません、テーマ名うろ覚えです
NETFLIXの最強人事戦略 私的まとめ
- 作者: パティ・マッコード,櫻井祐子
- 出版社/メーカー: 光文社
- 発売日: 2018/08/17
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (2件) を見る
2018年に読んだ本でダントツ一番おもしろい本でした。
この本はどんな本か？
Netflixが自社の文化をまとめた「カルチャーデック」という資料をベースとし、Netflixの人事哲学が語られています。
Netflixの人事哲学
コミュニケーション
- 徹底的に正直であること。
- 徹底的に議論を戦わせること。
- コミュニケーションは双方向であること
いつでも間違いを認め、正しい選択ができなければならない。 そのために徹底的に議論を戦わせる必要がある。 Netflixでは「問題がおこったら当事者同士でオープンに話し合う」ことが重要な約束事となっている。 またコミュニケーションは双方向でなければならない。経営陣は会社の戦略や事業運営、業績に関する情報を正しく従業員に伝えなければならない。 また従業員は知りたいことを自ら問わなければ答えを得ることはできない。
誰かがバカなことをしているというのなら、それは情報を与えられていないか、誤った情報を与えられたせいである。 能力が不足しているためではない。 上層部から正しい情報を下ろさなければ、従業員は他の誰かから誤った情報を与えられる可能性が高い。
チーム・組織づくり
優れたチーム作りに本気で取り組むことが、経営陣にとって一番重要な仕事である。 「今のチームが理想でないことが、会社の成長の足かせになっていないか」を常に問い続けなければならない。
ただし、これは「これは従業員を育て、鍛える必要がある」という意味ではない。
- 従業員に能力を超えた仕事、才能と合わない仕事を与える義務はない。
- 長年の貢献に報いるためにポストを用意する義務もない。
- 誰かに遠慮して重要な人事変更を控える義務もない。
会社は家族ではなくスポーツチームである。 だから優れた成績を挙げていないプレイヤーは交代させなければ、チームやファンをがっかりさせてしまう。 会社の将来に必要な人材は社外からも広く探して最善の人材をポストに当てる。
解雇された従業員が会社を相手に訴訟を起こす可能性は、とくに業務上の課題について定期的に話し合いを持っていた場合はゼロに近い。 キャリアマネジメントはあくまで従業員自身の責任である。マネージャーの責務ではない。
従業員にとって最高の特典や催しは立派な福利厚生や働きやすい職場環境ではなく、事業や顧客について理解を深められる機会である。 最高の人材や優秀な専門家が、会社の最も差し迫った問題を議論する様子を間近で見させ、その議論に参加させる。 これ以上の学習機会・成長機会は無い。
採用
- 優れた人材の採用と従業員の解雇は主にマネージャーの責任である。
- すべての職務にまずまずの人材ではなく、最適な人材を採用するように務める。
- どんなに優れた人材でも会社が必要とする職務にスキルがあってないと判断すれば進んで解雇する。
いつでも最高の人材を補充できるとわかっていなければ、安心して解雇することができない。 だからヘッドハンティング会社から人材を引き抜いて、社内に採用機能を構築した。
本当に欲しい人材を獲得するためには、社内の給与水準やルールなどに縛られることなく、現実の市場の需要に対応するしかない。
人事評価
ほとんどの企業の人事施策や制度はどれもお金がムダにかかる上、「インセンティブをもらい、支持されなければ動けない」という人間に関する誤った考えを前提としている。 Netflixでは従業員にトップレベルの給与を支払い、高い業績をあげるようにハッパをかけている。
人事考課は評価を給与・報酬と連動させているから大変な手間をかけて行なっているだけで、なんの成果も生み出していない。 人事考課と給与・報酬を分離し、給与は会社業績だけに連動させれば人事考課を行わず、従業員成長のためのフィードバックのみに注力できる。。
まとめ
効率の良い働き方を目指し、従来の慣習を見つめ直し、不要なルール・取り組みを無くしていった結果の働き方だと感じました。 全てが「その通り」と同意できるものではありませんが、Netflixの事例をきっかけに自社・自分たちのやり方を見直すのは価値があることだと考えます。
上にあげた事項だけでも十分刺激的ですが、下記の内部暴露はさらに刺激的です。
ゆとりを計画しておく-物流業界の"Flying Spares"という考え方
はじめに
Blog: Allow for Uncertainty with Built-In Slack – The Flying Spare Example | Innolutionというブログ記事で、物流業界における「計画されたゆとりで不確実性に備える」例が紹介されていました。とても興味深い内容なので概要を紹介します。
Flying Sparesとは?
空っぽ、または積載量に空きがある飛行機を指した用語だそうです。 別の呼び方として"hot spares"とも呼びます。 ソフトウェア開発でいうと「ホットスタンバイ」のサーバが近い気がします。
他の飛行機の積み残しを搭載する、または故障時の代替として使用することを想定して「常に」用意するだそうです。 航空機を使った物流では下記の「不確実性」が日常的に発生しうるそうです。
- 顧客が持ち込んだ荷物が事前の連絡よりも大きかった
- 航空機機材の故障
- 天候不順
FedEx 1311便
FedEx 1311便は"Flying Spares"用の定期便らしくデンバーからFedExの拠点があるメンフィスまで定期運行しています。 空っぽの航空機を飛ばすにもパイロットや従業員が必要で、さらにこの便はデンバーからメンフィスまで直線距離(2時間15分)で向かうのではなく、ニューメキシコを経由して3時間30分のフライトをします。 1回の飛行にかかる費用は$30k(300万弱)とのことです。
それでもアメリカの南西部の空港で起きた不確実な事態に備えるため今日も飛んでいます。
おわりに
プロジェクト管理やリソース配分を考える際、つい不確実性を過小評価し、有事の際は頑張り・努力で対応して、結果スケジュールを遅らせてしまいがちです。 航空機を使った物流ビジネスほど大掛かりな準備が必要な分野でできている「計画されたゆとり」が、ソフトウェア開発で実現できないはずがないと考えました。
LOVOT体験会に行ってきました： 最高の特典や催しは事業や顧客について理解を深められる機会である。
はじめに
1/11(金)と1/14(月)の2回、GROOVE X社が開発したLOVOTの体験会に行ってきました。金曜日は同じ会社の友人と、月曜日は子供を連れ家族とです。
「体験会の様子をぜひSNSで拡散してください」とお願いがあったのですが、このブログのテーマは「アジャイル開発、組織変革、ファシリテーションについて学んだことの記録」としているので「ちょっと違うかな」と思っていたのですが、最近読んだネットフリックスの組織本にあった文章をふと思い出しました。
ネットフリックスが考える「従業員が仕事に満足感を得る時」はどんな時か
- 作者: パティ・マッコード,櫻井祐子
- 出版社/メーカー: 光文社
- 発売日: 2018/08/17
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (2件) を見る
この本はカルチャーデックと呼ばれるNETFLIXの企業文化や社員の行動規範を定めたガイドをより詳しく説明したものです。
その中で「従業員が仕事に満足感を得る時」について、こんな説明があります。
仕事に対する真のゆるぎない満足感は、優れた同僚たちと真剣に問題解決に取り組む時や、 懸命に生み出した製品・サービスを顧客が気に入ってくれた時にこそ得られる。
従業員が働きたくなるように、給与・福利厚生・ピカピカしたオフィス・ビールサーバーなどいろいろな用意をする企業が多いですが、ネットフリックスはこれを「従業員を子供扱いしている」と一刀両断しています。
最高の特典や催しは事業や顧客について理解を深められる機会である。
ネットフリックスの例では映画事業について学ぶ機会をたくさん設けたそうです。 従業員全員をサンダンス映画祭へ連れて行ったり、著名な映画監督・映写技師・映画編集者の話を聞きにロサンゼルスへしょっちゅういったと紹介されています。
LOVOT体験会の様子
体験会のアンケート項目から推測するに、LOVOTの購入を検討している近い将来のお客様から、LOVOTに興味を持っている少し将来のお客様、ロボットや技術に興味があるエンジニアなど様々な人が訪れているようです。
そういった人と社員が直接コミュニケーションが取れる機会を与えるのはまさに「事業や顧客について理解を深められる機会」だなと思いました。
またLOVOTを構成する技術を集めたコーナーからは「優れた同僚たちと真剣に問題解決に取り組む」ことに真摯に向き合っていることが伝わります。
技術展示会やオープンハウスを年一で開催し、社員が説明に立つことはよくあると思いますが、それとは違った印象を受けました。残念ながら理由は私もうまく言葉にできません。少人数制で説明員の方とたくさんお話しする機会があったからなのか。技術・アイデアの出し惜しみをしてないように感じたからか。これから育てていく、いわばβ版をぶつけてきているからなのか。そもそもGROOVE Xもどう広めていくか悩みを素直にぶつけているように感じたからか‥。
会場にいるLOVOT達にはみなかわいい名前がついています。社員からも愛されていることが自然と伝わります。
金曜日訪問した際、何気ない雑談で「LOVOTがいる家庭の子供達は「LOVOTネイティブ」として大きくなるんですね。どんな考えをロボットに対して持つんだろう。」といったやり取りがありました。それを聞いた社員の方は「そんな製品を自分たちは作っていたんですね！」と話していたことが印象的でした。「事業や顧客について理解が深まった時」に立ち会えた気がします。
「率直に買おうと思う？」
と聞かれると、NOです。
一般家庭で買うには価格が高いですし、LOVOTの振る舞いもまだまだ少なく、飽きてしまうかもと感じました。家の見守りもできるそうですが、人がLOVOTに求めるものとは少し違う気がします。
ただ、そんなことは会社もとっくにわかっていて、それでもいい製品に育てるべく、一歩歩みを進めるために今回の体験会を開いたのだと思います。よその会社の展示会と違うと感じたのはこれが理由かもしれません。
おわりに
残念ながら今回の体験会は1/18(金)までとのことです。 反響を見て秋に開催するかもしれないそうですが、行く機会があればぜひ行ってみてください。
