社会人3~5年目のキャリアに悩むエンジニアに知って欲しい、「プロダクトマネジメントしながらエンジニアする」という選択肢
こんにちは、atama plus エンジニアの鈴木です。好きな開発領域は、Webフロントエンドです。
突然ですが最近、カジュアル面談や面接の担当を行う機会が増えてきました。その中で「前職の大手IT企業時代に感じていたモヤモヤのいくつかが、実は普遍的な悩みだったのでは」と考えはじめました。
本記事では、これまで私が感じてきたモヤモヤを紹介するとともに、それらを解決しうる「プロダクトチーム」というコンセプトについて紹介させてください！
本記事は下記書籍を参考にしており、一部引用を用いています（文末に参考書籍へのリンクがあります）。
・Melissa Perri「プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける」 , オライリージャパン (2020/10/26)
・Marty Cagan「INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント」, 日本能率協会マネジメントセンター (2019/11/1)
・Jonathan Rasmusson「アジャイルサムライ−達人開発者への道−」, オーム社 (2011/7/16)
社会人3年目あたりで私が感じていたモヤモヤ
・「アウトカム（顧客への価値）」よりも「アウトプット（作ること）」が重視される
私がatama plus入社前にいた大手IT企業では、期中にリリースする機能のロードマップが設定され、それが顧客に良い価値を及ぼしたかよりも、納期の達成度合で人事評価されるケースがありました。
ウォーターフォールの考え方に基づいて、目標や計画が策定されている状況では、開発チームが現場でアジャイル開発をしても、本質的にはアジャイル開発を行えていないな、と感じていました。
ちなみに、 顧客の課題を解決するような価値（outcome）ではなく、納期であったり、作ることや完成させること（output）に集中する状態を「ビルドトラップ」と呼ぶことがあります。
ある会社で聞いたのは、「私のボーナスはリリースする機能と連動しています。年末が近づいてるのでリリースしなければいけないんです」というものでした。（中略）
すぐに気づきました。ビルドトラップにはまってるいるのはプロダクトマネージャーだけでなく、組織全体でした。
出典：プロダクトマネジメント p.xiii
・職種や部署をまたいだ役割を超えるコラボレートが難しい
エンジニアの皆さまは社会人3年目くらいまでに「アジャイルサムライ」といった書籍を読んだ方も多いと思います。
そうした書籍で語られる「互いに補完し合う職能横断型チーム」というコンセプトが、自分の組織では実現できないことを恨めしく思った方もいるのではないでしょうか。（以前の私のように…）
アウトプットを重視する組織では、生産性の向上を図るため、役割を細かく分割することがあります。私自身、自分が流れ作業の一部のようで、役割を超えた働きかけが難しいと感じる経験がありました。
・プロダクトの仕様に責任をもつ立場になるためには、人のマネジメントをしなくてはならない
社会人4~5年目になるとマネージャーの役割に進むべきか否か、決断を求められることがあるかと思います。もちろんエンジニアの場合は専門性を強化していくという選択肢もあります。
前職では、本当にやりたいことは「良いプロダクトを作ること」であっても、そのためには管理職のような人をマネジメントする役割を兼務する必要がありました。プロダクトの仕様に責任をもつ立場になるには、同時にマネージャーになる必要があったのです。
・プロジェクトマネージャーしかおらず、プロダクトマネージャーが存在しない
納期や作ることそのものに集中する組織には、見積りやそれを遂行することに責任をもつ「プロジェクトマネージャー」というメンバーがいることがあります。
機能が積み上がったプロダクトは、経緯のよくわからない機能があったり、誰も知らない古のページが存在することもしばしば…
反対に、顧客の課題解決やそれを実現するプロダクト開発に集中する組織では、「プロダクトマネージャー」というメンバーがいることがあります。
以下に、プロジェクトマネージャーとプロダクトマネージャーの違いを示す文章を引用します。
プロジェクトマネージャーは「いつ」に責任を持ちます。（中略）
プロダクトマネージャーは「なぜ」に責任を持ちます。
出典：プロダクトマネジメント p.32
私にとって大切だった仕事の価値観とは
転職活動を行っていた当時、言語化することはできませんでしたが、今になって思うと私は下記のようなことを大切にする組織やチームを探していたことがわかりました。
・アウトプットではなくアウトカムを大切にする組織であること。
・プロダクトのために役割や役職を超えてコラボレートしあうチームであること。
・仕様やプロダクトのことを考えながらコードを書けること。またそうした活動に自身の業務時間がフォーカスされていること。
・プロジェクトマネージャーではなくプロダクトマネージャーがいるチームで働くこと。
プロダクトチームとは何か
「INSPIRED」や「プロダクトマネジメント」といった、プロダクトやチーム、組織のあり方について記述されたモダンな書籍を読み、そうした書籍で描かれている「プロダクトチーム」というコンセプトは、まさに私の大切にしたい要素を兼ね備えていることに気づきました。
ここからはatama plusの開発チームがどのようにして、「プロダクトチーム」の実現を試みているかについて、少しだけ紹介させてください。
・ディスカバリーのために役割を超えてチームが協力しあう
atama plusでは、机上で考えたアイデアや機能をそのまま開発し始めるということは滅多にありません。まず「ディスカバリー」と呼んでいる課題解決のアイデア出しと、その筋の良さを検証する実験を行います。
私の所属するチームでは、特に重要な課題に「Design Sprint」というフレームワークを活用しながらチーム全体で取り組みます。エンジニアやQA、デザイナーといった役割を超えて、紙にスケッチしたものをFigmaでプロトタイプ実装し、ユーザーテストまで行います。コードになる前にアイデアが本当に顧客の課題を解決するのか、事前にメンバー全員で見極めます。
・チームはフラットで上下関係がない
チームにプロダクトオーナーは存在しますが、優先順位を決めるなどの役割を担っているだけで、マネージャー(管理職)ではありません。
atama plusでは、とにかく生徒のためになることを、皆がフラットに議論することを良しとする文化が根付いており、チームや組織もそれに適したものであろうとしています。
・チーム全員でプロダクトマネジメントする
atama plusでは「何を作るのか」や「どう作るのか」に対して、チーム内でのディスカバリーを通して考えていきます。
そのため、チームが考えたり責任をもつ範囲がとても広くなります。チームメンバー全員が課題を解決していくために自律して行動するため、プロダクトオーナーは目先の改善策の優先順位を考える仕事のみならず、非連続な（10xな）成長をもたらしうる選択肢にフォーカスすることができます。
・権限委譲ができる組織であり、チームに必要な権限が与えられている
atama plusではチームに目標達成のオーナーシップが渡されるので、チームメンバーがいつでも実験やアイデアを試すことができ、自律してプロダクトやビジネスの課題を解決できるようになります。すると、アウトプットよりアウトカムを重視した上で、その先にあるインパクトまで考えた動きが取れるようになります。
このようにatama plusは、チームがプロダクトのオーナーシップを握り、全員で同じ目標を達成するための「強い」製品開発文化が根付いています。また、これからもそうしたプロダクト主導の組織であり続けようとしています（少なくとも私にはそう見えます）。
宣伝
採用活動を頑張っています。atama plusのプロダクトつくりに興味を持っていただいた方はお話聞きに来てくれると嬉しいです。
参考書籍
この記事が気に入ったらサポートをしてみませんか？