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

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

これは

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:下手したら間違っていることもある。