STEAM PLACE

とあるエンジニアのブログ

発売のお知らせ『エンジニアのためのマネジメント入門』

2023年3月9日に、『エンジニアのためのマネジメント入門』が発売になります!


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

  • 著者: 佐藤大典
  • 出版社: 技術評論社
  • 発売日: 2023年3月9日
  • ISBN: 9784297133344
  • A5判/208ページ

エンジニアリングマネージャーの入門書です

本書では、エンジニアリングマネージャーの職務を組織的側面から解説しています。コミュニケーションの技術からチーム作りや企業戦略など、マネージャーとしての必要な知識をまとめました。

特別に、本書の「はじめに」から一部を引用して、本書をご紹介しましょう!

 2010年代後半になり、エンジニアリングマネージャーという言葉が、世の中に認知され始めます。エンジニアリングマネージャーに向けた情報も増え、マネジメント初学者にとっての敷居が下がりました。
 一方で、「エンジニアリングマネージャーは何をすればよいのか」と悩む人を見るようになりました。日本には、1万人以上のエンジニアリングマネージャーが存在すると考えられますが、定義は曖昧で組織によって役割は違います。そのため、人がいうエンジニアリングマネージャーは別のものであり、「何をするのか」はそれぞれ異なっているでしょう。
 このような背景により、エンジニアリングマネージャーに関する知識は体系化されていませんでした。そのため、皆が同じような悩みを抱いていたのです。そこで、本書ではエンジニアリングマネージャーに関する知識の体系化を図りました。
 エンジニアリングマネージャーになると、「自分はエンジニアではない」という感覚になるかもしれません。事実、エンジニアリングマネージャーは、エンジニアではない別の職務になります。それは、エンジニアキャリアの終焉ではなく、マネジメントキャリアの始まりになるのです。本書をとおして、マネジメントに関する学びの提供と、マネジメントの楽しさをお伝えできると喜ばしい限りです。

「エンジニアのためのマネジメント入門」(佐藤大典. 2023. 技術評論社. p.7)より引用

本書のイメージが少し伝わりましたか?

書籍の目次および執筆の背景は、過去のエントリでも紹介していますので、併せてご覧ください。

steam.place

それでは、みなさんぜひ手に取ってみてください ;D

書籍『エンジニアのためのマネジメント入門』を執筆しました

2023年2月〜3月頃に、私が執筆した書籍『エンジニアのためのマネジメント入門』が発売になります🎉

本稿では、発売に先立って「書籍について」と「執筆のきっかけ」、そして、書籍の「目次」と「各章の内容」を紹介します。

書籍『エンジニアのためのマネジメント入門』について

本書は、タイトルのとおりエンジニアリングマネージャーの入門書です。

本書のポイントは、エンジニアリングマネージャーの実務よりも、基礎となる知識の体系化を図ったことです。 この一冊で、エンジニアリングマネージャーの基礎的・基本的な知識と技能を学べます。

ハウツーではなくマネジメントの原典を基にした本なので、エンジニアリングマネージャーの入門者だけではなく、経験者の方も楽しめると思います。

執筆したきっかけ

私は初めてマネジメントに携わったとき、「マネジメントは何をすればよいのか」と悩んでいました。 「マネジメントについて学ぼう」と思っても、何から学べばよいのかわかりませんでした。 マネジメントに関する情報や書物は数多くあり、私にとって何が必要かわからなかったのです。

当時の私はマネジメントが好きではなく、マネジメントをする不安や恐怖に負けないように、必死にもがいました。 マネジメントと名がつく書籍をいくつも読み漁ったり、上司の見よう見まねをしてみたり、手探りでマネジメントをしていたのです。あるいは、「マネジメントは何をすればよいのか」に対する納得する答えを探していたのかもしれません。

それから時は流れて、いつの間にかマネジメントが楽しくなっていました。 さまざまなマネジメントの知識や経験が「点」ではなく「線」になり、頭の中にマネジメントの地図が作られて、マネジメントを学ぶのが楽しくなっていたのです。 「どのような理論からこの手法が提唱されているのか」というような原典にあたる知識にも興味が湧き、気がつけばマネジメントの探求が始まっていました。

「マネジメントが好きかもしれない」と思ってきた頃、エンジニアリングマネージャーという言葉を耳にします。 エンジニアリングマネージャーに向けた情報も増え、Engineering Manager Meetup というコミュニティもできて、マネジメント初学者にとっての敷居が下がりました。 一方で、「エンジニアリングマネージャーとは何か」と悩む人を見るようになりました。

この課題に対して、コミュニティが Engineering Management Triangle を作ったところ、多くの方から反響をいただきました。 誰かの役に立てていることを体感して、非常に嬉しかったことを記憶しています。 この頃から、エンジニアのためのマネジメント入門書を作ってみたいと思うようになったのです。

10年前の私にも贈りたい──エンジニアが「マネジメントは何をすればよいのか」と悩んだときに、最初に手に取る一冊になる。そのような書籍を目指して執筆を始めました。

目次

それでは、『エンジニアのためのマネジメント入門』の目次を紹介します!

  • はじめに
  • 第1章 こんにちは、マネージャー
    • 1-1. あなたは転職した
      • マネジメントの歴史 
    • 1-2. マネジメントのはじまり 
      • リーダーになること 
      • リーダーとマネージャーの違い 
      • 組織の成果に責任を持つ者 
    • 1-3. エンジニアリングマネージャーとは何か 
      • マネジメントドメイン 
      • エンジニアリングマネージャーの業務 
      • マネージャーのキャリア 
    • 1-4. 本書の読み方
  • 第2章 対話の基礎を学ぶ
    • 2-1. コミュニケーションを支える技術
      • ティーチング
      • コーチング
      • フィードバック
      • メンタリング
    • 2-2. 対話のフレームワーク
      • 1on1と経験学習
      • 1on1の進め方
    • 2-3. 会議の進め方
      • 定例会議症候群
      • 会議の壊し方
      • ファシリテーション
      • 質の高い会議にする4つのテクニック
      • 合意の作り方
  • 第3章 チームをエンジニアリングする
    • 3-1. マネージャーが「指示待ちチーム」を作ってしまう
      • 「指示」の使い方
      • マイクロマネジメント
      • 委譲はマネージャーのスキル
    • 3-2. リーダーシップスタイルを使いこなす
      • チームのフェーズ
      • 6つのリーダーシップスタイル
      • リーダーでありサーバントである
      • マネージャーのフォロワーシップ
    • 3-3. 良いチームの作り方
      • 良いチームとは
      • 心理的安全性
      • 5つの因子
      • 人間らしい課題
    • 3-4. 別れと向き合う
      • 退職コストを知る
      • バス係数を高める
    • 3-5. 良いチームが価値を生むとは限らない
      • マネージャーは価値を生むのか
      • マネージャーも目標も要らないチーム
  • 第4章 組織のマネジメント
    • 4-1. 組織構造は語る
      • 組織の基本型
      • 組織構造の特性
      • 組織構造に従うな
    • 4-2. 組織とシステム
      • システムと組織構造の関係
      • 組織をソフトウェアにたとえる
      • 組織のデバッグ
    • 4-3. 組織は人から成る
      • マネージャーの視座
      • 分業が作り出すもの
      • ステークホルダーと関わる
  • 第5章 戦略実現のためのマネジメント
    • 5-1. 戦略とは何か
      • 戦略の構造
      • 戦略プランニング
      • 戦略は計画するだけではない
    • 5-2. 内部環境と外部環境
      • ケイパビリティとメトリクス
      • 組織文化の醸成
      • 組織の知識
    • 5-3. 戦略の実行
      • 予算と指標の測定
      • 目標によるマネジメント
      • ビジョンによるマネジメント
    • 5-4. 組織デザイン
      • チームをデザインする
      • エンジニアリングチームのデザイン
      • 組織デザインは決断
    • 5-5. 決断せよ、マネージャー
      • 時間をかけても良い決定にはならない
      • 意思決定の責任と権限
  • 第6章 人材の成功にコミットする
    • 6-1. 人材採用の進め方
      • 応募者プロセス
      • 人材採用プロセス
      • 面接担当は責任重大
    • 6-2. 育成のための人材の評価
      • 人材評価の基本
      • 評価フィードバックは慎重に
      • 納得性の高い評価のために
  • 第7章 技術とわたしのマネジメント
    • 7-1. テクノロジーマネジメント
      • 技術戦略とは
      • 技術戦略を描く
      • 技術選定
    • 7-2. セルフマネジメント
      • 瞬間のマネジメント
      • 時間のマネジメント
      • レベルアップ
  • 参考文献

各章の内容

第1章「こんにちは、マネージャー」では、マネジメントの歴史、リーダーとマネージャー、そしてエンジニアリングマネージャーとは何かを学びます。

第2章「対話の基礎を学ぶ」では、対話における基礎となる技術や知識を学びます。マネージャーは、対話の機会が増えるため、対話の基礎はさまざまなシーンに活かされるでしょう。コミュニケーション技術として、ティーチング・コーチング・フィードバック ・メンタリング・ファシリテーションを学び、1on1ミーティングや会議などでこれらを応用します。

第3章「チームをエンジニアリングする」では、チーム作りにおけるリーダーシップの使い分けと良いチームの作り方を学びます。チームのマネージャーは、誰しも良いチームを作りたいと考えていることでしょう。そのようなマネージャーのために、良いチーム作りの方法をまとめています。

第4章「組織のマネジメント」では、組織の構造を詳解します。どのように組織が構成されているかを理解することで、組織におけるマネージャーの役割が見えてくるでしょう。また、組織はいくつものチームから成っているので、ほかのチームとの関わりについても考察します。複数チームのマネジメントをしている人は、これらの知識が役に立つでしょう。

第5章「戦略実現のためのマネジメント」では、戦略の作り方から実現方法までをまとめています。戦略の実現は、目標から組織デザインまで多岐にわたるでしょう。戦略の策定から実行までする──複数のマネージャーのマネジメントをする人へ、網羅的な知識を提供します。

第6章「人材の成功にコミットする」では、人材採用と人材評価を学びます。人材の採用は育成のはじまりです。人材の成功のために、育成・支援するのもマネージャーの仕事です。

第7章「技術とわたしのマネジメント」では、技術のマネジメントと自らをマネジメントするための方法をまとめています。

以上、7章から本書は構成されています。各章は独立しているので、読者が学びたいマネジメント領域やキャリアなどに合わせて、本書を活用いただけます。

さいごに

2022年12月現在、原稿の最終調整と組版を行っています。 追い込みをかけているところですが、今から発売が楽しみでドキドキワクワクしています。

書籍『エンジニアのためのマネジメント入門』が発売されたら、ぜひ手に取って読んでください!発売日が決まりましたら、本ブログにてご報告いたします。

さいごに、本書のキャッチコピーを作ってみました。

すべてのエンジニアへ、マネジメントの楽しさを。エンジニアリングマネージャーの基礎的・基本的な知識と技能を学び、マネジメントを探求する旅に出よう。

以上、 Engineering Manager Advent Calendar 2022 24日目エントリでした ;D


追記: 書籍の発売日が2023年3月9日に決まりました!ぜひ、お買い求めください ;D

テクノロジーロードマップとは何か

ソフトウェア開発組織において、テクノロジーロードマップを作る機会があるでしょう。

テクノロジーロードマップとは、戦略的かつ長期的な計画を明示化し、そのプロセスをサポートするソリューションです。 ロードマップを作ることで、技術リソースや組織の目的、環境の変化との間の"動的な連携"を可視化できます。

テクノロジーロードマップとは

テクノロジーロードマップを実際に作ると、奥が深いことに気付くでしょう。 最初に考えさせられることが、テクノロジーロードマップは「テクノロジーの話だけではない」ということです。

技術戦略はビジネス戦略から独立して立案されるべきではなく、ビジネス計画が考慮されるべきです。 マーケットがあり、プロダクトがあり、そしてテクノロジーがあるのです。

ロードマップでは、マーケットとプロダクトとの連携を、時間軸の上に表現します。

https://d3i71xaburhd42.cloudfront.net/533d39a32b51704bb99dc3f95095b0d90fd18653/6-Figure2-1.png 引用: Technology roadmapping—A planning framework for evolution and revolution

ロードマップそのものより、ロードマップを作るプロセスのほうが重要

マーケット、プロダクト、テクノロジーのレイヤーが相互に連携したロードマップを作るためには、いくつものコミュニケーションが必要になります。

ロードマップを作ることは、組織間の議論を促進し、マーケット・プロダクト・テクノロジーの間のギャップを埋めることになります。 そのプロセスは、①マーケットを分析し、②プロダクト仕様を抽出し、③技術を抽出し、④ロードマップを作成するというように、それぞれの知識を共有しなければなりません。

https://d3i71xaburhd42.cloudfront.net/533d39a32b51704bb99dc3f95095b0d90fd18653/13-Figure6-1.png 引用: Technology roadmapping—A planning framework for evolution and revolution

このプロセスにおいて、マーケットの「プル」とテクノロジーの「プッシュ」のバランスをとるために、知識の共有が促進され、組織を跨いだコラボレーションにつながります。

https://d3i71xaburhd42.cloudfront.net/533d39a32b51704bb99dc3f95095b0d90fd18653/15-Figure8-1.png 引用: Technology roadmapping—A planning framework for evolution and revolution

マーケット・プロダクト・テクノロジーの間には、必ずコンフリクトが発生します。 コンフリクトを解消するために、対話を通して各レイヤーがお互いを理解することで、ロードマップが作られていきます。

そして、ロードマップを作るまでに発生するコミュニケーションを通して共通認識が生まれます。 このプロセスこそが、ロードマップがもたらす大きな価値になります。

トップダウンとボトムアップ

テクノロジーロードマップをトップダウンで作っただけでは、技術組織の理解は少ないため、ロードマップの実現は難しくなります。 一方、ボトムアップで作ると、特定の組織に閉じられたロードマップとなり、ダイナミックな戦略は生まれません。 そのため、トップダウンとボトムアップの両方が必要になります。

トップダウンである程度の指針を立てて、ボトムアップの意見を吸い上げて、そのコンフリクトを解消します。 この際に、マーケットやプロダクトロードマップとの整合性が崩れないようにしなければなりません。

トップとボトムを行き来することで、ロードマップの質が向上します。

ケイパビリティ

2015 NASA Technology Roadmaps では、個々のテクノロジーとともに、そのケイパビリティも定義されています。

f:id:dskst9:20220124093757p:plain
2015 NASA Technology Roadmaps

ロードマップを実現するために、どのようなケイパビリティが必要なのかを分析することで、技術(あるいは、組織)戦略の具体化をできるようになります。

まとめ

テクノロジーロードマップは、それ単体では価値があまりありません。

マーケット・プロダクト・テクノロジーのロードマップと連動しながら、トップとボトムを行き来して作成することに意味があります。 そして、ケイパビリティを分析することで、組織戦略が見えてきます。

これらが連動することで、テクノロジーロードマップの価値が発揮されるようになります。

参考文献

マネジメントの根っこには何があるのか

こんにちは!この記事は Engineering Manager Advent Calendar 2021 の12日目の記事です。

マネジメント関して、その論理や知識などさまざまな情報が溢れており、体型的に学ぶことができます。 しかし、これらを自分のものにして、使いこなすのは容易ではないでしょう。

本エントリーでは、マネジメントの根っこに何があるのか明らかにし、論理や知識をどうすれば自分のものにできるか考察します。 (という、ポエムを書きます)

マネジメントの根っこ

マネジメントは、その根っこに何があるのでしょうか。

マネジメントの対象であるプロダクトマネジメントやピープルマネジメントなどは、ソフトウェアにおけるユーザーインターフェースに近しいものです。 そこから1つレイヤーを降りると、マネジメントの論理や知識というスキルがあるでしょう。

さらに、その内側には何があるのでしょうか。

f:id:dskst9:20211212005201p:plain
マネジメントアーキテクチャ

筆者は、マネジメントにおける根っこには、ポリシーがあると考えます。 ポリシーとは、自らの主義であり私たちはそれぞれのポリシーに従って行動しています。

そして、ポリシーからマネジメントスタイルが構成されています。 マネジメントスタイルは、マネジメントのアプローチのことであり、いくつものスタイルが存在します。 民主型や放任型など、その1つひとつが適したシーンも異なりますが、すべては中心にあるポリシーに従って行動をしています。

マネジメントの中にあるプリミティブなもの

マネジメントにおいて大事なものは、ポリシーやスタイルという根っこにあるものです。 それらを、何かに依存させてしまうと、マネジメントスタイルやポリシーがブレてしまうでしょう。

世の中にあるマネジメント論理や知識を、そのまま自分のものとしようとしても、うまくいかないのもそのためです。 それは、誰かのポリシーやマネジメントスタイルから生まれたものであり、自分のポリシーに従っていないこともあります。

体型的に得た知識をただ使うのは、表層だけのロジックになりかねません。 マネジメントの中にあるプリミティブなものが何なのかを、理解することが重要ではないでしょうか。

ポリシーをアップデートする

論理や知識は、先人たちの研究結果から導き出されたもので、それらを学ぶことは非常に有用です。 一方で、それだけに頼ってマネジメントすることは困難です。

自分の中のポリシーを見つけ、マネジメントスタイルを確立することで、論理や知識を自分のものできたと言えるのではないでしょうか。 これにより、自分だけのマネジメントができるようになります。

ポリシーは経験から作られていきます。 さまざまな難問と困難を乗り越えることで、複雑なポリシーが形成されて、示唆に富んだマネジメントができるようになるのでしょう。

感覚に頼らない。組織課題をeNPSから分析する方法

メリークリスマス🎄
この記事はEngineering Manager Advent Calendar 2020の25日目の記事です!

ついにアドベントカレンダーも最終日となりました。 さて、最後の記事は組織課題の分析方法についてまとめました。 組織課題というものは目に見えなくわかりにくいものです。それを分析するにはどうしたら良いでしょうか。

最初に1つ質問です。皆様の組織はどのように組織課題を集めて分析していますか?

これが課題“だと思う”、という直感的な感覚で課題を見つける人も多いでしょう。しかし、それが本当に課題なのかは定かではありません。私たちはあくまでも自分の認知フレームでしか課題を認識できないからです。

本稿では、組織課題を感覚に頼らず定量的に分析していく手法を紹介します。

組織サーベイやっていますか?

1on1などを通してヒアリングしていくことはとても大事ですが、組織サーベイ*1という方法でも課題と向き合うことができます。 組織サーベイとは、組織に対してアンケート等を行い得られた情報から組織の問題点や改善点を分析するプロセスのことを指します。 そのプロセスはサーベイの頻度/量によってセンサスとパルスサーベイに分類できます。

  • センサス ー 半年から一年に一度の頻度で数十問の設問に回答してもらう。根幹にある課題の可視化をする。
  • パルスサーベイ ー 1週間から1ヶ月に一度の頻度で10問以下の設問に回答してもらう。細かい変化を把握する。

昨今はさまざまな組織サーベイツールが登場しており、パルスサーベイもやりやすい環境整ってきました。AIを利用した分析などもできるようになり今後大きな発展が期待される分野です。 一方で、その解析・診断結果の過程はブラックボックスと化しているツールもあるというのも現状です。「あのサーベイツールがこう言うからこれをやろう」となってしまうと、サーベイツールが"組織の羅針盤"と化してしまいテンプレートのような組織開発を進めてしまうかもしれません。

サーベイツールをより効果的に利用をするためには、組織サーベイではどのような分析を行えばいいのかという基本を学ぶことは必須です。 それでは早速、センサスやパルスサーベイで得られるアンケートデータの分析手法を学んでいきましょう。

重要指標 eNPS

組織サーベイでは、従業員が会社をどのように認識/評価しているかを数値化して組織診断を行います。中でも重要視されているのがeNPSという指標です。eNPSとはEmployee Net Promoter Scoreの略で、従業員のロイヤルティ(忠誠心、愛着心)を可視化する指標です。

なぜ、eNPSが重要かと言うとeNPSが高い社員は離職率が低いだけではなく、生産性も高くなるからです。また、チームやメンタルヘルスなどとも相関関係が強いため、eNPSを軸として分析をすると良いとされます。

元々は顧客ロイヤルティの指標であるNPS(Net Promoter Score)を起源としており、NPSでは「あなたは{商品名やサービス}を、どの程度親しい友人や家族に勧めたいと思いますか?」のような設問を用いてロイヤルティを測定していました。 eNPSでも同様に「あなたの会社を、どの程度友人や知人に勧めたいと思いますか?」といった設問に対して、0~10点で評価してもらいロイヤルティを測定します。

eNPSの算出は、まず各点数ごとに次の分類を行います。

  • 推奨者(9~10点) ー 会社やサービスを愛しいつも周りの人に薦めてくれる。離職率が低く仕事のやりがいを感じて会社に優秀な人材を呼び込む。
  • 中立者(7~8点) ー 中立的な立場をとっていて会社やサービスを薦めることも批判することもない。
  • 批判者(0~6点) ー 会社やサービスに対してネガティブな感情を持っている。中立者や推奨者に比べて離職率が2倍にもなるという。

点数ごとの分類

そして、推奨者の割合から批判者の割合を減算することでeNPSを算出できます。 例えば、推奨者17人、中立者31人、批判者19人というデータでは次のようになります。

推奨者25.4% - 批判者28.4% = eNPS -3.0

尚、日本国内企業においてeNPSの平均的な点数は -40 ~ -20 程度と言われています。

eNPSを上げるにはどうすればいいか

では「eNPSを上げればいい」と考えるのは少し違います。eNPSはあくまでも測定指標でしかなく、組織課題の解決することにより結果としてeNPSが上がることになります。

eNPSだけに注目するのではなく、その背景にある課題などを分析することが非常に重要です。 そこで必要になるのがアンケートデータです。

アンケートデータを分析する

それでは、具体的にeNPSとアンケートデータを分析してみましょう。

本稿ではサンプルアンケートデータを用いて分析を行います。アンケートの設問はリッカート尺度*2を5段階で用意したと仮定し、5に近ければポジティブな回答とします。

Googleフォームでの設問例

15の設問を用意したと仮定すると、次のようなデータを集めることができます。(イメージしやすいようにスプレッドシートにしました)

サンプルアンケートデータ

これらのサンプルアンケートデータを分析します。

eNPSと設問の相関を探る

組織サーベイにおける代表的な分析はどの設問がeNPSに相関があるのかを確かめることです。それには相関分析という手法を用います。

相関分析とは、2つのデータの関係性を表す相関係数を計算し、数値化するという分析手法です。相関分析にもいくつかの種類があるのですが、ここではピアソンの積率相関を使用しています。 相関係数は-1から1の間の数字となり、1に近づくほど正の相関、-1に近づくほど負の相関となります。

正と負の相関

各設問の相関係数を算出して散布図にプロットします。
本稿ではRを用いて算出しました。各設問はインデックスを数字として散布図にプロットしています。

# アンケートデータ読み込み
data <- read.csv("data/input.csv", header=TRUE)

# 1列目はeNPSとして扱う
enps <- data[,1]

# 2列目以降はスコアデータ
scores <- data[2:length(data)]

# スコア平均を算出
avg_scores <- apply(scores, 2, mean)

# eNPSとスコアの相関を算出
cor_enps <- cor(enps, scores)

# 二次元散布図を作成
plot(avg_scores, cor_enps, type = "n")
abline(h = mean(cor_enps), v = mean(avg_scores), col="#dcdcdc")
text(avg_scores, cor_enps)

サンプルアンケートデータの散布図

この散布図をアクションドライバーチャートと呼びます。アクションドライバーチャートは、中心線によって4象限に分かれていて各象限毎に次の意味を持ちます。

  • 右上の象限 ー 重点維持項目。eNPSと相関が高く現状のスコアも高い。
  • 左上の象限 ー 優先改善項目。eNPSと相関が高く現状のスコアは低い。ここを改善することでeNPSの向上を見込める。
  • 右下の象限 ー 基本維持項目。eNPSと相関は低い、あるいは負の相関でスコアは高い。相関が0に近ければ基本は維持する。
  • 左下の象限 ー 注意観察項目。eNPSと相関は低い、あるいは負の相関でスコアも低い。相関が0に近ければ注意観察をする。

サンプルアンケートデータの散布図に4象限を当てはめると次のようになります。

サンプルアンケートデータの4象限

重点維持項目としては 4,12,15、優先改善事項は 1,2,3,5,6,8 ということが分かります。

しかし、これだけで「相関分析ができた!」とはいえません。

これだけでは相関が強い、弱いということはいえないのです。 例えば、次の絵はコイントスのシミレーションをしたものです。眺めていると分かるのが、確率1/2のコイントスでも1シーンを切り取ると偶然にも偏りが発生しています。

コイントスのシュミレーション

アンケートの分析も同様で、偶然にも相関が算出されることがあります。この偶然というものが結果を歪めてしまうのです。 そのため、相関係数にどれほどの信頼度があるのかということを確認しなければなりません。

相関の信頼度を可視化する

相関係数の統計的優位性を確認する方法の中から、無相関の検定を用いて検定してみましょう。 無相関の検定では、その相関が偶然に発生しえるものかどうか検定します。相関が偶然起きているのか、それとも高い相関があると言えるのかを有意水準という境界で判断します。

有意水準を設定するためにはP値という値を算出します。P値とは、極端な(仮説に反する)統計量が観測される確率のことです。 有意水準としてP値を0.05(5%)で設定するのが慣習となっています。これは5%のエラーは容認せざるえないという閾値だと考えてください。 言い換えれば95%信頼できるデータかどうかを検定すると言っても良いでしょう。

さて、先ほどの散布図にP値を表現できるでしょうか。2次元だと難しそうですね。
では、散布図に対してP値の軸を追加して、3次元の散布図を作ってみましょう。

Rを用いて3次元散布図をプロットしてみます。

# 相関係数の優位性を検定
cor_tests <- vector(mode = "numeric",)
for (score in scores) {
  cor_test <- cor.test(enps, score)
  cor_tests <- c(cor_tests, cor_test$p.value)
}

# 3D散布図を作成する
plot3d(avg_scores, cor_tests, cor_enps, type = "h", col = ifelse(cor_tests <= 0.05, "#d52b2b", "#ffd5d5"))
text3d(avg_scores, cor_tests, cor_enps, c(1:length(cor_enps)))
grid3d("x", at = list(x = mean(avg_scores)), col = "#dcdcdc") 
grid3d("z", at = list(z = mean(cor_enps)), col = "#dcdcdc")

3次元散布図

濃い赤い線になっているのが有意水準を満たす相関になります。2次元散布図(検定前)では 2,3,6 が優先改善項目に入っていましたが、有意水準を満たしていないということがわかります。 よって、 2,3,6 は優先改善項目から外した方が良いでしょう。

3次元散布図を動かす

3次元散布図を作ることで、一つの散布図で分析ができるようになりました。

データを俯瞰して見てみる

では最後にサンプルアンケートデータの分析を俯瞰してみましょう。 eNPSと相関がある設問は次の通りとなります。

  • 重点維持項目: 4,12,15
  • 優先改善項目: 1,5,8

この結果に対して、なぜこの設問が連動しているのかを考え、アンケートで同時に集めたフリーコメントなどを確認しながら仮説を立てます。 さらに、(本稿では取り上げませんでしたが)因子分析を行うと尚良いでしょう。

仮説を立てたら仮説検証、要するに組織課題改善に着手を進めていきます。 その途中経過をパルスサーベイで観察しながら、次のセンサスの結果でどう変わったのかを追っていくというのが組織サーベイになります。

さいごに

このように組織サーベイを行い分析することで、感覚に頼らない組織課題分析が可能となります。 組織サーベイを行う際は参考にしていただけると嬉しい限りです。

併せて読みたい

note.com

*1:従業員サーベイ、エンゲージメントサーベイとも呼ばれます。

*2:https://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%83%E3%82%AB%E3%83%BC%E3%83%88%E5%B0%BA%E5%BA%A6

Engineering Manager Competency Matrix を作った(エンジニアリングマネジメントトライアングルの考察:破)

Engineering Manager Competency Matrix というものを作りました。 まだ作成途中ですが、現時点で公開することにします。

Engineering Manager Competency Matrix とは何か

Engineering Manager Competency Matrix(以下、EMコンピテンシーマトリクス)エンジニアリングマネージャーの行動特性をマトリクスにまとめたもので、Google Spreadsheet で公開しています。 EMコンピテンシーマトリクスを用いることで、エンジニアリングマネージャーにとって望ましい行動が明らかになります。

コンピテンシーとは何か

書籍『コンピテンシー・マネジメントの展開(完訳版)』によれば、コンピテンシーとは、「ある職務または状況に対し、基準に照らして効果的、あるいは卓越した業績を生む原因として関わっている個人の根源的特性」と定義されています。 同書によると、コンピテンシーの特性は次の5つのタイプに分かれます。

  1. 動因: ある個人が行動を起こす際に常に考慮し、願望する、さまざまな要因。
  2. 特性: 身体的特徴、あるいはさまざまな状況や情報に対する一貫した反応。
  3. 自己イメージ: 個人の態度、価値観、自我像。
  4. 知識: 特定の内容領域で個人が保持する情報。
  5. スキル: 身体的、心理的タスクを遂行する能力。

動因・特性・自己イメージに関わるコンピテンシーが、知識やスキルに基づく行動の引き金になるでしょう。 これらの特性によって、成果が生まれる──原因・結果のフローになる──のです。 また、コンピテンシーには必ず「意図」が含まれており、意図を伴わない行動はコンピテンシーではありません。EMコンピテンシーマトリクスも、この定義を根底にして構築しました。

マトリクスの構成

EMコンピテンシーマトリクスは、エンジニアリングマネージャーの一般的なコンピテンシーを定義しました。 さらに、これらのコンピテンシーを次に挙げる3つのカテゴリに分類します。

  • Person based: 個人の人間性などによる行動特性。動因、特性、自己イメージに該当する。
  • Skill based: エンジニアリングマネージャーのスキルベースによる行動特性。スキル、知識に該当する。
  • Culture based: 企業文化に適したコンピテンシー。

Person based

書籍『コンピテンシー・マネジメントの展開(完訳版)』によると、エンジニアのような専門職の管理者を一般的な管理者と比べても、コンピテンシーに大きな差はなかったようです。 そのため、EMコンピテンシーマトリクスでは、同書から「管理者」のモデルを引用しました。

Skill based

エンジニアリングマネージャーのスキルを考える土台として、エンジニアリングマネジメントトライアングルを使用しました。 トライアングルの各領域をスキルという視点でさらにブレイクダウンして、各項目を作成しました。

Culture based

企業文化に適したコンピテンシーは、企業ごとに異なります。 したがって、マトリクスでは未定義の項目としました。 自身の企業に適したコンピテンシーを読者自身で定義してみてください。

レベルの定義

コンピテンシーは、1から6までレベルを定義しました。 レベルの定義には、「行動の強度と徹底さ」「インパクトの範囲」「将来のための行動をする時間軸」という測定尺度を用いています。 たとえば、レベル1はアソシエイトエンジニアリングマネージャー。レベル6は、エグゼクティブエンジニアリングマネージャーというように、レベル6に近づくにほど強い行動特性を発揮します。

EMコンピテンシーマトリクスを価値あるものにしていきたい

コンピテンシーの定義は、本来は行動結果面接(BEI)などによって行われます。 しかしながら、私一人で多くのエンジニアリングマネージャーにインタビューすることは困難でした。 そのため、EMコンピテンシーマトリクスはまだまだ未成熟な状態です。

ぜひ、周りのエンジニアリングマネージャーのコンピテンシーを元に、EMコンピテンシーマトリクス作成を手伝っていただけると嬉しい限りです。

元データは GitHub で管理しています。Contribution については README を参照ください。 github.com

GitHub の Json を Google Spreadsheet に取り込むと、冒頭にもリンクしていたマトリクスになります。(Json は GAS で取り込めるようしています) docs.google.com

謝辞

EMコンピテンシーマトリクスの作成にあたり、以下2つの資料を参考にさせていただきました。 この場をお借りして、感謝申し上げます。

Circle CI 社のコンピテンシーマトリクス

circleci.com

エンジニアリングコンピテンシーマトリクスとして有名な記事です。 エンジニアリング全般から、企業文化も反映されています。 EMコンピテンシーマトリクスは、エンジニアリングマネージャーにフォーカスしたかったため、同社のマトリクスのレイアウトをベースにして軸を改訂して作成しました。

コンピテンシー・マネジメントの展開(完訳版)

コンピテンシーについて説いた非常に学びがある書籍です。 著者のスペンサー氏は、次のステップで数多くの職務を分析していました。

  1. 業績考課制の尺度を定義する
  2. 尺度ごとのサンプルを選ぶ
  3. データを収集する(行動結果面接、パネル、360°評価、観察など)
  4. データを分析し、コンピテンシーモデルを作る
  5. コンピテンシー・モデルの妥当性を検証する
  6. コンピテンシー・モデルの適用を準備する

この分析を、数多くの被験者に対して実施しています。 EMコンピテンシーマトリクスの Person based は、すべて同書からの出典です*1

*1:生産性出版社から引用許可をいただいています

5分でわかるOKR

OKRとはObjectives and Key Resultsの略で、目標と成果指標から構成されます。 Oは定性的な目標を作り、KRは定量的な指標を決めます。そして一定期間内にOの達成を目指し、KRで目標の達成判定するというものです。

OKRの一番の特徴は”大胆な目標設定と目標へのフォーカス”にすることです。 ムーンショットと呼ばれるストレッチした目標にフォーカスすることで、革新的なアイデアや前例のないアクションが生み出されるのです。

Objectivesの基本

  • 野心的でワクワクするような高い目標を1つ立てる
  • 時間の制約を設ける(通常は四半期)
  • 各チームが独立して実行できること

Oを達成したかどうかを測定するのがKRです。Oの定性的な目標を定量的な視点で定義したものといえます。 たとえば売上、サイトスピード、エンゲージメントなど測定できるものならどんなものでも良いとされます。

Oは1つだけ作られるのに対して、KRは3つほど定義されます。

Key Resultsの基本

  • 必ず測定できること
  • Objectiveを具体化している
  • 3つほど定義する
  • 高難易度だが不可能ではない数値である
  • シンプルに測定できる

OKRの連鎖

OKRのもう1つの特徴は、組織のOを連鎖させメンバーのOまで繋がっていることです。

f:id:dskst9:20200517073507p:plain
OKRの連鎖

これはトップダウンを意味するのではありません。OKRはトップダウンとボトムアップの両方の視点から作成されるとよいとされています。
最初は全社のOKRをひとつだけ決めて、組織全体に公開することが望ましいです。全社ができない場合は1つのチームで導入してみる、プロジェクト単位で導入するということもできます。

OKRの評価

OKRの評価は数字で行います。
KRを個別に評価をしてその結果に基づいてOの評価を行います。KRの中にはやったかやらないかのいわゆる1か0のものや、複数の要素で構成されるKRも存在します。

重要なのは厳密な採点ではなく、チームが実態を把握して一貫した評価方法を用いて評価をすることです。達成率はおおよそ60%~70%になりますが、70%達成できたら成功と言えるくらい、それくらいの高い目標を掲げることに意味があるのです。野心的な目標はなかなか達成はできないのです。

OKRの運用

OKRはただの目標管理ではなく、達成困難な目標にチーム、個人をフォーカスするフレームワークと言えるでしょう。 やるべきことをOKRにしても意味がありません。OKRを用いることでチームが自発的に考えることが大事になります。

また、OKRの導入初期は、OKRを達成できずに失敗すると言われます。
OKRを達成できないからといって途中でOKRの内容を変更してはいけません。達成できなかったという事実を次のOKRへの糧にしましょう。

参考書籍など

rework.withgoogle.com

OKR(オーケーアール)

OKR(オーケーアール)

すべてのエンジニアが持つべきプロダクト思考とは

メリークリスマスイヴ!エンジニアリングマネージャーの さとうだいすけ @dskst9 です!
この記事は Engineering Manager Advent Calendar 2019 24日目の記事です。

みなさんはプロダクト作りを楽しんでますか?

私達エンジニアの存在意義であるプロダクト開発において、プロダクトマネジメントは切っても切れない存在です。

f:id:dskst9:20191224013706j:plain

本稿では、エンジニアが持つべきプロダクト思考とは何かを探求します。

エンジニアにとってプロダクトとは

私達は機能を作っているのではなく、プロダクトを作っています。 プロダクトとは顧客に届ける価値であり、私達はプロダクトの価値を高めたいと考えています。

しかしながら、プロダクトを取り巻く環境は多様であり、価値提供のための活動は開発だけに留まりません。

採用などの一見プロダクトと関わりのないような活動も、辿ればプロダクトの価値提供に帰着します。

プロダクトの価値がゼロになると

プロダクトの価値がゼロになると何が起こるでしょうか。そう、私達の価値はゼロになります。(お給与も出ません…!)

企業はプロダクトの価値を販売して売上を上げ、原価や固定費、変動費などを差し引いて利益をあげます。簡単な図にすると下図のように整理ができます。

f:id:dskst9:20191222152012j:plain
会計図解

私達の人件費は、管理会計上は固定費に属します。財務会計上は少しややこしいので下図を引用いたします。

f:id:dskst9:20191222132017j:plain
引用 https://globis.jp/article/5440

プロダクトの価値とは企業活動においてコアとなるものであり、プロダクトが上げる売上やお金の流れを理解して開発をする必要があります。採用などの活動においても同様です。人件費を増やすことで、どのような効果を出すのかを計画して行う必要があります。

私達の活動すべてが企業の活動と理解すればよいでしょう。

プロダクトにおける技術的負債の返済

プロダクトに一見関係のなさそうな技術的負債について考えてみましょう。会計図解で見たときに技術的負債はどこに入るのでしょうか。

プロダクトの生産活動の低下による人件費増、価値提供遅延による売上減などに反映されるかも知れません。技術的負債の返済とは何をするべきか、一般的には下記ような活動がイメージされるのではないでしょうか。

  • プロダクトコードをリファクタリング
  • システムの段階的リニューアル
  • 開発プロセスの自動化

これらを解消することで、価値提供が加速化してさらなる利益を見込めることでしょう。

しかしながら、技術的負債の返済において“プロダクトの価値”があまり登場してこないという問題もあります。

たとえば、リファクタリング。リファクタリングとは「ソフトウェアの外部的振る舞いを保ち、内部構造を整理すること」とあります。外部的振る舞いを変えないのはなぜでしょうか、変えてはダメというこはないはずです。

技術と同じようにに、長い年月をかけてプロダクトの負債も溜まっています。プロダクトの価値を最大化するためには、プロダクトの負債も返済する開発が求められています。

プロダクトの機能と価値と負債

企業活動におけるさまざまな施策がプロダクトの機能として開発され、年月が経つほど機能は増えていきます。すべての施策が成功すればいいのですが、ほとんどは失敗に終わり、長い時間をかけて価値を失っていく機能もあります。知らず知らずのうちにプロダクトの負債は溜まっているものです。

どのような機能も存在する限りは、顧客体験を提供する機能でなければなりません。

負債だと思っていたものがプロダクトの重要な機能であるということもあります。Quipper社の事例はとても素晴らしい事例なので紹介いたします。

quipper.hatenablog.com

プロダクトの負債を判断することは難しく、事業の状況やどこに何を投資しているかにより定義する指標が異なります。プロダクトにおける機能が、売上等どの指標どう変えようとしているものなのか見極めが重要となります。

プロダクトの価値を高める、あるいは負債を返済する

幸いなことに、エンジニアはプロダクトの価値を気付きやすい環境にいます。

変更のないプロダクトコードに気付いた時。リクエストがないエンドポイントに気付いた時。過去に開発したあの施策はどうなったのかと気になった時。ソースコードという剥き出しのプロダクト、ログというむき出しのデータからでも気付くことはたくさんあります。

せっかくの気付きは、すぐにでもエンジニア自身で価値を見極めたいものです。とはいえ、プロダクトの価値はどのように見極めたら良いでしょうか。

ストーリーを知る

プロダクトには必ずストーリーが存在します。まずは、プロダクトを定義する5つの質問に答えてみましょう。

  • なぜ開発をするのか? (ビジョン)
  • 誰に対しての製品なのか? (ターゲットとなる顧客)
  • どのような問題点を解消するのか? (ユーザーの抱える問題)
  • どのようにそれを行うのか? (戦略)
  • そして、なにを達成するのか? (最終目標)

引用 https://uxmilk.jp/60637

しっかりと答えられましたか? プロダクトのストーリーがクリアになると、プロダクトの機能を考えることができます。

ストーリーは企業のKPIツリーなどにも反映されているはずなので、各種指標も確認してみましょう。

ファクトを集める

プロダクトの価値の検証は「この機能をこうしたらいいのではないか?」などの小さな疑問が事実なのかを検証することから始まります。

データ分析チームに頼らずとも、まずは見れるデータの範囲で確認します。プロダクトのKPIツリーのどこに効果があるのか、それに対して機能はどのような効果を出しているのかデータを集めます。機能の狙いや機能が作られた背景を丁寧に紐解いていきます。

多角的にファクトを集めて仮説が有力になったところで、データ分析です。データ分析のプロがいる場合は協力してもらいましょう。

機能の価値を見極める

集めたファクトを分析すると機能の傾向が見えてきます。

  1. 高い価値を提供している
  2. 価値は少ない(あるいは、価値がない)

価値が少ないものは、機能改善をして価値を高める可能性を秘めています。 一方で、価値がないというものも事実存在します。

  • 価値が少ないものは価値を高める
  • 価値がないものは削除する

という、2つのアクションが考えられます。

ほとんどの場合、価値を高める可能性を模索することになりますが、価値がないものは放置してはいけません。*1

ネゴシエートする

機能を改善、あるいは削除するときには、ステークホルダーと交渉する必要があります。エンジニアもプロダクトオーナーなどと交渉する機会はありますが、苦手な人が多いのではないでしょうか。

交渉とはただ論理的に会話をしてもうまくいきません。ゼロサム*2ではなく、Win-Winの関係を目指す必要があります。そこで、交渉の条件や範囲など整理する方法としてBANTA, RV, ZOPAを考えます。

  • BANTA(Best Alternative To Negotiated Agreement)
    交渉合意できなかった場合の最善案。
  • RV(Reservation Value)
    BANTAを行使した際に得られる価値。絶対に交渉で妥結しないという最低条件。
  • ZOPA(Zone Of Possible Agreement)
    交渉妥結する範囲。

図解すると以下のようなイメージになります。

f:id:dskst9:20191222155039j:plain

ZOPAの範囲で以下に交渉を妥結するために、ステークホルダーとの会話を進めます。

プロダクトの負債を返済を例にします。 RVがプロダクトの保守費用を1%削減することであれば、その価値が他指標を押し下げて利益にどう反映するのかをロジカルに説明します。次に相手の視点から見るとまた別の案が出てくることで交渉が始まります。相手のRVを理解してZOPAの範囲を見出して妥結案を詰めていくことになります。

また、顧客との交渉も必要です。ある時に機能が無くなるということが許容できることは難しく、別の機能でフォローアップすることや段階的に機能をクロージングしていくなどさまざまな考慮が必要です。

機能を削除するときは機能を作ることよりも大変になりますが、誰かがやらなければいけません。負債を返済することで、プロダクトは健康を保ち続けさらなる成長させることができるはずです。

成長するプロダクトを描く

プロダクトの機能を改善、プロダクトの負債を返済する横で、新たなプロダクト機能開発は始まっています。 プロダクトの進化 (Sequoia Capital) - FoundX Review - 起業家とスタートアップのためのノウハウ情報 ではプロダクトの進化というものが紹介されています。

プロダクトの成長はEarly, Growth, Hyper Growth, Matureのフェーズがあります。 Growth, Hyper Growthでたくさんの機能が作られますが、急激な成長はたくさんの負債を生むはずです。「今回だけ」と言われて機能を作ることもあるでしょう。

f:id:dskst9:20191222011849p:plain
引用 https://bfore.hongotechgarage.com/entry/evolution_of_a_product

Matureフェーズに入ったらプロダクトの負債をゆっくりと返済できるかといったら、そんなことはありません。プロダクトは新たな環境や機能で新たな成長曲線を描きはじめます。

f:id:dskst9:20191222012249p:plain
引用 https://review.foundx.jp/entry/evolution_of_a_product

プロダクトが成長する限り、プロダクトを作り続けていきます。プロダクトを作り続ける限り、プロダクトの改善は続きます。

おわり

エンジニアが持つべきプロダクト思考について探求してみました。

プロダクトを開発すると言えば、何か機能を作るイメージが強いかと思いますが、時には何も作らないことが最良のプロダクト作りになることもあります。

なにをしないのかを決めるのは、なにをするのかを決めるのと同じくらい大事だ。
ー スティーブ・ジョブズ

プロダクトチームの一員になるということは、開発している機能が”プロダクトにどのような価値を提供するのか”を理解を求められます。プロダクト思考を持つことは、正しいプロダクト作りの手助けになってくれるはずです。

*1:AmazonやGoogleなどの企業では、サービスを終了するという英断を幾度となく行っています。不確実な世の中で必ず成功するものは存在しないため何度ものチャレンジが必要です。チャレンジ失敗の時に撤退する勇気を見習わなければなりません。

*2:一方の利益が他方の損失になることです。

組織本能の考察と適応

Developers Summit 2019 Summer にて『組織本能の考察と適応』という発表をした。
プレゼンでは話せなかった組織本能というものを考えた背景について書いていこうと思う。

組織本能とは

組織にも、集合体にも本能というものが存在するのではないかという考えから生まれた造語である。

組織の本能ということを考えたきっかけは3つ。

  • 会社にてエンジニアリング組織を広げる活動をしていて、各部門ごとに文化があるのを感じた。そして文化はなかなか変わらない。
  • 組織変更があると人は組織図に忠実に行動をする。昨日の仲間も組織が変わると過去のこと。
  • 人間の本能というものは集団にも濃く反映されているのだが、集団というものは多様性を生まない時もある。

f:id:dskst9:20190907163713j:plain

これはどの組織でも聞くような話で、なぜこういったことが起こるのだろうかと考えていた。 かく言う自分も本能的に守りの行動もしてしまい、これも人間の本能的なものではないだろうかと。

そんなことから集団心理を学びたく『群集心理』を読んでみた。

群衆心理 (講談社学術文庫)

群衆心理 (講談社学術文庫)

この本は、社会心理学の古典的名著で、群衆はなぜそのような行動をするのかという人間心理を描いている。 革命や宗教などが例に挙げられているのだが、読み進めると会社という組織もまったく同じである気付いた。 ”組織にも本能がある”と確信した。

人と感情

いくら論理をまとめても動かざること山の如しの集団がいる。 そういった集団に論理を語っても意味がなく、結局は感情にに左右されている。

群集心理にはこうある。

群衆は、ただ過激な感情にのみ動かされるのであるから、その心を捉えようとする弁士は、強い断定的な言葉を大いに用いねばならない。誇張し断言し反覆すること、そして推論によって何かを証明しようと決して試みないこと

群衆が非常に高く上昇したり、反対に非常に低く降下したりすることのあるのは、もっぱら感情の領域においてである。

群衆は、心象によらなければ、物事を考えられないのであるし、また心象によらなければ、心を動かされもしないのである。この心象のみが、群衆を恐怖させたり魅惑したりして、行為の動機となる。

集団の前で発言するには論理的なものよりも、感情に訴えた方が心に響くようだ。
自分が正しいと思って正しい論理を並べようが、響かないものは響かないのである。

民衆の想像力を動かすのは、事実そのものではなくて、その事実の現われ方

間違えた事実でも事実がどのように現れるかで集団の動きは異なってくる。
一歩間違えれば怖い話だが、文化変革には事実をどう表すかが肝になる。

組織と文化

文化というものは習慣から生まれている。
毎日の習慣を明日から変えられるだろうか?難しいだろう。

制度は、何ら本質的な価値を持っていず、それ自体ではよくも悪くもないのだ。ある時期に、ある民族にとってよい制度も、他の民族にとっては、厭うべきものとなることがある。

一般的信念のために、各時代の人々は、網の目のように入りくんだ伝統や意見や習慣にとりまかれていて、その絆からのがれることができないであろうし、またそれらのために、常にたがいがやや似かよったものになるのである。

組織もそれと同様で、一度できた文化(習慣)を即座に変えることはできないのである。
少なくともボトムアップで実行するのは時間を要する。

思想が群衆の精神に固定されるのに長い期間を要するにしても、その思想がそこから脱するにも、やはり相当の時日が必要である。

ひとつ方法があるとすると、圧倒的トップダウンで組織を変えることである。
ついていけない人は組織を去るが、それこそが文化を変えることとなる。逆をいえば、それこそがトップのやることではないかと思う。

組織と有機体

組織は有機体である。本能的に行動し、文化の中で感情的に生きているのである。

民族というものは、過去によって創造された一種の有機体である。どんな有機体とも同様に、民族は、祖先伝来徐々に蓄積されてきたものに手を加えなければ、変改することはできないのである。民族を真に導くものは、伝統である。

生き物の本能を歪めようとしてもそれは難しい話だ。
本能を受け入れてそれを理解しないとわかり合えないだろう。

集団に入ってしまうと本能から逃れることはできない。

あらゆる集団は、その構成如何を問わず、精神的に低下する

たとえば、集団で記念写真を取ろうとしよう。
カメラマンの指示にほぼ全員が従っているのはなぜだろうか?

たとえば、全社集会があったとしよう。
メッセージに反論があってもその時に大声で反論しないのはなぜだろうか?

人は大勢の中ではいとも簡単に、本能的に周りと同じ行動してしまうのである。

分断された世界

集団が別の集団を見るときに、「わたしたち」と「あの人たち」と分けて考えてしまう本能がある。『FACT FULNESS』にある”分断された世界”というものだ。

FACTFULNESS(ファクトフルネス) 10の思い込みを乗り越え、データを基に世界を正しく見る習慣

FACTFULNESS(ファクトフルネス) 10の思い込みを乗り越え、データを基に世界を正しく見る習慣

  • 作者: ハンス・ロスリング,オーラ・ロスリング,アンナ・ロスリング・ロンランド,上杉周作,関美和
  • 出版社/メーカー: 日経BP
  • 発売日: 2019/01/11
  • メディア: 単行本
  • この商品を含むブログ (1件) を見る

人は誰しも、さまざまな物事や人々を2つのグループに分けないと気がすまないものだ。そして、その2つのグループのあいだには、決して埋まることのない溝があるはずだと思い込む。これが分断本能だ。

世界は分断されているという勘違いをしている。「わたしたち」と「あの人たち」で分けて考えてしまう。

話の中の「分断」を示す言葉に気づくこと。それが、重なり合わない2つのグループを連想させることに気づくこと。多くの場合、実際には分断はなく、誰もいないと思われていた中間部分に大半の人がいる。分断本能を抑えるには、大半の人がどこにいるか探すこと。

同じ会社にいても組織違えば分断しているのである。小さくはチームから、会社、国へ分断本能は広く生息している。

組織は変えられないのか

『組織パターン』にこんな言葉がある。

どんな組織に属しているのであれ、組織を変えることはできないということを認識しておいてほしい。変えるべきは自分自身なのだ。

組織パターン (Object Oriented SELECTION)

組織パターン (Object Oriented SELECTION)

自分を変えることができれば、組織も変わると思っている。

前述の群衆心理にある通り、ただ論理を語っても意味がない。組織を変えるには体験が必要だと考えている。体験、経験から文化は生まれて組織は変わっていくはずである。

一方で、変わらないことも自然なことであり、組織本能に適応して長い時間をかけて変えていく必要があるのだと思う。

【EM必読】エンジニアリングマネジメントトライアングルの考察:序

エンジニアリングマネジメントトライアングル

エンジニアリングの話をする前に、プロダクトマネジメントトライアングルという言葉と聞いたことはありますか?

それは、プロダクトマネジメントという言葉の定義、責任をまとめたグラフィックモデルのことです。これはプロダクトマネジメントを探求するために作られました。

かたやエンジニアリングマネジメントも組織やフェーズによって役割が違う、責任もさまざまということから、プロダクトマネジメントトライアングルと同じように思考を整理できるのではないかと考えました。*1

では、このトライアングルをエンジニアリングマネジメントで作るとどうなるのか。Engineering Manager Meetup の有志が作ったので紹介します。

 

f:id:dskst9:20190703005645p:plain

エンジニアリングマネジメントトライアングル

中心にエンジニアリングを置いて、テクノロジー、プロダクト、チームでトライアングルを構成しています。

※最新のトライアングルは Github で管理しています。本ブログの内容は古い可能性がありますので、 Github で最新のトライアングルを確認してください。

github.com

トライアングルの軸

エンジニアリングマネジメントの3つの軸から見ていきましょう。

  • Technology
    プロダクトを形成する技術から、組織の全体の技術を広く扱います。
  • Product
    エンジニアリングは不確実なものをプロダクトにします。
  • Team
    チーム、そして組織というものにフォーカスをします。

これら3つの軸とその間を埋める空白領域こそが、エンジニアリングマネージャーの役割になると考えています。

エンジニアリングマネジメントの役割

空白領域に役割を埋めてみましょう。*2 各デルタを繋ぐ領域ごとに役割を説明します。

f:id:dskst9:20190714115349j:plain

エンジニアリングマネジメントの役割

Product - Technology

プロダクトとテクノロジーの間にある空白には、プロダクトを作るための技術、そして技術からプロダクトアウトする過程、プロダクト運用が含まれます。

 

Product Design

プロダクトのビジュアル的なデザインだけではなく、技術のデザインも含まれる。

Architecuture

プロダクトを構成するアーキテクチャ全般。

Technical Leadership

技術的側面からプロダクトをリードする。*3

Process Management

サービスインに至るまでのプロセスそのものをマネジメントする。

Quality Assurance

ニーズ、期待、要求にプロダクトが適合していることを保証する。

DevOps

運用と開発を親和させて、プロダクトをより良くしていく。

 

Technology - Team

テクノロジーとチームの間にあるものを見てみましょう。開発チームを最適化していき、チームの生産性を上げ、エンジニアリング組織を作っていきます。

 

Team Building

チームビルディングを行い機能するチームを作る。

People Development

メンバーのキャリア開発を行い成長を促す。

Recruting

採用活動、面接担当などを行い組織を拡大していく。

People Evaluation

メンバーの成長目標に対しての評価、フィードバックを行う。

Technology Selection

技術的な意思決定、あるいは技術選定を行う。

DevRel

社内外にマーケティング、広報活動を行う。

 

Team - Product

チームとプロダクトの間にあるものは、チームが作るプロダクトそのものからプロダクトと関係する組織まで多岐にわたります。

 

Vision

組織のビジョン、プロダクトのビジョンを語る。

Team Design

プロダクト組織を設計、構築する。

Product Roadmap

プロダクトの方向を明確にする。

Team Development

プロダクト組織改善、チームの育成を行っていく。

Resource Management

ヒト、モノ、カネなどの資源を管理する。

Stakeholder Engagement

ステークホルダーのエンゲージメントを高める。

エンジニアリングマネージャーは何をするのか 

トライアングルにより、どんな役割があるのか整理できたと思います。当然ながら、これらすべてを担っている人はいないかもしれません。

各領域の空白になっているところに対して、エンジニアリングマネージャーの職務が存在するのです。しかしながら、1つの組織でも組織のフェーズや戦略によって空白領域は異なるため、エンジニアリングマネージャーが何をするか明文化するのは難しくなるでしょう。

また、エンジニアリングマネージャーは、これら全てをやるのではありません。これらの役割を完璧にこなせる必要もありません。このトライアングルの空白があったときに、その空白を埋める糊のような存在こそエンジニアリングマネージャーなのです。

 

フィードバックを求めています

Engineering Manager Meetup のコミュニティでは、エンジニアリングマネジメントトライアングルがエンジニアリングマネージャーをやる人たちの役に立ってほしいと思っています。そのためには、エンジニアリングマネジメントトライアングルについて広くフィードバックを集めてより良いものにしたい考えています。

ぜひ、Twitterなどで気軽にコメントをいただけると嬉しい限りです。(追記: Githubに移行しましたのでissueを作成いただけると幸いです https://github.com/dskst/engineering-management-triangle

さいごに

このトライアングルを見ながら自身の組織での役割を考えてみるとおもしろいものが見えてきます。例えば、3年前はどの領域をやっていたのか、1年前はどうなのか、ふりかえるとさまざまな領域を移ってきたと気付かされるでしょう。

トライアングルがもう少し形になったら、次は空白領域の具体化を進めていきたいですね。

コミュニティのみなさまの紹介

本記事を公開するにあたり、Engineering Manager Meetup の @aki85135 さん、@gim_kondo さん、 @qluto さん、 @yunon_phys さん、@_tweeeety_ さん(*4)と一緒に、トライアングルについてディスカッションをしてきました。

一緒に悩みながらディスカッションができて、コミュニティのアウトプットとしておもしろいものができたのではないかと思います。ありがとうございます!

また、 Developer Summit 2019 Summer にて @yunon_phys さんがエンジニアリングマネージャーは何者か、エンジニアリングマネジメントトライアングルのお話もしてくれました。

これからも Engineering Manager Meetup は精力的に活動していきますので、EMに興味がある方はぜひご参加ください!

engineering-manager-meetup.connpass.com

2019.7.14更新

 

*1:下記のエントリーにて概念というものを探索dskst9.hatenablog.com

*2:役割は例として記載

*3:テックリードの領域に近い

*4:アルファベット順

ブルックスの法則を可視化できるのか(あるいは、人と月は等価交換できるのか)

書籍:組織パターンにて興味深い数式が紹介されています。

その数式とは、ベテランが新人を鍛えたときのチーム全体の生産性表すものです。 本の中では”託児所”というパターンで紹介されています。

なぜ興味深いのか

人月の神話、ブルックスの法則にある通り、開発者の人数と生産性が比例しないことは自明の理ですが、わたしはそれを論理的に説明することができませんでした。

ブルックスの法則

ブルックスの法則はフレデリック・ブルックスによって提唱された、「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである」という、ソフトウェア開発のプロジェクトマネジメントに関する法則である。

数式を使ってシュミレートまでできると、開発者の人数と生産性の関係性の説明でき、さらに最適な人数がわかってくるのではないかと考えました。

問題に思うこと

さて、プロジェクトを進めていると「開発者をもっと増やせばいいのでは?」とよく言われます。
「増やしても意味ない」と口でも言っても建設的な議論にはなりません。

我々も考えなければいけません。

稼働中のプロジェクトに増員することは本当に効果がないのでしょうか。
銀の弾丸はないと言われますが本当でしょうか。

生産性を可視化する

さて、ここで数式がでてきます。
以下の通り、変数を利用して生産性というものを算出します。

X=ベテランの人数
N=新人の人数
n=新人の生産性

書籍では以下2つのケースが紹介されていました。

託児所

ベテランをひとり、新人全員の教育に割り当てるケースです。

ひとりで全員を見るということで託児所と比喩されていました。

これは、以下の数式で表現できます。

(X - 1) + N * n

ベテランがひとり減り、
新人の生産性を積算することでグループ全体の生産性がでます。

託児所の例

X=ベテランの人数=5人
N=新人の人数=7人
n=新人の生産性=0.1(ベテランの1/10とする)

(5 - 1) + 7 * 0.1 = 4.7

ベテラン5人の時の生産性が5になるので、生産性が0.3減少しました。

均等割り当て

ベテランに対して新人を均等に割り当てるケースです。

チーム全員で新人を見るケースと言ったほうがわかりやすいでしょうか。

以下の数式で表現できます。

(X * X / (N + 1)) + N * n

ひとりあたりm=N/Xの新人が付きます。ベテランの生産性は1から1/(m+1)に落ち込みます。

尚、本数式ではベテランの人数より、新人の人数が少ないケースを算出することができないのでご注意ください。

均等割り当ての例

変数の値は託児所を同じとします。

(5 * 5 / (7 + 1)) + 7 * 0.1 = 3.8

生産性が1.2減少しました。

ビジュアル化する

以下2パターンをシミレーションをしてみます。
今度は新人ではなく中堅プログラマーが増員したと考えてみます。

増員人数と生産性の関係

増員をN人行った際にどれくらい生産性に影響があるのかを図にしました。

ベテラン5名のチームに、増員を5,8,13,21名とアサインするとどうなるのか。
ここでは、増員の生産性を0.5としています。

f:id:dskst9:20190302180503p:plain

図で見て取れる通り、ベテラン5名のチームに8名が入っても生産性は10にも届きません。
人数が増えれば増えるほどチーム人数と生産性は乖離します。

増員してもリニアに生産性は向上しないことがよくわかります。

増員した人の成長を考えるとどうなるか

増員した人の生産性が向上することを視野にれるとどうなるでしょうか。

ベテラン5名のチームに、増員を8名アサインします。
生産性が成長すると考えて、0.5から1か月ごとに少しずつ上昇して4か月目で1になるとします。

f:id:dskst9:20190302182459p:plain

13名のチームが2か月経過して10名の生産性になりました。
この増員は果たして意味がある増員になるのでしょうか。

まとめ

以上から無闇なアサインがどうなるかがわかりました。

生産性という変数をどのように設定するかで状況は変わってきますが、増員というもので確実に生産性が伸びるものでもないということがわかります。

ブルックスの法則にある「プロジェクトをさらに遅らせる」というのは、増員の生産性が低いときに多く発生するのはないかと思います。

たとえば、生産性が0.1(ベテランの1/10)の人を増員したときは下記のようになります。

f:id:dskst9:20190302183453p:plain

何人アサインしても生産性が上がっていきません…。均等割り当てに至っては生産性が下がってます。
悲しみしか起きないプロジェクトになりますね。

こんな過ちが起きないように、人と月は等価交換できないということが、広く一般の知識になっていってほしいものです。

組織パターン (Object Oriented SELECTION)

組織パターン (Object Oriented SELECTION)

エンジニアリングマネージャーの概念を探る

エンジニアリングマネージャーって何者か?というものを考えているのですが、明確な定義は難しいものです。

Engineering Manager Meetup #4 で Job description の話をしてきた #em_meetup - dskst's diary でも発表しましたが、 Job description という方向から攻める一方で、今後は別の切り口からも考えていこうと思います。

さて、今回はエンジニアリングマネージャーの概念に近づけそうなことがあったので整理してみました。

エンジニアリングマネージャーの概念は何か

@bufferings さんのブログ 「エンジニアリングマネージャは必要か?」 - Mitsuyuki.Shiiba にて、以下の表現がありました。

組織の形に合わせて今足りない部分を補いつつ複数のロールを担っている人、のことをエンジニアリングマネージャと呼んでいるのではないか

確かにそうだなと納得しました。
組織ごと明確になっていない空白のところやっている人。

図にすると下記のような感じでしょうか。

ここで、図という切り口で概念に近づいてみましょう。
たとえば、下記はUX概念図をまとめていますが、多様な図が出てきます。

uxxinspiration.com

エンジニアリングマネージャーも同様に、整理すると概念図にまとめることができると考えています。

プロダクトマネジメントトライアングルに似てる

プロダクトマネジメントトライアングルという、プロダクトマネジメントの責任を整理したトライアングル図にエンジニアリングマネージャーが似ているという話があります。

ninjinkun.hatenablog.com

機能横断型チーム間におけるプロダクトマネジメントの責任について、部分的には正確だが曖昧な説明として、「空白を埋める」「糊の役割を演じる」などが含まれる。

f:id:dskst9:20190210150630p:plain
引用 https://ninjinkun.hatenablog.com/entry/the-product-management-triangle-ja

この空白というのを埋めるのが各職務であり、プロダクトマネージャーだと。
エンジニアリングマネージャーもエンジニアリングの各職務があり、その空白を埋めているのではないでしょうか。

概念から具体へ、エンジニアリングマネージャーという者は存在するのか

かく言う私の会社でもエンジニアリングマネージャーというものは公式には存在しておらず、対外的に勝手に名乗っているのは事実です。

他の会社はどうなのかなとアンケートを取ってみたところ、以下の結果でした。

名刺に記載という条件がよくなかったのか、なんと定義されている会社が12%しかありませんでした。
エンジニアリングマネージャーというのは新しい考え方なのかもしれません。

一方、 Indeed で「Engineering Manager」を検索すると十数万件ヒットします。
新しい考え方というより、日本では認知されていないだけかもしれません。

外資系や海外で働いている方は、エンジニアリングマネージャーがどのように定義されているのか、コメントをいただけると嬉しいです。

Engineering Manager Meetup #4 で Job description の話をしてきた #em_meetup

f:id:dskst9:20190202220351p:plain

Engineering Manager Meetup #4 に参加してきました。

engineering-manager-meetup.connpass.com

「em_meetup から生まれる!? Engineering Manager Job description」というタイトルで発表をしてきました。本記事では、プレゼンでは時間が無くてお話しできなかったことをまとめました。

em_meetup から生まれる!? Engineering Manager Job description

エンジニアリングマネージャーの Job description を作ろう!
というプロジェクトの成果報告でしたが、 Job description は完成していなかったので、こんな課題があるよということを話しました。

Job description はこれからどうなるのか

今後はコンピテンシーモデルも検討されると記載していますが、どうなんでしょうか。 調査をしていたところ、興味深い資料が見つかりました。

「The End of the Job Description」
名前の通り、 Job description が終わると。

提言されていることは、従来の Job description ではなく、役割やコンピテンシーへ注目するべきと。人事制度で言うと役割等級制度になっていくのでしょうか。

Job description は能力に制限をかけてしまう!?

そうなんです。職務が明確ということは、やらなくても良いことがわかります。
ミスマッチを防ぐという効果がありますが、人の成長、Y理論で考えると制限になることが予想されます。

これは実際に、自分の業務以外はやらないという文化になっていったのではないでしょうか。 日本は職能資格制度により成長をしてできないことをできるようにしていく、という考え方なので潜在能力が発揮される環境だったのかもしれません。

外資企業の求人から見れる Job description も明確な職務が書かれていないことが見て取れました。
これは意図的に書かないようにして、職務を制限しないようにしているのではと予想しています。

コンピテンシーモデルを適用するのか?

プレゼン内ではコンピテンシーにはあまり触れませんでしたが、今後は意識する時がくると感じています。

コンピテンシー・モデルの開発と活用 をご一読いただきたいです。
コンピテンシーディクショナリなどのコンピテンシーが、好業績者とどう紐づくかを調査してそれを評価に紐づけていくと提言されています。

コンピテンシーモデルの一番の課題は「抽出のコストと寿命の短さ」だと考えています。

一方で、どのようなコンピテンシーがというのを抽出するのは非常に難しいことです。その割にその職務の寿命というものは短いものです。 コンピテンシーモデルが適用され運用されるのは、まだまだ時間がかかりますが、無視できないものとなります。

人事制度との深い関わり

Job description は人事制度と密接に紐付いています。
等級制度というものがあり、職務等級制度で Job description が使われていました。

  • 職務等級制度
  • 職能資格制度
  • 役割等級制度

職能資格制度では、 Job description は不要です。 よって、会社によっては作る必要はないかと思います。

時代の流れは純粋な職能資格制度が減って、役割等級制度や職務等級制度を混ぜた形にシフトしています。
そのため、 Job description はなんらかの形で使われることになっていきます。

しかし、等級制度をベースに、採用、評価などが展開されているため、本当の意味で Job description を理解するには人事制度の理解が必要になってくるというわけです。

今回の発表を通して感じたこと

Engineering Manager 共通の Job description を作ることはチャレンジでしょう。
職務というものだとミクロの話になってしまうので、具体的に書けば書くほど共通ではなくなります。

Job description をもっと抽象化したものや、 Job description の材料となるものを作るのか、今後コミュニティで考えていきます。

参考文献

エンジニアリング組織の文化ができるまでの3年間の軌跡

メリークリスマスイヴ!
この記事は Engineering Manager Advent Calendar 2018 の24日目の記事です。

私 (@dskst9) が3年前、アスクルという会社のエンジニアリングチームにJoinしてから、エンジニアリング組織の文化がどのように作られていったのかというお話です。

これは、私自身のアクションと、エンジニアリングチームの一人ひとりがアクションしたことを織り交ぜて書いています。誰かがアクションし続けることで、会社は変わり続けることができるということを感じてもらえると幸いです。

この記事が伝えたいこと

  • どんな会社でも変えることができる
  • 組織を変えたいなら自分自身でアクションする
  • 組織がアクションを続けると習慣となりそれが文化になる

そもそもどんな会社

むかし

3年前は、全社員比でエンジニアが 1% もいない会社でした。(5年前は0人…!!)

エンジニアリング組織の文化どころか、「エンジニア?何それ、おいしいの?」という状態。「外注すればいいじゃん」「本当に必要なの」というような感じでした。

(吉幾三がエンジニアだったら)こんな歌が聞こえてきそうです。

ハァ Gitも無ェ チャットも無ェ
Macもまったく使って無ェ
Wikiも無ェ ツールが無ェ
Excel毎日ごーりごり

そこへ、エンジニアが20名ほど Join(私も含む) して、組織が大きく変わっていくことになりました。

いま

さきほどの歌のようなことはなくなり、そこそこモダンな環境に変わったと思います。 何よりも組織としてエンジニアの立場が認められて、エンジニア側から組織に対して発信し、受け入れられるようになりました。

そして、エンジニアリング組織の文化というのが少しずつできていることを感じています。

ふりかえる

どのようなフェーズでどんなことをやってきたか、タックマンモデルにはめてふりかえってみます。

タックマンモデル

心理学者 B.W. Tuckman が唱えたチームビルディング(組織進化)モデルです。
チームは形成されただけで機能し始めることはなく、チームは形成後、混乱を経て、期待通り機能するようになります。 各フェーズを「Forming」「Storming」「Norming」「Performing」「Adjourning」と呼び、下図のように表現されています。

f:id:dskst9:20181224174138p:plain

Forming(形成期)

メンバーはお互いのことを知らない。また共通の目的等も分からず模索している状態。

3年前、20名ほどのエンジニアが Join した時期です。
当時はIT部門の1チームとしてエンジニアリングチームがありました。

20名程が短期間で入社したので、お互いを知らない、組織からも認知されていないというカオス状態でした。
この頃のエンジニアリングチームは、案件だけで繋がっていたような気がします。

  • 社内でのエンジニアの認知度が低い、信頼されていない
  • よって、エンジニアから組織への声が通らない

やったこと

社内のたくさんの人にエンジニアリングチームを信頼してもらうにはどうしたらいいのだろう?

まずは、社内の信頼を積むべくエンジニアリングチームとして案件へのコミットに全力を尽くしました。

内製エンジニアの形成期フェーズでは、案件で結果を出すことが一番でした。 目に見えてリリースが早くなることで、「エンジニアってすごいのかも」という認知が広がりました。

また、エンジニアリングチームを認知してもらうために、広報、法務、総務などの部門にも積極的に関わるようにしました。理由を作ってまで、とにかく話してみるということを続けました。

これは、影響の輪を広げて増やすということを考えていました。影響の輪の詳細は記事にまとめています。
dskst9.hatenablog.com

しかし、急に信頼されるということはなく、小さな信頼の積み重ねが次へと繋がっています。活動を1年くらい続けてやっと信頼が少し広がっていきました。

Storming(混乱期)

目的、各自の役割と責任等について意見を発するようになり対立が生まれる。

今から2年前、エンジニアリングチームができて1年が経つ頃です。
小さなエンジニアリングチームは部となり、何個かのチームが存在していました。

組織では少し認知が広がってきたところ、エンジニアリングチームの中は混乱期に突入していました。

  • 各エンジニアリングチームが何をしているのかよくわからなかった
  • 個人個人が何を思って何を目指しているのかわからなかった

やったこと

1on1 を始めたのはこの頃です。
上司とやり始めたことがきっかけで、そこから半年くらいかけて全エンジニアリングメンバーにまで広がりました。

同時期に Scrum を導入し始めました。
これは、モダンな開発を経験してみようという勢いで始めましたが、チームでの会話が増えたということはとても大きかったです。

1on1, Scrum など、個人個人の会話が増えたことにより、チームが何をしていて、個人が何をしているというのを理解したと思います。会話によって混乱期を乗り越えたのかなと。

また、この年からアイデアソン/ハッカソンを年1回やるようになり、今も恒例行事になっています。

失敗したことももちろんあります。
社内で小さな勉強会を開いたのですが、これが大失敗でした。
自分の想いだけで開催して、誰もついてこれずに1回で終了してしまいました、まさに混乱期(笑)

Norming(統一期)

行動規範が確立。他人の考え方を受容し、目的、役割期待等が一致しチーム内の関係性が安定する。

今から1年前、エンジニアリングチームができて2年が経つ頃です。
エンジニアリングチームとしてはお互いを知ることができて、チームとしてチャレンジしていこう空気になっていました。

  • エンジニアリングチームとしてのアクションをやり始めた
  • 他部門から信頼されの意見が通るようになった

やったこと

プロダクトともっと向き合うべく、 LeSS の導入がチャレンジングで面白かったです。

コンポーネントチームがフィーチャーチームになることで、エンジニアの技術領域も広がり、新しいコミュニケーションも生まれました。
しかし結果としては、フィーチャーチームを作りきれず、残念ながら LeSS チームは解散しました。

インセプションデッキ、ポストモーテムをして、プロジェクトとしっかり向かい合おうという取り組みもやりました。とくにインセプションデッキはプロジェクトの同じゴールを見ることができて、効果が大きかったように感じています。

個人的に一番嬉しかったことは、社内の勉強会を開催できたことです。(この時期になってリベンジできました)
今度はたくさんのエンジニアが参加してくれて、今では月1回の恒例行事になっています。

この時期から技術ブログを立ち上げる相談を広報などとはじめました。

Performing(機能期)

チームに結束力と一体感が生まれ、チームの力が目標達成に向けられる。

そして、今年です。
1年間いろいろとありましたが、エンジニアリングチームの影響の輪が大きく広がりました。

会社の中でもエンジニアリングチームが一目を置かれるようになっており、社内への技術的な提案や改善を推し進めることができるようになりました。エンジニアも外と交流するようになってきました。

  • いろんな人からさまざまなアイデアやアクションが生まれた
  • エンジニアリングチームが外へと踏み出した

やったこと/やっていること

びっくりしたことに、月1勉強会から派生して週1勉強会が自然発生しました。
混乱期の失敗を思うと、他のエンジニアから勉強会が生まれた瞬間は感無量でした。
さらにさらに、月1勉強会にエンジニア以外の他部門の人も参加してくれるようになりました…!

勉強会の他にも、会社の技術ブログが開きました。
たかがブログですが、開設し、更新を続けることというのはこの時期だからできたと感じています。

社外勉強会を自社で開催することもでき、とにかくアクションをし続けていました。

そしてこれから、
エンジニアバリューを作りビジョンを浸透しようとしたり、
OKR でプロダクトにフォーカスしようとしたり、
新しい挑戦を始めているところです。

文化を作るということ

「Forming」「Storming」「Norming」「Performing」とフェーズをなぞってきました。 「Forming」では存在しなかった習慣が、いま存在を感じて、この習慣こそが文化だと思っています。

文化は作れるものであり、作るのはそこにいる自分自身含めたみんなです。
アクションしたことがずっと続くことで習慣が生まれ、習慣が続くことでそれは文化になっていくと思っています。

おわり

文化を作っていくということも EM の大事な仕事ではないかと思っています。

これを意識すると、明日起きる誰かの小さなアクションが文化の芽となっていくことに気づくかもしれません。

おまけ

この軌跡をエモいストーリーにまとめて話したことがあるのでリンクしておきます。

Engineering Manager Meetup #3 - 番外編 OST風懇親会 - #em_meetup

Engineering Manager Meetup #3 に参加してきました!

f:id:dskst9:20181104163356p:plain

EMの魅力をたくさんの人に伝えればと思い、 EM Meetup のレポートをしていきます。

また、この記事は write-blog-every-week(毎週ブログを書くぞー!というコミュティ)の write-blog-every-week Advent Calendar 2018 - Adventar の18日目の記事でもあります。

Engineering Manager に興味がなくても、読んでもらえると嬉しいです。

イベントの内容

engineering-manager-meetup.connpass.com

今回は Engieering Management に関わる方々からのプレゼンテーション + OST風懇親会(※1) という流れでした。

※1 OST(オープンスペーステクノロジー)風懇親会とは?「話したいテーマについて話したい人同士が話せる懇親会」を目指す、今回初めての試みです。以下のような流れを想定しています。

1.参加者の皆様から話したいテーマを募る
2.テーマごとに懇親会のテーブルを分ける
3.各々が関心のあるテーマのテーブルへ集まる
4.意見交換する

今回の記事は番外編

OST懇親会は非常に良かったんですが、ディスカッション内容が残らないのはもったいない!
ということで、プレゼンの内容ではなく番外編 OST風懇親会の内容をまとめます。

私が参加したテーマは「Engineering Manager の役割を再定義する」です。

Engineering Manager の役割を再定義する

さて、ディスカッション内容の前にどのようなテーマだったのか、@yunon_phys さんのプレゼンテーション資料です。

さらに詳細は @yunon_phys さんのブログ記事にまとまっています。

yunon-phys.hatenadiary.com

OST風懇親会でディスカッションする

乾杯をして早速ディスカッションをしました。
(酔っ払っておりあまり覚えていないので、変なことを書いていたらご指摘ください!)

テーマ席には @yunon_phys さんと @hiroki_daichi さんがおり、 EMFM の収録みたいでしたw

f:id:dskst9:20181216224050j:plain
EM定義ディスカッション1

まず、話に上がったのがテックリードとEMの違い。
違うようでとても似ていることもある、マネジメントもやるがこの定義はどうすれば良いのかということ。

エンジニアのためのマネジメントキャリアパス にもあるように、テックリードもマネジメントをするというのが共通認識です。 組織や規模によって内容は異なるので、一概にはこれだとい言えないというのが悩ましいです。

そこから話は、キャリアパスの話へと広がっていきました。
キャリアパスとして、テックリード、EMの最終形とというイメージも存在するようです。

  • テックリード -> CTO (コーポレート・ガバナンス)
  • EM -> VPoE (執行責任)

しかし、これらの役割と等級が混ざって認識されてしまうため、みんなの認識が異なってしまいます。
CTOだから技術をする、VPoEだから採用をすると分けられてしまうことがありますが、別にCTOが採用をしてもいいし結局はその組織での組織設計が大きく関わってくるのです。

ラインマネージャーは例外をキャッチすると考えると、複数のラインがあるよりもシンプルだと考えることもできます。

f:id:dskst9:20181216223912j:plain
EM定義ディスカッション2

議論は、ホワイトボード二枚目へと。 具体的な組織設計の例を元にディスカッションが進みました。

コンポーネントチームごとにEMがいたり、プロダクトごとにEMがいたりとさまざまな形がありました。
コンポーネントチームから、フィーチャーチームになった組織は共通してリエゾンオフィスを作っていました。 しかし、EMの組織上の役割などはやはり別々でした。

そんな時、以下をごちゃ混ぜにするからわからなくなってくるのでは?という意見がありました。

  • 職責
  • コンピテンシー
  • マクロな組織設計

なるほど。確かに、職責とコンピテンシーが混ざって考えてしまいますね。
組織設計上の役割とかもごちゃってしまいます。

これを整理して、さらにプロダクトの性質も整理することでEMの定義ができるということです。
また、それぞれの組織に合った定義があり、さらにそれは分岐しているというのも考える必要があります。

と、ここで時間終了になりました…!

答えは出たのか?

1つの答えにたどり着くというのはないと思っていましたが、そのとおりで答えは大きく広がりを持っていました。

このディスカッションを通じで、依存するものが何かというのが整理できたのはとてもよかったです。

さいごに

プレゼンも素晴らしかったですが、今回はOST風懇親会のディスカッション内容にフォーカスしてみました。

とても有意義な時間を過ごすことがでましたので、次回参加したいですね。 イベントでお会いした皆様、ありがとうございました!

おまけ

プレゼン資料一覧

番外編という記事ですが、プレゼンもとてもよかったのでリンクします。

今回のイベントで登場した書籍

たくさんの本が紹介されていました。
プレゼンの中、Twitter(#em_meetup)から集めて来たのでリンクします。

書籍じゃないものもご一緒に。

さいごに、印象に残った一言で締めます。

それでは、よいEMライフを!