仮説検証が必要な作業が発生した場合の対応手順についてまとめます。
ここでいう仮説検証が必要な作業とは、すぐに単一の確度の高い答えがでてこないようなバグ・トラブルなどです。
（トラブルって抽象的ですけど、まぁ色々です）
手順
- 確度の高い一つの答えがないと判断したら仮説メモを残すことを決める
- パターン・ランゲージのフォーマットで状況を整理する
| 名称：英 | 名称:日 | 内容 |
|---|---|---|
| Context | 状況 | どんな状況のときに起こる事象か |
| Problem | 問題 | どんな問題か。 Forces に比べると抽象的な内容 |
| Forces | 要因 | 問題が発生してしまう具体的な要因 |
| Solution | 解決 | どのように解決するか。 Actionsに 比べると抽象的な内容 |
| Actions | 行動 | 問題を解決するための具体的な行動 |
| Consequence | 結果 | 解決した結果起こること。 良い影響、悪い影響双方について考える |
- 状況、問題のみ記入する
- 別ファイルで仮説の一覧を作成する
- 仮説を確度が高いと考える順に並べる
- 1件1件の仮説に対して以下を実施する
- 作業記録用のメモを作成する
- 仮説の内容を記載する
- 調査しながら調査内容を記録する
- 調査の結果、仮説が正しかった場合は検証終了。誤っていた場合は次の仮説を検証
- 自分で考えうる仮説が全て誤りだった場合に他のメンバーに相談する、等外部の力を得る
- 仮説が正しかった場合は要因・解決・行動・結果を記載する
- 問題を解決して対応完了
- パターン・ランゲージにそってまとめた内容があとで役立ちそうなら情報共有ツールに登録
まとめ
各個人の作業記憶の強さによって、どの段階でこういったメモを残すると有効なのか変わってくると思います。
そんなのいちいち書き残すより全部頭のなかで解決しちゃったほうが早い、という人もいると思うので。
補足
- 最初から人に聞いたほうが早そうだと判断できるものについてはきく
- メモがあると誰かに相談しようと思った時に検証内容や検証済みの内容がまとまっているので説明しやすい
- メモを取りながら自分の頭の中も整理される
- メモを取るコストもある
