デジタルビジネスの潮流とアジャイル開発〜ビジネスとエンジニアの協働チームづくり〜

1

株式会社永和システムマネジメント
株式会社チェンジビジョン
Scrum Inc, Japan
平鍋健児

平鍋健児
(株)永和システムマネジメント社⻑
(株)チェンジビジョンCTO(株)Scrum Inc. Japan 取締役
第⼆版

3

福井で受託開発を続けながら、アジャイル開発を推進し、国内外で、モチベーション中⼼チームづくり、アジャイル開発の普及に努める。ソフ
トウェアづくりの現場をより⽣産的に、協調的に、創造的に、そしてなにより、楽しく変えたいと考えている。アジャイルジャパン初代実⾏委員⻑。

本社／福井市

東京⽀社／神⽥◎●沖縄事務所／那覇市●5開発はすべてスクラム
共創・共育で利⽤するプラクティス
モブプログラミング●●●●

⼀つのPCとディスプレイ
同じ課題にみんなで⽴ち向かう
知識伝搬が早い
レビューも同時に⾏うことで効率的

スプリント（1〜4週間）ふりかえり● 毎週（スプリント毎）実施● ⾃分たちの課題を出し合い改善策を探る● チームワークを⽣み出す効果も6https://www.asf.esm.co.jp/remote-know-how

9なぜ、アジャイル?

ミッション・リスク分割型ビジネスとウォーターフォール型開発（従来型）
発注

市場分析

市場

ビジネス

納品

リリース
半年から３年
13IT

従来型の問題＝要求の劣化!"#$%機能%利用度

1@A使>
B4
C,使>
9D4;<=使>
9?45678使./0
1
9:4
•
14

全,使./01
234

Standish group study report in 2000 chaos reportミッション・リスク共有型ビジネスとAgile型開発
市場

ビジネスとITが⼀体になった「OneTeam」を作り、ミッションとリスクを共有する。
やってみて、結果から戦略を作りながら進む。

IT

15

⼀ヶ⽉以
内

市場
ビジネス

Lean Startup
IDEAS
素早く学習LEARN

AB テスト
顧客インタビュー
顧客開発
なぜなぜ5回、真因分析
顧客アドバイザリボード
仮説検証
プロダクト・オーナーの責任顧客タイプ分析
機能横断チーム
半自立チームスモークテスト

BUILD

DATA

素早く測定

CODE

MEASUREAB テスト
明確なプロダクトオーナ
継続的開発
ユーザビリティテスト
リアルタイムモニタ
顧客代表
16

素早くコード単体テスト
ユーザビリティテスト
継続的結合
漸進開発
オープンソース利用
クラウド
クラスタ免疫システム
JITスケーラビリティ
リファクタリングデベロパーサンドボックス

漏斗分析
コホート分析
ネットプロモータスコア
検索エンジンマーケティング
リアルタイムアラート
予測的モニタリング

アジャイルは3周⽬に⼊った!
クラウドの普及
IoT/SoE時代の到来
不確実さへの対応
リリーススピード重視

3rd Wave到来
組織変⾰の⼿法

2nd Wave
2010年当初
企業戦略

1st Wave
2000年当初
エンジニア主体
テクノロ
ジーに感度の⾼いソフ
トハウス

⼤⼿ITサー
ビス企業/
スタート
アップ

先進的
⼤⼿企業

⼀般的
⼤⼿企業

• シリコンバレー型のやり⽅を既存⼤企業が取り⼊れ始めた。
21

従来型
企画部⾨
開発部⾨

発注側
受託側

壮⼤な伝⾔ゲーム

発注（開発ベンダー）
発注

発注

下請ベンダー

下請
ベンダー

発注

下請
ベンダー

アジャイル開発
企画部⾨
参加
組織横断⼀体チーム
参加

開発部⾨

24

参加

開発
ベンダー

アジャイル開発(2)営業部⾨マーケティング部⾨企画部⾨Analysis
部⾨
UX
部⾨参加

参加

参加
組織横断⼀体チーム

参加

開発部⾨

25

参加

開発
ベンダー

品証部⾨

アジャイル開発とは何か?
スクラムとは何か?

プロセスとしてのAgile• 短いサイクルで、分析、設計、実装、テストを並列に⾏う• タイムボックス型、進化型開発

Waterfall

要求(スコープ)

Agile

要求(スコープ)

分析
設計
実装
時間

テスト
時間
Royce 1970

最後に動くものができる33

Beck 2000

動くものが徐々にできあがり、成⻑する

分割の仕⽅• 顧客に分かる機能で切る。
• 層で切らない。
• ビジネスの価値が分かる。
• やりがい、コミュニケーション"These days we do not program softwaremodule by module;
we program software feature by feature.“—Mary Poppendieck34

by Akiyahスクラムの流れ（イベントと作成物）

スクラムでの３つの責任

ゴール

作成物

37

開発者

スクラムのフレームワーク
分類

呼び名

説明

責任

プロダクトオーナー

何を開発するか決める⼈

開発者

実開発に携わる⼈々

スクラムマスター

全体をリード・⽀援する⼈

スプリント

開発の反復単位スプリントプランニング（計画づくり）

スプリント内で⾏う開発の計画をつくる
ミーティングデイリースクラム

毎⽇⾏われるミーティング

スプリントレビュー

スプリントの最後にステークホルダーを交えて⾏われる意⾒とフィードバック
ミーティング

スプリントレトロスペクティブ

スプリントの最後に⾏われる開発の改善
活動ミーティング

インクリメント

スプリント内で完成された製品の増加分（完成の定義に合致している）

プロダクトバックログ

順位づけられた製品の機能リスト（プロダクトゴールを含む）

スプリントバックログ

スプリント内で開発する機能リスト（スプリントゴールを含む）

イベント

（朝会）

（ふりかえり）

作成物（製品増分）（製品機能リスト）38（スプリント機能リスト）

アジャイルソフトウェア開発宣言

重要

私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。

いま重要!

プロセスやツール よりも 個人と対話を、包括的なドキュメント よりも 動くソフトウェアを、契約交渉 よりも 顧客との協調を、計画に従うこと よりも 変化への対応を、価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。
Kent Beck
James Grenning
Mike Beedle
Jim Highsmith
Arie van Bennekum
Andrew Hunt
Alistair Cockburn
Ron Jeffries
Ward Cunningham
Jon Kern
Martin Fowler
Brian Marick© 2001, 上記の著者たち

Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas

この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。

40

アジャイルのゴール

ビジネス価値、
顧客満⾜、市場創造アジャイルのレフトウィング

ソーシャルプラクティス

協働でゴールに向かう「チーム環境」

朝会
タスクかんばん
バーンダウンチャート
ふりかえり
…
その他
47

アジャイルのライトウィング

技術プラクティス

⾼速に⽯橋を叩いて渡る「開発環境」
継続的インテグレーション
テスト駆動開発
リファクタリング
ペアプログラミング…
その他

アジャイル開発の現場

プロジェクトの可視化からはじめましょう。

⾒える化/透明性l「最新の正の情報」が、「⼀箇所に」、「⼤きく」書かれていて、それを、「両チームのメンバー」、「審判」、「観客」が⾒ている。 「次の⾏動」を誘発する。

POINT 全ステークホルダーが、行動を起こせるような、確かな、分かりやすい情報源
50

タスクかんばん• 作業の見える化– ToDo(未実施)
Doing(実施中)
Done(完了)で管理。
– 各自の作業を指示しなくても、毎朝自発的に作業開始。
– フォーマットは徐々にカイゼン。

タスクかんばんの例(協力：チェンジビジョンastah* チーム）

※バーンダウンチャーなどと共に、とにかく、壁に貼る。「情報発信器」とも呼ばれる。

POINT
52

作業の見える化は、「タスクかんばん」で行なう。

助け合う

SOMCでの朝会のヒトコマ３⼈のリーダが集まっての朝会。移動式ホワイトボードであるNUboardを使ってます。
（写真提供︓ソニーモバイルコミュニケーションズの冨⽥さん）

54

⽇本からも海外へ発信

55

“Kanban, Successful Evolutionary Change forYour Technology Business”

http://www.agilemanagement.net
56

Corey Ladas
http://leansoftwareengineering.com/2007/10/27/kanban-bootstrap/
57

現場で⼯夫する

（協力：ヤマハモーターソリューション）

59ポータブルかんばん(協力：CCS 佐藤竜一さん）

POINT
60

「かんばん-nano」スーツにもベストフィット！

バーンダウンチャート• 進捗の見える化– バーンダウン（下向き）– タスクかんばんと連動– 中間成果物では計測しない。
– メールでエクセルシートを配布したり、サーバに置いたから見てね、はナシ。
バーンダウンチャートの例(協力：永和システムマネジメント：チーム角谷）

POINT61

全体進捗は、「バーンダウンチャート」で見える化、繰り返しのリズムづくり

スルーしない朝会• 作業の明確化– ⾃発的なサインアップ– 昨⽇やったこと、今⽇やること、問題点、の３点のみ。
– かんばんの前で、⾏なう。
– 朝の仕事はじめが重要︕
朝会の例(協力：チェンジビジョンastah* チーム）– スタンドアップで１５分．
– 定時刻、定位置、短時間
PF実践編：朝会ガイド
http://www.ObjectClub.jp/community/pf/

POINT
p.63

毎朝、「かんばん」の前で全員で短い会議を行ない、リズムをとる。

ふりかえり(1)• カイゼンの気づき– Keep(良い点)
Problem(悪い点)
Try(次回挑戦)を出す。
– 全員で意⾒を出し、暗黙知の共同化と形式知化を⾏なう。「名前付け」– 「課題－解決リスト」、とは違う。
ふりかえりシートの例– とにかく、カジュアルな雰囲気で全員発⾔することで、チームの実践編：ふりかえりガイド
安全性を確保する。
http://www.ObjectClub.jp/community/pf/– 「問題vs私たち」の構図になるように。

POINT
p.64

カイゼンの「気づき」を「ふりかえり」で得る。

ふりかえり(2)• Keep/Problem/Try（KPT）–Keepは定着する。
やってみて–ProblemはTryをうまく行った⽣み出す。
Keep
Try–Tryは、Keepか定着ProblemProblemに移動する。
うまく行かない解決法–定着したものには、「名前づけ」を。
新しい問題！
新しいアイディア！
ふりかえりがカイゼンを導く

POINT
p.65

イテレーション毎に「ふりかえり」を繰り返すことでプロセスが改善される。

66

esm-conferenceブログより
やわたメディカルさんの事例

67“現場では、このようにKPTを張り出し、気づいた時に付箋をはり、毎⽇お昼に話し合って、すぐアクション、というサイクルで回していたとのこと。24時間/365⽇とまらない現場は、このように⼿軽に導⼊しやすく、当事者同⼠で話し合って解決策を⾒つける仕組み（問題vs私たち）がフィットしたとのこと。”

佐賀県庁の事例(1)• ニコニコカレンダー(協力：佐賀県庁東 泰史さん)
68佐賀県庁の事例(2)• タスクかんばん

危険ゾーン(協力：佐賀県庁東 泰史さん)
69佐賀県庁の事例(3)

• 朝会

副知事

(協力：佐賀県庁東 泰史さん)

70

ぜひこの資料を見てください。（有名資料）
http://www.slideshare.net/hiranabe/agilejapan2010-saga-prefecture-higashi

ヴァル研究所

⽇本最⼤数(100以上)のかんばん実践例が観れます。
下は総務(!)の例。営業でも、開発でも。

https://speakerdeck.com/araitakeshi/hui-she-falsewen-hua-woaziyairunibian-etaikiminimodekiruyo

全体構成•••••

色つきUML

⾒える化リズム
名前づけ問題対私たちカイゼン

１週間
計画
半日

イテレーション開発
一日の繰り返し

ふりかえり
半日

タスク
タスク

要求

朝会、かんばん バーンダウン
タスク
タスク

ふりかえり
ペアボード

マインドマップ
p.78

あんどん

にこにこカレンダー

SKMSastah* 開発チーム例

p.79

ウォーターフォールからアジャイルへの移⾏中

https://www.agilejapan.org/session.html#kb-06
80

Scrumと野中郁次郎

99最初のスクラムの本• “Agile Software Development with Scrum”(by Ken Schwaber, Mike Beedle) の最初の⼀⾏は次の引⽤で始まっている。
今⽇では新製品開発の動きが速く、競争率の⾼い世界では、速度と柔軟性がとても重要である。企業は、新製品開発に直線的な開発⼿法は古く、この⽅法では簡単に仕事を成し遂げることができないことを徐々に認識し始めている。⽇本やアメリカの企業では、ラグビーにおいて、チーム内でボールがパスされながらフィールド上を⼀群となって移動するかのように、全体論的な⽅法を⽤いている。
-- “The New New Product Development Game”

Agile and Lean
Patterns
The New New ProductDevelopment Game

1

Manufacturing Industry in Japan
Toyota Production
System2

XPScrum

Lean Software
DevelopmentLean

AgileKanban
Lean Startup

2013 Yasunobu Kawaguchi

Startup

Four steps
to the epiphany

Innovation Sprint 2011

meJeff Sutherland

Ikujiro Nonaka

http://www.publickey1.jp/blog/11/10_innovation_sprint_2011.html

106

出典: So what is the role of Management in Scrum?
Management becomes Leadership -- Jeff Sutherland

Harvard Business Review
2018年10⽉版

107Scrum Interaction 2019(1/2)

108Scrum Interaction 2019(2/2)
ソフトウェア開発を超えた。
マーケティング改⾰や組織改⾰へ。
事例発表︓• コカコーラ• MSD(製薬)• 3M109••••

知識はどこから来る︖
暗黙知(1)
形式知(2)SECI モデル• 知識を”実践する”には︖• 実践知(3)• それを誰が作る︖

第⼆版によせて我々が1980年に書いた論⽂「新しい新製品開発ゲーム」で提⽰した「スクラム」というコンセプトが、アジャイルというソフトウェア開発分野でさかんに使われているという。このことを初めて知ったのは、2010年のことだ。（中略）2011年にはJeff Sutherland と初めて話す機会を持った。彼は、ベトナム戦争でかつて戦闘機パイロットとして従軍し、極限状態での臨機応変なマネジメントの重要性を知っている。そこでなるほど、と納得した。私が研究してきた知的機動⼒による組織的イノベーション論との融合がソフトウェア開発の場で起こっているのだ。（中略）

仮書影•
••

⽇本の4事例追加
Nexus/Scrum@Scale/
LeSS/DA/SAFe の解説追加
スクラムガイド2020対応

2020年には、そのスクラムが、ソフトウェア開発プロセス⼿法に閉じず、イノベーションのための「組織改⾰⼿法」として拡張されている、という話を聞いた。今度は、私の専⾨である組織論にまで彼の考えも及んできたのだ。私はもともとスクラムの概念を組織論として論じており、アジャイルスクラムが⼩さなチームの話だけで終わるはずがない、と考えていた。
そして、実際に、その変化が起きている。 現在デジタルトランスフォーメーション(DX)という薄っぺらい⾔葉で語られる変化には、もっと⼈間の内⾯にせまる本質があるはずだ。（中略）ここに来て、もともと私たちが思索・理論化した組織論、知識創造理論とのつながりが、さらに強くなった。（中略）今、⽇本ではスタートアップの世界だけではなく、⼤企業も変わらなければならない。⾃分ごととして組織や社会を考えるリーダーシップが、トップにも、フロントの現場にも、そしてミドルマネジメントにこそ必要だ。
そんな⽅々に、ぜひ読んでいただきたい。
野中郁次郎

野中郁次郎/竹内弘高
The New New ProductDevelopment Game(HBR)
1

失敗の本質
アメリカ海兵隊
知的機動⼒

2

Scrum
リレーからラグビーへ

Knowledge-Creating Company
知識創造企業SECIモデル
暗黙知と形式知のスパイラルな変換活動が、知識創造過程である

3

4
Wise Company
ワイズカンパニー

知的機動力

実践知/フロネシス

消耗戦から機動戦へ
フラクタル組織

SECIプロセスを駆動する、実践知。賢慮のリーダーシップ

第２の系譜

第１の系譜

SoS（フラクタル構造）

SoS（プロダクト・サービス）
スクラム
チーム

114

SoSoS
（事業）

PO

チームのバックログの優先順位を決める

SM

チームの障害が取り除かれるようにする

CPO

プロダクト・サービス
レベルのバックログの優先順位を決める

SoSM

プロダクト・サービスレベルの障害が取り除かれるようにする

CCPO

事業レベルのバックログの優先順位を決める

SoSoSM

事業レベルの障害が取り除かれるようにするスクラムとはスクラムとは、会社を機能単位に分割した階層や組織ではなく、どこをとっても会社のビジョンに向かった判断・⾏動パターンを共有する⾃⼰相似形（フラクタル）の知識創造活動であり、それを実践する⼈々である。
-- 野中郁次郎・平鍋健児『アジャイル開発とスクラム』

デジタルとアナログ

15

15

リモート場作りのツール群

よく使うツール会議 Zoom/Teams/Google Meet

⾳声 discord/spatial chatホワイトボード Mural, miro

連絡系 Slack/idobata

158

バーチャル⽀社︓ovice

discord

15

Idobata16

Spatial chat161

Miro – ホワイトボード

164

167

16

コロナの中でハマっています。
⾳楽もとても素敵16出典︓東洋経済オンライン https://toyokeizai.net/sp/thinkers/ed/nonaka01.html

創発場

対話場

実践場

システム場

SECIにはそれぞれ、場の名前がある

外国で「場」って⾔ってもなかなか通じない。
ところが、イギリスでは通じるんだな。
Ba は Bar って。

イギリスの Bar - (パブ)待ち合わせはパブで。その後食事にいく。
自然と会話を楽しめるセッティング。
見知った仲間がそこにいる。知らない人を紹介される。

https://www.flickr.com/photos/orangejon/

リモートでの場作り

リモートアジャイル開発のノウハウ集

https://www.asf.esm.co.jp/remote-know-how

Work Together Anywhere – Lisette Sutherland

1
9

195

リモートワークのパタン

当⽇書いていただいたものも含めました︕
https://clipport.io/invites/ab3cfd6b69db46a62e8f3833890c1ba0リモート場作りの難しさ「あなた」が「あなた」になるまえ相互主観を媒介とする主観の客観化
主観

客観

組織

大きな組織で共有する
客観
(3人称)

対面で共創する
相互主観

集団

（2人称）

個人の主観
（1人称）

個人
相互主観とは、相互に他者の主観と全人的に向き合い、受け容れ合い、共感し合うときに成立する、自己を超える「われわれ」の主観である。
© 2017 Nonaka I. all rights reserved.

210

21

Management3.0 Japan conf で聞いてみた
オンラインのみでチームの信頼関係は作れるでしょうか︖
ぼくは、オフラインの合宿などが、チームづくりで必要だと考えていますが、、、私も、リアルに会う場⾯を作ることがとても好きです。定期的に開催することはとてもいいことだと思います。でもできない現状の中でも、なんとか信頼作りの時間を⼊れていきます。合宿は⼀緒にいることで、いろんな会話が起こりますが、オンラインでは⻑時間の時間を取って話の集中⼒を保つのはとても難しいです。なので、短い時間でもチームづくりの時間を、通常のミーティングに定期的に⼊れていくことが必要。例えば、短いアイスブレーキングの時間を会議に⼊れたり、チャットに「⽇常の写真」チャンネ
ルを作って家族や猫の写真を流したり、、、
215

21

21

Continuous (Team) Integration
Continuous (Trust) Build21

⼀緒に学ぶの⼤事

21

ともに働くのだいじ

22

喜びの⾷事だいじ22

Amazon 予約開始︕
https://www.amazon.co.jp/dp/4798167460/

225