良い人に集まってもらうことの大切さ。とか、なんかつぶやき。

「さよなら2018年、ようこそ2019年!」
まだちょっと早いか。

はじまり

完成させる気概

非エンジニアの方から見ると*1、お金をお支払いして依頼したエンジニアだったら「お願いしたものを作ってくれるだろう。」という認識が一般的にはあると思う。

そして、面接なんかで「○○を作ってきました。」「○○に携わってました。」みたいな話で入社。
「アレを作って欲しい。」などと作業に入ってもらうけれど、仕様だって最初から詰めきれているものでもないし、企画側とエンジニアが話し合いながら1つ1つ作っていったりする場面もままあったりして。
企画側も企画側で、仕様の決定に悩んだりして、悩むくらいなら決めて良いか悪いか判断すればいいものを、開発日数を食いつぶしていたりするもんで。*2
でも、なんやかんや、言ったものと違うものでも完成したのならば未だ良いんですよね。
何にしたって良ければ成功だし、悪ければ失敗した。といって次にいけるから。

そんな開発の現場にいるのが、完成させる気概がないエンジニアだったりすると…。
出てきた仕様に対してプログラミングして、仕様が不足していれば質問して、回答が返ってくるまで待ってたり*3して…進んだり戻ったり、戻ったり進んだり、見た目は違うんだろうけれど、当初と本質的には変わらないプロダクトが横たわってたりする。*4
とはいえ一応は業務しているわけで給与なりが入ってくるから、当人にはさして問題ないんだよね。

「リリースできない」なんて言っても。
言われたことを「やりました、やったんですよ必死に!その結果がこれなんですよ!!」*5なんてのたまったりする。もちろん指示や依頼が穴ばっかな場合もあるんだろうけれど、作業に責任は持ってても完成に責任持ってなかったりするからまぁそうだよね。

じゃあ、完成させる気概を持っているようなエンジニアだったら?
改善提案し、一つ一つ完成に導いてくれる。*6
にしても失敗することはあるけれど、少なくとも期待通りの挑戦はしていると思う。

既に気概を持っているエンジニアがいるのであれば、手数として数名*7を招き入れることもありだろうけれど、可能なら控えたほうがいい。損失のリスクを減らせる。

「戦いは気概だよ兄貴」

どんな状況だとしても受け止められる器量

続きの話でもないけれど、完璧な開発チームなんてそうそうないと思う。
どんなに優れたチームでも、まだまだ非力なチームでも自分たちの持っているリソース(時間、お金、能力など)では足りないプロダクトの完成に向かって開発作業をしている。

完成までの距離もピンきり。
手が届くような距離にあったり、霞むようなほど先にあったり。
そして、霞むような先にあるようなプロダクトの場合は、落ち着いて今の状況を分析して目標までの道のりを考える。
たとえ、時間やお金を費やす必要があっても知ることが大切。
それで命とられるわけでもないでしょ?

でも、分析したときにどうにもならない時もある、だったら諦めることも必要。
プロダクトが完成しなくたって生きていけるし、また別のプロダクトをやり直せばいい。
やり直すのも大変だけれど。*8

まぁそうならないようにする為には「人なんだろうなー」って思う。

程よいプレッシャー

学生の頃に教授に言われたことを今も覚えてる。
「負荷かけないと脳みそくさるよ。」*9

だから「全然平気」というよりも「ちょっと大変だな。」って思うことに常々取り組むようにしている。

そして、そんな感じでプロダクトの完成に向けて一緒に挑戦してくれる人の集まったチームワークの面白さったらないね。

*1:そうとも限らないんだろうけれど

*2:このくだりはいらないか

*3:とはいえ何かしら見つけて作業していたりするんだけれども

*4:何年プロトタイピングしてるの!!!

*5:すみません、言いたいだけです。

*6:その作業とプログラミングの作業の負荷は考慮しないと体力的に大変だし、契約的にもオーバーワークになったりすることあるから注意が必要。

*7:ほんの数名

*8:人生かかってるプロダクトだったら…ガクガク………。

*9:とはいえ人間の記憶は曖昧さーね

「俺たちのようには!なるなぁぁあ~~~!!」

そろそろ2018年も終わるけれど1年のふりかえりというものではなく、ここ最近感じたことを徒然とPdM的、EM的に感じたことを吐露してみる。

PdM的に感じたこと

誰にどう使ってもらいたいプロダクトなのか考えること

同じ機能を持ったプロダクトだったとしても、使われるものにもなれば使われないものにもなる。
「何を作るか」、「どう作るか」も大切だけれど誰にどう届けるかを考える。

方法は、プレゼン?UI?CM?はたまた別の方法?

その人たちにどう伝えれば使ってもらえるのか。
対象や届け方によってプロダクトの魅せ方、作り方も変えよう。

ペルソナ、ユーザーストーリー、カスタマージャーニーマップ、ジョブ理論があったとして、
便利だったり楽しい機能があったとして、
最新の技術、管理しやすい技術で作ったとして、誰にどう届ける?
期待通りに認識してもらわなければ使われない。

それでも、うまくいかなかったりするんだけれどね。
*1

グロースのシナリオを作り、評価しながら開発すること

何も無しに闇雲に開発作業をしてはいけない。

プロダクトに自信があったとしても、正しい方向を向いているのかは結果が出るまでわからない。
開発した機能が期待通りの結果であるのか、自分たちの思考を調整しながら成功の再現性を高めていく。

プロダクトの評価が良いものであれば、長い開発においても、
チーム内ではモチベーションが保たれるし、チーム外からは期待を得ることも出来る。
*2
*3

何があっても歩みを進めること

"悩む"ことと"考える"ことは違う。

"悩む"は、あーだこーだ、苦しむこと。
"考える"は、現状と目的に対して解決の手段を導きだすこと。

"悩む"を"考える"に変えるには、整理すること。
整理とは、「現状を把握」し「何をすべきか」を考え、その間にどんな問題があるか一つ一つ洗い出すこと。
そして、その解決手段を出していく。
そうすれば、"悩む"は"考える"に変わる。

うまく出来ていないと思うなら、気分転換するでもいいし、周りの人に聞くでもよい。
なにごとも焦らないこと。

また、悩んでいるくらいであれば何か試してみよう。
失敗したら何故失敗したのか振り返り、またやってみればいい。
やらないで何もできなかったよりも、やって失敗したほうが同じ轍を踏まないようにする分マシな自分になっている。

今、解決できなくっても、いつか解決出来るときがくるかもしれない。

やるからには腹をくくること

くくれないなら、早々に止めるべき。
何のためにやっているのか。わからないなら考える。
腹のくくれないものやってても、人のせいにしかならない、ふりかえれない。

EM的に感じたこと

生存戦略として選ぶなら、好きで続けられるものまたは得意なものがよいと思う。

働く上で、なにを得たいのか、今一度考えてもらいたいなと思ってる。
肩書?お金?査定評価?働きやすい環境?一緒に働くメンバー?または自分の能力やキャリア?
取り繕うことなく、かつロジカルに考えてもらいたい。

よくあるなー。と感じるのが、エンジニアやりたいです、マネージャーやりたいです、PMやりたいです。
開発やりたいです、人をまとめたいです、プロダクト作りたいです。
けど「どうしたら出来るようになりますか?」「何をやったらそうなれるんですか?」「評価されるんですか?」と自分の答えや仮説を持たずに疑問だけを持っていたりする場合。

話をしていくと、本質的にはエンジニアがやりたいわけではなかったりする。*4
また、エンジニアとして続けられないからマネージャーをやりたいと言っていたりする。

けど、本当にその理由でエンジニア続けられるの?マネージャー続けられるの?PM続けられるの?
そして、続けられないと、得られるものも得られないよ?

まぁ何やるにしても、上手くいくことも下手こくこともあったりして、思わずハマったりするから。
好きなようにやったらいいし、挑戦してもらいたい。
何があっても「それでも!!」っていうならそれでいいと思う。*5

あまり周りの評価を気にして何やったら良いか考えるより、「きっとこれだろ」と思って挑戦して成功なり失敗なりを経験する方が有益だと思うけれどね。*6

自分じゃない何かの物差しで生きてるとその物差しの中でしか生きていけなくなるよ。

*1:それに、モチベーション次第ではどうでもいいんだけれどね。

*2:人や資金が集まることによって継続した開発が可能になる。

*3:グロースハック

*4:給与が良いからとか。

*5:「俺たちのようには!なるなぁぁあ~~~!!」

*6:一度の失敗が命取りになることもあるけどね(汗

エンジニアリングマネージャーの種を前向きに植えたい

もしくは、エンジニアリングマネジメントの価値を前向きに植えたい。

はじめに

絶望しているわけでもないし、希望も持っているし、その通りに実行もしている。
けれど結局は、
ビジネス的要求、
必要にかられるような状況、
辞令、
コマンドアンドコントロール
といったような、自分の希望からではなく、外界からの力によって生まれるエンジニアかつマネージャーが多いのではないのか?
生存本能かなにか、必要にかられてEMになっている、だが今は幸せだしこれからもそうだろう。
しかし、その発現はちょっと寂しいと思っている。

最初は後ろ向きだけれど、やがて前向きにな感じになるともいうのですかね。
*1

事前説明1

以下、エンジニアマネージャーをEMとする。
そして、EMってざっくり説明。
EM=人、組織などなど特化型、VPoE的な人。
テックリード=開発、技術力などなど特化型。設計から実装、テストが凄い的な人。

事前説明2

自分の思考の発散で駄文なんで、余程暇な時以外はそっ閉じしてください。
世の中には様々な"視点"があると思っているので意見があったら優しく教えてください。
勉強しますから、どうか後生です。

EMとしての自分の成り立ち

自分の性質として、相手のものさしで動くことが苦手、コントロールされるのが苦手。
納得のいかない管理は精神的衛生上受け入れられない。そしてそういうことがまま起きていた。

それは一緒に働くエンジニア*2もいやだろうし、
それは、幸せな現場ではないわけで愛されプロダクトは生まれづらい(生まれないとは言っていない。)だろう。

そんな生き方は自分はいやだから。ならば自分が自分をチームをマネジメントしよう。
というのが成り立ち。*3

理想のEMの誕生きっかけ

逆に、理想のエンジニアマネージャーが生まれる動機としては、以下な感じなんですよ。
「愛されプロダクトに携わるエンジニアマネージャーかっこいい!すげー!パフォーマンスすごい。
エンジニアのメンバーもすごいけれど、そのメンバーをコラボレーションさせてるのすごい!
プログラミングの開発力も素晴らしいけれど、自分は凄い人たちに頑張ってもらえる凄い環境を作ることがやりたい!!」
みたいなことじゃない?って思うんですよ!!*4

けれども、そういう人は現実には多くはなさそうだなと思っているわけです。

EMになろうとするきっかけ頻度考察

で、エンジニアリングマネージャーになろうと思うきっかけの頻度を考えてみると、

EMになるきっかけ=組織の数 x ビジネス機会 x (前向き要因 + 後ろ向き要因)とかかなって思って。
さらにEMとして続けていく人数は、EM発生頻度 x (育成環境 + EMに前向き) みたいになるかなって思うわけです。

そうなると、社会の需要に対してEMは絶対数として足りない状態が続いていくみたいなことを考えて、
それって人類にとってきっと不幸な状況が横たわっているなーとか思うわけです。

少しでもEM誕生の可能性を高めるためにも、
どんなエンジニアに対しても研修期間などにはEMの基本的な知識を備えてもらえるよう時間をとるようにしていたりする。*5

EMの発生頻度をあげる為に「それでも!」と言い続ける。

けれども、それじゃあトップラインがなかなかあがりづらい。

EMのクラスタに来る人は、EMに"なっちゃった"系の人が多いように思う。
現在エンジニアで「EMになってみようかなー。」みたいな人はそんなに見かけない。
そんな人はそういった場所にはこない、クラスタへの参加のハードルとかなんやかんやで。
ひとまず行ってみるか!役に立つかもしれないし、みたいな興味あるモチベーションで参加してくれる人が少ない。
時間も有限ですしね。*6

それでも、現場でツラミを抱えている人や組織に届けたいのですよ!!「EMっていいよ!!」みたいなことを!

なので、EM以外の勉強会やコミュニティで、そんな話を今後も続けていきます。
そして、いつか勝手に植えさせてもらったその種が自ら芽吹くときをねがってやまないのですよ!!

おまけ1

あ、でも自分の話って課題解決スタートみたいなところあるな、考え直してみよう。

おまけ2

エンジニアリングマネジメントだけじゃなくて、プロジェクトマネジメントとかプロダクトマネジメントについても同様のことを考えている。

*1:前向きじゃないとEMなんてやってられないし、やらないべきだと思う。

*2:思考の方向性が似ていることが前提ではあるが

*3:まぁわがままなわけですよ。

*4:めちゃくちゃポジティブ!!

*5:「ともすればエゴと呼ぶべきもの。」

*6:自分だって気づきがないだけで、知っておいた方がいいこと沢山あるだろう。

エンジニア採用どうしてますか?

これは

qiita.com

こちらのアドベントカレンダーの9日目の記事です。*1

はじまり

採用に関してここ数年、新しい動きをしていない。
何が正しいとか、何が間違っているかではないと思うけれど、なんだか自分が凝り固まっているんじゃ?という思いと、同様に考えている方がいたら一緒に考えられたらな。と思い書き出してみる。

皆さん、採用どうしているのでしょうか。
自分は社員採用する前に一緒に働くような「お試し採用」をちょっと試したいなと考えています。

前提

ざっくりこういうような組織での採用についてのお話。

組織規模

会社全体:50人〜200人
エンジニア:10〜50人
走っているプロジェクト:大小合わせて3~10

業務内容

Web寄りのプロダクト開発。
自社開発もしくは、受託も無くはないが協業という形である程度の制約、要求がある中での開発。
toC事業が主流。

最初に懺悔しとく

面接なのに1on1や進路相談みたいになることがある…。
これって「不採用です。」って、その場で言っているようなものだよね…。

技術を通して、やりたいことがある人を採用する。

事業に直結しないまでも社会的に活用される技術や活動を考えて行動している人を採用するようにしている。
逆の場合は、時間もお金もただ消費するだけだと思っている。

やりたいことがある人は、そのやりたいことを話し合えば必要なことを自発的に考えて行動してくれる。
組織的に定義づけられた自分の役割があったとしても、それを越えて行動してくれる。*2

「開発やりたいです。」みたいな、開発で得られることが出てこない人は、それ以外はあまり興味がなかったりする。
そうなると、事業だったりチームだったりと目的意識があっていないから*3組織的に動きづらく、成果としても良い結果が出づらくなってしまう。

面接のときにこういう発言をされた場合、念の為、突っ込んで質問をしている。
「どんな開発をやりたいのか。」
「開発の結果なにが得られるのか。」
「なんのために開発をするのか。」

ただし「開発やりたいです。」みたいな人も、手数が欲しい時や組織の方向性として特化した技術力が必要になる場合には必要な人であると考えてもいる。
手数の話は言うまでもないが、技術のアウトプットの質は、インプットを大量にした結果だと思う。
高度な質を求めるには、その技術に常に探求している必要があると思う。
しかし、常に高度な質を求めるか?というと違うことがわりかし多いと思っている。

いや、実のところ手数だとしても管理コストがかかってきたりするから止めたほうがいいと思っているんだけれどね。

正社員の場合は、組織構造を考えて採用をする。

正社員は会社を組織するメンバーになる人を採用する。
突発的なプロダクトに起因する理由などでは採用しない。
会社の事業戦略(明確なものが無かったとしても短期的にでも想定しうる計画に基づいたもの。)に合わせて人員計画をたてて採用を行う。

チームの目標は何か、その目標はいつ達成させるのか。
そのために必要なパフォーマンスは?そして、どんな人で何人構成にするのか。
誰をマネージャーにすえるのか、それをチームごとに時系列で考える。

採用から話はずれるが、プロダクトが無くなった場合のことも念の為考慮しておくこともある。
これは本当に動きづらい。

会社全体でもプロダクトのチームでも受け入れの準備も出来ていないのに人を入れることと、活動の方向性が散らばらないように所属人数と新人の方の人数比が3:2みたいになるような受け入れ方は避けたほういいと思っている。*4

突発的だったり(突発的なのは極力避けたいんですけれどね。)、準備が出来ていないがどうしても助けが必要、特定の技術力が必要という場合だけ、派遣の方や外注の方にお願いするように心がけている。(心がけている。)

契約の分だけ助けてもらってその分しっかりお支払いをする。

一緒に働く人が面接をする。

主にエンジニアだが、ポジションに寄っては営業の方や事業部?の方などにも面接してもらう。
エンジニアは入る想定のチームに拘らず、マネージャーだったりメンバーだったり、チームが解散したとしても引き続きその組織で働けるかどうかを意識している。
何度も足を運んでいただくのも申し訳ないとは思いつつも、間違いに気づくなら早いほうがいいとそのようにしている。
なので時には、四次、五次みたいな場合もでてくる。とはいえ、無駄に回数は重ね無いように、面接の順番を組んでいる。

組織によっては、人事の方が採用を決めたりする所もありますよね。
組織構造も人事の方が考えていたりする場合も。
エンジニアに限らずクリエイティブな業務の場合、人事の方が決めるのには懐疑的です。

「開発という手段で活躍はしたいですけれど、それによって得られる結果はこのプロダクトじゃないんです。」とか「本当は、開発もしたいわけじゃない。」みたいな人が入って来たときの不幸ったらありゃしない。

もしそういう組織があったとしたら、人事の人に声をかけて一緒に活動するようにするのが組織としても採用される側にとっても良いだろう。

技術的スキルは重要だけれど…。

経験年数が長いのに技術力無い方は厳しいけれども、現状の技術的スキルよりはどういう積み方をしているかを重要視している。
技術的移ろいも勿論あるけれども、事業的変化も多分にあるので、変化に対応する力というところが大切だと考えてのこと。

こういう時に「ネットを調べてます」"だけ"の人は苦手。大して知識吸収もしてなければアウトプットもしていないことが多い。
ネットの場合はピンポイントで必要な知識しか調べられないので知識の広さ深さが足りないと思う。*5
本や勉強会などに参加したり、自分でプロダクトを作たりして少しでも見てもらえているような人がよい。

少し話はそれるが、01の経験やリリース経験、リリース後の運用経験、クローズ経験なども頼もしいスキルだと思う。

この先、対応してくれるか、成長してくれるか。が大切だと思っている。
とはいえ、見るっちゃみるけれどね(汗笑

採用フローは定形はありつつも臨機応変に対応する。

メンバー採用の場合
一次面接:エンジニアマネージャー+メンバー
二次面接:エンジニアマネージャー+メンバー
三次面接:役員

マネージャー採用の場合は
一次面接:エンジニアマネージャー+メンバー
二次面接:エンジニアマネージャー or メンバー + 非エンジニアマネージャー
三次面接:役員

とはいえ形に拘らず、互いに納得できるよう繰り返し情報交換をする。
回数が多いと他社に負ける。みたいな場合は、
そもそもマッチングが他社よりスムーズにいかなかったのだから正しい結果だと思う。

採用活動

長くなるから省略…。
でも、一番はリファーラルだと思う。

終わりに「採用の一つ一つを大事にする。」

採用するにせよ、お断りするにせよ、お互いの人生が大きく変わるタイミング。
どちらにせよ自分もよい人生を送りたいし、相手の方にも良い人生を送ってほしい。

同じ方向を向いているなら一緒に頑張れるし、
違う方向を向いていたとしても「またどこかで」と言い合える。

そんな採用活動を心がけたいものだと思っている。

*1:書くの忘れてたので追記

*2:なんて素晴らしい人なんだ!! しかし、こういうタイプの人は積極的である反面あれもこれもと抱え込んでしまったり、その人にフォローされるが故に周りがあるべき役割を果たさない負荷のバランスが悪い組織になったりしまうので、 適宜、仕切る必要がある。

*3:"開発"がやりたいのはエンジニアだけ。

*4:とはいえ、事業をグロース、チームをスケールさせたいときもあるだろうから、そこは自分なりの覚悟を持って進める。

*5:下手したら間違っていることもある。

吉祥寺.pm #16に行ってきたゾイ。(自分メモ)

pm(perl mongers)なのに、perlの話が「チョトだけな」吉祥寺pm(以下、キチピー)に行ってまいりました。
LTで参加したことはあったのですが、今日はゆったりトークで参加させていただきました。

kichijojipm.connpass.com
kichijojipm.hatenablog.com

*スライドやグラレコなどは上記にありますゆえ、そちらを参照するようにしましょう。

いきなり総括

  • 自分のトークには余裕なかったけれど、出番が早かった為かいつになく落ち着いて楽しめていた…。
  • キチピーは、今回もPerlにとどまらず、PHP、起業の話、人力システムの話とか様々あって(時間的にはミニだが内容の幅的にはビッグな)カンファレンスの様相を呈していた。
  • そしてほぼ懇親会に流れるという驚異。そして、お店煮ジルさん++。お肉美味しい。コスパがステキ。

大衆ビストロ 煮ジル 吉祥寺店 - 吉祥寺/バル・バール [食べログ]

  • まみーさんのスライドを参考に次回は登壇準備をしようと思うのであった。

speakerdeck.com

続きを読む

プロダクトマネージャー・カンファレンス2018に行ってきた。

2018.pmconf.jp

自分の気づきを中心に"自分用"の備忘録的にまとめ。

セキュリティのお話

個人情報保護基準

PCI DSS」(、「GDPR」)。
日本は緩いそうだ。

業界的にも?徹底もされていなければ、知識的にも心得ている方が少ないからかな。
ちな、困ったら法務関係の方と相談しましょう。

PCI DSSクレジットカード業界のセキュリティ基準

規則的なものはドキュメントを見るのがよいですね。

日本語版ドキュメント
https://ja.pcisecuritystandards.org/minisite/env2/

提供元らしい。ステキ。
http://www.intellilink.co.jp/article/pcidss/26.html

PMの領域定義、働き方など

PMの領域定義って、各所でブラッシュアップしながら進めている印象。

責任者的なところもあるので広さもある。
その広さに悩んでいる方も見てきたことを考えるに定義の必要性ってあるんだろうなぁー。とか思う。

バリエーションを用意して、自分も選択するし、周りも認識してみんなハッピー。的なのだろうけれど。
今後、変化していったりするのかな。

ヒトリゴト
チームビルディングする時に、役割をカードで並べて取っていくイメージ。
RACIチャート。

PMは開発経験(企画、デザイン、エンジニア、特にエンジニア)が必要と強く思っている。

のだけれど、連携を強める、コミュニケーション齟齬解消などの為の理解が必要。という話なので、
分業や連携が進んだチームであるならば、いきなりPMキャリアにいくこともいいんじゃないか?という気付きを得た。

楽天さん

30の項目定義をしている。
個人の特性を見て、計画的成長を促す。

サイバーさん

組織成果を最大化する。
市場に埋もれないよう、差別化、特徴づけ。
話題を絶やさない。

ドワンゴさん

PM = Biz、UX、Tech

企画者自身がユーザーストーリーを想像できていない。
その不安を払拭するためなのか作りたい機能が多すぎる。
からのPdMの必要性が生じた。

スマートニュースさん

北米では、PdMは体系化されている。(海外動向)
PdMとPeopleマネジメントが分かれている。

PdM=30代男性。ダイバシティの確保が必要なのではないか?

バイドゥさん

PMに必要なのはニーズの発見力。
コンピューターサイエンスはいらない。
PMは最初からPM。
PdMは社長に近い。
それぞれ特化した人材で組織的には縦割り?分業されている。

DeNAさん

プロダクトをマネジメントして目標を達成する。
姿勢と責任を持っている。

食育大切

体資本ですしね。
以前、一緒に働いていた方が完全食です!!*1とか言ってサプリばっか食べていたけれど。
自分の気持ちとしては足りないと思うんだよなー。

栄養観点はわからないけれど。
味を楽しむとかもマインド的に良いことだと思うし、噛む力とか体のつくり的にもね。

ちな、上の方は個食が好きっていうわけではない。*2

食事という企業内のプロダクト。
ある種の物理的な製品以外にもプロダクトとしてとらえマネジメントするのは興味深いな。って最近思う。

Googleさん

ミッション!!「全社員の寿命を2年伸ばせ!!」「30年後も健やかでいられるように!!」

わかりいいよね。具体的だし。気持ちがいい。

食べ残しが多かったのに困っていた。

「体調悪いのですか?」「お口に召しませんでしたか?」とケアの言葉を伝えるようにしたら減った。
しかも、数カ国語で。

そして、コストが改善され担当の方たちの評価があがり待遇も良化した。

なんとなく思うけれど、食べ残しを減らしたい気持ちもあったのかもしれないけれど、ケアの言葉って担当の方たちの気持ちとして自然と出てきている気がする。じゃないと続かないしね。

チームビルディング

チームの構築フェーズについて

フェーズ1、同質性、空気を読んであわせられる人。
フェーズ2、多様性、おそらく管理者が必要。

情報透明性の大切さ

一生懸命やろうとみんなしているけれど、齟齬がどうしても生じる。
共有することで各位、自律的に動ける。
「リズム、ステータス、KPI」

メンバーのスクリーニング

年齢、学歴、web業界。*3

フラットすぎて言うこと聞いてくれないメンバー

LINEさんww

ドワンゴさん

スターエンジニアがボトルネックになることもある。
人もそもそも足りない。

育成は、ライブコーディングとコーディングバトルを通して。
VSCode使ってる。

衝突を避ける方法として、チームの価値基準を策定し判定する。

スマートニュースさん

コンポーネント型からフィーチャー型へ?

戦略

日本向け?世界向け?

「日本で流行って、世界展開する時に再開発だと周りに遅れる。」
白か黒かっていう話ではないと思うけれど、開発コストが早いフェーズでちょっと増えるよね。
戦略として、タイミングなど何を選択するかだよね。

その辺の振り返りとか聞けると良かったな。

ポーター、コトラー

プロダクトマネジメント経営学?
そういう戦略も必要な時あるよね。
ここ数年触って無いな。という改めて最近の状況を探してみるのも面白いだろうな。

パクる

追っかけている最中はパクってパクってパクる。
そういうタイミングのニーズは、自ら調べるよりもパクる方が効率が良いかも。
差別化や追っかけをやめるときに、ユーザーの価値を考える。
そしてマーケティングで勝つ。*4
追っかけは、パクる。トップはユーザーを考える。

ヴィジョンのお話

ステークホルダーがヴィジョンを伝える。現場は作る。

でも、モノづくりって大変だよね。
ということを理解しているステークホルダーはコミュニケーションのハードルは低くなりやすいけれど、馴れ合いにもなりかねない。
協調関係が築けると良い。

迷ったら立ち返るべき場所

またはブランドなども考慮。

成果の出し方(一例)

pixivさん

ドメインを極める。
何かに浮気するより、注力することで見えてくるニーズがある。

ZOZOさん

入社から活躍するまでがトップの責任

リクルートさん

エンジニアが優秀なのと営業マンが多いので、PMはHowは気にせずWhatにフォーカスして行動する。

PMは、ヴィジョンに立ち返る*5

LINEさん

「送信取り消し機能」めっちゃ揉めた。
ストーリー的には「投稿したものを削除する」というだけなはず。と思っていた。
しかし、考慮しなければいけないことが多くあった。

消されることによって、約束が反故にされる。
いじめの証拠が消される。など。

じゃあどうする?いつまで消去可能にする?完全に消せるようにする?など考慮しなければいけない仕様が出てくる。

プロダクトの方向付け、ユーザーの心情やブランディングなども考慮。

エンジニアさんといろいろなパターンを試してみた。
全員は満足する方法はないだろう。

どうすれば??

どの方法を採用するのか。ここからがPMの本領発揮。「どう使ってほしいのか?を突き詰める。」

LINEとしては「間違えて送ってしまった!!でも既読になっていない!!」みたいなものを消せることで、
コミュニケーションの失敗を低減したい。という想いに立ち返って仕様を決めた。

リリース後、マイナスの反響もあったが、すべてのユーザーが満足するものはないと思っていたところもあり納得している。

プロダクトの活用用途、要求、あり方など

物づくりの場にいると、誰かしらが「〇〇を作りたい!!」という気持ちでいつの間にかPdMになっている気がする。
そうじゃないと、カオスになってプロダクトが終わるか時間を無駄にしてある意味終わる。

LINEさん

国レベルで怒られることがある。*6

ラクスルさん

業者や配送屋さんの空き時間を使ってもらう。
現場にソフトウェアを使ってもらうのは厳しいし大変。

社内に配送経験のある方がいて、その方と確認しながら進めていたとしても。
現職配送屋さん「両手では使いづらいです。(自分たちは)荷物持っているか、ハンドルを持っているか。」
ということも合った。

「作りたい!」という気持ちを持っている人は、仮設から一直線で作り込んでしまう。そして失敗する。*7

Natureさん

社名が判然としなかったついでに調べたのでURLも貼っておく。
スマートリモコンのNatureRemoの会社さん。https://nature.global/jp/top

「電気の需要の観点で問題視していた。電気を効率的に使おう」という思いから開発。*8

一部故障品が発生してしまった。
お金もなく対応に苦慮したが、お客様と時間をいただき交渉しながら全品交換対応。

リクルートさん

プロダクト選定基準。「わくわく、もうかる、やる意味(競争優位性、レア)」

ドワンゴさん

機能が使われ生きるまでのストーリーを書くのがPdM。
ストーリーが破綻していたら、若しくは書けないのであればそれは不要でしかない。

バイドゥさん

「中国は模倣の文化です!!」*9

きんどど?ターゲットは農村部*10

都市部=品質
農村部=価格、偽物でも構わない!!

DeNAさん

コンセプト、価値を明確にする。
Anyca=車、男性的、安心など。

ユーザー向けにやってること、「サービス説明会を定期的に」、「投稿用の写真撮影会、写真家さんを呼んでユーザー呼んで。そしてお話し合い。」、「懇親会」
月に7回くらいユーザーさんとの関わりがある。

3日以内に予約するルールだが、則っているユーザーさんは50%くらい。みんな直前に予約するので貸し手と借り手との不整合があった。
なので、平行予約機能を作ってみた。が、使われたのは問い合わせ中の3%。
認知さていないのでは?と思って告知をしてみたが更に減少。
良いだろうと思って作った機能であったが、使われなかったので該当機能は削除した。

開発プロセスのお話

ラクスルさん

リリースしてから失敗に気づいても遅い。負の投資になる。
リリースする前に失敗をする。
失敗をデザインする。(中竹さん)
「良いコーチは失敗のデザインが上手いのです。」
ラグビーにて、雨の日を想定して掴みづらいボールで練習する。など。

仮設があっているか?
試作品で検証、ワイヤーレベルでも検証する。

開発者に必要なのは、仮設の"証明"ではなく。仮設が正しいのかを検証して"学ぶ"姿勢が必要ではないのか?*11

Natureさん

頭でっかちに成らない。
フレームワークを踏み抜きまくる。

ドワンゴさん

今まで技術ドリブンでした!!*12

学習コストの回収が大変。*13

7ステージのカンバン、各ステージごとに責任者を立てる。

メルカリさん

ダブルダイヤモンド。
1.アイデア
2.ユーザー理解、観察と参加
3.チームワーク開発
4.デザインスプリント、検証
5.プロダクトGo or Stop

DeNAさん

PdMがプロダクトバックログを作成し、何をどう作るのかはエンジニアに託す。

トークセッション。からのまとめ

「愛されるプロダクトを作る。」必要とは?そして、自分(たちPdM)は何をすべきか。

万物の発展のため!!とか思ってる。
そういうプロダクトが無いと、人類とか社会とか動物とかいろいろ終わっちゃうんじゃないかなーとか思うし。

ただ便利になる為。というだけでなく、
環境に合わせて豊かさとは何かを考えてそれを獲得していけるプロダクトを作っていかないとなー。と思った二日間でした。*14

*1:お前だお前!w

*2:よね。

*3:なかなかハードなところあるかもね!

*4:という手段が採れる場合

*5:個人的に大切な気付きなのでヴィジョンとはわける

*6:インフラなところあるものね

*7:わかる。

*8:これ系は「便利」で作っていると思ったらそういうわけではなかったので興味深し

*9:衝撃だわww

*10:とても貧しい

*11:検証方法を蓄積するっていうことでよいのかな。もしくは、検証からユーザーの要求を学ぶ。ということなのか?

*12:それでウケると思っていた。とのこと?

*13:学習時間もかかれば、効果が出るまでに時間がかかる。

*14:待て待て、開発者として広く考えているならそれでいいだろうけれどPdMとしてはどうするの??

誰も教えてくれないネガティブメンバーマネジメント

さぶたいとる:サーヴァントリーダーシップの限界

ネガティブメンバーとは

今回のネガティブメンバーとは「愚痴を言う」、「怒る」など、恒常的にネガティブな表現を周りにする人のこととします。

成果が出ていない。というのは今回は対象外です。
育成コースに移すなりしましょう。

ネガティブメンバーの思考、行動一例

  • 評価に不満
  • チームの判断に不満
  • スケジュールに不満
  • 不満を喋りつづける
  • 納得した。風で納得していない
  • 周りの失敗を認めない
  • 周りの状況を鑑みない
  • 周りを手伝わない
  • 代替の提案をしない、聞き入れない
  • まじつらいわー、俺一番頑張ってるわー

想定する聞き手

ネガティブなメンバーをマネジメントしている。
ネガティブなメンバーのマネジメントを今後は避けたい方。
マネージャー職に向けて今後の心構えをしておきたい方。

はじめに

マネージャーであるならば、第一に、環境に対して文化づくりや評価、メンバーに対して育成やメンタリングなどを行い、ネガティブなメンバーを産まない土壌づくりをすべきだと思います。

最初にまとめ

ネガティブメンバーはマネジメントすべきではない、です。
多様性は認めつつも”合わない”と思うメンバーはチームへ入れない、早くに外すべきです。
そして、気の合うメンバーでチームを構成すべきです。
それは、ネガティブメンバーにとっても新たな活躍の場所に所属するキッカケにも繋がります。

続きを読む