プロダクト提供を行う企業において、開発から販売までの一貫した戦略設計やマネジメントを担う「プロダクトマネージャー（以下、PdM）」を役職として置いているケースは多くあります。

一方、当社の開発部（※エンジニア/デザイナー在籍）は100名規模を目前とし、年々メンバーが増えていますが、今だ「PdM」という専任のポジションは置いていません。

“PdM不在でなぜ問題ないの？”
“とはいえ、実態はエンジニアが不満に思っていたりして......?”

今回はそんな淡い期待(!?)を抱きつつ、開発本部CTO室の🟦 Oさん（トップ写真左）・🟥 Iさん（写真右）に開発現場の実情を教えていただきました！

✔️ PdMのいない開発ってどんなイメージ？
✔️ PdMがいなくても問題が起きない秘訣
✔️ それでもやっぱり大変なことは？

などなど、リアルボイス満載です！ぜひ最後までご覧ください（＾＾）

専任PdMがいないなら、エンジニアが全部やる！

ー最初に、お二人の現在の担当業務を教えていただいてもよろしいですか？

🟦 O：
現在、スマレジのiOSアプリの開発を担当しています。メインはiOSエンジニアですが、兼任でCTO室にも所属していまして、プロダクトを横断した課題解決に取り組んでいます。

🟥 I：
私も同じくCTO室所属で、バックエンドを中心に担当しています。具体的にはプロダクトの立ち上げ補助や、大量データを伴う特定プロダクトの設計最適化や業務効率化にも取り組んでいます。

ー早速本題に入るのですが、自社開発においてPdMがいない体制は珍しいように思います。お二人は今の体制について、率直にどう感じていますか？

🟦 O：
現体制で特に問題はないですね。その分エンジニアが全部やることになるので、もちろん適任な方がいてくれたらいいなとは思いますが（笑）。

一般的にPdMの役割って、開発チームとコミュニケーションを取りながら、他部署との橋渡しをするようなイメージだと思うのですが、ただの連携だったらRedmine（タスク管理ツール）のチケット管理で十分ですよね。なので、必然的に開発チームとのコミュニケーションの比重が大きくなっていきますが、それなら別に人を立てるより、エンジニアが兼任しちゃった方がスムーズなんじゃないかなって。

現状、POS開発に関しては「PdMがいない」というよりは「PjMやPLが兼任してる」といった方が実態に近いと思います。POS以外のプロダクトでは、事業責任者が実質PdMの役割を担っている場合もありますね。その場合でも、開発と上下関係があるわけではなく、横並びで協調しているイメージです。

ープロダクトによっても少し異なるのですね。Iさんはいかがでしょうか？

🟥 I：
「PdM」という肩書きの人は現状いないですが、当然本来PdMが担う業務自体は存在するので、分割されながらも誰かしらがその役割を担うことになります。それがスマレジの場合、エンジニアが通常のPdM業務まで補っている、というイメージですかね。

僕もOさんと同じく、もちろん専任の方がいたらいいなとは思うのですが、実質開発と営業のリーダーを両方やるようなものなので、相当難しい役割だとは思います。部署間の伝言ゲームをするだけのPdMだったら、あまり介在価値がないですし。

🟦 O：
そうですね。実は以前、社内で専任のPdMを置いてほしいという声が挙がったこともあったんですよ。でも「専任にしかない価値を発揮できるほど、開発も営業も視座高く見られる人ってなかなかいないよね」という話になって。それで、一部のプロダクトは事業責任者がPdMとしての役割も担いつつ、大枠はエンジニアが上流から携わる今の体制に落ち着きました。

🟥 I：
エンジニアがPdM的な動きをするのは、とてもスムーズですし特に不都合はないと思っています。ただ、やっぱりエンジニアだけだと直接的な顧客接点が少ない分、他部署からの又聞きとか数字見てるだけだと実感を持ちにくくはあるんですよね。例えば「お客さんはこういう点につまづきやすいのか」とか「こういう問い合わせがよく来るな」とか。もし、そういった“肌感覚”みたいな部分を補ってくれる方がPdMとしていたら、心強いなとは思います。

上司への報告はほとんどなし？自由度高く働ける理由

ー専任のPdMが不在でも円滑に開発が進められる背景に、何かしら理由や秘訣があるのかなと思うのですが、いかがでしょうか？

🟦 O：
裁量が大きいというか、自由度が高い点は一つあるんじゃないですかね。スマレジはかなり自由にやらせてくれるなと感じます。

実際にどれほどかと言うと、リリース時の承認以外で役員（上司）と話すことがほぼないくらい（笑）。具体的には、営業やCSからあがってきたユーザー要望を踏まえて、機能追加することになったらリリース申請をするのですが、申請はほぼ承認されるので、それ以降は全部自分たちでやっているイメージですね。

もちろん、必要に応じて都度相談することはありますし、何か問題があれば「これ今どうなってる？」みたいに声をかけてもらうこともありますが、余計なマイクロマネジメントはないという意味です。

ー想像以上に任されているんですね。機能追加も現場判断ですか？

🟦 O：
そうですね。役員側から「この機能入れてほしい」みたいなお話をもらうこともありますが、基本的には各チームリーダーに最終決定権があるので、実施可否や優先順位を含め、現場で決めて進めていきます。

🟥 I：
スマレジの役員が技術畑なので、開発の理解度が高いからこそ現場に裁量権を与えられるというのもあると思いますよ。前職では上長がどちらかというと技術に疎い方だったので、開発の感覚を分かってもらうのに結構苦労していました。説得だけで1ヶ月とかかかるから「この時間あったら開発進められるのにな〜」とか思ってましたね（笑）。そういう労力は、スマレジではほとんどないので。

判断基準は、“ビジネスにおけるインパクト”

ーエンジニアの業務範囲がかなり広い印象を受けますが、工夫している点などはありますか？

🟦 O：
一般的にはPdMの業務なのかもしれないですが、ユーザー要望の優先順位付けが結構大変なので「要望シート」を作成して、営業側でユーザー要望のリストと営業としての優先順位を取りまとめてもらった上で、開発側で精査するようにしています。

ーどんな観点を意識して優先順位をつけているのでしょうか？

🟦 O：
実装に見込まれる工数だけでなく、ビジネスにおけるインパクトも考慮していますね。例えば「この機能を追加したらどれくらい成約につながるだろうか？」みたいな。実際に営業の場面では「この機能がないから」という理由で失注するケースも結構あるんです。

逆に「この機能なら、あってもなくてもあまり売り上げに影響ないのでは？」と感じる要望もあったりするので、そういった場合は営業の方に相談することもありますね。

ーなるほど、ビジネス感覚が求められますね。要望シートを介したやり取りは、以前からその運用なのでしょうか。

🟦 O：
もともとは各部門からの要望が、全て直接僕のところに集まっていたんです。それぞれ「〇〇をいつまでに欲しい！」みたいな感じに言われていたのですが、全案件ヒアリングするのは到底無理で。ちょうど2019年の軽減税率導入の時期に、僕の業務量が完全にパンクしまったのをきっかけに、役員との面談で文句を言い続けた結果、一旦営業側で取りまとめていただく運用に変えてもらいました（笑）。

ーそんな経緯があったのですね！Iさんは比較的入社して間もないと思いますが、前職と比較して感じることはありますか？

🟥 I：
前職ではリーダーの立ち位置だったので、割と裁量大きく動いていたとは思うんですよね。でも、スマレジは規模もそれなりに大きくて組織体制もしっかりしているのに、これだけちゃんと開発主導で進められているのはすごいと思います。

マネージャーだけでなく、メンバークラスも営業やCSと連携を取ったり、自分で情報を取りに行ったりしているので、業務の幅は広いのは間違いないかと。その分、広すぎてタスクが増えがちなところはありますね。

🟦 O：
あと、業務の幅が広いがゆえに境界線が曖昧なところもあるかもしれないです。どこまでやるべきかも自分で決めないといけないというか。

例えば、明確な境界がないので、実はSlack等で他部署のやりとりを側から見ていて、口を挟もうか迷ってる時もあります（笑）。営業メンバーが「こういう機能あったらいいけど、今回は開発に依頼するのは辞めておこうか」みたいなやりとりをしてたりすると「え、それ全然工数かからないからやるけどな......」などとひっそり思っていることもあったりして。

ー実は裏で見てるんですね（笑）。そういう時は、結局どうするのですか？

🟦 O：
実際は声をかけることの方が多いんですけど、その機能を追加したらビジネス的なインパクトがあるのかを考えるようにしています。そんなに大きなインパクトがなさそうだったら「まあいっか！」と思って見過ごしちゃいます（笑）。

情報がオープンなら、無駄な伝言ゲームは不要になる

ーその他、PdM不在の体制でも上手く機能するための特徴があれば、教えてください！

🟥 I：
Slackでのコミュニケーションが活発で、オープンに情報がやり取りされているので、他部署の動きを把握しやすい点もあるのかなと感じます。

前職では、ここまでオープンなコミュニケーションは取れていなかったのと、アナリティクスなどで得られた数字を見て議論する文化が強かったんですよね。スマレジはBtoBサービスなのもあり、数字ももちろん大事ですが、顧客との接点から得られる定性的な情報も重要なので、その辺りの情報がSlack上のやり取りから得られやすいのは特徴だと思います。

ー個人で情報が得やすい環境だったら、関係者間で伝言ゲームしていく必要もないですもんね。

🟥 I：
そうですね。ただ、その分自分で情報を取りに行く姿勢や習慣は求められますね。

🟦 O：
今は浸透しきっているオープンにコミュニケーションを図るSlackも、実はまだここ2〜3年くらいの運用なんですよ。以前はGoogleチャットを使っていたんですが、基本的にプライベートチャンネルしか使えなくて、その時は他部署の動きが全然見えなかったんです。それを改善しようとなってSlackが導入されたんですが、せっかく変えたのに最初の頃はみんな全然パブリックチャンネルでやり取りしてくれなくて（笑）。その頃と比べると、今は本当に他部署との連携がしやすくなったなと感じます。営業などの他部署の方にも「開発に情報を渡さなきゃ」みたいな意識を段々持ってもらえるようになったなと感じますね。

🟥 I：
僕も同じ経験があって、前職でまさにSlackを導入して情報はオープンにやり取りしようって推進していたんですよね。それで、一応形式上はオープンな状態に整えたんですが、やっぱりなかなか根付かなくて結局クローズになっていました（笑）。スマレジはリモートワークの方が多いのもあると思いますが、やっぱりSlack上のオープンなコミュニケーションがかなり活発だと感じますね。

自由度の高さと、体系化の両立

ー専任のPdMを置かずに、幅広い業務をエンジニアが担う良さもある一方、大変な点や課題もあると思うのですが、その辺りはいかがでしょうか？

🟥 I：
自由度が高いからこそ、ワークフローなどが定まっていなく未整備な部分もまだまだあるなとは思いますね。仕事を進めようとした時に、ワークフローが必要なのか、もし必要なら申請はSlack？DM？タイムカード（ワークフロー等を行える自社サービス）？などと迷ってしまうことも......。

先ほどの話と関連しますが、ある意味Slackを上手く使いすぎてしまってるんですよね。Slackのやり取りでなんとかなっちゃっているところがあるので、体系的に整備しきらなくても回ってしまうというか。

🟦 O：
開発部は社歴が長い人も多くて、属人化もやや強いのでその傾向はあるかもしれないです。例えば、各人がドキュメントを作成していても、集約できていないので結局見つけられなかったりとか。情報集約についての課題感はずっとあるので、最近だと全社的に社内wikiに情報を蓄積していこうという流れになっています。

ーありがとうございます。まだまだ課題はありつつも、PdM不在の体制でも十分に成り立つ理由がよく分かりました！最後に、読者の皆さんにメッセージを一言ずつ頂いてもよろしいでしょうか？

🟥 I：
先ほどの情報を自分で取りに行かないといけないという話にも繋がりますが、自由度が高いということは、その分自分で動かないといけないんですよね。なので、前例踏襲でやり続けるのではなく、新しいことに挑戦したり改善したりしていかないといけない点は、結構大変かもしれません。今ある課題に対して、自ら動ける方にはとてもマッチする会社だと思いますので、そういった方にはぜひ来ていただきたいですね。

🟦 O：
僕も同じく、基本的に指示待ちではなく自分で考えて動くのが好きな方には合う会社だと思います。むしろ「人に指示されるのが嫌い」という方、歓迎です（笑）。ぜひ一緒に働きましょう！

いかがでしたか？

今回の対談を通じて、PdMが不在でも問題なく機能する背景には、スマレジならではの業務プロセスや文化が大きく影響していることが分かりました！

役職や担当業務に縛られず、「エンジニアが全部やる！」のスタンスは、一人ひとりのエンジニアとしての経験値も高めるものだと感じます。

「境界線がないからこそ面白そう！」「枠組みに捉われずに経験の幅を広げたい！」

そんな風に感じていただける方のご応募を、心よりお待ちしております（＾＾）

〜おすすめの参考記事〜

▽スマレジの開発バリューが分かる！CTOインタビュー★

▽今回登場いただいたお二人が所属するCTO室の部署紹介！

▽スマレジエンジニアが連載する「Engineer's Voice」