PowerPoint Presentation

Size: px

Start display at page:

Download "PowerPoint Presentation"

かずしさわまつ
4 years ago
Views:

1 Software Engineering Center Information-technology Promotion Agency, Japan プロセス改善におけるプロセスアセスメントの適用 IPA ソフトウェアエンジニアリングセンター北野敏明 Center 1

2 プロセス改善とはプロセス改善とは, よいと信じる方向に自分達の仕事のやり方を変えていくこと事業目標よいと信じる方向どう仕事を進めるか導出改善のゴール ( 結果系 ) プロセスゴール ( 要因系 ) 検証検証創出見直し改善計画 ( これからの ) 自分達の仕事の仕方入力策定アセスメントゴール検証アセスメント結果 Center 2

3 プロセスアセスメントとは自分達の仕事のやり方がどの程度の能力があるかを診断するという, いわば自分達の仕事のやり方の健康診断健康診断は 1 回受診すれば済むものではない定期的に診断をしてそのときの体の状態を調べるものプロセスの能力診断も同じプロセス能力診断を実施するための一つのツールとしてプロセスアセスメントがある例えば CMMI SPEAK IPA AutomotiveSPICE Center 3

4 SPEAK が誕生するまで SPEAK 誕生までの歴史は一向に根付かないソフトウェア品質保証への挑戦の歴史ユーザとしての豊富な経験知見を持っていると同時にユーザゆえの我が儘な文化もソフトウェア事業に持ち込んでしまったソフトの修正はいつでもできる仕様書なんか書かなくてももの ( ソフトウェア ) はできる Center 4

SPEAK IPA 版への道のりハードウェア ( 半導体 PC/FC プロッタ etc) 撤退 -1995 年 EFRAME 初版発行共通フレーム 94 をベースにこれまでの一貫開発方法論を再構築共通フレーム 98 へ SLCP 適用の事例として国内で唯一公開 ( 共通フレーム 98 に採録 ) パッケージビジネスの時流に乗る 2001 年 11~12 月第二次 ISO9001(2000

5 SPEAK IPA 版への道のりハードウェア ( 半導体 PC/FC プロッタ etc) 撤退年 EFRAME 初版発行共通フレーム 94 をベースにこれまでの一貫開発方法論を再構築共通フレーム 98 へ SLCP 適用の事例として国内で唯一公開 ( 共通フレーム 98 に採録 ) パッケージビジネスの時流に乗る 2001 年 11~12 月第二次 ISO9001(2000 年版 ) 取得ブーム 1996 年 6 月 ~1998 年 7 月第一次 ISO9001(94 年版 ) 取得ブーム年 SPEAK Ver.1.0 リリースプロセス改善活動のツールとして ISO/IEC TR と両立性を持った SPA モデルの開発年事業統合により新日鉄ソリューションズ発足 SQC 部発足 : 新日鉄 EI 事業部 ENICOM の持つ資産の整理年 ERAME-SX 発行 (ISO/IEC Amd.1 対応 ) 年 SPEAK Ver.2.0 リリース ISO/IEC Part2 の IS 版発行にともない適合 SPA モデルとして SPEAK Ver.2.0 開発 ISO9001 取得ブーム官公庁入札要件としての ISO9001 認証取得不採算 Project の増加による収益減年 SPEAK Ver.3.0 リリース対象プロセスの拡張プラクティスの整理年 SPEAK IPA 版リリース IPA/ より汎化したモデルとして 9 月に公表 Center 5

6 開発の背景 ISO9001 認証取得をはじめとした現場のやらされ感からの脱却国内外でソフトウェアプロセス改善 ( 特にCMM / CMMI) の注目度がアップ顧客からの調達の要件として客観的な開発能力の証明が求められるケースが増加良い ( 品質の ) 製品は良いプロセスから生まれるという認識の定着人と技術だけではプロジェクトの成功に結びつかないこともある安定した製品の供給にはプロセスの安定が必要 Center 6

7 開発の方針 1. 所見自分達のソフトウェアプロセスの現状を把握するためのツールで (SWOR) の重視能力水準およびプロセス属性の評定結果について厳密性あることを最大の目標とする!? を求めない ( 評定ルールの簡素化 ) 2. ISO/IEC 国際標準に準拠して客観的尺度で診断できるようにし独りよ ISO/IEC 12207Amd.1への適合自己宣言ならびに第三者検証の実施がりの診断や改善にならないようにする 3. 運用プロセスユーザビリティプロセスは適用範囲外としいくつかソフトウェア開発保守における重要プロセスを絞ってモデルをのプロセスは他のプロセスや能力軸へ対応付ける作成する 4. 平易なモデル記述自己診断に使えることを考慮し使い易さを追求する ( モデル要素対応表 ) アセスメントシートの利用 5. フォーマルなアセスメントを指向した第フォーマルな診断を行うためモデル手法と専門家でない人が 2 部 ( ) 第 5 部 ( ) と ( 自己診断を行うためのモデル手法を提供する簡易な ) 自己アセスメントを指向した第 4 部の提供 6. 第 ISO/IEC 5 部 ( 標準アセスメントモデル Part5のモデルは抽象的で使いにくいので内 ) ではプラクティス実施特性の記述第 4 容を具体化したモデルを作成する部 ( 軽量アセスメントモデル ) ではプラクティスの平易な解説具体的に利用可能な技術の例示 Center 7

SPEAK のプロセス能力水準 (ISO/IEC 15504 Part2) 5. 最適化 4. 予測可能最適化しているプロセスプロセス革新プロセス最適化 1. 実施 2. 管理 3.

8 SPEAK のプロセス能力水準 (ISO/IEC Part2) 5. 最適化 4. 予測可能最適化しているプロセスプロセス革新プロセス最適化 1. 実施 2. 管理 3. 確立管理されたプロセス実施管理作業生産物管理確立されたプロセスプロセス定義プロセス展開予測可能なプロセスプロセス計測プロセス制御 0. 未実施実施されたプロセスプロセス実行不完全なプロセス Center 8

9 主要なアウトプット ( プロファイル ) 各能力水準はプロセス属性に細分してプロセスの達成度を評価するプロセス属性プロセス ID プロセス名称能力水準目標 / 診断結果実施された管理された確立された予測可能な最適化している PA PA PA PA PA PA PA PA PA P.3.1 要求事項抽出 2 目標診断結果 P.3.5 ソフトウェア設計 3 目標診断結果 S.2 構成管理 0 目標診断結果 O.1.3 プロジェクト管理 2 目標診断結果 1 目標診断結果目標 : 充分に達成ほとんど達成設定しない対象外診断結果 : 充分に達成ほとんど達成部分的に達成達成してない対象外 Center 9

10 主要なアウトプット ( 所見 ) プロファイルに現れない観察結果 (SWOR) を記述する所見 P.3.5 ソフトウェア設計 < 強み > という限定されたソフトウェアパッケージを利用したシステム構築においてはパッケージベンダ提供のシステムアーキテクチャの上にアプリケーションを構築するための設計の作業範囲作業成果物の範囲を理解している明文化されてはいないがプロセスの目標が定量的に捕らえられており当該組織のプロセス計画の標準になっている < 弱み > 作業成果物の検証基準が明確になっておらず検証実施者の力量に依存している作業成果物の変更管理構成管理について制御の要求事項が定義されていないそのため例えば変更依頼があっても詳細設計書については明確な修正指示がでない修正されたか確認していないなど作業成果物の制御の実施が確実になっていない < リスク > に特化した組織であるがゆえ今回アセスメント対象とした規模のプロジェクトを繰り返し実施するのであれば大きなプロセスの変更は必要ないがシステムアーキテクチャがパッケージベンダから提供されているためシステムアーキテクチャ設計ソフトウェアアーキテクチャ設計といった構造設計を実施していないまたパッケージ案件では決まりきっていることは作業や作業成果物から省略される ( 作業担当者の頭にある ) ため本来のソフトウェア開発の作業や作業成果物で必要とするものを実施作成していないことがある < 改善の機会 > 設計の一貫性検証が可能になるように要求や要件の基準線を確立維持管理し設計プロセスにおける検証で要求の基準線に対する設計の一貫性を検証可能にする S.2 構成管理プロセス < 強み > 実施に先立って構成管理で行う作業と構成品目管理責任者の役割を決めているバージョン管理台帳で最新の成果物が管理され変更や修正のための管理手順 ( フロー ) も決めている SWOR: 強み (S) 弱み (W) 改善の機会 (O) リスク (R) Center 10

11 アセッサに必要な能力 (1) ソフトウェアプロセス面での能力対象プロセスのソフトウェア開発管理保守の経験と知識プロマネを評価できるレベルの知識アセスメント面での能力 SPEAK の構成手順規格の正確な理解テキパキ進行シッカリ確認ハッキリ判定個人的属性面での能力意思疎通能力外交的慎重根気判断力と指導力一貫性親密さ Center 11

12 アセッサに必要な能力 (2) アセッサは高い能力が必要なので育成は簡単ではないがアセスメントをできるくらいの人でないとプロセスの改善は難しい組織的に改善の裾野を広げるために教育 / 訓練が必要研修アセッサ養成研修 (6.0 日 ) 講義 ( 演習含む )2.0 日 + 模擬アセスメント演習 4.0 日研修ソフトウェアアセスメント基礎講座 (0.5 日 ) アセスメント事前説明会としてもアセスメント受診組織に対して実施 Center 12

13 SPEAK をやってみて ~ プロセス改善にまつわる誤解 ~ アセスメントを受診することがプロセス改善である受診後に組織が如何にプロセスを変えていくかが重要であるアセスメントは社の標準をどれだけ忠実に守っているかどうかの監査であるアセスメントで見るのは物作りの過程 (= プロセス ) であり開発方法論や標準はプロセスの実現もしくは定着のための手段として副次的に捉える標準化は組織の画一化 / 官僚化を招く成熟度が高いプロセスとは技術や環境の変化に追従して進化できるプロセスのこと標準書を作っても見ないし維持が大変標準あるいはツールが本当に役立っているかを監視し手直ししていく継続的活動こそが改善であり標準化は改善の一つの手段でしかない組織全体でひとつの標準プロセスに従わなければならない組織のビジネスの形態や対象とするプロセスの範囲に合った標準プロセスを持つべきであり無理に 1 つに合わせようとするのは本末転倒 Center 13

14 SPEAK をやってみて今できているから ( 問題になっていないから ) への対処リスク管理の弱さをどう克服するかコミットメントのない活動はボランティア活動継続性の保証はどうする? SPEAK アセッサ能力の維持ペーパーアセッサをどう活かしていくか? 資格はとったけれどプロセス改善活動関係者のモチベーション維持 ( うまく ) できて当たり前をどう評価してくれる? うまくいってしまうとそれがあたかも当たり前にできることであって改善活動の成果 ( 活動推進者の努力 ) が周囲から認められない Center 14

15 SPEAK をやってみて ~ うまくいく改善いかない改善 ~ 身の丈に合わないプロセス変更はインパクトが大きすぎて挫折してしまう大事なことはビジネス戦略 / ゴールに沿ったロードマップを作ること Center 15

16 SPEAK IPA 版は普及するのか SPEAK IPA 版を開発公開したけれど一企業で運用してきたモデル手法は他のソフトウェア企業でも適用できるだろうか? CMM や CMMI と比べてどうなの? これから改善を始めようとしている企業組織で実際に改善に取り組めるだけのものが揃っているか? だったら他のソフトウェア企業 ( 組織 ) でも実際に使ってもらい使い勝手を検証しよう!! プロセス改善の実証実験アセッサの育成 ( 教育の実施 ) アセスメント実施の支援アセスメント結果からのプロセス改善計画の立案の支援その結果は Center 16

untitle

untitle ISO/IEC 15504 と SPEAK IPA 版の解説 2008 年 11 月 25 日 TIS 株式会社室谷隆経済産業省プロセス改善研究部会 WG1 委員 ( 独 )IPA ソフトウェアエンジニアリングセンター ISO/IEC 15504 (JIS X0145) ) とはプロセス改善と能力判定のためのアセスメント体系を規定する国際標準アウトソーシングオフショアサプライチェーンプロセス能力を議論するための会社間