直近開催のScrum Alliance認定スクラムマスター研修のご案内
【書評】リーンソフトウェア開発と組織改革
みなさんこんにちは。@ryuzeeです。
正月中に積ん読を消化したので書評を書いておきます。結論から先に言うと素晴らしい本でした。
リーンソフトウェア開発と組織改革
- 著者／訳者：Mary and Tom Poppendieck 著、 依田光江 翻訳、 依田智夫 監訳
- 出版社：アスキー・メディアワークス
- 発売日：2010-10-09
- 単行本（ソフトカバー）：336ページ
- ISBN-13：9784048687416
- ASIN：4048687417
本書はリーンの大家のポッペンディーク夫妻の最新の著作です。 本の裏表紙には、「中級技術者向け」とありますが、前提知識としてアジャイルやリーンに関する理解は必要ですし、ウォーターフォールの現場等で言われた通りのモノを作っているだけの人には理解が難しいかもしれません。
大事だと思ったことを以下にメモしておきます。
- 重要なのは結果ではなく、結果に注目するマネジメントの誤りである
- 設計と実装は分離できない（個人的には仕様書を書いたあとに開発を丸投げする意味がわかりません）
- 低依存アーキテクチャは必須で計画や予測に勝る
- システムの結合テストの頻度は、欠陥が紛れ込んだあとどれだけすぐに発見することを望むかによって異なる
- 欠陥が残っていたら、欠陥がなぜそこまで残っていたのかの理由を突き止めて、設計や開発プロセスを改善する機会とする
- リファクタリングは通常の仕事の一環
- システムで最大の障害原因となるのは、技術的な誤りではなく、間違ったものを作ることである
- 専門性を育成するには10年、10000時間かかる。メンバーの専門性を継続的に成長させる配慮が必要
- 設計をもとに制約を計算するのではなく、制約にあわせて活動を設計する
- システム設計に着手する前に、測定可能なビジネスゴールが何かについて合意しておくべき
- (1)依存 (2)稼働率 (3)クリティカルパスはスケジュールの結合度を高めてしまい納期への対応が難しい
- やらないリストを作る
- 顧客はスコープを必要としておらず、必要なのは時間とコストの制約の中でビジネスゴールを達成すること
- チームは長い時間を一緒に過ごすと作業効率が高まる（チームをいじくらない）
- フィードバックに対応する時間の余裕を確保する
- 最も先に得るべきフィードバックは製品の消費容易性(価値の得やすさ)
- その場しのぎをやめ、問題の根を根絶する
- 他の組織のソリューションをそのまま採用するのではなく、自分の問題のソリューションの見つけ方を学ぶべき
- 標準が最善だと思ってはいけない。標準とは改善するためのベースにしかすぎない（継続的改善のベースライン）
- 策定した標準や規制が６ヶ月以内に改訂されないなら、それは誰も真剣に使っていないということだ
- 問題の発生そのものを非難してはいけない
- 知的労働者の生産性を向上させる６条件は１つを除き肉体労働者のそれとは正反対である
- 「相互尊重」は無料でありながら最高のROIを実現できる投資である
- 自律的なチームの良いところと、リーダーシップの兼ね合いについてもっと考えるべきだ
- コードの行数やFPの個数を測ったり実際の計画との差異を測っても仕方ない。こういう評価は本当に必要な「顧客の成果」を測るようにはなっていない
それでは。
アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください（初回相談無料）
