エンジニアの多様性を活かすには
「多様性の科学」という本がめちゃくちゃおもしろかった。多様性とは何か、なぜいま重要視されているか、多様性のある組織を作るにはどうすればよいかといったことが、事例をまじえてわかりやすく説明されている。多様性is何？という状態から読み始めたが、これ１冊でかなり理解は深められたように感じる。
一番大きい学びは、単に「多様である」だけではなく「多様性を活かせる」環境を作らなければその価値は発揮されない、という点だ。そもそも多様性が重要視されている理由は、変化の激しい世の中なので様々な視点を持つことがリスク回避につながるし、新しい発想はこれまでにないコラボレーションから生まれやすいという点にある。なんだけれど、心理的安全性の無く若い人が発言しにくい環境にあったり、部署ごとに壁がありコラボレーションが生まれにくい環境にあったりすると、多様な人材がそろっていても意味がなくなってしまう、とのことだ。（超意訳）
ここでは書籍の内容をふまえて、エンジニア組織において多様性を活かすためにすべきことについて考えてみた。
エンジニアの多様性を活かすには
技術力を権威にしない
「副操縦士らは機長に意見するより、死ぬことを選んだ」。人間の心はヒエラルキーに多大な影響を受ける。たとえ生死に関わる状況でも、無意識のうちに自分を押し殺してしまう。
書籍「多様性の科学」では、機長が副機長に意見が言えずに事故にいたってしまう航空事故の例が紹介されている。機長が権威となり、大事なことが言えなくなってしまうというものだ。
エンジニアの場合、役職や年齢といったラベルよりも、技術力の高さや合理的であるかどうかを重要視する人は多いと思う。それが純粋なリスペクトであればよいが、ときに権威になってしまわないかは注意したほうがよい。例えばコードレビューのときにレビュアーとレビュイーとで技術力に差があるときに、レビュー内容が無条件に適用されてしまう、といったことがないだろうか（書籍では信頼は盲目につながるとある）。
権威に感じるかどうかは心理的な問題なので、コントロールしづらいところだが、権威につながる行動はルール下で制限できるように思う。 コードレビューであればレビュアーは断定的な表現を使わない、レビュイー自身が責任をもちコミットする、といったガイドラインを作成するのは有効だと考える。
エンジニアへの偏見を取り除く
一番わかりやすいのは１９７０年代のオーケストラの例だろう。この時代、アメリカ（に限らず各国）のオーケストラは団員のほとんどが男性だった。入団審査をする側が「一般的に見て、男性のほうが演奏がうまい」と思い込んでいたからだ。それを「実力主義による採用」だと主張していた。
どちらかというとエンジニアではなく人事やディレクターなどのエンジニアにかかわる人に伝えたい内容だが、エンジニアへの偏ったイメージをお持ちでないだろうか？エンジニアに独特な人が多いのは認めるが、事実とは異なるイメージを持たれていることも結構ある。最近だと、朝早くに働くエンジニアをみて驚いている人がいたが、エンジニアはみな夜型というわけではない（弊社、フレックス制のため早朝から働く人もいる）。
35歳定年説？
ある程度年齢を重ねるとマネージメントできるようにならないと、という風潮はエンジニア界隈でも感じるが、最近は IC (individual contributor) という言葉も定着してきているように、ミドルやシニアに分類される年齢でもマネジメントロールを持たずに個人開発者として活躍する道は一般化してきている。身近にも40歳を超えてバリバリ実装しているエンジニアはざらにいる。
文系より理系のエンジニアのほうがすぐれている？
エンジニアへの向き不向きはあるのは認めた上で、文系・理系といった学歴分類自体はエンジニアを評価するうえで役に立たないように思う。エンジニアの素養を持ちながらもその時の興味や都合で文系に進んでいる人もいるし、文系で学んだ知識が分野横断的にエンジニア業務に役立っている場面を何度も見たことがある。
女性はエンジニアに向いていない?
女性エンジニアが男性より少ないのは事実だが、優秀なエンジニアかどうかはまた別の話で、優秀な女性エンジニアの方をたくさん見てきた。エンジニアに男性のイメージがある理由の一つに、3K（きつい、厳しい、帰れない）と呼ばれていた過去の労働環境の悪さがある。体力的に不向きというのは以前はあったかもしれないが、今は労働環境はだいぶ改善されてきた。
上記はぱっと思いつくものをあげたのでわかりやすいが、書籍でも「無意識のバイアス」と表現されているとおり、本当の偏見は自分では気づきにくい。 書籍では、採用時の無意識のバイアスを取り除く方法として、履歴書を「目隠し」する（性別などの情報を非表示にする）方法が紹介されている。（実験手法だったかも）
リモートワーク下でもユニットを超えた交流をもつ
１９８６年にジョージ・ルーカスから買収して新たに設立したピクサー・アニメーション・スタジオのデザインを考える際、彼はトイレを１カ所だけにすると決めた。しかも場所はアトリウム〔エントランス付近に設けられる明るい大空間〕の中だ。つまり社員はそれぞれのオフィスから出て、そこに集まってくる。一見、非効率だが、そのおかげで偶然の出会いが起こり、第三者の視点を得るチャンスが増える。「みんな誰かと出くわすんだ」とジョブズは言った。
一般的なプロダクト開発組織の形状は、機能別組織、目的別組織、マトリクス組織の３つのいずれかに分かれると思う。こういったユニット分けは、コミュニケーションパスを制限し認知負荷を下げるためにあるが、あまりにユニットが分かれすぎると交流が固定化し、コラボレーションの機会がなくなってしまうので、意図的に離れた人をつなぐ設計をすべきだと思う。
いま、オフィス回帰の流れもあるが、とくに開発業務はリモートワークとの相性がよく、リモートメインを継続するIT企業は多いのかなと思う。 リモートワーク下のなかで、ユニットをまたいだ交流点（ピクサーのトイレ）をどこに設けるかは悩ましい。
単に雑談会を開くというのはやりがちだが、経験上「さあ！雑談しよう！」というノリだと盛り上がらないことが多い。 絶賛模索中ではあるが、ユニット横断での課題を話し合うOSTであったり、設計技法などの共通項の多い領域の勉強会といった、業務にかかわるテーマで横串で集まる機会を設けるのは有効だと感じている。
エンジニアの認知的多様性に目を向ける
性別、人種、年齢、信仰などの違いは、「人口統計学的多様性」としてよく分類される。本書ではこの種の多様性のほかにもう１つ、ものの見方や考え方が異なる「認知的多様性」についても検討する。
「認知的多様性」とは、様々なバックグラウンドの違いによりもたらされるものの見方や考え方の違いのことである。書籍によれば、同質化した組織だと盲点に気づかず大きな失敗をしてしまうことがあり、そういった事態を避けるには、この「認知的多様性」のある集団であることが多様な視点を持つ点で有利だとある。
エンジニアにおける「認知的多様性」とは、個々のエンジニアリングへのスタンスの違いと言い換えられる。例えば、エンジニアには悲観的な人もいれば楽観的な人もいるし、システムの厳密性にこだわる人もいればユーザーの利便を最重要視する人もいる。
一方、「人口統計学的多様性」の方は、スキルセットや経験年数と言えそうだ。それ自体は多様性と無関係ではないが、採用やチーム組成を考える際には、表層上のスキルセットの組み合わせだけでなく、個々のエンジニアリングへの考え方や特性にも目を向けるのが重要だと感じた。
エンジニアの特性を表したもので、「エンジニア風林火山」というのがある。*1
- 風のエンジニア：迅速な設計・実装によって開発を加速させる
- 林のエンジニア：突発的なトラブルにも冷静に対処できる
- 火のエンジニア：新しい技術や方法を積極的に導入する
- 山のエンジニア：厳密なエラーチェックと堅牢なプログラミングで成果物の安定性を高める
この分類はあくまで一つの視点にすぎないが、こういったエンジニアならではの特性分類について知っておくのは良いと思う。
ここまで真面目に書いたけれど、ぶっちゃけ多様性というものの抽象度が高すぎて、今の開発チームがいい感じに多様なのかどうかはさっぱりよくわからない。
ただ、自分自身が多様性によって助けられてきた、という感覚はある。マネージャーをしているといろいろ考えているつもりでも特定の視点が抜け落ちることがあって、そんな時は「メンバーの気持ち分かってます？」とか「これ私にはさっぱり意味がわかりません」とか、どぎつい愛のある直球の意見をもらうことで「はっ」とさせられてきた。
多様性のある組織のマネージャーは、結構しんどいのかもしれない。。（愛ある直球をくれた方々にはめちゃくちゃ感謝しています）
