Software Engineering Center Information-technology Promotion Agency, Japan SEC セミナー 2013 年 2 月 20 日プロセス改善とは ~ 良い成果を得るための変革に向けて ~ 独立行政法人情報処理推進機構 (IPA)

(1)

Information-technology Promotion Agency, Japan

Software

Engineering

Center

独立行政法人情報処理推進機構（IPA）

技術本部ソフトウェア・エンジニアリング・センター（SEC）

ＳＥＣセミナー

プロセス改善とは

～良い成果を得るための変革に向けて～

研究員倉持俊之

2013年 2月20日

(2)

SEC

Software Engineering for Mo･No･Zu･Ku･Ri

セッション内容

１．プロセス改善とは？

２．アセスメントの活用

～アセスメントモデル

SPEAK-IPA～

３．現場が主役のプロセス改善

～

SPINA

3 CH自律改善メソッド～

４．プロセス改善の勘所

（参考）プロセス改善に関するSECBOOKSとツール

(3)

SEC

(4)

SEC

ソフトウェアは社会基盤の一部

(5)

SEC

現状！

(6)

SEC

改善とは？



改善とは？



物事をよい方に改めること。



現状より良い状況にするために、

何かを

変更すること。

プロセス改善ナビゲーションガイド～なぜなに編～ P63より

(7)

SEC

プロセスとは？

プロセス改善ナビゲーションガイド

～なぜなに編～ P3より

(8)

SEC

プロセスに関する標準化動向

ISO/IEC 12207

Systems and software engineering -- Software life cycle processes

ISO/IEC 15288

Systems and software engineering -- System life cycle processes

ISO/IEC 20000-4

Information technology -- Service management -- Part 4: Process reference model

SEC BOOKS 共通フレーム2007 第2版

～経営者，業務部門が参画するシステム開発

および取引のために～

(9)

SEC

プロセスに着目

(10)

SEC

どうして、“プロセス”なのか？

そもそも、ソフトウェアは人が作るもの。

開発者個人の方法や技量だけに頼ってプロジェクトを進めると。。。

役割や責任が不明確なまま作業をすすめてしまう。

→開発分担がきまらないまま、時間だけが経過。

→工程が遅れ、顧客承認を得ないまま設計終了し、プログラミングに着手。

→しかし、テスト工程で設計工程に起因する問題が多発。

→手戻り量が多く、結果的に工期も守れなくなった。

というように、属人的な仕事のやり方では、

● 製品（サービス）の品質（Ｑuality）は、安定しない。

● 納期（Ｄeliver）は、不確実（納期を必ずしも守れない）。

● 結果的に、コスト（Ｃost）は増大する。

⇒ 組織が、顧客に提供する製品（サービス）品質を維持し、または向上させていくため

には、組織の活動基盤となる“プロセス品質”が重要である。

(11)

SEC

プロセス改善が目指すもの

(12)

SEC

プロセス改善へのアプローチは多々あり！

(13)

SEC

２．アセスメントの活用

(14)

SEC

プロセス改善の国際標準化動向



ISO/IEC JTC1/SC7/ＷＧ１０が国際標準化を推進



1992年、ＣＭＭ、ＳＰＩＣＥなど、似て非なるプロセス評価モデル

が乱立する中、プロセス能力レベルの統一基準を制定すべく発足



ソフトウェア組織の有するプロセスの能力レベル及び組織の成熟度

レベルを評価するための枠組みの標準化



ISO/IEC 15504ベースのプロセス評価改善のスキームの整備



国際規格準拠の業界モデルAutomotiveSPICE、SPICE for SPACE等の

策定



欧州を中心にアセッサ育成/認定スキームの整備が進展



車載組込みSW分野では、欧州カーメーカが発注要件化



IPA/SECでは、15504準拠のアセスメントモデルSPEAK-IPA

版を策定

(15)

SEC

ＩＳＯ／ＩＥＣ15504アセスメントモデルの構造

適合したプロセス

アセスメントモデル

プロセス項目（活動）

プロセス参照モデル

・領域及び適用範囲

・プロセス（目的及び成果を含む）

測定の枠組み

・能力水準

・プロセス属性

・評定尺度

能

力

の

尺

度

ISO/IEC12207/AMD.1,AMD.2

(Software life cycle processes)

ISO/IEC15288

(System life cycle processes)

対応付け

対

応

付

け

（連

続

表

現

）

二

次

元

モ

デ

ル

(16)

SEC

水準0

未実施

 不完全なプロセス

ISO/IEC 15504で定める能力水準

水準1

実施

 実施されたプロセス

・プロセス実施

水準2

管理

管理されたプロセス

・実施管理・作業生産物管理

水準3

確立

確立されたプロセス

•プロセス定義 •プロセス展開

水準4

予測可能

 予測可能なプロセス

・プロセス測定・プロセス制御

水準5

最適化

最適化しているプロセス

・プロセス革新・プロセス最適化

(17)

SEC

アセスメントの活用（Ｘ社事例）

背景・目的・ねらい

Ｘ社は、Ｙ社ビジネスに直結するＩＴシステムの一部の保守業

務を

技術支援

業務として長年受託。昨年度までは、技術者が客

先へ常駐し、業務システム保守を客先担当者と共同で実施して

いたが、今年度より顧客からの強い要望から

請負契約

へ変更、

要求分析からソフトウェア結合テスト

までを担当している。

客先での標準プロセスを使用しているが、要求分析(影響範囲

）のもれ、レアケースデータに対しての考慮不足、パフォーマン

スの問題など発生することがある。ＰＪ管理（短工期の）、レビュ

ー、品質保証系プロセスに課題があると思われる。

見積精度を強化したい。最終的には瑕疵コストの削減（但し数

ヶ月後に判明する）半減を目指す。

(18)

SEC

アセスメントの活用（Ｘ社事例）

△キックオフ

△推進教育

◆アセスメント実施

△全社成果報告会

◆アセスメント実施

△・・△・・△アセスメント教育

改善活動

◆アセスメント実施

A事業部

B事業部

改善活動

準備



アセスメント対象プロセス



要求事項抽出（P.3.1）



ソフトウェア要求分析（P.3.4）



ソフトウェアテスト（P.3.8）



問題解決（S.8）

(5日間） (5日間） (4日間）外部アセッサ２名で実施外部アセッサ２名に加え、アセスメント教育受けた社内アセッサ２名がアセスメントに参加Ｘ社でアセスメント教育受けた社内アセッサ３名で実施

(19)

SEC

アセスメントの活用（Ｘ社事例）



活動開始時



プロセス改善への取り組みは、事前に顧客も了承。



実施結果から改善すべき点も顧客へ報告し、協力を依頼。



活動から半年後



当初、他人事と受け取っていた顧客だが、改善提案からの効果

を見て、評価しはじめた。



その後



社内でアセスメントできる要員育成にチャレンジ！



他の案件（保守業務）でのプロセス改善活動を開始

(20)

SEC

SPEAK-IPAの特徴



ISO/IEC 15504に準拠した日本発のモデル



開発の経緯

• 新日鉄ソリューションズ株式会社がSPEAKを開発（第１版：2002年3月） • 社団法人情報サービス産業協会（JISA）がSPINACHを開発（2003年） • 両者をベースに、IPA/SEC プロセス改善研究部会が一般化を行い、2007年9月に公開



多分野でISO/IEC 15504に沿ったアセスメントモデルを作成する場合の参考例

として活用可



アセスメントの厳格さに応じた標準モデルと軽量モデルを提供



アセスメント手順を提供



フリーにダウンロード可能

http://sec.ipa.go.jp/reports/20110328.html

アセスメントモデルとアセスメント手法 標準モデルと軽量モデル フリーで使える

アセスメントモデルの規格

ISO/IEC15504

モデル化 （規格準拠）

SPEAK-IPA

アセスメントモデル日本発

(21)

SEC

アンチパターン



危機感のない現場



問題は認識しているが、現状に甘んじている。（ゆでガエル？）



なぜか他人事。自らは動かない。



過去の失敗経験



前もやったが徒労に終わった。



苦労しても報われない。



経営層の無理解・無関心



レベル達成ありき。



努力して良くしても評価されない。（成果主義？プロセス軽視？）



育ってきた活動推進役が他部署へ異動。

(22)

SEC

３．現場が主役のプロセス改善

～

SPINA

3 CH自律改善メソッド～

(23)

SEC

プロセス改善の姿・形

プロセス改善を実際に行うのは・・

プロセスの実際の担い手である現場のメンバーと

プロセス実施の責任者であるプロセスオーナ！

(24)

SEC

「

SPINA

3 CH自律改善メソッド」の特長

1. 日々の業務でおぼえる違和感を見える化し、問題意識として

捉えることができる。

2. 当事者の

問題意識に基づき自主的に改善活動を推進

するた

め、効果を実感でき、継続的な活動の推進につながる。

3. 問題気づきシート、改善検討ワークシートを用いた改善活動

により、対象領域の

課題の因果関係を視覚的に把握

できる。

4. 改善検討ワークシートの課題テーマは、「

成果を得るために

は何をすべきなのか

」という視点で38種類を選定しており、活

動成果をイメージしやすい。

5. ワークシート裏面にある

改善方法のヒントや事例

を参考に、

課題認識を具体的な改善活動に結びつけることができる。

6. 継続して改善活動を行う環境が整備され、生産性向上、品質

向上等の

効果を実感

できる。

http://sec.ipa.go.jp/reports/20110707.html

(25)

SEC

改善への取り組み

ボトムアップとトップダウン

ボトムアップ

トップダウン

メリット



気付いたところから早期

に改善できる



改善の効果が即体感でき

る



活動にある程度のリソース確保が

期待できる



体系的・網羅的に取り組める



全体最適が目指せる

陥りやすい

問題



目の前の課題に着目する

あまり、やるべき事に網羅

性がない



将来の課題につながる手

当ができにくいため、常に

火消しの状態



推進側（≠現場）が進めてしまい、

現場不在に陥りやすい



現場でのメリットが感じられない、

逆に現場の負担が増える

改善が当たり前の企業文化が成功への鍵？

ムリ、ムダ、ムラの削減／５Ｓ運動／ＱＣサークル etc.

(26)

SEC

SPINA

3 _{CH自律改善メソッドの改善サイクル}

新しい作業の実行

（変更プロセス実装）

現場の問題洗い出し

問題の分析と絞込み

振り返り

問題の対応計画

（プロセスの見直し）

新しい作業の計画

（プロセス変更プラン）

さらなる改善へ組織展開新たな課題に挑戦

継続的な

改善サイクル

Start

(27)

SEC

SPINA

3 _{CH実証実験での事例（被験チーム)}



作業方針



メンバーが主体的に進め、PMは状況を確認しながら、適宜、フォロー

する方針とした。



プロセス改善経験が浅いメンバーで構成されたプロジェクトのため、

実験者が本メソッドの使い方について随時ガイドすることにした。

対象の作業内容組込ソフトウェア開発の統合支援プロジェクト構成メンバプロジェクトマネージャー(以下「PM」)1名、メンバ3名メンバの知識 PMは、本業務に参加し、本メソッドについての基本的な知識を有している。 PMのプロセス改善に関する知識は、ほとんど知らないに近い程度である。また、現在のプロジェクトでは導入した実績はない。 PMが本メソッドについての簡単な説明を行い、メンバ2名は、作業の概要や流れを理解した。残り1名は説明を受けず、ガイドブックを参考に本メソッドの概要を把握した。その他 残業が認められていないため、本メソッドは業務時間内で実施。 PMはメンバに対し、自分で考え自主的に活動することを期待している。

(28)

SEC

Software Engineering for Mo･No･Zu･Ku･Ri メンバーだけで実施 (STEP1) ・業務多忙により、約1ヶ月中断・メンバーだけでは因果関係分析は進められず、PMがサポート・深堀せずに先に進める (STEP2) 優先度の高い日々の問題、以前から問題視されていた問題に絞込む｢朝礼が長い｣｢スケジュールを立てていない｣（STEP3) ・直接該当するワークシートはなし・ヒントが得られそうなワークシートを選択（ WS-PMC-01：プロジェクトの進捗を確認する）（STEP4) ・各自で改善策を考えてくる・改善検討ワークシート[裏面）は一部ヒントになった（STEP5) 改善作業を3週間実施（STEP7) ｢朝礼が長い｣について 4つの改善策｢スケジュールを立てていない｣について、3つの改善策を策定 (STEP6) 全員で振り返り（STEP8) 改善効果が期待できるため、引き続き実施中

SPINA

3 _{CH実証実験での事例(実施ステップ)}

プロセス改善活動への前向きな意識変化・改善への意識が芽生えた・次回は自分達で回せそう・意識が変わった・メソッドの有用性を強く感じる・改善活動を継続したい

(29)

SEC

SPINA

3 _{CH実証実験での事例（分析結果）}

朝礼、夕礼の時間が長い他人の失敗の経験を生かせず、同じ失敗をしてしまう朝礼の時間が長く、作業開始の遅延に繋がっているベースライン更新作業で機種ごとに細かな手順が異なるため、作業が煩雑になっているメンバー全員に顧客の要求が共有されていないことがあるビルド作業などのルーチン作業に追われ、付加価値の高い作業ができていないレビューの時間が取れないラベルの引き間違いや、構成仕様作成ミスなど、作業のミスが多いベースライン更新作業を俯瞰する適度な粒度の初心者用ドキュメントがないベースライン更新作業用のツールの不具合を場当たりに対処しているように見えるスケジュールを立てていないので、作業期限や範囲が曖昧ビルド作業以外の溜まっているタスクを把握できていないビルド以外の作業を実施する時間がなかなか取れず、作業が溜まる仕様書を読めていないので、プロセスの役割などが分からない

(30)

SEC

SPINA

3 _{CH実証実験での事例（対策）}



｢朝礼が長い｣の改善策



｢アジェンダを事前に作成し、朝礼の議題を共有しておく｣



｢調整が必要だと思う議題は事前にプロジェクトマネージャーに

相談しておく｣



｢終了時間を決めておく｣



｢タイムキーパーを立てる｣



｢スケジュールを立てていない｣の改善策



｢ビルド以外の作業についてWBSを考える｣



｢スケジュールを作成し、マイルストンを明確にする｣



｢スケジュールを使って、進捗を確認する｣

それぞれの問題ごとに｢改善検討ワークシート｣を作成する担当者を決め、作成された

｢改善検討ワークシート｣を

メンバ全員でレビュー

した。その後、各自が考えてきた改

善策について、｢すぐに着手できるもの｣、そして、｢改善効果が比較的得られやすいと

思われるもの｣の観点から、

改善策を絞り込んだ

。

(31)

SEC

SPINA

3 _{CH実証実験での事例（実施結果と変化）}



＜朝礼が長い＞



実施期間が短いため朝礼時間の大幅な短縮には繋がっていないが、改善のための準

備が整い、各自が意識して行動するようになった。



＜スケジュールを立てていない＞



成果物に対し必要な作業を整理するようにした。作業経験者に具体的な作業内容を確

認する姿が見受けられた。



概略スケジュールを作成することで、チェックポイントとなるマイルストンを共有すること

が出来た。



朝礼のアジェンダに進捗を確認するよう追記し、スケジュールを立てる習慣をつけた。



実施前後の変化



朝礼での議論の内容の記録が残るようになった。



朝礼の時間は短くなっていない。



作業の負荷分散ができるようになった。



締め切りを意識するようになった。

（メンバの声）・議題が決まっているので、話題が逸れ難くなった。・アジェンダがあるので、議事録がとりやすくなった。・時間を守るように意識するようになった。・作業詳細を把握していないことに気がついた。・スケジュールを作ることで溢れる作業が把握でき、作業を他の人に振ることができた。

(32)

SEC

SPINA

3 _{CH実証実験での事例（活用のヒント）}

1. プロセス改善活動導入のきっかけ作り



プロセス改善経験が浅い実験参加者が殆どだったが、改善活動の全体像を把握した

上で本メソッドのステップを全て実施している。本メソッドが改善活動の基本的な

手順とシート、そして、網羅された問題点リストや改善策検討のためのヒントを提

供することで、改善経験がなくとも参考にしながら改善活動を実施することが出来

たのではないか。プロセス改善経験が浅いプロジェクトが改善活動の一歩を踏み出

すきっかけとして活用できると考える。

2. コミュニケーションの活性化



このチームは、試行以前では個人で作業をすることが多く、さらに、業務全体に関

わる問題やその要因について深く討論する機会が少なかったが、当メソッドを試行

することで意見交換や問題領域の共有活動を行うことができ、チーム内のコミュニ

ケーションが活性化される効果が得られた。

3. ポジティブ思考



チームメンバだけでは、因果関係分析を十分に進めることが出来なかった。（経験

・スキルが不足）結果として、マネージャが問題の関連を整理した図を作成したが

、問題の現象に近い部分を問題として特定し、実施することになり、問題を因果関

係で結びつける材料が不足していた（抽出した問題を詳細化する作業の省略など）

ようである。にもかかわらず、一定の効果をメンバが実感し、改善活動を続ける動

機づけの効果があった。改善活動は、トライ＆エラーを繰り返すことで、経験・ス

キルが培われることを念頭に前向きな姿勢で取り組むことが大切なのではないだろ

うか。

(33)

SEC

(34)

SEC

プロセス改善は組織活動そのもの



プロセス改善：

組織のプロセスを変えるために行なわれる行動。

組織の事業目標を、より効果的に、及び／又は、より効率的

に満たすような行動。（15504-1:2004）

（ＳＬＣＰでは）

ライフサイクルモデル管理プロセスの下位プロセス

1 プロセスの確立プロセス

2 プロセスアセスメントプロセス

3 プロセスの改善プロセス

プロセスの改善プロセスは，継続的に

組織の有効性及び効率を改善すること。

(35)

SEC

プロセス改善における10の勘所

人が中心になること

明確な目的・目標

を持つこと

関係者間での

認識が共有されること

現実的に進めること

活動を継続すること

全員が参画すること

成功を分かちあうこと

計画的に行うこと

主体性を持つこと

事実情報に基づいた

行動をとること

(36)

SEC



まとめ



プロセスに着目！



技術、人も忘れずに！



アセスメントという客観的評価の有効活用！



改善活動は、“現場の人が中心”



アセスメントはツールの一つ



使い方次第！最後はお互いの信頼関係？

（参考）プロセス改善に関するSECBOOKSとツール

(37)

SEC

これまでのプロセス改善に関する活動成果

プロセス改善ナビゲーションガイド

なぜなに編

プロセス診断活用編

虎の巻編

ベストプラクティス編

国際規格準拠アセスメントモデル：

SPEAK-IPA

標準モデル

軽量モデル（SPINACH）

SPINA

3 _{CH自律改善メソッド}

当事者の取組みを促進するプロセス改善ツール

(38)

SEC

これまでの主な部会成果物

編者：（独）情報処理推進機構ソフトウェア・エンジニアリング・センター

執筆者：経済産業省プロセス改善研究部会WG

（現ＩＰＡ／ＳＥＣプロセス改善ＷＧ）

(39)

SEC

プロセス改善ナビゲーションガイドの概要

ガイド名

概要

主なコンテンツ

なぜなに編

そもそもプロセス改善とは何か？、何を目指すのか？、どのようなアプローチがあるのか？等、プロセス改善の概念や概要を整理し、まとめたもの・なぜプロセス改善か・プロセス改善の姿・形・プロセス改善の留意点と実施体制

プロセス診断

活用編

アセスメントモデルベースのプロセス改善を推進しようとしたときに、道具として必要となる、アセスメントモデルの活用方法についてエッセンスをまとめたもの・プロセスアセスメントの活用・アセスメントモデルを活用するにあたって理解しておきたいこと・組織の能力を測る道具・国際規格15504への適合性検証・アセスメントの実施

虎の巻編

プロセス改善を推進する上で抱く実務的な疑問に答える形式でとりまとめた、実務者向けガイドブック・プロセス改善における10の勘所・プロセス改善８ステップ・プロセス改善８ステップ一問一答・プロセス改善事例

ベスト

プラクティス編

実際のソフトウェア開発現場で実施されたプロセス改善事例の中から、参考となる事例：ベストプラクティスを統一した様式でまとめたもの・効果的プロセス改善のための情報共有の必要性・プロセス改善とベストプラクティス・ベストプラクティス集

(40)

SEC

プロセス改善ナビゲーションガイド <なぜなに編>

第１章なぜプロセス改善かプロセス改善の意義と狙いソフトウェアプロセスの現状仕組みを持つ組織と持たない組織の差ソフトウェアプロセスを改善する狙いプロセス改善のアプローチプロセス改善の対象プロセスの発見プロセス改善の効果まとめ第２章プロセス改善の姿・形改善サイクルプロセス管理の手法やツールプロセス実施技術事業目標とプロセスのニーズサプライチェーンとソフトウェアプロセスモデルベース改善とその他のアプローチ第３章プロセス改善の留意点と実施体制プロセス改善推進の留意点プロセス改善推進の知恵プロセス改善の推進体制プロセス改善事例の公開プロセス改善プログラムおわりに＜コラム＞プロセスの詳細記述の仕方プロセス理解の主体プロセスを実施する人とプロフェッショナルについて会議のもち方について情報の見える化について “５ゲン”主義について良いアセッサについてプロセス改善プログラム（process improvement program）について

(41)

SEC

プロセス改善ナビゲーションガイド <虎の巻編>

はじめに第1章プロセス改善８ステッププロセス改善の基本は「サイクルに沿った活動」検討ステッププロセス改善目標の設定開始ステッププロセス改善サイクルの開始診断ステップ現状の把握計画ステップ行動計画の開発実装ステップ改善の実施確認ステップ改善効果の確認維持ステッププロセスの維持定着ステップ実行結果の監視第2章プロセス改善８ステップ一問一答 Q1 改善は誰のために行うもの Q2 改善による売り上げやトラブルの問題解決 Q3 要求変更により、実業務がうまく回りません Q4 マネジメントシステムとプロセス改善の違い Q5 QCサークル活動とプロセス改善の違い Q6 事業目標から改善のゴールへブレークダウン Q7 経営者がやってはいけないこと Q8 改善推進者がよくやってしまう誤り Q9 プロセス改善を導入しやすくする方法 Q10 改善を推進する人に必要なスキル（能力） Q11 ゆとりのない場合のよいプロセス改善の方法 Q12 プロセス改善は管理の問題なのでしょうか Q13 改善の有効性の判断 Q14 測定した結果を効果的に活用する Q15 アセスメントの進め方で注意すべきこと Q16 プロセスアセスメントによる組織の現状把握 Q17 アセッサを育成するときの注意点 Q18 銀の弾丸（特効薬）はありませんか？ Q19 実現性の高い計画を立てる際に注意すべき点 Q20 派遣企業でのプロセス改善の進め方のコツ Q21 受託ソフト開発にプロセス改善は必要 Q22 改善（の効果）を維持する Q23 改善活動の関連組織への展開 Q24 改善活動の水平展開 Q25 統廃合されたときの改善（の効果）の維持 Q26 「継続的な改善」とは、どのようなこと Q27 火消し活動は、沈静化させるだけではダメ第3章プロセス改善８ステップによるプロセス改善事例事例１：スミセイ情報システム事例２：パナソニックエレクトロニックデバイスおわりに巻頭：折り込み「プロセス改善における10の勘所」

(42)

SEC

プロセス改善ナビゲーションガイド <診断活用編>

はじめに

第1章プロセスアセスメントの活用

1.1. プロセスアセスメントって何？

1.2. プロセスアセスメント結果とゴール

1.3. アセスメント結果の読み方

1.4. 改善計画の策定

1.5. アセスメントと調達

第2章アセスメントモデルを活用するに

あたって理解しておきたいこと

2.1. アセスメントフロー

2.2. プロセスアセスメントに必要な役割

2.3. プロセスアセスメントの入力、出力

2.4. アセスメントモデルとは

2.5. アセスメント手法とは

第3章組織の能力を測る道具

3.1. 仕事の括りを決めたもの

(プロセス参照モデル)

3.2. 診断の仕組み

3.3. アセスメント手法

3.4. アセスメントモデルの選択

3.5. アセスメントモデルの作成

第4章国際規格15504への適合性検証

4.1. 国際規格15504の適合要件

4.2. 検証の手段

第5章アセスメントの実施

5.1. アセッサへのプロセスアセスメント実施

の依頼

5.2. アセスメント入力に必要な情報の整理

5.3. プロセスアセスメントに関わるリソース

の確保

5.4. プロセス改善ならびにプロセスアセスメ

ント実施に対する動機付け

5.5. アセスメント結果の報告

おわりに

(43)

SEC

プロセス改善ナビゲーションガイド <ﾍﾞｽﾄﾌﾟﾗｸﾃｨｽ編>

第１章効果的プロセス改善のための情報共有の必要性プロセス資産という考え方プロセス資産の蓄積と活用事例の共有化― 使える情報から学べる情報へ他組織に学ぶ外部への情報発信の意義第２章プロセス改善とベストプラクティスベストプラクティスとはプロセス改善におけるベストプラクティスの活用ベストプラクティスの調べ方第３章ベストプラクティス集 Case１：設計からはじめる見逃しバグの防止 Case２：生産性を５年で２．５倍に！ Case３：究極の高品質ソフトウェア開発プロセスを目指して Case４：生産性原理を具現化するプロセス改善 Case５：高品質ソフトウェア開発管理プロセスの実現 Case６：マネジメント自らが予防のための行動を取り、問題が起こりにくい組織に Case７：派生開発による品質および開発効率の向上 Case８：ソフトウェア部品による組立型開発と品質保証 Case９：全社レベルでのプロジェクト管理の改善

Software Engineering Center Information-technology Promotion Agency, Japan SEC セミナー 2013 年 2 月 20 日 プロセス改善とは ~ 良い成果を得るための変革に向けて ~ 独立行政法人情報処理推進機構 (IPA)

Software

Engineering

Center

独立行政法人情報処理推進機構 （IPA）

技術本部 ソフトウェア・エンジニアリング・センター （SEC）

ＳＥＣセミナー

プロセス改善とは

～ 良い成果を得るための変革に向けて ～

研究員 倉持 俊之

2013年 2月20日

SEC

セッション内容

１．プロセス改善とは？

２．アセスメントの活用

～アセスメントモデル

SPEAK-IPA～

３．現場が主役のプロセス改善

～

SPINA

3

CH自律改善メソッド～

４．プロセス改善の勘所

（参考）プロセス改善に関するSECBOOKSとツール

SEC

SEC

ソフトウェアは社会基盤の一部

SEC

現状！

SEC

改善とは？



改善とは？



物事をよい方に改めること。



現状より良い状況にするために、

何かを

変更すること。

プロセス改善ナビゲーションガイド～なぜなに編～ P63より

SEC

プロセスとは？

プロセス改善ナビゲーションガイド

～なぜなに編～ P3より

SEC

プロセスに関する標準化動向

ISO/IEC 12207

Systems and software engineering -- Software life cycle processes

ISO/IEC 15288

Systems and software engineering -- System life cycle processes

ISO/IEC 20000-4

Information technology -- Service management -- Part 4: Process reference model

SEC BOOKS 共通フレーム2007 第2版

～経営者，業務部門が参画するシステム開発

および取引のために～

SEC

プロセスに着目

SEC

どうして、“プロセス”なのか？

そもそも、ソフトウェアは人が作るもの。

開発者個人の方法や技量だけに頼ってプロジェクトを進めると。。。

役割や責任が不明確なまま作業をすすめてしまう。

→開発分担がきまらないまま、時間だけが経過。

→工程が遅れ、顧客承認を得ないまま設計終了し、プログラミングに着手。

→しかし、テスト工程で設計工程に起因する問題が多発。

→手戻り量が多く、結果的に工期も守れなくなった。

というように、属人的な仕事のやり方では、

● 製品（サービス）の品質（Ｑuality）は、安定しない。

● 納期（Ｄeliver）は、不確実（納期を必ずしも守れない）。

● 結果的に、コスト（Ｃost）は増大する。

⇒ 組織が、顧客に提供する製品（サービス）品質を維持し、または向上させていくため

には、組織の活動基盤となる“プロセス品質”が重要である。

SEC

プロセス改善が目指すもの

SEC

プロセス改善へのアプローチは多々あり！

SEC

２．アセスメントの活用

SEC

プロセス改善の国際標準化動向

Software Engineering Center Information-technology Promotion Agency, Japan SEC セミナー 2013 年 2 月 20 日プロセス改善とは ~ 良い成果を得るための変革に向けて ~ 独立行政法人情報処理推進機構 (IPA)

独立行政法人情報処理推進機構（IPA）

技術本部ソフトウェア・エンジニアリング・センター（SEC）

～良い成果を得るための変革に向けて～

研究員倉持俊之