nav-portfolio-lean

金もうけとダイエットは、きりがない。

 

リーンの概要

SAFeはリーン思考、プロダクト開発フロー、アジャイル開発というような現代ソフトウェアエンジニアリングにおける多くのトレンドに基づいている。チームレベルでは、開発チームが今までにない高いレベルの生産性、品質、従業員関与度を達成できるように、アジャイルはチームへの権限委譲、チームの巻き込みに必要なツールを提供している。しかし、組織全体にリーン-アジャイル開発を展開するために必要な指針となる原則は、リーンに求めなければならない。私たちのリーンアイコンは従来の表現から導出したリーンソフトウェアの家を表す。SAFeのリーンソフトウェアの家には、 5つの構成要素がある:

  • ゴール:価値。持続可能な最短のリードタイム
  • 人々への敬意
  • カイゼン(継続的な改善)
  • プロダクト開発フローの原則
  • 土台:リーン-アジャイルリーダー

本ページではこれらについて説明する。

詳細

リーンソフトウェアの家

もともとリーン生産に由来したものであるが、ソフトウェアやプロダクト開発に適用されるリーン思考の原則やプラクティスは深く、広い。例えば、LarmanとVodde [1]は扱いやすいソフトウェアのコンテキストに多くの中心的な原則やプラクティスを入れたリーン思考の枠組みを説明している。それを行うために、彼らはトヨタ自動車やその他から発想した「ソフトウェアのためのリーン思考の家」という図を紹介した。SAFeでは、それを少し変更して、図1に示すような「リーンソフトウェアの家」を作成した。

 

Figure 1. The SAFe House of Lean

図1. SAFeのリーンの家

ゴール:持続可能な最短のリードタイム

リーンのゴールは議論の余地がない。それは可能な限り最高の価値と品質を顧客や人や社会全体に提供しながら、顧客に最大の価値を可能な限り最短のリードタイムで持続的に届けることである。これを実現するため、リーンは継続的なフローを実現すること、遅延や付加価値のない活動を識別し、それを継続的に削減することを重視している。他の人たちは以下のように述べている:

「我々が行っていることは、顧客が注文を下さる時点から我々が集金する時点までを時間軸で見ることだけである。そして、付加価値のないムダを減らすことで時間軸を短縮している。」 - 大野 耐一

「走者ではなく、バトンに注目すべし」 - Larman and Vodde[1]

「問題を顕在化するために継続的なプロセスフローを作る」 – Liker [2]

そのため、我々は仕事をするとき、以下のようなことを心がけるのである。

  • システムに対する理解を深める。これは我々のプロセスである。システムをよりよく理解するために、顧客の要求やコードやテストを管理する人や組織ではなく、まずシステム内での顧客の要求やコードやテストの移動に注目する
  • 遅延や引き継ぎなどの付加価値のない作業を探し、積極的に最低限に減らす
  • 最大のスループットを得るため、また、価値納品のさらなる加速の障害となる問題を顕在化するため、継続的なフローを実装する

第1の柱:人々への敬意

「バトンに注目すべし」というのは正しいが、我々は価値を追加する仕事を実際に行うのが自社の人たちだということや、人々に対する敬意はリーンとアジャイルで奨励される基本原則であるということを常に意識しなければならない(アジャイル開発宣言:意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します)。さらに、リーンでは自分自身のプラクティスや改善をさらに発展させる権限を人々に委ねる。上役は人々が変わることを促し、何を改善すべきかを示すことさえあるかもしれないが、チームや個人も問題解決の方法、振り返りのスキルを学び、適切な改善を行う。

第2 の柱:カイゼン(継続的な改善)

このことが、リーンの第2の柱である継続的なカイゼン(改善)に導いてくれる。カイゼンにより、「弛まぬ振り返りと継続的な改善を通じて学習する組織になる」へと導かれる。

  • 継続的な改善を用いて、非効率の根本的な原因を突き止め、効果的な対策を適用する。
  • 重要なマイルストーンとプロジェクト完了時点で振り返りを行い、オープンにプロジェクトのすべての不十分点を特定する

SAFeのこの重要な要素に関する詳細は、「検査と適応」および「振り返り」を参照のこと。

土台:リーン-アジャイルリーダー

リーン思考の土台はリーダーシップである。我々の考えはシンプルである。企業の既存の管理者、リーダー、経営者は、リーン/アジャイルパラダイムの導入と成功に関する最終責任を負う。このような責任はアジャイルチャンピオン、アジャイルワーキンググループ、開発チーム、PMO、プロセスチーム、外部のコンサルあるいは他の組織に委譲できない。成功するためには、リーダーは、この新しい革新的な思考と運営の方法でのトレーニングを受けなければならない。リーン-アジャイルリーダーには以下の特徴がある

  • リーンとアジャイルの原則を理解し、日常的な判断をこの長期的な考えに基づいて行う。これらの振る舞いを理解し、教える
  • SAFeのプラクティス、役割、活動と成果物の教育を受けていて、他の効果的なアジャイルプラクティスについての知識がある
  • 継続的な改善のプラクティスとツールの教育を受けていて、従業員に問題解決と是正活動のスキルを教える
  • 新しいプロセスの導入、障害の排除、組織変更管理の促進を実践する
  • リーン-アジャイルの成功に責任を持つ

これらの点で、リーンはアジャイル開発での我々の経験の多くとは違っている。我々の経験では、アジャイルは、「上役を排除する(そしておそらくは信頼しない)傾向のあるチームに基づくプロセス」という部分だけが導入されることが多い。これでは規模が大きくなったときに対応できない。従来のアジャイルとSAFeの1つの駆動力との重要な違いは以下の点である。

従来のアジャイルでは、上役が我々をサポートし、障害があれば取り除くのを支援することが期待されている。リーン-アジャイルでは、上役が我々をリードし、基本的なプラクティスに熟達し、継続的な改善を推し進めるための積極的な役割を果たすことが期待されている。

家の中:プロダクト開発フローの原則

リーンソフトウェアの家の中心には、ソフトウェアを開発しエンドユーザーに納品するために使う様々な原則やプラクティスがある。SAFeでは、プロダクト開発フロー(Reinertsen [3])の以下に示す8つの主要なテーマ(原則)を取り入れている。

  1. 経済面からものを見る:チームレベル、プログラムレベル、企業レベルに関わらず、置かれた特定の状況に合った意思決定の枠組みを確立する。価値全体を理解する。既に投じたお金を考慮しない。高リスク、低コストの作業(WSJF)を最初に行う。 1つしか定量化しないのであれば、遅延のコストを定量化する
  2. 積極的に待ち行列を管理する:長い待ち行列は普遍的に好ましくない。というのは、サイクルタイムを長くし、リスクを高め、品質を低下させ、モチベーションを下げるからである。積極的に待ち行列(プログラムバックログチームバックログを参照)を管理し、リトルの法則[4]を適用することで待ち時間を予見できるようにする。ピークよりも低いレベルの利用率で運用することにより、スループットと変化への反応が高まる。(イノベーションと計画策定反復)
  3. バラツキを理解し、利用する:製造では、予見できる結果、効率性、品質を得るためにバラツキを可能な限り減らさねばならない。ソフトウェア開発には、バラツキは元々つきものである。バラツキを取り除く代りに、バラツキを予測してそれに対処し、適当な場合にはバラツキを利用するようにシステムを設計しなければならない。
  4. バッチサイズを小さくする:バッチサイズが大きいと不必要なバラツキが生まれ、納品の遅延と品質の低下が生じる。最も重要なバッチは、チーム間またはチーム内の役割の間での受け渡し(引き継ぎ)バッチである(機能横断なアジャイルチームアジャイルリリース列車)。近接(同席)するように最適化することで、バッチサイズを小さくできる。優れたインフラ(テストの自動化、継続的なインテグレーションなど)を使用しアーキテクチャーの結合を緩めることで、ソフトウェアを小さなバッチで納品することが可能になる。
  5. WIPの制約を適用する:仕掛かり作業を制限することで、入力速度を利用可能な処理能力に合わせるようにしむけることができる。仕掛かり作業に制約を適用することで待ち行列の長さを制御する。固定期間毎に納品することで、作業が無制限に膨らむことを防ぐことができる(反復プログラムインクリメント)。ローカルの仕掛かり作業プールを制約することで全体の仕掛かり作業プールを制約する。WIPを(大きなよく見える情報発信板カンバンシステムで)常に見えるようにする。
  6. 不確実性の下でフローを制御する-リズムと同期:リズムは、予期できない出来事を予期できる出来事に変換するのに役立つ、予見可能な周期である。これにより、待ち時間が予見できるものになり、トランザクションのコストが下がり、プロダクト開発がより確実で信頼できるものになる。周期的な再同期により、1つの期間(プログラムインクリメントと反復)での変動や足並みの乱れを制限することができる。定期的にシステム全体を統合することにより、綿密なシステムテストを行いプロジェクトのステータスに対する客観的な評価を得ることができる(システムデモ)。定期的な同期により、機能を横断するようなトレードオフや広帯域での情報の伝達も促進される。(リリース計画策定
  7. できるだけ早くフィードバックを得る:リスクを取らずにソフトウェア開発を革新することはできないし、アクション(テストファーストプロダクトオーナーレビュー、短い反復、短いリリース期間)を早く取るには早くフィードバックを得なければならない。バッチサイズ(インクリメント)を小さくすると速いフィードバックが促されるが、CIとテスト自動化に対する投資の追加が必要になる。
  8. 制御を分散する:意思決定が遅くなると、フィードバックも遅くなると同時に決定の有効性も減る。待つ間に事実が古くなったり進化するからである。素早く効果的に行動と意思決定を行えるようにチームに権限を委ねなければならない。(スプリント計画、デイリースタンドアップ、リリース計画策定PPM

これら8つのテーマは、SAFeにとっての経済的、定量的、数学的に実証された基盤となる。上記のように、これらのテーマはさまざまなプラクティスの中に現れる。


さらに知りたい場合

[1] Larman, Craig, and Bas Vodde. Scaling Lean & Agile Development. Thinking and Organizational Tools for Large-Scale Scrum. Addison-Wesley, 2008.

[2] Liker, Jeffrey. The Toyota Way. 14 Management Principles from the Worlds Greatest Manufacturer. McGraw-Hill. 2004.(邦訳:ザ・トヨタウェイ、日経BP社、2004)

[3] Reinertsen, Don. Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.

[4] リトルの法則。この法則によると、待ち行列の平均待ち時間は、待ち行列の平均の長さが平均処理時間で割る結果に等しい。従って、長い行列と遅いサイクル時間が長い待ち時間を生じる。

[5] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.(邦訳:アジャイルソフトウェア要求:チーム、プログラム、企業のためのリーンな要求プラクティス、翔泳社、2014)

Last modified 24 July, 2014

This information on this page is © 2010-2014 Leffingwell, LLC. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. For permissions, please contact permissions@scaledagileframework.com.