自分の気づきを中心に"自分用"の備忘録的にまとめ。
セキュリティのお話
個人情報保護基準
業界的にも?徹底もされていなければ、知識的にも心得ている方が少ないからかな。
ちな、困ったら法務関係の方と相談しましょう。
PCI DSSクレジットカード業界のセキュリティ基準
規則的なものはドキュメントを見るのがよいですね。
日本語版ドキュメント
https://ja.pcisecuritystandards.org/minisite/env2/
提供元らしい。ステキ。
http://www.intellilink.co.jp/article/pcidss/26.html
PMの領域定義、働き方など
PMの領域定義って、各所でブラッシュアップしながら進めている印象。
責任者的なところもあるので広さもある。
その広さに悩んでいる方も見てきたことを考えるに定義の必要性ってあるんだろうなぁー。とか思う。
バリエーションを用意して、自分も選択するし、周りも認識してみんなハッピー。的なのだろうけれど。
今後、変化していったりするのかな。
ヒトリゴト
チームビルディングする時に、役割をカードで並べて取っていくイメージ。
RACIチャート。
PMは開発経験(企画、デザイン、エンジニア、特にエンジニア)が必要と強く思っている。
のだけれど、連携を強める、コミュニケーション齟齬解消などの為の理解が必要。という話なので、
分業や連携が進んだチームであるならば、いきなりPMキャリアにいくこともいいんじゃないか?という気付きを得た。
楽天さん
30の項目定義をしている。
個人の特性を見て、計画的成長を促す。
サイバーさん
組織成果を最大化する。
市場に埋もれないよう、差別化、特徴づけ。
話題を絶やさない。
スマートニュースさん
北米では、PdMは体系化されている。(海外動向)
PdMとPeopleマネジメントが分かれている。
PdM=30代男性。ダイバシティの確保が必要なのではないか?
バイドゥさん
PMに必要なのはニーズの発見力。
コンピューターサイエンスはいらない。
PMは最初からPM。
PdMは社長に近い。
それぞれ特化した人材で組織的には縦割り?分業されている。
DeNAさん
プロダクトをマネジメントして目標を達成する。
姿勢と責任を持っている。
食育大切
体資本ですしね。
以前、一緒に働いていた方が完全食です!!*1とか言ってサプリばっか食べていたけれど。
自分の気持ちとしては足りないと思うんだよなー。
栄養観点はわからないけれど。
味を楽しむとかもマインド的に良いことだと思うし、噛む力とか体のつくり的にもね。
ちな、上の方は個食が好きっていうわけではない。*2
食事という企業内のプロダクト。
ある種の物理的な製品以外にもプロダクトとしてとらえマネジメントするのは興味深いな。って最近思う。
Googleさん
ミッション!!｢全社員の寿命を2年伸ばせ!!｣｢30年後も健やかでいられるように!!｣
わかりいいよね。具体的だし。気持ちがいい。
食べ残しが多かったのに困っていた。
｢体調悪いのですか?｣｢お口に召しませんでしたか?｣とケアの言葉を伝えるようにしたら減った。
しかも、数カ国語で。
そして、コストが改善され担当の方たちの評価があがり待遇も良化した。
なんとなく思うけれど、食べ残しを減らしたい気持ちもあったのかもしれないけれど、ケアの言葉って担当の方たちの気持ちとして自然と出てきている気がする。じゃないと続かないしね。
チームビルディング
チームの構築フェーズについて
フェーズ1、同質性、空気を読んであわせられる人。
フェーズ2、多様性、おそらく管理者が必要。
情報透明性の大切さ
一生懸命やろうとみんなしているけれど、齟齬がどうしても生じる。
共有することで各位、自律的に動ける。
｢リズム、ステータス、KPI｣
メンバーのスクリーニング
年齢、学歴、web業界。*3
フラットすぎて言うこと聞いてくれないメンバー
LINEさんww
ドワンゴさん
スターエンジニアがボトルネックになることもある。
人もそもそも足りない。
育成は、ライブコーディングとコーディングバトルを通して。
VSCode使ってる。
衝突を避ける方法として、チームの価値基準を策定し判定する。
スマートニュースさん
コンポーネント型からフィーチャー型へ?
戦略
日本向け?世界向け?
｢日本で流行って、世界展開する時に再開発だと周りに遅れる。｣
白か黒かっていう話ではないと思うけれど、開発コストが早いフェーズでちょっと増えるよね。
戦略として、タイミングなど何を選択するかだよね。
その辺の振り返りとか聞けると良かったな。
ポーター、コトラー
プロダクトマネジメントと経営学?
そういう戦略も必要な時あるよね。
ここ数年触って無いな。という改めて最近の状況を探してみるのも面白いだろうな。
ヴィジョンのお話
ステークホルダーがヴィジョンを伝える。現場は作る。
でも、モノづくりって大変だよね。
ということを理解しているステークホルダーはコミュニケーションのハードルは低くなりやすいけれど、馴れ合いにもなりかねない。
協調関係が築けると良い。
迷ったら立ち返るべき場所
またはブランドなども考慮。
成果の出し方(一例)
pixivさん
ドメインを極める。
何かに浮気するより、注力することで見えてくるニーズがある。
ZOZOさん
入社から活躍するまでがトップの責任
リクルートさん
エンジニアが優秀なのと営業マンが多いので、PMはHowは気にせずWhatにフォーカスして行動する。
PMは、ヴィジョンに立ち返る*5
LINEさん
｢送信取り消し機能｣めっちゃ揉めた。
ストーリー的には｢投稿したものを削除する｣というだけなはず。と思っていた。
しかし、考慮しなければいけないことが多くあった。
消されることによって、約束が反故にされる。
いじめの証拠が消される。など。
じゃあどうする?いつまで消去可能にする?完全に消せるようにする?など考慮しなければいけない仕様が出てくる。
プロダクトの方向付け、ユーザーの心情やブランディングなども考慮。
エンジニアさんといろいろなパターンを試してみた。
全員は満足する方法はないだろう。
どうすれば??
どの方法を採用するのか。ここからがPMの本領発揮。｢どう使ってほしいのか?を突き詰める。｣
LINEとしては｢間違えて送ってしまった!!でも既読になっていない!!｣みたいなものを消せることで、
コミュニケーションの失敗を低減したい。という想いに立ち返って仕様を決めた。
リリース後、マイナスの反響もあったが、すべてのユーザーが満足するものはないと思っていたところもあり納得している。
プロダクトの活用用途、要求、あり方など
物づくりの場にいると、誰かしらが｢〇〇を作りたい!!｣という気持ちでいつの間にかPdMになっている気がする。
そうじゃないと、カオスになってプロダクトが終わるか時間を無駄にしてある意味終わる。
LINEさん
国レベルで怒られることがある。*6
ラクスルさん
業者や配送屋さんの空き時間を使ってもらう。
現場にソフトウェアを使ってもらうのは厳しいし大変。
社内に配送経験のある方がいて、その方と確認しながら進めていたとしても。
現職配送屋さん｢両手では使いづらいです。(自分たちは)荷物持っているか、ハンドルを持っているか。｣
ということも合った。
｢作りたい!｣という気持ちを持っている人は、仮設から一直線で作り込んでしまう。そして失敗する。*7
Natureさん
社名が判然としなかったついでに調べたのでURLも貼っておく。
スマートリモコンのNatureRemoの会社さん。https://nature.global/jp/top
｢電気の需要の観点で問題視していた。電気を効率的に使おう｣という思いから開発。*8
一部故障品が発生してしまった。
お金もなく対応に苦慮したが、お客様と時間をいただき交渉しながら全品交換対応。
リクルートさん
プロダクト選定基準。｢わくわく、もうかる、やる意味(競争優位性、レア)｣
ドワンゴさん
機能が使われ生きるまでのストーリーを書くのがPdM。
ストーリーが破綻していたら、若しくは書けないのであればそれは不要でしかない。
DeNAさん
コンセプト、価値を明確にする。
Anyca=車、男性的、安心など。
ユーザー向けにやってること、｢サービス説明会を定期的に｣、｢投稿用の写真撮影会、写真家さんを呼んでユーザー呼んで。そしてお話し合い。｣、｢懇親会｣
月に7回くらいユーザーさんとの関わりがある。
3日以内に予約するルールだが、則っているユーザーさんは50%くらい。みんな直前に予約するので貸し手と借り手との不整合があった。
なので、平行予約機能を作ってみた。が、使われたのは問い合わせ中の3%。
認知さていないのでは?と思って告知をしてみたが更に減少。
良いだろうと思って作った機能であったが、使われなかったので該当機能は削除した。
開発プロセスのお話
ラクスルさん
リリースしてから失敗に気づいても遅い。負の投資になる。
リリースする前に失敗をする。
失敗をデザインする。(中竹さん)
｢良いコーチは失敗のデザインが上手いのです。｣
ラグビーにて、雨の日を想定して掴みづらいボールで練習する。など。
仮設があっているか?
試作品で検証、ワイヤーレベルでも検証する。
開発者に必要なのは、仮設の"証明"ではなく。仮設が正しいのかを検証して"学ぶ"姿勢が必要ではないのか?*11
Natureさん
頭でっかちに成らない。
フレームワークを踏み抜きまくる。
メルカリさん
ダブルダイヤモンド。
1.アイデア
2.ユーザー理解、観察と参加
3.チームワーク開発
4.デザインスプリント、検証
5.プロダクトGo or Stop
トークセッション。からのまとめ
｢愛されるプロダクトを作る。｣必要とは?そして、自分(たちPdM)は何をすべきか。
万物の発展のため!!とか思ってる。
そういうプロダクトが無いと、人類とか社会とか動物とかいろいろ終わっちゃうんじゃないかなーとか思うし。
ただ便利になる為。というだけでなく、
環境に合わせて豊かさとは何かを考えてそれを獲得していけるプロダクトを作っていかないとなー。と思った二日間でした。*14
*1:お前だお前!w
*2:よね。
*3:なかなかハードなところあるかもね!
*4:という手段が採れる場合
*5:個人的に大切な気付きなのでヴィジョンとはわける
*6:インフラなところあるものね
*7:わかる。
*8:これ系は｢便利｣で作っていると思ったらそういうわけではなかったので興味深し
*9:衝撃だわww
*10:とても貧しい
*11:検証方法を蓄積するっていうことでよいのかな。もしくは、検証からユーザーの要求を学ぶ。ということなのか?
*12:それでウケると思っていた。とのこと?
*13:学習時間もかかれば、効果が出るまでに時間がかかる。
*14:待て待て、開発者として広く考えているならそれでいいだろうけれどPdMとしてはどうするの??
