13. Seeing is understanding.13
分割の仕⽅
• 顧客に分かる機能で切る。
• 層で切らない。
• ビジネスの価値が分かる。
• やりがい、コミュニケーション
"These days we do not program software
module by module;
we program software feature by feature.“
—Mary Poppendieck
by Akiyah
22. p.22 Project Facilitation by Kenji Hiranabe is licensed under a Creative Commons Attribution 3.0 Unported License.
プロジェクトの
⾒える化から
はじめましょう
23. p.23 Project Facilitation by Kenji Hiranabe is licensed under a Creative Commons Attribution 3.0 Unported License.
見える化/透明性
l 「最新の正の情報」が、「一箇所に」、「大
きく」書かれていて、それを、「両チームのメン
バー」、「審判」、「観客」が見ている。 「次の
行動」を誘発する。
全ステークホルダーが、行動を起こせるような、確かな、分かりやすい情報源 POINT
24. p.24 Project Facilitation by Kenji Hiranabe is licensed under a Creative Commons Attribution 3.0 Unported License.
プロジェクトの成功は、
Moving Target
要求 R(t)
システム S(t)
チーム(t)R(t) S(t)
Δ
t
不明確かつ不
安定な要求。
いくらよい計画を立てても、見えていなければ、プロジェクトは成功できない。POINT
Δ
基盤技術 T(t)
T(t)
25. p.25 Project Facilitation by Kenji Hiranabe is licensed under a Creative Commons Attribution 3.0 Unported License.
実践
26. p.26 Project Facilitation by Kenji Hiranabe is licensed under a Creative Commons Attribution 3.0 Unported License.
タスクかんばん
l 作業の見える化
– ToDo(未実施)
Doing(実施中)
Done(完了)
で管理。
– 各自の作業を指示しなく
ても、毎朝自発的に
作業開始。
– フォーマットは徐々に
カイゼン。 タスクかんばんの例
※バーンダウンチャーなどと共に、とにかく、壁に貼る。「情報発信器」とも呼ばれる。
作業の見える化は、「タスクかんばん」で行なう。 POINT
(協⼒:チェンジビジョンastah* チー
ム)
27. p.27 Project Facilitation by Kenji Hiranabe is licensed under a Creative Commons Attribution 3.0 Unported License.
助け合う
28. p.28 Project Facilitation by Kenji Hiranabe is licensed under a Creative Commons Attribution 3.0 Unported License.
バーンダウンチャート
l 進捗の見える化
– バーンダウン(下向き)
– タスクかんばんと連動
– 中間成果物で
は計測しない。
– メールでエクセルシート
を配布したり、
サーバに置いたから
見てね、はナシ。
バーンダウンチャートの例
全体進捗は、「バーンダウンチャート」で見える化、繰り返しのリズムづくり POINT
(協⼒:永和システムマネジメント:チー
ム⾓⾕)
29. p.29 Project Facilitation by Kenji Hiranabe is licensed under a Creative Commons Attribution 3.0 Unported License.
スルーしない
30. p.30 Project Facilitation by Kenji Hiranabe is licensed under a Creative Commons Attribution 3.0 Unported License.
SOMCでの朝会のヒトコマ
3⼈のリーダが集まっての朝会。移動式ホワイトボードであるNUboardを使ってます。
(写真提供:ソニーモバイルコミュニケーションズの冨⽥さん)
31. p.31 Project Facilitation by Kenji Hiranabe is licensed under a Creative Commons Attribution 3.0 Unported License.
日本からも海外へ発信
33. p.33 Project Facilitation by Kenji Hiranabe is licensed under a Creative Commons Attribution 3.0 Unported License.http://blog.crisp.se/henrikkniberg/
34. p.34 Project Facilitation by Kenji Hiranabe is licensed under a Creative Commons Attribution 3.0 Unported License.
http://leansoftwareengineering.com/2007/10/27/kanban-bootstrap/
Corey Ladas
35. p.35 Project Facilitation by Kenji Hiranabe is licensed under a Creative Commons Attribution 3.0 Unported License.
現場で
⼯夫する
40. p.40
ふりかえり(2)
l Keep/Problem/Try(KPT)
– Keepは定着する。
– ProblemはTryを
生み出す。
– Tryは、Keepか
Problemに移動する。
– 定着したものには、
「名前づけ」を。
ふりかえりがカイゼンを導く
Keep
Problem
Try
新しい問題! 新しいアイディア!
解決法
やってみて
うまく行った
うまく行かない
定着
イテレーション毎に「ふりかえり」を繰り返すことでプロセスが改善される。 POINT
41. p.41 Project Facilitation by Kenji Hiranabe is licensed under a Creative Commons Attribution 3.0 Unported License.
42. esm-conferenceブログより
p.42 Project Facilitation by Kenji Hiranabe is licensed under a Creative Commons Attribution 3.0 Unported License.
やわたメディカルさんの事例
“現場では、このようにKPTを張り出し、気
づいた時に付箋をはり、毎⽇お昼に話し
合って、すぐアクション、というサイクル
で回していたとのこと。24時間/365⽇とま
らない現場は、このように⼿軽に導⼊しや
すく、当事者同⼠で話し合って解決策を⾒
つける仕組み(問題vs私たち)がフィット
したとのこと。”
43. p.46 Project Facilitation by Kenji Hiranabe is licensed under a Creative Commons Attribution 3.0 Unported License.
PFの5つの原則
l 見える化(Management by Sight)
– 目に見えるようにして、行動につなげる。
l リズム(Rhythm)
– 人間活動として定期的なリズムを設計する。
l 名前づけ(Name and Conquer)
– 気づいた概念に名前をつけておく。
l 問題 vs. 私たち (Problem vs. us)
– 「問題」と「人間」を分離する。
l カイゼン(Kaizen)
– 継続的に、今の自分たちにできる、小さいことから。
44. p.47 Project Facilitation by Kenji Hiranabe is licensed under a Creative Commons Attribution 3.0 Unported License.
見える化
l 「最新の正の情報」が、「一箇所に」、「大き
く」書かれていて、それを、「両チームのメンバー」、
「審判」、「観客」が見ている。 「次の行動」を誘発
する。
全ステークホルダーが、行動を起こせるような、確かな、分かりやすい情報源 POINT
45. p.48 Project Facilitation by Kenji Hiranabe is licensed under a Creative Commons Attribution 3.0 Unported License.
リズム
l リズムを「デザイン」する
– 四半期、月、週、日
– 会議や成果物のタイミング
– 日次のテスト
– 日次の朝会(毎朝10:00)
– 週次の会議(毎週金曜は。。。)
l 朝会、ふりかえりのタイミング
l リズムが行動の「搬送波」
リズム(チームの鼓動)をデザインして、チームを前進させよう POINT
リズムがチームのハート
ビート
46. p.49 Project Facilitation by Kenji Hiranabe is licensed under a Creative Commons Attribution 3.0 Unported License.
名前付け
l 「気づき」をキャッチ
l ナレッジを,
– 定着
– 他のチームに伝播
l 例:
– 「今日のお仕事」(by 坂田さん)
– 「ぬかどこ」(by 倉貫さん)
– 「にこにこカレンダー」
名前をつけないと,「気づき」が逃げて行っちゃう! POINT
名前は⼤切(写真協⼒:平塚市博物館)
47. p.50 Project Facilitation by Kenji Hiranabe is licensed under a Creative Commons Attribution 3.0 Unported License.
問題対私たち
(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の構
図
48. p.51 Project Facilitation by Kenji Hiranabe is licensed under a Creative Commons Attribution 3.0 Unported License.
カイゼン
l 大きな改革でははじまらな
い
l 小さなカイゼンから
l 今の自分たちでできること
l 来週からできること
l よくなっていくことを体感し
よう
l ふりかえり、が強力な武器
l For the better tomorrow
l 明日はきっと今日よりも、い
い日に決まっている
継続的に、今の自分たちでできることからカイゼンを。うまくいったら自分たちをホメようPOINT
49. p.52 Project Facilitation by Kenji Hiranabe is licensed under a Creative Commons Attribution 3.0 Unported License.
要求
タスク
タスク
タスク
タスク
計画 イテレーション開発 ふりかえり
朝会、かんばん バーンダウン
あんどん ペアボード
ふりかえり
色つきUML
全体構成
半日 半日 一日の繰り返し
1週間
マインドマップ SKMS
l 見える化
l リズム
l 名前づけ
l 問題対私たち
l カイゼン
にこにこカレンダー
50. p.53 Project Facilitation by Kenji Hiranabe is licensed under a Creative Commons Attribution 3.0 Unported License.
佐賀県庁の事例(1)
l ニコニコカレンダー
(協力:佐賀県庁
東 泰史さん)
51. p.54 Project Facilitation by Kenji Hiranabe is licensed under a Creative Commons Attribution 3.0 Unported License.
危険
ゾーン
佐賀県庁の事例(2)
l タスクかんばん
(協力:佐賀県庁
東 泰史さん)
52. p.55 Project Facilitation by Kenji Hiranabe is licensed under a Creative Commons Attribution 3.0 Unported License.
副知事
佐賀県庁の事例(3)
l 朝会
(協力:佐賀県庁
東 泰史さん)
ぜひこの資料を⾒てください。(有名資料)
http://www.slideshare.net/hiranabe/agilejapan2010-saga-
prefecture-higashi
63. Change Vision, Inc.
ソフトウェア工学についての後悔
l Tom Demarco
– ソフトウェア工学、そのときは去った。
l Ed Yourdon
– ソフトウェア工学に大切なことは?
l Barry Boehm
- あの指数曲線は間違いだった。
l Ivar Jacobson
– ソフトウェア業界は、ファッション業界のようだ。
l Tom Gilb
– ソフトウェア工学は定義を間違った。
66. 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
69. 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
70. Published under the GNU Free Documentation License (GFDL)
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
71. Published under the GNU Free Documentation License (GFDL)
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). 西海岸に
ある2つのハイテク会社での1,000時間にわたる観察に基づいている。”
• “社員は、プロジェクトの中で11分ごとにインタラプトされ、別のことに振り回される。11分のタスクは、email の返信、のようなより短い3分のタ
スクに分断され、タスクから引き離されるたびに、戻るのに平均で25分の時間がかかる。”
82
74. 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
76. 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)
79. 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”
80. 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…