この記事で考えたいこと

前回の記事では、レビュー対話を、

論点探索
↓
共同検討
⇄
認識整合
↓
判断確定
↓
実行指示
↓
実行確認

という思考・判断の状態遷移として考えました。

前回の記事はこちら：

17. レビュー対話を状態遷移として考える〜問い・相談・判断・指示を進める条件と責任とは〜

では、そこで生まれた判断や思考は、その後どうなるのでしょうか。

レビュー記録に、

方式Aを採用する。
設計書へ判断理由を追記する。

と残っていたとします。

記録はあります。

しかし、後から似た判断を迫られた人が、

なぜ方式Aだったのか
方式Bは検討したのか
何を評価したのか
何が判断を動かしたのか
どのリスクを受容したのか

をたどれなければ、次の判断に使うことは難しいでしょう。

つまり、

記録が残っている
≠
判断に至る過程をたどれる

のではないでしょうか。

今回は、

過去の判断に至る流れを、後から意味のある形でたどれる状態にするには、何が失われてはいけないのか

を考えてみます。

1. 判断したあと、その思考はどこへ行くのか

ここまでの連載では、

違和感
↓
レビュー観点
↓
問い
↓
共同検討
↓
認識整合
↓
判断
↓
実行

という流れを考えてきました。

しかし、レビューが終われば、この流れは見えにくくなります。

成果物には最終結果が残ります。
議事録には決定事項が残るでしょう。
レビュー記録には指摘と対応結果が残るかもしれません。

それでも、

何を見て、何に迷い、どの情報によって検討が変わり、なぜその結論に至ったのか

までは残らないことがあります。

すると、同じ組織で似た問題が起きても、また一から考えることになります。

第2章では、良い思考をどのように組織知へ変えるかを考えました。

今回はそこへ戻り、

判断結果だけでなく、判断に至った思考をどう残すか

を考えます。

第7記事では組織知を文書だけではなく、複数人が理解し、教育や実践を通して文化として定着する段階まで含めて考えました。

今回はそのすべてを扱うのではなく、組織知として活用していくための基盤の一つとして、「過去の判断過程を後からたどれる状態」に焦点を絞ります。

2. 「残す」と「再利用可能にする」は同じではない

本記事では、次のような状態を「再利用可能」と考えます。

過去の結論だけでなく、前提、論点、選択肢、評価観点、転換点、判断理由、残った問題などの関係をたどり、判断過程を意味のある流れとして理解できる状態。

これは、当時の人と同じ思考や感覚を完全に再現することではありません。

暗黙知や感情、その場の空気、言葉にならなかった迷いまで、後からそのまま再現することはできないでしょう。

ここで目指しているのは、

当時何が見えていたのか
何が論点となったのか
何を比較したのか
何を重視したのか
何によって判断が変化したのか
なぜその結論に至ったのか

を、意味のある流れとしてたどれることです。

本記事では、この利用時のイメージを「追体験」と表現することがありますが、当時の思考の完全再現を意味するものではありません。

また、

再利用可能な状態であること

と、

実際に良い再利用ができること

も別です。

過去の判断過程をたどった人が、現在との違いに気づき、自分の判断へ適切に利用できるかは、その人の経験や知識、思考力にも影響されます。

今回は、まず判断過程を後からたどれる状態をどう作るかに範囲を絞ります。

3. 一つの意味のある判断を、ケースの単位にする

組織知というと、多くの事例やノウハウを蓄積することを想像しやすいかもしれません。

しかし、今回は件数よりも、

一つの意味のある判断を、その前後を含めて一つのケースとして残す

ことを考えます。

判断前の状況
↓
論点が生まれる
↓
選択肢を比較する
↓
新しい情報が入る
↓
判断が変化する
↓
最終判断
↓
実行・結果

一回の会議全体でも、プロジェクト全体でもありません。

一つの判断ストーリーとしてたどれる範囲を基本単位とします。

成功事例だけを残すわけではない

対象となるのは、成功した判断だけではありません。

結果的に失敗した判断
後から前提が崩れた判断
良い問いは出たが、実行へつなげられなかった事例
判断過程は危うかったが、結果的には成功した事例
途中で判断を修正した事例

にも、組織知として意味がある可能性があります。

つまり、

結果が成功したか

と、

良い問い・検討・判断ができていたか

は別の軸です。

結果だけを見て模範事例とすると、たまたま問題が顕在化しなかった進め方まで正解として残してしまうかもしれません。

そのため、本記事では「成功事例」ではなく、

意味のある判断事例

として捉えます。

4. 判断ストーリーをたどるために、何を失ってはいけないのか

必要な情報は、大きく三つに分けられそうです。

4.1 判断が始まった条件

前提・状況
どのような要求、制約、環境、開発段階だったのか。
論点
何が問題となり、何を判断する必要があったのか。

同じ「方式Aを採用」という判断でも、成立していた条件が違えば、その意味は変わります。

4.2 判断を作った材料

選択肢
何と何を比較したのか。
評価観点
性能、変更容易性、コスト、影響範囲、リスクなど、何を重視したのか。
判断を動かした情報
どの事実、制約、調査結果、指摘によって検討が変化したのか。

特に、判断を動かした情報は、ストーリーの転換点になります。

4.3 判断と、その後に残ったもの

判断と判断理由
最終的に何を決め、何を優先した結果、その結論になったのか。
残リスク・未確認事項
何が分からず、何を受容し、何が条件付きで残ったのか。
結果
当時の想定と、その後実際に起きたことに、どのような差があったのか。
結果は、判断時点にはまだ存在しない情報です。
そのため、判断ストーリーを残す際の情報というより、実行後にケースへ追加し、
当時の想定との差を振り返るための情報と考えます。

結果だけで判断の質を決めるべきではありません。

しかし、判断時の想定と実際の差は、次の判断にとって重要な情報です。

5. 「問い」はすべて残す必要があるのか

判断過程を残すなら、レビューで出た問いもすべて記録すべきなのでしょうか。

それは現実的ではありません。

例えば、

この表記は合っていますか？

という問いと、

方式Bを検討しなかった理由は何でしょうか？

という問いでは、判断への影響が異なります。

さらに、

この制約は、今も有効なのでしょうか？

という問いによって前提が崩れ、判断が変わったのであれば、その問いは重要です。

したがって、

すべての問い
≠
残すべき問い

と考えます。

残す価値が高いのは、

その問いを失うと、なぜ思考がその方向へ進んだのか説明できなくなる問い

ではないでしょうか。

問いそのものを大量に保存するのではなく、問いによって思考がどう動いたかを失わないことが重要です。

6. 方式A / Bの判断を、スライドショーのようにたどってみる

前回の記事で扱った方式A / Bの例を、一つの判断ケースとして見てみます。

Scene 1：当時の状況

性能要求を満たす方式を決める必要があった。

既存構成への影響は、できるだけ小さくしたい。

Scene 2：論点

方式Aと方式Bのどちらを採用するか。

当初は、主に性能を比較していた。

Scene 3：選択肢と評価

方式Aは性能面で有利だった。

方式Bは構造変更が少なく、変更容易性では有利だった。

Scene 4：判断を動かしたもの

レビューで、

将来変更するときの影響範囲は、どう違うのでしょうか？

という問いが出た。

これにより、変更容易性と保守コストが評価観点に加わった。

さらに、保守担当から新しい制約が提示された。

Scene 5：判断

最終的に方式Aを採用した。

性能要求を優先し、変更容易性に関するリスクを受容する判断とした。

Scene 6：残ったもの

保守コストには十分な実績がなく、不確実性が残った。

設計書へ、

採用理由
比較結果
影響範囲
残リスク

を追記した。

Scene 7：結果

その後、実際の変更時に、想定より影響範囲が大きいことが分かった。

このとき、

当時の判断は間違っていた

と結果だけで評価するのではなく、

当時どの情報が不足していたのか
どのリスク評価が甘かったのか
次回は何を確認すべきなのか

を考えることができます。

このように順を追えば、

なぜAを選び、当時何が分かっていて、何が分かっていなかったのか

を後からたどれます。

これが、今回イメージしている「スライドショー」の形です。

すべてを動画のように保存するのではなく、必要な場面で立ち止まりながら、判断に至る道筋を理解します。

7. ナレッジ件数より、再構成できるストーリーの質

組織知を仕組み化すると、

ナレッジが何件登録されているか

は分かりやすい指標になります。

しかし、1000件の記録があっても、

Aを採用
問題なし
対応済み

という結論しか残っていなければ、判断過程はほとんどたどれません。

逆に数件でも、

なぜ論点が生まれ、何を比較し、どこで検討が変わり、何が残ったのか

までたどれるなら、深く考える材料になります。

その意味では、

組織知の価値は、保存された件数だけではなく、そこからどれだけ意味のある判断ストーリーを再構成できるかにある

のかもしれません。

ただし、情報は少ないほどよいという意味でもありません。

必要なのは、

判断ストーリーを途切れさせない情報密度

です。

全部残しても、使えるとは限らない

会話、チャット、成果物、映像などをすべて保存すれば、情報の欠落は減ります。

しかし、

大量に保存する
↓
必要な情報を探せない
↓
判断の転換点が分からない
↓
使われない

こともあり得ます。

保存量と再利用可能性は別の問題です。

一次情報を保持するだけでなく、そこから判断ストーリーを再構成できるように、情報同士の関係が分かることが必要です。

8. 理論上必要な情報と、現場で残せる情報は違う

ここまで読んで、

こんなに記録しなければならないのか

と感じるかもしれません。

私自身も、これらをすべて追加作業として人に記録させるのは重いと思います。

レビュー後に、

前提を書いてください
選択肢を書いてください
評価観点を書いてください
判断理由を書いてください
残リスクを書いてください
……

と求めれば、記録自体が目的化する可能性があります。

その結果、

判断理由：総合的に判断
残リスク：特になし

という記録が増えれば、項目は埋まっていても判断ストーリーは残りません。

本記事で挙げた情報は、

すべてを人手で入力すべき記録項目

ではありません。

まず理論として、

判断に至る流れをたどるために、どの情報が失われると困るのか

を考えています。

実際の仕組みにするなら、

人が明示しなければならない情報
既存成果物から取得できる情報
レビュー記録から抽出できる情報
後から関係づけられる情報

に分ける必要があるでしょう。

これは、組織知を現場へ実装する際の別の問題として考えたいと思います。

9. まずは一つの判断過程をたどれるところまで

組織知の利用には、さらに先がありそうです。

まず、一つの判断過程をたどる。

その後には、

複数ケースを比較し、判断を分けた条件を考える
直接参考になる事例がなければ、複数の知識から参考ストーリーを構成する

といった利用も考えられます。

ただし、複数情報から構成した参考ストーリーは、実際に起きた過去事例とは明確に区別する必要があります。

今回は、そこまで進みません。

まずは、

レビュー・開発活動
↓
意味のある判断
↓
必要な情報と関係性を残す
↓
判断ストーリーとして再構成する
↓
後から判断過程をたどれる

という状態を考えます。

現時点で残る問い

今回考えたのは、理論上の「判断過程をたどれる状態」です。

まだ、次のような問いが残っています。

必要な情報を、現場負荷を増やさずどう取得するのか
人が明示すべき情報と、後から抽出できる情報をどう分けるのか
現在の状況に合う判断ストーリーを、どう選ぶのか
複数ケースを比較・構成することで、何が得られるのか

特に実運用では、

情報の完全性と記録負荷を、どこでバランスさせるか

が大きな問題になると思います。

おわりに：残すことより、もう一度たどれること

組織知化というと、文書化やナレッジ登録を想像しやすいと思います。

しかし、

方式Aを採用した

という結論だけが残っていても、その判断を次の人が理解できるとは限りません。

必要なのは、

当時何が問題となり、
何を比較し、
何によって判断が動き、
なぜその結論に至り、
何が残ったのか

を後からたどれることではないでしょうか。

これは、当時の人と同じ思考を完全に再現することではありません。

残された情報とその関係から、判断過程を意味のある流れとして理解することです。

成功した判断も、失敗した判断も、途中で変わった判断も、次の判断を考える材料になり得ます。

まずは一つの意味のある判断を、後からもう一度たどれるようにする。

そこから、組織知の使い方を考えていきたいと思います。

この連載の全体像はこちら：

車載ソフトウェア品質保証を考える：連載まとめ