Automotive SPICE 3.0 実践ガイドブック入門編の読み進めです。
自分向けのノートとして記録します。
#1 概要
##1-1 誕生の経緯と動向
開発体制の多様化
⇒✖技術者同士の阿吽の呼吸
〇共通言語での根拠の共有
ISO26262 システムの故障、誤作動での危険を回避するための要求をまとめている。
##1-2 改善活動の基本的考え方
###改善活動のマネジメントのためのPDCAサイクル
- PDCAサイクル
改善活動が事業目標と紐づくことが前提⇒でないと経営層と管理層の理解を得られない。
改善活動のPDCAには⇒運営の責任者による「目標の周知」、「リソース提供」といったインフラの確率が必要。
- 改善活動PDCA
- 改善目標設定（定量的）
- 現状把握
- 分析した弱みに対する改善策（全ての弱みに対処しなくてもよい）
- 改善目標設定（定量的）
改善策をパイロット実施し、効果を確かめる。
OKなら組織標準プロセスを定義する。
- 作業タスク
- 手順
- 適用技術・ツール
- 必要スキル・役割
以上を整理する。測定の尺度も定義すること。
改善策を試行したら、測定データから有効性を検証する。
###段階的な目標設定の考え方
関係者の慣れ・学習を想定して
グループ ⇒ プロジェクト ⇒ 小組織 ⇒ 大組織 と段階的な目標を設定する。
また逆方向で、
組織の目標を想定して ⇒ 中間目標を立て ⇒ プロジェクトレベルの活動を始める。
###プロジェクトレベルの改善
目標とリソースのギャップ⇒設計方法の見直し、テストの効率化
###組織レベルの改善
各プロジェクトの改善内容を展開する。
【注意】メンバーに改善活動の経験がないと、展開された標準プロセスの意味が理解できない。
プロセス実績を蓄積する。
###事業レベルの改善
実績データの分析から。
車載システム開発における改善活動
失敗事例を参考として、改善活動の勘所を説明。
失敗事例とその要因
- プロジェクトはSPICEの目標レベルを達成したが、メンバーが意味を感じていない。
- メンバーがプロセス改善の横展開の必要性を感じていない。
- 何のための、誰のための改善かの理解がされていない。
失敗の共通要因
■改善目的と手段の入れ替わり「SPICEの能力レベルを達成する！」
能力レベルを達成する！ではなく、あくまで「日程遅延を少なくする」、「コストを低減する」といった具体的な目標で改善活動を実施しないとメンバーに達成感がわかない。
■改善活動の範囲がパイロット（改善対象として初めに実施される）プロジェクトに限定されている。
プロジェクト限定で言われたことだけをやればいい。⇒横展開ができない。
改善に対する期待
- プロジェクトメンバー層の改善活動への期待
- 技術者自身が成長する？
- 上手くいった達成感が得られるか？
- 納得する評価が得られるか？
- 管理者層の改善活動への期待
- 部門がかかえる課題を意識している？
- 個人のノウハウを集合知として共有できている？
- 複数のプロジェクトの状況を一元的に管理できている？
- 経営層の改善活動への期待
- 顧客満足度はあがるのか？
- 部門間が協調して相乗効果が出るのか？
- 経営判断のスピード、競争力が向上するのか？
著者が推奨するアプローチ
切っ掛けの大半は取引先からの要求。⇒組織力強化の機会ととらえる。
■中長期の段階的な目標設定（管理者層の責任）
- ステージ１：開発の基礎力強化
- プロセスモデルに基づいた標準プロセスの構築と展開
- プロセス改善活動を通して、改善基盤を構築
- 「成果」：初めて構築した標準プロセス、改善活動の経験蓄積
- 納期の問題もあって、後継プロジェクトには適用しやすいが、横展開にはリスクがある。
- ステージ２：組織力＆組織運営力強化（事業部）：本書対象外
- モノづくりの土台を構築し、組織力を強化
- マネジメントサイクルを構築し、継続的製品価値を生み出す組織力を強化
- 指標、データ収集、分析の仕組み
- 開発対象の製品に必要な人材リソース、アーキテクチャ、手法を体系化する。
- 「成果」：ノウハウが自然とたまる、活用できる標準プロセスができる。
- ステージ３：企業競争力強化（全社）：本書対象外
- カイゼンの定着から、企業文化の形成と企業成長を継続させる。
- 必要に応じてカイゼンの革新