pm(perl mongers)なのに、perlの話が｢チョトだけな｣吉祥寺pm(以下、キチピー)に行ってまいりました。
LTで参加したことはあったのですが、今日はゆったりトークで参加させていただきました。
kichijojipm.connpass.com
kichijojipm.hatenablog.com
＊スライドやグラレコなどは上記にありますゆえ、そちらを参照するようにしましょう。
大衆ビストロ 煮ジル 吉祥寺店 - 吉祥寺/バル・バール [食べログ]
自分の気づきを中心に"自分用"の備忘録的にまとめ。
業界的にも?徹底もされていなければ、知識的にも心得ている方が少ないからかな。
ちな、困ったら法務関係の方と相談しましょう。
規則的なものはドキュメントを見るのがよいですね。
日本語版ドキュメント
https://ja.pcisecuritystandards.org/minisite/env2/
提供元らしい。ステキ。
http://www.intellilink.co.jp/article/pcidss/26.html
責任者的なところもあるので広さもある。
その広さに悩んでいる方も見てきたことを考えるに定義の必要性ってあるんだろうなぁー。とか思う。
バリエーションを用意して、自分も選択するし、周りも認識してみんなハッピー。的なのだろうけれど。
今後、変化していったりするのかな。
ヒトリゴト
チームビルディングする時に、役割をカードで並べて取っていくイメージ。
RACIチャート。
のだけれど、連携を強める、コミュニケーション齟齬解消などの為の理解が必要。という話なので、
分業や連携が進んだチームであるならば、いきなりPMキャリアにいくこともいいんじゃないか?という気付きを得た。
30の項目定義をしている。
個人の特性を見て、計画的成長を促す。
組織成果を最大化する。
市場に埋もれないよう、差別化、特徴づけ。
話題を絶やさない。
北米では、PdMは体系化されている。(海外動向)
PdMとPeopleマネジメントが分かれている。
PdM=30代男性。ダイバシティの確保が必要なのではないか?
PMに必要なのはニーズの発見力。
コンピューターサイエンスはいらない。
PMは最初からPM。
PdMは社長に近い。
それぞれ特化した人材で組織的には縦割り?分業されている。
プロダクトをマネジメントして目標を達成する。
姿勢と責任を持っている。
体資本ですしね。
以前、一緒に働いていた方が完全食です!!*1とか言ってサプリばっか食べていたけれど。
自分の気持ちとしては足りないと思うんだよなー。
栄養観点はわからないけれど。
味を楽しむとかもマインド的に良いことだと思うし、噛む力とか体のつくり的にもね。
ちな、上の方は個食が好きっていうわけではない。*2
食事という企業内のプロダクト。
ある種の物理的な製品以外にもプロダクトとしてとらえマネジメントするのは興味深いな。って最近思う。
わかりいいよね。具体的だし。気持ちがいい。
｢体調悪いのですか?｣｢お口に召しませんでしたか?｣とケアの言葉を伝えるようにしたら減った。
しかも、数カ国語で。
そして、コストが改善され担当の方たちの評価があがり待遇も良化した。
なんとなく思うけれど、食べ残しを減らしたい気持ちもあったのかもしれないけれど、ケアの言葉って担当の方たちの気持ちとして自然と出てきている気がする。じゃないと続かないしね。
フェーズ1、同質性、空気を読んであわせられる人。
フェーズ2、多様性、おそらく管理者が必要。
一生懸命やろうとみんなしているけれど、齟齬がどうしても生じる。
共有することで各位、自律的に動ける。
｢リズム、ステータス、KPI｣
年齢、学歴、web業界。*3
LINEさんww
スターエンジニアがボトルネックになることもある。
人もそもそも足りない。
育成は、ライブコーディングとコーディングバトルを通して。
VSCode使ってる。
衝突を避ける方法として、チームの価値基準を策定し判定する。
コンポーネント型からフィーチャー型へ?
｢日本で流行って、世界展開する時に再開発だと周りに遅れる。｣
白か黒かっていう話ではないと思うけれど、開発コストが早いフェーズでちょっと増えるよね。
戦略として、タイミングなど何を選択するかだよね。
その辺の振り返りとか聞けると良かったな。
プロダクトマネジメントと経営学?
そういう戦略も必要な時あるよね。
ここ数年触って無いな。という改めて最近の状況を探してみるのも面白いだろうな。
でも、モノづくりって大変だよね。
ということを理解しているステークホルダーはコミュニケーションのハードルは低くなりやすいけれど、馴れ合いにもなりかねない。
協調関係が築けると良い。
またはブランドなども考慮。
ドメインを極める。
何かに浮気するより、注力することで見えてくるニーズがある。
入社から活躍するまでがトップの責任
エンジニアが優秀なのと営業マンが多いので、PMはHowは気にせずWhatにフォーカスして行動する。
｢送信取り消し機能｣めっちゃ揉めた。
ストーリー的には｢投稿したものを削除する｣というだけなはず。と思っていた。
しかし、考慮しなければいけないことが多くあった。
消されることによって、約束が反故にされる。
いじめの証拠が消される。など。
じゃあどうする?いつまで消去可能にする?完全に消せるようにする?など考慮しなければいけない仕様が出てくる。
プロダクトの方向付け、ユーザーの心情やブランディングなども考慮。
エンジニアさんといろいろなパターンを試してみた。
全員は満足する方法はないだろう。
どうすれば??
どの方法を採用するのか。ここからがPMの本領発揮。｢どう使ってほしいのか?を突き詰める。｣
LINEとしては｢間違えて送ってしまった!!でも既読になっていない!!｣みたいなものを消せることで、
コミュニケーションの失敗を低減したい。という想いに立ち返って仕様を決めた。
リリース後、マイナスの反響もあったが、すべてのユーザーが満足するものはないと思っていたところもあり納得している。
物づくりの場にいると、誰かしらが｢〇〇を作りたい!!｣という気持ちでいつの間にかPdMになっている気がする。
そうじゃないと、カオスになってプロダクトが終わるか時間を無駄にしてある意味終わる。
国レベルで怒られることがある。*6
業者や配送屋さんの空き時間を使ってもらう。
現場にソフトウェアを使ってもらうのは厳しいし大変。
社内に配送経験のある方がいて、その方と確認しながら進めていたとしても。
現職配送屋さん｢両手では使いづらいです。(自分たちは)荷物持っているか、ハンドルを持っているか。｣
ということも合った。
｢作りたい!｣という気持ちを持っている人は、仮設から一直線で作り込んでしまう。そして失敗する。*7
社名が判然としなかったついでに調べたのでURLも貼っておく。
スマートリモコンのNatureRemoの会社さん。https://nature.global/jp/top
｢電気の需要の観点で問題視していた。電気を効率的に使おう｣という思いから開発。*8
一部故障品が発生してしまった。
お金もなく対応に苦慮したが、お客様と時間をいただき交渉しながら全品交換対応。
プロダクト選定基準。｢わくわく、もうかる、やる意味(競争優位性、レア)｣
機能が使われ生きるまでのストーリーを書くのがPdM。
ストーリーが破綻していたら、若しくは書けないのであればそれは不要でしかない。
コンセプト、価値を明確にする。
Anyca=車、男性的、安心など。
ユーザー向けにやってること、｢サービス説明会を定期的に｣、｢投稿用の写真撮影会、写真家さんを呼んでユーザー呼んで。そしてお話し合い。｣、｢懇親会｣
月に7回くらいユーザーさんとの関わりがある。
3日以内に予約するルールだが、則っているユーザーさんは50%くらい。みんな直前に予約するので貸し手と借り手との不整合があった。
なので、平行予約機能を作ってみた。が、使われたのは問い合わせ中の3%。
認知さていないのでは?と思って告知をしてみたが更に減少。
良いだろうと思って作った機能であったが、使われなかったので該当機能は削除した。
リリースしてから失敗に気づいても遅い。負の投資になる。
リリースする前に失敗をする。
失敗をデザインする。(中竹さん)
｢良いコーチは失敗のデザインが上手いのです。｣
ラグビーにて、雨の日を想定して掴みづらいボールで練習する。など。
仮設があっているか?
試作品で検証、ワイヤーレベルでも検証する。
開発者に必要なのは、仮設の"証明"ではなく。仮設が正しいのかを検証して"学ぶ"姿勢が必要ではないのか?*11
頭でっかちに成らない。
フレームワークを踏み抜きまくる。
ダブルダイヤモンド。
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としてはどうするの??
さぶたいとる:サーヴァントリーダーシップの限界
今回のネガティブメンバーとは｢愚痴を言う｣、｢怒る｣など、恒常的にネガティブな表現を周りにする人のこととします。
成果が出ていない。というのは今回は対象外です。
育成コースに移すなりしましょう。
ネガティブなメンバーをマネジメントしている。
ネガティブなメンバーのマネジメントを今後は避けたい方。
マネージャー職に向けて今後の心構えをしておきたい方。
マネージャーであるならば、第一に、環境に対して文化づくりや評価、メンバーに対して育成やメンタリングなどを行い、ネガティブなメンバーを産まない土壌づくりをすべきだと思います。
ネガティブメンバーはマネジメントすべきではない、です。
多様性は認めつつも”合わない”と思うメンバーはチームへ入れない、早くに外すべきです。
そして、気の合うメンバーでチームを構成すべきです。
それは、ネガティブメンバーにとっても新たな活躍の場所に所属するキッカケにも繋がります。
参加しないと身につきもなければ気づきもないからな!!
それから、マネージャーとメンバーの関係って"一対多"だから。
マネージャーってメンバーに対して思っていることがあまり無いよね。っていう論調があると思うんだけれど、
そういう人ももちろんいるのかもしれないけれど、メンバーに対して"一対一"で向き合おうとする人も沢山いる。
マネージャーに対して真面目に困っている人がいたら、他のマネージャーの人に相談するとかしたほうがいいと思う。
まだ始まったばかりの集まりに40数名の人間が集まるんだもの、ちょっと探せば良い関係が築けるマネージャーがいるさ。
って、コンビニに酒を買いに行く沢山の背中を見てなんとなく思った。
このテーマで話された内容というよりは感想とかヒトリゴト。
自分の｢エンジニアマネージャーをこれからも続けていくのか?10年先も?20年先も?｣という問いかけ。
マネージャーorエンジニアの切り口からスタートして、マネジメント領域だと同じことを繰り返している感じもして飽きもある。
(だから、人事や広報を最近やり始めているという方もいた。)
なんかワクワク感が薄らいでいる。年をとって鈍感にでもなったかな?
｢エンジニアマネージャーを初めました!｣っていう方もいて、勉強しながら頑張ってます。とか、大変さに戸惑ってます。とか。
そうだよねウンウンとか思いながら。
自分が何かこの先の発展や成長があったとして何が出来るのか残せるのかなー。とか考えていたり。
勉強するのは楽しい、物を作るのも楽しい。マネジメントだって、コード書くのだって楽しい。
楽しいのだけれど、何が残るんだろう。
今自分は、エンジニアマネージャーなのか、プロダクトor プロジェクトマネージャーなのか、そんな岐路にいる気がする。
そもそも岐路なんて意識する必要もないんだけれどね、やりたいことをやれば好きに生きられるだろうし。
健全な開発現場の構築とそこから生まれるプロダクトが、現場も利用者も楽しくいきられることが大切。
それだけなのだけれど、肩書や役割が自分の気持ちの邪魔をしている気がする。
自分にフィードバックしないといけないタイミングとかなのか。
否、ワクワクを探しに行くのだ!!作業興奮だ!!
よし、EMの未来は明るいゾ!!
疑問:作業興奮をしようとしても、ついダラダラしてしまう感じになると無駄時間になる。あれの分かれ道ってなんだ??
などなど
上司になってくれる方募集!!
10月は決算発表が多い時期ですね、皆さんいかがおすごしでしょうか。
こういった時期は、ネット上でなんやかんや給与問題が取り沙汰されがちかと思います。
ということで、今朝ふと思ったことを書いていきたいと思います。*1
評価=給与ではない。
給与は個人の実績を評価して決められる。と同時に会社の状況を踏まえて決められている。
しかし、評価から給与決定の一連の流れというのは、個人の実績のみが考慮する対象だと思われている。*2
ここが多くの問題を引き起こす原因だと思う。
そこで、給与決定に関しては｢評価｣という個へのフォーカスになりそうな言葉を使わずに、｢分配｣という組織全体にフォーカスする言葉に変えて運用してはどうか?
という提案である。*3
｢半期に一度、利益の分配計画としての人事評価があります。｣みたいな感じですかね。(あ、評価って使っちゃった。)
そうでないと、会社が赤字*4になります。
会社を運営するにあたって様々な費用が必要になってきます。
社員に給与を渡すだけでなく年金や社会保険などの福利厚生の費用も支払っていたりします。
もちろん、直接売上を上げる部門ばかりではありませんから間接部門の方も含めてになります。
他に、会社のPCや文房具などの設備、賃料や光熱費など、今後の投資への費用も必要です。
また、利益が出ない期間があったとしても給与を払えるよう余剰も必要でしょう。
そういった費用が積み重なった結果がだいたい給与の3倍だと言われています。
自分の組織の売上、利益を知っていますか?
冒頭にも書きましたが、評価=給与ではないと思っています。
例えば、評価していても昇給できない時もあるし、昇給があったからといって評価が良かったわけでもない時もある。*5
そして、こうも言えると思う。
成長=昇給ではないということだ。
成長したからといって売上がどれだけあがったのだろうか考えてみてほしい。
だから、昇給されないからといって評価について落ち込む必要はないし成長していないわけでもない。
もし昇給されないなら、会社の利益が出ていないかブラックなだけだ。
｢利益がなければ昇給は求めるな?｣そんなことはない、昇給を求めてもよいと思う。
生活を豊かにする方法としてごく自然なことだと思う。*6
そして、昇給は組織が自分の成果をわかりやすく表現する方法でもあると思う。
要求と同時に自分の組織への成果がいかほどであるかを伝えるようにしよう。
投資としての昇給だ。
売上げがなくとも会社の投資として昇給をする場合もある。*7
特に、経験的に若手の場合は給与が賄えるだけの売上がたたない場合もある。
それは、将来の成果に対しての投資と一定の給与によって社員の生活を守るためでもある。
自分の給与が、他組織、他者と比較して高いまたは低い。
それは組織の判断であり、方針である。
利益があろうがなかろうが。
能動的に働こうが受動的に働こうが。
業界内の需要と共有の関係もあるだろう。
｢じゃあ売上がある組織にいるほうがいいじゃないか。｣｢利益をあげることだけ考えていればいいのか?｣*12
自分の所属する組織の方針だ、良いか悪いかは自分で考えて行動するしか無い。*13
その時は、異動でも転職でもいいし、引き続き組織で利益が増えるよう行動するようにしてもよい。
はたまた、評価と給与制度の見直しに挑戦するのもいいかもしれない。
共に働くのであれば、評価する側も評価される側も責任を持って判断しなければいけない。
給与を決める場合には、個としての｢評価｣で行うのを止めて、
売上から会社の費用差っ引いて、｢分配｣という形で行ったらいいのではないか?
じゃあ一律に分配するのか?というとそれもどうかとは思うので、組織内の責任の上下とか能力差も考慮するとよい。
それから貢献度*15とか、それらの具合でちょっと割合いじって分配すればいい。
その結果、昇給になることもあれば、減給になることもあるだろう。
ついでに、関係者が全員見える形でやれば納得感も出るのではないか?*16
｢利益出てるのに給与あげない組織かよ。｣とか｢給与上げすぎると会社立ち行かなくなっちゃう。｣とかわかるじゃん。
なので、給与を決める場合は｢分配｣をオススメしたいと思います。
言葉変えただけでやってることは変わらない。
給与に対しても、組織への関わり方にしても、当事者が｢何を大事にするか｣だと思います。
確か、ティール組織の思想を採用したとこなどで、自分の給与を決めたりするところってありましたよね?
内部留保吐き出せという話もあるんでしょうけれどね。
｢企業の内部留保、過去最高446兆円 17年度法人企業統計｣
https://www.nikkei.com/article/DGXLASFL03HS5_T00C18A9000000/
給与交渉は評価のタイミングではなくて、目標設定のタイミングですべきだと思う。
そして、評価する側が必ず｢個人の実績だけではなく会社の状況も踏まえて評価することになる｣ということを伝えるべき。
｢好きなことやってるから給与が低くても良い。｣というのは無い。｢給与良くして好きなことをよりやれるようにする。｣が良いと思います。
*1:マネジメントの目線に寄りすぎていたらご容赦を、不勉強なところもあるのでツッコミ歓迎
*2:気がする…自分の印象として…。
*3:言葉の定義についても自分の印象ですけれどね!!
*4:IT系だと利益率高い傾向だったりもするので少し良化しますかね。
*5:売上げいいから全体のベースアップなど。多くの場合はボーナスですかね。
*6:一般的な意見として
*7:自分が駆け出しの頃、上司自身の給与を削ってでも部下の給与を確保しようとしてくれる人がいたなぁ。それがいいかどうかはまたあるのでしょうが。
*8:どこの組織にも認められないなら、個人としての能力がないということもあるかもしれませんね!(泣笑)。
*9:組織の見る目がない、方針が悪い。ということもあると思います。
*10:長いな…。
*11:そんなことお構いなしな人間もいるので注意は必要だろうけどね。
*12:そんな事を言い出したら世も末だよ、そういうものは好きじゃない。
*13:多くの人が方針の合う組織に居られることを願う。
*14:疲れてきた…
*15:ラッキーパンチでもいいし。
*16:組織であるなら透明性が大切。
気が向いたので、つらつらと書いてみる。
退職すると時間があるもので、
どこか長期で旅行にでも行ったりするものなのだろうが自分は特になく。
何をしていたかというと。
そして健康になっている。
1万歩達成ペースが早くなっているし、足への疲れも減ってる。
開発には集中出来ていると思うし。
久しぶりに集中してコード書いているのは楽しく、
ReactNative+expoは脱初心者くらいまでにはなったかなと。
｢ReactNative+expoﾁｮｯﾄﾃﾞｷﾙ。｣
また、オーナーが自分なので変なストレスもない。
それから毎日2,3時間は平気で歩いたりなんかしたり、
ご飯やお酒の美味しいお店も見つけられたり楽しい。
(運動しているのに腹が出る不思議。)
先週、アプリ開発が一段落した。
最初の1ヶ月くらいは開発環境の習熟、もう1ヶ月はアプリ開発で、ミニマルなアプリが上がった。
そして、今後のロードマップ的なものも引けた。
(セキュリティとかスカスカなので、まだリリースはしないですが…。)
この先は、知り合いの人に触ってもらいフィードバックをもらいつつ開発を進めればいいかなと考えている。
特に一人で開発していて気づいたこと。
｢この心地よい開発の現場はスケールしないじゃないか!!!!｣ということ。
一人2ヶ月で1アプリ作ったとしても、良い開発の現場は増えていかないんだよね。
｢お前が1つでも良い開発の現場を作れてきたのか?｣と言われたらアレだけれどさw
まぁ自分としてはそう思ってやってきたつもり。
社会の成長や幸せを、確率高くそして効率良く可能にするのはエンジニアだろうと思ってる。
真剣に｢エンジニアが一番向いているんじゃねーの｣って思ってる。
昔から常に。
けど、それを生み出すエンジニアの現場環境はまだまだ良くない。
それを良くしたい、増やしたいと負けじと自分は思っていたりする。
そんな感じで、マネージャーやプロマネなんかも勉強して動いてそれなりに評価いただくまでになれたけれど、
まだまだこの先、必要とされるエンジニアの人口は増えつつも、それを補える程のエンジニアの増え方はしないだろう。
一人一人のエンジニアにのしかかる要求、負荷は増加傾向になる。
そういう社会にはなりたくない。一人でも多くの幸せが増やしたい。
｢一人こもって開発してる場合じゃねー｣なと。
Q.よい現場を作るために、開発のコーチングをしてるのはどうか?
こないだとある方にお話させていただいた。
｢開発現場のコーチングやアジャイルのコーチになるキャリアパスってなんだろう。｣という話。
結果だけいうと｢自身の活動の結果そうなっている。｣という話で、肩書つければ仕事が出来るわけでも無いんだよね。っていう。
そりゃそうだよね。
そう考えると、今まで通りチームを作ってプロダクト開発を通して、
チームで成長して、自分やそのメンバーで次に広げていくっていうのを地道にやっていくしか無いんじゃないかなと。
(他のアイデアがあったら知りたい。)
また、個人的に言うと、事業の成功が正義な感じもあるので、良い現場の話だけでなく、
当然な話だけれども｢良い現場と良い事業をゴールとしてやってくのが良いのだろうなと。
(当然の話を何をくどく話しているんだ。)
企業様でお話を伺ったり、または勉強会の懇親会に参加したりして開発の現場で困っているところは沢山ある。
じゃあ、出来るところからやろう。とも思うが、とはいえ、まだどうするか考えている。
企業に入る道もあれば、投資していただいて人を集める道もある。
どの道にもビジョンがあり興味深いミッションがある、そして素晴らしいチームがいる、将来的にも。
｢ネットは広大だわ…｣とも言いたくなる。
