PROJECT TO PRODUCT (DevLOVE)

191 Views

December 08, 23

スライド概要

profile-image

UXデザインとアジャイルをつなぐ人。

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

ダウンロード

関連スライド

各ページのテキスト
1.

PROJECT TO PRODUCT ビジネスとテクノロジーを 繋ぐFlow Framework Takahiro Ito@Slalom

2.

自己紹介 • Slalom株式会社 • アジャイルコーチ

3.

翻訳のきっかけ • アジャイルを知った • SAFeを知った • GlobalSummit • その先で出会った

4.

みなさん、 AIを仕事に活かしていますか

5.

みなさん、 ソフトウェアを 仕事に活かしていますか

6.

1771 1793–1801 運河狂時代 (英国) 産業革命 1829 蒸気と鉄道の時代 1848–50 ビクトリア朝の繁栄 鉄道狂時代 (英国) 1875 1890–95 ロンドン資本によるグローバル市場 インフラストラクチャの構築 鉄と重工業の時代 1908 石油と大量生産の時代 ベル・エポック(ヨーロッパ) プログレッシブ時代(米国) 1929–43 戦後 黄金時代 狂騒の20年代 2000–? 1971 ソフトウェアと デジタルの時代 大英帝国の発展 ドットコムおよびインターネットマニア グローバアルファイナンスと住宅バブル 導入期 ? ターニングポイント 展開期

7.

導入期 展開期 石油および大量生産の 時代 ターニング テクノロジーの浸透度 ポイント 実権を握る 生産資本 成熟 相乗効果 熱狂 ソフトウェアと デジタルの時代 割り込み ? 実権を握る 金融資本 2001–? 時間

8.

ソフトウェアの時代における 古い生産方式とは何で、 新たな生産方式とは何か。

9.

アジャイルが1つ。

10.

どれだけ開発チームを教育し、 どれだけアジャイルにしたとして、 ターニングポイントは越えられない。

11.

Nokiaの例 • アジャイルの重要性を理解していた • ソフトウェアの重要性も理解していた • 有名なアジャイルコンサルタントを雇っていた • 開発チームにアジャイル教育を施していた • Nokiaテスト

12.

LargeBankの例 • 経営陣は変革の重要性を理解していた • 3度目のDX、今度はDevOpsも含めていた • 2年がかりのDXプロジェクトとして10億ドル投資していた • 大幅なコストカットが目標として設定され期待されていた • コストはカットできたがデリバリー能力が同時に落ちた

13.

プロキシーメトリクス • 代理指標 • アウトカムに直結しない指標 • 何人にアジャイルトレーニングをしたか • プロジェクトのQCDを守ったか

14.

バリューストリームのサイロ化 経営 戦略 投資 企画 チーム 組成 要求 定義 要件 定義 セキュ リティ 診断 結合 試験 単体 試験 実装 詳細 設計 基本 設計 ユーザ 受⼊ テスト 運⽤ テスト 本番環境 デプロイ 社内 周知 社外 周知 運⽤ 開始

15.

3つの教訓 1. 局所最適の落とし穴を避けるには、エンドツーエンドのバリ ューストリームに注目すること。 2. コストだけで改革を管理すると、生産性が低下すること。 3. エンジニアリング、ITソフトウェアとビジネスは繋がってい なければいけないということ。

16.

では、 どのメトリクスを追うべきか

17.

リーンがヒントになる。

18.

リーンの原則 • プロダクトの価値を特定する • プロダクトのバリューストリームをマッピングする • プロダクトに沿ったフローが流れるようにする • フロー内にプルシステムを確立する • 継続的に改善する

19.

BMW Production Plant Leipzig https://www.youtube.com/watch?v=qDrm0hR324k

20.

BMW Production Plant Leipzig https://www.youtube.com/watch?v=qDrm0hR324k

21.

Google Map https://www.google.com/maps/search/BMW+Werk+Leipzig/@51.4054779,12.4382338,2079m/

22.

ただし、自動車製造とソフト ウェア開発との違いを理解す る必要がある

23.

車の製造 エンタープライズIT • 統合された製造ライン • 分断されたツールチェーン • プロダクトとしてマネジメント • プロジェクトとしてマネジメント • フローに基づいた設計 • テクノロジー層ごとの設計 • E2Eの最適化 • サイロ毎の最適化 • ビジネス成果の計測 • プロキシーメトリクスでの計測

24.

ビジネスバリューフローの違い BMWでの車の製造 エンタープライズIT • 「駆け抜ける歓び」を提供する高品質な車 • 成功と歓びをもたらす新たな機能 • 年単位の設計、70秒毎のデリバリー • 設計とデリバリーが日単位 • クリエイティブと製造のプロセスの分離 • クリエイティブと製造のプロセスの統合 • 単一製造ラインのフロー • バリューストリームネットワークのフロー

26.

ビジネス成果&メトリクス フローメトリック ビジネス成果 フローベロシティ バリュー フロー効率 コスト フロータイム 品質 フロー負荷 幸福度 フロー配分 フィーチャー 不具合 リスク 負債

27.

ビジネス成果 • バリュー: プロダクトがユーザーにもたらす成果 • コスト: バリューストリーム全体でかかるコスト • 品質: プロダクトの内部&外部品質 • 幸福度: バリューストリームに関わる人の幸福度

28.

フローメトリック • フローベロシティ • フロー効率 • フロータイム • フロー負荷

29.

フロー効率

30.

フロータイム、フロー負荷、フローベロ シティ

31.

フローアイテム(フロー項目) • フィーチャー • 不具合 • リスク • 負債 MECEな関係 これらの割合がフロー配分 100% フィーチャー 不具合 ディフェクト 80% リスク 負債 60% 40% 20% 0 01 02 03 04 05 06 07 08 09 10 11 12

32.

ネットワークとモデル

33.

フローフレームワークを 実践&実現するには

34.

フローフレームワーク実現作戦 • ボトムアップなら小さく始める • プロダクトのバリューストリームの可視化 • ビジネス成果の設定と可視化(価値、コスト、品質、幸福度) • フローメトリクスの可視化 • フローアイテムの分類とフロー配分の可視化

35.

フローフレームワークの 詳細の理解より大事なこと

36.

ビジネスとテクノロジの共通言語を持つ

37.

共通言語としてのフローフレームワーク

38.

共通言語としての プロダクトマネジメント

40.

壊れたサイロから バリューストリームネットワークへ プロジェクト マネージャー 開発者 テスター 運用 ビジネス成果 ビジネスオブジェクティブ ビジネス アナリスト

44.

Project to Product: How Value Stream Networks Will Transform IT & Business - Mik Kersten https://www.youtube.com/watch?v=E5VP3ioSRU8

45.

私たちは何をすべきか • ビジネスリーダー • 製品ポートフォリオとバリューストリームメトリクスの追跡 • 戦略に合うようフロー配分を割り当てる権限をデリバリーチームに与える • プロダクトゴールの達成にはE2Eの視点が必要なことを理解する • 開発者 • ツールネットワークを接続し、バリューストリームネットワークを構築する • バリューストリームアーキテクチャを定義し、製品モデルにマッピングする • フローメトリクスを使用して、ボトルネック、依存関係、機会を特定する

46.

越境のために、 フローフレームワークを 取り入れてみませんか。

47.

ご清聴 ありがとうございました Takahiro Ito@Slalom