Microsoft PowerPoint - VeriSM+DevOps2.1Mr.Toda.pptx

Size: px

Start display at page:

Download "Microsoft PowerPoint - VeriSM+DevOps2.1Mr.Toda.pptx"

さやはぎにわ
6 years ago
Views:

1 Jan Strategic Staff Services Corporation 1 AGENDA Digital Transformation Digital Age のビジネス VeriSM とは? 出現の背景概念と目的 DevOps との関係性 VeriSM の利用法誰が主要なユーザーか? 何のために必要か? 2 1

2 2018/1/23 デジタルトランスフォーメーションとは最新のデジタル技術の適用が全ての組織営業マーケティング生産経理人事顧客サービス等に浸透するデジタル技術と協働して新たなサービスオポチュニテキィを開き顧客の行動習慣を変質させることにより既存のビジネス習慣にディスラプション破壊を起こす ITの浸透が人々の生活をあらゆる面でより良い方向に変化させるという概念既存ビジネスをアナログからデジタルへデジタルからアナログへとシームレスに変換できる組織への変革全ての企業はITを中心とした組織に変わる全ての組織がITサービスプロバイダーに変質するという事 IT 情報技術が一般化すると優位性はデータを保有する側に移るデジタル技術は変化のスピードをより速くさせる既存のマネジメントモデル静的な管理機構が機能せずよりアジリティーを求める動的なマネジメントモデルが必要となるビジネスのデジタルトランスフォーメーション実質的なテクニカルな知識 3 UX デザイン重要な６要素最新のデジタル技術とクラウドの影響アジャイルな体制ビジネス洞察力カルチャー企業文化の変更サービスカルチャープロセスの変更マネジメントの変更よりテクノロジーとの連携ユーザーエクスペリエンス顧客の行動習慣の変質協働協調のプロセス起業家マインド Graphic: Deloitte University Press 2

3 サービスカルチャー必要な要素 : 適応力 ( 柔軟性 ) サービス品質に拘る顧客の期待感に答える徹底した顧客主義 ( 最終消費者 ) やる気のあるスタッフ 10 個の E Empathy 共感 ( 感情移入 ) Excellence 卓越 ( 所 ) より良いサービス良いフィードバック満足する消費者 Empowerment 自由裁量権の増大 Engagement 約束 ( 積極的な関与 ) Easy to do business with ビジネスをしやすくする Everyone 誰でも Environment 周囲の状況 ( 環境 ) Experience 体験経験を通した知識 Encouragement 激励促進助 Effective 効果的印象的な ( 感銘を与える ) 5 デジタルトランスフォーメーションどの様に変革を起こすのか? 三つのタイプ 1 ビジネススピードトヨタ型ビジネスプロセスのスピードを上げて競争力を生むビジネス戦略 2 イノベーティブアップル型今まで世の中にないイノベーティブな商品 / サービスを作り競争力を生むビジネス戦略 3 1 と 2 の混合アマゾン型究極のデジタル化で上記二種の要素を複合してあらゆる製品サービスを組み合わせられるサービスを作り出して圧倒的な競争力を生むビジネス戦略 6 3

4 2018/1/23 VeriSM によるデジタルによるデジタルトランスフォーメーション VeriSM のご紹介のご紹介 VeriSM 出現の背景 2017年デジタルエージ時代を見据えた新しい環境下でのサービスマネジメントの必要性が高まってきた伝統的なITサービスマネジメントの手法考え方を利活用しアジリティーを高める新たな概念が求められてきたネットワークエフェクト影響が強くなってきた繋がり新しいデジタルエージ時代に適した新しいガバナンス企業統治やコンプライアンスの重要性が高まってきた要は時間軸を強く意識したアジリティーマネジメントシステムの構築 8 4

5 VeriSM とは? Digital Transformation の時代全ての組織がサービスプロバイダー化する可能性があるどの様に IT サービスを提供し維持するのか? VeriSM とは組織が持っている固有の環境を前提にしたサービスマネジメントからのアプローチ基本的価値観 Value-driven ( 価値主導 ) Evolving( 発展展開する ) Responsive( 敏感に反応する ) Integrated( 統合結合された ) Service( サービス ) Management( マネジメント ) 9 対象は活動経営者管理者 ( 事業部 &IT) サービスオーナーサービスマスター IT 専門職 (DevOps チーム ) IFDC (International Foundation for Digital Competences) プラクティスの本発行 VeriSM のオーナーは 10 5

6 2018/1/23 VeriSM はテイラードアプローチ各々の組織固有の環境仕組管理手法等バラエティに富む実情から各々が固有のアプローチができる VeriSM の基本概念の基本概念全ての組織は組織が持てるあらゆるケイパビリティを活用して製品やサービスを通して価値を提供しなければならない情報システム人事営業マーケティング等はすべて組織の持つケイパビリティの一部である 6

7 2018/1/23 VeriSM の基本概念概念リーンの概念が全てのプロセスに渡って適用定義 SIAMの追加制作アジャイル制作提供反応のサイクルを回すのは DevOps DevOps2.1はこの基本プロセスである定義制作提供反応の循環型 PDCAサイクルの仕組みのフレームワークであり全てのプロセスにTOYOTAway リーンの概念が適用されている顧客の要望マネジメントメッシュ新しい概念ガバナンス企業統治サービスマネジメントの原則サービスカルチャー定義環境リソース管理手法新しいテクノノロジーの４要素を効果的効率的に組み合わせて基本プロセスを実行するためのマトリックスな管理制作マネジメントメッシュ提供顧客検証評価改善 ( ) 反応時間軸サイクルの同期を取る VeriSM の構成要素１ガバナンス (Governance) 基本は透明性(Transparency) 説明責任(Accountability) ビジョン戦略企業文化機敏に反応(Responsiveness) 効果的効率的(Effectiveness and Efficiency) 公平非排他的(Equitable and inclusive) 行動指針誰でも参加(Participatory) 持続可能(Sustainability) サービスマネジメントの原則サービスとは消費者お客様の明らかになった要望を満たすこと ITSMが開発し成熟させてきたサービスマネジメントの概念や手法の活用 BSM(Business Service Management) ESM(Enterprise Service Management) 方針展開全ての製品プロダクトとサービスに適用されるコンプライアンス 14 7

8 VeriSM の構成要素 2 マネジメントメッシュ VeriSM の特的な概念目的 : チームがリソースや管理手法ビジネス環境最新の IT 技術を駆使して製品 ( プロダクト ) やサービスに柔軟性を維持する VeriSM は柔軟性を維持するための多くのフレームワーク標準手法管理原則思想 ( 考え方 ) の活用と管理の方法論を提供マネジメントメッシュには 1 リソース 2 ビジネス環境 3 各種管理手法 4 革新的なテクノロジーが含まれる 15 マネジメントメッシュ ( 例 ) リソース人 ( 人工 ) 予算期間知識経験コンテナー企業文化ビジネス環境競合状況 IoT AI 革新的なテクノロジー法規制ブロックチェーンプロセスビジネスモデル SIAM COBIT CMMI IT4IT ISO/IEC20000 各種管理手法 16 8

9 VeriSM の構成要素 3 定義 : プロセスでの活動やプロダクトやサービスの設計関連する結果 ( 成果物 ) を明確に定義するこのステージではガバナンスやサービスマネジメントの原則が考慮されているかの確認も行われる主な活動 : 消費者のニーズ要求される成果物ソリューションサービスブループリントステアリングコミッティーによるビジネスケースの承認 & 同意要求の収集整理と技術的検討構成要素のパフォーマンス仕様調達方法テスト仕様計画立案サービスソリューションの設計調達方針制作条件パフォーマンスこのステージから以降反応のステージは事業は継続している間はサイクルが廻る詳細は DevOps2.0 でのプロセスに従う 17 VeriSM の構成要素制作 4 制作 : サービスブループリント ( 概略案 ) からサービスをコーディングテストそして移行準備までの作業の実施主な活動 : ビルドブループリントから実装するサービスを作成するテストテスト仕様に基づくテストの実行移行 & 検証リリース可能なモデルに整える移行計画の確認提供提供 : プロダクトやサービスはすでにパフォーマンスを含めて使用可能な状態になっている反応主な活動 : 保護 & 保全測定と保守改良 & カイゼン反応 : 消費者との定常的な相互交流ポリシーセキュリティーリスク継続性の確保最新のテクノロジー採用調達方法の変更社会秩序 & 世論主な活動 : 記録単一のPOCの管理体制 ( 要望課題 / 問題調達元からの変更 ) 管理課題の解決 18 9

10 プロセス DevOps2.1 ( エンタープライズ ) 概念図計画要求設計開発移行運用 E O L VeriSM Project Charter SIAM Require ment Definitio n User Story SLA SDP SAC ACDM Test Story Scrum Continuous Delivery SLA SDP SAC Operation Story LW- ITSM 手法 P D M 見える化されたプロジェクト管理 (TPS での大部屋方式 ) 計画から運用までの全体最適による整流化されたプロセスの構築トヨタの TPS の様な一個流しによるマイクロサービスの提供クラウド環境 ( コンテナー ) 開発環境テスト環境移行環境実行環境 ALM (Application Lifecycle Management) MSDPM:Micro-Services Delivery Process Management 道具立て 19 VeriSM 導入に当たっての注意事項組織の筋トレ ( 全部門にリーンの概念を導入 ) 職場の活性化 ( 自己組織化されたチーム / 職場 ) 動的なマネジメントシステムの構築軽量化された ITSM の基本概念と同様に MRI(Minimum Requirement Information) の定義ビジネスの全プロセス (End-to-End) の見える化プロセス間のサイクルの同期を取る必ず測定する 20 10

11 VeriSM の利用法誰が主要なユーザーか? サービスマスター (DevOps2.1) 事業の責任者 (LoB) ビジネスに携わるすべての関係者 DevOps に関与するすべての IT 関係者何のために必要か? 事業継続性の確保消費者 ( 顧客 ) の安心安全の確保企業のクレディビリティー向上 21 DevOps2.1 の事例 2009 年アジャイル開発を開始 2011 年秋アジャイル開発は成功裏に導入できたが課題噴出 : 開発工程はボトルネックでは無かった 2012 年 4 月ビジネスプロセスの全工程の見直しと整流化のプロジェクト開始 2013 年 10 月 DevOpsの導入 ( 全プロセスの見える化同期化と大部屋化実現 ) 事業規模が 2 年で 3 倍以上非製造業で初の大部屋の実現バリューストリームマップ xx 事業部ビジネスプロセスプロセスの同期化 ( 管理サイクル ) とタスク粒度の均一化一週間一時間企画営業管理デザイン開発移行運用コールセンタービジュアルボード 22 11

デジタル化のプロセスとプラクティス既存のビジネスまたは企画中のビジネスについてビジネスモデルジェネレーションを用いてビジネスモデルを整理するデータに基づきブレーンストーミングを行い SWOT 分析を行いビジネスモデルを見直す S W O T ビジネスモデルを完成させる MVP(Minimum Viable Product) を定義するデータサイエンティストの支援 MVP MVP の

12 デジタル化のプロセスとプラクティス既存のビジネスまたは企画中のビジネスについてビジネスモデルジェネレーションを用いてビジネスモデルを整理するデータに基づきブレーンストーミングを行い SWOT 分析を行いビジネスモデルを見直す S W O T ビジネスモデルを完成させる MVP(Minimum Viable Product) を定義するデータサイエンティストの支援 MVP MVP の Value Stream Map を作成する ( 理想的なプロセスの流れと各ステップ定義されたプロセスの各ステップ毎にユーザーストーリーにて要件を整理するユーザーストーリーでの創造する価値と所要時間 ) As a Role ( 役割 ) I can ( 機能 ) Which I need ( 要件条件 ) To ( ビジネス価値 ) プロセスへ続く 23 デジタル化のプロセスとプラクティス EXIN DevOps Professional VeriSM Foundation 認定同等の知識経験サービスマスター ( 総責任者 ) の決定 EXIN DevOps Master 認定同等の知識経験プロセスマスターの決定 DevOps チームの編成 DevOps エンジニアリライアビリティーエジニアゲートキーパー開発チーム運用チーム他必要に応じてスペシャリストビジョン狙い期待効果サービスマネジメント原則 (VeriSM) サービスインの時期リソースの確定調達リスク (SIAM) EOL 条件サービス提供の環境 ( 実行環境 ) 大部屋の設置 (Management Mesh の設定 ) プロジェクト憲章の制定 ( プロジェクトの企画 ) 24 12

13 プロセス DevOps2.1 ( エンタープライズ ) 概念図計画要求設計開発移行運用 E O L VeriSM Project Charter SIAM Require ment Definitio n User Story SLA SDP SAC ACDM Test Story Scrum Continuous Delivery SLA SDP SAC Operation Story LW- ITSM 手法見える化されたプロジェクト管理 (TPS での大部屋方式 ) クラウド環境 ( コンテナー ) P D M 開発環境テスト環境. 移行環境 ALM (Application Lifecycle Management) MSDPM:Micro-Services Delivery Process Management 実行環境道具立て 25 DevOps 2.1 とは DevOps 1.0 DevOps 2.1 カバーする領域開発からデプロイリリース迄ビジネス企画から運用 EOL 迄主な着目点頻繁なリリーススピード SoE(Web) が主体素早いリリース事業の継続性 SoE, SoR 双方適用する概念手法 Process アジャイル開発継続的インテグレーション継続的デリバリーリーンの考え方企画要求設計開発 DevOps 1.0 規律あるアジャイル開発継続的インテグレーション継続的デリバリー軽量化した IT サービスマネジメント ISO20000 ALM TPS の考え方 SIAM, VeriSM との結合デプロイ運用 E O L DevOps

プロセスの流れに基づく設計 (SPDD) 対象ビジネスプロセスのバリューストリームマップユーザーストーユーザーストーリーユーザーストーリーユーザーストーリーリーユーザーストーリー MoSCoW 分析 B A O 分解オプションプロセス Could オルタナティブプロセスボディープロセス Must Should プロセスフロー業務フロー 27 業務プロセスで設計 & 開発企画

(Body) ユーザーストーリー PBI( プロダクトバックログアイテム ) 分類オルタナティブプロセス (Alternative) オルタナティブプロセスユーザーストーリー (Alternative) オルタナティブプロセスユーザーストーリー (Alternative) ユーザーストーリー PBI( プロダクトバックログアイテム ) オプションプロセス (Option) オプション

14 プロセスの流れに基づく設計 (SPDD) 対象ビジネスプロセスのバリューストリームマップユーザーストーユーザーストーリーユーザーストーリーユーザーストーリーリーユーザーストーリー MoSCoW 分析 B A O 分解オプションプロセス Could オルタナティブプロセスボディープロセス Must Should プロセスフロー業務フロー 27 業務プロセスで設計 & 開発企画要求分析設計構築テスト運用観点業務の Value Stream Map A 価値 A ユーザーストーリー A B 価値 B 分解 C 価値 C ACDM による分析業務流れ PBL( プロダクトバックログリスト ) PBI( プロダクトバックログアイテム ) ボディープロセス (Body) ボディープロセスユーザーストーリー (Body) ボディープロセスユーザーストーリー (Body) ユーザーストーリー PBI( プロダクトバックログアイテム ) 分類オルタナティブプロセス (Alternative) オルタナティブプロセスユーザーストーリー (Alternative) オルタナティブプロセスユーザーストーリー (Alternative) ユーザーストーリー PBI( プロダクトバックログアイテム ) オプションプロセス (Option) オプションプロセスユーザーストーリー (Option) オプションプロセスユーザーストーリー (Option) ユーザーストーリーつのバックログ毎に開発運までタスク分割 e タスクボード To Do On Going Done c d h コミットステージデプロイメントパイプライン b g ユーザー受け入れテストステージ a f 手動テストステージキャパシティテストステージ EOL ボディープロセス (Body): 業種を問わず共通している基本プロセスオルタナティブプロセス (Alternative): 業種特性に影響を受けるプロセスオプションプロセス (Option): 企業の商慣習や慣行に影響を受けるプロセス一個流し流水化 ACDMにより品質要件非機能要件等の制約条件を見つける 28 イテレーティブ繰り返し 14

サービスバックログサービスマスタープロセスマスターイテレーション大部屋バリューストリームマップ見える化ボード類ディプロメントパイプラインサービスバックログタスクボードタスクボードタスクボードサービスバックログタスクボードスクラムチームアジャイルチーム ( スクラム )

ゲートキーパー運用チーム運用週日単位タスクボードアジャイルチーム ( スクラム ) 計画から運用までの全体最適による流水化されたプロセスの構築 29 軽量化された IT サービスマネジメント (LW-ITSM) エピック目的ユースケース MRI(Minimum Required

) BC( ビジネス制約 ) 理解仮説テストストーリー 1 ( テスト環境を含む ) 理解仮説評価要求のリファクタリングオペレーションストーリー 1 ( 運用シナリオ ) 役割考慮点理由ユーザーストーリー n PBA SLR SLA SAC OLA 工程 & 工法選択

作業手順完了基準共通部品フレームワーククラスコード( オブジェクト ) テスト環境設定手順テストデータテスト結果合否判定 SDP SLP リリース時期範囲の決定 ( 準備 ) リリース方法判定 ( 見直し ) 手順決定 SAC リリース情報時期方法範囲 ( 組織機能

15 サービスバックログサービスマスタープロセスマスターイテレーション大部屋バリューストリームマップ見える化ボード類ディプロメントパイプラインサービスバックログタスクボードタスクボードタスクボードサービスバックログタスクボードスクラムチームアジャイルチーム ( スクラム ) アジャイルチーム ( スクラム ) アジャイルチーム ( スクラム ) アジャイルチーム ( スクラム ) デプロイメントバックログタスクボード一個流しのフローデプロイメントパイプライン DevOps エンジニアオペレーションバックログタスクボードリライアビリティーエンジニアゲートキーパー運用チーム運用週日単位タスクボードアジャイルチーム ( スクラム ) 計画から運用までの全体最適による流水化されたプロセスの構築 29 軽量化された IT サービスマネジメント (LW-ITSM) エピック目的ユースケース MRI(Minimum Required Information) を決める事が大事ユーザーストーリー 1 ユーザーストーリー 2 役割 (Role) 機能 (I can ) 測定基準 (Which I need ) ビジネス価値 (To) ペルソナ ( ユーザー像 ) RF( 主な機能 ) RQ( 品質要件 ) TC( 技術制約 ) BC( ビジネス制約 ) 理解仮説テストストーリー 1 ( テスト環境を含む ) 理解仮説評価要求のリファクタリングオペレーションストーリー 1 ( 運用シナリオ ) 役割考慮点理由ユーザーストーリー n PBA SLR SLA SAC OLA 工程 & 工法選択開発プロセス定義ワークアイテム作業タスクコード ( プログラム ) 開発手法 ( 手順 ) リリース方法時期システムテストの要領開発手法に応じたワークアイテム ( 生産計画 ) 開発全体のプロセス完了基準時期タスク粒度を意識した作業タスクの定義 ( 作業指示書 ) 作業手順完了基準共通部品フレームワーククラスコード( オブジェクト ) テスト環境設定手順テストデータテスト結果合否判定 SDP SLP リリース時期範囲の決定 ( 準備 ) リリース方法判定 ( 見直し ) 手順決定 SAC リリース情報時期方法範囲 ( 組織機能 ) 対象プログラム稼働環境 System KPT System 仕様へのF/B 運用情報バグ情報( 時期内容積算量 ) フィックス情報( 時期内容種類 ) 稼働環境運用業務結びつけ OperationKPT 運用自身へのF/B 各作業現場では正しく作業を行うために 30 それなりの情報が創出されている 15

ビジョン上位方針組織の存在価値 ) チームの生産性を阻害する要件を全て排除する方針指示にはすべて明確なビジネス価値に基づく優先順位付けを行い常にこの優先順位を更新管理する見える化自工程完結改善 ( ムダを見つける目 ) 現地現物現状否定 ( 常に常識慣習に疑念の目を向ける ) プロセスの流れ 31 DevOps2.

16 役割と責務チーム管理者 ( マネージャー ) 職場を活性化させる全ての行動の立案と実行お客様の要望する品質納期価格での提供 ( お客様が満足してすぐに代金を支払っていただけるか?) 自身の仕事の価値の向上 ( 常に現状に満足せず日々改善の模索 ) 新技術手法の目利き ( 評価 ) ツール類の企画作成部下の職場の活性化を促す環境を整える職場を活性化させる気付きを作る全体プロセスの流水化 ( 澱みなく仕事が流れる ) 流水化の為の他部門への提言 ( 組織間のサイロの破壊 ) 明確な方針の展開 ( ビジョン上位方針組織の存在価値 ) チームの生産性を阻害する要件を全て排除する方針指示にはすべて明確なビジネス価値に基づく優先順位付けを行い常にこの優先順位を更新管理する見える化自工程完結改善 ( ムダを見つける目 ) 現地現物現状否定 ( 常に常識慣習に疑念の目を向ける ) プロセスの流れ 31 DevOps2.1 に必要な知識体系 Process 企画要求設計開発デプロイ運用 E O L SIAM 規律あるアジャイル継続的デリバリー軽量化した ITSM VeriSM タスク粒度完了基準継続的インテグレーションイテレーション ( タイムボックス ) プロセスの自動化デプロイのパターンテストの自動化 TPI NEXT TPS / リーン事業の継続性 ISO ジャストインタイムと自働化行灯自工程完結一個流しのフロー ( 平準化 ) 学習する組織 ( 反省カイゼン ) 32 16

17 TOYOTA-way(TPS) から移入される思想手法 DevOps 2.1 ジャストインタイム大部屋後工程引き取り現地現物規律あるアジャイル開発 ( 開発チーム ) 自工程完結職場の活性化仕事の分析振り返り ( 反省 ) タクトタイムデプロイメントパイプライン自働化一個流し ( 流水化 ) 運用チーム先行改善平準化自工程完結仕事の分析職場の活性化振り返り ( 反省 ) 33 価値観スピード働き方時間の使い方計画プロジェクトリスク役割進捗管理見える化評価基準要求設計開発コード品質ドキュメントデプロイ & リリース運用運用管理リーダーシップ計画重視遅い仕事はまとめた方が効率が良い残業を認める仕事の目的を達するまでの時間計画重視全期間にわたる計画立案 ( 計画通りにコトは運ぶ ) しっかりと計画を立て理論的に進めるプロジェクト後半に増大専門家 ( 分業化 ) 管理指標作業が終わらないと見えない計画に対して管理可能 100% 定義可能機能中心設計基本は個人 ( 専門家 ) 属人化する管理強化 ( 当たり前品質 ) 多種多様管理基準半自動分権独立 ITIL 統率型 ( 指示 & 命令 ) 何を変えるべきか? ウォーターフォールを中心とした従来の方式アジャイル DevOps の新しい方式リソース重視適応性重視早い仕事は一つづつこなした方が効率が良い残業を認めない ( 定時間労働 ) 区切られた時間内で仕事の目的を達成タイムボックス計画作り重視 ( 朝令暮改 ) 当面 1ヶ月は詳細に後は粗い計画 ( 計画通りにはコトは運ばない ) 反復的 ( イタラティブ ) に進めるフィードバックが重要プロジェクト前半に集中多能工化 (T 型人材 )) 現地現物管理 ( 働くプログラムのみ ) ほぼ何時でも見える化 ( 透明性 ) ビジネス価値 ( ビジネスの成果 ) 管理不能定義不能 ( 標的は動く ) プロセス中心設計チームの連帯責任属人性の排除向上可能性あり ( 魅力的品質 ) MRI ( 最低必要限 ) 使用目的の明確化自動化 ( デプロイメントパイプライン ) オペレーションの一体化軽量化したITサービス管理 &ISO20000 サーバントリーダーシップ ( ファシリテーション ) 34 17

18 EXIN のサイトから入手できますホワイトペーパーエンタープライズ DevOps DevOps によるビジネスを支援する IT サービス DevOps の為の軽量化された IT サービスマネジメントメールマガジン連載 ; 全体最適への DevOps(Agile, TPI, ITIL/ITSM) EXINでは計 10 回システムの全体最適をテーマにメルマガを6 月 17 日より配信第 1 回 : ITIL 側から観たAgileの不安第 2 回 : 計画企画段階のAgileとITIL 第 3 回 : イテレーション期間のITILから診た評価第 4 回 : テストにおける当たり前品質とSAC 第 5 回 : リリース時の評価とSDPとSLP 第 6 回 : 運用へのScrumの適用第 7 回 : 研究と改善 ( 品質は現場でつくられる )( 運用状況によるフィールドバック ) 第 8 回 : 全体最適へ (DevOps) 軽量化したITSM (1) 全体像第 9 回 : 全体最適へ (DevOps) 軽量化したITSM (2) 適応させるロードマップ第 10 回 : 全体最適へ (DevOps) 軽量化したITSM (3) 理想となる姿とそれに向けたチェック項目バーンアップチャート 35 日経コンピュータ連載コラム総合タイトル : 前編現場を元気にするチーム運営術年 4 月 13 日元気が無い現場に四つのサインあいさつが元気を取り戻す第一歩年 4 月 27 日コミュニケーションが取れない組織他人をどれだけ知っているのか年 5 月 11 日残業が減らない組織属人的な仕事を無くしているか年 5 月 25 日多忙で夏休みを取れない職場改善活動の停滞乗り越え取得率向上年 6 月 8 日助け合いの無いシステム部門心のマネジメントが改善のカギ年 6 月 22 日アジャイル開発でチームを元気に初挑戦でも成功カギは見える化年 7 月 6 日発注者の信頼をどう得るのかアジャイル開発成功のカギ年 7 月 20 日チームの透明性はアナログで高める自らを律するのが成功の秘訣年 8 月 3 日暗すぎるウォーターフォールの現場やる気引き出す心のマネジメントを年 8 月 17 日進捗が90% から先に進まない 1 時間の作業に分割しているか総合タイトル : 後編現場を元気にする DevOps 年 9 月 14 日今こそ大量生産時代の常識に決別トヨタ由来の方法論で元気になろう年 9 月 28 日自ら改善を続けるチームに変える働き方改革への第一歩年 10 月 12 日人を大切にするのが強い企業仕事のやり方を変えて近づこう年 10 月 26 日サイロ現場を3 段階で変革個別最適では幸せにはなれない年 11 月 9 日アジャイル開発の品質向上策 7つの視点で作業の様子を観察年 11 月 23 日伝達ゲームは開発失敗の元凶業務プロセスの観点を貫こう年 12 月 7 日ビジネスの速度が3 倍に全体最適に変革する3ステップ年 12 月 21 日ウォーターフォールは時流に合わないまずは安全管理と可視化に着手年 1 月 4 日チームを育てるならアジャイルをマネジャーは支援役に徹する年 1 月 18 日ツールだけでは元気は出ない DevOps 2.0に必要な7つの役割 36 18

TOYOTA way 12の原則

TOYOTA way 12の原則デジタルトランスフォーメーションの基本は TMS ビジネスとITのかかわり方の変遷ビジネス 1970 モノ中心のビジネスモノ製品が主役バッチ処理システムビジネスの事後事務処理 WF 1990 モノ中心のビジネスモノ製品が主役オンライン処理システムビジネスと同時並行での事務処理 WF モノのビジネスとサービスのビジネス (モノが主役でサービスはおまけ) インターネットウェブシステム