ジョブ理論を活用する難しさについての雑記
プロダクトマネージャーの方々であれば、「ジョブ理論」を一度は耳にしたことがあると思います。
自分は以前、クレイトン・M・クリステンセン教授が著した書籍「ジョブ理論」を読んだ学びと、UX DAYS TOKYO 2018のJim Kalbach氏のJobs To Be Doneのワークショップにて得た学びを、こちらのスライドにまとめました。これが結構ご好評をいただいていました。
こちらを先日少しアップデートしてツイートしたところ、興味を持っていただいたギルドワークスの@yohhatu さんからお声がけいただき、ジョブ理論の活用についてお話させていただきました。
この記事では、そのお話の中で盛り上がった「ジョブ理論を活用する難しさ」について備忘録的に書いていきます。
そもそもジョブ理論とは
↑のスライドをご参照ください(･∀･)
よろしければ感想をツイートしてください(･∀･)
その1：ジョブを見つける、評価する難しさ
書籍「ジョブ理論」の中で、ジョブは主にインタビューや観察にて見つけるとされています。つまり主に定性データを元にジョブを見つけていく必要があります。
個人的な考えですが、この定性データ分析には人間の思い込みやバイアスが大きく影響します。つまりインタビューで出てきたいくつかのジョブ候補に対して、フラットな評価が非常に難しいと考えています。
例えば、既に多くの時間をかけてある程度自信のある仮説ができてきた中で、その仮説に全く当てはまらないジョブ候補が出てきたときに、無意識のうちに「これはレアパターンだ」と捨ててしまうリスクがあります。これが定量データだと数字で顕在化するので無視しにくいのですが、定性データは分析・整理の過程でいくらでもバイアスを潜り込ませることができるので、より無視してしまうリスクが高いと思っています。無意識のうちに無理やり「既定路線」に着地させようとしていないか、自分自分を客観的にチェックする必要があります。
また、定性データを元に定めたジョブが本当に正しいのかどうかを、定量データと合わせて評価する必要があります。数字で効果が出ていないのであれば、そのジョブが間違っている可能性を疑わなくてはいけません。
この評価プロセスをUXデザイナー・UXリサーチャー・データサイエンティスト・エンジニアなどと協力してやっているPMの方も多いと思います。そのように複数人で定性分析と定量分析を分担している場合、ジョブを定義するに至った細かいコンテキストを全員で共有できていないと、正しい評価ができないリスクがあります。
続きを読む
RSGT2021に行ってきたのでレポートをする
2020年1月6日から3日間、Regional Scrum Gathering Tokyo 2021が開催されました。
もちろん…
参加しました！(`･ω･´)
初参加です！
去年と一昨年は、参加もしてないのにTwitterに流れてくるスライドを見つけてレポートをするという暴挙をしていただけだったのですが、今年はついに参加できました。
というわけで学びや気づきのレポートをしていきます。
Rethink Scrum from a Japanese cultural perspective
組織文化を「場の文化」と「個の文化」にわけてスクラムを見つめ直すアプローチ。「場の文化」の支配が強すぎると同調圧力やアンラーニングの失敗などによって合理性とは反する力学が働いてしまうし、「個の文化」の支配が強すぎると共感がないためただ契約関係の中だけでの協働となってしまい、チームの相乗的なパフォーマンス向上は望めない。
要はここのバランスを取りながら、ちょうどいい「場」を作るのがリーダー（TOYOTAでいうチーフエンジニア）の役目なんだなという学び。楽天が公用語を英語にした狙いが、「場の文化」に「個の文化」を取り込むためだったというのは驚きだった（英語の方が相手に合わせた表現の使い分けや婉曲表現のバリエーションが少ないため「個の文化」にシフトするとのこと）。
リーダーももちろんこの組織文化の中にいる一人の人間なのだが、場と個のバランスがどうなっているのか、暗黙的にどの力の支配力が強くなっているのかを、中にいながらそれに染まらずに組織を客観視して見極めなければいけない。要はシステム思考を持たなければならない。難しい仕事だなあとしみじみ。
“あざとくて何が悪いの？”建設的であり続けたいだけの､人たらしチームマネジメント
チームのパフォーマンスを高めたり物事を円滑に進めるためなら、あざとく打算的に振る舞わないといけないという内容。大事なメッセージを伝えたいときは画面の40〜50％になるように映るとか、プレゼン時は資料ではなく参加者のリアクションを見るとか、非常に細かい振る舞いなんだけどこの積み重ねは本当に後からじわじわ効いてくると思う。自分も結構相手のリアクションを見ながら態度や話し方を変えるタイプなのだが、それは別に嫌われたくないとかの理由ではなく、ただ物事を早く正しく前に進めたいからだけなのよね。
組織は人間の集まりなので、どうしたって感情的で非合理な力学が働いてしまう中で、いかに建設的な状態を保てるかはこういう泥臭い人間力みたいなものにかかっている。ただこういう動きをしていると理不尽なことも多く、結構ストレスフルなのでサーバントリーダーの如く「チームがうまくいく」ことを心底願っていないと途中で心が折れてしまうかもしれない。なので、こういう「あざとい」マネージャーを見かけたら、時には優しく接してあげてくださいw
ヒット商品を生み出すプロダクトマネジメントブースター
このセッションと及部さんの『「わからない」と共存するチーム May the CHAOS be with team』で共通していた「未知のわからないが多く存在するにもかかわらず、既知のわかる・わからないの中で意思決定をしてしまう限定合理性の恐ろしさ」は非常にいい気づきになった。だからこそ我々はスクラムやアジャイルで経験主義的アプローチをしていく必要があるのだ。
たがか知れてる我々の認知能力を過信せずに、未知のわからないを問い続ける姿勢を忘れてはいけない。そのために現場に行ってユーザーの課題を探ったり、事実を集めて柔軟に軌道修正していかねばならない。アジャイルの基本を改めてぶつけられた気がしたいい機会でした。
スクラムにおける「完成」とはなにか？
スクラムにおける「完成の定義」について、個人的に答えのわからないモヤモヤしたテーマだったのだが、このセッションのおかげで少しモヤが晴れた。
自分のモヤモヤの内容は、品質担保のためにある程度画一的な定義が必要なのは理解しているものの、とはいえPBIの種類によっては例外がどうしても生まれてしまい「あ、これはいいや」を繰り返しているといつの間にか形骸化していく、というもの。なので完成の定義をしっかり言語化することの意義をあまり見出せていなかった。
しかしこのセッションでは形式知としての完成の定義には限界があり維持もできないと言い切ってくれて、残りの部分は人間の力で随時更新していき、最終的に共通理解にすることで担保していくべきだというお話で、スッと腹落ちした。
What’s Testing Got to do with Quality?
プロダクトの品質に対する重要な示唆に富んだセッションだった。特に刺さったのが、品質を評価するのはQAでもステークホルダーでもなく顧客であるということ、そしてテストは顧客の様々な目線に立って行う必要があるということ。文字にすると当たり前なのだが、現場では時に忘れてしまうので常に心に留めておきたい言葉。
このセッションを聞きながら以前属していたスマホアプリを作るチームにいたQAエンジニアを思い出した。この方は本当にユーザー目線に立っていて、PMやデザイナー、エンジニアが思いつかないような使い方をシミュレーションして様々な不具合を見つけてくれて本当にありがたかった。まさにユーザーの代弁者となってくれていた。
このスタンスをチーム全体にインストールしないといけないし、それを実現するために以下の記事にあるようなループを回していかないといけない。
独立QAチーム1年戦記：スクラムの外からチームと組織の品質を創る道 / An Independent QA Team's 1 Year's War: Way to Create Quality of the Teams and the Organization from the Outside of Scrum
弊社のスーパーQAチームを率いるKawarada-san。自分はまだジョインして半年でこのスライドで紹介されている事例は詳しく知らないので、客観的にすごいなーと思った。
時々社内勉強会でKawarada-sanと「QAとスクラムチームの関わり方」や「テストに対する考え方」について話をするが、個人的にはここに唯一解はなくて組織と状況に合わせて最適な距離感や関わり方を見つけていくしかないと思っている。スライドにもあるように、「丁寧なコミュニケーション」を相互に繰り返していって成長していくしかない。これからもよろしくです。
野中郁次郎先生のクロージングキーノート
なんか感想を書くのも憚られるほど濃密で深いお話でした…恐らく10％も正しく理解できていない気がする。しっかり書籍も拝読しながら時間をかけて自分の中に落とし込んでいきます。
とにかく受け取ったメッセージとしては、誰かが作った形式知（理論やフレームワーク）に頼るのではなく、自分たちの共感や経験から得た暗黙知によって生み出した形式知に頼っていこうということ。勇気をもらえる貴重なお話でした。
以上、レポートでした。スライドはこちらの記事にまとめていただいているのでご参照ください。
今回書いたセッション以外にも素晴らしいセッションがあったし、参加者交流（OSTなど）でもいろいろな話が聞けたので、参加してよかったです。悔やむべきは、自宅からの参加だったので中途半端に仕事もやりながらになってしまい、ネットワーキングに全力を注げなかったこと。来年は会場に行けるといいな。
2020年の振り返りと2021年の抱負
あけおめ
(ノ・ω・)ノｳｪｰｲ
昨年同様、2020年の振り返りと2021年の簡単な抱負をまとめてみます。
仕事
何より転職が大きなイベントでした。
お世話になりました！様々な経験をさせてもらったことに感謝でいっぱいです。
— 久津佑介(HisatsuYusuke) / プロダクトマネージャー (@Nunerm) 2020年6月15日
そして明日から新しい職場で頑張ります。 pic.twitter.com/zYxP9drhKC
これまで大企業でしか働いていなかった自分にとっては、CAMPFIREで働いた期間に得た経験はかなり貴重なものでした。小さく未熟な組織で、裁量と責任を持ってプロダクトや組織に向き合う日々は刺激に溢れるものでした。担当していたCAMPFIRE Ownersのローンチと、最低限のグロースまではできたかなと思う一方で、もっとできたことはあったなと後悔もたくさん残っています。
そして6月にグロービスにPMとしてジョインしました。元々教育分野に強い興味があり、学習によって意識と行動を大きく変えられた自分自身の原体験をより広げたいと思い、教育業界に飛び込みました。この領域はまだまだテクノロジーが十分に活用されておらず、開拓の余地が多分にあると思っています。余白しかねえっす。
現在は特定のプロダクトのPMというより、横断系プロジェクトの推進やプロダクト戦略の整理・検討など、どちらかというと裏方に回ってます。我々が届けたい価値を世界中に届けるために、まずは土台固めに注力している感じです。ジョインして半年である程度自分がやるべきことが見えてきたので、2021年はギアを2段階ぐらい上げて走っていき、我々が目指す世界に少しでも近づけたいと思います。
転職活動期はこちらにまとめています。
productmanager55.hatenablog.com
副業
2019年12月からアルプ株式会社でお手伝いをさせてもらっています。週1しか稼働できていないのは申し訳ないなと思いつつ、スタートアップならではの本業ではできない経験を積ませてもらって感謝しております。
自分の仕事として、このリリースにある分析機能の構築を任せてもらいました。Scalebaseはこれから伸びていくプロダクトだと思うので、今後が楽しみです。
元々副業を始めた目的は「他組織の文化や手法を知ることで、本業における無用な『暗黙の了解』や非効率を是正したい」でした。アルプにおけるドキュメントのまとめ方やコミュニケーション文化はかなり参考になる部分が多く、しっかり真似させてもらっています。
登壇
2020年はなんと一回も登壇機会がありませんでした(´･ε･`)
コロナのせいでイベント自体も減ったこともありますが、ゼロは反省…
2021年は積極的に人前に出ていこうと思います。
取材・メディア掲載
キャリア系のメディア2つでインタビューしていただきました。
個人的にはいつかプロダクトマネジメント系、あるいは教育系のメディアに掲載されたいなと思っているので、お声がかかるようになるために日々精進して参ります。
コミュニティ・イベント運営
今年もプロダクトマネージャーカンファレンス2020の運営をお手伝いさせていただきました。2019年は当日だけのお手伝いだったのですが、2020年は企画段階から参加させていただきました。
各業界のPMの方々と一つのカンファレンスというプロダクトを創り上げるプロセスを経験できたことは非常に良かったです。参加者・登壇者・スポンサー様にとって何が価値なのか、それをどのようにデリバリーするのが最適なのか、（初めてのオンライン開催なので）不確実性やリスクにどう対応していくのかなど、まさにやってることはプロダクトマネジメントそのものでした。運営の皆様は各業界の第一線で活躍されている方ばかりなので、毎週の定例の中で時々手法論に走ってしまった際でも、議論の中で自然と「本質的な価値」に立ち返ることができていたのが印象的でした。
自分は主にセッション選定と登壇者コミュニケーション、当日のオペレーション検討、トラックAの画面スイッチングなどをやりました。特に当日のオペレーション検討は、自分自身にとってもpmconfにとっても初めてのオンライン開催ということで、ゼロから検討を始めたため非常に難しいものでしたが、当日何も問題は起こらず好評を頂けたので一安心でした。
（こんな感じで当日の動きをまとめてました。Miro便利。）
この辺の裏話やチームビルディングなどの話はここにまとめてあります。
もちろん来年もやりますぜ( ◞•̀д•́)◞
プライベート
コロナ禍でひっそりと引越しをしていて、さいたま市民から東京都民になりました。
その目的は2つあって、1つは奥さんの職場（アトリエ兼ショップ）が蔵前にできたことと、もう1つは猫を飼いたかったからです。
我が家に来て２日目にして早くも全く緊張感のない愛くるしい子はこちらです pic.twitter.com/J4nkCfPRY6
— 久津佑介(HisatsuYusuke) / プロダクトマネージャー (@Nunerm) 2020年6月12日
日々幸せな猫ライフを楽しんでおります(´∀`*)
そこまで堂々と邪魔するようになったか pic.twitter.com/nkMAWfUAry
— 久津佑介(HisatsuYusuke) / プロダクトマネージャー (@Nunerm) 2020年11月6日
その他
2020年は大半を自宅で過ごしたことで、リアルで人と会う機会は激減しましたが、一方でPM界隈の方とオンライン雑談する機会は増えたような気がします。大体はTwitterで何かの話題で盛り上がって「一度話してみましょう」みたいな流れですね。場所の制約が無くなったことにより、気軽に誘う（誘われる）ようになれたと思います。
現在もMeetyでカジュアル面談を受け付けてます。
2020年の読書量は49冊でした。月4冊ペースですね。もう少し増やしていきたい。
そのうちのおすすめトップ10はこちら
2020年からオンライン英会話を始めました。
今まで何度か挑んでみては挫折してきましたが、今の職場に外国人が多く日々のコミュニケーションで必要で、かつこれから海外市場にも挑んでいくという明確な目的意識があるおかげで継続できています。
自分はBizmatesを使っています。今のところ順調に少しずつ上達してきており、レッスン前に5分くらい雑談できるようになりました。こうなるとどんどん楽しくなってきますね。2021年もしっかり継続していきます。
最後に…2020年の最初に立てた「ループミュージックのYouTuberになる」という目標に対して、ほぼ何もアクションできなかったので2021年こそトライします。
というわけで2020年の振り返りと2021年の簡単な抱負でした。
みなさま今年もよろしくお願いいたします。
プロダクトマネージャーに必要な「定義しにくいスキル」
こちらはプロダクトマネージャー Advent Calendar 2020の21日目の記事です。
改めまして久津と申します。今年の6月からグロービスでPMをやっております。
はじめに
「PMにはどのようなスキルが求められるのか」
「PMになるためには何から学べばいいのか」
こういった話をよく聞きます。若手のエンジニアからよく相談されたりもします。その際に自分なりに「まずドメイン知識を学ぼう」とか「ユーザーの声を聞きに行こう」などアドバイスはするのですが、毎回自分の口から発しているアドバイスに自分自身が腹落ちしないというか、芯を食っていない気がしていました。
PMのスキル定義には、有名なプロダクトマネジメントトライアングルや、エンジャパン岡田さんがこの記事で定義した「PM SkillChart HEX」があります。
これらの定義は良く整理されてて素晴らしいと思いますし、内容に対して全く異論はないのですが、「定義されている全てのスキルを身につけたPMが確実に結果を出せるのか？」と想像すると、どうもしっくりこない。何かが足りないような気がしていましたが、今までそれを言語化できていませんでした。
しかし、最近いろいろな方々とお話する機会があって、ある程度言語化できてきたので、この記事にまとめてみます。
続きを読むプロダクトマネージャーの意思決定ロジックの可視化
こちらはGLOBIS Advent Calendar 2020の10日目の記事です。
グロービスには今年の6月にジョインし、早いもので半年が経過しました。現在は特定のプロダクトのPMというより、プロダクトの裏側を整える系のプロジェクトをいくつか動かしています。
そんな私は、社内で「可視化おじさん」と名乗っております。
以前の記事でプロダクトマネージャー（以下PM）がキャッチアップする際に「様々な構造の可視化が大事だよ」と書きました。実際にそれを実践してどんどん可視化しまくった結果、お褒めのお言葉をいただくことが多かったので、調子に乗って名乗ってみました。
というわけで、次に可視化おじさんが可視化を試みようとしているのは「PMの意思決定ロジック」です。この記事では、PMの意思決定ロジックの可視化によるメリットなどを書いていきます。
プロダクトマネージャーの意思決定とは
PMは様々な種類の意思決定をする必要があります。そこには抽象度の高いもの（プロダクト価値の定義やプロダクト戦略など）や、具体性の高いもの（機能の取捨選択や優先度など）があり、この具体と抽象を常に反復横飛びして意思決定し続けなければいけません。
また、この様々な抽象度の意思決定たちは相互に繋がっています。
例えば抽象度の高いプロダクトビジョンを立てたら、それをより具体に落とし込んでプロダクト戦略を立案し、さらに具体に落とし込んで数値目標（KPI）を定義し、次にそのKPIを達成するためにインサイトを捉えてユーザーストーリーを定義するという抽象的な思考を働かせる必要があります。
つまり、一連の意思決定のインプットとアウトプットの抽象度が異なるのです。
このインプットとアウトプットの間には、意思決定ロジックが存在します。ここで言う意思決定ロジックとは「何の情報を基に決めたのか」、逆に「何の情報を使わなかったのか」、そして「どのようなロジックでそのインプットを基にアウトプットを作り上げたのか」を指します。まあプログラムと同じですね。
もちろん意思決定ロジックが異なれば、インプットが同じでもアウトプットは変わります。
ヘビーユーザーがプロダクトに見限られたと感じる際に起こる、負の感情の暴走について
これは何か
ライフサイクルの一部となっているプロダクト・サービスの大幅な方針転換により、自分が明らかにメインターゲットじゃなくなった時に、そのヘビーユーザーの中に起こる「負の感情の暴走」について書いたものです。今回自分がその当事者（＝見限られたヘビーユーザー）になる機会があり、プロダクト提供側としても教訓になりそうだったので、記録として記事に留めることにしました。
きっかけはNewsPicksのUI大幅変更
先月NewsPicksのアプリUIが大きく変わりました。リリース前は少し楽しみにしていたのですが、いざ使い始めてみると「自分はメインターゲットではなくなった」と感じ、自分でも予想していなかった負の感情と行動が見られるようになりました。
まず自分はどのようなユーザーなのか
ローンチ当初からのヘビーユーザーで、大きく以下３つの目的で利用し続けていました。
- 幅広い情報源からニュースを知りたい
- コメントを書くことでアウトプットスキルのトレーニングとしたい
- 質の高いオリジナル記事を読みたい
よって、リニューアル前のカテゴリごとに理路整然と並んでいるUIは、能動的に記事を探すには最適なUIでした。毎朝のルーチンワークは、[総合トップ]タブのニュースタイトルを上から見ていって、気になったものは開いて記事を読み、思ったことがあればコメントし、一通り見終わったら次のタブに移り…（以下繰り返し）という感じでした。
またオリジナル記事が増えたり、番組を配信したり、書籍を出版したり、享受できるコンテンツの種類もどんどん豊富になってきたため、コンテンツ消費が追いつかないと感じることも増えてきました。それくらい愛用していました。恐らくアプリを開かない日はないぐらいのヘビーユーズっぷりだったと思います。
続きを読むプロダクトマネージャーのキャッチアップ術 〜構造の絵を描こう〜
はじめに
以前「プロダクトマネージャーの転職活動記」を書きましたが、その続編となります。実際に転職をして３ヶ月ほど経ち、それなりに良いスタートを切れたと思っています。
そんな中で、上司や同僚から「キャッチアップが早いね」とか「３ヶ月でよくそこまで把握してますね」とよく言われることに気づきました。あまり自覚はなかったのですが、実は高速キャッチアップが自分の得意技みたいで、それが良いスタートに繋がりました。
これが自然と身についた理由は、リクルート時代にプロジェクトマネジメントに特化した組織に属していて、組織やプロダクトが既に存在している状態から立ち上がったプロジェクトに参画するケース、つまり「新しい環境でゼロからキャッチアップをする」機会が人に比べて多かったためだと思います。その後プロダクトマネージャーとしても１回の出向、２回の転職をしているので、単純に場数が多いんですね。
というわけで、新しい環境に入って少しでも早くプロダクトマネージャーとして活躍できるようになるための自己流キャッチアップ術をまとめてみます。転職や異動したばかりでなくても、うまくプロダクト開発が進まないと悩んでるPMの方にも参考になるかもしれません。
続きを読む
