Teachme Bizの4つの開発チームのうち、基本機能強化チームを指揮するプロダクトマネージャー（以下：PdM）・東 亜綾乃さん。

前職ではQAエンジニアだった東さんは、2019年にPdMとしてスタディストにジョインし、スキルと経験を一から積み上げ、今ではスタディストに欠かせないメンバーへと成長しました。チームメンバーに丁寧に寄り添いながら案件を着実に形にしていく、その調和と推進力を両立させるスタイルはどんな考えや経験から生まれるのか、東さんにインタビューをしました。

＜プロフィール＞
開発本部　プロダクト部　プロダクトマネジメントグループ
東 亜綾乃（ひがし あやの）
主力事業であるTeachme Bizにある4つの開発チームのうち、比較的大きな規模の案件を扱う「基本機能強化チーム（通称：キリンチーム）」のプロダクトマネージャー。案件選定から課題の特定、機能の価値検討、実装、リリースまでを一気通貫で指揮する。

スピード感と納得感。PdMとして心がけていること

——入社以降、携わってきたことを教えてください。

スタディストには開発チームが4つあって、入社後すぐは勉強もかねて小規模改善のチームに配属されました。小規模改善とは、「エラーメッセージの日本語がおかしい」「ボタンの使い勝手が悪いから設置場所を変える」など、課題から解決策がわりと見えやすい機能改善のことです。1年目はひたすらそれを繰り返しながら、講座にも通わせてもらい、PdMの役割と仕事を学ぶ日々でした。

2年目になると急に難易度が上がって、中規模案件を任せられるようになりました。「詳細版レポート」や「ユーザープロビジョニング」など、難易度が高く、規模の大きな案件も乗り越えて、PdMとして安定感が出てきたかな、と感じるようになったのが3年目に入る頃。

3年目は、会社の状況的に「これまでに集積したお客様からの要望を、とにかく多く早く解決する」というフェーズだったので、2年目よりも案件規模は小さくなりましたが、その代わりスピード感が求められるようになりました。

そして4年目は、これまでで一番大きな規模の案件にも挑戦して、現在に至るという感じです。

——期間や規模がさまざまなプロジェクトに携わってきた東さん。まず、小規模改善の案件に携わる上で、PdMとして心がけていたのはどんなことでしょうか？

スピード感が求められていた3年目は、「各担当が業務を引き渡すリードタイムを短くすること」を意識していました。

PdMやデザイナーが仕様を決め、エンジニアに依頼して……というプロセスを踏んでいると、どうしても内容を確定しきってからでないと、エンジニアが作業に入れないので、若干ロスが出てしまう。そうではなく、価値検討からエンジニアにも入ってもらい、設計や技術選定を並行して取り組んでもらうなど、決まった部分から実装を始めてもらっていました。

——内容が詰まりきっていないがゆえの手戻りが発生しやすい気もするんですが、その場合はどうしていたんですか？

そういう場合もありました。なので、あらかじめ「このフローだと、最初に決めたことが後から難しいと判明する場合がある。それを受け入れる心構えでいよう」とメンバーには伝えていました。それを恐れていたら、スピードがとれないので。

ただ、なるべく手戻りを減らすために、デザイナーやエンジニアと密にコミュニケーションを取り、各段階で「懸念点はあるか？」と色々な視点で意見を出してもらい、合意を取ってから進めるようにしました。それが結果として、「手戻りが出たとしても仕方ない」というメンバーの納得感にも繋がっていたと思いますし、いざ方向転換が必要になった際のスピード感にも繋がったかなと。

——次に、中規模改善で心がけていたことはどんなことでしょうか？

中規模～大規模案件になると、今度はお客様が抱えている課題への解決策を、自分たちで見つけなければいけないので、難易度が格段に上がります。課題も、お客様によって内容も違えば、規模も違うし、業種も違う。そこにどんな“答え”を出すのか。それも、私一人ではなくチーム全体で考えていくようにしていました。

PdMが主導して決めたことを、エンジニアやデザイナーに振り分けていくケースもあると思います。だけど私は、メンバーに納得感が醸成されるようなプロセスを組むのが大事だと思っているので、PdMとして意思決定する必要性もありますが、まずはエンジニアやデザイナー、QAも含めて、チームで解決策を話し合い、決めていきます。

これは肌感ですが、弊社のエンジニアはとくに“納得感”を大切にする方が多い印象があるので、「何のために」「この機能で誰がどう嬉しいか」を明確にして、プロジェクトを進めるようにしています。

——「マニュアル」というテーマについては、どう感じていますか？

前職では、給与計算系のソフトを作っていたので、例えば税率や法律に変更があると、施行日までに改正内容に対応した機能をリリースしなければお客様側が法律違反となってしまいます。それだけは絶対に避けなければいけない、そんなプレッシャーがありました。その代わり、法律などで用語や公式的な見解が示されているので、携わる上で言葉の扱いや認識を統一しやすいという面もありましたね。

マニュアルはそれらと逆で、納期に対しては機能改善は開発部起点なので、スケジュールはあくまで自分たちが設定しています。Timeboxという形で開発期間の目標を置いてはいますが、開発が遅れたとしても法律的にお客様に迷惑をかけるリスクは少ないため、機能のベストを追いかけられるという点では気持ちにゆとりがある気がします。

ただ、「マニュアル」自体の難しさは大きいと感じますね。人によって思い浮かべるイメージや役割が違ったり、周囲にある言葉の定義が曖昧だったり。クライアントの要望を正確に拾い上げることの難しさや、議論を重ねる上でまずその認識統一を図らなければいけないという難しさがあります。

開発とビズをつなぐスプリントレビュー、はじめ方と浸透の工夫

——東さんは、スタディストで「スプリントレビュー」を取り入れたと聞きました。背景や取り組の詳細を教えてもらえますか？

これは入社してから2年ほどで企画したんですが、当時、開発側とビズサイドの連携があまり取れておらず……。開発主導で作るものを考えて、極端に言ってしまえば勝手にリリースしているような形でした。

ただその形だと、機能のリリース後にビズサイドから、「思ってたのと違う」「なんでこの仕様になっているの？」とか、マイナスのフィードバックが出てくるようになってしまっていて。それを不健全に感じて、始めたのが「スプリントレビュー」でした。

スプリントレビュー
週1回1時間行われている、スタディストのきりん（基本機能強化）チームとCREチーム合同主催のMTG。開発チームが取り組んでいる新機能や機能改善について、Bizサイドメンバー、他開発チーム、プロダクトサポートチームなど全社に共有。様々な視点からフィードバックをもらい、より価値を高めた状態で顧客に機能リリースを行うことが狙い。※スクラムのスプリントレビューを参考にしたため名前が同じになっていますが、スクラムのガイドラインに厳密に沿った運用にはなっていません。

——今では平均20名以上が参加する取り組みと聞いていますが、みんな最初から参加してくれていたんですか？

いえ、当初はビズサイドのメンバーを招くことに対して、開発側のメンバーの抵抗感が強くて……。「何を言われるかわからない」「怖い」といった意見が多かったです（笑）。

だから最初はなかなか腰が重いメンバーが多かったように思います。ただ、デモを動かす時、どうしてもエンジニアに手元で動かしてもらわないとレビューできないものもあって…「質疑応答とか全部私が引き受けるので、なんとか操作だけお願いします…！」と話して協力してもらいました。

——そんな状態から、どうやって参加者を増やしていったんですか？

開発側があまり乗り気ではないところからのスタートだったので、はじめはプロダクトサポートなど、ビズサイドと開発側の、ちょうど中間にいるようなメンバーを呼ぶことから始めて、ちょっとずつ規模を広げていきました。必ず、「誰でも来ていい場ですよ！」と告知をしながら。

やっぱりみんなが参加してくれないことには、取り組みをしても意味がないので、反応は気にしつつ、少しずつ段階を踏んで広げていった感じです。

そうしたら、ビズサイドから「めっちゃいいじゃん。なんで出ないの？」って他のメンバーを誘いながら参加してくれるファンのような人が増えてきて、徐々に今みたいな規模になった、という感じです。

ビズサイド的には、お客様にとって必要な意見はきちんと機能に反映されるのに加えて、リリース前から新機能の情報がキャッチアップできることでより早く商談に活かせたり、提案の幅が増えることがメリットになったようです。

スプリントレビュー開催お知らせSlack　最近は参加しやすいようお昼休みに開催すること多め

——開発側とビズサイドをつないでいかれたんですね。

そうですね、そうできていたら嬉しいです。結果的に、当初不健全だと思っていた機能リリース後にビズサイドから出る、「思っていた機能と違う」などのマイナスなフィードバックはなくなりました。

むしろビズサイドからは、お客様目線で「こういう場面でお客様が困るかも」というポジティブなフィードバックが出てくるようになって、プロダクトの質が上がったり、製品に還元できるようになってきているので、自分でも取り組んで良かったと思っています。

振り返ると、ずっと“挑戦”があった

——QAエンジニアからPdMがやりたくて転職してきた東さん。やりたいと思っていた仕事は、今できていますか？

そうですね。前職時代にQAエンジニアをしていた頃は、モノづくりの最終工程としてプロダクトの品質を担保する、いわゆる最後のケツ持ちみたいな役割でした。そこから逆に、モノづくりの入り口、つまり「課題に対してどんなプロダクトや解決策を考えられるか」ということに興味を持ち、スタディストに入社したんですね。

さっき話したとおり、お客様の課題に向き合って自分たちなりの“答え”を探していく時に、当時思い描いていたPdMの仕事に、今向き合えているという実感が湧いてきます。もちろん、その“答え”が間違っていることもあるかもしれません。だけどPdMの世界、とくに新規事業では「1000個試して当たるのは3つぐらい」と言われるほど、失敗するのが当たり前。PdMになってから、失敗は経験として積めばいい、と思うようにもなりました。

——「失敗が当たり前」、すごく大事な姿勢ですね。でも失敗するというのは、東さんがちゃんと挑戦しているからでもありますよね。

うーん……自分では、そういう自覚はなくて（笑）。

任せてもらえる仕事がどれも面白そうで、誘いを受けて「やります！」と返事することは多いですね。「やりたい」と手を挙げれば任せてもらえるし、手を挙げなくとも挑戦の機会をうまく与えてくれる。スタディストには、その両面があるのがすごいなと。

あまり積極的なタイプではない私でも、振り返るとずっと「挑戦」が当たり前だった、という気がしています。

——最後に、今後どんなPdMになっていきたいですか？

入社5年目を迎えて、一定の実力は付いてきたと自分でも感じているので、今後はどんな案件でも任されたものを確実に、そして早く仕上げていく、よりプロといわれる存在になっていきたいと思っています。

ただ、PdMは一人で案件をリリースできるわけではありません。チームメンバーの力があってこそ。これまでもチームメンバーが動きやすいように環境を整えて、快適に仕事ができるようにするのがPdMの仕事のひとつだと思って意識してやってきましたが、それは今後も変わらないのかな、と思っています。