エンジニアリング組織論への招待 Chapter3 - 読書メモ
エンジニアリング組織論への招待
目次
- Chapter1：思考のリファクタリング
- Chapter2：メンタリングの技術
- Chapter3：アジャイルなチームの原則
- Chapter4：学習する組織と不確実性マネジメント
- Chapter5：技術組織の力学とアーキテクチャ
書籍
Chapter3：アジャイルなチームの原則
アジャイルなチームをメンタリングする技術
アジャイル開発
- チーム全体に対してメンタリングを行い開発出力を向上させる手法
開発手順・開発フロー
アジャイル開発が必要とされた2つの理由
- ソフトウェアの大規模化・複雑化
- マーケットの不確実性に対応
アジャイル開発は3倍の成功率、1/3の失敗率
- 大規模開発こそ、アジャイル開発はより効果的であるという結果が出ている
プロジェクトマネジメントとプロダクトマネジメント
- ソフトウェア開発の前提が変化した
- プロジェクト型開発 → プロダクト型開発
| プロジェクト型開発（計画駆動） | プロダクト型開発（マーケット駆動） |
|---|---|
| 予算が開始時点に決まっている | 予算は各ステージごとに徐々に調達される |
| 成功はコスト・スケジュール・スコープが満たされるかどうかで計測される | 成功はその製品が最終的に得たマーケットや収益に基づき計測される |
| プロジェクトマネージャーによって指揮される | プロダクトマネージャーとテクニカルリードのペアで指揮される |
- 2つの不確実性に対するアプローチ
| 計画駆動 | アジャイル型開発 | |
|---|---|---|
| 前提とする不安 | スケジュール不安 | スケジュール不安とマーケット不安 |
| 戦略 | 初期計画の精度を高める | 実験的に徐々に精度を高める |
| 変化 | 変化に弱い | 変化に強い |
| アプローチ | 理性主義 | 経験主義的 |
ウォータフォールかアジャイルか
- スコープとする範囲
アジャイルの歴史
デミング博士とPDCA
- デミングの4つの「深遠なる知識」が日本の製造業に浸透し、ソフトウェア開発にも取り入れられた
- システムの理解
- システムの個別要素ではなく、関係性に着目し生産性を向上させる
- ばらつきに関する知識
- 測定によって知識を得るという態度
- 知識の理論
- 知識がどのようにして得られ、展開していけば良いのかという知識
- 心理学に関する知識
- 人間性に関する知識
- システムの理解
トヨタ生産方式とリーン生産方式
- トヨタ生産方式
- 「在庫は悪」として捉え、実現手段として「従業員」のマインドに徹底的にこだわった
- リーン生産方式
- トヨタ生産方式の徹底した無駄の排除と現場主義による改善を高く評価
- それらを整理し、マニュアル化、パッケージ化したもの
生産方式から知識経営へ
- 新しい新製品開発ゲーム
- NASAと日本企業における新製品の開発フローを比較した論文が発表された
| NASA | 各プロセスがばらばらの専門家によって分割されている |
| 日本企業 | 異なる分野の専門家が一丸となって開発を進める |
- SECIモデル
- 4つの段階を繰り返すうちに、組織内に知識が獲得されていく
- シングル・ループ学習
- 過去の学習を通じて獲得した「ものの見方・考え方」に基づいて、改善を繰り返す学習
- ダブル・ループ学習
- シングル・ループ学習のサイクルに、環境の不確実性を取り込んで、今まで前提としていた前提自体を変えていくような学習
軽量ソフトウェア開発プロセス
- スクラム
- ダブル・ループ学習を短い期間で繰り返していく
- エクストリーム・プログラミング
- 適応型ソフトウェア開発
- 不確実なビジネス環境では、官僚機構的なワークフローではなく、創発的な仕組みが必要という考え
- リーンソフトウェア開発
- ムダ・ムラ・ムリという3つの贅肉を減らし、引き締まったソフトウェア開発を実現する
- 贅肉を減らすための7つの原則
- 1：全体を最適化する
- 2：ムダをなくす
- 3：チームに権限移譲する
- 4：学習を強化する
- 5：早く提供する
- 6：品質を作り込む
- 7：決定を遅らせる
アジャイルソフトウェア開発宣言
| 従来重視されてきたもの | これから重視していくべきもの |
|---|---|
| プロセスやツール | 個人と対談 |
| 包括的なドキュメント | 動くソフトウェア |
| 契約交渉 | 顧客との協調 |
| 計画に従うこと | 変化への適応 |
アジャイルの歴史に見る3つのポイント
アジャイルをめぐる誤解
アジャイルに関する5つの誤解
- 誤解１：アジャイル開発は決まったプロセスである
- 誤解２：アジャイル開発では設計しない
- 必要であればドキュメント作成も行う
- 情報伝達はドキュメントよりもコミュニケーションの方が伝達効率が良いという考え
- 誤解３：アジャイル開発は優秀なメンバーでないとできない
- 自立性が求められ、課題に直面し成長した結果、優秀なメンバーがいるように見える
- 誤解４：アジャイル開発では中長期計画がない
- 不確実性が大きい場合は中長期計画の意味があまりないと判断することもある
- 誤解５：アジャイル開発は開発者に決定権がある方法だ
- アジャイルなチームは仮説検証を繰り返し、顧客ニーズやビジネス価値を深く理解する
- より抽象的な要求を定義できるようになり、意思決定の権限が徐々に移譲されていく
アジャイルはなぜ誤解されたのか
- 経験主義の意味が理解されないまま、プロセスだけ導入してしまう場合があるため
- システム思考、自己組織化、禅といった要素を知らない人には伝わりづらい
- ウォータフォールvsアジャイルとして対立した形で広まってしまった
- 開発・ビジネスそれぞれの立場における限定合理性としてアジャイル開発を理解してしまった
- 従来手法を重視する人たちにとって、生業となっていた知識が否定されるような体験になってしまった
- 誰かの思想信条を無条件に受け入れてしまう場合があった
アジャイルの格率
「アジャイル」は理想状態
- 「チームが環境に適応して不確実性を最も効率よく削減できている状態」
- この状態に向かうため「どうしたら、さらに不確実性を減らせるのか？」という問に答えていく
アジャイルな方法論
- 不安に向き合うこと
- 不安の正体は不確実性である
- 1人で不安に向き合うのは難しいので、チームの力を借りる
- 少人数の対話を重視する
- 少人数かつ対面でのコミュニケーションで情報共有を行う
- 「情報の非対称性」を減らし、「通信不確実性」を削減する
- 役割を分けない
- 役割を分けると「役割を遂行するにはどうすればいいか」という「限定合理性」が発生してしまう
- チームの目的について「今、自分は何をすべきか」という問いをメンバーが常に持つようにする
- 経験のみを知識に変える
- 「うまくいく」ことだけを目的にしてしまうと、「うまくいかない」ときに不安が増大してしまう
- 実験によって得られた結果だけがチームにとって重要な知識となる
- 意思決定を遅延する
- 「仮説思考」と「リアルオプション戦略」により、経営上の意思決定を遅延させる
- 価値の流れを最適化する
- プロジェクト型チームは、ある要求に対してどれだけ早く応えられるかを最適化する
- プロダクト型チームは、ある時間にどれだけの要求に応えられるかを最適化する
- アジャイル開発においては、チームが自分たち自身のやり方や役割を変えていくような「脱構築」帰納を内蔵させるように振る舞うことを要求する
- 別のチームが実行している「ある瞬間の特定の開発手法」を真似たからといって、チームがアジャイルになるとは限らないことに注意する
書籍
