－1－－11－

ぢ✚䜒䜚㏻䜚䛺䛾䛻䚸 ィ⏬䛛䜙㐜䜜䛯䚹䚷 ୙ලྜศᯒ䛻᫬㛫䜢䛸䜙䜜䛶䝍䝇䜽䛻๭䛡䜛᫬㛫䛜
ῶ䛳䛯䚹

㻡㻡

㻢㻢

ᶵ⬟䝔 䝇䝖䛷䚸␗ᖖ䜿䞊䝇䜢ᛀ䜜䛶 䛧䜎䛔䚸 ᭱⤊䝔䝇 䝖䛷୙ලྜ䛜ከⓎ䛧䛯䚹䝁䝇䝖⟶⌮䝺䝡䝳䞊ᣦ᦬ᑐᛂ䛧䛯䛜䚸☜ㄆ䛧䛶 䜒䜙䛘䛪䛻䚸ᶵ⬟タィ䛜㐜䜜䛯䚹㏵୰䛷 せ௳䛜ኚ᭦䛸䛺䜚䚸㛤Ⓨᚋᡠ䜚䛜Ⓨ⏕䛧䛯 䚹ୗὶᕤ⛬䛷䚸 タィ⪅䛜᝿ᐃ䛧䛯ᙳ㡪⠊ᅖ௨እ䛾㡿ᇦ䛷䚸 ୙ලྜ䛜ከⓎ䛧䛯䚹᣺䜚㏉䜚ෆᐜ㻔㻼㻾㻻㻮㻸㻱㻹㻕ရ㉁⟶⌮䝋䝣䝖䜴䜵䜰᪉ᘧタィ䝋䝣䝖䜴䜵䜰せ௳ᐃ⩏

㻼㻹㻮㻻㻷

㻠㻠

㻟㻟

㻞㻞

㻝㻝

䝋䝣䝖䜴䜵䜰ᐇ⿦䝋䝣䝖䜴䜵䜰ᵓ⠏䛾⥅⥆ุ᩿䛾ᐇ᪋䐦)23$ 75<ᐉゝ㻝㼀㻾㼅ᐉゝᑐ㇟

ᐉゝᑐ㇟እ

ᐉゝᑐ㇟እ

ᐉゝᑐ㇟እ

ᐉゝᑐ㇟

ᐉゝᑐ㇟

䛆)23$.37䝅䞊䝖䝅䞊䝖 ௜㘓௜㘓 䠖 ᐇ⾜ᨭ᥼≧ἣ䛇ᐇ⾜ᨭ᥼≧ἣ䛇䛆)23$䛺䛬䛺䛬ศᯒ䝅䞊䝖䛺䛬䛺䛬ศᯒ䝅䞊䝖 ௜㘓௜㘓 䛇୙ලྜศᯒ䜒⪃៖䛧䚸ணഛᕤᩘ䜢ྵ䜑䜘䛖䟿ᐇ⾜ᨭ᥼䛾ᐇ᪋

䐥)23$75<ᐉゝ䛾䝥䝻䝆䜵䜽䝖䝣䜷䝻䞊䜰䝑䝥ᐉゝ䛾
ᐉゝ䛾⟶⌮
⟶⌮
ᐉゝ䛾

㔜せᗘ

㻠

㻟

䝺䝡䝳䞊ィ⏬䜢❧᱌䛧䚸䝺䝡䝳䞊䜲䛸䝺䝡䝳䞊䜰 䛷䚸䝺䝡䝳䞊ᐇ᪋᪥䚸ಟṇ☜ㄆ᪥䜢ඹ᭷䛧 㻞䜘䛖䟿㻞␗ᖖ䜿䞊䝇䜢⪃៖䛧䛯タィ䛻䛧䜘䛖䟿䞉タィ㛤ጞ๓䛻䚸௻⏬㒊㛛䛸఍㆟䜢㛤䛝䚸せ௳䜢☜ㄆ䛧䜘䛖䟿䞉せ௳ኚ᭦䛻ഛ䛘䚸せ௳ኚ᭦⟶⌮䜢ᚭᗏ䛧䜘䛖䟿䝥䝻䝉䝇㛤ጞ䛾‽ഛ᫬䛻䚸 ᭷㆑⪅䛾䝺䝡䝳䞊᫬㛫䜢☜ಖ䛩䜛ィ⏬䜢❧䛶䜘䛖䟿㼀㻾㼅䠄ᨵၿ䠅䚷䛰䛛䜙䚸䛣䛖䛧䜘䛖䟿᣺䜚㏉䜚䜰䝉䝇䝯䞁䝖䛆 )23$ほⅬ䝏䜵䝑䜽䝅䞊䝖䠄௜㘓
ほⅬ䝏䜵䝑䜽䝅䞊䝖䠄௜㘓
ほⅬ䝏䜵䝑䜽䝅䞊䝖䠄௜㘓 䛇䛆 )23$.37䝅䞊䝖䝅䞊䝖 ௜㘓௜㘓 䠖᣺䜚㏉䜚ෆᐜ䛾グ㘓 䛇䐡ᚲせ䛻ᛂ䛨䛶┿ᅉศᯒ䠄䛺䛬䛺䛬ศᯒ䠅

㻼
㻾
㻻
㻮
㻸
㻱
㻹

ศ㢮㻔ほⅬ䝏䜵䝑䜽䛷㑅ᢥ䛧䛯䜒䛾䠅䠄䝋䝣䝖䜴䜵䜰ᐇ⿦䚸㻼㻹㻮㻻㻷䛾䛔䛪䜜䛛䠅

䐠.37䛾ලయ໬

䐟᣺䜚㏉䜚ほⅬ⥙⨶䠄30%2.䜺䜲䝗䚸ඹ㏻䝣䝺䞊䝮䠅ಶே䝏䞊䝮䛷䛾᣺䜚㏉䜚‽ഛಶே 䝏䞊䝮䛷䛾᣺䜚㏉䜚‽ഛ䕔㻌㻲㻻㻼㻭᣺䜚㏉䜚䝥䝻䝉䝇䚷䜲䝯䞊䝆ᅗ䠄㻼㻰㻯㻭䝃䜲䜽䝹䠅

ᣦᐃ䛇
ᣦᐃ䛇

ᣲ䛢䛯ෆᐜ䛾㐺⏝䐤)23$ 75<ᐉゝ䛷䝥䝻䝆䜵䜽䝖䜈䛾㐺⏝䛆)23$.37䝅䞊䝖䝅䞊䝖 ௜㘓௜㘓 䠖䝣䜷䝻䞊䜰䝑䝥ᑐ㇟䝣䜷䝻䞊䜰䝑䝥ᑐ㇟⪅䜰䝑䝥ᑐ㇟⪅䛾᫂☜໬䚸ᒎ㛤ඛ䝇䝁䞊䝥䛾᫂☜໬䚸ᒎ㛤ඛ䝇䝁䞊䝥䛾䚸ᒎ㛤ඛ䝇䝁䞊䝥䛾䐣䝣䜷䝻䞊䜰䝑䝥ᑐ㇟⪅䛾᫂☜໬䚸ᒎ㛤ඛ䝇䝁䞊䝥ᣦᐃ䛆)23$.37䝅䞊䝖䝅䞊䝖 ௜㘓ᐉゝ䠄75<ᐉゝ䜢ᐉゝ䜢:+䛷ල⌧໬䛷ල⌧໬ 䛇௜㘓 䠖᣺䜚㏉䜚75<ᐉゝ䠄
䠖᣺䜚㏉䜚
ᐉゝ䠄
ᐉゝ䜢

䐢䛂)23$75<ᐉゝ䛃䜢䛧䛶㛵ಀ⪅䛾ྜព䜢ᚓ䜛䝥䝻䝆䜵䜽䝖᣺䜚㏉䜚఍䕔㻌┠ⓗ䚷䚷䞉㻲㻻㻼㻭㻌᣺䜚㏉䜚䝥䝻䝉䝇䜢㻼㻰㻯㻭䝃䜲䜽䝹䛸䛧䛶䝏䜵䝑䜽䜢⾜䛖䠊䚷䚷䞉䛂㻲㻻㻼㻭㻌᣺䜚㏉䜚䝥䝻䝉䝇㻷㻼㼀䝅䞊䝖䛃䜢䝯䜲䞁䛻ά⏝䛧䛯⤌⧊ᶓ᩿ⓗ䠈䛛䛴⥅⥆ⓗ䛺᣺䜚㏉䜚䜢ᐇ⌧䛩䜛䠊䕔䚷䛂㻲㻻㻼㻭䚷᣺䜚㏉䜚䝥䝻䝉䝇㻷㻼㼀䝅䞊䝖䛃グධせ㡿䚷䚷䞉䛆௜㘓䠎㻌㻲㻻㻼㻭㻌᣺䜚㏉䜚䝥䝻䝉䝇㐠⏝せ㡿䛇䜢䛤ཧ↷䛟䛰䛥䛔䠊䛆௜㘓㻝䠖㻲㻻㻼㻭㻌᣺䜚㏉䜚䝥䝻䝉䝇䛇䠘ಶே㻛䝏䞊䝮䛷䛾᣺䜚㏉䜚‽ഛ䠚㻼㻰㻯㻭༊ศ ෆᐜㄝ᫂㻭㻯㼀䐦ရ㉁ᨵၿຠᯝ䜔㛤Ⓨຠ⋡໬䛾ほⅬ䛛䜙㻲㻻㻼㻭㻌㼀㻾㼅ᐉゝ䜢ḟ䛾㛤Ⓨ䝥䝻䝆䜵䜽䝖䛻䜒⥅⥆䛩䜉䛝䛛䜢᳨ウ䛩䜛䠊䠘ಶே䠋䝏䞊䝮䛷䛾᣺䜚㏉䜚‽ഛ䠚䛾㻼㻸㻭㻺ෆᐜ䛸ྠᵝ䛻ḟ䛾㛤Ⓨ䝥䝻䝆䜵䜽䝖䛾㻼㻸㻭㻺䜢❧䛶䛶ᘬ⥅䛞䜢⾜䛖䠊䠘㼀㻾㼅ᐉゝ䛾㻿㼠㼍㼠㼡㼟⟶⌮䠚㻼㻰㻯㻭༊ศ ෆᐜㄝ᫂㻯㻴㻱㻯㻷䐥㻲㻻㻼㻭㻌㼀㻾㼅ᐉゝ䛾ᐇ⾜ᨭ᥼⪅䛿㻲㻻㻼㻭㻌㼀㻾㼅ᐉゝ䛜㛤Ⓨ䝥䝻䝆䜵䜽䝖䛻㐺⏝䛥䜜䛶䛔䜛䛛䝏䜵䝑䜽䜢⾜䛔䠈㐺⏝୙༑ศ䛾ሙྜ䛿䝣䜷䝻䞊䜢⾜䛖䠊䠘䝥䝻䝆䜵䜽䝖䝣䜷䝻䞊䜰䝑䝥䠚㻼㻰㻯㻭༊ศ ෆᐜㄝ᫂㻰㻻䐤ḟ㛤Ⓨ䝥䝻䝆䜵䜽䝖䛷㻲㻻㻼㻭㻌㼀㻾㼅ᐉゝ䛾ෆᐜ䜢㐺⏝䛩䜛䠊

䠘䝥䝻䝆䜵䜽䝖䜈䛾㐺⏝䠚㻼㻰㻯㻭༊ศ ෆᐜㄝ᫂㻼㻸㻭㻺䐢᣺䜚㏉䜚఍䛾୰䛷䠈㻲㻻㻼㻭㻌㼀㻾㼅ᐉゝ䛻グ㍕䛧䛯ෆᐜ䛾ྜព䜢ྲྀ䜛䠊䐣᣺䜚㏉䜚఍䛾୰䛷䠈㻲㻻㻼㻭㻌㼀㻾㼅ᐉゝ䛾ᐇ⾜ᨭ᥼⪅䠈ᒎ㛤ඛ䝇䝁䞊䝥䜢Ỵ䜑䜛䠊

䠘㛤Ⓨ䝥䝻䝆䜵䜽䝖᣺䜚㏉䜚఍䠚㻼㻰㻯㻭༊ศ ෆᐜㄝ᫂㻼㻸㻭㻺䐟㻲㻻㻼㻭ほⅬ䝏䜵䝑䜽䝅䞊䝖䛻䜘䜚䠈㻼㻹㻮㻻㻷㼹䜺䜲䝗䠈ඹ㏻䝣䝺䞊䝮㻞㻜㻝㻟ほⅬ䛷㛤Ⓨ䝥䝻䝆䜵䜽䝖䜢᣺䜚㏉䜛䠊䐠㻲㻻㻼㻭㻌㻷㻼㼀䝅䞊䝖䛻ලయⓗ䛺䛂᣺䜚㏉䜚ෆᐜ䠄㻼㻾㻻㻮㻸㻱㻹䠋㻷㻱㻱㻼䠋㻵㻰㻱㻭䠄㻼㻾㻻㻼㻻㻿㻭㻸䠅䠅䛃䛸䛂㼀㻾㼅䠄ᨵၿ䠅䛃䜢グධ䛩䜛䠊䜎䛯䠈䛭䛾㝿䛻㔜せᗘ䛾㑅ᐃ䜒⾜䛖䠊䐡㻲㻻㻼㻭┿ᅉศᯒ䝅䞊䝖䜢౑⏝䛧㔜せᗘ䛾㧗䛔ศᯒෆᐜ䛾┿ᅉศᯒ䜢⾜䛖䠊䛆௜㘓㻞䠖㻲㻻㻼㻭㻌᣺䜚㏉䜚䝥䝻䝉䝇㐠⏝せ㡿䛇㻲㻻㻼㻭䚷㻷㻼㼀䝅䞊䝖ྛ▮༳␒ྕ䛻䛚䛡䜛グධせ㡿䜢ୗ⾲䛷♧䛩䠊㻲㻻㻼㻭㻌㼀㻾㼅ᐉゝ㻲㻻㻼㻭㻌㼀㻾㼅 ᐉゝ䠘ಶே㻛䝏䞊䝮䛷䛾᣺䜚㏉䜚‽ഛ䠚㻼㻰㻯㻭༊ศ 㻺㼛㻚
㻼㻸㻭㻺

㻼㻝㻙㻝
㻼㻝㻙㻞
㻼㻝㻙㻟

㻲㻻㻼㻭᣺䜚㏉䜚䝥䝻䝉䝇㐠⏝せ㡿䠄㻲㻻㻼㻭㻌㻷㻼㼀䝅䞊䝖グධせ㡿䠅䞉㻲㻻㻼㻭ほⅬ䝏䜵䝑䜽䝅䞊䝖䜢౑䛳䛯ほⅬ⥙⨶ᛶ䠄㻼㻹㻮㻻㻷㼹䠄ᑐ㇟䠖㻼㻹䠅䠈ඹ㏻䝣䝺䞊䝮㻞㻜㻝㻟䠄ᑐ㇟䠖㛤Ⓨ䝯䞁䝞䞊䠅䠅䜢⢭ᰝᚋ䠈㻌㻌ྛ䚻䛾ほⅬ䛻䛚䛡䜛ศ㢮䠄䝋䝣䝖䜴䜵䜰ᐇ⿦䠈㻼㻹㻮㻻㻷㼹䠅䜢グධ䛩䜛䠊䞉ලయⓗ䛺䇿᣺䜚㏉䜚ෆᐜ䠄㻼㻾㻻㻮㻸㻱㻹䠋㻷㻱㻱㻼䠋㻵㻰㻱㻭䠄㻼㻾㻻㻼㻻㻾㻿㻭㻸䠅䠅䇿䛸䇿㼀㻾㼅䠄ᨵၿ䠅䚷䛰䛛䜙䠈䛣䛖䛧䜘䛖䟿䇿䜢グධ䛩䜛䠊䞉᣺䜚㏉䜚䜰䝉䝇䝯䞁䝖䜢グධ䛩䜛䠊䚷䚷䠘㔜せᗘ䠚䚷䚷䚷᣺䜚㏉䜚⤖ᯝ䛾㔜せᗘ䜢グධ䛧䛶䛟䛰䛥䛔䠊䠄௨ୗ䛿㔜せᗘ䛾┠Ᏻ䛷䛒䜚䠈ྛ♫䛾≧ἣ䛻ᛂ䛨䛶ᐃ⩏䛧┤䛧䛶䛟䛰䛥䛔䠊䠅䚷䚷䚷᣺䜚㏉䜚⤖ᯝ䛾㔜せᗘ䜢グධ䛧䛶䛟䛰䛥䛔䠊䠄௻ᴗ䛾≧ἣ䛻ᛂ䛨䛶䜹䝇䝍䝬䜲䝈䛧䛶䛟䛰䛥䛔䠊䠅㻠㻦䛸䛶䜒㔜せ ᐃᛶⓗᇶ‽䠖඲♫䠈஦ᴗ㒊䠈㛤Ⓨ㒊㛛඲య䛻ᒎ㛤䛩䜛䝺䝧䝹䠊䠄ሗ࿌ඛ䠖஦ᴗ㒊㛗௨ୖ䠅ᐃ㔞ⓗᇶ‽䠖㛤Ⓨ㈝㻔ᕤᩘ䠅䠇㻞㻜㻑ᙉ䠈⣡ᮇ㐜ᘏ䠇㻝㻹ᙉ䠈ရ㉁పୗ䠖ฟⲴุᐃ䛷㻺㻳䛸䛺䜛㻟㻦㔜せᐃᛶⓗᇶ‽䠖㛤Ⓨ㒊㛛඲య䠄ḟ㛤Ⓨ䝥䝻䝆䜵䜽䝖䠈௚〇ရ䠅䛻ᶓᒎ㛤䛩䜛䝺䝧䝹䚷䚷䠄ሗ࿌ඛ䠖㛤Ⓨ㒊㛗௨ୖ䠈ḟ㛤Ⓨ䝥䝻䝆䜵䜽䝖䝬䝛䞊䝆䝱䞊䠅ᐃ㔞ⓗᇶ‽䠖㛤Ⓨ㈝㻔ᕤᩘ䠅䡚䠇㻞㻜㻑䠈⣡ᮇ㐜ᘏ䡚䠇㻝㻹䠈ရ㉁పୗ䠖௚ᶵ⬟䛻ᙳ㡪䜢ཬ䜌䛩㻞㻦ᬑ㏻
ᐃᛶⓗᇶ‽䠖௚䝏䞊䝮䛻ᒎ㛤䛩䜛䝺䝧䝹䠊䠄ሗ࿌ඛ䠖䝥䝻䝆䜵䜽䝖䝬䝛䞊䝆䝱䞊䠈௚䝏䞊䝮䝸䞊䝎䞊䠅ᐃ㔞ⓗᇶ‽䠖㛤Ⓨ㈝㻔ᕤᩘ䠅䡚䠇㻝㻜㻑䠈⣡ᮇ㐜ᘏ䡚䠇㻞㼃䠈ရ㉁పୗ䠖ᶵ⬟ไ㝈䛜䛛䛛䜛㻝㻦㍍ᚤ
ᐃᛶⓗᇶ‽䠖ಶே㻛䝏䞊䝮䛻ᒎ㛤䛩䜛䝺䝧䝹䠊䠄ሗ࿌ඛ䠖䝏䞊䝮䝸䞊䝎䞊䠅ᐃ㔞ⓗᇶ‽䠖㛤Ⓨ㈝㻔ᕤᩘ䠅䡚䠇㻡㻑䠈⣡ᮇ㐜ᘏ䡚䠇㻝㼃䠈ရ㉁పୗ䠖ᶵ⬟ไ㝈䛿䛛䛛䜙䛺䛔䚷䚷䠘㼀㻾㼅ᐉゝᑐ㇟䠚䚷䚷䚷᣺䜚㏉䜚⤖ᯝ䛛䜙㻼㻝㻙㻞䛾㼀㻾㼅ᐉゝᑐ㇟䛸䛩䜛䛛䠛䜢グධ䛧䛶䛟䛰䛥䛔䠊䠄㑅ᢥᘧ䠅䚷 䚷䚷䚷䚷㻙㻌ᐉゝᑐ㇟䚷䚷䚷㻙㻌ᐉゝ㠀ᑐ㇟

䠘㛤Ⓨ䝥䝻䝆䜵䜽䝖᣺䜚㏉䜚఍䠚㻼㻰㻯㻭༊ศ 㻺㼛㻚
㻼㻸㻭㻺
㻼㻞㻙䠍
㻼㻞㻙㻞

㻲㻻㻼㻭᣺䜚㏉䜚䝥䝻䝉䝇㐠⏝せ㡿䠄㻲㻻㻼㻭㻌᣺䜚㏉䜚㻷㻼㼀䝅䞊䝖グධせ㡿䠅䞉㻲㻻㻼㻭㻌㼀㻾㼅ᐉゝ䜢䠈㻟㼃㻝㻴䛂䛔䛴䠛䠄䛔䛴䜎䛷䛻䠛䠅㼃㼔㼑㼚䠛䠄㻮㼥㻌㼃㼔㼑㼚㻫㻕䛃䛂ㄡ䛜䠛㻔㼃㼔㼛㻫㻕䛃䛂ఱ䜢䠛䠄㼃㼔㼍㼠㻫㻕䛃䛂䛹䛾䜘䛖䛻⾜䛖䛛䠛㻔㻴㼛㼣㻫㻕䛃㻌㻌䛷グධ䛩䜛䠊
䞉ᐇ⾜ᨭ᥼䜢⾜䛖䝣䜷䝻䞊䜰䝑䝥ᑐ㇟⪅䜢ㄡ䛻䛩䜛䛛䠛䠈ᒎ㛤ඛ䝇䝁䞊䝥䠄඲♫䠈஦ᴗ㒊䚷䠋〇ရ䠈䝥䝻䝆䜵䜽䝖䠋௚䝏䞊䝮䠋ಶே䠅䜢Ỵᐃ䛧䛶グධ䛩䜛䠊䞉ᪧ㛤Ⓨ䝥䝻䝆䜵䜽䝖䝬䝛䞊䝆䝱䞊䛛䜙䝣䜷䝻䞊䜰䝑䝥ᑐ㇟⪅䛻ྥ䛡䛶䠈᣺䜚㏉䜚㼀㻾㼅ᐉゝෆᐜ䜢ㄝ᫂䠄⥅ᢎ䠅䛩䜛䠊䠄ᑐ㇟䠖ᪧ㛤Ⓨ䝥䝻䝆䜵䜽䝖䝬䝛䞊䝆䝱䞊䠈䝣䜷䝻䞊䜰䝑䝥ᑐ㇟⪅䠅䠘䝥䝻䝆䜵䜽䝖䜈䛾㐺⏝䠚㻼㻰㻯㻭༊ศ 㻺㼛㻚㻰㻻㻰㻙㻝㻲㻻㻼㻭᣺䜚㏉䜚䝥䝻䝉䝇㐠⏝せ㡿䞉ୖグ㻼㻞㻙㻞䛾ෆᐜ䜢䝥䝻䝆䜵䜽䝖ෆ䛷㐺⏝䜢ᅗ䜛䠊䠄ᑐ㇟䠖䝥䝻䝆䜵䜽䝖䝬䝛䞊䝆䝱䞊䠈㛤Ⓨ䝯䞁䝞䞊䠅䠘䝥䝻䝆䜵䜽䝖䝣䜷䝻䞊䜰䝑䝥䠚㻼㻰㻯㻭༊ศ 㻺㼛㻚
㻯㻴㻱㻯㻷
㻯㻙㻝

㻲㻻㻼㻭᣺䜚㏉䜚䝥䝻䝉䝇㐠⏝せ㡿䞉ୖグ㻼㻞㻙㻞䛾ෆᐜ䛜䝥䝻䝆䜵䜽䝖ෆ䛷㐺⏝䛜ᅗ䜙䜜䛶䛔䜛䛛䠛䝏䜵䝑䜽䜢⾜䛔䠈㐺⏝୙༑ศ䛾ሙྜ䛿䝣䜷䝻䞊䜢⾜䛖䠊䠄ᑐ㇟䠖㻼㻞㻙㻞䛷Ỵ䜑䛯䝣䜷䝻䞊䜰䝑䝥ᑐ㇟⪅䠅䠘㼀㻾㼅ᐉゝ䛾㻿㼠㼍㼠㼡㼟⟶⌮䠚㻼㻰㻯㻭༊ศ 㻺㼛㻚㻭㻯㼀㻭㻙㻝㻲㻻㻼㻭᣺䜚㏉䜚䝥䝻䝉䝇㐠⏝せ㡿䠄㻲㻻㻼㻭㻌᣺䜚㏉䜚㻷㻼㼀䝅䞊䝖グධせ㡿䠅䞉䝥䝻䝉䝇䛾⫧኱໬㜵Ṇ䛾䛯䜑䛻䠈ḟᅇ㛤Ⓨ䝥䝻䝆䜵䜽䝖䛾᣺䜚㏉䜚఍ෆ䛷᣺䜚㏉䜚㼀㻾㼅ᐉゝ䜢⥅⥆䛩䜉䛝䛛᳨ウ䜢ᅗ䜛䠊䞉䝥䝻䝆䜵䜽䝖䝬䝛䞊䝆䝱䞊䛜䠈䝣䜷䝻䞊䜰䝑䝥ᑐ㇟⪅䛾ពぢ䜢㋃䜎䛘䛶ᐃ╔䜢☜ㄆ䛧䛯᫬Ⅼ䛷㻯㻸㻻㻿㻱䜢ᥦ᱌䛧䠈᣺䜚㏉䜚఍㆟䛾ሙ䛷䠈䚷⟶⌮ᒙ䛾ྜព䛾䜒䛸䠈㻯㻸㻻㻿㻱䜢ᐉゝ䛧䛶㼀㻾㼅ᐉゝ䛾㻿㼠㼍㼠㼡㼟䜢ኚ᭦䛩䜛䠊

䚷䚷䚷䚷

－12－
－2－

【付録3-(1)：FOPA 観点チェックシート(前半部分【FOPA 振り返り用観点チェック】
開発プロジェクト名
個人名orチーム名

分類（ソフトウェア実装）：開発メンバー向け）】※「○：該当事例あり」の分類について、KPTシートに記載してください。

Aプロジェクト バージョンアップ V〇.〇
Bチーム

(記入例)
＜分類（ソフトウェア実装）：開発メンバー向け＞
分類（共通フレーム”
SLCP-JCF2013”ソフト
ウェア実装プロセスのア
クティビティ）説明（タスク）

具体的要求事項

KEEP/
PROBLEM/
IDEA

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

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

・プロジェクトの範囲、規模、複雑さに応じたライフサイクルモデ
ルを定義または選択できていたか
PROBLEM・ソフトウェア実装プロセス及び支援プロセスを行うために、組織によって文書化され、適切であり、確立されている作業標準、
IDEA
方法、ツール及び計算機プログラム言語を選択していたか・ソフトウェア要件の確立
・ソフトウェア要件の評価
・ソフトウェア要件の共同レビューの実施※便宜上、システム要件定義、システム設計含む・ソフトウェア要件（品質特性仕様を含む）が確立され、文書化されていたか・システム要件及びシステム設計への追跡可能性（トレーサビリ PROBLEMティ）、システム要件との外部一貫性、内部一貫性が取れているか評価していたか
・テスト可能性、ソフトウェア設計の実現可能性、運用保守の実 IDEA
(PROPOSAL)
現可能性を評価し、レビューを実施したか。

(PROPOSAL)

KEEP

ソフトウェア要件定義

ソフトウェア方式設計

ソフトウェア詳細設計

ソフトウェア構築（プログラミング）・ソフトウェア構造とコンポーネントの方式設計
・各インターフェースの方式設計
・データベースの最上位レベルの設計
・利用者文書（暫定版）の作成
・ソフトウェア結合のためのテスト要件の定義
・ソフトウェア方式設計の評価
・ソフトウェア方式設計の共同レビューの実施
・ソフトウェアコンポーネントの詳細設計
・ソフトウェアインターフェイスの詳細設計
・データベースの詳細設計
・利用者用文書の更新
・ソフトウェアユニットのテスト要件の定義
・ソフトウェア結合のためのテスト要件の更新
・ソフトウェア詳細設計及びテスト要件の評価
・ソフトウェア詳細設計の共同レビューの実施

KEEP

・ソフトウェア品目に対する要件を、最上位レベルの構造を表現する形でかつソフトウェアコンポーネントを識別する方式に変換したか。またこれらの文書化したかPROBLEM・ソフトウェア結合のために暫定的なテスト要件及びスケジュールを定義し、文書化、レビューをしていたか・ソフトウェア品目の方式並びにインターフェース設計を評価し IDEA
(PROPOSAL)ていたか、文書化ならびにレビューをしていたか・ソフトウェア品目の各ソフトウェアコンポーネントに対して詳細 KEEP
設計を行ったか。これらを評価していたか、評価結果を文書化していたか(ソフトウェアコンポーネントをコーディング、コンパイル、テスト PROBLEM
できる下位のレベルまで詳細化できること）
・ソフトウェアユニットをテストするために、テスト要件及びスケジュールを定義し、文書化していたか
IDEA
・ソフトウェア結合のためのテスト要件及びスケジュールを更新 (PROPOSAL)
していたか・ソフトウェアユニットを作成していたか。これらを文書化してい KEEP
・ソフトウェアユニット作成及びテスト手順とテスト たか・ソフトウェア要件を満たすことを確実にする各ソフトウェアユ
データの作成ニットをテストし、テスト結果を文書化したか。必要に応じて利用 PROBLEM
・ソフトウェアユニットのテストの実施
者文書を更新したか
・利用者用文書の更新
・ソフトウェア結合のためのテスト要件及びスケジュールを定義 IDEA
・ソフトウェア結合テスト要件の更新
し、文書化していたか・ソフトウェアコード及びテスト結果の評価(PROPOSAL)

観点チェック
確認

備考(観点チェック確認
結果の理由など自由記
入)×：該当事例なし
×：該当事例なし
×：該当事例なし
×：該当事例なし○：該当事例あり

途中で要件が変更

×：該当事例なし
×：該当事例なし○：該当事例あり

レビュー確認遅れ

×：該当事例なし
×：該当事例なし○：該当事例あり

機能テストで異常ケー
ス漏れ

×：該当事例なし○：該当事例あり

チーム間でテスト観点
共有○：該当事例あり

下流工程で不具合が多発

×：該当事例なし

KEEP

ソフトウェア結合・ソフトウェア結合計画の作成
・ソフトウェア結合テストの実施・利用者用文書の更新
・ソフトウェア適格性確認テストの準備
・ソフトウェア結合の評価
・ソフトウェア結合の共同レビューの実施

・ソフトウェアユニット及びソフトウェアコンポーネントを結合してソフトウェア品目にするために結合計画を作成したか。この結合計画に従って、ソフトウェアユニット及びソフトウェアコンポーネントを結合し、集合体が作成されるごとにテストしたか。テスト結 PROBLEM
果を文書化したか・ソフトウェア品目の各適格性確認要件に対して、ソフトウェア適格性確認テストをおこなうため、テストの集合、テストケース、テスト手順を作成し、文書化していたか・結合計画、設計、コード、テスト、テスト結果及び利用者用文 IDEA
(PROPOSAL)
書を評価していたか。評価結果を文書化したか。レビューを実施したか。

×：該当事例なし

×：該当事例なし

×：該当事例なし

KEEP

・ソフトウェア適格性確認テストの実施
・ソフトウェア品目に対して、適格性確認要件に従って、適格性・利用者用文書の更新
確認テストを行ったか。適格性テストの結果を文書化していた・ソフトウェア適格性確認テストの評価
か。
PROBLEM
ソフトウェア適格性確認 ・ソフトウェア適格性確認テストの共同レビューの・必要に応じて利用者用文書を更新したか。
実施
テスト
・設計、コード、テスト、テスト結果及び利用者用文書を評価した
・監査の支援か。評価結果を文書化したか。レビューを実施したか。
IDEA
・納入ソフトウェア製品の準備(PROPOSAL)※便宜上システム適格性確認テストを含む。

KEEP
・契約に指定されたように実環境にソフトウェア製品を導入する
PROBLEM
計画を作成したか・導入計画に従ってソフトウェア製品を導入したか
IDEA
・導入中に起きたこと及び結果を文書化したか(PROPOSAL)

ソフトウェア導入・ソフトウェア導入（インストール）計画の作成
・ソフトウェア導入の実施

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

・取得者のソフトウェア製品受け入れレビュー及びテストを支援
・取得者の受け入れレビューと受け入れテストのしたか支援
・受け入れテスト及びテストの結果を文書化したか・ソフトウェア製品の納入・契約に沿ってソフトウェア製品を完成し納入し、教育訓練及び・取得者への教育訓練及び支援
支援を取得者に提供したか

－13－
－3－

×：該当事例なし

×：該当事例なし

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

KEEP○：該当事例あり

PROBLEM

×：該当事例なし

IDEA(PROPOSAL)

×：該当事例なし

社内SEのβ評価

【付録3-(2)：FOPA 観点チェックシート(後半部分 分類（PMBOK知識体系）：プロジェクトマネージャー,チームリーダー向け）】(記入例)＜分類（PMBOK知識体系）：プロジェクトマネージャー、チームリーダー向け＞
分類（PMBOK）

説明

具体的要求事項

KEEP/
PROBLEM/
IDEA

KEEP

統合管理

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

観点チェック
確認

備考(観点チェック確認
結果の理由など自由記
入)×：該当事例なし
×：該当事例なし
×：該当事例なし

KEEP
×：該当事例なし

スコープ管理プロジェクトの範囲、成果物、作業を過不足なく定義する。

・機能、非機能の各要件の受け入れ基準を明確にしていたか・WBSを作成し、タスクの実施者、実施時期が明確であったか PROBLEM
・品質、進捗上の問題を基に、開発要件への変更管理を検討していたか
・ステークホルダーからの要件変更等に対応できていたか、対 IDEA
(PROPOSAL)
応方針は明確であったか

×：該当事例なし

×：該当事例なし

KEEP

タイム管理

進捗に遅れは生じなかったか
また、特に遅れが発生していた際に下記の内容は妥当である
プロジェクト中の作業を見積もり、スケジュールお かを確認したか
PROBLEM
よびマイルストン時期を計画する。また、計画時 ・進捗率の定義（例：設計完了で50%、レビューを受けて80%、レ
期通りに完了できるように、定期的に監視・コント ビュー指摘への対処完了で100%）が明確であったか
・作業者の遅れを把握できる会議体を実施し、適切なエスカロールする。
IDEA
レーションを実施していたか・見積もりの精度、人員配備の妥当性について分析していたか (PROPOSAL)○：該当事例あり

日々のPDCAの実施

×：該当事例なし○：該当事例あり

開発効率化についてKEEP
×：該当事例なし

コスト管理

コストの基準値はクリアしていたか
また、特にクリアできていない場合に下記の内容は妥当である PROBLEM
プロジェクト予算を設定し、定期的にコスト状況をか確認したか管理する。
・コストについての計画との予実差を定期的に確認していたか
・計画時の見積もり手法は妥当であったか
IDEA○：該当事例あり(PROPOSAL)

×：該当事例なし

見積もり通りなのに計
画遅れ

KEEP

品質管理

品質基準（工程完了条件など）をクリアしていたか。
また、特にクリアできていない場合に下記の内容は妥当であるか確認したかPROBLEM
プロジェクトの品質ニーズを満たすために、品質 ・盛り込んだ品質施策の内容は妥当であったか
方針、品質計画、品質目標を設定し、対象物の ・品質尺度は妥当性か
・品質基準値そのものの妥当性について検証したか
品質を監視・モニタする。
・品質状況は工程内だけでなく、工程間（設計工程の品質不備 IDEAがプログラム工程に影響していないか 等）を検証していたか (PROPOSAL)

×：該当事例なし○：該当事例あり

工程完了時に定量的/定性的な品質分析基
準の見直し

×：該当事例なし

KEEP
×：該当事例なし

人的資源管理プロジェクト・チームを組織化し、マネジメントする。

・プロジェクト体制を明確にしメンバーに周知していたか
・教育の提供について十分だったか、次開発ではどのように教 PROBLEM
育を行うか検証していたか
・個々人の能力分析と、チームとしての能力分析を実施していたかIDEA

×：該当事例なし(PROPOSAL)

×：該当事例なし

KEEP
下記のメンバーとの連絡についての情報共有が適切であったか
ステークホルダおよびチームメンバーに対して、 ・開発内部
コミュニケーション管理 必要な情報をタイムリーに提供する。
・開発―品質部門間・開発―SE間・開発―開発外部のステークホルダー（顧客や上層部など）

×：該当事例なし

PROBLEM
×：該当事例なし
IDEA(PROPOSAL)○：該当事例あり

キックオフミーティング

KEEP

リスク管理

ステークホルダーのニーズについての計画とマ
ネジメントを行い、意思決定等にステークホル
ダーを適切に関与してもらう。

リスク抽出計画（時期、抽出観点、抽出体制・リスク特定後の管理方法、影響度、発生確率の定義）は明確で今回の開発において発生した問題は顕在化前にリスクとして抽出していたか
PROBLEM※特にPMだけでリスクを挙げているのではなく、特定する際に関係者を呼び、確実な抽出を行っていたか
・リスクへの対応が十分であったか検証したか
IDEA

×：該当事例なし(PROPOSAL)

×：該当事例なし

KEEP
調達管理

・協力会社への発注は基準に沿って適切に発注できていたか
外部が保有している技術や成果物を、プロジェク
PROBLEM
検証していたかトに活用する。そのための、外部技術や成果物
・協力会社の作業分の品質確認、進捗確認に問題が無かったの調達計画・管理を行う。
かを確認していたか
IDEA(PROPOSAL)

KEEP
プロジェクトの問題を未然に防止するため、リス

ステークホルダー管理 クを計画、識別、分析、監視、コントロールする。

×：該当事例なし○：該当事例あり
×：該当事例なし
×：該当事例なし○：該当事例あり

・ステークホルダーとの関係（プロジェクトへの認識、影響力、関 PROBLEM
与度合い）を分析したか

×：該当事例なし

IDEA(PROPOSAL)

×：該当事例なし－14－－4－

必要なテスト機材の確保品証部門との品質レ
ビュー

記入

P
R
O
P
O
S
A
L

I
D
E
A

P
R
O
B
L
E
M

K
E
E
P

選択式

4
5

3

2

1

#

7

6

5

選択式

コスト管理

コミュニケーション管理

調達管理

タイム管理

PMBOK

分類(観点チェックで選択したもの）（ソフトウェア実装、PMBOKのいずれか）

ソフトウェア実装

選択式

ソフトウェア詳細設計

プロジェクトキックオフミーティングに、協力会社も含めてほしい。（情報共有のため）テスト用に、高性能と低性能PC、新旧モデルPCを組み合わたいので、多種多様なPC環境がほしい。

開発効率化について
・すべてのレビューを1時間以内に終わるような工夫が必要（時間が取れない中、効率的に実施すべき。）
・周知事項は、会議をせずに、メールで周知する。

振り返り内容(IDEA,PROPOSAL)

記入

見積もり通りなのに、計画から遅れた。 不具合分析に時間をとられてタスクに割ける時間が減った。

機能テストで、異常ケースを忘れてしまい、最終テストで不具合が多発した。

下流工程で、設計者が想定した影響範囲以外の領域で、不具合が多発した。

レビュー指摘対応したが、確認してもらえずに、機能設計が遅れた。

3

4

途中で要件が変更となり、開発後戻りが発生した。

下流工程で、設計者が想定した影響範囲以外の領域で、不具合が多発した。

振り返り内容(PROBLEM)

ソフトウェア方式設計

品質管理

PMBOK

2

ソフトウェア構築

ソフトウェア実装

記入

記入

プロジェクトキックオフミーティングに、プロパ、協力会社含めて招集しよう！

2018年X月からのプロジェクトで利用するために、高性能ｘ低性能PC、新ｘ旧モデルPCを確保しよう！

開発効率化に向けて、無駄な会議は削除しよう！
・レビュー会議は1時間以内に終わらせよう。
・リーダーからメンバーへの連絡・周知事項は、メールで行おう！

TRY（改善） だから、こうしよう！

不具合分析も考慮し、予備工数を含めよう！

工程完了時に定量的/定性的な品質分析基準を見直し、開発者と工程完了承認者で認識を共有できるようにしよう！
異常ケースを考慮した設計にしよう！

4

2

2

重要度

選択式

2
1

4

レビュー計画を立案し、レビューイとレビューアで、レビュー実施日、修正確認日を共有しよう！

4

3

重要度

選択式

1

2

3

2

・設計開始前に、企画部門と会議を開き、要件を確認しよう！
・要件変更に備え、要件変更管理を徹底しよう！

プロセス開始の準備時に、有識者のレビュー時間を確保する計画を立てよう！

TRY（改善） だから、こうしよう！

記入

個人でPDCAを実践した結果、優先度の高い業務に集中できた。
前日までに当日の業務リストを優先度付きで作成し、当日帰宅前にチェックするよう心掛けた。
毎日PDCAを実行しよう！

プロジェクト計画時に、品質保証部門と、工程毎の、品質レビューレビューポイントを、事前に整合していた プロジェクト計画時に、ステークホルダーを洗い出し、整合しておこう！
結果、効率的にレビュー指摘が挙がり、かつ時間通りに完了した。

タイム管理

チーム間で定期的に会議体を開催し、上流品質確保の方法について議論し合おう！

ステークホルダ管理

ホワイトボックステストにおいて、従来設計者が属人的に行っていたものを、チーム間でテスト観点を合わせた。これにより、上流工程での品質向上が行われ、下流工程での不具合検出率が○○％削減した。

テストに必要な機材において、事前に必要数を確認し、設計（〇△さん）と調整した。そのため機材の不足 プロジェクト開発計画立案時に、テストに必要な機材の必要数を見積もり、関係者と調整しておこう！
は発生しなかった。

2

選択式

重要度

TRY（改善） だから、こうしよう！

記入

実行中

未着手

CLOSE

調達管理

振り返り内容(KEEP)

記入

全社、事業部

製品、プロジェクト

未着手

実行中

Status選択式

PMBOK

分類(観点チェックで選択したもの）（ソフトウェア実装、PMBOKのいずれか）

ソフトウェア構築

選択式

選択式

分類(観点チェックで選択したもの）（ソフトウェア実装、PMBOKのいずれか）

ソフトウェア実装

選択式

ソフトウェア要件定義

1

#

5

4

3

2

1

#

4

クオフミーティングに参加してもらう！そこでプロジェクトの目的と ダーYさん
計画を共有しよう！
1.工程完了時の定量的/定性的な品質分析基準を見直す。その 組織Aの経営層Bさん
際過去〇〇年の開発プロジェクトの品質メトリクスとリリース後の 1. 2018年3月まで
品質状況の関連性を分析する。
2, 2018年6月まで
2.組織管理層、品質保証部門承認の元、運用を開始し、開発者と工程完了承認者に周知する。

ホワイトボックステストの共通ルールを決め、毎週のチーム間ミー 開発プロジェクトXのティングで、実行状況を確認しよう！
PMO Kさん・企画部門と会議体を開き、要件に誤りがないかを確認する。
組織A全体のPMOリー 全社、事業部
・レビュー完了後万一要件が変更になる場合は、要件変更管理 ダーYさんを運用する。

PROBLEM

ホワイトボックスのテスト（ユニットテスト）

ロジェクトのキックオフミーティン マネージャー全員
有グ
工程完了時に定量的/定性的な品質分析基準を見直2018年7月以降の組織Aの開発プ 組織Aの 品質管理責任者 組織の品質基準
し、開発者と工程完了承認者で認識を共有できるように ロジェクト
Tさん
しよう！

含めて招集しよう！

ロジェクトのホワイトボックステス
トシステム設計3 プロジェクトキックオフミーティングに、プロパ、協力会社 2018年4月以降の組織Aの開発プ 組織Aの 開発プロジェクト プロジェクトの目的と計画の共 プロパー、協力会社含め、開発プロジェクトメンバー全員を、キッ 組織A全体のPMOリー 全社、事業部

ム間で共有して上流工程での品質を高めよう！

ロジェクト

IDEA

展開先
スコープは？

製品、プロジェクト

選択式

2 上流工程での品質確保方法のルール化を推進し、チー 2017年9月以降の組織Aの開発プ 組織Aの Fさん

よう！
・要件変更管理を徹底しよう。

開発プロジェクトAのPMO Kさん次のプロジェクトで誰がフォローするか？

記入

KEEP

どのように行うか？
(How?)

・レビュー計画を立案する。
・有識者を割り当て、レビュー時間を確保する。

（真因分析した結果、3W1Hでアクションを記載しよう。）

何を？
(What?)

開発プロジェクトAのプロ
有識者の割り当てとレビュー
ジェクトマネージャー Sさん 計画

誰が？
(Who?)

記入

2 ・設計開始前に、企画部門と会議を開き、要件を確認し 2018年4月以降の組織Aの開発プ 組織Aの Fさん

ジェクトBのシステム設計段階

いつ？（いつまでに？）When？（By When?)記入←観点チェックのシートの情報が表示されます。

記入

PROBLEMする計画を立てよう！

(TRY宣言対象の内容を転記しよう！)

FOPA TRY宣言

下表のTRYを転記

1 プロセス開始の準備時に、有識者のレビュー時間を確保 次のバージョンアップ開発プロ＃

記入←観点チェックのシートの情報が表示されます。

Bチーム

個人名orチーム名※観点リストを運用する場合、「○：該当事例あり」の分類について、本KPTシートに記載してください。

Aプロジェクト バージョンアップ V〇.〇

開発プロジェクト名

PROBLEM

区分

選択式

ＦＯＰＡ KPTシート【付録4：FOPA KPTシート (記入例)】(記入例)】

))))

((((

－15－
－5－

フォロー

宣言対象

宣言対象外

宣言対象外

TRY宣言対象

振り返りアセスメント

選択式

宣言対象外

宣言対象外

宣言対象

宣言対象外

宣言対象

宣言対象

TRY宣言対象

振り返りアセスメント

選択式

宣言対象外

宣言対象外

宣言対象

宣言対象外

TRY宣言対象

振り返りアセスメント

選択式

過去〇〇年の品質メトリクスを集計中。

2018月１月から開始から全開発プロジェクトで実施する。

チーム間ミーティングを毎週開催し、ホワイトボックスのチーム間共有と実行状況確認の運用が定着したため、CLOSE。

2018月１月から開始から全開発プロジェクトで実施する。
企画部門とは整合済。

○月○○日に会議体を開き、要件の妥当性を確認予定。

補足（CLOSEの場合は、必ず理由を記入）

記入

－16－
－6－

事象
下流工程で、設計者が想定した影響範囲以外の領域で、不具合が多発した。

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

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

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

PROBLEM #02

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

KEEP/PROBLEM 番号(#):

【FOPA なぜなぜ分析シート】【付録5：FOPA なぜなぜ分析シート(記入例)
なぜなぜ分析シート(記入例)】(記入例)】

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

なぜ３
なぜ、レビューアが影響範囲を見誤ったのか？

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

なぜ４
なぜ、有識者が参加しなかったのか？

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

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

「TRY」をFOPA KPTシートに転記しよう！

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

－17－
－7－

５）TRY宣言４）「どうして」
の解決策

３）抽象化
（FMEA形式）２）事実の整理＜手順＞
１）KEEP/PROBLEMの抽出

KEEP/PROBLEM 番号(#): PROBLEM #02

下流工程の品質が悪くなった。

だから、こうしよう！（TRY)５）をFOPA KPTシートに転記しよう！

自分にとって、「納得性、有効性、実現可能性」のある内容を書こう！
後で、実施状況をチェックするように、具体的な内容にしよう！

阻害要因を解決できる方法を考えよう。「納得性、有効性、実現可能性」
を持つことができるかを考えよう。

①プロジェクト計画時にレビュー計画を立て、有識者のレビュー時間を確保する。

抽象化した「何がどうしてどうなったか」を受けて、次のプロジェクトでTRYする内容を宣言しよう！

「どうして」の阻害要因をしっかり考えよう！。分からなければ、他の人に相談しよう。

何が？：観点チェックの、ソフトウェア工程（共通フレーム2013）、PMBOKの知識領域
どうして？：観点チェックの、具体的要求事項 レベルの内容
どうなった：開発プロジェクトのCostやDelivery、製品のQualityや要件が達成できたorできなかった など

自チーム内で通じる言葉で、「何について」「内部的に、どのような良い/
悪い出来事があって」「外部的に、どのような良い/悪いことにつながったか？を書いてください。」

記入時の説明KEEP/PROBLEMの事実を記載してください。（この時点では、「思い付KEEP/PROBLEMき」のフリーフォーマットで可。）

有識者のレビューを実施しなかったので、「どうして」を阻害する要因と、解決方法を考えよう！

影響範囲を見誤ったので、「どうして」「どうなった」

下流工程で、設計者が想定した範囲以外で、不具合が▲件発生した。

プロセス開始の準備時に、有識者のレビュー時間を確保する計画を立て、確実にレビューを実施してもらおう！

どうしたら阻害要因は解決できるのか？

PROBLEM：「どうしてしなかった」の阻害要因は何だろう？
KEEP：「どうして」を継続できない阻害要因は何だろう？

ソフトウェア詳細設計「何が」有識者の確認やレビューを行わなかった
ので、内部的な設計範囲を見誤ってしまい、

上流工程における、○○機能の設計において外部的に、どのような良い/悪いことがあった
外部的に、
のか？
（外部的：開発プロジェクトのCostやDelivery、
製品のQualityや要件など）

マネージャや、他チームにも共有できるように、抽象度を上げよう！

内部的に、どのような良い/悪いことが内部的に、あったのか？
（内部的：プロジェクト内、あるいは製品に関する内部的な出来事）「何について」の事象なのか？
「何について」事実として、「何がどうしてどうなった？」で分類しよう！

PROBLEM：下流工程で、設計者が想定した影響範囲以外の領域で、不具合が多発した。

【FOPA 真因分析シート】【付録6：FOPA 真因分析シート （記入例）】（記入例）】

－18－
－8－

質問

○あまりそう思わない○あまりそう思わない○あまりそう思わない○あまりそう思わない○あまりそう思わない○あまりそう思わない○あまりそう思わない○少しそう思う○少しそう思う○少しそう思う○少しそう思う○少しそう思う○少しそう思う○少しそう思う○少しそう思う

振り返りアセスメントで重要度、頻度は選択しやすいですか︖○とてもそう思う
振り返り内容、分類、振り返りアセスメントによって、”改善（TRY)だから、こうしよう︕”の記載に関して記載○とてもそう思う
しやすいでしょうか
展開先スコープは、TRYを実践する上で、有効でしょうか︖○とてもそう思う「KEEP」、「PROBLEM」欄に対して、良かった点・改善点などの意⾒があれば、記⼊ください。（⾃由記⼊）「IDEA(PROPOSAL)」欄のフォーマットは記載しやすいですか︖「IDEA(PROPOSAL)」欄のフォーマットはKPT整理に有効ですか︖
分類（ソフトウェア⼯程、PMBOK)によって、”TRY(改善)だから、こうしよう︕”は、導出しやすいですか︖「IDEA(PROPOSAL)」欄に対して、良かった点・改善点などの意⾒があれば、記⼊ください。（⾃由記⼊）しやすいでしょうか?

○とてもそう思う

４．「IDEA(PROPOSAL」 振り返りアセスメントで重要度、頻度を選択するのは、優先度の⾼いTRYを選択する上で、有効でしょうか︖ ○とてもそう思う
欄は振り返りを実践する上で、振り返りアセスメントで重要度、頻度は選択しやすいですか︖○とてもそう思う
有効でしょうか︖
振り返り内容、分類、振り返りアセスメントによって、”改善（TRY)だから、こうしよう︕”の記載に関して記載○とてもそう思う○とてもそう思う○とてもそう思う○あまりそう思わない○少しそう思う○少しそう思う○あまりそう思わない○あまりそう思わない○あまりそう思わない○少しそう思う

振り返りアセスメントで重要度、頻度を選択するのは、優先度の⾼いTRYを選択する上で、有効でしょうか︖ ○とてもそう思う○あまりそう思わない○あまりそう思わない○少しそう思う○少しそう思う○あまりそう思わない○あまりそう思わない○あまりそう思わない○あまりそう思わない○あまりそう思わない○少しそう思う

観点シート中の以下の「PMBOK知識エリア」情報は、管理⾯の重要なKPTを⾒つける上で有効でしょうか︖
・統合管理、・スコープ管理、・タイム管理、・コスト管理、・品質管理、・⼈的資源管理○とてもそう思う
・コミュニケーション管理、・ステークホルダー管理、・リスク管理、・調達管理○あまりそう思わない○少しそう思う○少しそう思う○とてもそう思う○あまりそう思わない○少しそう思う○少しそう思う○少しそう思う○少しそう思う○とてもそう思う○あまりそう思わない○あまりそう思わない○少しそう思う○少しそう思う○あまりそう思わない○少しそう思う「振り返り観点チェック」シートに対して、良かった点・改善点などの意⾒があれば、記⼊ください。（⾃由記⼊）FMEA形式（何が、どのようにしたため、どうなった）のフォーマットは記載しやすいですか︖○とてもそう思う
FMEA形式（何が、どのようにしたため、どうなった）のフォーマットはKPT整理に有効ですか︖○とてもそう思う
FMEA形式（何が、どのようにしたため、どうなった）がうまく書けない場合は、整理のため、真因分析を実施○とてもそう思う
するのは、適切な運⽤だと思いますか︖
FMEA形式（何が、どのようにしたため、どうなった）がうまく書けない場合のみ真因分析を実施するのは、プ○とてもそう思う
ロセス上、実施者の負担を軽減する意味で有効でしょうか︖
分類（ソフトウェア⼯程、PMBOK)によって、”TRY(改善)だから、こうしよう︕”は、導出しやすいですか︖○とてもそう思う
3．「KEEP」、「PROBLEM」 FOPA真因分析シートは、真因分析を導出するために、有効でしょうか︖○とてもそう思う欄について、振り返りを実践す FOPAなぜなぜ分析シートは、真因分析を導出するために、有効でしょうか︖○とてもそう思う

る上で、有効でしょうか︖

日付

回 答 ＊当てはまるセルをダブルクリックしてください

チーム名・⽒名︓○とてもそう思う

観点シート中の以下の「ソフトウェア実装プロセス」情報は、各実装プロセスを網羅的に振り返る上で有効でしょうか︖
・ソフトウェア実装プロセス開始の準備・ソフトウェア要件定義・ソフトウェア方式設計・ソフトウェア詳細設計
・ソフトウェア構築・ソフトウェア結合・ソフトウェア適格性確認テスト・ソフトウェア導⼊・ソフトウェア受け⼊れ支援観点シート中の以下の「ソフトウェア実装プロセス」情報は、各実装プロセスの重要なKPTを⾒つける上で有効でしょうか︖
・ソフトウェア実装プロセス開始の準備・ソフトウェア要件定義・ソフトウェア方式設計・ソフトウェア詳細設計
2．「振り返り観点チェック」
・ソフトウェア構築・ソフトウェア結合・ソフトウェア適格性確認テスト・ソフトウェア導⼊・ソフトウェア受け⼊れ支は、観点網羅（抽出）に対し 援観点シート中の以下の「PMBOK知識エリア」情報は、管理⾯を網羅的に振り返る上で有効でしょうか︖て、有効でしょうか︖
・統合管理、・スコープ管理、・タイム管理、・コスト管理、・品質管理、・⼈的資源管理
・コミュニケーション管理、・リスク管理、・調達管理、・ステークホルダー管理

FOPA 振り返りプロセスについて、良かった点・改善点などの意⾒があれば、記⼊ください。（⾃由記⼊）FOPA 振り返りプロセス（観点チェック、KPTシート作成、TRY実践フォロー）は、実開発プロジェクトで実践○とてもそう思う
可能ですか︖
１．「FOPA 振り返りプロセ FOPA 振り返りプロセス（観点チェック、KPTシート作成、TRY実践フォロー）は、実開発プロジェクトで実践○とてもそう思う
ス」について、有効でしょうか︖ するにあたり、かける時間に対して効果は発揮できると思いますか︖

カテゴリ

開発プロジェクトの振り返りで実⾏していただいた、FOPA 振り返りプロセス、新テンプレートについて、ご意⾒をきかせてください。

FOPA 振り返りプロセス、観点チェック、KPTシートのアンケート【付録7-(1):アンケート（前半部分）】○まったくそう思わない○まったくそう思わない○まったくそう思わない○まったくそう思わない○まったくそう思わない○まったくそう思わない○まったくそう思わない○まったくそう思わない○まったくそう思わない○まったくそう思わない○まったくそう思わない○まったくそう思わない○まったくそう思わない○まったくそう思わない○まったくそう思わない○まったくそう思わない○まったくそう思わない○まったくそう思わない○まったくそう思わない○まったくそう思わない○まったくそう思わない○まったくそう思わない○まったくそう思わない

0

0

0

0

詳細結果 カテゴリ結果

－19－
－9－

○とてもそう思う○とてもそう思う○とてもそう思う

FOPAプロセス、観点チェック、KPTシートは、「自主的な活動に依存。組織の支援がない。」を解決するために、有効でしょうか︖
FOPAプロセス、観点チェック、KPTシートは、「他製品に展開していくと、実施することが増え、プロセスの肥
大化につながる。」を解決するために、有効でしょうか︖
FOPAプロセス、観点チェック、KPTシートは、振り返り結果を他製品へ横展開するプロセスやツールとして、有効でしょうか︖
３）最後に、振り返り活動全般、FOPAプロセス、観点チェック、KPTシート全体について、ご意⾒をお願いします。
FOPAプロセス、観点チェック、KPTシートは、今後も使っていきたいでしょうか︖
FOPAプロセス、観点チェック、KPTシートを、今後活⽤するにあたり、何をどのように改善すべきでしょうか︖（⾃由記⼊）
振り返り活動に対して、意⾒があれば教えてください。（別の課題や改善提案など）

8. 我々研究者が考える、振り ２）我々は、職場で実践している振り返りの中で、他製品へ横展開する方法が確⽴していないと考えていま返りの問題を解決するのに、 す。これは、以下の理由によると考えます。
「FOPA 振り返りプロセス、観 ・⾃主的な活動に依存。組織の支援がない。
点チェック、KPTシート」は有効 ・他製品に展開していくと、実施することが増え、プロセスの肥大化につながる。
・振り返り結果を他製品へ横展開するプロセスがない。
でしょうか︖○あまりそう思わない○少しそう思う○少しそう思う○少しそう思う○少しそう思う○とてもそう思う○とてもそう思う○とてもそう思う○あまりそう思わない○あまりそう思わない○あまりそう思わない○あまりそう思わない○あまりそう思わない○あまりそう思わない○少しそう思う○少しそう思う○あまりそう思わない○あまりそう思わない○あまりそう思わない○あまりそう思わない○あまりそう思わない○少しそう思う○少しそう思う○少しそう思う○少しそう思う○とてもそう思う

FOPAプロセス、観点チェック、KPTシートは、「表現的な分析で留まっており、真因分析までたどり着けな○とてもそう思うい。」を解決するために、有効でしょうか︖
FOPAプロセス、観点チェック、KPTシートは、「振り返りの網羅性が低い。重要案件を発⾒できない可能性○とてもそう思うあり。」を解決するために、有効でしょうか︖
FOPAプロセス、観点チェック、KPTシートは、「多数のKPTからどれを実践すれば良いか悩む。」を解決する○とてもそう思う
ために、有効でしょうか︖

１）我々は、職場で実践している振り返り結果のKPTの質が低いため、次のプロジェクトで十分に活⽤できないと考えています。これは以下の理由により、振り返り結果の納得性、実現性可能性、有効性が低いためであると考えています。
・表現的な分析で留まっており、真因分析までたどり着けない。
・振り返りの網羅性が低い。重要案件を発⾒できない可能性あり。
・多数のKPTからどれを実践すれば良いか悩む。

7. 「フォロー（Status）」欄
Status欄で、CLOSEの状態を設けることは、プロセスの肥大化を防⽌するために、有効でしょうか︖
は、振り返りのTRYを実践する「フォロー（Status）」欄に対して、良かった点・改善点などの意⾒があれば、記⼊ください。（⾃由記⼊）上で有効でしょうか︖

Status欄は次のプロジェクトで、TRYの状況を確認するために、有効でしょうか︖

振り返りTRY宣言対して、良かった点・改善点などの意⾒があれば、記⼊ください。（⾃由記⼊）他チームや横展開は、この振り返りTRY宣言を⾏うことで有効に展開できるでしょうか︖○少しそう思う

して、有効でしょうか︖○少しそう思う○とてもそう思う○とてもそう思う

振り返り宣言は、最も大事なTRYを、次のプロジェクトなどで実践するために、有効でしょうか︖
いつ、だれが、何を、どのように⾏うかの３W1H のフォーマットは、管理層や、周りのメンバーに、自分のアク6．「振り返りTRY宣言」に関 ションを伝えるのに、有効でしょうか︖○あまりそう思わない○あまりそう思わない

回 答 ＊当てはまるセルをダブルクリックしてください○少しそう思う○少しそう思う○とてもそう思う○とてもそう思う質問

5. 「展開先スコープ」欄は、振 展開先スコープは、TRYを実践する上で、スコープが明確になることで、有効でしょうか︖
展開先スコープは、振り返り結果を他チームや、他製品、組織全体に展開するために、有効でしょうか︖
り返りのTRYを実践する上で「展開先スコープ」欄に対して、良かった点・改善点などの意⾒があれば、記⼊ください。（⾃由記⼊）
有効でしょうか︖

カテゴリ【付録7-(2):アンケート（後半部分）】○まったくそう思わない○まったくそう思わない○まったくそう思わない○まったくそう思わない○まったくそう思わない○まったくそう思わない○まったくそう思わない○まったくそう思わない○まったくそう思わない○まったくそう思わない○まったくそう思わない○まったくそう思わない○まったくそう思わない○まったくそう思わない

総合結果

0

0

0

0

0

詳細結果 カテゴリ結果

－20－
－10－
『肯定的な意⾒』『否定的な意⾒』
・本気で取り組む⼈とそうでない⼈とでGAPが⽣まれる可能性が感じられた。 → 支援を⾏うことで効果が得られる。
・有効活用できるようになるまでのハードルが高い。組織的教育が必要。

観点シート中の以下の「ソフトウェア実装プロセス」情報は、各実装プロセスの重 ・観点シートで洗い出しを実施するのは網羅性向上に有効
要なKPTを⾒つける上で有効でしょうか︖
・観点抽出が苦手な⼈には役⽴つソフトウェア実装プロセス開始の準備、ソフトウェア要件定義、ソフトウェア方式設 ・管理者視点と設計者視点で観点を分けるのは有効。
計、ソフトウェア詳細設計、ソフトウェア構築（プログラミング）、ソフトウェア結合、
・KEEPのところを⾒つける場合は有用
ソフトウェア適格性確認テスト、ソフトウェア導⼊、ソフトウェア受け⼊れ支援観点シート中の以下の「ソフトウェア実装プロセス」情報は、各実装プロセスを網羅的に振り返る上で有効でしょうか︖
ソフトウェア実装プロセス開始の準備、ソフトウェア要件定義、ソフトウェア方式設
計、ソフトウェア詳細設計、ソフトウェア構築（プログラミング）、ソフトウェア結合、
ソフトウェア適格性確認テスト、ソフトウェア導⼊、ソフトウェア受け⼊れ支援

ださい。（自由記⼊）『肯定的な意⾒』
・従来の振り返り（ざっくばらんなKPT）よりしっかりと考えられる手順である・振り返りの質を一定レベルに保つことに有用・シート作成まではそれほど問題なく実践可能・振り返るレベルには有効・深く考える機会を与えてくれる回答『否定的な意⾒について、本研究で対応済』
・「KPT」の手軽さがなくなってしまう → KPTシートを簡略化して、対応済。
FOPA 振り返りプロセスについて、良かった点・改善点などの意⾒があれば、記⼊く ・もっとシンプルな方が良い。Keep、problem、tryに絞って自由に記載など → 本研究で対応済。

FOPA 振り返りプロセス（任意︓観点チェック、KPTシート作成、TRY実践フォロー）は、実開発プロジェクトで実践するにあたり、かける時間に対して効果は発揮できると思いますか︖

FOPA 振り返りプロセス（任意︓観点チェック、KPTシート作成、TRY実践フォロー）は、実開発プロジェクトで実践可能ですか︖

質問

1 2 2 3 2 1 2 1 2 3 2 3 2.0

1 2 2 3 1 1 2 1 1 3 2 2 1.8

3 2 3 3 3 2 2 2 3 2 2 3 2.5

1 2 2 3 2 2 2 2 3 2 2 2 2.1

各人の回答（1︓とてもそう思う、2︓少しそう思う、
3︓あまりそう思わない、4︓まったくそう思わない）
a〜lは回答者を表す
・平均値が2.0未満:有効
・平均値が2.5を超える︓有効でないと判断し，該当シートを改善a b c d e f g h i j k l 平均値「振り返り観点チェック」シートに対して、良かった点・改善点などの意⾒があれば、記⼊ください。（自由記⼊）観点シート中の以下の「PMBOK知識エリア」情報は、管理⾯の重要なKPTを⾒つける上で有効でしょうか︖
統合管理、スコープ管理、タイム管理、コスト管理、品質管理、⼈的資源管理
コミュニケーション管理、リスク管理、調達管理、ステークホルダー管理

2 2 3 4 1 1 2 1 2 3 2 3 2.2

2．「振り返り観点チェック」
は、観点網羅（抽出）に対『否定的な意⾒』
して、有効でしょうか︖
観点シート中の以下の「PMBOK知識エリア」情報は、管理⾯を網羅的に振り返・「網羅的に振り返る」という部分の意図が不明確 →（プロジェクト全体を⼗分把握している）管理層にとって、網羅る上で有効でしょうか︖
的に振り返る意味が薄いという意⾒。本当に⼗分なのか、実践での検証が必要。
2 2 3 4 1 2 1 1 2 3 2 2 2.1
統合管理、スコープ管理、タイム管理、コスト管理、品質管理、⼈的資源管理
・PROBLEMは「ここがダメだ」という認識が先に来るために、分類単位で問題点を⾒つけることの意義が不明確 →コミュニケーション管理、リスク管理、調達管理、ステークホルダー管理
気づかないところ、忘れているところを思い起こさせる意味で有効であると推察。
・有効であるが、（PMBOK知識体系の）ただ⾔葉が分からない⼈は勉強が必要 →教育、支援が必要。

１．「FOPA 振り返りプロセス」について、有効でしょうか︖

カテゴリ【付録8:アンケート結果詳細】

－21－
－11－

2 2 2 3 1 2 1 2 2 2 3 3 2.1
2 2 2 3 2 2 1 3 1 3 3 3 2.3

振り返り内容、分類、振り返りアセスメントによって、”改善（TRY)だから、こうしよ ・フリーフォーマットですが、改善アイデアに対してなぜそうしたほうがよいのか、背景・根拠を整理して記載できる枠組みがう︕”の記載に関して記載しやすいでしょうか?
あったほうが良い。 →真因分析、なぜなぜ分析シートを使って背景・根拠を整理することを推奨。

2 3 3 2 3 2 2 3 2 3 3 4 2.7

2 2 2 3 2 1 1 1

1 3 2 3 1 1 1 1

未回答

1.8

1.7

2 3 4 3 2 1 2 2 2 2 3 3 2.4

3 3 2 2 3 1 2 3 2 3 3 3 2.5

3 2 4 4 2 2 2 2 3 3 3 3 2.8

3 2 2 3 3 2 2 3 1 2 3 3 2.4
3 2 2 3 2 2 2 3 1 2 3 4 2.4

2 2 2 2 3 1 1 1 2 3 3 4 2.2

2 2 4 3 2 1 2 2 2 3 3 3 2.4

2 3 3 3 3 2 3 3 2 3 3 3 2.8

3 3 2 2 2 1 2 3 2 3 3 3 2.4

2 2 2 3 1 2 1 3 2 3 2 2 2.1

2 2 2 3 1 2 1 3 2 3 2 2 2.1

4 2 4 4 2 2 3 2 3 3 3 3 2.9「IDEA(PROPOSAL)」欄に対して、良かった点・改善点などの意⾒があれば、記⼊ください。（自由記⼊）
展開先スコープは、TRYを実践する上で、スコープが明確になることで、有効でしょ 『肯定的な意⾒』
2うか︖
・TRYの展開先スコープが明確であるため、関係者と共有しやすい（⾏動がとりやすく、次開発プロジェクトの改善につな
5. 「展開先スコープ」欄は、展開先スコープは、振り返り結果を他チームや、他製品、組織全体に展開するた2
がる）
振り返りのTRYを実践する上めに、有効でしょうか︖
で有効でしょうか︖「展開先スコープ」欄に対して、良かった点・改善点などの意⾒があれば、記⼊くだ『否定的な意⾒⇒なし』
さい。（自由記⼊）

４．「IDEA(PROPOSAL」
欄は振り返りを実践する上で、有効でしょうか︖『肯定的な意⾒』
分類（ソフトウェア⼯程、PMBOK)によって、”TRY(改善)だから、こうしよう︕”
は、導出しやすいですか︖ →アンケート時点から意味づけを変え、観点チェック ・KEEP/PROBLEMのフォーマットでは書きにくい項目もあるので、それらとは別に欄を設けるのは良いシートとKPTシートをつなぐ情報として利⽤する。
振り返りアセスメントで重要度、頻度を選択するのは、優先度の高いTRYを選択 『否定的な意⾒』
する上で、有効でしょうか︖
・KEEP/PROBLEMのTryで⼗分では︖（改善アイデアがあるなら、必ず、問題があったはず）→ KPTシートを簡略
振り返りアセスメントで重要度、頻度は選択しやすいですか︖
化して、対応済。

「IDEA(PROPOSAL)」欄のフォーマットはKPT整理に有効ですか︖「IDEA(PROPOSAL)」欄のフォーマットは記載しやすいですか︖「KEEP」、「PROBLEM」欄に対して、良かった点・改善点などの意⾒があれば、記⼊ください。（自由記⼊）→ アンケート時点で存在していたが、最終的に本欄を削除することで、対応済。
『否定的な意⾒』
振り返り内容、分類、振り返りアセスメントによって、”改善（TRY)だから、こうしよ なし。
う︕”の記載に関して記載しやすいでしょうか
展開先スコープは、TRYを実践する上で、有効でしょうか︖

・もっとシンプルでいいのでは。 → KPTシートを簡略化して、対応済。
・「PROBLEM」で振り返りアセスメント欄の改善要否は不要。問題として列挙しているので改善するのは当然 →KPTシートを簡略化して、対応済。
FOPAなぜなぜ分析シートは、真因を導出するために、有効でしょうか︖
振り返りアセスメントで重要度、頻度を選択するのは、優先度の高いTRYを選択 ・「重要度」の、粒度が荒い。テーマ全体の振り返りには良いが、各チームの業務レベルでは、3,4はほとんど発⽣しない→重要度を⾒直した。また各社でカスタマイズできるようにしたことで、解決する運用とする。
する上で、有効でしょうか︖
・発⽣頻度は書きづらい。新旧プロジェクトで異なるため、書いても意味がない。 →KPTシートから削除。対応済。
振り返りアセスメントで重要度、頻度は選択しやすいですか︖

欄について、振り返りを実践す
FOPA真因分析シートは、真因を導出するために、有効でしょうか︖
る上で、有効でしょうか︖

2 3 1 3 3 2 3 3 2 2 3 4 2.6

3 2 2 3 3 1 2 2 2 2 3 3 2.3FMEA形式（何が、どのようにしたため、どうなった）がうまく書けない場合は、整 『肯定的な意⾒』
理のため、真因分析を実施するのは、適切な運用だと思いますか︖
・振り返りフローに沿って整理できて良い

回答

各人の回答
（1︓とてもそう思う、2︓少しそう思う、
3︓あまりそう思わない、4︓まったくそう思わない）
a〜lは回答者を表す
・平均値が2.0未満:有効
・平均値が2.5を超える︓有効でないと判断し，該当シートを改善a b c d e f g h i j k l 平均値

FMEA形式（何が、どのようにしたため、どうなった）のフォーマットは記載しやすいですか︖
FMEA形式（何が、どのようにしたため、どうなった）のフォーマットはKPT整理に有効ですか︖

質問

FMEA形式（何が、どのようにしたため、どうなった）がうまく書けない場合のみ真 ・真因分析シートで、（順を追って分析できるので）真因を抽出するために、分析が⾏い易い
因分析を実施するのは、プロセス上、実施者の負担を軽減する意味で有効でしょ ・なぜなぜ分析シートは、不具合分析に使っている帳票と似ているので、使いやすい。
うか︖
・KEEP/PROBLEM欄のフォーマットについては、左から右に手順に沿って記載できるので、慣れてくれば書きやすい→ アンケート時点で存在していたが、最終的に本欄を削除することで、対応済。
『否定的な意⾒について、本研究で対応済』
分類（ソフトウェア⼯程、PMBOK)によって、”TRY(改善)だから、こうしよう︕”
・分類がなくてもTRYは書けるので分類は不要 → KPTシートを簡略化して、対応済。
は、導出しやすいですか︖ →アンケート時点から意味づけを変え、観点チェック
3．「KEEP」、「PROBLEM」 シートとKPTシートをつなぐ情報として利⽤する。
・FMEA形式での⼊⼒は記⼊者にとって負担が⼤きい → KPTシートを簡略化して、対応済。

カテゴリ【付録8:アンケート結果詳細】

－22－
－12－

質問

『否定的な意⾒⇒なし』

回答⼊ください。（自由記⼊）7. 「フォロー（Status）」欄
は、振り返りのTRYを実践す
る上で有効でしょうか︖「フォロー（Status）」欄に対して、良かった点・改善点などの意⾒があれば、記Status欄で、CLOSEの状態を設けることは、プロセスの肥⼤化を防止するために、有効でしょうか︖『否定的な意⾒』 → 具体的な実⾏支援のプロセス化が必要という意⾒。 今後の課題と捉える。
・Statusを記⼊する最初のタイミングは、次のテーマが始まるときだと思いますが、その後のチェックタイミングが不明確
・いつ誰がフォローするかが不明確
・誰がどの基準でcloseするのか、期限等はどうするのかなど、この欄の運用方法が不明確『否定的な意⾒について、本研究で対応済』
・「フォロー」の内容を更新するタイミングをコメントに記載したほうがよい →備考欄を設けることで、対応済。

・次開発プロジェクトでの実践状況を記載し共有する上で有効。実⾏支援に役⽴つ。

Status欄は次のプロジェクトで、TRYの状況を確認するために、有効でしょうか︖ 『肯定的な意⾒』

振り返り宣⾔は、最も⼤事なTRYを、次のプロジェクトなどで実践するために、有『肯定的な意⾒』
効でしょうか︖
いつ、だれが、何を、どのように⾏うかの３W1H のフォーマットは、管理層や、周り ・意思を明確に示す意味で有用のメンバーに、自分のアクションを伝えるのに、有効でしょうか︖
・個⼈以外の協⼒が必要な場合は、今回のような仕組みとセットにすることで効果を発する
6．「振り返りTRY宣⾔」に関 他チームや横展開は、この振り返りTRY宣⾔を⾏うことで有効に展開できるでしょ・他チームとしては内容を⾒て、判断できるうか︖
して、有効でしょうか︖
・TRYの項目について重点的に実施するものを定めることで、次開発プロジェクトでの留意点が明確になる
振り返りTRY宣⾔対して、良かった点・改善点などの意⾒があれば、記⼊ください。（自由記⼊）カテゴリ【付録8:アンケート結果詳細】

2 2 3 3 2 2 1 3 2 3 3 4 2.5

3 2 2 3 2 2 1 3 1 2 3 4 2.3

3 2 2 3 1 2 2 3 2 3 3 4 2.5

2 2 2 3 1 1 1 2 1 2 3 2 1.8

3 2 2 3 1 2 1 2 1 2 3 2 2.0

各人の回答（1︓とてもそう思う、2︓少しそう思う、
3︓あまりそう思わない、4︓まったくそう思わない）
a〜lは回答者を表す
・平均値が2.0未満:有効
・平均値が2.5を超える︓有効でないと判断し，該当シートを改善a b c d e f g h i j k l 平均値

－23－
－13－

FOPAプロセス、観点チェック、KPTシートは、「表現的な分析で留まっており、真 ・シート"KPTシート"の振り返りTRY宣⾔は必要・真因を求めるために重要な作業である
因分析までたどり着けない。」を解決するために、有効でしょうか︖

１）我々は、職場で実践している振り返り結果のKPTの質が低いため、次のプロジェクトで⼗分に活用できないと考えています。これは以下の理由により、振り返り
結果の納得性、実現性可能性、有効性が低いためであると考えています。
・表現的な分析で留まっており、真因分析までたどり着けない。
・振り返りの網羅性が低い。重要案件を発⾒できない可能性あり。
・多数のKPTからどれを実践すれば良いか悩む。
『肯定的な意⾒』

質問

回答

2 2 3 3 2 2 1 1 2 3 3 3 2.3

各人の回答（1︓とてもそう思う、2︓少しそう思う、
3︓あまりそう思わない、4︓まったくそう思わない）
a〜lは回答者を表す
・平均値が2.0未満:有効
・平均値が2.5を超える︓有効でないと判断し，該当シートを改善a b c d e f g h i j k l 平均値

振り返り活動に対して、意⾒があれば教えてください。（別の課題や改善提案など） （自由記⼊）

FOPAプロセス、観点チェック、KPTシートを、今後活用するにあたり、何をどのように改善すべきでしょうか︖ （自由記⼊）FOPAプロセス、観点チェック、KPTシートは、今後も使っていきたいでしょうか︖

3 2 3 3 2 2 2 2 3 3 3 2 2.5

・KPTの手軽さと本シートの両⽴ができるとより良い
FOPAプロセス、観点チェック、KPTシートは、「振り返りの網羅性が低い。重要案 ・シンプルな観点リストは反省点を考える上で有効
2 3 3 3 1 2 2 1 2 3 3 3 2.3
件を発⾒できない可能性あり。」を解決するために、有効でしょうか︖
・振り返り分析は質が高くても、他のタスクと比べて優先順位が低ければやらないので、開発のプロセスに組み込むのは
FOPAプロセス、観点チェック、KPTシートは、「多数のKPTからどれを実践すれば ⼤賛成
2 3 3 3 2 1 1 2 2 2 3 3 2.3
良いか悩む。」を解決するために、有効でしょうか︖
・優先度の高い改善を⾏うには有効
２）我々は、職場で実践している振り返りの中で、他製品へ横展開する方法が ・今までの振り返りは任意や思い付きの実施がほとんどだったので、プロセスとして組み込むと適切な分析ができるようにな
8. 我々研究者が考える、振 確⽴していないと考えています。これは、以下の理由によると考えます。
る。
り返りの問題を解決するのに、 ・自主的な活動に依存。組織の支援がない。
「FOPA 振り返りプロセス、観 ・他製品に展開していくと、実施することが増え、プロセスの肥⼤化につながる。
『否定的な意⾒』
点チェック、KPTシート」は有 ・振り返り結果を他製品へ横展開するプロセスがない。
・最初にKPTシートを記載するのは⼤変。余計な分析までをする手間がかかる。 →KPTシートの簡略化＆重要度のFOPAプロセス、観点チェック、KPTシートは、「自主的な活動に依存。組織の支 高いに絞り分析することで「解決済」では︖
効でしょうか︖
3 3 3 3 2 2 2 1 3 3 3 2 2.5
援がない。」を解決するために、有効でしょうか︖
・②-5時点までは、観点チェックのネタ出しにとどめ、最後にTeam内で完成させる方がよい。→ 優先度の高いものを振FOPAプロセス、観点チェック、KPTシートは、「他製品に展開していくと、実施する り返り会で共有するプロセスにしたことで、対応済。
ことが増え、プロセスの肥大化につながる。」を解決するために、有効でしょうか︖ ・強制的に実施させるのは手間がかかるので、分析が苦手/出来ない⼈向けの補助ツールとしての運用の方が良い。
4 3 3 3 3 2 3 3 3 3 3 2 2.9→プロセスの肥大化を防⽌するためには、具体的な実⾏支援のプロセス化が ・記⼊項目多く、作業コストがかかってしまう。 → KPTシートを簡略化して、対応済。
必要という意⾒。 今後の課題と捉える。
・振り返りアセスメント欄の頻度について管理⾯（スケジュール、規模⾒積もり、コストなど）に関する振り返りには重要
FOPAプロセス、観点チェック、KPTシートは、振り返り結果を他製品へ横展開す
度だけで⼗分 → KPTシートを簡略化して、対応済。
2 2 2 3 2 2 2 3 2 3 3 3 2.4
るプロセスやツールとして、有効でしょうか︖
３）最後に、振り返り活動全般、FOPAプロセス、観点チェック、KPTシート全体 ・個⼈に特化する内容は、分別した方がよい。これを含めると、分析にも時間がかかる。プロセスの肥⼤化にもつながる。
→ 優先度の高いものに分析を絞ることで、対応済。
について、ご意⾒をお願いします。

カテゴリ【付録8:アンケート結果詳細】

－24－
－14－

振り返り結果の受け入れ拒絶

精神的余裕のなさ

振り返り結果非公開

振り返り結果の取得未実施

11 個人スキル

12 個人スキル13 情報管理14 情報管理

売れなかった製品

9 企画力

支援活動の停滞

久しぶり開発8 機会

10 個人スキル

開発スキルが低い

組織成熟度が低い

6 開発体制7 開発体制他部門へ依頼する分析内容

5 開発体制△△A)KEEP/PROBLEMの網羅性の不十分さB)KEEP/PROBLEMの真因分析の不十分さI)改善意識不足（モチベーション）
C)情報伝達する仕組みが不確定
D)実行支援体制が不確定
E)スキル不足（業務改善）C)情報伝達する仕組みが不確定
E)スキル不足（プロセス）C)情報伝達する仕組みが不確定
E)スキル不足（プロセス）

次開発のプロジェクトマネージャが振り返り結果を知っているのも関 ①TRYに対する納得感の低さ
わらず，実践しない．
⑦個人的改善意識の低さ⑦個人的改善意識の低さ
プロジェクトマネージャが精神的に改善活動を行う余裕がなく，目先②個人/チームに依存したTRYの業務に邁進し，振り返り結果を実践しない．
の実践②個人/チームに依存したTRYの実践②個人/チームに依存したTRYの実践

前開発のメンバが振り返り会の情報を積極的に公開していない．

次開発のメンバが前開発の振り返り会の情報を積極的に取りに行っていない．

○○×E)スキル不足（スタッフ）④個人スキルの低さ

E)スキル不足（プロセス，品質）製品が売れなかったために，振り返り分析としても開発内容の分析ではなく，商品力の分析のみに特化している．そのために開発プロ ⑨開発改善が対象外の扱い
セスの改善には活かされていない．

PMOが次開発での改善活動を支援しているが，改善活動が滞る．

△

C)情報伝達する仕組みが不確定
D)実行支援体制が不確定
G)計画未立案

例えば5年ぶりのエンハンス（バージョンアップ）開発であり，前開発 ②個人/チームに依存したTRYで分析した当時とはツールや技術が変わっており，今回の開発に分 の実践③実行機会逸失
析内容を全て適用すべきか判断できない．

×

×

△

E)スキル不足（開発スキル，改善活動）

D)実行支援体制が不確定
E)スキル不足（プロセス，品質）

CMMI レベル１相当でプロセスが未確立となっており，組織的な品 ②個人/チームに依存したTRY
質改善活動が不十分
の実践

○

○

○

○

○

効果
判定

プロジェクトのメンバーに新人が多かったり，自律的な開発を行う意
識が低いメンバーが多かったりすることで，目先の作業に手いっぱ ④個人スキルの低さ
いで，振り返り結果の活用まで手が回らない．

A)KEEP/PROBLEMの網羅性の不十分さB)KEEP/PROBLEMの真因分析の不十分さ

C)情報伝達する仕組みが不確定
D)実行支援体制が不確定

開発部門の分析結果より，品証部門が実施すべき内容が発生したが，品証部門に納得してもらえなかった．そのために結果的に実施 ①納得感の低さ
されず工程内障害を再発してしまった．

振り返り分析をしているにも関わらず，開発体制が変わる際に分析
開発ごとに開発体制が解体，新規②個人/チームに依存したTRY
内容を引き継がれないために，次開発で開発プロセスが改善されなの実践構築される開発
い．

4 開発体制B)KEEP/PROBLEMの真因分析の不十分さ
C)情報伝達する仕組みが不確定

振り返り結果の理由が分からないので，前開発の協力会社に適用 ①TRYに対する納得感の低さしている品質保証プロセスが，今回の開発の協力会社にも適用で ②個人/チームに依存したTRYの実践きると判断できなかった．

協力会社の変更

3 開発体制A)KEEP/PROBLEMの網羅性の不十分さB)KEEP/PROBLEMの真因分析の不十分さ

開発リーダー，担当者の変更

開発リーダーや担当者が変更になった際に，改善されたプロセスを適用する必要性が分からず，単に肥大化したプロセスと考えてしま①TRYに対する納得感の低さ
う．そのために，開発計画書に記載しているにも関わらず，その内容を担当に実施するよう説明しない．

小項目B)KEEP/PROBLEMの真因分析の不十分さ

大項目

プロジェクトマネージャーが変更になった場合，なぜそのTRYを開発
プロセスに適用しないといけないかが分からず，TRYが未適用にな ①TRYに対する納得感の低さ
り開発プロセスが改善されない．

事例説明

2 開発体制

事例概要

プロジェクトマネージャーの変更

事例観点

1 開発体制No.

振り返り結果（TRY)が実践されない課題(理由）⇒大項目①と小項目A)B)，および大項目②と小項目C)D)
大項目①と小項目A)B)，および大項目②と小項目C)D)が大項目①と小項目A)B)，および大項目②と小項目C)D)
研究員4名全員の共通課題【付録9:振り返り結果（TRY)が実践されない事例・課題と，FOPA振り返りプロセス適用時の効果】

振り返り会で，次開発メンバ（経営管理層，PMO）を招集し，FOPA
TRY宣言により情報伝達が確実に行えるため，本課題は解決される．またFOPA振り返りプロセス導入により，E)についても補うことができる．

FOPA TRY宣言により情報伝達が確実に行えるため，本事例は解決される．またFOPA振り返りプロセス導入により，E)についても補うことができる．

FOPA振り返りプロセスを適用することで，支援体制が構築されるために，改善活動が実践可能．
【留意点】プロジェクトマネージャの精神的余裕を持たせる支援も必要．

FOPA振り返りプロセスを適用することで，納得感をつたえることができ，次開発に振り返り結果を引き継ぐが実践可能．
【留意点】プロジェクトマネージャの改善意識の醸成も必要．

FOPA振り返りプロセスを適用しても，PMOが開発プロジェクトをしっ
かり支援できなければ効果がない．PMOなどスタッフの教育が必要．

今回のFOPA振り返りプロセスは開発プロセスへの適用になるので，要件定義など一部関わる所はあるものの，基本的には対象外
である．

KEEP/PROBLEMを基にしたTRYを残しているために，判断をできる．
【留意点】前開発の分析時が5年前だと技術自体が失われている場
合（OSSの終了やツールの販売終了など）もあるので，その場合は直接適用できない．

振り返りの実践に余裕がない体制なので，FOPA振り返りプロセスを実践しても，効果が期待できない．開発体制を盤石に整えることが先決．

FOPA振り返りプロセスとして用意することで，組織的に展開が可能となる【留意点】プロセス，品質に関する教育を行う必要あり．

FOPA TRY宣言による明確な引継ぎ方法と，PDCAによる組織的な支援体制を構築しているため，振り返り結果が他部門へも適切に引き継がれる．

３W1Hで引き継ぐ内容が明確になり，分析内容のフォローア（実行支援者）も明確になるので，振り返り結果が次開発に適切に引き継がれる．

振り返り結果の理由が分かるので，今回の協力会社にも適用すべき内容，適用不要の内容を判断できる．

開発リーダーや担当者が前開発の分析内容を納得するために，前開発の振り返り結果（TRY)を積極的に取り入れることができる．

プロジェクトマネージャーが前開発の分析内容を納得するために，
前開発の振り返り結果（TRY)を積極的に取り入れることができる．

FOPA振り返りプロセス適用時の効果

－25－
－15－

○

○

×

○

B)KEEP/PROBLEMの真因分析の不十分さ
F)適用範囲不明確（誤り）A)KEEP/PROBLEMの網羅性の不十分さB)KEEP/PROBLEMの真因分析の不十分さ
E)スキル不足（業務改善）

D)実行支援体制が不確定
E)スキル不足（プロセス，品質）C)情報伝達する仕組みが不確定
D)実行支援体制が不確定
E)スキル不足（プロセス）C)情報伝達する仕組みが不確定
D)実行支援体制が不確定
C)情報伝達する仕組みが不確定
F)適用範囲不明確

前開発と次開発の開発特性が異なるにも関わらず，意味のない振①TRYに対する納得感の低さ
り返り結果を次開発にインプットしてしまった．

前開発のメンバが自分の視点で振り返りを行い，次開発で実施しや ①TRYに対する納得感の低さ
すいTRY（結果）を出していない．
③プロセススキルの弱さ

開発計画書に記載した開発プロセスを守っていないために，振り返④個人スキルの低さ
り分析の内容についても改善されていなかった．

振り返りプロセスが定義されていない．そのために振り返りが実施 ②個人/チームに依存したTRYされない，もしくは実施しても個人的改善に留まり情報が共有されて の実践⑧プロセススキルの低さ
ない．

②個人/チームに依存したTRY
振り返り会に必要なメンバが集まっていなかった．（次開発で実施すの実践べき担当者が不参加）

同一部署内の類似開発に適用できる内容であったが，その内容を②個人/チームに依存したTRY
適用すべきか不明確であったために適用せず，結果的に同じ工程の実践
内障害を発生させた．

24 振り返りの質 振り返り結果の適用範囲誤り

25 振り返りの質 振り返りの視点の狭さ

プロセスを遵守しない

振り返りプロセスが未定義

振り返りプロセスの弱さ

横展開の範囲の考慮不足

26 プロセス

27 プロセス

28 プロセス

29 横展開○○○A)振り返り観点網羅性が不十分
B)KEEP/PROBLEMの真因分析の不十分さ△I)改善意識不足（全体最適）⑥組織的改善意識の低さ

新しいことに挑戦しようとしない．
経営管理層，プロジェクトリーダが保守的，話しづらい．

前開発のQCD問題が十分分析しておらず，次開発にインプットして①TRYに対する納得感の低さ
も，納得性が得られず実施されない．

保守的体質

21 組織風土△C)情報伝達する仕組みが不確定
D)実行支援体制が不確定
E)スキル不足（業務改善）⑥組織的改善意識の低さ
縦割ベース（自チーム，自部門）中心に開発をしており，横断的な業②個人/チームに依存したTRY
務や他チーム，他部門との連携を行っていない．
の実践

23 振り返りの質 振り返り結果が不十分

縦割り体質

20 組織風土△D)実行支援体制が不確定I)改善意識不足（モチベーション）⑤個人的改善意識の低さ②個人/チームに依存したTRYの実践

メンバや組織のモチベーション（向上心）が低く，改善活動が怠る．

○

モチベーション

19 組織風土○D)実行支援体制が不確定
E)スキル不足（業務改善）

自分，あるいは自チームのみを考慮し，他チームへの展開の優先度を下げている．

C)情報伝達する仕組みが不確定
D)実行支援体制が不確定
E)スキル不足（品質，リスク管理）

個別最適（チームワーク欠如）

18 組織風土○C)情報伝達する仕組みが不確定
D)実行支援体制が不確定
F)適用範囲不明確②個人/チームに依存したTRYの実践⑥組織的改善意識の低さ②個人/チームに依存したTRYの実践⑤個人的改善意識の低さ

かなり過去の開発の振り返り結果が，次開発で活用されない．

ツールを変更した際に目的が同じにもかかわらず，ツールが変更さ②個人/チームに依存したTRYれたことにより，品質施策を適用する必要がないと誤認識してしまっの実践
た．

過去の資産活用不十分

17 情報管理×K)インフラ整備の不十分さ△

前開発の振り返り結果がどこにあるかわからないので，次開発で実⑥組織的改善意識の低さ
践できない．

小項目C)情報伝達する仕組みが不確定J)管理層との信頼関係が不足

大項目

効果
判定

②個人/チームに依存したTRY
経営管理層が振り返り内容を知らないので，新たな行動が実践しづの実践
らい．
⑥組織的改善意識の低さ

事例説明

22 ツールの変更 ツールの変更

振り返り結果の管理方法が未確立

16 情報管理

事例概要

経営管理層への情報非伝達

事例観点

15 情報管理No.

振り返り結果（TRY)が実践されない課題(理由）⇒大項目①と小項目A)B)，および大項目②と小項目C)D)
大項目①と小項目A)B)，および大項目②と小項目C)D)が大項目①と小項目A)B)，および大項目②と小項目C)D)
研究員4名全員の共通課題【付録9:振り返り結果（TRY)が実践されない事例・課題と，FOPA振り返りプロセス適用時の効果】

チーム内で閉じるべき内容か，組織横展開すべき内容かを判断できるために，適切に横展開される．

FOPA振り返りプロセスを適用することで，改善活動が実践可能．経営管理層，PMO，次開発の担当を招集し，FOPA TRY宣言するのが効果的．

振り返りを行っていなかった組織に，次開発に振り返り結果を引き継ぐことが可能．またFOPA振り返りプロセス導入により，E)についても補うことができる．

振り返りの問題ではなく，プロセスをなぜ遵守すべきかという基本的な内容を理解できていないプロジェクトであるので，FOPA振り返りプ
ロセスの適用以前の問題である．プロセス教育などの別手段が必要．

FOPA観点チェックシートとFOPA真因分析シート・なぜなぜ分析シー
トにより，次開発でも有効な振り返り結果を導出することができ，実践が進む．FOPA KPT宣言の内容を経営管理層やPMOなどがチェックすることで，自分の視点のみで振り返りを行っていないかを確認することができるため，E)についても補うことができる．

FOPA観点チェックシートとFOPA真因分析シート・なぜなぜ分析シー
トにより，納得感のある振り返り結果を導出することができ，実践につながる．
FOPA真因分析シート・なぜなぜ分析シートにより，意味のある振り返り結果を導出することができる．FOPA KPT宣言の内容を経営管理層やPMOなどがチェックすることで，真因分析で適用範囲の誤りがないかを確認することができるため，F)についても補うことができる．

ＴＲＹの理由（なぜツールが必要なのか，目的に沿うために改善すべき点が何であったのかが等）が明確なために，必要な事項を引き継ぐことができる．真因分析のプロセス化により，E)についても補うことができる．

FOPA振り返りプロセスの中で，FOPA KPT宣言を行うことで，経営管理層やPMOの支援を受けることができ，組織的に実施展開が可能となる．
【留意点】組織的改善意識向上のための教育を行う必要あり．

FOPA振り返りプロセスとしての仕組みが明確になっているため横断的な組織に対しても対応可能．
【留意点】全体最適を狙った改善意識向上のための教育を行う必要あり．

分析内容に関して納得性を持ったTRYを積極的に取り入れ，開発プ
ロセスが改善される．
【留意点】改善意識向上のための教育を行う必要あり．

FOPA振り返りプロセスには，横展開の仕組みがあるので，展開が可能になる．

プロセスではなく，構成管理方法の問題であるため，効果はない．
構成管理などインフラを整えた上で，FOPA振り返りプロセスを導入する．
FOPA振り返りプロセスのPDCAを回すことにより，過去の振り返り結果でStatus欄がCLOSE以外のものは次開発で実行することが明確になるため，本課題は解決される．

振り返り会で，次開発メンバ（経営管理層，PMO）を招集し，FOPA
TRY宣言により情報伝達が可能．
【留意点】経営管理層と開発メンバの信頼関係の確認が必要．

FOPA振り返りプロセス適用時の効果

－26－
－16－

大項目

○

C)情報伝達する仕組みが不確定
D)実行支援体制が不確定
H)優先度・重要度不明確

効果判定

FOPA振り返りプロセス適用時の効果

× FOPA振り返りプロセス適用対象外

FOPA振り返りプロセスで，C)D)を解決．加えてH)についても対応．
重要度を付けて分析深掘りする内容を決めるために，優先度が明確になる．

FOPA KPTシートで展開先を明確にするために，本問題を解消できる．
【留意点】その反映先が正しいかの検証をすることは，FOPA振り返
りプロセスでは明確に定義していないので，振り返り会で参加者に確認するなどの運用が必要．

凡例：〇 効果あり， △ 条件付き効果あり，△

D)実行支援体制が不確定
G)計画未立案

小項目

効果
判定

FOPA 振り返りプロセスにより、研究員4名全員の共通課題である，「大項目①と小項目A)B)，および大項目②と小項目，および大項目②と小項目C)D)」を解決した結果，31事例中26事例（※)に効果あり．
「大項目①と小項目，および大項目②と小項目」を我々が挙げた大半の事例でFOPA振り返りプロセスが効果的であることを確認した．
【※内訳】○（効果あり）： 17事例△（条件付き効果あり、留意点が存在．）： 9事例

優先度の未考慮

分析意欲があり，ＴＲＹを毎回50個程度挙げている．数が多すぎる②個人/チームに依存したTRY
ために，どの内容を実施すべきか次開発のプロジェクトの人が判断
の実践
できない．

事例説明

31 横展開事例概要

30 横展開事例観点

出荷前に既に先行して，次開発に組み込む機能の開発が始まって ②個人/チームに依存したTRY
並行開発が多く，反映先が不明確 いる．そのために，振り返り分析内容を次開発に反映するタイミング の実践③実行機会逸失を逃してしまった．

No.

振り返り結果（TRY)が実践されない課題(理由）⇒大項目①と小項目A)B)，および大項目②と小項目C)D)
大項目①と小項目A)B)，および大項目②と小項目C)D)が大項目①と小項目A)B)，および大項目②と小項目C)D)
研究員4名全員の共通課題【付録9:振り返り結果（TRY)が実践されない事例・課題と，FOPA振り返りプロセス適用時の効果】