Software EngineerがSports Businessに行ってみた話(ex-MIXI Advent Calendar 2023/12/01)

Advent Calendarとしては通算3回目、個人的に関わるのは2度目のex-MIXI Advent Calendar 2023、初日は masartz がお届けします。
ちなみに前回2017年のときの記事はこちら。

masartz.hatenablog.jp

MIXIには2007年から2014年まで7年間所属しておりました。
当時もちろんSNSmixi」を使っていた自分も時を経て、今は「みてね」に子供x2の写真・動画をアップする毎日です。
SNSmixi」が来年に20周年、モンストが今年10周年など既存の事業が長い間継続し続けているのも素晴らしい一方、スポーツビジネスの領域などにも取り組み、今はJリーグのFC東京の親会社という立ち位置であるのも、当時は全く想像できなかったことでした。
一方、今所属するメルカリも同じくJリーグの鹿島アントラーズをグループ会社に迎え入れています。 Jリーグの試合で「自分のキャリアダービーマッチ」ができる人はなかなかいないんじゃないかと思うし、サッカーファンとしてとても幸せなことだと思っています。そしてサッカーファンであることを拗らせて、実は2021年10月から2022年3月までの半年間、Software Enginnerとして鹿島アントラーズの業務に携わっていました。
「鹿島でエンジニア?」と色々と聞かれることがあるので、せっかくなので「スポーツビジネスとSoftware Engineer」というテーマで書いてみようかと思います。

取り組んだ経緯

前提として、当時入社後5年くらい経っていて、事業やRole( Enginnering Managerをやったり、Technical Product Managerをやったり)でできることはやった一方、成果はどれもあまり出せずに行き詰まっていた。そんな時に、アントラーズを含むSportsBusiness事業のチームにjoinできる機会があった(※現行の採用プロセスは異なります)。状況としてはそれまでいなかったSoftware Engineer第一号だったので、定められたJDのようなものはなく、「自分で切り開けられれば、なんでもできる」状態だった。なので、「Software Engineerとしてスポーツビジネスにコミットできるのか」という課題の検証をするべく、飛び込んでみたというのが事の発端だ。

実際に業務を始める際に事前に想定していた事として、おそらく業務にいくつかのベクトルがあるのだろうなと思っていた。

  • For Customer
    • いわゆるサポーター向けのtoC施策、オンライン・オフライン含めた様々な施策がある
  • For Football, Player, Team
    • 根幹であるチーム運営に関わる様々なこと。チーム強化に関わること全般
  • For Company
    • 鹿島アントラーズ社に対して、会社運営に関わること。Corporate IT と呼ばれる分野を含む様々なこと

という分類分けをしていたけど、アントラーズの組織もまさにこのような感じで部門が分かれていて、初期のキャッチアップが思った以上にやりやすかったりした。

やってみてどうだったか

結論としては、Webサービスを提供・運用する事との違いの大きさをまじまじと感じた、というまとめになるのだが、もう少し紐解いていく。

ビジネスグロースについて

スポーツビジネスはスケールしない、と書くとかなり語弊がある。Webサービスのスケールが異常、というのが正しい。ある日を境にユーザー数が10倍になったりすることが平気であるのがWebサービスだ。
一方で、スポーツビジネスではそんな事は起きないし、ある日突然10倍の入場者にスケールする事とかはない。これはスポーツビジネスに限らず、物理プロダクト(鹿島ならサッカーチーム)を持つ事業に当てはまる。

sotarok-sanのblogを引用させてもらうと

note.com

  • MAU1000万とか、CVRが2%改善したとか、流通量が100億を超えたとかを目指して作り上げていきます。インターネットを利用したスケールするビジネスと言う事は基本的にそういうことなのです。
  • まず場所や広さによりMAUの最大値がほぼほぼ決定されます。利益率や顧客単価は努力で上げ得るものもありますが、それでも上限値は存在します。つまりビジネスはスケールしません。
  • 一方で、ミクロなレベルでの体験の濃厚さと言うものが存在します。

上記のように書いており、まさしくこれである。

テレビ(DAZNなど含む)を含めた視聴者つまりお客さまというのは地球規模で数えられるほどのスポーツがサッカーなのだが、個々のチームかつ、その事業的な面も含めて見ていくと、スタジアムに来場するお客さまからの入場料やグッズ収入というのがスポンサー(パートナー)収益と並んで売上の大きな柱となる。そしてこの変数の一つの要素であるスタジアムのキャパシティというのはWebサービスインスタンスのようにある日突然倍増するものではない。

一方、Webサービスを運営している事業の場合、無限のスケールからくる無限の売上によって莫大な投資をしたりする。技術投資もその一部に含まれ、Software Engineerの生産活動と生存領域はその中にある。一方で、スポーツビジネスは年間の売上・予算などの上限値が実質的に存在し、利益も必然的に導かれる中で生きていく必要がある。まして、当時はまだコロナ禍だった。

となると、Webサービスのような大きな技術投資をするよりも、技術によって業務効率化を図るのが最も合理的なアプローチになる。いわゆるDXが一番効きやすい部分だ。これは上述の分類分けでいうと「For Company」の部分に該当する。コーポーレート部門(社内IT)としての活動がイメージしやすいと思われる。具体的な業務としては「SlackのIntegrationを作成して、〇〇を効率化しましょう」とかになる。

ついでに他の領域の部分を具体に落とし込んだ説明をすると、「For Customer」は例えばサポーター向けの公式アプリを通じて、エンゲージメントを増やすための施策検討などだ。さらに補足すると「For Business Partner」もこれの隣にあたるところにあり、いわゆるスポンサーへの営業や権益に関わる部分がある。そこで技術的に検討できそうだった例として「物理の広告面に対して、各スポンサーロゴの紹介を個々の契約形態を考慮しつつ、どう最適に表示するか」みたいな課題があったりした。

最後の部分が「For Football, Player, Team」であり、チーム強化の部分。ここに対するSolutionとしてイメージしやすいものとしては「試合映像を解析して、戦略分析に役立てる」みたいなカッコ良さそうなやつだ。一見やれる余地があるように見えるが、実はこの分野は結構開拓されていて、海外を含めたベンダーがたくさんある。とても一人でゼロから事業を立ち上げて、太刀打ちできる領域ではなくて、ベンダーの技術選定をしたりする方が余程エンジニアリングの価値を出せたりする。また、ここにもスポンサー権益ビジネスという側面があり、スポンサーとのリレーションを活かしたコスパの良い技術選択というものも、事業的に見て大事なポイントだったりする。

Software EngineerとSoftwareのコアコンピタンス

要約すると、「ガリガリコード書いて、Productを作りValueを出す」ような直球勝負ではなくて、技術力を活かしたそれぞれの領域の期待成果を出すようなアプローチが導かれる。そのもう一つの前提が、Software Productが事業のコアコンピタンスではない、という事実だ。
鹿島アントラーズコアコンピタンスフットボールチーム、つまり主役はサッカー選手だ。

これまでのキャリアで、ありがたいことに「エンジニアさんあっての(事業|会社)ですから、ありがとうございます」みたいな事を言われる事があった。そのたびに「いやいや、みんなで作っている(事業|会社)でしょう」と思ったり返答してきたつもりだ。今でも本当にそう思っているが、一方で「エンジニアが主役」であることもまた事実なのだと感じた。それは鹿島で「主役ではない」環境を経験したからこそそう思う。

どんなに良いSoftware Productがあったとしても、また仮にそれをゼロから作ったとしても、それによって本当の意味で「直接的に」勝利に貢献するということはない。もちろん間接的には、試合環境を整えたり、サポーターの熱量を高めたり、チーム強化をしたり、などが勝利の変数にはなっているのだが、そのインパクトは決して大きくない。何と比べて大きくないか、と言えば、Webサービスを提供するためのProductのコードを書くことと比べてである。

例えばサポーターの熱量が勝利にどれだけ貢献するかで言えば、俺はサッカーは12人でやるものだと思っているし、W杯を現地で観て勝利の瞬間を経験した身として、そのインパクトの大きさを絶対的に信じている。

あくまでWebサービス運営との比較である。Webサービス運営において、エンジニアは確実に試合のピッチの上に立っている。ボールをゴールに突き刺すことができる立ち位置だと思う。かつてEngineering ManagerやTPM(Technical Product Manager)をやって、「現場からは退いてしまったか」という葛藤がずっとあったが、どのRoleもピッチの上でのポジションチェンジだったと思う。

まとめ

という訳で、Software Engineerとして出せるValueが(相対的に)少ない立ち位置で、見込める事業成果の規模に対してコミットし続けるか、という選択を改めて問うた時に、せっかくのチャンスだったが今回は離れようという決断をして、メルカリ側の事業に戻った経緯でした。悩むポイントはたくさんあり、ちょっと挙げるだけでも

  • 役割が固まってない魅力、なんでもできる段階である点
  • サッカーファンとして、働く環境の魅力
    • 選手の練習グラウンドが窓から見える
    • 業務中にうっかりジーコとすれ違う
  • ゼロイチフェーズっぽい成長余地
    • 本職のスポーツビジネスとしてはもちろん歴史・伝統ありなのだけど、Engineeringで改善できる余地は多分にある
  • 地域密着の理念とその実践ができる

などなど、伝えきれてない魅力は他にもまだあると思いますが、例えばそんなところ。

振り返ってみれば、限られた期間の取り組みだったが、携わるときには「このままサッカービジネスに行くかもしれないな」と本気で想像しながら取り組んだし、今でもボランティアベースで関係は継続させてもらっている。 メルカリ内でなければできない挑戦だったし、言うても当たり前にSlackを導入できていて、使いこなせてるリテラシーのあるJクラブがどれだけあるのか、っていうのは環境的に恵まれていたことを強く推しておきたい(FC東京もそうであることを願いますが)

また、このチャレンジを後押ししてくれたのも、小泉さんはじめ、元MIXIかつ現メルカリの関係者のご協力と配慮があってのことだったので、改めて「mixiが築いたつながり」の強さを感じる経験でした。

という訳で、改めて「Software Engineerとは Software事業を牽引するキープレイヤーである」というありがたい事実を知ると共に、それでもやはり「事業とは様々な役割の人、様々な取り組みによって支えられ、作られていくものである」と思います。MIXI社の事業も、メルカリ社の事業もそうであったし、これからもそうあることを願ってます。

美味しいコーヒーを提供するためのDeveloper Productivity

コロナ禍とコーヒー生活

コロナ禍で自宅勤務がメインになって以降、コーヒーにハマっている。
アメトーークで紹介されていたコーヒーサーバーをふるさと納税で購入し、近所のお店で焙煎してもらった豆を、自宅で挽いて淹れている。
それまではコーヒーの味の違いなどわからなかったが、やはり日常的に飲んでいると豆の種類・焙煎度・挽き方で味が変わることに気づく。(多分厳密には、もっと他のパラメータもあるんだろうけど、そこまでわかってない)同じ豆で、同じ焙煎でも、挽き方やその他を少し変えただけで味が変わったりして「あれ、昨日と違ってイマイチだな」と思うこともあり難しさと奥深さを感じている。

という前置きがあって本題だが、最近 Developer Productivityの向上というのをメインタスクとして活動している。もう少し詳しく言うと、グループ全体の各開発組織(=チーム / project)の開発生産性に係る指標を計測し、その計測結果から改善アクションにつなげる、という試みに取り組んでいる。

engineering.mercari.com

ここで目的としている Developer Productivityの向上って、「美味しいコーヒーを飲んでもらう」という顧客体験に対して、「様々な種類の良いコーヒー豆をより多く提供する」ようなものだな、と感じたという話。

コーヒーの作業工程と味への影響

前述したように、コーヒーの味を分解すると、豆の種類・焙煎・挽き方(and more)に分かれる。ここで注目すべきは、豆を製造するという工程と、製造された豆を焙煎する・挽くという加工する工程に分かれることだ。
当然それぞれの工程に別々の担当者がいて、生産者は日本から見た外国(コーヒーベルトと呼ばれている国々が主)の人たちで、加工者は地元のコーヒー屋の店員さんだったり、自分自身だったりして、全然違った人が担っている。

それらの工程を経て、最終的にエンドユーザー(つまり自分)の前にコーヒーが提供され、それが美味しいものだと幸せである、というストーリーになっている。しかし、違う領域の担当者のそれぞれのアウトプットの品質が、最終的な成果物の品質にも影響してしまうのがデリケートなところだ。特に製造者から見たら、豆の質にしかresponsibilityを持てない状況で如何ともし難い問題と言えるかもしれない。

と匂わせて書いてきたので、コーヒー豆の製造者がエンジニアで、加工者がプロダクト(ビジネス)サイドっぽいよね。というのはおそらくしっくりくるだろう。

Developer Productivityの指標

開発生産性の話をするときに「生産性(が高いこと)をどうやって測るのか」が議論になることがあり、個人的にも未だに結論は出ていないのだが、最近立てている仮説として、「Deployment Frequency(デプロイ頻度)」をKPIとできるのではないかと考えている。Deployment Frequencyは御存知の通り、Google が提唱する Four Keysと呼ばれる指標のうちの一つだ。Four Keysは Deployment Frequency , Leadtime for Change, MTTR, Failure Rate の4つがあり、それらを俯瞰してみていくことでDeveloper Productivityが可視化されるとされている。

実際、今取り組んでいるタスクにおいてもこれらの指標を可視化するのがこれまでのメインフォーカスになっている。それに対して、「KPIは Deployment Frequencyだ」と言うと、4つのうちから1つに絞りこむように誤解されがちだが、そうではなくて、

  • Developer Productivityの向上という取り組みを、とあるFunctionと捉える
  • Four Keysの指標を Functionに渡すためのInput パラメータと捉える
  • FunctionにInputがあれば、Outputもあり、それが生産性向上の取り組み結果つまりKPIとなる。これを Deployment Frequencyと置く

つまり、Four Keysの指標を以てDeveloper Productivity改善に取り組んだ結果を Deployment Frequency向上に跳ね返ってきたことで測るべきではないか、という仮説だ。これは特に今所属する組織がFocusすべき指標として攻めの Deployment Frequency や Leadtime for Changeと守りの MTTR, Failure Rateであれば攻めの指標をKPIにする方が組織風土に合っているのではないか、という個人的な事情も含んでいる。特に、究極的な数値が「0」のLeadtime for Changeに対して、Deployment Frequencyはそれが「正の数値」なので、「向上」施策で「数値を増やす」ことが直感的にわかりやすいし、会社のカルチャー(Go Bold)にマッチしている気がする。

そして、これをKPIとする穴は、Deployment Frequency向上がDeveloper Productivity向上の最終的な目的ではないということだ。
Developer Productivity向上の最終的な目的はなにか?ずばり Business Growthである。すべては事業が成功するために取り組んでいる。これはとても重要なポイントだ。
しかし、Business Growthが目的だとしても、Business KPIと同じ数値をDeveloper Productivity向上の取り組みのKPIとすることはできない。なぜならそのKPIに対してダイレクトにリーチできないからだ。その間には Product Productivityとでも呼べるものがある。より良いProductを提供するための様々なファクターだ。
toCのProductだったらPMの企画設計力・仮説設定力、Designerのデザイン力、BIの分析力、QAの品質確保レベル、CSが握る顧客満足度、などなどどれも欠かせない要素が絡み合ってProductの成否を左右する。

Developerがどれだけコーヒー豆に風味と香りをつけても、焙煎と挽きの工程次第では顧客の望む美味しさにはならないかもしれない。
一方で、加工工程に一流のバリスタを置いていても、豆そのものの質が悪ければ期待したクオリティにならないのもまた同様だ。
そして何より、製造・加工それぞれがベストを尽くしても、「顧客にとってそれが美味しいと思うものか」はわからない。
加工工程でどう処理するかもわからないし、顧客が何を望むかもわからない。しかし「だから我々Developer はただ『質の良いコーヒー豆を提供すること』にfocusする」というのはたとえ論理的であっても、それがゴールになってはいけない。何故なら我々Developerも顧客に提供したいUXは例えば「ホッとするひととき」であり、それを達成するためのProductは豆ではなく、飲み物としてのコーヒーだからだ。

なんのためにDeveloper Productivityを向上させるのか

Developer Productivity向上という取り組みに対して、

  • Business KPIは本質的には追いたいが、成果が見えない数値であること
  • Technicalな数値(e.g. Deployment Frequency)だけを追いたくはないが、成果が見える数値であること

これらを理解した上ならば、それぞれの数値を扱うのも良いのではないかと思う。

これはEMFMで言われている「物的労働生産性」と「付加価値の労働生産性」の違いだと思う。

www.youtube.com

ここまで考えれば、最終的に我々が目指しているDeveloper Productivityの向上というのは、ただ「コーヒー豆を大量生産する」物量の話では決してない。コードを書いてデプロイすることそれ自体に意味はない。「多くの顧客の”それぞれ”が美味しいと感じるコーヒーを飲んでもらえるようにするために、様々な種類の良いコーヒー豆を提供する」ことを目指すべきだ。できるだけたくさんの種類で、できるだけたくさんの量を、できるだけ早く。
Sortware Engineerであるならば、高い技術力で、多くのコミットを、素早くデプロイ、とかになるのではないだろうか。それによって Productの仮説検証の回数と確率を上げて、Business Growthに至るのが理想的なストーリーである。

子育てで活きる目標設定と期待値調整

そういえば、子育て情報が育休時の生後4ヶ月くらいで止まっていた。

masartz.hatenablog.jp

3歳も無事にすぎてすくすく育っており、せっかくなので、その後のメモを残しておきたい

(前置き) 子供の成長のログ

大体、1歳くらいで歩けるようになる。この頃になると、行動範囲が増えるので、それまでは家の中をうろつくだけでラクだったなぁと今にして思う。
大体、2歳くらいから言葉を喋るようになる。今振り返ると、それまでの意思疎通をどうしてたのかもう思い出せない。喋れなくてもなんとなくわかっていたのは今にして不思議。
1歳半くらいから一言くらいの言葉なら発するようになった気がする、2歳を迎えてようやく「公園、一緒、行く」みたいな文が繋がった時に感動したが、それから会話になるまでがあっという間だった気がする。

うちの子の場合、夜泣きがなくなったのは多分2歳半以降だと思われる。寝たあとに仕事をし直してから、遅れて寝る。というのができるようになったのはこれ以降。それまでは、そもそも寝るのが遅くて23時近くなることも多かった。「寝るのにも体力が必要」というのは逆に自分がこの歳になって、年々睡眠時間が減ってきて感じることでもあるが、まだ小さいこの時点では身についていないのかもしれない。

1歳半頃に夜泣きで起きてから寝かすのに散歩(AM2時)とか、2歳頃に寝かしつけのために外を1時間散歩(22時頃)とか、時期はそこまでピンポイントではないのだが、記憶にあるのはその辺。

(本題) 子育てで意識しているマネジメント方法

前置きメモはこれくらいにして本題はここから。
子育てをしていて、仕事のピープルマネジメントが役に立ったと思うのは「期待値調整と目標設定」だ。
これは普段から日常的に意識して取り入れている。
とにかく子供は、やりたいことを無限にやりたがる。散歩でも、ブロック遊びでも、お風呂でシャンプーの栓をプッシュしつづけるでも、ずーっとやる。これをいきなり制してしまうと大体ギャン泣きになる、けど、こちらとしては止めてほしい(特にシャンプーのプッシュ)。
その時には「あと1回で終わりね」と言ってから、止めるようにしている。目標を共有した上での行動を促す期待値調整だ。
多分1歳になる前くらいから取り組みはじめてたと思う。と言っても子供の期待値など不明瞭なものなので、約束したところで「まだやる!」というのは日常的にある。それでも「じゃあ、あともう1個ね」と折れることも必要で、「もう1個」がN回続くことも当然ある。それじゃ意味ないのでは、とも思われるがどこかの段階で「1個って言ったので終わり」と区切って、強制終了させる。
それで結局ギャン泣きになるんだけど、「それはお前が約束しただろう」と大人側が割り切ることができて、甘やかさずにギャン泣きを受け入れるためにも期待値調整は必要。実際に、初回の「あと1個」ですんなり終わるケースもあるから、それはそれで子供の成長を感じられる。

大人が持つ事情という子供にとって見えない目標

何かを止めさせたい時には、大抵は大人側の事情がある「ご飯を食べさせたい、お風呂に入れたい、寝かせたい」などが筆頭候補。なので、その意図を伝えることも大事なポイントだ。つまり目標設定。「お風呂に入るから、おもちゃはあと1個遊んだらおしまい」と伝える必要がある。「お風呂に入るから」を省くと、おもちゃは止められても結局別の遊びをしたがってもう一戦交えることになるだけである。
おもちゃ遊びの「あと1個」の先に、「別のおもちゃ遊び」があるのか「お風呂」があるのかは子供には想像できないし、子供の目標は往々にして「別のおもちゃ遊び」だったりする。ここで、「あと1個」をちゃんと守れたのに「じゃあ、お風呂入ろう」って言われたら、「それはイヤー!」ってなってしまう。

普段1on1でメンバーの仕事を「これをやりきりましょう」とだけ言っておいて、いざ評価の際に「この達成度だとこれくらいの評価(=実はメンバーはもっと良い評価を期待値していた)ですね」というフィードバックに「思ってたのと違うー!」という状況と似たようなものである。

形骸化しないために

「あとテレビ1話みたらお風呂入ろう」とかが日常会話になって以降、子供も成長して慣れてくる。すると今度は子供側から「1個見たらお風呂入るからテレビ見たい」とか打診するようになってくる。そういう時は大体1個で収まらなくて1個見終わったあとに「もう1個」とか平気で追加リクエストしてくる。ここまで来ると「条件提示すればテレビが見られる」と子供はわかっていて「1個」に意味がなくなっている。単純によく聞かされる「1個」をそのまま発しているだけである。
これをそのまま受け入れてしまうと「目標のための認識合わせ」にならなくなってしまい、やりとりに意味がなくなってしまう。なので、「本当は何個見たいか言いなさい」と問い直すようにしている。すると、「3個」とか真の要求が引き出せるので、キチンと目標のためのすり合わせが行われる。例えすり合わせた結果だとしても結局「あともう1個」となる時もあるけど、それも時に許容し、時に却下し、で賑やかな日常となっている。

簡単だけどまとめ

いずれにしても、「なんのために、何をしてほしいか」を話し合うことは子育てでもマネジメントでも重要である。

と、マネージャーっぽく書いているが、実は最近はマネージャー業は全然していない。ただのプレーヤーとしてやらせてもらっている。それこそ子供が産まれてからピープルマネジメントしていないが、それができている人は本当にすごいと思う。

家でも会社でもこれやってたら、自分のエゴを出すところがどこにもないので、精神的にキツいと思ってしまう。少なくとも絶対疲れる、というか家でやるだけでめっちゃ疲れている。仕事でプレーヤー側でいさせてもらえていること改めて大変感謝である。

Technical Product Managerとしての1年の振り返り

まえがき

アップデートできてませんでしたが、約1年くらいTechnical Product Manager(以降 TPM)のRoleを担当しているので、その振り返りです。 ちなみに今回はRole変更エントリではなく、まだ引続きこのRoleを続ける予定です。

What is TPM

JDが公開されているので、まずはこちらを御覧ください

Why TPM

きっかけは 「TPMの組織を作ろうと思うので来てくれませんか?」と現在 Smartnewwsで活躍する @tairoに誘われ、「TPMってどういう仕事ですか? というかPMとの違いは?」という俺の問に対して「まさに僕みたいな人のイメージです!」と説明されて、とてもすんなり合点がいき、それならばやってみたいと思ったのがきっかけです。

When,Where TPM

いつからという意味では、冒頭にも書いた通り、現在で1年とちょっと経ったくらい。 どこの領域という点に関しては、過去に記事にもなっていたこのあたりです。

mercan.mercari.com

How TPM

これは社内でも話題に挙がる項目でもあり、社内向けにも説明用ドキュメントが作られたりしているが、一言で表現するとまんま「Technical knowledgeを持ち、それを用いてProductを成功させるProduct Manager」となる。 これだけ書くと、PMの上位互換のように感じるが、それはある意味正しくて、ある意味正しくない。というのも、plain なPMという定義がもはや難しいと思っているからだ。

note.com

上記記事がとても参考になるように、PMに求められるスキルが高度・多様化する中で、何かしらの専門性を持つPMというのは増えているし、今後も増えていくと思う。数あるその方向性の一つの亜種に過ぎないと思っている。エンジニア向けに説明するなら、PMというのが「Software Engineer」と同じくらいplainなものを指していると思うと良さそう。

これだけでたくさんのことが書けてしまうし、議論ができてしまうが、この記事のメインはそこではないので、細かい定義はここまでにしておく。

現状課題

という訳で、仮にもPMの端くれなので、やることはProduct Managementになる。ここが大事で、Project Managementではないということだ。 両者の違いも難しいが、ProductにはLifecyleがあり、それはProjectのように一直線のものではないのが一つ差かなと捉えている。

  1. Product Concept
  2. Product Design
  3. Product Development
  4. Product Delivery
  5. Product Maintenance
  6. Back to Concept(= Step1)

これも様々なフェーズ分けの定義があって、上記は一例だけど、要は開発して終わり、リリースして終わりではない、ということだ。 このサイクルと自身の作業との振り返り比較で言うと、ようやくサイクルを1周できそうかどうかというレベル。この 1年かけてようやく というスピード感と経験の薄さが現状の最も大きな課題と感じている。 もちろん開発やリリースするのに色々な課題がある。リソースがなかったり、逆にブロッカーがあったり、などなど。 とはいえ、その辺を解決しつつ進めることこそが仕事であり、逆に進めることで成果を出すことがProductの改善につながると思う。 本当であれば、1つのCycleとして振り返り、何をやってどうなったから、次にどうするのか、ということがここで述べられるのがベストなのだが、そこまでには至っておらず、現状における成果をこれ以上に書けないのがとても悔しい。

Technical というPrefixに関しては、メルカリにおけるEngineering経験を活かすっていうことはできている部分があると思う。具体的にはコードやアーキテクチャを知っていることでできる設計の部分などだ。一方で、それは汎用的なTechnical knowledgeではなくドメイン知識だと思っていて、他の環境で同じことができるとはまだ思えないのが正直なところ。 これも大きな課題で、 ただのEngineerがPMの真似事しているな と見られてもおかしくないようなことしかできておらず、PMとしての専門性はまだ全然だと思うのは前述のサイクルを回しきれていない点が物語っている。

Individual Contributor との違い

EngineerからPMというRole変更は以下の資料における振り子を振った状態にあると思っている。

speakerdeck.com

まず、どうして振り子を振ったか、という点であるが、PMの良さとして、Productの What(何をするか) にフォーカスできる点が挙げられる。対してEngineerは How(どうやるか) についてフォーカスできる。(もちろん両方とも「フォーカス」であって、それしかやらない訳ではない。)

Backend(サーバーサイド)領域を抽象度を上げて表現すると、「RDBにデータを出し入れしてレスポンスを返す機能」という1つの大きなHowで括ることができるとして、この1括りのHowで解決しなければいけないWhatは山程ある。

おそらくこれを「1括りのHow」とするのに多くの意見があって、

  • 言語の種類やその性質による開発スピード、規模、パフォーマンスなどの違い
  • インフラ設備の違いによるコスト、Availability,Mutabilityなどの違い
  • NetworkやSecurityなど環境によるコストや制約などの違い

など他にも挙げきれないような多くの差異要素があることはもちろん知っているつもりだ。しかし、それらの要素は全て何らかの課題を解決するための手段として存在・提供しているものだ。 それぞれの要素の特徴や差異の意味を全て詳細に把握はできなくとも理解できるのならば、それを1つの大きなHowとして、多くのWhatの解決に向き合うのは良い経験になるのではと思ったのが振り子を振った理由だ。

逆に、自分の中で勉強不足で全くピンと来ていなくて括りの外にあるのが、例えば機械学習分野。RDBからSelectする代わりにそれと同じような感覚で機械学習モデルからデータを引くようになったとして、そのシステムの当たり前さをどれだけ咀嚼できているかは今時点ではさっぱりだ。この不透明さによってWhatにフォーカスできなくなるようなら、それが振り子を戻す時かもしれない。

まぁ、でもここまで書いて、完全に逆もまた然りだなと思った。 「顧客の求めるサービスを提供する」というのを1つのWhatという括りにするなら、それを解決できるHowも山程ある。その山を自身の中に積み上げる目的で、エンジニアとして技術力を磨く、というのも全く成り立つし、とても良い経験になると思う。

EMとの違い

一応、かつてEngineering Managerをやっていたので、それとの比較も書いておく。

個人的な経験だけでもの凄い簡単に言うと、

  • 人のために人にアプローチするのがEngineering Manager
  • Productのために人にアプローチするのが Product Manager

だと感じている。結局どちらも人にアプローチするのは一緒、というのがまず大事なところ。

この時、アプローチに行き詰まった際に、突き詰める先としてEMの場合「あなた」というベクトルに対して突き詰める訳だけど、ここが個人的に難しかったポイントだと思う。 「あなたのことを考えに考えて、○○したいんです」というのは、恩着せがましいというか、おこがましいというか、それってなぜ自分がやらないといけないんだっけ、と思って躊躇うことが多かった。

一方PMの場合は、「Product」へのベクトルを突き詰めれば良い、具体的にはプロダクト開発をしたいためにエンジニアにアプローチして、それが合意されない場合おそらくQCDのどこかに問題があり、それぞれについて突き詰めることになる。 Qualityを上げるのか、Costを下げるのか、Deliveryを遅らせるのか、とかを検討できれば合意できるケースが多いのではないか。もちろん例外もあるだろうし、QCDのどれかがUncontrollableであることも往々にしてあるだろうが・・ それらがControllableであるならば、QCDへのアプローチがReasonableかつLogicalであればあるほどその分だけ合意に近づけやすい。またReasonableかつLogicalにやるっていうのはエンジニア脳を使えて、やりやすくて良い。

そういう意味では、今の環境がQCDがControllableなので、恵まれているのかもしれない。。より厳しい環境でPMをやった上でのEMとの比較が必要かもしれない。

・・・と、ここまで書いて思ったが、QCDというのは実は浅い課題で、深い行き詰まりだとProductのMission/Vision などへの不合意になるのではないか。これらを突き詰めてエンジニアにアプローチする際には、Logicalに、だけでは成功しない。Logicの積み上げだけでVisionには到達しないからだ。むしろある種の熱意を持ってアプローチする必要があり、それは俺のめちゃめちゃ苦手な分野に該当する。PMだからLogicalで簡単というのはおお大きな誤りということになる。

しかも、もしMission/Visionが語れるのならば、EMとしてももっとできることがあったかも、とも振り返れる。多分

  • 人のために人にアプローチするのがEngineering Manager

この前提自体が違っていて、あるべきは『組織のために人にアプローチするのがEngineering Manager』だ。 思い返せば、EM時代もMission/Visionをマトモに考えられたことはなかった。どういう組織(これはEngineering Division全体もそうだし、自チームもそう)にしたい、という明確なモノは持っていなかった。当時、人に翻弄されているように感じたのは、指し示すものがない中で彷徨っていた感があったかもしれない。暗中模索という言葉がまさにしっくり来る。

つまり、結局Roleは変わっても自分の突き当たるべい苦手分野は一緒で、それは克服はできていないのでは、と思い始めてきた。

何が言いたかったか

それなりの理由を持って、TPMに取り組もうと思ったのでその背景整理をしつつ、現状課題というこの1年の整理を書き残すのが当初の目的だったが、Enginner及びEMとの違いを補足で書くつもりが、実は大して違わないし、課題は同じだった、ということを書きながら思ったのが自分自身の収穫になったというオチ。

書いてみたら、小さいもの課題として捉えてた反省が見つかった。いや、小さくはないか、基本的な事で事実自分には足りていないものだが、それよりもっと大きな根本的な課題があるのがわかったという学びか。

おまけ

再掲ですが、ちょうど最近OpenになっているJob Descriptionはこちらです。 ご興味のある方は、カジュアルにでも構わないので、ご連絡ください。

2ヶ月間の育休取得を終えて

2020年1月より2月末までの丸二ヶ月間、育児休暇を取得させていただきました。 この背景にはmerci boxと呼ばれる会社の手厚い福利厚生があることと、実際にそれを用いて育休を取得した先輩パパ達が数多くいたからであり、改めて感謝しています。 ということで、恩の還元の意図も込めて、(前回経過を少し書いていたけど)今回はそのまとめです。

想定読者と前提条件

  • これから育休を取る(あるいは検討している)方(で一応エンジニア)に向けて
  • うちの環境がこうだった(他では違うこともある)前提条件としては、
    • 生後3〜4ヶ月目のできごと(生後すぐは妻の実家に里帰りしていた)
    • 一人目の子供(上の子がいるときっとまた状況は違う気がする)
    • 母乳育児(後述しますが、ミルク育児とは夫のできる活動に差がある)

TL;DR; やってみてどうだったか

  • ちょうど同じ時に育休を取っていた小泉進次郎が言うように、育休は全然休暇じゃないし、むしろ日常の仕事よりしんどかった
  • これまで妻より家事をやってこなかった人はやったほうが良い
  • 育児も仕事と一緒で、経験と慣れが必要
  • 同じく、市場(子供)が刻々と変わるのも仕事と一緒
  • 仕事への向き合い方、キャリア形成の考え方も変わりそう
  • 我が子は何よりも可愛いので幸せである

育児「休暇」ではない

やる前から忙しいだろうと思っていたけど、やってみたら本当に忙しかった。 どこでそう思うかというと、休日がないからだ。労働基準法に則った業務なら1日ごとの営業時間と休日があるが、育児は24時間/365日の作業だ。そういう意味ではwebサービスを運用しているエンジニアは作業をイメージしやすいかもしれない。ただし、そのサービスはActiveなインスタンスが2つあるだけで、それ以上のスケールアウトやバックアップがない。リクエストを捌くロードバランサはないので常にActiveでいる必要がある。
と書くと深刻そうにも読めるが、まぁこれは「夫婦」というサービスが始まったときからその運用は始まっているとも言える。子供という膨大なリクエストを送る顧客を手に入れたという変化だけかもしれない。

子供からのリクエストのトラフィックを捌くために

というわけで、子供からの要求をいかに対応するか、というのが結局のところ育休中に取り組むべきことだと思う。 この辺についてパートナーとよく話し合うこともこのまとまった時間があるからこそできること。 ただし、話し合うためにある程度2人の間での前提条件を合わせる必要があり、そのためにまず一通りの家事ができないといけない。

洗濯を普段やる人と全くやらない人では課題認識が違うので、その状態で「ドラム式乾燥機付き洗濯機」を買うかどうかを議論しても、その結果について双方納得することは多分難しい。 (余談としては、「ドラム式乾燥機付き洗濯機」は絶対に買うべき)

我が家の場合、お互いに一人暮らし経験があり、結婚後も共働きで家事は分担していたため、そこの差はあまりなかった。(俺が料理ができないというのが大きな差) 一方で、子育てに関しては生後3ヶ月まで妻が里帰り育児をしていたというのは大きな差だった。日々のオムツ替えや、3時間起きの授乳・夜中に寝てくれない、などを十分に経験していた妻と週末に少し参加していた俺のギャップは大きかった。

ギャップがある時にどうするかは前述の通り、前提を合わせるために追いつくしかないので、そこは妻を見習って頑張りましょう

育児も仕事と一緒で、経験と慣れが必要

1ヶ月経つくらいまでは、大変だった。 この頃に思っていたのは「2020年に育児はなんて非科学的なんだろう」ってこと。 特に妊娠から出産までの間で「科学の進歩」を感じた人は多いのではないか。 妊娠初期からエコーではクリアに赤ちゃんが見え、妊娠時期ごとのリスク一覧が都度提示され、さらには出生前診断など重い選択を迫られたりもする、、 一方で、産まれてきてからについては、「○○ヶ月頃に (夜泣き|人見知り|黄昏泣き|etcetc)が始まります、(抱っこして|あやして)あげましょう」みたいなことしか書いてない本もある。親という無限の愛の提供者としての踏み絵をさせられてるのではと思うほどだった。

それでも2ヶ月目になるとようやく慣れてきた。それによって考え方も変わる様になった。 例えば、最初はベッドで寝かすしつけをしたかったがうまくいかず、抱っこで寝かせながらモヤモヤした気持ちになっていたが、この頃になると朝寝は妻より自分が抱っこする方がスムーズにいくようになり、うちの子は寝る前にひと泣きするので、泣いたらシメたものとさえ思える様になった。

後半の方が体重が増えて大変だったハズなのだが、むしろ抱っこしてすぐ寝てくれるのがラクだと感じるようになったのは単純に慣れたのだと思う。根性論であり非科学的、と過去の自分にツッコまれればそうかもしれない。ただ、赤ちゃんは既にこの世に解き放たれたており、多種多様な環境で画一的な分析などできないんじゃないか、くらいの反論ができるようになった。大人に「○○すればXXになる」などの画一的なアプローチが当てはまらないように、赤ちゃんもそうであり、それが人間ってものだと思って納得できるようになった。

結果は後からついてくるものというのも仕事っぽいし、結果がでると楽しいものである。

母乳育児の父としての辛さ

特に母乳育児環境下において「結果が出て楽しい」と父親が感じられるまでは一定の時間がかかるのでそこは心して臨んでいただきたい。 授乳は生後間もない育児におけるハイライトであり、実際それによって赤ちゃんは成長するし、育てている実感も得られる(と思う)。赤ちゃんからの信頼も圧倒的である。
父親はそこにコミットできないので、最初は「マイナスをゼロにする作業」しかできないように感じる。夜に泣いたら寝かす、オムツが汚れたら替える、などの繰り返しだ。新生児の体重はみるみる増えていくけど、自分はそれにどんだけ貢献できているんだろうか、、みたいなことを悩まずに、「こうしたら寝てくれる」「お風呂であれすると機嫌が良い」などできることを少しずつ増やしていけると良い。

前提が揃ったところで、議論開始

そんなこんなで、ある程度対等に話せる様になり、「子供からの要求をいかに対応するか」というオペレーションの対応方針検討になる。 とはいえここは変数が多いので、それぞれに何を代入するか次第と言える。例えば

  • 保育園には(いつから)入れる/入れない
  • 子供はいつまでに何人欲しいうちの今何人目
  • 自分がやりたい、相手にやってほしい家事は何か
  • 日々の安定稼働第一か、多少の波風を時に許容しつつリフレッシュするのを目指すか

などがあり、どういう状態を想定してどういうアクションをするかがポイントになる

市場(子供)が刻々と変わるのも仕事と一緒

と、そこまで考えても全然終わりじゃない。というと身も蓋もないけど、子供が成長するのも重要な変数の一つなのだ。例えば、ちょうど今回の育休が終わったタイミングで離乳食が始まった。上記の変数に「子供の食事をどうするか」というものはなかった。何故ならば母乳一択だったからだ。離乳食だと俺でも担当できることになるので、そうしたら育休期間中に話した内容をアップデートする必要があるかもしれない。

市場は逐次変化するし、それによって発生する案件があって、アサインされる人がいて、タスクの整理分担があって、というのも仕事と一緒だ。

本業の仕事への向き合い方、キャリア形成の考え方も変わりそう

育休を取ったことで、本業の仕事への捉え方が変わるかもという部分も感じている。 よく言うワークライフバランスの感覚はもちろんそうだが、それ以外に育休からの復帰というのは「自分が一定期間いなくてもまわる職場を自分の目で確認できる機会」だと感じた。

「どんなにそれまで頑張っていても、自分がいなくなっても仕事はまわる」これは転職を経験すると感じることができる大事な事実だ。ただ、それを実際にこの目で見たことまではなかったが、今回はそれが見られる初めてのケースだった。 見て大丈夫そうなのでじゃあ辞めようとも、見たらダメダメだったのでもっとやらねばとも思わないが、なんというか「やるべきことをしっかりやる」のが大事なのではないか。
やるべきことをやれば、次に休むとき/異動するとき/辞めるときに迷惑をかけずに引き継げる
やるべきことをやれば、次に戻ったとき/移ってきたとき/入社したときに貢献できる

我が子は何よりも可愛いので幸せである

期間中には区が主催する赤ちゃんクラブ(要はママ同士のコミュニケーションイベント)や、生後4ヶ月検診などにも参加できた。 赤ちゃんクラブには30組程度の親子が来ていたが、父親も参加していたのは自分だけだった。これが男性の育休取得率のパーセンテージを体現しているなと感じた。(このイベント自体が生後3,4ヶ月向けなので、生後直後だったらもう少し多いのだろうか)

その30組の中で、我が子がダントツで可愛かった。
育児に疲れた時こそ、(コロナが落ち着いたら)是非イベントごとに参加すると良い(予防接種・生後検診・行政が主催する取り組みなど)。 我が子はどこで会う誰よりも可愛いので、それを感じるたびにリフレッシュされる。

まとめると、結構先々まで適用していけるのではないかという考え方を整理できた経験だったと思う。
ここまでできたのは、まとまった時間があり、それだけに集中できたのが大きい。週末だけの育児ではできることもここまで増えなかったし、それによって考えが変わることもなかったのではないかと思う。

貴重な時間を一緒に過ごしてくれた妻と我が子に感謝の2ヶ月でした。

育休取得後2週間経っての経過報告

2020年1月の頭から2月末まで、2ヶ月の育休を取得しています。子供視点で言うと、生後3ヶ月からの2ヶ月間になる。ちょうど2週間が経過し、4分の1が消化された。
また話題の小泉進次郎大臣が「生後2ヶ月の間の通算2週間」を取得予定らしいので、小泉進次郎が消化できるのがこれくらいということになる。

ネントレするためのリズムある生活よりも優先したもの

出産前からジーナ式などの本を読み導入を検討していたけど、実際には出産直後は妻が里帰りしていたため、その間のやり方はお任せしていました。それでも大体の授乳時間とお風呂・入眠の時間等は決まってはいた。 とはいえ、12時間寝てくれるなんてことはなくて、夜中に最低1回は起きる。 夜中1回というのは、一般的に決して多くなくむしろ普通。決して悪いものじゃない前提で、こういう12時間睡眠とかを目指した固定リズム制を導入するかどうか。

これを考えた時に思ったのは、「実際これやるのって、1日中家にいる前提だよな、、」ということ。 何時に授乳させ、その後何時間寝かせる。というのが本に書いてあるんだけど、安定的に授乳させられる環境と、ベッドに寝かせて昼寝させられる環境は家以外にない。 逆にでかけてしまうと、授乳室がある場所にいるタイミングに左右されるし、抱っこ紐の中で寝かす・起こすを制御することはできない。

と考えた時に、一旦この2週間はネントレ系のことは考えすぎないようにしようと思った。なぜなら、この期間には以下のようなイベントがあって、

  • ちょうど俺の誕生日だったこともあり、孫を連れて実家に顔出し
  • (育休始まったばかりなのに)俺が連続して数日予定があり、再度妻が実家に帰省
  • 両親への内祝いを兼ねて、家族で温泉旅行
  • 友達と会ってランチ
  • 子供の銀行口座を作ってあげたり、新しいベビーカーの試乗に行く
  • 親を招いて、初節句(雛祭り)の飾り付け

この不規則かつ非日常な出来事のために、むしろ1日家にいる方が圧倒的に少なかった。

特に親と彼らの孫を会わせてあげようと思うと、どうしても生活リズムは不規則になる。移動を考えた時間の授乳になるし、お昼寝も移動中に抱っこで寝かせる運用になる。代わりに一緒にいる間にたくさん抱っこさせてあげられるようになる。
ただ、やっぱりこれらは優先してやって良かったなと思う。リズム作りなどは、(もちろん早い方が良いのかもしれないけど)あとででもできることではある。一方で、すくすく育つ孫と数多く会わせられる期間は限られるので代えがたいものだし、温泉旅行など孫ができる前に行くことは相当な期間なかったので、良い孝行ができのではないかと勝手に思っている。

これからやれそうなこと

とはいえ、この後どうするかで言うと、いくつかトライしたいことがある。 大前提として前述のネントレもそうだが、なるべく負担の少ないライフスタイルを構築したいというのはある。それは特に一人で育児を続ける妻のためでもある。 子供向けの施策は子供自体が成長して変化する、かつ不確実性が高いので、その周りへのアプローチの方が良いんじゃないかという気がしている。

  • キッズラインお試し
    • 家事に困ったときに、どのタイプの家事ならアウトソースしたいか見定める
  • ベビーカーで行けるランチ場所を見つけておく
    • 妻が1人で行けて、昼をラクできるところを見つける
  • 俺ができる料理の品目を増やす
    • できない家事の代表格。この期に改善したい
  • 週末の料理作り置き準備
    • こっちの料理はメインが俺じゃないが、平日妻一人で料理タスクが難しくなるだろう想定のもと

どれも今時点では困っていないことだけど、育休終わったら絶対大変になるだろうな、っていうところ。 この辺の仮説検証を一緒にできるのが育休期間のメリットかなと思っている。また経過か結果でこの辺の進捗を書こうと思います。

pm conf2019 参加レポートと知識の体系化がまだ出来てない話

2019/11/12,13で開催されていた PM conf に参加してきたのでそのレポートですが、既に結構時間経ってしまったので、参加してから感じた自分の知識の体系化への課題の所感も合わせてです。

PM confとは

今年で4回目となる(らしい)Product Manager向けのカンファレンス。規模は年を追うごとに拡大していっている。 今年は1000人以上は来ていたんじゃないだろうか。

カンファレンスのセッションの種類とその市場の成熟度

いきなり大枠から入るが、全体で見ると 市場の成熟度 みたいなものが満ちるのにまだ余地があるように感じた。 これはEngineering Manager界隈にも同じような感想を持っていたので、そこに通じるものがあったのだと思う。

例えば、プログラム言語のイベント/カンファレンスだと、セッション内容に以下のようなフェーズがあると思っている

  1. そのプログラム言語を触ってみた系
  2. そのプログラム言語のライブラリを書いてみた系
  3. そのプログラム言語のフレームワークを作ってみた/使ってみた系
  4. そのプログラム言語でサービスを運用してみた系

徐々に言語への理解が深まり、体系立ったものが身につき、それが業務に活きるというようなストーリーになる。どの辺のセッションが多いかで、その言語や市場が流行っているのかがなんとなく掴めるのではと思う。

これに当てはめてみると、今回のカンファレンスで多いのはフェーズ1か2のイメージに近い「やってみた」系のセッションだったように感じた。 上記のフェーズ分けの整理があらかじめできていた訳ではないが、聞いてみておもしろいと感じたのは、フェーズ3,4系のセッションであり、自分が求めていたのはその辺だったのだなと後になってから腑に落ちた。

フェーズ4の運用面で最も学びがあったのはシリコンバレーで9年PMをしているこちらのセッション

2019.pmconf.jp

残念ながら資料非公開なのでキーポイントをいくつか並べると

  • Think Big
    • 大きな市場を獲りにいくことを意識しているか
    • ちなみに、これをメルカリ風に言うと Go Bold になる
  • Data Driven
    • 直感ではなく、分析能力が求められる
  • 小さく上手く失敗する
    • 逆に失敗がない人はチャレンジをしていないとみなされる
  • Why にfocusする
    • Why と問い詰めることは相手の人格否定でもなんでもなく、本質を見極めること

あたりで、これを述べられるのは完全に、やってきた年数が違う、経験の差という話な気もする。だからこそ貴重なセッションだったし、個人的なベストはこれだった。

もう一つ、こちらは フレームワークの情報がたっぷり詰まっている

www.slideshare.net

実際のカンファレンスの展示物制作を例にフレームワークの使い方を説明しており、理論と実践がとてもきれいまとめられた内容になっている。推敲を重ねた結果、詰め込めるだけ詰め込んだという力作っぷりが感じられる。聞いていて引き込まれる内容だった。

Engineering Manager界隈の体系知識

話は少し変わるが、最近のEM関連のコミュニティで以下のようなイメージの会話を見ることがある。

  • Aさん: こんな形式で1on1をやってみました!
    • Bさん: すごい工夫されていますね、参考になります
  • Cさん: 皆さんどうやってメンバーを評価していますか?
    • Dさん: うちでは○○でやっています
      • Cさん: なるほど、試してみます

これらのやりとりで気になるポイントは コンテキストの共有がない(少ない)のに、会話が成立している ということだ。 1on1も評価もプラクティスだし、背景には何か目的(課題)があるハズだ。それ次第によってアプローチは変わるし、他の事例が良いかそうでないかは判断ができない。 またその上段にはフレームワークと呼ばれるようなものがあり、どのフレームワークからのアプローチなのか次第で期待するものも変わる。

例えば、以前に書いた

masartz.hatenablog.jp

この記事などは、「コーチング」の分野に属するものであり、それについてノウハウが欲しい人には有用情報かもしれない(もしそうだったら嬉しい)。一方で「ティーチング」をした方が効果的なメンバーがいる場合、多分ほとんど役に立たない情報になるのではないか。

その意味では、前述の4段階のフェーズに分類してみると、フェーズ2のあたりでオレオレライブラリをいくつか公開してみたという内容に近く、一方それを体系立てて使える設計はまだできていないというのが自分の現状と感じる。
そうして自分自身を振り返ってみると、どういう背景やコンテキストというのが認識・共有が不十分なまま発信していたし、この学びがどういう知識体系の血肉になるのかがわかってなかったなぁという学びがある。

フレームワークをさらに俯瞰的に捉えて学ぶ

というような話を先日 @hirokidaichi と話していたのだが、その後に公開された記事がこちら

qiita.com

個人的に完全に俺のための記事だー、ということで勝手にアンサーソングを貰った気持ちになって読みました。 これは各フレームワークをさらにカテゴライズして関連づけているため、職種をまたいで俯瞰的に見える素晴らしい記事になっている。 Engineering ManagerやProduct Managerと言う単語そのもの(しかも各社ごとに定義が違う)に囚われるのではなく、どのような知識を持ち、何に取り組むかが大事なことであると思う。

イベントについて、登壇者による発表資料公開について

話は戻して、PM Confのイベント自体についての雑感

過去の情報を聞くと、発表資料が公開されないケースもあるらしかった。 そのせいもあってか、今回も多くの参加者がメモ代わりにスライド毎に写メしていて、それがとてもとても気になってしまった。 カンファレンスにどのように参加するかについては過去にもblogで書いたので、そちらも見ていただきたい。

SREcon19 Asia/Pacific 参加レポート - masartz->log(type=>'hatenablog')
 (カンファレンス参加とレポーティング の項)

多くの人をメモ取る作業から解放するためにも、登壇者の方には資料を公開していただきたいし、それを発表の冒頭で宣言してただきたい。なかにはConfidentialな内容の発表もあると思うので例外は当然あると思うが、今回は2日間ずっとそれが目立った。 撮る人が気になってしまうのは単純に個人の気持ちの問題だが、実際に写メる手によって視界が遮るのは物理的な問題だと思うので避けられるなら避けたい。 かくいう自分も要所のスライドを写メったりはする。即時にTweetしたい、みたいな欲求もあると思うので、完全に禁止とかまでする必要はないが基本は聞いて「理解する」ことに集中できるようになると良いと思う。

また、これも以前触れた通り、各セッションの内容を詳細にレポートする必要もないと思う。大事なのはアクションであり、各セッションから得られる具体的なNext Action は(セッションの質ではなく、聞く側のキャパ的に)多くない。逆にそれだけ得られれば十分ではないかと思う。

まとめ

再掲になってしまうが、
抱えている問題は何で、そのためにどういった体系知識(フレームワーク)が必要であり、何を身につけ・どうやって解決するか、
書くのは簡単だが、これは2020年以降も自分の課題です。