STEAM PLACE

エンジニアリングとマネジメント

トップ > マネジメント

悩めるエンジニアリングマネージャが『Engineering Manager Meetup #2』に参加した #em_meetup

マネジメント 勉強会

f:id:dskst9:20181104163356p:plain

Engineering Manager Meetup（EM Meetup）の第二回目が開催されました！

connpass.com

一回目の開催と同じく、とても熱気があり、学び多き勉強会でした。

悩める私

ここ最近の私の悩みはアスクルという会社で「エンジニアリング文化をどうつくっていくのか」です。
そんな悩みをディスカッションしたく参加しました！

文化をつくることについて語りました

文化とは？
  • 外と中から見た抽象的なイメージ
  • 行動規範になる
  • 何が良いことなのか、考え方、働き方である
  • 価値観

文化とは、信仰に近いものがあるのではないかという話になりました。
確かに、何を信じでそれに従っているのかに近いですね。

日本の文化〜というスコープで考えた時に、普段私達が何気なくやっていることが文化となっている。
そう考えると、組織の文化も何気なくやっていることが文化として根付いているのかも知れません。

なぜつくるのか

では、なぜ文化が必要なのでしょうか？

  • 行動に一貫性をもたせたい
  • 組織をブランディングしたい
  • 最高のチーム作りをしたい
  • 事業発展に貢献したい
  • 自己組織化したい

このようななぜが出てきました。
確かに、文化があって理念があると、自分たちで判断し、一貫した行動が取れるので必要だと感じました。

どうつくるのか

さて、本題。どうやって文化は作るのか。
目標などの仕組みに組み込んだり、文化に馴染む人を集めたり。

中でも印象的だったのが「繰り返し伝えること」

カルチャーブックを作ったり、仕組みを作ったりすることで、
繰り返し繰り返し一貫した行動で伝えていくとそれが文化になっていくのではないかと感じました。

EMの転職について語りました

EMのスキルは明文化しづらく、レジェメにどう書けば良いのか。
面接でどう判断していけばいいのかというテーマです。

テーマのパンチ力すごいｗ

EMの採用

EMをやりたくて転職する人が希少で、今の組織でエンジニアからEMになったという方の方が多かったです。
では、EMの採用はどうしたら良いのか？

EMとしてできる人を、こちらから探して口説くというのがミスマッチも少なく効果的なようです。
自身でEMとして応募してくる人とはミスマッチの確立も高くなるので、面接での工夫が必要です。

  • 言っていることのリファレンスをとる
  • 疑似1on1をやる
  • 今困っていることを話してあなたならどうするか
  • EMとして努めたら最初に何をするか

などなど。一番避けるべきはミスマッチですね。

EMの転職

では、転職の時は何をアピールしたら良いのか。
個人的には「EMのスキルはストーリー」という言葉が刺さりました。

組織がどのような状態で、
何に課題を感じ、
どんなアクションをして、
どうなったのか。
そして、なぜそのアクションを選択したのか。

このようなストーリーにこそ、EMのスキルが見えるのかもしれません。

他のテーマ

パンチのあるテーマがたくさんでました。

他にもテーマはありましたが、全部撮りきれませんでした。（飲んで酔っ払って撮るの忘れました。。）

いい雰囲気でした

ハムが振舞われたり

日本酒やワインを飲みながらパワーテーマをディスカッションしたり

初めての参加の方でも存分に楽しめたと思います！ 3回目も楽しみですね！

今日の学び

前回の参加レポート

dskst9.hatenablog.com

このままでいいんだっけ？エンジニア面接官のレベル

マネジメント

エンジニア採用が 重要!重要!! と言われる昨今、どの会社も採用活動に励んでいるかと思います。

私自身も面接官として日々面接をしているのですが、ふと思いました。
あれ？自分は面接官としてちゃんとできているのかな？

f:id:dskst9:20181104164041p:plain

最高のメンバーと働くために、企業の顔になる面接官はとても大事。
そして、合否も出しているというから面接官はめちゃくちゃ大事。
応募者が全力を出せるかどうかも面接官次第。

自分はしっかり向き合えているのだろうか。

  • エンジニア面接官という重要なものが、軽視されているのではないか？
  • エンジニア面接官のスキルを体得する機会は、少ないのではないか？
  • 面接官のレベルアップはどうやってしていけばいいのだろうか？

このままでいいんだっけ？自分よ。エンジニア面接官たちよ。

私が面接官になって今に至るまで

始めて面接をしたのは前職での事。
リーダーのような立場で、上司と一緒に面接に参加したのが始まりでした。

上司の背中を見ながら見よう見まねで、実際の面接で少しずつ学んで行きました。
今に至るまでの間、面接の現場で少しずつノウハウを溜めて、自分でもよくわからない秘伝のタレと化した面接官スキルが出来上がっていました。

そして現職アスクルにてエンジニア採用に対してのPDCAを回す過程で、エンジニア面接の全面見直しを進めています。
評価基準を作ったり、面接フレーム作ったり、トークスクリプト作ったり、コーディング試験作ったり、etc、

そこで、秘伝のタレも明文化していってるのですが、そのタレは果たしていい味なのか、正解はわからないので悩んでいます。

悩んだら誰とディスカッションするのか

本を読んで知識のインプットはできますよね。
Google re:Work - 採用 もとても参考になります。

が、悩んだときどうしたらいいのでしょうか？
そのようなコミュニティも存在しないみたいなので、みんな自社でなんとかしているんでしょうか…？

もっとみんなと情報交換をしてみたい！

ということで「エンジニア面接官」コミュニティを作った

interviewer.connpass.com

キャッチ画像がものすごくイケてないような気もしますがｗ
エンジニア面接官のレベルアップをしていこう！というようなコミュニティです。

人が少し集まればイベントを立てようかと思いますので、是非みんなで意見交換してきましょう。
もちろん、面接官じゃなくても参加OKです。

想いを乗せて

もっとこんな事聞きたかったなー。こんな風にプレゼンしてくれたらいいのになー。
そんな、面接における悔しい思いを、”する側される側”がしないような、
良い面接とはなにか？を体得できるようなコミュニティになればいいなと思います。

1on1の教科書には載ってないそこんところ

マネジメント

1on1 やってますか？

1on1 大事ですよね。
みなさんはどのように 1on1 をしていますか？

1on1 は "経験学習を促進する" のが大事と言われています。コーチング、ティーチング、フィードバックなどを駆使して、内省を促します。

上記を基本として、それぞれのスタイルを確立してしていく。守破離の法則で、基本の型から始まり自分の型へと進化していきます。

さて、今回は私の型の中から5つの考え方をまとめます。

続きを読む

マネジメントに興味がなくても騙されたと思って『エンジニアのためのマネジメントキャリアパス』を読んでくれ

書籍 マネジメント

エンジニアのためのマネジメントキャリアパスという書籍が出版されました。 
タイトルに書いたとおり、マネジメントに興味がなくても、読むこと大きな学びをもらえる本です。

及川さんが前書きを書いており

本書を読み終わった後、私はひどく落ち込んでいる自分に気づきました。
~中略~
内容が素晴らしい故に、いかに自分が未熟であったかを思い知らされた

と、記載があって衝撃を受けました。
及川さんが落ち込んだら、私なんて精神崩壊してしまうのではないか…！？

本書を読んで、精神崩壊こそしなかったですが、ひどく落ち込みました。自分のレベルの低さを痛感します。

本記事では本書の知識定着のためのアウトプットと、所感をまとめています。各章毎にピックアップして記載します。

続きを読む

『Engineering Manager Meetup #1』に参加してきた

マネジメント 勉強会

f:id:dskst9:20181104163356p:plain

Engineering Manager Meetup #1 というとても気になるタイトルのイベントに参加してきました。

connpass.com

オープンスペーステクノロジーで進行する流れで、テーマは下記がピックアップされました。
※オープンスペーステクノロジーについてはconnpassのページをみてね。

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

どれもこれも気になる話題で参加するセッションに悩んでしまいます！
そんな人のために、全チームディスカッションをして、チームのディスカッション内容を全体共有という流れが組まれています（ステキ

続きを読む

『私のカイゼンジャーニー』で登壇してきた

Conference マネジメント

私の「カイゼンジャーニー」に参加＆登壇してきました！

devlove.doorkeeper.jp

7年ぶりくらいに高円寺に降り立ち、エモい話を精一杯話しました。

0にんから始まるカイゼン

私が発表したスライドです。

ストーリー仕立てのエモい感じで仕上げて、20minの発表なのに113スライドになってしまいました。。やりすぎた。
この話が誰かの役に立つと嬉しいですねー。

続きを読む

”群衆の英知もしくは狂気”から考える組織にビジョンを浸透させるには

マネジメント 思考整理

先日、朝から刺激的な記事をみつけた。

yunon-phys.hatenadiary.com

情報は人のネットワークを通じてどう感染していくのかということである。
ここで興味深いのが、ただ闇雲に情報を発信しても情報は伝わらないということ。

では、情報ではなく別のなにかを伝えるときは？
人のネットワークも考えた上で、戦略をねることで本当の効果が狙えるのではないか。と考えた。

続きを読む

『エンジニア採用担当者必見！~技術選考におけるスキルの見極め方~』に参加してきた

Conference マネジメント

givery.connpass.com

技術選考というテーマはなかなか見ないイベントだったので参加してきました。
公開NGの情報もあるということで、書けそうなことだけ書いていきます。

こんなイベント

メインはバンナムさんとクックパッドさんとのトークセッションです。

  • オープニングセッション
    • エンジニアの選考にスキルチェックが求められる背景
  • トークセッション
    • スキルチェックを活用したエンジニア採用選考手法の紹介
    • スキルチェック導入による採用効果の変化とは
    • スキルの見極め方について
    • 導入/運用体制
  • 質疑応答
続きを読む

影響の輪を増やすこと

マネジメント 書籍 思考整理

影響の輪という言葉はご存知だろうか？

7つの習慣にも出てきたこの言葉は、自分で変えられるものの範囲（輪）を言っている。

完訳 7つの習慣 人格主義の回復

完訳 7つの習慣 人格主義の回復

  • 作者: スティーブン・R・コヴィー,フランクリン・コヴィー・ジャパン
  • 出版社/メーカー: キングベアー出版
  • 発売日: 2013/08/30
  • メディア: ハードカバー
  • この商品を含むブログ (9件) を見る

例えば、天気、過去や他人など自分に変えることはできないものはこれに該当せず関心の輪と言われている。
自分で変えれるもの、例えば自分自信。そこに注力することで、自信が主体的になり影響の輪が広がるという考え方だ。

他人は変えれないけど、友人はどうか？
その友人を変えることができるなら、その友人はあなたの影響の輪の中いることになる。

続きを読む

変化を追い求めること

マネジメント 思考整理

私は選択に困った時、
変化が大きい方を選択している。

環境の変化、職場の変化、仕事内容の変化など、様々なシーンで変化が大きい方を意図的に選択している。

f:id:dskst9:20181104164230j:plain

なぜ変化を選択するのか

変化が大きい=自分が経験したことがない（少ない）

と、考えた時に自分が成長できるのは変化が大きい方だと思っている。自分の成長戦略をどう考えているかにもよるが、私は多様なドメインでエンジニアとして成長したいと考えているということだ。

続きを読む

スクラムとヒエラルキー組織の付き合い方

Scrum マネジメント

ヒエラルキー組織とスクラム

世界ではヒエラルキーからフラット、ネットワーク、ホラクラシー、ティールなど様々な組織体がありますが、日本はまだまだヒエラルキー組織が多数を占めていると思います。

そんな私が属する組織もスクラムを導入して3年が経ちました。
結果、ヒエラルキー組織でもスクラムを実施することはでき、たくさんのいい効果を生み出しました。

f:id:dskst9:20180408132330p:plain

一方で、今までの組織の考え方とスクラムの考え方とで課題も多々発生もしました。
この記事ではそんな課題にになった3つのことをまとめます。

  1. 組織体との関係
  2. 評価制度と組織のベクトル
  3. プロジェクトとプロダクトとの関わり
続きを読む

『カイゼン・ジャーニー』を読んで熱くなれ

マネジメント 書籍

twitterでも話題になっているカイゼンジャーニーを読みました！

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

展開されるストーリーに胸が熱くなり、一歩踏み出すパワーをくれます。

続きを読む

『エンジニアリング組織論への招待』はおもしろかった

マネジメント 書籍

タイトルだけで絶対におもしろいと思い、即買いしてしまった本です。  

エンジニアリング組織論への招待　?不確実性に向き合う思考と組織のリファクタリング

エンジニアリング組織論への招待　?不確実性に向き合う思考と組織のリファクタリング

 

広木さんもサピエンス全史の4倍おもしろいと言っていましたｗ

続きを読む

企業が公式テックブログをつくるべき3つの理由

Tech マネジメント

職場にてテックブログを立ち上げる機会があったので、何のためにやるのだという説明が必要だった。

f:id:dskst9:20170914003346j:plain

改めて、何のために？というのを考えると、ぼちぼち深いテーマでもあるなと思ったのでまとめてみた。
（立派なタイトルを付けてしまったが、あくまでも私感。）

続きを読む

おすすめの工数見積もり方法 2点見積もり

Scrum マネジメント

おすすめの工数見積もり方法についてのお話です。

（前置き）ストーリーポイントと相対見積もりについて

本題の前に相対見積もりとストーリーポイントについて少し触れましょう。 私は人日／人月などの絶対見積もりは使わず、相対見積もりによってストーリーポイントをつけています。

ストーリーポイントは、ユーザーストーリーやフィーチャーの規模感を表す単位です。 そして、基準となるユーザーストーリーのストーリーポイントに対して、どれくらい大きい／小さいかを見積もるのが相対見積もりです。

本エントリの見積もり単位もストーリーポイントを使用して説明します。

2点見積もりとは

「最小工数」と「最大工数」の2つを算出して見積もる方法のことです。 見積もるプロジェクト規模が大きい、あるいは不確定要素があるという時に効果を発揮するでしょう。

hirokidaichi さんの記事に、2点見積もりのことがさらに詳しくまとまっているので、是非一読ください。
qiita.com

それでは、どうやって見積もるかを具体的に説明します。

1点見積もり

まず、普段よく目にするのは下記のような1点見積もりです。

タスク名 sp（ストーリーポイント）
タスクA 5
タスクB 3
タスクC 13
合計 21

これには、個々人の尺度で見積もられており、リスクやバッファも含めたストーリーポイントになっていることでしょう。 とりわけ、見積もりは大きくなればなるほど不確実になります。

「タスクCは、本当に13なのか」、「もっと多いのではないか」──。この判断は、非常に難しいものです。

2点見積もり

対して、2点見積もりは「順調に進行した工数」、「遅延した工数」、そして「不安量」を用います。

  • sp順調: 順調に進行した場合のストーリーポイント
  • sp遅延: 最大限に遅延した場合のストーリーポイント
  • 不安量: =(sp遅延-(sp順調とsp遅延の平均))^2
タスク名 sp順調 sp遅延 不安量
タスクA 3 5 1
タスクB 2 5 2.25
タスクC 13 34 110.25
合計 18 44 113.5

上記のタスクCを例にすると、順調に進めば13 、遅延すると34と見積もっています。 もちろん、もっと遅延する可能性があれば55と入力することもあるでしょう。 2点見積もりでは、sp順調とsp遅延を入力することで、バッファ量を算出できます。 算出したバッファ量を順調spに足すことで、最終的な工数を算出するという仕組みです。

※バッファ量をスプレッドシートで算出する場合は、 SQRT関数 で平方根を算出できます。

例に挙げたプロジェクトの場合、 18+SQRT(113.5)≒29sp が工数になり、1点見積もりより7sp多くなりました。 これにより、1点見積もりの方が楽観的見積もりになっていたことがわかりました。 なお、順調と遅延の差が大きければ大きいほど、不安量が積まれバッファ量に反映されることになります。

何がいいのか

1点見積もりの場合、不確実な見積もりに対して確実な値を入れることになり、悩みが付き纏います。 前提となる要求が定まっていない場合、その悩みは大きくなるでしょう。

「この想定だとすぐ完了するが、もしかすると全然想定が違うかもしれない。そうなると21かな──。」

見積もりの際に、このようなことを繰り返している方も多いのではないでしょうか。 そして、1タスク毎の微妙なズレが見積もり全体を破綻させるのです。

不確実性のコーン 『プロジェクトの本質とはなにか』 (日経クロステック) https://xtech.nikkei.com/it/article/COLUMN/20131001/508039/ より引用

不確実性のコーンが示すとおり、「初期コンセプト」段階の見積もりは、0.25~4倍ほど乖離することもあるでしょう。 プロジェクトのフェーズによっては、見積もりの精度を突き詰めても価値ある見積もりはできません。

2点見積もりを用いた場合、最小と最大を取るのである程度ざっくりと見積もることができます。 最小と最大の差が開くと「不安量」が大きくなり、その分だけバッファが積まれることになります。

これにより:

  1. 見積もりという不確実なもので悩む時間を削減できる
  2. 悲観的見積もり、楽観的見積もりの偏りが少ない
  3. 不安量が多いタスクの洗い出しができる

さいごに

不確実性のコーンを考えると、開発する前に正確な見積もりはできません。見積もりに対する注力する価値はどれほどになるでしょうか。 少しでも確実な見積もりにしていくためには、不安量の高いタスクから着手していくことで、見積もりをブラッシュアップしていくと良いでしょう。

エンジニアのためのマネジメント入門

『エンジニアのためのマネジメント入門』という本を執筆したので、こちらも併せてご覧いただけると嬉しい限りです。

エンジニアのためのマネジメント入門

エンジニアのためのマネジメント入門

Amazon