『こんな時だからこそ状況を把握する ～SaPIDでふりかえる～』フィードバック編
この記事は，『こんな時だからこそ～』シリーズです*1
5/27(水)に，↑のエントリーを肴にワイワイする会が開催されました笑
出てきた質問やアドバイスを元に，フィードバックを残したいと思いました． ただし，個人的な考えでありますので参考程度にしていただけたらと思います．*2
フィードバック
STAGE1で問題構造を確定してから実施するか，問題構造が出来上がったタイミングでSTAGE2, STAGE3を実施するか？
個人的には，ある程度STAGE1で問題構造は確定してから，STAGE2, STAGE3に移りたいです．
ただし，今回作成した問題構造はリアルタイムで起きている出来事で，対策可能な事象は暗黙的にSTAGE2, STAGE3を実施していると思います． 例えば，以下のことが挙げられます．
引き継ぎ作業に時間が取られている件
今月中の作業で，無事引き継ぎが終わったので問題構造図からは消えます． 代わりに新しい何かが出てくる可能性があります．
仕様書の修正が必要になっている件
スケジュールが遅れている原因の一つが 『開発規約に基づいて作成された開発計画に沿って実施していない』ことだと仮説を立てたので，引き継ぎ作業が完了した後に「仕様書を修正する」「テストを着手する」を実施し始めました．
大事なことは，対策した時に問題構造図を更新する事だと思います．
更新し続けるうちに問題構造図が安定してくるはずなので，そのタイミングでSTAGE2, STAGE3を実施してもいいかなぁと思っています．
今回の方法を使えば，一発で納得できる問題構造を作れるようになるのか？
答えはNoですかねぇ．
問題構造を書くと，新しい考えが出てくることが多いです． 特に，今回は3ヶ月以上前のの出来事をふりかえっているため，忘れていることが多いです． なので，何度も作ってみては，足りないものがないか確認してみることは必要だと思っています．
今回試してみた事を実践すれば，大きく問題構造図を変えずに済みそう，が自分の予想です．
問題構造図の作成で一番辛いのは，問題構造図を一から作り変えることだと思います． 今回実践してみて，一から作り変える羽目になる理由が，グルーピングの仕方にありそうだと仮説しました． なので，初めはざっくりグルーピングすることで，問題構造の変更が少なくて済むんじゃないかと思っています*3
ふりかえりにKPTを使わずにSaPIDを使った理由
こんな理由になります．
- SaPID bootcamp以降使う場面がなかった
- 一度ちゃんと教本を使って作ってみたかった
- コロナ自粛で，自宅で考える期間ができた
- 自分の業務がテーマにぴったりだった
スクラムみたいに短期間でふりかえるならKPTでいいと思いました． ただ，同じようなProblemが出てくるときは，SaPIDやTOCfEのブランチを使うことになるだろうと思います．
安達さんからも，KPTで出た事象を元に問題構造図を作るとよい，という意見をいただきました．
問題構造を作るのに，嫌な事を突き詰めないといけないのか？
自分の場合，嫌な事はあんまり考えないようにしています．
どちらかというと，自分の行動に興味をもっている感じです． 多くは脊椎反射で行動していることが多いので，その行動の理由を知る(もしくは仮説を立てる)ようにしています．
重要な事は，問題を突き詰める事ではなく全体感を把握する事だと思います．
大体作り上げた問題構造図から「やっぱり，この問題は避けられないよねぇ・・・」って絞られた時に，嫌な事に対してようやく重い腰を上げる感じでしょうか．
ただし，チームでふりかえる場合は，行動の理由の聞き方に注意する必要があると思います．
自分の問題構造から対策型が出てこなかったことについて
今思えば，開発スケジュールを決めるのに『CCPMを使った』が対策型だったのかも・・・
に置き換えていたので，結果的に対策型が現れなかったのかも．
自分が考えた対策を，自分自身が一番信用していないのかもしれません笑
クリアしたい問題を最初に定めることについて
クリアしたい問題を最初に定めることは，問題でなかった時にリスクがあるかも
と意見をいただきました．
自分の場合は「問題につながらないのであれば，それは逆に安心できるので成功」と捉えているので，確証が得られるまで集中して考えるイメージです． 初めの段階で，何かしら確証に近いものを感じていることが，そのモチベーションになっているのかもしれません．
ただ，チームで実施した場合は，メンバーが考えている事が出てこなかったり，思い込みに気づかないことが多いので，クリアしたい問題につながらない可能性がありそうです． 個人で実施した場合も，自分の行動をふりかえることに慣れていないと，うまくいかない可能性があることに，この意見で気づくことができました．
今回の方法は，あくまで一手法ということに留めていただけたらと思います．
まずは，問題構造図にしなくても，KJ法やマインドマップを使ってグループ化するだけでも効果があると思います．
目標がモヤモヤすることについて
アウトカム（＝外に出せる価値）を考えるようにしましょう．
というわけで，こんな感じの目標にしてみました．
信頼できる開発チームであること
こういう目標に変えると，着目するべき事象が変わってきて，問題構造が変わりそうですね．*4
目標の立て方は，TOCfEのアンビシャス・ターゲット・ツリーを使って，戦略的に目標を達成するとよいかも，とも思いました．
最後に
今回初めて，自分が主体的になったイベントを開催することになったわけですが，多くの学びがありました．
(ルールに沿って開発していないのがばれるから)，自分の問題構造図を人に見せるのは恥ずかしい
『にわか』なので，自分より作るのがうまい人につっこまれるのが怖い
と思って，自信がなく，内心ドキドキしていましたが，みなさん優しくて安心しました． 逆に，質問をしていただいたり，アドバイスをいただけたりと，懇親会も含めて4時間も自分の問題構造図でワイワイできてお得な時間でした．
今回，企画してくださった安達さんと参加者の皆さんに感謝したいと思います．
また，個人的には，生々しい事例が出ていないという意外な事実を知ることができました． 当初は教本通りに実践してみる事が目的でしたが，最後までちゃんと使ってみようと思いました．*5
