振り返りを力強く推進する「FOPA 振り返りプロセス Ver.2」の提案
-
効率的で納得感の高い振り返り分析と，TRY 実行支援活動の具体化
-Proposal of ”FOPA Retrospective process Ver.2" that powerfully supports Retrospective
- Efficient and high convincing Retrospective and embodiment of TRY execution
support-オムロン株式会社 APRESIA Systems 株式会社
OMRON Corporation APRESIA Systems, Ltd.
田中 桂三 中川 幸治
Keizo Tanaka Yukiharu Nakagawa
概要
本論文では開発プロジェクトの振り返り分析と TRY(改善点)実行の問題を解決する手法 について述べる．振り返りで挙がった TRY(改善点)が次の開発プロジェクトで実行されな いという問題について，その原因を「振り返り分析の不十分さ」および「担当者に依存し た TRY の実行」の 2 点と捉え，対策として「FOPA 振り返りプロセス Ver.1」を作成した． 本プロセスにより観点網羅と真因分析による振り返り分析の十分性の確保，および PMO/SEPG による TRY の実行支援の仕組みを確立した．さらに開発現場での実運用を想定し， 振り返り分析の効率化と十分性の両立と TRY の実行支援活動の具体化を行い「FOPA 振り返 りプロセス Ver.2」として改良した．本プロセスは開発現場の運用に適合しており，開発 担当者の業務改善活動を「力強く推進」するプロセスであることを確認した． Abstract
This paper reports a method that resolved an issue of Retrospective activity and execution of TRY items (improvement measures) in a development project. About the issue that TRY found in the Retrospective activity is not utilized in the next development project, we ascertained that the causes are "insufficient Retrospective analysis" and "TRY execution depending on members". We created "FOPA Retrospective process Ver.1" to solve them. This process ensures the sufficiency of Retrospective analysis by “Coverage of view point” and “Root Cause Analysis” and establishes an organizational execution support of TRY items. In addition, we improved the process considering actual usage in development site and created "FOPA Retrospective process Ver.2" that offers the balancing of efficiency and sufficiency of Retrospective analysis, and embodiment of TRY execution support. We confirmed that this process will conform to operation of our development site and promote the improvement activities of development members powerfully. 1. はじめに 前開発プロジェクト(以下，前開発PJ)の振り返り分析で挙がったTRY(改善点)を，次の 開発プロジェクトや類似他製品の開発プロジェクト(以下，次開発PJ)で十分実行していな い問題がある[1]．本問題を解決するために「FOPA 振り返りプロセス Ver.1」[6]を作成した． さらに，開発現場での実行を通じて「より手軽に振り返り分析を行い，かつTRYの実行支援 活動を明確にしてほしい．」という意見を受け，「FOPA 振り返りプロセス Ver.2」として改 良し，前開発PJの振り返り分析の効率化と次開発PJのTRYの実行支援活動の具体化を行った． 以降，2 章では本論文の背景(開発プロジェクト振り返りの問題など)について述べる．3 章では，振り返りの問題を解決するために提案した「FOPA 振り返りプロセス Ver.2」の説 明と期待効果について述べる．4 章では，FOPA 振り返りプロセスの有効性を検証するため の実験方法と実験結果について述べる．5 章では実験結果を受けて，振り返りの問題が FOPA 振り返りプロセス Ver.2 により解決できたかについて考察する．最後に 6 章では，本プロ セスの成果まとめと今後の展開について述べる． 2. 本論文の背景 2.1 振り返りに関する問題(前開発 PJ の振り返り分析と次開発の TRY 実行における問題）
ウォーターフォール型で 3 か月～1 年の期間で製品のバージョンアップを繰り返す，あ るいは類似他製品への展開を行うソフトウェア開発を想定する．振り返り分析として著名 な KPT 手法(KEEP(開発プロジェクトでの良い点)と PROBLEM(問題点)を抽出し，それに応じ た TRY(改善点)を挙げる手法)がある[2].開発現場では次開発 PJ で TRY を実行しない問題が 発生している．原因として「振り返り分析の不十分さ(TRY に対する納得感の低さ)」，「担 当者に依存した TRY の実行」の 2 点が存在する[6]． ＜前開発 PJ の振り返り時：振り返り分析の不十分さ(TRY に対する納得感の低さ)＞ 前開発 PJ の振り返り分析(KEEP/PROBLEM の抽出，およびそれらから TRY を導く過程の作 業)が不十分であると，次開発 PJ のリーダーやメンバー(以下，担当者)にとって振り返り に対する納得感が低くなり，TRY の実行をためらってしまう[6]． ＜次開発 PJ の TRY 実行時：担当者に依存した TRY の実行＞ 振り返り分析により導出した TRY について，開発担当者がその実行を任されるが，実行 状況や完了の確認は行われていない．そのため，開発プロジェクトの QCD 問題に関わる重 要な TRY であっても実行されないことがある．[6] 2.2 FOPA 振り返りプロセス Ver.1 の成果，および問題 2.1 節に挙げた TRY が実行されない原因を解決するため，SQiP33 年度研究活動で”振り 返り活動を力強く支援する「FOPA 振り返りプロセス」の提案[6]”を作成した．FOPA とは
“Full persuasive Organized Process with Aggressiveness"の略称であり，積極性をベ ースとした十分な納得感を持つ組織的改善プロセスの造語である．特徴を以下に述べる． ・振り返り分析の不十分さの対策として，「FOPA 観点チェックシート利用」と「FOPA なぜ なぜ分析シート利用」により納得感の高い振り返り結果を導出する．
・TRY が十分実行されない対策として，「FOPA TRY 宣言の実行」により次開発 PJ 担当者に 意志を持って TRY を伝え理解を得る.また「PMO/SEPG による TRY の実行支援」を行う．
Ver.1 の試行によるアンケート調査や担当者からのヒアリング から，成果として FOPA 観 点チェックシート利用により KPT の数が 2.5 倍になった事例や TRY の展開先スコ―プが明 確になり TRY が実行し易いなど，有効な結果を得ることができた．しかし問題として，振 り返り分析の効率化と TRY の実行支援活動の具体化を求める声が挙がった(表 1 参照)．
表 1 TRY が実 行され ない原因 ，FOPA 振り 返りプ ロセス Ver.1 の提案 と問題[6]
TRY が 実 行さ れ ない 原 因 原 因 の 説明 Ver.1 の 提案 Ver.1 の 問題
前 開 発 PJ の 振 り 返 り 時 ： 振 り 返 り 分 析 の 不 十 分 さ (TRY に 対 す る 納 得 感 の 低 さ ) KEEP/PROBL EM の 網 羅性 の 不 十 分さ 次 開 発 PJ の 担 当 者 が 振 り 返 り 結 果 を 見 て ，以下 の 観点 網羅 の 疑念 が生 じ る ． 「 振 り 返り 担 当者 の 思い 付きや ，興 味 の 範 囲 で 挙げ て いる の では ないか ？ 」 「 も っ と重 要な KEEP/PROBLEM が 存 在 す る の で は？ 」 担 当 者 の 発 想 の み に 委 ね ら れ ない ，体 系 的な 網 羅 性 を 保証 す る. 【 FOPA 観 点 チ ェ ッ ク シ ー ト 利 用】 観 点 網 羅 や 真 因 分 析 を 行 う 作 業 が 必 須 と な る の で ， 振 り 返 り 分 析 に 時 間 が か か り 担 当 者 の 負 担 が 増 す ． KEEP/PROBL EM の 真 因分 析 の 不 十 分 さ 次 開 発 PJ の 担 当 者 が 振 り 返 り 結 果 を 見 て ， 以 下 の 分 析 の 十 分 性 に 対 す る 疑 念 が 生 じる ． 「 KEEP/PROBLEM の表 面 的な 結果 だ け を 見 て 短 絡的 に TRY を 導出 してい る の で は な い か？ 」 な ぜ な ぜ 分 析 に よ る KEEP/PROBLEM の 真 因 分 析 を 実 施す る .[5] 【 FOPA な ぜ な ぜ 分 析 シ ー ト 利 用】 次 開 発 PJ の TRY 実 行 時 ： 担 当 者 に 依 存 し た TRY の 実 行 TRY を 伝 え 理 解 を し て も ら う 仕 組 み が 不 確定 前 開 発 か ら 次 開 発 に 担 当 者 ベ ー ス で TRY を 伝 えて い る． その た めに TRY の 情 報 伝 達漏 れ が発 生 する 場合が あ る ． 次 開 発 PJ 担 当 者に TRY を 伝 え 理解 を 得る ． 【 振 り 返 り 会 で の FOPA TRY 宣 言 によ る 次開 発 PJ 担 当 者 への 伝 達】 PMO/SEPG に よ る TRY の 実 行 支 援 体 制 は で き た が ， 支 援 活 動 が 不 明 確 で あ る た め ，次 開 発 PJ で 確 実 な TRY の 実 行 支 援 は 難 し い ． TRY の 実 行 支 援 活 動 が 不 確 定 担 当 者 の 改 善 へ の 意 欲 が 低 い ， ま た は 繁 忙 な 開 発 プ ロ ジ ェ ク ト で は ， TRY が 実 施 さ れな い 可能 性 が生 じる ． 担 当 者 に 任 せ る だ け で な く ，組 織 的な 開 発支 援 体 制 を 導入 す る 【 PMO/SEPG に よ る TRY の 実 行 支援 】
3. FOPA 振り返りプロセス Ver.2 の提案と Ver.1 からの改良内容 3.1 FOPA 振り返りプロセス Ver.2 の概要
開発プロジェクトの振り返りにおける問題を解決するために，我々は「FOPA 振り返り プロセス Ver.2」へ改良した．特徴は次の 4 点(①～④)である．
・振り返り分析の効率化： ①振り返り分析の経験を積んだ担当者を配慮した，FOPA 観点 チェックシート及び FOPA なぜなぜシートの任意使用ルールの追加(3.2 (3)節で説明). ・強力な支援活動の具体化： ②チケット駆動開発の実行による TRY のチケット管理 ③ 開発プロジェクトの既存会議で TRY の実行状況確認 ④PMO/SEPG が担当者を強力に支援 (3.3 節で説明)
Ver.1 と Ver.2 の差異を明示するために，以降 Ver.2 の改良ポイントには“Ver.2”を付 記する．図 1 と表 2 に FOPA 振り返りプロセス Ver.2 のイメージと提案内容を表す．本プ ロセス(Ver.2)を各社で追加試行してさらにアンケート調査を行い ，有効性を検証した.
図 1 FOPA 振り返 りプロセ ス Ver.2 イメ ージ図
表 2 TRY が実 行され ない 原因 に対する FOPA 振り返りプ ロセス Ver.2 の各提案 と期 待効果
TRY が 実 行さ れ ない 原 因 解 決 方 針 FOPA 振り 返 りプ ロ セス Ver.2 の 各 提 案
前 開 発 PJ の 振 り 返 り時： 振 り 返 り 分 析 の 不 十 分 さ (TRY に 対 す る 納 得 感 の 低 さ ) KEEP/PROBL EM の 網羅 性 の 不 十 分さ 担 当 者 の 発 想 の み に 依 存 し な い 体 系 的 な 網 羅性 の 保証 「 効 率 的 で 納 得 感 を 高 め る 振 り 返 り 分 析 」 「 FOPA 観 点 チ ェ ッ ク シ ー ト 」 期 待 効 果： 体 系的 な KEEP/PROBLEM 観 点 網羅 (3.2 (1) 節 参 照 ) KEEP/PROBL EM の 真因 分 析 の 不 十 分 さ な ぜ な ぜ 分 析 に よ る KEEP/PROBLEM の 真 因 分 析 を 実 施 す る . [5] 「 FOPA な ぜ な ぜ 分 析 シ ー ト 」 期 待 効 果： 問 題の 本 質を 捉えた 真 因 分析 の 導出 (3.2 (2)節 参 照 ) 「 FOPA KPT シ ー ト 」 期 待 効 果：振り 返 り結 果 の整 理 (3.2 (4)節 参 照) 振 り 返 り 分 析 に 時 間 が か か り ， 担 当者 の 負担 増 ． 振 り 返 り 分 析 の 経 験 豊 富 な担 当 者 「 FOPA 観 点 チ ェ ッ ク シ ー ト 」と 「 FOPA な ぜ な ぜ 分 析 シ ー ト 」 <Ver.2： 任 意 > 期 待 効 果： 振 り返 り 分析 の効率 化 (3.2(3)節参 照 ) 次 開 発 PJ の TRY 実 行 時： 担 当 者 に 依 存 し た TRY の 実 行 TRY を 伝 え 理 解 し て も ら う 仕 組 み が 不 確 定 次 開 発 PJ 担当 者 に TRY を 確 実に 伝 え ， TRY の 必 要 性 の 理 解 を 得 る． 「 FOPA TRY 宣 言 」 と 「 PMO/SE PG に よ る 実 行 支 援 活 動 の 具 体 化 」 「 FOPA TRY 宣 言 」 期 待 効 果： FOPA TRY 宣言 に よる 意 志 入れ /次開 発 PJ へ TRY を 伝 え 理解 を 得る (3.3 (1)節 参 照 ) 「 チ ケ ッ ト 駆 動 開 発 に よ る TRY の チ ケ ッ ト 管 理 」 <Ver.2： 追 加 > 期 待 効 果 ： TRY の 見 える 化 によ る 情 報 伝 達 (3.3 (2)節 参 照 ) TRY の 実 行 支 援 活 動 が 不 確 定 TRY 実 行 に向 け ，担 当 者 に 任 せ る だ け で な く PMO/SEPG に よ る TRY の実 行 支 援 活 動 を導 入 する 「 開 発 プ ロ ジ ェ ク ト の 既 存 会 議 で 状 況 確 認 」 <Ver.2： 追 加 > 期 待効 果： 確実 な 状 況確 認 (3.3 (3)節 参照 )
PMO/SEPG が TRY の 実 行 を 強 力 支 援 <Ver.2： 追 加 > 期 待 効 果： 確 実 な TRY の 実行 (3.3 (4)節 参照 ) 3.2 十分な振り返り分析による TRY の導出
KEEP/PROBLEM の 網 羅 性 の 確 保 の た め に FOPA 観 点 チ ェ ッ ク シ ー ト を 用 い る ． ま た KEEP/PROBLEM の問題の本質を捉えるために FOPA なぜなぜ分析シートで真因を導出する．
その後 FOPA KPT シートで分析結果を整理して，次開発 PJ で実行すべき TRY を選定する． (1) FOPA 観点チェックシート(KEEP/PROBLEM の網羅性の確保) KEEP/PROBLEM の抽出が担当者の発想のみに委ねられないよう ，体系的な網羅性の観点と して，世間に認知度の高いフレームワークを用いて分析する．開発メンバー向けの観点に は「共通フレーム 2013[3]」のソフトウェア実装プロセスのアクティビティを，管理者向け の観点には「PMBOK 知識体系ガイド」［ 4］を採用し，「FOPA 観点チェックシート(図 2 参照)」 として振り返りの観点の網羅性を確保できるように する．これにより，次開発 PJ 担当者が 振り返りの結果に対して納得感を持って理解することを期待する． 図 2 FOPA 観 点 チ ェ ッ ク シ ート イ メ ー ジ (マ ネ ジ メ ン ト 向 けの 一 部 ) (2) FOPA なぜなぜ分析シート(真因分析) 真因分析を行うことで前開発 PJ に特化した KEEP/PROBLEM が適度に抽象化され，次開発 PJ に適切な TRY 内容や展開先を定義できる．真因分析手法として，KWS 法[5]で用いられて い る 「 な ぜ な ぜ 分 析 」 手 法 を 採 用 す る ． 本 プ ロ セ ス で は 図 3 の 形 式 を 採 用 す る ． KEEP/PROBLEM 全てを対象にすると次開発 PJ で焦点が定まらず真因分析が浅くなるので， 重要度の高いもの(表 3 の重要度 3 と 4)を対象にする．重要度の考え方については組織・ 製品の特徴や開発プロジェクトの位置づけによって異なるため任意に設定する運用とする． 図 3 FOPA な ぜ な ぜ 分 析 シ ート イ メ ー ジ 表 3 KEEP/PROBLEM の 重 要 度 重 要 度 レ ベ ル 例 1(展 開 先) レ ベ ル 例 2(計 画 ) な ぜ な ぜ分 析 ,TRY 宣 言 4:と て も重 要 組 織 全 体 計 画 よ り 50%以 上遅 れ 対 象 3:重 要 プ ロ ジ ェク ト 全体 計 画 よ り 30％ 超 ～50％ 未満 遅れ 2:普 通 チ ー ム 内 計 画 よ り 10％ 超 ～30％ 未満 遅れ 対 象 外 1:軽 微 個 人 計 画 よ り 10％ 未 満遅 れ
(3) FOPA 観点チェックシート，FOPA なぜなぜ分析シートの任意利用＜Ver.2＞
FOPA 観点チェックシートと FOPA なぜなぜ分析シートの利用は任意とする．「振り返り の経験を積んだ人には不要」という現場の声を反映したためである．過去の振り返り結果 に不満足な人や振り返りに不慣れな人のために両シートを利用する運用とする． (4) FOPA KPT シート ・KEEP/PROBLEM/IDEA/TRY 記入 振り返りで挙がった KEEP/PROBLEM/IDEA/TRY(表 4 参照)を FOPA KPT シート上(図 4 参照) で整理する．また，全ての KEEP/PROBLEM を対象に TRY を行うと，項目が多くなり次開発 PJ で全て実行できない恐れがある．「振り返りアセスメント」を行い ，重要度を判断する． 表 3 のうち原則重要度 3(重要)と 4(とても重要)を TRY の対象とする． 分類 （PMBOK） 説明 具体的要求事項 KEEP/ PROBLEM/ IDEA 観点チェック 確認 備考(観点チェック確認結 果の理由など自由記入) KEEP ○：該当事例あり 有識者レビューを受 けたので、見積もりと 実績の差異なし PROBLEM ○：該当事例あり見積もり通りなのに、 計画遅れ発生 IDEA (PROPOSAL) ○：該当事例あり アジャイル開発にお けるSPRINT毎の EVMの採用 KEEP ○：該当事例あり ISO/IEC25010品質 モデルによる品質観 点の導出 PROBLEM ○：該当事例あり 工程完了時の品質 分析で、定量値以外 に、定性的な見解が 必要 IDEA (PROPOSAL) ○：該当事例あり自動テストの品質尺度の設定（テスト工 数の考え方を整理） コストの基準値はクリアしていたか また、特にクリアできていない場合に下記の内容は 妥当であるか確認したか ・コストについての計画との予実差を定期的に確認し ていたか ・計画時の見積もり手法は妥当であったか 品質基準（工程完了条件など）をクリアしていたか。 また、特にクリアできていない場合に下記の内容は 妥当であるか確認したか ・盛り込んだ品質施策の内容は妥当であったか ・品質尺度は妥当性か ・品質基準値そのものの妥当性について検証したか ・品質状況は工程内だけでなく、工程間（設計工程の 品質不備がプログラム工程に影響していないか 等） を検証していたか コスト管理 品質管理 プロジェクト予算を設 定し、定期的にコスト 状況を管理する。 プロジェクトの品質 ニーズを満たすため に、品質方針、品質計 画、品質目標を設定 し、対象物の品質を監 視・モニタする。 事象 なぜ１ なぜ２ なぜ３ なぜ４ なぜ５ 何が どうして どうなった だからこうしよう（TRY) なぜ、下流工程 で、不具合が多 発したのか？ なぜ、上流工程 で、設計の内部 的影響範囲を 見誤ったのか？ なぜ、レビュー アが影響範囲を 見誤ったのか？ なぜ、有識者が 参加しなかった のか？ どうしたら、有識 者に参加しても らえるか？ ソフトウェア 詳細設計で、 レビューアが 影響範囲を見 誤ったので、 不具合を流出 させ、下流工程 の品質が悪く なった。 なぜなら、上流 工程で、設計の 内部的影響範 囲を見誤ったか ら。 なぜなら、内部 設計の影響範 囲を、設計者と レビューアが見 誤ったから。 なぜなら、有識 者がレビューに 参加しなかった から。 なぜなら、有識 者の割り当てを 計画していな かったから。 プロジェクト立ち 上げ時に計画し ておき、設計ま たはレビューを 依頼する。 プロセス開始の準 備時に、有識者の レビュー時間を確 保する計画を立 て、確実にレ ビューを実行しよ う！ 下流工程で、設 計者が想定した 影響範囲以外の 領域で、不具合 が多発した。
表 4 FOPA TRY 宣 言 の イ メ ージ KPT 分 類 KPT 意 義 KEEP 前 開 発 PJ の 中で ， 今後 も 継続し た い こと PROBLEM 前 開 発 PJ の 中で ， 今後 に 向けて 改 善 した い こと IDEA 次 開 発 PJ で ，周 り に提 案 したい こ と TRY KEEP/PROBLEM/IDEA を 受け ， 自分 が 取 り組 み たい こ と 図 4 FOPA KPT シ ー ト イ メ ー ジ(PROBLEM の 整 理 ， 振 り 返 り アセ ス メ ン ト 例 )
3.3 FOPA TRY 宣言による情報伝達と PMO/SEPG による TRY の実行支援活動の具体化 Ver.1 で評価が高い FOPA TRY 宣言を Ver.2 でも継承し，振り返り分析で挙げた TRY 内容 を次開発 PJ の担当者に引き継ぐ．また Ver.2 では，次の（2）～（4）の 3 点を明確に定義 し，次開発 PJ での TRY の実行支援活動の具体化を行う．
（1）次開発 PJ 担当者への確実な TRY の情報伝達(FOPA TRY 宣言)
前開発 PJ の振り返り会の場に次開発 PJ の担当者と開発支援の役割を持つ PMO または SEPG(以下,PMO/SEPG)が参加する．前開発 PJ 担当者は，意志を持って「FOPA TRY 宣言」を 行い，次開発 PJ の担当者に TRY の必要性の理解を得る ．アクションを明確化するため に,3W1H を記載する(図 5)．その後次開発 PJ の担当者は，次開発 PJ の会議で他の関係者に TRY の内容説明を行い，TRY の必要性の理解と実行の了解を得る.
図 5 FOPA KPT シ ー ト イ メ ージ (FOPA TRY 宣 言 の 例 ) (2) チケット駆動開発の実行による TRY のチケット管理 ＜Ver.2＞ チケット駆動開発を活用し TRY を管理する．なぜなら各社現場でチケット駆動開発を導 入しているためである．構成管理ツール(Redmine や TFS など)を用いてチケットにより TRY のライフサイクル(実行～定着～CLOSE)を管理することで，PMO/SEPG が TRY のステータス を容易に確認し，次開発 PJ での TRY の実行を適確に支援できる． (3) 開発プロジェクトの既存会議で TRY の実行状況確認 ＜Ver.2＞ 開発プロジェクトの会議の中で TRY の実行状況を確認する．開発プロジェクト進捗会議 やチーム会議など既存の会議を利用する．なぜなら，新たに会議の場を設定することなく， 開発プロジェクトの進捗・課題・リスク管理等と同様，定期的に状況確認ができるためで ある．既存会議に PMO/SEPG が参加し，TRY の実行状況や実行に対する問題有無を確認する． (4) PMO/SEPG が担当者を強力に支援 ＜Ver.2＞ PMO/SEPG が積極的に担当者の TRY 実行支援を行う運用とする．なぜなら担当者に任せる と，業務繁忙などの理由で優先度を下げ，実行が滞る場合があるためである．PMO/SEPG は， ソフトウェア実装 PMBOK 重要度 TRY宣言対象 1ソフトウェア構築 3 宣言対象 2 ソフトウェア要 件定義 4 宣言対象 3 ソフトウェア方 式設計 2 宣言対象外 4 品質管理 4 宣言対象 5ソフトウェア詳細設計 2 宣言対象外 6 コスト管理 1 宣言対象外 振り返り内容(PROBLEM) TRY（改善） だから、こうしよう！ 機能テストで、異常ケースを忘れてしまい、 最終テストで不具合が多発した。 見積もり通りなのに、計画から遅れた。 不 具合分析に時間をとられてタスクに割ける 時間が減った。 異常ケースを考慮した設計にしよう！ 不具合分析も考慮し、予備工数を含めよう！ 振り返りアセスメント P R O B L E M 分類(観点チェックで選択したもの） （ソフトウェア実装、PMBOKのいずれか） # 途中で要件が変更となり、開発後戻りが発 生した。 レビュー指摘対応したが、確認してもらえず に、機能設計が遅れた。 プロセス開始の準備時に、有識者のレビュー 時間を確保する計画を立てよう！ ・設計開始前に、企画部門と会議を開き、要 件を確認しよう！ ・要件変更に備え、要件変更管理を徹底しよ レビュー計画を立案し、レビューイとレビュー アで、レビュー実施日、修正確認日を共有し よう！ 下流工程で、設計者が想定した影響範囲 以外の領域で、不具合が多発した。 下流工程で、設計者が想定した影響範囲 以外の領域で、不具合が多発した。 工程完了時に定量的/定性的な品質分析基 準を見直し、開発者と工程完了承認者で認 識を共有できるようにしよう！ いつ？ When？（By When?) 誰が？ (Who?) 何を？ (What?) 次のバージョンアップ開発 プロジェクトBのシステム設 計段階 開発プロジェクトA のプロジェクトマ ネージャー Sさん 有識者の割り当 てとレビュー計 画 組織全体 2018年4月以降の組織A の開発プロジェクト 組織Aの Fさん システム設計 プロジェクト全体 ・設計開始前に、企画部門と会議を開き、要件を確認 しよう！ ・要件変更管理を徹底しよう。 プロセス開始の準備時に、有識者のレビュー時間を確 保する計画を立てよう！ FOPA TRY宣言 (TRY宣言対象の内容を転記しよう！) ・企画部門と会議体を開き、要件に誤りがない かを確認する。 ・レビュー完了後万一要件が変更になる場合 は、要件変更管理を運用する。 ・レビュー計画を立案する。 ・有識者を割り当て、レビュー時間を確保する。 展開先 スコープは？ （真因分析した結果、3W1Hでアクションを記載しよう。） どのように行うか？ (How?)
担当者が TRY 実行の中で問題が生じている際に相談に乗り，問題の原因分析を経て支援し ていくことで，確実な TRY の実行につなげていく． 4. 実験結果(FOPA 振り返りプロセス Ver.2 の提案の有効性検証) 3 章の FOPA 振り返りプロセス Ver.2 の各項目の提案(仮説)に対して，有効であるかど うかを検証するために，各社で実開発プロジェクトでの試行後，アンケートを実施した． 4.1 実験方法 各社開発プロジェクトの担当者に Ver.2 の有効性を確認するため，12 人に対して表 5 のアンケートの項目を実施した．アンケートの質問項目については 4 択とした．『◎とても そう思う＝1 点』『〇そう思う＝2 点』『△あまりそう思わない＝3 点』『×まったくそう思 わない＝4 点』とする．点が 1 に近づき小さい方がより有効性が高いとして計算する．集 計結果として，平均値が「2.0 以下なら有効，2.0 超～2.5 未満なら Even，2.5 以上なら無 効」と判断した．また自由コメント欄を設け，忌憚なき意見を収集した． 4.2 実験結果まとめ 本実験のアンケート集計結果，質問項目 6 項目のうち，5 項目で“有効”，1 項目で“Even”， 無効は“0 項目”であった．自由コメント欄では有効な意見が多かった．本プロセスの狙 い通り，振り返り分析の効率化と十分性の両立や，次プロジェクトで実行支援活動が有効 であるという意見が多かった．一方でそもそもなぜ TRY が自律的に実行されないかを考慮 すべきなど，さらなるプロセスの改良を求める意見もあった．(表 5 参照)． 表 5 ア ン ケ ー ト 集 計 結 果 質 問 の 狙い 質 問 集 計 結 果 主 な 意 見（ 自 由コ メ ント 欄） 振 り 返 り分 析 の 効 率化 と 十 分 性の 両 立 が 可能 か ？ 1.Ver.1 と 比 較し て Ver2 は振 り 返 り 分 析 を 効 率 的 に （ 負 担 な く ） 行 う こ と が で き ま す か ？ Even(平 均 値 ： 2.25) ◎ ： 1 人 〇 ： 7 人 △ ： 4 人 ×： 0 人 〇：なぜ な ぜ分 析シ ー トの 任 意使 用 は ,深 堀 が 必 要 な 時の み に使 う 運用 で効率 化 で きる ． △：TRY 宣 言で 詳 細(3W1H)を 記載 す る 場合 に 時 間 が か る． △ ： QCD 重要 問 題に 絞 れば ，発 散 を 防止 し ， よ り 効 率化 で きる の では ないか ． △ ： PMO/SEPG が 振り 返 り分 析に 参 加 すれ ば ， よ り 効 率的 に 分析 で きる と思う ． 2.観 点 チ ェ ッ ク シ ー ト ＆ な ぜ な ぜ 分 析シ ー トを Ver.2 で任 意 使 用 に し ま し た が ， そ れ で も 納 得 感を も った TRY が 導出 で き ま すか ？ 有 効 (平 均 値 ： 1.83) ◎ ： 4 人 〇 ： 6 人 △ ： 2 人 ×： 0 人 ◎ ： 振 り返 り 時会 議 時 に TRY の 十 分 性を 確 認 し て い るの で ，本 運 用で 問題な い ． 〇 ： 納 得感 が 持て な い人 は ，本 シ ー トを 使 う 運 用 な ので 問 題な い ． △ ： シ ート を 使っ て いる ので変 化 な し ． 次 開 発 PJ で の 実 行 支援 活 動 が 有効 か ？ 3.Ver1 と比 較し て ， TRY を実 行 支 援 し て も ら え る で し ょ う か ？ 有 効 (平 均 値 ： 2.00) ◎ ： 3 人 〇 ： 7 人 △ ： 1 人 ×： 1 人 〇 ： TRY の放 置 をな く すの に 有効 ． ×：そ も そも な ぜ TRY が自 律的 に 実 行さ れ な い の か を考 慮 した ほ うが 良い ． 4.実 務 で 活 用 し て い る 構 成 管 理 ツ ー ル(Redmine， TFS な ど) で TRY の内 容 が監 視 ・管 理し や す く なる で しょ う か？ 有 効 (平 均 値 ： 1.83) ◎ ： 7 人 〇 ： 2 人 △ ： 1 人 ×： 2 人 ◎ ： 状 況の 管 理を チ ケッ トで実 施 す るの は 現 運 用 に 合っ て いる ． △：構 成 管 理ツ ール へ の登 録 が面 倒 ．KPT シ ー ト か ら 自動 登 録で き ない か ． ×： Excel で 管理 し ても あ まり変 わ ら ない ． 5.既 存 の 会 議 (定 例 進 捗 管 理 ) な ど で TRY の 実行 内 容を 確認 す る こ と は ， 有 効 で し ょ う か ？ 有 効 (平 均 値 ： 1.83) ◎ ： 3 人 〇 ： 8 人 △ ： 1 人 ×： 0 人 〇 ： チ ーム の 既存 会 議で 行う運 用 が ，実 現 場 に 合 っ てい る △：状況 確 認の 具 体的 イ メー ジが 欲 し い ．(毎 回 会 議 で確 認 する の か？ PMO/SEPG が ど のよ う に 支 援 する の か？ ) 6.PMO/SEPG が ，担 当 者を 補佐 す る 形 で 状 況 確 認 ， 実 行 支 援 す る の は有 効 でし ょ うか ？ 有 効 (平 均 値 ： 1.83) ◎ ： 4 人 〇 ： 6 人 △ ： 2 人 ×： 0 人 〇 ： PMO/SEPG が TRY の 内容 を熟 知 し てい れ ば 有 効 で ある ． △ ： 本 来開 発 担当 者 が TRY を自 前 で 実施 す べ き で あ る． 凡 例：「 有効 か ？」に 対し ◎：とて もそ う 思う ，〇：そ う 思う ， △：そ う 思わ な い， ×：まっ たく そ う思 わ ない 5. 考察 5.1 FOPA 振り返りプロセス Ver.2 全体の有効性 実験結果により FOPA 振り返りプロセス Ver.2 の解決方針および提案が,振り返り分析 で導出された TRY が実行されないという問題の解決に有効であることを確認した．表 6 に FOPA 振り返りプロセス Ver.2 の各提案の仮説検証結果をまとめる．
表 6 FOPA 振り 返りプロ セス Ver.2 の各提 案の仮説 検証 結果 TRY が 実 行さ れ ない 原 因 解 決 方 針 FOPA 振 り 返 り プ ロ セ ス Ver.2 の各 提 案 実 験 結 果 *(Ver.1)：Ver.1 時の コ メ ント *上記 以 外： Ver.2 の コ メ ント 前 開 発 PJ の 振 り 返 り時： 振 り 返 り 分 析 の 不 十 分 さ (TRY に 対 す る 納 得 感 の 低 さ ) KEEP/PROBLEM の 網 羅 性の 不 十 分 さ 納 得 感 を 高 め る 振 り 返 り 分 析 [ 有 効 ]FOPA 観 点 チ ェ ッ ク シ ート 〇 ： 観 点抽 出 が苦 手 な人 に有効 ． (Ver.1) ◎ ： ある PJ で は ，観 点 抽出 が強 化 され KPT の 数 が 2.5 倍 に増 加 した ． (Ver.1) KEEP/PROBLEM の 真 因 分析 の 不 十 分 さ [有 効 ]FOPA KPT シー ト [ 有 効 ]FOPA な ぜ な ぜ 分 析 シ ート ◎ ： TRY の展 開 先ス コ ―プ が 明確 .(Ver.1) 〇 ： 真 因分 析 が苦 手 な人 に有効 . 振 り 返 り 分 析 に 時 間 が か か り ， 担 当者 の 負担 増 [Even] FOPA 観 点 チ ェ ッ ク シ ー ト と FOPA な ぜ な ぜ 分 析 シ ー ト <Ver.2:任 意 > 〇 ： 担 当 者 の 経 験 等 に 応 じ た 任 意 使 用 に よ り ， 振 り返 り 分析 の 効率 化に貢 献． △：振 り返 り ポイ ン トを 絞 る ,PMO/SEPG が分 析 に 参 加し 支 援す る など 改良意 見 あ り． 次 開 発 PJ で の TRY の 実 行 時 ： 担 当 者 に 依 存 し た TRY の 実 行 TRY を 伝え 理 解 し て もら う 仕 組 み が不 確 定 「 FOPA TRY 宣 言 」 と 「 PMO/SEPG に よ る 実 行 支 援 活 動 の 具 体 化 」 [有 効 ]FOPA TRY 宣言 [有 効 ] チ ケ ッ ト 駆 動 開 発 の 実 行 に よ る TRY の チ ケ ット 管 理 <Ver.2:追 加 > 〇 ： FOPA TRY 宣 言 は 担 当 者 の意 志 を 示 し 次 開 発 担 当者 の 理解 に つな がる .(Ver.1) ◎ :構 成管 理 ツー ル 上で TRY を管 理 す るこ と で ， 自 然に 実 業務 に 適合 するた め ， 有効 ． △ ： Excel で 運 用し た いと い う意 見 あ り TRY の 実行 支 援 活 動 が不 確 定 [有 効 ]開 発 プ ロ ジ ェ ク ト の 既 存 会 議 で 状 況 確 認 <Ver.2:追 加 > 〇 ： 実 務に 直 結し た 運用 であり 有 効 . △：状 況 確 認の 具 体的 イメ ー ジを 求 め る意 見 あ り (頻度 ,PMO の具 体 的支 援 内容 な ど ). [有 効 ]PMO/SEPG が TRY の 実 行 を 強 力 支 援 <Ver.2:追 加 > 〇：PMO/SEPG が TRY を 熟知 して い れ ば有 効 ． △：本 来 開 発担 当 者が 自律 的 に TRY を 実 施す べ き と いう 意 見あ り ． 凡 例：「 有効 か ？」に 対し ◎：とて もそ う 思う ，〇：そ う 思う ， △：そ う 思わ な い， ×：まっ たく そ う思 わ ない 5.2 “振り返り分析の不十分さ(TRY に対する納得感の低さ)”の問題解決について 表 5 アンケート質問 1，2 の結果，質問 1(振り返り分析の効率化)は Even(2.25)，質問 2(納得感のある TRY の導出と FOPA TRY 宣言)について有効(1.83)であった．FOPA 振り返り 観点シートと FOPA なぜなぜ分析シートから導出された FOPA TRY 宣言により納得感の低さ を解決できるが，さらなる振り返り分析の効率化については運用面で検討の余地がある． (1) FOPA 観点チェックシート/FOPA なぜなぜ分析シートの有効性，振り返り分析の効率化 FOPA 観点チェックシート利用により過去の類似開発プロジェクトと比較して 2.5 倍に 増えた事例や，なぜなぜ分析シートにより自信を持って TRY 宣言できるという意見により， 両シートで納得感を高める振り返り結果の導出が可能となり問題解決に貢献すると言える． 振り返り分析の効率化については，担当者の経験に応じた任意使用により効率化に貢献 するなどの有効的な意見があった．しかし質問 1 のアンケート結果が Even であり，かつ「プ ロジェクトの重要 QCD 問題に絞ればさらに効率化が進む」,「PMO/SEPG が振り返り分析に 参加すれば効率的に分析が進む」などの意見も出た．ただし仮にこれらの意見を本プロセ スに反映すると，KEEP/PROBLEM の網羅性が失われたり開発担当者の自律性が阻害されたり する恐れがある．本プロセスには反映せず，本意見を挙げた担当者へ個別に対応していく． (2) FOPA TRY 宣言の有効性 質問 2 のアンケート結果が有効であり，FOPA TRY 宣言は担当者の意志を明確に示すので 次開発 PJ 担当者の理解促進につながるという意見も得られた．次開発 PJ での TRY の実行 に貢献できると言える． 5.3. “担当者に依存した TRY の実行”の問題解決について 質問 3～6 のアンケート結果，基準値をクリアしたため有効と判断する (実績は，質問 3:2.00, 質問 4:1.83, 質問 5:1.83, 質問 6:1.83).また開発現場の実態に適合した振り返 りの実行支援が明確に定義され，有効に作用されるという意見を得た．PMO/SEPG の実行支 援活動が有効作用し担当者への依存をなくすため，本問題を解決できると言える． (1) チケット駆動開発による TRY のチケット管理の有効性 構成管理ツール上で TRY を管理することで自然に実業務に適合するため有効であるとい う意見を得た．狙い通り次開発 PJ で TRY を有効に管理できると言える．ただし Excel に慣 れた担当者が Excel の利用を求める意見もあり担当者に合わせた柔軟な運用を検討する． (2) 既存会議で TRY 実行状況確認の有効性 「 既 存 の 進 捗 会 議 で 確 認 す る こ と に よ り ， 実 務 に 直 結 し た 運 用 が 可 能 と な っ た ．」， 「PMO/SEPG が参加するので，支援を受けやすい．」という意見を得た．本提案は TRY の実
行に有効であると言える．ただし，確認頻度や PMO の関わり方法など具体的イメージを求 める意見があるので，各社開発プロジェクトの既存会議や PMO/SEPG の責任範囲を明確にし た上で，運用を具体化していく． (3) PMO/SEPG による実行支援の有効性 アンケートの結果，有効であるという意見が 12 人中 10 人と多数を占め，PMO/SEPG によ る 実 行 支 援 が 有 効 で あ る こ と を 確 認 し た ． た だ し ，「 確 実 に 支 援 を し て も ら う た め に は PMO/SEPG が TRY を熟知している必要がある．」という意見があった． TRY の実行支援だけ でなく振り返り分析からの PMO/SEPG の関与も運用の中で検討していく． また「本来（PMO/SEPG の支援を受けることなく）開発担当者が TRY を自律的に実施すべ きである．」という意見があった．開発担当者が TRY を自ら実行しない原因を分析した上で， 担当者の自律的な業務改善活動を阻害するための問題を排除し，かつ自律的な業務改善活 動を推進するための教育・啓蒙活動を実行していく． 6. まとめ 6.1 結論 我々は，前開発 PJ の振り返り結果を次開発 PJ で確実に実行する手順を FOPA 振り返り プロセス Ver.2 として定義した． Ver.1 では「開発担当者の納得感を持たせるために，開発工程およびプロジェクトマネ ジメント観点で KEEP/PROBLEM を網羅的に抽出した後，重要度の高いものを 真因分析して TRY を導出する仕組み」と「次開発 PJ で組織的に TRY を実行支援する枠組み」を定義した． Ver.2 では，さらに開発現場での実務に適合する形として Ver.1 からプロセスを改良し た．「振り返り分析の効率化に向け，振り返りの不慣れな担当者に限定した一部シートの使 用」と「次開発での TRY の確実な実践に向け，実行支援策の具体化(TRY のチケット管理・ 既存会議での状況確認・PMO/SEPG による TRY 実行支援)」を定義した． 各社での実験により， 本プロセスの各提案が”TRY が実行されない原因の解決”につな がるという結果となり，本プロセスは次開発 PJ での TRY 実行に効果があると言える．これ により，本プロセスが FOPA の名の通り，積極性をベースとした十分な納得感を持つ組織的 改善活動を推進することを確認した．従って，我々と同様，前開発 PJ の振り返り結果が次 開発 PJ で活用されない問題を抱えている読者に本プロセスを活用いただくことを提案す る．本プロセスが読者の開発プロジェクトの改善活動に貢献できたら幸いである． 6.2 今後の展開
Ver.2 では，FOPA 観点チェックシートと FOPA なぜなぜ分析シートを任意使用にして， 振り返り分析の経験を積んだ担当者は利用しなくてもよい形とした．しかし，経験を積ん でいても実際の分析能力が低い場合もある．担当者の振り返り分析能力を見極める方法を 具体化し FOPA 観点チェックシートと FOPA なぜなぜ分析シートの適用範囲を定義していく． 7. 参考文献 ［1］内藤拓，島田さつき，中井清元，"第三者検証活動からの開発プロジェクトマネジメ ントに対する改善提案"，ソフトウェア品質シンポジウム 2017 報文集，2017 年 ［2］天野 勝，"プロジェクトファシリテーション 実践編ふりかえりガイド", http://objectclub.jp/download/files/pf/RetrospectiveMeetingGuide.pdf, 201 8. ［3］共通フレーム 2013 ～経営者，業務部門とともに取組む「使える」システムの実現～， 独立行政法人情報処理推進機構(IPA)，2013 年 ［4］プロジェクトマネジメント知識体系ガイド(PMBOK®ガイド)第 5 版, 2012 年 ［5］花原雪州，伴野孝，徳留浩二，小川忠久，坂静香， "KWS 振り返りで得られた知識と 知恵を，組織的に活用する仕組みの研究"，第 28 年度ソフトウェア品質管理研究会分 科会報告書，第一分科会，(一財)日本科学技術連盟，2012 年 ［6］田中桂三，中川幸治, 内藤拓，荒川拓，"振り返り活動を力強く支援する「FOPA 振り 返りプロセス」の提案", 第 33 年度ソフトウェア品質管理研究会分科会報告書 ，第一 分科会，(一財)日本科学技術連盟，2017 年
![表 1 TRY が実 行され ない原因 ，FOPA 振り 返りプ ロセス Ver.1 の提案 と問題 [6]](https://thumb-ap.123doks.com/thumbv2/123deta/6827899.734169/2.892.99.798.694.1040/表1TRYが実行されない原因FOPA振り返りプロセスVer1の提案と問題6.webp)
