フィーチャー・不具合・技術的な作業など、プロダクトに必要でプロダクトオーナーから見て価値のあるものが優先順位付けされて並べられたリスト。
今のチームでポートフォリオプランニングの運営をしているので、勉強のためチームメンバでエッセンシャル スクラムの「16章 ポートフォリオプランニング」を読む会をやりました。昨年度に別のメンバで1冊通しでエッセンシャル スクラムを読む会をやって以来なので久しぶりです。
今回の自分のパートは以下。
「プロダクトをいつポートフォリオバックログから取り出すか」についてのアウトフローの戦略は
がポイントでこれらは、スプリントプランニングに通じるものがあるのでわかりやすいところです。
仕掛品の戦略は作業中のプロダクトについて
を判断するための戦略です。限界費用で考えましょうということ。限界費用が適切に見積もれる必要がありますが、そこが難しいところですね。
16章を通して11の戦略が示されていますが、おわりにの節でどれかを選ぶとしたらとして 11の戦略から選ぶとしたら
だとのこと。参考にします。
やはりポートフォリオレベルでは収益とコストをしっかり考える必要があるなと。
読み直して、やはり今ポートフォリオバックログと呼んでいるのは階層化プロダクトバックログだなと。複数チームで取り組んでいるのでそれはそれで必要なのですが、ポートフォリオプランニングという意味では考え直したいところです。
「ポートフォリオバックログ」のスプレッドシートに「概要レベルのプロダクトバックログ」列を追加したら、プランニングでより具体的な話し合いができるようになりました。
みたいなメリットが生まれました。
みんなをバスに乗せるためにプロジェクトのプランニングで明確にして共有した方が良いドキュメント形式って、方法論やプロジェクトの段階によっていろいろな名前のものがありますが、基本的に項目はどれも似たような感じです。
項目名を整理して決めておくと楽なのでちょっと書き出してみました。
比較的軽量にまとめる時。
プロダクトプランニング(エンビジョニング)のアウトプットとして。エピックレベル(数カ月程度の大きさ)。
ポートフォリオプランニングで、プロダクトプランを評価した結果のもの。エピックレベル(数カ月程度の大きさ)。
スクラムで1スプリントで完成できるサイズのアイテム。フィーチャーレベル。
ちょっとしたタスク。
他には以下のような形式もあります。
[ プロジェクトマネジメント ]
四半期毎にふりかえりをしようと思っていたんだけれど、第2四半期末は後回しにしている間に終わってしまった。第3四半期末も後回しにしてこれを書いたのは10月23日だったりする。
最近行ってないなと思ったけどここ半年43回は行っていた。もっといろいろ見て感性を磨きたいな。
最近は通勤時にスマートフォンで Kindle本を読むようにしている。ちょっとずつだけれど時間的にはこの枠が習慣化しやすいかなと。
毎朝通勤時に1枚撮ることを日課にしたら習慣になった。
それ以外に毎日2枚 Twitter に投稿するという自分ルールを作ったら、撮りためなきゃというのがあってカメラを持って出歩く時間が増えた。 DSC-RX0 が気軽に持ち歩けること・ Lightroom を買って現像が楽しくなったというのも大きいな。
フィルムの方は TC-1 に入れたフィルムと写ルンですがまだ撮り終わっていない。今となってはフィルムは撮りどころが難しくて。
感想を聞いたことはまだないんだけれど、 Retweet したらいいねがつくので継続してみる。
前日に will do リスト(クローズドリスト)を作っておいた方が朝の仕事の出だしが早い。前日作れないこともあるけれど、できるだけ前日で。
以下はいい感じなので引き続き継続。
元日に今年意識してみることにしたもの。「情報を遮断して考える」「毎日考える時間をとる」仕組み化できてない。
自重筋トレ続かず。
関連する本を読んだりするようになったけれどまだ不足している。
ポートフォリオプランニングの優先順位決めに WSJF 導入しようとしたんだけれど、うまくいっていない。今はほぼない感じになってしまっているので、続けるのかやめるのか判断せねば。
ちなみに「ポートフォリオバックログ」のスプレッドシートに「概要レベルのプロダクトバックログ」列を追加したのは良い感じ。
ふりかえりからはなし。
最近はオフィスでポモドーロテクニック的休憩の間にたまに回すぐらい。忘れない程度にいったん維持できればいいかな。
行きたいとは思っているんだけれど優先度下げ。
アイカツスターズ! を2年間観たわけだけど、アイカツフレンズ! は観ないことに。最近観ているのは「レイトン ミステリー探偵社 〜カトリーのナゾトキファイル〜」。
煩雑なので続かず。
無くてもまわるようになった。次回 Premium プランは更新無しかな。
プロダクトマネージャー・カンファレンス 2018 2日目。
以下メモ。
プロダクトマネージャー・カンファレンス 実行委員長 関満徳氏
今日もタイムテーブルから遅れて 10:10 スタート。
▲株式会社FOLIO 代表取締役 CEO 甲斐真一郎(@folio_kai)氏
経営者という立場でのセッション。金融サービスは一般のネットサービスとは異なる要求がある。また今まで枯れた業界であった。3カ月でできると思ったが2年かかったとのこと。 リリース後に単一プロダクトから異なるビジネス/KPIの複数のプロダクトに事業展開していく中で、個別のアプリケーション部分と共用されるバックエンドという構成になっていきマネジメントが複雑化し始めたとのことだった。
今は全プロダクトを単一の巨大なプロダクトバックログで管理しているのだそうで、今後どうしていくのかぜひ知りたいところ。単一の方が事業全体での優先度が明確になるもののリファインメント含めバックログの管理コストが大きいという問題があり、これはいつも悩ましい判断である。
その他の紹介されていた課題ははエッセンシャル スクラムでも取り上げられているテーマのものが多く、あるあるだなーと。
(まだ FOLIO 社にはいないが)プロダクトマネージャーには「プロダクトへの尊敬」を求めたいとのこと。プロダクトへの尊敬とは何だろう。愛じゃ駄目なのかな。
▲株式会社マネーフォワード MFクラウド経費本部 本部長 プロダクトオーナー 今井義人
短期的にはプロダクト改善が最適な改善ではない。人力で頑張るという局面も確かにあるよね。
B2C と B2B の違いはそうだよねで終わりがち。これから B2C から B2B に移ろうとしている人には参考になるかもという感じ。
「愛をお金に変えよう」で築いたエンゲージメントをベースに、より高いプランを作って移ってもらう施策などを紹介。
Nature株式会社 代表取締役 CEO 塩出晴海氏 新規事業での製造まわりのトラブルあるある談を含めた、プロダクトリリースまでのストーリー。プロダクトマネージャーというよりは起業家としての話。あきらめずにやり切る態度は凄いな。
特に話題なし。
▲株式会社リクルートコミュニケーションズ ICTソリューション局 アドバンスドプロダクト開発部 部長 宮里裕樹氏、▲株式会社リクルートコミュニケーションズ ICTソリューション局 戦略企画グループ マネジャー/シニアプロデューサー/シニアプロダクトオーナー 金田將吾氏
細かいところはエンジニアがどんどん進められる組織なので、プロダクトマネージャーは HOW ではなく WHAT に注力しているとのことだった。開発チームのスキルや成熟度によって千差万別なところだ。
プランナーと呼ばれていた人がやっていた役割を
に分けて定義しチーム体制を構築、得意な役割を任せたり不得意な役割を成長させたりしているらしい。しっかりピープルマネジメントに取り組んでいるなあと感じた。
特に話題なし。
▲楽天株式会社 顧客戦略統括部 Vice Senior Manager 山下徹朗氏
「顧客・会社・チームを Happy にする」ことをプロダクトを作る目的として事業を進めている。全能なプロダクトマネージャーは(ほとんど)いないので、ビジネス・UX・マーケティングについてそれぞれ担当を割り当てそれぞれ問いを立て答え続けていくことで結果を出すプロダクトを生み出すという体制を全てのプロジェクトで採用しているとのことだ。
冒頭で「高すぎる目標の」「自己満足な」「誰のためのかわからない」プロダクトという偏った愛あるあるという話を取り上げていた。
▲株式会社ドワンゴ サービス開発本部 副本部長 池田明啓氏、株式会社ドワンゴ セクションマネージャー 宮城良征氏
前半は、様々な手法を利用・開発してプロダクトマネジメントに取り組んでいるという紹介でとても研究されているなと感じた。知らない手法が紹介されていたので、それぞれちょっと調べてみたいな。
後半は実際のプロダクト開発事例の紹介。
特に話題なし。
▲株式会社メルカリ UX consultant Jasper WU 氏
Design Thinking についての非常に洗練された圧倒的なプレゼンテーションだった。ベストスピーカー賞があれば絶対 Jasper WU 氏だったと思う。
自己紹介や会社紹介などに時間は割かずセッションのメインテーマに絞ってきちんと語られた。直メルカリのプロダクトについて直接アピールしていないのだが Design Thinking についての取り組みのみの中で出てくる感じなのだが、結果的に組織・プロダクトについて好印象を受けてしまうというマジック。
デザインスプリントで駄目な案だったということがわかったことは失敗ではなく学びだということがきちんと根付いているのが素晴らしいなあ。
デザイン思考についてもきちんと学びたくなった。
一過性のキャンペーンを繰り返すのではなく、継続的な取り組みをしていくことが愛されるプロダクトにつながると言っていた。
▲スマートニュース株式会社 プロダクトマネージャ 宮田善孝氏
海外のカンファレンス紹介は、カンファレンスセッションとして知見を広める良いコンテンツだった。
スマートニュースではファンクショナルな組織のもと、プロジェクト毎に人が集まりチームを作るという体制とのことだった。プロジェクト毎にチームビルディングが必要そうだなというのと、機能開発プロジェクト終了後のその保守についてどうなっていくのかが気になった点。ファンクショナルな組織の方で保守していけるのかな。
特に話題なし。
Baidu, Inc. Product Manager 陈兆伟 (Chen Zhaowei)氏
日本語入力アプリ Simeji のプロダクトマネージャーの方のセッション。
コンピュータサイエンスやビジネススキルの高いスキルが求められる米国とは違い、中国のプロダクトマネージャーはニーズを掴みイノベーションを生み出す能力の方が求められているという話だった。またプロダクトマネージメントが階層化されていて、プロダクトマネージャーの下にプロダクトマネージャーがいる体制らしい。Baidu ではプロダクトマネージャーの役割/スキルについてのテーブルがあり、育成にも力を入れているようだった。
特に話題なし。
▲株式会社ディー・エヌ・エー オートモーティブ事業本部 Anyca事業責任者 馬場光氏
DeNA もプロダクトマネジメントの定義をしっかりともたれていた。 DeNA でも「全部できる人はいない」という前提で体制化しているようだ。
やはりある程度の規模になるとプロダクトマネジメントの定義・体制化・育成の仕組みが必要だなあ。
特に話題なし。
東京大学 本郷テックガレージ ディレクター 馬田隆明(@tumada)氏、プロダクトマネージャー・カンファレンス 実行委員長 関満徳氏、プロダクトマネージャー・カンファレンス 実行委員 坂本登史文氏、プロダクトマネージャー・カンファレンス 実行委員 横道稔氏
馬田氏は「逆説のスタートアップ思考の人」の方。
「なぜ愛されるプロダクトにしていく必要があるのか」また「そのために自分の Next Action は何か?」をカンファレンスの最後にワークショップ形式で考えましょうという枠。聞きっぱなしにさせず、きちんとリフレクションまでカンファレンス内で完結させるという仕組みを入れるところに運営のセンスを感じた。
まわりの人と自分の考えを披露しあってその言語化を相手にさせるというフォーマット、1つめのワークで sli.do というサービスで anonymous で入力させて気持ち的な投稿障壁を下げたあとに2つ目のワークで自社製品名まで書かせるテンプレートで Tweet させるというマーケティング戦術にも恐れ入った。
ちなみに1つ目のワークで自分が考えた愛されるプロダクトについては
わたしは愛されるプロダクトがだいじだとおもっている。なぜなら「チームメンバの士気とパフォーマンスが向上し、さらに良いプロダクトへと導ける」から。
で Next Action については
わたしは「製品名」をもっと愛されるプロダクトにしたい。そのためにわたしは「プロダクトマネージャーを組織化する」。
としてみた。
プロダクトマネージャー・カンファレンス 実行委員長 関満徳氏
2日間合計の来場者数速報値は563名との発表。1ホールでのカンファレンスでは結構な人数だ。
2015年・2016年・2017年以来、2年ぶり4回目の Developers Summit 参加。一昨年には無かった Wi-Fi のスポンサー提供があってとても快適になった。素晴らしー。
朝1番のセッションの冒頭で今回の事前登録が4000人超という話があった。大盛況。会場の混み具合からするともうキャパオーバーも近いのではと思えてくる。各セッション会場でのバーコードチェックがステージ近くで、まだセッションが終わる前に次のセッションの人が誘導されて入ってきたりして、待機列の問題からだろうけれど、ちょっと発表者に失礼なんじゃないかなーとは思ってみてた。
以下セッションタイトルは2月13日時点の公式サイトより。
株式会社アトラクタ 原田騎郎(@haradakiro)氏
やはり適切な人数の自己組織化されたチームで構成される体制を作っていきたいな。エッセンシャル スクラムだとプロダクトバックログは唯一なものと書かれていたと思うんだけれど*1、現実的なところ抽象度の違う階層化されたバックログとチーム毎にそれぞれあるバックログという感じでいいんだな多分(エッセンシャル スクラムでも階層化バックログ自体は紹介されている)。
*1 どんなプロダクトバックログをいくつ用意すべきかを考えるにあたっては、基本原則がある。プロダクトごとに、プロダクトバックログをひとつ用意するというルールだ。-- エッセンシャル スクラム 6.7
GitHub 池田尚史(@ikeike443)氏
GitHub Actions で Docker イメージを作成して、デプロイまで実行できるようになるという話。デプロイ以外にも GitHub 内での様々な処理も。
株式会社grasys 長谷川祐介氏
サンドイッチ。HashiCorp 製品と Google Cloud の紹介。それから企業の話についての自分語りを伺えた。
ワイクル株式会社 角征典(@kdmsnr)氏 株式会社アトラクタ 永瀬美穂(@miholovesq)氏
前半永瀬氏による enPiT 事例紹介。
後半角征典氏のエンジニアリングデザインプロジェクト(EDP)を通じた知見紹介。参加者の多様性とモチベーションのばらつきを意識した取り組みが素晴らしい。
こちらでもやはり最適なチームについて(人数・多様性)が取り上げられていた。メンバの多様性によるデメリット(ここではモノづくり工程ではデザイナーができることが少ない)もきちんと示されていて、その上でそうしているという話で説得力があった。
ただ「やってみているという話」ではなく、裏打ちされた方法論を押さえた上での取り組みで学びのある話だった。
東工大生イジりが嫌味がないのも素敵。
株式会社コロプラ 廣本洋一氏
機能別組織だからこそ、事業部とは別のロードマップで優先度判断ができる部分があるのだなと感じた。
株式会社VOYAGE GROUP 福田剛広氏 小林徹也氏 駒崎大輔氏
ECナビについて2年弱かけて AWS 移行した話。
サービスの長期運用で技術が古くなり、エンジニアから見た魅力がなくなり新規採用で苦戦したり、在籍エンジニアのモチベーションがダウンしたりというのはあるある話だ。
別だったインフラとアプリの管轄を分けないようにする・オンプレから AWS に移行する・いったんそのままの構成で移すなどは、そうだよねというかそうするよねというかそうしているよねとかそういう感じ。現実的・保守的な判断かなと。
株式会社ZOZOテクノロジーズ 塩崎健弘氏
BigQuery 移行事例についての、味わいのある発表。
今日はシャッター音少なめだなと思っていたのだけれど、このセッションは賑やか。聴講者の層が違うのかな。
高柳謙氏 株式会社丸善ジュンク堂書店 平木啓太氏 株式会社スマートニュース 瀬尾傑氏 株式会社アトラクタ 永瀬美穂(@miholovesq)氏
技術書・ビジネス書のそれぞれトップ3人の著者(や関係者)によるプレゼンテーションと投票・発表のセッション。
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。