disciplined scaling...

TMSによるシステム開発 - Disciplined Scaling Agile -

2014年 4月

株式会社戦略スタッフ・サービス Strategic Staff Services Corporation

目次

i. プロジェクト・チーム崩壊 ii. TMSとの出会い iii. TMSの素晴らしさ iv. TMS（トータル・マネージメント・システム）とは v. TMSとは職場活性化活動 vi. TMSとアジャイルの親和性 vii. Disciplined Scaling Agile (DSA)の考え方（概念） viii. Disciplined Scaling Agileとは ix. Planning Phase（計画） x. Inception Phase（方向付け、プロジェクトの開始） xi. Construction Phase（システムの製作） xii. Transition Phase（移行準備＆ソリューション確認） xiii. Production Phase（運用＆フォローアップ） xiv. Disciplined Scaling Agile (DSA)の概念図 xv. Quickening Visualization System (QVS)（大部屋方式） xvi. 活動の見える化の原理 xvii. DSAのスパイラル・アップなアプローチ xviii.（参考資料）

Copyrights@2014_Strategic Staff Services 2

システム開発プロジェクトが失敗に終わる話をよく聞く。その時の失敗の原因が、ＰＭの管理が甘かった。お客の要求を整理できなかった。お客の変更要求があまりにも多かった。などなどである。本当にこのような事が失敗の原因なのだろうか？あまりにも基本的でそんなこと当り前だろうと思われている事が実は失敗の根源の様に思えてきた。それは開発プロジェクト・チームの崩壊（コラップス）だと思える。崩壊という一寸衝撃的な言葉を使用したが、敢えて皆さんに注意を喚起してほしくてこのような激しい言葉で表現している。たぶんプロジェクトを指揮、管理する立場の皆さんからは激しい反論を受けると思う。『自分たちはそんな基本的な事は既にできている。』と。何を言っているんだ。そのような声が聞こえてきます。が、もう一度よく考えてください。私が『プロジェクト・チームの崩壊』と言っているのは、皆さんが編成したプロジェクト・チームが自律的に、モチベーション高く、本来のチームとして機能（働いて）していたでしょうか？やらされ感満載のチームメンバーといきりったプロジェクト・リーダー（管理者）のプロジェクト・チームに落ちっていませんでしたか？このような状態でチームは正常に機能しますか？チームはお客様のことや、品質、納期等を常に意識していましたか？私はこのような事が機能しないチームを『プロジェクト・チームの崩壊』と表現しています。この問題は開発メソドロジー（ウォーターフォールであれアジャイルであれ）やツール、PMBoKといった知識の問題ではありません。何故プロジェクト・チームを編成す

るのか？プロジェクト・チームの目標、目的は何か？チーム内（関係者全員で）で共有している基本的な価値観は何か？チームが正常に機能するためにはこのような基本的な事が必要です。失敗したプロジェクト・チームをこのような観点で冷静に振り返ってみてください。本当にこのような事が出来ていて失敗しているでしょうか？私の経験から言えば、この様な事が出来ていればプロジェクトは失敗しないはずです。というのはこのようなチームであればどの様な状況の変化に対しても対処可能だからです。対処できないのは、チームが硬直化して、何のためのプロジェクト・チームであるかと言う基本的な価値観が共有されていなく、各人がまちまちの勝手な思いでいるからチームが機能しなくなったり、官僚的な仕事（対処）になるのです。ですからシステム開発プロジェクトを成功させたいと考えるなら、しっかりとチーム・ビルディングをしなければなりません。プロジェクト・チームを編成した時に管理者の皆さんこの事に意識を傾けて重要視してますか？単に必要工数をカバー出来る人工をそろえるチームを作ってはいませんか？それでは最初からプロジェクトが失敗に帰することは自明の理です。折角編成したチームが最初から機能しないからです。アジャイル開発の指導から成功したお客様に評価されるチームのビヘイビアーとトヨタのＴＭＳの基本を学んで、この事に気づき、今では確信になりました。

プロジェクト・チーム崩壊


ＴＭＳとの出会いアジャイル開発（Scrum）の導入を企業向けに実施してきた経験から、アジャイル開発の基本的な考え方にトヨタ

生産方式（ＴＰＳ）の概念が含まれていることは、アジャイル開発を実践された方には感じ取っていただけると思います。このような感触からアジャイル開発を指導し始めた頃よりＴＰＳについて並行して学び始めました。 2009年に豊田マネージメント研究所の高木副社長とお会いしてＴＭＳの紹介をして頂きました。ＴＭＳとはＴＰＳ

（トヨタ生産方式）がもの作りの現場、所謂製造現場とその周辺に関わる生産部門でのマネジメントですが、この考え方をまったく踏襲して非生産部門、所謂俗に言われるホワイトカラーの人たちのマネジメントとして職場の活性化という形で解り易く紹介されております。ＴＰＳとＴＭＳの大きな違いは、生産部門のＴＰＳでは指示命令系統が強い職場で適用されるメソドロジーですが、非生産部門のホワイトカラーの職場では必ずしも指示命令系統が強い職場ではありません。また生産部門と異なり品質という事を見てみても生産部門では誰にでも見れば品質の良し悪しは明確に判断できますが、仕事の内容、結果が見えにくい事務作業では品質を誰が見ても解るようにはできません。見える化の工夫が必要です。したがって作業者自らの自律性やモチベーションといった基本的に働くビヘイビアーに結果が左右されることになります。ここで問題になるのは、知識を持ち合わせていたとしても、その知識を自分で実際の行動に移せるか？は知識の有る無しよりも重大な事になります。たとえ知識を持っていても、実際に行動レベルまで落とし込んで実行できなければ、その知識は単に知っているという事で、その知識を生かして期待する結果を求められるかという事では、知識が無い事と同義になります。トヨタではＴＰＳでもＴＭＳでもまず知識よりの行動を求められます。また個人が経験した体験から生じる暗黙知を見える化することでチーム内、組織内の形式知化する事を求められます。このようにして、チーム、組織の全員が形式知化した知識をまた実行して暗黙知を生み出し、さらにまた形式知化することで、カイゼンが廻ってよりよい作業結果や作業環境を整えていきます。自律した開発チームを前提としたアジャイル開発の現場においては、このＴＭＳで言う暗黙知と形式知の循環サイクルを回して、反復的に現地現物のコードで確認しながらお客様に評価される品質や納期（ＪＩＴ）を確保していきます。そういう意味でＴＭＳに出合いアジャイル開発を指導するうえで大きな指標を得たと言えます。またウォーターフォールであれ、アジャイルであれ開発メソドロジーの紹介に終始して、特にアジャイル開発で要求される自律した開発チームをどのように育成していくのか？というメソドロジーは提供されておりません。ここは従来から、自分で勝手にやってください。そのようなチームを編成してくださいと言った形で触れられておりませんし、その様なチームありきが前提でメソドロジーが論じらております。過去この最初のチームを作る（育成）段階では何か良いメソドロジーが紹介されていなかったのです。ＴＭＳはこのチーム育成のメソドロジーを我々に提供してくれます。またこの方法で成功したトヨタという企業が存在するという目に見える結果も見ることができます。 Copyrights@2014_Strategic Staff Services

4

ＴＭＳの素晴らしさ

ＴＭＳ一番の利点は、プロジェクト・チームを編成した時に、まず自律したチームを育成するメソドロジーを提供してくれる事である。Scrumでも、望ましいチームの形としてある期間（長期間）チームを固定した方が良いとアドバ

イスしているのは、あながち間違ってはいない。チームを固定化することで、プロジェクト開始時のチームの育成という段階を省略できる。では皆さんのシステム開発プロジェクトを編成した時の事を思い起してほしい、プロジェクト案件毎に多分チーム編成は固定されておらずその都度チームを編成していないだろうか？プロジェクトとい性質上案件ごとに異なるメンバー構成になるのは必然である。ではチームを編成した後に、このように自律して正常に機能するチーム育成に何か方策をやメソドロジーをお持ちであろうか？ほとんどのプロジェクトではこの段階は現場に放り投げられ、意識することも少ないと思われる。これでプロジェクト・チームは皆さんの期待通りに機能するのでしょうか？ＴＭＳはこのような段階で自律したチームを育成する環境やメソドロジーを提供してくれます。これはウォーターフォールであれアジャイルであれ開発メソドロジーの問題ではありません。同じです。残念ながらPMBoKにもこのチーム育成の知恵は語られておりません。できているという前提に立った知恵です。

システム開発プロジェクト特に大規模になればなるほどこのチーム編成後のチームの育成という問題は大きくなります。ウォーターフォールでもアジャイルでも触れられていないこの空白の部分をＴＭＳはメソドロジーを提供して見事に補ってくれます。

自律したチーム（作業者）を育成するステップは、基本的に次のようになります。まず自分の足元が見えていなければなりません。自分がどこにいるのかわからなくて、自分の環境や仕事をよりよくすることはできません。その意味で『見える化』が重要な役目を負います。また自分が知らず知らずのうちに（無意識で）行っている行動、意思決定（マネジメント）の癖を認知する必要があります。これも自分の足元を見る事と同義です。さらに仕事を通して、達成感（必ずしも成功体験ばかりではありません）を味わえる事が大事です。これも『見える化』されていないと、味わえません。達成感を味わえることで自信が芽生えます。この自信が発展しなければ自律へとは向かいません。自信を持てることが自律への第一歩を踏みだせる要件です。このようなステップを経なければ自律したチームを育成できません。ＴＭＳはこの自律へのステップをメソドロジーとして提供しています。結果として自律したチームでは自然とカイゼン（ＰＤＣＡ）が廻り始めます。これは『やらさせ感のないカイゼン』です。


ＴＭＳ（トータル・マネジメント・システム）とは

ＴＰＳ（トヨタ生産方式）思想の変遷

初期のＴＰＳ：トップダウン的な改善

徹底したムダ、在庫をなくす活動でした。

現在のＴＰＳ：自主的、民主的な改善

職場の活性化

ＴＭＳ（トータルＴＰＳ）：ＴＰＳ思想を製造以外の各業務分野に展開

見える化

ポカヨケ

かんばん

標準作業

自働化

後工程引き取り

平準化生産

工程の流れ化

ムダの顕在化と排除工程改善・省人化

品質は工程で造り込む

ＪＩＴジャスト・イン・タイム

ムダ取り

高い品質

在庫低減

低い原価

従来のＴＰＳ

活動の見える化

職場づくり

価値の創造

改善マインド

仕事の品質

利益の創造

ＴＭＳコア


ＴＭＳとは職場活性化活動

ＴＭＳコア（６つの要素）

この６つの要素を実践することで職場を活性化できる

６つの要素には、それぞれ「考え方」と「方法論」から成り立っている

ＴＭＳは「考え方」と「方法論」の両輪で実践する事で職場の活性化が早く進む

職場活性化活動（ＴＭＳコア）

活動の見える化

職場づくり

価値の創造

改善マインド

仕事の品質

利益の創造

活動の見える化：方針管理、日常管理、仕事の見える化職場づくり：コミュニケーション、リーダーシップ価値の創造：お客様第一、成果へのこだわり改善マインド：ムダを見つける目、整理・整頓（２Ｓ）、問題解決力仕事の品質：統計的なモノの見方・考え方、自工程完結利益の創造：利益を生み出す仕組み、生産性の向上

『人間性尊重』という考え方が中心 ① 自分にとってのお客様は誰か ② あるべき姿と現状とのギャップは何か ③ あるべき姿に向けての行動を妨げている真因は何か ④ 真因に対して直ぐに対策を打てているかこれらの考え方を実践することが人間性尊重に繋がる行動

『失敗から学ぶ』成功した時と同じ環境、同じ人、同じ行動が再現できるとは限らない失敗にこだわる事が大事です（失敗は記憶に残る）「なぜうまく行かないのだろうか？」を考え、仮説・検証しながら試行錯誤を始める


ＴＭＳとアジャイル（Scrum）の親和性

アジャイル開発、特にScrumでは、ＴＰＳの概念が多々流用されています。ＴＰＳで言われているところの、お客様第一、後工程引き取り、一個流し、自工程完結、平準化、現地現物、カンバン（タスクボード）、見える化、等々。

また具体的なメソドロジーも借用されています。振り返り（ＫＰＴ）、スタンドアップ・ミーティング（朝会、昼会、夕会）がそうです。また、ＴＭＳもScrumもどちらも指示・統制型マネージメントから現場での自律したマネージメントへのマネージメントスタイルの変換を求めているところは同じです。特に振り返り（ＫＰＴ）はScrum Alliance（Scrumの振興団体）の欧米でのプロジェクト成功要因として重要視されてお

りますが、その具体的な指導方法やメソドロジーについては、スクラムマスターの個人的な力量としか扱われておりません。

ただ残念なのは、形式に囚われて、その意義、目的が正しく理解されていないという事です。ですからアジャイル（Scrum）の形を真似て実施しても、その真意がわからずに実施すれば、やはり失敗とは言いませんが、成功させることはできません。このようにアジャイル（Scrum）を実施しようと考えたならば、まずＴＭＳを学ぶことが先決です。基本的な意義や目的をを理解した上でScrumのメソドロジーを知れば、自律したScrumチームを育成でき、かつ効果的にScrumのプロセスを回すことができます。


Disciplined Scaling Agile (DSA)の考え方（概念） 2000年以降、わが国でもアジャイル開発が取り入れれて幾多の成功事例が報告されておりますが、その殆どは、Web系の開発やベンチャー企業などの単一の開発チームであったり小規模なチーム構成です。それで大

規模なシステム開発や大企業での適用は向かない等の意見が散見されますし、アジャイル開発に向いた案件規模等の議論がされてきました。確かに開発チーム内でのプロセスやチームマネジメントについては有用なメソドロジーを提供してくれておりますが、大規模なチーム、組織での大規模な案件ではどの様に対処すべきか？はScrumでも簡単にScrum of Scrumといった概念を提供しているだけです。ではアジャイル開発の利点を

求めながら大規模案件ではどのように対処すればよいのでしょうか？これまでの議論では、ウォーターフォールのメソドロジーと組み合わせてハイブリッドやＲＵＰを起源とするＤＡＤなど種々なメソドロジーが語られております。私のアジャイル開発指導経験とＴＭＳの経験からＴＭＳの職場活性化のメソドロジーとScrumのプロセス、

メソドロジーを組み合わせる手法が、大規模なプロジェクトでも効果的であるという結論に至りました。その理由は、ＴＭＳのメソドロジーはシステム開発手法に囚われず、自律したチームの育成とマネジメント能力の向上を支援してくれます。ウォーターフォールであれ、アジャイルであれ大規模なプロジェクトの効果的な運営については、特にメソドロジーを提供しておりません。一方、このような大規模なプロジェクトのマネジメントとしてトヨタで実際に活用されて効果を発揮している『大部屋』という概念と手法は大規模なシステム開発プロジェクトにはうってつけです。 Disciplined Scaling Agile (DSA)という概念は、このようにＴＭＳの『大部屋』の概念、手法でプロジェクト全体を見える化し、マネジメントできる事と各チーム内で実施されるScrumのプロセス、マネジメントを組み合わせることで、全体と個の双方の同期をとることができ、プロジェクト全体を現地現物でマネジメントできるようになります。


Disciplined Scaling Agileとは

Planning Phase（計画）: ① Project Scoping ② 方針展開 ③ Visual Board作成 Inception Phase（方向付け、プロジェクトの開始）: ① 要求の把握」とBody Processの確認 ② システム要求仕様の整理（Rule/Process/Data) 品質条件 ③ Digital Mock-UpでのBody Processの検証 ④ 大部屋の設営 Construction Phase (Iterative)（システムの製作）: Scrum(Agile) Product Cycle Lean Product Cycle KANBAN Product Cycle Transition Phase（移行準備＆ソリューション確認）: Product/Solution Ready Deploy the solution into production Production Phase（運用＆フォローアップ）: システム運用 Runtime Scenario検証 Dependability Assurance

Design

Code

Integration / Build

Test


Planning Phase（計画）このフェーズでは、従来対象となるプロジェクトの計画立案が中心であったが、DSAでは、このプロジェク

トの計画以外にプロジェクト・チームのビルディングの作業を重要視する。したがって以下の三つの事柄をこのフェーズでは主に実施することが求められる。期間としては、4週間から6週間程度。

① プロジェクト・スコープの把握 ② プロジェクト・チームとしての方針展開 ③ 各構成チームのビジュアル・ボードの作成

① プロジェクト・スコープの把握プロジェクトの目的の明確化（作製するシステムの存立意義・要件）プロジェクトの完了時期、予算規模とプロジェクトチームの編成 ② プロジェクトの方針展開

上位方針を受けて下位のチームと擦り合わせを行い具体的な行動を起こせるようにプロジェクトとしての目標やあるべき姿、基本的価値観の共有を図る ③ ビジュアル・ボード

上位の方針展開を受けて各チーム毎にプロジェクトの目的に沿った具体的行動をとるためのチームとしての目的、行動指針、目標を定めチーム構成員内での自律、活性化の見える化を行う。

お客様は誰か？価値の提供（あるべき姿）ギャップを埋める為の施策

価値の提供（現状）

組織の価値観（原理・原則・考え方）プロジェクトに対する自分達の思い

あるべき姿（目的）方針活動体制

チームの目標チームの施策（行動）管理指標（ＫＰＩ）

活動結果指標（ＫＧＩ）ＫＧＩグラフＫＰＩグラフ補助管理のチャート


Inception Phase（方向付け、プロジェクトの開始）このフェーズでは、従来の要求管理とシステム概要設計を実施するが、従来からのアプローチとは少し異なる視点で実施する。したがって期間としては2～3ケ月間で完了することが望ましい。このフェーズで実施されることは以下の四点が主要な活動となる。期間としては8週間から12週間程度。

① 要求の把握とシステムのBody Processの確認 ② 仕様の整理とプロセスの整理 ③ 実演(Demo)による主要機能(Body Process)の確認 ④ プロジェクトの大部屋の設営

① 要求の把握とシステムのBody Processの確認ユーザーの要求については、現実に明確になっている事柄のみを整理する。推測、仮説、希望はその旨明示し別管理対象システムの製作意義（ビジネス価値）を明確にし、その主要な機能、プロセスを定義する。 ② 仕様の整理とプロセスの整理システムに要求される要件・仕様をRule, Process, Dataで明確に分別仕訳し定義する。プロセスについても、Body Process, Alternative Process, Option Processに分別定義を行う。仕様の確定（ユーザーとの合意）に際しては、仕様を確認するのではなく、後工程引き取りの考え方で、システムの受入テスト基準・項目にて確認（ユーザーとの合意）を行う。 ③ 実演(Demo)による主要機能(Body Process)の確認 (Digital Mock-Up Demo) システム概要が把握できたならば、そのシステムの存立意義を確認するためにBody Processを簡便に実装し、実演(Demo)してユーザーにシステム概要設計の確認を得る。 ④ プロジェクトの大部屋を設営物理的に大部屋をセットする。【大部屋については後続の資料を参照ください】


Construction Phase（システムの製作）

開発手法（メソドロジー）は反復的(Iterative)に開発を行う手法であれば、混在可能であるので、スクラムであれ、

リーンであれ、ＫＡＮＢＡＮであれ手法を限定しないが、スクラムの手法がＴＭＳと親和性が高く、実施するうえでは容易と思われる。他の手法の場合は、十分な検討、検証が求められる。ここでは、手法の着実な実施よりも下記の項目について開発チームの理解と実践に注意すべきである。

① 現地現物での作業進捗把握の徹底 ⇒ファクト・コントロール ② 正味作業と付帯作業、及びムダの理解 ⇒お客様に価値を生まない作業の排除 ③ 後工程引き取りの意味 ⇒手待ちの撲滅 ④ 一個流しを実現する工夫 ⇒品質の向上、整流化、 ⑤ 自工程完結のためのチームとしての行動基準 ⇒品質の早期安定 ⑥ 仕事、プロセスの平準化、整流化 ⇒ボトルネックの解消 ⑦ 振り返り（ＫＰＴ）の実践と質的向上（カイゼン） ⇒すべての活動（作業）の基本（エンジン）

お客様への価値の提供（品質）については、常にチーム・メンバー全員に意識の喚起が必要である。


Transition Phase（移行準備＆ソリューション確認）

このフェーズでは、もちろんこの前のConstruction Phaseにおいて自工程完結で作業ができていれば、プログラム

の品質は担保されているはずであるが、ユーザーにソリューションとして提供されるシステム全体としての確認＆テストは必要である。このフェーズでは下記の二点が主要な活動となる。期間としては、4週間から6週間程度。

① ソリューションとしてのシステム全体での運用テスト ② ユーザーに必要なドキュメントの整備

① ソリューションとしてのシステム全体での運用テストユーザーのオペレーション・シナリオに基づきソリューションとして運用可能であるかの確認をユーザーに確認して貰う。またこのテストが最終のユーザー受入テストとなる。これはユーザーのビジネス・プロセス上、新たに提供したソリューションとして機能できるか？スムースに運用できるか？という点を確認する事である。 ② ユーザーに必要なドキュメントの整備最終的にユーザーへ提供されるドキュメントを整備する。ユーザーに必要と思われるドキュメントは、 ◆ メンテナンス・マニュアル ◆ システム運用マニュアル（含む障害回復） ◆ 導入ガイド ◆ ユーザー・マニュアル（操作マニュアル＆ガイド）等である。


Production Phase（運用＆フォローアップ）

めでたくソリューション（システム）として稼働するわけであるが、稼働後にお客様（ユーザー）に満足を得ていただくために、フォローアップの様子見の期間。

ここでの注意点は、事前にオペレーション・シナリオにてソリューションの操作や運用を検証しているが、必ずしもユーザーがそのシナリオ通りに、使用し続けてくれるかというと、案外そうではない。ユーザーも新しい運用を開始したのち経験を積むに従い、運用や操作の暗黙知（知恵）が出てくる。この暗黙知を形式知するか？どうかを見極める必要はある。一定期間（半年とか一年）後に、この見極めを実施することをお勧めする。


Disciplined Scaling Agile (DSA) の概念図

Visual Board

Visual Board

Visual Board

Visual Board

Scrum Team A

Operation Team

Scrum Team B

Scrum Team C

ＳＭ

大

部

屋

ＰＭ

ＴＭＳコーチ

ＰＯ

ＫＰＴ

ＫＰＴ

ＫＰＴ

ＫＰＴ


Quickening Visualization System （大部屋方式）

品質プロセス

方針展開

スクリーン

大部屋の模式図狙い：人と職場（チーム）の活性化を促進する効果が大きいプロジェクト全体が俯瞰（見える化）できる「見える化」とは、異常が瞬時に解る、気づく事 Scrum of Scrumの実施会場（場所）

改善テーマ

５Ｓ

特長：

大きなプロジェクトや他部署との連携したチームなど組織横断的な事業に取り組む場合には、『目で見る管理』を大部屋化して行う

大部屋とは、関係者が一つの部屋に集まって課題を見える化し、問題解決を進めていくやり方

同じ部屋で仕事を行う事でコミュニケーションが活発化しアイデアが沢山でる様になる


活動の見える化の原理見える化とは、『異常や問題がすぐにわかるようにする事』

脳の原理に基づいたマネジメント

体験、経験して記憶する方法が効果的

記憶を残すには手や体を動かしながらイメージで記憶する事

脳の記憶を行動に移すには、『繰り返す事』

やるべき事や考えている事（暗黙知）なども紙や付箋に書き出して見える様にする（形式知化）と良いでしょう。

暗黙知形式知見える化

見える化のサイクルを回すと、 ①短時間で教える事が出来る ②初めての仕事でも早く覚える事が出来る ③人によってやりずらいなどの課題が見え改善出来る ④仕事の品質のバラツキを抑える事が出来る『知る→行動する→経験値が増える→形式知化する』のサイクルを繰り返すことで仕事の品質が向上し達成感に繋がるファクト・コントロール（Fact Control）事実に基づいた情報現地・現物（現場で事実を見る）現場が「見える化」されていなければ、現場に行っても事実は見えない事実をどの様にして伝えれば良いか？


ＤＳＡのスパイラル・アップなアプローチ ①見える化

基本２S（整理・整頓）データによる現状把握

②職場環境の整備（職場づくり）

リーダーシップとコミュニケーションスタンドアップ・ミーティング（毎日）振り返り（毎週）

手順（標準）の整理タイムボックス、カンバン

見える化の徹底タスクボード、掲示物

大部屋の導入企画・要求からアーキテクチャ設計そして移行準備迄

③価値の創造（作り込み）

お客様第一の視点（考え）での見直し UX（ユーザーエクスペリエンス）

振り返りの徹底ジャストインタイム（JIT）、整流化（タスク粒度）

仕事完了（ダーン）の定義（自工程完結の基準）

手順（標準）の再設定お客様視点、プロセス（整流化）視点

ユーザーストーリー

④カイゼンの定着（改善マインド）ムダ取りの実施

５S（整理・整頓・清掃・清潔・躾）の定着

真因の追求（なぜなぜ５回）ブレイクスル―思考法（目的の追求）

データによる振り返りベロシティー

先行改善の実施開発チーム、運用チームからの提言

⑤仕事の品質データでの分析と現地・現物の確認

品質作り込み視点での見直しフィードバック・サイクル、ユーザーとの協働

仕事完了（ダーン）の再定義

手順（標準）の再々定義プロジェクトの透明性

⑥利益の創造データによる評価

プロジェクトの評価 Q（品質）、D（納期、リリース）、C（コスト、生産性）


参考資料

トヨタ流の教科書【企業編】堀切俊雄著日経ものづくり刊ＴＭＳ検定公式テキスト４級社団法人ＴＰＳ検定協会刊 TPS-Toyota Production System-検定4級テキスト社団法人ＴＰＳ検定協会刊 Total-TPS基礎知識編 Agile Project Management with SCRUM Ken Schwaber著 Microsoft Press刊 The Enterprise and SCRUM Ken Schwaber著 Microsoft Press刊 Disciplined Agile Delivery Scott W. Amber / Mark Lines著 IBM Press刊


disciplined scaling...

Documents