YAPC2019に行ってきたん!!

感想

Perl成分多めだった!!

Plack/PSGI」のトークは今でも鮮烈に記憶に残っているな〜。
あの時半分くらい何言ってるかわからなかったけれど、あの衝撃があったからこそ、エンジニアとしてもモチベーションがめちゃくちゃ高まって、今では自称ちょっとできるエンジニアとして生きて行けてる。
YAPCなかったらオレ死んでたぜ!!*1

っていうのを、songmuさんとかtokuhiromさんとかyoku0825さんとかの話聞いてて、ふと。

生じた悩み*2

現状、課題という課題を感じず、課題があっても「こう対処すればいいよね。」みたいな感じになっていてプレッシャーを感じていない。
ちょっとした手持ち無沙汰感がある。

「挑戦は良いこと、失敗するのを恐れない。」
「試行錯誤していい、直せばいい。」ということに甘えている自分がいるんだろうな。
と思っている。*3

エンジニアもざっと10年、マネジメントもざっと10年くらいやってみて、この先何をやるんだろう自分は。的な悩み。
適度にプレッシャーをかけたいし、もっと何かをって思うんだけれど。
その何かがわからない。

ちょっと言葉変えると課題は目標だったりして。
目標に至るまでの方法をあれこれ仕入れてより良くするっていうのも良いんだけれど、日頃やっているから何か実感がわかない。

眼の前にやることがあるから今はそれに集中しているし不満は無いけれど、なんだろね。

まぁ焦ってもしょうがないけれど、この辺すっきりしないと自分の成長とか仕事が終わるんだろうなー。
と危機感も感じながらも前向きに思ってみた。

YAPCラーメン

f:id:i47_rozray:20190126211005j:plain
別のお店に行こうとしたんですけれど、機器修理のためにお休み。
そしてこちらのラーメンにありつく。
量と味も懇親会の後に手頃で優しい。
食べながら、ごま、胡椒、ニンニクと追加して完食。
博多ラーメンと認識せずに入ったので麺硬めのオーダーができなかったのは残念だった。
是非今度は粉落としを頼みたい。

懇親会

いろいろな人とお話。
昔一緒に働いた人とか運営の人とか、
それから、知らない人と話してみようと声掛けさせていただいたり。*4

その他、参加したトーク

  • Perl to Go』xaicron さん

またGo書く機会があったら見直したい。

  • 『Garuda:汎用コネクティビティ プラットフォームPerlをサイエンスの世界につなぐ』

データの変換が多く必要な現場にはいいのだろうなー。

  • 『20歳の僕が経験したPerlエンジニアへの道』

TMTOWTDIが考える力を養う。ってのはよいよね。そしてまた一人「高専生さすが。」な感じになる。

宥和政策w

  • 『Wazuhを利用した 大統一サーバ監査基盤』山下和彦さん

Wazuh今度試す。vulsよりも便利そう

  • 『2つのDXと技術的負債-YAPC Tokyo 2019』広木大地さん

DX、開発者体験と企業のデジタル化(デジタル変革)、そして左右に並んで表示されてるの見やすい。

  • Perlでも分散トレーシングしたい! - AWS::XRayによる解析とその実装』fujiwara さん

SDKなんて飾りです。偉い人にはそれがわからんのです

次回は京都らしい!楽しみ!!

海外スピーカーさんにも喜ばれそう。

*1:つか、あれから10年経ってるんだな!!

*2:YAPCとは離れた話

*3:スクラムは麻薬www

*4:自分頑張った!!

宇宙世紀37年の節目に、ナラティブとはよく言ったものだ

37年というのは今日自分がちょうど誕生日で言いたかっただけ許して。

本題『<第6回>ガンダムNTの制作過程を語ろう』に行ってきた。
gundam-nt.net

はじめに

ナラティブを見るのは多分5回目?
今日も面白かった!!
最初リタ好きだったはずが、いつの間にかミシェル好きになった。
ゾルタンはどんどんギャグだな。って。
そしてバナージのおさえのセリフがまたカッコいい
「遠いな…それでも、それでもいつか。」
ミネバのツッケンドンがまた笑うんですよね。
ミシェル姉とミシェルの会話まじ切ない。
リタの振り返った顔が哀愁。
ちなみに好きなセリフはゾルタンの「キンピカァアア!!」です。
他にもゾルタンの飛んだ感じのセリフ好き。「撃っちゃうんんだなこれが!!」とか?

という感じで本編も面白く見させてもらって、今回トークショーがまた良かったので記録のために覚えている限り書き出し。
正誤確認していないので間違っていることもあるかもしれない。

エンジニアリングと関係ないけれど、記憶の定着のためにも書き起こし&投下!!

トークショー最初にまとめ

手書きの色気最高!!

ユニコーンの時も思ったけれど、ストーリーも面白いしMSはカッコいいしそれだけでもとても価値あるんだけれど。
けどね、映像だけでもめっちゃ見応えあって何回も見れるし見たいんだよね。
ユニコーンの日の冒頭のクシャトリヤスタークジェガンの格闘なんかマジ目に焼き付いているもの。
マジ、アート。

以下メモ

挨拶は、トークショー用に吉沢監督と司会のクゼさん?とパワポをじっくり用意と。

*1
それからゾルタンの3分宇宙世紀twitterのトレンド入りした話からスタート。
www.youtube.com

ナラティブガンダムの作り方、ということで映像制作の流れの話を

カット番号272を題材にして始まりました。

youtubeで冒頭23分が公開されていますが、こちらだと13:40の所からの4秒間のカットだと思います。
www.youtube.com

福井氏がシナリオを書いて、吉沢監督が絵コンテを出す。

タイムシート4秒+15コマ?で、該当時間にどのコマを当てるか管理している。
*2

フェネクスの登場シーンなので左右に激しく動かしている。

のち、ナラティブ登場でフェネクスを抑えていくことを表現したカット。

(今作は?)空間表現を特に大事にしている。

宇宙空間からフェネクス、ナラティブを移して、コックピットからのヨナが出てくることで"空間"を演出をしている。

セルはAを一番下にして重ねていく。

このカットは、
BCがフェネクスと残光(かな?)
Dがナラティブ体
Eがナラティブ顔、顔が動くからセルは別
Hがヨナ
Iがヨナ口、セリフで動くから

物理セルだとセルを重ねると、重ねたセルに影が出来たり、重ねたセルの色が変わってきてしまうことがあったが、デジタルだと、いくら重ねても大丈夫だからA~Zまで重ねても大丈夫!

大変だけれど!
撮出しは、物理だと何枚も重ねられることになって昔は肉体労働バリだった。
(福井さんが、地面から腰くらいまで積まれているような所作をしていた)

ヨナがカットインしてくるけれど、この演出は富野さんの功罪。

演出としては秀逸。1本のアニメだとカット数の制限があるけれど、それをクリアできるが描く量は増えるから大変。
ちなみにカットインの三角形の尖ったところは、その人がいるところ。つまりコクピットを指している。
というのは意図した演出だったりする。
そこにいることがわかるってね。*3

コクピット、椅子はCG。

操縦桿は動くから手書き。
椅子は動いているようで固定している、動いている上で手書きで描くのはコスパ重め。

コクピット内を描くのが大変だから、簡単にするために全天周囲モニターにしたのに、今じゃCG工程を挟まなければいけなくなったので作業が増えた。

それから、宇宙だけじゃなくてコロニー内なんかは特に、背景として描かなければいけなくてとても大変。
*4
またユニコーンからコクピット内の映像みたいなのもついてより大変。
あれは福井さんのオーダーではない。*5

フェネクスが逃げて?いくカットのコロニーの残骸みたいなのは、1枚の絵をコピペして長くして流して高速移動を表現している。

効率化効率化。

こんな感じで激しいカットが1500ほど?

作画監督さんお一人で300とか600とか?

色指定「どんだけ色作ればいいのよ!」って怒られる。

ホント多い。

ユニコーンのブライトさんと逆シャアのブライトさんの白目はありやなしやの話題。

つぶらな瞳ということで!!
*6

フェネクスの残光は全て手書き。*7

CGでも出来るが、画一的??になってしまう。
デ○○○ーとか宇宙○○とかとは違うぜ。サンライズピカイチ!!

手間がかかっているけれどここまでやらなければガンダムじゃない!とは福井氏のお言葉。

*8

お土産は今回のカットで使われた原画の2点!!

本日限定?のようです。

f:id:i47_rozray:20190116014638j:plainf:id:i47_rozray:20190116014646j:plain

こういったときに配られる原画は、ちょいと綺麗にしてお渡ししている。
実際の作業の原画では指示がいろいろ書き込まれている。

ヨナのバイザー有無の指示とか地味に効いてくる。
バイザーの有無は原画だけだと分かりづらい、肌の色が変わってくるのでそういうのを書き込んでいたりする。

「だからロングランヒットしちゃうんだなこれが!」

ということで、来週もよろしくおねがいします!

来週もトークショーあるよ!!発売中だよ!!

www.smt-cinema.com

*1:見やすかった!!

*2:ナラティブは1秒何コマなんですかね24?30?

*3:トムラ!

*4:今回めっちゃ人動いてますもんね。逃げたり助けたりしている人が凄いと思う。

*5:めっちゃカッコいいけれどね。そういえばシナンジュシナンジュ・スタインのUI?一緒な感じしますね、精査してみたわけじゃないですが。

*6:ユニコーンのブライトさんの目は逞しさ感じます!

*7:ホント馬鹿なのかな?って思うッ!

*8:まじ情熱だよなー。

Regional Scrum Gathering® Tokyo 2019の自分メモ

公式はこちら

2019.scrumgatheringtokyo.org

スライドはこちら

scrummasudar.hatenablog.com
まとめてくださって多謝。

最初にまとめ

RSGTは知識だけじゃなくて、衝動みたいなのも激しく得られる。
そして、それがわりと重要。
本当に必要なのは行動して、知識を経験に転化させること。*1

自分が組織に戻って、展開はすることもするんだけれどそれじゃたりんのだよ、それじゃあ。

f:id:i47_rozray:20190114231009j:plain
f:id:i47_rozray:20190114231018j:plain

今回の自分の気づきキーワード

  • 計測
  • 素早く検証
  • 実験

参加したセッションのテーマが違えど、この辺のキーワードが耳についた。
*2

個人的ふりかえり

2016年から?参加、今年3回目だったかな。
そして、全て良い記憶。
RSGTは、今のフェーズの自分に一番多くの価値がある勉強会だなと。

それから、ネットワーキングというか懇親会というか、例年よりフリーにお話させてもらえた。
Twitterでもお話させてもらったし、ありがたみ高い。

前職の人にもオススメしたら来てくれていたけれど、どうだったんだろ。
感想を聞いてみたい。

*1:二の足踏んでる人は、騙されたと思って参加した方がいいよ。で、本当に騙されたと感じたら、あたくしに言ってください。

*2:「めぐらぶ」は一旦置いておく。

続きを読む

アジャイルかどうかはともかく。オレはプロダクトリリースを"今より"早くしたいだけ。

magnoliakさんに「凄いね。」といわれた気がしたので興奮して書きなぐり。

アジャイルって良いよ!」*1みたいなこと言われるけれど、合意を持って進められるから成功している"ように見えている"だけであって、実のところ、うまくいってないんじゃない??みたいなことをたまに思ったりするんです。*2

というのは、PO的には、いつだって開発速度をあげてもらいたいわけですよ。
もっというと早くリリース、納品して、使われたい、売上だしたい。わけですよね。

でも、開発期間は短くならないんです。
スクラムマスターと現場的には物理的制約があるのです。
だから、無理なものは出さないし、そもそも出せない。頑張ることは出来たとしても、だ。

POが何を思っているかわからないですけれど、だいたい最初に思うのは「もっと短く」です。変な話、当初の期待を満たしていようがいまいが。「もっと短く」みたいなことを言うわけですよ。*3「もっと」って何?って思うよね。「じゃあストーリーのサイズ調整しましょう」みたいな交渉に入っていくわけですけれども。*4
でも、合意形成できないと、だいたい「スクラムマスターガー」「開発チームガー」みたいな感じになって変な「下げ」が入ったりするんですけれども。*5

制約がある中でも期待する結果を導き出すために*6、現実を見てどうすべきかを考えなきゃいけないんだけれども、そこには信頼関係みたいなものが無いとそれもうまくいかないんだよね。でいうと、プロジェクトの成否って立ち上がりの時でも見えたりするんだよね。とか思う。

まとめ

アジャイルだろうがなんだろうがプロジェクトの成否には、良い人があつまって良い環境で良いモチベーションで頑張れるのが大事なんじゃないか?*7
その方法の1つとしてアジャイルがあるのだろう。
でも、もし、モノづくりを「早い安い美味い」で作りたいなら、技術力を高められる環境を開発進捗とは別に管理しないといけないんだろうね。時間はかかるけれども。
プロセスも大事だけれども人も大事。と思うわけです。

そんな感じで明日からRSGT2019が始まります。自分も参加します。楽しみ。*8
2019.scrumgatheringtokyo.org

おまけ2

そして期待を変な形で裏切られた組織は、過去の慣例にならった方法で開発を続けるんでしょう。

おまけ3

変なプロジェクトに関わらない為のアジャイルな知識っていう観点もあったりすると思うので、アジャイルは面白かったりするんですけれど。

*1:アジャイルにもいろいろあるけれどまぁ広く捉えてください…。

*2:アジャイルは確かにコスパよく開発を回してくれるという統計データもどっかにあったはず…。

*3:「え!そんなに早いの!?」って言ってくれる人もいますけどね。

*4:ココらへんがアジャイルの意義だったりすると思います。

*5:実際、下げな場合もあるのでしょうが。

*6:「期待をコントロールする」という言葉もありますね。

*7:合意がとれていると、自然とそうなってくるとこあるよね?

*8:良い繋ぎですね!

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

「さよなら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:自分だって気づきがないだけで、知っておいた方がいいこと沢山あるだろう。