[読書] エンジニアリング組織論への招待

#エンジニアリング組織論への招待 #マネージメント #メンタリング #アジャイル開発 組織論

読んだ本


エンジニアリング組織論への招待　～不確実性に向き合う思考と組織のリファクタリング

モチベーション

仕事上、チーム開発においてメンタリングやマネージメントのやり方、見積もりの方法などで「実践的な」知識を身に着けたいという気持ちがあった。
しがないラジオ ep.37で紹介されていて、実際にsp.84 で著者の広木さん本人の話をきいて、書籍を読みたいと思った。

かかった時間など

期間： 2021/5/16 〜 2021/8/14
読書時間：16.7 時間
やり方
- 電子書籍版で購入して、風呂中や寝る前、空き時間にちょこちょこ読む感じ

手短な感想

見事に招待された。
疲弊しきったマネージメントへのネガティブなイメージを払拭してもらい、新たな道への道筋を立ててもらった
エンジニアリングマネージメントの理論やノウハウの、現場・現実と理想の乖離を埋める本。腹落ち感を持って、マネージメントの方法を学べることができ、自分のものとして組織論を身につけるための道筋を立ててくれる
文章が読みやすい。知識体系を、分類・章節項立てして、手順やノウハウとして紹介するようなものではなく、必要な考え方を流れで説明してくれる。
読んで得した感じがする。読むか読まないかで仕事の進め方、考え方が大きく違いそう
アジャイル開発への理解については、シリコンバレーでの誕生した歴史的背景をベースにしたアプローチがすばらしかった。このやり方でないと依然としてアジャイルに対してとっつきにくい印象が変わらなかった可能性がある

この本を読む前のマネージメントに対する自分のイメージ

それまで持っていたマネージメント系の知識は、IPAの応用情報の試験勉強でざっくりと学んだ共通フレーム2013やPMBOK、大手SIerのISO監査を意識したウォーターフォール開発をベースの開発ルールなど。
これらに対する自分としてのイメージとしては「理想的にはそうすべきであるが、現場としては逆にツライ気持ちにさせるもの」だった。
具体的には、以下のような完全に負のイメージだった。
- 上(上司・経営層など)と下(現場レベルの担当者)との調整にメンタルを消費させられるもの
- 調整力＝言い回しなど、技術力ではなく「ヒューマンスキル＝対外的には可視化しにくいスキル」でやるもの
- 人との信頼関係の上で成り立ってくるものなので、信頼関係が構築できて、もしうまくいくようになったとしても「他のチームでは、信頼関係をつくるところから始まり、他では通用しないもの」
- うまくいったとしても上記の信頼関係が築けたかなので、「自分でないと仕事が回らない状態＝属人化になり、抜けられなくなる」
- 実績をつくっていくには、「かなりのメンタル力がないとできない」もの
- 上記のとおり、成果・スキルが一見可視化されづらいにも関わらず、かなり手数のかかる仕事なので、「そういう立場に＝その分の報酬をもらえるように」ならないかぎり、マネージメントの仕事は避けないようにしないと自分のタスクが回せない。
この本を読んで、これら↑が覆った。

ざっくりと理解したこと

Chapter1 思考のリファクタリング

エンジニアリングとは、不確実性を下げること。
不確実性の発生源は、２つ
- 通信不確実性：他人とのコミュニケーション
- 環境不確実性：未来どうなるか
不確実性を下げるには、情報を生み出す必要がある。そのために大事な考え方は３つ
- (1)経験主義
- (2)仮説思考
- (3)システム思考
(1)経験主義
- 実際に手を動かして情報を得ること。
- 不確実性を抱えたままにして議論するより、さっさと行動して潰す。
- 不確実性を最初に一つ消すことから、不確実性を下げるフィードバックループを始めるきっかけづくりができる。
(2)仮説思考
- 仮説を立てない上でのPDCAサイクルは、何を確かめようとしたのかがブレる
- 不確実性をすべて除去するまでやるのではなく、MVP(Minimum Viable Product)最小限の検証をして仮説が検証されてから投資していく
(3)システム思考
- 拡張のフィードバックと抑制のフィードバックを分析する
- 自分が他人が見ている視野、視座、視点がどうなっているのかで、ものを捉える
- 人間の性格ではなく、人の関係性に問題の構造を見出す
通信不確実性を下げるための心構え
- 情報の透明性は意思決定と、その意思決定に関わる情報が正しく伝わるように努力すること
- 伝わらなかったら、それは隠そうとしたのではなく抜けてしまったのだと、直接きいてみようという関係性をつくること
- 物事が完璧に理解されるはず！と完璧を求めて、回避したり攻撃した結果、エンジニアリングは失敗する

Chapter2 メンタリングの技術

メンタリングとは、メンターの思考を一時的に借りて思考の幅を広げることで、歪んだ認知を直すこと
エンジニアリングでは、人の不完全さの影響を減らす作業=コードレビューなどでメンタリングが使われるが、コードそのものにアイデンティティを広げていることが多いため、コードを書いた人に気づいてもらうようにするのが理想的
メンタリングの難しさは、「手取り足取り〜放任」どの程度がちょうどよいかだが、メンティの認知の歪みの度合いと自ら考える力の度合いからマネージメントする
- 与えられた役割のみに閉じてしまうコンフォートゾーン現象
- 逆に自立していろいろやって失敗してしまい、やっても無駄と思ってしまう学習性無気力現象
良いメンタリングは、自己効力感を得られるフィードバックループにして、自立させていく=コンフォートゾーンの快感より自己効力感の快感が上をいく状態にすること
解決策を直接提示するのではなく、質問によって、メンティの思考回路を正解に導く
メンターは、メンティの課題を自分の課題を思ってはいけない
メンティの手が止まってしまうときが学んでもらうチャンス。気づきを促して、考える＝行動するに変えてもらう
メンティの信頼を勝ち取るためのテクニック(1)：傾聴
- 不安や悩みを聴いてあげて、一度コップを空にしてからだと、話を聞いてもらいやすい
- 感情の共感を言動で表す：感情を表す言葉が出たら、それに関わる部分を抜き出してリピートする
- 相手の話の内容を可視化する：メモやホワイトボードに書き出すか、グラスや灰皿を人物や構造に見立てる
- 相手の話の盲点を探索する
メンティの信頼を勝ち取るためのテクニック(2)：可視化と明晰化
- 感情と事実を分離する
- 可視化した事実から、こまかな問題の焦点がどこにあるのかをはっきりさせる。一挙に大きな問題の答えをざっくりだそうとしない。
- メンティペースは、メンティにあわせて、メンティが主体で話してもらい、質問は直球で返さず、分解してみる。
- メンターの姿勢は、バグ調査時の環境周りや全体像の把握をするスタイル
メンティの弱さ、失敗をさらけ出してもらう＝心理的安全性が重要
メンティの信頼を勝ち取るためのテクニック(3)：アクノレッジメント
- 褒めるのではなく、アウトプットを理解して「感謝」する。理解した良い行動の具体的な内容を伝えるだけで良い。
- 承認の種類（存在承認、行動承認、結果承認）
- YouメッセージではなくIメッセージをつかう。あなたはなぜ遅刻したの？ではなく、私は心配したなど
- メンターからメンティに相談して、意見を求めてみる
メンティの信頼を勝ち取るためのテクニック(4)：ストーリーテリング
- 自分の弱さ、失敗を開示して、こういうふうに改善して成長したという話を出す
- つらいとか憎いとか感情をいれる。
- 価値観を共有する
- 返報性の原理＝メンティはそのお返しをしたいと感じるようになる。
メンティへのアドバイステクニック(1)：メンティが解決策は思いついているが、行動できない場合がある。
- 他の選択肢が不明確
- 比較軸が不明確
- 評価方法が不明確
メンティへのアドバイステクニック(2)：認知フレームに縛られている
- リフレーミングで認知しているものを変えてもらう
- 認知フレームのキーワードが発言されたら、その前提を問い直す

心理的安全性について

心理的安全性は、仲良しで何でも話せることではない。
結果としてチームの創造性や成長に至るための環境

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

アジャイル開発の歴史、誤解など

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

チームマネジメントにおいて、以下の不確実性をマネージメントする
- 方法不確実性：スケジュール予測と見積もりの方法
- 目的不確実性：要求と仮説検証の手法
- 通信不確実性
方法不確実性
- 制約スラックを削減するようにマネージメントする（リソース制約、依存制約）
- 経営層見積もりの数字の扱い方が重要。エンジニアとの情報の非対称性からエージェンシースラックが発生することが多々ある
- 当初立て計画どおりに間に合うかということよりも、スケジュール予測が収束するか？=不確実性の量をマネージメントする
目的不確実性
- 市場が受け入れるのかどうかを調べる上で、どのような機能をどういう順番でリリースするのか考える必要がある。
- ユーザストーリー単位で機能を分割する。
- 機能の分割の粒度診断はINVESTが有効
- リーンキャンバスでプロダクトの重要な性質を見抜く
通信不確実性
- スクラム開発での振り返り

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

生産性という言葉がよく使われるが、ソフトウェア開発においては情報処理能力を評価すべき
技術的負債の正体は、情報の非対称性。組織構成とシステムが乖離していると取引コストが大きくなり、非対称性が起きる。
組織構成とシステムは、同じものになる（コンウェイの法則）。逆コンウェイの法則でシステムに合わせた組織構成をする
マイクロサービスアーキテクチャ:ビジネス要件ごとにチームを組み、全レイヤーをチームが作るというやり方がある。導入のタイミングややり方は難しいが、市場の不覚醒がある程度下がってきたときに段階的漸進的変えていく。

今後の展望など

未だ『招待された』状態であることを認識。もっと学ぶこともあるし、活かせるかどうかは自分次第。
アジャイル開発については、「ケムに巻かれたような、あるいは宗教じみた印象」は解かれたので、本来スクラムガイドやリーン開発の基礎など学ぶべきことをちゃんと学べる気がした。
自社業務では、これらの考えかたはかならずしも他の社員に浸透しているわけではないので、まずは自分が置かれた状況とこの本で記載されていることをすこしずつ当てはめながら活用していきたい。
この記事をまとめながら何度も復習したが、知識が凝縮されているので、反復する必要があると感じた。学習が無駄にならないように、身につくまで学び直したい。

最終更新日: June 25, 2022