「現場の論理」と「システムの論理」をどう仲介するか

システム開発のプロジェクトを進めていると、必ずといっていいほど「現場」と「開発チーム（あるいはシステムそのものの制約）」の間で意見が対立します。

現場は「今の仕事のやり方を変えたくない」「もっと自由に、柔軟に操作したい」と主張します。一方で、システム側は「データの整合性を保つためにルールを厳格にしたい」「例外処理を増やすとコストが跳ね上がる」と主張します。

この 「現場の論理」と「システムの論理」 の板挟みにあったとき、発注側のPMはどう振る舞うべきでしょうか。

なぜ両者は対立するのか？

まず、それぞれの言い分には正当な理由があることを理解する必要があります。

• 現場の論理： 「お客様を待たせられない」「現場は多忙で、入力に時間をかけられない」。これらはビジネスを回すための切実な声です。
• システムの論理： 「例外を認めるとデータが汚れる」「あやふやなルールではプログラムが組めない」。これらはシステムの品質と保守性を守るための正論です。

これらを「どちらかが正しくて、どちらかが間違っている」と考えてしまうと、プロジェクトは停滞します。

PMの役割は「翻訳者」と「裁定者」

発注側PMに求められるのは、両者の言い分を「翻訳」し、ビジネス上の「着地点」を見つけることです。

1. 「何のために」に立ち返る（翻訳）

現場が「この機能が使いにくい」と言ったとき、そのままベンダーに伝えるのではなく、「なぜ使いにくいのか？」「その操作で何を実現したいのか？」を深掘りします。 同様に、ベンダーが「その機能は実装困難です」と言ったとき、現場には「技術的に無理だそうです」と伝えるのではなく、「それを実現するにはこれだけのコストと期間がかかり、他への影響も大きいですが、それでも優先しますか？」と翻訳して伝えます。

2. 「手運用」という選択肢を持つ

すべての要望をシステム化しようとすると、コストは無限に膨らみ、システムは複雑怪奇になります。 「頻度が低い例外処理は、システム化せずにエクセルや手作業でカバーする」という判断も立派なPMの仕事です。システムの論理を優先してデータの綺麗さを保ちつつ、現場の論理には「手運用」という逃げ道を用意するのです。

3. 「将来の負債」を説明する

現場の要望を無理にシステムに押し込むと、将来的に改修が困難な「負債」になることがあります。PMは現場に対し、「今ここを柔軟にすると、後で集計ができなくなりますよ」と、将来のリスクを丁寧に説明し、納得してもらう必要があります。

「どちらも100点」はあり得ない

システム開発において、現場の満足度も100点、システムの美しさも100点、という結果はまず得られません。

大切なのは、 「ビジネスの目的を達成するために、どの程度の不便や制限なら許容できるか」 という合意を事前に取っておくことです。

現場の論理に寄り添いすぎず、システムの論理に屈しすぎない。その絶妙なバランスを保つ「仲介」こそが、プロジェクトを成功に導くPMの真骨頂なのです。