Visualizing Software Development

ソフトウェア開発の「見えるソフトウェア開発の「見える化」化」

平鍋健児平鍋健児永和システムマネジメント主席コンサルタント

4-D-5

開発プロセス開発プロセス


2 　　　　　　　　　　　　　　　　　　　　Copyright © 2005 Kenji HIRANABE, Some rights reserved

今日お話したいこと今日お話したいこと自己紹介、私が思う現在のソフトウェア開発の問題点

リーンソフトウェア開発（簡単に）

ソフトウェア開発の「見える化」とは ?

「見える化」手法の実例をお見せします !

PM から、 PF( プロジェクトファシリテーション ) へ

『『リーンソフトウェア開発リーンソフトウェア開発』』、特にソフトウェアの「見える化」を中心に話します。、特にソフトウェアの「見える化」を中心に話します。POINTPOINT



自己紹介自己紹介

㈱永和システムマネジメント– 本社は福井県福井市， 200 名– 金融・医療・オブジェクト指向を使ったシステム開発– 2002 年より品川に東京支社

平鍋健児– リアルタイム， CAD 、オブジェクト指向の実践– UML エディタ JUDE の開発– オブジェクト倶楽部主宰– アジャイルプロセス協議会、副会長– XP-jp メーリングリスト主宰– 翻訳、 XP 関連書籍、『リーンソフトウェア開発』本日は、本日は、福井から来ました。福井から来ました。POINTPOINT

http://jude.esm.jp/



現在のソフトウェアの問題（顧客）現在のソフトウェアの問題（顧客）

システムの機能の利用度

全く使われない45%ほとんど使われな

い19%

たまに使う16%

いつも使う7%

よく使う13%

Standish group study report in 2000 chaos report

早期に仕様を決定しようとすると，要求仕様が膨らみムダが多くなる早期に仕様を決定しようとすると，要求仕様が膨らみムダが多くなるPOINTPOINT



現在のソフトウェアの問題（開発）現在のソフトウェアの問題（開発）

ビジネスの変化が速い「狙え，打て」では当たらない．個性を持った人間を，交換可能な人的リソースとして扱

うことが開発現場から不人気実際の開発現場では「できる人」におんぶ．一般プロジェクト管理とソフトウェアプロジェクト管理

が違うことは，みんな気付いている．顧客満足は工数やコード行数と関係が薄いプロセスが，読まれないドキュメントづくりとすりかわ

るビジネス変化に対応する，人間ベースのソフトウェア開発手法が必要ビジネス変化に対応する，人間ベースのソフトウェア開発手法が必要POINTPOINT



リーンリーンソフトウェアソフトウェア開発開発

LLean ean SSoftware oftware DDevelopmentevelopment(( 簡単に簡単に ))



『『リーンソフトウェア開発リーンソフトウェア開発』』とはとは

アジャイル開発方法論の１つ。– アジャイル＝変化に対応する開発手法– XP/Scrum/FDD/DSDM/Crystal/ASD など

2003 年、 Mary/Tom Poppendieck が共著。製造業の「リーン生産方式」 ( トヨタ生産方式を含む )

をソフトウェアに置き換えたもの。アジャイル開発方法論がなぜうまくいくのかを、

– XP は、実践とプログラマーの視点からパラダイムシフトとして書いた。

– ASD は、複雑系の理論によって解き明かした。– LSD は、生産革新で実証済みの考え方の延長とマッピングさせた

。リーンソフトウェア開発は、リーン生産方式の言葉でアジャイルを説明したものリーンソフトウェア開発は、リーン生産方式の言葉でアジャイルを説明したものPOINTPOINT



書籍が出ています書籍が出ています

Agile Software Development Conference 2004, 2005(Salt Lake City, USA) で著者と仲良くなりました。

詳しくは書籍にて詳しくは書籍にて……POINTPOINT



リーン思考のリーン思考の 77 つの原則つの原則ムダを排除する

– ムダ、とは顧客にとっての価値を付加しないもの、すべてである。ソフトウェア開発における７つのムダ（未完成作業のムダ、余分なプロセスのムダ、余分な機能のムダ、タスク切り替えのムダ、待ちのムダ、移動のムダ、欠陥のムダ）を発見し、ムダを排除しよう。

学習効果を高める– ソフトウェア開発プロセスは、繰り返し可能な「生産」ではなく、常に「発見」を繰り返す「学習活動」である。この学習プロセスを機能させるために

、活動を見える化し、フィードバックを得ながら自己を改善していく仕組みを作ろう。

決定をできるだけ遅らせる– 不確定要素が多い場合、確実な情報を元に決定を下せるように、「オプション」を維持したままで前進することを許容しよう。このため

には、システムに変更可能性を組み込んでおくことが戦略的に重要である。

できるだけ速く提供する– 「完璧主義」に陥らず、とにかく早く提供する。顧客からフィードバックを得ることで、発見と学習のサイクルが生まれる。このために

も、顧客からのプル型で開発を進めよう。チームに権限委譲する

– 現場の開発者が、 100% の力を出せるようにする。中央集権で管理しようとしてはいけない。自発的な決定ができるようにチームをエンパワーする。見える化の手法をうまく使って、チームが自分の意思で状態を確認しながら前進できるようにしよう。

統一性を作りこむ– 統一性が感じられるシステムには、一貫したビジョンと思想がある。これはプロセスや手順で作ることができない。リーダ

シップとコミュニケーションが、統一性の源泉となる。全体を見る

– 部分最適に陥ってはならない。個人や一組織のパフォーマンスのみで評価すると、部分最適が起こってしまう。一つ上のレベルで評価するようにし、個人や組織の協調が生み出されるようにしよう。

見える化

７つの原則が、プロセスを編み出すためのガイドライン。見える化が裏テーマ７つの原則が、プロセスを編み出すためのガイドライン。見える化が裏テーマPOINTPOINT



ムダを認識するムダを認識する

トヨタ生産方式の「７つのムダ」とソフトウェア開発をマッピング生産工程の７つのムダソフトウェア開発の７つのムダ

在庫のムダ未完成の作業のムダ

加工そのもののムダ余分なプロセスのムダ

作りすぎのムダ余分な機能のムダ

運搬のムダタスク切り替えのムダ

手待ちのムダ待ちのムダ

動作のムダ移動のムダ

不良を作るムダ欠陥（バグ）を作るムダ

まずムダを認識。顧客価値に結びつかない、「すべて」がムダ。まずムダを認識。顧客価値に結びつかない、「すべて」がムダ。POINTPOINT



ムダの見える化＝バリューストリームマッムダの見える化＝バリューストリームマッププ

「価値の流れ」を時間軸上に表したもの

要望要望提出提出

プロジェクプロジェクト承認ト承認

要件要件収集収集

顧客顧客承認承認

分析分析設計設計設計設計レレビュービュー

実装実装テストテスト導入導入

「流れ」に注目し、ムダを発見する。ムダを排除するためのツール。「流れ」に注目し、ムダを発見する。ムダを排除するためのツール。POINTPOINT



ソフトウェア開発の見える化とソフトウェア開発の見える化とはは ??



Moving TargetMoving Target

要求　　 R(t)

システム　　 S(t)

開発チーム (t)開発チーム (t)R(t) S(t)

Δ

Δ

t

不明確かつ不安定な要求。

不明確かつ不安定な要求。

見えなければ、制御できない。適応できない。カイゼンできない。見えなければ、制御できない。適応できない。カイゼンできない。POINTPOINT



見える化の例見える化の例

情報がパッとわかる「現在の状態」も、「結果」もわかる

ソフトウェア開発で使える、見える化手法のヒントは、まだたくさんある。ソフトウェア開発で使える、見える化手法のヒントは、まだたくさんある。POINTPOINT



よく聞く現場の声（よく聞く現場の声（ SESE侍バージョン）侍バージョン）

プロジェクトは遅れているということだが、自分は今日何をすればよいのか分からない。（開発者）

　何が問題か？現在の状態が見えていないのではないか？　何が問題か？現在の状態が見えていないのではないか？POINTPOINT

次の週はきっと９２％ですから！残念！次の週はきっと９２％ですから！残念！

切腹！切腹！

設計が９０％完了のまま、２週間同じ報告が続いている。（マネジャ )

って言うじゃな ~い？

って言うじゃな ~い？

PM （プロジェクトマネジメント）が重要です。数値化し、計画との差異でマネジメントするのです。 (取締役）



「見える化」手法の実例を「見える化」手法の実例をお見せしますお見せします !!



見えなければ行動ができない見えなければ行動ができない

進捗どう見せる？何で測る？日々の作業はどうやって自発的に？異常はどうやって検出する？どうやって改善の行動を生み出す？

見える化の手法、おみせしましょう！見える化の手法、おみせしましょう！POINTPOINT



バーンダウンチャートバーンダウンチャート

進捗の見える化– バーンダウン– 中間成果物で

は計測しない。– 受け入れテスト

を通過した要求数でカウント。

– メールでエクセルシートを配布しない

バーンダウンチャートの例

全体進捗の見える化は、「バーンダウンチャート」で行なう。全体進捗の見える化は、「バーンダウンチャート」で行なう。POINTPOINT



ソフトウェアの一個流しソフトウェアの一個流し

プッシュ型の生産は在庫のムダを増やす。要求を一個流し。テストで進捗管理。プル型で、生産指示を行なう（かんばん）。

工程１

顧客

情報（指示）の流れ

工程２工程３受け入れテスト

生産物（価値）の流れ

プル型によって、在庫を最小に減らしつつ、変化に対応した管理が行なえる。プル型によって、在庫を最小に減らしつつ、変化に対応した管理が行なえる。POINTPOINT



ソフトウェアかんばんソフトウェアかんばん

作業の見える化– ToDo(未実施 )

Doing( 実施中 )Done( テスト完 )で管理。

– 各自の作業を指示しなくても、毎朝自発的に作業開始。

ソフトウェアかんばんの例※バーンダウンチャーなどと共に、とにかく、壁に貼る。「情報発信器」とも呼ばれる。

作業の見える化は、「ソフトウェアかんばん」で行なう。作業の見える化は、「ソフトウェアかんばん」で行なう。POINTPOINT



朝会朝会

作業の明確化– 自発的なサインアップ– ソフトウェアかんばん

の前で、行なう。

– 朝の仕事はじめが重要！

– スタンドアップで１５分．

朝会の例

毎朝、「ソフトウェアかんばん」の前で全員で短い会議を行なう。毎朝、「ソフトウェアかんばん」の前で全員で短い会議を行なう。POINTPOINT



ソフトウェアあんどんソフトウェアあんどん

異常の見える化– 全受け入れテストを自動化。– 毎時バッチで流す。失敗があれば、即時表示。原因追及。

– 欠陥のムダを排除。– 自働化とあんどんに対応

ソフトウェアあんどんの例

異常の見える化は、「ソフトウェアあんどん」で行なう。（受け入れテストを回帰）異常の見える化は、「ソフトウェアあんどん」で行なう。（受け入れテストを回帰）POINTPOINT

※　欠陥のムダ＝欠陥の大きさ ×プロセス中の滞在時間



見える目標見える目標

目標の見える化– なにか形になるもの

で目標をしめし、達成感を味わう。

– プロジェクトキックオフで注目を得て、偶像化する。

– グラフや、数値でもよい。– 目に入ることが重要。

選挙でおなじみのダルマ

目標を全員で共有しよう。目標を全員で共有しよう。POINTPOINT

※　ダルマの目には、開始と終了がある。



ペアボードペアボード

ペアの討議内容の見える化– UML などを使って、二人の討議を見える化。

– 議論が空中戦になるのを避ける。– 他の人を巻き込みやすくする。– ノートを捨てる。（蓄積⇒表現）– 記録は、必要ならそのままコピー！

ペアボードの例

ペアの討議内容を、ボードにして見える化。ノートでなくボードで。ペアの討議内容を、ボードにして見える化。ノートでなくボードで。POINTPOINT



色つき色つき UMLUML

ソフトウェア内部構造の見える化– UML を使って、全員が意識する構造（アーキテクチャ、モデル）を貼り出す。

– 手書きでもよい。– 色をうまく使う。– 図の前で議論が始まる。

ソフトウェア内部構造の UML 例

構造の見える化は、構造の見える化は、「色つき「色つき UMLUML」」で行なう。厳密でなくてよい。手書きでよい。で行なう。厳密でなくてよい。手書きでよい。POINTPOINT



ふりかえりふりかえり (1)(1)

カイゼンの気づき– Keep(良い点 )

Problem(悪い点 )Try(次回挑戦 )を出す。

– 全員で意見を出し、暗黙知の共同化と形式知化を行なう。

ふりかえりシートの例

カイゼンの見える化は、「ふりかえりシート」で得る。カイゼンの見える化は、「ふりかえりシート」で得る。POINTPOINT




Keep/Problem/Try （ KPT ）– Keep は定着する。– Problem は Try を生み出す。– Try は、 Keep か Problem に移動する。

日本語で書くと、– 継続実施 /問題点 /解決案– 良かった点 /悪かった点 /

やってみること– 継続 /不満 /努力– （け・ぷ・と）ふりかえりシートの例

Keep

Problem

Try

新しい問題！新しいアイディア！

解決法

やってみて

うまく行った

うまく行かない

定着

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




プロジェクトやリリースの回顧

タイムライン– プロジェクトを時間軸で振り返る。

– 個々人の物語をチームの物語として表現

青＝喜び赤＝怒り黄＝驚き

感情によって思い出を引き出す。

プロジェクト終了のヒーリング、カタリシス、次のプロジェクトへの勇気



見えなければ行動ができない見えなければ行動ができないとにかく、「壁に貼れ」 (Excel シートのメールでは見

えない）進捗は「バーンダウン」で。日々の作業は「ソフトウェアかんばん」で。「朝会」を行い、作業を自発的に宣言。異常は「ソフトウェアあんどん」で。「見える目標」を置いて。「ペアボード」でその場で話し合いながら。重要なモデルやアーキテクチャは「色つき UML 」で。イテレーション毎に「ふりかえり」を。

見える化は、行動をうみだす第一歩。見える化は、行動をうみだす第一歩。POINTPOINT



要求

タスク

タスク

タスク

タスク

見える目標

テスト・ペアプロ・リファクタリング

計画イテレーション開発

ふりかえり

朝会、かんばんバーンダウン

あんどんペアボード

Keep/Problem/Try

色つき UML

全体構成全体構成

半日半日一日の繰り返し

１週間



その他の「見える化」その他の「見える化」～思考・試行中～～思考・試行中～



その他の試行中のツールその他の試行中のツール

マインドマップ

KYミーティング

SKMS



マインドマップマインドマップ頭の中の見える化

– 中心に話題をおいて– 放射状にキーワードを書く。

すばやいノート術として自己紹介としてどちらかというと、

– ブレインストーム– アイディア書き出し– アウトラインなどの発散系ツールマインドマップの例

頭の中は、「マインドマップ」で見える化。頭の中は、「マインドマップ」で見える化。POINTPOINT



朝会で、リスクの確認を朝会で、リスクの確認をPOINTPOINT

建設・土木現場で行なわれる、「リスク管理」の手法

明示的にリスクを書き出し、それに対する対策を書く。

担当者の名前必須。

テスト期間、大事な日、大きなリスクがある場合、これを行なう。

KYKY （危険予知）ミーティング（危険予知）ミーティング



SKMSは、ナレッジを構造的にまとめます。は、ナレッジを構造的にまとめます。POINTPOINT

SKMS(SKMS( Structured Knowledge Management Structured Knowledge Management System)System)

複数人の頭の中を一気にまとめる

赤、青、黄の付箋紙。

赤＝分類青＝原理・原則黄色＝インスタンス

※資産工学研究所：坂本善博



PMPM からから PFPF へへ



PMPM からから PFPF (( プロジェクト・ファシリテープロジェクト・ファシリテーションション )) へへ

ソフトウェア開発を成功させるために。– 行動を起こさせるために。– ひとりひとりの能力を最大限に発揮させるために。– 個人の総和以上の価値をチームとして発揮するために。

エンジニアとして、よりよい人生の時間をすごすために。（ Quality of Engineering Life: QoEL 　の向上 )– 気づきを得るために。– 仕事の中で、プロジェクトを越えて続く人間関係を得るために。– やりがいと笑顔と信頼関係で、プロジェクトに取り組むために。

QCD から QCD + SM(Safety, Morale) へPF は、ソフトウェア開発を成功させ、あなたの人生の質を向上させます。は、ソフトウェア開発を成功させ、あなたの人生の質を向上させます。POINTPOINT



PFPF の５つの価値の５つの価値コミュニケーションコミュニケーション

– 必要な人と、必要を感じたときすぐ、対面で話をしていますか？ – チームとして個人の総和以上の成果を上げるために、「コミュニケーション」を価値と

します。行動行動

– あなたの言葉に、行動はともなっていますか？– 価値を現実のものとするために、そして気づきを得るために、「行動」を価値とします

。気づき気づき

– 今日、何かに気づきましたか？気づきを、毎日誰かに話していますか？– 個人そしてチームが成長するために、「気づき」を価値とします。

信頼関係信頼関係– あなたはチームのメンバーを信頼していますか？チームのメンバーはあなたを信頼して

いますか？– 行動を起こす勇気の源として、「信頼関係」を価値とします。

笑顔笑顔– 人からの非難をおそれてびくびくしていませんか？冗談を言える雰囲気はありますか？

今日、みんなの笑顔は見えますか？– 人生の貴重な時間を楽しくすごすために、「笑顔」を価値とします。



PFPF の５つの原則の５つの原則見える化 (Management by sight) リズム (Rhythm) 名前（ Name and Conquer ）初めよければすべてよし (Early Victory) 問題対私たちの構図

(Problem vs. us)You vs. Me の構図 You vs. Us の構図

問題 vs. Us の構図問題 vs. Us の構図



PFPF の実践（プラクティス）の実践（プラクティス）

朝会朝会バーンダウンバーンダウンかんばんかんばん。。。。などなど、考え中。。。。。。。。などなど、考え中。。。。





PFPF についてドキュメントを公開についてドキュメントを公開（予定）（予定）

http://http://www.www.ObjectClub.jp/ObjectClub.jp/からメルマガにてお知らせしますからメルマガにてお知らせします

◆ 　『プロジェクト・ファシリテーション価値＆原則編』◆ 　『プロジェクト・ファシリテーション実践編：朝会ガイド』◆ 『プロジェクト・ファシリテーション実践編：バーンダウンガイド』　　　　　　　　。。。◆ 『プロジェクト・ファシリテーションツール編』



WWithout ithout PPractice, ractice,

NNo o EEmergencemergence

－　道元



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



ご質問をどうぞご質問をどうぞ

Q & A

Business

Visualizing Software Development