名著だと思う。
全編にわたって参考になることばかりが書いてあるので、繰り返し読んだほうがいいかもしれない。特別に抜粋すべきところがあるというよりは全体がすごく良い。
トヨタ生産方式とソフトウェアの関連がいまいちついていなかった面があったが、腑に落ちた。
だいぶ昔の本であるのに、日本にリーン開発が根付いていないのが非常に気になりはした。
原則1:ムダをなくす
原則2:品質を作り込む
原則3:知識を作り出す
原則4:決定を遅らせる
原則 5: 速く提供する
原則6:人を尊重する
原則7 : 全体を最適化する
が原則として挙げられており、それらについて細かく説明がされている。
基本的なコンセプトはサイクルタイムをいかにして短くしていくのかという点だ。
ムダをなくしていくのも、その手段となっている。
ムダには大きく７つがある
- 未完成の作業のムダ
- 余分な機能のムダ
- 再学習のムダ
- 引き継ぎのムダ
- タスク切り替えのムダ
- 遅れのムダ
- 欠陥のムダ
バリューストリームマップの作成をしてムダを排除していく。
スピードを上げるために、可能な限り作業を詰め込むのではなく、少し余裕をもたせることで、スループットがあがり、最終的なスピードがあがる。
あまり詰め込みすぎると渋滞が起きるのと同じ。
チームを作っていくために、命令して作業を割り振るというよりは、話し合いながら何をすべきかを全員で決めていくことだ。
ただ、何かをきちんと決めるリーダーは絶対に必要。
集合ベース設計では、３パターンくらいの設計案を考えて、最適なものを選んでいく。時間的な成約に間に合わせるために、確実に間に合うもの、間に合わないだろうけど最高なものなど。
リファクタリングは必要なもので、最初から最適なものを作れなかったから行われるのではない。変更を受け入れやすくして、コードの寿命を伸ばすためのものだ。
リファクタリングは必須であり、プロセスにいれて最初から時間を確保すべき。
リファクタリングのためには、自動テストの強力な取り組みが必要となるので、それが血管の混入を防ぐなどの効果もたらす。
自動テストで重要なのは、製造有形で言うところの、ラインストップに相当する効果を狙ったものだ。
出荷前に不具合を検出して、完成品の検証という時間をなくすことでサイクルタイムを短くするのだ。
ここでは、リーン開発を実践するための、 21 ステップのプログラムを提案 する。各ステップでは、何を行うか、手短な説明だけをする。詳細は、本書 の各所ですでに紹介してきたはずだ。 これらは、 提案として受け止めてほし い。 私たちの提案を試してみて、自分の組織で求めている成果が得られるか どうか、確認してほしい。
■全体を最適化する
1. バリューストリーム全体、製品全体を通してリーン手法を実践する。 バ リューストリームのリーダー(あるいはリーダーとなるチーム)を任命 して、顧客に始まり顧客に終わる、バリューストリーム全体の責任を負 わせる。 ソフトウエアだけではなく、 製品全体を重視する。 バリュース トリームマップを描き、 流れに中断がないか、やり直しや揺れ動きがないか、流れの中で必要なときに利用できなかったり、必要な成果を出せ ていない個所がないか、チェックする。 プロセスのほころびを直し、シ ステムに欠けている機能を補足する。
2. 計測基準を作り直す。 バリューストリーム内で、部分的な計測を行って いる可能性が非常に高い。また同様に、そのような計測によって部分最 適化や、さらに悪ければ、機能不全につながっていることも非常に多い。 部分的な計測を行うのをやめて、 代わりにバリューストリームでの計測 を行おう。
3. 境界越えのコストを減らす。 バリューストリームに大きな遅れがある場 合、おそらくそれは、部署や企業の境界で起きているはずだ。 そのよう な境界を注意深く調べて、 そこで実際にどれだけのコストがかかってい るのかを評価する。 そのような境界で、価値の流れのスピードアップに つながることなら、 ほぼ確実に、境界越えのコスト削減にもなるはずだ。
■ 人を尊重する
4. チームリーダーや監督者を訓練する。 プロセスリーダーを重視する代わ りに、現場のチームリーダーを訓練し、指導し、 配備して、彼らの持ち 場でリーン手法を実践するための時間を与える。
5. 責任や意思決定をできるだけ下のレベルに委譲する。 リーン活動は、価 値を生み出している作業チーム自身により、今いるリーダーの指導の下 で実践されるべきである。 作業チームには、新プロセスをうまく機能さ せるために必要なものを要求させる。
6. 技術へのプライドを育てる。 技術へのプライドは、いろいろなもので崩 される。チームへではなく個人への報酬、散らかった職場やぞんざいな 作業プラクティス、守れるはずのない締め切り、きちんとしたテストや リファクタリングを行う時間の欠如、プロセスの押し付け、ロボットが やるような繰り返しの作業など、 すべてがプライドを崩すもとになる。 このようなプラクティスは根絶し、廃止しなくてはならない。チームメンバー間で報奨をめぐっていさかいが起こらないようにし、 繰り返しの タスクは自動化し、作業をする本人にいちばん適切な作業方法を決めて もらう。また、締め切りに間に合わせるために、作業をいい加減に行わ せるような指示は、絶対に出してはならない。 熱意を持って約束をし、 最高の品質を備えた成果を期待しよう。 そのほうが、個人に対して報奨 やボーナスを与えるよりも、より継続可能であり、はるかに大きな効果 もあるはずだ。
■速く提供する
7. 小さなバッチで作業を進める。 プロジェクトサイズを縮小する。 リリー スサイクルを短縮し、安定させる。 そして、繰り返す。 すべてのリスト や待ち行列の掃除をして、規模が大きくならないよう積極的に制限する。
8. 作業を許容量までに制限する。 繰り返し可能なリズムでチームに作業を させて、許容量を確定する。 実証済みの速度(ベロシティ) に基づいて、 チームに作業を待ち行列からプルさせ、その作業を完全に終わらせてか ら、次の作業に手をつけさせる。 待ち行列の長さを制限し、 その待ち行 列に空きができるまでは、作業を受け付けない。
9. 利用率ではなく、 サイクルタイムを重視する。 リソースの利用率に気を 揉むのはやめて、製品化までの時間や、 顧客への応答時間の計測に切り 替える。
■決定を遅らせる
10. 完全に仕様を決定してから開発に着手するのがよい方法である、という 考えは捨てる。 コンカレント開発を行うということは､開発プロセスか ら仕様を浮かび上がらせるということだ。 コンカレント開発によって、 コストも時間も節約でき、 最高の成果が生み出せ、 最も新しいデータに 基づいて決定を下せるようになる。 コンカレント開発を嫌う理由などな い。 それなら、開発に着手する前に、 完全な仕様ができあがっているべ きだという考えに、どうして執着する必要があるだろう? その答えが、 資金調達が事前に行われるためなのであれば、徐々に資金調達を行うように変更しよう。 もし、固定価格での契約によるものなら、別の契約モ デルに移行しよう。
11. 依存性を断ち切る。 依存性を気にかける代わりに、どのような機能も、 どのような順序ででも追加できるように、 依存性を断ち切るあらゆる努 力をする。 分割可能なシステムアーキテクチャは必須である。 依存性を とことん疑いできるかぎりなくしていく。
12.選択肢を持ち続ける。 撤回のできない決定には、かならず､ 複数の選択 肢を設け、 最終責任時点まで、絶対に選択肢を切り捨てない。 重要な設 計上の決定は、トレードオフである。 最善の選択を行うのに必要なデー タと確信を手に入れるため、それぞれの選択肢が持つ影響力を十分に理 解するための投資をする。 それ以外のすべての決定に関しては、変更を 受け入れやすいコードを作り、クリーンかつシンプルに保ち、変更をた めらってはならない。
■知識を作り出す
13. 設計・構築チームを作る。 製品を論理モジュールに分割して、 バリュー ストリームの各フェーズをそれぞれ代表するメンバーからなる部署の壁 を越えたチームを作り、そのチームでモジュールを担当できるようなシ ステムアーキテクチャを作り上げる。 各チームに適切なリーダーシップ やインセンティブを与え、積極的取り組みや透明性、集中的なフィード バックが維持できるようにする。 チームに対しては、情報を早期かつ頻 繁に共有し、 速く失敗し、絶えず学習し続けることを推奨しなくてはな らない。
14. 継続的な改善を行う文化を守る。 各チームや各部署で、継続的にプロセ スを見直し、改善し、仮説をテストするように求め、また、そのための 時間を作る。 チーム間あるいは部署間でミーティングを開いて、 バ リューストリームの流れに内在する制約や、制約への適応手段を見出 し、全体的な成果を改善させるプラクティスや方針に置き換える。
15. 問題解決手法を教える。 PDCAサイクルや科学的方法など、何らかの問 題解決手法を教える。 チームが仮説を立て、 すばやく数多くの実験を行 い、簡潔に文書化し、検討済みの変更を実行するように促す。
■品質を作り込む
16. 同期する。 未完成の作業を積極的に減らす。 テストを最初に書く。でき るだけ早くコードをテストする。欠陥はリストに付け足していかずに、 見つかった瞬間に作業を止め、直すようにする。 コードをできるかぎ り、継続的に、広範囲にわたって統合する。より大規模で複雑なシステ ムの統合には、同期を入れ子にする。
17. 自動化する。 人間は間違うものだという事実を受け止めて、 自動化によ りポカヨケを施す。 できるだけ早く、 自動化できるプロセスすべてを自 動化する。 テスト、 ビルド、インストールなど、 繰り返し行う作業はす べて自動化する。 ただし、 人を支援して、どうすればもっとうまくでき るか、人に考えさせ続けるような自動化でなくてはならない。
18. リファクタリングする。 コードベースをクリーンかつシンプルに保ち、 重複を目にしたらただちに、コードやテスト、ドキュメントをリファク タリングして、複雑さを最小にとどめる。
■ ムダを排除する
19. マーケティングと技術の両方を理解しているリーダーを任命する。顧客 が何に価値を見出すのか、また、それと密接に関連して、 技術側が何を 提供できるのか、両方を深く理解する責任があることを明確にする。 チームが正しいものを確実に作れるようにする。
20. 価値のみを生み出す。 すべてのプロセスのすべてのステップにおいて、 できるかぎり、価値を生み出す活動と価値の提供能力向上が重視されて いることを確認する。 プロセスサイクルの効率を計測し、改善し続け る。
21. コードをできるだけ書かない。 システムの機能を積極的に制限し、価値 を付加するために絶対必要な機能のみを作る。 組織をあげて、 複雑さに 抵抗する姿勢を作り上げる。
