めるノート

一児の母 兼 へっぽこWebエンジニアの内省ノート

Roppongi.vue のこと

roppongi-vue.connpass.com

Roppongi.vueは、六本木で働いていたときにやりたいなーと思っていた勉強会だったのですが、なかなかやれていなかったものでした。

当時の所属には気軽に使える会場はなかったし（今はエンジニア・デザイナーの努力により少しずつ使えるようになったけど）、一緒にやれる仲間もいなかったり、徐々に自分の仕事もエンジニアから遠ざかっていったり、、と、発案した自分自身もすっかり忘れていました。

そんなある日、六本木から六本木に転職された 元同僚さんから
「ぼくがやってもいいですか？」
と声をかけていただけました。

「特に徒党を組んでやっているわけでもないので、おゆずりしてもいいですし、人手が足りないようであれば個人でお手伝いもできます」
とお返事したところ、せっかく（当時）お互い六本木にいるので一緒にやりましょうという話になり、そうしてご紹介いただいたのが GameWith社のみなさんでした。

gamewith.co.jp

第1回は他の企業にツテもないので、GameWithさんでやろうということになったのですが、GameWithさんの場合は会議室のキャパの関係と、動画配信用のスタジオをもっている（！？）という関係で、配信メインの勉強会の方がやりやすいだろうという話になりました。
当時は自分も動画の会社にいたので、
「いやまさかエンジニア勉強会のためにスタジオを使わせてもらうなんて無理でしょ〜むりむり！」
と思っていたのですが、結果的にスタジオだけじゃなくて、 ホンマもんの配信スタッフさん まで来ていただけました。マジかよ最高じゃん...

それだけではなく、すてきなケータリングの提供や、おしゃれなステッカーの作成（designed by Fukiさん）までしていただけて、ほんとうにうれしかったのを覚えています。

当初は初回だけ配信という話もあったのですが、やはりこの配信形式の勉強会が先進的で、配信の品質も好評だったということで、第2回以降も継続してGameWithさんのスタジオを使わせていただきつつ、配信ノウハウをスタッフに伝授してもらって、やっています。
ほんとうにほんとうにありがとうございます！！

第2回くらいまでは自分もお仕事が大変な時期だったので、あまり映ったり喋ったりしていないのですが、第3回はかなり喋っています。

こうやって少しずつ回を重ねていくごとに、初回から一緒にMCをやっているたぐちさんだけではなく、LT会場のMCをしているplumさんや、くろもかさん、いのすさんなどなど、一緒に運営を手伝ってくれるメンバーも増えてきました。感謝感謝です！

そして実は以前から、こういったオンラインコミュニティの計画案を先立ってお持ちだったpotato4dさんも、第2回・第3回はがっつりトークセッションで入ってもらっています。ありがたいです！

自分は公式ユーザーグループの方でも微力ながらお手伝いをさせていただいている身で、それはVue.jsのハードルの低さとプログレッシブフレームワークの思想が、ひよっこからベテランまで、そしてエンジニアからデザイナーまで、どんな人でも受け入れてくれるような気がして、個人的に気に入っているから です。
だからRoppongi.vueも個人的にではありますが、「Vue.jsの話しかしない！」というよりは、Vue.jsを中心に昨今のWeb開発の役に立つ話、くらいのノリでいたいな〜なんて思っています。

あとなんとなく、公式コミュニティではないアングラ感を出したい！と思ってます（お前が言うな）。
もちろん、前回はkazuponさんがゲストで来ていただいたり、ちょこちょこ公式ユーザーグループのメンバーも来ていただいたりしているので、ケンカしてるわけじゃないですよ。笑

とにかくこの記事で伝えたいことは、Roppongi.vueは各メンバーの力と幸運によってできているということです！！（わたしはほとんどなにもしてないかもw）
第4回も、ぜひぜひ、よろしくお願いします！

誕生日と最近のこと

28回目の誕生日、そして3回目の結婚記念日は、史上最強の台風によって引きこもりを余儀なくされておりました。

VueFesのことはおいちゃんさんが書いてくださったので、自分からは特にありません。

 

今回は誕生日らしい文章じゃないし、技術的な文章でもないのですが、ふと思ったので備忘録として書いておきます。

 

続きを読む

10月から所属が変わります。

9月まで開発を離れてマネージャーをしていましたが、先日最終出社を終え、10月1日よりWebエンジニアとして新天地で働く予定です。

 

マネージャーをやってみたことに対して後悔はしていません。

どんなマネージャーかと言われると言語化が難しいのですが、ピープルマネジメントがメインで、プロジェクトマネジメントのサポートとプロダクトマネジメントのサポートもしていたのかなたぶん、という感じです。後半はめっちゃ採用してました。

 

前職で過ごした時間は本当にあっという間で、振り返ってみると在籍期間全体で見ても、あまりコードは書いてなかったなあと思います。

ですが、急成長している会社で経営層とコミュニケーションをとることができ、とても信頼していただけたことや、エンジニアだけではなく多くの素晴らしいメンバーと仕事ができたことなど、貴重な経験がたくさんありました。

 

当時はとにかく「人」について考えることが多かったなあ、と思います。

人と人が立場の違いから断絶してしまうことは胸が引き裂かれるほど苦しかったですし、逆に、人と人が対話や意見交換を通して分かり合えたその一瞬は、開発に例えるなら大規模なリリースの成功に匹敵するほどの尊さが、わたしにはありました。

 

話は変わりますが、4月に初参加したRubyKaigiや8月にコーチとして初参加したRails Girlsで、ぜひ女性エンジニアとして走り続けてほしい、という声をいただくことが多くありました。

Rails Girls出身のエンジニアが増えてきたり、Ruby界隈でも現役女性エンジニアを盛り上げていこうみたいな流れがある？ようで、(わたしはコミュニティは新参者なのでよく分かっていないのですが)そういった方々のモデルケースになってほしい、という意図だったような気がしています。違ってたらスイマセン…！

 

マネージャーでいたときは周囲にギークなメンバーが多かったので、自分は現場やらない方がいいんだろうなと思っていた部分があったのですが、上記のような声を聞いて少しずつ、わたしも現場にいて良いんだと思えるようになってきて、エンジニアにまた挑戦したいと思うようになりました。

 

そこから少しずつ、忙しい日々の合間に謎解きレベルのプログラムを書き始めたり、技術的な本を読んだりするのを再開して、プログラムを書くことや新しい学びに対する楽しさを改めて実感しました。

 

マネージャーになる前は、プログラムを書けば書くほど人と比べて落ち込んでしまう時もありましたが、Rails Girlsでは参加者のみなさんとrails newの感動を分かち合い、最近また自分なりの楽しさというのを思い出すこともできたので、もし辛くなることがあっても、こういう気持ちを大切にすればやっていけるかなって思っています。

 

最後に、コミュニティやTwitterなどでお世話になっているみなさま、いつもありがとうございます。

今後はClassi株式会社の所属となります。引き続き、どうぞよろしくお願いします。

 

マネージャーの能力について考えてみた

最近お仕事で、優秀な人について言語化する、ということをやっています。
その第一歩として、自分ひとりで考えたり調べたりしている中で、少なくとも（エンジニアリング）マネージャーの能力についてはこんなことが言えるのかなって思ったので、メモ書きがわりに残しておきます。

  • 戦略・課題・目標を考える能力
  • コミュニケーション能力
  • テクニカルスキル
    • 技術力に近いものだと思っていただいて大丈夫だと思います
  • リーダーシップ
  • 自己研鑽

戦略・課題・目標を考える能力

  • 戦略や課題を考え、目標設定する能力
    • チームのビジョン・戦略を明確に持てる
  • 目標や計画などの進捗管理を行う能力
  • 状況を構造的かつ概念的に把握し、物事の本質を見極める能力

コミュニケーション能力

  • 指示やアドバイスなどを、的確に伝える能力
  • 傾聴する能力
  • 質問する能力
  • フィードバックする能力
  • コンテキストの異なる他の部署などとコミュニケーションができる能力
  • メンバーの成功と幸せへの関心をもっていること
    • 社内キャリアチェンジなど、メンバーのキャリアについてサポートできる

テクニカルスキル

  • 専門的な職務遂行について秀でている
  • メンバーの能力や状況を把握するアセスメントスキル
    • 長所と短所を正確に把握し、成長する方法や育成方針を的確に定める能力
  • コーチングスキル
    • メンバーの長所や強みを見つけ出し、それを活かす
    • 面倒見のよさ

リーダーシップ

  • 大局的な分析力と判断力
  • 信頼を示す能力
  • 人を束ね、組織として機能させる力

自己研鑽

『THE TEAM』×『エンジニアリング組織論への招待』コラボイベントに参加しました

先日、以下のイベントに参加しました。

connpass.com

ブログ枠で参加したのに、投稿が遅くなってしまってすみません！
実は「THE TEAM 5つの法則」本編を読むのがイベント後になってしまった（死）のですが、イベントと書籍についての感想を書かせていただきました。
もし「書きすぎ！」とか「それはちがう！」みたいなところがあれば、遠慮なく自分（@c5meru）までご連絡いただければと思います！よろしくお願いします。

イベントの冒頭で「何か決まった手段をとればマネジメントができるという思い込みが失敗の元である」という言葉があって、これは本当にその通りだな、と思いました。自分は日頃から、手法にこだわりすぎないように意識しています。

Aim（目標設定）の法則

こちらはイベント会場では？？？だったのですが、書籍に書いてある例がとてもわかりやすかったです（そもそも書籍を読んでから来る前提のイベントなので当たり前ですが...）。

本を売る時の目標の立て方の例（書籍内での例）

  • 行動目標: 事例を交えて分かりやすく伝える本を作る
  • 成果目標: 10万部売る
  • 意義目標: 日本全体のチーム力を高める
  • OKRの「Objectives」が意義目標、「Key Results」が成果目標

イベントで話されたこと

  • 意義目標
    • 学校では教わらない
    • OKRで定められる
    • 抽象と具象の行き来をするのはトレーニングしないと大変
      • メンバーのレベルに合わせてやっていく
      • ジュニアなメンバーだと意義目標を立てるのは難しい
  • 成果目標
    • 数字を出すなど
    • OKRで定められる
  • 行動目標
    • 学校でやるような目標
      • あいさつをする
      • 忘れ物をしない
    • 環境の変化が少ない場合にワークする
    • 最近の企業は変化が多いのでワークしなくなってきた

書籍では、それぞれにメリット・デメリットがあるので、適切に設定することが大事とありました。
ですが、実際の現場では意義目標が欠けていることが多いそうです。自分の身の回りでもそのように思います。
「何のためにやっているのか」ちゃんとわからないまま走っていることが多いです。

Boarding（人員選定）の法則

こちらの説明は、本よりも、勉強会の場でガーッと説明されたほうがわかりやすかった印象がありました。

環境の変化度合い

  • 体が触れるスポーツは、相手の動きを気にしなくてもいい
  • 環境の変化度合いが高いチーム
    • 流動的なチームにした方がいい
    • 環境の変化によって入れ替えた方がいい
    • 採用で絞るのではなく、ある程度は誰でもいれて、合わない人が退職などの、入れ替えを考慮する
    • 必ずしも退職は悪いことはない、適切に循環すれば
  • 低いチーム
    • 固定的なチーム、退職は良くないかも
    • チームの入り口で厳選すべき

人材の連携度合い

  • 同じ時間に味方とフィールドで動くかどうか
  • 連携度合いが高いチーム
    • 異なるタイプ、多様性の高いチームにする
  • 低いチーム
    • 均質性の高いチームにする
    • 似たタイプを揃える

両者の度合いの大小で4つのタイプに分けられる

  • 駅伝型（環境の変化度合いが小さく、人材の連携度合いも小さい）
  • 野球型（環境の変化度合いが小さく、人材の連携度合いは大きい）
  • 柔道団体戦型（環境の変化度合いが大きく、人材の連携度合いは小さい）
  • サッカー型（環境の変化度合いが大きく、人材の連携度合いも大きい）

どんなビジネスモデル、どんな価値観の中にいるのかによって、どんなチームが向いているのかを考えるのが大事とのこと。

異なる価値観のチーム間では文化摩擦が起きやすい

  • 柔道団体戦のような営業チームに多い組織だと、目標を数値にしたり、目標を個人に設定させたりしがち
  • スタートアップだと中途入社のメンバーが前職の制度と比べがち
  • THE TEAMが、互いの理解を深めるためのヒントになれば

イベントでは、今どんなチームにいますか？という話がありました。

前はフルスタックエンジニアが1人1プロジェクトをもっていたのですが、現在は数人で同じプロジェクトをやったり、プロジェクト間のデータ連携があったりするので、以前とは違う体制が求められているな、と感じています。

また、チームの入口（採用）と出口（退職）にどのくらいこだわるべきなのかは自分もモヤっとしていた部分があったので、今回これを見てスッキリした気持ちがありました。

Communication（意思疎通）の法則

イベントではあまり言及がなかった部分です。
前の「Boarding（人員選定）の法則」で語られたチームのタイプに応じて、Communicationにおけるルールを適切な粒度で設定する必要がある、という話でした。
同様に、

  • 責任範囲
  • 評価対象（成果を評価するのか、プロセスを評価するのか）
  • コミュニケーションの頻度

もチームのタイプに応じて適切に設定すべきということでした。
他にも、コミュニケーションやチーム作りにおいて大切にすべきポイントなどが書かれています。

具体的にどのように設定すればいいのかについては、あまり書きすぎてもアレなので、書籍の方でお楽しみください！

Decision（意思決定）の法則

まずは意思決定の仕方を意思決定すべき、という話があり、なるほど！と思いました。

意思決定の3タイプ

  • 独裁
    • 納得感が低い、すぐ決まる
  • 多数決
  • 合議
    • 納得感が高い、なかなか決まらない
    • 最近はスピード感が求められるので最終的には誰かが決めた方がいい

それぞれにメリット・デメリットがあるので、企業のフェーズ等に合わせて適切に設定するのが大事ということでした。

イベントで話されたこと

  • THE TEAMでは3〜10人をチームと定義している
  • 決まらなくて組織が腐っていくことが多い
  • 決めることが怖い人が多い
    • 責任が曖昧、失敗したらやめないといけない感じ
    • その責任をうやむやにするための合議になってしまっている
    • イエスかノーか決まらないままになっている会社が腐っていく会社である
    • 即時の意思決定力が低いマネージャーは能力が低いことが多い
      • 即時の意思決定のトレーニングをするべき
      • 早く決めたチェスの手と、考えて決めた手は86%同じ
      • 早く決めればやり直せるから正解に近づける

上記に書いた通り、以前@magnoliaさんに1on1をしていただいたのですが、その時に話したことと同じことが話されていました。
magnoliaさんは某大手IT企業のスーパーマネージャーなので、規模などに関係なく、やはり決めることって大事なんだな、と実感しました！

Engagement（共感創造）の法則

こちらも、イベントではあまり言及がなかった部分です。
「気合ではない方法で、メンバーのモチベーションを上げるには？」という話で、あまり感情的な話が得意ではない自分にとって非常にありがたい話でした。
こちらも、あまり書きすぎてもアレなので、書籍の方でお楽しみください！

まとめ

「THE TEAM 5つの法則」の冒頭に、『チームをチームたらしめる必要条件は「共通の目的」』とありましたが、現職で自分がみているチームはこれを利用して「インフラチーム」とし、馴れ合いがなくても協力できるような体制になっていきました。
その他にも、自分がこれまでの部活・サークル・会社などを通した経験の中で感じたこと、やってきたことなどが、たくさん言語化されて散りばめられていたので、読んでいてとっても楽しかったです。

この本を読んで、いろんな法則について「じゃあウチはどうだろう？」って、周囲の（特に社内の）人とたくさん話をしてみたくなりました！これ読んでるかわからないけど、関心のある人だれか話そうよ！

素晴らしい本を書いてくださった麻野さま、冒頭のイベントを企画してくださった、リンクアンドモチベーション社とレクター社の皆さま、ありがとうございました！

アイコン缶バッチのすゝめ

おもしろいので、アイコンを缶バッチにしてみました。

RubyKaigiより前から持ち歩いていて、勉強会などで見えるところに着けるようにしているのですが、これが結構便利です。
よく、オンラインゲームみたいにハンドルネームやアイコンが頭上に出れば良いのにねー、なんて話がありますが、それを手軽に実現できている気がします。
RubyKaigiでは、インターネットだけで知り合っていた方と数人お話しすることができました。

作成したのはGMOペパボさんが運営するSUZURIです。
缶バッチを買うと考えるとちょっと高いですが、オリジナルが1個から作れるのは非常に魅力的です。

ちなみに、カバンも作りました。

髪が短い方はRubyKaigi翌日の観光中に紛失したんですが、SUZURIならすぐに再購入できるので楽です。

RubyKaigi に初参加してきました

Ruby3年目にして初めての RubyKaigi に行ってきました。とても楽しかったので、来年も身軽だったら参加したいと思いました。
キーノートのレポートは追って会社ブログにあげる予定なので、ここではセッション以外の話を箇条書きしていきます。

知見

  • 朝早めに行って公式ノベルティをもらわないとTシャツのサイズがなくなるらしい
  • スポンサーのノベルティも早めに回らないとなくなる
  • 荷物は少なめがよい
  • 飲み会が川で行われるらしい
  • カラオケではジャンル別に部屋ができるらしい
  • partyをしっかりチェックして、ちゃんと夜の予定を定めるべし
    • 前夜祭の船とコード懇親会、面白そうだったけど埋まっちゃってた
  • 飛行機のチェックインは早すぎるくらいがちょうど良い
    • 行きの飛行機がかなりギリギリになってしまった

よかったこと

エモリハウスに突撃した

  • エモリハウス
  • ぼっちにならない
  • 一方で団体行動もきつくない
    • 17人もいると、いつも全員で、という感じは一切ない
  • 行く店が全部おいしい
  • 無限に日本酒が飲める
  • エモリさんの顔が広いので、有名人とたくさんエンカウントできる
  • 4泊5日でめっちゃ安い

ノベルティが豪華だった

  • スポンサーも多かった
  • ノベルティをひと通りもらうと3kgあるらしい
    • クラウドワークスさんのPC台が結構重いんだけど、可愛いし便利そうなのでついもらってしまった
  • それでも全部欲しい
    • かわいいし便利だし豪華だし
  • スタンプラリー40カ所まわってキーケースもらった
  • JapanTaxiで、人事の人だと気付かずk8sについて質問してしまったので申し訳なかった
  • 三木さんと久しぶりに話せて嬉しかった

note.mu

会場ロケーション

  • 海が綺麗
  • ランチ時間で散歩できる

カンファレンス運営の学び

  • HTML5もVueもスタッフ参加の経験しかなかったので、大規模カンファレンス一般参加は初めて
  • 同時翻訳すごかった
  • ゴミ箱がいっぱいあった
  • 座るところもいっぱいあった
  • スポンサーブースの設置時間
  • 地方カンファレンスは、大人数のオペレーションがやりやすそう

Rails Girls

  • 今まで特に縁もなかったし、知り合いも繋がりがなかったRails Girls
  • バックエンドの国際カンファレンスなのに女性比率が高いことにびっくりした
    • しかもRails Girls関係者が多いような気がした
  • 日本各地のつながりが強い
  • 子育てする女性、年上の女性のロールモデルがたくさん
  • 無意識のうちに不安になっていたけど、この業界でやっていくイメージが具体的になった

コミュニティにいる人それぞれの生き方

  • スタッフじゃない常連が活躍するかどうかがコミュニティの肝
    • エモリさんをはじめ、エモリハウスのRubyKaigi経験者は素晴らしかった
    • スタッフや関係者と、一見さんをつなぐ非常に重要な役割となっていた
  • 有名企業に勤めるエンジニアだけが優秀なわけじゃない
    • 当たり前のことだけど最近は見失っていた
  • コードを書くことで活躍する人、コミュニティで活躍する人、さまざま
  • 仕事ではなくても、好きなコードを書いて幸せに暮らしている人がいる
    • わたしの好きなコードは何だろう、最近は忘れていた気がする
  • 自分なりの生き方を見つけていこう

エンジニアリングマネージャーでいるのがつらくなったときは

そういうときがよくあります。
マネジメントを仕事にしたのは今の会社が初めてだけど、きっとこれから先も会社に所属している限りは、なくならない気持ちなんだと思います。
だから、そんなときに振り返れるようなものを残しておきます。

...時が経つのは早いもので、コードレビューを受けるのがつらかったわたしも、気がついたらチームリーダーになっていました。
今では、当時自分自身が書いた記事を読んで、レビュアーとして考える日々を送っています。

煽りタイトルで申し訳ないのですが、マネジメントを始めてまだ1ヶ月しか経っていません。
けれど、なんとなく、

  • コードを書く時間が減ってしまったことに対する不安
    • 自分は何も生産していないのではないか
    • 今後のキャリアどうしよう？
  • 職場の人間関係に対して常にアンテナを張っていなければいけない気がする不安
    • Slackから目が離せない
    • あそこで話している人たち、何を話しているのだろう？

こんな感じで、うっかり夜遅くまで残業することになってしまったり、やや寝不足ぎみになってしまったり、なんとなく胃腸の調子を崩したりしています。
それが自分だけならまだしも、どうやら他のリーダーも遅くまで残業したり、どこか顔色が悪そうだったりするのです。
もしかして、こうして悩んでいるのは自分だけではないのかもしれないと思い、約1年ぶりに「つらくなったときは」というタイトルで記事を書くに至りました。

特につらいこと

自分は幸いなことに、そういう機会が巡って来ることは今のところないのですが、周囲の話を聞いているとマネジメントのお仕事で一番つらいのがこちら。ネガティブメンバーのマネジメントだそうです。

i47.hatenablog.com

現状

自分がチームリーダーになってからのスタンスは、以下の記事に近いです。ちなみにこの翌日のアドベントカレンダーがリアル上司ですw

takaking22.com

社内の人に読まれていそうなのですごく書きづらいんですが、特に、なるべく「情報を筒抜けにする」のは、やってみてかなり良い感じです。メンバーとの距離も広がらないですし。

そして自分を取り巻く現状としては、以下の記事が近いです。たぶんお会いしたことのある方の記事です。

kobakei.hatenadiary.jp

いかんせんコードを書くことの成果が見えやすいので比べてしまうのですが、ここで出てくる 「エンジニアの生産性」って、どうやって成果としてはかるものなんだろう？ と最近は疑問に思ったりもしています。

よく言われる「プレイヤーとして優秀なエンジニアが昇給していくためには望んでないのにマネジメントにならないといけない」問題の対策として、マネジメント系のキャリアパス以外にもエキスパート系のキャリアパスを定義し、「それぞれのキャリアパスの各グレードってどういう役割が期待されているんだっけ」などと考えて設計しています。

ここは最近、自分も部署内で問題提起をしました。
だって、昇給したくてマネジメ(自主規制
というのはおいといて、わたしはこうあるけれど、チームメンバーにはエキスパート系のキャリアパスを早く見せたいな、と思っています。

悩みは「悩みを言えないこと」

先の記事の「意識低い系」スタンスで、けっこう悩みを言ってしまうことは多いです。でもやっぱりあんまりよくないなあ、と最近は思っていて、チームリーダーだけで話し合う場を設けたり、他の部署との交流を増やすなどして工夫しています。

あとは採用ですね。「一番大事なのは採用」と記事にもあるとおり、マネジメント難易度を下げるための採用、したいです。。

今の自分にはなかった考えがあった

この記事を書くにあたり、例によって「チームリーダー　つらい」とか「エンジニアリングマネージャー　つらい」とかいうググり方をしたわけですが（笑）、そんな中で新しい発見もいくつかありました。

toyokeizai.net

上記の記事は2ページ目から「退職を伝える前に試してみること」がいくつか上がっているんですが、

  • 仕事のやり方をパクる
  • チームメンバーの個性を知る
  • 準備をする

あたりは自分も意識している一方で 「助けを求める」 という案はなかったな、と思いました。
先述の通りわたし自身にも上司がいるので、あまり抱え込まずに頼ってもいいのかもしれません。

次に、以下の記事です。

geechs-magazine.com

この 「マネージャーになると起こる変化」 の中で自分が「おっ」と思ったのが以下です。

  • 技術の習得範囲が広がる
  • 非エンジニアとのコミュニケーションが増える

マネージャーなのに技術の習得範囲が広がるのはすごく不思議なんですが、マジです。
自分は最近インフラまわりを勉強しているんですが、たまたま自分のチームにインフラが得意なメンバーがいたり、自分と同じようにインフラ勉強したいって思っているメンバーがいるので、一緒に勉強している感じがして楽しいです。まあ、あっという間に自分だけ置いていかれちゃうんでしょうけどw
あと、チームメンバーのインフラの設計レビューに出ることもあるんですが、CTOが直々に出てきてハイレベルなやりとりが見れるのも（傍観者だからというのもあり）ちょっと楽しいです。傍観者だけど、事前に自分も必死で予習しました。笑

非エンジニアとのコミュニケーションが広がるというのは、コミュ力のある方ならマネージャーにならなくともできるかもしれないのですが、規模の大きな企業になってくるとなかなか難しかったりします。
リーダー同士での会話や、リーダーのみが対象になるイベントは、大きな企業の中でも比較的優秀なメンバーが集まってやることが多いので、お互い話してみると普通に面白かったりします。

わたしの理想

個人的には、こういう感じが理想です。タイトルがアレですがw

eri-twin.hateblo.jp

最初に出てくる、こういうリーダー、ほんとうによく見ます。

リーダーはただのスーパーマン。 要件からバックログのタスクにする。調整して、みんながタスクに集中できる環境をつくってあげられる。コード書いてタスクを燃やせる。なんでもできる。リーダーすごいよ。

なんでもできるのは確かに良いことなんですけど、この記事にあるような「リーダーに甘えていたボンクラコーダー」を生み出すような人はチームビルディングできない人なんだな、と思います。なので、そうならないように意識はしているつもりです。

「プロジェクトの目的のために行動できる人になる」のは、リーダーだけじゃいけない

こういう話は他の記事でもありまして、

developers.freee.co.jp

上記のfreeeさんの記事ではCTOみずから新卒のメンバーに 「3年間でスモールチームのCTOになってほしい」 と伝えていますし、

www.m3tech.blog

上記の記事はエムスリーさんですが、実際にCTOを任せちゃってます。

マネジメントはやりたくなかったわけじゃない

わたし自身、本当に昇給のためにマネジメントを始めたのかというと、今のタイミングだけ見たらイエスなんですが（笑）、そのうち子供ができて、生まれて、子育てして、それを2人か3人くらいやって、本格的に復帰して現場にコミットできるようになった段階では、どのみちもう一度やろうと思っています。今のところ。

以下の記事にもあるんですが、

qiita.com

機械を直接相手にする必要はなくなりますが、チームの価値を最大化するという課題にたいしエンジニアリングすること自体にかわりがない

この通りでして、たしかEM.FMの第1回かな？同じような話を広木さんあたりがされていた記憶があります。

大学時代オーケストラサークルにいたときに、どうやったら効率よくメンバーに動いてもらえるんだろうって思って、マネジメントとか、心理学に関する本を読み漁って、トライアンドエラーを繰り返していた時期がありました。
そういうのもあって、どうやら自分は他人よりもその手のスキルがあるらしい？と思うこともあるのですが、単にエンジニアの中にいるからかもしれません。

ただ、今のタイミングではもう少し技術力を強化したい気持ちもあって、その間で揺れてしまうことも多いです。
エンジニアのためのマネジメントキャリアパスという本の5章でも、以下のようにあります。

いきおい管理者は経営と人的管理に関する職務に忙殺され、仮に技術的な作業に時間を割こうとしても夜間か週末しかない、ということになります。自分の会社がこういう企業なら、「コードの作成やシステムのデザインはもう十分マスターした」と得心するまでは技術力の強化に専念し、納得がいった時点で初めて経営系に舵を切るか否か判断するとよいでしょう。いったんコードを書く作業から遠ざかってしまうと遅れを取り戻すのが大変です。機が熟する前に離れてしまうと、中間管理職より上に昇るのに必要な技術力を十分身につけられずに終わってしまう恐れがあるのです。

いつだってプレイヤーに戻れる

先に紹介したエンジニアのためのマネジメントキャリアパスの3章には、こんな文章があります。

あなたが望めば進路変更も可能だ、ということを忘れてはなりません。ある時点で管理職に就いてはみたが、やはり自分には向いていないと判断し、技術畑に戻る人も少なくありません。どちらの選択肢も決して恒久的なものではないのです。いずれにしても常にしっかり目をあけていること。どちらの道にもメリット、デメリットはあり、どの仕事が一番自分に向いているかを見定めるのはあなた自身なのです。

わたし自身、この文章にすごく救われました。
今日も、他の部署の方と話している中で「戻ったって良いんだよ、そうしたいと思ったら伝えてごらん」と言ってもらうことがありました。ですので、つらくなってしまったときも過度に悲観的にはならないでいたいな、と思います。

また、以下の記事では、えふしんさんが「エンジニアリングマネージャは入れ替わっても良い」と述べています。

devblog.thebase.in

そして、ここからが大事なことですが、必ずしもエンジニアリングマネージャは永遠にその立場でいる必要もなく、一定期間で別の人に入れ替わっても良いと考えています。期待するのは大人としてチームの活躍を支えるチームディレクションとしての役割です。ディレクションかプレーヤーかというのは、その都度、役割を入れ替えることはあってもよいと思います。

なによりそうすることで、たくさんのエンジニアが人の成長を支える仕事の難しさを知ることができるし、一度、エンジニアリングマネージャを経験した人は、より広い視野での仕事を期待できるわけなので、改めて現場でコードを書く役割にコミットしながら、開発プロジェクトマネジメントやメンバーの育成においてもエンジニアリングマネジメント力を発揮することが期待できます。

そうこうしてるうちに新しい事業アイディアが出てきた時には、そういう人が率先してエンジニアリングマネージャとしてチームを作れるようになることで組織のスケーラビリティは向上します。

このようにエンジニア組織全体としては、立場を入れ替え可能であることと、マネージャという役割をエンジニアとしてのキャリアの幅や柔軟性を高める役割として定義することで、プログラマ35歳定年説に代表されるような、コードを書かなくなって、エンジニアとしての死を迎えるみたいな不安な世界を終わらせることができるのではないかと考えています。

まとめ

マネジメントを任せてもらえるというのは信頼されている証しで、成長している証しです。そしてきっとマネジメントという仕事を通して、エンジニアとして技術的にも人間的にも、もっと成長できることがあるはずです。いっぽうで、コードにコミットできる今だからこそ手を動かしてスキルを伸ばしたい！と思うこともあります。
まあ、マネジメントはやりたければいつでもできるという話でもないので、もうしばらく、この貴重な機会を味わっているつもりです。

余談

...という日々を過ごしている中で、そういう気持ちをもっともっといろんな人とお話ししたいので、サイゼリヤミートアップをしようと思いconnpassで下書きまで作ってあるんですが、予約できるサイゼリヤが見当たらなくてできないでいます...！
もう普通の居酒屋でやろうかなあ。

わたしのオススメ技術書

今日会社で「なんかいい本ないですか？」と聞かれて、オススメ本リストを作りました。
前提としては Rails × Vue をメインに開発している会社なので、他のバックエンド・フロントエンドの情報はない感じです。。

オススメ本って人によって違うので、幅広いジャンルを心がけました。
未読のものもあるのでなんとも言えませんが😅、せっかくなので、ここに残しておこうと思います。

反省としては、Railsに関する本、Vanilla.jsに関する本、データベースに関する本、インフラに関する中級者以上向けの本を知らないんだなあ、わたし。と思いました。
特にDBとインフラは、もうちょっとがんばらねば。

あとから思い出したら黙って追加してるかもです。

Web全般

設計

インフラ

Ruby

デザイン

Vue.jsなど

外部サイトにリダイレクトするときは、オープンリダイレクトに注意しよう

すごく当たり前の話なんですけど、最近うっかりやってしまったので反省文として書きます。

まだリリースしていないサービスの初期実装で、現在のURLをパラメータにとって、ログインしたらリダイレクトで戻ってくる処理を作りました。

サービスにアクセスした時、ログインしていなければ、以下のアドレスにリダイレクトされます。
redirect_uri パラメータの中身は、最初にアクセスしたURLになります。

https://www.example.com/login?redirect_uri=https://www.example2.com/

ここで、普段おとなしい同僚から、こっそり声をかけられて、危険ですよ、というアドバイスをいただきました。
実際、作っている時もなんか危ないな、という気はしていたのですが、具体的に何かは思い出せなかったのでした。

そう、URLにある redirect_uri パラメータの中身って、なんにでも変えられちゃうんですよね。以下のように。

https://www.example.com/login?redirect_uri=https://www.cho-warui-site.com/

リダイレクト先をコントロールできてしまい、意図されていないページへのリダイレクトも許してしまいます。
これをオープンリダイレクトといいます。

オープンリダイレクトは、Webアプリケーション自体には問題がないように見えるのですが、たとえば、想定したリダイレクト先のサービスとデザインを似せたページを作って、ログイン情報を再度入力させることができれば、ログイン情報を盗み取れてしまいます。
こうしてフィッシング詐欺などに悪用される恐れがあるのです。
また、リダイレクト先を自由に設定できてしまうということは、HTTPヘッダインジェクションにもつながります。

なので、このようなリダイレクトをするときは

  • なるべくURLパラメータを使わず、リダイレクト先URLのホワイトリストを作って、そこから選ぶようにする
  • どうしてもURLパラメータを利用しなくてはならない場合
    • ドメイン名などパラメータの内容を正規表現等で厳密にチェックする（サブドメイン等も注意）
    • クッションページを設けて、外部サイトに行くよ！と注意喚起をする

以上のことを心がけるのが大切です。

いやはや、リリース前でほんとうによかったです。
今度、会社で徳丸本の輪読会をするので、きっちり読み返します。

参考 https://www.websec-room.com/2014/06/22/1899