Management 3.0 勉強会 2020 #1 : (1) マネジメント 3.0 とその必要性 1 回目の概要
マネジメント 3.0 やアジャイルマネジメントとは何か? : 本ページ
アジャイルマネジメント : アジャイルソフトウェア開発のカウンターパート
組織がアジャイル開発をするなら、チームリーダーや開発者のマネジャーはアジャイルマネジメントを理解する必要
どういう人が読むとよいのか?
アジャイルになりたいマネジャー
マネジメントを学びたいアジャイル開発者
ソフトウェア技術マネジャーやソフトウェア品質マネジャー、プロダクトオーナーのキャリアパスであれば Level 2
アジャイル技術コーチのキャリアパスであれば Level 4
信岡の感想
情報量が多くていいんだけど、主張が分かりにくかったりして読みにくくはある
話のつながりとかがわかりづらかったりする
ので、構造的にとらえて勉強会で概要を話し、本書を読む際のガイドなどになればと思っている
マネジメント 3.0 とその必要性 (前書きと 1 章)
マネジメント 3.0 とは
本書での定義
マネジメント 1.0 : 階層構造的
組織はトップダウン式に設計・マネジメントされて、力はごく少数のものの手にある
マネジメント 2.0 : 流行
組織の設計をより良いものにするが、これらはトップダウン式のままであり、根本解決はしていない
マネジメント 3.0 : 複雑性
組織はネットワークであり、マネジメントとは部門と利益ではなく人と人同士の関係が主である
マネジメント 3.0 は、アジャイルマネジメントのためのモデル
Martie : Management 3.0 のモデルらしい。 かわいい怪物っぽい? 6 つの目がそれぞれ Management 3.0 で大事な観点 (本書ではそれぞれ知識と実践が語られる / 勉強会では毎回 1 個ずつ扱う)
物事は単純ではない (1 章)
計画したとおりに物事が起こるはずだ、という考えの根っこにあるもの
ソフトウェア開発でもソフトウェアの動作について設計し、計画し、予測できる
しかし、因果決定論だけでは不十分
ソフトウェアプロジェクトの機能、品質、時間、リソースの完全な組み合わせを予測することができない
いつ、どの程度、顧客獲得できるかどうかといったことも予測できない
大きな数 (例えば同時に大量の出来事が起こる) と複雑性を混同する人もいるが、大きくなくても複雑にはなりうる
我々は複雑性より因果関係を好みやすい
人間の脳は、すべてのものに目的と因果関係を見出すように設計されているようである
物音がしたらそこに誰かが居ると思い込む、みたいな、因果関係の過大評価
人の危機回避のために発達した特性、みたいな話をどこかで見た nobuoka.icon
私たちの直線的な思考は、世界を、単純な原因と単純な効果を持つ、簡単に説明可能な出来事に満ちた場所と見なす
特にエンジニアや技術的な思考を持った人は、制御の概念に影響を受けやすい
アジャイルマネジメントへ (1 章)
マネジメント上の因果関係により、マネジャーは、慎重な事前設計と綿密なトップダウン計画により、求める成果を生み出す要因を探すことになる
組織が大きくなればなるほど、システム全体を分解および再構築して、目的の目標を達成するための労力が大きくなる
2 つの考え方
構成要素を理解することで、システム全体を理解できる、という考え
ある程度は有益だが、あらゆるところで使えるわけではない
全体論 (Holism) : システムの動作は構成部品からだけでは完全には決定できない、という考え 代わりに、全体としてのシステムこそがシステムがどうふるまうかを決定する
複雑性の科学者は、複雑性がこの 2 つを橋渡しすると考えている
「ハイパーリンクは電子によって構成されており、実際にはハイパーリンクは存在しない」 みたいな極端な考え方
貪欲な還元主義が真ならば、貪欲な還元主義者も本当には存在しないことになるよね
複雑なシステムは階層で記述でき、それぞれの階層はその一段下の階層の部品で記述できる (が、より下の階層の部品では記述できない) という中間的な思想
層ごとに新しく不可逆な特性を持つこともありうる
全体論の見方でも階層的還元主義の見方でも、システムのより低い層に原因を求めても複雑系の全ての事象について説明ができるわけではない (どちらの見方も、各階層に新しく、単純化できないプロパティの存在を認めている)
階層システムのあるレベルについて全て知っている人が、そのシステムのより下位または上位のレベルについて扱えるわけではない
別種の知識が必要になるため
複雑系 (complex systems) のマネジャー (開発マネジャー、プロジェクトマネジャー、チームリーダー) に大きな影響がある
組織のマネジメントには人のマネジメント (マネジャーが扱うべきレベルより下位のレベル) とは別の技能が必要
(開発マネジャーやプロジェクトマネジャー、チームリーダーに人のマネジメントの技能は不要という話ではない)
詳細が漏れることもあるので、より低い層の知識が有用なこともある
アセンブリプログラミングについて知らずとも高級言語でプログラミングできるが、知っていると役に立つこともある
これらはほとんどマネジメントの責任
これこそがアジャイルマネジメントのための理論 (アジャイルソフトウェア開発に適するマネジメント理論) が必要な理由
マネジャーに役立つ理論 (1 章)
アジャイル環境のマネジャーを支援できる理論は存在するのか → ない
何十年にもわたって多くのマネジメント理論が提案されてきたが、それらのほとんどは科学的な意味での理論ではない
それらは理論ではなく技術 : 世界がどのように機能するかを説明するのではなく、問題や状況に対処するための (有用な) アドバイスを提供する
筆者は、ソフトウェアチームのマネジメントについての万物の理論 (すべてのソフトウェアチームの原則を説明し、それらのマネジメントをするための完全に統一されたモデルにより人々を助けるもの) を見つけようとしたが、できなかった
これは 16 章でも触れる話題
本書は、より良いマネジャーになることを支援する
どういうことを伝えるか
アジャイルな組織のアジャイルマネジャーとしての責任が何であるか
理論から日常の実践につなげるための多くの技術
一般的にはシステムは複雑であると認識し、チームをマネジメントする方法
予測可能性ではなく適応性に焦点を当てる方法
開発マネジャー、チームリーダー、CTO、ソフトウェア開発者であれば、大きな違いはない
結局のところ、私たちはみな、自分自身の周りの環境のマネジャーである
本書のモデルは、冒頭で説明した Management 3.0 モデルの Martie Management 3.0 モデルの詳細の前に、まずはアジリティと複雑性の基本を説明する