IT人材は、DXを必要に迫られたアナログから引く手あまたになろう。
けれども、アナログはデジタルな慣習を理解しきれず、アナログとデジタルの対立が発生する時期が当分あるだろう。
そして、これまでのアナログはまだ維持され続ける。
時間をおいて、デジタルの慣習を理解しようとするのか、デジタルの慣習を伝えようとするのか、そんな関係が発生したときにやっとDXが進んで行くのかな。
その時まで、IT人材がアナログな業界で続くとよいのだろうけれど。
デジタルがアナログを取り込むっていうDXもあるよね。
大人のふりかえり、子供のふりかえり
何か終わった時、年度の終わりやプロジェクトの終わりに｢"ふりかえり"をしよう!｣みたいなイベント、ままありますよね。何か失敗した時なんかは特に。
そこで｢ふりかえり｣という言葉によって、過去を｢ふりかえ｣ればいい、と印象や感想で｢ふりかえり｣が実施されたりしていませんか?
「過ちを気に病むことはない。 ただ認めて、次の糧にすればいい。 それが、大人の特権だ。」
と、ある偉い人は言っていました。
気質なのか、何に起因するのかわかりませんが、つい｢失敗｣と｢ふりかえり｣という言葉によって過去の粗を探したりしてしまう。原因をつい探してしまう。みたいなことありますよね。
そこで考えて欲しいところなのですが、
その年度やプロジェクトの始まりの時に、計画は立てたでしょうか?
また、失敗の確率はどの程度でしたでしょうか?
その｢失敗｣というのは本当はある程度想定されていた結果の一つではありませんでしたか?
｢ふりかえり｣で必要なのは、そのチームにおいて失敗したことを次に失敗しないように成長を得るため、があると思います。
結果が望む形ではなかったからといって、何も悪かったというわけではないと思うんです。
計画したことが 順風満帆にうまくいくことなんてそうありません。
失敗することの方が多いくらいです。
未来がわかるわけないんですから。
なので｢ふりかえり｣というのは、次の成功の為にチームが成長する場にした方が幸せだと思うのです。
想定通りでない部分があれば捨てる、想定通りの部分があれば残す。
そういうように、目的に合わせて手段を修正していき、知識と経験をためて成長する。
ということが次に繋がる大人の｢ふりかえり｣だと思うのです。
｢悪い｣という結果、印象に左右されずに、大人の｢ふりかえり｣ができるよう気をつけていきたいですね。
おまけ
想定どおりに進んだこと、良かったことをしこたま出し切ってから、想定外だったことを話し始める。というのもいいかもしれませんね。
RSGT2020に行ってきたーん。
キーワード
- スクラムは成長、プロセスづくりの方法、プロダクトづくりのものではない。
- うまく50%失敗する。失敗から学びを得る。
- Hidden Cost
- 見積もりは意思決定の為に使っているはず、ネガティブなパワーがあるので、管理の為に使うということを疑う。
- MVPは本当にMVP。期間も機能も小さく、しかしプロダクトであること。
- コミットメントは約束、というより献身。
- うまく行ったらどうなるの?という問いかけ。
- デリバリすることで｢AだったものがBになる｣ようなものに価値がある。
- コミュニケーションは聞く側の問題もある。
- Performingに辿り着けるのは2%とかなり困難。
- チームの新陳代謝を自分たちが新陳代謝することで行う。
- Practice = Principles x Context。プラクティスだけ見られがち。
- Scrumを選択するには、成長したいという動機が必要。
- レビューにも目的をもたせる。
- 魅力的なスプリントゴールを作る。
- 意見のでないレビューに意味はない。
- フィードバックの無いプロダクトを作る意味はない。
- 方法よりもエンパワーメント(かもしれない)。
参加できたセッション
Day1
- James Coplien - The Ten Bulls of the Scrum Patterns
- アジャイルコーチ活用術
- みなさんのプロダクトバックログアイテムはOutcomeを生み出していますか？
- 見積りしないスクラム / NoEstimates Scrum
- モブプログラミング x 行動分析学 x 教育 / Mob Programing x Behavior Analysis x Education
- The Product Owner and Scrum Master Brain Transplant! Mwuhahahaha!!!
- テックリードは未来の話をしよう (Tech Lead in Scrum)
Day2
- Michael Sahota - Lost in Translation: The Manager’s Role in Agile
- チームの再定義 -進化論とアジャイル-
- Team-Based TEAM - 会社を越えるチーム
- 【元士官が語る】軍隊組織からみる、これからのアジャイルのあり方
- ORGANIC agility®: an evolutionary approach to organizational resilience
- 最高のScrumキメた後にスケールさせようとして混乱した(してる)話
自分のモチベーション見える化
- トータル、49個
- 共感したこと(Empathy)、18個
- 学んだこと(Learn)、21個
- 疑問(Problem)、4個
- 次の行動(Action)、6個
共感したこと(Empathy)
- モブプロはスループットを安定させて、パーキンソンを解決する。
集団で活動する事によってカバーしあい、個人に左右されづらくなる。
- どろくさくやる。恥をさらす。
- プロダクトはコンセプトを決めてそれを軸にMVPにする。
MRD,PRD。
- PMの代わりにスクラムマスター、PM=SM。と思われがち。
それは、健全ではない。PMはプロジェクトの管理者。SMはプロセス、成長の管理者。とでも言うニュアンスかな?
- ワクワク、情熱を感じる場であるべき。
- チーム全体で取り組む
全員がPBIをこなせるようにする。
個々の依存性にとらわれないように。
在庫(滞留)が発生しているのは恥ずべきこと。
全員がすべての仕事をする。
パラレルで進む。
- 開発チームとともにoutcomeを考える。
ユーザーの声を届けることで行ったり。
- 期待値を設定するのは、依頼側の責任。
- チームはいつ死ぬか?
老衰?衰弱死?っていうのは面白いなと。
- 同じチームでも自ら新陳代謝する。
チームの新陳代謝は人を入れ替える事。が本質ではない。
- 講義を予習しない。は怠惰ではない。
予習をしない。という行動を選択している。
｢人間は何もしない｣ということはない。
何もしないという選択をしている。
予習してこないのは予習しなくても済んでいる。から。
｢学び｣が喜びであれば好子になるが、そうでなければ嫌子。
- 文化はPrinciplesやContext
｢Practice = Principles x Context｣
Practiceに注目されがちで、Principles(原則) x Context(環境、背景)を無視される。
PracticeはPrinciplesとContextの掛け合わせから生まれる。
- イノベーターのジレンマ
結果を変えたくて(失敗からの脱却)、行動を変えようとしても、文化を変えていかないと失敗のエリアから抜け出せる行動を選ぶことができない。
文化を変える必要性。
- POとSMはやることが異なっていてもマインドセットでは変わらない。
から、POがSMやってもSMがPOやっても問題ないのではないか?
というのは興味深い。
- コミットメントをなんと思うのか人によって違う。
約束･結果、献身。
何にせよ、期待のすり合わせがされないと不幸になる。
まぁ言いたいことはわかるw
- 盛り上がるレビューに演劇という手段
- レビューに対する不感症
学んだこと(Learn)
- スクラムは自然の道、門。
人も自然。抗わずに調和を持ってすすめる。
- スクラムはプロセスを作る、チームを成長させる。
タスク管理やプロダクトを作る手法である面もあるが、プロセスづくりや成長する為の手法という面もある。
タスク管理の面ばかりで捉えていると、ふりかえりも｢作業の進め方ややりかた｣の話をせずに｢次なんの作業をするのか｣と作業の話をしがちになりそう。
改めて｢POはプロダクトを考えるし、SMはプロセスを考える。｣と、強く思った。
プロダクトの為ではなく、組織のためのアジャイル。
プロセスがプロダクトを作る。スクラムはプロダクトを作らない。
- スプリントは実験の場、スプリントは半分失敗させる。
失敗から学びを得て、改善させる。
計画よりもスプリント期間内での行動を計測し改善させる。
- PBIはデリバリの順番、優先順ではない。
優先順=デリバリ順ではないこともある。
デリバリにフォーカスして考える。似ているようで違うもの。
- スクラムなんて存在しなかった。
調和、自然が唯あるのみ?
"やる"と"なる"。は違う。
本来の自分に習うのがスクラムで、ソレ以外はメソッド。
- 見積もりにはHidden Costが発生する。
見積もりは数値化しても正確にはやりきれない。
そこにムラ、ムダが常に発生する。
見積もりすることで、パーキンソンとかプレッシャーとかネガティブに作用する(ところがある)。
- なぜ見積もりを行うのか?計画を立てたい、適切な意思決定を行いたいから。
ではないか?という提示。
見積もりをしないことで、スケジュールをどう担保するのか?
遅延による"損失"を見積もることでリリースのタイミングを決める。
リリースまでの?リードタイムを計測している。=キャパシティの実績をためている。
- コミットメントは献身
約束というよりは｢献身｣と考える。
- MVPは常に。
- うまく行ったらどうなるの?という問いかけ手段。
価値があるかどうか問いかけの質問にも使えそう。
- コミュニケーションは聞く側の問題もある。
当事者意識とか自分ごと化みたいなところにも通じそう。
伝え方の良し悪しを考える。というだけでなく、聞く側に何かしら課題があるのでは?と考えるのも一つの手。
- 情報の並列化
目的がチームではなく、つながりがあるのがチームなのでは?という問いかけ。
仕組み化。
- 価値とは?利用者がどう変わるか。
ビジネスアウトカム=売上。
ユーザーアウトカム=｢欲しい物が見つかる。｣とかユーザビリティを向上させる的な。
- アウトカムとアウトプットは対立しない。
outputがないのにoutcomeの話をしても意味がない。
- ｢チームアウト｣的なプロダクトの作り方みたいなのもあるのか?
自分たちチームが作りたいものを作る的な。
トークの本意ではないだろうけれど。
- タックマンモデルの最後までたどり着けるのは2%(どっかの海運?海軍?大学調べ)
｢いつからお前はPerforming期にいけると思っていた?｣的な。
StormingからのAdjourningウケる。
- モブは、貢献出来ない感が嫌子として作用する。
けど、嫌子の介入はあまりオススメしない。
モブ自体が嫌子になったり。
好子と嫌子は人さまざま、種類もバランスも。
- コミットメントから想起するものはベクトルがある。
自分がコミットしていると感じること、周りの人がコミットしてくれていると感じること。
- スクラムを選択するには、成長したいという動機があること
みたいなのはありそう。
成長したい感がなければ、選択してもうまくいきづらい。
- レビューのテーマを決める。
｢レビューによって何を得るのか｣｢○○に見せる為に事前にレビューするよ｣とか。
- 意見のでないレビューに意味はない。
そして、それが現状。問題があるなら改善すればよい。
フィードバックを得るサイクルを適度に短くしつつ意味のある状況で実施すればよい。
フィードバックの無いプロダクトを作る意味はない。
疑問(Problem)
- 遅延による"損失"の見積もりとは?
極端な話、損失が無ければどこまでも開発をしていい。ということかな?
逆にいつまでに開発すれば(見込みの)利益が得られる。みたいなことの計算もしているのかも。
四半期、半期の計画をしたい場合には、ポイントだとか見積もりとか、どうしてもしてしまいそう。
- ディスカバリのスキルの見つけ方。
アイデアの見つけ方でいいのかな。
- OpsでScrum?
opsな感でも継続開発な感じなのだと違和感なさそう。
けど、インフラ系とかだとやっぱりハマりづらいのか?
ルーチン的な業務でも時にカオスだったり、先の見えづらい作業にはよいのだろうな。
- 経営陣は逆に何を考えているか認める必要があるのではないか?
トップを変えたがっている人たちが多いけれど。
一方的な感じも受ける。
次の行動(Action)
- Hidden Costの発生源をさぐってみる。
- リモートは常にウェブカメラで繋いで少しでもコミュニケーションしやすく。
- デイリースクラムは報告じゃなくて先のタスクを調整するもの。という話し合いをする。
- ワクワクしているか、ワクワクする場所にできるか確認、行動する。
- 今後もScrumですすめるか?成長したい動機の確認。
- 魅力的なスプリントゴールをたてるよう工夫する。
最後にヒトコト
pmconfに続き、ものすごく充実したカンファレンスでした。
感謝。
pmconf2019に行ってきたゾイ!!(番外、懇親会編)
pmconf2019が終わって、ちょうど一週間。
冷めやりませんな。
早速、明日『ドラッカー風エクササイズ』やるですよ。
で、懇親会やその他立ち話した内容のメモを書いておくですよ。
共感したこと
- 仕事を依頼したときはいつ終わるか確認する、何をするか確認する。
- 組織づくりには信頼関係が必要。けど、全員とは信頼関係を結ぶことはそれなりに大変。メッシュで構築するのもありだろう。
- ユーザー要求と検証のサイクルからでは、トップラインを上げる方法が出ない可能性がある。ということは頭にいれて、都度発想の転換だったりチャレンジが必要。
この話は本当に重要で、示唆に富む話だと思っていて、
PdMとかスクラムの文脈だと、経験主義的な配分が多いような気はしていて、つい成功したルールや習慣を積み上げていってしまうけれども。
いつまでも同じでいちゃいけないし、同じだと持続できなくて。
プレッシャーを程よく感じながらチャレンジングでなければならない。
じゃあどうするのか、というとUnlearn(学びを捨てる。学びほぐし。)だったりする言葉があって、学びはもちつつも、現状に対して改めて構築すなおす。みたいなことは自身としてもしなければいけないし組織としてもしなければいけないよね。
それも計画的にやれたらいいよね。っていう。
イノベーターのジレンマですね。
追加、学びや成功体験についてもサンクコストみたいなこともあるんだろうな。
学んだこと
- OKRに対して何ができたか毎日振り返る。OKRって毎日考えることも普通なのか。
- 仕方なくやらなければいけない。という状況は何かがおかしい(かもね)。
そもそもやるべきでないのか。
チームとして成熟しておらず、仕方なしを変えられない、もしくは必要なこととして受け止められない。
- 原則と経験とワクワクを伝える。
疑問に思ったこと
特になし!
次やること
- スプリントを短く、チームも小さくまたは分割
- pixivさんに見学に行く。(ちゃんと誘われたら!
pmconf2019に行ってきたゾイ!!(｢ストーリーテリング｣｢1チーム｣｢データドリブン｣｢トラスト｣｢解釈｣)
重点を置きたいキーワード
- PDMとして、解釈を届ける
- データドリブンによって動く
- 1チームのメンバーは、同じことが出来る状態を選択する。
- ストーリーテリングによって覚えてもらう。
- トラストする。(なんて日本語だw)
参加できたセッション
Day1
- ORDINARY PEOPLE, EXTRAORDINARY RESULTS
- TransferWise
- 海外の現場を訪問してわかったコード中心ビジネスの時代におけるプロダクトオーナーシップ
- PMにおけるストーリーテリング
- “失敗事例で学ぶ” 失敗しないプロダクトマネジメント- PMの必須スキルと、自走する組織のつくりかた -
- コミュニティマネジメント: プロダクトの開発と展開をコミュニティが加速させる
- 企業が求めるプロダクトマネージャーとその人材戦略
- 発明、ドッグフーディング、プロダクトマネジメント
- Zoom
Day2
- 「愛と解釈のコンダクター」
- A day in the life of Silicon Valley PM
- プロダクトアウトな新規事業立ち上げのリアル
- DXにおけるプロダクトマネジメント
- プロダクトマネージャーが知っておくべき、「OKR」を通じたこれからのチームマネジメント
- 面白いプロダクトの作り方と魅せ方
- 顧客要望と情熱の間- B2B SaaS のプロダクトマネジメント -
- Rebuild the Industry 〜産業の半自動化を実現するプロダクト開発手法〜
- シリコンバレーPMのキャリアと働き方
自分のモチベーション見える化
数が多いほど、モチベーション得られたということじゃ!!
- トータル、62個
- 共感したこと(Empathy)、17個
- 学んだこと(Learn)、34個
- 疑問(Problem)、4個
- 次の行動(Action)、7個
共感したこと(Empathy)
- SVで、会社をやめる時の理由
マネージャーが良くないから辞める。
- ordinary people
普通の人だし、普通の事。
でも、浸透しきっているとは言えないので、知らぬ間に力関係が偏ったりする。って思ってる。
そして、恐れ知らずに意見を言うエンジニアは貴重。
- EMPOWERED
どのセッションも、プロダクトよりも先ず人が大切という気持ちが溢れてた。
社員もそうだし、ユーザーさんにもそうだし。
良い人、チームじゃないと良いプロダクトも生まれないよね。
- 自律と責任のもたせ方、もってもらい方
ただ自由ではない、責任とセット。
ふと高校の校則を思い出した、何年前だっつの。
でも、伝道師的なメンバーで組みたいけれど、パートナーの方には"契約"の話があるから、
正しくは持ってもらってはだめな責任もあったりするよなー。とも思った。
自分やパートナーの方もそんな事気にしない人たちだけれど、商習慣というかルールとして線引きがあることは覚えておかないとね。
- 同じものだと思ってたら本質が変わっていた。
表層ではなく、ソースを確認する。
- いきなりコントローラーを渡す宮本さんの話
ほんとそれ。
- 一体感を持って連携しているようで、きれいなWFしてるだけ問題。
イテレーションをするんじゃ!
- ユーザーが本気になるタイミングで｢運用だから｣と人が減らされる問題。
ずっと作り続けるんじゃ!
それがアジャイルじゃ!
- 考えて考えて考えて、ぼーっとしたときにフッとアイデアが出てくる。
PdMって毎日8時間、就業時間に沿ってに働く仕事でもない。
常に考え続けてる。
- 自分に仕事をあわせる。
仕事に自分をあわせない。
- メランビアンの法則
ボディランゲージ55%、トーン38%、言語7%
信頼にはコミュニケーションが必要か?
まぁ必要な要素の一つだと思うんだけれど、それを考えたらコミュニケーションをしっかりとるには、ボディランゲージとトーンを外しちゃ駄目だな。
チャット"だけ"は向いてない。
例えば、リモートワークのチャットだけはやっちゃ駄目だなー。
- PassionはEgoではない。
熱すぎる情熱は、Egoになる恐れがある。
周りは熱狂させても自分は常に冷静に。
- 音楽さえもPdMに役立つ!!
どんな経験が今に活きるのかわからない。
どんな経験も解釈しだいで今に活きる。
自分も、あれとか、これとか全く今の仕事に関係ないところだけれど活きている感とても感じる。
- 徹底した透明性。
全公開。
- 提供と価値と時間軸
裏で手動で動かしてもいい。
それでスループットはよくないが、検証にも活用できる。
神業BOTもいいけれど、拘りすぎない。
- PDMに型はない
状況に対して、レバレッジを考える。
経営者目線。経営者的ふるまい。
とにかくなんとかする。
- 組織問題もメカニズム
日本は、プロダクトアウトなことが多い。
IT業界では、そうでもないけれども、製造は自分たちの都合でやりがち。
そういうったことも、メカニズムで対処する。
学んだこと(Learn)
- Product Discovery
Valuable,Usable,Feasible,Viable
価値があること、使えること、
｢日本とSVで違いがあるからできない。｣ということではない。
- Product Team
Feature Teamと対比されていたのが印象的だった。
｢ロードマップを解消するでない、問題を解消せよ!｣
｢機能のを作るではない、製品を作るのだ。｣ということかな?
納品するだけでなく、ビジネスの成果も考える。
それでいうと、製品を作るに留まらず、ストーリーまで作り込んで行きたいな。
という考えに至った。
- ビル・キャンベル氏
www.amazon.co.jp
まさか、GA(F)Aの(Fは外されてた。)共通点としてコーチを挙げてくるとはサプライズ。
｢リーダーシップは、コマンド･アンド･コントロールではなく、環境のマネジメントをしてカスタマーに向かわせる事｣
最後のセッションで佐藤さんが｢頭の中に必ずカスタマーを。｣って言っていたことも想起される。
心に刻んでおきます。
ちなみに、ビル氏は残念ながら数年前亡くなられてしまった。
｢自分をあまりフォーカスしないで欲しい。周りの活躍している人たちを見てほしい｣と言っていたそうな。
そういう方だったんでしょうね。R.I.P.
ふと、この映画も思い出したので貼っとく。
www.uplink.co.jp
- CEO(もしくは、経営層) VS Product Team
っていう関係がまま問題になったりするんですね。
共感している方が多そうだった。
自分はあまり感じた経験ないから、困っている方が多くいる。ということがわかった。
- プロダクトマネージャーは、ミニCEO
会社経営ができる人材をあてる。
けど、CEOではないので勘違いしないように。
- サービスを広く使ってもらうには口コミとかコミュニティとかそういう方法
プロダクトを好きになってもらう。
- ヨーロッパでは3年くらい前から内製化?が進んでいる。
そして、人はそのままに動きが変化している。
から、そんなに人に幻滅しなくてもいいのでは?ということかな。
- はげちゃびん問題
現場を信頼して判断を委ねればいいのに変な所で説明を求める人がいることで起きる問題の名前。
意思決定が止まっちゃうから。
まぁ、意思決定するには正しい情報が必要な場合もあるけれどね。
- PBIの管理方法
3スプリント分は作業着手できるようにしておく。
それから、荒くてもいいから先々までいれておく。
- 複数チームで1つの開発をしているなら、分散させないで1チームで行えるようにする。
プロダクトを作る為に必要な業務は、チームの全員が実施可能な方法で業務フロー、技術戦略を行う。
チーム内での分断が行われないようにする。
1チームで出来ない作業があるなら、そのチームで出来るような作業に置き換える。
そして、余ったチームは別のこと新しいことをする。
目からウロコ。
Visionがあっても大して機能しない。
忘れられちゃうし。
その点ストーリーテリングは覚えられやすいし、何よりも印象的。
静的ではなく、動的で主観的で因果関係が描かれたもの。
ストーリーの型、｢主人公(当事者)→問題→解決(主人公の変化)｣
｢自分が夢中になる物語を!!｣
ヒーローズジャーニーは、ハリウッドの起承転結。
そして、ストーリーを計測する。定性的でも。
ポエム。
プレスリリースでフィードバック得たりするやつ。
- 学会の人は、ビジネスに興味がないので研究が結果が共有されないw
で、放置されるw
- いろいろな発想方法
制約的発想、そもそも発想、音楽は右脳を埋める。芋づる発想。
そもそも、ドッグフーディングってそういうモノなんだったんだろうけれど、なんだか自分の中では｢場を作って実施する。｣みたいな手法感があった。
日常的に実施するでもなく日常に取り込むことが真のドッグフィーディングだ!!
みたいなこと思った。
『プロダクトイン』『自己中心設計』
- ユーザーの体験を変化させる。
デバイスまで作っちゃう。ある種の『自己中心的』な発想なのかな。
ユーザーのストーリーやシーンにあったものを提供して使ってもらう。ではなく、
そもそものストーリーやシーンを変えてしまうほどの環境を作ってしまう。
- 指揮者(プロダクトマネージャー)は解釈を提示する。
合奏は、楽譜を再現する活動。
指揮者は、そのペースを守ること。ではなかった。
指揮者は、解釈を届ける。
｢赤ずきんちゃんがお婆さんに食べられないように(演奏する)｣ << 楽譜に無い解釈によってチーム全体の動きが統一される。
解釈によって、機能やストーリーも見え方が変わってくる。
無駄なもの必要なものが解釈によって変わってくるし判断できる。
コンセプト、ストーリー、コンテクスト。
要件は考えない、要求を考える、それ以上に解釈、ストーリーを伝える。
置かれている環境情報を伝え、自ら何が必要で不要かを判断できるようにする。
- 自律するシステムづくりをする。
人間、自動だと不満。
自分でやってる感必要。
そもそも全部自動とか難度が高い部分がある。
なので、人に対して自然と協調できるシステム。
システム任せではないモノをつくる。
半自動化。
- Think Big(大きく考える)
打席に立てるのが大事。
打席に立ちづづけるのが大事。
SVでは、ホームランを打つのに必要なヒット数(と質)という思考。
ある点から試行し続けるではなく、ある点に向けて試行し続ける。
目的が大事、みたいなことだと解釈。
- ペルソナは一回横に置く。
世界を見るとペルソナ作っても、ダイバシティーありすぎ。
(捉えきれなくなってる?)
- 強く信じるが、拘りすぎない。
柔軟性を持つ。
新しい事実が出てきたら、やりなおす。
- データドリブンは必須。
データドリブン出来るようになるのは｢できたら必要｣ではなく、必須のスキル。
直感は使うが頼りすぎない。
｢事実は何か?｣ << ｢誰が言ってるの?本当にいってるの?｣
日本はそういう確認は避けられがち。
これを避けてはいけない、これは｢リスペクトある批判｣である。
- 分けて考える。大きすぎるなら。
分け方によって熟練しているかどうかわかる。
｢何故、そのように分け方なのか?｣
そして、優先順付けと説明責任を持つ。
- やりきる力、実行力
知らないことでもやりきる力。
PDMは自分の人生も解決させることができる。
- シリコンバレーは玉石混交
Hire Slow ,Fire Fast.
Go Big or Go Home.
大きくやらないなら帰れ。
- 上手に失敗する。
レイオフなんて日常のこと。
次のチャレンジの始まり。
学びがいのある失敗の為に、賢く挑戦をする。
- 上手に失敗する1、成功しているとしたら何が必要か?
過去からの視点。
｢あれがあったから成功した。｣のあれとは?
- 上手に失敗する2、プリモーテム、失敗するとしたら何か?
未来からの視点。
｢何で失敗し"た"か?｣と考える。
むきなおり的な。
- プロダクトアウトとマーケットインは対立ではない。
価値を考える手法。
両方使えばいい。
- ワクワクさせる。
人は、感情で動く。
顧客にも社員にもワクワクしてもらう。
セールスの時、機能を説明しない、楽しく見てもらえるようにする。
利活用で、前向きなイメージを持ってくれるようにする。
遠隔のモノは遠隔で実際に見てもらうとか。考える。
- 新しいビジネスの考え方
一見愚かなアイデア
先ずマネタイズしない
新しい行動パターン
競争が激しい飽和市場
経験が無い創立者
- ピラミッド型組織
ピラミッドってお墓じゃん。
お墓な組織。
- プレイングマネージャーはNG、ポートフォリオマネージャー。
- OKRは野望を掲げる。
7割で成功。
- 新しい機能への流入を促すには｢オススメ｣表示
1年半くらいで既存機能から新機能への使用率が逆転した。
疑問(Problem)
- PDMのスキル定義をしないと、PDMできません。不安です。みたいなのはなんか違う感じがする。
そもそも向いていないというか…。
やりきる力みたいな事は必要だし｢そういう力あったらそうならなくない?｣みたいなことを思う。
そして、PDMのあり方に悩む人ってPDMをやらされているような気がしちゃってる。
組織の戦略とか教育とかそういう場合には必要になるのもわかりますけれども。
それにしたって、面白みとかで伝える方がいいよなー。
なんか型にハマる感じがして｢仕事をしているだけ。｣みたいな印象がある。
別の面として、スキルを定義するにも自分の弱点を克服するためとか伸ばすためとかそういう発見器みたいな使い方とかもあると思うけれど、
まぁ、スキル定義に興味を持っている方が多かったらしく、なんとなくそんな事を思った。
- やりきる力ってどう図る?
構造化面接?
行動面接?
適性診断?
- OKRのすり合わせはともすれば、コマンドアンドコントロールになる?
プロセスの踏み方なのかな?
組織ではなくて個人に尊重していればいいのかな?
重心の置き方なのかな?
- 複数チームで1つの開発をしているなら、分散させないで1チームで行えるようにする。
に名前が欲しい。
次の行動(Action)
- ドラッカー風エクササイズ
- ムービングモチベーター
- プロダクトを解釈しなおす。
コンセプトを確認する。
- プロダクトの価値を分割する。
そして、ストーリーを立て直す。
- セールスのストーリーを考える。
小芝居考える。
- OKRが目に触れる頻度を増やす仕組みづくりをする。
- カスタマーを頭の中に常におく。
『エンジニアの成長を支える 1on1 ワークショップ』に参加していた。
https://engineers.connpass.com/event/126523/
前フリ
さる5月18日『エンジニアの成長を支える 1on1 ワークショップ』っていうものが実施されていた。
そして、それに参加していたのです。
で…。
そろそろ3ヶ月も経つのですが、ふと湧いては消える感じで、どうにも頭から離れない感じになっているので書き出してみる。
｢学んだことなので頭から離れないでもいいのかもね!｣というのもあるけれどw
書き出したいこと
会の中で1on1を互いに受けてみる、実施しているのを見てみる。
というものがあったのですが…これがまぁ面白い、興味深い。
1on1がまさに十人十色に実施されていたのです。
今まで自分が見てきた1on1は、バリエーションはあるにしろ組織内でやっている分にはどこか似通った感じのところはあったかなと思うのですが、まぁそのバリエーションを軽く越えたバリエーションを見せられたように思いました。
伝え方、聞き方、姿勢、身振り手振り、表情、PCやノート、テーブルや椅子の配置などなど様々な所に意図を感じました。
そして、1on1の実施後に互いにインタビューがあったのですが、マネジメントのスタイルだけでなく、組織の形やフェーズなども1on1の形に影響してくることが見えてきたのです。
自分と似た感じの方は似たような1on1のスタイルをとっていたり、逆に自分の経験したことない組織にいる方は、全く違うスタイルをとっていたり。
｢こんなにも違うものなのか!!｣、｢1on1深い!!｣ってずーっと脳みその裏の方にこびりついていてこびりついていて…。
様々な形があれど、第一に互いに向き合うことだよなぁ。
って書き出したいことを書いていて、ふと思った。
1on1のバリエーションはあっても、互いに｢向き合う｣ということだけは変わらないよね。
向き合う為の手段だったり、向き合うことで次へ進む為の手段だったり、そういうのに合わせていろいろな方法があるんだろうけれど｢向き合う｣ってのは不変。
仕事していると、自分のだったり、それぞれのだったり、チームのだったりする課題に目を向けてしまって問題が起きる。
毎日何かしら起きてる。
でも、そういうのって｢互いに認識する｣みたいなことをちょっと意識する、してもらうだけでも変わってきたりして、
1on1ってそういうのを体系だってというのか、なんというか、形あるものとして置いておくってのは大切だよなぁ。ってね。
問題解決のためだけでなく、理想に辿り着くためだったり、仕事だけでなくキャリアとか人生みたいな話もあったりして、
たまたま仕事の関係で1on1やったりしてるけれど、実に人と人の大切な繋がりだよな。
と改めて思ったりした。
おまけ
www.nichinichimovie.jp
ちょうど昨日『日日是好日』を見て、お茶の空間って1on1のバリエーションの一つみたいだなと。
www.comicbunch.com
『「子供を殺してください」という親たち』ってのも最近読んでいるのだが、過酷な1on1の形もあるんだなとか思った。
kaigo.homes.co.jp
なんか脳みそが全て1on1に見える呪いにかかっているようだ。
これも1on1のバリエーションに見えてきている…。
まぁでも1on1を｢向き合う｣まで抽象化した概念にしたら1on1だよね。
親と1on1、家でやったらやっぱり飲み会に落ち着くだろうな。
あなたの知らない(怖くない方で)1on1事例とか探すのも面白いかもね。
#kichijojipm 19にいってきた!
今回は、余裕をもって19時前参加。
見る枠です!
お母さんもなつやすみ。(akiko)
https://www.slideshare.net/akiko_pusu/20190802kichijojipm
ibisペイント使ってるのね!
と思ったらパワポ、ベジェで書き直してビビる。
でも、パワポだったらペイントソフト無い方でも使いやすいよね!
編集もできるからコミットplz!
https://github.com/akiko-pusu/kichijoji-pm-logo
How I discover a working implementation of clock_nanosleep() for macOS in CPAN Time::Hires(jj1bdx)
https://github.com/jj1bdx/kichijoji.pm-19
システムコールは依存あるけれど、乗り越えられるよPerlならね!
macのコマンドはmanで出てこないw
アンカンファレンス3(karupanerura)
JSON扱うときに型にハマる時あるよね。
Perlは文字型と数字型と文字型+数字型があって。
適宜変えてくれるんだけれど、逆に"変わっちゃってしまう"ということがあるので気をつける。
JSON::Typesもね。
Talk1:心理的安全性の論文を読んでみた(setoazusa)
心理的安全性の原点を振り返り。
文化の背景も考えつつ心理的安全性を考える必要があるのではないか。
良いもののはずが悪く捉えられてしまう。
Talk2:TBD(Yoshitaka Kawashima)
Emacsでプレゼン!
本物のREPLはEmacsで!
なので、Emacsだからこそ出来る感じのプレゼンになっててワロ。
これで登録情報以外のメールアドレスにも送れる!
Scrumでコールド負けしないために “計画”に向き合ってみた/Do not lose cold with Scrum I tried to face "plan"(KamoShinichiro)
https://speakerdeck.com/tyankamo/do-not-lose-cold-with-scrum-i-tried-to-face-plan
計画の話もいいけれど、メトリクスがすごい!
こういう素材の鉛筆の持ち方気になる…。
Talk4:TBD(tzkb（こば）)
k8s+PostgreSQLを丁寧に解説。
説明がスラスラ入ってくるトークが凄い!
出版するための手引書 / Publishing Manuel(sapi_kawahara)
https://speakerdeck.com/sapi_kawahara/publishing-manuel
出版するにはやることあるけれど、かなり省力化できる!
文書を書くことだけは頑張り。
めっちゃ意識改革起きた。
LT2:TBD(kiririmode)
gRPCで接続きれちゃうの、どうしたらいいか教えて!
っていう質問LTw
LT3:Botkit 4.x has come!(うちる)
BotkitをすててBoltを使いましょうwww
モデルとは何であって、何でないのか(a_suenami)
https://speakerdeck.com/a_suenami/moderutohahe-deatute-he-denaifalseka-number-kichijojipm
数字と自然言語と手続きと関数と…
ソフトウェア開発を越えるモデルの話!
(手続きと関数は懇親会でのお話。)
ソフトウェア設計は難しくない(polidog)
https://speakerdeck.com/polidog/sohutoueashe-ji-hanan-sikunai
設計のアウトプットの形は様々ある。
雑に書いてみる!
TDDの修行をエアペアプロで行う(i-dach)
https://speakerdeck.com/dach/tddfalsexiu-xing-woeapeapurodexing-u
kaztoさんが電池切れで順番入れ替え。
エアペアプロのすゝめ。
ぼっちでも、t_wadaさん動画とペアプロをしよう!
動画だからわからないことあっても繰り返しできるよ!
C言語でオブジェクト指向プログラミング / object-oriented-in-c(kazto)
https://speakerdeck.com/kazto/object-oriented-in-c
スマホでプレゼン!!?
と思ったらノートの電池が切れただけだったw
Cでオブジェクト指向、運用でカバーからの自力で構造体!
本日の #kichijojipm テーマ統計
— ろずにゃっく (@i47_rozary) August 2, 2019
パワポ･イラスト x 1
Perl x 2
心理的安全性 x 1
Clojure(なの?Emacsなの?) x 1
Scrum x 1
PostgreSQL･k8s x 1
出版(Publishing Manual) x 1
gRPC x 1
Botkit(焼肉) x 1
モデル(pair programming Meat) x 1
設計 x 1
TDD、エアペアプロ x 1
C、オブジェクト思考 x 1
アンカンファレンスでPerl話が勢いよく2本続いたがその後失速w
そしていろいろな方向の話が飛び出してほんと知見広がる夏かもね!!
次回は6周年、どんな開催になるのか楽しみ!!
