もくもくプロダクトマネジメント( @Nunerm )

プロダクトマネジメント・エンジニアリングマネジメントなどについて黙々と

職種に求められる役割やスキルは環境変数次第だよね、という雑記

最近以下のような問いによく出会います。

 

「プロダクトマネージャーはどこまでを担うべきか」

スクラムマスターはどこまで踏み込むべきなのか」

「デザイナーとPMの境界線はどこか」

「プロダクトマネージャーが持つべきスキルは何か」

 

要は「職種の定義」というやつですね。それぞれの職種が一般的にどのような役割とスキルを持つのが望ましいのか、というような議論をあちこちで目にしますし、意外とこれ盛り上がりますよね。おそらくそういう記事はPVを集めやすいのだと思いますし、私も昔そういう記事を書いたことがあります。

 

ただ、私は最近「どうでもええやん」と思うようになりました。

 

それは、これまで何度か転職をして様々な環境で様々な役割を担い、様々な人たちと仕事をしてきた中で、「職種に求められる役割やスキルは、周りの環境によって決まる相対的なものである」と確信を持ったからです。事業ドメイン、事業フェーズ、プロダクト特性、プロジェクト特性、組織規模、組織文化、組織状況など、様々な環境変数によって今求められる役割やスキルが決まります。

シリコンバレーはこうやってます」みたいな情報は確かにキラキラして参考にしたくなりますが、自分の環境が持つ変数と、シリコンバレーの環境が持つ変数はどれだけ同じなのか?を考えないといけません。変数が異なるなら、その真似をしても今の環境では成果につながらない可能性が高いです。

 

pmconf2021のRetty 野口さんの発表にあった「Rettyに求められるPMの必要スキルの定義」のように、自らの環境の変数を踏まえて定義されたものは、この組織で活躍するために必要な指標なので、非常に有用なものだと思います。

f:id:swnws322:20220205185026p:plain

https://speakerdeck.com/roki_n_/how-we-introduced-the-pm-skills-and-evaluation-system-and-evolved-into-a-product-management-group-that-produces-outcomes?slide=30

ただ、そういう環境変数を考慮しないで「この職種にはこのスキルが必要」「ここまでがこの職種の役割であるべき」と一般的に定義されたものを盲目的に信じてもあまり効果はないと思いますし、それに囚われ過ぎるとどこの組織にもハマらない凡庸な人材になってしまうリスクがあると思っています。

もちろん、今所属している組織が持つ変数がよくわからず、かつ組織内にロールモデルとなる人がいないような環境であれば、「一般的な定義」を参考にして役割や得るべきスキルを見出していくのはアリだと思いますが、それが今の環境にハマっているかどうかは別問題です。一時的に成果は出たとしても、併せて環境変数を見抜いて役割をチューニングしていく動きも求められます。

また、逆に「一般的な定義」や「他社の定義」を自分の環境で実現するために、環境変数の方を変えにいくアプローチもあります。上の例で言えばシリコンバレーのやり方ができるように環境をシリコンバレーのように変えていく、という使い方もアリだとは思います。ただ、本当にそれが今の環境に求められていることなのかは見極めるべきです。

 

つまり言いたいのは「一般的な定義や他社の定義を参考にするなら、その裏にある環境変数も理解しようぜ」ということです。もちろんめちゃくちゃ難しいことを言っているのは自覚してますが、それをやっていかないとただの自己満足に終始してしまうリスクがあると思うのです。なので書籍や他社の事例を見て参考にしたい際には、可能な限り発信者に背景を聞きにいくことをお勧めします。

そしてこれは職種の役割に限らず、フレームワークにも共通する話です。スクラムとかOKRとか、イケてる企業が使ってるフレームワークが自分たちにも有効かどうかはやはり変数次第です。これらのフレームワークを活用したいなら、変数の方を合わせてから導入するべきだと思います。例えばOKRの恩恵を受けたいなら、チームへの適切な権限委譲をしないといけません。ただのTODOリストになってしまいます。

 

 

以上、最近よく思うことを雑に書いてみました。

昨年はブログの更新頻度が著しく減ってしまったので、今年はあまり準備せずに気軽に書いていきます。

2021年の振り返りと2022年の抱負

あけおめ

(ノ・ω・)ノウェーイ

 

毎年恒例となりました、昨年の振り返り&今年の抱負記事を書きます。

 

仕事

グロービスに2020年に6月にジョインし、早くも1年半が経ちました。

最初は横断系プロジェクトのPjM的な動きから始め、その後法人プロダクトのPO/PMを担いました。

社会人教育のtoBプロダクトは非常に面白いと同時に難しく、今でも満足する成果を出せていません。やりたいけどできていないこと、思った通りに進まなかったことも多かったですが、少しずつ前には進んでいる実感はあるので、2022年もよりギアを上げていく所存です。

 

グロービスtoBプロダクトの面白さと難しさを語った記事はこちら。

productmanager55.hatenablog.com

 

また公に堂々と自慢できる我がチームの成果はこちら。

prtimes.jp

 

そして、PMの役割以外に「ネオ・何でも屋」の動きも始めました。

採用をはじめとした組織戦略、長期的な視点でのプロダクト戦略、問題が深刻化しつつある技術的負債&運用負債の解消戦略など、プロダクトや組織を俯瞰して大きな変革を起こす動きを取り始めています。この役割を何と呼べばいいのか分からないので、適当に「ネオ・何でも屋」と名付けてみましたw

これはまさに2022年の大きなチャレンジなので、気合入れて取り組んでいく所存です。

 

副業

2019年からお手伝いさせていただいたアルプでのお仕事は一旦一区切りとさせていただきました。理由はシンプルで、本業がどんどん忙しくなってきた&週一休み生活が辛くなってきたからです。

トータル1年半くらい関わらせていただき、いろいろなことを学ばせていただきました。受け入れていただいた皆様には感謝しております。

 

現在は、とある企業のDX支援的なお手伝いをさせていただいてます。本業の忙しさはまだ変わらないので、作業で貢献するというより知識と経験を基にアドバイスさせていただく形で関わらせてもらってます。この形でもしっかり価値を発揮できるかどうかが、自分の中のチャレンジでもあります。

 

登壇

3月の「プロダクトオーナー祭り2021 Spring」で登壇させていただきました。

複雑系と対峙するプロダクトマネージャーが持つべき「システム思考」について話させていただきました。他の登壇者の方々と比べて非常に堅苦しく抽象的な内容だったにも関わらず、質疑応答コーナーに結構集まっていただいたのは嬉しかったです。

speakerdeck.com

 

2021年はこの1回だけでした。もう少しアウトプットせねば…

今年はいよいよプロダクトマネージャーカンファレンスの公募に挑もうかなと密かに思ってます。

 

取材・メディア掲載

ProductZineさんの「PMが知っておくべき、プロダクトマネジメントで重要な100のこと」というシリーズの第6回に寄稿させていただきました。こちらでもシステム思考の話を書かせていただいています。いつも拝見してるメディアへの寄稿の機会をいただけるのは嬉しいですね。

productzine.jp

そして、いつもジョギング中に聴かせて頂いている、あのfukabori.fmにも出させていただきました…!と言っても、私個人としての出演ではなく、プロダクトマネージャーカンファレンス実行委員会の代表として出演でした。

fukabori.fm

今回初めてのPodcastだったのですが、自分の話し方のダメさ加減がよくわかりました。とはいえ収録は非常に楽しかったので、今後機会があればトライしてみたいなと思います。(一人語りは辛いので、誰かと一緒にやりたいw)

 

コミュニティ活動

今年もプロダクトマネージャーカンファレンス2021の実行委員会を務めさせていただきました。しかも、今回はこれまで横道さんが担われていたプロジェクトリードの役目を仰せつかりました…!

 

いや〜大変でした!!

 

まず前提として、運営メンバーは全員有志のボランディアで、本業やご家庭の都合の隙間を縫って活動されているため、人やタイミングによって稼働できる時間が異なります。その中での役割分担やタスクの割り振り、スケジュール設定などが非常に難しく、過去に類を見ないタイプのプロジェクトマネジメントでした。その分色々と学ぶこともでき、結果的にカンファレンスも大成功となったので大変満足です。

カンファレンスの結果はこちらの記事をご覧ください。中の人として書きました。

note.com

 

今年は初の無料化やアーカイブ動画の公開など、新たなチャレンジも取り入れました。来年のプランはまだ全く決まっていない、というか議論すらしてないのでどうなるかわかりませんが、どうせこの好奇心旺盛なメンバーのことなので、また新たなチャレンジを盛り込んだ進化したプロダクトマネージャーカンファレンスになるはずです。というわけでお楽しみに!

f:id:swnws322:20211230111232p:plain

またpmconfのご縁もあって、横道さんの翻訳された『プロダクト・レッド・オーガニゼーション』の翻訳のお手伝いに、本当に少しだけですが参加させていただきました。初めての体験でしたが、翻訳って難しいなあと改めて実感しました。

プライベート

自分にはそんなに書くことはないので、奥さんのブランドを勝手に宣伝しますw

脱サラしてジビエレザーによるものづくりをしています。一人でやっているのでまだまだ小さいブランドですが、ちょこちょこ手伝いをしている中で、着実に成長していると横から見てて感じます。個人事業主として一人でここまでできるのは、純粋にすごいなって思います。そして同時にサラリーマンって守られた存在だなってつくづく感じましたw

 

蔵前駅前のウグイスビルという建物にショップがあるので、蔵前に来られた際は立ち寄ってくださいませ(土日のみです)。

makami.official.ec

 

あと我が家の猫は順調に育ってます。

 

 

その他

2021年の読書量は39冊となり、昨年と比べてかなり減ってしまいました。これは大反省。

 

その中での「2021年に読んだ本のおすすめランキング」はこちら。

f:id:swnws322:20211230114349p:plain

ビジネス書以外に宗教系の書籍があるのは、最近仏教的思想(執着を捨てること、流れを見極めることなど)が今の自分に必要なのではないかと思っているためです。書籍を読んだり京都の寺に行ったりしましたが、まだまだちゃんと理解できていないので、一度寺に修行に行こうかと企んでいます。

 

2022年に向けて

2021年は仕事とpmconf運営にがむしゃらになりすぎて、自己研鑽が疎かになってしまいました。

仕事のところにも書いた通り、今後は組織戦略周りにも積極的に携わっていくつもりなので、マネジメント・リーダーシップ・コーチング周りを改めて勉強し直すつもりです。これまで、経験と独学で積み上げた知識とスキルだけで勝負してましたが、それでは通用しないなと思ったシーンに何度か直面したので、改めて体系的に学んでいきます。

今のところまだ具体的な計画を立てていないので、スクールなど何かオススメの方法があれば教えていただけると幸いです。

 

また同時に英語のレベルも飛躍的に上げたいです。昨年から英会話を始めましたが、ある程度のレベルに達してからの頭打ち感が出てきて、そこから少しサボり癖も出てきてしまったので、気合を入れ直します。ちょうどアメリカに拠点ができたこともあり、アメリカに渡って海外事業に関わる野望も密かに持っているので、ビジネス英会話を苦なくできる状態を目指します。

 

 

 

というわけで2021年の振り返りと2022年の簡単な抱負でした。

皆様、今年もよろしくお願いいたします。

GLOBISのtoBプロダクトの面白さと難しさを語ろう

この記事はGLOBIS Advent Calendar 2021 の21日目の記事です。

f:id:swnws322:20211219005633p:plain

見ての通り、これまで我々が誇るエンジニアたちの技術寄りの記事が多い中、PMである私は空気を読まずに担当しているプロダクトについて語ります。

社会人教育という分野で、非デジタルの既存事業を持ち、グローバル展開までしているGLOBISならではの面白さや難しさを存分に語らせていただきます。

 

プロダクトの紹介

私が担当しているのはGLOBIS 学び放題/GLOBIS Unlimitedというプロダクトです。どちらもビジネスパーソン向けの定額制動画学習サービスで、歴史あるグロービスMBAで培ったノウハウを詰め込んだ良質な学習コンテンツを多く取り揃えています。

GLOBIS 学び放題は国内向け・日本語コンテンツを提供しており、既に動画は3,900本以上となっています。

hodai.globis.co.jp

GLOBIS Unlimitedは海外向け・英語コンテンツを提供しており、こちらはまだ立ち上げ期なので動画は125本ですが、かなり海外戦略に力を入れており今後もどんどん追加しいく予定です。

globisunlimited.com

 

上記の2つのLPはどちらもtoC向けのページで、知名度としてもtoCサービスが比較的高いかなと思います。ですが、実はtoB向け、つまり法人企業様向けにもサービスを提供させていただいております。

hodai.globis.co.jp

 

既に2,400社以上の企業様に導入いただき、様々な組織課題の解決のためにご活用いただいております。

私のチームでは、主に人事の育成担当者様が使う管理機能の開発や、先月ニュースリリースが出た外部LMSサービスとの連携など、法人事業に関わるプロダクト開発全般を担っています。

f:id:swnws322:20211219011436p:plain

 

プロダクトの紹介はこのくらいにして、このようなtoBプロダクトを開発・提供することの面白さと難しさ、そして我々がどのような工夫をしているかを、プロダクトマネージャーの立場から語っていきます。

 

面白難しポイント①:ユーザーの課題が多種多様である

我々の顧客は法人企業様ですが、そこには大きく分けて3種類のユーザー(人)が存在します。

  • サービスの導入を決める意思決定者(主に人事部門の責任者様)
  • 学習促進や進捗管理を行う管理者(主に人事部門の担当者様)
  • サービスを利用して学習をする受講者(社員の方々)

 

そして、各企業様の解決したい課題は多岐に渡ります。

  • 管理職の中から次世代の経営人材を育てたい
  • 組織に自ら学ぶ文化を醸成したい
  • タレントマネジメントに活用したい
  • 企業研修の効果を上げるために予習・復習教材として活用したい など

 

また、それぞれの顧客の組織の状況も異なります。

  • 既に自ら学習する文化がある組織
  • これから自ら学習する文化を作り上げたい組織
  • 既に育成プロセスが構築されており、そこにGLOBISのサービスを組み込みたい組織
  • 育成プロセスは無く、GLOBISのサービスを基点として構築したい組織

 

さらに、我々は海外市場にも挑んでおり、日本と英語圏では育成事情が異なります。特にアメリカの大企業では育成プログラムとLMS(Learning Management System)が構築されていることが普通であり、そこの生態系にうまく入り込めないと検討のテーブルに上げてもらうことすら難しくなっています。

 

 

このように「ユーザー」と一言で言っても、バックグラウンドやコンテキスト、課題の種類などが多種多様です。こうなると、単一のペルソナを定義してそこだけにフォーカスする戦略は取れません。だからと言って、全変数を考慮したペルソナ定義は非現実的です。

よって、我々のチームでは取り扱う変数を絞ってペルソナ定義をしてみました。

f:id:swnws322:20211220205125p:plain

ユーザーインタビューの結果や営業・カスタマーサクセス部門に溜まっている情報を基に、解決するべき課題(ジョブ理論でいうところのジョブ)やソリューションの選択との因果関係が強い変数を絞り込みます。さらにその絞り込んだ変数を「Why/Whatに関わるもの」「Howに関わるもの」に分類します。(前者が☑️、後者が△)

上記の図の「受講者規模」を例に挙げてみます。(左から五番目)

受講者規模によってソリューションの選択は確かに変わり、大人数の場合はグループ作成機能や受講履歴一覧機能などで利便性や視認性が強く求められます。しかし、これらの機能で解決したい課題は「受講状況を正確に把握し、学習活性の効果を評価し、ネクストアクションにつなげたい」であり、それは受講者規模には関係ありません。少人数の組織でも同じ課題になります。つまりこれは「Howに関わるもの」です。

この「Howに関わるもの」は機能レベルの要件ではもちろん考慮が必要ですが、もう少し抽象的なユーザーストーリーレベルでは「How/What」に着目したいのであまり考慮しないようにしています。

 

このようにして、多種多様なユーザー属性をある程度抽象化して考慮すべき情報を意図的に削った上で意思決定をしていく工夫をしています。もちろんこの定義は不変ではありません。実際にデリバリーを繰り返して評価していく中で、思った通りの結果が出なかった場合はこの定義を疑って見直しています。

この点は難しく大変なポイントではあるのですが、世界中の様々な企業の組織成長の課題に向き合うという取り組みは非常に面白いと感じています。これによってより価値を増幅し世界の企業の組織成長に貢献できたら、本当に素晴らしいことだと思います。

 

 

面白難しポイント②:学習の活性化

我々のサービスは「導入したらすぐに効果が出る」といった類のものではありません。学習する機会やコンテンツを提供することはできますが、実際に社員の方々に学習していただくには「学習の活性化」が欠かせません。以下の図やこちらの記事のように、管理者の方に促進活動を行なっていただく必要があります。

ただし、人事の方は忙しい方が非常に多いため、なるべくここは省力化したい業務になります。

 

そこで、ほっといても学習活性が実現できる、スーパー学習活性機能を提供させていただきます!(´∀`*)

 

…と、言いたいところですが、こちらも非常に難しいポイントがあります。というのも、①で書いた通りユーザーの課題や状況が多種多様なため、どのような学習活性が効果的なのか簡単に選択できないのです。

例えば、能動的にサービス利用を選択した社員の方と、人事に言われて受動的にサービス利用をしている社員の方では、全くモチベーションが異なるため伝えるべきメッセージも変わってきます。toCプロダクトであれば、ユーザーは基本的に自らの意思で課金をした、つまり能動的なユーザーで占められていますが、我々のtoBプロダクトはそうとは限らないのです。前者には「次はこのようなコンテンツがオススメです!」というメッセージが効きそうですが、後者には「今月中に3つのコースを受けてみましょう」というメッセージが効きそうです。

しかし、我々はこの社員の方のモチベーションを区別できません。人事の方であればある程度把握できるかもしれませんが、現時点で我々が保持しているデータからの推測は難しいです。要は「ノリノリで学習しているのか、渋々学習しているのか」が学習履歴からはわからないのです。

 

ここはまだ我々が未熟なところで、今後定性データの取得や分析などを活用して進化させていきたいポイントになります。余白だらけってワクワクしますよね。

 

 

面白難しポイント③:導入効果の評価

ここが最大の難所です。GLOBIS 学び放題/GLOBIS Unlimitedを導入いただく法人企業様の目的は「組織成長」です。つまり「今の状態より良くなっていること」が求められます。

 

では、それをどうやって評価すれば良いのでしょうか?

 

例えば会計系のSaaSであれば「削減された業務時間」がわかりやすい評価軸かと思いますが、我々のサービスにおいてはわかりやすい数字がありません。もちろん「学習量」「学習頻度」のような数字はありますが、本当に追い求めるべき指標は「学習をした結果、社員あるいは組織がどう変わったか」になります。

しかし当然ですが、人や組織が変わる・成長する要因は学習だけとは限りません。現場での経験やマインドセットの変化、外部環境の変化など、様々な要因によって起こります。我々が提供させていただいた学習機会やコンテンツがどのように貢献できたのか提示できれば、より効果的な活用方法を示すことが可能になりますが、顧客の社内事情を細かく把握できないため、なかなか難しいのです。

現時点では営業やコンサルタント、カスタマーサクセスによるヒューマンタッチでここをサポートさせていただいておりますが、プロダクトマネージャーとしてはプロダクトでもここに貢献できないか挑戦してみたいと思っています。これからグローバル展開に注力し顧客数を爆発的に増やそうとしている我々にとって、人によるサポートに頼ってばかりではいけません。

 

これまでもβ版機能として「テスト機能」や「アンケート機能」などリリースして検証をしていますが、まだまだブラッシュアップする必要があります。これも難しいけれど楽しみな挑戦です。

 

 

 

おわりに

いかがだったでしょうか?「難しそう、やだな〜」と思いましたか?

 

私は「めっちゃ面白そう!やったるで!」と思うタイプですd(゚∀゚d)

 

確かに難しいポイントが多く、まだまだできていないことも多いですが、これからの工夫や頑張りで新たな価値を提供できるようになると確信しています。

 

 

もし「面白そう!もっと詳しく聞いてみたい!」と思われた方は、私のTwitterのDMMeetyからご連絡いただければお話しさせていただきます。お気軽にどうぞ!

また「ここで働いてみたい!」と思っていただけたら、こちらの採用ページから応募いただけるととても嬉しいです。全方位で積極採用中です!

recruiting-tech.globis.co.jp

 

さらに、1/12(水)にEd-Tech企業が集まるMeetupを主催させていただきますので、こちらにもどしどしご参加ください!

connpass.com

 

最後に我々の組織紹介資料を置いておきます。

speakerdeck.com

プロダクトマネジメントに活きるウォーターフォールプロジェクトマネジメントの経験

こちらはプロダクトマネージャー Advent Calendar 2021 の21日目の記事です。

なんと10ヶ月ぶりのブログ投稿となってしまいました…!

f:id:swnws322:20211218162207p:plain

久津(ひさつ)と申します。現在はGLOBISで法人向けプロダクトのPMをやっており、これまでのキャリアでエンジニア→プロジェクトマネージャー→プロダクトマネージャーという順で経験を積んできております。


この記事では、プロダクトマネジメントに活きるウォーターフォールプロジェクトマネジメントの経験について書きます。現在プロジェクトマネージャーで今後プロダクトマネージャーへのジョブチェンジを考えられている方、既にプロダクトマネージャーだがプロジェクト推進で悩まれている方の参考になればいいなと思っております。

 

 

プロダクトマネジメントとプロジェクトマネジメントの違い

これについては説明されている記事や書籍が腐るほどあるので割愛します。こちらの記事が最もわかりやすいかなと思います。

aboutproduct.jp

 

ネット記事やブログでは「プロジェクトマネジメント≠プロダクトマネジメントという説明が多いですが、「プロジェクトマネジメントプロダクトマネジメントつまりプロダクトマネジメントに必要な要素にプロジェクトマネジメントがあるという解釈が個人的には好きです。

プロダクトマネジメントトライアングルやエンジャパン岡田さんが作られた「PM SkillChart HEX」でも、プロジェクトマネジメントはいち領域として定義されています。

画像1

ゴリゴリのウォーターフォールのプロジェクトマネジメント時代

私はリクルートテクノロジーズのプロジェクト推進部という部署で4年ほどプロジェクトマネジメントを担っていました。リクルートといえばデジタルプロダクト開発の最先端でアジャイル開発をしているだろうみたいなイメージをお持ちかもしれませんが、当時はウォーターフォール開発がかなり多く、かつ事業規模が大きいためプロジェクト自体も大規模なものになりやすい環境でした。

プロジェクト推進部は、プロジェクトマネジメントに対して本気で向き合っていた部署で、以下のような取り組みをしていました。

 

  • PMBOKなどのナレッジをベースに独自にオリジナルスキームを作る(大規模プロジェクトガイドと呼ばれていた)
  • プロジェクトの変数(人数/予算/期間/言語/業界など)やその結果を全てデータ化し、成功・失敗要因を科学する
  • 独立したPMO組織を作り、プロジェクトマネージャーが気づかない潜在リスクを検知するために、プロジェクトの状況を客観的に評価をする仕組みを作る(リスクが見つかった場合は合理的な回避・軽減策を提示しないと次に進めなかった)

 

ただ漫然とタスク管理をしてWBSを引いて定例会議を開いてたわけではありません。プロジェクトマネジメントに真摯に向き合い、数々の大規模プロジェクトを推進して成功に導いてきました(もちろん失敗もありました)。

 

アジャイルウォーターフォール論争

最近「世界の不確実性が増してきたから、計画主義のウォーターフォールでは対応できない」「だからまず小さくリリースしてフィードバックを得ながら進む経験主義のアジャイル開発をすべきだ」という言われ方を多く見かけますが、私はそんなに極端に分けるのではなく「状況に応じてうまくハイブリッドするべきだ」と思っています。

もちろんシステムや組織の依存関係の少ないシンプルなプロダクトであれば、大掛かりな計画などせずに早く前に進めた方がいいとは思いますが、ある程度依存関係や複雑性を持っているのであれば、事前に必要最低限の計画を立てた上でしっかりプロジェクトマネジメントをしないと、プロダクト開発が前に進まないこともあると思っています。たまに見かけるのが、アジャイルに傾倒するがあまり計画が杜撰で、フィードバックサイクルを回して進んでるつもりが同じところをぐるぐる回っているようなプロジェクトです。

「大規模で複雑なプロダクトだが、多くの小さいチームでアジャイルを回せている」という組織ももちろんあります。それは依存関係を軽減させる仕組みやアーキテクチャ、または依存関係をコントロールする役割の人がいることで実現できているのだと思います。

もしまだその仕組みや人が存在せず、依存関係や複雑性と共にプロダクト開発、プロダクトマネジメントに挑んでいるのあれば、個人的にはハイブリッドのプロジェクトマネジメントをお勧めします。チームがアジャイル開発をしていたとしても、ウォーターフォールのプロジェクトマネジメントの勘所を知っておいて損はありません。

 

プロダクトマネジメントに活きていること

少し話が逸れましたが、本題に入ります。私はリクルート内での異動や転職の中でプロダクトマネージャーにキャリアチェンジしましたが、あの頃のゴリゴリのウォーターフォールプロジェクトマネジメント経験は、現在のプロダクトマネジメントの中でも存分に活きています。プロダクトマネジメントの責務とタスクが増えたので、相対的にプロジェクトマネジメントに割くパワーは減り、重厚長大な計画書やWBSを作ったりはしませんが、あの頃に得たスキルや考え方が役立っています。

 

ここからはその中でも特に日々役立ってることを書いていきます。

 

リスク感度が高くなる

ウォーターフォールのプロジェクトマネジメントの場合、最初にプロジェクト計画を行い、その中でリスク定義をします。ここでいうリスクとは、品質やスケジュール、コストや人に関わる問題の発生リスクのことを言います。例えば開発が予定通り進まないリスク、開発途中で要件が変わるリスク、リリース後に大障害が起こるリスクなどです。

このプロジェクトではどのようなリスクが起こりうるか、それが起こったらどのような影響が起こるのかなど、可能な限りリストアップしておきます。また、現時点でリスク評価が難しいものは、どのタイミングになったら改めてリスク評価をするのかを定義しておきます。

 

この考え方が頭にあると、プロダクトマネジメントの中で不意に発生する問題に対して強くなります。何か新しいこと始めるときに、一旦のゴールまでの流れをイメージしてリスクの存在をサーチし、影響の大きいリスクがあれば先に打ち手を決めておく、あるいは早い段階でリスク軽減の打ち手を打っておく癖がつきます。逆にリスク評価の結果、起こってもその場で対処できるし影響が少ないと判断すれば、今後そのリスクは特に気にせずプロダクト開発に集中する意思決定もできます。つまり起こってから慌てて考える場当たり的な対応を減らせます。

もちろん今考えてもわからないことを頑張って考える必要はありません。時間の無駄なので。ただ、少しの労力で調べて考えれば検知できるリスクは、早めに検知しておくに越したことはないという考え方です。

当たり前っちゃ当たり前の話なのですが、意外とリスク評価は難しいし大変なのです。評価のための情報を適切に集めないといけないし、どのような軸で評価すればいいのかもわからないことが多いです。プロダクトやプロジェクトの特性によって評価方法や基準は変わるので唯一の解はなく、自分なりのリスク評価軸を持って育てていくことが求められます。

 

勘違い防止力が上がる

ウォーターフォールのプロジェクトにとって恐ろしいのは「勘違い」です。ステークホルダーの勘違いによって要件が変わったりスケジュールが遅れたりします。アジャイルに比べるとウォーターフォールでは勘違いの発覚が遅れ影響が大きくなってしまうので、いかに勘違いを起こさないか、共通理解を作れるかが勝負となります。

リクルート時代、この勘違いを防ぐ取り組みとして「ビジネスルール」の作成を行なっていました。ビジネスルールとは以下のようなものを定義したリストです。

  • プロダクト、サービスに関わるもの(人/役割/機能/業務など)の名前と意味
  • 機能や業務の範囲・境界(例:「決済機能」は会計システムへのデータ連携処理まで含む範囲)

最近はドキュメントは少ない方がいいと言われている時代です。口頭やテキストなどフロー情報でのコミュニケーションが相対的に増えた中で、言葉の意味や定義をいちいち補足するのは難しくなっています。であれば、最初からズレが起こらないように共通理解を作っておくことが勘違いの防止につながります。

またプロダクトマネージャーは様々な職種や部門のステークホルダーとやり取りをする機会が多いと思います。大きい組織になればなるほど、職種や部門によって言葉の使い方が異なるケースが多く、勘違いが生まれやすい環境になります。

DDDのユビキタス言語など、最初から共通言語を使うようなプロダクト開発手法もありますが、そのような仕組みのないプロダクト開発の現場では、ステークホルダーとのコミュニケーションの中で「あれ?何か人によって解釈が違うな」と感じたら、すぐにズレを解消する動きを取ることをお勧めします。

 

クリティカルパスを見つけやすい

ウォーターフォールのプロジェクトマネジメントのキモはやはりスケジュール管理です。各タスクの依存関係や前後関係を意識しながらWBSと日々睨めっこしてました。

WBSのタスクには遅れてもそこまで問題にならないものと、遅れると全体のスケジュールを遅らせるものがあります。後者が俗にいう「クリティカルパス」です。プロジェクトマネジメントにおいてクリティカルパスの発見と遅延防止は本当に重要な仕事です。クリティカルパスは以下の画像のように表されることが多いですが、実際はこんなにシンプルな図で表せるものではありません。もっと関連タスクが多いし変数も多いし、そもそもタスクの洗い出し自体が難しかったりします。


https://www.jooto.com/contents/critical-path/

 

プロダクトマネージャーになった今は、WBSは作らないしこのようなクリティカルパスの定義も丁寧にしないですが、頭の中で常に「どれがクリティカルパスになりうるか?」は考えています。例えば大きめのリリースをなるべく早く行いたいときに、発生するタスク(社内ステークホルダーへの説明、ヘルプページの更新、メンテナンス準備など)をどのように進めるのが最も確実に早く進められるのかを考えます。思いついた順にやるだけでは、どれかがボトルネックになって待ちが発生してしまいます。

 

 

おわりに

ウォーターフォールのプロジェクトマネジメントを経験されてる方にとっては当たり前の内容かと思いますが、最近はアジャイルネイティブのプロダクトマネージャーも増えてきているかなと思うので、誰かの役に立ったら幸いです。もし役に立ちそう、取り組んでみたいと思っていただけたら、プロジェクトマネジメントを学ぶことをお勧めします。

もし内容についてご意見やご質問がありましたら、TwitterでDMいただくかMeetyでお話しできればと思いますので、お気軽にご連絡ください。

 

おすすめの本はこちら

先制型プロジェクト・マネジメント―なぜ、あなたのプロジェクトは失敗するのか | 長尾 清一 |本 | 通販 | Amazon

ザ・ゴール | エリヤフ ゴールドラット, 三本木 亮, 稲垣 公夫 | 英米の小説・文芸 | Kindleストア | Amazon

PMBOK®ガイド第7版日本語版 販売および出荷開始のお知らせ|お知らせ|一般社団法人 PMI日本支部

ジョブ理論を活用する難しさについての雑記

プロダクトマネージャーの方々であれば、「ジョブ理論」を一度は耳にしたことがあると思います。

 

自分は以前、クレイトン・M・クリステンセン教授が著した書籍「ジョブ理論」を読んだ学びと、UX DAYS TOKYO 2018のJim Kalbach氏のJobs To Be Doneのワークショップにて得た学びを、こちらのスライドにまとめました。これが結構ご好評をいただいていました。

speakerdeck.com

 

こちらを先日少しアップデートしてツイートしたところ、興味を持っていただいたギルドワークスの@yohhatu さんからお声がけいただき、ジョブ理論の活用についてお話させていただきました。

 

この記事では、そのお話の中で盛り上がった「ジョブ理論を活用する難しさ」について備忘録的に書いていきます。

 

そもそもジョブ理論とは

↑のスライドをご参照ください(・∀・)

よろしければ感想をツイートしてください(・∀・)

 

その1:ジョブを見つける、評価する難しさ

書籍「ジョブ理論」の中で、ジョブは主にインタビューや観察にて見つけるとされています。つまり主に定性データを元にジョブを見つけていく必要があります。

個人的な考えですが、この定性データ分析には人間の思い込みやバイアスが大きく影響します。つまりインタビューで出てきたいくつかのジョブ候補に対して、フラットな評価が非常に難しいと考えています。

例えば、既に多くの時間をかけてある程度自信のある仮説ができてきた中で、その仮説に全く当てはまらないジョブ候補が出てきたときに、無意識のうちに「これはレアパターンだ」と捨ててしまうリスクがあります。これが定量データだと数字で顕在化するので無視しにくいのですが、定性データは分析・整理の過程でいくらでもバイアスを潜り込ませることができるので、より無視してしまうリスクが高いと思っています。無意識のうちに無理やり「既定路線」に着地させようとしていないか、自分自分を客観的にチェックする必要があります。

 

また、定性データを元に定めたジョブが本当に正しいのかどうかを、定量データと合わせて評価する必要があります。数字で効果が出ていないのであれば、そのジョブが間違っている可能性を疑わなくてはいけません。

この評価プロセスをUXデザイナー・UXリサーチャー・データサイエンティスト・エンジニアなどと協力してやっているPMの方も多いと思います。そのように複数人で定性分析と定量分析を分担している場合、ジョブを定義するに至った細かいコンテキストを全員で共有できていないと、正しい評価ができないリスクがあります。

 

続きを読む

RSGT2021に行ってきたのでレポートをする

2020年1月6日から3日間、Regional Scrum Gathering Tokyo 2021が開催されました。

2021.scrumgatheringtokyo.org

 

もちろん…

参加しました!(`・ω・´)

初参加です!

 

 

去年と一昨年は、参加もしてないのにTwitterに流れてくるスライドを見つけてレポートをするという暴挙をしていただけだったのですが、今年はついに参加できました。


 

というわけで学びや気づきのレポートをしていきます。

 

Rethink Scrum from a Japanese cultural perspective

speakerdeck.com

 

組織文化を「場の文化」と「個の文化」にわけてスクラムを見つめ直すアプローチ。「場の文化」の支配が強すぎると同調圧力やアンラーニングの失敗などによって合理性とは反する力学が働いてしまうし、「個の文化」の支配が強すぎると共感がないためただ契約関係の中だけでの協働となってしまい、チームの相乗的なパフォーマンス向上は望めない。

要はここのバランスを取りながら、ちょうどいい「場」を作るのがリーダー(TOYOTAでいうチーフエンジニア)の役目なんだなという学び。楽天公用語を英語にした狙いが、「場の文化」に「個の文化」を取り込むためだったというのは驚きだった(英語の方が相手に合わせた表現の使い分けや婉曲表現のバリエーションが少ないため「個の文化」にシフトするとのこと)。

 

リーダーももちろんこの組織文化の中にいる一人の人間なのだが、場と個のバランスがどうなっているのか、暗黙的にどの力の支配力が強くなっているのかを、中にいながらそれに染まらずに組織を客観視して見極めなければいけない。要はシステム思考を持たなければならない。難しい仕事だなあとしみじみ。

 

“あざとくて何が悪いの?”建設的であり続けたいだけの、人たらしチームマネジメント

speakerdeck.com

チームのパフォーマンスを高めたり物事を円滑に進めるためなら、あざとく打算的に振る舞わないといけないという内容。大事なメッセージを伝えたいときは画面の40〜50%になるように映るとか、プレゼン時は資料ではなく参加者のリアクションを見るとか、非常に細かい振る舞いなんだけどこの積み重ねは本当に後からじわじわ効いてくると思う。自分も結構相手のリアクションを見ながら態度や話し方を変えるタイプなのだが、それは別に嫌われたくないとかの理由ではなく、ただ物事を早く正しく前に進めたいからだけなのよね。

組織は人間の集まりなので、どうしたって感情的で非合理な力学が働いてしまう中で、いかに建設的な状態を保てるかはこういう泥臭い人間力みたいなものにかかっている。ただこういう動きをしていると理不尽なことも多く、結構ストレスフルなのでサーバントリーダーの如く「チームがうまくいく」ことを心底願っていないと途中で心が折れてしまうかもしれない。なので、こういう「あざとい」マネージャーを見かけたら、時には優しく接してあげてくださいw

 

 

ヒット商品を生み出すプロダクトマネジメントブースター

speakerdeck.com

このセッションと及部さんの『「わからない」と共存するチーム May the CHAOS be with team』で共通していた「未知のわからないが多く存在するにもかかわらず、既知のわかる・わからないの中で意思決定をしてしまう限定合理性の恐ろしさ」は非常にいい気づきになった。だからこそ我々はスクラムアジャイルで経験主義的アプローチをしていく必要があるのだ。

たがか知れてる我々の認知能力を過信せずに、未知のわからないを問い続ける姿勢を忘れてはいけない。そのために現場に行ってユーザーの課題を探ったり、事実を集めて柔軟に軌道修正していかねばならない。アジャイルの基本を改めてぶつけられた気がしたいい機会でした。

 

スクラムにおける「完成」とはなにか?

スクラムにおける「完成の定義」について、個人的に答えのわからないモヤモヤしたテーマだったのだが、このセッションのおかげで少しモヤが晴れた。

自分のモヤモヤの内容は、品質担保のためにある程度画一的な定義が必要なのは理解しているものの、とはいえPBIの種類によっては例外がどうしても生まれてしまい「あ、これはいいや」を繰り返しているといつの間にか形骸化していく、というもの。なので完成の定義をしっかり言語化することの意義をあまり見出せていなかった。

しかしこのセッションでは形式知としての完成の定義には限界があり維持もできないと言い切ってくれて、残りの部分は人間の力で随時更新していき、最終的に共通理解にすることで担保していくべきだというお話で、スッと腹落ちした。

 

 

What’s Testing Got to do with Quality?

プロダクトの品質に対する重要な示唆に富んだセッションだった。特に刺さったのが、品質を評価するのはQAでもステークホルダーでもなく顧客であるということ、そしてテストは顧客の様々な目線に立って行う必要があるということ。文字にすると当たり前なのだが、現場では時に忘れてしまうので常に心に留めておきたい言葉。

このセッションを聞きながら以前属していたスマホアプリを作るチームにいたQAエンジニアを思い出した。この方は本当にユーザー目線に立っていて、PMやデザイナー、エンジニアが思いつかないような使い方をシミュレーションして様々な不具合を見つけてくれて本当にありがたかった。まさにユーザーの代弁者となってくれていた。

このスタンスをチーム全体にインストールしないといけないし、それを実現するために以下の記事にあるようなループを回していかないといけない。

janetgregory.ca

 

独立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

speakerdeck.com

弊社のスーパーQAチームを率いるKawarada-san。自分はまだジョインして半年でこのスライドで紹介されている事例は詳しく知らないので、客観的にすごいなーと思った。

時々社内勉強会でKawarada-sanと「QAとスクラムチームの関わり方」や「テストに対する考え方」について話をするが、個人的にはここに唯一解はなくて組織と状況に合わせて最適な距離感や関わり方を見つけていくしかないと思っている。スライドにもあるように、「丁寧なコミュニケーション」を相互に繰り返していって成長していくしかない。これからもよろしくです。

 

野中郁次郎先生のクロージングキーノート

なんか感想を書くのも憚られるほど濃密で深いお話でした…恐らく10%も正しく理解できていない気がする。しっかり書籍も拝読しながら時間をかけて自分の中に落とし込んでいきます。

とにかく受け取ったメッセージとしては、誰かが作った形式知(理論やフレームワーク)に頼るのではなく、自分たちの共感や経験から得た暗黙知によって生み出した形式知に頼っていこうということ。勇気をもらえる貴重なお話でした。

 

 

 

 

以上、レポートでした。スライドはこちらの記事にまとめていただいているのでご参照ください。

scrummasudar.hatenablog.com

 

今回書いたセッション以外にも素晴らしいセッションがあったし、参加者交流(OSTなど)でもいろいろな話が聞けたので、参加してよかったです。悔やむべきは、自宅からの参加だったので中途半端に仕事もやりながらになってしまい、ネットワーキングに全力を注げなかったこと。来年は会場に行けるといいな。

2020年の振り返りと2021年の抱負

あけおめ

(ノ・ω・)ノウェーイ

 

昨年同様、2020年の振り返りと2021年の簡単な抱負をまとめてみます。

 

仕事

何より転職が大きなイベントでした。

 

これまで大企業でしか働いていなかった自分にとっては、CAMPFIREで働いた期間に得た経験はかなり貴重なものでした。小さく未熟な組織で、裁量と責任を持ってプロダクトや組織に向き合う日々は刺激に溢れるものでした。担当していたCAMPFIRE Ownersのローンチと、最低限のグロースまではできたかなと思う一方で、もっとできたことはあったなと後悔もたくさん残っています。

 

そして6月にグロービスにPMとしてジョインしました。元々教育分野に強い興味があり、学習によって意識と行動を大きく変えられた自分自身の原体験をより広げたいと思い、教育業界に飛び込みました。この領域はまだまだテクノロジーが十分に活用されておらず、開拓の余地が多分にあると思っています。余白しかねえっす。

 

現在は特定のプロダクトのPMというより、横断系プロジェクトの推進やプロダクト戦略の整理・検討など、どちらかというと裏方に回ってます。我々が届けたい価値を世界中に届けるために、まずは土台固めに注力している感じです。ジョインして半年である程度自分がやるべきことが見えてきたので、2021年はギアを2段階ぐらい上げて走っていき、我々が目指す世界に少しでも近づけたいと思います。

 

転職活動期はこちらにまとめています。

productmanager55.hatenablog.com

 

副業

2019年12月からアルプ株式会社でお手伝いをさせてもらっています。週1しか稼働できていないのは申し訳ないなと思いつつ、スタートアップならではの本業ではできない経験を積ませてもらって感謝しております。

自分の仕事として、このリリースにある分析機能の構築を任せてもらいました。Scalebaseはこれから伸びていくプロダクトだと思うので、今後が楽しみです。

prtimes.jp

元々副業を始めた目的は「他組織の文化や手法を知ることで、本業における無用な『暗黙の了解』や非効率を是正したい」でした。アルプにおけるドキュメントのまとめ方やコミュニケーション文化はかなり参考になる部分が多く、しっかり真似させてもらっています。

 

登壇

2020年はなんと一回も登壇機会がありませんでした(´・ε・`)

コロナのせいでイベント自体も減ったこともありますが、ゼロは反省…

2021年は積極的に人前に出ていこうと思います。

 

取材・メディア掲載

キャリア系のメディア2つでインタビューしていただきました。

www.kiitok.com

eng.kandc.com

 

個人的にはいつかプロダクトマネジメント系、あるいは教育系のメディアに掲載されたいなと思っているので、お声がかかるようになるために日々精進して参ります。

 

コミュニティ・イベント運営

今年もプロダクトマネージャーカンファレンス2020の運営をお手伝いさせていただきました。2019年は当日だけのお手伝いだったのですが、2020年は企画段階から参加させていただきました。

各業界のPMの方々と一つのカンファレンスというプロダクトを創り上げるプロセスを経験できたことは非常に良かったです。参加者・登壇者・スポンサー様にとって何が価値なのか、それをどのようにデリバリーするのが最適なのか、(初めてのオンライン開催なので)不確実性やリスクにどう対応していくのかなど、まさにやってることはプロダクトマネジメントそのものでした。運営の皆様は各業界の第一線で活躍されている方ばかりなので、毎週の定例の中で時々手法論に走ってしまった際でも、議論の中で自然と「本質的な価値」に立ち返ることができていたのが印象的でした。

自分は主にセッション選定と登壇者コミュニケーション、当日のオペレーション検討、トラックAの画面スイッチングなどをやりました。特に当日のオペレーション検討は、自分自身にとってもpmconfにとっても初めてのオンライン開催ということで、ゼロから検討を始めたため非常に難しいものでしたが、当日何も問題は起こらず好評を頂けたので一安心でした。

(こんな感じで当日の動きをまとめてました。Miro便利。)

f:id:swnws322:20201231134303p:plain

 

この辺の裏話やチームビルディングなどの話はここにまとめてあります。

note.com

 

もちろん来年もやりますぜ( ◞•̀д•́)◞

f:id:swnws322:20201231132851p:plain

 

プライベート

コロナ禍でひっそりと引越しをしていて、さいたま市民から東京都民になりました。

その目的は2つあって、1つは奥さんの職場(アトリエ兼ショップ)が蔵前にできたことと、もう1つは猫を飼いたかったからです。

 

日々幸せな猫ライフを楽しんでおります(´∀`*)

 

その他

2020年は大半を自宅で過ごしたことで、リアルで人と会う機会は激減しましたが、一方でPM界隈の方とオンライン雑談する機会は増えたような気がします。大体はTwitterで何かの話題で盛り上がって「一度話してみましょう」みたいな流れですね。場所の制約が無くなったことにより、気軽に誘う(誘われる)ようになれたと思います。

現在もMeetyでカジュアル面談を受け付けてます。

meety.net

 

2020年の読書量は49冊でした。月4冊ペースですね。もう少し増やしていきたい。

bookmeter.com

そのうちのおすすめトップ10はこちら

f:id:swnws322:20201231145703p:plain

 

2020年からオンライン英会話を始めました。

今まで何度か挑んでみては挫折してきましたが、今の職場に外国人が多く日々のコミュニケーションで必要で、かつこれから海外市場にも挑んでいくという明確な目的意識があるおかげで継続できています。

自分はBizmatesを使っています。今のところ順調に少しずつ上達してきており、レッスン前に5分くらい雑談できるようになりました。こうなるとどんどん楽しくなってきますね。2021年もしっかり継続していきます。

 

 

最後に…2020年の最初に立てた「ループミュージックのYouTuberになる」という目標に対して、ほぼ何もアクションできなかったので2021年こそトライします。

 

 

 

というわけで2020年の振り返りと2021年の簡単な抱負でした。

みなさま今年もよろしくお願いいたします。

【スポンサーリンク】