$for$MOST$ WCOS の利用方法5 新しい授業の追加 • コミュニティからWCOS ツールをクリックすると、WCOS ツール が利用できます。$ 1. $「新しい授業を追加」をクリック
管理&改善らくらくパッケージの 部門展開事例 ·...
Transcript of 管理&改善らくらくパッケージの 部門展開事例 ·...
© 2012 Toshiba Corporation
管理&改善らくらくパッケージの 部門展開事例
〜即効性もあり中長期的にも効果のある プロセス改善の取り組み〜
2012年10月11日 東芝セミコンダクター&ストレージ社
システムソフトウエアセンター 岸 利至
Rev1.0
2 © 2012 Toshiba Corporation
製品の一例 東芝S&S社 製品群
ディスクリート半導体
汎用CMOSロジック/小信号デバイス/
パワーデバイス/オプトデバイス
ロジックLSI マルチメディアSoC/カスタムSoC
メモリ フラッシュメモリ/MCP(Multi
Chip Package)
東芝セミコンダクター&ストレージ社のご紹介
ストレージプロダクツ SSD/HDD
アナログ・イメージングIC
アナログIC/CMOSイメージセンサ
/マイコン
3 © 2012 Toshiba Corporation
カンパニーSPIチームとソフトウェア関係組織関連図
品質
信頼性
部門
カンパニー SPIチーム
SW開発PJ
社内SPI会議
統括技師長
カンパニー
品質部門
品質技師長
(SWC)
東芝全社
SPI
全社SPI委員会
部門SPI
メンバ
SW開発PJ
部門SPI
メンバ SW開発PJ
部門SPI
メンバ
• 部門SPIの支援 • 開発部門の直接支援 • 品質保証部門との連携 • 東芝全社との連携
4 © 2012 Toshiba Corporation
もくじ
「管理」&「改善」軽量化パッケージの開発と部門展開
1. 背景:過去の活動から
2. パッケージ開発
3. 部門への展開
4. 効果と考察
2002 2004 2006 2008 2010 2012
SPI 活動
先行部門
パッケージ
後続 部門
トップダウン プロジェクト管理支援
初期プロセスセット
プロジェクト改善試行
開発
パック展開
1.背景:過去の活動から
2.パッケージ開発
3.部門への展開
4.効果と考察
5 © 2012 Toshiba Corporation
1.背景:過去の活動から
「管理」&「改善」軽量化パッケージの開発と部門展開
1. 背景:過去の活動から
2. パッケージ開発
3. 部門への展開
4. 効果と考察
2002 2004 2006 2008 2010 2012
SPI 活動
先行部門
パッケージ
後続 部門
トップダウン プロジェクト管理支援
初期プロセスセット
プロジェクト改善試行
開発
パック展開
1.背景:過去の活動から
1.背景:過去の活動から
6 © 2012 Toshiba Corporation
活動初期:トップダウン
2002年~2004年
トップダウンアプローチでプロセス展開
CMMでいうレベル3相当の仕組み構築をめざし、下記を作成して開発者に展開
SW-CMMレベル3相当の部門規定
開発のやり方をわかりやすくまとめたハンドブック、ガイド
帳票作成のためのテンプレート、記載実例
マイルストーン管理ツールで文書の承認を行いながら開発を進める癖
SW-CMMレベル3相当の各種プロセス教育
開発者のやらされ感、丌満などはあったものの、これらは継続して活用&定着
1.背景:過去の活動から
7 © 2012 Toshiba Corporation
活動中期:個別プロジェクト支援 2005年~2010年
景気の悪化、リーマンショック → 活動縮小
SPI人員削減
プロジェクト直接支援中心の作業
→ 直接支援を繰り返すうちに、大枠でプロジェクトの支援手順は、下記の4ステップから成っている事を発見。
1. PJ状況把握
2. 把握した状況を見える化
3. 状況と問題を共有
4. 問題に対する対策
このパターンで支援をすると問題解決していく
1.背景:過去の活動から
8 © 2012 Toshiba Corporation
何を見えるようにすると良いのか?
現実に終わると思われる日(完了見込み)が示されると、初めて本気で対策を検討し始める。
納期までに「何ができるのか」を考えるためには、「できないこと」がどのくらいなのかを全員で共有して、目をそむけずに対策を検討することができて、初めてプロジェクトは加速し始める。
状況が把握できず完了見込みが示せない QCDが達成できるかわからない 「がんばれ」しか言えない
管理がなされていない
できない量を明確にして、 完了見込みを示し続ける
どのぐらいできないかがわかる 目標としたQCDとのすりあわせができる 具体的な対策が検討できる。
管理がなされている
1.背景:過去の活動から
9 © 2012 Toshiba Corporation
構想&試運用
構想:「できない量を明確にして、完了見込みを示し続ける」方法について検討
redmineでバグの管理はしている。 → 作業タスクについても同様に管理できないか
タスクの消化数を計測する事で、完了見込みを示すことはできないか
試運用
2004年までに作り上げた帳票類と教育を適用し、簡単な導入説明資料でキックオフを行うことから始め、構想を実プロジェクトに試運用を行い、試行錯誤を繰り返しながら、パッケージの原型を作っていった。
1.背景:過去の活動から
10 © 2012 Toshiba Corporation
2.パッケージ開発
「管理」&「改善」軽量化パッケージの開発と部門展開
1. 背景:過去の活動から
2. パッケージ開発
3. 部門への展開
4. 効果と考察
2002 2004 2006 2008 2010 2012
SPI 活動
先行部門
パッケージ
後続 部門
トップダウン プロジェクト管理支援
初期プロセスセット
プロジェクト改善試行
開発
パック展開
2.パッケージ開発
2.パッケージ開発
11 © 2012 Toshiba Corporation
パッケージ構成検討
構想のパッケージ化を検討
作りこみの活動に人をアサイン
3本柱
仕組み
教育
サポート
軽量化パック
プロセス、管理手法、ツール
SPI支援、PJ管理支援
PJ管理教育、プロセス教育
見込みを 示し続ける
プロジェクト マネジメント
2.パッケージ開発
12 © 2012 Toshiba Corporation
仕組みとは:A)標準プロセス
仕組みとしては下記3つ
A) 標準プロセス
B) 開発管理手法
C) ツール
A) 標準プロセス
規定、テンプレート、ガイド
活動初期のころに作成したSW-CMMのレベル3相当のものが既にあり、記載実例もある。
この部分については、特に新たな活動は必要なし
2.パッケージ開発
仕組み
13 © 2012 Toshiba Corporation
仕組みとは:B)開発管理手法
B) 開発管理手法
問題のあるプロジェクトの支援手順の4つのステップを短期にタイムリに実行しながら、毎週のリズムを決めて開発を進めることができる手法を取り入れた。
作業タスクをredmine上で管理し、タスクの消化数で開発速度やできなかったタスクをコントロールするような管理の手法を取り入れた。
2.パッケージ開発
イテレーション2 イテレーション1 イテレーション3
リリース
リリース1 リリース2 リリース3
仕組み
14 © 2012 Toshiba Corporation
仕組みとは:C)ツール
C) ツール
タスク管理ツール:redmine
構成管理ツール:subversion
可視化ツール:自製ツール
Redmine、subversionについてはツールを触るというレベルではできていたので、あとは
適切なプロセス
チームで決められたルールに沿って開発を進める
状況を見えるようにするための仕掛け
をすることがSPIチームとしての、キーとなる活動。
2.パッケージ開発
仕組み
15 © 2012 Toshiba Corporation
成果物
不具合
工数
作業進捗
既設サーバ・ツール利用
Web表示 可視化ツール
チケット管理ツール
(Redmine等)
DR/Gate
進捗
マイルストーン
管理ツール
(自製ツール)
部門サーバ
共通DB
共通メトリクス
• データを自動収集
• 状況をWeb上でグラフ表示
• 定期的にステータスレポート
新たなツールの
導入コスト不要
集約表示&誰でもいつでも気軽にチェック
構成管理ツール
(Subversion等)
データ収集
省力化
自動収集
・過去の類似PJデータの参照が容易
・現在の複数PJデータの俯瞰、集計が容易
仕組みとは:C)ツール:可視化 2.パッケージ開発
仕組み
リスク見える化
設計見える化
テスト見える化
実装見える化
バグ見える化
PJ情報見える化
作業見える化
16 © 2012 Toshiba Corporation
仕組みとは:C)ツール:分析改善ガイド(抜粋)
TOSHIBA CONFIDENTIAL
No 表示イメージ 活用例
開発
計画
設計
実装
テス
ト
出荷
後上
級管
理者
/SQ
Aプ
ロジ
ェク
トリ
ーダ
担当
活用時期 活用対象者
2.6.1 バグ件数と改修件数の推移【バグ対応状況の確認】
バグ件数とその改修推移を確認することで、バグ収束やバグ改修を視覚的に判断することができます。DR/Gate日程予実などと照らし合わせて確認することによって、不具合収束と改修が、あるマイルストーンに間に合うかの判断にも利用できます。→ DR/Gate日程の確認は、「2.1.1 プロジェクト情報」で行うことができます。
- - - ○ - - ○ -
2.6.4 バグ滞留日数ヒストグラム【チケット優先度付け支援】
バクの滞留日数区間のチケット数を確認することで、滞留日数が大きいチケットがどのくらいあるのかを視覚的に判断することができます。また、滞留日数が大きいチケットに絞り込むことにより、チケットの優先度付けを行うことができます。→ チケット別の滞留日数については、各チケットへ展開した、「2.4.6 チケット別のバグ滞留日数」で確認することができます。
- - - ○ - - ○ ○
活用時期 活用対象者
いわゆる、バグ曲線。棒グラフは差分。バグの推移は落ち着いていないなぁ。ここ最近バグ改修が追い付いて来ている様子。
滞留日数が大きいものから内容を確認して、不具合の修正を加速させよう!!
改修のフォローについては、バグの滞留日数の多いものから対策すると効果的です。→ バグの滞留日数の確認は、「2.6.4 バグ滞留日数ヒストグラム」で行うことができます。
バグ発生状況、収束状況 バグ発生と修正の乖離
この部分は強調して見せたい!
PJ進捗状況
全体傾向
2.パッケージ開発
グラフの
どのあたりを
見ればよいか
グラフの目的、
分析方法、
改善例などを
わかりやすく説明
どの工程で
活用するのか
仕組み
17 © 2012 Toshiba Corporation
教育とは
まずは教育により、全員の意識共有、知識共有、基盤技術の底上げ!
SPIチームが既に提供しているプロセス教育の中から、最も基本的な3種類の講座をパックに入れる必要がある
開発プロセス基礎教育(基本)
プロジェクト管理関連教育(ヒトとコトの管理)
構成管理関連教育(モノの管理)
•今回追加で必要だったのはプロジェクト管理関連の教育
•PMPの資格を持っていてプロジェクト管理について詳しい人がSPIメンバとして参加
2.パッケージ開発
ヒト
コト モノ
教育
18 © 2012 Toshiba Corporation
教育とは:プロジェクト管理教育体系
導入(e-learning)
製品開発とプロジェクト管理
一般教養(e-learning)
管理技術基礎 1~7章
実践入門教育(座学)
初級者のためのプロジェクト管理
実践詳細教育(e-learning)
計画と進捗管理実践
グループ討議(座学)
プロジェクト事例検討
初級者 管理者 上級者 中級者 PJL経験:0~1回 PJL経験:2回以上 PJL経験:複数回
管理人数: ~3人程度 管理人数 :数十人規模 管理人数: ~10人程度
基礎
入門
詳細
発展
GPM、SM、...
実践
導入
管理人数 :数十人規模
必要性の
再認識
基礎概念
の共有
勘所を
知る
知識向上に
応える
事例と経験
に学ぶ
プロジェクト管理の...
2.パッケージ開発
教育
19 © 2012 Toshiba Corporation 19
教育とは:教育メニューと受講対象者
計画と進捗管理実践(e-Learning + コンサル)
担当者 全体リーダ サブリーダ
プロパ
駐在担当者
主任、マネージャ
プロセス管理
プロジェクト管理
構成管理
初級者のプロジェクトマネージメント教育(座学)
ソフトウェア開発のQMS基礎(プロセスの必要性と詳細) (e-Learning)
ソフトウェア開発のメトリクス基礎教育(e-Learning)
構成管理教育(座学)
構成管理ツール教育 (e-Learning + コンサル)
プロジェクト管理(導入編)教育(e-Learning)
プロジェクト管理(基礎編)教育 (e-Learning)
2.パッケージ開発
パッケージに入れる教育メニューと受講対象者の目安を決めた
教育
20 © 2012 Toshiba Corporation
サポートとは:
サポートする時に必要なモノとして、
らくらくパックメニュー
らくらくパック展開手順説明資料
kizashi(可視化ツール)構築と設定ガイド
プロジェクト管理、構成管理、プロセス開発、教育実施時の各導入(キックオフ)資料。
サポートに必要な各種ガイドとテンプレート。
(担当一覧表テンプレート、構成管理計画作成ガイド、チケットによるプロジェクト管理ガイド、教育受講管理テンプレート)
を作りこんだ。
俗人的な要素があるので、最低限の成果物を準備
2.パッケージ開発
サポート
21 © 2012 Toshiba Corporation
軽量化パックメニュー
開発プロジェクトを運営するために最低限必要な環境/仕組みと育成のパッケージ
1.準備/計画立案 ・ システム導入計画案 ・ 体制案 ・ 展開スケジュール案 ・ 予算計画 ・ 関係者への説明 2.教育 ・ プロジェクト管理 ・ ツール操作 ・ プロセス ・ 構成管理
3.実践 ・ 規定、テンプレート、ガイド、ルール作成支援 ・ ツール構築と設定支援 ・ オンジョブ実践支援 (タスク管理、構成管理、プロジェクト 管理者支援) ・ 定期的なフィードバック 4.結果分析/報告 ・ 実践結果の定量的分析、報告、評価 5.改善検討/提案 ・ 評価を元に改善策検討/提案 ・ 次回の目標設定
2.パッケージ開発
22 © 2012 Toshiba Corporation
3.部門への展開
「管理」&「改善」軽量化パッケージの開発と部門展開
1. 背景:過去の活動から
2. パッケージ開発
3. 部門への展開
4. 効果と考察
2002 2004 2006 2008 2010 2012
SPI 活動
先行部門
パッケージ
後続 部門
トップダウン プロジェクト管理支援
初期プロセスセット
プロジェクト改善試行
開発
パック展開
3.部門への展開
3.部門への展開
23 © 2012 Toshiba Corporation
部門への展開:展開部門概要
今回のパッケージを展開した開発部門の概要は下記
組み込み系のファームウェア開発部門
約50~70人規模×3部門 = 約180名
C言語
組織の標準プロセスが整備されているとは限らない
3.部門への展開
24 © 2012 Toshiba Corporation
部門への展開:step0 Step0:立ち上げ準備、底上げ(約一か月でここまで実施)
3.部門への展開
全体スケジュール案の策定
スポンサーに概要説明/予算確保
部門のステークホルダに方針説明/
合意
開発者全員に方針説明/合意
担当設置:教育、SCCB、プロセス、インフラ、PM、可視化
教育計画、場所確保、出席者選定、
受講管理
教育開講/受講 サーバ/ツール設
置計画策定
サーバ手配、構築、ツール設定、ユー
ザ登録、試用
SPI SPI スポンサー SPI 管理層
SPI 開発者 SPI 管理層 SPI 教育担当
SPI 開発者 SPI インフラ担当 インフラ担当
25 © 2012 Toshiba Corporation
部門への展開:step1 3.部門への展開
タスク管理導入説明/イテレーション間
隔、リリース定例日決定
タスク管理導入説明/タスク登録開始、記載内容レビ
ュー
リリース会議:リリース内容、タスク消化率、次リリース計
画策定
リリース会議 リリース会議
構成管理導入説明/構成管理計画書作成
手順説明
構成管理計画書作成
構成管理計画を説明
可視化方針策定/計画
ツール設定
ツール導入説明/使用方法、グラフの見方、分析改善例説
明
現状の開発プロセス調査、まと
め
あるべきプロセスとのギャップ分析、プロセス作成・改善計画
プロセス作成・改善計画を説
明
改善実施
SPI PM担当 SPI 開発者 SPI 開発者 SPI 開発者
SPI SCCB 開発者 SCCB
開発者
SPI SCCB
SPI 可視化担当 SPI SPI 開発者
SPI SPI プロセス担当 プロセス担当 SPI プロセス担当 開発者
繰返 繰返
構成管理を考慮したリリース
データを活用した高度な管理
実運用と照らしながら
プロセス管理
プロジェクト管理
構成管理
可視化管理
26 © 2012 Toshiba Corporation
展開時の苦労
きれいに展開したように書いているが、実際には苦労
プロセスは無くても、いままで俗人的にやっていた文化があり、改善後の姿と現状との違いを示しながら開発者の視点での説明が必要
変えたくないと思われている場合に、説得力やアプローチを変えて説明する臨機応変さが必要
エンジニアリングに入り込んだ話になった時に、理解し、会話ができる程度の知識と実務経験が必要
今後さらなるSPIチームのスキルアップが必要。
3.部門への展開
27 © 2012 Toshiba Corporation
4.効果と考察
「管理」&「改善」軽量化パッケージの開発と部門展開
1. 背景:過去の活動から
2. パッケージ開発
3. 部門への展開
4. 効果と考察
2002 2004 2006 2008 2010 2012
SPI 活動
先行部門
パッケージ
後続 部門
トップダウン プロジェクト管理支援
初期プロセスセット
プロジェクト改善試行
開発
パック展開
4.効果と考察
4.効果と考察
28 © 2012 Toshiba Corporation
4.効果と考察
このように、上級管理者でも理解しやすいプロジェクト管理という側面からのアプローチで、最低限必要なプロセスを抽出し、開発者になじみやすい形で展開を行うための導入パッケージを構築し、部門へ展開した。
即効性
パックが先に準備されていることで、物量の大量投入により一気に制覇するようなやり方で適用することができた。
部門側の意識も含めて一気に変えていく活動を、4か月という短期間で実施することができた。
中長期的効果
先行してパックの原型となるものを実践していたプロジェクトでは、安定してこの方法を実践しつづけており、数年間納期遅れゼロを実現している。(顧客バグもほぼゼロ)
即効性
中長期的効果
4.効果と考察
29 © 2012 Toshiba Corporation
4.効果と考察
今後
このパッケージは、ソフトウエアに依存しない内容になっているため、今後はHW部門や海外ベンダへの展開も視野に入れて活動を検討していく。
可視化ツールで蓄積されたデータを元に、ビジネス上の勝ち負けを定量的に指標にする手法を検討していく。
今後
4.効果と考察
30 © 2012 Toshiba Corporation 30
31 © 2012 Toshiba Corporation 31
以下は参考
32 © 2012 Toshiba Corporation 32
1.改善活動基本方針
改善 ゴール 調査
現状(コト、モノ)の見える化
プロセス管理
ヒアリング
構成管理
Subversionによる
成果物作成状況の確認
成果物確認
動き(ヒト)の見える化
プロジェクト管理
redmineによるタスク消化状況の確認
運用ルール策定、見せ方の工夫
(例:Kizashiによる
自動監視など)
プロセスの最適化
部門共通項目の一元ルール化
グループ固有ルールの明確化
仕組み上のリスク特定
技術スキルの特定
シナジーを発揮できる部門への転換 部門を横断した開
発体制・技術 共通語・共通文化
の発展
技術とルールの最適化
フラグ管理の効率化
派生管理の効率化
テスト効率向上
実現性のある計画の立案
TATがカギとなるビジネス状況への対応 タイムリーな開発 迅速かつ確実なリリ
ース
Q C
D
トレードオフがあるため 同時に連携しながら実施
33 © 2012 Toshiba Corporation 33
目指すアプローチ
メトリクス
進捗みえる化
設計 要件/仕様
コーディング
テスト
バグ 納期
PJ管理
妥当性確認
レビュー/検証
品質管理
構成管理
意思決定
計画
調達管理
エンジニアリング
共通言語
NAND Driver NAND
Controller
SSD
HW DTV
車載 評価
画像認識
音声合成
進捗みえる化
PJ管理
プロセス担当
開発担当
34 © 2012 Toshiba Corporation 34
目指すアプローチ
メトリクス
進捗みえる化
設計 要件/仕様
コーディング
テスト
バグ 納期
PJ管理
妥当性確認
レビュー/検証
品質管理
構成管理
意思決定
計画
調達管理
エンジニアリング
共通言語 進捗みえる化
進捗みえる化
NAND Driver NAND
Controller
SSD
HW DTV
車載 評価
画像認識
音声合成
チームが見える
問題が見える
解決策が見える プロセス担当
開発担当