プロジェクトマネージャになって、ユーザー企業の偉い方とも対等に交渉する立場になると、システム化要件に対して、積極的な提案ができると好印象を与えることができます。BPR（ビジネスプロセス・リエンジニアリング）とかDX（デジタルトランスフォーメーション）の視点での提案ですね。
ただし、こちらの思いを一方的に伝えるだけでは駄目で、相手の役割・立場・言い分をよく理解してコミュニケーションをとらないと、折角よい提案をしても空振りに終わることも少なくありません。
どのようなユーザー企業も、以下のような役割を担う方がおり、各担当者が置かれた状況を理解した上で、関係者全員に高い満足度を与えられるシステム提案を心掛けましょう。
システム開発で関わるユーザー企業の方々
経営者・役員
経営者・役員は企業のトップで、Webや新聞などでIT関連のデジタル化戦略の他社動向を確認しています。IT・デジタル技術を経営戦略に組み込み、CS向上・事務効率化・コスト削減などを図りたいと考えています。自社の特徴を押さえた上で、営業手段や社内事務に対して、ドラスティックで現実的な提案をあなたに対して期待しています。
予算管理者
予算管理者は企画や経理関連の仕事をし、会社・各部署の投資・経費の予算を管理する方々です。コスト意識が強く、システム開発を「投資の一行動」と捉え、定量・定性効果やコスト回収期間などの目線で、システム投資をチェックします。
例えば、システム開発を行なうことで毎月100時間の事務削減の効果が出るとします。1年で1200時間、5年間で6000時間ですね。この5年間の人件費に3000万円かかると仮定します。あなたが、システム開発に4000万円かかる提案をしたら、5年かかっても4000万円と3000万円の差額1000万円分が回収できないので、予算管理者は、あなたの提案を却下します。
自社利用目的のソフトウェアの耐用年数は5年償却ですので、上記例では、5年を基準にして試算しましたが、当然、投資効果は高い方がよく、またリリース後の保守費用がかからないこともあり得ないので、現実の契約金額交渉はもっとシビアなものになります。いくらであれば、予算管理者を提案を受け入れてくれるのかボーダーラインを押さえることが重要です。一般的には、利用者が多くなればなるほど投資効果は大きくなる傾向があるので、より大きな金額の開発でも採算ラインに乗る可能性は高いです。
ユーザー部署の取り纏めの方
対象システムの利用者が複数部署にまたがるケースなどで意見集約を担う方です。要件定義工程の中心人物となりますが、実際には、要件の細かい部分は押さえ切れておらず、話を鵜吞みにすると痛い目にあうことも多いです。エンドユーザーからもよく話を聞いて、ユーザー要件に整合性が取れているかよく確認しましょう。
（開発側ではどうすることもできないのですが、）システム開発を円滑に進める上で、この取り纏め者の存在は最も重要です。取り纏め者の力量が不足していると感じた場合は、経営者など上位の職層の方に担当者増員・交代を働きかけるなどの対策を取りましょう。それが難しい場合は、とにかくやり取りを記録化し、後で要件相違などで揉めるケースに備えましょう。
エンドユーザー
エンドユーザーは実際のシステム利用者です。システム開発では、現行事務フローの確認と、現状の課題・要望のヒアリングを最初に行ないますが、エンドユーザーの言うことが必ずしも正解(Tobeモデル)とは限りません。１～３の方の見解を交えて、Tobeモデルを検討していくことが大切です。
自分の仕事に自負があるため、細部のユーザー要件まで拘る方が多いのも特徴です。一方で、エンドユーザーの要件を全て取り込むと要件が肥大化し予算オーバーする傾向があるので、ユーザー要件に優先度をつけて開発範囲を絞り込むことも大事です。実際には、優先度の低いユーザー要件をシステム化してもあまりその機能が使われないことが多いです。
まとめ
大前提として、ユーザー企業の方々は、特に事業規模の小さい会社であるほど、ITに知見のある方はほとんどいません。システム化範囲、開発内容や受注金額に対して、これ以上ないくらい丁寧に説明することを心掛けましょう。自分は伝えたつもりでも、相手には理解されていなかったことでトラブルになるケースも多いです。表現を換えて繰り返し確認する、書面で確認し記録化する、議事録を取る、といった基本行動を意識しましょう。
こちらもよければ一読ください。
