kaizen it summit 2017 プロフェッショナルコース tps...
TRANSCRIPT
TPSとDevOpsDevOps,アジャイル開発をTPSから考える
Sept. 29 / 2017
戸田孝一郎
社団法人TMS&TPS検定協会
Kaizen IT Summit 2017プロフェッショナルコース
アジェンダ
DevOpsの概念DevOpsの仕組み（プロセス）TPSから見えるDevOps【ワークショップ】まとめ
DevOpsの定義
ビジネスの企画からITサービスの開発、稼働、運用までの一連のプロセスを顧客の視点を優先し、ビジネス競争力を高める施策やそれらを支援するITサービスを効果的、効率的に提供する一連の活動とその活動を成熟化させる行動習慣（組織文化）である。
上記の概念を実現するために特に重要な基本思想として、ジャスト・イン・タイムでのITサービスの提供可能な限り自動化されたプロセス顧客視点でのプル型のプロセス運用自律したチームによるQCDの向上
CALMSモデル
Culture
Automation
Lean
Measurement
Sharing
パラダイムシフト行動習慣の変革
可能な限りの自働化
継続的な改善（ムダの排除）
見える化、ビジネス業績による評価
目的、情報、知識、経験（失敗）の共有化
コラボレーションとコミュニケーションを推進するための変革を負う
バリューチェーン内から手作業のステップをなくす
リーン原則の採用により，サイクル周期を高める
すべてについて計測し，データをサイクルの洗練化に活用する
他者が学べるように，経験や成功の可否を共有する
頭字語であるCAMS (Culture, Automation, Measurement, Sharing)は，John Willis氏とDamon Edwards氏が2010年，カリフォルニアのマウンテンビューで，米国内で始めて開催されたDevopsdaysの中で提唱したものです。後にリーンを意味する“L”がJez Humble氏によって加えられました。
DevOpsの原則
①顧客中心の活動エンドユーザーからの短いフィードバックループ
②全体最適で目標を意識した創造製品、サービス全体を描ける技術者としてのマインドセット
③エンド・ツー・エンドの責任垂直統合された一つのチームがコンセプトから廃棄までのすべての責任を持つ
④機能横断型の自律したチームT型人間（技術スキル）のチームでQCDを自らマネジメントできる
⑤継続的な改善継続的に変更を受け入れ顧客の要求の変化、新技術、法規制に対応するカイゼン（昨日よりも良い）の姿勢とプロセスの成熟化
⑥自動化できるものはすべて自動化高いサイクルレート、短いリードタイムの実現に向けあらゆる自動化を試みる
DASA: DevOps Agile Skills Association
DASAコンピテンシーフレームワーク
８つの知識エリアと4つのスキルエリア
【知識エリア】①要件と検証
事業価値最適化事業分析アーキテクチャと設計テスト仕様
②開発とデリバリープログラミング継続的デリバリーセキュリティ、リスク、コンプライアンスインフラストラクチャ・エンジニアリング
【スキルエリア】③導入と拡張
勇気チーム構築DevOpsリーダーシップ継続的改善
アジャイルチーム
(スクラム)
アジャイルチーム
(スクラム)
アジャイルチーム
(スクラム)
アジャイルチーム
(スクラム)
アジャイルチーム
(スクラム)
デプロイメントパイプライ
ン
サービスバックログ
デプロイメントバック
ログ
オペレーションバックロ
グ
運用
タスクボード
タスクボード
タスクボード
サービスバックログ
タスクボード
サービスバックログ
タスクボード
タスクボード
タスクボード
イテレーション
週・日 単位
ゲートキーパーDevOpsエンジニア
リライアビリティーエンジニア
運用チーム
スクラムチーム
サービスマスター
プロセスマスター
DevOps2.0概念図
DevOpsのプロセス（模式図）
開発チーム ビルド管理
パイプライン
テスト 受入 稼働
Aプロジェクト
Bプロジェクト
Cプロジェクト
Dプロジェクト
DevOps 2.0 とは
DevOps 1.0 DevOps 2.0
カバーする領域
主な着目点
適用する概念、手法
開発からデプロイ・リリース迄
頻繁なリリース、スピードSoE（Web)が主体
アジャイル開発、継続的インテグレーション、継続的デリバリー、リーンの考え方
ビジネス企画から運用・EOL迄
素早いリリース、事業の継続性SoE, SoR双方
規律あるアジャイル開発、継続的インテグレーション、継続的デリバリー、軽量化したITサービスマネジメント、ISO20000、ALM、TPSの考え方
企画 要求 設計 開発デプロイ
運用EOL
Process
DevOps 1.0
DevOps 2.0
【ワークショップ】
規律あるアジャイル開発 （開発チーム）
デプロイメント・パイプライン
DevOps 2.0 職場の活性化
自工程完結
仕事の分析
一個流し（流水化）
自働化
先行改善
振り返り（反省）
ジャストインタイム
平準化
後工程引き取り
運用チーム大部屋
タクトタイム
現地現物
右のTPSの考えや手法は、DevOpsのどの場面で活用されるでしょうか？
【ワークショップ】
規律あるアジャイル開発 （開発チーム）
デプロイメント・パイプライン
DevOps 2.0
職場の活性化自工程完結
仕事の分析
一個流し（流水化）
自働化
先行改善
振り返り（反省）
ジャストインタイム
平準化
後工程引き取り
運用チーム
大部屋
タクトタイム
現地現物
自工程完結
仕事の分析
職場の活性化
振り返り（反省）
アジャイルチーム
(スクラム)
アジャイルチーム
(スクラム)
アジャイルチーム
(スクラム)
アジャイルチーム
(スクラム)
アジャイルチーム
(スクラム)
デプロイメントパイプライン
サービスバックログ
デプロイメントバックログ
オペレーションバックログ
運用
タスクボード
タスクボード
タスクボード
サービスバックログ
タスクボード
サービスバックログ
タスクボード
タスクボード
タスクボード
大部屋
一個流しのフロー
イテレーション
週・日 単位
ゲートキーパーDevOpsエンジニア
リライアビリティーエンジニア
運用チーム
スクラムチーム
サービスマスター
プロセスマスター
バリューストリームマップ見える化ボード類
DevOps2.0概念図
計画から運用までの全体最適による流水化されたプロセスの構築
価値観スピード働き方
時間の使い方計画
プロジェクト
リスク役割進捗管理見える化評価基準要求設計開発コード品質ドキュメントデプロイ＆リリース運用運用管理リーダーシップ
計画重視遅い仕事はまとめた方が効率が良い残業を認める仕事の目的を達するまでの時間計画重視全期間にわたる計画立案（計画通りにコトは運ぶ）
しっかりと計画を立て、理論的に進める。プロジェクト後半に増大専門家（分業化）管理指標作業が終わらないと見えない計画に対して管理可能、100％定義可能機能中心設計基本は個人（専門家）属人化する管理強化（当たり前品質）多種多様、管理基準半自動分権独立ITIL統率型（指示＆命令）
リソース重視、適応性重視早い仕事は一つづつこなした方が効率が良い残業を認めない （定時間労働）区切られた時間内で仕事の目的を達成 → タイムボックス計画作り重視（朝令暮改）当面１ヶ月は詳細に、後は粗い計画（計画通りにはコトは運ばない）
反復的（イタラティブ）に進めるフィードバックが重要プロジェクト前半に集中多能工化（T型人材））現地現物管理（働くプログラムのみ）ほぼ何時でも見える化（透明性）ビジネス価値（ビジネスの成果）管理不能、定義不能（標的は動く）プロセス中心設計チームの連帯責任属人性の排除向上可能性あり（魅力的品質）MRI （最低必要限）使用目的の明確化自動化 （デプロイメント・パイプライン）オペレーションの一体化軽量化したITサービス管理＆ISO20000サーバントリーダーシップ（ファシリテーション）
ウォーターフォールを中心とした従来の方式 アジャイル、DevOpsの新しい方式
何を変えるべきか？
DASAコンピテンシーフレームワーク
８つの知識エリアと4つのスキルエリア
【知識エリア】①要件と検証
事業価値最適化事業分析アーキテクチャと設計テスト仕様
②開発とデリバリープログラミング継続的デリバリーセキュリティ、リスク、コンプライアンスインフラストラクチャ・エンジニアリング
【スキルエリア】③導入と拡張
勇気チーム構築DevOpsリーダーシップ継続的改善
職場の活性化（自律したチーム）
TMS
活性化された職場・チームの定義
方針展開に沿い、組織の目標を効果的(効率的)に達成する為にチームが協調して自律的に、問題、課題を認識し、その解決を図りながら、永続的に成長する事で、仕事を通してやり甲斐、達成感を味わい、顧客を含めたその関係者間に、感謝・感激・感動の気持ちが芽生える。
職場活性化の認定基準
モラールモチベーションカイゼン目線(現状否定)目標の共有作業標準化見える化施策、手段の共有自発的な言動One for All, All for Oneの意識(言動)プロセスの流れ重視品質に対する拘りお客様に対する想い自分達の強み、弱みを認識できる
上記の事柄が振り返りの中で議論され、その結果がビジュアル・ボードに表現されているか？
準備中： 一人のリーダー格が頑張ってチームを引っ張って居る状態 20%成長中； 複数の一部リーダー格が協調してチームを引っ張って居る状態 40%醸成中： 過半のメンバーがリーダー格をこなせ、チーム何に協調が働いている 60%成熟期： 大多数のメンバーがリーダー格をこなせ、ほぼ全員が日替わりリーダーでチームが活動中 80%
具体的には？
活性化された職場での社員の行動は？
問題解決の検討など思考のパターン（以下の四点のどれかが発想の原点）
① お客様第一② 全体最適③ ビジネススピードを上げる④ 品質の向上（手戻りを発生させない）
チームの行動（働き方）
① 全員がタイムボックスで行動（チームの行事にはすべて上限時間が決められている）② 一定間隔（一週間）での振り返り（反省）が全員で実施されている③ チームに規律ができている（チームのルールが決められ、振り返りの結果で適宜更新されている）④ 全員がチームの目標を共有している（目標達成の為の自分の役割、責務、責任を明確に各自が把握している）⑤ チームの活動が「見える化」されている⑥ 全員が自工程完結の働き方をしている
全員が自分の存在意義（意味）を理解し、どの様な価値を提供するのかを理解している作業完了の定義（DoD）が明確に決められ、全員が守っている作業完了を判断できる道具（測定ツール）をチームで自作している
作業標準を自分たちで決めて、適宜更新されている⑦ チーム内のコミュニケーションの基本は、フェイス・ツー・フェイスで行われている⑧ 事象の判断、決定（決め事）は全て現地現物で全員一致で決められている⑨ チームの構成員全員が互いにリスペクトしている。（チームの構成がフラットな構造で、リーダーとフォロワーの
関係が固定化していない）
役割と責務
チーム 管理者（マネージャー）
職場を活性化させる全ての行動の立案と実行 お客様の要望する品質、納期、価格での提供
（お客様が満足して、すぐに代金を支払っていただけるか？）
自身の仕事の価値の向上（常に現状に満足せず、日々改善の模索）
新技術・手法の目利き（評価） ツール類の企画・作成
部下の職場の活性化を促す環境を整える 職場を活性化させる気付きを作る 全体プロセスの流水化 （澱みなく仕事が流れる）
流水化の為の他部門への提言（組織間のサイロの破壊）
明確な方針の展開（ビジョン、上位方針、組織の存在価値）
チームの生産性を阻害する要件を全て排除する。 方針、指示にはすべて明確なビジネス価値に基づ
く優先順位付けを行い、常にこの優先順位を更新管理する。
➢ 見える化➢ 自工程完結➢ 改善 （ムダを見つける目）
➢ 現地現物➢ 現状否定 （常に常識、慣習に疑念の目を向ける）
➢ プロセスの流れ
日経コンピュータ連載コラム
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日 今こそ大量生産時代の常識に決別 トヨタ由来の方法論で元気になろう
ご清聴ありがとうございました。
ワークショップ （演習課題）
一個流し 流水化プロセス デプロイメントパイプライン
自工程完結 テスト駆動開発（TDD)
平準化タクトタイム
小さい粒度のタスクタイムボックス
自働化 行燈 継続的インテグレーション（CI)継続的デリバリー（CD)
反省 PDCA レトロスぺクティブ KPT
関係性を説明してください。
プル型のプロセス 後工程引き取り
見える化 ビジュアルボード タスクボード、情報ラジエター
方針展開目標、目的の共有化
現地現物 実測駆動での見積・計画
リリースプラン（2レベルプランニング）