こんにちは、ヤプリの小野です。
「プロダクトマネージャーのお仕事」シリーズ、4回目の記事です。前回の記事はこちら。

私は、ノーコードのアプリ開発プラットフォーム「Yappli」のプロダクトオーナーを務めています。同時に、プロダクト開発本部の中で開発企画部という開発の上流工程の企画・設計を担う部署の部長でもあります。
そんな私がヤプリでどんな仕事をしているかは、少し前の記事になりますがキャリアハックさんの『「ヤプリ」グロース徹底解剖！ コロナ禍にも強い、SaaSプロダクトの戦い方』の記事をぜひご覧ください。

さて、部長という役職柄、自部門のメンバーの採用業務にも携わっており、多くのプロダクトマネージャー（以下PdM）や今後PdMを目指している方々とお話する機会があります。
そこで多くの方から、様々なプロダクトマネジメントの悩みや迷いをお聞きします。今日は、そんな悩みに対してヤプリではどのように取り組んでいるか、よくあるケース3つとそれを解決したアイデアにわけて紹介していきたいと思います。

CASE1 - 『改善が一向に進まない』

時期：会社としては5年目
従業員の数：50〜100人に満たないくらい、開発組織は30人くらい

事業が本格的に回ってくると、導入企業の数も増え、利用者の数が増えるとともに製品の不具合なども少しづつ目立つようになってきます。常にどこかの不具合対応に駆り出されて、なかなか物事が進まなくなってきます。

改善に集中する「YappdateDay」

とにかく改善をする時間を確保しようということで、立ち上がったのが「YappdateDay」。開発部門がその日だけは日々のプロジェクトの手を止めて、改善に専念するという取り組みです。

YappdateDayは、毎月2日間（全体のおよそ10％は、改善する時間として確保している計算）実施しており、年間数百件のプロダクトアップデート（今年も既に400件を越えています）を支えるヤプリのカルチャーとして、5年経った今でも、欠かさず毎月開催されています。
詳しい取り組み内容については、ぜひ下の記事をご覧ください。

全社でやること（やらないこと）を決める「ヤプリク」

もう一つは「ヤプリク」です。ヤプリクは、全社員から寄せられた開発アイデアから優秀なアイデアを選び抜くプレゼン大会です。どんな取り組みかは過去の記事をご覧ください。

社員の皆さんから寄せられる開発要望の数も膨大になり、優先順位をつけるのも一苦労。良い開発アイデアであれば取り組みたいが、前述の改善の手も止めたくない。無理してなんでもかんでも取り組むと結果的に品質が下がり不具合も多発する。そうすれば結局また開発が止まってしまう。というわけで「ヤプリク」は全社員で、やること（ともすればやらないこと）を決める、全社でプロダクトをどうすべきかを判断することに一役買っています。

CASE1からの学び

というわけで、CASE1の対策は、改善は鉄の意志をもって、やると決めたらやる。「YappdateDay」のように取り組む時間を確保し、「ヤプリク」のような優先順位つける機会を設けてやること・やらないことを全社でコンセンサスをとる。というのがとても効果的です。

CASE2 - 『開発プロジェクトが遅延する』

時期：会社としては7年目（丁度この頃、本社も六本木一丁目に移転）
従業員の数：150人くらい、開発組織は50人くらい

導入企業も増え、さまざまな業界・用途で利用されるようになり、それに伴い、個々の企業のニーズに合わせる必要性も高くなってきます。例えば、外部システムと連携する必要があるケースや特定企業向けの開発が必要となるケースなど。そのような状況では、短期間での開発や稼働中のシステムへの問い合わせ対応が不定期に発生し、多くのエンジニアが開発プロジェクトとそれらの業務を兼任して担当することになります。

このような状況の場合、緊急性の高い開発業務に時間を取られ、重要度は高いけど緊急度は高くないという大規模なプラットフォーム改修など、進行が滞りがちになります。
ここで少し頭を悩ますのは、遅延する要因となった作業も大切な作業で、「それだったら仕方がない」という雰囲気が会社全体に漂い、誰も特定の責任を感じていない空気になります。
でも肝心なのは、開発が遅れている事実には代わりはないということ。ここで課題を棚上げしてしまうと、頑張っているのになかなか成長しないプロダクトになってしまいます。

緊急性の高い案件を専門に対応する「遊撃チーム」

ここで、取り入れた取り組みが「遊撃チーム」です。
遊撃チームは、個社別の開発対応、不具合等の問い合わせならびに不具合改修など、緊急性の高い業務に取り組む専門チームです。特徴的なところはこのチームのKPIには、問い合わせの対応速度・解決までの時間だけでなく、問い合わせを溢れさせず、大規模プロジェクトのチームのメンバーが不具合改修対応に駆り出されないという、遅延要因を作らないというKPIを持っています。

この「他方のプロジェクトを遅延させない」というのは、なんとも正義感溢れるミッションで、多くの開発チームが、遊撃チームに足を向けては寝れない。というのは他でもありません。
大規模プロジェクトの開発チームへの刺激にもなって、遊撃チームの活躍に応えようという空気も醸成されて、とても良い取り組みになっています。

CASE2からの学び

CASE2の対策は、遅延要因を徹底して排除する。「遊撃チーム」の活躍によって遅延の要因を排除し、開発プロジェクトも他責要因による不可抗力な遅延が起きなくなり、この取り組みも非常に効果的なプロダクトを着実に成長させるためのよい取り組みになっています。

CASE3 - 『中規模の改善が動かない』

時期：会社としては9年目
従業員の数：200〜250人くらい、開発組織は70〜100人は満たないくらい

さて、改善も進むようになったし、大規模開発も遅れずに進行できるようになり、順風満帆…。
と思いきや、改善といっても規模は様々で、「YappdateDay」で取り組むには大きすぎて、とはいえCASE2のような大規模というほどでもない、そんなに大きくはないが、やるとなったらそこそこ人手がかかるという、中くらいの規模の課題が、なかなか消化されないということが新たな悩みのタネとなったのがつい最近。
（わかってはいるけど、手がつけられないんですよね…。）

中規模改善を専任に取り組む「ideabox1000」チーム

ということで、新たに立ち上げた取り組みが、「ideabox1000本ノック（通称 ideabox1000）」。ideabox1000は、ヤプリクのために寄せられた開発アイデアを投票窓口「ideabox」を1000本ノックのごとく、チームでどんどん開発してリリースしようという目的で作られたタスクフォースチームでPdMとエンジニアの少人数で構成されています。
これまでは、ある程度の規模の開発は、経営サイドとコンセンサスを取りながらやることを決めていたのですが、そうすると規模が中途半端のものはなかなか開発計画に採択されずらいという傾向がありました。そこで、これまでのヤプリの開発計画の策定サイクルを度外視して、中規模のものはこのチームに預けて、やるやらないの判断から、仕様策定、開発までを一貫して取り組むチームを組成しました。

CASE3からの学び

CASE3の対策は専任のチームを立ち上げて、そこで意思決定もできるようにする。「ideabox1000」の取り組みはプロダクトの満足度の維持・向上の一翼を担っています。

まとめ

ざっとこれまでの3つをまとめてみると上の図のような形で、それぞれの時代ごとで課題は異なり、徐々に成長していったことがわかります。まずは課題（悩み）を特定して、解消するためにどのような状態にする必要があるか、その状態にするにはどんなアクションが必要かを順を追って詰めていくことで、意外となんとかなるものです。

さいごに

長文失礼しました。最後までお読みいただきありがとうございます。
ほんの少しでも日々の仕事のヒントになれたら幸いです。

この記事はヤプリのAdvent Calender 2023の22日目の記事にもなっています。プロダクトマネジメントだけでなくヤプリのその他のプロダクトチームのメンバーの記事も多く掲載されているので、ぜひ他の記事もチェックしてみてください。

この記事でヤプリのPdMやそれ以外の職種にご興味をお持ちいただけましたら、Tech Blog や採用サイトもぜひご覧ください！
Yappli Tech Blog
カジュアル面談