システムは道具だ（前編）
久々にシステムのことを書きます。(~_~;)
（「ホントにシステムコンサルタントか？」という疑惑があったりして。。）
特に、システム開発の現場にどっぷり使っている方。
「システムはビジネス上の要件を達成するための手段、道具に過ぎない」
ということを、是非頭の中に置いて下さい。
私は、この約１０年で、
下流のシステム開発（プログラミングやテスト）から、
上流のシステム開発（システム企画、ユーザ要件定義 ※）、そして
システムコンサル（クライアントのシステム評価やアドバイス）、と
仕事が移り変わってきました。
※「ユーザ要件定義」というのは、ユーザの話を聞いて、何をシステムで
作り（実現し）、何をしないか（作らないか）を決めることです。
「何をするか」は決めやすいし、比較的簡単に進むのですが、この
「何をしないか」が曲者。
決めるのは非常に難しく、決まったとしても、簡単にくつがえります。(@_@)
ユーザと開発側の思惑が正反対であることもしばしはであり、
ユーザ側の事情や、力関係なんかで、やらないと決めたことを、
やっぱりやる、ということは非常に多いのです。
で、だんだんシステム開発側の人たち（ＳＥ、プログラマー等）よりは
ユーザ側の人たち（ユーザやクライアント）と接する時間が増えて
いったんですね。
そうすると、自分がシステム開発をしてた頃に見えなかったことが、
だんだん見えてきます。
システム開発にどっぷり漬かっていた頃は、上の人から言われた
システム機能をどのようにシステムとして実装（実現）するか
ばかり考えていました。
「こういう風にプログラムすると、この機能が動くはずだ。
なるべく短い（バグが少ない）ようにしたいから、こんな風に
やってみよう。」とか、
「バグがなかなか取れないなー。どこが間違ってるのかなー」とか
ですね。(@_@)
勿論、「システムの仕様（作り方）を変更します｣ということになると、
今までの作業はやり直しになるし、残業は増えるしで、「最初から
決まった仕様を持ってきてくれー」と思ってました。
「ユーザや、上司は何てわがままなんだー。
簡単に『直せ』とか言ってくれて。。。。」
ってぼやいてたんですね。
でも自分が、ユーザと話し合ってシステムの仕様を決めたり、
決めた仕様を開発サイドに伝える、という仕事をやってみて、
（つまり今までと逆の立場でシステム開発を見ることで）
今までの考えが間違ってたことが分かったんですね。
システムをどうやって開発するか（作るか）は重要ではなく、
システムを作ることで何が実現できるか、つまり、
そのシステムを使う自分たちの仕事が
・いかに安くできるか
・いかに楽にできるか
・いかに短時間でできるか
が重要、ということ。
まあ、使う側からすると当たり前の話です。
でも、不思議なことに、作る側の立場にどっぷり使っていると、
このことが分からなくなってしまうんですね。
周りの人たちも、同じ開発の仲間であり、ユーザから直接話を聞いたり
することはないですから、どうしても「開発をどうやってやるか」に
集中するようになってしまうんです。
というわけで、
「システムはビジネス上の要件を達成するための手段、道具に過ぎない」
ということを、もう一度申し上げておきますね。
（ちょっと長くなるので、続きは明日書きます。(~_~;)
カテゴリ
