Software Engineering CenterSoftware Engineering Center 17 アセスメントの活用（X社事例）背景・目的・ねらい X社は、Y社ビジネスに直結するITシステムの一部の保守業

Information-technology Promotion Agency, Japan

Software Engineering Center

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

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

Copyright© 2013 Information-technology Promotion Agency, Japan. All rights reserved. Software Engineering Center 1

ＳＥＣセミナー

プロセス改善とは～良い成果を得るための変革に向けて～

研究員倉持俊之

2013年 2月20日

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

Software Engineering Center 2013.2.20 ＳＥＣセミナー Copyright © 2013 IPA, All Rights Reserved. 2

セッション内容

１．プロセス改善とは？

２．アセスメントの活用

～アセスメントモデルSPEAK-IPA～

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

～SPINA3CH自律改善メソッド～

４．プロセス改善の勘所

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



１．プロセス改善とは？



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

（2008年10月1日情報化月間記念式典特別行事後援資料より）



現状！

（ソフトウェアプロセスの現状と問題点）



改善とは？

改善とは？

物事をよい方に改めること。現状より良い状況にするために、何かを変更すること。

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



プロセスとは？




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

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版～経営者，業務部門が参画するシステム開発および取引のために～発行：2009年10月



プロセスに着目




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

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

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

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

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

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

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

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

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

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

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

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

⇒ 組織が、顧客に提供する製品（サービス）品質を維持し、または向上させていくためには、組織の活動基盤となる“プロセス品質”が重要である。



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

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



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

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



２．アセスメントの活用～アセスメントモデルSPEAK-IPA～



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

ISO/IEC JTC1/SC7/ＷＧ１０が国際標準化を推進 1992年、ＣＭＭ、ＳＰＩＣＥなど、似て非なるプロセス評価モデル

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

ソフトウェア組織の有するプロセスの能力レベル及び組織の成熟度レベルを評価するための枠組みの標準化

ISO/IEC 15504ベースのプロセス評価改善のスキームの整備国際規格準拠の業界モデルAutomotiveSPICE、SPICE for SPACE等の

策定

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

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

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



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

適合したプロセスアセスメントモデル

プロセス項目（活動）

プロセス参照モデル・領域及び適用範囲・プロセス（目的及び成果を含む）

測定の枠組み・能力水準・プロセス属性・評定尺度

能力の尺度

ISO/IEC12207/AMD.1,AMD.2 (Software life cycle processes) ISO/IEC15288 (System life cycle processes)

対応付け

対応付け

（連続表現）

二次元モデル



水準0 未実施

不完全なプロセス

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

水準1 実施

実施されたプロセス・プロセス実施

水準2 管理

管理されたプロセス・実施管理・作業生産物管理

水準3 確立

確立されたプロセス •プロセス定義 •プロセス展開

水準4 予測可能

予測可能なプロセス・プロセス測定・プロセス制御

水準5 最適化

最適化しているプロセス・プロセス革新・プロセス最適化



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

背景・目的・ねらい

Ｘ社は、Ｙ社ビジネスに直結するＩＴシステムの一部の保守業務を技術支援業務として長年受託。昨年度までは、技術者が客先へ常駐し、業務システム保守を客先担当者と共同で実施していたが、今年度より顧客からの強い要望から請負契約へ変更、要求分析からソフトウェア結合テストまでを担当している。

客先での標準プロセスを使用しているが、要求分析(影響範囲）のもれ、レアケースデータに対しての考慮不足、パフォーマンスの問題など発生することがある。ＰＪ管理（短工期の）、レビュー、品質保証系プロセスに課題があると思われる。

見積精度を強化したい。最終的には瑕疵コストの削減（但し数ヶ月後に判明する）半減を目指す。




△キックオフ

△推進教育

◆アセスメント実施

△全社成果報告会


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

改善活動


A事業部

B事業部改善活動

準備

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

要求事項抽出（P.3.1）

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

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

問題解決（S.8）

(5日間） (5日間）

(4日間）

外部アセッサ２名で実施

外部アセッサ２名に加え、アセスメント教育受けた社内アセッサ２名がアセスメントに参加

Ｘ社でアセスメント教育受けた社内アセッサ３名で実施




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

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

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

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

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

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



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 アセスメントモデル日本発



アンチパターン

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

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

過去の失敗経験前もやったが徒労に終わった。

苦労しても報われない。

経営層の無理解・無関心レベル達成ありき。

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

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



３．現場が主役のプロセス改善～SPINA3CH自律改善メソッド～



プロセス改善の姿・形

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

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

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



「SPINA3CH自律改善メソッド」の特長

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

2. 当事者の問題意識に基づき自主的に改善活動を推進するため、効果を実感でき、継続的な活動の推進につながる。

3. 問題気づきシート、改善検討ワークシートを用いた改善活動により、対象領域の課題の因果関係を視覚的に把握できる。

4. 改善検討ワークシートの課題テーマは、「成果を得るためには何をすべきなのか」という視点で38種類を選定しており、活動成果をイメージしやすい。

5. ワークシート裏面にある改善方法のヒントや事例を参考に、課題認識を具体的な改善活動に結びつけることができる。

6. 継続して改善活動を行う環境が整備され、生産性向上、品質向上等の効果を実感できる。

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



改善への取り組み

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

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

メリット

気付いたところから早期に改善できる

改善の効果が即体感できる

活動にある程度のリソース確保が期待できる

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

全体最適が目指せる

陥りやすい問題

目の前の課題に着目するあまり、やるべき事に網羅性がない

将来の課題につながる手当ができにくいため、常に火消しの状態

推進側（≠現場）が進めてしまい、現場不在に陥りやすい

現場でのメリットが感じられない、逆に現場の負担が増える

改善が当たり前の企業文化が成功への鍵？ムリ、ムダ、ムラの削減／５Ｓ運動／ＱＣサークル etc.



SPINA3CH自律改善メソッドの改善サイクル

新しい作業の実行（変更プロセス実装）

現場の問題洗い出し問題の分析と絞込み

振り返り

問題の対応計画（プロセスの見直し）

新しい作業の計画（プロセス変更プラン）

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

継続的な改善サイクル

Start



SPINA3CH実証実験での事例（被験チーム)

作業方針

メンバーが主体的に進め、PMは状況を確認しながら、適宜、フォローする方針とした。

プロセス改善経験が浅いメンバーで構成されたプロジェクトのため、実験者が本メソッドの使い方について随時ガイドすることにした。

対象の作業内容組込ソフトウェア開発の統合支援

プロジェクト構成メンバプロジェクトマネージャー(以下「PM」)1名、メンバ3名

メンバの知識 PMは、本業務に参加し、本メソッドについての基本的な知識を有している。 PMのプロセス改善に関する知識は、ほとんど知らないに近い程度である。また、

現在のプロジェクトでは導入した実績はない。 PMが本メソッドについての簡単な説明を行い、メンバ2名は、作業の概要や流れを

理解した。残り1名は説明を受けず、ガイドブックを参考に本メソッドの概要を把握した。

その他残業が認められていないため、本メソッドは業務時間内で実施。 PMはメンバに対し、自分で考え自主的に活動することを期待している。



メンバーだけで実施 (STEP1)

・業務多忙により、約1ヶ月中断・メンバーだけでは因果関係分析

は進められず、PMがサポート・深堀せずに先に進める

(STEP2)

優先度の高い日々の問題、以前から問題視されていた問題に絞込む

｢朝礼が長い｣｢スケジュールを立てていない｣

（STEP3)

・直接該当するワークシートはなし

・ヒントが得られそうなワークシートを選択（ WS-PMC-01：プロジェクトの進捗

を確認する）（STEP4)

・各自で改善策を考えてくる

・改善検討ワークシート[裏面）は一部ヒントになった

（STEP5)

改善作業を3週間実施（STEP7)

｢朝礼が長い｣について 4つの改善策｢スケジュールを立てていない｣について、3つの改善策を策定

(STEP6) 全員で振り返り

（STEP8)

改善効果が期待できるため、引き続き実施中

SPINA3CH実証実験での事例(実施ステップ)

プロセス改善活動への前向きな意識変化

・改善への意識が芽生えた・次回は自分達で回せそう

・意識が変わった・メソッドの有用性を強く感

じる・改善活動を継続したい



SPINA3CH実証実験での事例（分析結果）

朝礼、夕礼の時間が長い

他人の失敗の経験を生かせず、同じ失敗をしてしまう

朝礼の時間が長く、作業開始の遅延に繋がっている

ベースライン更新作業で機種ごとに細かな手順が異なるため、作業が煩雑になっている

メンバー全員に顧客の要求が共有されていないことがある

ビルド作業などのルーチン作業に追われ、付加価値の高い作業ができていない

レビューの時間が取れない

ラベルの引き間違いや、構成仕様作成ミスなど、作業のミス

が多いベースライン更新作業を俯瞰する適度な粒度の初心者用ドキュメントがない

ベースライン更新作業用のツールの不具合を場当たりに対処しているよ

うに見える

スケジュールを立てていないので、作業期限や範囲が曖昧

ビルド作業以外の溜まっているタスクを把握できていない

ビルド以外の作業を実施する時間がなかなか取れず、作業が溜まる

仕様書を読めていないので、プロセスの役割などが分からない



SPINA3CH実証実験での事例（対策）

｢朝礼が長い｣の改善策

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

｢調整が必要だと思う議題は事前にプロジェクトマネージャーに相談しておく｣

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

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

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

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

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

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

それぞれの問題ごとに｢改善検討ワークシート｣を作成する担当者を決め、作成された｢改善検討ワークシート｣をメンバ全員でレビューした。その後、各自が考えてきた改善策について、｢すぐに着手できるもの｣、そして、｢改善効果が比較的得られやすいと思われるもの｣の観点から、改善策を絞り込んだ。



SPINA3CH実証実験での事例（実施結果と変化）

＜朝礼が長い＞

実施期間が短いため朝礼時間の大幅な短縮には繋がっていないが、改善のための準備が整い、各自が意識して行動するようになった。

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

成果物に対し必要な作業を整理するようにした。作業経験者に具体的な作業内容を確認する姿が見受けられた。

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

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

実施前後の変化朝礼での議論の内容の記録が残るようになった。

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

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

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

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



SPINA3CH実証実験での事例（活用のヒント）

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

プロセス改善経験が浅い実験参加者が殆どだったが、改善活動の全体像を把握した上で本メソッドのステップを全て実施している。本メソッドが改善活動の基本的な手順とシート、そして、網羅された問題点リストや改善策検討のためのヒントを提供することで、改善経験がなくとも参考にしながら改善活動を実施することが出来たのではないか。プロセス改善経験が浅いプロジェクトが改善活動の一歩を踏み出すきっかけとして活用できると考える。

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

このチームは、試行以前では個人で作業をすることが多く、さらに、業務全体に関わる問題やその要因について深く討論する機会が少なかったが、当メソッドを試行することで意見交換や問題領域の共有活動を行うことができ、チーム内のコミュニケーションが活性化される効果が得られた。

3. ポジティブ思考

チームメンバだけでは、因果関係分析を十分に進めることが出来なかった。（経験・スキルが不足）結果として、マネージャが問題の関連を整理した図を作成したが、問題の現象に近い部分を問題として特定し、実施することになり、問題を因果関係で結びつける材料が不足していた（抽出した問題を詳細化する作業の省略など）ようである。にもかかわらず、一定の効果をメンバが実感し、改善活動を続ける動機づけの効果があった。改善活動は、トライ＆エラーを繰り返すことで、経験・スキルが培われることを念頭に前向きな姿勢で取り組むことが大切なのではないだろうか。



４．プロセス改善の勘所



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

プロセス改善：

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

組織の事業目標を、より効果的に、及び／又は、より効率的に満たすような行動。（15504-1:2004）

（ＳＬＣＰでは）

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

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

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

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

プロセスの改善プロセスは，継続的に組織の有効性及び効率を改善すること。



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

人が中心になること

明確な目的・目標を持つこと

関係者間での認識が共有されること

現実的に進めること

活動を継続すること

全員が参画すること

成功を分かちあうこと

計画的に行うこと

主体性を持つこと

事実情報に基づいた行動をとること

IPA 「プロセス改善ナビゲーションガイド～虎の巻編～」から引用



まとめ

プロセスに着目！技術、人も忘れずに！

アセスメントという客観的評価の有効活用！改善活動は、“現場の人が中心”

アセスメントはツールの一つ使い方次第！最後はお互いの信頼関係？

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



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

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

なぜなに編

プロセス診断活用編

虎の巻編

ベストプラクティス編

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

軽量モデル（SPINACH）

SPINA3CH自律改善メソッド

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



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

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

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

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



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

ガイド名概要主なコンテンツ

なぜなに編そもそもプロセス改善とは何か？、何を目指すのか？、どのようなアプローチがあるのか？等、プロセス改善の概念や概要を整理し、まとめたもの

・なぜプロセス改善か

・プロセス改善の姿・形

・プロセス改善の留意点と実施体制

プロセス診断

活用編

アセスメントモデルベースのプロセス改善を推進しようとしたときに、道具として必要となる、アセスメントモデルの活用方法についてエッセンスをまとめたもの

・プロセスアセスメントの活用

・アセスメントモデルを活用するにあたって理解しておきたいこと

・組織の能力を測る道具

・国際規格15504への適合性検証

・アセスメントの実施

虎の巻編プロセス改善を推進する上で抱く実務的な疑問に答える形式でとりまとめた、実務者向けガイドブック

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

・プロセス改善８ステップ

・プロセス改善８ステップ一問一答

・プロセス改善事例

ベスト

プラクティス編

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

・効果的プロセス改善のための情報共有の必要性

・プロセス改善とベストプラクティス

・ベストプラクティス集



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

第１章なぜプロセス改善か

プロセス改善の意義と狙い

ソフトウェアプロセスの現状

仕組みを持つ組織と持たない組織の差

ソフトウェアプロセスを改善する狙い

プロセス改善のアプローチ

プロセス改善の対象プロセスの発見

プロセス改善の効果

まとめ

第２章プロセス改善の姿・形

改善サイクル

プロセス管理の手法やツール

プロセス実施技術

事業目標とプロセスのニーズ

サプライチェーンとソフトウェアプロセス

モデルベース改善とその他のアプローチ

第３章プロセス改善の留意点と実施体制

プロセス改善推進の留意点

プロセス改善推進の知恵

プロセス改善の推進体制

プロセス改善事例の公開

プロセス改善プログラム

おわりに

＜コラム＞

プロセスの詳細記述の仕方

プロセス理解の主体

プロセスを実施する人とプロフェッショナルについて

会議のもち方について

情報の見える化について

“５ゲン”主義について

良いアセッサについて

プロセス改善プログラム（process

improvement program）について



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

はじめに第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の勘所」



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

はじめに第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. アセスメント結果の報告

おわりに



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

第１章効果的プロセス改善のための情報共有の必要性

プロセス資産という考え方

プロセス資産の蓄積と活用

事例の共有化― 使える情報から学べる情報へ

他組織に学ぶ

外部への情報発信の意義

第２章プロセス改善とベストプラクティス

ベストプラクティスとは

プロセス改善におけるベストプラクティスの活用

ベストプラクティスの調べ方

第３章ベストプラクティス集

Case１：設計からはじめる見逃しバグの防止

Case２：生産性を５年で２．５倍に！

Case３：究極の高品質ソフトウェア開発プロセスを目指して

Case４：生産性原理を具現化するプロセス改善

Case５：高品質ソフトウェア開発管理プロセスの実現

Case６：マネジメント自らが予防のための行動を取り、問題が起こりにくい組織に

Case７：派生開発による品質および開発効率の向上

Case８：ソフトウェア部品による組立型開発と品質保証

Case９：全社レベルでのプロジェクト管理の改善

Case１０：GDD（Genba Driven Development）



提供ツールの位置付け

モデルベース

客観的

主観的

課題ベース

CMMI/SPICE

SPINA3CH自律改善メソッド

SPEAK-IPA

ソフトウェアプロセス・アセスメントキット



プロセス改善を組織能力の向上手段の一つとして活用してみてください！

最後に

IPA/SECホームページ

http://sec.ipa.go.jp/

http://sec.ipa.go.jp/std/ent02-b.html （プロセス改善）

SECBOOKS（書籍PDF版） http://sec.ipa.go.jp/publish/index.html#ent

ご清聴ありがとうございました。

http://sec.ipa.go.jp/

http://sec.ipa.go.jp/std/ent02-b.html

http://sec.ipa.go.jp/publish/index.html

Documents

Software Engineering CenterSoftware Engineering Center 17 アセスメントの活用（X社事例） 背景・目的・ねらい X社は、Y社ビジネスに直結するITシステムの一部の保守業

Software Engineering CenterSoftware Engineering Center 17 アセスメントの活用（X社事例）背景・目的・ねらい X社は、Y社ビジネスに直結するITシステムの一部の保守業