valid,invalid

関心を持てる事柄について

誰がジュニアを育てるのか -出題編-

過熱する採用市場の盛り上がりにあわせて感じたことについて言語化を試みているが未だ納得解が得られずにいる。書きかけの Scrapbox は随時更新していくとして、現時点での dump をとっておく。

誰がジュニアを育てるのか - ohbarye

主にソフトウェアエンジニア採用の文脈で「誰がジュニアを育てるのか」ということについて。

f:id:ohbarye:20180929013900p:plain *1

「優秀な人間だけを採る」という採用戦略

著名テック企業が自社の採用戦略について語った本が出版されるたびに話題になる中で「優秀な人間だけを採る」というのが採用戦略として認知されるようになってきたのを感じる。Netflixの最強人事戦略Work Rules!あたりが代表的…かどうかは知らないがあくまで自分が読んだ中の代表。世には同じことを謳う書籍や記事がもっとたくさんあるかもしれない。

※「優秀」という言葉を定義するのは難しく、そしてまた常に相対的なものだが、わかりやすくするために「在職者と並べた時に上位50%に入るスキルを持つ人」はその企業にとって「優秀な人」としておく。

この採用戦略はいち企業としての成功を追い求めるうえで圧倒的に正しい*2。人材育成に投資する余裕のないスタートアップであれば尚更そうせざるを得ないというのは誰でも合点がいくところだと思う。

局所的な正しさ

正しい、とはいえ採用市場にて大多数の企業がこの戦略を選択すると、この定義において優秀でない人間を雇用する企業が減る。言い換えれば就職先がなくなる。この定義において優秀でない人間とは、新卒や第二新卒、またはキャリアチェンジして業界に参入するキャリアが浅いエンジニアなどだ。長いので"ジュニア"と呼称することにする*3

優秀であればキャリアに関係なく採用される、というのはわかる。だが「在職者と並べた時に上位50%に入るスキルを持つ」のはごく一握りで9割8分ぐらい*4のジュニアはあてはまらない。

彼/彼女らの就職先がなくならないにしても「優秀な人間だけを採る」戦略をとり、その恩恵を享受するような企業や環境では働けない。そこで起きるのは、優秀な同僚と一緒であれば成長したであろう人の芽が出ずに終わってしまうという問題*5や、優秀な同僚と働きたいのであれば相対的に劣るかもしれない環境の中で自ら成長して優秀にならなければいけないという問題だ。

スタートラインからビハインドしている者がこうした努力と転職を繰り返すことで初めて求めていた職場にたどり着くことはもちろん不可能ではない…不可能ではないが、厳しい。

誰がジュニアを育てるのか?

前置きが長かったものの、誰がジュニアを育てるのか?それが問題だ。

ジュニアの受け皿になる企業は教育コストを支払うだけ支払って彼/彼女が成長した折に"卒業"されてしまうのか。

教育コストを払いたくない企業が生む"ババ抜き"になってしまわないか。

さらに長期的に見ると、優秀だったエンジニアたちが定年を迎える頃には後輩が誰も育っていない、なんてことにはならないか。中途で問題に気づいて新たな解決策が出てくるか。

まだまだ勉強不足なので自分の観測範囲では納得解が得られていない。もしかすると歴史ある他業界や他職種では既に起こったことなのかもしれない。

引き続き考え続けていく。


「優秀な人間だけを採る」に乗らない

別の観点で、「優秀な人間だけを採る」戦略に乗らないことで得られるメリットも存在するという話。

ジュニアを採用することで一時的に平均的なレベルが低下するがそれを許容してでも得られるものはあるのかもしれない。それまで荒野だったオンボーディングが整備されたり、チームで技術力を向上させる仕組みを作る方向に向かったり、Engineering Manager や Tech Lead を志向する社員にメンターの機会を与えたり。

これらのことはジュニアを採らずともできるものではあるが、より強く必要性を認識させる手っ取り早い手段にはなりそう。


引用

以下、記憶にあって探せたものからの引用

Netflixの人事制度

経営陣が従業員のためにできる最善のことは、一緒に働く同僚にハイパフォーマーだけを採用することだと学んだ。これはテーブルサッカーの台を設置したり、無料で寿司を提供したり、莫大な契約ボーナスやストックオプションを与えたりするよりずっと優れた従業員特典だ。

Work Rules!

採用の質で妥協することは、間違いにほかならない。間違った採用は有毒だ。本人のパフォーマンスが損なわれるだけでなく、周囲のパフォーマンスとモラルと活力を堕落させる。


自分より優秀な人だけを採用する


10 人の新規採用者のうち 9 人が自分より優秀なら、採用はうまくいっている。


たとえば大学生を評価するなら、GPAの点数は考慮すべきかなり重要な要素だと思えるかもしれない。だが、日本からの応募者に関してはそうでもない。日本では大学への入学は主として全国的なテストの結果で決まる。そのため、高校生はそのテストで好成績をあげることに注力し、数年にわたって毎週 15 から 20 時間も塾に通うことが多い。しかし、いったん一流大学に入ってしまうと、成績をまったく気にしない。歴史的に、日本の大学生は塾での鬱々とした時間と「サラリーマン」(過去の日本に特有の年功序列と終身雇用を土台とするキャリアを示す用語)生活の単調さとの狭間で、遊びと自由という最後のあがきにふける。日本の大学の成績は採用データとしては実質的に意味がないが、どこの大学に通っていたかを知ることは、少なくとも新卒者の採用については役に立つ。

クックパッド

日雇い労働者だった赤髪エンジニアがクックパッド技術部長になるまでのストーリーより

その人が入ると、クックパッドのエンジニアの技術力の平均が上がるということを求めてます。


すごくわかりやすく技術力を数字で表わすと……いや、そんな単純じゃないのはわかっていますが、説明のために数字で表わすと、いまのエンジニアの平均値が5だとしますよね。

そこに「いまどうしても人が足りなくて・・・」と、4.5の人を入れる。すると平均は4.83。5と5と4.5。そこにもう一人5を入れても4.87。5に戻らないので、レベルが下がります。

*1:いらすとやより https://www.irasutoya.com/2015/03/blog-post_53.html

*2:なぜ正しいかは上述の本を読むと書いてある

*3:著名テック企業にもジュニアという肩書があるのは知っているがそれは業界全体で見たら優秀層なので例外的とする

*4:要出典

*5:その才覚を見抜くのも採用テクかもしれないが、在職者と並べた時に上位50%に入るスキルを持っていないから入れない、としておく

Engineering Manager Meetup #1 をやりました #em_meetup

Engineering Manager Meetup をやります - valid,invalidで宣言した通り Engineering Manager Meetup #1 をやりました。本記事では感想と振り返りを、イベント運営者と参加者の両視点から忘れないうちに記しておきたいと思います。

connpass.com

本記事の主な想定対象読者はイベントに参加されなかった方です。#em_meetup ハッシュタグ を目にして興味が湧いた方や、Engineering Manager Slack に入っているがイベントには来られなかった方々に""現場の様子""をお伝えするのが目的です。

(参加された方にとっては既知のことばかりかもしれませんが、イベントを追体験したり主催者の思考をのぞき見することで楽しめる可能性があります)

3行で要約すると

気づいたら6,000字以上も書きなぐっていたので要約しました。

  • Engineerng Manage(r|ment) に関心と情熱がある人は少なからずおり"需要"があるとわかった
  • 圧倒的当事者意識を持って参加してくださった皆さんが出会って"何か"が生まれた
  • 早速フィードバックを貰えて"情熱"が伝播したので第2回開催を決めた

Engineering Manager Meetup とは?

イベント開催の動機や趣旨については Engineering Manager Meetup をやります - valid,invalid をご参照ください。

当日のようす

当日のようすです。写真上の文字は各テーブルで話し合われていたテーマです。

f:id:ohbarye:20180926231722p:plain f:id:ohbarye:20180926231727p:plain f:id:ohbarye:20180926231733p:plain

OST形式の魔力

今回のイベントではゲストによるトークやプレゼンは抜きでOST(オープンスペーステクノロジー)形式でのセッションを2回行いました。

オープンスペースは「興味関心の拠り所は明確だが誰もその問題について正解や答えを知らない」chaotic な問題に向き合うのに適したディスカッション形式です。*1

オープンスペースとは、各自が喋りたいテーマを持ち寄り、その中からテーマと進行役(セッションオーナー)を選出し、各グループに分かれて自由に発表、議論、雑談などを行うイベント形式です。

セッションオーナーはあくまで進行役、その時間の枠で何をするかを決めるだけで、そのテーマについて必ずしも詳しい必要はありません。

https://www.meetup.com/ja-JP/GraphQL-Tokyo/events/251782724/ より

この形式を選んだ理由は以下です。

  • 「Engineering Manager」というロール自体が不明瞭であったり、付随する周辺課題についても唯一解がないものばかりなので、そんなテーマたちを話し合うために優れた形式だと考えた
  • 参加者同士が関心を持つ事柄について話し合い、共感したり意見を交わし合うことで横の繋がりを生みたかった
  • イベント全体でのインプット・アウトプットの総和を最大化したかった

振り返ってみてもこの形式を選んで良かったと思っていますが、OSTが成功するか否かは何よりも参加者の姿勢に依存するので、圧倒的当事者意識を持って参加してくれた皆さんに改めて感謝です。

オープンスペースのメリットをまとめると

  • 主体的であることにインセンティブがある
    • セッションオーナーになれば自分の聞きたいことが聞ける、話したいことが話せる
    • セッションオーナーだからといって問題に詳しい必要がない
    • 主体的になればなるほど多くを得ることができる
  • 参加者全員に主体的な参加を促すことができる(運営者視点)
    • 話を聞きに来ただけ、という人には向かない
  • プレゼン準備が必要なくて楽 ;-)(運営者視点)

参加した人にのみわかる熱気のようなライブ感にも似た良さがある一方、デメリットを挙げるとすれば

  • 未経験の方に良さが伝わりづらい
    • 参加者の中にはOST未経験の方も少なからずいたのですが、終了後には「この形式初めてやったけどいいですね」というフィードバックをいただきました
  • 発表資料が残るわけではないのでイベント終了後に拡散しづらい(運営者視点)
    • 皆さんの tweet や blog や口コミで広めていただくほかない
  • テーマがなかなか挙がらないこともあるので仕込みはあった方が安心(運営者視点)

という感じです。

いずれ劣らぬテーマたち

以下のテーマについてそれぞれのグループに分かれて30分ずつディスカッションをし、各グループ2分ずつ発表して共有する、という形で進めました。

  • 目標管理・評価制度
  • 『エンジニアリング組織論への招待』について広木さんと語る
  • Engineering manager とは何者
  • 1-on-1のやりかた
  • managerのキャリアパス
  • 採用・ブランディング
  • 給与
  • チームビルディング
  • Engineering Manager の魅力を伝えるには

@cobasparxxx さんの tweet にあるように、全てのテーマが魅力的で参加するグループを選ぶのに本当に、本当に悩みました。。

参加者の感想ツイートもセルフでトゥギャり、参加しなかったグループの雰囲気の一端を味わおうとしました。@dskst9 さんがアップロードしてくれたホワイトボードから"何か"が伝わるかもしれません。

togetter.com

イベント参加者として

「Engineering manager とは何者」→「給与」それぞれのセッションに参加しました。

Engineering manager とは何者

実に本質的な問いすぎて頭がクラクラするのですが、他社における定義や責任範囲を聞くことで改めて多義性・曖昧性があるなぁと実感しました。それでもぼんやりと共通項みたいなものが見えてきており、広木さんの tweet がその辺を絶妙に突いてくれていました。(ちなみに広木さんはこのテーブルにはいなかったw)

給与

インターネットに残せない話が出ました、それだけで大満足です。

書けることの中で興味深かったのは、給与という切り口一つから初めても色んな周辺の問題を議論できるんだな、ということでした。「Engineering Managerは給与を決定する"権限"を持つのか」「"採用"(オファー金額)にどう関わるか」「"評価"への納得感と給与への納得感は一致しない」「"1-on-1" で給与に関する本音を引き出す」などなど。

Engineering Manager の魅力を伝えるには

こちらのセッションには参加できなかったものの実に興味深いテーマでした。

感想ツイートに並ぶ「エンジニアリングマネージャも人間である」がヒットしている様子を見るに、皆さんはふだん人間と思われていなくて辛い思いをしている可能性が濃厚になってきました。

こうした雰囲気が続くとエンジニアリングマネージャを誰もやりたがらなくなってしまう。だからこそ楽しさも伝えていったほうが良いはずだという流れから、何やらこのイベントをきっかけにすごい"戦闘潮流-ムーブメント-"が生まれそうです。

f:id:ohbarye:20180926105637p:plain

イベント運営者として

まずは終わってほっとしました。

イベント運営の知見がないために至らないところが多々あったかと思いますが、 圧倒的当事者意識のある皆さんのおかげでなんとかなったところが多分にあると思います。

特に@dskst9 さんを始めとしたアスクル社の皆さんは会場提供のみならず受付・設営・ホワイトボードや文房具の準備など本当にありがとうございます。セッションが始まった瞬間に何も言わずとも皆さんがホワイトボードを活用し始めたのを見て勝利を確信しました。

第2回

濃度の高い方々(第1回に参加してさっそく第2回を望む方と、今回参加できなかった方)だけで相当数集まることがわかったので第2回も企画します。ご期待ください。

余談

イベント関連の知見、というかメモみたいなものを貼っておきます。

参加者数

  • 申し込み 76名
  • キャンセル 35名
  • 実際の参加者 27名

connpass の統計ページで見ると、公開直後と増枠のタイミングで波ができています。

f:id:ohbarye:20180926111001p:plain

(イベントでの集客のコツはこまめな増枠で波を作ること、というのを広木さんから聞いた。あと少しで定員という状況を作ると申し込みしたくなる心理)

当日のキャンセルが22名ぐらいあってドキドキしたが初心に帰って"濃度"を意識しました。

事前の仕込み

大きく2つやってみました。

Engineering Manager Slack

Engineering Manager Slack を作って事前に参加者同士の繋がりを作ろうとしました。

これはかなり良かったと思っていて、おかげでイベント参加前からすでに"エンジンが暖まっている"人々を集めることに成功しました。「この人たちが参加してくれるなら無限に安心だ」という心持ちになりました。(まぁ、そのうちの何名かは参加できなかったのですが…次回に期待!)

イベント会場にて「Slackでお見かけした○○さんですね?」みたいな会話が偶発的に生まれたときの「あ、"オフ会"…!?」という感動的瞬間もありました。

一方でSlackに参加されずに来場された方もいたと思うのでそうした方々から見た時に内輪っぽい感じになるというか、"クラスのLINEグループに自分だけ招待されてない"時みたいな気持ちになってほしくはなかったのでSlack上で起きた会話を前提とした進め方は極力避けました。(もし出てしまっていたらすみません)

また、有志4人による先行オフ会が行われたのも非常に良かったです。そのときの異常な""濃度""はそのままイベントにも引き継がれました。

Topic bucket

当日話すテーマが挙がらなかったときのために Topic bucket sheet を用意して事前に書き込んでもらおうとしました。

こちらはいまいちで、内容を見れば分かる通りなのですが僕がSlackの雑談の中でちょくちょく上がっていたトピックを転記したのがほとんどです。これは単純にあまり集まらなかったからです。

雑談の中で諸々出てきていたので「ネタはあった」「しかし書き込まれなかった」というのが実態だと思い、書き込むハードルがやや高かった or 導線が悪かったと反省してます。

横の繋がりをつくる

もともと予定にはなかったのですが、終了間際に参加者の皆さんにSNSアカウントや名刺を交換する時間を設けました。

人間だと思われていない者たちが抱えている孤独を分かち合ったからこそ生まれた"何か"があった、そしてこれから生まれる"何か"があると信じます。(何か言っているようで何も言っていない文)

その他の反省と改善点

  • ohbaryeの会場到着が18:57と開始3分前で余裕がなかった
    • テーブル割りとかを事前にチェックしておけばよかった
  • 司会進行・タイムキーパーあたりを同時にやるとけっこうきつい
  • 途中参加した方に対するフォローがなかった
    • それぞれのグループにぬるっと紛れ込んでもらうほかなかった
  • 飲食物の提供がなかった(個人のイベントなので省エネでやった)
    • 食べながらの議論は難しいので食料は無くても良かったが、よく喋るイベントなので飲み物は用意しても良かった
  • スライドを投影していたohbaryeのPCの電源が途中で落ちた
    • いろいろ慌ててしまったが参加者の方の機転で助かった
  • 各セッションのアウトプットを良い感じに共有できる仕組みがほしい
    • 2分間の発表でも伝わるものはあったが、それをストック情報にしたい
    • 口頭で「ブログや tweet で今日の input / output を教えてください!」と呼びかけてはみたがスマートではない
  • イベント運営に気を揉んだために100%ディスカッションに集中できなかった
    • セッションオーナーへの立候補も自重し、ある意味""サーヴァント""していた
    • イベント片手に回しながらセッションオーナーも余裕を持ってできるぐらいになりたい
  • ohbaryeが名刺を切らしてしまった
  • OSTのあとに懇親会をやりたい(めっちゃ盛り上がりそう)

長々6,700字も書きましたがとにかく楽しかったので優勝です。

はてなブックマーク側でタイトルやサムネイルが残念だったときの修正方法

具体例

f:id:ohbarye:20180902231427p:plain

f:id:ohbarye:20180902231456p:plain

あとは、サムネイルを貼り忘れたり意図しない画像がサムネイルになったりして困ることもよくある。

修正方法

http://b.hatena.ne.jp/entry/s/:url のページに行く。

この次がめちゃくちゃわかりにくいのだが、記事タイトルの枠の右上にマウスを持っていく。すると「適切な情報に変更」という tooltip と編集アイコンが現れる。

f:id:ohbarye:20180902231710p:plain

クリックすると以下のモーダルが現れるのでタイトルを修正することができる。

なお、この操作はブックマークをしたユーザーであれば誰でも行えるようだ。

f:id:ohbarye:20180902231902p:plain

サムネイルを更新したい場合はブログ記事を更新したのち、このモーダルの左下にある「情報を更新する」をクリックする。数分から数十分で最新の情報を取得してくれる。

なお、この操作はブックマーク先のページのオーナーでないと行えない、らしい。(オーナーという概念をよくわかっていないが)ログインしているユーザーのはてなブログでないと行えないようだ。

#iOSDC で『サブスクリプションサービスにおけるIn-App Purchase再考』という発表をしてきました

iOSDC 2018 に参加しています。また、3日目の9/1に『サブスクリプションサービスにおけるIn-App Purchase再考』という発表をしました。

iosdc.jp

発表

資料

サーバサイドエンジニアとして In-App Purchase (IAP) とその他の決済手段を開発・運用してきた経験をもとに IAP を考えなおす、という内容です。

今回は比較する軸を「決済ゲートウェイ」としました。

決済ゲートウェイとしての機能・性能・サービス・サポート面においてAppStoreを選ぶことにはどのようなメリット・デメリットがあるのか。また、IAPを選択する前、運用する中ではどのようなことを考慮しなければいけないのか。これらの観点について考えてみました。

15分で63枚というボリュームになってしまったので発表では以下を省略しました。気になる方は資料でご確認ください。

  • 開発〜テストまわりの比較
  • 運用における加盟店サポートの比較

反応

気になったのでセルフまとめ

togetter.com

反応見たところ明らかな間違いもなかった…はず。そのうえで共感ありつつ聴衆の埒外からの知見も共有できたみたいで良かったです。感想を呟いてフィードバックをいただけるのは本当にありがたいです。

準備について

3回ほど通しで練習してみた経緯が以下です

23分→18分→15分

かなり巻いたのに23分かかった初回で絶望し、内容を削ることを決めました。とはいえ調査したことや大事な補足を削ってしまうと資料価値が薄れると思ったので、Google Slides の機能でスライドを残したまま非表示にするようにしました。

発表にあたって挑戦してみたこと

朝イチの発表、大学の薄暗い大教室、100人近い聴衆が各々のPCを見つめて待機している… という状況で自分の出番を待つのが耐えきれませんでした。なのでトークの頭で話そうと思っていたアイスブレイク的な話題を開始前にしました。

具体的には発表で使った Logicool Spotlight をデモ的に紹介し、「おお〜」という声が一斉に上がったのは嬉しかったです。

これを使うことで壇上を自由に動いたダイナミックなトークができた(かもしれない)。持っててよかった Logicool Spotlight。

iOSDC

全体を通じてトークテーマの幅が広く、新しいものを取り入れたり新しい人を取り込んだりすることに非常に好意的であるという印象を受けました。

自分も iOS のことやコミュニティのことはまったくわかっていなかったのですが、勢いで申し込んだCFPが通ったのでけっこう驚きました。

相互コミュニケーションを推奨/実践しててすごい

発表者にフィードバックを促すように運営の方が仰っており、実際に参加者の方がそのように動いているのに感銘を受けました。

自分も発表に対していくつも質問をいただいたり、発表後に用意された Ask The Speaker テーブルに追加の質問・議論をしたい方が訪れたり、非常に双方向的なコミュニケーションができて良かったです。(発表前に登壇者に向けてスタッフから「質問を受けたら必ず復唱をお願いします」という気遣いがあったのも Good)

ホスピタリティがすごい

参加者が過ごしやすい環境が揃っていました。

  • ノベルティがすごい
  • ランチがすごい
  • コーヒー提供がすごい
  • Wifi、電源の充実がすごい

出る前はアウェイだろうな〜と思っていましたが開催者の長谷川さんからもフォローいただけてそこからも"ホスピタリティ"を感じました。

自分がイベントを開催するときにも参考にしたいことが沢山あった。

会場がすごい

疲れたときに座れる場所があってすごい

理工キャンパスがかっこいい

緒方恵美さんがすごい

緒方恵美さんがすごい

www.youtube.com


ということで、開催前はけっこうナーバスになっていたものの発表/参加して良かったな〜という気持ちになりました。運営の皆さん本当にお疲れ様です。

#roppongijs で『続・貢献できるOSSの見つけ方 -How to find "Good First Issues" part 2-』というLTをしてきました

第5回 Roppongi.js に参加し、『続・貢献できるOSSの見つけ方 -How to find "Good First Issues"-』というタイトルでLTをしました。

リンク付きの原稿はこちら https://ohbarye.github.io/slides/2018/roppongi.js-5/

紹介したアプリケーション

github.com

https://goofi.netlify.com/

(近々 Netlify をやめる可能性はある==この URL は死ぬかもしれない)

発表に関して所感

GUI作るぞという点で有限実行できてよかった(Firebase云々はさすがにてきとうすぎた)

また、web上で見知っていたが現実では見たことなかった方々を見ることができてよかった。特にazuさん、橋本商会さんは公開情報で助けられていることもあるので感謝したい気持ちはあったが話しかけられなかったのは残念。

Logicool SPOTLIGHTが良い

Logicool SPOTLIGHT を初めて登壇で使ってみた。"掴み"で面白がってもらえたようで良かった。PCから離れて歩き回ることで聴衆の集中力を高める"先生"の技が使えるようになる。

一方、会場トラブルで投影状況がデグレしたので肝心のスポットライト機能自体は今回はあまり活きなかったかもしれない。

spo

「頻繁に登壇するわけでもないから個人で買うには高い」と思う場合、会社の経費で購入すると社員で適宜使い回せて良さそう。

話題

発表内容にも次にやることを実現可能性無視して書いたが、その内容についてイベント参加者からフィードバックをもらえてよかった。

というわけで、さらなる改善をやっていったうえで『真・貢献できるOSSの見つけ方〜完結編〜』という話ができると良い

"まともなステージング環境"を考える

このツイートを見て弊社は5%に入れるかどうかを考えてみたいと思った。

が、そもそも何をステージング環境と呼ぶか、何をもって"まとも(信頼できる)"と言えるのかわからないのでそこから考えてみた。

ステージング環境とは

本記事中では「アプリケーション、システムの動作や表示を試験するための環境」とする。

試験の対象は機能・性能・外部連携などの多岐にわたる。また、試験を行うのはサーバサイド開発者、クライアントサイド開発者、デザイナー、カスタマーサポート、プロダクトマネージャ etc.…と、これも多岐にわたる。

まともであるために、ステージング環境で実現したいこと

少なくとも自分の感覚では、以下を実現できるのであれば良い開発体験(Developer Experience)が得られる、"まとも"なステージング環境を持っていると言えそうだ。

1. ステージング環境のアプリケーションが接続するステージング環境用データベースは、本番(production)のデータベースと同期されている

2. 任意のブランチを独立した専用のインスタンスにデプロイすることができる

  • feature branch を GitHub などに push するとCIでテストが実行され、テストがパスした場合のみステージング環境が自動的にデプロイされる

3. 特定のブランチは常に特定の名前でステージング環境にデプロイされる

  • 後述する Edge, Develop などの環境が常に存在し、継続的にアップデートされることを保証する

4. ステージング環境のアプリケーションのプロセスコントロール環境変数設定は開発者が自由にできる

5. 外部連携の試験ができる

  • 外部連携先の保持するデータとこちらのデータに一貫性がある
  • この要件は外部連携先のステージング環境に依存するので本番相当のデータを使えないことが多い

6. 本番相当の負荷試験ができる

  • 本番相当のアクセス数・データ量・サーバースペックがある
  • 常時その状態にする必要はなく、特定のタイミングでその状態にできればよい

7. multirepo構成の場合、協調して動作するアプリケーション群の任意のステージング環境から任意のステージング環境に接続できる

  • たとえばクライアントサイドのSPAとサーバサイドのAPIエンドポイントを同時に開発しているとき、前者の feature branch に対応したステージング環境から後者の feature branch に対応したステージング環境に接続したい

8. monorepo構成の場合、feature branchをそのままステージングクラスタにデプロイできる

9. アプリケーションの振る舞いに作用する環境変数を production と揃えている

  • Rails でいえば RAILS_ENV=production で動かしていること
  • 開発中の機能を production では隠す、staging では表示する、みたいな feature flag は揃えなくてよい

他にもあるかもしれないがとりあえずの思いつきを列挙してみた。弊社 Quipper はすべて実現している(はず)


ステージング環境の種類

上述の要件のうち幾つかは互いにデッドロックしあってしまうので、たった1つの環境で補うのは不可能だ。そのため各々に適した環境のセットアップが必要になる。

Quipper で実現している環境を用途ごとにまとめた。

本番で発生したバグや問い合わせを再現したい

主にカスタマーサポート(非開発者)が利用している。開発者もデバッグ用途でよく使う。

  • 本番相当のデータ+本番にデプロイされているのと同じバージョンのアプリケーションが動作する環境
  • 弊社では Edge 環境と呼んでいる

開発中の最新の動作を見たい

  • 本番相当のデータ+develop branch のHEADのアプリケーションが動作する環境
  • Edge 環境とは異なるデータベースを用意している
  • 弊社では Develop 環境と呼んでいる

次回リリースされるバージョンの動作を見たい

主にQAを行う環境。

  • 環境固有のデータ+Develop環境のある時点でfreezeしたバージョンのアプリケーションが動作する環境
  • 弊社では Release 環境と呼んでいる

本番相当のデータをあえて用意せずに環境固有のデータを用意している理由は以下。

  • 外部連携をテストする(外部のデータベースと一貫性を保つ必要がある)
  • テストデータが自動的に上書きされないようにする(current streak とか連続ログインボーナスとかの試験をしたい)

特に外部連携が曲者で、連携先が社外のベンダーでコントロールできないことがほとんどになる。

開発者、非開発者がある機能のレビューをしたい

詳しくは非開発者もGitHub Flowに巻き込んでみんなハッピーになった話 - Masatomo Nakano Blog参照

  • 本番相当のデータ+各開発者の feature branch のアプリケーションが動作する環境
  • 弊社では Staging 環境と呼んでいる…が正確ではなく、Feature Staging などと呼んだ方が良さそうだ

結論

うーん、思いつく範囲では"まとも"は満たせていると思うが、どうだろうか。

こういうのはあれば当たり前と思ってしまうが、そもそも体験したことが無いと存在の可能性にすら思い当たらないことがしばしばある。自分も現職に入ったときは「こんな便利な仕組みあったのか!」と思ったし、次の職場で何かが欠けていたら「開発体験が悪い…直さねば」と思うだろう。

なので、皆さんの考える"まとも"の(必要|十分)条件があれば教えて欲しいところ。

Engineering Manager Meetup をやります

詳細の確認および参加申し込みは以下のページからお願いします。早速定員になってしまったようなのですが増枠も検討中です。

(追記) 40名に増枠しました。

connpass.com

動機

いちエンジニアリングマネージャとして、エンジニアリングマネージャ・エンジニアリングマネジメントに興味・関心・知見・意見・失敗談・一家言ある方々と話してみたい。

"エンジニアリングマネージャ"の曖昧性

イベント概要欄に書いたとおり、(少なくとも自分が観測しているWebサービス業界隈では)エンジニアリングマネージャ職について統一された定義・見解を見ることはほとんどありません。

エンジニアリングマネージャというポジションは組織が成熟する過程において戦略的または偶発的に発生しており、会社や人それぞれによって思い描く姿やその実態・運用が異なるようです。*1

また、スタートアップ初期においては必要性が認識されることはあまりなく、CTOがその役割を兼ねていることも多いようです。*2

「いわゆるマネージャやテックリードとは何が違うのか?」という問を見るにつけて、プロダクトマネージャという役割が流行り始めた当初の「プロジェクトマネージャと何が違うのか?」と言われていたことを思い出します。

しかしプロダクトマネージャ職は今でこそ product manager conference や product manager meetup が開催されるほどにその専門性と職務内容の認知が高まり、組織ごとの知見や工夫・失敗談を交換する機会も多いものの、エンジニアリングマネージャは未だそれには及ばないと考えています。

そうした機会は少ないながらも、このポジションに就いている方はそれなりにいるようなので、各々の創意工夫や悩み、ドラマがあるのでしょう… 僕はそんな方々のうまくいった成功談、また、それ以上に失敗談も聞いてみたいのです。


…という思いを込めた tweet


話すテーマについて

Connpass ページに書いたとおりオープンスペース形式でやりたいと考えています。LTやプレゼンの準備は不要です。その代わり「何を話してみたいか」のタネが大事です。

興味が沸くように、あるいはイメージが湧くように、Connpass に書いたテーマのいくつかについて一言ずつ触れてみたいと思います。

「自分はこんなことを話してみたいな」ということを書きます。(議論の方向性を決定づけないように自分の意見は控えめで)

エンジニアリングマネージャの仕事内容

少なくともコードを全く書かないポジションではなさそうだと思うものの、どのぐらい書いている、あるいは書くことが期待されているのか。オレは毎日書いている…お前らはどうだ…???

エンジニアの上司はコードを書ける人間であるべきか?という問をよく見るが、個人的にはどちらの視点から見るかによって意見が変わりうる。

例えば自らの立場がメンバーだとしたら「マネージャはコードを書けなくても良い」と答える。コードを書けなくても頭の切れるマネージャのもとで働いたときの経験からそう思っている。エンジニアリングや目標設定に関するフィードバックは同僚から貰うこともできる。

だが、もし立場がマネージャであるときは、コードを書ける人間であるよう自分が自分に要請する。前述した自分の元上司ほど頭が切れるわけではないので、メンバーのエンジニアの抱える問題や挑戦をより深く理解するためには一定のエンジニアリングスキルは間違いなくあったほうがよい。

ちなみに『Work Rules!』によると

グーグルの採用の信条は、エンジニアリング部門のマネジャーは最低でも自分のチームのメンバー並みの技術力を備えていなければならないというものだった

エンジニアリングマネージャの仕事、キャリアパス、求められるスキル

この辺は先述の、エンジニアリングマネージャ何する人かという問いの答え次第でもある。

また、エンジニアリングマネージャを続けた先に何があるのか?VP of Engineering なのか CTO なのか分からないが、それがオレたちの望んだ未来なのか...???

テックリードなど他職種との違い

エンジニアリングマネージャからピープルマネジメント除いたらテックリードになる、みたいな会社もあるようです

エンジニアリング組織論

はい

本の感想を語り合う場所であっても良さそう

給与

エンジニアリングマネージャの給与の話だけでなく、マネジメントするメンバーの給与に関して裁量があるのか、どのように決定しているのか。そのあたりが気になります。

また、各社エンジニアリングマネージャの給与をそれ以外のメンバーに比べて高く設定しているのだろうか?

個人的には"マネージャ"と付く名前の役職にならないと給与が頭打ちになるような会社は嫌だという思いがあります。

自分が新卒入社したSIerで、エンジニアリングスキルを伸ばすよりもプロジェクトマネジメントスキルを伸ばした方が評価されるような状況にて悩んだ経験から強くそう思っています。

ちなみに U.S. 全体で$108,849 per yearが推定平均給与 by Indeed (8/13時点)

https://www.indeed.com/jobs?q=Engineering+Manager&l=United+States

Indeed Japan だと給与どころか募集があまり多くなく、推定平均給与の記載もない

https://jp.indeed.com/%E6%B1%82%E4%BA%BA?q=Engineering+Manager&l=Japan

エンジニア採用

会社によっては採用もやるようだ。

自分も採用活動に関わっているが、エンジニアリングマネージャだからやっているとか、エンジニアリングマネージャだから採用権限があるわけではない。

そういえば、マネージャに採用権限を与えるのはアンチパターンだと『Work Rules!』にはある。

採用に関する権限をマネジャーに手放してもらう必要がある。前もって言っておかねばならないが、グーグルが新たに雇うマネジャーはこれを嫌う! マネジャーは自分のチームを選抜したがるものだ。ところが、意欲に満ちたマネジャーでさえ、人材発掘の作業が長引くと採用基準をゆるめてしまう。


マネジャーに採用決定を任せると、チームのメンバーに対して彼らの権力が大きくなりすぎてしまう

評価、育成、1-on-1

1-on-1 のやり方や研修関連の情報はそれなりに見かけるし、参考になる書籍もある。

評価は結構ナイーブな話題なのでオンラインで公開するのが難しい側面も含んでいると思う。

ネガティブフィードバックをどうするか。パフォーマンスの低い社員の扱い。解雇の権限(日本だとまず無さそうではあるが…)

また、エンジニアリングマネージャにメンバーの給与を決定する裁量があるのかどうか。

許可より謝罪 権限とか承認とか

功利主義的に考えたとき承認制は本当に効用が費用を上回るのか?

意味ある承認、会社や法的に義務付けられた承認があるのも勿論知っていますが、世の中の89%ぐらいの承認って無意味ではないのだろうか。残り11%で失敗したときのリスクがでかすぎるというなら払うべきコストだと思うが…。承認業務が比較的少ない現状でもそんなことを考えている。

またまた『Work Rules!』を持ち出すと「マネージャは部下に権限を与えまくって、不安になるぐらいでちょうどいい」という話が良かった。

人々がマイクロマネジメントに走るのは、組織のパフォーマンスに関する不安を緩和するためだ。つまり、他人の行動を絶えず監督し管理していると気が楽になるのだ──これは、本質的には彼らの自信のなさを表しているにすぎない。そうすることで、マイクロマネジャーは自分が管理をしている(役立っている)という幻想に浸れる。もうひとつの動機は、スタッフの能力に対する信頼の欠如だ。マイクロマネジャーは仲間が『やります』と言っても、彼らが職務を見事にやり遂げる、あるいは責任を果たすとは考えないのだ


書き始めたら一言触れる程度では終わらなかったうえにあまり unobtrusive にもならなかったので、わりと話したいことがある気がしています。

ということで改めて応募お待ちしています。

connpass.com


Slack group も用意しました。“コミュニティのSlack廃れがち“問題はあると思うので何か面白いアイデアが欲しいところ

https://join.slack.com/t/engineering-manager/shared_invite/enQtNDEyMjM2NzY3OTY4LWY5NjgwMzVhMGM0MDUwZDE5OTgxNjE3MTQxMjc5NGM0YjRmMGQ4ZDYwYzVmNjdlZmRkMzAxZDQ1NWYyM2ViMWY

参考

ちょうど読んでいる最中なので引用元が Work Rules! ばかりになってしまった

*1:要出典

*2:要出典