はじめに
業務で使われているシステムやアプリケーションについて、
次の質問に答えられるでしょうか。
- なぜこのツールを選んだのか
- なぜ他の選択肢ではなかったのか
- どんな前提や制約を考慮したのか
これらは、
導入時には分かっていたが、時間とともに失われやすい情報 です。
この回では
「なぜそれを選んだのか」を他人に説明できることの重要性
について整理します。
1. 結論：選定理由を説明できない仕組みは、必ず揉める
業務で問題になるのは、
「そのシステムが正しいか」ではありません。
問題になるのは、
なぜそれを使っているのか分からない
という状態です。
この状態では、
- 別のツールを使うべきでは？と言われる
- トラブル時に判断の根拠が示せない
- 改修・刷新の議論が感情論になる
結果として、 意思決定そのものが属人化 します。
2. システム選定は「過去の判断」によって成り立っている
どんな業務システムも、
導入時には必ず理由がありました。
- 予算の制約
- 人員・スキルの制約
- 導入までの期限
- 当時の業務要件
しかし時間が経つと、
- なぜその制約があったのか
- 今も有効なのか
- 前提が変わっていないか
が分からなくなります。
理由が失われると、選択が正当化できなくなります。
3. 「昔からこうしている」が危険
以前からこれを使っている
他に選択肢がなかった
では、
- 当時の選定理由が分からない
- 今も妥当か判断できない
- 改善すべきか決められない
結果として、変えられないが、納得もされない状態になります。
4. 説明できない選定は、責任を人に押し付ける
選定理由が残っていないと、
トラブル時に次の問いが発生します。
- 誰がこれを選んだのか
- なぜこの構成にしたのか
ここで説明できないと、
- 個人の判断ミスとして扱われる
- 当時の担当者が矢面に立つ
- 防げない責任追及が始まる
判断の記録がない＝人が守られない ということです。
また、説明できる人がすでにその場にいないという事態もしばしば発生します。
5. 説明できる選定とは「正解を示すこと」ではない
重要なのは、
「最善だった」と証明することではありません。
重要なのは、
- 当時、どんな選択肢があったか
- 何を重視し、何を捨てたか
- どんな制約の中で決めたか
を説明できることです。
これが示せれば、
- 判断は評価できる
- 見直しも建設的にできる
- 責任を個人に集中させずに済む
6. 選定理由として最低限残すべき情報
システムやアプリを選んだとき、
最低限、次の情報が人に伝わる形で残っているべきです。
- 目的（何を解決したかったか）
- 前提条件（予算・期限・人員・スキル）
- 比較対象（検討した他の選択肢）
- 採用理由（何を優先したか）
- 不採用理由（何を捨てたか）
これがあれば、
第三者でも判断を追体験できます。
7. マニュアルや設計書に書くべきなのは「背景」
多くの資料には、
- 操作手順
- 構成図
- 設定値
は書かれています。
しかし、本当に必要なのは、
なぜこの構成なのか
という 背景情報 です。
これが無い資料は、
引き継ぎや見直しの場面で不足が発生し得ます。
8. 結論
なぜそのシステム・アプリケーションを選んだのか、
今その理由を他人に説明できるか？
YESと言えないなら、
その仕組みは経年とともに危うくなる可能性があります。