AIを教育系プロダクトに爆速で組み込んだPOが心がけてる25のこと
みなさんこんにちは！
グロービス学び放題でPOをやっている前嶋です。
今はPOをやらせてもらっていますが、元々は生粋のデザイナーです。
※元ヤフーデザイン責任者。グロービスに入社してPOをやるようになった。
話を戻すと・・。
私たちは2023年度1Qで、「振り返りAIフィードバック機能」をリリースしました。 それを皮切りに、「AI書き起こしによる字幕機能」の実装。 「自由記述QuizにAIフィードバック機能」を実装。
6月23日には「AIと学ぶ」機能をリリースしました。
https://prtimes.jp/main/html/rd/p/000000111.000052928.html
世間的にも、ChatGPTを中心にしたAIが色々なプロダクトに実装されていることもあり、 社内、社外でも割に好評です。（2023年6月現在）
とくに「AIと学ぶ」はグロービスの知見を入れ込んだプロンプトを踏まえて、専用のコースで学習ができるので大変好評をいただいています。
これらはグロービス学び放題でも、Beyond Experienceチーム（以下BXチーム）が中心になってリリースしました。
→私はBXチームのPOです。
BXチームは、「Beyond動画学習」をミッションにしています。
グロービス学び放題は「動画学習」がメインです。
つまり、わたしたちは次の体験を作ろうとしています。
そのため、スピード感をもって色々な仮説をユーザーにぶつけている最中です。
→前述のAIと学ぶなどもその１つです。
BXチームのメンバー構成は下記の通り。
iOSエンジニア（1名＝チームリーダー）
デザイナー（1名）
FE（1名）
BE（1名）
わたし
今回は「AIを教育系プロダクトに爆速で組み込んだPOが心がけてる25のこと」のことをお伝えします。
1つ1つはカンタンなものです。
同じようにPOとしてお仕事されている方にとって、
一つでも参考になればうれしいです。
マインド
1.みんなちがってみんないい
ヤフー時代にお世話になった師匠、伊藤羊一さんの言葉です。
私はPOの価値を「チーム全員の能力を最大化させること」と定義しています。
そして、結果的にプロダクトがよくなればいい。 プロダクトが良くなればPOの枠なんて関係ないんです。
だからこそ、メンバーそれぞれが持つ、専門性やキャラクターをリスペクトする。
そんな前提にたって仕事をしています。
２．マイルールを持つ
私は1000冊以上の本を読んできました。
そして、本を読んでわかったことが1つあります。
それは成功者は、必ず「ルール」を持っているということ。
「習慣」が人生を変えるように、「ルール」は仕事を爆速化します。
ルールを持つことで、都度判断しなくて良くなります。 その結果、意思決定のスピードがあがります。
3.アンコントローラブルな要件で悩まない
悩んでも何も生まれません。大事なのは「考えること」
とくにPOは多くの関係者とやり取りをします。
悩まなくていいことに脳のリソースを使うのは避けましょう。 →1日で判断することができる脳のリソースは決まってます。 スティーブ・ジョブスやマークザッカーバーグが、脳の負荷を下げるために同じ洋服を着てたのは有名な話ですよね。
大事なのは「コントロールできることの"決断”に全力を注ぐことです。」ことです。
4.ポジティブ
「うわ・・つらいな・・」と思うよりは、「今が成長のチャンスだ！」と捉えるほうがいい。
プラスもマイナスも自分自身で考えているだけです。
自分自身で前向きに考えるだけならタダでできますｗ
どうせなら前向きに考えてみませんか？
とはいえ、POとしては「リスク」を正確に捉えることがとても大切です。
前提として、リスクの洗い出しなどやることをやった上で「ポジティブ」にプロジェクトを進めていきましょう。
5.「◯◯と思う」という言い方は極力避ける
私は言葉をできるだけ言い切るようにしています。
◯◯だと思うという方がとても多いですが、
これは間違えていたときの保険をかけた言い回しだから言葉が弱くなります。
自分の保身のために保険をかけるより、POとして明確な意思表示をすることを大切にしています。
→その方がメンバーが動きやすいため
判断間違えてたら怖い・・という方もいらっしゃいますが、判断は間違えててもいいんです。
大切なのは、成功にせよ失敗にせよスピーディーに軌道修正をしていくことです。
6.一次情報で判断する
ご存知のとおり、POは自分の意志を明確に表明することが大事です。
なぜなら、判断しないとタスクが次にすすまないからです。
できるだけボールは自分で持たずにすぐに打ち返す。
その際に、聞いた情報（二次情報）ではなく、（できる限り）直接情報を拾いにいきましょう。
自分で調べた情報で決めた判断なら、たとえ間違えていても後悔しないはずです。
7.多数決は信用しない
多数決を信用していません。
なぜなら、多数決で出た結論は玉虫色になりがちです。 みんなで決めた決定は、想いが分散されて弱い意思決定になりがちです。
意思決定はには強い気持ちが大事です。 それには強い意志が込められていることが大切です。
8.朝令暮改はいいこと
わたしたちは動画学習の「次の学習体験体験」を探求するチームです。
そのため、スピーディーに実験を繰り返しユーザーにぶつけながらデータを貯めてます。
やってみないとわからないことも多いので、当初の方針を覆すこともしばしばあります。
間違えてたらすぐに方向転換をする。
下手に遠慮して間違えた方向で走り続けることは絶対に避けるべきです。
メンバーに遠慮せずに、間違えてると思ったらすぐに方向転換をしましょう。
9.心理的安全性を担保する
どんな施策も、「失敗」は存在しない、が持論です。
→重要なのはうまくいかないときのリカバリー。
だから失敗を恐れるチームは絶対に避ければなりません。
なぜなら、ユーザーに価値を与えるには行動するしかないためです。
そして、BXチームは新しい価値を出すので正解は試してみないとわかりません。
色々試す段階では当然失敗もします。
でも失敗を恐れていたら、そもそも打席に立つことすらできません。
だから、失敗の不安をできるだけ消す必要がある。
ここはグーグルにならって、心理的安全性の担保をしました。
私たちのチームでも、バグが原因でリリース直後にロールバックしました。
担当のエンジニアは気にしてましたが、みんなで「ナイスチャレンジ」と、ポジティブに声をかけあいました。
大事なのはユーザーに、いち早く価値を提供することです。
失敗を恐れてプロダクトを完璧にしすぎたらいつまでも価値提供はできません。
10.巻き込む
キングコングの西野さんが、応援してもらうには目的地と現在地の共有をすることが大事だと言っています。
チームをPOとして運営する上で、大事にしていることが目的地の共有です。
それを踏まえて、我々はこれができてないから一緒にやっていこうとチームでよく話しています。
→ときにチーム外の人にも言ってる。
人は指示されたことより、自分自身で意思決定をしたことのほうが積極的に取り組めますよね。
情報は極力シェアしながら、目的地をみんなでシェアして、開発のパフォーマンスを最大化しています。
案件
11.成功事例をパクる
世の中には何度も実験してうまくいった事例がいっぱいあります。
当たるか当たらないかわからないオリジナルの施策ではなく、成功事例を参考に施策を考えています。
ただ、そのまま流用することはしません。必ず、施策の本質を議論して重要な部分を転用するようにしています。
→ここが超大事。
12.中の人がワクワクする施策をリリースする
プロダクト開発の優先度は定量・定性両面から判断するのが王道ではありますが、中の人がワクワクする施策の優先度も積極的にあげてます。
どうせ作るなら、自分たちが使いたくなるようなプロダクトを開発するほうが、ワクワクしていいですよ。
13.Whyを伝える
メンバー全員に意思決定の意図を丁寧に説明しています。
もしくは話し合うようにしています。
メンバーのみんなが、タスクをこなすのではなく、その結果、
どんな未来がまっているのか？その意義を伝えるようにしています。
14.あいまいにしない
POはエンジニアを始め色々な職種のメンバーと会話をします。
わたしはデザイナー出身のため、エンジニアの専門知識はありません。
ときにわからない言葉が出てきた時に必ず確認するようにしています。
知ってる言葉でも、「ちょっとニュアンスがちがうかも？」と思ったら確認しています。
あいまいにしておくと、あとで痛い目にあうので要注意です。
15.リリースにこだわる
できる限りこまめにリリースするようにしています。
プロダクト開発はリリースしないとユーザーに価値提供ができません。
作って作ってじっくり出すくらいなら、フェーズを切って最低限の機能でリリースしたほうが早く価値提供できます。
リリースにはとてもこだわっています。
実際担当プロダクトもフェーズを細かく切ってリリース回数を増やしています。
一方で、慎重に品質を上げてからリリースをするケースもあります。
これはユーザーへの影響を慎重に判断して決めています。
コミュニケーション
16.話す相手の名前を呼ぶ
一緒に働くメンバーの名前をできるだけ呼ぶようにしています。
名前は一人ひとりにとって特別なものです。
それぞれに合わせてカスタマイズしたコミュニケーションを意識しています。
すべてのやり取りのベースは前述の通り心理的安全性を確保した上です。
17.すべてのことに感謝する
何事にも感謝するようにしています。
それがクレームだとしても、バグだとしても、認識した時点から改善ができます。
当然、ユーザーの方に迷惑をかけた事自体は反省すべきです。
繰り返してはいけません。
ただし、バグやクレームがゼロのプロダクトを作ることは不可能です。
だからこそ、バグやクレームが発生したこと、認識できた事自体はすばらしい。
前述したとおり、バグがありロールバックした際にもエンジニアの方には、みんなでポジティブなフィードバックをしました。
何かあったときに言い出せないことは絶対に避けるべきです。
言って文句を言われるチームより、それを受け入れて「NextAction」を考えていけるほうが圧倒的に建設的です。
18.大きなリアクション
弊社のプロダクトチームはほぼリモートで作業しています。
ミーティングもおおいのですが、リアクションが希薄な人が多いです。
会議で自分の意志を表明する時、相手がどう受け取るか気になりませんか？
賛成なのか、反対なのか。
賛成なら笑顔で大きく頷いてみる。
反対なら、悩ましい顔で聞いてみるなど、きちんと反応することを大切にしています。
そうすることにより、より深い議論ができています。
19.チーム外への説明は丁寧に
プロダクト開発には色々な関係者がいます。
プロダクト開発はリリースするだけでなく、それをメールでお伝えしたり、
その機能に関してユーザーの方から問い合わせをいただくこともあります。
それらの担当者にもきちんと機能について説明をするようにしています。
とくにアイデアはプロダクトサイドではでないようなヒントをいただくことも多いです。
様々なチームへの説明や連携はとても大切にしています。
20.一緒にやってる感を出す
個人的にPOの仕事は「メンバーのパフォーマンスを最大化することだと定義しています。
」
一人で考えるより、みんなで考えたほうが色々なアイデアが出ます。
考える人と作業する人を分けてしまうと、もったいない。
だから情報はできるだけシェアして一緒に考えて開発を進められる雰囲気作りを大切にしています。
メンバーの方を作業者にならないように気をつけています。
21.みんなが自分より優秀だという前提にたつ
私は頭が悪いです。
庶民的なスキルしかないので、あまり自分を信用していません。
一方で、チームにいるメンバーの方は優秀な方々ばかりです。
この前提にたつと、色々なアイデアをフィルターなく受け入れることができて、判断がしやすくなります。
22.どんなアイデアも一度受け入れる
いきなり否定されると嫌な気分になりませんか？
とはいえ、POとしては判断をして意思決定をしなければならない。
伝え方を間違えると、メンバーもモチベーションが下がり
チームとしてパフォーマンスが下がってしまいます。
まずは意見を受け取って「そう考えてるんですね」と受け入れるようにしています。
人には誰しも認められたいう欲求があります。
その上で、議論をしていくと前向きな議論ができます。
23.伝わってないのは自分のせい
POとして働いていると、依頼して何かをしてもらうことが多いです。
→例えば、開発要件を伝えて開発をしてもらうなど。
その際、こちらの意図通り伝わらないことも多いですよね？
→少なくとも私はよくある。
この時に必ず自分に原因があるという前提にたつようにしています。
相手に原因を求めても、認識するかしないかは相手の課題なので、
いつまでもストレスがつきまといます。
一方自分に原因があるという前提にたてば、
自分自身の伝え方を改善すればいい。
つまり、自分がやれば改善できます。
このように、自分軸で変えられる事にフォーカスすることを大切にしています。
したたかさ
24.やってる感の演出
自分たちの成果は積極的に発信するようにしています。
「きっと誰かが見てくれているはず・・！」とつい期待してしまいますが、
みんな忙しいです。
私達のチームは2023年の4月に新設されたチームでした。
しかも新しい学習体験をつくるという「ふわっと」したものを求められてました。
なので、未来の話をして何もリリースできないという状態は絶対に避けたかったのです。
→よくありがち
できる限り途中経過もシェアしてましたし、
実際リリースしたときに周知はすごく盛り上げました。
あと、細かい技としては・・
リリース周知はSlackを使ってます。その際に「スタンプ」を自作自演で過剰に押していますｗ
こうすることで、他の人もスタンプを押しやすくなるし盛り上がってる感が出せますｗ
25.スピード感
私たちのチームはチーム立ち上げて1ヶ月立たないうちにAI系のプロダクト開発をリリースまでもっていきました。
弊社は4月は期初であり、ミッションを大事にする社風です。そのため、4月は議論をしながらどんなことをしていくかに時間を割くことが多いです。
そんななか、4月にリリースをしたことで、「開発が早いチーム」ということが社内で認識されました。
この社内ブランディングのお陰で、今でも「開発が早いチーム」と認識されています。
大事なのは一番はじめです。
始めに早い印象をもってもらえば、その後は多少おそくても大丈夫です。
それくらい最初が重要です。
そのためにやるべきことはやっていました。
新チームは3月の時点で決まっていたので、早めに作戦会議をみんなでやって4月にリリースしようとすり合わせをしていました。
POとしてどんなチームにしていきたいか。
どう認識されたほうがいいか？
それを考えることで、社内での立ち回りがしやすくなります。
まとめ
以上、25個。
私がPOとして、爆速でAIサービスをリリースした際に気をつけたことです。
今回はスキルについては特に触れてません。
POとして大事なことはマインドやコミュニケーション、 そしてしたたかさであると感じるからです。
POはこれをやれば正解ということがなかなか定義し辛い職種なので、
日々色々模索しながら仕事をしています。
同じようにもがいているPOの方の参考になれば嬉しいです。
この記事が気に入ったらサポートをしてみませんか？