2005年07月08日

60.システム設計は、例外設計とエラー対処

今日は朝に書いてます。おはようございます!

久々にシステムの話。

特にシステム設計に携わる人に知っておいていただきたいことなんですが、
基幹業務システム(※1)のプログラムを作るときのこと。

※1:会社の基幹となる業務のシステムのことです。
   例えば、製品の受注、出荷、売上を管理するための「販売システム」、
   皆さんの給料を計算する、「給与計算システム」なんかが、
   基幹システムにあたり、ないと日々の業務に支障があります。
   コレに対して、文書管理システムなんかは、普通は基幹システムとは
   呼びません。

昔、プログラムを作るとき(まだ経験が浅かったとき)は、意図したとおりの
動きをいかにさせるか、ということばかり考えてしまうものなんですね。

「えーと、ユーザ(システムを使う人)はこの画面で、こういう入力をすると、
 次の画面でコレが表示されて、だからその次の画面では、こういうことを
 入力してもらおう」 とか。

でも、やっていくにしたがって分かったのは、ユーザって、こちらの意図した
通りには、
 ・画面操作をやってくれない

 ・マニュアルを読んでくれない

 ・分からないといろんなボタンを押そうとする


ってこと。

これって、皆さんにも経験ありませんか?
エクセルやパワーポイントを使っていて、

・分からなくても、とりあえずやってみる。

・分からないボタンがあれば、押してみる。

・他のソフトのデータや画像、ファイルなんかを、(できるかどうか調べないで)
 とりあえず貼り付けてみる


・・・こういうのって、ユーザからすると当たり前なんですよね。

でも、作るほうになってみると、ユーザって、ちゃんとこっちの意図した
使い方をする(させる)つもりになるから不思議です。

というわけで、システムは、実現できる機能も大事なのですが、
例外処理やエラー処理、リカバリ処理が非常に大事 なんですね。^^;

作ってみたプログラムを見て分かるのは、
 ・エラーチェック機能や、
 ・間違いが起こらないようにする機能、
 ・間違いが起こったときでも、なんとかシステムが止まらないようにする機能、

なんかが、下手をすると、そのシステムで実現できる機能が書いてある
プログラムの、3倍〜5倍!! というのも珍しくないこと!

(もっと多い場合すらありますよ。(^.^)

これって考えてみれば当たり前なんです。

原子炉設計では、どんなことが起こっても事故にならないように設計する。
(それでも事故がおきますよね。)
ゲームソフトだって、どのタイミングでどのボタンを押しても、おかしな
動作をすることがない。

これは、事前に、あらゆる例外処理、エラーパターンを想定して、その対処を
組み込んでいる 
からなんですね。

システム設計でもまったく同じ。

自分で使うだけのツールとしてなら、そこまでやる必要もないんですが、不特定
多数の人が使うものほど、何が起きるかをすべて考えてプログラムを作っておか
ないと、トンでもないことになります。

ユーザの後ろで、自分の作ったソフトが、どう使われるかを見てたことが
ありますが、本当にびっくりしました。

「そこでそれを押すなよー」とか、
「そんなに、ボタンを何度もクリックしたら困る」とか、
「え?その項目を入れないで終わるの?」とか、そんなのばっか。^^;

だから作ったプログラムのテストをやる時だって、ほとんど例外処理や
エラー処理をやったときの動作になるんですね。

システム設計は、エラー対処処理、例外処理が大事!って覚えておいてください。
(やったことのある人には、当たり前なんですねー。)

<こんな行動いかがでしょう?>
  今日の仕事で1つ、あなたの思った通りにいかない場合の、
  安全装置(そのときどうするか)を考えてみる



---------------
今日もお役に立ちましたら、下記クリックをお願いしまーす。^^;

人気blogランキング
  

Posted by fastwork at 07:38Comments(0)TrackBack(0)

2005年06月14日

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

さてさて、前編(こっちから読んでくださいね) では、

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

と言いまして、その続きです。

これって、考えてみると、世の中に出回っている製品全てに
当てはまるんですよね。

例えば、テレビ。
開発している方々は、ものすごい情熱を持って、走査線が何本に増えた
とか、何億色が発色できるとか、素晴らしい新製品を開発しています。

でも、テレビを見ているほうからすると、スペックや性能なんかには
そんなに興味がなくて、

 ・置き場所が少なくて(狭くて)済む
 ・好きな番組が(そこそこ)きれいに見られる
 ・それなりに大画面がいい

というところが、大方のニーズではないでしょうか?
開発者の情熱や、実現されたスペックを考えてテレビを選ぶ人は
少数派だと思います。

作っているほうは、24時間その製品のことを考え続けますが、
使うほうは、なるべく面倒がないように使いたいもの。
言い換えると、
 『よっぽど楽しいものでない限りは、道具のことは考えたくない』
ってことです。

考えるのって、普通は人間苦痛なんですね。(~_~;)

というわけで、システムを作る側と使う側の視点は、全く異なります。

頭では分かっていても非常に難しいのですが、あなたが
システム開発にかかわる方であれば、

・ユーザ(顧客)の業務を理解すること
 (つまり、システムがどのように使われるかを理解すること)

・ユーザ(顧客)の心情を理解すること
 (つまり、システムにより何を実現したいか、どんな面倒を
  解決したいか)


ということを念頭においてください。

(2点目の「どんな面倒を解決したいか」は、前編にも書いた、
 ・いかに安くできるか
 ・いかに楽にできるか
 ・いかに短時間でできるか
 ということですね。)


そういう視点を持つことで、確実に一段上の仕事ができるようになると
思いますよ。
(くどいですが、頭で分かっていても、いざ実践するのは非常に
 難しいです。
 でも、一流になるのであれば、避けては通れない思考なんですね。)


是非、一度「システムは道具だ」の意味を、
良く考えてみることをオススメします。(^。^)


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

人気blogランキング
  
Posted by fastwork at 00:55Comments(0)TrackBack(0)

2005年06月12日

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

が重要、ということ。


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

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

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

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

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

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


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

人気blogランキング


  
Posted by fastwork at 00:41Comments(0)TrackBack(0)

2005年05月16日

データベースを勉強せよ

「システムコンサルタントが教える」と銘打っていながら、システムの話をしたことが無かったので、今日は書いてみます。
(実はこのブログは、開設後1週間までは、「速攻仕事術」というタイトルでしたが、変更したんですよ。)

もしあなたが、次のようなニーズがある場合は、特に今回のトピックを読んでください。
 ・システムコンサルタントになりたい。
 ・会社の業務をヒアリングして、システム設計をする必要がある
 ・現状のシステム機能が、今の会社の業務実態に合っているかどうか判断したい(システム監査をする必要がある。)

そんな時は、システム関連のスキルとして、「データベース」の勉強をしておくことをオススメします。

なんでか?

私は上記のニーズが全てあったのですが、最も役立つシステムのスキルが「データベース」の理解・設計機能だったからです。

「データベース」というのは、システムで何らかのデータを保持・保存しておくときの、入れ物です。

コレを詳細に語ると、非常に長くなるのですが、イメージを、とっても簡単に言ってしまうと、「Excelで作った名簿表(名前、郵便番号、住所、電話番号なんかの項目があって、人ごとにそれぞれの情報が入っている表)」みたいなものだと理解してください。
(あくまでイメージですが。)

そして、システム処理を行うときは、会社で発生した情報をコンピュータの中に保持して、その情報に対して処理をかける必要があります。
その時に、どうやってデータを持たせるか、ということを決めるのが「データベース設計」と呼ばれるスキルになります。

・・・・今日は難しいですかね?SEの人は楽勝?

さて何でそんなスキルが役立つか?

1)システムを作る時、システムで実現したいこと(「要件」といいます)を聞くと、どう実現すれば良いか(逆に出来るかどうか)わかる。

2)今会社でやっている業務を聞いた時に、システムの中身がどんな風になっていれば、それが実現できるかが分かる。
(逆に、システムの中身が違っていれば、「それはシステムで実現できない」となり、システムでは出来てないことになります。)

3)(ちょっと上級スキルですが)データベースを見ると、その会社の業務が分かる。

つまりデータベースは、「会社でやっていること(業務)」と「システムで実現すること」の橋渡しの役割をしてるんですね。

私はシステム系の資格を色々(システム監査、システム管理等)持っているんですが、「データベーススペシャリスト」の資格をとる際の勉強と実際のデータベース設計をした経験が、今の仕事(システム監査、コンサル)に一番生かされていると思っています。

システム監査なんかで会社の業務を聞くと、「データベースはこうなってないといけない」と分かり、実際のシステムの中身(データベースの関連図)を見せてもらうと、「これは実現できる」、「これは実現できないから、システムの外で手処理をしているはず」と分かりますので、「このシステムはここが弱い」なんてのがすぐ指摘できたりします。

システムコンサルや、システムの上流工程(どんなシステムを作るか決めていくようなこと、対して、実際のプログラミングなんかは「下流工程」と呼ばれます。)にかかわって行きたい方、是非データベースの勉強をしてください。

他にネットワークとか、ハードウェアとか、セキュリティとかの勉強の必要もあります(私は苦手 ^^;)が、まずはデータベース。

どうやって勉強するか、とかはまた機会があったら(気が向いたら)書いてみますね。

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

人気blogランキング
  
Posted by fastwork at 00:02Comments(5)TrackBack(0)