Agile, Software Engineering, Process Kaizen. They mix like oil and water ?

Seeing is understanding.1
アジャイルはエンジニアリングか
プロセスか、あるいは新思想か？
〜⽔と油と醤油の混ざり⽅〜
株式会社永和システムマネジメント
株式会社チェンジビジョン
平鍋健児

Seeing is understanding.
⾃⼰紹介
•  ㈱永和システムマネジメント
–  福井市（本社）、上野東京（⽀社）、沖縄（事務所）
–  「⾦融」、「医療」、「組込みシステム」開発
–  GoogleApps を使った KAZEN Cloud
–  「Ruby と Agile」を使ったシステム開発
•  株式会社チェンジビジョン
–  福井市（開発部）、上野東京（本社）
–  astah* (旧：JUDE) の開発
•  平鍋健児
–  UML+マインドマップエディタ astah*の開発
–  要求開発アライアンス、理事
–  翻訳、XP関連書籍、『リーン開発の本質』
『IMPACT MAPPING』等多数。
–  著書『アジャイル開発とスクラム』、『要求開発』
『ソフトウェア開発に役⽴つマインドマップ』

p.3
1F交流ギャラリーにて

『アジャイル開発とスクラム』
• 顧客・技術・経営の３者をつなぐ
ために、アジャイルと⽇本経営の
接合点を探る
• 海兵隊の組織とアジャイル
• 知識創造プロセスとアジャイル
• 実践知リーダーとアジャイル
• 富⼠通・楽天・リクルートの事例
• Jeﬀ Sutherlandインタビュー
平鍋健児＋野中郁次郎著

アジェンダ
• アジャイル開発⼊⾨
– なぜアジャイルか?
– アジャイルとは何か？
– アジャイルの事例
• アジャイルの実際
– アジャイルのチームづくり
• アジャイルはプロセスか?

なぜ、
アジャイルか?

市場ビジネス IT
市場分析発注
納品リリース
半年から３年
ミッション・リスク分割型ビジネスと
ウォーターフォール型開発（従来型）

従来型の問題＝要求の劣化
システムの機能の利用度
全く使われない
45%ほとんど使われな
い
19%
たまに使う
16%
いつも使う
7%
よく使う
13%
•  Standish group study report in 2000 chaos report

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

IDEAS
CODEDATA
BUILDLEARN
MEASURE
素早くコード
単体テスト
ユーザビリティテスト
継続的結合
漸進開発
オープンソース利用
クラウド
クラスタ免疫システム
JITスケーラビリティ
リファクタリング
デベロパーサンドボックス
素早く測定
AB テスト
明確なプロダクトオーナ
継続的開発
ユーザビリティテスト
リアルタイムモニタ
顧客代表
素早く学習
AB テスト
顧客インタビュー
顧客開発
なぜなぜ5回、真因分析
顧客アドバイザリボード
仮説検証
プロダクト・オーナーの責任
顧客タイプ分析
機能横断チーム
半自立チーム
スモークテスト
漏斗分析
コホート分析
ネットプロモータスコア
検索エンジンマーケティング
リアルタイムアラート
予測的モニタリング
Lean Startup

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

プロセスとしてのアジャイル
•  短いサイクルで分析、設計、実装、テストを並列に⾏う
•  タイムボックス型、進化型開発
分析
設計
実装
テスト時間時間
要求(スコープ) 要求(スコープ)Waterfall Agile
Beck 2000Royce 1970
最後に動くものができる
動くものが徐々に
できあがり、成長する

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

製品
バックログ
スプリント
バックログ
1-4 週
24 時間
出荷可能
ソフトウェア
朝会
スクラムのフレームワーク

アジャイルの
価値、原則、実践
価値
value
原則
principle
実践
practices
まずはこれを共有すること
考え方としての方針
具体的に現場ごとに作る

アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツール　よりも　個人と対話を、
包括的なドキュメント　よりも　動くソフトウェアを、
契約交渉　よりも　顧客との協調を、
計画に従うこと　よりも　変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
Kent Beck 
Mike Beedle 
Arie van Bennekum 
Alistair Cockburn 
Ward Cunningham 
Martin Fowler 
James Grenning 
Jim Highsmith 
Andrew Hunt 
Ron Jeffries 
Jon Kern 
Brian Marick 
Robert C. Martin 
Steve Mellor 
Ken Schwaber 
Jeff Sutherland 
Dave Thomas 
© 2001, 上記の著者たち
この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。
重要超重要!

アジャイルの原則
• 顧客価値の優先
• 変化に対応
• 短期のリリース
• 全員同席
• モチベーションと信頼
• 会話
• 動くソフトウェア
• 持続可能なペース
• 技術的卓越性
• シンプル
• ⾃⼰組織的チーム
• ふりかえりと改善

アジャイルの
プラクティス（例 XP）
•  計画ゲーム
•  ⼩規模リリース
•  メタファー
•  シンプルデザイン
•  テスティング
•  リファクタリング
•  ペアプログラミング
•  共同所有権
•  継続的インテグレーション
•  週40時間
•  オンサイト顧客
•  コーディング標準

⾼速に⽯橋を
叩いて渡る
「開発環境」
協働でゴールに
向かう
「チーム環境」
ビジネス価値、
顧客満⾜、市場創造
継続的インテグレーション
テスト駆動開発
ペアプログラミング
アジャイルモデリング
…
その他
朝会
タスクかんばん
バーンダウンチャート
ふりかえり
…
その他
アジャイルの
レフトウィング
アジャイルの
ライトウィング
アジャイルのゴール
ソーシャルプラクティス技術プラクティス

アジャイル開発の実際
〜プロジェクトファシリテーション〜

p.22 Project Facilitation by Kenji Hiranabe is licensed under a Creative Commons Attribution 3.0 Unported License.
プロジェクトの
⾒える化から
はじめましょう

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

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

プロジェクトの成功は、 
Moving Target
要求　　R(t)
システム　　S(t)
チーム(t)R(t) S(t)
Δ
t
不明確かつ不
安定な要求。
いくらよい計画を立てても、見えていなければ、プロジェクトは成功できない。POINT
Δ
基盤技術　　T(t)
T(t)

実践

l  作業の見える化
– ToDo(未実施) 
Doing(実施中) 
Done(完了) 
で管理。
– 各自の作業を指示しなく 
ても、毎朝自発的に 
作業開始。
– フォーマットは徐々に 
カイゼン。タスクかんばんの例
※バーンダウンチャーなどと共に、とにかく、壁に貼る。「情報発信器」とも呼ばれる。
作業の見える化は、「タスクかんばん」で行なう。 POINT
(協⼒：チェンジビジョンastah* チー
ム）

助け合う

l  進捗の見える化
– バーンダウン（下向き）
– タスクかんばんと連動
– 中間成果物で 
は計測しない。
– メールでエクセルシート 
を配布したり、 
サーバに置いたから 
見てね、はナシ。
バーンダウンチャートの例
全体進捗は、「バーンダウンチャート」で見える化、繰り返しのリズムづくり POINT
(協⼒：永和システムマネジメント：チー
ム⾓⾕）

スルーしない

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

日本からも海外へ発信

“Kanban, Successful Evolutionary
Change for Your Technology Business”
http://www.agilemanagement.net

p.33 Project Facilitation by Kenji Hiranabe is licensed under a Creative Commons Attribution 3.0 Unported License.http://blog.crisp.se/henrikkniberg/

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

現場で
⼯夫する

p.36
「かんばん-nano」スーツにもベストフィット！ POINT
ポータブルかんばん
(協力：CCS 佐藤竜一さん）

p.37
日本からも海外へ発信

p.38
朝会
l  作業の明確化
–  自発的なサインアップ
–  昨日やったこと、 
今日やること、 
問題点、の３点のみ。
–  かんばんの前 
で、行なう。
–  朝の仕事はじめが 
重要！
–  スタンドアップで１５分．
–  定時刻、定位置、短時間
朝会の例(協力：チェンジビジョンastah* チーム）

毎朝、「かんばん」の前で全員で短い会議を行ない、リズムをとる。 POINT
PF実践編：朝会ガイド 
http://www.ObjectClub.jp/community/pf/

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

p.40
ふりかえり(2)
l  Keep/Problem/Try（KPT）
–  Keepは定着する。
–  ProblemはTryを 
生み出す。
–  Tryは、Keepか 
Problemに移動する。
–  定着したものには、 
「名前づけ」を。
ふりかえりがカイゼンを導く
Keep
Problem
Try
新しい問題！新しいアイディア！
解決法
やってみて
うまく行った
うまく行かない
定着
イテレーション毎に「ふりかえり」を繰り返すことでプロセスが改善される。 POINT

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

PFの5つの原則
l  見える化(Management by Sight)
– 目に見えるようにして、行動につなげる。
l  リズム(Rhythm)
– 人間活動として定期的なリズムを設計する。
l  名前づけ(Name and Conquer)
– 気づいた概念に名前をつけておく。
l  問題 vs. 私たち (Problem vs. us)
– 「問題」と「人間」を分離する。
l  カイゼン（Kaizen)
– 継続的に、今の自分たちにできる、小さいことから。

見える化
l  「最新の正の情報」が、「一箇所に」、「大き
く」書かれていて、それを、「両チームのメンバー」、
「審判」、「観客」が見ている。「次の行動」を誘発
する。

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

リズム
l  リズムを「デザイン」する
– 四半期、月、週、日
– 会議や成果物のタイミング
– 日次のテスト
– 日次の朝会（毎朝１０：００）
– 週次の会議（毎週金曜は。。。）
l  朝会、ふりかえりのタイミング
l  リズムが行動の「搬送波」
リズム（チームの鼓動）をデザインして、チームを前進させよう POINT
リズムがチームのハート
ビート

名前付け
l  「気づき」をキャッチ
l  ナレッジを，
–  定着
–  他のチームに伝播
l  例：
–  「今日のお仕事」（by 坂田さん）
–  「ぬかどこ」(by 倉貫さん)
–  「にこにこカレンダー」
名前をつけないと，「気づき」が逃げて行っちゃう！ POINT
名前は⼤切（写真協⼒：平塚市博物館）

問題対私たち  
(Problem vs. Us)
l  ともすると，議論は 
You vs. Me 
You vs. Us になりがち．
l  「問題」と「人」とを分離
l  Problem vs. Usにもちこむ。
–  ホワイトボードを使う
–  座り方を替える
–  ペアプログラミング
不毛なゼロサムゲームから，生産的な議論へ向かうカギ． POINT
You vs. Meの構
図
You vs. Usの構図
問題 vs. Usの構
図
問題 vs. Usの構
図

カイゼン
l  大きな改革でははじまらな
い
l  小さなカイゼンから
l  今の自分たちでできること
l  来週からできること
l  よくなっていくことを体感し
よう
l  ふりかえり、が強力な武器
l  For the better tomorrow
l  明日はきっと今日よりも、い
い日に決まっている
継続的に、今の自分たちでできることからカイゼンを。うまくいったら自分たちをホメようPOINT

要求
タスク
タスク
タスク
タスク
計画イテレーション開発ふりかえり
朝会、かんばんバーンダウン
あんどんペアボード
ふりかえり
色つきUML
全体構成
半日半日一日の繰り返し
１週間
マインドマップ SKMS
l  見える化
l  リズム
l  名前づけ
l  問題対私たち
l  カイゼン
にこにこカレンダー

佐賀県庁の事例(1)
l  ニコニコカレンダー
(協力：佐賀県庁 
東　泰史さん)

危険
ゾーン
l  タスクかんばん
東　泰史さん)

副知事
l  朝会
東　泰史さん)
ぜひこの資料を⾒てください。（有名資料）
http://www.slideshare.net/hiranabe/agilejapan2010-saga-
prefecture-higashi

Seeing is understanding.
デジタルとアナログ

p.57
astah* 開発チーム例

アジャイルはソフトウェア⼯学か？
73

Change Vision, Inc.
ソフトウェア工学についての後悔
l  Tom Demarco
–  ソフトウェア工学、そのときは去った。
l  Ed Yourdon
–  ソフトウェア工学に大切なことは？
l  Barry Boehm
-  あの指数曲線は間違いだった。
l  Ivar Jacobson
–  ソフトウェア業界は、ファッション業界のようだ。
l  Tom Gilb
–  ソフトウェア工学は定義を間違った。

Change Vision, Inc.
IEEE SOFTWARE 2009

Software development is and always will
be somewhat experimental. The actual
software construction isn’t necessarily
experimental, but its conception is.
And this is where our focus ought to
be. It’s where our focus always ought
to have been.
– Tom DeMarco

ソフトウェア工学で 
最も大切な 
１０の考え方
Ed Yourdon
Blog: www.yourdonreport.com,
Twitter, Flickr, Facebook, LinkedIn:
“yourdon”
Version 11.1, spring 2009
Slideshare.net version
Japanese translation by
Kenji Hiranabe
日本語訳：平鍋健児
全⽂はこちら
http://blogs.itmedia.co.jp/hiranabe/2009/03/ed-
yourdon-ca9f.html

Published under the GNU Free Documentation License (GFDL)
Top Ten Eleven Items
1. 計測できないものは制御できない
2. ピープルウェア(Peopleware)
3. インクリメンタル(Incrementalism)
4. 反復(Iteration)
5. 欠陥が下流に漏れること、修正コストが増加する
6. トレードオフは、非線形
7. 再利用は重要
8. リスクマネジメントが鍵
9. 一貫性は才能+デスマーチに勝る
10. 車輪を再発明しない
11.  透明性を重視。何も隠さないこと
80

1.計測できないものは制御できない
q  多くの良書がある。例えば、トム・デマルコ 1982 の古典、
「品質と生産性を重視したソフトウェア開発プロジェクト技法」, そして、Paul Strassmann の
The Squandered Computer
q  Cultural/management issues more important than technical issues (1987 の古典
HP’s Robert Grady & Deborah Caswell,
Software Metrics: Establishing a Company-Wide Program
q  コア・メトリクス: 規模, 見積, 欠陥, 離職
q  ソフト・メトリクス: 士気（モラール）、ユーザ満足度など。
q  システム・ダイナミクス — 例えば、ブルックスの法則 (Tarek Abdel-Hamid の
Software Project Dynamics, と Ray Madachy の新しい本,
Software Process Dynamics)
q  新展開: Joel のエビデンス駆動スケジューリング(evidence-based scheduling)
q  ハイゼンベルグの不確定原理の潜在的なポジティブな側面を利用。
81

2. ピープルウェア
q  人は（いつの時代でも）プロジェクトにおける最大の生産性要因である。
q  最もよい人材を採用して、Google の人材管理をまねよ。
q  質問：一番頭のよい大学卒業生が、あなたの会社を選択しますか（選択権が彼ら
にあると仮定して）？
ü  注意！　彼らのほとんどは MS Outlook を見たことがない。 (もし見たら恐れるだろう)
ü  彼らは、すべての人がFacebook にブログを書き、とiPhone/Android上で IM していると思っている。
ü  彼らは、 COBOLでのプログラミングできる人がまだ生きている、ということに仰天する。
q  彼らによいオフィス空間をあたえて、仕事環境でのインタラプトを最小限にせよ。
q  「チーム殺し(teamicide)」をするな。
q  『ピープルウェア』: ICSE 2007 パネルセッション、「peopleware20周年記念」のレ
ポートを見よ(Sep 2007 IEEE Software). 私のブログでも無料でみれる。（訳者
注：ぼくのブログに解説あり）
q  “Meet the Life Hackers,” を見よ(Oct 16, 2005 New York Times). 西海岸に
ある２つのハイテク会社での1,000時間にわたる観察に基づいている。”
•  “社員は、プロジェクトの中で11分ごとにインタラプトされ、別のことに振り回される。11分のタスクは、email の返信、のようなより短い3分のタ
スクに分断され、タスクから引き離されるたびに、戻るのに平均で25分の時間がかかる。”
82

http://www.flickr.com/photos/74987020@N00/131796142/
Barry Beohm

Plan-driven
sweet spot
Time and Effort Invested in Plans
Damagefrom
over/underplanning
The “correct” mix of planning vs. reacting
depends on the individual project’s risk exposure.
from “Get Ready for Agile Methods – With Care”
(Barry Boehm, IEEE Computer, January 2001)
Agile
sweet spot

Change Vision, Inc.
ソフトウェア工学は未成熟なプラクティス(immature
practices)によって、重大な阻害(gravely hampered)
を今日受けている。例えば、具体的には以下のように：

l 言葉の流行が、工学の一分野というより
ファッション業界のようだ。
l しっかりした広く受け入れられた、理論的基礎の欠如。
l 非常に多くの方法論(methods)とその派生。またそ
れらの違いがほとんど理解されずに作為的に強
調されている。
l 信頼できる実験的評価(experimental evaluation)
と妥当性確認(validation)の欠如。
l 産業界の実践(industry practice)と学界の研究
(academic research)の乖離。
Call for Action(1/2)

私たちは、ソフトウェア工学を堅固な理論およ
び検証された原則とベストプラクティスを基礎と
して、再建するプロセスを支援する。そのプロセ
スは、以下の特徴を備えている。

l 広く合意された要素からなる、 
特定用途に拡張可能なカーネルを含み、
l 技術の問題と人の問題の両方を扱い、
l 産業界、学界、研究者そして、ユーザに支援
され、
l 要求とテクノロジの変化に応じて追随できるよ
うな拡張性を備えている。
Call for Action(2/2)

TomGilb
ソフトウェアシンポジウム第一回

Definition of Software Engineering
from Wikipedia (= SWEBOK)
“Software engineering is the application
of a systematic, disciplined,
quantifiable approach to the
development, operation, and
maintenance of software, and the study
of these approaches; that is, the
application of engineering to software”

Definition of Software Engineering
Tom Gilb
“Software engineering is the engineering
discipline of enabling and motivating
software systems to deliver a
balanced set of values, directly or
indirectly, to a balanced set of
stakeholders, throughout their
lifecycle…

アジャイルはプロセスか？
96

アジャイルの
価値、原則、プラクティス
価値
value
原則
principle
プラクティス
practices
まずはこれを共有すること
考え方としての方針
具体的に現場ごとに作る

製品
バックログ
スプリント
バックログ
1-4 週
24 時間
出荷可能
ソフトウェア
朝会
スクラムのフレームワーク

価値-原則-プラクティス
＋
プロセスフレームワーク
＋
プロセス改善
p.100

Change Vision, Inc.
Alistair
Cockburn

EcosystemMethodology
Process
Techniques
Tools Skills
Roles
Standards
Quality Teams
Products People
MilestonesActivities
Personality
Jenny
Jim
Peter
Annika
But people are stuffed full of
personality
Project manager
Documenter
Designer
Tester
Values
Values

103
⽅法論の終焉(The End Of Methodology)
“われわれは、ようやく成熟した。現在われわれが作っ
ているのは、「ふりかえり改善フレームワーク
(Reflective Improvement Framework)」とも呼ぶべき
ものであり、方法論(methodology)ではない。
Crystal, Scrum, Kanbanがその例で、これらは少数
のルールからなる。少数とは、プロジェクトを運営す
るのには不十分なくらい、でも、単なる観察と調整
(inspect&adapt)を繰り返すよりも、現場の人々が状
況を改善するには十分なものだ。旧式の「方法論」、
つまり ”Big-M のMethodology” は現在ではもう過
ぎ去り日のものになった。それはよいことだといえる
だろう。”
-- Alistair Cockburn
⽇本語訳: http://blogs.itmedia.co.jp/hiranabe/2011/05/end-of-methodology-ja.html

QA to AQ
Quality Assurance から Agile Quality へ
出典: http://www.washi.cs.waseda.ac.jp/?p=3147
品質⾯でアジャイルになる)
品質の特定
品質の可視化

アーキテクチャリスク
キーとなる品質シナリオ
受け⼊れ基準値

まとめ
（私の⾒解）
108

⽔と油から醤油へ
l  アジャイルはプロセスではない。しかし、現場には必
ずプロセスはある。
l  すべてうまくいくプロセスはなく、環境、働く⼈々、
お客様、製品などの特性によってそれぞれである。
l  誰かが決めるプロセスではなく、現場改善こそが、具
体プロセスを作っていく。その仕組みをプロセス⾃⾝
に⼊れるべき。
l  そして、その活動⾃体も、現場で⾏うべき。
l  この場のみなさんにとっては、、、、
p.109
なんて当たり前のことを言っているのだ！

プロセス改善
ソフトウェア開発の中での、
Agile の位置づけ
ソフトウェア⼯学
ソーシャル⼯学
プロジェクト管理
ビジネス
Agileが 
埋める領域

⾼速に⽯橋を
叩いて渡る
「開発環境」
協働でゴールに
向かう
「チーム環境」
ビジネス価値、
顧客満⾜、市場創造
継続的インテグレーション
テスト駆動開発
ペアプログラミング
アジャイルモデリング
…
その他
朝会
ふりかえり
…
その他
アジャイルの
レフトウィング
アジャイルの
ライトウィング
アジャイルのゴール
ソーシャルプラクティス技術プラクティス