ユニファ開発者ブログ

ユニファ株式会社プロダクトデベロップメント本部メンバーによるブログです。

エンジニア経験のないPdMが見積もりに関わるときのチェックポイント

こんにちは、ユニファPdMの水本です。

前回ブログでは、仕様書に関する時短化のお話をさせていただきました。 tech.unifa-e.com

今日は、PdMの幅広い業務のうち、わたしが比較的弱めである「概算見積もり」「見積もりレビュー」について、弱いながらにどのような工夫で乗り切っているか?というテーマで書かせていただきます。

私は、新卒からずっとディレクター職(ITコンサル、ディレクター、プロジェクトマネージャー的なところ)を担当しており、業務としてエンジニアを経験したことがありません。 そのため、自分で概算見積もりをしたり、見積もりレビューを技術的な観点ですることはできません。

ただ、PdMとしてこの領域が「わからない」まま放っておくと、PJのリスクが高まりますよね。

  • 適切な追求をせず見積もりを確定させると・・・

    • 開発着手後に工数増が起き、スケジュールやコストが増大してしまう
    • 目先の工数で対応内容や順番を判断してしまい、のちのフェーズのコストが嵩んでしまう(引き返せない)
  • 見積もり確認の仕方を間違えると・・・

    • チームコミュニケーションの悪化(議論ポイントが伝わらないまま対立してしまうなど)

そういったことを避けるために、開発の業務経験がなくてもできるチェックポイントを挙げてみたいと思います。

見積もり依頼時:とにかく認識齟齬を生まないための説明をする

1. 「実施の目的」「現状だれがどこでどんなふうに困っているか」「解決したいこと」を最初にもれなく説明

この案件の価値になる部分なので、最初にしっかり伝えます。簡潔に文章で書き、口頭でも背景を説明して、見積もり担当者に認識していただきます。こうすることで、見積もり中に出る疑問が、目的から逆算したものとなるため、コミュニケーションの精度があがっていきます。

2. 希望の外部仕様がはっきりしているときは、ワイヤーに書く

既存画面のキャプチャ&切り貼り&吹き出し説明などがあれば一旦十分です。スピード感も大事です。

3. 実現方法に特別なこだわりがない部分は、先にその旨を伝えておく

「原案では〜〜ですがこだわりはあまりないです(工数優先)」などと書いています。

見積もり確認時:不明点は解消して記録に残し、検討材料として使えるよう整える

4. ここ1年くらいの他の見積もりと比較し、「なんか大きいな」と思ったらその部分の詳細を確認する

ユニファでそのようなコミュニケーションがあるわけではありませんが、一般的に「値切り」が目的ではないことが見積もり担当者に伝わっていないと、議論がずれていくことがあります。適切にヒアリングが進むと、「実はここに技術負債があって…」や「他プロダクトとのデータ連携のため制約があって…」など付随する問題がいろいろと見つかり、今後の計画に役立つことがあります。

5. フェーズアウトできる部分を積極的に探し、MVP(最低限)案を作る

向こう1年くらいの他施策の実現粒度も参考にしながら「どこまでやるのがちょうどいい(=少ない工数で大きい効果が出せる)か」という観点で調整していきます。ここがPdMとしてのこだわりポイントかと思います。今回実現できないという結論になった部分も、次の開発検討時にまた使えるので、しっかりメモを残していきます。

ーー

以上になります。

見積もりに関するやりとりは、人によってコミュニケーションスタイルの違いがやはりあるものなので、チーム編成当初は効率が悪く見えることがあるかもしれません。でも前向きに議論が進むことをお互いに経験することで、だんだん意見がスムーズに出し合えるようになると思います。

同じようなお困りごとが発生した際には、ぜひ試してみてください!

ユニファでは、一緒に働く仲間を募集しています!

jobs.unifa-e.com