アルパカログ

カスタマーサポート (CS) とエンジニアリングを掛け算したい CRE (Customer Reliability Engineer) が気になる技術や思ったことなど。

「エンジニアリング組織論への招待」は誰にとっても必読である

少し前に話題となった「エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング」をようやく読み終えたので内容をまとめておきます。

304ページとなかなか読みごたえのあるボリュームですが、エンジニアであるかどうかを問わずエンジニアリングに関わる組織のマネージャーには必ず読んで欲しい内容です。

例えば次のような例があります。

f:id:otoyo0122:20180610160258p:plain

数々の現場を見てきた皆さんは「あるある!」と思ったのではないでしょうか?

もちろんこの不可解な開発速度の低下についても明快に説明してくれています。

本書はチームリーダーやマネージャー向けの内容を多く含みますが、1, 2章の内容は誰が読んでも役立つでしょう。特に、初めて誰か (新卒やインターンシップなど) を導く役になった人にとってメンタリングは必須のスキルです。

なお、このまとめは私にとって響いた部分だけを切り取っているので、興味を持たれた方はぜひご自身で手にとってください。きっと多くの発見があると思います。

少し長くなりますが、それでは行きましょう!

Chapter 1 思考のリファクタリング

エンジニアリングとは?

この問いに対して明確な答えを出すのはきっと難しい。にもかかわらず、本書ではシンプルに表現されています。

エンジニアリングとは、曖昧なアイデア、曖昧な指示を明確な仕様に落とし込むといったように、

「曖昧さ」を減らし、「具体性・明確さ」を増やす行為

であり、同時にまた企業における組織とは、市場や顧客などあらゆる不確実なものに対し、

不確実なものを確実なものに変化させる「処理装置」

である。

私たちは不確実性を減らすことに従事していたのですね。

具体的で細かい指示 vs 抽象的で自由度のある指示

同じ成果が得られる2つの組織があるとして、一方は「具体的で細かい指示」が、もう一方は「抽象的で自由度のある指示」が必要としましょう。

もちろん後者の方が強い組織であることは明白ですが、さて、それは何故でしょうか?

「具体的で細かい指示」が必要な組織は、

  • 指示を出す人の能力に依存する
  • スケールしない
  • 不確実性の削減量が小さい

というデメリットが挙げられる。

このような「具体的で細かい指示」が必要な組織はマイクロマネジメント型と、「抽象的で自由度のある指示」でも動ける組織は自己組織化された組織と呼ばれる。

マイクロマネジメントという言葉は悪いマネジメントという文脈でよく用いられますが、「具体的で細かい指示」を出している時点で、組織が削減する不確実性が小さいからだったのですね。

上司が自分の仕事を評価してくれない

私たちはしばしばコントロールできないものをコントロールしようとしてストレスを感じてしまいます。

まずはコントロールできるもの・できないものがあるということを知ることが先決です。

本書では次のような例が挙げられています。

上司が自分の仕事を評価してくれないとき、コントロールできないものは、

  • 上司の自分に対する内心での評価
  • 上司の評価基準

といったように「他人の内心」である。一方、コントロールできるものは、

  • 上司の評価基準を詳しく聞くという行動
  • 上司の評価基準に合わせた自身の行動の変化
  • 上司を変えるための異動などの行動
  • 自分の仕事を上司に詳しく説明するという行動
  • 自分自身の思いを上司に知ってもらうための行動

いったように「自分の行動」である。

コントロールできるものは変化を観測できるものでなければならない。

「コントロールできるもの」を操作し「観測できるもの」の結果を見ることが、あなたが前進するためにできることだ。

私たちはつい「あの人は要領が悪い」とか「あの人はやる気がない」といった曖昧な決めつけをしては悩んでしまうので、何がコントロールできて何が観測できるのかということは常に意識しておきたいですね。

Chapter 2 メンタリングの技術

メンタリングとは?

メンタリングやそれを行うメンターという言葉は誰しも聞いたことがあるでしょう。

私はこれまでメンターに対して「若手の指南役」くらいの認識しか持っていませんでした。

本書では具体的に次にように説明されています。

メンタリングは、知識のある人はない人に対して、上から押し付けるような教育方法ではありません。対話を通じて、メンタリングする人の思考力を一時的に貸し出し、思考の幅を広げていくことで、その人の歪んだ認知を補正し、次の行動を促し、成長させていく手法です。

また、メンタリングは成長を促すテクニックが必要であるため、単に年長者というだけでうまくいくはずがないのである。

ふむ、ただ単に不足した知識を与えるだけではないというのが読み取れます。

メンターの仕事

個人の成長を階段に例え、メンタリングにおいてメンターはメンティに次のことをする必要があると言います。

  • 階段を認識させる
  • 壁に梯子をかける
  • 階段を登りたくさせる

何か課題があっても本人は上を見ているのでなかなか気づかないもの、「階段があるよ」よりも「足元は大丈夫?」と聞く方が効果的である。

自分が相手の立場に立ったときにどう感じるか?どうして欲しいか?という想像や思いやりに基づく深い洞察がメンタリングにおいては大事なのかもしれませんね。

メンタリングにおける心理的安全性 (Psycological Safety)

心理的安全性とは、Google が2012年の行った調査において、チームの生産性と最も強い関係性のある要因として挙げられたもので、「対人リスクと取っても問題ないという信念がチームで共有されている状態」や「自分のキャリアやステータス、セルフイメージにネガティブな影響を与える恐れなく、自分を表現し働くことができること」だそうです。

本書ではメンタリングを効果的にするためには次の状況を作り上げていく必要があると言います。

  • メンティの弱さ・メンティの失敗を開示してもらう
  • 自分の弱さ・自分の失敗を開示する

これは「どんなダメなところを見せても、関係性が破綻することはないという確信」をメンティに抱いてもらう必要があるため。

しかしこれは難しく、年月が必要に思える。

この期間を短くするためにもメンターは「メンティ自身の存在を認めている」というメッセージを発し続ける (アクノレッジメント: 承認) 必要がある。

心理的安全性が闊達な議論を促進するのも、お互いの失敗の開示が難しいことも容易に想像できますね。

Chapter 3 アジャイルなチームの原理

アジャイルの目的

アジャイルは今や当たり前のように聞くようになりました。

アジャイルといえばスクラムやスプリントといった手順に関するワードを思い浮かべてしまいますが、本書によるとアジャイルは手続きではなく方法論なのです。

つまり、「ソフトウェアをどのように作るか?」はアジャイルの主眼ではありません。

中略

「ソフトウェア開発を行うチームをどのように構築していくか?」がアジャイルの目的と言えます。

ゆえに、一部のアジャイル開発に無理解な人々が言うように、アジャイル開発が大規模開発においては不向きであるという考え方は誤解である。

正直なところ私もアジャイルについてスクラムやスプリントなどといった手続きのイメージばかりが先行し、アジャイルについて無理解でした。

Chapter 4 学習するチームと不確実性マネジメント

エージェンシースラック

エージェンシースラックとは、あなたが誰かに仕事を依頼したとき、依頼者に「嘘をついてしまった方がトクだ」と思わせ適正よりも高いコストを支払ってしまった際の差額のことを言います。

つまり次のような取り組みは、エージェンシースラックを生まないためであると本書は説明しています。

経営者は労働者を監視しようとしたり、労働者がしっかりと成果を残せたら、給与やインセンティブ報酬の形で提供することで「サボるほうがトクだ」と思わせない環境づくりをしようとします。ストックオプション制度などもその一例です。

また、労働者側もエージェンシースラックが生まれないように、自身が持つ情報を開示するなど情報の非対称性を解消するために支払うコストのことをシグナリングコストという。

エージェンシースラックが起こり得るような状況はよくありますよね。だからこそシグナリングコストを支払ってでも、情報発信やアピールをしていきたいですね。

Chapter 5 技術組織の力学とアーキテクチャ

何が組織の生産性を下げるのか?

我々は薄々勘付いているのではないでしょうか?本書では次のようにきっちりと説明されています。

生産性が高いことを情報処理能力が高いことと定義する。

このとき個人の情報処理能力の総和が組織全体の情報処理能力とはならないことに注意が必要である。

なぜなら、人間は目的や思惑を含めた完全な情報伝達ができないため、人数が増えるほどコミュニケーションの失敗が発生し、コミュニケーションコストが発生するためだ。

そのため、誰がどのような人とどれだけコミュニケーションをとるか組織設計する必要がある。

私たちはコミュニケーションコストが組織の生産性を下げていることは気付いていました。だからこそ、どのようにコミュニケーションが取られるのかという組織設計は重要なのです。

システムはそのシステムを作る組織の構造に似る

いったいどういうことでしょうか?私は最初意味がわかりませんでした。順を追って見ていきましょう。

コミュニケーションコストは組織が離れているほど大きくなる。

ある機能追加を考えたとき、開発者はどうやって効率的に開発を行うかを考える。

すると開発者は知ってか知らずか、コミュニケーションコストが大きい (組織が離れた) 開発を回避して、コミュニケーションコストが小さい (組織の近い) 開発を重点的に行ってしまう。

このようにしてシステムに組織構造が反映されてしまうのである。

いかがでしょうか?意外ですが、言われてみると納得いく部分もある気がしますね。

技術的負債の正体

冒頭で紹介した不可解な開発速度の低下の理由として聞かれる技術的負債とは一体何でしょうか?

私たち技術者はもはや手が入れにくくなってしまった複雑なシステムのことを指して「技術的負債」と言ってしまいますが、経営者にとってはどのように見えるのでしょうか?

本書ではこのように説明されています。

経営者ではない多くの人々にとって「負債」とは「放っておいてはいけない」「定期的に返済すべきもの」といった「借金」のイメージがあるが、経営者にとってはそうではない。

経営者にとって負債とは資本という意味合いもあり、利子率の低い借り入れなら有利なので積極的に借り入れるべきという心理がある。

技術者の「技術的負債を返済したい」という提案が、経営者の首を縦に振らせない理由の1つはここにあったんですね。意外でした。

そして技術的負債の正体はいったい何でしょうか?

本書ではジェンガで例えられています。

ゲーム初期段階でのジェンガは、簡単にブロックを抜き出したり、積み上げることができます。このとき、ゲームはスピーディに進んでいきます。ところが、ゲームをしばらく続けると、バランスを取るのが急激に難しくなっていき、テンポがゆっくりとなっていきます。

中略

様々な要件の変化によって形作られたジェンガは、徐々に不安定に、積み上げるのが難しく時間がかかるようになります。これが開発が遅くなる現象とよく似ています。

システムの中身を知っている技術者は、複雑になってしまった構造を一度再構築して、さらにスピーディに高く積めるようにしたいと考え、経営者に「技術的負債が溜まっていて返済しないといけない」といったコミュニケーションを取るのである。

経営者からしてみれば「負債」の意味合いも違うし、「技術的負債の返済」と言われてもどういうものか想像もできないから、互いにストレスが溜まる原因となってしまっていたのですね。


感想

まとめてもかなりの分量になってしまいました。

サブタイトルの「不確実性に向き合う思考と組織のリファクタリング」の通り、不確実であること・わからないことは誰しも怖いことであるという認識を持つことが第一歩です。

本書が伝えたいことの本質はそういった自己の弱さの認識と他者への思いやりなのかもしれない、そう私は感じました。

著者の広木さんはミクシィに在籍していた時期があり、私とも在籍期間が被っていたのですが、ほとんどお話しすることがなかったので、もっとお話を聞いておけばよかった、惜しいことをしたなという気持ちですが、本書で得られたことを忘れず心理的安全性の高いチーム作りを心がけたいと思います。

こちらもあわせてどうぞ

alpacat.hatenablog.com