Movatterモバイル変換

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Movatterモバイル変換

Change Language

Visualizing Software Development

Embed presentation

Recommended

More Related Content

What's hot

Viewers also liked

Similar to Visualizing Software Development

More from Kenji Hiranabe

Recently uploaded

Visualizing Software Development