ビジネスに資するエンジニア組織の多様性とは
これは Engineering Manager Advent Calendar 2022 22日目のエントリです。
去年の Engineering Manager Advent Calendar 2021 では、 yoichitgy さんが下記エントリで多様性がプロダクト開発組織を強くする一般的な理由について説明しています。
このエントリを読んだ上で、多様性という言葉は抽象的かつ人によって幅広い解釈が可能であり、私自身EM(Engineering Manager)として組織運営や採用戦略を考える上でどのような多様性を重視すべきなのか、より具体的に言語化したいと思うようになりました。
そこで、このエントリでは "ビジネスに資する" "エンジニア組織の" 多様性とはなにかについての私の考えを書きます。
はじめに
このエントリで扱う多様性というテーマはセンシティブかつ人によって解釈にばらつきがあるため、あらかじめこの記事のスタンスを明言しておきます。
- このエントリに書かれている内容はあくまでnaopr個人の意見であり所属する組織を代表するものではありません
- このエントリではビジネス観点から多様性について考察するものであり社会課題や倫理、また企業広報の観点はスコープに含みません
- 筆者がWebサービスを提供する会社に在籍しており、このエントリはWebサービス企業のエンジニア組織を対象としています
また、このエントリを書くにあたって下記2冊の本を参考にしており、それぞれ『多様性の科学』、『世界最先端の経営学』と表記して引用します。
ビジネスに資する組織の多様性とは
エンジニア組織に限定せず、ビジネスに資する組織の多様性について考察します。
『多様性の科学』では、問題空間という概念やそれを満たす多様性について下記のような記述があります。
図1の長方形は、有効な概念や知識を示す領域だ。つまり、特定の問題解決やゴール達成に必要な洞察力、視点、経験、物事の考え方などがこの長方形につまっている。これは「問題空間」（problem space）とも呼ばれる。
取り組む問題が単純な場合は、1人でこの空間の「情報」をカバーできる。多様性は必要ない。しかし問題が複雑になると、1人ではカバーしきれない部分が出てくる。（中略）そこで見えてくるのが画一的な集団の危険性だ。同じような考え方の人々の集団は図2のようになる。
次の図3では、個人個人の賢さはこのセクションの冒頭に紹介した図2と変わらない。しかし集合知ははるかに高い。問題空間を幅広くカバーしている。複雑な問題に対処する際に、考え方の違う人々を集めるのが肝心な理由がここでわかるだろう。
多様性は高い集合知を生む要因となるが、それには根拠が必要だ。対処する問題と密接に関連し、かつ相乗効果を生み出す視点を持った人々を見つけることがカギになる。
『世界最先端の経営学』では組織パフォーマンスに影響を与える多様性とそうでない多様性についての研究結果が紹介されています*1。
学者の間でも大まかな一つの合意が形成されてきた、というのが私の認識です。それは「ダイバーシティーには二つの種類があり、その峻別が重要である」ということなのです。その二つとは「タスク型の人材多様性」と「デモグラフィー型の人材多様性」です。
「タスク型の人材多様性（TaskDiversity）」とは、実際の業務に必要な「能力・経験」の多様性です。（中略）「デモグラフィー型の人材多様性（DemographicDiversity）」とは、性別、国籍、年齢など、その人の「目に見える属性」についての多様性です。
（中略）過去の研究を集計したメタ・アナリシスから得られた事実法則では、組織に重要なダイバーシティーとはあくまで「タスク型の人材多様性」のことであり、性別・国籍・年齢などの多様性は組織に何の影響も及ぼさないどころか、場合によってはマイナスの影響を及ぼすこともあり得る、という結論になったのです。
『多様性の科学』と『世界最先端の経営学』の双方に共通する主張は、「ビジネス上取り組む問題と密接に関連する多様性は組織にとって重要である」ということです。
ビジネスに資するエンジニア組織の多様性とは
前章で得た「ビジネス上取り組む問題と密接に関連する多様性」をどうエンジニア組織に当てはめるべきか考えたとき、究極的には下記2軸で表現できるのではないかと思っています。
- 専門性
- タイプ
それぞれについて順に説明します。
専門性
専門性については詳しい説明は不要かと思いますが、Backend/Frontend/Mobile/Infra/QA(Test)/ML/... といった技術領域に関する能力や経験です、サービスを開発・運用するのに必要な技術領域をエンジニア組織全体で網羅している必要があります。
上記のような大まかな職能分類だけではなく、今まで経験したビジネスや開発してきたサービスの特性によって同じ職能の人でも得意とする領域が細かく異なります。
例えば、私は前職ではBackendエンジニアとしてソーシャルゲーム開発を行ったことで、短時間に急激にアクセスが増えるサービスで発生する問題やそれを防ぐためのキャッシング・DBスキーマ設計について経験があります。一方、同僚のAさんは同じBackendが専門ですがGCP(Google Cloud Platform)に明るく、Cloud TasksやCloud Pubsubを使った非同期処理の設計に詳しいです。
高負荷なAPIの負荷を下げようと思った時に私とAさんではぱっと思い浮かぶアプローチが違いますが、お互いの知見を持ち寄ることでより質の高いシステム設計ができます。これは専門性の多様性がうまく発揮されている例です。
タイプ
エンジニアの指向性を分類する方法として、「技術志向/プロダクト志向」や「ゼロイチ/運用」などいくつか言われているものがありますが、個人的にはプログラマー風林火山がしっくりきています。
上記エントリ内で示されている分類方法を引用します。
これらの分類は1人の中にいくつも同居し得るものですが、全てを満たすエンジニアはなかなかいないのでエンジニア組織全体やチームの中で偏りなくバランスよく満たしていることが理想的です。
ただ、0→1フェーズでは風のエンジニアがより重要であったり、10→100フェーズでは山のエンジニアがより重要であったりとプロダクトのフェーズによって優先されるエンジニアのタイプが変わることはあります。
おわりに
このエントリを読んで、「ビジネスに資するエンジニア組織の多様性とは」の結論がさほどビジネスの内容に依存していないことに違和感を覚えた方がいるかと思います。私もです。
例えば、ビジネスドメインに関する知識があったほうがいいんじゃないかという意見が出そうですが、ことエンジニアの業務として直接必要なのはそのビジネスドメインに必要なエンジニアリングとしての専門性であり、必ずしもビジネス自体の知識は必要ないんじゃないかと思っています*2。このあたりはぜひご意見いただきたいところです。
最後に、D&I(DEI)についてスタンスを表明している様々な企業の中で、私が一番好きなLayerX福島さんのエントリを紹介して終わりにします。「なぜ」「どんな」多様性を「なぜいま」受け入れるのかが完璧に言語化されていて素晴らしいです。
