できない理由を説明するよりエンジニアがやらなければならないこと

システムはエンドユーザの業務をITで代替することで省力化とか生産性などを向上させることが目的で導入します。

つまり、最初に「実現したい業務の課題がある」のです。

ベンダは、エンドユーザの「実現したい業務課題」に対する解決策を提案し、それが採用されるとプロジェクトとを立ち上げ、業務課題をITで解決するためにシステム化要件を整理していくことになります。

そうした中で起きるのが当初提案していたシステム方式（ソリューション）で実現することが難しいという技術的な課題です。

実現できない理由を説明してもあまり意味はない

「なぜ」の説明は必要です。それは当初見積もりから変更になる可能性があるからです。プロジェクトオーナーはエンドユーザですから、エンドユーザのプロジェクトオーナのミッションとして提案されていた方式が変わるというイベントが発生した時点でプロジェクトのリスクを考える必要があるためです。

また、プロジェクトオーナとはいえ、経営者に説明しなければならないので当初提案の方式で「なぜ」実現できないかを理解していく必要がありますし。

でも、それは些細なことです。エンドユーザにとって実現したい業務課題が解決できればそれでいいのです。もちろん、コストや時間的な制約があるのは先にプロジェクトととして契約をしているからです。エンドユーザは、

「じゃあ、どうしたら業務課題が解決できるの」

とすでに関心が移っているからです。

エンジニアはエンドユーザのことを知らなすぎる

こうした事態に遭遇することは珍しくありません。というか、エンドユーザのシステム環境や業務環境をシステム要件を具体化していく中で判明する事実により、

「そうだったらこんな提案にならないのに」

ということの方が多いのです。エンジニアはエンドユーザのことについて何も知らないことを知るのがシステム化要件定義だったりします。

エンジニアがやらなければならないこと

当初のソリューションでエンドユーザの実現したい目的を解決できないと判明した時点で、エンジニアができない理由を説明しても意味はありません。

なぜなら、できない理由を説明してもエンドユーザの実現したい業務課題を解消できないからです。

今、エンジニアがしなければならないことは、代替案を提示することです。

代替案にたどり着くために必要なツール

代替案をサクッと持ち出せればそれに越したことはありません。代替案にたどり着くためには、エンドユーザのことをシステム的に解決するための

・制約条件
・前提条件

を整理し、当初提案のソリューションとのギャップを把握できていることが必要です。

それを把握できたらどうするか。

簡単です。会社に戻り、有識者を集めるのです。そしてやることはこの３つです。

・組織の中の技術サポート体制の確認
・組織の中の提供できるソリューションが存在するか有無の確認
・プロフェッショナルとの解決するためのアイデア出し

ここの場でもやはり、できない理由の説明は実現しようとしていたことの説明としては必要ですが、それはエンドユーザの実現したいことではないのでさっさと切り上げて、代替案を作り出す方に移る必要があることを忘れてはいけません。