ベンダーの言い分

ベンダーの言い分


先日、10年来付き合いのあるベンダー企業の営業部長を訪問した時の話しです。

打合せ中、携帯電話に頻繁に連絡が入り、その都度打合せは中断。

普段は打ち合わせを中断する事がない方なのですが、相当切羽詰った急用と察し、やっと落ち着いたところで尋ねてみました。

すると、
最近システム開発でのトラブルが頻発し、顧客からのクレーム処理に追われてしまっている 
と嘆いていました。

その営業部長が言うには、
トラブルの大半が開発段階における設計段階への後戻り

で、それが原因で
納期へかなり影響が出るほどのスケジュール遅れ
となってしまっているとの事。



納期が遅れればその間売上を計上できず、当然ながら入金も遅れてしまうので、営業としては一大事。

何とかしようと策を講ずるも、社内調整(主に開発部門との調整)が進まず、ほとほと困り果てた様子でした。

そこで出た一言。


『ユーザには言えないけど、ユーザ側が要件をハッキリとさせないことに端を発している事が多く、ユーザの責任による部分が多いんだよね。』

この営業部長のみならず、大半のベンダーでこの様な思いを抱いているのではないでしょうか。

確かに一理あります。

と言うより、『確かにそうだ』 と判断できる場合が結構あると思います。

提案依頼書(RFP)があれば、ユーザのシステム化要件も明確になっているでしょう。

しかし、提案依頼書(RFP)も部分的には行間を読まなければならず、そこに書いてある事が全てではない、という事が多いのです。


業務要件/機能要件をシッカリと引き出し、要件調整をすることができなかったベンダーに責任はないのでしょうか。

また、コミュニケーション不足等によりユーザとの諸々の調整をできず、そこまで事態を悪化させてしまったプロジェクト・マネージャに責任はないのでしょうか。


確かに、ユーザ側の要件調整不足に起因する事はあると思いますが、それを補うのがベンダーの役目でもあるはずです。

言われた事のみをやるのであれば、ベンダー側としてはシステム開発のリスクは低くなるでしょうが、システム開発に精通していないユーザにとっては堪ったものじゃありません。

私はユーザ企業向けに、システム企画/システム調達等のコンサルティングサービスを提供しているのですが、

『この様な事態を確実に回避できる策はないか?』と尋ねられれば、回避する確率は高められても、100%保証できる策はない

と言わざるを得ません。

それほどシステム開発は不確実性が高く、ましてや、システム化範囲が広くなればなるほど、システム開発には不確定要素が多くなるのです。


『ユーザには言えないけど、ユーザ側が要件をハッキリとさせないことに端を発している事が多く、ユーザの責任による部分が多いんだよね。』

この言い分が真っ当であるか否か。

それは、ベンダーのシステム開発に対する取り組み姿勢に左右されるところでしょう。

とは言え、ユーザ企業がシステム化の目的や目標、範囲や要件など、システム発注までにやるべき事をシッカリとやる、という事が前提ではありますが。

最後は、ユーザとベンダーの信頼関係に行き着くのではないでしょうか。

こちらもご覧ください

0 件のコメント:

コメントを投稿

システム設計書

システム設計書 システム開発における設計書。 名前の付け方、内容の記述の仕方、実はこれ、ベンダーによってまちまちなんです。 名前の付け方に関して言えば、外部設計書/内部設計書というベンダーもあれば、基本設計書/詳細設計書というベンダーもあります。 場合によっては...