Developer's Summit 2005

1. ソフトウェア開発の「見える化」 平鍋 健児 永和システムマネジメント 主席コンサルタント 4-D-5 開発プロセス

2. 今日お話したいこと 自己紹介、私が思う現在のソフトウェア開発の問題点 リーンソフトウェア開発（簡単に） ソフトウェア開発の「見える化」とは ? 「見える化」手法の実例をお見せします ! PM から、 PF( プロジェクトファシリテーション ) へ 『リーンソフトウェア開発』、特にソフトウェアの「見える化」を中心に話します。 POINT

3. 自己紹介 ㈱永和システムマネジメント 本社は福井県福井市， 200 名 金融・医療・オブジェクト指向を使ったシステム開発 2002 年より品川に東京支社 平鍋健児 リアルタイム， CAD 、オブジェクト指向の実践 UML エディタ JUDE の開発 オブジェクト倶楽部主宰 アジャイルプロセス協議会、副会長 XP-jp メーリングリスト主宰 翻訳、 XP 関連書籍、『リーンソフトウェア開発』 本日は、福井から来ました。 POINT http://jude.esm.jp/

4. 現在のソフトウェアの問題（顧客） Standish group study report in 2000 chaos report 早期に仕様を決定しようとすると，要求仕様が膨らみムダが多くなる POINT

5. 現在のソフトウェアの問題（開発） ビジネスの変化が速い 「狙え，打て」では当たらない． 個性を持った人間を，交換可能な人的リソースとして扱うことが開発現場から不人気 実際の開発現場では「できる人」におんぶ． 一般プロジェクト管理とソフトウェアプロジェクト管理が違うことは，みんな気付いている． 顧客満足は工数やコード行数と関係が薄い プロセスが，読まれないドキュメントづくりとすりかわる ビジネス変化に対応する，人間ベースのソフトウェア開発手法が必要 POINT

6. リーン ソフトウェア 開発 L ean S oftware D evelopment ( 簡単に )

7. 『リーンソフトウェア開発』とは アジャイル開発方法論の１つ。 アジャイル＝変化に対応する開発手法 XP/Scrum/FDD/DSDM/Crystal/ASD など 2003 年、 Mary/Tom Poppendieck が共著。 製造業の「リーン生産方式」 ( トヨタ生産方式を含む ) をソフトウェアに置き換えたもの。 アジャイル開発方法論がなぜうまくいくのかを、 XP は、実践とプログラマーの視点からパラダイムシフトとして書いた。 ASD は、複雑系の理論によって解き明かした。 LSD は、生産革新で実証済みの考え方の延長とマッピングさせた。 リーンソフトウェア開発は、リーン生産方式の言葉でアジャイルを説明したもの POINT

8. 書籍が出ています Agile Software Development Conference 2004, 2005 (Salt Lake City, USA) で著者と仲良くなりました。 詳しくは書籍にて… POINT

9. リーン思考の 7 つの原則 ムダを排除する ムダ、とは顧客にとっての価値を付加しないもの、すべてである。ソフトウェア開発における７つのムダ（未完成作業のムダ、余分なプロセスのムダ、余分な機能のムダ、タスク切り替えのムダ、待ちのムダ、移動のムダ、欠陥のムダ）を発見し、ムダを排除しよう。 学習効果を高める ソフトウェア開発プロセスは、繰り返し可能な「生産」ではなく、常に「発見」を繰り返す「学習活動」である。この学習プロセスを機能させるために、活動を見える化し、フィードバックを得ながら自己を改善していく仕組みを作ろう。 決定をできるだけ遅らせる 不確定要素が多い場合、確実な情報を元に決定を下せるように、「オプション」を維持したままで前進することを許容しよう。このためには、システムに変更可能性を組み込んでおくことが戦略的に重要である。 できるだけ速く提供する 「完璧主義」に陥らず、とにかく早く提供する。顧客からフィードバックを得ることで、発見と学習のサイクルが生まれる。このためにも、顧客からのプル型で開発を進めよう。 チームに権限委譲する 現場の開発者が、 100% の力を出せるようにする。中央集権で管理しようとしてはいけない。自発的な決定ができるようにチームをエンパワーする。見える化の手法をうまく使って、チームが自分の意思で状態を確認しながら前進できるようにしよう。 統一性を作りこむ 統一性が感じられるシステムには、一貫したビジョンと思想がある。これはプロセスや手順で作ることができない。リーダシップとコミュニケーションが、統一性の源泉となる。 全体を見る 部分最適に陥ってはならない。個人や一組織のパフォーマンスのみで評価すると、部分最適が起こってしまう。一つ上のレベルで評価するようにし、個人や組織の協調が生み出されるようにしよう。 ７つの原則が、プロセスを編み出すためのガイドライン。見える化が裏テーマ POINT 見える化

10. ムダを認識する トヨタ生産方式の「７つのムダ」とソフトウェア開発をマッピング まずムダを認識。顧客価値に結びつかない、「すべて」がムダ。 POINT 欠陥（バグ）を作るムダ 不良を作るムダ 移動のムダ 動作のムダ 待ちのムダ 手待ちのムダ タスク切り替えのムダ 運搬のムダ 余分な機能のムダ 作りすぎのムダ 余分なプロセスのムダ 加工そのもののムダ 未完成の作業のムダ 在庫のムダ ソフトウェア開発の７つのムダ 生産工程の７つのムダ

11. ムダの見える化＝バリューストリームマップ 「価値の流れ」を時間軸上に表したもの 要望 提出 プロジェクト承認 要件 収集 顧客 承認 分析 設計 設計 レビュー 実装 テスト 導入 「流れ」に注目し、ムダを発見する。ムダを排除するためのツール。 POINT

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

13. Moving Target 要求 R(t) システム S(t) 開発チーム (t) R(t) S(t) Δ Δ t 不明確かつ不安定な要求。 見えなければ、制御できない。適応できない。カイゼンできない。 POINT

14. 見える化の例 情報がパッとわかる 「現在の状態」も、「結果」もわかる ソフトウェア開発で使える、見える化手法のヒントは、まだたくさんある。 POINT

15. よく聞く現場の声（ SE 侍バージョン） プロジェクトは遅れているということだが、自分は今日何をすればよいのか分からない。 （開発者） 何が問題か？ 現在の状態が見えていないのではないか？ POINT 次の週はきっと９２％ですから！残念！ 切腹！ 設計が９０％完了のまま、２週間同じ報告が続いている。 （マネジャ ) って言うじゃな ~ い？ PM （プロジェクトマネジメント）が重要です。数値化し、計画との差異でマネジメントするのです。 ( 取締役）

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

17. 見えなければ行動ができない 進捗どう見せる？ 何で測る？ 日々の作業はどうやって自発的に？ 異常はどうやって検出する？ どうやって改善の行動を生み出す？ 見える化の手法、おみせしましょう！ POINT

18. バーンダウンチャート 進捗の見える化 バーンダウン 中間成果物で は計測しない。 受け入れテスト を通過した要求 数でカウント。 メールでエクセルシート を配布しない バーンダウンチャートの例 全体進捗の見える化は、「バーンダウンチャート」で行なう。 POINT

19. ソフトウェアの一個流し プッシュ型の生産は在庫のムダを増やす。 要求を一個流し。テストで進捗管理。 プル型で、生産指示を行なう（かんばん）。 プル型によって、在庫を最小に減らしつつ、変化に対応した管理が行なえる。 POINT 工程１ 顧客 情報（指示）の流れ 工程２ 工程３ 受け入れテスト 生産物（価値）の流れ

20. ソフトウェアかんばん 作業の見える化 ToDo( 未実施 ) Doing( 実施中 ) Done( テスト完 ) で管理。 各自の作業を指示しなく ても、毎朝自発的に 作業開始。 ソフトウェアかんばんの例 ※ バーンダウンチャーなどと共に、とにかく、壁に貼る。「情報発信器」とも呼ばれる。 作業の見える化は、「ソフトウェアかんばん」で行なう。 POINT

21. 朝会 作業の明確化 自発的なサインアップ ソフトウェアかんばんの前 で、行なう。 朝の仕事はじめが重要！ スタンドアップで１５分． 朝会の例 毎朝、「ソフトウェアかんばん」の前で全員で短い会議を行なう。 POINT

22. ソフトウェアあんどん 異常の見える化 全受け入れテストを自動化。 毎時バッチで流す。 失敗があれば、即時表示。 原因追及。 欠陥のムダを排除。 自働化とあんどんに対応 ソフトウェアあんどんの例 異常の見える化は、「ソフトウェアあんどん」で行なう。（受け入れテストを回帰） POINT ※ 欠陥のムダ＝欠陥の大きさ × プロセス中の滞在時間

23. 見える目標 目標の見える化 なにか形になるもの で目標をしめし、 達成感を味わう。 プロジェクトキックオフで注目を得て、偶像化する。 グラフや、数値でもよい。 目に入ることが重要。 選挙でおなじみのダルマ 目標を全員で共有しよう。 POINT ※ ダルマの目には、開始と終了がある。

24. ペアボード ペアの討議内容の見える化 UML などを使って、 二人の討議を見える化。 議論が空中戦になるのを避ける。 他の人を巻き込みやすくする。 ノートを捨てる。（蓄積⇒表現） 記録は、必要ならそのままコピー！ ペアボードの例 ペアの討議内容を、ボードにして見える化。ノートでなくボードで。 POINT

25. 色つき UML ソフトウェア内部構造の見える化 UML を使って、全員が意識する 構造（アーキテクチャ、 モデル）を貼り出す。 手書きでもよい。 色をうまく使う。 図の前で議論が始まる。 ソフトウェア内部構造の UML 例 構造の見える化は、 「色つき UML 」 で行なう。厳密でなくてよい。手書きでよい。 POINT

26. ふりかえり (1) カイゼンの気づき Keep( 良い点 ) Problem( 悪い点 ) Try( 次回挑戦 ) を出す。 全員で意見を出し、 暗黙知の共同化と 形式知化を行なう。 ふりかえりシートの例 カイゼンの見える化は、「ふりかえりシート」で得る。 POINT

27. ふりかえり (2) Keep/Problem/Try （ KPT ） Keep は定着する。 Problem は Try を生み出す。 Try は、 Keep か Problem に 移動する。 日本語で書くと、 継続実施 / 問題点 / 解決案 良かった点 / 悪かった点 / やってみること 継続 / 不満 / 努力 （け・ぷ・と） ふりかえりシートの例 イテレーション毎に「ふりかえり」を繰り返すことでプロセスが改善される。 POINT Keep Problem Try 新しい問題！ 新しいアイディア！ 解決法 やってみて うまく行った うまく行かない 定着

28. ふりかえり (3) プロジェクトやリリースの回顧 タイムライン プロジェクトを時間軸で振り返る。 個々人の物語をチームの物語として表現 青＝喜び 赤＝怒り 黄＝驚き 感情によって思い出を引き出す。 プロジェクト終了のヒーリング、カタリシス、次のプロジェクトへの勇気

29. 見えなければ行動ができない とにかく、 「壁に貼れ」 (Excel シートのメールでは見えない） 進捗は 「バーンダウン」 で。 日々の作業は 「ソフトウェアかんばん」 で。 「朝会」 を行い、作業を自発的に宣言。 異常は 「ソフトウェアあんどん」 で。 「見える目標」 を置いて。 「ペアボード」 でその場で話し合いながら。 重要なモデルやアーキテクチャは 「色つき UML 」 で。 イテレーション毎に 「ふりかえり」 を。 見える化は、行動をうみだす第一歩。 POINT

30. 全体構成 要求 タスク タスク タスク タスク 見える目標 テスト・ペアプロ・ リファクタリング 計画 イテレーション開発 ふりかえり 朝会、かんばん バーンダウン あんどん ペアボード Keep/Problem/Try 色つき UML 半日 半日 一日の繰り返し １週間

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

32. その他の試行中のツール マインドマップ KY ミーティング SKMS

33. マインドマップ 頭の中の見える化 中心に話題をおいて 放射状にキーワードを書く。 すばやいノート術として 自己紹介として どちらかというと、 ブレインストーム アイディア書き出し アウトライン などの発散系ツール マインドマップの例 頭の中は、「マインドマップ」で見える化。 POINT

34. 建設・土木現場で行なわれる、「リスク管理」の手法 明示的にリスクを書き出し、それに対する対策を書く。 担当者の名前必須。 テスト期間、大事な日、大きなリスクがある場合、これを行なう。 KY （危険予知）ミーティング 朝会で、リスクの確認を POINT

35. SKMS( Structured Knowledge Management System) 複数人の頭の中を 一気にまとめる 赤、青、黄の 付箋紙。 赤＝分類 青＝原理・原則 黄色＝インスタンス SKMS は、ナレッジを構造的にまとめます。 POINT ※ 資産工学研究所：坂本善博

36. PM から PF へ

37. PM から PF ( プロジェクト・ファシリテーション ) へ ソフトウェア開発を成功させるために。 行動を起こさせるために。 ひとりひとりの能力を最大限に発揮させるために。 個人の総和以上の価値をチームとして発揮するために。 エンジニアとして、よりよい人生の時間をすごすために。 （ Quality of Engineering Life: QoEL の向上 ) 気づきを得るために。 仕事の中で、プロジェクトを越えて続く人間関係を得るために。 やりがいと笑顔と信頼関係で、プロジェクトに取り組むために。 QCD から QCD + SM(Safety, Morale) へ PF は、ソフトウェア開発を成功させ、あなたの人生の質を向上させます。 POINT

38. PF の５つの価値 コミュニケーション 必要な人と、必要を感じたときすぐ、対面で話をしていますか？ チームとして個人の総和以上の成果を上げるために、「コミュニケーション」を価値とします。 行動 あなたの言葉に、行動はともなっていますか？ 価値を現実のものとするために、そして気づきを得るために、「行動」を価値とします。 気づき 今日、何かに気づきましたか？気づきを、毎日誰かに話していますか？ 個人そしてチームが成長するために、「気づき」を価値とします。 信頼関係 あなたはチームのメンバーを信頼していますか？チームのメンバーはあなたを信頼していますか？ 行動を起こす勇気の源として、「信頼関係」を価値とします。 笑顔 人からの非難をおそれてびくびくしていませんか？冗談を言える雰囲気はありますか？今日、みんなの笑顔は見えますか？ 人生の貴重な時間を楽しくすごすために、「笑顔」を価値とします。

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

40. PF の実践（プラクティス） 朝会 バーンダウン かんばん 。。。。などなど、考え中。。。。

42. PF についてドキュメントを公開（予定） http:// www. ObjectClub.jp/ からメルマガにてお知らせします ◆ 『プロジェクト・ファシリテーション価値＆原則編』 ◆ 『プロジェクト・ファシリテーション実践編：朝会ガイド』 ◆ 『プロジェクト・ファシリテーション実践編：バーンダウンガイド』 。。。 ◆ 『プロジェクト・ファシリテーションツール編』

43. W ithout P ractice, N o E mergence － 道元

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

45. ご質問をどうぞ Q & A