ユーザーとの関係

システム開発を行う上で絶対に必要な人は間違いなくユーザーです。
システムから見れば開発ベンダーは何処でも良いですが、
要件定義元であるユーザーは変更する事はできません。
変更するという事はシステムが変わるという事になりますので．．．

で開発ベンダーとユーザーの関係を考えます。
開発ベンダーはユーザーから仕事を頂いて働くわけですから
ユーザーは開発ベンダーから見ればお客という事になります。

「お客様は神様である」という話が良く聞かれますが私の考え方は違います。
ユーザーが開発ベンダーを決定した段階で関係は対等です。
後は一つの目標に向かって協力していく必要があります。

開発ベンダーは手を抜いて儲けようとは思ってはいけませんし
ユーザーは抽象化させ過ぎて何でもかんでも
開発ベンダーに作業させてはいけません。

直接的な事を言えば
「一定の作業を一定期間で完了させる事をある金額」で受注しています。
それを超えた場合、契約範囲外作業となり契約上お客ではなくなります。
もちろん、こんなにドライな意見が現場で通る訳ではありませんが
これは常に頭で考えて置くべきです。

つまり作業を行う時は、範囲外作業となってしまう場合
過剰な機能を作成しようとしている可能性があります。
それを開発ベンダーはコントロールする必要があります。
時には「それは契約外機能となるので追加が発生する」と
言って上げる事が良い事もあるでしょう。

逆にユーザーは要件を決める上で欲張ってはいけないという事になります。
自分達は何を作りたいのかを常に考えて要件を決める必要があります。
これがぶれると過剰な機能が原因で、本当に必要な機能を影響を与える。
パフォーマンスを期待しているのに過剰な要件のために大幅に劣化してしまう
と言う事になります。
ユーザーが一番考える必要があるのは
「システムを作るのは自分達である」という自覚でしょう。

それぞれこのような立場で仕事をする人が
上手に付き合っていくには信頼関係が必要になります。
これを築く事ができれば、お互いに本当の目標を共有できる事になるので
それを達成するための最も良い方法を考える事になります。

またお互いには、それぞれの仕事があるという事も重要であると考えます。
そのため余計な口出しは不要という事です。

開発ベンダーは過剰に発生してしまう要件から
本当に実現したい要件は何であるのか見極め、
ユーザーに理解させる事から始める必要があります。
それは、要件を変えるという事ではなく気付かせるという事です。
そして決まった要件を開発ベンダーの勝手な要望で変更する事はできません。
あくまでも要件を決めるはユーザーです。

またユーザーは開発ベンダーが要件を実現する方法に対して
議論するドキュメントが存在し、
それについてはお互いに議論をすれば良いのですが
その先に開発ベンダーが作成するドキュメントに対しては
口を挟んではいけないと考えます。
ユーザーが読むという事は開発ベンダーは
ユーザーが理解できるように作成する必要が出てきます。
必ずしもそれは良いドキュメントとは言えないからです。
通常は悪くなると考えるべきです。


必ずお互いの立場を尊重して仕事をする必要がありますね。
どちらかが偉いという事もなければ、
どちらかが不必要という事もありませんので。