エンジニアのジレンマ ~悩む立ち位置と仲間の境界~

第9回 価格は誰が決めるのか?

この記事を読むのに必要な時間:およそ 1.5 分

値段を決める難しさ

皆さんは,何か欲しいモノを購入する際に,予算を決めてから購入したいモノを検討されますか? それとも,欲しいモノのスペックを決めてから価格を検討されますか?

筆者はある程度欲しいモノを決めてから,値頃感が納得するまで待つ(安いと思うまで待つ)タイプですが,一般的には,ある程度の予算を決めてから購入したいモノを決めることが多いと思います。また,欲しいものがあったとしても予算オーバーであれば検討対象外でしょうし,予算内であっても購入価格にお得感を感じなければ,やはり購入には至らないでしょう。つまり,予算と値頃感は,モノを購入する際の一番大事なファクターなのです。

それでは,システムを導入する際の費用はどうでしょうか? 目に見えないシステムは値段を決めることが難しいものです。例えば,数社からとった見積りは前提条件が全く異なり10倍以上の価格差があったり,似たような内容でも価格差が出てきたりします。また,スペックを比べるのも容易ではありません。それだけに,他社がいくらの価格で見積りを出しているのかは,他業界に比べてビジネスに大きな影響を与えます。

今回は,システムの価格を決めることの難しさについて考えてみましょう。

値段の決め方

筆者が数年前にマンションを購入した際に,間取り変更の見積り依頼を行いました。その見積りは結構な額でしたが,その際に「管理費用一式」という記載が目に留まりました。そこで「管理費用一式って何ですか?」と営業担当者に聞いてみましたが,⁠分かりました。見積りを再提示します」と回答があり,値引き要請もしていないのに管理費用が極端に減ったのは,今でも覚えています。どうやらあまり根拠のない費用だったのでしょう(説明を求めただけで見積りが大幅に下がるのは,如何なものかと思いました)⁠

見積りに対する,根拠は明確にする必要があります。それではシステムの費用はどうやって決めているのでしょうか?

企業により方法は様々だと思いますが,多くの企業が期間と人数より総工数を計算し,それを元に人件費を掛け,利益を上乗せするやり方ではないでしょうか。もちろん,機能単位に積み上げて総工数を計算する会社やサービス,商品化して値段をあらかじめめつけてしまう方法もあります。

どのような方法を行っても,重要な点は「管理費用一式」と違い,エンジニアは「人」が商品という点です。エンジニア費用は,人件費そのものですから,簡単に値下げをすることができないのはいうまでもありません※1)⁠

※1
例えば,ソフトウェアパッケージは沢山販売すると安価でも利益は大幅に増えます。モノを売る際には,シェアを獲得することがとても重要です。一方,エンジニア費用は人件費そのものですから,大型受注を獲得しても,利益が比例して延びるとは限りません。

比較対象が異なる

筆者が数年前に提案活動に参加した案件は,パッケージ適用ではなく,お客様向けに個別開発を行うものでした。お客様が作成された提案依頼書は曖昧なものでしたが,筆者にとっては得意分野であったため,内容はよく理解できました。そのため,作成した提案書はお客様のことを十分に考え,かつ適正な値頃感と感じていました。

自信作である提案書を持って説明に行くと,競合他社は半額以下の見積りを出しているというのです。そのような価格では絶対に実現できないはずですが,お客様は価格を露骨に比較されます。

「提案内容に差があるとはいえ,この価格差は受け入れられない」⁠提案内容を落とさずに,せめて2割くらいの価格差にできないのか?」とお客様からいわれました。

「提案前提が異なります。他社と我々が見積りしている内容は対象範囲が異なっています。他社が見積対象外にしている機能がないと,業務としてなりたたないと思います」と訴えても,聞いてもらえませんでした。

競合他社は「小さく産んで,大きく育てましょう。どうしても必要な機能は後から追加すればよいでしょう」と伝えているようで,もっともな説明でしたが,筆者にはこれ以上の機能削減はどうしても考えられませんでした。

上手いシステム提案

このようなケースは実に多いと思います。お客様に最小機能で提案をおこなって追加で発生した要件を追加費用でいただくのか,最大機能で提案をおこない,お客様から不要という意見を聞いて費用を落としていくのか,非常に迷うところです。

いうまでもなく,最小機能で提案をおこなうほうが,最初の提案価格は安価になるため,営業上は有利です。しかし,エンジニアは,お客様のことを考えれば考えるほど,過剰スペックになりがちです。システムが使えないといわれるのが怖いからだと思います。

先の事例に戻りますが,結論は他社に受注を取られてしまいました。しかも,システム構築後に営業担当者が確認した結果は,後から追加費用が発生したが,お客様は「我が社が悪い,我が社が追加要望した」といい,納得している様子とのことでした。とても悔しく感じましたが,上手いシステム提案とプロジェクトマネージメントだと脱帽しました。

提案の極意

筆者はこの経験をつ通じて,思い込みに気づきました。条件によっては,必要最低限の機能のほうがシンプルな場合もあるということです。予算を重視するお客様にはなおさらでしょう。

重要なのは,すべてにおいてお客様が納得することです。そのための努力を惜しまないことがエンジニアには必要なのです。システム構築途中で追加費用をいただくことはとても大変なことですが,受注の極意とプロジェクト成功の鍵は,このあたりにポイントがありそうです※2)⁠筆者は現在もこの問題に継続して取り組んでいます。

営業担当者から「なんでこんなに工数が掛かるんだ」といつもいわれて,受注がとれないエンジニアの方もいるでしょう。また,追加費用をいただくことを是とされないエンジニアも多いかもしれません。お客様によっては,追加仕様を無償で依頼するケースも多いのも事実であり,お客様の文化に依存する部分も多いでしょう。⁠小さく産んで大きく育てる提案の極意」について,提案段階から研究することをお勧めします。

※2
多くの企業で,稟議書を作成し,システム構築開始時に予算を決めてしまいます。そのため,予算外で追加費用を捻出することはなかなか難しいものです。システム推進が上手なお客様は,若干の予備費を稟議段階から取られているようです。

著者プロフィール

森平也寸志(もりひらやすし)

システムエンジニア経験が18年。資格としては,PMP Project Management Professionalや情報処理技術者試験(システムアナリスト)などを保有。

これまで数十人のプロジェクトマネージャから少人数での中小向けシステムの導入等の経験がある。過去には自身が担当するプロジェクトで数億の赤字プロジェクトも経験済み。SEがシステムを構築する際には,常に失敗との背中合わせである事を痛感し,お客様との関係や自社の営業との関わり方を日々考えている。

コメント

コメントの記入