笑顔で取材を受けてくださったのは自らを「子育てPM」と呼ぶ濱窄（はまさこ）亮介さん。資金調達がかかった大型のリリースを、それまでのプロジェクトの進め方を見直すことで見事に叶えました。その鍵は「3つの可視化」。いったいどんな改革をおこなったのでしょう。これまでのキャリアからそのプロジェクトの舞台裏まで、お話を聞きました。

「How」ではなく「Why」「What」を追求するPMを目指して

──まずはこれまでのキャリアから伺いたいと思います。もともとエンジニアをされていたとか。学生の頃からそのような勉強をされていたのですか？

大学では法律を学んでいたので、プログラミングには全く縁がありませんでした。同期には弁護士を目指す友人もいましたが、法律の道に進みたいという思いはありませんでした。そんな中、腕試しをしてみようとプログラミングのインターンに応募しました。大学の優秀な先輩方がそのインターンをなかなか突破できないのを見て、どれだけ難しいのだろうという単純な興味から受けてみたら、運良く入社パスをいただくことができました。

そのインターンでプログラミングの面白さを知り、そのままそこに就職するわけですが、上には上がいることを思い知ります。小学校の頃からプログラミングをしていたような筋金入りのエンジニアと出会い、またそういう人とペアプロを行ったりするうちに「これは勝てないな」と思うようになりました。一方でその会社で経験した企画の仕事には手応えがあり、これでキャリアを積んでいこうと考えるようになりました。

それで、二社目ではエンジニアではなく企画職を志望したのです。

──二社目のモバイルメッセンジャーアプリケーションを運営する会社では、今と同じPMの仕事に就かれていますね。

はい。その会社では大きく分けて2つのサービスのPMを経験しました。どれもやりがいのあるプロジェクトで、かけがえのない経験をさせていただいた一方で、社歴が長くなるにつれ、社内の人脈やお作法を使って仕事を回せてしまっている感覚が大きくなっていきました。また、自分のPMとしての責任範囲を広げてみたいと考えるようになり、転職を検討するようになりました。

──PMの責任範囲を広げるとは、どんなことなのでしょうか。

PMの責任範囲や定義は一定ありますが、その実態は会社によってさまざまで、いわゆる「How」のみの会社・部署もあれば、「Why」「What」のところもあります。2社目では「どんなサービスを提供したいのか」「どんな価値を届けたいのか」などの「Why」「What」はある程度固まっていて、実装方法や実現の仕方を考える「How」寄りのPMをしていました。けれど、実際に使ってもらえる・効果が出るサービスや機能は「Why」「What」の部分が根幹。そこにフォーカスできる環境に身を置くことが必要だと考えていたのです。

ドライに売り上げに貢献したい。
ちょっと珍しいオーナーさんへの愛情

──そこで出会ったのが STORES だったんですね。

STORES は、そのPMの責任範囲だけでなく、toBのビジネスモデルであることも相性が良いと感じました。2社目に転職した時はtoCがいいな、なんて思っていたのに、あらためて自分の思考の癖や得意なやり方を考えてみると、toBのほうが合っていると感じたのです。プロダクトを磨き込めばお客さんのメリットが売上になるというシンプルなビジネスモデルも気に入りました。

──その他に決め手はありましたか？

選考を通して出会った方々です。「こんな人のところではたらきたい！」と思わせてくれる方がたくさんいて、オファーを受ける時に「この方とはたらけるなら」とお受けしたぐらいでした。人間的な魅力も、僕が持っていないスキルも持っていて、きっと成長できると感じさせてくれた方たちでした。

──STORES には、入社の決め手にオーナーさんへの共感をあげる方も多いですよね。

それが、僕はちょっと違うタイプなんです。STORES には、特定のオーナーさんが大好きな方や、目を輝かせてオーナーさんの話をしてくれる方がたくさんいる。そんなみなさんを羨ましいなと思う一方で、僕のオーナーさんへの愛情はドライで少し一歩引いたものなんです。ドライに、マクロな視点でオーナーさんの売り上げに貢献できるのが僕の喜び。もしかすると社内ではちょっと珍しいタイプかもしれません。

──なるほど。読者の中にも、それに共感してくれる方もいると思います。

資金調達がかかった大型のリリース。
それを叶えた3つの可視化

──STORES Peopleでは、印象に残った仕事や、大変だった仕事をひとつ挙げていただいています。やはり「Google で集客」（以下、“Google Merchant Center 連携”の略称“GMC”）連携機能のリリースでしょうか。

そうですね。GMCのリリースと、それに至るための体制の見直しが印象に残った仕事です。きっかけは、直前のプロジェクトで、メンバーが「なんかこのプロジェクトの進み具合、不安になってきたな」とSlackに投稿してくれたこと。チームが停滞していることにアラートをあげてくれたのです。

──ヒヤリとしますね。

本当に、心臓がキュッとしました。「やべ」って。当時はまだチームに入って1、2ヶ月の頃。「入社してきたPMが全然ワークしていないぞ」と言われているようで「なんとかしなきゃ」と思いました。今となっては、その人は「人」に向かってではなく「コト」に向かって発言してくれたのだとわかりますが、当時はそんなことを考える余裕もないほどでした。

──それで、どうしたのですか。

ちょうど前任のPMが育休に入るところで人はいない。僕も育児があるので時間で解決するパワープレーは選択肢にない。あらためて状況を見つめてみると、「How」ばかりに目が行っていており、「Why」や「What」がおろそかになっていることにも気づきました。あれほど「How」のPMを手放そうとしていたのに、また同じ状況に陥ってしまっていたのです。

そこで、3つの可視化を行いプロダクトチームに「How」を委ねられるようにしました。「進捗」「役割」「タスク」の可視化です。今どこにいるのか、それぞれがどこまで意思決定すべきか、今やるべきタスクはなんなのか。それらを全て可視化し、権限委譲を進めました。

それまでのチームは、今自分たちが何に取り組んでいて、タスクがどのくらい進捗するかを確かめるのが難しい状態でした。そこで、進捗やタスクをいつでも確認できる共通のページを作り、定例MTGでもみんなで眺めながら更新する時間を作りました。僕はなるべく、みんなのコンパスになるようなイメージで動きながら、その運用が定着するのを待ちました。

──実際にどのくらいで定着したのでしょうか。

1ヶ月くらいでした。はじめは更新を忘れていたり、そのページを見にいく習慣がなかったりしましたが、次第に目線が揃っていき、明らかにチームの動きがよくなっていって。タイトなスケジュールにも対応できるようになっていきました。

──そのおかげで、GMCのリリースが叶ったというわけですね。それにしても大変なリリースだったと思います。

このリリースができたのは、今お話しした体制の見直しと、それによりチームが自発的に動いてくれたからに尽きます。着手してみるまでは全く未知のことばかりのプロダクト連携でしたが、Google側のテックサポートもクイックかつ丁寧でしたし、やりとりをドキュメントファイルに落とし込んだりとメンバーが工夫を凝らしてくれました。

最終的に予定よりも1ヶ月も早くリリースが叶ったのは、メンバーがこのプロジェクトの大切さを自分ごととして認識してくれてプロの目線で調査や提案、開発を進めてくれたおかげです。まさに「オールスター」の動きを目の当たりにした経験でした。

──濱窄さんご自身が乗り越えた「壁」はありましたか？

このリリースの如何が資金調達に結びついているという大きなプレッシャーを日々感じていました。もともと資金調達の前提となる事業計画にこのリリースが入っているということは知っていましたが、その規模や、会社にとって重要な時期であることも十分に認識していたので「間に合わなかったらどうしよう」と悪夢を見るくらいでした。僕自身がコードを書くわけではないので、エンジニアのみなさんが効率よく開発できるためにはどう立ち振る舞うことができるのか模索し続けていました。

無事リリースができたから言えることですが、振り返ってみるとそういう時期を体制づくりの工夫で乗り越えられたことはラッキーでしたし、こんな重要なプロジェクトを入社半年で任せていただいたことに感謝しています。

子育てもキャリアも。
心が満たされている今、目指す未来は

──大きなプロジェクトを終えられて、次に目指していることはあるのでしょうか。展望や、野望のようなものがあれば聞いてみたいです。

それが、あんまりないんですよ。今もまた重要な仕事を任せていただいていて、育児も大変ですが楽しんでやれていて。現状に満足しながら、STORES に転職してきた理由のひとつである「Why」「What」を追い求めるPMを突き詰めていけたらなと思います。

PMはチームのいく方向を指し示す重要な役割。チームや会社を良い方向に導いていくための判断の精度を上げるため、スキルを磨いていきたいと思います。

（写真・文：出川　光）

＼ STORES では一緒にはたらく仲間を募集中です！／