リーンソフトウェア開発を読んだのでまとめておく
はじめに
- 今回は表題の通りです
- すこし古い本ではありますが、下記の本を読んでのでさらっとまとめていきます
リーンの7大原則
リーンには7つの原則があります(以下列挙)
- ムダを排除する
- 学習効果を高める
- 決定をできるだけ遅らせる
- できるだけ早く提供する
- チームに権限を与える
- 統一性を作り込む
- 全体を見る
これらについて簡単に要約と関係性をまとめておく
ムダを排除する
- リーンではムダを最大の問題としている
- ムダというのは「すぐに必要になる機能以上のものを実装」したり、 「いろんなところに資料や情報が散らかってる状態」であったり、「作業をいろんな人に引継ぎまくる状態」など。
- 本書ではソフトウェア開発における7つのムダを掲げている(今の時代に完全に当てはまるのかはわからないが)
- 未完成の作業
- 余分なプロセス（ここでいうプロセスというのは承認プロセスみたいなもの）
- 余分な機能
- タスク切り替え（1人を複数のプロジェクトにアサインするなという話）
- 待ち
- 移動
- 欠陥 （欠陥のムダの量の算出については、欠陥の影響×気づかずに過ごした時間である）
- これらに関して、まずは認識することから始める必要がある
学習効果を高める
- ソフトウェアの開発での品質とは「認知統一性」と「コンセプト統一性」の両方に帰結する
- 前者は、UX、信頼性、経済性のバランスが保たれていること
- 後者は、システムのコンセプトが全て合わさっていて、スムーズな統一体として機能すること
- 上記のような品質を満たすためには、「可変性」を意識し、より正しいモノへと学習サイクルを回していく必要がある（顧客によって満足できる品質は異なり、それを認識し改善するためにフィードバックループが必要）
- そして、学習サイクルをただ回すだけではあまり意味がなく、できるだけ効果的に回し続ける必要がある。
- そのためには、「短い学習のサイクルを回し続ける」必要がある
決定をできるだけ遅らせる
- 遅い意思決定を許容する開発手法は、不確定要素の多い場合における開発では非常に有効的である
- 重要な意思決定を不確実性の高い状態で下そうとすると、推測ベースで議論が進み正しい意思決定ができなくなってしまう
- そこでオプションベースでの開発が生きてくる
- 金融や商品取引において使われる「オプション」という概念をソフトウェア開発でも取り入れることで、不確実性を解消するためにコストや時間を支払って、その引き換えにリスクを低減する
- そして、意思決定を遅らせることで利益を最大化にする
- 最終的には不確実な要素が、良い方向にいった場合のみのオプションを考えておけばよい
- すなわち、重要な意思決定を不確実性の高い状態で下し、いずれ変更を強いられるよりも、変更を許容するようなソフトウェアにしておいて、確度が高まった時点で意思決定をし必要なオプションを行使した方が、変更は少なくて済む（モジュール・インターフェース・抽象などがここでは生きてくる）
- 要するに、オプションを使うことで、推測ではなく事実に基づいた意思決定が可能になる
できるだけ早く提供する
- これは、「ムダを排除する」や「学習効果を高める」というプラクティスと関連が高い
- 今ユーザーが必要としている機能をできるだけ早く提供する
- そして、提供した機能に対してフィードバックサイクルを回し学習効果を高める
- それを実現するためには、「ムダの排除」が必要になる
- 例えば、「待ち行列理論」を少し意識してみるといい
- 具体的にはサイクルタイムの短縮化が有効
- 到着の標準化：大量の作業の到着を待つのではなく、小さく作業することで待ち行列を短くできる
- サービス時間の標準化：処理時間を平準化すること。小さな作業にしていくことで、くるいが少なくなる。
- あとは、ゆとりを持たせることも有効である
チームに権限を与える
- ソフトウェア開発の成功にはやる気のある訓練された人材が不可欠
- また、何か大きなことを成し遂げるためには、人々がグループになって結束し合う必要がある
- これらのためには、マネージャーによる計画的な戦略よりも、個々の従業員の自主性と創造性によって発展し続ける組織が必要（自己組織的なチームの必要性）
- 自己組織的なチームにするためには、魅力的でかつ達成可能な目的がある必要がある。
- そして、その目標達成のために、全勢力を傾けるのなら、目標達成に必要なリソースを入手する権限をチームが持つ必要がある
- 基本的には「内在するモチベーション」は「自己裁量」と「目的意識」によって喚起されるが、敵対的な環境では育まれない
- 所属意識
- 安全(心理的安全性)
- 能力(自分にはいい仕事ができる能力があると信じる必要がある)
- 進歩
統一性を作り込む
- 製品の統一性には外面的な統一性と内面的な統一性がある
- それを「認知統一性」と「コンセプト統一性」と呼び替えている
- 「認知統一性」はシステムに関する顧客に全てが影響する、すなわち「マインドシェア」とほとんど同義である
- 「コンセプト統一性」は「認知統一性」の必要条件である
- 「コンセプト統一性」はシステムの中心にあるコンセプトによって全ての機能スムーズにまとまっていること
- 「認知統一性」の実現のためには「モデル駆動設計」が非常に有効である
- ドキュメント引き継ぎの繰り返しをするのではなく、システムの統一性を判断できる人と直接連絡でき、お互いの共通言語でやりとりすることが統一性を作り込む最も有効な方法であるから
- 「コンセプト統一性」を作り込むためには、ソフトウェアアーキテクチャの理解が不可欠である
- そして、健全なアーキテクチャを維持するためには、定期的なリファクタリングが必要である
- 単純さ(単純かつ機能的な設計になっているか)
- 明確さ(プログラムに携わる全ての人がそのコードを理解できるか)
- 利用への適合(意図した目的を達成する設計になっているか)
- 繰り返しのないこと
- 余分な機能がないこと
全体をみる
- システム思考について
- 「システム」とは相互依存し相互作用する部品群がある目的を果たすために集まったもの
- 「システム思考」では組織をシステムとみなす。組織がどのように関連しあい、組織全体が時間と共にどのようにふるまうか分析をする
- 組織の行動をコンピュータシミュレーションにより分析することを「システムダイナミクス」という
- システム思考の基本パターンとして以下の3つがあげられている「成長の限界要因」「重荷の転嫁」「部分的最適化」
- 「成長の限界要因」とは、あるプロセスによって望む結果が得られたとしても、同時に成功を平均化するような二次的影響が発生し、徐々に成功を妨げるようになるというもの。大きな成功のためには同じプロセスを強いるのではなく、「成長の限界要因」を見つけ取り除く必要がある。
- 「重荷の転嫁」とは、根底にある問題が目に見える症状を生み出しているのだが、根底問題に立ち向かうのが困難な場合に発生しやすい。そもそも、人は問題の元凶よりも症状を解決する方向にあり、根底問題が悪化しているのに見過ごしてしまうことがある（-> 5 whys）
- 「部分最適化」とは、システムが複雑であればあるほど、システムを分割し部分的に管理したくなるもので、局所マネジメントにより生産性の局所的なものさしができことが多い。これらの局所的なマネジメントは全体としての生産性を低下させ、全体に悪影響を及ぼす。
- 通常、局所マネジメントによる全体に対する害は隠れて見えないので、迷信（原因と結果の間に実証がない繋がり）と習慣からくる局所最適的な計測から抜け出すことができない
- 局所最適化した部分的な計測ではなく、ビジネス全体として成果を最大化するに必要な「すべて」を測定する必要がある(「個人成果計測」ではなく「情報化計測」)
