エンジニアからプロダクトマネージャーへ 3ヶ月の記録
皆さんこんにちは。はじめまして。3月からMutureでフィンテック領域のプロダクトマネージャーを務めているさらしーです。もともとバックエンドエンジニアをしており、Mutureで初めてプロダクトマネジメントに本格的に取り組んでいます。バックエンドエンジニアとしてはScalaやTypeScript、またはTerraform、AWS CDK、そしてもちろんSQLを書くことが多かったです。複雑な要件をシンプルな概念に落とすことが本当に好きでした。
本文ではプロダクトマネージャーになった経緯や、その後最初の3ヶ月で学んだことについて書きました。結構赤裸々です。プロダクトマネジメントについてのイメージを膨らませたい方や新しくプロダクトマネージャーになった方、今後プロダクトマネージャーになりたい方に有益な手記になったのではないかなと思います。
なぜプロダクトマネージャーになったのか
プロダクトマネジメントに興味を持った理由
大学在学中やソフトウェアエンジニアとしてキャリアを積む中で、次第にプロダクトマネジメントに強い興味を抱くようになりました。そのきっかけは、学生時代にメディアアートとデザインエンジニアリングに魅了されたことに始まります。そこから、ビジネス・テクノロジー・クリエイティブ（BTC）の各要素を調整し、一つの統合されたプロダクトや体験を創り上げることに情熱を感じるようになりました。
大学では工学を学びましたが、同時に自学として建築のような総合芸術のディレクションについて調べたり、柳宗理のような啓蒙活動を含む様々な領域で活躍するデザイナーの影響を受けていました。その過程でBTCをまとめ上げ効果的なプロダクトや体験に導く重要性を痛感しました。以下に柳宗理のデザイン考、十箇条より、私にとって象徴的な主張を三つ引用します。このようなプロダクト開発の考えに共鳴したことから、プロダクトマネージャー(PdM)という仕事をしたいという思いが具体性を帯びてきたように思います。
…
4. デザインは一人でするものではない。
5. 企業者は何よりもプロダクトマンシップを持っている人でなければならない。
…
10. デザインは社会問題である。
しかし、ソフトウェアエンジニアからPdMに転身するのと同時に転職をすることには多くの課題が伴います。PdMの役割は通常、特定のドメインに深く精通した歴の長いメンバーが担うことが多いです。実際、転職市場で近傍ドメインを得意とするPdMを採用することの難しさを鑑みるに、内部で知見と信頼を築いてきた人材をPdMにコンバートする方が適当なケースは多いかと思います。またその際には、事業ドメインの特性ごとの偏りはありますがBTCどの領域からも登用される可能性があります。転職市場がそれほど成熟していない日本においては、PdMは内部的かつ偶発的に生まれることが多いのです。このような背景で、いちエンジニアから直接PdMに転職することにはリスクが伴うと感じていました。
転身を決意した理由
同時にPdMの本質的にアウトカムに向き合う役割は、私の生きるべき道を示していると感じていました。Marissa Perri氏の「プロダクトマネジメント」あるいは通称ビルドトラップ本を引用するまでもなく、PdMは役割であるだけでなくキャリアです。もちろん、ソフトウェアエンジニアもキャリアです。もし私がソフトウェアエンジニアとしてキャリアを進めたのであれば、コンピュータサイエンス独特のアカデミックとインダストリーの気水域でもう一度大学院にチャレンジしていたかもしれません。けれど私の関心はそこに限定されませんでした。ソフトウェアエンジニアの私は常にサービスのユーザーとの接点とビジネス構造についてふらふらと脇目を振っていました。
Mutureという会社は転職活動の中で一番最後に応募した会社でした。それだけ慎重に、少くとも幾つかのPdMに関する書籍や記事を今一度ちゃんと読んでから面接に進もうと思っていたのです。正直なところ、当時はPdMとしての役割を得るにはもう1ステップ挟む必要があると感じていました。実際に入社前の選択肢には、事業会社でエンジニアリング・マネージャー(EM)を経由してPdMを目指すというプランもありました。伴走型で専門職としてプロダクトマネジメントに関わっていくか、事業会社で成り行きを作ってからPdMに成るか、ここについては最後まで迷っていました。職能がエンジニリングから外れていくことで今後キャリアが行き詰まってしまうのではないか、という視点から見ると、これはPdMという職能が今後の市場でどれほどポータブルになるのかという命題でもありました。
結局のところ、私にとってPdMはキャリアなので一早くPdMとしての姿勢や知識を身に付けることができる方へ進みたいと考えました。というよりも多分そう考えたんだと思います。実のところそこまで言語化して決断をしたわけではありませんでした。単純にMutureという会社のトーン&マナーや選考と内定後のコミュニケーションに惹かれたというところもありましたし、最後はより困難そうな方を選んだというだけだったのかもしれません。
事業会社の採用担当の方がくださった言葉でもあるのですが、このキャリアを正解にするのは自分自身だと本当に思います。
挑戦のはじまり
「はじめまして、プロダクトマネージャーのさらしーです。」
プロダクトマネージャー(PdM)として最初の仕事は、PdMというロールを名乗って挨拶をすることでした。サービスドメインの知識をある程度キャッチアップし、またソフトウェアエンジニアとして内製のアジャイルなプロダクト開発の知見はあるものの、PdMというロールに対して緊張感を持っていました。とはいえ自分のロールを名乗ることはPdMとして重要な仕事です。円滑なコミュニケーションにはまず自分が何者であり、どのような役割を果たすのかを明確に伝える必要があります。
コミュニケーションはPdMの主要な役割のひとつです。正確で緻密な設計図やPRD(Product Requirements Document)を書くことよりも、プロダクトのアウトカムにコミットすることが求められます。そのためには多彩なコミュニケーションパスの構築が必須です。迷ったならコミュニケーション過剰な方を選ぶべきだと様々な場面で言われていますね。そんな中でロールが判然としない人間が考え方だけPdMであっても意味がありません。私はこのチームでプロダクトのアウトカムを向上させ、波乱のないプロダクトマネジメントに寄与するためにここに居るのだというメッセージを発していかなければならないのだと感じました。そして同時に、できるだけ打ち解け易いキャラクター性を意識的に演出する必要もあります。
例えるなら私は、新しい学校に転校して来た異星人のようなものです。エンジニアなら多少異質に見えていたとしても仕事はできますが、PdMはそうはいきません。キャラクター性を明示し瞬時に朗らかなコミュニケーションを構築するという意味では、お笑いは最高の教材です。社内でそのような雑談をしたこともあって、ノンスタイル 石田さんのお笑いの説明を見返していた時もありました。今もそのような振舞がうまくできている自信はまったくないのですが、集団の性質の分布を考えながら外れ値にならないように、平均値の近傍で少し戯けることを意識します。
MutureのPdMとしての関わり方
MutureにおけるPdMの役割は、組織にプロダクトマネジメントの仕組みやノウハウを提供し、伴走しながら支援していくことです。Mutureが全てを巻き取ってしまっては丸井グループの変化に繋がらないため、どんなに不安を感じていてもなんとなく浮いたタスクを拾ってまわるような動き方をすることはできません。また丸井グループの開発チームは基本的にソフトウェア開発を外注していることもあり、エンジニアのバックグラウンドがあってもコードを読むことに逃げることもできません。どちらもアウトプットが出る作業に逃げることを減らし、PdMとして本質的なアウトカムに向き合う職能を会得していく上でとても良い環境だと感じています。
私がMutureに入社したのは創業からおよそ二年目のことで、会社として価値発揮の型が見えつつある時期だったように思います。Mutureの果たす役割については先日のPdM Nightでの弊社兼原の登壇資料等ご覧いただければと思います。また今後とも社外発信していきますので、これからもMutureの発信に関心を持っていただければ幸いです。まだまだ伝え切れない魅力が沢山あるので、乞御期待です。
🎤兼原・PdM Night 登壇レポート
🎧#52 小な現場課題を、組織の構造・システムの課題として捉えよ！〜大企業DXの成果指標の測り方 前編〜
🐤Muture公式X
主要なクライアントである丸井グループは、これまでも物理的なプロダクトについてユーザー中心なプロダクト開発を実践してきた会社です。全社的にソフトウェアの強みであるアジリティ(俊敏さ)を活かしていくためにはまだ課題があるものの、ユーザー中心主義でアジャイルなデジタル・プロダクト開発に向かう強い内的な欲求が存在し、実際にプロジェクトチームでそのような開発が徐々に実現しつつあります。ユーザーとプロダクトチームと企業全体に対して非常に大きな価値を出すことができる仕事だと感じています。Mutureでは現在、アソシエイトおよびミドル・シニアのプロダクトマネージャーを募集していますので、ご興味を持っていただけた際にはカジュアル面談で詳細をお話しいたします。また、Mutureでの仕事については、以下のPdM Daysの登壇レポートが参考になるかと思います。
丸井グループにおいては、お客さまの声を聞きながら、靴の型をとってパンプスはどうしたら痛くならないか？と速いサイクルを回しながら改善していく…と、ものづくりの現場では既にやってきたことだったんです。
スキルの変化と成長
エンジニアから見たプロダクトマネージャーの動き方
Mutureの身近にロールモデルになるPdMがいる環境で、必要な姿勢についてもより実感を持って捉えることができるようになってきました。特に重要だと感じたのが以下の3点です。
文字通り常に、アウトカムから逆算した指針をもっていること。
チームが主体性を持ってアウトカムに向かうために必要十分な関わり方をしていること。
プロダクトに関わる組織全体を俯瞰し、繋げるべきところを意識的に、しかし滑らかに繋げること。
1の「アウトカムから逆算した指針」は、まだまだ一朝一夕ではどうにもならない思考のクセや習慣にしなければならない姿勢で、常に意識して体に覚え込ませなければいけないものだと考えています。やはりPdMは役割である以上にキャリアだということですね。私がエンジニアからEMなど連続的なステップを踏んでPdMになっていたら今以上に「どのように解決するか」に思考が寄ってしまって、苦戦していただろうと思うところです。
2の「チームが主体性を持ってアウトカムに向うための必要十分な関わり方」は伴走型のクライアントワークだからというわけではなく、チームでプロダクト開発をする上での基本的な姿勢です。私は、PdMという仕事はある側面から見るとプロダクトチームから作家性を取り出し整えることなのだと考えています。対してプロダクトチーム全体は作家性の原石を創発的に創造していると言えるのではないでしょうか。プロダクトチームを活性化させ作家性を取り出し整えることによって、プロダクトに独自性と一貫性、信頼を付与することがひとつの重要なアウトカムだと考えています。
3の「組織全体を俯瞰し、部分を繋げること」については、PdMの中でもVPoP(Vice President of Product)やCPO(Chief Product Officer)レベルの仕事かもしれません。2と合わせてこれを実践していく様は、私からすると「達観した善良な人」であるように映りました。不思議な感覚ですが、滑らかに人を繋いでいく時に生じている表層の現象は本当にそんな感じだったのです。
PdMは常に組織とプロダクトの健康な関係のために資する存在です。プロダクトチームではプロダクトの価値に資するというセットアップがあり、困ったことがあればそこに立ち返ってアウトカムを凝視め直すことで方向性が見えてくるかと思います。しかしプロダクトチームを越えて異なるミッションを持った組織と協力し、目線を合わせて活動するためには相手の立場に立つことが必要です。相手の立場で物事を捉えることと、組織全体を俯瞰して物事を捉えることを反復して振り子を揺らすことで、「達観した善良な人」という摩訶不思議な存在かのように見えてくるのだと解釈しました。
「達観した善良な人」ではなく「カフェ店員」になろうと思った
「達観した善良な人」なんてなんだかむずかしいですし、私自身はそれよりもずっと手前のことができていませんでした。実際に相談を受けた際に「もちろんです！」と言ったつもりでいて、傍から見ると表情が暗く既に考え込んでいて、そもそも「もちろんです」と言っていなかったということがあったのです。そこでまず手始めに、オフィスをカフェだと思って「カフェ店員」になることにしました。それが一番演じ易く、身近な話し掛けやすい人だと思ったからです。冗談みたいな話ですが、オフィスに入る時に心の中で「ここからカフェ店員」と言ってから入場しています。
一方で、提供できるものがなければ誰も興味を持ちません。カフェ店員だと思っても給仕の仕事があるわけではないのです。ここでまず大切なことは、今プロダクトチームで話されているトピックについてスタンスを持つことだと考えています。スタンスを持つということは、その判断ができる程度にトピックの関連知識や背景情報にキャッチアップしているということでもあります。PdMという立場上、一時であればチームを迷走させる「それっぽい返答」をすることができてしまいます。もちろん長期的には信頼を失なっていきますし、そのようなPdMの言動によってプロダクトチームはアウトカムから遠のいていきます。アウトカムに繋がらないただの正論を並べているのであれば、それはダメなPdMであるだけでなくダメなチームメイトでもあります。
このような「それっぽいことを言えてしまう」ことに対する恐怖心はMutureで一緒に働く仲間も同様に感じていて、そのような発言をしないよう強く意識しています。
今私が一番恐れているのは「それっぽいことが言えるがために、短期的には役に立てている風に振る舞えてしまう」ことです。
必要だった新しいスキルセット
これまで述べたPdMとして必要な姿勢に加えて、必要と感じた以下4つのスキルについても簡単に書き記しておきます。
① 以前の仕事のアンラーニング
② 論点をMECEに切り出す
③ 一歩踏み出せる範囲を目測する
④ アウトカムから逆算したインプット
職種が変わっているので当たり前に思うかもしれませんが、まず① 以前の仕事のアンラーニングが必須でした。エンジニアとしてのスキルを一度本当に全て手放し、PdMとしての仕事と関連するエンジニアリング以外の要素について学習を主題に据える必要があります。
次に、② 論点をMECEに削り出すというスキルが重要となります。これは議論の切り出し方が無数に存在する中で、議論が進行していく過程で抱えてしまいがちな盲点を避け、後から問題が爆発することを防ぐためのスキルです。手戻りコストが大きくなってから「最初はいいと思ったけど、これ考慮されてなくない？」「ターゲットAは削ってBに集中するって話はしたけど、Zを削るって話はしてないよね？聞いてないよ！」といった状況に陥ることを避けるために、議論の始点がMECEに切り出されていることは議論の起点になりがちなPdMにとって非常に重要です。ただし、当たり前ですがMECEは手段であって目的ではありません。
また、③ 一歩踏み出せる範囲を目測するスキルも求められていると感じました。これはクライアントワークだからこそ強調される側面もあるのかもしれません。特にコミュニケーションのミスは最初は軌道修正するイメージが付きづらく、自分の言動で物事が明後日の方向に動いてはいけないと毒にも薬にもならない言動に収束する引力があると感じていました。これについては機会設定やフィードバック、実際に方向修正をしていただく中で徐々に掴めてくるものなのかなと思います。同時に、もし踏み出した一歩の筋が悪いと感じたら自身で方向性を変える柔軟さも求められます。より多くの試行錯誤が必要だと理解していますが、私としてはまだまだ試投数が足りていないのが実情です。
効率的なインプット、あるいは④ アウトカムから逆算したインプットも重要なスキルとなります。ただ無策にインプットするのではなく、ただデータを集めるのでもなく、サーベイのアウトカムを定義して目的意識を持って探索することで発見的でありながらアウトカムの打点の向上を図ることができます。当然のように感じられるかもしれませんが、広く地続きで知識が広がっている時に適切にスコープを区切るのは、意識しなければ中々難しいと思っています。特に私は興味関心が散漫な方で気が付くと本質から外れて掘り下げてしまうことがあるため、気を付けるようにしています。実際に具体的な課題が浮上した時点でドメイン知識に早急にキャッチアップするべき時により広域の探索をしていたために、周回遅れでインプットを開始する形になってしまったことがありました。なおこの遅れが次節で記述する最大の危機に繋がりました。
成人発達理論によれば、スキルには変動性があり環境と課題に依存して発揮されます。このうち他者の支援によって変動する範囲を発達範囲と呼び、他者による環境の変化や指導によって最適レベルの仕事をする中で環境に左右されづらい機能レベルの能力が発達していきます。この時、私は啐啄同機という概念が重要だと考えています。これは鶏の親が卵の内側から殻を破ろうとする音を聞いて殻を外からつつくことを比喩として、弟子に教えが伝わる最適なタイミングに相互に行動することの重要性を言い表わしたものです。知識によって大きく伸びる最適レベルを自助として引き上げながら、適当な時に機能レベルが発達するようなサポートを受ける機会を作ることが重要なのだと思います。そしてMutureにはそれができる環境があると感じています。
計らずも弊社の執行役員であるひろやさんと同じく啐啄同機をという言葉を使っていることに後から気付きました。一年前の記事になりますが、Mutureの活動についてより詳しく知りたい方はぜひご一読ください。
目隠しをして走り、段差がなくても転ぶ
考えることが仕事じゃない
心臓が締め付けられるような、重くなるような感覚。「あれ、このままだとかなり不味い？」まるで単位が足りないことが判明した大学4年生の如く追い詰められる瞬間が早くも訪れました。
私の最初のミッションはPdMとして仕事を探すことです。組織の構造を理解し、プロダクトのアウトカムのため自身の価値発揮領域を見付け出さなければいけません。そのためにすべきことやステップはメンターとの対話を基に考えています。一方で遠くのアウトカムのみに注目すると具体的な行動が見えにくくなります。それどころか今回は具体的な行動に移った途端に失敗してしまいました。なんということでしょう。アウトカムの迷宮でなにをすれば良いかわからなくなってしまいました…！そんな胃が痛くなるような状況は、いくつかの課題がとある一週間に集中して顕在化することで発生しました。ここでは具体的な事象を挙げることはしません。重要だった要素を紹介します。
第一に、あるタスクについて、プロダクトチームがアウトカムに向うことに寄与しないアウトプットを出してしまいました。作業時間の管理やアウトカムの定義、どこまでも追いかけてコミットメントを果すという意識が欠如した結果、PdMとして適当な活動をすることができていなかったのです。仕事をする上での基本的な計画性が欠けていて、その他の事象と重なることでそれをカバーすることができませんでした。基礎的な能力の部分でアウトカムに繋がる仕事をし損なったため、とても反省していました。
加えて、自分の仕事を探すというミッションをどのように進めていくのかについて、まさに暗中模索で出口が見えなくなっていました。事業ドメインや過去の議事録などのインプットをする傍ら、具体的なタスクについて前述のように失敗してしまいました。どんな仕事をみつけてくるのかわからない、どうみつけてくればよいのかわからない、スタンスを取り切れずにPdMとしてのWhyを見据えた応答ができていない。状況を見て社内で声をかけて頂くこともありましたが、それによって輪をかけてプレッシャーを感じてしまう始末。エンジニアとしては沼に落ちていく障害対応を思い出すようでした。先述のアウトカムから逆算したインプットというのはそのような過程で学んだことです。これらの問題は、アウトカムから逆算する距離を長く取りすぎてしまったことと、自分自身の状況を俯瞰して意識的に行動できていなかった結果だと感じました。
転んだらまず起き上がる
物事が整理される前、私はしっかりとパニックに陥っていました。こういった機会は初めてではありません。ソフトウェアエンジニアとして、泥沼のリリース障害対応をしたこともあります。ベストではありませんでしたが、問題が顕在化した後の一次対応は及第点だったと思っています。何をしたのかというと、
めちゃくちゃ寝ました。
土日中本当に寝る以外のことをしませんでした。途中途中、完全に睡眠している状態ではなく、うつらうつらとしながら入社からその日までの出来事にハイライトを付けていきました。そうすることで客観的に自身がどのような不全を引き起こしているのか、少くとも現象を捉えることができるようになりました。
少し客観視してみて、「うん、そりゃそうなるよね。しゃーない。」となりました。それだけです。私の基本姿勢でもあり、最初から決まっていた答えです。そう思えるまで何が起きたのか連鎖を紐解くことに意味があると考えています。自己責任にしたところで、現実の自分は当時、責任能力がなかったからこうなっているのですから。分析を書き起こすには余白が足りないので、細かい分析は割愛します。
起きたことは起きたことです。私が果せなかった責任に思いを馳せても過去は変わりません。今回はメンターの庇護下でコントロールされた失敗だったので、既に軌道修正されたことは伺っていました。けれど直後のアクションで未来は大きく変わります。反省すべき点がいくつもありました。明らかにこれまでの会話の中で重要だった点を抜き出せていなかったこと。相手の立場に立てていなかったこと。相手の立ち場に立つことから逆算して情報を集めていなかったこと。単純にメンターにぶつける仮説の量の多寡。自分自身が人からの評価に怯えていたこと。そういった本質的な課題が表出したに過ぎないのです。
これを踏まえて、メンターとPeer(役員との連携ライン)、PX(People Experience)の方とそれぞれコミュニケーションを取りました。メンターとPeerに対しては反省点の共有を、PXの方には万が一パニックが持続する場合を想定して予防的に「今パニックです」という連携をしました。それぞれ日頃からすぐに相談できる距離感にいたことで本当に助かりました。ところで上記では単純に責任と言っていますが、責任には以下のような3種類あります。
遂行責任(Responsibility): ものごとを実行する責任。この場合アウトカムに向かうためのアウトプットを出すこと。
説明責任(Accountability): ステークホルダーに対して説明をする責任。今回はメンターに対する振り返りの説明。
賠償責任(Liability): 損失を補填する責任。
今回は遂行責任を巻き取られ、内部的には説明責任を果たし、賠償責任は発生しませんでした。
学びはあったのか
大変初歩的でお恥しいのですが、内部的な説明責任を果たしメンターからのフィードバックを頂くなかで得た学びは次のようなものでした。
まず期日のあるタスクが来た時点で動ける時間を棚卸しと、ヘルプお願いするライン設定をしなければいけませんでした。加えてPdMとしては、話の流れではなく常に会社のパーパスと事業戦略を引っ張り出してくる役割でなければなりません。そしてそのために、アウトカムから逆算したアウトプットのあるべき姿を自分の手元に持っておかなければならなかったのです。
また、期日を絶対のものとして早々に諦める姿勢はアウトカムに基いていませんでした。今回のタスクの提出期限は比較的延期し易いものでしたし、資料として完成できなくとも直接会いに行って軌道修正をするなどアウトカムに向かう方法はいくつもあったのです。実際にメンターは臨時出社で問題を修正しました。この件では、仕事をする上での基本的なところ、PdMとしての姿勢など複合的な遠因がありました。一言で言うならばPdMとしての遂行責任を果たすことができなかったということだったのだと理解しています。
目的地を振り返る
プロダクトマネージャーという仕事を再認識する
ブックスマートと言うほどスマートではないのですが、ここまでで私は不完全な理屈ばかりで現実が見えてない頭でっかちな人間であると再度痛感しました。以下にここまでで学んだ姿勢とスキルを再掲します。
PdMとしての姿勢
1. 文字通り常に、アウトカムから逆算した指針をもっていること。
2. チームが主体性を持ってアウトカムに向うために必要十分な関わり方をしていること。
3.プロダクトに関わる組織全体を俯瞰し、繋げるべきところを意識的に、しかし滑らかに繋げること。
PdMに転身する上で必要だと感じたスキル
① 以前の仕事のアンラーニング
② 論点をMECEに切り出す
③ 一歩踏み出せる範囲を目測する
④ アウトカムから逆算したインプット
これらを自然に遂行することが、私がPdMとして機能していくために必要な基準点なのだと思います。PdMの仕事には大きなレバレッジがかかります。アウトカムに繋がらない些事に1スプリント消費するようなガイドを引けば、その分だけアウトカムは遅れ、プロダクトチームの士気が下がります。私が果たせるPdMとしての遂行責任を徐々に大きくしていくことが、PdMとして今後向き合わなければならない使命なのだと考えています。
私の意思
私個人が人生を通して向き合っていきたいことが二つあります。
ひとつは、人・金・物・事の均衡と相乗を目指し、摩擦の少ない滑らかなプロダクト体験を実現すること。もうひとつは、世界に、より作家性の色濃いプロダクトを増やすことです。
クラフトから組織レベルのエンジニアリングになる過程で作家が組織化されることで発生した限定合理性による不全と、衰退した作家性を、プロダクトマネジメントというアプローチで組織レベルで再獲得していきたいです。この目的地を今後とも忘れず、時おり振り返りたいと思います。
目的地を振り返ると言うと、なんだか矛盾した一文に思えます。直感的には目的地は前にあるもので、後ろを振り向いて見付かるものではないでしょう。けれど私は、目的地は遠ければ遠いほど今の行動の先には存在しないものだと思っています。気付いた時には背後に回っていることも、それに気付かずに遠ざかることも、登る山の全貌を確認するためにあえて遠ざかることもあるでしょう。
Mutureは「相利共生の未来を実現する」会社です。それぞれの個性や事情の衝突や不均衡を乗り込えて、互いが互いにとって利益となり共に生きる関係性を目指します。Mutureとクライアントや社会との関係性もそれを目指しますし、私自身とMutureの関係性もそれを目指しているのだと様々なコミュニケーションの中で感じています。これからMutureで、時おりこの目的地を振り返りながら相利共生の未来を目指して尽力していきたいと思います。
おわりに
そんなこんなで楽しい3ヶ月を過しました。
読み返してみると壮大に何かが動いているようで何も動いていない大変よくできた作文です。作文のモメンタムをちゃんと仕事にぶつけていくぞ💪
個人的にチューニングできてないと思うことが沢山あるけど、今ここで起こっていることはめちゃくちゃ楽しいです。Mutureが2年間で実現してきたアウトカムが結実しつつある様を、外から突然飛び込んで体感させていただいていることに罪悪感さえ覚えます。
Mutureがこれまで2年間で築き上げたものの上に、複利を効かせたアウトカムを作るためにいち早く実力を伴わせたいと思います。
ぴーす✌️
Mutureは共に働く仲間を探しています！
一緒にMutureの組織作り、組織支援に取り組んでいただけるメンバーも絶賛募集中です。特にPdMや、これから共に成長していくアソシエイトPdMの採用に注力しています。ぜひご連絡ください！
✍️この記事を書いた人：さらしー／Product Manager
Ｘ ＠MutureCorp
📕 note
🏠 muture.jp
🎧 Podcast
この記事が気に入ったらサポートをしてみませんか？