scrummasudar.hatenablog.com
まとめてくださって多謝。
RSGTは知識だけじゃなくて、衝動みたいなのも激しく得られる。
そして、それがわりと重要。
本当に必要なのは行動して、知識を経験に転化させること。*1
自分が組織に戻って、展開はすることもするんだけれどそれじゃたりんのだよ、それじゃあ。
2016年から?参加、今年3回目だったかな。
そして、全て良い記憶。
RSGTは、今のフェーズの自分に一番多くの価値がある勉強会だなと。
それから、ネットワーキングというか懇親会というか、例年よりフリーにお話させてもらえた。
Twitterでもお話させてもらったし、ありがたみ高い。
前職の人にもオススメしたら来てくれていたけれど、どうだったんだろ。
感想を聞いてみたい。
凄い大事な論点 https://t.co/TfPQ3bYuNa
— magnoliak (@magnolia_k_) January 8, 2019
magnoliakさんに｢凄いね。｣といわれた気がしたので興奮して書きなぐり。
｢アジャイルって良いよ!｣*1みたいなこと言われるけれど、合意を持って進められるから成功している"ように見えている"だけであって、実のところ、うまくいってないんじゃない??みたいなことをたまに思ったりするんです。*2
というのは、PO的には、いつだって開発速度をあげてもらいたいわけですよ。
もっというと早くリリース、納品して、使われたい、売上だしたい。わけですよね。
でも、開発期間は短くならないんです。
スクラムマスターと現場的には物理的制約があるのです。
だから、無理なものは出さないし、そもそも出せない。頑張ることは出来たとしても、だ。
POが何を思っているかわからないですけれど、だいたい最初に思うのは｢もっと短く｣です。変な話、当初の期待を満たしていようがいまいが。｢もっと短く｣みたいなことを言うわけですよ。*3｢もっと｣って何?って思うよね。｢じゃあストーリーのサイズ調整しましょう｣みたいな交渉に入っていくわけですけれども。*4
でも、合意形成できないと、だいたい｢スクラムマスターガー｣｢開発チームガー｣みたいな感じになって変な｢下げ｣が入ったりするんですけれども。*5
制約がある中でも期待する結果を導き出すために*6、現実を見てどうすべきかを考えなきゃいけないんだけれども、そこには信頼関係みたいなものが無いとそれもうまくいかないんだよね。でいうと、プロジェクトの成否って立ち上がりの時でも見えたりするんだよね。とか思う。
アジャイルだろうがなんだろうがプロジェクトの成否には、良い人があつまって良い環境で良いモチベーションで頑張れるのが大事なんじゃないか?*7
その方法の1つとしてアジャイルがあるのだろう。
でも、もし、モノづくりを｢早い安い美味い｣で作りたいなら、技術力を高められる環境を開発進捗とは別に管理しないといけないんだろうね。時間はかかるけれども。
プロセスも大事だけれども人も大事。と思うわけです。
そんな感じで明日からRSGT2019が始まります。自分も参加します。楽しみ。*8
2019.scrumgatheringtokyo.org
そして期待を変な形で裏切られた組織は、過去の慣例にならった方法で開発を続けるんでしょう。
｢さよなら2018年、ようこそ2019年!｣
まだちょっと早いか。
なんかさー。開発をしたこと無い組織がシステム開発に手を出すとお金だけ使われれて完成しない。みたいなことあるあるなんだろうなー。とかポツリと思った。
— ろずにゃっく (@i47_rozary) December 26, 2018
非エンジニアの方から見ると*1、お金をお支払いして依頼したエンジニアだったら｢お願いしたものを作ってくれるだろう。｣という認識が一般的にはあると思う。
そして、面接なんかで｢○○を作ってきました。｣｢○○に携わってました。｣みたいな話で入社。
｢アレを作って欲しい。｣などと作業に入ってもらうけれど、仕様だって最初から詰めきれているものでもないし、企画側とエンジニアが話し合いながら1つ1つ作っていったりする場面もままあったりして。
企画側も企画側で、仕様の決定に悩んだりして、悩むくらいなら決めて良いか悪いか判断すればいいものを、開発日数を食いつぶしていたりするもんで。*2
でも、なんやかんや、言ったものと違うものでも完成したのならば未だ良いんですよね。
何にしたって良ければ成功だし、悪ければ失敗した。といって次にいけるから。
そんな開発の現場にいるのが、完成させる気概がないエンジニアだったりすると…。
出てきた仕様に対してプログラミングして、仕様が不足していれば質問して、回答が返ってくるまで待ってたり*3して…進んだり戻ったり、戻ったり進んだり、見た目は違うんだろうけれど、当初と本質的には変わらないプロダクトが横たわってたりする。*4
とはいえ一応は業務しているわけで給与なりが入ってくるから、当人にはさして問題ないんだよね。
｢リリースできない｣なんて言っても。
言われたことを｢やりました、やったんですよ必死に!その結果がこれなんですよ!!｣*5なんてのたまったりする。もちろん指示や依頼が穴ばっかな場合もあるんだろうけれど、作業に責任は持ってても完成に責任持ってなかったりするからまぁそうだよね。
じゃあ、完成させる気概を持っているようなエンジニアだったら?
改善提案し、一つ一つ完成に導いてくれる。*6
にしても失敗することはあるけれど、少なくとも期待通りの挑戦はしていると思う。
既に気概を持っているエンジニアがいるのであれば、手数として数名*7を招き入れることもありだろうけれど、可能なら控えたほうがいい。損失のリスクを減らせる。
｢戦いは気概だよ兄貴｣
続きの話でもないけれど、完璧な開発チームなんてそうそうないと思う。
どんなに優れたチームでも、まだまだ非力なチームでも自分たちの持っているリソース(時間、お金、能力など)では足りないプロダクトの完成に向かって開発作業をしている。
完成までの距離もピンきり。
手が届くような距離にあったり、霞むようなほど先にあったり。
そして、霞むような先にあるようなプロダクトの場合は、落ち着いて今の状況を分析して目標までの道のりを考える。
たとえ、時間やお金を費やす必要があっても知ることが大切。
それで命とられるわけでもないでしょ?
でも、分析したときにどうにもならない時もある、だったら諦めることも必要。
プロダクトが完成しなくたって生きていけるし、また別のプロダクトをやり直せばいい。
やり直すのも大変だけれど。*8
まぁそうならないようにする為には｢人なんだろうなー｣って思う。
学生の頃に教授に言われたことを今も覚えてる。
｢負荷かけないと脳みそくさるよ。｣*9
だから｢全然平気｣というよりも｢ちょっと大変だな。｣って思うことに常々取り組むようにしている。
そして、そんな感じでプロダクトの完成に向けて一緒に挑戦してくれる人の集まったチームワークの面白さったらないね。
そろそろ2018年も終わるけれど1年のふりかえりというものではなく、ここ最近感じたことを徒然とPdM的、EM的に感じたことを吐露してみる。
同じ機能を持ったプロダクトだったとしても、使われるものにもなれば使われないものにもなる。
｢何を作るか｣、｢どう作るか｣も大切だけれど誰にどう届けるかを考える。
方法は、プレゼン?UI?CM?はたまた別の方法?
その人たちにどう伝えれば使ってもらえるのか。
対象や届け方によってプロダクトの魅せ方、作り方も変えよう。
ペルソナ、ユーザーストーリー、カスタマージャーニーマップ、ジョブ理論があったとして、
便利だったり楽しい機能があったとして、
最新の技術、管理しやすい技術で作ったとして、誰にどう届ける?
期待通りに認識してもらわなければ使われない。
それでも、うまくいかなかったりするんだけれどね。
*1
何も無しに闇雲に開発作業をしてはいけない。
プロダクトに自信があったとしても、正しい方向を向いているのかは結果が出るまでわからない。
開発した機能が期待通りの結果であるのか、自分たちの思考を調整しながら成功の再現性を高めていく。
プロダクトの評価が良いものであれば、長い開発においても、
チーム内ではモチベーションが保たれるし、チーム外からは期待を得ることも出来る。
*2
*3
"悩む"ことと"考える"ことは違う。
"悩む"は、あーだこーだ、苦しむこと。
"考える"は、現状と目的に対して解決の手段を導きだすこと。
"悩む"を"考える"に変えるには、整理すること。
整理とは、｢現状を把握｣し｢何をすべきか｣を考え、その間にどんな問題があるか一つ一つ洗い出すこと。
そして、その解決手段を出していく。
そうすれば、"悩む"は"考える"に変わる。
うまく出来ていないと思うなら、気分転換するでもいいし、周りの人に聞くでもよい。
なにごとも焦らないこと。
また、悩んでいるくらいであれば何か試してみよう。
失敗したら何故失敗したのか振り返り、またやってみればいい。
やらないで何もできなかったよりも、やって失敗したほうが同じ轍を踏まないようにする分マシな自分になっている。
今、解決できなくっても、いつか解決出来るときがくるかもしれない。
くくれないなら、早々に止めるべき。
何のためにやっているのか。わからないなら考える。
腹のくくれないものやってても、人のせいにしかならない、ふりかえれない。
働く上で、なにを得たいのか、今一度考えてもらいたいなと思ってる。
肩書?お金?査定評価?働きやすい環境?一緒に働くメンバー?または自分の能力やキャリア?
取り繕うことなく、かつロジカルに考えてもらいたい。
よくあるなー。と感じるのが、エンジニアやりたいです、マネージャーやりたいです、PMやりたいです。
開発やりたいです、人をまとめたいです、プロダクト作りたいです。
けど｢どうしたら出来るようになりますか?｣｢何をやったらそうなれるんですか?｣｢評価されるんですか?｣と自分の答えや仮説を持たずに疑問だけを持っていたりする場合。
話をしていくと、本質的にはエンジニアがやりたいわけではなかったりする。*4
また、エンジニアとして続けられないからマネージャーをやりたいと言っていたりする。
けど、本当にその理由でエンジニア続けられるの?マネージャー続けられるの?PM続けられるの?
そして、続けられないと、得られるものも得られないよ?
まぁ何やるにしても、上手くいくことも下手こくこともあったりして、思わずハマったりするから。
好きなようにやったらいいし、挑戦してもらいたい。
何があっても｢それでも!!｣っていうならそれでいいと思う。*5
あまり周りの評価を気にして何やったら良いか考えるより、｢きっとこれだろ｣と思って挑戦して成功なり失敗なりを経験する方が有益だと思うけれどね。*6
自分じゃない何かの物差しで生きてるとその物差しの中でしか生きていけなくなるよ。
了
もしくは、エンジニアリングマネジメントの価値を前向きに植えたい。
絶望しているわけでもないし、希望も持っているし、その通りに実行もしている。
けれど結局は、
ビジネス的要求、
必要にかられるような状況、
辞令、
コマンドアンドコントロール、
といったような、自分の希望からではなく、外界からの力によって生まれるエンジニアかつマネージャーが多いのではないのか?
生存本能かなにか、必要にかられてEMになっている、だが今は幸せだしこれからもそうだろう。
しかし、その発現はちょっと寂しいと思っている。
最初は後ろ向きだけれど、やがて前向きにな感じになるともいうのですかね。
*1
以下、エンジニアマネージャーをEMとする。
そして、EMってざっくり説明。
EM=人、組織などなど特化型、VPoE的な人。
テックリード=開発、技術力などなど特化型。設計から実装、テストが凄い的な人。
自分の思考の発散で駄文なんで、余程暇な時以外はそっ閉じしてください。
世の中には様々な"視点"があると思っているので意見があったら優しく教えてください。
勉強しますから、どうか後生です。
自分の性質として、相手のものさしで動くことが苦手、コントロールされるのが苦手。
納得のいかない管理は精神的衛生上受け入れられない。そしてそういうことがまま起きていた。
それは一緒に働くエンジニア*2もいやだろうし、
それは、幸せな現場ではないわけで愛されプロダクトは生まれづらい(生まれないとは言っていない。)だろう。
そんな生き方は自分はいやだから。ならば自分が自分をチームをマネジメントしよう。
というのが成り立ち。*3
逆に、理想のエンジニアマネージャーが生まれる動機としては、以下な感じなんですよ。
｢愛されプロダクトに携わるエンジニアマネージャーかっこいい!すげー!パフォーマンスすごい。
エンジニアのメンバーもすごいけれど、そのメンバーをコラボレーションさせてるのすごい!
プログラミングの開発力も素晴らしいけれど、自分は凄い人たちに頑張ってもらえる凄い環境を作ることがやりたい!!｣
みたいなことじゃない?って思うんですよ!!*4
けれども、そういう人は現実には多くはなさそうだなと思っているわけです。
で、エンジニアリングマネージャーになろうと思うきっかけの頻度を考えてみると、
EMになるきっかけ=組織の数 x ビジネス機会 x (前向き要因 + 後ろ向き要因)とかかなって思って。
さらにEMとして続けていく人数は、EM発生頻度 x (育成環境 + EMに前向き) みたいになるかなって思うわけです。
そうなると、社会の需要に対してEMは絶対数として足りない状態が続いていくみたいなことを考えて、
それって人類にとってきっと不幸な状況が横たわっているなーとか思うわけです。
少しでもEM誕生の可能性を高めるためにも、
どんなエンジニアに対しても研修期間などにはEMの基本的な知識を備えてもらえるよう時間をとるようにしていたりする。*5
けれども、それじゃあトップラインがなかなかあがりづらい。
EMのクラスタに来る人は、EMに"なっちゃった"系の人が多いように思う。
現在エンジニアで｢EMになってみようかなー。｣みたいな人はそんなに見かけない。
そんな人はそういった場所にはこない、クラスタへの参加のハードルとかなんやかんやで。
ひとまず行ってみるか!役に立つかもしれないし、みたいな興味あるモチベーションで参加してくれる人が少ない。
時間も有限ですしね。*6
それでも、現場でツラミを抱えている人や組織に届けたいのですよ!!｢EMっていいよ!!｣みたいなことを!
なので、EM以外の勉強会やコミュニティで、そんな話を今後も続けていきます。
そして、いつか勝手に植えさせてもらったその種が自ら芽吹くときをねがってやまないのですよ!!
あ、でも自分の話って課題解決スタートみたいなところあるな、考え直してみよう。
エンジニアリングマネジメントだけじゃなくて、プロジェクトマネジメントとかプロダクトマネジメントについても同様のことを考えている。
これは
こちらのアドベントカレンダーの9日目の記事です。*1
採用に関してここ数年、新しい動きをしていない。
何が正しいとか、何が間違っているかではないと思うけれど、なんだか自分が凝り固まっているんじゃ?という思いと、同様に考えている方がいたら一緒に考えられたらな。と思い書き出してみる。
皆さん、採用どうしているのでしょうか。
自分は社員採用する前に一緒に働くような｢お試し採用｣をちょっと試したいなと考えています。
ざっくりこういうような組織での採用についてのお話。
会社全体:50人〜200人
エンジニア:10〜50人
走っているプロジェクト:大小合わせて3~10
Web寄りのプロダクト開発。
自社開発もしくは、受託も無くはないが協業という形である程度の制約、要求がある中での開発。
toC事業が主流。
面接なのに1on1や進路相談みたいになることがある…。
これって｢不採用です。｣って、その場で言っているようなものだよね…。
事業に直結しないまでも社会的に活用される技術や活動を考えて行動している人を採用するようにしている。
逆の場合は、時間もお金もただ消費するだけだと思っている。
やりたいことがある人は、そのやりたいことを話し合えば必要なことを自発的に考えて行動してくれる。
組織的に定義づけられた自分の役割があったとしても、それを越えて行動してくれる。*2
｢開発やりたいです。｣みたいな、開発で得られることが出てこない人は、それ以外はあまり興味がなかったりする。
そうなると、事業だったりチームだったりと目的意識があっていないから*3組織的に動きづらく、成果としても良い結果が出づらくなってしまう。
面接のときにこういう発言をされた場合、念の為、突っ込んで質問をしている。
｢どんな開発をやりたいのか。｣
｢開発の結果なにが得られるのか。｣
｢なんのために開発をするのか。｣
ただし｢開発やりたいです。｣みたいな人も、手数が欲しい時や組織の方向性として特化した技術力が必要になる場合には必要な人であると考えてもいる。
手数の話は言うまでもないが、技術のアウトプットの質は、インプットを大量にした結果だと思う。
高度な質を求めるには、その技術に常に探求している必要があると思う。
しかし、常に高度な質を求めるか?というと違うことがわりかし多いと思っている。
いや、実のところ手数だとしても管理コストがかかってきたりするから止めたほうがいいと思っているんだけれどね。
正社員は会社を組織するメンバーになる人を採用する。
突発的なプロダクトに起因する理由などでは採用しない。
会社の事業戦略(明確なものが無かったとしても短期的にでも想定しうる計画に基づいたもの。)に合わせて人員計画をたてて採用を行う。
チームの目標は何か、その目標はいつ達成させるのか。
そのために必要なパフォーマンスは?そして、どんな人で何人構成にするのか。
誰をマネージャーにすえるのか、それをチームごとに時系列で考える。
採用から話はずれるが、プロダクトが無くなった場合のことも念の為考慮しておくこともある。
これは本当に動きづらい。
会社全体でもプロダクトのチームでも受け入れの準備も出来ていないのに人を入れることと、活動の方向性が散らばらないように所属人数と新人の方の人数比が3:2みたいになるような受け入れ方は避けたほういいと思っている。*4
突発的だったり(突発的なのは極力避けたいんですけれどね。)、準備が出来ていないがどうしても助けが必要、特定の技術力が必要という場合だけ、派遣の方や外注の方にお願いするように心がけている。(心がけている。)
契約の分だけ助けてもらってその分しっかりお支払いをする。
主にエンジニアだが、ポジションに寄っては営業の方や事業部?の方などにも面接してもらう。
エンジニアは入る想定のチームに拘らず、マネージャーだったりメンバーだったり、チームが解散したとしても引き続きその組織で働けるかどうかを意識している。
何度も足を運んでいただくのも申し訳ないとは思いつつも、間違いに気づくなら早いほうがいいとそのようにしている。
なので時には、四次、五次みたいな場合もでてくる。とはいえ、無駄に回数は重ね無いように、面接の順番を組んでいる。
組織によっては、人事の方が採用を決めたりする所もありますよね。
組織構造も人事の方が考えていたりする場合も。
エンジニアに限らずクリエイティブな業務の場合、人事の方が決めるのには懐疑的です。
｢開発という手段で活躍はしたいですけれど、それによって得られる結果はこのプロダクトじゃないんです。｣とか｢本当は、開発もしたいわけじゃない。｣みたいな人が入って来たときの不幸ったらありゃしない。
もしそういう組織があったとしたら、人事の人に声をかけて一緒に活動するようにするのが組織としても採用される側にとっても良いだろう。
経験年数が長いのに技術力無い方は厳しいけれども、現状の技術的スキルよりはどういう積み方をしているかを重要視している。
技術的移ろいも勿論あるけれども、事業的変化も多分にあるので、変化に対応する力というところが大切だと考えてのこと。
こういう時に｢ネットを調べてます｣"だけ"の人は苦手。大して知識吸収もしてなければアウトプットもしていないことが多い。
ネットの場合はピンポイントで必要な知識しか調べられないので知識の広さ深さが足りないと思う。*5
本や勉強会などに参加したり、自分でプロダクトを作たりして少しでも見てもらえているような人がよい。
少し話はそれるが、01の経験やリリース経験、リリース後の運用経験、クローズ経験なども頼もしいスキルだと思う。
この先、対応してくれるか、成長してくれるか。が大切だと思っている。
とはいえ、見るっちゃみるけれどね(汗笑
メンバー採用の場合
一次面接:エンジニアマネージャー+メンバー
二次面接:エンジニアマネージャー+メンバー
三次面接:役員
マネージャー採用の場合は
一次面接:エンジニアマネージャー+メンバー
二次面接:エンジニアマネージャー or メンバー + 非エンジニアマネージャー
三次面接:役員
とはいえ形に拘らず、互いに納得できるよう繰り返し情報交換をする。
回数が多いと他社に負ける。みたいな場合は、
そもそもマッチングが他社よりスムーズにいかなかったのだから正しい結果だと思う。
長くなるから省略…。
でも、一番はリファーラルだと思う。
採用するにせよ、お断りするにせよ、お互いの人生が大きく変わるタイミング。
どちらにせよ自分もよい人生を送りたいし、相手の方にも良い人生を送ってほしい。
同じ方向を向いているなら一緒に頑張れるし、
違う方向を向いていたとしても｢またどこかで｣と言い合える。
そんな採用活動を心がけたいものだと思っている。
pm(perl mongers)なのに、perlの話が｢チョトだけな｣吉祥寺pm(以下、キチピー)に行ってまいりました。
LTで参加したことはあったのですが、今日はゆったりトークで参加させていただきました。
kichijojipm.connpass.com
kichijojipm.hatenablog.com
＊スライドやグラレコなどは上記にありますゆえ、そちらを参照するようにしましょう。
大衆ビストロ 煮ジル 吉祥寺店 - 吉祥寺/バル・バール [食べログ]
