PMとして仕様を考える時のTips
新機能の仕様作成はPMが担当するでしょう。しかし、仕様を作成する時の気をつける部分を新人メンバーに教えるのがなかなか難しいです。 そのため、今回仕様検討時に意識すべきことを言語化してみます。
※具体的な内部仕様や設計はエンジニアの仕事なので、今回の記事ではスコープ外とします
- ファクトベースで、インサイトを洞察する
- 仕様書が機能の共通認識になる
- 将来のメンバーが見ることを念頭におこう
- 実現可能性を検証する
- 最小機能でv1をリリースする
- アップデートや他の新機能とのコンフリクトを意識する
- まとめ
ファクトベースで、インサイトを洞察する
プロダクトの仕様を考えるときに、解釈と事実を分けて考えることが基本となります。 解釈で物事を考えると、自分とユーザーの意見に乖離が生じてしまうでしょう。 あくまでユーザーはこう考えているという事実（課題）ベースでユーザーを考えることで、仕様がユーザーの課題に沿った良いものになると思います。
ここで注意しなければいけないのは、ユーザーの声を真に受けてはいけないということです。 ユーザーは自分の考えられる範囲でしか要望を上げられないし、そもそも何が問題なのかユーザー自身ではわかっていないことが多いです。 従って、「ユーザーの要望を生み出している根本の課題はなんだろう？」と洞察してみて下さい。
洞察のコツは以下の記事に詳しく記載してるので、参考にしてみて下さい。
仕様書が機能の共通認識になる
前提として、PM、PMM、エンジニア、デザイナー、QAなど立場や役割が違うステークホルダーがプロダクトに関わっているでしょう。プロダクトを考えてコミュニケーションする際、その共通認識として仕様書を介してやり取りが発生することを念頭において仕様書を書くべきです。
組織によっても異なりますが、仕様書を読み得る人によって情報の粒度を調整することが必要だと思います。
将来のメンバーが見ることを念頭におこう
将来のメンバーは、当然ながら現在の文脈（コンテキスト）は理解しておらず、仕様書からどうしてこの仕様になったのか推測し、読み取ろうとするでしょう。この時間の経過と将来を意識して、仕様書を書くべきです。
現在のメンバーが理解できない仕様はもってのほかで、「どうしてこの仕様になったか」という部分を言語化して仕様検討しないと、将来のメンバーはより理解できないでしょう。
従って、文脈を確認してない将来のメンバーが見ることを念頭に、全てに理由付けして深く思考したうえで仕様を作成してみることをお勧めします。
実現可能性を検証する
当然ながら、実現できない仕様は意味がないです。（完全に意味がないわけではないが、プロダクトに反映させれるかどうかという点では意味はない） なので、仕様を検討する過程で、「そもそも技術的に実現可能なのか」、「コストがかかりすぎて実質不可能ではないか」を意識して仕様を考えましょう。エンジニアとの連携が重要です。
最小機能でv1をリリースする
新機能だったり、プロダクトのfirst releaseだったり、リリースする時に小さくリリースする方が良い場合が多いです。 機能が多すぎると本当に必要な機能がユーザーに伝わらないかもしれないし、開発コストとメンテコストが高くなります。
機能を絞って最小機能でユーザーに提供することでフィードバックも得られるので、検証のサイクルもより早く回せます。プロダクトをグロースしていくという観点では、最小機能でv1をリリースする方が良いでしょう。
アップデートや他の新機能とのコンフリクトを意識する
仕様を検討するときは該当機能に目線がいってしまうが、アップデートしたり他の機能との住み分けを意識する必要があります。 「この機能があるから他の機能が開発できない」「この機能の仕様、アップデートしづらい」といった問題になると、後から改修が必要になり、開発コスト、しいてはユーザーの認知負荷が高くなってしまいます。
現状で考えられ得るアップデートや新機能が搭載された際、「これは邪魔しない機能かどうか」といった点を意識して検討することで、プロダクトの今後のグロースに対して許容度の高い仕様になるでしょう。
まとめ
仕様作成するときのTipsを記載してみました。 色々あるが、組織やプロダクトによって意識すべきポイントは異なるが、ぜひ参考にしてみて下さいmm
【PMのソフトスキル】問題解決能力について
今日も今日とてPMとして働いていると問題解決能力が大事だと実感します。
今回は問題解決に必要な考え方を言語化していきます。
PMとして働いている人だけでなく、他の職種にも応用できると思いますmm
問題解決するとは
筆者は、問題解決とは以下のプロセスであると考えています。
- 理想（目的）を設定する。
- 現状を確認する。
- 理想と現状のギャップを確認する。
- ギャップを埋めるための越えるべきハードル（問題）を定義する。
- 問題を解決するための手段を考える。
- 手段から実際のタスクを洗い出す。
- 実際に実行する手段を選ぶ。
- 手段（タスク）を実行する。
- 最初に設定した理想状態になったか振り返りをする。
理想（目的）を設定する
まず初めに、どのような状態になったら問題が解決されたと言えるのかを定義することから始まります。日本語は主語が省略されやすいので主語を含めて「誰に何と言って欲しいか」を言語化しましょう。
つめの甘い理想の設定だと、それ以降の問題定義やネクストアクションの方向も大きくずれてしまいます。理想の設定は慎重に行うことをおすすめ致します。
現状を確認する
理想を設定した後は、現状を確認しましょう。 ここでは解釈(バイアス)を入れないように注意して、事実のみを羅列して下さい。
理想と現状のギャップを確認する
理想と現実のギャップを確認します。事実として確認することが大切で、解釈が入ると取るべきアクションを間違える可能性があるので、注意して下さい。
ギャップを埋めるための越えるべきハードル（問題）を定義する。
理想と現実の差分を生み出す原因を定義しましょう。これが理想に近づくために解くべき課題となります。ここで定義した問題はあくまで仮説であり、複雑な事象であればあるほど、元々問題がはっきりわかることなどなく、なにが問題なのか曖昧な場合も多いです。
どのように目の前の事象を洞察するかについては、後述致します。
問題を解決するための手段を考える。
ここでは仮説である問題に対しての具体的なアクションを羅列いたします。実現可能性や懸念点など気にせずとにかく発想してみて下さい。
大事なのは、問題に対する解決策であればなんでも良いという点です。問題さえ解決できれば理想に近づけるので、慣習なども取っ払って考えることが思わぬ最適解につながるかもしれないです。
手段から実際のタスクを洗い出す。
出てきた手段のタスクを洗い出します。これをすることで、実際の作業のイメージを確認できて、懸念点や、やっぱり他の選択肢の方が良いといったことが出てくるでしょう。
実際に実行する手段を選ぶ。
手段を選定します。基本的に特定の観点での良い悪いになると思うので、筆者は譲れない観点を３つ程度にしぼり、観点別に松竹梅に分けて順位をつけています。比較しやすいように、なるべく言語化や表にすることをおすすめ致します。
手段（タスク）を実行する。
実行する際も、理想と現実、問題の構造を抑えて目の前の作業を行います。もし理想からずれていれば、すぐに修正が必要です。
最初に設定した理想状態になったか振り返りをする。
アクションし終わった後、理想の状態になったかを、定性と定量の両方で確認しましょう。定性のみに結果がある場合は、人には貢献したが事業に貢献してない可能性があります。定量のみに結果がある場合は、事業に貢献したが実際にその効果を人が認識していない可能性があります。
問題解決で意識するポイント
問題や理想を定義する作業は正解がなく、どうすれば良いのかわからない時も多いでしょう。そこで、物事を洞察する上で意識すべきポイントを記載します。
構成要素を洗い出す
物事の構成要素を洗い出すと良いと思います。いわゆる因数分解です。 これをすることで、ボトルネックのスコープを推察しやすくなります。
図にしてみる
図にしてみましょう。それぞれの構成要素やキーワードの関係性が推察できます。また、モノの見方を意識して変えることができたりします。
言語化する
対象を言葉にしてみましょう。言語化することで自分の頭から離れて自分の考えを客観視できます。また、他者に伝えたり、他者の意見を伺うためには言語化は必要不可欠です。
過去と未来で一貫性があるか確認する
時間は物事を見る上で重要な観点です。 過去から現状は生まれてるし、現状からアクションを起こすことで未来である理想を実現することができます。
一貫した流れであるので、何か突飛なことをしてないか確認してみるといいかもしれません。もちろん一貫すれば良いということではないが、過去があって今が成り立っている、そして未来は今の積み重ねという視点からみて違和感がないかは確認すべきだと思います。
依存関係を整理する
ここの手段や問題に依存関係が存在する場合があります。AをやらないとBができない、Cに含まれたD、EさんとFなど、時間や集合、人間関係などの依存関係は往々にしてあります。依存関係がある場合はそれを想定して考える必要があるでしょう。
ここで大事なのは依存関係を無理矢理引き剥がそうとしないことです。依存関係は多くの場合簡単に動かせない、いわば定数である可能性が高く、そこにリソースを投下しないように気をつける必要があります。
リソースに対して動きやすい変数が高コスパなので、見極めて選択と集中をした方が良いでしょう。
最後に
今回、問題解決能力についてまとめてみました。これに限らないと思いますが、とはいえ意識するポイントを事前に言語化して頭の片隅に入れておくと良いでしょう。
【PMのソフトスキル】 コミュニケーション能力について
PMとして働いていると、コミュニケーション能力が大事だと痛感する機会が多いと思います。 また、そのコミュニケーション能力が一体なんなのか、他人に説明するのも難しいと感じます。
今回は、その抽象的なコミュニケーション能力について、自分なりの定義と意識しているポイントについて説明致します。
学生と仕事上でのコミュニケーション能力の違い
学生の時からコミュニケーション能力は高い方がいいと言われてきたと思います。 おそらく友達同士の会話でも、「あいつはコミュ力が高いからさ〜」みたいな会話があったでしょう。（筆者はあった） しかし、明確に学生のコミュ力と仕事上でのコミュニケーション能力は違います。
学生の時はコミュニケーションを通じて、仲良くなれるか、親睦を深められるかどうかが大事です。 見ず知らずの人に話しかけることができて、ユーモアを交えて「この人と楽しい、面白い時間を過ごせそう」と相手に感じてもらえるコミュニケーションができることがコミュニケーション能力がある人とみなされるでしょう。 いわゆる陽キャと言われるパーソナリティを持っている人です。
一方仕事では、信頼と納得感を得られることが大切であり、見ず知らずの人に話しかけることは必ずしも必要ではありません。 コミュニケーションを通して、自分に対して信頼を、主張に対して納得感を感じてもらえるコミュニケーションが求められます。 したがって、面白いと感じてもらっても、信頼や納得感が欠けていたら意味がないと言えます。
チームとして信頼と納得感を得られるコミュニケーションが、仕事において大事であり、これを踏まえて普段意識すべきことを記述します。
コミュニケーションで意識すること
まず前提として、コミュニケーションで意識するべきことは、人や属している組織によって異なるし、正解はないことです。 しかし、根幹となるものを言語化することで、応用が効くと考えてます。なので、以下のポイントを意識して、ご自身の状況に応用して下さい。
信頼している姿勢を行動で示す
まずはじめに自分から相手を100%信頼しましょう。関係性が築き上げれてない状態で信頼するのは難しいかもしれないです。 しかし、giveの精神が良い関係性にとって最重要です。信頼してほしいと思うのであれば、自分から信頼しよう。
ここで注意したいのは、「信頼している」と口だけにならないことです。行動で示しましょう。 例えば、目的と背景を伝えて具体的な手段の発想を求めたり、実際のタスクの実行自体を任せたりすることだ。タスクの実行や的確な意見を言ってくれるという信頼がないと、Howの部分をこちらから明示して押し付けがちです。 「このやり方でやってください」「この意見でいきます」こういった言葉は相手の意見をシャットアウトするもので、相手の能力に委ねた議論は期待できないでしょう。 もちろん、状況に応じて具体的なHowの部分を提案する必要はあるが、必要性がないのにも関わらず、全部押し付けてしまう時があるかもしれません。これは知らず知らず相手の当事者意識を削いでしまう可能性があります。
相手が自分の言いなりに動くようなコミュニケーションは長期的な信頼と納得につながりません。相手の意見をしっかりと聞いて、お互いでコミュニケーションを創造することをお勧め致します。
自分が持っている情報とチームメイトが持っている情報の差分を限りなく0にする
知らないところで話が進んでいて、自分に関係する意思決定されることをよく思わない人は多いでしょう。 決定的な情報だと、タスクにも影響が出るかもしれません。
そのため、プロジェクトの情報でクリティカルなものは逐次共有、ほぼ全てのチャットにCCを付与、悩んでいることや計画を逐次ドキュメント化して、「知ろうと思えば全てを知れる」状態にします。 これにより、各メンバーがプロジェクト全体を見渡して個人のタスクを見つめることができます。「今なぜこのタスクをやっているかの納得感」と「説明するコストを削減し、言いたいことをスリムに言えるようにすること」を目的としています。
また、筆者は本格的な議論の際、その時に初めて出す情報や参加者の中に知らない人がいる情報の扱いは注意しています。テキトーに伝えると、当人の疎外感を生む可能性があり、チームとしての連携力を低下させてしまうかもしれません。 なるべく、今まで伝えてなかった意図やクローズドで議論されていた背景を共有するようにしています。
ドキュメントなどの非同期コミュニケーションでも注意が必要です。論理的にわかりやすく記載することはもちろん、最新の情報に更新されていることも重要でしょう。例えば、最新のイベントを反映させたバックログはこれから取り組む開発者を安心させます。また、進捗や状況が記載された報告書は上司を安心させます。
情報や意見、それに基づいたドキュメントのボールを常にチーム全体が持っている状態が理想です。自分含め当人にボールが停滞していると、認識のズレや不安感を生む原因になりかねません。
相手の処理のステップに沿った情報の出し方、言葉の選び方をする
コミュニケーションで情報を発するということは、当然、情報を受け取る側も存在するということです。 したがって、何かを伝えたい際は、受け取る側を想定したコミュニケーションが求められます。
筆者は、特に議論で扱っている範囲と情報の順番を意識する必要があると考えてます。
ミーティングなどの同期コミュニケーションの場合、枕詞の付与と相手が漏斗のように情報を処理することを意識してして、「〜について」「〜の観点でいうと」「〜の話ですが」という枕詞をつけて、今何を話しているのかを冒頭に宣言します。これにより、論点のズレを回避することを心がけてます。 そして、1文で漏斗のように範囲を徐々に絞るようにして言いたいことを伝えます。 例えば、「Aというプロジェクトについてですが、材料に関してBが予算オーバーするということがわかりました。」と言った感じです。「Aというプロジェクト」→「材料に関して」→「Bが予算オーバー」といったように、上位概念を先に出してから詳細を出すといった流れです。 先に詳細から出すと、もしかしたら人によっては、Aというプロジェクトの話かわからないでしょう。相手の情報処理の方法をベースとしたコミュニケーションが大事です。
一方、チャットなどの非同期コミュニケーションでは、非同期で見られることを意識しましょう。 チャットツールだとメンションすると、通知が飛ぶものが多いです。そうすると、まず通知のプレビューがやりとりのファーストコンタクトであり、その後普段使っているチャットツールの通知チェック欄で詳細を確認するでしょう。 受け取った側は連絡に対して、すぐに返すべきか、そうでないかを考える必要があると思います。そのため、通知のプレビューに収まる部分で先に要約を書いておくと、連絡に対するアクションを通知段階で決定させることができるでしょう。 これは、コミュニケーションコストを削減して、認識の相違を減らす工夫です。非同期である以上、コミュニケーションの受け取るシーンを細かく想定し、言いたいことや要約を先に書いておくことで、風化しないチャットやドキュメントを作成できると思います。（結論ファーストは大事だが、背景を理解して使うことが大切だと考えてます。どんなコミュニケーションも万能ではないから。。）
間違った情報、そして、理解に時間がかかるコミュニケーションはなるべく避けて仕事しましょう。
意見の差を観点の差と捉える
議論をしていると意見や提案の相違があります。この時に「あの意見が良い」「この意見はダメ」というように、良い悪いで判断しがちですが、これを観点の差と捉えるべきです。
仕事上絶対にどんな状況でも良いことなど存在しないし、逆も然りでどんな状況でも絶対にダメということはそうそうないでしょう。あくまで、良い悪いということは与えられた状況や文脈に決定される主観的なものです。 したがって、良いというのは「特定の見方や観点において良い」ということであり、悪いというのは「特定の見方や観点において悪い」ということです。大事なのは、背景となるモノの見方を洞察して、そこを批判的に捉えることだと思います。大元に対して意見をすることで、本質的な議論を生むことができ、議論がズレにくくなるでしょう。
上記を踏まえると、議論の結論は特定の観点を優遇するということになるかもしれないです。 全体の納得感を大事にするためには、なぜその結論になるのか合理的な理由をしっかり言語化し、全体に正しく周知しましょう。
相手の時間を奪っている意識を持つこと
ミーティングだったり、チャットにせよ、コミュニケーションにおいて相手の可処分時間を奪っている意識を持つ方が良いです。 相手も人間なので、忙しい中何を言いたいのかわからない連絡が来るといい気分ではないと思います。
結論を先に書いたり、いつまでに返信して欲しいのか期日を書いたり、ミーティング前にサマリーを共有したり、工夫1つで相手が使用する時間を最小にすることができます。 文字だけでなく、画像や図を使うのもいいかもしれないです。
まとめ
今回、チームメンバーから、コミュニケーションで気をつけていることがあるかと聞かれたことがきっかけでこの記事を書いてみました！ 自分もまだまだだが、明日から実践できる内容だと思うので、皆さんも試してみてほしいです。
プロダクトマネージャーになって半年経った
概要
プロダクトマネージャーになってから半年が経ちました。自分にとってプロダクトマネージャーは本当に面白く、向いている仕事だなと実感しています。一人立ちから半年も経つと色々できることも増え、全体概要も把握できたかなと感じていますので、半年なりの学びを共有したいと思います。
この記事では、PMの概略とそれに必要なスキルなどについて触れています。まだまだ経験の浅い自分ですが、半年前に知りたかったことをメインに書かせていただきます。なお現場によって異なる部分も多いので、個人の体験、意見として捉えていただけると幸いです。
プロダクトマネージャーとしての仕事について
それでは具体的に「プロダクトマネージャーとは」という部分に触れていきましょう。
プロダクトの方向性
PMの仕事はざっくり言うと「プロダクトの方向性を決め、その実現に対してコミットする」です。もちろん現場によって微妙な違いはあると思いますが、大枠はどこも同じでしょう。
プロダクトの方向性を決めるということはすなわち、プロダクトがどういった目的で存在するのか、誰にどんな価値をどのように提供するのか、といった部分を決めることになります。この大元をしっかり言語化することで全ての施策や行動の判断基準となり、自分たちの向かうべき場所を明確にしてくれます。この部分が弱いと各ステークホルダーがそれぞれの立場で良いと思ったもの、またその時々で良いと思ったものがプロダクトに反映され、ユーザーはプロダクトが迷走しているように感じ、いつしか離反するでしょう。プロダクトの方向性を言語化しチームと関係者に浸透させることは、いいユーザー体験を届けるための基礎になります。
自分が担当しているプロダクトではOKRを定めました。プロダクトの存在意義としてのOとそこをモニタリングする指標のKRを設定し、各活動を検証できるようにしました。OKRじゃなくても良いのですが、プロダクトの方向性とそこに近づいているのか定量的に観測する仕組みはチームに作る必要があります。
「プロダクトの方向性を決め、その実現に対してコミットする」
先ほどこのように述べました。では、”その実現に対してコミットする”とはどういうことか？これはマインドセットと活動自体の意味の２つを含んでいます。
マインドセットという意味では、「泥臭さ」が求められます。プロダクトの成長を阻害するものがあれば積極的に自分がタスクを拾っていく必要がありますし、加えてまだ見えてない課題を見つけるところから始める必要があります。これを尻込みするような態度はあまりふさわしくありません。泥臭くプロダクトの成長に向き合う必要があります。
そして、プロダクトマネージャーの仕事の詳細は、「プロダクトの目指す世界の実現に対してコミットすること」、これに紐づいています。これが先述した活動自体の意味という部分です。先ほどまでプロダクトの方向性という言葉を使っていましたが、少し解像度を上げました。理想の世界が目的で、それに近づく手段としてプロダクトが存在する、このような関係性です。その上で、プロダクトマネージャーの業務はプロダクトが手段として正しく機能することを目的としています。
ユーザーについて深く知る努力
プロダクトマネージャーはユーザーを深く理解する存在であるため、インプットをし続ける必要があります。 なぜならプロダクトは目指す目的があり、そのためには利用するユーザーの満足度をあげてユーザー数を増やす必要があるためです。ユーザー価値を最大化するためにはユーザーを理解する必要があります。なので、ユーザーからのFBや要望は全て目を通し、気になった定量情報は積極的に取得し、ユーザーとの会話の機会（ユーザーインタビューなど）に積極的に参加する必要があります。プロダクトのペインポイントはどこで、プロダクトの何を気に入っていただいているのか、理解するための努力は継続しましょう。（もちろん難しいことではありますが）
ここで大事なのが、ユーザーの声を鵜呑みにしないということです。もちろんユーザーの声は大切です。しかし、ペインポイントを解消するためには、要望を文字通り受け取ることは避けたほうが良いでしょう。ユーザーの声から垣間見えるインサイトに対して議論することが根本的な問題の解決になります。
仕様や要件の検討
新機能ないし、プロダクトに搭載する機能についてまとめます。 まず、ユーザーストーリーを記載します。ユーザーストーリーには、誰にどんな理由でどんな価値を提供したいのかを明記します。これが該当の要件の軸になります。ユーザーストーリーを目的として仕様を検討し、逐次確認する事で提供したい価値から仕様がずれる事を防ぎます。
次に、どういう機能なのか、どんな外部仕様なのかを仕様書に書いて言語化します。先ほど述べたように、ユーザーストーリーが目的なので、目的を実現する手段としての仕様は複数ある場合があることが多いです。これは色々な観点から検証して最適解を探っていく必要があります。社内はもちろん、できればユーザーにヒアリングしたいところです。また、定性情報だけでなく定量情報も確認しましょう。ユーザーの行動データを見て、ペインポイントを解消するにはどれが最適か検証することが大事です。
仕様書に期待している動作を誰が見てもわかるように書くことは意外と難しいです。言語化が綺麗にできれば最高ですが、そうもいかない場合も多いので、文字だけでなくペーパープロト、もしくはそれに同等のものも見せながらエンジニアやデザイナーに説明できるといいと思います。
バックログの作成、管理
プロダクトマネージャーは、プロダクトバックログアイテム（以降PBI）を作成し管理します。PBIには、概要とユーザーストーリー、受け入れ条件を記載します。この記載内容は現場によってそれぞれだと思います。
※ちなみに自分のチームではPBIに親子関係を持たせて、親は開発では取り扱わず、子を開発で扱うようにしています。githubのマイルストーンとissueで管理しています。（自分がエンジニアなので、githubを採用しました。）
そして、バックログに優先順位をつけていきます。優先順位をつけることでどの順番で製品に機能を追加したりしたいかを明確にします。リソースは限られているので、リリースの時期やたくさんの変数から何を優先すべきか意思決定することで製品価値を最大化させます。
この辺のスケジューリングや進捗のマネジメントも重要な業務です。開発の知識も必要でしょう。
関係各所との調整
プロダクトにはさまざまなステークホルダーが関わっており、プロダクトを成長させるためにはそれらの方々の協力はとても大切です。プロダクトの責任者として協力を仰ぐためには、簡潔にわかりやすくコミュニケーションする必要があります。人当たりも大切な要素です。
これはヘコヘコするような態度ではなく、立場や役割が違う中でその違いを踏まえた上で適切なコミュニケーションができるかどうかをさします。やはり、立場や役割が異なるとどうしてもそれぞれで利害関係が生まれます。同じ事象に対する見方もそれぞれで異なります。そういった中で画一的なやりとりをするのではなく、関係者の立場に応じて適切にコミュニケーションできることが大切です。
リリース
プロダクトは終わりがないですが（そう仮定する）、実際のリリースにおいてはリリース日があります。ここまで色々なステークホルダーにコミュニケーションをとり、依頼事項を依頼し、プロダクトマネージャーとしてプロダクトの成長を第一に考えてきました。ただ、ここで気を抜いてはいけません。リリースしてから問題がないように成果物をPM自身でしっかり触ってみましょう。仕様書と今までやってきたプロセスを振り返り、何か問題がないか最後の最後まで確認します。問題なければ無事リリースとなります。チームと関係者にお礼を言い、ユーザーの反応を待ちましょう。
リリースした後の効果測定
もちろん、リリースした後もプロダクトは続きます。検証をしないと今後立てる仮説の質が上がらず、プロダクト全体として成長しません。
まずは定量情報として、リリースした機能がどのくらい使われているのか確認しましょう。そして定性情報で確認できるものは確認しましょう。ここから推察できることを挙げて、次回のリリース、その次のリリースと反省点を反映させることが大切です。常に検証することは意識づけておきたいです。
必要スキル
開発知識
最低限の開発知識は必要です。自分はフロントエンドのエンジニアも兼務しているので、苦労はありませんでしたが、エンジニア経験のないのPMの場合はキャッチアップする必要があります。開発知識がないと、各施策や実装がどのくらいの工数かかるのか見通しを立てられませんし、どんな仕様が問題を生むのか予測ができません。ここは ITプロダクトであれば必須となります。
デザイン
デザインについても理解があるとなお良いでしょう。UXやどんなデザインがユーザーライクなのか知識として知っておくと、より良い案を検討することができます。加えて、関係者で議論しているときに具体的なデザインを定義、提示することで共通認識を取れるメリットがあります。そのため、figmaやXDなどのプロトタイピングツールを使えることも大切です。
データ分析
ユーザーの行動データや施策を検証する際に必ずデータを分析します。その際、基礎的な統計学の知識とSQLは必須です。統計学を抑えていると、データが提供している事実をしっかり事実として見ることができるようになります。もちろん深く学習しようと思えばいくらでも深く学習できると思いますが、基礎だけで構いません。また、欲しい情報をSQLですぐ確認することはどの業務でも必要になります。実際に書かないとなかなか覚えられないのですが、SQLは使いこなせるとベストです。
ビジネス
最低限のマーケティングや営業の知識は必要になります。ビジネスサイドと議論することは必ずあるので、共通言語として最低限押さえておきましょう。また、BtoBであれば営業の方が日々ユーザーと接しているので、営業の方にヒアリングする機会はあると思います。ビジネスと開発で溝ができないように気を付けましょう。
まとめ
プロダクトマネージャーは業務が抽象的でよくわからないと言われます。しかし、全ての業務は一貫していてプロダクトの成長を常に考えることです。そのために必要なスキルは幅が広く責任もありますが、とても楽しいです。半年経過したけど、これからも頑張ります。
参考文献
社会人になってから数学を中学からやり直しました
タイトルの通り数学を社会人になってから勉強し直したので、その勉強の過程や方法をシェアしてみたいと思います。
背景
そもそもなぜ自分が「数学を勉強しよう」と思ったかというと、エンジニアとしての地肩をあげるため、周りのエンジニアとの差を少しでも縮めたいためです。
自分は私立の文系の大学を学部で卒業してwebエンジニアとして仕事を始めたのですが、周囲のエンジニアは理系院卒が基本でした。
数学を受験でしっかり勉強していないことは自分の不利な部分であり、そこから生じうるロジックの構築能力の差があると感じていました。
それをキャリアの早い段階で埋めたいと思い、勉強しようと思いました。
勉強のコンセプト
社会人で勉強する時間が限られていますし、ゴールを設定することが学習の効率を最大化すると思ったので、下記のゴールを設定しました。
「数学Ⅰ・Ⅱ・A・Bの参考書を一通り終わらせ、全ての概念を理解できたと言える状態」
したがって、試験で何点取るとか、参考書の問題を全てを必ず解く、といったものではありません。
あくまで概念を理解して、プログラムを書く際に連想したりして役立てること、コンピュータを勉強する上での下地をつけることが目的です。
実施した具体的な勉強方法
使った参考書、どのように進めたのかをシェアしたいと思います。
参考書
使った参考書は下記の通りです。
中学の数学のやり直し以外、基本的にはマセマの参考書を使いました。 講義形式でそれぞれの公式や範囲の概念を理解するのにはもってこいでした。
どのように進めたのか
単元ごとに範囲があるので、基本的にそれに沿って勉強をしました。 例えば数BであればDAY15と15分割されていたので、1日5DAY分みたいなふうにやってました。（1日に1DAYはさすがに遅すぎる）
大体のかかった時間としては下記通りです。 数学Ⅱがやっぱり重かった印象を受けました。
- 改訂版 中学校3年間の数学が1冊でしっかりわかる本 1日
- 初めから始める数学I 改訂9 →7日
- 初めから始める数学A 改訂8 →5日
- 初めから始める数学Ⅱ 改訂9 →9日
- 初めから始める数学B 改訂8 →7日
旅行に行っていて勉強できなかった日もあるので、初めから終わりまで5週間強かかりました。
勉強し終わった所感
素直な感想としては、勉強し直してよかったです。どういう概念なのかがわからなかった分野も「基本的にこういう分野だよね」と自分の中で理解できるようになりました。
元々の数学の知識にも依存しますが、自分が設定したような目標であれば約5週間で達成できたので、勉強をやり直すか悩んでいる方はぜひやってみることをお勧めします。
新卒一年目に読んだ技術書＆仕事に関係する本
今回は新卒一年目で読んだ技術書、それに関連した取り組んだ勉強を紹介していこうと思う。
フロントエンドが自分の領域で、基本的にはそこから外の部分は業務で担当することはなかった。しかし、かなりいろんな分野の技術書を読んだので、この記事は本を探している人に参考になるかもしれない。
一覧
- 基礎
- コーディング
- リーダブルコード
- linux
- 新しいLinuxの教科書
- コンテナ
- 仕組みと使い方がわかる Docker＆Kubernetesのきほんのきほん
- Kubernetes完全ガイド 第2版
- DB
- 達人に学ぶDB設計 徹底指南書
- 達人に学ぶSQL 徹底指南書
- セキュリティ
- 体系的に学ぶ 安全なWebアプリケーションの作り方
- 暗号と認証のしくみと理論がこれ1冊でしっかりわかる教科書
- ネットワーク
- マスタリングTCP/IP
- インフラ／ネットワークエンジニアのためのネットワーク技術＆設計入門
- JS
- JavaScriptパターン ―優れたアプリケーションのための作法
- ハンズオンNode.js
- 開眼! JavaScript ―言語仕様から学ぶJavaScriptの本質
- フロントエンド
- Webフロントエンド ハイパフォーマンス チューニング
- コーディングWebアクセシビリティ - WAI-ARIAで実現するマルチデバイス環境のWebアプリケーション
- テスト
- はじめて学ぶソフトウェアのテスト技法
- デザイン
- なるほどデザイン
- PM系
- OKR（オーケーアール）
- 最高の結果を出すＫＰＩマネジメント
- 読み物
- 達人プログラマー
基礎
下記の四冊を読んだ。
基本的な考えや知識をインプットするために読んだ。 応用情報のテキストは実際に過去問をwebで解くことで、コンピュータに関する幅の広い知識を得ることができた。80%以上の正解率になるまでやることで知識が定着すると思う。 実際に応用情報の問題を8割以上にするまで2ヶ月くらい時間をかけました。（わからないことは逐次ググる）
コーディング
「読みやすいコードとは？」を教えてくれる本である。
学生時代にインターンしていた時にも読んだのだが、新卒で入社する時に戒めとして再度読んだ。 チーム開発では確実に知っておくべき知識だろう。
linux
基本的なlinuxの仕組みやコマンドを勉強できる本だ。
結局全てに通ずる分野なので、これは抑えたい。 linuxを使えずして何ができるみたいな部分は確実にあるので、確実に自分の知識にするべく研修に加えてインプットした。
コンテナ
コンテナ仮想化技術の概要を学べる。
dockerは全てのエンジニアが、使いこなせるべき。とはいえ奥が深いので基本コマンドと概念を正しく覚えることが大切だと思う。
k8sに関しては、弊社のインフラが大規模なレベルでk8を使っているので、インプットした。 minikubeを立ててサンプルコードをほぼ全て試して挙動を確認した。
DB
DBがどういったものなのかはキャリアの早い段階で学ぶべきだと思う。MySQLなど、DBは寿命が長い知識なのでコスパが良いだろう。
セキュリティ
「暗号と認証のしくみと理論がこれ1冊でしっかりわかる教科書」は興味で読んだ。
セキュリティに関する概要と全体像は「体系的に学ぶ 安全なWebアプリケーションの作り方」で確認できる。 この本は名著。わかりやすくて自分は好きである。
ネットワーク
どういった経路でサーバーにリクエストが飛び、レスポンスが返ってくるのかの仕組みはアプリケーションエンジニアとして理解しておくべきだろう。特にマスタリングTCP/IPはわかりやすく、ネットワークの教科書とも言えると思う。
JS
研修を早めに終わらせてしまい、改めてJSを基礎から勉強してみようと思い読んだ。正直JavascriptやTypescriptを結構書いている人にとっては発見がない本だと思う。自分には優しすぎた。もう少し初心者の時に読んだらいい本だと思った。
フロントエンド
フロントエンドエンジニアとして、細かい部分の知識を得るために2つの本を読んだ。
ブラウザの仕組みから、サイトを早くするためにはどうすればいいのかを「Webフロントエンド ハイパフォーマンス チューニング」で学んだ。すごくわかりやすい。
また、アクセシブルなサイトを作るための知識として、「コーディングWebアクセシビリティ」を読んだ。 a11yは学生の時なかなか意識できなかったので、再度勉強したいと思い購入。やはりWAI-ARIAは実装しながら学ぶものだと実感した。
テスト
ソフトウェアのテスト理論をインプットした。テストの考え方や種類など。 QAが考える領域も理解しておいた方がいいと思うので、ぜひ読むことをおすすめする。
デザイン
デザインを図解で表現していて、実践的なデザイン感覚を学べる。デザインはセンスではなく、どれだけ触れてきたかが重要になりそう。
PM系
2022年からPMとしての役割が追加され、目標設定や方向づけの部分もしていく必要があった。そのため、各フレームワークについて改めてしっかりインプットした。
OKRをプロジェクトで議論し作成したが、これからが楽しみになる良いOKRを策定できた。その意味ではこの本を読む価値はとてもあると思う。
読み物
エンジニアとしてのスタンスを学べる本。結構いい本だったが、あくまで精神論や勉強に対する姿勢なので、大したものでもない。
まとめ
結果として24冊の技術書を今年は読んだ。今後も謙虚に勉強して行きたい。
社会人になる前に知りたかった社会の仕組み
本記事では、人生において本当にケアすべきリスクとそうではないリスクをまず考える。 そしてそうではないリスクに対して、いかに国が対応しているかを見ていく。
個人的には、国が用意している社会制度ついて、案外知らなかった。社会人になる前に知りたかったので、本記事を「社会人になる前に知りたかった社会の仕組み」というタイトルにした。
参考文献にも書いているが、この記事は両学長の「本当の自由を手に入れるお金の大学」という本を参考にしている。
ためになるので、読むことをお勧めする。
気にするべきリスク
世の中リスクに溢れている。それら全てに対応していたら時間もお金も足りないだろう。
大事なのは低確率で大損失なものに備えるという考え方を持つこと。
具体的には以下の事象に備えることが大切。
- 火災
- 死亡（家族がいる場合）
- 自動車事故（自動車を持つ場合）
逆にいうと、これらは自分で備える必要はないということだ。（もちろん個人の志向や状況に依存するが、多くの人が準備不要）
- 病気・怪我のリスク
- 歩けなくなるなどの障害リスク
- 死亡リスク
- 失業リスク
- 老後リスク
- 介護リスク
- 出産費用のリスク
では実際にどういったケアを社会が準備しているのか。
知っておくべき社会制度
今から紹介する社会制度は時間の流れで制度が変更される可能性がある。そのため、盲目的に信じるのではなく自らで知識を吸収する姿勢が大事だ。
公的医療保険
日本では、会社員/公務員は健康保険、自営業者/フリーランスは国民健康保険、高齢者は後期高齢者医療制度、というふうに国民全員が健康保険に加入している。保険により、自己負担30％で最低限の医療を受けることができる。
さらに高額療養費制度という制度により、同じ月にかかった医療費が自己負担限度額を超えた場合超過分が後で払い戻される。自己負担負担額は年収と年齢によって決まるので、詳しく知りたい場合は厚生労働省のページを参照しよう。
すなわち上限が設定されているので、高額な医療費になった際の自己負担も比例して増加するというのは間違いである。
また、傷病手当金により病気や怪我で働けなくなった際には、生活を保証するために直近月収の2/3が最長1年六ヶ月補償される。
公的医療保険により、病気・怪我のリスクに対して個人で特に対応する必要がない。
障害年金
障害年金とは、病気や怪我によって生活や仕事が不自由になった場合に支給される年金である。もちろん現役世代も受給することができる。条件は少し複雑なので、ここでは割愛する。しかし、ちゃんと国民年金に加入し、加入期間の2/3以上保険料を納めている人が、1年6ヶ月以上経っても働けない場合に受給できると考えて良い。
受給額は障害の級、会社員かどうか、配偶者・子供の有無によって変わるので、詳しく知りたい場合は、日本年金機構の障害年金のページをチェックしよう。
遺族年金
家族がいる場合は、自分が死んだときのために遺族年金を使おう。養っている家族がいるのであれば、最低限の金額が支給される。
詳しくは日本年金機構の遺族年金のページを確認しよう。
雇用保険
失業してしまった場合には失業給付を使うと良い。働く意志と能力があるのにも関わらず職業につけず、かつ原則として被保険者機関が通算で12ヶ月以上ある際に使える。
失業給付の給付金計算サイトが存在するのでいざとなった時は計算するとよい。 https://keisan.casio.jp/exec/system/1426729546
さらに就業手当、再就職手当、教育訓練給付金、育児介護休業給付金といった、雇用に関する手当はたくさんある。
厚生年金・国民年金
厚生年金と国民年金という2つの年金で年金制度は運用されている。自営業やフリーランスは国民年金のみで、会社員は厚生年金も支払う必要がある。
また、厚生年金は勤続年数✖︎平均年収✖︎0.005481、国民年金は年額約78万円、受給することができる。
もらえる金額を見ると、払い損になるかどうかが気になるだろう。
しかし、基本的に払い損にならない試算がでていて、詳しくはググるといいが下記ページが参考になる。 https://news.yahoo.co.jp/articles/37440c699bb2c29146a63085908ee6d320a49177
どうやら利率は高く、65から10年以上生きると元が取れるそうだ。（厚生年金の方がたくさん受給できるがほとんど結果は同じ）
とはいえもらえる金額を試算したのち、贅沢したい場合は個人でなんとかするしかない。
介護保険制度
要介護状態になった場合の方策がある。介護保険制度だ。
介護保険制度は４０歳以上から保険料を納めることで、将来要介護で介護サービスを利用した際に自己負担が原則1割で済む保険である。保険料自体は大体5000円くらいらしい。
出産に関する制度
出産育児一時金という制度が存在する。これは、出産時に40~42万の出産育児一時金が支給されるという国民保険の中の制度である。なので出産にかかるのは50万くらいといわれているが、実質10万円くらいでなんとかなる。
加えて、出産手当金と育児休業給付という制度が存在する。これは一時的な収入減に対応するもので、詳しい期間の条件が存在するので詳しくは下記リンクから参照してほしい。
まとめ
上記でチェックしておくべき社会制度を見てきた。もちろん個人で保険で対応することは悪いことではないと思う。しかし、時間とお金、労力は有限なリソースであるため、最小限の部分に個人で対応した方が賢いと言えるだろう。
個人の意見としては、病気や怪我は可能性自体はとても低いのでそこに日常からケアするよりも、自己投資などして稼ぐ力を上げる方に注力した方が、若いうちは効率がいいのではないだろうか。もしくは定期的に運動したり、食べるものに気を使うなどして長期的な健康を考える方が本質的な対策だと思う。
参考文献
介護保険料はいくらぐらい？ 保険料はどのようにして決まるの？
出産で会社を休んだとき | こんな時に健保 | 全国健康保険協会
