【17-d-3】リーンスタートアップとスマートなエンジニアリングの葛藤...

[17-D-3]リーンスタートアップとスマートなエンジニアリングの葛藤Hashtag: #devsumiD

【17-D-3】リーンスタートアップとスマートな

エンジニアリングの葛藤

#devsumiDグロースエクスパートナーズ株式会社

関満徳


撮影可録音可

Copyright© Growth xPartners, Inc. All rights reserved. 1


今日お話したいこと• 「リーンスタートアップ」と「スマートなエンジニアリング」の間に生じるズレや葛藤

• 企画サイドや開発サイドがこの悩みに対しどのように動くべきか



アジェンダ• 今、起きていること• ズレや葛藤について考える• どう動くとよさそうか• まとめ



今、起きていること



「作る」から「使い続ける」へ• モノからコトへのパラダイムシフト

–幅広い業界で市場は成熟し、すでに必要なモノはほとんど手に入った

–人々の関心はモノの所有欲を満たすことから、経験、思い出、人間関係、サービスなどの目に見えない価値であるコトに移行してきている




–モノを作る

–作ったモノを使い続けてコトを得る




–一度作ったモノは、作ったらおしまい

–目に見えない価値であるコトは変わっていくので、追随していく必要がある




–一度作ったモノは、成長しない

–一度作ったモノは、リリース後も成長し続ける


リリース1回目↓

リリースn回目↓

成長度

時間

成長しない

成長し続ける



–一度作ってリリースしたら、改修されない

–リリース後も改修し続ける


リリース1回目↓

リリースn回目↓

成長度

改修されない

改修し続ける

時間



–モノの提供＝数年間に一度のリリースの時代

–コトの提供＝数ヶ月/数週間/数日に1回、または1日数回のリリースの時代へ


時間

時間

リリース

リリース



–単一プロジェクトのためのプロダクトマネジメント単一プロジェクトプロダクトマネジメント

–複数プロジェクトに跨がるプロダクトマネジメント複数プロジェクトプロダクトマネジメント


…



–単一リリースのためのアーキテクチャ単一リリースアーキテクチャ

–複数リリース毎に改善するアーキテクチャ複数リリース改善するアーキテクチャ


…


• 日本的プロダクトオーナーの現状

スクラムマスター

開発チーム開発日本的プロダクトオーナー

経営層情シス

営業

広報ｺｰﾙｾﾝﾀｰ

現場作業者管理

部門

法務財務

顧客

意思決定促進

現場調整

Dev/Ops視点

ビジネス視点

意思決定者

現場

「作る」から「使い続ける」へ


日本的プロダクトオーナーの苦労のポイント日本的プロダクトオーナーは、スクラムで定義されるプロダクトオーナーより、より多く、複数の視点の結節点で調整力を求められる場面が多い。

プロダクトオーナーの現状プロダクトオーナーは、様々な部署から任命されることが多く、実は必要なスキルや経験と案件がマッチしていないことも多い。


モノとコトの実現プロセス


なぜやるべきか

土台づくり

使い続けさせる作って

仮説検証

作る計画を立てて

作る計画をまわす

作らずに仮説検証

作る

WHY

HOW

アイディア

モノコトデータ計測

する

学習する

構築する

アイディア


する

学習する

構築する

WHAT





土台づくり


仮説検証




作る

WHY

HOW

アイディア


する

学習する

構築する

アイディア


する

学習する

構築する

WHAT

思い込みにより発生する各種ムダを省くためにリーンにやる

ムダなモノを省き必要なモノを素早く

作り続けるエンジニアリング

モノを支えるアーキテクチャ





土台づくり


仮説検証




作る

WHY

HOW

アイディア


する

学習する

構築する

アイディア


する

学習する

構築する

WHATやりたいコト

用意しなければならないモノ






土台づくり


仮説検証




作る

WHY

HOW

アイディア


する

学習する

構築する

アイディア


する

学習する

構築する




葛藤葛藤


ズレや葛藤について考える



ズレや葛藤について考える• アーキテクチャから見た葛藤• リーンから見た葛藤



アーキテクチャ設計から見た葛藤



土台づくり


仮説検証




作る

WHY

HOW

アイディア


する

学習する

構築する

アイディア


する

学習する

構築する



用意しなければならないモノ葛藤


アーキテクチャ設計から見た葛藤• アーキテクチャ設計とは

–システムの構造と振る舞いを定義すること»構造システムの分け方と組み方»振る舞い稼働しているシステムが利用できる状態で

外部に対して行うこと


ITサービス

機能

非機能

静的構造

動的構造

構造のパターン振る舞い


アーキテクチャ設計から見た葛藤• 構造と振る舞いの関係

»静的構造時間軸にとらわれない要素の配置と関係性»動的構造時間軸の中で現れる要素の配置と関係性»機能インプットに対するアウトプット»非機能振る舞いの質


ITサービス

機能

非機能

静的構造

動的構造

構造のパターン振る舞い


アーキテクチャ設計から見た葛藤• 構造と振る舞いの関係


振る舞いの初期要求

システム開発の流れ

振る舞い

振る舞い

システムの設計

システムの実装

システムのテスト

アーキテクチャの設計構造構造構造定義定義

参照参照

定義実現

確認

利用

評価


アーキテクチャ設計から見た葛藤• アーキテクチャ設計のジレンマ

–本来はシステムを作り始める前にアーキテクチャを定義すべき

–その時点で得られる要求が正しいかわからない



システム開発の流れ

振る舞い

振る舞い

システムの設計

システムの実装

アーキテクチャの設計構造構造構造定義定義

参照参照

定義実現

利用


アーキテクチャ設計から見た葛藤• アーキテクチャ設計のジレンマ

–要求が定まらなければ構造が決まらない–要求を定めるためには作らなければならない–作るためには構造が決まっていないといけない



構造振る舞い構造が決まっていないと作れない

振る舞いを見ないと要求がわからない

要求が曖昧では決定できない


リーンから見た葛藤



土台づくり


仮説検証




作る

WHY

HOW

アイディア


する

学習する

構築する

アイディア


する

学習する

構築する




葛藤


プロダクトLog

リーンから見た葛藤


仮説スプリント計画

ふりかえり

スプリント

スプリントバックログ

デイリースクラム

プロダクトバックログ

評価用成果物

仮説検討

価値検討仕様検討

オポチュニティバックログ

価値評価

リーンキャンバス

.....::::::::::

::::::::::

::::::::::.....

::::::::::

::::::::::

::::::::::.....

::::::::::

::::::::::

::::::::::

ペルソナ

カスタマージャーニーマップ

インセプションデッキ

サービスブループリント

アーキテクチャ設計

アーキテクチャビジョン& デザイン設計

テクニカルソリューション技術

検討

スプリントレビュー

価値計測出荷

プロダクト利用

サイクルのタイミングがあわない

スプリントのサイクルに乗らないタスクはどうすればいいのか


どう動くとよさそうか



どう動くとよさそうか• アーキテクチャ設計でできること• リーンでできること



アーキテクチャ設計でできること



土台づくり


仮説検証




作る

WHY

HOW

アイディア


する

学習する

構築する

アイディア


する

学習する

構築する



用意しなければならないモノ葛藤


アーキテクチャ設計でできること• ジレンマに対するアーキテクチャ戦略

–戦略1 変化に対応出来る構造の導入–戦略2 構造パターン追加への対応–戦略3 犠牲的な構造パターンの導入



アーキテクチャ設計でできること• 戦略1 変化に対応出来る構造の導入

–要求の変化を可能な限り予測–変化に対応出来る構造にしておく


構造

機能A 機能B 機能C

構造

機能A

変化を予測し、変化に対応出来る作りにする

変化に合わせて機能を追加していく


アーキテクチャ設計でできること• 戦略2 構造パターン追加への対応

–構造パターンの追加に対応できるようにしておく


構造1


構造1

機能A

機能に適した構造を用意するが、構造の拡張性を残す

変化に合わせて機能を追加していく

構造2


アーキテクチャ設計でできること• 戦略3 犠牲的な構造パターンの導入

–意図的に簡易的な構造パターンを導入–本当に必要になったタイミングで作り直すことを前提


構造2


構造1

機能A

機能に適した構造を用意し、最小限な機能にしていく

変化に合わせて機能と構造を追加していく

機能A

構造1




メリットデメリット【戦略1】

変化に対応出来る構造の導入

変化に効率的に対応出来る

変化が発生しないと保守的に大きな影響が出る

【戦略2】構造パターン追加

への対応

変化が発生した時点で適切な構造を導入できる

使われなくなった構造パターンが技術的負債となる

【戦略3】犠牲的な構造パターンの導入

もっと効率的に実装できる

早く限界が来てしまうと作り直す無駄が出る


リーンでできること



土台づくり


仮説検証




作る

WHY

HOW

アイディア


する

学習する

構築する

アイディア


する

学習する

構築する




葛藤


リーンでできること• 管理するものを分類する• リズムを合わせる



プロダクトLog




ふりかえり

スプリント




評価用成果物

仮説検討



価値評価


.....::::::::::

::::::::::

::::::::::.....

::::::::::

::::::::::

::::::::::.....

::::::::::

::::::::::

::::::::::

ペルソナ







検討


ToDo Ready In Progress Done Feedbackかんばん

価値計測出荷



プロダクトLog




ふりかえり

スプリント




評価用成果物

仮説検討



価値評価


.....::::::::::

::::::::::

::::::::::.....

::::::::::

::::::::::

::::::::::.....

::::::::::

::::::::::

::::::::::

ペルソナ







検討



価値計測出荷


• アイディア出し中• 問題が本当にあるか確認中• プロトタイプによる検証中で、ユーザーストーリーが確定していないものは、「オポテュニティバックログ」で管理

現在のスプリントで、開発チームが着手中のタスクは「スプリントバックログ」で管理

スプリントのサイクルに入らないタスクは「かんばん」で管理

スプリントのサイクルに入るものは、「プロダクトバックログ」で管理


プロダクトLog




ふりかえり

スプリント




評価用成果物

仮説検討



価値評価


.....::::::::::

::::::::::

::::::::::.....

::::::::::

::::::::::

::::::::::.....

::::::::::

::::::::::

::::::::::

ペルソナ







検討



価値計測出荷


次のスプリント計画前までに、• バックログ見直し• ユーザーストーリー見直し• ストーリーテスト作成• 価値・リスク観点での優先順位見直しを実施しておく


まとめ






土台づくり


仮説検証




作る

WHY

HOW

アイディア


する

学習する

構築する

アイディア


する

学習する

構築する

WHAT





土台づくり


仮説検証




作る

WHY

HOW

アイディア


する

学習する

構築する

アイディア


する

学習する

構築する

WHAT

思い込みにより発生する各種ムダを省くためにリーンにやる

ムダなモノを省き必要なモノを素早く

作り続けるエンジニアリング

モノを支えるアーキテクチャ





土台づくり


仮説検証




作る

WHY

HOW

アイディア


する

学習する

構築する

アイディア


する

学習する

構築する




葛藤葛藤


どう動くとよさそうか• アーキテクチャ設計でできること

–アーキテクチャ戦略を立てる

• リーンでできること–管理するものを分類する–リズムを合わせる





メリットデメリット【戦略1】

変化に対応出来る構造の導入

変化に効率的に対応出来る

変化が発生しないと保守的に大きな影響が出る

【戦略2】構造パターン追加

への対応

変化が発生した時点で適切な構造を導入できる

使われなくなった構造パターンが技術的負債となる

【戦略3】犠牲的な構造パターンの導入

もっと効率的に実装できる

早く限界が来てしまうと作り直す無駄が出る


プロダクトLog




ふりかえり

スプリント




評価用成果物

仮説検討



価値評価


.....::::::::::

::::::::::

::::::::::.....

::::::::::

::::::::::

::::::::::.....

::::::::::

::::::::::

::::::::::

ペルソナ







検討



価値計測出荷


• アイディア出し中• 問題が本当にあるか確認中• プロトタイプによる検証中で、ユーザーストーリーが確定していないものは、「オポテュニティバックログ」で管理

現在のスプリントで、開発チームが着手中のタスクは「スプリントバックログ」で管理

スプリントのサイクルに入らないタスクは「かんばん」で管理

スプリントのサイクルに入るものは、「プロダクトバックログ」で管理


プロダクトLog




ふりかえり

スプリント




評価用成果物

仮説検討



価値評価


.....::::::::::

::::::::::

::::::::::.....

::::::::::

::::::::::

::::::::::.....

::::::::::

::::::::::

::::::::::

ペルソナ







検討



価値計測出荷


スプリント計画の日程は、あらかじめ共有しておく。その上で、次のスプリント計画前までに、• バックログ見直し• ユーザーストーリー見直し• ストーリーテスト作成• 価値・リスク観点での優先順位見直しを実施しておくと、次のスプリントが終わったタイミングで企画側が確認可能になることを、企画側と共有。


お知らせ• アーキテクチャについてもう少し全体感が知りたいなら–Cloud First Architecture 設計ガイド

»第1章クラウドファーストの意味»第2章クラウド技術の構成»第3章クラウドファーストに至るまでの歴史»第4章エンタープライズとクラウドファースト»第5章アーキテクチャー設計ガイド»第6章クラウドファーストにおけるエンジニア

» https://www.amazon.co.jp/dp/4822237818


https://www.amazon.co.jp/dp/4822237818


【17-D-3】リーンスタートアップとスマートな

エンジニアリングの葛藤

#devsumiDグロースエクスパートナーズ株式会社

関満徳


ご清聴ありがとうございました！


コンタクト先 URLBlog http://fullvirtue.com/Twitter https://twitter.com/fullvirtueFacebook https://www.facebook.com/fullvirtueEmail [email protected]資料公開場所 http://slideshare.net/fullvirtue/

これまで登壇してきた資料はこちらで公開しています！是非ご覧ください！

関満徳せきみつのり

グロースエクスパートナーズ株式会社 ITアーキテクトMicrosoft MVP for Visual Studio and Development Technologies

ITサービス開発全般のコンサルティング、開発、運用を一括して手掛けながら、「顧客価値の創造」と「持続可能な仕組み創り」をテーマとしたアジャイル・プロダクトマネジメントのワークショップデザインを数多く実施。全国各地でファシリテーターとしても活躍。

http://fullvirtue.com/

https://twitter.com/fullvirtue

https://www.facebook.com/fullvirtue

http://slideshare.net/fullvirtue/

Copyright© Growth xPartners, Inc. All rights reserved.

CONFIDENTIAL 本文書は、グロースエクスパートナーズ株式会社が著作権その他の権利を有する営業秘密（含サプライヤー等第三者が権利を有するもの）です。

当社の許可なく複製し利用すること、また漏洩することは「著作権法」「不正競争防止法」によって禁じられております。本資料内の社名・製品名は各社の登録商標です。

【17-d-3】リーンスタートアップとスマートなエンジニアリングの葛藤...

Technology