自転車に乗る主夫エンジニアの日記

ソフトウェアエンジニア(Web)の日記です。

読書録: NETFLIXの最強人事戦略

近頃、ソフトウェア開発ではない文脈でアジャイルという言葉をよく目にする。

Harvard Business Reviewが組んだ「アジャイル人事」という特集のなかで、本書の一部が抜粋されたのを読んだのが手に取ったキッカケだった。

どうやらNETFLIXはとても筋肉質な組織のようだ。

評価

時間が許す方は是非とも読んでいただきたい。

語り口が痛快で読みやすい。目次を読んで、自分の心の中にある理想の組織像と照らし合わせるだけで1,600円の価値がある。

具体的な方法論までは明示されていないものの、実際にNETFLIX社内で起こった出来事をもとに、彼らの行動指針が紹介されている。

概要

この組織が筋肉質であるのは、次のようなポリシーで運営されているからだ。

優秀な同僚と、明確な目的意識、達成すべき成果の周知徹底 - この組み合わせがパワフルな組織の秘訣である

まさに筋肉質な組織に憧れを抱く人の理想と一致するのではないか?

要約すると、この一文で済んでしまって味気ない。 以下、面白いと思った記述をかいつまんで引用する。

  • 問題が起こったら当事者同士でオープンに話し合うこと
  • 率直な意見を促すには、率直に話す人が無事生き延びることを示すのが一番だ
  • 事業や顧客のためになる議論をする(そ
  • キャパシティビルダー、すなわちチームの能力を高めるスキルをもつ人材が足りているか
  • 会社は家族ではなく、スポーツチームだ
  • この仕事をするためには、社内の誰ももっていない専門知識が必要か、それともこれはうちがイノベーションを牽引している分野の仕事なのか
  • この従業員が情熱と才能を持っている仕事は、うちの会社が優れた人材を必要とする仕事なのか

報酬についても独特(似たようなNETFLIX特有ではないと思うが)で、ボーナス等で従業員をモチベートするつもりがない。
「優秀な同僚と、明確な目的意識、達成すべき成果の周知徹底」から生まれる充実した時間さえあれば、人事評価連動型の報酬でモチベートしなくても大人なら走れる。 人事評価連動型の報酬がなければ、煩雑な評価管理の仕組みが必要ない。

感想

コストセンターと認識されがちな人事部が、まるでプロフィットセンターのように考えて行動していて、ただ関心するばかりだ。
(※零細ベンチャーに所属していた経験からすると、そんなことでは困るのだが。)

人事評価の仕組みも収益に貢献しないのであれば廃止する姿勢からは、できる限りのリソースを収益を上げることに集中させるという意志を感じた。

一般的な企業がコストセンターに割り当てているリソースを、このようにプロフィットセンターに向けられているのは明確な強みだ。

NETFLIXくらい組織のミッション、事業ドメインがクリアだと、筋肉質な組織を実現できるのだろう。つまり、事業計画を要員計画にまで落としやすいのではないか。次の事業目標を達成するために必要な人材、そして必要でなくなる人材が具体的にイメージし、実行する。 NETFLIXも2,000人を超える組織であるから、本書からイメージされるような完全に筋肉質な組織ではないのだろう。 - 事実、人材のミスマッチがあることを文中で認めている。 しかし、そういった規模の会社がこのような方法論で組織を運営しているという事実はある種の夢を与えてくれる。

最後に、本論からは脱線するが、本書から想像されるA級プレイヤーは私の想像を遥かに超えているようだった。 文字通り、 その人にしかできない仕事 をやってのける その人しか知らないノウハウ を持っているプレイヤーが海の向こうにはいるのだろうか。

読書録: マッキンゼーが予測する未来

年末年始に読んだ。

マッキンゼーが予測する未来―――近未来のビジネスは、4つの力に支配されている

マッキンゼーが予測する未来―――近未来のビジネスは、4つの力に支配されている

目次

  • 評価
  • 読み方
  • 概要

評価

未来を予測しているわけでない。邦題が良くない。

原題)No ordinary disruption - the four global forces breaking all the trends
邦題)マッキンゼーが予測する未来 - 近未来のビジネスは、4つの力に支配されている

経済情勢を掴むうえでのきっかけは得られる

都市化、技術進歩、高齢化、グローバル化と、本書が焦点を当てているトレンド自体は決して新しいものではない。ただ、これらのトレンドがこれまで以上の規模で起こり、事業機会、供給力、資本コスト、労働市場へとそれぞれ大きな影響を与えているとわかるのは面白い。

本文がダラダラ長い

本文をメインに読んでいると結局何が言いたいのかわからなくなるので、見出しを読んで意図を理解するのが良い。

読み方

まずは目次と小見出し(目次には載っていない)を読んで、意図を理解するのが良い。その後で、気になるファクトをじっくり読むと効率的である。
大事なのは5、(6)、7、8章なので、そこだけ読めば良い気もする。

概要

第1部

都市化、技術進化、高齢化、グローバル化はこれまで通り、経済情勢を形作る原動力である。
こうした変化が世界の各地(これまで新興国後進国と呼ばれていた国々)で発生するので、急速かつ大規模な変化が起こることになる。

個人的には「高齢化すると年金として貯まるお金より、出て行くお金が増える」という視点がなかったので、それを得られたのが良かった。
これまで大きな資本の供給源のひとつであったと思うので、これまでとは大きく違う力が働くポイントになるのではないかと思う。

第2部

第5章

これから生まれる大都市における需要を取り込もうという話題
「自国での事業をそのまま横展して参入」ではうまくいかないことが多い。商品、サービス、それを提供する組織をその土地に合わせる必要がある。 それを実現するためには、HQは各都市圏をフラットに評価し、権限を移譲するのが良いのではないか。

とあるCEOのインタビューにある「再配分するのは資本のほうが、人材を動かすのよりも簡単です」というのが至言だった。

第6章

新たに生まれる需要を支えるだけの自然資源が足りないという話題 「供給側、需要側の努力によって単位資源あたりの生産性が改善することに期待する」という夢のない話。
各人が単位資源あたりの無駄をなくす施策を実施すること、供給側はコスト増、および原料の供給停止に備えること。

第7章

資本コストは概ね上昇しそうだという話題
これまでは経済の重心が先進諸国にあり、そのなかで豊かな資本供給(長く続いた低金利政策による)と、低い資本需要(交通網、上下水道といったインフラや生産設備への初期投資が必要ないといった事情による)によって、低い資本コストが実現されてきた。
しかし、今は新興国がいたるところで都市化を進め、先進国は古くなったインフラを置き換えようという状況で、資金需要が急速に増えている。
さらに、高齢化が年金プールや貯蓄を削る方向へ作用し、資本供給は減ることになる。
※本書では政府の赤字、積み上がる負債も貯蓄を減らす要因として挙げられている。
こうした事情によって、資本コストが上昇する蓋然性が高まっている。

一方で、各国政府は長く続いた低金利の時代に国債を発行し、負債を積み上げてきている。
こうした多くの政府は停滞する経済成長に悩んでいて、従来のやり方では債務を解消できない。
そこで、中央銀行に恒久的に国債を買い取らせることで、今の状況が維持されるかもしれない。

という現状において、資本の生産性を上げること、新しい資本供給源を探すことが推奨されている。
また、その事例が紹介されていて面白い。

第8章

労働市場で需給ミスマッチが発生しやすくなっているという話題
技術進歩のスピードが早く、人材に求められるスキルの変化も早い。
また、高度なスキルを持った人材に対する需要が増え、そういったスキルを必要としない人材に対する需要が減るなか、供給される人材の割合はこれまでと変わらないという状況にある。

こうした状況において、これまで目を向けなかった属性の人たちを人材源と捉えること、技術を人の代わりではなく人を力づけるものと捉えること、職務を分解して高スキル人材から一部の職務を低スキル人材へ移譲させること、自ら人材を育てることが推奨されている。

第9章

新しく強力な競合がいつ生まれてもおかしくないという話題
新興国で進む都市化は、その国の企業を既存のグローバル企業と肩を並べるまで成長させるポテンシャルがある。 IT技術を活用することで、ベンチャー企業や新規参入企業が既存企業より優位な事業を立ち上げられる可能性がある。

第10章

政治、政策の話題
目前の政策課題として下記箇条書き部のようなことが述べられた後に、 政策予算の規模、政策権限の割振り(中央集権/地方分権)、そもそも政府の役割を見直すことがサラっと提起されている。
予算規模、中央・地方政府の権限、政策スコープを議題にすること自体は良いことだと思うので、もう少し丁寧に扱ってほしい。さすがに前後の脈略がよく分からない。

  • グローバル化と技術進歩によって、非熟練労働者が失業しやすい状況にある一方、理工系分野での人材不足に悩まされている。
  • 積み上がる財政債務、低成長にとどまる経済、上昇するであろう資本コストによって、財政の健全化が迫られている。
  • 失業者が生まれやすく、国内所得格差が広がりやすい状況で、貿易や移民に関わる政策が保護主義に傾きがちである。
  • 大きな破壊的変化が度々起こるので、中長期的にどういった人材を育成し、どういったインフラを整えるべきかを策定するのが困難である。(本当かよ)

WEBアプリケーションの言語・フレームワーク選択について

今新たにWEBアプリケーションを作るとしたら、どのようにサーバーサイドの言語・フレームワーク選ぶか。今の自分の立場を書き残しておきたい。

結論(追記

フレームワーク選定ももちろん大事だが、チームで設計の合意を形成することの方がもっと大事なのではないか。

選択肢

※私が触ったことがあるものの中でという意味で。
※言語を統一できていない時点で、フレームワーク自体の比較には失敗している。

選定軸

1. 厳密性: そのアプリケーションでバグが出ることで、ユーザーやオーナーにどれだけ重大な影響が発生しうるか

これを意識するほど重要なアプリケーションを作った経験がないのだが、おそらくこれが一番重要なのかもしれない。
バグが人の生き死に、大きな金の流れに影響を及ぼすアプリケーションであれば、RubyPHPなどコンパイルを必要としない言語を積極的に採用する理由はない。ランタイムエラーくらい普通に開発していればまず発生し得ない、CIを回せばいい、と言いたい気持ちもあるが、わずかに残る可能性すら許されないか否かが基準になる。

2. 開発規模: 将来、そのアプリケーションの保守・開発にどれだけの人数が必要となるか

大規模になるのであればコンパイルを必要とするJava(あるいはScala)を選ぶし、そうでなければPHPを選ぶ。どんなアプリケーションであれ、インターフェースを定義できるIDEレベルで型チェックができる十分に使えるレベルのエンジニアを揃えられる言語を選ぶ。

自分が信頼できるエンジニア越しに束ねられる人数を超えたら、それは大規模に入るのだと思う。コンパイルすら通らないものを成果物として提出されても困る。それを人為的にチェックする体制を築くのに大きな労力を割くのはできるだけ避けたい。これもある程度CIで代替可能ではあるが、そもそもテストコードを書いてもらうか、自分で書くかしなければCIではチェックできない。

インターフェースが定義できると、知らない人に開発を依頼しやすいように思う。極論、インターフェースを定義し、具象クラスの用途さえ伝えれば実装してもらえる。そういう意味でインターフェースを定義できる言語であれば、開発規模の拡大に対してある程度のスケーラビリティを備えることができるのではないか。また、インターフェースを定義せず、関数の引数に型を指定するだけでも、安全かつ意図を明確にできる。引数の取り得る値がどのようなものか想像しづらいのは開発効率がよくない。

人手を揃えやすい、十分に熟達していなくてもアサインしやすいという意味において、JavaPHPはやはり秀でていると思う。古く、異臭を放つPHPに悩まされてきた人たちには信じられないかもしれないが、PHPも一応型で縛れる安心感がある。

3. 開発速度

正直なんでもいいよという気分である。 2〜3名規模のチームを保てるのであればRuby on Rails、それを超える規模になるのであればLaravelを選ぶだろうか。

フレームワークが想定しているアプリケーションの規模があると思っていて、そこから外れるとそのフレームワークの開発効率が落ちるのではないだろうか。小規模開発では手数を減らしてくれるようなツール、クラスも大規模開発では使えなかったり、大規模開発では使える枠組みも小規模開発では手数ばかり増えると言った具合である。
Ruby on Railsは純粋なMVCフレームワークであり、それ以外の構造化について開発者を縛る枠組みがない。MVCの構造に従って密結合に作っていられるうちは確かに速い。ただし多くの人が経験したように、規模が大きくなるとModelやControllerがファットになって見通しが悪くなる。
Laravelは同様のMVCフレームワークであるが、IoCコンテナが用意されている。その分、疎結合に作りやすく規模の拡大に耐えやすいだろう。
SymfonyはBundle, Entityの2軸でテーブル、カラムのアクセス権を実装できるので、DB操作がセキュアに設計できそう。しかし実際のところ手数がかかるだけで、全カラムが結局publicになってなんの意味があったんだ状態に陥る気がする。何がしたかったんだお前は。

5人以上の開発規模になるチームの人数が3人を超える(*1)のであれば、インターフェースを定義できる言語を選ぶ。規模が大きくなるにつれ、他人の書いたコードに触れる頻度が多くなったり、自分の書いたコードを覚えていられなくなる。その際にインターフェースをIDEが認識できる言語はキャッチアップを助けてくれる。おそらく、それくらいの規模になるとコーディングにかかる時間よりも、コードを読む時間や設計を考える時間のほうが増えやすくなっているだろう。

後書き

正直、Ruby on Railsをdisりたくてこの記事を書きはじめた。 しかし、自分がRubyおよびRuby on Railsに対する理解が浅いだけだと、冷静に思い直している最中である。

以下、Ruby on Railsに対するdisりを書き残しておく。

Ruby on Railsはチームがごく少人数にとどまらない限り採用しない。素早くアプリを開発できるというのは確かにそうだが、それは 小規模な0=>1MVCの枠組みに収まり切る対面で意思疎通を取り切れる規模 の話に限られた話だと思っている。そのアプリ、新しい機能のリリースが1分1秒を争うというのなら話は別だが、そうでない限りは採用しようと思わない。(そもそも、そういったシチュエーション自体が想像できない。) Ruby on RailsMVCの枠組みを外れると、設計者の意図を知らずにコードを読み解くことは非常に困難になる。(それはどのフレームワークでも、枠組から外れたらそうなのかもしれない。) Ruby Gemsは非常に強力だが、後から参画したメンバーがそのgem特有の機能を使ったコードを見せられて理解できるかといえば、そうではない。そもそもRuby自体が強い動的型付け言語であることが、コードリーディングの妨げになっているのではないか。 総じて、ドキュメントを十分に用意するなどスキトラを十分にこなせるのであれば良いが、そんな現場を見たことがない。

*1: 2018-09-04 updated

鰤の照り焼き

理想

中まで十分に火が通りつつ、鰤自身の脂が十分に残ってていて、柔らかくジューシーな食感を楽しめる。

ポイント

  • 表面に小麦粉をまぶす
  • 短時間、強火で加熱する

ピーマンの肉詰めでも登場したが、やはり肉汁を閉じ込めるには小麦粉が欠かせないようだ。浸したタレをふるい落としたら、小麦粉を満遍なくふりかける。 サラダ油を敷き、強火で熱したフライパンで強火で加熱する。一気に加熱することで切り身の外側に「膜」ができ、脂を閉じ込めてくれるようだ。両面それぞれ30〜40秒ほどで焼き色をつけたら弱火に切り替え、タレを投入する。この間、フライパンを揺すって切り身が焦げ付かないようにする。タレの水分が飛んだら完成だ。

その他

レシピによっては「キッチンペーペーなどでサバの水気を拭き取る」と記載されていることがある。タレに浸し、小麦粉をまぶす工程の直前のことを指すものと思われる。タレに浸す前にするものと誤解を招きかねないので注意したい。タレに浸す前の切り身に対してキッチンペーペーで水気を拭き取るということは、脂を拭き取る作業に等しい。せっかく脂の乗った旬の食材も台無しである。ただし、血が付いている場合は拭き取ること。

味付けについては好みの問題であるため、タレについては強く主張するつもりはない。私個人としては、醤油、みりん、酒、砂糖を2:2:2:1の割合で混ぜるのが好みだ。

ピーマンの肉詰め

理想

肉は中まで十分に火を通しつつも、肉汁が滴りジューシーに。 ピーマンは臭みや水気を飛ばしつつ、パリッとした食感が残っている。

調理のポイント

  • 肉をピーマンいっぱいに詰めない
  • 肉の面に小麦粉をまぶす
  • 加熱は肉、ピーマンの面を順に1回ずつ
  • 肉の面は強火で短時間、ピーマンの面は弱〜中火で適当に焼く

肉汁とピーマンの食感を楽しみたい都合上、火にかける時間はなるべく短く済ませたい。 一方で、豚のひき肉は中まで十分に火を通したい。

まずタネを小さめにするのが重要である。タネが大きいとどうしても内側まで火が通りづらい。短時間で中まで加熱するにはタネが十分に小さいことが重要である。

次に肉の面に小麦粉をまぶすことが重要である。私自身、原理がよくわかっていないが、一般論として肉汁が流れ出るのを防ぐ効果があるようだ。実際にそんな効果がある気がする。

最後に肉の面は強火で短時間、ピーマンの面は弱〜中火で焼くことが重要である。ピーマンの肉詰めは1度しかひっくり返すことができない。ピーマン側を加熱したのちに肉側を加熱してしまうと、肉汁が溢れてしまうからだ。また、肉側は加熱した時間に応じて肉汁が溢れていってしまう。したがって、短時間で焼き色をつけることが重要である。あとはひっくり返してピーマンが焦げつかないよう、弱〜中火で加熱すればよい。

読書録: デザインパターン(GoF)

GoFデザインパターンを読んだので、振り返りがてら紹介する。

オブジェクト指向における再利用のためのデザインパターン

オブジェクト指向における再利用のためのデザインパターン

目次

総評

本書は設計力を身につけるために必要な知識を身につけるためのものである。手っ取り早く手元のコードを綺麗にするために何某かのデザインパターンを採用したいというのであれば、身近にいる熟練したエンジニアにレビューをもらうのが格段に早い。もちろん、すぐに実践で活かせるパターンも紹介されているが、ある程度知識が備わっていなければそれを選び出すことはできない。本書ではデザインパターン生成構造振る舞い、大きく3つに分類して紹介している。この枠組は、自身が問題に直面したとき、それを分析する手掛かりとなる。翻って、オブジェクト指向パラダイムに沿ってアプリケーションを構築するための足がかりとなるだろう。

評価

読みやすさ

  • 私は読み進めるのに苦労した。読み始めるにあたって私は手元にあるサーバーサイドプログラムでどのようにデザインパターンを活かそうかという視点が強く、著者の例示をうまく飲み込めなかったためだ。GUIアプリケーション(テキストエディタなど)を例にデザインパターンを説明することが多いとわかっていればもう少し読みやすかったのではないか。
  • また、例示されるアプリケーションが古くてイメージが湧きづらいので、例を読めば理解できると高をくくって読み進めると苦労するだろう。本書の大まかな構成は良いが、文章構成(文章の論理構造)が簡潔でなく、サラッと読み進めると理解できていなかったりする。

効能

  • オブジェクト指向言語に対する理解を深める助けになる。(この本が相応しいかはともかく)
  • 型に従ったプログラミングを意識するようになる。
  • 設計力の基礎を身につけることができる。

紹介されているデザインパターン

振る舞いに関するパターンのInterpreterパターンやIteratorパターンは読み飛ばして良いだろう。Interpreterパターンは用途が非常に限定的であるし、Iteratorパターンは今日のプログラミング言語が標準的に備えている機能で賄えるためである。それ以外はどれも一読の価値があるだろう。(日常的に使わないパターンもあるかもしれないが)

【生成】

  • Abstract Factory
  • Builder
  • Factory Method
  • Prototype
  • Singleton

【構造】

  • Adapter
  • Bridge
  • Composite
  • Decorator
  • Facade
  • Flyweight
  • Proxy

【振る舞い】

  • Chain of Responsibility
  • Command
  • Interpreter
  • Iterator
  • Mediator
  • Memento
  • Observer
  • State
  • Strategy
  • Template Method
  • Visitor

読み方

まずはパターンをすべて覚えることよりも、大きく3つの観点でパターンが別れていることにどのような意味があるのかを理解することが重要だろう。ただし、それを理解するには各パターンの概要をある程度押さえておく必要はあるだろう。

  • プログラミング初学者にはパターンを学ぶことを後回しにして、1章をじっくり読むか、他の本を読んでオブジェクト指向について理解を深めることをオススメする。
  • 駆け出しのエンジニア(Railsなどのフレームワークを使って開発ができるようになったレベル)には1、3〜6章を順に読むことをオススメする。

3〜5章では、それぞれ生成、構造、振る舞いに関する種々のパターンを以下の構成で紹介している。私は「実装」と「サンプルコード」の節は読み飛ばした。パターンの特徴(目的と長所、短所)を捉えることを目的としていたためである。1パターンあたり30分程度かかった。1ヶ月程度で一通り読み終わるはずだ。

  • 目的
  • 別名
  • 動機
  • 適用可能性
  • 構造
  • 構成要素
  • 協調関係
  • 結果
  • 実装
  • サンプルコード
  • 使用例
  • 関連するパターン

所感

  • 生成に関するパターンは、オブジェクトの生成をカプセル化することがテーマである。ゆえに、プロジェクトが型に従って開発が進むことを助ける働きがあるように思う。( new Hoge() のように特定のクラスをインスタンス化することを避ける)
  • 構造に関するパターンは、クラスをどのように協調させるかがテーマである。ゆえに、クラスの巨大化を防いだり、クラスの無駄な増殖を防いだり、クラスが歪な形に成長するのを防ぐのに使えるパターンが多かったように思う。
  • 振る舞いに関するパターンは、ロジックをカプセル化することがテーマである。ゆえに、実践ですぐに活かせそうなパターンが多かったように思う。