Embed Size (px)
Citation preview
REVIVAL TO ORIGIN OF SCRUM & XP アジャイル開発 原点への回帰 TPSからの気付き
TMS ＆ LEAN DIGITAL SUMMIT IN JAPAN 2019
エグゼクティブセミナー
TMS＆TPS検定協会 理事株式会社戦略スタッフ・サービス
戸田 孝一郎
何が大事なのか？
アジリティー（機敏性）スピード
でもしっかりと管理すべきことは、管理できる。
リアルの世界を常に認識できる。
現地現物（100%の透明性）
デジタルビジネス・アジリティー
アジリティーがディスラプションを生み出すハイパーアウェアネス（察知力）情報（事実）に基づく意思決定力迅速な実行力
速く走れなければ、機敏性も適応力も向上しない！状況の見える化意思決定の速さ実行の即時性（真実の瞬間、MOT）
➢管理（組織）階層を浅く、少なくする。（フラットな組織）意思決定スピード、サイクルの短期化
➢大幅な現場への権限移譲自律した社員（現場）方針展開（ビジョン、目的の共有化）
アジリティー（機敏性）とは？
➢ より素早い提供 （Deliver Faster）➢ 高品質 （High Quality）➢ より安く （Lower Cost）➢ シンプル化 （Reduce Complexity）➢ 素早い意思決定 （Faster Decisions）➢ 常に先行 （Stay Ahead）
優先順位（Prioritization）
見える化（Visualize）
5S（Seiri, Seiton）
9 million cars
600,000
9.5 million cars
344,000
現場オペレーション
管理
経営
現場オペレーション
管理
経営
組織の筋トレ
大部屋システムは、現場と経営、管理のスピードの同期を取り、意思決定サイクルの短縮を目指す。
Reporting
Daily Daily
Daily
Daily
DailyDaily
Weekly
Monthly
現場が見える化されて居れば、報告書を作成する必要が無い。
OBEYA
TMS改善塾（TOYOTA way Management System）
スピードは品質（e-TOYOTA 藤原部長）
ビジネス・スピードを上げる
テイラー主義とTPS（トヨタ生産方式）
テイラー主義（フデリック・テイラー、IEの父）20世紀の遺産1900年に科学的管理法を発表（Industrial Engineeringの父）大量生産の理論、リソースの効率良いモノつくり法特徴的な思想： 物事は計画通りに進む。
計画立案と実行を分ける精緻に計画を立案できれば、実行者（作業員）は置き換え可能、マニュアルで標準化して教育できる。独立した品質管理部門の設置で品質を管理できる。
TPS（トヨタ生産方式）1945年より研究＆成熟してきたモノつくり法（今やグローバルスタンダード）当初よりテイラー主義で成功した大量生産方式に対抗するために考案特徴的な思想： ジャストインタイムと自働化
無駄を無くしてリーンなプロセスを作る。理想は一個流し品質を良くするとスピードが上がる。品質は現場で作り込む。自工程完結（不良を作らない）現地現物（理論ではない現場が全て）人作り
昭和20年 豊田喜一郎社長から大野耐一氏へ『3年でアメリカに追いつけ』日本とドイツ１対３、ドイツとアメリカ１対３＝日本とアメリカ１対９（10倍の生産性）
ウォーターフォールとアジャイル
ウォーターフォール型開発：何を間違えたのか？大量生産方式の理論であるテイラー主義を採用。【仮説】1970年代、80年代のソフトウエア開発の主要な領域（主役）は、OSやDBMS、ミドルウエア群であり、言語はアセンブラー、COBOL、PL/1。また当時はIT技術や開発手法を先導したのはIBMに代表される大手ITベンダーであり、OSやミドルウエアでの成功体験がユーザーに広まった。またユーザーが作成するアプリケーションプログラムはシステム全体から見れば従であり、ITベンダーの技術を横展開システム全体像を固めて（範囲の定義）、必要な機能にブレークダウンする詳細設計、詳細な仕様を定義するWBS等全体から局所への設計手法が洗練化され確立しPBoKとして経験値の標準化が行われた。
【問題提起】OS、DBMS、ミドルウエアとアプリケーションプログラムの性格は異なるのに何故大手IT ベンダーの狭い領域での成功体験を模倣したのか？アプリケーションは千差万別でＯＳなどとは全く性格が異なる。元々、アプリケーション開発にＯＳなどの開発成功体験は活用できないのでは？？？100％カストマイズされているアプリケーション（世界で一つしかないモノ）に100万個製造するような大量生産の概念が適用できる訳がない。品質管理手法についても同様。
機能を重視したＯＳ、ＤＢＭＳ，ミドルウエアは機能設計ビジネスプロセスを支援するアプリケーションは機能よりもプロセス（流れ）が重要ではないか？何故プロセスで設計しないのか？オブジェクト指向の概念導入以来アプリケーションも機能指向で設計される。（強い違和感）
ウォーターフォールとアジャイルYou can’t Do Agile, You have to BE Agile
アジャイルな働き方アジャイルなプロセスアジャイルな体制アジャイルな計画アジャイルな設計アジャイルなプログラミングアジャイルなテストアジャイルな移行（ディプロイ）アジャイルな運用アジャイルな管理
Scrum + DevOpsScrumScrumT-MethodXPXP + Scrum + CIDevOps (CD)DevOpsLight weighted IT Service Management
全面的なパラダイムシフト
History of Agile
TPS （1945～）Scrum （1995～）
eXtream Programming （1996～） Agile Manifest （2001）
Lean （1990～）
New New Product Development Game（1986）The book of TPS
published （1978）
TPSアジャイル （2008～）
The Concept Tree for Disciplined DevOps & Agile
Just In Time(JIT)
自働化(Autonomation)
流れ
不良を流さない不良で止まる
スピード、機敏性、変更対応力
品質最優先
アンドン 自工程完結
プル型のプロセス（後工程引き取り）
かんばん（最小WIP)
整流化 流水化
一個流し
タクトタイムかんばん ０
タスク（作業）の粒度
平準化（ムラ、ムリ）
サイクルタイムバリューストリームマップ
ポカヨケからくり
反省（失敗から学ぶ）
全員で解決最終プロダクトの品質を決定するタスクの発見
DoD（完了の定義）
５Sなぜなぜ
5回
永遠の改善先行改善
見える化目で見る管理
チームプレー連帯責任
お客様第一全体最適
目標・価値の共有現地現物
ムラ・ムリ・ムダ
現場アティテュード（行動習慣）
スクラム
XP
TOC（ザ・ゴール）KANBANの考え方は中途半端で終了
CD（継続的デリバリー）
CI（継続的インテグレーション）
ペアプログラミングリファクタリング
TDD（テスト駆動開発）
ベロシティー
スクラムチーム・ビルディング職場活性化活動（TMSコア）の六つの要素
1. 活動の見える化：方針管理、 日常管理、 仕事の見える化
2. 職場づくり：コミュニケーション、 リーダーシップ
3. 価値の創造：お客様第一、成果へのこだわり
4. 改善マインド：ムダを見つける目、整理・整頓（２Ｓ）、問題解決力
5. 仕事の品質：統計的なモノの見方・考え方、 自工程完結
6. 利益の創造：利益を生み出す仕組み、生産性の向上
職場活性化活動
活動の見える化
職場づくり
価値の創造
改善マインド
仕事の品質
利益の創造
「人間性尊重」という考え方が中心
組織目標に向けた仕事を通じ、感動や達成感、やりがいを味わえないのはとてももったいない時間の使い方であるというのが「人間性尊重」の考え方です。
• 自分にとってのお客様はだれか
• あるべき姿と現状とのギャップは何か
• あるべき姿に向けての行動を妨げている真因は何か
• 真因に対してすぐに対策を打てているか
これらの考え方を実践することが人間性尊重につながる行動といえます。
幹部社員やチームリーダーの役割は、メンバーの能力を最大限に発揮させ、やりがいや達成感を持たせ部下に成果を出させることです。
デジタルよりもアナログ日常がわかる「目で見る管理」
「目で見る管理」は、自分のマネジメント能力の限界を広げてくれます。
チームビルディングのスタートポイント Visual Management Board
『考える』の開始点 なぜなぜ5回
真因を考え、品質に影響を与えていた本当の原因を取り除くための考え方。なぜなぜを５回くらい繰り返せば、真因が見えてくるだろうと仮定して５回と決めている。
問題の真の原因が発見されない限り、根本的な解決、再発防止ができません。
発生防止と流出防止 （自工程完結）
• 発生防止– 一度でた不良を次の仕事にフィードバックし同じ問題を起こさない。（再発防止）– 再発防止では防げないような問題を事前に問題として見つけ予防する考え方。
• 流出防止– 後工程に不良を流さないための考え方。
他人の努力を無にしない
目指すべき姿 ---- 機敏な、高品質チーム （自己組織的、自律的）
１．境界や限界を超える優れたチームには、通常と違う高い目標意識がある。自ら認識しているゴールがあるからこそ、通常のレベルを超え、卓越した領域に達する事ができる。平凡なレベルで良しとしない決意、素晴らしい仕事をするという決意そのものが、自らを見つめる目を変え、能力をも変える事ができる。
２．主体性優れたチームは自己組織的かつ自己管理的である。どう仕事を進めるかを自分たちで決める力があり、決めたことを守り実現していく力を持っている。
３．機能横断的優れたチームはプロダクトの完成に必要なスキルを全て備えている。計画、設計、製造、営業、販売など。こうしたスキルはそれぞれ支え合い強化しあっている。キヤノンで革新的なカメラを考案したチームのメンバーはこう表現する。『広い部屋にチームの全メンバーが集まると一人が持つ情報は自然と自分の情報になる。すると自分一人の立場からだけでなく、チーム全体にとって何がベストか？、次に良いのは何か？という視点で考えるようになる。』
スクラムの基礎となった論文より（HBR 1986年 New New Product Development Game:『新たな新製品開発競争』著者：一橋大学 野中郁次郎、ハーバードビジネススクルール 竹内弘高）
自己組織化されたチームを育む環境要件
三つのレベルで考える必要があります。まずチームを構成するメンバー（人材）に関する要件です。それは最低限『自律したメンバー』で構成されているという事です。『自律したメンバー』とは、具体的な行動に表すと、自身の行動につて自身で意思決定し、その状況や結果に対する説明責任を果たす信頼できる人材という事になります。ここで大事なことは、人間としてメンバーとして関係者間で信頼される人材であるという事です。信頼を醸成する要素は、有言実行、説明責任を果たす、行動の透明性を確保できるという三つの要素です。特に行動の透明性を確保するという事が一番大事です。次にこのような人材で構成されるチームに関する要件ですが、チームとして最初に重要なのは、メンバー間、その他外部のステークホルダー間で、十分なコミュニケーションがとられ、目的、目標、責務などチームにとって必要な情報がメンバー内で完全に共有化された状態にあるという事です。そしてすべての行動、結果はチームの全体責任で運用されている事です。さらにチーム内のメンバーは機能横断的な知識、スキルを保持しており、理想としては、メンバー全員がチームリーダーであり、かつフォロワーでもある柔軟な（ダイナミックな）チーム内での役割分担ができるチームです。そして当然のごとくチームは主体的であり、チームの限界や境界を越えて仕事のできるチームです。最後にこのような人材、チームを育む組織運営が企業として求められます。この様な組織の特徴はアダプティブで機敏性のある柔軟な組織構造（フラット化）を有しています。また組織内では、常に権限委譲が必要に応じて大幅にされるスピード感のある組織です。このような組織では、従来からの人事評価制度も個人からチームの評価へと変更を余儀なくされます。
組織の変革（組織の四段階）
個人
人間関係
マネジメント
組織
アウトサイド・イン インサイド・アウト
従来のアプローチ パラダイム・シフトのアプローチ
二面性
不信感
命令＆統制
深い階層
信頼性
信頼感
エンパワーメント
アライメント
ビィジョン、原則
各要素が同じ方向を向く
自分自身を変える！外枠からのアプローチ
見える化、説明責任
活性化された職場 （役割と責務）
チーム 管理者（マネージャー）
職場を活性化させる全ての行動の立案と実行 お客様の要望する品質、納期、価格での提供
（お客様が満足して、すぐに代金を支払っていただけるか？） 自身の仕事の価値の向上（常に現状に満足せず、日々改善の模索）
新技術・手法の目利き（評価） ツール類の企画・作成
部下の職場の活性化を促す環境を整える 職場を活性化させる気付きを作る 全体プロセスの流水化 （澱みなく仕事が流れる） 流水化の為の他部門への提言（組織間のサイロの破壊）
明確な方針の展開（ビジョン、上位方針、組織の存在価値）
チームの生産性を阻害する要件を全て排除する。
方針、指示にはすべて明確なビジネス価値に基づく優先順位付けを行い、常にこの優先順位を更新管理する。
➢ 見える化➢ 自工程完結
➢ 改善 （ムダを見つける目）
➢ 現地現物
➢ 現状否定 （常に常識、慣習に疑念の目を向ける）
➢ プロセスの流れ
日経コンピュータ連載コラム（１）
1. 2017年4月13日 元気が無い現場に四つのサインあいさつが元気を取り戻す第一歩2. 2017年4月27日 コミュニケーションが取れない組織他人をどれだけ知っているのか3. 2017年5月11日 残業が減らない組織属人的な仕事を無くしているか4. 2017年5月25日 多忙で夏休みを取れない職場改善活動の停滞乗り越え取得率向上5. 2017年6月8日 助け合いの無いシステム部門「心のマネジメント」が改善のカギ6. 2017年6月22日 アジャイル開発でチームを元気に初挑戦でも成功、カギは見える化7. 2017年7月6日 発注者の信頼をどう得るのかアジャイル開発成功のカギ8. 2017年7月20日 チームの透明性はアナログで高める 自らを律するのが成功の秘訣9. 2017年8月3日 暗すぎるウォーターフォールの現場 やる気引き出す心のマネジメントを10.2017年8月17日 進捗が90％から先に進まない 1時間の作業に分割しているか
総合タイトル：前編 【現場を元気にするチーム運営術】
総合タイトル：後編 【現場を元気にするDevOps 2.0】1. 2017年9月14日 今こそ大量生産時代の常識に決別 トヨタ由来の方法論で元気になろう2. 2017年9月28日 自ら改善を続けるチームに変える 働き方改革への第一歩3. 2017年10月12日 人を大切にするのが「強い企業」 仕事のやり方を変えて近づこう4. 2017年10月26日 「サイロ」現場を３段階で変革 個別最適では幸せにはなれない5. 2017年11月9日 アジャイル開発の品質向上策 ７つの視点で作業の様子を観察6. 2017年11月23日 「伝達ゲーム」は開発失敗の元凶 業務プロセスの観点を貫こう7. 2017年12月7日 ビジネスの速度が3倍に 全体最適に変革する3ステップ8. 2017年12月21日 ウォーターフォールは時流に合わない まずは安全管理と可視化に着手9. 2018年1月4日 チームを育てるならアジャイルを マネジャーは支援役に徹する10.2018年1月18日 ツールだけでは元気は出ない DevOps 2.0に必要な7つの役割
25
日経コンピュータ連載コラム (2)
26
総合タイトル：続編 【現場を元気にする組織変革術】
1. 2018年4月12日 組織変革は１日にして成らず トップを変え、３段階で現場を変える2. 2018年4月26日 やる気引き出す「心のマネジメント」、まずは鏡を3. 2018年5月10日 言葉では３割しか伝わらない、現場に出向き変化を感じ取る4. 2018年5月24日 大切なのはルールよりマナー、「人の幸せ」を目指す発想方法5. 2018年6月7日 意思決定の遅さを変革 新事業を次々生み出すコツ6. 2018年6月21日 泥臭さと人を幸せにする思い リーダーに求められる行動原理7. 2018年7月5日 さらば縦割り組織、形だけで終わらせないマネジメント8. 2018年7月19日 「知る」と「分かる」は大違い マネジャーは現地現物の徹底を9. 2018年8月2日 誰でも必ず変革できる 行動できない人を動かす術10.2018年8月16日 慣れ親しんだ全てが変革を妨げる ウォータフォールの現場に決別11.2018年8月30日 高めたいのはIQより「EQ」 フェイス・ツー・フェイスから始めよう12.2018年9月13日 アジャイル変革は「急が回れ」 上っ面の理解では失敗が連鎖する13.2018年9月27日 変化の兆しを感じ取れるか 「KPT」で可視化して成長促す14.2018年10月11日 運用部門に元気を取り戻す NTTデータCCSの挑戦15.2018年10月25日 チェックリストが元気を奪う NTTデータCCSの気づきと改善16.2018年11月22日 ベンダー常駐チームと初アジャイル 外資系保険会社が一念発起17.2018年12月6日 外資系保険会社の初アジャイル 成功への軌跡
Bit Coin POC projectVeriSM＆TMSを活用したプロジェクトの例
ケーススタディー
2018年度ＩＴ特別賞（組織風土改革賞）受賞 ㊗ 2018年度企業情報化協会
スーパーSE100人衆登録
https://www.youtube.com/watch?v=cYPRddt3E8k&t=29s
Key Partner
KeyActivities
Key Resources
Cost Structure
CustomerRelationships
Customer Segments
Channels
Value Propositions
Revenue Streams
Key Partner
KeyActivities
Key Resources
Cost Structure
CustomerRelationships
Customer Segments
Channels
Value Propositions
Revenue Streams
企画承認 プロジェクト着手（開発開始）Key Partner
KeyActivities
Key Resources
Cost Structure
CustomerRelationships
Customer Segments
Channels
Value Propositions
Revenue Streams
サービスイン（リリース）
推測：思い付き、データで説明できない仮説：一部のデータで主要な部分の説明ができる事実：ほぼデータで説明できる。
プランニング・セッション
マネジメントメッシュ定義
企画から実現へ
4週以内
24週以内
どんなに大きな課題でも、基本24週以内で計画する。24週以上になるプロジェクトは、24週ごとにレビュー＆次の予算の承認を得る。
明確に色が認識されてから企画承認を得るのでは無く、ぼんやりと色が識別できる様になったならば企画の是非を問えるスピード感を持たせる。
ビジネス・チーム施策
インフラ・チーム施策
開発チーム施策
運用チーム施策
セキュリテー施策
ビジネス・チーム行動計画
開発チーム行動計画
インフラ・チーム行動計画
運用チーム行動計画
セキュリテー・レビュー計画
KPI
KPI
KPI
KPI
KPI
ビジネスの目的 方針 活動体制 マイルストーン
３ヶ月後のあるべき姿
６ヶ月後のあるべき姿
KGI管理項目
VMBを企画段階からプロジェクト終了まで一貫した管理資料として活用
計画立案～企画承認～プロジェクト開始～完了までの間に徐々に情報量、情報精度が改善していく為に、常に定期的な見直しを関係者で行う。
Environment Environment Environment
Key Partner
KeyActivities
Key Resources
Cost Structure
CustomerRelationships
Customer Segments
Channels
Value Propositions
Revenue Streams
Key Partner
KeyActivities
Key Resources
Cost Structure
CustomerRelationships
Customer Segments
Channels
Value Propositions
Revenue Streams
運用中
Key Partner
KeyActivities
Key Resources
Cost Structure
CustomerRelationships
Customer Segments
Channels
Value Propositions
Revenue Streams
Key Partner
KeyActivities
Key Resources
Cost Structure
CustomerRelationships
Customer Segments
Channels
Value Propositions
Revenue Streams
修正(Maintenance)：該当分を修正し保守する。（4週以内）使用継続差し替え(Replace)：該当部分を作り直す。（12週以内）⇒開発完了後、該当部分を追加、差し替えをする。移行(Convert)：新しいやり方に作り直す。（13週以上）⇒既存を稼働させながら並行してアジャイルで新規を開発し、一定の条件で移行可能な状態に至ったらば、業務を新しいモノに切り替えて移行を完了する
既存サービス（システム）の更新
既存サービス（システム）への変更修正、保守要求は、下記の判断基準にて対処する。
マネジメント・メッシュの管理項目に注目して、運用中サービス（システム）への変更、保守の必要性を定期的にレビュー
リソース
ビジネス環境
革新的な
テクノロジー
管理手法
日経コンピュータ連載コラム (３)
1. 2019年1月24日 創業15年目にシステム障害が多発 停滞した現場に社長自らがメス2. 2019年2月21日 統率型に染まったリーダーたち それで現場が明るくなる？3. 2019年3月21日 冷めたメンバーは必ずいる 思いを聞き出しチーム巻き込む4. 2019年4月18日 スランプは改革に付き物、答えは不要、やる気促す声かけを5. 2019年5月16日 熱い思いが空回り そんなときこそ「聞く耳」を6. 2019年6月13日 2泊3日の集中議論 関係者の合意を一気に取る7. 2019年7月11日 社長メッセージでやる気にさせる、文書作成よりも「全員合意」を重視8. 2019年8月8日 開発費を6割削減 初挑戦アジャイルで得た成果9. 2019年9月5日 アンチの塾生に1時間向き合う 行動する人を支えて良い流れに10.2019年10月17日
総合タイトル： 【現場を元気に！ カブコム現場改革の軌跡】
ThankYou
