2023年の振り返りと2024年の抱負
あけおめ
(ノ・ω・)ノｳｪｰｲ
毎年恒例となりました、昨年の振り返り＆今年の抱負記事を書きます。
もはや誰かに見せたいようなものでもなく、自分の定点観測として書いています。
そしてこのひとつ前の記事が昨年の元旦の振り返りとは…全くブログを書かない体になってしまいました。
仕事
グロービスにジョインして3年半が経ちました。
2023年度から正式にDirector of Product、要はPM of PM的なロールになり、プロダクト開発組織をガッツリテコ入れした年となりました。チームを小さく分割して大胆に権限委譲する改革を行いました。
結果としてはデリバリー速度やスループットは飛躍的に高まり、過去最大のリリース量と進捗を実現することができました。反面、チームが増えたことで目線が合わなくなり、アウトカム思考が弱まったり部分最適が進むデメリットも発生しました。それに対し都度打ち手を考え、現在進行形で日々奔走しております。
この組織変革の詳細は、こちらの２つに記事に記載しておりますので、お時間ある方はどうぞ。
というわけで、PM of PMの難しさを痛感した一年でした。
なるべく現場に下りずに権限委譲をして組織を強くする目論みでしたが、自分の方針・戦略の言語化のやり方や権限委譲後のサポートの甘さなどから、なかなか狙い通りになりませんでした。また、その対処に奔走するあまり自分の時間がほとんど取れず、PM of PMとしてやるべき「未来を考えること」に時間を割けなかったのは反省点です。本当はプロダクトマネジメント組織の設立や、プロダクトマネージャー評価制度の整備などにも着手したかったのですが、その余裕はなかったので今年に持ち越しです。
とはいえ、少しずつできるようになってきているので、24年度は組織にとって、そしてプロダクトにとって飛躍の年になる予感があります。一通り降るべき雨は降った感じはあるので、ここから地面を固めていくフェーズになりそうです。（もう数回大雨が来る可能性もありますがw）
続きを読む
2022年の振り返りと2023年の抱負
あけおめ
(ノ・ω・)ノｳｪｰｲ
毎年恒例となりました、昨年の振り返り＆今年の抱負記事を書きます。
仕事
グロービスにジョインして2年半が経ちました。
2022年はなんといっても担当プロダクト（toB向けの管理機能）の大型リニューアルプロジェクトを完遂できたことが何よりの喜びでした。同僚にもかなり助けられながら大きなトラブルなくリリースできたのは本当に良かったです。とはいえまだまだ成果に繋がっているわけではないので、2023年もガンガンプロダクトを成長させていきます。GLOBIS 学び放題の法人プロダクトにご期待ください。
個人としては、徐々にプレイヤーからマネジメントレイヤーにシフトし始めています。プロダクト組織のパフォーマンスを最大化するためにすべきこと（仕組みづくり、育成・評価制度の整理など）を推進する役割になりつつあります。"Product Ops"に近いかもしれません。
100人を超えるプロダクト開発組織でのマネジメント経験は初めてなので、試行錯誤しながらにはなりますが、2023年はここにしっかりコミットします。現場を見たくなる衝動、細かいところに口出ししたくなる衝動をどれだけ抑えられるかが勝負ですw
その活動の一環で、プロダクトマネジメント組織の設立も考えています。GLOBIS 学び放題はEdTechに分類されることもありますが、昨今のリスキリングや人的資本経営の流れから人材育成の重要度が急上昇しており、もはやHRTechと言ってもいいかと思います。HRTechはかなり群雄割拠かつニーズが多様な市場なので、柔軟かつ迅速に動く必要があります。現在のPM人数だけだとこれに対応できないことが見えてきたので、プロダクトマネジメント組織の設立とPMの増員を企んでします。というわけで、一緒にこれを楽しんでみたいPMの方がいらっしゃたらTwitterでDMください。
一方で、昨年は久しぶりに大きな失敗というか挫折のようなものに直面した年でもありました。詳しくは書けないですが、これまでの自分の経験や知識・スキルばかりを信頼し、周りに対して少し傲慢になってしまったことが理由だと自己分析しています。
2023年は「謙虚さを忘れない」ことに気をつけて過ごしたいと思います。
続きを読むやりづらい環境でも地味に地道に頑張るPMたちへ
この記事は地味PM Advent Calendar 2022の19日目のエントリーです。
グロービスでPMをやっている久津と申します。
地味PM meetupの初回でも登壇させてもらいました。
地味PMの名に恥じぬよう、今日も地味で普通のことを書きたいと思います。
ためになる話もエモい話もありませんのであしからず。
ところで、あなたは成果を出せていますか？
いきなり圧が強くてすいません。
ご存知の通り、プロダクトマネージャーという役割にはプロダクトの成長などの「成果」が求められます。そのためにみなさん日々奮闘されていると思います。
いくら機能をリリースしても、いくらイケてるプロダクトビジョンを作り上げたとしても、プロダクトや事業がグロースしなければ意味はありません。
ですが、そんなに簡単に成果って出ないですよね。
そんなに簡単な仕事ではないですよね。
プロダクトマネージャーにとって、なかなか成果が出ない時期はかなり精神的にきついものです。ついつい「自分の立てた仮説が根本的に間違っているのか？」「あの時の判断が失敗だったのか？」「もしかして自分にはまだ十分なスキルが備わっていないのではないか？」と考えて落ち込んでしまうこともあります。
ただ、このように疑念や不安が「自分」に向いているのは良い行い、良い問いかけだと思っています。もちろん過度に自分を責め立ててパフォーマンスやメンタルが崩れてしまってはダメですが、適度な内省はプロダクトマネージャーにとって大事なことです。
一方「いつもステークホルダーが邪魔してくるから成功しないのではないか？」「うちの開発チームのパフォーマンスは低いのではないか？」「この市場にはもうチャンスがないのではないか？」のように、周りの環境が原因だと考えることもあるでしょう。これについては一概に良いも悪いも言えません。
大した分析もせず、自分の可愛さのあまり他責にするのは問題外ですが、本当に「やりづらい環境」であり、そのせいで成果がなかなか出ない可能性は確かにあります。それであれば、そこの解決に向けて動くのは当然のことです。
ですが、自分を変えるより周りを変えるほうが難しいのです。
成果を出すために周りを変えたいけど時間がかかる。その間も成果が出ない期間が続く。プロダクトマネージャーとしての自信がなくなっていく。気づけば年を取っていく…
「よし、すぐ成果が出そうなやりやすい環境に転職しよう」
こう思ったことのある方も多いのではないでしょうか？
もちろん私も何度もありますし、それが悪いことだとも思いません。
けど、この記事で私が言いたいのは
「やりづらい環境でも成果を出すために地味に地道に土台づくりをするPMも尊いよね」
ということです。
続きを読む職種に求められる役割やスキルは環境変数次第だよね、という雑記
最近以下のような問いによく出会います。
「プロダクトマネージャーはどこまでを担うべきか」
「スクラムマスターはどこまで踏み込むべきなのか」
「デザイナーとPMの境界線はどこか」
「プロダクトマネージャーが持つべきスキルは何か」
要は「職種の定義」というやつですね。それぞれの職種が一般的にどのような役割とスキルを持つのが望ましいのか、というような議論をあちこちで目にしますし、意外とこれ盛り上がりますよね。おそらくそういう記事はPVを集めやすいのだと思いますし、私も昔そういう記事を書いたことがあります。
ただ、私は最近「どうでもええやん」と思うようになりました。
それは、これまで何度か転職をして様々な環境で様々な役割を担い、様々な人たちと仕事をしてきた中で、「職種に求められる役割やスキルは、周りの環境によって決まる相対的なものである」と確信を持ったからです。事業ドメイン、事業フェーズ、プロダクト特性、プロジェクト特性、組織規模、組織文化、組織状況など、様々な環境変数によって今求められる役割やスキルが決まります。
「シリコンバレーはこうやってます」みたいな情報は確かにキラキラして参考にしたくなりますが、自分の環境が持つ変数と、シリコンバレーの環境が持つ変数はどれだけ同じなのか？を考えないといけません。変数が異なるなら、その真似をしても今の環境では成果につながらない可能性が高いです。
pmconf2021のRetty 野口さんの発表にあった「Rettyに求められるPMの必要スキルの定義」のように、自らの環境の変数を踏まえて定義されたものは、この組織で活躍するために必要な指標なので、非常に有用なものだと思います。
ただ、そういう環境変数を考慮しないで「この職種にはこのスキルが必要」「ここまでがこの職種の役割であるべき」と一般的に定義されたものを盲目的に信じてもあまり効果はないと思いますし、それに囚われ過ぎるとどこの組織にもハマらない凡庸な人材になってしまうリスクがあると思っています。
もちろん、今所属している組織が持つ変数がよくわからず、かつ組織内にロールモデルとなる人がいないような環境であれば、「一般的な定義」を参考にして役割や得るべきスキルを見出していくのはアリだと思いますが、それが今の環境にハマっているかどうかは別問題です。一時的に成果は出たとしても、併せて環境変数を見抜いて役割をチューニングしていく動きも求められます。
また、逆に「一般的な定義」や「他社の定義」を自分の環境で実現するために、環境変数の方を変えにいくアプローチもあります。上の例で言えばシリコンバレーのやり方ができるように環境をシリコンバレーのように変えていく、という使い方もアリだとは思います。ただ、本当にそれが今の環境に求められていることなのかは見極めるべきです。
つまり言いたいのは「一般的な定義や他社の定義を参考にするなら、その裏にある環境変数も理解しようぜ」ということです。もちろんめちゃくちゃ難しいことを言っているのは自覚してますが、それをやっていかないとただの自己満足に終始してしまうリスクがあると思うのです。なので書籍や他社の事例を見て参考にしたい際には、可能な限り発信者に背景を聞きにいくことをお勧めします。
そしてこれは職種の役割に限らず、フレームワークにも共通する話です。スクラムとかOKRとか、イケてる企業が使ってるフレームワークが自分たちにも有効かどうかはやはり変数次第です。これらのフレームワークを活用したいなら、変数の方を合わせてから導入するべきだと思います。例えばOKRの恩恵を受けたいなら、チームへの適切な権限委譲をしないといけません。ただのTODOリストになってしまいます。
以上、最近よく思うことを雑に書いてみました。
昨年はブログの更新頻度が著しく減ってしまったので、今年はあまり準備せずに気軽に書いていきます。
2021年の振り返りと2022年の抱負
あけおめ
(ノ・ω・)ノｳｪｰｲ
毎年恒例となりました、昨年の振り返り＆今年の抱負記事を書きます。
仕事
グロービスに2020年に6月にジョインし、早くも1年半が経ちました。
最初は横断系プロジェクトのPjM的な動きから始め、その後法人プロダクトのPO/PMを担いました。
社会人教育のtoBプロダクトは非常に面白いと同時に難しく、今でも満足する成果を出せていません。やりたいけどできていないこと、思った通りに進まなかったことも多かったですが、少しずつ前には進んでいる実感はあるので、2022年もよりギアを上げていく所存です。
グロービスのtoBプロダクトの面白さと難しさを語った記事はこちら。
productmanager55.hatenablog.com
また公に堂々と自慢できる我がチームの成果はこちら。
そして、PMの役割以外に「ネオ・何でも屋」の動きも始めました。
採用をはじめとした組織戦略、長期的な視点でのプロダクト戦略、問題が深刻化しつつある技術的負債＆運用負債の解消戦略など、プロダクトや組織を俯瞰して大きな変革を起こす動きを取り始めています。この役割を何と呼べばいいのか分からないので、適当に「ネオ・何でも屋」と名付けてみましたw
これはまさに2022年の大きなチャレンジなので、気合入れて取り組んでいく所存です。
今後採用へのコミット度合いを強めていく決意をした。というわけで求人ページ整理はこれからですが、PM・デザイナー・エンジニア全方位で絶賛採用募集中です💪というか助けてください😭
— 久津佑介(HisatsuYusuke) / プロダクトマネージャー (@Nunerm) 2021年11月25日
少しでも興味のある方はDMでもリプでもMeetyでもいいのでお気軽にお声がけください🙌https://t.co/8ZHHP1NgYs
副業
2019年からお手伝いさせていただいたアルプでのお仕事は一旦一区切りとさせていただきました。理由はシンプルで、本業がどんどん忙しくなってきた＆週一休み生活が辛くなってきたからです。
トータル１年半くらい関わらせていただき、いろいろなことを学ばせていただきました。受け入れていただいた皆様には感謝しております。
現在は、とある企業のDX支援的なお手伝いをさせていただいてます。本業の忙しさはまだ変わらないので、作業で貢献するというより知識と経験を基にアドバイスさせていただく形で関わらせてもらってます。この形でもしっかり価値を発揮できるかどうかが、自分の中のチャレンジでもあります。
登壇
3月の「プロダクトオーナー祭り2021 Spring」で登壇させていただきました。
複雑系と対峙するプロダクトマネージャーが持つべき「システム思考」について話させていただきました。他の登壇者の方々と比べて非常に堅苦しく抽象的な内容だったにも関わらず、質疑応答コーナーに結構集まっていただいたのは嬉しかったです。
2021年はこの１回だけでした。もう少しアウトプットせねば…
今年はいよいよプロダクトマネージャーカンファレンスの公募に挑もうかなと密かに思ってます。
取材・メディア掲載
ProductZineさんの「PMが知っておくべき、プロダクトマネジメントで重要な100のこと」というシリーズの第６回に寄稿させていただきました。こちらでもシステム思考の話を書かせていただいています。いつも拝見してるメディアへの寄稿の機会をいただけるのは嬉しいですね。
そして、いつもジョギング中に聴かせて頂いている、あのfukabori.fmにも出させていただきました…！と言っても、私個人としての出演ではなく、プロダクトマネージャーカンファレンス実行委員会の代表として出演でした。
今回初めてのPodcastだったのですが、自分の話し方のダメさ加減がよくわかりました。とはいえ収録は非常に楽しかったので、今後機会があればトライしてみたいなと思います。（一人語りは辛いので、誰かと一緒にやりたいw）
コミュニティ活動
今年もプロダクトマネージャーカンファレンス2021の実行委員会を務めさせていただきました。しかも、今回はこれまで横道さんが担われていたプロジェクトリードの役目を仰せつかりました…！
いや〜大変でした！！
まず前提として、運営メンバーは全員有志のボランディアで、本業やご家庭の都合の隙間を縫って活動されているため、人やタイミングによって稼働できる時間が異なります。その中での役割分担やタスクの割り振り、スケジュール設定などが非常に難しく、過去に類を見ないタイプのプロジェクトマネジメントでした。その分色々と学ぶこともでき、結果的にカンファレンスも大成功となったので大変満足です。
カンファレンスの結果はこちらの記事をご覧ください。中の人として書きました。
今年は初の無料化やアーカイブ動画の公開など、新たなチャレンジも取り入れました。来年のプランはまだ全く決まっていない、というか議論すらしてないのでどうなるかわかりませんが、どうせこの好奇心旺盛なメンバーのことなので、また新たなチャレンジを盛り込んだ進化したプロダクトマネージャーカンファレンスになるはずです。というわけでお楽しみに！
またpmconfのご縁もあって、横道さんの翻訳された『プロダクト・レッド・オーガニゼーション』の翻訳のお手伝いに、本当に少しだけですが参加させていただきました。初めての体験でしたが、翻訳って難しいなあと改めて実感しました。
本日の #pmconf2021 にもご登壇いただいたPendoさんのCEOの方が書かれ、@ykmc09 さん翻訳の『プロダクト・レッド・オーガニゼーション』を献本頂きました🙇♂️本当に本当にすこーしだけ翻訳のお手伝いをさせていただきました。めちゃ良い本で学びが多いのでぜひお読みください！（15,16章がオススメ） pic.twitter.com/eco3uNE57u
— 久津佑介(HisatsuYusuke) / プロダクトマネージャー (@Nunerm) 2021年10月26日
プライベート
自分にはそんなに書くことはないので、奥さんのブランドを勝手に宣伝しますw
脱サラしてジビエレザーによるものづくりをしています。一人でやっているのでまだまだ小さいブランドですが、ちょこちょこ手伝いをしている中で、着実に成長していると横から見てて感じます。個人事業主として一人でここまでできるのは、純粋にすごいなって思います。そして同時にサラリーマンって守られた存在だなってつくづく感じましたw
蔵前駅前のウグイスビルという建物にショップがあるので、蔵前に来られた際は立ち寄ってくださいませ（土日のみです）。
あと我が家の猫は順調に育ってます。
君、バチクソかわいいな pic.twitter.com/ZQ9BTpouNH
— 久津佑介(HisatsuYusuke) / プロダクトマネージャー (@Nunerm) 2021年12月29日
その他
2021年の読書量は39冊となり、昨年と比べてかなり減ってしまいました。これは大反省。
その中での「2021年に読んだ本のおすすめランキング」はこちら。
ビジネス書以外に宗教系の書籍があるのは、最近仏教的思想（執着を捨てること、流れを見極めることなど）が今の自分に必要なのではないかと思っているためです。書籍を読んだり京都の寺に行ったりしましたが、まだまだちゃんと理解できていないので、一度寺に修行に行こうかと企んでいます。
2022年に向けて
2021年は仕事とpmconf運営にがむしゃらになりすぎて、自己研鑽が疎かになってしまいました。
仕事のところにも書いた通り、今後は組織戦略周りにも積極的に携わっていくつもりなので、マネジメント・リーダーシップ・コーチング周りを改めて勉強し直すつもりです。これまで、経験と独学で積み上げた知識とスキルだけで勝負してましたが、それでは通用しないなと思ったシーンに何度か直面したので、改めて体系的に学んでいきます。
今のところまだ具体的な計画を立てていないので、スクールなど何かオススメの方法があれば教えていただけると幸いです。
また同時に英語のレベルも飛躍的に上げたいです。昨年から英会話を始めましたが、ある程度のレベルに達してからの頭打ち感が出てきて、そこから少しサボり癖も出てきてしまったので、気合を入れ直します。ちょうどアメリカに拠点ができたこともあり、アメリカに渡って海外事業に関わる野望も密かに持っているので、ビジネス英会話を苦なくできる状態を目指します。
というわけで2021年の振り返りと2022年の簡単な抱負でした。
皆様、今年もよろしくお願いいたします。
GLOBISのtoBプロダクトの面白さと難しさを語ろう
この記事はGLOBIS Advent Calendar 2021 の21日目の記事です。
見ての通り、これまで我々が誇るエンジニアたちの技術寄りの記事が多い中、PMである私は空気を読まずに担当しているプロダクトについて語ります。
社会人教育という分野で、非デジタルの既存事業を持ち、グローバル展開までしているGLOBISならではの面白さや難しさを存分に語らせていただきます。
プロダクトの紹介
私が担当しているのはGLOBIS 学び放題/GLOBIS Unlimitedというプロダクトです。どちらもビジネスパーソン向けの定額制動画学習サービスで、歴史あるグロービスのMBAで培ったノウハウを詰め込んだ良質な学習コンテンツを多く取り揃えています。
GLOBIS 学び放題は国内向け・日本語コンテンツを提供しており、既に動画は3,900本以上となっています。
GLOBIS Unlimitedは海外向け・英語コンテンツを提供しており、こちらはまだ立ち上げ期なので動画は125本ですが、かなり海外戦略に力を入れており今後もどんどん追加しいく予定です。
上記の２つのLPはどちらもtoC向けのページで、知名度としてもtoCサービスが比較的高いかなと思います。ですが、実はtoB向け、つまり法人企業様向けにもサービスを提供させていただいております。
既に2,400社以上の企業様に導入いただき、様々な組織課題の解決のためにご活用いただいております。
私のチームでは、主に人事の育成担当者様が使う管理機能の開発や、先月ニュースリリースが出た外部LMSサービスとの連携など、法人事業に関わるプロダクト開発全般を担っています。
プロダクトの紹介はこのくらいにして、このようなtoBプロダクトを開発・提供することの面白さと難しさ、そして我々がどのような工夫をしているかを、プロダクトマネージャーの立場から語っていきます。
面白難しポイント①：ユーザーの課題が多種多様である
我々の顧客は法人企業様ですが、そこには大きく分けて３種類のユーザー（人）が存在します。
- サービスの導入を決める意思決定者（主に人事部門の責任者様）
- 学習促進や進捗管理を行う管理者（主に人事部門の担当者様）
- サービスを利用して学習をする受講者（社員の方々）
そして、各企業様の解決したい課題は多岐に渡ります。
- 管理職の中から次世代の経営人材を育てたい
- 組織に自ら学ぶ文化を醸成したい
- タレントマネジメントに活用したい
- 企業研修の効果を上げるために予習・復習教材として活用したい など
また、それぞれの顧客の組織の状況も異なります。
- 既に自ら学習する文化がある組織
- これから自ら学習する文化を作り上げたい組織
- 既に育成プロセスが構築されており、そこにGLOBISのサービスを組み込みたい組織
- 育成プロセスは無く、GLOBISのサービスを基点として構築したい組織
さらに、我々は海外市場にも挑んでおり、日本と英語圏では育成事情が異なります。特にアメリカの大企業では育成プログラムとLMS（Learning Management System）が構築されていることが普通であり、そこの生態系にうまく入り込めないと検討のテーブルに上げてもらうことすら難しくなっています。
このように「ユーザー」と一言で言っても、バックグラウンドやコンテキスト、課題の種類などが多種多様です。こうなると、単一のペルソナを定義してそこだけにフォーカスする戦略は取れません。だからと言って、全変数を考慮したペルソナ定義は非現実的です。
よって、我々のチームでは取り扱う変数を絞ってペルソナ定義をしてみました。
ユーザーインタビューの結果や営業・カスタマーサクセス部門に溜まっている情報を基に、解決するべき課題（ジョブ理論でいうところのジョブ）やソリューションの選択との因果関係が強い変数を絞り込みます。さらにその絞り込んだ変数を「Why/Whatに関わるもの」「Howに関わるもの」に分類します。（前者が☑️、後者が△）
上記の図の「受講者規模」を例に挙げてみます。（左から五番目）
受講者規模によってソリューションの選択は確かに変わり、大人数の場合はグループ作成機能や受講履歴一覧機能などで利便性や視認性が強く求められます。しかし、これらの機能で解決したい課題は「受講状況を正確に把握し、学習活性の効果を評価し、ネクストアクションにつなげたい」であり、それは受講者規模には関係ありません。少人数の組織でも同じ課題になります。つまりこれは「Howに関わるもの」です。
この「Howに関わるもの」は機能レベルの要件ではもちろん考慮が必要ですが、もう少し抽象的なユーザーストーリーレベルでは「How/What」に着目したいのであまり考慮しないようにしています。
このようにして、多種多様なユーザー属性をある程度抽象化して考慮すべき情報を意図的に削った上で意思決定をしていく工夫をしています。もちろんこの定義は不変ではありません。実際にデリバリーを繰り返して評価していく中で、思った通りの結果が出なかった場合はこの定義を疑って見直しています。
この点は難しく大変なポイントではあるのですが、世界中の様々な企業の組織成長の課題に向き合うという取り組みは非常に面白いと感じています。これによってより価値を増幅し世界の企業の組織成長に貢献できたら、本当に素晴らしいことだと思います。
面白難しポイント②：学習の活性化
我々のサービスは「導入したらすぐに効果が出る」といった類のものではありません。学習する機会やコンテンツを提供することはできますが、実際に社員の方々に学習していただくには「学習の活性化」が欠かせません。以下の図やこちらの記事のように、管理者の方に促進活動を行なっていただく必要があります。
ただし、人事の方は忙しい方が非常に多いため、なるべくここは省力化したい業務になります。
そこで、ほっといても学習活性が実現できる、スーパー学習活性機能を提供させていただきます！(´∀`*)
…と、言いたいところですが、こちらも非常に難しいポイントがあります。というのも、①で書いた通りユーザーの課題や状況が多種多様なため、どのような学習活性が効果的なのか簡単に選択できないのです。
例えば、能動的にサービス利用を選択した社員の方と、人事に言われて受動的にサービス利用をしている社員の方では、全くモチベーションが異なるため伝えるべきメッセージも変わってきます。toCプロダクトであれば、ユーザーは基本的に自らの意思で課金をした、つまり能動的なユーザーで占められていますが、我々のtoBプロダクトはそうとは限らないのです。前者には「次はこのようなコンテンツがオススメです！」というメッセージが効きそうですが、後者には「今月中に３つのコースを受けてみましょう」というメッセージが効きそうです。
しかし、我々はこの社員の方のモチベーションを区別できません。人事の方であればある程度把握できるかもしれませんが、現時点で我々が保持しているデータからの推測は難しいです。要は「ノリノリで学習しているのか、渋々学習しているのか」が学習履歴からはわからないのです。
ここはまだ我々が未熟なところで、今後定性データの取得や分析などを活用して進化させていきたいポイントになります。余白だらけってワクワクしますよね。
面白難しポイント③：導入効果の評価
ここが最大の難所です。GLOBIS 学び放題/GLOBIS Unlimitedを導入いただく法人企業様の目的は「組織成長」です。つまり「今の状態より良くなっていること」が求められます。
では、それをどうやって評価すれば良いのでしょうか？
例えば会計系のSaaSであれば「削減された業務時間」がわかりやすい評価軸かと思いますが、我々のサービスにおいてはわかりやすい数字がありません。もちろん「学習量」「学習頻度」のような数字はありますが、本当に追い求めるべき指標は「学習をした結果、社員あるいは組織がどう変わったか」になります。
しかし当然ですが、人や組織が変わる・成長する要因は学習だけとは限りません。現場での経験やマインドセットの変化、外部環境の変化など、様々な要因によって起こります。我々が提供させていただいた学習機会やコンテンツがどのように貢献できたのか提示できれば、より効果的な活用方法を示すことが可能になりますが、顧客の社内事情を細かく把握できないため、なかなか難しいのです。
現時点では営業やコンサルタント、カスタマーサクセスによるヒューマンタッチでここをサポートさせていただいておりますが、プロダクトマネージャーとしてはプロダクトでもここに貢献できないか挑戦してみたいと思っています。これからグローバル展開に注力し顧客数を爆発的に増やそうとしている我々にとって、人によるサポートに頼ってばかりではいけません。
これまでもβ版機能として「テスト機能」や「アンケート機能」などリリースして検証をしていますが、まだまだブラッシュアップする必要があります。これも難しいけれど楽しみな挑戦です。
おわりに
いかがだったでしょうか？「難しそう、やだな〜」と思いましたか？
私は「めっちゃ面白そう！やったるで！」と思うタイプですd(ﾟ∀ﾟd)
確かに難しいポイントが多く、まだまだできていないことも多いですが、これからの工夫や頑張りで新たな価値を提供できるようになると確信しています。
もし「面白そう！もっと詳しく聞いてみたい！」と思われた方は、私のTwitterのDMやMeetyからご連絡いただければお話しさせていただきます。お気軽にどうぞ！
また「ここで働いてみたい！」と思っていただけたら、こちらの採用ページから応募いただけるととても嬉しいです。全方位で積極採用中です！
さらに、1/12（水）にEd-Tech企業が集まるMeetupを主催させていただきますので、こちらにもどしどしご参加ください！
最後に我々の組織紹介資料を置いておきます。
プロダクトマネジメントに活きるウォーターフォールプロジェクトマネジメントの経験
こちらはプロダクトマネージャー Advent Calendar 2021 の21日目の記事です。
なんと10ヶ月ぶりのブログ投稿となってしまいました…！
久津（ひさつ）と申します。現在はGLOBISで法人向けプロダクトのPMをやっており、これまでのキャリアでエンジニア→プロジェクトマネージャー→プロダクトマネージャーという順で経験を積んできております。
この記事では、プロダクトマネジメントに活きるウォーターフォールプロジェクトマネジメントの経験について書きます。現在プロジェクトマネージャーで今後プロダクトマネージャーへのジョブチェンジを考えられている方、既にプロダクトマネージャーだがプロジェクト推進で悩まれている方の参考になればいいなと思っております。
プロダクトマネジメントとプロジェクトマネジメントの違い
これについては説明されている記事や書籍が腐るほどあるので割愛します。こちらの記事が最もわかりやすいかなと思います。
ネット記事やブログでは「プロジェクトマネジメント≠プロダクトマネジメント」という説明が多いですが、「プロジェクトマネジメント⊂プロダクトマネジメント」つまりプロダクトマネジメントに必要な要素にプロジェクトマネジメントがあるという解釈が個人的には好きです。
プロダクトマネジメントトライアングルやエンジャパン岡田さんが作られた「PM SkillChart HEX」でも、プロジェクトマネジメントはいち領域として定義されています。
ゴリゴリのウォーターフォールのプロジェクトマネジメント時代
私はリクルートテクノロジーズのプロジェクト推進部という部署で4年ほどプロジェクトマネジメントを担っていました。リクルートといえばデジタルプロダクト開発の最先端でアジャイル開発をしているだろうみたいなイメージをお持ちかもしれませんが、当時はウォーターフォール開発がかなり多く、かつ事業規模が大きいためプロジェクト自体も大規模なものになりやすい環境でした。
プロジェクト推進部は、プロジェクトマネジメントに対して本気で向き合っていた部署で、以下のような取り組みをしていました。
- PMBOKなどのナレッジをベースに独自にオリジナルスキームを作る（大規模プロジェクトガイドと呼ばれていた）
- プロジェクトの変数（人数/予算/期間/言語/業界など）やその結果を全てデータ化し、成功・失敗要因を科学する
- 独立したPMO組織を作り、プロジェクトマネージャーが気づかない潜在リスクを検知するために、プロジェクトの状況を客観的に評価をする仕組みを作る（リスクが見つかった場合は合理的な回避・軽減策を提示しないと次に進めなかった）
ただ漫然とタスク管理をしてWBSを引いて定例会議を開いてたわけではありません。プロジェクトマネジメントに真摯に向き合い、数々の大規模プロジェクトを推進して成功に導いてきました（もちろん失敗もありました）。
アジャイル・ウォーターフォール論争
最近「世界の不確実性が増してきたから、計画主義のウォーターフォールでは対応できない」「だからまず小さくリリースしてフィードバックを得ながら進む経験主義のアジャイル開発をすべきだ」という言われ方を多く見かけますが、私はそんなに極端に分けるのではなく「状況に応じてうまくハイブリッドするべきだ」と思っています。
もちろんシステムや組織の依存関係の少ないシンプルなプロダクトであれば、大掛かりな計画などせずに早く前に進めた方がいいとは思いますが、ある程度依存関係や複雑性を持っているのであれば、事前に必要最低限の計画を立てた上でしっかりプロジェクトマネジメントをしないと、プロダクト開発が前に進まないこともあると思っています。たまに見かけるのが、アジャイルに傾倒するがあまり計画が杜撰で、フィードバックサイクルを回して進んでるつもりが同じところをぐるぐる回っているようなプロジェクトです。
「大規模で複雑なプロダクトだが、多くの小さいチームでアジャイルを回せている」という組織ももちろんあります。それは依存関係を軽減させる仕組みやアーキテクチャ、または依存関係をコントロールする役割の人がいることで実現できているのだと思います。
もしまだその仕組みや人が存在せず、依存関係や複雑性と共にプロダクト開発、プロダクトマネジメントに挑んでいるのあれば、個人的にはハイブリッドのプロジェクトマネジメントをお勧めします。チームがアジャイル開発をしていたとしても、ウォーターフォールのプロジェクトマネジメントの勘所を知っておいて損はありません。
プロダクトマネジメントに活きていること
少し話が逸れましたが、本題に入ります。私はリクルート内での異動や転職の中でプロダクトマネージャーにキャリアチェンジしましたが、あの頃のゴリゴリのウォーターフォールプロジェクトマネジメント経験は、現在のプロダクトマネジメントの中でも存分に活きています。プロダクトマネジメントの責務とタスクが増えたので、相対的にプロジェクトマネジメントに割くパワーは減り、重厚長大な計画書やWBSを作ったりはしませんが、あの頃に得たスキルや考え方が役立っています。
ここからはその中でも特に日々役立ってることを書いていきます。
リスク感度が高くなる
ウォーターフォールのプロジェクトマネジメントの場合、最初にプロジェクト計画を行い、その中でリスク定義をします。ここでいうリスクとは、品質やスケジュール、コストや人に関わる問題の発生リスクのことを言います。例えば開発が予定通り進まないリスク、開発途中で要件が変わるリスク、リリース後に大障害が起こるリスクなどです。
このプロジェクトではどのようなリスクが起こりうるか、それが起こったらどのような影響が起こるのかなど、可能な限りリストアップしておきます。また、現時点でリスク評価が難しいものは、どのタイミングになったら改めてリスク評価をするのかを定義しておきます。
この考え方が頭にあると、プロダクトマネジメントの中で不意に発生する問題に対して強くなります。何か新しいこと始めるときに、一旦のゴールまでの流れをイメージしてリスクの存在をサーチし、影響の大きいリスクがあれば先に打ち手を決めておく、あるいは早い段階でリスク軽減の打ち手を打っておく癖がつきます。逆にリスク評価の結果、起こってもその場で対処できるし影響が少ないと判断すれば、今後そのリスクは特に気にせずプロダクト開発に集中する意思決定もできます。つまり起こってから慌てて考える場当たり的な対応を減らせます。
もちろん今考えてもわからないことを頑張って考える必要はありません。時間の無駄なので。ただ、少しの労力で調べて考えれば検知できるリスクは、早めに検知しておくに越したことはないという考え方です。
当たり前っちゃ当たり前の話なのですが、意外とリスク評価は難しいし大変なのです。評価のための情報を適切に集めないといけないし、どのような軸で評価すればいいのかもわからないことが多いです。プロダクトやプロジェクトの特性によって評価方法や基準は変わるので唯一の解はなく、自分なりのリスク評価軸を持って育てていくことが求められます。
勘違い防止力が上がる
ウォーターフォールのプロジェクトにとって恐ろしいのは「勘違い」です。ステークホルダーの勘違いによって要件が変わったりスケジュールが遅れたりします。アジャイルに比べるとウォーターフォールでは勘違いの発覚が遅れ影響が大きくなってしまうので、いかに勘違いを起こさないか、共通理解を作れるかが勝負となります。
リクルート時代、この勘違いを防ぐ取り組みとして「ビジネスルール」の作成を行なっていました。ビジネスルールとは以下のようなものを定義したリストです。
- プロダクト、サービスに関わるもの（人/役割/機能/業務など）の名前と意味
- 機能や業務の範囲・境界（例：「決済機能」は会計システムへのデータ連携処理まで含む範囲）
最近はドキュメントは少ない方がいいと言われている時代です。口頭やテキストなどフロー情報でのコミュニケーションが相対的に増えた中で、言葉の意味や定義をいちいち補足するのは難しくなっています。であれば、最初からズレが起こらないように共通理解を作っておくことが勘違いの防止につながります。
またプロダクトマネージャーは様々な職種や部門のステークホルダーとやり取りをする機会が多いと思います。大きい組織になればなるほど、職種や部門によって言葉の使い方が異なるケースが多く、勘違いが生まれやすい環境になります。
DDDのユビキタス言語など、最初から共通言語を使うようなプロダクト開発手法もありますが、そのような仕組みのないプロダクト開発の現場では、ステークホルダーとのコミュニケーションの中で「あれ？何か人によって解釈が違うな」と感じたら、すぐにズレを解消する動きを取ることをお勧めします。
クリティカルパスを見つけやすい
ウォーターフォールのプロジェクトマネジメントのキモはやはりスケジュール管理です。各タスクの依存関係や前後関係を意識しながらWBSと日々睨めっこしてました。
WBSのタスクには遅れてもそこまで問題にならないものと、遅れると全体のスケジュールを遅らせるものがあります。後者が俗にいう「クリティカルパス」です。プロジェクトマネジメントにおいてクリティカルパスの発見と遅延防止は本当に重要な仕事です。クリティカルパスは以下の画像のように表されることが多いですが、実際はこんなにシンプルな図で表せるものではありません。もっと関連タスクが多いし変数も多いし、そもそもタスクの洗い出し自体が難しかったりします。
https://www.jooto.com/contents/critical-path/
プロダクトマネージャーになった今は、WBSは作らないしこのようなクリティカルパスの定義も丁寧にしないですが、頭の中で常に「どれがクリティカルパスになりうるか？」は考えています。例えば大きめのリリースをなるべく早く行いたいときに、発生するタスク（社内ステークホルダーへの説明、ヘルプページの更新、メンテナンス準備など）をどのように進めるのが最も確実に早く進められるのかを考えます。思いついた順にやるだけでは、どれかがボトルネックになって待ちが発生してしまいます。
おわりに
ウォーターフォールのプロジェクトマネジメントを経験されてる方にとっては当たり前の内容かと思いますが、最近はアジャイルネイティブのプロダクトマネージャーも増えてきているかなと思うので、誰かの役に立ったら幸いです。もし役に立ちそう、取り組んでみたいと思っていただけたら、プロジェクトマネジメントを学ぶことをお勧めします。
もし内容についてご意見やご質問がありましたら、TwitterでDMいただくかMeetyでお話しできればと思いますので、お気軽にご連絡ください。
おすすめの本はこちら
先制型プロジェクト・マネジメント―なぜ、あなたのプロジェクトは失敗するのか | 長尾 清一 |本 | 通販 | Amazon
ザ・ゴール | エリヤフ ゴールドラット, 三本木 亮, 稲垣 公夫 | 英米の小説・文芸 | Kindleストア | Amazon
