spina ch自律改善メソッド」解説2011.7.7 spina3ch自律改善メソッド公開 spina 3 ch...

Information-technology Promotion Agency, Japan

SoftwareEngineeringCenter

Copyright© 2012 Information-technology Promotion Agency, Japan. All rights reserved.

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

SEC ソフトウェア・エンジニアリング・センター

Software Engineering Center

ＳＥＣセミナー

1

「SPINA3CH自律改善メソッド」解説～ワークシートを使ったプロセス改善のナビゲーション～

研究員倉持俊之

2012年 4月 6日

SECSoftware Engineeringfor Mo･No･Zu･Ku･Ri

2012.4.6 SECセミナー Software Engineering CenterCopyright © 2012 IPA, All Rights Reserved. 2

本日のセッション内容

１．ワークシートを使ったプロセス改善ナビゲーション

２．SPINA3CH自律改善メソッドの進め方

３．継続的改善活動を目指して



１．ワークシートを使ったプロセス改善ナビゲーション



2011.7.7 SPINA3CH自律改善メソッド公開

SPINA3CH = Software Process Improvement with Navigation, Awareness, Analysis and Autonomy for CHallenge

Navigation : ガイドがある

Awareness : 気づきから始める

Analysis : 状況・課題を分析して進める

Autonomy : 自律的に改善を進める

Challenge : 業務上のチャレンジ意識が重要



SPINACHプロジェクト

元は、

SPEAK（IPA版）第4部に組み込まれた軽量アセスメントモデルの名前（Software Process Improvement aNd Assessment for Challenge）

現在は、

当事者が主体的にプロセス改善を推進するためのガイド・支援ツール（Software Process Improvement with Navigation, Awareness, Analysis and Autonomy for Challenge）

スピナッチ・キューブ



SPINA3CH自律改善メソッドの開発経緯 2002年頃・・新日鉄ソリューションズがアセスメントモデル『ＳＰＥＡＫ』を開発 2005年・・・ＪＩＳＡが軽量アセスメントモデル『SPINACH』を発表 2006年・・プロセス改善研究部会発足

2007年9月：ＳＰＥＡＫ－ＩＰＡ公開 2007年10月～200８年3月：実証実験実施 2008年10月～2009年3月：実証実験実施

2011年3月：ＳＰＥＡＫ－ＩＰＡ改訂

2006年～プロセス改善研究部会の中で、日本におけるプロセス改善活動の普及の一環として、日本で開発された国際標準ISO/IEC15504準拠アセスメントモデルを一般公開すべく、『ＳＰＥＡＫ』と『ＳＰＩＮＡＣＨ』を無償提供いただき汎用化を実施した。

SPEAK-IPA

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

SPEAK-IPA改良PT SPINACH検討PT 人材育成PT ・・・

検討課題

当事者が改善に踏み出すきっかけとなる道具の提供



主体的・持続的に推進されない場合がある

トップダウンが強調されすぎる

SPIの意義がつかみ切れていない

「銀の弾丸」を求めてしまう

適切なガイドがない

課題の把握が場当たり的となっている

プロセス改善の課題



これまでのプロセス改善に関するIPA-SECの活動

プロセス改善ナビゲーションガイドなぜなに編プロセス診断活用編虎の巻編ベストプラクティス編

国際規格準拠アセスメントモデルの確立標準モデル

SPEAK-IPA版軽量モデル

SPINACH

総合的に利用したい

配慮点１：

アセスメントモデルとアセスメント手法

標準アセスメントモデルと軽量アセスメントモデル

フリーで使える(モデルおよび手法)

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

ISO/IEC15504

モデル化

(規格準拠)

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



特定の事故・トラブル

トラブルが絶えない、事故が予想され危ない

競争力がない、業績不振

勤務が過重、作業の無駄が

多すぎる

配慮点２：

改善へ向かう動機：多様！



発注者利用者

経営者／シニアマネージャ

プロジェクト・マネー

ジャ開発者

品質管理者、SEPG

など

配慮点３：

当事者: 多様！



日常の仕事なんとか仕上げる

問題を感じる

不満が内向するなんとかしたいと思う

出来そうにないのであきらめる

対処の方向を見つける = 気づき

この辺をガイドする

チャレンジ！する

この意識に近づけていく

「気づき」と「チャレンジ」



本アプローチの位置付け

モデルベース

Top Down

Bottom Up

課題ベース

CMMI15504

SPINA3CH自律改善メソッド



ワークシートを使ったプロセス改善のナビゲーション

現場やプロジェクトリーダ自らが課題を分析し、解を導く手法は標準的なソフトウェアエンジニアリングの要素を網羅的に含んでいる

入り口は課題ベース＋世間の経験・知見の蓄積も活かす

本アプローチの目指す先

実際に作業しながら考えよう！！



SPINA3CH自律改善メソッドとは

ソフトウェア開発の「仕事のやり方」を現実に即して改善・向上させるためのツール

特色：自主的な努力と追求（手と頭を動かす作業）を期待

しかし、その手がかりとしてのヒントも提供

利用の場面• 開発チームの取り組みとして• エンジニア個人の自己トレーニング、自己チェックとして• 企業総体の改善ツールの一つとして



「仕事のやり方をよりよくする」ための道筋

よりよくする範囲・対象

• プロフェッショナルな仕事のスタイル

•技術とノウハウの獲得・蓄積

•プロジェクトの環境、大小の考慮

• これらが「仕事のやり方」であり、それをプロセスという

• これらをより良くすること＝プロセス改善

改善のポイント

• 自分で、事実に即して考える

•改善主体は自分（とチーム）

•現状の問題をいろいろな観点からみる

• これらには、学習や相談、討議といったことも含まれる



SPINA3CH自律改善メソッドの特色(1/4)モデルベース改善と課題ベース改善の融合

課題ベースモデルベース

陥りやすい問題

火がついた課題に着目するあまり、やるべき事に網羅性がない将来の課題につながる手当ができにくいため、常に火消しの状態

一度に多量のプラクティスを示されるため、現場に敬遠されるレベル到達ありきになってしまうモデルを実装してしまいがちで、現場には負担になりやすい推進側（SEPG）が進めてしまい、現場不在に陥りやすい

メリット改善の初心者も入りやすい改善の効果が即体感できる

ソフトウェア開発としてやるべきこととして網羅的にしくみの定義ができる



SPINA3CH自律改善メソッドの特色(2/4)

業務担当者を変更

したい

システムの設計書類

がないので欲しい

４月～６月に作業が集中するので対応が遅れることがある

Ｙさんしか対応できな

い

そもそも引継がなかっ

たんだ

顧客からの問い合わせ対応が負担

なんだシステムの中味が分か

らない

処理で障害は検知できない

毎年同じような質問が多い

問い合わせ対応契約は固定で少額

こうした状況を整理して課題を分析していく

さまざまな状況・問題・要望（ある組織の事例）



要求抽出要求管理

見積計画立案進捗管理

工程完了リリース管理

要求分析要件定義設計実装テスト

納品後対応

□いつも計画と実績の乖離が大きい□進捗状況が見えない□急に大きな問題が発生する□超過・休日勤務が多い。疲弊している□進捗が遅れているときの対処が適切でない

□設計が進まない（時間がかかる）□レビューは実施してない・一部しかしていない□設計レビューで指摘事項が多数発生する□レビューで欠陥が発見できない□プロジェクトの途中で想定外の仕様変更が多い

□見積がずさん□最初から無理な計画になっている□計画の詳細が分からない

□テストで使える期間・時間が足りなくなる□テスト時たくさんの設計や実装のバグが見つかる□テストが不十分(テスト件数、網羅度)□テスト環境が不十分

□コスト超過することが多い□納期遅延することが多い□製品品質が悪いことが多い□顧客のクレームが多い□間違ったソフトウェアをリリースしてしまう

□納品後に障害が多発する□納品後にずるずると持ち出し工数が発生する□コストが超過する

□要求分析が不十分□要件定義が不十分（不明確）

□システム（製品）化目的が不明である□要求事項に抜け・漏れ・矛盾がある（または、確定が遅い）

開発のライフサイクル編

問題気づきシート

一貫性の確保・フィードバック

□実装の効率が悪い(時間がかかる)□実装環境が整備されていない□実装不備が多い□コードが読みにくい

□設計書を修正せずに、ソースコードを修正している□変更に対する影響範囲が特定できない

①

② ③ ④ ⑤

⑥⑦ ⑧

⑨

①

②

③ ④

⑤

⑥

⑦

⑧

⑨

⑩

⑩


発注者、利用者

経営者／シニアマネージャ

プロジェクト・マネージャ

開発者

品質管理者、SEPGなど




カテゴリグループプロセス

主ライフサイクルプロセスカテゴリ

顧客―供給者プロセスグループ

P.1.1 取得準備プロセスP.1.2 供給者選択プロセスP.1.3 供給者監視プロセスP.1.4 顧客の受入れプロセス

エンジニアリングプロセスグループ

P.2 供給プロセスP.3.1 要求事項抽出プロセスP.3.2 システム要求分析プロセスP.3.3 システムアーキテクチャ設計プロセスP.3.4 ソフトウェア要求分析プロセスP.3.5 ソフトウェア設計プロセスP.3.6 ソフトウェア構築プロセスP.3.7 ソフトウェア結合プロセスP.3.8 ソフトウェアテストプロセスP.3.9 システム結合プロセスP.3.10 システムテストプロセスP.5 保守プロセス

支援ライフサイクルプロセスカテゴリ

支援プロセスグループ S.1 文書化プロセスS.2 構成管理プロセスS.3 品質保証プロセスS.4 検証プロセスS.5 妥当性確認プロセスS.8 問題解決プロセス

組織ライフサイクルプロセスカテゴリ

管理プロセスグループ O.1.3 プロジェクト管理プロセスO.1.4 品質管理プロセスO.1.5 リスク管理プロセス

組織プロセスグループ O.1.1 組織に関するアライメントプロセスO.1.2 組織管理プロセスO.1.6 測定プロセスO.4.1 人的資源管理プロセスO.4.2 教育訓練プロセスO.7 ドメイン技術プロセス

自ら考える

絞り込む

アセスメントモデル：SPEAK-IPA版のプロセス全体像（開発者等向け）



SPINA3CH自律改善メソッドの道具の構成

全体として記入シートを使ったプロセス改善のナビゲーション

現状問題の気づき

領域の絞り込み

ワークシートの選択

テーマごとのワークシートの記載

改善へ着手


改善検討ワークシート

＜３つから構成＞

問題分析絞り込みシート




２． SPINA3CH自律改善メソッドの進め方



どうやって使うか？

STEP1：『問題気づきシート』を使って、開発のライフサイクルで発生している問題を粗くチェック

STEP2：問題の詳細化と因果関係の分析

STEP3：改善の対象を絞る

STEP4：該当する改善検討ワークシートを選択する

STEP5：選択された改善検討ワークシートに従い、自らが、やるべき事を考え、記入していく

STEP6：チーム討議や、専門家との討議をして深める

STEP7：ワークシートの検討結果を作業の改善に適用する

STEP8：振り返りを行う

Copyright © 2010 ＩＰＡ, All Rights Reserved

STEP1～STEP7を結果を、STEP8で再点検し、次のサイクルへつなげる



どうやって使うか？

問題を抽出

問題の因果関係を探る

問題詳細化ヒント

問題分析絞込みシート


【表】

問題とテーマのマッピング


【裏】

どないなっとんねん！

どこがあかんねんやろ？

問題の絞込み

問題の改善方法を検討

参照ﾁｪｯｸ

因果

絞込

施策


ワークシートの選択

白紙

問題をカードに記入

ヒント

STEP1

STEP2

STEP3

STEP4

STEP5

実施プランのとりまとめ

STEP6

作業改善の実施

STEP7振り返り

STEP8

2サイクル目の活動へ


【表】改善計画新しい

作業方法

これでよかったんかな

これでいこか

どないしたらええんやろ～



準備する主な道具


問題点カード

問題詳細化ヒント

問題分析絞り込みシート

問題とテーマのマッピング




ＳＴＥＰ１『問題気づきシート』を使って発生している問題を粗くチェック

要求抽出要求管理

見積計画立案進捗管理

工程完了リリース管理

要求分析要件定義設計実装テスト

納品後対応

□いつも計画と実績の乖離が大きい□進捗状況が見えない□急に大きな問題が発生する□超過・休日勤務が多い。疲弊している□進捗が遅れているときの対処が適切でない

□設計が進まない（時間がかかる）□レビューは実施してない・一部しかしていない□設計レビューで指摘事項が多数発生する□レビューで欠陥が発見できない□プロジェクトの途中で想定外の仕様変更が多い

□見積がずさん□最初から無理な計画になっている□計画の詳細が分からない

□テストで使える期間・時間が足りなくなる□テスト時たくさんの設計や実装のバグが見つかる□テストが不十分(テスト件数、網羅度)□テスト環境が不十分

□コスト超過することが多い□納期遅延することが多い□製品品質が悪いことが多い□顧客のクレームが多い□間違ったソフトウェアをリリースしてしまう

□納品後に障害が多発する□納品後にずるずると持ち出し工数が発生する□コストが超過する

□要求分析が不十分□要件定義が不十分（不明確）

□システム（製品）化目的が不明である□要求事項に抜け・漏れ・矛盾がある（または、確定が遅い）

開発のライフサイクル編


一貫性の確保・フィードバック

□実装の効率が悪い(時間がかかる)□実装環境が整備されていない□実装不備が多い□コードが読みにくい

□設計書を修正せずに、ソースコードを修正している□変更に対する影響範囲が特定できない

①

② ③ ④ ⑤

⑥⑦ ⑧

⑨

①

②

③ ④

⑤

⑥

⑦

⑧

⑨

⑩

⑩



■要求事項が不明確

■計画の詳細が分からない

■要件定義が不十分（不明確）

■プロジェクトの途中で仕様変更が多く作業が翻弄されている

■超過・休日勤務が多い・疲弊している

■テストで使える期間・時間

が計画より短くなることが多い

■急に大きな問題が発生する

■いつも計画と実績の乖離が大きい

■コスト超過

■テスト時たくさんの設計や実装のバグが

見つかる

■製品品質が悪い

■顧客からのクレームが多い

■レビューで欠陥が発見できない

■レビューは実施していない／一部しかしていない

抽出した問題を詳細化

因果関係の分析

ＳＴＥＰ２問題の詳細化と因果関係の分析



＜問題点カード＞

レビューは実施していない・

一部しか実施していない

●記載例1-期日に余裕があるとレビューを実施するが、スケジュールが遅れてくるとレビューを実施しなくなる

●記載例2-重要な機能はレビューを実施するが、以外は実施しない

●記載例3-前回のプロジェクトでのレビュー実施は対象25に対して3件だった

ＳＴＥＰ２－１問題の詳細化

チェックした問題事項のカードに、そのことを裏付ける実際に発生した（発生している）事象を具体的に記載する




■テスト時たくさんの設計や実装のバグが見つかる


■レビューで欠陥が発見

できない

このことがあると

・・・・

このことが起きる、あるいは

起きやすい

原因結果

ＳＴＥＰ２－２因果関係分析

時系列や発生順を表現することではないことに注意！

分析をしていると新た問題に気がつくことがある。

⇒問題点カードやポストイットを使って追加する。

問題発生の構造を事実情報に基づいて構造的に分析する。

並べ替えたり、事実の記載を追加することにより、自分たちリアルな問題点を示したものなってゆく。



■要求事項が不明確

■計画の詳細が分からない

■要件定義が不十分（不明確）

■プロジェクトの途中で仕様変更が多く作業が翻弄されている

■超過・休日勤務が多い・疲弊している

■テストで使える期間・時間

が計画より短くなることが多い

■急に大きな問題が発生する

■いつも計画と実績の乖離が大きい

■コスト超過

■テスト時たくさんの設計や実装のバグが

見つかる

■製品品質が悪い

■顧客からのクレームが多い

■レビューで欠陥が発見できない

■レビューは実施していない／一部しかしていない

絞り込み

ＳＴＥＰ３改善対象を絞る



ＳＴＥＰ４該当する改善検討ワークシートを選択する

■開発のライフサイクル編1.顧客要求の明確化

WS-P31-1顧客要求を獲得する仕組みを確立する

WS-P32-1顧客要求からシステム要求事項にまとめ直す


WS-S1-1作成すべき標準文書と記載すべき内容を明確にする

2.要求分析・要件定義WS-JRev-1プロジェクトの作業成果物について利害関係者とレビューを実施する。

WS-S5-2妥当性確認（顧客が本来やりたいことが実装できているかを確認すること）実施する

WS-P32-1顧客要求からシステム要求事項にまとめ直す


WS-S1-1作成すべき標準文書と記載すべき内容を明確にする

WS-S5-2妥当性確認（顧客が本来やりたいことが実装できているかを確認すること）実施する

3.設計WS-P33-2システムアーキテクチャ設計の適切性を確認する

WS-P34-2ソフトウェア要求事項の適切性を確認する

b)レビューは実施してない・一部しかしていない

WS-JRev-1プロジェクトの作業成果物について利害関係者とレビューを実施する。

WS-JRev-1プロジェクトの作業成果物について利害関係者とレビューを実施する。

WS-P33-1システム要求を満たすシステムアーキテクチャ設計を実施する

WS-P35-1ソフトウェア要求を満たすソフトウェア設計を実施する

WS-P35-3ソフトウェア設計を元にソフトウェア詳細設計を実施する

d)レビューで欠陥が発見できない WS-JRev-1プロジェクトの作業成果物について利害関係者とレビューを実施する。

a)システム化目的が不明である

b)要求事項に抜け・漏れ・矛盾がある（または、確定が遅い）

a)要求分析が不十分

b)要件定義が不十分（不明確）

a)設計が進まない（時間がかかる）

c)設計レビューで指摘事項が多数発生する

ワークシートの表の１－２の『このテーマが解決すると何が良くなるか』を参照してください



ＳＴＥＰ５改善検討ワークシートを作成する

選択した領域に該当するワークシートを作成する過程を通じて、自ら改善手段を導き出す。

(WS-S2-1)改善検討ワークシート１．テーマと課題①取り上げたテーマ

構成管理の戦略やしくみがある

②このテーマが解決すると何が良くなるか

・成果物の構成要素の一貫性と追跡可能性を維持できなくなる・仕様変更や保守を管理する際に、ドキュメントの内容を分析し、必要な変更事項を決定し、該当するプログラムを変更する等の手順が踏めなくなる・ソフトウェア開発の作業にデグレード、ファイルの取り違えなどの事故や不具合が発生し、非効率な作業、不正確な情報、不必要な手戻りが発生する

・構成管理の方針、作業一覧、作業生産物、構成管理の責任者、定期的な監査のタイミング、を含む構成管理活動の戦略を立てる・仕様書やソースコードなど、構成管理の対象となる作業成果物を明確にする・プロジェクトの目標、リスクなど複数の制御レベルを管理する仕組みを確立する・構成ベースラインの一貫性を維持するため、構成管理の監査を定期的に行う

２．テーマを実施しなかった場合、起こるであろう問題

３．テーマを実現するために必要な実施事項（典型的な活動）

・構成管理の戦略やしくみを確立することで、構成管理の３要素である「バージョン管

理」「ベースライン管理」「変更管理」についてのルール作りと運用を徹底できる・プロジェクトのライフサイクルで生成される構成要素をベースライン管理することでデグレードやファイルの取り違えを起こすことなくリリースにつなげることができる・リリースバージョンにどのような機能が盛り込まれているかが適切に管理できる

５．ソリューション例１

４．現実には実現することが難しい点・仕様変更などで、ソースコードのみを修正してしまい、設計書やテスト仕様などの一貫性を保つ必要がある関連の成果物を修正しない場合がある・大規模プロジェクトでは機能追加などで仕様変更が多くなり、成果物の構成要素も増加する。そのため、多くのモジュールの世代を管理したり、一世代前に戻してリンクし直すなど、変更が管理されておらず、成果物のバージョンや変更の履歴がとれない

・構成管理は、要件定義書、設計書、プログラム、テスト仕様などを横断的に管理するべきである。しかし、実際には関連するドキュメントを最新化して同時に構成要素をベースライン管理する煩雑な作業の手間を惜み、プログラムモジュールのバージョンを管理することに精一杯である

・エドワードヨードン著, 松原友夫訳、ソフトウェア管理の落とし穴 ―アメリカの事例に学ぶ－、トッパン、1993年・Ｆ.Ｐ.ブルックス著、山内正彌訳、ソフトウェア開発の神話、企画センター、1977年・東秀和（データプロセス）、＠It自分戦略研究所、第4回　Subvers ionで簡単・確実にファイルを構成管理、Http ://jibun.a tmarkit .co.jp/ ls ki ll01/rensai/tool10/04/01.html

８．参考文献（SPEAK-IPA版のプロセス、その他の資料文献）

７．参照するとよい、他の改善検討ワークシート

・構成管理を実施するためには、例えば、ベースライン管理の作成計画、特定のベースラインに含まれる作業成果物のバージョン、一貫性を保つトレーサビリティマトリクス作成、ベースラインを特定するための命名規約作成などの活動がある

・構成管理は、組織やプロジェクトによって定義が異なる。そのため、組織やプロジェクトでの構成管理の手順を、研修・OJT・オリエンテーションで周知したほうがよい・バックアップテープの保管やプログラムソースの日付、バージョン、各版へのコメントの記録、ファイルの登録 (チェックイン)、取出し(チェックアウト)、差分情報の表示、ソフトウェア構成変更の制御などを構成管理と定義している例もある

ツールを導入しない場合、チェックイン・チェックアウトなどの機能をフォルダー管理により代替する方法もある。例えば、プロジェクトの共用フォルダーにパスワードを設け、構成管理担当者とプロジェクトマネージャ以外は「書込み禁止」にすることで、プログラム担当者が、作成したプログラムをプロジェクト・モジュールとして組み込むことはなくなり、デグレードやファイルの取り違えが発生することを予防できる。

・W S-S2-2プロジェクトで作成すべき成果物（中間成果物と納入成果物）と作成時期が決まっている・W S-S2-3プロジェクトで作成すべき成果物（中間成果物と納入成果物）の変更管理がされている・W S-S2-4プロジェクトで作成すべき成果物（中間成果物と納入成果物）の間の一貫性を保つ仕組みがある

６．ソリューション例２

テーマに沿った解決事例


４．現在のやり方の不十分点・改善すべき点はどこか

※問題の分析・絞り込み時に考慮した改善箇所と関連づけると良い

※例えば裏のソリューション例を参照して、考えてみてください

※例えば、対処案実施の際の、制約事項、コスト、他への影響など

※例えば、必要な協力者とか関係者への支援の要望など

６．上記対処をするにための懸念事項

７．上記対処をするにための留意事項

１．テーマと課題①取り上げたテーマ

５．この問題にどのように対処したいか

３．現状のやり方でうまくいっているところと悪いところ

※現在のやり方に対して、どこがうまくいっていて、どこが悪いか記載する


２．この課題について、現在どのように行っているのか

現状のやり方

現状のやり方でうまくいっているところと悪いところ

改善点

対応方法

懸念事項

留意事項















現状のやり方


改善点

対応方法

懸念事項

留意事項



表面















現状のやり方


改善点

対応方法

懸念事項

留意事項



(WS-S2-1)改善検討ワークシート１．テーマと課題①取り上げたテーマ

構成管理の戦略やしくみがある


・成果物の構成要素の一貫性と追跡可能性を維持できなくなる・仕様変更や保守を管理する際に、ドキュメントの内容を分析し、必要な変更事項を決定し、該当するプログラムを変更する等の手順が踏めなくなる・ソフトウェア開発の作業にデグレード、ファイルの取り違えなどの事故や不具合が発生し、非効率な作業、不正確な情報、不必要な手戻りが発生する

・構成管理の方針、作業一覧、作業生産物、構成管理の責任者、定期的な監査のタイミング、を含む構成管理活動の戦略を立てる・仕様書やソースコードなど、構成管理の対象となる作業成果物を明確にする・プロジェクトの目標、リスクなど複数の制御レベルを管理する仕組みを確立する・構成ベースラインの一貫性を維持するため、構成管理の監査を定期的に行う

２．テーマを実施しなかった場合、起こるであろう問題

３．テーマを実現するために必要な実施事項（典型的な活動）

・構成管理の戦略やしくみを確立することで、構成管理の３要素である「バージョン管理」「ベースライン管理」「変更管理」についてのルール作りと運用を徹底できる・プロジェクトのライフサイクルで生成される構成要素をベースライン管理することでデグレードやファイルの取り違えを起こすことなくリリースにつなげることができる・リリースバージョンにどのような機能が盛り込まれているかが適切に管理できる

５．ソリューション例１

４．現実には実現することが難しい点・仕様変更などで、ソースコードのみを修正してしまい、設計書やテスト仕様などの一貫性を保つ必要がある関連の成果物を修正しない場合がある・大規模プロジェクトでは機能追加などで仕様変更が多くなり、成果物の構成要素も増加する。そのため、多くのモジュールの世代を管理したり、一世代前に戻してリンクし直すなど、変更が管理されておらず、成果物のバージョンや変更の履歴がとれない・構成管理は、要件定義書、設計書、プログラム、テスト仕様などを横断的に管理するべきである。しかし、実際には関連するドキュメントを最新化して同時に構成要素をベースライン管理する煩雑な作業の手間を惜み、プログラムモジュールのバージョンを管理することに精一杯である

・エドワードヨードン著, 松原友夫訳、ソフトウェア管理の落とし穴 ―アメリカの事例に学ぶ－、トッパン、1993年・Ｆ.Ｐ.ブルックス著、山内正彌訳、ソフトウェア開発の神話、企画センター、1977年・東秀和（データプロセス）、＠It自分戦略研究所、第4回　Subversionで簡単・確実にファイルを構成管理、Http://jibun.atmarkit.co.jp/lskill01/rensai/tool10/04/01.html

８．参考文献（SPEAK-IPA版のプロセス、その他の資料文献）

７．参照するとよい、他の改善検討ワークシート

・構成管理を実施するためには、例えば、ベースライン管理の作成計画、特定のベースラインに含まれる作業成果物のバージョン、一貫性を保つトレーサビリティマトリクス作成、ベースラインを特定するための命名規約作成などの活動がある・構成管理は、組織やプロジェクトによって定義が異なる。そのため、組織やプロジェクトでの構成管理の手順を、研修・OJT・オリエンテーションで周知したほうがよい・バックアップテープの保管やプログラムソースの日付、バージョン、各版へのコメントの記録、ファイルの登録(チェックイン)、取出し(チェックアウト)、差分情報の表示、ソフトウェア構成変更の制御などを構成管理と定義している例もある

ツールを導入しない場合、チェックイン・チェックアウトなどの機能をフォルダー管理により代替する方法もある。例えば、プロジェクトの共用フォルダーにパスワードを設け、構成管理担当者とプロジェクトマネージャ以外は「書込み禁止」にすることで、プログラム担当者が、作成したプログラムをプロジェクト・モジュールとして組み込むことはなくなり、デグレードやファイルの取り違えが発生することを予防できる。

・WS-S2-2プロジェクトで作成すべき成果物（中間成果物と納入成果物）と作成時期が決まっている・WS-S2-3プロジェクトで作成すべき成果物（中間成果物と納入成果物）の変更管理がされている・WS-S2-4プロジェクトで作成すべき成果物（中間成果物と納入成果物）の間の一貫性を保つ仕組みがある

６．ソリューション例２

テーマに沿った解決事例

裏面



ＳＴＥＰ６チーム討議や、専門家との討議をして深める

改善検討ワークシートの内容をもとに具体的な実施プランを取りまとめる。

・具体的な施策、取組み内容・活動の成果、達成目標・スケジュール（実施項目、担当者、日程）・制約条件、留意事項、など















現状のやり方


改善点

対応方法

懸念事項

留意事項















現状のやり方


改善点

対応方法

懸念事項

留意事項



ＳＴＥＰ７：ワークシートの検討結果を作業の改善に適用する

現作業のやり方を明確化し、これに対し改善の「対応方法」を適用し、新作業のやり方を創出する。

現状の作業

現作業のやり方作業手順役割分担成果物

新作業のやり方作業手順役割分担成果物

改善された作業

改善活動

情報収集

実務展開



改善の対応方法

業務システムの移行作業と考え方は一緒かな？



ＳＴＥＰ８：振り返り

改善活動を振り返り、実施してきた内容の良かったところ悪かったところをまとめる。この内容をもとに、（STEP1～STEP7）で実施した作業のやり方を再点検し、作業の進化を確認する

新しい作業の実行

STEP1～STEP3問題の分析と絞込みSTEP8：

振り返り

STEP4～STEP6問題の対応計画

STEP7新しい作業の計画

達成目標に対して実績を把握して状況を分析

定量的にできたらうれしいですね

プロジェクトで改善された作業に関する情報を把握する仕組みを入れておいたらいいかもしれません



【表】

改善計画

改善活動結果



継続的な改善サイクルへ

新しい作業の実行

STEP1～STEP3問題の分析と絞込み

STEP8：振り返り

STEP4～STEP6問題の対応計画

STEP7新しい作業の計画

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

継続的な改善サイクル



３．継続的改善活動を目指して



プロセス改善の姿・形

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

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

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



合意形成が

できている状態

活動リソース抑制

消極的な管理者の言動

→モティベーション低下

活動への反発

・業務が忙しい

・今さらなぜ？

活動自体が目的化

無改善

管理者の改善意欲

現場メンバーの

改善意欲

現場とプロセスオーナとの合意形成

高い

低い

強い弱い

無改善継続性の課題

無改善形骸化のリスク

効果的に

改善が回る

トップダウン

アプローチ

ボトムアップ

アプローチ



プロセス改善推進のための知恵

✔

✔

✔

✔

✔

✔

✔

開発者が自分たちの

仕事の課題を取り扱う

問題分析絞込みシートと

改善検討ワークシートの活用

負担を少なく、短期間の

活動を推奨

道具は提供するが、

強制はしない

SPINA3CHは・・



自律改善で用いる道具

SPINA3CH自律改善メソッドのねらい・仕組み開発の現場の「事実」と問題への「気づき」

注目するポイントを見出す

現実のプロセスの良いところと悪いところを考える

問題の原因や改善点の把握

良い事例や他の組織との比較

ソフトウェア開発技法、マネジメント技法の学習

ツールなどの調査・評価

よく考え、その結果を改善計画としてまとめる

知識の蓄積と整理を行う

工夫してご活用ください個人・プロジェクト・社内教育で利用する場合、印刷し共有利用可能です。企業で利用する場合、社内イントラなどに掲載し２次利用も可能です。※ただし、その場合には出典元を「独立行政法人情報処理推進機構ソフト

ウェア・エンジニアリング・センタ－」または「IPA/SEC」と記載。著作権は、各著者およびSECが所有しております。



ワークショップ開催による普及活動と受講者の反応 2010/2～、ＳＥＣセミナー／実証実験（半日）6回開催、受講者：113名

2011/12、ＳＥＣセミナー（1日、有料）、受講者：19名

外部団体イベントでのワークショップ 2011/7-8、実施3回、受講者：46名

半日ＷＳ

（参考）これまでの活動実績

半日ＷＳ１日ＷＳ理解度

１．よく理解できた 70

２．少し理解できた 43

３．あまり理解できなかった 0

４．理解できなかった 0

満足度

１．とても満足 46

２．満足 67

３．やや不満 0

４．不満 0

理解度解説課題抽出分析改善検討

１．よく理解できた 11 13 7 7

２．少し理解できた 8 6 12 12

３．あまり理解できなかった 0 0 0 0

４．理解できなかった 0 0 0 0

満足度解説課題抽出分析改善検討

１．とても満足 13 14 10 9

２．満足 6 5 8 10

３．やや不満 0 0 1 0

４．不満 0 0 0 0

※当メソッドを開発したＷＧ委員による手厚いワークショップ

満足度

１．とても満足 27

２．満足 7

３．やや不満 0

４．不満 0




ワークショップ受講者のコメント（半日ワークショップ）紹介のあったツールが自組織でも役立ちそう

初心者にもわかりやすい内容になっていたと思います。

課題のつながりを考えることで改善ポイントが見つけられると思う

実際にワークシートをうめるのは、かなり大変そうです。

実施するためのポイントは明確になりました。

現場課題を明確にわかった

チュータの方が横について指導していただけたので良かったです。

吸収することができた。次回はファシリテーターとして務まるかは別です。

ステップ分けされた内容が非常に分かりやすかった。講義と演習のバランスも良かった。

演習を通して実践的なやり方が理解できた。

ツールは直感的で分かりやすく、活動の大義的な目的、有効性も理解できました。

問題はそれをどうやって現場に適用するか・・です。

半日では短いので１日程度にしてください。少し足りない。

講師がグループに一人ついていたので理解が進んだ。現場でも実施してみたい。

※受講者は、ＳＥＰＧ／品質・支援組織の方が中心




ワークショップ受講者のコメント（１日ワークショップ）「問題気づきシート」は使えるかも

現在開発から離れているため、次の機会で試したいです

現在SPINA3CHを使用した改善を行なっているので引き続き取り組みたい

現在開発側の品質・プロセス改善WGで利用中

運用方法が理解できたので、社内で効果的に運用したい

なかなか改善活動が定着しなかったが、この手法なら継続できると感じた。これができなきゃ明日はない！との決意で取り組む

利用してみたいと思うが、チュータの能力がないので改善検討が難しそう

SPINA3CHの内容は参考になりました、チュータの方からとても良いアドバイスを受けました。このような機会はほとんどないので貴重でした

非常に具合的なところが出てきたので利用してみたいです

上司も参加をすすめてくれたのですぐにでも利用したいです

問題気づきシートはすぐに利用できそうなので使ってみたいです

本日参加できなかったメンバーと相談し、利用を検討したい

改善箇所が手のつけやすいところを優先したため、本質をつけたかが気になりました ※２～５名のチーム受講（開発チーム中心）



（参考）これからの活動

客観性ある評価容易に研修できるか？

改善検討ワークシートを準備したが、本当に使えるか？

実際の開発現場で活用できるか？効果があるのか？

途中結果メソッドを使うにあたっての敷居が低い

メソッドの枠組みが好評であり、更なる拡充を望む声あり

メソッドを通じて改善について考えられる

改善を専門としない開発現場の開発者でも効果が期待できる

理解しやすい用語、表現が用いられている

経験の浅い現場担当者でも効果が期待できる

実証実験実施中



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

IPA/SECホームページ

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

SECBOOKS（書籍PDF版）

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

アセスメントモデル SPEAK-IPA http://sec.ipa.go.jp/reports/20110328.html

SPINA3CH自律改善メソッド http://sec.ipa.go.jp/reports/20110707.html

spina ch自律改善メソッド」解説2011.7.7 spina3ch自律改善メソッド公開 spina 3 ch...

Documents