hikoharu's blog

エンジニアリング、プロダクトについて考えていること。twitter: @hikoharu06

プロダクトマネジメントにおける事業理解について、NETFLIXの事例を考えてみた

最近0→1以降のフェーズでプロダクトマネジメントする上で最も重要なのは事業、ドメイン理解だと思っています。

PMというただでさえよくわからない業務の本質は、

事業の価値や戦略を理解した上で、全体最適を維持する。 その上で、何かしらの専門性(エンジニアリング、グロースハックなど)を発揮して事業のHOWであるプロダクトを作って事業を加速させること

だと思っています。 それをするには、結局「この事業の価値は何だっけ?」、「今ビジネス的に何が最重要なんだっけ?」という問いに常に答えれないといけない訳です。

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

を読んで、そこら辺が書かれていて面白かったのでまとめます。

Googleとの企業文化の違い

イメージ的にNETFLIXと近い企業としてGoogleがあるなと思っていたのですが 読んでみると両者は根底の部分が違っていて

  • Googleの事業はとても多様。そして採用ではメンバーの創造性を何より重視する。アイデアを出してもらい、それを事業にできるから
  • NETFLIXは基本プロダクトが1つ。事業上必要なことが厳格に決まっていて、メンバーに高度な事業の理解と貢献を求める

どちらが優れているという話ではないのですが、NETFLIXは事業に対して必要な業務、人材の定義が徹底していると感じました

実際のエピソードとして、事業として検索に力を入れたいが、Facebook広告に固執する超優秀なエンジニアに対して、退職を推奨するという、、、 Googleとかであれば、配置転換などでやらせてもらえそうだなと

他にも象徴的なエピソードが

  • 人事考課は時間のムダ。なぜなら事業KPIのどれにも紐付かないから
  • 人事にも事業理解を求める。人事が事業理解をし、チームに必要な人材を採用する。事業が成功した時は「私があのチームを作った」と感動して号泣する

などが興味深かったです。

自由と責任と事業理解

本のタイトルにもなっている「自由と責任の文化」というのは、

  • 組織として透明性が担保された状況(全従業員が事業の現状と今後の戦略について理解している)
  • 事業理解をもとに自分のミッションの明確化(=責任)
  • ミッションを果たすために邪魔な制約は会社として全て取り払う(=自由)

ということなのかなと解釈しました。

自分の好きな技術を何でもやっていいということでは決してなく、やるべきことは事業戦略として厳格に決まっている。 そこがスタートラインにあった上で、徹底的に情報アクセスのハードルを下げて、自由と責任を持って事業戦略に基づいたミッションにコミットできるということなのかなと

ここらへんは自分のPMとしてのバックグラウンドのバイアスが思いっきりかかっているので、あくまで1つの解釈として読んでもらえれば

従業員のモチベーションは不要なのか

後半で従業員エンゲージメントに対しても真っ向否定していて、「まるで従業員のやる気不足が原因のような言い方だ。やる気のない従業員を解雇して好業績になるなら、とっくに他のところも成功している」これは「なるほど」と思うところがある一方、かなりのパワーワードだなと 笑

この背景としては、すでに上述していますがNETFLIXはプロダクトは1つ、さらに事業としてのビジョン、やることを明確にしている さらにアメリカのジョブディスクリプション文化(総合職とかではなく、明確に職務が規定されている)とも重なって、 完璧に事業戦略〜1人1人のミッションがつながっているからで、組織マネジメントの1つの完成形だと思いました。

つまりは採用のタイミングで完全にミッションが事業戦略からの逆算で決まる&人事、現場がそれを理解しているので求職者にブレなく伝えられている。 という前提になるので、モチベーションは関係ないと

日本だとそもそもジョブディスクリプションを厳格にできない、風土の問題も大きいし、そもそも厳格にしてしまうとポジションがクローズした時に解雇が発生するが それができないという事情があります。 事業理解など参考になる部分は多かった一方で、前提が違うので日本でそのままやるのは難しいなと感じました。

https://www.amazon.co.jp/dp/B07GWJCBVP/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1

中小企業のM&A、留職事情について調べてみた

最近新規事業として大企業から中小企業に留職(留学の社会人版)する事業を検討していて、周辺事情について調べてみた

背景

日本に380万社あるといわれている中小企業は後継者不足がとにかく深刻。ざっと試算ではこの中で100万社ほどが 社長が60歳以上&後継者不在だと言われている。当然この中には黒字企業も含まれている

中小企業のM&Aについて

上記のような問題があるので、ここ数年で中小企業と個人のM&Aが盛んになってきた。M&Aというと企業がやるもので 数百億のディールとかイメージしてしまうが、中小の場合は数百万レベルでM&Aできるものも多く存在する。 ただ当然だけど、購入しようと思っても個人が中小企業を探すの大変だから最近多くのプラットフォームができてきている。

https://macloud.jp/

https://www.tranbi.com/

https://fundbook.co.jp/

あとはこの辺りのテーマについてドンピシャな本がある

要約すると

  • 老後不安だろうし、頑張って資本家になろう
  • とはいえ0→1企業は難しいしリスク高い
  • 飲食店経営もレッドオーシャンでおすすめしない
  • 後継者不足の中小企業を経営するのがおすすめ
  • 中小は普段大企業で当たり前にやっているような業務効率改善(Excel使うとかのレベル)ができていないから、普通に大企業で働いて自然に身についたスキルで十分貢献できる

https://www.amazon.co.jp/dp/B07C21NBMM/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1

事業検討について

事業検討していく中で、それなりのキャリアの人が中小企業で働くにしても、会計、人事とかの専門知識ないと厳しいかなーと思っていたのですが、中小の業務の実情が結構レトロそうなのでいわゆる真ん中くらいの普通の層でも大企業でしっかり業務プロセスの仕組みを学んでいれば中小企業で業務改善などで活躍できるかもというのは新鮮だった

本だと上のTRANBIとかM&A仲介サイト使って探すの進めてるものの、相当ハードル&リスク高いと思うので、実際やる前に一度体験するという留職は中小側にもニーズありそう (実際、本でもリスク把握のためのデューデリジェンスと社員との信頼関係を作るためにまず2年位は役員で働くこと勧めている)

留職だと現状は大企業とベンチャーを結ぶこういうのがある。

http://loandeal.jp/

留職考える上で難しいのは、派遣元企業、派遣先企業、社員のどこにピン留めするか。 それぞれのニーズ想定すると

  • 派遣元企業

    • 中間層派遣して、メッチャ優秀になって帰って来てほしい
    • 最悪優秀にならなくてもいいから、さっさと退職させて代謝良くしたい
  • 派遣先企業

    • 大企業のノウハウ知りたい。業務改革したい
    • 後継者欲しい
    • お金はあんまりかけたくない
  • 社員

    • 経営者やってみたい(ここは老後ゆっくりしたい層と、暇だし肩書欲しいし働きたい層で結構違う)
    • とはいえ年で老後もあるし、金銭的なリスクは最小限に押さえたい

上のローンディールとかは派遣元の「中間層派遣して、メッチャ優秀になって帰って来てほしい」にフォーカスしてる気がする(しかもメインターゲットは30代)。 中小企業の後継者不足&黒字倒産にピン留めするならどういう座組みがいいか要検討。

エンジニア組織における組織開発について

先日会社でこんな感じのイベントをやってきました

https://tech.recruit-mp.co.jp/event/post-16667/

ぶっちゃけ転職して今の会社に入るまでは組織活性、組織開発という言葉も知らずにひたすら

  • 雑談大事
  • 1on1大事
  • メンター大事

みたいな戦略なき根性論みたいなことしかやってこず(それでも一定の効果は出ていたと思う)、しっかり組織開発について自分でも学んでみました。

イベントの趣旨として、実現したいのは開発組織におけるあらゆる知見がなめらかに循環する世界で、 中でもこのイベントの中でも参加者の1人が言っていて印象に残っているのがエンジニア組織は組織開発のsandboxということ エンジニア組織は規模もそれほど大きくないことがほとんどだし、エンジニア自身が勉強熱心で流行りに敏感だし、変化の許容量が大きいので最適だと、確かにその通り

ただ現状の問題として大体会社ごとに1つしかsandboxを持ってなく、そこへのcommitログが公開されておらず他社から見れないこと それにより、ある場所で起きているrevertとか、他の場所でも全く同じこと繰り返したりしてる ここらへんを循環できるようにしていきたいなと

最終的には別に他の会社のsandboxにcommitしてもいいと思うし、お互いのログを見せ合うことでかつてないほどお互いのコアな部分を知り合うことができると思っているので その関係値を利用した、施策とかが行えれば面白いなと思っています。

アジャイルについて最初に知るべきことだけをまとめてみた

今の副業してるところが本格的にフルコミットのエンジニアと学生インターン数名で開発組織を作ろうとしていたものの アジャイル開発について開発フローも何もかも全然わからんという状態だったので、 とりあえずアジャイルサムライとかScrum Boot Campとかエンジニア組織論への招待とかは読んでもらうとして

最初に知るべきことだけをまとめてみた。

  • 歴史
  • アジャイルに対する誤解
  • 目指すべきところ、そのために明日からやること

という構成に

特にこだわったのはアジャイルに対する誤解のところ

これだけ色々なところでスタートアップやっているアントレプレナーやエンジニアがいる中で アプリの開発について色々聞いたことや、ちょっとググって色々な資料が出てきたりする。

大体開発やったことない事業サイドの人だと、それらの情報から間違った開発フローのイメージ持って 突き進んでしまうなと経験的に感じているので、歴史的経緯と誤解を解消して事業サイド、開発サイド もゼロベースでスタート地点を合わせてこれから皆でインプットして健全に議論しながら 進めていこうというところを目指してみた

https://speakerdeck.com/hikoharu06/aziyairudeiketerutimuru-men

GTmetrix使ってサイトのパフォーマンス改善した

これは何

ブラウザアプリをGTmetrixというサイトのパフォーマンス計測するサービス使って、速度面でのボトルネックを特定して解決した話

https://gtmetrix.com/

そもそもなぜやろうと思ったか

最近、SEOやらコンテンツマーケティングやらに興味が出てきて、グロースハック的なmeetupに行っている。 その中である人が、「グロースハックには色々施策あるけど、一番コスパのいい施策は速度改善」と言っていたのが印象的だった。 実際に自分がプロダクトオーナーやっているサービスで試してみた

実際やってみた

これが最初に計測した時

f:id:hikoharu06:20180802160803p:plain

屈辱のF評価。。。。 どの項目が悪いか調べると

  • Serve scaled images: 必要以上に大きい画像を用意して、cssでサイズ調整している

  • Enable gzip compression: gzip圧縮を使っていない

  • Leverage browser caching: ブラウザキャッシュが有効になっていない

が問題なのがわかる。

なので、それぞれ

  • Serve scaled images: 画像のサイズ調整

  • Enable gzip compression: nginxでcss,javascriptgzipするようにnginx.conf設定変更

  • Leverage browser caching: nginxで静的ファイルを30日間ブラウザキャッシュするようにnginx.conf変更(ブラウザキャッシュはブラウザ側の設定だけだと思っていたので、nginxにも設定あるの初めて知った)

結果が

f:id:hikoharu06:20180802160742p:plain

喜びのA評価!!

まとめ

まだサービスが動くようになってから、数ヶ月ということもあり2〜3時間程度で対応できた。nginx周りで少し詰まったので、知識ある人なら1時間以内とかでできると思う ただこれが1年運用したとかになると、膨大な修正を入れなければならず、永遠塩漬けになる未来が見える。。。

持論だけど速度改善(にとどまらず改善系全般)は担当者がちょっと手が空いた2時間くらいで「やってみるか」という状態にいかに保つことが重要だと思う。

  • マメにリファインメントして、課題の粒度を細かくしておく
  • 計測方法、修正方法の確立
  • チームの文化(空いたらその分機能開発ではなく、改善に力を注ぐ)

のを常に実行しようというのが改めて身にしみた

Google I/Oで発表された電話予約、Duplexについて

Google I/O行きたかったけど、行けなくて発表されたものを一通り見ていました。 多分みんな同じだろうけど、一番の注目はDuplex

https://www.youtube.com/watch?v=bd1mEm2Fy08

https://japanese.engadget.com/2018/05/08/google-ai-duplex/

電話予約をGoogle Assistantがお店の人と電話してやってくれるという、ペコッターの中の人いない版ですね これは大きなゲームチェンジの可能性があうのではないかと。。 従来、電話で予約やら問い合わせやらやっていましたがこれだと

カスタマー - 時間に縛られる同期的なコミュニケーションしかできないので、人によっては手間

店 - 電話でのやり取りがデータとして残らないので、Q&Aや予約状況とかを公開ができず、いつまでも工数確保が必要

という課題があり、「じゃあWebサービス上でやったらよくね?」ということで美容院やら飲食、最近は病院とかまで ネットで申し込むという文化が徐々に広がってきたわけですね ただ結構長いことやっているけど、色々な問題がありカバレッジが一向に100%にならない。これって性質上、60%と80%の違いってそれほどなくて100%にならないと 意味がないものかなと思っています。

Duplexは技術の未来感、カスタマーから見たらとても便利なものの、店側としては対応工数変わらず、それほど嬉しくないという特徴があり、これが広まっていって 誰にとってもいいのかという不安があります。 まあ、Googleのことだから店側もAI用意して、AI同士で解決できる。もしくはAIと店側の会話内容からデータ作成するくらいやってくれそうですが

とにかく、レガシーなコミュニケーションしていたのをWeb上でやることで価値を出してきたサービスはこれから危なくなるんじゃないかというのがざっくりとした感想です。

Macのメモ帳のデータを手動で復旧した話

知人がMacのデータが全て消えてしまって、死にそうになっていたのでメモ帳の復旧をした話。経緯としては

  • Adobe Illustratorを入れようとする
  • インストールしようとするも、ハードディスクの設定が「大文字/小文字を区別する」という設定になっており入れられない
  • どうにもならないので、ハードディスクを初期化して設定を変えようと思い、Time Machineを使って全てバックアップした上でフォーマット
  • 「大文字/小文字を区別しない」設定にして、Time Machineから復旧しようとしたところ、フォーマットが異なっており復旧できないという事態に。。
  • しょうがないので、ファイルは外付けHDのTime Machineから手動で復旧、ただメモ帳に関してはファイルの実態がわからず、復旧できない。超大事なデータが入っておりヤバイ。。
  • iCloudに保存されていれば大丈夫だと思ったが、なぜかバックアップの設定をしていなかった。。。

というところで依頼され、色々ツッコミどころはあるものの、すでにメモ帳以外のデータが復旧されていたため、一旦スルーしてメモ帳の復旧作業始めることに

アプローチとしてはiCloudにバックアップされてない以上、メモ帳の実体ファイルを特定してTime Machineのバックアップ内から探して持ってくる以外は手がなさそうなので、 やってみる。

色々調べた結果、どうやらメモ帳の実体は

  • ユーザー名/Library/Containers/com.apple.Notes/Data/Library/Notes/ の NotesV6.storedata** :独自の拡張子でメモ帳内の情報がファイルに記載されている。一応テキスト形式なので、エディタで確認可能。
  • ユーザー名/Library/Group Containers/group.com.apple.notes/ の NoteStore.sqlite** :sqliteファイルでインデックスなどの情報が格納。ここにはあるテーブルにメモ帳の題名と、上記のファイル内の対応する本文のキー情報が記載されている

で管理されているらしい

ということでTime Machineのバックアップフォルダの中から、上記のファイルを探して、Macのものと置き換えて無事復旧。 まさかMacのメモ帳がsqliteで管理されているとは思わなかった。。。というかなりマニアックな知見でした。

ちなみに多くのブログやQAでは

ユーザー名/Library/Containers/com.apple.Notes/Data/Library/CoreData/ExternalRecords

というところにデータの実体があるという回答が多かったのですが、確認できず

https://discussionsjapan.apple.com/thread/10175353

このブログがなかったら、なかなか厳しかった(とはいえ、該当フォルダ内のファイルはそれほど多くないので、手当たり次第チェックすれば多分たどり着ける。未確認だがフォルダ毎もってきても多分うまくいくかも)

https://gachan55.blogspot.jp/2016/05/el-capitantime-machine.html