Comments
Description
Transcript
住友電工における Agile(Scrum)の試行・評価
SEC セミナー 住友電工における Agile(Scrum)の試行・評価 住友電気工業株式会社 情報システム部 中村 伸裕 2012.10.24 Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. Agenda １．会社紹介 ２．Agile(Scrum) 導入の背景と狙い ３．Agile(Scrum) の適用 ４．Agile(Scrum) の試行結果 ５．Agile(Scrum) の評価 Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. １．住友電気工業と情報システム Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. 1.1 会社概要 商 号 住友電気工業株式会社 創 業 １８９７年（明治３０年） 資本金 ９９７億円 社 長 松本 正義 連 結 従業員 １８２，７７３人 グループ 連結対象会社 ３２５社 （国内１２４社、海外２０１社） 業 績 連結売上高 ２兆３３８億円 連結営業利益 １０３８億円 （２０１１年３月末現在） Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.4 Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.5 1.3 製品 銅荒引線 合成ダイヤモンド単結晶 スミクリスタル® ワイヤーハーネス 多心光ファイバケーブル フレキシブルプリント回路 40Gbit/s伝送用光トランシーバ 超硬工具 イゲタロイ® Ingenious Dynamics 純緑色半導体レーザ Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.6 1.4 住友電気工業(SEI)の組織図 電 線 事 業・ 機 本材 部・ エ ネ ル ギ ー ((事業部門)) 情 エ 報 レ 事 事ク 通 業 業ト 信 本 本ロ ・ 部シ 部ニ ク ス ス テ ム <営業本部> 自 動 車 事 業 本 部 産 業 素 材 事 業 本 部 ((研究開発部門)) 材料技術研究開発本部 情報通信研究開発 本部 Ｎ パ 解 自 エ 半 Ｅ ワ 析 動 レ 導 Ｎ パ 情 光 伝 Ｘ ー 技 車 ク 体 Ｅ ワ 報 通 送 Ｔ シ ト Ｘ ー 通 信 デ セ ス 術 技 ロ 技 Ｔ シ ン テ 研 術 ニ 術 セ ス 信 研 バ タ ム 究 研 ク 研 ン テ 研 究 イ ー 研 セ 究 ス 究 タ ム 究 所 ス ・ ン 研 ー 研 所 究 タ 所 材 所 究 料 所 ー 究 所 研 所 究 所 ((コーポレートスタッフ部門)) 法務部・広報部・人事総務部・人材開発部・安全環境部・経理部・財務部・経営企画部・ 情報システム部・資材部・物流管理部・生産技術部・品質管理部・知財部・貿易管理室 等 Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.7 1.5 情報システム部門の体制 住友電工 情報システム部 ・システム企画 ・情報技術(IT) 住友電工 情報システム(株) 設計、開発 運用、保守 Ingenious Dynamics 事 業 部 協 力 会 社 事 業 部 協 力 会 社 事 業 部 事 業 部 ・・・ ・・・ Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.8 1.6 オープン化への取り組み 年度 OS 方式 IBM S370 NEC ACOS ～８０ ホスト集中処理 ８１～９０ 汎用機分散設置 ９１～９４ 分散処理（telnet） ９５～９６ ＵＮＩＸ Ｃ／Ｓ ９７～９８ ９９～０４ ０５～０６ IBM 4300 NEC ACOS Windows NT Webシステム Linux 言語 COBOL Informix-4GL Developer2000 Cold Fusion IMS ADBS DB2,DL/I ADBS Informix Oracle Oracle, DB2 Java / Tomcat Linux + Xen ０６～ ＤＢ PostgreSQL ポイント： ・新規開発のシステムは、全社同一プラットフォーム ・比較的小さい規模で再構築する為、全ＰＪ同一プロセスで開発 Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.9 1.7 ＱＣＤ改善の取り組み 1991 1994 1997 1999 2001 2003 2007 2011 Informix-4GL用 ジェネレータの開発 T字形ER手法の導入 （DOA導入） ファンクションポイントの導入 楽々Framework の開発 (View, Controller) システム開発プロセス改善 （CMM） 楽々Framework II の開発 組立型開発の開始 統計的品質管理（ＳＱＣ） 品質予測モデル確立 Ingenious Dynamics 開発フェーズ 生産性 30%UP 外部設計～結合テスト生産 性 30%UP 計測方法の見直し UI Component Struts相当の部品 CMMレベル３を達成 （2003年４月） 業務用コンポーネント ５００種類以上 CMMI レベル３達成 (2007/7) CMMI レベル５達成 (2011/6) Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.10 1.8 組織の強み 核となる技術を組織全体で定着化 管理図の導入 (2007 ～) 品質制御技術 統計的品質管理 楽々Framework II （適用率: 100%） （適用率: 100%） 要件定義のあいまいさと 内部矛盾を排除 (1994～) Ingenious Dynamics 再利用技術 要件定義技術 Ｔ字形ＥＲ手法 開発量の大幅削減を 実現 (2003～) Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.11 1.9 他社との生産性比較 当日のみ SEC『データ白書 2010-2011』 との比較 スクリーンをご覧下さい Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.12 ２．Agile(Scrum)試行の背景と狙い Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. ２．１ Agile（アジャイル）の現状 「顧客満足を最優先し、価値あるソフトウェアを早く継続的に提供します」 「アジャイルソフトウェア開発宣言 アジャイルソフトウェア開発の原則」より アジャイルが欧米の競争力に繋がっている（IPA/SEC報告書） CMMI, PMBOK, BABOK 等のモデルもアジャイル対応が進んでいる 海外におけるアジャイル普及状況 Scrumが全体の 70%を占める →日本では請負契約の問題で広まっていない（米国では 準委任契約が主体） 引用元 「非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査報告書」ＩＰＡ Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.14 ２．２ Ａｇｉｌｅ導入の目的 １．システムの価値を最大化 システム開発の費用と期間を固定し システムの価値を最大化 ２．開発者のモチベーション向上 自立的な活動 ３．開発者の能力向上 開発者全員が計画、監視、制御、外部設計に関わることで能力が向上する ４．改善活動の定着化 ５．QCDの評価 品質： 悪化しないのか コスト：繰返し開発による手戻り量 納期：「顧客満足を最優先し、価値あるソフトウェアを早く継続的に提供」 Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.15 ３．Agile(Scrum)の適用 Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. ３．１ Scrum（スクラム）とは •プロダクト開発の管理に使用されてきた プロセスフレームワーク •スクラムの特徴： ①軽量 ②理解が容易 ③習得は非常に困難 スクラム マスター ＳＭ プロダクト オーナー ＰＯ 上長（課長、部長） 開発チーム ５～９名 ユーザー スプリント 計画ミーティング Ｐａｒｔ１ （１～２時間） スプリント（２～４週間） Ｐａｒｔ２ （２～４時間） スプリント ゴール プロダクト バックログ スプリント バックログ スプリント レビュー スプリント レトロ スペクティブ （１～２時間） （１～２時間） デイリー スクラム （１５分／日） バーンダウン チャート プロダクト 繰り返し Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.17 ３．２ 試行ＰＪの概要 他ＰＪとの 掛け持ち ２名 新人 ２名 スクラム マスター ＳＭ プロダクト オーナー ＰＯ •基幹系システム二次PJ（派生型開発） •開発規模：約２８人月 •１スプリント２週間 × ６スプリント •ユーザ：システム部門 時短勤務 ２名 開発チーム ６名（＋ＳＭ） 開発チーム ６名（＋ＳＭ） スプリント 計画ミーティング Ｐａｒｔ１ （１～２時間） ユーザー 兼上長 スプリント（２週間） Ｐａｒｔ２ （２～４時間） スプリント ゴール プロダクト バックログ スプリント バックログ スプリント レビュー スプリント レトロ スペクティブ （１～２時間） （１～２時間） デイリー スクラム （１５分／日） バーンダウン チャート プロダクト 繰り返し Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.18 ３．３ プロダクトバックログ スクラム マスター ＳＭ プロダクト オーナー ＰＯ 開発チーム ６名（＋ＳＭ） 開発チーム ６名（＋ＳＭ） スプリント 計画ミーティング Ｐａｒｔ１ （１～２時間） ユーザー 兼上長 スプリント（２週間） Ｐａｒｔ２ （２～４時間） スプリント ゴール プロダクト バックログ スプリント バックログ スプリント レビュー スプリント レトロ スペクティブ （１～２時間） （１～２時間） デイリー スクラム （１５分／日） バーンダウン チャート プロダクト 繰り返し Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.19 ３．３ プロダクトバックログ Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.20 ３．４ スプリント計画ミーティング スクラム マスター ＳＭ プロダクト オーナー ＰＯ 開発チーム ６名（＋ＳＭ） 開発チーム ６名（＋ＳＭ） スプリント 計画ミーティング Ｐａｒｔ１ （１～２時間） ユーザー 兼上長 スプリント（２週間） Ｐａｒｔ２ （２～４時間） スプリント ゴール プロダクト バックログ スプリント バックログ スプリント レビュー スプリント レトロ スペクティブ （１～２時間） （１～２時間） デイリー スクラム （１５分／日） バーンダウン チャート プロダクト 繰り返し Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.21 ３．４ スプリント計画ミーティング マニュアルでは２～４Ｈだったが 実際は倍近くかかっていた スプリント計画ミーティング Ｐａｒｔ１ （１Ｈ） Ｐａｒｔ２・・・基本的にはメンバーのみ（ＰＯは必要に応じて参加） （４～８Ｈ） ＰＯより説明 イメージ 合わせ 概算見積 ゴールの 決定 スプリント バックログ作成 説明を受けたプロダクトバックログより 今回、開発できる機能を選択 ※優先度の高いものから取り組み Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.22 ３．５ スプリントバックログ スクラム マスター ＳＭ プロダクト オーナー ＰＯ 開発チーム ６名（＋ＳＭ） 開発チーム ６名（＋ＳＭ） スプリント 計画ミーティング Ｐａｒｔ１ （１～２時間） ユーザー 兼上長 スプリント（２週間） Ｐａｒｔ２ （２～４時間） スプリント ゴール プロダクト バックログ スプリント バックログ スプリント レビュー スプリント レトロ スペクティブ （１～２時間） （１～２時間） デイリー スクラム （１５分／日） バーンダウン チャート プロダクト 繰り返し Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.23 ３．５ スプリントバックログ Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.24 ３．６ バーンダウンチャート スクラム マスター ＳＭ プロダクト オーナー ＰＯ 開発チーム ６名（＋ＳＭ） 開発チーム ６名（＋ＳＭ） スプリント 計画ミーティング Ｐａｒｔ１ （１～２時間） ユーザー 兼上長 スプリント（２週間） Ｐａｒｔ２ （２～４時間） スプリント ゴール プロダクト バックログ スプリント バックログ スプリント レビュー スプリント レトロ スペクティブ （１～２時間） （１～２時間） デイリー スクラム （１５分／日） バーンダウン チャート プロダクト 繰り返し Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.25 ３．６ バーンダウンチャート ～部外者にもわかる進捗管理～ 失敗 大変 よくできました 「着地」 タスクを計画通りにやりきること Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.26 ３．７ デイリースクラム スクラム マスター ＳＭ プロダクト オーナー ＰＯ 開発チーム ６名（＋ＳＭ） 開発チーム ６名（＋ＳＭ） スプリント 計画ミーティング Ｐａｒｔ１ （１～２時間） ユーザー 兼上長 スプリント（２週間） Ｐａｒｔ２ （２～４時間） スプリント ゴール プロダクト バックログ スプリント バックログ スプリント レビュー スプリント レトロ スペクティブ （１～２時間） （１～２時間） デイリー スクラム （１５分／日） バーンダウン チャート プロダクト 繰り返し Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.27 ３．７ デイリースクラム ～日々の監視と制御～ 当日のみ スクリーンをご覧下さい Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.28 ３．８ スプリントレビュー スクラム マスター ＳＭ プロダクト オーナー ＰＯ 開発チーム ６名（＋ＳＭ） 開発チーム ６名（＋ＳＭ） スプリント 計画ミーティング Ｐａｒｔ１ （１～２時間） ユーザー 兼上長 スプリント（２週間） Ｐａｒｔ２ （２～４時間） スプリント ゴール プロダクト バックログ スプリント バックログ スプリント レビュー スプリント レトロ スペクティブ （１～２時間） （１～２時間） デイリー スクラム （１５分／日） バーンダウン チャート プロダクト 繰り返し Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.29 ３．８ スプリントレビュー ～結果報告とデモ～ メンバー プロダクトオーナー、スクラムマスター、チームメンバー ユーザ兼上長 通常はユーザ部門の利用者も参加する 実施 １時間程度で以下の内容を実施 （参加者は状況に応じて判断） ※今回は情報システム部門で利用するシ ステム スプリント結果報告 ゴールの達成状況、バーンダウンチャート、品質レポート デモと質疑応答 「デモ」することはとても重要視されている プロダクトオーナーによる完了判定 →改善要望はプロダクトバックログへ うまくいったこと、問題点、解決方法（レトロスペクティブの前に） スプリントレビューだけがプロジェクトトレースの場 これ以外はチームの邪魔をしてはいけない Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.30 ３．９ スプリントレトロスペクティブ 状況に応じて スクラム マスター ＳＭ プロダクト オーナー ＰＯ 開発チーム ６名（＋ＳＭ） 開発チーム ６名（＋ＳＭ） スプリント 計画ミーティング Ｐａｒｔ１ （１～２時間） ユーザー 兼上長 スプリント（２週間） Ｐａｒｔ２ （２～４時間） スプリント ゴール プロダクト バックログ スプリント バックログ スプリント レビュー スプリント レトロ スペクティブ （１～２時間） （１～２時間） デイリー スクラム （１５分／日） バーンダウン チャート プロダクト 繰り返し Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.31 ３．９ スプリントレトロスペクティブ ～振り返りと改善の機会 当日のみ まず良かった点から振り返る メンバー１人ずつ順番に話す Keep Try 次に問題点を振り返る 次へのＴｒｙは 問題の対策だけなく 継続すべき良かった事も あげる（定着するまで） Problem Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.32 ３．１０ 次のスプリントへ スクラム マスター ＳＭ プロダクト オーナー ＰＯ 開発チーム ６名（＋ＳＭ） 開発チーム ６名（＋ＳＭ） スプリント 計画ミーティング Ｐａｒｔ１ （１～２時間） ユーザー 兼上長 スプリント（２週間） Ｐａｒｔ２ （２～４時間） スプリント ゴール プロダクト バックログ スプリント バックログ スプリント レビュー スプリント レトロ スペクティブ （１～２時間） （１～２時間） デイリー スクラム （１５分／日） バーンダウン チャート プロダクト 繰り返し Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.33 ４．Agile(Scrum)の試行結果 Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. ４．１ スクラムの実施 ～着地までの道のり～ 第１スプリント 約90Hタスク残 ・計画甘い 第３スプリント 第２スプリント 失敗 約60Hタスク残 失敗 ・計画外のタスク発生 ・遅れのトレース不足 •投入予定の見直し （スプリント期間中の各日の 投入予定工数を積上げ） •タスク毎に責任者の明確化 初めての着地！ 成功 ・20%バッファの活用 ・デイリースクラムでの トレース有効 •予定工数の80%で計画 （20%はバッファ） •デイリースクラムで遅れトレース スプリントレトロスペクティブ（メンバー自身の振り返り） これでうまくいくと思ったが・・・ Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.35 ４．２ スクラムの実施 ～再び着地を目指して～ 作業残 第４スプリント 約60Hタスク残 作業残 第５スプリント 約25Hタスク残 作業残 第６スプリント １日遅れ 第７スプリント 第８スプリント成功 着地！ ・事前の仕様検討 ・残り２回の準備期間 ・開発はしない （小改善のみ実施） ・UT検収強化 ITシナリオ減(いじわるテスト増) 第９スプリント 成功 着地！ ・８ｽﾌﾟﾘﾝﾄでの仕様準備 ・PG開発の進捗チェック •要件を理解する期間を確保 スプリント 設計 スプリント 開発 設計 事前に要件の理解と 設計に着手しておく ようやくわかってきた チームも成長してきた 開発 チームはもっと 成長できる スプリントレトロスペクティブ Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.36 ４．３ ９スプリントの結果 第１スプリント 約90Hタスク残 リリース 失敗 ・計画甘い 第２スプリント 約60Hタスク残 リリース 失敗 ・計画外のタスク発生 ・遅れのトレース不足 第４スプリント 成功 約60Hタスク残 作業残 ・メンバー入れ替えの オーバーヘッド？ 第７スプリント ・残り２回の準備期間 ・開発はしない （小改善のみ実施） Ingenious Dynamics 第３スプリント 成功 初めての着地！ ・20%バッファの活用 ・デイリースクラムでの トレース有効 成功 第５スプリント 約25Hタスク残 作業残 ・もうちょっとなのに 成功 第６スプリント 成功 着地したが１日超過 作業残 ・成功と言えなくも ないが・・・ 第８スプリント 成功 着地！ ・事前の仕様検討 ・UT検収強化 ITシナリオ減(いじわるテスト増) 終了 （予算100%消化） 第９スプリント 成功 着地！ ・８ｽﾌﾟﾘﾝﾄでの仕様準備 ・PG開発の進捗チェック Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.37 ５．Agile(Scrum)の評価 Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. ４．Agile試行の評価 ～Ａｇｉｌｅ導入の目的に対して～ 確認したかったポイント １．システムの価値を最大化 システム開発の費用と期間を固定し システムの価値を最大化 ２ モチベーション ２．開発者のモチベーション向上 自立的な活動 ３．開発者の能力向上 開発者全員が計画、監視、制御、外部設計に関わることで能力が向上する ４．改善活動の定着化 ５．QCDの評価 品質：JUAS報告によるとウォーターホール型開発よりバグ数１．５倍 コスト：繰返し開発による手戻り量 納期：「顧客満足を最優先し、価値あるソフトウェアを早く継続的に提供」 Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.39 ４．１ システムの価値を最大化 ★本ＰＪに現れた現象★ ・議論の時間が増える （計画時に20%のバッファ確保） ・ＩＴフェーズでも機能追加 ・設計リードタイムは1/2 ・設計コストは２倍 ・ホワイトボードで設計 （イメージ合わせ） →直ぐにダメと指摘できる スプリント毎の価値の最大化 ユーザの要求を 実現する脳 複数名が１つの 設計に参加する →複数のアイデアが出る ２ モチベーション チーム全員 ＋ ５Ｈ／機能 アジャイル型 価値観×価値観 １人のＳＥ ＋ＰＭ・ＰＬのレビュー １つの価値観 １４Ｈ／機能 機能に対する 価値を高めている ウォーターフォール型 １０Ｈ／機能 外部設計 Ingenious Dynamics 動くものができることによって さらに設計アイデアが出る →設計時間をより多くかける 基本設計 ＰＧ開発 Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. ＩＴ ユーザの要求を 実現する時間 P.40 ４．１ システムの価値を最大化 機能別に見る価値の最大化 「スプリント毎の価値の最大化」 →より価値を高める 機能の価値 ２ モチベーション 「繰り返し開発による価値の最大化」 →より価値のある機能を選択し開発する １ ２ ３ ４ ５ ６ ７ ８ ９ １０ システムを構成する機能 機能 さほど価値（効果）の高くない機能 Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.41 ４．２ モチベーションの評価 メンバー７名にアンケート スクラム開発について 「従来のウォーターフォール型と比べてどうです か？」 ２ モチベーション ← とても やや どちらともいえない やや とても → 良い |---------○--------+---------+---------| 悪い 面白い |--------○---------+---------+---------| 面白くない やる気がでる |---------+-○------+---------+---------| やる気がない 効率的 |---------+----○---+---------+---------| 非効率 効果的 |---------+-○------+---------+---------| 非効果的 スクラムを続けたいか？ ← とても やや どちらともいえない やや とても → 続けたい |--------○---------+---------+---------| 続けたくない なぜ好印象をもってもらえたのだろう？ Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.42 参考文献 「仕事が楽しくなる！２５のルール」 大林伸安,ダイヤモンド社 ４．２ モチベーションの評価 仕事が楽しくなる５つのキーワード スクラムのルール 充実感 「ありがとう」といってもらえる仕事 ２ モチベーション 使命感 「なぜ、何のために」がわかっている仕事 達成感 「ゴール」が見える仕事 スプリントレビュー ユーザ（ＰＯ）から直接フィードバック Ｓ計画ミーティング①など ユーザ（ＰＯ）と直接コミュニケーション スプリントゴール スプリント期間 成長実感 「昨日より今日が」前進している仕事 一体感 「おめでとう」が言い合える仕事 レトロスペクティブ バーンダウンチャートの 着地をみんなで喜ぶ アンケート結果 •要求変更をエーッと思いながら も取り込めた •１次開発ではＰＧ担当でなぜは わかってなかったが２次開発では 要求を理解しながら取り組めた •１次に比べて機能が充実した •機能設計で細かい事にこだわ らない、ゴールを重視 •機能設計するときに目的を意 識するようになった •Ｔｒｙに対する結果が２週間後に 出る •メンバーみんなで目標に向 かってやっていけた •相談しやすい •自主的に他の人のタスクを引 き取る ・仕事が楽しくなるポイントを押さえているスクラムのルール ・アンケート結果も対応 Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.43 ４．３ 開発者の能力向上 開発者の能力 ベテラン 中堅 若手 ２ モチベーション ＰＪ管理能力 （計画・監視・制御） 外部設計能力 プログラミング能力 － 統合テスト能力 Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.44 ４．４ 改善活動の定着化 ～レトロスペクティブのTry～ ス プ リ ン ト 改善の分 類 計画 ① ② 投入予定 時間を積上 80%で計画 ③ ④ 予定工数の ⑤ ⑥ ⑦ ２ モチベーション 要求・仕様を 理解する 期間の確保 遅れﾘｽﾄで ﾄﾚｰｽ 設計開発 全員で ｲﾒｰｼﾞ合わせ コミュニ ケーション 打合せ中に ﾀｲﾑｷｰﾊﾟｰ ⑨ 日別人別 投入計画 PG完了 前半/後半 予定日の意識 計画 後半に回しても いいタスク 進捗 ⑧ PG開発 タスクの細分化 とトレース UTｴﾋﾞﾃﾞﾝｽ 作成指示 プログラム 構造図の記述 若手２名の 指導 外部ﾁｰﾑとの 調整は前倒しで ﾎﾜｲﾄﾎﾞｰﾄﾞに 見たﾁｪｯｸ欄 ・スプリントが終わる度にレトロスペクティブを実施 ・一人一人が必ず発言するので自ずと改善意識が高まる ・次の２週間ですぐ実践できる Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.45 ４．５ QCDの評価 Ｑ：品質 時間あたりの欠陥作り込み（ＰＧ開発） →組織標準より約２０％多い 規模あたりの流出欠陥（リリース後３ヶ月）→組織標準より約１５％少ない ２ モチベーション 欠陥作り込みは多いが流出はむしろ少ない Ｃ：コスト 生産性 規模（ＦＰ値）あたりの開発工数 →組織標準とほぼ同じ ※但し、今回は計測したのは機能拡張ＦＰ値（派生開発型） 組織標準はアプリケーションＦＰあたりの標準工数なので 厳密な比較ではない （機能拡張ＦＰでの標準工数は規定無い） 厳密な比較はできていないが、さほど悪くならない Ｄ：納期 約２週間毎に対象機能を確実にリリース 動くソフトを継続的にリリースできた Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.46 ４．６ Agile試行の評価 まとめ Agile試行 評価項目 結果 １．システムの価値を最大化 ◎ ２．開発者のモチベーション向上 ◎ ３．開発者の能力向上 ◎ ４．改善活動の定着化 ◎ ５．QCDの評価 △ ◎：効果がとても認められる △：効果はあまり認められないが悪くなることもない Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.47 ＣＭＭＩモデル適用のウォーターフォール型プロセス 補足.AgileScrum試行における従来プロセス資産の活用度 評価項目 従来プロセス資産の活用度 開発者モチベーション C M M I の プ ロ セ ス エ リ ア プロセ ス 管理 PJ管 理 エンジ ニアリ ング 支援 × 従来のCMMIではモチベーションに関するPAはない OPD,OT, OPM 組織プロセス定義,組織トレー ニング,組織実績管理 － OPF 組織プロセス重視 △ レトロスペクティブでなぜなぜ分析を実施 OPP 組織プロセス実績 ◎ 組織ベースライン、ｕ管理図（工数ベース）活用 QPM 定量的プロジェクト管理 ◎ PP,PMC, IPM プロジェクト計画、監視と制御、 統合プロジェクト管理 × SAM 供給者合意管理 － RSKM リスク管理 × コスト超過・納期遅延のリスク小 REQM 要件管理 ○ 業務要件の理解→画面設計の技術は同じ RD 要件開発 ○ TS,PI 技術解,成果物統合 ◎ VER,VAL 検証,妥当性確認 ◎ MA,CM 測定と分析,構成管理 ◎ PPQA プロセスの成果物と品質保証 － 試行ＰＪだったのでSQA検証など実施せず DAR 決定分析と解決 ○ チーム開発による複数案 CAR 原因分析と解決 － Ingenious Dynamics アジャイルではスプリントバックログ、バーンダウン チャート、デイリースクラムなど活用 ウォーターフォールとほぼ同じ Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.48 補足．開発メンバーからの提言 ～アジャイルを取り組む方へ～ 開発チームは一箇所集中 １日最低５時間のコアタイム確保 ※コアタイム＝全員が揃っている時間 本ＰＪでは実質３時間（10:00～14:00） 時短メンバー、他PJとの掛け持ちメンバーおり実質はもっと少なく コミュニケーションロスが多かったという声 メンバー構成 コミュニケーションが最大の効果を生む ＰＪルーム、席を集めるなど（７人でも席が端と端だと効率落ちるという声も） 打合せを頻繁に行うので他の人に気兼ねなくできるスペースが望ましい 少なくとも、ウォーターホールの各工程をできる人が集まっている事 設計だけできる人のチーム、ＰＧだけできる人のチームでは何もリリースできない 期間が短いのでフレ幅が小さく安定して開発できる人 （＝自己品質管理ができる人）が理想 チームワーク 与えられた仕事をだけをやるスタンスではダメ チームの達成すべきゴールを理解し、 それに対して自分がどういう貢献できるか という取り組みが必要 Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved. P.49 The END Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All rights reserved.