ソフトウェア・シンポジウム2019 in 熊本

コンセプト＆ゴール指向のふりかえりの提案
小楠 聡美
株式会社 HBA
ogusuxs@hba.co.jp
要旨

図 1 ふりかえりの効果が感じられない要因

筆者は，過去に経験した開発現場でのふりかえりについて，「ふりかえりの効果が実感できない．」「ふりかえりをやる意味があるのか？」と思っていた．
そして，その原因として，複数の要因があると考えた．
そこで筆者は，上記の要因を解消して，より効果を実感できるふりかえりを実施できるような手段はないかと考え，実際のものづくりにおけるふりかえり手段として活用した．
本事例では，「ふりかえりの効果が実感できない」要因を解決できるようなふりかえりの手段と，実際のものづくりにおける改善実践例，およびその効果を報告する．

1. はじめに筆者が過去に経験した開発現場でのふりかえりは，以下のように進められることが多かった．

筆者の開発現場と同じように，目先の過程にしか着目していないふりかえりや，KPT などの様式に沿ってただ思ったことを羅列するふりかえりをしている組織も多いのではないだろうか．そのようなふりかえりは効果が薄く，問題がいつまでも解決しないままのチームになったり，最終的にふりかえりすることが目的になってしまったりするのではないかと筆者は考えている．
そのため，図 1 の以下の要因に着目し，それを改善することでもっと効果を実感できるようなふりかえりをできないかと考え，実践してみた．
・ どの問題に対する改善案なのか，つながりが見えない．
・ P が解決しないまま次のふりかえりから消えてしまう．
・ ものづくりの過程にしか着目せずにふりかえりを実施している．
・複数の改善案が挙げられた場合に，どれを採用したらよいかはっきりわからない．

・ KPT[1]の様式に沿って自由に意見を挙げている．
・ 前回のふりかえり終了後から，次のふりかえりの期間内の作業をふりかえった KPT を出している．
そのようなふりかえりを実施しながら開発プロセスを進めても，問題と思っていたことが解決されない，あるいは解決したと感じられなかった．そのため，「ふりかえりの効果が実感できない．」「ふりかえりをやる意味があるのか？」と感じていた．なぜそのように感じるのか，その要因は複数あり，以下の構造になっていると考えた（図 1）．

96

SEA

ソフトウェア・シンポジウム2019 in 熊本

T がどの G や B に割り付くものなのか一目でわかるので，「どの問題に対する改善案なのか，つながりが見えない」という要因が改善されるのではないかと思ったのと，一つの B と G に割り付く T がグループ化されるので，どの Tを実践するか選びやすくなり，「複数の改善案が挙げられた場合に，どれを採用したらよいかはっきりわからない」要因が改善されるのではないかと考えたためである．
KPT の項目ではなく、YGBT の各項目を使用したのは以下の理由による．

2. 解決手段と効果（提案内容）
2.1. 解決手段
効果の実感を促進するふりかえりとして，新規製品作成の際に，以下のルールを取り入れた MindMap を用いてふりかえりを実施しながら，何度か改善を試みた（図2）．

・KPT だけだと、どんな行動に対する K や P なのかが明確にならない場合がある．

＜ルール＞① やったこと（Y）に対して，その下層のブランチによかったこと（Good，以下 G とする）／うまくいかなかったこと（Bad，以下 B とする）を挙げ，さらにそれぞれにブランチをきって，次にやること（T）を列挙する．

・実業務をしていく上で，まったく同じ状況になることはほぼないため，「Keep」という意味でそのまま繰り返されることは少ないため，「Keep」という言葉に違和感を抱いており，「Good」の方が合っていると感じていたため．

② MindMap の中心に，完成イメージとコンセプト，そのイテレーションにおける目標を置く．

・「Keep」の代わりに「Good」を使うのであれば、その対語として「Problem」には「Bad」の方がよいと考えた．

③ ふりかえりの結果から出た「次にやること（T）」において，うまくいくか試験的に試した方がよい部分や，改善に時間がかかりそうな部分は切り出して，そこだけを深堀りしてうまくできるまでふりかえりながら実施する．うまくいったものは，本番にそのまま組み込み，必ず部分試作をすべて完了させてから次の代を作成するようにする．

ただし，「Keep」と「Good」，「Problem」と「Bad」の用途に差はないと考える．
また，ルール②により，製品がコンセプトに合っているかとういう視点でふりかえりをすることができ，「ものづくりの過程にしか着目せずにふりかえりを実施している」の要因が改善できるのではないかと考えた．
そしてルール③により，解決が難しい B に対する T の部分的な試作を取り入れることで，問題が解決できる見通しが立たない B を残したまま次の本番製作に着手することがなくなり，「P が解決しないまま次のふりかえりから消えてしまう」ことを防ぎ，実施されないまま忘れられてしまう T がなくなるのではないかと考えた．

図 2. ふりかえり様式イメージ

2.2. 今回の成果物について今回の解決手段の効果確認として，システム開発ではなく，レザークラフトによるスマートフォンケースの製作で実施した．その理由は以下の通りである．
＜スマートフォンケースの製作で効果確認した理由＞① スマートフォンケース製作において，市販の型などは参考にせず，設計から筆者自身でやろうと考えていた．
② 筆者はレザークラフト初挑戦で，最初から完璧に作れるとは思っておらず，作ってうまくできないとこ

MindMap にルール①を適用することで，挙げられた

97

SEA

ソフトウェア・シンポジウム2019 in 熊本

ろを改善しつつ，何度か作成してみようと思っていた．このプロセスが，ソフトウェアの新規開発→保守・改修のプロセスに似ていると考えたため．にやってみる．

改善する．

段階的に改善を進めて製作するにあたり，3 代目で完成させるというゴールを定め，各製作が終わる都度，中央にコンセプトと各ゴールを置いた MindMap のフォーマットを用意し，やったこと（Y）を挙げ，それに対するよかったこと（G）とうまくいかなかったこと（B），および，それらに割り付く，次にやること（T）を挙げた（図 3）．

③ ソフトウェアの設計やコーディングにも，レザークラフト製作にもセンスが必要である．そのセンスによって成果物の出来栄えが変わるという点においても，ソフトウェア開発と類似している．
以上のことから，スマートフォンケースの製作の過程に今回のふりかえりを取り入れて実践した．
なお，今回のスマートフォンケース製作のコンセプトは以下の通りである．

図 3．MindMap によるふりかえりの例「インコに噛まれてももう泣かない」
上記の理由は，筆者はスマートフォンケースを新しく買うたびに，短期間でインコにボロボロにされていた．そのたびに買い替えていたのだが，コストがかかる上に機種が古くなってきたので，なかなか自分が気に入ったデザインのケースが見つからなくなってきた．そのため，安いコストで自分好みのケースを自分で作りたいと思ったからである．
以上の理由から上記コンセプトが生まれ，以下の方針が導出された．
・コストは安く抑える．
・自分好みのデザインにする．
（絵柄，デザイン，色，重さなど）

拡大

ただし，中央にコンセプトやゴールを入れない場合と入れてふりかえりを実施した場合の効果の違いを確認するために，1 代目のふりかえりの際は，まず中央にコンセプトなどは置かずにふりかえりを行い，その後コンセプトとゴールを置いてふりかえりを再度実施し，両者の違いを確認した．

2.3. 手段実施の流れ
上記でも述べたように，筆者にとって今回レザークラフ
ト，およびスマートフォンケースの製作はいずれも初めての試みである．ふりかえりを実施して改善しながら 1 代から 3 代目まで，以下のコンセプトと各代ケース作成のゴールを立てて 3 つのスマートフォンケースを作成した．

ふりかえりを行って次代のケース製作を実施する前に，部分的に試作をしてみた方がよいと判断した B-T については，MindMap の該当項目を新規 MindMap に抜き出して，完了するまで試作とふりかえりを同 MindMap 上で繰り返した（図 4）．完了したパーツを組み込み．次代のケースを作成した

表 1．コンセプトと各代製作のゴール
コンセプト

インコに噛まれてももう泣かない-安く自分好みのケースを作るゴール
1 代⽬

2 代⽬

3 代⽬

ま ず，本当にでき1 代目のうまくいか売れるクォリティでそうか 1 回思うようなかったところを仕上げる．

98SEA

ソフトウェア・シンポジウム2019 in 熊本

図 4．試作部分のふりかえりの例②G の件数と B の件数が比較しやすい構造化されているのと G と B の色分けにより，1 件の Yに対する G と B の件数の比較，およびそれらに割り付くT の件数の比較し易くなった．
拡大例）Y に割り付く G と B の件数例

こうして，製作→ふりかえり→試作→ふりかえり・・・を繰り返し，3 代のスマートフォンケースを製作した．

3. 結果
今回の試みの結果，この手段の各ポイントとなる点について，以下のことがわかった．

③手戻りの抑止となった

3.1. MindMap 形式にルール①を取り入れたふりかえり
既存のフレームや，表形式などではなく MindMap を使って Y-G-T／Y-B-T を導出したところ，以下のことがわかった．

1 件ごとの T に自由にメモやさらなる検討事項を追加して残すことができるのとその見やすさから，部分試作が必要な問題と部分試作不要な問題の切り分けが容易になった．これにより，手戻りすることが少なく製作を進めることができた．

①全体の俯瞰のしやすさが向上した例）部分試作を試みたふりかえり項目
この T の施策は，うまくいかなかった場合手戻りが大きいので，部分的に試作をして進める判断をして進めた．

構造化されているため，全体を俯瞰しやすく，Y-G-T やY-B-T のつながりといった各要素のつながりがわかりやすかった．また，T が割り付いていない B がすぐに発見できた．
例）MindMap を用いたふりかえり項目の一部

99

SEA

ソフトウェア・シンポジウム2019 in 熊本④文字と図を同時に扱いにくい⑥コンセプトに合った施策案を導出できた
図を挿入して説明したい箇所があったが，思うようなレイアウトにできなかった．また，画像を挿入したファイルを別のコンピューターで表示すると表示できないことがあった．

1 件の G や B において複数の T 案が出た場合に，コンセプトに立ち戻ってどの T 案がふさわしいかを検討できた．

例）MindMap ツールへの画像取り込み例）レザーの端処理の改善案検討

挿入前

挿入後インコがレザーの端を噛むことが想定できる．

実際にどう変わったかを画像で残しておきたかったのだが，挿入すると文字が消えてしまった．

インコが噛まないのであれば下案のほうが適切だが、コンセプトから噛むことが想定でき，薬品はインコに有害な成分が含まれる可能性があるた
め，上案のほうが望ましいと判断できた．

3.2. MindMap にルール②を取り入れたふりかえり
MindMap の中央に，「コンセプト」「完成イメージ」「イテレーションの目標」を置いてふりかえりを行った結果として，以下のことがわかった．
⑤異なる視点のふりかえり項目を導出できた
中央にコンセプトとイテレーションの目標を置いてふりかえりをした際，置かずにふりかえりを実施した場合とは異なる視点のふりかえりが出た．
例）1 代目ケースのふりかえりの Y 導出結果
コンセプト配置前

コンセプト配置後

・自分で設計した・自分で設計した・革の端を，書籍を見ながら処理した・革の端を，書籍を見ながら処理した・革を手縫いで縫い合わせた・革を手縫いで縫い合わせた・電気ペンを使って絵を描いてニスを塗った・電気ペンを使って絵を描いてニスを塗った・革 ， 布 ，レザークラフトのツール以外は 100 均で揃えたコンセプトに合った製品にするために何をしたかという視点のふりかえり項目が挙がった．

100SEA

ソフトウェア・シンポジウム2019 in 熊本

3.3. ルール③を取り入れた MindMap によるふりかえり⑨施策選択の経緯や実施の過程が見えた

試作部分について，新規 MindMap に抜き出して完了するまで，試作とふりかえりを同 MindMap 上で繰り返して改善を行った結果から，以下のことがわかった．

複数の T の候補からその施策を選んだ経緯や注意点などのメモを，MindMap では容易に枝を追加して記載できた．こうすることで，完了後にその MindMap を見直すと，なぜその手段を選択したのか，どのような経緯で現在の状態に至るのかを枝を辿って読み取ることができた．

⑦改善必要と判断した B はすべて改善できた例）柄プリント部分試作における MindMap

今回 3 代目までのスマートフォンケースの作成とふりかえりを実施中に，その間で改善しようと判断した B で改善できないままとなったものは 1 件もなかった．つまり，改善必要なすべての B において T は完了するまで実施された．
例）部分試作の MindMap

拡大MindMap ツールを使用すると枝の追加が容易なので，該当箇所に置けるメモや注意点などを残すことができる．

4. 考察

すべての T について「完了」となるか，次の見通しを立てるところまで進めることができた．

今回の結果から，中心に製品のコンセプトとそのイテレーションの目的を置いた MindMap 形式のふりかえりを実施した結果をまとめると以下の通りである．

⑧次代の目標が部分試作の完了基準となった
部分試作でどの程度まで改善できたら「完了」とするか，次代のゴールから判断することができた．例えば、3 代目のゴールは「売れるクォリティにする」なので，市販されている類似製品と同等の品質になるまで改善する必要があると判断し，試みた．
例）ケース留め具の型（角丸）にうまく革を貼り付ける部分
試作を繰り返した結果（上：改善後，下：改善前）．

3 代目に組み込むパーツなので，市販品と同じように滑らかな弧になるまで改善を試みた．

＜結果＞①全体の俯瞰のしやすさが向上した．
②G の件数と B の件数が比較しやすい．
③手戻りの抑止となった．
④文字と図を同時に扱いにくい．
⑤異なる視点のふりかえり項目を導出できた．
⑥最適な施策案を導出できた．
⑦改善必要と判断した B はすべて改善できた．
⑧次代の目標が部分試作の完了基準となった．
⑨施策選択の経緯や実施の過程が見えた．
①の結果から，挙げられた T がどの G や B に割り付くものなのか一目でわかるので，冒頭で述べた「どの問題に対する改善案なのか，つながりが見えない」という要因は発生しなくなると考えられる．また，一つの B や G に対する T が同列に列挙される形となるので，どの T を実施するか選びやすくなる．このように，ふりかえり結果が構造体として表現するため，本ふりかえりの様式は，結果が101

SEAソフトウェア・シンポジウム2019 in 熊本

見やすく，現状把握が容易になる様式であると言える．
また，解決したものについては「完了」の識別メモを付けるようにしたが，これによりメモが書かれていないものは解決していないままとなっている B やまだ完了していない Tと判断できる．構造化されて全体が俯瞰しやすいので，このような何も解決していない B や，完了していない T を見つけやすい．つまり，改善項目を漏れることなく実施しやすいと言える．
②の結果から，G の件数が B の件数よりも多いほど，メンバーの今回の結果に対する満足度が高い状態であり，それが構造化により俯瞰しやすくなっているため，その状況を，ふりかえり結果を見てすぐに読み取れるということがわかる．つまり，このふりかえり結果がプロジェクトの状況を測る一つのメトリクスとなりうる．
また，後述の⑤の結果より，プロジェクトの過程だけではなく製品の品質にも着目したふりかえりができるため，このふりかえりでプロジェクトの状況と製品の品質の両方を見ることができる．
③の手戻りが少なく製造を進めることができた結果からは，このふりかえりを実施しつつものづくりを行うことで，効率的に開発・製造を進められることがわかる．
④の結果は，チームメンバーでふりかえり結果を共有しにくい要因となるため，今後の課題であると考えている．
⑤の結果から，製品がコンセプトどおり作られているかどうかという視点のふりかえりができたと判断でき，本ふりかえり手法により，製品ユーザーに受け入れられるかという視点，つまり，製品の品質に着目したふりかえりもできるようになったと言える．これにより，冒頭で挙げた「ものづくりの過程にしか着目せずにふりかえりを実施している」という問題は解決できる．
⑥の結果からは，本ふりかえりにより，ユーザーの立場に立った最善の改善策を選択できると言える．つまり，本ふりかえりにより，「複数の改善案が挙げられた場合に、どれを採用したらよいかはっきりわからない」問題を解消し，ユーザー目線の開発・ものづくりができるようになる．
①の俯瞰しやすさ向上の結果が，この選択をより行いやすくしてくれる．

⑧では，段階的に目標を置いたが，それが今回の改善の完了基準になった．ソフトウェアの開発，およびプロセスの改善や品質の改善を試みると，「どこまでやればいいのか」という話がよく挙がるが，この結果から，本手法を取り入れた開発・改善を実施すると，このゴールが，「どこまでやるか」の指標となると言える．例えば，ソフトウェアのテストにおいても「どこまでテストすればいいのかわからない」と思うことがよくある．その際にこの目標が，どの程度詳細なテストをするのがよいかの指標になってくれる．
これも無駄な作業をしない，品質が悪いまま次に進まないための手段となる．
⑨の結果では，MindMap の途中に残すメモが，なぜ現状このような結果になっているのかの経緯を示してくれることがわかったが，このような途中経過を残すことで，よく開発現場で聞く「前任者が不在でどうしてこうなったのか誰もわからない．」といった事態も避けることができるのではないだろうか．つまり，チームで開発状況を共有するにも役立つ手法であるともと言える．
また，今回の結果から，この判断の根拠や途中経過を見ながらふりかえりを実施し，その内容を残すことは，チームメンバーの教育にもつながるであろうと感じた．例えば，熟練者が製作･実装を行った場合，初心者がそのふりかえり結果を見ると，熟練者がどう考えてこの結果になったのか道筋が明確に見えるためである．
さらに，教える立場（熟練者）側にとってもメリットがあると感じた．なぜならば，前述で「ソフトウェア設計，コーディング，レザークラフトにおいてセンスが必要」と述べたが，センスを持つ人は時に直感で自分の考えが当たり前として設計や製作等を進めてしまい，なかなかその理由を説明できないことがある．そういった場合にもこのふりかえりの過程を辿り，自分がどうしてそのように考えたのかを相手に伝えることができるようになると考えている．

5. まとめ⑦の結果では，長引きそうな T については抜き出して完了するまで実践とふりかえりを繰り返すことになるので，完了する前に新しいふりかえり結果が導出されても，実施されないまま見なくなってしまうことはなくなる．これにより，冒頭で述べた「P が解決しないまま次のふりかえりから消えてしまう」ことを防ぐことができる．

102

今回の結果から，中心に製品のコンセプトとそのイテレーションのゴールを置いた MindMap 形式のふりかえりを実施することで，ものづくりにおいて，冒頭で述べた以下の問題に有効であることがわかった．
● どの問題に対する改善案なのか，つながりが見えな
い．
・ 構造化して表現するので，各要素のつながりが見SEA

ソフトウェア・シンポジウム2019 in 熊本

えるのと，全体が俯瞰しやすい．
● P が解決しないまま次のふりかえりから消えてしまう・ すぐに解決が難しそうな T については，抜き出して完了するまで実践とふりかえりを繰り返すので，完了するまで続けることができる．
● ものづくりの過程にしか着目せずにふりかえりを実施している．
・ ものづくりの過程だけではなく，製品がコンセプトに合っているかという視点のふりかえりができる．
● 複数の改善案が挙げられた場合に，どれを採用したらよいかはっきりわからない・ 複数の改善案が挙がった場合，中央のコンセプトに着目し，ユーザー目線の改善策を選択できる．
上記に加えて，以下のこともわかった．
◎ プロジェクトや製品の品質の状態を表すメトリクスとして活用できる．
・G と B の件数を比較することで，プロジェクトや製品の品質における現状を探ることができる．
◎ チームで開発状況を共有するにも役立つ手法になる．
・ 前任者不在でも，開発の経緯がわかる．
◎ 初心者スキルアップの教育としても活用できる．
・熟練者の開発経緯を見ることで，どう考えて作ればよいのかの思考を探ることができる．
・ 教育指導の際にうまく表現できない場合にもこれを見ながら説明することができる．
今後は他のツールを含め，図の扱いを容易にする手段や他者と共有しやすくするための手段の検討，またはより図も扱いやすいツールがないか検討すると共に，この手法をシステム開発の現場に適用し,より大きなプロジェクトの現場で活用できるか探っていきたい．

参考文献[1] プロジェクトファシリテーション 実践編 ふりかえりガイド
http://objectclub.jp/download/files/pf/Retrospective
MeetingGuide.pdf，

103SEA