#book #r2023  # なぜこの本を読んだか 会社のとあるイベントの中で言及されてたので前に読んだことがあったけど改めて読んでみた # 何が書かれている本か 1990年代から製造や物流の分野から生まれたアイディアや考え方をソフトウェア開発に落とし込んでいったものがリーンソフトウェア開発で、アジャイル開発の1つの手法となっている。 元々はトヨタでの開発の仕方が元となっており、「7つのリーン原則」や「7つのムダ」でよく知られている。 # メモ ざっくりと言うならば、### Just in Time で Just Enough なものを変化を前提にしながら作るべき だという内容 ## 歴史 トヨタ生産方式では、先行してたアメリカの大量生産モデルを採用していては、追いつけないと考えていた。 > 豊田喜一郎は、組み立てられた部品すべてが、利用される「ちょうどその時 (Just in Time)」に組み立てラインに到着しなくてはならないというビジョンを持っていた > 聡明なことに、喜一郎も英二も、勝敗を決めるのは規模の経済ではなく、複雑性の攻略であるということに気づいていた。 > 規模の経済では、数量が倍になると、製品1体にかかるコストが15 ~ 25パーセント減少する。しかし、種類が倍になるたびに、コストは20~35パーセントずつ増加する。「多様性のコスト」の要因は、ジャスト・イン・タイムの流れによってなくなる。 ## リーン生産とリーンソフトウェア開発 - 頻繁な設定変更 - -> 頻繁な製品変更 (ソフトウェアリリース) - 短い製造スループット時間 - -> 短い開発時間 - 製造ステップ間の未完成品在庫の削減 - -> 開発ステップ間の情報在庫の削減 - 製造ステップ間で部品を頻繁に交換する - -> 開発ステップ間で仮決定の情報を小ロットずつ頻繁に移動させる - 在庫削減にはリソースのゆとりやステップ間のさらなる情報のフローが必要 - -> 開発時間削減にはリソースのゆとりやステージ間での情報フローが必要となる - 数量、製品構成、製品設計の変更への順応性 - -> 製品設計、スケジュール、原価目標の変更への順応性 - 製造作業者への幅広いタスクの割り当てによって、高い生産性が得られる - -> エンジニア (開発者) への幅広いタスク割り当てによって、高い生産性が得られる - すばやい問題解決と継続的なプロセス改善の重視 - -> 頻繁でインクリメンタルな革新と継続的な製品・プロセス改善の重視 - 品質、納期、製造生産性の同時改善 - -> 品質、開発時間、開発生産性の同時改善 ## プロジェクトからプロダクトへ プロジェクトは、 - その開始時点で、すべての資金が供給される場合が多いということ - プロジェクトの成功は、コストとスケジュールとスコープに関する確約が満たされたどうかで計測される - 始まりと終わりがある プロダクトは、 - 徐々に資金調達が行われるもの - 最終的に得たマーケットシェアや収益性に基づいて計測される - 始まりはあるが (うまくいけば) 終わりがない ## リーンソフトウェア開発の7つの原則 ### ムダをなくす > 私たちが行うことのうち、顧客価値を付加しないすべてのことがムダであり、顧客が望むときに価値を手にすることを妨げる遅れもまた、すべてムダなのである - 「機能を作りすぎるムダ」が最悪のムダ - 特にソフトウェアの世界では、せいぜい20%程度しか機能は使われないという事実を認識する必要がある - see also [https://mtx2s.hatenablog.com/entry/2023/03/27/222358](https://mtx2s.hatenablog.com/entry/2023/03/27/222358) - Just in Time で Just Enough なものを ### 品質を作り込む 欠陥 (バグ) のトラッキングシステムは未完成の作業の待ち行列であり、どんどん在庫を増やしていることになる したがって見つけたそばから修正できる方法が重要 ### 知識を作り出す フィードバックをもらい、仮説が修正されることを前提に作る ### 決定を遅らせる > 時間枠の終わりがもっとも多くの情報を得ているはずの時点だから > ... > 取り返しのつかない決定は、最後の瞬間まで、つまり手遅れにならずに決定を下せる最後のチャンスまで取っておくのである。 ### 速く提供する > 顧客に気を変える時間を与えないためにも、ソフトウェアを速く提供する方法を見つける必要がある ### 人を尊重する ### 全体を最適化する ## ムダ > ソフトウェア開発においては、複雑さへの処方箋はいたって簡単だ。できるだけコードを書かなければいいのだ！ ### 7つのムダ (ソフトウェア開発版) - 未完成の作業のムダ - -> ソフトウェアの世界における在庫 - 余分な機能のムダ (= 作りすぎの無駄) - -> 最悪のムダである - 再学習のムダ - 引き継ぎのムダ - -> 暗黙知を形式知にして明示的に引き継ぐのは難しい - タスク切り替えのムダ - -> コンテキストスイッチ的にも、ユーザーが使い始めることができる時期的にもムダ - 遅れのムダ - 欠陥のムダ - -> 未完成の作業がどんどん増えていくことになる + unplanned work となるのでリスクもある ### 複雑さ  「余分な機能のムダ」でも触れているが、複雑性は機能とは指数関数的にコストが上がっていく そのため最初からコードベースに追加する機能を積極的に絞り込むことが大事 ## サイクルタイム > コンセプトがキャッシュとなるまで、あるいは、顧客の「注文」がソフトウェアの導入に至るまで、平均でどれくらいの時間がかかるか # 感想