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.（参考資料） 2 Copyrights@2014_Strategic Staff Services プロジェクト・チーム崩壊 システム開発プロジェクトが失敗に終わる話をよく聞く。その時の失敗の原因が、ＰＭの管理が甘かった。お客 の要求を整理できなかった。お客の変更要求があまりにも多かった。などなどである。本当にこのような事が失 敗の原因なのだろうか？あまりにも基本的でそんなこと当り前だろうと思われている事が実は失敗の根源の様 に思えてきた。それは開発プロジェクト・チームの崩壊（コラップス）だと思える。崩壊という一寸衝撃的な言葉を 使用したが、敢えて皆さんに注意を喚起してほしくてこのような激しい言葉で表現している。たぶんプロジェクトを 指揮、管理する立場の皆さんからは激しい反論を受けると思う。『自分たちはそんな基本的な事は既にできてい る。』と。何を言っているんだ。そのような声が聞こえてきます。が、もう一度よく考えてください。私が『プロジェク ト・チームの崩壊』と言っているのは、皆さんが編成したプロジェクト・チームが自律的に、モチベーション高く、本 来のチームとして機能（働いて）していたでしょうか？やらされ感満載のチームメンバーといきりったプロジェクト・ リーダー（管理者）のプロジェクト・チームに落ちっていませんでしたか？このような状態でチームは正常に機能 しますか？チームはお客様のことや、品質、納期等を常に意識していましたか？私はこのような事が機能しない チームを『プロジェクト・チームの崩壊』と表現しています。この問題は開発メソドロジー（ウォーターフォールであ れアジャイルであれ）やツール、PMBoKといった知識の問題ではありません。何故プロジェクト・チームを編成す るのか？プロジェクト・チームの目標、目的は何か？チーム内（関係者全員で）で共有している基本的な価値観 は何か？チームが正常に機能するためにはこのような基本的な事が必要です。失敗したプロジェクト・チームを このような観点で冷静に振り返ってみてください。本当にこのような事が出来ていて失敗しているでしょうか？私 の経験から言えば、この様な事が出来ていればプロジェクトは失敗しないはずです。というのはこのようなチー ムであればどの様な状況の変化に対しても対処可能だからです。対処できないのは、チームが硬直化して、何 のためのプロジェクト・チームであるかと言う基本的な価値観が共有されていなく、各人がまちまちの勝手な思い でいるからチームが機能しなくなったり、官僚的な仕事（対処）になるのです。ですからシステム開発プロジェクト を成功させたいと考えるなら、しっかりとチーム・ビルディングをしなければなりません。プロジェクト・チームを編 成した時に管理者の皆さんこの事に意識を傾けて重要視してますか？単に必要工数をカバー出来る人工をそ ろえるチームを作ってはいませんか？それでは最初からプロジェクトが失敗に帰することは自明の理です。折角 編成したチームが最初から機能しないからです。アジャイル開発の指導から成功したお客様に評価されるチー ムのビヘイビアーとトヨタのＴＭＳの基本を学んで、この事に気づき、今では確信になりました。 3 Copyrights@2014_Strategic Staff Services ＴＭＳとの出会い アジャイル開発（Scrum）の導入を企業向けに実施してきた経験から、アジャイル開発の基本的な考え方にトヨタ 生産方式（ＴＰＳ）の概念が含まれていることは、アジャイル開発を実践された方には感じ取っていただけると思 います。このような感触からアジャイル開発を指導し始めた頃よりＴＰＳについて並行して学び始めました。 2009年に豊田マネージメント研究所の高木副社長とお会いしてＴＭＳの紹介をして頂きました。ＴＭＳとはＴＰＳ （トヨタ生産方式）がもの作りの現場、所謂製造現場とその周辺に関わる生産部門でのマネジメントですが、この 考え方をまったく踏襲して非生産部門、所謂俗に言われるホワイトカラーの人たちのマネジメントとして職場の活 性化という形で解り易く紹介されております。ＴＰＳとＴＭＳの大きな違いは、生産部門のＴＰＳでは指示命令系統 が強い職場で適用されるメソドロジーですが、非生産部門のホワイトカラーの職場では必ずしも指示命令系統 が強い職場ではありません。また生産部門と異なり品質という事を見てみても生産部門では誰にでも見れば品 質の良し悪しは明確に判断できますが、仕事の内容、結果が見えにくい事務作業では品質を誰が見ても解るよ うにはできません。見える化の工夫が必要です。したがって作業者自らの自律性やモチベーションといった基本 的に働くビヘイビアーに結果が左右されることになります。ここで問題になるのは、知識を持ち合わせていたとし ても、その知識を自分で実際の行動に移せるか？は知識の有る無しよりも重大な事になります。たとえ知識を 持っていても、実際に行動レベルまで落とし込んで実行できなければ、その知識は単に知っているという事で、 その知識を生かして期待する結果を求められるかという事では、知識が無い事と同義になります。トヨタではＴＰ ＳでもＴＭＳでもまず知識よりの行動を求められます。また個人が経験した体験から生じる暗黙知を見える化す ることでチーム内、組織内の形式知化する事を求められます。このようにして、チーム、組織の全員が形式知化 した知識をまた実行して暗黙知を生み出し、さらにまた形式知化することで、カイゼンが廻ってよりよい作業結果 や作業環境を整えていきます。自律した開発チームを前提としたアジャイル開発の現場においては、このＴＭＳ で言う暗黙知と形式知の循環サイクルを回して、反復的に現地現物のコードで確認しながらお客様に評価され る品質や納期（ＪＩＴ）を確保していきます。そういう意味でＴＭＳに出合いアジャイル開発を指導するうえで大きな 指標を得たと言えます。またウォーターフォールであれ、アジャイルであれ開発メソドロジーの紹介に終始して、 特にアジャイル開発で要求される自律した開発チームをどのように育成していくのか？というメソドロジーは提供 されておりません。ここは従来から、自分で勝手にやってください。そのようなチームを編成してくださいと言った 形で触れられておりませんし、その様なチームありきが前提でメソドロジーが論じらております。過去この最初の チームを作る（育成）段階では何か良いメソドロジーが紹介されていなかったのです。ＴＭＳはこのチーム育成の メソドロジーを我々に提供してくれます。またこの方法で成功したトヨタという企業が存在するという目に見える結 4 果も見ることができます。 Copyrights@2014_Strategic Staff Services ＴＭＳの素晴らしさ ＴＭＳ一番の利点は、プロジェクト・チームを編成した時に、まず自律したチームを育成するメソドロジーを提供し てくれる事である。Scrumでも、望ましいチームの形としてある期間（長期間）チームを固定した方が良いとアドバ イスしているのは、あながち間違ってはいない。チームを固定化することで、プロジェクト開始時のチームの育成 という段階を省略できる。では皆さんのシステム開発プロジェクトを編成した時の事を思い起してほしい、プロジェ クト案件毎に多分チーム編成は固定されておらずその都度チームを編成していないだろうか？プロジェクトとい 性質上案件ごとに異なるメンバー構成になるのは必然である。ではチームを編成した後に、このように自律して 正常に機能するチーム育成に何か方策をやメソドロジーをお持ちであろうか？ほとんどのプロジェクトではこの段 階は現場に放り投げられ、意識することも少ないと思われる。これでプロジェクト・チームは皆さんの期待通りに 機能するのでしょうか？ＴＭＳはこのような段階で自律したチームを育成する環境やメソドロジーを提供してくれま す。これはウォーターフォールであれアジャイルであれ開発メソドロジーの問題ではありません。同じです。 残念ながらPMBoKにもこのチーム育成の知恵は語られておりません。できているという前提に立った知恵です。 システム開発プロジェクト特に大規模になればなるほどこのチーム編成後のチームの育成という問題は大きくな ります。ウォーターフォールでもアジャイルでも触れられていないこの空白の部分をＴＭＳはメソドロジーを提供し て見事に補ってくれます。 自律したチーム（作業者）を育成するステップは、基本的に次のようになります。まず自分の足元が見えていなけ ればなりません。自分がどこにいるのかわからなくて、自分の環境や仕事をよりよくすることはできません。その 意味で『見える化』が重要な役目を負います。また自分が知らず知らずのうちに（無意識で）行っている行動、意 思決定（マネジメント）の癖を認知する必要があります。これも自分の足元を見る事と同義です。さらに仕事を通し て、達成感（必ずしも成功体験ばかりではありません）を味わえる事が大事です。これも『見える化』されていない と、味わえません。達成感を味わえることで自信が芽生えます。この自信が発展しなければ自律へとは向かいま せん。自信を持てることが自律への第一歩を踏みだせる要件です。このようなステップを経なければ自律した チームを育成できません。ＴＭＳはこの自律へのステップをメソドロジーとして提供しています。結果として自律し たチームでは自然とカイゼン（ＰＤＣＡ）が廻り始めます。これは『やらさせ感のないカイゼン』です。 5 Copyrights@2014_Strategic Staff Services ＴＭＳ（トータル・マネジメント・システム）とは ＴＰＳ（トヨタ生産方式）思想の変遷 初期のＴＰＳ ：トップダウン的な改善 徹底したムダ、在庫をなくす活動でした。 現在のＴＰＳ ：自主的、民主的な改善 職場の活性化 ＴＭＳ（トータルＴＰＳ） ：ＴＰＳ思想を製造以外の各業務分野に展開 従来のＴＰＳ ＴＭＳコア 見える化 自働化 品質は工程で造り込む 高い品質 ポカヨケ 職場づくり 後工程引き取り かんばん 平準化生産 標準作業 ＪＩＴ ジャスト・イン・タイム 価値の創造 在庫低減 改善マインド 工程の流れ化 ムダの顕在化と排除 工程改善・省人化 活動の見える化 仕事の品質 ムダ取り 低い原価 利益の創造 6 Copyrights@2014_Strategic Staff Services ＴＭＳとは職場活性化活動 ＴＭＳコア（６つの要素） この６つの要素を実践することで職場を活性化できる ６つの要素には、それぞれ「考え方」と「方法論」から成り立っている ＴＭＳは「考え方」と「方法論」の両輪で実践する事で職場の活性化が早く進む 活動の 見える化 利益の 創造 職場 づくり 職場活性化活動 （ＴＭＳコア） 仕事の 品質 方針管理、 日常管理、 仕事の見える化 コミュニケーション、 リーダーシップ お客様第一、成果へのこだわり ムダを見つける目、整理・整頓（２Ｓ）、問題解決力 統計的なモノの見方・考え方、 自工程完結 利益を生み出す仕組み、生産性の向上 『人間性尊重』という考え方が中心 価値の 創造 改善 マインド 活動の見える化： 職場づくり： 価値の創造： 改善マインド： 仕事の品質： 利益の創造： ① 自分にとってのお客様は誰か ② あるべき姿と現状とのギャップは何か ③ あるべき姿に向けての行動を妨げている真因は何か ④ 真因に対して直ぐに対策を打てているか これらの考え方を実践することが人間性尊重に繋がる行動 『失敗から学ぶ』 成功した時と同じ環境、同じ人、同じ行動が再現できるとは限らない 失敗にこだわる事が大事です（失敗は記憶に残る） 「なぜうまく行かないのだろうか？」を考え、仮説・検証しながら試行錯誤を始める Copyrights@2014_Strategic Staff Services 7 ＴＭＳとアジャイル（Scrum）の親和性 アジャイル開発、特にScrumでは、ＴＰＳの概念が多々流用されています。ＴＰＳで言われているところの、お客様第 一、後工程引き取り、一個流し、自工程完結、平準化、現地現物、カンバン（タスクボード）、見える化、等々。 また具体的なメソドロジーも借用されています。振り返り（ＫＰＴ）、スタンドアップ・ミーティング（朝会、昼会、夕会） がそうです。 また、ＴＭＳもScrumもどちらも指示・統制型マネージメントから現場での自律したマネージメントへのマネージメント スタイルの変換を求めているところは同じです。 特に振り返り（ＫＰＴ）はScrum Alliance（Scrumの振興団体）の欧米でのプロジェクト成功要因として重要視されてお りますが、その具体的な指導方法やメソドロジーについては、スクラムマスターの個人的な力量としか扱われてお りません。 ただ残念なのは、形式に囚われて、その意義、目的が正しく理解されていないという事です。ですからアジャイル （Scrum）の形を真似て実施しても、その真意がわからずに実施すれば、やはり失敗とは言いませんが、成功させ ることはできません。このようにアジャイル（Scrum）を実施しようと考えたならば、まずＴＭＳを学ぶことが先決です。 基本的な意義や目的をを理解した上でScrumのメソドロジーを知れば、自律したScrumチームを育成でき、かつ効 果的にScrumのプロセスを回すことができます。 8 Copyrights@2014_Strategic Staff Services Disciplined Scaling Agile (DSA)の考え方（概念） 2000年以降、わが国でもアジャイル開発が取り入れれて幾多の成功事例が報告されておりますが、その殆ど は、Web系の開発やベンチャー企業などの単一の開発チームであったり小規模なチーム構成です。それで大 規模なシステム開発や大企業での適用は向かない等の意見が散見されますし、アジャイル開発に向いた案 件規模等の議論がされてきました。確かに開発チーム内でのプロセスやチームマネジメントについては有用な メソドロジーを提供してくれておりますが、大規模なチーム、組織での大規模な案件ではどの様に対処すべき か？はScrumでも簡単にScrum of Scrumといった概念を提供しているだけです。ではアジャイル開発の利点を 求めながら大規模案件ではどのように対処すればよいのでしょうか？これまでの議論では、ウォーターフォー ルのメソドロジーと組み合わせてハイブリッドやＲＵＰを起源とするＤＡＤなど種々なメソドロジーが語られており ます。私のアジャイル開発指導経験とＴＭＳの経験からＴＭＳの職場活性化のメソドロジーとScrumのプロセス、 メソドロジーを組み合わせる手法が、大規模なプロジェクトでも効果的であるという結論に至りました。その理 由は、ＴＭＳのメソドロジーはシステム開発手法に囚われず、自律したチームの育成とマネジメント能力の向上 を支援してくれます。ウォーターフォールであれ、アジャイルであれ大規模なプロジェクトの効果的な運営につ いては、特にメソドロジーを提供しておりません。一方、このような大規模なプロジェクトのマネジメントとしてト ヨタで実際に活用されて効果を発揮している『大部屋』という概念と手法は大規模なシステム開発プロジェクト にはうってつけです。 Disciplined Scaling Agile (DSA)という概念は、このようにＴＭＳの『大部屋』の概念、手法でプロジェクト全体を見 える化し、マネジメントできる事と各チーム内で実施されるScrumのプロセス、マネジメントを組み合わせること で、全体と個の双方の同期をとることができ、プロジェクト全体を現地現物でマネジメントできるようになります。 9 Copyrights@2014_Strategic Staff Services Disciplined Scaling Agileとは Planning Phase（計画）: ① Project Scoping ② 方針展開 ③ Visual Board作成 Inception Phase（方向付け、プロジェクトの開始）: ① 要求の把握」とBody Processの確認 ② システム要求仕様の整理 （Rule/Process/Data) 品質条件 ③ Digital Mock-UpでのBody Processの検証 ④ 大部屋の設営 Design Construction Phase (Iterative)（システムの製作）: Scrum(Agile) Product Cycle Lean Product Cycle Test KANBAN Product Cycle Code Transition Phase（移行準備＆ソリューション確認）: Product/Solution Ready Deploy the solution into production Integration Production Phase（運用＆フォローアップ）: / Build システム運用 Runtime Scenario検証 Dependability Assurance Copyrights@2014_Strategic Staff Services 10 Planning Phase（計画） このフェーズでは、従来対象となるプロジェクトの計画立案が中心であったが、DSAでは、このプロジェク トの計画以外にプロジェクト・チームのビルディングの作業を重要視する。したがって以下の三つの事柄 をこのフェーズでは主に実施することが求められる。期間としては、4週間から6週間程度。 ① プロジェクト・スコープの把握 ② プロジェクト・チームとしての方針展開 ③ 各構成チームのビジュアル・ボードの作成 ① プロジェクト・スコープの把握 プロジェクトの目的の明確化（作製するシステムの存立意義・要件） プロジェクトの完了時期、予算規模とプロジェクトチームの編成 ② プロジェクトの方針展開 上位方針を受けて下位のチームと擦り合わせを行い具体的な行動を起こせるようにプロジェクトとしての目標 やあるべき姿、基本的価値観の共有を図る お客様は誰か？ 価値の提供（あるべき姿） 組織の価値観（原理・原則・考え方） ギャップを埋める為 の施策 価値の提供（現状） プロジェクトに対する自分達の思い ③ ビジュアル・ボード 上位の方針展開を受けて各チーム毎にプロジェクトの目的に沿った具体的行動をとるためのチームとしての目 的、行動指針、目標を定めチーム構成員内での自律、活性化の見える化を行う。 あるべき姿（目的） 方針 活動体制 チームの目標 チームの施策（行動） 管理指標（ＫＰＩ） 活動結果指標（ＫＧＩ） ＫＧＩグラフ ＫＰＩグラフ Copyrights@2014_Strategic Staff Services 補助管理のチャート 11 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)してユーザーにシステム概要設計の確認を得る。 ④ プロジェクトの大部屋を設営 物理的に大部屋をセットする。 【大部屋については後続の資料を参照ください】 12 Copyrights@2014_Strategic Staff Services Construction Phase（システムの製作） 開発手法（メソドロジー）は反復的(Iterative)に開発を行う手法であれば、混在可能であるので、スクラムであれ、 リーンであれ、ＫＡＮＢＡＮであれ手法を限定しないが、スクラムの手法がＴＭＳと親和性が高く、実施するうえで は容易と思われる。他の手法の場合は、十分な検討、検証が求められる。 ここでは、手法の着実な実施よりも下記の項目について開発チームの理解と実践に注意すべきである。 ① ② ③ ④ ⑤ ⑥ ⑦ 現地現物での作業進捗把握の徹底 正味作業と付帯作業、及びムダの理解 後工程引き取りの意味 一個流しを実現する工夫 自工程完結のためのチームとしての行動基準 仕事、プロセスの平準化、整流化 振り返り（ＫＰＴ）の実践と質的向上（カイゼン） ⇒ファクト・コントロール ⇒お客様に価値を生まない作業の排除 ⇒手待ちの撲滅 ⇒品質の向上、整流化、 ⇒品質の早期安定 ⇒ボトルネックの解消 ⇒すべての活動（作業）の基本（エンジン） お客様への価値の提供（品質）については、常にチーム・メンバー全員に意識の喚起が必要である。 13 Copyrights@2014_Strategic Staff Services Transition Phase（移行準備＆ソリューション確認） このフェーズでは、もちろんこの前のConstruction Phaseにおいて自工程完結で作業ができていれば、プログラム の品質は担保されているはずであるが、ユーザーにソリューションとして提供されるシステム全体としての確認 ＆テストは必要である。このフェーズでは下記の二点が主要な活動となる。期間としては、4週間から6週間程度。 ① ソリューションとしてのシステム全体での運用テスト ② ユーザーに必要なドキュメントの整備 ① ソリューションとしてのシステム全体での運用テスト ユーザーのオペレーション・シナリオに基づきソリューションとして運用可能であるかの確認をユーザー に確認して貰う。またこのテストが最終のユーザー受入テストとなる。 これはユーザーのビジネス・プロセス上、新たに提供したソリューションとして機能できるか？スムース に運用できるか？という点を確認する事である。 ② ユーザーに必要なドキュメントの整備 最終的にユーザーへ提供されるドキュメントを整備する。ユーザーに必要と思われるドキュメントは、 ◆ メンテナンス・マニュアル ◆ システム運用マニュアル （含む障害回復） ◆ 導入ガイド ◆ ユーザー・マニュアル （操作マニュアル＆ガイド） 等である。 14 Copyrights@2014_Strategic Staff Services Production Phase（運用＆フォローアップ） めでたくソリューション（システム）として稼働するわけであるが、稼働後にお客様（ユーザー）に満足を得て いただくために、フォローアップの様子見の期間。 ここでの注意点は、事前にオペレーション・シナリオにてソリューションの操作や運用を検証しているが、必 ずしもユーザーがそのシナリオ通りに、使用し続けてくれるかというと、案外そうではない。ユーザーも新しい 運用を開始したのち経験を積むに従い、運用や操作の暗黙知（知恵）が出てくる。この暗黙知を形式知する か？どうかを見極める必要はある。一定期間（半年とか一年）後に、この見極めを実施することをお勧めす る。 15 Copyrights@2014_Strategic Staff Services Disciplined Scaling Agile (DSA) の概念図 ＰＭ ＳＭ Visual Board ＰＯ 大 部 Visual Board Scrum Team A ＫＰＴ Scrum Team B ＫＰＴ Visual Board Scrum Team C 屋 Visual Board ＫＰＴ Operation Team ＫＰＴ ＴＭＳコーチ Copyrights@2014_Strategic Staff Services 16 Quickening Visualization System （大部屋方式） 大部屋の模式図 狙い： 人と職場（チーム）の活性化を促進する効果が大きい プロジェクト全体が俯瞰（見える化）できる 「見える化」とは、異常が瞬時に解る、気づく事 Scrum of Scrumの実施会場（場所） スクリーン 品質 プロセス 特長： 大きなプロジェクトや他部署との連携したチームなど組織横断的 な事業に取り組む場合には、『目で見る管理』を大部屋化して行う 大部屋とは、関係者が一つの部屋に集まって課題を見える化し、 問題解決を進めていくやり方 同じ部屋で仕事を行う事でコミュニケーションが活発化しアイデア が沢山でる様になる 改善テーマ ５Ｓ 方針展開 17 Copyrights@2014_Strategic Staff Services 活動の見える化の原理 見える化とは、『異常や問題がすぐにわかるようにする事』 脳の原理に基づいたマネジメント 体験、経験して記憶する方法が効果的 記憶を残すには手や体を動かしながらイメージで記憶する事 脳の記憶を行動に移すには、『繰り返す事』 やるべき事や考えている事（暗黙知）なども紙や付箋に書き出して見える様にする（形式知化）と良いでしょう。 暗黙知 見える化 形式知 見える化のサイクルを回すと、 ①短時間で教える事が出来る ②初めての仕事でも早く覚える事が出来る ③人によってやりずらいなどの課題が見え改善出来る ④仕事の品質のバラツキを抑える事が出来る 『知る→行動する→経験値が増える→形式知化する』のサイクルを繰り返すことで仕事の品質が 向上し達成感に繋がる ファクト・コントロール（Fact Control） 事実に基づいた情報 現地・現物（現場で事実を見る） 現場が「見える化」されていなければ、現場に行っても事実は見えない 事実をどの様にして伝えれば良いか？ Copyrights@2014_Strategic Staff Services 18 ＤＳＡのスパイラル・アップなアプローチ ①見える化 基本２S（整理・整頓） ②職場環境の整備（職場づくり） リーダーシップとコミュニケーション データによる現状把握 手順（標準）の整理 見える化の徹底 大部屋の導入 ③価値の創造（作り込み） お客様第一の視点（考え）での見直し 振り返りの徹底 仕事完了（ダーン）の定義 （自工程完結の基準） 手順（標準）の再設定 ④カイゼンの定着（改善マインド） ５S（整理・整頓・清掃・清潔・躾）の定着 真因の追求（なぜなぜ５回） データによる振り返り 先行改善の実施 ⑤仕事の品質 品質作り込み視点での見直し 仕事完了（ダーン）の再定義 手順（標準）の再々定義 ⑥利益の創造 プロジェクトの評価 スタンドアップ・ミーティング（毎日） 振り返り（毎週） タイムボックス、カンバン タスクボード、掲示物 企画・要求からアーキテクチャ設計そして移行準備迄 UX（ユーザーエクスペリエンス） ジャストインタイム（JIT）、整流化（タスク粒度） お客様視点、プロセス（整流化）視点 ユーザーストーリー ムダ取りの実施 ブレイクスル―思考法（目的の追求） ベロシティー 開発チーム、運用チームからの提言 データでの分析と現地・現物の確認 フィードバック・サイクル、ユーザーとの協働 プロジェクトの透明性 データによる評価 Q（品質）、D（納期、リリース）、C（コスト、生産性） Copyrights@2014_Strategic Staff Services 19 参考資料 トヨタ流の教科書【企業編】 堀切俊雄 著 ＴＭＳ検定公式テキスト ４級 TPS-Toyota Production System-検定4級テキスト Total-TPS基礎知識編 Agile Project Management with SCRUM Ken Schwaber著 The Enterprise and SCRUM Ken Schwaber著 Disciplined Agile Delivery Scott W. Amber / Mark Lines著 日経ものづくり刊 社団法人ＴＰＳ検定協会刊 社団法人ＴＰＳ検定協会刊 Microsoft Press刊 Microsoft Press刊 IBM Press刊 20 Copyrights@2014_Strategic Staff Services
© Copyright 2024 Paperzz
