業務システム設計が難しい理由を私に分かるように説明してもらえませんか？

投稿者

投稿内容

七味唐辛子: ぬし; 会議室デビュー日: 2001/12/25; 投稿数: 660

投稿日時: 2006-07-23 22:37

引用:
キャットマンさんの書き込み (2006-07-20 20:24) より: 私が思うに業務システム設計はコンピュータの命令の羅列を集めたものに過ぎない。

命令の羅列で開発できるなら　苦労しないんだが,,,
こんなのが上にいると配下のメンバー苦労するんだろうな

桜緋女: 常連さん; 会議室デビュー日: 2004/09/15; 投稿数: 46

投稿日時: 2006-07-24 12:51

　まじめな話、そもそも「業務を理解すれば」という前提条件のところが一番難しいのではないでしょうか？
　
　システム化によって業務を効率化しないといけないということは、
クライアントの中でも十分に個々の業務の連携が取れていないということですよね。
　本職の人たちでもすべての部署の業務を把握できないのだから、横からフラっと入って個々の業務間の連携や影響範囲をすべて洗い出すのが生半な仕事でないのは自明の理かと。

がんふぃーるど: ベテラン; 会議室デビュー日: 2006/06/05; 投稿数: 58; お住まい・勤務地: さいたま

投稿日時: 2006-07-24 15:10

システムが上がってこないこないのであればキャットマンさん自身がもう少し
マネージングしてあげればよろしいのではないでしょうか？
状況から下請けがロスコン状態（もしくはロスコン一歩手前）な気がします。
このままだと動かないシステムが上がってきて、泣きを見る可能性が大です。
専門書をいくつも読まれているみたいなので、下請けの現状を把握すれば、
それなりの手を打てるとかと思います。
最終的に責任を取るのは下請けではなくあなた自身なのですから、何か手を
打ったほうが良いかと思います。

mio: ぬし; 会議室デビュー日: 2005/08/25; 投稿数: 734; お住まい・勤務地: 神奈川県

投稿日時: 2006-07-24 15:37

「できない」のと「やらない」のと、二通り考えられますが、前者だとすれば。
能力が不足していることも多々あるけど、
元請からの情報が少なすぎることもある（「もっと教えろ」と言えばいいんだけど）し、
根本的に無理な注文をしていることもある（「できない」と言えばいいんだけど）。

単純に「上がってこない」というだけでは、状況は誰にも分からないし、
「現状どうなってるんだ」と、ちゃんと聞いてみるべきじゃないかと。

と、あえて答えてみた。

nagise: ぬし; 会議室デビュー日: 2006/05/19; 投稿数: 1141

投稿日時: 2006-07-25 11:57

引用:

キャットマンさんの書き込み (2006-07-20 20:24) より:
実は、納期を大幅に過ぎても下請けからシステムがあがってきません。
私が思うに業務システム設計は
コンピュータの命令の羅列を集めたものに過ぎない。
顧客の要求や部署間同士の事情などを配慮しても
その都度、命令を入れ替えるだけなのだから
業務を理解すれば難しいことではないと思うのだが。

ひとつ失念していることがあります。
システムを作る際には「全ての要件を」あらかじめ網羅しなければなりません。

通常の業務ではイレギュラーケースはマニュアル化されていなくて
その都度詳しい人に聞くことよって解決されていたり、
まったく想定していなくて発生した時点でおろおろする

なんてことがあるわけですが、システムにする時点で
そういう考慮漏れがいろいろ出てくるので
そういう部分をどう対処するかというところが難しいですね。

仕事なんて、その都度ケースバイケースで判断してやるわけですが、
システム化ってのは「判断を機械に任せる」わけですから、
難しい判断を機械にさせるより、機械に出来るところだけ
うまいこと抜き出して処理の高速化を図る、という程度の
スタンスでシステム化を考えるほうが現実的なモノになるように思います。

はっきりしている部分をシステム化するのは難しくはありません。
しかし、中にははっきりしなくて難しい部分もあるでしょうし、
その難しい部分を全部クリアしないとシステム全体は完成しません。
現場の実感としてのシステム開発の難しさってその辺じゃないかなぁ。

# 現場についての評価などはノーコメント

ＪＩＭＭＹ: 常連さん; 会議室デビュー日: 2004/10/26; 投稿数: 32; お住まい・勤務地: 東京

投稿日時: 2006-07-25 15:31

引用:
キャットマンさんの書き込み (2006-07-20 20:24) より: 私が思うに業務システム設計はコンピュータの命令の羅列を集めたものに過ぎない。顧客の要求や部署間同士の事情などを配慮してもその都度、命令を入れ替えるだけなのだから業務を理解すれば難しいことではないと思うのだが。

システム設計とプログラミングを混同していらっしゃるようですが、キャットマンさんはシステム開発のご経験はありますか？
言葉に対しても、会社によっては指している意味合いも違う場合があるので、もしかするとキャットマンさんの認識に誤りはないのかもしれませんが、私の認識という枠で簡単にお答えしたいと思います。

今まで、コンピューターを導入していなかった業務に対して、新規に開発を行う場合はまず、どの作業をシステム化するかを考えます。
一般的には伝票や書類で管理している情報の管理部分をシステム化しますが、顧客要件によっては物の運搬の仕組みもシステム内で制御する場合もあります。

次に、どの項目／内容／状態を管理するかを決めていきます。
この管理する情報を元にデーターベース設計や、登録/更新/削除/照会のタイミングなども決めていきます。
データーベースの構造によって、拡張のしやすい機能や、拡張のしにくい機能が決まってくる場合も多いので、この作業は業務に対する知識やシステム開発経験などの、いわゆる
ノウハウが必要になってくると思います。

あとは、ユーザーインターフェースや、加工処理の設計等が出来て、初めてプログラムに取り掛かります。
でも、これらは通常、業務を知っているお客様の協力なしには出来ませんし、仕様が決まらなければ先に進まない作業も出てきます。
仕様決定は、「業務上どうしなければいけないか」を知っているお客様に判断していただかなければならない部分も多くありますが、それらが解っている前提であれば、あとは命令を並べていくだけでしょう。

納期が遅れている事は問題ですが、何故遅れているのかは確かめなければいけないでしょうね。
また、仕様決定が遅れているとか、お客様との協力体制がきちんと整っていない場合は、作業の受託側の調整不足もしくはお客様側のシステム開発に対しての理解不足の可能性が高いのではないかと思います。
（人材不足だとか可能性は他にもありますけどね）

未記入: 大ベテラン; 会議室デビュー日: 2005/03/12; 投稿数: 148

投稿日時: 2006-07-27 09:46

業務システムって具体的にどんなもので
仕事をどのように進めているのかわかりませんが、
下請けに業務システムを投げた時点で失敗が決まっていたのかもね。

> その都度、命令を入れ替えるだけなのだから
･･････
> 業務を理解すれば難しいことではないと思うのだが。

仕様変更が頻発しているの？
そりゃ駄目なパターンだな。

自分の会社の業務であっても他人の仕事まで
会社全体をすべて把握している人なんてそう居ないでしょ。
思いついたように、こうしたほうがいいなあ～みたいに後から色々出てくる。

個々の命令の関連性がまったくないならいいけどね。

業務システムなんて長期化して失敗するのさ。
見積もりが安くて速いところは経験低いところだろ。

自社の業務をすべて把握している人が参画すべきだな。
で、その人があらゆるトラブルの組み合わせが発生しても
矛盾の無い完璧な設計を短期間で作り上げて
仕様変更はその人が拒否するんだよ。
↑無理だけどね。

[ メッセージ編集済み編集者: 未記入編集日時 2006-07-27 09:54 ]

«前のページへ 1|2

業務システム設計が難しい理由を私に分かるように説明してもらえませんか？

スキルアップ／キャリアアップ（JOB@IT）