#Book
[[📒エンジニアリング組織論への招待]]
## 💭3章を読んでみて
- [[🗃️アジャイル]]は言葉は浸透しているにもかかわらず、人によってイメージするものが違っていたりして、[[🗃️アジャイル]]について議論すると空中戦になるイメージがあったが本章で[[🗃️アジャイル]]の意味が少し理解できた気がする。
- [[🗃️アジャイル]]は理想な状態([[🗃️不確実性]]を効率よく低減できている状態)であって、普段話に上がる手法や、[[🗃️スクラム]]はあくまでプラクティスでしかない。
- 大切なのは、[[🗃️傾聴]]と対話。
- [[🗃️目的不確実性]]と[[🗃️方法不確実性]]という概念を知っているだけで、不安な状態になった時に、これはどの[[🗃️不確実性]]が高いんだ？という問いを自分にできるし、ちゃんと頭に入れておきたい。
- [[🗃️プロジェクトマネジメント]]とプロダクトマネジメントの違いも勉強になった
- プロダクト開発においては、[[🗃️プロジェクト]]マネジメント(終わることを目的とする)のはしないようにしたい。
- プロダクトマネジメントの継続していくことを目的として取り組みたい。
- [[🗃️アジャイル]]の歴史も面白かった
- ヒッピー文化は好きなので、今自分が[[🗃️ソフトウェア]]開発の仕事をしていることが納得感があった
## 3-1 [[🗃️アジャイル]]はチームを[[🗃️メンタリング]]する技術
- [[🗃️アジャイル|🗃️アジャイル開発]][[🗃️アジャイル|]]はチーム全体に対して[[🗃️メンタリング]]を行い開発出力を向上させる方法論
- [[🗃️ソフトウェア]]をどのように作るか？は[[🗃️アジャイル]]の主眼ではない
- [[🗃️ソフトウェア]]開発を行うチームをどのように構築していくか？が[[🗃️アジャイル]]の目的
- [[🗃️アジャイル|🗃️アジャイル開発]]が必要とされた2つの理由
- [[🗃️ソフトウェア]]が大規模化・複雑化
- マーケットの[[🗃️不確実性]]に対応する
- [[🗃️アジャイル|🗃️アジャイル開発]]は3倍の成功率、1/3の失敗率
- 大規模な開発にこそ効果的
### [[🗃️プロジェクトマネジメント]]と[[🗃️プロダクトマネジメント]]
- [[🗃️プロジェクトマネジメント]]
- 対象となるプロジェクトの資源、資産、リスクを管理し効果を最大化する手法
- プロジェクトは、「はじめ」と「おわり」がある。
- 終了することが目的
- 計画駆動
- [[🗃️プロジェクトマネージャー]]は「スケジュール不安」を減少させるように取り組む
- [[🗃️方法不確実性]]
- [[🗃️プロダクトマネジメント]]
- 対象となるプロダクトの資源、資産、リスクを管理し効果を最大化する手法
- 終了しないことが目的
- [[🗃️プロダクトマネージャー]]は「マーケット不安」を減少させるように取り組む
- [[🗃️目的不確実性]]
- マーケット駆動
- 💭どっちがどっちかイメージついていなかったけど、この定義は、納得感ある。
- 💭そう考えると、ロードマップを作って計画を立てるけど、計画駆動に倒しすぎるのもよくない気がしてきた
- 現在は、目まぐるしく変化する市場環境や顧客ニーズに応えていく必要があるため、プロジェクト型からプロダクト型へ変化していった
- スケジュールとマーケットという2つの不安
- [[🗃️ウォーターフォール]] -> 計画駆動
- 初期の計画段階で[[🗃️目的不確実性]]をできる限り減らそうとする
- [[🗃️アジャイル|🗃️アジャイル開発]]では初期工程から最終工程まで[[🗃️目的不確実性]]と[[🗃️方法不確実性]]の両方に対してアプローチをする
- 定期的に顧客やマーケットとの齟齬を実験する。仮説に誤りがあれば計画自体を修正する
- [[🗃️経験主義]]的な態度
- [[🗃️方法不確実性]]へのアプローチ
- [[🗃️ウォーターフォール]]
- 完成品を要素分解して、小さなタスクに分解する
- そのタスクに対してどの程度時間がかかるのかマージンを設けて見積もりいつ終わるかを計算する
- [[🗃️アジャイル|🗃️アジャイル開発]]
- 最初期には大雑把に見積もり、実際の開発工程にどの程度進んだかという知見をもとに、推計する。それを繰り替える。
- **マーケット不安やスケジュール不安の両方を構成する大きな[[🗃️不確実性]]から優先的に対応するというのが基本的な思想**
- 💭これは納得感がある。
- チームに対する考え方の違い
- [[🗃️アジャイル|🗃️アジャイル開発]]は「チーム全体を[[🗃️メンタリング]]」するための方法論であって、開発方式ではない
- 開発方式に見える部分はその方法論の表面的な一部にすぎない
- [[📚2 メンタリングの技術]]を伴っていない場合は、望ましい効果を得ることは難しい
- どういうこと？
- [[🗃️メンタリング]]の最終目的が「セルフマスタリー=[[🗃️自己組織化]]」を得ること
- チームが高いゴール認識をもち、チーム自体がチームを[[🗃️メンタリング]]している状態
- 💭抽象的で難しいかも。あとで2章を読み返そう
### [[🗃️アジャイル]]をするな、[[🗃️アジャイル]]になれ
- NG -> Do agile(Be agileとはいうことができる)
- [[🗃️アジャイル]]は状態を指している
- [[🗃️自己組織化]]されていることを指す
- [[🗃️アジャイル]]とはどのような状態？
- [[🗃️情報の非対称性]]が小さい
- 認知の歪みが少ない
- チームより小さい[[🗃️限定合理性]]が働かない
- 対人リスクを取れていて[[🗃️心理的安全性]]が高い
- 課題・不安に向き合い[[🗃️不確実性]]の削減が効率よくできている
- チーム全体のゴール認識レベルが高い
### [[🗃️ウォーターフォール]]か[[🗃️アジャイル]]か
- [[🗃️アジャイル]]なチームのスコープ
- [[🗃️方法不確実性]] -> スケジュール不安
- [[🗃️目的不確実性]] -> マーケット不安
- [[🗃️通信不確実性]] -> 継続するチームマネジメント
- 💭 今のチームだと、[[🗃️方法不確実性]]はリードエンジニアが責務を持つし、[[🗃️目的不確実性]]はPOが担うし、[[🗃️通信不確実性]]は[[🗃️エンジニアリングマネージャー]]が担うみたいな感じになりそう
- [[🗃️アジャイル]]な方法論は、組織間の[[🗃️限定合理性]]と[[🗃️情報の非対称性]]の解消を試みるアプローチであると言える
## 3-2 [[🗃️アジャイル]]の歴史
- [[🗃️アジャイル|🗃️アジャイル開発]]は経営学
- 💭この辺りは流し読み
- [[🗃️SECIモデル]]と[[🗃️ダブル・ループ学習]]
- [[🗃️アジャイル|🗃️アジャイル開発]]は日米合作のコンセプト
- ハッカーカルチャーと東洋思想への憧れ
- ヒッピー文化 -> 東洋思想との出会い
- 禅: 瞑想、坐禅を通じた悟り
- 西洋文明的な合理的な理解よりも、基本的な型を繰り返し「プラクティス(練習・習慣・実践)」することによって、ある時全体的な理解を得て、「うまくできるようになる」「体感的に習熟する」という学習プロセスという学習プロセスこそ「禅」の重要な構成要素
- パーソナルコンピューターという思想実現装置
- 特定の権威を持たず、全地球規模で個人をつなぐコンピューターネットワークというコンセプトがヒッピーたちを社会に引き戻してく原動力となった
- -> ハッカー文化
- 中央集権的な権威を嫌い、個人の力で世界の階層構造をフラットに変革したいと考えているリバタリアン
### [[🗃️アジャイル|🗃️軽量ソフトウェア開発プロセス]]
- 従来の計画主義的な[[🗃️ソフトウェア開発]]プロセスと異なるプロセスが生まれた
- 共通項
- 人間性の尊重
- 組織学習の取り入れ
- システム論
- [[🗃️経験主義]]的
#### [[🗃️スクラム]]
- 振り返りのための[[🗃️フレームワーク]]
- 2つの学習ループ
- 開発現場の改善を促す、[[🗃️計画]]と、[[🗃️振り返り]] -> 「Howに関する学習ループ」
- 顧客に何を届けるかを検証する -> 「Whatに関する学習ループ」
- [[🗃️ダブル・ループ学習]]を取り入れた手法
- 💭[[🗃️方法不確実性]]、[[🗃️目的不確実性]]の対応をしていくということか
#### [[🗃️エクストリームプログラミング]]
- ドキュメントよりもソースコードを、組織開発の歯車になるよりも個人の責任と勇気を重んじるような人間中心のプロセス
#### [[🗃️適応型ソフトウェア開発]]
- [[🗃️創発|🗃️創発的]]な機序が必要であるという考えを基軸としている
- PDCではなく、「思索・コラボレーション・学習」という要素が重要であるという
#### [[🗃️リーンソフトウェア開発]]
- リーンは贅肉を削ぎ落としたという意味
- ムダ: 付加価値のないものを極限まで減らしていくための考え方
- ムラ: 作業やコーディングルールといったものを均一にすることでタスクのばらつきを減らし、スケジュールなどの予見可能性を上げていく
- ムリ: 過負荷な労働や、不合理なストレスを減らして、長期的なパフォーマンス実現する
- [[🗃️アジャイルソフトウェア開発宣言]]が調整し発表された
## 3-3. [[🗃️アジャイル]]をめぐる誤解
- 誤解1: [[🗃️アジャイル|🗃️アジャイル開発]]は決まったプロセスである
- 正: [[🗃️アジャイル]]な[[🗃️チーム]]を作るための方法論(複数の軽量[[🗃️アジャイル|🗃️軽量ソフトウェア開発プロセス]]の総称)
- 誤解2: [[🗃️アジャイル|🗃️アジャイル開発]]では[[🗃️設計]]をしない
- 中間成果物を価値とはみなさない。従来の不必要な設計文書やその工程は無駄とみなすだけ。
- ドキュメントを書いた方がいい場面もある。ナレッジの形式知化は重要である
- 情報伝達は口頭やチャットベースの方が効率が良い
- 何かを作る際に[[🗃️設計]]を考えずに、場当たり的にプログラミングしてしまい、バグや遅延を引き起こしてしまう場合は、コミュニケーションがうまくいっていないことを示唆している
- 誤解3: [[🗃️アジャイル|🗃️アジャイル開発]]は優秀なメンバーでないとできない
- メンバーに自立性が求められ、[[🗃️チーム]]は常に課題と直面する必要がある。最初はそれによって多少の問題が生じる。
- その問題はかえって、成長を促すことにつながる
- 誤解4: [[🗃️アジャイル|🗃️アジャイル開発]]では中長期計画がない
- 計画を立てることはいつでもできる。
- [[🗃️不確実性]]が大きすぎるときは、中長期計画を立ててもさほど意味がないということはあるかもしれない。
- 誤解5: [[🗃️アジャイル|🗃️アジャイル開発]]は開発者に決定権がある方法だ
- よく見られる誤解
- 優れた[[🗃️アジャイル]]チームになるほど権限委譲が行われる
- [[🗃️アジャイル]]はなぜ誤解されるのか
- 「クールエイドを飲む」= 誰かの思想信条を無批判に受け入れる
- アジャイル教場主義者によって、誤解を増大させた部分がある
- 必要なのは[[🗃️情報の非対称性]]を解消すること
- 自分たちと他の人たちを隔てる目的意識のズレを[[🗃️傾聴]]と対話によって調整していくことが、[[🗃️アジャイル]]な立ち振る舞い
## 3-4. [[🗃️アジャイル]]の格率
- [[🗃️アジャイル]]
- 目的地([[🗃️ゴール]])。環境に適応して、最も効率よく[[🗃️不確実性]]を減少させられている状態
- [[🗃️アジャイル]]な[[🗃️チーム]]
- [[🗃️自己組織化]]
- 目的地に向かう集団。
- [[🗃️アジャイル]]な方法論
- 目的地に向かうための考え方。
- [[🗃️アジャイル|🗃️アジャイル開発]]
- 目的地に向かう特定の移動手段。チームで実行されている開発プロセス。
- [[🗃️アジャイル|🗃️アジャイル開発]]手法
- 移動手段の手引書に書かれていること。プラクティス。ルール、[[🗃️フレームワーク]]。
### [[🗃️アジャイル]]は理想状態
- 理想状態。
- [[🗃️チーム]]が環境に適応して、[[🗃️不確実性]]を最も効率よく削減できている状態
- この状態に向かうための問いは、「どのようにしたら、私たちはもっと[[🗃️不確実性]]を減らすことができるだろうか？」
- 不安 <- [[🗃️不確実性]] -> 確実性
- 未来 = 環境不確実性
- [[🗃️方法不確実性]]
- [[🗃️目的不確実性]]
- 他人 = [[🗃️通信不確実性]]
### [[🗃️アジャイル]]な方法論
- 問いに対する答えの1つ。
- システムにアプローチする
- 不安に向き合うこと
- [[🗃️振り返り]]、学習という仕組み。
- 問題を隠してしまうよりも、チームで共有した方が良いというようにリスクを取りやすくることによって促される
- 不安が[[🗃️通信不確実性]]へ転化されることを防ぐ
- 少人数の対話を重視する
- [[🗃️通信不確実性]]を減らすためには大人数では難しい
- できる限り少人数で、最も情報の多い対面でのコミュニケーションによって情報共有を行う -> [[🗃️情報の非対称性]]を減らす
- 役割を分けない
- [[🗃️アジャイル]]な方法論で重要なことは役割で関係性を縛らないこと
- 「役割を遂行するにはどうしたらよいか」ではなく、チーム全体の目的において、「今じぶんは何をすべきか」という問いを持つようになるから
- [[🗃️情報の非対称性]]と[[🗃️限定合理性]]を押さえ込むことによって、[[🗃️通信不確実性]]が[[🗃️環境不確実性]]に転化することをを押さえ込む
- 別の専門領域の事柄も手伝っていくように変化させていく。
- 💭役割を分けるメリットもあるけど、確かに役割があることによって[[🗃️情報の非対称性]]が発生するし、役割を分けないに越したことはない気がする。
- 経験のみを知識に変える
- 「うまくいく」ことだけを目的としてしまうと、「うまくいかなかった」時に不安が増大してしまう
- まずは実験をしてみることが重要
- [[🗃️意思決定]]を遅延する
- あらかじめ大惨事にならないようにしておけば、[[🗃️意思決定]]を遅延しても大丈夫
- [[🗃️仮説思考]]、[[🗃️リアルオプション]]戦略
- 価値の流れを最適化する
- 完了を目指す[[🗃️プロジェクトマネジメント]]よりも、継続を目指す[[🗃️プロダクトマネジメント]]を重視する
- システムのパフォーマンス指標
- [[🗃️レスポンスタイム]]
- [[🗃️スループット]]
- [[🗃️プロジェクト]]型[[🗃️チーム]]
- [[🗃️レスポンスタイム]]が重要になる
- リソースがあれば、高速化に利用する
- プロダクト型[[🗃️チーム]]
- [[🗃️スループット]]が重要になる
- ボトルネックを探し出し、そこに対して、メンバーが自発的に解決するように調整する
### [[🗃️アジャイル|🗃️アジャイル開発]]は「脱構築」される
- [[🗃️アジャイル|🗃️アジャイル開発]] = 自分たちの状態や周囲に存在する[[🗃️不確実性]]をしっかりと観察し、[[🗃️チーム]]状態をより[[🗃️アジャイル]]に身ちびていくための暫定状態で用いている手法
- [[🗃️チーム]]が同一の目的でありながら、チームの内部に二項対立が生まれる場合、そこに[[🗃️不確実性]]が隠れていることを示唆する
- 脱構築 = 対話と熟慮を通じて、対立をそもそもなかった状態に解消するような視点を得て、自分たち自身を再構築していくこと
- [[🗃️アジャイル|🗃️アジャイル開発]]では、[[🗃️チーム]]が脱構築機能を内臓させるように振る舞うことを要求する
- **別チームの開発手法を模倣しても、チームが[[🗃️アジャイル]]になるとは限らない**
- 必要なことをは、自分たちを取り巻く状況を観察すること
- 今何をすべきかをしっかりと周囲と対話していくこと