背景
- ２年間くらい PO & Scrum Master とソフトウェアエンジニアを兼務したり色々あった
- この度、ソフトウェアエンジニアに集中できることになった
- せっかくなので、忘れる前に ( もうたくさん忘れたけど ) 書き出すことにした
- この記事は、未来の自分が思い出すための記事である
全般
絶対に兼務しない
- これだけ兼務まつりしてて言うのもあれだが
- POに集中する期間は、SMとエンジニアとしての貯金が減ってるのを感じ
- エンジニアに集中する期間は、POやエンジニアとしての貯金が減ってるのを実感する
- 兼務状態は、常に何かしらの貯金が減る不安を抱えながら仕事することになる
- スーパーマンでない限り、１つ１つのクオリティが落ちてしまい、よしんばなんとかなっても「なんとか破綻しない」程度になる
- うまくいったとしても９割のケースは、誰かが荷物を持ってくれたから
- なので 成功ケースだけを見て「兼務いけるやん」と思ってはいけない
- 自分がうまくいった経験があったとしても「誰かのフォロワーシップに助けられただけ」 という意識を忘れてはいけない
Product Management 領域
仕事のほとんどは組織のチェンジマネジメント
- Product Management の仕事。と考えると、顧客ヒアリングをして、市場調査して、仮説建てて、プロトタイプ作る。そんな感じの面白い仕事を想像してしまう。
- だけど、それは仕事の中のほんの一部でしかない
- プロダクトが変えるのは、顧客の業務だけでない。自組織の仕事の仕方も変わる
- 顧客・自組織を問わず、業務のASIS/TOBEを描き、変化の過程を設計し、信頼を獲得し、より良い価値を提供するために変化させていく
- 現状を適切に把握する上で、自ら営業として現地に行ったり、CSとして電話を取ったりすることもある
- いつも慣れない領域に飛び込まねばならないので、ストレスフルなお仕事になる
- けど、コンフォートゾーンにいるだけではまともな結果は出せないのでやるしかない
新しいソフトウェアじゃなくて新しい業務を作る
ベストプラクティスはWeb系企業で育まれている〜三菱重工業のDXを支える学びの姿勢〜 川口賢太郎、森岡周平（三菱重工業株式会社） | ITエンジニア向けのトレンド情報
仕事の大部分でPCを使わないような人達に、ソフトウェアの力で価値を届けていくという難しさがあると感じています。ただ、それこそとても挑戦しがいのある課題だと捉えています。
- 昔、インタビューの中でこんなことを言った
- これは今でも重要だと思っている
- 顧客とソフトウェアのタッチポイントが多ければ多いほど、作る機能が増える
- コード量、バグの可能性、顧客の負担、不満を言われる可能性も増える
- ドリルと穴の話で、最高のドリルをつくるばかりに意識を向けず
- 「穴を最小のコストで開ける」ってことに意識を向けたい
- 顧客の利益を最大化しつつ、サービスとのタッチポイントを最小化することが重要
- 例えば画面作らなくても、メールで済むものはそれで終わらせるとか
- そのために、顧客の既存業務をしっかり理解し、ASIS/TOBEを描き、TOBEに至るまでの過程と、その都度のサービスのあり方を考えることが重要
ニーズが表面化するまで解決しない。でも準備はする
- 「データが１万件になったら整理が必要なのでこの機能作りたい」
- みたいな話が出ることがある
- その時期は半年後だったり１年後だったりする
- 今必要ない or ビジョン実現にMustでない機能は絶対に作らない を徹底しろ
- 必要になったときの方が情報が増えてて適切な判断をできるだろうし
- 今解くべき課題を確実に解くためにチームのキャパシティを割きたいし
- 今、その課題に直面していないユーザーから納得感を得られないからだ
- 前もって準備しても、課題に直面していないユーザーからは不満の声しか出てこない
- 機能は作るよりも削るほうが難しい
- Nice to Haveな機能を作ることに、なに１つ良いことはない
- ステークホルダーの一時的な欲求を満たすだけだ
- その代わり、課題が表面化したときに迅速に対応できる体制はつくっておく
PSFit完了まで人を増やさない
- 一般的な会社において、人を遊ばせることに罪悪感を覚えない人はいない
- だが、PSFitまでのフェーズにおいて、ひとはそんなに必要ない
- PO、営業、デザイナ、場合によってマーケター (or コンサル) がいればなんとかなる
- それ以上の人がチームにいたとき、POはそれらの人の仕事をつくることが求められる
- またPOはステークホルダーの不安マネジメントも求められる
- 結果、なかなかPSFitに集中できずズルズル余計なコストが嵩んでいく
- ただし、各々が自走できる場合、不安マネジメントが不要な場合は人がいても良い
- 開発チームは空気を読んで必要そうな機能の実験・検証・学習をしてくれてたりすると最高のスタートを切れたりする
ホームランを狙うか、アウトを避けるか決めておく
- プロダクト開始時に、どちらのスタンスを取るか決める
- ホームランを狙うなら、積極的にリスクを取れ
- アウトを避けるのであれば、不要なリスクを取るな
- コントロールしやすいリスクは、極力安全に倒せ
- POとして意思決定する際は、何のリスクを取ってるか常に意識しろ
様々な道具で具体・抽象のアウトプットし続ける
- 具体と抽象を行き来しなければ、有用な発見は得られない
- 考えるだけでは意味がない。手を動かせ。手で考えろ
- 抽象であたりをつけ、具体で検証しろ
- 具体で違うとなったら、また抽象にもどれ
- 例として、下記のような成果物が考えられる
- 煮詰まったらDesign Sprint を頻繁に行っても良いだろう
- 具体的なアウトプットイメージは上記である
- １週間で１往復くらいがちょうど良い
資料作りを絶対サボらない
- 顧客に説明に向かうとき、説明資料を持っていくことがある
- 社内のステークホルダーに協力を依頼するとき、資料をつくることがある
- この資料は絶対にサボってはいけない
- 顧客においては、上司にシステム導入の話をする際に、自分が作った説明資料を使うことがあるし
- 社内のステークホルダーも、周りに協力を得る際にその資料を使うことがある
- PO自身が作った資料が、どんどん独り歩きしていく
- そのため、明確で分かりやすい言葉を使い、多くの人が理解できるように、懇切丁寧な渾身の資料を作ることを常に意識することが大切
意思決定を人に委ねるな
- プロダクトオーナーはプロダクトの意思決定者
- 偉い人アドバイスをくれるだろうが、短絡的に飛びついてはいけない
- アドバイスをくれた人に対して、自分が現状を100%伝えられてない可能がある
- その場合のアドバイスは、必ずしも正しいとは限らない
- 自分の中でロジックが説明できないことは、誰が言ったことでも通しちゃいけない
- ステークホルダーがどんなにイヤと言ってもやらなければいけないこともある
- 誰かに恨まれても、やるべきと思ったらやるという意志を持つ
- そのとき、説明だけはちゃんとする。伝わらなくても、全力で伝える努力をする
最後に
- 他にもいっぱい学びがあった気がするが... 今すぐ思い出せるのはこれくらい...
- 思い出したら追記する
