2005年06月12日

システムは道具だ(前編)

久々にシステムのことを書きます。(~_~;)

「ホントにシステムコンサルタントか?」という疑惑があったりして。。)

特に、システム開発の現場にどっぷり使っている方。

「システムはビジネス上の要件を達成するための手段、道具に過ぎない」

ということを、是非頭の中に置いて下さい。

私は、この約10年で、
 下流のシステム開発(プログラミングやテスト)から、
 上流のシステム開発(システム企画、ユーザ要件定義 ※)、そして
 システムコンサル(クライアントのシステム評価やアドバイス)、と

仕事が移り変わってきました。

※「ユーザ要件定義」というのは、ユーザの話を聞いて、何をシステムで
 作り(実現し)、何をしないか(作らないか)を決めることです。

 「何をするか」は決めやすいし、比較的簡単に進むのですが、この
 「何をしないか」が曲者。
 決めるのは非常に難しく、決まったとしても、簡単にくつがえります。(@_@)

 ユーザと開発側の思惑が正反対であることもしばしはであり、
 ユーザ側の事情や、力関係なんかで、やらないと決めたことを、
 やっぱりやる、ということは非常に多いのです。

で、だんだんシステム開発側の人たち(SE、プログラマー等)よりは
ユーザ側の人たち(ユーザやクライアント)と接する時間が増えて
いったんですね。

そうすると、自分がシステム開発をしてた頃に見えなかったことが、
だんだん見えてきます。

システム開発にどっぷり漬かっていた頃は、上の人から言われた
システム機能をどのようにシステムとして実装(実現)するか
ばかり考えていました。

「こういう風にプログラムすると、この機能が動くはずだ。
 なるべく短い(バグが少ない)ようにしたいから、こんな風に
 やってみよう。」とか、

「バグがなかなか取れないなー。どこが間違ってるのかなー」とか
ですね。(@_@)

勿論、「システムの仕様(作り方)を変更します」ということになると、
今までの作業はやり直しになるし、残業は増えるしで、「最初から
決まった仕様を持ってきてくれー」と思ってました。

「ユーザや、上司は何てわがままなんだー。
 簡単に『直せ』とか言ってくれて。。。。」

ってぼやいてたんですね。

でも自分が、ユーザと話し合ってシステムの仕様を決めたり、
決めた仕様を開発サイドに伝える、という仕事をやってみて、
(つまり今までと逆の立場でシステム開発を見ることで)
今までの考えが間違ってたことが分かったんですね。

システムをどうやって開発するか(作るか)は重要ではなく、

システムを作ることで何が実現できるか、つまり、
そのシステムを使う自分たちの仕事が
 ・いかに安くできるか
 ・いかに楽にできるか
 ・いかに短時間でできるか

が重要、ということ。


まあ、使う側からすると当たり前の話です。

でも、不思議なことに、作る側の立場にどっぷり使っていると、
このことが分からなくなってしまうんですね。

周りの人たちも、同じ開発の仲間であり、ユーザから直接話を聞いたり
することはないですから、どうしても「開発をどうやってやるか」に
集中するようになってしまうんです。

というわけで、
 「システムはビジネス上の要件を達成するための手段、道具に過ぎない」

ということを、もう一度申し上げておきますね。

(ちょっと長くなるので、続きは明日書きます。(~_~;)


---------------
内容がお役に立てば、今日も下記クリックをお願いしまーす。(^.^)

人気blogランキング




この記事へのトラックバックURL

http://trackback.blogsys.jp/livedoor/fastwork/24944861