はじめまして。プラットフォームチームの高山です。
この記事は カンム Advent Calendar 2024 の18日目の記事です。
最近読んだ本がなかなか興味深かったので、ちょっとご紹介できればと思います。
「技術者・研究者のための 技術者倫理のキホン」と言う本です。
この世の中、様々な方の研究があり、それに付随する形で技術の発達・進展があります。そして、それを実装していく際に「倫理」みたいなものは大変大事だなぁと思っています。
エンジニアとしても「それはちょっと…」みたいな企画・仕様に出くわす時はたまにあります。その際、自分がその気持ちをきちんと共有し、線引きをすることも大事な仕事だと思っています。改めて知識を整理する上でも、この本を読んでみることにしました。
全体的にはタイトルどおり、技術者が持つべき倫理観について様々な視点から書かれているのですが、ここでは「4章のモラル」について抜粋して書きたいと思います。 ただ、この章の内容は倫理観というより、チームとしてどのようにしていくのが良いか、というところに繋がる感じだったので、その点を念頭に置いてお読みくださいませmm
モラルには8種類ある
そもそもモラルとは、手元のMacに付属しているスーパー大辞林に
道徳。倫理。また，人生・社会に対する精神的態度。
とあります。
そのモラルを、この本では「〜であってはいけない」という意味で以下の8つ示しています
利己主義：他人よりも自分を優先し、個人的な利益を追求すること
自己欺瞞：自分の言い訳を信じ込み、現実を歪めて自己を欺くこと
意思薄弱：正義や正しい判断を実行する勇気が欠け、他人の意見に流されること
無知：知識や知恵を得る努力を怠り、適切な判断を下すことができないこと
自己本位：他人の視点や意見を無視し、自分だけの立場や利益を優先すること
狭い視野：物事の一面のみに固執し、全体的な視野を持たずに判断すること
権威追従：自らの判断力を放棄し、権威や上司の意向に従うこと
集団思考（浅慮）：集団内の価値観や意見を優先し、独自の判断を怠ること
田中和明. (2023). 技術者・研究者のための 技術者倫理のキホン. 秀和システム. p.52
このように8つのモラルが挙げられているのですが、このうち、利己主義〜権威追従までの7つは自分自身のお話です。 自分が何か行動をしよう（した）時に、このような事に陥っていないか？陥っているとしたら、上のモラルと照らし合わせてどのようにギャップを埋めて行けばいいか？を心に置きつつ、自分の改善を少しづつでも続けるのが大事だなと思います。（とはいえ、人間なので難しい面はいっぱいありますが💦）
ただ、8つ目にある「集団思考（浅慮）」に関しては自分自身だけではありません。集団（組織 or チーム）全体の話になってくると思います。
集団思考（浅慮）とは何だろう？
みなさんも経験があるかもしれませんが、組織やチーム内で意思決定をする際、一人ひとりは冷静に考えられるはずなのに、なぜか全体ではおかしな方向に進んでしまうことはないでしょうか。
これが「集団思考（浅慮）」と呼ばれる現象です。組織の結束力が高まるほど、メンバーは内輪の雰囲気に流され、十分な検証や異なる意見の考慮を省略してしまう傾向が強まってしまうことです。
主な特徴として、下記のような事があげられています。
過大な自己評価とオールマイティ幻想：集団内では、組織やグループに対する過大な自己評価や、自分たちの判断力があらゆる状況に対応できるというオールマイティ幻想が広がる。
集団への自己弁護と外部への偏見：集団内では自己弁護が行われ、集団外部への偏見が生じることがある。他の意見や視点を排除し、集団内の考えが優越的であると信じ込むことがある。
組織の均一性の維持：集団浅慮の集団は、組織内での均一性を維持しようとする。外れた意見や行動がないかを監視し、集団の結束を保つために誘導することがある。
代替案の不考慮と情報の偏り：集団内では、代替案を考慮せず、目標や対策の選択肢の危険性を無視することがある。情報の収集が不十分で、偏りのあるデータを元に判断がされることがある。
事態に対する計画の不足：集団思考の状態では、非常事態に対する十分な計画が策定されず、適切な対応ができない可能性がある。
田中和明. (2023). 技術者・研究者のための 技術者倫理のキホン. 秀和システム. p.68
エンジニア視点で集団思考（浅慮）を考える
先ほどの特徴として挙げられている事をエンジニア視点で考えた時に、どこかあてはまる事はないでしょうか？
あくまで個人的意見にはなりますが「全てそのまま」はあてはまらずとも、形を変えて1つ、ないしは2つは経験としてはあるのでは？と思っています。
インフラ寄りの例にはなるのですが、よくありがちな例として
- 障害発生時の1次対応が、思い込みからあらぬ方向にいってしまう
- 作業手順や障害対応手順などのドキュメントに関するレビューが機能していない（レビューによる指摘がされない、もしくは指摘しづらい）
- 外部の人から指摘を受けた改善すべき点に大きな抵抗力が出てきてしまう
というようなことがあるかなと思います。
もちろん、上記の例において、だれも悪意はもっている訳ではないと思います。ただ、そのような場合でも意図せずとも発生することはあると思います。
できるだけ集団思考（浅慮）を避けるには
ではでは、どのようにすれば、集団思考（浅慮）から避けれるのでしょうか？
個人的には「Team Geek ―Googleのギークたちはいかにしてチームを作るのか」で書かれているHRTの原則が大事だと思っています。
- H(Humility：謙虚）
- 世界の中心は君ではない。君は全知全能ではないし、絶対に正しいわけでもない。常に自分を改善していこう。
- R(Respect :謙虚)
- 一緒に働く人のことを心から思いやろう。相手を1人の人間として扱い、その能力や功績を高く評価しよう。
- T(Trust:信頼)
- 自分以外の人は有能であり、正しいことをすると信じよう。そうすれば、仕事を任せることができる。
Brian W. Fitzpatrick (著), Ben Collins-Sussman (著), 及川 卓也 (解説), 角 征典 (翻訳). (2013). Team Geek ―Googleのギークたちはいかにしてチームを作るのか. オライリージャパン p.15
この原則の上で、心理的安全性を保ち、多様な意見を促す仕組みを作ることが集団思考を避けることに繋がると感じています。
たとえば、今まで、自分がよくやっていた取り組みとしては下記のようなものがあります。
- ファシリテーターのローテーション
- 非難なきポストモーテム文化（Blameless Postmortems）
- 障害発生後の振り返りは、「誰が悪いか」ではなく、「何が起こり、なぜそうなったか」を冷静に明らかにする場の空気づくりをしましょう。批判や個人攻撃を避けることで、メンバーは安心して失敗や問題点を共有しやすくなるかなと思います。
- 小さく始め、成功体験を積む
- 大きな改善提案よりも、小さく改善して、少しづつ成功体験を繰り返していくことで、多様な意見をどのように改善に結びつけていくのが良いか、という仕組み作りをチームで行なっていけるようになっていきます。
その組織（チーム＆メンバー）によって最適な取り組みは様々ですし、何が正解！というのは一概に言えるものではないです。が、ちょっとした仕組みと気遣いで、色々なことが少しづついい方向に変わっていくような取り組み方はきっとあるはずなので、一気に変えずに、一つ一つ少しづつ進めるのがいいかなと思います。
まとめ
当初の本のテーマから、少しエンジニアチームの例に目線を移した話になってしまいましたが、「技術者・研究者のための 技術者倫理のキホン」には品質管理からコンプライアンス、BCP、安全対策といったITエンジニアにとっても割と身近なテーマが扱われていますので、興味がある方は一度書店で手に取ってみて、年末年始の帰省など移動の際に読んでみてはいかがでしょうか〜
採用について
カンムではこんな僕たちと一緒に働いてくれるエンジニアを募集しています！ カンムテックブログを見て、少しでも興味を持たれた方、ぜひぜひ応募してください！一緒に働きましょう！
