一般財団法人日本科学技術連盟
第33年度ソフトウェア品質管理研究会 成果発表会
2018年2月23日(金)振り返り活動を力強く支援する「FOPA振り返りプロセス」の提案～観点網羅と真因分析による納得性の向上とFOPA TRY宣言による組織的な実行支援～研究コース１ ソフトウェアプロセス評価・改善 チームFOPA
リーダー ：田中 桂三(オムロン株式会社)
研究員 ：内藤 拓(富士通クオリティ・ラボ株式会社）
中川 幸治(APRESIA Systems株式会社）※発表者
荒川 拓(パナソニック株式会社）
主査 ：三浦 邦彦（矢崎部品株式会社）
副主査 ：山田 淳（東芝ソフトウェア・コンサルティング株式会社）
アドバイザー：中森 博晃（パナソニック スマートファクトリーソリューションズ株式会社）
Copyright (C) 2018 SQiPソフトウェア管理研究会 All Rights Reservedはじめに・現場改善活動として、振り返り会を実施されてますか？

・振り返り結果が次のプロジェクトで活用されてますか？

Noと言われる人のために有効な振り返りの方法をご紹介します

Copyright (C) 2018 SQiPソフトウェア管理研究会 All Rights Reserved2チーム名の「FOPA」とはFull persuasive and Organized Process of retrospective with Aggressiveness

Full persuasive:十分な納得性をもってOrganized Process of retrospective:組織的な振り返りプロセスをwith Aggressiveness:積極的に意思をもって行動する
Copyright (C) 2018 SQiPソフトウェア管理研究会 All Rights Reserved

3振り返りとＫＰＴ手法
振り返り：自律的な改善活動
ＫＰＴ：振り返りで用いるフレームワーク

Keep：続けること
Problem：問題点
Try：次にすること
Keep

Try

改善活動

Problem

KPTフレームワーク
参考URL： http://www.juse.jp/sqip/library/shousai/?id=67
http://objectclub.jp/download/files/pf/RetrospectiveMeetingGuide.pdf
Copyright (C) 2018 SQiPソフトウェア管理研究会 All Rights Reserved

4振り返りが実践されない大きな課題（理由）・振り返り結果（TRY）が実践されない事例・課題をピックアップ（※）（※詳細は論文_付録９ご参照）

個人のスキルが低い

実行機会を逸失してしまった

開発のプロセス改善が対象外

プロセススキルが低い

開発プロジェクト PMO Ａさん

Copyright (C) 2018 SQiPソフトウェア管理研究会 All Rights Reserved

組織的な改善意識が低い

個人的な改善意識が低い

開発プロジェクト PQA Bさん

5

振り返りが実践されない大きな課題（理由）共通課題として 振り返りがうまくいかない大きな理由として・我々研究員の共通課題として２点をクローズアップ
２点をクローズアップ （※詳細は論文_付録９ご参照）

個人のスキルが低い（課題１）
TRYに対して納得感が低い
プロセススキル実行機会を逸失してしまった

開発のプロセス改善が対象外が低い

開発プロジェクト PMO Ａさん

Copyright (C) 2018 SQiPソフトウェア管理研究会 All Rights Reserved（課題２）
TRYの実践が個人的な個人／チーム任せ
組織的な改善意識

改善意識が低いが低い

開発プロジェクト PQA Bさん

6

課題解決のための仮説
課題を解決するにあたり、仮説を立案しました。 （詳細は論文_２章をご参照）

TRYに対して納得感が低い

TRYの実践が個人／チーム任せ

KEEP/PROBLEMの網羅性が不十分なためではないか？

フリーマインドでＫＰＴ分析しているため
KEEP/PROBLEMの真因分析が不十分なためではないか？

情報伝達する仕組みが不確定なためではないか？
フォローアップができていない
ため

SQiPシンポジウム
FMEA事例発表を参考振り返りアセスメントはどうか？
（重要度、頻度）

実行支援体制が不確定なためではないか？

・真因分析として「FMEA」を使おう！ ・高優先を情報伝達しよう！（アセスメント）
・その他の２つは、各社運用で解決できるのではないか？
7Copyright(C) 2018 SQiPソフトウェア管理研究会 All Rights Reserved

1回目：KPTシート 試行時のご意見

試行 ＆アンケート

１回目に作成したKPTシートを使ってもらったご意見として、実務では使えない実務では使えない。。という感想がほとんど・・・
ＦＯＰＡチームふりかえりシート（案）Rev.02

開発プロジェクト名
チーム名orタスク名

振り返りTRY宣言

いつ？

誰が？

何を？

最も大事なTRYを、３W1Hで宣言し、確実に実行しよう！

何が振り返り内容（FMEA)
どうしてどうなった

分類
工程

PMBOK

振り返りアセスメント（重要度、頻度）

どのように行うか？

重要度

振り返りアセスメント
頻度
スコア
改善要否

K
E
E
P

改善(TRY) だから、こうしよう！
回避・軽減：TRY、需要：対象外、転嫁：Proposal「FMEA」は書きにくい「KPT」の手軽さがなくなるよ！

FMEA
形式で記入
(何が・どうして・どうなった）

PQA Bさん PMO Ａさん
Copyright (C) 2018 SQiPソフトウェア管理研究会 All Rights Reserved「頻度」はプロジェクトによって違うので、意味がないよ！

開発PM

そもそも、いつ誰がフォローするかがわからないよね！
各社の運用でカバーできないよ ！
8１回目試行時は思考の偏りもあって・・・実務に乗せるにはどうすべきか？四苦八苦してた。。。そんなところに・・・「開発プロセス改善」の救世主FOPAマン参上！！

妙案が思い浮かばないねー

どうしようかねー

そだねー
2018 平昌冬季オリンピック
カーリング女子日本代表
銅メダル獲得 おめでとう！！
Copyright (C) 2018 SQiPソフトウェア管理研究会 All Rights Reserved

9

救世主 FOPAマンが、悩みを解決！！
１回目の結果大変だったね。FOPAマンが解決策をアドバイスするよ！
お任せあれ！

お願いします。

Copyright (C) 2018 SQiPソフトウェア管理研究会 All Rights Reserved

４つの仮説を、実務で使えるようにしたいんだけど・・う～ん。
課題分析してKPTシート自体を見直すか？

10

FOPA 振り返りプロセス フレームワーク
各種課題を改善するためのフレームワークを考案【課題】
KEEP/PROBLEM
網羅性の不十分さ体系的で網羅的にチェックしたいよね【フレームワーク】

管理者向：PMBOK®ガイド

ＦＯＰＡ 観点チェックシート
開発メンバ向：共通フレーム2013

KEEP/PROBLEM
真因分析の不十分さ

シートを用意したほうが分析しやすいよね

情報伝達する仕組みが不確定

次開発担当者、経営管理層 ＦＯＰＡにしっかり
ＦＯＰＡ
伝えたいよね実行支援体制が不確定担当者任せにＦＯＰＡ ＫＰＴシート
せずしっかり支援したいよね フォローアップ対象者の指定

Copyright (C) 2018 SQiPソフトウェア管理研究会 All Rights Reserved

ＦＯＰＡ なぜなぜ分析シート
ＫＰＴシート
ＴＲＹ宣言

いかが？

11

FOPA KPTシート
FOPA観点チェックシートからFOPA KPTシートを記載
観点チェックシートから共通フレーム2013／
PMBOK®ガイドを転記 具体的な内容を記入

1

PROBLEM2

真因分析の対象とするか？判断の目安に使用

具体的なTRY（改善）内容を記入

分類(観点チェックシートで選択したもの）
TRY（改善）振り返り内容共通フレームPMBOK®
だから、こうしよう！
2013
ガイド
下流工程で、設計者が想定した プロセス開始の準備時に、有識ソフトウェア構築影響範囲以外の領域で、不具 者のレビュー時間を確保する計合が多発した。
画を立てよう！
・設計開始前に、企画部門と会
ソフトウェア
途中で要件が変更となり、開発 議を開き、要件を確認しよう！
要件定義後戻りが発生した。
・要件変更に備え、要件変更管理を徹底しよう！

重要度

TRY宣言の候補とするか？

振り返りアセスメント
重要度

TRY宣言対象

3

宣言対象

4

宣言対象

K(KEEP)
重要度
基準例
P(PROBLEM)IDEA(PROPOSAL) 4:とても重要 全社，事業部,開発部門全体に関わるレベル．（報告先：事業部長以上）
開発部門全体（次開発プロジェクト，他製品）に横展開するレベル．
分類
3:重要（報告先：開発部長以上，次開発プロジェクトマネージャー）
2:普通
他チームに展開するレベル．（報告先：プロジェクトリーダー，他チームリーダー）
個人/チームに展開するレベル．（報告先：チームリーダー）
1:軽微
12
Copyright (C) 2018 SQiPソフトウェア管理研究会 All Rights Reserved

12FOPA TRY宣言
重要度高FOPATRY宣言！
TRY宣言！
FOPA KPTシートから重要度高（3,4）についてFOPA
３Ｗ１Ｈで次開発プロジェクトでの具体的なアクションを記載

FOPA TRY宣言に転記
区分 ＃いつ？
（いつまに？） 誰が？
FOPA TRY宣言(TRY宣言対象の内容 When？（By (Who?)
When?)を転記しよう！)

何を？
(What?)

どのように行うか？
(How?)（真因分析した結果、3W1Hでアクションを記載しよう。）
PRO 1 プロセス開始の準備時に、次のバージョン 開発プロジェ 有識者の割り当 ・レビュー計画を立案する。
BLE
有識者のレビュー時間を アップ開発プロ クトAのプロ てとレビュー計画 ・有識者を割り当て、レビュー時間をM確保する計画を立てよ ジェクトBのシス ジェクト確保する。
う！
テム設計段階 リーダー
Sさん
PRO 2 ・設計開始前に、企画部 2018年4月以 組織Aのシステム設計・企画部門と会議体を開き、要件に誤BLE門と会議を開き、要件を 降の組織Aの開 Fさんりがないかを確認する。
M
確認しよう！
発プロジェクト・レビュー完了後万一要件が変更にな・要件変更管理を徹底しる場合は、要件変更管理を運用する。
よう。

Copyright (C) 2018 SQiPソフトウェア管理研究会 All Rights Reserved

13２回目：振り返りフレームワークのご意見

試行 ＆アンケート

それぞれのフレームワークにおける適用のタイミングは？
ふ～ん。フレームワークの良さは分かった。
でも、これらのシートの適用タイミングがわからないよね？

個々のシートを使うタイミングをプロセス化します？

そうだ！FOPAの精神でもう一回、奮起してみよう！

フォローアップ
対象者を動かすためのプロセスを作ります？

＜FOPAドリンクを飲んで、FOPA精神を思い出せ！＞＜オリンピック選手に負けずにがんばれ！＞

Copyright (C) 2018 SQiPソフトウェア管理研究会 All Rights Reserved

Full persuasive:十分な納得性をもってOrganized Process of retrospective:組織的な振り返りプロセスをwith Aggressiveness:積極的に意思をもって行動する

14FOPA 振り返りプロセス PDCAサイクル「FOPA KPTシート」をメインに活用した組織横断的、かつ継続的な振り返りを実現
個人/チームでの振り返り準備

プロジェクト振り返り会

ＦＯＰＡ 観点チェックシート

ＦＯＰＡ ＫＰＴシート
ＦＯＰＡ ＴＲＹ宣言（3W1H）
When？（By When?)Who？
What？How？

ＦＯＰＡ ＫＰＴシート

ＦＯＰＡ なぜなぜ分析シート
各自で記入
TRY宣言のStatus管理（CLOSE/継続）
ＦＯＰＡ ＫＰＴシート
FOPA TRY宣言status
効果がなかったからCLOSEしよう

プロジェクトフォローアップ
FOPA TRY宣言、守れているかな？
Copyright(C) 2018 SQiPソフトウェア管理研究会
All Rights Reserved
次開発プロジェクトＢのPMO
Nさん

ＦＯＰＡ ＫＰＴシート
フォローアップ対象者の指定実行支援してね
次開発プロジェクトＢのPMＯ Ｎさん

前開発PJ AのPLのAさん

次開発PJ BのPＭのTさん

前開発プロジェクトAのPＭのＴさん

プロジェクトへの適用

FOPA TRY宣言、TRY宣言と・・・【詳細は論文_付録１ご参照】

次開発PJ BのPＭのTさん 15

最終検証結果：FOPA振り返りプロセス

試行 ＆アンケート

FOPA 振り返りプロセスを、実務適用してもらった結果、大好評！
振り返り意見の数も、2.5倍。業務改善に大幅に貢献！２社で採用決定！
２社で採用決定！
振り返り意見の数も、2.5倍
振り返りの観点チェックの網羅性、上がった！

効果の低いプロセスの削減に効くね！

TRYのスコープが明確で実行支援に役立つね！

従来のＫＰＴより納得性のある振り返りができるね！
2社で採用決定！
試行前より、振り返り意見が2.5倍に増えたよ！

業務改善につながるね

ありがとう！
FOPAマン！！
Copyright (C) 2018 SQiPソフトウェア管理研究会 All Rights Reserved

16試行 ＆アンケート

最終検証結果まとめ：FOPA振り返りプロセス

・いずれのシートも効果あり！という結果が出た．
なかでも、TRYの展開先スコープ、観点チェックシート、振り返りTRY宣言 が好評．
・より具体的な実行支援体制を求める意見あり、今後の課題。【詳細は論文_表6ご参照】
振り返りの課題

FOPA 振り返りプロセスの提案

検証結果

TRYに対して納得感が低い

KEEP/
PROBLEMの網羅性が不十分

FOPA観点チェックシート○：観点チェックシートは網羅性向上に有効

KEEP/
PROBLEMの真因分析が不十分

FOPA KPTシート
FOPA真因分析シート
FOPAなぜなぜ分析シート〇：深く考える機会を与えてくれる．
×→○：重要度が自社に合わない．
→カスタマイズできる運用に変更

TRYの実践が個人／チーム任せ

情報伝達する仕組みが不確定

FOPA TRY宣言◎：TRYの展開先スコープが最も有効

実行支援体制が不確定

TRY実行支援方法のプロセス化〇：FOPA TRY宣言:担当者の意志が明確に伝達(次開発プロジェクトの実践に有効）

凡例： ◎：有効なコメントが多数 ○：有効
Copyright (C) 2018 SQiPソフトウェア管理研究会 All Rights Reserved〇：次開発プロジェクトで実践状況を共有する上で有効．
△：いつ誰がフォローするのかが不明確。
CLOSEの基準を決めるべき△：改善が必要もしくは特に意見なし

×:無効17

研究会テーマ 総合見解（今後の展望）
FOPA振り返りプロセスは皆様の会社でも振り返り会に使えそうでしょうか？

更に実務に取り入れるための目安として・・・
適用不要

強

一部必要

【判断】分析内容の組織的な展開が不十分【適用範囲】【判断】従来の方法でも大丈夫！ 「FOPA KPTシート」を使って、重要度に応じて組織展開を図ろう！

一部必要

必要

【判断】振り返り観点や分析内容が不十分【判断】適用必須！
【適用範囲】【適用範囲】「FOPA 観点チェックシート」
FOPA 振り返りプロセスを全て使おう！
「FOPA 真因分析シート」「FOPAなぜなぜ分析シート」を使おう！

強組織的改善能力

弱振り
返り分析能力弱

振り返りができていない・弱いと感じた方は、是非、御社に見合ったカスタマイズを図りつつ、実務へ浸透させてください！
【詳細は論文_表８ご参照】
Copyright (C) 2018 SQiPソフトウェア管理研究会 All Rights Reserved

18

研究コース１ ソフトウェアプロセス評価・改善 チームFOPA一同FOPA精神をモットーにした 研究員よりFujitsu
Naito
Panasonic
Arakawa

Copyright (C) 2018 SQiPソフトウェア管理研究会 All Rights Reserved

Omron
TanakaAPRESIA Systems
Nakagawa

19

APPENDIX

Copyright (C) 2018 SQiPソフトウェア管理研究会 All Rights Reserved

20

「振り返り」に関する過去論文
2011年度、2012年度でKWS（KPT Why Solution)手法として提示された。

Copyright (C) 2018 SQiPソフトウェア管理研究会 All Rights Reserved

21

KWS手法における貢献
KWS手法としての貢献は以下のようなポイントにある。

ブレーンストーミング、付箋紙で意見収集→網羅性を上げる

なぜなぜ分析の導入→納得性を持たせる

Copyright (C) 2018 SQiPソフトウェア管理研究会 All Rights Reserved

管理層支援のもと→実行支援を行う

コミュニケーションフレームワークの活用→管理層向の情報伝達ができる22

しかしながら・・・（KWS手法の課題）
KWS手法はリスペクトしつつも、以下の課題があると認識。
KWSの功績

KWSのTRYを実践するにあたり以下の課題があり。

ブレーンストーミング、
付箋紙で意見収集→網羅性を上げる担当者の発想に委ねられる。
体系的な網羅性の保証が必要。

なぜなぜ分析の導入→納得性を持たせる

全てを真因分析→時間がかかり運用できない。
真因分析結果→分析が浅くなり納得性が得られない。→真因分析のスコープ（範囲）定義が必要

コミュニケーションフレームワークの活用→管理層向の情報伝達ができる×管理層への情報伝達ではなく、〇次開発プロジェクト担当者への情報伝達が大切

管理層支援のもと→実行支援を受ける
納得性のいくTRYを登録し続ける実行支援体制としては、実務に関わる開発メンバーへの実行支援が必要
プロセスの肥大化が起こる→プロセス肥大化を防止する仕組みが必要

Copyright (C) 2018 SQiPソフトウェア管理研究会 All Rights Reserved

23

個人／チームでの振り返り準備（FOPA観点チェックシート）
担当者の発想に委ねられる。
体系的な網羅性の保証が必要。

FOPA観点チェックシートを使用。
PMBOKRガイド、共通フレーム2013観点で体系的な振り返り網羅性を上げる。
＜分類（ソフトウェア実装）：開発メンバー向け＞
分類（共通フレーム”SLCP-

共通フレーム2013

JCF2013”ソフトウェア実装プ
ロセスのアクティビティ）説明（タスク）

具体的要求事項

KEEP/
PROBLEM/
IDEA

KEEP
ソフトウェア実装
プロセス開始の準備

・開発作業の組み立て・必要なプロセスの組み込み・開発環境の整備
・ソフトウェア実装プロセスの実施計画作成
・非納入品目の使用の容認

・プロジェクトの範囲、規模、複雑さに応じたライフサイクルモデルを定義
または選択できていたか
PROBLEM・ソフトウェア実装プロセス及び支援プロセスを行うために、組織によって文書化され、適切であり、確立されている作業標準、方法、ツール及びIDEA計算機プログラム言語を選択していたか

観点チェック
確認

備考(観点チェック確認結果の理由など自由記入)

×：該当事例なし

KEEP
PROBLEM
×：該当事例なし
IDEA（PROPOSAL)(PROPOSAL)

×：該当事例なし

KEEP/
PROBLEM/
IDEA

観点チェック
確認＜分類（PMBOK知識体系）：プロジェクトマネージャー、チームリーダー向け＞
分類（PMBOK）

説明

具体的要求事項

KEEP

PMBOK
®ガイド

統合管理

・開発計画（開発機能、開発プロセス、体制、想定顧客など）の変更や、プロジェクト内の各プロセスとプロジェクトマネジメント活 開発中のQCDの不備が生じた際に開発計画書を最新化していたか PROBLEM
動を識別、統合、統一、調整する
・特に最新化していなかった場合は情報共有に問題が無かったか確認
IDEA
していたか

(PROPOSAL)

Copyright (C) 2018 SQiPソフトウェア管理研究会 All Rights Reserved

備考(観点チェック確認結果の理由など自由記入)

×：該当事例なし
×：該当事例なし
×：該当事例なし
24

FOPA観点チェックシート（ご参考）担当者の発想に委ねられる。
体系的な網羅性の保証が必要。

共通フレーム2013、 PMBOKRガイド観点で体系的な振り返り網羅性の保証が可能。
分類（共通フレーム”SLCPJCF2013”ソフトウェア実装プロセスのアクティビティ）

共通
フレーム
２０
１
３

ソフトウェア実装
プロセス開始の準備

ソフトウェア要件定義

ソフトウェア方式設計

ソフトウェア詳細設計

ソフトウェア構築（プログラミング）

ソフトウェア結合

ソフトウェア適格性確認テスト

ソフトウェア導入

ソフトウェア受け入れ
支援

説明（タスク）分類（PMBOKRガイド）・開発作業の組み立て・必要なプロセスの組み込み・開発環境の整備
・ソフトウェア実装プロセスの実施計画作成
・非納入品目の使用の容認
・ソフトウェア要件の確立
・ソフトウェア要件の評価
・ソフトウェア要件の共同レビューの実施※便宜上、システム要件定義、システム設計含む
・ソフトウェア構造とコンポーネントの方式設計
・各インターフェースの方式設計
・データベースの最上位レベルの設計
・利用者文書（暫定版）の作成
・ソフトウェア結合のためのテスト要件の定義
・ソフトウェア方式設計の評価
・ソフトウェア方式設計の共同レビューの実施
・ソフトウェアコンポーネントの詳細設計
・ソフトウェアインターフェイスの詳細設計
・データベースの詳細設計
・利用者用文書の更新
・ソフトウェアユニットのテスト要件の定義
・ソフトウェア結合のためのテスト要件の更新
・ソフトウェア詳細設計及びテスト要件の評価
・ソフトウェア詳細設計の共同レビューの実施
・ソフトウェアユニット作成及びテスト手順とテストデータの作成
・ソフトウェアユニットのテストの実施・利用者用文書の更新
・ソフトウェア結合テスト要件の更新
・ソフトウェアコード及びテスト結果の評価
・ソフトウェア結合計画の作成
・ソフトウェア結合テストの実施・利用者用文書の更新
・ソフトウェア適格性確認テストの準備
・ソフトウェア結合の評価
・ソフトウェア結合の共同レビューの実施
・ソフトウェア適格性確認テストの実施・利用者用文書の更新
・ソフトウェア適格性確認テストの評価
・ソフトウェア適格性確認テストの共同レビューの実施
・監査の支援・納入ソフトウェア製品の準備※便宜上システム適格性確認テストを含む。
・ソフトウェア導入（インストール）計画の作成
・ソフトウェア導入の実施
・取得者の受け入れレビューと受け入れテストの支援
・ソフトウェア製品の納入
・取得者への教育訓練及び支援

Copyright (C) 2018 SQiPソフトウェア管理研究会 All Rights Reserved

プロ 統合管理ジ スコープ管理
ェク タイム管理
トマ コスト管理
ネジ 品質管理メ 人的資源管理
ン コミュニケーション管理
ト知 リスク管理
識体 調達管理系 ステークホルダー管理

説明
プロジェクト内の各プロセスとプロジェクトマネジメント活動を識別、統合、統一、調整する
プロジェクトの範囲、成果物、作業を過不足なく定義する。
プロジェクト中の作業を見積もり、スケジュールおよびマイルストン時期を計画する。また、計画時期通りに完了できるように、定期的に監視・コントロールする。
プロジェクト予算を設定し、定期的にコスト状況を管理する。
プロジェクトの品質ニーズを満たすために、品質方針、品質計画、品質目標を設定し、対象物の品質を監視・モニタする。
プロジェクト・チームを組織化し、マネジメントする。
ステークホルダおよびチームメンバーに対して、必要な情報をタイムリーに提供する。
ステークホルダーのニーズについての計画とマネジメントを行い、意思決定等にステークホルダーを適切に関与してもらう。
外部が保有している技術や成果物を、プロジェクトに活用する。そのための、外部技術や成果物の調達計画・管理を行う。
プロジェクトの問題を未然に防止するため、リスクを計画、識別、分析、監視、コントロールする。
25

個人／チームでの振り返り準備（FOPA なぜなぜ分析シート）
FOPAなぜなぜ分析シートを使用。重要度が３もしくは４の場合、真因分析を実施。
事象
下流工程で、設計者が想定した影響範囲以外の領域で、不具合が多発した。

なぜ１
なぜ、下流工程で、不具合が多発したのか？

なぜ２
なぜ、上流工程で、設計の内部的影響範囲を見誤ったのか？

なぜなら、上流 なぜなら、内部工程で、設計の 設計の影響範囲内部的影響範囲 を、設計者とレを見誤ったから。 ビューアが見誤ったから。

なぜ３
なぜ４
なぜ、レビューア なぜ、有識者がが影響範囲を見 参加しなかった誤ったのか？のか？

なぜ５
どうしたら、有識者に参加してもらえるか？

なぜなら、有識者がレビューに参加しなかったから。

プロジェクト立ち上げ時に計画しておき、設計またはレビューを依頼する。

なぜなら、有識者の割り当てを計画していなかったから。

真因分析 実施
何がどうしてどうなっただからこうしよう（TRY)
ソフトウェア詳細設計 影響範囲を見誤った 不具合を流出させ、 プロセス開始の準備時に、で、レビューアがので、下流工程の品質が悪 有識者のレビュー時間をくなった。
確保する計画を立て、確実にレビューを実施してもらおう！

FOPA KPTシートへ転記
Copyright (C) 2018 SQiPソフトウェア管理研究会 All Rights Reserved

26

TRY宣言のstatus管理（FOPA KPTシートのstatus管理）
実行支援状況の管理

プロセスの肥大化が起こる→プロセス肥大化を防止する仕組みが必要

フォロー
補足（CLOSEの場合は、必ず理由を記入）○月○○日に会議体
実行中 を開き、要件の妥当性を確認予定。

Statusフォロー
補足（CLOSEの場合は、必ず理由を記入）
開発プロセス定義書にCLOSE 記載して、運用が定着したため、CLOSE

StatusStatusを「実行中」から「CLOSE」に変更

本件は運用が定着したので次開発プロ
ジェクトからはTRY
宣言対象から外していいよね？
Copyright (C) 2018 SQiPソフトウェア管理研究会 All Rights Reserved27