本記事は、Engineering Manager Advent Calenderの１日目です。

はじめに

エンジニアリングマネージャ(EM)と呼ばれる職務を設置する企業が増えてきました。

私たちの主催したイベントEOF2019でも700名近い方に参加していだき、また多くの方にご協力いただき成功裏に終わることができました。

EM Meetup/EM.FMなどのムーブメントの中心の一翼を担わせていただき、その高まりを感じる一方で不安も感じます。このエンジニアリングマネージャという職務は非常に多岐にわたるケースが存在していますし、必要だとされるスキルもまちまちです。そして、多くの場合、その企業のステージや状況ごとに求めるものは違います。また、求めていることを明文化することすらされていないケースも存在します。

このことから、エンジニアリングマネージメント自体が一時的な潮流として消費され、消えていってしまうのではと危惧しています。このようなバズワードとしての消費は、同時にソフトウェアエンジニアリングの全体にとっての損失になるだろうと考えています。エンジニアリングマネージメントは、継続的なソフトウェア/デジタル技術関連するシビジネスを開発部隊にとって重要なスキルだからです。

また、もう一角としてプロダクトマネージャと呼ばれる職種を採用する企業も増えてきました。これは、ソフトウェアを構築する際に、「何を作るか」「なぜ作るか」を担当するような職務で、マーケット理解からソフトウェア要件に関する理解までと多彩なスキルが求められます。それに対して、エンジニアリングマネージャは「どう作るか」。そこには、「いつまでにつくるか」「どうやって品質と効率を上げるか」「どうやって人を育てるか」といった要素が入ってきます。

なぜ、なにを、どのようにつくるかは連続的なものです。ですから、複数の知識体系から必要に応じて適切な知識や手法を採用することが求められます。

このようなスキルセットは、ソフトウェア開発のための知識体系にも昔から存在します。

たとえば、BABOK/PMBOK/REBOK/SWEBOK/SQuBokなどの知識体系は、プロダクトマネージャやエンジニアリングマネージャにとって基礎的なスキルやフレームワークを提供してくれるはずです。

しかし、SoEに近い領域の自社開発を行うプロダクトマネージャやエンジニアリングマネージャにとって、SoR的な大規模エンタープライズのシステム開発の請負などに比べて、複数の関連会社とのプロジェクトのリソースマネジメントや調達管理をするスキルは内製開発ではほとんど必要とされませんし、複数のステークホルダー分析や、レポーティング文書や受け入れのための証跡管理のスキルも重視されません。

とても複雑な要件定義書を書いたり、1000や2000のユースケースを業務分析から漏れのないようにタスク出ししたりすることも、段階的に仮説検証するために小さくなったストーリーでは必要がないことが多いです。

むしろ、いかにして要件自体を小さくするかというマーケティング知識や仮説構築能力がプロダクトマネージャの本懐とも言えるでしょう。

ですが、ソフトウェア要件の書き方の訓練ができていないプロダクトマネージャでは、SaaSやソーシャルゲーム、決済サービスなど高度なトランザクションや複雑な機能要件を定義することができず開発の足を引っ張ってしまいます。

EMもPMも現在は残念ながら、異なる技術や知識体系から自社の今のステージにとって、必要なものを再構成して、適用していく能力が求められることになります。そうであるがゆえに難しく楽しいものではあるのですが。

本稿では、２つの新しいマネジメント職に向けての、この知識体系の柔軟な運用が可能になるような読書のガイドラインを作ることで、健全な業界発展の一助になればと思っています。

EMとはなにか

以前、１００名のエンジニアリングマネージャ(および技術系管理職)にアンケートを行い、どのような責務を任せられているのかということ分析しました。

得られた結果としては、ピープルマネジメントのスキルを中心にしながらも、プロジェクトマネジメント、テクノロジーマネジメント、採用活動、要求定義やプロダクトマネジメントといった多岐にわたる責務を担っていることがわかりました。

「弱めのEM定義」と「強めのEM定義」

このような事実から、EMの定義を１つに集約することは難しいことがわかります。

試しに、すべてのEMが求められるような共通部分だけをくくって、「EMの弱い定義」をつくり、関係部分のすべてをさして、より多くのことを求められるものを「EMの強い定義」を作るということを試してみましょう。

「弱めのEM定義」は、「エンジニアのマネジメントスキル」としてのピープルマネジメントスキルとテクノロジーマネジメントのスキルを持っているキャリアになります。

これだけでも、結構難しいものです。というのも、ソフトウェアエンジニアの業界変化ははやく、また転職市場も流動的ですから、常にキャリアになる仕事を提供したり、専門的な知見をもったエルダーとしてアドバイスを行う必要があります。また、その人のキャリアを見越した上での人事評価やスキル評価も難しいため、新しい専門職のチームには「弱めのEM定義」に当てはまるような役職をつけることが少なくありません。

たとえば、フロントエンドエンジニアやアプリエンジニアなど、１つの会社にサーバーサイドエンジニアほど多くいない時期がありました。このような時期に、それぞれのスペシャリティを考慮に入れながら、人事評価や適切なプロジェクト配置を行うことが現実的に難しいという事情から、EMを配置することも少なくありません。

最近では、データサイエンティストや、MLエンジニアなどのキャリアなどを考慮に入れるために専門家集団のエルダーとしてのEMという場合も増えてきました。

一方で、「強めのEM定義」ではどうでしょうか。ピープルマネジメントに加えて、テクノロジーマネジメントのみならず、プロジェクトマネジメントやプロダクトマネジメントの一部の要件定義能力などが求められることもあります。

つまり、SQCD(スコープ、品質、コスト、納期）という４つのトレードオフや課題をマネージメントしながら成果を出すことが求められます。非常に難易度の高い仕事と言えます。

さて、これらすべてに優れた人というのはなかなか採用できるものではありませんし、現実にチームにいなければ分業体制や協力しながら、これらの責務を成し遂げるしかありません。しかし、チームメンバーの期待するマネージャというのは、これらすべてを成し遂げてくれる人であったりします。

このギャップが「マネージャにスーパーマンを求めてしまう現象」です。
そうはいっても、マネージャ職なのだから「高い給料」をもらっていて、それくらいはできて当然だと考える方もおられるかもしれません。

ソフトウェア開発の現場では、技術的なスキルの高い個人に対しての給与制度も用意されていることが多く、マネージャよりも多くの給与もらっているメンバーを管理することもありふれたことです。（事実、私が初めてマネージメントしたチームは、ほぼ全員が私よりも給与が高い状態でした。）

日本の旧来企業が持っている給与の労使境界がはっきりした人事制度のもとでは、このような考えも成立したかもわかりませんが、ソフトウェアエンジニアの働くチームではこのようなことはなかなか成立しません。

実際に「強いEM」定義と「弱いEM」定義が採用されるケースはどのような違うがあるかというと、チームのタスク型ダイバーシティの高さに由来することが多いです。

タスク型ダイバーシティとは、同一のチームの中にどれだけいろいろなスキルの人が存在するのかを指します。

タスク型ダイバーシティが低いとマネージャは、その専門職の経験値の高い人を当てる傾向があります。誰が何をやっているのかをはっきりとわかるため、マネジメントがしやすいです。一方で仕事全体のスコープが、市場そのものと接するというより、会社内を顧客とした仕事になりがちです。そのため、短期的な目標に関してのコミットメントに対して意識が弱くなるといったことが起こります。一方、その専門性を発揮して内部人材の育成を強化したい、自社でのキャリアを形成できるようにしていきたいというフェーズに適しています。

タスク型ダイバーシティが高いとマネジメントしているメンバーの専門職のスキルが全部わかるということはなくなってきます。でも、大筋わかっていないといけないので、様々なものが求められながらも、価値をとどけるために「強いEM定義」が求められるようになります。プロジェクトやプロダクトのプレッシャーが掛かるため、短期的な目標に対して目が行きがちになります。イノベーションや成果を生みやすい反面、ソフトウェア品質や人材育成から目が離れてしまうことがあります。

この際のEMは、プロジェクトと品質、文化などのトレードオフを見ながら適切な投資をする能力が求められます。

ですが、そうした場合、「専門職としての経験」を軸にマネジメントを行うことが難しくなるため、結果的にサーバント・リーダーシップや、コーチングなどを通じて、チーム全体が１つのミッションを達成するためのピープルマネジメントスキルが必要になってきます。

各種スキルと読書ガイド

弱いEMから強いEMにかけての、知識体系をまとめるとこのようになります。自分自身のキャリアや足りない部分などを見つめ直して、インプットするのに使えるとよいかもしれません。

また、それぞれのコアな知識を学んでいくと、学際的な領域にフォーカスがあたった知識が隠れていることが理解できます。

たとえば、ピープルマネジメントとテクノロジーマネジメントの境界線には、DevOps的な思想やツール群が見え隠れします。このトレンドを正しく理解するには、ソフトウェア品質とピープルマネジメントやチーミングについて学ぶ必要があるでしょう。

たとえば、プロジェクトにおける依存関係や不確実性について理解すると、交換可能なモジュールやオプションを組み上げて効率的なデザインを行うことのプロジェクトへのポジティブな影響やネガティブな影響を理解できるでしょう。

この他にも、隠れた共通項・学際領域が隠れており、別分野の知識があるのとないのでは理解の深さが異なってきます。

重要なことですが、全てを読む必要はありません

必要に応じて、段階に応じて「このような世界があるんだなー」と認識しておき、行き詰まりを感じたときに深堀りをしてみるといいかもしれません。

また各書のリンクは主にshort url作成のためにアフィリエイトリンクを用いています。それらに不快感をお持ちの方は、書名からの検索をお願いします
非アフィリエイトリンクを個別に作成してくださる編集リクエストもお待ちしています。

ピープルマネジメント

1on1/メンタリング

ピープルマネジメントの基本的所作である１：１のマネジメントスキルは、究極のところカウンセリングの技法や、精神科医の実践的治験によるところが大きい。実際の所作を獲得することを考えるとこういった書籍が最もわかりやすい。

ファシリテーション

１：１での行動変容をうながせるようになったら、会議の場でのファシリテーションからプロジェクトファシリテーションなどのステークホルダーの広い場所での行動変容を学んでいくと実際の仕事に活用しやすい。

チーミング

心理的安全性や目標をどのように維持・獲得・達成していくのかの関係性をバラバラに抑えてしまうと、目的と手段が転倒しやすい。なので、OKRなど目標管理と心理的安全性については、同じタイミングで読書すると理解が進む。

テクノロジーマネジメント

ソフトウェア品質

ソフトウェアプロジェクトの成否を決めるほど強い要素でありながら、しばしば理解が及んでいないことがあるのがソフトウェア品質に関する知識です。様々なファクトとデータ分析が積み重なっている分野でもあり、これらの知見はエンジニアリングマネジメントにとって必要不可欠と言えます。

XP/DevOps

XPの習慣とDevOps的なアプローチは、ソフトウェア品質のための、協調・創造の文化と自動化の技術、プログラミング的習慣によって構成されている。直接的なファクトが得られづらいが、実践を積み重ねることによって高度な技術チームを作り上げることができる。

SRE/モニタリング

ソフトウェア品質は、事前と事後の品質が存在する。リリース事後において発見されるバグというのは、ソフトウェアライフサイクルの中で非常に大きい割合を占める。以下にして、安定した運用を実現するのかという技術や文化、習慣の理解がないと、事前品質と事後品質のトレードオフやメトリクスが理解できなくなってしまう。

アーキテクチャ

継続的にソフトウェアの開発効率を維持し、バグの起こりにくい・起きてもクリティカルになりにくいといった性質を実現するためには、アーキテクチャの素養がなければならない。ソフトウェアプロジェクトマネジメントの場合、アーキテクチャやソフトウェア品質に関する理解があるとないとでは、打ち手の幅が全然変わってくる。モジュール化の理論は、プロジェクトマネジメントと同じく不確実性とオプションの数理で構成されていることがわかってくると、プロジェクトマネジメントとソフトウェアアーキテクチャの隣接点が浮かび上がってくる。

プロジェクトマネジメント

PMBOK

プロジェクトファシリテーションの知見やチーミングが理解できていると、プロジェクトマネジメントのプラクティスの理解が早くなる。PMBOKなどの知識体系はとても広い。ソフトウェアだけではないプロジェクトマネジメントの一般的な性質について理解してから、ソフトウェアに戻ってきたほうがポイントが抑えやすい。

不確実性分析・クリティカルパス

プロジェクト管理の手法の背後には、統計的な不確実性の取り扱い方や、依存関係の取り扱い方と言った統計数理と離散数理がついてまわる。自分たちがリスクという不確実性の管理を行っているという見方を広げていくと、プロジェクトマネジメントのレベルが一弾上がるはず。

CCPM

CCPMは、納期に向けてのプロジェクト管理でありながら、バリューストリームの最適化のToCなどの理論を背景に持つ管理手法。バッファを統合し、バッファの消費率でプロジェクトの健全性をチェックするなど、不確実性を見える化して進むプロジェクト管理の重要手法。

見積もり

ソフトウェアプロジェクトにおける不確実性の原因の１つは、見積もり誤差から生じる。この見積もりにというものについて、人々はどのような歴史を持ち、どのような手法を分析してきたかを理解するとソフトウェアプロジェクト管理の半分が手のうちに入る。

アジャイル/リーン

これまでのソフトウェアプロジェクト管理の流れから、どのようにしてスクラムやアジャイルなどの手法が生まれてきたかを理解すると、ポイントがおさえやすい。逆に最初からスクラムだけを学ぼうとしたり、リーンだけを学ぼうとすると躓くことがある。従来のプロジェクトマネジメントの知見を理解してそのうえにアジャイル開発を捉えたほうがいい。

CMMI

経験主義的チームの管理手法は、スクラムだけではない。ケイパビリティではなく成熟度モデルと経験主義的工数管理がCMMI/PSP/TSPなどの知識体系として存在したことを思い出していくと、よりソフトウェアプロジェクトマネジメントの理解が進む。

プロダクトマネジメント

ビジョンマネジメント/ビジネス分析

プロダクトマネジメントは、プロダクトの各フェーズごとに不確実性のジャンルが異なります。
顧客理解であったり、コンセプトであったり、ビジネスモデルであったり、デザインやマーケティングであったり。

多くの場合、フェーズと自分の得意分野がミスマッチしてしまっても、新しいステージでの学習が進まず成長が飽和してしまうことがあります。自分の事業のフェーズ認識とそのビジョン共有がプロダクトマジメントの最も難しいポイントです。

ソフトウェア要求/仮説検証

また、現在では単純だがWebメディアだけでなく、複雑な業務用件を満たした上で複数社に同じサービスを提供するようなB2B SaaS型/B2B2C型マッチングのサービスを開発していく企業が増えました。

これまで、画面仕様書をざっくり書いて伝わっていたことが、正確に要求を分析した上で定義していくことが求められるようになりました。また、まだ見ぬ複数の顧客に提供しても勝ちがあるかどうかが重要なファクターですから、仮説検証的に「最小限度の価値のある単位」に分割して、顧客の応答を求めていくような開発要件定義も必要になります。

このあたりは「開発キャリア型のプロダクトマネージャ」か「BizDevキャリア型のプロダクトマネージャ」で、スキルにギャップが現れるところです。

プロダクトマーケティング/プロダクトセールス

プロダクトマネジメントのフェーズが、PMFに到達する前後でセールスラインやプロダクトマーケティングがプロダクトマネージャの主な関心事になります。自社のセールスモデルかマーケティングモデルが、フィットしているかを検証しながら、グロースをすすめるための基礎的な知識をもつ必要があります。

これまで、0-1で開発チームとの時間を長く過ごしたプロダクトマネージャがマーケティングチームとつきっきりになるため、組織問題を生み出しやすい時期でもあります。

UXデザイン/ユーザビリティ

プロダクトマネージャとエンジニアリングマネージャにとって、デザインやUXの知識はプロダクトの成否を分けるほど重要な知識です。

デザイン的思考法とUIコンポーネントやユーザビリティ、総合的なUX

おわりに

繰り返しになりますが、すべての本を読む必要はありません。
マネジメントは様々なスペシャリストと対話をしながら適切な意思決定をしていくための機能です。
なので、スペシャリストとの会話ができるような各分野への関心とリスペクトを持ち続けることが最も重要です。