「成功の定義」を誰も求めなかった——投資が通ってしまう会議の構造

ある会議で、ツールの導入が決まった。機能の説明があり、コストの話があり、スケジュールの確認があった。しかしその場で「これが達成されれば成功と判断する」という問いは、誰も口にしなかった。

半年後、そのツールはほとんど使われていない。

この結末は、偶然でも担当者の怠慢でもない。組織の中に、成功を定義しないまま投資が承認されやすい構造が存在する。

「成功」を定義しないまま進む、3つの思考パターン

整理しておきたいのは、成功の定義を欠いたまま始まるプロジェクトが、「ノリ」や「勢い」だけで動いているわけではないという点だ。一定の論理と手続きを経た上で、それでも成功の輪郭が抜け落ちていく。代表的なパターンが3つある。

1. 「導入できれば成功」という暗黙の合意　ツールの選定に時間と労力をかけるほど、「導入」そのものが目標にすり替わりやすい。検討中は「このツールで何が変わるか」を語るが、承認を得た後は「予定通り動かすこと」に集中する。測定すべき変化は問われないまま、プロジェクトは進行する。

1. 「使えばわかるはず」という期待の先送り　新しいツールへの期待は往々にして具体性を欠く。「現場が使い始めれば、効果は自然と見えてくるだろう」という楽観が、成功指標の設定を後回しにする。使い始めた後に「何と比べて効果があるか」を測る基準がなければ、評価のしようがない。

1. 「問うと反対しているように見える」という場の空気　承認会議において、「これで何が改善されたと判断するのか」という問いは、プロジェクトへの疑義として受け取られやすい。推進者を萎縮させたくない、議論を長引かせたくない——そうした配慮が、本来最初に決めるべきことを会議室から追い出す。

なぜその問いが会議室で立たないのか

根本には、提案の形式にある。稟議や提案書の多くは「何をするか」を説明するよう設計されている。導入するシステムの機能、ベンダーの実績、コストの根拠——これらは書きやすく、承認者も確認しやすい。

一方、「何をもって成功と呼ぶか」を具体的に書こうとすると、現状の把握と未来の想定が必要になる。業務がどう変わるか、どの数値がどれだけ動くか、いつまでに効果を確認するか。その作業コストが高いため、意識的に避けるのではなく、様式として求められていないから書かれない。

「担当者は後で決める」が通ってしまう理由で触れたように、後回しにされた問いは多くの場合そのままになる。成功の定義も同様だ。提案の段階で求められなければ、誰も自発的には書かない。

「便利そう」で選んだツールが半年で眠るで指摘したように、選定の段階での問いの立て方がその後のツールの命運を左右する。しかし問いを立てる「場」が設けられていなければ、誰も立てない。

承認の前に「成功の定義」を組み込む

防ぐ方法は、個人の意識改革ではなく、プロセスへの組み込みだ。

提案書に成功の定義欄を設ける　「導入後○ヶ月で何が変わっていれば成功か」を、提案書の必須項目にする。記載がなければ承認しないというルールを置くだけで、提案者は必ず考えることになる。

「どう測るか」を承認の条件にする　成功の定義だけでなく、測定の方法と確認のタイミングも一緒に提出させる。「効率が上がれば成功」ではなく、「○○の処理時間が、○ヶ月後に○%短縮していれば成功」という形が求められる。

成功の評価者を事前に決める　ツールを使う人と、効果を評価する人を分けておく。導入担当者は「動いている」ことを成功と捉えがちだ。業務成果に責任を持つ別の評価者を置くことで、測定が形骸化しにくくなる。

問うべき問いを、承認書類の中に最初から埋め込む。それだけで、組織の多くの意思決定は変わる。

ツールが「眠る」原因を導入後に探しても、手遅れになりやすい。出発点での問い——「これが達成されなければ失敗だ」——を誰もが言える状態を作ること。それが、使われ続けるツールの条件だ。