プロダクトオーナーを経験してドメインを理解する感覚が身についたかもしれないという話

現在自分は会社の仕事で認証基盤とマイクロサービス向けのアプリケーションプラットフォームを構築していて、 役割としてはテックリードとプロダクトオーナーを兼任している。 自分が開発、運用するシステムは主に社内のエンジニア向けの仕組みなので、 問題解決対象が技術領域となっている。 "技術的な課題を技術で解決する" という性質上、 プロダクトオーナーもある程度技術を分かっていないといけないので現状兼任している感じである (正確に言うと People Management もしているので、Engineering Manager も兼任していることになるが、 今回の内容と関係ないので触れないでおく)。

チームに興味ある方は連絡ください。


"社内のエンジニア向けの仕組み" を作るには社内のエンジニアのニーズ(抱えている問題)を知らなければいけない。 そして、それを解決するためのプロダクトを作らなければいけない。 プロダクトオーナーとして動くと、単にエンジニアとして開発するよりもここらへんが見えてきて、 プロダクトの重要な機能や満たさなければいけない要件が分かってくる(むしろ、ここが分からないと何もができない)。 実は社内のエンジニアが気づいていないだけで、 自分から見ると明らかに課題が存在するケースもあるので、 単に社内のエンジニアとコミュニケーションを取って、望むものを作ればいいというわけでもなかったりするが、 それを書くと長くなるので詳しくは触れないでおく。

開発ではスケジュールも重要である。 最高品質のものを作ろうとすると、"あれもこれも" になってしまい、どーしても時間がかかってしまう。 完成するまでずーっと問題を放置するわけにもいかないし、 実際に社内のエンジニアにそのプロダクトを使ってもらわないと、 そのプロダクトが本当に問題を解決できるかも分からない。 なので、問題を解決できる最低限の機能を実装したものを開発し、 とにかく良し悪しのフィードバックをもらうのが重要である。 いわゆる MVP(Minimum Viable Product)を設計するスキルが求められる。 当然いつまでも最低限の機能だと不便だったり、他の利用者の要件を満たせないので、 利用者からのフィードバックを参考に徐々に機能をリッチにしていく。

プロダクトオーナーとして動くことで、問題、解決手法、MVPをそれぞれ深く考えることになるので、 プロダクトにおける "この機能がないと使ってもらえない" とか "この機能があの問題を解決する" という部分が分かってくる。

また、自分は副業で主に自社サービスを開発している企業の技術支援をしているが、 その際にまず最初に確認するのが "営業用の資料" や "サービス説明をしているホームページ" である。 特に営業用の資料は(ToBのサービスを開発している企業しか用意していないことが多いが)、 "営業の方が自社サービスを利用者に使ってもらうための資料" なので、 想定している課題とそれをどのように解決するのか? という部分を理解するのにとても役に立つ。 想定している課題や解決方法の良し悪しは当然ながら、 企業側が重要視している部分を知ることができるので、 (技術支援で求められた内容次第ではあるが)自分としても重要視している部分を中心にレビューしたり、 優先順位をつけて開発するような提案ができる。

DDDではエンジニアがドメインエキスパートとコミュニケーションを取って、 ドメインを理解するというのが王道だが、 自分がプロダクトオーナーというドメインエキスパートに相当する役割になる機会が多くなって、 多分これがドメインを理解するってやつなんだろーなと思った(特にコアドメインを認識できるにようになった)。