2023-02-21

プロダクトマネージャーをやり続けて見えてきた、やりたいことの本質

キャリア

自己分析です。いくつかの事業やプロダクト、そしていくつかのチームでPdMをやって、見えてきたこと。

将来的になりたい姿

課題解決方の人材としてスペシャリストになりたい

プロダクトの開発工程を最適化すること
ふわっとした「こうしたい」を具体化するプロセス
考慮事項や変数が多い課題の最適解を見出すこと

に非常に強い関心と積極性がある。

本業や複業の取り組みで経験を積んでいたり、日頃から情報収集をしていたりする。

モチベーション

プロダクトがユーザーに(最大化された)価値を迅速に届けられる状態を作りたい
困難な課題を解決したい

複雑な要因が絡み合う課題を解決するときに、なるべく多くの関係者が利益を得られるようにすることへのモチベーションが高い（パズル的な感じ, 一石N鳥）

特に課題に感じやすく、解決したい気持ちが大きくなること

チーム速度感を阻害する事象
チームに納得できていないメンバーがいる状態でリリースをすること
チームの状況が整理されていないこと

2023-02-21

リモートコラボレートにおけるCode of Contact(行動規範)とRules of Engagement(交戦規定)の規定

チームで働く上でCode of ContactとRules of Engagementを作ると良いという話を職場で聞いたので、内容をざっくりまとめつつ自分だったらどうするかを記す。

Code of ContactとRules of Engagementとは

Code of Contact(CoC)は行動規範、Rules of Engagement(RoE)は交戦規定である。元の使われ方から転じて、チームで協調作業をする際に、前者は基礎におくべき根本的に大事な原則をまとめたもの、後者は部内でのメンバーの責任範囲を段階評価し文章化したものだ。

個人がCoC, RoEを発する意味

CoC(行動規範)

CoCは仕事を一緒に進めていくメンバーとの間で、心理的安全性を高く保つためのガードレールみたいなものだと思う。多分対面だとこういうのは自然と構築され把握されていくものだが、リモートは情報が落ちるのでむずかしい。これらを決めることで、以下の目的が達成されると考えている。

言動や行動が意図しない読み取られ方をするを防ぐ
実はしてもいいことを遠慮する/されてることを防ぐ

結果として、言動や行動のストレスが減って良いであろう。

RoE(交戦規定)

RoEは上下・水平両方向で責任分担をするときに強く働く。何をどの段階まで誰が責任を持つか（やって良いか）を明確にする。やり方としてデリゲーションポーカーが有名である。やってもらう想定をして思ったのにやらなかった、やるべきだったことをやれなかったと言ったすれ違いを減らせる。

自分のCoCを考えてみる

ここでは考えやすいように、手段のレイヤーまで落とし込んで考える。

通話・対面コミュニケーションを重視します

必要に応じて音声通話を使います。テキストで決めたいことの前提情報含めて伝達するのは大変で、話したほうが早い場合があります。短時間で多数のコミュニケーションをとって毎回滞りをとり、歪みを溜め込まないようにします。また高度な共通認識の構築やディスカッションを要する場面(特に発散系)では、非言語情報の重要性が増すので対面でのコミュニケーションも必要だと考えています。

効率を重視し簡潔を目指し無駄を排除します

無駄を嫌いそれを潰すところからプログラマー生活は始まりました。また対象がなんであれ簡潔であればあるほど、扱うのが楽です。より本質的なところにリソースを割くために、無駄をなるべく無くし、効率を上げるための仕組みを作り、複雑なものは簡単に扱えるようにします。

雑に発言します

まず雑に発言することがしないことより大事だと思っています。経験や感覚からくることはその場で最も脳に浮かび上がり、言わないと忘れます。また一度発言してもその後様々な可能性に思考を広げるため、発言したことは変わることがあります。一方しっかり考慮を重ね結論を出したことは(文章化して)誤解のないように伝えます。議論の時は批判的検証・アイデアの発散をし発言します。

Done is better than perfect.+ agilityの精神で行動します

最初から完璧を目指して成果物をそと（評価者）に出さないよりは、短い期間でとりあえず出して改善を後から重ねていく方を好みます。

当事者全員が快い状態であることを重視します

合意、納得、大事。チーム全体が持続的かつ有機的に価値を生産できるために重要だと考えています。

自分のRoEを考えてみる

RoEは所属組織や人間関係によって変わるためここでは示すことができない。実例で言うと、スタートアップで業務委託メンバーと仕事をした時にコード品質面の責務を移譲したり、学生時代からいる複業先で自分がほぼ全て知ってる人（単一障害点）になってしまっている環境で、後輩に対しやらないことを明示したりして、創業＋PdMでありがちな「何でも屋」「単一障害点」となることを避け、一点特化型の人材に責任範囲を明示し特定領域を深掘りしてもらうなどの適切なデリゲーションを心がけている。

と、こんな感じだろうか。特にCoCは日々働いていく中で見出されるものだろうし、より洗練させチームを組むメンバーが自分とやりやすいようにしていきたい。

2023-01-18

アプリ事業のスタートアップ創業メンバーとしてやったことと感想 #EM #PdM

キャリア

こういう記事は年末に出すのがいいのかもしれないが、だらだら書いてたら新年になってしまった。

2022年の活動として一番大きかったのは、個人の活動としてスタートアップの創業を手伝ったことだ。自分が手伝ったのはエンジニアリング周りとプロダクトマネジメント周りの大体全部。

オファーいただいた時点で事業規模からフルタイムでのコミットは不要とのことで、副業でこの仕事をしていた。

ざっくり出来たことと感想

一つのアプリを文字通り0から作り上げてリリース、ユーザーを集めることに成功した。またエンジニア組織を1人（自分だけ）の状態から立ち上げ、経営方針からフルタイムではない業務委託のエンジニアオンリーという限られたリソース下で、パズルのような配置をやって、二週に一度はアップデートのリリースを出せる運用をやっていた。

もともと可処分時間をプロダクトマネジメントのことを勉強したり考えたり、課題解決のためのアイデアを練ったりするのに使ってしまうくらい好きなことであるため、非常に楽しい仕事だった。経営側があまりエンジニアリングの事情に詳しくなかったため、エンジニアリングが絡むことをほぼ任されたり、エンジニアリングの事情を分かりやすく伝えたりし、エンジニアとしてのバックグランドも存分に活かせた仕事だった。

一方で、全員の勤務時間が不定なことによるコミュニケーションの難しさ＋スタートアップ特有の特大不確実性との立ち向かい＋経営側と開発チーム側の板挟みになる、といったことで苦悩する時も多かった。（がまあこれをなんとかするがPdMの仕事なのでやりがいは非常に感じてた）

この記事ではどんなことをしてたか、書いていきたい。

そのときの選択にはベストを尽くしたつもりで、うまくいったものもあれば、微妙だったのもある。ここでは一つひとつについては結果を考察しない。（別途振り返り記事は書くかも）

あと到底1年でやったことを書き切ることなど出来ないので、サマリ的な感じで書いてます。

事業

toCコミュニケーションアプリの制作と運営

加入タイミング

CEO, COOが競合分析やペルソナ作りを終えて作るサービスの方針が確定し、エンジニアとエンジニアを動かしてプロダクトを作れる人を探していたタイミング。エンジニアは業務委託で数名決まってる人がいた。

やったこと

組織作り

組織文化の醸成

組織文化の情勢は最初がだいじだと思ってたので、特に初期は頑張っていた。情報の透明性の高い組織づくりを目指し、当初LINEでやりとりしてた経営メンバーに対してもSlackでの情報交換やNotionの利用を呼びかけた。

エンジニアに対しては特にリリース前の初期はここどうしますか？系の話が非常に多く、決まらないと先に進めないことが多かったので、気軽にエンジニア同士、またPOに対し質問できる空気作りを心がけた。加えて質問しやすいようなコミュニケーション(MTG)設計も心がけた。

（MTG終わりに、何か1週間限りのこの場所で言っておきたいこと、聞いておきたいこと、あればお願いします（10秒待つ） + MTG終わって解散になった後MTG部屋に10分くらい残るので、なんでも話しかけてくださいなど...）

▲SSoTの原則に則ったドキュメンテーション文化を作っていった

エンジニアリング周り

技術選定

業務委託のメンバーと相談しつつ最終的な決定は自分がやった。

クライアント

CEO, COOが採用したエンジニアがFlutterエンジニアだったため(本来逆)、またAndroid, iOSアプリを同時に迅速に提供したいという理由から、Flutterを採用。Flutter, riverpodを使ったクリーンアーキテクチャでの実装、またmockitoを使ったテスト実装をやっていった。

バックエンド

業務委託のSREメンバーと相談しながら、Cloud SQL, Cloud Run, Cloud Storage, Cloud Functions, Firestoreなどを使った構成を決めていった。Firestoreはアプリ内のチャットサービスに使い、クライアントのSDKから直接APIを叩く方式で実装していった。

チーム運用

Slack, Notion, ClickUp, Google Workspaceを採用し使い方をチームに広めた。2022年後半はNotionの機能が拡充されていったのとスクラム運用を廃止したため、タスク管理をClickUpからNotionに移行した。

費用管理

資金が非常に限られていたため、特にGCPでは利用頻度やアクセス数を考慮した、Cloud Runでのminimum instance数の設定、開発環境のアーキテクチャ変更などのチューニングを行った。

エンジニア採用

応募者と面接して採否を決定。とはいえ業務委託の採用だったので、スキル面と条件面の確認が主だった。

エンジニア配置

エンジニア全員と技術スタックに加え思想的な部分（こうであってほしいこうしたいこういうのが気持ち悪い）などを定期的にヒアリングし、各々のエンジニアが最大バリューを発揮できる、かつエンジニアチームが円滑に回るようなアサインをした。

プロダクトマネージャー的なこと

エンジニアチーム運用（タスク運用、コミュニケーション設計など）

スクラム開発を導入。チームの特性にあったカスタマイズを加え、回していった。自分がPOをやってユーザーストーリーを作ってメンバーに説明をしていた。2022年後半はスクラム運用を廃止し、タスクには明確な期限設定＋アジャイルのための振り返りをやる運用にした。というのも、業務時間が不定（月の目安労働時間と成果目標だけ設定してあってあとは自由）の業務委託エンジニアに対し、スプリントを回す方式がタスクを遂行してもらうことに対し合わなかった。しかしスタートアップゆえ未熟の組織で定期的に開発チームで振り返りをすること、またエンジニア同士で同時に勤務時間を過ごすことがあまりないので振り返り会が貴重で興味深い雑談機会となること、それがエンジニア同士で課題を解決しなければならない時のコミュニケーションの壁を薄くすること、これらは重要視していたためスクラムをやめても定期的な振り返りMTGは残した。

コードオーナーの任命（デリゲーション）

物事を円滑に素早く進めていくことがスタートアップでは非常に大事である。初期、文法や記法、アーキテクチャ、諸々で議論が煮詰まり本質的なコーディングとそのデプロイが滞ることがあった。そこで、コードオーナーというロールを作り任命した。コードオーナーにはコミッター間での意見や知識を統合し、最終的にコーディング規約を規定してもらう役割、コードレビューで悩んだ時に最終的に判断する役割、コード品質を担保する役割をつけた。これによって、

エンジニアリングに親しくない経営メンバーとのコミュニケーション

他のサービスがやっている一見簡単そうに見えることも、エンジニアリング的観点から見ると非常に大変なことが多々ある。これを理解してもらえるまで説明する、現実世界のわかりやすい事象に例えて説明するなど、いろいろ心がけていた。

サービス設計

toCアプリのスタートアップで大切なのは、仮説検証を短いサイクルで行い資金を使い切る前に収益構造を生み出すことである。4月初頭のファーストリリースまでは、自分が加入する前からあって投資家のGoももらってるアイデアをそのまま実現するのが仕事だったが、それ以降はリリース後のユーザーの反応を見て新しい機能を考え仕様を決めエンジニアを動かす仕事に徹することになった。

アイデアの発散と収束を繰り返し、さまざまなユーザーに影響を与えるファクターを考慮、またユーザ数と収益をプラスのフィードバックに持っていくこと、現在会社が持ってるリソースで実現可能なこと、など諸々を考慮して、次につけるべき機能を割り出していった。

またPMF(Product Marketing Fit)するために、考案した新機能がついた後のアプリに対し、SWOT分析等の各種戦略的分析手法を適用していった。