システムエンジニアとして知っておくべき業務知識

システムエンジニアとして仕事しています。

自分は、下請け常駐して仕事をするなど、いくつもの現場で経験を積んできました。

しかし、主に開発フェーズ寄りになってしまうため、いまいち業務に関して知識が養えていません。

珍しく、直請けで入った現場でも、やはり業務知識を身につけないといけないなと思う日々です。

見本となる先輩はいるのですが、経験してきた道はやはり違いがあるのでどうしても経験論が多いのが実状です。先輩も何か具体的な方法を教えてあげたいと思ってくれているようですが(^^;)

何か良い業務知識の本などありますか？

よろしくお願いします。

No.1 ベストアンサー 回答者： IDii24 回答日時： 2012/08/12 15:23

ＳＥというのはその意味するところの範囲が広すぎて一般的には理解されていません。

業務設計をするのはＳＥなのか、要件定義からなのか、あるいは開発に入ってからか？
通常業務設計をするのはビジネス側の人間。でもその人間でもある程度システムに詳しくないとできません。これはコンサルの仕事になります。
要件定義の基本はヒアリング、つまり業務に係る人から話を聞いてシステムに仕上げる仕事。通常の日本のＳＥはここからですね。ただここも業務側に人間がする事もあります。
つまりここからやる場合でも業務に精通している必要があるわけでそれは業種によってさまざまです。
上流になればなるほどシステムから離れていくというのは今までの手法。でも最近はクラウドの登場で、どこまでを社内で処理し、どこからを外で処理させるかなど、システムを業務に取り込むことが勝つ為の条件になっています。
業務を知るには直接その業界の知識を身に着けるしかありません。それは金融であったり製造業であったりその道のトレンドを把握します。
つまりこれが出来る人はコンサルとして独立出来るわけでコンサル系の勉強の仕方をするしかありません。
でも日本ではこの分野は非常に遅れてます。こういうのが得意なのは欧米です。つまり訴訟が多い国ではプロセスの作成が第一だから。
一番いい例がＳＡＰの導入コンサル。導入コンサルだけで食って行けるのです。システムは一から作らない。既に確実に動くものを間違いなく導入し余計な感情を入れない。
試しにＳＡＰの導入コンサルのやり方を勉強してみたらどうでしょう。
http://www.sap.com/japan/index.epx

No.2 回答者： drum_KT 回答日時： 2012/08/12 15:47

「業務」という名の業務はありません。

実際に担当するシステムが「何の業務を扱うシステムなのか」がまずポイントです。

例えば、経理処理などを扱うシステムを担当しているのであれば、簿記・会計の知識が業務知識になります。

例えば、製造業の品質管理システムであれば、品質管理の知識そのものが業務知識になります。

例えば、何らかの業界でしか使わない専用のシステムであれば、その業界の業界知識が業務知識になります。


少なくとも、担当顧客の業界で良く使われる基本的な用語等を理解しないと、お客さんとの会話も成り立ちません。全く知識がない状態から始めるのであれば、まずは学生向けの「○○業界入門」のような本を読んでみるところから始めるのもいいかもしれません。

No.3 回答者： itou2618 回答日時： 2012/08/13 07:38

元ＳＥの隠居爺です。

業務を覚えるのに、手っ取り早いのがお客に教えてもらうことです。
ただ、一から十まで聞いていたのでは、相手にうっとうしがられますから、それなりの基礎知識が要ります。
私は、お客に聞くときは予備知識として三割くらいを調べておいて、七割を教えてもらうように心がけていました。
そうしないと、お客が言っている内容が、まったく分からないですから。
大きな書店に行けば、専門書のコーナーに、たいがいの業界の業務関連の本がありますから、お客に聞いて理解できなかった用語とかが載っている本を探してみましょう。

No.4 回答者： yokohamahope 回答日時： 2012/08/14 08:51

具体的な業種を明示されたほうが的確な回答が得られると思います。

No.5 回答者： dionysus_chaos 回答日時： 2012/08/15 10:52

コンピュータやプログラミングの知識、技術に精通していれば、

ユーザからさほど非難されないと思います。
別途、個別に勉強するほどのことは、ほとんどありません。
開発現場で開発しながら、業務知識に精通していけばよいと思います。
業務知識に詳しいことに越したことはなありませんが、
大切なことは、ユーザに対して「業務には興味があります」ということを
アピールすることです。
また、業務知識より、ユーザとのコミュニケーションが大切なので、業務で、
疑問や興味が湧いたら、ユーザーにすかさず質門しましょう。
回答してくれたら、驚いたり、関心したりの反応を見せましょう。
（このあたり、ＳＥは幇間のようなところもあるね）

No.6 回答者： Brian12 回答日時： 2012/08/20 16:37

業務システム構築におけるシステムエンジニアとしての責任は、お客様と開発チームに共通の認識ができるモデル図を作ることと思います。

これは、システム全体から部分についても同じ事です。

この観点から、業務知識の吸収を優先する必要は全くありません。無論、知っていても良いですが、業務は業種どころかお客様ごとに違います。本に書かれた知識は勝手な思い込みになってしまう恐れがあるのです。

＞主に開発フェーズ寄りになってしまうため、いまいち業務に関して知識が養えていません。
その前に、これまでの経験でシステムの妥当性を示す書類はありましたでしょうか。UMLも部分的には評価できますが、全体を示すものではありませんね。業務そのものの前に、システムエンジニアとしては正しいデータがきちんと連携しているかを保証しなければなりません。

さて、その為には、モデル図が描けると良いでしょう。更に、適切な名称を選択ないし命名できること。
モデル図はトム・デマルコ著「構造化分析とシステム仕様」で提唱しているデーターフロー図が良いと思います。
このモデル図は、プロセス名やデータ名を記載しますので、名称に関する整理法を学ぶことをおすすめします。
次のサイトにデータ項目名名体系として図示されています。
http://www.kensc.co.jp/k/advantage/solution/data …
これに、異音同義語を無くする工夫として５W2Hを付加すれば、充分に使えます。（下記の補足を参照下さい）

とは言え、新しい現場でどの様な形でシステムの妥当性を示しているかわかりません。要は情報処理の根元である「データの入出力に齟齬がないということを見えるようにしてある」かなのです。データに違いがない、データがつながっている、それらがひと目で分かるようになっていれば、そこまでは大丈夫です。そうなっていなければ、出来ることとして、問題の箇所を一つ一つ指摘して、直して行きましょう。その数が多く、プロジェクトが破綻すると判断したらリーダーに相談しましょう。


補足：データ項目名名体系
　名称を主要語／修飾語／分類語の語に分解します。分解した語に5W2Hの属性を付加します。次に分解した語別属性別に語を昇順に並べて、異音同義語を見つけます。異音同義語があったら、どちらかに統一するか、新たに標準とする語を設定します。異音同義語でなくとも不適切な表現の語は標準とする語に変えます。この作業を一通り終えたら、名称を標準とした語で置換えます。この結果、標準とした語が不適切な場合は調整をします。
　因みに属性として付加するのは、異音同義語を見つけやすくするためです。必ずしも5W2Hで無くともよいですが、時／所／人／物／方／由／量（／価）の切り口がわかりやすいと思います。