設計についてわかりづらいご質問ですが・・

質問

現在概要設計というフェーズで作業をしています。PGや保守など技術寄りの仕事が長く、はじめての上流の仕事なのですがちょっと壁にぶつかっています。

現状としては業務フローが機能分割され自分はそのうち５機能ほどを担当しています。
でその機能をプログラム化をイメージした設計書に起こす必要があるのです（ちょっと詳細よりかもしれません）。

ただどうも自分の意識の問題かもしれませんが、プログラム化をイメージはできますが業務よりの下記のような意識（発想）がなかなか持てないのです。

・業務全体としてその機能の役割
・業務であり得るデータのパターン
・各論理テーブルが持つ業務的な役割

結局、業務的な説明ができないため作成した設計書のレビューでうまく話ができない状態です。
なにかきっかけをつかみたいのですが・・。
わかりづらい内容ですがどうぞよろしくお願いします。

回答No.7

Broner

あなたの質問を見ますと、統括責任者の説明能力不足のように思われます。
　概要設計ということですので、目的はこういう業務フローを作って、プログラム化をイメージできるような設計書を創ることですね。
　要するにあなたは、業務全体としてその機能の役割が分かっていないのです。教えられていないのです。
　そういう時は、あなた自身で全体のフローを作ってみることです。それも次のような段階を想定して創るのです。
(1). 全体の業務フローの概要を10項目位で書いてみる。そう非常に大雑把な概要フローを創ること。
　　これが出来ると業務の全体が見える。

(2). 少し詳しく、全体の業務フローの概要を30項目位で書いてみる。そう非常に大雑把な概要フローを創ること。
　　これが出来ると業務の各部の機能が見える。

(3). もう少し詳しく、全体の業務フローの概要を50項目位で書いてみる。そう大雑把な概要フローを創ること。
　　これが出来ると業務のデータのパターンが見える。
　そう要するに、業務のフローを大雑把に創ってみる事、次に少しづつ業務のフローを詳しくしていく、そうすればある段階でいろんなことが明確に定義できるようになる。
これが業務を行う、全ての基本原理です。

お礼

わかりづらい質問でしたが詳細なご説明をありがとうございます。

＞＞プログラム化をイメージできるような設計書を創る

今まさにこの作業をしております。
教えられていない、というよりは「業務全体としてその機能の役割が分かっていない」の方が１００％近いかもしれません。
他の機能を担当する人から「あなたの担当機能ではどうしてこの処理をするの？」と聞かれ「業務的フロー」の観点からうまく回答できないのです。

「最終的にこのデータストアにこのデータ形式に格納するため」という自分の担当機能に終始した話では外部の方は理解できないんですよね。。
結局「勉強不足」「あなただけには任せられない」と言われ悔しい思いをしております。

また全体打ち合わせで「業務的にはこうだからデータはこうで・・」という業務全体（顧客視点）の話もやっぱりついていけず発言すらままなりません。

結局こういった状況を変えるには何か今までとは違う視点で仕事をする必要があると思い投稿した次第です。

ご教授頂いた方法を早速試してみます！。ありがとうございました。

回答No.6

Samurai-Jack

No.5です。

細かい状況がわからないのに余計なことを言って申し訳ありませんが、業務フローにデータストアは載せない方がいいと思いますよ。業務フローはあくまでも業務の流れを記述するもので、細かいデータは載ってこないものだと思います。

データストアはＤＦＤに載せて、データの流れを分析しないと、正しくＥＲ図が書けないのではないでしょうか？時間があれば、ＤＦＤを作成することをお勧めします。

回答No.5

Samurai-Jack

＞でその機能をプログラム化をイメージした設計書に起こす必要があるのです

まだ、プログラム化をイメージするのは早いんじゃないですかね？？簡単な画面をイメージしていった方がいいと思います。

システム化するということは、今まで紙ベースでやり取りしていた情報を画面に打ち込んで処理を行うということになります（簡単に言えば）。ですから、ユーザーとしては、いままでの業務がシステム化することによってどのように変わるのかが興味のあるところだと思います。

したがって、レビューする時は、現行の業務がどのようにシステムに置き換わるのかを説明するといいと思います。

このためには、まず業務フローを作成し業務を理解する必要があります。そしてＤＦＤを作成してデータの流れを分析する必要があります。そうすれば、どこに画面が必要になってくるのかが見えてきます。また、データストアがはっきりするので論理テーブルが持つ業務的役割がわかると思います。

まずは細かいところにはこだわらず、大枠で捕らえていくことが重要だと思います。そして、自分の担当機能だけではなく、全体の機能から見ていくと、自分の担当機能の役割がはっきりしてくると思います。

答えになっているか判りませんが、数をこなしていけば自然と理解できてくると思います。（大体どんな業務でもやっていることは似たようなものですからね）

今は色々悩みが多いと思いますが、頑張ってくださいね！

お礼

大変参考になりました。ありがとうございました。

現状あるのは業務フローと論理ER図で業務分析が終わった状態です。業務フローには参照するデータストア名は書いてありますがDFDのような資料はなくER図と分析者からヒアリングして理解、という状況です。

自分の役割はそこから落としこむことですが担当機能だけに視点があり全体のデータの流れを見落としていたかもしれません。

そもそも概要設計って言葉が初めてでどこまで落とすかが
見えていなかったのですが・・。
ちなみに画面設計は別部隊が作業していますがやはりその基準がわからず苦労しているようです。

もう一度最初にどうデータが作成され、最終的にどうなるか見なおそうかと思います。

回答No.4

g_express999

業務を一番よく知っているのはお客さんですから、分からない部分は徹底的にお客さんにヒアリングするしかありません。
また、お客さんの仕事を実際に見学してみるといいかもしれません。業務フローがビジュアル的にイメージできるはずです。

回答No.3

gc-arashi

質問があまりにも漠然としていて回答になっているかどうか分かりませんが・・・
まず大切な事は、現在どういう形で貴方の担当している「機能」というものが働いているかを理解すること
ではないでしょうか？
あなたの設計するものでソフトが動くのか、機械が動くのか、はたまた人間が動くのかは知り様がないので
すが、とにかく現状で貴方が設計しようとしてる「機能」の働きや長所・短所を掴むところから始めなけれ
ば設計のし様がないと思うのです。
それからもう一つ大切なことは、貴方が担当する機能の前の段階と後の段階、つまりインターフェースです。
どういう形で前の工程から仕事を引き継いで、そしてどのようにして後の工程が貴方の工程に求める機能は
何なのかが分からないと、設計の初めと終わりが定まりません。その点については、貴方の前後の機能を設
計する担当者と十分に話し合い、理解する必要があると考えます。
頑張って下さい。

お礼

大変参考になりました。ありがとうございました。

現状あるのは業務フローと論理ER図で業務分析が終わった状態です。業務フローには参照するデータストア名は書いてありますがDFDのような資料はなくER図と分析者からヒアリングして理解、という状況です。

「インターフェース」、「機能の働き」などご指摘頂いた内容の認識がやっぱりかなり足りなかったように思います。もう一度見なおしてみます。ありがとうございました。

回答No.2

gc-arashi

質問があまりにも漠然としていて回答になっているかどうか分かりませんが・
まず大切な事は、現在どういう形で貴方の担当している「機能」というものが働いているかを理解すること
ではないでしょうか？
あなたの設計するものでソフトが動くのか、機械が動くのか、はたまた人間が動くのかは知り様がないので
すが、とにかく現状で貴方が設計しようとしてる「機能」の働きや長所・短所を掴むところから始めなけれ
ば設計のし様がないと思うのです。
それからもう一つ大切なことは、貴方が担当する機能の前の段階と後の段階、つまりインターフェースです。
どういう形で前の工程から仕事を引き継いで、そしてどのようにして後の工程が貴方の工程に求める機能は
何なのかが分からないと、設計の初めと終わりが定まりません。その点については、貴方の前後の機能を設
計する担当者と十分に話し合い、理解する必要がある
と考えます。
頑張って下さい。

回答No.1

noname#105965

習うより慣れるしかない部分もありますが・・・。

まずは、業務内容やワークフローを理解し分析することです。
さらに、顧客が望んでいるのはどういう仕様なのか？
どうしたら顧客が作業を楽にできるか？等々、
顧客の視点に立って考えてみてください。

画面イメージがあると話がしやすいですよね。
業務フローにどういうデータが流れるのか書き込んでみる。
プログラムの事を考えるのはもう少しあとでいいかもしれません。

あとは、場数を踏むしかないですね。