「エンジニアリング組織論への招待」をチームに活かす


1. 今回読んだ本


タイトル: エンジニアリング組織論への招待
著者: 広木 大地
発行所: 技術評論社

2. 概略


このnoteは、エンジニアリング組織論に関する知識を、私の会社にいかに活かすかをまとめたものである。
note用に体裁を整えていないため、一部読みにくい部分があるかもしれない。

3. 知識・方法論


3.1. エンジニアリング

  • エンジニアリングとは、不確実性を排除し、具体性・明確さを増やすことである。

  • ビジネスにおける課題には、100%の回答は存在しない。目指すべきは、おそらく確からしい答えを導くことであり、そのためには不確実性の排除、すなわちエンジニアリングが求められる。

3.2. 論理的思考

  • 論理的思考とは、事実から結論を導く思考方法である。

    • 仮説1: 人間は死ぬ。

    • 仮説2: ソクラテスは人間である。

    • 結論: ソクラテスは死ぬ。

  • 恐ろしいのは、事実が100%事実でないなら、結論は正しくない可能性があること。

    • 論理的思考はあらゆるところで用いられているが、その仮説の確度を確かめることが大切である。

3.3. アジャイル開発

  • ビジネスにおける意思決定は、不確実性の排除が基本となる。そして不確実性の排除に最も貢献するのは経験である。

  • アジャイル開発は、高速に開発サイクルを回すことで、経験を積む手法と表現できる。

    • 例: MVP(Minimum Viable Product)

3.4. 仮説思考

  • 少ない情報から仮説を立てて、検証することである。

    • 情報確度が低すぎる状況において、一時的に理論を飛躍させることで糸口を見つける。

  • 例: PDCAサイクル

    • PLAN: 少ない情報から、大胆に仮説を立てる。

    • DO: 仮説を確かめるために行動する。

    • CHECK: 仮説が正しかったのかを検証する。

    • ACT: 検証結果を整理し、次の仮説に活かす。

3.5. システム思考

  • 全体を構成する要素を最適化することは、必ずしも全体の最適化には繋がらない。

  • 意見の対立とは、事象の側面に対する局所最適が原因である。

    • A: コストと売上を重視するため、直近の利益しか見ない。

    • B: 継続性を重視するため、中期的な視点しかない。

    • C: 退会率を気にするため、長期的な視点しかない。

    • 上記施策は、良し悪しを比較することができない。

  • 考えるべきは、全体のフィードバックシステムである。

    • 原因: アプリが使いやすい。

    • 結果: ユーザーが増える。

    • 拡張のフィードバック: 資金が増えて、アプリを使いやすくする資金になる。

    • 抑制のフィードバックは、短期的な利益が見えても避けるべきである。

3.6. 情報の非対称性と限定合理性

  • 情報の非対称性とは、同じ目的を持った集団で、何かの情報を片方の人が知っていて、もう片方の人が知らない状態である。

  • それぞれが、それぞれの情報の中での限定的な合理性を主張することで、不協和が生じてしまう。

  • 対策としては、情報の透明性の担保が挙げられる。

    • 情報の透明性とは、意思決定と意思決定に関わる情報が、整合性を持って伝達される環境のこと。

3.7. ペアプログラミング

  • プログラムを書くドライバーと、書き方を考えるナビゲーターに分かれてプログラミングする手法。

  • 個別にプログラミングするのと同程度のコード量を生成でき、バグ発生率が改善される。双方の成長につながる利点もある。

    • 実際のプログラミングでは、コードを書いている時間より考えている時間のほうが長いことが起因しているのではないか。

3.8. メンタリング

  • メンタリングとは、自ら考える人材を作るテクニックである。

    • 自立型人材: 自ら問題を発見し、解決することができる。

    • 依存型人材: 問題を与えられてから考える。

  • 自立型人材と依存型人材を分ける要素は、上司と部下の期待値である。

    • 「ここまでは自立的に考えてほしい」「ここまでは自立的に考えるのが自分の仕事だ」という期待値が一致しなければならない。

    • 人は、与えられたと思っている役割に対して、自分の思考を閉じてしまう習性がある。与えられた以上の階層レベルに対して、思考しない。

  • 信頼関係の上に期待値を調整し、自立的行動に正のフィードバックを与えることで、拡張のフィードバックシステムを作ることが大切である。

  • メンター/メンティの関係性の条件(HRT)

    • Humility(謙虚): お互いに弱さを見せられる

    • Respect(敬意): お互いに敬意を持っている

    • Trust(信頼): お互いに自身の成長期待を持っている

  • メンティに階段を登らせるためには、以下のことをする必要がある。

    • 階段を認識させる: 「階段がある」と伝えても当人が認識していなければ転ぶまでわからない。「足元は大丈夫?」と伝える方が効果的。見えていない課題に自ら気づかせる方が積極的に解決できる。

    • 壁に梯子をかける: 大きな飛躍が必要なときは、梯子をかけることで小さな達成感を感じさせる。これが拡張のフィードバックシステムにつながる。

    • 階段を登りたくさせる: 「おもしろいこと」でなければ登らない。

  • 他者説得よりも自己説得

    • 答えではなく、質問を通じてメンティにとっての思考回路の盲点となっている部分を外していく。

    • メンティ: 「今のプロジェクトは残業時間が多すぎるのに、プロダクトオーナー(ビジネスと技術を結びつけ、何を作るべきかを決定する役割)はそれを問題だと認識していない」

    • メンター: 「プロダクトオーナーはそれを問題と思っていないと、どうして判断したの?」

    • メンティ: 「話し合っていないことが問題だと気づきました!」

  • 悩ませるのではなく、考えさせる

    • 悩むとは、行動が伴っていない状態であり、生産性が全くない。

    • 考えるとは、次にすべきことがわかっている状態であり、生産性がある。

    • メンターは、考えさせる、すなわち問題解決の道筋を提供すべきである。同時にメンティが悩んでいるとき、すなわち行動できていないときは、悩みを聞き出し気づきを促し、考えさせる必要がある。

    • 「問題を解決してあげよう」ではなく「モヤモヤしていない問題に変換してあげよう」

    • メンターは、メンティの課題を自分の課題として捉えてはいけない

  • メンタリングの基本スキル

    • 傾聴: 相手の立場に立って話を聞き、共感を表現する

      • 真正面に座らないというテクニック

      • 共感とは、相手の個人的な価値観を理解するだけでいい。同感とは違う。

    • 明晰化: 問題を客観視する

      • 感情と癒着した問題は一般化する傾向にあるため、どこが問題なのかをはっきりさせる。

    • 可視化

      • 事実と意見を分ける。

      • 小さな問題に分割する。

    • リフレーミング: 認知フレーム(人間の認知は、何かに対してフォーカスされている。例えば、身の回りの青いものという認知フレームを持つと、発見できる)を外すこと

      • 「一旦、この前提がなかったらどうなりますか?」でリフレーミングを促せる

3.9. 心理的安全性

  • 心理的安全性が高いとは、対人リスクを取ることができる状態である。

    • 例えば相手の悪いところを指摘することは、関係性が悪化する可能性があるため、対人リスクを取ることである。

    • 人が対人リスクを取れるのは、「関係が終わってもいい」と思っている時か、「関係が終わらない」と確信を持てる時である。

    • 心理的安全性を高く保つには、「関係が終わらない」と確信を持てる環境を作る必要がある。

  • 心理的安全性が高いと、以下のような影響が出る(これらは対人リスクを伴う)。

    • 率直に話すようになる

    • 考えが明晰になる

    • 意義ある対立が後押しされる

    • 失敗が緩和される

    • イノベーションが促される

    • 組織内の障害でなく目標に集中できるようになる

    • 責任感が向上する

  • メンタリングへの活かし方

    • メンティが自分の弱さを見せる環境を作る必要がある。

    • そのためには、「弱さを見せても関係が壊れない」という心理的安全性を担保する必要がある。

    • メンターが自ら弱みを見せることで、心理的安全性を高めることができる。

    • ストーリーテリング: 自分の体験を負の感情も踏まえて赤裸々に語る。

  • YouメッセージとIメッセージ

    • Youメッセージ: なんであなたは遅れたの?

    • Iメッセージ: 連絡がなかったから、心配したよ

    • 自分が思っていることを率直に伝える

  • 当たり前のことを意識してやる

    • ちゃんと挨拶する

    • 無視しないで話を聞く

    • 相手に感謝を伝える

    • 気にかけて話しかける

    • 自分本位でなく相手本位で話をする

4. 思ったこと


4.1. 経営

  • ビジネスにおける課題は、判断のための情報が不足しているために発生している。エンジニアリングを通じて不確実性を排除することで、課題解決ができる。

  • 施策は、フィードバックシステムで比較すべきである。

  • 情報の非対称性は完全に排除する必要がある。なぜそうなるのかのロジックを説明するだけでいい。

4.2. 思考法

  • 「何か言い切れない気がする」という時は、論理的思考の仮定を疑う。

  • PDCAサイクルは、容易に検証できなければ意味がない。

4.3. テクニック

  • 調査は不確実性を排除する方法であり、効率的に課題解決を行うことができる。

  • ChatGPTとのプログラミングは、ペアプロなのでは?

  • メンタリングは、「問題を解決してあげよう」ではなく「モヤモヤしていない問題に変換してあげよう」と考える。

  • Iメッセージは、「自分の感情を相手につたえる」という高等な技術。子供とかIメッセージ多用している気がする。

5. チームに活かせること


5.1. アジャイル思想での導入検討

  • アジャイルとは:

    • 小さな開発から得た経験を、次の小さな開発に活かす

  • 導入概要:

    • 一旦やってみて、微妙ならすぐやめるという思想を持つ。

  • 導入効果:

    • 導入ハードルを下げつつも、不必要なものを削除して身軽にできる。

5.2. レトロスペクティブの導入

  • レトロスペクティブとは:

    • アジャイル開発手法「スクラム」の振り返りフェーズのこと。短い時間の中で、今回のスプリントの反省点等を共有する。

  • 導入概要:

    • 定例の最後の10分間で、「今日うまく行ったこと」「今日うまくいかなかったこと」「次回に活かすこと」を振り返る。

  • 導入効果:

    • 定例自体の生産性を向上させられる

  • 導入への懸念:

    • 形骸化してしまって、無駄に時間を取るだけになる。現在の環境では、明示的に時間を取らなくても、話し合えているという視点もある。

5.3. ディスカバリー・レトロスペクティブの導入

  • ディスカバリー・レトロスペクティブとは:

    • 「プロダクトの問題点を定期的に振り返る」という意味を持った造語

  • 導入概要:

    • 月1回程度の広いスパンで、「プロダクトの現状」「プロダクトの課題点」「ネクストアクション」を決定する

  • 導入効果:

    • チームという視点で、複雑に絡み合った悩みを考えられるように整形できる。

いいなと思ったら応援しよう!