リーン開発_第6章_人

マネージメントシステム

「人を尊重する」という原則以外のすべてのリーン原則を実践しても、 リーンがもたらしうる利益のうち、ほんのわずかしか得られない。
逆に「人を尊重する」という１原則だけを実践すれば、人が残りのリーン原則を発見し、実践してくれる。

■ボーイング７７７の話

スケジュールの遅延の根本的原因を分析した結果、ひとつの結論に至った。 遅れが出たのは、人々が一緒に作業をしていなかったため、そして、問題を早期に発見しようとせず、問題が発生しても気に留めなかったため。 また、コミュニケーションが迅速かつ効果的に行われてなかった。

早期にテストをして、速く失敗する。

W・エドワーズ・テミング

テミングは４つの要点からなる「深遠な知識のシステム」を信奉していた。

1.システムの正しい理解

• どのようなシステムであれ、部分間の相乗効果がシステム全体の成功の鍵となると教えた。
• 製造をシステムと捉えていた為、その部分間の関係、つまり、企業内の部署間の関係や、サプライヤ、製造者、顧客の間の関係を管理する事が重要
• システム全体を見ることが基本であり、システムのどの部分であれ、部分最適化は全体の最高の利益にはつながらない。

2.変動についての知識

• 作業者がシステムに内在する問題のせいで、責められるのは言語道断。
• 一般的原因による変動、つまりシステムに内在する変動。
• この変動をシステムから排除しようとするのはムダで、状況を悪化させかねない。
• 低品質や低生産性の原因の大半は、そのシステムに内在するものであり、個々の作業者にはどうしようもないこと。
• 締切やスローガンは、システム上の問題の解決にまったく役に立たない。システムの動きを変える際のリーダシップが必要。

3.知識の理論

• 仮説を立て、実験し、学習し、学習を組み入れるという科学的手法のステップによって、計画・実施・監視、改善(PDCA)という有名なテミング・サイクルを生み出した。

4.心理学

• スキルや誇り、専門知識、自信、そして協力による影響が大きい。

品質に関する多次元的な観点をマネージメントの14項目としてまとめた。

<テミングの14項目>

• １．長期にわたって、必要とされる企業となる。
  端的な採算性に目を奪われてはならない。
  目標はビジネスで生き残り、雇用を生み出すことである。

• ２．世界は変わった、マネージャーも新しい考え方を取り入れなくてはならない。
  遅れやミス、欠陥品、質の悪いサービスは、もはや受け入れられない。

• ３．欠陥を発見するための検査に頼るのをやめ、製品を作る過程で、品質を作り込むようにする。
  統計的プロセス制御を採用する。

• ４．サプライヤは、入札額だけで選んではならない。
  誠実さと信頼に基づいた、長期的な関係をサプライヤとの間に確立し、それによって総費用を最少に抑えるべきである。

• ５．生産やサービスの提供のシステム改善するため、絶えず努力を続ける。
  改善は、一度で終わらせる作業ではない。
  システムの各活動は、ムダの削減と品質向上のため、絶えず改善されなくてはならない。

• ６．訓練を制度化する。
  マネージャーは、自分が監督している作業のやり方を知っていなくてはならず、また、作業者の訓練も出来なくてはならない。
  マネージャーもまた、生産のシステムを理解するため、訓練を受ける必要がある。

• ７．リーダシップを育てる。
  マネージャーの仕事は、人々がよりうまく仕事を出来るように手助けし、システム内において、彼らが誇りを持って仕事をするうえでじゃまになるものを取り除くことである。
  アメリカの最大のムダは、人の能力を活用できない点である。

• ８．恐怖感をもたせない。
  うまく仕事をするためには、身の安全を感じていなくてはならない。
  会社にとって最善のことと、今の作業に期待されていることが矛盾してはならない。

• ９．部署間の垣根を壊す。
  全員がお互いの考え方を理解できるように、部署の枠を超えたチームを作る。
  個人の成績を評価して、チームの協力関係の土台を崩してはならない。

• １０．スローガンや説教、到達目標の使用をやめる。
  欠陥や生産性を生み出すのは、人ではなくシステムなのだ。
  説教をしてもシステムが変わるわけではない。
  システムを変えるのはマネージメント側の責任である。

• １１．作業者への数量的ノルマや、管理者層の数量的目標をなくす（開発チームへの身勝手な締切をなくす）これは、恐怖によるマネージメントである。
  代わりにリーダシップによるマネージメントを試してみると良い。

• １２．技術者の誇りを奪う制度をなくす。
  時間給の作業者をモノのように扱うのをやめる。
  固定給の作業者には、毎年の査定をやめる。

• １３．全員に対して教育と自己改善を奨励する。
  教育を受けた労働力と管理層が、将来への鍵になるのである。

• １４．変化を遂げるための行動をとる。
  経営トップ層が、サポートするだけではなく、実際の行動によって変化を導いていかなくてはならない。

良いはずの活動がなぜ失敗するのか

• マネージメント改革を勝手な解釈に基づいて模倣しようとする企業はほぼ例外なく、革新の基本原則を見落としてしまう。
• マネジメントの常識は、経営者層の考え方にあまり深く浸透しているため、ほとんど無意識に信じられており、論破できない。
• マネージメント革新の根本にある原則が型破りであればその分、競合他社側の反応も時間もかかる。何十年もの間、手が打てないまま頭を悩ませ続ける場合さえある。

別の言い方をすれば、マネージメント革新の要点は、
その革新を真似しようとするほとんどのマネージメントチームには見えないもの。

• 例：
  トヨタの真の革新は、「普通の」従業員の知力を引き出す能力である。
  リーン導入を成功させるためには、何よりもまず、社員全員（特に、製品を作ったり、コードを作り出したりする「普通の」従業員）に対する深い敬意を基礎としなくてはならない。

チーム

人を集めてグループにし「チーム」と呼んだとしても、それでチームが出来上がるわけではない。
メンバーが、各自持つさまざまなスキルを出し合って、共通の目的のために共同作業をする、
というお互いの約束があってはじめて、グループはチームに変わる。

つりがね曲線

優れたソフトウェア製品を生むには、
第一に、アーキテクチャー、オブジェクト指向技術、コーディング戦略、データ構造、テスト自動化など、あらゆる分野での優秀な技術専門知識が必要となる。
優れた製品の背後にはからなず、その開発手法とは関係なく、優秀な技術者いるものである。

• 開発チームには
  目標達成に必要とされる専門知識を備えた人材がいなくてはならない。
• チームメンバーは
  特定のチーム目標を達成することを約束し合わなくてはならない。

協力し合い、必要とあればお互いに助け合って、確実にその目標を達成できなくてはならない。 チームに複数のスキルを兼ね備えた人材がいれば、お互いに助けやすくなる。

チームの全員が、第一に、チームの一員であり、次に、特定の分野におけるスペシャリストなのだ。
チームに完成させると約束した作業がすべてが終わるまでは、チームの誰一人として「仕事がおわった」ことにはならない。
そのため、全員が自分にできることなら何でもする。

チームリーダー

• １人か２人、顧客を深く理解し、技術を深く理解する人物がいるべきなのだ。
• それが２人の場合、お互いの意見を一致させ、２人で製品の成功に対する責任を負わせなくてはならない。
• 組織が新しいプロセスを実施するときには、プロセスリーダを立ててもいい。
• しかし、チャンピオンと緊密に協力し合うか、プロセスリーダー役をチャンピオンの役割として加えるかして、
  プロセスリーダーの役割をチャンピオンの役割をうまく同調させなくてはならない。

責任ベースの計画と制御

• ボートのチームにはコーチがいる。
• コーチは通常、メガホンを手にモーターボートに乗り、練習メニューを組み立てたり、改善点を指摘したりする。
• しかし、レースが始まれば、後はすべてチームに任される。コーチに出来るのは見ていることだけ。
• 責任ベースの計画と制御も、それと同じ原則で動いている。
• 十分に訓練された専門家に指図するのをやめて、彼ら自身に何をすべきかを見つけ出すように求める時期は来る。

スケジュールを約束するときに、心に留めておかなくてはならない重要な点がある。
それは、完成を約束した仕事をするための時間がかならずなくてはならないということ。
その仕事の細部は常に変化するということである。チームに厳しい締切を守って欲しいなら。
作業を許容量以内に制限しなくてはならない。

それにはいくつかの方法がある。

トヨタは、どのような開発サイクルであっても、必要な作業量を見積もるのがうまく、各職務がある程度平均して必要とされるよう、モデルの開発サイクルをずらしている。
さらに、トヨタは細かなスケジュールを決めようとはせず、各部門や各サプライヤに、チームメンバーが手助けを必要としているときはいつでも支援するよう、求めている。

スケジュール

1．タスクのスケジュールを立てないほうが良いですか？

　タスク完了日のように、本質的に変動しやすいものに対して、決定論なスケジュールを用いれば、 　本当のタスク完了日はスケジュールとかならず食い違う。
　タスクの完了日を変動させまいとするのは、テミングの教えのとおり、間違った手法にほかならない。 　変動は、システムに内在するものだから。

システム自体を変える必要があり、その選択肢は３つである。

• a．モンテカルロ・シュミレーションを行って、スケジュールの確実性をあげるという方法がある。
  しかし、この手法が最も効果的なのは、機能レベルでのスケジューリングの場合。

• b．後述するように、クリティカルチェーン・スケジューリングによってスケジュールにプロジェクトバッファを使うという方法がある。

• c．単に、タスクのスケジューリングを一切しない、という方法もある。その代わり、責任をベースとした計画と制御を行う。

2.WBS(WorkBreakdownStructure 作業分割構造)は必要ないのでしょうか？

• システム設計には欠かせない作業、主要なサブシステムの設計やインターフェース設計は必要である。

• これは機能のブレークダウン構造(FBS)であり、作業のブレークダウン構造(WBS)ではない。

• 【ＦＢＳ】Function Breakdown Structure： 　ものごとを行うためにはそれを実行する機能が必要である。 　裏返せばプロジェクト遂行は“まずそれに必要な機能(Function)を確保し、これを（メンバーの誰かが）実行すること”とも言える。
  

　タスクのスケジューリングをする代わりに、どのような機能を、いつ実際にデモとして動かすべきかを決定する。 　そのような機能を、実装できるだけのスキルと許容力があることを確認した上でチームにアサインして、チームに自分たちで作業管理させよう。

3.依存関係はどうしたらいいですか？

• まず、すべての依存関係が本当に必要だとは考えないほうが良い。

　個人やチームは、依存関係にあるタスクを、その目標が達成できるように実装しなくてはならない。 　聡明なシステム設計やオプションベースの開発手法（第７章の「集合ベース設計」を参照）を用いた上で、 　シンプルで効率的なコミュニケーションを取り合えば、依存関係に対処する最高のツールになる。

自律的な作業

• 多くのことを本当にすばやくやるには「人に作業を与える」という戦略から「人が作業を自律的に行う」という戦略に切り替えなくてはならない。

• 作業を与える場合 他の人の作業ステップをいちいち計画しなくてはならない。 作業を自律的にするためには 指示を受けなくても各自がどのように作業を行えばよいのかわかる環境を作り上げなくてはならない。

• 多くのことを素早くやらねばならない場合 作業を自律的に行うのが、唯一うまくいく手法。
  

作業が自律的であれば、朝職場に現れた全員が、指図されなくても、正確にやるべき仕事を把握できる。そして、もっとも重要な仕事を選んで取り掛かるだろう。
仕事を終わらせたら、次にすべきことが見えてくる。
一日のうちいつでも、質問が出たときに見回して、すぐにその答えがわかるような職場にする。

自律的な職場を作るには３つの重要な情報ツールに着目しなくてはならない。

かんばん、あんどん、ダッシュボード

かんばん

• かんは、日本語で「見る」、ばんは日本語で「板」のこと。

かんばんに関して、肝となるのは、次の作業の選び方ではない。 それは簡単だから。
本当に難しいのは、カードが選ばれたときに次に取り掛かるのにふさわしい分量の作業内容がカードに十分書き込まれているよう、カードの内容や場所を確実かつ正しく保つという点

カードは作業仕様ではない、それは、次の仕事に向けて、カードに書かれたストーリーを詳細設計したり検証したり実装したりするのにふさわしい人材を集めるための合図。

作業を自律的にするために、どのような仕組みを使うにしても、多少の思索や実験が必要になる。
それぞれの仕事が、簡潔に説明されていなくてはならないし、作業のセットは完全かつ正しい順に並べられていなくてはならない。
作業の提出や選択のルールにより、その作業を上手にできる専門知識を備えた人が作業するよう、保証しなくてはならない。

あんどん

• トヨタでは「あんどん」という言葉を「ライン・ストップ」させるために引っ張る紐を指して使っている。

あんどんの紐を引くと、通常ライトがついて、問題がおきている場所に注意を喚起させるから。 あんどんの背景には「すぐに解決できるように問題を開始化する」という考え。

駅に設置された出発ホームを表示する掲示板は、あんどん板と呼ばれることがある。
あんどん板は、注意すべき異常に気を向かせ、変わりゆく状況に応じて表示を変え、頻繁に手が加えられている箇所（例えば、どのサーバが今のテストサーバなのか）を示す。

ダッシュボード

• チームが自分たちの作業進捗を、状況に即して、そして、より広範囲な会社の目標に即して目にするのは重要なこと。
  

そのために、いろいろな種類のダッシュボードを用いる。
バーンダウンチャート、作成・実行された受け入れテストのグラフなどは非常に役立つ。
複数チームにまたがる作業の全体的な進捗状況は、中心となる「戦術ルーム」に全員が見れるように貼っておくのがよい。

その場合、電子ダッシュボードが最適ツール 電子ダッシュボードは、手で作るよりも電子的に生成したほうが簡単な、主要メトリクスを算出するのにも便利。

インセンティブ

• 企業が死ぬのは、マネージャーたちが製品やサービスを生み出す経済活動ばかり意識を向けて、組織が本来、人のコミュニティであると言うことをわすれてしまうためである。
• 人々が仕事に対して関心を持ち、信頼し、熱中する度合いは、収益に直接的な影響を与えるだけでなく、企業の予測寿命に何よりも直接的な影響をあたえるのである。

業績評価

• テミングのアドバイスの中で、最も無視されているのがこれ

「従業員に対する毎年の査定をやめる。個人の成績を評価して、チーム内の協力関係の土台を崩してはならない」
毎年の能力評価で、思いがけないフィードバックをして、社員を驚かしてはならない。
能力評価のフィードバックグループは１年（あるいは、四半期）も一度の査定サイクルよりももっと短くあるべきだ。
毎年の能力査定のときだけ、従業員にとって自分の働きぶりを知る機会なのであれば、その評価システム自体に真の欠陥があるということだ。

能力査定の基準では（もし現状がそうであれば）、個人の業績よりも、チームの成功への貢献を重視し、チームワークに重点を置くべきである。

結果として、得られるのは、評価する対象なのだ。つまり、協力関係を評価する効果的な方法を見つけられれば、協力関係からもっと多くのものが得られることになる。

効率に関する問題は、マネージャー側の問題である
マネージャーは組織の業績に対する責任を負い、システムの効率を改善するために、部下と協力しなくてはならない。

ランクづけ

• リーンな世界では、わざわざ誰かを非難するようなことはしない。

誰でも同じ失敗でをしていたかもしれない。非難する代わりに、 その問題が二度と起こらないように、システムのポカヨケを備える方法を見つけ出そうとする。

リーン開発_第5章_スピード

スピードが出せるということは、ムダがないということだ。 スプリント≒並行反復イテレーション

ペイシェント・キーパー社の場合

PatientKeeperのホームページ

• すべてのスプリントを、最終的に製品リリースに結びつける。
  
• 品質保証部は、開発者が最初のコードを更新するとすぐにテストに取りかかる。品質保証部は、独立してビルドプロセスを開始でき、また任意のあいている品質保証用サーバでビルドしても良い。
  
• スプリントの中盤までに、インストールチームがリリース候補１を顧客に導入する。そこで顧客は、内部の品質保証部門と並行でテストする。
  
• 顧客から問題のフィードバックが届き始めるとすぐ、品質保証部が見つけた問題と合わせ、開発者が問題を解決する。
  
• 機能要求は、顧客が絶対必要と考えれば、スプリントの終了直前まで出し続けてかまわない。急な要求であっても、受け入れる、それによって、製品がすべての顧客にとって、より速く、より良いものになるためでもある。
  
• 通常、稼働までに２〜３のリリース候補を出す必要がある。すべての開発タスクを完了し、すべての品質保証上の問題が解決され、すべての顧客問題が完了する。そして、品質保証部はシステム全体へ回帰テストを終えている。
  
• スプリントの終わりに、すべてを新しいソフトウェアに切り替える。ときには、何百という医師用PDAユーザや数千のウェブユーザを持つ、複数の病院を結ぶシステムの場合もある。通常はスプリントの最後に３〜５組の顧客に対応する。
  
• すべての顧客が、目立った重大な問題なしにシステムを使うことができれば、それで完了である。このシナリオでは、品質保証部と開発が密接に関係するのと同様、顧客と導入チームも密接な関係にある点に注目して欲しい。

ジェフ・サザーランドは

すばやいタイムサイクルを次のように説明

• 学習量を増やす
• バグだらけのソフトウェアをなくす。直さないとひどい目に遭う。
• 導入プロセスをすっきりさせる。年間45回も導入しなくてはならないのに、インストールが面倒だったらやっていられない
• アップグレードプロセスを改善する。必須のアップグレードが常にあるので、プロセス改善によってアップグレードが簡単になる。
• 持続可能なペースでの実装が徹底される。そうしなければ、消耗死することになる。

時間：普遍的な通貨

• 時間（特に、タイムサイクル）は、なにかが間違っていることを警告してくれる、リーンの普遍的な計測基準である。

タイムサイクル

• 有効な開発プロセスとは、確実かつ繰り返し可能なペース
• 認識した顧客のニーズを顧客価値として提供するプロセスのことである。
• 組織にペースを与え、価値の流れを引き起こし、製品に品質を作り込ませ、企業の許容能力を明確化するのがタイムサイクル。

ソフトウェア開発プロセスの品質を計測する

• 開発から終了までの平均タイムサイクルを計測をするのがいちばん。
• 顧客のニーズかが出されてからそれを満たすまでにかかっている平均時間を計測しなくてはならない。

誤りの計測方法

• 特に、繰り返し確実に、コンセプトをキャッシュに変えていくには、あるいは顧客の注文からソフトウェア導入までにこぎつけるには、平均としてどれだけの時間がかっているだろうか？このタイムサイクルの、一例だけを計測するのではないという点がミソ。

リリースサイクルを設ける

• 2週間毎、6週間ごとでも、6ヶ月ごとでも自分たちにとって現実的な期間で良い。
• 管理可能な、なるべく短い期間が良い
• 一度のリリースで完了できる業務量を見極めて、それ以上の作業は受け付けない。
• 何かが出来てないからといって、リリースを遅らせてはならない。
• 定期的なリリースが行えない状況なのであれば、プロジェクトの上限を設定できるように（必死で）努力しよう。目標は、6ヶ月ぐらい。
• プロジェクトの規模に上限を設けたら、プロジェクトを２つか３つにグループ分けしよう、緊急、小、大などのカテゴリに分ける。それぞれのカテゴリにおける「サービス水準」に達するよう努める。
• 開発作業がどれだけ大規模で、小さなスッテプに分割し完成できる。

リトルの法則

• リトルの法則とは 安定したシステムにおいて、何かがあるプロセスを通り抜けるまでにかかる平均時間は、
  そのプロセス内にあるものの数を其の平均完成率で割った値に等しいという主張である。

リーン開発組織の目標はサイクルタイムの短縮

• 短縮する方法の１つめ 速く完成させること、つまり平均完成率を上げればよい。

• 短縮する方法の２つめ（開発資金に余裕がない場合） プロセス内のものの数を減らすという方法。

変動と使用率

• リトルの法則で不安定なシステムになる要因

要因１：変動

• 例：ソースコードを統合しなくてはならなくなった場合 それが、６週間分の作業なら、確実にたくさんの問題が起きる。 しかし、６０分の作業であれば、過ちの量も限られてくる。

大規模なプロジェクトならスケジュールの変動も大きくなる。 小規模のプロジェクトならスケジュールの変動はそれよりはるかに地位いさくて済む。

要因２：高い使用率

開発者のプロジェクトに対する使用率（稼働率）が80%を超えると開発速度が落ち、 タイムサイクルも長引き始める。

• 例： 道路の使用率が80%を超えると、車の流れが滞り始める。 そこにほんの数台車が加わっただけで、すぐにノロノロとしか運転できなくなる。のと同じ

小さな仕事に分割して、割り振りを行う流れを意識すれば、実際には効率が良くなる。 ただし、決して使用率を最優先の目標にすべきではない。

サイクルタイムの短縮

待ち行列理論は、サイクルタイムを短縮するための教科書的な方法をいくつか提示してくれている

• 1.作業の到着率を平準化する
• 2.プロセス内のモノの数を最少化する
• 3.プロセス内のモノのサイズを最小化する
• 4.一定のリズムを確立する。
• 5.作業を許容範囲に制限する。
• 6.プル型のスケジューリングを利用する。

1．作業の到着率を平準化する。

すべてのリーンプロセスにの核心には、均一の作業レベルがある。

• 例 工場では、月間１万の部品を作るという計画が、毎分１部品という意味になる。 そして、その工場での作業は、毎分１部品という決まった速度で生産するように調整される。

開発作業の安定した流れを作るということになる。

開発プロセスの最初に待ち行列があれば、開発組織に同じペースで仕事を出せるため、 待ち行列の置き場所としては適切であるように思える。 しかし、そのような待ち行列の長さは、作業到着の平準化に必要な程度まで抑えるべき。

2．プロセス内のものの数を最小化する

• 開発の場合 リリースサイクルは長く、商用リリース前にいろいろなことを積み上げておく。 承認プロセスのせいで、組織の対応能力を大幅に超える作業が、一挙にまとめて詰め込まれる。 シーケンシャルなプロセスにより、まとまりのない作業が大量に出来上がる。欠陥は長い待ち行列を作っている。

一般的にやるべき作業の長い待ち行列は、非現実的で不要である。

待ち行列を対処するアイデア

• 1．まずは「この待ち行列の中で、現実的に考えて絶対に対処することのない項目はいくつのあるのか？」と問いかけよう。どう考えても作業に着手することがないと思う項目を、今すぐすべて削除。

• 2．次に残っている項目だけを選び出し、パレート分析を行う。 それぞれの項目に、１〜５までの点数をつけよう、絶対に必要な項目には、５点。あまり重要ではない項目には、１点をつける。 それが出来たら、４点と５点のもの以外はすべて消す。

• 3．ここで、残された項目だけを選び出し、それが何日分、何ヶ月分、何年分の作業になるのかを計算する。 この先もっと重要な、ほかの項目がリストに加わるだろうか？ それを考慮したうえで、あなたには、リストにある残りの項目の近い将来にこなせるだけの力を蓄えているだろうか？もし、ないのなら、追加の要員を加えるべきだろうか？

• 4．リストが依然として現実的でないくらいに長いのなら、すべき事とすべきでない事を効果的に決定する以上の、くだらない要求をはなつけたりするために長いリストがあるのかもしれない。 もしそうなら、そのリストを２つに分けよう。ひとつは外部向けのリスト、もうひとつは短く保ち、残作業を減らしていくためのリストにする。

3．プロセス内のもののサイズを最小化する

リーンな視点からで見れば

• リリースとリリースの間の時間を延ばすのは、まったく正解とは逆方向に進むことになる。
• リリースに時間が長くかかりそうでも、リリースまでの時間を延ばすべきではない。
• それほどに時間がかかっている原因を見つけ出し、それを解決しよう。
• 苦手なことでも、頻繁に行えばずっとうまく出来るようになるはず。

4．一定のリズムを確立する

• イテレーションは開発組織のリズムである。
• 作業がむらなく流れていれば、正しいリズムだということ。
• イテレーション終わりに大騒ぎするようなら、おそらくイテレーションが長すぎる。
• イテレーションを短くすれば、作業負荷が平準化される。
• イテレーション間隔は、顧客がイテレーションの終わりまで、変更依頼を出さずに待てる程度に短く、システムを安定させる程度に長くする。

5．作業を許容範囲内に制限する

• 開発組織では、時間をいくらでもひねり出せると思っているふしがある。
• 一時的に集中して残業を行えば、より多くの作業を済ませられることもある。
• しかし、残業漬けは長続きしない。疲れて注意散漫になる。
• スピードアップするどころかスローダウンすることになる。

組織が許容能力を大きく超えた作業をこなそうとして、スラッシングを起こして、 作業がまったく進まなくなってしまうこともある。 開発の重要なメンバーが対応能力を超えるほど酷使されると、そうなってしまう。

6．プル型のスケジューリングを利用する。

• 一度のイテレーションで完成を約束する作業を選ぶ場合、ルールとしてチームメンバーは完成させる自信がある（細かくブレークダウンされた）項目だけを選択しなくてはならない。
• チームが妥協な作業のみを選択するために必要な情報は数回のイテレーションを行えば、作業量が把握できるので得られる。
• 実際に、開発チームは待ち行列から作業を「プル」しているのだ、このプルの仕組みによって、チームに期待される作業量が、チームの許容範囲内に制限される。
• プルシステムのよって、作業のゆとりが生まれる。

待ち行列は、便利なマネージメントツールである。 待ち行列によって、マネージャは開発チームに自分で作業を管理させておきながら、 優先順位を変えたり、サイクルタイムを管理したり出来るようになるかである。

待ち行列を使うには一般的なルールがある

• 1.待ち行列は短くなくてはならない。おそらく、作業の2サイクル分あたりが適当だろう。その程度の長さであれば、開発プロセスの間中、要求の平均サークルタイムを管理できる。
  
• 2.マネージャーは、待ち行列にある項目をいつでも改定したり、変更したりできる。しかし、一旦チームがある項目に着手したら、マネージャーが日々の開発作業に干渉してはならない。
  
• 3.チームは、待ち行列から作業をプルし、その作業が完了するまで、一定のリズムで作業を行う。プルシステムによって、作業を許容範囲に収めながら、常にチームに仕事を与えられる。
  
• 4.待ち行列がありさえすれば、チームに応対する時間がなくても、そのうち要求に応対してもらえる。という誤解を与えてはならない。

リーン開発_第4章_ムダ

ZARAでは技術適用する際に５つの原則をあげている

1．ITは判断を支援するものであり、判断を下すものではない

• 情報システムは、経営者が意思決定をする際に必要となるデータの整理を手助けするものである。
• 情報システムがを意思決定するわけでも、提案するわけでもない。

2．コンピュータとは、標準化することであり、目標を絞る

• 販売店であれ地域であれ、共通の企業システムの枠からはみ出すことは許されない。
• 開発者はシステム機能を最大にするのではなく、最小に絞る。

3．技術の導入は内部からはじめる。

• ビジネス目標が、常に企業における技術の使い道を規定する。その逆はない。
• IT部門が、ラインのマネージャとともに働き、彼らが必要とするものが何かを理解してから、利用可能な技術を探するのである。

4．プロセスが焦点である。

• 販売店のPDAは、マネージャの使う「個人用生産工場機器」ではない、PDAは毎日の販売のレポートと、週２回の発注や発送を支えている。
• PDAが全店にわたって一貫したプロセスを浸透させている。

5．組織全体で一丸となる

• CEOにITマネージャーの経験があることは有益だが、ビジネスとITを統合するにはそれだけでは足りない、ビジネス側の人間と、技術側の人間が互いの世界を本当に理解し合う。
• 我々と彼らと分けたり、ソフトウェアを壁越しに投げたりするようなことがあってはならない。

複雑さ

• 市場の需要が明確になるまで、機能は作ってはならない。
• 不要なコードを書くぐらいなら、開発者にはサーフィンでもしてもらったほうがよっぽどいい。
• 結局使わないコードを書いても、システムが稼働している間ずっと代償を払うことになる。
• 必要最小限の機能ごとに開発しない理由はない。

複雑さを自動化するな

• プロセスを自動化する前に、まず取り組みべきことは、明確化と単純化であり、既存の自動化さえ取り払うことを考慮する。
• そうして初めてプロセスがはっきりと理解でき、効果的な自動化のポイントが見えてくる。
• プロセスに必要なのは単純化であり、自動化ではない。
• 自動化により、今ある複雑さを封じ込めてしまったら、注文プロセスも単純化するチャンスを失ってしまうはずだから。

7つのムダ

• 1．未完成の作業のムダ
• 2．余分な機能のムダ
• 3．再学習のムダ
• 4．引き継ぎのムダ
• 5．タスク切り替えのムダ
• 6．遅れのムダ
• 7．欠陥のムダ

未完成作業の例

1．未完成の作業のムダ

• コード化されていないドキュメント
• 設計や要求を記録したドキュメントが書棚に置かれている期間が長いほど、それだけそのドキュメントには変更が必要になる。
• 要求が変更されるのは、顧客にすれば要求が書かれるのが早すぎるだけ。

2．同期されていないコード

• 作業スペースや並行で開発されるコードは、出来る限り頻繁に同期すべきである。別々に存在する期間が長いほど、マージも困難になる。

3．テストされていないコード

• 欠陥をすぐに検知するに方法を備えずにコードを書くことは未完成の作業という在庫を作り出している一番の近道。
• コードの結合、テスト、受け入れが完了している状態でなければ「完了」にはならない。

4．ドキュメントのないコード

• ドキュメントが必要なら、コードと同時に書くべきである。
• 理想はコード自体がドキュメントの役割を果たすべきだが、それ以外のユーザ向けドキュメントやヘルプ画面も必要になる。
• テクニカルライターもまた開発チームに属するのでドキュメントは必要

テクニカルライター

専門的な技術に関する文章を書くライターです。
テクニカルライターの業務には、製品の取扱説明書などを書く
「マニュアルライティング」と、技術的な文章を翻訳する「技術翻訳」があります。

5．導入されていないコード

• 環境によっては、理想的な頻度でコードを導入できない場合もある。
• 新しいソフトウェアが、顧客の今している仕事の邪魔になることもある。
• しかし、出来るだけすぐにコードを導入するように務める出来である。
• 事実、ユーザは少しずつ変化を吸収していく方が楽な場合が多い。
• すぐに導入したほうがトレーニングの量が少なく、混乱も最低限に抑えられる。

余分な機能のムダ

• １．常識的に考えよう。これはガイドラインに過ぎないことを忘れないでほしい。
• ２．顧客の仕事に焦点を合わせる。ある仕事に必要なソフトウェアを作り出すのに、イテレーションが数回分かかったとしても、仕事上、絶対に必要な機能であるならばムダではない。
• ３．出来る限り機能を追加しない。機能の必要性について、いくらかでも疑問があるなら、時期尚早ということだ。手を付けずに待とう。
• ４．すぐにではないが、後で機能を追加できるようにアーキテクチャじょうにの仕組みを作るのは良い。ある企業向けに再利用可能なサービス「フレームワーク」を抽出するとよいかもしれない。ただし、何でも設定できるような仕組みを持ったアプリケーションフレームワークは、これまでの実績から考えると、失敗に終わる可能性が高い。その違いを理解しよう。

再学習のムダ

• 設計書などのドキュメントを作成しても二度と見ないので、再度、調査を行い同じ発見や仕様を学ばなくてはならない。
• 上記を効果的に達成するのに役立つ知識を記録しておく手法をチームと協力し合って考え出そう。第７章でさらにアイディアを紹介。

引き継ぎのムダ

• 引き継ぎは乗り方を知らない人に自転車をあげるのに似ている。
• 乗り方について教本をあげてもいいが、調子が出るまでバランス感覚を掴む手伝いをしたほうが良い。
• ちょっとしたアドバイスをするほうが、たとえ言葉で説明しなくても、すぐに乗り方がわかるようになるはず。
• このような知識は「暗黙知」と呼ばれる。
• 暗黙知は、ドキュメントではなかなか他の人に引き継ぎにくい。

引き継ぎによるムダを減らす方法

• １．引き継ぎの回数を減らす。
• ２．設計、構築チーム（部署の枠を超えた完全なチーム）を作り、チー ムメンバー同士でお互いに乗り方を教えられるようにする。
• ３．コミュニケーション料を増やす。ドキュメントでは、ほぼすべての暗黙知が取り残される。ドキュメントの代わりに、顔を合わせて議論をしたり、直で見てもらったり、モックアップやプロトタイプ、シュミレーションで対話方法を見せたりしよう。
• ４．作業に対するフィードバックがもらえるよう、検討材料として、部分的な作業や試験的な作業リリースをする。現実的な範囲で出来るだけすぐに頻繁にリリースすること。

タスク切り替えのムダ

• 同時にいくつものタスクに取り組むことは通常意味がない。
• タスクが３つあり、１週間毎に一つずつ取り組んでいけば、１週間毎にタスクAの価値が出て、タスクBの価値が出て、三週間後にはすべてのタスクが完了し、その頃には多くの価値が実現されている。

３つのタスクを同時に取り組んだ場合。

上記と比べて、３週間後にも完成できているタスクは一つもない。 タスクを完了させるのにムダな時間が必要となるばかりではなく、完成させれば提供されていたはずの潜在的な価値もムダにされている。

開発と保守を行う手法の例

• 1.チームから２人ずつ選出し、月ごと、あるいはイテレーションごとの交代制で、２人の期間中のすべての保守作業を担当させる。
• ２．毎日、午前中の２時間を、チーム全体で過去の24時間に発生したすべての問題に対処する時間にする。その後に毎日の進捗ミーティングを行い、残り時間は新規開発に集中する。
• ３．保守要求を積極的に選別し、緊急の作業のみ、すぐに対応する。１〜２週間に一度、時間をとって、大きな保守案件に対応する。 その周期が十分に短ければ、ほとんどの要求に待たせておくことが出来た、要求がなくなることさえあるだろう。このテクニックは、保守作業の平準化に役に立つ。
• ４．すべての顧客に１つのコードベースで対処し、毎週新しいバージョンをリリースする。どのような問題もすべて、このリリースで対応し、問題を抱えている顧客には、最新バージョンにアップグレードしてもらう。

遅れのムダ

開発者が待つ場合、以下の３つの選択肢がある。

• １．作業を中断し答えを探す。
• ２．他のタスクに切り替える。
• ３．ただ推測して作業をすすめる。

上記は３つは間違った手法である。

• 解決として 完全なチームを１ヶ所に集めて、定期的なフィードバックが得られる短期イテレーションを用いれば、遅れは大幅に減り、決定の質も上がる。

ソフトウェアはどうしてそんなに時間がかかるのですか？

• １．開発者は、我々が何が本当に欲しいのか示さないかぎり、問題解決にとりかからない。どうやったら何がほしいかわかるというのか？
• ２．開発者はプロジェクトの承認を得るために、何ヶ月も待っている。
• ３．開発者が担当が決まるまで、延々、待っている。
• ４．担当になって人たちが手が空くまで待っている。
• ５．いらただしい変更承認プロセス。何ヶ月も待たせておいて、こちらのビジネスに変化が起きてないとでも思うのだろうか？
• ６．今まさに必要になっている重要機能を手にするのに、システム全体が出来るまで待っている。
• ７．コードがテストを通るまで待っている。どうしてテストにそこまで時間がかかるのか？
• ８．新しいソフトウェアが、既存のプログラムをめちゃくちゃにしないようになるまで待っている。あるいはその逆。やってみなくてはわからない。

欠陥のムダ

アジャイルチームでは欠陥発生率が極端に低い、それはコードにポカヨケを施し、欠陥が日常的に発生しないようにすることを最重要視しているからである。
そして、第２に、できるだけ早期に欠陥を見つけ、同様の欠陥の再発防止策を探すことを重視している。

重要： テストファーストの考え

コードを書く前に単体テストを書くことで、シンプルに理解しやすく、テストしやすいコードになる。 テストがコードや最終的な製品が、どのように動くことになっているのかを正確かつ詳細に教えてくれる。だからテストはシステムの最高のドキュメントになる。

広範囲にわたる要求仕様書を書いてきた組織であれば、実行可能な仕様としてテストを書くことで、仕様を書いたり、仕様書からコードを追跡したりするのにかかる時間を、大幅に短縮できるのである。

顧客の環境でテストできないので、かならず欠陥が見つかる。

改善活動を立ち上げ、インストール時に頻繁に起きる失敗を箇条書きにして、根本原因の解決に優先度の高いものから取り組み、顧客現場での欠陥発見がほとんどなくなるまで、やり続けよう。

バリューストリームマップ

ムダを表出化するのに非常に効果がある。

流れの中での遅れは間違いなく、重要なムダがあることのサイン

• 長期の遅れ(待ち行列がある暗示)
• 差し戻し(揺れ動きが起きている暗示)

を探すことでプロセスに潜むムダが浮き彫りにされる。

準備

開発の場合、難しい事が多い。代わりに平均的なプロジェクトを１つ選んでマップにすると良い。
よくあるのは、保守要求を３つのカテゴリにわける。 カテゴリごとに解決時間を約束するというもの。

例：

• 非常に緊急の問題ならば２時間以内
• 重要な問題ならば１日以内
• 些細な問題であれば２週間毎の次回リリースで対応

など。

時間軸の開始と終了を選択する

目的はコンセプトをキャッシュに変えるまでのバリューストリームマップを描くことである。

• 組み込みソフトウェア開発の場合 時間軸の開始は、顧客のニーズが明確になった時か、または組織が製品の開発を確約した時点であり、 終了は製品が世に出たときである。

• 顧客要求を受け入れてソフトウェア開発を行う場合 要求を注文とみなし、顧客要求が出された時点から、時間軸を開始するのが一般的。 顧客が気がかりなのは、自分たちが出した要求が対応されるのに、どのくらいの期間がかかるのかである。

バリューストリームオーナーを見つける。

• 顧客要求の責任者がいないと、人々は境界内にこもって部分最適化ばかりしてしまう。
• 要求は、待ち行列の中で承認前に陳腐化してしまうか、延々と放っておかれたあげくに別の機能に変更されるか、永久に導入されないかである。

システム全体にわたって顧客要求に責任をもつバリューストリームオーナーがないのは、ムダの根源に取り組む権限を与えられた人がいないも同然

シンプルに保つ

• バリューストリームマップは、ムダを発見を手助けしてくれる診断ツール。
• 目的は、ムダを排除するために、ムダを発見する方法を学ぶこと。
• バリューストリームマップを利用することで顧客の眼鏡をかけ、顧客の目で開発のプロセスが見れるようになる。
• 目標は１〜２枚の紙に、顧客が注文してから、顧客が満足するまでのプロセスを１０個程度の大まかなステップに分けて、マップに描くこと。

重要なのは、最初から最後まで、コンセプトがキャッシュに変わるまでを隙間なくつないでいくことであり、狭い範囲を細かく掘り下げることではない。

マップを描きあげたところで、２つの質問に答えて欲しい。

1.製品の開発が終わるまで、あるいは顧客の要求が満たされるまでに、どれだけの時間がかかるか？(経過時間であって、実際の作業時間として計上する時間ではない)
2.経過時間に対して、実際に価値を付加するのに使った時間は何パーセントか？(これを「プロセスサイクル効率」と呼ぶ)

実際利用してわかること。

• 開発者のリソースを完全に食い尽くそうという幻を追い求めると長い待ち行列になる。
• 実際には、優先度の低いタスクでゆとりを作り、優先度が高いタスクにジャストインタイムでスケジュールすることで、待ち行列にかかるオーバヘッドを取り除いている。
• リリースは定期的でも結合テストを頻繁に行わないと最終テストでいつも欠陥がみつかるのでは、テストが遅すぎる。目標は早い段階で見つけることだ。

バリューストリームマップとは

コンセプトから製品を世に出すまで、もしくは機能要求からコードを導入するまでのステップの時間軸である。 マップが描きあがったら、揺れ動きと遅れを見つける。

• 揺れ動きはタイミングの問題を示す。
• テストと修正の揺れ動きは、テストの開発と実行が遅すぎることを示す。

• 組織が成し遂げられる量まで仕事を制限すると、仕事がシステムを通過するスピードがとても速くなる。

• 遅れはさらに組織的境界を示している場合もある 仕事の準備ができていない組織に仕事を引き継ぐと遅れが生じる この対処方法は、引き継ぐ前に受け取る側の組織の人に深くかかわってもらうことである。

将来のバリューストリームマップ

• 将来のマップを理想のマップにしてはならない。
• すぐに改善にとりかかるための道筋が示されている必要がある。
• 最も大きな遅れ、最長の待ち行列、最悪の揺れ動きを把握する。
• ３〜６ヶ月以内で、組織が到達できる１つから３つの鍵となる変更を示す新しいマップを描こう。
• それらに変更があったときが、新たな現状のバリューストリームマップを描くときである。
• 次に重要なのは、取り組むべき部分をピンポイントで示してくれる。

リーン開発_第3章_価値

Google社の場合

製品開発にはフィージビリティスタディ(実現可能性調査)が必要である。

システム設計

製品が見えてくるにつれて進化していくものであるという事を心得た上、スムーズに先に進めれるよう その進化をきちんと考慮に入れられる経験を積んだ設計者によって行われなくてはならないのである。

1．価値　ユーザに焦点を絞れば「結果」は自然についてくる

　開発チームの命題はレーザのようにピンポイントでユーザにフォーカスした製品を開発する事だった 　その製品が広く使われるようになったら、スタッフは利益を生み出す方法を見つけ出すように求められる。

2．卓越性　1つのことを極めてうまくやるのが一番

　グーグルという組織は、彼らが作る検索エンジンと同じように、やるべきことを本当にうまく果たせるように作られている。 　高い技術力があればこそ、一度にいろいろな実験をし、試してみる柔軟性がうまれるのだ。

3．民主主義　民主主義はウェブでも通用する。

　グーグルでは、新しいアイディアを思いついたら参加者を募り、一定数以上の賛同者を集められれば、 　実現へ踏み出すことが出来る。製品は、グーグルラボに掲載され、ユーザの興味を引くことで成長していくのである。

4．スピード　遅いより早いほうがいい

　グーグルでは、他社で何年もかかることがすばやく、何日間、何週間という単位で起こっている。

　フィージビリティスタディの段階でシステム設計が十分に行われているのなら、たいていの場合、 　パイロットの段階で顧客へのソフトウェアリリースは有益である。

喜ぶ顧客

• 機能追加によって性能を向上
• 顧客が気づいてすらいないニーズを発見し、そのニーズを満たして喜ばせる。

満足度を指数的に伸ばしたいのであれば、満たされていないニーズを発見して満たし、 それによって顧客に驚きと喜びを与えなくてはならない。

素晴らしい製品は、ただ顧客の要求を聞いているだけでは生まれてこず、 顧客の世界を深く理解し、満たされていないニーズを発見し、そのようなニーズを満たして 顧客を驚かせることによって、生まれてくるものである。

すばらしい、ソフトウェアはビジネスを理解している人物と技術を本当に理解している 人物との意気投合から育っていく。

顧客を重視する組織

リーダシップ

• チャンピオン(製品統括責任者を指す)
• チャンピオンは、顧客の作業や、顧客に驚きと喜びを与える技術を理解する人物。
• チャンピオンには、製品に関する重要な決定を下す責任と決定した結果に対する説明責任がある。

チーフエンジニアを立てるという、手法には多くの情報を責任ある一個人の頭の中に統合できるメリットがある。 チーフエンジニアにとって、適切な訓練環境がない企業や、チーフエンジニアは知識の統合よりも 業務管理に注力すべきだと考えている企業ではこれが問題となる。

リーダシップチーム

• 二人のリーダーを立てることのが最良の道になることもある。
• 一人は市場を深く理解する人物、もう一人は技術的なリーダー

リーダシップチームのメンバーは、開発チーム全体の方向性をひとつにまとめ、 いわば「一心同体」にならなくてはならない。

共有リーダーシップ

• チーフエンジニアではなく、専門家集団が開発

専属チームが組まれ、メンバーが1ヶ所に集め。多くの時間を進捗具合の見直し、 教えあったり、問題を解決したりするのに費やした。 チームリーダの第一の仕事は、開発プロセスを管理し、メンバーの連携やチームの意思疎通を促したり、 意志の統一を求めたり、チームを正しい軌道から外れないようにすること。

責任は誰にある？

• 市場ニーズを明確にし、ポイントとなる製品特性を決定するために他チームと協業する。

このチャンピオンとビジネス上重要な機能を持つ全ての部署から集結したチームの組み合わせが、 何十年も会社を支える。
トヨタの原則「チームワークは質の高い仕事を成し遂げる鍵になるが、誰かが必ず責任をもたなくてはならない」 的確な意思決定は、有能な組織の証拠であり。意思決定の役割を明確にすることが、 聡明でタイムリーな決定を下すうえで欠かせない。

完全なチーム

• ソフトウェア開発で、製造しやすい設計にあたるのが、「運用しやすい設計」である。

目立ちはしないが、ソフトウェア開発チームには、 コンピュータ操作、ネットワーク構築、保守、顧客サポートという役割がある。 ソフトウェアを実際に製品として使われたときからどのような問題が起こるのか、

そしてそのような問題を避け、問題から復旧するために必要な機能は何かを考え、 チームにつきつけるメンバーが開発チームには必要である。

ソフトウェア企業とIT部門が異なる点

マーケティングというステップを飛ばしてしまう事があまりに多く、 作った製品がビジネス上のニーズに合わないとこに驚かさられることになる。

IT部門には、ソフトウェア企業のビジネス継続に不可欠な、 費用対効果をつり合わせるための施策を実施しようとする動機づけがほとんどない。

開発成果物がビジネスの成功に貢献しない限りIT部門の成功もない。

リーン開発_第2章_原則

ソフトウェア開発の７つの原則

１．無駄をなくす

• 1-1．無駄なコーディング、無駄な機能は減らす。
• 1-2．テストの段階で必要のないテストによるバグや修正が入り大幅なコスト増になる。

２．知識を得る

• 2-1．最小限の機能セットを早期に顧客にリリースして、評価とフィードバックを得る。
• 2-2．毎日ビルドして、統合テストからすばやいフィードバックを得る。
• 2-3．経験と直感を備えたチームリーダに適切な決定を下させること、新規機能が追加しやすいモジュールアーキテクチャーにする。
• 2-4．市場から学習を得て成長するシステムが市場受け入れ度が高い。経験論的な制御システム（フィードバックに基づく制御システム）

３．品質を上げる

• 3-1．テストは最後にせず、作っている段階から行い欠陥分は後回しにぜず、その時に対処する。 そのことにより、後々欠陥による身動きが取れない状況を防ぐことが出来る。

４決定を遅らせる

• 4-1．初期の機能開発で重要な設計について将来変更しづらい決定をしてはならない。
• 4-2．変更が起きそうなポイントでは複数の選択肢を持ち続ける必要がある。
• 4-3．システム開発は不確実性だから、いろいろなソリューションを実験して難しい問題に対処するのがいい。
• 4-4．取り返しのつかない決定はできる限り遅らせるのが得策

５．早く提供する

• 5-1．顧客に気を変える時間を与えないためにソフトウェアを早く提供する方法を見つける。
• 5-2．安心して決定を任せられ、最後まで助け合える思考力のある人材が専任で必要である。
• 5-3．許可を得なくても問題を解決し、変化に適応でるように作業が構造化されている。

６．人を尊重する

作業を行う人の視点からの尊重３つの基本理念

１.起業家的リーダー

• 人を尊重する企業は、優秀なリーダーを育て、彼らにリーダーシップを発揮させることで、 さらに熱心に思考力にあふれた人材を育て、すばらしい製品を生み出す作業に打ち込ませる。

２.エキスパートエンジニア

• 専門知識をすべて外注に任せている企業は、競合他社も同様に外注出来る。
• 専門知識など必要ないと考えている企業は、維持可能な競争優位を何ひとつ持ち合わせてないことに気づく。
• 聡明な企業なら、確実に目的に合ったエキスパートエンジニアを育成し、目標達成に必要な専門知識を備えた人員を配備しようとする。

３．責任ベースのプランニングと制御

• 人を尊重するということは、チームに概要計画とそれに見合う目標を提示し、目標に向けて自立実行するよう任せるこという意味である。
• やるべき事や、やり方を指示するのではなく、人が頭を使い自らそれを見つけ出すことが出来る、自律管理能力を備えた組織を作るということなのである。

７．全体を最適化する。

• 7-1．人は、複雑な状況を小さな部分へと分解する傾向がありそのため、システム全体を部分的に最適化を行いがちになる。
• 7-2．部分的に最適化で、パフォーマンスやコスト、スケジュールとした場合、顧客満足や品質が考慮されなく、二の次にされてしまう恐れがある。
• 7-3．最適化の改善項目を増やした場合、今度は事柄が多すぎて改善する作業の本当の目標が、多くの改善目標に埋もれ見失ってしまう。
• 7-4．解決策は低い視点ではなく、高い視点で上位を計測すること。本当に重要な１項目だけを測定対象として行う。

例「投資対効果を計測する」など。 本当に必要なひとつだけを最適化すれば、その他諸々はひとりでに最適化されていくはずとのこと。