ゆるふわTechBlog

おしごと関係のひとりごと

女性エンジニアのプロダクトオーナーへの挑戦

この記事はGeek Women Advent Calendarの11日目です。

www.adventar.org

書きたいこと

今まで関わってきたプロダクトで、 もっと エンジニアが主導権を持っていれば、シンプルでいいものが作れたのに って思ったことはありませんか? 無理ゲーな企画とスケジュールが既にあって、 頑張って作ったのに全く使われなかった ことはありませんか? 苦労して作ったのに無駄だったとか嫌じゃないですか。

この記事では、プロダクトオーナーに挑戦しているエンジニアの私が、無駄なものを作らないためにしたことを、実例として紹介します。

尚、ローンチ前のプロダクトのため、資料は一枚も出していません!(すみません)

それから、Geek Women のアドベントカレンダーなのでタイトルに「女性」と書きましたが、女性に言及した内容はひとつもありません!(すみません)

というのも、エンジニアもプロダクトオーナーも女性であるメリット・デメリットはさほど変わらないからです。 「女性管理職」という文脈なら変わりますが。

私について

私は30代半ばの女性エンジニアです。

ここ数年、大きめのWEB系IT企業で新規案件の開発リーダーをしてきました。 スクラムマスター的な関わり方が多いです。

今秋、また新規開発の話が来たので、今度はプロダクトオーナー(以降、POと略します)としてプロダクト作りをさせてもらうことにしました。

プロダクトオーナーって何するの?

POは、何を作るかを決定する人です。それにつきます。 って言っても抽象的なので、今秋POになってから今日までの2ヶ月強に起きたこと、やったことを書いていこうと思います。

1週目〜2週目

前のプロジェクトの引き継ぎをしながらプロダクト設計を始めました。

まずは インセプション・デッキ」「リーン・キャンバス」 を使って、上司/顧客/チームと製品の目的とスコープの定義やリスク整理を始めました。 更にほとんど全ての関係者に 「実用最小限の製品(MVP)」 から作りたいと伝え、 芯を食った製品 は何かを定義しました

3週目〜4週目

顧客と 「ペーパー・プロトタイピング」 を始めました。

メンバーには平行して「アーキテクチャの検証・選定」、「システム設計」をしてもらいました。 また スクラム の導入を決め、 「プロダクト・バックログ を作成し、おおまかな見積もりもしました。 この作業の中で「インセプション・デッキ」と「リーン・キャンバス」がほぼ固まりました。

このプロダクトには試作品と協力的な顧客がいましたし、さほど難易度の高いプロダクトではないので、ここではあまり苦労をしませんでした。

5週目〜6週目

組織上の理由で、開発メンバーが5人増えました。

「実用最小限の製品(MVP)」に削ったのにエンジニア7人!多過ぎっ! でもサラリーマンなので決定には逆らいません。っていうか多い分には工夫できます。

「技術的なチャレンジ」 を盛り込んで組織貢献することにしました。 更に、諸々の設計や見積もりをした既存メンバーはマイノリティになるので、必要な分だけの再設計、再見積もりを全員でし直して、納得して始めてもらえるようにしました。

7週目〜8週目

やっと機能開発のスタートです。 チームはトラブルが少なく、思った通りのプロダクトが上がってこなかったとしてもまだ巻き返せる、平和な時期です。

この頃から私は 「他プロダクトの課題解決」「新企画の計画」 に参加するようになりました。 このプロダクトはとあるシリーズ物の中の1プロダクトなのですが、他プロダクトとの連携に課題があることに気付き、 全体最適 への提案もしました。

POの仕事って担当プロダクトのミッションや盛り込む機能の定義をするので、その中で別のプロダクトにあるべき機能に気付いたりするんですよね。 新米POの私にとってこれは新しい発見でした。 これらは今も進行中・・・(進めなきゃ・・汗)

あと、この頃から 「会議資料作り」 が面倒くさくなりました! これまでは決まってないことが多いのでざっくりでよかったのですが、急に詳細な計画が求められます。 スクラムなので、未来のことはざっくりしてますからね、デタラメをそれっぽく書いて提出してます(嘘です)

※補足をすると、スケジューリングはプロジェクトマネージャの仕事ですが、このプロジェクトでは組織上の理由からスクラムマスターと私で分担して担っています。

9週目〜10週目(現在)

BIツール の導入を爆決めしました。 ある日出席したBIツールの勉強会で、これを導入すれば実装する機能を減らせるなあ、と気付いてしまったんです。(遅い)

で、関係各所に交渉。 チームは既にその機能の開発に着手していたのですが、 謝って変更 してもらいました。

機能が減った分、 スケジュールを2週間前倒し に。

来週ユーザーテストに入る予定で、現在、細かい機能の実装と試験と修正をしています。

一点、ひどく驚いたことがありました。

実はこのプロダクトはPOも顧客もスクラムマスターもエンジニアか元エンジニアです。 突拍子もない要望や設計はなく、ペーパー・プロトタイピングでアウトプットのイメージも合い、そしてエンジニアは依頼通りのものを作ってくれました。

それでも成果物に多くの修正が発生したんです。全員が驚きました。

ここまで認識があっていれば大丈夫だと思っていたんですが、ソフトウェアの開発は私の知っていた以上に難しいようです。 次からはもっと作りこむ前に顧客チェックを入れます。猛省。

まとめ

まずは、POってマトモに取り組むとすごい忙しいんだな、という実感です。

  • 日々変わるビジネスのトレンドやボスの要求をキャッチして、検証したり、軌道修正を加えたり、愛想笑いでごまかす
  • 他所のプロダクトの最適化をしたり新しい提案をする(自分のプロダクトを適正に保つため)
  • そのための調整調整調整
  • 完成したプロダクトの確認・調整
  • 完成しなかったプロダクトをどうにかする
  • ボスに進捗報告
  • チームや組織の盛り上げや調整

※上記の中には純粋なPOとしての責務以外のこともありますが、サラリーマンなのでそういうこともあります

それでも頑張ろうと思うのは、 顧客にお金を払ってもらい、チームに苦労して作ってもらったプロダクトを成功させるのが私の責任 だからです。

ここで手を抜いたら人でなしだと思う・・チームに顔向けができない!

最後に

私は POは専門職 だと思っています。 エンジニアリングでもマーケットでもなく、プロダクト作りという専門技術があると思って勉強しています。

私のプロダクトはまだローンチしていないので成功するかわかりませんし、顧客やチームから見たらとんでもないPOかもしれません。 (実際にたくさんの失敗をしていますし!)

1年後くらいには結果がでているでしょうから、また報告ブログが書けたらいいなと思っています。