B-Teck!

お仕事からゲームまで幅広く

【振り返り】2022年2月

前月の振り返り
【振り返り】2022年1月 - B-Teck!

学習

今月やったこと

所感

自分の会社では2月が下期スタートということもあり、ひたすらバタバタしていたような気がします。
あっという間に終わっていて、今月は主だったこと何もできていないなあという感じでした。

今月も引き続きすこーしずつコップ本を進めながら、先月読んでた実践Terraformを読了しました。
AWSの知識がうろ覚えのものばかりだったのでちょっと難しかったですけど、わかりやすい本でした。
いい機会なのでAWSもうちょっと理解しようと何冊か積み増したりしています。 コップ本は数ページ読みながら写経して咀嚼するのに1時間とか平気でかかっていて、全然読了が近づいている気がしないです。
数字の上では半分は超えたんですが…。

あとは先月も書いていた、キャリアの話に引続き悩んでいます。
これまでは人の足りないところに飛び込み、必要に応じてスキル習得しながら着地に持っていく、という仕事が多く、中長期のことをあまり考えていませんでした。
ちょっと先を見たときに自分がどうなっているかの姿が全然ないんですよね。
中長期的にはこうなっていたい、と現状の自分に出せる最大出力を出す、は両立できればちゃんと武器になる気はするので、どうにかしたいと思いつつ。
プロダクトとか組織について中長期的にどうあるべき、だからこうするはなんとなく考えられても、自身についてが格別に難しい。
こういう思考の筋肉もつけていかないといけないんだろうなぁという今日このごろです。

趣味の話。 今月はゲームをする元気もあまりなかったので控えめですが、相変わらず基本的にはApexばかりしてました。
あとは何冊か積んでいた小説を崩したり。
なんかここ数年のこの時期はいつもへばっている気がするので、うまくこの流れを断ち切っていきたいところではあります。

来月の振り返りまでには、もうちょっと自分の先の姿について想像できていると良いなぁ。

SaaSの開発ロードマップ、マイルストーンどう決める?【開発PM勉強会vol.8 オンライン】に参加した #開発PM勉強会

peer-quest.connpass.com
に参加してきたのでメモ。
投稿時点で公開されていた資料は記載しましたが、順次追記予定です。

個別最適のSaaSと上手く向き合うプロダクトロードマップ

speakerdeck.com

  • プロダクトロードマップとは
    • 「やることリスト」ではなく「ありたい姿」への最短ルート
    • 2軸で伝える「ありたい姿」
      • 将来プロダクトが実現していたいユーザーの姿を描いた「よげんの書」
      • 提供したい価値を抽象化したプロダクトビジョン
  • ロードマップの策定
    • 具体化するフェーズと抽象化するフェーズを行き来する
    • 事業計画を因数分解し、優先順位を付ける
      • やらないことを明確に
      • バリュープロポジション内でも優先順位を決める
  • ロードマップの課題とそれに対する運用
    • 関係者が多く、プロダクトの在り方や目指す姿、最新のロードマップがわからない
      • 最新のロードマップの場所を固定化し、月1回の全部署誰でも参加可能な議論タイムを設けた
    • プロダクトが大きくなり、異なる目標を追いかけるチームの要望をうまく扱う必要が出てきた
      • セールス・CSそれぞれバックログを分けた
      • POがそこから実際に取り扱う順番を決めている

エンタープライズSaaSの初期成長戦略

  • POが思い描く世界観を実現したい顧客を探す
    • 通常の受託開発とは異なることを理解してもらう
      • 個別要求に答える場合もある
        • 汎用的な機能はSaaSに取り込む
        • 個社に特化したものはあくまで機能外のものとする
        • 一旦個社の機能として対応してから汎用機能化する場合などもある

急成長なフェーズでの成長戦略

  • ロードマップで実現したいことはコンテキストで変わる
    • 未来予想
    • 工数管理・リソースの可視化
    • 計画を立てて機会損失をなくす
  • ロードマップ文化が定着した背景
    • メンバーが増えたことで難しくなった事業・部署間連携のため
      • ビジネスチームが売りたいものとエンジニアが作りたいものが乖離していた
      • 成長ファクターが一部の人間に集中し、リスクとなっていた
    • 新規開発、追加開発、改善や技術的負債回収のいずれかによって異なるスケジュール感
  • ロードマップ作成の流れ
    • 達成するべき売上・リリース日がトップダウンで決まる
    • 事業課題を小課題に分解し、コスト計算
    • ステークホルダーとの意思決定、スケジュールの打診
    • Qが始まる3ヶ月前から、Qの開始から半年分のロードマップを引き始める
      • 20%のバッファを設けた状態で引く
  • 運用時に出た課題
    • 差し込みが入って進まない
      • 予想可能なものはロードマップに組み込む
      • 予測不能なものはその内容によっていくつかの対応がある
        • 次に同じことが起きた場合に備えたドキュメント化
        • バッファを一定設けておく
    • マイルストーンやスケジュールが引けない
      • はじめてだと精度は50%くらい
      • 実際に発生した工数を管理して運用しながら精度をあげる
      • ある程度の係数を設けて見積もる
      • 複数人で見積もりをする

アルプのロードマップ変遷

speakerdeck.com

  • 仮説検証フェーズではロードマップはあまり参照されなかった
    • 半年くらいの目標はあったが、顧客のニーズに合わせて変化していた
      • 追いかけるための目標としての信頼感がなかった
      • エンジニアはあまり気にしていなかった
    • 作ってみないとわからないフェーズではロードマップよりもなぜ作るのか?が知りたい
  • プロダクトの方向性が定まった上で、それを伝える手段としてのプロダクトビジョン
    • プロダクトビジョンからトップダウンでロードマップを決める
    • 組織間でプロダクトビジョンを達成するための共通認識としてのロードマップ
  • ハイインテグリティーコミットメント
    • わかる/できる前に求めない
      • 誠実な時期を伝えるための情報収集・整理
    • 開発チームに驚きがない状態で方針を決める
    • できるだけ納期はコミットしない
    • コミットメントを小さく、納得感のあるサイズにする

感想

  • プロダクトのビジョンとロードマップの接続がわかりやすいかで組織の納得感が変わってきそう
    • 組織が方向性を揃えて連携するためのロードマップ
    • 現在のビジョン・ロードマップから未来の姿を思い描けているか?
  • 必要としているロードマップのコンテキストについてあまり意識したことはなかった
    • 複数のコンテキストを統合して1枚のロードマップとして表現する場合もありそう
  • ロードマップの精度を上げるために開発に提供してほしい情報はどういうものなんだろう
    • 予測不能なものから予想可能なものを切り出して、わからないものを小さくするとか
    • やはり実工数の計測は必要かもしれない
  • 仮説検証フェーズでのロードマップは引いても気にされないし、信頼もされないのはなんとなくわかる

【雑記】このキャリアがわからん2022

ここしばらく、キャリアとか今後目指すべき姿ってなんだろうみたいなことをよく考えてる。

これまでは浅く広く技術を学んで、人が足りなければ飛び込み、チームを駆動させるということを目指していた。
得意不得意はあるものの、最短でキャッチアップしてとりあえず走り始めるみたいな戦い方はある程度できるようになった気がする。
でもそれは目の前の事にがむしゃらになっていればよく、良くも悪くも自分に閉じた動き方や学習でなんとかなる範囲の話で。
これまで先の事をあまり考えていなかったツケもあり、今後どうなっていきたいのか、何を目指したいのかと問われたときにうまく答えられない自分がいる。

足りないロールを埋める、から一歩先に進むときに、目指すべきゴールが急にわからなくなってしまった感覚。
何になりたいのかがいまいちはっきりしないので、足りない段差を埋めるためのなにかを見つけられていない。
そもそもこれまでも自分の意志なんてあまりなくて、周りの要求に合わせてふわふわ生きてただけなのかもしれないけど

自分が考えてこなさすぎだったのか、他の人も悩む部分なのかわからないけど、最近はなんともモヤモヤ考える毎日を送ってる。

とりあえずこの辺を読んでみてるけどまだ腹落ちはしてない



アドバイスとか、参考になるいい話とか記事とか本とかあればこっそり教えて下さい。