NETFLIXの最強人事戦略 読書メモ

 読みました。

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

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

 

読んで、思ったことをまとめます。以下の内容は、かならずしも本書の内容に一致するものではありません。

情報はオープンにしよう

経営陣の判断や議論の経緯、社員の不満、双方向に情報が言い合えるようにする。「このプロジェクトうまくいかないんじゃないかな...」なんて情報も大事だ。とはいえそれをうまくやるには運用を丁寧に考える必要がある。しかし経営陣が気づけなかったことを現場社員が指摘し、結果成功した、ということが NETFLIX でもよくあったらしい。

オープンな議論のためには技術が必要だ。ファシリテーションがなければ議論は容易に破綻する。社員に適切な教育をしたり、ファシリテーションに長けた社員を配置することが大事だろう。またその結果をいかに共有するかも難しい問題だ。

リクルーターはビジネスを知ろう

必要な人材はどんなスキルを求められているのかを知るべき、ということ。それができたらヘッドハントにしろスカウトにしろ、スピーディに的確に実現できる。

そのために、そもそも組織がどんな人材を必要としているのか、現場が明らかにする必要がある。いま必要な人材もそうだし、6ヶ月後にビジネスがどうなっていて、そのときに必要となるだろう人材もそうだ。成長企業は特に、それまで組織に存在しなかったポジションが求められるようになることもあるため、想像力と他社の知見が大事だろう。

人事考課を廃止できないか検討しよう

NETFLIX は人事考課制度を廃止したらしい。人事考課は、とにかく時間がかかる。とくにマネジャー層は、その時期になると相当の時間が奪われる。人事考課の目的は通常、給与計算だろう。廃止するためには給与計算の仕組みを変える必要がある。本書では「給与を業績だけに連動させる」とある。「情報はオープンに」とも関連するが、業績をいかに給与に反映させるか、の情報も明確に打ち出すことになる。このあたりは詳細に書かれていないが、慎重になる必要があるだろう。

2018年に知って惚れたアーティスト

以前から活動していた方々もあり。去年はこちら

関取花

youtu.be

広島にいったとき、たまたまラジオの公録をやっていた。いい声〜と思って CD 買った。歌詞も良い。めっちゃ良い。魂。

ルックスで売ってないのも好き。

John OFA Rhee

youtu.be

Spotify で流れてきた。ふだん韓国の曲は全く聞かないけど、ドラムにしろギターにしろ音が良くて気に入った。韓国も良いじゃない。となった。

スペクトラム

youtu.be

スタン・ハンセンの入場テーマのアーティスト、というのは知ってたけど、ある曲をアレンジして演奏することになって他の曲を知った。クソかっこいい。ラッパやべぇしベースも鬼

Kutiman

youtu.be

ファンクやらアンビエントやらダブやら、ひたすらに音とグルーブが気持ちいい。

学びたい技術と今の理解

2019年に学びたい技術がいろいろある。現時点でのふんわりした理解をまとめておく。

GraphQL

GitHub 製。REST のツラミを解消するクエリ言語。 REST だとエンティティごとにエンドポイント用意して、それぞれクエリを受けて、という実装をする必要があるが GraphQL ならエンドポイントはひとつでよく、 json でクエリ条件を記述する。

わからないこと

  • サーバー側どんな実装になるのか
  • レスポンスコードどうなるのか
  • ページネーションどうするのか
  • 複数エンティティとれる??みたいな噂があるけど、実装どうするのか

Flux

フロントエンドのアーキテクチャ設計思想。 React と相性がいい。

わからないこと

  • フレームワークがあるのか
  • vuex は Flux なのかか
  • 実際どうなのか
  • MVC / MVVM と書き味どう違うのか

gRPC

Google 製の RPC 用プロトコル。 Protocol Buffers でシリアライズする。 Go と相性がいい。

わからないこと

  • Go 以外はどうなのか
  • どんな実装になるのか
  • そもそもなんで RPC したいんだっけ

Firebase

GCP の 1 サービス。CRUD 程度の簡単な API 実装が吸収できるらしい。

わからないこと

  • コスパどうなのか
  • エラー処理どうするのか
  • バージョン管理どうするのか
  • デプロイどうするのか

Service Worker

Web ブラウザのバックグラウンド JavaScript 実行環境。たぶん並列処理っぽいことができる。たぶんキャッシュもうまいこと扱える。

わからないこと

  • 実際なにができるのか
  • PWA との関係
  • 仕様としてどこまで確立しているのか

2018年

1年を振り返ります。いろいろやってた気がしてけどそうでもなかった。あと月で偏りがある。


1月 たぶん仕事してた

2月 サービスローンチ

3月 面接に加わる

4月 勉強会登壇、ダテカン13回定期、柏交響楽団エキストラ

5月 広島ひとり旅

6月 バンドアレンジ、植樹

7月 オペラ祭り、部長陣議論ファシリ

8月 マインドフルネスの会、イタリア演奏旅行

9月 北海道、秘密のプロジェクト

10月 技術書典

11月 朝日新聞デビュー、初プロレス観戦、phantom参加

12月 人事部へ異動、ダテカン14回定期、大喜利

 

ま、でもいろいろチャレンジできた1年でした。これからはチャレンジだけじゃなくて成果に繋げていきたい所存。

Clean Architecture より、3つのプログラミングパラダイムの本質

読んでいます。

Clean Architecture 達人に学ぶソフトウェアの構造と設計

Clean Architecture 達人に学ぶソフトウェアの構造と設計

第3章~第6章で、3つのプログラミングパラダイムについて語られています。

Uncle Bob (著者の愛称) いわく、これらそれぞれはプログラマーに何か能力を与えるのではなく、プログラマーの能力を制限している。すなわち「何をすべきではないか」を規定しているのだ。構造化プログラミングは直接的な制御の移行 (goto) を封じ、それてによってプログラムの反証可能性を確実なものにする。オブジェクト指向プログラミングはポリモーフィズムによる依存関係逆転によって、制御の移行の方向を制限する。関数型プログラミングは、変数を固定にし、代入を制限する。これらによって、コードベースに秩序がもたらされる。

これは味わい深い話だ。コードベースでは数十年にわたってこうした「何をすべきではないか」を学んできた。アーキテクチャレベルではどうだろうか?恐らく「どんな実装をすべきでないか」を完全に制御できるようなアーキテクチャは現実的ではない(実装者に依存する)だろう。これをどうやって規定し担保していくか、がソフトウェアアーキテクチャの難しさだろう。たとえば Microservices Architecture は最近、山のように「すべきではない実装」が書籍だったりブログだったりで報告されているが、それらを厳密に体系立てられたパターンとして制限できるような仕組みが生み出されるには至っていない。ソフトウェアアーキテクチャはまだまだ進化の途中だ。

IT 関連のややこしい用語

IT 関連の用語は使い所によっていろんな意味をもってややこしい。ざっと思いついたものを挙げる。

フロントエンド

  1. Web アプリケーションにおける、ブラウザに動作させる実装。 HTML/CSS/JavaScript など。 クライアントサイド。「フロントエンドエンジニア」と言った場合はこれを指す。
  2. 機能をユーザーが触れるようにするもの。これ自体が Web アプリケーションを指す場合もある。アプリケーションA (バッチ) が処理結果をDBに保存し、アプリケーションB (Web) がその情報を画面に出力する、といった場合は「アプリケーションBはアプリケーションAのフロントエンド」と呼んだりする。

アプリ

  1. スマホアプリ。スマートフォンで動作するアプリケーション。
  2. PC アプリ。 Windows なら .exe、 Mac なら .app など。
  3. アプリケーション。 Web アプリケーションなど。 1. および 2. を含む。

特に口頭で「アプリ」と言った場合はなぜか 1. を指すことが多い。携帯電話→ケータイ、みたいな。

リポジトリ

  1. Git などバージョン管理システムのホスト先。Git であれば GitHub など。
  2. npm などパッケージマネージャのホスト先。
  3. Repository Pattern の実装。

サービス

  1. ユーザーが認識する単位の Web サービス。
  2. 機能単位のサービス。マイクロサービス、SAOなど。
  3. Windows サービス。

Atom

  1. GitHub が開発するテキストエディタ
  2. コンテンツ配信用のプロトコルRSS 的なやつ。
  3. Intel の CPU ブランドの名称。

Unity

  1. 3D に強いゲーム開発エンジン。 https://unity3d.com/
  2. DI コンテナ。 https://github.com/unitycontainer/unity

いずれも C# 関係なのが余計にややこしい。

エンジニア

GAS で Google カレンダーの1日の空き時間を取得する

最近予定が詰まっているのでスキマ時間がどれくらいあるのか取得したくなった。ので GAS で書いた。

function myFunction() {
  const calendar = CalendarApp.getCalendarById('hogehogei@example.com');

  const date = new Date();
  
  const freeTime = getFreeTimeMinutes(calendar, new Date());

  // あとは気分に応じて Slack に投げたりする
}

function getFreeTimeMinutes(calendar, date){
  const events = calendar.getEventsForDay(date);
  
  // 終了時間の昇順にした後に開始時間の昇順にする
  const sortedEvents = events.sort(function(a, b) {
    return a.getEndTime() - b.getEndTime();
  }).sort(function(a, b) {
    return a.getStartTime() - b.getStartTime();
  });
 
 // 時間がかぶっている予定をひとまとめに `block` とする
  const blocks = [];
  var block = {
    start: sortedEvents[0].getStartTime(),
    end: sortedEvents[0].getEndTime()
  };
  
  sortedEvents.forEach(function(event) {
    const start = event.getStartTime();
    const end = event.getEndTime();
    
    if(block.end < start){
      blocks.push({
        start: block.start,
        end: block.end
      });
      block.start = start;
      block.end = end;
    }
        
    if(block.end < end){
      block.end = end;
    }
  });
  
  blocks.push({
    start: block.start,
    end: block.end
  });
  
  // 9:30 - 18:00 を定時とする
  const bizStart = new Date(date.getYear(), date.getMonth(), date.getDate(), 9, 30, 0);
  const bizEnd = new Date(date.getYear(), date.getMonth(), date.getDate(), 18, 00, 0);
  
  // 完全に業務時間外の予定を省く
  const filteredBlocks = blocks.filter(function(block) {
     return bizStart < block.end && block.start < bizEnd
  });
  
  // 業務時間から溢れた分をカットする
  const cutOffBlocks = filteredBlocks.map(function(block){
    if(block.start < bizStart) block.start = bizStart;
    if(bizEnd < block.end) block.end = bizEnd;
    
    return block;
  });
 
 // 業務時間内で重複を取り除いた予定の合計時間
  var sumMinutes = 0;
  cutOffBlocks.forEach(function(block) {
    sumMinutes += (block.end.getTime() - block.start.getTime()) / (1000 * 60);
  });
  
  const bizMinutes = (bizEnd.getTime() - bizStart.getTime()) / (1000 * 60);
  
  return bizMinutes - sumMinutes;
}

業務時間外を省いているのは、飲み会とかの予定も入ってるから。 休憩時間とかフレックスは未対応です。

もっと効率よく書ける気はしている。