システムエンジニアが業務知識を理解するということ

質問

プログラマ以上システムエンジニア未満の者です。
仕様書を元にプログラムする とか ごく小規模な機能の設計はできる(と思っている)のですが、
ある程度以上の規模の設計になると、途端に難しく感じます。

具体的には、現行業務を理解ができないのです。
理解ができないと言っても、説明して貰った事柄は分かった気になるのですが
その知識をもとにして、“あんな場合はどうするのか？” “少し異なるこんなケースはどうするのか”と視点を変えて理解していく作業ができません。

私自身の性格的にも言葉のまま受け取ってあまり疑問を持たないことが多いです。

これが例えば資格試験だったら
教科書を書いてあることがどのくらい理解できてるか
練習問題が解ければだいたい理解できてるかで
自分はまだ理解できてないとか、だいたい理解できてる、といったことがわかりますが

自分は現時点で全体の何%くらい理解できているのか、わかりません。
これだけ理解しているから大丈夫と自信を持って言えません。
足りてないだろうな、と感じるのですが、何が理解できてないのか分かりません。

まとまりのない文章になってしまいましたが、業務を理解するってどういうことでしょうか？

回答No.4

o09080706o

使ってみて、使いにくい部分についてクレームを入れるということをすると思います。

使いにくさについては、下記の本で理解できるかもしれません。

誰のためのデザイン?―認知科学者のデザイン原論
http://www.amazon.co.jp/dp/478850362X

回答No.3

toi_awase_01

ひと言でいえば経験ですね。

＞小規模な機能の設計はできる(と思っている)

私も若い頃、業務知識を身につけろと散々先輩に言われ続けました。（笑）
業務知識を身につけるには、お客様の立場に立って考えろと言う事です。
お客様は業務知識しかありません。（当然プログラミングの事は知らないので）
SEは、お客様の立場に立って考えつつシステム化を実現するためにはどうしたら
最善かを並行して考えます。
設計書はお客様目線でシステム化されたものを作成してレビューします。
プログラマーには更に具体的なDBレイアウトや処理の流れ（フローチャート）
や具体的な処理内容を作成し説明して依頼します。
単体テストが終わったものを結合し総合テストの際に「シナリオ」が書ける人が
SEとなります。
また、お客様とのヒアリングの際に、SEは例外ケースを想定しながらヒアリング
し、出来る限りその場で回答も頂きます。
お客様は例外時の作業の事は頭で分かっていても言わない事が多いです。（笑）
例外ケースが実際に発生して慌てるSEは未だ本物ではありません。
（私もまだまだですが（笑））

コミュニケーション能力や行間を読む力が試されますので、業務知識を習得すると
更に仕事が楽しく感じられますし、お客様もSEが自分達の業務を理解している事を
知ると安心し、更に親しくなるような感じが私はします。

業務知識が苦手やお客様との打ち合わせが苦手と言う事になれば、PGに留まる
しかありません。
この業界に入る時は、あまり人と話をしたがらない人が多い（私も）と思って
入ったのですが、ほんの数年でそんなことを言っていられなくなります。（笑）
実はSEには他にもやらなければイケナイ仕事（プロマネ的な事）があるのですが
省略します。

最初からSE・PG両方できる人はいませんので、結局経験を積む以外にありません。
焦らず「小規模な機能の設計」から徐々に慣れていく事ですね。

回答No.2

sigesigeo1919

対象の全体像（アーキテクチャ）が理解できていないのかなーと思います。
全部を理解するには細かい知識が必要になりますが、既存のシステムやプログラムの役割はある程度分類分けできると思うので、どういったシステム、プログラムが存在するのかをふわっと知ることで、現行業務がどういった役割に位置するのか俯瞰することができるようになるのかなーと思います。

私はお勉強が苦手なので、関わっている狭い範囲から、理解を外に広げていくことでシステム全体が理解できるようになりました。
ただ、とても時間がかかりました。
事前に世の中にはどういったシステム、プログラムが存在するかの分類を知っておけば理解はもっと早かったかなと思っています。
振り返ってみれば、あーこれっていわゆる〇〇ってゆーシステム構成じゃん！といった具合でした。

参考までに。

回答No.1

drum_KT

あなたの場合は、逆にもっとプログラミングの経験を積んだ方が早道かもしれません。

例えば、あるデータをこれこれこういう風に扱ってくださいと言われた時、プログラマーなら即座に「それは数値として扱うべきなんだろうか？それともコードとして扱うべきなんだろうか？実際の変数の型は何にしようか？」と考えるはずです。その答えが与えられた仕様から読み取れない（不明確である）ということがわかれば、そこは仕様を提示した人に質問すべき内容ということになります。

この時、けして「書いてないけどこういう解釈でたぶん良いだろう」という思い込みで判断しないことです。